SDHC adaptors...

[Peter]

Cool Did you use the pick and place machine for the BGA, or just your own equipment?

[Dave]

Neither. A friend at National Instruments did the mounting using infrared reflow.

Note, I did not design this specific board; I just kitted and assembled a run.

[Paul]

Auction on SMR is now active
http://www.sellmyretro.com/offer/detail ... or-QL-3596
Kind regards
Paul

[Peter]

Important notice redarding a mistake in the Manual also posted on SellMyRetro:
QL-SD does not contain Toolkit 2 in EPROM!

[QLObi]

Hi all,
as part of the BETA-testing team for the QLSD drive, i like to post some result from the testing. Due to the fact, that QLSD is occupying some more RAM it leads to the situation that not all progs work fine (especial older ones). It tested some of the software i have and some i got for testing. I also tested the work with Q-emulator with BDI interface, but its still a bit disappointing. Don't get me wrong: without the extension Q-emultor is fine.
I tested in my personal enviroment, that means that it might work with yours or , if differend, not.
I have ISSUE 5 with Trumpcard 896kB and QLSD drive and a ISSUE 7 with Trumpcard 896Kb and QLSD. Both have MInerva 1.98 on board.
Some older progs store direct into memory at absolute adresses, which causes damaged FAT's. In this case unmout SD before start, or better boot direkt into floppy/mdv.
I general you encounter the problem having a lot of space on the drive, but an operating system which is not really prepared for that.
The table is an EXCEL sheet as ZIP, feel free do add your experience and please publish !

QLOBI

[Peter]

Great job, many thanks!

The massive problems under Qemulator sound unfamiliar to me. Is it possible that you run the free Qemulator version only and are therefore more limited in RAM than on your QL setup? In this case, it makes sense to reduce BDI image size (to reduce RAM consumption by the driver) and retry.

[RWAP]

Some of the programs which struggle under Minerva, may actually run in dual screen mode - certainly that was one of the changes I used to do to some of the early games (to detect minerva and if present force it to run in dual screen mode)....

[RWAP]

I have had some feedback from Simon Goodwin on this - I am sure we all wish him well, as his knowledge of the QL and device drivers is much missed.

Simon wanted to commend the new project and it having finally been brought to market.

Unfortunately as with anything we always get those who have different ideas on how things could have been implemented, and if Simon's health and commitments allowed him to do so, no doubt he would have a bash at something himself (thinking back to how he re-wrote the way the QL network was used in DIY Toolkit days)....

Anyway, his comments:

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.

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 )

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.

4) There's a typo in section 3.2 where it refers to ROM slot ($C800 - $FFFF).

The ROM slot address is 0xC000 to 0xFFFF - an extra 8 has got in there and initially made [Simon] concerned that it might clobber the other ROM or I/O areas from 0xC0000 to 0xFFFFF usually accessed from the main expansion connector.

The same typo is repeated at the end of section 12.1

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".

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.

[Simon infers] from the text much later that the 'native mode' uses the device at the sector level, bypassing the obstacle of MSDOS FAT32, but that's not clear, and probably [he'd] be better off reading the source to answer such questions...

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.

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.

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?

9) On p18 - the comment relating to "The operating system can only read and write complete groups" - This sounds as though this is something which could be avoidable.

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?

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.

[Dave]

There being multiple QL-SD type projects, I think that whatever the inner workings of the different systems, it is vital that they be cross-compatible for reading and writing.

[tofro]

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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