Hello there:

Do you know of any reliable supplier of 27C128 EPROMS?
I will settle for pulls (used ones), as long as they are not defective.
I used to buy it from Futurlec (Australia), but having problem getting it now.
There are a few suppliers who say they have it, but don't.
Then there are companies who send you pulls (used) 27C128, but they are defective and cannot be programmed.
One of these companies is Jameco out of California.
Any suggestions will be appreciated.
Thanks!

In the title you put 28, and in the body you put 27. Which one do you want? I suspect it's 27, and I first went to DigiKey's website and they had them in 120, 150, and 200ns, in windowed ceramic DIP. Minimum purchase quantity is 1. If you really can't find any, I have some I could probably let go of.

Hello Garth,
I did indeed mean 27C128, I have corrected it in Subject.
I used to buy these from Digi-Key. Their web site still list these, but only because the web site program has not been updated.
They do not have any in stock and will not take any order.

It is surprising that they have plenty of 27C64 and 27C256.

I will try Debco Electronics, see if they have any stock.
http://safe.dhwd.com/cgi-bin/debco/index.html

Thank you for your offer, when I become really desperate, I would ask you to sell me some.

Of the six that Jameco lists, two of them, cat. nos. 266061 and 149665, are not pulls.

I just checked Digi-Key's website again, and they're not showing any. It gets updated automatically though as inventory changes. I always verify things online before ordering from them on the phone, and I never find any discrepancy.

Depending on what you're doing, you might be able to use the top half of a 32Kx8 instead of 16Kx8. A14 is kept high which is PGM\ on the 16Kx8.

Garth,
how can you tell that these two items are not pulls?
By the bold print?
I have a hard time deciphering their catalog.

I face another snag. I have a ton of Dallas battery-backed NVRAM, either 150ns or 200ns. I will have to get some 100ns. But, Jameco's 266061 (100ns) is out of stock (or so it seems). They do have 149665, but that is 70ns. So, as of now, I don't know if there is 70ns or faster, 2K NVRAM.
Of course, I would have to then throw away all those NVRAMs, the darn things are $12.- a piece.

Your suggestion of using half of 32K EPROM is a good one, looks like the way to go. I could also keep my NVRAMS. I will have to make some changes in circuit, which I have been trying to avoid for practical purposes.

On page 6 of Cat 281 (Feb '08), about 2" down the left column, you see the two 16Kx8's that are new, not used. Their catalog number is in black instead of the orgish-brown, and the number in the next column is not followed by the little character that looks like four arrows pointing out from the center, pointing up, down, left, and right. The "key" up about 2.5" from the bottom says that character means they're "refurbished," and these two don't have that character.

On the NVRAMs, are you thinking 70ns is too fast? It's highly unlikely that they're too fast for your construction or circuit. NVRAMs are always slow and expensive. What you might want to use instead is a 24- or 25-series 8-pin serial EEPROM or flash memory that come in densities from 16 bytes to 4Mx8 for just a few dollars-- much cheaper and bigger than NVRAM, although your software has to transfer the data through two VIA pins (for the 24-series I²C ones) or four VIA pins (for the 25-series SPI ones) instead of being able to just remember everything if the power is suddenly killed.

In the case of the I²C type, you can interface several other I²C devices connected at the same time to the same two VIA pins, whether more memory, D/A and A/D converters, relay drivers, port expanders, etc.. In the case of the SPI type, you need an additional select bit for each device you want to hang on the other three pins (clock, data in, and data out), and you can add UARTs, USB interfaces, and other things that usually require more speed than I²C can deliver. These synchronous serial devices are much, much easier to interface than parallel ones because there are so few connections to make.

Got it,
meaning the Jameco's clever code.

I use NVRAM as a RAM also. If my EPROM is say 120ns and NVRAM is 200ns, it will not work at all. I need to match closely enough my EPROM and NVRAM speed.
The fastest NVRAM I can realisticaly get is 100ns. Most likely, that would not work well enough with 70ns EPROM that Jameco has in stock.
I will have to wait for their "hopefuly new" 100ns 27C128, which they are supposed to have in stock as of July 15, or so they say.

I will certainly use some of the suggestions in a new design.
I have used I²C before, but with Microchip micros.

I can't think of any situation where 120ns EPROM or even 45ns EPROM wouldn't work with 200ns RAM. You must have a very strange setup. The rated access time is a maximum anyway, meaning that most of the devices, under most conditions, will be considerably faster. There's a maximum guaranteed accesst time, but no minimum.


Sure-- but if you want to be able to keep certain data or programs there when the power goes down, you can move them to the serial EEPROM like a tiny hard disc. 20 years ago before there were NVRAMs or off-the-shelf ICs to handling the battery back-up job and make sure the processor couldn't write garbage to the RAM as the power was going down, I made my own circuit. It used kind of a lot of parts (all very cheap ones), but it seemed to be 100% reliable.

I'd be curious to see that, is it online?
Or perhaps you could post it somewhere or maybe just elaborate a little bit?

I'll try to dig it up and scan it and put it online. Somewhere I also have a simpler one from a magazine from many years later. My own circuit is one of those things like my old tape modem that used a lot of penny parts that together came to a buck or two. The tape modem made sense back then because non-volatile storage of any kind was expensive and/or big and/or complex, but everyone had a portable cassette machine of some kind, and we didn't store as much data anyway. Today the tiny 8-pin serial EEPROMs and flash memories hold so much more data than a cassette can, and are cheap and much faster too, so there's no point in storing data on tape anymore. I know there are several ICs on the market to automatically take care of the job of battery-backing and protecting RAM when the computer's power is down or in transition.

I have a straight-forward circuit design pretty much standard 6502 textbook from Synertek days, but more up to date decoding chips.
I use 74HC*** family decoding. The NVRAM has Output Enable grounded, meaning output is enabled all the time.
I have tested various speeds of NVRAMs, results are consistent. If a NVRAM has a max speed 200ns, typical speed is say 180ns. If my EPROM is say 150ns, some functions may work with some NVRAMs, others will not. Or, it will not work at all. But, when I plug in 150ns NVRAM, all works fine.

Until Mostek came up with NVRAMs, I used to have regular SRAM, #6116, backed up with rechargable battery pack. A simple circuit would disable the SRAM when the power went down. It worked like a charm, but was not practical.

For the outputs to be enabled, the OE\ must be low, the CS\ must be low, and the WR\ must be high. The output is only enabled when all three of those conditions are met.

The access time on the EPROM is a guarantee of the maximum time it will take for the output to be valid. The output buffers may be enabled sooner, but the data coming out is not guaranteed to be valid yet. It's ok if the data is valid sooner, even if the processor isn't in any hurry to read it yet.

People who are just starting into 6502 usually make the address decoding much more complex than it needs to be, and can get themselves into trouble with too many levels of gate delays, or at least unwittingly reduce the maximum clock speed their circuit could otherwise work at. My workbench computer uses nothing but a 74ACT00 for address decoding (not even using all four sections) for 32KB EPROM, 16KB RAM, 3 6522 VIAs and 3 6551 ACIAs, IOW 6 I/O ICs, and it could be expanded to 10 I/O ICs without any additional logic. With 4MHz parts, 70ns EPROM, and 55ns RAM, it works at any speed up to 7MHz. Faster memory would not hurt a bit, but at this point, I don't think RAM access time is the limiting factor in how fast it will run.

I should point out, however, the simpler the address decoder, the less dense the memory map. Garth has a lot of "holes" and "mirrors" in his address map, and IIRC, individual address bits connected directly to peripheral buffers or _CS inputs, which opens the possibility for bus contention when accidentally reading from multiple peripherals at once (easily possible when, e.g., attempting to read from a corrupted memory pointer in memory).

Thus, there is an engineering tradeoff -- you can provide a slower, more correct address decoder, or you can use a faster, cheaper, but potentially more dangerous, address decoder. It depends on your target audience and applications.

True, there are multiple addresses (mirrors) that can reach a particular I/O IC, all in the $4000-$7FFF range, but in the 15 years I've used this computer, it has never been a problem. There are no mirrors in the RAM & ROM address ranges. There is only one address capable of reaching any given RAM or ROM byte, and none of those will enable an I/O IC. Something it allows you to do however is to write to multiple VIAs or ACIAs simultaneously if you wanted to set them all up identically. I have never had the occasion to do that, although I thought I might back when I first made it. You don't normally have pointers for I/O anyway though (which is where my memory map is strange), so even corrupted pointers won't normally cause any bus contention.

This is the extreme in address-decoding logic simplicity though. There are various steps between this and having a half-dozen ICs for it. The first computer I made was bigger and used more parts and did very little by comparison. I keep learning to do more with less.

I'm really not sure I believe this.

I've been coding since I was 4 years old (yes, it is true), and ever since I learned machine language for the Z-80 at age 6, I've always had to deal with stray pointers. I continue to deal with stray pointers even today, after almost 30 years! Sure, I've gotten more practice, and can more reliably prevent this kinds of bugs from happening, but they DO still occur.

The ranges that the pointers take on often are application dependent, but at least on the Amiga and on the Commodore 64, I've tweaked I/O settings accidentally more times than I care to remember.

Like death and taxes, stray pointers happen.