Re: [Ql-Users] Q60 aging problems

2016-03-14 Thread Marcel Kilgus
Ralf Reköndt wrote:
> Hmm, nothing to find in the source code (if you have a quick look), as it's
> Open Source?

What? You think I did my work on the binary code?

> Where doesn't it follow all the QDOS conventions?

Cache handling, data management (e.g. physical definition blocks).

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

2016-03-14 Thread Ralf Reköndt
Hmm, nothing to find in the source code (if you have a quick look), as it's 
Open Source? Where doesn't it follow all the QDOS conventions?


- Original Message - 

On 14 Mar 2016 at 0:45, Marcel Kilgus wrote:
A few months ago I bought a QL-SD for my original black box. Then I
tried to adapt the driver to QPC. I wanted to add hot-swapping but
found it extremely difficult to implement due to the way the driver is
organized. It doesn't follow any of the QDOS conventions but always
does its own thing. I found it very difficult to understand. Then I
experienced some data loss and somewhat lost interest. Interesting to
hear that there are known problems with it. 


___
QL-Users Mailing List


Re: [Ql-Users] Q60 aging problems

2016-03-14 Thread pgraf
On 14 Mar 2016 at 0:45, Marcel Kilgus wrote:

> Peter Graf wrote:
> > Before you get tempted too much, please consider the SDHC card driver
> > issue. QDOS Classic and Minerva both work on the Q68, but the QL-SD
> > driver clashes with other extensions. Similar effects were seen under
> > Qemulator and UQLX, for which the same native driver minus the hardware
> > specific code exists.
> 
> A few months ago I bought a QL-SD for my original black box. Then I
> tried to adapt the driver to QPC. I wanted to add hot-swapping but
> found it extremely difficult to implement due to the way the driver is
> organized. It doesn't follow any of the QDOS conventions but always
> does its own thing. I found it very difficult to understand. Then I
> experienced some data loss and somewhat lost interest. Interesting to
> hear that there are known problems with it.

On the black box itself such issues have not been reported. My guess 
was, that the larger RAM on Q68, the fact that it has no other 
storage than SDHC card, and further side effects come in.

Did you try to adapt the BDI driver, or the hardware based driver?

> > 3) Wait until someone else has solved the QL-SD driver issues.
> 
> That's what I'm hoping for now, too :-P

Me too. There was help offered at the Edinburg show.

In the worst case, I must go back to my QL-HD (Steinkopf) based 
driver. But I hoped to avoid it.

> > All we do is without guarantee or timeframe. I have lost track of SMSQ/E
> > completely, so I'm not sure how much help I can be. And like must of us,
> > I suffer from lack of time.
> 
> I, too, have offered in the past to port SMSQ/E to new platforms, but
> in this case the hardware unfortunately didn't materialize. I could
> still be bothered if it's just a port.
> 
> I was actually once offered a quite huge sum of money for porting SMS2
> to a new hardware but ultimately declined because I got the feeling
> that "porting" there meant "also make drivers for all of the
> newfangled stuff on board", which for example would have meant
> creating a complete USB stack for it. In 68k assembler. Thanks, but no
> thanks.

If someone like me, who is not an assmbler expert, can port QDOS 
Classic in a single day, SMSQ/E should be a simple port. There would 
just not be a solid SD card driver, as long as QLWA is not adapted.

Does the QLWA driver offer single places, where the lowlevel block 
read/write oprations are implemented? Then it should be relatively 
easy to adapt it for SDHC card on Q68. 

The Q68 bootloader does completely initialize the SDHC card. It 
could locate the QLWA image on the card (just like it locates the 
ROM image) and store the start block in a register where the OS 
driver can grab it. A (non hot-swapping) OS driver would then just 
need simple linear block read/write operations.

Peter

___
QL-Users Mailing List