Close
0%
0%

Gigatron TTL microcomputer

Just because! A home computer without microprocessor

Similar projects worth following
In 1975 Wozniak famously designed the Breakout arcade game out of 44 simple chips, without using a microprocessor, simply because those weren't available to him at the time. When one year later the MOS 6502 and Zilog Z80 were launched, his Apple 1 started the microcomputer revolution. The debate still rages about which processor was the better one. But more interesting is to investigate if these devices were really necessary for the personal computer revolution at all: what would have happened had they never appeared?

Update: For info on the kit version of this project, check out: https://gigatron.io/

History followed one path
There were many other ways
It will always be like that

Can fewer than 40 old-skool TTL chips implement a multi-megahertz microcomputer with video and sound?

This project started as an exploration of what you can build from 30-40 simple logic chips. It has turned into a general purpose 8-bit microcomputer without any microprocessor driving it. I initially designed this on a large breadboard in early 2017, but soon after that I converted it all to a small PCB. It has VGA-compatible 60 Hz video in 64 colors and can display full-screen images, scroll them and play sound. Soon it will be running games like Pac Man and Space Invaders. But just for fun, I'll keep everything compatible with the breadboard design.

This is what we have now:
• 8-bits system built out of 1970s TTL chips (74LS)
• 34 TTL ICs, or 930 logic gates, for the CPU proper
• No microcontroller and no complex chips (such as the 74181 ALU)
• 16-bit virtual CPU runs ported versions of classic games (Snake, Racer, Tetris, Bricks, ...)
• 8-bit virtual CPU runs 6502 programs such as Microchess and Micro-Soft BASIC without blinking an eye
• Can emulate an Apple-1 including wozmon, Apple-1 BASIC, mini-assembler and some games
• Only simple ICs, such as AND/OR, 4-bit adders, multiplexers, registers and so on
• 6.3 MHz. Can be pushed to 15 MHz with 74F logic and faster RAM
• 32kB 70ns RAM
• Harvard architecture with EPROM for kernel and cold storage. [And no @Benchoff, it doesn't require a large ROM at all.]
• Operates on 2.5W, or below 0.5W for the 74HCT version
• RISC with pipelining:  1 instructions per clock (sometimes 2...)
• Instruction decoding with diodes
• Nice clean instruction set: add, sub, and, or, xor, conditional jumps, many useful addressing modes
• 60Hz 64 color VGA and 4 sound channels bit-banged from software
• Originally designed and built on a solderless breadboard in 6 weeks (see the logs!)

The build has become a contradiction of itself. To reduce the parts count, every hardware function is essentially software-defined: video, audio and I/O are all handled by software. Video at the pixel level. Audio at the sample level, in 4 channels. Even the applications themselves are running in a non-existent 16-bit processor (aka interpreter).

Yet there is no microprocessor chip in there that runs the software of any of those virtual subsystems: it's all handled by the TTL circuit, acting as a minimalistic CPU and switching rapidly between these tasks. Not only does it work, the board is smaller and faster than the microcomputers of the day, including the first IBM PC. Having no microprocessor might have been better than having any of the time :-)

Check the videos for the current capabilities. The HaD blog section has the full story in all detail, so don't miss that if you're interested.

Some concepts to ponder about before starting

  1. How many bits? 4, 8, 16, 32, ...
  2. Software-generated video or hardwired?
  3. Harvard or Von Neumann architecture?
  4. Single cycle or multi cycle? Pipelining?
  5. ALU chips or not?
  6. Sliced ALU or full width?

A rule of thumb is that a minimalistic four bit system can be done in 10 chips, an eight bitter needs no more than 20 chips and going to 16 bits roughly doubles that again. Not all units double in chip count, but by extending the buses you will also have need for more addressing modes for it all to make sense. For example, a four bitter might work fine with a 256 word memory and absolute addressing, but with larger memories you'll need ways to construct addresses dynamically. Also, add more chips if extra functionality is required, such as high speed, a stack pointer, interrupts, a custom ALU or video.

Simplest possible concept

One concept, probably the simplest, is to replace the TrinketPro from the earlier breadboard VGA from TTL and SRAM with a minimalistic 4-bit TTL CPU. We will then get a working system with around 25 chips, or about 30 if we make a custom ALU....

Read more »

Schematics 2020-03-20.pdf

Circuit diagram

Adobe Portable Document Format - 1.39 MB - 03/21/2020 at 10:07

Preview
Download

Gigatron Rev. 2012 OSH.zip

Gigatron TTL computer KiCad files and gerbers

Zip Archive - 4.60 MB - 03/20/2020 at 16:30

Download

PluggyMcPlugface.zip

PS/2 keyboard adapter KiCad files and gerbers

Zip Archive - 2.77 MB - 03/20/2020 at 16:27

Download

Native instruction overview 2019-11-25.pdf

Two views on the native 8-bit instruction set

Adobe Portable Document Format - 62.81 kB - 11/27/2019 at 00:47

Preview
Download

2019-VCF-Berlin-GigatronTTL.pdf

2019 Vintage Computer Festival Berlin presentation

Adobe Portable Document Format - 32.15 MB - 10/14/2019 at 06:55

Preview
Download

View all 13 files

  • Ye Olde Gigatron and Гигатрон

    Walter08/26/2020 at 15:09 0 comments

    There's two Gigatron "specials":

    Ye Olde Gigatron

    The Gigatron was designed to run with old TTL chips. The kits were supplied with modern, CMOS type chips, but the goal was to keep it TTL compatible. Marcel had already started sourcing some old TTL components, most notably an old 70ns SRAM. I've taken over that task, which has led to the creation of what I call "Ye Olde Gigatron". (And yes I know "Ye" was pronounced "The" and the word "Olde" does not exist.)

    Not counting the clock and the 75HC595, all the ICs are old. The newest IC on there is the RAM, which is from 1991. All the rest is pre-1990, so over 30 years old!

    I've thrown in a mix of stuff:
    - 54LS, extended temperature range ("mil-spec")
    - 74, standard TTL
    - 74S, Schottky
    - 74LS, Schottky low-power

    Ye Olde Gigatron is a bit unstable and it consumes a whopping 1.2Amps. It requires a good power supply so I used my lab power supply. Also the clock did not work at first. The 74HCT04 provides a clock booster and that started ringing so I had to add a resistor. The clock circuit will not work with Schottky components, so I left in a 74HCT04. A 7404/74H04/.. will not work in a Pierce oscillator design. Still looking into using a 74C04.

    The components used are:
    6x 74163 (National Semiconductor, 1972)
    4x 74157 (Stewart Wagner, 1975)
    4x 74153 (Fairchild, 1976)
    2x 74283 (Fairchild, 1978)
    1x 74S240 (Signtics, 1979)
    2x 74S153 (National Semiconductor, 1980)
    2x 74S153 (Signetics, 1981)
    2x 74S138 (Fairchild, 1982)
    3x 54LS377 (Texas Instruments, 1982)
    1x 74LS273 (Motorola, 1983)
    1x 74LS244 (Signetics, 1984)
    1x 74LS153 (Raytheon, 1985)
    1x 74LS244 (Signetics, 1986)
    1x 74LS32 (Motorola, 1986)
    1x 74LS139 (Fairchild, 1986)
    1x 27C1024 (ST Microelectronics, 1988)
    2x 74LS273 (Texas Instruments, 1989)
    1x 62256 (Micron Technology, 1991)

    If somebody has older components than this, let me know :-)

    yeolde1.jpg
    2. Gigatronski

    Since I gave a talk about the Gigatron at Neuron hackspace in Moscow, I wanted to make a Gigatron with old Soviet chips. Unfortunately, I did not get any from my new Russian friends. By the way, Pavel and others of Neuron Hackspace have a wonderful "Flipper Zero" kickstarter project.
     
    But anyway, after a long time occasionally looking for Soviet TTL chips, I suddenly found Evita, a company in Vilnius, Lithuania, that has a lot of NOS Soviet components. I was able to order everything there. One chip appeared to be broken, but the company send me a replacement at no extra cost.

    The chips were new. The newest of the lot is manufactured in 1992 (so strictly speaking, not Soviet but Russian!). They have a different colour than the IC's I'm used to seeing. Also on quite a few, you can see a piece of aluminum on the bottom. I've opened one up, to see that this is used to put the die on before the epoxy is added.

    The Soviet chips also have a different pin spacing (2.5mm instead of 2.54mm). But I was able to (gently!) get them all into their sockets, even the larger ones. I did spend quite some time looking for Soviet replacements of the 62256 SRAM and 27C1024 EPROM, but don't believe they ever existed. The 75HC595 is also not available. A Soviet 74LS04 can be found, but it will not work in the pierce oscillator (same as with Ye Olde Gigatron). There is a Societ 74ACT04 version called КФ1594ЛН1, but that is pretty rare and I could not get one. Since it's used for the clock and not the CPU itself, it is not that much of a problem.

    I got a white PCB from somebody in Hong Kong, which I used for the Гигатрон. I swapped SRAM in between pictures. It now has the same old SRAM as Ye Olde Gigatron.

    Since I ran out of VGA connectors, I bought a cheap one from China, instead of buying from Mouser/Farnell/Digikey, which I've always done for the kits. Although cheap, it also is not as mechanically sturdy and.. quite a bit smaller, so it no longer aligns with the serial connector. Oh well.

    gigatronski.jpg

  • The Gigatron lives on!

    Walter07/16/2020 at 14:42 0 comments

    The Gigatron lives on!

    Dutch company Budgetronics is offering Gigatron kits. They are a bit different to what we used to ship though:

    • No wooden enclosure included
    • No game controller included
    • No manual included (you can download & print yourself)
    • Black PCB instead of green

    Since there's less included, the price is also lower: € 99.95

    If you attach a PS/2 keyboard, you have all the functionality, as ROMv4 is included (preprogrammed) as well as the Pluggy McPlugface PS/2 adapter.

    https://www.budgetronics.eu/en/building-kits/gigatron-retrocomputer-building-kit/a-25779-20

  • Gigatron fully open source

    Walter06/11/2020 at 10:33 0 comments

    The Gigatron TTL computer is now fully open source! The source code had been open source (BSD license) since the beginning of course. A while ago, we published the design files for the printed circuit boards, both for the Gigatron and for Pluggy McPlugface, the PS/2 adapter.

    We have now also made the full Assembly and User manual available online, under a CC-BY-SA license. The assembly manual contains the list of components, which is now also available separately as a Bill of Materials under the same license.

    These files should enable to you make your own Gigatron. The only part that is no longer available is the custom made wooden enclosure.

    If you decide to build your own Gigatron, we won't provide support. But we do encourage people to go down the rabbit hole :-)

  • 1000! And Gigatron future

    Walter05/28/2020 at 10:47 0 comments

    In the last year, a lot has happened. We now have 6502 emulation and the Gigatron can run Apple-1 code, such as WozMon. We have BASIC running and there's a great BASIC compiler, opening the way to create great games. Looking back on the original goal to play tic-tac-toe on a LED matrix, we are super chuffed that we have a system running BASIC that feels like an actual homecomputer from years ago - still without a microprocessor.

    And today, Gigatron #1000 has found a new owner! Thanks to everybody for making happen what we could not have dreamt of when we started!

    We have decided to stop selling kits once our stock has been sold, which should be in a few months. For us, the Gigatron was always about inventing new things, understanding technology, designing, fine tuning, tinkering, and also about meeting like minded people (and having fun in the process). Making it into a kit had its own charmes, writing a manual, sourcing components, designing a PCB. Packaging and sending out kits, however, resembles a plain job too much, but was needed to create a community of people that would also want to design, understand and tinker.

    That community now exists, and wonderful things have already come from it, both in hardware and software. So we will stop selling and providing support in a few months. Does that mean you can no longer get a Gigatron? No, you still can, because the PCB layout, the schematics and the software have all been open sourced. The only thing you probably cannot get is the wooden case that we had tailor made for the Gigatron. Somewhere in July or August, the assembly manual and more will  open sourced as well. We hope the Gigatron will live on!


  • The gtBASIC compiler for games

    Marcel van Kervinck05/05/2020 at 09:31 0 comments

    The Gigatron can be a great gaming machine. However, Tiny BASIC is a bit too slow for games and nowadays not everyone wants to do assembly. Yesterday at67 formally released his solution to this dilemma: the gtBASIC compiler(!) supporting sprites, sound effects and music! Now there's NO excuse to turn the Gigatron into the retro game console you always wanted. I hope this brings the platform to a whole new level.

  • Mastermind in 177 bytes

    Marcel van Kervinck02/22/2020 at 12:21 0 comments

    Typed in from this 1976 Dr Dobbs article. Worked first time.

    Except that we don't do decimal mode and Woz used that to increment the "tries" counter on the left side. So you better win the game in less than 10 tries (or accept a hexadecimal count).

    If we sacrifice 13 more bytes, we can get the correct try count without using BCD mode:

    190 bytes works for me.

  • Why settle for two BASICs when you can have four?

    Marcel van Kervinck12/27/2019 at 20:47 0 comments

    Today we gained two more BASICs. One new, one very old. First at67 offered his BASIC compiler for the Gigatron. This project has been brewing for over a year. It's still in alpha, but it is GREAT already. This is a cross-compiler that creates fast Gigatron binaries. This is fantastic news for those who like to write games but don't want to dive too deep into the Gigatron machine languages. This week it built our Christmas greetings, with snow physics and Jingle Bells tune.

     Video link: https://streamable.com/5ds9d

    At67's compiler is the third BASIC for the Gigatron. The first was our port of Tiny BASIC more than a year ago. The second was MS BASIC with floating point. Today I decided that three BASICs aren't enough because we can have four.

    We have Apple-1 emulation after all, so why not? Most work was to arrange the video table such that we have a 4K continuous block for Wozniak's original Apple-1 BASIC. We managed to free $6000-$6FFF in the 32K system. That mirrors to address $E000 and that is exactly where the original likes to sit. Then we reordered the zero page a bit and recompiled the A1 BASIC using cc65. Et voilà, there it runs! 

  • Micro-Soft BASIC and π

    Marcel van Kervinck10/16/2019 at 19:32 0 comments

    It took a while, but now Micro-Soft BASIC is running on the 32K Gigatron! We already had Tiny BASIC of course, but that doesn't have 9 digits floating point (40 bits), let alone transcendental functions. Remember when Hackaday wrote that the Gigatron would probably never have floating point?

    This is the BASIC that Paul Allen and Bill Gates wrote with Monte Davidoff and Ric Weiland, and for which they started Microsoft, or spelled Micro-Soft back then. They licensed it to many microcomputer builders, amongst others to Commodore. The version we have running is an early one for the Commodore PET. 

    Although the system can interpret 6502 code, there still was work to do: code, buffers, zero page variables and stack needed relocation, but that wasn't the biggest hurdle as Michael Steil's excellent set of reconstructed assembly sources made that relatively painless. The main problem was to create a sufficiently large continuous memory space. Although the Gigatron has 32K of RAM, 19KB of that is used for screen memory and the remainder is heavily fragmented. For example, by default the largest continuous block we have is just 512 bytes. BASIC itself needs 8KB, plus we need some K's for user program and variables. Ouch... 

    The first win is to disable the sound channels 2 through 4. That creates a continuous block from $200 to $800. For this trick you need ROM v4.

    The next step is to compress the video memory. Our video resolution is already next to nothing, but we can always lower it even more! Of the 120 visible pixel lines, every 8th is always empty. At least, as long as we only use capitals, and for a mid-1970s BASIC that's perfectly acceptable. The empty pixel lines can then be shared for all rows of text. That saves 14*256 = 3585 bytes already.

    The last trick is to increase the spacing between text lines from 1 to 4. This reduces the text lines from 15 to 11, but yields 4 * 7 * 256 =7,168 bytes.

    Of course we then went overboard and added a flashing cursor, we made sure that the WAIT 6502 Easter Egg works, and that there is a π-symbol. The Gigatron doesn't have that in its font, but it does have T and U.... And... the font is stored without horizontal spacing, so there's our glyph:

      R         S         T   pi    U
      |         |         |   |     |
      v         v         v   v     v
      x x x x . . x x x . x x # # # # . . . x
      x . . . x x . . . . . . # . . # . . . x
      x . . . x x . . . . . . # . . # . . . x
      x x x x . . x x x . . . # . . # . . . x
      x . x . . . . . . x . . # . . # . . . x
      x . . x . . . . . x . . # . . # . . . x
      x . . . x x x x x . . . # . . . # x x .
      . . . . . . . . . . . . . . . . . . . .
      0 1 2 3 4 5 6 7 8 9 a b c d e f 1 1 1 1
      ^                               0 1 2 3
      |
      font82up

    Good enough for me:

  • Heatmap of Gigatron applications

    Marcel van Kervinck10/08/2019 at 16:01 0 comments

    A static RAM map constructed by overlaying all GT1 files in the GitHub repo.

  • The anthem of 8-bit computing

    Marcel van Kervinck08/13/2019 at 10:07 0 comments

    A bunch of TTL chips playing the "anthem of 8-bit computing". Four channels: 2x pulse, 1x triangle, 1x noise

    The player is an enhanced version of the Contrib/at67/midi player in the gigatron-rom repository. The noise is created from waveform 0 ("metallic") that receives a randomised XOR modulation 60 times per second.

    Only 7400 logic. No microprocessor, no video chip, no sound chip.

    The Arduino is used to load the music and player into RAM. You see that happen in the first few seconds of the video.

View all 76 project logs

Enjoy this project?

Share

Discussions

at67 wrote 05/31/2020 at 21:18 point

Rest in peace Marcel.

  Are you sure? yes | no

hwrecruit55 wrote 05/28/2020 at 09:39 point

RIP Marcel, you will be missed.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 09/26/2019 at 07:08 point

the Gigatron is mentioned at about 1:17 on the EEVblog !
https://www.youtube.com/watch?v=4VTtkF5fzMM

  Are you sure? yes | no

Marcel van Kervinck wrote 09/26/2019 at 07:41 point

\o/

  Are you sure? yes | no

Stefano wrote 07/05/2019 at 15:08 point

First of all compliments for the idea and the nice realization! :)

I was very interestingly looking at the project, and among the things that might be improved for a newer version (e.g. clock frequency, keyboard instead of controller, cartdridge/expansion port, etc), I was thinking that instruction set might be a very relevant one.

The following proposal for a revisited instruction set should not change much the number of logic ports and the current schematics, but seems to me more rational and powerful.

Bit 5:7        Bit 2:4            Bit 0:1
Operation      Mode               Bus


0. LOAD        0. [D,X],AC        0. D 
1. AND         1. [Y,X],AC        1. RAM     
2. OR          2. [Y,D],AC        2. AC
3. XOR         3. [Y,X],(**)AC    3. IN
4. ADD         4. [D,X],Y              
5. SUB(*)      5. [Y,X++],AC                 
               6. [Y,D],X
               7. [Y,X++],OUT            

6. STORE       0. [D,X]           0. D
               1. tbd             1. tbd
               2. [Y,D]           2. AC
               3. [Y,X]           3. IN
               4. Y
               5. tbd
               6. X
               7. [Y,X++]

7. JUMP        0. jmp y,bus       0. D
               1. AC>0 (bgt bus)  1. [D]
               2. AC<0 (blt bus)  2. AC
               3. AC≠0 (bne bus)  3. IN
               4. AC=0 (beq bus)
               5. AC≥0 (bge bus)
               6. AC≤0 (ble bus)
               7. Branch always

Notes:

(*) put A as second operand (meaning doing "minus A") because:
   - A minus D (fixed constant) can be always be transformed in an addition at compile time
   - the instruction will be also useful to negate A (as 0 minus A), and is already useful in conditional jumps calculations
   - for the addition first or second is the same

(**) add also carry on this combination if possible (it was redundant so it will be useful) and many instructions can be used to clear carry flag


With this set it will also be possible to reuse with very little changes all the current sw.

What do you think about it?

  Are you sure? yes | no

Marcel van Kervinck wrote 07/08/2019 at 22:52 point

Sorry I didn't see the message earlier. You would have to draw the control logic. This design is based on reducing the number of parts as much as possible (without crippling the capability of making software too much). As said in the log when we worked on this: the instruction set is the result of that process, not the beginning: https://hackaday.io/project/20781-gigatron-ttl-microcomputer/log/57462-control-unit-design

  Are you sure? yes | no

Stefano wrote 07/10/2019 at 19:36 point

This proposal was to try to maintain a similar hw complexity as now (mostly rewiring or with some little change on the CU arrangment)! ... Anyway I got the point of reducing and I'm trying to work on this concept, trying to see if I can make some relevant proposal... let's see! :)

  Are you sure? yes | no

Marcel van Kervinck wrote 07/11/2019 at 14:06 point

It's difficult to judge without seeing the full proposal. We don't have flags now for example (as explained in the FAQ). But don't let that stop you. Just build your machine the way you believe is best, and share your results! The proof of the pudding is in the eating after all.

  Are you sure? yes | no

Stefano wrote 07/12/2019 at 20:38 point

Yes, the absence of the carry is pretty relevant (for this reason I wrote if possible in the notes), but the rest should be quite easily doable. In the new design I'm anyway trying to keep the carry. Hope to serve in the medium term a nice pudding variation! :)

  Are you sure? yes | no

Marcel van Kervinck wrote 11/24/2019 at 16:54 point

I was wondering if you have progressed to the point where you have built something?

  Are you sure? yes | no

Marcel van Kervinck wrote 06/10/2019 at 21:06 point

I started a thread on 6502 emulation here: http://forum.6502.org/viewtopic.php?f=8&t=5666 I think I have the skeleton for an emulator that can be made to work.

  Are you sure? yes | no

Jac Goudsmit wrote 11/21/2018 at 23:33 point

Ha, I just noticed the picture from your racing game has the Evoluon on it. Now I have to save up and buy it just for that :-)

  Are you sure? yes | no

Marcel van Kervinck wrote 11/21/2018 at 23:36 point

Well spotted! I can put one aside and reserve it for you...

  Are you sure? yes | no

Jac Goudsmit wrote 12/11/2018 at 22:46 point

My Gigatron kit just arrived in the mail. It's absolutely gorgeous, even better looking than on TV :-)

Great job, Marcel and Walter!

  Are you sure? yes | no

Marcel van Kervinck wrote 10/30/2018 at 17:18 point

The 8-Bit Guy has just released an update video on the Gigatron \o/
https://www.youtube.com/watch?v=uidtGvsk21M

  Are you sure? yes | no

Ingo Truppel wrote 10/15/2018 at 11:56 point

I got into contact with Gigatron at the VCFB 2018. I could not resist to buy one. Thanks for the detailed explanation and nice presentation. I'm looking forward to build the Gigatron myself.

In between my Gigatron is alive: https://forum.gigatron.io/viewtopic.php?f=3&t=63

  Are you sure? yes | no

Marcel van Kervinck wrote 10/09/2018 at 20:16 point

Decided to attend Vintage Computer Festival Berlin next weekend. Looking forward !

  Are you sure? yes | no

edsjac wrote 05/30/2018 at 20:52 point

Really nice and interesting project! Open source Hardware and Software. 

Many people can use it to learn in-depth how computers works.

Thank you very much for sharing!

  Are you sure? yes | no

Marcel van Kervinck wrote 05/30/2018 at 21:38 point

Thanks! This project has been a blast, and still is...

  Are you sure? yes | no

Marcel van Kervinck wrote 05/27/2018 at 23:47 point

It turns out there is a Gigatron Service centre in Belgrade. How cool is that! https://forum.gigatron.io/viewtopic.php?p=115#p115

  Are you sure? yes | no

Marcel van Kervinck wrote 05/14/2018 at 11:48 point

We have kicked off a Gigatron user forum: https://forum.gigatron.io

  Are you sure? yes | no

hosabike wrote 05/04/2018 at 11:17 point

Hello. I have a small question for creators. This design seems damn effective and useful, but I still have to wonder: why exactly something like this wasn't built in late 60/early 70 despite TTL logic was avaiable since 1966?

  Are you sure? yes | no

Marcel van Kervinck wrote 05/08/2018 at 23:12 point

Two reasons. First but not foremost is that the RISC architecture was not recognised as commercially viable until much later, like 1985 or so. Doing RISC drops your component count by an order of magnitude. Second is that the real hero in this design is the RAM chip. That chip allows for software to do a lot of stuff you would normally do with circuitry. Dating it: if the design were to be retrofitted for slower TV signals of the day, something like this might have existed around 1985 considering part availability. (Mind: slowest VGA speed = 4x TV speed). The CPU-part could still be made from early 1970s logic. The total system would have been expensive because 32KB SRAM (not DRAM) at that time was expensive.

I have scored some amazingly cool milspec SRAM chips from eBay that are from 1988. They *WORK* in the VGA version! In fact they are already 3 times faster than required for that (25ns while 70ns needed). They must have cost a fortune back then.  I did go through a lot of old BYTE magazine's component ads: you can't find such amazingly fast specs in the commercial offerings at the time... Nothing even close.

  Are you sure? yes | no

hosabike wrote 05/09/2018 at 07:33 point

Thank you very much for your answer, Marcel. So, it was virtually impossible to build in 70s, wasn't it? May be use magnetic core memory instead?

About TV signal - may be it's possible to DIY assemble a simple display device with Gigatron resolution 160*120 (even monochrome) on the 80's technologies? This would solve a TV problem.

And the second question. How hard is it to code BASIC interpreter on this machine? It does have it's own assembler, AFAIK.

The same question applies to OS.

  Are you sure? yes | no

Julian wrote 05/24/2018 at 03:15 point

"First but not foremost is that the RISC architecture was not recognised as commercially viable until much later, like 1985 or so."  --- I suspect you're right about this, despite the fact that the clearly *were* people in the industry who knew this was the best approach.  Seymour Cray had been building designs that were effectively RISC systems and which dominated the high performance computing world from the mid 60s right up to the end of the 80s, but nobody else really seemed to understand what lesson to learn from that.

"Second is that the real hero in this design is the RAM chip.  [...] The total system would have been expensive because 32KB SRAM (not DRAM) at that time was expensive."

For reference of how expensive: I found an advert from Dec 1981 (which would probably have been about the last date a machine like this could have launched and been commercially successful -- any later and it'd have to compete with the C64) that priced 70ns SRAM at $30/4kilobits, so you'd be looking at about $2000 worth of RAM to build this machine at the time.  That said, I wonder how well it would work with, say, 8KB of fast SRAM for critical parts of the system and 16-64KB of slow DRAM for bulk storage, which would put the build cost at approximately the same price as the retail cost of a C64 at launch.

Updated: I found another advert from 1981 that suggests the first price I found was ridiculously over the top -- although I'm making some assumptions in interpreting it -- Byte vol 6 issue 11 has an advertiser on page 546 selling "2147" chips for $3.15 each... there are multiple manufacturers who used that number, but of the ones I've looked at (Intel and Mostek), 70ns was the slowest they were still producing in 1981 (Mostek had a 90ns variant in 1979, but seemed to have dropped it by 81), so I'm making an assumption that these were in fact 70ns chips.

  Are you sure? yes | no

Marcel van Kervinck wrote 05/10/2018 at 00:01 point

With pure 1970s components the CPU section could certainly be built using 74LS parts, but something else has to be done around the RAM. At least make it DRAM, slow down the clock to match (which might be ok for slower TV signals). It is difficult to really go back to that era, because RAM chips of those days are practically unavailable now. So it will look a bit different, but either way still be expensive for the 32KB RAM capacity (even if it were DRAM).

About BASIC: it is just a lot of work. Microsoft could become a company precisely because they had done a BASIC and the microcomputers of the day needed it. This project is a bit in the same state. Unfortunately, Bill Gates is doing different things nowadays! There is a proper assembler already written by user at67 on GitHub. It does both the 8-bit native instruction set as the 16-bit vCPU instruction set.

You want several steps:

- Direct or indirect keyboard hookup. Indirect is easy, but a bit cheating. Direct hookup is a harder nut to crack (at least: if you want to stay with the minimalistic spirit of the rest of the system. If not, just use the Arduino).

- BASIC parser/interpreter. Several weeks of full time effort for an "integer basic".

- Some kind of screen editor

If you go all the way, you need to add:

- Floating point package

- Program save capability. (Load is already there.).

  Are you sure? yes | no

hosabike wrote 05/10/2018 at 18:05 point

Thanks again. So is it possible to code some network drivers to connect this thing to Internet? At least it seems capable to support some kind of relatively easy protocols like IRC or whatever.

  Are you sure? yes | no

Marcel van Kervinck wrote 05/24/2018 at 07:07 point

@Julian : I'm interested in that 1981 reference to 70 ns SRAM, because it helps date this project. Do you have a URL or can you scan a copy for me if it is from a magazine?

  Are you sure? yes | no

Marcel van Kervinck wrote 09/29/2018 at 08:17 point

We did more archeology. Personally I always believed that the SRAM was the anachronism in the design, but it turns out not the case: Julian has been digging into old BYTE magazines for us, and surprisingly, 2147 (4096x1bit) "high speed" or "arcade" SRAM was available for $3.15 in... 1981. Ebay lists such parts with date codes as early as 1978. The slowest grade mentioned in data sheets I can find is 70 ns, and the March 1980 Intel application note AP-74 talks about speeds of 55 ns as if it is old news. I'm completely surprised by all of this. It's part of an interesting quest to date the Gigatron.

  Are you sure? yes | no

Hacker404 wrote 09/30/2018 at 11:52 point

Some things -

$3 then is about $20 today or more

It's one bit so you need eight of them, that would be $160 or more

They draw 0.8W@70ns so that 6.4W for 8, better go back and redesign the PSU

DRAM was much cheaper and was generally 100ns, 120ns, 150ns or 180ns - either one or four bit

  Are you sure? yes | no

Bob wrote 04/20/2018 at 15:23 point

Kit worked great, placing the chips in position on the foam like that simplified things hugely and the build manual was very clear - my only soldering error was leaving one pin unsoldered which resulted in a strange offset on the VGA signal, till I spotted it.  I'd be keen to learn more about exactly why it is that for instance this clump of 74xx chips are the ALU and that clump are a register, etc - once that kind of info is made available it could be a great teaching resource along the lines of the excellent Elements of Computer Systems / From NAND to Tetris (https://www.amazon.co.uk/Elements-Computing-Systems-Building-Principles/dp/0262640686) which @monsonite once pointed me towards.

Might I suggest Google Groups as a quick & easy way to get a forum community up?

  Are you sure? yes | no

Marcel van Kervinck wrote 05/10/2018 at 00:24 point

Hi Bob, sorry I missed your update, but I think I saw it on Twitter :-)

We recognise the usefulness for a forum, but we're super busy so we're really in need of helping hands here, otherwise it isn't going to happen anytime soon. If somebody starts one and I like it, I will join threads I'm interested in. I have to say that I find Google Groups disappointing from user point of view, and for this project there are builders and tweakers/hackers and those threads shouldn't mix. The bbCode type of forums are so much nicer in presentation, and they can support two sections under one roof: Assembly and Hacking (no need to divide it up further, I would be against that).

But then also beggars can't be choosers. Now some programming discussions happen on GitHub for example.

  Are you sure? yes | no

Bob wrote 05/10/2018 at 00:46 point

Google Goups seems to work fine for other similar kits / kit makers e.g Oscar Vermeulen's awesome PiDP-8/i is here https://groups.google.com/forum/#!forum/pidp-8 and soon to be joined by PiDP-11/70 here https://groups.google.com/forum/#!forum/pidp-11, Spencer Owen's excellent Z80 kit RC2014 is here https://groups.google.com/forum/#!forum/rc2014-z80, Chris Davis' Altair-Duino is here https://groups.google.com/forum/#!forum/altair-duino, Julz' Forth-based Fignition is here https://groups.google.com/forum/#!forum/fignition, etc - I imagine a number of your customers / readers are, like me, already denizens of these places.

  Are you sure? yes | no

Marcel van Kervinck wrote 05/10/2018 at 01:03 point

I'm aware. Let me say I have just have no real positive experiences with Google Groups. The groups I know and sometimes check out feel disconnected to me and the overview and content presentation is poor, as if it is still running on Usenet. Also no inline images, no markup. I find it frustrating to use for technical content, and therefore groups is not something I would personally frequently checkout and become like a home.

  Are you sure? yes | no

Marcel van Kervinck wrote 05/10/2018 at 08:21 point

We could be looking into bbPress as forum plugin for on the main site... Any experiences with that? Good or bad?

  Are you sure? yes | no

Marcel van Kervinck wrote 05/12/2018 at 19:56 point

We're looking at phpBB now... Either self-hosted, or we're going for a rental scheme.

  Are you sure? yes | no

lion mclionhead wrote 04/14/2018 at 20:41 point

Interesting video from 8bit guy.  It's sort of extraordinary that the gigatron outperforms a VIC 20 using only discrete logic gates for a CPU, but the trick is using modern memory chips & cost.  If it just drove a serial port instead of driving a CRT, it could run much more powerful demos.  8 bit guy was hard on it because he only saw the default firmware spending all its clockcycles driving the CRT.  

  Are you sure? yes | no

Marcel van Kervinck wrote 04/14/2018 at 21:02 point

We absolutely love his episode! We don't think he is hard on it at all... He presents the project in a superb manner. As he mentions at the end, the programmability is a matter of software, and it is the next phase of the project. The Apple-1 didn't come with a built-in BASIC either, for the same reason: it takes time to build a software environment.

  Are you sure? yes | no

Ruud van Falier wrote 03/27/2018 at 09:57 point

Such a cool project and also very extensive!
Ordered the kit and built it this week: https://twitter.com/BrruuD/status/978355534033227777/photo/1

Now for diving into the mechanics and figuring out how everything works exactly :-)

  Are you sure? yes | no

Marcel van Kervinck wrote 03/27/2018 at 10:18 point

So cool to see it work!

  Are you sure? yes | no

[deleted]

[this comment has been deleted]

Marcel van Kervinck wrote 02/24/2018 at 21:52 point

Thanks :-) It can make proper bleeping sounds though. It has 4-bits sound output (16 levels) and the default loop squeezes 4 software channels through that. They can synthesise pulse, triangle, sawtooth, etc. It sounds crappy but charming, just right!

  Are you sure? yes | no

Marcel van Kervinck wrote 12/26/2017 at 07:12 point

Anyone attending 34C3 in Leipzig this week: we will be strolling around, and of course we'll bring Gigatron prototypes!

  Are you sure? yes | no

monsonite wrote 11/08/2017 at 18:28 point

Hi Marcel,

Great work!  Faster, simpler and cheaper than the original IBM PC - love it!

Is there a schematic available for your design?  I'm interested in the final approach you took for your ALU.

Interested to hear some more about the virtual machine you hinted upon.

I have shared your work with anycpu.org

Well Done

Ken

  Are you sure? yes | no

Marcel van Kervinck wrote 11/08/2017 at 19:10 point

The full schematic might appear in some later stage as it is quite a mess in need of serious cleanup and I'm working on software the upcoming weeks. But the ALU is described adequately elsewhere: the "Logic" stage comes from here  http://www.6502.org/users/dieter/a1/a1_4.htm  (bottom of the page) and the ALU uses two of those with two 4-bit adders, as described here: http://www.6502.org/users/dieter/a1/a1_6.htm  except that my design does without the 3rd stage that only provides right-shifting. So in total it is 8x'153 and 2x'283 with 5 control signals going in. Dieter's pages suggest that you need 8 signals, but most of them have the same value for the common operations. The carry-out goes back into the condition decoder where it acts as an allzero-indicator during jumps. There is no flags register as it costs too many chips for too little added value. I do right-shifting in software using the "single-instruction subroutine" technique described in the log on pipelining. This computer doesn't need shifting that much because the graphics layout is 1 byte = 1 pixel.

  Are you sure? yes | no

monsonite wrote 11/11/2017 at 18:33 point

Hi Marcel,

I'm suitably impressed with the elegance of your design that I have taken time to transcribe it to EagleCAD, so that I can get a better understanding of the control and data paths.

After pondering your Control Unit schematic for an hour yesterday lunchtime, and how it decodes the ALU instructions and generates the various addressing modes and jumps, I was happy that I could figure from the bus and dataflow diagram how most of the rest of it worked. 

Now that the bulk of the design is captured, I'm figuring out a way of using an ATmega1284 as an easy to update ROMulator device, running code from faster RAM and a way of extending by adding more VRAM.

When you consider that the first Sinclair ZX80 machine took 18 TTL chips, plus Z80, ROM and RAM to create a monochrome TV picture of 32 x 24 8x8 characters, for just another 18 chips they could have replaced the Z80 and had something that produced colour graphics and ran at 4 or 5 times the speed.

regards

Ken

  Are you sure? yes | no

Justin Davis wrote 01/02/2018 at 16:51 point

I don't think schematics are ever really "finished", but the schematic that the layout was made from would be most helpful even if it is a mess.  I would like to see them because I would like to try to recreate it in an FPGA.  You could post them now, and then replacement them with a cleaned up version once you have it finished.

  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