usar666

Great !

I could say it's better than spectrum as it allows video reconfiguration as you want with 1bpp/2bpp/4bpp or screen format as you want without attributes clashes.the counterpart is you have at least twice data to process. Cpc has built-in mass storage too, monitor is too part of the cpc as it is sell and designed for cpc main unit.

About sound, It is like MSX or spectrum+2, the main difference is ay is slower on cpc so it plays louder. It's slower to address because ay is behind a ppi on cpc.on the practical way there are no difference as you can use the same play (arkos tracker) for cpc, speccy or MSX...

...

thanks, how close is this system from original coleco, maybe that would help to understand why it doesn't work with some mods, have you pics of this ?

It has been tested on emulator, on real coleco with atari Max and on its final form on a real cartrige on a real coleco.

I see a lot of hypothesis but i'll make short if some didn't read previous post.I'm not the designer of the cartrige but if you encounter this room changing problem, check how fine your console has been re-assembled, especially mass and ground connect, it maybe not the ultimate solution but i'm pretty sure it is the most frequent issue, the other possible issue is vram reading problem as vram is used for collision détection but you should have some visual corruption in this case. About testing, we tested a lot this game, especially about vram timing problems, playing with coleco joystick too, the game runs in various events through Europe, every problem detected has been fixed, some were really inexpected but we worked to fix them... Sorry for the long post, to make it short : please check if your coleco has been correctly re-assembled after modification and take attention to grounds.

I'd be curious how theses revisions differences could impact Coleco behaviour, RR code use only manufacturer documented features and we can say Coleco is a simple (but powerfull for its time) machine, the most problematic issue seems to be VRAM timing and VRAM delays have been increased over theorical specifications to avoid problems.About mods, this is another problem as mods should respect behaviour of the original hardware, simply because it's not possible to code something without knowing unexpected effects of an additional/modified hardware. Btw, despite the attention given to the final product, minor bugs can happen, i would be sad and apologize to learn that.

Sorry, i may not have explained correctly my point, i'm not an english native so it's sometimes not easy to be understood.Let's say we have been very influenced by demoscene too, my approach is not only for Colecovision but for writing retro games in general and can fit in a simple question 'why using extra hardware/memory when you are not already using fully the machine ?'

Totaly stock machine, getting the best with no extra hardware, this is the whole beauty of making retro games.

yes i'm serious, i see no other robust reason for this topic, and that seems i'm not the only one...

Is this serious or just trolling ?

there is no sprites flickering, this is just an artifact caused by video.

Yep, i wrotte my player exactly like this, the problem is the encoder itself.I'd like to encode sound with 1/300 sec samples (for CPC) but actually the encoder uses only 1/60 sec samples.Do you plan to add variable sample size to your encoder or will it stick to 1/60 sec samples ?

Ah yes, i didn't notice you are artrag, i use already your tool, this is a great thing for machines that owns PSG, thank you a lot that has been very usefull I didn't have time (i am not very good in math i must say so this is a lot of work and i'm involved in other projets) but one day , i'd like to re-write/adapt a such encoder to allow faster replay (for machines like SMS or CPC)

There is no pre-order for now because we want the game in solid state (fully finalized in all aspects) before selling it. It uses fourier transform sounds converted from AY/YM.Interesting, did you write encoding program yourself ?

Don't be afraid , game will be released.Game is ok, cartrige is ok, just some things about the package take more time than excepted, and worst, one of us got a bereavement in his family. Actually, everything else than package is ok but we are waiting his return to finalize package.

For sure that would be very difficult to do a Colecovision , i'd say issues are fast RAM and ROM size.Without theses memory limitations , i'd be tempted to use Bob Pape's spectrum version as base.

who knows, maybe one day, you can ask opcode to port MSX version for sgm, maybe he can add the FM chip that is in its cartridge

Thanks a lot , i must admit i'm very proud of this trick .That was one of the things i absolutely wanted in the game.That was not trivial to obtain, especially to get a correct game speed (btw NTSC version is the best of both in terms of speed and sound) Thx Youki, as i can see RR seems to have impressed you a lot, i'm happy about this In fact, we both owned a Colecovision a bit after the start of the devellopement but mine fried and totO's one had alimentation problems. Remember seeing that when working on RR, the same trick is used too in 'Sydney Hunter & The Caverns of Death' (nicely done game btw) , are you author of this one too ? As you can see in RR, things are a bit more complex as any arbitrary tile can mask any sprite, the whole rendering engine has been built around that. That remember me a funny fact : The game fits in a 32KB ROM but the game source (containing code,tools,gfx,scripts,sounds,musics and so on) is exactly 32MB , ratio 1024 =)

We tried to get the best possible of the console, there are 3 levels.RAM , VRAM and ROM are full =) If you talk about scream, we tried to get an acceptable result from the SN, that was a compromise betmeen performance/size impact and result as we didn't want that freeze the game when playing this sound.

Thanks, no sgm involved here

Thanks for the offer, we made a video last year for the RGC 2016.Some noticed player seems to flicker on video but it doesn't flicker on real game

After one year on finishing, tweaking, testing and debugging , we are very proud and happy to confirm Risky Rick is finally finished. It was planned for Christmas but due to manufacturing issue, it will be released for the beginning of 2018. Stay tuned !

Vram on coleco (like MSX or other systems using the same VDP) is a 16K block.There is no imposed organisation, you can store everything (sprites pixels,tiles pixels,attribute table, color table,sprite table and if you want unrelated to VDP data) where you want (with some limitations caused by pointers alignements).Vram is private and can not be seen directly by Z80. Afaik mode II affects the whole screen. Btw , Z80 is able to address only 64K and is not able of bank switching alone , this job is done with external (to Z80) logic on other systems.