Wait-States with a GAL

[BigEd]

BigDumbDinosaur wrote:

kc5tja wrote:

http://apple2online.com/web_documents/a ... _65-79.pdf

... pages 9 through 15 [...] may be relevant to both the use of RDY and the use of clock-stretching [...]

I just thought I'd pass this on. It seemed interesting.

It is ... [and] supports a long-time assertion of mine about when to assert RDY on the '816: do not assert it when PHI2 is low, as it will result in an invalid bank address being latched.

Agreed, this document is an interesting find. But I don't see that it supports your position on RDY. It says that Apple's support chip controls the bank latch with the assumption that RDY is stable throughout phi2 low. Add-on hardware should not break this assumption. There's a statement here about Apple's design, not about the '816 behaviour or spec.

Cheers
Ed

[BigDumbDinosaur]

fachat wrote:

That requires that the address decoding to detect a slow device is done before phi2 rises. That can create some timing constraints for higher clock speeds.

With the '816, the address bus is guaranteed to be valid before the rise of Ø2. In fact, even at 20 MHz, a 7 ns 16V8 GAL is more than fast enough to detect that an address for which wait-stating is required has been placed on the bus. So I don't envision any timing gotchas with Daryl's circuit.

Quote:

Also your design automatically restricts RDY to a single cycle - which is often enough, though.

That could be addressed by using an extra flop, although that might not be possible in the 16V8 (22V10, most likely). A two-position jumper could be used to select one or two wait-states.

[8BIT]

Since the 65C22 requires the addresses to be stable before PHI2 rises, I figured that most systems work around this principle too. If the address decoding is too slow, it should be updated too.

I plan to experiment with adding a second flip-flop and for allowing different address ranges to select either 1 or two wait states.

Depending upon the # of Address inputs and other signals needed for the address decoding, this should still fit in the 16V8.

Daryl

[ElEctric_EyE]

HiassofT wrote:

BigDumbDinosaur wrote:

Probably no easier in terms of expressing the logic. The cost of the part itself isn't particularly important at this stage, as I don't have any immediate plans to mass-produce this thing.

OK, good points.

Quote:

More significantly, the XL9536 and XL9572 are 3.3 volt parts, which would preclude their use to control standard 5 volt CMOS parts. I don't want to have to consume PCB real estate with voltage level converters (and the propagation delay they produce).

This, however, is not an issue. Although the XC95..XL series are running at 3.3V, the I/Os are guaranteed to be 5V tolerant. So all you need is a small 3.3V voltage regulator sitting somewhere...Hias

First BDD, nice to see someone using alternate tech, i.e. Altera, compared to the "most popular".

But, I am writing in just to clarify something which I've quoted above...

There are still 5V Xilinx CPLD devices being sold by distributors. The XC95xxx family is powered by 5V and all I/O's are obviously 5V compatible.
However, the XC95xxxXL series are 3.3V powered devices. One can read about all the tolerances and 5V I/O compatibility in the App Notes for the XL series.

Also, one will pay a premium for the older 5V powered parts for as long as they last...

[BigDumbDinosaur]

ElEctric_EyE wrote:

First BDD, nice to see someone using alternate tech, i.e. Altera, compared to the "most popular".

You mean Atmel, not Altera?

Quote:

There are still 5V Xilinx CPLD devices being sold by distributors. The XC95xxx family is powered by 5V and all I/O's are obviously 5V compatible.
However, the XC95xxxXL series are 3.3V powered devices. One can read about all the tolerances and 5V I/O compatibility in the App Notes for the XL series.

What is problematic with the XL series (and any other 3.3 volt PLD) is interfacing to CMOS parts. The XLs are not at all hobby-friendly, and are not ideal for prototyping and short-run applications.

Quote:

Also, one will pay a premium for the older 5V powered parts for as long as they last...

Maybe and maybe not. Although Xilinx and Lattice are busy cutting back on their 5 volt PLD parts and indirectly inducing a price run-up, Atmel is not. That's the reason I'm looking at Atmel for the PLD logic in my next generation POC computer.

I recall that 20 years ago it was predicted that PLDs would be the demise of the 74xx logic series. Well, guess what? Twenty years have come and gone, and 74xx parts are still readily available. Adding insult to injury, at least one manufacturer, NXP, has expanded their line of 74ABT parts, albiet they are SMT types for the most part. BTW, it was also predicted EIA-232 would go the way of 25 cents per gallon gasoline once Ethernet was developed. Hasn't happened. Ditto for SCSI after SATA came along.

[kc5tja]

It's a pity I cannot find a 74ABT688. I cannot think of a better chip outside of programmable logic to perform 6502/65816 address decoding with.

[GARTHWILSON]

Quote:

It's a pity I cannot find a 74ABT688. I cannot think of a better chip outside of programmable logic to perform 6502/65816 address decoding with.

+1. I've been wishing for that one too. The '521 is the same thing, but still unavailable, AFAIK.

[fachat]

kc5tja wrote:

It's a pity I cannot find a 74ABT688. I cannot think of a better chip outside of programmable logic to perform 6502/65816 address decoding with.

+1 The '688 has been my favourite address decoder for years :-)

André

[BigDumbDinosaur]

The fact that the '688 is unobtanium in ABT silicon was a factor in my decision to equip my POC V2 unit with programmable logic. Also, I was starting to feel cramped in the PCB real estate department with all those gates scattered about.

However, having studied my next concoction a bit more, I'm now of a bent to forgo the use of GALs and instead apply something like Atmel's ATF2500C, which is a low-end CPLD. I can incorporate all logic on that one part in less real estate, if I use the PLCC44 version (there's also a PDIP40 package). Alas, my present programmer doesn't support anything larger than a GAL22V10, so it looks as though I will have to spend some of the company's hard-earned money on a more up-to-date unit.

As an aside, I have early plans for an even more ambitious unit that would support a full 16 MB of memory that could run a true preemptive multitasking operating system (which I've dubbed 65nix). There would also be hardware memory protection that takes advantage of the 65C816's ABORT input. The logic that would be required to implement this thing would be much too involved to be satisfactorily realized in anything less than a good-sized CPLD. Therefore, I might as well go off the deep end and have expansion slots, plug-in memory cards (SIMMs), a wet bar—and a toilet to go with it.

[ElEctric_EyE]

The 8 bit identity comparator is in the XC95xxx library. Why are you people so stubborn?

And as I said before the XC95xxx family is still being sold, and is a strictly 5V device.

I ask again, why so stubborn to stick with your TTL/CMOS discrete parts?

[GARTHWILSON]

Quote:

I ask again, why so stubborn to stick with your TTL/CMOS discrete parts?

It's because I don't want to invest the time and money to get started in programmable logic right now. I think Daryl will be providing some PLDs as standard parts though which will be geared around 65K projects.

[ElEctric_EyE]

Oh, I see now. You guys are making replacements for IC's no longer made, maybe custom parts along the same lines?

Replacements with the same pin count as the original?

If so, that's cool. I won't push.

[kc5tja]

ElEctric_EyE wrote:

I ask again, why so stubborn to stick with your TTL/CMOS discrete parts?

I cannot speak for anyone else, but for me, it comes down to:

1) Cost. Getting started with FPGAs is damn expensive. I have $500 budgeted for this purpose -- to TEACH myself how to use them. Yes, I'm aware of cheap solutions, and they might work great for more limited projects -- embedding a single CPU with only 20% of the resources left over for other logic. This is self-limiting, and impedes my grander ideas from the get-go. If I'm going to spend the money, I'm going to spend $200 on a good FPGA kit, with effectively infinite room for growth. The $199 Xess Spartan-3E model is what I currently have my eye on right now.

2) Developer tools are necessarily vendor specific. I can't stand this. No open standards exist, except for ISO Verilog and VHDL. We've played the Tom and Jerry game about this elsewhere on this forum.

3) Developer tools require Windows to really work right. Some claims of success running software in Linux can be found here and there on the 'net, but seemingly without fail, when things go wrong (and they do), the support forums I've read all indicate, "You should use Windows." Part of my $500 budget is reserved for a copy of Windows and VMware, should I discover the necessity of this.

4) Programmers sold separately, which couple to ports no longer in production. It's as if vendors are incapable of making USB-native programmers. Instead, most programmers I've seen are parallel port devices. I don't have a parallel port, requiring me to purchase additional converters, which imposes still more software compatibility constraints.

and finally, and perhaps most relevant to me,

5) For the same reasons why people buy jigsaw puzzles instead of purchasing a photograph.

[Ruud]

kc5tja wrote:

I don't have a parallel port, requiring me to purchase additional converters, which imposes still more software compatibility constraints.

Then buy an USB programmer. I have a LPT-programmer but it refused to cooperate with any of the USB2LPT converters I tried.
An other option: if possible, buy a docking station for your laptop.

I was forced to revive an old Compaq Armada laptop to be able to use my programmer again :(

[BigEd]

kc5tja wrote:

ElEctric_EyE wrote:

why ... stick with ... discrete parts?

I cannot speak for anyone else, but for me, it comes down to:

In a similar vein, not wishing to try to change your mind but to put forward an alternate view:

kc5tja wrote:

1) Cost. Getting started with FPGAs is damn expensive. I have $500 budgeted ...

I think $100 is possible and $200 should be fine, for anyone on a limited budget. For those on unlimited budgets... I don't know!

kc5tja wrote:

2) Developer tools are necessarily vendor specific...

I think you're referring to the bitstreams being proprietary and undocumented. But that's not the level anyone works at. If you design in Verilog or VHDL, you can be pretty neutral: you still might need to describe timing constraints for each vendor toolchain. If you work in schematics you'll probably get more locked-in - other than re-entering them in another system. But...

kc5tja wrote:

3) Developer tools require Windows to really work right. Some claims of success running software in Linux can be found

The Xilinx tools are free and cross-platform and I've found them very reliable on Linux. So, I'm prepared to consider this a single-vendor market in the medium term - no cross-platform concern and no issue with swapping toolchains. It's no bigger a problem than having WDC as the only supplier of 65816.

kc5tja wrote:

4) Programmers sold separately, which couple to ports no longer in production. It's as if vendors are incapable of making USB-native programmers. Instead, most programmers I've seen are parallel port devices.

Xilinx parts allow either parallel port or USB adapter cables. The USB choice is more universal but more expensive. You do only need to buy one! $60 from ebay for a grey import. (Note that a USB-parallel printer converter is not a solution.)

kc5tja wrote:

and finally, and perhaps most relevant to me,
5) For the same reasons why people buy jigsaw puzzles instead of purchasing a photograph.

This is a very good point. People make projects covering the span from relays, through transistors, 74-series, ROM-based CPUs to FPGAsand then into python and javascript. All are good, but each of us has areas of interest.

Cheers
Ed