APSoft

Adding VGA hardware palette support

VGALIB has lead a long and meandering path, development has been an exercise of leveling up each of 3 different environments: PC hardware running DOS, SDL under Linux, and SDL under emscripten. Much of the early development was done in dosbox with the Borland C++ 3.1 IDE, but once I grew past the point of basic C++, using std::string, I had to abandon the BC3.1 IDE and go strictly to makefiles. It was during this time that using the BC3.1 IDE for editing (and it’s weird Brief key sequences) started to become an exercise in patience. I really enjoyed developing on Linux, since that’s what I’ve done for the last 25 years.

Moving to makefiles under DOS was no small feat, the issue is that dosbox is a best effort emulator for running games, but compatibility with Borland C++ 4 and later is sketchy causes crashes. I ended up creating a Windows 2000 VM with Virtualbox to compile VGALIB, but even that acts peculiar and cmd.exe requires End Task. Virtualbox doesn’t have guest additions for any 16bit legacy OSes, so Win2K is the oldest usable environment. My current development environment is Eclipse for the editing (with VIM plugin), Win2K to compile the DOS programs, and dosbox to run them. For Linux and emscripten I use Eclipse with command line make.

The reason my build environment is important to this article has to do with the development target that was most feature complete: SDL running on Linux. Palettized 8bit mode on SDL is really a pain to program to, much more so than straight RGB or RGBA, but it mimics the original IBM VGA 13h mode most closely. I implemented palette support as a matter of requirement when I added SDL support, since there there is no default palette. Until this time I hadn’t added hardware palette support to the VGA driver, I simply relied on the default VGA palette (which is fine for most things).

The Sale of WebCom

The sale of WebCom was both bitter and sweet. The sale represented independence and success for many involved, but it also was the beginning of the end. WebCom was bootstrapped from what money Chris had and some surplus equipment that we got from a customer in exchange for free hosting. That equipment lasted us until late 1995 when we needed to transition from a 486 running Windows NT 3.51 and Microsoft SQL Server, to a Sun Enterprise 1000e running Sybase SQL Server.

I mentioned before that Chris and Thomas organized the company with a 67%/33% split, eventually I would have 1%, taken from Chris’ portion, and Neal [the CFO] got 10% IIRC, of which I think Chris and Thomas gave up 5% each. After we moved to 2880 Soquel Ave, Thomas started working on his exit from the company. That exit would precipitate one of the biggest threats we ever had as a company.

Hacking CGA

This is meant to be a short post to talk about some CGA idiosyncrasies and how you can bypass them.

My video library VGALIB now supports CGA in addition to VGA, EGA support is planned too. Adding VGA was simple and that’s why I did it first; VGA implements a 320×200 linear framebuffer. A linear framebuffer is one where each pixel is represented by a simple lookup and the pixels are contiguous in the memory region. The formula width*y + x is commonly used to perform linear buffer address resolution. It is because of this simplicity that I made the internal representation of images 8 bit linear buffers. Each pixel is represented by 1 byte that can hold 1 of 256 colors.

WebCom: New Locations, New Logos, Questionable OpSec

The only constant in a startup is growth, and WebCom grew exponentially during the 4 years it was WebCom. Recapping a little bit, when I joined WebCom it was just Chris and Thomas, shortly after came Rick. There were 3 people in the A suite and Rick was in the B suite, more employees wouldn’t fit! In late 1995 we moved from 903 Pacific to 125 Water St, the new location was a lot bigger but shared the same pains: parking. Working in downtown Santa Cruz is an exercise in patience, strategy, and luck. Sometimes all 3 are on your side and sometimes all 3 are against you!

The new location was a welcomed change from the office full of hand-me-down furniture, we got cubicles! Yes, it seems strange to be excited by cubicles, but it meant that Rick and I got nearly double the space we had before. The A suite had 2 offices, one that was a nice professional office and one that had the telephone lines and other miscellany — the latter became the break room and server room, with a cubicle partition in the middle. Thomas was the proud tenant of an 8×12 cubicle office that didn’t quite reach the ceiling. I think we had about 13 cubicle desks at that location, which lasted us until late 1997, when we were bursting at the seams.

Web Communications

Web Communications [WebCom] was a web hosting provider that started in Santa Cruz California in late 1994, opening to the public in 1995. WebCom was the brainchild of Chris Schefler, a Cal State graduate who believed in freedom, communication, and ecology.

Chris started WebCom with co-founder Thomas Leavitt in a small windowless office at 903 Pacific Ave, Suite 306 A. This building was informally named Geek Hall because it was the nexus of every internet connected Santa Cruz startup.

Introduction to VGALIB

During the Christmas break of 2018 I started working on a cross-platform video library that would work on DOS, Linux, and Web. The idea was really born from tinkering with some old C++ code that found on an old hard drive.

I wrote my first C++ code in 1995 in Borland C++ 3.1 on my old DOS computer. When I was a Junior in High School [ca 1993] I was part of what they call a “coding bootcamp” today. There were 2 Support Engineers from Borland, Tom Orsi and Jeff Peters, and they volunteered to teach a small group of HS students how to program in C. Most, but not all of us, had prior programming experience in another language. My experience was with Microsoft QBasic, Visual Basic for DOS, and Visual Basic 3.0 for Windows.

Fadal 1400-1 CPU Card Reverse Engineering and Schematic

This article originally appeared in My little (home) shop thread on Practical Machinist.

I only worked on the CPU board schematic a few minutes today, but I finished all the address decoding logic.

The 8088 only has 20 address lines, of that, 16 of them are used for addressing segments of 64KB each. The address lines A16 through A19 are used as card selects to talk to the peripheral cards. There is a 4 to 16 line decoder that takes the upper nibble of the CPU address, then converts that to a selector that is 1 of 16 lines on the bus. Fadal repurposed a bunch of address and logic lines to make these card selects.

A 20bit address is represented as 5 hex nibbles, like 0xFBC00, that’s segment 15, address BC00. That happens to correspond to the video memory on the video card. The first F selects card 15, which is the video card (we are talking base 0 numbers here, so 0-15), the BC00 selects the base address within the F segment. The F segment also contains the system ROM, which is located at FE000-FFFFF, an 8KB chunk. The video ram is only 1KB, so it occupies addresses FBC00-FBFFF.

It would seem that the memory expansion cards occupy a card select range, though I’m not certain exactly where the memory and NC executive ROMs are mapped yet. Once I have the schematic completed and the system ROM reverse engineered, I could design my own memory expansion card.

Fadal 1420-1 Video Card Reverse Engineering and Schematic

This article originally appeared in My little (home) shop thread on Practical Machinist.

I finished my reverse engineered schematic of the Fadal 1420-1 video board. I’d estimate I have 20-25 hours into the schematic at this point.

The schematic, and observation of the control display, lead to some interesting observations about the original design.

It’s widely told that Adrian de Caussin is the one who designed the control hardware, unfortunately he passed away some time ago (a reference from 1996 indicates he’d passed by then), so this public accounting may be the only hardware level details known outside of the de Caussin family.

I did reach out to David de Caussin the younger to try and learn details about the original control development, because at this point they are considered vintage computer systems. Unfortunately I didn’t receive a reply from him, so I had to go at it myself.

Fadal Chargen ROM Reverse Engineering

This article originally appeared in My little (home) shop thread on Practical Machinist.

That’s the contents of the character generator ROM on the Fadal video card. I used a Parallax Propeller development board to make a breadboard EPROM reader.

I’m interested in making a video card that will plug in place of the Fadal card and output a video format of my choosing.

Specifically I’m talking about using a Parallax Propeller microcontroller to generate a VGA signal. The picture is actually the Propeller outputting the ROM data to a VGA monitor.

Fadal CNC Reverse Engineering

This article originally appeared in My little (home) shop thread on Practical Machinist.

Just to be clear, the control and electronics work fine on my Fadal at present, it was the iron that needed major help.

The process of reverse engineering the control started with researching the history of the Fadal control. On the VMC Electric website they give a few pieces of information about the process of creating the control.

They said they used an Imsai 8080 to develop the NC executive. If you read closely you’ll see they used the NC software to process G-code into NC tapes for their other machines. This specifically includes applying cutter radius compensation and other stuff that old NC systems couldn’t do.