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.

rom-r0_3.hex

v0.3 ROM image - boots to 8080 system monitor in 75Hz VGA (80x30) text mode with serial enabled. Burn NOR flash on TL866 using: minipro -p "SST39SF020A" -w "build/output/rom.hex" -f ihex

hex - 600.28 kB - 03/24/2022 at 13:48

Download

pcb-silkscreen-rev-a.pdf

Silkscreen for Rev.A PCB

Adobe Portable Document Format - 87.32 kB - 03/15/2022 at 01:24

Preview
Download

schematic.v1.10.pdf

Schematic for release (rev. A) PCB

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

Preview
Download

novasaur.jed

PAL JEDEC file

jed - 6.29 kB - 08/11/2021 at 02:11

Download

instructions.pdf

Instruction Encoding

Adobe Portable Document Format - 124.78 kB - 08/11/2021 at 02:10

Preview
Download

View all 9 files

  • A Slight Detour

    Alastair Hewitt07/08/2022 at 21:28 1 comment

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

  • Problem Solved

    Alastair Hewitt03/19/2022 at 02:21 0 comments

    After many weeks of detailed investigation... the "bug" with the ED command has been resolved!

    I know there are not many fans of ED, but it appears to be so unloved that no one has noticed that a copy shipped with certain CP/M 2.2 distros is actually corrupted. Perhaps this is what you get for trusting garbage scraped off a 40-year old 8" floppy that was uploaded to the Internet. Arrrggg!!

    There are still issues with Altair BASIC... but this was OCRed from a listing of dubious origin found at the back of an old manual. I'm willing to guess my 8080 virtual machine is not the culprit for this buggy mess either.

    To be continued....

  • Three Years Later

    Alastair Hewitt02/21/2022 at 22:27 0 comments

    In keeping with the first and second year updates... here is year three! Normally it is a look ahead at the next phase of development, but things are pretty much complete at this point.

    There is an outstanding issue causing a crash when running the ed command in CP/M and not much progress has been made in tracking that down yet. Enough of CP/M is working to run some of the existing CPU compatibility testers out there and these helped clear up the last remaining bugs. Unfortunately the ed problem persists, so there's something more to this than just the 8080 interpreter.

    Sound Instructions

    After no progress on the remaining bug the gears were switched to add some extended instructions to control the sound features of the platform (the plan is to also add some extended graphics instructions to plot points and draw lines natively).

    There are 16 new extended instructions as follows:

    Config Voice

    Four 3-cycle instructions are used to configure each of the 4 voices with the following 8080 registers:

    • A - Waveform
      • 0 - sine
      • 1 - sawtooth
      • 2 - square
      • 15 - noise
    • BC - Attack (0-15) and Decay (0-15)
    • DE - Sustain (0-15) and Release (0-15)

    Set Note

    Three 2-cycle instructions are used to set the note for voices 1-3 using the 8080 accumulator:

    • A - MIDI Note Number (0-127. +128 for 60Hz VGA video timing)

    This instruction will also update the specific version of the sawtooth and square waves to band limit the harmonics for the note frequency and prevent aliasing.

    Since the frequency of voice 0 is fixed at the vertical video frequency, the instruction that would represent this note is used to control the level of voice 3. This is needed when using 60Hz video modes since the ADSR for the 3rd voice is only updated in the 75Hz VGA mode.

    Gate On/Off

    Eight 1-cycle instructions are used to gate each voice on and off. Gate on will start the attack/decay to the preset sustain level. Gate off will release the note back to zero.

    PCM Playback

    A new feature was also added to the audio thread to play back PCM samples. The sampled data is stored in bank zero and played back by specifying the start and stop page of the sample data. The sample size is capped at 32k to leave the other half of the memory for the display.

    The simplest playback method is to write one byte per block to the audio register. This is a sample resolution of 8 bits at a rate of 9,593bps giving a bandwidth of around 4.8kHz. This is definitely not CD quality, but that rate is still fairly fast and 32k will only provide 3.4 seconds of playback.

    A couple of other schemes can be used to increase the playback time: Halving the sample rate and companding. Half rate skips every other block to drop the sample rate to 4797bps with a somewhat underwater sounding 2.4kHz bandwidth.

    The companding method (shown below) stores the log of the 8-bit sample as 3 bits plus a sign bit. This also halves the storage requirements as each sample takes up just one nibble. Combining these two schemes gives a maximum playback of 13.66 seconds for 32k of data.

    log: rounded  :  range
    ...:..........:.........
    -8 : 10000000 : -80..-41
    -7 : 11000000 : -40..-21
    -6 : 11100000 : -20..-11
    -5 : 11110000 : -10..-09
    -4 : 11111000 : -08..-05
    -3 : 11111100 : -04..-03
    -2 : 11111110 : -02
    -1 : 11111111 : -01
     0 : 00000000 :  00
     1 : 00000001 :  01
     2 : 00000011 :  02..03
     3 : 00000111 :  04..07
     4 : 00001111 :  08..0F
     5 : 00011111 :  10..1F
     6 : 00111111 :  20..3F
     7 : 01111111 :  40..7F

    The PCM playback is handled as a separate audio mode and the various playback schemes are added as an additional four audio modes. The complete list of modes is as follows:

    • 0 - mute
    • 1 - 1+1 voices
    • 2 - 2+1 voices
    • 3 - 3+1 voices
    • 4 - 8-bit PCM @ 9.6kbps - 9.37kB/s -  3.42s playback -  27ms per sample
    • 5 - 4-bit PCM @ 9.6kbps - 4.68kB/s -  6.83s playback -  53ms per sample
    • 6 - 8-bit PCM @ 4.8kbps - 4.68kB/s -  6.83s playback -  53ms per sample
    • 7 - 4-bit PCM @ 4.8kbps - 2.34kB/s - 13.66s...
    Read more »

  • Kits are coming...

    Alastair Hewitt01/10/2022 at 05:10 4 comments

    The first batch of Rev A boards have arrived. This may sounds like the first revision, but the revisions are being counted in hex, so "A" is actually the 10th! It's almost identical to Rev 9. except for a larger regulator and some ESD protection on the VGA circuit. These were the final updates before the board was ready for public release in a kit.

    A prototype of the new board was tested this weekend and passed all the stress tests. There are parts on hand to build two more kits, but like many projects there are growing issues with sourcing more components.

    One example is the ROM. The only available part that meets the timing specifications is the AT27C020-55PU. These have more than doubled in price since the start of the project and are now out of stock with a 65 week lead time. Luckily is appears the NOR flash used during development works fine at 55ns even though it is rated at 70ns. The plan is to use this for the kit.

    Some of the other parts were at risk, so initial orders have been placed for these. The rest of the parts should be available when needed for a total production of 100 kits during 2022. The plan is to release an initial batch of 20 beta kits in Q2. These will likely be just the basic board-only kit to keep the cost down and come with limited documentation. The full kit should be available in the second half of the year with enclosure and full documentation.

    Software debug is progressing well. The B: drive has been set up and the CP/M utilities are being tested. Most things are working (like STAT shown below) but ED is crashing for some reason. Software development should be wrapped up within the next few weeks for the beta kit release.

  • CP/M is Running!

    Alastair Hewitt12/30/2021 at 20:14 0 comments

    An unofficial goal of 2021 was to get CP/M 2.2 running on the Novasaur. I'm close enough to officially claim that goal had been achieved... with less than 48 hours to go!

    This isn't the final configuration though; CP/M is running alongside the kernel on CPU 1 and is started by calling the CCP at 0xE200. This is temporary since the goal is to have CP/M run in its own CPU instance. In fact, the plan is to have two instances of CP/M running: One with console IO and the other with serial IO.

    For now the initial BIOS development is being done alongside the kernel and system monitor for debugging. That debugging took the vast majority of the time, but ironically not as part of the BIOS development.

    There were still a few bugs in the 8080 virtual machine. Not every instruction is being used by the monitor so there were still a few that were not fully tested. These caused some strange behavior in CP/M and proved very challenging to identify. The fixes were usually simple, but figuring out what was broken involved extensive reverse-engineering of the CP/M BDOS and CCP.

    There are a couple of minor issues remaining: Saving large files can result in an error and if an invalid disk is selected the system gets stuck with that invalid disk selected (as can be seen above). These should be fixable with some additional error handling in the BIOS though.

    Only the A: drive is working right now, so the next stage of development is to add the B: drive. This is a read-only drive mapped to the 64k cold-storage area of the ROM. The plan is to store the following CP/M tools and utilities there:

    • CPM.SYS (6k) - CCP/BDOS/BIOS (loaded by boot loader).
    • STAT (6k) - Lists the number of bytes of storage.
    • ASM (8k) - Loads the CP/M assembler and assembles.
    • DDT (5k) - Loads the CP/M debugger into TPA and starts execution.
    • PIP (8k) - Loads the Peripheral Interchange Program.
    • LOAD (2k) - Loads command from Intel HEX machine code format file.
    • DUMP (1k) - Dumps the contents of a file in hex.
    • SUBMIT (2k) - Submits a file of commands for batch processing.
    • XSUB (1k) - Extension to submit command.
    • ED (7k) - Loads and executes the CP/M text editor program.
    • MBASIC (8k) - Microsoft BASIC-80 for CP/M 
    • XMODEM (5k) - Used for File transfer over serial.

    The example above shows the B: drive being selected, but this currently maps to the A: drive with the same directory. This directory is shown below by using Kernel GET commands to copy the first six records from the A: drive to the memory locations 0x0100-0x03FF.

    This example shows several test files created using the CCP's SAVE command. The speed to save data was measured at around 6k bytes per second, so the largest file would take up to 10 seconds to save to the disk. Not that fast by today's standards, but perfectly reasonable for the late 70's!

  • A: Drive

    Alastair Hewitt11/18/2021 at 04:06 0 comments

    The A: drive has 63 tracks across 4 quadrants. Each quadrant has 8 sectors making up a total of 32 sectors per track. The record size is 128 bytes for a total of 252k bytes (63*32*128). The first 2k is used for the disk directory leaving 250k available for storage.

    The decision was made a while ago to use a RAM disk and a detailed design was discussed earlier this year. It's taken about 6 months to develop the code and get it working (amongst other things). The net result is the initial version of the micro kernel weighing in at a whopping 160 bytes of 8080 machine code!

    :20F000003A80E8B7C0ED06AF3CE607CA00F03281E8DD09B7C208F079FE04D205F0FE01DA45
    :20F0200005F0CA2BF02190F0F240F02141003A81E8CD4CF07EB7CA05F0360023E52198F04A
    :20F04000D5875F1600195E2356EBD1E9C6E8677887876FC97B0F0F0FE603F604C9CD54F012
    :20F06000DD08B7CA05F0CD4CF036023A81E82377C305F0E16E3A81E8677DED0BDD07C30585
    :20F08000F03A81E867CD54F06FED0BDD08C305F005F005F05DF081F005F005F073F005F077

    This initial kernel supports two operations: GET to read a record from the drive, and PUT to write a record to the drive. The record is specified using the DE register to represent the track (D register) and sector (E register). The most significant 2 bits of the sector are used by the kernel to determine a quadrant. Each quadrant is assigned to one of 4 virtual CPUs, each with its own 64k of RAM. 

    Each of the quadrant CPUs run a program to respond to commands from the kernel and read/write records from the memory it manages. The following code maps the track/sector in DE to the memory location:

        MOV     A,D     ;A=00TTTTTT
        CPI     63
        JNC     WAIT    ;SKIP TRACKS>62
        MOV     A,E     ;A=000QQSSS - 4 QUADS OF 8 SECTORS
        RRC             ;A=S000QQSS
        RRC             ;A=SS000QQS
        RRC             ;A=SSS000QQ
        ANI     0E0H    ;A=SSS00000 - CLEAR QUAD
        MOV     E,A
        XCHG            ;HL=00TTTTTTSSS00000
        DAD     H       ;HL=0TTTTTTSSS000000
        DAD     H       ;HL=TTTTTTSSS0000000
        INR     H       ;HL+0000000100000000
        PUSH    H       ;SAVE HL

    The current software still boots to the monitor program, but the monitor can now set a break point and call the kernel code to allow records to be read and written to the A: drive. The next step is to add some kernel commands for console input and output and plumb everything through with a CP/M BIOS.

    The assembler code for the operating system can be found here: https://github.com/ajhewitt/novasaur/tree/master/src/os

View all 81 project logs

Enjoy this project?

Share

Discussions

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