where to jmp in memory to run cartridge

[Marius]

Hi.

When I have the OSS Mac/65 cartridge installed, I can go pretty to the assembler by typing CAR at the Dos Prompt.

 

Typing run B000 does ALMOST the same except for the fact that it does not show the name and the version of Mac/65

 

Typing run A000 does not do the trick. But... when this cart is not installed RUN A000 goes to basic.

 

So my question is:

 

Where is the INIT address of the cartridge stored? Or is there a fixed init adress to JMP to to run a cart?

 

Thanks

Marius

[Bryan]

This is my cheat sheet for how cartridges work:

 

FYI, here's the 800 OS-B's cartridge startup procedure:

 

 

-First check for Diagnostic Cart:

-This is done in the first few cycles of operation

-To allow a diagnostic cart to take over before a flaky computer

-crashes.

 

Lda $BFFC

 

-If it's zero, then test to see if it's a ROM:

 

Bne - outta here

Inc $BFFC

Lda $BFFC

 

-If it's still zero, then it must be ROM!

 

Bne - outta here

 

-Is this a "Diagnostic" cart (runs before OS initializes)?

 

Lda $BFFD

 

-Bit 7 is the Flag

 

Bpl - outta here

Jmp ($BFFE)

 

-outta here: gets us to this point:

-Cartridge was not Diagnostic, so hardware init has now run

 

-RAM size is verified. Cartridges are only checked if RAM is not

-found in their space.

 

-Assuming RAM was not found in $8000-BFFF

-Locations $9FFC and $BFFC are checked for 0 values.

-If they are found, an Init routine in the cart is run. It is expected to end in an RTS.

 

lda $9FFC

bne - next test

jsr ($9FFE) - (actually a JSR to a IND-JMP)

 

-next test

 

lda $BFFC

bne - DOS test

jsr ($BFFE)

 

-DOS test

-Now DOS is loaded if the cartridge so desires.

 

-$BFFD and $9FFD are OR'ed (only cartridges that passed the above "zero" test are included). Bit 0 means Boot DOS.

 

And #$01

Beq - No boot!

 

-Otherwise, DOS is booted.

-Now, if Cart A is present (passed the "zero" test), it can be run if the RUN flag is set:

-No boot! Jumps to here

 

Lda $BFFD

And #$04

Beq -Try Cart B

Jmp ($BFFA)

 

-Try Cart B

-If Cart B passed the "zero" test, then see if it wants to RUN.

 

Lda $9FFD

And #$04

Beq -All Done

Jmp ($9FFA)

 

- All Done, OS continues...

 

 

Note that with a 16K cart ($8000-BFFF) a 0 value in $9FFC will cause an init routine to be run at $9FFE whether it exists or not! Make sure $9FFC is non-zero in a 16K image.

 

If a cartridge is marked as executable ($9FFC or $BFFC=0) the Init address (xFFE) is always taken. You can point this to an RTS instruction, and then run at (xFFA), or you can simply never return from the Init call, or you can run as a diagnostic cart if you don't need the OS at all.

 

$9FFA/BFFA - Run Address

$9FFC/BFFC - Zero if cart is executable/Nonzero cart is ignored

$9FFD/BFFD - Flags (if bit set) b7=Diagnostic, b2=Run, b0=Boot DOS

$9FFE/BFFE - Init Address/Diagnostic Run Address

 

Diagnostic cartridge is signalled at Cartridge A ($BFFD) only.

[Rybags]

The Mac-65 image I have is RUN @ $B022.

 

There's no requirement for any cartridge to run at $A000, just some languages like AtAsm and Basic do so.

 

Mac-65 can't Init or Run at a low address, the A0-AF bank can be any of 3 in ROM, or might even be swapped out entirely.

[russg]

Hi.

When I have the OSS Mac/65 cartridge installed, I can go pretty to the assembler by typing CAR at the Dos Prompt.

 

Typing run B000 does ALMOST the same except for the fact that it does not show the name and the version of Mac/65

 

Typing run A000 does not do the trick. But... when this cart is not installed RUN A000 goes to basic.

 

So my question is:

 

Where is the INIT address of the cartridge stored? Or is there a fixed init adress to JMP to to run a cart?

 

Thanks

Marius

$BFFA (Low byte) BFFB (Hi byte) is run address. INIT usually points to a RTS.

[Marius]

Thank you all so much for this info!

 

Interesting info indeed! And $b022 works indeed. This address is stored in BFFA and BFFB indeed!! Great!

 

Greetings

Marius

[Mclaneinc]

Me and a mate were writing a multiboot clone in the day, we had it all going, loads of nice sprites ripped from say the EA loader and so forth, looked great (to us), it was fully functional but the one hassle we had was that some games, dumped carts I seem to remember had weird run addresses like 0 iirc, we could load and init everything else but these gave us hassle.

 

Its so long ago I forget half the bits but I'm pretty sure it was dumped deprotected carts that ran happily on Multiboot.

 

Any idea's?

 

Would love to find out what the issue was..

[Rybags]

You don't have to use the Run address in a cart.

 

Plenty of games just take control from Init and don't return.

 

The advantage - you can have a non-diagnostic cart and get control without a disk/tape boot being allowed and the system is almost all initialised for you.

As opposed to diagnostic mode where nothing has been done for you.

[russg]

You don't have to use the Run address in a cart.

 

Plenty of games just take control from Init and don't return.

 

The advantage - you can have a non-diagnostic cart and get control without a disk/tape boot being allowed and the system is almost all initialised for you.

As opposed to diagnostic mode where nothing has been done for you.

There's an option byte at $BFFD, determines boot/no boot, init start/init no start, diagnostic/non-diagnostic.

INIT is at $BFFE, $BFFF, sometimes points to RTS ($60).

[atariksi]

You don't have to use the Run address in a cart.

 

Plenty of games just take control from Init and don't return.

 

The advantage - you can have a non-diagnostic cart and get control without a disk/tape boot being allowed and the system is almost all initialised for you.

As opposed to diagnostic mode where nothing has been done for you.

There's an option byte at $BFFD, determines boot/no boot, init start/init no start, diagnostic/non-diagnostic.

INIT is at $BFFE, $BFFF, sometimes points to RTS ($60).

 

I have seen some cartridge footers with addresses pointing to low areas in memory (maybe Star Wars). I guess either OS must be checking for this and ignoring these or the cart is copying code there, but latter seems impossible given it hasn't taken control yet.

[Rybags]

If the cart doesn't bother returning control from Init $BFFE then it doesn't matter what's in $BFFA.

 

Having some low Run address is perfectly valid - could be used in conjunction with a copy protection algorithm to generate different code depending if ROM or RAM is found up high.

[+Stephen]

I am still amazed just how complex the Atari OS was, ignoring the fact that it was only 10kB! Truly masterful piece of 6502 code (minus the FP routines).

[Bryan]

I am still amazed just how complex the Atari OS was, ignoring the fact that it was only 10kB! Truly masterful piece of 6502 code (minus the FP routines).

I agree. In many ways, it's the little OS that thinks like a big one.

 

Most 8-bit OS's are basically just a collection of handy little routines you can jump to, kinda like a DLL, but provide very little abstraction or environment management.

[Fox-1 / mnx]

where to jmp in memory to run cartridge

 

 

I think it's located about here:

 

 

 

or just take a direct jump to the cart, about here:

 

 

 

:-)

Edited December 31, 2010 by Fox-1 / mnx

[Chilly Willy]

I am still amazed just how complex the Atari OS was, ignoring the fact that it was only 10kB! Truly masterful piece of 6502 code (minus the FP routines).

 

Well, the FP was masterful, too, it just shouldn't have been used for all variables in BASIC.

 

Back in the stone age of hacking, I cut the cart line on the cart port and added a toggle switch to my extra 400. The switch allowed me to toggle the cart line by hand, allowing me to boot the floppy, flip the switch to enable the cart, and use bsave to copy the cart to floppy. It was how I dumped Pitfall II since it used the diagnostic start vector to help prevent dumping the cart.

[Rybags]

Nice HW hack.

 

But... the FP was/is kinda rubbish. It was just built out of a set of publicly available generic and slow routines.

 

It did have one positive - it created a market for FastROMs with better FP routines, which had the flowon effect, if you're going to replace the FP then may as well put an enhanced OS in the package as well.

[kurtm]

Nice HW hack.

 

But... the FP was/is kinda rubbish. It was just built out of a set of publicly available generic and slow routines.

 

It did have one positive - it created a market for FastROMs with better FP routines, which had the flowon effect, if you're going to replace the FP then may as well put an enhanced OS in the package as well.

 

Yeah, the FP stuff is basically shoved into the OS to make the BASIC fit in 8K.

 

The FP routines are clearly a very different pedigree, and not originally considered part of the OS. The OS is well designed and has vectors for routines so that the OS can be revised without breaking everything. The FP routines are where they are, and all FastROMs since then have not only had to implement the faster code, but make sure the entry points are exactly the same...

 

--Kurt