DFS Plagarism?

bbc/electron apps, languages, utils, educational progs, demos + more
Post Reply
Coeus
Posts: 1575
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

DFS Plagarism?

Post by Coeus » Mon Jun 29, 2020 2:44 pm

Having been tracing some of the DFS ROMs recently I was struck by an odd similarity. In the Acorn DFS ROM there a subroutine that can be called from the head of another subroutine that saves all the registers on the stack as well as adding an intermediate return that pops them off again:

Code: Select all

       83E1: 48          PHA         ; Save all registers.
       83E2: 8A          TXA         
       83E3: 48          PHA         
       83E4: 98          TYA         
       83E5: 48          PHA         
       83E6: A9 84       LDA #84     ; add a new return address that points to the tail of this
       83E8: 48          PHA         ; subroutine which will pull the registers back off the stack.
       83E9: A9 03       LDA #03     
       83EB: 48          PHA         
       83EC: A0 05       LDY #05     
       83EE: BA          TSX         
       83EF: BD 07 01    LDA 0107,X  ; grab the return address of our caller and the registers
       83F2: 48          PHA         ; pushed at the start of this routine and push them back
       83F3: 88          DEY         ; on the top of the stack.
       83F4: D0 F8       BNE 83EE    
       83F6: A0 0A       LDY #0A     ; now move the top ten bytes of the stack down two bytes 
       83F8: BD 09 01    LDA 0109,X  ; removing the copy of the address of our immediate caller
       83FB: 9D 0B 01    STA 010B,X  ; burried the most deeply but leaving the values of the
       83FE: CA          DEX         ; registers pushed at the start of this routine.
       83FF: 88          DEY         
       8400: D0 F6       BNE 83F8    
       8402: 68          PLA         ; as we didn't adjust the stack pointer when we moved the stack
       8403: 68          PLA         ; down by two bytes, discard two bytes from the top.

       8404: 68          PLA         ; This bit is executed twice, once as part of the original call
       8405: A8          TAY         ; and then again when the calling subroutine returns to here.
       8406: 68          PLA         
       8407: AA          TAX         
       8408: 68          PLA         
       8409: 60          RTS         
I first came across a subroutine like this in the Solidisk DDFS back in the 1908s and sure enough an copy of this routine is in the Solidisk DDFS 2.1 at 8328 with the only difference being the immediate values loaded and then pushed as these are the address of the tail that pops the registers at the end and therefore change when the whole routine is relocated.

So looking at Watford DDFS 1.53 the same applies with the routine being at 82D7 and in Opus DDOS 3.45 it can be found at A2EC.

Now clearly this is a generally applicable subroutine, not something specific to floppy discs or even filing systems in general, though it is going to be a bit slow compared to each subroutine pushing and popping registers directly so would seem more applicable for a case where is speed is limited by the floppy disc itself and space is at a premium, but I have never seen it anywhere else. Now if two DFS ROMs had a very similar piece of code to program a command into the 8271 that would not be surprising but this piece of common code suggests there is some link in the history of these DFSes. Possibilities seem to be:
  • The other manufacturers signed a source license with Acorn.
  • Someone who had worked on the Acorn DFS was hired to work for the others.
  • Other manufacterers disassembled the Acorn DFS and copied the bits they liked.
Does anyone know more about this?

jay
Posts: 28
Joined: Sat Apr 25, 2020 12:53 pm
Location: Dublin
Contact:

Re: DFS Plagarism?

Post by jay » Wed Jul 01, 2020 9:04 am

I don't have any information about the specific question you asked. But, most of the DFS implementations seem to have been written with significant code size constraints. Consider for example that Watford DFS 1.54T had to sacrifice the disc sector editor in order to fit in other features (auto double-step and Acorn 1770 DFS compatibility). Or that (at least some) versions of Acorn DFS didn't include the format command in ROM. I don't have any specific info about this, but I assume the idea was to avoid needing a larger ROM chip.

Using code like you describe avoids, as you say, repeating it in a bunch of routines, providing perhaps a significant code side saving. Might that not, by itself, explain this similarity? IOW, programmers having similar problems and similar constraints choosing similar solutions?

Post Reply

Return to “8-bit acorn software: other”