Is this the model you would recommend? I was considering Atmel GALs but it seems from the forum that they are hard to program. I would rather not buy an expensive programmer. If there is a cheap board that I can program the chip over USB with or documentation of the protocol so I can build a programmer (which I have done before) then that would be ideal.

This sounds good. How much logic could I fit into one? I would also need one that could be easily programmed (ie no high-voltage or expensive programmers) If I do try to do the complicated memory mapping I suggested, it would be something like this. Do you think it would fit?



Also, from Garth's page it seems that there are some speed penalties for running at 3.3v. Would you recommend just running everything at 5v to make things easier?

For ROM speed, is it just phase time - tDSR - decode? 70 - 30 - 10 = 30ns for 14MHz? For writing to RAM, is it phase - 20 (min time before phi2 goes down) - decode? 70 - 20 - 10 = 40ns for 14MHz?

Make sure you look at Jeff Laughton's animated to-scale timing diagrams, at http://laughtonelectronics.com/Arcana/V ... iming.html. He shows and explains the efects of speed on margins, and voltage on speed, etc..

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

Atmel's GALs have a programming algorithm that doesn't appear to have widespread support. For GALs, track down Lattice parts, which are readily available from eBay sources.

On the other hand, Atmel's 15xxAS CPLDs are "industry standard," in that they may be programmed with Atmel's test rig (which I have) or via a suitable JTAG setup. Atmel offers WinCUPL for writing your code, which ultimately gets compiled to a standard JEDEC fuse map that can be burned into any PLD that uses that format. Hence you could use WinCUPL to write code for a Lattice GAL.

My POC V2 unit, which is currently on the "drawing board," will use an Atmel 1504AS CPLD in a PLCC-44 package for the glue logic. Said logic will include memory mapping for a single 512KB SRAM, as well as the customary chip selects for RAM, ROM and I/O. The design will also include wait-stating for ROM and I/O, since a goal of this design is to support 20 MHz operation. The irony is that the PLCC-44 package takes up only a little more space than the PDIP-24 package of a 22V10 GAL, yet the 1504AS has far more logic capability.


Something along those lines would work with a 22V10 GAL (10 outputs). You need to do some reading on the standard GAL series and what they offer in terms of logic capabilities and I/O pins. At the time when GALs were riding high, many companies produced interchangeable parts, such as 16V8, 20V8, etc. The data sheets are still readily available.


In general, CMOS performance is a function of operating voltage. The relationship between Vcc and Fmax (maximum operating frequency) is graphically described in the WDC product data sheets—look on page 24 of the 65C02 data sheet to see the graph. The Vcc vs. Fmax curve for the 65C02 indicates that 14 MHz is possible at 3.3 volts. Stepping Vcc up to 5 volts increases Fmax to (it is implied) well over 20 MHz. It's your call. I chose to run my POC units at 5 volts so I could use standard 27Cxxx EPROMs and other standard I/O hardware. Going with 3.3 volts may close some doors but open others (larger SRAMs are 3.3 volt parts, for example).


A simplistic way to state the timing goal is to say that the addressed device must accept or output data before the fall of the Ø2 clock during a valid read or write cycle. There's a bit more to it but that is a starting point. So what you can do is work your way back from the fall of Ø2 to determine the level of performance that the glue logic and addressed device must achieve. Let's suppose the Ø2 rate is 10 MHz. Hence the duration of each phase of Ø2 is 50ns, assuming a symmetric clock.

In studying the 65C02 timing diagram, it is understood that the MPU places a valid address on A0-A15 no more than tADS nanoseconds after the fall of Ø2. That number is listed as 30ns maximum if Vcc = 5 volts, which means that A0-A15 will be valid 30ns before the rise of Ø2 (however, see my digression below). At that time, your glue logic would get to work generating the appropriate chip select for the addressed device. The glue logic, of course, adds gate delays (prop time), so the relevant chip select doesn't get asserted until tPROP nanoseconds after tADS, where tPROP is the cumulative delay of all gates involved in the selection process. Let's suppose tPROP is 10ns for the sake of argument, implying that you are using a PLD (10ns via cascaded discrete logic is essentially not achievable). That being the case, the chip select will be asserted tADS+tPROP nanoseconds from the fall of Ø2, which is 40ns. Looking at it a different way, chip selection will not occur until 60ns before the next fall of Ø2, which is our ultimate reference point, since D0-D7 must be valid (read) or will be stable (write) before that point in time (I'll get to that in a minute).

Now, even though the addressed device's chip select has been asserted we don't yet have a "connection," as the device itself exhibits some delay from when it is selected until it is ready to accept or output data. Let's say that device is a 27C256-55 EPROM (fastest erasable version of the 27C256 series available from stock), which is what I use in my POC V1.1 unit. The EPROM's "access time" is 55ns, which is defined by the symbol tCE. What tCE means is that the device will take up to 55ns to respond following assertion of its /CE (chip select) input. This is a worst-case number, of course, but must be considered in designing a circuit that will reliably operate in a variety of temperature and voltage conditions. Hence the EPROM isn't guaranteed to respond until 5ns before the fall of Ø2, which is cutting it uncomfortably close.

DIGRESSION: Some of WDC's timing figures seem to be unworkable when considered in terms of how fast the 65C02 and 65C816 can be operated. A number of us are of the opinion that the 30ns tADS number is clearly bogus, as devices such as CMD's SuperCPU cartridge for the Commodore 64, which operated its 65C816 at 20 MHz, would not have functioned if tADS = 30ns were true. Also, my POC V1.1 unit runs reliably at 15 MHz, which the timing analysis says is impossible if tADS is actually 30ns.

Also to be noted is the delay that occurs from when the address inputs of the 27C256 are asserted until it exposes the correct memory cell to the data bus. This delay is defined as tACC and is listed as 55ns as well. Since A0-A15 is valid before /CE is asserted (due to tPROP), tACC will be satisfied before tCE and can be safely ignored.

The other EPROM input that glue logic must control is /OE (output enable), which must be asserted before the EPROM will actually drive the data bus. As with /CE, some delay will occur after /OE is asserted before data will appear, which is defined by the symbol tOE, which for the 27C256-55 is 35ns. As all read/write activity on non-65xx silicon should be qualified by Ø2 to avoid glitches (especially important with the 65C816, which uses D0-D7 to generate the memory bank address during Ø2 low), the reference point for tOE is the rise of Ø2. Since each clock phase is 50ns in duration, the earliest that the EPROM could be made to generate output would be 35ns after the rise of Ø2 or 15ns before the next fall. Hence the logic that qualifies RWB must assert /OE in less than 15ns if the EPROM is to put data on the bus before the fall of Ø2.

The WDC specs say that data must be valid tDSR nanoseconds before the fall of Ø2, that is, 10ns. In reality, that number can be (probably is) smaller than specified, as the MPU samples D0-D7 on the fall of the clock. Once the EPROM is driving the data bus your circuitry must satisfy the MPU's tDHR hold time, which elapses 10ns after the fall of Ø2. Hence the /CE and /OE inputs to the EPROM must be maintained for the tDHR period to assure that the MPU will reliably read what's on D0-D7. As it turns out, the EPROM maintains output for a short period of time after /CE and/or /OE are deasserted, which is described by the symbol tDF, and is specified as 25ns for the AMD EPROM that I am using. Hence the EPROM takes care of satisfying tDHR.

As you can see, it's not complicated, just some addition and subtraction. Understanding timing characteristics is key to successfully designing a circuit that will run fast. As Garth once point out, you can get away with murder at 1 MHz. Higher speeds won't be as forgiving.
________________________________________________
Edit: fixed two typos.

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

Those are great.

BigDumbDinosaur, your explanation is exactly what I was looking for. Maybe something like that could be added to Jeff Laughton's animated page? It answered all my questions.

Out of curiosity, if the tDF is too short, what can you do?

As long as nothing else cuts in and starts driving the bus, bus capacitance will hold the last value for much, much longer. I observed, by accident, tens of thousands of times as long when I was developing the testing for my 4Mx8 5V 10ns SRAM module that I sell.

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

Garth answered that in his post...it's likely you won't run into that sort of problem. Even though I went to quite a bit of trouble in the design of POC's PCB to minimize parasitic capacitance, I've observed some data persistence on the buses such as Garth observed with his DIMM test setup. However, to further allay your concerns, consider the following.

tDHR (read) and tDHW (write) on the 65C02 are 10ns at 5 volts. Looking at it from the perspective of the fastest part you are likely to install into a 65C02 system, a static RAM (SRAM), let's see how that influences your design.

In his 4MB SIMM, Garth is using the Cypress CY7C1049D-10 SRAM, which is a 10ns part. That is, the CY7C1049D is guaranteed to be available for read or write access no more than 10ns after its /CE (chip enable) input has been asserted. Also, there is a spec for data persistence called tHZCE. tHZCE is the time that will elapse from when /CE goes high (deasserted) until the SRAM's data lines go to the high-Z condition, which means they can no longer access or drive D0-D7. tHZCE is a maximum of 5ns, but may be less (it definitely won't be zero).

Now, it would seem that tHZCE is too short to satisfy tDHR and tDHW. However, the SRAM's /CE input isn't deasserted until after tPROP has elapsed, since the same glue logic that enabled the SRAM is what will disable it. Even if tPROP is the 10ns of a fast PLD, tDHR and tDHW will be satisfied, and in fact, data persistence due to bus capacitance will guarantee it.

Something that I hope you take away from this discourse is that glue logic prop time is not something to be cavalierly dismissed. Allowing it to build up too much will limit the speed of your system to that of a 10 dollar pocket calculator.

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

BDD, great explanation again.

I have been thinking more about the memory map. Do you think it would be possible for the CPLD to talk to an SD card and copy a few hundred bytes of bootloader code into RAM? I know I can do the SD card format but I am not sure a CPLD could handle something that complicated. I am trying to think of a way to use the SD card to hold code without having to wire up a separate ROM too.

Also, if the stack at 0100-01FF is not big enough, what would you normally do? Push the relevant variables to the stack then copy them elsewhere in RAM to be retrieved and popped later?

I can't speak on BDD's behalf, but I would move to a 65802 if I had to have a larger system stack. The question that you might want to ask yourself is why 256 bytes is not enough. Is it because you're using a high-level language compiler that you can't easily modify? If not, coding around this limitation shouldn't be that difficult; just keep the system stack for return addresses, and roll your own data stack elsewhere, using a zero-page pointer.

Mike

From the program tips page of my 6502 primer:

A common criticism of the 6502 is that the stack space is so limiting. A few higher-level languages (notoriously Pascal) do put very large pieces of data and entire functions and procedures on the stack instead of just their addresses. For most programming though, the 6502's stack is much roomier than you'll ever need. When you know you're accessing the stacks constantly but don't know what the maximum depth is you're using, the tendency is to go overboard and keep upping your estimation, "just to be sure." I did this for years myself, and finally decided to do some tests to find out. I filled the 6502 stack area with a constant value (maybe it was 00-- I don't remember), ran a heavy-ish application with all the interrupts going too, did compiling, assembling, and interpreting while running other things in the background on interrupts, and after awhile looked to see how much of the stack area had been written on. It wasn't really much-- less than 20% of each of page 1 (return stack) and page 0 (data stack). This was in Forth, which makes heavy use of the stacks. The IRQ interrupt handlers were in Forth too, although the software RTC (run off a timer on NMI) was in assembly language.

If you wanted to set up a multitasking system then, and give each task its own portion of the stack space, you could do three tasks with no trouble at all, perhaps six or eight with care. (Remember that the above, using less than 20% of the stack space was, in a sense, already multitasking.) The 65816 works much better for multitasking systems anyway though, and it has a 16-bit stack pointer and a relocatable direct page, so it's like every task can have its own zero page. The 65802 that Mike mentioned is an '816 made to go into an '02 socket which means you are limited to the first 64K bank; but that still gives a ton of benefits. Unfortunately the '802 is no longer available. The '816 is available, with no end in sight.

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

I can't really answer, as I don't know the protocol for talking to an SD card. I suspect you'd be working with state machines, which a reasonably sized CPLD can do.


If you are truly worried about stack overflow then you should consider using the 65C816, which theoretically will support a 64KB stack. However, as Garth replied, actual stack overflow from ordered pushes is rare. Most often, when that happens it's due to program errors that fail to clean up the stack after using it.


You meant the 65C816, I'd guess. The 65C802 has been out of production for some 20 years.

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

It sounds like the stack will be big enough. I have also been thinking about what could be done with a CPLD. One clever thing to do would be to reuse some ununsed opcodes to tell the CPLD to set the bank page. You could also have an opcode to move the stack somewhere else in memory or have multiple stacks since the CPLD translates all the addresses.

Couldn't you use the bus signals to enable separate program and data memories that were each 64k? You would not be able to execute code from the data section or fetch constants from the program section but you would have double the memory range.

This also looks like a neat option if you are using a CPLD and want to hold some startup code: http://www.digikey.com/product-detail/e ... ND/1768308

If you are going to use the 65C816 there are no unused opcodes. If you are going to use the 65C02 all unused opcodes are NOPs of varying lengths and execution times. Either way, there's no need to do anything like this because you can set up registers in the CPLD that can be read/write and be made to affect the memory map.


You could, as long as you are willing to make the CPLD police each bus access.

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

If you're willing to go to that complexity, it would be simpler and giver better results to just use the 65816. It is made to do this kind of thing much more efficiently. You can set the program bank and the data bank (which may or may not be the same bank), and other banks can be accessed at any time through long addressing, without changing the bank registers. From experience, I can tell you there's a disadvantage to forcing program and data memory to be separate; so I would recommend against that. The '816 can address 16MB of memory space, so you'll have enough. There's a 16-bit stack pointer which can be changed to give each task its own stack space without the inefficiency of having to move the stack to another part of memory. Zero page is now called "direct page" because it's not bound to page 0 anymore, as you can put it anywhere in bank 0, so each task can have its own direct page. A bank is 64K, while a page is 256 bytes.

Back to the 65c02 though, Dr. Jefyll (Jeff Laughton) on this forum has a lot of clever circuits to trap unused '02 op codes and things like watch the SYNC line during I/O access to do special things. Some are scattered around the forum here, but I hope he will document the collection well on his website. [Edit: He gave me permission to post them on mine since he won't be able to get them up on his own site for a while yet, and he sent me the diagrams. It's at http://wilsonminesco.com/6502primer/potpourri.html#Jeff.]

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

Yes, the 6502 and 'C02 have immense potential for this, because there are lots of unused opcodes, and they mostly occur in a nice, regular pattern. That makes it easy to design hardware that will detect those opcodes and trigger special functions you've invented yourself. A few examples:

• Here's a simple demonstration of what I'm talking about: Ultra-fast output port using 65C02 illegal instructions. Many variations are possible, for example writing to one bit selected from several (rather than writing to 5 bits simultaneously).
  
  
• Since we were discussing stack space issues, check out Radar Controller hacks 6502 illegal instructions. Marc Brooks created a long list of new functions that respond to unused 6502 opcodes, and this includes expansion of the stack space.
  
  
• Along the same lines as Marc's project is my KimKlone computer. Among other feats, the unused opcodes expand the address space. The size of the space (16 MB) and the speed and ease of its accessibility are directly comparable to that of a 65c816.
  
  
• Re-mapping Op-codes (eg: to create virtual instructions)

It's true there's more than one way to skin a cat (oops! -- sorry, kitty! ). Exploiting unused opcodes isn't the only option; however it conveys a huge advantage performance-wise, and results in smaller code, too.

I thought the '816 had one unused opcode left. Maybe it's supposedly "reserved for future expansion," but nothing prevents expansion by us! BTW, even without unused opcodes the '816 still has plenty of scope for clever tricks that expand the instruction set. The entire 65xx family is wide open, simply because almost all the "registers" (ie; zero-page) are off-chip and therefore accessible for embellishment.

cheers,
Jeff

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

I was thinking in terms of one or more CPLD registers that would roughly correspond to the four "preconfiguration" registers labeled PCRA-PCRD that were present in the Commodore 128's MMU and mapped in at $D500. You could write bit patterns into these registers that defined various RAM/ROM/IO combinations. When you wanted to select a specific combination you did a write operation on the corresponding "load configuration" register, LCRA-LCRD, which appeared at $FF01-$FF04 in all banks (the MMU's $FFxx range could never be mapped out). It was the write that switched the configuration—the actual value written was irrelevant. The result is a single instruction switched the configuration in only a few clock cycles. If one peruses the BASIC ROM, a variety of STA $FF0x instructions can be seen, which set up different memory maps on the fly.


That would be the WDM instruction (opcode $42—WDM is a two byte instruction). It behaves as a NOP and is marked "reserved" in the instruction set.


That the '816 has dedicated hardware outputs like VDA, VPA, VPB, E and MX to tell the system what is going on at any instant opens doors to several hardware implementations that could do all sorts of cool things.

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