A question for all SW developers....

[MCes]

I read that for to be loaded a lot of new games want a 16-24-35k ram expansion.

Have the developers never imagined a cartridge version of their games?
If the SW expect to be wrote on ROM inside BLK1,2,3,5 using for variables (and eventually some self-modifying routines) the native 3.5k ram inside the VIC20, than the SW can be fitted inside a cart.

And in future, if wanted, it can be fitted inside a multicart......

I ask this because I am developing a multicart that is intended for contain 2-BLKs cart images, but with an HW modify this multicart could contain also to 4-BLKs SW imageges.

The question is whether there is a possibility that 3 or 4 BLOCK cart images will be needed in the future (so I have to modify my prototype), or if it can be ruled out.

Any suggest will be appreciated,
thanks.

[DarwinNE]

Have the developers never imagined a cartridge version of their games?

Yes, for my adventure games. They are split in three sections and each one requires BLK1,2,3,5. A single game would therefore require a multicart and it would be a pity not to show the loader screen at all.

If the SW expect to be wrote on ROM inside BLK1,2,3,5 using for variables (and eventually some self-modifying routines) the native 3.5k ram inside the VIC20, than the SW can be fitted inside a cart.

I haven't tried this memory configuration yet, maybe it is possible. Text adventure games do not require much RAM, after all.

[MCes]

Imagine to develop a game for a VIC20 expanded 8K-16k-24k-32k using for all kind of variables only the VIC20 native 3.5k RAM (and only the expanded BLOCKs for the SW body).
It will result in a code that can easy fit on cartridge but also on a disk.

CARTRIDGE: on ROM into BLK5 the autostart key will start the game: 32k (4 BLOCKs) cartridge is easy & cheap to realize, independently of how many BLKs are filled with the game.

DISK: the loading can start with a short SW to be loaded into the native 3.5k ram, inside it a speed loader (EasyLoader?) that will load the body of the game on BLKs1,2,3,(5) and then it will jump on the start of the game.

Using exclusively the native 3.5k of ram for all kind of variables (and only the expanded BLOCKs for the SW) would imply that a single huge work (like as a game) will be a flexible result that will imply the possibility to be easy used in two different HW support.

Could be an interesting strategy of developing?

I'm not expert in writing SW, so if I have told some naivety please forgive me...

[srowe]

The internal 3.5K is precious because it is the only memory that can be addressed by the VIC itself so tends to be used for screen and character generator. If the program needs storage for other state information it tends to be stored elsewhere.

[MCes]

The internal 3.5K is precious because it is the only memory that can be addressed by the VIC itself so tends to be used for screen and character generator. If the program needs storage for other state information it tends to be stored elsewhere.

It's a good point, but it imply that the current game could never been ported on a simple cartridge (excluding a game cart with RAM + ROM on board), and it's a pity.

But if 3.5k native RAM can be sufficient for screen+chars+variable then the strategy seems to be a good strategy...

Is reasonable the self-imposing this limit (about 3.5k ram) when a new game is developed, or it's expect to be not sufficient at all?
For a new game, how many RAM is normally needed for any kind of variables (datas & parameterized code)? I have no idea about it!

[AndyH]

The games I have been working on these last few months are on the principle of blocks 1, 2, 3 and 5 being possibly ROM and so I put nothing there that will need to change. Also, on the principle that my games take over most of the machine I can safely steal many areas of zero page and other areas in block 0 so there is more space than the 3.5K normally afforded to BASIC ... which is handy for me, as I am liking to work with a full simulated bitmap mode and that takes most of the memory between $1000 and $1FFF for the screen and characters allocated to the bitmap array.

So on that basis, your plans / designs for your device could fit nicely with the way I work and I'd say other developer probably do (or could write software) to make use of it too.

[DarwinNE]

I haven't tried this memory configuration yet, maybe it is possible. Text adventure games do not require much RAM, after all.

I forgot an important detail: I use a 40-column driver that requires a bitmap screen... I think the internal RAM only would not be enough for the screen and the game variables.

[majikeyric]

I think the internal RAM only would not be enough for the screen and the game variables.

I second that, using only the internal RAM (which is 5k not 3.5K : [$0000-$03ff] and [$1000-$1fff] ) for variables+screen would surely limit most developers as this RAM is very precious for screen.