Launched Escape from M.O.N.J.A.S.

[rastersoft]

Hi all:

I'm very happy to announce that I finally launched Escape from M.O.N.J.A.S. I also want to thank Einar Saukas for his great help pointing bugs, doing suggestions and helping with the building of the .TAP file.



You can download it from my homepage at http://www.rastersoft.com/programas/monjas.html . It is available in Spanish and in English. It is compatible at least with the Spectrum 48K, Plus, 128K, Plus 2, Plus 2A and Plus 3 (these two in 128K mode to ensure that the floating bus does work). I tested it in 48K mode in an emulator, and in a real Plus 2A. Also, if you are curious, you can surf the source code, available in my gitlab account.

[rastersoft]

BTW: launched version 1.1 that fixes a typo (ussual -> usual)

[cmal]

The visuals look excellent. At first I thought it was a Spectrum Next release until I read further. Thanks for the hard work on this.

[rastersoft]

BTW: again, launched version 1.2: four betatesters and no one detected a little bug Hope it is the last one.

[Einar Saukas]

This game is excellent: great graphics, great puzzles, great sense of humor. I highly recommend it!

[akeley]

Simply amazing. If you released it back in the day, it'd sure be a Crash Smash, etc It's so great to see a proper adventure too, not yet another platformer.
Only played for a bit (welcomed the ship) so far, but love the humour, gfx style and the little details. Well done!

So, move over Metamorphosis, M.O.N.J.A.S. is my new #1 for 2021.

[Ast A. Moore]

This looks great. Do you think you can make it work in 128K mode? I understand it currently only works in 48K mode on 128K machines.

[rastersoft]

This looks great. Do you think you can make it work in 128K mode? I understand it currently only works in 48K mode on 128K machines.

It does work in both 48K and 128K mode. In fact, in Spectrum +2A and +3 you have to use it in 128K mode because in those machines, the floating bus only works in that mode.

[Ast A. Moore]

This looks great. Do you think you can make it work in 128K mode? I understand it currently only works in 48K mode on 128K machines.

It does work in both 48K and 128K mode.

Well, in Fuse, I get a black screen after the game loads and I press a key. If I have the time, I’ll give it a go on my Toastrack and +2A tomorrow.

In fact, in Spectrum +2A and +3 you have to use it in 128K mode because in those machines, the floating bus only works in that mode.

Well, I should know all there is to know about the floating bus on the +2A/+3.

[rastersoft]

Well, in Fuse, I get a black screen after the game loads and I press a key. If I have the time, I’ll give it a go on my Toastrack and +2A tomorrow.

Mmm... you are right... quite odd... In FBZX it does work in 128K mode, but in fuse or in Es.pectrum it doesn't... but in +2A mode it does work... In fact, I tested it in a real +2A and worked fine. Also, quite odd the fact that doing a reset shows the menu...

In fact, in Spectrum +2A and +3 you have to use it in 128K mode because in those machines, the floating bus only works in that mode.

Well, I should know all there is to know about the floating bus on the +2A/+3.

Ops... you are right, sorry

[akeley]

I tried it on MiSTer in 128k and +2a modes, works ok.

[rastersoft]

Well, in Fuse, I get a black screen after the game loads and I press a key. If I have the time, I’ll give it a go on my Toastrack and +2A tomorrow.

Odd... if I change the contention port read from 0x0FFD to 0xFFFF, it does work in 128K mode...

[rastersoft]

This looks great. Do you think you can make it work in 128K mode? I understand it currently only works in 48K mode on 128K machines.

Ok, I received a comment in other forum. It seems that doing a LD BC, 0x0FFD IN A,(C) in a classic 128K (not +2A/+3) is interpreted as a write to the port of the paging latch... and since I do it at the beginning of the INT, it takes the value in the bus (thus 0xFF), and that's why it fails.

[Ast A. Moore]

Ah, yes. I thought it had something to do with paging.

I normally stick to port $40FF for the 48K/128K, and $0FFD for the +2A/+3. I/O contention also plays a role in how the floating bus is read by the CPU, and you can’t use the same port for every machine.

[rastersoft]

Ah, yes. I thought it had something to do with paging.

I normally stick to port $40FF for the 48K/128K, and $0FFD for the +2A/+3. I/O contention also plays a role in how the floating bus is read by the CPU, and you can’t use the same port for every machine.

Mmm... interesting... Why don't you use $FFFF for 48K/128K? In fact, that port should result in contention in the 48K because the ULA would think that there is a memory access, and return always 0xFF, I think...

[Ast A. Moore]

Why don't you use $FFFF for 48K/128K? In fact, that port should result in contention in the 48K because the ULA would think that there is a memory access, and return always 0xFF, I think...

Well, no, because it’s outside the $4000–$7fff range.

[rastersoft]

Why don't you use $FFFF for 48K/128K? In fact, that port should result in contention in the 48K because the ULA would think that there is a memory access, and return always 0xFF, I think...

Well, no, because it’s outside the $4000–$7fff range.

I mean that your port, $40FF, is inside $4000-$7fff range and should cause contention...

[Ast A. Moore]

Well, no, because it’s outside the $4000–$7fff range.

I mean that your port, $40FF, is inside $4000-$7fff range and should cause contention...

Oh, I see. Yes, it does, and my sync loop accounts for that. I use almost the exact same loop for both architectures—48K/128K/+2 and +2A/+3. The loop is self-modifying code, changed at runtime as soon as the machine architecture is detected.

I forget the details now, but it took me a while to come up with a stable and universal (more or less) solution back when I was investigating the floating bus. It is certainly possible to use other ports, but the padding instruction for precise syncing will be different, and you might get some false positives (for example, reading a bitmap byte instead of an attribute byte).

I don’t know which part of the screen your game syncs up to (perhaps it’s just the topmost line of the bitmap area, but my intention was to be able to sync up to any vertical attribute position on the screen, so my loop had to be pretty tight.

[rastersoft]

I don’t know which part of the screen your game syncs up to (perhaps it’s just the topmost line of the bitmap area, but my intention was to be able to sync up to any vertical attribute position on the screen, so my loop had to be pretty tight.

I wait for the beam to arrive to the beginning of the screen to start to copy the working buffer. That way I keep the writing behind it and have nearly two frames for copying the screen and avoid tearing.

[Ast A. Moore]

I don’t know which part of the screen your game syncs up to (perhaps it’s just the topmost line of the bitmap area, but my intention was to be able to sync up to any vertical attribute position on the screen, so my loop had to be pretty tight.

I wait for the beam to arrive to the beginning of the screen to start to copy the working buffer. That way I keep the writing behind it and have nearly two frames for copying the screen and avoid tearing.

Ah, then your loop doesn’t have to be so tight and you have a little more freedom with your port choice.

[Lethargeek]

[mention]rastersoft[/mention], just tried it, very good! So far my only complaint is asymmetric field of view as player's on-screen position is shifted to the right so you can see 4 floor tiles to the left but only 3 to the right. Could you please fix this, putting the player in the exact screen center?

[rastersoft]

@rastersoft, just tried it, very good! So far my only complaint is asymmetric field of view as player's on-screen position is shifted to the right so you can see 4 floor tiles to the left but only 3 to the right. Could you please fix this, putting the player in the exact screen center?

It is a technical problem: in that case, all the map tiles would be "cut in half" in the sides, and that means that it would be the slowest code path. And since I'm already having trouble to keep the 8fps during scrolling, doing that would reduce it to 7fps, and I assure you that it is noticeable (it is a reduction of more than 10% of speed).

[Lethargeek]

It is a technical problem: in that case, all the map tiles would be "cut in half" in the sides, and that means that it would be the slowest code path. And since I'm already having trouble to keep the 8fps during scrolling, doing that would reduce it to 7fps, and I assure you that it is noticeable (it is a reduction of more than 10% of speed).

But aren't tiles sometime partially visible anyway while being scrolled, so what's the difference?
Another possible solution could be scrolling by one tile when the player's facing direction has changed - what do you think?
(also maybe scrolling not immediately but after a step was taken in that direction)

[akeley]

I wouldn't say it's something that necessarily needs "fixing". The main character is not always centered in photography or video games. I wasn't even aware it's actually not centered here unless you mentioned it.

[rastersoft]

It is a technical problem: in that case, all the map tiles would be "cut in half" in the sides, and that means that it would be the slowest code path. And since I'm already having trouble to keep the 8fps during scrolling, doing that would reduce it to 7fps, and I assure you that it is noticeable (it is a reduction of more than 10% of speed).

But aren't tiles sometime partially visible anyway while being scrolled, so what's the difference?
Another possible solution could be scrolling by one tile when the player's facing direction has changed - what do you think?
(also maybe scrolling not immediately but after a step was taken in that direction)

The problem is that, doing that, the tiles would be always partially visible also in the vertical scroll.