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.
Finally starting the schematic for my first W65C02 SBC
-
billylegota
- Posts: 60
- Joined: 31 Mar 2016
- Location: Austin, Texas
- Contact:
Re: Finally starting the schematic for my first W65C02 SBC
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.
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.
- Billy
-
billylegota
- Posts: 60
- Joined: 31 Mar 2016
- Location: Austin, Texas
- Contact:
Re: Finally starting the schematic for my first W65C02 SBC
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:
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:
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)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:
- 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).
- 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.
- Billy
Re: Finally starting the schematic for my first W65C02 SBC
(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.)
- floobydust
- Posts: 1394
- Joined: 05 Mar 2013
Re: Finally starting the schematic for my first W65C02 SBC
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.
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.
viewtopic.php?f=2&t=2849&start=0
Regards, KM
https://github.com/floobydust
https://github.com/floobydust
- 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
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.)
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!
- 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
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.
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
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?
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
- GARTHWILSON
- Forum Moderator
- Posts: 8775
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Re: Finally starting the schematic for my first W65C02 SBC
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).
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.
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 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?
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
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).
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.
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 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 .
- Billy
-
billylegota
- Posts: 60
- Joined: 31 Mar 2016
- Location: Austin, Texas
- Contact:
Re: Finally starting the schematic for my first W65C02 SBC
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: Clock Gen: Reset: Interrupt: Power + Bypass:
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: Clock Gen: Reset: Interrupt: Power + Bypass:
- Billy
-
billylegota
- Posts: 60
- Joined: 31 Mar 2016
- Location: Austin, Texas
- Contact:
Re: Finally starting the schematic for my first W65C02 SBC
Here is the schematic file if needed (diptrace):
Last edited by billylegota on Wed Apr 13, 2016 1:51 pm, edited 1 time in total.
- Billy
- GARTHWILSON
- Forum Moderator
- Posts: 8775
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Re: Finally starting the schematic for my first W65C02 SBC
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.
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?
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
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.
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.
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
- GARTHWILSON
- Forum Moderator
- Posts: 8775
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Re: Finally starting the schematic for my first W65C02 SBC
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?
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
- 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
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.
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.
x86? We ain't got no x86. We don't NEED no stinking x86!