There is the input capacitance of the RDY input, plus a significant amount of stray inductance (~20 nH per inch of wire) and stray capacitance as well which will play a role, as well as the resistor. In my experience, modeling the poles and zeros can be very useful, but so is making careful measurements in order to gain insight into effects which are not always obvious (except possibly in hindsight).


I like active probes. Load capacitance is on the order of 1pF. Usually not a factor on PC boards up to a couple of hundred MHz. Certainly not a factor on a breadboard (other than finding a suitable nearby ground connection).

Despite what's been said, you can usually get away with a lot at the relatively low frequencies we're dealing with here, even on a breadboard. One need only look at what Brad has done with his Vulcan74 project to get some appreciation for that! I was surprised to note that he doesn't even bypass all of his logic chips yet everything still works!

So many ways to skin a cat! I like this method because it allows multiple active devices to be connected to the RDY line just like the wire-OR method, and Schottky diodes are almost free anyway.

With I2C devices, the rule of thumb for pullups is 10k for 100 kHz, and 2.2k for 400 kHz transfer rates at 5 volts. I'd worry that 3.3k wasn't enough if you were running clock rates near the device limit (14 MHz), but if you've already tried it and it works, so be it...

OK, the test system is now working with a wait state inserted for UART accesses. I used BDDs Schottky diode suggestion to connect the logic output to the RDY line and tested it up to 7.37 MHz without a hitch. Now it's time to replace the 68B50 with the PIC24FJ32 and see if I can get it talking to my PC terminal again without changing a line of code on the 6502 side.

I just remembered the PIC doesn't have enough 5V tolerant pins to make it practicable to interface it directly to the 6502 bus so I'm going to need to use those 74LVX4245s I picked up at Dr Jefyll's suggestion some time ago. Would have just switched everything over to 3.3 volts except the CY7C199 SRAM chips only work at 5 volts.

What do people like for SRAMs in 3.3 volt systems? I came across the ISSI IS61LV256AL-10TLI SRAMs, but they only come in a weird wide TSSOP form factor. They are fast (10 nS) and cheap though. Link to datasheet: http://www.issi.com/WW/pdf/61LV256AL.pdf

The 74LVX4245 is now about ready to mount on the breadboard. I was wondering whether it's worth mounting bypass caps directly on the carrier board, but I think I'll wait and see how it performs first.

At 3.3V the 65C02 supports only 8MHz so you can use the AS6C1008-55 or AS6C4008-55 which are specified for VCC = 2.7..5.5V.

If the 65c02 will run over 30 MHz at 5V (I believe Oneironaut tested this earlier as part of his Vulcan74 project), then I can't help but wonder if it won't run a lot faster than 8 MHz at 3.3 volts as well?

In any event, thank you for the suggestion. Not only do they run from 2.7 volts to 5.5 volts, they also come in large sizes and I don't have to do any soldering with them. I will pick up a couple to play with. In the worst case, I already have a wait state generator working...

I see they also make a 28-pin DIP in 32Kx8 as well, and a 5V-only 15nS part with specs which mirror the Cypress CY7C199 part.

They supposedly top out at about 25MHz at room temperature; but that's according to the data sheet as an interesting guideline, not a guarantee. I think what you're thinking of that Oneironaut did at over 30MHz was 74HC stuff. I don't think he has run the '02 over 4MHz. The data sheet should give a good idea of the relative max speed at one voltage versus another. I'd be delighted if someone found it would do 50MHz if you do the design and layout right and use fast-enough support parts!

_________________
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?

You had me worried that my memory was failing me, so I looked back through Brad's thread and found it: viewtopic.php?f=4&t=3329&start=150#p40449

He did say 25 MHz, not 30 MHz, so my memory is still not 100%, but I did remember he had a 6502 running at a surprisingly high speed.

Spent my free time today coding up part of the PIC-UART. With the built-in oscillator, looks like I'll be limited to about 115200 or maybe 230400 baud with under 1% timing errors. Near zero timing error at lower baud rates. Without an external crystal oscillator, it's not going to run any faster at standard baud rates without huge timing errors. I'll look around for another member of the PIC24 family with a 7.37 MHz RC oscillator built in which will improve the situation and allow operating at higher baud rates -- not that the 6502 could keep up anyway.

I'm handling register accesses with an interrupt handler for minimum latency. I started by putting everything in a polled event loop but the interrupt handler is faster since it will prioritize register accesses over checking the status of the serial port. I was left with one extra I/O port which I think I'll use to detect when the 6502 has overflowed a register by writing to it faster than the PIC is able to read it. There will be a couple more extra I/O lines when debugging is done as well. But it has provisions for DCD, RTS, CTS, TXD, and RXD right now.

Why not? I've run well over 100,000 interrupts per second at 5MHz, equivalent to over 1Mbps. Without writing or looking through code, I think the job to do for each byte might be small enough to keep up. But you're talking about the 6502 going faster, up to five times that fast if it's on 5V; so yes, I'm sure you can do 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 65C02 can easily handle an interrupt rate well into the tens of thousands per second, even with an ISR that pushes all registers in the preamble and a "relatively slow" Ø2 rate. So you shouldn't sell it short.

I've fooled around with CBAT loopback testing on POC V1.1, running both serial ports at 230.4 Kbps, which amounted to over 46,000 IRQs per second. It was clear that the 65C816 wasn't even working up a sweat while that load was on it. Even when I tossed in some code that would do reads of one of the disks—SCSI I/O is also interrupt-driven—I couldn't see any evidence of MPU saturation.

The 6502 family has very short interrupt latency, and even if it is necessary to fully preserve the MPU state during interrupt processing, (as my POC unit does—it's a general purpose computer, so no assumptions can be made about register usage), will process IRQs with considerable alacrity.

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

Also, the 6502 doesn't require an interrupt for each character. You could implement a FIFO in the PIC, and transfer 8 or 16 chars in a single interrupt.

I attempted to find another PIC with the PMP peripheral and a built-in 7.37 MHz oscillator instead of the 8 MHz the PIC24FJ32 comes with. If such a part existed, it should simplify operation at higher baud rates. The PIC has a baud-rate generator built in. It can run either 4x or 16x the actual baud rate, and operates by dividing down the master oscillator with a counter. If you do the math, you find that in order to hit the higher baud rates without a large timing error, you need to run the system at a clock frequency which is an integer multiple of your fastest baud rates. Unfortunately, no such part seems to exist based on searches I did using the PIC selector tool: http://www.microchip.com/maps/Microcontroller.aspx.

I'm currently running the PIC24FJ32 at an internal clock frequency of 8 MHz which is then multiplied by four by the on-board PLL for a final clock frequency of 32 MHz. Incidentally, most instructions execute in 2 clock cycles so that gives us 16 MIPS (16-bit) to work with (interrupt latency is fixed at 4 instruction cycles -- 8 clock cycles). But with a clock frequency of 32 MHz, the baud rate generator works in units of 4/32 MHz (125 nS) which leads to large timing errors at baud rates above about 230400 baud.

One way around this limitation would be to use an external oscillator. In their infinite wisdom, Microchip chose to use one of the two pins to which you would connect an external crystal or resonator as one of the PMP address lines on the 28-pin DIP part I'm using. If you switch to the 44-pin QFN or TQFP this problem goes away, but is replaced by a new one of how to mount it on a breadboard. That may not be an issue for other people building PC boards, but I do want a solution that is breadboard friendly as well. Another option, which exists for both the DIP version and the larger QFN/TQFP versions is to use an external oscillator since the OSCIN pin is not used for anything else on the part. This is the avenue I will go down as soon as I have the basic version working with the built-in RC oscillator.

The 6850 UART assumes that the user provides a reference clock which is either 1x, 16x, or 64x the baud rate being used. This severely limits the users choice of baud rates unless he wants to build some additional hardware to divide the reference clock to the many different values potentially required by the user. I have been thinking about how to work around this and maintain software compatibility with the chip and have come up with the following idea. The 6850 only requires a single address line to access its functionality but I have two available. I can add up to two additional registers to augment its operation. I was thinking of either providing a table of baud rates from which the user could select, or alternatively allowing the user to specify the 16-bit clock divisor directly into these two registers which will allow him to select any baud rate he wishes, standard or not. Since the possibility of allowing an external clock is now on the table, I think the latter choice will be the better one.

So, in summary, with an external 7.37 MHz oscillator (other values could be used but may impact the performance of the PIC adversely), it should be no problem reaching the maximum supported baud rate of approximately 1 Mbps with the PIC (perhaps it will even go as high as Fosc/4, though the specs say 1 Mbps).

I intend to get the PIC working in 6850 mode initially (with the augmentation discussed above), and then tackle the 6551 emulation. I foresee some problems with the 6551 because the PIC is incapable of supporting some of the modes the 6551 supports -- such as 5-bit and 6-bit modes, and 1.5-bit stop bit modes. However, these modes are rarely used so I don't think the average user will be affected. In addition, I need to figure out how to augment the 6551 with provision for selecting the baud rate (beyond the rates available by default) so that will take some more thought as well. I suspect I can steal another bit for the baud rate table that would otherwise have been used to select a word length of 5 or 6-bits but figured it was worth hearing from others before I commit to anything.

Speaking of FIFOs, the PIC has built in 4-byte input and output FIFOs which are fixed and used transparently by the hardware. Additional buffering could be added, but we need to make sure it is worthwhile. Given that each bus transaction to the PIC-UART will generate an interrupt on the PIC, there is going to be a limit on the maximum number of these bus transactions per second. If the interrupt routine is carefully optimized, I imagine that it may be possible to approach 1 MTPS, though certainly that number will decrease somewhat if additional buffering is added. Anyway, this is one of those bridges we can cross when we get there. The source code will be open-source so anyone can enhance or customize it as they see fit.

Spec sheet for the PIC24FJ part I'm using: http://ww1.microchip.com/downloads/en/D ... 39881e.pdf

With the AVR MCUs you can calibrate the internal 8MHz oscillator and 7.37 MHz is within the possible calibration. Do the PIC not have such a feature as well? To use TQFP-44 on a breadboard I used the following adapter

The result is a DIP-48 with standard width (0.6"). I use the PCB from dipmicro.com and as pins I use machined round pins (not the square ones)

Yes, you are referring to what is usually referred to as the OSCTUN register. It is designed to allow the user to calibrate the RC oscillator. The specs say it may be used to adjust the frequency as far as +/-12%, though I have never tried to take it that far. I worry, however, that the adjustment will be too coarse. Nonetheless, I will give it a try and see what happens.


I'll only resort to soldering as a last resort. In this case, I believe the DIP-28 is perfectly serviceable. Others, however, are free to use a larger PIC and take advantage of the additional pins they offer. Might be nice to combine a RAM loader, UART, SPI, and I2C interface all in one. I wonder how many pins that would take?