Just to be clear, I am not pressing for a change to the current TIPI DSR configuration.
It is my understanding that legacy software would be just as mystified by "DSK<5-7>." as they are with "TIPI.", is that not true?
What does a program like DM2K assume about DSK5? Looking at the binary, it appears to just map Level 2 IO types based on the prefix (first 3 letters) of the device name... Is that the norm? Will all the other software have followed that pattern? I expect large amounts of software to just HONK at me if I suggest to it there is a DSK5. Since 5 is greater than 3, or 4 if the software was 'progressive'
DSK5-9 should behave like any other floppy DSKx. device, so long as the software is not artificially limiting the device number, most often seen in older programs /or/ programs that rely upon sector IO, the latter being irrelevant to this discussion. I suppose old programs that only ask for a drive number might also limit the device number to 1-3? Honestly, I don't recall the last time I encountered or used a program that could only open drives 1-3.
The 3-letter prefix mapping to device/CRU is fairly 'recent'. It is necessary in programs that (a) rely upon level 2 IO and (b) support more than one hard drive card and © expect the user to type in the device name. This device mapping would almost never be used with DSK device (floppy controller, ramdisk, etc) as their DSRs try to avoid device duplicity wherever possible.
What I'd like to know still is why... and everyone thinks they've told me why, but I haven't seen a single reason why yet. Eliminating the "conflict" isn't a use case, it is a solution approach. Having the "conflict" and exploiting it is my solution approach to old software.
A use case would be like: I run PageExtreme-2005, from my HRD mapped as DSK1-3 for the program disks, and it only allows DSKx for font disks, so I'd like to use folders on the TIPI as DSKA-Z for my alphabetized sub-directories of fonts and clip-art..
I'd respond with: 1) "Do you actually still use PageExtreme-2005?" And an example of someone actually using productivity software would say 'yep' , and then I'd be, "damn... ok, that's a real problem. So where do I find this software, and the manuals for it? Maybe I can work something up, but I want to test it."
? Does that make sense?
I understand the approach. You and I tackle use cases and solutions differently.
If the workarounds and options are adequate for developer and users alike, then I see not further need to poke at the DSK5-8 suggestion. I'll leave the use case issues to the users who encounter them.
The "conflict" code is good and necessary; this is true whether or not you implemented the mapping feature. That reminds me of something I wanted to check within the Horizon RAMdisk DSR related to device duplication; I'll get back to you on that.
There is no conflict. only a feature of TIPI to allow you to map a folder to DSK1,2,3 if you CHOOSE to do so. the level2 io issue is a software problem in disk manager. TIPI can be moved to a higher CRU to avoid it taking any DSK calls for physical drives.. it will still respond on the TIPI. device regardless
Perhaps also Fred will get a TIPI and add code to support it. This is due to the code in DM2K expecting a floppy DSR and not finding it. Matt's temp solution is to implement WDS1 mode which works for now..
Technically yes, there is a conflict, better described as device duplicity, and it is partly responsible for how devices respond or fail. This isn't strictly a software issue created by the disk manager.
Anyway, asking Fred to support the TIPI device sounds like a winner to me. I'm already adding some TIPI device support to my test code and will try the folder mapping when I get a card.
Edited by InsaneMultitasker, Sun Aug 12, 2018 4:47 PM.