• Please review our updated Terms and Rules here

Homebrew Z80 No. 3

I've got the schematic mostly done. There's a few non-obvious connections to trace out, if you want it more complete. Referring to the schematic and layout:

1) There are some control connections between the PIOs and the 50-pin connector (P3) that I can't make an educated guess about. PIO pins 16, 17, 18, 21 (both units) are connected in some order to the P3 pins 11, 12, 23, 24, 35, 36, 47, 48. If you can trace those out, we can have a complete picture of that connector. Note, pin 1 on the connector is marked by that raised triangle/arrow on the top of the connector housing.

2) P1 (first DIP14 socket of the pair) pin 13 is raising questions. In the photos it looks to me as though it goes to A0, but that doesn't make sense since all other signals are buffered there and BA0 is already on that connector. I'm not sure where it goes, perhaps to one of the logic gates near the CPU.

Thanks
 
I'd love to see some more detailed photos of the keypad PCB. An RS232 input device (if that's what it is) with so few chips seems really interesting
 
I'll get pics and do the tracing durgadas requested hopefully tomorrow. I had a covid shot and am knocked right out for the moment. To get a clear shot of the keypad PCB probably will involve removing the transformer and such.
 
As I was looking over the monitor ROM commands, I'm having trouble associating the command letters with likely commands. I'm wondering, could this system have been built for a non-english speaking user? That would certainly explain why I'm not seeing logic in the commands. I see 'G' for what would (in english) be the "Go" command, and 'R' for dumping a register, but the other letters 'V', 'I', 'T', 'P', 'H' are not making sense.
 
I'd suggest something a bit different about the system.
First, I agree this might be some type of remote access system. The keypad has its own power supply, the connecting wires are long, and I'll bet the keypad output is RS-232 (also good for long runs). I agree the keypad is probably being reused.

Second, look at the 50-pin connector. That does not match up with Centronic interfaces, not any parallel printer pinout. The wiring is always ground, 4 data lines, and blank. While that could be a keyboard, I'd place strong odds on it being tied to a BCD (or binary) display with 8 digits.

I see no evidence so far of being tied to actual phone lines (no tone, modem, etc management).
 
Analysis of the ROM code is still going on, but a picture is forming. This looks very much like a development platform for the Z80. The usage seen for the two serial ports suggest full ASCII communications for both, not limited to the 12 keycodes on the keypad. The 50-pin connector is not used in any fashion that would align with connection to a keypad - there are "commands" that send or receive 2K bytes over this connection at full processor speed - but not in a manner that suggests a display (although, the 2K is the typical size of an 80x25 terminal's RAM - but usually only 1920/2000 bytes are in use). It would appear that there are three basic modes of operation. Normally, the system acts as a debug monitor on the local terminal at SIO channel A, allowing a program loaded into RAM to be executed, debugged, examined, modified, etc. Another mode is where the terminal attached to SIO channel A is software-connected to whatever is on SIO channel B, presumably a remote computer (local keystrokes are sent to the remote, input from remote is sent to local terminal). This mode also appears to support downloading Intel HEX data into memory (bulk program load from the output of an assembler, for example). The third mode appears to be a "remote control" mode where the remote system sends commands that, presumably, manage a program image in RAM and also interact with whatever is on the 50-pin connector (including the 2K bulk transfers). I am having trouble, though, finding mnemonic associations for the command letters, which is what made me wonder if they were for some language other than English.
 
I've made some progress restoring the ROM, albeit using a lot of educated guessing. I also threw together a simulator to run it on. The following commands are implemented and approximate what the original ROM did:

Code: 
[addr]CR - print the byte stored at <addr> (addr += 1)
[addr]/  - print the word stored at <addr> (addr += 2)
[addr]I  - Input bytes starting at <addr>.
        [byte]CR - store <byte> (or 00)
        SP       - skip to next addr
        -        - skip to previous addr
        .        - exit back to monitor
[addr]G  - Go (start execution) at <addr> or saved PC
P        - start execution at PC+1 (for RST1 traps)
T        - print word at SP (use '/' for next up stack)
R<reg>/  - print word for saved register pair (use '/' for next)
           <reg>: A,B,D,H,A',B',D',H',X,Y,S,P
(SP = space, CR = carriage return)

In general, <addr> is advanced to the next item and so repeating a command without an address just goes to the "next" location.

There are two ways to breakpoint a running program. Press NMI or have a RST 1 (0xcf) instruction in the program. In the case of a RST 1, the 'G'o command will re-execute the RST 1 unless a new address is input (or the 'P' command is used).

This ROM may work on your hardware (homebrew3.rom), but you'll need to connect a terminal to the SIO channel A port (P4 pins 1,3).

I created a simulator for testing. This runs in JAVA and uses a config file "homebrew3.rc" to set details. This sets up a telnet port where you may connect a terminal program (or plain telnet) to use as the console. The config file may be edited to change the host or port number as required. The simulator is run using the command java -jar VirtualHomeBrew3.jar homebrew3.rc.

All of this is located at https://github.com/durgadas311/homebrew3/tree/master/bin, with associated/source files located in neighboring subdirectories.

Commands that have not been restored will have unpredictable results. Since we don't know much about the device connected to the 50-pin connector, or how the serial port B was used, those items are still unfinished.
 
So, I've updated the ROM and associated materials. I was able to implement enough of the 'H' command and "terminal mode" to restore and test the HEX load feature. I was able to test this on the simulator by connecting SIO channel B to a telnet login session on my computer, and then I just did "cat junk.hex" and saw that the data was loaded into memory. Still a lot of details are unknown, like whether there was a way to offset the HEX load address (e.g. to load a ROM image org'ed at 0000 into actual RAM between 1000-1FFF).

The 'H' subcommands are currently interacting with the console (channel A) because that's the only practical way to test this. I'm not even certain the original code did otherwise, but I was suspicious because it called a completely different routine for character input, even though there already existed input routines for channel A. There could be explanations for that, even simple accidental duplication of code. I have not come up with a theory as to why this command loop would require a different input routine that still used channel A.

My test consisted of:
  • 'H' to enter the "H subcommand mode"
  • 'T' to enter "Terminal mode"
  • login to my computer
  • type "cat junk.hex" (this is a Linux system)
  • press Ctrl-^ to exit terminal mode
  • press 'X' to exit H subcommand mode
  • examine memory and see that data from "junk.hex" was loaded.
 
Just to have a little fun with this, I got the gui part of the simulator working. I then wrote a "demo" program for the HDSP-2111 chip that displays all 128 possible (built-in) characters in a scrolling pattern on the display. I created a possible ROM image with (only) this program in it.

@falter If you have the means to burn a 2716, you can try making one with https://github.com/durgadas311/homebrew3/blob/master/bin/demo.rom and see if the display lights up. It is still possible that I traced the connections to the HDSP-2111 wrong, so perhaps I have the I/O port addresses wrong. But this might help give some indication of how operational the board is (without requiring any peripheral hookups).
 
You must log in or register to reply here.
Back
Top