Jump to content
InsaneMultitasker

Horizon RAMdisk ROS and CFG Development

Recommended Posts

Does anyone use the XB27 cartridge suite (using an uberGrom cartridge) together with a Horizon RAMdisk?

 

When I initialize a Horizon RAMdisk for the first time and reboot, the system locks up before the cartridge option screen appears.

Share this post


Link to post
Share on other sites

Does anyone use the XB27 cartridge suite (using an uberGrom cartridge) together with a Horizon RAMdisk?

 

When I initialize a Horizon RAMdisk for the first time and reboot, the system locks up before the cartridge option screen appears.

 

I have a 1mb HRD in my system and use the XB 2.7 cart. recently I had to reinit my ramdisk and did not see that issue.

Share this post


Link to post
Share on other sites

With the P-CODE-IV.0 <snip> The card is available there, showing her address (but no DSR, as there seems to be none)

No, there's no DSR on the p-code card in the normal way. The reason the p-code card has the last possible expansion card CRU address, 0x1F00, is that this ensures the card is the latest one to start up. Hence all other cards have had a chance to run their power-on reset routines, if they have any, before the p-code card starts running. Once the p-code card runs its power-up routine, it will never return. That's how the p-system takes over and prevents the normal operating system from running.

 

Note the the proper way to write the p-system version is IV.0. They used Roman numerals for versions of the p-code emulator (PME), and arabic for versions of the p-system operating system code.

  • Like 1

Share this post


Link to post
Share on other sites

yes, but TI printed "P-CODE VER 4.0" on the PEB-cards (?)

 

I was amazed that switching the P-CODE-card on <after> the TI has booted was "successfully",

Successfully in that way, that the card is shown by the tool.

 

Maybe there is a diagnostic-software, using this behaviour ?

Share this post


Link to post
Share on other sites

The switch enables the card. Nothing special there.

Since the p-code card only takes command after running through the power-up routine, this doesn't matter. It will not do anything until you power cycle or press FCTN+QUIT.

 

Yes, you're right, TI didn't know the proper naming either!

Edited by apersson850
  • Like 1

Share this post


Link to post
Share on other sites

Does anyone use the XB27 cartridge suite (using an uberGrom cartridge) together with a Horizon RAMdisk?

 

When I initialize a Horizon RAMdisk for the first time and reboot, the system locks up before the cartridge option screen appears.

 

You need to set "Powerup On" to "N" when loading the HRD DSR. You'll still be able to use it as a RAMdisk, but you won't have the HRD boot menu.

Share this post


Link to post
Share on other sites

 

You need to set "Powerup On" to "N" when loading the HRD DSR. You'll still be able to use it as a RAMdisk, but you won't have the HRD boot menu.

Once I load MENU into the Ramdisk, everything is fine. It seems there is a conflict between my XB27 Suite and the DSR. After doing some digging, it appears my XB27 suite is an older iteration Gazoo had sent to me. Looks like I need to update it and re-test.

Share this post


Link to post
Share on other sites

Once I load MENU into the Ramdisk, everything is fine. It seems there is a conflict between my XB27 Suite and the DSR. After doing some digging, it appears my XB27 suite is an older iteration Gazoo had sent to me. Looks like I need to update it and re-test.

 

Hmmm. I didn't try that; it blue-screened after formatting, getting back into CFG via E/A and turning off PowerUp made it go away, and it made sense because both would be fighting over the same powerup DSR (I thought)

 

My XB2.7 is homebuilt, from the latest version Gazoo posted before he passed (061315 according to my fileserver). Was there a newer version?

Share this post


Link to post
Share on other sites

 

Hmmm. I didn't try that; it blue-screened after formatting, getting back into CFG via E/A and turning off PowerUp made it go away, and it made sense because both would be fighting over the same powerup DSR (I thought)

 

My XB2.7 is homebuilt, from the latest version Gazoo posted before he passed (061315 according to my fileserver). Was there a newer version?

Mine is probably one of the first versions he released. I had placed the cartridge in a 'safe place' and only recently found it.

 

I inspected the DSR code this evening. When the DSR fails to find MENU on any of the active ramdisks, it falls through to test for an active cartridge at g>6000. If a cartridge header is found then that cartridge's startup address is tested and if !0, the cartridge is started.

 

The XB27 cartridge uses a powerup to bypass the TI title screen. I suspect the cartridge content is put together in a manner that can not be started immediately by the TI console, and that the grom address/bank must be set up first by the cartridge menu (hence pressing spacebar during reset to see the standard menu with XB27).

 

I can't validate my suspicions until later this week or next week.

Share this post


Link to post
Share on other sites
The XB27 cartridge uses a powerup to bypass the TI title screen. I suspect the cartridge content is put together in a manner that can not be started immediately by the TI console, and that the grom address/bank must be set up first by the cartridge menu (hence pressing spacebar during reset to see the standard menu with XB27).

 

I can't validate my suspicions until later this week or next week.

 

The XB27 cartridge also won't work with the Navarone cartridge expander, as reported elsewhere (and I personally verified). He was undoubtably doing something unholy with the powerup bit.

 

(insert my obligatory statement about "it would be nice if source were available for that part of the XB27, so it could be fixed if possible, but ... " here. I'm not competent in assembly past fixing cartridges to run from different GROM locations and/or disabling unintended bank switching anyway ... )

 

Edit: it turns out after a moment of searching and experimentation that the Navarone problem is an UberGROM and Red-card issue, not XB27-specific, so ignore my second paragraph. The fix there is probably to replace the slider with a dual-pole switch and run that extra pole to the Navarone slot power pin. That'll kill the sucker icon_smile.gif

Edited by ckoba

Share this post


Link to post
Share on other sites

No UberGROM will work with the Navarone cartridge expander -- it's not a software issue, it's hardware. The Widget doesn't properly gate the GROMs, it just turns off the -5V line to the inactive slots. The UberGROM doesn't use -5V so turning that voltage off has no effect, and there are no other GROM-compatible lines gated, so no other way to detect where the switch is. We took a couple of stabs at the detecting the -5V but never came up with a circuit that worked with everything else on the board.

 

The ROM side gates the select line (as you'd expect), if you did the same on the GROM side it'd be fine. But as it is we recommend not plugging UberGROMs into a Widget. At best it will just conflict with the other carts, at worst one of the can be damaged. (My expectation is the former but we've done no testing.)

Share this post


Link to post
Share on other sites

No UberGROM will work with the Navarone cartridge expander -- it's not a software issue, it's hardware. The Widget doesn't properly gate the GROMs, it just turns off the -5V line to the inactive slots. The UberGROM doesn't use -5V so turning that voltage off has no effect, and there are no other GROM-compatible lines gated, so no other way to detect where the switch is. We took a couple of stabs at the detecting the -5V but never came up with a circuit that worked with everything else on the board.

 

The ROM side gates the select line (as you'd expect), if you did the same on the GROM side it'd be fine. But as it is we recommend not plugging UberGROMs into a Widget. At best it will just conflict with the other carts, at worst one of the can be damaged. (My expectation is the former but we've done no testing.)

 

I kinda sorta broke my Navarone while opening it up (brittle plastic), so I took a stab at modifying it to switch properly for the UberGROM.

 

The Navarone switch is a dual-pole slider, and apart from switching -5VDC on the active cartridge, it also pulls !ROMS high on all inactive cartridge slots (and connects the active slot to 34). So it kinda tries to gate the cartridges, but only gates for ROM cartridges -- GROMs are untouched.

 

Long story short, modifying the Navarone to physically switch !GS instead of -5VDC doesn't work. If adding pullup resistors as they did for !ROMS doesn't work, I think you'd have to isolate the slots from !ROMS, VCC, -5VDC, and maybe !GS to get it to do the right thing in all cases. As you've said, it won't work as-is, and with only two poles to work with it doesn't appear to be worth the effort to make it work.

 

(I break things and analyze them so that others don't have to icon_smile.gif )

Edited by ckoba
  • Like 1

Share this post


Link to post
Share on other sites

hmmm.. interesting that pull-ups didn't work. I would have expected them to. The AVR won't reply to GROM read cycles if !GS is high, so it wouldn't be able to override the other GROMs. I would have thought it'd work for real GROMs too, but maybe there is more going on there, and that's why they went with the power line instead in the first place. ;)

Share this post


Link to post
Share on other sites

hmmm.. interesting that pull-ups didn't work. I would have expected them to. The AVR won't reply to GROM read cycles if !GS is high, so it wouldn't be able to override the other GROMs. I would have thought it'd work for real GROMs too, but maybe there is more going on there, and that's why they went with the power line instead in the first place. icon_wink.gif

 

Yeah, I was pretty surprised by that as well. I'll give it another go tomorrow and see if I didn't do something stupid like switch the wrong pin, but I'm pretty sure I got it right, and Navarone was killing -5VDC because !GS wasn't working. I'll let you know what I find.

 

Update: you have to kill the +5VDC line with an UberGROM. The !GS method doesn't work.

Edited by ckoba

Share this post


Link to post
Share on other sites

Mine is probably one of the first versions he released. I had placed the cartridge in a 'safe place' and only recently found it.

 

I inspected the DSR code this evening. When the DSR fails to find MENU on any of the active ramdisks, it falls through to test for an active cartridge at g>6000. If a cartridge header is found then that cartridge's startup address is tested and if !0, the cartridge is started.

 

The XB27 cartridge uses a powerup to bypass the TI title screen. I suspect the cartridge content is put together in a manner that can not be started immediately by the TI console, and that the grom address/bank must be set up first by the cartridge menu (hence pressing spacebar during reset to see the standard menu with XB27).

 

I can't validate my suspicions until later this week or next week.

 

(You all probably know this already, but I didn't see it documented anywhere, so I'll do it here)

 

I got XB27 working with MENU active on my HRD+. The trick is to function-9 out of MENU. This will call the next powerup, which in this case is XB27, so all is well.

 

There is a chicken-and-egg problem with XB27, the HRD, and getting MENU on in the first place. Best way I can see is to turn off the HRD powerup when formatting the RAM disk, resetting and copying MENU onto the RAM disk with XB27's DM2K, then re-running CFG and turning on the powerup.

 

It may be possible to use the "hide" switch instead of flipping the powerup bit twice, but I didn't test it because I don't have one installed at the moment.

Edited by ckoba
  • Like 2

Share this post


Link to post
Share on other sites

(You all probably know this already, but I didn't see it documented anywhere, so I'll do it here)

 

I got XB27 working with MENU active on my HRD+. The trick is to function-9 out of MENU. This will call the next powerup, which in this case is XB27, so all is well.

 

There is a chicken-and-egg problem with XB27, the HRD, and getting MENU on in the first place. Best way I can see is to turn off the HRD powerup when formatting the RAM disk, resetting and copying MENU onto the RAM disk with XB27's DM2K, then re-running CFG and turning on the powerup.

 

It may be possible to use the "hide" switch instead of flipping the powerup bit twice, but I didn't test it because I don't have one installed at the moment.

Thanks for sharing your findings. On closer inspection, I think the power up routine may be forcing the grom base to 9800 instead of using the last base scanned by the console, 980c, the base expected by the xb27 powerup. I will try hardcoding the expected base address to see what happens.

 

Turning off the menu powerup during a ros load (automatically via CFG) might work so long as it doesn't affect an already formatted Ramdisk during a reload. I will look into that as time permits. If I recall correctly there is a basic CALL routine to enable and disable the menu startup. This could be an alternative to reloading CFG to enable the menu.

 

Edit: clarification

Edited by InsaneMultitasker
  • Like 1

Share this post


Link to post
Share on other sites

Thanks for sharing your findings. On closer inspection, I think the power up routine may be forcing the grom base to 9800 instead of using the last base scanned by the console, 980c, the base expected by the xb27 powerup. I will try hardcoding the expected base address to see what happens.

 

Turning off the menu powerup during a ros load might work so long as it doesn't affect an already formatted Ramdisk during a reload. I will look into that as time permits. If I recall correctly there is a basic CALL routine to enable and disable the menu startup. This could be an alternative to reloading CFG to enable the menu.

 

This may be related to something else I was trying this morning. Gazoo's "Extended Basic Fun" compilation doesn't appear to have any powerups, yet MENU will only see "Extended BASIC TML" at the "C" slot. Hitting "G" cycled between console BASIC and TML, not the other two Extended BASIC versions as one would expect. TML could successfully launch by hitting "C".

 

(I have not torn into "Extended Basic Fun" yet to see which bases Gazoo was using, so I'm just floating this as theoretical data)

Edited by ckoba

Share this post


Link to post
Share on other sites

 

This may be related to something else I was trying this morning. Gazoo's "Extended Basic Fun" compilation doesn't appear to have any powerups, yet MENU will only see "Extended BASIC TML" at the "C" slot. Hitting "G" cycled between console BASIC and TML, not the other two Extended BASIC versions as one would expect. TML could successfully launch by hitting "C".

 

(I have not torn into "Extended Basic Fun" yet to see which bases Gazoo was using, so I'm just floating this as theoretical data)

Do you have an F18A or 80 column card in your system? Most MENU and BOOT programs only look at the base 9800 address. The menu program I updated for f18a/v9938 scans the first 16 bases, addresses 0x6000-0xf000, for cartridge headers. I haven't made any changes to the 40 column versions.

Share this post


Link to post
Share on other sites

Do you have an F18A or 80 column card in your system? Most MENU and BOOT programs only look at the base 9800 address. The menu program I updated for f18a/v9938 scans the first 16 bases, addresses 0x6000-0xf000, for cartridge headers. I haven't made any changes to the 40 column versions.

 

I do have an F18A. I was unaware of your MENU program until you mentioned it -- I was using the version that came with ROS 8.14(mumble). I've grabbed it (assuming it was the one at the beginning of the thread entitled "9640 Menu System & TIMXT (Beta Releases) and tested it as MENU/MENV (vice BOOT/BOOU) on the HRD+.

 

Nice piece of work, this, visually much better than stock MENU. "G" still cycles between console BASIC and TML (as does the stock version), so no difference there -- and it could well be an artifact of how Gazoo put the cartridge together. gromcfg resets the console when attempted to load via yload, and the space bar recovery is missing. Attempts to execute XB2.7 via "C" bluescreens.

 

There is a regression between your menu and the ROS menu -- function 9 on yours appears to reset the console, and thus executes itself again. Function 9 on the stock version moves on to the next powerup and XB2.7 (or, rather, its powerup menu) comes up.

 

Just FYI icon_smile.gif

Edited by ckoba

Share this post


Link to post
Share on other sites

Like a few other things on my list, it is likely I haven't posted the latest version. Beta testers confirmed the "G" and "C" (Fctn-6 and Fctn-7) options to work with multi-base cartridges. I'll PM you the files to test.

 

Historically, BOOT and MENU were two different programs. Fctn-9 is operating as I intended, however, I can see where the MENU style F9 would be helpful. I'll give that some thought....

  • Like 1

Share this post


Link to post
Share on other sites

Like a few other things on my list, it is likely I haven't posted the latest version. Beta testers confirmed the "G" and "C" (Fctn-6 and Fctn-7) options to work with multi-base cartridges. I'll PM you the files to test.

 

Historically, BOOT and MENU were two different programs. Fctn-9 is operating as I intended, however, I can see where the MENU style F9 would be helpful. I'll give that some thought....

 

Thanks for that.

 

Please do give the F9 bit fair consideration. Although it's most annoying with XB27, it would be useful for there to be a one-touch way for the system to continue executing powerups, if they exist. This might break Plato, for example.

Share this post


Link to post
Share on other sites

 

Thanks for that.

 

Please do give the F9 bit fair consideration. Although it's most annoying with XB27, it would be useful for there to be a one-touch way for the system to continue executing powerups, if they exist. This might break Plato, for example.

 

Oh, yes, very very incompatible with Plato (the real cartridge, not my UberGROM version -- another reason to use UberGROM instead of dodgy cartridges with fscked-up powerups, folks icon_smile.gif ). Bluescreens on powerup, but the HRD is being accessed so *something* is loading and got stuck.

 

Here's the weird thing: it *continues* to bluescreen even after powering everything off and waiting five minutes. Turning the HRD's "hide" button on, then powering it up and running CFG, brings it back to life. Even though CFG doesn't see the HRD because the '138s are out-of-circuit. Flip the hide switch again and it's alive again. The HRD has no apparent corruption.

 

Have to run CFG. Just flipping the switch and turning everything on does not work.

 

I'm at a loss to explain this behavior. I've been all over the HRD+ schematic, and I'd like to think that I understand it fairly well, but this makes no sense.

Edited by ckoba

Share this post


Link to post
Share on other sites

A little more testing:

 

This version doesn't see the console BASIC GROM, nor does it see ROM cartridges at >6000. And it bluescreens if it doesn't see a GROM, so ...

 

... if there isn't a cartridge plugged in with a GROM at >9800 or >9804, it bluescreens (probably a hang). The cartridges I put together have GROMs at >9808 and above (to avoid the console GROM scanning bug), with Tursi's Multicart program at ROM >6000, and those don't work. Carts built on red boards don't work, either.

 

I tested with a wiped HRD+, and the behavior persisted. I'm not positive, but I think the weird persistence errors I was seeing in my previous post were caused by testing without a proper GROM cart slotted in.

 

This is a corner case, as I'm invoking MENU via the HRD+'s powerup, but I reckon it's worth a public bug report in case someone else tries this. For now I've reverted to the MENU that came with ROS.

Share this post


Link to post
Share on other sites

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....

 

The cartridge scanner operates cyclically, meaning once it scans the final base/address, it loops around to the first base/address. Without BASIC or a cartridge, the search will continue indefinitely. Unintended consequence.

 

... if there isn't a cartridge plugged in with a GROM at >9800 or >9804, it bluescreens (probably a hang). The cartridges I put together have GROMs at >9808 and above (to avoid the console GROM scanning bug), with Tursi's Multicart program at ROM >6000, and those don't work. Carts built on red boards don't work, either.

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

 

thanks

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...