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.