Commander X16

18 hours ago, Guybrush said:

Well, we can always build an emulator for our non-existent dream computer. It wouldn't be much different from where we are right now with the X16 ?.

The difference is the number of people developing for the CX16, and that suggests that the existence of prototype boards and the strong likelihood of an actual computer actually is a significant difference for this kind of thing.

The marriage to backwards compatibility is directly at odds with current day Personal Computer Usage.

I love the idea of maybe getting something put into a socket or expansion port - possibly with a daughterboard because that's retro as hell - but it's more important to make the computer work to the needs of its intended users, and...well...work at its base specifications first. Good Design will carry it forward after that. There's a reason there were so many new computers back then, and I think discussions like these really demonstrate it because we have such higher demands on our stuff now.

Honestly - Why wouldn't I just get an Amiga hardware clone project, instead? (Or a raspberry pi with everything including the disk drive sounds) . Also - it's 2021 - I am not messing with Kickstart and Workbench the same way I did in the 90's. It was bad enough I didn't know if my disks worked or not - but my Amiga became unusable when my Kickstart 1.3 disk died. As we go forward over the next 40 years of PC history, we can see how standards, design, and completeness became more important for every new computer system right into the x86 and beyond.

1 hour ago, Starsickle said:

... I love the idea of maybe getting something put into a socket or expansion port - possibly with a daughterboard because that's retro as hell - but it's more important to make the computer work to the needs of its intended users, and...well...work at its base specifications first. ...

This seems like a non sequitur, since there's is nobody suggesting anything that would involve putting a 65816 option ahead of "working at its base specifications", and the point about the 65816 is that if it's available, it would make the CX16 better meet the needs of its intended users.

17 hours ago, BruceMcF said:

... the point about the 65816 is that if it's available, it would make the CX16 better meet the needs of its intended users.

 

Right.  The way I look at it, it would be nice if it could simply replace the 65C02, with no other changes.  And I figure that was the original thought as well -- "can it just be plugged in and used like a super-powered 6502?"  And the answer (based on video #2) was: probably not without annoying and/or expensive extra work.  Since the system had to work first, that and other options were scrapped.  The decision makes sense.  It would be nice if the current board, being stable, allowed some experimentation, but meh.

 

53 minutes ago, rje said:

Right.  The way I look at it, it would be nice if it could simply replace the 65C02, with no other changes.  And I figure that was the original thought as well -- "can it just be plugged in and used like a super-powered 6502?"  And the answer (based on video #2) was: probably not without annoying and/or expensive extra work.  Since the system had to work first, that and other options were scrapped.  The decision makes sense.  It would be nice if the current board, being stable, allowed some experimentation, but meh.

Technically, "not without finding out what the issue is with the Vera startup process". Since they are taking advantage of the early assert of the 6502 address lines, it is entirely possible that the two bus timings comply with the same read delays and write holds specs, but the actual timing is not the same, so the 6502 just slips in under the bar while the 65816 misses. For instance, Vera is faster than the system bus, and is internally not synchronous with the system bus, it may be that the Vera sometimes actually performs its read early enough in the cycle when the 6502 is actually in a settled state, irrespective of what the timing diagram says, and the 65816 data bus is an an ambiguous state between the bank assert and the data asset.

And it could be use of Rockwell opcodes which can easily be replaced at the cost of a handful of bytes and a handful of clock cycles.

After their long delay getting the Proto#2 board to boot up, they can quite reasonably conclude that they don't have the time to hammer that out. If it can be fixed up later so that an end user can drop in a 65816 and just go, well, so be it, but leave that until the original is out in the wild and more people who are more interested in it have a go at the problem.

ESPECIALLY since they are explicitly setting up the slots so that a board that is willing to go to the extra work required can take over as the bus master, so a 65816 bus master expansion card is always an option. That expansion card can play clock cycle games that the drop in replacement cannot play ... for instance, with a 25MHz frequency source and a FPGA with a 2x PLL, it can generate an asymmetric 8MHz clock cycle for the 65816, with a shorter PHI2=1 cycle and a longer PHI2=0 cycle, if the problem is data not being asserted soon enough in the motherboard system clock cycle.

Edit: Note that if using an FPGA as sketched above fixed the problem, it might be a single main chip board ... other than clock module, voltage translation and some resisters and caps ... since WDC also licenses a soft core of the 65816.

14 minutes ago, BruceMcF said:

After their long delay getting the Proto#2 board to boot up, they can quite reasonably conclude that they don't have the time to hammer that out. If it can be fixed up later so that an end user can drop in a 65816 and just go, well, so be it, but leave that until the original is out in the wild and more people who are more interested in it have a go at the problem.



ESPECIALLY since they are explicitly setting up the slots so that a board that is willing to go to the extra work required can take over as the bus master, so a 65816 bus master expansion card is always an option. That expansion card can play clock cycle games that the drop in replacement cannot play ... for instance, with a 25MHz frequency source and a FPGA with a 2x PLL, it can generate an asymmetric 8MHz clock cycle for the 65816, with a shorter PHI2=1 cycle and a longer PHI2=0 cycle, if the problem is data not being asserted soon enough in the motherboard system clock cycle.

Both good points.  Thank you Bruce.  

 

I started thinking of the '16 again because of theoretical delays due to current chip shortages.  Granted, I suspect that's not on the critical path.

1 minute ago, rje said:

Both good points.  Thank you Bruce. 



I started thinking of the '16 again because of theoretical delays due to current chip shortages.  Granted, I suspect that's not on the critical path.

I'd think both designs can use a quite old process, and likely the same process (since WDC is a fabless design studio), and there will be available capacity in that process to produce a new batch if present stockpiles run low. It's rather the FPGA where I would not be surprised if there are logistic difficulties with some specific members of some specific families ... I know that the Foenix256 design was redone because she was having difficulty getting the specific FPGAs that she had originally designed around, and she felt that transitioning to a new family would ease the supply constraint.

Anyone know the deep technical explanation for why the 65816 was scrapped? I saw David's 2nd building the ultimate 8 bit computer video, but he didn't have the time to go into it in depth.

I was one of those in the 6502 camp at the beginning and after reading through the arguments I decided to buy parts and build a Ben Eater style solderless breadboard computer with a 65816 to see what was involved. The 65C816 and 65C02 seem to have a high degree of timing compatibility so it really came down to adding a high speed latch, bus transceiver, and inverter. The reference design for demuxing BA0-7 and D0-7 are included in the 65816 datasheet (you have to read it carefully though, I wasted a lot of time on my first implementation because I did not). I also needed to modify the low memory address decoder so it was not used when not using bank address 0 but would assert the correct chip enable in 24 bit mode. I wanted to keep to the all DIP design style and needed to map 18 address bits (A4-A21), plus an A1-A3 OR'd signal (to detect access to $00 and $01) to chip enables for 5x SRAM, 8x IO select, 1x ROM, and 4x ZP RAM/ROM bank flipflops. A total of 19 inputs and 18 outputs. This wasn't going to practical using discrete 7400 series DIP parts so I ended up using 2x ATF22V10C SPLDs to handle all address decoding; it was pretty similar to the C64 PLA replacements that use 2 GAL parts (e.g. "PLA20V8" which uses 2x Lattice GAL20V8B parts). This also allowed me to scrap several 7400 series chips that previously did the address decode. Altogether I think the count was 4 chips and 3 diodes replacing maybe 6 or 7 discrete logic chips (I don't recall, it was a whole season ago) to enable functionality for something that might be CX16 compatible (hard to tell without a VERA card) and can seamlessly transition between 6502 emulation mode and full 65816.

3 hours ago, Wavicle said:

Anyone know the deep technical explanation for why the 65816 was scrapped? I saw David's 2nd building the ultimate 8 bit computer video, but he didn't have the time to go into it in depth.

However, what he said there was why ... using the 65816 in 24bit address mode was using a CPLD to dereference the address, while going to the 64K address map with banking allowed the chip select to be done with glue logic. And the 64K address map could be done in the VIC-20 style that Dave preferred, where every part of the memory map only does one thing.

Of course, we don't get a blow-by-blow account of development, especially false starts and dead ends, so we don't know how much of the description of development hell in the second video was just general experience and how much was experience with the first generation of the design.

However, once you have a 64K address map, you can build the board with a 65C02 to have one less point of difference between the original Commodore Kernel and BASIC ROM code that was the starting point, so you have one fewer problem areas in trying to get the board to boot up at full 8MHz speed. Then if the board can boot with the 65C02, it's possible to see if it will boot with the 65C816.

At this point, it doesn't boot with the 65C716, seemingly because of some problem in the Vera initialization, but the board has been designed to be electrically compatible with putting a 65C816 in the 65C02 socket.

15 hours ago, Wavicle said:

Anyone know the deep technical explanation for why the 65816 was scrapped? I saw David's 2nd building the ultimate 8 bit computer video, but he didn't have the time to go into it in depth.

There are availability arguments about the 65816, it's not as popular as the 65C02 and it could go out of usage.

The design is basically the 6502 Reference design with Vera wedged on with kludges to try to make the timing work.   There was a desire to use Commodore Basic, why I don't know because it's absolutely dire, and if anyone wants to use it to teach programming to kids verging on criminal.

The one thing that has always worked is Vera which is on an FPGA, it's been revamped slightly but it always worked properly.

You might as well reduce the abilities of Vera slightly (or, say, be able to map the RAM onto a 6502 address space) and then put the CPU in the FPGA - there are umpteen 6502 cores available - and they run way quicker. You'd get a much better machine. 

RJE wrote about doing a P-System interpreter and I know Bruce was looking at the 6502 Pascal Compilers that are out there. If the 6502 was 5-10 times faster than it is now, say the speed of the Mega65's core, the problems about speed, data sizes and address space simply go away. 

Isn't going to happen though.