Hm ... you using Python to bootstrap. Much harder would be to assume no languages whatsoever and go from there (some musings I've done on this type of project: http://boston.conman.org/2009/11/05.1)
Did 1982 MS-DOS have I/O redirection? You're right that that would help quite a bit.
I think one of my first programs in that environment would be some kind of editor. Maybe a hex or octal editor rather than a text editor, but an editor nonetheless. Typing programs more than a few dozen bytes with no ability to see or fix typos gets old fast.
I don't know how much harder the job really gets if you bootstrap directly from machine code instead of Python. I don't think it's that much.
I remember typing in simple assembly listings for utilities to use in batch files from books & magazines. (generally saved as headerless .com files) Unfortunately, I didn't try hard enough to find out how they worked at the time, which probably delayed my programming abilities by a couple of years.
One day Nirva Toomish entered the ACM Programming Competition. But the languages allowed were Pascal and something else, neither of which he knew. But the machine had DEBUG.COM on it, so he wrote his programs in DEBUG.COM's assembler, and solved several (all?) of the problems.
The problem came when the proctors asked to see the source code. He used DEBUG.COM to disassemble his programs, but they were not satisfied with that.
A friend of mine was master of getting zeros without zeros - usually without increasing the program size -- so that he could type them with a "copy con" command.
Those were the days.
(Me, I was able to read machine code from hex, but not write it unless it was extremely simple; and the hex<->dec conversion took too long. So I just used debug for those 10-20 instruction things)
It's still kind of magical to me to write a program that does something useful that's only half a line of gibberish when you TYPE it. I just wish there was a better way than PNG to share what it's supposed to look like!
According to Ralf Brown's interrupt list, http://www.ctyme.com/intr/rb-2554.htm, MS-DOS 1.0 did not support redirecting standard output; that was a feature added in MS-DOS 2.0, which didn't come out until 1983: http://en.wikipedia.org/wiki/Timeline_of_x86_DOS_operating_s...
So if you really had to solve this problem on 1982 MS-DOS, you'd need to open an output file with a file control block and INT 21 with AH=0F. (And if you really can't type NUL bytes on the keyboard, I think you are going to have to write some code to zero out most of the FCB at start time, too. Ick.)
This program might solve that problem for MS-DOS 2+, although I haven't tested it yet, and you'd have to use something like JKLMNO instead of ABCDEF for your hex digits past 9:
100: b4 01 mov $0x1,%ah
102: cd 21 int $0x21
104: 24 0f and $0xf,%al
106: 88 c2 mov %al,%dl
108: c0 e2 04 shl $0x4,%dl
10b: cd 21 int $0x21
10d: 24 0f and $0xf,%al
10f: 08 c2 or %al,%dl
111: b4 02 mov $0x2,%ah
113: cd 21 int $0x21
115: eb e9 jmp 100 <loop>
kragen@VOSTRO9:~/devel/misc$ xxd < hexconverter.com
0000000: b401 cd21 240f 88c2 c0e2 04cd 2124 0f08 ...!$.......!$..
0000010: c2b4 02cd 21eb e9 ....!..
kragen@VOSTRO9:~/devel/misc$ od -t u1 < hexconverter.com
0000000 180 1 205 33 36 15 136 194 192 226 4 205 33 36 15 8
0000020 194 180 2 205 33 235 233
0000027
kragen@inexorable:~/devel/inexorable-misc$ od -t u1 hexconv.com
0000000 180 1 205 33 36 15 136 194 192 226 4 205 33 36 15 1
0000020 194 180 2 205 33 235 233
0000027
1. It echoes its input so you can see, at least in theory, if you made a mistake.
2. You only need to type two keystrokes instead of one to four per byte.
3. There are no forbidden bytes. At least in Dosbox, COPY CON converts ^@ to the sequence 00 03, interprets 08 as backspace (even if entered on the keypad with Alt), and stops copying when it gets a carriage return, even if the carriage return was entered with Alt.
4. To exit, you must reboot. In Dosbox, the output has already been flushed to the filesystem, but I have my doubts about whether, on MS-DOS, every single INT 21H AH=2 would write a 512-byte floppy disk sector with the newly appended byte. On the other hand, you could probably just mash some key on autorepeat long enough to fill up a couple of sectors, and you'd be good to go. This program, after all, only has to be sufficient to enter the next phase of the bootstrap, one with backspace and explicit termination.
5. There is no backspace, so if you hit any incorrect keystrokes, you must start over. For programs of this size, that's not a major constraint — it's pretty easy to carefully enter 40 or 50 or 100 keystrokes without making any errors — but it becomes more serious as programs get larger.
1983 doesn't seem that late to me. http://en.wikipedia.org/wiki/Timeline_of_x86_DOS_operating_s...