"standard" I/O compatibility

BruceMcF

Active Member
May 19, 2019
139
42
28
A CPLD/FPGA can do everything.
I don't particularly care what an FPGA can do in this context since I wouldn't have any interest in commissioning anyone in Shenzhen to put together anything in an FPGA. Not saying what anyone else ought to be interested in, but that wouldn't interest me much.

But if there is a CPLD that is the equivalent of a few or a handful of 22v10's , which can handle the bus addressing and can act as SPI bus master for a couple of SPI chips that are of interest, I would be happy to have all of that consolidated into one hard programmed chip.

And while I'm definitely not a hardware hand, my impression is that you can't just toss CPLD's and FPGA's in the same basket. That is, CPLD's don't seem to evolve near as fast as FPGA's. Heck, you can get SPLD's like 16v8's and 22v10's that are upwardly compatible with some of the very early SPLD's.
 

picosecond

New Member
Sep 27, 2019
11
3
3
Northeast U.S.
I don't particularly care what an FPGA can do in this context since I wouldn't have any interest in commissioning anyone in Shenzhen to put together anything in an FPGA. Not saying what anyone else ought to be interested in, but that wouldn't interest me much.

But if there is a CPLD that is the equivalent of a few or a handful of 22v10's , which can handle the bus addressing and can act as SPI bus master for a couple of SPI chips that are of interest, I would be happy to have all of that consolidated into one hard programmed chip.

And while I'm definitely not a hardware hand, my impression is that you can't just toss CPLD's and FPGA's in the same basket. That is, CPLD's don't seem to evolve near as fast as FPGA's. Heck, you can get SPLD's like 16v8's and 22v10's that are upwardly compatible with some of the very early SPLD's.
You're getting way too wrapped up in semantics. Programmable logic is a continuum. There are no bright lines that distinguish CPLDs and FPGAs. There is tons of overlap in device complexity and programming methods in the big-CPLD / small-FPGA markets.

If the re-programmable aspect of FPGAs bothers you, just draw a box around the FPGA and its programming ROM. Many devices have bitstream encryption and other security features, so they are effectively inseparable. Or pick an FPGA that uses flash instead of SRAM for its programming and lock it. Or an SRAM based one with optional one-time programming.

Hardware engineers don't care about mostly meaningless marketing nomenclature. Just pick a device that does what you want and don't worry about what someone else calls it.

You can't generalize about device longevity. Programmable logic is no different from other semiconductors. A device will stick around as long as it makes the manufacturer money. Sometimes it's decades, sometimes it's months.
 

BruceMcF

Active Member
May 19, 2019
139
42
28
You're getting way too wrapped up in semantics. Programmable logic is a continuum. There are no bright lines that distinguish CPLDs and FPGAs.
Of course it's a continuum, and when people are talking about a wide continuum, we normally break it down into subsets, like SPLD, CPLD, FPGA ... where there is no hard boundary between "simple" and "complex" and if one was being pedantic, a field programmable gate array is kind of complex programmable logic device, and it's just historical sequence that puts them next to each other on the continuum.

And yes, when speaking in general terms., it is commonly understood to be talking about tendencies rather then claiming it is true in each and every instance. In general, popular configurations of "medium sized" CPLDs tend have a lot of market longevity, either in their design or upwardly compatible upgrades.

But talking about the market economics that drive that is too much like work, so I'll break that off there.
 
Last edited:

GregZone

Member
Sep 29, 2019
32
20
8
That's quite an exaggeration. The FPGA used in Gameduino was introduced in Q1 2007. And while Xilinx are not exactly encouraging its use in new designs, it is still in production. The last time I checked its EOL has not been announced. The XC3S200A is definitely long in the tooth but calling it obsolete is a stretch.

That being said, porting the design to Spartan-6 would have made lots of sense. You get a lot more chip for similar cost. That family will remain in production until at least 2027.
I would imagine the Verilog (or VHDL) for something like a RGB video controller could be quite easily ported to almost any FPGA that has the required minimum clock capability and required number of logic elements etc.

For a new design it would be reasonable to choose a more recent FPGA that meets the minimum criteria (with some expansion headroom), which comes in at a competitive unit cost. There are plenty to choose from these days, and as alternatives to Xilinx, who appear to be more targeting the higher end these days, and also focusing on non-maker friendly BGA packaging.
So, perhaps a Altera or Lattice FPGA might make more sense. Perhaps one of the cheaper iCE FPGA's might even be a fit?

Speaking of which, does anyone know which FPGA is currently being used to implement VERA? I can see on the prototype board images that it is a smaller package than a Spartan-3A (that the GameDuino used).

On David's 2nd update video I can see that it appears to be a 48pin TQFP (or QFN?) packaged FPGA. The GameDuino's XC3S200A is a 144pin TQFP.
Although I can't make out the markings, it does look like it might be a Lattice logo on the chip?
So I'm guessing it might even be one of the lower cost iCE40 FPGA's (which are available in QFN48 package).

It's such a shame that the VERA development is not open sourced, with the technical details being freely shared for those of us with an interest in FPGA keen to play with / and perhaps even be able to contribute to the final product.
 
May 22, 2019
486
250
43
It's such a shame that the VERA development is not open sourced, with the technical details being freely shared for those of us with an interest in FPGA keen to play with / and perhaps even be able to contribute to the final product.
It will be, but you have no idea how many people are constantly suggesting "pie in the sky" features on Facebook... if the Facebookers had their way, VERA would be the whole computer, with a 32-bit CPU, 3D rendering, and streaming audio....
 

picosecond

New Member
Sep 27, 2019
11
3
3
Northeast U.S.
Speaking of which, does anyone know which FPGA is currently being used to implement VERA? I can see on the prototype board images that it is a smaller package than a Spartan-3A (that the GameDuino used).

On David's 2nd update video I can see that it appears to be a 48pin TQFP (or QFN?) packaged FPGA. The GameDuino's XC3S200A is a 144pin TQFP.
Although I can't make out the markings, it does look like it might be a Lattice logo on the chip?
So I'm guessing it might even be one of the lower cost iCE40 FPGA's (which are available in QFN48 package).
David wrote in the FB group that the Vera FPGA vendor is Lattice. We also know that it has at least 128KB of embedded RAM. That doesn't narrow it down much...

I looked closely at the video too. I agree it's most likely a 48pin QFN. My best guess is Vera uses the Lattice iCE40 UP5K. The package matches, the RAM matches, it's cheap, and the LUT count seems about right for a display controller of this complexity.

I really like the UP5K. I think it's a good candidate for a fully embedded 6502 micro with decent capability. It could never match CX16's RAM size of course and the graphics would probably have to be scaled back. But I think you could run an embedded 6502 much faster than CX16's 8MHz target.

It's a big project, especially if you roll your own 6502 core. But it could be lots of fun. I'll never get around to it. I have way too many paying chips to work on.
 

picosecond

New Member
Sep 27, 2019
11
3
3
Northeast U.S.
It will be, but you have no idea how many people are constantly suggesting "pie in the sky" features on Facebook... if the Facebookers had their way, VERA would be the whole computer, with a 32-bit CPU, 3D rendering, and streaming audio....
Yes, many of the FB comments are from people who know absolutely nothing about hardware design.

That being said, some of the dev team's comments have given me pause too. Take the "too slow" AY-3-8910's for example. Handling slow peripherals is pretty much microcomputer 101 stuff. I'm all for keeping things simple, but I don't think adding wait states by driving RDY should be considered too-complicated territory.

Some of the comments during the YM2151 bringup were pretty scary too. If one cares about designing for worst-case timing (and one should for a project like this) it is impossible to run the YM2151 at 8MHz without violating some datasheet parameter(s). I'm not surprised they have something working on the bench. Is the design robust enough to build hundreds or thousands of working units?

There have been many crappy, crash-prone computers built over the years. I would hate to see CX16 added to that list because of sketchy hardware design. This project isn't especially cost or performance sensitive. There is no reason to push the envelope and risk system stability.

There is still plenty of time for debugging and improvements, so I remain optimistic that the final result will be robust.
 

GregZone

Member
Sep 29, 2019
32
20
8
I really like the UP5K. I think it's a good candidate for a fully embedded 6502 micro with decent capability. It could never match CX16's RAM size of course and the graphics would probably have to be scaled back. But I think you could run an embedded 6502 much faster than CX16's 8MHz target.
Yes, the iCE40UP5k (as used in the recent ICEBreaker board, and others), is a very nice & cost effective little FPGA. But as with all solution design, it is always a case of determining the best fit for purpose, for the design task at hand.

Personally, I think the best option for a full FPGA implemented CX16 would be to port it to MiSTer. Given there is already a mature MiSTer C64 core, this would also provide a good point of reference.

I already have a DE10-Nano, amongst my collection of FPGA dev boards, and the MiSTer community is growing stronger by the day with a significant number of platform cores now supported (including quite a few retro 8bit + 16bit computers).

Plus, for new users the price of a DE10-Nano and one of the now commonly available plug-in 32MB SDRAM modules (to get it up and running for MiSTer cores) will probably be cheaper than a stage 1 or stage 2 CX16, but perhaps more importantly come with the added benefit of providing the new user with access to a whole variety of alternative gaming console and computing cores to play with, all for the one hardware investment. :)
 
  • Like
Reactions: mobluse
May 22, 2019
486
250
43
Personally, I think the best option for a full FPGA implemented CX16 would be to port it to MiSTer. Given there is already a mature MiSTer C64 core, this would also provide a good point of reference.
I have been thinking the same thing, although I would probably start with the VIC-20 core, rather than the Commodore 64. And yes, I'd be thrilled to have a MISTer core for the Commander.
 

GregZone

Member
Sep 29, 2019
32
20
8
I have been thinking the same thing, although I would probably start with the VIC-20 core, rather than the Commodore 64. And yes, I'd be thrilled to have a MISTer core for the Commander.
Yes, of course. The VIC-20’s simpler hardware / memory map etc would seem a closer match as a basis to the CX16.

Once the CX16 is finalised, and hopefully the required resources become available to the community, then a CX16 MiSTer core project will hopefully become a reality! :)
 

BruceMcF

Active Member
May 19, 2019
139
42
28
That being said, some of the dev team's comments have given me pause too. Take the "too slow" AY-3-8910's for example. Handling slow peripherals is pretty much microcomputer 101 stuff. I'm all for keeping things simple, but I don't think adding wait states by driving RDY should be considered too-complicated territory.
AFAIU, doesn't doing it on the 65C02 mean that RDY only works for reads? A sound chip you cannot write to would be a bit problematic.

I was a bit skeptical whether it was something that couldn't be made to work, or something where making it work in the glue logic approach they are using was too much of a headache.

But I've still got my fingers crossed that the 65816 works out when they try it.
 

picosecond

New Member
Sep 27, 2019
11
3
3
Northeast U.S.
AFAIU, doesn't doing it on the 65C02 mean that RDY only works for reads? A sound chip you cannot write to would be a bit problematic.
No.
RDY did not work for writes on the original NMOS 6502. It's fully functional in the WDC 65C02.
65C02 RDY is a little weird because it is bidirectional, but that's not difficult to deal with.

See section 3.10 and table 7-1 in the w65c02s datasheet for the details.
 
Last edited:

picosecond

New Member
Sep 27, 2019
11
3
3
Northeast U.S.
Personally, I think the best option for a full FPGA implemented CX16 would be to port it to MiSTer. Given there is already a mature MiSTer C64 core, this would also provide a good point of reference.
Yes. At the very least, MiSTer would make a nice development platform for a design that could be cost-reduced and nicely packaged later.

One main obstacle to this approach is experience. Except for Vera's designer, it is clear from the FB comments that the rest of the core team have very little experience designing digital systems, and none at all with FPGA design methods.

That's fine of course. Everybody starts with zero experience and I am grateful my learning curve was not on public display in social media. But a big part of this project is education, and not having "how to do it the right way" on the hardware side is a missed opportunity.
 

BruceMcF

Active Member
May 19, 2019
139
42
28
No.
RDY did not work for writes on the original NMOS 6502. It's fully functional in the WDC 65C02.
65C02 RDY is a little weird because it is bidirectional, but that's not difficult to deal with.

See section 3.10 and table 7-1 in the w65c02s datasheet for the details.
Thanks! I added AFAIU since I had got that from somewhere other than the datasheet, so it was clearly someone confusing NMOS 6502 with the 65C02. I hesitate to say it was someone in the design team, maybe it was someone else on FB and I got them confused together. But the datasheet makes it clear they are taking advantage of the static design to just hold state, which eliminates that NMOS limitation of writes not holding.

I'm not a hardware guy, but If all that is needed is to generate a low on RDY for (with AY3's on their original 2MHz speed limits) something like 4 additional clock cycles when that I/O zone is selected, it seems like that could be done with not very much glue logic ... I know they have a countdown clock divider circuit, modifying one into a one shot pull down seems like it should be straightforward ... then make it a really long count, and once it works, adjust the initial count down until you get the fastest one that still works.

So yeah, now I'm just as puzzled why they couldn't get it to work.
 

Hiraghm

Member
May 18, 2019
35
8
8
The team has firmly rejected a built-in Ethernet option. It will not be happening.

There WILL be an RS-232 UART, as Bruce has explained, and this can be connected to a terminal server (ie: Network or WiFi "modem") for network access. With an ESP8266 or ESP32 based device and NodeMCU, you can have full access to standard network services.

While most people may opt for the simpler "AT" command set, I'm encouraging developers to look at natively supporting NodeMCU, since it's much more powerful.
What's NodeCPU?
 

picosecond

New Member
Sep 27, 2019
11
3
3
Northeast U.S.
I'm not a hardware guy, but If all that is needed is to generate a low on RDY for (with AY3's on their original 2MHz speed limits) something like 4 additional clock cycles when that I/O zone is selected, it seems like that could be done with not very much glue logic ... I know they have a countdown clock divider circuit, modifying one into a one shot pull down seems like it should be straightforward ... then make it a really long count, and once it works, adjust the initial count down until you get the fastest one that still works.

So yeah, now I'm just as puzzled why they couldn't get it to work.
That's the gist of it.
You might find these forum posts at 6502.org interesting. The first is a simple RDY generator, the second a clock stretcher (useful for NVMOS 6502 writes for example)

I think they have never tried using RDY to stretch cycles. They have drawn a very bright "too complex" line and resist crossing it. IMO this line is in the wrong place and they are actually making the job harder, not easier.

Sometimes you have to learn things the hard way. These are hobbyists on their first big project. They don't have the benefit of decades of design screwups to help make the easy path clear. My profile pic is a reminder to myself of that. The kid who designed it was a real bonehead and was very lucky it worked.
 
  • Like
Reactions: BruceMcF
May 22, 2019
486
250
43
What's NodeCPU?
To expand on what Bruce said... it is a Lua interpreter for the ESP8266 WiFi module. Lua is a programming language very similar to BASIC, but with much more power. Putting this in a WiFi module means we can talk directly to the network with simple commands.

For example, something like
conn:send(“hello world”)
Sends a message on an open network connection.

And since the ESP chips are also computers in their own right, we can do a lot of things with them besides just use them as dumb network cards.
 

Hiraghm

Member
May 18, 2019
35
8
8
To expand on what Bruce said... it is a Lua interpreter for the ESP8266 WiFi module. Lua is a programming language very similar to BASIC, but with much more power. Putting this in a WiFi module means we can talk directly to the network with simple commands.

For example, something like
conn:send(“hello world”)
Sends a message on an open network connection.

And since the ESP chips are also computers in their own right, we can do a lot of things with them besides just use them as dumb network cards.
oh. thanks for the info...
I've heard of Lua; I think Lightwave used it as a scripting language... and I vaguely recall coming across something about Lua in connection with the SIM5320A Adafruit FONA cellular module.