Archive of FSD files?
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Archive of FSD files?
Hi,
Is there a place where I can grab the archive of FSD protected disc files? I've found a few lying around here and there but I see references in some threads to there being 600+(?!!) of them.
I want to check a broader range of FSD files against an experimental emulator I'm working on. It loads the FSD into an internal representation which is tracks of FM data and I've been able to shoehorn everything in so far.
Cheers
Chris
Is there a place where I can grab the archive of FSD protected disc files? I've found a few lying around here and there but I see references in some threads to there being 600+(?!!) of them.
I want to check a broader range of FSD files against an experimental emulator I'm working on. It loads the FSD into an internal representation which is tracks of FM data and I've been able to shoehorn everything in so far.
Cheers
Chris
- billcarr2005
- Posts: 1840
- Joined: Fri Sep 09, 2005 4:01 pm
- Location: UK
- Contact:
Re: Archive of FSD files?
There are in excess of 1172 images now, but there aren't many "new" forms of protection on the later titles, just variations on a theme.
Off the top of my head, so long as Exile (track IDs not equal), Infinity (different sized sectors), Mini Office 2 (duplicated sector ID), Winter Olympiad '88 (sector overread), Disc Duplicator III (protected in different ways), Krakout (logical track ID isn't at correct physical track, so try the next 2 tracks), Sherston titles (deliberate CRC error) all work, then everything should be fine!
Thanks for taking an interest, I look forward to seeing the results. If you PM me, I can send you some / all as necessary.
Off the top of my head, so long as Exile (track IDs not equal), Infinity (different sized sectors), Mini Office 2 (duplicated sector ID), Winter Olympiad '88 (sector overread), Disc Duplicator III (protected in different ways), Krakout (logical track ID isn't at correct physical track, so try the next 2 tracks), Sherston titles (deliberate CRC error) all work, then everything should be fine!
Thanks for taking an interest, I look forward to seeing the results. If you PM me, I can send you some / all as necessary.
Re: Archive of FSD files?
I have only managed to collect 56 of them myself.
If you are interested in/all any let me know its only 3Mb.
Code: Select all
Directory of F:\BBC\!Images\Discs_pve\Demo Games
29/10/2017 10:23 102,318 Revs Demo.fsd
1 File(s) 102,318 bytes
Directory of F:\BBC\!Images\FSD
11/01/2013 21:56 107,219 003 Mini Office II.fsd
29/11/2012 14:32 35,171 014 Return to Eden.FSD
02/12/2012 01:20 102,399 021 Exile Review Copy.FSD
02/12/2012 04:19 104,947 032 WHITE KNIGHT Mk12.FSD
02/12/2012 20:38 81,667 050 FIRETRACK.FSD
29/11/2012 11:19 55,277 Arcadians 40-80.FSD
29/11/2012 10:47 35,063 Arcadians.FSD
19/12/2014 14:15 82,663 Avon.FSD
20/11/2012 11:08 102,387 EXILE.FSD
21/11/2012 21:41 113,295 INFINITY.FSD
29/11/2012 10:34 55,146 Magic Mushrooms.FSD
19/12/2014 14:17 61,697 Murdac.FSD
28/10/2017 20:14 102,318 Revs Demo.fsd
29/11/2012 18:31 78,570 STARQUAKE.FSD
30/08/2016 21:11 59,717 VECTOR2-140.FSD
15 File(s) 1,177,536 bytes
Directory of F:\BBC\!Images\FSD\AcornSoft
29/11/2012 13:40 101,175 008 Hopper 40-80.FSD
02/12/2012 01:00 102,329 015 Black Box and Gambit.FSD
02/12/2012 01:01 55,282 016 Meteor Mission.FSD
02/12/2012 01:02 55,276 017 Tetrapod.FSD
02/12/2012 01:09 55,275 018 Firebug.FSD
02/12/2012 01:03 55,138 019 Snapper.FSD
02/12/2012 01:03 55,274 020 Drogna.FSD
02/12/2012 04:16 55,270 026 Go.FSD
02/12/2012 04:15 55,272 027 Maze.FSD
02/12/2012 04:17 55,275 028 Quondam.FSD
02/12/2012 04:17 55,275 029 Bouncer.FSD
02/12/2012 04:18 104,934 030 REVS.FSD
02/12/2012 04:19 102,322 031 REVS 4 TRACKS.FSD
02/12/2012 17:28 55,276 034 Monsters.FSD
02/12/2012 18:21 55,275 035 Snooker.FSD
02/12/2012 18:23 101,177 036 Carousel.FSD
02/12/2012 18:25 55,277 037 Free Fall.FSD
02/12/2012 18:27 101,318 038 Crazy Tracer.FSD
02/12/2012 18:29 73,134 039 Kingdom of Hamil.FSD
02/12/2012 18:32 101,185 040 Starship Command.FSD
02/12/2012 18:34 73,495 041 Countdown to Doom.FSD
02/12/2012 19:35 101,181 042 Missile Base.FSD
02/12/2012 19:50 55,287 043 Philosopher's Quest.FSD
02/12/2012 19:53 55,275 044 Aviator.FSD
02/12/2012 19:54 55,284 045 Sphinx Adventure.FSD
02/12/2012 19:58 55,277 046 Planetoid.FSD
02/12/2012 20:00 55,282 047 Super Invaders.FSD
02/12/2012 20:02 55,279 048 Rocket Raid.FSD
02/12/2012 20:44 35,175 051 Colossal Adventure.FSD
02/12/2012 21:42 24,716 053 Super Invaders 40track.FSD
02/12/2012 21:33 24,710 054 Monsters 40track.FSD
02/12/2012 21:40 24,711 055 Planetoid 40track.FSD
29/11/2012 13:31 55,273 Boxer 40-80.FSD
29/11/2012 14:02 55,277 Labyrinth 40-80.FSD
29/11/2012 13:55 24,709 Meteors.FSD
29/11/2012 13:49 55,275 Volcano 40-80.FSD
36 File(s) 2,256,945 bytes
Directory of F:\BBC\!Images\FSD\TyneSoft
04/12/2012 21:35 107,328 013 Winter Olympiad 88.FSD
05/12/2012 02:17 119,005 056 Indoor Sports.FSD
05/12/2012 02:17 116,858 058 BOULDER DASH.FSD
05/12/2012 02:18 118,644 060 SAIGON.FSD
4 File(s) 461,835 bytes
Total Files Listed:
56 File(s) 3,998,634 bytes
Regards Peter.
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Re: Archive of FSD files?
I have all of those working.billcarr2005 wrote: ↑Thu Feb 06, 2020 5:19 pm There are in excess of 1172 images now, but there aren't many "new" forms of protection on the later titles, just variations on a theme.
Off the top of my head, so long as Exile (track IDs not equal), Infinity (different sized sectors), Mini Office 2 (duplicated sector ID), Winter Olympiad '88 (sector overread), Disc Duplicator III (protected in different ways), Krakout (logical track ID isn't at correct physical track, so try the next 2 tracks), Sherston titles (deliberate CRC error) all work, then everything should be fine!
Krakout is interesting -- it seems to be working fine for me without having yet implemented the 8271 quirk of looking forward a couple of tracks if there's a track mismatch.
I did hit something a little related with The Living Daylights. If my emulated seek time was too fast (it used to be instant), my emulated disc won't have rotated past a section of "00" track IDs, and load will fail with a missing sector error. With a correctly emulated seek time, it works
Thanks for your efforts in archiving so many titles. It's definitely a different experience using unmodified original discs so I hope we don't lose that. In case anyone is curious, a couple of screenshots for some of the things you'll never see playing from bbc.godbolt.org or bbcmicro.co.uk:Thanks for taking an interest, I look forward to seeing the results. If you PM me, I can send you some / all as necessary.
- The Micro Power loaders cycle through graphical adverts for their other titles.
- If you mess up copying Disc Duplicator III (or you have an emulator bug like I did) you are treated to a piece of art.
The protected Exile loader also brings back a lot of memories for me. I like how you "see" the unpacker running and resolve the game code and graphics across a couple of passes, because it is operating on screen memory!
Cheers
Chris
Re: Archive of FSD files?
Are these available online? Or do you need someone to host them for you? If the latter, I can do it.billcarr2005 wrote: ↑Thu Feb 06, 2020 5:19 pm There are in excess of 1172 images now, but there aren't many "new" forms of protection on the later titles, just variations on a theme.
Or you could do something similar to what MB does with his disks; just create a thread and post the images!
Rgds
Stephen
Stephen
Re: Archive of FSD files?
Chris, how disk accurate is the internal representation of the fm data? I.e. Is it a bit stream that could be written back to a real floppy?
d.
d.
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Re: Archive of FSD files?
Yes, you should be able to write it back cleanly to a real floppy.
Each track is just 3125 bytes of data and 3125 bytes of FM clock bits. This is similar to the so-called "mid-level" FDI format, which Rich discovered is essentially unused and not even supported by libfdi! In a sense, I'm doing the same job as Rich's fsd2fdi program, just in the context of an emulator.
From what I can tell, billcarr's thorough work doing the FSD archiving hasn't turned up anything which can't be represented in this format, i.e. no fuzzy bits, long tracks or short tracks which were common in the Amiga days. The trickiest protection appears to be Sherston Software. I suspect they use weak bits (as distinct from fuzzy bits) and I'm still looking for some Sherston Software discs to find out for sure. Weak bits can be represented as patches of disc surface with neither data bits nor clock bits, i.e. compatible with the format I'm using.
The main complication I hit is that FSD files often have tracks that declare more than 3125 bytes worth of stuff because of the way sector overread based protection has to be catered for. With a bit of heuristic jiggling, I've got something that handles all of the "tricky" FSD cases documented in other threads.
Did you have a usage in mind other than emulation?
Cheers
Chris
Re: Archive of FSD files?
Yup
Lots of images have been captured as FSD. These days the gold standard should really be to capture them as flux streams and then derive a master descriptor that can be used to recreate that flux stream. If you can successfully recreate that flux stream from the FSDs, then that's brilliant, the FSD becomes that master descriptor: We can use it to create SCP files (which are raw flux timing files and what the GreaseWeazle reads/writes) to put back on to real discs, and also use it to create HFE images which can be used in Gotek emulators and that will therefore behave as the native discs. FSD doesn't really lend itself to that as you'd have to generate the bitstream on the fly.
Incidentally, I have a Sherston archimedes title that I think uses that trick. I can produce a flux dump of it for you to have a look at?
d.
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Re: Archive of FSD files?
So, a question: what level of fidelity to original discs are you looking for? FSD -> FM will produce a close approximation that is good enough to keep the protected loader happy.danielj wrote: ↑Fri Feb 07, 2020 9:16 amYup
Lots of images have been captured as FSD. These days the gold standard should really be to capture them as flux streams and then derive a master descriptor that can be used to recreate that flux stream. If you can successfully recreate that flux stream from the FSDs, then that's brilliant, the FSD becomes that master descriptor: We can use it to create SCP files (which are raw flux timing files and what the GreaseWeazle reads/writes) to put back on to real discs, and also use it to create HFE images which can be used in Gotek emulators and that will therefore behave as the native discs. FSD doesn't really lend itself to that as you'd have to generate the bitstream on the fly.
As one example of where fidelity is lost, consider a normal boring unprotected track of 10 x 256 byte sectors. What format parameters were used for that track for the inter-sector gaps? Both 21 and 16 are common values but the information of which (if either) is lost in FSD. There's potential for information loss in various other scenarios too, such as inter-sector "messages" that are not relevant to copy protection; the FM bytes present in "unreadable" tracks; probably more.
That would be interesting to see but would the Archimedes 3.5" have moved on to MFM? Perhaps that would switch things up. I also don't trust flux dumps as much as I used to, after comparing the drive's analog circuitry output vs. the drive's externally exposed read pin.Incidentally, I have a Sherston archimedes title that I think uses that trick. I can produce a flux dump of it for you to have a look at?
d.
Cheers
Chris
Re: Archive of FSD files?
No, I realise that - ideally we'd have the entire lot captured, interesting intersector gubbins, mastering info on extra tracks, but I fear that's not feasible without re-dumping everything at a lower level. I think having an FM image (e.g. HFE) which is good enough for the original copy protected code to run either from a recreated floppy disc, or from a solid state floppy emulator rather than the cracked versions which circulate would be ideal.scarybeasts wrote: ↑Fri Feb 07, 2020 9:45 am So, a question: what level of fidelity to original discs are you looking for? FSD -> FM will produce a close approximation that is good enough to keep the protected loader happy.
Yes, it had moved to MFM, but it wouldn't surprise me if Sherston were employing the same tricks... Have a word with Flaxcottage and see what he's got knocking about?That would be interesting to see but would the Archimedes 3.5" have moved on to MFM? Perhaps that would switch things up. I also don't trust flux dumps as much as I used to, after comparing the drive's analog circuitry output vs. the drive's externally exposed read pin.
It's degrees isn't it. Ideally you'd tap the analogue signal and record that (c.f. Simon's work on the Domesday system). Certainly for the beeb stuff I'm fairly sure the flux timings are good enough to have a pretty solid idea of what was written.
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Re: Archive of FSD files?
The HFE format looks simple enough. The harder part is parsing FSD files into FM tracks. Spewing out mid-level FDI or HFE or whatever is relatively easy.danielj wrote: ↑Fri Feb 07, 2020 10:31 am No, I realise that - ideally we'd have the entire lot captured, interesting intersector gubbins, mastering info on extra tracks, but I fear that's not feasible without re-dumping everything at a lower level. I think having an FM image (e.g. HFE) which is good enough for the original copy protected code to run either from a recreated floppy disc, or from a solid state floppy emulator rather than the cracked versions which circulate would be ideal.
I must admit, I'm confused as to what format I should support / prefer for FM-level disc images. There are plenty of other historic threads on this forum struggling with the same issue. It'd be great if the BBC community settled on something or another. Do you have any thoughts / recommendations?
Cheers
Chris
Re: Archive of FSD files?
Given that space is rarely an issue these days, I'd argue at the lowest level representation possible.
The SCP format, which is rather smaller than the kryoflux format, runs in at about 40mb/disk, which seems to be overkill, but should be a minimum for preservation. HFEv3 which can represent everything necessary for protected images on almost every platform runs in at about 2mb/disk. It's also the format that the solid state floppy emulators use (HxC/FlashFloppy) when not using sector images. The software preservation society would like you to support IPF, but seeing as FM encoding has never been implemented in IPF, that can probably do one
However, at present everything for the beeb that's commonly available is a cracked version in a sector image format (e.g. SSD/DSD).
I think supporting FSD and HFE should cover everything that might happen. Personally I'd really like to see people moving to SCP/HFE for protected stuff over time, as there's an open source tool chain that can deal with it manipulating it!
d.
The SCP format, which is rather smaller than the kryoflux format, runs in at about 40mb/disk, which seems to be overkill, but should be a minimum for preservation. HFEv3 which can represent everything necessary for protected images on almost every platform runs in at about 2mb/disk. It's also the format that the solid state floppy emulators use (HxC/FlashFloppy) when not using sector images. The software preservation society would like you to support IPF, but seeing as FM encoding has never been implemented in IPF, that can probably do one
However, at present everything for the beeb that's commonly available is a cracked version in a sector image format (e.g. SSD/DSD).
I think supporting FSD and HFE should cover everything that might happen. Personally I'd really like to see people moving to SCP/HFE for protected stuff over time, as there's an open source tool chain that can deal with it manipulating it!
d.
- Rich Talbot-Watkins
- Posts: 2054
- Joined: Thu Jan 13, 2005 5:20 pm
- Location: Palma, Mallorca
- Contact:
Re: Archive of FSD files?
I would actually argue in favour of IPF, simply because it's easier for emulators to consume, leads to smaller files (I still care about that, even if few do), can represent all known forms of 'exotic' disk surfaces, and is quickly establishing itself as a de facto standard. It's a curious omission that FM data isn't apparently supported though (it would have to be flagged as encoder type "undefined").
Re: Archive of FSD files?
It's really not defacto other than in the amiga world - it's not open, and the "owners" won't extend it unless they see fit to. If something is going to be a de-facto standard, it should at the very least have an open toolchain and associated library. Any documentation/understanding around IPF is from having reverse engineered the format, not because the originators deigned it appropriate to release anything publicly other than the CAPS library source. I think you'd have to encode FM as "raw" which really isn't ideal at all...
Anyway, if you run with HFE/SCP and eventually someone extends IPF or creates another format, then it's easy enough to convert to those formats. 2MB for a disk image is about the size of a high density disk image itself, so HFE really isn't excessive. I do agree that having something IPF-like is the ideal solution longer-term, but I think the politics around it need to be bottomed out
d.
Anyway, if you run with HFE/SCP and eventually someone extends IPF or creates another format, then it's easy enough to convert to those formats. 2MB for a disk image is about the size of a high density disk image itself, so HFE really isn't excessive. I do agree that having something IPF-like is the ideal solution longer-term, but I think the politics around it need to be bottomed out
d.
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Re: Archive of FSD files?
This isn't an immediate term offer, as I have some other bugs to fix first -- but if I were to attempt to make an HFE or two, are you set up to test them?
Cheers
Chris
Re: Archive of FSD files?
Yup. Certainly can. Have a look in Kier's github repo - there should be some example HFE code in both disk analyser and greaseweazle.scarybeasts wrote: ↑Fri Feb 07, 2020 11:44 pm
This isn't an immediate term offer, as I have some other bugs to fix first -- but if I were to attempt to make an HFE or two, are you set up to test them?
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Re: Archive of FSD files?
Regarding file size, I'm curious what are your parameters? i.e.Rich Talbot-Watkins wrote: ↑Fri Feb 07, 2020 1:07 pm I would actually argue in favour of IPF, simply because it's easier for emulators to consume, leads to smaller files (I still care about that, even if few do)
- Is it OK if the raw file is big but zips really well?
- Is it OK if the file is reasonably sized, but only on account of some form of compression in the format itself?
(I think I can answer the second question based on previous comments about "eyeballability" and I'd be inclined to agree that it's nice to be able to open up a file in a hex editor and see what is going on.)
Cheers
Chris
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Re: Archive of FSD files?
Thanks. That's a great reference because it shows the v3 format additions in code:
https://github.com/keirf/FlashFloppy/bl ... mage/hfe.c
Without that, most searches for the HFE format tend to end up here which doesn't cover as new a version:
https://hxc2001.com/download/floppy_dri ... format.pdf
I've hit a bit of a wall with some tricky bugs in my video code so maybe I can look more into HFE to take a rest from those
Quick couple of questions in case you knew the answers:
- Do you have any HFE files for BBC discs kicking around? Probably best I start with real examples before I start to try and save my own out out my FM track buffer.
- Do I read the spec right that FM data bits are intermingled with FM clock bits? That's sort of reasonable because that is what is on the disc surface BUT it does break the "eyeballability" requirement of a storage format, as raised by Rich and others. It'd be nice to have a run of FM data bytes separate from a run of FM clock bytes. This would fix eyeballability and likely compress better since the clock bytes will mostly be 0xFF.
- Do I read the spec right that I shouldn't rely on single-sided discs working in common HFE readers? Should I emit a blank upper side for single sided discs, to be safe?
Cheers
Chris
Re: Archive of FSD files?
1. I'll try and get some time today to do it, but you can also make HFEs yourself using the HxC Floppy Emulator software:
http://hxc2001.free.fr/floppy_drive_emu ... l#download
It'll take an SSD/DSD and eject in a variety of formats.
2. Yes - it really is raw in that sense, all the clock bits are there: it's lower level than IPF (but IPF would still have to represent FM at that level as it doesn't specify FM encoding, just MFM).
3. Sometimes single sided HFE images appear as the same image on both sides iirc. It depends on what it is and how it's trying to deal with them. I'll test and see how FlashFloppy deals with both later when I get a mo!
Speaking to Keir yesterday, he was advocating using the SCP format straight, and extending it with some metadata (TBC) about things which would be ambiguous in the flux timings. You could have the original dump, a tidied up version for emulation (these are smaller), and a version suitable for remastering.
http://hxc2001.free.fr/floppy_drive_emu ... l#download
It'll take an SSD/DSD and eject in a variety of formats.
2. Yes - it really is raw in that sense, all the clock bits are there: it's lower level than IPF (but IPF would still have to represent FM at that level as it doesn't specify FM encoding, just MFM).
3. Sometimes single sided HFE images appear as the same image on both sides iirc. It depends on what it is and how it's trying to deal with them. I'll test and see how FlashFloppy deals with both later when I get a mo!
Speaking to Keir yesterday, he was advocating using the SCP format straight, and extending it with some metadata (TBC) about things which would be ambiguous in the flux timings. You could have the original dump, a tidied up version for emulation (these are smaller), and a version suitable for remastering.
- Rich Talbot-Watkins
- Posts: 2054
- Joined: Thu Jan 13, 2005 5:20 pm
- Location: Palma, Mallorca
- Contact:
Re: Archive of FSD files?
Yes I would prefer to de-interleave clock and data bits, for human readability and for greater compressibility too. Whether this were done at the byte level or greater, I don't know. However in a real disk surface, it'll be possible and even likely that the amount of data per track is not a whole number of bytes (considering the end of track padding, and write splices). So in practical terms, perhaps it's not possible to do that, unless you only model an "ideal" disk image with exactly 3125 bytes (FM) or 6250 bytes (MFM).
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Re: Archive of FSD files?
Ah thanks. I can certainly do that myself.danielj wrote: ↑Sat Feb 08, 2020 9:25 am 1. I'll try and get some time today to do it, but you can also make HFEs yourself using the HxC Floppy Emulator software:
http://hxc2001.free.fr/floppy_drive_emu ... l#download
It'll take an SSD/DSD and eject in a variety of formats.
Do you happen to have a setup that can write HFE files back to a real disc? I think it'd be great to close the loop with billcarr's FSD files by recreating actual working protected discs from the FSD. If it works, I'd be happy to attempt a bulk FSD -> HFE conversion if that would be useful.
Cheers
Chris
Re: Archive of FSD files?
Yes, they need converting to a flux format (supercard pro), and then GreaseWeazle can write straight back to disk. The HFE files will also work for anyone who's using gotek floppy emulators with their beeb
d.
d.
Re: Archive of FSD files?
Hi,
Is there a full list of titles that have beeb archived in FSD?
All by BillCarr I am guessing!
Lee
Is there a full list of titles that have beeb archived in FSD?
All by BillCarr I am guessing!
Lee
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Re: Archive of FSD files?
Ok, thanks for your continuing help!
I updated my emulator to use HFE (v1) for its write format for protected discs. So, if you load an FSD, it'll auto-convert it to something it can write -- HFE -- if you select mutable disc files. (Once we verify this is working, a mass / batch conversion could trivially be done via the command line).
I'm attaching 3 ZIP files, each containing a .hfe file. One for Exile (of course! what else (uses 18 sector track with crazy sector ID fields and physical / logical track mismatch), one for Elite (uses unformatted track, and physical / logical track mismatch) and one for Boulderdash (various awesomeness including 5 sector tracks totaling a real 2944 actual data bytes due to close sector packing).
If you could check if any / all of them work a) with Gotek b) written back to a real disc, that'd be awesome. I think the hfe files are mostly ok. I can read them back and load them in my emulator. The HXC floppy emulator command line tools seem happy to convert them to scp. I also converted them from hfe -> hfe3 -> hfe and the resulting file still loads in my emulator.
On the topic of GreaseWeazle, do you happen to know if it works on Linux, and whether there's somewhere I can get a pre-assembled one?
Cheers
Chris
- Attachments
-
- 022 ELITE-SNG38-0.FSD.hfe.zip
- (107.3 KiB) Downloaded 79 times
-
- 058 BOULDER DASH.FSD.hfe.zip
- (46.53 KiB) Downloaded 75 times
-
- 001 EXILE.FSD.hfe.zip
- (138.48 KiB) Downloaded 73 times
Re: Archive of FSD files?
I only have a Master to test on, no real floppy attached at present, but:
Elite works as HFE, Exile works as HFE, Boulderdash fails to load - disk error 18 on catalogue. I've not looked into that any further.
GreaseWeazle. If you can get hold of a bluepill STM32F103 board from bitsbox you can lash it up to a floppy drive using dupont cables as per the instructions in the wiki. For something a bit more robust with some pullup resistors, Keir should have some adaptor board PCBs knocking about still? The version two boards which are self contained using an STM32F730 are being built buy Keir, but there's a big old waiting list forming and things are taking a while to arrive from China at the mo. If you're on facebook join the greaseweazle group?
d.
Elite works as HFE, Exile works as HFE, Boulderdash fails to load - disk error 18 on catalogue. I've not looked into that any further.
GreaseWeazle. If you can get hold of a bluepill STM32F103 board from bitsbox you can lash it up to a floppy drive using dupont cables as per the instructions in the wiki. For something a bit more robust with some pullup resistors, Keir should have some adaptor board PCBs knocking about still? The version two boards which are self contained using an STM32F730 are being built buy Keir, but there's a big old waiting list forming and things are taking a while to arrive from China at the mo. If you're on facebook join the greaseweazle group?
d.
- scarybeasts
- Posts: 1052
- Joined: Tue Feb 06, 2018 7:44 am
- Contact:
Re: Archive of FSD files?
Thanks for testing! Exciting that at least some work.
Boulderdash _does_ have shenanigans on track 0:
chris@chris-ThinkPad-T450s:~/progs/beebjit$ ./beebjit -0 ~/Downloads/IMAGES/FSDs/Tynesoft/058\ BOULDER\ DASH.FSD -log disc:protection
info:disc:FSD: excessive length track 0: 2816
info:disc:FSD: multiple sector read sizes $e1 track 0: 00/00/09/02
info:disc:FSD: non-standard sector count track 1 count 5
info:disc:FSD: excessive length track 1: 2944
[...]
To make the tracks fit, I squish down the various inter- and intra- sector gaps. I suspect I may have overdone it and exceeded some tolerance of the 1770 on the Master. I'm happy to make another attempt if it's of interest to you, or indeed, convert additional FSDs if there are any in particular you'd like to see.
What exact device are you loading the HFEs on to? I may have to investigate getting one.
Cheers
Chris
Re: Archive of FSD files?
It'd be good to get an original disk of boulderdash to see what it looks like in the raw, as it were
I'm using a gotek with flashfloppy (https://github.com/keirf/FlashFloppy/wiki) - gotek = £12, flashfloppy = £0, USB A-A cable to flash the thing = £1.50ish?
You can then pimp it with a rotary encoder and OLED display for probably a total of an extra five or six quid?
d.
I'm using a gotek with flashfloppy (https://github.com/keirf/FlashFloppy/wiki) - gotek = £12, flashfloppy = £0, USB A-A cable to flash the thing = £1.50ish?
You can then pimp it with a rotary encoder and OLED display for probably a total of an extra five or six quid?
d.
- billcarr2005
- Posts: 1840
- Joined: Fri Sep 09, 2005 4:01 pm
- Location: UK
- Contact:
Re: Archive of FSD files?
E1 is the error code for the sector within the FSD meaning that any read other than &100 will result is &0E (Data CRC)scarybeasts wrote: ↑Wed Feb 12, 2020 10:18 am
Boulderdash _does_ have shenanigans on track 0:
chris@chris-ThinkPad-T450s:~/progs/beebjit$ ./beebjit -0 ~/Downloads/IMAGES/FSDs/Tynesoft/058\ BOULDER\ DASH.FSD -log disc:protection
info:disc:FSD: excessive length track 0: 2816
info:disc:FSD: multiple sector read sizes $e1 track 0: 00/00/09/02
info:disc:FSD: non-standard sector count track 1 count 5
info:disc:FSD: excessive length track 1: 2944
[...]
The sector is reported as being &200 in length, but the CRC is correct for &100 of the data
Code: Select all
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
A4 0C 53 45 4B 55 52 45 58 20 50 52 4F 54 45 43
54 49 4F 4E 20 53 59 53 54 45 4D 53 20 27 38 38
2E 20 4E 4F 57 20 54 48 45 52 45 20 41 52 45 20
4E 4F 20 4C 49 4D 49 54 53 2E 54 48 49 53 20 50
52 4F 54 45 43 54 49 4F 4E 20 53 59 53 54 45 4D
28 53 29 20 52 45 41 43 48 45 53 20 54 48 45 20
50 41 52 54 53 20 4F 46 20 54 48 45 20 42 42 43
20 54 48 41 54 20 4E 4F 20 4F 54 48 45 52 20 50
52 4F 54 45 43 54 49 4F 4E 20 53 59 53 54 45 4D
20 43 41 4E 21 FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
SEKUREX PROTECTION SYSTEMS '88. NOW THERE ARE NO LIMITS.THIS PROTECTION SYSTEM(S) REACHES THE PARTS OF THE BBC THAT NO OTHER PROTECTION SYSTEM CAN!
The sector details are as follows
Code: Select all
Date: 4/12/2012
ID: 1
Release #: 58
Title: BOULDER DASH
40 Tracks
Tr.# No.S Sec.# Tr.ID Head# SecID IDsiz REsiz Error
00 0A 00 00 00 00 0100 0100 OK
01 00 00 01 0100 0100 OK
02 00 00 02 0100 0100 OK
03 00 00 03 0100 0100 OK
04 00 00 04 0100 0100 OK
05 00 00 05 0100 0100 OK
06 00 00 06 0100 0100 OK
07 00 00 07 0100 0100 OK
08 00 00 08 0100 0100 OK
09 00 00 09 0200 0200 E1
01 05 00 01 00 00 0400 0400 OK
01 01 00 01 0400 0400 OK
02 01 00 02 0200 0200 OK
03 01 00 03 0100 0100 OK
04 01 00 04 0080 0080 OK
02 05 00 02 00 00 0400 0400 OK
01 02 00 01 0400 0400 OK
02 02 00 02 0200 0200 OK
03 02 00 03 0100 0100 OK
04 02 00 04 0080 0080 OK
03 0A 00 03 00 00 0100 0100 OK
01 03 00 01 0100 0100 OK
02 03 00 02 0100 0100 OK
03 03 00 03 0100 0100 OK
04 03 00 04 0100 0100 OK
05 03 00 05 0100 0100 OK
06 03 00 06 0100 0100 OK
07 03 00 07 0100 0100 OK
08 03 00 08 0100 0100 OK
09 03 00 09 0100 0100 OK
04 05 00 04 00 00 0400 0400 OK
01 04 00 01 0400 0400 OK
02 04 00 02 0200 0200 OK
03 04 00 03 0100 0100 OK
04 04 00 04 0080 0080 OK
05 05 00 05 00 00 0400 0400 OK
01 05 00 01 0400 0400 OK
02 05 00 02 0200 0200 OK
03 05 00 03 0100 0100 OK
04 05 00 04 0080 0080 OK
06 05 00 06 00 00 0400 0400 OK
01 06 00 01 0400 0400 OK
02 06 00 02 0200 0200 OK
03 06 00 03 0100 0100 OK
04 06 00 04 0080 0080 OK
07 05 00 07 00 00 0400 0400 OK
01 07 00 01 0400 0400 OK
02 07 00 02 0200 0200 OK
03 07 00 03 0100 0100 OK
04 07 00 04 0080 0080 OK
08 05 00 08 00 00 0400 0400 OK
01 08 00 01 0400 0400 OK
02 08 00 02 0200 0200 OK
03 08 00 03 0100 0100 OK
04 08 00 04 0080 0080 OK
09 05 00 09 00 00 0400 0400 OK
01 09 00 01 0400 0400 OK
02 09 00 02 0200 0200 OK
03 09 00 03 0100 0100 OK
04 09 00 04 0080 0080 OK
0A 05 00 0A 00 00 0400 0400 OK
01 0A 00 01 0400 0400 OK
02 0A 00 02 0200 0200 OK
03 0A 00 03 0100 0100 OK
04 0A 00 04 0080 0080 OK
0B 05 00 0B 00 00 0400 0400 OK
01 0B 00 01 0400 0400 OK
02 0B 00 02 0200 0200 OK
03 0B 00 03 0100 0100 OK
04 0B 00 04 0080 0080 OK
0C 05 00 0C 00 00 0400 0400 OK
01 0C 00 01 0400 0400 OK
02 0C 00 02 0200 0200 OK
03 0C 00 03 0100 0100 OK
04 0C 00 04 0080 0080 OK
0D 05 00 0D 00 00 0400 0400 OK
01 0D 00 01 0400 0400 OK
02 0D 00 02 0200 0200 OK
03 0D 00 03 0100 0100 OK
04 0D 00 04 0080 0080 OK
0E 05 00 0E 00 00 0400 0400 OK
01 0E 00 01 0400 0400 OK
02 0E 00 02 0200 0200 OK
03 0E 00 03 0100 0100 OK
04 0E 00 04 0080 0080 OK
0F 05 00 0F 00 00 0400 0400 OK
01 0F 00 01 0400 0400 OK
02 0F 00 02 0200 0200 OK
03 0F 00 03 0100 0100 OK
04 0F 00 04 0080 0080 OK
10 05 00 10 00 00 0400 0400 OK
01 10 00 01 0400 0400 OK
02 10 00 02 0200 0200 OK
03 10 00 03 0100 0100 OK
04 10 00 04 0080 0080 OK
11 05 00 11 00 00 0400 0400 OK
01 11 00 01 0400 0400 OK
02 11 00 02 0200 0200 OK
03 11 00 03 0100 0100 OK
04 11 00 04 0080 0080 OK
12 05 00 12 00 00 0400 0400 OK
01 12 00 01 0400 0400 OK
02 12 00 02 0200 0200 OK
03 12 00 03 0100 0100 OK
04 12 00 04 0080 0080 OK
13 05 00 13 00 00 0400 0400 OK
01 13 00 01 0400 0400 OK
02 13 00 02 0200 0200 OK
03 13 00 03 0100 0100 OK
04 13 00 04 0080 0080 OK
14 05 00 14 00 00 0400 0400 OK
01 14 00 01 0400 0400 OK
02 14 00 02 0200 0200 OK
03 14 00 03 0100 0100 OK
04 14 00 04 0080 0080 OK
15 05 00 15 00 00 0400 0400 OK
01 15 00 01 0400 0400 OK
02 15 00 02 0200 0200 OK
03 15 00 03 0100 0100 OK
04 15 00 04 0080 0080 OK
16 05 00 16 00 00 0400 0400 OK
01 16 00 01 0400 0400 OK
02 16 00 02 0200 0200 OK
03 16 00 03 0100 0100 OK
04 16 00 04 0080 0080 OK
17 05 00 17 00 00 0400 0400 OK
01 17 00 01 0400 0400 OK
02 17 00 02 0200 0200 OK
03 17 00 03 0100 0100 OK
04 17 00 04 0080 0080 OK
18 05 00 18 00 00 0400 0400 OK
01 18 00 01 0400 0400 OK
02 18 00 02 0200 0200 OK
03 18 00 03 0100 0100 OK
04 18 00 04 0080 0080 OK
19 05 00 19 00 00 0400 0400 OK
01 19 00 01 0400 0400 OK
02 19 00 02 0200 0200 OK
03 19 00 03 0100 0100 OK
04 19 00 04 0080 0080 OK
1A 05 00 1A 00 00 0400 0400 OK
01 1A 00 01 0400 0400 OK
02 1A 00 02 0200 0200 OK
03 1A 00 03 0100 0100 OK
04 1A 00 04 0080 0080 OK
1B 05 00 1B 00 00 0400 0400 OK
01 1B 00 01 0400 0400 OK
02 1B 00 02 0200 0200 OK
03 1B 00 03 0100 0100 OK
04 1B 00 04 0080 0080 OK
1C 05 00 1C 00 00 0400 0400 OK
01 1C 00 01 0400 0400 OK
02 1C 00 02 0200 0200 OK
03 1C 00 03 0100 0100 OK
04 1C 00 04 0080 0080 OK
1D 05 00 1D 00 00 0400 0400 OK
01 1D 00 01 0400 0400 OK
02 1D 00 02 0200 0200 OK
03 1D 00 03 0100 0100 OK
04 1D 00 04 0080 0080 OK
1E 05 00 1E 00 00 0400 0100 OK
01 1E 00 01 0400 0100 OK
02 1E 00 02 0200 0100 OK
03 1E 00 03 0100 0100 OK
04 1E 00 04 0080 0080 OK
1F 05 00 1F 00 00 0400 0400 OK
01 1F 00 01 0400 0400 OK
02 1F 00 02 0200 0200 OK
03 1F 00 03 0100 0100 OK
04 1F 00 04 0080 0080 OK
20 05 00 20 00 00 0400 0400 OK
01 20 00 01 0400 0400 OK
02 20 00 02 0200 0200 OK
03 20 00 03 0100 0100 OK
04 20 00 04 0080 0080 OK
21 05 00 21 00 00 0400 0400 OK
01 21 00 01 0400 0400 OK
02 21 00 02 0200 0200 OK
03 21 00 03 0100 0100 OK
04 21 00 04 0080 0080 OK
22 05 00 22 00 00 0400 0400 OK
01 22 00 01 0400 0400 OK
02 22 00 02 0200 0200 OK
03 22 00 03 0100 0100 OK
04 22 00 04 0080 0080 OK
23 05 00 23 00 00 0400 0400 OK
01 23 00 01 0400 0400 OK
02 23 00 02 0200 0200 OK
03 23 00 03 0100 0100 OK
04 23 00 04 0080 0080 OK
24 05 00 24 00 00 0400 0400 OK
01 24 00 01 0400 0400 OK
02 24 00 02 0200 0200 OK
03 24 00 03 0100 0100 OK
04 24 00 04 0080 0080 OK
25 05 00 25 00 00 0400 0400 OK
01 25 00 01 0400 0400 OK
02 25 00 02 0200 0200 OK
03 25 00 03 0100 0100 OK
04 25 00 04 0080 0080 OK
26 05 00 26 00 00 0400 0400 OK
01 26 00 01 0400 0400 OK
02 26 00 02 0200 0200 OK
03 26 00 03 0100 0100 OK
04 26 00 04 0080 0080 OK
27 05 00 27 00 00 0400 0400 OK
01 27 00 01 0400 0400 OK
02 27 00 02 0200 0200 OK
03 27 00 03 0100 0100 OK
04 27 00 04 0080 0080 OK
Re: Archive of FSD files?
Yup - here you go:
d.
Can you tell how large the inter-sector gaps are on that?d.
- Rich Talbot-Watkins
- Posts: 2054
- Joined: Thu Jan 13, 2005 5:20 pm
- Location: Palma, Mallorca
- Contact:
Re: Archive of FSD files?
Wow, that Boulderdash format is weird. I just looked to see if there were any way it could fit, and even reducing gaps 1 and 3 to zero, it still needs 3146 bytes. So is data slightly more squeezed together (written at less than 300rpm?) or is the sector actually incomplete?
I guess the different sector sizes mean that it needs a 1770 to write it, and then you can shrink gap 2 as well.Gap1: 0+6
For 9 sectors:For last sector:
- ID: 7
Gap2: 11+6
Data: 259
Gap3: 0+6
-------------
Total: 289Gap4: 0
- ID: 7
Gap2: 11+6
Data: 515
------------
Total: 539
Total: 3146