| |
ADF floppy disc image reader |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Jon Abbott |
Message #119999, posted by sirbod at 14:08, 8/4/2012, in reply to message #119561 |
Member
Posts: 563
|
1.18 beta available. It needs thorough testing under the various emulators and physical on both 26/32 bit.
I've done limited testing under RPCEmu 0.89, Red Squirrel 0.6 and a RISC PC, running RISC OS 3.7 with an ARM 610.
All of the hardware related issues from 1.17 have been resolved, however please be aware of the remaining general issues below.
For the list of working APD titles, see message 119907 above.
Known issues:
- Requires RISC OS 3.5+ currently
- Requires an ARM 610+ currently
- ADFFS no longer loads though the !Boot, you must manually load it via the app icon. You can however place a copy of the ADFFS and ZLib modules in !Boot.Choices.Boot.PreDesk to have them loaded as the machine boots (needs testing though)
- Ensure all files are closed before loading ADFFS, any open files will become invalid
- Do not try writing large files (over one sector) to a mounted image, it will lock the machine immediately
- DO NOT attempt to flush an APD file, it will corrupt the original file
- Using Save As on an APD file will result in a corrupt ADF file
[Edited by sirbod at 09:05, 9/4/2012] |
| |
 [ Log in to reply ] |
| |
|
Steffen Huber |
Message #120002, posted by hubersn at 01:07, 9/4/2012, in reply to message #119991 |
Member
Posts: 91
|
Hi Jon,
have you considered supporting IPF as an image format? As far as I know, it is able to support any copy protection on the Amiga, so should cater for our Arc world easily.
The SPS has released the library source code to support IPF recently. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120003, posted by sirbod at 01:37, 9/4/2012, in reply to message #120002 |
Member
Posts: 563
|
I have and raised a ticket with them over a month ago, for sample IPF files to test with.
As yet, I've heard nothing back despite chasing.
If anyone has any IPF's, feel free to send them to me. |
| |
[ Log in to reply ] |
| |
|
Tom Walker |
Message #120011, posted by TomWalker at 09:46, 9/4/2012, in reply to message #120003 |
Member
Posts: 25
|
I've been waiting more than six years for them to send me any sample images, so I wouldn't get your hopes up. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120013, posted by sirbod at 10:15, 9/4/2012, in reply to message #119999 |
Member
Posts: 563
|
Has anyone noticed the Filer not appearing recently?
I'm testing on Arculator for 3.11 support and noticed it doesn't appear on the Icon Bar. So...I went back to the RISC PC and it's stopped appearing there as well - although I've not touched it and it was working yesterday!
The weird thing is, it's working fine under Red Squirrel - identical setup.
RO 3.1 support is mostly there, although for some unknown reason although ADF's load fine, APD's are reporting "Unknown disc"
I've noticed a bug in Arculator...although MSR / MRS are implemented, the immediate form of the instruction seems to have been omitted. I've recoded to work around it. Question for Tom I think (MSR CPSR_flg, #1<<28 - Opcode &E328F201)
Am I correct in believing MSR / MRS are ARM3+ in both register and immediate form? I can't find the detail on the ARM web site.
[Edited by sirbod at 10:16, 9/4/2012]
Add opcode details
[Edited by sirbod at 10:18, 9/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120014, posted by sirbod at 10:25, 9/4/2012, in reply to message #120011 |
Member
Posts: 563
|
I've been waiting more than six years for them to send me any sample images, so I wouldn't get your hopes up. I read your conversation with them online...it made me chuckle 
To be honest, I don't think we'll be implementing it any time soon as I don't see many IPF's ever becoming available.
Did you see my comments about SD / DD mixed APD's earlier in post# 119991. I'd be interested in your thoughts on the way forward.
Oh...and the MSR issue above.
[Edited by sirbod at 10:28, 9/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #120015, posted by Phlamethrower at 10:44, 9/4/2012, in reply to message #120013 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Am I correct in believing MSR / MRS are ARM3+ in both register and immediate form? Incorrect - MSR/MRS are ARMv3+. There's a big difference between ARM3 and ARMv3. Which makes me wonder why it's even implemented in Arculator (They should act as NOPs on older hardware, and require no special code to discard them if the emulator decodes instructions correctly).
On ARMv2 machines (ARM2, ARM250, ARM3) you'll have to use TEQP and friends. There's a good summary of dealing with 26bit PSR manipulation here, along with advice on writing 26/32bit neutral code here.
Also be aware of two nasty processor bugs:
On ARM2, the next instruction that comes after a 'P' instruction will access the banked registers for the previous mode. Instructions which would write to R15 as a whole (MOVS, LDM ^, etc.) aren't affected since they trigger a pipeline flush.
On StrongARMs, a conditional MSR which writes to the c field of the CPSR will execute the following instruction twice if the MSR fails the condition test.
Also you might spot the following on heyrick's page:
When R15 is used as the second operand, all 32 bits are accessible The "second operand" being referred to here is the Rm operand. Typically instructions with 2 operands have the form <op> Rd,Rn,Rm. You'd expect single-operand instructions like MOV to be <op> Rd,Rn, but in reality they're <op> Rd,Rm - so the full PSR is available there as well.
[Edited by Phlamethrower at 10:54, 9/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120017, posted by sirbod at 12:56, 9/4/2012, in reply to message #120015 |
Member
Posts: 563
|
Incorrect - MSR/MRS are ARMv3+. There's a big difference between ARM3 and ARMv3. ...hence the confusion! 
So long as they're NOP's - that should be fine. It just means the flags won't be preserved when it returns to FileCore, which doesn't seem to affect it anyway.
So ... an ARM3 is an ARMv2 and ARM610 is an ARMv3. My head hurts! Thanks for clarifying.
Tom...I retract my previous statement about a bug in Arculator 
Just one bug to fix before 1.19 is out...APD's on RISC OS 3.1 - I'm now certain its a bug in my "non sector mode" FileCore code. |
| |
[ Log in to reply ] |
| |
|
Jason Togneri |
Message #120018, posted by filecore at 13:02, 9/4/2012, in reply to message #120017 |
Posts: 3867
|
So ... an ARM3 is an ARMv2 and ARM610 is an ARMv3. My head hurts! And to further confuse you, although the ARM610 and ARM710 as used in the RiscPC are both ARMv3, the ARM7TDMI is ARMv4T, and the ARM7EJ-S is ARMv5TEJ. Or, as Wikipedia puts it, "The most widely used ARM7 designs implement the ARMv4T architecture, but some implement ARMv3 or ARMv5TEJ." Hooray! |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120021, posted by sirbod at 15:26, 9/4/2012, in reply to message #119561 |
Member
Posts: 563
|
1.19 beta available
For the list of working APD titles, see message 119907 above.
Changes from 1.18
- Now compatible with ARM3+
- Now compatible with RISC OS 3.1+
- Includes all pre-req modules
- Wolfenstein no longer hangs the machine when mounting.
Known issues:
- Writing to a mounted APD image doesn't currently work
- Ensure all files are closed before loading ADFFS, any open files will become invalid
- Do not try writing large files (over one sector) to a mounted image, it will lock the machine immediately
- DO NOT attempt to flush an APD file, it will corrupt the original file
- Using Save As on an APD file will result in a corrupt ADF file
[Edited by sirbod at 18:07, 9/4/2012] |
| |
[ Log in to reply ] |
| |
|
Trevor Johnson |
Message #120024, posted by trevj at 16:18, 9/4/2012, in reply to message #120011 |
Member
Posts: 660
|
Doesn't Dream17 claim to host some IPFs? And what about the sources and HxC stuff? (Sorry if I'm missing the obvious here.) |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120026, posted by sirbod at 17:20, 9/4/2012, in reply to message #120024 |
Member
Posts: 563
|
Doesn't Dream17 claim to host some IPFs? And what about the sources and HxC stuff? (Sorry if I'm missing the obvious here.) I think you're missing the obvious , the source is all well and good - but without Acorn games in IPF, it's impossible to test...and completely pointless. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120027, posted by sirbod at 18:12, 9/4/2012, in reply to message #120021 |
Member
Posts: 563
|
Anyone know if there's a 32bit version of the MemAlloc module available?
A few games use it during their loader, I need to either include a fixed version with ADFFS or code the functionality into ADFFS...or if there's someone willing to assist with rewriting it |
| |
[ Log in to reply ] |
| |
|
Chris Gransden |
Message #120028, posted by grannyg at 18:14, 9/4/2012, in reply to message #120021 |
Member
Posts: 51
|
1.19 works fine on !ArcEm running Risc OS 3.11. |
| |
[ Log in to reply ] |
| |
|
Trevor Johnson |
Message #120030, posted by trevj at 18:26, 9/4/2012, in reply to message #120026 |
Member
Posts: 660
|
missing the obvious Oh well, it's not the first time! |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120031, posted by sirbod at 18:34, 9/4/2012, in reply to message #119561 |
Member
Posts: 563
|
Does anyone have the manual for Premier Manager, so we can check it?
If it does have disc protection (which doesn't look likely), it must happen after the codewheel check.
If someone can test if it works and report back, that would be helpful. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120032, posted by sirbod at 18:37, 9/4/2012, in reply to message #120028 |
Member
Posts: 563
|
1.19 works fine on !ArcEm running Risc OS 3.11. Good to hear, thanks for testing. Please be aware that I've noticed writing to mounted APD's has broken. I'll get it fix for the next release. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #120033, posted by Phlamethrower at 19:06, 9/4/2012, in reply to message #120027 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Anyone know if there's a 32bit version of the MemAlloc module available?
A few games use it during their loader, I need to either include a fixed version with ADFFS or code the functionality into ADFFS...or if there's someone willing to assist with rewriting it I would have thought the bigger issue would be that the game itself most likely isn't 32bit compatible. If you're running on a decent 32bit machine (i.e. Iyonix or faster) then ArcEm is probably your best bet for running old games (although ArcEm's floppy emulation is currently rather poor, and I think the only way of getting the latest version of ArcEm (i.e. one which runs at a usable speed!) is to build it yourself) |
| |
[ Log in to reply ] |
| |
|
Tom Walker |
Message #120034, posted by TomWalker at 21:27, 9/4/2012, in reply to message #120031 |
Member
Posts: 25
|
Does anyone have the manual for Premier Manager, so we can check it? Seems to work okay. The log file with the APD suggests a standard format. |
| |
[ Log in to reply ] |
| |
|
Tom Walker |
Message #120035, posted by TomWalker at 21:32, 9/4/2012, in reply to message #120014 |
Member
Posts: 25
|
Did you see my comments about SD / DD mixed APD's earlier in post# 119991. I'd be interested in your thoughts on the way forward. Option 1 would be preferable. If the APD format needs to be changed then fine - I was going to extend it for the next Arculator version anyway (when/if it ever appears).
I can accept though, that APD isn't especially appropriate for old hardware (and nor is FDI, the only other format protected Arc discs currently exist in). My suggestion, if you were to go for option 3, would be to use a pre-existing format - the extended DSK format, as used by Speccy and CPC stuff, seems a reasonable alternative.
I've noticed a bug in Arculator...although MSR / MRS are implemented, the immediate form of the instruction seems to have been omitted As far as I can remember, both MSR and MRS are implemented as NOPs on v0.99, which is the correct behaviour. Older versions implemented them as undefined traps. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #120036, posted by Phlamethrower at 22:03, 9/4/2012, in reply to message #119963 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Memory can't be ruled out, particularly looking at the awful, evil FreeMem utility, which seems to be assuming an OS_ReadDynamicArea API rather different to the one I'm accustomed to. (Did that SWI used not to return the maximum size in R2? The code only makes sense if it's operating in some parallel universe where R2 is preserved.) The behaviour of OS_ReadDynamicArea has definitely changed a bit over the years, but not in any (major) backwards-incompatible way.
Originally it only returned the address and size in R0 & R1
Then they added the ability to set bit 7 of R0 to return the area max size in R2
Then when the RiscPC came along they made it so that any dynamically allocated areas (i.e. area number &100 and above), or the application slot, will always return the area max size in R2. Requesting info about system DAs will still only return the area size if bit 7 is set. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120037, posted by sirbod at 22:36, 9/4/2012, in reply to message #120035 |
Member
Posts: 563
|
Option 1 would be preferable. If the APD format needs to be changed then fine - I was going to extend it for the next Arculator version anyway (when/if it ever appears). I think APD 1 can remain as is. What were your ideas for extending it?
if you were to go for option 3, would be to use a pre-existing format - the extended DSK format, as used by Speccy and CPC stuff, seems a reasonable alternative. Seems to cover the mixed density okay (although will still need pre-processing in my case), but still leaves us with no multi-disc set support, or patching for older games.
I've noticed a bug in Arculator...although MSR / MRS are implemented, the immediate form of the instruction seems to have been omitted As far as I can remember, both MSR and MRS are implemented as NOPs on v0.99, which is the correct behaviour. Older versions implemented them as undefined traps.
Should the immediate version not be a NOP as well in that case? What does an ARM3 do when it hits an immediate - I don't have one to hand to test. |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #120038, posted by swirlythingy at 00:21, 10/4/2012, in reply to message #120036 |
Posts: 460
|
[Magic Pockets]
Memory can't be ruled out, particularly looking at the awful, evil FreeMem utility, which seems to be assuming an OS_ReadDynamicArea API rather different to the one I'm accustomed to. (Did that SWI used not to return the maximum size in R2? The code only makes sense if it's operating in some parallel universe where R2 is preserved.) The behaviour of OS_ReadDynamicArea has definitely changed a bit over the years, but not in any (major) backwards-incompatible way.
Originally it only returned the address and size in R0 & R1
Then they added the ability to set bit 7 of R0 to return the area max size in R2
That fits in with what I thought it was probably doing (bit 7 isn't set). Considering that it attempts to zero practically everything, except screen memory (which it sets to a fixed 320x256 bytes), I can easily imagine it failing, but it doesn't explain why it would ever work.
Curiously, it works slightly better if I disable the FreeMem utility in the !Run file than if I run the game in its original state. With it enabled, it changes mode then prints a message and locks up. With it disabled, it changes mode, writes something or other to screen memory which is illegible (presumably related to the dynamic area being larger than expected) and flickers (interrupt-driven screen bank switching, I'd wager), and then locks up. Both lockups are unrecoverable, implicating interrupts in some way. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120039, posted by sirbod at 00:35, 10/4/2012, in reply to message #120038 |
Member
Posts: 563
|
Martin - Zarch and Sensible Soccer do the same thing. They all use the R.A.North disc protection, which I suspect might have something to do with it.
They all read in the SD sectors from side 2, then crash, so perhaps it's decoding encrypted data and it's that causing the issue?
I'm just starting to write the FM decoder for SD, so I'll be able to debug it in the coming week(s) and find a solution. |
| |
[ Log in to reply ] |
| |
|
Steffen Huber |
Message #120049, posted by hubersn at 21:26, 10/4/2012, in reply to message #120003 |
Member
Posts: 91
|
I have and raised a ticket with them over a month ago, for sample IPF files to test with.
As yet, I've heard nothing back despite chasing.
If anyone has any IPF's, feel free to send them to me. I do have KryoFlux hardware here, and some Acorn discs as well (maybe 20 or 25 games).
Don't know when I will get the time to image those floppies though...don't hold your breath.
Steffen |
| |
[ Log in to reply ] |
| |
|
Holger Palmroth |
Message #120050, posted by Raeddie at 21:31, 10/4/2012, in reply to message #120003 |
Member
Posts: 58
|
Maybe you could get some help regarding IPF in the forums (http://forum.kryoflux.com/) for the KryoFlux Controller: http://www.kryoflux.com/ |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120051, posted by sirbod at 01:39, 11/4/2012, in reply to message #120039 |
Member
Posts: 563
|
I now have Zarch loading on 1.20, debugging the code it tries to write 0's from &1FED400 to &2000000 - which doesn't exist.
Anyone know what that range is on an A310? Screen would be the obvious one (320 x 256 with 16 lines not touched) |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #120052, posted by swirlythingy at 02:26, 11/4/2012, in reply to message #120051 |
Posts: 460
|
I now have Zarch loading on 1.20, debugging the code it tries to write 0's from &1FED400 to &2000000 - which doesn't exist. Eep!
"Pass me a pickaxe..." |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120053, posted by sirbod at 08:56, 11/4/2012, in reply to message #120037 |
Member
Posts: 563
|
if you were to go for option 3, would be to use a pre-existing format - the extended DSK format, as used by Speccy and CPC stuff, seems a reasonable alternative. Seems to cover the mixed density okay (although will still need pre-processing in my case), but still leaves us with no multi-disc set support, or patching for older games.
On second thoughts I don't think DSK will work for discs using the R.A.North protection, which has mixed SD and DD sectors within Track 40 Head 0. I suppose you could put two Track 40's in, but it would break the Track Offset table.
We could suggest an extension I suppose.
On the multi-disc / patching, we could use an external wrapper to it (zip?) and embed delta changes for patches (in the same disc image format) / other disc images for multi-disc. We'd probably need a descriptor file, as the patching may need to be hardware / OS specific and we'd probably want disc titles and game instructions / notes.
Still leaves me with lots of coding though, as to reduce the memory footprint, I need to pre-process the MFM/FM back into raw data during loading. Even if I took 4mb RAM and processed at run time during the DiscOp, I'd still need the 1772 emulator - which is a big chunk on slow code.
Ideally, I need raw pre-processed data with a track/sector table. Quick to load and lowest memory usage, leaving me with only an ADFS emulator.
The final alternative for me, is to not load the file into memory and read from disc at run time - I don't believe FileCore is re-entrant though, which would knock that idea on the head.
EDIT: One question, the DSK standard doc doesn't mention if the data is in raw or FM/MFM encoding, I've assumed the latter. If its the former, it's ideal if we can extend the sector table to include density on each sector.
EDIT2: I also presume we're talking about the extended version of DSK, as the standard form has far too many deficiencies.
[Edited by sirbod at 13:32, 11/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #120054, posted by Phlamethrower at 09:04, 11/4/2012, in reply to message #120051 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I now have Zarch loading on 1.20, debugging the code it tries to write 0's from &1FED400 to &2000000 - which doesn't exist.
Anyone know what that range is on an A310? Screen would be the obvious one (320 x 256 with 16 lines not touched) Yes, that'll be screen memory. |
| |
[ Log in to reply ] |
| |
| Pages (8): |< <
4
> >|
|
