Introducing: "Steckschwein"

[BigEd]

Found a copy of the schematic:
http://web.archive.org/web/201206281353 ... _schem.pdf

[ArnoldLayne]

BigEd wrote:

Found a copy of the schematic:
http://web.archive.org/web/201206281353 ... _schem.pdf

Cool, thanks!

[fachat]

Dr Jefyll wrote:

ArnoldLayne wrote:

Unfortunately, the link to the schematics seems to be dead.

If this can't be resolved then I'll upload the schematic myself. I'm out of town right now but have a copy on my machine at home.

Personally I find the VIA-SPI idea very appealing. It`s just a small amount of hardware, judiciously applied, and it solves the only problem not soluble by software -- namely, the bottleneck on transmission of the datastream itself.

-- Jeff

I have to look up where I stored it, but you can use the VIA to actually easily use for SD-Cards with only a small variation: an additional output to XOR the shift out register. Make sure the last BIT shifted out is always 1, and before you shift out the byte, if the first BIT shifted out is zero, invert the output with the XOR, and also XOR the output BYTE, then shift it. This way you can also work with SPI modes that expect the data on the leading clock edge (and not the following as the VIA/CIA shift registers usually do).

André

[ArnoldLayne]

Yay! I noticed our little Project has been added to the homebuilt page! Thanks a lot for that!

In other news: We are concentrating on creating PCB layouts right now, so we will have a (hopefully) stable base for further development without wobbly connections.
Not that much Steck anymore, but still a lot Schwein then.

[ArnoldLayne]

Goodbye steck, hello schwein:

http://8bit-gefriemel.blogspot.de/2015/ ... bande.html

Video and sound will follow soonish.

[BigDumbDinosaur]

Just a little bump to this.

During a recent visit to the Steckschwein site, I noticed this update posted on July 19:

Quote:

Since we introduced our new banking logic to access 512k RAM, our glue logic is being accommodated by a Xilinx XC9572 (without XL) CPLD.  This component has long been deprecated when we started using it.  We chose it because it was what we had available.  The upgrade path would be the successor family XC95..XL.  Those have been rather expensive lately, and finally AMD/Xilinx axed their whole CPLD line in 2024, leaving us at a dead end.  Where do we go from here?  The market for CPLDs is not exactly growing.  Only a few manufacturers are still actively producing them.

It seems the logical path to follow would be to update the design to work with an Atmel (aka Microchip) ATF1508AS CPLD, which is in a PLCC84 package like what you have on Steckschwein.  The 1508 is in current production, relatively inexpensive and has more logic resources (128 MCs vs. 72 MCs) than the XC9572.  The fastest version is rated at 7.5 nS TPD.  You’d likely have to spin a new PCB to use the 1508, but while doing so, could add a JTAG port for easy programming.

atf1508as.pdf

Atmel ATF1508 AS CPLD Data Sheet

(690.1 KiB) Downloaded 42 times

BTW, one thing I would not do is have the CPLD act as the Ø2 clock source.  CPLDs have TTL-level outputs, not CMOS.  WDC’s specs calls for a clock that meets CMOS levels, with a maximum rise/fall time of 5 nS.  While a CPLD can meet the rise/fall time spec, it likely cannot satisfy the VDD × 0.7 high phase requirement.  While there is wiggle room with clock symmetry and rise/fall times, not reaching VDD × 0.7 may bring about some instability.  A better approach would be to use a flop (74AC74) to condition the clock signal, which takes care of symmetry, voltage levels and rise/fall times.

[BigEd]

(Just to note, I checked the most important thing, which is that this CPLD can operate at 5V.)

[ArnoldLayne]

BigDumbDinosaur wrote:

It seems the logical path to follow would be to update the design to work with an Atmel (aka Microchip) ATF1508AS CPLD, which is in a PLCC84 package like what you have on Steckschwein. 

Indeed. That's why the rest of the article is about the ATF1508 and how to program it using the Adafruit FT232 breakout adapter.

BigDumbDinosaur wrote:

BTW, one thing I would not do is have the CPLD act as the Ø2 clock source.  CPLDs have TTL-level outputs, not CMOS.  WDC’s specs calls for a clock that meets CMOS levels, with a maximum rise/fall time of 5 nS.  While a CPLD can meet the rise/fall time spec, it likely cannot reach the satisfy the VDD × 0.7 high phase requirement.  While there is wiggle room with clock symmetry and rise/fall times, not reaching VDD × 0.7 may bring about some instability.  A better approach would be to use a flop (74AC74) to condition the clock signal, which takes care of symmetry, voltage levels and rise/fall times.

Good point. The reason we generate Ø2 with the CPLD is to have the option to do clock stretching instead of using RDY, and maybe introduce odd duty cycle, since we do not use the Ø2 low phase for anything, so we as well might keep it as short as possible and Ø2 high as long as needed.
As stated in the article, there will be breadboarding again. Meaning - I will redesign the "computer core" around an ATF1508, and look into some other things (like clock generation) as well, as I am at it.

[ArnoldLayne]

BigEd wrote:

(Just to note, I checked the most important thing, which is that this CPLD can operate at 5V.)

Yep!
There is also the ATF1508ASV which runs on 3.3V. One day, going to 3.3V will be unavoidable, but for now I am happy there are still 5V native CPLDs in active production.

[BigDumbDinosaur]

BigEd wrote:

(Just to note, I checked the most important thing, which is that this CPLD can operate at 5V.)

Yes, plus, as Arnold notes, there is a 3.3 volt version.  The TQFP packages offer 80 or 96 user-defined I/O pins, depending on which package is used.  Lotsa capability in a relatively-inexpensive device.

From what I have read on the Microchip site, they seem to be committed to continuing with SPLD and CPLD production, which makes sense.  After all, not every application needs the resources of an FPGA.  Plus an SPLD or CPLD is “instant on”—no need to load configuration from a support ROM like with an FPGA.

Now, if only someone could convince Microchip to clean up WinCUPL... 

[BigDumbDinosaur]

ArnoldLayne wrote:

BigDumbDinosaur wrote:

It seems the logical path to follow would be to update the design to work with an Atmel (aka Microchip) ATF1508AS CPLD, which is in a PLCC84 package like what you have on Steckschwein.

Indeed. That's why the rest of the article is about the ATF1508 and how to program it using the Adafruit FT232 breakout adapter.

Adafruit...something about that name always gives me a chuckle. 

Quote:

Good point. The reason we generate Ø2 with the CPLD is to have the option to do clock stretching instead of using RDY, and maybe introduce odd duty cycle, since we do not use the Ø2 low phase for anything, so we as well might keep it as short as possible and Ø2 high as long as needed.

With the 65C02, use of RDY for wait-stating is not the problem it is with the 65C816.  However, wait-stating via clock stretching is something that can be readily done with a couple of gates—I illustrate such a method here.  I designed that circuit with the 65C816 in mind, but it will, of course, work as is with the 65C02—the Ø1 clock output can be omitted if there is no need for it.

The test design uses a 74AC109 J-K flop to act as the wait-state timer.  The reason I externalized that function was the design that was going to use that clock generator was based on the ATF22V10C GAL, in which rigging up a J-K flop is a royal pain.  However, in the ATF1508, setting up a J-K flop is trivial and can be synthesized entirely in buried logic.  The only output the CPLD would have to produce to stretch the clock is something that goes low when the MPU has to be stopped.

Quote:

As stated in the article, there will be breadboarding again. Meaning - I will redesign the "computer core" around an ATF1508, and look into some other things (like clock generation) as well, as I am at it.

Should be interesting.  With a reasonably compact PCB layout and a 7.5 nS CPLD making the glue logic decisions, no reason Steckschwein 3.0 (?) couldn’t make it to 20 MHz...or maybe beyond.  A while back, David Grey at WDC informed me that production testing of MPUs and the 65C22 is done at 20 MHz.  I know from testing in POC V1.2 that even the Sanyo-cored 0.6µ 65C816s will easily handle 20 MHz.  The current TSMC parts are likely better.

[plasmo]

This is an excellent write up of Quartus to ATF150x conversion process with many references. I have large stock of EPM7128SQC100, EPM7064SLC44 and still able to find a reliable source for EPM7128SLC84, but if I ever need to use ATF1508 and ATF1504, I’m bookmarking this link to aid future search.

https://www.steckschwein.de/post/2025/0 ... toolchain/

I’ve done few experiments with converting designs in Quartus to ATF150x. My experiences with POF2JED were mixed; simple designs were converted successfully, but complex designs may not convert correctly.

Write up about openOCD and JED to SVF is most excellent.

Bill

[ArnoldLayne]

plasmo wrote:

This is an excellent write up of Quartus to ATF150x conversion process with many references. I have large stock of EPM7128SQC100, EPM7064SLC44 and still able to find a reliable source for EPM7128SLC84, but if I ever need to use ATF1508 and ATF1504, I’m bookmarking this link to aid future search.

Thank you. It was quite a journey to get all information together, as it is pretty much scattered all over the place, with https://github.com/peterzieba/5Vpld/ being the best point to start. I figured, I might dump my brain into a blog post as soon as I have everything together, as it might help others. Glad to read it does.

plasmo wrote:

I’ve done few experiments with converting designs in Quartus to ATF150x. My experiences with POF2JED were mixed; simple designs were converted successfully, but complex designs may not convert correctly.

Okay? What's a complex design in this context? I need to make sure my stuff is below the theshold

plasmo wrote:

Write up about openOCD and JED to SVF is most excellent.

Thanks again. As I posted my article on Mastodon, I right away got a reply from Whitequark about the completeness of fuseconv's ATF1508 support which I found encouraging enough to go that way instead of ATMISP. Being forced to use a GUI app in the middle of a mostly scripted workflow really sucks, so all hail to fuseconv.
And OpenOCD ist just a swiss army knife. No need for expensive proprietary JTAG adapters, OpenOCD and a cheap FT232 breakout adapter will do.

[BigDumbDinosaur]

ArnoldLayne wrote:

plasmo wrote:

This is an excellent write up of Quartus to ATF150x conversion process with many references. I have large stock of EPM7128SQC100, EPM7064SLC44 and still able to find a reliable source for EPM7128SLC84, but if I ever need to use ATF1508 and ATF1504, I’m bookmarking this link to aid future search.

Thank you. It was quite a journey to get all information together, as it is pretty much scattered all over the place, with https://github.com/peterzieba/5Vpld/ being the best point to start. I figured, I might dump my brain into a blog post as soon as I have everything together, as it might help others. Glad to read it does.

[RANT]
It really sucks that Microchip is apparently unwilling to invest some time in cleaning up that mess called WinCUPL and port it so it can be run on a real operating system, instead of only on that mess called Windows.  The underlying modules that do the compiling and fitting are all DOS programs, so they would have been written in ANSI C and therefore should be portable to Linux or some other x86 Unixy thing.

It has been nine years since Microchip bought out Atmel and in those nine years, they have done zilch with Atmel, other than use that product line as another revenue source.  It makes zero sense to sell a specialized product such as a line of PLDs and not provide adequate software to facilitate that product’s usage.  CUPL the language dates back over 40 years and WinCUPL had its origins during the Windows 95 days—it was merely DOS modules with a GUI front end—a pig with lipstick, as it were.  The most recent update to WinCUPL appears to have been c. 2004.  Ridiculous!

A designer intent on using one of Atmel’s PLDs shouldn’t have to jump through myriad hoops just to get the damned thing to work.  That’s too much like a new car dealer selling you a car with no steering wheel, forcing you to come up with your own wheel.
[/RANT]

[ArnoldLayne]

BigDumbDinosaur wrote:

It really sucks that Microchip is apparently unwilling to invest some time in cleaning up that mess called WinCUPL and port it so it can be run on a real operating system, instead of only on that mess called Windows.  The underlying modules that do the compiling and fitting are all DOS programs, so they would have been written in ANSI C and therefore should be portable to Linux or some other x86 Unixy thing.

Yes, the toolchain situation is a bit of a mess, especially when you want to avoid Windows (who doesn't?). There used to be a Unix/Linux version of POF2JED, which is no longer available. Which should be no problem at all to bring back. Or even better, if they have no plans whatsoever to do anything with their toolchain, why not open source it?
On the other hand, all their tools seem to run fine on Wine, including ProChip Designer.

One the plus side, they are actively producing CPLDs while almost everyone else is axing theirs. That's pretty cool and I hope they keep doing that for a while.
My theory is that their commitment to the ATF150x line is due to some contractual obligation, probably with Altera/Intel, to provide replacements for their EPM7xxx chips. But my guess is as good as anyone's here.