Jump to content

Possible idea surrounding x16 and x8 discussion


Sisko
 Share

Recommended Posts

I know this is complicated and I'm nowhere near the expertise, 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?

Please know this is more of a topic of discussion, and maybe a way for me to learn more about the technical side of these computers while throwing a bone of a idea from my head.

Edited by Sisko
Link to comment
Share on other sites

  • Sisko changed the title to Possible idea surrounding x16 and x8 discussion
On 10/16/2021 at 1:55 PM, Sisko said:

I know this is complicated and I'm nowhere near the expertise, 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?

Please know this is more of a topic of discussion, and maybe a way for me to learn more about the technical side of these computers while throwing a bone of a idea from my head.

All we know right now is that the X8 in its original form will not be released. Whether there will be a release in the X8 style that is more compatible with the X16, whether that would be before, alongside or after the first of the X16 boards released ... we simply do not know and any guesses would be speculation.

Link to comment
Share on other sites

On 10/15/2021 at 3:03 PM, Scott Robison said:

 

 

On 10/16/2021 at 3:57 PM, BruceMcF said:

All we know right now is that the X8 in its original form will not be released. Whether there will be a release in the X8 style that is more compatible with the X16, whether that would be before, alongside or after the first of the X16 boards released ... we simply do not know and any guesses would be speculation.

I understand, I was just thinking about the post they made and one of the concerns that they raised, I just had a thought and wanted to put the thought out there.

Link to comment
Share on other sites

The phases in particular were:

  1. the mostly DIP chips including all of the glue logic chips as "phase 1", aka X16p (informally, "pro").
  2. the cost reduced version of the X16p, surface mount chips where available, possibly a single SRAM, only one or two slots, maybe with a CPLD replacing the glue logic if it brings enough cost reduction, as "phase 2", aka X16c (informally "compact", even more informally, "cost reduced")
  3. the version that brings as much as practicable into an FPGA (likely an upgrade on the Vera FPGA), without slots, possibly without User Port, "phase 3", aka X16e (which I prefer to think of as "embedded processor")

Swinging the X16e to the first release or alongside the X16p release means we would REALLY need to drop the already confusing "phase" language, since saying something like "we are going to release Phases 1 and 3 side by side, and if they are successful we will then release Phase 2" is completely and totally confusing to anything who wasn't been following the project closely.

An option without a name, but with could be called the "X16jr", would be to do something along the lines of the X8 but with a memory map and I/O memory location more closely compatible with the X16, allowing plug and play sharing of binaries that happen to fit within the tighter memory constraints of the "X16jr".

Link to comment
Share on other sites

The X8 is really a different beast than the later stages of the CX16 roadmap, so the X8 debate won't be one with the FPGA or SMT versions of the CX16. 

With the X8, you're talking about a computer that's really very different: it will not have a full ROM. Instead, it will have a bootstrapped RAM operating system with a very small bootstrap ROM. This is how CP/M works: there's just enough ROM (a single page, in fact) to boot the BIOS from disk. Then the BIOS boots the command processor, and you have an operating system. From what I understand, the CX8 will work similarly: the bootstrap ROM will load a BASIC+KERNAL program from SD. This means that programs can be written to occupy all 63K of system memory (There is a small carve out for I/O space) without ever actually loading the KERNAL or BASIC. This is not something the CX16 is currently capable of (unless we get RAM in one of the ROM banks.)

The other difference is that VERA is accessed via a single, 256 byte page, rather than the 32 I/O registers we have now. This dramatically changes the I/O process, since you have access to a full line of text or tiles directly, rather than the indirect method the CX16 uses. 

And we obviously have the 512K vs 128K issue to think about. Programs written for the CX8 will have  to fit no more than 128K: 64K of main memory and 64K of video memory. 

On the other hand, the Commander X16 roadmap includes a Surface Mount (SMT) version and an FPGA version. Both of those  will have the same I/O and memory structure as the CX16E (the version currently in the works), but with smaller circuit boards and fewer chips to do the same job. While the package may be smaller, the software will be the same: the same program will run, unmodified, on all 3 of the planned Commander X16 editions. Software that directly accesses video, sound, the User port, or the IEC bus will not run unmodified on a Commander X8.

That's the difference. The X8 is a different computer, and while it shares some common parts, it's as different from the CX16 as the Commodore 64 was from the Plus 4. 

 

  • Like 3
Link to comment
Share on other sites

On 10/16/2021 at 3:29 PM, Ju+Te said:

Why not use clear, easy to memorize and understand names like X16-DIP, X16-SMD and X16-FPGA?

Don't know.

Of course, there's going to be some sticklers who would be all "not ALL of the chips in the X16p are DIP, not ALL of the chips in the X16c are surface mount, all three boards HAVE an FPGA". Iron Internet Law number 38 is "no naming satisfies everyone".

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

On 10/16/2021 at 2:25 PM, TomXP411 said:

From what I understand, the X8 will work similarly: the bootstrap ROM will load a BASIC+KERNAL program from SD.

Aha, that's interesting.  I had thought that it would bootstrap from one of those supercheap slow-ROM thingies.  Rats, I forgot the name. 

Well anyway.  Booting from SD is certainly more modern, and very flexible!

Link to comment
Share on other sites

On 10/16/2021 at 4:26 PM, rje said:

Aha, that's interesting.  I had thought that it would bootstrap from one of those supercheap slow-ROM thingies.  Rats, I forgot the name. 

Well anyway.  Booting from SD is certainly more modern, and very flexible!

Given that the bootloader is 512bytes, power-up interrupt vectors included, so I supposed that it would be booting off the serial flashROM, with the Kernel that it loads containing the code to read the SD card. But that was just supposition.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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

I know this is complicated and I'm nowhere near the expertise, 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?

Please know this is more of a topic of discussion, and maybe a way for me to learn more about the technical side of these computers while throwing a bone of a idea from my head.

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Edited by BruceMcF
  • Like 1
Link to comment
Share on other sites

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. 

Edited by Ed Minchau
  • Like 3
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

Edited by Tatwi
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

@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, ...

Is "limited to 512K banked High RAM as the only functional difference" an "X8" in any useful sense of the term? I suspect not ... that sounds like a design option for an X16e.

The X16p has from 512KB-2MB High RAM, depending on how many of the High RAM sockets are populated ... while the original "X8" basically splits the 128KB internal SPRAM in the Vera FPGA into 64KB for the system and 64KB for the Video RAM. It HAS no HighRAM, it has no VIAs, it has no OPM sound chip, and it has half the "Vera Video" RAM that Vera has.

The point of the design is that it gets a workable 65C02 V2 Basic system with Vera-system video that fits the constraints of the Vera FPGA chip, which is where the under $50 price point (if electronics logistics gets back to something like normal) comes from. If you want to generalize on "X8", it would be some kind of more or less compatible system with most of the system fitting within a single relatively inexpensive FPGA.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use