The MSX was the sole reason why I am on IT today.<p>Picture a 8 year old boy unwrapping his first computer back in 1988. It would boot up right into MSX Basic (until later on when I added a floppy drive). One could play around with commands and have stuff happen. "screen 2" would take you to a graphics mode, where amazed me would get simple programs drawing stuff on the screen. I didn't know that I was 'programming' anything, only that I would type stuff and run and things would happen. I didn't understand what the 'for' instruction did, among others.<p>My first 'assignment' came from my father. He repaired TVs as a hobby(mostly, he did fix a few for money). One thing he couldn't do was to adjust the alignment on said TVs. There were pattern generator devices which cost quite a lot of money, money we didn't have (even the computer was second-hand).<p>So young me had set out to draw a greed. Easy - screen 2, then a bunch of 'line' instructions, one per grid line. Lots and lots of typing. Since the computer connected to TVs already (through a RF box), all my father needed to do was load the program (from a K7 tape) and hook up to TVs. That was great.<p>Revisiting the program a couple of months later (he wanted the grid spacing changed) and dreading to do that work, I was flipping over the manuals, when it suddently clicked: I could use a variable for the 'line' instructions, and change with this 'for' instruction, which so far had eluded me. A few 'pages' worth of code got translated into 4 lines.<p>I was hooked. Never stopped coding since then.<p>Another thing I tried to do. So PCs came around, with nice graphics (nicer than what I had, and it took a while but then they got nicer graphics than even MSX 2.0 or the Turbo-R). Then Windows 3.1 came around.<p>I tried to replicate Windows 3.1 based on magazine printouts - PCs were still hard to come by, PCs with enough specs to run 3.1 even harder still. At that time, I had switched from Basic to Turbo Pascal (3.0). The MSX port was lacking a few units. Most notably, the * graphics * unit (massive omission if you ask me).<p>So I set out to implement the drawing functions myself. Only I wasn't at the university yet, and didn't know how to draw lines (or god forbid, circles). A quick google search today will give you Bresenham's. Back then, information like that was hard to come by.<p>So I did some thinking. Even though I was booting up to DOS at this time – which meant that all pages were mapped to RAM – MSX Basic was still there in ROM. How did it do it? The functions must be there somewhere.<p>I got hold of the "MSX Red Book". That book described all ROM functions, even undocumented ones, with the memory address, input and output registers. Jackpot! Only problem was, as previously mentioned, all memory banks were switched to RAM. I would have to flip two banks to ROM, run the functions, and then switch back.<p>Then I found a function that did just that, CLPRIM I think it was called. In short order, I had ASM wrappers for most basic drawing functions, and I could draw my "windows".<p>Two problems remained: text, and the "mouse" (I had no mouse, I was faking with cursor keys).<p>Drawing text in graphical mode was far beyond my capabilities – specially since I wanted to squeeze 64 columns (ordinarily that computer would do 40 per line, in text mode, and the character patterns were designed for that). Then I remembered that I had WordStar. WordStar managed to get 64 columns. How?<p>After some digging I found that it would load a program into RAM before running the editor (PC-based DOS users would call these TSR's). So I 'stole' it. Before running my 'windows', I would load it too. Yay windows with titles! (Lots of work done afterward to ensure they would horizontally match and not overflow).<p>Good, now all that's left was the mouse. So I wrote a 'TSR' of my own, which would draw and move a hardware "sprite". The only thing the turbo pascal program would have to listen would be for the space bar, and then retrieve the 'mouse' position from a pre-arranged memory location. The asssembly code took a while to write - it was easy to lock the machine up - no memory protection or multi-processes meant that these were "hard" lock ups, which required a reset. Still, I eventually got it done.<p>Last major problem: both the wordstar TSR and mine required some of the same hooks. hooks were pre-determined memory locations. A 'call' – CD 21 – instruction would be issued to these locations whenever the event happened. Usually, they would contain 'C9' (RET). However, there was just enough space for, lets say, a (JMP) instruction (C3) plus memory address. This way, you could run your own code and then (RET) when done. So we both used the same hooks.<p>The way I got around this was: load the Wordstar one first, then load mine. If I found that there was anything there other than C9, that meant that the hook was in use. So I would save it, put my own in place. When finished, I would transfer control to the code that I had saved before.<p>Finally I had a working system. A few tweaks here and there – I had to save the current state of the graphics processor (VDP) ports whenever my 'mouse' program activated, otherwise it would corrupt the screen. But then it worked flawlessly, if a bit slow (ROM was much slower to access, something I did not know at the time).<p>12 year old me used this fancy and overengineered system... mostly as a menu to run games, icons and all. Very little 'serious' work was done.<p>It's too bad that there was no version control and almost none of the code survived (I may still have some of the 'TSR' code printed out, an earlier version). It would have made for a nice blog post.<p>I do miss some of that. There were very few abstraction layers between your program and the system, so you really understood what you were doing.<p>The downside is that I now have a few neurons which are forever locked to store now useless MSX trivia.<p>poke &HF346,1<p>call system