Hallo Levente,
Received your mail after sending my answer to Marko :-(
> I'm with the idea of using an 1541 wreck and use the digital board, the
> PS and the case for the hdd. You can expand the original board with RAM,
> ROM and a portchip easily (if needed), you can keep all 1541 properties.
> So you can make your business about 99.99% compatible to the original
> 1541, even using the HDD instead of the floppies.
Yes, that's the whole idea I had in mind.
> Since it's just a hacked 1541, it works with all computers supporting
> the serial IEC bus.
> I'm thinking about using the now obselete gates of the onboard 6522's for
> an IEEE-interface. Only problem is (again) the SW. But When I'm ready to
> realise this idea I hope to get some help from Andre :-)
> Talking about the filesystem: I'd use a FAT-like system, just to make
> things easier. Maybe, I'd use a FAT-32 like stuff because of the many
> and small files.
Yes.
> Or you can decide with the CBM like scheme, to allocate a big
> bitmap on the first blocks of the HDD as BAM and use daisy-chain linked
> file blocks.
I've thougt about it. But I also want to support disk-images and they all use
256 bytes per sector. There go two 256-bytes sector in one 512-bytes sector
(correct me if I'm wrong). If I'm going to use link-bytes then this is not
possible anymore. That would mean either one 356-bytes sector in every
512-bytes sector or using a weird algorithm to hack the 256-b sectors in
pieces. The first costs a lot of space and the last one is too tricky IMHO: one
mistake and you maybe loose everything. It also costs more processor time to
reconstruct everything.
> Try to create a standart HDD header, I mean the master boot record and
> the partitions table.
Why do I need a partition table???
My ideas (worked out a litlle further in more details):
- The "bootblock":
- identifier, like "CBM-HD"
- version
- HD-parameters:
- number of tracks, 2 bytes
- number of heads, 2 bytes
- number of sectors, 2 bytes
- 4 bytes pointing to the first directory-sector
- 4 bytes pointing to the boot-PRG, all 0 when none
This a PRG anyone can use to make patches to the original onboard
ROM SW or to change it to its own taste like implementing a speeder.
By changing these (4?) bytes you can let them point to other PRGs
and in this way simply change your patch. Only a reset of the drive
is needed.
- FAT-table
The idea is to use a 32-bit FAT. The idea is to use an entry for every
sector. With 16 bits we only can address 32 MB. With 32 bits we can
address 65536 * 32 MB. But I'm thinking of using the two MS bits for
other purposes: one for the validation process to mark them when
checked and one to mark it as not used. In this way an undelete is
still possible. All zeros mean end of file.
The size of the FAT-table depends on the size of the HD.
- All other sectors:
I've no plans of dedicating sectors to directories or files. I don't
see any point of doing that unless someone has a good point of doing
so.
- directory structure, 64 bytes per entry:
- name, 16 bytes like CBM or 32 like UNIX
- FAT-entry, 4 bytes
- filetype, 1 byte
- 00 = DELeted
- 01 = SEQuential
- 02 = PRoGram
- 03 = USeR
- 04 = RELative
- 05 = DIRectory
- 10 = 1541-image
- 11 = 1571-image
- 12 = 1581-image
- 13 = 8050-image
- 14 = 8250-image
- 15 = D16-image
- number of bytes in last sector, 2 bytes
- FAT-entry side-sector-block relative file, 4 bytes
- recordlengte relitve file, 2 bytes
- date/time-stamp, 14 bytes (YYYYMMDDHHMISS)
- number of sectors per file, 4 bytes
> It's no question, the filesystem should have subdirs. I guess, a subdir
> is a regular file....
Yes, see filetype 5 above. I use it in PC-Disk3 and it works fine (AFAIK).
> Of course, any old programs supporting direct block read/write commands
> would go mad when applying onto this filesystem. However, you have the
> option to treat special filetypes (regular 1541 disk images) on the HDD
> as subdirs too. When being able to not just copy, but even CD to an image
> file, your DOS can emulate a normal 1541 disk (as long as you're in the
> image), all with the appropriate parameters,
Yes.
> even low-level things like GCR codes.
No knowledge about this so this should wait, just like IEEE. As it seems
that you know where you're talking about, you can help me with this :-)
> Because of the image files, it would be possible to use not just 1541
> but any type and kind of C= floppy images.
See above
> keeping in mind that we can treat image files as subdirs.
I was thinking of connecting a image to a devicenumber like I do with
PC-Disk3. I can connect up to 28 images to a devicenumber. Even then I can
change the file on the fly.
> Since you have the 1541 board (and the DOS 2.6), you also have the option
> ...........
> The key is, to present the same functions in the same places as found in
> the original 1541 DOS.
My idea too.
> (This also gives you a chance to tie your routines to a modified -
> speeddos like - 1541 DOS easily).
I hope so.
> (Of course, it would be also a question of an at least 32K Eprom
> replacing the original, then all of your routines could reside in the
> expanded area (instead of scratching anything from the original DOS).
> There is fortunately, no problems with this extension, as there is fairly
> enough place to use in the memory map).
Enough to place extra RAM as well. Can be used for a lot of purposes:
buffers, patches etc...
> Good luck, and don't forget to send reports to the list! (I don't know
> if I can help you, I don't know if you need my help at all, but let me know
> if so.)
I have to concentrate on the HW around the hD for the moment. This wil
include interfacing it with the 1541.
What has to be done as well is:
- Find out to direct the original routines to our own. This needs a good
knowledge of the original OS which I lack.
- We have to implement our own commands (like CD, MKDIR etc) so we'll need
to know where to insert them in one or another way.
- Then the whole filesystem handling itself. It should be able of
handling/emulating more then one drive, subdirectories and dealing with
images. Here we can use the knowledge I've build up by programming
PC-Disk3.
The way to program it:
- it must be in assembler.
- I'm thinking of using a "jump"-table. If we have to break in the original
OS, we first jump to this jump-table and from there to the new routine.
I think the advantages of a jump-table ore obvious.
> So be aware... I'll be one of the first persons re-building the
> stuff.
One remark: don't sell the skin before you have shot the bear :-) But I
have confidence the interface will work sooner or later.
Groetjes, Ruud
-
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.