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. |
| |
|
Trevor Johnson |
Message #119852, posted by trevj at 21:37, 24/3/2012, in reply to message #119850 |
Member
Posts: 660
|
+1
I don't have many old disks or even pre-RPC software but this is brilliant stuff!  |
| |
 [ Log in to reply ] |
| |
|
Martin Bazley |
Message #119853, posted by swirlythingy at 00:01, 25/3/2012, in reply to message #119850 |
Posts: 460
|
I've moaned about the lack of a tool to do exactly this several times in the past on this very forum, so I'd better balance it with: thank you so much for actually stepping up and doing it! |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119862, posted by sirbod at 09:44, 26/3/2012, in reply to message #119841 |
Member
Posts: 563
|
I now have at least four games working: Formula Two Thousand, Last Ninja, Repton 4 and The Wimp Game.
I've also analysed all the APD discs I have, so know what they're looking for. I've also analysed in detail a few. Zarch took my interest, as the size of the APD is disproportionate to the size of the data. The APD needs cleaning up, as the disc itself is 79 tracks of DD and track 80 SD, with three 512 byte sectors - I'll sort that out at some point, as the APD has 160 tracks of both SD and DD in it. I've noticed a few other discs that may need recreating...The Dungeon disc 2 for example, looks like track 21 has some corruption - it could be protection, but it seems odd as it's completely different to disc 1 and has a corrupt sector ID.
Cycloids is an interesting one, as it reads four sectors from track 159 - one of which needs to fail. The problem is, it's ADFS that's generating the error (Bad Parameters), but I can't for the life of me see why - the request looks like a valid read to me, its sector aligned and the sector matches the alternative disc record. I need to debug ADFS to see why it thinks it's a bad request.
I'm having fun with background transfers though, FileCore expects DiscOp's over a certain size to occur in the background...hence the issue I mentioned earlier.
ADFS uses a Floppy FIQ, but as there's no hardware in our case that's not going to work, so I need to find another method to notify FileCore the background transfer completed. I think the reason the machine locks solid after a large transfer is because ironically, something is waiting for the background transfer to complete. It's odd though, as it's a complete lock, mouse and all - as if the processor / MEMC have get into an unknown state.
After FileCore has requested the initial read, I'm guessing it's expecting the DiscOp to return (which I do) and after a certain time period, it's then expecting a call to it's floppy background completion code. Currently I'm doing this before I exit, but I'm guessing FileCore hasn't yet set up the return code, so it doesn't know what to do.
All speculation on my part at the minute, as I've not looked though the FileCore source to see what happens.
So...one possible course of action is to claim the Vsync vector and count down before notifying FileCore. Nasty. For the time being I've turned off background transfers so I can get on with sorting out the ADFS emulation, but it needs sorting as it will impact performance with physical hardware. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #119866, posted by Phlamethrower at 10:40, 26/3/2012, in reply to message #119862 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Cycloids is an interesting one, as it reads four sectors from track 159 - one of which needs to fail. The problem is, it's ADFS that's generating the error (Bad Parameters), but I can't for the life of me see why - the request looks like a valid read to me, its sector aligned and the sector matches the alternative disc record. I need to debug ADFS to see why it thinks it's a bad request. You don't have to worry too much about Cycloids - we've got a copy-protection free version in our free games section.
ADFS uses a Floppy FIQ, but as there's no hardware in our case that's not going to work, so I need to find another method to notify FileCore the background transfer completed. I think the reason the machine locks solid after a large transfer is because ironically, something is waiting for the background transfer to complete. It's odd though, as it's a complete lock, mouse and all - as if the processor / MEMC have get into an unknown state. One of the things I found when tweaking the floppy emulation in ArcEm is that things go tits up if the emulator responds too quickly to read/write commands. It looks like RISC OS relies on a certain amount of time passing between the command request and completion - not a certain number of CPU cycles, as you'd expect if there was some kind of interrupt hole somewhere (i.e. the completion handler not being set up properly as you suggest). I would have expected that to be a bug in ADFS, not FileCore, but if you're having trouble with it then maybe it is a FileCore problem. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119868, posted by sirbod at 11:34, 26/3/2012, in reply to message #119866 |
Member
Posts: 563
|
You don't have to worry too much about Cycloids I still need to cover the disc protection used, but I see what you mean.
One of the things I found when tweaking the floppy emulation in ArcEm is that things go tits up if the emulator responds too quickly to read/write commands. It looks like RISC OS relies on a certain amount of time passing between the command request and completion - not a certain number of CPU cycles, as you'd expect if there was some kind of interrupt hole somewhere (i.e. the completion handler not being set up properly as you suggest). I would have expected that to be a bug in ADFS, not FileCore, but if you're having trouble with it then maybe it is a FileCore problem. I read your note on this a few weeks back, I believe your issue was related to the Floppy FIQ needing time to be setup and then trigger.
Anyhow, I think I just got it working. Seems if I completely ignore the fact it's a background transfer and complete it in the foreground it works. I suspect its related to where the scatter list pointer ends up, if it doesn't end on a 0/0 pair on exit FileCore seems to lock the machine solid. Odd, I'd expect the scatter list on exit to be pointing at the pair following the foreground transfer pair...ie the 2nd pair. PRM2-603 describes background transfer, but doesn't detail where the scatter list should be on exit after the foreground. Trial and error prevail.
[Edited by sirbod at 18:03, 26/3/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119873, posted by sirbod at 07:00, 27/3/2012, in reply to message #119862 |
Member
Posts: 563
|
Hmm, some of the APD's have rotating sectors, ie track 0 has sectors in the order 0,1,2,3,4. Track 1 has sectors in the order 1,2,3,4,0 etc
That's proving to be really tricky to fix, I can't just reorder the sectors as some protection relies on sector within sector. Looking at ADFS, it seems to search the current track for the lowest sector and assume that's the start of the track. This should however break The Dungeon disc 2, as track 21 has corruption on sectors 0 and 1 and would cause them to appear out of sequence.
Before I go any further, I need to analyse that track 21 in detail and try reading it in Arculator to see what ADFS does. It's either a bug in my code, or there's simply no data on it.
I should probably explain that to keep the memory foot-print down, I'm pre-processing the APD into an ADF in memory as its loaded. The only difference being that we now know the track and sector positions and their format status, ie unformatted, SD, DD.
Although I fixed the scatter list on reads, writes now lock the machine solid, so that's another day trying to figure out where FileCore expects the scatter list pointer to end up! It certainly seems to change between a foreground and background transfer - which is what I expected for reads.
Other obstacles to overcome are cleaning up when FileCore kills us. At the moment, if background transfers are enabled, FileCore locks the machine solid soon after removing the FileCore%ADFS instance. I have no idea why, as nothing should be pointing to us.
At some point I need to clear out a lot of code from the Filer. Format for example needs to change, as ADFS is providing that now, we just need to allocate the correct amount of memory first - its already reporting the correct errors if it runs out of disc. Free is redundant and can go, same goes for Eject. I think we just need current disc info, Flush, Save and something to specify the virtual size for ADFS Format to work.
I've yet to look at sector within sector or duplicate sectors, on the latter I think starting the sector search from a different starting position on every read should cover it. Sector within sector, possibly keeping the sector ID in the data and also adding the subsector to the sector table may work. I've yet to analyse the one game that uses it, to see what disc reads it does.
Going to be a while before I have anything for public release.
[Edited by sirbod at 08:04, 27/3/2012] |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #119876, posted by swirlythingy at 13:04, 27/3/2012, in reply to message #119873 |
Posts: 460
|
I know you've probably already done this, but it might be worth downloading the ADFS sources from ROOL and trying to re-implement them as faithfully as possible, undefined behaviours and all.
Although I don't know where that would leave the copyright situation, what with the notorious Castle licence... |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119881, posted by sirbod at 18:40, 27/3/2012, in reply to message #119876 |
Member
Posts: 563
|
I know you've probably already done this, but it might be worth downloading the ADFS sources from ROOL and trying to re-implement them as faithfully as possible, undefined behaviours and all. That's the idea, shouldn't be any copyright issues though as I'm writing from scratch and not copying. It's very hard to follow though, whoever wrote it should be ashamed at their lack of comments! |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119893, posted by sirbod at 23:03, 28/3/2012, in reply to message #119862 |
Member
Posts: 563
|
Gods and World Class Leaderboard are now working.
If anyone has Gods disc 2, the APD looks like a bad dump. Can you verify the disc and if you don't get "Bad Parameters", can you create an ADF of it - it doesn't have any protection.
Drop Ship disc 1 may be bad. If someone can verify the disc and see if it immediately reports "Bad Parameters" as soon as verify starts - I suspect the dump is bad on tracks 0 and possibly 129/130 - although they could be protection.
Same goes for Pandora's Box disc 1, see if you get an immediate "Bad Parameters" on a verify. |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #119895, posted by arawnsley at 10:17, 29/3/2012, in reply to message #119893 |
R-Comp chap
Posts: 600
|
Just out of curiosity, you said this was RO 3.5+ only.
Many of the games were RO3.1 at best, so probably wouldn't be too good on 3.5+
I'd be quite keen to put out something that let you easily play disc images of the old Krisalis titles, but AFAIK the only suitable emulators are RISC OS 3.1 max...? |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #119898, posted by swirlythingy at 13:05, 29/3/2012, in reply to message #119895 |
Posts: 460
|
I'd be quite keen to put out something that let you easily play disc images of the old Krisalis titles, but AFAIK the only suitable emulators are RISC OS 3.1 max...? You've answered your own question.
If you have an emulator then, by definition, you don't need ADFFS to mount a disc image. |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #119900, posted by arawnsley at 13:57, 29/3/2012, in reply to message #119898 |
R-Comp chap
Posts: 600
|
OK, but then do these copy protected images actually work on the RO3.5 machines needed for the reader to work?
For example, would it make sense to include disc images of all the Krisalis games on the Kris Gold CD? |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119901, posted by sirbod at 14:31, 29/3/2012, in reply to message #119895 |
Member
Posts: 563
|
Just out of curiosity, you said this was RO 3.5+ only.
Many of the games were RO3.1 at best, so probably wouldn't be too good on 3.5+
I'd be quite keen to put out something that let you easily play disc images of the old Krisalis titles, but AFAIK the only suitable emulators are RISC OS 3.1 max...? I've just not coded the backward compatibility for the vector handler yet. It should eventually work on RO 3.0+
A lot of games I've seen just have poor !boot loaders that try to play with the memory settings and fail (eg Last Ninja). There are a few that rely on the fixed memory addresses of the A310. eg some expect the screen to be at a certain address.
Name a title, if I can find it, I'll see if its possible to fix at runtime. I need to do something similar to Zarch as it probably wont work on anything post A3xx.
I've been pondering this question for a while, as there's a lot of games that need fixing. I even contemplated a new disc image format to add this kind of post fix-up support - one which doesn't require pre-processing at load time, as APD does. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119902, posted by sirbod at 16:31, 29/3/2012, in reply to message #119893 |
Member
Posts: 563
|
Drop Ship disc 1 may be bad. If someone can verify the disc and see if it immediately reports "Bad Parameters" as soon as verify starts - I suspect the dump is bad on tracks 0 and possibly 129/130 - although they could be protection.
Same goes for Pandora's Box disc 1, see if you get an immediate "Bad Parameters" on a verify. Ignore these two, it seems some extra bits have crept into the header between the sync mark and the ID mark - although that indicates a bad dump, I've worked around it by checking and correcting for them. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119907, posted by sirbod at 12:18, 30/3/2012, in reply to message #119862 |
Member
Posts: 563
|
Made some good progress today, figured out what ADFS is doing for CRC data errors - which has fixed a few more protection methods. Sector within sector is the next thing to fix.
APD working list:
Cycloids
Darkwood
Drop Ship (loads, but does work correctly on RISC OS 3.7)
The Dungeon (loader crashes on RISC OS 3.7)
Formula Two Thousand
Gods (loader crashes on RISC OS 3.7)
Gribbly's Day Out (1.23+) (loader crashes on RISC OS 3.7)
Last Ninja
Magic Pockets (loader crashes on RISC OS 3.7)
Nevryon (loader crashes on RISC OS 3.7)
Populous
Powerband
Repton 3
Repton 4
Sensible Soccer (1.24+) (loader crashes on RISC OS 3.7)
Star Fighter 3000
The Wimp Game
Wolfenstein
World Class Leaderboard
Zarch (RISC OS 3.1 only)
Possibly working, but not RISC OS 3+ compatible:
Pandora's Box (loader crashes on RISC OS 3+)
Known not working:
Fire & Ice (two tracks missing from APD)
Potential game fixes for RISC OS 3.x
Drop Ship
1. !Run2, add "Set Alias$L. LOAD" as the 1st line
2. Replace "RUN <Drop1$Dir>.SetUp" with "RMEnsure MemAlloc RMLoad <ADFFS$Dir>.MemAlloc"
3. Below MemAlloc line add "SpriteSize 100"
The Dungeon
!Run, comment out the line "Run <Obey$Dir>.!Setup"
The Last Ninja
!Run, comment out the line "RUN <Last$Dir>.SetUp
Pandora's Box
1. !Run, comment out the line "*RMclear"
2. Replace "*<Merlin$Dir>.!Setup" with "RMEnsure MemAlloc RMLoad <ADFFS$Dir>.MemAlloc"
3. Below MemAlloc line add "SpriteSize 50"
PowerBand
!Run, add "Set Alias$L. LOAD" as the 1st line
Repton 3
!BOOT add "*DIR ADFS::0.$" as the 1st line
[Edited by sirbod at 23:00, 19/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119949, posted by sirbod at 22:23, 3/4/2012, in reply to message #119907 |
Member
Posts: 563
|
Sensible Soccer
The Dungeon
Gribbly
Magic Pockets Can anyone confirm if any of these work on RISC OS 3.7 / RISC PC - to save me wasting hours debugging the code. |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #119950, posted by swirlythingy at 01:10, 4/4/2012, in reply to message #119949 |
Posts: 460
|
Magic Pockets Can anyone confirm if any of these work on RISC OS 3.7 / RISC PC - to save me wasting hours debugging the code.
I have a copy, which I acquired when my main computer was a RISC OS 3.7 RiscPC, and subsequently played to completion, so it must have worked. Unfortunately, I just tried to play it again for the first time in years, and discovered it doesn't any more! Anyone have any clue why? Maybe there was a patch I installed from somewhere? |
| |
[ Log in to reply ] |
| |
|
Jason Togneri |
Message #119951, posted by filecore at 06:19, 4/4/2012, in reply to message #119950 |
Posts: 3868
|
I have a copy, I just tried to play it again for the first time in years, and discovered it doesn't any more! Anyone have any clue why? I have the same recollection that it works in 3.7, because from about 1998 until 2003, a RO3.7 RPC was my main machine. Have you possibly upgraded processor from ARM710 to StrongARM in that time? A lot of games needed SA-compatibility patches installed. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119952, posted by sirbod at 07:29, 4/4/2012, in reply to message #119951 |
Member
Posts: 563
|
I have a copy, I just tried to play it again for the first time in years, and discovered it doesn't any more! Anyone have any clue why? I have the same recollection that it works in 3.7, because from about 1998 until 2003, a RO3.7 RPC was my main machine. Have you possibly upgraded processor from ARM710 to StrongARM in that time? A lot of games needed SA-compatibility patches installed.
I'll debug the protection then, from the disc reads its certainly getting to the last disc check, then changes video mode and crashes. It must be the protection kicking in, I suspect it's doing it's reads and does the check last.
[Edited by sirbod at 08:47, 4/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jason Togneri |
Message #119953, posted by filecore at 07:38, 4/4/2012, in reply to message #119952 |
Posts: 3868
|
By the way, I saw this article and was amused: Ten... ADF-based inkjet all-in-one printers. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119962, posted by sirbod at 14:31, 4/4/2012, in reply to message #119561 |
Member
Posts: 563
|
Just recoded to use ZLib and hence native APD files. It's too slow to use though, taking 3 minutes to load an APD!
Have some ideas to speed it up, but it's going to need a recode of the APD reader. Fingers crossed, I can get it done today and a public beta out tonight or tomorrow.
EDIT: Spoke too soon, a few minor tweeks have got the load time down to 12 seconds, so should have a beta out later today.
[Edited by sirbod at 16:23, 4/4/2012] |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #119963, posted by swirlythingy at 16:13, 4/4/2012, in reply to message #119951 |
Posts: 460
|
I have a copy, I just tried to play it again for the first time in years, and discovered it doesn't any more! Anyone have any clue why? I have the same recollection that it works in 3.7, because from about 1998 until 2003, a RO3.7 RPC was my main machine. Have you possibly upgraded processor from ARM710 to StrongARM in that time?
Yes, in fact, I have, but from 610, not 710. That's why I deliberately tested it on my other RiscPC, which is currently running on an ARM610 - the exact same ARM610, in fact, which was originally installed in the now-StrongARM RiscPC (it's an old and complicated story). The only difference I can think of is that the 'new' RiscPC now has 32MB of memory, whereas the 'old' one used to have 16.
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.) But even commenting that out in the !Run file, the game locks up after changing mode. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119972, posted by sirbod at 00:24, 5/4/2012, in reply to message #119962 |
Member
Posts: 563
|
v1.17 beta is up: http://adffs.filecore.net
On physical machines, there are some issues, but under emulation it seems to behave itself. Ensure you read the details below before trying this beta.
The app also includes the ZLib module, I'd like to thank Jeffrey for getting that finished so quickly. I believe it's dependent on CLib, but haven't yet included any checks for it before loading ZLib.
On physical machines:
- As ADFFS intercepts ADFS, you may get unexpected results on any discs attached to ADFS after mounting or dismounting an ADF / APD.
- DO NOT attempt to mount a second ADF / APD when one is already mounted - reboot the machine first. ADFS will report issues with your HD if you don't - I'm working on a fix.
- Ensure all files are closed before loading ADFFS, any open files will become invalid otherwise.
- As ADFS is reinitialised whilst ADFFS is loading, you will need to launch the app twice to get the Filer icon. It's not really necessary, ADFFS will work without it.
General issues:
- Runs on RISC OS 3.5+ currently
- ADFFS no longer loads though the !Boot, you must manually load it via the app icon.
- 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.
- Using Save As on an APD file will result in a corrupt ADF file.
[Edited by sirbod at 23:56, 7/4/2012]
Update: 1.18 when released fixes the issues on Physical machines. It's stable enough to go into Pre-desk, avoiding the issues with reinitialising ADFS from the desktop.
1.19 will hopefully provide compatibility back to RISC OS 3.1
[Edited by sirbod at 00:00, 8/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119983, posted by sirbod at 21:23, 5/4/2012, in reply to message #119949 |
Member
Posts: 563
|
If someone has the original disc 1 of Drop Ship, can you check the following directory for me:
$.!Drop Ship.GameDir
Is there a BASIC file in this directory, with a blank filename, that you can't open?
I'm seeing:
<blank file name BASIC file>
DemoData
Font
Mode145
ObjCode
TitleScr
Tuneinfo
It's the same under Arculator. What makes me suspicious is that the HD !Install crashes when it gets to that directory - implying it's either poor coding or a bad dump.
[Edited by sirbod at 23:47, 5/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119986, posted by sirbod at 21:45, 6/4/2012, in reply to message #119950 |
Member
Posts: 563
|
Magic Pockets Can anyone confirm if any of these work on RISC OS 3.7 / RISC PC - to save me wasting hours debugging the code.
I have a copy, which I acquired when my main computer was a RISC OS 3.7 RiscPC, and subsequently played to completion, so it must have worked. Unfortunately, I just tried to play it again for the first time in years, and discovered it doesn't any more! Anyone have any clue why? Maybe there was a patch I installed from somewhere?
Just to add to the confusion, it works under RPCEmu, but an identical !Boot / RISC OS under Red Squirrel or Physical crash. Sounds like a bug in the code to me.
[Edited by sirbod at 23:19, 6/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119991, posted by sirbod at 17:41, 7/4/2012, in reply to message #119907 |
Member
Posts: 563
|
Mixed density support, I have several choices and wonder what other people's opinions on it are. The main issue is with the way it was implemented in APD.
Mixed density within an APD is a bit of a mess at the minute, as the disc is potentially within the image as SD as well as DD and potentially QD in the future. This is fine on a PC where memory is cheap, but on an Arc, it means an image requires up to 4mb.
Ideally an APD should only have SD data where the disc does actually contain SD sectors. This of course requires some knowledge of the disc protection, which is why I suspect it's been implemented the way it has.
Taking Zarch for example, the APD is around 3mb, even though the disc itself has around 600kb contained in 40 tracks of DD and 40 tracks of SD.
Magic Pockets uses the same protection method, but has slightly more data on it.
So, choices are:
1. Tidy up APD's so SD is only present on SD tracks.
Pro: Images will more accurately reflect the actual disc
Pro: images will work in both Arculator and ADFFS
Con: We'll have two versions of the APD floating around
2. Allocate 4mb of ram and hold all three densities.
Pro: APD's remain untouched
Con: restricts the physical hardware it can run on
3. Create a new file format
Pro: Images will load instantly, as they won't have to run though a 1772 emulator during loading
Pro: Can be extended to be multi-disc aware
Pro: Can be extended to add fixes for modern hardware / OS
Pro: Can be extended to allow capturing of most protected floppy disc retaining the protection, natively on the Arc.
Pro: Flush can be made to work on protected discs
Con: Yet another format, which will be specific to ADFFS
Con: Months more programming for me!
To explain how I'm dealing with APD's currently. As the image is read in, the MFM data is passed through a 1772 floppy emulator and the sectors are reconstructed into native data. We end up with a long list of sector headers, pointers to where they start in the raw data, and the data stored in one stream identical to an ADF.
As read/write/verify requests come in, they're split up into a list of sectors, which are then looked up in the sector table and errors or data are returned accordingly.
Essentially it's a ADF with a sector table, which keeps the memory footprint to the bare minimum, ie formatted disc size, plus 20kb for the sector data.
[Edited by sirbod at 23:49, 7/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jason Togneri |
Message #119995, posted by filecore at 06:19, 8/4/2012, in reply to message #119991 |
Posts: 3868
|
1. Tidy up APD's so SD is only present on SD tracks.
Pro: Images will more accurately reflect the actual disc
Pro: images will work in both Arculator and ADFFS
Con: We'll have two versions of the APD floating around I see this as being the lesser of three evils. Two versions of the APD is a small price to pay, in these days when relatively large-capacity CFs can be co-opted as local HDDs. Emulator support is less of an issue, because images should be directly mountable from the host in any event, but accurately reflecting the actual disc is probably more worthwhile from a long-term historical point of view.
2. Allocate 4mb of ram and hold all three densities.
Pro: APD's remain untouched
Con: restricts the physical hardware it can run on In a sense, this isn't an issue either - only on very old hardware, and to some extent, old modules can be found to bulk up those older machines. I don't feel that most people who have anything older than an A5000 will be regularly wanting to mount floppy images in any case (although I'm sure the immediate following responses will disabuse me of this notion). Given the prevelance of RiscPCs and later hardware, I'm sure that this will concern a minority of users at best. I can imagine that a lot of retro-fanatic BeagleBoard/RPi users will want to emulate old floppies but have a lot of hardware resources at their disposal.
3. Create a new file format
Pro: Images will load instantly, as they won't have to run though a 1772 emulator during loading
Pro: Can be extended to be multi-disc aware
Pro: Can be extended to add fixes for modern hardware / OS
Pro: Can be extended to allow capturing of most protected floppy disc retaining the protection, natively on the Arc.
Pro: Flush can be made to work on protected discs
Con: Yet another format, which will be specific to ADFFS
Con: Months more programming for me! Well, since you're filling a largely-untapped area of need in the RISC OS community, I think people could probably accept a new format, and I can certainly see the benefits. Perhaps you could add this as a side-task and eventually implement it in any event, because there are some great advantages there. It's really only because not much has existed here in the past that we're using what we are for disc images. In the long term, this is probably the best solution (especially if you keep up development of ADFFS) but for a shorter-term fix, I'd still probably f for the first option.
Just me two pence  |
| |
[ Log in to reply ] |
| |
|
Blind Moose |
Message #119996, posted by Acornut at 09:27, 8/4/2012, in reply to message #119991 |
 No-eye-deer (No Idea)
Posts: 487
|
I think Jason has put that, very eloquently.
Nicely rational. |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #119997, posted by swirlythingy at 10:10, 8/4/2012, in reply to message #119996 |
Posts: 460
|
I guess it's true - since pretty much nothing can read the formats we already have apart from ADFFS, it can't be much of an issue to have another format which can only be read by ADFFS. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #119998, posted by sirbod at 11:45, 8/4/2012, in reply to message #119997 |
Member
Posts: 563
|
Okay, I'll go for option 1 now, followed by option 3 once I'm at a stable release.
The next question...multi-disc support without option 3. The simplest way for me to code is to rename the files to xxx1, xxx2, xxx3 ... xxx12 and to mount the image based on you pressing a key combination. eg CTRL-ALT-SHIFT-F1 to F12
Anyone have any better ideas?
No idea if I can trap the keys yet, but I would have thought there's a vector for it somewhere - if anyone's has any pointers, it will save me hours of trial and error.
1.18 is now stable on hardware, although for some reason its hanging on scatter list reads - they are a royal pain in the arse! It's working under emulation - no idea why. If anyone's dealt with scatter lists before, help would be welcome.
I'm starting to see other differences between the emulators and physical. Using OS_WriteC for debugging, for example; works fine under emulation, on physical it locks the machine on exit when called under supervisor. No idea why, as they're identical hardware, OS and !Boot.
I'm spending more time testing under physical, Red Squirrel and RPCEmu than coding! Haven't even started any 32 bit testing yet.
Right...going to get scatter reads working, then get 1.18 out for people to play with. That should be the first truly stable release for physical.
[Edited by sirbod at 13:06, 8/4/2012]
Weird, swapped to a different monitor, now WriteC works correctly. And..now that's working, I've discovered why scatter lists are hanging. On physical FileCore is sending a foreground request of 0 bytes - which of course I'm checking for and exiting immediately, I've put way too much error checking in! Might have 1.18 out very soon.
[Edited by sirbod at 13:09, 8/4/2012] |
| |
[ Log in to reply ] |
| |
| Pages (8): |< <
3
> >|
|
The Icon Bar: General: ADF floppy disc image reader |
|
