The project is entering its fifth year and plenty has been going on. Here's an update on completed and in-progress tasks for the 1.0 software release, plus some future plans for the platform.

Load Averages

To finish debugging the kernel, some additional insight was needed on how the kernel was handling messages. It's possible to measure the load average of the machine by counting the number of virtual machine cycles used by the CPUs vs. the kernel. Each CPU can run for up to 100 blocks before a context switch and sequence; kernel, CP/M, CP/M, disk, means up to 300 blocks could pass between kernel calls.

This average block count is sampled every two seconds and added to a record containing 128 values. This can be averaged again to give various load averages, e.g last 15 seconds, 1 minute, 4 minutes. The load average is just the average block count divided by 100 and since the disk block count is typically below 20 it will fit in the available range 0.00 to 2.55 for one byte per sample.

In addition to the load average the kernel also tracks CPU efficiency. The IDLE instruction is called every time the virtual CPU doesn't have enough cycles in the video line to execute an instruction. The additional idle time is used to increment a 16-bit counter and keep track of the number of idle cycles. This count is now reset and sampled by the same code used to sample the load average. The result is a byte representing the percentage of idle cycles and can range from 0 to 25.5%.

The data is stored in the kernel memory at location 0xE800-0xE87F for the idle data and 0xE880-0xE8FF for the load average. The plan is to add a way to view this data in future.

Buffered Serial

A serial console has been in place since the early days of the 8080 machine code monitor, but this was designed for handling one byte of text data as a time. What is needed for file transfer is a buffered binary mode. Work started on this back in April last year and was only recently completed.

Data sent to the PUNCH BIOS call is buffered by CP/M until a threshold is reached. Once reached the buffer is copied to the CPU's shared memory as a record and a SEND command sent to the kernel. The kernel will then add the record data to the serial transmit buffer. This buffer may be full, or only some of the data can be sent. These various corner cases are handled by the CP/M BIOS and kernel code to keep the transfer state in sync.

Data read from the READER BIOS call sends a RECV command to the kernel and the kernel returns the serial receive buffer as a record back to CP/M. The subsequent calls to READER will return bytes from this record until empty, then a new call is made to the kernel. Both kernel calls for sending and receiving data result in a delayed return from the kernel. The delay is two ticks, or the amount of time it takes to transmit or receive 128 bytes of data at 9600 baud.

This delayed kernel response keeps the CP/M calls in sync with a 128 byte transmit or receive transfer buffer size. In this way the serial connection can be utilized at its most efficient with CP/M sleeping until the next chunk of data is available.

Basic Load and Save

The plan was to have basic "on board" when the machine ships. There is not a lot of room in the ROM, so the more advanced MS BASIC was out of the question. Instead a more classical 8k BASIC is included. These early BASIC interpreters would typically load and save programs via tape... not 1980's home computer cassette tape, but punched paper tape!

IMSAI 8k BASIC is shipping in the ROM and the tape load and save code has been updated in the  to use the new buffered serial mode. The SAVE command switches the BASIC output to the READER and then the LIST command is called along with a terminating KEY command. The output can now be copied from the serial console and saved in a file.

The LOAD command will switch the BASIC input to READER and then start processing commands until a KEY command is reached. This way the original saved output can be replayed via the serial console to re-enter the program. The console output is silenced to keep the transfer as fast as possible.

The 8k BASIC is now complete with the ability to load and save BASIC programs.

Util

That covers all the completed features, now comes the last piece of the puzzle. The original plan was to include an XMODEM program to transfer files over the buffered serial connection. It turns out to be a very obsolete tool and not well supported on modern computers. It also turns out to be fairly unnecessary since the FTDI chip does a great job of handling error-free communications between a host USB and the RS232 port.

The original XMODEM program is being refactored to be just a simple file transfer tool that can read/write CP/M files and send them over the buffered serial connection. The plan is to add a few more features, like a "format" command to format the A: drive and possibly an uptime command to show the uptime and load averages discussed earlier. As such, the 2k byte XMODEM command has now become a more generic UTIL command.

The UTIL command will be the final feature and complete 1.0 software release.

Disintegrated

So what comes next? The 3+ years of software development has created a pretty impressive TTL computer platform with a lot of potential and it would be great to get it out to a wider audience.

The idea of offering an assembled version has been floating around for some time. It makes most sense to use surface mount components for automated assembly, and an SMD version of the current design is definitely possible. However, this might be a great opportunity to go a bit further and create something more along the lines of the Monster 6502.

Going down to the transistor level would be impractical though, but a single gate/function-per-chip design is possible. The plan would be to use a limited selection of chips, each of which would come in an SOT-23 size package. After evaluating the options, the following four devices were chosen:

These consist of:

• 1G374 - D-type Flip Flop with tristate output (est. 170 total)
• 1G19 - 1:2 demultiplexer, or OR-gate, or inverter (est. 100 total)
• 1G11 - 3-input AND-gate (est. 50 total)
• 1G86 - 2-input XOR-gate (used to convert D-flip flops to T-flip flops, est. 20 total)

There would also be a few analog switches for the video selector, op-amps for the audio filter, and transistors for the RS232 drivers, PS/2 port. These would also be SOT-23 packages. The only non-SOT-23s would be the RAM (TSOP II) and ROM (socketed PLCC).

There would be at least 500 SMD components on the board, of which 350-370 would be SOT-23. The rest would be passives. The board would be the same size with the same connector layout and fit in the same box as the original Novasaur. There may be some more LEDs on the board for that added blinken light look.

The first step is to see if the logic can meet the propagation and setup times to run at the current speed. The critical areas are the execution state machine (PAL) and program counter. The schematics below show what this logic looks like in the disintegrated form.

The good news is the LVC 5V logic can not only meet but exceeds the timing requirements. The execution state machine comes in just below 25ns and the subsequent program counter propagation is just under 40ns total. This could allow the machine to run with a 40MHz dot clock using 45ns RAM.

It's a long road ahead though. This project can not be done in one step. The first stage will be to evaluate this approach by building out the two circuits above and validating them in the current design. Once debugged the rest of the system is fairly easy to convert. It will likely take the rest of this year to get to a working design and this is a current year 5 goal.