46 minutes ago, StephenHorn said:
I found parts of that to be a little hard to parse, but I think I pretty much agree. Honestly, I have my doubts as to whether Paul will ever buy even the X16e, because the emulator is even less expensive and provides all the features of the X16 at an acceptable level of performance. With a little tweaking of the source code, it could even emulate the CPU (and various other components) running even faster than the real X16 will allow. I don't think Paul has ever indicated what, exactly, is interesting to him about the X16.
A compiler would have simply abandoned parsing, as it had unbalanced parentheses, just recently fixed. A notional interest in the CX16e would be the interest with the greatest standing that fits the argument, so for the sake of argument I was prepared to grant it (pending contradiction).
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. One part of that could well be that it appeals to a variety of different niches.
And a system that was perfectly suited to target exactly one of those niches might have some "checklist features" that they like better, but if nobody ever writes any interesting programs for that system, the checklist features don't matter.
So if a bit of compromise against my personal "ideal 8bit retro system" is necessary in order to attract interest from that range of interests, I reckon it's probably a worthwhile trade-off.
The thing that FIRST attracted me to the project doesn't even seem to be a thing anymore, which is that it was going to use the 65816. However, OTOH, given the expansion slot design, putting in a 65816 card that takes over the system bus looks like it would be pretty straightforward, so even if the surface mount 65c02 for the CX16c is soldered in for cost reduction, as long as it has at least one expansion slot, "swapping in" a 65816 looks like it might still be workable.
Indeed, since the 65816 sends the status of the Emulate bit onto a pin (Pin E, 35 in the 40 PIN DIP, Pin 39 in the PLCC, which are NC's in the 65c02), the same CPLD that is handling the takeover of the system bus protocol could trap writes to $0001 and raise the top bit if the 65816 is operating in Native mode, allowing for mirrored Native Mode versions of the system ROM banks ... if, that is, the system ROM banks do not occupy more than half of the System ROM.