Interesting discovery regarding GORF cartridge

[Gunstar]

At least I think it's interesting, and a new discovery, maybe I'm wrong.

 

Now, for background, Gorf is one of those old 800 cartridges that doesn't want ot work on the XL and XE models. Generally, if you try to load it on XL/XE it gives you a black screen.

 

I've got the APE Warp+ OS and I noticed, and tested on most of the OS's, including Warp, several XL/XE revisions, 1200XL, 800 and compatibles, and it only loads on the 800 and compatible OS's as normal.

Unless...you hold down the SELECT key when powering up the Atari (normally this action would take you into the APE Warp 32-n-1 OS menu), but regardless of OS currently activated, GORF loads and works, instead of going to the APE Warp menu...

Edited March 30, 2012 by Gunstar

[Rybags]

Weird.

 

Maybe the menu OS is based on the 400/800 one and he didn't take out some of the cartridge startup code.

[Wrathchild]

I've looked into the Gorf cart in the past as part of non-XL working game investigations.

 

The cart version is utilizing page 3 for game data and so in the XL/XE operating system there is a 'background' check (IIRC) for detecting whether carts have been removed/inserted by comparing a byte in page 3 with one in hardware registers. Therefore because Gorf is rewriting the value in this address the O/S check will result in the machine going into an infinite loop in the O/S code. So it would make sense that swapping to another OS that doesn't implement this check would let the game run OK (assuming it too doesn't have anything importing in page 3!).

[Gunstar]

I've looked into the Gorf cart in the past as part of non-XL working game investigations.

 

The cart version is utilizing page 3 for game data and so in the XL/XE operating system there is a 'background' check (IIRC) for detecting whether carts have been removed/inserted by comparing a byte in page 3 with one in hardware registers. Therefore because Gorf is rewriting the value in this address the O/S check will result in the machine going into an infinite loop in the O/S code. So it would make sense that swapping to another OS that doesn't implement this check would let the game run OK (assuming it too doesn't have anything importing in page 3!).

 

Regardless of what GORF and some OS's are doing with page 3, I'm not talking about swapping to an OS without the check, I'm talking about running it regardless of what OS is enabled. Please re-read my first post.

Edited March 30, 2012 by Gunstar

[Gunstar]

Weird.

 

Maybe the menu OS is based on the 400/800 one and he didn't take out some of the cartridge startup code.

 

I don't think the menu system to choose an OS is an OS itself, one of the 31 OS's to choose from on the menu is already active until you choose another.

That page 3 stuff has something to do with it, interacting with APE 32-n-1 somehow, Wrathchild just took his eye off the ball going on about OS's that do or don't implement the check since I can get Gorf to work with all the OS's.

[Rybags]

The menu is an OS - albeit probably reduced to bare bones in some regards to fit the menu stuff in. That's why there's only 31 choices.

The flash chip banking is for the entire 16K of the OS.

 

The PIC chip handles the low level stuff, communication for function requests is done serially by sending the info using bit 7 of PortB, ie - the menu or a user program can send commands to the Pic to either return the current setting or to alter it.

 

Also, the Select key is hard-wired so the Pic can read it, and Reset is wired in as well so the Pic can do a reset when a new OS is switched in.

 

The page 3 stuff - the cartridge state is monitored in Stage 2 of the VBlank. In normal instances the machine will lock up if the state changes or you inadvertantly change the flag. But if a program skips the OS VBlank code, then it gets bypassed.

 

There's also PBI relevant stuff on Page 2, which if set wrong can cause problems in the IRQ handler.

Edited March 30, 2012 by Rybags

[Gunstar]

The menu is an OS - albeit probably reduced to bare bones in some regards to fit the menu stuff in. That's why there's only 31 choices.

The flash chip banking is for the entire 16K of the OS.

 

The PIC chip handles the low level stuff, communication for function requests is done serially by sending the info using bit 7 of PortB, ie - the menu or a user program can send commands to the Pic to either return the current setting or to alter it.

 

Also, the Select key is hard-wired so the Pic can read it, and Reset is wired in as well so the Pic can do a reset when a new OS is switched in.

 

The page 3 stuff - the cartridge state is monitored in Stage 2 of the VBlank. In normal instances the machine will lock up if the state changes or you inadvertantly change the flag. But if a program skips the OS VBlank code, then it gets bypassed.

 

There's also PBI relevant stuff on Page 2, which if set wrong can cause problems in the IRQ handler.

 

I'm not questioning anything you said, I don't know, but I figured Remote Control is the 32nd OS, though it's activated by holding option and select together, not by the menu system. I figured it was the 32nd OS becuase you get to it by bypassing the regular OS boot-strapping.

 

And I'm still a bit confused, since the menu OS isn't activated with the GORF cart installed, it's seems to be completely bypassed by Gorf.

Edited March 30, 2012 by Gunstar

[Rybags]

My 32in1 isn't installed ATM, but IIRC you hold Select while powering on to get the menu.

 

So my theory to your situation - you hold Select when powering up. The Pic sees this and selects the "Menu OS". The menu OS sees and runs your cartridge instead of displaying the menu.

 

I think there's a few image files around from people who've dumped out the entire 512K flash chip - the menu OS part could be extracted and should run on an emulator if we really needed to see what's happening.

[Wrathchild]

Regardless of what GORF and some OS's are doing with page 3, I'm not talking about swapping to an OS without the check, I'm talking about running it regardless of what OS is enabled. Please re-read my first post.

Yes, I had read the post, but apologise for failing to conclude that in all likelyhood the currently selected O/S is not being activated due to the Select key overriding.

 

As Rybags' subsequent posts have explained, I'd concur with his theory on the menu-OS. I'm not sure how the choice is 'stored' (PICs can have their own EEPROM) so either the Select key state can be detected during the PIC's own loading and then bypass the stored choice to default to the menu-OS, or the menu-OS could itself could normally read the O/S choice, select and launch it or present the menu if the Select is held.

 

GORF has the 'cartridge option' value '4' and so will initialize and start the cartridge which is standard on most game cartridges so are other titles run the cart or the menu if Select it held?

[Gunstar]

Regardless of what GORF and some OS's are doing with page 3, I'm not talking about swapping to an OS without the check, I'm talking about running it regardless of what OS is enabled. Please re-read my first post.

Yes, I had read the post, but apologise for failing to conclude that in all likelyhood the currently selected O/S is not being activated due to the Select key overriding.

 

As Rybags' subsequent posts have explained, I'd concur with his theory on the menu-OS. I'm not sure how the choice is 'stored' (PICs can have their own EEPROM) so either the Select key state can be detected during the PIC's own loading and then bypass the stored choice to default to the menu-OS, or the menu-OS could itself could normally read the O/S choice, select and launch it or present the menu if the Select is held.

 

GORF has the 'cartridge option' value '4' and so will initialize and start the cartridge which is standard on most game cartridges so are other titles run the cart or the menu if Select it held?

 

My guess would be that other cartridges that normally only work on 400/800 OS and compatibles would work with APE 32-n-1 OS with the select key too. Unfortunately I don't have any of those other cartridges. I lost all my cartridges years ago and just recently started aquiring them again. I currently have 9 cartridges including BASIC.

[Rybags]

I think what Mark's asking is do other cartridges run if you hold Select?

 

The menu OS via Select on powerup should override any cartridge flags - the PIC reads Select by itself. But of course that's not to say the menu OS isn't allowing the cart to run in precedence of showing the menu (maybe the menu is done via DOSVEC ?)

 

Can you try the Basic cart? That'd be interesting, as you'd then be able to see if certain other things work. Try without booting anything from SIO, and see what comes up if you type DOS and BYE.

[Gunstar]

I think what Mark's asking is do other cartridges run if you hold Select?

 

The menu OS via Select on powerup should override any cartridge flags - the PIC reads Select by itself. But of course that's not to say the menu OS isn't allowing the cart to run in precedence of showing the menu (maybe the menu is done via DOSVEC ?)

 

Can you try the Basic cart? That'd be interesting, as you'd then be able to see if certain other things work. Try without booting anything from SIO, and see what comes up if you type DOS and BYE.

 

I tried BASIC, Defender, Star Raiders, Galaxian and Atariwriter all with SELECT held down, and they all went straight to the cartridge, EXCEPT BASIC which went to the OS menu. But then BASIC is built in with the upgrade anyway and reacts the same way.

[Rybags]

32in1 doesn't have Basic included.

 

You could tell which Basic is being selected by exploiting one of the bugs.

 

e.g. if your cart is Rev A then if you type INPUT with no parameter, it should lock up.

[+David_P]

Could GORF be a diagnostic cart - taking control of the system before all of the OS init routines are called? I seem to recall Star Raiders does that; maybe GORF does as well.

[thorfdbg]

I've looked into the Gorf cart in the past as part of non-XL working game investigations.

 

The cart version is utilizing page 3 for game data and so in the XL/XE operating system there is a 'background' check (IIRC) for detecting whether carts have been removed/inserted by comparing a byte in page 3 with one in hardware registers.

 

Indeed the page-3 TRIG-3 shadow is the most common reason why programs written for Os A and Os B do not work on the XLs, there are a couple of others, for reasons exactly as indicated above.Nothing in the Os checks specifically for SELECT, at least not in the regular Atari binaries. Of course, if you have a third party Os switcher installed, all bets are off. It certainly won't work on a regular XL then.Whether the cart indicates itself as "diagnostic cart" has nothing to do with the matter. It just means that the Os transfers control to the cart earlier in the boot process, i.e. it doesn't try to bootstrap the disk or tape, for example. But it doesn't change what the Os is checking, and it neither bypasses the TRIG-3 shadow check which happens in the VBI.

[Gunstar]

32in1 doesn't have Basic included.

 

You could tell which Basic is being selected by exploiting one of the bugs.

 

e.g. if your cart is Rev A then if you type INPUT with no parameter, it should lock up.

 

The 1200XL version of 32in1 comes with a BASIC chip to install in the second socket, so it INDEED DOES have BASIC included. I'm not refering to the 32in1 board, but the KIT. My 1200XL has built-in BASIC Rev. C, so NAH NAH, take your BASIC cart and testing for revisions and shove it! (I already shoved my BASIC cart)

Edited April 1, 2012 by Gunstar

[Gunstar]

I've looked into the Gorf cart in the past as part of non-XL working game investigations.

 

The cart version is utilizing page 3 for game data and so in the XL/XE operating system there is a 'background' check (IIRC) for detecting whether carts have been removed/inserted by comparing a byte in page 3 with one in hardware registers.

 

Indeed the page-3 TRIG-3 shadow is the most common reason why programs written for Os A and Os B do not work on the XLs, there are a couple of others, for reasons exactly as indicated above.Nothing in the Os checks specifically for SELECT, at least not in the regular Atari binaries. Of course, if you have a third party Os switcher installed, all bets are off. It certainly won't work on a regular XL then.Whether the cart indicates itself as "diagnostic cart" has nothing to do with the matter. It just means that the Os transfers control to the cart earlier in the boot process, i.e. it doesn't try to bootstrap the disk or tape, for example. But it doesn't change what the Os is checking, and it neither bypasses the TRIG-3 shadow check which happens in the VBI.

 

to all: I specifically refered too, and have said this has to do with the 32in1 OS. I never said or suggested this would work with any XL/XE.