Commander X16

When I first read that the X16 will have 512K installed, and be expandable up to 2MB, I thought of the law of the curse of expansion, which says that programmers will develop to the minimum requirements in order to reach the largest audience.

 

But then I went online and saw that 512K SRAM chips are selling for appx $5 each.

 

OK.

 

I'd imagine if it's easy and cheap to add RAM chips everyone would want to max it out, and devs will have no problem asking for more RAM.

In 90's, when IBM PC platform became wide spread, I don't remember this law working any more. Developers asked for any RAM requirements, and users expanded their RAM if they wanted that soft badly.
X16 is a blend of retro and modern system, so I would not be surprised to see the same effect here.

Maybe a stupid question, but what program would need 2 MB ram on an 8-bit computer? You could fill the memory banks with sound samples, I suppose. A game could fill them with images or other graphic resources, but you would have to copy them to VRAM in order to display them and if they belong to different parts of the game you might just as well load them from an SD-card?

@Johan Kårlin I share your astonishment as many others do. 512K is probably enough for everybody. Bill Gates said similar thing once. )
But you never know what developers might come up with one day.

4 hours ago, Johan Kårlin said:

Maybe a stupid question, but what program would need 2 MB ram on an 8-bit computer? You could fill the memory banks with sound samples, I suppose. A game could fill them with images or other graphic resources, but you would have to copy them to VRAM in order to display them and if they belong to different parts of the game you might just as well load them from an SD-card?

One thing that comes to mind is huge lookup tables for fast floating-point (or fixed-point) calculations, e.g. for demos or games using some kind of 3D graphics.

Note that this is all CX16p ... the memory situation for CX16c and CX16e is unknown. For instance, it might be cheaper to have one surface mount 1MB RAM in the CX16c and skip the RAM sockets, and the RAM in the CX16e might be internal to the FPGA and dependent on the specific FPGA used.

When it comes to using up memory, I mean, art assets rule supreme. Want a 256x256 tilemap for your JRPG or platformer? Bam, 128KB of himem right there (256*256 is 64KB, *2 because tilemaps in the VERA are 2 bytes per tile). On both layers? Now 256KB. We haven't even started talking about the pixel data, right? Just the maps. If those tiles have random encounters (for JRPGs), then there's another 64KB for the encounter group table indices. Collision/exits/triggers/other meta? Probably another 64KB. We've consumed anywhere from 1/2 to 3/4ths of the emulator's default system memory and haven't spent a byte on color or sound, or enemies, dialog, behavior... games can really eat through your memory budget in a snap. And there's only so much you can do behind a black screen to preload assets -- you can only keep so much resident in himem, the rest is locked away on that SD card. (And the VERA doesn't make for a great cache... I suppose in theory you could exchange groups of bytes with the VERA as you want to overwrite its contents, but the overhead for this would be relatively high.)

You might try a "streaming" type of approach, if you, say, put your game logic in the vblank interrupt and leave the non-interrupted execution to spin through a series of values which determine which files you want in which banks. That assumes that reading from the SD card won't, itself, generate interrupts which could clobber significant time slices of vblank. And you can only read in data so quickly, so you have to be careful of how much data you're potentially needing to stream in at any given time, and possibly continue to make allowances for when your player gets ahead of the streaming process.

I see your point, impossible to question : ). But I’m still a bit hesitative about the graphic resources. Let’s say you fill a lot of memory banks. You still have to copy that data to VRAM every time you want to use it, probably something games will do between levels, and then the difference between loading them from an SD-card might not be so big?

For someone with very limited knowledge of hardware, it seems better to have loads of VRAM instead of RAM. As you say, a tilemap with the size of 256x256 takes 128 KB, which means it is an impossible choice. There is no room for tiles, sprites or other graphic elements. Because everything you want to display at the same time must exist in VRAM at the same time, having loads of RAM is of no use.

I know I have brought up this before. I think Bruce McFarling had some good explanation of this. It leads to different hardware problems if I remember right. Sorry to be a slow learner...

Well, it's much faster to have the assets in himem because you can retrieve them more quickly than SDCard data. The SDCard requires banging away at the protocol for data transfer, which might be assisted somewhat with hardware but might also involve literally byte-banging single bytes through what effectively amounts to a serial port on an I/O address with commands and replies to retrieve blocks of data... or worse, bit-banging a similar interface to the same job but 8X slower. However the kernal ends up implementing it, it will be way slower than accessing himem.

There are ways to mitigate the costs. For some assets, if you can preload their entirety into VRAM then you could read straight from the SDCard into VRAM, and skip himem. Fair enough. But again, for the 256x256 tilemap case, you have to store at least some of the data in himem, and at that point you might as well limit the contents in VRAM to a 128x64 window into the data (actually, you could probably go as low as an 81x41 window in 640x480 resolution with 8x8 tiles, and if you're using 320x240 and 16x16 tiles, you could go as low as 21x11... but powers of two make certain maths easier; and since they conveniently fit into the VERA's tilemap sizes, you could just scroll the layers and not have to worry about moving quantities of VRAM around to constantly re-align the tilemap.