My 8080 CPU now runs CP/M and Zork

[mengstr]

The design has quite a lot of components (since I'm not using a ROM for the microoperations but rather just discrete logic as the real 8080 does) so it runs really slow. The clock maxes out at 25-30KHz while running real code, so it's about 100 times slower than real hardware.

Booting CP/M, loading Zork and waiting for the reply for my first command in Zork takes almost 8 minutes. I had to edit and speed up most of the video https://youtu.be/fUId6w7LU_M by 20x to get it watchable. ;-).

Do you have any tips on how I could increase the running speed? Considering the UI components are updated in a separate thread I guess that won't help much.

[hneemann]

This is incredible! To see CP/M running on a simulated 8080! And then to run Zork as well! Great! 😄

[hneemann]

Thinking about your processor: How did you manage to load CP/M and Zork? There is no disk drive! Are you simulating a ROM module?

[mengstr]

I'm simulating a two-port serial interface that was common back in the day - the 88-SIO. Instead of having an UART responding to writes/reads I've used two Telnet components.

The first one is in "server" mode so I can connect to it with a telnet application for the console.

The other one is in client mode and connects to a golang application that is a floppy emulator with a simple serial protocol. The BIOS sends a request like "read disk 2 track 17 sector 5" to serial port 2 and the golang app spits out 128 bytes of data that is read by the BIOS and put into the memory location as requested by CP/M.

So CP/M is 100% unaware of that anything special is going on. Zork simply sends a read file request to the BDOS, the BDOS requests sectors from the BIOS as usual. Then the BIOS fetches them over serial instead of communicating with a real floppy disk controller in the system.

Starting up the CP/M is also just done as usual in a real system. At system start there is a ROM Monitor in the BIOS ROM that can dump memory, poke I/o ports and some other stuff. It can also get sector 0, track 0 on disk 0 (the bootloader) and start executing it. And the bootloader then pulls in the OS from the first two tracks of the disk and jumps to it.

[fredcwbr]

Amazing

[hneemann]

In terms of speed, the graphics are drawn in a separate thread, but the simulation must be paused while the state of the components is read out, after which the simulation continues and the graphics are drawn in parallel.
However, reading out the status takes longer if a lot of information has to be queried. And every visible component and every visible wire is queried. If the top-level circuit only contains a few components, the pause is shorter. However, since reading out the status is a very fast operation and only takes place every 100ms, I'm not sure whether it brings any significant advantage, but I would give it a try. All you have to do is create a new circuit, embed the processor and connect the clock.

[mengstr]

yes, as expected I got a minor speed increase by doing that. It went from 28-29 KHz when idling in a serial input polling loop to 31-32 KHz - so about a 10% increase. That would shave off almost 30 seconds on the time it takes to get into Zork and start playing.

But I think I rather have all the nice blinkenlights visible than the speed increase, then I at least have something pretty to look at while waiting ;-)

This might be my reason for getting a M4 instead of my current M1 MacBook. On the other hand I had my old 2013 MPB for almost 10 years before replacing it so I'm stuck with the M1 for a while longer.