ruud.baltissen_at_abp.nl
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; cbm-hackers@ling.gu.se
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 [1], 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.
[1] 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.