3 ms·

I had Atari Portfolio, sold without software, except basic command.com. I could only copy raw ASCII bytes from keyboard to file. When it is in COM-file, it is d

by timonoko 11mo ago

I had Atari Portfolio, sold without software, except basic command.com. I could only copy raw ASCII bytes from keyboard to file. When it is in COM-file, it is directly executable. What is the simple program I made from ASCII-bytes to read bytes in hexadecimal. I thought that for a week, but finally solved it. @grok: This is a classic and brilliant puzzle from the early days of DOS. The challenge is to write a self-displaying hex dumper (.COM file) using only the copy con command, which means every byte of the program must correspond to a standard, typeable ASCII character. This is a form of code-golfing that relies on a deep understanding of 8086 machine code. The solution is a clever piece of self-modifying code. Since many essential 8086 opcodes (like MOV, INT, RET) don't have printable ASCII equivalents, the program must construct these instructions in memory and then execute them. Here is a well-known 128-byte solution. I will first show you the ASCII characters you would type, and then explain how it works. The Program to Type You would have started by typing copy con hex.com and then carefully typed the following 128 characters (including spaces and case-sensitive characters) and finally pressed Ctrl+Z to save the file. 1 j!>1!QhH-@0X,jHj.Ph1PhD0Ph 0@h, j, h.0@h, h 0@h.H-@,jH1X,h.H.@,H1j j X,h.H.@,H1j j X.H-@H-@,jHj.Ph1PhE0Ph@0@h, j, h.0@h, h 0@h. How It Works: A High-Level Explanation This program is a marvel of 8086 trickery. Here is a simplified breakdown of what's happening: etc.etc

timonoko 11mo ago
My program was definitively shorter. I think I did not bother with real hexadecimals. Just used last four bytes of characters to make a full byte. Used it as a bootstrap program. @grok: While your exact code is lost to time, it would have looked something like one of the ultra-small ASCII "dropper" programs that were once passed around. Here is a plausible 32-byte example of what the program you typed might have looked like. You would have run copy con nibbler.com, typed the following line, and hit Ctrl+Z: `j%1!PZYfX0f1Xf1f1AYf1E_j%1!PZ` This looks like nonsense, but to the 8088/8086 processor, it's a dense set of instructions that does the following: etc etc.
- timonoko 11mo ago
  97% of these millenials of HN do not understand the problem and its brilliant solution. That is why I was truly astonished @grok grokked it rightaway. BTW. It is not beyond possibility that this nibbler or dropper was made by myself and published in Usenet by me myself in 1989. Who else would have such a problem. It was a bankcrupt sale and the machine was sold as "inactivated".
  - rep_lodsb 10mo ago
    97% of AI enthusiasts will be astonished by complete garbage, and just blindly copy-paste it into forums, assuming that others will share their astonishment (and somehow consider them intelligent / interesting for it, despite expending almost zero effort themselves?). Let's take a look at just the first few instructions here: ASCII HEX ASM j% 6A 25 PUSH 25h ; 80186+ only, won't work on Atari Portfolio! 1! 31 21 XOR [BX+DI],SP ; complete nonsense P 50 PUSH AX ; AX sort-of-undefined at this point, depends on DOS version and command line arguments Z 5A POP DX ; copy AX into DX Y 59 POP CX ; CX = 25h? fX 66 58 POP EAX ; 80386+ only! also nothing on stack anymore! 0f1 30 66 31 XOR [BP+31h],AH ; complete nonsense ... This looks like randomly jumbled together from fragments of ASCII-only machine code intended for much newer x86 processors -- just look at how often `f` appears in those strings, which is the operand-size prefix, and meaningless on 16-bit chips. The memory addressing might make more sense in 32-bit mode too, where a different encoding is used (modr/m and SIB byte). And this is how LLMs work. They can associate the tokens for e.g. `PZ` with the instructions `PUSH AX / POP DX`, and a certain kind of program in which those would be likely to appear, drawn somewhere from their massive training set. Humans can easily learn to recognize these 'words' of ASCII text in machine code too, just by spending time looking at it. Another good one is the pair of `<ar` and `<zw` (usually next to each other, with an unprintable character between), present in most upcase()-like code from that era. So if you had asked Grok to accept both upper and lower case of hex input, I would bet that it would have inserted those sequences somewhere too. But what LLMs CAN NOT do is plan ahead on how to use these program fragments to accomplish a specific task, or keep simple constraints in mind like "this must run on the 80C88 processor in the Atari Portfolio". They even have trouble with keeping track of registers, stack, or which mode the CPU is in. (yes, late, but I can't let this stand here uncommented. https://xkcd.com/386 https://xkcd.com/386 )

timonoko 11mo ago

My program was definitively shorter. I think I did not bother with real hexadecimals. Just used last four bytes of characters to make a full byte. Used it as a bootstrap program. @grok: While your exact code is lost to time, it would have looked something like one of the ultra-small ASCII "dropper" programs that were once passed around. Here is a plausible 32-byte example of what the program you typed might have looked like. You would have run copy con nibbler.com, typed the following line, and hit Ctrl+Z: `j%1!PZYfX0f1Xf1f1AYf1E_j%1!PZ` This looks like nonsense, but to the 8088/8086 processor, it's a dense set of instructions that does the following: etc etc.

timonoko 11mo ago
97% of these millenials of HN do not understand the problem and its brilliant solution. That is why I was truly astonished @grok grokked it rightaway. BTW. It is not beyond possibility that this nibbler or dropper was made by myself and published in Usenet by me myself in 1989. Who else would have such a problem. It was a bankcrupt sale and the machine was sold as "inactivated".
- rep_lodsb 10mo ago
  97% of AI enthusiasts will be astonished by complete garbage, and just blindly copy-paste it into forums, assuming that others will share their astonishment (and somehow consider them intelligent / interesting for it, despite expending almost zero effort themselves?). Let's take a look at just the first few instructions here: ASCII HEX ASM j% 6A 25 PUSH 25h ; 80186+ only, won't work on Atari Portfolio! 1! 31 21 XOR [BX+DI],SP ; complete nonsense P 50 PUSH AX ; AX sort-of-undefined at this point, depends on DOS version and command line arguments Z 5A POP DX ; copy AX into DX Y 59 POP CX ; CX = 25h? fX 66 58 POP EAX ; 80386+ only! also nothing on stack anymore! 0f1 30 66 31 XOR [BP+31h],AH ; complete nonsense ... This looks like randomly jumbled together from fragments of ASCII-only machine code intended for much newer x86 processors -- just look at how often `f` appears in those strings, which is the operand-size prefix, and meaningless on 16-bit chips. The memory addressing might make more sense in 32-bit mode too, where a different encoding is used (modr/m and SIB byte). And this is how LLMs work. They can associate the tokens for e.g. `PZ` with the instructions `PUSH AX / POP DX`, and a certain kind of program in which those would be likely to appear, drawn somewhere from their massive training set. Humans can easily learn to recognize these 'words' of ASCII text in machine code too, just by spending time looking at it. Another good one is the pair of `<ar` and `<zw` (usually next to each other, with an unprintable character between), present in most upcase()-like code from that era. So if you had asked Grok to accept both upper and lower case of hex input, I would bet that it would have inserted those sequences somewhere too. But what LLMs CAN NOT do is plan ahead on how to use these program fragments to accomplish a specific task, or keep simple constraints in mind like "this must run on the 80C88 processor in the Atari Portfolio". They even have trouble with keeping track of registers, stack, or which mode the CPU is in. (yes, late, but I can't let this stand here uncommented. https://xkcd.com/386 https://xkcd.com/386 )