Hacker News Reader

Comment by Semaphor | Hacker News Reader

> 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

View on HN

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.

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?

At the time (early to mid 1980s) I think we would say "patching". The Wordstar devs certainly did mean you to do this - the memory locations available were fully documented, and I seem to remember they supplied a small patch utility to incorporate your code into the Wordstar executable.

I remember the words "peeking" and "poking", but this may have been specific to basic.

Yes, most Basics had peek and poke commands with which you could read and write specific memory locations. For example - parentheses may or may net be needed, depending on the Basic implementation:

    X = PEEK( 123 )

would read the byte at memory location 123 and store its value in X. Then

   POKE( 123, 42 )

would change the byte at 123 to be 42.

But these didn't normally have so much to do with patching executables to add/change functionality.

That unlocked a memory of me seeing my computer lab teacher after class in 5th or 6th grade to ask her about the applications of PEEK and POKE. I’d picked up a copy of the GW-BASIC manual from a used bookstore. She’d never heard of those commands. Ended up promptly locking up one of the school computers by poking random numbers to random addresses.

I remember looking into BASIC sources to figure out how they did some things I had no idea how to do with BASIC... and finding POKE statements with weird numbers, it was looking a bit like magic... (I was probably 10 or so, though)

Some time before that it would have been "painting", when you used conductive paint to patch the microcode on your CCROS (Card Capacitor Read-Only Store) machine.

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

Cool, yeah, he had the 16 kb extension and his own software written on a cassette/tape.

He says hi back, for him it was purely a work machine (PhD in Chemistry, never did anything with computers as in CompSci), he doesn’t remember too much from back then but he said he loved the architecture of it.

He's likely a good bit older than me then - I was about 9 when we got ours. I think "fancy calculator" was probably one of the best ways to use them given their limitations.

Their success was largely down to their very low price point (clever cost-shaving engineering) at a time when there was a huge untapped public interest in computers.

> > 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.

Not only that, the operating itself was configured by a process known as "sysgen". You relink the entire operating system with options set the way you wanted. It was generally a miserable slow process.

At least on PDP-11 that's how it went for something like RSX-11. I believe same is true for early IBM mainframe operating systems like DOS 360- I think all programs had to be relinked because one option you had was to move things around in memory, and ancillary programs had to know the memory map.

Even later: I wrote a device driver for Xenix: you got a link kit for the OS, you relinked it with your custom driver object file included.

On CP/M you patched the running image (perhaps with DDT), then use the CP/M SYSGEN command to install it on a disk.

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.

Reply on news.ycombinator.com