I don't publish anymore in X, so I don't mind it. And by the number of points, I can see it is pretty obvious no one cares anymore. The owner is giving a great lesson on how to destroy a social network, while alienating the remaining users.
The practical advantage is that the 74LS chips are available in several corner stores at 25 or 35 cents each one, and I preferred the logic to be the same family.
You cannot choose the source, these come mixed from ST, TI, and other manufacturers. I preferred the laser-engraved ones instead of the white ink ones just to have an uniform look.
The crystal oscillator needs something faster so it requires 74F04, and the link communication buffer requires 74F244 or 74AS244. These are more expensive, the 74F are 2 dollars each chip, and the 74AS are 4 dollars each chip.
I didn't know it was "oddball". I had brochures, official Inmos datasheets, and reference books about it, along magazines articles citing it as the "faster processor in the world". I believed it was pretty popular until Internet put me down in Earth, and I discovered the transputer was pretty much dead since 1994.
I was already proficient in Z80 and 16-bit x86, so learning another instruction set was pretty welcome. The fun came from developing things for the first time and discovering how to actually do things, a 32-bit operating system, a K&R C compiler, and the assorted utilities.
Enforcing limitations was inspired by the IOCCC, and later by my boot sector programs. The type of things you do after work, just to test yourself and have some fun.
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.
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.
I've included a transputer emulator in the git for using the Pascal compiler. The FILE functions are missing probably because I couldn't figure a method to ask for host services and interleave data in the input/output channel.
The simplest emulator in the world would be like this one:
unsigned char memory[65536];
int reg[8];
int main(void)
{
int pc = 0;
/* In this point you read something into memory */
while (1) {
instruction = memory[pc];
if (instruction == 0x76) break; /* HLT */
pc = (pc + 1) & 0xffff;
if ((instruction & 0xc0) == 0x40) /* Handle MOV r,r (opcodes 0x40-0x7f) */
reg[(instruction >> 3) & 7] = reg[instruction & 7];
}
return 0;
}
What it does? It simply reads each instruction from memory (PC is the Program Counter), and increments PC continuously limiting it to 16-bit.
It does a comparison for each possible instruction, for this example I only handled the most basic one of 8080 (MOV r,r) and HLT, but this is already 64 cases of the 256 possible!
Then I added iteratively chunks of opcodes to emulate and used language C macros to reduce the code size. For example, there is #define d(e) to join two 8-bit registers into a 16-bit value, and #define Q to read the accumulator.
In the end, to stay inside the size limit of the IOCCC, I removed the tree of 'if' statements and replaced it with a tree of trinary operators ?: (a way of doing 'if' inside an expression) and this is what the macros C and S does.
Automatic generation of code for Z80 is kind of hard because some operations are forced to use a few registers.
For example, ADD only works with A or HL (and IX or IY), and the code generator requires register shuffling or using the stack for saving temporary values.
My current approach is building a node tree for expressions, generating code by detecting common patterns, and if there isn't a pattern it goes the complicated but simple way. For example, for add:
right expr. / push hl / left expr. / pop de / add hl,de