Speed of later models

[raygard]

As the circuitry gets smaller in the future models, will the speed go up, and if so, by how much?

[m00dawg]

I would say it's just too soon to say given the current design is still being ratified but I would expect the current X16 models (P, C, and E) will all be running 8MHz and wouldn't expect there to be any changes at this point.

[Perifractic]

I would agree that we do not expect to change the speed of the product. In some cases features may be taken away as the board gets simpler, so it would be contradictory to also give it a speed improvement for less money.


Perifractic, X16 Visual Designer
http://youtube.com/perifractic

[BruceMcF]

Note, I would not expect a CX16c to come with expandable RAM, but since a 1MB SRam might be available in surface mount, I would be OK with the LowRam coming from the top 40K of a 1MB SRAM and 123 segments of High RAM available.

[raygard]

If we were so inclined -- just from a technical standpoint -- how fast could it go?

[Sean]

9 hours ago, raygard said:

If we were so inclined -- just from a technical standpoint -- how fast could it go?

Western Design Center (WDC) has been rating their MCU's and MPU's at 14 MHz for years now, and testing them at 20 MHz.  ASIC's based upon 65C02 (and variant) cores have been reported by WDC to run at speeds of 200 MHz, but in those cases most of the supporting chips (memory, glue logic, etc.) are no doubt physically integrated into the same chip.  People have overclocked recent stock 65C02 and 65C816 MPU's at speeds of up to 29.5 MHz successfully.  This doesn't mean that you could necessarily run a Commander X16 at that speed - the rest of the system, including bus, glue logic, other chips, etc. would also need to be capable and designed in such a way as to accomplish that.  Reading threads over at 6502.org I see a lot of people building 6502 (and variant) based computers where they experiment with clock speed, and often find they need to replace components or completely redesign to maintain stable operation at some point.  Sometimes that speed is less than the MPU's rated speed, sometimes they can get well above it - it all depends upon the overall system design.   

[StephenHorn]

10 hours ago, raygard said:

If we were so inclined -- just from a technical standpoint -- how fast could it go?

Additionally, the X16 team was targeting 8MHz because that was the fastest they'd been able to clock the chip on the board.

So - just from a technical standpoint - it will probably go about as fast as they ship it.

[BruceMcF]

Yes, when you get past what the speed of the ROM supports, you either need to have clock-halving built into accessing the ROM memory window or else shadowing, either of which would complicate the design. I'm not a hardware hand, but I recall 8MHz being described as near the top of the comfortable access speed for the FlashROM for a 65xx type bus.

And remember that the CX16p is the system reference design ... having the CX16p and CX16c with different top operating speeds would unnecessarily fragment the software base for what is already still a niche hobbyist system ... even if we hope it develops into a relatively big niche as far as hobbyist systems go.

[Sean]

31 minutes ago, BruceMcF said:

Yes, when you get past what the speed of the ROM supports, you either need to have clock-halving built into accessing the ROM memory window or else shadowing, either of which would complicate the design. I'm not a hardware hand, but I recall 8MHz being described as near the top of the comfortable access speed for the FlashROM for a 65xx type bus.



And remember that the CX16p is the system reference design ... having the CX16p and CX16c with different top operating speeds would unnecessarily fragment the software base for what is already still a niche hobbyist system ... even if we hope it develops into a relatively big niche as far as hobbyist systems go.

 

Maximum speed for the ROM chips is one of the common first stumbling blocks for increasing clock speed.  That can be dealt with by clock stretching, wait stating, etc. but that adds some extra complexity and some propagation delays with the required "glue logic."  Speed of other glue logic, or of supporting chips (VIA, UART, etc.) are usually the next stumbling blocks.    I can readily understand why the Commander X16 crew stopped at 8 MHz, though I wish they'd managed to incorporate a 65C816 instead of a 65C02 - I understand not wanting to mess with the multiplexed bank/data lines, especially since WDC's reference design for doing so has known problems.

[BruceMcF]

8 hours ago, Sean said:

 



Maximum speed for the ROM chips is one of the common first stumbling blocks for increasing clock speed.  That can be dealt with by clock stretching, wait stating, etc. but that adds some extra complexity and some propagation delays with the required "glue logic."  Speed of other glue logic, or of supporting chips (VIA, UART, etc.) are usually the next stumbling blocks.    I can readily understand why the Commander X16 crew stopped at 8 MHz, though I wish they'd managed to incorporate a 65C816 instead of a 65C02 - I understand not wanting to mess with the multiplexed bank/data lines, especially since WDC's reference design for doing so has known problems.

There is no need to multiplex if you want to run the 65C816 inside the 16bit address space, which is perfectly possible. You have to add a pull up resister on a pin that is a rarely used clock output on the 65C02 and is an abort input on the 65C816, so it doesn't float. However, at the moment, it seems more likely that that is going to be on a 3rd party socket daughterboard.