youki

My vote didn't change too. a Black one! It is more authentic.

Wouaahouuu. Did you convert that by hand ? note by note?

If you don't want use BIOS you can also. I think for a beginner it is less discouraging to start with a C64 than a A2600. He will be able to have quickly something on screen and he will be motivated to do more and learn more. And then being able to study a more difficult machine with good base.

I'm new to Colecovision programming but i'm not novice at all in programming. I started programming back in 1982 on machine with 0.5k of RAM (a sharp pocket computer PC1215 or something like that)... I know assembler 6502 , 68000 , 80x86 and i just toyed a little with the Z80 for the coleco. I wrote my first "homebrew" game on C64 in 1984 back in time i Coded some demo and homebrew on Atari St , and lot of other things on PC. And Development (unfortunaly not game dev) is my job. For now i use C for my coleco development because it is more convinient and i don't have lot of time , but if really needed i will write some part in ASM . My game have already 12 screens with "fancy" but not definitive graphics , 20 sprites defined and 90% of logical control is done and for now the rom size is 11k. The thing to see , if how much space will take the sound track.... for now i don't have it... so...

I guess I don't understand why you say you can't do both? If your target is 32K, this shouldn't really be an issue. I assumed you were talking about a 2/4K cartridge on the 2600, where you could just move to a bank selection scheme. How big are your levels in terms of rom space? What would your title screen look like? These are more factors for which direction you should go, IMHO. --Selgus The question is not a technical question , it is just what would prefer to have ? As "gamer" or "collector" , Do you prefer one with few more levels and less presentation. or do you prefer a game with nice title screen and other cosmetic things and less levels. For instance in the game i 'm making i can choose : (1) To put a nice bitmap title screen and code 2 or 3 additionnal cinematics for inter-level or (2) Let a very basic text based title screen and no cinemetic and in that case add 2 more playable screen.

I agree, do both. The project I am working on has two title screens, but it doesn't affect the actual game. --Selgus I can not do Both. I have to make a choice. I'm developping a Colecovision game. I would like then once completed create few cartridges (at least one!) , that will be the first cartridge i do and it is my first coleco project. So i don't want use bank switching (do not even know if possible on coleco) , my idea was simply to use a 32k eprom to keep thing as simplier as possible. 32k is lot of memory , but my game is very big ,i should have a minimum of 30 screens . May be after having squizzed these 30 screen in the game i will have some free space left. So the question is what to do with that free space. More screens you can play , or title and cinematic.

Hi, This is a kind of pool. Considering that space on cartridge for old system is limited. What would you prefer to have : - A game witih a nice title screen and some little cinematic between level.s - Or would you prefer to not have nice title screen and cinematic but more levels. Thanks.

it could be even more, depending if i have free space left at the end.

I don't know what your "big bosses" will look like or how they will behave on-screen, but have you considered just using background tiles instead of sprites? If you're using screen mode 2, you'd have a greater range of control over pixel colors, but if your bosses move around the screen, you'll have to move them in increments of 8 pixels, which is not such a terrible drawback... This is not at all a horibble way to do it but one other twist...make copies of the boss shifted a pixel or two at a time to smoothen the animation. I think its one bit per pixel? So what you can do is make 8 bosses, each shifted over one pixel from the last. Assuming a 256 horizontal screen using 32 characters across: x>>3 = the X position character location x & 7 = the boss to place onscreen at that position. Of course you can skimp and go 2 pixels jumps and save some memory x>>3= the X position character location (x & 7)>>1 = the boss to place onscreen. I think the later would be fine and you can save yourself 4 bosses worth of memory not to mention be able to use 16x 16 sprites. I know this technic , i used the same kind of trick to do smooth scrolling in some test i did. But here in my case it would consume too much memory. My game should have minimum 30 screens (more depending if i still have memory) .

I don't know what your "big bosses" will look like or how they will behave on-screen, but have you considered just using background tiles instead of sprites? If you're using screen mode 2, you'd have a greater range of control over pixel colors, but if your bosses move around the screen, you'll have to move them in increments of 8 pixels, which is not such a terrible drawback... Yes, i already thought about that. but my bosses need to move smoothly , so i 'd prefer avoid to use chars. And i don't want waste char pattern for monsters and keep it for backgrounds and other elements.

Nope. It's either all 32x32, or all 16x16, but not both simultaneously. I'm not aware of any commercial CV games that ever used double-sized sprites, but I do know that the SG-1000 game "Girl's Garden" used it in the bonus rounds, so if anyone was to port that game, it would be the first and only CV game to make use of 32x32 sprites. thanks for your confirmation. I thought i could double size for my ends level' s big bosses!. i wanted to have a big boss counpounded of 4 double sized sprite and using other sprites (not double sized) above it for details. But anyway , it is not a problem if i can i will use more sprites , and if not i will find another solution or my big bosses will be smaller ...

Hi, so i have figured out my problem with sprites. Now, i have one more question. Is it possible to double size a given sprite and not the other? (reading documentation i 'd say no , but i prefer have confirmation ). Thanks

Very original game! Very good idea!

No, sprites when they diseapear are not at all on the same row. The problem is not here. The limit seems clearly 8 sprites 16x16 , i don't know why. i have checked, put a y=208 where it should . But nothing change. Only 8 sprites at the same time. Did somebody tested that with the SDCC kit from new coleco? May be it is a limitation of the 4k lib or something like that?? #Edit: i have figured out the problem. It was due to my call to updatesprite that was wrong. I have to understand exactly how it works. Now i have all my sprites but with lot of flickering if more than 8... #Edit 2 : Ok, i fixed all It was well a problem with my updatesprite. Now it works like i expect! thanks to all

I use y=207 to hide sprites. But in that case i'm sure they are all on screen area. do you mean i should put after the last sprite , a kind of Dummy sprite with his Y=208 ? But i will double check , it possible i'm doing something wrong here. Another question, can we use on the same screen freely : 8x8 sprites and 16x16 sprites ?

humm.. interresting. I uses SDCC kit from Newcoleco . Would it be a limitation due to libraries here ? Because clearly, if i have 8 sprites(16x16) on screen and try to display 9 , the sprite 9 appears and another one (the 8 i think) disappears.

thanks for confirmation. It seems i will have to change my approach for my game. I started with 32 sprites in mind but 16x16. not good... I will see if if for certain i can use flickering without degrading to much the visual. I suppose we can not do sprite multiplexing as we do on C64 as it seems very difficult to get scan line information. (i saw a "proof of concept" a video on youtube (Here) that do that with TMS9918 VDP but... not really exploitable i think ) Is there a way to manage to do sofware sprites on the coleco in mode 2 ? I don't think as it seems not possible the video memory being character based and so not really possible to access directly pixel in a efficient way.

hi, I would recommend also a 6502 / 6510 based machine. The Commodore 64 would be very good to start with. It is heavly documented and the architecture is quiet simple and powerfull. The Atari 800XL is good also to start , but i think the C64 architecture is simplier to begin with. Other very interesting machine based on 6502 and very easy to learn is the Oric Atmos. It is also very well documented and a lovely machine (therefore less powerful than Atari 800 or C64) , but perfect machine to learn 6502 Assembler. I think the ORIC series is not very known in U.S , but was very popular in Europe (at least UK and France) in early 80's. If you prefere a more modern computer, i would recommend 68000 based processeur , like Atari ST . I would go for Atari St instead of Amiga , i think for a beginner it is easiest. The Amiga has too much coprocessor to deal with for a very beginner. Anyway , that is important to start, is to choose a machine you like , and a very documented one!. If you prefer program in BASIC , i would recommand the Amstrad / Schneider CPC , the locomotive's basic is very very good.

Hi, How many sprites 16x16 can i display on the same screen? i thougth, it was 32 sprites (no more than 4 on the same row of course) But in the game i'm programming , it seems i can only display : 8 ! So i guess it is because in that you can display : 32 sprites (8x8) , it would mean : 8 sprites (16x16). Is it correct? Thanks #post edited : it was late, my sprite count was wrong...

Hi Daniel! C'est Genial! It works well on my machine. No problem. It would be really great if you can add on option that if active , each time you press a note button it add data just after existing one. and add a "replay all" button. It will be a very usefull simple music composer with that function!. That's exactly the kind of tool i need!. Again thanks so much!

I think a 24k (may be 32k, not sure but i think 24) Cartridge of Donkey Kong for colecovision exists. This version has the 4 levels and "in between" animations. The commun cartridge which was delivered with the console was a 16k , i think. Somebody could confirm?

Excellent !!!! Thanks a lot. The mode 3 is mode i'll definitely test in a project i have in mind!

Ca marche!!!! Mille Merci! Thanks a lot, now my game runs correctly with this new kit!!

I tested your last fix , not change in my case. Here the list of API i use : screen_mode_2_text() enable_nmi() disable_nmi() rle2vram() cls() screen_on() updatesprites() put_char() get_char() delay() keypad_1 joypad_1 change_spattern() rnd_byte() sprite_simple() i used also the following one, but i have commented the calls in order to compile. start_sound() update_sound()

Ok, i have quickly tried to compile my project. It compiles and links (after few modification ). But when it runs the screen is buggy. I can see almost my screen how it should be but with some bad characters at some place and i can not see my sprites.