And again a new Gigatron fan

A place to eternalise your Gigatron build photos. From box to BASIC.
Forum rules
Use this forum to show off your build photos. For build issues, please consult the directions in the sticky post on top instead.
Hans61
Posts: 27
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

And again a new Gigatron fan

Post by Hans61 »

06.jpg
06.jpg (1.18 MiB) Viewed 1151 times
07.jpg
07.jpg (217.29 KiB) Viewed 1151 times
On 30.11.2020 I accidentally came across the Gigatron on the Internet. I immediately ordered the kit from budgetronics.eu, it was a black board. A friend also built me a wooden case.
01.jpg
01.jpg (1.45 MiB) Viewed 1151 times
02.jpg
02.jpg (1.54 MiB) Viewed 1151 times
03.jpg
03.jpg (1.36 MiB) Viewed 1151 times
04.jpg
04.jpg (1.21 MiB) Viewed 1151 times
05.jpg
05.jpg (835.61 KiB) Viewed 1151 times
10.jpg
10.jpg (1.11 MiB) Viewed 1151 times
12.jpg
12.jpg (843.9 KiB) Viewed 1151 times
Something about me,
I am Hans, I was born in 1961 and grew up in a small town near Dresden in the east of Germany. Unfortunately I don't speak English, so I have to resort to the Google translator or DeepL. Please forgive me.
I learned the profession of an "electronic technician" 42 years ago and later I got a degree as an "IT specialist for application development".

First of all, if the fathers/originators don't mind and there is a need for finished Gigatron's and peripherals I would sell some. I also don't want to make a profit with it. Even if many don't understand, soldering is relaxation for me. I think I would sell a Gigatron for 100€ and a PluggyMcPlugface for 10€ plus shipping costs from Germany.

Gigatron changes
I think one should not overdo it there. The Gigatron should remain the Gigatron. In any case downward compatible.
My suggestions/wishes
1. the simple extension to 64k should be on the PCB, CS2 on VCC and for A16 a jumper. Then you would have the choice between 32k and 64k (128k chip) directly on the PCB and you would not need the line for A15 at the "expansion bus" extra.
2) I think there are already good games for the Gigatron. With a game you need a goal and an incentive. With "Racer" I miss the goal, for me it's more a nice interactive graphic demo. My favorite is Tetronis. The incentive is the highscore. It would be nice if it could be saved. One approach for me would be to equip the Gigatron with a SPI EERPOM on the "Expansion bus" board or the PluggyReloaded with a I2C EERPOM/FRAM. Or to use the SD card on the PluggyReloaded. You need software/administration for this again of course. For the software interface I see 3 possibilities: fall back on a file system, allocation of the data over a simple ID, orientation at the cookie from the WWW.
3. graphic resolution
With the Gigatron I am already impressed what is possible with a resolution of 160x120 pixels. For the porting of old games I would wish for more. Whereby a doubling would be the upper limit for me. A doubling of the resolution means a quadrupling of the amount of data, which has to be handled by "jump and run games".
My simplest thought would be to double the clock to 12,5Mhz and to add a divider to 6,25Mhz. The 6.25 then goes on to the Gigatron normally. With the 12,5Mhz a multiplexer is controlled, which splits the 6 bits of the colors into 2x 3 bits. This would require hardly any software changes at first. But in this case the dots would be rectangular, which wouldn't be nice either.

I realize I'm starting to write a novel, and that certainly doesn't fit in this forum. I still have a lot of things going around in my head that I would like to share. I still have an old blog, maybe I'll do something in German about the Gigatron.
Just a quick thought about the "expansion bus". The board now supports 128k RAM, which is more than enough for the Gigatron. What I think I have seen is that they are working on an 8080 vCPU. With a CP/M a RAM disk would be very advantageous. 64k for it is a bit low though. If there is an easy way to support larger RAM's, that should be considered now. But maybe there is a better solution then for it over SPI.
My personal goal is also to write code for the Gigatron, also native, but I still have a long way to go.
Finally, then I really stop. I am a fan of the Apple II and of Steve Wozniak. I also bought his book iWoz. I think his hardware solutions of the Apple1, Apple2 and especially the floppy control are unbeatable brilliant.
bmwtcu
Posts: 54
Joined: 01 Nov 2018, 12:02

Re: And again a new Gigatron fan

Post by bmwtcu »

Welcome Hans! Nice work!

"soldering is relaxation for me" - I totally get it! It's exactly the same situation for me. Nothing beats the leaded solder fume high:P

Doubling the clock in hardware is the easy part. The VGA timing is tied to instruction count, and deviating from the current architecture is going to require major software retooling, which is probably why Marcel never took it further that the ROMv3y experiments with 12.5MHz.

However, if you build it, they will come. Might I suggest that if you are going to be releasing custom kits, that you consider feeding a 25MHz oscillator (commonly used for Ethernet clock) clock into a 74LS74 and use each DFF to divide the 25MHz clock by two successively, then use jumpers to select the /2 output and /4 output respectively so that others will have a hardware platform on which to write said VGA timing code for 12.5MHz, but will still be able to enjoy 6.25MHz software compatibility. If anything the 25MHz will be easier to source cheaply than the 6.25MHz crystal.

Cheers!
walter
Site Admin
Posts: 117
Joined: 13 May 2018, 08:00

Re: And again a new Gigatron fan

Post by walter »

Hi Hans,

You made three of them right away? (Black, blue, orange)

Your wooden box is nice, nicely build.

Darn, now I want a blue and orange PCB for my collection of Gigatron stuff :)
Hans61
Posts: 27
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: And again a new Gigatron fan

Post by Hans61 »

Hello Walter,

thank you for your compliment. I will gladly give you two blank PCB in yellow and blue, just give me an address. The yellow looks better than I expected (goes more so into the golden) had only the white font can not be read so well. I didn't see anything where you can change that at JLCPCB. I will probably make another one in red. So far I have soldered 2x yellow, 2x blue and the kit in black. Then 2x PluggyReloaded, 3x "Expansion bus" and 3x PluggyMcPlugface. Compliment the Gigatron PCB is very replica safe I didn't even have problems getting it up and running. The "Expansion bus" made me a bit desperate at first. I had read late that you had changed the wiring. I am with the PCB so far in the Eagle, in KiCad I have to learn. I have already made small changes to the PluggyReloaded, but I am still waiting for the delivery. The Arduino Pro Micro is much cheaper in China, but there it is 2.54mm wider in the grid.

The article High resolution mode? (viewtopic.php?f=4&t=45) I have just seen. I guess I was a bit hasty, I'll have to take another look at it. A higher resolution would already be important to me for easier porting/after programming for games. I think the games have also helped the home computer at that time only to the broad breakthrough. The Apple 2 had a resolution for games of 256x192 pixels. If you would display 192 lines at 320x240 pixels VGA you would still have 48 lines left for computing. My favorite jump and run game was Lode Runner. I programmed it 40 years ago on my own Z80, because I liked it so much. Another game which still inspires me today was "Robot Odyssey". I haven't found anything comparable on a PC until today. In this game you had a construction kit with standard TTL circuits, with which you had to build controllers for three robots to solve different tasks. You can still play it today in an emulator if you don't have an Apple 2.

@bmwtcu: Thanks I love the smell of rosin(colophony)
walter
Site Admin
Posts: 117
Joined: 13 May 2018, 08:00

Re: And again a new Gigatron fan

Post by walter »

Wow, lots of soldering! But I also enjoy soldering. My latest project was this one: https://www.tindie.com/products/kilpela ... r-arduino/

Soldering *and* weaving cores, fun!

And thanks so much for your offer to send PCBs to add to my 'shrine'! I'll send a DM.
Hans61
Posts: 27
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: And again a new Gigatron fan

Post by Hans61 »

Is there a special thread about sprites? I don't know if I should ask all the questions in this place. I'll just do it.
To me, a sprite is a graphic that I can move around the screen without "breaking" the background.
I'm not sure, but as far as I've read that's not the case with the sprites we have.
When I'm programming a game, though, this would be important to me right now. Especially with jump and run games.
How the sprites work now on the Gigatron I don't really know.
The Apple 2 had support for sprites, these were defined as small graphics, which were defined as vectors from the starting point. One byte always contained more than 1 pixel. You could specify the neighbor pixel starting from the current pixel and whether it should be set or not.
I had earlier thought of hardware support for this on the Apple 2. But I'm sure now that it's not.
So the Apple supported sprites and didn't break the background and it didn't need extra memory for it.
I think it is done this way, bits of the sprite, whether as a vector or as a bitmap are XORed with the background. This makes the sprite appear. Now if you do this a second time in the same place, then the background is restored without needing any buffer memory for it. I think the Apple 2 benefited from having only 4 colors in the high resolution. Because then it comes to unwanted effects if a picture element of the background collides with a sprite.
But I see it in many Apple games and there are quite cool effects with only 4 colors.
This is just a food for thought. From my Z80 times with 2 Mhz clock I made the experience that for fast games a save and restore of the background is too slow.
Translated with Deepl, I hope I am to understand
[The back translation with Google is horrible, I try to express myself understandably]
Hans61
Posts: 27
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: And again a new Gigatron fan

Post by Hans61 »

What I noticed while building the Gigatron
- In ROMv5a Pictures does not work, also not in the emulator
- with physical RAM 64k or 128k ROMv4 always shows 64k and ROMv5a always 128k
- under Debian 10 I had to remove the space in the Makefile at:
minipro -p 'AT27C1024 @DIP40' -w "ROMv4.rom" -y -s
to
minipro -p 'M27C1024@DIP40' -w "ROMv4.rom" -y -s

But maybe these things are already known.
at67
Posts: 332
Joined: 14 May 2018, 08:29

Re: And again a new Gigatron fan

Post by at67 »

Hans61 wrote: 28 Feb 2021, 20:48 Is there a special thread about sprites? I don't know if I should ask all the questions in this place. I'll just do it.
To me, a sprite is a graphic that I can move around the screen without "breaking" the background.
I'm not sure, but as far as I've read that's not the case with the sprites we have.
When I'm programming a game, though, this would be important to me right now. Especially with jump and run games.
How the sprites work now on the Gigatron I don't really know.
The current sprites are really just memory blit's that blit stamp from an optimised data format to the gigatron's screen format, (start, width, height, pitch, etc), they are quite flexible though and that they can flip along both axis and be used to make non background restoring software sprites of practically any size, (until you run out of RAM or FPS).
Hans61 wrote: 28 Feb 2021, 20:48 The Apple 2 had support for sprites, these were defined as small graphics, which were defined as vectors from the starting point. One byte always contained more than 1 pixel. You could specify the neighbor pixel starting from the current pixel and whether it should be set or not.
Bit expanding blitters are quite common and useful as they form a very fast and efficient way of compressing your source data down to one effective bitplane instead of 8 effective bitplanes, (for the gigatron), so effectively 8:1 lossless compression for text characters and mono colour sprites.
I am working on bit expanding sys calls for the latest experimental ROM and more sprite routines.
Hans61 wrote: 28 Feb 2021, 20:48 I had earlier thought of hardware support for this on the Apple 2. But I'm sure now that it's not.
So the Apple supported sprites and didn't break the background and it didn't need extra memory for it.
I think it is done this way, bits of the sprite, whether as a vector or as a bitmap are XORed with the background. This makes the sprite appear. Now if you do this a second time in the same place, then the background is restored without needing any buffer memory for it. I think the Apple 2 benefited from having only 4 colors in the high resolution. Because then it comes to unwanted effects if a picture element of the background collides with a sprite.
The XOR trick is a great way to reduce the number of blit stamps/op's required for a traditional blit save-stamp-restore cycle down to stamp-stamp cycle, but it is highly source and destination colour dependent. i.e. the output you get is determined by an XOR of the inputs, most programmers don't want to have to judiciously and painstakingly choose the right combinations of background and sprite colours so that XOR doesn't produce a mess. They just want to be able to use any colours within the gigatron's palette and have the output make sense.
Hans61 wrote: 06 Mar 2021, 11:23 - In ROMv5a Pictures does not work, also not in the emulator
The pictures application was changed for ROMv5a and DEVROM to use smaller pictures and a scroll effect to make room for the 6502/MSBASIC/etc. They work fine for me.
Hans61 wrote: 06 Mar 2021, 11:23 - with physical RAM 64k or 128k ROMv4 always shows 64k and ROMv5a always 128k
ROMv4 and below do not understand the concept of an expansion card or expansion RAM and are missing the associated firmware and vCPU code functionality. ROMv5a and DEVROM have a display bug when it comes to 128K of RAM.
Hans61
Posts: 27
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: And again a new Gigatron fan

Post by Hans61 »

Thanks for this information. The XOR and sprite thing is of course very dependent on the colors and background. I still have a lot to learn about the Gigatron, I've only known it for 3 months. After the hardware, I want to get more involved with programming the Gigatron. I find the emulator from at67 very helpful for this. I compiled the current sources under a Debian 10 system which ran without problems. Under Windows 10 I installed Visual Studio 19 and also tried to compile the sources. After setting the Windows environment variables for the SDL (thanks to the forum) it also worked. When I start the emulator on another PC (without Visual Studio) I get the error of a missing VCRUNTIME140_1D.dll. With the download from the built at67 (viewtopic.php?p=1254#p1254) I don't have this. Is there a trick to get this into the executable?
What else I noticed, when I translate the CMakeLists.txt with the Visual Studio 19, then the tools are not automatically translated with, I have to translate each separately, but it works fine then. If I do with cmake-gui everything is compiled without errors, but the result stutters in the sound and the image build is sluggish.
at67
Posts: 332
Joined: 14 May 2018, 08:29

Re: And again a new Gigatron fan

Post by at67 »

Hans61 wrote: 14 Mar 2021, 18:20 Thanks for this information. The XOR and sprite thing is of course very dependent on the colors and background. I still have a lot to learn about the Gigatron, I've only known it for 3 months. After the hardware, I want to get more involved with programming the Gigatron. I find the emulator from at67 very helpful for this. I compiled the current sources under a Debian 10 system which ran without problems. Under Windows 10 I installed Visual Studio 19 and also tried to compile the sources. After setting the Windows environment variables for the SDL (thanks to the forum) it also worked. When I start the emulator on another PC (without Visual Studio) I get the error of a missing VCRUNTIME140_1D.dll. With the download from the built at67 (viewtopic.php?p=1254#p1254) I don't have this. Is there a trick to get this into the executable?
Use the following link for PC's that are missing Visual Studio C runtime, download x86 if you built for 32bit and are running 32bit Windows or x64 for 64bits: https://support.microsoft.com/en-us/top ... f26a218cc0
Hans61 wrote: 14 Mar 2021, 18:20 What else I noticed, when I translate the CMakeLists.txt with the Visual Studio 19, then the tools are not automatically translated with, I have to translate each separately, but it works fine then. If I do with cmake-gui everything is compiled without errors, but the result stutters in the sound and the image build is sluggish.
If you mean that CMake didn't run correctly from the command line but it did from cmake-gui, could you provide an example of the commands you used?

The stuttering/sluggishness, (assuming your PC is fast enough), is most likely because you built a DEBUG version, switch it to RELEASE in Visual Studio's Solution Configuration and that should solve your problem.
Post Reply