QL-SD news

Nagging hardware related question? Post here!
IRB
ROM Dongle
Posts: 2
Joined: Fri Mar 14, 2014 7:14 pm

Re: QL-SD news

Post by IRB »

Great work. put me down for one as well.


User avatar
Tesla
Bent Pin Expansion Port
Posts: 83
Joined: Fri Sep 15, 2017 6:19 pm

Re: QL-SD news

Post by Tesla »

Hi Marcel, great work. For a long time I'm searching an original sd-card from e-bay or Sellmyretro, and now you make avlaible an sd-card even gold card compatible . Please put one on these for me also, if possible.

Best regards.

Marco


User avatar
Doug
Chuggy Microdrive
Posts: 52
Joined: Tue Apr 04, 2017 11:25 am

Re: QL-SD news

Post by Doug »

Hi Marcel,

Please also put me down for one!

I have Tetroid's rom switcher with Minerva, so should be good to go.

And for the record, I would definitely be interested in an external one too if it were made available - a simple, less 'permanent' solution is appealing for tinkering and swapping things in and out quicker, using across multiple QLs, etc


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QL-SD news

Post by mk79 »

Doug wrote:I have Tetroid's rom switcher with Minerva, so should be good to go.
Hmm, actually the ROM switcher is a bit of a problem. Usually QL-SD comes with an EEPROM that contains Minerva and has some pins bend out so the EEPROM is only active on any address other than 0xFEE4. That's important because that is where the actual SD data is read. The Tetroid board cannot be bent, so this method doesn't work there.

Possible methods:
1. If the ROM board could be fit into the right socket (problematic because of the transistor) then I could provide a special QL-SD that doesn't map the first 48kb with the OS. The ROM switcher would need Switch 4 in the OFF position.

2. Putting the ROM board onto QL-SD (if physically possible, the SD-ribbon cable is very close to the EEPROM) would need some sort of hardware modification that routes the ROMOEL signal provided by QL-SD to the ROM switcher. Unfortunately I don't have the schematics for the ROM board, but maybe it could be connected to Switch 4 of the board somehow, disabling the upper 16Kb only on access to 0xFEE4.

Anyway, not quite so easy I'm afraid. Also, QL-SD is so far not QDOS compatible, for unknown reasons, so switching to anything but Minerva will not really work at this time.

Marcel


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QL-SD news

Post by mk79 »

In other news, I think I finally have a design for the MDV daughter board I like, I will probably order the boards soon. But it's at least another 2 or 3 weeks until all the parts for it arrive, so I'm not quite in a hurry ;) I've attached a picture of the paper mock-up. The second slot is an optional feature.

I've soldered some 8 QL-SD boards or so so far. Despite the low part count it's quite time consuming, about 30 minutes per board IF they work on first try, usually more. I've ordered a metal stencil and will try my luck with reflow soldering next.

I've also put a lot of time into the driver and I'm very satisfied with the result, yesterday for example I implemented automatic detection of card changes, this makes transferring data using QL-SD very very comfortable :D

So things are still moving along. Cheers, Marcel
Attachments
QL-SD double card external 2.JPG


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: QL-SD news

Post by Dave »

Nice work. :D

I assume the SD slot daughter card would also work with the previous QL-SD. You can count those owners amongst your customer base too - so you might end up selling more of those cards than the QL-SD main board itself!


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QL-SD news

Post by mk79 »

Dave wrote:I assume the SD slot daughter card would also work with the previous QL-SD. You can count those owners amongst your customer base too - so you might end up selling more of those cards than the QL-SD main board itself!
Yes, it is compatible to the original QL-SD. Fortunately I was able to pull off the "card change" detection feature purely in software as the original design didn't include any hardware for it.

Marcel


User avatar
Doug
Chuggy Microdrive
Posts: 52
Joined: Tue Apr 04, 2017 11:25 am

Re: QL-SD news

Post by Doug »

mk79 wrote:Hmm, actually the ROM switcher is a bit of a problem. Usually QL-SD comes with an EEPROM that contains Minerva and has some pins bend out so the EEPROM is only active on any address other than 0xFEE4. That's important because that is where the actual SD data is read. The Tetroid board cannot be bent, so this method doesn't work there.
Hi Marcel, thanks for the heads-up! I can always just go with your standard solution that comes with Minerva and use the rom switcher on my other QL, so it doesn't go to waste!


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: QL-SD news

Post by Peter »

mk79 wrote:Fortunately I was able to pull off the "card change" detection feature purely in software as the original design didn't include any hardware for it.
Which way did you do it? Hopefully not a periodic check for card presence which selects the card and thereby flashes the LED all the time. My approach:
Only if there is an actual R/W access, check time difference to the last lowlevel access, and if it's longer than e.g. 1 second (card might have been changed) check whether card is in initialized state, before doing the access. If the card is not in initalized state, assume it was changed.


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QL-SD news

Post by mk79 »

Peter wrote:
mk79 wrote:Fortunately I was able to pull off the "card change" detection feature purely in software as the original design didn't include any hardware for it.
Which way did you do it? Hopefully not a periodic check for card presence which selects the card and thereby flashes the LED all the time. My approach:
Only if there is an actual R/W access, check time difference to the last lowlevel access, and if it's longer than e.g. 1 second (card might have been changed) check whether card is in initialized state, before doing the access. If the card is not in initalized state, assume it was changed.
After about two seconds of inactivity the update counter of the root sector is checked on the next access. No flashing at all ;)

Marcel


Post Reply