[Coco] DWTCPDevice cannot be cast to DWSerialDevice

[Gene Heskett]

On Monday 17 November 2014 12:46:24 Aaron Wolfe did opine
And Gene did reply:
> The /n devices don't need iniz.  These act like /t devices (serial
> ports) in most ways.  They open in command mode, much like a /t serial
> port with a modem attached. In fact you can send standard Hayes AT
> commands to them in addition to the various other options.
> 
> The /z devices are a bit different as they are intended as OS9 style
> windows.  They need to act like the /w devices which do use the iniz
> step. This sends some initial parameters like what screen mode to use
> iirc.  This initialization sequence is used by DW to detect that you
> want a window and set it up.  If the device doesn't get this sequence,
> it will be confused.
> 
Ok, coco rebooted, server log cleared.
iniz /z1, prompt come back quickly, no response from the server according 
to the log

shell i=/z1 &
&003

Now no log from the server.  And no window. Remounted the dsk in drive 
/x0, logged that ok.

Now, this was logged when I last started dw: but hasn't been updated 
since:

Warning: NineServer port already in use.  Is another DW4UI running?
console.error: privacybadgerfirefox: 
  Policy document request to https://u.openx.net/.well-known/dnt-
policy.txt returned with status 404
console.error: privacybadgerfirefox: 
  Policy document request to https://ads.rubiconproject.com/.well-
known/dnt-policy.txt returned with status 404

I just disabled the privacy badger in the firefox extensions.  And 
rechecked for a new version, but nothing more was logged on that consoles 
screen.

what is this NineServer?  Usually I get that when the lock file is still 
there and the coco can't see it, and have to kill it all, nuke the 
lockfile & then restart it.


> If iniz isn't doing what you need, you can send the parameters directly
> with the 'display' utility.
> 
> You can see this in the demo of nineserver here:
> 
> http://
> <http://youtu.be/7C-QvdX2bNQ?list=UU-yqT9jllCdOqKyl3_exwug>youtu.be
> <http://youtu.be/7C-QvdX2bNQ?list=UU-yqT9jllCdOqKyl3_exwug>/7C-
> <http://youtu.be/7C-QvdX2bNQ?list=UU-yqT9jllCdOqKyl3_exwug>QvdX2bNQ
> <http://youtu.be/7C-QvdX2bNQ?list=UU-yqT9jllCdOqKyl3_exwug>?list=
> <http://youtu.be/7C-QvdX2bNQ?list=UU-yqT9jllCdOqKyl3_exwug>UU-
> <http://youtu.be/7C-QvdX2bNQ?list=UU-yqT9jllCdOqKyl3_exwug>yqT9jllCdOq
> Kyl3 <http://youtu.be/7C-QvdX2bNQ?list=UU-yqT9jllCdOqKyl3_exwug>_
> <http://youtu.be/7C-QvdX2bNQ?list=UU-yqT9jllCdOqKyl3_exwug>exwug
> <http://youtu.be/7C-QvdX2bNQ?list=UU-yqT9jllCdOqKyl3_exwug>
> 
> However, note that in the video I used /n devices, which at that time
> were overloaded with both /t and /w type functionality.  We later
> changed to separate descriptors (/zX) for the windows because they
> have some unique needs and OS9 needs to inherently know from the
> beginning that these are to be window devices.
> 
>  On Nov 17, 2014 12:19 PM, "Gene Heskett" <gheskett at wdtv.com> wrote:
> > On Monday 17 November 2014 11:51:22 Aaron Wolfe did opine
> > 
> > And Gene did reply:
> > > On Nov 17, 2014 11:03 AM, "Gene Heskett" <gheskett at wdtv.com> wrote:
> > > > I wasn't aware that could be done from a terminal on the coco3,
> > > > but there I get this:
> > > > {t2|08}/DD:dw se st
> > > 
> > > > DriveWire version 4.3.3o (06/21/2013) status:
> > > There are many, many useful DW commands that can be entered at the
> > > os9 command prompt :). In fact, you can do everything possible in
> > > the GUI right from there.  I always wanted DW to be controlled
> > > from the coco side.  The GUI that runs on a PC was a reluctant
> > > late addition.
> > > 
> > > > And regardless of whether I try to start a shell on an /n or on a
> > > > /z descriptor, the error log on the server says: (and the
> > > > numbers do not change)
> > > > 
> > > > DWVPorthand dwproto-0-10 Unknown API command:'{N1|03/DD:Error
> > > > #216 - Path Name Not Found'
> > > 
> > > This seems to be an os9 shell prompt being sent to the DW server as
> > > a command.  Obviously not what we want.  The channel needs to be
> > > in a mode that passes data before this data is sent.  What we have
> > > now is sort of like doing an xmodem upload while your modem is in
> > > AT command mode.. The DW device isn't "off hook" so its
> > > interpreting the data as a command.  I'll have to look at why this
> > > is.. Are you doing an iniz on the /Z device before sending it s
> > > shell?  That might be what puts the device into the correct mode,
> > > its been a long time.
> > 
> > No I am not, not its easy enough to test:
> > No results for .z1
> > results for /n1 after inizing /n are an error a second from the
> > server, and my terminal is locked up, so I'll have to go reboot the
> > coco.  And no screen here.
> > 
> > 
> > Cheers, Gene Heskett
> > --
> > 
> > "There are four boxes to be used in defense of liberty:
> >  soap, ballot, jury, and ammo. Please use in that order."
> > 
> > -Ed Howdershelt (Author)
> > Genes Web page <http://geneslinuxbox.net:6309/gene>
> > US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
> > 
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS