[sebhc] H17 ROM ?

[Dave Dunfield]

Hi Steven,

>Are you looking at your disassembly, or just that partial listing in the 
>archives?  (That listing only shows the very beginning of the ROM).   
>Disk-related entry points in the H17 ROM include:
> ... Very helpful list deleted for brevity.

Yes, that was a preliminary comment, based on some of my disassembly, the listing
from the archive, and some comments from the Mac emulator documentation which indcated
that the driver entry points were in the HDOS RAM area (I expected them to be in the
ROM) - I've since discovered that the ROM fills in a vector table in the HDOS area
with many references to itself, some of which I have worked out (will be much easier
now with your list).


>>I had been assuming that the ROM would contain all the disk
>>functions, so that the operating system could access the disk
>>no matter which controller/drive you had installed
>
>Different controllers had different ROMs.  The H17 ROM only addresses its 
>own controller.

I realize that - my point was that if the entire driver was in the ROM, then the
same OS image could work if booted on any controller - calls would filter down
to the ROM - I see now that it could work this way, however allowance has been
made for replacement of the ROM drivers.


>Ron said:
>>Look in the PAM-37 Panel Monitor Operation/service Manual. That book
>>contains a listing with routines for and references to all the disk types.
>
>I don't think the PAM-37 listing has made it into the archives - I've been 
>looking for it myself.  Ironically, even though I am the author of PAM-37, I 
>don't have a copy of the listing!

Hows your memory - with my disassmbler, you can add symbols, block definitions,
comments etc. as an ongoing work - makes it fairly easy to recover source code
if you have a good understanding of what the program is doing...


I spent a couple of hours looking at the material today ... I'm pretty sure I
can make the system perform physcal reads and writes, however I have hit a
stumbling block - according to the Mac emulator documenation, the disk system
keeps a "header" on each sector which identifies the volume and sector - It
does not give details on how this is organized. The images that I have are
exactly 102400 bytes in size, meaning that they contain the data portion only.
I would have to recrate the header on the fly - but without details on exactly
how it is formatted, the possibilities are endless - Can't proceed without
this information.

I've found sections of the code that "look" like they could be loading in
extra information (more than 256 sectors), but I don't completely understand
it yet. Here is an example, which looks like it would only load 256 bytes,
yet it "could" load more:

1C6E 0E 00     ..           MVI     C,$00       C=0
1C70 41        A            MOV     B,C         B=0
1C71 CD 91 20  ..           CALL    WSYNC       Does not modify B/C
1C74 DA B1 1C  ...          JC      $1CB1       No sync
1C77 CD 82 20  ..           CALL    REDATA      Read data byte
1C7A 77        w            MOV     M,A         Save
1C7B 23        #            INX     H           Next
1C7C 05        .            DCR     B           Reduce count
1C7D C2 77 1C  .w.          JNZ     $1C77       Read all
1C80 79        y            MOV     A,C         This will be Zero
1C81 A7        .            ANA     A           So this sets 'Z'
1C82 CA 8C 1C  ...          JZ      $1C8C       And no more data read
1C85 CD 82 20  ..           CALL    REDATA      ?Keep reading?
1C88 0C        .            INR     C           ?Advance to 256
1C89 C2 85 1C  ...          JNZ     $1C85       ?And then stop
1C8C 42        B            MOV     B,D         get computed BCC
1C8D CD 82 20  ..           CALL    REDATA      Read disk BCC
1C90 B8        .            CMP     B           Match
1C91 C2 BA 1C  ...          JNZ     $1CBA       No - error

As you can see the 0 in C prevents the second loop from running - At first I
thought there might be places which call 1C71 after loading B and C independantly,
however I have not indentified any such calls.

Some of the code does crafty things which may obscure some instructions until
I actually get to that function and figure it out - here is an example where an
XRA A instruction is hidden:

19AB 3E 01     >.           MVI     A,$01
19AD FE AF     ..           CPI     $AF
19AF CD 58 20  .X           CALL    $2058
19B2 D0        .            RNC
19B3 F5        .            PUSH    PSW
19B4 3A 31 21  :1!          LDA     $2131
19B7 A7        .            ANA     A
19B8 CC 0B 21  ..!          CZ      $210B
19BB F1        .            POP     PSW
19BC C9        .            RET

The CPI at 19AD serves no purpose other than to "eat" the AF, so that A can
remain at 1 - at other points in the code, address 19AE is called, which
results in XRA A / CALL ... -- tricks like this can make it hard to follow
some of the code.


If anyone can provide details on the complete disk sector format (including
SYNC bytes and BCC would be nice), that would help a lot.

Regards,
Dave

-- 
dave04a (at)    Dave Dunfield
dunfield (dot)  Firmware development services & tools: www.dunfield.com
com             Vintage computing equipment collector.
                http://www.parse.com/~ddunfield/museum/index.html

--
Delivered by the SEBHC Mailing List