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:

• 0x00C0-0x00FF

• 0x0700-0x073F

• 0x3FC0-0x3FFF

• 0x4600-0x463F

• 0x6200-0x623F

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.

Update

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):

C!!

     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.

Update

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:

• ;       Echo Loop
•         lxi     h,signon
•         call    prmsg
• echo:
•         call    const                   ; check if char available
•         cpi     00h                     ; no char available
•         jz      echo                    ; try again
•         call    conin                   ; get char in A
•         mov     c,a                     ; move char to C for conout
• ;       mvi      a,41h                  ; Insert 'A'
•         call    conout                  ; output char in C
•         hlt                                    ; wait for interrupt
•         jmp     echo                    ; repeat

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:

• my CPM 2.2 (32k)
• Z
• my CPM 2.2 (32k)
• 1111222233334444555566667777

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!

SUCCESS!!!!!

Now to update cbios. 

AlanX