EricBall's Tech Projects

Glad you're still working on this, Eric.

 

And figuring out all the tricks to developing on the SC for us!

It turned out to be less pain & suffering than I thought. I needed to:

rename the ASM files (so LEPBANK1.ASM contains bank1)

change the ORGs/RORGs in LEPBANK2.ASM to $3000-$37FF

change the SCCTRL updates in the code and in the header (forgot that last one the first time around)

change the INCLUDE order in LEPRCHN.ASM

reorder the page number table (file -> bank layout) in the header

and, finally, change the page counter in the header so bank2 got loaded.

 

Now I've got to debug my 6 digit routine so it works....

 

Part of my annoyance with the SC bankswitching is Starpath used D0 to enable (power) the ROM and D3 to map the ROM. If they had used the same bit for both functions then there would have been enough bits to handle the six RAM+RAM possibilites.

I will agree that having a separate bit to turn the ROM on and off seems like a waste; not sure why Arcadia couldn't have simply powered off the ROM when it wasn't banked in. True, it's necessary to wait between powering it up and using it, but would selecting it into the memory map before it was ready for use cause any problem if it wasn't actually accessed until it was ready?

 

Much bigger annoyances of mine are: (1) the inclusion of the "write delay" value in the same 8-bit latch location; (2) the fact that $1FF8/$1FF9 are always active, even when there hasn't been a recent access to $1000-$10FF; as a consequence of that, neither 2K block can be made available in its entirety anywhere in the memory map.

 

If Arcadia could have predicted that no new 2600 variants would add anything into lower memory space, they could have made things much nicer by putting the RAM-write hotspots at, e.g., $0800-$08FF, the bankswitch-select hotspots at $0400-$040F, and the ROM power/write-delay control at $0410/$041F (if the ROM power weren't handled implicitly by the bank switching).

 

If the write timing were sufficiently accurate (and it should have been possible to make it so given that it's adjustable), and if Atari could have been relied upon not to add a buffer between the cartridge slot and the bus, an even nicer option would have been to make it so that following the hit of the "write" hotspot, the following write operation would use whever was on the data bus. This would have simplified the chip and made the code much nicer.

If the write timing were sufficiently accurate (and it should have been possible to make it so given that it's adjustable), and if Atari could have been relied upon not to add a buffer between the cartridge slot and the bus, an even nicer option would have been to make it so that following the hit of the "write" hotspot, the following write operation would use whever was on the data bus. This would have simplified the chip and made the code much nicer.

I'm not sure how well that would have worked. The trick is there could be a variable amount of time between the write hotspot and the destination depending on the addressing mode used. (i.e. ABS is 4 cycles while (ZP),Y is 5 cycles) You also couldn't use a single hotspot and snoop the databus since you would run into bus contention issues.

 

Yeah, it's disappointing that you don't have either 2K bank fully read/writable. But even Leprechaun only uses 1K for a 1LK background bitmap.

If the write timing were sufficiently accurate (and it should have been possible to make it so given that it's adjustable), and if Atari could have been relied upon not to add a buffer between the cartridge slot and the bus, an even nicer option would have been to make it so that following the hit of the "write" hotspot, the following write operation would use whever was on the data bus. This would have simplified the chip and made the code much nicer.

I'm not sure how well that would have worked. The trick is there could be a variable amount of time between the write hotspot and the destination depending on the addressing mode used. (i.e. ABS is 4 cycles while (ZP),Y is 5 cycles) You also couldn't use a single hotspot and snoop the databus since you would run into bus contention issues.

 

The SuperCharger has to put its data onto the bus and hit /WE, then release /WE, then release the bus, all within one clock cycle; it's pretty much free to do those things at any time within that clock cycle provided that it does them in that order.

 

If it didn't put anything onto the data bus by itself, things would work pretty much as they do now otherwise; the only "gotcha" would be that the /WE line would have to be asserted sometime within the first half of the cycle and released sometime within the second half of the cycle. I'm not sure what bus contention issues there'd be if that were done.

 

Yeah, it's disappointing that you don't have either 2K bank fully read/writable. But even Leprechaun only uses 1K for a 1LK background bitmap.

 

The $1FF8-$1FF9 behavior I just fine annoying. That and the inclusion of the write-delay bits within the same register as the banking bits.

 

Still, the SuperCharger is by far the coolest piece of hardware of the ancient era.