Jump to content

Expandable RAM


rje
 Share

Recommended Posts

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.

 

Edited by rje
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

11 hours ago, Johan Kårlin said:

what program would need 2 MB ram on an 8-bit computer?

This is actually what I find the most exiting about a project such as the Commander X16.  What would devs have come up with in the 8-bit era had memory restrictions not been an issue?  I'm curious to find out.

  • Like 2
Link to comment
Share on other sites

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.


This is actually what I am doing in my ongoing project. I use a window of 21x11 tiles while the tilemap is 32x32 and the logical map (or what to call it) is 256x256! It’s absolutely doable even if I struggled with it quite a bit before it worked. It would be easier if there were more VRAM, talking about the benefits of more memory...
Link to comment
Share on other sites

20 hours ago, StephenHorn said:

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.

We do know that if it's coming from the built in SD card port, Vera is reading the data in from the SD card, which is an SPI interface with a 12.5MHz serial clock, so in the middle of a block read, the process of writing the output byte to $9F3E, reading $9F3F until bit7 is clear, then reading the input put from $9F3E is going to be about half the speed of a memory to memory copy, if it is properly interleaved. Add the file system overhead to set up which block is being read, perhaps a third of the speed of a memory to memory copy.

That seems likely to be part of why Vera was redesigned to bring out the registers which were previously accessed through the data ports ... direct copy from the SD drive to the VRAM works much faster if the SPI port can be accessed directly and then written to the data port where the auto-increment writes it to the correct location.

; Block read ready, VRAM port A destination & increment already set up
; Y is the byte countdown, X holds the dummy value to write to trigger the SPI transfer
    LDX #0
    TXY
    STX SPI_DATA
-    LDA SPI_CTRL
    BMI -
    LDA SPI_DATA
    STX SPI_DATA
    STA DATA0
    DEY
    BNE -
; (Next I assumed a 'DEC N' on a memory register is going to test whether more pages need transferring)
... note that would certainly busy wait in the first byte, because a maximum byte transfer frequency of 1.5625MHz can't keep up with a 4-clock instruction which has an effective instruction frequency of 2MHz plus, but storing the dummy to start the next SPI cycle immediately after reading the previous SPI data received means that normally the busy will be cleared by the time the loop restarts at SPI_CTRL ... a 13 clock 65C02 sequence has an effective frequency of 615kHz, so the SPI port is plenty fast to keep up with that.

But this is a block transfer that has already been set up. One choice that is likely going to be needed in a number of games is whether to load video assets straight into VRAM from SD card in a double buffered arrangement and feed audio from assets stored in High RAM, or to load, in particular, PCM assets straight into Vera's PCM ports, and load video assets stored in High RAM.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...
On 8/1/2020 at 4:04 AM, 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?

I. THEORETICAL

Taking cues from the 8 Bit Guy's video on his "Dream Computer" (part 2).

1. I assume that "Planet X16" will be distributed via diskette.

2. I assume that the 8 Bit Guy will load the game map and data into banked RAM.

3. Ultima VI is one of his favorite 8 bit games.  On the C64, it came in six diskettes, roughly taking 1MB of RAM.

Given those three assumptions, the Law of Resource Estimation suggests you take your requirements and double them.  If you think you need 1MB, then make sure you have 2MB.

* * *

II. PRACTICAL

The "full load" option is a good one.  You could load everything, instead of swapping files in and out, if you wanted to.

You could load whole diskettes from IEC drives, if you wanted to.

This could make *diskette* distribution "more" viable as an option -- again, if you wanted to.

Doable options that fit well with the overall design.

Link to comment
Share on other sites

I really got some good answers to that question, both from you and several others! When working on my own game I can still dream of more than 128 KB VRAM though. Now I manage to have a tilemap of 256x256 tiles by adding a software solution to what the hardware can offer. It is by far the most complicated and time consuming part of the game so more memory would have made a great difference. On the other hand it has been a fun and satisfying challenge! And sometimes I can’t make up my mind if I want more or less resources... As a whole I think the CX16 already has become my dream computer too.

  • Like 1
Link to comment
Share on other sites

Hmmm. For games memory issues can be workarounded. I mean, in the good old times (tm) of 8-bit, many developers did crunched their games to 32-40 kb of RAM, and some of them were quite large.  I remember impossible mission, draconus, for the c64... for the Ataris, Black Lamp, Mission (or misja), both of them featured 100+ rooms, digitalized music and animations crunched into 38-40 kb of RAM. Of course these were action games. Or rpg for the nes, and we're talking  2 KB of RAM, 2 kb of videoram and 24? (can't remember the exact value, less than 250 tho.) of ram for sprites... Final Fantasy was around 140 kb of rom, i think.

The X16 surpases anything built in the 80-90's era, so better can be done, although probably it won't be exactly easy tho. But then again... "640Kb should be enough for anyone (??)....." 😉

 

Edited by stargeizer
Typos....lots of 'em
  • Like 1
Link to comment
Share on other sites

On 8/21/2020 at 12:06 PM, Johan Kårlin said:

And sometimes I can’t make up my mind if I want more or less resources... As a whole I think the CX16 already has become my dream computer too.

I completely agree with that sentiment, Johan!  At what point does retro become absurd?  Why can’t I be satisfied with the limitations of an 80s architecture?  It’s those limitations that allow me to create, in the first place!  And the VERA chip is by far the most complex thing to work with (that I know of) in the X16.  It’s a bit frustrating when you have to manipulate bits with BASIC.

i imagine the power of VERA, and the sound generators, will be robust for the sake of courting the Commodore demo scene.  OK, I grok that - it’s a vibrant community and worth the serenade.  As for my end, i will be thinking about ways to alleviate my pain...  BASIC extensions to perform sprite ops sounds like a place to start.  And sound commands.

 

 

Edited by rje
Link to comment
Share on other sites

17 hours ago, stargeizer said:

The X16 surpases anything built in the 80-90's era, so better can be done, although probably it won't be exactly easy tho. But then again... "640Kb should be enough for anyone (??)....." 😉

 

Thank you for this!   The X16 is clearly overpowered.... but your post gave me one insight as to WHY that’s a good thing.

i already noted the demo scene, which I hope will be attracted to the X16.  But I’m talking about us programmers who, let’s face it, are used to the sloppy bigger languages.  We’re used to having ooodles of memory and probably will only enjoy a certain amount of data limitations.

in other words, there’s a bell curve here.  Offer 32K of RAM.... and that’s it.... and you could cause undue pain for developers.  Offer too much memory, on the other hand, and you’ve passed beyond into the absurd, or even beyond the 6502’s ability to handle memory reasonably.

 

 Note the 8 Bit Guy’s second video on his Dream Computer.  When he talks about performance, he is roughly aiming for the Intel 286...  in speed, video, and memory.

A 6502 architecture with 80286 specs is the upper end of the chip’s reasonable reach... it’s a good upper end, with enough “slop” to spare for us programmers to enjoy an 8 bit retro experience.

And that feels about right to me.

Edited by rje
  • Like 3
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