3 days ago •
Typed in from this 1976 Dr Dobbs article. Worked first time.
Except that we don't do decimal mode and Woz used that to increment the "tries" counter on the left side. So you better win the game in less than 10 tries (or accept a hexadecimal count).
If we sacrifice 13 more bytes, we can get the correct try count without using BCD mode:
190 bytes works for me.
12/27/2019 at 20:47 •
Today we gained two more BASICs. One new, one very old. First at67 offered his BASIC compiler for the Gigatron. This project has been brewing for over a year. It's still in alpha, but it is GREAT already. This is a cross-compiler that creates fast Gigatron binaries. This is fantastic news for those who like to write games but don't want to dive too deep into the Gigatron machine languages. This week it built our Christmas greetings, with snow physics and Jingle Bells tune.
Video link: https://streamable.com/5ds9d
At67's compiler is the third BASIC for the Gigatron. The first was our port of Tiny BASIC more than a year ago. The second was MS BASIC with floating point. Today I decided that three BASICs aren't enough because we can have four.
We have Apple-1 emulation after all, so why not? Most work was to arrange the video table such that we have a 4K continuous block for Wozniak's original Apple-1 BASIC. We managed to free $6000-$6FFF in the 32K system. That mirrors to address $E000 and that is exactly where the original likes to sit. Then we reordered the zero page a bit and recompiled the A1 BASIC using cc65. Et voilà, there it runs!
10/16/2019 at 19:32 •
It took a while, but now Micro-Soft BASIC is running on the 32K Gigatron! We already had Tiny BASIC of course, but that doesn't have 9 digits floating point (40 bits), let alone transcendental functions. Remember when Hackaday wrote that the Gigatron would probably never have floating point?
This is the BASIC that Paul Allen and Bill Gates wrote with Monte Davidoff and Ric Weiland, and for which they started Microsoft, or spelled Micro-Soft back then. They licensed it to many microcomputer builders, amongst others to Commodore. The version we have running is an early one for the Commodore PET.
Although the system can interpret 6502 code, there still was work to do: code, buffers, zero page variables and stack needed relocation, but that wasn't the biggest hurdle as Michael Steil's excellent set of reconstructed assembly sources made that relatively painless. The main problem was to create a sufficiently large continuous memory space. Although the Gigatron has 32K of RAM, 19KB of that is used for screen memory and the remainder is heavily fragmented. For example, by default the largest continuous block we have is just 512 bytes. BASIC itself needs 8KB, plus we need some K's for user program and variables. Ouch...
The first win is to disable the sound channels 2 through 4. That creates a continuous block from $200 to $800. For this trick you need ROM v4.
The next step is to compress the video memory. Our video resolution is already next to nothing, but we can always lower it even more! Of the 120 visible pixel lines, every 8th is always empty. At least, as long as we only use capitals, and for a mid-1970s BASIC that's perfectly acceptable. The empty pixel lines can then be shared for all rows of text. That saves 14*256 = 3585 bytes already.
The last trick is to increase the spacing between text lines from 1 to 4. This reduces the text lines from 15 to 11, but yields 4 * 7 * 256 =7,168 bytes.
Of course we then went overboard and added a flashing cursor, we made sure that the WAIT 6502 Easter Egg works, and that there is a π-symbol. The Gigatron doesn't have that in its font, but it does have T and U.... And... the font is stored without horizontal spacing, so there's our glyph:
R S T pi U | | | | | v v v v v x x x x . . x x x . x x # # # # . . . x x . . . x x . . . . . . # . . # . . . x x . . . x x . . . . . . # . . # . . . x x x x x . . x x x . . . # . . # . . . x x . x . . . . . . x . . # . . # . . . x x . . x . . . . . x . . # . . # . . . x x . . . x x x x x . . . # . . . # x x . . . . . . . . . . . . . . . . . . . . . 0 1 2 3 4 5 6 7 8 9 a b c d e f 1 1 1 1 ^ 0 1 2 3 | font82up
Good enough for me:
10/08/2019 at 16:01 •
A static RAM map constructed by overlaying all GT1 files in the GitHub repo.
08/13/2019 at 10:07 •
A bunch of TTL chips playing the "anthem of 8-bit computing". Four channels: 2x pulse, 1x triangle, 1x noise
The player is an enhanced version of the Contrib/at67/midi player in the gigatron-rom repository. The noise is created from waveform 0 ("metallic") that receives a randomised XOR modulation 60 times per second.
Only 7400 logic. No microprocessor, no video chip, no sound chip.
The Arduino is used to load the music and player into RAM. You see that happen in the first few seconds of the video.
06/23/2019 at 19:54 •
Today my Gigatron believes it's an Apple-1 instead of a TTL computer. It's running the original 6502 wozmon code with mockup terminal I/O patched to it. Of course the patching, and some relocation, make up for the system differences. With a tongue in the cheek, we can say it turns the Gigatron into an Apple-1 clone!(*)
Here we can see the "Apple-1 on TTL" running MicroChess code for the first time, with kudos to @oscarv for helping out.
(*) After all: "Apple1 = 6502 + RAM + WozMon ROM + PIA", and "PIA = DSP + KBD". There wasn't more to it and we emulate it all!
In reality, any original Apple-1 software will likely need some relocation and a tiny bit of patching for I/O. More technical details in the user forum: https://forum.gigatron.io/viewtopic.php?p=774#p774
06/13/2019 at 00:15 •
The computer without microprocessor is becoming dual core.
Today it ran its first 6502 program.
All of the 6502 addressing modes are implemented, and a fair amount of instructions as well. The v6502 interpreter runs in place of the standard 16-bits application vCPU. Switching between the two virtual processors vCPU and v6502 is a matter of modifying a zero page variable. The video driver dispatches at the next available scan line, so very lightweight.
The impressive thing about the 476-byte Baum-Wozniak 6502 disassembler isn't just its size: it's that it seems to be secretly designed for 26 character wide displays. Now that's quite a foresight by these gentlemen! Here you see it running on the Gigatron, disassembling it's own code:
More details on the user forum: https://forum.gigatron.io/viewtopic.php?f=4&t=128
11/15/2018 at 11:15 •
The joy of using hypermodern multiple e-beam direct-write lithography to "advertise" TTL technology from the 1960s... This is an electron microscope image of the Gigatron startup screen. This time it isn't displayed on a VGA monitor (or on a supercon badge), but printed on a silicon test wafer as used for IC making. The image was printed using a Mapper FLX-1200 e-beam writer. For comparison, a human hair is typically 75 µm in thickness.
The Mapper principle is much like that of an ink jet printer head with hundreds of nozzles, except we're using accelerated electrons here instead of ink, and silicon wafers instead of paper (and there are no colors). The beams each have a spot size of under 30 nm and they're scanning the surface with a positioning accuracy of below 3 nm. They're all perfectly stitched together to seamlessly cover the large area needed to make complex devices. The wafer was coated with a thin layer of resist material, and everywhere a sufficient number of electrons landed, an image formed that could be developed.
This tiny area of 24 µm x 18 µm shown above was printed in just a few milliseconds by a couple of hundred parallel and independently controlled electron beams, all focussed on the wafer in a high-vacuum chamber. This image is a small part of a much larger test pattern. The resolution is in the 40-50 nm range here. The e-beam writer has tens of thousands of beams all working in parallel. The data stream to support that is about 3 Tbit/second and is generated by a large rack filled with FPGAs.
A SEM is needed to view the result because the details are too small for optical microscopes. This super fast e-beam technology is developed to make new types of security ICs possible, but it has other applications in nano-fabrication as well (one is entertaining the engineers working with it).
The image contains a schematic of the iconic 7400 quad NAND chip, introduced in the late 1960s. An actual NAND gate, or even a single transistor from the day, would be much larger than this entire image. The typical line widths in those early days of IC manufacturing were in the order 10 µm.
[Edit 2019-02-11: Unfortunately, Mapper is no more. Looking for a job now! ]
10/30/2018 at 17:21 •
The 8-Bit Guy just published his review of Pluggy McPlugface, Tiny BASIC v2 and the new games in ROM v3. And oh... we'll show it at the Superconference this weekend!
For those interested, I brought a very limited number of kits to Pasadena. They can go for a nice discount because I don't want to bring them back home.
Update: The conference badge was screaming for this hack:
The emulation is slow as molasses, running at 3 frames per second, instead of 60 frames. Contrary to my expectation, the slowdown doesn't come from the LCD update. Instead it's all due to the cycle-exact simulation which is based on the gtemu.c reference.
Hex file and modified sources attached to the project. Game controller button [A] is mapped to the DEL button. The BKSP button takes over the role of [Select] for switching between video/speed modes. You don't see the different scan line effects, because the LCD always only displays the first out of every 4 VGA scan lines (even in "full mode", aka "mode 0"), with the odd LCD lines always black. The applications still run faster depending on the mode. Continuous presses don't work, you have to simulate them by repeating. I managed to play Racer that way. Typing in Tiny BASIC v2 goes remarkably well.
Credits must go to @shaos, @jaromir and @rogerrandom for helping me plow through all the PIC stuff, as I never worked with any of that before.
09/16/2018 at 18:27 •
Today, a circle closed at the Centre for Computing History in Cambridge, UK.
How? Well, one week before this project started here on Hackaday, I was at the Computer History Museum in Mountain View, US, and jokingly posted the following remark on Facebook:
That's an original Apple-1. The Apple-1 next to the Gigatron is a beautifully done replica. It's fully functional, complete with cassette interface. The PCB is drawn in the same way and the chips even have 1970s date codes on them. It's on display in an operational state. I could play around and type commands in the original Woz Mon to verify that the Gigatron version works the same.
Many thanks to David Williams for the great opportunity!