Hi,

I'm a software guy looking to build my first 6502-based system. The information on this forum and members' sites is very helpful, so thank you to everyone who's words I have read. I tried using software with an ARM dev board to provide PHI2, reset control, address decoding and simulated bus devices such as RAM, ROM and a UART, which went well but it only managed about 100 kHz.

I'm currently using an ATmega32 to do the same thing with a simulated version of Daryl's 65SPI although the AVR only has 512 bytes of simulated RAM and 1K of simulated ROM, so I'd like to make the jump to real hardware.

I've been thinking a lot about address decoding and reading recommendations of 74xx logic and CPLDs but I'd really like to use a SPLD because:

• They're simple enough for a software guy to understand. Sum of products, optionally inverting the inputs and/or outputs. No "registered" outputs or macrocells that I have to understand
• They can arbitrate up to 5 bus devices with single-address granularity in a single DIP24 footprint. If I want to map a 65SPI to addresses $0200..$0203 then I can. 74xx logic would require a 14-input gate for that scenario. Precision mapping with no mirroring means saved RAM and no need to think about banking out I/O

There's a SPLD compiler at the bottom of this page with source available that compiles and processes its example .equ in to a .jed. Are there any open hardware programmers that don't require a parallel port and which are known to program the readily available chips? If there is no open hardware option, I would very much like to create one. In that case, would anyone be interested in helping or advising?

Welcome to our 6502 world. If you haven't done so, please visit the "introduce yourself" topic and...introduce yourself.


I personally try to get folks new to the DYI computer hobby to build their first contraption with 74-series logic, rather than with PLDs. The main reason is using discrete gates forces you to thoroughly analyze your design's logic, which means you will acquire a much better understanding of how it all works. It'll also improve your knowledge of potential timing issues, conditions that can cause bus glitches (e.g., contention), conditions that affect the maximum reliable speed of the circuit, etc.

That said...


Most CPLDs come with a JTAG port, which is an industry standard interface for which building a programmer running off a parallel port is not at all difficult. Building a USB version is another matter. You may find it more expedient to purchase a burner from one of the many eBay suppliers.

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

Hi,

I can fully understand the motivation of "unclouded". Often simple TTL logic is sufficient to achieve your goal in setting up a small minimal 6502 system. However as soon you want to have a decent memory map, fully decoded addresses and make use of VDA and VPA of the 65816, using only TTL logic will get your project unnecessarily complex. Simple PLDs like the GAL16V8 or even the GAL22V10 can be real life safers in these cases. I'm also more a software than a hardware guy. SPLDs are very simple to use and I do not agree with BDD regarding the better understanding of circuits. I successfully use a slightly modified "galasm" from Alessandro Zummo https://github.com/daveho/GALasm. I had to modify it to be able to compile it on MacOSX (char instead of UBYTE) and a fix in GetBaseName in support.c for non-dos filenames. For some time I was using a GAL Programmer based on the project in the c't magazine of heise Germany. But once my slow DOS PC broke it was no longer usable. So I got myself a Genius G540 programmer (about 55USD incl. shipping). This is a very nice piece of hardware but the software lacks usability and it does not burn all the devices it says. I had to throw away all my A, B, C type GALs as they were apparently not supported. The support of Genius is almost non-existant. D type GALs of Lattice however are programmed perfectly. The Genius G540 is a USB programmer and the software works in the virtual Windows XP machine on my Mac. I use a lot of GAL16V8D and GAL22V10D. They are still available at very moderate prices. I love using these GALs they save a lot of real-estate on PCBs, use a lot less of wires for my bread-board setups, make design changes easy, are reprogrammable and are 5V devices (this is the main reason I use them). The syntax for the equations is simple and easy and does not require any special know-how if IDEs.

Cheers

Peter

I'm sort of in the same position as Unclouded -- after looking at various designs for a 65816, I've reluctantly decided that using 74-logic would take up a massive amount of space and would needlessly complicate my life, not to mention the layout. (I have a working, if only breadborded 6502 with pure 74-logic, so I've been through the BDD school of computer design -- and yes, for a newbie like me, that was time well spent.)

What I have in mind is something like Daryl's DEC-1 (http://sbc.rictor.org/decoder.html), but "one size larger" for the various 65816-specific thingies. If possible, it should be DIP (for easier wirewrapping) and be programmable in JTAG (so I can start off programming it with something cheap like the Bus Pirate, and upgrade to more expensive tools later).

However, from what I've read it would seem that GALs of his sort are pretty much dead, and the closest available part is something like the ATF15xx family from Atmel recommended by BDD (http://www.atmel.com/products/Other/spl ... tible.aspx). These are PLCC (sigh) and seem more complicated (another sigh) but available in large quantities and both 3.3 and 5 V, and have lots of documentation available.

So would that be the way to go, or might somebody have a different suggestion? As always, thanks for the help.

(Just to make sure I've understood the science of this -- shouldn't it be possible in theory to do a lot of this with a simple EEPROM chip or two, by hard-coding the logic table? Obviously is not what you want to do because of speed and only eight outputs, but I do understand correctly that in theory this would be an alternative?)

Atmel continues to produce GALs, although finding a programmer that understands them is a bit of a challenge.


Think of a CPLD as a large (metaphorically as well as physically) GAL, with more resources. You can write combinatorial logic and once you get comfortable with the development cycle, try your hand at registered logic and state machines.


Since you have already put something together with discrete logic, and seeing that one's needs always seem to outgrow resources in short order, a CPLD may be right for you. If you are going to use Atmel, the smallest one I would recommend is the ATF1504AS, which is in a PLCC44 package. Wirewrap sockets are available, though not inexpensive.


What you are referring to is often called a "poor man's PLD". You attach the EPROM's address inputs to the MPU's data bus and the EPROM's data outputs to a D-type latch (e.g., a 74VHC363¹). The latch's outputs are used to drive chip selects and such, up to eight maximum. The latch is opened while a bit pattern is being written to the EPROM, which itself has to be selected like any other device in the system, that is, decoding is required to assert the EPROM's /CE input. The latch is closed when the EPROM's /OE input is deasserted.

The fastest EPROM that I know of that is available from stock is the AMD 27C256-55, which JAMECO Electronics sells. This device is rated at 55ns and is the EPROM that I use with POC V1.1. Atmel makes a 45ns OTP PROM, but of course, you can't reprogram it if you make a mistake.

My recommendation is to go with a PLD rather than monkey-rig a poor man's PLD with an EPROM. Using the EPROM means more gates and more propagation delay. The Atmel ATF15xx is available from stock in 10ns pin-to-pin versions, which will make it easy to run your unit at a high clock rate.

———————————————————————————————
¹I mistyped and somehow made that 74HVC563.

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

Yes and no. An EPROM (or ROM) is no good for registered logic and state machines, but it can easily do combinatorial logic, which is to say logic that relies entirely on currently-prevailing inputs. That covers a lot of ground -- masses of gates can be simulated. Unfortunately, latches and flip-flops don't qualify as combinatorial. They don't rely entirely on currently-prevailing inputs -- they act as memories, storing the result of some previously prevailing input.

Example: The Bank Address output by an 65c816 is information that's typically stored by a latch. A ROM could not reliably act as a latch to perform that function. However, it could implement a decoder to generate the system's chip selects. (The decoder deals entirely with currently-prevailing inputs, namely signals from the latch and from A15-A0.)

Do you want a more exhaustive explanation than that? You did say, "in theory." Splitting hairs, it's true that a latch or flip-flop can be decomposed into instances of a 2:1 multiplexer, one of whose inputs is simply its own output fed back so as to recirculate. Since a multiplexer does fit the definition of combinatorial logic, in theory a ROM could implement a latch or flip-flop. But a real-world latch made from a ROM circuit would not work reliably (due to "race condition" timing issues selecting & de-selecting the fed-back information). In contrast, a memory decoder (for instance) may be quite complex, but, assuming no race conditions, a real-world ROM circuit will work just fine, though perhaps a little slowly.

Good point -- you need to get it right the first time, or else you'll be forced to purchase a new part. But 45 ns is fast enough for many jobs. Plus, on a large device like this you have the benefit of lots of inputs -- at the cost of consuming a lot of board space. The flip side of that tradeoff is TTL PROMs such as 74S288 or 82S123, which use less board space but have fewer inputs. They store 32 eight-bit words in a 16-pin DIP. They're power-hungry and hard to find, but I think they get as fast as 30 ns.

(Those 32 by 8's can be very handy as memory decoders. They fit in the same footprint as the familiar 74xx138, but are far more flexible. For example, you can manage a collection of devices with various sizes -- I mean the size of the address range they occupy. A '138 can't do that; each of its outputs will get an equal-sized address range.)

I like the expression, "poor man's PLD." But the rest of this seems misguided or at least poorly explained. Would you care to elaborate, BDD, or is there perhaps a link you can provide to material describing what you have in mind?

cheers,
Jeff

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

If we're going the direction of using ROMs in place of gate arrays, with the corresponding speed issues, why not go one step further and use an SRAM? Yes, you'd have to arrange an initialization sequence to get the logic loaded in, but getting a 20ns (or faster) 15-input, 8-output device is fairly simple, and shouldn't cost much in the way of power.

You could do that, although it seems, like the poor man's PLD, to be a lot of hoop-jumping for some combinatorial logic. You might as well use a real PLD and reduce the mess to a one chip solution.

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

It's more poorly explained than anything else. It's been years since I've done anything like that, so I'm not sure where a better explanation could be dredged up. I'll see if I can more adequately explain it in a later post, perhaps with a schematic.

Historical note: when Lloyd Sponenburgh of Fiscal Information Inc. was developing the hardware for what would become the Xetec Lt. Kernal hard disk subsystem for the Commodore 64, he implemented a poor man's PLD in the host adapter to handle the hardware gyrations needed to make it work. The original Lt. Kernal design ran the DOS in the RAM underneath the kernel ROM ($E000-$FFFF), which feature indirectly led to the system's name. This arrangement ultimately wasn't satisfactory for several reasons, which resulted in Lloyd figuring out how to install 16KB of SRAM in the host adapter and running the core of the DOS in there instead of in the $E000 block. The added complication exceeded what could be done with EPROM logic and a switch was made to a real PLD, two of them, actually. As an anti-piracy measure, the security fuses were blown in both PLDs, which subsequently made it nearly impossible to fix a failed host adapter if the failure was caused by a bad PLD.

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

I would rather not use a EPROM, PROM or EAROM as a "poor mans PLD" replacement. First fast ones (<25ns) are very difficult to get, they are expensive, take a lot of power and space (SDIPs are rare) and require a programmer and PROMS are like PAL one error and here it goes to the bin. SRAM need a external initialization circuitry, but even then 32kbyte cache SRAMs are rare items (they would however be fast, use less power and space and mostly come in a SDIP). This gives you a maximum of 15 inputs and 8 outputs. Also there is a big pitfall when using memory to decode combinatorial signals. You cannot guarantee spike free propagation of input changes. E.g. you want to qualify a /RD and /WR signal with PHI2, you might be surprised what the memory gives you as intermediate results.
Compared to a GAL22V10 these are in my opinion no options. So I still vote to go with a cheap (50-60USD) non-certified programmer and GALs. Lattice D GALs can be bought from many stocks and are cheap, they are 5V devices and available in SDIP with speeds down to 7ns. I looked into the ATMEL versions, but after finding that there is no reasonable priced programmer with a USB interface I forgot about this option. It's really a shame that ATMEL is not making a cheap (40-80USD) USB programmer available like they have for their AVR MCUs. CPLS are neither an option as they are no longer available for 5V (except ATMEL but.... ) I will stay with GALs and once I come to the conclusion I need something more sophisticated I will directly jump into the FPGA world.

cheers

Peter