Marek Konopka

Put on hold. Working on another Monty incarnation project.

Admittedly, we did not test the game with the real disk drive. Don't know yet what the reason is. We'll look into it. The program does not rely on specific sector configuration. The visual glitches are the outcome of IRQ hadler interference with raster program. Should have switched IRQ completely off. Minor deficiency. Return is no special case, other keys would result with the same side-effects.

No plans to distribute on any other media then freeware electronic version that xxl indicated already.

As already mentioned, we never cared about doing a full Monty game. It wasn't our goal to add any additional gameplay features. It was all about making a relatively easy cassette port of a hi-res game from C16, to see if it is possible to pack it with lots of colors. We do not plan to do anything more with it. C16 version is lacking in many departments compared to other 8 bit platforms. Fact is, it is a quite different game under the very same name.

C16 game map Atari game map

No sfx emulated. No Stereo support. Collision detection is accurate/inaccurate as with C16 original. Not meant to change game logic. The aim was to achieve colorful hi-res game.

There you go - https://www.pouet.net/prod.php?which=84138 Have fun.

The correction works fine. Thanks again.

I will pay attention. Anyway, thank you very much for a correction. I will be doing verification shortly and update you on the outcome.

Can not say VBXE is doing something wrong. It simply masks off the LSB bit. Altirra is not following it. Part of XDL List: dta b(vbxe.EXdlc.RPTL + vbxe.EXdlc.MAP_ON, vbxe.EXdlc.MAPADR + vbxe.EXdlc.MAPPAR + vbxe.EXdlc.ATT) // enable properties dta b(CHAR_HEIGHT - 1) // number of repetitions dta t(VbxePanelColorMapAdr) // attribute map address dta a(0) // attribute map step dta b(0, 0, PANEL_VBXE_COLOR_MAP_ENTRY_WIDTH - 1, PANEL_VBXE_COLOR_MAP_ENTRY_HEIGHT - 1) // hscroll, vscroll, cm width, cp height dta b(vbxe.EXdl.OV_WIDTH_NARROW, 0) // narrow ov/am, main priority = 0 StatisticsPanelVbxeColorMap: StatisticsPanelVbxeColorMapBegin: .rept 2 dta b(0, 2, 0, %01000000) // even entries are fine .endr .rept 2 dta b(0, 4, 0, %01000000) // even entries are fine .endr .rept 2 dta b(0, 6, 0, %01000000) // even entries are fine .endr .rept 2 dta b(0, 8, 0, %01000000) // even entries are fine .endr StatisticsPanelVbxeColorMapEnd: If I use indices from 0..4 Real HW will mask-off the LSB and show wrong colors. Had to use even entries (0, 2, 4, 6, 8 ) I haven't touched the xcolor bit in VIDEO_CONTROL register. Wasn't aware of its existence. Thanks for the tip - I will use this one. Anyway, it's worth fixing the issue on the emulation side.

I meant ANTIC palette emulation with regards to VBXE color map. Should have stated that explicitly, Though mentioned implicitly by saying "color map".

If I set VBXE color palette (#1) like this: #0 black #1 yellow #2 white #3 brown #4 green and reference its entries through color map like this (#1,#2,#3,#4) for PF1, Altirra will show these color accordingly (yellow, white, brown, green), whereas it should not, according to your statement. It should show black (masked off from #1), white, white (masked off from #3), green. Real HW is indeed doing the masking. Altirra does not. Everythings gets corrected when I set up an extended palette and index colors with even numbers: #2, #4, #6, # 8. #0 black #1 black (not used, due to masking off) #2 yelow #3 yellow (not used) #4 white #5 white (not used) #6 brown #7 brown (not used) #8 green #9 green (not used)

There is a bug in Altirra with ANTIC palette emulation. Real hardware is ignoring the least significant bit when interpreting color indices in color map (leads to 128 palette entries being used effectively), whereas the emulation software takes it into account (complete set of 256 entries is used). Notice the top panel colors. Altirra: Real HW:

The 64 KB limit is the ultimate challenge for the game, if you consider having additional soundtrack, the title screen, double buffering etc. You need to save-up on memory as much as you can and still keep in mind the 25 FPS target. Unfortunatelly, on-the-fly pre-shifting would not spare much memory. There are times where there are up to 8 soft-sprites rendered at the same time, and there may be several types on them. The ones on the screen take the most of memory. Would give some benefits on some shots, but the worst case scenario could take most of the memory. The code itself would take also some space.

It's a "work in progress".