Superboard Expanded on S-100 motherboard

[davisgw]

Mark,
I'm stumped on this XMODEM transfer to my 600B board. So far I have tried a shorter null modem cable, a null modem adapter directly on the USB to serial adapter, verified as best I can the RS232 circuit and connections to the 600B board, and purchased a USB to serial adapter based on the FTDI chips instead of PROLIFIC. Nothing has worked, at either 300 or 4800 baud. And I have no problem downloading the disktool.lod file to run on the OSI. I KNOW it worked at least once because I transferred disktool5 to a floppy. From the description of the xmodem protocol it would seem that TeraTerm is waiting for a NAK to the first packet sent so it hangs. The only thing left I have not tried is wire an rs232 J9 connector to one of the 600D boards but I doubt that will tell me whats wrong on the 600B. Here is the new USB to serial adapter I tried: https://www.amazon.com/dp/B0759HSLP1?re ... tails&th=1.
Any ides to try would be appreciated....

[bxdanny]

davisgw,

I will leave the XMODEM question for Mark, but i wanted to follow up on the changes you made to the disks for WP6502. You got the menu working, but if you actually tried typing in some text, I expect you found that the cursor still skips to a new line if you enter a space as the 15th or higher character on a line. After spending more time on it than I probably should have, I figured out how to fix that. (The "Screen Width" setting in the "change WP6502 codes" dialog only affects 540-board and serial systems.)

The location to change is $4192 (16786 decimal). So what you should do is to once again boot from Tutorial Disk 2, then do the following:

1) Insert the WP6502 disk that you prepared for use with your S-100 video board and type the following commands:

DISK!"LO WP6502"
POKE 16786,60
DISK!"PU WP6502"

2) Insert the WP6502 disk that you prepared for use with the 600D in 48-character mode and type the following commands:

DISK!"LO WP6502"
POKE 16786,44
DISK!"PU WP6502"

In each case, the value to POKE is four less than the actual screen width.

BTW, the file WP6503 (in the version of the software you have) is just a backup copy of the WP6502 program, which doesn't get modified by the change codes dialog, and can therefore be copied to WP6502 to restore default values. And TODWO is just a sample form letter. (Actually, DQFLS wanted people to fill in the blanks, print out the result, and mail it back to them to register their software.)

[Mark]

Sorry for the frustration! I'm digging into this deeper.
In the meantime if you feel like playing with it, try setting Transmit Delay in TeraTerm Serial Port Setup to 2 mSec/char and set Xmodem Opts in OSI DiskTool to CRC mode.

[davisgw]

With both settings it works at 300 baud but not at 4800. I tried the delay alone and that did not work and I previously tried CRC but I don't think that worked either but I will try it again to be sure. Keep me posted when you find something that will me to download at 4800. Thanks.

[davisgw]

Even though I'm sure I tried CRC mode with the Prolific cable without success, it now works at 300 baud with the FTDI cable. The 2 msec delay does not seem to change anything. I'll let you know the results if I think of something else to try.

[Mark]

So the problem with 4800 baud receiving using ACIA clock divide by 1 mode is the serial port can't sync to the starting edge of the incoming bits. When using clock /16 or /64 mode, the starting bit is sampled and the ACIA internal clock is synchronized with the incoming data. So if the baud rate is slightly different in /1 mode or it gets sampled at the wrong time, there may be transfer issues. Also the parity error, framing error and receive overrun conditions were not checked in the DiskTool code and I feel incoming data could be misinterpreted. (Parity is not checked/generated by the ACIA in 8N1 mode so that is not an issue). This doesn't affect transmitting because the receiver (PC) can sync to the incoming bitstream from the OSI easily.

I wonder what frequency your 600B board ACIA is running at? If you have a frequency counter to measure it perhaps we could adjust the receiving baud to match? Though I don't know if FTDI does arbitrary baud rates.

Anyway I'm updating the code to better detect & handle garbled transmissions and also indicate what it is doing. I have an FTDI cable set up with an OSI at 300baud so I can try to emulate your setup. I'll see what I can figure out.

I have had good success receiving at 9600 baud on a 1Mhz machine and 19.2K on a 2Mhz C3 with real PC COM ports, but I was using an ACIA clock in /16 mode. If you have a way to modify the 600B baud rate you may have better luck at higher speeds in normal (/16) mode.

300 baud is so painfully slow for disk sized images! I salute you for you patience!

[davisgw]

bxdanny,
Thanks for the new settings. As near as I can tell the line length looks good. Keeping all these notes and changes requires a searchable index

Mark,
According to my tiny LCD o'scope the period of the ACIA clock is 204 microseconds, or 4.9019 Khz. If that figure is way off I will need to fire up my big scope to do better.

[davisgw]

Mark,
For what it's worth I wired one of my 600D boards with RS232 and loaded disktool no problem. Then downloaded at 300 baud NP, but 4800 does not start as expected. Have you made any progress on modifications to disktool? Is there any hope 4800 baud transfers can work without hardware mods?
If not is there any way to modify disktool to allow the floppy drive to stop after writing a track while it is receiving data? That would be very helpful at either baud rate....

[Thomas]

As Mark explained, the problem lies in the clock/1 setting for 4800 baud, which only works reliably, if Rxclk is provided by the sender. Otherwise the ACIA will sample the incoming bit stream not synchronized. I have tested this myself with different setting without success.

I would suggest a "minimal" setup (not mod, as it has been designed in by Ohio Scientific).
Just change W5

W5.JPG (43.46 KiB) Viewed 47703 times

to

W5n.jpg (3.52 KiB) Viewed 47703 times

and feed in a TTL signal of 16times the baudrate into J2 pin 2 (left backside of the board)

By using the classic TI CMOS 555 (TLC555), you can easily get 153,6 kHz needed for 9600 Baud (div 16 configuration) for example.

[Mark]

Hi,
So the good news is I have made good progress with the update. It now handles framing errors well and I am able to receive disk images reliably at 4800 baud on the OSI with a /1 clock from the usual 300 baud /16 clock. I have tested the transfers at up to 57.6K in /16 mode on a 2MHz C4P without error. Sending data at /1 works flawlessly, however receiving data gives me a maybe 20% bad packet rate which still translates into a much shorter overall transfer.

However, my serial port is being clocked at exactly 4800Hz. You measured your clock frequency at 4902Hz or so which is about 2% fast. I think you may have an even higher error rate. You MAY be able to set the FTDI/Teraterm baud rate to 4900 though, I haven't verified that it actually changes to that speed.

I have attached a monitor loadable file & disk image of disktool with your update. I have also included a mod to shut down the drive between reads as requested, which may cause problems (previously it would just unload the heads & let the disk spin, however your drive may not have an unloadable head). There is additional diagnostics information sent to the screen during upload so you can follow progress.

I'd like to make a few more changes before finally releasing an update, but you're more than welcome to give it a try.

Anyway, in the future I think you'll be much happier with an adjustable/selectable baud rate that leaves the ACIA in /16 mode so it can better sync to the serial stream. I'm working on a single 8-pin chip hardware solution that may help.

-Mark