Post-roundup update

Well, at least I didn't get a "this project seems to have fizzled out" status...

The Sun 3/50 project is totally still happening, and so here is some more imagery to appease the judging gods.

The keyboard and mouse has been retr0brited by now -- another three hours of daylight finally aligned with my project time -- and I also did the TeleVideo keyboard and a Sun Type 5 keyboard/mouse for good measure (supposedly the Type 5 is electrically compatible with Sun 3 systems, just using a plug adapter which I may or may not try to make, but the Type 5 mouse I have is a mechanical ball mouse, so if I need that I have the option). I did not do the bottom of the mouse because I feared the felt peeling up and since this is already a Sun4 doner part, I'm not risking it; so one of the pictures lets you see how improved the top piece of the mouse is compared to the unchanged bottom piece.

Also I included a 10Base2 ethernet proof shot for good measure -- yes, T-connectors and terminators included -- can you believe with as much thinnet cable and T-connectors that I seem to have that I only have two terminators in all my storage boxes?

I tried to get the pasty white look on the CRT, but the signal is too dim to drive multiple channels like that I suppose. I included a "it's too dark" shot for demonstration. Also I took some oscilloscope pictures on the HSync and VSync lines, and the verdict is vertical runs at 66.667Hz, and horizontal at 62.500KHz, if the HP16500B's measure mode is to be believed.

I drew a custom retro-style font, and got the numbers deployed to the Sun 3, and then spent some time playing with animating the numbers across the screen. I used the size 64x256 for the characters, and since I'm drawing alternate lines, it looks quite large, and easy to read onscreen.

Before deploying the rest of the characters, I decided I'd better look into compression for a bit. Well, after much debate, I selected to use the C-language lzss implementation by Haruhiko Okumura, mostly because the implementation was portable, and simplistic enough to understand. So I ported the decompression routine to run on the Sun 3 metal with no operating system (not too difficult, just had to implement a fgetcmemfake and fputcmemfake and replace the calls to fgetc and fputc in lzss's decode routine appropriately). Since there is no operating system end-of-file indication, and lzss only stops decoding when it hits EOF, I have to specify the expected byte lengths of the input and output, and return EOF when they are met -- simple enough.

To embed the data, I've noticed that any data specified outside of a function doesn't appear correctly, and ends up blank on the Sun 3, so to deploy the data, my approach is to declare an array inside main with the packed data #included from an external file. Main then copies the data into a fixed memory location (I'm using (unsigned char*)0xF0205000) and then calls the lzss decode routine, which decompresses the data to 0xF0200000. To prepare the data for inclusion, I do the following: Since each of the characters is 2048 bytes (obtained by converting the drawing to .pbm and stripping the header off to obtain raw bytes), the offsets from one to the next is known. Next cat each of the original files together into one unit, which I call numbers.unpacked. Use the lzss compressor on this to obtain what I call numbers.packed. Then using a line like the following, it's prepared for inclusion in the C source:

xd -2x numbers.packed \
  |awk '{print "0x" $2 ",0x" $3 ",0x" $4 ",0x" $5 ",0x" $6 ",0x" $7 ",0x" $8 ",0x" $9 ","}' \
  |grep -v '0x,0x,0x,0x,0x,0x,0x,0x,' \
  |sed 's/0x,0x,0x,0x,//' \
  >numbers.c

I suppose I'll need to do some more artwork now that I made it to this point.

Just for fun, I did a techtech effect, so I also included some shots of that. This is not doable by default with bwtwo hardware: if Debbie had tried this, she'd have been removed from the university computer lab for sure.