----- Original Message -----
From: "Stuart Brady" <[EMAIL PROTECTED]>
To: <sam-users@nvg.ntnu.no>
Sent: Wednesday, July 07, 2004 4:40 PM
Subject: Re: A poor mans CF interface :-)
> Something that would be generally useful is a series of LDI instructions
> in ROM. Larger copies can be done from RAM using loops that jump to
> this series of LDIs. (The return address can be passed in HL'.)
That the way. When the LDIs are in RAM rember this:
LDI 20 T-states
LDIR BC*24-4 Tstates
(with HL and DE both in RAM)
> If the offset within the memory mapped I/O space has no effect:
>
> LD (%sp), SP
> DI
> LD SP, %source
> LD HL, %cfmmio
> POP BC ; 10 t-states
> LD (HL), B ; 7
> LD (HL), C ; 7
> POP BC ; 10
> LD (HL), B ; 7
> LD (HL), C ; 7
> ; ...
> LD SP, (%sp)
> EI
I assume the code is in ROM. The POP will take probably 12 Ts because SP
will point
to RAM (in ram a POP takes 12Ts, PUSH 16Ts)
> LDI takes 32 cycles per word, stack-copying uses more than 21, and this
> "stack-read-copying" method uses 24. It takes less space, too -- LDI
> uses 4 bytes per word, but stack-read-copying uses 3. Recovering from
> interrupts during copying should be possible, and I'd really like this.
I really like it too and I Didn't think of it myself ! Way to go !
I will check out if your 'POP LD' idea will take 26 Ts and also will check
LDI timing again when code is in ROM and DE,HL,SP are in RAM
> Using DJNZ, a loop of 4 or 8 of these in ROM should suffice. You could
> initialise the loop from RAM, since that part doesn't need to be as
> fast. A loop of 4 iterations would only occupy 13 bytes of ROM.
If this method realy works out as good as it looks I'd free as much bytes as
possible
for it ! However Using the stackpointer will not permit use of NMI and
Interrupts.
Not using NMIs is not a problem since it should not be used during disk
access
anyway. Not beeing able to use interrupts is a pitty though.
> I've noticed that stack-copying can be used to write to the interface,
> but the registers just need to be pushed in the same order that you
> popped them in (I.e. the opposite order to ordinary stack-copying).
Adjusting the SP will just take too much time I think.
> Checksum, error correction and compression code seem like good ways to
> use any spare ROM space, as well as sorts and searches, and manipulation
> of trees, lists and hash tables. How much space is there?
I think there would be not enough for it. I'd go for on the fly CRC and
compression
Edwin
