Horizon RAMdisk ROS and CFG Development

[ckoba]

Not seeing BASIC is a direct result of the AVPC problem-solving effort. I will re-enable it because it ties into your next point....

Thanks for that.

 

Can you go into a few more details concerning the cartridges you put together? How does the MENU included with ROS react to them?

The UberGROMs carts I build have GROMs starting at >9808 (because there's a bug in the console scan routine that expects carts with multiple GROM programs to have their header at the first slot of each GROM address, which is not the case with Return to Pirate's Isle (for example)). They are activated via Tursi's Multicart program at >6000 in cartridge ROM space.

 

ROS's MENU ignores ROM cartridges completely -- Gazoo's collections, TurboForth, what have you. They can be reached, however, by F9'ing to continue with powerups -- console cartridge selection menu comes up and does the right thing.

Edited April 11, 2016 by ckoba

[+InsaneMultitasker]

The UberGROMs carts I build have GROMs starting at >9808 (because there's a bug in the console scan routine that expects carts with multiple GROM programs to have their header at the first slot of each GROM address, which is not the case with Return to Pirate's Isle (for example)). They are activated via Tursi's Multicart program at >6000 in cartridge ROM space.

 

ROS's MENU ignores ROM cartridges completely -- Gazoo's collections, TurboForth, what have you. They can be reached, however, by F9'ing to continue with powerups -- console cartridge selection menu comes up and does the right thing.

MENU 7.3 contains code for ROM cartridge support, based on a header at 0x6000. I would think Menu 7.39 should have it as well.

 

The MENU 7.39 Fctn9 code restores a few conditions necessary to continue the powerups or drop to the title screen. I've made a few notes and will look into this further.

[ckoba]

MENU 7.3 contains code for ROM cartridge support, based on a header at 0x6000. I would think Menu 7.39 should have it as well.

I take it back -- it's there. Need to hit "S" instead of "G" to switch to it. My bad.

 

(The ROS documentation from whtech.com is in serious need of OCRing -- it's practically unreadable)

 

The MENU 7.39 Fctn9 code restores a few conditions necessary to continue the powerups or drop to the title screen. I've made a few notes and will look into this further.

Thanks for that.

[+InsaneMultitasker]

The UberGROMs carts I build have GROMs starting at >9808 (because there's a bug in the console scan routine that expects carts with multiple GROM programs to have their header at the first slot of each GROM address, which is not the case with Return to Pirate's Isle (for example)). They are activated via Tursi's Multicart program at >6000 in cartridge ROM space.

 

ROS's MENU ignores ROM cartridges completely -- Gazoo's collections, TurboForth, what have you. They can be reached, however, by F9'ing to continue with powerups -- console cartridge selection menu comes up and does the right thing.

 

I added code to allow the 9640 menu to return to the previous powerup - from the console or RAMdisk - with an alternate exit key.

 

I am at a cross-roads on how to handle the cartridge space. I would like to replace the current method with a display of all associated GROM carts, selectable from one screen. Maybe A-Z to keep it simple. I also want to display the grom bank number with the cart name in the event of multiple entries. ROM carts could be handled similarly, though I'm not sure I want to deal with that challenge right now. Dropping back to the cart is much simpler or those..

[ckoba]

I added code to allow the 9640 menu to return to the previous powerup - from the console or RAMdisk - with an alternate exit key.

 

I am at a cross-roads on how to handle the cartridge space. I would like to replace the current method with a display of all associated GROM carts, selectable from one screen. Maybe A-Z to keep it simple. I also want to display the grom bank number with the cart name in the event of multiple entries. ROM carts could be handled similarly, though I'm not sure I want to deal with that challenge right now. Dropping back to the cart is much simpler or those..

Neat. Can I test it out?

 

For the cartridge space, I'd list the detected GROMs and >6000 only. The way we're building ROM cartridges nowadays, what with the "map pages to >6000" scheme, there's not much point in iterating through the space for additional carts. They wouldn't run anyway, as they'd expect to be at >6000. Pick up the >6000 header and call it a day.

[+InsaneMultitasker]

Neat. Can I test it out?

 

For the cartridge space, I'd list the detected GROMs and >6000 only. The way we're building ROM cartridges nowadays, what with the "map pages to >6000" scheme, there's not much point in iterating through the space for additional carts. They wouldn't run anyway, as they'd expect to be at >6000. Pick up the >6000 header and call it a day.

 

Let me add the BASIC grom detection back into the mix first. I also see I exceeded the size Gazoo set up for the first BOOT file within the ubergrom. He limited it to 6k versus 8k, so I need to work around that issue.

[+InsaneMultitasker]

BASIC detection is restored. I will need to revise my AVPC interrupt workaround.

 

Exiting the menu and returning control back to the console works, if not a bit too aggressively. For example, if I load the menu from the E/A cart, the menu returns to the cart and does some strange things, then continues the powerup. Since the RAMdisk MENU was intended to be run from the RAMdisk at powerup, I may need to limit the 9640 menu return to autostarts only. This is complicated by the XB27 Suite's method of executing the menu first from disk then from internal 'GROM'. Time to put the code (and myself) to bed for the night.

[+InsaneMultitasker]

This afternoon I was trying to find information related to the TI's powerup and review library functions. I wrote a small routine to find the grom headers to build a cartridge list for MENU and BOOT, but some cartridges like XB and EA show up in every GROM base. I haven't figured out a way around this yet (grrrr) but I came across this thread from Tursi that gave me an "ah hah" moment for a recent problem that had me stumped:

 

http://atariage.com/forums/topic/218096-multicart-menu-software/?do=findComment&comment=2856710

 

Whenever I tried to launch XB from BOOT/MENU loaded via a Horizon RAMdisk autostart, XB would fail miserably. Sometimes garbage on the screen, other times lockup. If I bypassed the Horizon menu autostart, executed Gazoo's cartridge menu, selected EA, and loaded BOOT/MENU, XB worked just fine. It seemed to be an environment setup difference and one that was quite elusive. (Telco also exhibited some strange behaviour that may or may not be related)

 

In th thread Tursi made mention of setting the proper ROM bank, "Of course, the ROM page is going to matter to RXB, REA (part of the same set), and Parsec, as well. So for each of those, I did a small patch to their startup routine to set the valid ROM page,". Ah hah!

 

Not having much experience with these carts, it never occurred to me to set the ROM page. I expect if I look more closely at Gazoo's powerup and/or startup code, he is setting the ROM page early in the process. Once I added a "CLR @>6000" instruction to BOOT, I was able to successfully start XB and the related problems disappeared.

 

I intend to modify the Ramdisk OS so that its power-up forces UberGRoM and ROM cartridges to bank 0. I would save and restore the contents @>6000, just in case a RAM-based supercart is inserted.

 

Any thoughts or gotchas that come to mind ?

[TInaut]

 

Not having much experience with these carts, it never occurred to me to set the ROM page. I expect if I look more closely at Gazoo's powerup and/or startup code, he is setting the ROM page early in the process. Once I added a "CLR @>6000" instruction to BOOT, I was able to successfully start XB and the related problems disappeared.

 

I intend to modify the Ramdisk OS so that its power-up forces UberGRoM and ROM cartridges to bank 0. I would save and restore the contents @>6000, just in case a RAM-based supercart is inserted.

 

Any thoughts or gotchas that come to mind ?

Because you are going to restore contents @>6000 and you are trying to keep BOOT to 6K, unless you are trying to preserve status bits, none of which CLR affects, use "MOV(B) @>6000,@>6000" or "C(B) @>6000,@>6000" or "SOC(B) @>6000,@>6000".

 

I prefer the SOC(B) option. The C(B) option will always set the EQ bit of the status register and clear higher and greater bits. The MOV(B) and SOC(B) options will affect higher, greater, and equal bits by comparing destination results to 0.

[+InsaneMultitasker]

Because you are going to restore contents @>6000 and you are trying to keep BOOT to 6K, unless you are trying to preserve status bits, none of which CLR affects, use "MOV(B) @>6000,@>6000" or "C(B) @>6000,@>6000" or "SOC(B) @>6000,@>6000".

 

I prefer the SOC(B) option. The C(B) option will always set the EQ bit of the status register and clear higher and greater bits. The MOV(B) and SOC(B) options will affect higher, greater, and equal bits by comparing destination results to 0.

Good idea. I hadn't considered C or SOC as options to conserve space.

 

Adding this code to BOOT is pretty simple. Adding the same code to the Ramdisk OS is tougher with its DSR space constraints; however, I feel it is an important and necessary compatibility update. Ckoba first noticed that when MENU isn't installed on the ramdisk, the powerup routine tries to start the primary cartridge (in XB27 Suite's case XB27) and fails miserably. Now we know why.

[+InsaneMultitasker]

I inspected Telco's startup code to determine if its lockups were truly related to the ROM bank. As some may know, Telco tries to identify available memory to load its various modules in order to reduce disk loading time. Here is a snip from the memory identification routine:

 

 

       mov @>6000,r1   read current value, save to R1
       inv @>6000      invert the data at this address
       c @>6000,r1     then compare the two values
       jne RAMFND      if not equal, assume ram is present

 

Telco first saves the value at 0x6000 into a register for later comparison. When the value at address 0x6000 is INVerted, the write sets the bank to #0. When the comparison occurs, if the bank was not already #0 (i.e., it changed) there is a strong probability the value at 0x6000 will have changed. Telco cannot distinguish between RAM and a banking operation and in most cases, will assume RAM is present. A similar test is performed at 0x7000, presumably to test for the mini memory cartridge RAM.

 

The problem manifests when an Ubergrom/multicart starts up/presents a bank other than 0. The XB27 suite does set the ROM bank on its own but when preempted by the Horizon RAMdisk or other powerup routines, the cartridge state is indeterminate. For Horizon owners, the fix will be incorporated into the ROS barring any unintended consequences.

[ckoba]

I intend to modify the Ramdisk OS so that its power-up forces UberGRoM and ROM cartridges to bank 0. I would save and restore the contents @>6000, just in case a RAM-based supercart is inserted.

I am very very okay with a software fix to a hardware "documented exception".

 

Query: could this be an ROS that doesn't use on-chip buffers, and therefore can live in an EPROM?

[+InsaneMultitasker]

I am very very okay with a software fix to a hardware "documented exception".

 

Query: could this be an ROS that doesn't use on-chip buffers, and therefore can live in an EPROM?

ROS is split into a 6K section (the 8k SRAM) and 2K banked sections (the rest of the ram chips). The 6K section houses the DSR and buffers and other information that would first need to find a home elsewhere and still be visible while accessing the 2K sections. A bit of analysis is required to answer your question.

[Tursi]

Good idea. I hadn't considered C or SOC as options to conserve space.

I don't think C will work... that only reads the addresses. You need a write in order for the banking to occur.

 

Cool investigation

[+InsaneMultitasker]

ROS 8.32 has been updated to 'set' the multicart/UberGROM ROM to bank 0. I need to complete some regression testing before release due to something I noticed within the reconciled source code. I also don't recall fully testing the VDP modifications nor the CFG CRC test that were implemented months ago.

 

Early indications are the XB27 Suite now plays nicely when a RAMdisk is installed. By fixing ROS, earlier versions of MENU and BOOT will also function properly within their respective limitations, including limited (or non-functional) support for the multiple GROM bases. Older versions of MENU and BOOT are still susceptible to the AVPC interrupt issue described elsewhere.

Edited May 3, 2016 by InsaneMultitasker

[TInaut]

I don't think C will work... that only reads the addresses. You need a write in order for the banking to occur.Cool investigation

An exception to the 9900 Format I instructions -- C only has 3 memory cycles. It is a special case, but it would have worked had it simply wrote out the destination operand during the last memory cycle. In fact, even with 1 less memory cycle, the shared microcode may have an incomplete write cycle at C completion.

 

Someone with real 99/4A would have to check.

 

I think you are right, and I am wrong, until someone proves otherwise.

[Tursi]

If it did write back, it would break compares to bank switched memory, which Extended BASIC does successfully. I'm not sure what a partial write would look like, though.

 

Without explicitly looking it up though, C should read the instruction, read the source operand, and read the destination operand -- that's three memory cycles?

[+Lee Stewart]

fbForth 2.0 TMS9900 Assembler code

HEX

ASM: xxx

6002 @() 6002 @() C, attempt to switch to bank 2

SP DECT, reserve stack space

6034 @() *sp MOV, copy 'MYBANK' to the stack

6006 @() CLR, ensure we get back to bank 0

;ASM

which is equivalent to

C @6002,@6002

DECT SP

MOV @6034,*SP

CLR @6006

read C000h, which is the value at 6034h in bank 0, not the 4000h of bank 2. That would appear to confirm @Tursi's assertion.

...lee

[+InsaneMultitasker]

C @6002,@6002

DECT SP

MOV @6034,*SP

CLR @6006

read C000h, which is the value at 6034h in bank 0, not the 4000h of bank 2. That would appear to confirm @Tursi's assertion.

...lee

 

 

Thanks for the insight into the inverted cartridges, Lee.

 

A general question for those who know the cartridges:

 

Is there an expectation that the bank mapped via a write to >6000 contains a proper header?

 

Or in other words, should I be concerned about my implemented ROS fix ?

[+Lee Stewart]

Thanks for the insight into the inverted cartridges, Lee.

 

You are most welcome.

 

A general question for those who know the cartridges:

 

Is there an expectation that the bank mapped via a write to >6000 contains a proper header?

 

Or in other words, should I be concerned about my implemented ROS fix ?

 

I would say, “yes”, because we've all been warned by the hardware guys that, at the very least, power-up can be expected (most of the time) to land in the first or last bank and a write to >6000 will be the last bank for inverted cartridges (379) and the first bank for normal ones.

 

...lee

[Tursi]

Thanks for the insight into the inverted cartridges, Lee.

 

A general question for those who know the cartridges:

 

Is there an expectation that the bank mapped via a write to >6000 contains a proper header?

 

Or in other words, should I be concerned about my implemented ROS fix ?

Your fix is probably a good idea anyway, but cartridge makers are warned that the startup bank shouldn't be considered guaranteed (unless something external guarantees it like Marc's circuit or a GROM powerup). That said, the practice is that on nearly all boards either the first bank or the last bank is selected (meaning the latch powers up with all zero bits or all one bits). That means that just offhand you can't predict whether it's the bank selected by >6000 or the last bank on the EPROM (address depends on size) that the author expected to be the powerup bank.

 

All bets are off after a reset anyway. I'm still personally a fan of "header in every bank", and all that goes away.

[TInaut]

If it did write back, it would break compares to bank switched memory, which Extended BASIC does successfully. I'm not sure what a partial write would look like, though.Without explicitly looking it up though, C should read the instruction, read the source operand, and read the destination operand -- that's three memory cycles?

Yes, that is how I count them. All the Format I instructions have clock cycles C=14, memory cycles M=4, except for instructions C and CB, which have C=14 and M=3. This is according to the data sheet, which is at the ftp site and elsewhere:

 

ftp://ftp.whtech.com/datasheets%20and%20manuals/Datasheets%20-%20TI/9900DataSht.pdf

 

Oh, well. I got carried away and assumed that C(B) would follow the same sequence as the others, because there is no penalty except delay in writing the destination operand unchanged.

 

I think having MOV be C=14 and M=3 would have been my choice to optimize microcode rather than shaving a memory cycle from C(B).

 

In any event, the MOV(B) and SOC(B) can be used when source and destination addresses are the same to preserve the contents when it is RAM or to bank ROM. SOC(B) should have been OR(B), unless I am missing more grey matter. The 9900 has ORI.

Edited May 4, 2016 by TInaut

[+InsaneMultitasker]

Your fix is probably a good idea anyway, but cartridge makers are warned that the startup bank shouldn't be considered guaranteed (unless something external guarantees it like Marc's circuit or a GROM powerup). That said, the practice is that on nearly all boards either the first bank or the last bank is selected (meaning the latch powers up with all zero bits or all one bits). That means that just offhand you can't predict whether it's the bank selected by >6000 or the last bank on the EPROM (address depends on size) that the author expected to be the powerup bank.

 

All bets are off after a reset anyway. I'm still personally a fan of "header in every bank", and all that goes away.

The unpredictability is what stymied me in the first place Now I know better!

 

I would say, “yes”, because we've all been warned by the hardware guys that, at the very least, power-up can be expected (most of the time) to land in the first or last bank and a write to >6000 will be the last bank for inverted cartridges (379) and the first bank for normal ones.

 

...lee

I will assume, at my own demise, that you were answering 'yes' to my first question So for now based on yours and Tursi's most recent responses, the fix is "in".

 

Thanks

[+Lee Stewart]

I will assume, at my own demise, that you were answering 'yes' to my first question

 

Yes, of course!

 

...lee

[+InsaneMultitasker]

Attached is a disk image with two files, ROS834 and CFG834. They are intended to operate together. While it is theoretically acceptable (CFG will allow it) to install different versions of ROS on individual RAMdisks within the system, I recommend using the same version throughout.

 

ROS834 removes most of the remaining 8.14F/8.32 VDP access and tries to safeguard VDP when no disk controller is present.

 

This ROS contains a CRC. CFG834 computes the ROS file's CRC and compares it with the embedded value. If the two match, the load is considered successful. I do not recall if I allow the user to accept a modified or corrupted ROS file. If needed, blanking out the CRC (sector 1, bytes 6-7) will force CFG to skip the CRC test.

 

CFG834 is essentially what was released here in May. I recompiled the source in the event I had made some changes. ROS834 is compiled from the same work disk.

 

While I consider v8.34 stable, I have not properly tested it. I am releasing here for those of you interested in testing and providing feedback, with the understanding this is not a formal release.

 

Edit: Updated ROS834. Size changed from 8188 bytes to 8192 bytes.

ROS834-Release2016-8-30.dsk

Edited August 30, 2016 by InsaneMultitasker