[Coco] os9/drivewire driver problems
Aaron Wolfe
aawolfe at gmail.com
Sun Nov 8 19:20:20 EST 2009
On Sun, Nov 8, 2009 at 5:46 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> Thanks for the response Boisy. Your name is becoming a very common
> sight on my screen as I look through the NitrOS9 and drivewire
> modules.. is there anything you didn't write or improve? :)
>
> I tried removing the A from the PULS but got the same results. I am
> failing to understand something about how the data is returned from
> the DWSUB to the calling routine. The reason I was pulling A, was I
> thought the byte read by DWSUB,READ would be on the stack.. because I
> thought I was putting a pointer to my stack in X prior to calling
> DWSUB. But I must be getting this wrong, either in concept or
> implementation. I apologize, my assembler skill was never very good
> and I'm very rusty. Trying to learn as I go here.
>
> What is the proper way to get 1 byte of data from DWSUB into A? I see
> that when the rbfdw driver reads in a block, it puts a pointer to
> PD.BUF in X prior to the read call, I am guessing this is where OS9
> expects the block to be returned.
>
> * Get 256 bytes of sector data
> ldx 5,s
> ldx PD.BUF,x get buffer pointer into X
> ldy #$0100
> jsr 3,u
>
> when the clock2_dw gets time, I see:
>
> ldx #D.Year
> ldy #$0005
> jsr 3,u
>
> So X is the constant D.Year, $53 from the coco OS9Defs file, I am
> guessing this is writing the returned bytes directly into OS9's "whats
> the current time" area?
>
> Eventually I'd like to read a variable amount of data from the server,
> but for now I am trying to just get one character at a time (the
> server additions I've made have a buffer that can make this work sort
> of OK).
> So.. if I just want to get one byte into the A register.. can anyone
> point out where my code or comments are wrong? I'm sure I'm
> misunderstanding something. I've found what I think are some other
> problems in my code, but still I get the same behavior, constant calls
> back and forth to read and write with null results.
> Current attempt:
>
> Read equ *
> lda #OP_SERREAD ; put opcode for read in A
> pshs a ; put A on stack
> leax ,s ; put pointer to top of stack in X
> ldy #$0001 ; put 1 in Y because we want to send 1 byte
> ldu >D.DWSUB ; put addr of DWSUB in U
> jsr 6,u ; call write routine, it should send one byte to
> server asking for a character
> * puls a ; was removing it, but I think I need to leave a
> byte there so we have room for incoming byte and don't clobber other
> contents?
> ldy #$0001 ; we want to read 1 byte back
> leax ,s ; and put it on our stack, in place of A/the opcode
> used in previous call
> jsr 3,u ; call DWSUB to read 1 byte
> puls a,pc ; pull that byte and the pc off stack (pc now sends
> us back to calling routine?)
>
I just did a bit of an experiment, returning the byte sent by the
server as the error code (in B) instead of the data in A. This works
great, I get error #X where X is whatever value the server sends..
Read equ *
lda #OP_SERREAD
pshs a
leax ,s
ldy #$0001
ldu >D.DWSUB
jsr 6,u
ldy #$0001
leax ,s
jsr 3,u
lda #$FF ; cause cc to be set
adda #$01 ;
puls b,pc ; return character from DW as error #
So this technique *is* getting the byte from the server. Yet when I
return the same byte in A, with no error... I get strangeness.
What I thought was the shell echoing characters might be something
else, because when I do something like: LIST /T2
which I think should just read from /T2 until EOF (which is not going
to happen, but whatever).. instead I get the same cycle of READ/WRITE
requests to the driver. Why would I get a write request at all here?
I think I am actually getting the bytes from DW, so what I thought was
my problem isn't really the problem.. somehow I am not implementing
or understanding something.. thats about as specific as I can get :)
thanks for any advice, I'm reading through everything I can find on
scf device drivers and not finding the clue so far.
> I am guessing the address I'm supposed to return to is already on the
> stack when Read gets called? Lots of example seem to pull PC of the
> stack when they are ready to return but I haven't found where this is
> documented so not entirely sure.
>
> Well.. something is wrong with my code, any clues are much appreciated.
> -Aaron
>
>
>
> On Sun, Nov 8, 2009 at 8:37 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
>>
>> On Nov 8, 2009, at 5:58 AM, Aaron Wolfe wrote:
>>
>>> First, please don't laugh, I am new and surely making many simple mistakes
>>> here.
>>> Second, I cannot say thank you enough to everyone who has made
>>> NitrOS9, the toolshed and drivewire possible. I'm very impressed by
>>> how well the tools work.
>>
>> I think it's awesome that someone is taking the reigns and doing something
>> like this. Good going.
>>
>>> I am trying to add to drivewire the ability to act as a serial port
>>> under NitrOS9. I've managed to setup a build environment and create a
>>> device descriptor and driver for the new device. I added the op codes
>>> and handling routines on the server side, etc. I have write working,
>>> but that's the easy part since the dw printer driver already did that
>>> and I mostly just copied it.
>>>
>>> So, I can do things like: LIST STARTUP > /T2
>>> and everything works great.
>>
>> Good so far.
>>
>>> However, read is another story. I can't seem to get anything working
>>> properly and after several hours I am stumped.
>>>
>>> Here's what I think I've figured out about how dw works, I might have
>>> some things wrong.
>>> To read a character, I think I am supposed to put my opcode in A,
>>> pointer for the incoming data in X (usually my stack, i think?), the
>>> number of bytes to read in Y.
>>> Then, jsr to the DWSUB and let the magic happen? At least this is
>>> what I think I've gleaned from the source of other modules.
>>> According to the OS9 dev manual, the Read routine should return a
>>> character in reg A.
>>
>> This all sounds correct.
>>
>>> So, my first attempt was:
>>>
>>> Read
>>> lda #OP_SERREAD
>>> pshs d
>>> leax ,s
>>> ldy #$0001
>>> ldu >D.DWSUB
>>> jsr 6,u
>>> ldy #$0001
>>> leax ,s
>>> jsr 3,u
>>> puls d,a,pc
>>>
>>> I may be doing stupid things here, I haven't done 6809 assembler in
>>> many years. I'm not sure what the 6, and 3, in the JSRs is for, it
>>> seems like every write uses 6 and read uses 3 in the other modules.. ?
>>
>> the jsr 6,u says: "save the address of the next instruction on the stack,
>> then obtain the two byte location 6 bytes from the U register and jump to
>> that location." The 6 jumps into the WRITE section of the DWSUB routine,
>> and the 3 jumps into the READ routine.
>>
>>> This "works" in the sense that the server sees the call and sends back
>>> a byte. However, I've botched something because the process calling
>>> read always gets a null character. If I spawn a shell on /T2, it
>>> reads and writes bytes constantly (I think it's echoing the character
>>> it thinks I typed) but its all null chars.
>>
>> Your last line needs to read: puls d,pc
>>
>> You don't want to pull A off the stack because you haven't pushed it on
>> prior to the call. I think you will find that it works after that.
>>
>> Note that you should be checking for a timeout error after the jsr 3,u and
>> load B with an error if so, but get this working first.
>>
>>> So, I thought to test I would just:
>>>
>>> Read
>>> lda #OP_SERREAD
>>> clrb
>>>
>>> (#OP_SERREAD is the character 'C'). I was hoping then that something
>>> like LIST /T2 would give me a stream of Cs. But instead I get Error
>>> 208, Illegal service request.
>>
>> Error #208 is an illegal service request. I suspect you aren't implementing
>> something in your getstat or setstat routine; I don't remember the exact
>> issue here, and I'm not at my CoCo at the moment to test this out and
>> remember.
>>
>> Try the fix above with your shell test and see if something happens. Let us
>> know.
>>
>>
>>> Hopefully this makes some kind of sense, I'm sure I've done something
>>> silly but if I make Read just put a constant in A and clear B (no
>>> errors), shouldn't I get a character every time I call Read?
>>
>>
>>> Thanks for any pointers
>>> -Aaron
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
More information about the Coco
mailing list