Commander X16

With the way things are going, FPGA might be the only option when all the fabs are shut down and discrete chips go the way of the dodo. As much as that would suck, it’s definitely a real possibility…

5 hours ago, Fabio said:

As for The commander x8 I think we should decrease the cpu frequency to 8.33 Mhz (25/3) to ensure CX16 is a better machine

Aww... don't do to the X8 what Jobs did to the Apple II line... throttle the speed just so it wouldn't compete with the Macintosh line. (Did that actually happen or is that an urban legend?)

(Sorry to pick out @Fabio, several other people in this thread also suggested it.)

24 minutes ago, John Chow Seymour said:

Aww... don't do to the X8 what Jobs did to the Apple II line... throttle the speed just so it wouldn't compete with the Macintosh line. (Did that actually happen or is that an urban legend?)



(Sorry to pick out @Fabio, several other people in this thread also suggested it.)

I doubt that's literal truth, but clearly the IIGS could have been the New Mac, if it had been allowed to develop, rather than being shut down.

 

Can anyone tell me why the X8 interface to the VERA has to different from the X16 apart from the fact that it has only 64K of VRAM? It seems to me that if they can be reconciled that would make writing from the X8 to the X16 easier kinda like writing from EGA to VGA. If the programmers choose they can just write to the "lower" specification and have it run on both with no code changes.  Also is the upper 16K of ROM for the BASIC and Kernal ROM code "hiding" the remainder of the lower 64K from the FPGA?  If so would it be possible to make these accessible by allowing them to be banked to the same range in the X16?  That would give the X8's 65C02 another 16K to work with almost like it was an X16 with a small amount of "upper" RAM.

On 8/20/2021 at 7:16 PM, Snickers11001001 said:

That is impossible in the current state of things.    There are not basic commands for graphics or sound like the C128 or Plus/4.   Its all pokes and vpokes, that true for sound, sprites, tiles, etc.   The only exceptions are simple graphics like putting a pixel or a line on the bitmap.   



That means if X8 comes out with a vastly different VERA interface it will nuke all the work people have done on the emulated platform that's been out and targeted with development for years. (Edited to add:   Its one thing to say 'don't rely on official kernal calls; they may change' and quite another to say 'oh, the core video is getting torn out after 2 years, so sorry!')    There's a lot of ways to burn goodwill besides just not delivering on a kickstarterer.    Having some rando (to you) subject matter expert dedicate 100+ hours on a an assembler core, or IDE, or music tracker, or etc., etc., etc., only to say "oops, just rewrite your work to use a vastly different VERA" is like slapping that guy in the face.   Not only will he be reticent to go all in for your project again, but anyone who watches it happen will be likewise hesitate.  



The X8 will kill this project and ecosystem in my view.    Just go to the 'downloads' section of this site and ask:  How much of this stuff would actually work with what has been described as the X8.     That sort of pivot would be tantamount to a bait and switch.   Sorry if it is rude or uncouth to say so, but somebody has to. 



EDITED:   I've edited to moderate my tone slightly.    Sorry for the language prior to the edit. 

Couldn't the VPOKE and VPEEK commands for the X8 be implemented to hide the access method to the VERA's video RAM?  They only need to deliver or retrieve a byte from the VERA's VRAM address space and the VERA memory map need not be that dissimilar with only the missing 64K being different.  I admit (from the 8BG's description) it would be different for machine code programs but the BASIC interpreter could hide it from the BASIC programmer.  FWIW I have a pending question asking why the access interface should be different for the X8. If it was only because of a performance improvement I think it would be worthwhile to reconcile the X8 and X16 and take the performance hit for the sake of compatibility.

Some thoughts on porting a X16 assembly program to X8.

The time and effort it takes will vary a lot depending on the structure of the program. Especially programs depending on banked RAM will be hard, as it's just not just a different interface, but an important feature that is missing entirely. Taking X16 Edit as an example, you would probably need to replace banked RAM with virtual memory on disk. This would require a complete rewrite of large parts of the program. At present X16 Edit does bank switching in 67 different situations. Virtual memory banks would not be a simple drop in. You would need to find new strategies to avoid unnecessary reading and writing from/to the disk. It think it would be a lot of work, almost easier to start from scratch.

The different VERA interface might be easier to handle. In X16 Edit the VERA_D0 register is read or written in 33 different situations, so porting this to X8 is not trivial.

I do not believe in hiding the differences between X16 and X8 behind API layers. 8 bit computers running at 8 or 12 MHz need all computational power they have if we are to make great programs. Even if there were such an API many assembly programmers would avoid it to gain performance.

If the X16 and X8 are incompatible, the programs written for them will be so too. If both the X8 and the X16 are released, developer time will be divided between the two platforms. 

11 hours ago, The 8-Bit Guy said:

Some people seem confused on why I'm in favor of releasing this.  So I'm going to open up and totally lay it out here.  This is my honest opinion on that matter:  The X16 has taken much longer to bring to market that I thought.  There were many times where development was halted for 6 months or more because of unsolvable bugs.  And even though we are close to being able to release a kit fo the X16, it's going to still take more time to get this out the door and the people wanting fully assembled systems will be waiting extra time. The X16 is definitely happening.  The X8 is not meant as a replacement for it.  But, I felt like the X8 with it's super-low price-tag and easy manufacturing could help keep interest in the project much like "The C64 Mini" did, even though everyone was wanting a full-sized machine. 

First, the "maintain interest" piece. When the CX16p goes to crowd funding, there will be a flurry of interest. There is just a set of people who are not going to follow the development phase of the project until it reaches crowdfunding. And with the work that has already gone into the CX16p, it's going to hit it's "minimum launch target" with ease, which is then either part of the initial flurry of interest or else a second wave of interest, depending on whether it hits in hours, days or a week or two.

There are going to be a number of people who follow and report on things in this space for whom the crowdfund launch will be the trigger for their in depth look at the project ... and then their coverage will attract more interest further afield, and so on. There is no need to worry about "maintaining" interest: there is a substantial latent interest just waiting to be generated with the launch of the crowdfund.

Relative to the project development so far, the project team is being ultra-cautious in its crowdfunding launch ... many projects would have launched already and these multi-month delays for bugs would be with the added pressure of slipping public development point target dates. And being conservative has avoided some public dust-ups over those dates slipping.

But at some point, you need to set a range of months to "get this out the door" and open the crowdfunding phase for the CX16p. One clear scheduling point for that is you guys shouldn't be building a set of boards for wider beta testing without the crowdfunding being open. Profit or not, the labor of building the boards for wider beta testing should be paid for up front by a share of the crowdfunding budget.

This is not advice to "start the crowdfund phase early". Premature launch is launching when you cannot honestly say "the X16 is definitely happening". If it is definitely happening, we are presently in the window when crowdfunding is justified, and the only question is how late into that window will the team wait to do the launch.

But in any event, the team now knows that the CX16p crowdfund launch will happen. So organize around your certainties.

So that makes the questions, should there be an X8 launch, and if so, when? Should there be a CX16c launch, and if so, when? Should there be a CX16e launch, and if so, when?

 

... The X16 is definitely happening.  The X8 is not meant as a replacement for it.  But, I felt like the X8 with it's super-low price-tag and easy manufacturing could help keep interest in the project much like "The C64 Mini" did, even though everyone was wanting a full-sized machine.  This would keep development on-going, and most anything made for the X8 could easily be ported to the X16 later.    I do not believe X8 sales will cannibalize X16p sales.   And sales of the X8 could even help to fund more development on the X16 surface-mount version and eventual X8-FPGA version.  And for those people that don't want an X8, it seems like the solution is simple.  Just don't buy one.  Buy the X16p instead.  Or wait for phase-2, or whatever. 

Seriously, the point of crowdfunding is to let the "crowd" of willing customers help with funding the development of a project starting at some stage in its development. It also gives the most accurate real world indicator of whether to do the development, in terms of whether it hits its minimum funding requirement.

If funds are the bottleneck for development of the CX16c, then open it to crowdfunding to relieve that bottleneck. In any event, we do have one point we can hang the crowdfund timeline on: if the CX16p can go ahead, then so can the CX16c. If the CX16c is done with a CPLD instead of all of that glue logic, then a zero force insertion socket for CPLD the CX16c development board(s) and most discrepancies between CX16p and CX16c operations can be fixed by debugging the CPLD specification and reprogramming it's matrix. And if the discrepancy reveals something that should be fixed in the CX16p, fixing it brings them back into alignment.

The hold up other than the development funding side that crowdfunding can take care of if the developing funding is worth doing at all

You are certainly correct that there will be no cannibalization between LX8 and CX16 sales. If launched side by side, there will be effectively no cannibalization between the "LX8" ("Lieutenant" X8) and the CX16c.

So if going with the LX8, there are the following crowdfund launch plans to consider:

(1) Launch the LX8, CX16p and CX16c sequentially.

(2) Launch the LX8 first and the two CX16's in parallel afterwards.

(3) Launch the LX8 and CX16p first and the CX16c after.

(4) Launch all three simultaneously.

In a sales funded model, there is a strong argument in favor of (1). The LX8 is the simplest to get manufactured, the proof of concept design is already functional, so needs at most a few tweaks to make it ready to ship, and as the mass market priced part of the product line, it has the biggest opportunity for people to purchase it as an impulse buy to occasionally tinker around with.

In a crowdfunded model, there is a strong argument in favor of (4). Simultaneous launch provided the biggest "punch" to the initial rollout. There are no "reasons to wait" on Day 1 ... so the progress toward full funding number that people look at as a short hand for "how good do other people think this is" are going to be as good as possible. The total funding across all three crowdfunded projects in the product line can be aggregated to give the largest possible "we have attracted this much funding" number, which is the other big shorthand for "how interested are other people in this project?"

What are the downsides. A big downside of the first two is that the project will be initially defined in the broader audience that is attracted by the LX8, and the CX16's when they launch will be downgraded for being "only partly compatible" with the LX8. If the LX8 is a runaway hit, that undermines the buzz for the CX16 launch, and if the LX8 is not a runaway hit, that also undermines the CX16 launch. Also, "but it's slower!", which is likely not true in terms of effective operating speed for things where "system speed" really matters ... but is an easy first impression to draw.

The biggest downside of the fourth is the need to make it clear at a glance which project somebody should support who has just heard about the project and has followed the link. "At a glance" is the key here. It needs to be a picture that "conveys" the key distinctions. That is the product line shot ... the LX8 at the far left, with its bare board in front, keyboard plugged into its optional mini case behind. The (render) of the CX16c in the middle left, with the bare board in front, the keyboard and it's cute little mini-ITX case option behind it. And the CX16p at the middle right, with two different third party cases, one with the standard keyboard and one with the fancy switch key keyboard.

Underneath that, the entry points to the individual projects, in order to target delivery date ranges. First is the CX16p DIY (or, if I were to attempt it, "DYI" for "do yourself in"). Second the LX8. Third, the CX16p pre-built. Fourth, the CX16c.

One thing about a simultaneous launch and the downsides of showing the whole product line at once is that the complexity of choices within the individual projects should be kept down, to make them easier to summarize. So go ahead and populate the CX16p SRAM. It can then be labelled as the "64K system address space, 2MB extended RAM, 512KB system flashROM, 128K Video Memory Space" option. With surface mount and a CPLD for chip select, it should be possible to "carve out" Low RAM from the highest 40K of the High RAM chip, so if available a single 55ns 1MB surface mount SRAM could be the sole RAM chip to reduce parts count. That is "64K system address space, 1MB system RAM, 512K system flashROM, 128K Video Memory Space". And of course the LX8 is the "64K system address space, 64K system RAM, ??K system flash ROM, 64K Video Memory Space".

Obviously, those are just notional CX16c design decisions ... so long as the product description starts with, "Real 8bit 65C02 CPU / Real 8bit 65C22 VIA support chips / 100% Compatible with the CX16p applications / ...", a range of specific design decisions can be made within that framing.

But in the CX16p funding page, you can pick between a DIY tier with a minimum funding requirement and a prebuilt tier with a specific closed amount to be funded, an option to add the expensive custom keyboard to the standard keyboard, and that's it. The only difference between the two CX16p entry points from the main entry page is where on the crowdfunding page you land.

In the CX16c funding page, you can pick between the bare board version and the cased version, with a minimum funding requirement for each to launch, an option to add the expensive custom keyboard, and that's it.

In the LX8 funding page, you can pick between a bare board with keyboard and a mini-cased version with keyboard and power supply. The mini case is designed to "mini" style resemble the CX16c case.

Just do the bare board and parts with kb. Plenty of making videos on your site.

Most of my board pcs I have do not have a case and infact that makes it a cheaper purchase. As its big I may buy a sheet of plexiglass to mount it or you could offer that?

11 minutes ago, Stefan said:

Some thoughts on porting a X16 assembly program to X8.



The time and effort it takes will vary a lot depending on the structure of the program. Especially programs depending on banked RAM will be hard, as it's just not just a different interface, but an important feature that is missing entirely. Taking X16 Edit as an example, you would probably need to replace banked RAM with virtual memory on disk. This would require a complete rewrite of large parts of the program. At present X16 Edit does bank switching in 67 different situations. Virtual memory banks would not be a simple drop in. You would need to find new strategies to avoid unnecessary reading and writing from/to the disk. It think it would be a lot of work, almost easier to start from scratch.



The different VERA interface might be easier to handle. In X16 Edit the VERA_D0 register is read or written in 33 different situations, so porting this to X8 is not trivial.



I do not believe in hiding the differences between X16 and X8 behind API layers. 8 bit computers running at 8 or 12 MHz need all computational power they have if we are to make great programs. Even if there were such an API many assembly programmers would avoid it to gain performance.



If the X16 and X8 are incompatible, the programs written for them will be so too. If both the X8 and the X16 are released, developer time will be divided between the two platforms. 

That is why I said i'll never release anything for the X8.

I don't mean i'll never touch a X8, I'm buying one and will use it and even enjoy using it. Just for the sake of preserving the X16 softwarebase, I'll only use it as a toy for BASIC, and patiently wait for the real machine to show up.

__________

Some posts made good points that eventually people would gain more interest in the X8 due to its advantages and it's something that i'm still afraid about. Please at least make it as slow as the X16. It's all I ask for this machine.

By the way, my wallet is ready ? I started saving since the start of this project so I got a bit of money dedicated to it

1 hour ago, Stefan said:

Some thoughts on porting a X16 assembly program to X8.



The time and effort it takes will vary a lot depending on the structure of the program. Especially programs depending on banked RAM will be hard, as it's just not just a different interface, but an important feature that is missing entirely. Taking X16 Edit as an example, you would probably need to replace banked RAM with virtual memory on disk. This would require a complete rewrite of large parts of the program. At present X16 Edit does bank switching in 67 different situations. Virtual memory banks would not be a simple drop in. You would need to find new strategies to avoid unnecessary reading and writing from/to the disk. It think it would be a lot of work, almost easier to start from scratch. ...

My thoughts on virtual memory on disk:

(1) Those programs that make full use of the Bank RAM as an internal data store will often not be organized in a way that allows a cross platform API to be a functional equivalent to the bespoke API representing their functions that use the Banks.

(2) At the same time, there is a simple API that supports cross-platform programming that could actually be included as Kernel calls. It does not "hide" the difference, it just allows whichever system it is running on to do the best it can do to offer access to the extended data.

This abandons the idea of a bitmap of allocated banks, and organizes user available High RAM into two sets: User High RAM and User Buffers.

"BANKSFREE". It is not used by the system, it is not used by the allocated RAM / pseudo-RAM below. It is actual RAM. If no pseudo-RAM is set up, it is the first available User bank in A and the number of available User banks in X.

"BUFFTOP". BUFFTOP resets the buffer allocation done below. It sets the bank number for the banks used as individual 8K buffers. This can be any number up to 255 for bank (0 base) 255. On a CX16 without 256 Banks (less than 2MB Extended RAM), as might be the case if the CX16c has a single smaller surface mount SRAM chip, and on the LX8, if the BUFFTOP is above the largest actually available RAM bank (eg, possibly 122 for the CX16c, 2 for the LX8), then one actual RAM bank is set aside for buffer use. Therefore, after it is executed, "BANKSFREE" may return a number of available banks one smaller. On the LX8, this make Bank 1 the User Bank and Bank 2 the Buffer Bank. On the notional 1MB total RAM CX16c, 122 would be the Buffer Bank if the BUFFTOP is set above 122.

If BUFFTOP is set to 0, the BUFFTOP is set to the actual last RAM Bank. This can be used to either "turn off" the buffers to make the maximum number of user banks free, or to use buffers but ensure that no pseudo RAM is used.

"BUFFALLOT". The three transient data points the system needs is whether a Buffer Bank is being used, the byte representing the "fence" between the free User Banks and Bank Buffers, and a current buffer value. If carry is clear, "BUFFALLOT" allocates one buffer by reducing the fence by one, saves the newly allocated buffer number as the current buffer value and returns it in A. If carry is set, the fence is not adjusted. After it is executed, the value returned by BANKSFREE may be reduced by one.

"BUFFLOAD". This sets the bank to the indicated buffer, which should be equal or greater than the buffer allotment fence. The current buffer bank is returned, and the indicated buffer bank is saved.

1. 
   If carry is set, the current window contents are treated as the original current buffer value. If the buffer number is not an actual RAM Bank, it is saved in a system file with a name that contains its buffer number.
   


2. 
   The requested buffer number in A is stored as the current buffer, and the previous current buffer number is returned in A.
   


3. 
   If the requested buffer number is an actual RAM Bank, it is stored in the BANK register at $0000.
   


4. 
   If the requested buffer number is pseudo RAM, the buffer bank is stored in the BANK register at $0000. If a buffer file with that buffer number exists, it is loaded into the HighRAM window.
   

_____________

Yeah, the biggest selling point of the C8, aside from the USB ports and "it's here now" is the faster clock. 

I'm thinking being under $50 rather than over $200 is the biggest selling point.