I started programming in 1977/78 in CBM/PET Basic on a Commodore PET 2001 with cassette tape drive and 32k upgrade. I loved those days. My parents didn't understand what the deal was with the costly computer I saved up for at age 13, and why I thought it was so important. It also required many late hours on my part on school nights. I moved on to assembler and C and many other languages over the years. I had a renaissance for the low-level and small thanks to you. Oscar, I worked through your, "Programming Boot Sector Games" with much joy. Your books and writing have brought back some of that nostalgia and fun for me, so thank you for that, and keep it going! It's also resharpened some dead areas and gaps I have sustained from the multiple abstraction layers of today's modern software world.
Thanks for sharing! Mine was a pretty similar experience in the eighties, because you could learn so much just by reading books and doing experiments. Recently, I got three Commodore 64 (the descendants of the PET) and I just want to type some BASIC games and start learning. I'm very humbled by the experience of writing "Programming Boot Sector Games", because like you, many people have told me about having a nice experience reading and learning with it, and I'm glad the effort was worth it.
This is so wonderful. I hope I can get your Transputer emulator running to try it. I wish I'd spent my teen years doing something so awesome.
One minor grammar thing: "didn't worked" should be "didn't work", because "do" in English as an auxiliary verb always takes the root form of the verb, just as "will", "may", and "can" do. Similarly "don't exists" should be "doesn't exist".
I'm a native English speaker and the article reads very naturally. I've been learning Spanish over the last two plus years, and I'm jealous of how regular and consistent Spanish is compared to English.
The orthography, maybe? And there are no phrasal verbs, which is nice. But you have gender, you have plenty of irregular verbs, you have a significantly more complex inflection system even for regular verbs (including the subjunctive mood and the conditional tense in the indicative), and its allophonic phonotactics are tricky (though English has a fair bit of mess here too).
Zapotec sounds like it would be a lot more difficult, but I think really all natural languages are equally difficult, because if it takes children more than about five years to master them, they get simplified, and if it takes children less than about five years to master them, they accrete irregularities, idioms, and metaphorical sense extensions to compress the representation of low-entropy concepts.
I realized just this month I miss the days of being able to crash my computer completely with a typo. Such a weird feeling. I was debugging some pcie passthrough issues this week and the feeling that the computer could go dark whenever I started the VM was fantastic. It took sooooo much time, and I loved it. Of course, I hated it at the same time. But I got the same feeling as when I was writing ring0 code at 14.
One of my favorite pastimes on my TRS-80 and TRS-80 color computer was to type in a simple basic program that would poke random values into random memory addresses and see how long it would take to crash or do something else.
Sometimes the value would wind up in the basic program itself and it would stop. Mostly it just locked up and I had to hit the power button and try again.
Ha! I did that with the first machine I worked with. A TRS-80 Model III.
Not only was finding interesting memory locations fun, it generated interesting ideas for program features.
I found the address for the line length constant 64, used by the screen scrolling loop. I think the screen was 16 lines x 64 characters. By setting the scroll width to less than 64 I could protect the right side of the screen from scrolling.
So my first games had an area on the right for a non-scrolling title, author attribution, and game state info. It seemed to be a unique feature - I didn't come across any other programs that did that.
Some of my first programs were text adventures. Looking back, I should have put a short room description and usable object list on the right, updating in response to actions. That would have been a significant improvement over having to type "look" over and over, as was typical for those games.
Crazy times: 64x16x1 byte = a 1,024 bytes screen. Total memory was only 16k -> Today that is just a 64x64 rgba (4 x 8-bit channel) icon. But we always found a way to create our programs. I had a 4k RAM TRS-80 handheld and was able to create a tiny version of Zork on that, with a few starting and iconic rooms.
Get yourself a retro computer and you can appreciate all that joy with renewed vigour! :)
I regularly return to my old 80's 8-bit machine (Oric Atmos, FOREVER!) just so that I can remind myself how great we've got it in this day and age of near-infinite memory, the network-is-the-computer, and endless pixels for days. Nothing sharpens the mind stronger than a misplaced RTS or a failure to budget for room on the stack ..
Submitted title was "Released my full transputer OS, K&R C compiler and utilities (1996)". We've changed that to the title on the page.
(Actually we sometimes make exceptions when the author is the submitter, and I'd be happy to do that here, but the original title is pretty damn cool and will probably attract more readers!)
Thank you. A ton of work was done, in typing and debugging as well as creating. While some of us were cutting out teeth on nix clones... You made an OS. This is amazing* worthy of praise from Michael Swaine.
This is amazing. Nice job, I'm going to have to check this out sometime.
Back around 1985 I was 15 years old and very interested in transputer processors, so much that I called up SGS Thompson, as I wanted to get the datasheets for the chip. The guy at the company was so surprised to be getting a call from a 15 year old. He didn't send me the technical info I was seeking but he did send me some brochures. That's as close as I got to a transputer :(
I daydreamed about transputers and how they could be the future of computing, while I was hacking way on assembly language on my Commodore 64. I'd draw all kinds of network topologies between transputer chips in my high school english class. I had dreams of a system where adding more computing power meant just adding some more transputer chips. In my ideas, connecting a printer would also add more computing power, because the printer would also have a transputer chip in it to control print functions, but when it wasn't printing the rest of "the system" could use the CPU. Of course none of that came to pass, but it was great to daydream about the possibilities.
CD-ROMs and only 128k of RAM? Sorry, that doesn't pass the smell test. Once CD-ROMs were available, 2-digit megabytes of RAM were standard (and affordable) for home PCs.
It is something you can download and test, and it includes the source code for the emulator, the operating system, the C compiler, and everything else.
Just provide the emulator with an ISO CD image, and once it boots up, type DIR D: this single operation requires just about 28 kb of transputer RAM memory for the operating system, the command-line processor, and the buffers.
There's a file browser embedded in the text editor, so you can navigate using the arrows keys and choosing text files to read.
In fact, we need very little info to read CD-ROM directories. A directory search only requires a 2 kb buffer and some variables to keep track, read until you find the first part of the path, read that block, and repeat recursively until you find the desired file.
Reading a file from the CD-ROM can also be done just keeping a 2 kb. buffer and some position variables. My transputer operating system is inefficient in this because it reads the CD-ROM discs in terms of 512-byte sectors, cached by the host system.
When something doesn't match your expectations you (and others reading along) can often learn a lot more if you start with the assumption you had missing information rather than the assumption it's just incorrect. Even in cases where the story really does have an error by asking about it instead of asserting it you are more likely to hear something additional you didn't know before.
An Apple IIc with an Apple II SCSI interface card will happily utilise the 1989 AppleCD SC. Apple IIgs maxed out at 8mb RAM or so; with only 128kb out of the box for the IIc for example.
CD-ROMs were outselling all other audio formats in the United States by 1991 for context.
The standard home PC in rural Mexico at the time was a mechanical typewriter—if you were lucky. Oscar Toledo E. designed and built one from electronic components, such as the Zilog Z280 CPU mentioned in the article. As I understand it, he and his son Oscar Toledo G. wrote the operating system for it in assembly.
CD-ROM block sizes were 2048 bytes (2k), so its not entirely unreasonable to design what we now consider low-memory devices around the technology, nor is it a requirement that huge-memory systems be tied to CD-ROM drives...
CD-ROMs were available long before the mid-90s and even 8086-class machines could be equipped with them. They were just very expensive, and there wasn't a consumer market for them until the "multimedia" craze hit which required a 386 or 486 with at least 4 MiB of RAM (8 or more was better). But public libraries, for instance, had InfoTrac machines as early as the late 80s, which were XT- or AT-class machines that pulled magazine data off a CD-ROM catalog.
The Spectrum did not have 128kB until near the end of its life. It started out with a choice of 16kB or 48kB and that was all you got until 1986.
It also didn't have a joystick port. Nor did it have floppy disks (although 3rd party interfaces existed). Amstrad added joystick ports when it bought the product line and brand from Sinclair Research, soon after Sinclair launched the Spectrum 128, based on a Spanish model.
One minor grammar thing: "didn't worked" should be "didn't work", because "do" in English as an auxiliary verb always takes the root form of the verb, just as "will", "may", and "can" do. Similarly "don't exists" should be "doesn't exist".
Zapotec sounds like it would be a lot more difficult, but I think really all natural languages are equally difficult, because if it takes children more than about five years to master them, they get simplified, and if it takes children less than about five years to master them, they accrete irregularities, idioms, and metaphorical sense extensions to compress the representation of low-entropy concepts.
This text makes me relive it!
Sometimes the value would wind up in the basic program itself and it would stop. Mostly it just locked up and I had to hit the power button and try again.
Not only was finding interesting memory locations fun, it generated interesting ideas for program features.
I found the address for the line length constant 64, used by the screen scrolling loop. I think the screen was 16 lines x 64 characters. By setting the scroll width to less than 64 I could protect the right side of the screen from scrolling.
So my first games had an area on the right for a non-scrolling title, author attribution, and game state info. It seemed to be a unique feature - I didn't come across any other programs that did that.
Some of my first programs were text adventures. Looking back, I should have put a short room description and usable object list on the right, updating in response to actions. That would have been a significant improvement over having to type "look" over and over, as was typical for those games.
Crazy times: 64x16x1 byte = a 1,024 bytes screen. Total memory was only 16k -> Today that is just a 64x64 rgba (4 x 8-bit channel) icon. But we always found a way to create our programs. I had a 4k RAM TRS-80 handheld and was able to create a tiny version of Zork on that, with a few starting and iconic rooms.
I regularly return to my old 80's 8-bit machine (Oric Atmos, FOREVER!) just so that I can remind myself how great we've got it in this day and age of near-infinite memory, the network-is-the-computer, and endless pixels for days. Nothing sharpens the mind stronger than a misplaced RTS or a failure to budget for room on the stack ..
If not, somebody definitely should.
(Actually we sometimes make exceptions when the author is the submitter, and I'd be happy to do that here, but the original title is pretty damn cool and will probably attract more readers!)
Back around 1985 I was 15 years old and very interested in transputer processors, so much that I called up SGS Thompson, as I wanted to get the datasheets for the chip. The guy at the company was so surprised to be getting a call from a 15 year old. He didn't send me the technical info I was seeking but he did send me some brochures. That's as close as I got to a transputer :(
I daydreamed about transputers and how they could be the future of computing, while I was hacking way on assembly language on my Commodore 64. I'd draw all kinds of network topologies between transputer chips in my high school english class. I had dreams of a system where adding more computing power meant just adding some more transputer chips. In my ideas, connecting a printer would also add more computing power, because the printer would also have a transputer chip in it to control print functions, but when it wasn't printing the rest of "the system" could use the CPU. Of course none of that came to pass, but it was great to daydream about the possibilities.
It were great times. Like aviation in 192x-193x.
> if you are using macOS you'll be able to edit easily the files
I find it charming though, to be honest :)
Just provide the emulator with an ISO CD image, and once it boots up, type DIR D: this single operation requires just about 28 kb of transputer RAM memory for the operating system, the command-line processor, and the buffers.
There's a file browser embedded in the text editor, so you can navigate using the arrows keys and choosing text files to read.
In fact, we need very little info to read CD-ROM directories. A directory search only requires a 2 kb buffer and some variables to keep track, read until you find the first part of the path, read that block, and repeat recursively until you find the desired file.
Reading a file from the CD-ROM can also be done just keeping a 2 kb. buffer and some position variables. My transputer operating system is inefficient in this because it reads the CD-ROM discs in terms of 512-byte sectors, cached by the host system.
Too bad the UK gov were so shortsighted, or that Atari, instead of making the ATW (https://en.wikipedia.org/wiki/Atari_Transputer_Workstation)
should have simply used a T212 in the ST blitter socket as a coprocessor. That way people could have slowly gotten familiar with the arch :|
People are building new hardware to run transputers though: https://forums.atariage.com/topic/369254-pre-annoucement-atw... so maybe this amazing code can be resurrected on real hardware!
Edit: Found it. This is the paper on 3d parallel transforms: https://repository.arizona.edu/bitstream/handle/10150/611934...
Later transputers also had DSP instructions built-in.
The target is the embedded space now, though.
https://pubmed.ncbi.nlm.nih.gov/18255845/
CD-ROMs were outselling all other audio formats in the United States by 1991 for context.
128k is enough for a lot of things.
A quick google didn’t tell me anything so maybe I imagined it.
The Spectrum did not have 128kB until near the end of its life. It started out with a choice of 16kB or 48kB and that was all you got until 1986.
It also didn't have a joystick port. Nor did it have floppy disks (although 3rd party interfaces existed). Amstrad added joystick ports when it bought the product line and brand from Sinclair Research, soon after Sinclair launched the Spectrum 128, based on a Spanish model.
https://www.computinghistory.org.uk/det/57231/Amstrad-Buys-S...
I may still have imagined it.
But it's not really a CDROM.
Wow! I defer.
A CD not a CD-ROM, but you're right.