There are five modules, each with a Dialight driver and 7-segment LED display. Each module is separate, and you can remove the endcaps to remove the modules. I guess you could remove modules and cut the chassis down to a smaller size, or even theoretically add modules but you’d have to embiggen the chassis. Either way, it looks like a quick/cheap method for a production house to provide a product for various customers who might require different quantities of displays.

It was easy to find the datasheet, and just as easy to match up the pins with the card edge connectors, which you can see via my handwriting on the sheet under the display module.

Not sure what, if anything, I’ll do with them. Standard TTL logic, consistent pin ordering, and what appears to be 0.156″ card edge would make it fairly simple to interface to something.

But the question is, what? I’m kinda short on ideas. The whole thing is vaguely reminiscent to the TIL311 displays I played with in the past, but I don’t know if I wanna do another clock.

I built a P112 some time ago, and then added the GIDE. This was before the Kickstarter campaign.

After building everything, I got it mounted in an enclosure that was originally an HP drive module. The GIDE mounting orientation is not going to remain as in this photograph. I have ordered some 90 degree headers so I could mount it horizontally, and be able to (hopefully) put the cover back on the whole thing.

Along the way, I ran into various stumbling blocks and user errors. I ended up putting everything aside, only to pick it up and periodically noodle with it.

Finally, with the help of Hector (part of the conversation you can see on the GIDE link), most of my issues were resolved. Now it was time to work on getting the GIDE configured, an operating system installed and booting directly from the GIDE drive.

I am going to focus on BPBIOS (Banked/Portable BIOS), because that works. I would actually prefer to use CP/M 3.0, but a different set of issues appear when going that route. I will talk about that later.

While getting my mental state prepared to tackle this, once and for all, I noticed that a new version of BPBIOS was posted, this time as a complete hard drive image, so I opted for that.

If you use this new image and write it directly to a CF card, the below installation process is going to be different.

Most of this is going to be notes to myself, but if others find it useful, so be it. I did eventually work out the installation process, because I like to make sure I understand something as fully as possible. The most important thing I ran into was the need to use BPCNFG to ensure that logical drive A: was pointing to the first hard drive partition. Otherwise, if logical drive A: points to the floppy, the system will load the bootloader from the GIDE, but continue to boot from the floppy.

First ensure that the BIOS parameters are configured properly for the CF card. In my case, with a 128mb card. Somewhere, I don’t remember where, I found the CHS parameters as 980 cylinders, 8 heads, 32 sectors.

Once setting the CHS (and any other BIOS parameters) and booting off the floppy drive with the BPBIOS floppy, make sure to load one of the dynamic images, because it seems that the GIDE “drivers” are not part of the base 64k boot. I load BANK1M1F (1mb RAM, 1 floppy).

When the system is booted, the floppy drive will change to F: and the hard drive will be A:. You will probably receive errors when the startup script(s) tries to run, but mostly, they can be ignored. You’ll probably be on the A: drive by default, so make sure to look on F:, the floppy. Most of these below are on F15:

* IDEINIT.COM, SHOWHD.COM or HDIAG.COM will give you GIDE parameters.
* HASHINI.COM to format the GIDE drive.
* BPSYSGEN.COM to copy the floppy boot tracks to the GIDE.
* BPCNFG.COM, using the “Disk” option to read the book tracks of drive A: (which is the GIDE drive, don’t forget):

In BPCNFG.COM, use the various menus to ensure that the baud rate is correct, that the GIDE CHS matches, and that A: is pointing at the GIDE (not the floppy)

* Copy that floppy
* BPCNFG.COM on one (or all) of the images (BANK*.IMG), to make sure the same parameters match.
* Remove the floppy, boot off the GIDE, and cross your fingers.

The above is for building a system from a boot floppy. If you are using the (new) disk image in the link at the top, the only problem I ran into was making sure the CHS parameters matched the boot track and the image file. Here, I had to boot the floppy, and use BPCNFG.COM on the boot track of the GIDE drive (A:), and the image (BPSYS.IMG) to make sure the CHS matched.

When all is done, if no errors, you should be able to boot:

There is a prompt in the startup script to load the banked/portable image BPSYS.IMG. I will edit that out to load this system by default. I personally see no need to run a base 64k system, and if I do, well, it’s easy enough to revert.

Now, I mentioned that I wanted to use CP/M 3.0, but I ran into (only) one problem. While the CP/M 3.0 disk boots, I was able to use the FDISK.COM program to partition the disk (using the “standard” boot code) and format the GIDE disk (INIC.COM, I think). Once that was done, I could not remember/figure out how to copy the boot tracks from the floppy to the GIDE drive. Perhaps if someone ever stumbles on this, they’ll refresh my memory, or correct my errant ways.

I’m glad to have gotten this far. I always hate leaving things half-assed.

What you can’t see here (and neither can I, because I drew the traces too narrow at 6 mils) is that every row of three vias are connected. There is a power rail going down the left side, quote noticeable (gnd and vcc), but the grid layout didn’t work like I hoped… So I manually drew a marker down to visually separate the grid.

Each edge is connected to a row of two vias directly above the edge connector. They’re labeled, but again, I used too small of a font to really read them. But the upper edge connects to the closest two rows, and the lower edge connects to the third and fourth row.

This should make it easy to layout a variety of parts. For which I have an idea, being the whole point of this project, but which I’ll defer for a later post, as I strive to overcome the disappointment in myself for not thinking clearly enough while laying out the visual markings.

Given that the specs for the C64 edge connector is well know, this is nothing stupendous, but I’ve not really come across anything in this specific configuration. I’ve picked up socketed cartridge carriers, but nothing quite generic like this. I drew it in EaglePCB, so if anyone is interested, I can post the project here. Perhaps after I widen the traces and embiggen the font…

Been wanting to build an Atari Punk Console for a while, so I sat down and breadboarded one up, using a pair of 555′s rather than a 556 (because I had 555′s and did not have a 556). I wanted to make it a bit more permanent but didn’t have any really good perfboard. I could have ordered some, but by the time you add shipping, as well as associated parts, it was more cost effective to just order one of Jameco’s kits.

They’re fun and simple to build. If you’re not familiar with an APC, it’s just basically a noise maker using one of the oldest commercially available ICs, the 555. They’re hackable: you can add things like CV in, line out, etc, which is/was my plan.

But one day, I saw this thing…

It’s a “Myosone 401 EMG Monitor” by Edmund Scientific. I have no idea what it is, but the retroness of it just screamed at me. Look at it: dials, buttons, analog meter. For $10, why the heck not?

I took it apart, and it looked like a perfect fit for the Jameco APC. This is what the original thing looks like inside. The PCB is single-sided with those very 70s hand-drawn traces (which I didn’t get a picture of, but you know what I mean, right?). I dunno what the ICs are, timers or op-amps, but who cares…

It was short work to fit the Jameco APC inside.

The meter is currently not attached to anything. Not sure where to attach it. I do want it to do something, even just move up and down as you twiddle a dial. I’ll mess with that eventually.

Since it’s the thing to do, I do want to build a Baby-8 or Baby-10 sequencer. I should be able to build it inside this enclosure. But even if not, it still looks cool. At least I think so.

It’s just a repurposed fan, probably from an old CPU cooler. 12vdc, dunno what the amp rating is. I tapped off C7, the large filter cap that goes in the same orientation as the ICs. It measured 10vdc across. I looked at C8, the other large filter cap perpendicular to it, but that measured close to 20vdc.

The case of the 1541 is a good candidate for Retr0-Brite, think?

So what you’re looking at here are two Atari 2600 games, Pac-Man and E.T. By themselves, probably rather nondescript games, but if you’re familiar with video game history, these two games are often cited as the most vivid reasons for the great video game crash in the early 80s.

While the statement may have a small bit of truth to it, I figure calling these two games the primary reasons for the collapse is a gross over-simplification. Like many issues that can crash an entire industry, there were many factors at hand, these two games being only part of it. If you’re interested in the reasons behind the collapse, and the role that the E.T. game played, see the Wikipedia article. Disclaimer, I generally dislike Wikipedia, but for this purpose, it meets the needs.

But the lore behind the E.T. game is much more entertaining than citing sales figures, market over-saturation, etc.

Some people may not be familiar with this era of video game history. Those of us who lived thru it may have experienced the fallout without really knowing the reason (how many teenagers can concisely summarize an industrial crash?), but I say “lore”, because I personally haven’t been able to verify the story behind the E.T. game.

So just what is the story of these carts? In brief, when the video game industry crashed in 1983, Atari had millions of these E.T. carts to dispose of, and they dumped them into a landfill in New Mexico. I’ve not read any accounts of any excavating such landfills, but that might be due to the landfills being private property, or just being in an undisclosed location, or I’m just too lazy to find such excavation accounts.

The Pac-Man game might have suffered a similar fate, but it’s always the E.T. game cited. The Pac-Man game lent weight to the collapse due to the extremely poor quality of the game.

Which brings up the point, why even bother buying these games, if they’re just a footnote in history? Apparently The Angry Video Game Nerd is coming out with a movie in 2013 which focuses around the story of this game.

I didn’t buy the games like those people who took advantage of Steve Jobs death to post common-as-dirt Apple IIe’s on eBay for $10,000 (yes, they were), but rather to _avoid_ such a rush, if there is a rush. They’re currently common games, you can pick them up on eBay for a few dollars.

Since I don’t have an Atari 2600 (or emulator), for your enjoyment, here is a gameplay session of the Atari 2600 version of Pac-Man:

Compare it to the original:

Hideous, isn’t it? Both of those are probably emulators, but the comparison is nontheless still valid.

It would take ~5 years before the industry was able to recover, and Atari was no longer a player, but the industry now belonged to Nintendo.

Visual inspection revealed no major flaws, so I took the plunge and powered it on. I was expecting the PLA to be blown, at the very least. But to my surprise, it booted right into BASIC. It had some bad memory, reporting 30929 bytes instead of the standard 38911.

So my first goal was to take out the board with the memory and see what the deal is. Unfortunately, unlike the SX-64′s less-portable brother, the SX-64 is not very “user accessible”. Things are jammed at tight as possible, with various daughterboards connecting to one another thru a mess of assorted wiring harnesses.

The board at the far rear is the main CPU board. In front of it, a bit to the left, you can see the expansion cart slot, with a homemade diagnostics ROM. To the left of that is the “expansion” board, which carries the 6526′s, and plugs into the main board via a 40-pin header. Behind THAT, is the 1541 drive control.

When I remove cables, even if their orientation is obvious, I always mark them which you can see on the two white cables at the top of the main board. Then it was a matter of extracting this thing.

I didn’t really get a shot of the whole main board while it was out, but this is where the RAM chips are.

I tried to remove the original RAM in a non-destructive manner, with the idea to test them via the swap-and-replace method on another 64, but that plan didn’t work out. I was more concerned about damaging the PCB, so in the end, I eventually snipped the RAM chips out, which destroyed them. That’s a shame, because some of them were good.

I did find replacement RAM (4164s), and decided to socket them as well. I figure once something needs replacing, there’s a possibility that it may need replacing in the future, and why not? So I picked up a stack of really cheap “machined” sockets.

Well, it goes without saying, but I’ll still say it. When you buy cheap Chinese parts, expect nothing but cheap Chinese parts. It’s hard to tell from the photo, but the pins are flimsy to the point that practically breathing on them will bend them. And the insertion holes are dumb.

Normally I use “real” machined sockets:

They’re usually much more expensive, but for small projects like this, for a do-it-yourself, etc, the cost is so much worth it. I should have just backed out and ordered some good sockets, but I was not in the mood to order $10 worth of sockets with a $10 shipping fee.

Once that was said and done, when I powered it on, I received the expected 38911 bytes free, but the 1541 was not working; the LED and motor stayed on. I did not remember if it was doing this prior to my fiddling with it, as once I saw the memory incorrect, I just jumped in. So I don’t know if I blew the 1541 controller, or if it wasn’t working in the first place.

Ah well, this symptom is apparently one of the most common failures in the 1541, and the first thing you do is replace the 6522s, which fixed the problem.

As far as I can tell, everything else is working, but I’ll have to find some way to put it to more tests. I made a Commodore 64 dead-test diagnostic cart (which you can see above, inserted into the cart slot), but the SX-64 is apparently different enough that it fails quite a lot of tests.

But all in all, I’m quite happy. The keyboard needs a standard cleaning cycle, but that’s nothing to write home (or blog!) about.

My ROM edits worked in VICE, so MikeS on the VC forums offered to burn me a ROM with my image. I just got the ROM today, and I am excited: it works! I even made a video with a “live smoke test”:

There are a number of Ethernet devices available for Commodores, such as the 64NIC or the RR-Net, but these are all memory I/O based. The Flyer instead uses Commodore device channels to communicate with the network.

For me, this seems to open up a whole lot of possibilities that may not be practical with the 64NIC/RR-Net stuff, because each and every individual program needs to be “net aware”, while with the Flyer, you use standard Commodore device commands (OPEN, GET, etc).

The network device appears as #7, and you can open, read and write to this just like any other Commodore device. There is even a command channel, sub-address 15, where you can issue net specific commands.

On the Retroswitch web page are a couple of demos of network-aware programs: irc and telnet. But since web traffic is just another protocol, would it be possible to have a Commodore PET web browser?

Of course, I am using the Hack-a-Day retro challenge as my example…

Fundamentally this is pretty easy: open a channel to a URL, read the incoming text, and process it. I wrote a short BASIC program which is probably the crudest HTML processor you’ve ever come across…

You’ll excuse the spaghetti code. It’s unavoidable in a language whose only conditional is a simple IF, and whose basic control flow consists of GOTOs and GOSUBs. Niceties like “do while” didn’t exist yet…

Some comments on the actual code:

Line #1 sets the lower case. This is in conjunction with line 61, which converts from ASCII ATOZ to PETSCII ATOZ. I needed to do this to ake sure the “if” statements in 600+ would process correctly.

Line 35 sends the string to the open network socket; line 40 is for the network processor (secondary device 15).

From there, it simply grabs characters between < and > (HTML delimiters) and does some very simple processing in lines 600 and up.

Given the limitation of the hardware, I did not go all-out. There is only 1k of video memory, and 32k of RAM, so you probably would not be able to implement buffering to allow scrolling. There’s not many text formatting, so things like bold and italic, well, use your imagination.

It’s also VERY SLOW. You probably could re-write it in machine language for speed, and add a few more parsers.

Check out the Flyer documentation for some more interesting possibilities.

Edit: I made the Hack-a-day front page!, and just for that occassion, I made a short video of this: