Model B serial speeds

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
Post Reply
cmorley
Posts: 886
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Model B serial speeds

Post by cmorley » Mon Sep 17, 2018 2:38 pm

I do 95% of my dev on a PC and use serial to send to the Beeb and control it.

Short story after having problems with the USB->RS232 adapter with the BBC I ordered a different one with a genuine FTDI chip in.

My build tool normally squirts stuff over at 38400 (9600 with 6850 divider on 16x instead of 64x) to good effect. I remembered when playing with FTDI chips that newer ones will do _any_ baud. 76800 is usually off limits because no PC will select it... but the FTDI adapter will.

So I tried it. *fx7,8 & *fx8,8 & *fx156,149 to get 19200 with 16x divider for 76800 & it works. The OS IRQ handler is too slow but I use a custom poll & store for binary transfer. It seems very reliable.

So I tried 153600 *fx7,5 & *fx8,5 & *fx156,148 to get 2400 with 1x divider & it kinda works. PC->BBC drops/corrupts bytes so not a lot of use but BBC->PC is flawless!

I will mod my dev tool to switch to 76800 for binary transfer which should get me 7.5K/s or so. Not too shabby for the original hardware :)

User avatar
1024MAK
Posts: 8862
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Model B serial speeds

Post by 1024MAK » Mon Sep 17, 2018 3:07 pm

Nice 8)

Mark

cmorley
Posts: 886
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Model B serial speeds

Post by cmorley » Thu Sep 20, 2018 7:35 pm

Ha found a problem... I am using the MOS CRC code (CFS) to CRC received data. The poor CPU can't do the CRC in time!

By my approximation it has around 260 cycles between bytes arriving @ 76800 baud. A quick speed test of the MOS CRC handler and it uses ~330 cycles per byte. #-o If only it ran at 3MHz!

colonel32
Posts: 65
Joined: Wed Jan 18, 2017 7:59 pm
Location: USA
Contact:

Re: Model B serial speeds

Post by colonel32 » Thu Sep 20, 2018 9:26 pm

Can you send the data in blocks and do the CRC checks at the end of each block received, rather than as you go?

I'm using something similar on a FPGA Spectrum implementation, at a 2 meg baud rate and 8KB blocks with XOR checksumming, and it is rock solid over a 6 foot FTDI cable. The UART is in the FPGA in this case.
Last edited by colonel32 on Thu Sep 20, 2018 9:29 pm, edited 2 times in total.

cmorley
Posts: 886
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Model B serial speeds

Post by cmorley » Thu Sep 20, 2018 10:14 pm

Yes I could do something like that. My client code fits in one page at the moment so space is tight - which is why I'm using the MOS CRC. I could use a faster implementation - no point using the MOS one because it takes 10s to CRC 64K but only 16s to upload _and_ CRC @ 38400... 8s upload @ 76800 and 10s MOS CRC is slower! (Hence the need for a different implementation, there are plenty documented 16 bit and 8 bit CRCs in 6502 assembler)

It is all just tinkering. I have my Tube serial which can stuff 400kB/s 8)

User avatar
jgharston
Posts: 3566
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Model B serial speeds

Post by jgharston » Thu Sep 20, 2018 11:11 pm

There's faster version of the CRC-16 code on the Wiki.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
sweh
Posts: 2043
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Model B serial speeds

Post by sweh » Fri Sep 21, 2018 1:33 am

The tape loader uses CRC because tape loading is notoriously unreliable. If your serial code is more reliable than maybe you can use a simpler check (eg EOR).
Rgds
Stephen

cmorley
Posts: 886
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Model B serial speeds

Post by cmorley » Fri Sep 21, 2018 8:01 am

jgharston wrote:
Thu Sep 20, 2018 11:11 pm
There's faster version of the CRC-16 code on the Wiki.
I found that one when searching yesterday. I just tried it and it is 220 cycles per byte it seems.

My code does lda ACIAD:jsr CRC so I need to strip the pointer inc and counter code which will win me some so I'll give it a go!
Edit: I'll loose a bit from saving A,X & Y and restoring + JSR/RTS pair... could be close

I also found some others on 6502 sites including a 22 cycle (or byte can't remember) 8-bit CRC.
Last edited by cmorley on Fri Sep 21, 2018 8:04 am, edited 1 time in total.

User avatar
Elminster
Posts: 3540
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Model B serial speeds

Post by Elminster » Fri Sep 21, 2018 9:05 am

Semi related but I just happened to have watched this recently on Mike's channel, and this thread reminded me of it.

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

Edit: Ignore the title/description. It doesnt explain this is doing various serial applications. (for first 10 mins )
Last edited by Elminster on Fri Sep 21, 2018 9:18 am, edited 2 times in total.

User avatar
jgharston
Posts: 3566
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Model B serial speeds

Post by jgharston » Fri Sep 21, 2018 4:16 pm

sweh wrote:
Fri Sep 21, 2018 1:33 am
The tape loader uses CRC because tape loading is notoriously unreliable. If your serial code is more reliable than maybe you can use a simpler check (eg EOR).
With Serial HostFS I can get up to 19,200 with a MTU of 32K with no errors. I can theoretically get up to 76,800 but I can't get my PC to select that speed as it jumps from 38,400 to 115,200. From testing 38,400 works with no errors in data transfer below 32K, but text replies (eg *CAT, *EX) start dropping characters, so I tend to stick to 19,200.

From observation, at high speeds I get dropped or missed bits, but byte framing remains correct, so I get things like:
>*INFO HELLO
HDLLP FFFF1900 etc.
so a simple CRC-8 would probably suffice, or even simpler, ADC the byte stream.

Edit: and, of course, a table-driven CRC calculator is faster than a calculated CRC, as each step is simply newCRC=table(byte EOR oldCRC) which can be as simple as EOR crc:TAX:LDA table,X.
Last edited by jgharston on Fri Sep 21, 2018 4:21 pm, edited 1 time in total.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

cmorley
Posts: 886
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Model B serial speeds

Post by cmorley » Sat Sep 22, 2018 8:59 am

jgharston wrote:
Fri Sep 21, 2018 4:16 pm
From testing 38,400 works with no errors in data transfer below 32K, but text replies (eg *CAT, *EX) start dropping characters, so I tend to stick to 19,200.
I wonder if this is the PC end or the BBC end causing this?

I found using the naff USB adapter that full duplex caused errors (characters PC->BBC were lost/corrupt) but with my old Dell laptop or the new FTDI USB adapter 38400 is very reliable. Half duplex on the naff USB adapter worked fine. Long cable >5m with CTS/RTS flow control. It would manifest with *fx2,1 *fx3,5 then write a bunch of stuff (e.g. BASIC listing) to the serial port even at 9600.

I watch RTS from the beeb like a hawk in my PC code to prevent byte loss PC->BBC due to FIFOs stuffing bytes when the BBC MOS serial buffer is full... but the only dropping of characters or corruption I've seen was with the naff USB serial adapter - so PC side hardware.

User avatar
MartinB
Posts: 5213
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Model B serial speeds

Post by MartinB » Sat Sep 22, 2018 8:32 pm

Chris wrote:...but the only dropping of characters or corruption I've seen was with the naff USB serial adapter
I couldn't stress this point strongly enough during the development of UPURS. My findings showed that with inferior USB-RS232 adaptors (i.e. pretty much anything non-FTDI or hooky versions thereof), RTS and CTS are simply not implemented with sufficient integrity and so fail miserably at any significant speeds. I actually also found that most legacy PC ports struggled at any useful speed but this appeared to be firmware and/or software buffer mis-management to me but I'm no expert on PC stuff. Anyway, as Chris says, genuine quality FTDI are a must and with these, UPURS happily runs bit-error free at 115,200 baud on every permutation of Beeb, Elk, Master and PC variation I've ever encountered.

cmorley
Posts: 886
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: Model B serial speeds

Post by cmorley » Sun Oct 14, 2018 2:01 pm

I grafted the Wiki CRC (with a minor change to preserve the Y register) and 76800 is reliable to the Beeb with full CRC calculated between byte receives.

7.5kB/s or so using the original B hardware & an FTDI RS232 adapter. I think that is pretty good!

I wonder though & perhaps JGH knows... I used the MOS CFS CRC word at &BE. This is in the filesystem scratch space according to the memory text files I have. Is it safe to trash these two bytes with DFS or ADFS active or do they hold state across filesystem calls so need preserving? Or would I be better using A8-AF the transient command workspace?
Last edited by cmorley on Sun Oct 14, 2018 2:01 pm, edited 1 time in total.

User avatar
jgharston
Posts: 3566
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Model B serial speeds

Post by jgharston » Sun Oct 14, 2018 2:56 pm

cmorley wrote:
Sun Oct 14, 2018 2:01 pm
I wonder though & perhaps JGH knows... I used the MOS CFS CRC word at &BE. This is in the filesystem scratch space according to the memory text files I have. Is it safe to trash these two bytes with DFS or ADFS active or do they hold state across filesystem calls so need preserving? Or would I be better using A8-AF the transient command workspace?
&B0-&BF is temporary filing system workspace. Whenever a filing system call is made the filing system has full ownership of it, but the filing system must not assume its contents stay the same between filing system calls. So, a filing system can put something there, but as soon as it RTS's to its caller it must assume that what it's put there is no longer there. And a non-filing system can put something there, but as soon as a filing system call is made it must assume that what it's put there is no longer there.

&C0-&CF is permant filing system workspace. As long as a filing system is selected that is owned by that filing system and is allowed to assume that its contents remain the same between filing system calls. Meaning that non-filing system must not put anything there.

&A8-&AF is transient command workspace, and is what you should be using fo transient commands. You own it from the moment your *command code is entered to the moment you RTS back to your caller (or bomb out with a BRK). If more space if needed you should 'overflow' into &B0-&BF, but with the caveat that that space is assumed to be trashed as soon as you make any JSR to code that is not your code, as you have no control over the possibility that that other code may make a filing system call. Even OSWRCH may make a filing system call if SPOOL is active.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Post Reply