Commander X16

On 10/17/2021 at 4:52 AM, paulscottrobson said:

They're very similar. In some ways the X8 is actually better.



The shortfall in the X8 is RAM memory (and expandability, but that doesn't affect software so much).  I'd say it was likely that a machine with the X8 level of specification would load code and graphics off Smartcard rather than holding it in SRAM, would probably not use much in the way of direct sound (though this is an X16 issue as well) and would be more likely to use 4 bit colour rather than 8 bit colour and/or have a lower resolution.



It's backwards to the Plus4/16 issue really, they had identical hardware but much less program RAM. The X16 has more banked storage, but both systems have the same basic memory space.

Though if you program in assembly, you can usefully use the "banked storage" as program RAM, and there's so much of it, that in assembly there is also the Plus4/16 issue.

On 10/17/2021 at 1:58 PM, BruceMcF said:

Though if you program in assembly, you can usefully use the "banked storage" as program RAM, and there's so much of it, that in assembly there is also the Plus4/16 issue.

I'm not convinced people are going to write enormous programs at all, let alone in assembler. Though it may be more useful in FORTH.

On 10/17/2021 at 9:45 AM, paulscottrobson said:

I'm not convinced people are going to write enormous programs at all, let alone in assembler. Though it may be more useful in FORTH.

I rather expect that people are going to write toolkits that can be loaded into HighRAM, and assembly language programs using HighRAM will be using those. The "Golden RAM traffic jam" that the C64 experienced is not an issue if a toolkit is tucked into a HighRAM page.

On 10/17/2021 at 2:45 PM, paulscottrobson said:

I'm not convinced people are going to write enormous programs at all, let alone in assembler. 

It's what I'm doing.

On 10/17/2021 at 7:45 AM, paulscottrobson said:

I'm not convinced people are going to write enormous programs at all, let alone in assembler. Though it may be more useful in FORTH.

Asteroid Commander is up to 11kb of assembly language code and about 400kb of lookup tables, so far. 

On 10/16/2021 at 7:55 PM, Sisko said:

but out of all curiosity around what people think will happen with the x8 gets released (that all program development will focus on the lowest capable device), but is that not a concern with each phase of the base x16, Or is there such a leap in specs that I don't understand?

For the games I've released so far (Brixx and Invaderz) for the X16 I would see the following impacts if I had limited them to the X8 specs:

• 
  No music soundtracks. I use Deflemask to compose and to export VGM and then convert this to a similar condensed format. Without the YM2151 I would have to use a different tracker - which doesn't exist - at least not one usable on a PC. Also my friend who is the composer of the soundtracks won't use anything different than the Deflemask.
  


• 
  Graphics need to be nerfed down to 16 colors instead of 256 for the title screens and background graphics (Invaderz). Which maybe would be ok for Brixx, but:
  


• 
  for Invaderz that would mean that the background needs to share it's 16 colors with the sprites as well. That might leave around 4 colors for background, 4 colors for player sprite, 4 colors for enemies and 3 colors for explosions/phasers etc. (1 color is the black background color). It won't look nice. Actually I'd rather remove the scenic background images then.
  


• 
  Probably less levels in both Brixx and Invaderz. At least there won't be more - which I had planned. The same for my jump & run platformer I had in development (halted atm).
  

Bottom line for me is like this: Had the X16 specs been the X8 spec right from the beginning, the platform would have been less interesting for me and I would not develop for it now.

Comparing the different X16 variants the X16e (FPGA) would only offer 512K of RAM and cannot be expanded (the others can). That's a limitation, yes - but it would be plenty of RAM for what is meaningful to do in most cases. Everything else is identical, software will run on all variants.

Making the X8 mostly compatible with the X16 (VERA adressing, memor map, I/O adresses, ROM etc.) would leave it as a X16e with less RAM and VRAM... I'd suggest to just go for the X16e (FPGA) directly, to get some cash in. I'd buy one - and the kit version as well.

@AndyMt Perhaps when using an X8 that is limited to 512K of banked "high ram" as it's ONLY functional difference from a full sized X16, the programmer could use a routine that loads data from disk as it's needed rather than all at once in the beginning. Taking this approach would allow the vast majority of software to run on either a 512K or a full 2MB system. There might not even be a noticeable difference for the end user, given the speed of SD card storage.

Obviously I know this data management paradigm isn't new and it wouldn't be compatible with every manner in which one might organize a program. However, if not using banked ram in chaotic ways was made a standard "best practice" by the community, I think the concept would work out well.

I agree that having significant differences between the specific capabilities of the two machines would suck. You've listed some excellent examples that demonstrate the downsides for all involved, programmers, creators, and end users alike.

I'm of the mind that the X8 vs. X16 should be like the difference between a stock VIC20 and a VIC20 with a 3.5K memory expansion cartridge - same device, but with more RAM for more better bigs!! Going the C64 vs. Plus/4 route would not be worth doing, because it would just be a pain for everyone.

On 10/18/2021 at 10:51 AM, Tatwi said:

Perhaps when using an X8 that is limited to 512K of banked "high ram" as it's ONLY functional difference from a full sized X16, the programmer could use a routine that loads data from disk as it's needed rather than all at once in the beginning.

This won't work for music, the single sound tracks are too big, which would not leave enough room for the actual game and loading them in chunks would be very challenging without interrupting audio.

On 10/18/2021 at 9:57 AM, AndyMt said:

• 
  Graphics need to be nerfed down to 16 colors instead of 256 for the title screens and background graphics (Invaderz). Which maybe would be ok for Brixx, but:
  


• 
  for Invaderz that would mean that the background needs to share it's 16 colors with the sprites as well. That might leave around 4 colors for background, 4 colors for player sprite, 4 colors for enemies and 3 colors for explosions/phasers etc. (1 color is the black background color). It won't look nice. Actually I'd rather remove the scenic background images then.
  

You do realize that each tile instance (in tile mode, not character mode) and each sprite has a 4-bit palette offset field which allows you to use practically the entire 256-color palette? I don't think that would be any different on an X8.

On 10/18/2021 at 1:49 PM, Guybrush said:

You do realize that each tile instance (in tile mode, not character mode) and each sprite has a 4-bit palette offset field which allows you to use practically the entire 256-color palette?

That's what I actually do in Brixx, where I use tile mode. In Invaderz I use bitmap mode. But you are right - there I could also use the palette offsets (bitmap and sprites) which would mitigate the issue. So the background images could be in 16 colours, which would probably be fine - and the sprites in 16 colours, too ?.