> > 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.
Okay, if you have some idea. If you read my e-mails, you know that my ideas aren't much applicable to 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. Monster? The problem is that there are several programs using direct access to floppy disk, but this "direct" is only direct as "not using basic" or "reading sectors via DOS". So it is possible to emulate this together with "large" capacity. > > 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? I know it well. Do you know how RST calls to DOS work? It is possible to ignore this allocation table. Ignoring is possible, since I do load & save myself. When some programs will try to read directory sector by sector, they give some (e.g. empty) fake-table. > > 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. No. Files will be stored as real files. Short additional information like screen mode of screen$ files can be optionally added to file names. Partitions are not built, since SamDos don't access the disk this way. SamDos offers you the possibility to read files directly (without basic), but it works on the principle: 1. open file - SamDos reads 256 bytes from directory 2. read whole file - giving only starting side/track/sector to SamDos. So I can allocate one sector per file, and have much more sectors than fit into that allocation table you mentioned. > > Sorry, what is DIR$? > A function of MasterDOS. This is problem, since I don't know how to simply hook on basic commands. If you are able to hook this command, I can simply generate a directory listing, skipping any original algorithm of MDos. > > 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. no no. I work on Windows. I have no specs. or other information, so I can't think about other systems. If somebody will want to, he can convert my code to other system. Of course, I don't go to build any more "barriers" which would go against porting the source code to other systems. > > 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. This problem I discussed above. > I think, the filesystem should be abstracted from SAM hardware > and SAMDOS structures. File system IS abstracted, since you use Windows' file system. In the fact, you can have several file systems in Windows. I see no problem here. > 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? MS-DOS? Oh no, please, I had enough. > 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. The thing I need is not to convert MDos to other file system, but to let me gain the control over it and generate the results for the functions like LOAD or DIR$ in Windows. I know Sam drive file system well, but my knowledge of ROM and Sam drive hardware is much worse. > Yarek. Aley Keprt
