Superboard Expanded on S-100 motherboard

[bxdanny]

YES, change the U57 input to (C0) to get 4800 bps in the standard divide-by-16 mode, or simply to (CLK) for 9600 bps.

I thought I remembered the crystal on the 600B being the same as the CPU clock, or 983040 Hz (=16384 x 60), but I guess I remembered wrong, and it is four times that.

At one time, I did understand how that circuit worked to generate 4800 Hz (exactly), but I admit I can no longer follow it. The (C4) signal, which should be 122,880 Hz, would need to be divided by 25.6 to get 4800 Hz, rather than by an integer value. If anyone has an explanation of how this works, please post it.

Glen, I also have a question about the 600D board in general. If the board is in 48-character mode, and you hold down BREAK to reset it, does it immediately switch back to 24-character mode? I think I remember that it does, but I'm not entirely sure if that's accurate either.

[davisgw]

bxdanny,

Thanks for affirming that the circuit to produce 4800 Hz for ACIA clock is a mystery I really don't need to push the ACIA clock to get 9600 baud
so I will go for 4800 baud by changing the source from C4 to C0.

Yes, the 600D board reverts from 48 to 24 character mode after pressing BREAK. That's why I modified my 600D monitor ROMs to put the video
back to 48 character mode since I don't plan to play any graphical games. I will try a couple adventure games though.

Mark,

Can you take another whack at changing Disktool to pause the floppy drive while reading data? I'm pretty sure the write delays I suggested will fix it. Thanks.

[bxdanny]

OK, here's how the circuit works:

The 74LS163 at U57, if left to its own devices, would count from 0 to 15 and then go back to 0. But on the count of 12, the NAND gate attached to pins 12 and 11 has its output go low, making the /CLR input to U57 low. But the '163 is a synchronous device, and its output will only change on the following input pulse, the one that would otherwise make the output count go to 13. When that pulse arrives, the counter clears to 0 instead. So the pin 11 output divides the input by 13, being low for 8 cycles of the input, then high for 5 cycles. That is then divided by 2 by the D flip-flop at U63, resulting in a symmetrical square wave at 1/26 the frequency that was input to U57.

So the output of U63 on a stock system is not exactly 4800 Hz, but rather about 4726.15 Hz, or about 1.54% too slow. That's close enough to work fine with the ACIA in /16 mode, but not to receive in /1 mode.

(Using a crystal frequency of 3.993600 MHz would make the ACIA clock exactly spot-on, but that is simply not necessary. It would also make the vertical frequency of the video output be 60.9375 Hz, which seems a bit high, but the horizontal frequency would be 15,600, which is closer to NTSC standard than the usual 600-board value of 15,360.)

[davisgw]

Thanks for clearing up that mystery. I did not know about the extra clock required for the 163 to clear, but I also made the mistake of thinking that it was counting to 15 to clear, not 13.

I will look at making the 600B board change and let you know success or failure to transfer at 4800 baud

[davisgw]

bxdanny, thomas,
Success! I rewired the 600B board U57 input clock from C4 to C0 and transferred a disk image to the OSI in about 5 minutes at 4800 baud. And Disktool
actually appeared to be reading the data from the PC USB/RS232 adapter without any errors. Thanks for the tips.
Who needs 300 baud cassette tapes anymore....

Mark,
I would still would like to have Disktool stop the floppy drive while it's receiving data, though it's not high priority....running the floppy for 5 minutes with a disk inserted will dirty the heads eventually.

[Thomas]

Welcome to the 4800 baud club ..
Thomas

[davisgw]

Though I had my suspicions, I've discovered that ROM BASIC cannot read a program faster than 300 baud. In fact it's likely the reason that the SAVE command pads the end of each line with extra line feeds / carriage returns that get stripped out when a BASIC program is loaded from tape.
I have some BASIC programs that I downloaded from the UK101 archive and when I tried to transfer one to my modified 600B at 4800 baud the ROM BASIC choked, So I tried to transfer to my 600D at 300 baud it still stored invalid line numbers until I setup TeraTerm to add at least 20 msec delay per character during transmit. Then I tried the 600B at 4800 baud with 50 msec delay per char and 200 msec delay per line and the program was correctly received by ROM BASIC.
Anyone know if I can use the DISK! IO command in OS65D3 to read a program into memory the same way? What other tricks can I try with the 4800 baud serial RS232?

[bxdanny]

Trying to load a BASIC program from an ASCII listing at 4800 bps is unlikely to work, because characters will be missed while BASIC is "crunching" (tokenizing) the lines. What could work is a two-step process in which the ASCII listing is first dumped into RAM, and then memory input is used to feed it to BASIC. But you'd have to have enough memory to hold both copies of the program. (Well, no, I guess you really wouldn't, as the growing program could overwrite some of the ASCII copy as it grows.)

I seem to remember that some simple BASIC programs could be loaded from tape at 1200 bps, but that longer and more complex ones couldn't. I once [but only once] even saw a commercial program, sold on a 300 bps tape, that caused the computer to drop a character from the beginning of one of the lines near the end of the program because too much time was taken tokenizing and adding the previous line.

[Mark]

Remember OSI uses 8N2 serial word format by default.
You may have better luck with teraterm at 300 baud without the 20msec delay if you use 11 bit words.
OR poke 61440,21 to set the ACIA to 8N1 before transfer.

[davisgw]

A friend sent this link to me and it's hilarious! Enjoy.

https://www.youtube.com/watch?v=ow78cUDdTOg