• Please review our updated Terms and Rules here

Assemble Kaypro BIOS From Source?

m_thompson

Veteran Member
Joined
Jul 8, 2014
Messages
1,985
Location
Rhode Island, USA
I am debugging a Kaypro-10, trying to find out why it stops running CP/M after a few seconds. I think that it is running the code that checks for a key press, when it fails.

I have the source code for the BIOS EPROM, ROM19EE.MAC. The format of the source code doesn't seem to match the CP/M Macro Assembler, or any other that I have tried.

Does anyone know what tools Kaypro used to assemble their BIOS source code?
 
I've confirmed what ChuckG says, it assembles with M80. Here's the listing file:
 

Attachments

  • ROM19EE.prn.txt
    209.5 KB · Views: 15
Thanks very much for the assembled listing. That will be very helpful.

I expected the addresses to be based at 0xEE00, because I think that is where the EPROM is addressed.
Maybe the EPROM is addressed at 0x0000 at power on and then moves to 0xEE00?
 
I expected the addresses to be based at 0xEE00, because I think that is where the EPROM is addressed.
Maybe the EPROM is addressed at 0x0000 at power on and then moves to 0xEE00?

The Z-80 starts executing at 0000h on reset, so unless the Kaypro has separate hardware to insert a jump I'd assume it must alias at least part of the ROM into low memory at boot-time temporarily.
 
Yes, the Kaypro puts the ROM at 0x0000. Note that there is a bit in the system control register (port) that switches the ROM in and out, and that the BIOS does this to call various routines in the ROM. Console I/O are among those.
 
Thanks for the info on the EPROM. This system was working OK a few weeks ago and we were in the process of debugging the WD disk controller. Now it boots from floppy OK, and you can enter about 30 characters at the CP/M prompt and then it locks up. If you are fast enough you can get a partial directory to list, or get DDT loaded, and then it locks up. I made a new EPROM, and that didn't change anything. The power supply voltages are OK. The video stays on the screen.

My next project is to connect a logic analyzer to the Z-80 and see what it is doing when it locks up.
 
LA on the Z80 is a good idea, if you've got enough channels.

It sounded at first like the lockup was related to the number of characters typed? But then it sounds like it might be strictly elapsed time related? So, it is sounding like basically "N" seconds after RESET the system locks up? I'm still thinking DRAM refresh, and the early K10 (ROM 1.9E) has discrete components for the DRAM (not the custom LSI chip) so you have a better chance of diagnosing and fixing it, if it is refresh.

It looks like this version of the ROM is continually checking for bootable media - although it's possible that whatever is wrong with the HDD results in a hang - so it might be interesting to leave the system "at the ROM prompt" for long enough to reach lockup, then insert the floppy and see if it boots without pressing RESET. Of course, if refresh is the problem you may be able to run out of ROM for an indefinite period of time (depending on RAM access patterns - if the RAM (e.g. stack) is continually being accessed then it won't "fade" even if there is no refresh). But as soon as you alter the code path (e.g. press a key) then you likely access RAM (via RET) that has faded and you crash.

Also, the ROM does have some snippets of code that it copies into high RAM, I think (other versions do, at least), in which case some event may cause that code to be executed after it has faded. Of course, once CP/M is loaded then nearly everything of import is in high RAM, but the console input routine (for example) is in ROM and may be able to survive while spinning (but as soon as you return, you crash).
 
Thanks again for all of the pointers.

Another mystery I haven't solved yet is the source of the PROMCE\ signal that selects the boot EPROM. I see it on pin 18 of U42 on page A of the schematics, and again on page C. Both are input signals. Am I blind, or is it missing from the schematics that I have?
 
The *PROMCE logic is shown drawn off to the right on the Schematic. A15, and BLANK - U11 Pin 12 (Sheet D) are
the signals that select *PROMCE.

Larry
 
Last edited:
I can see BANK (c) on sheet D goes to U 50 Pin 9 on sheet C.
I can see PROMCE\ going into U42 pin 18 on sheet A.
I still don't see where PROMCE\ comes from.
 
It's not easy to see on the scan, but /PROMCE *is* U50 pin 8. That signal goes *to* U50 pin 13, U56 pin 11, and (sheet A) U42 pin 18.
 
Ah, I didn't see the little dot on the schematic.

So, if the address is in the lower 32k, and BANK is active, the boot EPROM will be selected, and RAM inhibited?
 
Ah, I didn't see the little dot on the schematic.

So, if the address is in the lower 32k, and BANK is active, the boot EPROM will be selected, and RAM inhibited?
Yes, and because the ROM is smaller than 32K it will be replicated throughout the 32K space. I don't know whether the circuit supports "write under ROM" or not, have not looked at the circuit in detail.

As you discovered, the ROM uses a section of high RAM for data and buffers. If you look at the CP/M images in detail, you'll see that they don't reside all the way to the top of 64K. In some cases they actually say e.g. "63K CP/M...". I'm not sure what ROM 1.9E is doing at 0xEE00, or whether all of that is reserved when CP/M is running. Different ROMs had different amounts of high RAM reserved.
 
I looked at the signals on pins 11 OE, 12 MREQ-RD, and 13 PROMCE\ of U50. When it first boots there is a lot of activity on all three signals. Then there is a constant pattern of rapidly switching of the PROMCE\ signal just after it displays an error message about a sector read problem. I suspect that this is when CP/M is constantly calling the keyboard I/O routine in the EPROM looking for a character. I hit the return key, and the pattern changed again when the CP/M prompt was diskpayed. After a few seconds the PROMCE\ signal was only active every 2ms, so something is broken.

I need to look at RFSH\, RAS, and CAS to see what they are doing. As suggested earlier it is possible that the RAM refresh is dying, CP/M dissapears, and the CPU is just running trash.
 
Back
Top