65C51 ACIA Baud Rate Surprised Me!

[DRG]

My involvement with the 6502 and my breadboard SBC is the love of the journey, rather than the destination (mainly as I haven't set one!).

Consequently, I enjoy attempting to make a "more my own" SBC than the Ben Eater clone I built following his videos. Many forum members have helped me develop my understanding as my skills in this area are rudimentary (but improving). Also, I like writing 65C02 code for my Eater SBC and getting programs into it via serial.

Recently, my dabbling has been around getting a better serial transfer system (more speed and some error checking) whilst using minicom as well as writing python apps to do the transfer. As part of this improvement, I happened to look at my (Ben's) 65C51 initialisation code and I recently read on Garth's site that the 65C51 is supposed to be able to achieve 115,200 baud (at 1.8432 MHz). So, I thought I'd look at the datasheet again to see if there was anything I could do to improve speeds.

However, my SBC runs off a 3.6864 MHz oscillator. I also feed that into pin 6 (XTLI) meaning my 65C51 has always run at twice the speed of the selected baud rate i.e. 38,400 when SBR is set to 19,200. And it has done so without issue. As part of my experimenting today, I changed SBR Bits 3-0 of the control register from 1111 (19,200 - aka 38,400 for me) to 0000 (XTLI / 16). This mean that the 65C51 would be operating at a baud rate of 230,400 - that couldn't possible work, could it? Surely, WAAAY outside specifications?

Well, it only went and worked. I rewrote my monitor code accordingly (if you can call changing $1F to $10 a rewrite!) and my data transfers now are, well, like lightening!

I now do my uploads in Intel Hex so wrote a python program to create a dummy file that's around 14 Kb in size and uploaded it into my SBC. It took 0.954 seconds. That's around, well, 14 Kb/sec transfer rate.

I was so expecting a crash and burn conclusion. Instead, I'm blown away by what the 65C51 could handle in terms of throughput.

I hope this data point is of use.

Edit

I surmised that this may also work the other direction too i.e. outputting quicker than the specification. Due the the 65C51 bug, my "put_char" code uses a delay before sending the next character. I kept reducing this delay. The outcome being doing a memory dump in my monitor for 8000 to FFFF took 28 seconds before my changes to 13 seconds after them.

PS. According to the value for the delay as calculated by Ben Eater (https://youtu.be/CnA8nG3zYHw?si=QiBq3uPkVl7YZ8iJ&t=1294) for my baud rate, 8N1 (10 bits) and CPU speed it should be 160 cycles between sending characters. For a 5 cycle loop (DEC / BNE) that'd be 32 of those loops. However, I can't get reliable operation below 78 loops (390 cycles). Dunno why that would be the case, but still happy with the improvement.

All-in-all, a productive day!

Dave

[BigDumbDinosaur]

Something that has long puzzled me is why anyone would use Intel hex to feed code to a MOS Technology MPU.   

[DRG]

BigDumbDinosaur wrote:

Something that has long puzzled me is why anyone would use Intel hex to feed code to a MOS Technology MPU.   

Sheer convenience! My assembler, vasm, can produce the format and the code to upload it is in the forum's code repository (thanks to Ross Archer).

At some point I'll reverse engineering Ross' code to understand it more and will be able to do the same for Motorola S19 record format. The binary output is, obviously, more dense (one-to-one byte correspondence) but doesn't include the start address of the code. However, you can "fake" this using .org directives so the first 2 bytes of the binary are the "load to" address and the next 2 bytes are the "execute at" address. When I get more adept at coding, I fancy attempting to roll my own process along these lines. Perhaps something like XMODEM-1K.

[BigDumbDinosaur]

DRG wrote:

BigDumbDinosaur wrote:

Something that has long puzzled me is why anyone would use Intel hex to feed code to a MOS Technology MPU.   

Sheer convenience! My assembler, vasm, can produce the format and the code to upload it is in the forum's code repository (thanks to Ross Archer).

At some point I'll reverse engineering Ross' code to understand it more and will be able to do the same for Motorola S19 record format. The binary output is, obviously, more dense (one-to-one byte correspondence) but doesn't include the start address of the code. However, you can "fake" this using .org directives so the first 2 bytes of the binary are the "load to" address and the next 2 bytes are the "execute at" address. When I get more adept at coding, I fancy attempting to roll my own process along these lines. Perhaps something like XMODEM-1K.

There exists a genuine MOS Technology hex format that is conceptually similar to Motorola S-record.  The only place I ever used MOS hex was with Commodore’s HCD-65 assembler, which produced it as object output.  S-records are more flexible and, in my opinion, easier to parse.  Since the 6502 may be considered the immediate descendant of the MC6800, I don’t lose any sleep over using S-records in my POC unit’s loader.