FPEmulator
Re: FPEmulator
In that case, we don't need FPEmulator and I'll remove it. Although ZLib specifies it requires FPEmulator 4.19, it appears to get along fine without it.
Re: FPEmulator
NiceJonAbbott wrote:In that case, we don't need FPEmulator and I'll remove it. Although ZLib specifies it requires FPEmulator 4.19, it appears to get along fine without it.
Reminds me of !SparkFS - it refuses to load if it <System$Dir> isn't set... But simply removing that check from its !Run file and it loads and functions perfectly...
Still we should check it's ok on RO3.1 which has FPE 2.87 in ROM.
Re: FPEmulator
I've haven't been loading FPEmulator for several months and have seen no issues in RO3.1
-
- Posts: 15
- Joined: Wed Jun 12, 2013 9:29 pm
Re: FPEmulator
Hello!
I haven't checked myself, but I suspect the "bad vector release" error when trying to softload FPEmulator on the Pi (or a BeagleBoard/Pandaboard) will be due to a limitation in OS_ClaimProcessorVector/OS_ReleaseProcessorVector. On ARMv6+ machines there'll be two things claiming the undefined instruction vector on startup - FPEmulator and VFPSupport, with FPEmulator being the one that gets in first. Trouble is, once VFPSupport has claimed the vector, VFPSupport is the only one that's allowed to release it - so to replace FPEmulator you need to kill VFPSupport (which will then restore FPEmulator's handler as the current claimant), then kill FPEmulator, and then restart them in whatever order you desire.steve3000 wrote:The old version, v4.31, doesn't seem to quit properly (*RMKill FPEmulator gives 'Bad vector release')
Yes, there are several different builds, each optimised for different OS/CPU versions. The build variants are primarily identified by their suffixes - see coresrc.s.main for a description: http://www.riscosopen.org/viewer/view/m ... v=1.2#l302JonAbbott wrote:Ive just rechecked PlingSystem.zip - there are three different binary versions of FPEmulator:
Yes. I think FPEmulator has been kept out of the RO5 hard disc image so far because (a) it's a bit tricky/dangerous to softload, and (b) it rarely changes. This is the first bug fix for the past three and a half years.JonAbbott wrote:There will be a fourth for RO5, which we don't have. It's not in HardDisc4, so will require a ROM update.
Really? Assuming it's the version I made for ROOL, it should only need FPEmulator 4.03 (as that's a pre-requisite for the CLib version it requires).JonAbbott wrote:Although ZLib specifies it requires FPEmulator 4.19, it appears to get along fine without it.
Re: FPEmulator
Although CLib may require it, it doesn't look like any of the functions I'm using in ZLib actually invoke the FPU...or if they do, they work okay on the original ROM based FPEmulator.Phlamethrower wrote:Really? Assuming it's the version I made for ROOL, it should only need FPEmulator 4.03 (as that's a pre-requisite for the CLib version it requires).JonAbbott wrote:Although ZLib specifies it requires FPEmulator 4.19, it appears to get along fine without it.
I'd prefer not to bundle anything written in C, as getting CLib to update when softloaded without updating !System is fraught with danger. Ideally, I'd like to rewrite ZLib into assembler or at least remove it's dependency on CLib if possible, but it's not very high on the priority list.
The only games I'm aware of to date where CLib is an issue are the Magnetic Scrolls titles: Corruption, The Guild of Thieves, Wonderland and possibly Jinxter and The Pawn.
Fish! doesn't seem to have an issue with the new CLib's, or more correctly, the versions we've received don't (1.08 and 1.10)
Re: FPEmulator
Yes, that'll be it - I knew I'd seen that error before, but it's amazing what you forget in the space of 12 years...Phlamethrower wrote:I haven't checked myself, but I suspect the "bad vector release" error when trying to softload FPEmulator on the Pi (or a BeagleBoard/Pandaboard) will be due to a limitation in OS_ClaimProcessorVector/OS_ReleaseProcessorVector.
Not suggesting you'd do this for FPE / etc, but for those interested, there is method to avoid such exit problems, which I used a lot BITD - although it is rather inelegant... I would set up my module finalisation code so that if OS_ReleaseProcessVector failed, my module would patch over its own vector entry code, with a "MOV PC,R14" instruction, so when the vector entry is called it immediately exits. Then the finalisation code would patch over the module's title with something unique (eg. from 'StevesModule' to 'Exited120553' - with the last 6 numbers being the time), and finally it would exit with V set, so the module remains resident.
This effectively disables the old version while retaining it in memory to avoid problems when the vector entry is called - so you loose some memory until the next reset - but it is successful in allowing new versions to seamlessly load over old version, even when the release fails...
Steve