The Bondwell B300
I believe it was in 1991 (or possibly 1992) that I got a secondhand computer that my father brought home from work. It was a Bondwell B300 “lap-sized” computer with a built-in LCD screen and a crazy aspect ratio. One of the known limitations of this specific machine (and I suspect the reason my father got his hands on it) was that the floppy drive was faulty. This, in an era when networks weren't common, was quite a problem.
But the computer already had some software installed, a word processor called Q&A Write, and a few games: Tetris, GP (Grand Prix Circuit), Golf, The Hunt for Red October, and a flight simulator called AFS.
I fondly remember playing those games, especially Tetris, but also GP (Grand Prix Circuit). The monochrome LCD screen and the weird aspect ratio made the golf game virtually unplayable, and The Hunt for Red October was way too hard, and I don’t have any memories at all of playing the flight simulator. Perhaps it never even worked.
I kept tinkering with that 286 and, especially since it was a “portable computer”, I remember bringing it with me to friends' places. I also learned a lot about computers, DOS, and of course, how to type on a keyboard. But that broken floppy was a problem. I remember asking my father to take the machine to a computer repair shop and see if replacing the floppy drive would fix the problem; the reply being (as I remember it), “No, changing just the floppy drive won’t fix the problem.”
So I used the machine as it was. One of the cooler aspects of it was that it had a 1200 baud modem, but I didn’t really know enough to use it, I just knew it existed. I played the pre-installed games, rummaged around the filesystem, tried out commands, and so forth. Eventually, however, I made a mistake. As I remember it, I somehow messed up and moved a whole bunch of files to the root of the C: drive. In my attempts to clean it up, I created subdirectories for each file type and moved the files into those subdirectories; including command.com, which I placed in a directory named “COM”. After that, the machine wouldn’t boot.
I have a very vague recollection of bringing it to my friend Björn and trying to connect the hard drive to one of his old XT/AT machines, but I don’t really remember how that turned out. Eventually, the B300 went into its custom Bondwell carrying case, which was left in a closet under the stairs at my father’s house until 2012. When I found it in 2012, it was obvious the carrying case had been destroyed by “something.” It was sticky and gooey, and I didn’t really want to touch it. But I put some gloves on, took out that childhood computer of mine, and placed it in a plastic container with a sealed lid. It stayed in that container for another 13 years, until I unpacked it again this summer.
The floppy drive and floppy cable were missing, but inside that black box was my childhood 286, a manual, a power supply, and some loose cables. Fortunately, I had removed the two 6V lead-acid batteries before storing it, otherwise, it probably would have been completely ruined.
30+ years later
With a lot of trepidation, I booted the machine for the first time in what was probably more than 30 years.
It did turn on, and it went through the BIOS POST with several of error messages, including the rather menacing “FLOPPY DISK CNTRLR ERROR OR NO CNTRLR PRESENT”.
Eventually the computer continued and attempted to boot from the old hard drive and, not surprisingly, failed. The boot from the hard drive failed with the message that DOS couldn't find COMMAND.COM (or rather, the Swedish equivalent). That last message was expected, since I had moved COMMAND.COM away from C:\.
I was back to the root of my problem, no floppy drive and a broken OS on the hard drive, just as 30 years ago. But this time around I had far more resources to bear, including my very skilled friend Peter.
The faulty floppy controller
The first step was to investigate why the BIOS thought that it had no contact with the floppy controller. I remember that the floppy wasn’t completely dead, sometimes it would temporarily work, which suggests a loose connection. Physically shaking the machine right at boot would sometimes bring the floppy drive back to life.
The original floppy drive had been lost, so to get going I connected a standard PC 3.5” floppy drive using a typical PC floppy cable, the kind with two connectors and a twist for the second one.
One of my theories was that a faulty solder joint would explain the intermittently working floppy drive. In many cases, a bad solder joint can be found through careful examination using a loupe or similar visual aid. This actually took quite a bit of effort, because the designers of this machine clearly never intended for the motherboard to be removed. Removing the motherboard required desoldering several of the peripherals, the glued-pc-speaker included. I will admit that when it came to the modem, I simply cut the cables. I don't expect to ever have a PSTN phone line to use it with again.
Searching the motherboard very carefully yielded very little, no obvious bad connections.
We did, however, find the floppy controller, a large 48-pin DIP package marked DP8473N. The DP8473N is a floppy disk controller by National Semiconductor that, if I understand the specifications correctly, had as one of its main advantages that it didn't require (any?) external components and could be connected directly to the floppy drive.
When we looked closely at the DP8473N floppy controller in my machine, we noticed something extra sticking out of pin 25. It was hard to see, but it looked a bit like someone had wedged a cable between the chip and the socket. Unfortunately I didn't take any picture of it, so it isn't visible in the picture above, the photo was taken after the issue had been fixed.
After some hesitation, I decided the best course of action was to remove the chip and double-check what was going on with pin 25. It turned out pin 25 had been bent, and what we had seen sticking out, and perceived as the remnants of a cable, was actually the bent 25th leg of the chip. According to the datasheet, pin 25 is “digital ground for the 12 mA microprocessor interface buffers. This includes D0–D7, INT, and DRQ”. No wonder the controller didn’t work as it should.
Luckily, all that was needed was to straighten the 25th leg and reseat the chip in its IC socket. This solved the “FLOPPY DISK CNTRLR ERROR”-problem, but the machine still didn’t detect the floppy drive or boot from it. The machine found the floppy controller, but not the floppy drive.
The faulty floppy drive
In total, I have 3 floppy drives available for experimentation. At least one of them I have used recently.
A floppy controller is capable of driving more than one floppy at a time. To let the connected drives know which floppy drive the controller is addressing there are “drive select”-pins in the cable that can signal which drive is the target. This also requires the floppy drives themselves to know which drive select pin to listen for.
Different platforms follow different standards and conventions. A typical PC floppy drive is hard-wired to be drive 1 and listen on Drive Select 1; meaning that Drive Select 0 is not used in single floppy machines.
In contrast, Amiga drives typically default to DS0. To be more versatile, some older floppy drives come with jumpers that allow the user to configure which drive select pin the drive should respond to. This is somewhat similar to the jumpers used to select which drive was master for old IDE drives.
To connect two floppy drives to a PC (both hardwired to be DS1), a special cable is used that has a twist for the second drive. This twist rewires DS0 to DS1, allowing both drives to be used even though they are both physically set to be DS1.
One of the reasons that we started looking into the jumper settings was that, according to online forums, the PC standard of hard wiring the floppy to DS1 wasn’t well established in 1989. It was not uncommon for drives to either have jumpers or that they were hard-wired for DS0 in single-drive-machines.
Only one of my three floppies had jumpers, the oldest one, a NEC from 1992. So all the initial testing was done using that drive. We tried moving the jumper to all possible positions and connected it to both connectors on the floppy cable to test out different configurations.
Eventually my friend Peter asked the obvious question: “Are you sure this floppy drive even works?”. Of course I wasn’t sure, and finding out wasn’t all that easy either.
To test it, I had to dig out an old Dell workstation that I hadn't started in almost half a decade. Fortunately, it had Ubuntu 16 installed and connecting the old NEC floppy drive was easy enough.
It turned out that the old NEC drive was either dead, faulty or possibly not compatible with a regular PC. Long story short: the drive with the Drive Select jumpers didn’t work with the Dell computer, so it's probably not functional. Out of the three available floppy drives we tested, only two were confirmed working. However, both of these were standard PC-drives hard-wired for DS1.
This is what the twist on the cable is for, if the drive is connected at the end of the cable (the part with the twist), it will be addressable by the computer as DS0 even though the drive itself thinks it's DS1. All in all, it makes things more difficult, but it shouldn’t be impossible to make it work.
While connecting the power for the floppy I noticed that the original B300 floppy power connector had been replaced. I can only presume that this was done under the assumption that the problem with the drive was a faulty power connector. The patch had been done with color matched heat shrink tubing, so we can safely say that it wasn't me who did that as a teen, if anything I would have used black electrical tape. The patch looks nicely done and works perfectly fine.
The faulty floppy cable
Once we had confirmed that the controller was functioning, the drive had power, and that we had a working floppy drive, one of our theories was that there was a breakage or disruption between the controller and the floppy pin-header. So we very diligently measured the continuity between the controller and the floppy pin-header on the motherboard. The more we measured the more confused we became, because something was clearly off.
The datasheet for the DP8473N is fairly straightforward. Pin 4 (DR0) is Drive Select 0 and pin 6 (MTR0) is motor select 0. Pin 3 and pin 5 are for Drive 1.
And the pinout for a floppy connector is also very clear. I have limited the pinout below to the relevant signals:
On a correctly functioning circuit board, the controller is wired this way:
MTR0 on the controller connects to PIN 10 (motor 0 enable)
DR1 on the controller connects to PIN 12 (drive select 1)
DR0 on the controller connects to PIN 14 (drive select 0)
MTR1 on the controller connects to PIN 16 (motor 1 enable)
On The Bondwell B300 however, the controller is connected to the motherboard floppy header like this:
DR0/DS0 on the controller is connected to PIN 10 (Motor 0 Enable)
MTR0 on the controller is connected to PIN 16 (Motor 1 Enable)
MTR1 on the controller isn't connected to the motherboard floppy header.
DR1/DS1 on the controller isn't connected to the motherboard floppy header.
It's worth noting that MTR1 and DS1 on the controller are connected to the external DB25 floppy connector at the back of the computer. The pinout is in the manual, but I have not double-checked if it's actually correct.
It seems that the Bondwell B300 motherboard has the Drive Select and Motor Enable PINs crossed and neither of the two DS-pin in the floppy cable is connected to the floppy controller. Obviously, this would never work with a regular PC floppy drive; and honestly, how this could ever work with any floppy drive is just beyond my comprehension. Possibly the original cable had a patch for this, or the original floppy drive was unusually forgiving.
The solution, however, was quick and easy and worked on the first try; we put a small patch at the end of our two-connector cable that bridges the relevant signals. From the picture below it seems like floppy connector pin 10 (Motor Enable 0) and floppy connector pin 14 (Drive Select 0) (after the twist) have been patched together. But note: this is after the twist! So on the motherboard side, what I believe is happening here is that we are patching pin 12 (Drive Select 1) and pin 16 (Motor Enable 1).
It's confusing, very confusing, but it works. Let’s just call it a success and leave it at that.
With the patch in place, just like that, the old Bondwell B300 detected its floppy drive and began booting from floppy!
The 20 Mb MFM hard drive
The Bondwell B300 has a beautiful 20 Mb MiniScribe MFM hard drive connected to a custom Bondwell controller card that is mounted directly on the bottom of the hard drive. Once the machine had booted FreeDOS from floppy, I hesitantly ran the command DIR C:\, not really knowing what to expect.
I was very surprised by the results. My expectation was that C: would be cluttered with old files, since my memory of what had gone wrong was that I had accidentally moved lots of files to C:, and then in an attempt to clean that up had moved *.COM to a subdirectory, including COMMAND.COM and thereby rendered the machine unbootable.
The machine was still unbootable from the hard drive, but C: did not contain what I thought it would contain.
Running the DIR C: command revealed a freshly installed IBM DOS 5 installation from 1994. Apparently someone (I assume me) had managed to re-install DOS on the drive, but for unknown reasons it still refused to boot from C:.
What happened in '94?
I vividly remember the day that I messed up COMMAND.COM and my Bondwell didn’t boot anymore. I can’t say that I remember which year it was, but I remember clearly where I was, what I did, and the feeling of hopelessness that I wouldn’t be able to solve this problem since the floppy drive was bad.
I also remember bringing the machine over to my friend Björn and removing the hard drive and trying to put it in an old IBM XT/AT machine of his. I have always assumed that the result of that endeavor was a failure to even read the drive, since it obviously didn’t get the machine started. On a side note; I do remember that Björn’s father (I believe his name is Leif) told us very strictly to not use magnetic screwdrivers in proximity to the hard drives.
It’s clear now that I don’t fully remember what happened. We can see from the data on the drive that in August 1994 we reformatted the hard drive and installed IBM DOS 5 as well as copied a few games.
So, the MFM hard drive had what looked like a fully functional IBM DOS 5 installation but despite this it didn’t boot. As a clue to why it didn't boot there were numerous read errors from the hard drive even when just running DIR to list files.
Resurrecting the MiniScribe and booting from the hard drive
MFM hard drives are notorious for their bad blocks. In fact bad blocks were expected and somewhat accounted for by design. MFM hard drives came with a “bad block table” printed from the factory and my MiniScribe hard drive was no exception.
Bad sectors could be mapped out, and the FAT filesystem has a simple but functional method to mark sectors on the hard drive as bad by marking the corresponding clusters in the FAT with 0xFFF7. This tells the operating system not to use those clusters.
I assume that this was normally done during the formatting of the hard drive, and the DOS FORMAT-command has a flag for it (/B) that would scan for bad blocks and mark them as such in the FAT.
When running DIR C:\ it was clear that this hard drive had developed more bad blocks and it constantly gave the “Abort, Retry, Fail” option while trying to calculate the amount of free diskspace. For older versions of DOS there is the tool CHKDSK that can be used to check the integrity of the FAT, but with MS-DOS 6.2 Microsoft shipped an updated tool called SCANDISK.
Booting from a MSDOS 6.22 boot floppy (yay!) I was able to run scandisk on C:. The first few times I ran this tool it told me that it had found an incorrectable error in the FAT-structure.
This flustered me for a while, but I have since figured out that after powering on the hard drive will give quite a lot of read errors until it has been turned on for a while. Once it has “warmed up” a bit the number of read errors decreases and the FAT is fully readable.
Once the drive was a bit more comfortable, I managed to run SCANDISK and it found and fixed quite a number of problems, both logical and physical and reallocated some files from the DOS-directory to sectors without read errors.
After this my Bondwell B300 booted from its own hard drive for the first time in well over 30 years. I found Grand Prix Circuit (GP) from Accolade installed on the hard drive and it looked and sounded just like it did when I was a kid. Lots of fun and nostalgia all around!
But I was missing Tetris and the hunt for red october and a lot of the productivity tools that used to be installed on this machine. Clearly, they had been lost in the reformatting of the hard drive.
Data recovery options?
The one game I wanted to play the most on this machine (Tetris) was missing from the hard drive and I really wanted to install it again. But installing lots of cool games on the drive would overwrite unallocated space on the hard drive and nullify any chances I would have of ever doing any type of data recovery from the drive.
Obviously doing data recovery from a 286 with only a floppy as interface was going to be a hassle, so I spent some time weighing my options carefully. Potentially the reformatting of the drive in 1994 had overwritten the entire drive, specifically writing a test-pattern to the drive when looking for bad blocks. However, this seems to have been an option only in version 6 of MS-DOS, so there was a chance that it wasn’t in use at the time of the reformatting of the hard drive.
Another problem was that I needed some type of hard drive imaging tool for DOS that would run on a 286. After a bit of searching, I came up with Norton Ghost version 2.0.4 from 1996. It would run on a 286 and a careful reading of the manual showed that it can be started with the option “-IA” to force a sector by sector copy of the entire disk.
-IA Image All. The Image All switch forces Ghost to do a sector by sector copy of all partitions.
Interlnk/Intersvr
I also needed a way of getting the data off the hard drive and onto another storage media. Realistically the floppy drive isn’t really a bad choice, the hard drive is only 20 Mb and that would fit into 14 floppies, clearly archivable. There were a lot of games that shipped on more than 10 floppies back in the day (11 floppies for Monkey Island 2 and 12 for Kings Quest 6). But Norton Ghost didn’t seem to support splitting the image to floppies and I didn’t really have 14 empty floppies lying around anyhow.
Back in the 90s, I used a technique to transfer files between two DOS-based computers using a serial cable. INTERLNK and INTERSVR were a pair of utilities included with the last few versions of MS-DOS that essentially turned one machine into a very basic file server for another machine to mount as a drive letter in DOS, thereby enabling remote file access over a serial (or parallel) cable.
So the Bondwell B300 can be booted off a floppy disk with MS-DOS 6.22 with Interlnk.exe and ghost.exe while a virtual machine runs MS-DOS 6.22 with Intersvr.exe and I can interconnect these two machine requiring only 3 pins (RX, TX and GND). Only needing 3 pins was a fortunate thing because I did not have all of the adaptors needed so a bit of improvisation was required to get it working.
Due to hardware limitations in the 286 UART transfer speed capped out at 19200 baud, making the transfer somewhat slow yet functional.
The 1 Gb hard drive from the virtual machine running on a modern PC showed up as E:\ on the Bondwell, allowing for the usage of the “Local/Server”-imaging option in Ghost.
Norton Ghost successfully transferred a files-only compressed copy (6 Mb) of the hard drive using this technique.
Read errors, read errors and more read errors
When running ghost.exe with the -IA (image all) option it fails almost immediately at around 3% completion. As I understand it from reading online, later versions of ghost may have better support for handling read errors, but those versions of ghost won’t run on my machine. So basically, I was stuck, ghost wasn't the answer.
Once again, I reevaluated how likely it would be that there would actually be some data on that hard drive. Spending a lot of effort to image an empty hard drive would be sort of an anticlimax. I looked for a way to confirm if there was data available in unallocated hard drive space. One of the tools that was installed on the hard drive was a utility called PCSHELL, and this tool had an option to view individual sectors on the disk in a hex editor. In order to evaluate my options, I restored the ghost image into a virtual machine, allowing me to boot the same DOS version and have access to the same tools in an environment that would be a bit more forgiving if I messed something up.
Naturally all the unallocated sectors that I viewed in the virtual machine contained only null bytes, but it allowed me to learn how to use the tool (without accidentally wiping the disk) and gave me a reference for what should be empty and not.
Running the same command and viewing the same unallocated sectors on the real machine unequivocally showed that the unallocated space on the hard drive was full of data. I was even lucky enough to just happen to stumble over some old text referencing TETRIS.EXE just to confirm that what I was looking at was the old installation.
So, this not only confirmed that there was data to be recovered from the hard drive but it also confirmed that the data to be recovered was not in the Ghost image. I needed another tool!
tschak909/disk-xfer
Reading some forum threads on the topic I eventually found the disk-xfer-tool by Thomas Cherryhomes. In fact, it seemed to fit the bill perfectly; it would read the entire disk using the DOS INT 13h and write it either as a disk image to a local drive or over the serial port to a special recipient program written for Linux.
The imaging tool was exactly what I needed, it would read the full drive and just dump it out as a file to a local drive. And I just happen to have a 1 Gb “local” drive ready for writing mapped with Interlnk/intersrv. All in all, a very fitting solution, with the one little exception that Thomas’s imaging tool didn’t handle read errors. When the Imaging tool encountered a read error it would just exit, just as ghost.exe.
The patch wasn’t complex, in case of read errors returned from INT13h, instead of aborting it will fill the buffer with a known pattern (0x42) and then just move on to the next sector. This ensures proper alignment of the disk image in the output file while at the same time marking the data clearly, which makes it easy to see where data is missing due to read errors.
But with the update in place in the source code, I still needed to compile it into a DOS binary that would work on a 286 from 1989. It took a while, but eventually I got the Open Watcom compiler installed and working. Then it turned out that the Makefile included in the project wasn’t compatible with the make command included with Open Watcom but instead expected GNU Make. Since I was doing the compilation on a windows machine (I know, rookie mistake) I figured out that I could install trusty old MSYS to get GNU Make and successfully compile my updated image-tool.
Once running it encountered numerous bad blocks, as foretold by SCANDISK, but it successfully evaded those and continued dumping the disk for a total of four hours at glorious 19200 baud!
Once completed I confirmed that the image was complete by successfully booting it in VMware.
Recovery of files
So, from the hexdumps I had already concluded that there was data available in unallocated space. Now I needed to find a way to extract it. The first thing I did was run the Sleuth Kit tool fls on it. The Sleuth Kit (TSK) is an open-source tools suite used for digital forensics, analysis and data recovery from disks and filesystems. Sleuth Kit fully and partially recovered a long list of files using remnants of filesystem meta data on the disk. But using strings I also found what looked like partial text in Swedish with somewhat weird formatting, for example a lot of what I would assume to be spaces in the text had been replaced with 0xCF. At the very beginning of the text was the preamble “Q&A WRITE -- B. Emerald”.
This stirred a memory, one of the word processing tools that this machine had installed was called QA. And some googling turned up Symantec Q&A; a “database manager that includes a word processor”. I don’t have any memories of using the database part, but I think I used the word processor to write and then print to a dot matrix printer (a Star LC24-10 if I remember correctly).
The internet archive (archive.org) actually had a 286 compatible version of Q&A Write available for download, though in English, I presume the version I had as a kid was in Swedish. But it turned out to be enough for what I needed, as I could install it in the VMware clone that I had just successfully created. And using this clone with Q&A in VMware I created a set of new Q&A files with known file-contents, such as a few static strings.
Analysis of the newly created Q&A Write files showed a clear and simple header, “TBWP” followed by a null, that could be used with file carving tools such as foremost and scalpel. According to an old online specification I found “TB stands for TouchBase, Symantec's original internal name for the product. WP = Word Processor”.
A really nice thing about the Q&A Write file-format is that just following the TBWP-header is a date in clear-text, so it's really easy to see when the files were created, even when the filesystem metadata is missing.
A simple scalpel definition yielded roughly 12 files, most of them opened nicely in Q&A Write, both in VMware and on the real machine.
TBWP y 50000 TBWP\x00
I found several lists of movies that I had on VHS, and a long text about bats. But the most fascinating document was a book review that I had written in September 1992, it's by far the oldest digital file that I have created.
Re-installing the old games and tools
Now that I have a sector level copy of the entire hard drive, or at least the readable parts, I can safely install anything I find interesting on the old hard drive. Rummaging through archive.org I found a whole host of games that I played as a kid (not all of them necessarily on this specific machine).
I installed the following games:
Tetris – It's just the way I remember it, very compressed by the aspect ratio of the LCD.
GP – Honestly, this game is very hard to play on the LCD, it will require an external screen.
The Hunt for Red October – This game is hard and just as confusing as I remember it!
Lemmings – This game wasn’t on the original machine, and it’s hard to play without a mouse. But it looks absolutely gorgeous on the backlit LCD display, the photo really doesn't do it justice.
Prince of Persia – It’s such a beautiful game! I never played it on this specific machine, but I did play it as a kid, and I got just as frustrated with it as I did back then.
Golf – It's unplayable on the LCD, it will require an external monitor.
In addition to the games I also remember using Q&A Write, so I installed that as well and copied the recovered files so that I could open them in all their wonderful LCD-glory.
CGA to VGA converter
Graphics for PCs went through an evolution with many steps, and I had first-hand experience from several of them. First there were the 80x25 and eventually Hercules graphics (MCA) modes that I had on my first IBM PC. It was monochrome but quite high resolution. Then on the Bondwell B300 I had CGA which was 640x200 with very limited color space and then I had VGA on my first 486 computer, with a Trident 9016 graphics card that supported up to 800x600 in 256 colors (or 1024x768 in 16 colors). When I enumerate it like this, I realize that I never had a computer with EGA though.
Once upon a time I had a CGA monitor, but it's long gone and I’m very unlikely to buy another one. So now I’m looking for a solution to connect my CGA output from the Bondwell B300 286 to a modern screen.
CGA (Color Graphics Adapter) was the first color video standard for IBM PCs. It supports both Composite video and digital RGB output, but the B300 only has monochrome composite video. The only color output for the Bondwell B300 is the digital RGBI interface.
The DB9 output uses one pin per color and one intensity-pin, for a total of 4 bits of color signal, together with VSync and HSync, at a pixel rate of 14.318 MHz.
A fascinating thing is that the digital RGBI signal can be converted to an analog 15 kHz VGA-compatible signal using just a few resistors per channel. I bought this ready-made adapter for 130SEK (~13 EUR).
But this type of adapter will output a 15 kHz signal, far too slow for most modern monitors that typically has a lowest supported frequency of 30 kHz. There are monitors available that will sync to 15 kHz, but they are somewhat rare, and I don't have any such monitor.
So we are going to need a little bit more than just a few resistors. Fortunately there is this really nice little ESP32 project available on GitHub called RGBI2VGA developed by Alexander Martinelle.
All that is needed is an ESP32, some resistors, a DB9 for the RGBI-interface and of course a VGA cable for output. Is it flawless? No. Did it work out of the box? No.
Alexander designed it for the Commodore 128 and that computer seems to have completely different vertical and horizontal sync parameters, so it took quite a bit of fiddling to it that right. Additionally, and this is probably just about missing skills on my part, the original code packs 2560-RGBI samples into 640 VGA pixels, and that works really well since 2560 divides nicely by 8. My problem is that I need more than 2560 samples to fit the entire CGA output screen from the Bondwell B300. I seem to need 2880 samples, and that doesn't divide nicely into 640.
Something something hsync, something something 14.31818 MHz, who knows? I can read in more data and then just skip some bytes to get something that looks okey-ish, but the scaling is completely off and I get lots and lots of weird artifacts. But hey, let's go with okey-ish for now and play some games!
It works sufficiently well, but some day I'll give it some more time and try to get the scaling from CGA to VGA to work better. 2880 divides nicely with 720, but I seem to be running out of either CPU-time or memory on the ESP32 when I try to do 720.
