6502.org

Posted: **Mon Sep 10, 2012 8:52 pm**

BigEd wrote:

I'd describe baud as the symbol rate.

That article you mention might be this: George Hug, Toward 2400 (Transactor Vol. 9, Issue 3 - Feb. 1989 p.62)
In PDF here: http://ia700701.us.archive.org/21/items ... 3_text.pdf
In HTML reader here: http://archive.org/stream/transactor-ma ... 3/mode/1up
(via http://archive.org/details/transactor-magazines-v9-i03)

Interesting, thanks!

Cheers, Ed

I couldn't recall his name but I remember that when I read the article (which was in the same issue as one of mine) I was impressed with the diligence Mr. Hug had put into solving a riddle that no one previously could solve.

The problem had to do with the timer B interrupt in the CIA (CIA #2) that was being used to bit-bang the RS-232. If timer B interrupted right around the interrupt status register was being read (e.g., due to timer A interrupting) the flag bit for B would not be set in the ISR, no interrupt (NMI in this case) would occur for quite a while (in computer terms, not wall-clock time) and incoming data bits would be dropped. No one, including Commodore, seemed to have a handle on the problem until Hug identified it and determined that it was a chip defect (which I subsequently discovered to be present in both CIAs in all three of my C-128s). It then turned out Elizabeth Deal had tripped over the same problem several years before Hug's article was published. Deal had published an article (in 1984, I believe) on how to use CIA interrupts to "orchestrate" the SID, in which she described how she kept running into periodic timing problems. She, however, did not research it to the extent that Hug did.

This CIA glitch was a common sort of problem with MOS Technology products. The best-known defect, of course, was the 6502's JMP (<addr>) bug, which could have been fixed if it weren't for a certain guy named Jack who was always exhorting the troops to cut cost to the bare bone.

Posted: **Mon Sep 10, 2012 10:24 pm**

syscall wrote:

Hello everyone, just thought I let you know that I managed to get 68,2kbit/s with on the fly checksuming from this sucker

Looks to me like with a little bit of tweaking
you might get 115200
Need two stop bits.
Timing would be really tight though.

First when you loop back nothing changes the
accumulator so you can add cksum first

Second, sta doesn't change the carry and nothing
at the end or beginning of the loop will change the
carry so you can arrange to clear the carry as part
of inter-bit delay by clearing the bit that will
eventually be shifted into the carry with an and

and then adc cksum after the sta and before iny
and then add the carry from that back in after you
loop (there by saving a cycle assuming the buffer
starts on a page boundary).

Third saving cksum won't change the carry
and reading the port won't change the accumulator
so you can delay saving cksum to the inter-bit time

bit time at 115200 is 8.68c (1us/c)

Code: Select all

         ldx   #$3f
         lda   #0
         tay
         sta   zero
         clc

wb:      bit   portb   <- startbit
         bvc   wb       ;not taken = 3c long 3+4+2=9c short 2c
                        ;so jitter is 7c
         adc   zero     ;3
         cpx   portb    ;4 b0  9c-16c we need 8.68-17.36 
         sta   cksum    ;3
         ror   @        ;2

         cpx   portb    ;4 b1  18c-25c we need 17.36-26.04 
         ror   @        ;2
         bit   zp       ;3

         cpx   portb    ;4 b2  27c-34c we need 26.04-34.47
         ror   @        ;2
         and   #$E0     ;2 clc for cksum add when bit 4
                        ;  gets shifted out

         cpx   portb    ;4 b3  35c-42c we need 34.47-43.4
         ror   @        ;2
         bit   zp       ;3

         cpx   portb    ;4 b4  44c-51c we need 43.4-52.08
         ror   @        ;2
         bit   zp       ;3

         cpx   portb    ;4 b5  53c-60c we need 52.08-60.76
         ror   @        ;2
         bit   zp       ;3

         cpx   portb    ;4 b6  62c-69c we need 60.76-69.4
         ror   @        ;2
         nop            ;2

         cpx   portb    ;4 b7  70c-77c we need 69.4-78.14
         ror   @        ;2

         sta   sekbuf,y ;4   
         adc   cksum    ;2
         iny            ;2
         cpy   count    ;2
         bne   wb       ;3
 
         adc   #$00
         sta   cksum
         rts

It's probably possible to move the port read for the start
bit to the end of the loop, which might be desireable, since
the loop back is 19c, and the time to the start bit ie two
stop bits is 17.28.
It seems you might tend to the later read/longer jitter
but I haven't tried to work it out.

hmm, maybe I have that exactly backwards.
I guess you'd want the port read to come a
couple cycles later.
Wouldn't really matter anyway.

edit: tweaked the timing, removed a goof

Posted: **Wed Sep 12, 2012 1:30 am**

Quote:

I recall that the fake RS-232 routines in the Commodore 64 kernal could barely manage 1200 bits per second (bps) without error, and those were allegedly written by professionals.

Aw, don't be so hard on them! It's ugly code, yes, but (a) it's essentially the same as the code in the VIC-20 that used a 6522 VIA instead of a 6526 CIA (and hence did not have quite the same capabilities), and (b) was designed to handle multiple combinations of start-data-parity-stop bits, and (c) even a 300-baud modem cost a significant fraction of the price of a C64 (a 2400 baud modem? Did such things exist outside of development labs at the time?).

Quote:

I also recall an article in the old Transactor magazine in which the author described how he got the C-64 up to 2400 bps by essentially rewriting the kernal code.

Yes, and it's nice code, but it also throws out the multiple combinations option (it was 1-8-1 only, IIRC) and all parity and error-checking (the latter of which he claims couldn't be detected in any case, so there is no point in trying).

Full disclosure: ah, when I wrote a terminal emulator for a Control Data "Maggie", I, uh, also replaced the multi-purpose Kernel RS-232 routines with a dedicated version specific to that terminal. And I'd do it again today!

Posted: **Wed Sep 12, 2012 2:45 am**

Quote:

same as the code in the VIC-20 that used a 6522 VIA instead of a 6526 CIA (and hence did not have quite the same capabilities)

not the same as in inferior, or just different? In comparing the data sheet, I find the '26 to be very similar but does not have as many SR modes or as many interrupt sources as the '22. Unfortunately the '22 has that darn bug in just two of its seven SR modes, shift in & out under control of external shift clock, requiring the addition of an external flip flop to get around it. That is its only bug, and doesn't affect most users. What the '26 does have is the time-of-day clock which never interested me because its resolution is only 1/10th second, it's BCD, and it requires an external 50 or 60Hz input.

Posted: **Wed Sep 12, 2012 2:47 am**

teamtempest wrote:

Quote:

I recall that the fake RS-232 routines in the Commodore 64 kernal could barely manage 1200 bits per second (bps) without error, and those were allegedly written by professionals.

Aw, don't be so hard on them! It's ugly code, yes, but (a) it's essentially the same as the code in the VIC-20 that used a 6522 VIA instead of a 6526 CIA (and hence did not have quite the same capabilities)...

Yes, but the 6522 didn't have a timer-B interrupt bug. Commodore probably spent as much on programming talent to bit-bang a 6551 as they saved on not using the genuine article. Plus they reused code that was inappropriate for the 6526, as Hug pointed out in his article.

Quote:

...(b) was designed to handle multiple combinations of start-data-parity-stop bits...

A feature largely unused in the applications where the C-64's fake RS-232 might have been used. In fact, I did a huge amount of RS-232 work in years past and seldom used anything other than 8N1 with most peripherals.

Quote:

...(c) even a 300-baud modem cost a significant fraction of the price of a C64...

That was true, although the first one that Commodore shipped (model 1600, which was one level above being an electrically-powered desk ornament) was actually quite inexpensive. The later 1650 was a better product at a somewhat higher price.

Quote:

...(a 2400 baud modem? Did such things exist outside of development labs at the time?).

2400 bps modems were commercially available in 1985, but definitely not at a price that was commensurate with the C-64. I bought a 1200 baud Hayes-compatible modem in early 1985 to try out on my C-64. The modem worked fine, the C-64 struggled with CBAT at that speed. The C-128 was okay, but couldn't touch 2400 with reliability, which I discovered when I got a 2400 modem to try out. That prompted me to cobble together a serial adapter with a real 6551 on it, using 1488 and 1489 line drivers.

Quote:

I also recall an article in the old Transactor magazine in which the author described how he got the C-64 up to 2400 bps by essentially rewriting the kernal code.

Yes, and it's nice code, but it also throws out the multiple combinations option (it was 1-8-1 only, IIRC) and all parity and error-checking (the latter of which he claims couldn't be detected in any case, so there is no point in trying).

Hug's assertion about the inability to check parity errors was correct, and in any case, with the majority of modems in use when he wrote his article (1989), was unneeded.

Quote:

Full disclosure: ah, when I wrote a terminal emulator for a Control Data "Maggie", I, uh, also replaced the multi-purpose Kernel RS-232 routines with a dedicated version specific to that terminal. And I'd do it again today!

Let's face it: the C-64 and C-128 could do a lot for the money they cost, but that low price had its...er...price.

Posted: **Wed Sep 12, 2012 2:57 am**

GARTHWILSON wrote:

Quote:

same as the code in the VIC-20 that used a 6522 VIA instead of a 6526 CIA (and hence did not have quite the same capabilities)

not the same as in inferior, or just different? In comparing the data sheet, I find the '26 to be very similar but does not have as many SR modes as the '22.

The 6522 timer differs in some respects than the 6526's when running in one-shot mode.

Quote:

Unfortunately the '22 has that darn bug in just one of its seven SR modes, shift in under control of external shift clock, requiring the addition of an external flip flop to get around it.

The only machine that actually put the CIA's serial shift register to use was the C-128, which is how the so-called fast serial bus was implemented. Back when I had my my Lt. Kernal development system running with three C-128s attached, I had a sort of local area network rigged up using the CIA's SR. It could easily run at 32 KBps without errors. However, not too long after I got this "network" working, I came up with a better data transfer scheme that used a contiguous data file on the hard drive. Strange as it may seem, this "software" network was nearly twice as fast as the SR to SR setup.

Quote:

What the '26 does have is the time-of-day clock which never interested me because its resolution is only 1/10th second, it's BCD, and it requires an external 50 or 60Hz input.

Which neither the C-64 or C-128 used. The B-128 did use the TOD clock as the source for the TI and TI$ BASIC time variables. The TOD clock was also used in the 1571 and 1581 floppy drives to support CP/M file time-stamping.

Posted: **Thu Sep 13, 2012 11:05 pm**

Quote:

Quote:
same as the code in the VIC-20 that used a 6522 VIA instead of a 6526 CIA (and hence did not have quite the same capabilities)

not the same as in inferior, or just different?

IIRC, the main hardware difference w/r/t software RS-232 is that Timer B in the CIA can operate in continuous mode rather than the VIA Timer B's one-shot only mode. Timer B is used for the receive function, and on the VIC-20 that meant manually re-loading the timer latches for each incoming bit expected. On the C64/128 that could have been avoided (and the service code made shorter and faster) by using Timer B in continuous mode, automatically re-loading the value stored in the timer latches to Timer B for each bit.

That's one of the changes Hug made to the routines in his "Toward 2400" article. He also finessed a hardware bug present in many but not all 6526's (though why some worked and some didn't isn't clear).

Posted: **Fri Sep 14, 2012 5:26 am**

teamtempest wrote:

IIRC, the main hardware difference w/r/t software RS-232 is that Timer B in the CIA can operate in continuous mode rather than the VIA Timer B's one-shot only mode. Timer B is used for the receive function, and on the VIC-20 that meant manually re-loading the timer latches for each incoming bit expected. On the C64/128 that could have been avoided (and the service code made shorter and faster) by using Timer B in continuous mode, automatically re-loading the value stored in the timer latches to Timer B for each bit.

Your recollection is correct. The C-64/C-128 RS-232 code needlessly reloaded the latches after each time-out.

Quote:

That's one of the changes Hug made to the routines in his "Toward 2400" article. He also finessed a hardware bug present in many but not all 6526's (though why some worked and some didn't isn't clear).

Hug dealt with the random failure of the timer-B interrupt that I earlier mentioned.

Around the time Hug's article came out I was on the phone almost weekly with Fred Bowen at CBM on various matters and discussion ensued about this problem. He had said something to the effect that CSG was well aware of the problem and thought that it was caused when the 6526's mask was developed. Evidently someone must have looked at the design and found nothing wrong, yet random 6526s would have this defect. To my knowledge it was never corrected and was quite widespread. It wasn't a concern of mine at the time. I had a cheap hardware solution that was solid. In any case, CBM discontinued the C-128D in 1989 (I learned about the machine's impending demise in late 1988 but was sworn to secrecy) and we all know what happened to them five years later. Huge investment in the Amiga, from which no profit of significance was made.

Posted: **Fri Sep 14, 2012 6:30 am**

Quote:

IIRC, the main hardware difference w/r/t software RS-232 is that Timer B in the CIA can operate in continuous mode rather than the VIA Timer B's one-shot only mode. Timer B is used for the receive function, and on the VIC-20 that meant manually re-loading the timer latches for each incoming bit expected. On the C64/128 that could have been avoided (and the service code made shorter and faster) by using Timer B in continuous mode, automatically re-loading the value stored in the timer latches to Timer B for each bit.

Timer 2 in the 6522 is normally one-shot, but not when used to set the shift rate of the serial port. In the latter case it does not have to keep being re-loaded, and you can even keep sending out the same byte continually in free-run mode, as I show in Tip #5 for using it as a 9-level PWM for D/A output suitable for things like DTMF and speech. T2 is also for counting pulses on PB6. Its functions are different from those of T1.

Posted: **Sat Sep 15, 2012 12:09 am**

Quote:

Timer 2 in the 6522 is normally one-shot, but not when used to set the shift rate of the serial port.

The software RS232 routines of the VIC-20/C64/128 do not use the serial port. Timer B is used to determine when to sample an input pin in one of the data ports.

It wasn't until the C128 and the 1571 disk drive that the serial port of the CIA was used to implement "burst" mode communication between the computer and the drive. The hardware to do it was present in the C64 and 1541 drive, but never used for that purpose.

Posted: **Sun Sep 16, 2012 10:20 am**

OK guys, I need your help one more time.
I rewrote my 68.2k routine to check for timeout. This adds 7 cycles to the first wait for start bit loop. And now for the hell of me I can't cycle-up the thing. Please advise

Here's the code:

Code: Select all

read_from_serial        ldx     #$3f


wb:                   ;this is the additional 7 cycle
                        bit    porta
                        bvc    err1
                        
                        BIT     portb   ;<- startbit.
                        BVC     wb              ;not taken = 3c


                        #cycle #13-8

                        CPX     portb   ; b0    ;4c
                        ROR     @               ;2c
                        #cycle #9

                        CPX     portb   ; b1
                        ROR     @
                        #cycle #9

                        CPX     portb   ; b2
                        ROR     @
                        #cycle #9

                        CPX     portb   ; b3
                        ROR     @
                        #cycle #9

                        CPX     portb   ;b4
                        ROR     @
                        #cycle #9

                        CPX     portb   ;b5
                        ROR     @
                        #cycle #9

                        CPX     portb   ;b6
                        ROR     @
                        #cycle #9 ;8    ;9

                        CPX     portb   ;b7
                        ROR     @
                        nop

                        sta     (bufptr),y
                        iny
                        cpy     count
                        BNE     wb
                        rts

I threw away checksumming for now but that's not the problem.

What I get if I send all $AAs is:

Code: Select all

0000: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ****************
0010: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ****************
0020: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ****************
0030: aa a8 ac ac ac a4 b4 b4 b4 d4 d4 d4 54 54 54 54    *(,,,$444TTTTTTT
0040: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ****************
0050: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ****************
0060: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ****************
0070: aa aa aa aa aa aa aa aa a8 ac ac ac b4 b4 b4 94    ********(,,,444.
0080: 94 d4 d4 d4 54 54 54 54 aa aa aa aa aa aa aa aa    .TTTTTTT********
0090: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ****************
00a0: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ****************
00b0: aa aa aa aa aa aa aa aa ac ac ac b4 b4 b4 d4 d4    ********,,,444TT
00c0: d4 54 54 54 aa aa aa aa aa aa aa aa aa aa aa aa    TTTT************
00d0: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ****************
00e0: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa    ****************
00f0: aa aa a8 ac ac a4 b4 b4 b4 d4 d4 d4 54 54 54 aa    **(,,$444TTTTTT*

Can you help? I am counting the cycles all day and can't come up with a good solution.
Bittime in 68.2 is 14.6 cycle.

Posted: **Sun Sep 16, 2012 3:57 pm**

Why have a nop in there?
It's not like you've got cycles to spare.

If the buffer crosses a page boundary that
will add a cycle.

The err1 check is an additional 6 cycles
(not 7, unless the branch is taken in which
case it presumably doesn't matter)

I count 146 cycles to read a byte if you
catch the start bit, and a byte time is 146.6,
pretty tight

Did you try it with 2 stop bits?

Time from the middle of the first data bit
to the middle of the last data bit is 102.6
cycles and you're using 105 (at 1us/c)
so you could afford to lose a couple there.

It looks to me like it should work.

edit:
I just realized I miscounted.
I get 152c to the next start bit if
you catch this one and 139c if you
miss but that's assuming 6 cycles
between reading the start bit and
reading the first data bit.

6c start bit to first data bit
105c first to last data bit (7 x 15)
18c for the end of the byte loop
10c for the beginning of the byte loop
139c total or +13
152c if you catch the start bit and loop at the beginning

if that 139c is actually more than 146.6c you'll never catch
(sync) to the start bit and eventually walk off the end of the
received byte

Does the err1 check have to be in the loop?
Could you, like, read for one or two bit times and
if you don't see a start bit then do the error check?

Posted: **Fri Sep 21, 2012 5:33 pm**

The buffer addressing could be rearranged to use
the implicit test for zero when y is changed

and let's stick it in the middle of the loop so that
the branch is not taken so as to save a cycle
so we'll just beq out of the loop instead

so change

Code: Select all

 iny           ;2
 cmp count     ;3
 bne wb        ;3

to

Code: Select all

 dey           ;2
 beq exit_loop ;2

there by saving 4c
(assume we can branch back to loop as part of
one of the intra byte/inter bit delays)

You could use a fixed buffer or self modifiying
code ie sta buf,y instead of sta (bufptr),y
saving 1c

This is the minimum time I could figure.
It's still 15c and you've only got 14.66c (one stop bit)

Code: Select all

 
 cpx  portb      ;0 b7
 ror  @          ;2
 sta  buf,y      ;5
 dey             ;2
 beq  exit_loop  ;2
 cpx  portb      ;4 check for start bit
 bcs  first_bit

So I can't see how to do it with one stop bit

Posted: **Fri Sep 21, 2012 8:30 pm**

Thank you bogax. Much appreciated.

Posted: **Fri Sep 21, 2012 10:15 pm**

On second thought
If it's possible to do the time out check after
we've given up looking for the start bit,
perhaps we can move enough stuff into the
inter bit delays to make it work.
Get's messy though.
Something like this:

Code: Select all

 ;  the buffer should start at a page boundary
 ;  so that  sta (bufptr),y will always be 6c
 ;
 ;  count will have to contain the actual count-1
 ;
 ;  part of the time we'll use a zp variable, byte
 ;  for the incoming byte so that we can use the
 ;  accumulator for other stuff 
 ;
 ;  absolute in the comments means use absolute
 ;  addressing to waste an extra cycle
 ;
 ;  bit zp is to any zp location as a 3c nop/delay

 ldx  #$3F
 ldy  #$FF
 lda  #$00
 sta  cksum
 clc
 jmp  ENTER_LOOP

LOOP
 cpx  portb      ;4  b6 107-113  109.97
 ror  @          ;2
 cpy  count      ;4  absolute
 beq  EXIT_LOOP  ;2
 nop             ;2

 cpx  portb      ;4  b7 121-127  124.63
 ror  @          ;2

 ;  using the bit instruction to test because we need
 ;  to keep the carry clear for the adc cksum 
ENTER_LOOP
 bit  portb      ;4  start bit
 bvs  BIT0       ;3  have to have a enough
 bit  portb      ;4  checks for the start bit here
 bvs  BIT0       ;3  to get the first one when you
 bit  portb      ;4  enter the loop
 bvs  BIT0       ;3
 bit  portb      ;4
 bvs  BIT0       ;3
 bit  porta      ;4
 bvc  err1       ;3  not sure where you'd want to go
 bvs  SOMEWHERE  ;3  if you haven't found a start bit
                 ;   but you haven't timed out yet
BIT0
 sta  (bufptr),y ;6  the first pass here will write $00
                 ;   to location $FF in the buffer
 adc  cksum      ;4  absolute  first pass the accumulator is $00
 adc  #$00       ;2
 cpx  portb      ;4  b0  19-25c   21.99
 ror  byte       ;5
 sta  cksum      ;4  absolute
 iny             ;2

 cpx  portb      ;4  b1  34-40   36.66
 ror  byte       ;5
 bit  zp         ;3  some zp location 3c nop/delay
 nop             ;2

 cpx  portb      ;4  b2  48-54   51.32
 ror  byte       ;5
 nop             ;2
 nop             ;2
 nop             ;2

 cpx  portb      ;4  b3  63-69   65.98
 ror  byte       ;5
 nop             ;2
 nop             ;2
 nop             ;2

 cpx  portb      ;4  b4  78-84   80.65
 ror  byte       ;5
 nop             ;2
 bit  zp         ;3  some zp location 3c nop/delay

 cpx  portb      ;4  b5  92-98   95.31
 lda  byte       ;4  absolute
 and  #$F8       ;2  put some zeros in there
 ror  @          ;2  to clear the carry
 bcc  LOOP       ;3
 

EXIT_LOOP
 nop             ;2
 cpx  portb      ;4  b7 122-128  124.63
 ror  @
 sta  (bufptr),y
 adc  cksum
 adc  #$00
 sta  cksum
 rts

edit: forgot to initialize the carry, accumulator,
cksum and y
y needs to be intialized to $FF
the first sta (bufptr),y will write $00
to $FF in the buffer
moved the iny so that it comes before
cpy else it would fail for count=$FF

6502.org

1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud

Re: 1Mhz 6502 bitbang 57kbaud