6502.org Forum Projects Code Documents Tools Forum
It is currently Thu May 09, 2024 11:39 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Newbies

All times are UTC




Post new topic Reply to topic  Page 2 of 2
  [ 21 posts ]  Go to page Previous  1, 2
  Previous topic | Next topic 
Author Message
GARTHWILSON
PostPosted: Mon Apr 25, 2022 7:57 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8432
Location: Southern California
zrthxn wrote:
Something I'm still struggling with is, how would the 6522 know if the device on any particular port has finished putting data on the port? For example, the USB interface chip I'm currently using has two lines, ~RD and WR, which indicate when the parallel output is available. But how would the 6522 know this so it can trigger an interrupt?

I've used nearly all of the many different features of the '22, but automatic handshaking has not been one of them. The data sheet addresses it though, starting in section 2.2 on page 10.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Tue Apr 26, 2022 12:10 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8177
Location: Midwestern USA
GARTHWILSON wrote:
I've used nearly all of the many different features of the '22, but automatic handshaking has not been one of them. The data sheet addresses it though, starting in section 2.2 on page 10.

Don’t know how well the 65C22’s automatic handshake works, but I recall it didn't work well in Commodore’s 6526, at least in one application. I tried setting up the user port on a C-128 as a Centronics port to drive a parallel printer, using the auto-handshake to toggle the printer’s /STROBE input. The printer wouldn’t respond, which I later discovered was a timing issue with auto-handshake.

The Centronics standard requires that a minimum of one microsecond elapse after D0-D7 is written before toggling /STROBE. After being driven low, /STROBE must stay low for at least one microsecond before going high. What was happening was the 6526 was toggling /STROBE around 100 nanoseconds after driving the data onto D0-D7. The required setup time before /STROBE was being toggled was insufficient to give the device at the other end enough “warning” that data was on the way.

I ended up using one of the port-B lines as /STROBE, since I could control the elapsed time from when D0-D7 was written to when the remote device was strobed.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
zrthxn
PostPosted: Tue Apr 26, 2022 8:21 pm 
Offline

Joined: Sat Apr 23, 2022 5:59 am
Posts: 8
Re: GARTHWILSON
Re: BigDumbDinosaur

GARTHWILSON wrote:
I've used nearly all of the many different features of the '22, but automatic handshaking has not been one of them. The data sheet addresses it though, starting in section 2.2 on page 10.
The way I'm thinking of doing it is, this. This is all with the FT245RL USB controller in mind.

READ FROM USB
Controller's !RD is set low via PORTB line 0, by default. USB data is now shifting into controller and thus onto PORT A from the connected device.
Controller pulls !RXF low (it does this internally), connected to VIA's CA1 indicating that the data is ready, PORT A is latched onto DATA bus and IRQ is set.

WRITE TO USB
Controller sets its !TXE low, indicating it is ready to receive data, connected to VIA's CA1.
When the VIA's both CS are active, i.e. it has been addressed and the CPU is writing (R!W is low), it latches DATA bus onto PORT A, since CA1 is low.
On the next clock edge, we set the controller's WR high (via PORTB line 1) and it starts transmitting the data on PORT A to the USB lines.
And on the next clock edge to that, we set the WR low again.

This scheme assumes it takes less time than one CPU clock cycle to transmit one byte over the USB lines.
Please let me know what you think. Have I misunderstood or made an error?
Top
 Profile  
Reply with quote  
gfoot
PostPosted: Tue Apr 26, 2022 10:59 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
BigDumbDinosaur wrote:
The Centronics standard requires that a minimum of one microsecond elapse after D0-D7 is written before toggling /STROBE. After being driven low, /STROBE must stay low for at least one microsecond before going high. What was happening was the 6526 was toggling /STROBE around 100 nanoseconds after driving the data onto D0-D7. The required setup time before /STROBE was being toggled was insufficient to give the device at the other end enough “warning” that data was on the way.

I've mostly used the mode where it automatically sends just a single clock cycle pulse, to clock flipflops or latches automatically after I write to a port. But if you're connecting to some existing protocol then I guess you have to be lucky and find it matches what the 6522 can do.

There is a mode where it holds one handshake line low until the remote end pulls the other one low to confirm receipt. Maybe that would have worked better for the printer you used - I think the BBC Micro did use it this way for example.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Wed Apr 27, 2022 4:33 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8177
Location: Midwestern USA
gfoot wrote:
There is a mode where it holds one handshake line low until the remote end pulls the other one low to confirm receipt. Maybe that would have worked better for the printer you used - I think the BBC Micro did use it this way for example.

Centronics-style printers respond to the rising edge of /STROBE. Only after /STROBE has gone high and the printer has digested the datum will it assert /ACK (/ACK was the original handshake—BUSY was a later aberration). The standard doesn’t define how soon after the rise of /STROBE the printer must assert /ACK.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
drogon
PostPosted: Wed Apr 27, 2022 8:19 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1405
Location: Scotland
gfoot wrote:

There is a mode where it holds one handshake line low until the remote end pulls the other one low to confirm receipt. Maybe that would have worked better for the printer you used - I think the BBC Micro did use it this way for example.


The Beeb uses Port A of one of the VIAs in a more or less standard data+strobe... wait for ack mode. I used several different printers with it, never noticed any issues - it "just worked" from what I recall.

Extract of the schematic here:

Attachment:
Screenshot_2022-04-27_09-14-33.png
Screenshot_2022-04-27_09-14-33.png [ 1.41 MiB | Viewed 429 times ]


The busy signal isn't used, but the ACK from the Printer goes to CA1 and the Strobe comes from CA2.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 2 of 2
  [ 21 posts ]  Go to page Previous  1, 2

Board index » 6502.org Users Forum » Newbies

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 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:  
6502.org is an ongoing project by Mike Naberezny and contributors.