[Coco] CocoNIC

[Brett Gordon]

On Sat, Sep 17, 2016 at 10:24 PM, RETRO Innovations <go4retro at go4retro.com>
wrote:

> On 9/17/2016 3:46 AM, Brett Gordon wrote:
>
>> Jim, I took Barry to mean just that: drivewire over tcp. So the stack
>> would
>> be like this:
>>
>> Hdbdos
>> drivewire
>> tcp
>> ip
>> ethernet
>> coconic
>> (Ancillary needed protocols: arp, and maybe dhcp)
>>
> Understood, but drivewire is a "stream" protocol, while tcp/ip is mainly a
> "packet" protocol.


IP is a packet protocol.  TCP sits atop IP to make the packets look like a
stream.  Aaron's DW server already speaks TCP (the emulators use it that
way), DW also sits on the serial port of course - and that's definately a
stream :)



> And, HDBDOS is probably a packet protocol.  The double conv makes life
> more difficult.
>
>
HDBDOS is really just function calls (and an odd sort of interface, anyway)



> HDBDOS:  save sector 5
> DRIVEWIRE: <save sector>
>                       <5>
>                        <0> number of bytes in lo/hi format.
>                       <1>
>                        <byte 0>
>                     <byte 1>
>                      ...
>                      <byte 255>  (I am making some assumptions on DW, but
> it has to be something like that...
>

Yeah, it's pretty much that simple.  Drivewire is very similar to SCSI
actually, or even IDE. Boisy was clever enough to understand that because
of the serial port limitations of the coco, that it needed to be
"transactional"...  a synchronous remote procedure call, really.

so it's something like this:

CoCo: hey DW server: load sector 5 to address ......
CoCo then sits and waits for an answer  <--- the synchronous part
DW server:  OK.. found the sector and here's the data.....

and the DW server never sends anything to the CoCo without the CoCo
expecting it. So it's a CoCo driven protocol.



>
> In essence, I think the code under DW will have to parse DW commands to
> know what to do, even if it just passes the data off to a DW server,
> because it has to know when it is OK to send a packet (so it has to parse
> the commands to get the length).  It seems easier to just hook the HDBDOS
> commands directly as a peer of DW.
>
> JIm
>
>
> So what Barry's suggesting is mostly a software thing.  Here's the fun
>> part:  Hdbdos is out of ROM space and RAM space... banking is a solution
>> to
>> ROM.  the lack of RAM may be a harder nut to crack.
>>
> Well, if your RAM needs are modest, I just picked up some 32kB SRAM for a
> price that will only add $1.50 to the design.  But, it's not 128kB :-)
>
> I did not realize HDBDOS is out of space.


It depends on which flavor of disk driver, but yeah... it's nearly full.
RAM-wise, BASIC itself is just about out of RAM too.  I was able to squeeze
46 more bytes for my YA-DOS, but I had to fidget with the RAM map.  There's
some other solutions but software compatibility would start to suffer.  32K
of RAM would probably work:  The C code of uIP requires 1 packet buffer,
and a few dozen bytes for the ARP table.  The packet buffer should be at
least 576 bytes (per IP standards), or even 1500 bytes (per ethernet
standards).


>
>
>> Given your c64 experience, and our quite smaller pool of programmers, I
>> wouldn't do more on the hardware end until our programmers *prove* they
>> can
>> hold up their part of the bargain! :)
>>
> Hehe.  Well, I don't want to sound demanding, just noting that I really am
> at a disadvantage as a 6809 programmer.
>
>
lol... yes.. I agree:

Software without Hardware = useless mind experiments.
Hardware without Software = useless physical crap.

:)


For now, I say we go slow, and work in baby steps.  Let me get Fuzix
working with the card.  Then I'll do up a stand-alone library designed for
assembler, given my time.  Maybe John Linville has the chops for an ASM
stack.


Here's a brain warper (but nothing new in the networking world) :  William
Astle's "LWWire" is the DW server I'm using to get networking working now,
as it allows for a packet interface.   Using the tcp/ip stack, it should be
possible to connect via uIP via LWWire to another drivewire server (it
speaks TCP, right?)... so on and so forth.  "It's turtles all the way
down", as the joke goes.  This concept is called "tunneling". The DW just
becomes something eerily similar to SMB or NFS :)

 -brett