How to improve the game competition...

[TFM]

There are plenty of advantages to running directly from ROM...

The only advantage I see is to save RAM. Please tell me about the other plenty of advantages.[nb]No irony![/nb]

[Axelay]

My 2 cents on the current subject then...

While I agree it is blatantly obvious a CTC-AY sized project would be running from ROM as much as possible, in the context of a 16KB ROM competition with 64KB of RAM available, I'd have thought it far less clear cut, and entirely reasonable to imagine that in some instances the best way to get the most out of the ROM to be simply to load it up with a compressed file.

If the purpose of this discussion is to improve the competition, which I'd understand to mean encourage more entries, then I dont see how making a distinction between 'real' ROM games and 'others' really helps that cause.   A game is not an extension to the OS and it doesnt need to preserve RAM or even the OS by the existing rules.   So when I see it said that the ROM games 'should' run from ROM, all I see is either more concern with implementation than the quality of the end result, or perhaps a desire to see only particular kinds of game being entered that would benefit from masses of RAM and a small code base, and I dont really see how an approach that adds restrictions would help grow the competition.

[redbox]

I agree with Axelay.  If Subtera Puzlo had needed to be a purely ROM game then it simply wouldn't have happened.

In reality the 16kb ROM competition was about the size limit rather than the actual use of ROMs - having games that fit in a MegaFlash slot was an added bonus (albeit a very nice one). Being 16kb also meant 1) it encouraged people to finish the games - no room or time for large projects that would ultimately end up unfinished and 2) meant more experienced programmers refined their skills to get the most out of the imposed limit.

If anything, maybe a future combination could take the size limit route (like with demo competitions), i.e. best 4kb, 16kb and 32kb game?  Could encourage more entries and produce some interesting results.

[Gryzor]

Thanks, Axelay. After reading the last several posts I was going to post a "stay on topic" comment, but you said it all, really. Not that the question was not interesting


And yes, Redbox is right, the 16KB size limit was more practical than anything.

[andycadley]

Details... we got four blocks of RAM, and for a smooth game, you probably use double buffering. Means you need two screens, right?


Block 0000-4000: Contains the RST vectors, you can't use them when putting a screen there.

Um, no. If you aren't using hardware scrolling you can still place the screen in the lower 16K and retain the RST vectors and IM1, you just have to offset the start of the display slightly.

Block 4000-8000: Can be used as screen, if you don't bank. It also contains the 6128 Plus's memory mapped IO.
Block 8000-C000: Only common RAM block for all configurations, so it shall contain the stack
Block C000-FFFF: Can contain one screen.


Now using &C3 RAM configuration banks the screen from &C000 to &4000, BUT this only works on 6128 machines, not on 464/664.

If you're banking, it doesn't preclude the screen being at 4000h, unless you actually need to write to it from banked memory. And if you aren't banking at all, because you're running on a 464, then you also don't need to keep the stack in 8000h, because it's always going to be available if it's below C000h (assuming you never page in the lower ROM of course)

Now if you put only few routines in RAM (either for writing to a screen at &C000 or for selfmodifying routines) then you just DON'T HAVE a program running in ROM!

You can run 90% of the code from ROM and only copy routines into RAM where essential. It's what BASIC does after all.

The only advantage I see is to save RAM. Please tell me about the other plenty of advantages.[nb]No irony![/nb]

Primarily, it gives you more effective address space than the Z80 can normally manage, because of the way the CPC still writes to RAM when ROM is paged in. That's particularly handy when the display is located under the ROM if your drawing routines work such that they never need to read from the display file since the screen then lives, in effect, outside the address space.  On 128 machines it also makes it easier to use the more complex banking schemes, since you don't need to worry about you code being paged out as you switch configurations.  On occasion you may even be able make use of the read-write duality for other effects.

[TFM]

Well, you name a lot of advantages of programs in ROM, but code in the Block &8000-&BFFF can do the same. Ok, the exception is to bank complete 64 KB blocks, but seriously, who is doing that? 


About limitation: From a technical pov it may be interesting to see productions of 1K, 4K, 8K or what ever size. But anything below 16 KB would be a waste of ROM space in the MegaFlash (or similar). So thinking in 16 KB Blocks is IMHO a good idea. And yes, the entries of the ROM compo did show what 16 KB can do when using exomizer or similar. Personally I used MadRAMs Turbo Cruncher, which gives the best result of all (to me known) CPC compression utilities. However Exomizer did free nearly another 4 KB, which could have contained a lot more stuff.

A 32 KB limit would be of interest in particular, when using 128 KB machines. Of course a _LONGER_ development time would be needed and it would probably some people scare off (too huge project). Nevertheless I would like to see such games.