Re: Virtual serial drive

[BLuRry <brendan.robert@gmail.com>]

On Tuesday, September 4, 2012 12:40:01 PM UTC-5, schmidtd wrote:
> On 9/4/2012 12:27 PM, David Schmidt wrote:
> 
> > On 9/4/2012 11:59 AM, BLuRry wrote:
> 
> >> On Tuesday, September 4, 2012 6:28:34 AM UTC-5, schmidtd wrote:
> 
> >>> On 9/4/2012 4:46 AM, Ric wrote:> I try on my //c 255 rom but don't work
> 
> >>> right.
> 
> >>>
> 
> >>>   > Should be rewrite serial card subroutine on file SERIAL.DRIVE
> 
> >>>   > The command dos is Apple2VirtualDrive COM1 disk.hdv
> 
> >>>
> 
> >>> It won't work on a IIc because it is currently hard-coded to talk to the
> 
> >>> GS serial hardware.  I've got the serial code isolated and bolted the
> 
> >>> serial backend of ADTPro to it, and now it'll use whatever hardware is
> 
> >>> supported by that.  But I still have to get the driver to attach to
> 
> >>> ProDOS correctly - I'm reading the Beyond ProDOS book for that now.
> 
> >>
> 
> >> That's a pretty easy problem to fix!
> 
> >
> 
> > The 'problem' isn't the comms - I'm pretty solid on that - the problem
> 
> > is cleanly interfacing to the P8 driver model.  I expect that a "hello
> 
> > world" message from the driver's entry point that is fed to DEVADR21 (he
> 
> > calls it DEV2S1) should produce that message when doing a CAT,S2,D1 -
> 
> > but it crashes instead.
> 
> >
> 
> > The initialization code doesn't quite look complete to me, or at least
> 
> > my translation to ca65 didn't come across quite right:
> 
> >
> 
> > ; ADD POINTER TO DRIVER
> 
> >      LDA    #<DRIVER
> 
> >      STA    DEV2S1
> 
> >      LDA    #>DRIVER
> 
> >      STA    DEV2S1+1
> 
> > ; ADD TO DEVICE LIST
> 
> >      INC    DEVCNT
> 
> >      LDY    DEVCNT
> 
> >      LDA    #$20 ; SLOT 2 DRIVE 1
> 
> >      STA    DEVLST,Y
> 
> >      RTS
> 
> >
> 
> > Where "DRIVER" is the entry point to the block driver command processor.
> 
> >   Terence had only stored a value at DEV2S1+1, which can't be right...
> 
> 
> 
> Ah, never mind.  I had it right after all.  I just needed to remember 
> 
> what environment I was in when the driver code is called... ROM is 
> 
> switched out, so calling COUT (among other things) was doomed.  ;-)

I figured you knew how to do the com stuff, as it is far from your first rodeo.  I just posted that code for posterity in case anyone wanted to see the comparison.  Hooking into the prodos drivers can be tricky, I remember seeing others overwrite the disk routines to make room for alternate drivers but there's probably a much cleaner way to do it.  The advantage of overtaking the disk routines is that you have more room to add stuff like error checking and retry logic.

-B