56k address decoding logic

[technifix]

Hello all!

I've been lurking around the forum here for more than a year now. I've built a couple of 6502 SBCs now and this forum as well as Mr. Wilson's primer have been indispensable!

I've run into an issue that I can't seem to solve this time, and I can't seem to find anything specific enough to help me, so I figured I'd make an account and ask!

My first SBC was a Ben Eater design, with a similar memory map. My second had the lower 32k as RAM, upper 8k as ROM and the rest as IO through a 74138. Both work well, I made a PCB for the first (my first PCB design and it worked first try for some reason) and my second is still on breadboards because I have a different bit of design in mind.

I have a bunch of 64k RAM chips here, UM61512-15 15ns chips. I've tested them with the ROM writer Ben uses and according to it they all work. I realize that 32k of RAM on one of these is more than plenty for mostly anything, but I figure if I have these why not use them? I came up with the logic below. The 61512 has a CS input that I've connected to PHI2 (which is not on the diagram), which I believe should work to qualify the /CS input.

I've breadboarded the new design. The RAM doesn't work (or it doesn't seem to). I can flash LEDs on my 6522 so I know that the IO logic and ROM logic work but when I JSR it just crashes, I'm assuming it makes the jump but doesn't return to the correct place. I don't really have a great way to debug unfortunately. I did leave a method of PHI2 qualifying in there - I could connect PHI2 where the VCC is connected to the AND gate, but it didn't seem to work.

CSRAM connects to /OE and /CS on the RAM, in case that helps.

Just to be plain - My intended memory map is the 8k of ROM, a page of IO space at $DF00 (although I'll be putting in dip switches so I can configure that) and the remaining 56k as RAM.

I must be missing something... and I should probably get the aspirin for the facepalm I'll do when someone points out my failing.

Thanks from Canada!
Steve

[BigEd]

Welcome! That's a nice progression of projects. In principle your idea should work: the 8k ROM and the 256 bytes of IO disable the RAM, which therefore fills the remainder of the address space.

So, the problem must lie in the details. Either your design isn't quite right, or your implementation isn't quite right.

It will be helpful for you to show how you have hooked up the CPU and the RAM, I think, because at this point it's all about the details. I'm pretty sure you must qualify RAM accesses with the clock, and there are various posts and threads about that already. Garth's primer is probably the fastest way to find guidance.

[John West]

It looks OK to me as well. Connecting the clock to CE2 should be valid - writes happen while /CE1 = /WE 0 and CE2 = 1, and stop as soon as any of those signals goes to the other state. As long as the address is stable throughout (which it is) and data doesn't change too soon before CE2 falls (it doesn't), it should be OK.
For debugging without an oscilloscope, you could attach (buffered) LEDs to the control signals on the RAM and slow the clock right down. That will at least let you know that the logic is doing what you think it is.
And since you can execute code from ROM, and have data displayed on LEDs on the 6522, I'd simplify the RAM test. There's a lot that can go wrong between JSR and RTS. Write a sequence of values to at least two different locations in RAM, read them back, and display them. Do you get back the values that you wrote? Are they stable or changing? If it goes wrong, perhaps the value you read will give a clue.
What clock speed are you using? There's more logic on the RAM path, and if you're pushing the clock speed that might cause problems.
RAM can be tricky to debug, because there's no easy way to tell whether the problem is in writing values, reading them back, or both.

[Dr Jefyll]

Steve, when you refer to Phi2, is that the signal you're applying to the CPU input on pin 37, or are you talking about Phi2 from the output on CPU pin 39? I suggest you use the former for the RAM logic. What is your clock source, BTW -- a "can" type oscillator? Also, are you using a plain (NMOS) 6502, or is it a 65C02 (CMOS)?

Absolutely it is necessary that writes to RAM be qualified with Phi2. (That's to prevent spurious writes to unintended addresses during Phi2-low.) It's nice, though less crucial, if RAM reads are also qualified with Phi2. Happily, both are easily accomplished by incorporating Phi2 in the logic that drives CS or /CS.

Applying Phi2 to the input of the AND is the right idea, and is probably OK, but applying Phi2 to CS means Phi2 will take effect somewhat sooner, and that would be my choice (at least until we get things working). And BTW there's no harm if you use both solutions simultaneously.

To help us look for potential issues it would be a good idea to share some photos, and on this forum you're able to attach photos with your posts. A complete schematic would be helpful, too.

-- Jeff

[plasmo]

I second Dr Jefyll's comment about posting pictures of your breadboard and schematic. UM61512-15 is 15nS RAM; it is very fast. High speed is not your friend in a breadboard environment. You need to be very careful with power/ground and keep the connections short.
Bill

[1024MAK]

And plenty of 100nF capacitors connected close as possible to the VCC/+5V and 0V/GND pins of each chip is also essential.

Mark

[technifix]

Thanks for the tips!

I have connected both CS and one input of the AND to PHI2 as recommended. I've also added some more 100nf capacitors. I connected 8 LEDs to port A of my 6522 and have done some testing, and I'm getting some rather odd behaviour.

Code: Select all

main:
 lda #$55
 sta $0000
 ldx $0000
 stx PORTA

 lda #$AA
 sta $0000
 ldy $0000
 sty PORTA

 lda #$FE
 sta PORTA
 jmp main

I just typed that in, I left out my delay loops in between each (so I can see the LED output). Upon power up I get $FF's for the first two (the $FE is just to show me I'm still in the loop), but after about 10 seconds it starts working, and it works for about 5-10 seconds and then I see $00's along with the $FE.

I am currently running a 1MHz oscillator can. I'm using a 74HC04, a 74HC11 and a 74HCT688. (As soon as I can afford it I have 74HC10's and 74HC688's in my mouser cart, $20CAD just to ship to Canada unless you spend $100.) Everything connected to PHI2 comes directly from the can. I am hoping to increase the clock speed later, but right now I think 1MHz should be fine. My previous version uses a AS7C256B 32K chip with 15ns CS access time and 6ns OE access times and it works great. I am running the WDC65C02S chip. I do have an oscilloscope, but it's a Tektronix Type 422 (with a couple of vacuum tubes) so it's obviously not the best tool for the job (though it does let me see continuous signal patterns).

I've included the schematic. It includes a MAX3100 and oscillator which are not on the board currently, the '688 is currently hardwired for $DF, and the 6522 doesn't show port A connected to LEDs (as I just did that). The 6502 and 6522 are using the PLCC footprints as that is what I'll be using for the PCB eventually.

I'm not sure a photo of the project would help. I wanted to test to see if it would work before I went to the trouble to cut a ton of neat (as far as my ability allows anyway) wires. It's difficult to even see the RAM chip. The fact that it works for a few seconds leads me to believe it's a timing issue though.

Hopefully I didn't forget any requested information!
Thanks again,
Steve

As an aside, I also have some 16550 UART chips. I've successfully got my 3100 to work with my previous sbc but if the 16550 is better (and works at clock speeds of 8MHz+) I would definitely like to give it a spin. Is it worth it?

[Michael]

Hi Steve.

Hopefully the RN1 resistor network is pulled up to 5 volts and not grounded as depicted in the schematic?

Happy Holidays. Cheerful regards...

[barrym95838]

Hey Steve. What Michael said. Plus, it's not clear to me at first glance if you have any open-circuit inputs anywhere in your apparatus, but others have encountered frustrating and intermittent meta-stability issues from the same.

[Michael]

May I showcase another decoder + glue logic method for inserting an I/O page almost anywhere into address space with ROM above and RAM below? I like it better than a GAL based solution because it's jumper configurable (no GAL programmer required) while providing several I/O strobes and qualified Read and Write strobes for memory and non-6500 peripheral ICs.

The 74HC682 is available at Mouser & Digikey but I purchased ten of them from a vendor on AliExpress ($1.29 each, including shipping).

[technifix]

Thanks for noticing my mistake with the resistor network. That's a PCB component, the breadboard has some individual 3.3k's tied high. All of the gates not used are also tied high.

I think I'm going to rewire the board (BB830's) and I'll use busboard's jumper wires as well. Hopefully I'll be able to rewire it quickly without being too messy.

That logic diagram is interesting. /OE is PHI2 (although it has PHI1 on the diagram) qualified but the chip selects are not. I have some '139's but I'll have to order a '682. They're 6.83 or something CAD from Mouser, though I've never used AliExpress before. I'll have to have a look.

Steve

[Michael]

PHI1 provides the active low enable to the '139 during the time when PHI2 is high.

The 74HC682 chips are surprisingly expensive ($5.02 USD at Mouser & Digikey) and that's why I bought them on AliExpress.

Happy to hear you're using the BB830 breadboards. They're so much better than the Chinese versions.

Hope you find the problem.

[1024MAK]

Can I just point out that some members here have difficulty reading coloured schematics. It would be appreciated if you can either post black and white diagrams, or provide both.

Also that there is normally no problem with 74HCxxx driving 74HCTxxx. And there is no problem with 74HCTxxx driving 74HCxxx, as both have the same type of output stages.

Mark

[akohlbecker]

Cool idea to use a comparator to decode the I/O prefix, I didn't see that one before. It is too bad that those parts are not available in faster logic, the HC variants are quite slow (42ns for the '688, 69ns for the '682) which makes them harder to use for fast clocks

[Dr Jefyll]

technifix wrote:

I'm not sure a photo of the project would help. I wanted to test to see if it would work before I went to the trouble to cut a ton of neat (as far as my ability allows anyway) wires. It's difficult to even see the RAM chip.

We're not gonna judge your project in terms of a beauty contest -- this is about functionality. We've doled out advice to project builders before, and it's by no means uncommon that a photo will reveal crucial details which the builder overlooked or considered unimportant.

Quote:

Upon power up I get $FF's for the first two (the $FE is just to show me I'm still in the loop), but after about 10 seconds it starts working, and it works for about 5-10 seconds and then I see $00's along with the $FE.

Let me see if I've got this right. Can you confirm...

• after powerup the LEDs show $FF (delay), $FF (delay), $FE (delay) in a repeating a pattern
• after about 10 s, the LEDs show $55 (delay), $AA (delay), $FE (delay) in a repeating a pattern
• after another 5-10 s, the LEDs show $00 (delay), $00 (delay), $FE (delay) in a repeating a pattern

Quote:

The fact that it works for a few seconds leads me to believe it's a timing issue though.

OK, you believe it's a timing issue. But remember to allow for the interpretations of others. Otherwise, why bother to post your problem here!

-- Jeff

ps- I'm in Canada, too, and have always found Digikey's shipping much cheaper ($8, as opposed to $20 from Mouser and others).