6502 PCB Power On Issues

[djh82uk]

BigDumbDinosaur wrote:

Why are you using that 68B50? That UART doesn't have a baud rate generator and is not CMOS-compatible. See if you can track down a non-WDC 65C51.

Ah ok, so I get the CMOS part, looks like Grants design just calls out the 6502 as opposed to 65c02, so guessing he's potentially on the older NMOS stuff?

On the baud generator, what's the benefit there? Being able to change baud without changing the clock circuitry? or is it a bit more stable?

Looking around, I found some Harris CDP65C51AE2's available, datasheet is dated around 1993 but not for that AE2 variant. Or I'm guessing the goto would be the rockwell? I've struggled to find the rockwell datasheet. (update, just found it for the P4 variant https://www.datasheets360.com/pdf/-6472429571977783289)

Guess I should look for some example schematics to see how to interface to it. Im guessing there should not be an issue using a USB-TTL adapter? or the keyboard/video board (not at the same time as the USB). I wanted to get those working before looking into my own VGA board and serial board. I find it easier to build out someone else's design before trying my own thing, but not if it won't work due to CMOS/TTL obviously).

[djh82uk]

Martin A wrote:

djh82uk wrote:

What would you consider low speed for the 74HC138?

That's relative, and depends on the CPU etc. A little digging in data sheets and some maths is required.

The modern W65C22 needs the chip selects stable 10ns before the clock rises, so chip selection has to be completed in 10ns less than the low half of the clock cycle.

The data sheet for the Nexperia HCT138 says worst case propagation delay at room temperature is 40ns. Other manufacture's parts may not be exactly the same, but will be similar.

If you've also got the WDC 65C02 then that has a worst case of 30ns from the clock going low to address being stable when running at 5v.

Add the three valuess together and that's 80ns minimum for the clock to be low for the chip select to meet all of the specified maximums. That is then 160ns for a complete clock cycle, which works out at 6mhz give or take a few fractions well short of what the CPU is capable of.

The older 65xx parts will have longer setup times and a lower maximum clock.

That's not to say you can't run faster than that it's just not guaranteed.

NB if you do have all WDC parts then the HC138 is also suitable and a little faster. The "T" part is designed to cope with TTL inputs ie NMOS 6502.

Thanks for explaining how you came to that conclusion, really helps it sink in as to how I should be thinking about these things and finding the info.

Im under 2Mhz so looks like I would have room there.

[BigEd]

Bear in mind there are quite a few people here interested in NMOS designs, older chips, lower clock speeds. And then there are some who are interested in CMOS designs, newer chips, higher clock speeds. Ideally, we all realise that there are two camps, but sometimes that subtlety can be missed.

Which is to say, if you don't read carefully and consider who is posting, you might get pushed into a different direction than you were interested in.

[djh82uk]

Yeah I hadn't thought of that, I guess either is just as valid as the other, and it's just mixing them that's considered bad.

I am trying to move to solely CMOS, I just finished (picture) this and it's all 74LS chips, damn thing draws 1.3A at full speed. (though it also has lots of led's).

[Dr Jefyll]

djh82uk wrote:

it's just mixing them that's considered bad.

Mixing them isn't necessarily bad. But if you avoid mixing them then you avoid the need to educate yourself about what to watch out for.

Some may consider this an advantage; others not. It depends how you choose to invest your time. And the rules and remedies aren't that complicated.

-- Jeff

[GARTHWILSON]

djh82uk wrote:

On the baud generator, what's the benefit there? Being able to change baud without changing the clock circuitry?

Right. A UART (or ACIA) with an onboard BRG should let you change the baud rate, in software, on the fly. The 65(c)51 gives you the options of all 15 standard baud rates from 50 (for communicating on a very weak radio signal) up to 19,200, plus the option of an external 16x clock source for up to at least 125kbps (and probably a lot more, but it's just that it's not guaranteed beyond that). I've used the latter for MIDI which requires 31.25kbps. The '51 has its own onboard oscillator, letting you hang a crystal directly on it so you don't need an external oscillator and your system clock speed can be entirely separate, like if you want 1MHz, 2MHz, 5MHz, etc., or even change the speed on the fly to save battery power without messing with the baud rate, as I did for a design in the late 1980's. When the requirement for computing power was minimal (which was most of the time), I ran the system at 170kHz, and bumped it up to 1MHz when we had to do a string of floating-point calculations, and back down when done in a fraction of a second. The entire computer, including the LCD, took only 2mA, so battery life was excellent. The '51 also has additional signals beyond RTS and CTS, having DSR, DTR, and DCD. There are of course lots of other UARTs on the market that can do this stuff plus have deep FIFOs. Nearly any of them will open up more options and freedoms for you than the 68(B)50, and I think you will be happier with them in the long run. One I have exercised (but not really put into service) is the MAX3100 in a 14-pin DIP, interfaced by SPI through a VIA. Just about any option will give you more freedom than the

Quote:

Looking around, I found some Harris CDP65C51AE2's available, datasheet is dated around 1993 but not for that AE2 variant. Or I'm guessing the goto would be the Rockwell? I've struggled to find the Rockwell datasheet. (update, just found it for the P4 variant https://www.datasheets360.com/pdf/-6472429571977783289)

This site has loads of data sheets, at http://6502.org/documents/datasheets/ . I'm surprised the Rockwell 65C51 isn't there. I'll have to try to get that to Mike to post. The GTE one is at http://6502.org/documents/datasheets/cm ... ar2000.pdf .

[djh82uk]

Ok, so if Im to look at the R65C51, does anyone have any reference implementations? I was looking at your site Garth, but it looked like the drawings were for a midi implementation?

I mean I guess im just using CS0, CS1B, RS0 & RS1 for the address decode.

PHI2 is the system clock?

ResB to the same reset circuit as the 65C02?

IRQB, I Guess this is where I will have to use an AND as I also have the S variant of the 6522?

RxC, can this be used by just using the system clock? If so are XTAL1 and XTAL2 left floating, or pulled high/low?

TxD and RxD Im guessing I need to flip around, so RxD on the R65C51 is connected to TxD of the USB-Uart adapter?

Now the bit where im really stuck, what the minimum I need for the serial (In addition to GND, TX & RX)? As it CTS or DTR?

And what do I need to do with the remaining pins (Float/Pull H/L)

These are the USB-Uart adapters I have: https://www.aliexpress.com/item/1005002 ... EPiW3&mp=1

[BigEd]

This reminds me of another very useful skill: being able to read a datasheet. They are usually well-organised and straightforward: the whole idea is to allow a design engineer to choose to use a part with confidence.

So, if datasheets exist, you shouldn't need to ask a slew of questions, if the answers you get will have come (indirectly) from the datasheet in the first place.

Much better, for you and for your fellow forum members, if you can try to read the datasheet, answer your own questions, and then come to the forum when you need clarification.

[djh82uk]

BigEd wrote:

This reminds me of another very useful skill: being able to read a datasheet. They are usually well-organised and straightforward: the whole idea is to allow a design engineer to choose to use a part with confidence.

So, if datasheets exist, you shouldn't need to ask a slew of questions, if the answers you get will have come (indirectly) from the datasheet in the first place.

Much better, for you and for your fellow forum members, if you can try to read the datasheet, answer your own questions, and then come to the forum when you need clarification.

I get your point, those were my post datasheet clarification questions. But admittedly I could do a deeper dive, so will do that.

Thanks

[BigEd]

Fair enough!

[GARTHWILSON]

djh82uk wrote:

Ok, so if Im to look at the R65C51, does anyone have any reference implementations? I was looking at your site Garth, but it looked like the drawings were for a midi implementation?

Hmmm... I see I could probably be more clear than what's there. In the QRG pages of the workbench computer at http://wilsonminesco.com/BenchCPU/B1QRG/, the 4th, 5th, and 6th little pages' scans there show the address decoding, the MC145406 (same thing as the SN75C1406) RS-232 line driver and receiver connections, DB-9 connections, and crystal connections; then the 7th, 8th, and 9th scans show the connections I have for AICA2 and ACIA3. ACIA2 is mainly for MIDI and a wireless transmitter and receiver, and ACIA3 was primarily for a tape modem. I've hardly used ACIA2 and ACIA3, and the chance that I'll ever put data on tape again is just about zero; but there could still be other uses for these.

Quote:

I mean I guess I'm just using CS0, CS1B, RS0, & RS1 for the address decode.

Right. And RS0 and RS1 will go to address lines. And be sure you don't qualify any of these with Φ2. They need to be valid and stable before Φ2 rises.

Quote:

PHI2 is the system clock?

Yes.

Quote:

ResB to the same reset circuit as the 65C02?

Yes.

Quote:

IRQB, I Guess this is where I will have to use an AND as I also have the S variant of the 6522?

Use the 3rd diagram in my 6502 interrupts primer at http://wilsonminesco.com/6502interrupts/ .

Quote:

RxC, can this be used by just using the system clock? If so are XTAL1 and XTAL2 left floating, or pulled high/low?

• If you want the system to run at 1.8432MHz, you can run Φ2 into the XTAL1 input. Leave XTAL2 output and RxC unconnected if you're using the onboard BRG. RxC becomes an output in this case, so it's not like you're leaving an input floating. ("RxC" stand for "receive clock;" but you can use it for transmit too. It's just that you can't use it in transmit without also using it in receive.)
• If the system runs at a different speed, you'll want to run the output of a 1.8432MHz oscillator into the XTAL1 input, or connect a crystal (not a crystal oscillator, but just the crystal) from XTAL1 to XTAL2 as shown in the 6th little scan at http://wilsonminesco.com/BenchCPU/B1QRG/, including with the capacitor as shown.

Quote:

TxD and RxD I'm guessing I need to flip around, so RxD on the R65C51 is connected to TxD of the USB-UART adapter?

Yes.

Quote:

Now the bit where I'm really stuck, what the minimum I need for the serial (In addition to GND, TX & RX)? As it CTS or DTR?

Hardware handshake is probably more common than software (XON and XOFF), so the main ones you'll need are CTS and RTS. These are discussed about 35-40% of the way down the page in my 6502-oriented RS-232 primer at http://wilsonminesco.com/RS-232/RS-232primer.html, where you see in bold, "Handshake lines:" After the table, and after the bug report, the 2nd paragraph starts with "Here's the idea. RTS was originally for" which describes RTS and CTS. (My apologies— this particular article doesn't have many pictures to make it interesting.)

Quote:

And what do I need to do with the remaining pins (Float/Pull H/L)

Outputs can be left unconnected, but unused inputs should be pulled one way or the other. Note that the transmitter is disabled if CTS is false, and that the receiver is disabled if DCD is false. If you don't use DCD or DSR or CTS, you'll want to pull them true (low), individually, whichever one(s) you don't use.

There's some sample code in section 3.1 of my 6502 interrupts primer, at http://wilsonminesco.com/6502interrupts/index.html#3.1 .

[djh82uk]

Thanks Garth,

Im still working through it, but here is what I have so far. Still not sure on the address space, I need to get better at it, but where I got to was, A13 & A15 are always one within that range (A000-BFFF) and A14 is always 0

So ive fed A14 into CS1B and AND'ed A13 & A15 together, and output that into CS0

And then ive fed A0 and A1 into RS0 and RS1.

The new stuff (ACIA and 74HC08) are on the right. Im using the 08 to and the A13/A15 together, but also for the IRQ, I figured I only needed a 2-input nand as I only have the R65C51 on the open drain portion (tied high) and the S variant of the 65C22 on the other input. Same as your diagram, minus one input and one VIA.

Thanks

[BigDumbDinosaur]

djh82uk wrote:

Thanks Garth,

Im still working through it, but here is what I have so far. Still not sure on the address space, I need to get better at it, but where I got to was, A13 & A15 are always one within that range (A000-BFFF) and A14 is always 0

So ive fed A14 into CS1B and AND'ed A13 & A15 together, and output that into CS0

And then ive fed A0 and A1 into RS0 and RS1.

The new stuff (ACIA and 74HC08) are on the right. Im using the 08 to and the A13/A15 together, but also for the IRQ, I figured I only needed a 2-input nand as I only have the R65C51 on the open drain portion (tied high) and the S variant of the 65C22 on the other input. Same as your diagram, minus one input and one VIA.

Thanks

In your schematic, you have BE, NMIB, SOB and SYNC all connected to a common 3.3K resistor. SYNC is an output, not an input, and if not in use, should be left floating. SYNC is driven high when the 65C02 fetches an opcode. Otherwise, it is driven low. As you have it, each time the 65C02 fetches an opcode, the other inputs will be driven high. When the 65C02 fetches an operand, SYNC will go low, driving the other inputs low. In particular, pulling RDY low will halt the 65C02 and all processing will cease. Adding insult to injury, an NMI will occur, which your firmware might not be ready to handle.

BE, RDY and SOB should be on separate resistors. In particular, RDY in the WDC 65C02 is a bi-directional signal—it will be driven low if a WAI instruction is executed. You might well protest, "But, I don't ever plan to use WAI." That may be, but a software error could accidentally cause the MPU to read a $CB from RAM or I/O and misinterpret it as an instruction. WAI going low when tied to the other inputs will cause some really strange things to happen.

In general, the PHI2Out output of the 65C02 should not be used and everything that needs the Ø2 clock should get it from the clock generator. PHI2Out and PHI1Out lag Ø2 by an unspecified amount and are there to give the 65C02 some backward compatibility with the NMOS 6502. WDC advises against using those outputs in new designs.

In future revisions of you schematic, I recommend you draw the individual gates instead of using "black boxes" to symbolize glue logic, such as like this:

Doing so makes it much easier to figure out how things work.

[djh82uk]

Great feedback as always, I think I got tripped up again by Grants design being NMOS based (again). SYNC, I have no answer for, I knew the answer and still wired it up wrong.

So am no longer using Phi1/2 Out. SYNC is now floating and individual resistors for the 3.3K pullups. Think I may try an smd resistor array to save some space.

On the schematic, I'll see if I can start using the glue/7400 series in that way, may need to create some new libraries as Easy EDA seems quite opinionated on doing it the chip way (I guess it's more fabrication focused, but I do like the tool).

Personally I like that way, but when I go back to FPGA stuff I end up having to do it on a gate level anyway. So makes sense to align if it also helps people read it.