Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #1932 > unrolled thread

Re: More info on Apple /// drivers?

Back to article view | Back to comp.sys.apple2.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: More info on Apple /// drivers? David Schmidt <schmidtd@my-deja.com> - 2015-10-27 11:00 -0400
    Re: More info on Apple /// drivers? ultramagnus_tcv <email@domain.com> - 2015-10-27 12:38 -0500
      Re: More info on Apple /// drivers? David Schmidt <schmidtd@my-deja.com> - 2015-10-27 16:28 -0400
        Re: More info on Apple /// drivers? ultramagnus_tcv <email@domain.com> - 2015-10-28 07:42 -0500
          Re: More info on Apple /// drivers? David Schmidt <schmidtd@my-deja.com> - 2015-10-28 09:42 -0400
    Re: More info on Apple /// drivers? ultramagnus_tcv <mikew@thecomputervalet.com> - 2015-11-10 12:25 -0600
      Re: More info on Apple /// drivers? David Schmidt <schmidtd@my-deja.com> - 2015-11-11 00:31 -0500
        Re: More info on Apple /// drivers? ultramagnus_tcv <email@domain.com> - 2015-11-11 12:12 -0600
          Re: More info on Apple /// drivers? ultramagnus_tcv <mikew@thecomputervalet.com> - 2015-12-11 10:07 -0600

#1932 — Re: More info on Apple /// drivers?

On 10/27/2015 10:16 AM, ultramagnus_tcv wrote:
> Hello,
>
> I am looking for more  detail on writing Apple /// drivers. I have the
> 1982 version of the Device Drivers Writer's Guide and it's answering
> most questions for me, but not everything.

The only other place where documentation is common is in device driver 
source code itself - you can see a bunch of them here:
http://apple3.org/iiisourcecode.html

> I'd like to know, for instance, more about the bytes in-between
> sub-drivers (e.g. between .FMTD2 and .FMTD3). I'd also like to know if
> Apple ever published a larger list of manufacturers and types and
> sub-types.

I've written a few myself, and can probably help.  But I'm not sure what 
you're asking for in this case.  If you mean the DIB - that data 
structure is pretty well defined.  If you mean the padding bytes after 
the device name - they're spaces.  Example:

;------------------------------------
;
; Device identification Block (DIB) - VSDRIVE
;
;------------------------------------

DIB_0     .WORD     DIB_1            ; Link pointer
           .WORD     Entry            ; Entry pointer
           .BYTE     008              ; Name length byte
           .ASCII    ".VSDRIVE       "; Device name
           .BYTE     080              ; Active, no page alignment
           .BYTE     000              ; Slot number
           .BYTE     000              ; Unit number
           .BYTE     0E1              ; Type
           .BYTE     010              ; Subtype
           .BYTE     000              ; Filler
DIB0_Blks .WORD     0000             ; # Blocks in device
           .WORD     DriverMfgr       ; Manufacturer
           .WORD     DriverVersion    ; Driver version
           .WORD     0000             ; DCB length followed by DCB

(followups set to comp.sys.apple2.programmer)

[toc] | [next] | [standalone]

#1935

On 2015-10-27 15:00:09 +0000, David Schmidt said:

> On 10/27/2015 10:16 AM, ultramagnus_tcv wrote:
>> Hello,
>> 
>> I am looking for more  detail on writing Apple /// drivers. I have the
>> 1982 version of the Device Drivers Writer's Guide and it's answering
>> most questions for me, but not everything.
> 
> The only other place where documentation is common is in device driver 
> source code itself - you can see a bunch of them here:
> http://apple3.org/iiisourcecode.html

Thank you much.

>> I'd like to know, for instance, more about the bytes in-between
>> sub-drivers (e.g. between .FMTD2 and .FMTD3). I'd also like to know if
>> Apple ever published a larger list of manufacturers and types and
>> sub-types.
> 
> I've written a few myself, and can probably help.  But I'm not sure 
> what you're asking for in this case.  If you mean the DIB - that data 
> structure is pretty well defined.  If you mean the padding bytes after 
> the device name - they're spaces.  Example:

Yes, I think the book I have sets out the DIB well, however, it doesn't 
seem to address bytes in between subdrivers... I'm new to programming 
so it could be in front of my face.

... and so it is.... somewhat.

These are the bytes between your .CFFA3000 names:
20 20 20 20 80 01 00 F1 10 00 00 00 53 44 00 10 00 00 44 00 32 01
20 20 20 20 80 01 01 F1 10 00 00 00 53 44 00 10 00 00 66 00 32 01
20 20 20 20 80 01 02 F1 10 00 00 00 53 44 00 10 00 00 88 00 32 01

Looks to me one change is the Unit field is incremented by x01. In the 
example I have, we reach up to 07. IOW: .D1 - .D7

Although I don't know what the 44, 66, and 88 refer to. Probably part 
of the DIB I've not looked at yet.

But since you're already here.... I am trying to understand the Entry 
field. My book states:

"The Entry field (bytes $2 and $3) points to driver's entry address. 
The entry point is defined by the device driver's writer and the value 
is relocated during system boot to reflect the driver's location in 
memory after startup. The pointer is used by the SOS device manager 
when it calls the device driver."

Is the value one you chose when writing your device driver? Does it 
matter what the value is when the driver is at rest, so to speak, or 
only when loaded into memory?

Mostly as a programming exercise, a friend and I are writing a Python 
script that can be fed an imaged Apple /// disk, pull out the 
SOS.DRIVER file, parse through it for drivers and their associated 
DIBs, then log the output to a CSV.

Cheers,

Mike Whalen

[toc] | [prev] | [next] | [standalone]

#1937

On 10/27/2015 1:38 PM, ultramagnus_tcv wrote:
> These are the bytes between your .CFFA3000 names:
> 20 20 20 20 80 01 00 F1 10 00 00 00 53 44 00 10 00 00 44 00 32 01
> 20 20 20 20 80 01 01 F1 10 00 00 00 53 44 00 10 00 00 66 00 32 01
> 20 20 20 20 80 01 02 F1 10 00 00 00 53 44 00 10 00 00 88 00 32 01
>
> Looks to me one change is the Unit field is incremented by x01. In the
> example I have, we reach up to 07. IOW: .D1 - .D7

Correct.  Just map the DIBs to the memory footprint you're dumping. 
You'll see the correlation.

> Although I don't know what the 44, 66, and 88 refer to. Probably part of
> the DIB I've not looked at yet.

The DIB structure itself is 34 ($22) bytes long. So the 44/66/88 you see 
are offsets to each one. If you dump out more of the surrounding data, 
you'll see where the DIB map begins and ends. I suspect SOS stuffs some 
bytes in between there that I as a device driver writer don't insert as 
part of the DIB data structures.  $44/$53 are my initials, DS, as the 
"driver manufacturer."  Since Apple doesn't hand out manufacturer IDs 
any more (nor did they ever publish such a list - but that could be a 
project for you and your Python script) I just made that up.

> But since you're already here.... I am trying to understand the Entry
> field. My book states:
>
> "The Entry field (bytes $2 and $3) points to driver's entry address. The
> entry point is defined by the device driver's writer and the value is
> relocated during system boot to reflect the driver's location in memory
> after startup. The pointer is used by the SOS device manager when it
> calls the device driver."
>
> Is the value one you chose when writing your device driver? Does it
> matter what the value is when the driver is at rest, so to speak, or
> only when loaded into memory?

The Entry field is used as the address for the OS to call you when 
someone accesses your driver.  It's the driver's "entry point."  It's 
where the business of the driver actually takes place:

;------------------------------------
;
; Driver request handlers
;
;------------------------------------
Entry     LDA DIB0_Slot
           JSR SELC800    ; Turn on C800 ROM space from our slot
           LDA SOS_Unit
           STA CFFAUnit
           INC CFFAUnit   ; CFFA3000 unit is 1-based vs. SOS 0-based
...

As an assembly programmer, you're accustomed to knowing where in memory 
"Entry" actually is... but in SOS, you don't.  From your perspective, 
you don't care - you let the relocating loader take care of it.  You 
simply have to provide space for SOS to fill that in at the appropriate 
time (runtime).  It's meaningless as persisted on disk, as it gets fixed 
up at driver load time.

> Mostly as a programming exercise, a friend and I are writing a Python
> script that can be fed an imaged Apple /// disk, pull out the SOS.DRIVER
> file, parse through it for drivers and their associated DIBs, then log
> the output to a CSV.

That would be really cool to harvest.  I have generated a list of /// 
drivers and the disks they came from as folks come asking for a 
particular driver from time to time.  But getting that next level of 
detail would be really useful, and some drivers are buried in a 
SOS.DRIVER file without having a version sitting outside of it.  (You of 
course can always pull a driver out of the SOS.DRIVER file to 
reconstitute a more readily distributable version of it, but you need to 
know it's there in the first place... hence the utility of your exercise.)

[toc] | [prev] | [next] | [standalone]

#1939

On 2015-10-27 20:28:04 +0000, David Schmidt said:

> As an assembly programmer, you're accustomed to knowing where in memory 
> "Entry" actually is... but in SOS, you don't.  From your perspective, 
> you don't care - you let the relocating loader take care of it.  You 
> simply have to provide space for SOS to fill that in at the appropriate 
> time (runtime).  It's meaningless as persisted on disk, as it gets 
> fixed up at driver load time.

Ok. That helps. It tells me, more than anything, that logging the Entry 
field is not terribly useful here.

> 
>> Mostly as a programming exercise, a friend and I are writing a Python
>> script that can be fed an imaged Apple /// disk, pull out the SOS.DRIVER
>> file, parse through it for drivers and their associated DIBs, then log
>> the output to a CSV.
> 
> That would be really cool to harvest.  I have generated a list of /// 
> drivers and the disks they came from as folks come asking for a 
> particular driver from time to time.  But getting that next level of 
> detail would be really useful, and some drivers are buried in a 
> SOS.DRIVER file without having a version sitting outside of it.  (You 
> of course can always pull a driver out of the SOS.DRIVER file to 
> reconstitute a more readily distributable version of it, but you need 
> to know it's there in the first place... hence the utility of your 
> exercise.)

That's encouraging, thanks. We do have some future goals once we get 
done with the intial pass. For one thing, my script requires the user 
have AppleCommander (and JAVA) in order to extract the SOS.DRIVER file. 
Eventually, I'd prefer to pull out the SOS.DRIVER file natively but I 
haven't really touched SOS or offsets as they relate to disk. I'm new 
to all of it... programming, too. :-) If you have any tips on this, I'd 
be grateful.

We also would like to be able to rescue drivers wholesale off imaged 
disks. The hope is we'll run across disks with oddball drivers. That 
way, they can be identified (initially) and rescued (ultimately).

Cheers,

Mike Whalen

[toc] | [prev] | [next] | [standalone]

#1940

On 10/28/2015 8:42 AM, ultramagnus_tcv wrote:
> [...] We do have some future goals once we get
> done with the intial pass. For one thing, my script requires the user
> have AppleCommander (and JAVA) in order to extract the SOS.DRIVER file.

Works fine for me.  :-)  You can distribute the ac.jar as part of your 
deliverable; that's not an issue with GPL.  I do with ADTPro.

> Eventually, I'd prefer to pull out the SOS.DRIVER file natively but I
> haven't really touched SOS or offsets as they relate to disk. I'm new to
> all of it... programming, too. :-) If you have any tips on this, I'd be
> grateful.

Nothing like diving in and having a real problem to solve to teach you 
what you need to learn.

> We also would like to be able to rescue drivers wholesale off imaged
> disks. The hope is we'll run across disks with oddball drivers. That
> way, they can be identified (initially) and rescued (ultimately).

Love it.  Definitely a needed resource.

[toc] | [prev] | [next] | [standalone]

#1950

David (or anyone else, perhaps),

On 2015-10-27 15:00:09 +0000, David Schmidt said:

> DIB_0     .WORD     DIB_1            ; Link pointer
>            .WORD     Entry            ; Entry pointer
>            .BYTE     008              ; Name length byte
>            .ASCII    ".VSDRIVE       "; Device name
>            .BYTE     080              ; Active, no page alignment
>            .BYTE     000              ; Slot number
>            .BYTE     000              ; Unit number
>            .BYTE     0E1              ; Type
>            .BYTE     010              ; Subtype
>            .BYTE     000              ; Filler
> DIB0_Blks .WORD     0000             ; # Blocks in device
>            .WORD     DriverMfgr       ; Manufacturer
>            .WORD     DriverVersion    ; Driver version
>            .WORD     0000             ; DCB length followed by DCB

Maybe you can clear up something for me...

In the Driver Writer's book indicates that immediately following a 
comment is the link field. However, it's clear that there are two bytes 
between the end of the comment and the link field.

So, for instance, in the case of your driver:

Comment Length:
4E 00

Comment:
41 70 70 6C 65 20 2F 2F 2F 20 43 46 46 41 33 30 30 30 20 28 43 6F 6D 70 
61 63 74 20 46 6C 61 73 68 20 46 6F 72 20 41 70 70 6C 65 20 33 30 30 30 
29 20 44 72 69 76 65 72 20 62 79 20 44 61 76 69 64 20 53 63 68 6D 69 64 
74 20 32 30 31 31

??
22 06

Link field
22 00

If there is no comment, the link field would be preceded by:

00 00 XX XX YY YY

Where XX XX are the unidentified bytes and YY is the link field.

Example: FMTD1

Comment Length:
00 00

??
A4 04

Link field
3E 04

Do you know what these two bytes represent?


By the way, I am not so adept at reading source so if this is available 
inside the source let me know how to find it.

Cheers,

m

[toc] | [prev] | [next] | [standalone]

#1951

On 11/10/2015 1:25 PM, ultramagnus_tcv wrote:
> In the Driver Writer's book indicates that immediately following a
> comment is the link field. However, it's clear that there are two bytes
> between the end of the comment and the link field.

I think you're expecting a 1-1 correspondence between the in-memory 
representation of a data structure and the way it's persisted on disk. 
My guess is that the driver is instead in an intermediate object code 
form on disk.  I further guess is the extra padding is an identification 
of where an address relocation/fixup needs to occur when it's being 
readied for its final destination in memory.

[toc] | [prev] | [next] | [standalone]

#1952

On 2015-11-11 05:31:44 +0000, David Schmidt said:

> On 11/10/2015 1:25 PM, ultramagnus_tcv wrote:
>> In the Driver Writer's book indicates that immediately following a
>> comment is the link field. However, it's clear that there are two bytes
>> between the end of the comment and the link field.
> 
> I think you're expecting a 1-1 correspondence between the in-memory 
> representation of a data structure and the way it's persisted on disk. 
> My guess is that the driver is instead in an intermediate object code 
> form on disk.  I further guess is the extra padding is an 
> identification of where an address relocation/fixup needs to occur when 
> it's being readied for its final destination in memory.

Yes, I am expecting a 1-1 correspondence (corrleation?) between the 
in-memory representation of a data structure and the way it's persisted 
on disk.

I appreciate your help. I continue to learn more and more. Cheers,

m

[toc] | [prev] | [next] | [standalone]

#2001

On 2015-11-11 18:12:19 +0000, ultramagnus_tcv said:

> On 2015-11-11 05:31:44 +0000, David Schmidt said:
> 
>> On 11/10/2015 1:25 PM, ultramagnus_tcv wrote:
>>> In the Driver Writer's book indicates that immediately following a
>>> comment is the link field. However, it's clear that there are two bytes
>>> between the end of the comment and the link field.
>> 
>> I think you're expecting a 1-1 correspondence between the in-memory 
>> representation of a data structure and the way it's persisted on disk. 
>> My guess is that the driver is instead in an intermediate object code 
>> form on disk.  I further guess is the extra padding is an 
>> identification of where an address relocation/fixup needs to occur when 
>> it's being readied for its final destination in memory.
> 
> Yes, I am expecting a 1-1 correspondence (corrleation?) between the 
> in-memory representation of a data structure and the way it's persisted 
> on disk.
> 
> I appreciate your help. I continue to learn more and more. Cheers,
> 
> m

David,

Is there a way I can email you something private? You can use my address above.

Cheers,

Mike...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web