<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Sat, 03 Jan 2009 00:51:45 +0000
From   : afra@... (Phill Harvey-Smith)
Subject: My sideways ram utils

Sprow wrote:
> In article <495E8917.50605@...>,
>    Phill Harvey-Smith <afra@...> wrote:
>> I've hopefully ironed out most of the bugs from these, feel free to 
>> download and have a play.
>>
>> Constructive comments welcome :)
> 
> Skim reading the documentation, does *SRSAVE and *SRLOAD allow the optional
> 'Q' parameter? 

Alas not yet, at the moment it uses the 512 byte tape buffer, I guess 
what Q does is uses the memory between OSHWM and HIMEM as buffer I guess 
that could be implemented, with the advantage that if there's 16K of 
free memory there a whole load/save can happen in one go.

> Likewise for SRLOAD, the optional 'I' parameter added to later MOS versions.

What does the I flag do I've not seen that one ? At least the master ref 
  pdf I have makes no mention of it.

> Should the help for SRCOPY specify which is the master and which is the copy?

Yes that's probably a good idea, I was working on the assumption that as 
we read left to right the source was the first parameter and the 
destination the second.

> I think an address range would be necessary for "SRCMP", otherwise if you
> loaded a long image into RAM followed by a short one then compared it with a
> ROM it wouldn't match. Or maybe SRCMP with a file (though SRLOAD followed by
> SRCMP would do the same thing).

Yeah that's probably a good idea a start and end address.

> Seriously impressed by the tidy source code!

Thanks, I figure that when I come back to look at it in 20 years time 
and try and debug it, being tidy and more importantly commented will 
help. One of the things I have noticed, and not liked about some of the 
beeb source code that I have seen is the multiple instructions per line
I can understand why the native assebler allows that but IMHO, it could 
make tracking down bugs much harder, and makes the source harder to 
understand for someone unfamilliar with it :)

> A minor optimisation, given that OutHexDigit AND's with 15 would make
> OutHexByte be
> 
>   pha
>   pha
>   lsra                    ; Move to bottom nibble
>   lsra
>   lsra
>   lsra
>   jsr     OutHexDigit     ; Print it
>   pla                     ; Recover byte to print
>   jsr     OutHexDigit     ; Print it
>   pla
>   rts

Yep you are correct, well spotted :)

Cheers.

Phill.

-- 
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !

"You can twist perceptions, but reality won't budge" -- Rush.
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>