rridge@csclub.uwaterloo.ca (Ross Ridge) writes:

> Anssi Saari   wrote:
>>Yes, presumably. But it's just a little bit hard to do I/O if you switch
>>I/O out of your memory space so that's not the thing to do, exactly.
>
> You can either swap the I/O space in and out as each byte is read or
> keep it mapped and have 4K less RAM to store the program.
>
>>One could use RAM to RAM copy to fill the RAM under I/O. But I wonder,
>>Pekka's routine was just 40 bytes using ROM routines so 6.5K (or 5.5K
>>since the program was actually copy 58.5k) RAM seems excessive.
>
> I'm assuming it would be using some sort of "fastloader" code to improve
> speed so it wouldn't use the kernal ROM.

The program is 1983 vintage and doesn't seem to use a fastloader or
compression. Disk is read and written a byte at a time using kernal's
ACPTR and CIOUT routines. The program is delightfully straightforward:
it starts by setting screen and border colors, then puts a preformatted
message on screen and starts polling for keyboard input.

After going through the disassembly I eventually found the code which
reads a byte from RAM ($0d19) and writes a byte to RAM ($0d08):

0d00: S0d00         sei
0d01:               ldy #$34
0d03:               sty $01
0d05:               ldy #$00
0d07:               rts
0d08: S0d08         jsr S0d00
0d0b:               sta ($22),y
0d0d: L0d0d         inc $22
0d0f:               bne L0d13
0d11:               inc $23
0d13: L0d13         ldy #$37
0d15:               sty $01
0d17:               cli
0d18:               rts
0d19: S0d19         jsr S0d00
0d1c:               lda ($22),y
0d1e:               jmp L0d0d

So, in the end that's all there is to it... Disable interrupts, switch
ROMs and I/O out. Display is blanked during disk reading and writing
too. Still not quite clear why the size limit is 58.5K but for copying a
whole disk in three passes it's enough. Limit for number of files seems
to be 32.

--- SoupGate-Win32 v1.05