polpo blogo

2025: The Start of Something New

2025-12-31T23:00:00-07:00

So, keeping up with my one-blog-article-a-year policy, here's a wrapup of what my 2025 was like. I usually write these wrapups on New Year's Eve, but last year I was flying back from Alaska and got an amazing show from the aurora borealis on the way so I didn't get around to writing a 2024 edition. In 2024 I did write an article about identifying the interviewer in the primary sample of Little Fluffy Clouds, so that counts, right?

Celebrating #MARCHintosh

MARCHintosh is a celebration of all things Macintosh that takes place during (when else) March and a big thing people participate in is GlobalTalk where many people get on a world-wide AppleTalk network. On GlobalTalk, people share files, play games, and print fun things to each other's printers. And the most fun printers of all are dot matrix printers, especially the Apple ImageWriter II! The ImageWriter II requires a special card inside it to get on an AppleTalk/LocalTalk network, the LocalTalk Option Card, which has become quite rare over the years. I had the printer that I got off the free pile at VCF Midwest but didn't have the LocalTalk Option Card. After taking a look at one, I realized it'd probably be pretty straightforward to reverse engineer. Tom Barber let me borrow his card and desolder all of the chips from it so I could scan it and reverse engineer it in KiCad. I named it the ImageScribbler LocalSquawk Option card. If you want one, you can get one at JCM-1.com!

Continuing PicoGUS

Something I've wanted to do for quite some time was give a talk at a Vintage Computer Festival event. In 2024 I was part of a panel discussion at VCF Midwest with some extremely talented hardware creators and it gave me the idea to give a talk about the development of PicoGUS. Last year I wrote an article in Make Magazine about developing PicoGUS so I had a really good idea of what kind of story I wanted to tell, so I applied to give a talk at VCF East and was accepted! Come April, I flew to New Jersey and got to give the talk. I was kind of nervous at the start but soon got into a groove and I thought the talk went really well! The big themes of the talk were how making incremental progress kept me motivated, and how being open source allowed the project to go in some amazing directions.

Speaking of open source, despite being "done" for a couple years, I still kept working on PicoGUS. A while ago, Kevin Moonlight, a friend and frequent collaborator on retro projects with the Pico, reverse engineered the Panasonic/MKE CD-ROM drive interface to emulate it on his Pico PCMCIA project and he was gracious enough to let me use his code on PicoGUS. This meant that the project was able to add yet another ability: optical drive emulation!

Onto the next thing...

Once I got experience integrating CD-ROM support into PicoGUS and writing disc image handling code, a question I've asked myself came back into my head: could I make an IDE drive emulator? IDE is somewhat close to ISA, which I know quite well after creating PicoGUS. And the RP2350 is probably fast enough to handle IDE bus transactions. After doing some back-of-the-napkin math and knowing I had about 30 clock cycles to respond to IDE register writes/reads, it definitely seemed possible. I dove in and got a proof of concept working pretty quickly.

Even though there are other IDE emulators out there, I set out to create what I wanted to use: fully open source, affordable, and with a really nice front panel and WiFi control. So PicoIDE was born (yes, kind of boring name, but it follows from the PicoGUS name, and my contact at Raspberry Pi OKed the name)!

I wanted to get it fully done and launched before the end of the year, but real life gets in the way and I couldn't quite get it ready in time. However it's in pre-launch at Crowd Supply, a crowdfunding platform with a focus on makers and open source hardware. Sign up there to be notified when it actually launches!

Happy 2026!

Here's to a happy and healthy 2026 to all of you. 2025 was definitely rough for a lot of people and I'm really hoping it's better for everybody.

Who Asked "What Were the Skies Like When You Were Young?" in "Little Fluffy Clouds?"

2024-09-15T09:00:00-06:00

Who asked the famous question in the song Little Fluffy Clouds by The Orb? TL;DR: it's music writer Carl Arrington. Read on for more background.

The song "Little Fluffy Clouds" by The Orb is an electronic music classic with legendary status. Released in 1990, it has been remixed and reinterpreted countless times. Most versions of the song center around an extended vocal sample that starts with a question: "What were the skies like when you were young?" The question is answered by the singer Rickie Lee Jones, who gives a languid and dreamy recollection of the skies in her childhood home of Arizona that includes the phrase "little fluffy clouds," giving the song its name.

According to an oral history of Little Fluffy Clouds, the sample originally came to Youth, one of the song's co-producers, on a tape from a friend who worked in a record shop. This friend thought that an interview from a promo set for the album Flying Cowboys by Rickie Lee Jones could be made into a track and included it on the tape along with music by Steve Reich that was also sampled for the song.

While it's well established that Rickie Lee Jones is the answerer, the identity of the questioner hasn't been definitively answered. Many people think it's LeVar Burton, including The Orb's Alex Paterson himself, calling him "the bloke who played Geordi in Star Trek, The Next Generation" in the oral history and other interviews. However if you listen to more than just the "what were the skies like" question on the original source of the sample, it becomes increasingly apparent that it's not LeVar. The Flying Cowboys promo set has extensive liner notes, but there's no mention of who the interviewer is. Posts on The Orb mailing list from 1999 by someone who got the promo set because of its connection to The Orb corroborate that there's no additional info on the interviewer, and that it doesn't sound like LeVar. The Wikipedia page for Little Fluffy Clouds says it's not LeVar Burton but currently says the interviewer is unidentified.

When I was listening to a random mix of music a few weeks ago, Little Fluffy Clouds came up and I started thinking about this sample again and its source. Despite having no interest whatsoever in Rickie Lee Jones's music, I got the silly idea to track down a copy of the Flying Cowboys promo set and interview CD, which is titled A Conversation with Rickie Lee Jones. It took some sifting through copies of Flying Cowboys on eBay, but I found and purchased a complete copy of the promo set. So complete, it included something not mentioned by anyone else who had it: a letter from Geffen Records introducing the album to the people in the music industry that the set was sent to. In the letter is this nugget:

Enclosed is your limited edition Rickie Lee Jones boxed set containing the entire album, a conversation/interview cd with writer Carl Aarington (People, Us, Interview), and a lyric/bio booklet.

So there you go, there's the interviewer identified! But that exact name doesn't really exist anywhere, and that's because Geffen made a typo: the interviewer's name is actually Carl Arrington. Carl Arrington was the music editor for People Magazine for years and was a prolific interviewer of musicians. A couple years ago he started a podcast of his past interviews called the Carl Arrington Archive and while the Rickie Lee Jones interview is not part of it, in a sizzle reel for the podcast he shows racks of cassette tapes of interviews with countless musicians and other celebrities, and there are five tapes with Jones's name written on them. That confirms he's interviewed her extensively.

The recordings in the Carl Arrington Archive aren't as high quality as the one in A Conversation with Rickie Lee Jones, and Arrington's voice ranges up and down quite a bit depending on who he's talking to or how the interview is going, so it's actually not immediately obvious it's the same person in both. However after listening to both a lot, I could tell that it's Carl Arrington in A Conversation With Rickie Lee Jones. His voice is pitched up pretty high when he asks the famous question (hence the LeVar Burton confusion) but in general he talks in a somewhat lower register.

I reached out to Carl Arrington via the podcast company to ask him to confirm that he is the interviewer in A Conversation with Rickie Lee Jones, but I've had no response yet. But I'm pretty satisfied with the conclusion that Carl Arrington is the person who asked "what were the skies like when you were young?"

I've ripped the interview CD and scanned all materials that come with the promo set and uploaded them to the Internet Archive here so you can listen to it in its entirety. The sample starts at 2:03 into the interview.

2023: A Year of Accidental Business and Loss

2023-12-31T23:00:00-07:00

2023 was a really strange year for me. The PicoGUS project (a card that lets you emulate various retro sound cards for DOS systems) took off and I accidentally started a business around it. I also lost my mother, the fallout of which consumed a great deal of time and took a mental toll. Between all of that and my day job, I was pretty well consumed.

Getting PicoGUS "good enough"

In last year's end-of-year blog, things like ISA DMA weren't working great yet and I only had some untested code that might fix the issue. Fortunately once I got back in the saddle after the end of year holidays, I made pretty great progress. Streaming audio via DMA is a trick that many games use for sound effects on the Gravis Ultrasound, and fortunately I was able to figure out how to make it work well enough to get the world's most well known DOS game to work on PicoGUS: Doom. I made a video highlighting that plus a couple other features: swapping firmware in DOS and MPU-401 MIDI mode.

Pretty quickly on the heels of that, I fixed a bunch of bugs and in February I introduced two new sound card emulations: Tandy 3-voice and Creative Music System/Game Blaster.

I was feeling pretty great about PicoGUS at this point! Interest was picking up and quite a few people were making their own boards from the open source design files. I also got my first contribution by pull request to the repo.

Everything stops

Then, in March, I spent some time away from home to help out family for what I thought would be a short time. Late in 2022, my brother-in-law had passed away unexpectedly and I helped out dealing with his estate. Once that was dealt with, that time away was extended as I stayed with my elderly parents to help out around their house. One day in April, my mother had to be taken to the hospital and unfortunately she never made it home. She passed away in early May. On top of that, my father started treatment for cancer only a week afterwards. My brothers and I spent a lot of time just being there together so we could deal with the grief and also helping my dad out with day-to-day things as he dealt with his treatment. Fortunately he's doing really well these days, all things considered.

During this time, I missed being home and having the time to be with my wife and kids and to tinker at my workbench to get my mind off of the "real world." But, I'm glad I was able to take the time to help out my mom and dad. I'm also glad my day job allowed for me to work remotely for extended periods of time while I was away.

Slowly starting back up

I made my way home and started tinkering again, but also took turns with my brothers to travel periodically to help my dad out while he was undergoing treatments. Around this time the Hand386, a handheld retro 386-based computer, came out. I could use one to hack on PicoGUS while away from home! I got one and found out that dealing with a PicoGUS card hanging off of it was pretty awkward... so I got the somewhat crazy idea to shrink down PicoGUS so it could plug right into the side of the Hand386 and around July I had them made. Thus the PicoGUS Femto Edition was born:

Creating this version really took my PCB design skills to the next level. I integrated the DAC portion right onto the board instead of using the purple DAC module, and it was also my first experience having surface mount assembly of the PCB done at JLCPCB. I also made an adapter board so you could use the Femto Edition in a normal PC. Since the Femto board was so much smaller and used pretty small SMT parts, it was not DIY friendly, so I made a few extras to sell basically at cost to friends on Discord. This was technically in violation of my promise to myself to never get into selling boards and bring on everything that entails, but...

Vintage Computer Festival Midwest

My dad lives in St. Louis, and VCF Midwest is in the Chicago area. If I'm driving to St. Louis anyway from Colorado to be with my dad, why not drive a bit further on a weekend to make it to VCF Midwest? It's perhaps the biggest vintage computing event in North America and I've wanted to go for years. Despite never having been to one, I decided to get a table so I could show off PicoGUS and the other Pico-powered ISA cards like PicoMEM and PicoPOST. So with a table and room booked, I was ready to go. But then I got the idea to also make a few extra PicoGUS Femto Editions to sell at the show. One more step towards accidental business creation...

VCF Midwest was a blast. I sold out of all of the Femto card kits pretty quickly and I saw so many cool things and met so many amazing people! My table was next to yyzkevin's, who made a Pico-based PCMCIA card and who I've talked with a lot on Discord. I also ran into Adrian Black who creates the Adrian's Digial Basement channel on YouTube (he took the above photo of me being perhaps a bit too excited at my table). He's a great guy – despite all kinds of people vying for his attention, he still took the time to walk around and take everything in, so he wandered by and I was able to give him the whole spiel about PicoGUS which he was pretty excited about. I had sold out of my Femto bundles by the time I talked to him, so when I got home after the show I built a regular PicoGUS board and sent it his way. Little did I know that he was going to make a video on his channel about the PicoGUS!

Fortunately, I had some advance warning by Adrian and by the time his video premiered, I was kind of prepared. I had set up a store on Tindie so people could add themselves to a waitlist to be notified if I made PicoGUS boards available for sale. Once the video went up on his channel, waitlist signups on Tindie took off like a rocket!

PicoGUS 2.0

One downside to the Femto boards and their adapters is that they need a lot of manual labor to assemble. The IDC connector that lets the Femto plug into the Hand386 or ISA adapter has to have its pins bent and soldered by hand, which takes a ton of time. After I got home from VCF Midwest, I started thinking – what if I made the next version of PicoGUS 99% assembled at JLCPCB? It seemed like there was a decent amount of demand (this was before Adrian's video) to sell a few here and there to recoup the money I've spent on PCBs so far... And so I started on PicoGUS 2.0:

The goal of PicoGUS 2.0 is to be "mass produce-able" and add some extra features like a wavetable header with software volume control, and a USB-A port to allow USB joystick (and joystick-like devices) to be used. This allows fun stuff like playing old DOS driving games with an Xbox 360 driving wheel:

The final version wasn't even close to ready by the time Adrian's video came out, but two months later, I finally had a design I was confident in and had made what I thought was a risky amount of boards: 100. I updated and stocked my Tindie store listing aaaand... they sold out in two and a half hours! I was shocked. I had to make more. I thought to myself: this is a business, isn't it? My next batch I made twice as big, and that one sold out in about 12 hours, so I'm currently gearing up for yet another batch. I've had a ton of support from my family and everyone has pitched in to help test, assemble, and pack up boards to be sent. Fulfilling each batch has been a multi-day affair to get everything out.

What 2024 will bring

I'm still not done working on PicoGUS. There's always improvements to be made to make it more compatible, and I plan on broadening the types of joysticks it works with. Thanks to the work of yyzkevin, Sound Blaster emulation is close on the horizon, and wbc on Vogons has teased adding USB mouse support to it. I'll keep making and selling them as long as there's demand (which I expect will hit its limit sometime soon)!

I expect family stuff will probably still take a large part of my time. And my day job also takes up the bulk of my days! So it's not all fun and games...

What about other retro projects? I wanted to make a Pico-based SID replacement for the Commodore 64, but somebody beat me to it! The SIDKick Pico project is just that. I have some boards waiting for me to make in the new year... I'd love to hack on the firmware, and maybe port the cRSID library over to it. So when thinking of other platforms to tackle, the Sharp X68000 comes to mind as an area ripe for disruption. It seems like everything for that computer is overpriced and I'd love to do something about that. The Pico may or may not be capable of interfacing with its bus, but I'd like to find out. I just need to get my hands on one!

If you read all this, thanks, and see you on places like Mastodon (I'm @polpo@bitbang.social) or Discord (join us at Retro Pico Hardware). I also have a YouTube channel that I'm way behind on making videos for. Have a good 2024, everyone!

What I Made in 2022

2022-12-31T23:00:00-07:00

2022 is when I went hog wild creating electronic projects. I kinda dabbled in stuff before, but something unlocked in my head and I just couldn't stop making new things. I think learning my way around KiCad was what really got the juices flowing.

tms-adapter

In 2021, I got a Sony HB-101 HitBit Mezzo MSX computer. It has composite out, and I wanted higher quality output. It is an absolutely beautiful computer and it felt like a shame that it was limited to composite video only. In 2022, I came across the TMS-RGB which lets you add RGB output to computers and consoles that use the TMS9128 VDP. Unfortunately the HB-101 has a TMS9118 VDP that has a different pinout and doesn't have the component output signals that the TMS-RGB requires. So I designed a little adapter board that let me plug in a TMS9128 into my HB-101 and routes the component signals to the proper pins for the TMS-RGB with the required resistors. I gave it the very creative name of tms-adapter. The design files are up on GitHub. It was written about on a Japanese MSX modder's blog, which I thought was pretty cool.

The adapter:

Installed in the HB-101:

RGB output. Still some ringing but it's much cleaner than the composite:

MAC SCSI activity LED adapter

I've been restoring a number of classic compact Macintosh computers. I use a BlueSCSI to run the systems, plugged into the external DB25 SCSI port. Unfortunately this means that the internal hard drive activity light no longer works! I designed a tiny little adapter board to tap off the SCSI BSY signal, invert it, and drive the Mac's hard drive LED. Again, the design files are up on GitHub.

The board:

The blinking:

Amiga 1200 hard drive LED mixer thingy

In 2022, I brought back an Amiga 1200 from a trip to Scotland, along with a TerribleFire TF1260 accelerator board. The TF1260 has an IDE interface on it that's quite a bit faster than the Amiga's onboard interface, but it doesn't make the hard drive LED blink. I just can't let a hard drive LED go unblinking, so I started making a board that mixes the activity signal from the onboard IDE with the IDE on the TF1260. Unfortunately, this supposedly simple project went through six hardware revisions before I wound up with something that actually worked and drove the LED with enough current! I just had too much of a "digital logic" brain when designing it and wasn't thinking analog enough. Thankfully the helpful folks on the Retro Tinkering discord set me straight and I finally got something that worked. I was pretty humbled by this experience! I still need to get the design for this one up on GitHub...

Failed designs. These were based on NAND gates:

The final working design. It fits over the keyboard LED and floppy power headers on the A1200's motherboard:

Blinking:

PiGUS

This was something that started off as what I called a "very dumb prototype" that turned out to work way better than I ever expected. The idea came into my head when watching Twitch streams by 48kRAM and djh0ffman and they both lamented the high cost of a Gravis Ultrasound card. The Gravis Ultrasound (GUS for short) was for a brief period in the early-mid 90s, the absolute best bang-for-the-buck sound card out there. It had 1MB of sample ram and could mix up to 32 channels of what it called wavetable synthesis. This allowed a normally CPU intensive task to be offloaded completely to the sound card, freeing up the system to focus on graphics and other things. The GUS was pretty good at MIDI playback, and it was used in quite a few games for that, but it really was embraced by the DOS demoscene. That's how I came to be interested in one back in the 90s, and I was fortunate to get one for Christmas one year. I still have my card, and it's working great after replacing its main brain, the GF1 chip. There are quite a few PC emulators that also emulate the GUS, like DOSBox, DOSBox-staging, DOSBox-X, PCem, 86Box, and MAME, so I figured I could use an existing GUS emulation core, run it on a Raspberry Pi, and plug it into an ISA slot with some level shifting ICs. I found a project on GitHub called RPiISA that was a bit simpler but was capable of emulating an AdLib card. Using that as inspiration, I designed the first prototype of what I called the PiGUS, waited for the PCBs to come, and then assembled it. I got the Raspberry Pi header backwards, so I had to attach it with a ribbon cable. Whoops!

After some hacking, I was able to get AdLib emulation working based on the RPiISA project. Then after some more hacking, I got the first glorious sounds of a Gravis Ultrasound, playing Purple Motion's Starshine in CapaMOD, a GUS-only module player.

I was frankly shocked. I didn't expect it to sound this good straight away. I hacked a bit and was able to add IRQ support, and got it to play X14, my all-time favorite DOS demo:

At this point, I posted about it on the VOGONS forum. The response was quite positive, with some tangents into "why didn't you just do it on an FPGA" (the answer: "I don't know Verilog"). A comment by user rasz_pl, however, changed everything. He said:

I assumed you would need pico RP2040 with PIO to respond fast enough. Add ~$2 8MB SPI PSRAM APS6404L and you could do any sound card emulation on pico

OMG. What if. The Raspberry Pi Pico is only $4, and you could actually buy them. Throughout 2022, getting a "full" Raspberry Pi was almost impossible without relying on a bot to notify you of availability or buying from a scalper. My initial goal of this project was to democratize access to the GUS, so why not base it on a microcontroller that was actually available and really cheap? The RP2040-Doom project showed that the Pico was capable of some incredible things, including emulating the OPL2 chip on an AdLib card. So I got going...

PicoGUS

As a proof of concept, I started off by taking my original PiGUS board, and hanging a breadboard with mux/demux chips, Raspberry Pi Pico, and DAC module of it. I'd use this to learn about PIO (programmable IO) on the Pico's RP2040 microprocessor, an amazing state machine-based way to handle IO independent of the CPU. This PIO was going to be the key to making everything work.

After going though the "get port IO working" steps again on the Pico, I brought in the OPL2 emulation code from RP2040-Doom, and... it worked! AdLib emulation on the Pico!

Ok, this was feeling actually possible. I ran off and came up with a PCB design and sent it off to be made. I paid for express shipping because I really wanted to get things going for real with the Pico.

Because I was in such a rush, though, this board had numerous problems. A couple of the address/data lines were swapped, which I only realized after some very frustrating debugging. I had to do my smallest/fiddliest ever bodge, something I'm still really proud of:

A couple of the signal lines for the DAC also had to be changed around, due to the way the I2S PIO program in the pico-extras project drives the lines. So I had to hang the DAC module off of some Dupont wires instead of being directly on the board. After overcoming those hardware issues, I finally got going on GUS emulation. Port-only emulation wasn't too hard, and after settling on the GUS emulation core in DOSBox-X as a basis due to its eschewing of floating-point math, I got some promising results with chiptunes. Here's an example showing some stuttering audio at the end before I switched to DOSBox-X's emulation:

The RP2040 doesn't have enough RAM on board to emulate the full 1MB of RAM on the GUS, so I was limited to pretty small songs. The comment from rasz_pl mentioning SPI PSRAM was really important – with external RAM that only used a few pins for SPI, storing 1MB of samples would be no problem, as long as it was fast enough. I finally got things working, with a lot of effort. The timing requirements of the PSRAM chip are really fiddly – only a small mention noting that reads should happen on the falling edge of the SPI clock above 83MHz in the datasheet for one of the many variants of the PSRAM chip clued me in that I needed to handle things differently. I couldn't rely on the hardware SPI module on the RP2040, so I had to write a PIO program tailored to the odd timing. Fortunately, once I got things working, the speed was more than enough:

Once that was done, I could finally load songs with more than 100KB of samples!

With this under my belt, I decided I needed to do another hardware revision, to change the swapped lines that I had to bodge, and get a few GPIOs back to get a dedicated UART out to help in debugging. And if I had a dedicated UART out, I could also use it for MIDI output. Hmm...! Learning my lesson from last time, I did my best to test these hardware changes before having another PCB manufactured. More bodges appeared on the v1 PCB, mostly to implement the new reset logic and handling of the DACK signal to save on precious PIO instructions:

After getting this "final" PCB design, I was feeling pretty good with it. Unfortunately, progress really, really slowed down. Getting reliable IRQs was eluding me, and I had a feeling that DMA was going to be even harder to nail down...

At this point, I decided I was at a good enough milestone, and made a nice video showing the progress, with high quality captures of demos and other programs running on a system with a PicoGUS:

IRQs were hard, but I eventually figured out what the problem was: a race condition between timer IRQs and wave IRQs. The GUS can trigger an IRQ for three reasons: when a set timer expires, when wave playback reaches a set point, and when a volume ramp reaches a set point. After a lot of flailing about, I came across a 95% good enough fix - reducing the audio buffer size significantly! Wave and volume IRQs would trigger at the end of rendering the audio buffer, and increasing the frequency in which those IRQs could happen helped a ton. I made another video showing the improvements this made, but there were a few regressions with IRQs in programs that were working fine before.

Unfortunately, literally hours after I posted this video, a family emergency occurred that would wind up taking up a large part of my time for the following month. I did work on things to distract myself here and there, but progress was spotty. Everything I tried to stamp out the regressions were fruitless, until I finally came to a solution – using critical_section to wrap IRQ status updating and IRQ firing in a spinlock. These events can happen on either core, and this was finally a way to get things under control. I was super happy, wrapped up work on the fixes and made a new software release on the PicoGUS GitHub project.

After a couple more days work, even more things were working, and amazingly, my buggy DMA code was working far, far better! It actually worked with some games like Star Control II. I came out with another software release and made a quick update video for #DOScember:

Now, I am tackling the issues with DMA. The first issue I found is that data is valid on the data pins only on the rising edge of DACK – this significantly limits the time to respond to each DMA event, and there's basically no time to raise IOCHRDY to slow DMA events down. Here's a shot from my logic analyzer showing when data is valid, which is along the orange line. It disagrees with almost all DMA timing diagrams I've been able to find!

The primary reason is that port IO events can happen in between the GUS raising DRQ to start a DMA transaction and the system returning back with DACK to acknowledge and actually start the DMA transfer. The short time window due to the above timing issue, the slow speed of handling certain IO events, and high latency of writing to PSRAM really make this challenging. I'm currently away for a couple weeks for the holidays, but I'm still hacking on this problem. I have a minimal Pico development setup, and I have what I think will solve the DMA issue: more DMA! I can use DMA on the RP2040 to send data to the PSRAM chip's PIO state machine asynchronously with no CPU involvement, leaving it free to handle IO events in the middle of a DMA transaction. I have it working on my minimal setup. In the new year, we'll see how it behaves in a real computer. Fingers crossed!

You can find PicoGUS's hardware design files and firmware at the PicoGUS GitHub repository.

VGA-SCART adapter

I recently got a nifty 10-port SCART switcher for my gaming console area, and the one oddball in my console collection that didn't have a way to output RGB over SCART was my Dreamcast which uses VGA. I hunted around for ways to convert VGA to SCART and found this design from Mike Chi of RetroTINK fame. It uses an XOR logic chip to do the sync combining and seems to work well. The only problem is that his board is fairly large, and I wanted something that would fit on the head of a SCART connector. Also, many Dreamcast VGA cables don't put 5V on pin 9 of the VGA connector, so I added a jumper to allow it to be powered from a micro USB connector. This current design needs a bodge to put voltage on the right pin to get my SCART switch to switch, so I've put off putting this design up on GitHub.

Apple II Super Serial Card

I also got an Apple IIe and wanted a way to easily create new disks with ADTPro. The Super Serial Card is one of the ways that ADTPro can connect, but original ones go for quite a bit on eBay. I found this project on GitHub which is a reverse engineered and simplified version of the card. That design is on a 4-layer board but it's pretty simple so I made a 2-layer version so I could get 5 boards made for $2 at JLCPCB. The board uses several obsolete components, but I was able to source pretty much all of them from an eBay seller in my town that offers local pickup, so that was cool!

The board works fine in ADTPro, but there are some serious issues with using its built-in ROM. After finding some discussion on the VCF forums about it and a related GitHub issue, it looks like there are some issues with the GAL equations that replace some of the discrete logic chips in the original SSC design. I attempted rewriting the GAL equations after peering at the schematics for the original SSC but my new GAL equations and changes to the code in the ROM by user btb haven't been enough to solve the issue. So this project is on the back burner for now. A more faithful reverse engineering or a complete emulation of the card on a Pi Pico may be the best way forward for this.

MSX FM PAK DIY

A post by Inverse Phase on Mastodon got me really interested in the capabilities of the rather limited Yamaha YM2416 OPLL FM synthesis chip and its use on the MSX series of computers. There are several cartridges that include the YM2416, from the original Panasonic FM-PAC cartridge, to several reverse engineered options that retail for 50EUR or more which would have to be shipped from Europe. I decided to make my own YM2416 board for the MSX, and found a design by Erik Luppes for one. After reading a thread on MSX.org about it, I decided to change his design a bit to avoid some the audio noise issues mentioned in the thread. This was mostly adapting the layout a bit to avoid having the analog traces crossing all the way across the board, and making the PCB fit in a Konami style cartridge shell. I decided to call it the "FM PAK DIY" because I wanted to make the design DIY friendly. I had it made and it sounds really good, except in my Sanyo Wavy23 MSX2 machine, which has known issues in its cartridge expansion audio circuit. This is another one of my projects that I'd like to get up on GitHub, but the license situation for the original design is a bit unclear to me and I'd like to get it right.

Conclusion

Oh man, this post was a lot longer than I was expecting. I hope I can keep this up in the next year. Despite a lot of challenges in 2022, this has been some of the most fulfilling my "random retro tinkering" hobby has become. If you made it this far, thanks for reading! If you want to keep up with what I'm doing outside of these longer-form posts, I post on Mastodon at @polpo@bitbang.social.

Also, PicoGUS has spawned a few other projects: PicoMEM from FreddyV and a Pico PCMCIA project from yyzkevin. We talk on a new Discord server called Retro Pico Hardware and offer each other support and encouragement. If you'd like to see what we're up to and to help out with anything, feel free to join on the link above.