Been Enjoying the list now for a few months and have always wanted to basically roll my own ever since I seen PE come out with the ELF project of yesteryear. So I have been looking at schematics and decided I might toy with the idea of making my own C64 ish flavor of computer.
Okay so before you laugh, Its really an attempt to understand basic computer arch as well as machine code which would come next.
Now I know the original used a Programmable logic array (U8), but I want to try to keep away from that for the time being. So may I present to you something that I threw together tonight in an attempt to come to grips with how to pull a CE line from the address bus, now Im sure there is other chips I could have selected and wired them up differently and all comments are welcome. Is this on the right track? or is this not how it would be done with discrete devices?


Simple Schematic

I wonder why you aren't using the 74138 and/or 74139 for creating the various signals, like the C64 does? Less parts needed IMHO.

_________________

I can only take a minute now, but I will add a couple of quick comments. 4000-series logic is extreeeeeeemely slow. The 4068 could take as much as 300ns to propagate a signal through at 5V. Also keep in mind that if you are only using bank 0 with an '816 (ie, no addresses above $FFFF), you can totally ignore the bank byte, and not latch, decode, or use it at all. Gotta run.

Actually, the PET and VIC-20 use these. The C64 and C128 both depend on PALs (the C64 uses the 82S100, IIRC; not sure what the C128 uses).

This is a really rough diagram. My like of thought was to have all the system and IO in everything below 65535 and put static ram in everything above there to the 16Meg max on the 816 hence the 74LS(HC)573 the 4068 just seemed handy to provide a high logic pin to the NAND gates. In retrospect the 300ns is too long because I really want to run this thing at close the 14Mhz, IE some 20ns good up to 50Mhz. which is also the reason I dont want to use an eprom or the PAL that came with the C-64, Yet I would like to keep it somewhat compatible with the old 64. Im still undecided if I want to use the VIC II IC or The Yamaha v9938 IC, maybe both. I have toyed with the idea of making the whole cpu board on a ISA board and then be able to swap in some old PC hardware. I know this has been talked about before and done by some but I am not sure how to do that yet as I have not got a full grasp on how IRQ's work yet. Like I say, I am quite new to computer design.
Learn as I go.

I thought about some 74ls138's I will have to look at the VIC 20 diagram and see what they did in that, I suppose I could use a bunch of 74 series NAND/AND gates to accomplish the same thing as the 4068 too..

A couple of thoughts:

1) As suggested by Ruud, decoding with a 74*138 would make for a lower parts count and a less difficult to debug design. Your address decoding is going to suffer significant prop delays with all those gates. Be that as it may, I'm sure it'll run at least as fast as the real C-64.

2) Your design doesn't account for the VDA and VPA signals emitted by the W65C816S. The '816 generates spurious bus accesses during the intermediate stages of executing some instructions. VDA and VPA have been provided to identify and avoid such conditions. Failing to account for those two signals may lead to obdurate bus issues.

3) The '816 is a CMOS device and should used with CMOS glue logic where possible. With the exception of the 4000 series logic (which, as Garth noted, is dog-slow and should not be used), everything can be implemented in 74ABT or 74AC logic, which are substantially faster than 74LS logic.


4) You'll be struggling to get up to 14 MHz with this setup. I see 8 MHz as a stretch, given the circuit you have right now. At 14 MHz, machine cycle time is 70ns. Address setup has to be completed by the rise of Ø2, which means you'd only have about 25ns max for address setup. My opinion is it isn't going to happen with all that discrete logic. Also, you may be faced with wait-stating I/O accesses, depending on what you use for I/O hardware.


The C-128 used both an MMU and PAL, the former being the device that worked out the mix of RAM, ROM and I/O. The details are no longer in my head, unfortunately (ain't aging a bitch?).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

...Then there is the issue of your bootup ROM. What are your thoughts on how to boot up your system (i.e. program your EEPROM)?

If this is your first project, I would highly recommmend you start out at very low speeds.

Some things you need to consider:

1) Loose the old school CMOS. As other have said, the ABT/ACT TTL families are THE best/fastest to design with when using discrete components. If you start out with fast decoding logic, you can then push your CPU speeds up to the limiting factor, usually the EEPROM? in a basic system.

2) EEPROM programmer/size of EEPROM. The size will determine your address decoding scheme.

3) Bypass capacitor's/noise levels. This is perhaps THE single most important wall that beginners overlook. I did and I wasted a year chasing a ghost. Finally though persistence paid off, and I wish to pass on my experience.

4) How will you wire it up? Solder? Custom boards? Wirewrap?

There's much more I could ramble on about, but I'll cut it short here. Good luck!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Thankfully, you have young'uns like me to remind you. Since this is marginally on-topic, I'll continue the posting, but I'll refrain from furthering the digression afterwards.

If I'm understanding the schematics rightly, the MMU chip focuses mostly on Z80A interfacing to the 65xx bus and some DRAM timing (the rest is handled by the VIC-IIe). The "memory management" aspect of the chip appear limited to storing configuration bits set by the CPU, decoding accesses to $FF00-$FF04 (8502 address space; I think this would appear at $3F0x in the Z80A space), and responding to some of memory-map-affecting the cartridge pins. The PLA (model 8721; HUGE compared to the C64's 82S100 by the looks of it) appears to implement the actual combinatorial decode logic. Yes, folks, this means that the Commodore 128 dedicates the majority of 96 pins of IC interfaces to its address decoding. Enjoy!

Cripes this is complicated. If you ever want to see a schematic diagram that is about as dense to read as you've ever seen, turn to page 740 in the Commodore 128 Programmer's Reference Guide. Yikes! Dave Haynie is a better man than I am for having to analyze that kind of circuitry!

Thanks for the safety tip on the TTL guys, I realize that there are inherent problems with speed latency and gremlins in my scratches of a diagram. All good info. I still dont exactly know what the VDA or VPA pins do. the manual says

The Valid Data Address and Valid Program Address output signals indicate valid memory addresses when high and are used for memory or I/O address qualification.
VDA VPA
0 0 Internal Operation Address and Data Bus available. The Address Bus may be invalid.
0 1 Valid program address-may be used for program cache control.
1 0 Valid data address-may be used for data cache control.
1 1 Opcode fetch-may be used for program cache control and single step control.

Anyone care to elucidate how you put these to good use?

I was thinking of using a AT29C512 which I would program from my PC and test in the proto computer. Lots of Bypass caps at least on every IC and of course when I actually get to plugging circuits into a bread board to test I would run it at low speed 1/4Mhz. once I make it work then I can crank up the speed. Put in on some vector board and then maybe get some circuit boards made up....

Again, working from fading memory (which is covered up by "fading" hair), the MMU, among other things, generated the "translated address bus," which encompassed the A8-A15 address lines. The PLA,as you say, took care of the combinational logic in response inputs from the MMU and VIC-II. I'm still amazed that it actually worked.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

Unfortunately, WDC's documentation doesn't really clarify the use of these signals. When I built my POC unit, I had a strange problem involving one piece of I/O hardware, which was solved by correct implementation of VDA and VPA.

It has often been said one picture is worth at least 1K in words, so start by locking at the I/O decoding logic in this schematic.

Any instruction that involves some sort of memory access is subject to one or more intermediate cycles, during which the MPU has to compute the effective address. During that time, the address bus may undergo transitions that result in invalid addresses being presented.

As noted in the data sheet, any time both VDA and VPA are low the address bus should be considered invalid. While this usually is not an issue with RAM and ROM, it could be a problem with I/O hardware. The concern is that invalid bus cycles can result in false read operations that may inadvertently touch hardware registers when they should not be accessed. Hence the use of VDA and VPA in the above referenced schematic.

The logic equation looks something like this:

I/O is selected when the address is in the range $D000-$DFFF, VDA is high and VPA is low. If the VDA/VPA combination is anything other than high/low, the I/O decoder (74AC138) is not selected and thus no I/O hardware reacts in any way to address bus activity.

While on the subject of qualifying I/O accesses with VDA and VPA, also take a look at read/write qualification in that same schematic. The logic prevents a /WD (write data) from being applied to any read/write device (RAM or I/O) unless Ø2 is high. D0-D7 are not valid unless Ø2 is high, which is why it is essential to not allow a write operation to occur when Ø2 is low. This logic, combined with the VDA/VPA logic, will assure that all chips behave correctly during periods of invalid bus activity.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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