Commander X16

1 hour ago, paulscottrobson said:

I don't know if you ever actually worked with the original MS Source. I have, and the Kernal. It's not the easiest thing to work with, and it's not very readable, or well engineered. I reckon the amount of additional work that goes into BASIC/Kernel fixes because of that already outweighs the benefits of having prewritten code. Much of the Kernal is rewritten anyway I think. Michael Steil probably knows those to sources better than anyone else alive including the original authors.



I think there's the programming skills here to produce something much better. The problem would be coordinating it so we don't end up with 12 different BASICs but one written by 12 people where different bits (evaluator, variables, string handling, structures, tokenising/detokenising etc.) could be done by different people. You could even make it MS compatible (though personally I'd chuck the Taylor series, or at best make them a loadable extension !)



And then there's the education problem. Some can see a use for this in schools. As it is now, I can't, because of the programming language that's built in.

I'd like to experiment making a BASIC interpreter, this would lead to an interesting challenge. As for compatibility, it's also possible to write a converter and store it into one of the ROM banks. If more people are interested we can start a thread dedicated to this.

6 hours ago, BruceMcF said:

In addition to the below, note that much of your wishful thinking was the generation 1 board that they scrapped for being too complicated. So that is not Dave's dream computer project, but rather some other project ... specifically, for your wishlist, the Feonix256.



Remember that the FPGA is not because they wanted it, but because ...



Also, from a software perspective, 12MHz, 64K total general purpose system RAM and 64K RAM divided between video output and data storage is only going to be faster than 8MHz, 40K general purpose system RAM, 512KB-2MB extended RAM, 512K ROM, 128KB video RAM  for applications that fit the limited RAM. .. When you drop from using that internal RAM to using files on an SD card, your effective speed takes a much much bigger hit than the X16, which at a similar point pays a much smaller speed penalty to play extended RAM juggling games.



But mostly, keep in mind that "USB" is not "a general purpose USB stack". There is no reason to assume the hardware supports more than USB 1.0, which would be adequate for the keyboard + joystick support...



Indeed, switching from the X16 register access with two auto-incrementing memory ports with associated accumulator/adders to a simple page bank register may be freeing up some of the logic resources used for the 6502 core.



I'm looking at the X8 as a happy accident. I still want an X16c on my desk, but I'd only want an X16e if I couldn't afford an X16c when the crowdfund launches.



If the X8 can get an opportunity for an expansion option, I'd want one of them too.

Thank you very much, Bruce!!!

I always read your comments and especially your replays with a pleasure - right on point, there is no bla-bla, logical exposition supported by examples!!!

I wonder if the spec of the X8 (before all the scope creep, supply chain realities and development challenges of the X16) was pitched in 2019, whether people would be complaining about the percieved spec compromises vs the x16. The stated X8 spec (other than a lack of expansion connectivitiy) seems to be right on the money for anyone interested in a more modern, better documented and less quirky implementation of the capabilities and compromises inherent to the the golden ages of development in the 8 bit era.



Also - I often wonder if Dave would have been better off all along reversing the original development and rollout plan, i.e. by starting with the launch of a cheap, easy to produce FPGA based core product with enough capability to encourage community buzz, tooling development and initial games built on the the core VERA and 65C02 functionality (and the added benefit of being able to correct or append any glaring logical hardware or Kernel code issues easily after devices were in the wild), and then offering the physical version (with a real 65C02, RAM etc) for those who wanted to tinker with hardware hacking and expandability afterward once the big bugs had been ironed out on the FPGA based devices.



Does anyone really expect that they'll make a living out of selling X16 software? If not, and if the goal is to develop software for personal enjoyment / use, why does it matter if a proportion of the community can't your code on their "base" 128k devices? If the goal is to sell software, the X8/16 don't seem like the smartest platforms to target, and for anyone who is interested enough in what you're doing, the cost and hassle of a full fat X16 kit shouldnt be a blocker right? 

1 hour ago, Wonderdog said:

wonder if the spec of the X8 (before all the scope creep, supply chain realities and development challenges of the X16) was pitched in 2019, whether people would be complaining about the percieved spec compromises vs the x16

That's a valid point. I personally would have been perfectly fine with the X8 specs in the first place. My issue with it is the incompatible memory layout and access to VERA compared to the X16. If the X8 could be made 1:1 compatible in regards to memory layout and VERA access - I would be tempted.

1 hour ago, Wonderdog said:

Also - I often wonder if Dave would have been better off all along reversing the original development and rollout plan, i.e. by starting with the launch of a cheap, easy to produce FPGA based core product with enough capability to encourage community buzz

That's a very valid point, too... Maybe going for phase 3 directly would be the best option. I mean the emulator already achieved some if this effect, but didn't result in a cash injection.

1 minute ago, AndyMt said:

That's a very valid point, too... Maybe going for phase 3 directly would be the best option. I mean the emulator already achieved some if this effect, but didn't result in a cash injection.

Exactly. Low risk, predictable margin device to get Commander hardware of some form in peoples hands to raise awareness, confidence, start tooling development/refinement and of course, raise funds for further development of the more niche / fancy fully custom product. 

51 minutes ago, AndyMt said:

Maybe going for phase 3 directly would be the best option. I mean the emulator already achieved some if this effect, but didn't result in a cash injection.

I made that very point in another thread. I suspect the main hesitancy along this line is the fact that there's a major design decision in flux right now regarding the PS/2 interface. Personally, as long as the board is flashable without special hardware/cables, then I don't see any reason why it couldn't get "firmware updates" to go along with emulator updates. Anyway, I also suspect that the particulars of the "phase 3" design aren't as close to being done as the X8 which is probably why Dave's leaning towards releasing the X8.

2 hours ago, Wonderdog said:

I wonder if the spec of the X8 (before all the scope creep, supply chain realities and development challenges of the X16) was pitched in 2019, whether people would be complaining about the percieved spec compromises vs the x16. The stated X8 spec (other than a lack of expansion connectivitiy) seems to be right on the money for anyone interested in a more modern, better documented and less quirky implementation of the capabilities and compromises inherent to the the golden ages of development in the 8 bit era.



Also - I often wonder if Dave would have been better off all along reversing the original development and rollout plan, i.e. by starting with the launch of a cheap, easy to produce FPGA based core product with enough capability to encourage community buzz, tooling development and initial games built on the the core VERA and 65C02 functionality (and the added benefit of being able to correct or append any glaring logical hardware or Kernel code issues easily after devices were in the wild), and then offering the physical version (with a real 65C02, RAM etc) for those who wanted to tinker with hardware hacking and expandability afterward once the big bugs had been ironed out on the FPGA based devices. ...

Though the thing is, hindsight tends to be sharper than foresight (maybe that's why in Chinese, "the past" is what you see when you look ahead and "the future" is what you see when you look behind you) ... made with off the shelf ASIC parts seemed to be a compelling part of the vision for a lot of the people David was talking to, and there is no doubt that starting with Yet Another FPGA simulator, and this one for a retro system that did not, in fact, exist, would have been the path that made the real chips version of the board less likely to happen than the path that has been traveled.

Perhaps the experience, such as it was, would have been smoother, but it would have been smoother because of the different hardware constraints, and the various hangups that have been experienced getting the X16p to the "almost ready to crowdfund" point it is at now would have been even harder to fix if all of the software base was assuming something that turned out to be easier to implement in FPGA than with discrete chips.

The path has been harder largely because they tackled the harder challenge first.

Once they have all the kinks worked out, the only real hangups for the X16c and X16e would be market questions ... would there be enough demand to justify a cased X16c ... would there be enough market demand for an X16e when it is above RPi price points and up in the next tier of SBC's.

The smoother ride to doing the X16e first would likely also have meant an even bumpier ride to getting an X16p done, and it's all too likely that they would have ended up painting themselves into a corner, simulating a discrete chips 65c02 based SBC that they couldn't then actually make to work.

 

1 hour ago, Wonderdog said:

Exactly. Low risk, predictable margin device to get Commander hardware of some form in peoples hands to raise awareness, confidence, start tooling development/refinement and of course, raise funds for further development of the more niche / fancy fully custom product. 

All of this "raise funds for further development" keeps confusing me. Why do people forget that crowdfunding exists? Crowdfunding raises funds for the product you are trying to build with the fact that there are people out there who want you to build it so they can buy it.

I made that very point in another thread. I suspect the main hesitancy along this line is the fact that there's a major design decision in flux right now regarding the PS/2 interface. Personally, as long as the board is flashable without special hardware/cables, then I don't see any reason why it couldn't get "firmware updates" to go along with emulator updates. Anyway, I also suspect that the particulars of the "phase 3" design aren't as close to being done as the X8 which is probably why Dave's leaning towards releasing the X8.

Setting aside my whinging about wanting an X8 that doesn't exist ... one with more I/O options than just working out how to reuse the debug UART port as a regular UART port ... when David says he has a prototype and it just works, I think that means that there's no software challenge, just open the crowdfund to fund production of the board and it would be prototype the version on the finished board rather than the development board, test that it works as expected, fix any mistakes (never assume there are no mistakes to fix just because there "shouldn't" be), then put them into production.

IOW, the alpha prototype worked out like it was the beta test.

Meanwhile, while the X16p DIY may be a month or two away from being ready to crowdfund even for a very conservative approach to crowdfunding ... there's been various times already when a month or two has ballooned to six months, and there's perhaps some well justified nervousness about when the X16 side is going to turn cash-flow positive.

 

12 hours ago, BruceMcF said:

 



(1) If what you meant by "app store" was not, in fact, what is widely understood by "app store" ... you open up an app on the device, it takes you to a site on the internet where you browse from available apps, and then install the one(s) you decide you want ... and you were instead talking about a paid application section of the current free download section of this site, it probably would have been better to call it something other than an "app store". Then the inevitable criticism of the idea would have been criticizing your actual idea rather than criticizing the idea that your original phrasing clearly implied.



(2) On the other hand, there's no guarantee that it would not be misinterpreted. For example, look how you took the level of success I called "a nice little hobbyist system" and blatantly misrepresented it as my saying that would be a "rousing success", when I did not even label that next step up as a "rousing" success. This is the internet. Sometimes what you say will get misinterpreted.

Yikes. Chill out dude. This isn't the academy. I am pecking these out on my phone between meetings and diaper changes. Go make some tea and leave me alone.

13 minutes ago, snerd said:

Yikes. Chill out dude. This isn't the academy. I am pecking these out on my phone between meetings and diaper changes. Go make some tea and leave me alone.

No flames intended ... I was just using your misrepresentation of what I said to underline that the way you described adding a paid option to the store was easy to misinterpret.

Of course, in China I am now officially an old man, so it's easier to be chill about such things ... I remember days on the early 90s Usenet that might have been the start of a four month flamewar.

21 hours ago, Carl Gundel said:

I can see this as a super cheap way to add Internet connectivity, to support software for simple BBS style communities, or even simple FTP and HTTP type features.  I made a suggestion some time back for this kind of thing, but people seemed mostly uninterested.

If it was a suggestion for an ESP32 expansion slot card or User Port card, it seems clear on Facebook and here over time that there is a substantial amount of interest in that.

(Now, present it as something to be built in, and people might get a bit intent on shooting that suggestion down because they don't want to add anything to the base design to slow development down further, or because they think it's not appropriate to include in the base design, or both.)

But even for the X8, without a slot, without a user port ... since it has SPI input and output lines and clock, and SPI can be bussed, one I/O pin and an ESP32 hat is possible.

(... send that I/O pin and the existing SD select out for decoding, 2>4, reserve one for SD, and with the other three you can have a multi-I/O hat on the external SPI bus ... just saying ...)