Commander X16

note for admins: can you tell me if this breaks rule 3.C? I hope not, not the least because the former is meant to be DIY-only and the latter is very likely to remain on the drawing board.

So, while idling around on the mastodons, I found 2 interesting projects that seem to be in effect forks of the CX16, and they seem to have interesting ideas that might be worth looking into.

OpenX65 by Jarda: Successfully implemented an OPM emulation onto a board! See https://www.jsykora.info/2023/11/aura-f ... of-ym2151/
The IKAOPM emulation fits in an iCE40UP5k (like that used in the VERA) with room to spare - and it isn't optimized in the slightest for this use case. A custom-built emulation could provide much better results - who would say no to an OPZ-like upgrade!
(anyone know of a good search engine for mastodon/activitypub? please? the one built in doesn't. work. Was looking for this: https://oldbytes.space/@jarda/111314981782447451 but if i hadn't entered the actual site i would have never found it.)

(Sentinel 65X)? by Studio 8502: Proof that Yes, you can make an X16-compatible for cheap. See: https://soc.studio8502.ca/@mos_8502/111528836375882933.
Current BOM is around 60 USD for an X16-compatible, though with reduced RAM (512k, could be fixed with SDRAM handling circuitry?), no serial, expansion, second VIA... and no OPM. (but see above, this is a fixable issue!)

The "Sentinel 65X" guy seems to be reinventing the Commander X16 Phase 2 (which should be way cheaper than Phase 1) while patting himself on the back for being so smart.

Yeah, nothing he's doing is original.

To OP: @Wavicle has already built a "community" version of the system, a stand-alone VERA adapter, a replacement FM synthesizer chip, and has designed a gen-2 board.

So the tl;dr is that all this stuff has already been thought of and is in some stage of development.

fair enough, just thought that these would be interesting to look at since I didn't know y'all had it all figured out already - especially the FM synth replacement, as a mere outsider I would have thought there was no progress, especially since the thread about it hadn't been updated in a while.

Guybrush: are you sure you couldn't have worded that unoriginallity claim better? might want to be a bit careful with that mallet lest you drive away some contributors... if i didn't know any better your words could seem like mocking his mere attempt.

also heard S8502 is seeing what prevented jamming an 65c816 so i'm not sure your originallity claim will last much longer - assuming that would even matter, considering the limited information he's working with.

Just as a side note: What prevented the X16 from using a 65C816S was the extra circuitry and associated timing issues involved in demultiplexing the upper 8 address lines from the data lines. Totally doable, not even particularly difficult—but would drive up the cost of the machine.

FavoritoHJS wrote: ↑Wed Dec 06, 2023 11:34 pm are you sure you couldn't have worded that unoriginallity claim better? might want to be a bit careful with that mallet lest you drive away some contributors... if i didn't know any better your words could seem like mocking his mere attempt.

I'm pretty sure I couldn't have, but hey, that's just me. If they had done just a bit of research they would have known why the first generation is so expensive and that the cheaper variants would eventually be available. Or maybe they did and chose not to mention it, making it seem to the casual observer as if they're somehow smarter than all the people who poured probably thousands of hours into making this a reality. There wasn't even a line that would show that they understand why this first gen product uses DIP packaging and plenty of discrete logic chips which make it cost this much.

I'm not mocking the attempt (which, btw, at this stage consists only of pointing out that surface mounted parts and CPLDs make for a cheaper final product), I'm pointing out that their entire thread seems to (un)intentionally fail to mention that all of this has already been discussed and explained ad nauseam in David's YouTube videos, in the Facebook group and on this very forum (both incarnations of it).

The 65C816 had a couple of issues affecting integration.

TL;DR: 65816 is really only practical if you do your bus decoding / chip select generation with a CPLD instead of discrete DIP chips. The computer was designed to minimize architectural black boxes at the board level, so a CPLD didn't fit into this model very well. Also, one of the Dev team members who is very knowledgeable about these CPUs and the Commodore KERNAL really didn't like the '816.

The first big issue is that Michael Steil doesn't like it. I've talked with him some about this and the guy knows his stuff and had some legitimate gripes with it. The biggest one is that the Commodore jump table overlaps slightly with the 65C816 vector table. Overall, though, he just doesn't like it because it looks like a 16 bit hack tacked onto an 8 bit processor. It looks like that because that is exactly what it is. I personally think that a few of those hacks were sorely needed to get around issues like the very limited stack size on the 6502.

Another issue is handling RAM/ROM mapping in native mode. The Commodore KERNAL does not play well with native mode, so in order to avoid a years-long effort to rewrite the kernel for the '816, the CPU would need to drop into emulation mode for KERNAL calls. The straight-forward way to do this is to leave the bank address 0 mapping as it currently is implemented. This creates a problem with the upper address bits of both ROM and RAM sometimes coming from the $00/$01 registers and sometimes from the bank address multiplexed onto the data bus during the low phase of PHI2. This isn't too hard to do from a technical standpoint, it can be done with two tri-stateable transparent latches (i.e. 74xx573) tied to the E(mulation) signal from the CPU. This increases the number of discrete DIP ICs to 3.

Once that is solved, we now have to add logic for asserting the chip select signals for low RAM, high RAM, and ROM based on whether or not the bank address is 0. Perhaps this could be done with a high fan-in NOR gate, but off the top of my head I'm not familiar with any currently in production. At this point, one needs to re-evaluate one's life choices and start thinking of a 5V CPLD. About the only choice here is the ATF1508, which is a very capable part but only available in PLCC or QFP packages, not DIP, and costs $12 by itself.

Another potential issue I've been hit by: while the 65C02 can change the data bus 10ns after the edge of PHI2, it only ever does this when pushing an address onto the stack; however the 65C816 does this every single cycle (because the first half cycle is when the bank address is multiplexed onto the data bus). This has created issues with propagation delays and hold times for some peripheral designs where the data they are intended to pick up changes before they fully sample it because they sample slightly after the 10ns window. This was a significant issue early on getting VERA working with a 65C816 plugged into the X16 hardware, but I've long since fixed this in the FPGA design.

So, while I personally am still a fan of an "X17" with an '816 that is 100% backwards compatible with an X16, it's a big effort to make the '816 mode usable at all. Also, it kind of looks like the C128 at that point. As someone who owned a C128 shortly after it came out: I *love* the C128, but even I had it running in C64 mode 90+% of the time.