6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 4:14 am

All times are UTC




Post new topic Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Fri Jun 07, 2024 4:05 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
Welp, I found the problem, or at least *a* problem. Bad socket machine pin on the MAX232's R2OUT pin.
Attachment:
Frustrated Miss Piggy GIF.gif
Frustrated Miss Piggy GIF.gif [ 216.5 KiB | Viewed 548 times ]
I'm switching to dual-wipe for IC sockets next project.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 07, 2024 5:30 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
Paganini wrote:
CTS\: This is an input on the ACIA - pin 9...

RTS\: This is an output on the ACIA - pin 8...

Perhaps the attached will help in that regard:

Attachment:
File comment: TIA-232 w/Flow Control
tia232.gif
tia232.gif [ 14.59 KiB | Viewed 542 times ]

In the above, the connections on the left (“local”) side go to the UART.  CTS on the right (“remote”) side goes to RTS on the remote device; the remote side RTS goes to the remote device’s CTS, etc.  DTR, if needed, may be derived as shown—some remote devices will not go on line if their DSR inputs are not asserted.  If DTR needs to be controllable, then the larger MAX-238 should be used so something on the local side can assert/deassert DTR as required.  In applications using a modem, deasserting DTR is often the means by which the modem is disconnected from the phone line when a session is terminated.

The drawing shows the use of polarized capacitors for C1-C5, which was from the time when I was using tantalums with MAX transceivers.  Back in the 1980s when the MAX-232 became available, tantalums were the only 1 µF capacitors that weren’t bulky and didn’t exhibit leakage (electrolytics perform poorly in this application).  Since then, 1 µF MLCCs became available, offering both very low leakage and a package size similar to a corresponding tantalum.  The MLCC I use is Kemet part number C315C105K3R5TA.

One other thing: the MAX232-series of transceivers tend to inject a fair amount of noise into VCC when the serial interface is active.  Note C5, which is there to suppress that noise—use of such a capacitor is recommended by Maxim (mention of it is buried in the application notes).  In my POC units, I also place a 100 µF electrolytic as close to the MAX’s VCC pin as possible.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 07, 2024 6:36 pm 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 988
Location: Potsdam, DE
Yuri wrote:
Think you meant to direct this at Paganini :mrgreen:


Oops! Of course. But it applies whenever async serial stuff is working, or trying to work, together.

Neil


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 07, 2024 9:02 pm 
Offline
User avatar

Joined: Tue Feb 28, 2023 11:39 pm
Posts: 257
Location: Texas
Paganini wrote:
Attachment:
Frustrated Miss Piggy GIF.gif


As cool as Miss Piggy is, I don't think she'd have the patience to trouble shoot electrical circuits. XD

Pretty sure just about any of the Muppets' solution would be to just hit it with something until it "works".


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 08, 2024 2:35 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
BigDumbDinosaur wrote:
Perhaps the attached will help in that regard:
That's a great diagram, BDD! I wasn't having much luck finding similar things with google, the other day. Interesting note about capacitors too. Guess back then you couldn't just buy a 300 piece value pack of ceramic caps on Amazon for ten bucks. :D

I made some progress yesterday... after giving the MAX232 a new socket I got hardware flow control working, and polled / delayed rx/tx seems solid. I went on to try my interrupt-driven receive routines. These were working with the old Rockwell UART on the other board, but here on Blue August with the WDC part it seems to just spam interrupts constantly. I didn't have time to look to closely yesterday. Hopefully I didn't do something dumb like solder the pull-up to the wrong pin / rail...

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 08, 2024 4:12 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Paganini wrote:
I have a 4MHz breadboard computer. Using a Rockwell 65C51 I built a 3-wire serial connection. That one works fine. I duplicated that on an I/O board for Blue August, my faster wire-wrap-on-protoboard computer. Using the same Rockwell 65C51 and running Blue August at 4MHz, the duplicate 3-wire serial connection works fine. I replaced the Rockwell part with a WDC65C51 and clocked Blue August back up to 16MHz. Now the 3-wire serial connection [has intermittent glitches when receiving].

Two questions that somehow drifted to mind. Referring to the quote above, what happens if you replace the Rockwell part with a WDC65C51 and DON'T clock Blue August back up to 16MHz?

And, is the 1.8432 MHz oscillator rated to generate CMOS output levels, or do its specs only promise TTL levels? As a quick n dirty test, can you reduce/eliminate the glitches by hanging a pullup on the oscillator output?

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 08, 2024 6:30 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
Hi Jeff!
Dr Jefyll wrote:
Two questions that somehow drifted to mind. Referring to the quote above, what happens if you replace the Rockwell part with a WDC65C51 and DON'T clock Blue August back up to 16MHz?
I did do that, and in my memory it was a successful attempt; I didn't leave it in that configuration for very long, though, and since the glitches were intermittent I can't say for sure that it was 100% stable. I can pretty easily revert to that and give it another try, but see below.

Quote:
And, is the 1.8432 MHz oscillator rated to generate CMOS output levels, or do its specs only promise TTL levels? As a quick n dirty test, can you reduce/eliminate the glitches by hanging a pullup on the oscillator output?
It's this one: https://www.mouser.com/datasheet/2/96/C ... 665263.pdf I have the half-can variant with no output-enable that's rated at 50ppm.

This morning I got back to testing. I put a little tracking kludge in my ISR to help with debugging - whenever it executes it sends an 'i' to the serial port. I was getting lots and lots of 'i's. Sometimes Blue August would stabilize after a while and I could actually interact with WOZMON; other times it would just spam 'i's forever, like the interrupt wasn't being cleared. So, I disabled interrupts on the ACIA. No change. Disabled interrupts on the 65C02. *Still* no change. Checked all the IRQ lines on the scope and with my DMM. All holding steady at just over 5 volts. Pullups in the right place. I'm seeing lots of 'i's, but the scope is not triggering. I realize that my tracking kludge tells me when the ISR executes, but not necessarily when an actual hardware interrupt happens. I check through my code to make sure I haven't done something dumb like leave out a '#' or allowed a fall-through by leaving out a 'rts.' Everything seems OK. I remember that running at a slower clock speed yesterday seemed to improve things, so I start thinking maybe it's power/ground related. I fuss with adding a few connections between the main board and the IO board. I do manage to make the board totally unresponsive, but no improvements. The noisiest, hardest-switching IC on the board is the AC163 for the clock stretcher. I pull that out and replace it with an HC163. Like magic, the board now works perfectly.

This is a little disappointing. I had thought my careful ground layout and careful hand-wire-wrapped connections had resulted in a pretty robust board this time. Also, the HC163 has a longer setup time to parallel load, so the maximum clock speed is lower. (Going OK at 12.6MHz, but won't stretch at 14MHz.)

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Last edited by Paganini on Sat Jun 08, 2024 7:25 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 08, 2024 6:32 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Obviously late to this party (thread) as I don't have access via AT&T Fiber from home since November 2023...

Anyway, I did a fair amount of testing with the WDC 65C51 chips when they were first released. Before that, Bill Mensch also sent me a half dozen engineering samples of a few different step levels. I was able to get one of the engineering sample chips running with proper receive and transmit interrupt support running at 10MHz (RAM and EEPROM limited the CPU clock). Once the release ones came out (with the broken xmit bit) I was able to run fine with receive interrupts running but ended up doing a delay routine for transmit.

A couple things to possibly consider:

- I don't think anyone has tested the latest WDC 65C51 part at higher CPU clock rates, so perhaps step it down for testing.
- You might need to add some additional decoupling caps as you might be getting more noise from the WDC part.

I also used the WDC parts with a 3.6864MHz can oscillator and ran at 38.4K baud rate with no issues. I've always used RTS/CTS handshaking for ALL 65(C)51 implementations and never had problems. Back in the 80's I had a 6551 running in local loopback mode at 19.2K on a Vic-20 with no issues or data loss. Granted, it's an ancient design but it can still work.

No idea what your interrupt driven code looks like, but you might to grab my Micromon code from my Github page. It features an extendable BIOS with full interrupt-driven receive and transmit code for a 65(C)51 ACIA and a small monitor that fits within 1.75KB. If your hardware doesn't work with this, you most likely have a hardware problem ;-)

https://github.com/floobydust/Micromon-V1.2/

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 08, 2024 6:55 pm 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
Thanks Kevin! I have a copy of Micromon saved for study. In fact, earlier this week, I was checking my tx delay code against yours. :D

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 08, 2024 6:59 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
Paganini wrote:
Interesting note about capacitors too. Guess back then you couldn't just buy a 300 piece value pack of ceramic caps on Amazon for ten bucks. :D

No Amazon in those days, but we did have Radio Shack for emergency purchases.  :D

Quote:
...the WDC part it seems to just spam interrupts constantly.

Are you sure you don’t have the transmit interrupt enabled?  Due to the “stuck” TxD status bug, the TxD IRQ will be constant if enabled.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 09, 2024 9:38 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 988
Location: Potsdam, DE
BigDumbDinosaur wrote:

No Amazon in those days, but we did have Radio Shack for emergency purchases.  :D


Aye, at a quid each for a single resistor :shock:

Emergency only!

Neil


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 09, 2024 7:23 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
barnacle wrote:
BigDumbDinosaur wrote:

No Amazon in those days, but we did have Radio Shack for emergency purchases.  :D

Aye, at a quid each for a single resistor :shock:

Not only did they charge a lot for resistors and capacitors, they apparently thought 7400-series ICs were gold-plated—judging by the price!  On the other hand, their plastic project boxes were a good deal, as were their various perf boards.  I prototyped a lot of designs on those boards and still have some in my parts pile.

Attachment:
File comment: Locomotive Throttle Servo Control Prototype
throttle_servo_proto03.jpg
throttle_servo_proto03.jpg [ 418.48 KiB | Viewed 429 times ]
Attachment:
File comment: Locomotive Throttle Servo Control Prototype
throttle_servo_proto02.jpg
throttle_servo_proto02.jpg [ 672.58 KiB | Viewed 429 times ]
Attachment:
File comment: Locomotive Throttle Servo Control Prototype
throttle_servo_proto01.jpg
throttle_servo_proto01.jpg [ 551.47 KiB | Viewed 429 times ]

That little heatsink on the board is also a Radio Shack part—real handy for use with a regulator or power transistor in a TO-220 package.  I have used it in a number of finished products, such as in the below:

Attachment:
File comment: Engineer’s Controls
ctl_box_assy01_annotated.jpg
ctl_box_assy01_annotated.jpg [ 580.58 KiB | Viewed 429 times ]

The heatsink is circled in red.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 10, 2024 2:12 am 
Offline

Joined: Fri Mar 18, 2022 6:33 pm
Posts: 491
I still haven't managed to clear this up. I'm really stumped! My polled Rx routine works great:
Code:
;_ACIA_cin:
;       Polled version
;               lda     ACIA_STATUS
;               and     #$08
;               beq     _ACIA_cin               ; wait for character to arrive
;               lda     ACIA_DATA               ; got one!

;               jsr     _ACIA_cout              ; echo it
;               rts
but the interrupt driven one is occasionally one bit off.
Code:
irq:
                pha

                lda     ACIA_STATUS             ; Clear the interrupt
;       Assume the ACIA is the only soure of interrupts - have to add code if you want to use the VIA
                lda     ACIA_DATA
;               jsr     _INPUT_BUFFER_write
                jsr     _ACIA_cout              ; >DEBUG< ECHO

                pla
                rti
When I say "one bit," what I mean is that I send ASCII 0 (0011 0000) and every so often what I get back is ASCII ` (0110 0000). But *only* with the interrupt-driven receive. I *think* I have RTS/CTS flow control working, but that only seems like it has to do with whole bytes (i.e., deassert RTS when your input buffer is full). It seems to me that if I had a hardware bug my polling routine would also glitch, but it doesn't. :?:

_________________
"The key is not to let the hardware sense any fear." - Radical Brad


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 10, 2024 2:24 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
Paganini wrote:
Code:
irq:            pha

                lda ACIA_STATUS             ; Clear the interrupt
;Assume the ACIA is the only soure of interrupts - have to add code if you want to use the VIA
                lda ACIA_DATA
;               jsr _INPUT_BUFFER_write
                jsr _ACIA_cout              ; >DEBUG< ECHO  <<———

                pla
                rti

Are you sure the call to ACIA_cout is safe when made inside of your interrupt handler?  Also, let’s see the code in the _INPUT_BUFFER_write function.  Why is that even a subroutine?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 10, 2024 2:31 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Some things to think about:

- Never use a JSR routine in your interrupt handler... just don't.
- The routines you're using... any chance they are altering the X or Y index registers??

When writing an interrupt handler, always ensure ALL of your processor registers are saved on entry and restored on exit. Its worth the additional time to design and write a good interrupt handler that can manage all of the CPU registers and also discern between a BRK instruction and a hardware interrupt.

I would also recommend you add a software buffer for the interrupt handler to fill from the 6551 ACIA. As it stands now, how long (in clock cycles) is your current handler? Any chance the two JSR routines might take longer than a single character time baud rate? Also, if you're doing an echo by sending the character back via the transmit function of the 6551, that's a problem as you have a delay routine (with the WDC W65C51 chip with the xmit bug) that takes a full character time plus.... hence you'll likely miss a received character.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 46 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: