ruud.baltissen_at_apg.nl
Date: 2008-04-16 08:29:33
Hallo Jim,
Second thoughts:
> (How do you reference loading from the 257th byte of a sector
> using B-R or U* commands?).
A small correction: you don't read the sector, you read the buffer. And
that is done by the GET# command. This causes the 1541 to send the next
byte of the buffer. If it has read the byte at $0xFF, it simply starts
with the first byte, $0x00, again. HEY, this last means that for reading
a 512 bytes sector we can use the same 256 bytes buffer: the moment the
pointer becomes $00, the next 256 bytes are read into the buffer. And
the same can be done for writing a sector: again the buffer can be used
twice. Which means that for reading and writing 512 bytes sectors no
extra RAM is needed!
Just a reminder: now the various BLOCK commands are supplied with two
bytes, the track and sector. The LBA version will need four. And the 512
bytes version also needs a change of the B-P command; two bytes instead
of one because we need an extra bit.
> but I think it's trivial to handle 256 byte logical sectors in a
> 512 byte physical sector environment. uIEC and sd2iec do it and
> it does not take lots of extra RAM. 1581 did it as well.
But all three where written with this as a given specification. I have
to work with a FS that doesn't know 512 bytes sectors from start. It is
that the 1581 is so rare compared to the 1541, otherwise I had taken
that drive as a base.
> True, but you will eventually run out of partitions.
Has the CMD a limit? I support up to $1000000 partitions (although a 128
GB disk can only contain $555555).
Hallo David,
> I'd mentioned this before, and figure it may need to be
> mentioned again. A given 'aware' FS can have ....
I know. But thinking things over again and again I decided to go for the
extra RAM solution because IMHO solution will slow things down too much.
And writing the previous sentence I relialised another snag: we have 5
buffers. In the worst case one could read 5 sectors into those 5
buffers, change them and write them back to the harddisk in a complete
different order. Which means we need 5 buffers for the other 256 bytes
sectors, which is more then the 1 KB hack I had in mind. Maintaining
only one extra buffer means we are forced to do another read of the HD
sector so we can load the second sector into this buffer. And only then
we save the whole HD sector.
Hallo Raymond,
> is it possible to have a fsck routine that would ensure
> the quality and integrity of the HDD data (a hard drive
> is a lot to lose)?
Very good question! And the next idea popped up. An IDE interface can
handle two HD's: the master and a slave. Keep record of an extra
BAM-alike table on the master that keeps track of sectors that have been
written. During the time the drive is idle it can copy those changed
sectors from the master to the slave HD. So at the end you should have
two HD's in your system that are an exact copy of each other. And to
save weight etc. it is not needed to keep the slave inside the system
all the time; just plug it in once a week for the back-up.
JIM> When uIEC implements 'V', that will be the fsck.
And if you indeed meant the VALIDATE command instead of a back-up, yes,
that command is supported.
One remark: seeing all the trouble we run into, I doubt if I will take
the effort to support the 512 bytes sector FS. I myself will already be
happy having a working 8-bits system.
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org
De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.
APG NV te Heerlen is ingeschreven in het handelsregister Limburg onder nummer 14099617.
The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose it's
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.
APG NV, Heerlen, is registered in the trade register Limburg, The Netherlands no. 14099617.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.