FPGA vs Real, what is the tradeoff?

[paulscottrobson]

15 hours ago, BruceMcF said:

One thing about the CX16 project is what appears to be a real prospect of a healthy ecosystem of ongoing hobbyist development for the system.

A healthy ecosystem requires tools and libraries that allow you to easily create a healthy ecosystem.  It requires a way in - a more modern BASIC fast enough to program (say) Pacman without 6502 assembler for those who are learners ; they can't start on the godawful MS Basic. There are things like PROG8 and CC65 that sort of work, but no-one has yet solved the basic problem that if you do 16 bit arithmetic on a 6502 it eats up memory and if you have a Sweet16 type design it eats up CPU time. I actually quite enjoy trying to fix it - my language (based on HPs RPL more than anything, though I didn't know this until afterwards) does fix a chunk of it but it's not very newbie friendly.

It has to be affordable, the big thing lost from the original design. David's $30 (?) price point was never going to happen but a $60 price point was doable (e.g. the ZX-Uno is about that). I'm not short of cash, but laying out £500 for a virtual machine is non trivial. (so, yes, I'd buy the FPGA version), especially when almost nobody is going to develop on one.

In answer to Stephen what I find frustrating is all this is doable and often present but in serious danger of being lost in absurd design decisions. No. 1 here is, as you might have guessed, the desire for authenticity when the majority of the stuff that designs system is already on the FPGA. You have an add on card for the C64 (which some may remember was the initial design)

[BruceMcF]

3 hours ago, paulscottrobson said:

In answer to Stephen what I find frustrating is all this is doable and often present but in serious danger of being lost in absurd design decisions. No. 1 here is, as you might have guessed, the desire for authenticity when the majority of the stuff that designs system is already on the FPGA. You have an add on card for the C64 (which some may remember was the initial design)

How is that anything other than saying that catering to the part of the potential market that wants what you don't care about is absurd because you are not the one who wants it? That it is being done to satisfy somebody else's desires, so it is a mistake?

On a side note, I also don't believe that the CX16c will be $700 or 600 Euros until I see it. Granted, it might be $250 in the US but 500 quid delivered to the UK under your governments daft customs policies, but that's not really on the CX16 design team's decisions.

As to the extent that the kit-buildable CX16p (whether or not the built from kit option is offered) will be confirmed to have an actual market niche ... we'll find that out when it goes to crowdfunding, but I'm not going to be surprised if it proves to have one.

[StephenHorn]

While Bruce beat me to the point about the unit cost, I do realize that import taxes and shipping, combined, can weigh heavily on the price to non-U.S. locations, and Perifrantic in particular has clarified that there are no plans to warehouse units outside of the U.S. to mitigate shipping and taxes. There was an entire thread about this problem back in February, though the specific costs were to do with the WASD keyboard:


So I get it, that makes the potential X16e -- hopefully being much smaller and lighter, and starting from a lower-cost BOM to begin with -- look a lot more attractive. But the original hardware vision of the X16 was for through-hole parts, and I have the impression that if a viable, permanent silicon, through-hole video chip solution had been available then we wouldn't have an FPGA anywhere on the X16p board. At which point, I guess I'm left to wonder if the argument would be over why the X16 doesn't incorporate an FPGA to reduce the BOM, even though that's quite likely to be the case for future revisions of the X16 (if there even are future revisions, bearing in mind that the future models are not being designed yet and the team is focused on completing the X16p).

Referring to the through-hole hardware vision as "absurd" is dismissing Dave's original vision as "absurd". Well, phooey, because to me that was a part of the original appeal: this wasn't going to be some magical "single chip on a credit card" device that was somehow a computer. I can already get one of those, it's called a Raspberry Pi.

[BruceMcF]

4 hours ago, paulscottrobson said:

You (sort of) asked what my motivation was. This pretty much sums it up. What is lacking in all the other retrosystems, with the possible exception of the Mega65 and Spectrum Next is any kind of software ecosystem.



The problem is you can't have both of these at the same time. The BBC is a good example of this. There was little or no software for the Tube add ons ; the ARM one was I think used to develop the Archimedes, the fast 6502 one was used to produce a solid 3D elite. There was a Z80 CP/M board called Torch which had access to the CPM library. But there's no real software for it.



In practice software development is for the basic system, unless there is a simple and common upgrade (say Spectrum 16k -> 48k). Some limited upgrades can be supported (say the AY chip in later Spectrum, or the use of the extended memory to avoid repeated tape uploading). But most of the 'updates' in software tend to be incidental. So the Freescape thing runs better on the Next simply because the processor can do more in the time available, and it's synced by the VSYNC interrupt.



My concern, fundamentally, is that the limitations of the CPU handicaps development. It could have been worked round in one of two ways. Having a very fast 6502 like the Mega65 does. That allows you to use VMs much more effectively, or in the case of your FORTHs loses the hit of the execution loop and only having one real stack. Or to plug a 65816 in it, which gives you lots of memory and native 16 bit data if you want it and the option of putting VERA memory in CPU address space.



Plugging in a 65816 expansion board or anything else just means that there's a seperate tiny software ecosystem limited to the few that have that board.

But what would I care about whether "there software ecosystem" a 65816 card? I would be building/buying the 65816 card to play with it, not to run other people's software. The base configuration would run other people's software.

As far as I can see, your concern is that the project started out aiming to build Dave's dream computer rather than yours, given that the workarounds you propose are to NOT have the real ASIC CPU that he wants, or else to NOT have the simple 64K memory map that he prefers.

Once you aim for a 65816 with a 24bit address space running in native mode, then the project is going to start adding other bells and whistles and you are at a C256 Feonix board which already has four or so FPGA's. Then that is a system that is never going to be able to be put into an FPGA at whatever price point the CX16e ends up hitting.

 

 

[StephenHorn]

It may sound dismissive of me to analogize the potential X16e with a Raspberry Pi, but I see them as having very similar niches. The key differences are, as they appear to me:

• 
  MS BASIC console as a frontend
  


• 
  Native 65XX-series machine language
  

Everything else differing a Raspberry Pi from an X16e is about removing capabilities from the Pi: Less memory, fewer clock cycles per second, less powerful video and audio features, fewer standard peripherals, etc., etc.

And even then, the MS BASIC console is "just software". Yes, it's important to the old school Commodore experience, but there's no reason someone couldn't create that on Linux and provide the same programming environment (or a vastly improved iteration of it that still feels similar).

[BruceMcF]

10 hours ago, StephenHorn said:

It may sound dismissive of me to analogize the potential X16e with a Raspberry Pi, but I see them as having very similar niches. The key differences are, as they appear to me:

• 
  MS BASIC console as a frontend
  


• 
  Native 65XX-series machine language
  

Everything else differing a Raspberry Pi from an X16e is about removing capabilities from the Pi: Less memory, fewer clock cycles per second, less powerful video and audio features, fewer standard peripherals, etc., etc.

I guss I don't actually view them as similar niches at all. The first niche of the CX16e is to simulate one of the real CX16's. Because, after all, simulating a system is better than emulating it. And it seems like it will be able to simulate it to the point of sitting inside a CX16c case and pretending you have a real CX16, which as far as cycle correct FPGA simulations of real hardware goes is pretty good.

The second one is the implication of removing all the capabilities you refer to, which will be its education niche if it has one at all: that it is an understandable system. But unless it is a course in FPGA's, it's the real CX16's that are the understandable system, and the CX16e is simply the more affordable simulation of that.

As far as whether it ever occupies that second niche ... I dunno. I actually would be skeptical of anyone who claimed to know, because I reckon what it would take would be an established instructor who has a compatible approach picking it up and running with it. And on the one hand, I wouldn't hold my breath, but on the other hand, stranger things have happened.

[John Chow Seymour]

Both these earlier posts in this thread (one from January, one from earlier this week) compared the X16 project to the C256 Foenix project:

On 1/3/2021 at 7:05 PM, m00dawg said:

[...] I also greatly admire the C256 Fenix and am sad to hear it will likely no longer be maintained. That thing was a retro FPGA monster. Totally different design goals but both I think were incredible designs in their own right. The C256 would have been a chiptune tracker's dream, I expect. But given the more modest limitations of the X16, I think that'll bring about some nice creativity as well.

Good news! Earlier this week Stefany announced that she is indeed continuing to develop the Foenix, and released some videos about what the next generation of Foenix would look like. I want to talk more about it, but I'll make another thread for that.

On 6/8/2021 at 6:27 AM, BruceMcF said:

This project [the X16] certainly seems to be forming a target audience more successfully than, for instance, the C256 Feonix project, even though that project also has it's own type of appeal.

In one of the two vids from last week, Stefany admits to not being very good at communicating (at least in a "PR" sense) or at building a community.  She's very good at designing computers (as far as I can tell, anyway) but not so great at outreach... a Woz who needs a Jobs, if I may.  (Then again, Woz never told people who disagreed with his designs to F____ off.  She also apologized for that in the recent video, btw.)  

For example, as an audio/music person myself I would have loved to have bought the C256 Foenix FMX, but that model came and went before I even heard about it existing.  When you do things like that it makes it very hard to build a community.  She's acknowledged this so we'll see if the community starts to grow at all.

Her dream computer is different than David's, and each has its own fans, but if the Foenix's community is smaller I'm not sure it's because of the FPGA-heavy design.

 

 

[BruceMcF]

It is important to avoid overstating things. There are always a lot of different things going on in a real world case, so a single case should never be taken to firmly establish a single point. A single case is always suggestive evidence, rather than definitive evidence.

But having said that, AFAICT, the big difference is the team. The combination of the board and the hacking of the C64 ROMs and the emulator have all contributed to the situation where despite a long delay tracking down chip select design flaws, there is much more software developed for a system that only exists as a handful of prototypes versus a system that has shipped two main iterations of the design and is now in the process of developing its "II" version.

Most of the team are from the people originally attracted to the first statement of the vision, where the a "no FPGA design" is so strongly stated that a later explanation of "I didn't want to, but in this case there's no alternative" had to be made when the decision was made to go with an FPGA implementation of the video chip.

So it seems to me like appealing to that particular market niche bore fruit in terms of attracting many of the people to the team that has brought it to this stage.

That is not a criticism of Stefanie: I really like her original Feonix designs, and even if I am not all that interested in the bells and whistles added for the Gen X, if I was flush with cash I would have probably already have bought one.

[StephenHorn]

 

2 hours ago, John Chow Seymour said:

Then again, Woz never told people who disagreed with his designs to F____ off.  She also apologized for that in the recent video, btw.

Not very PR-savvy, but absolutely something I would probably do at some point if it were my community to piss off. I try to keep a lid on my more acerbic tendencies when folks frustrate me, and walk away, but it does leak through here and there, and I'm sure there's no way I could manage a community around me without a lot of help (in the form of less-abrasive folks acting as a buffer). So I sympathize. She also seems to invest a lot of herself into her projects, and it's a rare soul who can do that and not feel like criticism is at least a little personal.

On 6/10/2021 at 10:37 AM, BruceMcF said:

The first niche of the CX16e is to simulate one of the real CX16's. Because, after all, simulating a system is better than emulating it.

Ah, yeah, I see that I made an implied assumption that my list was describing a CX16e, sans the 'p' or 'c' models, since I was specifically following up on an argument I was making in favor of the 'p' having value. If the project were to jump straight to the all-in FPGA simulator, do you think the niche still exists for that platform, moreso than an FPGA implementing a purely fantasy computer?

[BruceMcF]

1 hour ago, StephenHorn said:

Ah, yeah, I see that I made an implied assumption that my list was describing a CX16e, sans the 'p' or 'c' models, since I was specifically following up on an argument I was making in favor of the 'p' having value. If the project were to jump straight to the all-in FPGA simulator, do you think the niche still exists for that platform, moreso than an FPGA implementing a purely fantasy computer?

If it does, it's much smaller. The sentiment that a cycle exact FPGA simulation of a system is superior to an emulation of a system is well entrenched, but in the end, the key issue is whether there is ongoing release of new software for the platform.

The problem with the all-in FPGA simulator of a purely fantasy system is that the project will fork, then fork again, over disagreements in design philosophy.

But with the CX16p in the mix, only the forks that are strict supersets of the CX16p get to participate in the programs written for the larger install base made up of CX16p's and CX16c's and compatible FPGA simulators.

Those superset forks would be the functional equivalent to a board that has sold to some minority percentage of CX16p owners. Those who get them get whatever their benefit may be, AND ALSO something that "just runs" CX16 software.

It's like you have street musicians forming a small group. The guitar and the sax can argue endlessly over which one should tune to the other one, but if there is a penny whistle in the mix, they all have to tune to the penny whistle, because the penny whistle is going to keep on playing at the tuning that came out of the factory.

The "as kit buildable as feasible" CX16p system reference platform is the anchor for the design.

So, for example, you COULD steal LowRAM from HighRAM, just having five of the HighRAM segments that get selected for LowRAM addresses and not for HighRAM addresses. But doing that logic in glue logic would be much more of a hassle and could well involve too may layers of logic to get the RAM selected in time, given that there simply IS a "fastest commonly available 512K SRAM in a through pin form factor". So that hard availability constraint is like the tuning of the penny whistle: that is not a practical option for the CX16p.

They really could do exactly that for the CX16c. When removing the through pin constraint, there are 1MB Static RAM in a surface mount form factor of the same speed as the one they are using. And relaxing the requirement to address things with glue logic is one of their big available cost savings moves that keeps the ASIC CPU, VIA and sound chip. And a surface mount CPLD could easily do that "steal the LowRAM from the HighRAM" addressing trick ... it wouldn't be all that big of a CPLD. So that gives a single surface mount RAM chip, which makes a cheaper build, but still is software compatible with the base CX16p with the minimum one HighRAM chip installed. And for people who go "ewwww, CPLD", you can point to the CX16p ... "yeah, we know what you mean ... if you can afford all of that lovely glue logic, get that one instead."