Gigatron 512k and more

[lb3361]

Well, this board seems to be a good way to realize ideas that had been floating on this forum for years. The surprise is that many of these ideas can be realized by taping the pins of just two ICs: the memory and the output register. The board logic has a complexity that is comparable to the Gigatron itself, but in a much smaller space because most of it happens inside the CPLD.

The surface mount is tricky. I hide them on the bottom face because I do not believe they look good on the Gigatron. For my first board, I used the JLCPCB SMT service for most components and added a few ones by hand. Soldering the SOIC PLL chip was easy. Soldering the denser memory chip was hard for me. I cannot imagine soldering the Xilinx IC by hand. On the negative side JLCPCB is charging increasing prices for the Xilinx IC (from $19 when I first ordered the board to $32 now!) On the positive side, Hans61 seems to have mastered his newly acquired reflow oven.

p.s. -- I recently found this file https://github.com/kervinck/gigatron-ro ... HiresY.txt where Marcel describes the method we now use to double the vertical video resolution.

[bmwtcu]

Just out of curiosity, do you and Hans live near each other to enable you to collaborate, or have you been racking up a big shipping bill?:P

The XC95xxXL parts have been in production for the better part of 2 decades now and still remain a popular choice if you need 5V tolerant IO. There haven't been ?many/any? new 5V tolerant programmable logic options for just as long, so my guess is once the existing stock of Xilinx/Altera/Lattice 5V parts are gone, we're looking at level shifters in conjunction with migrating retro computing to small 3.3V and below FPGAs. (Or just redo the whole design in FPGA) With the global chip shortages currently going on, it's more profitable for manufacturers to make newer smaller lithography parts since the same size silicon wafer will yield more parts which equates to higher profit. I've been seeing issues especially over the past year getting older parts from even big names like Qualcomm, TI and ST, so I wouldn't be surprised if the parts are eventually EOLed.

It does take time for me, but SMT isn't too bad with a microscope and lots of flux. A hot air gun helps for the inevitable wrong part/orientation. It's really lead-free solder that I have more issues with since my old tools often don't get hot enough. I find it strangely therapeutic to solder in general. Must be the leaded solder fume high... For me, once I figured out drag soldering, the number of pins didn't matter as much as the pitch. I've done hundreds of QFP32 - QFP144s by hand in the course of my working life, but I can't do BGAs without investing in stencils and a reflow oven. I've toyed with the idea of learning how to reball BGAs, but even I feel that might be a little masochistic.

[Hans61]

I come from Germany. I try the cheapest shipping. So far this has worked very well.

When I'm ready to give away extensions, I'll ask if anyone wants one (cost of materials + shipping).

So far I have soldered SMDs well by hand (QFP, 0603). The CY7C1049 and XC95144XL are a problem for my eyes though. I'm 60. I've always wanted to try reflow.

I ordered an extension-crazy and an extension-compact with stencils. The extension-compact was very easy to reflow solder and worked immediately. With the extension-crazy, everything worked well except for the XC95144XL. He didn't stay in his position. I had ordered the extension-crazy colored. I was wondering why JLCPCB only assembly green PCBs. Is the solder resist not so good with colored ones?

I got an old stereo microscope (purely optical). This allows me to hand solder the parts well. I also successfully soldered an extension-crazy by hand. This has the advantage that I can test in stages. This makes troubleshooting easier.

I haven't soldered BGA yet. I have a friend who has a special soldering station for desoldering and soldering BGA (he repairs notebooks). I would ask him if I need it.

I don't know of any amateur who uses lead-free solder. It just flows worse. But I wouldn't have a problem with reflow. I use Sn63 Pb37.

I only became aware of GAL/CPLD/FPGA here. The work on the board and the software alone is lb3361's credit. I want to do more with it but I don't have the time at the moment.

[veekoo]

Video banking

Because we do not rely on the Gigatron CPU to read the pixel values, we no longer have to place the video buffer in the current address space of the CPU. We can displace it into another bank that we only access when we want to write something to the screen. This frees almost all of the 64KB address space for programs and data (minus the audio buffers and the video table.)

In a brief comment in the Gigatron ROM Makefile https://github.com/kervinck/gigatron-ro ... efile#L299, Marcel spoke about a moon shot: getting his chess program, MSCP, to work on the Gigatron. He encountered a lot of problems with the C compiler crashing for obscure reasons. When I rewrote the C compiler, MSCP was high on my list of things to run. Alas MSCP in its default form requires about 56KB of memory to run. I was able to run it in the GLCC emulator, but not on a real Gigatron https://forum.gigatron.io/viewtopic.php?p=2379#p2379.

Displacing the video buffer outside of the 64KB address space changes this. The only thing I had to do was to write a customized version of the GLCC console library and compile MSCP. This is a very slow chess player. Anyway, I believe this is the first time MSCP runs on a real Gigatron, although I gladly recognize that this Gigatron is a bit puffed up.


20220116_180533.jpg

How much memory does MSCP require if its coded without stdio.h and instead console.h? Is 64K RAM version machine enough?

[lb3361]

How much memory does MSCP require if its coded without stdio.h and instead console.h? Is 64K RAM version machine enough?

MSCP requires about 25KB for code and 30KB for data. This is far more than available when the screen takes about 20KB out of the 64KB. Printf and stdio cost only 2 to 3 KB of code. I already removed scanf to save 2KB and reduced the size of certain history and cache data structures. Even when moving the video buffer out of the addressing space, it barely fits.

Another way to port MSCP would be to add "far" pointers to the C compiler giving direct access to data in distant banks. This requires support from the ROM in the form of new opcodes that peek/poke data using a large linear address instead of a 16 bits address. This also requires getting LCC to understand a new kind of pointers, probably requiring substantial patches to the LCC machine independent part. This is probably the right thing to do because the 512KB board should not be considered as anything but a wild experimentation. The 128k board is canonical in the sense that it follows Marcel's design with minor improvements and bug fixes. The logic complexity of the 512k board is about the same as a whole Gigatron.

Note that you can run MSCP in the GLCC emulator because there is no screen (see stuff/mscp In the gigaton lcc repository.)

[lb3361]

8 Bits Audio

The last version of the board (see https://forum.gigatron.io/viewtopic.php?p=3014#p3014 and https://github.com/lb3361/gigatron-lb/t ... sion-crazy) has a SD Card socket instead of space for a SD Card breakout. This creates more than enough space to for an analog audio filter and an audio plug. Meanwhile the patched ROM forwards the Gigatron sound to both the usual Gigatron audio plug and the 8 bits PWM on the expansion board.

This took time to debug because I have little sense of proper audio electronics. At some point, Hans61 kindly pointed out that my audio volume potentiometer was a ridiculously high 200KOhms. Replacing it by a 3KOhms one made a big difference in quality (at the expense of a few more mAmps). Suddently the filters start to make sense...

20220428_184428.jpg (157.19 KiB) Viewed 5124 times

Anyway, here are some recordings of tunes from At67's Music64k program, recorded on both the the Gigatron plug (4 bits) and the 512k Expansion board plug (8 bits with a better filter). These were directly recorded from the audio output with a wire. Although there is still audible noise, this is was all worth the effort. Great thanks to At67 for all his work on audio, Axelb for showing how to create filters, and Hans61 for debugging and constructing my often flawed designs.

midi2_4bits.mp3

(78.57 KiB) Downloaded 357 times

midi2_8bits.mp3

(78.57 KiB) Downloaded 360 times

midi8_4bits.mp3

(78.57 KiB) Downloaded 361 times

midi8_8bits.mp3

(78.57 KiB) Downloaded 352 times

[Hans61]

I wanted to solder. So I built a few extensions.
If you're interested, I'll give you an extension for €40 plus shipping from Germany.
All successfully tested.

4x 512k.jpg (628.61 KiB) Viewed 4245 times