Novasaur Retrocomputer

Retrocomputer with serial and video built from late 70's TTL logic

Public Chat
Similar projects worth following
Can you browse the Web using pre-1980 TTL logic and memory speeds? The goal of this project is to demonstrate how. Internet connectivity is via an era-appropriate RS232 interface. The machine is upward compatible by a decade to support currently available keyboard and video interfaces (PS/2 and VGA). The video includes a native text mode capable of displaying 80-columns and bitmapped color graphics for retro gaming.

Novasaur 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.
  • 128/512k RAM: 1-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: up to 4 voice wavetable synthesis, ADSR, 8-bit DAC, 8Hz-4.8kHz.
  • PS2 Keyboard interface built in.
  • RS232 Serial Port for host/client and network connectivity at 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 DC @ 2A (9W)

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 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 next byte in the program memory for immediate addressing, or to a lookup table for an ALU operation. The final cycle is the write cycle where a register is loaded with the execute 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). The average instruction takes 2.35 process cycles for a typical CPU speed of 3.5MIPS.

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


Schematic of main board for rev. 8 PCB

Adobe Portable Document Format - 856.97 kB - 10/10/2020 at 18:25



Font ROM rendered as a bitmapped image.

Portable Network Graphics (PNG) - 8.48 kB - 10/06/2020 at 00:16



Memory map of RAM and ROM address layout.

Portable Network Graphics (PNG) - 120.79 kB - 06/19/2020 at 16:42



3D render of Rev. 6 board from front

image/jpeg - 390.48 kB - 05/25/2020 at 01:45



3D render of Rev. 6 board from back

image/jpeg - 393.61 kB - 05/25/2020 at 01:45


View all 10 files

  • 14 × 74F574 Octal D-type Flip-flop with Tri-state Outputs
  • 4 × 74F541 Octal Buffers/Drivers with Tri-State Outputs
  • 4 × 74F163 Synchronous 4-Bit Binary Counter
  • 2 × 74F157 Quad 2-line to 1-line Multiplexers
  • 2 × 74ALS139 Dual 2-line to 4-line Decoders

View all 20 components

  • Roll-your-own SID Chip

    Alastair Hewitt10/07/2020 at 03:30 0 comments

    Audio testing is now complete. This includes both hardware updates and the software to generate the sound. Since the sound system is finalized this would be a good point to review all the gory details.


    To keep the hardware minimal, no registers are dedicated to the audio. Instead time is borrowed from the GPU's glyph (G) register during the horizontal blanking period. The GPU address registers (H and V) are left in tristate during blanking and pulled high to generate the address 0x0FFFF. This is the top byte of the zero page and reserved to store the next audio sample as a 7-bit signed number. The blanking period also aligns the ALU instead of the font ROM with a special audio function to remove the sign bit and create a DC-biased audio level.

    The audio DAC gets the full glyph signal during the active video period and the initial design attempted to use a sample and hold circuit to sample just the audio when blanking. This didn't do a good job of isolating the video signal and led to a lot of noise issues. The circuit was redesigned to the following:

    The new design uses the H-sync signal (blue trace below) to mute the DAC during the active period and then allow the audio signal (yellow trace below) to recover during the blanking. This presents pure PCM pulses to the audio filter stage rather than the typical step function. This isn't a problem since they both contain the same frequency domain information. The power level is a lot lower though, so a 20dB inverting amplifier is needed to bring the level up to the -10dBv line level.

    Prior to the amplifier are two filters: A second-order Sallen-Key low-pass filter followed by a passive high-pass filter. The high-pass cuts frequencies below 16Hz and the low-pass above 4.8kHz. This is the Nyquist corner frequency when generating audio at the standard 9.6kHz virtual process rate. The frequency response is shown below:


    The same method used by the Gigatron was shamelessly copied to generate the audio waveform here: A lookup table is used to map each note to a 16-bit value that is then added to a 16-bit counter register. The addition is done at a fixed sample rate such that the register counts to 65,536 at the frequency of the note being played. The upper 8 bits of this counter are then used to index another lookup table that contains a sample of a waveform. Multiple voices are generated by using additional 16-bit counters for different notes and adding the result of waveform lookups together.

    Two functions are included in the ALU to lookup the note by the MIDI value and return the high and low byte to use for the 16-bit counter register. The table goes from 0 to 127 for use with the non 60Hz VGA video mode, where full 88-key piano keyboard goes from 21 to 108. For 60Hz VGA the sample frequency is slightly different, so the table is duplicated for this frequency between 128 and 255. In both cases the entire 88-key piano frequency range can be played.


    The Gigatron is able to compute one voice per line during the horizontal sync period. The Novasaur requires up to 48 compute cycles to calculate each voice, which is longer than the entire virtual machine cycle containing the horizontal sync. The audio has to therefore consume additional machine cycles and is treated as an optional feature with the number of voices made configurable.

    The audio is handled by a non-blocking thread scheduled at the end of the first line in the virtual  process cycle. At least 2 virtual machine cycles are required if the audio is enabled and this can be extended by an additional cycle per voice up to a total of 4 cycles. The first two cycles provides the first melodic voice and an additional non-melodic voice that would typically generate a random noise signal. Each additional cycle adds a voice for up to 3 melodic voices in the VGA and SVGA video modes, or 2 voices in the XGA mode.

    The non-melodic voice uses the process line counter...

    Read more »

  • Lo-Fi

    Alastair Hewitt09/20/2020 at 22:01 0 comments

    After video came the audio testing. There was a known issue with a nasty 60Hz buzz breaking through in the audio channel. The last value in the glyph register shows up in the audio channel when the blanking period starts. This was assumed to be the cause of the buzz and the correct blanking during the front porch should take care of it. It turned out there was more to the issue than this...

    The audio DAC gets the full video signal during the active part of the video line. A sample and hold circuit is used to sample only the audio level during the horizontal blanking. However, there appears to be a significant parasitic capacitance associated with the DAC. This capacitance is charged up during the active video and then takes significantly longer than the front porch time to discharge. The result is an echo of the video signal in the audio channel, resulting in a periodic waveform at the frame rate of 60Hz.

    The solution was to add a muting circuit to the DAC. This is just a transistor that shorts the output of the DAC to ground during the active video.

    This worked so well that the sample and hold circuit was removed. The DAC now feeds the raw PCM pulses directly to the second-order low-pass filter section. The filter will need to be redesigned slightly to help filter out the increased high frequency harmonics and amplify the lower RMS level of the PCM signal. The following shows the current output of the DAC for an 880Hz sine wave:

    Note that the pulses come in groups of 4. The audio value is calculated once per virtual process cycle, but output once per line. The SVGA timing shown here has 4 lines per process cycle. The output wave (shown in blue) is via the existing filter design.

  • Classic VGA

    Alastair Hewitt09/14/2020 at 04:19 0 comments

    There was a completed version of the video system running a few months ago. Pretty much everything changed during the main software development and that also included the video modes. One change was to add the classic 60Hz VGA mode and allow even the ancient plasma TV rescued last year to understand the video timing.

    The image above shows the old TV displaying 104x60 of random text. This 104 column text is due to the dot clock being 33MHz, or 30% faster that the standard 25MHz VGA clock. This results in an additional 24 characters of text being output per line.

    So how is the classic VGA timing done?

    The original video modes used a process cycle of 4 lines of 5 virtual machine cycles. The virtual machine runs at 192kHz, so the horizontal frequency is 38.4kHz and close enough to support 75Hz VGA and 60Hz SVGA modes.

    The process cycle can be reconfigured to 5 lines of 4 virtual machine cycles. This results in the same block of 20 cycles and the serial compatible process cycle frequency of 9.6kHz. The horizontal frequency is now 48kHz and close enough to support 768-line video modes such as XGA.

    The new 60Hz VGA mode uses a configuration of 3 lines of 6 virtual machine cycles. There are some issues with this though. The process block is now 18 cycles and the process cycle frequency does not support a standard UART frequency, so not serial support. The horizontal frequency is also little high at 32kHz, but this can be fixed by adding a short delay to each line.

    The 60Hz VGA timing is determined by reseting the horizontal line every 262 cycles. The 6 virtual machine cycles add up to 258 (6 x 43), so an additional delay page is added before the horizontal sync page. The delay burns an additional 4 cycles to result in a horizontal frequency of 31.48855kHz (8.25MHz / 262). This is very close to the exact VGA horizontal frequency of 31.46875kHz.

    The frame is made up of 175 process cycles consisting of 3 lines each. This results in the exact 525 lines of the standard VGA mode and a vertical frequency of 59.98Hz. Again, this is very close to the VGA/NTSC standard of 59.94Hz.

  • Coding Complete

    Alastair Hewitt08/30/2020 at 01:18 0 comments

    Complete doesn't mean finished though! This was not like a modern iterative development process with small incremental changes as features were added and enhanced. The entire system had to be coded before all the dependancies were resolved. This took an entire year and there are still several weeks of testing ahead (and some inevitable updates).

    So what has been coded? Essentially the only program that will ever be written to run on this hardware. This is the firmware that forms the hardware abstract layer that all other programs will use to access the functions of the machine.

    There are two reasons for this approach. The first (and least significant) is the limited implementation of the Harvard Architecture: The system uses only one ROM and one RAM chip and there are two data data paths, one for program and other for data. It makes most sense to put the program in the ROM, so this means a new machine code program can not be loaded without reprograming the ROM.

    It is easy to add another RAM chip to the system and configure this as an additional bank of program memory. This solves the issue of not being able to load new machine code at run time, but there is a far more significant issue to consider: The main reason for not allowing a user to add their own machine code is to prevent a user's program from taking control of the CPU execution.

    If the system yields to a user's program then that program needs to be aware and responsible for all the critical real-time activities required to make the hardware work. The hardware provides the bare minimum to support the electrical interfaces for things like audio, video, and serial communications. The software is responsible for all the timing and state for these interfaces. An interrupt mechanism could be employed, but this is impractical with horizontal video timings running as fast as 48kHz.

    The way to keep the system simple is to use a byte code interpreter to execute the user's program. This does have a significant performance impact but there is plenty of room to extend the interpreter with fast native functions for common activities. A big advantage of the interpreter is the ability to provide binary compatibility with an existing processor like the 8080. This makes it easy to port things like CP/M to the platform.

    A lot of the firmware features have been discussed in previous logs during their development. A few things have changed as the final pieces came together, so these will be expanded on in later logs. For now this is a quick summary of the final firmware: The base system consists of 120 pages containing over 5,000 assembly instructions (not including 900 NOP instructions to pad timing). This code operates 10 non-blocking threads to control: horizontal video timing, vertical video timing, PS/2 keyboard scan, realtime clock, serial I/O sampling, RS232 transmit, RS232 receive, wavetable synthesizer, maskable interrupts, and byte-code interpreter.

  • Rev. 6

    Alastair Hewitt08/13/2020 at 19:44 0 comments

    The hardware abstraction layer development has taken an entire year and is finally nearing completion (final details in an upcoming log). In the meantime there were some minor updates to the hardware, some of which were discussed in the last log. This resulted in the rev. 6 board shown below:

    It was time to do a more detailed thermal analysis to make sure this hungry beast will not overheat. The F-series TTL chips consume about 5mW per gate and the 1,425 gates making up the Novasaur dissipate close to 7.5W. The regulator also dissipates up to 1.5W for a total power consumption of 9W.

    The plan is to have a sealed enclosure, so no ventilation holes. The components are cooled by radiating heat that is absorbed by the case. The case then radiates this heat to the environment until it reaches a thermal equilibrium. At this point the temperature is stable and the best way to measure this is via a thermal imaging camera.

    A budget camera was obtained and some initial measurements made. The picture on the left is the external case temperature after running for about an hour at 21C ambient. The picture on the right is with the cover removed showing the circuit board.

    There is a hot spot reading around 41.5C from the outside of the case and 62.5C from the inside. This area is centered around the B, X, and Y registers. The B register is the pipeline between the data and program address space and clocked at 16.5MHz. Both the X and Y register have pull-up resistors and are cycled at a similar rate. Together these three chips represent the highest heat density on the board.

    There is a second hot spot over the regulator shown in the left picture below (the H shape towards the bottom is the heatsink). The spot above that is the PAL, which also runs quite hot. It's interesting to note that the regulator is slightly cooler at 60C than the hottest chips.

    For comparison the picture on the right shows a hot spot on the 6V power adapter case. This had a temperature of 49C, which was several degrees above the Novasaur case.

    Note: These were just some initial pictures and more accurate and detailed images are planned. The emissivity was the default 0.95, but it is probably more accurate at around 0.90.

  • Video DAC

    Alastair Hewitt07/04/2020 at 04:30 0 comments

    It's been a month since the last log, so I thought I'd check in. Other priorities have taken over a bit so I'll cover one minor change that was made to the PCB design. This started with an examination of the Video DAC placement to see if the current VGA connector could be changed.

    The original PCB design used a low-profile VGA connector due to space constraints. Not only did this cost 2.5x as much, but the only distributor was out of stock for 4 months. This is a big risk for a kit version, so the change was made to fit the more common larger-sized connector.

    The original video DAC had to be moved and it was a good chance to re-examine the design. Calculating the resistor values for the DAC gets quite complicated, so in the end it was just easier to simulate the circuit and play with it.

    The circuit above shows the channels of a 3-bit DAC with resistors used to divide down each bit by a factor of two. The analog switch has a fairly large on resistance shown as a 150 ohm load in series with a transmission line to the monitor load of 75 ohms. The state shown in the circuit is with the most-significant bit high and the other two bits low. Low does not mean off, these other outputs are sinking current in their low state.

    The circuit assumes a high voltage of 3.2V and a low voltage of 0.3V. The 150 ohm resistance of the switch comes from the data sheet for the CD4053 being driven with a VCC-VEE voltage of 10V (the negative VEE is supplied by the RS232 driver).

    There are a couple of drawbacks with this simple DAC design. Since the low voltage is never 0V then there is no completely black color, only very dark gray. Since the blue channel is only two bits it varies from 0-3, where the red and green vary from 0-7. Seven doesn't divide into three, so there are no actual gray colors.

    The on resistance of the analog switch also changes as the chip warms up. The resistance could change by up to 20% from an initial 150 ohms at 25C to 180 ohms at 60C. The following color palettes were generated from the simulation to show the difference between 150, 165, and 180 ohms:

    The difference is fairly subtle, so the temperature change shouldn't be too noticeable. For comparison, this would be the ideal palette with the correct DAC voltages:

    There are no resistors used with the 8-color text "DAC". Each bit is passed directly to the analog switch, which when combined with the monitor load divides the voltage by 3.2. This gives a value of about 0.1V for low and 1V for high. The text mode will always saturate the color, but also never be completely black.

  • Interrupts

    Alastair Hewitt06/04/2020 at 21:06 0 comments

    The 8080 development has been extended to support most of the additional features found in the 8085. This includes four of the five hardware interrupts. This is possible because the lower nibble of the Ei register is available via the expansion header. A buffer controlled by the ~EOE signal can be used to read the interrupts as shown.

    Software Interrupt

    The 8080 provides eight software interrupts via the RST 0 through RST 7 instructions. These will jump to the vector n * 8, where n is the number after the RST. The virtual CPU executes these interrupts using the code rst.nsa followed by restart.nsa. The first single-cycle RST instruction will increment the program counter, load the temp register with the lower 8-bits of the reset vector, and then rewrite the instruction to RESTART. The two-cycle restart instruction will push the program counter on to the stack, clear the upper program counter byte, and then copy the reset vector from the temp register to the lower program counter byte. The instruction at the new program counter address is then fetched and the instruction cache updated.

    The original Micro-Soft Altair BASIC 3.2 used the RST instructions to call common subroutines. This was primarily to reduce program size since this is a single byte instruction rather than the typical 3-byte CALL which must specify the 16-bit subroutine address.

    Hardware Interrupt

    The 8080 provides one hardware interrupt via the INTR input. This is enabled via the EI instruction and disabled via the DI instruction. The 8085 adds an additional four interrupts: RST5.5, RST6.5, RST7.5, and TRAP. The TRAP interrupt is non-maskable and used to initiate things like a power shutdown. A client of the hardware abstraction layer (HAL) would not have this level of privilege, so this interrupt is not implemented.

    The first three interrupts act like the RST instructions, except they are offset by an additional 4 bytes, so RST5.5 is the vector 5.5 * 8. The INTR interrupt will read the value of the I0 register and use this as a vector into the zero page. This could be set according to some external state to control the program flow.

    An interrupt can only take effect during the fetch cycle, but the current fetch cycle does not have enough cycles to handle the interrupt mask. The solution is to treat the interrupts as another feature of the HAL and control them via the feature flag IMODE.

    The IMODE flag is set at the beginning of the virtual process cycle if the interrupts are enabled. The fetch cycle checks the IMODE flag and if set will fork from the standard fetch operation. In this case the IMODE flag is reset and the INTR1 instruction is written to the instruction cache. This instruction is executed in the next machine cycle and applies a mask to the Ei register to see if any of the unmasked interrupts are set. If an interrupt is set then the associated vector is written to the temp register and the RESTART instruction is rewritten to the cache. If the interrupts are clear then the fetch cycle is completed and next instruction written to the cache.

    This way the interrupts are checked once per virtual process cycle at the expense of one virtual machine cycle. Most applications would not use the interrupts and the IMODE flag would not be set. In this case there would be no impact on the virtual CPU performance.


    The SIM instruction sets an interrupt mask based on the contents of the accumulator. The lower 3 bits (0-2) will mask the RST5.5RST6.5, and RST7.5 interrupts respectively (when set high). Bit 3 represents the interrupt enable state, so will have the same effect as calling DI if set low and EI if set high. There is no additional mask for INTR, so it is always active when the interrupts are enabled.

    The RIM instruction reads the current interrupt mask and stores it in the lower nibble of the accumulator. Meanwhile the current value of the interrupts is stored in the upper...

    Read more »

  • Serial IO and the vUART

    Alastair Hewitt05/24/2020 at 03:34 0 comments

    There are two serial ports and only their physical interfaces are implemented in hardware. This means everything above layer one has to handled by software in realtime. There's no shift registers to hand off parallel data, only single bits in the Ei and Eo registers for the data, control, and clock signals.


    Along with the video timing and wavetable synthesizer, the hardware abstraction layer also implements a virtual UART (vUART). This is also an optional feature and is controlled in a similar way to the audio using a serial mode.

    ModeInterfaceVMCsCPUEo bits
    -1None0100% xxx10xxx
    0PS/20.199% xxx11xxx
    1RS-2321.987% xxx0Dxxx

    Note that the vUART only handles one type of interface at a time. This is possible because both interfaces implement hardware flow control: The RS-232 uses RTS/CTS flow control and the PS/2 interface can be inhibited by grounded the clock via a DTL open-collector NAND gate (shown above).

    The PS/2 device (in this case keyboard) is required to buffer data while the clock input is grounded. The fastest typist might get to 15 keystroke per seconds, so there's no need to scan the keyboard faster than that. The slowest PS/2 clock would be 10kHz and a make/break key stroke sequence would require 33 bits of data. This would only require a 5% duty cycle (33/667) for the keyboard to keep up.

    The rest of the time can be used for the RS-232 interface. This runs at the same speed as the virtual process cycle, so around 9600 baud. The serial link would need to be interrupted after about 600 cycles to scan the keyboard, limiting the longest sequence of data to around 64 bytes. Sine the keyboard is scanned 15 times per second, then the maximum data rate is 960 bytes/second.


    The clock synchronization is handled through sampling and state machines. The maximum clock speed for the PS/2 interface is 16.7kHz, placing the Nyquist frequency at 33.3kHz. This is close to the horizontal scan frequency of 38.4kHz and it makes sense to sample the serial ports during the horizontal sync period. This sampling takes place regardless of the serial mode and is just part of the fixed overhead making up the sync cycle.

    A custom ALU function is used to sample the serial ports and drive a state machine. The ports appear on the upper 8 bits of the Ei register and the state machine uses a single byte stored in the zero page. There are two ports, so the state machine byte is broken in to two nibbles (since they are independent variables). Each state machine nibble is further broken down as two 2-bit components: State (4 possible values) and Data (up to 2 bits). The state and data values are updated on each line of the process cycle

    The state machine of the PS/2 interface is driven by the PS/2 clock input. This can count up to 4 transitions of the clock value, or two complete clock cycles. This would be the most transitions possible within a singe process cycle and the result would be two bits of data received. The two data bits act as a shift register and the next PS/2 data bit will be sampled on the high to low PS/2 clock transition. The number of bits received can be determined by looking at the state before and after the process cycle. Either 0, 1 or 2 bits are received and this data is then shifted in to a larger register for processing during the keyboard scan cycle.

    The state machine for the RS-232 port is changed on every line, for up to 4 lines. This state is used to determine when to sample the RX data during the process cycle. The two data bits store the previous value of the RX line and the final sampled value of RX. The problem to solve here is the potential drift in the data transition due to the clocks being slightly different. The state is reset to 0 when the RX value changes from the previous to the current value. The value of the RX input is sampled when the state machine reached 2. This way the sample is made approximately half way between the implied baud-rate clock edge.


    Read more »

  • Wavetable Synthesis

    Alastair Hewitt05/20/2020 at 00:10 0 comments

    Development moved back to the hardware abstraction layer to finalize the timing and resource requirements for the audio and serial features. Added to this was hardware interrupt handling for the virtual CPU. Most of the interrupt handling of the 8085 should be achievable, but more on this in another log.

    The coding for the virtual sound chip is now complete and the design is based around a wavetable synthesizer. This is a somewhat basic version, but it was easy to implement given the design of the ALU and spare operation freed up by eliminating SUB (subtract).

    The new operation (WAV) consists of two cycles: The first cycle takes an index from 0-255 and looks up one of 16 waveforms. This waveform is encoded as 8-bit signed integers to return the amplitude of the wave at the index. The second cycle attenuates the wave amplitude by one of 16 possible values. These range from -12 to -42dB in 2dB steps. This takes the 8-bit waveform and reduces it to a maximum of 6-bits (42dB dynamic range). A DC offset is added so the final result varies from 0 to 63. Up to 4 of these waves can be mixed using the ADD operation on the audio register.

    Another function is used with the synthesizer to load a 16-bit value for each note indexed by their MIDI value. This value is added to a 16 register in the zero-page at the 9593Hz process speed. The highest reproducible note is D8, two semitones above the top of the piano scale at 4.7kHz. Anything above this frequency will result in alias distortion. This not only includes the fundamental frequency of notes above this range, but also many of the harmonics of notes much lower in the range.

    The wavetable serves two purposes: The table contains the classic square, sawtooth, triangle, and some noise waveforms. There is also room in the wavetable to include morphed versions between these classic waves that can be swept from one to the other. This can be done via an envelope, low-frequency oscillator, or both (matrix modulation). The second purpose of the wavetable relates to the issue of aliasing. The table can be swept towards a pure sine-wave by progressively dropping the higher harmonics. Higher frequency notes would only migrate to this band-limited area to prevent inharmonic aliasing.

    Sawtooth wave with a 42dB dynamic range up to the 15th harmonic

    The gain-control part of the synthesizer is used to adjust the amplitude of the wave. This would typically follow an ADSR envelope to give a natural musical quality to the notes played. The same envelope can be applied to the wavetable wave selection to dynamically change the harmonic content of the wave. This produces a similar effect to a voltage-controlled filter in an analog synthesizer.

    The envelope and LFO values change quite slowly and these could be controlled by the virtual CPU. Predefined envelops could be automatically applied by simply indexing a table on every frame with minimal cost. The wavetable index needs to be calculated on every virtual process cycle though and this has a more significant cost. Because of this the number of voices can be selected from 0-3 by selecting one of 4 audio modes:

    000100%audio off
    11 + noise287%
    22 + noise380%
    33 + noise473%entire line

    The table shows the audio modes, the number of voices, and the number of virtual machine cycles (VMCs) needed to implement those voices. The CPU column shows the impact of supporting these voices in terms of CPU performance. The additional noise channel is an unvoiced audio source used with a noise waveform. This can be modulated using the envelope to generate percussive sounds and sound effects.

  • RAM Disk

    Alastair Hewitt05/11/2020 at 02:43 0 comments

    Just as productivity picks up I decide to wander off on some tangents. Such are the joys of a no-deadline hobby project :)

    First up was the reset button. This was super handy when the hardware and software were still in an embryonic state, but the final board will not need one. The user works within the virtual machine and the design prevents the user from changing the underlying state. This means there is no way for the user to crash the computer. The user could crash the operating system, but the hardware abstraction layer will continue to run and the keyboard will still work. A handy ctrl-alt-del can be used to force a reboot.

    The reset button has now be changed to a power switch. The regulator has a shutdown pin that the power switch uses shut the power off to the board. One issue is the size of the toggle button: The switch is too long to fit in front of the mounting hole where the old reset button was positioned. A slight reshuffle and the power switch can be placed next to the mounting hole, freeing up all the space left by the old reset button.

    This same change was made on the other side of the board to free up enough space to fit two banks of super-capacitors. These provide power to the CMOS memory chip at around 10 days per farad. The plan is to use 2F capacitors for up to 3 weeks of backup, but there's room to fit 3F capacitors for up to 1 month of backup.

    The primary reason for the power backup is to give the impression of persistent storage. Most of the banked RAM will be used to create a single RAM disk for a CP/M operating system. This disk will be the primary persistent storage as long as the machine is used on a regular-ish basis. An FTDI serial cable (RS232-to-USB) can be used to back things up for longer term storage.

View all 60 project logs

Enjoy this project?



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

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?

  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.

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 -

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

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. 



  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 ( 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:

2) ATMega 328p "ROM" version:

3) And a schematic:

I have built the TD4 and have PCB designs on EasyEDA (, 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

Does this project spark your interest?

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