Casio 4bit SRAM replacement project

[Jeff_Birt]

It all started when I got a Casio PB-100 in very good shape but with a duff 2K SRAM chip. These are odd little beasts made by Hitachi for Casio that sit on the Casio 4bit bus, the same bus that goes to the expansion connector. These are unobtainium of course except for stealing one from another Casio that used the same chips.

I found that a nice guy in Poland had reverse engineered the bus protocol already which made my job much, much easier: http://pisi.com.pl/piotr433/hardware.htm . The PB-700 shown on his webpage is like a PB-100 with two 2K chips on board.

It is rather convenient that the same signals that go to the RAM also go to the expansion connector. This was the reason that I designed a compatible connector which I posted about a few weeks ago. Funny how projects seem to spin off side projects.

I was able to first capture the bus signals with a cheap Saleae Logic8 to have a look for myself. Then I set about trying to find a good microcontroller to use to simulate the SRAM chip. It had to be very low power, have more than 2K of RAM and enough I/O. I found that a PIC 16F18446 seemed like it would work, and there was an inexpensive dev board with built in programmer/debugger.

The choice of the PIC has been a stumbling block. I had not used one before and the architecture is defiantly different. The MPLAB X IDE is also a real PITA, very buggy, very bloated and a constant source of frustration. I have found that the peripherals built into this chip have come in really handy though and they can be switched off when not needed to save power. For example I was able to generate the quadrature clock the Casio bus uses with a combination of TMR+PWM+CWG.

This week figured out how to sync the data and control signals with this hardware generated clock (so same procedure can be used to sync output of PIC to clock generated by Casio.) I started with wanting to generate the clock myself to try and dump the RAM from the Casio as it seemed like good stepping stone. Luckily when in idle mode the Casio stops the clock and tristates the bus for long periods of time. Piotr from the website above had already figured this out and clued me into the idea.

There are two images attached. One is the 'real' output of the PB-100 and one is simulated by the PIC. It was exciting getting this to work this morning. You can see there is about 1.5us lag from the falling edge of CLK2 to the falling edge of /CE and /OP. Each 'bit time' seems to be two complete cycles of CLK1 so I'm guessing that it latches data in on the second falling edge of CLK1, i.e. the middle of the bit time. This short lag of 1.5us will not be an issue if this is the case.

I thought I would post now as sort of a way to keep a log of the project and maybe the ideas, even those that did not work will be of use to others.

   

   

[Jeff_Birt]

A bit more progress on this project. I can now read directly from the RAM via the expansion bus while the computer is in idle mode. The PIC waits until it detects the computer is in idle mode, starts outputting its own quadrature clock, transmits and address to start reading from and reads in 16 nibbles. This morning I added the ability to 'reflect' what was read, with /CE high so the computer's RAM ignores it. This was done to confirm what was being read.

Now to pack/unpack nibbles into bytes and do a full dump/restore of the computer's RAM.

[Jeff_Birt]

I have been able to back up and restore the entire 1K RAM on the PB-100. It takes about 100ms to backup or restore. Ironically it also takes 100ms to debounce the switch I'm using to start the process. Also managed to change one program line from A=5 to A=8 so figuring out the tokenization should not bee too difficult.

Now working on mimicking the RAM in the PB-100 by sniffing the bus and doing the same writes to the RAM in the PIC. This seems like a good stepping stone to syncing reads with the PB-100 clock. I've also captured the start up and reset with the LA so I know how the RAM needs to respond. It is rather simple and PB-100 reads/writes/reads to various address in each of the two RAM chips which can be on the BUS. If it reads back what it writes then it knows the RAM is present.

[Jeff_Birt]

When the Casio PB-100 / Tandy PC-4 starts up it does a Read/Write/Read/Write sequence to various RAM locations trying to find out how much RAM is available. It has one 2K byte (arranged as 4bits by 4K) chip on board and you can add one more as an 'option RAM'. The built in chip is Device 0, the option RAM is Device 1 (DEV1), etc.

With only the on board RAM you can see it ping DEV0, then DEV1. Of course it does not get a proper response from DEV1. I just got the handshaking working for emulating DEV1 and was surprised to see it trying to ping DEV2. It was my understanding it could only handle up to DEV1, i.e. a total of 4K bytes of RAM. The screen shot attached is from a program I wrote to decode the output of my LA.

Interestingly even though it gets the proper response from DEV1 at power on it does not show that is has more RAM. I suspect when the master reset it pressed it determines the amount of RAM present and stores that somewhere. The power on ping test may just be a way to confirm the RAM is still present.

   

[Jeff_Birt]

TRS-80 PC-4 (Casio PB-100): The PIC is successfully pretending to be a 1K RAM module! The code is a total mess but now that it works it can be cleaned up. I think with this PC-4's firmware it might be able to handle more RAM as after finding DEV1 it tries to find DEV2.