Hi guys

As you've probably noticed I've been developing OS routines for my homebrew 6502 .
I've now run into an interesting issue, in that if I write to anything above $3FFF I end up with rubbish.

Memory map:
0000-7FFF ... RAM (HY62256BLLP-70)
6000-6015 ... I/O (WDC 65C22S -mapped over the top of RAM at these addresses)
8000-FFFF ... ROM (Winbond W27C512-45Z -only upper 32KB mapped)

If I access ROM all is fine.
If I access I/O all is fine.
If I access RAM between 0000-2FFF all is fine
If I access RAM above 3000 then the data bus corrupts above the first two bits

I've done the following:
- tested for shorts across the data and address buses
- swapped the RAM IC for another of the same make/model
- Tested the data bus voltages - 0v for low, 5v for high without jitter
- Checked the /RAM select and /ROM selects never conflict. /VIA and/RAM do conflict, but never select at the sametime as the RAM /OE never enables if the VIA is being accessed.

- Ran some test code to store a number at 4000 then read it back - see attached for results (read using a bus monitor and using a single cycle stepping circuit).

Ignore the pre-amble in green - there are three LDA#01's, LDA#&52 then STA &4000 (in yellow). It then LDA#0 to clear A, then attempts to reload the contents of 4000 (in purple)...but seem to get 0 in the databus as a result.

It's late so I'll do more tests tomorrow, but in the meantime has anyone got any suggestions? Or is there a known issue with the RAM IC type that I've chosen?

OE\ of the RAM is on A14, which is high for $4000. $4000-7FFF is I/O space with this simple address-decoding scheme. It's what I have on my workbench computer. There's 32KB ROM, 16KB usable RAM, and the 16KB I/O space can have nearly a dozed I/O ICs.

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

Ahhh I see. I used your system in favour of my original as it was recommended, but obviously I didn't realise the full implications.
I might need to see if I can find a way of getting more RAM to be accessible. The good news is that your system is working for me as desired .

Thanks for the explanation.

Could the following circuit be used as a single chip solution for the 32K RAM, 16K I/O, 16K ROM example in the Primer?

RAM 0000-7FFF, I/O 8000-BFFF, and ROM C000-FFFF.

The U4A Y2 and Y3 outputs are used for the active low I/O and ROM chip selects, respectively. Use A15 for RAM /CS and /OE pins and connect the Φ2 qualified /WE signal from the decoder to the RAM /WE pin.

Hi Michael

Thanks for the suggestion. My original design had something very similar - a 74HC138 decoder. however, apparently these are a bit slow? As a possible alternative I was thinking of looking at using a GAL, although this may not be doable due to a lack of programmer and not knowing how to program them. Not insurmountable, though.

I have GAL's (ATF16V8,22V10), a programmer and experience with WinCUPL if you need help.

I've also got Atmel ATF1504 programming/development board and PLCC adapters somewhere - BNIB.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I'm not sure you'd have a problem using a '138 on a 2-MHz system, however, if you did, using a faster 74ACT138 might fix the problem.

I hesitate to use GALs for similar reasons. The dwindling supply of high speed parts, the power requirements, the cost, and the lack of a simple DIY programmer design are some of the factors that keep me from using them.

The CLC (Configurable Logic Cell) module in some recent Microchip PIC devices looks interesting. For example, you might use the CLCs in a 14-pin PIC16F1704 for a relatively simple single-chip decoder solution;


If the CLCs are all you're using on the PIC, the PIC program can put the microcontroller portion of the PIC to 'sleep' to conserve power, after initializing the CLC module.

If you were to drive the second (active high) chip select input on some 64KB or larger SRAM chips with the Φ2 clock signal you could avoid circuitry for qualifying the RAM /CS or /WE signals. This frees one of the limited CLC input pins for an additional address pin;


Good luck with your project.

Cheerful regards, Mike