Beagleboard XM ADFFS blank screen

Hello everyone,

I am having trouble running any game from JASPP repository with ADFFS installed. Any game I am starting is ended up with the black screen.

I am trying to find any instructions of how to configure OMAP3 video to make it stick to a single resolution according to MDF profile
and upscale the other modes to it like Raspbery Pi does by using the following commands:

fake_vsync_isr=1
#set GPU upscaling to nearest neighbour
scaling_kernel=8

in !Boot.Loader.CONFIG/TXT

and

disable_mode_changes

in CMDLINE/TXT

Is there any way to configure Beagleboard-XM GPU mode the similar way?
Or maybe you have some other suggestions of how to run JASPP games on Beagle?

I will really appreciate any help on this matter.

Thank you in advance

Vic.

I think the Pi is unique in this regard. RISC OS doesn’t have any scaling capability.

I think adding one (a scaler) to ADFFS is on Jon’s todo list, but it’s not there now.

Does it mean I can not start any of JASPP games on Beagle?
It Looks like ADFFS itself is not working correctly with MDF files or something similar to it.
Unfortunately I can not debug anything myself unless I am on a black screen.
Is there any way to trace the problem? Did someone else managed to run ADFFS on BeagleBoard-XM?
Is there any Alternative way maybe…

IIRC ADFFS makes use of the AnyMode module on the PI and RPCEmu to bypass the MDF and let the hardware/emulation perform the scaling of any resolution. For other machines, the MDF must contains the resolutions used by the games.

On my RiscPC I wrote a little module which intercepted mode change attempts. It looked for the nearest resolution and moved the extra pixels to the border timings. It let me at least see most games/demos, even if it was somewhat timestamp sized (the minimal screen resolution supported by LCD screens being 640×480 most occupied 1/4th of the screen).

I don’t know if it works on other machines or every monitor but if I have the time I will try to dig it out and its sources this evening.

I already posted it some time ago. The MissingModes module and sources can be downloaded from here

I am having trouble running any game from JASPP repository with ADFFS installe

Just noticed this, seconds after my email to you…

As far as I know ADFFS has never been tested on a Beagleboard. There’s an MDF on the ADFFS download page, but I’m not sure what it will do on a Beagleboard as it needs the machine to support the resolutions and bit depths.

As mentioned by Richard, a software scaler is planned for a future update. ADFFS is mostly centered around the Pi as its cheap-as-chips and has a built in upscaler.

IIRC ADFFS makes use of the AnyMode

ADFFS doesn’t require AnyMode as it has an inbuilt GraphicsV driver that overrides any mode restrictions. On a RiscPC ADFFS will use EGAonVGA timings to get most games working, although there’s still a few that won’t display due to the overscan being beyond limits.

Thank you for making the module source code available.
Is there a pre-compiled binary and the instruction of how to apply the module?
I would be happy to try it on my BeagleBoard and post the results here.

Is there a pre-compiled binary and the instruction of how to apply the module?

If you are talking about my MissingModes module, the compiled module is present in the MissingModes folder.
As for the instructions:
- save all your work before
- double-click on the module
- try your games with ADFFS

I tested MissingModes on my Pi4 and it had troubles with all those new color modes and RGB ordering in RISC OS 5, so I made some corrections. The module is now available from http://riscos-digitalcd.net/missingmodes/missingmodes.htm

Nice, but !LBreakOut, the game that I never play of course, is still stretched to 16:9 rather than the original 4:3. Or is this beyond the scope of the module? Strangely, viewed with VNC on the Windows PC, the game is displayed as it should. But of course, I never play it.

I just use a trick to transfer to use an larger screen definition and moving the extra pixels to the borders, no scaling, no stretching and it all depends of how the hardware and monitor handle them.

When I still had my Risc PC, it displayed the output at the center of the monitor.
Yesterday, when I corrected the module to work on RISC OS 5, the machine actually stripped the borders and the display of a 480×352 mode changed depending on the “disable_mode_change” option. With it active, it was displayed with the correct aspect ratio. When inactive, the monitor was in charge of the scaling and displayed it stretched to 16:9, though a check just now in the monitor’s menu shows that it as options “Full” and “Aspect” so I guess I could force it to display it as 4:3. The actual stripping of the border actually makes me a but nervous as I assume the Pi sends a 480×352 signal which may not be accepted by all monitors.

Is there any Alternative way maybe

Possibly. I’ve not downloaded any games from JASSP but have some software which originally required keydiscs. I imaged these some time ago to JFD format and use ADFFS to load these as Pseudo floppies. Which enables these progs to run.

I am having similar problems to you in that ADFFS will not run on my Pinebook Pro due to the laptop not being able to display the mode that is needed for ADFFS to run. Or at least that’s my (limited) understanding of it.

I have got my stuff runing with perhaps a slighly unorthodox solution, which may or may not work for you. Basically I downloaded !ArchiEmu from
http://www.tellima.nl/riscos/

Then using the RISC OS 3 environment provided with it, I then downloaded Uniboot31 from here:
http://www.riscos.com/ftp_space/310/index.htm

Installed it within the RISC OS 3 environment for ArchiEmu, and set up the environment to boot with the Universal boot.
I then copied my programs in there, put any relevant system modules into appropriate place in boot. Copied in ADFFS.

I can then run everything I need within that emulated environment.

Obviously I haven’t tried this on a BeagleBoard, so have now idea whether this will work and it is potentially somewhat long winded, but it may be worth a try anyway

Is there any Alternative way maybe…

Yes, You can re-package your games using ArchiEmu which emulates old Archimedes in a way that seems good enough to have the original game speed as well as making the video mode working (because it creates a window on top of the desktop).

I have repackaged my games so that they appears as if the game is a regular App for RISC OS 5, aka you can double click on it to launch it. But when you do, instead of running the game on RO 5, it will load ArchiEmu and run the game automatically within the emulator and with the best configuration for the game (some games, for example, runs better on RO 2 which was faster than RO 3, others on ARM2 etc.).

It’s not complicated and generally most games just run fine out of the box, while others need some minor patching.

I do not have permissions to redistribute my own collection, but I am hoping to have enough time to write some article (maybe some video) to help people to make their own re-packaging.

The difference is that while ADFFS runs games super smoothly (which is great), in most cases either video doesn’t work on modern machines/video displays or, if it does, it’s squeezed. So, I decided to go for full emulation using ArchiEmu because of the way ArchiEmu emulates the video preserves the original geometry also on modern displays (just my personal tastes tbh).

All ArchiEmu need to re-package a game is a pre-configured CMOS configuration (I can make this available), a config file (also this is easy to make it available) and then the game disc in ADF format (this is what I don’t have permission to redistribute). Most games will work with just with this, others will need some patching for auto-booting together with RISC OS (Amiga Style basically) and some will need some extra work on the disc image to transform it into a small HD where both (original) discs are present, plus some patching to avoid asking for disc 1 etc. Nothing too complex.

The final touch is to take the old game icon from the original disc and copy it into the App structure of the re-packaged game to make it look like it’s a RO 5 game.

The other advantage of this approach is that, when you’re bored, you just press [ALT] + [END] and you’ll return straight to your RO 5 Desktop (and quit game and ArchiEmu), with all apps you’ve loaded before still running fine and ready to launch the next game or do something else.

I have combined this with my Launchpad software and I have a really nice game collection and launcher and can run all games I want, quit them easly and then launch others. Pretty handy and games run with correct original proportions etc.

Next I wish to add a keys remapper to gamepad module to add some basic gamepad support for all games, configuration will be stored in the ADF image, I just need to find the time to finish this work, right now time for RISC OS is almost 0 :(

Hope this helps,

You can re-package your games

For the games publicly released, you can save yourself a lot of effort by downloading the packaged versions from the JASPP distro site and ensure !ADFFS is run as part of the emulator’s OS !Boot sequence:

If you download the package description file, you can extract the individual package URL’s from it:
https://www.jaspp.org.uk/packages/release

If you have configured the emulator to use the regular filesystem (ie not a HD image but hostfs) then the simplest route is to use PackMan on the host OS and install ADFFS and the games into the emulator hostfs path…then you can keep them up-to-date with PackMan on the host RISC OS. From there you can create the stub app in Apps to launch the emulator and run the individual game, using the !Sprites from the package install.

I’ve packaged 340 games to date, of which around 115 are publicly released. Games that use manual based protection have the protection removed and games that require floppies will auto-mount the floppy image. Admittedly there’s a few games that require floppy swapping, but in most cases I’ve provided an alternative version that is HD based – usually via an SA version.

in most cases either video doesn’t work on modern machines/video displays

The target machines for ADFFS are original Arc’s, RiscPC and Raspberry Pi. On those, most games will display correctly on modern monitors, provided the instructions on the ADFFS download page are followed.

So it’s clear for anyone that hasn’t followed the ADFFS development over the past 13 years, ADFFS is not a machine emulator, it’s closer to a VM as it Hypervises SWI and binary translates CPU instructions via a JIT. Games are running natively on the host machine at near native CPU speed and speed moderated by ADFFS back down to the original game speed. VIDC1/20 video modes are translated to a 24bit equivalent, so the host system must support the resolution at 24bit. ie 320×256×24bit for MODE 13

I’ve never targeted expensive RISC OS machines or the short-run machines that have come out over the years as the Pi is so cheap its not worth the extra effort, not to mention the huge workload it adds to maintaining and testing those machines. It makes more sense to target the Pi and use it as a dedicated games machine.

When testing I use a Pi1 attached to my main TV @ 50Hz, with a wireless Xbox360 controller. This is the kind of target I’m going for.

Where people want to run games on machines that aren’t an Arc, RiscPC or Pi then emulation is the better route, using ADFFS within the emulator.

The other advantage of this approach is that, when you’re bored, you just press [ALT] + [END] and you’ll return straight to your RO 5 Desktop

With ADFFS the key combo is CTRL-SHIFT-F12 to terminate the JIT and return to the RO5 desktop.

Next I wish to add a keys remapper to gamepad module to add some basic gamepad support for all games

If you use the JASPP packaged games or scripts, I’ve added Joystick support to all of them where required. Provided you have a Joystick using the Acorn interface within the emulator it should hopefully map to keys and the mouse as required for each game. That said, I’ve only test Joystick mapping on a Pi so feedback via the JASPP forum might be useful.

Where I’ve not added Joystick mapping to the script, you can add it using the relevant ADFFS *commands. Refer to the “Joystick commands” section in the !ADFFS help file.

You can launch your own game installs using the ADFFS scripts by replacing the !Run contents with *ADFBootFloppy where the ID’s are listed on the Boot script page.
In fact, I’ve switched many of the packages over to use this method to ensure the scripts get updated when ADFFS is updated and avoid unnecessary game package updates.

Is there a link to ArchiEmu anywhere?

Is there a link to ArchiEmu anywhere?

Try http://www.tellima.nl/riscos/

All right started to write a full procedure to create the ArchiEMu based game collection!

@ Jon

thanks for the offer and the details, looking at what I can use from your work!

Quick question: would it be possible to redistribute the re-packaged games using JASPP? Or would it be a problem for you? (I am not a fan of 20 repos for the same kind of stuff, given JASPP is already re-distributing the games, IMHO it may be the right place)

Thanks

@Paolo: Jon has put it better than I ever could… I was going to say that he’s done an absolute mountain of work around packaging games (ADFFS is ‘only’ a part of the project). I’d certainly recommend trying to harness that in some way, and plugging in ArchieEmu. I’m sure you could have some sort of technical solution where a packaged game could be launches via ADFFS or ArchieEmu.

Then again, what is it that ArchieEmu offers over ADFFS? Is it simply compatibility on some slightly obscure RISC OS platforms? (Beagle, Panda, iMX6, PineBook). Perhaps it would be less work to plug the gaps in those areas? Just a thought. Obviously, you can scratch whatever itch you like!

ADFFS is simplicity on a Pi. Run PackMan, and choose some games. It ‘just works’.

@ Richard

Jon has put it better than I ever could… I was going to say that he’s done an absolute mountain of work around packaging games (ADFFS is ‘only’ a part of the project).

Sorry, where anyone here has ever doubted this?

Then again, what is it that ArchieEmu offers over ADFFS?

this: “The target machines for ADFFS are original Arc’s, RiscPC and Raspberry Pi.” Jon’s words.

and besides, also jon’s words: “Where people want to run games on machines that aren’t an Arc, RiscPC or Pi then emulation is the better route,…”

Is it simply compatibility on some slightly obscure RISC OS platforms? (Beagle, Panda, iMX6, PineBook).

Please define “obscure”, you mean something you personally do not own? (Sorry I need to ask, ‘cause here some folks use the language in a way where plural means only one person, not saying it’s your case, but I need to ask now every time). As far as most of us know (where plular here means multiple people in this community), the entire RISC OS community is very small, so technically everything could be classified as “obscure”. Sorry if I may sound pedantic, but we keep ending up using terminology that always end up being ambiguous.

IMHO, the thing is very simple: RISC OS runs on a number of devices, people buy or use what they can/want/can afford and that is all good. Quite a few of these people wish to play some of the games from their youth on whichever RISC OS platform they own. So, whatever makes this simple and easy to use is good, this includes ADFFS (where it works fine) or everything else, so let’s please stop trying to read between the lines (just in case someone is).

On top of that there are both PineBook and PineBook Pro laptops which can’t change video resolution, Raspberry Pis used with 4K Monitors or with monitors that can’t display ADFFS video correctly.

Perhaps it would be less work to plug the gaps in those areas? Just a thought. Obviously, you can scratch whatever itch you like!

To me personally people can do whatever they prefer, not sure why an emulator has to trigger such reactions, ADFFS (if you do not know) works in ArchiEmu, so nothing of Jon’s work would be lost TBH. It’s more a matter of organizing things, for example:

- To avoid having a copy of ADFFS per each game “disc” (disc is between double quotes because obviously the image won’t be a floppy size), then should we create a dedicated configuration that has ADFFS on HostFS and then the game in an image disc?
- Then we can package the game in PackMan and set as dependecy a specific root package that contains ADFFS and whatever other bits is needed

OR

- Is it more manageable if instead we package a copy of ADFFS per game disc so the game is completely indipendent?

Finally, always remember the wise words: If you don’t need it, then don’t use it. It a solution for people that have troubles running ADFFS on their specific device, if you are happy with ADFFS on your Pi, then you don’t have such problem.

Makes sense?

Could try using Aemulor.

[Edit]
Oh dear – it seems to have been spelt that way on several occasions :-(

Any means of a global search and replace?

Amulator

A new emulator solution I don’t know about? Or just a new attempt at creatively spelling “Aemulor”? Or perhaps “Arculator”?

It am an emulator.

That is valid¹, if you’re in the right part of the country they won’t bat an eye at the words, just your pronunciation.

¹ I am, you am, they am, it am – etc.

would it be possible to redistribute the re-packaged games using JASPP?

Why do the games need repackaging?

I am not a fan of 20 repos for the same kind of stuff

Nothing from JASPP can be redistributed, JASPP has rights to distribute the games but not rights to grant distribution to 3rd parties.

“The target machines for ADFFS are original Arc’s, RiscPC and Raspberry Pi.” Jon’s words.

To expand on that statement. Because ADFFS isn’t an emulator, it relies on the underlying machine handling the HAL aspects of the virtual machine.

When running on an Arc, ADFFS purely acts as an ADFS emulator. The 1772 emulator is only used for APD’s, which are binary translated when mounted into JFD’s in memory.

When running on a RiscPC, VIDC1 is translated to VIDC20 and where required games are run under the JIT – either because they’re not StrongARM compatible, or because they expect a specific version of RISC OS. In some cases its just easier to patch games when they’re running under the JIT – for the most part though, I’ve implemented patching in the Boot scripts so they can run natively on an original Arc, particularly where games need bugfixing.

On everything post RiscPC, ADFFS runs games in full Hypervisor mode with all SWI hypervised through to the host OS and IOC/MEMC/VIDC and IOMD translated to a virtual chipset. In the case of VIDC1/VIDC20 the inbuilt GraphicsV driver takes over and presents a virtual VIDC20 to the host OS. Where games require VIDC1, this is translated to the virtual VIDC20.

For sound, ADFFS emulates MEMC DMA but everything else is just passed on to SoundDMA. Where there are difference is sample rate, it will adjust the output sample rate accordingly via a circular buffer.

So…on a “modern machine”, the game sees an IOC or IOMD machine running RISC OS 2.x/3.x and the host OS sees no change other than a new GraphicsV driver taking over that looks like a VIDC20.

Please define “obscure”

“obscure”/“niche”, ie a limited target audience. Its not a derogative term, just the reality that some machines have a really small user base.

On top of that there are both PineBook and PineBook Pro laptops which can’t change video resolution, Raspberry Pis used with 4K Monitors or with monitors that can’t display ADFFS video correctly.

As pointed out previously, ADFFS does not software emulate video, its simply up-bits to 24bit so the host machine/monitor must support the resolution being used, at 24bit.

In the case of the Pi, it has a hardware upscaler that handles upscaling from legacy resolutions to the native monitor resolution. RISC OS unfortunately does not offer a software method to override EDID – which is why ADFFS requires disable_mode_changes in CMDLINE/TXT. Provided CMDLINE/TXT and CONFIG/TXT are configured correctly there should be no video issues on any Pi’s.

In the case of the PineBook, I believe the onboard LCD driver supports only one resolution so software upscaling would be required.

ADFFS does not currently include a software upscaler. It’s on the to-do list, along with CPU paravirtualization.

To avoid having a copy of ADFFS per each game “disc” (disc is between double quotes because obviously the image won’t be a floppy size), then should we create a dedicated configuration that has ADFFS on HostFS and then the game in an image disc?

As detailed above, install ADFFS and the games via PackMan into hostfs. There’s no need to over complicate things with HD images or specific machines for each game. ADFFS will handle the OS version/machine translation within the emulator – just ensure !ADFFS is run in the !Boot Tasks folder as part of the !Boot sequence.

A RiscPC emulator would be preferrable, as that’s the minimum target for the JASPP game packages. As there’s no RiscPC emulator for RISC OS that emulates the chipset accurately, the next best would be an A310 with 4 or 8MB RAM.

Bare in mind that as I’ve yet to write a package manager for RISC OS 3.1x, I’ve not tested any of the packages under RISC OS 3.1×. The majority will work, but a few might fail. I’ve been slowly going through the packages and switching them over to use *ADFBootFloppy to correct that, so if you come across a package that doesn’t work let me know.

Provided you use PackMan, ADFFS and the games will stay up-to-date as I push out updates.

At some point I plan to write a MAME style front-end to ADFFS, which will include a package manager – I could also add a means to launch the games via an emulator.

@Paolo:

Sorry, I think I typed in my message slightly quickly and it may have come across as a bit terse. I did not intend this!

I think ‘obscure’ machines are those with the lowest volumes. So I would consider any Acorn-produced machine (with the possible exception of the A7000, but that’s identical to a Risc PC in terms of software compatibility) to be quite normal/standard, so not obscure (even though they are ancient!). But now we have things like the super-low-cost Raspberry Pi, which has got to be a popular RISC OS machine these days. The serious enthusiasts who can afford to do so may have an iMX6, Titanium or PineBook – but is that as many as have a Pi? Actually, you ask a fair question, and I realise that we don’t really have any numbers, do we? So it’s all guesswork.

There is also a ‘typical RISC OS user’ vs. someone who is interested in ‘retro’ RISC OS games. They could be entirely separate groups. As Jon has alluded to, the simple retro gamer solution is a Pi (I use a Pi1, ModelB+). They are so cheap, you can have it as a dedicated device – maybe even plugged into your TV, rather than on your desk.

For what it’s worth, I’m in total support of what anyone’s doing with RISC OS. People can and should do what they like. As you say, if others like it, then great. If they don’t, then that is fine too. At no point would I want to discourage or criticise anyone’s activities.

I was only drawing attention to Jon’s packages because there is a lot of work there which is already done, so maybe it would save you some effort to harness that. But obviously, this advice is worth exactly what you paid for it. ;)

@ Richard

all good, no worries.

Jon went full on defensive, so there is no more discussion. No idea why he felt he had to do that, probably my English made him feel like there was a threat to ADFFS or something like that. Not even remotely intended. However, I am sure we can find a solution for people that have systems no targetted by ADFFS, so all good :)