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

Groups > comp.sys.apple2 > #42208 > unrolled thread

IIGS AppleDisk3.5 device driver code?

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

Contents

  IIGS AppleDisk3.5 device driver code? J R <calphool@gmail.com> - 2019-03-21 13:32 -0700
    Re: IIGS AppleDisk3.5 device driver code? D Finnigan <dog_cow@macgui.com> - 2019-03-21 20:53 +0000
    Re: IIGS AppleDisk3.5 device driver code? Tim Buchheim <tim1724@gmail.com> - 2019-03-21 14:20 -0700
      Re: IIGS AppleDisk3.5 device driver code? Stephen Heumann <stephenheumann@gmail.com> - 2019-03-21 15:57 -0700
        Re: IIGS AppleDisk3.5 device driver code? Antoine Vignau <antoine.vignau@laposte.net> - 2019-03-21 22:06 -0700
        Re: IIGS AppleDisk3.5 device driver code? J R <calphool@gmail.com> - 2019-03-22 07:04 -0700
          Re: IIGS AppleDisk3.5 device driver code? Stephen Heumann <stephen.heumann@gmail.com> - 2019-03-22 20:14 -0500
    Re: IIGS AppleDisk3.5 device driver code? David Schmidt <schmidtd@my-deja.com> - 2019-03-22 11:57 -0400
      Re: IIGS AppleDisk3.5 device driver code? J R <calphool@gmail.com> - 2019-03-22 09:23 -0700
        Re: IIGS AppleDisk3.5 device driver code? David Schmidt <schmidtd@my-deja.com> - 2019-03-22 12:31 -0400

#42208 — IIGS AppleDisk3.5 device driver code?

Hello all,

I'm new to this group, but I just bought a IIGS (ROM3) from a collector.  It has a 3.5 and 5.25 disk drive (A9M0106 and A9M0107 respectively).

I'm a software engineer, and while I was able to get my IIGS to boot with ADTPro and a null modem cable, and I was able to create GSOS boot disks, I was thinking about VSDRIVE.  It *appears* that you can't use VSDRIVE with GSOS, because although I can install it before booting GSOS, when GSOS runs, it doesn't find the virtual drives.  My guess is that VSDRIVE only works in 8-bit mode or something.... not really sure.  (If someone knows definitively what's going on, that would be appreciated).

So, that got me thinking about what it takes to write native GSOS code, specifically device drivers.  The server side of ADTPro couldn't be more straight forward.  It's just a java app that's watching for serial traffic, and responding appropriately.  So that got me thinking about GSOS.  It appears that GSOS uses a device driver called "AppleDisk3.5" to work with 3.5" drives.  It also uses a device driver called "SCSIHD.Driver" to work with hard drives.  What I am imagining is that it is theoretically possible to write a device driver that works with the server side of ADTPro across its serial interface, with a device driver running in GSOS that reports itself to be a floppy or hard drive.  It wouldn't be especially fast, but in theory you could put your entire disk image collection in it, and all you'd need was a null modem cable.  It would be like CFFA3000, but would cost less, and probably not perform as well, since it would be emulating everything across a null modem cable, rather than acting like a proper SCSI device (I assume that's what CFFA does... or maybe it somehow adds its own driver, not sure).

So that got me thinking about how you write code for GSOS.  Can anybody point me to where you start for the IIGS platform?  Specifically, how do you get started understanding GSOS's architecture?

Thanks all,
Joe R.

[toc] | [next] | [standalone]

#42209

J R wrote:
> 
> So that got me thinking about how you write code for GSOS.  Can anybody
> point me to where you start for the IIGS platform?  Specifically, how do
> you get started understanding GSOS's architecture?

Do you know assembly language? If so, do you know 65816 assembly?

Apple published a technical library for the Apple IIgs. You can buy these
books used thru Amazon.com or you can find PDF copies of them on some Apple
II web sites.

Two great sources are these sites:
https://apple2.gs/library.php
http://brutaldeluxe.fr/documentation/index.html


So the answer to your question of where to start: you need to start reading.
;-)

-- 
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

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

#42210

On Thursday, March 21, 2019 at 1:32:41 PM UTC-7, J R wrote:
> 
> I'm a software engineer, and while I was able to get my IIGS to boot with ADTPro and a null modem cable, and I was able to create GSOS boot disks, I was thinking about VSDRIVE.  It *appears* that you can't use VSDRIVE with GSOS, because although I can install it before booting GSOS, when GSOS runs, it doesn't find the virtual drives.  My guess is that VSDRIVE only works in 8-bit mode or something.... not really sure.  (If someone knows definitively what's going on, that would be appreciated).

VSDRIVE patches ProDOS 8 in memory (either overwriting the 5.25" driver code or allocating extra memory to install the driver to leave the 5.25" driver intact).

GS/OS uses a completely different driver model from ProDOS. ProDOS and GS/OS ignore each other drivers. (When running GS/OS, if you run a ProDOS 8 program (e.g., BASIC.SYSTEM) it loads a copy of ProDOS 8 into memory and when the program makes ProDOS calls they run through the same ProDOS drivers as if you'd booted into ProDOS 8. When that program exists back to GS/OS, GS/OS wipes ProDOS 8 out of memory and goes back to using GS/OS drivers. (Whie ProDOS 8 is active GS/OS goes into a sort of hibernation where most GS/OS system calls can't be made and pretty much all GS/OS code is completely inactive.)


> So, that got me thinking about what it takes to write native GSOS code, specifically device drivers.  The server side of ADTPro couldn't be more straight forward.  It's just a java app that's watching for serial traffic, and responding appropriately.  So that got me thinking about GSOS.  It appears that GSOS uses a device driver called "AppleDisk3.5" to work with 3.5" drives.  It also uses a device driver called "SCSIHD.Driver" to work with hard drives.  What I am imagining is that it is theoretically possible to write a device driver that works with the server side of ADTPro across its serial interface, with a device driver running in GSOS that reports itself to be a floppy or hard drive.  It wouldn't be especially fast, but in theory you could put your entire disk image collection in it, and all you'd need was a null modem cable.  It would be like CFFA3000, but would cost less, and probably not perform as well, since it would be emulating everything across a null modem cable, rather than acting like a proper SCSI device (I assume that's what CFFA does... or maybe it somehow adds its own driver, not sure).

CFFA3000 emulates a Disk ][ controller for 5.25" disk images and acts as a SmartPort device for everything else. GS/OS uses a generic driver for SmartPort devices.

A GS/OS driver that reads/writes blocks across the serial port is certainly possible (and would be a great asset to the community!)

> So that got me thinking about how you write code for GSOS.  Can anybody point me to where you start for the IIGS platform?  Specifically, how do you get started understanding GSOS's architecture?

The first volume of the GS/OS Reference published by Addison-Wesley (a PDF can be found at http://www.brutaldeluxe.fr/documentation/apda/apple_appleiigs_gsosreference.pdf) covers the application-level APIs but the planned second volume (which would have been titled GS/OS Device Driver Reference) that would have covered writing device drivers was never published. (Addison-Wesley didn't think there was enough interest in the GS by that time. Unfortunately they were probably right.)

The APDA draft version of the GS/OS reference did include much of that information though. (It's also in two volumes, but organized differently from what was published. The device driver stuff is mostly in volume 2.)

APDA GS/OS draft reference volume 1: http://www.brutaldeluxe.fr/documentation/apda/apda_gsosreference_volume1_betadraft_19880831_k2s023_ocr.pdf
APDA GS/OS draft reference volume 2: http://www.brutaldeluxe.fr/documentation/apda/apda_gsosreference_volume2_draft_19890131_a0008lla_ocr.pdf

Brutal Deluxe has collected some additional information about GS/OS internals here: http://www.brutaldeluxe.fr/documentation/gsos/Apple_IIgs_GSOS_internals_v1.pdf (although I think most of that is only needed if you want to write FSTs or otherwise poke around in the part of GS/OS that weren't officially documented.)


You may also want to look through the GS/OS Tech Notes and the System 6 (and 6.0.1) documentation as there are various corrections and changes in there:

* https://apple2online.com/web_documents/gsos_technical_notes.pdf

Tech note #6 in particular has some very important corrections.

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

#42212

On Thursday, March 21, 2019 at 4:21:02 PM UTC-5, Tim Buchheim wrote:
> The first volume of the GS/OS Reference published by Addison-Wesley (a PDF can be found at http://www.brutaldeluxe.fr/documentation/apda/apple_appleiigs_gsosreference.pdf) covers the application-level APIs but the planned second volume (which would have been titled GS/OS Device Driver Reference) that would have covered writing device drivers was never published. (Addison-Wesley didn't think there was enough interest in the GS by that time. Unfortunately they were probably right.)
> 
> The APDA draft version of the GS/OS reference did include much of that information though. (It's also in two volumes, but organized differently from what was published. The device driver stuff is mostly in volume 2.)

There actually was a final version of the GS/OS Device Driver Reference put out, although it was done through APDA rather than published by Addison-Wesley. That’s available along with a lot of other IIgs programming docs at:

https://drive.google.com/drive/folders/19r4nKhrpnq48rLhglke73Ovp33E9_xKr

(The GS/OS stuff is under Documentation > GS/OS.)

-- 
Stephen Heumann

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

#42216

Ah, these Brutal Deluxe guys should make things clearer...

Use the Google drive link for the latest beta/final versions of the different docs.

Zorro

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

#42220

On Thursday, March 21, 2019 at 5:57:27 PM UTC-5, Stephen Heumann wrote:
> On Thursday, March 21, 2019 at 4:21:02 PM UTC-5, Tim Buchheim wrote:
> > The first volume of the GS/OS Reference published by Addison-Wesley (a PDF can be found at http://www.brutaldeluxe.fr/documentation/apda/apple_appleiigs_gsosreference.pdf) covers the application-level APIs but the planned second volume (which would have been titled GS/OS Device Driver Reference) that would have covered writing device drivers was never published. (Addison-Wesley didn't think there was enough interest in the GS by that time. Unfortunately they were probably right.)
> > 
> > The APDA draft version of the GS/OS reference did include much of that information though. (It's also in two volumes, but organized differently from what was published. The device driver stuff is mostly in volume 2.)
> 
> There actually was a final version of the GS/OS Device Driver Reference put out, although it was done through APDA rather than published by Addison-Wesley. That’s available along with a lot of other IIgs programming docs at:
> 
> https://drive.google.com/drive/folders/19r4nKhrpnq48rLhglke73Ovp33E9_xKr
> 
> (The GS/OS stuff is under Documentation > GS/OS.)
> 
> -- 
> Stephen Heumann



So I skimmed through the Apple IIGS GS/OS Driver Reference (https://drive.google.com/drive/folders/1YYzYACYT9k8sqmz2wEOyJ1shdyaBVRsI)... it has a great deal of information about the architecture... but I'm still a little hazy on what exactly I would need to implement.  The GS/OS device driver architecture is *complicated*.  You don't just have device drivers, you've got supervisory drivers, and device dispatchers, and explicitly loaded drivers, and generated drivers... holy smokes.

Here's what I *think* I need to build.

1) Needs to be a block driver.
2) Needs to be a loaded driver.
3) Probably needs to be a true device driver (as opposed to a supervisory driver).
4) Needs to have all the required entry points specified in the document above (DInfo, DStatus, DControl, DRead, DWrite, and DRename?)
5) Might have to interact with the SCC manager (how? who knows.) to do the serial interactions

What would be really nice would be a skeletal block device driver that does nothing.... like just returns the same block when asked for anything.... ideally implemented in C, but at this point I'd take assembler.  I'm really fuzzy on how the FST's interact with the device drivers.  Somehow it has to be facilitated by the data returned when the entry points are invoked.  The book doesn't give any code examples from what I can tell... which is disappointing, but sort of par for the course for OS documentation of the era -- big on architecture, small on implementation details.  (The "architects don't code" era.)

I found this:  https://github.com/byteworksinc

...which appears to be a compiler I could use, a linker, an assembler, and a utility that would allow me to dump IIGS objects... so maybe I could dump an existing device driver like the 3.5 disk driver or something...

Interestingly enough, it sure looks like there might be another route.... There's something called "the ProDOS Filing Interface", which the AppleTalk Filing Protocol uses.  It *appears* that if you wrote a version of the ProDOS Filing Interface (which I think is 8-bit code) that interacted with the modem port and talked to ADTPro, you'd get the equivalent of an Apple Talk file share.

I suppose it would be too much to ask for someone to have built a virtual machine somewhere that already is set up to do IIGS code compilation?  Anyone?  Anyone?  Bueller?

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

#42232

On 2019-03-22 14:04:42 +0000, J R said:
> So I skimmed through the Apple IIGS GS/OS Driver Reference 
> (https://drive.google.com/drive/folders/1YYzYACYT9k8sqmz2wEOyJ1shdyaBVRsI)... 
> it has a great deal of information about the architecture... but I'm 
> still a little hazy on what exactly I would need to implement.  The 
> GS/OS device driver architecture is *complicated*.  You don't just have 
> device drivers, you've got supervisory drivers, and device dispatchers, 
> and explicitly loaded drivers, and generated drivers... holy smokes.

It is pretty complicated, but you don't have to deal with all the 
complexity to write a basic block device driver. A good first step is 
to figure out what you actually need to do, and it looks like you've 
already made some progress on that.

> Here's what I *think* I need to build.
> 
> 1) Needs to be a block driver.
> 2) Needs to be a loaded driver.
> 3) Probably needs to be a true device driver (as opposed to a 
> supervisory driver).
> 4) Needs to have all the required entry points specified in the 
> document above (DInfo, DStatus, DControl, DRead, DWrite, and DRename?)
> 5) Might have to interact with the SCC manager (how? who knows.) to do 
> the serial interactions

I think points 1-3 are correct. For point 4, what a driver actually 
implements are the driver calls documented in Chapter 10 of the GS/OS 
Device Driver Reference (Driver_Read, etc.). The GS/OS device-level 
calls like DRead are called by applications and basically act as 
wrappers around these calls, dispatching to the appropriate driver.

The SCC Manager is mainly concerned with using the SCC chip for 
AppleTalk networking, so I doubt your driver would really interact with 
it, beyond maybe telling it that your driver is using a serial port. 
Accessing the serial ports on the IIgs is a significant issue in its 
own right (particularly if you want high speeds), but I'm not deeply 
familiar with it.

> What would be really nice would be a skeletal block device driver that 
> does nothing.... like just returns the same block when asked for 
> anything.... ideally implemented in C, but at this point I'd take 
> assembler.

GS/OS was designed with the idea that drivers would be written in 
assembly, and AFAIK pretty much all drivers were written that way. It 
is actually possible to write them largely in C, but it requires some 
assembly glue code, and you need to have a good understanding of things 
like the C compiler's calling convention. I think it would likely be 
easier for your purposes to just use assembly, but let me know if you 
really want to use C. I actually have some unreleased code that I might 
be able to share for that.

See below for links to several samples of driver code (in assembly language).

> I'm really fuzzy on how the FST's interact with the device drivers.  
> Somehow it has to be facilitated by the data returned when the entry 
> points are invoked.

They call the internal GS/OS system service call DEV_DISPATCHER 
(documented in the Brutal Deluxe GS/OS Internals book), which 
dispatches to the various driver calls implemented by each driver to 
read/write blocks, etc.

Both FSTs and drivers also deal with the GS/OS caching system. It's 
documented in the GS/OS Device Driver Reference and a couple tech 
notes, but it can be kind of confusing. There's an article on it called 
"Demystifying The GS/OS Cache," which may be helpful:
http://preserve.mactech.com/articles/develop/issue_02/Apple_IIGS.html
(At least when first developing your driver, though, you can simplify 
things by just not using the cache.)

> The book doesn't give any code examples from what I can tell... which 
> is disappointing, but sort of par for the course for OS documentation 
> of the era -- big on architecture, small on implementation details.  
> (The "architects don't code" era.)

The GS/OS Reference Volume 2 draft versions actually do include sample 
driver code in an appendix, so you can look at those. Here are the 
other examples of GS/OS driver code that I'm aware of:

Apple made the code for its SCSI drivers available as sample code. This 
is quite complex, but it gives an example of an actual driver from 
GS/OS. It's available on the Golden Orchard/Golden Grail CD 
(http://digisoft.callapple.org/golden_orchard/) under 
Programming/Apple/System 6.0 Sample Code/SCSI.Drivers.

There's driver code for an old version of the CFFA card available here:
http://www.lyons42.com/CFFA/GSDriver/SourceCode/
This was written by Dave Lyons, who was one of the GS/OS developers.

MountIt by Brutal Deluxe acts as a driver allowing you to mount disk 
images. The downloads include the code (in Merlin format):
http://www.brutaldeluxe.fr/products/apple2gs/mountit.html
Note that this dynamically installs the driver when it is invoked, 
rather than being a normal driver file that gets loaded and installed 
at boot time. The process for this is documented in the GS/OS Internals 
book, but the basic way a driver works is essentially the same in 
either case.

> I found this:  https://github.com/byteworksinc
> 
> ...which appears to be a compiler I could use, a linker, an assembler, 
> and a utility that would allow me to dump IIGS objects... so maybe I 
> could dump an existing device driver like the 3.5 disk driver or 
> something...

The ORCA assembler/compilers/environment are a very good option for 
IIgs development. Note that only updates to some of the ORCA programs 
are on GitHub. The full versions are still commercially available in 
the Opus ][ collection sold by Juiced.GS (very much worth the price, 
IMO). Juiced.GS also sells Golden Gate, which allow you to run the ORCA 
assembler/compiler/utilities as cross-development tools on modern 
platforms. See here for both of them:
https://juiced.gs/store/category/software/

The other assemblers targeting the IIgs are also viable options. Apple 
used the MPW IIgs assembler for its own development, and Merlin (on the 
IIgs, or the Merlin 32 cross assembler) could certainly also be used. 
If you really want to use C, though, I'd definitely recommend using 
ORCA/C along with ORCA/M for glue code.

> Interestingly enough, it sure looks like there might be another 
> route.... There's something called "the ProDOS Filing Interface", which 
> the AppleTalk Filing Protocol uses.  It *appears* that if you wrote a 
> version of the ProDOS Filing Interface (which I think is 8-bit code) 
> that interacted with the modem port and talked to ADTPro, you'd get the 
> equivalent of an Apple Talk file share.

I don't think this is the right way to go. The AppleTalk networking 
stack on the IIgs is a complex collection of components in its own 
right (in addition to interacting with GS/OS), and it wasn't designed 
for what you're trying to do. For one thing, PFI is largely but not 
completely bypassed in favor of the AppleShare FST when running GS/OS.

> I suppose it would be too much to ask for someone to have built a 
> virtual machine somewhere that already is set up to do IIGS code 
> compilation?  Anyone?  Anyone?  Bueller?

Opus ][ includes a disk image with a preinstalled copy of all the ORCA 
programs that you can use in an emulator, although you'd still need a 
separate boot disk image.  Also, Golden Gate is essentially a 
specialized emulator designed for running development tools.

-- 
Stephen Heumann

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

#42223

On 3/21/19 4:32 PM, J R wrote:
> I'm a software engineer, and while I was able to get my IIGS to boot with ADTPro and a null modem cable, and I was able to create GSOS boot disks, I was thinking about VSDRIVE.  It*appears*  that you can't use VSDRIVE with GSOS, because although I can install it before booting GSOS, when GSOS runs, it doesn't find the virtual drives.  My guess is that VSDRIVE only works in 8-bit mode or something.... not really sure.  (If someone knows definitively what's going on, that would be appreciated).

The code I used to learn how to poke at the SCC is here:
http://www.apple2.org.za/gswv/a2zine/Utils/Z8530_SCCsamples_info.txt
It has some cautionary tales in there about how to interact with the 
serial port in a running system - sharing interrupts and whatnot.  The 
ADTPro serial layer plays fast and loose with the hardware, and takes 
full advantage of the fact that it's the only game in town - which would 
definitely not be the case if it were running under GSOS.  Even running 
ADTPro as a ProDOS 8 app shelled out of GSOS fails because it doesn't 
get all the time it needs with the SCC hardware; too many interrupts are 
stolen.

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

#42225

On Friday, March 22, 2019 at 10:57:46 AM UTC-5, schmidtd wrote:
> On 3/21/19 4:32 PM, J R wrote:
> > I'm a software engineer, and while I was able to get my IIGS to boot with ADTPro and a null modem cable, and I was able to create GSOS boot disks, I was thinking about VSDRIVE.  It*appears*  that you can't use VSDRIVE with GSOS, because although I can install it before booting GSOS, when GSOS runs, it doesn't find the virtual drives.  My guess is that VSDRIVE only works in 8-bit mode or something.... not really sure.  (If someone knows definitively what's going on, that would be appreciated).
> 
> The code I used to learn how to poke at the SCC is here:
> http://www.apple2.org.za/gswv/a2zine/Utils/Z8530_SCCsamples_info.txt
> It has some cautionary tales in there about how to interact with the 
> serial port in a running system - sharing interrupts and whatnot.  The 
> ADTPro serial layer plays fast and loose with the hardware, and takes 
> full advantage of the fact that it's the only game in town - which would 
> definitely not be the case if it were running under GSOS.  Even running 
> ADTPro as a ProDOS 8 app shelled out of GSOS fails because it doesn't 
> get all the time it needs with the SCC hardware; too many interrupts are 
> stolen.

So that's useful.  Maybe what I need to do is break the problem in half.  Maybe I should just write some little utility that talks to the ADTPro server over the null modem cable from inside GSOS, and once I have that half figured out I could pivot to writing a device driver.

What's the quickest way to get a build environment set up?  Any idea?

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

#42226

On 3/22/19 12:23 PM, J R wrote:
> On Friday, March 22, 2019 at 10:57:46 AM UTC-5, schmidtd wrote:
>> On 3/21/19 4:32 PM, J R wrote:
>>> I'm a software engineer, and while I was able to get my IIGS to boot with ADTPro and a null modem cable, and I was able to create GSOS boot disks, I was thinking about VSDRIVE.  It*appears*  that you can't use VSDRIVE with GSOS, because although I can install it before booting GSOS, when GSOS runs, it doesn't find the virtual drives.  My guess is that VSDRIVE only works in 8-bit mode or something.... not really sure.  (If someone knows definitively what's going on, that would be appreciated).
>>
>> The code I used to learn how to poke at the SCC is here:
>> http://www.apple2.org.za/gswv/a2zine/Utils/Z8530_SCCsamples_info.txt
>> It has some cautionary tales in there about how to interact with the
>> serial port in a running system - sharing interrupts and whatnot.  The
>> ADTPro serial layer plays fast and loose with the hardware, and takes
>> full advantage of the fact that it's the only game in town - which would
>> definitely not be the case if it were running under GSOS.  Even running
>> ADTPro as a ProDOS 8 app shelled out of GSOS fails because it doesn't
>> get all the time it needs with the SCC hardware; too many interrupts are
>> stolen.
> 
> So that's useful.  Maybe what I need to do is break the problem in half.  Maybe I should just write some little utility that talks to the ADTPro server over the null modem cable from inside GSOS, and once I have that half figured out I could pivot to writing a device driver.

That sounds exactly right.

> What's the quickest way to get a build environment set up?  Any idea?

That's a religious question you've asked, there.  But since you're 
targeting GSOS, it probably makes sense to look towards 
cross-development with Merlin32:
http://www.brutaldeluxe.fr/products/crossdevtools/merlin/

[toc] | [prev] | [standalone]

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

csiph-web