NOP MOD Player v2.0 | MSX Resource Center (Page 6/12)

Ascended (10768)

22-04-2020, 15:31

knm1983 wrote:

Maybe it can be the access in the Turbo R as Grauw comments.

Likely, from your description of the issue.

An effective way to throttle the R800 for long periods without impacting the Z80 too much is by using a sequence of in a,(99H); 1x in a,(99H) = 10 cycles @ 7.16 MHz, 2x in a,(99H) = 72 cycles @ 7.16 MHz, 1x in a,(99H) = 134 cycles @ 7.16 MHz, etc.

Par SjaaQ

Champion (375)

22-04-2020, 16:04

The timing should be ok. It is based on the code from 1995 which already was tweaked by Remco Schrijvers. I even added waits to places where they were missing. I am waiting on the BUSY flag for timing.

I did move around the wait loops (from after the out to before the outs) but did not experience any issues with OpenMSX. If it still is a timing issue this would mean OpenMSX does not emulate it correctly and I have not other way to fix it.

There is no wait for the wave table number, and there never was. I will look into that since I optimized code I could be it is updating too fast currently. Having said that, I am using only the wave number registers and no other and the manual states updating it will cause additional registers to "maybe" fail.

The memory issue can be true if you have an ST with 256KB. It will use up 144KB for nextor in R800 RAM mode which is propably not enough to run nmp anymore (since NMP requires 128KB of memory). This is something I should be able to check and maybe fix, so it will just throw an error when your mod does not fit in memory.

Par SjaaQ

Champion (375)

22-04-2020, 16:36

Build 1781:

Changed the memory allocation to reserve at least 64K up to 128K

Par knm1983

Hero (575)

22-04-2020, 17:11

Thank you all, I am going to try this new version and report my results.

Par ToriHino

Paladin (857)

22-04-2020, 17:21

SjaaQ wrote:

The memory issue can be true if you have an ST with 256KB. It will use up 144KB for nextor in R800 RAM mode which is propably not enough to run nmp anymore (since NMP requires 128KB of memory). This is something I should be able to check and maybe fix, so it will just throw an error when your mod does not fit in memory.

Actually i had also a PlaySoniq installed with an additional 16MB of memory (or currently 4MB active). On a Turbo-R however this is not automatically selected as the main mapper, does NMP only look in the primary mapper for memory?

BTW: Build 1781 indeed solved the problem on starting up with again on a 256K Turbo-R

Update: It now freezes always at exit (not just a black screen but really a hang-up). On regular base it also freezes while using and it looks like the patterns or channels are mixed up now.

Par knm1983

Hero (575)

22-04-2020, 17:24

SjaaQ, now program crash.
The image of the program appears and it is blocked on the screen Loading pattern.
Tested on Turbo R with R800 mode and Z80 mode, in two cases the player crash in this screen.
In my NMS8280 same results.

Par SjaaQ

Champion (375)

22-04-2020, 19:25

NMP does not look for memory, DOS2 does. I only specify "main mapper" because do not want to change slots in the interrupt. As far as I know a Turbo-R never selects external memory for "main mapper" so adding external memory does not help.

There were several things wrong in memory handling of the last change, I think I have fixed that (not tested very much).

Build 1814:

Fixed serveral issues in memory handling.
Requires minimal 16KB and max 128KB of memory now. Throws an error when the MOD does not fit.

Par knm1983

Hero (575)

22-04-2020, 19:32

Thanks , later I can test new version.
Good work

Par Grauw

Ascended (10768)

22-04-2020, 19:51

SjaaQ wrote:

I did move around the wait loops (from after the out to before the outs) but did not experience any issues with OpenMSX. If it still is a timing issue this would mean OpenMSX does not emulate it correctly and I have not other way to fix it.

OpenMSX does not currently emulate the OPL4 timing limits. Nor any other sound chip (though the OPLL will soon). The best way to deal with it is to make sure the timing from the manual is respected in code, and then send test builds to someone who owns the device to confirm… p.s. Before the out is faster and more robust, so that’s a good change :).

SjaaQ wrote:

There is no wait for the wave table number, and there never was. I will look into that since I optimized code I could be it is updating too fast currently. Having said that, I am using only the wave number registers and no other and the manual states updating it will cause additional registers to "maybe" fail.

It is my experience from VGMPlay that when the Yamaha FM chip manuals specify timing requirements, they do not have margins on them :). If it “maybe” fails then that usually means it drops a note every minute or so, these can be annoying bugs to find.

By the way the wave change wait requirement is per-channel, that is, if you change the wave on channel 1 then you can still access channel 2 without problems. So practically speaking, you could set the instruments on all channels, and then poll LD to wait. It reduces the waiting time compared to polling after every channel. Maybe that’s useful for your case.

Par SjaaQ

Champion (375)

22-04-2020, 20:10

I am still not sure when to wait. I set register #8 first, after a while comes register #38 and #20. After this it is either wait for the next interrupt or do the next channel.

I have included a LD wait before I set register #38. Maybe it helps.

Build 1826:

Included a LD wait
Included command line parameter for /CMD9:[0/1] disable/enable
Updated the help a bit