Re: [Ql-Users] QxlwinReader
Hi all, I’ve been following this thread with some interest as I still have some QL hardware (SGC/Qubide/Aurora) which I recently converted from a spinning IDE hard drive to a Compact Flash card using an adapter. I then added an additional adapter with an external slot to use as a backup medium. As a further backup I moved the backup CF card to a Mac with a card reader and used dd to make an image file of the card. By writing the image back to another card with dd and verifying that the QL could still read it I knew that this process was successful. When I read about QXLwinreader I was interested as I’d like to start playing with the various emulators again but moving software to them from my real QL via floppies wasn’t sounding like much fun. I tried QXLwinreader on my dd image but it was not recognized as a valid image file. Then I read the post about the file possibly needing conversion due to the 68K being big-endian. Since I was running QXLwinreader on a Mac with an Intel cpu (little-endian) I ran dd on the file again using the conv=swab option and I can report that QXLwinreader happily accepts the converted file and I can peruse through files and directories in it. I haven’t tried copying any files yet in either direction as I have to set up a QXLwin file yet but it looks promising now. For reference the converison process was quick only taking seconds on my 7 year old Mac. One image file was 512MB and the other was 1GB. Here was the command I used: dd if= of= conv=swab As for the floppy format problem I have a Gold Card here somewhere, I will try to find it and hope it still works and do some testing with it. I can confirm that my SuperGold Card system with Aurora running recent SMSQ/E versions does have some trouble formatting floppies although I’m pretty sure I can format HD but not ED disks in ED drives. I’ll have to test again with DD disks as I don’t remember if I tried this. I can read an existing ED disk, not sure if I can write to one. I know I have been able to read and write to DD and HD disks. The format command does seem to cause the drive to make some strange sounds at first before settling in to the normal stepping routine as it formats the disk. > On Jun 21, 2017, at 3:25 AM, Wolfgang Lenerz via Ql-Users > wrote: > > Hi Davide, > >> ... The DD Unix utility might >> be of course an interesting option but maybe it could be more useful for SD >> cards written with the QL-SD interface rather than a Qubide hard disk >> (especially if it has more than one partition) > > Whilst it's true that this was written with these cards in mind, I'm not sure > about this statement. If you have a PC that still has the connections for > your hard disk (I presume it's IDE ?), using DD (or equivalent) might be the > fastest way to get your data off that disk. > > I think I can confidently state that if I had an image file with several > partitions, I could probably figure them out pretty quickly and amend > QxlwinReader so that it can handle them. > > Tracks/cylinders/heads would be more difficult. > >> Talking more in general I think it is a pity that some possibile >> implementations or bug fixes are becoming very difficult if not impossible >> just because lack of the native hardware to test to the few people which >> have the knowledge to solve these issues. I wonder how this could be >> improved. > > Yes, not being able to reproduce and trace a bug is a problem. For example, > some time back, a problem with SMSQ/E for the Atari was reported to me. I > used to have some Ataris (and still had/have them but not in working > condition). So there wasn't much I could do, until I stumbled upon an Atari > emulator for the PC, which at least allowed me to see and even test the > problem, and eventually figure out what went wrong. That was pure dumb luck! > > As you rightly point out, without the actual hardware this is going to become > practically impossible - not only to fix, but even just to check whether the > problem exists (a case in point : some recent QXL screen problem, one user > (Andrea) reported a problem, I had a look at the code to try to find out why > but couldn't, and then another user (Bob) said that it worked OK...). > > I'm not sure what can be done about this situation. Perhaps your solution, to > supply actual hardware to people still fixing things might work. Without > false modesty, I think I can safely say that most recent development for > SMSQ/E has been done by Marcel, and to a much lesser degree, by me. I won't > presume to speak for Marcel, so this only goes for myself : I'm just not sure > that I'd want more hardware here! > > Also, don't forget that working on SMSQ/E is purely a voluntary work. > For me, there is a big difference between writing something new like the > recent Thing, and then fixing the problems I inevitably introduce on the one > hand, and fixing other bugs, on the other hand. > > Si
Re: [Ql-Users] QxlwinReader
Hi Andrea, GC / SGG / Aurora The DD floppy problem. It's not just formatting but also reading/writing. They just do not work. Verified on both Aurora + SGC and QL + simple CG. I only have ED drives, so I do not know if the problem exists by using other hardware such as HD floppy drives or DD floppy drives. Andrea Carpi So, just to be clear : even with a normal Goldcard (not SuperGoldcard), you cannot read/write/format disks on an ED drive. Is that correct? Wolfgang ___ QL-Users Mailing List
Re: [Ql-Users] QxlwinReader
Hi Bob, This problem also exists on the HD drive of my Aurora or QXL-PC. If I can find a working DD drive I may test this later. Again just to be clear : yo also cannot read/write/format disks when they are HD (1.4 MiB) disks, when using he Aurora. Does this need a GOldcard or Supergoldcard (and if so, which do you use?). Wolfgang ___ QL-Users Mailing List
Re: [Ql-Users] QxlwinReader
Op Wed, 21 Jun 2017 11:58:01 +0200 schreef Andrea Carpi via Ql-Users : (...) If it were possible, it would be nice that with QXL, you should not have a QXL.WIN for DOS device (C :, D :, E: etc.), but it would be configurable as with QPC in any subdirectories This can be simulated on the PC side in the AUTOEXEC.BAT with a DOS command like SUBST: e.g. SUBST X: D:\qxl\data This way you can point win2 to drive 'X' and put your QXL.win inside the given directory and there is no need to create up to 8 partitions. For 'X' you can use characters that do not upset anything on the PC side. GC / SGG / Aurora The DD floppy problem. It's not just formatting but also reading/writing. They just do not work. Verified on both Aurora + SGC and QL + simple CG. I only have ED drives, so I do not know if the problem exists by using other hardware such as HD floppy drives or DD floppy drives. This problem also exists on the HD drive of my Aurora or QXL-PC. If I can find a working DD drive I may test this later. Bob -- The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/"; ___ QL-Users Mailing List
Re: [Ql-Users] QxlwinReader
Hi Wolfgang QXL: I think that the QXL display depends a lot on the video card installed on the PC. I could not find out what type of video card is needed to get all the best resolutions. If it were possible, it would be nice that with QXL, you should not have a QXL.WIN for DOS device (C :, D :, E: etc.), but it would be configurable as with QPC in any subdirectories GC / SGG / Aurora The DD floppy problem. It's not just formatting but also reading/writing. They just do not work. Verified on both Aurora + SGC and QL + simple CG. I only have ED drives, so I do not know if the problem exists by using other hardware such as HD floppy drives or DD floppy drives. Andrea Carpi Il 21.06.2017 09:25 Wolfgang Lenerz via Ql-Users ha scritto: > As you rightly point out, without the actual hardware this is going to > become practically impossible - not only to fix, but even just to check > whether the problem exists (a case in point : some recent QXL screen > problem, one user (Andrea) reported a problem, I had a look at the code > to try to find out why but couldn't, and then another user (Bob) said > that it worked OK...). > > (...) > > Finally just a not-so-related question: There is a bug reported here > that precludes formatting disks on a SuperGoldgard - does anybody know > whether that is also true for a simple Goldcard? I ask because I know > that I can get my hands on one of those. Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 200 minuti ed SMS a 15 cent. Passa a Tiscali Mobile! http://tisca.li/Open7GB0617 ___ QL-Users Mailing List
Re: [Ql-Users] R: QxlwinReader
By the way, if someone actually attaches a raw Qubide IDE harddisk to a PC in order to extract an image file with DD: Since 68K CPU's are big endian, while x86 is little endian, it might be required to do some conversion. Not sure about the QL, but on Q40/Q60, access to the IDE data registers is big endian! It might be required to swap every pair of bytes of input data, for which DD has the "swab" commandline option. ___ QL-Users Mailing List
Re: [Ql-Users] R: QxlwinReader
Hi Davide, > The DD Unix utility might be of course an interesting option but > maybe it could be more useful for SD cards written with the QL-SD > interface rather than a Qubide hard disk (especially if it has > more than one partition) There might still be a misunderstanding, because the DD utitly is completely useless for QL-SD. DD can convert a raw media (Qubide formatted in this case) to an image file. But QL-SD already has the Qubide partitions in an image file! It does *not* have Qubide raw media, although that would have made it easier to get a working driver. The whole reason I initially wrote the QL-side FAT32 code, is to save the step of converting raw media to image files. Or in other words, the basic concept of QL-SD is *not* to need tools like DD. On QL-SD you can directly read the Qubide image file from a PC, for instance with QxlwinReader or an emulator. By the way, the same approach could also be taken for Qubide IDE harddisks! The IDE harddisk (or compact flash, etc.) could be formatted in FAT32, and then have Qubide inside an image file like QL-SD. That way, DD would no longer be needed. Now that the QL-side FAT32 code is there, it could be re-used. Maybe Alain could comment on this? The only remaining issue would be to convert old "raw" Qubide harddisks once. > I think maintaining compatibility and support of native QL > hardware should have some priority. I agree, insasmuch retro-computing becomes pointless if it lives only on emulation. Whereever I saw people returning to the QL in the recent years, it was hardware-related. All the best Peter ___ QL-Users Mailing List
[Ql-Users] QxlwinReader
Hi Davide, ... The DD Unix utility might be of course an interesting option but maybe it could be more useful for SD cards written with the QL-SD interface rather than a Qubide hard disk (especially if it has more than one partition) Whilst it's true that this was written with these cards in mind, I'm not sure about this statement. If you have a PC that still has the connections for your hard disk (I presume it's IDE ?), using DD (or equivalent) might be the fastest way to get your data off that disk. I think I can confidently state that if I had an image file with several partitions, I could probably figure them out pretty quickly and amend QxlwinReader so that it can handle them. Tracks/cylinders/heads would be more difficult. Talking more in general I think it is a pity that some possibile implementations or bug fixes are becoming very difficult if not impossible just because lack of the native hardware to test to the few people which have the knowledge to solve these issues. I wonder how this could be improved. Yes, not being able to reproduce and trace a bug is a problem. For example, some time back, a problem with SMSQ/E for the Atari was reported to me. I used to have some Ataris (and still had/have them but not in working condition). So there wasn't much I could do, until I stumbled upon an Atari emulator for the PC, which at least allowed me to see and even test the problem, and eventually figure out what went wrong. That was pure dumb luck! As you rightly point out, without the actual hardware this is going to become practically impossible - not only to fix, but even just to check whether the problem exists (a case in point : some recent QXL screen problem, one user (Andrea) reported a problem, I had a look at the code to try to find out why but couldn't, and then another user (Bob) said that it worked OK...). I'm not sure what can be done about this situation. Perhaps your solution, to supply actual hardware to people still fixing things might work. Without false modesty, I think I can safely say that most recent development for SMSQ/E has been done by Marcel, and to a much lesser degree, by me. I won't presume to speak for Marcel, so this only goes for myself : I'm just not sure that I'd want more hardware here! Also, don't forget that working on SMSQ/E is purely a voluntary work. For me, there is a big difference between writing something new like the recent Thing, and then fixing the problems I inevitably introduce on the one hand, and fixing other bugs, on the other hand. Since I've become the "regsistrar", which was supposed to be a purely administrative job, I'm often being asked to fix problems in some old code which I didn't write nor know about. It then takes me a lot of time to look at the code to try to understand it. In most cases I then just chicken out and refer this to Marcel :-), on some rare occasions, I manage to find the problem myself and fix it. For me, this is less fun than writing something for myself. I still do it just because I like SMSQ/E... But the point is that I do it because I want to, not because there is any obligation to. Finally just a not-so-related question: There is a bug reported here that precludes formatting disks on a SuperGoldgard - does anybody know whether that is also true for a simple Goldcard? I ask because I know that I can get my hands on one of those. Regards Wolfgang ___ QL-Users Mailing List