Megagame speculation

[steve]

Imagine what features a game could have if it used 512KB megaflash, + 576KB ram + multiple disks either HXC, 3" or 3.5" or hard disk.
The game engine would be in the megaflash and data would be on disks.
The game probably should not rely on graphics to fill the space as the z80 and disk interface are not fast enough.

[ukmarkh]

Imagine what features a game could have if it used 512KB megaflash, + 576KB ram + multiple disks either HXC, 3" or 3.5" or hard disk.
The game engine would be in the megaflash and data would be on disks.
The game probably should not rely on graphics to fill the space as the z80 and disk interface are not fast enough.

Can't we just get the best out of the stock CPC's and Plus models first... I've hardly seen anything push the Plus models yet, and after seeing Sub Hunter, Bubble Bobble and the new R-type, I can't help think there's better things to come.

[steve]

Can't we just get the best out of the stock CPC's and Plus models first... I've hardly seen anything push the Plus models yet, and after seeing Sub Hunter, Bubble Bobble and the new R-type, I can't help think there's better things to come.

I agree, and people are working on getting the best from the machines already, but it will take time to create a megagame so it is worth thinking about ASAP, I did start to think of a 512KB cartridge game for the plus but just knew that people would say "what about the CPC" which is why I included the megaflash, 572KB ram should also be available before any megagame is completed.

But really I cannot imagine (yet) a 1MB to 2MB game for which the 3.3Mhz Z80 will be fast enough.

[TFM]

But really I cannot imagine (yet) a 1MB to 2MB game for which the 3.3Mhz Z80 will be fast enough.

Just be patient, there are two in the pipeline 

[alex76gr]

Wolfenstein 3D for the CPC.


First preview of my wolfenstein engine for Amstrad CPC

Fancy that!

[TotO]

But really I cannot imagine (yet) a 1MB to 2MB game for which the 3.3Mhz Z80 will be fast enough.

It's easy to waste memory... 

[steve]

It's easy to waste memory... 

Especially if you have a fast processor, but we don't.

I can see how lookup tables will help speed up programs though, they will take up memory without taking up too much of the available processor time.

[TotO]

I can see how lookup tables will help speed up programs though, they will take up memory without taking up too much of the available processor time.

Memory always allow to reduce computing times by giving constant result.
Look-up tables are gods.

[Optimus]

More memory would be interesting technically for bigger unroll codes for massive renderers (my wolfenstein renderer unroll codes take near 16k for the column rendering, more would be needed for a highres version (unless I write a smaller slower version) and I am already using the other space for two frame buffer, texture/sprite ram, code and map data and other precalcs for the wolfenstein math). So it would be interesting as an experiment or maybe having a 128k game that also supports higher res renderer for those who have more than 128k.


More memory would especially be interesting from the game designer's side. I am wondering how big worlds could be fit in 512kb. Could a sandbox game be made for CPC? What else is possible? Of course these worlds need much more developing and testing too, so most are happy enough with 64k or 128k based projects.


However I am sticking to 128k which is the standard and quite ok considering what games I have seen on a stock CPC already (Blackland was a big world, I am impressed you could split the heros and one could stay in the previous dungeon and others in other dungeons in the big map). But adding some additional stuff for people with more memory wouldn't be a bad idea if there is time and courage to do this (I remember once I added CPC+ pals in my first demo, I never owned a CPC+ but since I could test this in Winape32, I said why not?). I am also impressed by game devs who still do games for 64k CPC even though it feels little for bigger more ambitious gamedev projects (I always use double buffering now, 32k lost already, ouch!).

[TFM]

Good point!

A 64 KB CPC has 32 KB for code.
And a 128 KB CPC already 96 KB - three times more :-)

And 512 KB will allow us to have more detailed GFX, bigger sprites with more animation phases, also bigger maps. Maybe even video sequences. And todays crunchers allow us even to store 512 KB on a 178 KB disc in compressed form. (Not to mention that most of the people have 3.5" drive, which means 0.7 MB - so a nice intro in addition).

R-Type may show the way here - just for the 128 KB games.

[ralferoo]

One point that's very worth considering (in fact, it's still a massive headache when developing for current gen consoles) is the speed of loading data into RAM from disc. To be honest, it's so long since I used floppies (probably 1996) I've forgotten their transfer speed, but it's not quick that's for sure!

Anything that can be calculated quickly is probably worth doing, so e.g. Optimus' column rendering code could be generated at runtime rather than pre-compile time, and that's definitely something I do in my own code to unroll loops.

Equally, rather than loading data upfront, it'd be better to load pieces in as and when they're needed, which has the advantage anyway of generally reducing memory requirements and increasing the potential size of a game to the size of the disc.

However, if you're doing that it's worth bearing in mind that the slowest part of reading the disk is the seek time, so it's worth thinking about access patterns and clumping data together according to usage. I can't remember specifics for floppies, but for example current DVD drives have an edge-to-edge seek time of around 1s, which when you're transferring data at 8MB/s is a substantial time sink...

[ukmarkh]

I think you might as well play on an Amiga or other computer if you want all these extra's. I wanna see what the CPC can do in its stock form... but yes, a 512k option would be nice for people that want it, but please also do a 128k version for everyone else.


IMHO.

[Bryce]

It could be possible to have both: A game that works with 128K, but has other features if it finds a MegaFlash attached with the correct ROMs installed. The music in the 128K version could be a typical repeating loop, but if it detects the Music ROM, the music could be a much more elaborate affair, it could transfer the music in milliseconds and have different music on each level. The same migh be possible for two different levels of Graphics?

Bryce.

[TFM]

One point that's very worth considering (in fact, it's still a massive headache when developing for current gen consoles) is the speed of loading data into RAM from disc.

Well, working with a CPC is a real Gain. Amsdos is quick! (just compare it to c64). And if you use some "other" routines then you can load 178 KB (one 3" disc) in 9 seconds.

In case this 178 KB are compressed, then you can get about 0.5 MB out of it (or more, depends on your data).

So I guessimate that you can fill the CPCs 512 KB expansion is something less then 20 seconds.

The only example I could provide would be one of my programs, but I talked enough about my own prods anyway.

Boiled down to a nutshell: Loadaing time is no problem :-)

I think you might as well play on an Amiga or other computer if you want all these extra's. I wanna see what the CPC can do in its stock form... but yes, a 512k option would be nice for people that want it, but please also do a 128k version for everyone else.

I really appreciate that you don't ask for a 64 KB version ;-)

It could be possible to have both: A game that works with 128K, but has other features if it finds a MegaFlash attached with the correct ROMs installed. The music in the 128K version could be a typical repeating loop, but if it detects the Music ROM, the music could be a much more elaborate affair, it could transfer the music in milliseconds and have different music on each level. The same migh be possible for two different levels of Graphics?

Bryce.

Right, basicly it renders the CPCoG in a CPC with Cartridge :-)

[Bryce]

It's not fair to compare AMSDOS with C64 DOS disk speeds, it has nothing to do with the OS, it's the fact that the C64 hardware interface is serial that makes it so slow, the OSs are probably similar in speed.

Bryce.

[TFM]

It's not fair to compare AMSDOS with C64 DOS disk speeds, it has nothing to do with the OS, it's the fact that the C64 hardware interface is serial that makes it so slow, the OSs are probably similar in speed.

Bryce.

Well, there is some floppy speed up software for the c64 (which does NOT run with a lot of programs). That makes is 20x faster, BUT it's still not as fast as the CPC. 

However, Bryce, you're right for sure. To compare the simple FDC in the CPC with the c64 floppy - which has it's own CPU (!!!) and can be considered as small computer (!) - is really not fair 

[Gryzor]

I always wondered - how did they make the c64 drive to load faster?

[andycadley]

The C64 drive is basically a whole other computer that has another 6502 in it. That runs code that reads from the drive and then transfers it over a serial link to the C64, however the method used for transfer is extremely slow because it needed to be compatible with older Commodore machines. The fast loaders basically uploaded a different program to the drive which used a much higher speed serial transfer routine.

[MaV]

That runs code that reads from the drive and then transfers it over a serial link to the C64, however the method used for transfer is extremely slow because it needed to be compatible with older Commodore machines.

That was the second major catastrophe. The first one was that the original plan was to build a much faster communication line between the 1541 and the C64, only the production department deleted parts of the original plan because they deemed them not necessary without telling the original design team, when in truth they were needed to have a very fast C64 drive. After a hundred thousand or so boards had been produced, the error was discovered, but that was much too late as nobody wanted to ditch that many boards to begin anew.

The VIC20 itself had a bug in the serial comm chip - the timing somehow wasn't right - the solution was ultimately to lower the transfer speed to a quarter of the possible. Yep, and the second idiocy for the C64 was to make the 1541 compatible with the VIC20 (and slow 1540 drive).


The decision to use a processor instead of a dedicated FDC chip was not as strange as it may seem. Commodore wanted to produce everything in-house; Tramiel hated to depend on other companies, so the PET floppies contained two 6502 (derivates) to handle the floppy functions. And that eventually led to the single 6502 in the 1540 and the 6502 in the 1541.


This was in short and from memory what "On the edge" by Brian Bagnall tells about the drives. A very good reading BTW, and I recommend the book to anyone even remotely interested in Commodore.

[Bryce]

The bottle-neck on C64 drives is the serial communications, it's quite easy to boost their speed by upping the bit rate. The CPC has a parallel interface, so it's already relatively fast and the bottle-neck is at the disks read head, so there isn't really a way of speeding anything up any further.

My recommendation for a C64: Throw away your 1541 and get an SD2IEC or µIEC and install a JiffyDOS ROM while you're at it And if you own a 1581 that you don't want, then just send it to me for free

Bryce.

[ralferoo]

This was in short and from memory what "On the edge" by Brian Bagnall tells about the drives. A very good reading BTW, and I recommend the book to anyone even remotely interested in Commodore.

I second this recommendation. I've never owned a C64, but found that book to be a superb read...

[Gryzor]

"On the edge", as I think I've written before, is a really excellent book from two perspective: as a business case and as a book on retro computers. I definitely recommend it.

[TFM]

The bottle-neck on C64 drives is the serial communications, it's quite easy to boost their speed by upping the bit rate. The CPC has a parallel interface, so it's already relatively fast and the bottle-neck is at the disks read head, so there isn't really a way of speeding anything up any further.

Well, you could supply the double frequency to the FDC, this allows to read 8" drives and HD formats. In the early 90ies we had that guy Robert Steindl (known for his CP/M softwar for the CPC) in our computer club SCUC who told me that he created a mod to allow the CPC to read 8" (and there with also 5.25" HD formats, which are quite similar to 8" drives). Personally I never ever had such a mod, but it bought me to the idea to make the FDC routines in FutureOS quick enought to read HD formats too. One day I really would like to connect one of my two 8" drives to the CPC - just for the fun of it.

[Bryce]

The mod involves a bit more than just doubling the frequency, but otherwise yes, the FDC765 was actually designed to handle 8in drives too, so it's not that difficult to get a DDI-1 or CPC to read these disks.

Bryce.

[TFM]

Oh, yes, it does involve a bit more. You're so right :-DDD