Last visit was: Fri Sep 17, 2021 9:58 pm
It is currently Fri Sep 17, 2021 9:58 pm



 [ 26 posts ]  Go to page Previous  1, 2
 Gigatron - A TTL machine with integrated VGA 
Author Message

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157
Hi All,

I've had my Gigatron for about a year, bought initially to jumpstart my learning about TTL computers.

In just 34 basic TTL chips - here was a machine that could compete with commercial machines based on microprocesors, such as the 6502 or Z80, yet had a much simpler and more easily understood architecture.

I was intrigued how a practical computing machine could be designed in fewer than 1000 logic gates.

It is of special interest because it's fetch and execute are combined in a single clock cycle - the simplest form of pipelining, and a neat trick to gain performance from the simplest hardware, and allow it to outperform most of the late 1970's microprocessors.

I purposefully built up the pcb entirely with IC sockets, so that modifications and updates could be easily done.

The clock crystal was also socketed, and so I quickly experimented with higher frequency crystals - 8MHz and 10MHz - above the stock 6.25MHz which was selected for VGA video timing requirements. Without changing any other component, the standard build using 74HCT series logic would clock and execute code at 10MHz.

Over some time, I managed to obtain a 10nS RAM, a 74Fxx series set of ICs and a 45nS ROM. With the original 100nS ROM in place and the 74F set of ICs, I found that the machine would run on an 11.0592MHz crystal - but not on a 12.00MHz crystal.

I assumed that the design was limited by the ROM access time - but this was not the case.

Yesterday I received the 45nS ROM - programmed for me by the Gigatron creator Marcel van Kervinck. When this was plugged in - I could still not achieve operation above 11.0592MHz.

The Gigatron uses diode-resistor logic in its instruction decoder. The low to high time of this diode network is constrained by the value of the pull-up resistors. By reducing the pull-ups from 2K2 to 600 ohm, I was able to get the machine to run on a 12MHz crystal.

In this overclocking experiment - the next base was 200%. Would it run on a 12.5MHz crystal? The problem is that 12.5MHz crystals are not very common - and my parts bin lacked a 74HCT74 flip-flop that I could use to divide down the 25MHz crystal that I had at hand.

I decided to improvise, and remembered the newly purchased Nucleo 743 board that has a
400MHz ARM Cortex M7 on board. Surely this could be used to create a 12.5MHz clock? A quick hack with the Arduino IDE - I soon had a pin toggling at just a little above 12.5MHz.

With a quick modification to the Gigatron clock circuit, I applied the 12.5MHz clock and the machine sprang to life - executing its familiar Blinkenlights routine. A couple of scope measurements confirmed that the VGA horizontal sync was now running at 62.5kHz and the pixel time was 80nS - confirming that the machine was executing its main loop and generating video - at twice speed!

The Gigatron was designed to generate VGA compatible colour video from a minimum of standard 74HCT logic, SRAM and ROM. It does this with fewer than 40 ICs. However the task of generating video is cpu cycle intensive - and so the cpu has very little time left for actual application processing - be it TinyBASIC or whatever.
If the machine were to be freed from the arduous task of video generation - possibly using some other hardware such as a Raspberry Pi or BBC Micro - then it would be quite a fast TTL cpu - of sub-100nS instruction time.

The Gigatron is laid out on a 6" x 9" 2-layer pcb - very similar to the original Apple 1. The TTL devices are standard DIP packages with 0.1" pitch. This type of arrangement suits DIY construction, but the generous IC spacing, long bus lengths and lack of complete power and ground planes does not lead to a high performance design, and EMC emissions are mostly unsuppressed.

Reducing the package size to SOIC SMT devices would allow a shrinking of the pcb to about 6" x 4" - or even smaller if packages were placed on both sides of the pcb. The inspiration for this type of construction is the remarkable C74-6502 project which puts a TTL 6502 on two pcbs and runs at up to 20MHz: https://c74project.com/

The Gigatron has been a fascinating insight into what can be achieved in TTL. Unshackled from video generation, it would be a very capable processor.


Sat Apr 13, 2019 11:22 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1632
Interesting thoughts. (And, a lot of transistors to spend on making a fast clock generator! But that's not a serious point)

It looks like the original Gigatron had a scanlines effect - one in four video lines is black - which frees up 25% of the CPU time to run the VM which in turns runs applications. I guess a scanline buffer - a nice long shift register - would make that 75%?

A double-speed CPU only gets double speed if the same scanline trick is used. Although possibly it can do much more work during vertical retrace - does that get used at all?


Sun Apr 14, 2019 7:21 am

Joined: Sat Mar 31, 2018 7:31 pm
Posts: 6
It generates 521 scan lines per frame, of which 480 are visible for pixels and 41 invisible for vertical blank. The vCPU runs in each of the invisible lines. Depending on the video mode, vCPU can also run in 25%, 50% or 75% of the visible lines. You then have 1, 2 or 3 black lines for every 4 VGA lines.

Ken's setup is twice as fast, but that also means his monitor can't keep up with the faster video signal. A solution can be to send out more pixels per visible scanline, and to give the vCPU longer time slices between horizontal pulses.


Last edited by marcelk on Mon Apr 29, 2019 11:55 pm, edited 1 time in total.



Tue Apr 16, 2019 6:14 pm

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157
Hi All,

This weekend we got two Gigatron machines running at 12.5MHz or better.

I managed a rather jittery 12.5MHz whilst Marcel's machine built on a 4 layer board managed 15MHz.

The increase in clock frequency means that the video display only takes half of the CPU time, leaving 200 cycles at the end of each video line to run the application code.

An BASIC count-to-1000 program that took 8.5 minutes now runs in 25 seconds. A Mandelbrot plot that took 19 minutes now executes in just 3.5 minutes.

Follow the overclocking progress at the Gigatron Forum:

https://forum.gigatron.io/viewtopic.php ... 3&start=10


Last edited by monsonite on Tue Apr 30, 2019 6:58 am, edited 1 time in total.



Mon Apr 29, 2019 5:34 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1632
Thanks for the link to that thread. An excellent result! (Link within that thread to an in-browser emulation of the fast machine.)


Mon Apr 29, 2019 5:42 pm

Joined: Mon Aug 14, 2017 8:23 am
Posts: 157
As an update to the Gigatron TTL Computer Project, late last night, Marcel the project founder announced the development of a 6502 emulator, "v6502" residing in ROM.

It's not going to be fast - probably about 1/10th the throughput of a 1MHz 6502, but it can interoperate with the existing vCPU, which handles the video timing.

The discussion thread can be found here:

https://forum.gigatron.io/viewtopic.php?f=4&t=128


Attachment:
Benders_Brain.JPG


You do not have the required permissions to view the files attached to this post.


Sat Jun 15, 2019 11:34 am

Joined: Sat Mar 31, 2018 7:31 pm
Posts: 6
monsonite wrote:
but it can interoperate with the existing vCPU, which handles the video timing.

You can say there are three software entities in the system:

  1. The video driver, which also generates audio signals and handles the input port.
  2. The original 16-bit vCPU
  3. The new 8-bit v6502

There is no real hierarchy amongst these three. They pass control to each other in coroutine style, through references in the zero page.

Native 8-bit coding on the Gigatron is much like composing music. Both melody and rhythm must work out. It's much more fun to do than 16-bit coding. An additional fun factor is exploiting the branch delay slot. It not only gives speed and more compact code, but it also enables things that wouldn't be possible without it (jump tables and random access data reads from the program ROM come to mind).


Sat Jun 15, 2019 11:54 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1632
Marvellous!


Sat Jun 15, 2019 6:20 pm

Joined: Sun Jul 05, 2020 9:00 pm
Posts: 15
monsonite wrote:
One speed limiting factor will be the speed at which the ALU can propagate the carry when adding two large 16-bit numbers.


What might be helpful here would be using additional adder chips and multiplexers to create a carry-skip adder. That might even come in handy on the original Gigatron for overclocking. Theoretically, someone could design a small board as a replacement for the high nybble adder which includes 2 adders and a multiplexer, perhaps using SMT. Then it could be a performance upgrade for the Gigatron.

I might want to build a Gigatron, however, the kits are no longer available. RIP Marcel!


Sun Jul 05, 2020 9:21 pm

Joined: Tue Dec 18, 2018 11:25 am
Posts: 40
Location: Hampshire, UK.
From the Gigatron website (https://gigatron.io/?page_id=86):-

Quote:
A Dutch firm is planning to sell basic kits (PCB, components including pre-programmed EPROM, so without controller, manual, enclosure) in a few weeks from now.


Sun Jul 05, 2020 9:40 pm

Joined: Sun Jul 05, 2020 9:00 pm
Posts: 15
There are other ideas if one wanted to widen the Gigatron in addition to using fast carry adders wired to create skip carry adders:

1. You could have a way to stop the program counter for wider arithmetic, and also a way to override pausing the counter with a way to detect 8-bit operations. So if you are only using 8-bit operands, it could work like the original Gigatron by taking 1 cycle without waiting on the higher bits. So bit-banged 8-bit video still works as expected, and 16-bit instructions would still be faster than needing to emulate them in software.

2. If the ALU takes 2 cycles to complete for wider computations, then why not have 2 ALUs and 2 accumulators? To tell them apart without increasing the complexity of the control unit, you could use the lowest bit of the program counter to determine which one is used. So have odd and even ALUs and accumulators. You'd have to be more careful with the coding to make sure you are using the correct ALU/Acc set. Thus you could pipeline the operations to where you'd have a result in every cycle.


Thu Jul 09, 2020 5:06 pm
 [ 26 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: CCBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software