A8 XL/XE Switchable MegaCarts and Reset Trapping

[Sheddy]

Bit of an unusual scenario I know, but I'm having trouble trapping the reset key when a megacart is switched off to use the ram under it. No problem when a rom bank is switched in of course, it starts by running from the address in $bffe of the rom

 

The normal trick of disk games of putting a 0 (disable reboot) into COLST($244), and the address of the routine you want to run when reset is pressed into $0c and $0d, doesn't seem to work when the megacart is in but switched off- COLDST is being ignored and a reboot is always done.

 

So, is this the correct way of doing things when there is a switchable cart in? Anyone know any games that use switchable megacart that maybe I can peek at? Or do I need to move to another cart format like XEGS that always leaves some ROM mapped in? (Hate to lose the ram though!)

 

I haven't been able to test on a real machine, but am using AtariWinPLus 4.0 beta3

 

 

any insights appreciated

[Bryan]

The 1st thing the OS will do when it's reset is determine if location BFFC is ROM or RAM by testing for a '0' then incrementing the location and testing for '0' again (I believe the XL OS also tests the state of the unused TRIG3 input, which is connected to one of the RAM disable lines of the cartridge).

 

If the OS decides there's no cartridge inserted, then you have a problem, because it will reboot as a RAM-based system. I don't know how to overcome this. If you disable the OS to trap the RESET vector yourself, it will simply be re-enabled when the RESET line is asserted to the PIA.

 

I'm not sure what the first opportunity is to re-direct the CPU during warm-start. I'll have to look that up. Are you leaving the OS's page zero space intact?

 

-Bry

[Bryan]

It appears at first glance that you can take over after a warmstart if you flag either a successful tape or disk load, and fill in the vector CASINI or DOSINI.

 

-Bry

[Sheddy]

thanks Bry, I tried messing with those vectors too, but no joy. I had a quick look at what the OS does, but I don't have a good handle on it at all! I thought it might be something to do with the zero page also, so I put together something simple to try and figure things out. Anything obvious wrong anyone can spot?

This just puts some colours into the background. It gets copied from the cart to ram when it starts up. the code is then run from ram. the code disables the cart, attempts to set the reset vector to itself, and then just does some background colour changing. On reset it should go back to

running itself again.

 

00:80  A2 00    	ldx #0

02:80  BD 0E 80  lda trap_reset+$4000,x

05:80  9D 00 40  sta $4000,x

08:80  CA        dex

09:80  D0 F7    	bne ?1

0B:80  4C 00 40  jmp $4000

0E:80  A9 80    	lda #128

10:80  8D 00 D5  sta $d500

13:80  A9 0E    	lda #<trap_reset

15:80  85 0C    	sta $0c

17:80  85 0A    	sta $0a

19:80  85 02    	sta $02

1B:80  A9 40    	lda #>trap_reset

1D:80  85 0D    	sta $0d

1F:80  85 0B    	sta $0b

21:80  85 03    	sta $03

23:80  A9 00    	lda #0

25:80  8D 44 02  sta $244

28:80  A9 01    	lda #1

2A:80  85 09    	sta $9

2C:80  AD 0A D2  lda 53770

2F:80  8D 1A D0  sta 53274

32:80  4C 2C 40  jmp loop



FA:BF  00  	.byte <setup

FB:BF  40  	.byte >setup

FC:BF  00  	.byte 0

FD:BF  00  	.byte 0

FE:BF  00  	.byte <setup

FF:BF  40  	.byte >setup



Equates:





Symbol table:

LOOP: 402c  SETUP: 4000  TRAP_RESET: 400e

[Sheddy]

Oh dear... it's not a very good test program. the init address is not even pointing into the cart. I don't know why it even does anything...

[Sheddy]

Did finally get it working, for anyone trying this in future - this also applies to any switchable cart, not just megacart:

 

the normal reset trap can work, but GINTLK ($03fa) must also be correct.

 

on the XL/XE as Bry said, TRIG3 is used to indicate the presence of a cart (0 for no cart, 1 for a cart) the value is copied into GINTLK on coldstart.

 

this gets tested on warmstart (pressing reset). If it doesn't match the value in TRIG3 the system will coldstart - avoiding any reset trapping put in. Switching the cart off is equivalent to removing the cart, so when the RAM under a cart is being used GINTLK should be set to 0 for any warmstart reset trapping to work.

 

Another thing that threw me up was using the $0200-$03ff area of memory for my own code and variables. During a warmstart the OS won't re-initialize itself properly if (at least some of) those locations are changed, and that will cause a coldstart to be performed.

 

NB doing a google search on GINTLK brings up more info

[Wrathchild]

Nice to know! My Flash Carts just arrived and so I'll be getting into programming them soon!

 

Regards,

Mark

[Sheddy]

Nice to know! My Flash Carts just arrived and so I'll be getting into programming them soon!  

 

Regards,

Mark

 

Cool. I still haven't got round to using mine yet, so let us know how you get on!