Cartridge Formats and banking fun and games ?

[andym00]

I was just trying to find an answer to a few questions I've got about how the A8s handles cartridges, and whilst it all looks fairly reasonable and simple to implement a nice simple bank switching method on a cartridge thanks to CCTL, I came across Sheddys post on his blog and his concerns regarding what happens with the various methods when the user presses Reset, and his mention of needing a little bit of code in each bank to support this..

 

So I'm having trouble finding the answer to this and not sure exactly is the issue ? I'm assuming pressing Reset causes a problem ? But what happens ? What ROMs are put back in place, and what vectors are called ? And surely if I've got the ROMs banked out in the top 8K and RAM there I can't see how there's anything that couldn't be trapped and handled by me ?

 

 

 

The only sense I can make of it is that this is purely an issue on the old 800s without RAM in the top of memory under the ROMs and that you can't get control before the system starts processing the reset ? Is the bit of code something that you hide in the ROM space ($8000-$A000,$A000-$C000) that the Reset handling calls into, then you get control ?

 

Just wondering, because it's bugging me now, and I've not got a cartridge that I can test this with on the real thing right now, though one's on it's way courtesy of Jetset And I'm loathe to try it on an emulator, for reasons I'm not entirely sure about myself, just one of those little voice in the head things..

 

And would I be right in assuming that at startup, the $d500 page is zeroed by the system code ? Ensuring that a known bank will be selected on startup ? Or is there some other mechanism at play for that, that ensures a consistent startup state on bank switched carts ?

 

 

edit: Just found this thread which answers some of the questions.. BUt I'm still uncertain of why exactly such handling is needed ? Is it just because the bank select is uncertain at startup, in addition to the the top end not being bankable to RAM on the vanilla 800s, hence it's running the ROM vectors all the time ?

Edited January 6, 2010 by andym00

[Rybags]

I'm fairly sure that page $D5 is never touched by any version of the Atari OS. Banked ROM carts would rely on the IC or banking circuit's power-on default state to ensure the correct banking exists at powerup.

 

The Atari800Win+ Help system has a good description of practically all the banking schemes.

 

The reason most schemes work is that they tend to have a fixed bank that's always mapped to $B000-BFFF or $A000-BFFF, so you don't need to worry about the cartridge flags/vectors being different.

Of course they also often have the option to switch the ROM out there too - I'm not sure how they'd cope if the user presses Reset in that case.

 

In the case of Atarimax or carts that can reveal the RAM underneath, the obvious solution would be to just steal CASINI (2,3) and set bit 0 of BOOTFLAG ( 8 ), then have some code there to ensure the cartridge gets swapped in and your desired banking setup is there. In fact, the best idea might well be to just take control at that stage, swap the cart in and run it.

Edited January 6, 2010 by Rybags

[Rybags]

Just saw the other thread... yes, another consideration of the condition where "wrong" bank is at $A000-BFFF is that the cartridge flags/run addresses might be invalid.

 

The critical thing is to either have valid addresses on all banks (not always feasible) or ensure that $BFFC is non-zero on banks you don't want inadvertantly running - then of course you need your backup means of getting system control.

[andym00]

I'm fairly sure that page $D5 is never touched by any version of the Atari OS. Banked ROM carts would rely on the IC or banking circuit's power-on default state to ensure the correct banking exists at powerup.

 

The Atari800Win+ Help system has a good description of practically all the banking schemes.

 

The reason most schemes work is that they tend to have a fixed bank that's always mapped to $B000-BFFF or $A000-BFFF, so you don't need to worry about the cartridge flags/vectors being different.

Of course they also often have the option to switch the ROM out there too - I'm not sure how they'd cope if the user presses Reset in that case.

 

In the case of Atarimax or carts that can reveal the RAM underneath, the obvious solution would be to just steal CASINI (2,3) and set bit 0 of BOOTFLAG ( 8 ), then have some code there to ensure the cartridge gets swapped in and your desired banking setup is there. In fact, the best idea might well be to just take control at that stage, swap the cart in and run it.

 

Right that's made it a bit clearer now.. Thanks

 

Not mad about the idea of a fixed bank gobbling up valuable address space all the time especially if it can't be modified.. Perfect world would be no constant footprint at all, without the need to have the vectors spattered throughout the ROM banks.. But that's not happening I guess..

 

That stuff in AtariWin800++ looks like what I was searching for earlier, but since I've kind of stopped using that now and the only use Altirra, so I didn't think to look it's help stuff.. Next port of call was going to be the Altirra source code..

 

I was hoping there'd be a one fits all solution to this, but I guess there's more to it than appears, unless it really would be best and simplest to keep one bank fixed which would make life nice and simple anyway.. Hmmm..

 

I guess I'll just have to experiment and see which suits me more, the constant stuff in every bank, or one common bank paged in all the time..

 

Actually, writing that down, and I think I've already decided the answer to that in my head, and probably would go with having vectors in every bank, if only for simplicity, losing a tiny constant amount from each bank wouldn't be the end of the world for a nice simple solution that would be fairly bullet-proof and doesn't make life complicated.. Still need to run this all on a real machine and see what's what..

 

I don't suppose there's any off the shelf PCBs or carts available for the A8 that can take ~128/256KB eproms and have bankswitching on them ? Or am I getting my soldering iron out for that one ?

[Rybags]

Unsure - there's that new one (forgotten it's name) I think from GR8 software that allows flashmem hi-score saves and stuff and I think will have EPROM as well as RAM.

 

Some people pull apart existing carts and just replace EPROMs. Although I think some of the later carts might have the bank-select logic onboard the same IC as the ROM, which would kill the idea of using those.

 

The way I see it, the best schemes are the ones with a fixed bank so you don't need to worry about dud vectors/flags cropping up, ie constant bank at A000-BFFF or B000-BFFF, with changable bank taking 8000-9FFF or A000-AFFF.

 

The Atarimax way I think might be a necessary evil - IIRC you have to flash the thing in blocks of 8 or 16K, therefore they have to use a big bank size.

 

I'm no electronics expert but you'd assume a simple 4-bit latch could suffice to provide a simple banking system. Should have a powerup state of %1111 which could give you a guaranteed startup config, and give you 16 banks to play with.

[andym00]

Unsure - there's that new one (forgotten it's name) I think from GR8 software that allows flashmem hi-score saves and stuff and I think will have EPROM as well as RAM.

 

Some people pull apart existing carts and just replace EPROMs. Although I think some of the later carts might have the bank-select logic onboard the same IC as the ROM, which would kill the idea of using those.

 

The way I see it, the best schemes are the ones with a fixed bank so you don't need to worry about dud vectors/flags cropping up, ie constant bank at A000-BFFF or B000-BFFF, with changable bank taking 8000-9FFF or A000-AFFF.

 

The Atarimax way I think might be a necessary evil - IIRC you have to flash the thing in blocks of 8 or 16K, therefore they have to use a big bank size.

 

Oh, you mean the Corina Cart ? That one scares me... Too big not to be abused especially with all that RAM optionally available Though the EEPROM is a very attractive proposition and do love permanent high scores on carts..

 

The fixed bank is nice and simple granted, just a question of finding the right code that can sit there all the time and justify the expense from memory map point of view.. But I guess there's plenty that can go in there really..

 

edit: But if I'm right, with all of the ROM bank switching, there's no way I can access the RAM underneath whilst the carts are in ? I mean, not without cartridge specific support to switch the external ROMs out ?

 

I did find some nice simple looking EPROM carts on Ebay from B&C, but they're limited to 64KB, but I might grab one anyway since they'd be nice to have a play with..

 

 

I'm no electronics expert but you'd assume a simple 4-bit latch could suffice to provide a simple banking system. Should have a powerup state of %1111 which could give you a guaranteed startup config, and give you 16 banks to play with.

 

I'm no electrical wizard either, but that's pretty much exactly what I was thinking of doing

Maybe it's time to get the soldering iron out and blow up my first A8

Edited January 6, 2010 by andym00

[Rybags]

You'd need to check the A800Win+ Help... so many variations.

 

I'm fairly sure there's several schemes around that allow completely swapping out the cart.

 

Another consideration is that with tons of ROM, it does make 16K RAM feasible to do games, although it'd be an annoying limitation but expands the market to those who CBF'd upgrading old 400s or base 600XLs.

[andym00]

You'd need to check the A800Win+ Help... so many variations.

 

I'm fairly sure there's several schemes around that allow completely swapping out the cart.

 

Another consideration is that with tons of ROM, it does make 16K RAM feasible to do games, although it'd be an annoying limitation but expands the market to those who CBF'd upgrading old 400s or base 600XLs.

 

 

Whilst I'd like nothing better than to be able to plug it in and play on an original 400, really that'd be fecking awesome since the picture of a lonely 400 in front of a TV is somehow glued into my head from childhood, I'm afraid it's not going to happen with this.. There's no way this is going to work with 16K of RAM much as I would love to have it run on it.. But that's something I'll bear in mind for something else.. It would be cool to be able to still run it on the very minimum specced machines even after 30+ years

[Sheddy]

Be careful when testing in Atari800WinPlus, Andy. I thought I had reset trapped nicely at one point last year, but it didn't work on a real (XL/XE) machine. Altirra behaves correctly now, at least with AtariMax cart format. XL/XE reset gets done by the hardware rather than NMI which may explain some of the emu problems.

 

Used RAM under the cart when I tried using MegaCart format a while back, but that was only through Atari800WinPlus (pre Altirra). I did have some grand plan of trying to use just 48K RAM rather than 64K (XL/XE only), so I hadn't touched the 8K RAM under the AtariMax cart yet. Since that's pretty unlikely to be possible for me, I'll probably be trying to get at the RAM in the not too distant future. I expect(hope) that if the cart is turned off when reset happens on XL/XE the cart will also init and the default cart bank will pop back into mem...

Edited January 10, 2010 by Sheddy

[Wrathchild]

I'm fairly sure there's several schemes around that allow completely swapping out the cart.

I'd also recommend checking out this post and its link to the comparisons.

 

Sometimes I like the switchable XEGS model better as a fixed (but removable) 8K bank at 0xA000 to control things is useful - e.g. it can be used to house the CC65 lib routines and other banks at 0x8000 can be switched in and out as required, e.g. for graphics, music etc. This leaves everything below 0x8000 as RAM for screen lists and data and game variables. The downside is that there is no source for the boards, you need to hack an existing one yourselves. Technically I think some different GAL logic on the exiting AtariMax boards could achieve the same model?

 

Is Altirra supporting Flash writes as both Atari800WinPLus and Atari++ both can?

 

Regards,

Mark

[Shawn Jefferson]

Excuse my ignorance; Why is trapping RESET necessary (especially for a game?) Most users know that pressing RESET is either going to crash the machine or reboot the machine (in a game).

 

What's the sequence when RESET is pressed? It doesn't go through the whole startup process, does it even try to re-init a cart, or does it just jump through CASINI and then DOSINI depending on the BOOTFLAG value? You might get away with just a small routine at $100 that re-enables the proper cart bank and a JMP $A000... ???

[Rybags]

A crashing machine isn't very professional or elegant for cartridge software.

 

Cartridge Init takes place before CAS/DOSINI. Just what the system does with a cartridge is dependant on the flags at $BFFC/D.

 

The other consideration is that changing banks such that $BFxx ROM is different will fool the system into doing a Coldstart as it'll think a cartridge swap has occurred.

[Sheddy]

 

Is Altirra supporting Flash writes as both Atari800WinPLus and Atari++ both can?

 

Regards,

Mark

 

don't think so, there's fairly minimal support of different cart types; looks like phaeron has concentrated on making what's common work first. surprised the atarimax made it in at all at this stage!

[Sheddy]

Excuse my ignorance; Why is trapping RESET necessary (especially for a game?) Most users know that pressing RESET is either going to crash the machine or reboot the machine (in a game).

 

basically what Rybags said.

I agree it's not that important really, but I've not come across (many/any?) A8 cart games that crash when reset is pressed.

[Sheddy]

Be careful when testing in Atari800WinPlus, Andy. I thought I had reset trapped nicely at one point last year, but it didn't work on a real (XL/XE) machine. Altirra behaves correctly now, at least with AtariMax cart format. XL/XE reset gets done by the hardware rather than NMI which may explain some of the emu problems.

 

Used RAM under the cart when I tried using MegaCart format a while back, but that was only through Atari800WinPlus (pre Altirra). I did have some grand plan of trying to use just 48K RAM rather than 64K (XL/XE only), so I hadn't touched the 8K RAM under the AtariMax cart yet. Since that's pretty unlikely to be possible for me, I'll probably be trying to get at the RAM in the not too distant future. I expect(hope) that if the cart is turned off when reset happens on XL/XE the cart will also init and the default cart bank will pop back into mem...

 

[Edit: Sorry this is kind of redundant having re-read the previous posts properly. don't think you can get away without the cart header in every bank unless you don't mind crashing.]

 

I wasn't very clear that it wouldn't be necessary to have code in all the different cart banks:

 

At least for Atarimax, set the diagnotic bit in the cart header (shouldn't that be footer!) for all the non-default banks and point their init addrs to your reset trap in RAM (diagnostic takes control straight away before OS clears RAM). Although Star Raiders gets away with it, you probably don't want the default bank to be a diagnostic, as the OS H/W initialize is different between 400/800 and XL/XE

Edited January 10, 2010 by Sheddy

[andym00]

Be careful when testing in Atari800WinPlus, Andy. I thought I had reset trapped nicely at one point last year, but it didn't work on a real (XL/XE) machine. Altirra behaves correctly now, at least with AtariMax cart format. XL/XE reset gets done by the hardware rather than NMI which may explain some of the emu problems.

 

Used RAM under the cart when I tried using MegaCart format a while back, but that was only through Atari800WinPlus (pre Altirra). I did have some grand plan of trying to use just 48K RAM rather than 64K (XL/XE only), so I hadn't touched the 8K RAM under the AtariMax cart yet. Since that's pretty unlikely to be possible for me, I'll probably be trying to get at the RAM in the not too distant future. I expect(hope) that if the cart is turned off when reset happens on XL/XE the cart will also init and the default cart bank will pop back into mem...

 

I'm hardly using Atari800WinPlus anymore.. Altirra is just a far more 'social' program to work with, and the debugger is just absolutely heaven to work with, even though it appears not quite complete in some ways.. I don't know now if I'm dare going to try for RAM under the cart.. I think if I go with a fixed bank, a switchable bank and a fixed 32K of RAM will have to do I guess, plus it'll still work on older 48K machines which'll be nice, though I'm loathing the idea of having my IRQs being vectored through ROM before I can get my code, but if I want to support the 48K machines I guess that's a price I'm going to have to pay, not that it's a deal-breaker at all, just a tad annoying losing those few cycles..

 

But if the fixed bank is going make life so much easier as it would appear, then that's a simple choice..

 

I've been thinking more and more about what Rybags wrote though.. And I really do like the idea of a one cart fits all game..

Currently 16K is a no go for this, but there's something else that would fit nicely on it, especially with the total rewrite of all the character mode sprites that happened yesterday by accident, for the umpteenth time now..

 

So much so, that I've been giving thought to possibly making that run on the 5200 as well.. Is it even possible to use a cart on a 5200 from an 8bit ? I mean as long as the code supports the different locations of GTIA and POKEY ? And whatever differences there might be.. I've had a quick look-see at DanBs site, and from a cursory glance it would seem that there's not much problem doing so.. From a purely programming point of view, and with a simple cartridge at least..

 

Out of curiosity though, what should the ideal expected behaviour of a cart being on Reset being hit ? I was thinking just let the cart restart ? After all in console land that's what I'd expect it to do.. Is there any reason not to do that ? The only other desirable option would be to maybe ignore it, as best possible anyway..

 

I think some reading of ROM disassemblies is in order to fully understand what's going on with all of these different beasties..

 

I understand the 5200 Reset process since that's nice and simple, and seems exactly how I'd expect it to be.. And now it's clear why making the cart diagnostic would be seemingly the way to go..

 

Are the same banking schemes available on the 5200 ? I mean the fixed bank, plus switchable ? I haven't read much on the 5200 specifics, but I am doing so now..

 

Hell, I guess I should start with, are they even physically compatible really..

edit: Well that last question was swiftly answered with some reading.. Oh well It was a nice idea

Edited January 10, 2010 by andym00

[andym00]

The other consideration is that changing banks such that $BFxx ROM is different will fool the system into doing a Coldstart as it'll think a cartridge swap has occurred.

 

You mean only when reset is hit right ? Not at any other time ?

I mean, there's no system ROM code that I can't shut down, because of how the ROM interrupt and reset vectors work, that keeps checking this for a change is there ?

[Rybags]

The VBlank checks the cartridge status via TRIG2 - changing banks shouldn't affect that. Warmstart though, checks the status and the Checksum of ROM from $BFF0-$C0EF so if your topmost bank is changed it'll cause a coldstart.

 

Just why it checks that range is beyond me - $BF00-BFFF is what it should check (maybe a typo crept into the source).

 

But, typo or not, it makes it easy to have a non-volatile situation for a mult-bank cartridge - just ensure the checksum of $BFF0-BFFF is the same in all your banks (as well as providing valid cart flags/vectors)

[andym00]

The VBlank checks the cartridge status via TRIG2 - changing banks shouldn't affect that. Warmstart though, checks the status and the Checksum of ROM from $BFF0-$C0EF so if your topmost bank is changed it'll cause a coldstart.

 

Just why it checks that range is beyond me - $BF00-BFFF is what it should check (maybe a typo crept into the source).

 

But, typo or not, it makes it easy to have a non-volatile situation for a mult-bank cartridge - just ensure the checksum of $BFF0-BFFF is the same in all your banks (as well as providing valid cart flags/vectors)

 

Right, crystal clear now

[Sheddy]

The VBlank checks the cartridge status via TRIG2 - changing banks shouldn't affect that. Warmstart though, checks the status and the Checksum of ROM from $BFF0-$C0EF so if your topmost bank is changed it'll cause a coldstart.

 

Just why it checks that range is beyond me - $BF00-BFFF is what it should check (maybe a typo crept into the source).

 

But, typo or not, it makes it easy to have a non-volatile situation for a mult-bank cartridge - just ensure the checksum of $BFF0-BFFF is the same in all your banks (as well as providing valid cart flags/vectors)

 

IMHO all that OS checksum and TRIG stuff on XL/XE is a bit of a pain in the butt. Not sure how you avoid it trashing some locations in page 2 and 3 that the OS uses to do it either (GINTLK and ?). Maybe I'm a bit simple minded about it, but using the diagnostic avoids all the faffing about by stopping that check from happening.

[Edit: Although if the cart is just going to completely re-initialize on reset it's not such a big deal I guess. That would be normal expected behaviour for most carts - to just init like power on]

Edited January 10, 2010 by Sheddy

[Rybags]

Yeah, the diag approach has it's definate advantages - as in the OS is effectively gone if you want it that way.

Disadvantage though is you then have all the initialization stuff on your to-do list.

 

But you can get a "half-baked" OS initialization if you want - run as normal cart and use the Init vector as if it was a Run vector. Just don't return control back to the OS.

Not sure if VBlank is runnning at that stage - cart Init is called before E: is opened though.

[Wrathchild]

Warmstart though, checks the status and the Checksum of ROM from $BFF0-$C0EF

Does the OS provide a hook to use before this is done? In the case of a switched-out cart you need to have a little bit of code in RAM to restore the correct bank before this test was done. However, if the OS instead went ahead and did a coldstart your cart code would most likely take you to the same state anyway.

 

If you are looking to avoid some re-initialization due to a soft-reset (e.g. hi-score chart) then I think I've seen this done as setting the cart flags to boot from disk first and in your initialization code to setup the zero-page registers to say a disk load had completed and use something like DOSVEC, DOSINI or CASINI and set BOOT accordingly?

 

Mark

[Rybags]

No RAM-based hook... fairly sure the Checksum is done/checked before cart Init vector (logically it should occur very early in the process).

 

Of course, the Diag vector approach bypasses all this - in the case of Diag mode, you'd just setup your own process of Magic numbers in RAM to distinguish between a warm/coldstart.

[Wrathchild]

I just took a quick look at an old cart I did, a compilation of Codemaster games for the FlashCart. BMX Sim restarts on a warmstart but GP Sim and Red Max don't. Possibly worth a look behind the scenes to find out what's happening (i.e. trace debugging in an emu.)?

 

[Edit] Added image

CM_flash.zip

Edited January 10, 2010 by Wrathchild

[Rybags]

Should be easy to debug. Set a Breakpoint to the part of the OS that checks the Magic Numbers.

 

At that point, manually check the Magic Numbers, COLDST flag ($244) and WARMST (.

 

Setting WARMST to zero before running a cart will usually coldstart it - it is used in conjunction with COLDST by the system.

 

I'm fairly sure the Red Max I have on disk will warmstart properly (I hacked it years ago to take out an object that stopped me finishing a level).

 

If it's the case a piece of software uses the Magic numbers for it's own purposes, or if it uses the cartridge interlock flag or cartridge checksum flag, then you can get unwanted coldstarts.