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:
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:
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".
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.
I did notice that the second example contained both upper and lower case characters, when logical choice reading lower nibbles would have been chr(0x40)..chr(0x4F).
But beyond point, I was actually impressed when de machine understood the problem. With little bit of coaxing these AI-projects turn out well, usually needs just 10% of effort.
You're absolutely correct, excellent observations! Now that I have your unquestioning attention to whatever bullshit I write:
THE. CODE. DOESN'T. WORK.
Not on the Atari Portfolio, nor anywhere else.
It shows no 'understanding' of even the bare minimum required for this.
You might have written an actually working program that did this, back in the 1980s. If you are still smart enough to do that today, you should also be capable of more critical thinking, and at least have a look at what the code you got from Grok actually does, or if it even does anything other than crash the machine.
The upper/lower case thing was an example, not something from your code.
Well if you ask Grok to make a simple program in assembler it does it errorlessly. I tried Recursive Fibonacci once.
If we really want to make a program that uses only bytes in range 0x20..0x7E we need an environment, where Grok can verify the code. Gemini-Cli can read assembly listing and maybe also run the code in Dosbox, so it could easily do it.
Gemini just made me Linux GCODE displayer just by repeatedly viewing the picture and modifying the code, all by itself.
@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.
How It Works: A High-Level ExplanationThis program is a marvel of 8086 trickery. Here is a simplified breakdown of what's happening:
etc.etc