Considering all these difficulties, "with almost no restrictions" in the topic seems to be a bit of overstatement. But the matter is interesting, any chance for a practical application (in a preview form at least) any time soon?
Yes, it shouldn't. What I'm seeing in emulation is the firmware jumping through INTINV to reinitialize the interrupt vectors instead of doing a full cold boot of the OS. I haven't looked into it more deeply to figure out what's going on.
The exit through INTINV is supposed to occur only when the OS-es have not been swapped, i.e. the corresponding bit in the MCR did not change.
By the way, that call does not really "reinitialize interrupt vectors", it just (re)enables the NMI.
I wasn't aware that this requirement had been lifted.
Technically it is correct, *if* you want hotswapping, you have to keep one ROM to be an exact copy of the other. Because of the way the board works, it would have to be an ordinary 6502 OS (but not XL OS, which is lacking the 65C816 interrupt services)..
But as the FastROM is not really that fast (IIRC it does not run at 20 MHz, it is 10 or 6.66 MHz), this is not a very attractive approach. It is much better to have an 65C816 OS in the FastROM, and keep the XL OS as an alternative in the motherboard ROM.
Besides, the "original specification" refers mostly to early prototypes. They were lacking the configuration menu, the board was entirely configured using POKEs at SDX CP prompt. One then could think OS hotswapping to be an attractive feature.
I dunno, seems like it'd be pretty cool if you could remove the Rapidus in real life and still have a 65C816....
Well, it may be difficult to implement in the emulator, but in real life it is a pretty cool extension board: no new motherboard needed, no chips reseated, it just goes into the CPU socket plus you have to add three wires, and that is all. Moreover, the CPU does not get interrupted by Antic, when executing code in FastRAM, so you can f.e. easily have both the display enabled and pretty much undisturbed sample replay, which is not the case on the default Altirra emulation (I mean the 65C816 turbo mode).
But, having said that, I must also say that the exact emulation of the Rapidus board is IMHO not really needed unless someone wants to use its very specific features (such as the 16 MB banked SD-RAM). The generic Altirra emulation (65C816 + 21 MHz + 4 MB high RAM) seems in most cases good enough to test programs. Of course, I appreciate the now improved debugger support.
The menu settings are controlled by the PBI #0 module (check PM), without it the configuration will not work.
Also, the Rapidus does not really "stay" in the 6502 mode. When the "Classic" mode is selected and the machine is rebooted, the system starts in 65C816 mode first, then (again, by the PBI #0 code) the 65C816 is halted and the 6502 gets a reset signal and is started.
It is only patched lightly so that when you type DIR in the BASIC XE direct mode, it will display the current disk directory rather than the directory of the D1:
With BASIC XE there are some general problems. The CAR.SAV function does not save its entire memory in the EXTEND mode, for example. It would probably be best to develop a separate command (separate from CAR.COM, that is) which would be used to start BASIC XE and load/save its SAV files, than to embed all this in the CAR.COM command.
SIDE2 build (which was used to program Bits-of-the-past Supercartridges) does not contain code which can correctly handle the pass-through cartridge port. This code was left out because SIDE2 does not contain a pass-through cart port.
This means that it may accidentally work with some cartridges as long as you do not try to do file I/O while in the cartridge... and especially as long as it is not an OSS-supercart, which is banked, and therefore the system has not only to be able to switch it on and off, but also after switching it back on to be able to restore the correct configuration of the banks.
When the code which does that is not there, you will run into mysterious trouble like OP did.
It has been 20 years now since I last used MAC/65 seriously (having switched permanently to MAE), but yes, I seem to vaguely remember that there might indeed be a problem like that.
But even if so, it is MAC/65 fault, probably. If it remembered the initial file position with NOTE, then used POINT to set it back afterwards, such a procedure should work whether the position returned by NOTE is absolute or relative.
Since I am sharing the source code with OP, I can as well share the binary of my PSG player with everyone.
Just please remember that this particular version was never intended to run on anything besides my machine. So apart from Dual Pokey you will need Rapidus Accelerator or (since the program does not really require any CPU clock acceleration) Antonia with my OS. Also, a DOS which supports OSS CLI interface (like SpartaDOS). On Antonia, make "Linear on".
The plus side is that you can load and replay even very large PSG files with it without any conversions. The Cybernoid 2 PSG attached in the post above sounds very well under the player (to my ear, better than under OPs player, but that may be a question of taste).
While working on my Spectrum -> Atari ports, I got interested in playing AY-3-8910 music (Spectrum 128 sound chip, also known as PSG) in ported games. I found an idea for such player developed by drac030 (details in Polish here: http://www.atari.org...p?id=2908&p=2).My player has drac030's idea expanded.
The *_ay.mp3 file is recorded from the original. The corresponding *_pokey.mp3 is the version played on the dual Pokey.
- envelopes from AY are ignored
I have built this player later into Let's Emu!, my ZX Spectrum 48k emulator. Since it cannot occupy the entire CPU time, such emulation is far from being exact, therefore the results very, from quite good to very bad. The biggest loss are the envelopes. In a standalone player you could emulate a wide range of them, though.
Mono has written (but, as far as I know, has not released) a player which is able to synthesize the PSG chip and replay the sound on the available devices (e.g. on a single Pokey, or on a Covox, when available, or so). It also adapts the quality of the synthesis to the CPU speed, so it plays on a stock Atari, but the faster the CPU the result is better (on an Atari with the Rapidus the synth frequency is IIRC up to 64 kHz). If you make some pressure on the author, he might consider officially releasing the program
That is interesting. The ANT program works here with any version of Atari OS (even the 400/800 one), so maybe the 'Byte Eaters Omnimon' ROM is a damaged dump or the OS is incompatible for any other reason. Could you send me (or attach here) a dump of that ROM?
You can recover from this situation by joining together the appropriate jumper (or disjoining it, I do not remember at the moment). This will switch the Antonia ROM to the other half which has been permanently programmed with the regular XL OS. After recovering and switching the ROM slot to something else, you can swap the ROM halves again and reboot.
In meantime, I found a bug in the ANT 1.2, so here is the version 1.3. But I doubt if it would help.