6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue Sep 24, 2024 1:17 pm

All times are UTC




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: W65C02S BE signal
PostPosted: Mon Oct 21, 2013 10:14 pm 
Offline

Joined: Mon Nov 11, 2002 6:53 pm
Posts: 79
Location: Seattle
Hi There!

Been ages since I've been here! I'm considering changing my board over from a z80 to a W65c02. It's a custom board coupled with an FPGA that uses DMA. On the Z80, it's pretty straightforward using /busreq and getting a /busack back. Anyone know how the W65c02(s) let's you know when the bus has tristated? The datasheet is a little sparse..

Thanks!


Top
 Profile  
Reply with quote  
 Post subject: Re: W65C02S BE signal
PostPosted: Tue Oct 22, 2013 12:40 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8392
Location: Midwestern USA
yzoer wrote:
Anyone know how the W65c02(s) let's you know when the bus has tristated? The datasheet is a little sparse.

To quote the W65C02S data sheet:

    3.2 Bus Enable (BE)

    The Bus Enable (BE) input signal provides external control of the Address, Data and the RWB buffers. When Bus Enable is high, the Address, Data and RWB buffers are active. When BE is low, these buffers are set to the high impedance status. Bus Enable is an asynchronous signal.

Note the last sentence. If you want to get the 65C02 to relinquish control of the buses so you can do DMA, start a second MPU, etc., first halt it by asserting RDY whenever convenient, then assert BE to tri-state the buses. To restart the 65C02, deassert BE and then deassert RDY. The 'C02 will start on the next Ø2 high. You don't need a /BUSACK signal like with the Z80, since the 'C02 will do what it's told, when it's told.

Also note:

    3.5 Memory Lock (MLB)

    The Memory Lock (MLB) output may be used to ensure the integrity of Read-Modify-Write instructions in a multiprocessor system. Memory Lock indicates the need to defer arbitration of the bus cycle when MLB is low. Memory Lock is low during the last three cycles of ASL, DEC, INC, LSR, ROL, ROR, TRB, and TSB memory referencing instructions.

Incidentally, for your application, you probably should wait until SYNC goes high before asserting RDY and BE. Doing so will stop the 'C02 on the opcode fetch cycle, which should eliminate the need to monitor MLB, as the 'C02 will halt before it gets to the W part of R-M-W instructions. The same thing can be accomplished with the 65C816 by asserting RDY and BE when the expression VDA && VPA is true.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: W65C02S BE signal
PostPosted: Tue Oct 22, 2013 1:21 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
yzoer wrote:
I'm considering changing my board over from a z80 to a W65c02.
Welcome back from the dark side! :D

As noted by BDD, Bus Enable is an asynchronous signal. What this means is that, unlike the z80, the W65c02 has no bus arbitration circuitry on-chip. You supply the hardware that manages the handover of the bus -- and suspends the CPU, using RDY. (Coupla gates & flip-flops... it's not that difficult. I expect it'd be a piece of cake with an FPGA.)

Quote:
Anyone know how the W65c02(s) let's you know when the bus has tristated?
To be clear, there's no need to let you know. You can be sure the bus is tristated simply by negating BE then waiting a few nanoseconds. (For the exact figure, check tBV in the timing diagram.)

BigDumbDinosaur wrote:
Also note:
3.5 Memory Lock (MLB) [etc]
Needless detail, IMO. The vast majority of DMA applications (eg: straight-forward Input/Output from an ordinary peripheral device) can ignore MLB, and also SYNC/VPA/VDA. An exception would be if the other device sharing the bus were another processor, and the two processors required a system of shared semaphores in memory.

cheers
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  
 Post subject: Re: W65C02S BE signal
PostPosted: Tue Oct 22, 2013 5:43 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8392
Location: Midwestern USA
Dr Jefyll wrote:
BigDumbDinosaur wrote:
Also note:
3.5 Memory Lock (MLB) [etc]
Needless detail, IMO. The vast majority of DMA applications (eg: straight-forward Input/Output from an ordinary peripheral device) can ignore MLB, and also SYNC/VPA/VDA. An exception would be if the other device sharing the bus were another processor, and the two processors required a system of shared semaphores in memory.

BigDumbDinosaur wrote:
Incidentally, for your application, you probably should wait until SYNC goes high before asserting RDY and BE. Doing so will stop the 'C02 on the opcode fetch cycle, which should eliminate the need to monitor MLB, as the 'C02 will halt before it gets to the W part of R-M-W instructions.
:D

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


Top
 Profile  
Reply with quote  
 Post subject: Re: W65C02S BE signal
PostPosted: Tue Oct 22, 2013 6:04 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
yzoer wrote:
Hi There!

Been ages since I've been here! I'm considering changing my board over from a z80 to a W65c02. It's a custom board coupled with an FPGA that uses DMA. On the Z80, it's pretty straightforward using /busreq and getting a /busack back. Anyone know how the W65c02(s) let's you know when the bus has tristated? The datasheet is a little sparse..

Thanks!


Sounds interesting. In fact, I was thinking about doing something similar. Do you have your Z80 project described somewhere ?


Top
 Profile  
Reply with quote  
 Post subject: Re: W65C02S BE signal
PostPosted: Tue Oct 22, 2013 6:07 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
BigDumbDinosaur wrote:
Incidentally, for your application, you probably should wait until SYNC goes high before asserting RDY and BE. Doing so will stop the 'C02 on the opcode fetch cycle, which should eliminate the need to monitor MLB, as the 'C02 will halt before it gets to the W part of R-M-W instructions.

But unless you're doing multiprocessor design (or something with the same effect) there's no need to treat RMW instructions in a special way.


Top
 Profile  
Reply with quote  
 Post subject: Re: W65C02S BE signal
PostPosted: Tue Oct 22, 2013 5:11 pm 
Offline

Joined: Mon Nov 11, 2002 6:53 pm
Posts: 79
Location: Seattle
Thanks for all the replies guys. I'd completely forgotten about the RDY line! Makes total sense now and should be pretty straightforward to implement.

Main reason for me 'defecting' to the dark-side was that I got introduced to the z80 when I was doing gameboy work. Heck, that wasn't even a full z80 so it's kinda like being introduced to the dark side by Jar Jar Binks. Grew up on 6502 on the vic/c64.

Anyway, I really have no excuse really. Number of reasons I'm coming back is that it's a) cheaper, b) faster at the same clock rate and c) it can run at 3.3v! There's no 3.3v z80 equivalent and while it's possible to use level-shifters and what not, I'd rather not. A 20mhz z80 costs you $10 whereas a 14mhz 65c02 will run you $3 cheaper.

As far as my hardware design goes, I haven't put it up yet but will (hopefully) soon. First PCB batch had some design errors and while those weren't major, I'd like to re-design it and add a couple of new features. Like changing it over to a 6502 :-)

-Yvo


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 17 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: