Commander X16

I know someone mentioned that they couldn't believe that a program would take up all available banked RAM.

I tell you, if it's there, it will be used.  

 

7 minutes ago, rje said:

I know someone mentioned that they couldn't believe that a program would take up all available banked RAM.



I tell you, if it's there, it will be used.  



 

"640k ought to be enough for anyone".

1 minute ago, rje said:

I know someone mentioned that they couldn't believe that a program would take up all available banked RAM.



I tell you, if it's there, it will be used.



 

Maybe not a program, per se, but definitely a program + data. Here's how the current state of Cavy's Quest works:

Load #1: Engine code + Main config + Title screen data = 129kB

Load #2: Zone 0 data: 333 kB (nearly complete)

Load #3: Zone 1 data: 320 kB (likely to grow significantly)

Then more zones are to come, but only one needs to be loaded at a time, and the game will be structured to minimize zone transitions.

Then there is other data generated on the fly in three other banks, so an XCI game can absolutely use all 63 user banks at once and pretty much all of main RAM. Maybe not all banks at 100%, but close to it.

1 hour ago, SlithyMatt said:

Maybe not a program, per se, but definitely a program + data. ...

Yes, it's program+data that is the source of "biggish" size sets of files to be loaded onto the SD card.

And one thing to bear in mind is how much some of the C64 game companies would CRUNCH their data down to get it loaded onto a 1541 disk. Given that this is more hobbyist or niche programming, there will be sometimes be something like the US revolutionary war soldier who was writing home, "Dear sister, I apologize for the long letter, but I didn't have the time to write a short one."

11 hours ago, rje said:

Matt (and Bruce), I *think* the SD route is reasonable and (like with the cable) wear can be avoided.

If the sd slot location is inconveniently located and/or wear is a concern, why not 'make' an extension adapter that plugs into the micro and ribbon-cable's (v) it out to a standard size SD slot on the front/under the front of the X16.  Of course, I'm talking about an add-on product that some enterprising youngster can sell for $25 with just $10 worth of parts.  Limited market yes; mother-of-invention type solution, also 'yes'.

Sort of like the TFW8Bit Pet 'extension' Brought the card to the front: https://www.thefuturewas8bit.com/sd2pet.html. The aesthetics of battle-zone style braked metal 70's CBM that incorporates the color matched boxy 2031 style won't fit the Commander's motif but I'm sure something can be worked out.  (if only it were the 70's again, my riveting, shear, brake, punch, spot welding skills could come in handy and I could be a millionaire.  Come to think of it, the 'blue' that Dave uses in his cartridges is probably very close and he already has the mould for the SD slot... hmmm...)

4 hours ago, EMwhite said:

If the sd slot location is inconveniently located and/or wear is a concern, why not 'make' an extension adapter that plugs into the micro and ribbon-cable's (v) it out to a standard size SD slot on the front/under the front of the X16.  Of course, I'm talking about an add-on product that some enterprising youngster can sell for $25 with just $10 worth of parts.  Limited market yes; mother-of-invention type solution, also 'yes'.

Such a cable has quite a few markets which is why you can find them on Amazon for $6. I have a couple of them used to reduce wear on the micro SD socket on my 3D. They didn't turn out to be as necessary as I'd thought though because most of my prints are handled via Octoprint which enables me to start a print from any computer on my network.

I think the concept here is somewhat the same: we (well, some of us anyway) don't want to move around physical storage media in order to move bits. On my Mister, I don't move the SD card to a computer and copy the ROMs I want onto the card; I use FileZilla to copy them using FTP over the network.

On 3/21/2021 at 12:05 PM, rje said:

Matt (and Bruce), I *think* the SD route is reasonable and (like with the cable) wear can be avoided.

It will be fine with a lot of the potential market. For others in the potential market, they will find it annoying. But if there is a range of under $10-$20 solutions that cover the range of different ways that people prefer to handle it - eg, sneakernet, WiFi onto SD, USB flash drive, cheap cable to existing PC - then I think it's OK.

On 3/13/2021 at 9:37 PM, BruceMcF said:

There is, however, Kernel support for installing device drivers that can use the numbered device API, so as long as an autostart program is an option, there doesn't have to be a lot of difference between hardware that has Kernel support and hardware that has loadable Kernel API drivers.



...



And one thing to bear in mind is how much some of the C64 game companies would CRUNCH their data down to get it loaded onto a 1541 disk.

This is my preferred solution -- thing that patches into the KERNAL and acts like a Device, nice and sneaky proper.

And as for crunching data: I'm already doing this with my Traveller-Trader program.  I already have TOO MUCH data to put on the X16 without file-swapping, and I want to minimize that, so I pare down the data.  Remove excess bytes.  Mash two fields together into one byte.  Bitfields and flags.  Even Z-compressing labels (the texts aren't long enough to use the built-in compression library).  It'll still be more data than I can load.  So I drop all the non-essential data... and now I can fill up the RAM banks with a bit of space to spare.  But I had to crunch it.

Quote

How fast do you want 512 kilobytes transferred to the X16 by a game someone wrote?  Answer: probably at fast-loader speeds.  Maybe that just means we load a wedge at boot time.  Ok.

 

Here's my back-of-the-envelope load speeds.  I made what I *assume* are reasonable assumptions, but of course the devil's in the details.

 

ROB'S LOAD SPEEDS TABLE

CLASS  THROUGHPUT  ~BAUD    32K RAM   ONE BANK   256 BANKS  SUBJECTIVE RATING
-----  ----------  -----   --------   --------   ---------  -----------------
Lower      1 kb/s   9600     32 sec      8 sec      33 min  Slow
Meh      2.4 kb/s  19200     13 sec      3 sec      14 min  1541 + Fastloader
OK         5 kb/s  38400      6 sec      2 sec       7 min  Okay
Good       6 kb/s  48000      5 sec     ~1 sec       6 min  Nice (C128 + 1571)
Better     7 kb/s  56000     <5 sec     ~1 sec      <5 min  Nicer
NIC       16 kb/s  128 K      2 sec     <1 sec       2 min  Luxurious
Upper     30 kb/s  huuuge    ~1 sec    0.3 sec       1 min  Bliss


	

LOWEST NON-PAINFUL SPEED

If we can load 1 kilobyte per second, I think we'd be OK.  You'd have to be careful about how you load your banked RAM, but loading the main RAM is not painful.

 

"REASONABLE" SPEED

7 seconds is roughly the half-life of your short-term memory.  Call it 4 to 8 kb/s.  That would feel like luxury to 8-bit people. 

At this speed range (plus or minus), main RAM loads in a few heartbeats, and that's a good place to be in.

If I read right, this is the speed of the C128 with a 1571.

 

UPPER END

Speeds more than 6 kb/s start to approach Luxury. 

8 kb/s isn't a whole lot more noticeable.  12 kb/s is noticeable.

But after that, returns diminish.  Yes, you can load larger and larger chunks of RAM banking without caring.  And that may be important to the demoscene, so OK, there's value.

At what point does that value drop off, though?

30 kb/s is probably as fast as you'd need for file loading...

...and I suspect that 16 kb/s will typically look nearly as fast as 30 kb/s... but that depends on your data...

...unless I'm missing something.  

 

 

2 hours ago, rje said:

 



 



...unless I'm missing something.  



 



 

VRAM loads way faster than RAM, because data loads through VERA first. I'm working on a game right now that needs to switch between four 64kb lookup tables on the fly, and I needed to have the indices to those tables be only two bytes, so they'll go into the low bank of VRAM and all my tile maps etc will be in the high bank of VRAM.  I'm estimating that loading to VRAM will be about 3 times as fast as loading to RAM.

I'm also not really thinking about load speed from the SD card, which is likely to be the main route, isn't it?