Date: 2007-12-17 07:20:33
Sent from the wrong mailbox in the first place :( Another try :) -----Oorspronkelijk bericht----- Van: G.Baltissen@hccnet.nl [mailto:G.Baltissen@hccnet.nl] Verzonden: zondag 16 december 2007 16:30 Aan: Jim Brain; firstname.lastname@example.org CC: Baltissen, GJPAA (Ruud) Onderwerp: Re: 1541IDE and 1541IDE-S -- and 8250IDE? (and 64IDE, now) Hallo allemaal, Now the hardware becomes available, we have to think about how to deal with the needed software. Already having done quite some work, I would prefer to use my own work as base. But we live in a free world :) On top of http://www.baltissen.org/newhtm/1541ide8.htm you'll find some links pointing to the software I'm working on. The one under 1541IDE1 is the one handling 128 GB disks. Remark: I wrote the sources of 1541IDE2 and 1541IDE3 in such a way that all original needed routines still can be found at the original addresses. This in case speedloaders, disk editors etc. rely upon them. With 1541IDE1 I dropped this idea. But I kept the original labels so in case of trouble you can use these labels to compare these sources with the original 1541 ones. A possible problem is that sources are meant for my selfwritten assembler. IMHO I don't use extravagant directives or syntax so it should be possible to convert it in the format of another assembler. My assembler is freeware. The executable is available here: www.baltissen.org/files/mp-asm.exe , sources on request (as they are improved quite often). David wrote: > The concept I had in mind was to write a couple adjacent buffers > to a specific sector, read the target sector to write to these buffers, > ... Then, the buffers are restored from the disk. That's what I already suggested in my 1541IDE project. But it is a bit more complicated then that. You first have to find out which buffer is meant to be written to disk otherwise you run the risk to save the wrong one to disk in order to free it. OTOH, when just loading a PRG, there is a very good chance that at least two adjacent buffers are free and we can skip all the trouble mentioned above. > However, I do realize that this limits the number of possible open files Not at all. You only limit this number if you reserve two buffers permanently. And you said yourself, we just lend them temporary (if needed at all) so things are allright again when those file streams need to access these buffers themself. @all again: This morning I gave the use of 512-bytes-sectors another thought and I think I start to favour them above the "two C= sectors in one harddisk sector". When loading a PRG, the sectors are loaded from disk and sent almost directly to the computer. For reading or writing a whole 512-bytes- sector there is no need for a 512-bytes-buffer! For example: the 6502 first selects the sector and isues the read command, reads 256 bytes from the sector, sends them to the computer and then uses the same buffer to read the other 256 bytes before sending them. AFAIK the IDE drive doesn't object at all when there is a pause during reading. The question is: are there file types that will have problems with a 512- bytes-sector? In the past I mentioned some objections but IIRC they all concerned programs like disk editors. The only real trouble shooter could be the Pointer command. But having had a very good look at the sources of the 1541, I haven't found any other serious matter that obstructs the use of 512-bytes-sectors. Just a quick question: does anybody know if an IDE drive would object if you only would read, let's say, four bytes (= link to next sector) of a sector? Going through some files I ran into some BASIC PRG's that, I only realised now, only read 10 bytes of an sector and do that for 10 sectors in a row W/O any problem. If this isn't any problem at all, this feature can speed up things, like Validating a disk, enormously as we only need to read four instead of 256 bytes! I want to give you some info on the three fundamental basics of my file system capable of handling disks up to 128 GB: - LBA encoding - the layout of the disk - directory entry. LBA encoding speaks for itself IMHO. Basically it means that four bytes are reserved to point to a sector. The original LBA system only supports harddisk up to 128 GB. That is 3.5 bytes. This because it is based on the 'ancient' Track-Track-Sector-Head encoding. Bit7, 6 and 5 of the 'Head- byte' were always '101'. Bit 4 was used to tell whether the master or slave drive was addressed. In drives supporting LBA bit 6 is used to tell it to use the LBA mode (bit 6 = 1) ot to use the old TTSH mode (bit 6 = 0). Only needing 3.5 bytes means I have one nibble left for my own purposes. I use bit 7 to tell the system whether a sector is the last one (bit 7 = 1) of a file or not. Bit 6, 5 and 4 are free for future use. Ideas are welcome! If a sector is indeed the last sector in a row, the first and, in case of a 512 bytes sector, the second byte tell the system how many bytes are used in this sector. The layout of the disk is quite simple: - the very first sector is reserved to provide the system with some information: ; First sector ; identifier 16 bytes ; version 16 bytes ; disk parameters 4 bytes = total number of sectors ; directory parameters 4 bytes = start of directory ; name of disk 16 bytes = shows up in DIRECTORY - The rest of the sectors until the first directory sector have been reserved for the BAM. The BAM is quite simple: all bits are just for telling whether a sector is allocated or not. So no "free sectors/track" as in the BAM's of the other models. OK, it takes a bit more time to calculate the total free number of disks but simplifies calculations of where the BAM bit of a sector can be found. And don't forget, the system stores this number and updates it after allocating or freeing a sector. IIRC the routine that does the calculations is only called after Initialising, Validating and Formating a disk. When using two C= sectors within a 512-bytes-sector, we need two bytes for every real sector. - The BAM is followed by the root directory and only one sector is reserved for it. When more sectors are needed, the first free one is allocated and linked to this one. The same for saving PRG's and other files. I know, this is THE way to get fragmented disks but IMHO an harddisk is so fast that, certainly in the begin, we won't notice. And the moment we will notice, we 'simply' run a defragmention program. OK, the above sounds a bit simple but any addional feature will cost ROM space and that is, W/O some tricks , very limited in a 1541. - The following directory entry is based on the 256-bytes-sector: ; filetype 1 byte ; pointer 4 bytes ; name 16 bytes ; sideSector 4 bytes ; record size 1 byte ; pointer to replacement file 4 bytes ; number of Sectors 2 bytes ; future 4 bytes ; -- + ; 36 bytes 7*36=252 + 4 link bytes = 256 As you can see only one byte is used for the record size. I have thought about increasing that number but unfortunately this size is also limited to one byte in the various BASIC versions. I think I mentioned it before but for sure: I incorperated POST codes in the sources. The POST codes can be displayed on intelligent 7-segments displays, like the HP TIL311. At this moment the POST codes are outputted on the free A port of the first 6522, the one used for SpeedDOS and other parallel speedloaders. The idea is, when the Kernal works fine, to remove the POST codes or to move them to the now not needed A port of the second 6522.  just an idea: using the not needed outputs of the second 6522 to enable page swapping so we can place bigger EPROMs/FlashRAMs in the system. -- ___ / __|__ / / |_/ Groetjes, Ruud \ \__|_\ \___| http://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. Stichting Pensioenfonds ABP is gevestigd te Heerlen en ingeschreven bij de Kamer van Koophandel Zuid Limburg onder nummer: 41074000 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 its 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. Stichting Pensioenfonds ABP, having its registered office at Heerlen, is registered in the Traderegister of the Chamber of Commerce Zuid Limburg (Maastricht), the Netherlands, registration number: 41074000 Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.