Jump to content

Change of product direction, good and bad news!


What should we do?  

371 members have voted

  1. 1. Should we release the Commander X8?

    • Yes, it should replace Phase-3. It's good enough.
    • Yes, but you should still offer a Phase-3 Commander X16 eventually too.
    • No, don't release the X8, stick with the original plan.
  2. 2. Should we still make a Phase-2 product?

    • Yes, Phase-2 is what I want
    • No, skip and go straight to Phase-3
  3. 3. For the X16 Phase-1, do you prefer a kit or a somewhat more expensive pre-assembled board?



Recommended Posts

4 hours ago, The 8-Bit Guy said:

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.  

 

If you decide to go ahead with the X8, will you open a section to register intention to buy so that we can put our tentative orders in?  I expect it to be very popular.

Link to comment
Share on other sites

Goood evening

first of all I would ask : if a commander X8 has been somewhat ready for some months , how are we far from having the fully compatible X16e ready?

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 but i'm in favor of showing the 16 kb of low ram, which will be hidden by ROM, as 2 8 kb banks so people starts to use this feature.

for what concerns the Commander X16 I would make the phase 2 version the main one because I don't think anyone will ever abandon the project because of SMD components while this could happen with an FPGA based system.

 

Link to comment
Share on other sites

1 hour ago, Fabio said:

Goood evening

first of all I would ask : if a commander X8 has been somewhat ready for some months , how are we far from having the fully compatible X16e ready?

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 but i'm in favor of showing the 16 kb of low ram, which will be hidden by ROM, as 2 8 kb banks so people starts to use this feature.

for what concerns the Commander X16 I would make the phase 2 version the main one because I don't think anyone will ever abandon the project because of SMD components while this could happen with an FPGA based system.

 

It does seem like a funny idea to decrease the frequency, or to decrease anything else, but I think it makes sense.

On the other hand, it's okay if the video or audio hardware is slightly different I think.  Look at the PC games market as an example.  Most games in the 80s and 90s supported multiple audio and video standards.  Some of 8BG's games also do this, so why can't developers be encouraged to write games that work on both machines?  After all we do have access to an X16 emulator, so even if the X16 isn't available when the X8 is, there's no reason why software can't theoretically be developed for both, and published for both?

Link to comment
Share on other sites

2 minutes ago, Carl Gundel said:

It does seem like a funny idea to decrease the frequency, or to decrease anything else, but I think it makes sense.

On the other hand, it's okay if the video or audio hardware is slightly different I think.  Look at the PC games market as an example.  Most games in the 80s and 90s supported multiple audio and video standards.  Some of 8BG's games also do this, so why can't developers be encouraged to write games that work on both machines?  After all we do have access to an X16 emulator, so even if the X16 isn't available when the X8 is, there's no reason why software can't theoretically be developed for both, and published for both?

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

On the RAM thing... I actually am starting to think the banked RAM on the Commander won't be used that much. SD is fast enough that it's simpler and just as fast to load game levels from disk. And with no BASIC support for banking or complex data structures, there's little to no use for banked memory in BASIC, anyway. 

So as a BASIC computer, the C8 is actually a better machine. As a machine language or C computer, the X16 has some benefits... but I'm starting to think those benefits aren't as worthwhile as folks think. The real advantage of the X16 is the expansion and User ports, not so much the expanded RAM.

 

  • Like 2
Link to comment
Share on other sites

3 minutes ago, Carl Gundel said:

Most games in the 80s and 90s supported multiple audio and video standards.  Some of 8BG's games also do this, so why can't developers be encouraged to write games that work on both machines? 

The PC market was also always much more heavily fragmented than the X16 would ever be. If the X16 were more of an open, customizable platform, with install bases in the tens of thousands or hundreds of thousands, but with multiple competing standards on many subsystems and components, then X16 developers would be incentivized to write software with multiple hardware configurations in mind.

But there will be one X16, and maybe the X8. And the install base will be in the hundreds, maybe (maybe!) the thousands. This is much less incentive for wide support, especially if folks write software to be released for free, as opposed to software they intend to sell. Or, to the extend that wide support is encouraged, it will be by developing to the minimum spec shared between the two machines.

Link to comment
Share on other sites

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…

Edited by Brad
Link to comment
Share on other sites

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.)

  • Like 3
Link to comment
Share on other sites

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.

 

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Edited by BruceMcF
Link to comment
Share on other sites

7 hours ago, Carl Gundel said:

Some of 8BG's games also do this, so why can't developers be encouraged to write games that work on both machines?  After all we do have access to an X16 emulator, so even if the X16 isn't available when the X8 is, there's no reason why software can't theoretically be developed for both, and published for both?

For sure this is possible, but - it takes away time from my budget to actually develop something. I would certainly only develop for one of the 2 platforms and not go into the hassle to do ports. I'd probably also wait until there is a clear indication of which platform "wins". Maybe I'll then not develop for any of the 2 at all because my focus moved somewhere else.

7 hours ago, StephenHorn said:

But there will be one X16, and maybe the X8. And the install base will be in the hundreds, maybe (maybe!) the thousands. This is much less incentive for wide support, especially if folks write software to be released for free, as opposed to software they intend to sell. Or, to the extend that wide support is encouraged, it will be by developing to the minimum spec shared between the two machines.

I fully agree. Let's assume the X8 gets the same VERA interface as the X16 and is tuned down to 8MHz. I'd probably just develop to the minimum specs. For the 2 games I've released so far I pushed the X16 as far as I could. I've used almost all the VRAM (256 color bitmap graphics, lots of 256 color sprites) and also plenty of banked RAM (for music and sound). My platform jump & run game in the works goes even further: sound track running in parallel, 256 color palette switching to show up to 512 colors at once, partial palette shifting to achieve "water flow" effects etc. I'm not sure what I'll do with it now - probably just wait and see what happens.

1 hour ago, Stefan said:

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. 

Here I also agree. If the VERA interface is different, then the software will be incompatible. Or the effort to make it compatible will take away performance, which could be too much.

Link to comment
Share on other sites

1 hour ago, Stefan said:

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.

One of the reasons I love the BBC Micro is that it _does_ hide many things behind API layers. It was one of the only computers of the era with a fully featured operating system with lots of API calls. That's what allowed things like running software on an external second processor with minimal modification.

Not necessarily commenting on whether the same tradeoff would make sense here, but it's an interesting system to look at if you want to see how such an OS could work in the 8 bit era.

  • Like 1
Link to comment
Share on other sites

20 minutes ago, zapposh said:

commander_x8.png.dc5cf5cf80df6d80f4c7cd977ca7a2ff.png

It's not possible with the X8's VERA implementation, we got a 256 bytes window that is just impossible (or too expensive) to do on real hardware for the X16 😕

Edited by VincentF
Link to comment
Share on other sites

My first choice:
The Phase-2 X16 with FM chip in a mini-itx format. Preferably a complete system assembly with the keyboard included.

My Second choice:
The Phase-2 X16 with FM chip in a mini-itx format, bundled with some stickers and IO shield, so that I could install it in any SFF-case of choice. Keyboard included.

About the X8. I would buy it too. And add free open source case design for 3D-printing, that users can download. It’s a perfect product for those who want a base model.

As for Phase 1, it seems it might be expensive and demand a ton of work. It would only make sense to make it DIY kit, because this product really appeal to people who would like to tinker with it anyways. A bundle of parts, case and keyboard seems like a great idea.

 

Link to comment
Share on other sites

1 hour ago, VincentF said:

It's not possible with the X8's VERA implementation, we got a 256 bytes window that is just impossible (or too expensive) to do on real hardware for the X16 😕

Masking out a single page at a fixed address for the I/O page is bad enough ... having a "roving" page to access the Vera not be practicable. There's only so many layers of chip select logic they can have and still work with the through-pin, 55ns SRAM that they have available.

Link to comment
Share on other sites

If doing code for both X16 and X8, I would for performance reasons first look into creating a set of macros rather than using a common API.

As to bank switching, such a macro could on the X16 just select the RAM bank.

On the X8 that macro could load a virtual memory file (for instance numbered 0-255) into memory area $a000-$bfff. However, first the current content of $a000-$bfff need to be saved to its virtual memory file.

Maybe similar solutions are available for VERA access. I haven't given that much thought yet.

  • Like 2
Link to comment
Share on other sites

When I first read this post and its comments, it was still all only on one page. As of right now when I'm starting to type this response, there are 10 pages. Whew.

But since we're all offering our opinions, even people who have only been lurking up till now, I think that there should be a Phase 1 with discrete through-hole components and the same number of expansion slots as there already are on the Proto 3 board and it should come exclusively as a kit with a keyboard but without a case. It's MicroATX, there are a bajillion cases out there. You could even go buy the original version of the case that @Perifractic modified. Just, you know, independently.

I think that there should be a Phase 2 that also offers expansion slots but fewer of them, perhaps 3, with a cost-reduced motherboard, maybe in a mini-ITX form factor. Integrate as much as you can, reduce chip count, etc., and use the lessons learned from that and from the X8 as the jumping-off point for the Phase 3. Sell it fully assembled with both keyboard and case.

The Phase 3 will be the 'laptop' version. No one expects to be able to stick a full-sized expansion card in a laptop. Any expansions will have to come through the VIA port. Did I mention that I am hoping all of the phases will still have a VIA port? Yeah. Wimodems and printers and other odds and ends make retro systems more fun for people who are new to the retro scene to use in the modern era. It should also be sold fully assembled and with a keyboard and case, or a keyboard that is also a case, a la the RP400.

Every X16 should have 2MB RAM as standard. Three versions of the product are enough; no point in complicating things by having different RAM specs on top of that.

Regarding the X8: Less capable (less RAM, less VRAM, no FM chip [please keep the FM chip on the X16]), less compatible (changes in VERA addressing, ports), less retro (USB ports instead of PS/2 and SNES)... but ready RIGHT NOW. Sell it, ASAP, at a profit, and reinvest those profits into X16 development.

Also, the X8 is probably going to be subject to the actual Osborne Effect rather than the reverse. As the X16, and in particular the Phase 3, comes nearer to fruition, the X8 will likely go the way of the dodo. Given that, and its potentially low price even with the profit factored in, meaning that it won't deplete people's bank accounts, and its existence shouldn't cannibalize the X16's sales too much. I've bought multiple Raspberry Pi versions, at least one of every generation, simply because they're so inexpensive, even though I rarely do anything with them.

And the VERA addressing might not even be that much of a hurdle to compatibility. If the 256-byte window of shared RAM happened to default to starting at $9F00, wouldn't that make it possible for the same first few bytes to be accessed the same way as shared RAM as they would as I/O space on the X16?

Last but not least: Those of you who have said that they would rather donate directly rather than buy an X8, great! You don't have to wait for the product to be available for sale nor for David to set up a specific donation infrastructure; you can donate right now, to his Patreon! I did! Here's the URL: https://patreon.com/8bitguy1

Link to comment
Share on other sites

After a cooldown of a few days, I have changed my mind.
My initial response was no/no/DYI, driven from emotion primarily. 

I have built my own 6502 board from scratch. In fact, two versions of it.
While developing software, guess how many times it was actually interesting that it runs on discrete ICs. Not many. After implementing an XModem bootloader, I didn't even have to touch the EEPROM at all. Finally.

I did however quickly felt limited by the I/O options that I built in. It has a PS/2 keyboard and serial I/O, but video is still lacking. Then I got engaged with the X16 and built software for the emulator. My 6502 boards haven't been powered on for some time now.

In retrospect, even without knowing all the details from the X8, when this would have been the first option presented to me a year ago, branded as X16, I would have been sold.

Sure, bank switching, I/O slots and a dedicated sound-chip are interesting future options. But given the power of the VERA, I'm not really interested.

So please, deliver the X8 as the first option (with the cool keyboard 😉 ). I'll rewrite my sokoban clone when I have access to the emulator. Indeed doesn't sound like much work.

  • Like 2
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Please review our Terms of Use