Do you also feel like you did projects in your teen years that you wouldn't pull off today?
I coded assembly (Z80) in a disk editor, having no assembler, just a handwritten list of opcodes.
I wrote a chat client app (in Delphi) HAVING NO INTERNET at home, I went to a cafe, recorded a dump with Wireshark, printed it on a dot matrix printer, and used a marker pen to highlight the bytes I understand the meaning of.
My favorite program as a teen came about because I had gotten a Sound Blaster (in my 8088 IBM PC), and you could order C/MS chips (they were actually a pair of Philips SAA1099 chips, originally used in the Create Music System aka Game Blaster).[0] Since it came with documentation on how to directly program the hardware registers, and I enjoyed coding music output (I still do enjoy that kind of thing), I ended up writing a program in C that could drive all 12 voices on the chips using the same notation as used by Advanced BASIC "PLAY" statements[1], but added a "V" command to let you select a voice. (BASIC "PLAY" command only supported 1 voice. Maybe 3 on the PCjr.?) It would keep track of how much time passed in each voice while compiling the information so that you could line everything up, and then would use that information to play everything at the right time when the music played back. I remember I had a big case or if/else section depending on the next character, so I must have worked out some sort of state machine without knowing what that was at the time. I took the conductor's score for music we were playing in band class and entered that into a file for the program to play the multi-voice version on my computer. :)
and here's a fun video showing the upgrade with a bit of music from The Secret of Monkey Island towards the end. Like the video creator said, I also like how it sounds similar to the GameBoy: https://www.youtube.com/watch?v=3ZtyP9tE3Ug
Yup. I wrote a TSR program to extend Deluxe Paint II on PC with animation features. Never heard about APIs, and simply copied data from the VGA memory, overlaying my own user interface on top of DP.
The thought of doing this with contemporary systems just seems ... wrong :)
I wrote lots of TSR extensions, I remember one that would allow you to switch between DOS programs.... it broke when the next version of DOS came out.
I was most fond of my image viewer program that worked only on my video card (a cirrus logic) but was 10x faster then others because it used some hw acceleration on the card (not remembering details right now).
It's basically impossible to replicate this level on todays extra-locked-down machines - the bar to entry and just tinker is so much higher.
It's all still available, arguably more accessible from a cost and documentation point of view - I'd argue that the bar to getting something is so much higher.
You can today start banging registers on GPUs, or write your own shader programs, there's well documented modern hardware (e.g. [0]) and completely open-source drivers just sitting there for reference. The issue is that there's so moving parts now that to get anything visible to actually happen it's not just wiring up a couple of registers, but thousands just to get it into a state you can even see the registers you want, then a thousand more.
Hah, I spent countless hours poking bits around in the Cirrus Logic card that I had.
I found an undocumented (to me, at least) mode that showed 16-bit images by alternating two 8-bit images. I put it in a demo to show at a demoparty, but the projector system did not have a compatible VGA card :(
Well back then we didn’t have all of that memory for those fancy abstraction layers. Sticking your finger in the framebuffer probably wasn’t the worst way to do that!
Kids these days have much less exposure to boredom. Anywhere you are, you can get lost in TikTok or other social media feeds in three seconds.
As a parent I struggle with this a lot, trying to teach some patience to my children who seem conditioned to fiddle with their phones whenever possible. And of course I'm often not much better myself.
That's very relatable. I don't really have any specific project I could mention that would make anyone's jaw drop. But if I look back at how little I knew compared to now, and the fact that I completely self-taught myself everything, I did some insane stuff for my age. I was so determined and could lose myself for weeks into a project just because I was so positively driven. I could do the same stuff now, much better too. But I wouldn't have the same drive and inspiration to come up with something and build it to perfection.
One thing that comes to mind is a bot I made that played bejeweled blitz. It worked by taking screenshots and calculated the optimal move, and moved the mouse to make those moves. I was 13 and wrote it in VB6.
I wrote a basic bootable 32-bit OS and an editor in x86 assembly :) all without internet and by poring through the Intel manuals and the "Undocumented..." series of books.
I noticed I missed it and so I went back to it a few years ago. I have old systems (mostly from the 70-90s; a few newer because my love for Sun Sparc & pre-Intel SGI) and newer ones like RISC-V boards and low-powered small devices to thinker with. None of this has any commercial value but it feels so much better than the LLM grifting / code slinging for profit. I wish I found a way to combine them, but I feel it's not possible.
One of my "some day" / "thought experiment" projects is to create a small RISC-V RV32EC processor that would only be able to access 64k of its memory space, but would fit on a 40-pin IC: 16 pins of address, 8 pins of data, some interrupt and timing pins, etc. Basically like a 6502 or 8080/Z80 with the RV ISA. I can already think of some "fun" issues like requiring four read/write cycles per load/store operation.
Brings up a strong nostalgia from me. Around that time computers were becoming mainstream and available where I was in the UK, and I grew up acquiring old cast-off computers and tinkering. For me there was an 'assembly language masterclass' book (I was a beginner and this was my first serious tech book and I had to sink or swim) that went into a lot of 32-bit programming for the 386 (which I never had) but got me far enough along. It was that and computer magazines which were really programming magazines, which were a thing and quite popular back then.
Remember fondly how transformative it was to move from Basic to a copy of Turbo Pascal 6 and it's asm keyword that I got passed on a floppy disk in the playground.
Ah that was the time when it was just obvious that you could entertain yourself on a computer by creating things, however small, instead of just consuming them.
By the time I got computer games, I was thinking about them as programs not games and I got my entertainment by getting into the modding scene.
I loved reading this write-up. It was a wonderful trip down memory lane. Writing a PASCAL compiler is very impressive. I only got as far as the assembler!
In 1989 I designed and built a board with 3 transputers on it as part of my (physics) degree project. The transputers were T212 I think, so only 16 bit and no floating point with 2k of local RAM. They ran at 20 Mhz and the all important chip to chip network ran at 10 Mhz. Ostensibly it was so I could do Ising spin simulations on it but actually all I wanted to do was calculate Mandelbrot sets having seen a demo of a box with 256 transputers in doing that.
My transputer box was connected to a BBC Micro and to program the transputer I wrote an assembler in BBC Basic. The transputer instruction set was quite funky - everything was variable length. Which meant when calculating the jump instructions, sometimes my assembler would take 7 passes to find the optimium encoding for everything.
The BBC Micro only had 32k of RAM which wasn't nearly enough RAM to hold the assembler, the symbol table and the code you were assembling. So the assembler would write each pass to disk! To floppy disk! It was very slow as you can imagine but I did end up writing both an Ising spin simulation and a Mandelbrot set plotter. The Ising spin simulator ran slightly faster than a FORTRAN version I wrote for the university mainframe which I was very pleased with.
I got to learn about parallel processing using message passing and managed to make my first concurrency bug where the program would work on 1, 2 but not 3 transputers! I didn't write programs for multi-processor machines again for more than 10 years.
The transputer seems so ahead of its time, even now 36 years later. I sometimes wonder what it would be like if we'd continued down that path. Maybe your laptop would have 10,000 processors in it each with a few MB of RAM and we'd be writing very different programs in languages where message passing was a first class construct.
> I sometimes wonder what it would be like if we'd continued down that path. Maybe your laptop would have 10,000 processors in it each with a few MB of RAM and we'd be writing very different programs in languages where message passing was a first class construct.
I have wondered that too. I think having more but simpler processors and that style of software would have given us much better security and reliability.
> I sometimes wonder what it would be like if we'd continued down that path. Maybe your laptop would have 10,000 processors in it each with a few MB of RAM and we'd be writing very different programs in languages where message passing was a first class construct.
It sounds a bit like the Erlang BEAM VM to be honest, the BEAM processes tend to be small and there are a lot of them in real-world applications, and message passing is a first class construct (along with some others like ETS which are “cheats” that offer other tradeoffs for specific cases)
When I was teen moving into adulthood, I couldn't understand why Pascal is being abandoned and people are moving into C and C++. I often think how would the software world look like if that did not happen. It's such a shame that we lost such a simple, yet productive language, in the commercial settings. And now we have Rust as the next winning choice, language even more complex than C++.
Don't forget that, at least in the pascal that was used in my university programming course, all data structures have a fixed size. If you want variable size, you need to allocate them on the heap and free them manually, so it is not clear that this is going to be that much easier than C or C++ in practice. Actually attending the lecture about this I was a bit shocked that it was necessary to free memory manually and I thought to myself 'isn't this going to lead to a lot of trouble'. Turns out my 19-year-old self was right about that.
Why would you say that Pascal was (is?) a simple and productive? I wrote some software in Turbo Pascal and Delphi at that time, and was usually envying the C++ freedom. All the headers had to be translated to Pascal first. Pointer arithmetic was kludgy. I really wonder how could I do more complicated things, like large byte buffer with variant structures, parsing in Pascal.
Whereas if K&R had adopted Pascal (and tweaked the language to support whatever limitations they ran into when making the OS) instead of inventing C to make Unix, your experience would have been flipped; should C++ have come along, it would be the one with the header translation costs etc?
Wirth went on to create Modula2 and Oberon and make operating systems in them. It is fun to imagine a world where that was the way chosen forward instead of C to C++.
I believe C is closer to what happens in the computer, than the Pascal is. I am not advocating for C as I dreadfully fear of this language (though I have experience in it, it always fills me with respect when I'm getting to close). What I'm saying is that for example, LPS String implementation in Pascal is Pascal-specific, not ubiquitous in systems, and handling PChar in Pascal gives a headache. Simple task: call a Windows function with your own string from Pascal. (Maybe my experience is too old and I don't know that this has been solved already, but back when I tried it, it was a nightmare)
FWIW that string bit has been solved since Delphi 2 introduced "huge strings", which are basically reference counted, copy-on-write null terminated strings. A variable of type "string" or "ansistring" (the former is an alias for the latter when huge strings are enabled, which are by default in Delphi 2 projects) is actually a pointer to the first character of the null terminated string, making it memory compatible with C calls (the "header" that contains reference count, etc is placed at a negative offset from the pointer).
With modern Delphi and Free Pascal (another object pascal dialect) you rarely have to worry about the differences between ansistrings and C strings.
(the name "ansistring" is kinda odd but blame Borland for that - though the odd name most likely helped avoid conflicts with existing Turbo Pascal and Delphi 1 code)
That said, i wouldn't call modern Pascal a simple language at all. Free Pascal for example has three different object oriented types that are all incompatible with each other and none cover all usage scenarios - and hidden "gotcha"s exist in the language ever since the early Delphi days like the implicit "Result" variable in functions treated as a "var" (passed by reference) parameter, meaning that a call like "Foo:=Bar" where "Foo" is a variable and "Bar" is a function and you'd expect "Bar" to be called and its result assigned to "Foo" actually has "Result" inside "Bar" be whatever "Foo" was because the statement is basically as if "Bar" had a single argument where "Foo" was passed by reference.
Headers are the huge achilles heel of the C-based languages. Pascals modules were MUCH better. Pascal always built code faster in my experience, because it wasn't parsing megabytes of headers just to compile a hello world program. This also probably makes a pascal compile much simpler to implement as it's not 2 languages layered together.
Macros in C are an utter disaster imo. If you want to get an AST for any piece of code you have to know what's defined so you must know exactly what the build system is going to do to the code i.e. the code isn't self-contained. If you use one build system to build for production and another in your IDE for development then you might get totally different results.
C,C++ have a lot of ways to do one thing and Pascal tends to have one. The more you have to work on other people's code the more attractive Pascals' "one way" seems.
what I mean is that once you want to access some API, the standard is C, so the headers you will get are in C. For example: windows.h. To do anything, either you have translated windows.pas, or you need to manually rewrite the function definitions. Another example: if you would like to access HongKong Exchange, you will receive a .so object and omni_api.h file, which is damn hard to understand, easier to use.
Pascal had a different calling convention so you can "just" write all your libraries in pascal.
As you say, calling out to other libraries would need a translation but ..... it's the same for python or many other languages. It would be a bump in the road but not a disaster.
I mostly meant the DOS era, when you accessed hardware directly, there were pretty much no libraries. Further on, if people did not start using C++, Pascal would have to evolve to allow writing the things that were previously done in assembly, and libraries would be done in that language as well. That did not happpen, so C++ won and writing Pascal code was even more complex because you had to brindge the C APIs.
What things that were previously done in assembly do you mean?
I remember Delphi nicely allowed including C++ files and assembly in the project too, so there's that. It is a very wordy language, but apart from the need to separate declarations and implementation, was pretty nice to use, and powerful.
Fantastic, well done! - I remember the Inmos Transputers (T800), and there was Occam, the curious language, from which I remember just two operators, ? and ! to read and write from the four(?) fast serial ports that connected one transputer with its neighbors.
Pascal was beautiful, clean, simple and fast, and computer science has never reached that height again, IMHO - look at how slow Python is, how unstructured many programs are, when python permitted nested functionsa and procedures (C/C++/Rust still cannot do that today). And the fast compilers, TurboPascal, TurboModula, and TurboC that made Borland famous and wealthy are in some sense also unrivalled: on machines 1000x slower than what I have now in my desk, you felt like you had the fastest PC money can buy.
In those days, unless you were very privileged, you had to learn things from a maybe 1 book, maybe a magazine (some matrix printed stapled pages in my province) and, in my case, without having a computer for the first year of learning basic & assembly. I just had a 2nd hand book + those magazines and some old folk telling me I should learn it. When we did get a computer (borrowed), I knew listings by heart which I typed in, changed and explored. It was somehow nicer than instant gratification we have now. I worked out assembly listings in HEX (I did not know what an assembler was or that it existed) on paper in class (school was of course boring af) and typed it in when the borrowed computer was back. Very nice times.
Mexico surely made it harder, but his father was a bigger advantage than any school. And school fanciness does not reliably correlate with the realness of its instructors.
I coded assembly (Z80) in a disk editor, having no assembler, just a handwritten list of opcodes.
I wrote a chat client app (in Delphi) HAVING NO INTERNET at home, I went to a cafe, recorded a dump with Wireshark, printed it on a dot matrix printer, and used a marker pen to highlight the bytes I understand the meaning of.
I miss it so much.
[0] https://en.wikipedia.org/wiki/Philips_SAA1099
and here's a fun video showing the upgrade with a bit of music from The Secret of Monkey Island towards the end. Like the video creator said, I also like how it sounds similar to the GameBoy: https://www.youtube.com/watch?v=3ZtyP9tE3Ug
[1] QBASIC equivalent documentation https://www.qbasic.net/en/reference/qb11/Statement/PLAY-006....
The thought of doing this with contemporary systems just seems ... wrong :)
I was most fond of my image viewer program that worked only on my video card (a cirrus logic) but was 10x faster then others because it used some hw acceleration on the card (not remembering details right now).
It's basically impossible to replicate this level on todays extra-locked-down machines - the bar to entry and just tinker is so much higher.
You can today start banging registers on GPUs, or write your own shader programs, there's well documented modern hardware (e.g. [0]) and completely open-source drivers just sitting there for reference. The issue is that there's so moving parts now that to get anything visible to actually happen it's not just wiring up a couple of registers, but thousands just to get it into a state you can even see the registers you want, then a thousand more.
[0] https://gpuopen.com/amd-gpu-architecture-programming-documen...
I found an undocumented (to me, at least) mode that showed 16-bit images by alternating two 8-bit images. I put it in a demo to show at a demoparty, but the projector system did not have a compatible VGA card :(
As a parent I struggle with this a lot, trying to teach some patience to my children who seem conditioned to fiddle with their phones whenever possible. And of course I'm often not much better myself.
One thing that comes to mind is a bot I made that played bejeweled blitz. It worked by taking screenshots and calculated the optimal move, and moved the mouse to make those moves. I was 13 and wrote it in VB6.
Brings up a strong nostalgia from me. Around that time computers were becoming mainstream and available where I was in the UK, and I grew up acquiring old cast-off computers and tinkering. For me there was an 'assembly language masterclass' book (I was a beginner and this was my first serious tech book and I had to sink or swim) that went into a lot of 32-bit programming for the 386 (which I never had) but got me far enough along. It was that and computer magazines which were really programming magazines, which were a thing and quite popular back then.
Remember fondly how transformative it was to move from Basic to a copy of Turbo Pascal 6 and it's asm keyword that I got passed on a floppy disk in the playground.
Ah that was the time when it was just obvious that you could entertain yourself on a computer by creating things, however small, instead of just consuming them.
By the time I got computer games, I was thinking about them as programs not games and I got my entertainment by getting into the modding scene.
In 1989 I designed and built a board with 3 transputers on it as part of my (physics) degree project. The transputers were T212 I think, so only 16 bit and no floating point with 2k of local RAM. They ran at 20 Mhz and the all important chip to chip network ran at 10 Mhz. Ostensibly it was so I could do Ising spin simulations on it but actually all I wanted to do was calculate Mandelbrot sets having seen a demo of a box with 256 transputers in doing that.
My transputer box was connected to a BBC Micro and to program the transputer I wrote an assembler in BBC Basic. The transputer instruction set was quite funky - everything was variable length. Which meant when calculating the jump instructions, sometimes my assembler would take 7 passes to find the optimium encoding for everything.
The BBC Micro only had 32k of RAM which wasn't nearly enough RAM to hold the assembler, the symbol table and the code you were assembling. So the assembler would write each pass to disk! To floppy disk! It was very slow as you can imagine but I did end up writing both an Ising spin simulation and a Mandelbrot set plotter. The Ising spin simulator ran slightly faster than a FORTRAN version I wrote for the university mainframe which I was very pleased with.
I got to learn about parallel processing using message passing and managed to make my first concurrency bug where the program would work on 1, 2 but not 3 transputers! I didn't write programs for multi-processor machines again for more than 10 years.
The transputer seems so ahead of its time, even now 36 years later. I sometimes wonder what it would be like if we'd continued down that path. Maybe your laptop would have 10,000 processors in it each with a few MB of RAM and we'd be writing very different programs in languages where message passing was a first class construct.
I have wondered that too. I think having more but simpler processors and that style of software would have given us much better security and reliability.
It sounds a bit like the Erlang BEAM VM to be honest, the BEAM processes tend to be small and there are a lot of them in real-world applications, and message passing is a first class construct (along with some others like ETS which are “cheats” that offer other tradeoffs for specific cases)
Wirth went on to create Modula2 and Oberon and make operating systems in them. It is fun to imagine a world where that was the way chosen forward instead of C to C++.
With modern Delphi and Free Pascal (another object pascal dialect) you rarely have to worry about the differences between ansistrings and C strings.
(the name "ansistring" is kinda odd but blame Borland for that - though the odd name most likely helped avoid conflicts with existing Turbo Pascal and Delphi 1 code)
That said, i wouldn't call modern Pascal a simple language at all. Free Pascal for example has three different object oriented types that are all incompatible with each other and none cover all usage scenarios - and hidden "gotcha"s exist in the language ever since the early Delphi days like the implicit "Result" variable in functions treated as a "var" (passed by reference) parameter, meaning that a call like "Foo:=Bar" where "Foo" is a variable and "Bar" is a function and you'd expect "Bar" to be called and its result assigned to "Foo" actually has "Result" inside "Bar" be whatever "Foo" was because the statement is basically as if "Bar" had a single argument where "Foo" was passed by reference.
Macros in C are an utter disaster imo. If you want to get an AST for any piece of code you have to know what's defined so you must know exactly what the build system is going to do to the code i.e. the code isn't self-contained. If you use one build system to build for production and another in your IDE for development then you might get totally different results.
C,C++ have a lot of ways to do one thing and Pascal tends to have one. The more you have to work on other people's code the more attractive Pascals' "one way" seems.
That's why I said about freedom.
As you say, calling out to other libraries would need a translation but ..... it's the same for python or many other languages. It would be a bump in the road but not a disaster.
I remember Delphi nicely allowed including C++ files and assembly in the project too, so there's that. It is a very wordy language, but apart from the need to separate declarations and implementation, was pretty nice to use, and powerful.
Pascal was beautiful, clean, simple and fast, and computer science has never reached that height again, IMHO - look at how slow Python is, how unstructured many programs are, when python permitted nested functionsa and procedures (C/C++/Rust still cannot do that today). And the fast compilers, TurboPascal, TurboModula, and TurboC that made Borland famous and wealthy are in some sense also unrivalled: on machines 1000x slower than what I have now in my desk, you felt like you had the fastest PC money can buy.
https://en.wikipedia.org/wiki/Transputer
If so - doubles the magnitude of this achievement.
What's needed to actually implement FILE, are there any transputer emulators to run this on?
Also thanks for the Transputer deep dive, TIL!
Love the source code you posted on Github with its Spanish comments.