Thoughts on memory expansion and MMU etc

[gardners]

Hi Jim,

Nice project. A couple of thoughts and ideas:

1. For the colour RAM, have you thought about having the colour RAM selection automatically change every raster line, so that you have a kind of "hardware FLI"? You only need to use 8 of the 1K pages for this.

2. Much has been said about the upper-nybl of the colour RAM not being physically connected, and the last 24 bytes not being used, and thus might be candidate register locations. The later seems a sensible approach to me, but you will still want some kind of knock, so that routines that just fill all 4 pages of colour RAM don't cause problems. Your four-step knock looks ok, if perhaps a little over-complex, in so far as the number of cycles required will be quite high. Liveable, but just something worth keeping in mind. If you are sniffing the bus, you could instead use one or more of the unintended NOP opcodes to do most of it.

Paul.

[go4retro]

The Color RAM idea sounds cool, I'll consider it.

On the knock, concerning Color RAM, if I work the functionality into the 2114 SRAM replacement, I doubt I'd need the knock all the time. Knock to turn it on, and then just leave it on (I'd assume the dev using the feature would just set the last 24 nybbles to 0, to ensure VSP code would look OK, and then switch the last 24 bytes to registers, and always use them (the design would need a flying lead to PHI0, since it'd need to know which accesses are CPU and which are VIC. Robin Harbron asked that the design offer a way to configue a page of SRAM not currently in use, so the code could use one page for display while setting up a shadow copy for the next frame, wihtout having to wait until the end of the frame to do that. To enable that type of features requires access to PHI0.

As for the main unit, I could use non standard NOPs, though if someones wants to support this MMU design on a 65C02 or 65C816-based upgrade, that would pose problems (existing code would fail on those newer units). Thoughts?

[gardners]

Agreed using the colour RAM 24 spare nybls for registers makes the most sense, I think.

As for the non-standard NOPs, you are right, that this won't be a solution for 65C02 or 65C816 processors, so it should be an optional mode of operation.

Meanwhile, I have an idea for another C64 add-on board, to help discover remaining VIC-II tricks if you are interested. Basically it is a cartridge that pulls DMA low, and interfaces to a host computer allowing the host computer to determine every memory access during each video frame. That is, you can say which registers get written at exactly which cycle of which raster line (and probably even do some horrible tricks with doing multiple accesses per cycle for the chips with async registers). This would allow for rapidly exploring potential VIC-II tricks, without having to make C64 code that actually achieves that. It would be up to the demo coders to then work out code that achieves those memory accesses in practice.

[go4retro]

I am indeed interested. What speed uC/host computer were you considering? I know there's a RPi cart that interfaces that to the bus.

Jim

[gardners]

Hi Jim,

I'd just use a cheap FPGA + USB serial interface. A MAX10 FPGA + JTAG USB serial adapter + level converters and buffers should be sufficient. The FPGA can do the bus control, and has enough internal RAM to hold the info on every required memory access over a whole frame (~17K/21K cycles (NTSC/PAL) x (2 address bytes plus 1 data byte). Power requirements would be low enough to be powered from the C64 expansion port.

Paul.

[gardners]

... It could also double as a multipurpose cartridge emulator.

[go4retro]

To save time, I was looking for a prebuilt module for the FPGA.  THis one is so close, but only has 38 IO: https://www.ebay.com/itm/STEP-MAX10-Intel-Altera-FPGA-development-board-/143318504573?_trksid=p2385738.m4383.l4275.c10

[gardners]

Going for a pre-built FPGA module to fit to a cheap adapter board would make sense, as I don't think the volume for this product would be particularly high. In that case, I would recommend going for a TE0725-03 from Trenz Electronic, who also make the MEGA65 mainboards. I use the TE0725 in the MEGAphone and other projects, and am thus quite familiar with it. It has 104 IO available, which is more than enough. We could copy the level converters etc from the MEGA65 main board schematic, and have a working thing pretty quickly.

Another funny approach would be to make an adapter that connects a MEGA65 to a C64 via the expansion port, and allows the same functions.

[go4retro]

Dunno, that part is both overkill and also not enough for hobbyist use. It requires a JTAG programmer, where the MAX10 board I linked has a built in programmer, so nothing else needed, and it's half the price. With a cheap FR4 PCB with some simple level converters and this board, you're still below $50.00 in costs, whereas the other option is significantly more. I realize it is not a huge demand board, but I think the USB programming and the half price point would allow it to be the basis for many more projects.

I think I'd rather find a way to deal with the 2 missing signals, the price point is much better.

Jim

[gardners]

Understood. So, in terms of signals, you need to be able to write A0-15 and D0-7 = 24 lines. Then you need to be able to tri-state those = +1 signal. Then you probably want to monitor /BA, and be able to pull /DMA low, so +2 signals. That still is only 27 signals. You in fact then have enough for separately tri-stating D0-7 and being able to drive them: +9 signals = 36 signals. I guess you also want /RESET so that it can be used to reset the machine +1 = 37. Then you can monitor either /EXROM or /GAME, but not both, to use up the last pin in your 38-pin budget.

But if you are willing to consider a full custom PCB, you can use a MAX10 and get lots more spare pins.