Game assist cartridge [idea]

[Ramtop]

I've been toying with the idea of a cartridge for the Elk/Plus1 (and possibly Master, too) aimed at making it possible to write more impressive games, something like console cartridges from back in the day that contained extra hardware (Nintendo SuperFX, for example).

My back-of-an-envelope feature list is:

- 16K of sideways RAM
- 512K of indirect RAM accessible via a window in a sideways bank
- a couple of FPGA implemented SN76489 sound chips
- some 8-bit PCM channels, using DMA to the windowed RAM
- high precision programmable timers
- barrel shifter
- a fast co-processor of some kind, running from windowed RAM rather than via the tube. RISC-V possibly, for licensing reasons.

But I'm not a game programmer by any stretch of the imagination, so my question is does this sound like something useful or a giant white elephant? Bear in mind there's no way to affect the Elk's graphics using a cartridge, so that's not an option.

Suggestions appreciated!

[!FOZ!]

An interesting idea for sure. I think I am correct in saying that code in ROMs runs at 2mhz in the Elk, does this mean that graphics routines in the ROM in such a cart would run faster than those in the game code? Or does needing to access the screen memory slow things down regardless? Perhaps still I do wonder if such graphics routines would be useful separate from the game code since affordances for unrolled loops or other optimization that would otherwise bloat the game code could be made in the ROM code?

[arg]

An interesting idea for sure. I think I am correct in saying that code in ROMs runs at 2mhz in the Elk, does this mean that graphics routines in the ROM in such a cart would run faster than those in the game code?

Until they touch RAM, yes (and likewise for executing from sideways RAM). So in modes 4-6, a uniform small penalty for RAM accesses but still a consistent speed-up. In Modes 0-3 (and surely half the point of providing this card with extra RAM is to allow the higher res modes?), the penalty for accessing RAM at the wrong time is extreme. For actual accesses to screen RAM updating display, this can probably be managed by timing such accesses carefully, and program variables etc can be stashed in the sideways RAM (assuming the cartridge has things banked such that you can see a bit of ROM and a bit of sideways RAM at the same time, or you copy the code to RAM for operation). However, I don't see any solution to zero page and stack. You could maybe avoid using the stack, just requiring convoluted code, but avoiding zero page is probably such a big penalty in itself that it wipes out most of the gain.

[paulb]

However, I don't see any solution to zero page and stack. You could maybe avoid using the stack, just requiring convoluted code, but avoiding zero page is probably such a big penalty in itself that it wipes out most of the gain.

Obviously, techniques like the Turbo board handled the zero-page problem but that was an invasive solution, requiring the introduction of something similar to cache memory between the CPU and ULA. I have briefly considered solutions where some replacement RAM could be fitted, providing two switchable banks of memory where one could be readable by the ULA for screen memory, with the ULA tricked into letting the CPU write through to the other bank in upper memory, but this would be another invasive modification and perhaps not even feasible, either.

I think that for an expansion bus or, specifically, a cartridge solution, a second processor approach seems the most viable: a program running on the host CPU works as fast as it can to write to the dynamic RAM, and a second processor prepares data for the screen in some other memory, perhaps something appearing as sideways RAM to the host CPU or a region of I/O memory.

[Ramtop]

I think that for an expansion bus or, specifically, a cartridge solution, a second processor approach seems the most viable: a program running on the host CPU works as fast as it can to write to the dynamic RAM, and a second processor prepares data for the screen in some other memory, perhaps something appearing as sideways RAM to the host CPU or a region of I/O memory.

Yes, this is not far off the core idea behind the cartridge.

At power up the cart would appear as providing a pair of standard 16K sideways RAM banks. A game could use these as normal, via the paging register at &FE05. The SN76489s would appear in &FC or &FD I/O space, so using them should be fairly straightforward. I'm very keen the cartridge can provide some benefits even if a programmer isn't willing to invest much time into making use of it.

One of the sideways banks would act as a window into the 512K (what I call shared RAM). A paging register would permit the window to be moved, so writing 0 to the register means the sideways bank points to the first 16K of shared RAM, write 1 and it points to the second 16K, etc. Effectively giving 32 'virtual' banks.

The 8-bit audio hardware and co-pro would operate via the virtual banks; so, load a sound sample into shared RAM by way of a virtual bank and the audio hardware can play it back using DMA with no further involvement from the 6502. Similarly, a bitmap could be loaded to shared RAM so the co-pro can manipulate it, and the 6502 only has to copy the modified data from swram to screen memory.

It would be possible to run almost the whole game on the co-pro if necessary, just having some 6502 code to draw the screen and handle keyboard input. Not sure how authentic that would be, but it's an option.

[tricky]

It sounds a bit like a pi copro + pi 1mhz. I don't know the elk, but these things sound more useful there.
The pi 1mhz could have sample playback added to go with the music x000 and Sid chip and already has baked memory, but at 1mhz although the master already has four banks of swram + true doubles buffed video ram, well the usual 20k anyway.
The audience is relatively small for acorn games, so add-ons really need to provide something generally useful which you cover with the 32 swram.
There is the blitter project, which would be amazing for games but has too little adoption.
I think that robc's video nula is probably the most successful add on as far as game adoption goes as it can be used on existing games and is simple to add to new ones without making them nula only.
But if you fancy making some, I'm sure someone would love one and if you enjoy thinking about it or making them, go for it

[davidb]

paulb and I have discussed what kinds of expansions would be desirable for the Electron while still being authentic. With co-processors, there's always the danger that you end up writing games/applications for the co-processor and the Electron just becomes a bit pipe, and the Beeb is better suited for that task with its video system.

If I think about features that would make it more convenient for games writers and provide general enhancements, I think first about having better sound output. Unlike a separate video output, this could replace the existing sound system without making it seem like duplication of features.

Sideways RAM would be useful, but perhaps access to SD/microSD storage devices is more useful than indirect, banked RAM, unless it is non-volatile.

The timers would be very useful for video/palette effects.

One feature that DaveH added to the MGC2 was a port for shift register-based game controllers, like those from the NES, I think. It would be good to provide a very simple way to read the buttons because it then becomes a lot easier to write software to map them to keys.

[daveejhitchins]

Don't forget - you also have ROM 13 available in the Cartridge

Dave H.

[Ramtop]

It sounds a bit like a pi copro + pi 1mhz. I don't know the elk, but these things sound more useful there.

The issue with a Pi is the tube interface, it wasn't designed with games in mind. A 1MHz bus with only an 8 byte address space is necessary quite slow at transferring data. 3D games can work, Elite and Battlezone for example, but that's about it. The beauty of using sideways RAM for access is the speed, 2MHz with 16K of address space. On the Elk this means the 6502 can access the co-pro's memory at least twice as fast as the motherboard RAM.

I do agree completely about a small audience for Acorn games, so the cart needs to be easy to program for and at least somewhat useful even if nobody ever writes any code for it. And I'm keen on having low barriers to adoption; the VideoNuLA and Dominic's blitter board are very impressive designs, but as soon as you require people to open the case and start installing things into chip sockets the potential market plummets. Doubly so on the Elk because the CPU is soldered down.

Sideways RAM would be useful, but perhaps access to SD/microSD storage devices is more useful than indirect, banked RAM, unless it is non-volatile.

The timers would be very useful for video/palette effects.

One feature that DaveH added to the MGC2 was a port for shift register-based game controllers, like those from the NES, I think. It would be good to provide a very simple way to read the buttons because it then becomes a lot easier to write software to map them to keys.

An SD card interface would be beneficial, but there's quite a few issues there. It would cause problems with the Plus 1 Mini's built-in SD interface for a start, which would be quite embarrassing!

It would be a good selling point for original Plus 1 owners, but it may not be possible to cram even a microSD socket and the required ROM into the cartridge. I have a sinking feeling just the feature set in my first post will be tight enough to need a 6-layer PCB, with the associated expense. Likewise for a controller port the logic would be trivial to implement but very tough to squeeze in the physical socket. Some kind of breakout box may be the answer to both of these.

Dave, I did consider bank 13. But obviously if someone already has a cartridge that uses bank 13 the whole shebang comes tumbling down, so that's a snag. I guess the viability of this depends on how many cartridges use bank 13, you'll know that better than me

[roland]

The Electron Econet interface uses ROM 13 and if I remember correctly the AP5 and AP6 also provide a socket for ROM 13. Please correct me if I am wrong.