Finally starting the schematic for my first W65C02 SBC

Building your first 6502-based project? We'll help you get started here.
billylegota
Posts: 60
Joined: 31 Mar 2016
Location: Austin, Texas
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by billylegota »

BigEd wrote:
If you have one high priority device that you really care about servicing quickly, that's what NMI is for. Acorn's Beeb uses NMI for the (optional) floppy disk controller - there are very few ticks available to service incoming bytes from floppy.

For serial, even at 115200 baud you have 86 ticks to deal with each byte (or more if you're running faster than 1MHz) so IRQ is probably good enough. The usual approach is for the interrupt service routine to check the most urgent chip first - for example, check the serial chip before the timer chip, if you think you might otherwise miss bytes. Or, if you're running a high speed timer for some critical reason, check the timer chip first.
So as long as I keep my ISR code short and sweet I should be able to service both my serial port and timer (at 2MHz). I will probably end up having the serial port take precedence over the timer. In my application (a simple terminal) it doesn't really matter so much if my timing is off a tiny bit as long as my display isn't garbled and my keystrokes aren't ignored.
- Billy
billylegota
Posts: 60
Joined: 31 Mar 2016
Location: Austin, Texas
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by billylegota »

BigDumbDinosaur wrote:
VPB is one of those signals that a first-time builder should not be considering. As Jeff suggested, ignore it for now. That said, I'll explain how it could be used.

When a hardware interrupt occurs or a BRK instruction is executed, the MPU executes a series of steps to save its state on the stack and then jumps to the interrupt service handler (ISR) code. The jump occurs by loading the program counter from a location in memory that points to the ISR that is expected to process the interrupt. As there are several interrupt types, there are several addresses involved, which are collectively referred to as the interrupt vectors. On the 65C02 or the 65C816 when operating in 65C02 emulation mode, the vectors are as follows:

Code: Select all

$FFFA/$FFFB  non-maskable interrupt (NMI)
$FFFC/$FFFD  hardware reset
$FFFE/$FFFF  interrupt request (IRQ)
The addresses stored at these vectors are often burned into ROM, but in a unit whose operating system runs from RAM, the vectors will likewise be in RAM and could be changed. However, it gets even more interesting.

A system could be designed to prioritize IRQs, which means it would have hardware logic that can identify each interrupting device and assign it an ordinal number (interrupt number). A pecking order can be established based upon the interrupt number, making some interrupts more important than others. Nowadays, this function would be part of the glue logic in a CPLD or FPGA, but in the past was done with discrete devices. In either case, the glue logic, upon detecting an IRQ and determining which device caused it, could trick the MPU into jumping directly to the ISR for the interrupting device, eliminating the need to check all devices to see which one is interrupting. The result would be improved interrupt processing performance.

The trickery comes in two parts:
  1. The glue logic does nothing until the MPU asserts the VPB output, that is, pulls it low. When VPB goes low it means the MPU is fetching from the interrupt vector. It does this by performing consecutive reads from the least significant byte (LSB) at the vector address (at $FFFE in the case of an IRQ) and then the most significant byte (MSB) at the vector address (at $FFFF in the case of an IRQ). The address bytes are internally loaded by the MPU into the program counter (PC).
  2. The glue logic, in response to VPB going low, prevents ROM or RAM from actually driving the data bus and instead, takes control and places an alternate ISR address on it, first the LSB and then the MSB. That address is determined by the glue logic analyzing the interrupt number that it generated when a device interrupted. The MPU is none the wiser that the glue logic is talking to it and loads the alternate address into PC instead of the address at $FFFE/$FFFF. Hence execution is directed to the ISR associated with the interrupting device.
The logic to do all this is not particularly simple to implement, which is why it is something best left for a future project.
As you have said, it is quite a bit more complex implementation-wise so I won't be using it on this project. However, it certainly sounds like something that would be useful in a system that has a large number of interface ICs (or something that would be interesting to implement in a future project).
- Billy
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by BigEd »

(Worth noting that the VPB handling hardware is only needed if you have several interrupt sources and need to minimise the handling time of more than one of them. That turns out to be a rare case. But if it happens, it's nice to have a supported solution for it.)
User avatar
floobydust
Posts: 1394
Joined: 05 Mar 2013

Re: Finally starting the schematic for my first W65C02 SBC

Post by floobydust »

billylegota wrote:
BigEd wrote:
If you have one high priority device that you really care about servicing quickly, that's what NMI is for. Acorn's Beeb uses NMI for the (optional) floppy disk controller - there are very few ticks available to service incoming bytes from floppy.

For serial, even at 115200 baud you have 86 ticks to deal with each byte (or more if you're running faster than 1MHz) so IRQ is probably good enough. The usual approach is for the interrupt service routine to check the most urgent chip first - for example, check the serial chip before the timer chip, if you think you might otherwise miss bytes. Or, if you're running a high speed timer for some critical reason, check the timer chip first.
So as long as I keep my ISR code short and sweet I should be able to service both my serial port and timer (at 2MHz). I will probably end up having the serial port take precedence over the timer. In my application (a simple terminal) it doesn't really matter so much if my timing is off a tiny bit as long as my display isn't garbled and my keystrokes aren't ignored.
As you start to write your interrupt handler, you may want to take read at this thread... detailed analysis of servicing a serial port and the CPU resources it takes. My Current C02 BIOS is at version 1.3 and supports a 65C51 and 65C22. It's easily extendable and fits in 753 bytes.

viewtopic.php?f=2&t=2849&start=0
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by BigDumbDinosaur »

BigEd wrote:
(Worth noting that the VPB handling hardware is only needed if you have several interrupt sources and need to minimise the handling time of more than one of them. That turns out to be a rare case. But if it happens, it's nice to have a supported solution for it.)
VPB could also be used for other purposes, which I discussed some time ago in my POC V2 thread on memory management. However, in most of the systems we design, VPB is one of those MPU outputs (like MLB and the 65C816's E and MX signals) that is merely along for the ride.

During the design of POC V2, I considered implementing a fully vectored IRQ setup using VPB, but set the idea aside due to CPLD resource constraints and a lack of need. As you noted, the value of a vectored interrupt system comes when there are many interrupt sources to be serviced and some are very high priority. V2 only has three possible IRQ sources: the RTC, the QUART and the SCSI host adapter. Since I transferred the responsibility for generating the jiffy IRQ to the DUART in POC V1, the RTC doesn't generate interrupts for anything at this time, and the same will be the case in V2. So I only have two interrupt sources to poll. The code required to do so is succinct, which makes a vectored interrupt system an unnecessary luxury.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by BigDumbDinosaur »

billylegota wrote:
So as long as I keep my ISR code short and sweet I should be able to service both my serial port and timer (at 2MHz). I will probably end up having the serial port take precedence over the timer. In my application (a simple terminal) it doesn't really matter so much if my timing is off a tiny bit as long as my display isn't garbled and my keystrokes aren't ignored.
Presumably you've read Garth's 6502 interrupt primer. If so, then you've seen some good advice on how to structure efficient ISRs. ISR software engineering is also discussed in my 65C816 interrupt article, which although geared to the '816, has material that is applicable to the 65C02. Also, be sure to read the section on spurious interrupts, which Garth likewise discusses in his article.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
billylegota
Posts: 60
Joined: 31 Mar 2016
Location: Austin, Texas
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by billylegota »

Thanks for all the info. I have decided to omit the /VP pin. I have also made note to read the articles provided by BDD and floobydust when it comes time to start writing some code (which will need to wait for obvious reasons).

On a side note, I am currently only going to use the ACIA for interfacing with this video terminal. As such, I won't need the handshake lines on the ACIA. What should I do with them?

I am also just hooking up the IO on the VIA to a set of 5x2 headers. What should I do with the CA1, CA2, CB1, and CB2 pins?
- Billy
User avatar
GARTHWILSON
Forum Moderator
Posts: 8774
Joined: 30 Aug 2002
Location: Southern California
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by GARTHWILSON »

billylegota wrote:
Thanks for all the info. I have decided to omit the /VP pin. I have also made note to read the articles provided by BDD and floobydust when it comes time to start writing some code (which will need to wait for obvious reasons).
Be sure to go through the 6502 primer's section 20 on programming tips first, as some of them affect hardware hook-up decisions, because there are special functions for VIA bits 0, 6, and 7 afforded by the instruction set.
Quote:
On a side note, I am currently only going to use the ACIA for interfacing with this video terminal. As such, I won't need the handshake lines on the ACIA. What should I do with them?
  • The ACIA's transmitter is automatically disabled if the CTS\ input is high; so you'll need to ground it.
  • The DCD\ input must be low for the receiver to operate; so ground that too.
  • The other inputs can be taken high or low, but should not be left floating.
  • The RTS\ and DTR\ outputs can be left unconnected.
Pulling these unused inputs high or low would ideally be done through a high-value resistor so you can connect and use them later if you choose, without having to undo a ground connection which may be difficult, depending on the construction method.
Quote:
am also just hooking up the IO on the VIA to a set of 5x2 headers. What should I do with the CA1, CA2, CB1, and CB2 pins?
I hope I can convince you to make them available. I have never used them as printer handshake lines, but they're useful for a lot of other things. See the 6502 primer's "circuit potpourri" page, and "Tip of the Day." If you don't use them, you could pull them up with a weak pull-up resistor. WDC's W65C22S has true CMOS inputs, but other brands are more like TTL or LSTTL in the input mode, so you can't pull them down with a resistor and expect to use them later. (I found out the hard way.)

I also would encourage making the pin headers symmetrical with regard to power and ground, so accidentally plugging an IDC on backwards won't damage anything. I show this at the right end of the diagram at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU .
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?
billylegota
Posts: 60
Joined: 31 Mar 2016
Location: Austin, Texas
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by billylegota »

GARTHWILSON wrote:
billylegota wrote:
Thanks for all the info. I have decided to omit the /VP pin. I have also made note to read the articles provided by BDD and floobydust when it comes time to start writing some code (which will need to wait for obvious reasons).
Be sure to go through the 6502 primer's section 20 on programming tips first, as some of them affect hardware hook-up decisions, because there are special functions for VIA bits 0, 6, and 7 afforded by the instruction set.
Quote:
On a side note, I am currently only going to use the ACIA for interfacing with this video terminal. As such, I won't need the handshake lines on the ACIA. What should I do with them?
  • The ACIA's transmitter is automatically disabled if the CTS\ input is high; so you'll need to ground it.
  • The DCD\ input must be low for the receiver to operate; so ground that too.
  • The other inputs can be taken high or low, but should not be left floating.
  • The RTS\ and DTR\ outputs can be left unconnected.
Pulling these unused inputs high or low would ideally be done through a high-value resistor so you can connect and use them later if you choose, without having to undo a ground connection which may be difficult, depending on the construction method.
Quote:
am also just hooking up the IO on the VIA to a set of 5x2 headers. What should I do with the CA1, CA2, CB1, and CB2 pins?
I hope I can convince you to make them available. I have never used them as printer handshake lines, but they're useful for a lot of other things. See the 6502 primer's "circuit potpourri" page, and "Tip of the Day." If you don't use them, you could pull them up with a weak pull-up resistor. WDC's W65C22S has true CMOS inputs, but other brands are more like TTL or LSTTL in the input mode, so you can't pull them down with a resistor and expect to use them later. (I found out the hard way.)

I also would encourage making the pin headers symmetrical with regard to power and ground, so accidentally plugging an IDC on backwards won't damage anything. I show this at the right end of the diagram at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU .
I really like the reversible header idea... I was originally planning to get headers that only plug in the correct way, but now I can just use the headers I have anyway!
- Billy
billylegota
Posts: 60
Joined: 31 Mar 2016
Location: Austin, Texas
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by billylegota »

I have finally finished my first presentable schematic (all the others looked even worse)!

I am going to present the design to my mom and dad (who are CS and EE majors respectively) later but I would love input + criticism (especially criticism) from anyone who has time.

Main Schematic:
Main.png
Clock Gen:
Clock.png
Reset:
Reset.png
Interrupt:
Interrupt.png
Power + Bypass:
Power.png
- Billy
billylegota
Posts: 60
Joined: 31 Mar 2016
Location: Austin, Texas
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by billylegota »

Here is the schematic file if needed (diptrace):
SBC.zip
(39.47 KiB) Downloaded 97 times
Last edited by billylegota on Wed Apr 13, 2016 1:51 pm, edited 1 time in total.
- Billy
User avatar
GARTHWILSON
Forum Moderator
Posts: 8774
Joined: 30 Aug 2002
Location: Southern California
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by GARTHWILSON »

The OE\ of the RAM needs to go to A14 so the RAM won't output data when you're trying to read I/O.
WDC recommends adding a 1M resistor from pin 6 to pin 7 of the ACIA.
With a short look of a few minutes, I don't see any other problems.
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?
billylegota
Posts: 60
Joined: 31 Mar 2016
Location: Austin, Texas
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by billylegota »

GARTHWILSON wrote:
The OE\ of the RAM needs to go to A14 so the RAM won't output data when you're trying to read I/O.
WDC recommends adding a 1M resistor from pin 6 to pin 7 of the ACIA.
With a short look of a few minutes, I don't see any other problems.
Ahhh, the logic I had only checked to see if A15 was low (/CS and /OE was (A15' & PHI2)') so I need to connect A14 to /OE.

On that note, won't I need to do something about /WE on the RAM as well? As it stands /WE on the RAM is connected to R/W on the W65C02, which if I am correct will allow the RAM to be written to when A15 is low regardless of the state of A14 (unless I am wrong and /OE and /WE must be low in order to write). This really doesn't matter right now because it would be writing to the upper half of the memory (which can't be read) but I do have an extra gate on my 74AC00 which I could use to prevent this.
- Billy
User avatar
GARTHWILSON
Forum Moderator
Posts: 8774
Joined: 30 Aug 2002
Location: Southern California
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by GARTHWILSON »

Writing to the upper half of the RAM when you're writing to I/O is fine. You're not using that portion of the RAM, so overwriting it is ok. It doesn't even add any extra load to the bus. It's not a problem and there's no need to fix it.
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?
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Finally starting the schematic for my first W65C02 SBC

Post by BigDumbDinosaur »

billylegota wrote:
Ahhh, the logic I had only checked to see if A15 was low (/CS and /OE was (A15' & PHI2)') so I need to connect A14 to /OE.
Future note: gating chip selects (e.g., /CS on the ROM) with Ø2 is not a good idea if performance matters. The address bus becomes valid during Ø2 low on all 65xx MPUs, at which time chip selection should occur. The idea is to have the device ready for access as soon as Ø2 goes high. Commensurate with that is that /RD and /WD should be gated by Ø2 so those signals don't go true (low) until Ø2 is high. If using a 65C816, it is essential that no device be allowed to write to the data bus during Ø2 low, as that is when the '816 drives the data bus with the bank bits (A16-A23).

In the case of 65xx peripherals (65C22, etc.), Ø2 from your clock generator should be directly connected to Ø2 on each 65xx peripheral, RWB on the MPU must be connected directly to RWB on the 65xx peripherals, and chip selection must occur during Ø2 low and be maintained until the next fall of the clock. A failure to meet those conditions will result in a failure to operate when access to a 65xx peripheral is attempted.

WDC recommends that all timing be relative to the Ø2 clock, and that the Ø1 out and Ø2 out signals (pins 3 and 39, respectively) not be used. Here is their advisory on the matter (page 10 in the data sheet):
  • An external oscillator is recommended for driving PHI2 and used for the main system clock. All production test timing is based on PHI2. PHI2O and PHI1O were used in older systems for system timing and internal oscillators when an external crystal was used.
Ø1 out and Ø2 out exist primarily to allow a 65C02 to be fitted to a system that was designed with an NMOS 6502. Both signals slightly lag Ø2 by an unspecified amount, which in a high speed system, may result in difficult-to-resolve timing issues. WDC neither tests or guarantees the timing of those signals.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Post Reply