newcoleco

You're right about that, I didn't asked the publisher of the game Playhouse because it's not a game conversion and I'm not using the same title either. I give credits for the pictures even if they are modified versions of the original game to fit my own game. If using these pictures become a real issue then the carts production will simply stops for a moment until further developments. I know, that's why I've asked to contact me by sending me an email instead to my Yahoo.fr one.

4 regular black carts and 4 blue carts ordered so far.

Finaly for your ColecoVision game system ColecoVision Strip Poker Description : Kick-ass music, Lovely graphics, Human-like opponent, Humor, And Poker variation 5-card draw classic. DATE : August 2013 ROM SIZE : 32K (which includes more than 50K compressed graphics) The final beta version is approved by testers, cartridges production will starts at the end of August 2013. Accepting orders right now and for a limited time. Free shipping for more than one cartridge order. 1 cartridge : $36 6 cartridges : $186 1 of 6 special blue cartridges variation : $69 Maximum order of 6 cartridges. Quantity limited. Boxes and manuals sold separetely. Will be most probably done by Dale Wick if he has time. Contact and Payment Information : Send an email to newcoleco at yahoo dot fr with clear topic and clear text message. If your order fits into the free shippping cathegory, directly send money by paypal at daniel dot bienvenu at hotmail dot com with a very clear message specifying your order.

My dear friends, May I ask your cooperation, please? Don't worry, I'm not asking to vote for me... but it's sadly one of the most important things you can do for me and can show your support to the Coleco homebrew community and I hope to me aswell. Since my work with music seems to be highly appreciated, there is a chance that this pole reveals this fact and it gaves me an idea. I would like to ask from you an official web page, an official link showing the results, something very clear and easy to read, so I can show it to my family and friends. I would like a web page with bigger than normal icons and text showing clearly the winners of these poles that I think are relevants for two reasons : can drive homebrewers to keep going, and it's 30 years anniversary of the console and the number of released games is simply incredible. I technicaly agree with the seperation of the rom size and so on like it was done for the minigame compos but for what I do need it's not relevant. Just an idea, maybe using colored coleco standard controllers beside the name of the best of each cathegories like in gold, silver and bronze. Why I'm telling you this? Why it's doing me a favor? My family and friends aren't supportive. In fact, they see what I'm doing as valueless, a total waste of time and energy. My mother is the only person who loves my work but she can't hear well and can't read well unless it's written big, she can't read english either but can identify names and I would like to put a smile on her face and make my family proud of me. It's a difficult time for me emotionaly these days because it's the last period of my mother's life; her major organs may fail any time and that's why my current status here is saying for awhile "soon in depression". Let's keep the ColecoVision scene alive guys! Best regards, Daniel Bienvenu aka NewColeco

I don't know, but for a long time only rare emulators were capable of playing GhostBlaster, might be a good idea to give it a try and see.

It looks like data compression is a piece of cake for you. nom nom! When I've worked on Dan0, my own data compression format, part of it became the hability to steal a few bytes from another table in order to reduce a little more the number of bytes needed to be stored in the ROM file. In order to do this, bits that represent instructions like copy these bytes from an offset are seperate from the bytes stored clearly making possible to merge all the bytes needed to decompress a certain amount of tables into a big table where my routine can simply look into during decompresion, avoiding a little bit encoding too many times the same bytes. When I think about it, there might be a way to merge Dan0 and ZX7 formats in order to maybe get a slightly better compression depending on the number of pictures you want to compress all together in ROM but the cost will an even slower and bigger decompression routine.

The way ZX7 and similar formats avoid building a dictionary is simply by copying bytes from an offset of what is already decoded. For example, the way ZX7 encodes "AAAAAAAAAABCABCABC" is : output A, copy 9 bytes from position 1 (encoded as relative position -1), output B and C, copy 6 bytes from position 10 (encoded as relative position -3), end. This is simply brilliant.

In the case of the bitmap sample screen : Exomizer 2 : 489 ZX7 : 568 Pletter : 570 MegaLZ : 577 ApLib : 577 BitBuster : 595 DAN0 (my latest version) : 613 PkK : 675 pucrunch : 778 DAN0 decompression routine is 97 bytes long (91 bytes if you ignore the push and pop to set the parameters when called from a C program). Direct decompression in VRAM, no RAM involved (except usage of registers of course). It's RLE + fixed hardcoded Huffman in the routine itself, no extra table like an huffman tree needed. ZX7 decompression routine is 131 bytes long (125 bytes if you ignore the push and pop to set the parameters when called from a C program). Direct decompression in VRAM, no RAM involved (except usage of registers of course). Slower than DAN0 but provides LZSS type of compression.

Considering the size of the graphics (54KB) for ColecoVision Strip Poker game, data compression is a vital part of the project. After testing different options, the game fits in a normal 32KB cartridge, no problem. Time for some improvements here and there and that will be it. I will start another thread when ready to publish the game.

I agree, it's slower than RLE (with or without huffman) but not excessively. And rarely we will use compressed data to be decoded "on the fly" during the game. I've coded a routine to decompress in VRAM the zx7 format for ColecoVision (which should works for SMS too since it's the same port number for VRAM). I didn't tested on real hardware yet, but on the emulator it works fine. The routine is 125 only bytes long. It's working so great that I'm gonna adopt this format from now on for my CV projects and add this zx7 decompression in my devkit library. My ColecoVision Strip Poker game went from a size of 32K to 26K, which is quite impressive, and the time to decode never exceed a second.

After a few more hours of net surfing, I saw this gem named ZX7 from the zx spectrum scene. The decompression routine is 69 bytes long only, but it's a routine to decompression into RAM, not VRAM. Beside that, I think it's an incredible achievement. With the test case "ColecoVision Strip Poker title screen", I've got this result. BitBuster : 3595 Pletter : 3557 ZX7 : 3551 ; ----------------------------------------------------------------------------- ; ZX7 decoder by Einar Saukas, Antonio Villena & Metalbrain ; "Standard" version (69 bytes only) ; ----------------------------------------------------------------------------- ; Parameters: ; HL: source address (compressed data) ; DE: destination address (decompressing) ; ----------------------------------------------------------------------------- dzx7_standard: ld a, $80 dzx7s_copy_byte_loop: ldi ; copy literal byte dzx7s_main_loop: call dzx7s_next_bit jr nc, dzx7s_copy_byte_loop ; next bit indicates either literal or sequence ; determine number of bits used for length (Elias gamma coding) push de ld bc, 0 ld d, b dzx7s_len_size_loop: inc d call dzx7s_next_bit jr nc, dzx7s_len_size_loop ; determine length dzx7s_len_value_loop: call nc, dzx7s_next_bit rl c rl b jr c, dzx7s_exit ; check end marker dec d jr nz, dzx7s_len_value_loop inc bc ; adjust length ; determine offset ld e, (hl) ; load offset flag (1 bit) + offset value (7 bits) inc hl defb $cb, $33 ; opcode for undocumented instruction "SLL E" aka "SLS E" jr nc, dzx7s_offset_end ; if offset flag is set, load 4 extra bits ld d, $10 ; bit marker to load 4 bits dzx7s_rld_next_bit: call dzx7s_next_bit rl d ; insert next bit into D jr nc, dzx7s_rld_next_bit ; repeat 4 times, until bit marker is out inc d ; add 128 to DE srl d ; retrieve fourth bit from D dzx7s_offset_end: rr e ; insert fourth bit into E ; copy previous sequence ex (sp), hl ; store source, restore destination push hl ; store destination sbc hl, de ; HL = destination - offset - 1 pop de ; DE = destination ldir dzx7s_exit: pop hl ; restore source address (compressed data) jr nc, dzx7s_main_loop dzx7s_next_bit: add a, a ; check next bit ret nz ; no more bits left? ld a, (hl) ; load another group of 8 bits inc hl rla ret

It's not the first time we talk about data compression, particulary for graphics and because. For graphics, we want a way to decompress data directly into VRAM using near to zero extra RAM space. The common ways to compress data are Run Length Encoding, Huffman and Dictionary. Run Length Encoding (RLE) is the fastest one to encode and decode and can give a decent compression ratio. Huffman is basicaly an optimization by encoding with a small number of bits what occurs the most. Its decompression time is usually a bit longer than for other compression methods. Not a big deal normaly since it's during the initialiation of the graphics for a title screen or a grame screen. Dictionary compression is normaly the best one, but its main problem is usualy the need for extra memory space to create the dictionary while decompressing data which isn't the way to go for ColecoVision games because of the limited RAM space. I created my own data compression long ago which is basicaly an improved encoded RLE compression by using a fixed huffman to encode data. I called it DAN0 and I'm quite proud of myself for saving even more ROM space than with the RLE method I was using for years. Then I was curious to see the other data compressions and I saw that there are many many of them, some can decompress data directly into VRAM, and some of them are just simply better than the others. To help comparing the different data compressions out there, I decided to use a bitmap screen 256x192 with just enough complexity in it to see a difference in size for the different results of compression. LET'S COMPARE SOME OF THE DATA COMPRESSION WE MIGHT USE FOR TITLE SCREENS From my ColecoVision Strip Poker game project : strippokertitlescreen.zip RAW (no compression) : 12288 bytes RLE : 4528 DAN0 : 4143 Pucrunch : 4000 BitBuster or BitBuster Extreme : 3595 PLETTER : 3557 aPLib : 3543 MegaLZ : 3524 Exomizer v2 : 3337 Please note that the size of the program to decompress the data isn't included. Because the end result depends mostly on the original data, we can't say that Exomizer is the best, sometimes aPLib is better than Exomizer, it varies. But a few things are constant like DAN0 is always better than RLE, and Pletter is always better than BitBuster. Side note : SMS homebrew scene is very interesting for ColecoVision homebrewers because it imply Z80 assembly and the port number for VRAM is the same. Which makes links like this one from Maxim quite interesting. Feel free to comment, ask questions, and do your own tests with other data compression programs

After 3 days of development, I've a real easy to play strip poker game for ColecoVision. Title screen with Poker Face music 5 sexy pictures to discover (taken from msx playhouse game) Cards are 7 and up only to increase the frequency of interesting hands Instead of involving money, if she wins she dresses back up Balanced AI adds challenge just enough to want to keep going and replay My beta-testers are saying "It works fine! Make cartridges with this version!"

When I think they published the ROM file without my modification that fixes a minor sound issue. Oh well, it's fine!

Thanks for listening the music and answering my question! I'm reading comments here and I admit that I didn't expected some of your reactions. I'm glad that this thread encouraged imagination and exchange of ideas. Please continue to give your opinion about ColecoVision Strip Poker and other adult games. As for posing for an adult game, unless I transform into a top model, me naked isn't a selling argument.

ROM File : pokerface.zip You are invited to give your opinion. While I'm here, what is the real interest about a ColecoVision Strip Poker game?

What a shock! I've encounter 2 errors in the game Strip Poker. One was a stack overflow error where it's just calculating the next random numbers, the other was a wrong evaluation of cards : I had an ace as my highest card, a queen and the 3 others were under 10 and the game said : "YOU'VE NOTHING with a high card of Q."... ok, well it's not a big deal, I won anyway. I think it's the first time that a Coleco game said to me that I was awesome!

I was able to download the archive without an issue and I'm pretty happy about it. Thanks a lot! I've looked in the games section and I realised that there is a strip poker game for the Coleco Adam and now I want to play it

Totaly agree!

As I see it, idiots again desperate to sell stuff ... I bet they consider themself clever to use plenty of unrelated popular words just to get more views... I saw that too many times, on so many sites, it's just pathetic.

Very good observation/suggestion!

DAY 3 After coding some more to actually get data from the 12K VRAM to be rendered on screen as tiles, I did this quite simple "doodle" program where you can move around and press FIRE#1 to fill up a square and press FIRE#2 to empty one. Note : if you press both, you'll simply empty the square like if only FIRE #2 is pressed. If I wanted to do this doodle software I would have choosen only 1 bit (not an entire byte) to represent each tile, expending by 8 the size of the map... but this is just a test before the real game project starts. Now it's time for me to consider coding the game itself I've in mind which involves some collision detections, some more tiles and entities of course, and so on. I hope you enjoy this thread as much I do! day3.zip And the source code for the programmers interested into Z80 coding and also into how I coded this ROM file. ; gridtest.s .module gridtest ; INTERNAL VARIABLES .globl _player .globl window ; INTERNAL FUNCTIONS .globl _init_gamegraphics .globl _update_window .globl _output_window .globl _tile0 .globl _tile1 ;; TABLE OF VARIABLES (IN RAM) .area _DATA _player:: .ds 2 ; player (Y,X); window:: .ds 2 ; window (Y,X); playerspr_tmp:: .ds 2 ; playerspr_tmp (Y,X); buffered_tiles:: .ds 560 ; RAM buffer ( 28x20 = 560 ); .area _CODE _init_gamegraphics: ld bc, #0x0000 call #0x1fd9 ld bc, #0x0182 call #0x1fd9 ld bc, #0x0202 ; SCREEN * 0400 = 0800 call #0x1fd9 ld bc, #0x032d ; COLOR * 0040 = 0B40 call #0x1fd9 ld bc, #0x0400 ; PATTERN * 0800 = 0000 call #0x1fd9 ld bc, #0x0516 ; SPRITE_ATTRIB * 0080 = 0B00 call #0x1fd9 ld bc, #0x0601 ; SPR_GEN * 0800 = 0800, but only 0B60-0FFF is usable call #0x1fd9 ld bc, #0x0701 call #0x1fd9 ;; CLEAR VRAM ld hl, #0x0000 ; START xor a ; BYTE TO COPY ld de, #0x4000 ; COUNT call #0x1f82 ; FILL VRAM ;; SPRITE PATTERN #0x6C : FILLED SQUARE ld hl, #0x0B60 ; START ld a, #0xff ; BYTE TO COPY ld de, #0x0020 ; COUNT call #0x1f82 ; FILL VRAM ;; INIT SPRITES ATTRIBUTES : (Y,X,ID,COLOR) ld de, #0x0B00 ld hl,#spr_init ld bc,#5 call #0x1fdf ;; GAME CHARSET ld de, #0x0000 ld hl,#game_charset ld bc,#6*8 call #0x1fdf ;; GAME COLOR ld de, #0x0B40 ld hl,#game_color ld bc,#1 call #0x1fdf ;; SCREEN ON ld bc, #0x01e2 call #0x1fd9 ret _tile0: ld a,#0 jp set_tile _tile1: ld a,#1 set_tile: push af ld c,#0xbf ; 10 lines, port #BF ld hl,(_player) ; HL = window position srl h srl h ld a,l rra ld l,a ; HL = offset on map ld de,#0x1000 add hl,de ; HL = offset in VRAM out (c),l ld a,#0x40 add a,h out (c),a dec c pop af out (c),a ret _update_window: call #window_newxy ;; GET MAP DATA BASED ON WINDOW COORDINATES ld bc,#0x0abf ; 10 lines, port #BF ld hl,(window) ; HL = window position srl h srl h ld a,l rra ld l,a ; HL = offset on map ld de,#0x1000 add hl,de ; HL = offset in VRAM ex de,hl ; DE = offset in VRAM ld hl,#buffered_tiles+560-140 ; HL = offset in RAM jp $4 $3: ld a,e add #0x80 ld e,a adc a,d sub e ld d,a $4: out (c),e nop out (c),d push bc ld bc,#0xebe ; 14 bytes, port #BE inir pop bc djnz $3 ;;;; ld de,#buffered_tiles ; DE = POINTER TO BUFFER FOR TILES TO BE ON SCREEN ld hl,#buffered_tiles+560-140 ; HL = POINTER TO PARTIAL MAP IN RAM ld b,#10 ; B = 10 lines $5: push bc ld b,#14 ; B = 14 tiles per line $6: push bc xor a ld c,(hl) inc hl push hl sla c rla sla c rla ld b,a ld hl,#game_tiles add hl,bc ld bc,#0x0002 ldir push de push hl ld hl,#0x001a add hl,de ex de,hl pop hl ld c,#2 ldir pop de pop hl pop bc djnz $6 ex de,hl ld c,#0x1c add hl,bc ex de,hl pop bc djnz $5 ret _output_window: ld hl,#buffered_tiles ;; ADJUST WINDOW OFFSET xor a ld de,(window) bit 0,d jr z,$0 add #28 $0: bit 0,e jr z,$1 add #1 $1: ld e,a ld d,#0 add hl,de ;; OUTPUT TO VRAM ld de,#0x0863 ld b,#19 $2: push bc ld bc,#27 push de call #0x1fdf pop de inc hl push hl ld hl,#0x0020 add hl,de ex de,hl pop hl pop bc djnz $2 ;; PLAYER SPRITE ld hl,(_player) ld de,(window) ld a,h sub d sla a sla a sla a add #23 ld (playerspr_tmp),a ld a,l sub e sla a sla a sla a add #24 ld (playerspr_tmp+1),a ld de, #0x0B00 ld hl,#playerspr_tmp ld bc,#2 call #0x1fdf ret window_newxy: ld hl,(_player) ld de,(window) ld a,l or a sub #8 jr nc, $11 xor a $11: sub #246-8 jr c, $12 xor a $12: add #246-8 ld l,a or a sub #17-8 jr nc, $13 xor a $13: cp e jr c, $14 ld e,a $14: ld a,l or a cp e jr nc, $15 ld e,a $15: ld a,h or a sub #6 jr nc, $17 xor a $17: sub #184-6 jr c, $18 xor a $18: add #184-6 ld h,a or a sub #11-6 jr nc, $19 xor a $19: cp d jr c,$20 ld d,a $20: ld a,h or a cp d jr nc, $21 ld d,a $21: ld (window),de ret spr_init: .db #0xD0,#0x00,#0x6C,#0x0E,#0xD0 game_charset: .db #0x00,#0x00,#0x00,#0x00,#0x00,#0x00,#0x00,#0x00 .db #0xFF,#0x80,#0x80,#0x80,#0x80,#0x80,#0x80,#0x80 .db #0xFF,#0x01,#0x01,#0x01,#0x01,#0x01,#0x01,#0x01 .db #0x80,#0x80,#0x80,#0x80,#0x80,#0x80,#0x80,#0xFF .db #0x01,#0x01,#0x01,#0x01,#0x01,#0x01,#0x01,#0xFF .db #0xFF,#0xFF,#0xFF,#0xFF,#0xFF,#0xFF,#0xFF,#0xFF game_color: .db #0x51 game_tiles: .db #0x01,#0x02,#0x03,#0x04 .db #0x05,#0x05,#0x05,#0x05 #include <coleco.h> #include <getput1.h> extern void init_gamegraphics(); extern void update_window(); extern void output_window(); extern void tile0(); extern void tile1(); struct coord { byte x; byte y; }; extern struct coord player; char dy; char dx; void nmi(void) {} void update_player(void) { if (dy!=0 || dx!=0) { player.y+=dy; dy = 0; player.x+=dx; dx = 0; } else { if (joypad_1&FIRE1) tile1(); if (joypad_1&FIRE2) tile0(); if (player.x>0 && joypad_1&LEFT) dx = -1; if (player.x<254 && joypad_1&RIGHT) dx = 1; if (player.y>0 && joypad_1&UP) dy = -1; if (player.y<190 && joypad_1&DOWN) dy = 1; player.y+=dy; player.x+=dx; } } void main(void) { init_gamegraphics(); dy = 0; dx = 0; loop: delay(1); update_player(); update_window(); delay(1); output_window(); goto loop; }

There is no magical answer about making giant maps for Coleco games except that it is possible to find ways to accomplish it. All the ideas are pretty good, giving some solutions to think about in order to answer this question "how to make huge maps for ColecoVision games?" ... which is not easy to answer unless you involve special cartridges that can hold even more ROM and/or RAM. Using bigger tiles per byte is a clever idea to get a bigger map. Unfortunately, it forces the game to display only predetermined parts of rooms and formations of blocks. This method can be used for scrolling games without worrying too much about rendering speed. Using compressed data instead of uncompressed involve to keep track of where to look at in the compressed data to decompress it right on screen... something that you have to be very clever or don't care about cpu time to be used in a game as if it's uncompressed. This idea is pretty good for non-scrolling games but not really for scrolling ones.

Short answer : A different rendering strategy has to be considered in order to use 32x32 pixels per tile without using more RAM space or a lot more computations. Long answer : Extending the map with 32x32 pixels per tile is possible of course but it will results into different considerations and computations. By considering using only a single byte for X and a single byte for Y coordinates, the 8 pixels movements on 16x16 pixels tiles on a 96x128 tiles map provide the possibility of 191x255 coordinates for a 16x16 pixels entity. This way bytes for X and Y coordinates are used fully for all entities including the player giving an elegant and optimal RAM usage and assembly coding. My rendering strategy with 16x16 pixels per tile imply to show always the same number of tiles regardless if they are partialy visible or not, and to render all the tiles in RAM before loading them on screen. By using this strategy but for 32x32 pixels per tile instead of 16x16 pixels per tile will imply to show only 7x5 tiles on screen at once in a 200x136 pixels area instead of 14x10 tiles in a 216x152 pixels area. Note : screen resolution is 256x192 pixels. You might argue that we can have also 232x168 pixels area on screen and still use the same rendering strategy but in that case the size of the buffer in RAM will be 768 bytes long which is unacceptable considering that only 1K of RAM is available for everything including sound table, various informations for the player and other entities, etc. So, it's possible to use more pixels per tile but it's a different case that needs a different approach.

Hello everyone, You might remember one of my previous posts about extreme usage of Video RAM (VRAM) as extra RAM for the game and I decided to do a simple test to see if it worths more investigation. The idea is to use a variation of Graphic Mode I ( 1 charset, 32 pairs of colors for the entire charset, and a limited number of sprites) in a way to free up as much consecutive VRAM as possible for other purpose. DAY 1 After an entire day thinking and calculcating, I came up with the following potentialy interesting VRAM is structure. With a very limited sprites usage, a dynamic map of 96x128 tiles can be stored in 12K of the 16K available. Only 14x12 tiles can be shown on screen at once, each tile rendered as 2x2 characters (32x32 pixels). DAY 2 The following ROM file is a demonstration of the scrolling effect based I've imaged for this test. Depending on where the player is on the map and where (s)he is going, the window scroll or not accordingly allowing to reach every tile of the map. The player's movements are always completed to stop on a tile, never partial tiles, which may feel a bit odd the first time you try but it's an important part of the game mechanics I've in mind. day2.zip