ADFFS 2.61 beta

Discuss ADFFS development versions and upcoming additions
Vanfanel
Posts: 373
Joined: Mon Sep 16, 2013 12:01 am

Re: ADFFS 2.61 beta

Post by Vanfanel » Fri Jun 23, 2017 2:37 pm

@Jon: This project is very important to me. I try to do as much testing as I can with the time I have. But I don't know what has happened to the other testers. We are almost there, thanks to your work almost every Risc OS game is playable on the Raspberry Pi, that is incredible, but I think most people just don't understand what ADDFS does, how it's done and how awesome the results are.
I have tried to get new testers onboard by talking about the project on spanish forums, but I didn't get any response so far. I guess the Archimedes was unknown around here (I was just a little kid back then in the 80's-first 90's and only knew about the ZX Spectrum, Amiga and Atari 800) so people doesn't feel so hooked to the platform as I am.

JonAbbott
Posts: 1739
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: ADFFS 2.61 beta

Post by JonAbbott » Sat Jun 24, 2017 9:26 am

JonAbbott wrote:The last thing I want to look at before release is the flickering some games now exhibit when altering VIDC parameters, Cartoon Line pt.1 and Stunt Racer are affected by this. I'll fire up the "old OS build" Pi and rule out OS/Firmware changes before delving into the code as they flicker on all ADFFS builds that work on the current RISCOS build.
I tested RISCOS back to June 2016 and the flickering seems to be present on all builds of ADFFS as far back as I could test. I'll have to debug the game code and figure out the sequence of events that's triggering the issue.

Visually, it looks like a timing issue, where the screen geometry is changing partway through the raster scan. What I suspect is happening is the physical height of the screen is being changed in these games, which is highlighting a mailbox timing issue in RISCOS. Rockfall possibly alters just the borders, which would be handled by the blitter, where physical screen size changes would be handled by hardware.
Vanfanel wrote:I think most people just don't understand what ADFFS does, how it's done...
I'm planning on doing a series of videos going into detail about how it works, just haven't found the time yet to prepare them. I'll break it up into seperate videos covering areas such as how to install ADFFS, installing games to HD, floppy emulation, VIDC translation, IOC/MEMC emulation, VIDC20 emulation (ie the blitter), VIDC sound emulation, the JIT and possibly cover ARMv7 hackery separately.

JonAbbott
Posts: 1739
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: ADFFS 2.61 beta

Post by JonAbbott » Mon Jun 26, 2017 3:50 pm

JonAbbott wrote:Visually, it looks like a timing issue, where the screen geometry is changing partway through the raster scan. What I suspect is happening is the physical height of the screen is being changed in these games, which is highlighting a mailbox timing issue in RISCOS. Rockfall possibly alters just the borders, which would be handled by the blitter, where physical screen size changes would be handled by hardware.
The games are altering the physical screen size, which is being passed onto the GPU.

Testing GraphicsV 2, it appears that as a side effect the screen is cleared. This isn't necessarily an issue as its immediately blitted back, the problem however is that its done mid-scan so is visible. I'm not certain this can be resolved, so any game that alters the physical screen size is going to flicker (ie Stunt Racer 2000 and Cartoon Line pt.1)

JonAbbott
Posts: 1739
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: ADFFS 2.61 beta

Post by JonAbbott » Wed Jun 28, 2017 12:17 pm

2.61 RC1 now on the dev site. No need for any additional testing, the only change is to remove BASICTrans if a localised version was loaded whilst the JIT was active.

JonAbbott
Posts: 1739
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: ADFFS 2.61 beta

Post by JonAbbott » Wed Jun 28, 2017 2:05 pm

F1023801 Magnetoids (1994) (Oregan Developments) (music isn't 100%)
Add the following to the boot script and see if it fixes the music issue:

Code: Select all

IF ADFFS$CPUID>=&A10 THEN JITMEMORYA 521AC EF020042 E2820076
From looking at the version of DSymphonyPlayer that Magnetoids uses, its fill code counts the number of entries/second and alters the sample rate according. This doesn't appear to work when it's being called at a rate other than 118 times/second, this change forces it to think its being called at the expected rate. Other games that use DSymphonyPlayer include:
  • F10062 Burn 'Out (1995) (Oregan Developments) (sounds okay)
  • F10461 Burn 'Out [SA version] (1997) (Oregan Developments) (not currently supported, but should be okay)
  • F10145 Exodus (1997) (Artex Software) (not currently supported)
  • F10408 Inferno (1996) (Paradise Games) (sounds okay)
  • F10238 Magnetoids (1994) (Oregan Developments) (fixed with latest obey.zip)
  • F10272 Overload (2000) (Paradise Games) (sounds okay)
  • F10386 Wizard Apprentice (1997) (The Datafile) (not currently supported)
EDIT: I've updated 2.61 RC1 to include this fix.

Vanfanel
Posts: 373
Joined: Mon Sep 16, 2013 12:01 am

Re: ADFFS 2.61 beta

Post by Vanfanel » Thu Jun 29, 2017 2:12 pm

@Jon: I've been testing Magnetoids, Burn'Out and Overload (2000) and Inferno with the new RC1 and they all sound great.

I had noticed the problems with Magnetoids before, but they are no more. It has an incredible tittle music, BTW, so Amiga-like that it makes me dance like crazy :D

The other games (Burn'Out, Overload (2000) and Inferno) all sounded great before already, and they still do!

JonAbbott
Posts: 1739
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: ADFFS 2.61 beta

Post by JonAbbott » Fri Jun 30, 2017 8:48 am

That's for all the testing, I think we're good to release it.

The flickering in games that alter screen geometry every frame can't currently be resolved on the Pi. I've posted two BASIC demos on ROOL that highlight the issue of VSync not occurring at flyback, which is the root cause. In the current RISCOS build, VSync is never at a fixed point in the frame (it's triggered by BCMVideo based on an ARM timer, that's an approximation of 1/2 the Hz, instead of a fixed time from ISR), and the ISR IRQ (triggered by the blob allegedly at true VSync) is too late.

The issue is compounded by the fact, the GPU blanks the frame when GraphicsV 2 passes new geometry to it.

Post Reply