The Icon Bar: General: ADF floppy disc image reader
| |
ADF floppy disc image reader |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Jon Abbott |
Message #119597, posted by sirbod at 19:20, 15/2/2012, in reply to message #119592 |
Member
Posts: 563
|
This has me intrigued... I don't suppose anyone would be willing to write a short "how to" to transfer stuff (floppies, files) from an old machine to Beagle/ARMini using this?
It'd make for an excellent beginner's guide to cover migration from older kit. I ended up setting up an FTP server to transfer files, its going to be different with every device though. Rough steps are:
1. Create the ADF's, which can be done on RISC OS, or Windows using apps here
2. Image your discs
3. Transfer ADF's to device (via FTP, USB etc)
4. Set the File Type to FCE |
| |
 [ Log in to reply ] |
| |
|
Paul Vernon |
Message #119598, posted by PaulV at 02:32, 16/2/2012, in reply to message #119596 |
Member
Posts: 135
|
Yeah, 4MB and they're maxed out  Still, I can't think of any other machine that can do so much with what is now so little and that is a good thing
Fixing the memory to be released on eject will work well enough for me, I won't be able to run and F size discs from virtual but at least I can extract their content onto the CF card hard drives and run from there instead of having to use Omniflop to write out floppies and then transfer to the Arc's. ADFFS is a boon for that so that so once again, thanks for your work
Paul |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119603, posted by sirbod at 18:11, 19/2/2012, in reply to message #119561 |
Member
Posts: 563
|
v0.83 is now available
A few bugs fixed and flush now releases any allocated memory. Major updates to the filer, most of it is functional; with the exception of the following:
Save As
Free indicator bars
Current format
A few weeks back, I was looking at SoundSynth II and wondering why I wrote a compete WIMP replacement for it. Now I know...god WIMP is so painful to do simple tasks. It's great it you want total control and want to hand code your windows and menus, painful if you want WIMP to handle most of it and are using templates with in directed entries you need to update later. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119606, posted by sirbod at 17:50, 23/2/2012, in reply to message #119561 |
Member
Posts: 563
|
0.85 available
The Filer is almost complete, it just needs the Current Format code adding and the drag/drop improving to show the icon as you drag out to save.
Additions to 0.83:
- Format now sets the disc name to DAY_DD_YY if no name specified
- Save As now implemented in Filer
- Drag/drop onto filer to open implemented
- Free indicator bars implemented |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119616, posted by sirbod at 18:52, 27/2/2012, in reply to message #119561 |
Member
Posts: 563
|
v1.0 now up, feature complete with source code included.
Any issues, let me know. |
| |
[ Log in to reply ] |
| |
|
Michael Drake |
Message #119617, posted by tlsa at 21:44, 27/2/2012, in reply to message #119616 |
Posts: 1097
|
Thanks for the update. It seems to be working fine here.
Is the &fce filetype registered? I ask because ArcEm seems to need the floppy disc images to be in Data format. If &fce is officially registered for ADF disc images, ArcEm should probably support it.
When I Eject a disc from the ADFFS iconbar menu, it doesn't grey out the menu options that require a disc. Maybe it should?
Also, there's no Quit option on the iconbar menu.
Anyway, thanks! It's really handy.  |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119618, posted by sirbod at 11:23, 28/2/2012, in reply to message #119617 |
Member
Posts: 563
|
FCE is the Filecore file type for a floppy disc - as defined by Acorn and used in the disc signature.
You don't actually need to run the Filer to open ADF files. !boot loads the FileCore module which is all you need. The Filer is just a GUI front end for save, flush and eject.
My advise, run the !boot in your startup sequence, set the file types on the floppies and forget about mounting in ArcEm.
Quit will need some major recoding, as the Filer takes over the loading of ADF's when running. This was done to avoid requesting an official SWI block.
Greying out menu options, again lots of code for something even the existing ADFS filer doesn't do. All the options fail cleanly, so it would only be a cosmetic change.
I'll add both suggestions to the wish list. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119623, posted by sirbod at 21:01, 28/2/2012, in reply to message #119617 |
Member
Posts: 563
|
1.01 now available.
Changes:
- Quit option added
- Fixed a bug that would cause RISC OS to hang if the disc format wasn't identified
- D/L format detection changed |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #119625, posted by swirlythingy at 23:05, 28/2/2012, in reply to message #119618 |
Posts: 460
|
Quit will need some major recoding, as the Filer takes over the loading of ADF's when running. This was done to avoid requesting an official SWI block. Just out of interest, why were you so anxious to avoid doing this? |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #119634, posted by Phlamethrower at 13:28, 29/2/2012, in reply to message #119617 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Is the &fce filetype registered? I ask because ArcEm seems to need the floppy disc images to be in Data format. If &fce is officially registered for ADF disc images, ArcEm should probably support it. The fact that ArcEm wants/needs the files to be in data format is probably a bug. |
| |
[ Log in to reply ] |
| |
|
Michael Drake |
Message #119643, posted by tlsa at 18:13, 29/2/2012, in reply to message #119634 |
Posts: 1097
|
I suppose so, I don't think the requirement was documented anyway. |
| |
[ Log in to reply ] |
| |
|
Michael Drake |
Message #119652, posted by tlsa at 13:36, 1/3/2012, in reply to message #119643 |
Posts: 1097
|
Actually, ArcEm does load &FCE typed floppies. I'm not sure what was happening before.
:s |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #119653, posted by Phlamethrower at 14:50, 1/3/2012, in reply to message #119652 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Actually, ArcEm does load &FCE typed floppies. I'm not sure what was happening before.
:s In that case, either the file was open (does ADFFS keep the image files open?), or ArcEm refuses to open image files (remember that RISC OS will only know it's an image file once ADFFS has been loaded) |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119658, posted by sirbod at 17:37, 1/3/2012, in reply to message #119653 |
Member
Posts: 563
|
ADFFS asks RISC OS to load them into memory via OS_File#17.
Whilst testing on emulators, I have noticed that some emulators leave files locked randomly. I'm unsure what the cause is though, I've just noticed it and had to restart the emulator to release the file.
You can test if its the emulator by running:
SYS "OS_Find", 0, 0
... which will close any open files on the current file system. If you still can't rename/delete etc, it's the emulator holding the file open.
Martin - Requesting an SWI block for two modules to do internal communication seemed like a complete waste of an SWI block. If it was public facing SWI's, fair enough. |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #119673, posted by swirlythingy at 18:22, 3/3/2012, in reply to message #119658 |
Posts: 460
|
Version 1.01 is rather badly broken on this StrongARM RiscPC running RISC OS 6.20.
First I tried double-clicking on the !ADFFS application, which placed itself on the icon bar. Then I dragged an ADF file to it, which immediately produced an abort on data transfer, with an address in RMA, and caused the icon to vanish. *Modules revealed that both ADFFS and ADFFSFiler were still loaded.
After that, I tried simply double-clicking on the same ADF file, which successfully mounted it and displayed its contents in a standard Filer window. However, although I was able to navigate the ADF satisfactorily, I started getting persistent errors of "Too long" whenever I tried to do pretty much everything, from attempting to load !SciCalc to opening a directory containing unbooted applications. NetSurf also stopped doing anything useful at all, complaining that it was out of memory whenever I tried to get it to load anything - although it did manage to refresh the ADFFS page (possibly because it's so simple). The Task Manager swore I had 30MB free.
I tried RMKilling first ADFFSFiler and then ADFFS itself, to no avail, and only managed to fix the problem with a reboot. Then I tried double-clicking on the same ADF again, steering well clear of the filer this time, with the same after-effects.
Version 0.7 still works fine.
The ADF I was using is a clone of the original floppy from the Archimedes port of James Pond. It's quite possible it has copy-protection burnt in.
Loath though I am to make such a suggestion in a thread in which David Holden has been known to post, but I could send you a copy if you like? |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #119678, posted by arawnsley at 23:20, 3/3/2012, in reply to message #119673 |
R-Comp chap
Posts: 600
|
Actually JP is one of mine
And, go right ahead - if it helps RISC OS development I'm all for it.
JP was always a bit of a pig to get working properly anyway! I remember it was a right fiddle to get it going on the Krisalis Gold CD that we did, and was probably the fussiest of the lot in terms of timings and screen modes and things. Fun game, though! |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119679, posted by sirbod at 23:32, 3/3/2012, in reply to message #119673 |
Member
Posts: 563
|
If its happening on any ADF, there's no need to send a copy. Feel free to private email me as much info as you can to help reproduce though.
Ironically I'm adding validation checks in 1.02 to try to avoid this sort of issue on protected discs. I've no idea if this will fix your issue though.
One question, is the file path to and including the ADF longer than 255 chars?
[Edited by sirbod at 23:33, 3/3/2012] |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #119682, posted by swirlythingy at 00:00, 4/3/2012, in reply to message #119679 |
Posts: 460
|
If its happening on any ADF, there's no need to send a copy. Feel free to private email me as much info as you can to help reproduce though. Just tried it on a different ADF. Double-clicked on !ADFFS, icon appeared, dragged ADF to icon, abort on data transfer, icon disappeared but both modules still loaded, swiftly followed by a spate of inexplicable "Too long"s. This time, I did a *Where on the address given, which returned offset &938 in module ADFFSFiler.
Have you tested it on any 26-bit hardware? I haven't checked, but it's possible you're assuming the presence of e.g. MSR. I'd test it on this Iyonix, except I'm using it and would like to continue doing so.
One question, is the file path to and including the ADF longer than 255 chars? Not even close - just one directory above the root. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119687, posted by sirbod at 08:47, 4/3/2012, in reply to message #119682 |
Member
Posts: 563
|
I'm developing on a RISC PC, with an ARM 610 and RISC OS 3.7. There's no use of MSR, for backward compatibility I'm using ADDS to set/clear V.
I suspect it's either StrongARM or RISC OS 6.2 related, most likely differences in the later. I'll try to repro on an emulator today.
Update: Dropping ADF files onto the Filer crashes from RISC os 4.02 onward - I'll get this fixed.
I've not managed to reproduce the "Too long" errors though, I suspect they may only happen on 6.20 - which I don't have access too. It may be related to the issue above, so we'll see what happens after that's fixed.
Update 2: See if 1.02 fixes the "Too long" errors
[Edited by sirbod at 16:32, 4/3/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119691, posted by sirbod at 16:31, 4/3/2012, in reply to message #119561 |
Member
Posts: 563
|
1.02 now available
Changes:
- ADF file size limit can now be set in !Boot
- Reports a disc error, if FileCore requests data beyond the size of the ADF file
- Fixed crash when drag/dropping files onto the Filer |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #119694, posted by swirlythingy at 19:20, 4/3/2012, in reply to message #119691 |
Posts: 460
|
1.02 is less unstable, but frustratingly not quite stable. Dragging the James Pond ADF onto the filer seemed to work, so I tried double-clicking on it, which produced the usual unrecoverable 'Too long' errors.
Unfortunately, the bug isn't reproducible any more. After a reset, I tried doing the same again, but I've done several combinations of things now and my computer is still stubbornly in working order. Quitting both filer and FS then restarting and double-clicking on an ADF also doesn't, er, not work.
I'll let you know if I see it again. It is, I suppose, possible that the very first time I did it, I still had the 1.01 module either loaded or specified in an alias.
Just out of interest, what was causing the crash? |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119696, posted by sirbod at 21:17, 4/3/2012, in reply to message #119694 |
Member
Posts: 563
|
Just out of interest, what was causing the crash?
I'd neglected to set up a stack pointer under the RMRun entry - the only code that used the stack was drag/drop into the Filer.
Good to hear it's now working. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119709, posted by sirbod at 19:45, 8/3/2012, in reply to message #119561 |
Member
Posts: 563
|
Quick update. Finally figured out the APD structure and have managed to mount most of the APD's I have.
I'm now looking at taking over ADFS to present the image as ADFS:0, for the copy protection to work. If I succeed, I'll drop ADF: and just hijack :0 when an image is mounted.
I've no idea if any of this will work, at the minute. |
| |
[ Log in to reply ] |
| |
|
Charlie |
Message #119794, posted by Charlie at 22:44, 17/3/2012, in reply to message #119709 |
Member
Posts: 95
|
Just marvelous!
I've only just spotted your thread so haven't tried it yet...
...but as I lack the programming skill to do this myself its something that's been on my wish list for years.
Q. What to do about aging floppies?
A. Convert to .adf (or Tom's .apd format if copy-protected) before bit-rot takes over.
But
That made them all but useless on real machines... until your excellent proggie - especially as it supports .apd's
Even better if it will 'spoof' ADFS::0 - no more issues with software that insists on running from that drive.
You've made me very happy.
If you need help testing (I'm horribly busy) I have a fair old range of 32bit hardware - from boggo A3000's to over the top Kinetic RPC, Omega; OS 2 - OS 6.12
Thanks again.
[Edited by Charlie at 22:49, 17/3/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119809, posted by sirbod at 12:39, 19/3/2012, in reply to message #119794 |
Member
Posts: 563
|
I'm still working on APD support - it's some way off, same goes for ADFS::0
I think I'm okay with the testing, but thanks for the offer. Glad you find it useful. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119841, posted by sirbod at 10:40, 23/3/2012, in reply to message #119561 |
Member
Posts: 563
|
EUREKA!!!
I've managed...after trying five different methods over the past week; to successfully hijack ADFS::0
However, this has brought to light some interesting and somewhat worrying issues which require some re-writing.
The primary issue is that FileCore seems to talk to FileCore%ADFS completely differently to how it talks to all other FileCore modules.
When FileCore talks to FileCore%ADF (the ADFFS FileCore module), it uses physical disc addresses. ie 0 > &C8000 for an 800Kb E floppy
However, when FileCore talks to FileCore%ADFS (ADFS' FileCore module), it passes sector numbers! ie 0 > 4000 for an 800Kb E floppy
My concern is that this could be OS dependent...we'll find out when I release it!
The other big issue is caused when ADFS receives a Module ReInit; it removes the ADFFS module from memory because it thinks it's FileCore%ADFS ... the only thing that comes to mind to work around this, is to create child instances of the ADFFS module with the FileCore code in it. The real problem here is that the SWI vector suddenly points to memory that doesn't exist causing an instant hang - I have to take over the SWI vector, to watch for ADFS creating it's FileCore%ADFS instance.
However...those two issues aside, I can open an ADF and see it appear as ADFS::0, then eject it and see the physical floppy in the drive.
Still lots of coding to do though, as although I can read small files, loading large files causes an instant hang - this is related to the primary issue above, so I think it's fixable. The problem, I believe, is with the returned values; normally after a disc read you'd return the address you finished on. However, as we received a sector, not an address - what do you return when the final address is not on a sector boundary! I need to watch ADFS, before I'll know.
On the APD front, I can load APD's with "in order" sectors, still need to figure an easy way of dealing with "out of order" sectors though. On paper it sounds simple, however as we're dealing with a deflated file its not so easy.
For the time being, I've pre-inflated the APD files as no ZLIB module is available for RISC OS yet (outside of Select), so I'm hoping Jeffrey Lee will have his module available in the coming weeks - to save the big task of writing my own.
I've only managed to load one protected disc though, the issue here is that I'm having to emulate the behaviour of both the 1772 FDC and ADFS - errors and all. It's the errors that are the trouble here, as it's not documented what errors occur when, so I'm having to hack the protection on the discs to see what they expect to happen!
Other issues, loading APD will be slow...~30 secs on an ARM610. As they're not pre-processed I'm having to do it during loading, which is very memory / disc intensive. I've got some ideas to speed it up, but until the ZLIB module is available I can't be certain they'll work.
Finally, ADFFS will only work on RISC OS 3.5+, not sure how much of an issue this will be.
So...in short, I'm making slow progress. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #119843, posted by Phlamethrower at 13:21, 23/3/2012, in reply to message #119841 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
The primary issue is that FileCore seems to talk to FileCore%ADFS completely differently to how it talks to all other FileCore modules.
When FileCore talks to FileCore%ADF (the ADFFS FileCore module), it uses physical disc addresses. ie 0 > &C8000 for an 800Kb E floppy
However, when FileCore talks to FileCore%ADFS (ADFS' FileCore module), it passes sector numbers! ie 0 > 4000 for an 800Kb E floppy This will be down to whether you had the "supports big discs" flag set when you registered with FileCore.
However, as we received a sector, not an address - what do you return when the final address is not on a sector boundary! I need to watch ADFS, before I'll know. I may be wrong, but I think that if you're using sector addresses (i.e. the big disc flag is set) then FileCore will only ever ask you to read/write whole numbers of sectors. It's probably worth checking PRM 5a (Big disc support was added in RISC OS 3.5, IIRC)
For the time being, I've pre-inflated the APD files as no ZLIB module is available for RISC OS yet (outside of Select), so I'm hoping Jeffrey Lee will have his module available in the coming weeks - to save the big task of writing my own. With any luck I'll have a finished/working version of the ZLib module available sometime next week.
To answer one of your questions from earlier - as you've probably worked out by now, there's no way of presenting a virtual floppy controller to RISC OS. ADFS is designed to talk directly to the controller hardware. Some/all versions do issue a service call on startup to find the address of any alternative controller (I think this was to support machines which had the HD/floppy controller on a podule), but since ADFS expects the hardware to generate IRQs and FIQs in the manner real hardware would there's no way you'd be able to point ADFS towards a software emulation of the hardware. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119844, posted by sirbod at 18:40, 23/3/2012, in reply to message #119843 |
Member
Posts: 563
|
This will be down to whether you had the "supports big discs" flag set when you registered with FileCore Ahh! It sounds like I need to support both methods then, thanks for the info.
With any luck I'll have a finished/working version of the ZLib module available sometime next week. Excellent, that will allow me to finish off the APD reader.
To answer one of your questions from earlier - as you've probably worked out by now, there's no way of presenting a virtual floppy controller to RISC OS. ADFS is designed to talk directly to the controller hardware. Yes, I figured that early on after going through adfs15.
The method that worked in the end, was to intercept ADFS creating its FileCore instance, and redirect all calls to drive 0 to my FileCore code. Couldn't be simpler, and watching ADFS format a virtual floppy earlier was good proof that it's likely to work. |
| |
[ Log in to reply ] |
| |
|
antom |
Message #119846, posted by antom at 23:52, 23/3/2012, in reply to message #119844 |
Member
Posts: 37
|
Just logging in to congratulate & you for your sterling efforts so far Jon! Haven't tried it out yet myself but reckon this will be an extremely useful utility.
I've got plenty of games etc, some converted successfully to ADF and others resting on disc until I one day manage to get the necessary kit to create APDs so give me a shout if there's any specific requests for testing etc |
| |
[ Log in to reply ] |
| |
|
Xavier Tardy |
Message #119850, posted by Enzo at 06:48, 24/3/2012, in reply to message #119846 |
Member
Posts: 56
|
Just logging in to congratulate & you for your sterling efforts so far Jon! Haven't tried it out yet myself but reckon this will be an extremely useful utility.
I've got plenty of games etc, some converted successfully to ADF and others resting on disc until I one day manage to get the necessary kit to create APDs so give me a shout if there's any specific requests for testing etc I follow you with the same ideas in mind : hats off to you and thanks a lot. GREAT job ! |
| |
[ Log in to reply ] |
| |
| Pages (8): |< <
2
> >|
|
The Icon Bar: General: ADF floppy disc image reader |
|
