- The Ongoing Saga of this Commodore B128 (3/x)
In the last post, I ended up desoldering some components that I thought could be a problem, only to find that they appear to be just fine. I moved on to second guess my assumptions due to my experience level, specifically wondering about whether these address and data lines are correct. I then sent off all of my socketed chips to another member of the Commodore CBM-II community to see what he thinks.
Oh, ho, ho.
My new Commodore friend popped my 6509 CPU, 6526A CIA, PLA, and 3 ROMs into one of his test boards to verify functionality. My ROMs and PLA successfully ran for an hour of diagnostics. My CIA checked out okay (but looked quite different than the CIAs he had). My 6509… was toast. In two different machines, it hung up before it could even hit diagnostics. I don’t know for sure if what he saw was similar to what I see on my board, but it certainly was not computing, and that looked a lot like what I was running into.
Now, nothing else using the 6509 was released by Commodore, so finding these chips in the wild is rare to impossible. Luckily, back in December, I ordered a Nu6509 from RETRO Innovations, and with any luck, that will arrive soon. The Nu6509 allows one to use a 6502, 65C02, or 65C816S CPU, and adds the memory banking logic of the 6509 to provide a fully compatible CPU for these machines. I ordered it as a “just in case”, and now it looks like we have a winner.
That said, I’m fully aware that this could be one element of potentially multiple failures in this board, so I am not getting my hopes up.
In the meantime, I am awestruck by the work of Michal Pleban creating a replacement 8088 card for the CBM-II. Commodore originally created an 8088 board to allow CBM-II owners to use MS-DOS 1.25, however, since none of the I/O ports matched up with the IBM PC, it was DOS-compatible, but not PC-compatible, so of limited usefulness. Michal took the original card design, and created a quasi-virtualization layer to proxy those requests to Commodore hardware. Furthermore, he managed to get FreeDOS running on it from an SD card, making it a fairly usable XT-style machine that can work in high profile and low profile CBM-IIs. Now he has a schematic available, and is building boards to sell this fall. If I get this machine working, that may end up being my next step — unless I can convince him to send me a card. 🙂
Next update when I receive my parts and my Nu6509.
- The Ongoing Saga of this Commodore B128 (2/x)
In the last post, I introduced my US-market Commodore B128 that wasn’t feeling like being a computer. A lot of the diagnostics looked okay, and I was just about to start desoldering components out of a combination of hope and despair.
Some Soldering Required
Each desoldered component was replaced with a same-size socket, and continuity tested from the pin receiver to the bottom of the board.
Step one was desoldering the 74LS275 at U12. I wasn’t sure if there was an internal short that was bringing down D1 at pin 12, and I couldn’t test it in circuit effectively. Once out, I put it in my TL866-II to test, and it tested good. For fun, I replaced it with another 74LS275, with the same results. Drat.
Second was the RAM connected to D1, at U65 and U73. That is, theoretically, the only other thing on D1. I don’t have a DRAM tester, but I do have some 3764s which should be 1:1 compatible. Popped those in, no appreciable change. Drat.
Third was the 74S138 at U40, to figure out if there’s an issue with chip select, since what I was seeing in the oscilloscope didn’t really match what I thought the truth table said. It also tested good in the TL866-II. I tried a replacement SN74AS138N1 but that didn’t change any of the chip selects, so maybe I’m reading that truth table wrong.
Hands in the Air
It was this point that I started to wonder if I was going to desolder every TTL chip on this board. Due to my lack of experience, I don’t know what these address and data lines are supposed to look like on an oscilloscope, but something about them bother me. It shouldn’t be power ripple, but I just have this nagging feeling that something is affecting the data bus on this board, and that’s why things are getting weird. Furthermore, there’s a huge difference in how the bus looks when the BASIC ROMs are installed versus when they are empty. While I’ve already successfully read them in my EPROM programmer, something is bugging me.
With that, I’m taking up the offer of another member of the B128 community. He’s going to burn me a new 82S100 PLA, and while doing that, he’s taking all of my socketed chips and testing them in a working B128 board. I still have a feeling everything’s going to check okay, but at least it’ll eliminate those chips, particularly the 6509. Next entry will be after those chips are tested and back in the board.
- It’s incredibly difficult finding a 74S138 nearby, though fairly available as used stock on eBay. I went the instant gratification route after reading up on legacy vs modern versions of these TTL chips. The S is a faster max propagation delay (8ns), high power component. The LS was a low power, but somewhat slower (21ns) variant. The AS has a typical delay of 9ns, whereas the ALS is 12ns. Figured the AS was the closest match to the component.
- The Ongoing Saga of this Commodore B128 (1/x)
This is my Commodore B128, serial C002720. The B128 is the low-profile US version of the Commodore CBM-II, a machine designed to replace the PET/CBM series, released around the same time as the Commodore 64. Other pages, linked below, do a great job covering the history of this machine.
When I received it, it looked great but did not work. Upon applying power, the LED lights, but the connected screen over composite is garbled, looking almost like it lost sync. On a 1084S, presents almost looking like characters. On a LCD over composite, just looks like flickering.
No sounds are made when power is applied. Pressing CONTROL-G on the keyboard does not produce a beep. As a side project, connected the keyboard via USB to another machine, and verified that the keyboard works splendidly. Connecting a Commodore 4040 drive to the IEEE-488 bus will light up when the B128 is booted, but that could just be power applied to the bus. Attempting to type commands does not result in any activity from the drive.
After a little bit of starting, I decided to remove the variable of potential ripple or power shorts by recapping the OEM power supply. There are plenty of forum posts of DOA power supplies, might as well get one win in.
First up, the resource list. None of this diagnosis would be possible without the following pages, created with obvious love and care by the community of people who continue to appreciate Commodore and/or the CBM-II machines.
- B128 Schematics, manuals, and firmware at zimmers.net
- Steve J. Gray’s The Commodore CBM-II Page at 6502.org
- Edward D. Shockley’s Commodore B Series at insectria.org
Time for some diagnosis with absolutely no knowledge of how anything this works, armed with schematics and images from zimmers.net. I’m making this post to keep myself accountable.
- Power rails
- No short to ground
- Clean 4.99v at power LED
- Clean 4.96v-5.02v on major ICs across the board
- Addressing, timing, reset
- CPU clock is clean
- Dot clock is clean
- RESET line starts low, then moves high, and the address lines start to make some noise, so it seems like the 6509 might be ok
- Address lines have continuity throughout
- Address lines out of 6509 at U9 look like decent square waves showing proper TTL. Each look okay on the oscilloscope, but A13-A15 on the logic analyzer look stuck high after a short amount of time — maybe after the RAM test?
- Some research here suggests my kernal ROM isn’t in a good place
- Traced video lines from plug, through TTLs back to the 68B45P at U7
- Continuity is good across each path
- Video signal looks something approaching normal
- In most, but not all, cases, there is no hsync signal out of the 6845
- In some cases, there is an hsync pulse, with no relevant change in output
- It seems that the 6845 isn’t going to initialize on its own, the CPU needs to initialize the 6845, which also sets sync
- Signals out of kernal ROM at U61 look fine, from a TTL perspective
- For a fleeting moment, having the BASIC HI ROM at U60 inserted would cause a very noisy looking data bus, leading to a wild goose chase that I couldn’t reproduce later
- Forums seem to indicate having a kernal without basic lo or hi would boot into a monitor, but no change when leaving those out
- Building a 2364 to 2764 adapter and testing in a TL866-II show that each socketed ROM content matches the binaries available online
- Buying a 2764 to 2364 adapter, burning a ROM to a 27C64, and inserting does not change anything for any of kernal, basic lo, or basic hi. I did not try all three at the same time, but I have no reason to believe that it warrants further checking
- Chip select coming from a 74S138N at U40 looks high on kernal (U40p7), basic hi (U40p10), and basic lo (U40p11), and that also seems super suspect. Chip select comes out of a 74S138 at U40, which is soldered. Could be bad? Can’t test until desoldered, but maybe this is a RAM issue
- Initial checks of the data in/out lines (which are bridged) show that U65 and U73 kinda look shorted to ground on the oscilloscope, certainly a lower frequency on the logic probe
- For a brief moment, every single data line looked weird, but that could be the 275 doing its job, or the 275 sucks
- Tracing back to a 74LS275 at U12 shows the same grounded line. The opposite side of the 275 looks normal, so either the 74LS275 has a short, or something else on D1 has a short
- D1 comes from U12p12
- Passes through U65, U73, and the other bank of RAM if populated
- Passes through P9p4
- No obvious issues on the top or bottom of P9
- Maybe a RAM IC is dead?
I’m at the point now where it’s time to desolder parts. I’m likely starting with the 74LS275, and if that ends up good, moving on to the two RAM chips, and then looping back around to the 74S138.
I also have a standing offer to test the rest of my socketed chips in a working B128, and if this desoldering doesn’t go well, that’s my next step.
- Sharing your WSL2 environment with Linux
It seems like I’m in a constant state of switching between Windows 10 and Linux on my personal laptop, so I keep both environments available in a dual boot. I’ve really enjoyed using WSL2 on my Windows 10 side, so much so that I have a bunch of projects that are in active use within that environment.
WSL2 uses a lightweight virtual machine to boot a Linux kernel, and each WSL Linux distribution keeps a complete ext4 Linux filesystem as a virtual hard disk image for faster — and native — file access on your Windows 10 host. Luckily, it’s pretty easy to mount this filesystem if you’re booted on the Linux side.
I’m using Windows 10 2004 and Pop_OS! 20.04, but this process will work with any Linux distribution that is set up to mount NTFS partitions read/write using ntfs-3g and can install the guestmount utility via libguestfs.
To do this, the Windows 10 disk will need to be mounted within your Linux environment. On my Linux installation, I mount my Windows 10 volume using ntfs-3g under /mnt/c.
You will need to find your root virtual disk, which is located in the application package directory of the WSL Linux distribution being used. In Windows, this follows the pattern “C:\Users\username\AppData\Local\Packages\distribution\LocalState\ext4.vhdx”, where C is your drive letter, username is your Windows username, and distribution is the generated name of the distribution used. If one is using Ubuntu, the generated name is “CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc“. I’m going to use this path in the example below.
The other tool we’ll need is guestmount. This can be installed on Debian/Ubuntu/derivatives by installing the libguestfs-tools package using APT.
sudo apt install libguestfs-tools
Now, let’s mount the partition. The mount points in the image do not like being mounted as a normal user, and I’m happy to hear suggestions on how to get around this. We’re using the allow_other flag to let other users have access to the filesystem, and mounting it under /mnt/wsl. You can alter the username, distribution, and mount point to match your system.
sudo mkdir -p /mnt/wsl sudo guestmount -o allow_other \ --add /mnt/c/Users/username/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/ext4.vhdx \ -i /mnt/wsl
Your WSL2 distribution is now available under /mnt/wsl. I haven’t found any odd side effects, except that Visual Studio Code reminds you to install the Remote – WSL extension, as WSL is available on your system. Go figure. 🙂
Remember to use guestunmount when complete, before the Windows filesystem is unmounted. Too many force unmounts will eventually cause problems with the WSL2 environment, and there isn’t a lot of self-healing available.
- Adventures in running an AMI locally
I recently had to do some spelunking into a long-updated AMI image to move it over to automated builds. The AMI had been updated over the period of a few years with security updates, OS patches, configurations, and more, and very little documentation was generated on those changes, as organic growth tends to do. I wanted the opportunity to poke at it over time, but didn’t necessarily want to burn the compute time in EC2 to maintain the instance, so I wanted to get it booting locally.
Of course, Amazon does not let you download AMIs unless you had them built and uploaded in the first place.
In this example, I’m using Linux to create disk images, and I’m running the resulting image in Hyper-V on Windows 10. Some commands can be altered to work with other environments.
- Start a new instance with the AMI you’d like to work with. When creating the storage, uncheck delete on termination.
- Once created, terminate the instance, it isn’t needed anymore.
- Create a new, nano Linux instance with default settings.
- Within Volumes, attach the volume from your first instance to the new Linux instance.
- Create or identify an S3 bucket to store your image to, and make sure the instance profile of the Linux EC2 instance can access that S3 bucket.
- SSH into the Linux machine, and open a
tmuxinstance to shield you from disconnections.
- Identify the device node of the new image. You can
dmesg | tailor look in
/dev/nvme*for new matching, unmounted nodes.
- Now we image that device directly to S3. Replace
/dev/nvme1n1with the device you found, and
your_bucket_namewith the destination you chose in S3. This command pulls a raw image, compresses it, and transmits it directly to S3:
dd if=/dev/nvmen1 - | gzip | aws s3 cp - s3://your_bucket_name/ami-disk-image.img.gz
- With that image saved, you may now terminate the Linux EC2 instance you created, and delete the volume.
- On your local machine, pull the disk image:
aws s3 cp s3://your_bucket_name/ami-disk-image.img.gz .
- Use gunzip, 7zip, or WinRAR to gunzip the disk image
- Use qemu-img to convert the image to Hyper-V:
qemu-img.exe convert ami-disk-image.img -O vhdx -o subformat=dynamic C:\Users\Public\Documents\Hyper-V\ami-disk-image.vhdx
- Create a new Hyper-V instance in version 8, with this disk image mounted to IDE
- Remove the generated image from S3
Congratulations, you now have your environment in a local VM to play with.