Creating SSD/DSD images

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Creating SSD/DSD images

Post by MartinB » Sat Sep 25, 2010 10:57 pm

For my transfer project, I'm going to write a couple of utilities to allow a real floppy to be imaged and uploaded to a PC. Now, I'm fine with the process of creating the image (interleaved/non-interleaved etc.) and have already written several utilities to convert images back to real discs. However, I've never yet written a disc-to-image routine and there's one aspect that I'm unclear about...

I notice that SSD and DSD images vary in size which is of course a reflection of the quantity of data actually on the originally imaged disc. My question then is how does one determine precisely where the last used sector occurs for imaging purposes? If a disc is fragmented (I know that individual files won't be but the free space may well be) then there could be say four files at the low sectors, a stack of free space and then one file at the end of the disc. I presume that discs are not always *COMPACTed first as this could interfere with software which might directly access specific sectors? (DFS only btw - not interested in ADFS at this time.)

So, what's the process used to determine the last sector to be imaged and hence determine the size of the overall image? I assume it will be something along the lines of the assembler equivalent of a *I.* and then the last sector is calculated from the start sector of the highest file plus it's length? Anyone have experience in this area and can shed some light?

User avatar
SarahWalker
Posts: 1207
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: Creating SSD/DSD images

Post by SarahWalker » Sat Sep 25, 2010 11:02 pm

I don't think anyone bothers with determining last sectors anymore, certainly both B-em and Beebem just store the full size of the disc.

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Sat Sep 25, 2010 11:05 pm

Really? So always 100/200/400k then? That sounds way too easy :D

User avatar
tautology
Posts: 389
Joined: Wed Sep 01, 2010 2:26 pm
Contact:

Re: Creating SSD/DSD images

Post by tautology » Sun Sep 26, 2010 12:14 am

I wrote a .ssd reader around 1999, when I could find very few utilities to manipulate the files, my notes are below.

As to work out maximum space, minus the slack space. Scan track 0, sector 1 to find the file with the largest start sector (just look at each 0xf byte), then add on file space and round to the nearest sector (size 256 bytes) and you're done.

Code: Select all

BBC DFS Disc format
===================

This document is being written mainly because no other bugger has and I spent
a long time working out the details!

Even still it is not complete, so if anybody can comment on the last few
details I'd be grateful...

General Format
--------------
Like all other disc systems, Acorn DFS is divided up into tracks and sectors.

No matter how many tracks are present (80 or 40 usually!) each track consists
of 10 sectors, each sector being 256 bytes.

Catalogue
---------
The DFS is catalogue is in two parts, each taking up a sector.

First, at track 0, sector 0 we have the names sector, which consists of:
 byte  usage
 0-7   first part of disc title
 8-e   first file name (padded out with NULs)
   f   directory for first file 
 ...
 f8-fe 31st file name
     f 31st directory

From this one can see why there is the infamous 31 file limit on DFS discs -
1 sector = 256 bytes at 8 bytes per filename = 32 files 
- 1 for the title = 31 files.

Then at track 0 sector 1 we have the file information table:
  byte  usage
  0-3   End of the disc title
    4   Access count (a number which just cycles round!)
    5   Top five bits are the number of files on the disc
    6   Top nyble is the boot option (1,2 or 3)
        Bottom nyble is the High value for sectors on disc
    7   Low value for number of sectors on disc
  8-9   Load address of first file
  a-b   Execute address of first file
  c-d   File size of first file
    e   Strange byte of first file
        this seems to be divided into pairs of bits:
        bit    usage (?)
        0-1    high bits of executable address
        2-3    high bits of file size
        4-5    high bits of load address
        6-7    high bits of Start sector
    f   start sector of first file
  ...
  
From this we can see that the title can be up to 12 bytes, load and exec
can range up to &2ffff, and the maximum file size is &2ffff bytes.

Also DFS can only handle a maximum of &fff sectors on the disc.

The start sector address is an absolute address of the sector, one can get
the track and sector value from it by using:
   track=start_sector / 10
   sector=start_sector % 10

Files
=====
The easy bit :-). Files are stored, sequentially from the start_sector, 'til
they end... All rounded up to the nearest sector. So we could just load it
in, for example C by doing:
   fseek(inhandle,start_sector*256,SEEK_SET);
   fread(filebuf,file_size,1,inhandle);

User avatar
Samwise
Site Admin
Posts: 1820
Joined: Mon Mar 14, 2005 9:13 pm
Contact:

Re: Creating SSD/DSD images

Post by Samwise » Sun Sep 26, 2010 1:01 pm

Things have progressed a bit since 1999. :) JGH's writeup is pretty comprehensive and covers many flavours of DFS:

http://mdfs.net/Docs/Comp/Disk/Format/DFS

Sam.

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Sun Sep 26, 2010 1:45 pm

Thanks tautology and Samwise - I am familiar with the catalogue layouts and structure of the disc etc. but I was just wondering if there was perhaps an OSWORD call or similar trick that I'd missed which might return the address of the next free sector. It sounds though as if it is indeed a case of coding what I would do manually if I want to produce variable size images.

I realise that it's just as easy to produce full-size images these days since 100-400k is hardly significant but in terms of uploading from a real disc in a Beeb to a PC, it does affect the transfer time since every sector will still have to be physically read before uploading.

Hmm.., I will decide which is the better compromise but I think I still favour only imaging the used portion of the disc :-k

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Sun Sep 26, 2010 6:58 pm

This does the trick for Acorn 8271 and 1770 DFS :D

Code: Select all

   10 REM * SHOW END DISC SECTOR *
   20 *.
   30 SS=((?&F0E AND 3)*256)+?&F0F
   40 LS=((?&F0D*256)+?&F0C)+SS-1
   50 PRINT
   60 PRINT"Last sector in use is ";~LS
It's harder to write in Basic than it is in assembler :roll:

Performing a *. makes the DFS do all the work for you and then it's just a case of grabbing the necessary info from the top entry of the already start_sector_ordered data block.

Come on then someone, blow a big hole in it...... 8-[

User avatar
tautology
Posts: 389
Joined: Wed Sep 01, 2010 2:26 pm
Contact:

Re: Creating SSD/DSD images

Post by tautology » Sun Sep 26, 2010 8:50 pm

Samwise wrote:Things have progressed a bit since 1999. :) JGH's writeup is pretty comprehensive and covers many flavours of DFS:

http://mdfs.net/Docs/Comp/Disk/Format/DFS
That's why I stopped using my code :-)

User avatar
retroclinic
Posts: 3032
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Creating SSD/DSD images

Post by retroclinic » Sun Sep 26, 2010 8:59 pm

That just tells you the length of the first file doesn't it?

It's been a while since I did this, but this is the code used in RamFS to get the sector and file data from a dfs disc. Substitute the references for &FDxx with &0Fxx, as RamFS uses it's own private workspace.

Code: Select all

\** Read Used and Free space
\** On entry, &CF = Drive to examine
\** On exit, zpm0 & zpm1 = used number of sectors
\** zpm2 & zpm3 = free number of sectors
\** A = Number of used filenames
\
.readUF		JSR loadCAT
		LDA #&02			;Catalog takes up 2 sectors
		STA zpm0
		LDA #&00
		STA zpm1
		JSR set0F
		LDX &FD05			;Get number of files
		BEQ readUF_X
		
.readUF_1	LDA &FD05,X
		CLC
		ADC zpm0
		STA zpm0
		PHP
		LDA &FD06,X
		JSR mLSR4_AND3
		PLP
		ADC zpm1
		STA zpm1
		LDA &FD04,X
		BEQ readUF_2
		INC zpm0
		BNE readUF_2
		INC zpm1
		
.readUF_2	TXA
		SEC
		SBC #&08
		TAX
		CMP #&08
		BCS readUF_1		
		
.readUF_X	LDA &FD07
		SEC
		SBC zpm0
		STA zpm2
		PHP
		LDA &FD06
		AND #&03
		PLP
		SBC zpm1
		STA zpm3
		LDA &FD05			;Get number of files
		JMP mLSR3			;Divide by 8

.mLSR4_AND3	LSR A				;LSR A * 4, then AND &03
		LSR A

.mLSR2_AND3	LSR A				;LSR A * 2, then AND &03
		LSR A
		AND #&03
		RTS

.mLSR3		LSR A
		LSR A
		LSR A
		RTS
Mark.
Image

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Sun Sep 26, 2010 9:12 pm

retroclinic wrote:That just tells you the length of the first file doesn't it?
Not sure why you think that? I've just been testing it to death in BeebEm and it works a treat. It actually adds the length of the last file to it's start sector and Fanny's yer Aunt :D

I could supress the output of the *. but it's actually gonna be kind of a nice touch in that you see a cat of the disc followed by a GO (Y/N)? prompt before the upload proceeds.

Please feel free to try it yourself (or anyone?), I'd welcome a third-party test :wink:

(The released utility will be in assembler btw, the Basic was just for a quick test.)

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Sun Sep 26, 2010 9:53 pm

Actually no, it's not quite right, I've missed a x256 because I'm adding bytes to sectors which are of course 256 bytes. Wait one...

User avatar
retroclinic
Posts: 3032
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Creating SSD/DSD images

Post by retroclinic » Sun Sep 26, 2010 9:54 pm

EDIT: Okay, we posted together, I'll wait for your fix.

The RamFS code (which is the same was DFS does it), works by going through the directory adding up the file sizes of each file ignoring the least significant 8 bits, that gives the number of used sectors. I'm not sure there's a way of doing it with a simple few byte reads? If there is, I can optimise that bit of code next time round.

Mark.
Last edited by retroclinic on Sun Sep 26, 2010 10:01 pm, edited 1 time in total.
Image

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Sun Sep 26, 2010 9:59 pm

Code: Select all

   10 REM * SHOW END DISC SECTOR *
   20 *.
   30 SS=((?&F0E AND 3)*256)+?&F0F
   40 LS=?&F0D+SS
   50 PRINT
   60 PRINT"Last sector in use is ";~LS
There we go, even simpler :D

Yeah, I was actually testing the above (in assembler) but failed miserably to port it Basic!

Notice I just deleted the -1 too to cater for loose bytes <256. Might need a non-zero test on $F0C but my head hurts. However, it is just that simple give or take an instruction. In fact yes, something like a test to see if the the LS of the file length ($F0C) is non-zero and if so, add one to the result to account for the incomplete sector. You get the idea.... :lol:

User avatar
retroclinic
Posts: 3032
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Creating SSD/DSD images

Post by retroclinic » Sun Sep 26, 2010 10:14 pm

Yep, that seems to work better, altho it's sometimes off by 1 or 2, probably need to add 2 to account for the directory?

I see what that's doing, which is just saying what the last possible location of data is on the disc, not actual free space, which you don't really need to know.

Mark.
Image

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Sun Sep 26, 2010 10:26 pm

Yeah, it's just any final incomplete sector that can round the result down by one. Unless you beat me to it, I'll post the final assembler version that goes in the uploader but as you can see, it will ony be a handful of instructions which is what I was after.

EDIT : Double vodka and coke and finally I can convert assembler to Basic. The -1 is back in but removed if the last file has loose bytes. Sorted =D>

Code: Select all

   10 REM * SHOW END DISC SECTOR *
   20 *.
   30 SS=((?&F0E AND 3)*256)+?&F0F
   40 LS=?&F0D+SS-1
   50 IF ?&F0C<>0 THEN LS=LS+1
   60 PRINT
   70 PRINT"Last sector in use is ";~LS
retroclinic wrote:...probably need to add 2 to account for the directory?
I initially wondered about that but under DFS, the directory has no effect on the file order as it's only a single level system and the 'directory' of a given file is really just like having one extra character appended to the filename. The sector one info for all files has a single byte allocated to hold the directory character but other than that all files are treated exactly the same and are all mixed up and stored together.

User avatar
BeebMaster
Posts: 2926
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Creating SSD/DSD images

Post by BeebMaster » Mon Sep 27, 2010 4:29 pm

MartinB wrote:
Come on then someone, blow a big hole in it...... 8-[
Erm...well, it isn't going to work on a Master because &F0D-&F0F are in the user RAM. In general I'd be very wary of peeking memory locations in the hope of discovering disc information, I think it would be a much cleaner method (though much less straightforward) to use the OSWORD disc read call and use this information to work out the last used sector.

Another thing to bear in mind is that the last sector in use isn't the same as the (first free sector)-1, as there may be fragmented free space on the disc. However, if all you need to do is calculate where the last file data lives, then working out the last sector in use will work.

A third thing that may be important is that due to updating and deletion of files, disc compaction etc. there may be interesting or valuable data in sectors which are marked as free because the sectors aren't wiped when files are deleted or moved about.

Back on the subject of calculating the last used disc sector by reading from the disc, it isn't particularly easy because DFS doesn't maintain a free space map on the disc. Presumably the free space map is calculated immediately before a disc write and so to calculate the last used sector on a disc without guessing/assuming where DFS data might be held in RAM would involve something along these lines:

1. Read sector 1, examine the disc start sector for each catalogue entry
2. Remember the highest number
3. For this entry read the file length
4. Add the highest start sector number to the MSB of the file length
5. If the LSB of the file length <> 0 add 1
6. The result is the last used sector on the disc.
Image

User avatar
BeebMaster
Posts: 2926
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Creating SSD/DSD images

Post by BeebMaster » Mon Sep 27, 2010 5:51 pm

This will do the trick, and it works on a B and a Master, and with 8271 and 1770 DFS. As I alluded to earlier, it's a bit more involved than three lines of peeks! Apologies in advance for the similar variable names all over the place and general bodginess (especially lines 260-290, I just couldn't get my head round how to do it in BASIC!):

Code: Select all

   10REM Last Used
   20REM on a DFS disc
   30REM for 8271 DFS
   40REM (C) Ian Wolstenholme 2010
   50REM Version 1.0 27/ix/2010
   60DIM osblock 20
   70DIM sector 256
   80drive=0
   90A%=&7F
  100X%=osblock MOD256
  110Y%=osblock DIV256
  120?osblock=drive
  130osblock!1=sector
  140osblock?5=3:REM no. of params
  150osblock?6=&53:REM read
  160osblock?7=0:REM track0
  170osblock?8=1:REM sec1
  180osblock?9=1+32:REM read 1 sector;256 bps
  190CALL&FFF1
  200highest=0:length=0:len=0
  210FOR B%=14TO(sector?5)+4 STEP8
  220startsec=(sector?B% AND 3)+sector?(B%+1)
  230IFstartsec>highest highest=startsec:len=B%-2
  240NEXT
  250length=(sector?len)+(sector?(len+1)*256)
  260highbits=((sector?(len+2)) AND 48)
  270highlen=0
  280IFhighbits AND 32 highlen=highlen+2
  290IFhighbits AND 16 highlen=highlen+1
  300length=length+highlen*65536
  310lastsector=(highest+length DIV 256)-1
  320IFlength MOD 256<>0 lastsector=lastsector+1
  330PRINT"Last sector used on disc is &";~lastsector
Image

User avatar
regregex
Posts: 558
Joined: Sun Jan 02, 2005 9:51 pm
Location: London, UK
Contact:

Re: Creating SSD/DSD images

Post by regregex » Mon Sep 27, 2010 6:24 pm

BeebMaster wrote:A third thing that may be important is that due to updating and deletion of files, disc compaction etc. there may be interesting or valuable data in sectors which are marked as free because the sectors aren't wiped when files are deleted or moved about.
Anyone concerned about losing these could scan the disc backwards until a sector not filled with &E5 is found; then take the maximum of that address and the last sector claimed by the catalogue. Admittedly this would be utter overkill in almost all cases...
Back on the subject of calculating the last used disc sector by reading from the disc, it isn't particularly easy because DFS doesn't maintain a free space map on the disc
Not so, as the algorithm can be optimised to:
  1. Read sector 1, examine the disc start sector and length for the first file entry
  2. Add the start sector number to the MSB of the file length
  3. If the LSB of the file length <> 0 add 1
  4. The result is the last used sector on the disc.
This will only fail if one of the other files extends to a sector beyond this file, completely incorporating it but again, it ain't gonna happen.
Presumably the free space map is calculated immediately before a disc write
In the case of DFS 0.90 at least, it deletes the existing catalogue entry (if overwriting a file) then scans the catalogue backwards for the first gap big enough to accommodate the file.

--Greg
Last edited by regregex on Mon Sep 27, 2010 6:32 pm, edited 1 time in total.
Reason: fail case

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Mon Sep 27, 2010 7:45 pm

Thank you for your comments gentlemen :)
Beebmaster wrote:...it isn't going to work on a Master
Heh, just getting my own back on all the Master stuff that won't work on a Beeb. I would of course be happy to produce a Master version if anyone takes up the transfer system and would like same. Actually, I could even include a machine detect and then use the locations appropriate to the Master.
and wrote:I'd be very wary of peeking memory locations in the hope of discovering disc information
Words are curious things aren't they. Perhaps I could re-write your quote as "A robust method would be to load the disc catalogue information into ram using *CAT where formally documented locations can then be used to accurately calculate the last used sector" :wink:
and wrote:...there may be interesting or valuable data in sectors which are marked as free because the sectors aren't wiped when files are deleted or moved about.
And just who is otherwise gonna spend valuable hours ferretting around amongst a myriad of fossilised sectors?
(/me takes a large step backwards/)
I had actually thought about an <F> option to force a full disc image transfer so I guess that would cater for data archeologists.
and wrote:Back on the subject of calculating the last used disc sector by reading from the disc, it isn't particularly easy
Ohhhhh yes it is :D

Code: Select all

   10 REM * SHOW END DISC SECTOR *
   20 *.
   30 SS=((?&F0E AND 3)*256)+?&F0F
   40 LS=?&F0D+SS-1
   50 IF ?&F0C<>0 THEN LS=LS+1
   60 PRINT
   70 PRINT"Last sector in use is ";~LS
Yes, of course I know there are many long-hand ways to do it but that's not how to get free projects actually out there and working. Don't try and mend what 'aint broke is my motto 8)

User avatar
BeebMaster
Posts: 2926
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Creating SSD/DSD images

Post by BeebMaster » Mon Sep 27, 2010 8:27 pm

regregex wrote:Not so, as the algorithm can be optimised to:
  1. Read sector 1, examine the disc start sector and length for the first file entry
  2. Add the start sector number to the MSB of the file length
  3. If the LSB of the file length <> 0 add 1
  4. The result is the last used sector on the disc.
This will only fail if one of the other files extends to a sector beyond this file, completely incorporating it but again, it ain't gonna happen
I didn't know about this, it's not documented in the Master Reference Manual, where there's no mention of the catalogue order of files in relation to where they are on the disc. It certainly makes life a lot easier!
Image

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Mon Sep 27, 2010 8:31 pm

regregex wrote:
  • 1. Read sector 1, examine the disc start sector and length for the first file entry
    2. Add the start sector number to the MSB of the file length
    3. If the LSB of the file length <> 0 add 1
    4. The result is the last used sector on the disc
'ere Greg! I didn't notice that - it's exactly what my little ditty is doing!

User avatar
BeebMaster
Posts: 2926
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Creating SSD/DSD images

Post by BeebMaster » Mon Sep 27, 2010 8:34 pm

MartinB wrote:Thank you for your comments gentlemen :)
Beebmaster wrote:...it isn't going to work on a Master
Heh, just getting my own back on all the Master stuff that won't work on a Beeb. I would of course be happy to produce a Master version if anyone takes up the transfer system and would like same. Actually, I could even include a machine detect and then use the locations appropriate to the Master.
I sometimes think the poor old Master gets short shrift in some quarters! My method was a bit long-winded (especially since I didn't know a vital factoid about how the DFS catalogue works) but equally I would think it's long winded to catalogue the disc (thereby reading sectors 0 & 1) then detecting what OS is present and then peeking "B" locations or "M128" locations depending on the result, when you could just read disc sector 1 and get the answer in all cases.
MartinB wrote: Don't try and mend what 'aint broke is my motto 8)
That's very true, something I believe in very much, but it struck me that here was something which was almost deliberately intended to be broke on a Master 128/512/ET/Compact/Turbo/Scientific/AIV.....
Image

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Mon Sep 27, 2010 8:52 pm

Beebmaster wrote:here was something which was almost deliberately intended to be broke on a...
Not at all Ian. I work almost exclusively on Beebs and Elks and it never even occurred to me whether or not it would work on a Master. Indeed, I've simply come to expect that the kind of stuff I do won't work on a Master because it's always just that little bit different :roll:

Anyway, we now have our answer - I'll replace the *. with an OSWORD $7F Sector #1 read to ram and apply my ditty to that.

Sorted II =D>

(Errr..., is there a bit of free ram that is common to a Beeb, B+, Master 128/512/ET/Compact/Turbo/Scientific/AIV..... :-k)

User avatar
BeebMaster
Posts: 2926
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Creating SSD/DSD images

Post by BeebMaster » Mon Sep 27, 2010 9:42 pm

Just think of the possibilities when you sell it on E-Bay:

"Guaranteed to work on BBC Model A/B/B+ 64K/B+ 128K/Acorn Cambridge Workstation/Acorn Business Computer/Master 128/US OS 1.2/German MOS/Arabic Master Compact/Master 512/Master 512 with 1MB Upgrade/Domesday System/Master Compact with 1 Drive/Master Compact with 2 Drives/Electron/Electron +2/Electron +3/Electron/8271/1770/1772 ULTRA MEGA RARE UNIQUE NEW PICO POGO SPACE HOPPER NEVER BEEN ONE LISTED ON E-BAY BEFORE EVER"

and..

Tube!! ('cos the ?&F0D bit doesn't work with the Tube switched on)

Can one of the clever mathematical people let me know the proper way to extract those "two high order bits of a 10-bit number" for the file length which are stored in bits 4 & 5 of byte 14 of sector 1 (for the first catalogue entry)? It's been puzzling me all evening!
Image

User avatar
regregex
Posts: 558
Joined: Sun Jan 02, 2005 9:51 pm
Location: London, UK
Contact:

Re: Creating SSD/DSD images

Post by regregex » Mon Sep 27, 2010 9:59 pm

BeebMaster wrote:
regregex wrote:Not so, as the algorithm can be optimised to:
  1. Read sector 1, examine the disc start sector and length for the first file entry
  2. Add the start sector number to the MSB of the file length
  3. If the LSB of the file length <> 0 add 1
  4. The result is the last used sector on the disc.
This will only fail if one of the other files extends to a sector beyond this file, completely incorporating it but again, it ain't gonna happen
I didn't know about this, it's not documented in the Master Reference Manual, where there's no mention of the catalogue order of files in relation to where they are on the disc. It certainly makes life a lot easier!
This is why a free space map isn't needed, as you can find the end of each free fragment just by looking at the previous catalogue entry. The really cute trick is that it even applies to the first entry,with the disc size field acting as the start address of a 32nd file ;)

Sorry Martin, didn't mean to tread on yer toes there :)

Have fun

--Greg

User avatar
regregex
Posts: 558
Joined: Sun Jan 02, 2005 9:51 pm
Location: London, UK
Contact:

Re: Creating SSD/DSD images

Post by regregex » Mon Sep 27, 2010 10:19 pm

BeebMaster wrote:Can one of the clever mathematical people let me know the proper way to extract those "two high order bits of a 10-bit number" for the file length which are stored in bits 4 & 5 of byte 14 of sector 1 (for the first catalogue entry)? It's been puzzling me all evening!
Try:

Code: Select all

270 highlen=highbits DIV 16
DELETE 280,290
--G

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Mon Sep 27, 2010 10:44 pm

regregex wrote:Sorry Martin, didn't mean to tread on yer toes there
You didn't - I was just surprised how long it took me to realise that we had both come up with the same answer :)

Ian, generically - you right shift byte 14 by 4 places to get bits 4 & 5 to the lsb positions (/16), mask for the two (now) lsb (AND 3), shift left 8 places to get these bits to the msb of the 10 bit address at bits 8 & 9 (*256) and then add to the 8 bit address byte.

e.g.

Code: Select all

10 A=&AB
20 B=&30
30 C=(((B/16) AND 3)*256) + A
40 PRINT~C
where A is the 8 lower bits address byte and B is byte 14 which in this case has both of the bits in question set. The above Basic is written with it's assembler equivalent in mind where you would stop after the /16 and AND 3 and then store the result as required, probably little-endian (lo/hi or A/C) in a parameter block.

User avatar
BeebMaster
Posts: 2926
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Creating SSD/DSD images

Post by BeebMaster » Tue Sep 28, 2010 10:30 am

regregex wrote:
BeebMaster wrote:Can one of the clever mathematical people let me know the proper way to extract those "two high order bits of a 10-bit number" for the file length which are stored in bits 4 & 5 of byte 14 of sector 1 (for the first catalogue entry)? It's been puzzling me all evening!
Try:

Code: Select all

270 highlen=highbits DIV 16
DELETE 280,290
--G
So in fact I could probably just do

Code: Select all

highlen=((sector?14) AND 48) DIV 16
MartinB wrote: Ian, generically - you right shift byte 14 by 4 places to get bits 4 & 5 to the lsb positions (/16), mask for the two (now) lsb (AND 3), shift left 8 places to get these bits to the msb of the 10 bit address at bits 8 & 9 (*256) and then add to the 8 bit address byte.
It's one of those cases where it's almost easier to do (or at least to think how to do) in assembler. Shifting bits along as required and then ANDing them makes sense to me. It's all this DIV & MOD business I can never really get my head round, especially when you are setting up a control block for a SCSI command or something and you can't use the ! operator because it needs the bytes to be in reverse order from the way ! does them. I think I need a masterclass in all this at some point...
Image

User avatar
MartinB
Posts: 5252
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Creating SSD/DSD images

Post by MartinB » Tue Oct 12, 2010 11:43 pm

:?

I have just been testing my Beeb>PC disc imager for my fast serial link and everything was going great until by chance I tried imaging one of PJ's BeebSID compilation discs.

My imager reports the size of a requested image in sectors and then proceeds with the upload. When I tried BeebSID 5 (although all of his compilations appear to be the same) the image is reported as only 3 sectors long and the ensuing image created is, needless to say, very short and somewhat useless :(

Closer investigation reveals that unlike any other Beeb disc I've looked at, the files in the catalogue (sectors 0 and 1) are in reverse order to that normally expected. Specifically, issuing a *I.* will list the file info in the normal way but the earliest (low sector) files are at the top of the list with the later (high sector) files at the bottom :shock:. This is the exact opposite to the order that I would expect to see. Now, even though these BeebSID discs appear to run correctly (although they do have a *OPT4,3 !BOOT issue as previously discussed) it seems that even DFS is not expecting this reverse-by-sector ordering because if you save another file to the disc, the catalogue and affected file(s) is immediately screwed up. This is obviously because DFS uses the top entry to calculate the next free sector in exactly the same way as we have discussed in this thread but with the file order reversed, it just overwrites the lower sectors with the next saved file.

Is this layout therefore 'legal' in terms of Acorn DFS rules and has anyone else ever seen this before?

(I will post a pointer to this post in the BeebSID thread for PJ's attention.)

User avatar
jgharston
Posts: 3753
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Creating SSD/DSD images

Post by jgharston » Wed Oct 13, 2010 6:08 pm

retroclinic wrote:That just tells you the length of the first file doesn't it?
Files in a correctly formatted DFS catalogue are stored highest-sector-number to lowest-sector-number, as shown if you do *INFO *.*. Consequently, the first entry in the catalogue will point to the file that's furthest towards the end of the disk. So, adding that file's sector start to it's (length+255)DIV256 will point to the first sector past the last used sector.

Something like:
PROCfdc_rd(mem%,drive%,1,1) : REM Read sector 0001 to mem%
sector%=ptr%?15+256*(ptr%?14 AND 3)
length%=(ptr%!12 AND 65535)+1024*(ptr%?14 AND &C0)
lastsec%=sector%+(length%+255)DIV256

JGH
Last edited by jgharston on Wed Oct 13, 2010 6:23 pm, edited 1 time in total.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Post Reply