Close
0%
0%

YATAC78 - The WWW TTL Computer

Retro computer built from 1978-era TTL logic chips. Internet capable with built in web browser and server

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.

https://github.com/ajhewitt/YATAC78

YATAC78 - Yet Another TTL Archaic Computer (1978)

  • Dual Processor CPU/GPU (Harvard Architecture).
  • 35 MHz dot clock, 17.5 MHz memory clock, 8.75 MHz per processor (~3.5 CPU MIPs)
  • 256k ROM: 96k ALU, 64k native program, 64k relocatable code, 32k fonts.
  • 128k RAM: 64k user, 52k display, 12k buffers.
  • 50+ ALU functions including multiply/divide and math functions.
  • Bitmapped Graphics: Hi-res mode with 8 colors, 4 dithering patterns (320x240@75Hz, 320x200@60/85Hz). Lo-res mode with 256 colors (160x120@60/75Hz, 160x100@85Hz) double buffered
  • Text Mode: 80 columns using code page 437, 8 colors FG/BG, 256 line buffer, 40-75 rows using 8x8 glyph text or 25-37 rows using 8x16 glyph text.
  • Audio: 2 melodic voices and noise channels, 10 waveforms, ADSR, 9.6 kHz/8-bit DAC.
  • PS2 Keyboard interface built in.
  • RS232 Serial Port for host/client and network connectivity (9600 baud).
  • Expansion Port: 7 addressable 8-bit registers in/out, 4 input flags, 1 flip-flop output.
  • Blinkenlights: 1
  • Chip Count: 34 TTL, 1 ROM, 1 RAM, 1 PAL, 4 analog.
  • PCB size: 8" x 5" (200 x 125mm) 4-layer board.
  • Power: 24v @ 600mA (10W)

The system bus is clocked at 17.5MHz and a typical CPU instruction spans 4 clock cycles as follows:

  1. Fetch Instruction from ROM.
  2. Read data from source register or RAM.
  3. Execute ALU function using the ROM as lookup table.
  4. Write data to register and optionally accumulator and/or RAM.

The alternating use of both ROM and RAM allows a second processor to be added to the system. Both processors use a pipeline to cache data between the two address spaces. One processor handles serial communications and general computational tasks (CPU) while the other is dedicated to the display and audio (GPU).

The following sequence of diagrams demonstrates the multiplexing of the CPU (shown in blue) and GPU (shown in red). In this example the GPU is operating in text mode and the CPU is executing the sequence described in the numbered list above.

In the first cycle the GPU reads the ASCII code point of a character from the RAM and stores the result in the pipeline (gc). The CPU addresses the ROM using the Program Counter (PC) and Page Register (Pg) to fetch an instruction to the Instruction Register (I).

In the next cycle the context switches over and the CPU's X and Y registers are used to address the RAM and load the pipeline (cc). Meanwhile the gc, along with the Scan Register (S), is used to address the ROM and fetch a character bitmap line for the Glyph Register (G)

The GPU returns to the RAM where the H counter was moved to the next byte and loads the gc with text color values. The ROM is now configured as an ALU with a function specified in the instruction. The cc is combined with one half of the HL register and the result is stored in a register and Accumulator (A).

In the final cycle the value in A is written to the RAM. The font colors stored in gc are moved to the RAMDAC (C) and the bitmap loaded in to a shift register to start the next character render cycle.

Note: 8-bit ALU functions repeat the last two cycles to combine both halves of the HL register to form an 8-bit result.

memory-map.v1.1.png

Memory map of RAM and ROM address layout.

image/png - 54.00 kB - 10/31/2019 at 19:26

Preview
Download

schematic.v1.1.pdf

Schematic of verified circuit (ECU, CPU, GPU, I/O)

application/pdf - 838.14 kB - 10/28/2019 at 20:48

Preview
Download

inst_set.json

Mnemonics and hex codes for all 17,424 valid instructions.

application/json - 452.14 kB - 10/01/2019 at 02:02

Download

instruction_encoding.v1.0.png

16-bit instruction encoding.

image/png - 16.71 kB - 09/12/2019 at 03:51

Preview
Download

font_rom_v0.2.png

Font ROM rendered as a bitmapped image.

image/png - 10.28 kB - 08/11/2019 at 04:58

Preview
Download

View all 6 files

  • 14 × 74F574 Octal D-type Flip-flop with Tri-state Outputs
  • 4 × 74F541 Octal Buffers/Drivers with Tri-State Outputs
  • 1 × 74HCT4053 Triple 2-Channel Analog Multiplexer
  • 1 × NJM4580 Dual Operational Amplifier
  • 4 × 74F163 Synchronous 4-Bit Binary Counter

View all 19 components

  • Power Supply Design

    Alastair Hewitt5 days ago 0 comments

    The remaining instability in the Rev. 1 board is down to power issues. The power distribution was deliberately underspecified to highlight problem areas and test different designs. There are two main areas of concern: inductance and current consumption.

    Inductance is the biggest enemy for maintaining a clean power supply. The decoupling capacitors help, but adding multiple return paths to ground seems to be the most reliable strategy. The inductance of each path is placed in parallel, so two paths will halve the inductance of the single path.

    Inspiration was taken from 70's video game boards (an example shown above). These were designed before the introduction of microprocessors and typically required well over a hundred (non-LS) TTL chips. These are arranged in columns of several chips with one or more decoupling capacitors per column and a dual return power path. This is the approach taken for the power distribution on the Rev. 2 board.

    The other issue is the relatively large current consumption at 1.5A. This is just for the core system and doesn't include additional power to things like a WiFi dongle (2W) or expansion board (300-500mA). This pushes the maximum current consumption closer to 2.5A and poses some major challenges in maintaining the supply voltage between 4.75v and 5.25v

    The initial plan was to use a 5v power adapter and there are plenty of inexpensive options to meet the current requirements. The problem with these is the resistance between the power supply and the power distribution on the board. The leads from the supply and resistance of the barrel jack connector comes in over 300 milli-ohms. This would drop the voltage by 0.75v at 2.5A, resulting in only 4.25v getting to the board power rails. Some 5v supplies output 5.25v to compensate, but this still means the supply would only reach 4.5v on the board.

    One idea was to start with a higher voltage like 6v and add some additional resistance to drop the voltage down to 5v. The 6v supplies also tend to compensate and typically output 6.3v, so adding a 0.22 ohm power resistor to the supply line would drop the voltage to 5v (assuming a total resistance of 520 milli-ohms). This assumes a current consumption of 2.5A, but the base system consumption of 1.5A would result in a supply of over 5.5v if the additional components were not used with this approach.

    What's really needed is a regulator on the board. One option is a linear regulator to take a 9v or 7.5v supply and drop it down to 5v. Again the current consumption poses a problem here resulting in up to 2.5W of heat dissipation for each volt dropped. Low-dropout regulators are available, but these would still result in over 4W of dissipation and require a large heatsink. The other option is a buck converter and this is the current plan for the Rev. 2 board.

    There are inexpensive SMD modules that can fit in the available space, but these don't have the best thermal design or reliability. The components are available in through-hole however and the buck converter can be added directly to the board. A small heatsink is required and this can be wrapped around one of the mounting holes to maximize the available space as shown below.

    This design can use a much higher voltage and avoid the large input current and voltage drop getting the supply to the board. The current power supply design would only need 600mA using a 24v supply. This includes 2W of direct power to the Wifi dongle and provide up to 2A at 5v via the buck converter for the main system and optional expansion board (assuming 80% efficiency). Heat dissipation is also a more manageable 2W with this design.

  • Parrot!

    Alastair Hewitt12/08/2019 at 05:04 1 comment

    One significant milestone in any home brew VGA project is to generate a parrot image... so here it is!

    This is in the lo-res video mode (160x120) using the 3:3:2 video DAC. To do some baseline testing the board generating this does not have any decoupling capacitors and it looks pretty terrible. The video is being oversampled by a factor of 5 and a lot of the supply noise shows up in the image (the white area below should be the same color).

    Hopefully this will be greatly improved with the Rev 2 board, which is where most of the time over the last 2 weeks has been spent. Also worth noting is how this image is generated. The image is stored in the ROM, but the Harvard Architecture prevents data from being read from the ROM. The image is actually the product of several ALU functions, each one acting as a lookup table to return parts of the bitmap image.

  • HDMI Test in SVGAish Mode

    Alastair Hewitt11/28/2019 at 03:35 0 comments

    A quick test with the video loop updated to SVGAish mode. The differences being the 35MHz dot clock is 7/8th the speed of the true SVGA 40MHz clock. This means 87.5 columns of text instead of 100.

    The horizontal frequency is also adjusted up slightly from the SVGA 37.879kHz to 38.377kHz. This is only a few hundred ppm away from the 38.4kHz UART speed. The TV is happy with this timing passed straight through the cheap $8 VGA to HDMI converter.

  • Initial Rev.1 Board Results

    Alastair Hewitt11/24/2019 at 17:46 2 comments

    The Rev.1 boards came in earlier this week and a couple where built and tested. The only firmware that exists generates a text mode video pattern, so some unrelated components were not fitted.

    It took a few hours to resolve a couple of issues with the PAL. The pins were reassigned on the PCB version, but the old JEDEC file had been programmed. The reset input shouldn't need an external pull-up resistor, but the PCB version appears to need one. This was patched on the back of the board.

    The test program worked first time once the PAL issues were resolved. "Worked" as in it generated a somewhat glitchy test pattern and only with a 25MHz dot clock. This was not encouraging, since this is a similar performance level to the breadboard. Several hundred pads were soldered on the board and this resulted in a lot of flux. This was cleaned off as a precaution, but didn't seem to change anything.

    Some initial probing started to identify the source of the problems. The power lines to the chips were showing a decent amount of noise. The board being probed did have decoupling capacitors, but these seemed to be less effective than just using a low inductance path to ground instead. Almost all the glitching was eliminated by adding a single ground return from the RAM chip to the lower power bus.

    After that the clock speed was retested and the board was now able to reach its maximum dot clock speed of over 36MHz. The closest available oscillator is 35MHz and this was tested to good effect. This results in a machine clock of 17.5MHz and a memory access cycle of 57ns. Both the NOR flash and OTP ROMs respond in about 50ns, so there's 7ns left in the memory access cycle. A 40MHz oscillator was also tested, but there's no time left in the cycle to meet the setup times and latch valid data. The board may go a little faster (36.864?) but the current 7ns buffer is a good place to stop.

    Things were close, but not quite there. One final discovery appears to have cleared up the remaining glitches though. The dual 2-4 decoders are obsolete in the 74F series, but I was able to pick some up on Ebay and I've been using these. I want all the parts to be in production and the design should work with the currently available 74ALS139. This chip is routinely tested to make sure the board will still work and it appears that changing to this version solves all of the remaining glitches. Like many NOS chips listed on Ebay, the 74F139 chips I bought may have come from a rejected batch. It's also possible these 1987 chips have deteriorated over the past third of a century... Either way it looks like the board is now 100% working!

    Things are now blocked on further hardware testing until more firmware is written. The two bitmap graphics modes need testing (building out the 8-bit video DAC), the audio system and amplifier/filters, and the serial - both keyboard and RS232. All these require new code and that code will require build tools. Once the rest of the hardware testing is complete a Rev.2 board can be built to rework the grounding issues.

  • Routed

    Alastair Hewitt11/11/2019 at 01:13 5 comments

    Hot off the press... Routing was just completed using 8 mil traces with 7 mil spacing. This was 100% hand routed and took about 30 hours. The original attempt using 10 mil traces with 8 mil spacing failed after about 24 hours of work.

    The ability to route two traces between the DIP pads was the only way to complete routing at this density (40 chips on 8" x 5" double-sided board). Extra space was also added around the ROM to allow a ZIF socket to be installed.

    Update: DRC checks pass and initial visual inspection done. The power barrel jack needs fixing and possible additional mods after further review. If everything checks then it will get shipped for fabrication tomorrow.

  • PCB Taking Shape

    Alastair Hewitt11/07/2019 at 15:58 3 comments

    This is by far the most complex board I've ever worked on and I assumed it would take the rest of this month to lay out. However, things are progressing a lot faster than thought and it's possible a Rev. 1 board could be ready for fab by the end of the weekend.

    This may be wildly optimistic though... The last 10% of the traces could take 90% of the time to manually route. It's possible the last few traces may not be routable at this density and the entire layout could get scrapped when it's 99% done.

  • Long Road Ahead

    Alastair Hewitt11/04/2019 at 02:40 2 comments

    This was a long fought victory. Two pairs of loops were added, the first to fill the video memory with 64 columns of text repeating every 4 lines with the enumeration of code page 437. The second repeats the background colors as 8 columns and foreground colors and fonts on alternating rows.

    There were various issues getting this working. One was a bug in the build script that generates the list of valid instructions. Most of the other issues related to stability. The supply voltage sags from one side of the breadboard to the other. The difference is over 0.3V, but the most stable range of operation falls within a narrow 0.1-0.2V range. Adjusting the supply to stabilize one side will destabilize the other. It also appears the NOR flash is aging each time new code is flashed. The access time is slowly increasing and the once stable 25MHz is now glitching (spot the glitch in the last sequence of 0-9 above).

    There are a few more tests to run, but the value of developing and testing on the breadboard is rapidly diminishing. The PCB is starting to progress with a final component layout and routing strategy. The first revision will be a simple two-sided board to test the layout and power distribution. Further revisions will likely switch to 4-layers depending on actual stability.

  • 90 Column Text

    Alastair Hewitt10/31/2019 at 01:26 1 comment

    The scaler appears to be the most forgiving of the video devices on hand and a video signal was just possible with a clock of 29.4912MHz. This is a nice UART frequency but it is probably out of reach even when the circuit is on a real PCB. There is one frequency available that may be attainable and that is the other VGA clock: 28.322MHz.

    The standard 25.175MHz VGA clock generates a horizontal resolution of 640 pixels, or 80 columns of 8-pixel wide glyphs. The 28.322MHz frequency is 9/8ths as fast and generates a horizontal resolution of 720 pixels, or 80 columns of 9-pixel wide glyphs. Of course, this is with the VGA horizontal frequency of 31.5kHz, where this design requires 38.4kHz.

    The line length is shortened in order to get to the 38.4kHz. In this case the effective horizontal resolution would be reduced to 575 pixels, or around 71 columns of text. However, this shorter line is only required to support serial communications. This would be a requirement for something like a text based web browser, but non-network applications can use the original VGA timing. This would result a text mode with 90 columns using the font ROM's 8-pixel glyphs.

    This change requires two different timing loops. The 38.4kHz loop would divide the line by 184 process cycles and the 31.5kHz loop would divide by 225.  The decision had already been made to handle either serial or audio, but not both concurrently. It now makes sense to split these features between these two video modes. The additional 41 process cycles in the 31.5kHz loop can then be used to process the audio. The rest of the loop would operate the same interpreter fetch and execute cycles as the shorter 38.4kHz loop. Therefore the only change between the loops would be a longer H-sync cycle to process the audio.

    There would still be text and graphics modes with both loops and they can both support two video modes each depending on the field rate. The following examples show the supported video modes:

    31.5kHz Horizontal, 60Hz Field (native 720x480 60Hz VGA)

    • Hi-res Text: 90x60
    • Lo-res Text: 90x30
    • Hi-res Graphics: 360x240
    • Lo-res Graphics: 180x120

    31.5kHz Horizontal, 70Hz Field (native 720x400 70Hz VGA)

    • Hi-res Text: 90x50
    • Lo-res Text: 90x25
    • Hi-res Graphics: 360x200
    • Lo-res Graphics: 180x100

    38.4kHz Horizontal Scan, 60Hz Field (**native 800x600 60Hz SVGA)

    • Hi-res Text: 70x75
    • Lo-res Text: 70x35
    • Hi-res Graphics: 280x200
    • Lo-res Graphics: 140x100

    38.4kHz Horizontal Scan, 75Hz Field (**native 640x480 75Hz VGA)

    • Hi-res Text: 70x60
    • Lo-res Text: 70x30
    • Hi-res Graphics: 280x240
    • Lo-res Graphics: 140x120

    ** 38.4kHz modes are slightly modified versions of the VESA standards

  • 80 Column Text

    Alastair Hewitt10/29/2019 at 00:10 2 comments

    The testing phase has been using NOR flash memory. The fastest version is rated at 70ns, and although much better performance was observed, it will not support a dot clock above 25MHz. The final design will use the 55ns rated Atmel AT27C020. A similar performance boost was assumed and this suggests a clock of 32MHz might be possible with this faster memory.

    The AT27C020 is a one-time programable (OTP) device and it was finally time to commit a device to the video timing code. The 32MHz version of the code was programmed and tested. Unfortunately, the OTP ROM did not support 32MHz, or at least, not on the breadboard. The highest frequency achieved (with the crystals on hand) was 27MHz.

    This clock was just fast enough to meet the 50Hz limit on the CRT and display what the faster clock would show at 60Hz. The result below is the high-res text mode of 80x75. There is no horizontal blanking, so the random text actually wraps around to display about 87 columns of text. Click on the image and zoom in to see it in all its glory!

    I believe this might be the highest density text ever produced by a TTL-only computer.

  • GPU Build Complete

    Alastair Hewitt10/27/2019 at 23:06 0 comments

    The last few chips were added this weekend to complete the GPU functionality. The system had been stabilized to work with the 32 MHz dot clock and the initial testing started with that. Unfortunately things didn't work at all once the font ROM was engaged!

    Up until now the GPU has been kept in its blanking state for CPU testing. This is where the GPU addresses the RAM location 0x1FFFF, which returns the same byte on every GPU cycle. This means the ROM data bus alternates between the CPU code/ALU result, and a single value. This all changed once the GPU was brought out of the blanking state. Now there is the full entropy on the bus with alternating code/ALU and glyph data. This creates a much more complex set of signals and the already noisy bus became too unstable to latch valid data.

    Another issue is the memory speed. The 32 MHz dot clock requires memory access time of better than 50ns. The NOR flash was measured at around 35ns in the blanking state, but couldn't keep up when the font lookup was also being processed. Reducing the clock to 25 MHz brought things back under control, but only just. There is still a lot of glitching mainly caused by noise from the following rat's nest...

    The video loop described in the previous log was updated for the slower clock to produce 65 columns by 38 lines of text. The video memory is not initialized, so the color and text data is just random. The following photo shows this data when displayed on the CRT:

    The CRT works great and the video signal is crisp and well defined. This is unlikely to the typical display method, so the signal was also examined on an LCD. This is where things start to get interesting though. The 38.4kHz/60Hz video signal is treated as SVGA and assumed to come from a 40MHz dot clock. This means the LCD will oversample the signal and record all the timing glitches when one color changes to another.

    This effect can be seen in the following detail from the LCD:

    This ghosting was anticipated and the RGB bits were passed through a final set of flip flops to make sure all the bits change simultaneously. However, this did not solve the problem since the logic level rise and fall times differ. The final stage of flip flops made very little difference to the quality of the signal. In fact the version with the flip flops displayed additional noise caused by crosstalk with the other flip flops on the chip.

    Below is the same section of color text. The version at the top was resampled by the flip-flops, while the version on the bottom is the raw output direct from the 2:1 multiplexer.

    These observations have been taken in to consideration for one final update of the schematic. Everything except the audio and serial communications has now been verified. It is getting harder to test though and full speed testing will not be possible with the breadboard. The plan is to now proceed with the PCB layout and then continue testing when the rev 1 board is available.

View all 40 project logs

Enjoy this project?

Share

Discussions

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