• Please review our updated Terms and Rules here

Advanced Digital Corporation Super Six TurboDOS and TurboDOS x86 PC - can they communicate ?

Still no joy with rev 4. Everything is good on the ADC side, when I do a DIR to the remote PC drive, it pulses the transmit line and then gives 'network error'. If I connect it to a modem it transmits/receives like crazy trying to make a circuit connection. The PC side is a dead horse. I assembled the new UART sources and linked them in but the pc just locks up when osmaster runs. Like you told me, TurboDOS for PC was a science experiment at best. I'm flunking this science class so far :)

Larry G
 
Aha - reading the LAN-PC control manual Aug 84 p51 SIOA needs to be set to the COM1 port address (0x03F8).
I have it set to (0x00) which disables it.

Larry G
 
When I use the SIOIPC module, if I set SIOA = (0x03F8) then when booted, I get an 0C> prompt but no response to keyboard. I see no changes in the lights on my serial breakout box either. I have no clue why this would kill the keyboard ? Leaving it at (0x00) has an active command prompt but attempting a remote drive access just locks like a dead serial port. Since that module
had a different serial# makes me think it was written for the LAN-PC card and not a regular PC serial card but the description in the manual sure sounded like it would.

Larry G
 
Hmmm, since the SIOIPC driver was written for the IBM PC/XT 8250 chip, could there be an incompatibility with your 386 PC? I'm not sure what else to try, perhaps just need to meditate on the situation for a while.
 
I repeated the experiment on my IBM XT with a different ancient serial card for the XT with the same results. I think that SIOIPC driver is bogus.
All examples I've seen in manuals have that driver rem'd out. I would sure like to get that uart driver source to work
 
I had a setback when the hard drive on the ADC decided to crash. It was reporting a trashed track 3. I pulled the drive (Seagate ST-225) and connected to an MFM controller on a PC and formatted / confirmed the drive is perfect. I put it
back in the ADC connected to the Monitor Dynamics HD1013 I've been using, spaced the card out in the S100 frame with a cooling fan on it then went through the procedure in the ICM TurboDOS Configuration Manual June 86
starting on page 3-19. Yes I found a more detailed procedure in this manual vs the HD1013 technical manual itself. This time I paid attention to the last paragraph on page 3-21 which states if you don't have a sequencing power supply
which the 12v and 5v supply is turned off first then a second later the S100 gets turned off you could trash the directory of the hard drive. Well crap, the directory is stored on track 3 !!! I have a separate power supply for the hard drive
which I'd always turned off LAST !!! If not sequenced, the manual recommends assembling HALT.MAC and running that each time before powering down. I'll do that from now on. With all the testing I've been doing trying to get the serial
network to fly, I've been power cycling quite a bit and tempting fate which caught up to me. It pays to RTFM.

Larry G
 
I still haven't come up with a solution to network two TurboDOS systems via serial port. I revisited the work done by Mario Viaro porting TurboDOS to Z80 SIM and Joe Moore porting it to his ZEMU emulator.
Joe got ZEMU to connect master/slave via TCP/IP and I just got two Win98 boxes talking TurboDOS to each other. I did this back in 2015 as well. I see Joe also wrote a serial driver EMUSER so I'm going to see if I can get CKTSER
to connect thru his EMUSER to my real ADC S6 S-100 hardware which I'm sure is trying to connect via serial port. Here's a photo of my ZEMU TurboDOS connection between PC's with TCP/IP. The ADC S6 hardware is off to the left side out of photo. I see Joe gave me credit for helping him upgrade to TurboDOS 1.43 - Larry Greene
ZEMU TurboDOS network.JPG
 
Well, I'm halfway there. I now have the ADC S6 connected via a serial port to the Win 98 box running ZEMU emulator. I was able to use 19,200 baud. ADC S6 drive F: is mapped to the
ZEMU drive A: I am not able to do visa versa yet. On the ADC doing DIR F:*.* will show a directory of A: on the other ZEMU PC via com ports. Still a work in progress trying to get TurboDOS PC hardware
to respond to the com port directly without an emulator.
tdos remote.JPGtdos remote zemu.JPG
 
Now it appears that the disk assignment table of the remote drive has to be defined locally. I can type the file contents of the remote files but they are wrong
since the DPB's don't match. The ZEMU disk definition is PC1440 but the ADC local drive is currently 8" DSDD. It does report an error if the filename is wrong but not the contents.

Larry G
 
More progress on the TurboDOS ADC S6 to TurboDOS PC hardware to hardware, master to master via serial ports. I realized the UART x86 serial driver for the PC was not setting the baud rate during init. I added that step
to the source code and now doing a DIR F: from the ADC to the remote drive on the PC mapped as C: blinks the host hard drive but does nothing further. There must be some kind of file manager service program that needs
to run on the receiving host side since the sender would have no clue about the disk structure of the host ???

Larry G
 
I've confirmed NETMGR and NETSVC are in the STDMASTR package on both the ADC and the PC. Here are the gen and par files for both systems and my modified rev E of the UARTI86 source I'm currently using.
Everything is set to 9600 baud. Changing the baud rate doesn't seem to affect the outcome. There is still a bug where trying to connect from the PC back to the ADC crashes to an 0C> prompt with no keyboard.
Remoting from the ADC to the PC accesses the remote drive but then just hangs the ADC without a network error and the PC drive shuts back off but I also have no PC keyboard at that point to it might be crashing
to the same bug behind the scene.

Larry G
 

Attachments

  • m2m_r5.zip
    10.5 KB · Views: 1
Looking back at the notes that came with the CKTSER driver it says this:
"CKTSER assumes one single processor to processor network connection and does not care what the logical TurboDOS circuit/node assignment is. The circuit assignment table (CKTAST) in TurboDOS is patched for this logical assignment."
So I guess this means that whatever you put in the CKTAST parameter doesn't matter in regards to CKTSER, and it kinda makes me think that you can only have 1 circuit driver in each operating system. I modified your GEN/PARs and took out the Super Six Slave drivers. Try this.
 

Attachments

  • m2m_r6.zip
    10.4 KB · Views: 1
I don't know if I mentioned it but I still have two slaves. I need the first slave because it has the banked 128k to run Wordstar. There is not enough memory on the currently non-banked 64k master to run it.
The 2nd slave is a dummy right now because I had to borrow it's paddle to provide a serial run to the PC from the ADC master channel B. I only have 3 working paddles at the moment. I read somewhere
that the ADC master cannot be banked 128k when it has slaves ? To do what you're proposing will kill my slaves (see if that statement triggers some flag at the NSA :) so I think I will have to change my master
back to banked w/o slaves. I need to be able to edit with Wordstar. I do have a boot floppy for a backup when I shoot myself in the foot trying these changes so I can get back into Wordstar to correct them.
I learned the hard way you always need a plan B floppy boot and a plan C when the hard drive crashes as in backup your work to floppy !!! I just had a thought, I wonder if the cramped memory in the 64k
ADC master is the problem ? The PC has 422k free so memory to burn. Hmmm ...

Larry G
 
The more I think about it, it really does seem that if CKTSER is going to be used, then no other circuit driver can be present in the operating system. Perhaps putting CKTSER into a slave OS and networking off of a slave's serial port would be a valid use case. You'd have to add in some of the NET* modules into the slave OS, but perhaps it would work.
 
Back
Top