Roadmap and status of Gigatron TTL

General project related announcements and discussions. Events, other retro systems, the forum itself...
veekoo
Posts: 126
Joined: 07 Jun 2021, 07:07

Roadmap and status of Gigatron TTL

Post by veekoo »

Hello. I want to discuss about the future of Gigatron TTL coming years.

Do I get right that standard machine is 32K with ROMv5a and it would be better to be upgraded to 64K and offcourse using Pluggy Reloaded you can load programs. These things have full qtbasic and glcc support so we can make programs easily.

I am pretty satisfied with calculation power, graphics and sound so far. Best thing is strong community support. The more people have Gigatron TTLs we have better chance to see new things in it. ROM version 6 is coming probably in near future and then we need compiler support for that.

We have seen all sort of upgrades to machine and probably 128K upgrade could be considered if it had compiler support. Its made of era components so its close to line. Loading programs from sdcard can be done for example with Pluggy Reloaded or it comes with 128K upgrade. Retro machine should have its limits so that it keeps simple, so a line has to be drawn what could be accepted to "in line" machines and then we make compilers/programs for those.

In my own machine use I have noticed that its easy to port C-programs to Linux-X86-PC, so I have been making programs to both machines. If there is need for "more" I use PC to do it. There is no need for Gigatron TTL ver 2.0 with updated pcb and components. I have seen couple of retro machines been developed and soon they are made of FPGAs or ARM-emulations. When there is chance to make a program to fit Gigatron TTL I try it for fun.

I almost forgot that when I tested all the ICs with XGecu Pro TL866II-Plus: IC tester & ROM programmer. I noticed it tested all components with 12MHz and all the working ICs coped with it. Offcourse there is more components and they work in tandem, so over clocking by a notch could be possible.
veekoo
Posts: 126
Joined: 07 Jun 2021, 07:07

Re: Roadmap and status of Gigatron TTL

Post by veekoo »

Now I have studied the 128K RAM upgrade, maybe its too complicated to be considered. No need to update qtbasic and glcc compilers for this upgrade. Many of era retro computers managed with 64K RAM.

Over clocking what I have read is possible at 8 MHz without ROM update. With tweaked ROM update 10 MHz is possible.

But, this is only me talking. I don't what the key figures for example Walter, At67, lb3361 and so on think about what is the roadmap and status for Gigatron TTL.
bmwtcu
Posts: 149
Joined: 01 Nov 2018, 12:02

Re: Roadmap and status of Gigatron TTL

Post by bmwtcu »

veekoo wrote: 09 Feb 2022, 14:05 Over clocking what I have read is possible at 8 MHz without ROM update. With tweaked ROM update 10 MHz is possible.
In my mind, the limiting factor isn't so much ability of the ICs to run at a particular speed, but rather that video timing is hardcoded in the ROM based on instruction count. Depending on how forgiving your monitor is, you stop getting video at pixel clock frequencies significantly higher or lower than 6.25MHz. If you don't care about audio and video, you can run the Gigatron as fast as gate and board delays/timing allow without any retooling of the ROM. I haven't tried but I'm fairly confident from the post-route timing reports that I can run my Gigatron FPGA at 50MHz, but it's just not useful to me without the A/V.

axelb/Hans61/lb3361's efforts on the video repeater and various expansion boards that basically take over the actual video timing and output from the Gigatron seem to be a step in the right direction. It's analogous to 8-bit computers evolving from bit-banging A/V to having dedicated GPU/sound chips for rendering A/V from a buffer. In my opinion, at a minimum it's trivial to incorporate the repeater and get rid of the other video modes in any proposed Gigatron 2.0 effort for a great speed boost without sacrificing video quality even at stock 6.25MHz.

As far as other changes, having the RAM expansion in conjunction with SD Card browser be a default Gigatron 2.0 feature seems like a great update. Personally, I would save some cost by shrinking the ROM down to just what is needed for the ROM+SDCard Browser and just have all gt1s be loaded via SD card. I don't actually know how big that is, but I know that the Pluggy Reloaded SDCard Browser with ROMv5a takes up ~9kx16, so we could shrink from a 128kB ROM to a 32kB ROM.

Just a minor nit, but sourcing the 6.25MHz crystal seems to be an issue in some areas. 25MHz crystals and oscillators are a lot more ubiquitous. I have in the past proposed moving to a 25MHz oscillator through a 74xx74 flip-flop to get /1, /2 and /4 clock options that are jumper selectable, but have not looked into whether not having the asymmetric clock phases and in general whether SRAM timing will pose a problem with the 25MHz clock. It seems to be working in lb3361's crazy expansion with his 512kB SRAM.
lb3361
Posts: 376
Joined: 17 Feb 2021, 23:07

Re: Roadmap and status of Gigatron TTL

Post by lb3361 »

I am going to play the devil's advocate and argue that the Gigatron does not need new features.

First observe that no amount of fixing can make the Gigatron be a better game machine than what could be done around, say, a $5 Raspberry Pico. The point of the Gigatron is not to be a very useful machine. Instead the point is to entertain ourselves with inventive ways to go around its limitations. Could be software tricks, hardware tricks, anything. Without the limitations, what's the point?

Therefore we want a machine that is maybe limited but also very approachable and very hackable. And this is where we can do some work. Some components (e.g. the crystal) are getting hard to find. Other components are close to their end-of-life. There is probably some room for a kit that makes it even easier to build a Gigatron given the changes in component availability. Marcel and Walter did such a great job that I do not see huge changes.

Anyway, the point is that making the Gigatron even easier to build, understand, and hack is far more important than adding complications.
Last edited by lb3361 on 10 Feb 2022, 04:09, edited 1 time in total.
bmwtcu
Posts: 149
Joined: 01 Nov 2018, 12:02

Re: Roadmap and status of Gigatron TTL

Post by bmwtcu »

I agree that the appeal is in its simplicity and there aren't too many changes beyond faster load times compared to the Pluggy Reloaded that I'm really interested in pursuing for my FPGA handheld adventures. I made a quick 39 second video of my Gigatron Bartop Arcade and 17 seconds of it was load time for Space Invaders:P I do intend to dig into your extension-compact work next time I get a chance.
lb3361
Posts: 376
Joined: 17 Feb 2021, 23:07

Re: Roadmap and status of Gigatron TTL

Post by lb3361 »

Hello bmwtcu:

The extension-compact was an abandoned project. I was surprised when Hans61 reported it working. The extension-retro is far more up-to-date and well tested. The extension-crazy is an entirely different league. Anyway, all three can load programs from a SD card at about the same speed. The SPI interface transmits one byte per scanline, whereas the loader protocol transmits one bit per scanline. At67's "invaders.gt1" starts about two seconds after pressing the button to load the selected file. One could also count the time to boot from the SDCard, that is, a couple seconds from reset to having the browser on screen.

Now I realize that you want to see the extension compact because it contains verilog for the expansion protocol. So here is a simplified version: 2 spi ports, no zero page banking, no spi polarity, all ram disabled when sck is high, do nothing on extended ctrl codes.

Code: Select all

output reg nSS0, nSS1;  // spi: device select for two ports
input MISO0, MISO1;     // spi: separate inputs from each port
output reg MOSI;        // spi: common output for both ports
output reg SCK;         // spi: common clock for both ports
input [15:0] A;         // gigatron: address bus
inout [7:0] BUS;        // gigatron: data bus
input nOE;              // gigatron: ram output enable
input nWE;              // gigatron: ram write enable

reg [7:0] RAM[0:0x1ffff];  // the 128k ram
reg [1:0] BANK;            // the bank register

assign MISO = (MISO0 & !nSS0) | (MISO1 & !nSS1);                    // composite miso
wire [16:0] RA = (A[15]) ? { BANK, A[14:0] } : { 2'b00, A[14:0] };  // actual ram address
assign BUS = (nOE) ? 8'hZZ : (SCK) ? { 7'b0, MISO } : RAM[RA];      // bus output, async ram reads

always @(posedge nWE)
   if (nOE)                    // normal write
      RAM[RA] <= BUS;
   else if (A[3:2] != 2'b00)   // normal control codes
      begin 
         MOSI <= A[15];   
         BANK <= A[7:6];
         nSS1 <= A[3];  
         nSS0 <= A[2];
         SCK <= A[0];
      end
veekoo
Posts: 126
Joined: 07 Jun 2021, 07:07

Re: Roadmap and status of Gigatron TTL

Post by veekoo »

lb3361 wrote: 09 Feb 2022, 23:39 I am going to play the devil's advocate and argue that the Gigatron does not need new features.
I think also this way that we should concentrate in the software and ROM versions to be able to get most out of standard 32K RAM machine + ROMv5a. We also need way to load programs and I think Pluggy Reloaded has done this in acceptable way. I have collection folder of games including about 11 titles. Then we have couple of very promising game demos. All of those are very entertaining and have a/v things in it.

Mostly I think we havent seen or the machine is lacking of way to load more stuff during game play. Picture files, sound files and more levels to games.
at67
Site Admin
Posts: 652
Joined: 14 May 2018, 08:29

Re: Roadmap and status of Gigatron TTL

Post by at67 »

I'll add my 2 cents:

- IMHO everyone is free to do what they want, do whatever you like with the Gigatron and share, (or don't), your findings, musings and results with others here on the forum.

- Whatever motivates you to have fun or to learn with the Gigatron, do it, I think that's what Marcel would want.

- If you want your creation, modification or changes to remain 100% compatible with the current software eco-system, then there are some guidelines both in the docs folder in the main repo and here in the forums that you should adhere to.
bmwtcu
Posts: 149
Joined: 01 Nov 2018, 12:02

Re: Roadmap and status of Gigatron TTL

Post by bmwtcu »

lb3361 wrote: 10 Feb 2022, 04:06 So here is a simplified version: 2 spi ports, no zero page banking, no spi polarity, all ram disabled when sck is high, do nothing on extended ctrl codes.
Thanks! I will certainly check it out.
Sugarplum
Posts: 95
Joined: 30 Sep 2020, 22:19

Re: Roadmap and status of Gigatron TTL

Post by Sugarplum »

veekoo wrote: 08 Feb 2022, 16:35 Hello. I want to discuss about the future of Gigatron TTL coming years.

Do I get right that standard machine is 32K with ROMv5a and it would be better to be upgraded to 64K and offcourse using Pluggy Reloaded you can load programs. These things have full qtbasic and glcc support so we can make programs easily.

I am pretty satisfied with calculation power, graphics and sound so far. Best thing is strong community support. The more people have Gigatron TTLs we have better chance to see new things in it. ROM version 6 is coming probably in near future and then we need compiler support for that.

We have seen all sort of upgrades to machine and probably 128K upgrade could be considered if it had compiler support. Its made of era components so its close to line. Loading programs from sdcard can be done for example with Pluggy Reloaded or it comes with 128K upgrade. Retro machine should have its limits so that it keeps simple, so a line has to be drawn what could be accepted to "in line" machines and then we make compilers/programs for those.
The 512K upgrade seems even better, and it removes most of the video overhead.

As for overclocking, the fastest done after extensive mods was 15 Mhz. That was at the edge of stability, but I imagine a simple ALU mod could make that more stable. Just add 2 more chips to the ALU so that bit 7 returns faster. The big problem with overclocking is that the video is bit-banged, just like in the old Apple computers. You'd need a way to make the video asynchronous from the CPU if you want to go to an arbitrary speed.

I proposed a "100 Mhz" Gigatron. If one wants to bit-bang at those speeds, they'd need to add a few more registers and rewrite vCPU to work between the pixels. At 100 Mhz, you could write the same resolution to the screen 16 times in the same amount of time. And looking at the parts, it is possible that 75 Mhz would be closer to tops. To get this to work, the Gigatron would have to be rethought. I proposed a 4-stage pipeline. So that would force a new ROM and changes in how trampoline code is done.

On the I/O, what I'd like to see is merging the Pluggy and the various expansion boards to have the best of both. Use the larger "pipe" of the RAM socket mods while using microcontroller assistance for the I/O tasks that Pluggy gives. Right now, for I/O, you either have very slow access with a coprocessor or reasonable access that can only be bit-banged and needs more code to get to work.

And then a lot of what I am discussing is feature-creep, and yes, retro machines had their limits which made for more creativity.
Post Reply