Hardware Build

A project log for My CP/M Single Board Computer

A simple computer based on the CP/M OS and flash chips for disk drives

agp.cooperagp.cooper 10/23/2019 at 14:065 Comments

Assembled the Board

I assembled the board but was short an IC socket for he second Flash ROM. I thought I had a spare USB-Serial converted but no. So I quick trip to the local electronics shop tomorrow.

I have to write code to export the Disk data as two 16kb C arrays for my Nano Flash Programmer. So in theory it could be running tomorrow.

Found that spare FTDI (USB to serial adapter). So I programmed Disk0 and powered up.

No, power is up and clock is running but no response. Checked voltage levels (logic states) on the 8085 controls and they seem okay.

Checked the Flash ROM and there were five illegal writes:

The groups are 64 bytes (not 128 bytes) groups so they were not faulty disk writes.

Perhaps the bootstrap did not work?

I think I will test a basic echo program next.


I used the wrong latch for the low byte address, I used a 74HC374 instead of a 74HC373.

Built a new board with the right chip (I cannot extract soldered in chips without damaging the PCB). Okay, progress, I got this (after changing the "bit timing" from 30 to 32):


     my CPM 2.2 (32k)


where the !! is a shaded graphics box.

"myCPM 2.2 (32k)" is my logon message.

The OS responds to my typing but is not intelligible (mostly graphics boxes).

So I think I need to try the echo program to make sure it is working.


Part of the problem is the the Emulator uses 8080 timing rather than 8085 timing.

Even though I calculated the correct 8085 delays for the Serial IO, I adjusted the timing to match the emulations (I assumed I had made a calculation error). No so! At this point I am tempted to write my own 8085 virtual machine. Yes, I don't really like how the one I am using has been coded.

Anyway, I can get text out of the CPM machine but input is not working.

As it works on the emulator I suspect the interrupt set up on the emulator does not match the hardware (reality?).

Update 2

I inserted a HLT at the end the Echo loop:

What this showed is that the interrupt is unreliable. You can get the letter you typed if you repeat enough times. Basically it is (sometimes) missing the start bit and/or (sometimes) triggering other low bits and/or misses the whole sequence.

This would be a hardware/design problem. My understanding is that the RST6.5 interrupt does not trigger if the interrupts are disabled.

In theory, after the halt, the rst6.5 interrupt which senses the inverted serial in signal, restarts the CPU, executing one loop. In hardware, the start bit triggers the interrupt (RST6.5).

I have used the input design for my TTA8 and it works fine. I have checked  the schematic and the assembled board, and it looks okay. I am puzzled.

Update 3

I found I have swapped the labels of R15 and R16 on the PCB board. This in reality would not have affected the Serial Input except when the Serial Input is floating. The Serial Input signals are clean so it is back to a code or interrupt or both problem.

Terminal behaviour:

Reset displays the logon message - no problems.

Sometimes I get a 'Z' on the next line.

If I press a key it may or may not display. It may back space.

But I will get the pressed character. Its like the interrupt is retriggering?

For example:

After the first reset I got a 'Z' without doing anything else.

After the second reset I kept pressing '1', '2', '3' etc.

Although it shows four of each I pressed it many more times. Either nothing happened or it back-spaced (delete) or it showed the character.

Perhaps the ring buffer is not working? How to test?

Update 4

I checked the access time for the 8085 at 5MHz (10MHz crystal) and it is 150ns. I am using 90ns Flash. I have had problems with Flash access times being more that stated so I tried a 70ns Flash. No change.

I updated the emulator for 8085 timing. Now the delays calculations are correct. The code works perfectly in the emulator. But I wrote the SIM/RIM and RSTX.X interrupts, so not a convincing argument.

I found I had not initiated ring buffer pointers (rget and rput). This could cause problems. The code works correctly now except I have to push each key twice (but sometimes three or more times)! Now this is an improvement but it does still suggest an interrupt problem.

I suppose the thing to check is, is it missing and interrupt ("getchar") or is it not calling "conout"?

Update 5

I checked RST6.5 with a return (bypassing getchar) and it works (as the hacked code should). So the problem is in getchar. But why does it work in EMU but not for real.

Ah, the emulator only checks the keyboard every 52us (260 cycles), it is no asynchronous. And I short cut the code the exit as soon as possible (before the serial in mark). Okay, so if I add a delay to the end of the code it should work!


Now to update cbios. 



agp.cooper wrote 10/28/2019 at 01:44 point

Yes, the next version was to have a timer as well. I wanted a bare minimum to begin with (minimalisation is a thing with me!).

  Are you sure? yes | no

agp.cooper wrote 10/28/2019 at 01:41 point

Doing serial via SID/SOD was rather a bad idea (I thought it would be neat to save a couple of chips). The next version was to have a serial IO chip. The main problem is that the serial IO is not concurrent which is only okay for simple/human terminal use. The problem is that I am close to getting it to work.
Assuming my understanding that rst6.5 signals are ignored and not latched during DI is right then the problem is in hardware. Because the problem is "random", it has to be noise (AC?)  on SID input line. So my last test is to look for noise on the SID line.

  Are you sure? yes | no

Ken Yap wrote 10/27/2019 at 13:44 point

Are you relying on instruction timing for bit-banging the SIO pins? I don't think this is a reliable method.

  Are you sure? yes | no

agp.cooper wrote 10/28/2019 at 01:19 point

Yes, the output is straight forward but interrupts need to be disabled.

The input is triggered by rst6.5. I am having trouble with unreliable triggering.

  Are you sure? yes | no

Ken Yap wrote 10/28/2019 at 01:28 point

If you had a timer with interrupts you could ensure reliable bit widths. Another way might be an I2C or SPI serial adaptor if such things exist thus outsourcing the serial signal.

  Are you sure? yes | no