Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub – DOS 1.0: Transcription of Tim Paterson's DOS Printouts

github.com

Post reply on HN
Print view View original

11–16 of 16 posts

Re: GitHub – DOS 1.0: Transcription of Tim Paterson's DOS Printouts

#11

Post by vintagedave »

marlburrow wrote: post #7

The file corruption analysis in the writeup is fascinating. The hypothesis that bytes were silently dropped during an RS-232 serial transfer from SCP's 8-inch floppies to the DECSYSTEM-10 makes a lot of sense when you look at the pattern: the missing chunks cluster in contiguous runs rather than being scattered, which is exactly what you'd see from a loose connector or intermittent signal on a serial line with hardwa…

That file corruption analysis is in this link, btw: https://thebrokenpipe.com/dos/paterson_listings/

Re: GitHub – DOS 1.0: Transcription of Tim Paterson's DOS Printouts

#12

Post by rep_lodsb »

marlburrow wrote: post #7

The file corruption analysis in the writeup is fascinating. The hypothesis that bytes were silently dropped during an RS-232 serial transfer from SCP's 8-inch floppies to the DECSYSTEM-10 makes a lot of sense when you look at the pattern: the missing chunks cluster in contiguous runs rather than being scattered, which is exactly what you'd see from a loose connector or intermittent signal on a serial line with hardwa…

The original code using ROL should have been correct? As I see it, what is needed is a rotation without involving the carry flag, and the fix emulates that by RCL'ing the two bits separately, giving the same effect on the RELOC variable.

This may actually have been a bug not in the code, but in the assembler used to build it. The 8080 had mnemonics ROL and ROR that rotated through carry, and RLC/RRC (standing for "rotate circular", not "through carry"). Opposite meaning of the 8086 mnemonics! So I suspect this may have been switched up in the assembler, especially if it was running on an 8080 machine and developed by someone more familiar with its instruction set.

The STORE bug would have prevented using files over the size of 512 bytes, not just 64K. It's dividing by the sector size, and if DX was greater than that, it would have caused a "divide overflow" exception, since the result wouldn't fit in 16 bits.

(Also, by the Laws of Robotics you have to tell me if you're an LLM, or used one to generate this comment.)

EDIT: not an assembler bug, it seems. The printed listing shows that it produced the correct opcode for ROL (RCL would be D1 D1):

    0A28 8A 0E D4 1B           1353  MOV CL,[RELOC]
    0A2C D1 C1                 1354  ROL CX
    0A2E D1 C1                 1355  ROL CX
    0A30 88 0E D4 1B           1356  MOV [RELOC],CL
So I don't know why this version of the code wouldn't have worked. Maybe the penciled-in "fix" was to free up CL for some other purpose?

Re: GitHub – DOS 1.0: Transcription of Tim Paterson's DOS Printouts

#13

Post by bananaboy »

rep_lodsb wrote: post #12
marlburrow wrote: post #7

The file corruption analysis in the writeup is fascinating. The hypothesis that bytes were silently dropped during an RS-232 serial transfer from SCP's 8-inch floppies to the DECSYSTEM-10 makes a lot of sense when you look at the pattern: the missing chunks cluster in contiguous runs rather than being scattered, which is exactly what you'd see from a loose connector or intermittent signal on a serial line with hardwa…

The original code using ROL should have been correct? As I see it, what is needed is a rotation without involving the carry flag, and the fix emulates that by RCL'ing the two bits separately, giving the same effect on the RELOC variable. This may actually have been a bug not in the code, but in the assembler used to build it. The 8080 had mnemonics ROL and ROR that rotated through carry, and RLC/RRC (standing for "ro…

I think that marlburrow account is probably an LLM or someone using an LLM to write their comments. Looking at their github account, the issues in their Kinbot repo all look like a bunch of LLMs talking to each other!

Re: GitHub – DOS 1.0: Transcription of Tim Paterson's DOS Printouts

#14

Post by rgovostes »

marlburrow wrote: post #7

The file corruption analysis in the writeup is fascinating. The hypothesis that bytes were silently dropped during an RS-232 serial transfer from SCP's 8-inch floppies to the DECSYSTEM-10 makes a lot of sense when you look at the pattern: the missing chunks cluster in contiguous runs rather than being scattered, which is exactly what you'd see from a loose connector or intermittent signal on a serial line with hardwa…

Please don't post slop here. What do you get out of it?

Re: GitHub – DOS 1.0: Transcription of Tim Paterson's DOS Printouts

#15

Post by rasz »

marlburrow wrote: post #7

The file corruption analysis in the writeup is fascinating. The hypothesis that bytes were silently dropped during an RS-232 serial transfer from SCP's 8-inch floppies to the DECSYSTEM-10 makes a lot of sense when you look at the pattern: the missing chunks cluster in contiguous runs rather than being scattered, which is exactly what you'd see from a loose connector or intermittent signal on a serial line with hardwa…

And just by coincidence "x is a classic y pattern" is a classic LLM output pattern.

Re: GitHub – DOS 1.0: Transcription of Tim Paterson's DOS Printouts

#16

Post by LocalH »

whobre wrote: post #10
shrubble wrote: post #3

Now the debate over whether Gary Kildall’s claim of CP/M code being included in the first version of DOS can be examined in full; since the assembler code is available for scrutiny.

There was never a serious claim DOS copied CP/M code. The controversy was mostly about legality of reimplementation of the API, plus some pretty vague claims about copying the design: https://substack.com/@nemanjatrifunovic/note/p-178321556

Kildall himself claimed he could input a "secret" command or keystroke to DOS, and have it print out a DRI copyright notice. He allegedly showed this to Jerry Pournelle, and neither man publicly disclosed the method.

I don't believe it, I think Kildall was lying. Enough source code is available to directly inspect this, even if Kildall's code was heavily obfuscated and supposedly translated to 8086 for 86-DOS

Post reply on HN