[sebhc] H17 ROM ?
jack.rubin at ameritech.net
Fri May 21 20:16:28 CDT 2004
I've got the HDOS source listings which should include all this info,
but they are hard to read in the original and may be illegible in when
scanned. I'm hoping to load the H17 ROM tonight and then I can look at
the INIT program, which is the formatting utility.
> -----Original Message-----
> From: sebhc at sebhc.org [mailto:sebhc at sebhc.org] On Behalf Of
> Dave Dunfield
> Sent: Friday, May 21, 2004 4:35 PM
> To: sebhc at sebhc.org
> Subject: RE: [sebhc] H17 ROM ?
> 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
> >>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
> >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
> >I don't think the PAM-37 listing has made it into the
> archives - I've
> >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.
> dave04a (at) Dave Dunfield
> dunfield (dot) Firmware development services & tools:
com Vintage computing equipment collector.
Delivered by the SEBHC Mailing List
Delivered by the SEBHC Mailing List
More information about the Sebhc