artrag

In some cases it is convenient to stretch horizontally a bit the pictures to reduce the number of colors in the same line of 8 pixels. For static images the sprites can add a lot of details where you need to break the two colors rule. The converter by nanochess does an automagic placement of sprites to mask errors, anyway they are limited to 4 per line and can have a single color each. So it if matter of trade off also in this case

If you add segment management for mapped megaroms you can enable transparent cross development of large projects using colecovision Megacart mapper and ascii 8 msx mapper without changing the source code. You could also add 32kram support for colecovision (sgm) and this would make games totally portable without any effort

Awesome! I was going to ask for msx support 🤣🤣 Oscar, what about posting on msx.org the news about this new tool?

this should be shorter SAR R2, 2 ; R2 = R2/4 = R2*4/16 MOVR R2, R4 ; R4 = R2*4/16 SAR R2, 2 ; R2 = R2*1/16 SUBR R2, R4 ; R4 = R2*4/16 - R2*1/16 = R2*3/16

A nice gameplay https://youtu.be/804xXleO6YE?si=Ya4Y5quyDHS2y0ZG

Any progress on the sprites?

Very nice !

About invisible objects, the problem is that the game does sprite multiplexing to increase the number of bullets and items on the screen. On emulation, all frames appear correctly and all objects are visible. On real HW, some digital TV sets do not display odd or even frames, because they implement interlacing removal. The result is that some object does not appear or appear only in horizontal stripes. In this case try changing the settings of the TV in order to avoid interlacing removal. By trial and error I had some improvement on my Sony TV set.

Probably I should have betatested it a bit more... sorry for the inconvenience. About voices, I have decomposed the speech in tones and encoded them in data. Usually 3 tones are sufficient to get intelligible voice, but if Ecs is active, 6 tones per frame are used.

Yes! It supports both

Try OPENMSX ! It includes Colecovision and SGM

Not necessarily. Compare the asm files generated by the compier if you're curious about which solution is faster.

Note that x,y are 8 bit variables #backtab() is a 16 bit variable, its value has to be passed to a 16 bit variable unless you want to lose the upper 8 bits

The access to the video registers and memory is interdicted outside the VBlank period. The values you set are buffered in RAM and copied to the registers at the next interrupt

No idea, maybe adding a store section to non atari games,