I am working on my first W65C02 based microcomputer and was looking at the possibility of using this (or a similar) Atmel EEPLD instead of 74xx chips.

My thoughts being that this one chip can:

1. Replace the 4 74xx chips I would have needed otherwise.
2. Be easily reconfigured for different memory maps later on.
3. (AFIK) work as fast as (or faster) than the set of 74xx chips I would have had.

Has anyone done this before?
Is this a good idea or am I just crazy?

Any thoughts would be much appreciated.

- Billy

_________________
- Billy

Let me answer by first saying that you would learn more in the process of designing your system by using basic gates instead of programmable logic. At the most elementary level, a PLD of any kind is merely encapsulating basic gates into a single package. The downside is that you are insulated from the hardware to some extent by the language being used to program the PLD (CUPL in the case of Atmel PLDs). So I would encourage you to use discrete logic in your very first design so as to broaden your understanding of what is going on. I built my POC V1 unit (65C816 powered) with basic logic gates and was able to achieve reliable operation at 12.5 MHz on a PCB measuring 6 inches by 3-1/4 inches.

Speaking of performance, should you decide to try out discrete logic, you should design around 74AC or 74HC devices, not 74LS. The reasons for doing so are well-discussed in other areas of the forum. 74AC is substantially faster than 74HC and produces higher drive strength, but may pose some implementation problems, depending on construction methods. That too is discussed elsewhere on the forum. Similar discussions focus on construction methods (breadboard vs. wire-wrap vs. PCB) and hash out in detail what members have learned works well.

Also, you should design around the genuine WDC 65C02 or 65C816 MPUs, rather than the 6502, or the 65C02s available on eBay, at Jameco, and so forth. The genuine WDC parts are current production items and represent the state-of-the-art in 65xx microprocessors. Garth Wilson and I recommend that new builds be made with the 65C816, as doing so gives the system greater performance potential and greater programming flexibility. The NMOS 6502 has nothing to recommend itself at this point in time and should be avoided, if for no other reason other than its several design bugs.

Getting back to the use of a PLD as glue logic, you should know that the Atmel GAL you are considering uses a proprietary programming algorithm that is not supported by the majority of programmers that are available at reasonable cost. This is also true of Atmel's CPLDs. Another member, 8BIT, has a standing offer to program a Lattice GAL for anyone who is interested in using one in their design. Lattice discontinued production of their GALs a number of years ago, but examples continue to be available (although some may be Chinese knock-offs, not genuine product). I have a similar offer to anyone who wishes to use an Atmel CPLD in their system.

As a general suggestion, a small CPLD would be a better choice than a GAL at this time. As an example, in my POC V2 design (awaiting assembly), I used the Atmel ATF1504AS, which is in a PLC44 package. It takes up about 25 percent more space on the PCB than a 22V10 GAL, which is in a DIP24 package, but has six times the logic resources and many more I/O pins than the GAL.

That said, please do consider using basic logic in your first go-around. You'll learn a lot more—and will get "street cred" with your peers at school for being able to scratch-build a computer using nothing more than an MPU, some RAM, some ROM and a few basic gates.

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

I understand what you are getting at however, I do understand what is going on in the hardware (or at least I understand what logic the PLD is emulating) and the only difference (logically) to me between the PLD and the set of 74HCxx chips (2 quad NAND and 2 quad NOR) is that the latter of the two solutions will take up more space and will have higher (AFIK) propagation delays.


Mr. Wilson (or can I call him Garth?) has pretty much hammered that into my brain at this point .


Sorry, I meant to write W65C02. I would switch to the W65C816 but I already have a couple of W65C02s from Mouser.


This is probably the largest drawback to using PLDs. I really can't justify purchasing a programmer (especially for my first SBC). My EE class has a few programmers but I have no idea if they support Atmel's programming protocol (I will have to check tomorrow).


I don't think that I (currently) have a need for more logic or IO. Besides, I want to stick with all DIP for my first SBC.


At this point here are the pros for each:

74HCxx:

+ Very inexpensive (~$0.10 / gate) and no need for a programmer.
+ Feels right for my build (low level hardware, none of that newfangled software defined logic).
- Takes up more board space than the PLD or GAL might.

PLD/GAL:

+ Compact (fits all logic onto a single DIP-20 IC).
+ Faster (Atmel states that there is only a 15ns delay between input stabilization and output stabilization)
- Requires a programmer.
- Slightly more expensive than 74HCxx equivalent (~$3 / IC).
- Does not really feel right (software defined).

Based on these findings it seems unlikely that I will use a PLD, although it may be an interesting thing to explore in the future if I build something with a more complex memory map.

WINNER: 74HCxx (for now )

_________________
- Billy

Welcome, Billy, and congrats on entering the wonderful world of what goes on under the hood of a computer! As you're surely aware, there's amazing work been done in the past, and you'll have a chance to conceive and test ideas and designs of your own. Bare metal rocks!!

You haven't really given much detail about the proposed 6502 based microcomputer, such as what sort of code you hope to run, and especially what I/O it might have. This will have a bearing on the address decoder.

I see you've posted as I was typing this, so I'll cut this short. Glad you ended up favoring 74HCxx; the "feels right" comment perhaps reveals more wisdom than you realize. We look forward to hearing more from you in future.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

For anyone who is interested here is my memory map:

Binary Map:
0x00** **** **** **** - SRAM
0x0100 **** **** **** - IO_0
0x0101 **** **** **** - IO_1
0x0110 **** **** **** - IO_4
0x0111 **** **** **** - IO_3
0x1*** **** **** **** - EEPROM

Logic Equation (assuming CS_* is active high [which I think I messed up , correct me if I am wrong but I think CS_* for 65xx support chips is active low]):
CS_RAM = A15' A14';
CS_IO0 = A15' A14 A13' A12';
CS_IO1 = A15' A14 A13' A12;
CS_IO2 = A15' A14 A13 A12';
CS_IO3 = A15' A14 A13 A12;
CS_ROM = A15;

Decode Logic (autogenerated):

_________________
- Billy

Thanks! The amazing work from the past is what has inspired me to make my own microcomputer (that and the hope that undertaking such a project will help me decide if I want to major in EE or CS).

My basic idea for the computer is (probably by the standards of most here) quite simple. I plan to have the 16KiB of RAM, 32KiB of ROM, 2 VIAs, an ACIA, and a single expansion port (IO_3). I have taken Mr. Wilson's advice and not made my decoding system too complex (I hope) which has resulted in quite a bit of "wasted" address space (seeing as each IO IC / port takes up 4KiB of address space).

I will have a dip switch on the EEPROM to allow manual bank selection and the RAM will simply not use the upper 16KiB. My first VIA will be connected to a keyboard, my second VIA to an LCD, and the ACIA to a serial port.

_________________
- Billy

You can get all that, plus a lot more I/O, with a single 14-pin 74xx00 IC for address decoding, using the scheme shown at about the middle of the address-decoding page at http://wilsonminesco.com/6502primer/addr_decoding.html .


You can get those on the same VIA, with room left over for more! How many keys do you want?

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

Hmm, I do remember reading that. It simplifies the decoding a ton.

In your primer you advised against having tons of expansion slots (in particular backplanes were a big no no). I really have no use for more than a single VIA (as you have pointed out, the LCD and keyboard can be on the same one) and a single ACIA (still for serial). Which of the following would you recommend:

1. Just put the single VIA and ACIA and leave the rest of the address space empty (this would keep board size, cost, and complexity down).
2. Put a single header that would allow for a second board to use the rest of the address space later (which would violate your advice but would allow expansion later if needed).
3. Put additional VIAs on anyway and just connect their IO pins to a header for later use (IRC would not violate your advice, which I think was only talking about the data and address buses, but would make the board more complex, larger, and more expensive).

_________________
- Billy

On a side note, is there any convention on how to write out memory maps? Most of the ones I have seen start at the end of memory and work their way towards the start (which makes sense when looked at as a whole because the lower addresses are lower on the page), while others start at the start of memory and work their way towards the end (which makes sense when read line by line).

*by start and end of memory I mean 0x0000 and 0xffff respectively.

- Billy

_________________
- Billy

You may want to avoid the temptation to use such fine-grained I/O decoding. The logic will start getting bulky and slow due to too much prop delay. A lot of 65xx systems decode I/O into pages, since the required glue logic can be quite simple and fast. Incidentally, the 74AC138 is a good choice for generating I/O device chip selects.


I would go with option 1. The more hardware you add the greater the likelihood of a DOA or poorly functioning unit. It's best to learn how to fly a Piper Cub before stepping into the cockpit of a 747 and taking off for Tokyo. In other words, keep your first effort simple to maximize the likelihood of it working. Once you have this first build up and running you can develop a more elaborate second design.


I depict the architecture from the bottom up, viz:



The above is from the set of drawings for my POC V2 unit. The stuff in boxes to the left side represent alternate configurations that can be established after power on or reset, whereas the main part represents the default memory map.


Note that in the MOS Technology assembly language, hex values are traditionally preceded with a dollar sign—most assemblers will require it. Hence the C notation 0xFFFF would be written as $FFFF in 6502 source code. Binary values are notated with a percent sign and octal values (rarely used in 6502 programming) are notated with a commercial-at sign. Hence $FFFF would be %1111111111111111 in binary or @177777 in octal.

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

I am confused. Shouldn't the above memory map be very easy to decode? Ignore the hex values, the binary is the memory mapping, the hex values show the valid addresses for the given chips (or so I assume based on the fact that VIA1-3 take up the same amount of address space, as do ACIA1-3, and the VIAs and ACIAs have different range sizes).


I was thinking the same thing, I would hate to over design the thing and never end up finishing it. Better to start simple and then if I out grow the original build another one (in which I will be able to fix all of my mistakes from the first no doubt ).


No doubt I will forget this at some point and wonder why my code won't assemble . Alternatively I could write a preprocessor that replaces 0x, 0b, and 0o (I assume octal is 0o, I can't say that I've ever had any use for octal) with $, %, and @ respectively.

_________________
- Billy

What I advise against is having the processor's own address, data, and control buses go out on the backplane. You will frequently hear me refer to my "workbench computer." This is a home-made computer I use for controlling processes and experiments on the workbench for work, taking data, etc.. I am building myself another workbench computer at the moment with more of everything than the current one has—speed, memory, I/O, A/D and D/A channels and with more bits' precision, bigger display and keyboard, better portability (even though it's bigger), etc.—and I'm using a half-rack-width 3U card cage with the same 96-pin DIN connectors that VME bus uses. The processor's own buses do not go out on the backplane though. They will not go off the CPU board.

What's on the backplane is mostly VIA signals, SPI, I²C, interrupt lines, reset, power, and ground, with quite a few pins left for future expansion. Boards other than the CPU board will have things like the power supplies and A/D and D/A converters and associated signal conditioning. I'm thinking strongly of having more than one CPU board; but again, they will not look directly at each other's own buses. I may have them communicate through a VIA's shift register, with an SS22-type interface.


My current workbench computer that I've been using for 23 years (although it has had many improvements over the years) has three VIAs and three ACIAs. The new one will have at least four VIAs, maybe five. This is partly to get more of the VIA pins that have special functions. As long as you leave room for the extra VIAs, they don't all need to be connected from the get-go if you're wire-wrapping (which I'm doing because I do tend to make changes and upgrades over time). The additional bus loading of an additional onboard VIA or two is pretty minimal considering all the other loads, especially the many megabytes of RAM that come in half-megabyte ICs.

I probably don't need three ACIAs anymore though, and the tentative plan is to have two MAX3100 14-pin SPI-interfaced UARTs which are also capable of IrDA (infrared link) timing. Our resident expert on trapping unused op codes for special functions seems to be succeeding in developing circuit tricks to trap the 65816's unused WDM op code and its operand to allow operating SPI at half the Φ2 rate and maybe even the full Φ2 rate (and without any concern for addressing modes or what's in the bank registers, since it's not memory-mapped I/O), so a byte can be sent or received in hardly more than the time of one of the longest 65816 instructions.


I have somewhat answered that above. I will say however that on the current workbench computer, I originally brought most things to just the 72-finger board-edge connector; but then I had to wire up a separate 72-pin socket for every workbench project, and I couldn't have two or more of these connected at once unless I made up another big socket with the combination. I started adding smaller connectors for access to individual ports. That worked much better. The new one will have these along the front edge where they're accessible from the front of the card cage, but will also have sockets farther in for things like plug-in anti-alias filters for the data converters. This card cage has removable top and bottom panels, allowing access to the top and bottom too, so I won't always have to pull a card out to change a plug-in module. What you want to do with yours may dictate some changes in interface connectors.


I tend to view it the way BDD wrote above, with "low memory" being that near 0000, and "high memory" being near FFFF (or the upper limit of the address range, which on the 65816 would be FF:FFFF, the colon being used to make it easier to read, just as 1,430,092 is easier to read than 1430092). I like to recommend using all capitals in hex numbers though, not just because 0-9 are always "capitals," but at first glance, lower-case f's look like 1's on my monitor because of how narrow they are. I do prefer the non-C "$", or putting "H" after a hex number like some assemblers like. I think both the PC-based assemblers I'm using now allow either the leading "$" or the trailing "H". It's personal preference though, I suppose. In other contexts, the "x" means you don't know or don't care what that digit is; so "0xFE" could mean 00FE, 01FE, 02FE, 03FE, etc..

I've spent enough time on this for one night. I might post pictures later.

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

You are using a lot of bits to select I/O devices. As an example, in my POC unit, I/O starts at $00D000, which is the first device. The next device is $00D100, the next is $00D200, the next is $00D300, etc. This address progression is easily decoded using only three bits at the 74AC138 decoder's A, B and C inputs, plus a chip select that is true when A15-A12 is %1101 (a NAND gate driving /E1 on the '138 with A13 driving /E2 does it). The '138 A-B-C inputs are wired to A10-A8, which takes care of telling the '138 which device to enable when the I/O block is being addressed. Splitting up the I/O space into pages is efficient and demands minimal logic.

Generally speaking, as the "distance" between devices gets smaller and smaller, the logic required to decode the address space gets bulkier and bulkier. This is why most of the eight bit micros built around the 6502 (e.g., the Commodore 64) had paged I/O decoding.


My recommendation would be to use the proper symbology. Once you get your unit running you may want to adapt a machine language monitor to it for debugging purposes. Just about every 6502 M/L monitor I have encountered uses the MOS Technology symbology for number radices. In other words, if you are going to live in France you need to learn to speak French.

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

Hi Billy - good to see some ideas being bounced around here. Bear in mind that you'll get almost as many opinions as respondents - to some extent you have to construct your own wisdom from what you see around you. For me, you can draw a memory map either way up. But zero is always described as low memory, and the vectors as at the top of memory. I think I tend to place them on the page accordingly.

As for hex, we see various conventions, and in almost all cases everyone will understand what you mean. 0xffff, $ffff, &ffff or just plain ffff. The thing to watch out for is that any given assembler (or other software) will have a strict convention. Many a time someone has written 10 when they mean $10, or vice versa, and the program is not going to behave the same way.

(We're all on first name terms here, unless someone has determinedly not used their first name, in which case their forum name or a derivative of it is fine.)

Cheers
Ed

Garth,

What I think I will do is have 2 ACIAs (1 for serial to computer, 1 for use with Geoff's VT100 compat. terminal), and 2-4 VIAs that are wired directly to IO headers. That should give me enough room to add additional functionality if need be later (through IO on the VIAs) but still allow for a (relatively) simple system to start off with.


I'll use $ with capital letters from now on (unless I post anything in C).

_________________
- Billy