Dnia 00-10-09 Aley Keprt pisze: > I significantly prefer emulation over real hardware. OK. You prefer emulation and I prefer hardware. It is easier for me to solder something to hardware than crack emulator. Anyway, we can make something useful both for hardware and emulator.
> The one thinkg I know is that you don't need that opcode, > since there are other possibilities. I need it to call host operating system in order to access their disks at file level. This is fastest way and doesn't disturb when code is used on real hardware. > This is my idea: > The "dos" could simulate a very large diskette, so it would be > 95% compatible with existing software, including programs, > which use asm-access via RST instruction. I find it as a monster. > I think about a "diskette" with 255 tracks, 255 sectors, etc. > Each file could occupy a single sector, directory & file > bodies could share the same space (i.e. whole diskette for > directory, whole diskette for file bodies) - this is because > you use different functions to load files and read > directories. Have you seen allocation table in SAMDOS disk directory entry? > The files would be stored as real files on hard drive to let > anyone can access them from hosting OS. And the emulator must build virtual partition every time? Then convert it back to files? Yuck. > Sorry, what is DIR$? A function of MasterDOS. > I think we can do some "tilda-combo" for special characters in > filenames (as M$ do in DOS<--Win95), so we can have the same > filenames as original DOS. Don't limit your imagination with Win95. > Maybe I am wrong, but I think it would be nice to have the > most compatible system with original MasterDos, except the > capacity. But why to follow disk structure limitations? I think the compatibility should end at file access level. Well, I made such thing in my ZXVGS with TR-DOS. TR-DOS is also media-related filesystem (people who have harddisk under TR-DOS divide it into 640kB partitions, too). So the diskimages are usually 640kB "*.TRD" files (there's also "compressed" form "*.SCL"). Sometimes "*.$?" files are used to every file separately (only for transportation). In ZXVGS I remapped TR-DOS calls to ZXVGS functions. So, the program "thinks" it uses TR-DOS, but in fact deals with "*.$?" files stored on independent filesystem (MS-DOS, CP/M, network). This works also with "advanced" loaders that read sectors directly. I think, the filesystem should be abstracted from SAM hardware and SAMDOS structures. Let's consider MS-DOS for example. There's 11 characters per file name, we need only 10. (The "$" sign could be pleaced just after dot to inform "there's no dot in SAM name".) We have only uppercase letters, what makes no problem to SAM. Some characters are not welcome in file names, so we can convert them to "-", what shouldn't cause problems to SAM. The 9B file headers can be still used, what only slowes full directory listing (temporary file can be created). Special header must be developed for some file types (5, 9, 20???). There's no problem with flags, date, file length. There's no space for comment - anyone used it? I can modify the MasterDOS to use other filesystem. By the way I could add a RSX port, like in ZXVGS. All I need is cooperation - I don't feel need to make third operating system for SAM only for myself. -- Yarek.
