Since I was a kid growing up in Canada, everything was NTSC. And my first computer the Commodore 64 was of course NTSC based. My parents refused to get me a monitor, so I had to use the RF modulator to get it to work on a TV. In north America we had these RF modulators on the back of the TV’s to connect our systems up (Atari, Commodore, Nintendo, SEGA etc..)
And the picture looked terrible, it was an antenna so it was suspectable to all kinds of RF emission interference, grounding issues and all kind of all around problems. It’s no wonder I had 20/20 vision as a kid, but it was absolutely destroyed because I was even forbidden to buy a proper monitor.
So thanks to patreon and ebay, I found this amazing bundle for 49GBP, a Commodore 64, plus tape drive. The catch being it didn’t include any proper cables, so I went to Tesco and bought an RF lead. I have this weird LG TV, a LG 50PC1D 50in Plasma TV. The original list price was an eye watering £1800! I got it used a while back for a more reasonable £130.
Lots of Inputs!
While I was at Tesco, I didn’t see any kinds of RF boxes. I was hoping I could just plug the cable directly from the TV into the Commodore C64, and it turns out that is exactly how it works.
With the cable plugged in, I was able to eventually get an image. I found out that the LG is more than capable of locking the RF image from the Commodore 64, and it looks awesome!
One man and his Droid over the RF on the LG 50PC1D
It’s a lot better than I was expecting. Clearly RF on a ‘modern’ TV works great.
Of course getting this to work wasn’t all that intuitive, and again probably because I’ve only delt with NTSC TV’s where the channel would be locked to either 3 or 4. Not so in Europe.
So setting the TV to channel for, and the band to ‘cable’ you can see the distinct border of the basic screen. The image of course is useless but you can see it trying. And that is because after letting the TV scan and find the picture on it’s own it’s actually channel 36.
Messing with the image options I found that there is 3 systems to choose from:
You can see the image trying to form under System L, but it’s obviously no good
While the image looks better, the speakers erupt with absolute static. And the image is a bit faint, but immediately recognizable. It does look better in person however.
And finally we have System I, over V/UHF on Channel 36.
I don’t know if this will help anyone trying to get anything working. Maybe it’s only relevant for people new to PAL territories like me.
Shockingly no explosions, I was recapping stuff to notice that the PSU I’m using is sliced. Of course a 35 year old PSU runs better. I need some transistors, and maybe some diodes, but I don’t have good access to any at the moment. So weird how 80’s DRAM could need +12/+5/-5v to operate. Oh well.
So I wanted to capture some composite PAL signals, and well yeah I have a fancy capture card but it’s only HDMI of all things. NO VGA, EGA/CGA and sure no composite. So I headed down to Sun CHeong Computer Co. Ltd. 246 Apliu Street Shum Shai Po, and picked up one of these.
While talking about home brew 8080 and 8086 systems on Discord an ebay search brought me to Elijah’s store page where this small little curiosity was up for sale. It’s literally just a NEC v30 on a Raspberry Pi hat, for a mere $15 USD! Interestingly enough the v30 can operate at 3.3v meaning no special hardware is required to interface to the GPIO bus on a Pi. This reminds me so much of the CP/M cartridge for the Commodore 64, and the price being so right I quickly ordered one and eagerly awaited to 2 weeks shipping to Asia.
While I have Pi 4’s that I run Windows 10 on to drive some displays & power point, I wanted to use the slightly faster Pi400 for this. The Pi400 has a compatible GPIO expansion port so just like a cartridge it’s a simple matter of slotting the card, powering up and building the software. While there is an included binary, it’s a 32bit one, and I’m running Manjaro on the Pi400 for a similar look/feel as the PineBook Pro. Anyways the dependences are SDL2, and an odly named ‘wiringPi’ library that allows C programs to interface to the GPIO.
You can download the emulator over on homebrew8088, specifically the Raspberry Pi Second Project. The last ‘ver 2’ download has the project configured for a v30 which is an 8086 analogue, unlike the v20 which is an 8088. When physically interfacing to the processor things like this really matter!
With the emulator built it was pretty simple to fire it up, and boot into MS-DOS:
I have to admit I was a little startled at first as I really had no idea if this was going to work at all. I’d spoken to an engineer friend and he was saying plugging a CPU directly into the GPIO bus, and toggling connections to actually emulate the board was both crazy and that without any electrical buffers it’d most likely either fry the processor and maybe the Pi as well. I suspect this being low voltage may be sparing both, although I have no EE so I’m not going to pretend to know.
Loading up Norton SI confirms what Elijah had posted on Ebay is that it runs very slowly about 1/3rd the speed of an XT. Now I may not know anything about hardware but this seemed at least something a profiler could at least tell me what is going on, and if someone like me helicoptering in on the shoulder of giants could see something.
This will build a profiled version of the emulator that’ll let us know which functions are being called both the number of times, and how much time to do so. Not knowing anything but having profiled other emulators, the usual pattern is that you spend most time fetching and possibly translating memory; Both in feeding instructions and pushing/popping data from stack and pointers. Waiting is usually for initialisation and for IO.
Once you’ve run your profiled executable, it’ll dump a binary file gmon.out which you can then use gprof to format to a text file like this:
gprof pi gmon.out > report.txt
And then looking at the report you can see where the top time, along with top calls are. Some things just take a while to complete and other well they get called far too often.
As expected Start_System_Bus takes 1 second, followed by 1,100,374 calls to set the Data_Bus_Direction_8086_OUT (no doubt the Pi needs to alternate between reading and writing to the CPU), followed by 5,954,106 ticks of the CLK function. Of course the real culprit is Print_Char_9x16 which was called 286,883 times, and is responsible for nearly 40% of the tuntime!
Obviously for a simple MS-DOS boot the screen should not be calling any print char anywhere near this many times. Clearly something is amiss. Not knowing anything I added a simple counter to block at the top of the Print_Char_9x16 function to let it only execute 1:1000 times, and I got this:
Obviously it’s not right, which means that the culprit really isn’t Print_Char_9x16 but rather what is calling it. It was a simple change to each of the Mode functions to only render a fraction of the time, and I changed it to a define to let me fire it more often. This is a simple diff, assuming WordPress doesn’t screw it up. It’s not pretty but it gets the job done.
$ diff -ruN ver2/vga.cpp ver2-j/vga.cpp
--- ver2/vga.cpp 2020-07-29 10:36:51.000000000 +0800
+++ ver2-j/vga.cpp 2021-06-04 01:51:33.546124473 +0800
@@ -1,5 +1,9 @@
+static int do9x16 = 0;
+#define VIDU 5000
void Print_Char_18x16(SDL_Renderer *Renderer, int x, int y, unsigned char Ascii_value)
for (int i = 0; i < 9; i++)
@@ -23,6 +27,12 @@
void Mode_0_40x25(SDL_Renderer *Renderer, char* Video_Memory, char* Cursor_Position)
int index = 0;
for (int j = 0; j < 25; j++)
@@ -36,6 +46,7 @@
Print_Char_18x16(Renderer, (Cursor_Position * 18), (Cursor_Position * 16), 0xDB);
void Print_Char_9x16(SDL_Renderer *Renderer, int x, int y, unsigned char Ascii_value)
for (int i = 0; i < 9; i++)
@@ -57,6 +68,12 @@
void Mode_2_80x25(SDL_Renderer *Renderer, char* Video_Memory, char* Cursor_Position)
int index = 0;
for (int j = 0; j < 25; j++)
@@ -102,6 +119,12 @@
void Graphics_Mode_320_200_Palette_0(SDL_Renderer *Renderer, char* Video_Memory)
int index = 0;
for (int j = 0; j < 100; j++)
@@ -156,6 +179,12 @@
void Graphics_Mode_320_200_Palette_1(SDL_Renderer *Renderer, char* Video_Memory)
int index = 0;
for (int j = 0; j < 100; j++)
While it feels more responsive on the console, it’s still incredibly slow. SI was returning the same speed which means that although we aren’t hitting the screen anywhere near as often it’s still doing far too much. Is it really a GPIO bus limitation? Again I have no idea. But the next function of course is the clock.
First I tried dividing the usleep in half thinking that maybe it’s not getting called enough. And running SI revealed that I’d gone from a 0.3 to a 0.1! Obviously this is not the desired effect! So instead of a divide I multiplied it by four:
Now it’s scoring a 1.5! Obviously these are all ‘magic numbers’ and tied to the Pi400 and more importantly I haven’t studied the code at all, I’m not trying to disparage or anything, if anything it’s just a quick example why profiling your code can be so important! At the same time trying to run games is so incredibly slow I don’t even know if my changes had any actual impact to speed as emulation of benchmarks can be such a finickie thing.
My goto game, Battletech 3025 Crescent Hawks Inception loads to the first splash but then seems to hang. I could be impatient or there could be further issues but I’m just some impatient tourist with a C compiler…
With my changes and re-running the profiler I now see this:
Which is now what I expect with the bulk of the emulation now calling Read_Memory, with the Clock following that and of course our tamed screen renderer (although its still called far too much!) with the Data_Bus_Direction being further down the list. No doubt some double buffering and checking what changed in between calls would go a LONG way to optimise it, just as would actually studying the source code.
The one cool thing about this is that if I wanted to write a PC emulator this way gives me the confidence that the CPU is not only 100% cycle accurate, but it’s 100% bug for bug accurate since we are using a physical processor.
And again for $15 USD + Shipping I cannot recommend this enough!
The following is a guest post byÂ PA8600/PA-RISC! Thanks for doing another great writeup on that PowerPC that was going to transform the industry!.. but didn’t.
The history of the PReP platform from IBM is quite interesting, not only because of its place in the history of Windows NT but also the history of the PowerPC architecture in general. When the PowerPC platform was new, IBM (just like a few other vendors, notably DEC) had grand plans to replace the x86 PC clone market (they helped create) with PowerPC. Of course thanks to various factors such as Apple’s refusal to play along, the launch of the Pentium Pro CPU (and the later Itanium disaster), and high cost, this plan never ended up panning out. Later IBM PReP machines were designed for AIX and Linux use only, and they were sold as regular old RS/6000 computers.
Still, Microsoft being Microsoft and willing to port their OS to literally anything hedged their bets and made MIPS, PowerPC, and Alpha ports of Windows NT (along with a PC98 release for Japan only). In the guest post about Solaris for PowerPC I made, I talked about the history of IBM’s PReP platform some more so you should go read that post if you want an initial rundown on PReP’s flaws and history. But I have learned a bit about the Windows NT port for PowerPC, and I discovered a rare version of it as well. By now everyone with a PReP machine (or PPC Thinkpad) has run Windows NT 4.0 on it, and if PReP machines are emulated it’s guaranteed this will be the second most run OS on it aside from AIX of course.
IBM also made a half-baked OS/2 port for PowerPC as well, and then there’s the previously mentioned Solaris port. All of these are rarities and it’s worth documenting. With how rare PReP machines are and their high prices on eBay when they do turn up for sale (or their tendency to be snapped up fast), I think it’s fitting to write perhaps the most in depth look at PReP hardware that anyone has seen.
Windows NT 3.51: “The PowerPC Release”
It’s commonly accepted that Windows NT 3.51 was the first release for PowerPC hardware and it was even called this within Microsoft. Featuring HALs for most of the early PReP machines including the Moto Powerstack, the rare FirePower machines built for NT (which used Open Firmware), the Power Series 6050/70 (and maybe 7248), and the unobtanium IBM 6030, it’s pretty much what you’d expect for a first release for PPC. It’s a polished, solid OS that’s arguably faster than NT4 on the same machine. Aside from the red boot screen (on my Weitek GPU), it’s pretty much Windows NT 3.51 but on the PowerPC. It’s like running NT 3.51 on MIPS or Alpha, it’s interesting but more software will likely run on 4 anyhow (especially on Alpha).
One interesting quirk of Windows NT for PowerPC is it does not report the CPU type of your machine. It simply reports “PowerPC” and what machine you’re running it on. It does not tell you that you’re running it on a 601, it tells you that it’s running on an IBM-6015.
Unsurprisingly Visual C++ 4 works on PowerPC Windows NT 3.51 as well. This is no shock, Visual C++ 4 was designed to work on 3.51 as well as NT 4.0. The same goes with many of the pre compiled programs. One advantage Windows NT 3.51 offers over 4.0 is that it is simply faster than 4.0 on the PowerPC 601.
Here’s something I’ve found out from research however. There was actually a limited release of Windows NT 3.5, it’s been dumped, and it is a real operating system. It also requires a very specific model of RS/6000 to work, and one with a interesting history giving it a unique place among the PReP machines. While I was unable to make it work in the end, I did discover and document a lot of interesting features of PReP machines.
Enter Sandalfoot: The IBM 7020/6015 (and demystifying PReP machines)
To understand the HCL and weirdness of Windows NT for PowerPC (and why it won’t run on Macs), we need to take a look at one such machine it runs on. This is my RS/6000 40p, a machine that was given several brand names by IBM and used as a development platform for PReP software and operating system ports. This is also perhaps the most historically significant RS/6000 model from the era. While it wasn’t the first PowerPC RS/6000 (that honor goes to the 250), it was the first to use the PCI and ISA busses and it was a few months ahead of both the initial PCI PowerMacs and other PReP boxes. It’s also one of the few true bi-endian machines as just like other PReP machines, the MIPS Magnum, HP’s Integrity, and modern Power8+ machines it has OSes for both endians available.
In 1994 (presumably October 28, if the planned availability date is correct), IBM released the RS/6000 40p (announcement letter here, codenamed Sandalbow) and the Power Series 440 (codenamed Sandalfoot). Both are near-identical machines with different faceplates and boot screens. The RS/6000 ranged in price from around $4,000-6,000 and was designed to be an entry-level AIX workstation, bundling a copy of AIX with each machine. As an AIX machine it’s relatively slow and fits the entry-level badge quite well, but thanks to the 601’s POWER instructions it served as a transition machine over to the later 604 AIX machines. Unlike the later PowerPC 603 and 604 machines, it featured POWER instructions allowing it to run both legacy AIX POWER software and later PowerPC software. The Power Series was presumably sold to those wanting a PReP box for Windows instead.
Since IBM PReP hardware is so obscure and undocumented, I’m going to document this as best as I can being the owner of an IBM Model 6015/7020. The machine features a 66mhz PowerPC 601 (similar to that of the Power Mac 6100 and RS6K 250), PCI and ISA slots, and IBM’s “Dakota” PReP firmware (more on the boot process here). It uses an off the shelf NCR 53c810 SCSI controller, Crystal CS4321 sound chip, an Intel 82378 PCI bridge, and a NIC can be inserted into the ISA slots (mine has the famous 3com Etherlink III). The Super-IO chip is also off the shelf, and is a National PC87312VF. The clock IC is a Dallas DS1385S, a close relative of the Dallas DS1387 (with internal battery). At least some of the IBM custom ICs are the chipset ICs and those are also documented. A Linux 2.4 dmesg can be found here.
Mine is also maxed out at 192mb of RAM, however there are some solder pads for more and the chipset is limited at 256mb. This makes me wonder if the system was based on a reference design of some sort. There was an ultra-rare 604 upgrade as well, but considering how there are more 7248 and 7043 machines in the wild I can assume many customers just waited for that instead due to its superior AIX performance.
If the idea sounds familiar (off the shelf chips + RISC CPU) it’s because it was the very same idea used to create the two other non-x86 Windows NT platforms. The Microsoft Jazz MIPS platform most MIPS NT boxes were influenced by was infamously based on the same idea of a “PC with a MIPS CPU”. To a lesser extent, this was also seen on the DECpc AXP 150 and other EISA/ISA/PCI based Alpha machines designed to both run Windows NT and DEC’s own OSes. Crazy undocumented custom hardware and expansion busses were thrown out the window in favor of industry standards. In fact when I posted a photo of the motherboard to a chat full of PC nerds, they stated it looked remarkably like a normal PC motherboard. The whole industry would later adopt PCI and sometimes ISA on non-x86 machines to cut costs and reuse the same expansion cards.
The main difference between the RS/6000 40p and the Power Series variant is the boot ROM logo and chime. The RS/6000 and “OEM” systems used a boot ROM that featured the PowerPC logo and just a beep, while the Power Series machines featured a logo more closely resembling the PowerPC Thinkpads complete with the chime. One can boot firmware from a floppy as well by typing in the name of the ROM image in the prompt and pressing enter, and watching as it reboots once the firmware is loaded into RAM. Here’s a video I filmed demonstrating this, along with some other quirks including there being two SMS keys: F1 for a nice flashy GUI SMS and F4 for a text based SMS, along with F2 for netbooting (with the right NIC of course).
The Sandalfoot machines were LPX form factor machines, featuring a riser card and generic sheet-metal case popular with prebuilt machines from this era. The LPX form factor was wildly popular in the mid 90s due to its versatility, seeing use by both IBM and DEC for their RISC machines, various PC builders, and even Apple for the clone program and clone based Power Macintosh 4400. The Sandalfoot machines also drove home one of the core goals of the PReP project, which was to build a PowerPC platform using as many off the shelf and PC style components as possible instead of using lots of custom ICs like Apple did. I dug out one of my cameras to take a few high-res photos of the motherboard of this computer to illustrate this. Compare this to the motherboard of the Power Macintosh 6100 or even the 601 based 7200 and notice the bigger heatsink and use of fewer custom ICs (Apple loved those).
There were three main GPU options: the famous S3 Vision864, the Weitek Power 9100 (or P9100 for short) as a higher end option, and IBM’s own GXT150P. The S3 was the entry level GPU and the Weitek was a higher-end and faster GPU. The GXT150P is beyond the scope of this because it is unsupported on the other PReP OSes, only AIX. The other two video cards are essentially unmodified Diamond PC cards with the BIOS chips missing.
The Sandalfoot machines are perhaps the most important PReP machines due to their role in PReP OS development. Both OS/2 Beta 1 and Windows NT 3.5 were written for this machine in particular as it was one of the first PowerPC machines to support PReP and feature PCI/ISA slots, unlike the NuBus Macs released a few months earlier or the first PPC box: the MCA based RS/6000 Model 250. They also often shipped with the well documented and emulated S3 Vision 864 video card, a common GPU family in PCs of the time to the point where it was even included on some motherboards and emulated in too many PC emulators/virtualization programs to count (notably 86box/PCem). In fact it’s successor (the 7248) featured one soldered to the motherboard.
Windows NT 3.51 was dubbed the Power PC release, because it was designed around the Power PC version of NT, which was originally supposed to ship in version 3.5. But IBM constantly delayed the Power PC chips, necessitating a separate NT release. “NT 3.51 was a very unrewarding release,” Thompson said, contrasting it with Daytona. “After Daytona was completed, we basically sat around for 9 months fixing bugs while we waited for IBM to finish the Power PC hardware. But because of this, NT 3.51 was a solid release, and our customers loved it.” NT 3.51 eventually shipped in May 1995.
I think a more accurate thing to write is that there simply weren’t many PReP boxes out in late 1994. Windows NT 3.51 supported the Motorola PowerStack series, the IBM 6050/6070 (and maybe the 7248, which came out in July 1995), and rare FirePower machines. Windows NT only features HALs for the 6015 (Sandalfoot/Power 440/RS6K 40P), 6020 (Thinkpad 800), and the 6030 (a rare IBM machine that likely was only sent to a few developers). By 1995, there were more PReP machines on the market and this made the NT 3.51 release logical. NT4 even supported a few servers, mainly the RS6K E20, E30, and F30.
Windows NT 3.5 was most likely a limited release for testing purposes on the Sandalfoot machine as it’s HCL file declares it as “Build 807” with a date of October 18, 1994. The date seems to be around a week or two before the first 40p machines at least shipped. Some more files were modified later on and the folders were created on November 9th, 1994. Hardware support is very barren, and the readme file even has a section dedicated to quirks of the 40p along with a list of supported software for the x86 emulator. This might have been considered a beta as well, as an announcement letter for the Thinkpad 800 (6020) explicitly mentions Windows NT and that this version might be a beta for developers. It also talks about a Windows SDK for it and a Motorola compiler used to build 3.5 software.
However the real problem for me has to do with getting a video card. Windows NT 3.5 for PowerPC does not support the Weitek P9100 GPU that came with many RS/6000 branded machines, and neither does OS/2 for PowerPC. It only supports the S3 Vision 864 and 928 video cards. It’s listed in the setup options, but choosing it causes a txtsetup.sif error. I’m going to assume that the development units came with the S3 video card instead. My box contained a Weitek card which works for AIX, Solaris, and Windows NT 3.51/4. I bought a card from eBay to use with NT 3.5 and the OS/2 port.
The readme also features an ominous warning with the S3 video cards, that only revision B3 is supported and that 928 cards need 2MB of VRAM for anything above 256 colors. My revision of the card I ordered was B4, so I took the risk of seeing if it worked with my system. I also removed the ROM chip as the system initializes the video card itself and that having a ROM chip can cause the system to not complete the self-test or display video. As the IBM Weitek card lacks a BIOS, I did this.
Despite the scratches on the card from possibly coming out of an ewaste pile, the card worked fine in both a PC I inserted it in for testing purposes and the IBM system. I now had a 40p with a GPU much more well supported among non-AIX or Windows NT operating systems.
Anyhow, let’s talk about the install process in closer detail here. Windows NT for PowerPC installs in a similar manner to Solaris for PowerPC on the IBM PReP machines. First the floppy disk boots ARC, then when you choose to install it the machine copies the ARC bootloader/firmware to the hard disk so it can load it from there at each boot. The floppy disk can also be used to load ARC if the loader is damaged on the hard disk. Keep in mind, on IBM machines ARC is not stored in the ROM unlike on many other ARC capable machines so this has to be done. The Firepower machines do something very similar by using an Open Firmware shim, and unsuccessful attempts at emulating PPC NT have exploited VENEER.EXE to attempt booting instead of using the IBM firmware. It fails because they’re not emulating the hardware, just trying to find a quick way to just boot NT.
Once this is done, the installer loads up and installs just like every other NT install. It checks the HAL by reading the machine ID, what video hardware the machine has, and whatnot to prepare the installer. You need a IBM 6015, 6020, or 6030 according to the HALs it has and only the S3 video cards are on the HCL.
Or that’s what should happen. I first tried using ARC 1.51 as it worked for 3.51 and was greeted with a HAL error BSOD:
I first attempted to use older ARC boot floppies and I got somewhere, the BSOD changed to the classic 07b, and then I got nothing else. Using ARC 1.48 and 1.49 gave me this, I got some i/o error with ARC 1.46 (the first 3.51 ARC floppy), and any previous ARC floppy is most likely undumped. I’m assuming either the error is due to an ARC mismatch, a weird firmware mismatch/hardware revision mismatch, or some incorrect SCSI ID Solaris style. There might very well be some weird forgotten trick to making it work (maybe a Windows expert could dig through the files and find some weirdness), but I’m going to move onto another obscure PPC rarity:
OS/2 PowerPC Boot Attempts: Beta 1 and the Final
Recently the OS/2 Museum site dumped Beta 1 for PowerPC. It’s an earlier version of OS/2 for PowerPC that insists on a Sandalfoot machine with an S3 GPU. Unlike the other OS/2 PowerPC disc, it features a verbose boot featuring the kernel it uses. If you want to really see OS/2 for PPC working, try it on a 7248 or read this post about it.
This failed to boot, throwing up an error about mounting the disk or something. I did record it doing something at least however, an improvement over the Weitek which just does nothing at the PowerPC screen. I tried several things including removing the external SCSI CD drive and that didn’t fix much. It also declares 88c05333 an unknown PCI device.
So I decided to try the “final” build. The final build requires a 6050/70, and some people did get it working on the PPC Thinkpads. I decided to see what it’d do on my machine. Unsurprisingly it did absolutely nothing but give me a blank white screen and sometimes a 00016000 error (for a trashed CMOS). If anything the 6015 loves to trash it’s CMOS contents for absolutely no reason, especially when OS/2 is involved.
Anyhow this was very anti-climatic, as the OSes I threw at it found reasons to not work on it whatsoever. I weeded out the GPU being at fault by testing Windows NT 4.0 and finding out that it works just fine with the GPU, however I seem to have fewer resolutions available than what the Weitek card allows. It did change the boot screen font, making me wonder if the red boot screen is a GPU driver quirk.
However changing the device IDs with OS/2 PowerPC Beta 1 got me somewhere, as I now got a screen about the HDD failing to write. I formatted the HDD to FAT using the ARC diskette, then I nuked all the partitions, but not much else changed. I’m not sure what the error means, but it was a letdown.
Unless these OSes require some long lost firmware, I’m wondering if there’s else that’s causing issues with installation. Either way, it was a letdown. Nothing I tried worked and I spent hours messing with everything from SCSI IDs to using different drives.
Enter the Pi1541! What makes this different from the SD2IEC is that this emulates both the 6502 processor of the 1541 drive, it also emulates the two 6522 chips as well giving far stronger emulation. Is this enough to satisfy CP/M? Or is my issue something deeper?
So in my continuing adventure of stuff arriving for my Commodore 64 project, I took the opportunity to pull the keyboard apart and clean it. I didn’t do any weird retrobrite thing, as I don’t care that this looks 30+ years old. And I haven’t swapped out any further caps just yet, although I did also get a big box of random caps ranging from 0.1 to 220uF, so I can probably do all the small stuff on the board when I feel like it next.
The IEC cables had finally arrived, and that means I could connect up the Pi1541 hat I bought and get this project going.
Although it’s the latest ‘rev 4’ board, it doesn’t support the Pi4 (does anything support the Pi4? What an evolutionary dead end!), auction did include the LCD display, but no software, and no serial cable. The cooler looking one I wanted was all assembled in Poland and they are unable to ship.
Anyways, turns out the software is written by one Stephen White, who doesn’t get any cut of the board sales, but in turn I guess they aren’t bundling the software either… I’d have imagined it’d be some kind of 1+1 thing, but it’s not to be. I guess it’s also why so many people keep on thinking you can buy a PiZero for $5 or so, when they are much closer to $25.
Anways, getting the initial part of the board working was just a matter of reading Steve’s site, and following which files to be download, and where to be placed onto a FAT32 formatted SD card. This is one of those ‘bare metal’ type projects, so this also doesn’t run Linux.
Unfortunately for me the Pi1541 didn’t do ANYTHING on powering on, that is until I connected the HDMI cable. And yeah what a let down. And even worse when trying to load anything it’d just hang. So frustraiting!
Now this of course works for my v4 hat, and the way I like it. Also keep in mind that if the C64 isn’t detected it will appear to hang after loading the chargen ROM. It took a while to figure that out, until I just turned on the c64 to see what would happen. I also hate having it change disks when I power cycle, so IgnoreReset was a great feature, well for me anyways.
I fired up CP/M, and yeah it’s doing the same thing. So it turns out that it’s not the SD2IEC adapter that I have. I’m kind of mixed about this, on the one hand that’s great as the SD2IEC’s are significantly cheaper and easier to come by, at the same time I had hoped a little that the bigger investment of the Pi1541 would make the difference. At least it’ll be the difference for stuff like Ghosts’N’Goblins Arcade.
One interesting thing is that SOFT80 is now faster, getting somewhere between 1-3cps. It’s still totally unplayable, but I guess that’s progress?
Still waiting for the dead test cart to see if it tells me anything useful.
So since CP/M is acting all wrong, there is clearly something up with the C64. I hadn’t opened it yet, and I almost regret doing so as despite it ‘working’ it was a MESS!
After separating the case halves, and unplugging the top LED, I saw that capacitor C66 had exploded. There was some faint hint of staining from the top, but I didn’t expect it to be something like this.
The board was disgusting, like the cap had something spilt onto it? Then it ruptured? or did it rupture? it still powered on and ‘worked’ despite this gunk.
Isopropyl is in short supply still, so I did something probably dumb, I took a 50% baiju a brush and gave it a quick rinse.
with all the fuzz removed it’s a 250469 REV.B… which I understand is a pretty late model. It’s one of the short boards, which not a lot of chips, which I’d hope means fewer things to fault, although at the same time, some of these chips are going to be impossible to source.
Also, I should add that I found various C64 schematics online, and none had a 470uF cap for C66. Maybe I’m going crazy? I found an E-bay auction for replacement caps, and yep, they also have a 470uF in there. Am I crazy?
Now I was hoping that being in Hong Kong, that means I could actually find some retail shop actually selling capacitors. So I went around the audiophile places and scored this higher voltage cap for a whopping $5 USD! The store owner was insistent that this was for ‘high end audio gear’ and not my toy 80’s computer. That this thing was somehow some magical ‘audio only’ capacitor. Has anyone heard such a thing? Is this like audiophile grade SATA cables?!
So I replaced the cap, and NOTHING. The power led turns green and that’s about it. I had to dig up a simple volt meter and yeah power is going places. I gave up and went home for the night. Turned it on this morning expecting a POP or further disappointment, and it fired up.
A bit of digging around I found HeadAlign v1.1, which I transferred to the SD2IEC, and much to my amazement the stupid tape drive started working, although it was a full screw turn out of alignment, and it looked normal (no picture). I rewinded the tape, and loaded up Hans Kloss, and it worked!
Sadly CP/M still is printing far too many things to the screen. I guess I need to replace more caps, and keep on waiting for that dead test cart to get a bit of a further hint. Although my soldering skills are terrible.
Ever since I found that ‘cheap’ Commodore 64 online I’ve been wanting to try something. The machine came with a tape drive, so I ordered some ‘cheap’ reproduction tape game, to see if it worked.
While it almost works, it sees the program on the tape, the thing stalls out. Granted it being dated to 1991 probably means the belts are beyond usable. I am having a friend proxy some belts for me as nobody will ship them to Hong Kong (pandemic didn’t have any real effect there).
While this machine is a newer ‘C’ model, I’ve had seen this auction pop on and off on Ebay from time to time advertising a refactored and improved CP/M cart advertising that it works on all models. I’ve read somewhere that post 128 that they finally had figured it out, far too late to matter. But maybe with this new cartridge things could work?
I managed to get a SD2IEC board delivered from Germany, which uses external USB power, so it won’t tax the C64 PSU (I should look, is there an ATX to C64 PSU?). I can load some silly games and stuff seemingly okay. I haven’t bothered with GEOS, as I used it far too much when I had to, and it’s just far too slow to even dream of being usable. Anyways with the SD2IEC it came with ZERO instructions but I did find the page with the needed firmware, and the ‘FB64.PRG’ program to have it browse the SD card and mound D64 images as needed.
I have to admit, ever since I did that article about “Running CP/M on the Commodore 64” I’ve been dying to try this on real hardware. With all the excitement in the room, I mounted the CP/M disk, and held my breath as the *’s went across the screen….
And, well something isn’t right. I tried a bunch of images I could find online, and they all do the same thing. They print far too many characters on the screen from time to time. Clearly it’s some timing/IRQ issue. Something to do with the VIC chip.
Despite the screen being corrupt, it is running, and it does let you run commands, it’s just the output is being doubled (or 10x!) up.
So I tried the soft80 program which will setup an 80 column CP/M experience. It didn’t matter what version I used, the old one from the 80’s or the patched up one from Luis Antoniosi, they all do the same thing, which is run at a blistering 1cps.
I thought it’d be fun to stream this old beast playing the CP/M version of planetfall, but at 1cps I just can’t do it. Which is just a shame. I haven’t tried a regular C64 Infocom game, as the 40 cols was always crazy, but I guess it’s the fallback.
I know these things are so rare, but I had high hopes for this thing.
I never heard of this one before, but it’s legit!… As long as you have expanded your RAM, Edilbert’s Z-Machine opens up the world of Infocom to a whole host of machines:
CBM 8096 / CBM 8296
VC-20 (32K / 40K)
I’ve never seen the more advanced ‘European Business’ PET’s before, I’ve only dealt with the incredibly limited PET 2001-8C Chiclet keyboard models that were so insanely limited. It wasn’t until much later I saw the dual disk drives (4040’s??) that could have helped those machines so much more, but that was that. I’d been asked as a kid to make an electronic card file on an 8kb machine with a single tape drive. Sadly 8 year old me didn’t know about loading and saving sequential records on tape. Or maybe luckily as I can only imagine how insanely slow this would have been, and or tedious to not only save and update, but find things.
Anyways I thought I’d fire up some mythical 8296 beast with 128Kb of RAM. Attaching the disk image, and firing up “LOADER”, you can watch it load up as much as possible into memory:
And once it’s loaded up, the Z-Machine is active!
Now granted I don’t have a PET to test with, but using VICE, I can happily say that for an 8bit machine, this is incredibly fast. Maybe it’s the disk subsystem interface, as the VIC-20/C64 have an absolutely dreadful interface, but yeah wow playing HHGTTG on a non C64!
But at the same time there is great value in old computer hardware.
In my opinion around 2006-2007 we basically hit peak computing. The biggest restrictions I see on older machines is memory sizes, and disk speeds. And for the most part these can be taken care of with ease, although many chipsets and formfactors of the time seem to have these incredibly tiny 8Gb/16Gb/32Gb limitations that just really are annoying in the distant future of 2019 when you may want to run a few things at once.
So I bought this used i640GA6-BDO, an i7 machine oem’d by mouse computer. Yes the name of the business is the same name as the 2nd most popular peripheral of all time. From the blurb:
From the “NEXTGEAR series” with high cooling and excellent maintainability, IntelÂ® Core™ i7-4790K processor, dual channel 16GB memory, 1TB hard disk (7200rpm), DVD super multidrive, NVIDIA Â® GeForceÂ® GTX™ .970, 80PLUSÂ® BRONZE certified700W power supply, pre-installed Windows 8.1 Update i640GA6-BDO” is 149,800 yen.
I paid just over 20,000 yen for this machine. So losing some 120,000 yen, or about 80% of it’s value over 5 years is certainly not a good investment proposition. It seemed like a good bargain.
Finding the corporate website was NOT easy, but thankfully they own mouse-jp.co.jp so one of those wild guesses turned out being right. They seem highly influenced by the ‘idol group’ thing that is popular and japan, and they have an extensive YouTube channel over at MouseComputer2010. And an extensive ad gallery.
(the original video was taken down and made private… ? https://www.youtube.com/embed/mPd-vUSsAAo very strange)
They even have the making of videos. I could find so much about the advertising and various talent, but the machines… that was much more difficult than I could imagine.
The build quality however left a bit to be desired, when I turned it on and jumped into the BIOS the first thing that I noticed was that it ran HOT.
So yeah 75c in under a minute is not a good thing. The water pump was making a weird noise as the bearings were clearly shot, and it’s just not circulating anywhere near fast enough.
Although I didn’t take a picture I was able to find one online, that shows that despite the bottom of the case has a big slot for the PSU fan, but the fan was pointing up into the case, not venting to the bottom.
I guess that the original owner got rid of the machine as it was overheating, and/or thermal throttling. I ended up going back out looking for a new cooling solution, and I was torn between a cheap fan thing for $10 or another all-in-one liquid cooler for $50. I decided to go with the all-in-one, as this machine was originally liquid cooled anyways.
The machine also had no storage, so I also picked up a M.2 drive, and a spinning rust disk. I have to say that even for this ancient machine, it’s great it had a M.2 slot, and WOW I thought SSD was fast, but this positively blows it away!
While I was out I see this former holy grail of GPU’s a Nvidia GTX 980 for Â¥12,000. Now granted the machine I picked up has a GTX 970, a nice touch as I wasn’t expecting anything, but I can always use another DVI capable card back at home, so I’m probably taking that along with the i5 back to my HK office.
Now the real killer is that the card is a ASUS GTX, and looking around online it’s the STRIX-GTX980-DC2OC-4GD5 model.
I look around and find it on Amazon, and if the ad thing is to be believed the new price on this thing was Â¥70,900! Looking around on that part number also shows kakaku.com with a list price of Â¥73,480!
So granted the card is 5 years old now, but wow what a drop in price! It’s one more stop away from the junk piles that the other 9xx’s currently are (I’ve seen boxes of Zotac 750’s and up).
Naturally of course, like the i7, this card also had issues the moment I put it into my PC. The screen was flashing with garbage, and it’d eventually lead to a system freeze after a few minutes. What a pain, bad memory I suppose. And like the PC, I took the card apart, cleaned up the old thermal compound, and added some new generic stuff, put it together, and left it running The Outer Worlds at ultra high settings just fine. Who knows, maybe it’ll break later on, I don’t know, but I now have a ‘high end 5 year old’ gaming system for about the same or slightly more than a PS4. And I could be wrong but i’d like to think an i7/980 would crush a PS4. Although I could be wrong.
Naturally running cinebench 14, basically shows that the 970 & the 980 perform so close to each-other it makes no real difference. Although the fan setup on the 980 is far more aggressive, and it runs much more quieter. So that’s a nice bonus.
And if userbenchmark.com can be trusted, the performance difference from the 980 to the 1080, isn’t all that bad. It’s unreal that now even with 2nd generation RTX 2080’s out there, the 1080 is still an expensive GPU.
So, sometimes it may be worth looking at the junk piles. Although at the same time if you have nothing, the new/lowend stuff like the 1030’s/1050’s really aren’t so bad either. But for some reason I always seem to like yesterdays powerhouse.