usar666
-
Content Count
30 -
Joined
-
Last visited
Posts posted by usar666
-
-
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 ?I just want to point out that Risky Rick is working on CollectorVision Game System

-
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'm curious as to how this game was tested since apparently it won't run in ROM form on the AtariMax cartridge.
-
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.Yes and that is of course another possibility. Proof of that might be if a modded CV is able to play the game without issue or ideally one that has just the +5 RAM upgrade that works correctly. We find that, then we find out if that one is using a different board revision from what I'm working with here. I could crack both of mine open when I'm able and check them.
But yes, the thought did occur to me that we could be dealing with an incompatibility between revisions.
Btw, despite the attention given to the final product, minor bugs can happen, i would be sad and apologize to learn that.
-
IDK, it seems to me that by deliberately restricting software to what was typical in the very beginning (but not REALLY, given how modern programmers have tools they never had nor the vast quantities of documentation that exists today and an ability to leverage worldwide talent that could not have been done then) seems like a half measure and, in most cases, result in a less capable game. The idea is to release excellent games today for the old system. If better games can be made on the same console, that should be what developers should be shooting for.
For a fairer result, maybe they should only use development systems that were available and in wide use back then. Also, work with nothing but whatever documentation was available back then. If these limitations were adhered to, I doubt they could come up with much better.
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 ?'
-
1
-
-
Totaly stock machine, getting the best with no extra hardware, this is the whole beauty of making retro games.Why 32k? Breaking the 32k barrier wouldn't be that big of a deal. Most of the cartridge systems had their rom size expanded during the time.
-
2
-
-
yes i'm serious, i see no other robust reason for this topic, and that seems i'm not the only one...Are you serious? Does it look like I'm trolling? Would I use an account that I've been using for 10 years?
-
Is this serious or just trolling ?
-
there is no sprites flickering, this is just an artifact caused by video.Nice - looking forward to this one.
In the YouTube video above I see that Rick looks kind of transparent/slightly flickery. Is this something the F18A will prevent?
-
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 ?The replayer is on the interrupt and takes very few cycles already. It updates frequencies and volumes on the 3 channels at each interrupt from precomputed rom data. Packing volumes with periods, it needs 6 bytes per fame. That's all.
-
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 usefullYes the math, the Matlab encoder and the Ay8910 player.

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.Where will the game be for sale? AtariAge store or elsewhere? Can we pre order? If so, where?
It uses fourier transform sounds converted from AY/YM.Interesting, did you write encoding program yourself ?usar666 what do you use for voice playback?
I did a tool for lo-fi voice encoding used on msx and colecovision
-
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.Even if both versions end up being very similar? There's not a ton of ways to do R-Type on the ColecoVision. The MSX version looks and sounds quite nice to me, and I would definitely publish it on ColecoVision if someone went through the trouble of porting it. But the port would require a lot of effort, so that's why I'm not actively looking for someone to port R-Type.
-
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 cartridgeNow, do us R-Type on colecovision.

-
Thanks a lot , i must admit i'm very proud of this trickNot only that. They made the bgtiles having priority over the sprites is quite impressive. TMS9918A doesn't have the foreground pixel tile pixels have priority over the sprites feature. I'm 85.394% sure of that unless there's a secret graphic mode that allows that.
.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 thisIndeed the TMS does not have this feature and no secret mode . All is done by code. I know how they did , but as i'm not sure the author would like i reveal the "secret" , i prefer don't say. But nothing magic. Just a very efficient coding. As i said , the work done in that game is incredible. You can not even imagine that a colecovision was able to do that. or let say that somebody that crazy enough to put so much effort to release a game like that in a "officially" dead console... We are FAR FAR FAR away from the MSX ports for the SGM or SG1000 port .
And the thing even more incredible , is that it is the first attempt to do something on the colecovision by the guys who did that. Until recently they even did not have a real colecovision to test!

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 ?In Sydney Hunter I emulated this behavior from Intellivision (where player sank into the sand) reloading dinamically the sprite with 0x00 bytes for the hidden portion of Sydney Hunter.
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 =)
-
1
-
-
I remember playing Rick Dangerous on my PC many years ago. It played remarkably well with the keyboard, with a little practice.

How many levels are there in the CV version?
We tried to get the best possible of the console, there are 3 levels.RAM , VRAM and ROM are full =)
Anyone else think that sound is a bit harsh when you shoot the enemies ?
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.
-
-
Not because I'm the author of CoolCV emulator, but with it you can record easily an AVI video that can be uploaded directly to Youtube

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

-
6
-
-
-
Hello just looking for an abridged layman explanation of how much graphics data Colecovision games hold, I know it has 16 KB DRAM as graphics memory. Maybe I'm missing the terminology as different systems call the same things different names. Was working on a pixel art guide for the system but it needs more information to complete it properly.
-Is that 16KBs a generic chunk of memory that either sprites or background tiles can divide from in non equal ways at run time or is there a set size of bitmap one can use for either layer IE. the Nes and its two 128X128 CHRs?
-The Colecovision can't bank switch but the MSX can, does the ADAM or TI/994A allow bank switching?
-Do many Colecovision games use Mode II or is that something better suited to the MSX or Super Game Module? Also dumb question but is Mode II all or nothing or can it be applied liberally in just key areas of the screen graphics?
Any help would be most appreciated.

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.
-
1
-



Risky Rick in Dangerous Traps (June 25th)
in ColecoVision / Adam
Posted
Great !