Symptom:
WHDLoad and Benefactor is properly installed, but game shows corrupt graphics before level title, and crashes on level start (WHDLoad Exception "Access Fault").
Solution:
Add ToolType NOCACHE to program icon.
Amiga computing solutions - networking, graphics, file conversion, system setup, development, ... If you have suggestions, corrections, additions please leave a comment - thanks!
Symptom:
WHDLoad and Benefactor is properly installed, but game shows corrupt graphics before level title, and crashes on level start (WHDLoad Exception "Access Fault").
Solution:
Add ToolType NOCACHE to program icon.
When you want to play OctaMED music in your program, you'll probably want to take a look at the player routines provided by author Teijo Kinnunen, the package can be found here:
https://aminet.net/package/dev/src/OcSS_src
It contains everything required for the developer, including runtime libraries, but to be able to use these a little preparation is required.
vbcc includes a tool named "fd2pragma" that creates the required C include files in a format that's suitable for vbcc. The source file for operations with "fd2pragma" is an "fd" ("file descriptor") file that describes the library in question to the compiler. The result is one or more new C include files that contains the library's function prototypes, and the actual function addresses of the library.
Here's one way to provide the required information to vbcc:
1. The basic command line to create a prototype include file for "medplayer.library" is:
fd2pragma medplayer_lib.fd 70 clib libproto.h
"medplayer_lib.fd" is the fundamental library file descriptor, provided by OcSS_src package.
"libproto.h" is the "template" prototype file, provided by OcSS_src package.
"70" is fd2pragma's SPECIAL value for "vbcc inline prototype" generation - see fd2pragma docs (click "VBCC").
The result of the above commandline is a new file named "medplayer_protos.h" in your current directory.
(Note that there's a deprecated function named "DimOffPlayer()" for which no function prototype will be created, "fd2pragma" gives a warning that can be ignored.)
2. In your program's C code, include "proplayer.h", as suggested by the example code in OcSS_src package. Do not include "libproto.h", but use your newly created "medplayer_protos.h". (Probably after "proplayer.h".)
3. Put a "struct Library *MEDPlayerBase;" somewhere in your program's code.
Now your program should compile with vbcc, and you can use "medplayer.library" like any other AmigaOS runtime library. There are more options to "fd2pragma" and different ways to make it work - see fd2pragma's docs for more information (e.g. in your vbcc package at doc/fd2pragma.guide).
The procedure is the same with "octaplayer.library" and "octamix.library", only the "fd" file to use is "octaplayer_lib.fd" or "octamix_lib.fd", respectively, and the resulting names ("octaplayer_protos.h", "OctaPlayerBase", etc.) are different.
Note that if you want to play different types of OctaMED music (4-channel, 5-8 channel, multichannel-mixing) you can use function "RequiredPlayRoutine()" (medplayer.library) to find out if your program needs to also open octaplayer.library or octamix.library and use different playback functions ("PlayModule8()", "PlayModuleM()").
PiStorm accelerators come with a video driver for the Raspberry Pi's HDMI output, which, if you're booting CaffeineOS, it uses per default.
If you don't have a HDMI display connected, you're stuck a bit, because you can't just run "Screenmode" preferences program without executing S:Startup-sequence, and deleting ENVARC:sys/screenmode.prefs just resets to HDMI, not PAL (or NTSC).
To temporarily select Amiga native video, you can hold the left shift key while booting.
Now you can run "Screenmode" prefs, and save a PAL (or NTSC) screenmode setting.
To permanently select Amiga native video as default and fallback, you can disable PiStorm's HDMI monitor driver "emu68k-videocore", in directory DEVS:Monitors, by moving it to a different location (e.g. a newly created sub-directory, or SYS:Storage/Monitors).
Connecting two Amigas with a RVF Honda "Data Link" cable to play it in two-player mode should be straightforward - but somehow it isn't.
To try to link two Amigas for RVF Honda, you need a proprietary so-called "Data Link" cable, which you'll probably have to build yourself. Click here for more information.
The game's manual says this about the connection:
DATA LINK (SOME VERSIONS ONLY)
If Datalink is implemented on your version of RVF it will appear as the last item on the main menu. Datalink allows two people to race against each other on the same track using two similar computers, connected by a special cable.
HOW TO USE DATALINK
Both computers should be turned off and then joined using the datalink cable. Load RVF into one computer making sure the other is still switched off. Once RVF has loaded, for Datalink purposes this computer will be the master computer, the only one able to make selections from within the Datalink menu. Now turn on the and boot the other computer using the RVF disk, this computer will now be the slave unit, not capable of making selections from within the Datalink menu. Now select Datalink from the main menu on both computers, the master unit will now enable you to select which track you will race on. Pressing the Escape key during a race will exit Datalink Mode.
This sounds clear and easy, but it turns out not every setup works as expected.
From real-life experience, trying to establish the link, here are some notes that might help if you don't succeed on first try:
- "Once RVF has loaded" means "the game has fully loaded", as opposed to just the intro graphics screen with the music. The game has fully loaded when you see the credits screen:
![]() |
| RVF Honda credits screen indicates game is fully loaded |
- You need only one floppy disk. When the game has fully loaded, you can put it into the other (slave) Amiga.
- A (warm) reboot/reset of the slave Amiga won't do, it has to be switched on.
- Successful connections were made using Amiga 500, 600, and 1200 (no other models tested), and a RVF Honda floppy disk.
- No success was achieved with a WHDLoad version of RVF Honda on Amiga 1200, regardless of master or slave, or other Amiga model. (With, or without, Workbench loaded.)
- Amiga 1200 seems to be particularly picky about the connection, the success rate was low. Also it seems an Amiga 1200 (and probably 4000) can't be used as RVF Honda slaves, because when trying to run the game from floppy disk, "Disable CPU Caches" needs to be selected in "Early Startup Menu" for the game to load, altering the power-up init sequence.
- All CPUs and Kickstart versions seem to be allowed.
Overall, establishing the link just appears to be somehow unreliable. Even a tested, unchanged setup sometimes fails to connect. It's still unclear what precisely is happening, and why it's unpredictable - probably only reverse-engineering of the game's machine code will fully explain how to perfectly "data link" two Amigas.
Do you have experience with RVF Honda's "Data Link" connection?
Please leave a comment - corrections, additions are highly appreciated!
Problem symptoms
Solution
That's a bug in older versions of FAT95.
Update FAT95 to the latest version.
https://aminet.net/package/disk/misc/fat95 (currently v3.18)
There is none - it's one and the same.
TAG_DONE and TAG_END are defined as identical clones in NDK2.0:
NDK2.0-4/include/utility/tagitem.h
#define TAG_DONE (0L) /* terminates array of TagItems. ti_Data unused */
#define TAG_END TAG_DONE
NDK3.1 (and higher) has a slightly different definition of TAG_END, but it's still identical:
Includes\&Libs/include_h/utility/tagitem.h
The HippoPlayer.group must match the HippoPlayer executable ("HiP"), meaning it must be taken from the same archive/package/distribution as the executable.
HippoPlayer first looks for HippoPlayer.group file in the executable's directory ("PROGDIR:").
Then it looks for the file in the location given in HippoPlayer's settings (preferences).
If HippoPlayer reports an error with the HippoPlayer.group file, there's either a wrong one in PROGDIR:, or HippoPlayer's settings point to a non-existent, or wrong HippoPlayer.group file elsewhere.
Simplest solution is to just put the correct HippoPlayer.group file into PROGDIR:, and delete HippoPlayer.group files elsewhere.
Files and file sizes, for identification:
Hippoplayer v2.45:
Executable ("HiP"): 89036 Bytes
"HippoPlayer.group": 81954 Bytes
HippoPlayer v2.61:
Executable ("HiP"): 147636 Bytes
"HippoPlayer.group": 258010 Bytes