forums.jaspp.org.uk

I'm making progress on implementing IOC device 9 on RO3.71. Once it's working on the RiscPC I can look at adding the emulation on the Pi.

I've got sound coming out under DMA so it's now timed right, you can hear it's the music, but it's not 100% right so there's something wrong with the DMA buffer.

The other problem I need to solve is the fact that MEMC writes to set the DMA start and end use the physical address. To get that working I need to figure out how to translate MEMC physical addresses to ARM physical addresses. That may sound trivial at first, except as we don't have access to the MEMC address table so can't directly translate a MEMC physical address to logical, so we can convert it back to an ARM physical address.

JonAbbott wrote:I've got sound coming out under DMA so it's now timed right, you can hear it's the music, but it's not 100% right so there's something wrong with the DMA buffer.

The other problem I need to solve is the fact that MEMC writes to set the DMA start and end use the physical address. To get that working I need to figure out how to translate MEMC physical addresses to ARM physical addresses. That may sound trivial at first, except as we don't have access to the MEMC address table so can't directly translate a MEMC physical address to logical, so we can convert it back to an ARM physical address.

This is now all working on IOMD, provided you change the sound system to 8bit - I'm working towards getting it working on 16bit, but it involves a rewrite of the SoundDMA module, so may take a while. Rather annoyingly, SoundDMA has everything in it to support legacy 8bit audio games, the only problem is that you can't trigger it's 8bit to 16bit conversion at a specific time...if I can figure out how to do that, I won't need to rewrite SoundDMA.

The game is still hanging after you insert disc 2, it's the sound interrupt code that's hanging which I'm still investigating. I'm unsure if it's an issue with the IOC emulation or the ARM3 JIT at the moment.

Man, sounds like it's turning into quite the project - a complete rewrite of a module is crazy! Hope you can get it figured out, really appreciate this!

I've actually started again from scratch this week. After looking at the RISCOS source for SoundDMA and SoundChannels, I figured a better way of implementing IOC device 9, that should also resolve the fixed buffer size on the Pi (fixes 2067BC audio) and add MEMC DMA sound register support (fixes Rockfall and No Excuses).

The bit I've yet to decide on is sample rate conversion, I'm still reading mathematical papers to find the most appropriate equation to use.

And whilst I'm on the subject of audio, I must look at Paradroid 2000 to see why it's sound effects are wrong - I suspect it's related to one of the features above.

EDIT: Paradroid 2000 audio seems to be working on the Pi with the latest beta

I've made some further progress. Having now fixed 22 compiler errors in the main game code, it now gets into the game under the JIT on IOMD

To get it working on 32bit, I need to add 26bit module support so the Mode extension and pointer modules work and finish off coding the audio layer. The pointer module also writes directly to the RO3.1 mouse cursor address at 1F03800, so that's not going to display the correct cursor until Steve's blitter is available or I code something to translate the buffer into a sprite and use legal OS calls to change the mouse pointer.

So the base of the game is working, just the video and audio is left? That does sound like good progress

I was somewhat sidetracked from this when the server trashed itself, but am now back at looking at Diggers whilst preparing the next ADFFS release.

Actions left before it will work:

1. Correct the audio fill code, which is hardcoded to the RO3.1 sound buffer addresses
2. Add cursor support
3. Add 26bit module support

(1) is fairly trivial, I'll fix that up in the game boot script in the same way Rockfall was fixed.

(2) is next on my list now that the blitter fully supports VIDC parameters (from 2.47), I've not decided if I'll implement it through OS_Sprite or directly in the blitter. OS_Sprite has the advantage that it's handed off to RISCOS but RISCOS does have some quirky around scaling after MODE changes.

Implementing directly in the blitter requires hypervising a lot of mouse related OS calls and either replacing them with a software cursor or using the calls to determine if we should be blitting the cursor or turning it off whilst "official" mouse cursors are in use (hourglass etc).

It will really depend on how OS_Sprite handles being called every frame* and if it works with games like Caverns which use a full screen height cursor.

(3) I've still not come up with a good way of implementing 26bit modules, if RISCOS had a method for paging an application back into memory it would be a piece of cake. Without this, I've either got to hook into TaskManager directly (unlikely as it's not future proof), or replace TaskManager. For single tasking apps, none of this is really an issue as the app will never be paged out. It would instantly break WIMP apps though, which I need to add support for in the future, so need to ensure 26bit modules work along side the WIMP.


* Communication between RISCOS and the GPU is done via slots, I believe the GPU processes one slot during a refresh so swapping screen and updating the cursor may introduce a 1 buffer delay to the cursor update depending on how the HAL handles it. I know Jeffrey Lee did do a lot a work around minimising the delays, by using hardware timers and combining actions, but I've not studied the code to see how hardware cursors fall into the grand scheme of things.

Just wanted to check-in and say thank you again for keeping progress on this ticking along during my absence from the forum. I still don't have an ADF image of this game to even try it out, so I'm really hoping to see a JASPP release on here soon

Number 2 sounds quite tricky - I can imagine "hooking" into all those mouse events could be quite CPU consuming, since I expect there are a lot more layers involved on the new Risc OS Pi version, with USB mouse support, and as you mention there the GPU interface. I really don't know though. For 3 it almost sounds like you would have to hack the modules to convert them from 26bit to 32bit - I believe people were doing things like this with popular apps during the early days of the IYONIX release, but I have absolutely no idea how they did it. Lots of trial and error I expect.

EDIT: Just saw you made some progress with the 26bit modules here - viewtopic.php?f=8&t=187 - very exciting!

As of build 2.52a, everything is in place to get this game working on the Pi. There are however some real problems with the game itself that I need to track down:

1. Audio - It's knackered and I'm unsure why, as its happily writing 8bit muLaw audio to original Arc sound buffer addresses, which ADFFS then copies to its own buffer via emulated DMA. It should sound correct, but instead sounds corrupt
2. Screen corruption - It seems to plot the screen, then fade it out. My only guess is either a bug in ADFFS or the game code. I need to get it running on RO3.71 ARM610 to confirm which is at fault
3. Mode Modules - These are based on MODE 28 (not 13 as one would expect) and ADFFS is currently translating them incorrectly
4. Not switching to the correct mouse pointer, most of the time its set to the Diggers equivalent of the hourglass

One other thing I've noted is that the game wants a screen size of 125KB - which is illegal, 128KB would be the correct size. I'm not sure if this has any effect, but it does seem an odd choice of size as its not big enough for two MODE 13 screen buffers. 128KB would be correct for 2 x 320x200x8bpp, but it would then have to set the screen height via VIDC writes, so this is my next line of investigation.

It lives

I've managed to get into the game and actually play it on the Pi.

Issue 2 is being caused by it requiring RISCOS to correctly buffer two 320x200x8bpp screens. Fixing issue 3 may resolve this - to resolve this, requires two changes:

• Recode the ModeExtension type 0/1 handler to pass a translated type 3 back to RISCOS, this should fix the screen buffers
• Figure out why it's not writing the correct parameters to VIDC20 in the first place

Whilst testing, I noticed another issue with the mouse cursor not being set correctly (issue 4 in previous post)