| |||||||
|
The PCShare Project PCShare (originally called the PC Remote Sharer System PCRSS) was a project of mine designed to interface Dragon computers (running the OS9 operating system) to a PC - originally running MS-DOS, finally running Windows 9x. The aim was to allow the Dragon to utilise the PC's peripherals for itself including hard drives, display, keyboard & mouse. The final version (4.1) provided the following facilities:
It also provided support for using Paul Burgin's PCDragon emulator with it.
Hardware PCShare was designed to use 8-bit parallel I/O between the two machines, in my original setup this used an ISA card in the PC with an Intel 8255 I/O chip connected to a spare User Port (an MC6821 PIA) on my expansion board. I also developed drivers to operate with the PC's parallel printer port and a (modified) Dragon printer port. However in theory it could use any reliable communications medium (the underlying communication protocol did not include any checksum data). On the PC side, this was simply accomplished by swapping in a different DLL whilst under OS9 the underlying device drivers were replaced. Software Overview The PCShare protocol is defined by my Data Interface Protocol document which describes the format of all the messages sent across the parallel link. This is accompanied by a dedicated User Manual which describes how to set the link up and deploy the software on both Windows and OS9. Windows Software The Windows software consists of a standalone executable plus DLL which implements the parallel communications protocol. Two such DLLs are provided, one for the i8255 ISA card and one for a PC parallel printer port. Download PCShare 4.1 (32-bit, final release) Software (binaries only)
Download PCShare sources. This is the last development snapshot of the source code for PCShare. This is a mixture of C/C++ and was developed using Borland C++ v5.01 however it should port across to Visual Studio (or similar) without too much effort. OS9 Software Architecture This section provides a broad overview of the software modules developed for OS9 and some of the background behind them. There is more technical information on these at the back of the User Manual.
Access to the virtual PC hosted hard drives is implemented by the new RBF driver PC_Disk. This essentially implements the read/write sector calls of the interface spec (2.1.3) and can be readily added to any running OS9 system. Multiple hard drives are supported, simply by building additional device descriptors - h0, h1, h2 etc. PCSBF is a new file manager designed to blocks of data to be sent over the PCShare link (as opposed to the single character mode of SCF). It implements the standard OS9 system calls open, read, write, close etc. and generates the File Handling messages defined in section 2.1.1.3 of the interface spec which allow access to the host PC's file system and peripherals. The BPIA21 device driver performs the actual sending of the message over the interface & retrieval of status data which is then processed by PCSBF. Only one device descriptor is needed, the PC file system spec is simply appended to this - for example: dir /pc/d:/web_site produces a directory of the D:\Web_Site folder of the host PC. As with PC_Disk, these are standalone modules which can be loaded by any running OS9 system. The most complex component is the windrv module which replaces (on the Dragon) the kbdvdio module. Kbdvdio is responsible for the keyboard polling & console display (including the 51 column 'hi-res' mode). The 50hz IRQ vector is also handled by this module. In the early DOS versions of PCShare, the Dragon's keyboard was still used, with just the display sent to the PC's screen. This used a reverse disassmbled version of kbdvdio which had the output routines removed along with the the 6K of "hi-res" memory returned to the memory pool and pulled in a new viddrv module which implemented the write messages to the PC. When the first Windows version of PCShare (3.0) was released, windrv replaced the kbdvdio module in it's entirety and the IRQ handling code was moved to a modified ddisk module (Dragon floppy controller module). When the windrv read call was invoked from an application, it would poll issuing the Get Window Status calls (2.1.4.4) to check for any keyboard data arriving from the PC, only returning once data was available. This works fine except that because the keyboard is only polled when the read call is issued, processes can only be aborted from the keyboard if they are waiting on a keypress - ie. asynchronous keyboard aborts did not work. To address this, the windrv module shipped with PCShare 4.x is a much more complex beast. As with the original kbdvdio, it once again hooks the IRQ clock vector, this time to issue periodic Get Window Status calls (2.1.4.4). When a keyboard break is detected, it sends the appropriate wakeup signals to the process concerned - again much like the original driver. However to support the muti windowing system implemented in PCShare it has to make use of a few direct page memory locations which may not play well on other systems. There is a breakdown on this at the back of the User Manual. windrv also exposes (via OS9 GetStat/SetStat calls on stdin/stdout) the mechanism for issuing PCShare messages from userspace applications. This then allows the additional functionality offered by PCShare to be implemented. The replacement Basic09 GFXE module for example implements the Graphics Messages (2.1.1.2) subsection of the spec allowing access to a limited subset of the Windows GDI. These are the latest binary OS9 drivers for the last PCShare (4.1) release: PCShare 4.1 OS9 drivers for PC/LPT port PCShare 4.1 OS9 drivers for PC/8255 port The following archive comprises a snapshot of my PCShare sources for OS9. There is a lot here because I have kept older versions of the codebase, in general the latest version will be the one with the highest number after the filename. PCShare with PCDragon Emulator One of the last things I did with PCShare was adapt it to use Paul Burgin's PCDragon emulator. Paul's emulator was written under MS-DOS so in order to use it I needed to find a mechanism to communicate between it and the Win32 PCShare application. In hindsight, probably the most straightforward approach to this would've been to setup a small IP stack under DOS however instead I opted to use the stdin/stdout handles of the DOS application and communicate between it and the emulator. Naturally this required different drivers for OS9 and an updated comms DLL for the Windows application. You can read about it & download the programs from the PCShare/PCDragon Emulator page. Official PCShare release pages These are the links to the original PCShare releases for both DOS & Windows together with documentation and user guides: Drivewire and future possibilities... Much of this functionality can now be achieved more readily (and from a hardware perspective, a lot more simply) using the Drivewire application, certainly the virtual hard disks created with PCShare can be loaded by Drivewire and accessed by a running OS9 system. Some support is also available to access the PC's underlying file system although I don't think it is quite as streamlined as my PCSBF driver. However I'm not aware of anything there (yet) which provides the keyboard and windowing system which PCShare did for OS9. So one of my thoughts for the future is that it may be possible to use these features of PCShare via the Drivewire interface. I have only skimmed the documentation for Drivewire but it does seem to allow the client (CoCo or Dragon) to establish TCP/IP connections through the Drivewire server. So my thinking is to replace the PCShare I/O DLL with one that operates as a TCP server - no other application software changes should be required. At the OS9 end, the device drivers would need to be replaced with ones that used the Drivewire TCP client and you have connectivity - in theory it shouldn't be that big a job to accomplish. Those items in blue show (an example configuration ) of what I think would need to be changed. Here the bdwire module replaces the bpia21 module for implementing the message sending layer for the PCSBF manager. Whether I have have the will to pursue this idea is a different question but if someone else wants to have a go I'm more than happy to lend my support. jrb, march 2015
|
||||||