Comment by Semaphor
1 day ago
> My recollection is that most CP/M programs were configured via patching. At least that’s how I configured them. I remember my WordStar manual coming with details about which bytes to patch to do what. There was also a few dozen bytes of patch space set aside for you to write your own subroutines, in case you needed to add custom support for your printer.
Huh. That is interesting, it was before my time, and I never heard of this :D
Yes, it was definitely a thing. The patching code had to be in Z80/8080 machine code. I wrote higher performance keyboard and display routines for my copy of Wordstar using this feature.
Stuff like that is also cool (reminds me a bit of modding some games), patching machine code to improve performance of a compiled app? Very cool! (My dad might have done that, he has an old ZX81)
But I thought specifically patching something to configure it is such a weird concept that I never would have thought of.
The line between "configuration" and "modding" is pretty thin.
One could say that the difference is whether the developers intended the changes you're making to be possible or not, but what about programs with dedicated modding APIs?
6 replies →
The ZX81 didn't have so much software around for it - what there was mostly came on tape, or was typed in¹ on the ghastly membrane keyboard, and what there was was very limited in capability (the default RAM size was one kilobyte (yes, just 1024 bytes, though typically you'd buy a "ram pack" upgrade to 16k). Then it was very rapidly superseded by the more capable ZX Spectrum machine. So odds are your Dad didn't patch software on the ZX81 because it was usually already highly optimised to squeeze it into the tiny space available.
What was very common on those devices was using the "poke" command in BASIC to change a handful of values, but while it was possible to change code in this way it was much more common to be changing the value of variables - things corresponding to "number of lives left" and the like. Not all that different.
Fairly quickly, though, the games were entirely in machine code and used fancy loaders (still from tape mostly) so you didn't get access to BASIC. This created a market for devices that let you get at a monitor program - the "Multiface" series of addons². They had at least three generations of that device, but the company slightly weirdly evolved into a music production company³ after that, which is kind of cool.
Er, ok, I'll stop now while I still can...
Edit: PS - you should ask him about it. Tell him another former ZX81 owner says "Hi" and that my fingers still ache from that keyboard. Although I sneer a bit at its capabilities, it kicked off an interest in computing that's still paying the bills 40 something years later...
----
¹ https://spectrumcomputing.co.uk/entry/2000265/Book/Not_Only_...
² https://en.wikipedia.org/wiki/Multiface
³ https://en.wikipedia.org/wiki/Romantic_Robot
2 replies →
> > My recollection is that most CP/M programs were configured via patching.
> Huh. That is interesting, it was before my time, and I never heard of this :D
Yep, it was a thing, and for /some/ programs that were originally CP/M programs (i.e., WordStar 7.0 for DOS) it continued for a long time. The WordStar 7 documentation included patch locations to use (this time, IIRC, for DOS debug.exe) to change various behaviors of the program.
Some sort of still do. The stuff that suckless writes is generally configured by changing config.h and recompiling.
https://suckless.org/
Edit: oops just saw that this was already mentioned in another subthread on this page.
That is interesting, it was before my time, and I never heard of this
It was necessary because both RAM and disk space were so severely limited, and because almost every computer came with an assembler.
Many CP/M programs were expected to run in as little as 32K RAM, and 130K of slow-ass floppy disk. Or worse – From a cassette tape. If you had 64K of RAM and a 360K disk, you were something special.
Unlike today, most programs were optimized for the bottom of the market, not the top. You wanted your program to run on as many system as possible so you could sell more copies. You didn't just shrug your shoulders and tell people to upgrade their hardware. The failure was yours, not your customers'.
There simply wasn't room for any kind of external configuration file, or a program to generate that configuration file. Common functions could be accessed via a command-line parameter, but even that logic eats valuable bytes.
Today people complain about the MacBook Neo having just 8,000,000,000 bytes of RAM, saying you can't do anything in such a limited space.
Meanwhile, in 1978, people could write an entire rudimentary IDE in 2,048 bytes.