Memory Map Logic

[Tor]

Quote:

It's too bad nobody publishes a giant data book like TI did, anymore

TI gave them away for free, three or four years ago. I ordered one - they sent it FedEx (still for free!) to Norway.

[KhanTyranitar]

The Digi-Key site is primarily what I've been using. But yes, I am ignorant on the subject to a large extent. I played around with this kind of stuff back in my teenage years.

When I ran a search for a multi input OR gate on Digi-Key in the 74 AC series, it produced zero results. Now is it possible I ran my search wrong. Absolutely. I know there must be something that will work or is compatible.

Now in my view there is nothing wrong with asking for advise, and considering various views and approaches. I choose the chips partly by ingnorance, and partly by research. I found schematics produced by others who were doing similar things to what I'm trying to do, and so I tried imitating what they had done. And I imagine you would agree that looking at others designs is a good way to learn to a point.

Now if there is a good guide to familiarize myself with the different logic families, what the pros and cons and considerations of each design are, I will gladly read it. If TI or Fairchild or others have a good guide I can read, then yes, I want to learn and take the time to figure it out.

[BigEd]

This might be useful:
http://www.futurlec.com/IC74AC00Series.shtml

(And it might not!)

Cheers
Ed

[BigDumbDinosaur]

KC9UDX wrote:

It's too bad nobody publishes a giant data book like TI did, anymore.

Such a thing is handy but no longer essential. Most of the electronics parts companies have efficient search engines on their websites that if properly used will help you locate what you need. They also include access to data sheets. I regularly use Digi-Key's search functions, although I must confess that I mostly order from Jameco and Mouser, due to our company having open accounts with those two vendors.

[jac_goudsmit]

KhanTyranitar wrote:

When I ran a search for a multi input OR gate on Digi-Key in the 74 AC series, it produced zero results. Now is it possible I ran my search wrong. Absolutely. I know there must be something that will work or is compatible.

Google and Octopart are you friends too. If you type something like "4-input OR gate" or "4-input NOR gate" into Octopart, it will give you an idea of how available they are, how much they cost, whether they're DIP or SMD (though pictures are not always correct) and it will give you a link to the datasheet so you can quickly find timing parameters.

===Jac

[BigDumbDinosaur]

KhanTyranitar wrote:

The Digi-Key site is primarily what I've been using. But yes, I am ignorant on the subject to a large extent. I played around with this kind of stuff back in my teenage years.

When I ran a search for a multi input OR gate on Digi-Key in the 74 AC series, it produced zero results. Now is it possible I ran my search wrong. Absolutely. I know there must be something that will work or is compatible.

The use of discrete logic is steadily decreasing, predictably reducing or eliminating sources. Also, DIP packages in general have taken a back seat to SMD equivalents, which offer economies both in manufacturing and in PCB real estate consumption. Furthermore, certain logic families are not well-represented anymore due to declining demand, inadequate performance or other factors. While I didn't do an exhaustive search, I was unable to find any OR gates with more than two inputs in DIP packages. However, I had no trouble finding four-input ORs in SMT packages.

Quote:

Now in my view there is nothing wrong with asking for advise, and considering various views and approaches. I choose the chips partly by ingnorance, and partly by research. I found schematics produced by others who were doing similar things to what I'm trying to do, and so I tried imitating what they had done. And I imagine you would agree that looking at others designs is a good way to learn to a point.

There certainly is nothing wrong with asking for advice. However, don't be completely taken aback if you get an RTFM type response to a question that can be readily resolved with on-line research. A basic assumption on my part, and most likely on the part of others around here, is that you have exhausted readily available resources before posing a question. There is a mountain of useful information scattered all over the Internet on basic logic and the types of devices that implement it. As Jac said, hitting sites such as Octopart can be a big help in tracking down parts. While I don't consider Wikipedia to be 100 percent trustworthy, you can learn quite a bit about computer hardware by perusing articles and following links at that site. They have several pages that describe the major logic families and their pros and cons.

Quote:

Now if there is a good guide to familiarize myself with the different logic families, what the pros and cons and considerations of each design are, I will gladly read it. If TI or Fairchild or others have a good guide I can read, then yes, I want to learn and take the time to figure it out.

Almost any good search engine will get you where you need to go.

[GARTHWILSON]

KC9UDX wrote:

It's too bad nobody publishes a giant data book like TI did, anymore.

I have three shelf-feet of National Semi data books which I'm very glad I kept, especially after TI took over NSC and replaced NSC's more-helpful info with TI's own.

[Drass]

KhanTyranitar wrote:

I'm trying to figure out how to get rid of the FCT521s. What multi-input OR gates do you recommend? Or is it just as fast to just use regular or gates in a cascade?

Curious to know what you ended up doing on this. I ran into very much the same issue in my own TTL project and opted for using SMD LVC parts as suggested above: 3-Input NORs into a 3-input AND lets you handle 9 inputs in about 6ns. If an HC logic comparator is too slow, I'm not sure there are many alternatives in DIP packages. IIRC the FCT521 has TTL-level inputs so you may need to account for that. If you do decide on SMD, you may want to check out Fairchild "Tiny Logic" chips as well - the single gate NC7SZ series. They are a good alternative to LVC1G ICs and all work with 5V supplies (which is not always the case for LVC).

[KhanTyranitar]

I have not had much spare time this week. I'll probably just use a bunch of gates in dip style. Again the final build will probably use something different. I'll post a schematic when it's done.

[jac_goudsmit]

Of course you could use 74*138 for the upper address lines too (you might need them anyway to decode addresses for RAM chips). Keep an eye on the propagation delay though.

=== Jac

[KhanTyranitar]

I think I should have a working setup on the upper lines. Its probably not fast enough for anything more than a couple MHz because I'm limiting it to through hole type chips. I just used a bunch of NOR gates on the lines, then AND gates off those. But it should work.

Yes, I might need to redo it for the upper address range using 138s. It depends on what RAM I plan on using for anything beyond the initial 64K. If I use the WilsonMines RAM then I can set it up for the way He has it. Frankly his stuff is not a bad value at all, so thats what I'll probably use. The Cypress chips he uses in his modules is what I was looking at myself.

For now I've decided to use all 74AC series.

One thing I'm thinking of doing is by default disabling the BASIC ROM (A C64 enables it by default) and using a custom Kernal. The Custom Kernal will run startup routines, and load programs from disk into memory space. It will load a file which will tell it to load other files into RAM, or to switch to ROM routines. If it can't find the needed files one device8, then it will bank in a BASIC ROM. My BASIC rooms will be patches such that it disables cassette routines, as I don't plan on putting cassette support and I plan on using the PIO lines for other tasks. I know that breaks some C64 software, but really, not much that I would run uses that stuff, and it allows me to eliminate the cassette routines, which could be used for patching BASIC among other things.

Imagine powering the thing up to BASIC and instead of displaying 64K RAM SYSTEM 38911 BYTES FREE if it instead displayed how much of the 16MB RAM was free. Yes, I plan to patch my BASIC to locate BASIC programs into the extended RAM space. My KERNAL will maintain some essential KERNAL features so that software that makes KERNAL calls will still work. What I plan on doing is actually a bit different. I plan on having the KERNAL ROM boot a more C64 like KERNAL from the disk. Again, my system will be able to write to RAM under ROM, so having it read files to ROM space off a disk won't be a problem. Then if it banks the ROMs off, it does not have to slow down for access to KERNAL or BASIC routines.

A real trick will be getting external cartridges to work properly. It can be done in the glue LOGIC, I just have to take it into account.

[KC9UDX]

Unless the software is doing something with the cassette you don't (and most everyone else didn't) have, it's not going to use the cassette I/O anyway. So you'll only break software you can't use.

For what it's worth, the SX-64 didn't have cassette capability either, and I'm not aware of any software that doesn't run due to that.

[BigDumbDinosaur]

KC9UDX wrote:

Unless the software is doing something with the cassette you don't (and most everyone else didn't) have, it's not going to use the cassette I/O anyway. So you'll only break software you can't use.

For what it's worth, the SX-64 didn't have cassette capability either, and I'm not aware of any software that doesn't run due to that.

Historical note: a C-64 or C-128 equipped with a Xetec Lt. Kernal hard drive subsystem doesn't have tape functionality. I never heard of anyone running into problems with it.

[KhanTyranitar]

Cassette drives were popular in the U.K., but even then I doubt much software actually used anything specific to the drive. I used to have a Datasette, but I never recall using it, my software was all on disk.

My concern would be software modifying those bits for some reason, perhaps by not following the proper conventions for changing the bits. This is probably not a common issue. If I use those bits for things like alternate ROMs and they get changed when they aren't supposed to, then strange stuff will happen.