Close
0%
0%

Novasaur Retrocomputer

Retrocomputer with serial and video built from only 1978-era TTL logic

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 two bitmapped color graphics modes 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, 50k display, 14k shared.
  • 76 ALU functions including multiply/divide, system and math functions.
  • Bitmapped Graphics: Up to 320x256 Hi-res mode with 8 colors and 4 dithering patterns. Lo-res mode up to 160x256 with 256 colors, or 160x128 double buffered.
  • Text Mode: 8 colors FG/BG, 256 line buffer, up to 80x75 using 8x8 glyph text, up tp 80x48 rows using 8x16 glyph text.
  • 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 (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 112 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 an interpreter offering binary compatibility with the Intel 8080/5.

memory-map.v1.5.png

Memory map of RAM and ROM address layout.

Portable Network Graphics (PNG) - 121.56 kB - 05/29/2020 at 02:21

Preview
Download

novasaur-front.jpg

3D render of Rev. 6 board from front

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

Preview
Download

novasaur-back.jpg

3D render of Rev. 6 board from back

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

Preview
Download

novasaur-bottom.jpg

3D render of Rev. 6 board from below

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

Preview
Download

schematic.v1.6.pdf

Schematic of main board for rev. 6 PCB

application/pdf - 844.98 kB - 03/31/2020 at 15:13

Preview
Download

View all 10 files

  • 14 × 74F574 Octal D-type Flip-flop with Tri-state Outputs
  • 4 × 74F541 Octal Buffers/Drivers with Tri-State Outputs
  • 1 × 74F138 3-line to 8-line Decoders
  • 1 × 74F244 Octal Buffers with Tri-State Outputs
  • 1 × 74F175 Quad D-type Flip-flop with Clear

View all 20 components

  • Serial IO and the vUART

    Alastair Hewitt5 days ago 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.

    Modes

    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
    0None0100% xxx10xxx
    1PS/20.199% xxx11xxx
    2RS-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.

    Receive

    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.

    Transmit...

    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 (WTS) 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.

    The other function used with the synthesizer is in the audio/video timing (AVT) operation. This contains the 16-bit values needed to step through at 9.6Hz in order to cover each semitone in the full MIDI scale. 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 final feature of the synth provides something similar to a voltage-controlled oscillator (LFO). Additional tables in the AVT operation are available and can store micro-tonal versions of the standard notes. These can be used to sweep the frequency of the note up and down using a low-frequency wave. This same wave can also be used to also change the wavetable selection.

    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:

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

    Read more »

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

  • Intel 8080

    Alastair Hewitt04/21/2020 at 16:01 0 comments

    On the recommendation of @Marcel van Kervinck I took another look at emulating an Intel-based CPU. I was scared off initially by the complexity of the Z80, but the base 8080 instructions are fairly manageable. The initial work on the COSMAC was useful in figuring out how to approach the development of a virtual CPU, but the decision was made to abandon the COSMAC and focus on the 8080.

    Given the state of things these days, I was able to complete the development in only 4 weeks. It's still far from done though. Although the code is complete (almost 80 pages) none of it has been tested and there is currently no reasonable way to do this. The code will need unit tests and this involves building some form of simulator to verify the instructions work correctly.

    Another consideration is the video memory. The COSMAC had many index registers and the lower few are reserved hardware-specific tasks like DMA and interrupt handling. These weren't needed, so these registers were targeted to the video memory bank. This is not possible with the 8080, so an alternative approach is needed. The current idea is to partially implement the Z80 IX and IY registers and use these to address the video RAM. These wouldn't need to support the actual Z80 instructions though, so there is plenty of room for customization.

    Some initial performance numbers can be calculated based on the implementation. The virtual 8080 will operate with an equivalent clock speed around 450kHz or about 60kIPS. This is about 22% the speed of the original 2MHz 8080, or about 15% of the 3MHz 8080A/8085 version. The underlying hardware runs at 8.25MHz, so it takes about 137 CPU clock cycles to execute a singe vCPU instruction (this includes the video control and sync overheads).

  • Arithmetic Operations

    Alastair Hewitt04/10/2020 at 03:36 0 comments

    The hardware is complete and now collects dust as the firmware development grinds on. The virtual CPU is taking shape and lots of interesting problems are getting solved. One of the major hurdles is building out a functional ALU. The current hardware really doesn't have one, but can utilize lookup tables in the ROM to perform arithmetic operations.

    One example is addition. The ROM can be used to add two 8-bits value to produce an 8-bit sum. The easiest way to do this is with a 256x256 table to store the 65,536 possible values (64k bytes). This is a lot of memory though, so the problem is broken down in to two steps using two 256x16 tables (4k bytes each). The first table takes a full 8-bit value and adds the lower nibble. The second table takes the result of the first step and adds the upper nibble.

    example: 19 + 28
      19
       8 +
     ---
      27
      2  +
     ---
      47

    Both methods have a major flaw though. The ROM produces an 8-bit result, but adding two 8-bit values results in a 9-bit value; there is no carry from the ROM lookup table. The carry is an important component of any ALU, not only a carry out, but also a carry in to allow the chaining of arithmetic operations. Other flags are also useful, such as an overflow to indicate a carry from a signed addition, a zero flag to indicate if the result was zero, etc. The only flag the ROM table can produce is the negative flag, since it is the most-significant bit of the result. This is therefore the only flag available for performing conditional logic.

    The negative flag can be used to determine the carry by looking at the before and after state of the addition. This takes a lot of cycles and complicates things. The solution is to add another pair of tables to the ROM to create the Arithmetic Flag (AF) operation. This is a little more complex than it sounds due to the way the nibble cycles work. The first cycle returns the flags of adding the two lower nibbles: These include the carry and borrow from adding/subtracting the first 4 bits and a zero and parity flag for the first 4 bits of the result. The second table completes the flag operation using the initial 4 flags and processing the upper nibbles.

    To find the flags, the AF operation proceeds an ADD operation to generate the following:

    Flag bits - CNZPHOBL
    C - Carry (from bit 7)
    N - Negative (sign of result)
    Z - Zero (high if result is 0)
    P - Parity (parity of result)
    H - Half carry (carry from bit 3)
    O - Overflow (carry from bit 6)
    B - Borrow (from bit 7 if subtraction)
    L - Low borrow (from bit 3 if subtraction)
    

    The original SUB operation was removed to make room for AF leaving ADD as the only byte-wide arithmetic operation in the ROM. Subtractions can still be done by using the 2COM function (in the default set of unary operations) to negate the value being added. An additional pair of flags indicate if there was a borrow from the equivalent subtraction. 

    The final problem is the carry in. There's no easy solution to this, so the entire ADD/AF sequence is needed to first conditionally add/subtract 1 to the accumulator if the carry/borrow bit is set. Then the normal arithmetic operation is performed and the flags from both operations combined. This makes add with carry, and subtract with borrow, some of the most expensive operations on this type of restricted hardware.

  • Rev. 5

    Alastair Hewitt03/14/2020 at 01:31 1 comment

    The final board was supposed to be Rev. 4. The order was placed the day China went on Covid-19 lockdown and what should have been a week turned in to a month. This provided some time to reflect on the current design and see if it was possible to squeeze any additional functionality out of the already limited chip count... so by the time the Rev. 4 board showed up there was a Rev. 5 board ready to ship!

    The original design uses 128k RAM divided in to two banks: user and video. The bank is selected by a bit in the instruction, allowing fast switching between these two memory banks. The video memory is the only bank read by the GPU and must always be selected during the GPU RAM cycle. However, the other bank could be further selected and there are up to 3-bits available from the E register to do this.

    It was possible to implement this change by swapping a quad 2-input OR gate (74F32) with a quad 2:1 mux (74F157). A lot of things had to get moved around and the board went through a three-week long revision. The layout didn't change much, but almost all the ECU traces had to be rerouted. A jumper (shown below) was added to select between the original 128k and the new 512k memory chip.

    Another change was the power supply. Unfortunately, the high voltage buck converter didn't make it through the final round of Rev. 4 testing. There is over 3 watts being generated in just one cubic inch of space and things were overheating. The temperature is stable if air can flow over the area, but it starts to get too hot once the enclosure is sealed up.

    The alternative was a linear regulator, specifically the LDO variety. There are 1.5A versions available that can operate within 0.4V of the input and accommodate a 6V power supply. Like a lot of power supplies, the one currently under test outputs 5% over the rated voltage. There's about 366m ohms between the supply and the regulator dropping this to about 5.75V. The remaining drop across the regulator results in 1.125W being dissipated as heat, almost 1/3rd of the buck regulator design.

    The thermal properties of the board are much improved. The minimal board was assembled and tested up to 50C. Not only was it stable, it could run this hot at 35MHz with no decoupling capacitors fitted! This is a first and it appears the changes in the design and PCB layout have all been positive.

  • COSMAC

    Alastair Hewitt03/08/2020 at 22:32 0 comments

    The hardware abstraction layer contains a virtual CPU for executing application code. The plan has always been to emulate an existing CPU, but which one? 8-bits for sure, and since the Intel-derived CPUs (8085/Z80) were too complex, the initial approach was towards a Motorola-derived CPU (68XX/6502). There is a third option though; the RCA 1802 COSMAC.

    This chip is often overlooked because it didn't gain the same visibility as the other 8-bit micros. RCA started its precipitous decline soon after the CPU was launched and their commercial products were all flops. The CPU did find success in the embedded market, from GM's first ECU to space probes.

    The COSMAC is closer to RISC rather than the typical CISC processors of the era. This minimalistic design makes it even easier to implement that the Motorola-derived chips. The chip contains a total of 16 index registers, each with 16 bits, a single 8-bit accumulator, and a few other status registers.

    One issue with chips like the 6502 is their register constrained design (they rely heavily on a zero page to expand a limited set of registers). The emulator has access to its own zero page and can implement up to 256-bytes of registers at no additional cost. There is no benefit to implementing a register constrained design. In fact, a lot of 6502 code would be working around this limitation for no reason. COSMAC code tends to work within its own set of registers and this means it works within the emulator's zero page, so is far more efficient virtual CPU.

    The COSMAC uses a fetch and execute sequence, with a single fetch, and typically one, or sometime two execute cycles. The 1976 COSMAC CPU would run with a 4-5uS machine cycle, so comparable to the 5.2uS machine cycle of the hardware abstraction layer (HAL).

    The fetch code of the HAL just fits in the 43 clock cycles of the virtual machine cycle. There is one caveat: the program counter is pre-incremented. This is the only way to make it fit, so this will break binary compatibility of assembled machine code. However, the code can be easily fixed via static analysis - absolute jump locations need to be reduced by one.

    For the fetch cycle, any one of the index registers can be assigned to the program counter (the PC is essentially an indirect address). This address is used to reference the two bytes of the PC in the emulator's zero page. The lower byte is incremented and the upper byte is either loaded or incremented if the lower byte overflows. The memory location at this address is read and copied to an instruction cache in the zero page. This instruction is then used, along with the virtual machine state, to decode the next page jump.

    Most of the execution will fit in a single virtual machine cycle, but there are a few exceptions. One is the long branch - this is where the next two bytes referenced by the PC need to be read and then used to update the PC. This requires a double length virtual machine cycle (86-clock cycles).

    This is where the indirect location of the PC is used to find and then increment the PC (two step process with conditional jump), load the value at that memory location and then save it in a temporary location. It has to be cached because the PC needs to be incremented again to load the second byte. Both bytes are then used to update the two bytes of the PC (indirectly). This is a lot of work with such limited hardware, as can be seen in the assembly code below:

    # Long Branch (LBR)
    INCLUDE ../inc/unary.nsa
    INCLUDE ../inc/zpage.nsa
    INCLUDE ../inc/pages.nsa
    PAGE LBR_PG
    
    # $PREG - zero page location of the P register
    # $PREG:  10> 100
    # $REG0H: 100> 222 Big-endian
    # $REG0L: 101> 254
    # assume: Y = $VMS
    LDZ HL, $INC2$NULL
    FNH DZ, HLD        # double inc state
    LD HL, $INC$FORK
    LDZ Y, $PREG       # zero page address of PC (Y=10, [10]->100)
    FNH DZ, Y          # Y = lower byte address (y=101)
    FNFH DZ, XD        # inc value of lower byte put in X ([101]->254->255->X)
    FNEL A, PC         # fork based on X
    #16
    
    ADDR 0x40          # if X=0xFF : iden Y, inc X, inc...
    Read more »

  • One Year Later

    Alastair Hewitt02/27/2020 at 20:14 3 comments

    It was a year ago when I stumbled across the infamous 8-bit Guy video demoing the Gigatron. I was working on a retro arcade cabinet at the time, but building a video game system from scratch was a much more interesting challenge. It wouldn't be the first time either. I built a Racer game out of TTL chips using a 7x7 LED matrix as a senior project at school. I then spent that summer working on a Harvard Architecture CPU with a ROM-based ALU. I never thought about generating VGA (it was still a couple of years away at the time) but seeing the Gigatron achieve this with so little has re-inspired me!

    I'm essentially at the same place I was almost 12 weeks ago: I can copy an image from the ROM to the video RAM and generate the video timing. What has changed is the way the video timing is generated and how this code is built.

    The initial code was developed old skool by assembling the machine code by hand and then typing the hex code into the WIndows app that came with the EPROM programmer. It was nostalgic, but not very productive (not to mention frustrating when you typo '6' instead of 'b').

    The project now has an assembler and a build script to compile the code, calculate the ALU lookup tables, and generate fonts. The final step of the build process is to flash the ROM image using minipro. There is no simulator though, so testing must be done on real hardware and debugging still requires an oscilloscope.

    The oscilloscope trace above shows the Page Register clock pulse occurring every 52uS. This represents the virtual machine clock of a hardware abstraction layer developed over the last few weeks. This is the foundation of the system going forward and will be providing video, a virtual UART, "sound chip", and CPU for an operating system and user applications.

    Hardware Abstraction Layer

    There are multiple systems on the board with timing critical requirements like the video, audio, and serial ports. A user program can not take control of the hardware without having a significant insight in to the various timing constraints and requirements of these systems. The solution is to put an abstraction layer between the hardware and user program.

    Even though this has drifted up and down a bit, the final dot clock (until it changes again!) is 33 MHz. This drives a 4-phase clock for the hardware process clock of 8.25MHz. The hardware abstraction layer divides this clock down to a 43-cycle fixed virtual machine cycle running at 191.86kHz. This is further divided down to 9.593kHz by using 20 machine cycles to create a virtual process cycle consisting of either 4 lines of 5 cycles, or 5 lines of 4 cycles.

    Each line in the process cycle ends with a single machine cycle dedicated to timing. This cycle updates the scan register to generate the video sync pulses, updates the V register to select the next line for the GPU to render, samples the serial ports, and decides what additional cycles are needed to handle features (audio and serial communication).

    The remaining cycles are available to execute user code on a virtual CPU. So the 4-line process cycle has 16 machine cycles (153,488 per second)  and the 5-line process cycle has 15 machine cycles (143,895 per second) to execute user code. The virtual CPU uses a fetch/execute cycle, where the execute would need at least one and sometimes two machine cycles. The average would be around 2.3 cycles per instruction, which equates to a virtual CPU speed of around 66k instructions per second.

    Video

    The ALU now contains a video timing function to support four video timing schemes. The first two use the 4-line virtual process cycle with a horizontal frequency of 38.372kHz. The first of these uses 128 process cycles per field to generate VGA at 75Hz (VESA DMT ID: 06h). The second uses 160 process cycles per field to generate SVGA at 60Hz (VESA DMT ID: 09h). The last two timing schemes use the 5-line virtual process cycle with a horizontal...

    Read more »

  • Happy New Year!

    Alastair Hewitt01/25/2020 at 02:51 0 comments

    As in the Chinese Lunar New Year! It's remarkably cheap to run prototype PCBs since the design works on a 2-layer board. I decided to ship the Rev. 3 board design last week to get it here before things shut down in China.

    There's now four populated boards (2x Rev. 1 boards on top, Rev. 3 and Rev. 2 on the bottom of the picture)

    Rev. 3 included a few minor updates to improve the ground planes and power distribution. A bridge rectifier was added and the filter capacitors were increased to handle AC power input. There was also an update to the horizontal control circuit to allow switching between 2 and 3 micro-second H-sync pulses.

    The good news is the board worked first time. The bad news was the updated power supply generates too much noise when the components heat up. This is not a surprise though. Trying to put the entire power supply circuit on the same board was really pushing it!

    The output filter cap was moved away from the main switching circuit due to space constraints. This adds inductance to the ground return path and increases the switching transients on the buck regulator. This causes sharp 20ns pulses riding on the power lines and some pretty horrifying EMC implications I would imagine. The board starts ok, but then becomes unstable as the thermal drift kicks in.

    The Rev. 2 buck converter is working fine though, so the power circuit will be rolled back for the Rev. 4 board. Further testing seems to indicate a 33MHz dot clock is going to be stable and the the hardware abstraction layer is being designed around this (more on that in a later log). The true color video output is greatly improved in terms of supply noise. Not only that, but the video signal gets cleaner as things warm up. There's something strangely satisfying about that in a vacuum tube sort of way.

  • If It Ain't Broke, Don't Fix It

    Alastair Hewitt01/05/2020 at 18:19 0 comments

    There was one final delta between Rev. 1 and 2: The H-sync was put through the bus control latch to align it with the dot clock. This wasn't really necessary, so was rerouted to be a straight connection on the Rev. 2 board. This frees up a flip-flop for use elsewhere and was used to resample the output enable of the X register. However, this required an additional shift in the clock phase that was not made. The result was bus contention on the lower part of the RAM address.

    It's surprising the board was able to run at all with this problem. The OTP ROM did not work because it contained the text fill code and this was crashing before the video loop could start. The problem was resolved by cutting a pin and using a patch wire to select the correct clock phase.

    The Rev. 2 board is working and was able to run with the 35MHz dot clock. The quality of the video signal is greatly improved with the cleaner supply lines. The assumption was the cleaner supply would also improve the stability at 35MHz, but things are starting to glitch as they warm up. Dropping to 32MHz resolves any remaining stability issues and this is likely be the final dot clock speed.

    There's not much more to test on the computer side of things, so testing is focusing on the new power supply design. A trip to the local electronic store to pick up more solder lead to a chance discovery. They had inexpensive linear power supplies. I don't need a regulated input and a big hunk of iron in the power supply has additional retro appeal. Another option is to add a bridge rectifier to the the board to support an AC input. This would only require a simple iron core transformer for the power source.

View all 53 project logs

Enjoy this project?

Share

Discussions

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