H89 disk transfer program

From: Dwight K. Elvey <dwightk.elvey_at_amd.com>
Date: Mon Apr 14 20:28:00 2003

>From: "Patrick Rigney" <patrick_at_evocative.com>
>
>> It currently takes
>> about 40H+ of code to enter ( in octal for Heath monitor ).
>> I might find some code in the ROMs that does this
>> part for me. This is a little long but there is not much
>> I can do about it.
>
>> Any suggestions on things I might want to add?
>> Dwight
>
>Dwight,
>
>Hmmm... interesting. I have an idea... How about borrowing a concept from
>bootloaders in general? Shorten the program that you have to key in by hand
>to just a short bootstrap loader that reads bytes from the serial port and
>stuffs memory. The PC-side program's job, then, is to *first* send the
>*real* larger downloader down the line before the disk image data, which the
>bootloader stuffs into memory and then executes to read the image data that
>then follows. I'm not sure how much shorter the bootloader could be than
>40H, but I have to imagine a good bit since no disk I/O is needed at that
>stage, and it would certainly facilitate the bigger duplicator app being
>much larger without much hassle to the operator.
>
>Patrick
>

Hi Patrick
 Reread my post. That is just about all it does. It does
have to initialize the port and that takes more than about
half the code. The loop that loads the memory is quite short.
The com port on the H89 is a 8250 and so needs a bunch of stuff
setup. To load a value into the port I/O takes 3 to 4 bytes,
regardless of how it is done. I suspect I can strip a little
but I doubt I can take out more than about 10%.
One thing I haven't tried is to use the Z80 I/O instructions
and have a table of things to output in sequence. This might be
shorter.
 Anyway, I've made it so that I can optimize it more after
I get the rest of the functionality of the main code.
 There is a small amount of extra because I've not used a fixed
load address or fixed size. I could shorten it a little and
keep it flexable by only writing the load address. One would
write the bytes backwards from there. At some point, the
JMP instructions address would be over written by my new load code.
The address of the high byte would be the same, just the
low byte part of the address would change, directing the
code to the newly loaded code. This would simplify the load
loop since no count needs to be maintained ( a trick I learned
form my Nicolet 1080's bootstrap ).
 I'll make another pass at the code and publish what I have.
Others can then look at it for optimizations.
Dwight
Received on Mon Apr 14 2003 - 20:28:00 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:35:44 BST