Leprechaun Level Editor (now with load!)

[supercat]

Supporting the Supercharger RAM banking and memory writes is all well and good, but I doubt your board would stay simpler (or cheaper) than Chimera after adding in all the extra components necessary to make it host reprogrammable multiload games. Maybe it would work for a fixed single-load game in EPROM, but then you have a cart that can't be used to run all the existing Supercharger games or 2K or 4K BINs.

 

Using an XC9572XL instead of an XC9536XL, but with no other modifications, it should be possible to make the 4A50 cart run all existing Supercharger titles. Simply bank in RAM when needed, and switch in ROM when necessary to load. It would probably be necessary to use 4K or 6K for a bootloader (2K on the bottom; 2K or 4K on the top); the other 120K would be available for tape images.

 

For any new game development, though, "magic writes" seem much more practical than $10xx delayed writes. There are a few cases where the SuperCharger-style writes work out well (e.g. to decrement a location but stop at zero):

 ldx value
 nop $10FF,x
 nop value

Nine bytes of code, taking 12 cycles if it doesn't decrement or 13 if it does. The "magic writes" version:

 lda value
 beq nope
 dec value

takes 12 cycles if it decrements, or 7-8 if it doesn't; even in that case, therefore, the "magic writes" are a winner.

 

Because 4A50 can run code very nicely out of RAM, there is no major problem with setting up multi-load-style carts. The biggest weakness of 4A50 in that regard is the fixed bank at $1F00. Other banking schemes using the same hardware would not be bound by that limitation.

[mos6507]

Using an XC9572XL instead of an XC9536XL, but with no other modifications, it should be possible to make the 4A50 cart run all existing Supercharger titles. Simply bank in RAM when needed, and switch in ROM when necessary to load. It would probably be necessary to use 4K or 6K for a bootloader (2K on the bottom; 2K or 4K on the top); the other 120K would be available for tape images.

 

If you like the idea of Supercharger games on cart so much, it might be more productive if you lent some tech support to our project instead of even considering how to reinvent the wheel. For instance, I could really use a Dark Mage style text kernel with no gaps between the sprites, and I know you can do that kind of stuff in your sleep.

Edited October 4, 2006 by mos6507

[SeaGtGruff]

I could really use a Dark Mage style text kernel with no gaps between the sprites

This may be a dumb question, but when you say "no gaps," do you mean horizontally or vertically?

 

MR

[mos6507]

Chimera already allows you to get rid of the gaps between rows of text.

 

The fonts in Dark Mage/Stellar Track, etc... are limited to 7-bits wide. If we could get rid of this limitation than I could use the full unaltered Atari 8-bit home computer font in Chimera, as well as using the entire screen as a bitmap drawing surface.

[supercat]

If you like the idea of Supercharger games on cart so much, it might be more productive if you lent some tech support to our project instead of even considering how to reinvent the wheel. For instance, I could really use a Dark Mage style text kernel with no gaps between the sprites, and I know you can do that kind of stuff in your sleep.

 

Not quite in my sleep, but adapting the David Crane text kernel design to eliminate the gaps is pretty straightforward. Just time things so that the left-moving HMOVE occurs at cycle 74, use an HMPx value of $00 instead of $70, and eliminate all the shift instructions. You'll have to move some code around to make things happen at the desired cycles, but it's a good and simple learning project. One recommendation I have is to start out with character shapes where each character is solid $FF except for one line where it's $00 (and that line is at a different spot for each character). Use the Z26 trace (or Stella's would probably work) to ensure you've got the proper total number of cycles per scan line) and a quick glance at the screen will reveal whether the GRPx stores are happening at the right time, too early, or too late.

 

To eliminate vertical gaps, you should use a different copy of the code for each line of text. Since zero-page RAM for pointers is in short supply, use abs,Y mode instead of (ind),Y. In Ruby Runner, the code associated with each text line is given a full page to facilitate addressing and ensure that no branches unexpectedly cross page boundaries. Because going from one text-line's code to the next takes a few more cycles than simply looping within a text line, each text line's code ends with something like the following (from memory)

 dey
 bpl line{0}loop
 ldy #7
 lda #firstbyteofdata
 lda #secondbyteofdata
 jmp line{1}midloop

In the branching case, the branch takes 3 cycles and is followed by two four-cycle loads (total 11 cycles). In the non-branching case, the non-branch takes two cycles, the next three instructions take six, and the jmp takes 3 to go to the spot following the two four-cycle loads. The immediate load instructions are patched with the correct data at the end of vblank, just before entering the first of the loops.

 

The Ruby-Runner kernel approach would be somewhat workable on the SuperCharger, but the $10xx memory hole would be something of a nuisance. Further, the kernel uses 2K for the expanded-out code and 2K for the character set. A SuperCharger would have little room left for the map and game.