Gigatron 512k and more

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
lb3361
Posts: 186
Joined: 17 Feb 2021, 23:07

Re: Gigatron 512k and more

Post by lb3361 »

axelb wrote: 17 Jan 2022, 19:36 Even a resolution of about 256 x 240 would enable us to mimic some Arcade classics like Moon Patrol, Frogger etc…
Double horizontal resolution

In fact, the video snooping logic reads two pixels during each Gigatron cycle. It reads them from the same address but from potentially different banks. The two pixels are then fed into the output register at double the Gigatron frequency. When the two pixels are read from the same bank, they're identical, and we get the usual Gigatron horizontal resolution. If we select different banks, we get double horizontal resolution. The format is a bit annoying because successive even and odd pixels are stored at the same address but in different banks.

Thanks to another version of the GLCC console library, I could try MSCP with double horizontal resolution.


20220116_192852.jpg
20220116_192852.jpg (664.33 KiB) Viewed 1001 times


Double vertical resolution

Doubling the vertical resolution relies on the patched ROM, which, optionally, increments the scanline page number before scanline C. With this scheme, each entry of the video table describes two successive scanlines whose pixels are located in consecutive pages. There is a small problem because there are not enough pages in a single bank to store the 240 rows of the double vertical resolution screen. The solution was to use the highest bit of the page number found in the video table as the lowest bit of the video bank. The full scheme is that one controls the video snooping process with a four bit register XXYZ. Even pixels are read from bank XXYS and odd pixels are read from bank XXZS where S is the high bit of the page number found in the video table and recorded when the Gigatron outputs the first pixel of each scanline.

Another version of the GLCC console library uses the last four banks 12 to 15. Banks 12 and 14 contain the even and odd pixels of the first 120 rows from address 0x800 to 0x7fff. Banks 13 and 15 contain the even and odd pixels of the last 120 rows. Anyway, here is MSCP running with a 320x240 screen able to show 30 lines of 52 characters.

20220116_180450.jpg
20220116_180450.jpg (372.19 KiB) Viewed 1001 times
Last edited by lb3361 on 17 Jan 2022, 20:28, edited 1 time in total.
lb3361
Posts: 186
Joined: 17 Feb 2021, 23:07

Re: Gigatron 512k and more

Post by lb3361 »

What's next ?

There are two things I would like to pursue in the short term.
  • I would like to code a double resolution Mandelbrot.
  • There is already support for a pulse modulation output that can provide 6 bits audio https://github.com/lb3361/gigatron-lb/t ... gs/pwmtest. This cannot be as good as a dedicated DAC with a well controlled power plane, but it comes for free. Hans61 has already carried out some tests. It is not obvious to find a sound program that actually makes use of the six available bits. At67's midi code is optimized for 4 bit outputs. His expertise would be invaluable.
There are a lot of interesting things that one could do. Please feel free if you feel like it. I am getting burned out...
  • Transparent layers. Instead of using the two pixels for double resolution, one could use them to implement a background layer and a foreground layer with a transparency bit in the unused high pixel bits.
  • Hardware sprites. This requires more work. This might even require going to the next CPLD size (i.e. a XC95288XL). Like a true C64 :-).
  • Fancy audio. Besides 6 and 8 bits audio, one could envision something that matches the sound chip of a C64.
  • Hardware assisted SPI. Increasing the SD card read speed by a factor of 10 maybe.
  • vCPU instructions that directly access other banks, e.g., PEEK and POKE with far pointers. Again this is at67's expertise.
Finally it is also clear that this board does not represent the TTL spirit of the Gigatron. It was just intended as a playground for crazy ideas. In fact, for me, the Gigatron itself has been a playground to learn and make things. It might be something else for other people. Maybe somebody will maybe produce new kits that appeal to a large audience. All good for me...
walter
Site Admin
Posts: 137
Joined: 13 May 2018, 08:00

Re: Gigatron 512k and more

Post by walter »

Just to be clear: by saying the design is different I didn't mean to say that is a bad thing.. it is wonderful to see people inspired by the Gigatron and how the Gigatron provides a reasonable easy entry point for people to extend stuff and try out ideas. Having you or anybody else create something new and making it into a kit is also great, I encourage people to do that! And when it's just for fun, that is fine as well of course. But I would see this more as the start of a new kind of design, which is what I was trying to say. Haven taken the step to radically change the design, you could also go further with the rest of the hardware/software.
lb3361
Posts: 186
Joined: 17 Feb 2021, 23:07

Re: Gigatron 512k and more

Post by lb3361 »

walter wrote: 17 Jan 2022, 20:45 Having taken the step to radically change the design, you could also go further with the rest of the hardware/software.
That's the problem, isn't it? There are no limits to radical change. Limits are what make the Gigatron approcheable.

I had limits. The CPU is still made of the same bunch of diodes and 74 series ICs. It runs the same software, including the ROM. Although a new ROM can take advantage of new hardware capabilities, they are implemented by a daughter board that claims to be a SRAM. Although it cannot plausibly claim to be a TTL design (the SRAM cannot either), it does not contain another microprocessor (the Pluggy does).

In the end, we need to answer the question "what makes the Gigatron attractive" to know what the limits truly are. There are many answers....
bmwtcu
Posts: 111
Joined: 01 Nov 2018, 12:02

Re: Gigatron 512k and more

Post by bmwtcu »

lb3361 wrote: 17 Jan 2022, 19:06
bmwtcu wrote: 17 Jan 2022, 03:19 Nice work! Fun fact, I had to do an exhaustive fit, but I got the entire Gigatron (less SRAM and ROM) to fit in the XC95144 part!
This is a nice way to characterize the size of this part. I gave it a try : https://github.com/lb3361/gigatron-lb/t ... razy/bonus. However I could not make the Gigatron fit without moving the serial input register logic into an external 74HCT595. My design comes four macrocells short.
I didn't constrain the pinout, assumed a 32kB SRAM and ROM (which is all I needed to use Pluggy Reloaded) and I did an exhaustive fit. The one and only combination that fit was
"INFO:Cpld:994 - Exhaustive fitting is trying pterm limit: 21 and input limit: 54"
Last edited by bmwtcu on 10 Feb 2022, 11:30, edited 1 time in total.
lb3361
Posts: 186
Joined: 17 Feb 2021, 23:07

Re: Gigatron 512k and more

Post by lb3361 »

Just found a stupid bug. Being able to map different banks for reading and writing seemed very useful for copying data across banks. Just set NBANKR to the source bank, NBANKW to the destination bank, and use memcpy. Alas I forgot about a common dialect in the ROM, e.g.,

Code: Select all

              0307 0d00  ld   [y,x]       1755  ld([Y,X])                       #6 Fetch opcode (actually a branch target)
              0308 de00  st   [y,x++]     1756  st([Y,Xpp])                     #7 Just X++
The st([Y,Xpp]) is only used for its side effect incrementing X. This works because this store writes back the data read in the previous instruction ld([Y,X]). But this is no longer correct when the read and write banks are different. This idiom is used everywhere in the ROM and that makes my smart banking scheme useless. The code above comes from the vCPU instruction fetch. So long....


Update.
Here are a couple ideas for a revised extended banking scheme. Which one do you think is the best? Is there a better one?
  • Use a single extended banking register that overrides what is shown in range 0x8000-0xffff, but augment the codes to save or restore the previous bank configuration into a hidden register. Pros: quick access to another bank are cheaper. Cons: need a new SYS to copy data between extended banks (as opposed to normal banks.)
  • Bank with 16K granularity with two windows (0x8000-0xbffff, 0xc000-0xffff). Extended banking takes priority over the traditional banking scheme, i.e. specifying bank 0 for a window means that the window shows what's implied by the normal ctrlBits (BANK1,BANK0,ZPBANK). Pros: we can copy across banks with memcpy (SYS_CopyMemory) and a little bit of banking gymnastic. Cons: complicated relationship between 16KB and 32KBN banking.
  • Have the extended banking register say which actual bank is mapped when one selects the traditional banks 00 or 10. Pros: we can copy across banks by using the existing memcpyext (SYS_CopyMemoryExt). Cons: we need two ctrl instructions to write to a specific bank. We might need a new SYS call to do this efficiently from the vCPU.
Zebulon
Posts: 6
Joined: 03 Jan 2022, 09:56
Location: France

Re: Gigatron 512k and more

Post by Zebulon »

lb3361 wrote: 17 Jan 2022, 21:47
walter wrote: 17 Jan 2022, 20:45 Having taken the step to radically change the design, you could also go further with the rest of the hardware/software.
That's the problem, isn't it? There are no limits to radical change. Limits are what make the Gigatron approcheable.

I had limits. The CPU is still made of the same bunch of diodes and 74 series ICs. It runs the same software, including the ROM. Although a new ROM can take advantage of new hardware capabilities, they are implemented by a daughter board that claims to be a SRAM. Although it cannot plausibly claim to be a TTL design (the SRAM cannot either), it does not contain another microprocessor (the Pluggy does).

In the end, we need to answer the question "what makes the Gigatron attractive" to know what the limits truly are. There are many answers....
First of all, I also would like to congratulate you for such a job. It is not coming from nowhere and required lots of time and efforts. At the end it works, it is a piece of art in its kind (just designing it to insert into two distant slots is already challenging) and it keeps the community alive.

As for the question "is it a purist stuff or not", I would say that many developments done around the old 8-bit or even 16-bit computers nowadays could raise the same question... being able to load/save from/to SD cards from a ZX, an Amstrad CPC, all those side-carts for Amiga, etc. It is more or less intrusive and extending capabilities far far beyond the 8/16-bit purist stuff.

So again keep going on your developments and impressing us. Thank you. 8-)
walter
Site Admin
Posts: 137
Joined: 13 May 2018, 08:00

Re: Gigatron 512k and more

Post by walter »

It doesn't need to be purist :) Anything that's fun to do is good! Especially if you or others learn from it.
axelb
Posts: 26
Joined: 07 Jan 2021, 06:27

Memory Banking Scheme

Post by axelb »

Would it be possible to provide a banking of the standard video memory 0x0800-0x7fff, whilst preserving the range from 0x0000 to 0x07ff ? This should allow for a quick switch between two screens if a program resides in the range 0x8000-0xffff. In addition a 12.5 MHz Gigatron could potentially combine the two banks delivering an overall resolution of 256 x 240.
lb3361
Posts: 186
Joined: 17 Feb 2021, 23:07

Re: Memory Banking Scheme

Post by lb3361 »

axelb wrote: 20 Jan 2022, 07:34 Would it be possible to provide a banking of the standard video memory 0x0800-0x7fff, whilst preserving the range from 0x0000 to 0x07ff ? This should allow for a quick switch between two screens if a program resides in the range 0x8000-0xffff. In addition a 12.5 MHz Gigatron could potentially combine the two banks delivering an overall resolution of 256 x 240.
This seems possible, but the banking scheme is getting way too complicated. I am already thinking of dumbing down the zero page banking to a strict minimum because of this. Also we can now change the bank(s) from which the pixels are read. So fast switching is possible by simply preparing a new screen in a separate bank and telling the video snoop to use it. In this new world, the program lives in 0x800-0x7fff which is now entirely free, and the video banks are mapped in 0x8000-0xffff when it is time to read from or write to them. Which video bank is displayed is independent from which bank is mapped in the high address space.

With a 12.5MHz Gigatron, one would have to rewire the PLL config pins to generate a 25MHz clock from the 12.5MHz base clock (instead of generating a 12.5MHz and a 25MHz clock from the 6.25MHz base clock), and one has to entirely rewrite the CPLD program to use these new timings. The main issue is to estimate the earliest point in the cycle at which the Gigatron gives stable addresses, and the latest point at which the RAM can return a result leaving enough time for the ALU. This is affected by many board-to-board variations such as the CLK2/CLK1 delay and the components of the diode forest. In addition, Gigatron read cycles and Gigatron write cycles do not have the same timings because you don't get to see the WE signal before the negative edge of the clock, which comes at variable times because the duty cycle changes a little bit from board to board. This is why I was only able to make two additional reads in the 160ns of the 6.25Mhz Gigatron cycle. The first thing would be to kill the CLK1/CLK2 delay to position these points more consistently. In short, making all this work on a 12.5MHz Gigatron is a project. One also needs an actual 12.5Mhz Gigatron!. Anyway, feel free to copy anything you need from my repository....
Post Reply