FW: 1541IDE and 1541IDE-S -- and 8250IDE? (and 64IDE, now)

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
the needed software. Already having done quite some work, I would prefer
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
1541IDE3 in such a way that all original needed routines still can be
at the original addresses. This in case speedloaders, disk editors etc. 
rely upon them. With 1541IDE1 I dropped this idea. But I kept the
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
IMHO I don't use extravagant directives or syntax so it should be
to convert it in the format of another assembler. My assembler is
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
> ... Then, the buffers are restored from the disk.

That's what I already suggested in my 1541IDE project. But it is a bit
complicated then that. You first have to find out which buffer is meant
be written to disk otherwise you run the risk to save the wrong one to
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 

> However, I do realize that this limits the number of possible open

Not at all. You only limit this number if you reserve two buffers 
permanently. And you said yourself, we just lend them temporary (if
at all) so things are allright again when those file streams need to
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
sector there is no need for a 512-bytes-buffer! For example: the 6502
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
at all when there is a pause during reading.
The question is: are there file types that will have problems with a
bytes-sector? In the past I mentioned some objections but IIRC they all 
concerned programs like disk editors. The only real trouble shooter
be the Pointer command. But having had a very good look at the sources
the 1541, I haven't found any other serious matter that obstructs the
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 
Going through some files I ran into some BASIC PRG's that, I only
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
up things, like Validating a disk, enormously as we only need to read
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
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
'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
drive was addressed. In drives supporting LBA bit 6 is used to tell it
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.
use bit 7 to tell the system whether a sector is the last one (bit 7 =
of a file or not. Bit 6, 5 and 4 are free for future use. Ideas are 
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
in this sector.

The layout of the disk is quite simple:
- the very first sector is reserved to provide the system with some 
; First sector
;  identifier                           16 bytes
;  version                              16 bytes
;  disk parameters                       4 bytes  = total number of
;  directory parameters                  4 bytes  = start of directory
;  name of disk                         16 bytes  = shows up in

- 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"
in the BAM's of the other models. OK, it takes a bit more time to
the total free number of disks but simplifies calculations of where the
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
every real sector.

- The BAM is followed by the root directory and only one sector is
for it. When more sectors are needed, the first free one is allocated
linked to this one. The same for saving PRG's and other files. I know,
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,
'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
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
on the free A port of the first 6522, the one used for SpeedDOS and
parallel speedloaders. The idea is, when the Kernal works fine, to
the POST codes or to move them to the now not needed A port of the

[1] just an idea: using the not needed outputs of the second 6522 to
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.