BigDumbDinosaur, thanks for describing those projects. 100,000 lines taking two days to assemble. Holy God.
Nowadays I suspect assembly time would be in less than a minute. The Kowalski simulator will assemble my
mkfs program (17,000+ lines of source code) in a few seconds. Things have improved a bit since the days of the C-128 and its 2 MHz 8502 MPU.
BTW, my development system was supported by a UPS. A power blip during assembly would have been unpleasant, to say the least.
I'll assume that the truck leasing and billing system was a commercial project...
It was.
Why was the Commodore 128D chosen as the hardware platform? Was it your prerogative?
Actually, the 128D and Lt. Kernal combination was a pragmatic choice made by my client—I suggested, they chose. The client was a startup company whose capital was largely invested in refrigerated truck trailers, which at the time, cost about 40,000 USD each. They were prepared to do all the leasing and billing activity on paper when the owner's then-wife came to me and asked if I could help them out. It was immediately apparent that their requirements would be best met on a system that supported concurrent transaction processing. Unfortunately, the available machines at the time that could do that were running upwards of 25,000 USD minimum, just for the hardware and an operating environment. I was able to do everything for about half of that, with most of the cost in software development. As the husband-and-wife were friends and were financially stretched very thin, I gave them the best price I could without short-changing myself. They got the functionality they needed for a much lower cost, and the only significant downside was somewhat slower performance.
Did the client/employer give any push-back to using a "toy" computer?
I don't think they ever saw the C-128D as a toy. I already had a Lt. Kernal system for my own use, so what I did was bring two C-128Ds, the Lt. Kernal and a multiplexer in for a demo. When they saw what the combination could do they were sold on the idea. It was a whole lot cheaper than a Point 4 or MAI BASIC IV mini, and took up less space.
Why, specifically, the C128D?
Several reasons, some technical and some cosmetic. Going back to the "it's a toy" mentality, the C-128D looked more professional than the flat 128 due to the detachable keyboard and general arrangement. It was more PC-like in appearance, which meant it would not look out of place in an office.
I already had another friend who was (still is) in the auto repair business processing on a C-128D, and he was quite satisfied with the machine. So it wasn't as though I would be venturing into the unknown.
From a technical perspective, the 80 column display was a requirement, and since the 8568 VDC in the C-128D was shipped with 64KB of video RAM, the display capabilities were substantially enhanced over the flat 128. I devised a simple windowing system that took advantage of the extra video RAM and the 8568's "blitter" capabilities to produce fast and responsive display changes.
Did you use the on-board Z80?
No and I never even contemplated doing so. For one thing, I'm not fluent in the Z80 assembly language. More importantly, the Z80 in the C-128(D) was hamstrung, as it couldn't directly talk to the I/O hardware. CP/M on the C-128 had to use the 8502 as an intermediary, which really hurt performance, since CP/M tends to be heavily I/O bound. Also, the Lt. Kernal DOS was written entirely in 6502 assembly language, and the APIs were likewise all 6502 assembly language. Getting the Z80 involved would have been a programming nightmare, with little gain.
Did you use the high memory?
By high memory are you referring to RAM under the ROMs? I did use that RAM for disk buffers, a place for an interrupt handler and as an intermediary space for inter-workstation communication.
I made extensive use of RAM1 for data structures. Rather than use the cross-bank load/store functions in the kernel, I wrote new ones that were "one way." That reduce the amount of MMU activity and produced better performance.
By "running on a bunch of C128Ds", did you mean running together to perform a single, collective, function, or each C128D was a essentially a client terminal that could run this application or that application (on demand), but they all talked to the same database through the multiplexer? Or something else?
Each C-128D essentially ran as a smart terminal, both executing the program in use and handling user interactivity. The only time users would become aware of others users' presence would be when two (or more) attempted to acquire a lock on a resource.
I had a lot of help from Fiscal Information when I embarked on this project, as it was the first of its kind. The final version of the system had twin 40 MB ST-506 disks and a streaming tape drive, attached to an OMTI SASI controller (SASI is the ancestor of SCSI). There were three multiplexers ganged together to attach a total of 12 machines to the SCSI bus. Eleven were C-128Ds and the 12th machine was a C-64 acting as a printer driver. The C-64 was attached to three parallel printers via a custom interface built from three 6526 CIAs, the interface plugged into the cartridge slot, which was also shared by the Lt. Kernal host adapter.
The client ran on this system for some four years, at which time they had amassed enough capital to afford a UNIX system (which I also built and programmed for them). That was the end of the use of "toy" computers to run a multi-million dollar truck leasing business.
