Main programmer of the Agony port, an IOD/Abyss member! The game uses the original Amiga graphics with permission

What's the status of this port, WIP?

BTW, one of the big hurdle at the moment is music. Ideally we could re-use the MOD from the Amiga running on the OPL4 but the source code of the MOD player available on this site does not seem to work.

Does anyone know the author of this MOD player so we can try to contact him?

Or ask JohnHassink or another good composer to remake it for MoonSound

Also good to point out that a regular MOD player can't play the file, I presume a MOD file is in it's basics a standard, or are there differences because companies tried to protect them?
So converting the data to MWM or MIDI might not work because of that difference?
Hope it works out

Mod files can easily be ported to MWM.
I did a little try a while ago until I ran into an ancient bug concerning own wave 32.
If sampleram is no issue, a fairly good sounding 1:1 is feasable as this try proves (I stopped when the bug appeared).

This bug has been fixed by BiFi so it's possible to use more than 32 own waves now.

Hi there some news about this project, I'm now able to include sound fx (load an mwk file with tones included that I load in the opl4 sram and playing it on an available wave channel). The mwk file can be loaded from the rom.
I hope porting the mod to mbwave track and playing it with an mwm player... but the mwm player I have is a 12k com file, so i have started to dissamble it in order to modify the mwm load routine as well as the play routine.
I have sent a message to Marcel Delorme, maybe he can help with it.

if somebody could help us to port the track into mbwave. It will represents a huge help for us, since we don't have Dandan anymore in the group

Joel: OK, thanks. Feel free to send the ones you can reproduce already to me and Wouter! Then we can already take a look at those.

i don't see Danilo (DanDan) for 15-20 years ..I wonder where he is now...

Maybe I can do something wrt. the mwm conversion; shoot me a message.

Not yet, but Joel could make some Or Joel, if you don't mind, I can also make some of the version you showed in Nijmegen, if I can find back the ROM file somewhere.

Manuel, I cannot make a video this week (I'm in Austria this week), so yes you Make the video and publish it as you like, the version you have is not running on real hardware, I have a new version with corrections that I will share, this week you will receive the test cases in a rom file format.

128 k, not enough, Wow, I can ask to Frank Sauer which samples they used, he wasn't the author of the soundtrack but I know they had to change a lot to fit their volume constraints (3 disks), we can use one of the unused track with classical instrument in order to reuse as much as possible the rom instruments.

I've to come back on this sample ram size while relistening the OST on Youtube. I took for granted that a good MOD is larger than 128kB, but Agony doesn't use that many samples per song.
In total it's quite a lot more than 128kB, but per MOD it should probably fit.

For your reference (to see what was shown in Nijmegen), I put up a video here: https://youtu.be/xWwDbIwuRLM

Do you use any palette changes? The v9990 has a 'bug' that it shows 'white snow' if you change the palette while the v9990 is drawing on the screen. Only during vertical retrace you can change the palette without any visible side effects. OpenMsx probably doesn't emulate this.

Only changeable during retrace , never tried during horizontal retrace.

Wow ! What an amazing work ! I'm sure it will be a big hit and finished, and will for sure help to sell lots of V9990 cartridges.

320/200 with 16 px black as header, in that version, there are a 12px footer(to each 212), one idea could be to add gfx top and bottom to scroll vertically depending on the owl position

Have you tried Bitmap mode? I'm told the blitter speed in P1 is very slow but in B1 you can copy full screen 4 times per frame or something

Hit9918: The is not exactly how the Amiga display works. It has 5 independent bit planes which can be combined or moved independently, it also has a copper CPU which can execute commands independently from the 68000. This game on the Amiga uses those features extensively.

Just to give you an example look at https://www.youtube.com/watch?v=Rd_Ax7DSZ9w

The background layer on the Amiga (with the moon and cloud and gradient colors) uses a single bitplane (1bit/color)
and the sky color gradient which is a few hundred colors on its own is managed by a copper list. Toll on the CPU = 0.

Once that is done, the Amiga still has 4 bit planes left and sprites which it can also easily multiplex with the copper or manage as "software sprites" with the other Blitter co processor.

More details available at:
http://francksauer.com/index.php/games/15-games/published-ga...

So while the V9990 can do a lot, some of the bitplanes organization and copper tricks used to get the results on the Amiga are not always easy to port exactly "as is" given the very different way the V9990 & MSX work. It's not a question of better or worse hardware. Agony just happens to be designed to take advantage of the very specific Amiga Hardware.

After what syn said with copying 4 screens per frame in bitmap mode. one could try 64 color bitmap mode. Who knows, maybe it could blit all the layers.
With a software nametable, maybe 32x32 pixel tiles, the empty parts are no blit.

and in tile mode beware that the blitter got to run in vertical border, there is the speed, not in display area.
openmsx tables look like it's 6 times slower in display area. which is no shame because there is a whole screen wide of sprites.

but I wouldnt bother the third layer and pose with improved 9990 sprite colors. amiga sprites need to be of the pale 7 colors of the front layer.

but what are you blitting?
I suspect you blit the water in the style of a bitmap machine. a screen wide of background, then a screen wide of water.
but a tile mode needs only a fraction of it. in how many pixels does it repeat, maybe 64*32?
it maybe needs 3 versions, one with sky color background, one with black background, one with the graphics underneath at the transition points.

on the bottom I see a scroll register action.
in the scene where a sprite is there, 3 things wobble versus each other random. while it should be one stable image. the split 1 pixel apart, stable.
how is that pattern possible, I feel there could be some performance loss in that issue. in the timely order of things.

That palette change snow is unfortunate, didn't know about that... hopefully it does work during hblank.

The blit itself may be fast, but starting a blit command takes several times more CPU instructions than changing a tile in pattern mode. So for large copy areas the V9990 is quite fast in raw blitting speed, however as the number of draw calls increase it quickly starts to put a significant load on the CPU... Something to be aware of.

But luckily there is also plenty of VRAM to waste. And thanks to the nice command completion interrupt you can use the downtime between blits effectively for game logic. I wonder if the V9990 is fast enough to do full compositing each frame.

Maggoo is currently testing if we are actually changing the palet in the hblank, maybe you are right Grauw, thanks anyway

page 75 of the manual:
command data port
"acess to this port when the status TR bit is 0 while command is being executed will result in an output of WAIT signal."

so the z80 is waited and dont memory refresh anymore?
better wait for the blitter in software.

Yes the wait is connected. The command data port is used for blit commands from CPU<->VDP (Like command LMMC).The TR bit is the 'data tranfer ready bit'. If you try to send the data to fast to the v9990 it will activate the wait.. That is a wait to let the v9990 process the byte written to the command data port. Not the completion of the whole command.

Joel, did you check the reactions on the video in YouTube? Looks like Yves also reacted! Also, please are asking questions

it needs to be moved against the scroll register.
there are two horizontal adjust registers 0..15 for 6 bitplanes.
either there are 16 pics in memory, shifted pics, or it is blitted. some 25% of blitter budget.
16 times in memory is some 128k, 25% of vram.

Yes, it's still in development, Level 1 finished, level 2 ongoing.
Still have issue with the opl4 driver that crashes the system from
time to time.

still in development? i hope so...

Hi Mumbly, that would be me. I'm still available. Communication just faded. Could be partly from my side since I've got a lot on my head.
From what I remember the aim was to fit it into a 2MB ROM. It's just that the samples for the music take a lot of room. To keep the rest of the music in par with what's already there more space would be required (running from mass storage media?).
Last mail I received was about AAF (iirc) files. I'd like to investigate the options on how to rebuild them in mbwave as 1:1 as possible.

Regards

To be honest, the samples are all taken straight from the MOD files except for the intro track. Those were so big and hard to handle that I kindly asked Wolf to make new samples for me based on the originals.
A way to avoid popping/clicking is channel switching. That's using two channels to play one. Every note will be played on the other channel than the previous. A bit like this:

__CH1_CH2
1 A#4 OFF
2 --- ---
3 OFF G#4
4 --- ---
5 F#4 OFF

This way a note will fade with the set release rate and be mute until the next note on event. Otherwise the note would've been cut off by the attack of the next note. The position of the sine of the previous note and the next note will almost never have a fluent transition, causing a click/plop sound.
One instrument is more sensitive to this than the other, so if not really necessary I abondon this technique cuz effectively it would halven my available channels.

I see you're in Belgium, so there's a 50-50 chance your prevered language is Dutch. Mine most certainly is Dutch (I could've explained the above in halve the words if I used Dutch). So how to address you in e-mail?

Oh yes, sample looping... That's a thing... I've been taught to do that correctly by the only MSXer who can do it perfectly... 15 years ago... And I never did something with the skill cuz making custom samples for Moonsound is quite a hassle... It has nothing to do with the popping/clicking I mentioned (which is also easily achievable with a lot of the rom tones).
As you can see I can manage English, but your real name has a Dutch vibe, that's all... I'll contact you some day soon within a week.

@Meits

your tips is functionning very well, I've just ported the level 1 loading track and a pop occured during a note transition, I used your tip and the pop disapeared

I tryed to change the sample with Audacity and, Indeed it's a pain in the ass and not effiscient all the time , there are, apparently different click and pops cases (peaks, cross zero …).

I'll send you back (reply on your mail) what has been archieved so far.

see you

Any update on this, Joel?

Who need to multiplex sprites with 125 sprites on screen?