Don't use Aux7 since it's reserved for internal use. The default plugin uses the lower nybble of Cfg.Aux because it's written directly to the U1MB Aux register (which controls the IO signals, etc). If you write a plugin which drives the IO pins, then you'd use Cfg.Aux and a bitmask of $01-$08.
For some value you want to store and retrieve for your own purposes, use a bit from one of the two Ext bytes which are intended for plugin use. Something like:
CartResetFlag = Plugin1
@ dta Item (1,0,Title,ItemType.OnOff,CartResetFlag,Help,Cfg.Ext1,$80)
.byte 'Reset cart',0
.byte 'Toggle cartridge reset',0
This would store the option state in D7 of Ext1, corresponding to D0 of the internal variable CartResetFlag. Your hardware setup code just needs to check if CartResetFlag non-zero and take appropriate action.
Note, this is an approximate example since I don't have the docs for the prior plugin API in front of me. In the new version, the Help field has been completely dropped since more often than not it was just a slightly wordier repetition of the actual menu heading. You may have noticed that context-sensitive usage directions for the selected item type now automatically appear in the status area instead, and this is also true for plugin items.
In the forthcoming update, it's also possible to - for instance - code up a "Reset cartridge now" function which would do the same job as soon as you hit enter on it.
You should also change the plugin signature and name in the metadata area. In the latest firmware, the fact the 2-byte plugin signature is stored in NVRAM is exploited by the BIOS, which now compares the NVRAM signature with the actual signature in ROM and clears Ext1 and Ext2 in the configuration record if they don't match, before updating the signature in NVRAM. This ensures when you flash a new plugin, all its settings are zeroed out (and therefore not out of range) the first time you use it.
In the next setp I wanted to make it configurable: to enable/disable this feature over U1MB menu.
I looked at the source code and I'm confused:
@ dta Item (1,CovoxToggle,Title,ItemType.OnOff,StereoPokey,Help,Cfg.Aux,$01)
.byte 'Stereo Pokey',0
.byte 'Enable/disable stereo audio',0
@ dta Item (1,Device3Toggle,Title,ItemType.OnOff,CovoxFlag,Help,Cfg.Aux,$02)
.byte 'Enable/disable Covox',0
Menu item for Stereo uses CovoxToggle and menu item for Covox uses Device3Toggle ?
The menu is structured as a forward linked list and in this case, CovoxToggle and Device3Toggle are the pointers to the next node. The final item in the list has a next pointer of zero. The first argument is the menu number in which the item is to appear.
PORTB bit 7 is the self-test bit on the 1200XL, just as it is on other XL/XE models. It's overloaded by the 512K RAMBO upgrade, but still functions as the self-test bit unless extended RAM is selected. PORTB bit 7 doesn't access any other "advanced features" on the 1200XL and the self-test will still work following an upgrade to 512K without any kind of hardware switch:
As for the LEDs, these are controlled by bits 2 and 3 of PORTB, and the same bits are employed for bank selection by the 256K and 512K RAMBO expansions (along with bits 5 and 6 or 5, 6 and 7 respectively). The LEDs remain wired up regardless of how much RAM is in the machine and will continue to work when you write to PORTB, but since writing to PORTB also bank switches extended RAM on an upgraded 1200XL, deliberate manipulation of the LEDs must be performed with caution. LED functionality is completely independent from the OS.
If the scope of the upgrade were to broaden to encompass multiple operating systems and 512KB, one might consider Ultimate 1MB, since it provides 1088K, 576K and 320K RAM models plus a choice of four operating systems which may be replaced by any four of your choosing. You also get four flashable internal BASIC slots and the opportunity to drive a cartridge-based PBI IDE hard disk without using a hacked operating system and without the need for a physical PBI connector. When using the newest U1MB firmware, one also gets BASIC suppression without the Option key and high-speed SIO operation regardless of the operating system in use. The board must first be modded for a single-chip OS, but no XL OS ROM IC or MMU is required.
Yeah - that'll do it. If the resulting binary is identical the to published one, you're good. I'll try to take more care when preparing the examples in the update. It's just difficult to think of everything.
The plugins are BIOS version dependent and this is enforced by UFLASH (the plugin specifies the minimum required main BIOS version and won't flash to anything older), but since I changed the layout a little, I broke forward compatibility as well this time, so care should be exercised. Fortunately no-one else wrote any plugins yet, so I saw no harm in making a clean break of it.
I'm working flat-out on numerous fronts at the moment but I updated the screen shots in the manual the other day and with luck I'll spend time on Sunday getting things prepared for release.
Cross-compilation. The plugin source is intended for the MADS assembler, and I'd strongly recommend testing Plugins in Altirra before committing them to real hardware (since a bad plugin can completely brick the system). Personally I use WUDSN IDE in conjunction with MADS, and Altirra's drive 2 is a virtual drive pointing to the fixed MADS target folder. So I can hit Ctrl-Shift-F9 in Eclipse, then hop over to Altirra, log drive 2 in SDX, type UFLASH.XEX and then navigate straight to the file I just assembled. If all is well, I'll save the modified emulator ROM via File->Save Firmware->Save Ultimate 1MB Flash. If the system locks up, I'll figure it out with the debugger and then just shut down and restart the emulator (thereby reverting to the unmodified U1MB ROM).
The plugin equates have changed in firmware version 2.0, and the documentation unfortunately refers to this unreleased revision, so it might be best to wait a few days until I can get this build released (moreover, I made a further change since the current documentation was uploaded: there are now absolute vectors for the printfmsg and confirm functions, so plugins can easily interact with the user and display status messages; I found this useful after writing a test plugin intended to probe behaviour of extended memory and Shadow RAM while the config was unlocked). It's basically being held up by a raft of improvements to the SIDE loader which will hopefully justify the delay. Since you're interested in plugin development (which is great to hear), I'll be sure to update the skeleton code and other example sources before everything is released.
Of course, once someone else starts writing plugins, shortcomings in the API are bound to be uncovered, but hopefully things are reasonably flexible as they are.
One issue is that some of these guys use Apple Macintosh and Mads Assembler and Mad Pascal seem to only run in DOS mode, Command Prompt, or BAT batch file. I would need to set something up for them.
Well, the compilers aren't GUI apps: they're CLI tools. If you read the documentation for either (MADS assembler or MAD Pascal), you'll see you can download the source for both and build them using the Free Pascal Compiler on whichever target platform you like. I believe there are even pre-compiled versions of MADS available for macOS (courtesy of Jac!).
The loader should not freeze because of an IO error under any circumstances (although I don't know how old a version you're running), but there are certain cards (especially SD/CF adapters) which will sometimes cause a complete system-lock up following a hot-swap, which can't be recovered from in software at all. The diagnostic tool should demonstrate - entirely independently of the firmware revision - whether the card is basically reliable. I still recommend SanDisk cards.
I'll PM you the latest RC builds later on. I've somehow been detailing the 1088XEL's loader for the past week (the dual drive aspect threw up some interesting usability issues), but I'm pretty happy with what I have right across the board now.
What do you think about a monolithic binary file (one normal segment, one RUN segment, thus no way to execute a code before it is loaded) that loads let us say to addresses 40145 - 49152 most likely overwriting the screen memory and display list.
But do the two that don't work with SysCheck work with other ECI devices? Until we know that, I don't think we can conclude anything definite at all. I couldn't get my last remaining IDE plus to work with my 600XL until I cleaned the pads with isopropyl alcohol. The more that can be eliminated at this end, the less time Jürgen has to spend investigating potential non-issues.
Fixed issue with IDE slave device response with only a master on the bus. This was due to inconsistency between the CF and ATA implementations -- SIDE/MyIDE/IDEPlus should now have the same behavior here. Getting back $00 is documented behavior (ATA-4 9.16.1 Device 0 only configurations).
Many thanks. XEL-CF also fixed:
Thanks for the ATA documentation reference as well. That would have saved me some experimentation, had I looked that section up.
BTW: I meant to mention - if you're interested in implementing it - that the XEL-CF3 has "swap button" support (similar to the SIDE2 button accessed via System->Console Switches).
The reset register at $D1Cx is now R/W, and returns signature information, button status and can reset the latch independent of the IDE controller: