I am looking at building a flash cart for the Casio PV-1000 game console. I have an EEPROM connected with a little bit of code I wrote to show a menu for selecting games. The problem is that once the game is selected I need to put the right bits onto the upper address lines of the EEPROM, and then reset the Z80.

The Z80's reset line doesn't come out on the cartridge port. The upper address bits I can handle with an AVR or some logic, but the Z80 reset line is a problem.

I could maybe run a clip on lead to the Z80. The only other truly janky way of doing it I can think of is to pass power through the cartridge, and literally power cycle the console.

I was wondering if there was any other way of doing it.

I don't know anything about the Casio PV-1000 other than what I've just read on wikipedia, and I'm guessing you have a large EEPROM with all the games inside it, each taking up whatever the usual size of the game might be then you're using the upper address lines as some sort of 'bank switching' to select which cartridge/game appears on the lower address lines .... With your own 'game' (the menu) as the first / default image...

Z80 resets by jumping to Zero - hence the need for a reset of some sorts and you can't just jump to 0 during the bank switch time.

So... How about your menu copies some code into RAM then jumps to that RAM which then does what's needed to select the game/bank then jumps to zero?

-Gordon

Thanks Gordon. Yes, you are correct, it's basically an EEPROM with the games on it, and my menu. Upper address lines switched to select the game.

I forgot to mention that I wrote up my notes on the PV-1000 here: https://notes.world3.net/retro_computin ... -1000.html

The cartridge port pin-out is right at the bottom. It's a shame they didn't use pin A2 for Z80 reset. Maybe they found one ground pin wasn't reliable when the cartridge got dirty or something. They probably never thought that games would want to reset the system, or that they would use mapper chips that didn't reset a hardware reset of the Z80.

It's actually really weird. I traced the PCB out and found that although A2 is GND, and right next to A1 which is also GND, for some reason they two are not joined on the PCB. A2 has a thin trace, which goes to a wire, which goes to the GND ring on the outer edge of the PCB. The whole PCB is weird, being single sided with a lot of wires as well as jumpers. I can only think that they went through a few revisions and kept adding wires instead of adjusting the traces, because it was laid out by hand rather than in CAD.

I like your idea of using RAM to execute the reset. The console has no ROM of its own, power up just starts executing code from address zero once an NEC integrated video/sound/controller/reset management chip releases the Z80 from reset. So it doesn't matter if the contents of RAM is random, as every game assumes that it is in an undefined state anyway.

My plan for controlling the reset lines was to have an AVR microcontroller detect accesses to a special address by monitoring the address lines. The AVR isn't quite fast enough to catch every write cycle, but if I write repeatedly to that address it will pick it up eventually. The Z80 can simply check for some magic number in the cartridge ROM space to detect when the game has been "loaded".

Thanks again, I think your suggestion will work.

I wonder if you could get away with a GAL rather than an ATmega... Only because I use them in my 6502 systems for address decode and latch...

So if your magic address was $Fxxx which seems free according to your memory map, then the GAL needs the top 4 address lines and bottom 4 address lines. If the top 4 are all 1's then it can latch the bottom 4 addresses to 4 output pins controlling the top 4 address bits in the EEPROM (I'm assuming 16 equally spaced images in the EEPROM here.

So write to $Fxx1 to select image 1, $Fxx2 to select image 2, and so on.

Or pick up the bottom 4 data pins, then write 1 to $F000 to select bank 1, 2 for bank 2 and so on.

You might need a control signal or 2 to detect a memory write and activate the latch - I'm a bit out of touch with Z80 bus signalling. (I'm also presuming the IO read/write bits are also missing from the cartridge connector otherwise you could use the in/out instructions?

It does rather depend on programs/games not accidentally accessing those memory locations when they run ...

But it sounds like there is a solution that might not involve hacking into the console itself - then you have a "universal" cartridge for others to use?

Cheers,

-Gordon

I've never used a GAL before but I did look at them briefly. Can you recommend any that are easy to get started with? From memory the one I looked at needed a very old program to configure it and I had trouble setting it up. Some Atmel thing with a special programming language?

For the control signalling I think just reading the game number at the same time as the special address, and setting the upper address lines, and then disabling further changes until next power cycle would be enough. I don't know if any games erroneously access addresses up there.

One reason I wanted to use an AVR is to give the ability to load code into RAM for development. I'm not sure how good the available emulators are. There is a Japanese one that plays all known games, but some registers of the NEC chip are not fully understood. In fact we only know of the ones that games use, although the way they initialize them after reset suggests that there aren't any more hidden ones. The way that chip interrupts the Z80 isn't fully understood either.

Anyway, the RAM idea has the same issue, no way to issue a reset. There is an interrupt pin on the cartridge port, but that would mean you can't use the NEC chip's interrupts in your code. Maybe dual port RAM with a special debug address that can be used to communicate between the AVR and Z80.

It does seem like the top couple of address lines are unused. There are 16 address lines on the port so if you had a suitable mapper to avoid conflicting with the character RAM (which is actually built into the NEC chip so can't be remapped) you could probably put more ROM, or maybe some extra RAM in that space. Even a co-processor.

Wait... I could put a dual port RAM chip in that space and use it to communicate between the Z80 and AVR. It only needs to be small.

The plan was just to make a design for my own use. Those machines are pretty rare and the design would be open source. I suppose using an EEPROM and GAL would keep the costs down, and I don't know if I really want to do much development on it. I had an idea to write a game or tech demo on what is a very obscure and unloved machine. It came out a few months after the Famicom and was extremely weak in comparison (no sprites, no scrolling, only 32 RAM mapped tiles, and one channel square wave sound) and was apparently on sale for less than a year before Casio canned it. It looks like it must have cost a lot to manufacture, given how many wires it uses and how big the PCB is. But then again, the ZX Spectrum isn't much better, although it does have a lot more RAM, and that did very well.

I think I'd stick with the ATmega idea in the first instance if you're not familiar with GALs - yes, they're old technology but the Atmel ones (22v10) are still being made. You can always prototype it with an Arduino too.

As for shared RAM - Dual-port are relatively expensive and of-course many pins needed. You could drive it from the ATmega via a pair of shift-register for the address-lines and another for the data plus read/write signals too. This is sort of how the Cerberus 2080 does it. But you still have the issue of keeping the z80 busy while you load up the RAM - which could just be a loop up in high video RAM, polling for a 'done' value somewhere.

You might end up with more technology implementing the ROM/RAM system than in the original console if you're not careful though!

-Gordon

It's a shame they didn't bring BUSACK to the cartridge port!

Looking at dual port RAM, I see that 7007 (32k x 8) are available on eBay, if not from any suppliers. They aren't cheap but they aren't too expensive for a project like this. They are 5V devices but accept 3.3V logic levels, and for reading data some current limiting resistors are enough. I could use an XMEGA and my own USB stack, and keep all the games in the XMEGA's flash memory. Or an STM32, but I use those at work and don't really like them. They are 5V tolerant though. Plenty of pins, and 4 layer boards are cheap. With an MCU it's no problem to have address and data lines scrambled for ease of layout either.

The only other component needed would be an OR gate to stop games writing to the RAM, i.e. make it a ROM. Z80 to AVR communication could be via some fixed addresses at the top of the "ROM" space.