Superboard Expanded on S-100 motherboard

[davisgw]

Thomas,
Thanks for the suggestion. I may change one of my systems at some point to get faster transfer times, but since I don't have a lot of software to transfer it's not high priority right now.

Mark,
I did not get much joy with the test version of disktool. I tried 4800, 4850, 4900, and 4950 baud on TeraTerm and each one resulted in framing errors. And I tried both the FTDI and Prologic adapters with the same result so I suspect that neither gets set to the faster incremental baud rates.
The modification to shut down the floppy drive between writes seems to work and does not result in errors but the disk does not boot when transfer has completed....the timing may be a bit hinkey writing track 0. Perhaps a delay for the drive to come up to speed is needed?
Also the complete transfer of a disk seems slower at 300 baud (maybe presenting debug data to the console slows down the read).
I look forward to trying you next iteration. Thanks.

[Thomas]

One more comment to the "minimal" setup @ W5.
If you do not need the higher baud rate any more, you actually do not need the change back the W5 wiring,
Just connect Pin 5 and Pin 2 of J2 and you will feed in the original TxClock generated by the board and get back your 300 Baud.
How nice is that !

[Mark]

davisgw,
Framing errors are expected on receive /1, you can't avoid them but the transfer should complete OK unless it was completely unable to send any data successfully. I normally see about 1-2 framing errors for every 10 blocks sent. (There should be no errors when sending disk images from the OSI though.)

Disktool will verify that it can read what it has written & retry writes 3 times, so if you didn't see any error messages logged, it would seem disktool thinks it was successful.

Can you run disktool again, set transfer options to hexadecimal, turn on logging in teraterm and dump the first track or 3 of the disk you tried writing (just hit ESC to end), then save the log? I'd like to see what actually made it to the disk.

300 baud slower? Dang, I removed some delays that happened between blocks during transfer that should have sped it up! The data displayed on screen should not affect the overall transfer speed as it is stored character by character as it is received. (300 baud is so slow the computer spends most of it's time waiting.)

Does your C1P run at 1 or 2 MHz?
Thanks

[davisgw]

Mark,
Here is what I have observed.
1) There are no framing errors at 300 baud. But when I hear floppy drive A step to the next track for a write, the select LED's on the drives change from A to B so quickly that no data could possibly have been correctly written to disk. I think there needs to be a delay for the drive to come up to speed before a track write and another delay for the time to complete the write. That would add nearly nothing to the transfer time.
2) I assume you wanted me to ignore framing errors at 4800 baud and see if it will complete. What actually happens is a framing error occurs on the first block of data and nothing further happens until TeraTerm stops the transfer, so disktool does not write any data to the disk.
3) When I compare a transfer with the test version versus the unchanged version the time to write a disk is about the same....slow. It takes over an hour, which is why I requested the drive to be stopped while data is being received.
4) My Superboard clock is unmodified and has a 3.92 Mhz crystal, so it is running the CPU at 1 Mhz.
5) I'm not sure what the handshake is between TeraTerm and Disktool but it looks like the XMODEM NAK is never recognized by Disktool so no more data is requested for TeraTerm to send. In any case the data transfer stops with only 128 bytes transferred by the PC, so there is no retry.

I hope this helps.

[bxdanny]

davisgw,

Don't you have, or didn't you used to have, a switch on one of your 600 boards that controlled the baud rate in a rather odd way? The code at $FCD5 in your monitor ROM looks at the DCD line of the ACIA (or rather its bit in the status register) and initializes the chip to either /1 or /16 mode depending on its state. Wouldn't it have been simpler to just select which step in the clock divider is used to provide the clock to the ACIA, and always use /16 mode?

I used to have a five-position (DP5T) rotary switch on the back of my C1P that let me select baud rates from 300 to 9600 bps (omitting 4800, IIRC). The second pole of the switch was connected only in the 300, 600, and 1200 bps positions, and allowed the writing of cassettes (using standard KCS frequencies, but different numbers of audio cycles per bit) at those frequencies.

-Danny

[davisgw]

Danny,
Thanks for reminding me. I had to remove the switch when I removed the 600B board to replace a flakey keyboard switch. I only needed it when I had a Epson printer that I set to 4800 baud based on the state of the DCD line...it did not occur to me that your method provides more flexibility for no more effort. But Disktool does not have capability for baud rates other than 300 and 4800, correct? And if Mark changed that what would be the optimum baud rate for file/disk transfers without framing errors?
I don't plan to EVER use audio tape again for software.

[Mark]

Disktool can operate at any baud rate, it's the ACIA /1 setting with the 4902Hz clock that gives you trouble receiving data. /1 mode works fine for sending data from the OSI which is what this program was originally designed to do - dump disk images for archiving.

In normal ACIA /16 mode, I have error-free transmission at 56K on my C4P (the highest that my custom baud rate generator is wired for.) It takes just a few minutes to upload & write floppy disk images at that speed.

I find 9600 baud to be generally fast enough for general I/O which means you need to clock the ACIA at 153600 Hz. The OSI ROM monitor has no problem 'L'oading at that speed. Uploading programs for ROM BASIC at that speed will require a few second delay after each <CR> sent for the BASIC tokenizer to process the data. Writing floppy images with DiskTool at that speed takes less than 3 minutes total. Also at the 153600hz clock, ACIA /64 mode gives you 2400 baud which may be good for slower devices like a printer.

I feel changing your ACIA clock will give you the best experience going forward.

[davisgw]

Mark,

I'm having some difficulty understanding how the 600B board produces 4800 Hz using the logic on the attached sheet. I think pin 14 on U59 should be about 121.875 KHz for the U57 clock and cannot see how u57, U58, and U63 produces a divide by 25 resulting in 4875 Hz. I was thinking perhaps if I understood that, then I could change some wiring to come up with 153.6 KHz to clock the ACIA. Is there an onboard solution to this instead of adding an external clock (I understand it's easy, but it's extra hardware)? Am I overthinking this?
And, I think the transmit clock would also need to be modified for TeraTerm to receive from the ACIA.

[Thomas]

Don't make it overly complicated. As you have mentioned, C4 gives you your trusty 300 Baud. C3 will give you 600 Baud and finally C0 4800 Baud. Just this Mod and you have what you are looking for.

[davisgw]

Thomas,
Thanks again for your suggestion. Are you saying that my choices are:

1) Change the clock input on U57 to C0 instead of C4 and get 4800 baud on both Tx and Rx? This is too simple for me to have thought of...
2) Provide external Tx and Rx clock with a signal generator.

I have a multi-function signal generator but would need to scope the output to get the level and frequency I need. So this is the primary
reason I am reluctant to do that, though it provides more flexibility.