This is a set of notes on the modules/devices that go together for different areas of drivewire (DW) support that I might want to provide in the mc09 ports.

TODO: go through this and correlate what's in Level 1 and what's in Level 2.

The Drivewire spec. calls for 1 start + 8 data + 1 stop and that 115,200bps is a supported speed. The mc09 UART is hard-wired for 1 start + 8 data + 1 stop -- and the default configuration runs at 115,200bps.

In summary, the mc09 hardware is all ready to go!

rbdw

rbdw.dr provides disk access. Code in level1/modules/rbdw.asm, "use"s defs and dwcheck.asm device descriptors built from dwdesc.asm: ddx0.dd x0.dd x1.dd x2.dd x3.dd common code for L1 and L2.

depends on (links to) module "dwio" which can be provided by one of the following: dwio.asm dwiomess.asm

dwio.asm "use"s defs and dwread.asm, dwwrite.asm dwinit.asm do not want to fork dwio.asm - could put my code in dwread/write/init or new files??

scdwp

scdwp provides printer support. Code in level1/modules/scdwp.asm, "use"s defs. device descriptor built from p_scdwp.asm: p_scdwp.dd common code for L1 and L2.

depends on (links to) module "dwio" as before. Therefore, should "come for free"

scdwv

scdwv provides virtual terminal. Code in level1/modules/scdwv.asm, "use"s defs. all the device descriptors below are built from scdwvdesc.asm:

term_scdwv.dt -- used for ?? n_scdwv.dd n[1..13]_scdwv.dd -- used to communicate using TELNET via a port exposed on the host. midi_scdwv.dd -- used for ?? term_z_scdwv.dt z[1..7]_scdwv.dt -- used to communicate with virtual terminals on the host. common code for L1 and L2.

depends on (links to) module "dwio" as before. Therefore, should "come for free"

clock2_dw

clock2_dw provides a (one-time?) initialisation of the time from the DW server. It's only part 2 of the clock stuff, so it doesn't replace the timer interrupt stuff in clock. common code for L1 and L2.

depends on (links to) module "dwio" as before. Therefore, should "come for free"

General

Notes from Kip:

Looking at the output of the mdir command in VCC using the Becker version of NitrOS-9, the modules required to access Drivewire 4 drives involves rbf, rbdw, dwio and the descriptors x1, x2, x3 and if the boot disk boots off of a Drivewire drive then dd is the default boot drive which in this case would be x0 renamed to dd. Evidently since rbdw and scdwv link to dwio, I would expect dwio actually does the serial communications via the bigbanger serial I/O port on the Coco.

The RS-232 serial I/O port on the back of the Coco is used for all Drivewire communications thus far. It is driven in bitbanger fashion by a 6821 PIA I believe at $FF20-$FF23 I think. In the Multicomp the serial ports are of course driven by the 6850 as it should be. The thing that is interesting to me is we could make the serial port baud rate in the Multicomp as fast as we want it within the limits of the FPGA of course. I have a couple of Dell PCs with a serial port baud rate in excess of 921,000 baud if memory serves. Up to this point using Driverwire, I have only experienced speeds up to a maximum of 115,200 baud.

The modules scf, dwio and scdwv and the descriptors z1, z2, z3, z4, etc. are used to communicate with virtual terminals on the PC.

The modules scf and scdwv along with the descriptors n, n1, n2, n3, n4, etc. are used to provide a communications path for the telnet protocol and the program telnet.

The module rbdw is a random block file driver and the module scdwv is a serial character file driver. Inetd is used with other previously mentioned modules and descriptors to connect the coco/vcc to the internet via telnet.

The module scdwp, p_scdwp.dd implements a printer driver through Drivewire 4. I think this is about all the modules that communicate with Drivewire.