Close
0%
0%

Novasaur CP/M TTL Retrocomputer

Retrocomputer built from TTL logic running CP/M with no CPU or ALU

Public Chat
Similar projects worth following
The Novasaur is a full-featured personal computer built from less than three dozen Advanced Schottky TTL chips (circa 1979). It supports an 80-column SVGA text display, PS/2 keyboard, programmable sound generator, RS232 serial, and an Intel 8080 byte-code interpreter. The machine is capable of running early 80's computer games and CP/M using a built-in 250k RAM disk.

Novasaur TTL Retrocomputer

  • Dual Processor CPU/GPU (Harvard Architecture).
  • 33 MHz dot clock, 16.5 MHz data path, 8.25 MHz per processor (~3.5 CPU MIPs)
  • 256k ROM: 96k ALU, 64k native program, 64k cold storage, 32k fonts.
  • 512k RAM: 7 banks of 64k user, 60k display, 4k system.
  • 76 ALU functions including multiply/divide, system, and math functions.
  • Bitmapped Graphics: Hi-res mode up to 416x240 with 8 colors and 4 dithering patterns. Lo-res mode up to 208x160 with 256 colors, double buffered.
  • Text Mode: 8 colors FG/BG, 256 line buffer, up to 104x60 using 8x8 glyphs, 80x36 and 64x48 rows using 8x16 glyphs.
  • Audio: 4 voice wavetable synthesis, ADSR, 8-bit DAC, 8Hz-4.8kHz.
  • PS2 Keyboard: Native interface built in.
  • RS232 Serial Port: Full duplex, RTS/CTS flow control, 9600 baud.
  • Expansion Port: 7 addressable 8-bit register ports, 4 interrupt flags
  • Chip Count: 34 TTL (22 CPU, 12 GPU), 1 ROM, 1 RAM, 1 PAL, 4 analog.
  • Gate Count: 1,425 (935 CPU, 490 GPU)
  • PCB size: 8" x 5" (200 x 125mm) double-sided board.
  • Power: 6v @ 1.6A (10W)

The Novasaur consists of two processing units (CPU/GPU) operating on the alternating cycles of a 4-phase clock. The 4-phase clock is driven by a 33MHz oscillator to generate a processor clock of 8.25MHz. Each processor accesses one of the two address spaces (ROM/RAM) concurrently on a memory access cycle of 60ns (16.5MHz).

The GPU functions as a DMA controller operating in transparent mode to read the video memory and output to one of two video DACs. The first DAC generates 256 colors using three bits for the red/green, and two bits for the blue. This DAC is used for low res graphics mode where each byte of the video memory represents a single pixel.

The GPU also supports a text mode where the bytes of video memory alternate between a color byte and a code point representing a text character. The color byte is used with the second video DAC to represent two 8 color values for foreground and background. The text mode can also support a high res graphics mode with two pixels per byte of video memory.

The CPU instructions use a 4-cycle sequence consisting of: fetch, read, execute, write. The fetch cycle uses a program counter to access the machine code instruction in the ROM:

The read cycle provides access to the RAM in the indexed addressing mode.

The execute cycle returns to the ROM to access the program memory for immediate addressing, or a set of lookup tables for an ALU operation.

The final cycle is the write cycle where a register is updated with the execution result and optionally the RAM in the indexed addressing mode.

Instructions take from one to four process cycles to complete: The instructions are either 8 or 16-bits, so the fetch cycle takes either one or two process cycles to complete. The ALU operations can only handle one nibble per cycle, so two process cycles are required to handle an entire byte. The NOP instruction and conditional loads, were the condition is not met, are only one cycle (no execute). On average the instructions take 2.35 process cycles to execute for a nominal CPU speed of 3.5MIPS.

The base firmware implements a hardware abstraction layer (HAL) to support a video system with up to 46 addressable video modes, a multi-voice sound synthesizer, and a dual-port UART providing a full-duplex RS232 and PS/2 interface. The operating system and user programs are executed via a byte-code interpreter providing binary compatibility with the Intel 8080/5.

Novasaur - VCF East 2023.pdf

VCF East 2023 Presentation - https://www.youtube.com/watch?v=J4ykbJM90S0

Adobe Portable Document Format - 5.60 MB - 03/03/2024 at 15:31

Preview
Download

rom-r1.0.hex

ROM Version 1.0 (first complete software release).

hex - 615.40 kB - 07/24/2023 at 17:26

Download

Novasaur - VCF East 2023.pptx

VCF East 2023 Presentation https://archive.org/details/VCFE2023_Novasaur_TTL_Retrocomputer

presentation - 9.47 MB - 07/24/2023 at 14:48

Download

gigasaur-schematic-v1.5.pdf

Gigasaur schematic for release (rev. 5) PCB

Adobe Portable Document Format - 683.20 kB - 07/24/2023 at 13:50

Preview
Download

schematic.v1.10.pdf

Novasaur schematic for release (rev. A) PCB

application/pdf - 874.23 kB - 11/22/2021 at 02:44

Preview
Download

View all 11 files

  • Stick a Fork in it

    Alastair Hewitt07/24/2023 at 03:04 0 comments

    It's done! As in the software is at version 1.0 and ready to ship.

                 _
                /o)
       _/\/\/\_//
     _/NOVASAUR/
    /_/{_}~~{_}
    
    Novasaur 64k CP/M vers 2.2
    Copyright 1979 (c) by Digital Research
    
    a>b:uptime
    
    System uptime: 0 days, 03:18:38
    
               CPU Load Average (last 4 mins)
         0      0.5     1.0     1.5     2.0     2.5
         +-------+-------+-------+-------+-------+
    0.05 |              .
    0.05 |              .
    0.05 |              .
    0.06 |=            .
    0.67 |===========.
    1.02 |==========.=====
    1.03 |==========.=====
    0.30 |====         .
    0.07 |=             .
    0.24 |===            .
    0.15 |==             .
    0.29 |====          .
    0.05 |              .
    0.05 |              .
    0.05 |              .
         +-------+-------+-------+-------+-------+
         0%      5%     10%     15%     20%     25%
               CPU Idle Cycle % (dotted line)
    
    

    The last pieces of the puzzle have been added to the B: drive highlighted below.

    B: ASM      COM : BASIC    COM : CPM      SYS : DDT      COM
    B: DUMP     COM : ED       COM : FORMAT   COM : LOAD     COM
    B: PIP      COM : STAT     COM : SUBMIT   COM : UPTIME   COM
    B: XFER     COM : XSUB     COM

     These are three small (1k) utility programs as follows:

    FORMAT

    Used to format any CP/M drive installed on the Novasaur. Currently this would only apply to drive A:

    FORMAT drive: [/Y] [/B]
      /Y    Confirm without further prompt.
      /B    Bleach the file system (set all bytes to ctrl-Z).

    UPTIME

    As shown above. This returns the time elapsed since the last cold boot and a chart showing the load average and CPU idle percentage over the last four minutes. 

    XFER

    Used to send and receive binary files over the serial connection. This was originally going to be XMODEM, but this was changed to a basic file transfer utility. The USB FTDI connection is reliable and the transfer can be completed with a simple send or capture command from the host.

    XFER <drive:filename.ext> {/R or /S}
      /R    Receive file over serial.
      /S    Send file over serial.

    The XFER program detects if it running on the TTY and will respond appropriately. File capture from CRT will ask for a keyboard confirmation to start the file transfer. From TTY an extended timeout is used to allow time to control file capture without confirmation.

  • Year 5

    Alastair Hewitt02/27/2023 at 01:37 0 comments

    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...

    Read more »

  • Race Conditions

    Alastair Hewitt01/22/2023 at 21:21 0 comments

    There was a six month pause in software development, which wasn't such a good idea. It's taken a while to get back up to speed and get to grips with the remaining "minor" bugs/features. These are all hard problems like race conditions and the binary-mode serial interface. This log explains one such race condition.

    The following eye charts show the context switch sequence and message flow for requesting a RAM-disk record (discussed in the Kernel section of this log). The sequence is basically kernel-cpm-kernel-disk and originally all the disk quadrants were sequenced together (show below). The advantage of this is the ability to complete a full disk operation with only 8 context switches.

    [ 1 = Kernel, 2+3 = CP/M, 4+5+6+7 = Disk Quadrant ]

    One disadvantage is that all kernel operations require an 8-cycle turn around. This means just printing a single character to the console will take 8 context switches... such is the life of a micro kernel. One way to improve this is to scan only one disk quadrant per sequence. This increases the maximum disk operation (cpm-kernel-disk-kernel-cpm) to 16 cycles, but reduces the console turn around (cpm-kernel-cpm) to just 4 cycles.

    There is one issue with the approach and that's the possibility of dispatching multiple requests to the same disk quadrant before that quadrant is reached. This turns out to be quite likely when the machine is booting up. Both the TTY and CRT instances of CP/M boot up in lockstep. They both dispatch a request for the same disk quadrant around the same time and the second request gets dropped.

    Apparently this was a know issue with the classic "TODO" comment in the code...

    @@ -161,7 +163,7 @@ HANDHL: ADI     BASEPG  ;A=BASEPG+CPU#
     ;
     SNDRET: DW     IPCSND  ;SEND MSG, EXPECT RETURN
             ORA     A       ;A==0?
    -        JZ      WAIT    ;TODO: HANDLE ERR
    +        JZ      IPCERR  ;HANDLE ERR
     SETRET: CALL    HANDHL  ;HL=HANDLER
             MOV     M,C     ;CMD=C
             LDA     SRCCPU
    @@ -172,6 +174,12 @@ SETRET: CALL    HANDHL  ;HL=HANDLER
             INX     H
             MOV     M,D
             JMP     WAIT
    +
    +IPCERR: LDA     SRCCPU
    +        MVI     B,0
    +        DW     IPCSND
    +        JP      WAIT
    +

    The IPCSND instruction returns zero in the accumulator if the destination CPU is not expecting a message**, e.g. if it just received one from another process. The error is now handled by clearing the sequence number in the originating command and returning a message in the same thread. The CP/M BIOS will retry the disk operation if this occurs.

    ** Update: "not expecting a message" was the CPU not in the wait state, but it has now been updated to include both not sleeping OR sending a command. This was causing another race condition that showed up after the previous one was fixed.

  • Machined

    Alastair Hewitt12/15/2022 at 23:58 0 comments

    Figuring out the CNC machine and designing the panel cutting and engraving patterns was yet another subproject of immense proportions! Thankfully this is now complete...

    A simple method was found to machine the panels. This is done by using a slot made by a facing bit to hold the panel level with the face of the spoil board. A small gap is left at the top to allow two countersunk screws to hold the panel in place and stop it from breaking loose while milling.

    The back panels for the Novatron (top) and Novasaur (bottom) are show below.

    A V-cut bit is used on the front panel to engrave the name and cut two holes, one for the LED and one for the power switch. The image below shows the development of the engraving:

    And the final designs...

    A few kits have made it out in to the wild for beta testing. Work is starting on the assembly instructions to complete the kit.

  • Solid State Machines

    Alastair Hewitt10/06/2022 at 21:07 0 comments

    Things are still progressing with a lot of behind the scenes work. This included setting up a business to officially launch the products - there will be two initial products with plans for more produced by Solid State Machines!

    The website has some basic info, a forum, wiki, and store. The plan is to fill out the wiki by pulling a lot of details from these logs and adding more detailed info on the software and how to develop the platform.

    Both the Novasaur and Novatron made it to VCF Midwest last month. The Novasaur was showing off not one, but two instances of CP/M running on the same machine.

    The image above shows the VGA output displaying a mandelbrot set generated by MS Basic (it took a long time!) and a game of Super Star Trek being played via the serial terminal. Both these programs were loaded over the serial terminal using PIP as Intel hex files and then converted to binaries using Load.

    This is going to be the initial release configuration of the Novasaur with the machine booting to CP/M on both the VGA console and serial terminal (the machine-code monitor is still accessible by hitting ctrl-alt-home).

    VCF Midwest also hosts a lot of retro-tech YouTuners resulting in some brief coverage by the 8-Bit Guy and Ben Heck, plus a full one-on-one interview with Dr Dave.

    Components are on hand for two dozen kits including packaging materials to ship the final product. The images below show the kit components.

    There are a couple of things still missing: The assembly guide and the machining of the case. This requires something to machine the ABS panels... so there's a new side project to set up a CNC machine.

    After the CNC setup and assembly guide there's still a couple of minor bugs to clean up in the Novasaur software to get to a 1.0 release. The plan is to release both the Novasaur and Novatron together in the new year. Sorry for all the teasing this year... it's getting there!

  • A Slight Detour

    Alastair Hewitt07/08/2022 at 21:28 3 comments

    It's been a couple of months since the last update and the plan earlier this year was to have some kits available by now. Things in the post-COVID world were a bit more challenging than expected, but component inventory is starting to roll in! 

    The user manual still remains the long pole in the tent for the final kit configuration, so an initial kit will launch with a slimed down construction guide. The target for this is the Vintage Computer Fest Midwest in early September. A website is also under construction to provide more details and online ordering.

    But there's more... There was a slight detour to take a break from the endless software development and to remind me that debugging hardware is just a painful as software... Introducing the Novatron!

    The Novatron is a binary compatible version of the Gigatron TTL microcomputer in the form factor of the Novasaur. The benefit here is the existing software ecosystem proving a much shorter runway to a finished product (3 months vs. 3 years).

    Shown above is the Rev.2 board with the Pluggy Reloaded add-on, and below is the machine in action housed in a groovy faux-wood finished case and matching 80's portable TV.

    The final version will drop the Pluggy Reloaded and include features from the Gigatron IO and RAM Expander/Expansion project. This adds support for 128k RAM and two SPI ports with the first connected to an SD Card holder mounted directly to the board.  The second SPI is available via header for an internal expansion board or a second external SD Card breakout board.

    Other modifications over the original Gigatron include 6-bit audio (reducing the blinken lights to a single bi-color LED) and a hi-res output. The hi-res output is based on the Novasaur design and is selectable using a switch mounted in the same position as the Novasaur volume control. The rest of the connectors and switches match the Novasaur and are mounted in the same positions so they can use the same machined case.

    A Novatron kit should be available around the same time as the Novasaur kit, or shortly thereafter.

  • File Transfer

    Alastair Hewitt04/16/2022 at 04:17 0 comments

    The final piece of the puzzle is file transfer and the plan is to use the era-appropriate Xmodem. A modern version has been developed for 8080 CP/M by Martin Eberhard (founder of Tesla). Only basic functionality is needed, so the early version 1.01 is being added to the ROM at a cost of only 2k bytes. 

    It's going to take a few more weeks though. The plan is to buffer the data on the CP/M BIOS side and hand it off in chunks to the kernel. The CP/M process will yield on a kernel timer to allow time for the chuck to transfer (10 blocks per byte). This will allow the full duplex serial connection to perform concurrent transfers: One instance of CP/M can be downloading a file while another is uploading.

    In the meantime there is a way to transfer files to CP/M via the monitor: The monitor has some kernel functions available to get and put records to the RAM disk. These take the following form:

    KG[track][sector] [address]
    > KG0000 0000
    
    KP[track][sector] [address]
    > KP0000 0000

    There are a total of 63 tracks (00-3E) with 32 sectors each (00-1F). Each sector contains a 128-byte record that can be read (kernel get) with KG or written (kernel put) with KP. The records are read from, or written to, a 16-bit address in the monitor memory.

    The CP/M A: drive directory is 2k and occupies the first 16 sectors (track 00, sector 00-0F). The kernel format command KF will create an empty directory record and copy it to these sectors. The following monitor commands can be used to copy the first 4 sectors of the directory and display then in memory location 0-1FF:

    > KG 0
    > KG1 80
    > KG2 100
    > KG3 180
    > D 1FF

     A file can be created in CP/M  by quitting the monitor (enter Q) and using the save command:

    a> save 4 test.txt

    This will save the first 4 pages of the TPA in a 1k file called test.txt. The directory entry will show a single block number of 02 which corresponds to track 00, sectors 10-1F. A file can be transferred over the monitor serial connection as a sequence of hex digits (one per line) using the monitor load command. The following would load data (e.g. 1k) to address 100 to 4FF and then transfer it to track 00, sectors 10-1F.

    > L100
    0100: FF
    ... copy hex, end with Q
    
    > KP10 100
    > KP11 180
    > KP12 200
    > KP13 280
    > KP14 300
    > KP15 380
    > KP16 400
    > KP17 480

    The data transfer will overwrite the contents of the 1k test.txt file on the CP/M A: drive. This isn't very user friendly, but it was a useful technique for testing and debugging the CP/M BIOS and kernel code.

  • Time

    Alastair Hewitt03/31/2022 at 00:19 0 comments

    The realtime clock (RTC) was introduced in this log. There was mention of instructions to get the time in a more convenient format. That code was written about a year ago, but has only just been integrated as various loose ends are being tied up.

    The RTC counters are reset on power up or cold boot. The clock then keeps track of time with an accuracy of around 14ppm. The first application was to add an UPTIME command to the monitor. This displays the time since power up (cold boot) in the format DDD HH:MM:SS

    Clock Division

    The hardware abstraction layer (HAL) divides down the 8.25MHz CPU clock by a total of 182,474,244,096,000. This is done via the following steps:

    • Osc: 33.000MHz (+/- 100ppm)
    • CPU (÷4) 8.25MHz
    • HAL (÷43) 191.86kHz
    • Line (÷5 or ÷4) 38.372kHz or 47.965kHz (depending on video mode)
    • Block (÷4 or ÷5) 9.593kHz
    • Frame (÷128 or ÷160) 74.9455Hz or 59.9564Hz (depending on video mode)
    • Tick (÷5 or ÷4) 14.9891Hz
    • TIME0 (÷90*) count to 6.00436 secs (*adjust TIME0 by -1 every 15th TIME1 count)
    • TIME1 (÷120) count to 719.990 secs or 11.9998 mins
    • TIME2 (÷120) count to 1439.98 mins, 23.9997 hrs, or 0.999986 days
    • TIME3 (÷256) count to 256 days, 36.57 weeks, 8.4 months, or 0.7 years

    Real-Time Clock

    The realtime clock consists of the four bytes: TIME0-TIME3. As shown above, these don't count typical increments like seconds, minutes, hours etc. They are optimized for 7-bit arithmetic and the ability to update everything within one additional virtual-machine cycle. These counters are updated at the following rates:

    • TIME0 - 15 ticks per second
    • TIME1 - 10 ticks per minute
    • TIME2 - 5 ticks per hour
    • TIME3 - 1 tick per day

    One other thing to note. The counts for TIME0-TIME2 are negative and count up to zero. This is done to simplify the overflow condition and just test the sign bit. The final count TIME3 is the only positive count and represents the number of complete days the machine has been on.

    Calculating Time

    A general formula can be used to calculate the actual time unit:

    • UNIT[n] = (TIME[n+1] % 10) * max + TIME[n] / ticks

    Where max is the highest value of that unit held by the counter and ticks are the ticks per unit. This leads to the following formulas for the standard time units:

    • SECONDS = (TIME1 % 10) * 6 + TIME0 / 15
    • MINUTES = (TIME2 % 10) * 12 + TIME1 / 10
    • HOURS = TIME2 / 5
    • DAYS = TIME3

    However, these formulas assume the counts are positive numbers. In this case they are not and this type of math will not work.

    Modular Arithmetic

    There are two approaches to dealing with the negative counts: convert the numbers to their positive versions, or use the negative versions and then convert the result. An important observation here is the fact the results will be sexagesimal. This allows the use of modular or clock arithmetic and favors the latter method.

    The counts are considered to be positive 8-bit integers and adjusted with a final offset to wrap to the correct sexagesimal number using a MOD60 operation:

    • SECONDS = MOD60 (13 + (|TIME1| % 10) * 6 + |TIME0 - 1| / 15)
    • MINUTES = MOD60 (35 + (|TIME2| % 10) * 12 + |TIME1 - 6| / 10)
    • HOURS = MOD60 (|TIME2 + 120| / 5)
    • DAYS = TIME3

    This may look more complex, but it can be efficiently coded to fit in a single 2-cycle extended instruction (utilizing a jump page in the 0xED range of instructions). The MOD60 unary function is also used to convert the result to binary-coded decimal (BCD), or more specifically, binary-coded sexagesimal

    Sexagesimal Adjust Accumulator

    The reason for converting the result to BCD is the typical use case where the time displayed as a timestamp. The realtime clock is reset to zero on cold boot and the current time can be calculated by adding the time the machine started to the current uptime tracked by the realtime clock.

    This requires the addition of two BCD numbers...

    Read more »

  • State of Play

    Alastair Hewitt03/25/2022 at 01:07 0 comments

    The following log is going to be a bit of a brain dump on the current state of the firmware/software development. This snapshot is captured in the R0.3 ROM uploaded to the files section today (also tagged in the Git repo).

    First a quick overview of how the current software is structured:

    The R0.3 ROM was the final phase of the Kernel/CPM testing and debug (Test/Debug Configuration). Here the CP/M instance is running in the Kernel space of CPU1. It can access the input and output ports directly to simplify the console access. It is also possible to exit CP/M and return to the system monitor to examine the RAM. The Kernel is only used to talk to the RAM disk (CPU4-CPU7 contexts).

    The next stage of development is switching to the final Multi-user Configuration. Here there are two CP/M instances running on the CPU2 and CPU3 contexts. These cannot access the console directly and will interface via the Kernel to access the console. This additional layer of abstraction provides the ability to create pseudo-TTY terminals and allow the user to switch between the two CP/M instances (similar to Unix).

    Test/Debug Configuration

    The rest of this log describes the functions/features of the R0.3 ROM in the Test/Debug Configuration. On a cold boot (power on or hardware reset) the machine will boot to the 8080 system monitor. There are a couple of issues to clean up with the keyboard initialization, so there may be an extra character shown after boot.

    The monitor accepts input via the console (PS/2 keyboard and VGA display) and the RS232 serial port. This is the default start up, so the keyboard and display are not required. The board can be connected to just a serial terminal.

    Serial Port

    The RS232 serial port has a fixed speed of 9600 baud, one start bit, 8 data bits, no parity (9600-8-N-1). The serial port uses RTS/CTS hardware flow control. The LED is connected to the RTS line and will light when RTS is asserted. If the LED is off then the board is not ready for serial data.

    The serial status can be toggled using the 'T' command in the monitor. Typing 'T' will turn the serial thread off/on and the RTS LED will toggle to show the serial status. An additional state is tracked by the serial interface to manage flow control. If a command is sent via the serial port then the monitor will enforce flow control and prevent the input and output buffers from overflowing. This will cause the RTS LED to go out during heavy serial load, like doing a dump command.

    Note: some serial terminals and interface programs do not support RTS/CTS flow control correctly. This can result in some glitchy behavior.

    Console

    There are four native video modes supported by the board, with additional timings and fonts available. This provides the following 8 text modes:

    • VGA @ 60Hz - 8x8 glyphs - 104x60 text
    • VGA @ 75Hz - 8x8 glyphs - 80x60 text
    • VGA @ 75Hz - 8x10 glyphs - 80x48 text
    • VGA @ 75Hz - 8x16 glyphs - 80x30 text <-- cold boot starts here
    • SVGA @ 60Hz - 8x8 glyphs - 80x75 text
    • SVGA @ 60Hz - 8x10 glyphs - 80x60 text
    • SVGA @ 60Hz - 8x16 glyphs - 80x37 text
    • XGA @ 60Hz - 8x16 glyphs - 64x48 text

    The video mode can be changed from the keyboard using a CTRL-ALT escape sequence as follows:

    • CTRL-ALT-DEL - reboot machine to current mode
    • CTRL-ALT-PAGE_UP - reboot machine to next mode
    • CTRL-ALT-PAGE_DOWN -  reboot machine to previous mode

    The cold-boot console color scheme is set to the classic green text on a black background. The font, background, and foreground color can be changed by sending a byte to output port 2F ($CONF). The following command would update this to 78:

    O2F 78
    

     A control sequence from above will restart the video and fill the console memory with this value. The least-significant 3 bits from the first nibble sets the foreground color (RGB) and the least-significant 3 bits from the second nibble sets the background color. The most significant...

    Read more »

  • 8k BASIC

    Alastair Hewitt03/21/2022 at 03:49 0 comments

    The hope was to ship the Novasaur with some form of BASIC on board. There is just enough space on the B: drive to fit a 1970's era 8k BASIC. The more capable MBASIC 5.21 can be loaded to the A: drive, but at over 24k it won't ship in the ROM.

    The initial effort was bringing up the original Microsoft Altair BASIC (circa 1978). There is a source code available, but this proved to be defective. The alternative was the IMSAI 8K Floating-point BASIC (circa 1977). This source code was more successful!

    The image above shows the following BASIC program running at actual speed:

    10 FOR X=0 TO 2*PI STEP PI/15
    20 PRINT SPACE(INT(SIN(X)*36+36));"*"
    30 NEXT X

    There are still some optimizations to be made in terms of console integration and the software restarts. The performance isn't too bad though considering the CPU is running at 1/5th the speed of the original hardware.

View all 86 project logs

Enjoy this project?

Share

Discussions

Jim Bailey wrote 11/08/2023 at 19:53 point

I would be happy to beta test and give you feed back on the build and such (not expecting a free kit).

  Are you sure? yes | no

Alastair Hewitt wrote 11/10/2023 at 01:30 point

I have the part on hand for another small batch of beta kits. I'll need to machine the panels, so it may be towards the end of the month. I've been doing these for $200 plus shipping

  Are you sure? yes | no

Jim Bailey wrote 11/05/2023 at 23:45 point

Are you still planning to make a kit of this computer?  It looks really intresting.

  Are you sure? yes | no

Alastair Hewitt wrote 11/08/2023 at 14:45 point

Hi @Jim Bailey I have some beta kits available. I was pulled in to anther project so things went a but quiet here. I'll have some updates in December and will keep you posted.

  Are you sure? yes | no

hans61 wrote 02/14/2022 at 10:59 point

How do I get a set or the gerber files

  Are you sure? yes | no

Denjhang Liu wrote 01/10/2022 at 12:32 point

I want to buy a set right now! I am very interested in this project.

Of course I also hope that you can disclose more details, such as PCB design and gerber, so that I can build one myself.

  Are you sure? yes | no

John.D.Gay wrote 11/02/2021 at 20:22 point

I just discovered your project.

I also enjoyed the Gigatron, but the idea of a TTL computer running CP/M is enough to make me want to build my own. Once you've finished, of course.

My only real question is, since you've gone from the COMSAC all the way up to the 8080, why not take that last step to the Z-80? I know it is well supported in the CP/M world.

My original computer was the TRaSh-80, followed by the TS-1000. So I'm kind of partial to the Z-80. As I understand, it was what the original designers of the 8080 wanted to advance to, but Intel tied their hands.

I was even more impressed with the 68k series when Motorola decided to drop backwards compatibility in favour of an improved instruction set.

But I was only just a casual observer of these developments. Programming was just a bit beyond my skillset.

Anyway, I would really love to get one of these boards for my own and get Super Star Trek and Hitchhiker's Guide to the Galaxy running on it!

Keep up the great work!

  Are you sure? yes | no

Alastair Hewitt wrote 11/05/2021 at 00:07 point

Unfortunately the Z80 fills up all the available instructions and I need the unused 8080 instructions to break down some of the more complex instructions. I do extend the 8080 instruction set like the Z80 using the same $DD, $ED, and $FD codes. I'm building these out with new complex instructions that can do things like floating-point math, line drawing in graphics modes etc.

  Are you sure? yes | no

Dennis Kuschel wrote 10/28/2021 at 12:53 point

Hi Alastair,

I read about your project on the hackaday blog. I would like to congratulate you for this great project and your exhibition at VCF! I can very well understand how much work and heart blood is in the project. I find your computer design really remarkable, it is not easy to get a CPU and a DMA controller with so few components on one board. It is obvious that the project is very software driven.
How stable is your computer running? Especially with the high clock frequency it was certainly not easy to get the hardware stable under all circumstances. I myself exhibited my MyCPU at VCFe (in Europe) in 2007, and even won a prize. My computer consists of several boards and has a separate graphics card, but is not binary compatible to existing systems. So I had to write the operating system and all application software by myself, but the software runs very smooth with 4 MHz CPU clock. I also wanted to write an 8086 software emulator for the MyCPU and boot FreeDOS, but I just don't have the time at the moment.
Since rebuilding my MyCPU is very complex and expensive, I developed a new computer. The MyNOR is a single board computer with as few components as possible. Just like your Novasaur (great name!) it is also software driven, and therefore very slow. But it is also easy to rebuild, and it can even be built with transistors (I call my transistor version TraNOR).
Do you plan to sell kits? I could well imagine that there are some people who would like to rebuild your computer, especially now after the VCF. The kits for my computers are available at Budgetronics.eu, maybe Henk Verbeek (owner of Budgetronics) is also interested in offering your computer.

Regards, Dennis ( mycpu.selfhost.it )

  Are you sure? yes | no

Alastair Hewitt wrote 10/30/2021 at 14:00 point

Thanks for the comment Dennis! I'm familiar with your work and love the MyNOR. It is very compact and impressive. My plan is to offer a kit next year. The hardware is good to go but I still need to finish things on the software side.

The design is based on an idea I had a long time ago, but I had never intended that to run at high speed. The Gigatron was the inspiration to see if I could get this design to run fast enough for video and a native text mode. The main clock is only used to drive a shift register to output the text mode pixels. It is divided down by 4 to run the main CPU at 8.25MHz. The original plan was to run at 6.25MHz with the standard 25MHz VGA clock. I experimented with overclocking early on in the design process and that's how I got to 33MHz. It is completely stable at that speed, but only just. I see glitching at 35MHz and that's only a 3.5ns difference in terms of the memory access time. That makes me nervous.

Pretty much everything is bit-banged so I had to build a virtual machine to make it usable. That was the hardest part and has taken most of the time. It provides a set of hardware abstractions and the 8080 interpreter. I then decided to go a bit further and add a micro-kernal to manage the machine resources and an internal RAM disk. That's the final part of the puzzle so almost there!

  Are you sure? yes | no

Ian de Beer wrote 06/09/2022 at 05:36 point

I am also REALLY interested in your TTL computer!. Any update on the selling of Kits? I've built the GigatonTTL previously and loved it! Your computer is a MARVEL! I'd love to add it to my collection!

  Are you sure? yes | no

Alexander wrote 05/28/2021 at 13:45 point

2 CPUS and a GPU  in TTL?!?!  Is there more than that board? Seems literally incredible. Either I'm misunderstanding what you did, or what did is really amazing.

  Are you sure? yes | no

Alastair Hewitt wrote 05/28/2021 at 20:43 point

Thanks! That's the only board... what you don't see is the software. That's where most of the magic happens :) The CPU is very minimal and uses a byte-code interpreter to run 8080 machine code. The GPU is really just a DMA controller. It uses the same pipelining as the CPU, but only one "ALU" operation to do a font lookup.

  Are you sure? yes | no

aldolo wrote 05/31/2021 at 12:01 point

I'm trying to understand also, but the schematics itself is not usefull at all to grasp the soul of this project...

  Are you sure? yes | no

Alastair Hewitt wrote 05/31/2021 at 16:52 point

The CPU and interfaces are all software defined so the schematic doesn't give much insight into how thing actually work. The logs cover most of the development details though. I'm planning on going back and explaining the virtual machine in more detail now I've finished that part of the development.

  Are you sure? yes | no

aldolo wrote 05/19/2021 at 19:49 point

an 8080 emulation in 3 dozens of ttl chips seems a bit optimistic

  Are you sure? yes | no

Alastair Hewitt wrote 05/20/2021 at 05:54 point

That number includes the video and audio hardware. The CPU proper is only 22 TTL chips, so the 8080 emulation is done in less than 2 dozen.

  Are you sure? yes | no

Marcel van Kervinck wrote 03/25/2020 at 17:11 point

Great name change!

  Are you sure? yes | no

monsonite wrote 11/05/2019 at 15:04 point

Hi Alastair, I stumbled across your project following on from a message from Marcel. Excellent work and very inspirational. I'm planning a 16-bit design based on a 4-bit bitslice design and video and sound will not be a high priority. I noticed that you mentioned overclocking the ROM. I hope to be using a AT7C1024-45 - have you any estimate of how fast that might clock?

  Are you sure? yes | no

Alastair Hewitt wrote 11/05/2019 at 18:14 point

Thanks for the follow! I've become less certain about overclocking... I'm routinely seeing the 55ns OTP ROM perform as fast as 12ns. That's actually causing issues because the pull up resistors on the bus are jumping high for 6ns during the CPU/GPU context switch. The ROM is so fast it sees that as a valid address (0xFFFF) and returns a value before then doing the actual look up. That means it's doing twice the work in a time window that was barely long enough to do one. This is slowing things down a bit and I need to solve that problem before I can get an idea about actual performance.

Saying that, this is what I found with the 70ns NOR flash. That was responding within 32ns, so more than twice as fast. But, there are certain addresses, or sequences, that take up to 50ns. You have to design around the worse case, so that would be the actual limit. Since then I've seen it slow down a little more and that number is closer to 55ns. I suspect that may have been caused by repeated flashing of the chip. The chip also slows down when it heats up and you can expect another 5ns at 50C. That brings it down to 60ns. That's still better than the 70, but not by much.

So you should do better than 45ns and may see actual speeds in 10-20ns range. I wouldn't get too carried away though since worse case may be closer to 40ns for reliable operation in all conditions.

  Are you sure? yes | no

Shrad wrote 12/14/2020 at 19:37 point

Just my two cents... why not use two interleaved ROM to double the rate? would be easier than any other solution and there should be a leftover flip-flop somewhere to clock them each at a turn...

  Are you sure? yes | no

Marcel van Kervinck wrote 08/18/2019 at 08:14 point

I wonder if your architecture would be classified as a barrel processor. Any thoughts on that? https://en.wikipedia.org/wiki/Barrel_processor

  Are you sure? yes | no

Alastair Hewitt wrote 08/18/2019 at 13:24 point

I was a bit generous when using the term "GPU". That part of the circuit is really a DMA controller running in transparent mode.

https://en.wikipedia.org/wiki/Direct_memory_access#Transparent_mode

The Harvard Architecture makes it fairly simple to implement since there's two address/data spaces. I'm able to use both concurrently with some pipelining. The same technique could be used to build a 2-core barrel processor. I assume you would have to replicate the CPU registers though.

  Are you sure? yes | no

Shranav Palakurthi wrote 05/15/2019 at 03:05 point

I want to see a retro computer with 128K RAM run JavaScript. (will it support Javascript?)

  Are you sure? yes | no

Alastair Hewitt wrote 05/15/2019 at 11:48 point

No plans to go anywhere near Javascript! It would probably run out of memory just downloading a single JS file from a typical web page. There are some minimal JS engines like Espruino out there, but even those would use up all ROM and leave no room for anything else.

  Are you sure? yes | no

Scott Devitt wrote 05/07/2019 at 13:12 point

I have one those black cases and would love to get a few more any clue from where?

  Are you sure? yes | no

Alastair Hewitt wrote 05/07/2019 at 14:32 point

It's a Polycase ZN-40. You can buy them direct - https://www.polycase.com/zn-40

  Are you sure? yes | no

Scott Devitt wrote 05/07/2019 at 13:10 point

Kinda off target but where did you find that black case. I have one and want a few more but not clue where to find it.

  Are you sure? yes | no

Marcel van Kervinck wrote 04/05/2019 at 16:23 point

When I was contemplating the ALU and other random control logic for what later became known as the Gigatron, for quite a while I considered abusing the 74x48 7-segment decoder to build an instruction set around. But it's a slow chip, and also I couldn't get the instruction set quite right. After that phase I realised I really needed a ROM, but ROMs are very slow and it wouldn't fit in the critical path of a 6-8 MHz design. So that's where the diode-ROM came in, because that's fast. Interestingly, that was today exactly 2 years ago https://hackaday.io/project/20781-gigatron-ttl-microcomputer/log/56640-testing-a-bunch-of-diodes . I'm interested in what ROM speed are you planning to use?

  Are you sure? yes | no

Alastair Hewitt wrote 04/05/2019 at 18:58 point

Hi Marcel, thanks for your interest. The Gigatron is the main inspiration for this project, especially your work on generating VGA with TTL chips.

I read your article on using the diodes a few weeks ago. I was a bit worried discrete diodes wouldn’t switch fast enough, but it looks like this will work. I’m doing most of my instruction decode using discrete logic: This includes 8 chips of gates, 3 decoder chips, and 2 flip flop chips for state machines. There is one area where I decode 8 possible states and I plan to use a "diode ROM" for this.

Both the ROM and RAM are accessed at half the VGA dot clock (12.5875 MHz). I need to switch between three different contexts for the ROM address bus: program, ALU, and font bitmap. I have to determine what state I want next and then latch this so everything changes on a single clock edge. I don’t have time to determine the state after the clock edge because it takes up to 12ns to change the bus tri-state. This leaves me with just 65ns to access the ROM then latch the result before the next context switch.

To deal with this timing issue I have to use memory with 55ns or better access speed. The only ROM with this speed is one-time programable. I’ll use this when I have code worthy of "shipping", but for now I’ll be doing development using NOR flash. The fastest DIP version is 70ns (e.g. GLS27SF020) so I’ll need to drop my clock speed a little. Worse case is a screen refresh at 50 Hz instead 60 Hz during development.

  Are you sure? yes | no

Marcel van Kervinck wrote 04/05/2019 at 20:57 point

Ah great. How about the references to an 128K ROM for ALU functions? I also saw a memory map of that, or is that "out" already? Anyway, take your time to reflect and document, if for no other reason than for yourself. I found those "boring documentation cleanup tasks" after a design frenzy helped to improve the end result. [BTW. This is probably a 3-level deep post without Reply button. Threading works best by going back 2 steps and reply from there....]

  Are you sure? yes | no

Alastair Hewitt wrote 04/06/2019 at 01:39 point

(jumping back 2 steps) The same ROM is used for the both the program and ALU. The CPU instructions take more than one cycle. For example: the first cycle reads the instruction from the ROM, the next cycle reads from the RAM, then the ROM is used as an ALU to perform a function, and finally the RAM can be written to. The ALU only handles one nibble at a time, so the last two cycles would be repeated to do a full 8-bit operation.

  Are you sure? yes | no

Marcel van Kervinck wrote 04/06/2019 at 09:47 point

Got it! Good luck with the build! One or two PCB, both have their tradeoff. The Gigatron is very sparsely populated with wide spacing. You might fit your design in a similar size, and the PCB costs aren't really that steep.

  Are you sure? yes | no

Alastair Hewitt wrote 05/31/2019 at 23:13 point

I finally ditched the diode ROM. I was able to juggle things around a bit and got it down to just 8 diodes configured as two 4-input AND gates. I decided to just add the additional chip and use a 74F21 instead. It's very fast with a Tp of just over 3 ns.

  Are you sure? yes | no

Geri wrote 03/08/2019 at 16:20 point

Hi, i following your projects and i am impressed with your works, especially the SUBLEQ implementation. I suggest you to try creating an FPGA based implementation to run my operating system: 

https://hackaday.io/project/158329-dawn-the-subleq-operating-system-by-geri 

Running this operating system will put you in the next league as this is a multitasking-multiwindowing, smp capable operating system, and creating a hardware thats capable to run something like that gives the followers magnitude bigger impression. The example emulators are attached in the zip file to guide you in the process. Feel free to contact me in e-mail for information if you dont understand something. 

greetings

Geri

  Are you sure? yes | no

agp.cooper wrote 03/07/2019 at 01:11 point

Great computer specification! Perhaps your are aiming a little too high for ~30 TTL chips?

---

Have a look at some of the other TTL designs on Hackaday to get an idea of specifications and chip count. You may be disappointed what others have achieved.

Have a look at the Apollo181 (http://apollo181.wixsite.com/apollo181/index) which has a 65 chip count and uses the 74181 ALU (yuck!) for an example of what can be done in 4 bit.

Its pretty impressive for 65 chips!

---

If you want something simpler (to get started) have a look at the TD4:

1) Breadboard version: https://www.youtube.com/watch?v=e0QCErIIOWA

2) ATMega 328p "ROM" version: https://www.youtube.com/watch?v=tKO3O2UY_7s

3) And a schematic: http://xyama.sakura.ne.jp/hp/4bitCPU_TD4.html

I have built the TD4 and have PCB designs on EasyEDA (https://easyeda.com/search?wd=td4b&indextype=projects), you can get them made and posted to you.

Regards AlanX

  Are you sure? yes | no

roelh wrote 03/06/2019 at 08:18 point

Hi Alastair !  I'm looking forward to your schematics and instruction set....  I have similar plans...

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates