alekmaul

thanks guys for typo, I will fix them and it will save 2 bytes in Rom \o/ YES ! (and more for MATCH<>GAME switch).

I did them And I'm using Pletter and RLE compression to save space in ROM. RLE because I'm doing runtime decompression of Robee sprite during game. I will test with pletter later but I think it will be too slow in 4 players mode. Also, scoreboard is a "hommage" for the SNES version of Bomberman : http://www.mobygames.com/game/snes/super-bomberman/screenshots/gameShotId,103629/

It was a long time that I didn't update this post. Progress for RobeeBlaster is now really good. Multiplayer mode (4 players) seems OK and works fine (you can use 9 bombs max per player regarding the bonus you collected). You can use 2 to 4 players, but Colecovision can't replace a player ... Tournaments are from 1 to 5 victories. Story mode is also OK with 24 levels currently and four enemy types. Levels are dispatched in areas with differents graphics, 4 levels per area , so 6 area are in place in the game. I will see if I can add levels and enemy types when the sounds will be added. Bonus are of course bombs, bomb ranges, death, life, points. I will see to add more bonus. Here is a little video about multiplayer mode :

Of course I'm In !

thanks for your replies Philipp, it is clear for me now.

Yes, a chapter with homebrew and cartridges that can run homebrews or real console. Also , non official hardware will be very nice in such book. We have such book in France for other consoles like the SNES : "La bible SNES" is a good example about such book.

I hope they will be also a nice chapter regarding homebrews

You're right, it seems to work, Compiler transforms the value into byte a1 which seems correct ! To easy for me to test that Thanks a lot artrag !

I don't understand your reply (certainly my request was not enough explicit ). I want to declare a global const table with this struct, not to assign vars for it. The struct is using 5 bytes for the password, and 1 another for bonus, nbbricks, not two bytes for them because I'm using 3 bits for bonus and 5 for nbbricks, so the compiler knows it can be join into only one byte. My goal is to assign const for that and I don't want to use variables and only this struct to define the const table.for all the levels. It works fine without bit declaration, so I think it is fesible, just need to find how .... The problem is only for the byte concerning nbbricks and bonus, not for the password.

another question, i'm using structure with bit size specification like that : typedef struct { byte password[5]; // 0..4 level password byte bonus:3; // 5 bonus type (0..7) bbbbbttt byte nbbircks:5; // 5 nb bricks to destroy (0..31) } LevelStruct; bonus is 3 bit sized (so values between 0..7) and nbbricks 5 (values between 0..31). I want to define a const with such structure. const LevelStruct contentlevel[MAXAREA*MAXLEVEL] = { { "AAAA", 2 | (20<<3) , ... But what I tried to test to init the bit sized value, the compiler says : level.c(63) : warning 158: overflow in implicit constant conversion and of course, put 0 instead of the value in the constant. Someone has a solution regarding this problem ?

Yes I did, I modified Daniel's crtcv.s file and shipped it with each project that need this player instead than in the library. Here is the source code I used for UWOL, it works fine but I think I will update it for 50/60Hz management. The currrent checking is not OK, only adapt for coleco bios music. You can remove the frequency checking, it is useless. As you can see, the only thing I did is to removed calls to Coleco BIOS music to avoid problems. ; crt0.s for Colecovision cart .module crt0 ;; external sound table setting routine .globl set_snd_table ;; global from this code .globl _buffer32 .globl _no_nmi .globl _vdp_status .globl _nmi_flag .globl _joypad_1 .globl _keypad_1 .globl _joypad_2 .globl _keypad_2 .globl snd_areas .globl _vid_freq .globl _vid_frsw ;; global from C code .globl _main .globl _nmi .globl _update_music .globl l__INITIALIZER .globl s__INITIALIZER .globl s__INITIALIZED ;; Ordering of segments for the linker - copied from sdcc crt0.s .area _HOME .area _CODE .area _INITIALIZER .area _GSINIT .area _GSFINAL .area _DATA .area _INITIALIZED .area _BSEG .area _BSS .area _HEAP ;; TABLE OF VARIABLES (IN RAM) .area _DATA _buffer32:: .ds 32 ; buffer space 32 [7000-701F] snd_addr:: .ds 11 ; sound addresses [7020-702A] snd_areas:: .ds 61 ; 5 sound slots + NULL (00h) [702B-...] _no_nmi:: .ds 1 _vdp_status:: .ds 1 _nmi_flag:: .ds 1 _joypad_1:: .ds 1 _keypad_1:: .ds 1 _joypad_2:: .ds 1 _keypad_2:: .ds 1 _vid_freq:: .ds 1 _vid_frsw:: .ds 1 ;; CARTRIDGE HEADER (IN ROM) .area _HEADER(ABS) .org 0x8000 .db 0x55, 0xaa ; no default colecovision title screen => 55 AA .dw 0 ; no copy of sprite table, etc. .dw 0 ; all unused .dw _buffer32 ; work buffer .dw 0 ; ?? .dw start_program ; start address for game coding .db 0xc9,0,0 ; no RST 08 support .db 0xc9,0,0 ; no RST 10 support .db 0xc9,0,0 ; no RST 18 support .db 0xc9,0,0 ; no RST 20 support .db 0xc9,0,0 ; no RST 28 support .db 0xc9,0,0 ; no RST 30 support .db 0xc9,0,0 ; no RST 38 support (spinner) jp _nmi_asm ;; CODE STARTS HERE WITH NMI .area _CODE _nmi_asm: push af ld a,#1 ld (_nmi_flag),a ; set NMI flag ;;; call 0x1fdc ; get VDP status ld (_vdp_status),a ;;; ld a,(_no_nmi) ; check if nmi() should be or a ; called jp nz,nmi_exit inc a ld (_no_nmi),a ld a,(_vid_frsw) ; update flag for frequency inc a ld (_vid_frsw),a push bc push de push hl push ix push iy ex af,af' push af exx push bc push de push hl call 0x1f76 ; update controllers ld a,(0x73ee) and #0x4f ld (_joypad_1),a ld a,(0x73ef) and #0x4f ld (_joypad_2),a ld a,(0x73f0) and #0x4f ld (_keypad_1),a ld a,(0x73f1) and #0x4f ld (_keypad_2),a call decode_controllers call _nmi ; call C function ld a,(_vid_freq) ; if 50Hz, setting redo music for bagman sub #0x32 jr nz, $1101 ld a,(_vid_frsw) ; only recall if 1 cycle per 3 and #0x03 jr nz, $1101 $1101: pop hl pop de pop bc exx pop af ex af,af' pop iy pop ix pop hl pop de pop bc xor a ld (_no_nmi),a nmi_exit: pop af ret keypad_table:: .db 0xff,8,4,5,0xff,7,11,2,0xff,10,0,9,3,1,6,0xff ; joypads will be decoded as follows: ; bit ; 0 left ; 1 down ; 2 right ; 3 up ; 4 -------- ; 5 -------- ; 6 button 2 ; 7 button 1 ; keypads will hold key pressed (0-11), or 0xff decode_controllers: ld ix, #_joypad_1 call decode_controller inc ix inc ix decode_controller: ld a,0(ix) ld b,a and #0x40 rlca ld c,a ld a,b and #0x0f or c ld b,a ld a,1(ix) ld c,a and #0x40 or b ld 0(ix),a ld a,c cpl and #0x0f ld e,a ld d,#0 ld hl,#keypad_table add hl,de ld a,(hl) ld 1(ix),a ret start_program: im 1 ; interrupt mode -> rst 38h di xor a ; clear carry ld bc,#0x3b8 ; ram size left ld hl,#0x7000 ; starting from 7000 ld de,#0x7001 ld (hl),a ldir ; zero-fill bss call gsinit ; Initialize global variables. ld h,#0 ; set dummy sound table call set_snd_table ld hl,#0x0033 ; initialise random generator ld (0x73c8),hl ; set screen mode 2 text call 0x1f85 ; set default VDP regs 16K ld de,#0x4000 ; clear VRAM xor a ld l,a ld h,a call 0x1f82 ld a, (0x0069) ; initialise video frequency ld (_vid_freq),a ; call main rountine jp _main .area _GSINIT gsinit:: ld bc, #l__INITIALIZER ld a,b or a,c jr z, gsinit_next ld de, #s__INITIALIZED ld hl, #s__INITIALIZER ldir gsinit_next: .area _GSFINAL ret ;

Lol, really. Perhaps he knows the author of this new version !

ok, I tested your last version (i used sdcc 3.3.0, not the 3.4.0). Here are some things I noticed : - it use less code, we can save more than 1K for some games !, that's really great and it seems to work well. I can't notice some changes with sdcc 3.3.0 (but it is certainly faster because of code saving). Example for RObeeBlaster : - I still have this warning for bagman compilation but not for RobeeBlaster : Any idea about this warning, what does it mean ?

I think I will buy two more cables for my future game : robee blaster, count me in !

you know, if you can be on stock again, i will buy 2 more cables again count me in !

thanks a lot for this release, will test it for my future releases on CV !

ouch, not a simple trick for coleco pad I will check, perhaps you're right. I think I do not have enough "chaos monkeys" to test such things (http://blog.codinghorror.com/working-with-the-chaos-monkey/)

well, don't know when I will have time to add such feature. RAM and ROM >32 KO support is not a problem, it is just AY emulation that needs some works ...

if you add bagman, I would be interest too

ok, will check but certainly not before next year The big deal is certainly to have the same digits as I did for Coleco. The other thing is that I'm really happy that this game is apperciate by the community, thanks all of you for that, that's great !

Sorry no

Yes !

Thanks a lot, really nice review

Nope, MazezaM, RobeeBlaster and UWOL will be here, trust me

Perhaps, the main problem is to try to answer something about this : "porting is not coding" ? What do you think about that ?