On Wed, Apr 13, 2011 at 07:57:24PM +0200, Dave Long wrote: > >Using modern tools as cognitive aids (so I didn’t have to > >hand-assemble) and to diagnose problems allowed me to do this in a few > >hours. It might have taken a few days in Sean’s scenario. > > Being the dinosaur that I am[0], I can partially explain why your > approach was not too far off. Early PC's might have appeared to lack > [1] development tools, but circa 1982 I had access to a microcomputer > project (eventually killed by the PC's dominance), and although self- > hosted tools did appear by the end of development, all of the initial > work was done in a timeshared unix environment: sources were edited > and cross-compiled on the mini(s) and the resulting executables > transferred to the micros. No IDE's or mice, but they had full > screen editors, makefiles, and a gcc-like toolchain. Set your xterm > to 24x80 green-on-black[2] and the cross-compiling you were doing > wouldn't be far off at all from industry practice 30 years ago. > > [1] this is not strictly true; it appears that DEBUG.COM was already > present in MS-DOS 1.0, and already incorporated the symbolic > assembler by 2.0 > http://www.armory.com/~rstevew/Public/Tutor/Debug/debug-manual.html > cf http://en.literateprograms.org/Hello_World_(IBM_PC_bootstrap)
Ha! That's awesome. You don't look that old. This is the way Intergalactic Digital Research and Micro-Soft started out, too, but I think most other microcomputer software shops used self-hosted tools at the time, didn't they? Even Apple, I think? The self-hosted tools, however, were much better than COPY CON. I imagine Tim Paterson wrote the first version of DEBUG.COM using a cross-assembler hosted on a CP/M machine, which was presumably written using an 8080 assembler, and if you had to bootstrap an 8080 assembler on CP/M, you could certainly have used [DDT.COM][0], which included assembly and disassembly facilities similar to DEBUG's. (And DDT.COM was written by, I guess, Gary Kildall on some DEC machine.) What did you use at the time to copy executables across? MODEM7? [0]: http://www.iso.port.ac.uk/~mike/interests/chistory/documents/cpm-22-manual/ch4.html "Section 4: CP/M Dynamic Debugging Tool" > I haven't tried this myself yet, as some combination of Q, Freedos, > or laptop prevents me from entering ALT-numerics in the dos box. If it's the laptop, have you considered getting a US$5 USB keyboard? They're usually better than laptop keyboards, even if you aren't attempting feats of keyboard bootstrapping. > However, I'd think two other tricks might come in handy for a pure > bootstrap: > - having command.com means you have batch files. granted, .bats have > impoverished control structure, but it might save on some machine > code in the bootstrap > - copy also concatenates files; one could thus minimize transcription > errors by using COPY CON for relatively short sequences, then splicing > [3] them together to form the final executable. Those are good tricks. Once you are done with the initial bootstrapping, batch files will start to be painfully slow, but they could save quite a bit. I forget whether you could redirect their output in MS-DOS, but if that's possible, perhaps that's another way to concatenate files. > [0] I have, once in my life, programmed (an application, not an > exercise) using front panel switches and the reference manual That sounds like a lot of work. What was the application? > [3] choose naturally concatenative machine code sequences, and it > might even be about as easy as programming via DEBUG; after all, they > both lack decent symbol table/dictionary support I think that concatenative machine code sequences with a runtime stack --- i.e. a Forth compiler --- are probably a crucial technique for the next few stages of the bootstrap; they save you a lot of complexity in your compiler at the cost of perhaps a factor of 2 or 4 in performance. (On an 8-bit machine it would probably be a bigger factor.) Kragen -- To unsubscribe: http://lists.canonical.org/mailman/listinfo/kragen-discuss
