I coded a Pascal compiler for transputer as a teen in 1993(nanochess.org) |
I coded a Pascal compiler for transputer as a teen in 1993(nanochess.org) |
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.
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.
[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....
1. As a teen, I had a lot more free time and could spend hours every night on fun stuff. School was easy and I didn't spend much time on homework
2. As a teen, I also did not have a day job programming too. My head is kinda tired when I come home, so unless it's a really interesting project I will probably just watch some TV
3. As a teen, I did not know about good code practices and could just throw something together and see if it worked. For some reason I now find it hard not to spend time on a good code structure, architecture and best practices. I am too "advanced" to just push out crappy code quickly
4. As an adult, I know more about the alternatives out there, so I'm thinking that there's no point in creating something when there are alternatives.
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 also wrote few games on Atari when I was even younger, but since I got pc in highschool I haven't been able to make any decent progress on (let alone finish writing) a single game on PC. Despite writing a lot of software professionally as an adult I never had the motivation, that I had as a child, to go beyond shallow, small experiments for my personal coding.
This is certainly appealing in comparison to microservice monstrosity I write in a team at work.
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.
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.
The Occam code was easy to understand and maintain - very complicated controller logic used in power train test sites. The Pascal code not so much anymore and finally floodgates opened with C. Go wasn't around then yet. I've learned Go and wrote the cygwin port after I've left that job. But the fast hardware made up for that mess.
If so - doubles the magnitude of this achievement.
I still have the program source, but the required Vgraph dependency has been lost to time, so I'm sadly unable to run it. I've searched online but never had much luck. If this lib sounds familiar to anyone, I would love to hear about it.
By the way, I also have OP's "Programming Boot Sector Games" book, which is an amazing book.
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.
Oh? Are you referring to something different from a database's precompiler?
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++.
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.
You would use exactly that, a byte buffer with variant records.
The difference is that Wirth languages place correctness and safety before performance, apparently a common discussion subject across many goverment agencies nowadays.
https://github.com/jeceljr/digitalCPUzoo/tree/main/drv16
It is meant as a helper processor in larger FPGA projects. These need less than 64KB of memory. drv16 is about the same size as the tiniest RISC-V (SERV, Glacial) without the huge performance penalties these have.
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.
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 :(
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.
This kind of code was pretty typical.
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.
Even in C you cannot just give a char * to an Windows function, unless you are stuck using ANSI version of the APIs.
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.