Rich,
thanks for the comments and best wishes to Simon. I am sure Peter will have one or the other things to say on design decisions (There's always a "different way to do things", IMHO. Sometimes it's better to just use what you have at hand and have something that works instead of trying to make things better than they need to be
)
Maybe it makes sense to elaborate a bit on what the intention of the project is in my opinion at this stage:
QL-SD was intended as a microdrive replacement and mass storage media
for the average QL user - Not (at least not yet) for the power-user with huge partitions and high-speed access. But instead safe and easy to operate. And NOW. If it's conveniently fast, well, we take that as an extra. There's still a lot of potential to improve, I guess everyone will agree. When most of the improvements can be done with the hardware as it is today - Even better.
RWAP wrote:
1) Would it not make sense (or be possible) to disable the slave blocks for the device, as the high speed access to the SD card should mean that there is little benefit in using slave blocks. - This would mean less of the QL's memory is used by the device.
Might be. But the slaving mechanism is so deeply buried in the driver, that a re-write would have delayed the whole project considerably. And don't overestimate SD card as a "high-speed" device. It uses pure serial transmission - Block-based devices can be much faster.
RWAP wrote:
2) If you remove mdv1_ from the QL - surely mdv2_ cannot then be accessed (even as mdv1_) as the signal will not be passed across the QL microdrive connectors - see 3.4.1 in the manual (actually that comment is from me
)
Right, thanks. We had a conversation about that bit if I recall it right some months ago. Will correct the manual that COMMS_IN and COMMMS_OUT of mdv1_ needs to be bridged for that to work.
RWAP wrote:
3) Would it not make more sense at some stage to use a more direct method of storing files on the CF card - maybe utilising the methods used by uQLX / QLAY or even Q-emuLator for storing file headers - in that way there would be no need to use a BDI container for QL files and access from third party systems would be easier.
Hmm. That would have made the driver even more complicated. Today it just about fits into the available ROM space. On the other hand - The method as it is now (transfer through an emulator) should actually fit the targeted user base much more - They never have to leave their known grounds.
RWAP wrote:
4) There's a typo in section 3.2 where it refers to ROM slot ($C800 - $FFFF).
Thanks for that - I have already spotted and corrected this myself.
RWAP wrote:
5) There's a minor one in 4.1.1, where it says "the type of usage you take ypur QL to."
"ypur" should read "your" (off-by-one) but the whole phrase in English would be "how you use your QL".
Thanks - Please keep on posting corrections - remember we're no native speakers.
RWAP wrote:
6) Section 7 seems to fall apart after the third open parenthesis, which is never closed. It's as if it's about to describe a way around the BDI image approach but never gets round to it - rather saying that it is not worth even trying to use the 'native' mode.
Will look into this. And yes, this section tries to keep the targeted (see above) user base from using "native mode" in order to protect them from shooting themselves in the foot. We had quite a bit of discussion about this - But, in the end, decided to keep it as simple and safe as possible for the time being. There might - and probably will - be a manual addendum that is going to explain how to use QL-SD in native file system mode.
RWAP wrote:
7) The 'official' SD formatter (p16) was interesting - [Simon] followed the link and found it works on PPC Macs like [his] (Dual G5 here, a few G4s around), but not older (OX9 or previous) ones. It should work on current Intel ones too.
We actually were discussing whether to include a link to a formatting tool into the manual at all - In the end, we decided to recommend the most static link we could imagine that would cover most of the modern platforms and is at least going to stay for a while.
RWAP wrote:
It would be nice if there could be a QL tool to format the SD device - but this would need a tool to be written using the 'native' mode. But then the QL direct sector access commands are not designed to work in native mode on the device, so would also need to be re-written. It looks as if formatting (such as it is, really only high-level FS creation) could be done with a small SuperBASIC program, but perhaps the legacy layers prevent this). This is my main question, because it might provide potential for a way to start to work around the software legacy.
Right. But see targeted user base above. Simple. Safe. Now. We can evolve from here.
RWAP wrote:
8) The comment "we have no native support for creating BDI QDOS images other than on MS Windows" should possibly appear as a warning somewhere at the start of the manual. Of course, this may change in the future - does UQLX provide a way of doing this now?
The actual intention for the targeted user was(for the moment): Use copies of pre-created image files that come with QL-SD. We didn't want the average user go through the hassle of creating their own images. Simply copying a file will get you going.
RWAP wrote:
10) Section 15 says: "The source code for the driver can normally be obtained from the same
place that holds this manual." A link needs adding to the manual, as the source code for the driver is not actually available on sellmyretro.com (where the manual is) - are the sources now available?
That one is owed to the early stage where we are (Remember: The very first one is not even sold yet). This will be made available in due time. Promised.
RWAP wrote:
Simon concludes by saying that he hopes his little musings are helpful in some way and may provide some impetus and consideration either for future developments of the drivers for this product or any other QL-SD project.
They are - we are grateful for any comments, corrections and criticisms you might have. I hope my explanations on target users/current project goals have brought some clarity on why things are as the are.
But it also needs to be kept in mind we're not a development unit of a multi-mega$$$ enterprise, just a bunch of hobbyists trying to develop something useful in their spare time.
Currently, resolving the Miracle Gold Card and SuperGoldCard issues has the highest priority - If there's still time (and enough enthusiasm), we will see where we get from there.
Cheers,
Tobias
