05/05/2018 at 00:00 •
Dave's third Gigatron-featured video in a row. This time he is trying to slaughter it, but the Gigatron doesn't cave in. Go Gigatron Go! \o/
05/01/2018 at 12:22 •
Woke up this morning and wondered where those new kit orders suddenly came from. It turned out that right at that moment Dave Jones @EEVblog was building a board in a Youtube live stream with many hundreds of viewers looking on. I caught the last half hour or so. I couldn't stand the suspense when he was searching for a cable. He didn't use the manual, skipped all tests, still it worked 1st time. "This is disappointing, there is nothing to troubleshoot!". Greatest compliment ever! THANK YOU
Edit: the live soldering turned out to be a prelude to more to come. The Gigatron is now honoured with an official EEVblog episode! We’re truly and utterly flattered.
05/01/2018 at 00:31 •
The real progress is that this was loaded as a precompiled *.gt1 file. Gt1 is the newly defined object file format for vCPU programs. The code running, life3.gt1 was created by at67 on the other side of the world using his own assembler and tested in an emulator. This is my test to see if the file can be loaded and executed on actual hardware, and it works! So we now have a standard for exchanging Gigatron programs!
04/22/2018 at 16:53 •
The video shows how an Arduino can be hooked up and pretend to be an ASCII keyboard. No EPROM change is needed. After powering the Arduino, it takes over control by resetting the Gigatron, navigating the menu and starting Loader. It fakes game controller signals to do that. Then it pushes a tiny precompiled Terminal program into the RAM. From there on, it sends simple ASCII codes which the board dutifully displays. This is step 1 towards interacting with the system for direct hacking.
The source code for the sketch is in GitHub. Hookup is with 4 male-to-female jumper wires.
P.S: At the third test in the video the stream stops because the power bank that drives the Arduino was already empty :-)
03/31/2018 at 09:28 •
It is amazing to start getting almost daily reports back from all over the world of new Gigatrons seeing the light of day. This project started one year ago here on HaD with no more than a bunch of empty breadboards and some chips. Without any clue if the crazy minimalistic concept would be viable, and no clue on how the ALU or control unit were going to work. Thanks for your pictures and please keep sending them in!
For reference I took this breadboard photo on March 31, 2017. It accurately portrays the project status of exactly one year ago today:
03/17/2018 at 02:58 •
Double good news today. The first good news is that we will be speaking about Gigatron at the upcoming Hackaday conference on May 26 in Belgrade. We’re super excited that our talk was accepted, and hopefully this event is a chance to meet with many of you. The second and even greater news is that our supplier has sorted out their delivery issue. This means that now we’ve all parts in-house for a first batch of kits. Gigatron is ready to ship, and we're open to take orders!
Ordering details on our website: https://gigatron.io/?page_id=86 We have some stock prepared:
03/12/2018 at 18:15 •
With ROM v1 done and arrival of the last kit parts confirmed for this week (yeah), now is the time for chores. The syntax I used for writing the apps has some rough ends. It was grown bottom-up, hand in hand with the GCL-to-vCPU compiler, while vCPU was still evolving. As I'll need a new compiler for the Arduino interface anyway, why not fix what can be fixed? So now here is the formal EBNF definition of the updated notation, or call it a language if you wish.
There is a great online visualizer that turns these grammars into easy-to-understand railroad diagrams. I've always liked these since I first encountered them in the "Pascal User Manual and Report". A webpage with all diagrams sits here on HaD.
GCL will never look pretty, but it at least it isn't Perl.
03/04/2018 at 15:41 •
With great anticipation we received our last parts for the batch last week. Panic ensued when we discovered they were of the wrong type. Not a few, all of them... Did we place a wrong order? Frantic discussions with the supplier followed and yesterday it became clear: they messed up, apologised, and they are now sending us a new batch. We expect the total impact will be a two-week delay. Bummer, but at least we didn’t lose any money on a stupid mistake.
So please bear with us a little bit longer, soon you will be heating up your soldering iron!
02/18/2018 at 14:28 •
After 360 commits my coding frenzy has reached a conclusion: ROM v1 is feature complete! The kit will ship not with one but with two fast paced games: Snake and Racer. Sound improved and the serial loader is reliable, which is great for hacking and making more games. The fractal program now doubles as a clock, to give a valid excuse for keeping a unit on permanent display in the living room.
The unused ROM space is filled with three classic hires images from my previous projects. By packing 4 pixels in 3 bytes I got three images in where the ROM otherwise would only have space left for two.
This doesn't mean the to do list is empty, far from that: "make todo" lists 90 ideas I apparently still have in mind. But after 6 months of breadboard prototyping, 3 months of PCB design and 4 months of software hacking, this is a good point to shift focus again. For example, towards demonstrations, tutorials and documentation. Keep you posted.
02/11/2018 at 14:46 •
The software to be included with the kit release later this month is nearly done. Just in time as we're now also waiting for the last parts shipment to arrive, expected in two weeks. When those are good we know if we can meet our target selling price and will announce it to those interested on the mailing list. All other parts are in house already, manuals printed, packaging ready and beta tests successfully completed. Our living rooms look like a warehouse now.
Of course the kit will ship with some demo applications built-in. My focus is for a part still on those, but equally important is that the programming core is stable and tested. For me it is crucial that the memory map is well-defined and the 16-bit interpreter is fully tested and useful. After all, the vCPU opcodes are jump offsets, so it will be impossible to fix any of that later while maintaining compatibility as well. Last week I found I had some unused space in the interpreter code page, so I added some new bit-wise logic instructions and support stack variables. Surprisingly, none of the applications I wrote so far needed those.
To test, I ported my old n-Queens solver. It exercises bitwise logic and recursion, so it is a good test for these new instructions. On the screenshot above you can see it gets the correct answers for the sequence. The solver uses 5 stack variables. That, plus one for the the return address, gives 12 bytes per invocation. With the stack living in the top half of the zero page, this means we can go 10 levels deep. The solver needs less than a minute to compute the list, or at about 850 recursions per second. [Edit: I just figured that it should be easy to go down to using 4 variables or 10 bytes, and with that up to 12 levels deep.]
Although 8-bit assembly programs must be programmed in the EPROM, interpreted programs run from RAM. The built-in applications are of course stored in ROM also, but they are loaded into RAM first, so they use the ROM merely as a disk. Interpreted programs can also be loaded into RAM directly over the input port, and this is how you can program the Gigatron without using an EPROM eraser and programmer. For this I hook up the input port pins, that normally go to the game controller, to a simple Arduino. The Arduino can send data at the same rate as the horizontal sync. With some checksumming overhead, this boils down to exactly 28k8 payload bits per second. Much faster than loading C64 programs from tape back in the day... (3000 baud with speed loaders!)
The loader was the last part of the software that needed debugging with a scope.