Re: [Ql-Users] QubIDE II Source Code
I have said this so many times that I am getting really tired of the repetition! The QL-SD driver was derived from QUBIDE. It was turned inside-out to implement replaceable hardware interface routines. It's all there. Don't reinvent the wheel again! Just look at the hw_xxx routines in the QL-SD source code and you can see how it's done. Peter is the man who has custody of the current source, I believe. I do not. -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Dave Park Sent: 02 February 2014 19:54 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] QubIDE II Source Code Rich, One of the things we want to change is how drives are detected and initialized. If anyone would like to do this work with us and is familiar, comfortable and skilled at producing ROM images from the code provided, please get in touch with me off-list. Work would be compensated. Dave On Sun, Feb 2, 2014 at 1:44 PM, Rich Mellor (RWAP) r...@rwapservices.co.ukwrote: Just be careful with the last ROMs - not sure if it was an error with the ROM code, or the utilities which went with them - I recall that the disk could be corrupted if you used the recycle bin facility !! I also had problems that if the QL had not been switched on for a while, QubIDE would no longer recognise the drive... Rich www.rwapsoftware.co.uk www.sellmyretro.com On February 2, 2014 at 7:03 PM Dave Park d...@sinclairql.com wrote: Hehe I don't know how I missed that! Actually, I do! I have two identically named folders, and looked in the same one twice - the wrong one! Thanks Marcel! Dave On Sun, Feb 2, 2014 at 12:51 PM, Marcel Kilgus ql-us...@mail.kilgus.netwrote: Dave Park wrote: We would like to make further improvements, but unfortunately we do not have the source of the QubIDE II ROMs. If anyone out there has the source, we'd be grateful for a copy. Google qubide source and voila: http://www.dilwyn.me.uk/qlrom/qubide-gpl.zip Not that difficult it turns out ;-) Cheers, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm -- Dave Park Sandy Electronics, LLC d...@sinclairql.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm Rich Mellor RWAP Software www.rwapsoftware.co.uk www.sellmyretro.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm -- Dave Park Sandy Electronics, LLC d...@sinclairql.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QubIDE II Source Code
Fine. Do what you want. Signing off. -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Dave Park Sent: 02 February 2014 20:52 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] QubIDE II Source Code Adrian, Please do not be offended. We are developing revised hardware and we want to use a known working driver following the only change one thing at a time rule. Once we have the hardware 100%, we want to make some driver revisions to do with initializing devices. We have as a design goal that the new IDE interface is 100% software compatible with the original QubIDE, so the new driver can be applied to original QubIDEs also. Once that is done, those changes can be applied to either driver. At this time, QubIDE has an extremely mature and tested driver. The QL-SD driver contains a lot of new code. We're being conservative. When QL-SD is in a lot of peoples' hands, we'll see how it handles the different needs and systems it's in. Then, we'll happily consider it. Dave On Sun, Feb 2, 2014 at 2:41 PM, Adrian Ives adr...@acanthis.co.uk wrote: I have said this so many times that I am getting really tired of the repetition! The QL-SD driver was derived from QUBIDE. It was turned inside-out to implement replaceable hardware interface routines. It's all there. Don't reinvent the wheel again! Just look at the hw_xxx routines in the QL-SD source code and you can see how it's done. Peter is the man who has custody of the current source, I believe. I do not. -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Dave Park Sent: 02 February 2014 19:54 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] QubIDE II Source Code Rich, One of the things we want to change is how drives are detected and initialized. If anyone would like to do this work with us and is familiar, comfortable and skilled at producing ROM images from the code provided, please get in touch with me off-list. Work would be compensated. Dave On Sun, Feb 2, 2014 at 1:44 PM, Rich Mellor (RWAP) r...@rwapservices.co.ukwrote: Just be careful with the last ROMs - not sure if it was an error with the ROM code, or the utilities which went with them - I recall that the disk could be corrupted if you used the recycle bin facility !! I also had problems that if the QL had not been switched on for a while, QubIDE would no longer recognise the drive... Rich www.rwapsoftware.co.uk www.sellmyretro.com On February 2, 2014 at 7:03 PM Dave Park d...@sinclairql.com wrote: Hehe I don't know how I missed that! Actually, I do! I have two identically named folders, and looked in the same one twice - the wrong one! Thanks Marcel! Dave On Sun, Feb 2, 2014 at 12:51 PM, Marcel Kilgus ql-us...@mail.kilgus.netwrote: Dave Park wrote: We would like to make further improvements, but unfortunately we do not have the source of the QubIDE II ROMs. If anyone out there has the source, we'd be grateful for a copy. Google qubide source and voila: http://www.dilwyn.me.uk/qlrom/qubide-gpl.zip Not that difficult it turns out ;-) Cheers, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm -- Dave Park Sandy Electronics, LLC d...@sinclairql.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm Rich Mellor RWAP Software www.rwapsoftware.co.uk www.sellmyretro.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm -- Dave Park Sandy Electronics, LLC d...@sinclairql.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm -- Dave Park Sandy Electronics, LLC d...@sinclairql.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL-SD Card Interface
Sorry, Miguel. This has all been my fault. I was really too busy to take on porting the drivers at the time, then when I tried to kick the project off I had one hardware problem after the other. Possibly my QLs have had a good 30 years and need to be retired. I will return the card to you. I assume the address is the same as on the packet? Now, as to the QL-SD drivers, I did not ask for my name to be plastered around all over the place as being the (part) author. It is true that I wrote the 68K assembly language core, derived from the old Rebel hard disk driver, but when I decided that I did not want to proceed with producing QL-SDs I stated that I was happy for my code to go into the public domain. I state this very clearly because I don't want there to be any misunderstanding. I have done NO work on that code since then. I have NOT worked on QL-SD instead of on a driver for your hardware. In fact, I haven't written one line of 68K code since that date. So, let's be 100% clear about this and for the avoidance of all doubt: I have NO connection with the QL-SD other than wishing the project every success for the QL's 30th year! Sent from my Hudl Miguel Angel Rodriguez Jodar miguel.an...@zxprojects.com wrote: El 09/01/2014 20:35, Rich Mellor (RWAP) escribió: The first QL-SD Card Interface based on Peter Graf's design, and with drivers written in part by Adrian Ives is now available on SellMyRetro - http://www.sellmyretro.com/offer/details/QL-SD-internal-SDHC-Card-Interface-for-QL-3596 May I guess that Adrian won't work in the drivers for the QLSD interface I sent to him last year? I've had no news from both of you since then. -- Miguel Angel @zxprojects | www.zxprojects.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL-SD Card Interface
Not what you think. It's a Tesco HUDL Android Tablet. Sent from my Hudl Lee Privett lee.priv...@gmail.com wrote: Never mind about all that Adrian, what's this Head Up Display your using? On 11 Jan 2014 15:33, Peter Graf pg...@q40.de wrote: Hi Adrian, you had contributed a large amout of work for QL-SD and this work deserves many thanks and respect. The drivers are free software and without any warranty, I can confirm here that you are not responsible for QL-SD or any support. I mentioned your name in the manual under the acknowledgements section. If you wish your name to be removed, or unmentioned in general, please let me know. I'm saying this for the hardware I designed, not sure if there is a name clash. Many thanks again, Peter ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL-SD Card Interface
References in the manual are OK, but I do not want to see my name in any advertising blurb - as I have done these last couple of days. Anyway I'm very pleased to see the QL-SD getting distributed at last. Well done to all involved. Sent from my Hudl Peter Graf pg...@q40.de wrote: Hi Adrian, you had contributed a large amout of work for QL-SD and this work deserves many thanks and respect. The drivers are free software and without any warranty, I can confirm here that you are not responsible for QL-SD or any support. I mentioned your name in the manual under the acknowledgements section. If you wish your name to be removed, or unmentioned in general, please let me know. I'm saying this for the hardware I designed, not sure if there is a name clash. Many thanks again, Peter ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL-SD Card Interface
Rich, Yes, I can see it was well intentioned but, unfortunately, the trouble with getting credit for something is that it quickly turns into an 0800 support number! and I DO NOT want to go there! Anyway, forget it. It's an exciting new product and needs some enthusiasm. As to Javier (I thought his name was Miguel, by the way) and the alternative QL-SD, which is really just a QL-SD for the ROM port: Anyone with decent 68K assembler skills can port the driver. It is only necessary to create a new set of hardware-level interface modules - basically the routines that (from memory) init, getSize, GetLBA and PutLBA. In fact you can probably port the driver to any block-oriented device in that way. Of course, you do need at least one reliably working QL to do that ;) I believe most of the documentation needed is actually in the commented source code. Signing off from this discussion, Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Rich Mellor (RWAP) Sent: 11 January 2014 19:29 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] QL-SD Card Interface I'm afraid that I am probably the guilty party here - so please accept my apologies. I just thought it right that you should receive some credit - you did a lot of work with these drivers without which the product would never have come to market. It is just a shame that you have not been able to get the drivers / hardware working reliably on Javier's own version of the QL-SD. Rich On January 11, 2014 at 7:01 PM Adrian Ives adr...@acanthis.co.uk wrote: References in the manual are OK, but I do not want to see my name in any advertising blurb - as I have done these last couple of days. Anyway I'm very pleased to see the QL-SD getting distributed at last. Well done to all involved. Sent from my Hudl Peter Graf pg...@q40.de wrote: Hi Adrian, you had contributed a large amout of work for QL-SD and this work deserves many thanks and respect. The drivers are free software and without any warranty, I can confirm here that you are not responsible for QL-SD or any support. I mentioned your name in the manual under the acknowledgements section. If you wish your name to be removed, or unmentioned in general, please let me know. I'm saying this for the hardware I designed, not sure if there is a name clash. Many thanks again, Peter ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL-SD Card Interface
Peter's your man for that. -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Rich Mellor (RWAP) Sent: 11 January 2014 21:17 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] QL-SD Card Interface As to Javier (I thought his name was Miguel, by the way) and the alternative QL-SD, which is really just a QL-SD for the ROM port: Anyone with decent 68K assembler skills can port the driver. It is only necessary to create a new set of hardware-level interface modules - basically the routines that (from memory) init, getSize, GetLBA and PutLBA. In fact you can probably port the driver to any block-oriented device in that way. Of course, you do need at least one reliably working QL to do that ;) I believe most of the documentation needed is actually in the commented source code. Oops yes, it is Miguel ( apologies Miguel) - I had just written an email to a Javier - but then it is Saturday evening and I've been relaxing!! Where is the source code for the driver by the way - has it been published? Rich ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL-SD Card Interface
Miguel, You will need to contact Peter for the source code. I have the last version intact but I am sure there will have been some changes since then. When you create the driver it probably makes sense to keep the same device name (I think it's SDC, but Peter will be able to clarify), and instead define new values to be returned by the driver's API calls to get info about the installed hardware type and operating mode. In that way, programmers will be able to determine which type of SD Card interface is installed (if they need to). All of this stuff is setup in a ver_xxx_in file that is specific to each hardware type and driver build. See the variables hw_type, hw_type_str and hw_vers and their corresponding manifest constants. From memory the Partition Manager software will also need to be updated to recognise the new hardware type, but that is a relatively trivial change. Good luck. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Miguel Angel Rodriguez Jodar Sent: 12 January 2014 05:26 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] QL-SD Card Interface El 11/01/2014 15:08, Adrian Ives escribió: Sorry, Miguel. This has all been my fault. I was really too busy to take on porting the drivers at the time, then when I tried to kick the project off I had one hardware problem after the other. Possibly my QLs have had a good 30 years and need to be retired. I will return the card to you. I assume the address is the same as on the packet? Yes, it is. Don't worry about the drivers. I completely understand your position :) In fact, now that the drivers are available in source code (are they?) I can try porting them. I haven't got much experience with 68K assembly, but even so, if the heavy part (dealing with QDOS and the filesystem) is already done and all that is needed is to provide a low level layer for basic functions, I think I can deal with it :) Anyway, thank you very much! -- Miguel Angel @zxprojects | www.zxprojects.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator 1.13
fyi SMSQmulator7.zip is reported as corrupt. Adrian www.memorylanecomputing.com On 21/03/2013 05:56, Wolfgang Lenerz wrote: Hi A small bug: on start-up, the new warning sub-menu item is always ticked, regardless of the setting in the .INI file... Thanks, fixed in 1.14 Shift+Tab doesn't work Thanks, fixed in 1.14 This is up on the website. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator 1.14
Thanks. It's working OK now. Great piece of work btw. Adrian www.memorylanecomputing.com On 21/03/2013 09:02, Wolfgang Lenerz wrote: Thanks, I've reupped this. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Raspberry Pi gets Turbo mode!
I think those last two sudo commands (steps 3 4) should be: sudo raspi-config Adrian www.memorylanecomputing.com On 19/09/2012 15:37, Norman Dunbar wrote: On 19/09/12 14:03, Norman Dunbar wrote: sudo apt-get update sudo apt-get upgrade Actually, that should have been the following: 1. sudo apt-get update 2. sudo apt-get upgrade 3. sudo raspi-update select the update option which updated raspi-config and exits. 4. sudo raspi-update select the new configure overclocking option and choose one. select finish. select yes to reboot now. On reboot, your Raspberry Pi will be running [much] faster and, if it gets too hot, will slip back to normal non-turbo mode automagically. Cheers, Norm. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Raspberry Pi WiFi Update
As well as the overclocking mentioned previously, the latest Raspbian build also supports WiFi out of the box (for adapters using the RTL8188CUS chipset). Go here for the full story: http://www.raspberrypi.org/archives/2008 And here for details on how to update the previous Raspbian Wheezy build: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66t=17788p=176847 -- Adrian www.memorylanecomputing.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Withdrawing from the QL Market
It's a bit of an over-simplification to lay the reasoning for my decision to withdraw solely on the lack of interest. It has more to do with simple economics. It costs money to buy the stock to build the units. As I have said before about the Ser-USB, unless the stock can be bought in bulk, it is not possible to obtain worthwhile discounts. This makes the product more expensive and thus reduces the likely number of sales. Add to that a severely depressed economy and the continued mismanagement of the Euro crisis, which further depresses any market from continental Europe, and you have a pretty dire situation. Almost a perfect storm, in fact. I wish I could afford to do this as a hobby, but I can't. I considered a number of ways of moving it forward, including seeking funding from Quanta (banks in the UK don't lend to small businesses any more, so that route is closed and, anyway, what kind of a business case is it to say Two or three people have said that they will buy one and then, when other people know they are available, a lot more people will buy them?). In the end, and to be absolutely blunt about it, it simply wasn't worth the effort required for the small return. But the root cause of this is that there are significantly less QLs in circulation than ZX81s or Spectrums. It always was a niche machine and, even in today's more retro-friendly environment, it is a minor player. This is a great shame but it is a true and unavoidable fact and it will always influence decisions about resourcing new projects for it. Anyway ... sometime back in this thread I remember reading a question about the state of the drivers. As far as I am concerned they are good enough to be released into production, but that is up to Peter, or whoever takes the QL-SD forward. Adrian www.memorylanecomputing.com On 12/06/2012 09:58, Rich Mellor wrote: It is just a shame that there was not all this enthusiasm and discussion some months ago when Adrian needed to see some interest in the QL-SD Interface. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Withdrawing from the QL Market
Dave, I've no problem with doing that but right now I don't have the time to take it forward. I will put the schematics and code online just as soon as I can get around to it ... but it won't be anytime soon. Adrian www.memorylanecomputing.com On 10/06/2012 03:42, Dave Park wrote: Adrian, I know it's a tough decision, but it was one you needed to make. Would you consider open-sourcing Q-BUS and seeing what the community does with it? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Withdrawing from the QL Market
I have sent the most recent sources to Peter Graf just a few minutes ago. The code may be placed in the public domain, but it is up to Peter how he wishes to move forward with it. I regret that I cannot offer any support with the drivers as I am moving on to other projects, but the code is very well documented. Adrian www.memorylanecomputing.com On 10/06/2012 11:23, Rich Mellor wrote: Hopefully, the source code for the drivers will be made available as soon as possible - as this is at least some of the important side of things. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Withdrawing from the QL Market
I am sorry to announce that I have taken the decision to withdraw from developing QL hardware. In the current economic climate, it is no longer practical to devote resources to such a small (almost non-existent) market, and I need to concentrate my energies elsewhere. Unfortunately this means that I have withdrawn from the QL-SD project. I understand that Peter is talking with other parties who may be more able to bring the QL-SD to market. I wish them all the best and will make available the source code for the already written drivers to allow this to happen as painlessly as possible. Plans for Q-BUS have also been shelved. Thank you to the few people who have expressed a genuine interest in new QL hardware. -- Adrian www.memorylanecomputing.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] [OT] Email to Adrian blocked
Peter, I can also be reached at: adrian AT acanthis DOT co DOT uk I will register another complaint with my provider (EasySpace). Adrian www.memorylanecomputing.com On 31/03/2012 13:14, Peter Graf wrote: Hi Adrian, I received your email, but your provider's crappy Trend Micro RBL+ blocks my answer again. I can not find your alternatative email address at the moment. Please send it again. Regards, Peter ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL Ethernet/TCP/IP card prototype version 2
Great work, Petri. It's good to see more new hardware coming on stream and I wish you every success with it. Adrian www.memorylanecomputing.com On 15/02/2012 22:10, Petri Pellinen wrote: Hi everyone, in case anyone is interested, there's a pic of the second prototype version of an ethernet / TCP/IP expansion card for the QL available on Flickr: http://www.flickr.com/photos/petrip/6883064083/ Fresh off the production line, it was finished tonight :) And the amazing thing is that it actually works. To me, the hardware side of things was the scary/educational part of the project. Now I feel confident that this prototype can be used as a nice starting point for prototype v3 with an actual printed circuit board. I was forced to take a long (10 months!) break from all hobbies due to hectic personal/business life but finally had some time to put this second version together. Now that I have hardware that can actually be handled without fear of tearing a wire loose I can concentrate on the software side of things. I have the source code for a rudimentary socket layer interface for the WizNet module (the TCP-IP-on-a-chip on the board) and will try to compile something with it. A very simple command line HTTP client would probably be an interesting starting point as that would open up all kinds of possibilities (file download, REST client, etc). Best regards, Petri ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL manual
Dilwyn, Can I just make a small correction to my involvement. What I did was to convert an already OCR'd PDF to Word format. The actual scan on which that was based was originally done by a guy called Andy Dansby. The books look great btw. Well done. Adrian www.memorylanecomputing.com On 15/02/2012 20:43, Dilwyn Jones wrote: Working from a scanned QL User Guide kindly supplied by Adrian Ives, I have produced both eBook and online HTML versions of the QL manual. To keep file sizes down, it’s available in four parts – the Introduction, Beginner’s Guide, Keywords and Concepts guides. If I get time I’ll prepare the Psion program guides in the future. The eBook version is available as ePub, Mobi and PDF files, and can be found at http://www.dilwyn.me.uk/docs/ebooks/index.html The online HTML version can be found at http://www.dilwyn.me.uk/docs/ebooks/olqlug/index.htm (note: end in .htm not .html). This is a first trial and it was created in Word and saved from Word as filtered HTML, so if you find errors or omissions, please let me know! Hopefully the online version will be suitable for both new and occasional QL users as an online reference version which can be accessed from anywhere with an internet connection, without having to download the manual each time. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ser-USB 2.0 Drivers Released + Ser-USB End of Life Announcement
Norman, Yes, I am planning to make use of SourceForge. Adrian www.memorylanecomputing.com On 12/02/2012 14:02, Norman Dunbar wrote: On 11/02/12 17:45, Adrian Ives wrote: The reason that I won't release any sources until the QL-SD is ready is because there may need to be core library changes to be made before the final version, and I don't want lots of different EDDE versions floating around out there, nor the possible distraction of having to answer questions or provide additional documentation while I am trying to concentrate on finishing something else. Fair enough? Adrian, have you considered creating a SourceForge project for this open-sourcing. It's free etc etc. They supply a Subversion repository, web site, etc for the project - provided it's Open Source. That way, you can control what is in it. There would be less chance for various versions dotted about all over the place that way. Just a thought. Cheers, Norm. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ser-USB 2.0 Drivers Released + Ser-USB End of Life Announcement
Dave, A very good chance. In fact, this has been on my mind for a while. It was always the plan that the EDDE 2 Core of the driver would be open-sourced when the QL-SD is released, so that anybody can then use it to write new device drivers. My agreement with Peter is that the full source code of the hardware-specific layer of the QL-SD card driver will be released as well. For the Ser-USB drivers (which actually boil down to a hardware-specific layer on top of EDDE, plus a handful of modules that override their EDDE ancestors): What I would like to do - at the same time as releasing the QL-SD sources - is to offer the Ser-USB sources to anyone who is prepared to make a public commitment to produce a better driver for it, on a non-commercial basis, within one year. I freely admit that I failed to solve all the issues with this driver, but there are so many clever people out there that I am sure that somebody could do a lot better. I will give more details at the appropriate time, but this should give anyone interested the opportunity to consider whether they want to take up the challenge. The reason that I won't release any sources until the QL-SD is ready is because there may need to be core library changes to be made before the final version, and I don't want lots of different EDDE versions floating around out there, nor the possible distraction of having to answer questions or provide additional documentation while I am trying to concentrate on finishing something else. Fair enough? Adrian www.memorylanecomputing.com On 11/02/2012 17:10, Dave Park wrote: Any prospect you might open-source the drivers, so others can continue your work on a non-commercial basis? Dave On Sat, Feb 11, 2012 at 2:44 AM, Adrian Ives adrian.i...@memorylanecomputing.com wrote: All, If you are a Ser-USB user, or you have a USBWiz, please contact me for the download details of the last ever release of drivers for the Ser-USB. They are still not perfect, but I believe that they represent a significant improvement over what has gone before and they should be made available. I have also taken the decision to withdraw the Ser-USB product from sale so that I can concentrate on other projects. This is primarily because the USBWiz module that it uses is now officially an end of life product and will soon become difficult to obtain. Consequently, as of today, it is no longer available. Support will of course continue for existing users. Regards, -- Adrian www.memorylanecomputing.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Wherefore art thou, SMSQ?
I had similar thoughts about checking for the last name that SMSQ adds, but it's not a solution that I'm happy with as it adds a lot of (probably version specific) complexity, and I'm not even sure that it would give the right result anyway. I think the best answer is to check the OS version and simply report Not Implemented if an attempt is made to use the command to list non-core resident procedures under SMSQ, so that's the way I will go. Thanks for your thoughts. Adrian www.memorylanecomputing.com On 30/01/2012 17:24, George Gwilt wrote: On 30 Jan 2012, at 15:59, Norman Dunbar wrote: On 30/01/12 15:44, Adrian Ives wrote: Does anyone know if there is a documented and reliable way of finding out the address address range that any version of SMSQ has been loaded into? Um, no, sorry. Alternatively can anyone suggest a better way of performing the test? Off the top of my head, I assume that the inbuilt routines in the ROM are still linked in in the same order as on the original QL ROM. I assume that whatever is last in that list will be the last resident procedure/function in the name list. Could you not obtain that address (of whatever is last in the inbuilt list) and anything higher than that address is an extra? It could work? Maybe? ;-) I imagine that any entries in the name list after the last one in SMSQ will have to be LRSPRd ones. If so you wouldn't need the actual address of the keyword's code. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB 2.0 Driver - Blog Update
Here is where we are with the Ser-USB 2.0 driver on legacy hardware: http://www.memorylanecomputing.com/blog/?p=122 I had been aiming for a 2.0 release on the first anniversary of the original USBWiz driver (01-FEB-2012) but it seems likely that testing will take a bit longer. Now that I have been forced to circumvent QDOS in several key areas we have moved into unknown territory with this device driver. It is still possible that I will have to abandon the driver altogether on legacy hardware, but it would be a shame to do so after so much time and energy has been invested in this ... especially as the prize would be what I had previously thought was undoable; a fitting end to the Ser-USB project. Regards and thanks for reading. -- Adrian www.memorylanecomputing.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] A question about the MGx ROMs
John, Thanks for taking the time to look. I seem to remember that it was something to do with an on-screen clock, but I might be thinking of something else. On 19/01/2012 22:25, John Alexander wrote: I simply can't remember... I know it was something sensible but can't remember what. I found the Microdrive and floppy with the source on it a few weeks ago, I'll take a look at it now I've been reminded. I've been looking for my printouts of the code for ages so maybe this is the time to hack some old 68K code ! Hopefully my QL's will now still boot. Worryingly the code I did is now older than many of the folk going to the Edinburgh hackerspace I've been visiting whilst working here. John A --- On Tue, 17/1/12, Dilwyn Jones dil...@evans1511.fsnet.co.uk wrote: From: Dilwyn Jones dil...@evans1511.fsnet.co.uk Subject: Re: [Ql-Users] A question about the MGx ROMs To: ql-us...@q-v-d.com Date: Tuesday, 17 January, 2012, 19:18 But while we're on the subject of MG ROMs (MGUK, in fact) does anyone know what the single line black window that appears in the top half of S*BASIC window #1 after booting is all about? I know MGUK is not an official ROM (I believe it was hacked from the Greek MG ROM) and I'm sure I looked into this before, many years ago, but can't remember the outcome. The MGUK was a privately produced QL ROM produced by John Alexander. I remember being told about it by David Batty (Sector Software) and Dennis Briggs (Adman Services) around the time it became available. The ROM is now available to download from my site, and I think John Alexander was on this list last year, don't know if still a subscriber. Dilwyn Jones -- Adrian www.memorylanecomputing.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Some good news on Ser-USB
Thanks to Rich Mellor, who managed to source a Hermes chip, I can now confirm that the Ser-USB will work on a standard QL fitted with Hermes at speeds up to 19200 baud. It is still necessary to load the asynchronous I/O module (the Queue Manager), though. This takes up an extra 5K of RAM. It had been my intention to withdraw support for the Ser-USB on standard QL hardware, but after receiving some feedback on that, I went back to the code to see if there was anything that could be done to at least create something that was stable enough to be used with some limitations in that environment. I believe that effort has been successful; this was the result: - The problem of executable files being corrupted when read back using asynchronous I/O has been fixed, after eventually having been traced to some erroneous pointer arithmetic. - Out of order Trap #3 requests no longer cause the driver to abort. Instead, the driver attempts to gracefully bring the abandoned request to completion, deferring any other pending requests until the process is completed. Both of these issues only affected asynchronous I/O, but when combined they made the driver unreliable on systems that required that functionality. Many thanks to everyone who pointed me at the SimSer serial driver as a possible solution. I did spend some time looking at this, but as it only enhances the functionality of the unidirectional channels (SRX and STX) I was not able to immediately make use of its capabilities without quite a bit of rewriting. It does have some very useful features, though, and I will look at providing support for them in a later version of the driver. So . Ser-USB will be supported on base QL hardware, after all. However, without Hermes or (better still) superHermes you will be limited to 4800 baud. There will be an announcement at the beginning of May on the availability of the hardware and its pricing, before which I will be in touch with anyone who has already enquired about purchasing a Ser-USB. Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Announcement about the future of Ser-USB
Laurence, I'm a little bit surprised by your comment that I am misusing slave blocks. Obviously the authors of the original QUBIDE driver, on which Ser-USB was based, were also misusing them!!! Like them, I use the slave blocks to keep mirrors of the data on the drive in memory to save having to re-read it. (Which, I think is what you then go on to say) In fact, I have barely changed the slave block handling code from QUBIDE - I'm certainly not using them for any other purpose. Sorry, but I don't understand what you mean by the statement The driver doesn't even get told about that. QDOS calls the Forced Slaving vector and tells the driver to dispose of a slave block ... and that's where I have had a lot of problems. Adrian -Original Message- Laurence wrote: I believe you are misusing slave blocks. They are not intended to be used for general I/O buffering. If you want that, allocate memory from the common heap. Ideally, slave blocks are used just to mirror data present on a mass storage device, and being asked to release it is completely simple. The driver doesn't even get told about that. The microdrive code does use them for data to be written, and causes anything that makes any sort of memory allocation request - if the allocation needs space - to hang until the microdrive completes flushing the slave blocks (or fails!). As a flush of slave blocks can be triggered for any sort of memory request - from the common heap, expanding (a) SuperBasic, or RESPR - you have to work within that. The microdrive driver does just that. When it finds that it cannot flush a dirty slave block, it treats it as a microdrive bad or changed medium error. That's after seven times around the tape, which I think equates to roughly a minute before the triggering memory request might get serviced. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Announcement about the future of Ser-USB
Well, original, or son of original, it's all the same difference and this slave block flushing issue happens on an expanded QL as well. -Original Message- Tony wrote: . but the qubide driver is not original. Phil Borman based it on the Rebel disk code. Qubide got away with it, I presume, as it cannot be run on a non-expanded QL, so there was plenty of memory for slave blocks. Tony ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Announcement about the future of Ser-USB
I think perhaps we're talking at cross purposes here, but this is a subject that has caused me a massive amount of grief so I'm a no compromise mood. Here it is: I have no problem with releasing a slave block WHEN I AM DONE WITH IT! The Operating System is there to serve me. Not the other way around. I am perfectly happy to defer releasing blocks for just a few scheduler loop cycles to allow my driuver to finish what it's doing. My issue is the badly written QDOS operating system that forces a decision on the time of disposal and does not even handle an error return. Unforgiveable. That's sloppy, lazy programming. QDOS OR Minerva OR SMSQ!!! -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Laurence Reeves Sent: 20 April 2011 16:54 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Announcement about the future of Ser-USB Adrian Ives wrote: - As a further bonus, if QDOS has decided that you WILL flush a large number of slave blocks, the driver will exhaust all of the available memory trying to double buffer the requests. How can the driver exhaust all of the available memory. when it is not permitted to allocate memory while flushing slave blocks? ... My other comment, The driver doesn't even get told about that. was about the fact that the driver does not get called for slave blocks whose data is accessible. They are silently returned to the pool. * Workhorse for releasing slave blocks, most of this was in io_slave reglist reg d0-d1/d3/a0-a4 sb_slave movem.l reglist,-(sp) move.w #sv_fsdef2(-256)!$f0,d1 mask for drive id and part offset assert 0,bt_stat and.b (a1),d1 pick out drive bits from status asr.w #2,d1 shift id to make pointer to table move.l sv_fsdef63(a6,d1.w),a2 get physical definition block move.l fs_drivr(a2),a4 driver linkage address lea -sv_lio(a4),a3 base of driver definition block move.l ch_slave(a4),a4 get entry point of slave jsr (a4) movem.l (sp)+,reglist sb_allop moveq #bt.actn,d2 set up action (read or write) mask and.b (a1),d2 is action pending bne.s sb_slaveyes - go ensure slaving sf (a1)take this block ea_top add.l d3,a1 move pointer to next one ea_bot subq.l #bt_end,d0 bge.s sb_allopany more blocks? bra.s ok_rts -- Lau AS! d-(!) a++ c p++ t+ f-- e++ h+ r--(+) n++(*) i++ P- m++ ASC Decoder athttp://www32.brinkster.com/ascdecode/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Announcement about the future of Ser-USB
Arnould, Thank you for this. The last time I looked at simser I couldn't find an English translation, and had other things to deal with, so I set it aside; but this helps a lot. I will take a look and see if it can be applied to this problem. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Arnould Sent: 13 April 2011 11:05 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Announcement about the future of Ser-USB On Tue, 12 Apr 2011 16:18:53 +0100, Adrian Ives wrote Urs, File transfers to and from FAT format devices will still be possible using the File Manager, but a native QDOS driver will not now be supported. There is one massive limitation with the standard QL hardware that cannot be overcome anyway, and that's the fact that it can only support 4800 baud with one stop bit. This means that even when the driver is working it is so slow that transferring anything larger than a few small text files is a painful experience. Hans Peter Recktenwald was not happy with the QL's serial driver. He developped SIMSER and his code can be freely reused. Can be found on this site: http://morloch.hd.free.fr/smsq/ and a short description in english here (more detailed in german though): http://globalfilesearch.net/download.aspx?path=romeo-klive.nvg.ntnu.no/pub/s inclair/ql/utils/simser.zip Maybe it could be worth to test this with your Ser-USB driver? Arnould ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Announcement about the future of Ser-USB
All, It is with regret that I have to announce that I am withdrawing support for Ser-USB on QL hardware without superHermes (or better) enhanced serial ports. As of today the Queue Manager installable module, whose primary purpose was to support the base QL configuration, is also withdrawn. A final version had been developed which incoporated a completely new method of IOSS retry integration that seemed to be working extremely well. Much better, in fact, than any previous version - but once again the design of QDOS and the inherent unreliability of the standard serial ports prevented it from being useable. I have therefore decided that enough is - very definitely - enough! It has been a long and very costly process attempting to develop this driver, and with next to no interest in the device as a commercial proposition I can no longer devote resources to any further work. I will make the final Release Candidate (#3) available to beta testers later today. My plan is to make the public release of the (enhanced serial hardware only) driver available on the 1st of May, at which time the source code of the core driver will also be released into the public domain. Many thanks for your interest and assistance, Adrian Ives Memory Lane Computing Ltd 10 Hillcrest Shortlanesend Truro Cornwall TR4 9DS United Kingdom Registered in England Wales, No: 7074678 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Announcement about the future of Ser-USB
Rich, Thanks. It _could_ have been demonstrated at the QUANTA AGM but I am not a QUANTA member and an article published in their newsletter did not result in any interest from their membership. Unfortunately, it's not now possible to organise a demonstration as I am away on other business this weekend, but I would be happy to provide a demonstration at some future event. I know the Ser-USB works with superHermes and works very well. Hermes is an unknown because I have never seen one, but it would be useful to test it. In any event it's not just the hardware itself; the driver for the serial port also plays a part. Adrian -Original Message- Rich Mellor wrote: --- SNIP --- I can understand the issues with getting this to work on a standard QL, when I have some Hermes in stock, I will be able to loan you a chip, so that you could try the device with the standard Hermes chip, as this may resolve the issues (at least it is worth a try if you like). Don't take the lack of communication to be lack of interest in the overall hardware solution - certainly it would be nice to provide as an alternative option for transferring files to and from the QL. To a large extent, part of your main audience for these devices are probably not people on the ql-users mailing list. Adrian, will anyone be taking one of these to the Quanta AGM this coming weekend to show how they work as this will elicit more interest I am sure? Unfortunately, I don't have a QL with SuperHERMES to try it on - I know Tony has been working to make some more SuperHERMES chips, but was unfortunately not able to complete them in time for the AGM. Rich ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Announcement about the future of Ser-USB
Urs, File transfers to and from FAT format devices will still be possible using the File Manager, but a native QDOS driver will not now be supported. There is one massive limitation with the standard QL hardware that cannot be overcome anyway, and that's the fact that it can only support 4800 baud with one stop bit. This means that even when the driver is working it is so slow that transferring anything larger than a few small text files is a painful experience. These are the issues that remain outstanding with RC3 of the driver on Base QL serial hardware: - Out of order Trap #3 requests (in other words a second Trap #3 request issued before the first Trap #3 has completed), or Trap #3 requests with non-infinite timeouts, can leave unfinished I/O transactions as hanging threads in the driver. There appears to be no way to reliably prevent this, and recovering from it is especially problematic. In a normal device driver talking to fast hardware, where all that's needed is to move a few bytes into some control registers this wouldn't be a problem and everything could be completed in the scope of a single trap handler invocation, but the Ser-USB driver has to cope with a transaction that could take thousands of times longer than that. - If QDOS decides that it's time to flush a slave block then - that's it - you WILL flush that slave block! It doesn't matter what your driver is doing, or whether it needs that block in memory. You WILL flush it - and just for good measure you are prohibited from returning an error code to QDOS to say that it failed! This is pretty much a show stopper. The current driver uses a double cache system that transfers the block into a holding area to be written when current I/O is finished, but if there is a large volume of data going through the driver it's hard to interleave the flush request correctly. - As a further bonus, if QDOS has decided that you WILL flush a large number of slave blocks, the driver will exhaust all of the available memory trying to double buffer the requests. - I could disable slave block handling altogether, but then every single request would generate serial I/O, slowing the driver down to an unacceptable level of performance. - For reasons as yet unknown, reading large executable files back off the disk results in data corruption - but not if you don't use the Queue Manager (which you need to be running for a base QL). This last problem was uncovered this morning and was probably the straw that broke the camel's back! All of these problems stem from the same root cause: the serial ports. Not just the poor hardware, but the driver. Do a serial I/O trap with superHermes in supervisor mode and, providing you use zero timeout, you're fine. Do the same thing with the standard QL serial ports and the trap never completes. So the end result is that you _can_ use the driver with a base QL, provided that you only copy small files in small quantities and none of them have an executable header. In my opinion nobody could be expected to accept those limitations. I'm sure that there _is_ a way to get this all to work and, honestly, the current code comes very close, but I believe that to do it reliably, it would be necessary to start again from the ground up, probably based around a brand new serial driver that can serve the dual purpose of serial I/O and USBWiz interface, thus avoiding the problems of Device Driver on Device Driver code. On a QL equipped with superHermes, as far as the testing so far has established, the driver works fine. It's also very happy running under QPC and Q-emuLator. Adrian Footnote: If anyone wants to propose a hack to QDOS/SMSQ to allow the slave block flush operation to be deferred by the device driver code I would be very interested to discuss the possibility. -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Urs Koenig (QL) Sent: 12 April 2011 12:44 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Announcement about the future of Ser-USB Adrian Ives wrote: I know the Ser-USB works with superHermes and works very well. Hermes is an unknown because I have never seen one, but it would be useful to test it. In any event it's not just the hardware itself; the driver for the serial port also plays a part. Adrian, I'm following your development with great interest. As said a while ago in a pm Great work! It's sad you decided to skip standard QL serial ports support. Maybe you can rethink the story as I see big chances for Ser-UsbWiz spreading. I'm following the world-wide Retro-Scene where collectors exchange (sell/buy) working QL's in a rate of approximately 3 QL's a week. Many of those newbies are interested not only to collect the machine but also to fire some software. As almost all second hand microdrive cartridges are in such a bad condition that they refuse to load those people have no other chance that to put the QL on their shelves
Re: [Ql-Users] Announcement about the future of Ser-USB
Tony, 1) Yes - or with a File Manager written by anyone else. The USBWiz command set isn't rocket science. You are limited to FAT format with old style 8.3 DOS shortnames (no native QDOS file system) but it's still a very useful capability. 2) Yes, input; but the USBWiz can't do split baud rates and it isn't easy to do split rates on a standard QL without additional hardware and/or software. The input limitation is two stops at 9600. The USBWiz only sends one so it doesn't work. Therefore 4800 is the top speed. 3) If anyone wants to sort the issue ... over to them. I have always said that I will put the driver in the public domain and anyone is welcome to pick up the gauntlet. Of course the trouble with gauntlets is that they don't stretch very well, so they can end up being a rather tight fit. ;) The source code is well commented but, as I say, I firmly believe that a proper long term solution (if there is one) lies in starting from the ground up with the serial driver to achieve a much better level of integration. The slave block system should be totally ignored. Instead, the driver should implement its own cacheing algorithms which it, and not QDOS, would be in control of. Adrian -Original Message- Tony wrote ---SNIP--- 1) Ah - so one *can* use a standard QL, but only with your file manager? ---SNIP--- 2) You are talking *input* I think. Output via the 8302, when working, has always supported a full 19200. Hermes chip (not sH) will support a reliable 19200 input, with net throughput of around 14000 bps. This lower figure is simply because the 8749 co-processor is just too slow. ---SNIP--- 3)I wonder whether there is anyone around with the experience to go one (small?) stage further with an unexpanded QL. I *bet* Laurence could sort the issue in Minerva, but I don't reckon he is listening anymore (are you Lau?). I shouldn't be really - I bowed out a long time ago. I have maybe over £1000 retail value of my stock to build for Rich in the time I don't really have. Can one *never* escape (8-)# ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB Driver now in Public Beta
All, fyi Version 0.07.004 of the Ser-USB driver along with its extensions and add-ons were released for public beta to those who had previously volunteered this morning. Those users should already have received e-mails with the download locations. If not, please contact me directly. If anyone else is interested in testing the driver, please drop me an e-mail off list, _but_ note that you will not be able to test the driver without either a working Ser-USB or a Ser-USB clone that you have built with a USBWiz module of your own. Beta testing is always a nerve wracking time for the poor bugger who wrote the software (me) because it represents the moment when your creation, which you believe to be fully working and as good as you can get it, gets torn to pieces by real users. In my experience, within 0.5 seconds of issuing the first EXEC, RUN or LRESPR command, Beta testers usually encounter the most obvious of bugs; ones that were staring you in the face all along! ;) In the meantime I am turning my attention to Ser-USB++, a ROM-port, SPI based version of the hardware that will break the link with the abominable QL serial ports and should, if it comes together, result in a simpler, more robust and performant driver. . but no promises yet. Best regards Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB Beta Test Web Site
I believe the QL Users list has been deluged with quite enough information about this project for now, especially as there are other interesting hardware-related topics now open for discussion, so today I have set up an official beta testing page where people who are interested can check on the progress of the project from here on in. I don't expect to make any further announcements to this list until the beta testing is completed . which I am sure will be a great relief to some ;) The page is: http://www.memorylanecomputing.com/serusb.htm Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Medic board
Try these: http://img135.imageshack.us/i/medicinterfacecircuitdi.png/ http://img153.imageshack.us/i/medicinterfacecircuitdi.png/ -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Ralf Reköndt Sent: 13 March 2011 08:19 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Medic board Tony Firshman wrote: Ralf Reköndt wrote, on 10/Mar/11 18:37 | Mar10: Does anyone have a manual for a Medic I/F to scan in and send to Dilwyn? An EPROM dump for examining would also a be good idea...;-) Medic circuit diagram (in two scanned A4 parts which need stitching!): http://tfs.firshman.co.uk/temp/medic.zip The zipped file is called __MACOSX (under Windows)...8-(. Can't read it. Cheers...Ralf ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Draft Ser-USB User Manual now available
If anyone is interested, the draft Ser-USB user manual can be found here: http://www.memorylanecomputing.com/files/serusb_manual.zip Please note that this is a PDF file. This document will be important to anyone who is participating in the beta, but may be of general interest to others. Any comments or suggestions are welcome but off-list, please. Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Draft Ser-USB User Manual now available
You can access the PDF directly here: http://www.memorylanecomputing.com/files/serusb_manual.pdf -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Tony Firshman Sent: 13 March 2011 13:27 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Draft Ser-USB User Manual now available Adrian/ On 13 Mar 2011, at 12:36, Adrian Ives adr...@acanthis.co.uk wrote: If anyone is interested, the draft Ser-USB user manual can be found here: http://www.memorylanecomputing.com/files/serusb_manual.zip Please note that this is a PDF file. This document will be important to anyone who is participating in the beta, but may be of general interest to others. Any comments or suggestions are welcome but Can you please upload a pdf as well - my phone refuses to load zip files (8-(# and you seem to have done a brilliant job. I have two usbwiz but no beta time for at least a month. Tony -- QBBS (QL fido BBS 2:257/67) +44(1442)-828255 t...@firshman.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, Tring, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Draft Ser-USB User Manual now available
François, I have not had the opportunity to test Hermes (because I don't have one) only superHermes, but I have every reason to believe that it will work just as well, especially if it's using the same driver code. Tony can probably give some insight on the performance of the Hermes vs superHermes. I plan to offer complete built and tested units through Memory Lane Computing, provided there is a demand (and, obviously, if we can get this driver satisfactorily through beta testing). If anyone is interested in a built unit please send an e-mail to sa...@memorylanecomputing.com giving your details and we'll get back to you on likely availability and price. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Francois Lanciault Sent: 13 March 2011 14:38 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Draft Ser-USB User Manual now available Hi Adrian, After reading the manual I have one question: You are talking about the maximum baud rate supported on standard QL (4800) and Superhermes (57600). But what about a QL with an Hermes chip (not superhermes, just hermes). Do you think 19200 baud would work? Is there any plan for someone to sell the device, comlete with cable ? François Le 2011-03-13 à 08:36, Adrian Ives adr...@acanthis.co.uk a écrit : If anyone is interested, the draft Ser-USB user manual can be found here: http://www.memorylanecomputing.com/files/serusb_manual.zip Please note that this is a PDF file. This document will be important to anyone who is participating in the beta, but may be of general interest to others. Any comments or suggestions are welcome but off-list, please. Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SPI (was Ser-USB on Minerva)
Tobias, I agree 100% with everything you say. And ... by the way ... USBWiz can talk SPI, which is where I'm coming from with all of this. With a faster throughput it suddenly becomes more possible to use the other USBWiz functions, such as keyboard and mouse and maybe ... just maybe ... a USB ethernet adapter. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Tobias Fröschle Sent: 12 March 2011 10:53 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ser-USB on Minerva Adrian, Dave, while this might sound a bit naive, I doubt whether there would be much HW involved when trying to build a bit-bang interface to SPI. SPI is such dead simple that you could connect CLOCK to an address line, MISO to the data bus and MOSI to another address line (Suitable buffering and 5V/3.3V conversion would have to be provided, The ROMCS line needs to be married with the rest of the pins through some minimal logic). The rest would be a matter of clever software. The QL ROM port already is quite de-coupled from the Bus with complete address decoding so that this could actually work. What I would really like would be a small board connecting to the ROM slot, carrying a small CPLD for the decoding, an AVR controller, probably an Ethernet chip and an SD socket, maybe minimal USB hardware to connect USB mouse and keyboard. Dave, I like your idea with an FGPA based QL very much as it has lots of opportunities in it, but I think it's well beyond the capabilities of the current (small) QL scene, both regarding to Hardware and Software support. Start small! There's time for the more ambitious projects later. Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SPI (was Ser-USB on Minerva)
Tobias, Direct SPI to an SD card. Hmmmn. That's a good point, but actually the SD card feature is almost a secondary feature of the USBWiz. Don't forget that it also works directly with USB mass storage class devices (hard disks, memory sticks etc.) Just to be clear, I have not implemented a FAT filesystem on the QL. The Ser-USB driver does not use FAT - it formats the SD card or mass storage device as a native QL partition. The standalone file manager accesses FAT devices, but that facility is not in the driver; i.e. you cannot mount a FAT volume as a QDOS drive. In my opinion trying to mount a FAT filesystem under QDOS is fraught with problems anyway, not the least of which being ... trying to mount a FAT filesystem under QDOS!!! The best way around this is to use a QXL.WIN container on a FAT drive, and I do have plans for a later version of the driver to do exactly this. However my priority now, as soon as the beta testing is over for the current driver, is to commence work on a ROM port version of the USBWiz using SPI. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Tobias Fröschle Sent: 12 March 2011 17:59 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] SPI (was Ser-USB on Minerva) Am Samstag, den 12.03.2011, 11:00 + schrieb Adrian Ives: I agree 100% with everything you say. And ... by the way ... USBWiz can talk SPI, which is where I'm coming from with all of this. With a faster Adrian, well, if you get the QL itself to be able to communicate using SPI, there's at first thought probably not much use for the USBwiz after all, as you could talk to the SDCard directly - The USB ports to connect to a proper keyboard and mouse are worthwile, however (and there's no need to implement a FAT filesystem on the QL). So the USBWiz could be an optional component, then. Cheers, Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Lau's place dead...?
Tony, Sorry, but as I was poking around, clicking on links ... that link at the top of the page is wrong (Patched I2C drivers (I2C_IO_REXT) for SMSQ) it should be: http://tfs.firshman.co.uk/ql/ftp/minerva/i2cio.zip and not http://tfs.firshman.co.uk/ftp/minerva/i2cio.zip Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Tony Firshman Sent: 12 March 2011 20:37 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Lau's place dead...? ... from the (ex-)trader site - you did not search very hard (8-)# http://tfs.firshman.co.uk/ql/fminerva.htm Tony ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB on Minerva
Well it wasn't as bad as I had feared, but not as simple as I had hoped. And I'm certainly not going to mention the still unsolved mystery of the mm.alchp vectored call that reported success but actually zeroed out an entirely different area of the common heap, thus trashing the in-memory copy of the map! :( The driver is now running on a bog standard QL, albeit somewhat painfully. The crappy QL serial port is unfit for use above 4800 baud because it insists upon two stop bits @ 9600 and the USBWiz only sends one. Even if it did send two I doubt if it would work reliably. Really, superHermes is going to be a must . unless you like accessing a USB hard drive at the speed of a 1980s dial-up connection, that is! Public beta 1, code name Logopolis, is on course to be released on Monday. You will need a USBWiz, RS232 to TTL converter and some kind of regulated 5V supply for the electronics if you want to try it. I will send download links to those who have already volunteered. This has been a long and painful project, fighting every step of the way against cross-platform inconsistencies and serial hardware that was barely fit for purpose in 1984, let alone 2011. I really don't exaggerate when I say that I wish I'd never started it in the first place! For example: Under Minerva with the standard serial hardware you are forced to run the installable Queue Manager add-in, because it can't handle zero timeout serial I/O calls in supervisor mode. This probably happens with JS JM, too . although I have only tested JM with an Aurora/SGC superHermes. otoh SMSQ doesn't need the Queue Manager at all, but it can use it as a performance enhancement! SMSQ lets code called from the scheduler do mt.cjob traps, JM crashes if you try and do that. And so on . The higher up the hardware/software tree you go, the better things get. Best configuration is SMSQ on modern hardware with decent high speed serial ports. Ser-USB runs happily under the current versions of QPC2 and Q-emuLator . although, perversely, you will need a USB to serial adapter if your PC doesn't have a built-in serial port! Status: The current version supports SD cards and USB storage devices formatted as native QDOS. Multiple partitions are supported (but as yet there is no partition editor written). There are also hooks for supporting multiple LUNs on USB storage devices but at present no mechanism to mount them. Ser-USB *should* be able to mount any QLW1 format hard drive connected to a USB to IDE adapter, but I haven't had the opportunity to test this. Because all I/O is routed across a single serial connection, the driver is single tasking, non re-entrant, but this hardly affects performance as the biggest hit comes from the serial connection speed. The code is ROM-able, but it's currently too big to fit in a 16K EPROM. Also, it shouldn't be too hard to whip out the USBWiz Operations Layer from the driver and slap in an alternative hardware layer for something other than a Ser-USB at some future date. But that's another story. btw If anyone out there (like, for example, Dave Park) would like to build an SPI interface for the QL that would significantly increase performance! Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ser-USB on Minerva
Yes please. I'll do the driver. :) How about a board that plugs into the ROM port and has the necessary logic to implement the four wire SPI interface for a single slave device (namely the USBWiz). The board would also have a header socket to mount the USBWiz module on. Job done. -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Dave Park Sent: 12 March 2011 01:26 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ser-USB on Minerva On Fri, Mar 11, 2011 at 6:42 PM, Adrian Ives adr...@acanthis.co.uk wrote: btw If anyone out there (like, for example, Dave Park) would like to build an SPI interface for the QL that would significantly increase performance! I can do the hardware if someone else can do the driver. :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ser-USB on Minerva
Dave, That's all very nice and would be an absolutely fantastic piece of hardware but it's very complex and likely to be expensive. I would have thought that a better use of the development cost and time would be an FPGA-based QL clone running at 80MHZ with 1GB RAM and onboard USB3, SATA and HDMI. SPI otoh is a very simple protocol and the only hardware needed are four I/O lines for Clock, In, Out and Slave Select. When I finally get some time I will look at the spare I/O provided on the superHermes to see if that could be used for this purpose. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Dave Park Sent: 12 March 2011 01:57 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ser-USB on Minerva On Fri, Mar 11, 2011 at 7:32 PM, Adrian Ives adr...@acanthis.co.uk wrote: Yes please. I'll do the driver. :) How about a board that plugs into the ROM port and has the necessary logic to implement the four wire SPI interface for a single slave device (namely the USBWiz). The board would also have a header socket to mount the USBWiz module on. Job done. When you say ROM port I brace myself. Knowing the trickery involved in getting the RomDisq to work and the addressing gymnastics required... The hardware and driver need to be developed hand-in-hand. I'd rather work on a standard expansion card that could take submitted multiple interfaces from many people and implement them in a single board. I was thinking of it having some flash for ROM images, two daisy-chained SPI ports, two proper serial ports from a MAX232, 16 buffered/registered GPIO lines, an SDHC port/socket - things like that. Also, it could have a large flash bank on it, access through a mild hackery of the RomDisq driver, etc... People could buy the basic PCB, then simply add those interfaces they need... This is a project I plan to begin when I have a suitable venue for a hardware forum. (If one isn't available soon, I may install phpBB and start one myself)... I look at things like this and suddenly feel very naive... Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ser-USB Driver running under Q-emuLator
Tony, If you're talking about the drivers built into the USBWiz, there's USB printer support and HID for mice and keyboards. However, nobody should get excited about that because the USB printer support appears to be raw data only so it would need a driver written. Keyboard and mouse might be possible, but I've already covered the problems of running them across the same serial connection as used for the storage devices. Beyond that, it would be possible to talk to just about anything USB ... with a driver. The Ser-USB driver currently supports SD Cards and USB Mass Storage devices; both accessed in native QDOS mode. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Tony Firshman Sent: 28 February 2011 00:09 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ser-USB Driver running under Q-emuLator On 27 Feb 2011, at 23:49, Adrian Ives adr...@acanthis.co.uk wrote: I was asked this question recently and have only just got around to testing it. Yes, it does work! Tested this evening under Q-emuLator 3.0.2 with a JS ROM image on Windows 7 64 bit with a USB to Serial adapter connecting to the Ser-USB unit. That is really good news. What inbuilt drivers are there of any use? I forget the details but on first reading the specs anything really useful via USB will need QL drivers. Looks like you are making real progress. Tony -- QBBS (QL fido BBS 2:257/67) +44(1442)-828255 t...@firshman.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, Tring, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Help: Function to tell whether display is better than QL standard
I know I've seen this somewhere but, as usual, when you really want something it refuses to be found! I'm looking for a function to use in S*BASIC that will tell me if the display driver is capable of providing resolutions greater than the QL's mode 4 8 defaults - it would be enough just to know if the display driver is GD2 or not. It has to run on any QL system, including clones and emulators. Can anyone help? Thanks, Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help: Function to tell whether display is better than QL standard
Yes, display_cde is the one I was thinking of. I think I can get all I want from this. Thanks for jogging my memory and many thanks to Dilwyn for the toolkit in the first place! Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of tobias.froesc...@t-online.de Sent: 28 February 2011 14:50 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help: Function to tell whether display is better than QL standard Adrian, there is (I think) not a single function that allows to retrieve this information, but some strong hints from the system that GD2 is there: - Use SD.EXTOP and check offset $64 of the channel table - this gives you the number of bytes per scanline. - use MT.DMODE to retrieve the screen mode Divide scan line length*8 by the number of colour bits for the detected mode, should give you a hint on screen width when you cannot detect PE (The screen height is, I think not easy to detect when no PE is present) If you can detect PE, use iop.flim to get width and height from the PE directly. The only system with resolutions 512x256 and no PE is, to my knowledge, uQLX. Dilwyn's page has the wonderful display_cde toolkit that incorporates this (and a few other display related calls into a wonderful S*Basic extension. Cheers, Tobias -Original-Nachricht- Subject: [Ql-Users] Help: Function to tell whether display is better than QL standard Date: Mon, 28 Feb 2011 15:01:55 +0100 From: Adrian Ives adr...@acanthis.co.uk To: ql-us...@q-v-d.com I know I've seen this somewhere but, as usual, when you really want something it refuses to be found! I'm looking for a function to use in S*BASIC that will tell me if the display driver is capable of providing resolutions greater than the QL's mode 4 8 defaults - it would be enough just to know if the display driver is GD2 or not. It has to run on any QL system, including clones and emulators. Can anyone help? Thanks, Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help: Function to tell whether display is better than QL standard
That's also a good way of doing it. Thanks, George. -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of gdgqler Sent: 28 February 2011 15:09 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help: Function to tell whether display is better than QL standard On 28 Feb 2011, at 14:01, Adrian Ives wrote: I know I've seen this somewhere but, as usual, when you really want something it refuses to be found! I'm looking for a function to use in S*BASIC that will tell me if the display driver is capable of providing resolutions greater than the QL's mode 4 8 defaults - it would be enough just to know if the display driver is GD2 or not. It has to run on any QL system, including clones and emulators. Can anyone help? I look to see if WM_BLOCK is a valid keyword. If so then I assume that GD2 colours are there. By using TURBO I am able to replace WM_BLOCK by a valid keyword even though the real WM_BLOCK is not there. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help: Function to tell whether display is betterthan QL standard
Many thanks, Dilwyn. This all came about because ... I've only just found time to revisit the original Ser-USB File Manager program (now called USBWiz Terminal). It was written over a year ago and needed some updating. Because this program has to be able to run with nothing more than Toolkit 2 loaded, the first thing I had to do was to incorporate any machine code extensions into the Turbo'd task. It was while doing this that I remembered Simon Goodwin's W_STORE and W_SHOW functions, which I'd used for for its popup menus ... and they don't work with the higher screen resolutions! I couldn't find any high resolution replacements, so if the USBWiz Terminal is running on anything greater than Mode 8 it's going to insist that the pointer environment is there to handle its window saves and restores ... unless anyone knows of updated versions of W_STORE and W_SHOW? I don't have time to muck about developing my own at the moment. The PE version - when I get around to writing it - won't have this problem. I now have two volunteers for testing the driver and expect to release the first beta on the 14th March, after myself and my wife have (hopefully) had a nice holiday ;) Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Dilwyn Jones Sent: 28 February 2011 16:26 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help: Function to tell whether display is betterthan QL standard - Original Message - From: Adrian Ives adr...@acanthis.co.uk To: ql-us...@q-v-d.com Sent: Monday, February 28, 2011 3:26 PM Subject: Re: [Ql-Users] Help: Function to tell whether display is betterthan QL standard Yes, display_cde is the one I was thinking of. I think I can get all I want from this. Thanks for jogging my memory and many thanks to Dilwyn for the toolkit in the first place! Adrian Adrian - please feel free to use or adapt display_cde in any way you see fit. The sources are I think included in the package on the Toolkits page on my site, if not, just send me a private email and I'll send them. -- Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ser-USB Driver running under Q-emuLator
Tony, I don't use the file system access functions, only direct sector access. The SD card or USB hard drive really is formatted as a QLW1 volume. otoh The File Manager (which is a standalone program independent of the driver) does use the file system access functions to let users move files between PCs and QLs using FAT16 format media. This obviously means that QL filenames are truncated to 8.3, but their headers are preserved. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Tony Firshman Sent: 28 February 2011 21:58 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ser-USB Driver running under Q-emuLator Adrian Ives wrote, on 28/Feb/11 11:33 | Feb28: Tony, If you're talking about the drivers built into the USBWiz, there's USB printer support and HID for mice and keyboards SNIP The Ser-USB driver currently supports SD Cards and USB Mass Storage devices; both accessed in native QDOS mode. Those were the two that immediately looked practical. I thought it supported only FAT 8.3? How do you work around that? Tony ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB Driver running under Q-emuLator
I was asked this question recently and have only just got around to testing it. Yes, it does work! Tested this evening under Q-emuLator 3.0.2 with a JS ROM image on Windows 7 64 bit with a USB to Serial adapter connecting to the Ser-USB unit. Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ranting: A Story of two Operating Systems
It's easier said than done, though. You can't exactly whip the JS ROMs out of a QL and slap in SMSQ. So for those people who want to keep their QLs in service, or are just emotionally attached to them, they don't have the ability to enter the 90s in that way :) Hmmmn ... is it possible to make a ROM-able SMSQ? and make an adapter to fit it into a standard QL? From memory it would need at least a 256K ROM - add in a couple of meg of RAM at the same time on some kind of processor daughter board and ... Bob's your uncle! ... QL users literally rushing into the 1990s ... the 2000s ... the 2010s ... and beyond! Sounds like a job for Dave Park to me. :) Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Marcel Kilgus Sent: 24 February 2011 17:02 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ranting: A Story of two Operating Systems Dilwyn Jones wrote: Authors of QL software like me use JM and JS ROMs to test software for compatibility. Probably the only thing I use them for, though. Yeah, but that's something you didn't have to do if people would at least be willing to enter the 90s, QL wise ;) I had Minerva in all my QLs, and that was over 15 years ago... Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ranting: A Story of two Operating Systems
Sorry, I must have misunderstood. I thought from your original mail that you were saying that you had Minervae in your machines over 15 years ago. So, is this really a case of QL users rushing *back* in time to the 90s? ;) -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Marcel Kilgus Sent: 24 February 2011 18:54 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ranting: A Story of two Operating Systems Adrian Ives wrote: It's easier said than done, though. You can't exactly whip the JS ROMs out of a QL and slap in SMSQ. SMSQ? I'm talking Minerva here... and you certainly can whip out a JS ROM and put Minerva in there ;) I've never owned a machine capable of running SMSQ/E before creating QPC (got an SGC system on loan to develop SMSQ/E for QPC before QPC was capable of doing it itself, but that wasn't mine). Minerva on the other hand was a must, especially for non-(S)GC QLs. Hmmmn ... is it possible to make a ROM-able SMSQ? Probably, but for SMSQ/E it's really more practical to leave the QDOS ROMs in and just use them as a bootloader. Cheers, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ranting: A Story of two Operating Systems
So, in order to allow users to RESPR additional extensions after loading the Ser-USB driver, I changed the mechanism for the way in which it starts its Queue Manager task. It was quite elegant, really: setting a flag bit the first time that Queue Manager services were needed to be picked up later by the scheduler loop task which would start the manager. Under SMSQ? No problem. Sorted. Under QDOS? BLAM **^%%^$£$£ Now I have probably missed some important piece of documentation somewhere that says you're not allowed to do trap 1, mt.cjob in a scheduler loop task under QDOS, but you are allowed to in SMSQ. The QDOS documentation that I have doesn't say that you can't do this - but, fair enough, thinking about it I suppose the call would mess with the job table and might muck things up when a return is made to the scheduler. OK, that's that, it can't be done. I accept it. I'm moving on. But what I would really like is some kind of document that sets out a list of things that fall in the category: This should work under QDOS, it says it should, but it doesn't but we went ahead and fixed it in SMSQ This is not just for me, but for any other poor sod who has to try developing system level code to run under both platforms. This is not the first time that I've encountered things that should work under QDOS but don't, yet they work fine under SMSQ. It's fixed now. The QDOS underclass will have to manually issue a USB_START command after they've loaded any other extensions, while SMSQ users can be confident that the driver will automatically start queue management when needed. Further down my list is to start testing under Minerva. I'm dreading it. :( Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ranting: A Story of two Operating Systems
Page 34 of the QL Technical Guide; 6.3.3 Scheduler Loop Tasks states that: Calls from the scheduler loop do not interrupt atomic tasks. This means that operations such as allocating or releasing memory can be performed safely. Now admittedly it doesn't say This means that operations such as allocating or releasing memory AND starting jobs but, conversely, the definitive QDOS reference written by the author of QDOS himself doesn't say anywhere else that you can't. But anyway it's all a word game. We're probably doing things now with the QL platform that were never even imagined back when the machine and its original OS were first produced. In the driver I have decided to implement an OS Capability byte, which has bits set to indicate that the current OS is capable (or not capable) of doing things in a certain way. Bit 0 just got allocated to the function: Can launch tasks from the scheduler loop Maybe I'll be able to set it high for Minerva as well ;) In any event, I'm sure there will be a few more bits allocated before this driver makes it out of beta. I suspect that if I'd taken the path of simply not supporting QDOS (which, believe me, I would have loved to have done) the resulting product would be too restrictive to be useful. Anyway, I have no criticisms of SMSQ and the way it does things, nor of QPC2 - which has enabled me to develop this code so quickly. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Marcel Kilgus Sent: 23 February 2011 12:21 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ranting: A Story of two Operating Systems Where does it say it should work under QDOS? I guess this wasn't consciously fixed in SMSQ/E, it's probably more a side effect of the new implementation. And documenting all possible side effects borders on the impossible, unfortunately. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB Testing Screenshots
Here are some screenshots, taken off the image of an LCD monitor connected to an Aurora/SGC/superHermes QL: http://img202.imageshack.us/g/serusbtesting012.jpg/ There will be more pictures of the Ser-USB prototype in the forthcoming QL Today article. If the screen layout is not the familiar, homely red, white and black that you're used to seeing, it's because the windows have been redefined to fit in the monitor's displayable area. Here's the floppy disk boot program (ipcextuk_bin is the driver for superHermes external keyboard): 100 a=RESPR(6000) 110 LBYTES 'flp1_ipcextuk_bin',a 120 CALL a 130 REMark --- 140 REMark Set Windows for Aurora 150 REMark --- 160 WINDOW #0,512,256,0,0 : CLS #0 170 WINDOW #1,490,206,18,12 180 WINDOW #2,490,206,18,12 190 WINDOW #0,490,32,18,218 200 PAPER #1,0 : INK #1,7 : BORDER #1,1,7 210 PAPER #2,0 : INK #2,7 : BORDER #2,1,7 220 BORDER #0,1,7 230 CLS #0 : CLS 240 PRINT Load Ser-USB Driver? 250 a$= INKEY$(-1) 260 IF a$ INSTR yY THEN 270 a= RESPR(2) 280 LBYTES 'flp1_ser_usb_bin',a 290 CALL a 300 END IF Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB Driver Update
Current version is 0.04 Build 002. Development is now frozen while I finish testing so that I'm satisfied it's good enough to put out as a beta. The INPUT bug reported last time is fixed (slave block issue). Problematic initial handshaking under JM QDOS is fixed (yet again!) with a better retry and timeout mechanism. Calls down to the SER driver are now all made with zero timeout when in supervisor mode (as they should have been!). USB_RESTART command allows the driver to be restarted if it didn't detect the Ser-USB, or if you forgot to connect it. S*BASIC USB_PUTCMD, USB_GETCMD and USB_GETCMD$ interface to the driver layer is working. Implemented an auxiliary stack to get around QDOS's dreadfully small supervisor stack allocation when calling into the driver (even the original QUBIDE code had managed to exceed the 64 byte limit at one point). Driver is now layered to enable the hardware interface to be replaced. Default I/O mode is synchronous to preserve memory on low-end systems; asynchronous I/O functions are still available through the API for user programs. I would appreciate it if anyone who wants to help with the beta-testing could get in touch with me off-list. And now I'm having a few driver-free days ;) Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] MasterSpy Configuration
Has anyone out there got the top secret list of configuration offsets for the MasterSpy editor executable? I've wasted over an hour trying to change the size of the primary console, but I don't seem to be hitting the right bytes to poke. It's not just a question of overwriting the CON_ definition, there are obviously some bytes to poke for the xpos, ypos,width height. I thought these were at offsets 97,98,101 and 103 (because they matched the original CON definition) but they just seem to be there to deliberately mislead people trying to configure the damn thing without the manual! Grr!!! Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] MasterSpy Configuration
OK, I've found secret offsets 167 168, which set the number of rows and columns. The CON definition appears to be a Guardian window for the pointer environment. What I can't find is any way to set the position of the MasterSpy window relative to the Guardian. My manual for this very nice binary-capable editor went missing a long time ago, but wasn't there ever a configuration utility written for it? Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Adrian Ives Sent: 20 February 2011 10:14 To: ql-us...@q-v-d.com Subject: [Ql-Users] MasterSpy Configuration Has anyone out there got the top secret list of configuration offsets for the MasterSpy editor executable? I've wasted over an hour trying to change the size of the primary console, but I don't seem to be hitting the right bytes to poke. It's not just a question of overwriting the CON_ definition, there are obviously some bytes to poke for the xpos, ypos,width height. I thought these were at offsets 97,98,101 and 103 (because they matched the original CON definition) but they just seem to be there to deliberately mislead people trying to configure the damn thing without the manual! Grr!!! Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] A Landmark Moment for the Ser-USB Driver!
This morning at 10:50 GMT the latest version of the driver, running under a QDOS JM ROM, successfully loaded a file into the MasterSpy editor without crashing. This issue has been bugging me for days, but was finally traced to some errant mode swapping code that allowed an IOSS retry to happen when the process that was being retried hadn't actually surrendered control. Now, all I have to figure out is why an S*BASIC INPUT statement causes a hang under QDOS but not under SMSQ . unless the driver's Asynchronous Read facility is turned on. ;) I'm still planning for a test release mid March, when anyone who has a USBWiz that they can connect is welcome to try it out. Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] A Landmark Moment for the Ser-USB Driver!
Yes, that's the one. You also need some circuitry to translate RS232 to TTL levels. A MAX232 chip and a handful of capacitors is what the Ser-USB prototype uses to do this. If you search on eBay you can often find ready-made RS232/TTL converter modules intended for programming satellite TV boxes. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Petri Pellinen Sent: 20 February 2011 12:03 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] A Landmark Moment for the Ser-USB Driver! Congratulations Adrian. Is this the USBWiz module you are writing the driver for? http://www.crownhill.co.uk/product.php?prod= Best regards, Petri On Sun, Feb 20, 2011 at 1:06 PM, Adrian Ives adr...@acanthis.co.uk wrote: This morning at 10:50 GMT the latest version of the driver, running under a QDOS JM ROM, successfully loaded a file into the MasterSpy editor without crashing. This issue has been bugging me for days, but was finally traced to some errant mode swapping code that allowed an IOSS retry to happen when the process that was being retried hadn't actually surrendered control. Now, all I have to figure out is why an S*BASIC INPUT statement causes a hang under QDOS but not under SMSQ . unless the driver's Asynchronous Read facility is turned on. ;) I'm still planning for a test release mid March, when anyone who has a USBWiz that they can connect is welcome to try it out. Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Looking for inspiration: Death by MT.CJOB
I'm scratching my head over this ridiculously simple piece of code that works fine under SMSQ but locks a QDOS JM-ROM Aurora/SGC every time: moveq #mt.cjob,d0 moveq #0,d1 ; Independent job moveq #16,d2 ; Enough room for job name move.l #1024,d3 ; Some stack space sub.l a1,a1 ; Start address 0 trap#1 ; Create a job It's getting called at the end of a device driver installation, but actually it doesn't seem to matter how it gets called . it locks up the OS! And as I say, SMSQ has happily executed the same code hundreds of times (if not thousands by now). I've tried numerous combinations of code size and dataspace size; the only difference being that reducing the dataspace size below 512 causes the infamous message PROC/FN Cleared to appear . and still locks QDOS. Any suggestions - however much out of the box - would be much appreciated. Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Looking for inspiration: Death by MT.CJOB
Got the b***ard I had code like this bracketing it ... move.l a6,-(sp) ... my mt.cjob call and other code ... move.l (sp)+,a6 I was calling this all from SuperBASIC with a RESPR/CALL and my theory is that making a call to mt.cjob caused QDOS to do some shuffling around, changing the value of a6 - except that I then restored it with the value that it started with - now the wrong value! Now I'm one step closer to Ser-USB running on an unexpanded QL ;) Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Adrian Ives Sent: 18 February 2011 17:37 To: ql-us...@q-v-d.com Subject: [Ql-Users] Looking for inspiration: Death by MT.CJOB I'm scratching my head over this ridiculously simple piece of code that works fine under SMSQ but locks a QDOS JM-ROM Aurora/SGC every time: moveq #mt.cjob,d0 moveq #0,d1 ; Independent job moveq #16,d2 ; Enough room for job name move.l #1024,d3 ; Some stack space sub.l a1,a1 ; Start address 0 trap#1 ; Create a job It's getting called at the end of a device driver installation, but actually it doesn't seem to matter how it gets called . it locks up the OS! And as I say, SMSQ has happily executed the same code hundreds of times (if not thousands by now). I've tried numerous combinations of code size and dataspace size; the only difference being that reducing the dataspace size below 512 causes the infamous message PROC/FN Cleared to appear . and still locks QDOS. Any suggestions - however much out of the box - would be much appreciated. Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Looking for inspiration: Death by MT.CJOB
Well, I really should have picked up on a6 before - it's well known that you mustn't mess with it in extensions, but this was being invoked through a RESPR/LBYTES/CALL sequence and the issue hadn't occurred to me. It didn't help that SMSQ/E (neither under QPC2 nor on an Aurora SGC) didn't cause the fault to present! ;) which actually is a tribute to SMSQ's robustness. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Lee Privett Sent: 18 February 2011 18:57 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Looking for inspiration: Death by MT.CJOB Excellent Adrian, glad to se you making progress, sorry couldn't make any suggestions, machine code like my partners Greek is a language I have great difficulty with understanding. Lee - Original Message - From: Adrian Ives To: ql-us...@q-v-d.com Sent: Friday, February 18, 2011 6:20 PM Subject: Re: [Ql-Users] Looking for inspiration: Death by MT.CJOB Got the b***ard I had code like this bracketing it ... move.l a6,-(sp) ... my mt.cjob call and other code ... move.l (sp)+,a6 I was calling this all from SuperBASIC with a RESPR/CALL and my theory is that making a call to mt.cjob caused QDOS to do some shuffling around, changing the value of a6 - except that I then restored it with the value that it started with - now the wrong value! Now I'm one step closer to Ser-USB running on an unexpanded QL ;) Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Adrian Ives Sent: 18 February 2011 17:37 To: ql-us...@q-v-d.com Subject: [Ql-Users] Looking for inspiration: Death by MT.CJOB I'm scratching my head over this ridiculously simple piece of code that works fine under SMSQ but locks a QDOS JM-ROM Aurora/SGC every time: moveq #mt.cjob,d0 moveq #0,d1 ; Independent job moveq #16,d2 ; Enough room for job name move.l #1024,d3 ; Some stack space sub.l a1,a1 ; Start address 0 trap#1 ; Create a job It's getting called at the end of a device driver installation, but actually it doesn't seem to matter how it gets called . it locks up the OS! And as I say, SMSQ has happily executed the same code hundreds of times (if not thousands by now). I've tried numerous combinations of code size and dataspace size; the only difference being that reducing the dataspace size below 512 causes the infamous message PROC/FN Cleared to appear . and still locks QDOS. Any suggestions - however much out of the box - would be much appreciated. Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
Yes, I did this a year ago for my two SGCs and found the same difficulty - in my case it was proximity to the card in the next expansion slot of the Qplane. A surface mount battery holder will sort that. Rich, whatever did you do with the PCB design that I sent you for these battery holders back then? Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Bob Spelten Sent: 15 February 2011 13:31 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Gold card battery... On 14 Feb 2011, at 19:38, Plastic wrote: ... I would be happy to design and manufacture a limited run of these adaptors to use CR2032s so we can all have our battery backed clocks working again. Make sure the total height does not exceed the original. I had to shave of the legs of the holder to make it fit the QL without contacting the metal keyboard plate. Bob -- The BSJR QL software site at: http://members.chello.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Outputting from QPC to HTML
This, on the other hand I have used to do PDF to Word: http://www.anypdftools.com/pdf-converter.html -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Rich Mellor Sent: 14 February 2011 12:08 To: ql-us...@q-v-d.com Subject: [Ql-Users] Outputting from QPC to HTML I have a few documents (a fair size) which were written in Text 87. Using QPC + QPCPrint, I can output them to PDF, but ideally I would like to get them into HTML or another format suitable to put on the web. Does anyone have suggestions as to the best way of achieving this? -- Rich Mellor RWAP Services http://www.rwapsoftware.co.uk http://www.rwapservices.co.uk -- Try out our new site: http://sellmyretro.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ser-USB Driver Update: External Command Interface (and Progress Update)
Well, in that version it was because of the NUL device (although there are ways around that - any channel could be used as the target of a Turbo Toolkit SET_CHANNEL). However, I have now implemented three new commands which remove the need for all that mucking about ... USB_PUTCMD Byte [,Byte]: Put a command in the driver's command pipe. USB_GETCMD(): Get a long word command response from the driver's command pipe. USB_GETCMD$(): Get a long word command response from the driver's command pipe and return it as a string to S*BASIC. ... which makes the S*BASIC example look like this (also much faster): 100 PRINT The Response to Command $01 (Get Driver Version) was: GetResponse$(1) 110 PRINT The Response to Command $02 (Get Hardware Version) was: GetResponse$(2) 120 PRINT The Response to Command $03 (Get Hardware Type) was: GetResponse$(3) 130 PRINT The Response to Command $04 (Get I/O Queue Status) was: GetDWordResponse$(4) 140 PRINT The Response to Command $05 (Get I/O State) was: GetDWordResponse$(5) 150 PRINT The Response to Command $06 (Get Flags) was: Get32BitResponse$(6) 160 PRINT The Response to Command $11 (Get Mapped Physical Drive 1) was: GetDWordResponse$(HEX(11)) 170 REMark : 180 REMark === 190 REMark : 200 DEFine FuNction GetResponse$(Cmd%) 210 USB_PUTCMD Cmd% 220 RETurn USB_GETCMD$ 230 END DEFine GetResponse$ 240 REMark : 250 REMark === 260 REMark : 270 DEFine FuNction GetDWordResponse$(Cmd%) 280 LOCal Response, High%, Low% 290 USB_PUTCMD Cmd% 300 Response= USB_GETCMD 310 High%= Response DIV 65536 320 Low%= Response MOD 65536 330 RETurn High% '/' Low% 340 END DEFine GetDWordResponse$ 350 REMark : 360 REMark === 370 REMark : 380 DEFine FuNction Get32BitResponse$(Cmd%) 390 LOCal Response, High%, Low% 400 USB_PUTCMD Cmd% 410 Response= USB_GETCMD 420 High%= Response DIV 65536 430 Low%= Response MOD 65536 440 RETurn BIN$(High%,16) / BIN$(Low%,16) 450 END DEFine Get32BitResponse$ -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Plastic Sent: 13 February 2011 11:16 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ser-USB Driver Update: External Command Interface (and Progress Update) On Sun, Feb 13, 2011 at 1:09 AM, Adrian Ives adr...@acanthis.co.uk wrote: [SNIP] Here is a tidier version of the example S*BASIC program that I posted in my last mail. It shows how to use the interface in its current form. Requires SMSQ Turbo Toolkit (and the Ser-USB Driver). [SNIP] Is the SMSQ requirement permanent, or just for development purposes? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ser-USB Driver Update: External Command Interface (and Progress Update)
Bob, Hn. Well, I'm using SMSQ and I get this ... 65537 DIV 65536 = 1 65537 MOD 65536 = 1 128000 DIV 65536 = 1 128000 MOD 65536 = 62464 It's academic, anyway. This is just an example to show how you _could_ use these facilities. Thanks for pointing it out, though. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Bob Spelten Sent: 13 February 2011 13:44 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ser-USB Driver Update: External Command Interface (and Progress Update) Op Sun, 13 Feb 2011 13:10:41 +0100 schreef Adrian Ives adr...@acanthis.co.uk: 250 REMark === 260 REMark : 270 DEFine FuNction GetDWordResponse$(Cmd%) 280 LOCal Response, High%, Low% 290 USB_PUTCMD Cmd% 300 Response= USB_GETCMD 310 High%= Response DIV 65536 320 Low%= Response MOD 65536 330 RETurn High% '/' Low% 340 END DEFine GetDWordResponse$ 350 REMark : 360 REMark === 370 REMark : 380 DEFine FuNction Get32BitResponse$(Cmd%) 390 LOCal Response, High%, Low% 400 USB_PUTCMD Cmd% 410 Response= USB_GETCMD 420 High%= Response DIV 65536 430 Low%= Response MOD 65536 440 RETurn BIN$(High%,16) / BIN$(Low%,16) 450 END DEFine Get32BitResponse$ I think these functions need a little adjustment. The DIV MOD functions in S'Basic work on signed Integers and not on Longs. Value DIV 65536 will always produce zero. Value MOD 65536 will always produce value. There probably are Long DIV/MOD functions in some toolkit out there, I just happened to find one in an old Machine Code book. Otherwise just use '/' and INT to extract the high% and low% parts. high%=INT(response / 65536): low%=response -(high% * 65536) Bob -- The BSJR QL software site at: http://members.chello.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qemulator download
Try here: http://www.terdina.net/ql/winql.html -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Tony Firshman Sent: 13 February 2011 14:25 To: ql-us...@q-v-d.com Subject: [Ql-Users] Qemulator download I see Qemulator has moved form geocities. What link should I use for it? Tony -- QBBS (QL fido BBS 2:257/67) +44(0)1442-828255 t...@firshman.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB Driver Update: External Command Interface (and Progress Update)
Here is a list of the commands that the current version of the Ser-USB Driver can execute through its command pipe interface. This interface supports run-time interrogation and configuration of the driver and is intended to enable the development of utility software that does not require detailed knowledge of the underlying hardware. When the necessary code support is completed there will also be commands for mounting/unmounting partitions. This interface has primarily come about as a result of including run-time debugging so I would be very interested to hear any views on its usefulness, or what other features might be desirable. usbcmd_get_dr_ver $01 Get Driver Version Command Size: Byte Response Size: Long Returns the Ser-USB Driver version as four characters. usbcmd_get_hw_ver $02 Get Hardware Version Command Size: Byte Response Size: Long Returns the hardware (USBWiz) version as four characters. usbcmd_get_hw_type $03 Get Hardware Type Command Size: Byte Response Size: Long Returns the hardware type as four characters. USBWiz returns USBW. Other hardware types are supported as per the original QUBIDE defines (though these are unlikely to be encountered). usbcmd_get_q_stats $04 Get I/O Queue Stats Command Size: Byte Response Size: Long Returns statistics about the I/O Queue as a long word. High word contains the maximum I/O Queue size in requests. Low word contains the current number of entries in the queue. usbcmd_get_io_state $05 Get I/O State Command Size: Byte Response Size: Long Returns information about the currently executing I/O operation. High word contains the op code of the current operation (ip_op_read=1 or io_op_write=2). Low word contains the stage number in the operation. usbcmd_get_flags $06 Get Flags Command Size: Byte Response Size: Long Returns all flag bytes as one long word. High word contains the debug flags in the top 8 bits, the USBWiz flags in the bottom 8. Low word contains 0 in the top 8 bits, the Ser-USB Driver flags in the bottom 8. usbcmd_get_mphys_drv $10 Get Mapped Physical Drive Command Size: Byte with operand in low nibble ($11..$18) Response Size: Long Returns the physical drive/partition that is currently mapped to a USB drive number. High word contains the Logical Unit Number (LUN). Low word contains the partition number. The low nibble of command $10 is a logical drive number in the range 1..8; other values always return 0. usbcmd_clr_flag $e0 Clear Flag Command Size: Byte with operand in low nibble ($e0..$ef) Response Size: Long Clear a Ser-USB Driver or USBWiz flag. Returns the previous state of the flag as 0 or 1. The low nibble of command $e0 is broken down as follows: Bits 0..2 = Flag number (0..7). Bit 3 = 0 for Ser-USB Flags, or 1 for USBWiz Flags. usbcmd_set_flag $f0 Set Flag Command Size: Byte with operand in low nibble ($f0..$ff) Response Size: Long Set a Ser-USB Driver or USBWiz flag. Returns the previous state of the flag as 0 or 1. The low nibble of command $f0 is broken down as follows: Bits 0..2 = Flag number (0..7). Bit 3 = 0 for Ser-USB Flags, or 1 for USBWiz Flags. Here is a tidier version of the example S*BASIC program that I posted in my last mail. It shows how to use the interface in its current form. Requires SMSQ Turbo Toolkit (and the Ser-USB Driver). 100 OPEN #4,NUL 110 OPEN #5,NUL 120 SET_CHANNEL #4,USB_PIPE_W 130 SET_CHANNEL #5,USB_PIPE_R 140 PRINT The Response to Command $01 (Get Driver Version) was: GetResponse$(1) 150 PRINT The Response to Command $02 (Get Hardware Version) was: GetResponse$(2) 160 PRINT The Response to Command $03 (Get Hardware Type) was: GetResponse$(3) 170 PRINT The Response to Command $04 (Get I/O Queue Status) was: GetDWordResponse$(4) 180 PRINT The Response to Command $05 (Get I/O State) was: GetDWordResponse$(5) 190 PRINT The Response to Command $06 (Get Flags) was: Get32BitResponse$(6) 200 PRINT The Response to Command $11 (Get Mapped Physical Drive 1) was: GetDWordResponse$(HEX(11)) 210 REMark === 220 DEFine FuNction GetResponse$(Cmd%) 230 LOCal Response$, This$, Bytes% 240 PRINT #4;CHR$(Cmd%); 250 Response$= 260 Bytes%= 0 270 REPeat GetResponse 280 This$= INKEY$(#5) 290 IF This$ = THEN NEXT GetResponse 300 Response$= Response$ This$ 310 Bytes%= Bytes% + 1 320 IF Bytes% = 4 THEN EXIT GetResponse 330 END REPeat GetResponse 340 RETurn Response$ 350 END DEFine GetResponse$ 360 REMark === 370 DEFine FuNction GetDWordResponse$(Cmd%) 380 LOCal Response$, High%, Low% 390 Response$= GetResponse$(Cmd%) 400 High%= CODE(Response$(1))*256 + CODE(Response$(2)) 410 Low%= CODE(Response$(3))*256 + CODE(Response$(4)) 420 RETurn High% '/' Low% 430 END DEFine GetDWordResponse$ 440 REMark === 450 DEFine FuNction Get32BitResponse$(Cmd%) 460 LOCal Response$, High%, Low% 470 Response$= GetResponse$(Cmd%) 480 High%=
[Ql-Users] Ser-USB Driver Update w/e 11-FEB-2011
As of today there is a Ser-USB driver that's around 85% complete. The current version can mount, read, write and format SD cards/USB storage with a QLW1 partition, but it doesn't yet support multiple partitions on the same drive. All traps are implemented and some optimisation has been started, delivering a perceived performance at 56K that feels like a floppy disk - but even the default 9600 baud is useable, albeit somewhat pedestrian ;) The latest build has a standard level 2 config block allowing the default port name and baud rate to be configured. The hooks are also in place for load-time configuration upon hitting the F1 key after the banner is displayed. Now the bad news. I've started some application testing and I've already discovered a couple of incompatibilities. For instance, QD can load a file directly from a USBn_ device, but the MasterSpy editor locks up! The QPAC2 Files thing shows the device, but can't list the files unless the root directory is already in the slave blocks . that kind of thing. I'm hopeful that most of these issues can be resolved now that the core driver is working. I suspect that the main area of difficulty is the pitiful amount of stack that QDOS allocates when handing over to the device driver code! The Ser-USB API gets a little deep in places. Just for fun, here is an example of communicating with the driver through its command pipe (this example needs SMSQ/Turbo Toolkit): 100 OPEN #4,NUL 110 OPEN #5,NUL 120 SET_CHANNEL #4,USB_PIPE_W 130 SET_CHANNEL #5,USB_PIPE_R 140 PRINT #4;CHR$(1); 150 Response$= 160 Bytes%= 0 170 REPeat GetResponse1 180 This$= INKEY$(#5) 190 IF This$ = THEN NEXT GetResponse1 200 Response$= Response$ This$ 210 Bytes%= Bytes% + 1 220 IF Bytes% = 4 THEN EXIT GetResponse1 230 END REPeat GetResponse1 240 PRINT The Response to Command 01 (Get Driver Version) was: Response$ 250 PRINT #4;CHR$(2); 260 Response$= 270 Bytes%= 0 280 REPeat GetResponse2 290 This$= INKEY$(#5) 300 IF This$ = THEN NEXT GetResponse2 310 Response$= Response$ This$ 320 Bytes%= Bytes% + 1 330 IF Bytes% = 4 THEN EXIT GetResponse2 340 END REPeat GetResponse2 350 PRINT The Response to Command 02 (Get Hardware Version) was: Response$ The driver interface will be somewhat sleeker than this in the final build of course ;) Adrian In the interests of being open, and as I intend that this driver will ultimately become open source, here is this week's change log: 0.02.011 (OK) Unused messages removed. Optimised core:drv_inst. Removed usbdrv:usbwiz_link, core:set_d7, core:read_params. Fixed wrong register error in usbdrv:drive_select. USB_RD USB_WR now attempt to select correct physical drive if not current at start of process. 0.02.012 (OK) usbdrv:drive_capacity no longer returns a hard coded result, but instead establishes the size of the drive through iterative RS commands (USBWiz MS command won't work with direct sector access on non-FAT). usbdrv:usbwiz_fetch now able to exit faster on detection of an error return. New S*BASIC function USB_SIZE() returns the capacity of the selected drive. 0.02.013 (OK) Fixed bad error exits in usbdrv:usbwiz_fetch Added new debug messages in usbdrv:usbwiz_send and usbdrv:usbwiz_fetch. 0.02.014 (OK) Implemented new variable usb_fix_capacity to override calls to drive_capacity. New S*BASIC command USB_FIXSIZE to set usb_fix_capacity. 0.02.015 (OK) In usbdrv:usbwiz_queue_status, if an entry has a status of failed it will be set to complete so that it will automatically be purged when its retention count reaches zero. Map write delay now configurable at run-time. New function core:selected_drive to eventually replace the deprecated core:set_drive. In open:do_open, legacy calls to set_drive/write_block replaced with selected_drive/drive_write. Check at startup, just after driver version banner, for F5 pressed. If so, debug flag is set. 0.02.016 (OK) New constant io_queue_safe_limit determines how full the I/O Queue is allowed to get before I/O write operations are blocked. Implemented bit 29 of I/O request flag to indicate request came from forced slaving. forced:do_forced optimised; deprecated calls to drive_nbusy removed, legacy call to write_block replaced with drive_write. Documentation headers on read/write functions updated to reflect changes. 0.02.017 (OK) Incorporated the queue safe limit test into drive_read, so neither call can exhaust queue space (Bit 29 of d6 treated the same). Greatly simplified and cleaned up the project make file, removing the module boot entirely. Stripped out code to support ROM version (Ser-USB was never intended to be loaded from ROM - at least not conventionally). Simplied initialisation code and swapped order so that driver is initialised before S*BASIC PROCs FNs installed. Removed obsolete pointer hard_add from startup_asm. 0.02.018 (OK) Cleaned up the module
Re: [Ql-Users] Ser-USB Driver Update w/e 11-FEB-2011
Thanks. I will be looking for anybody who already has a USBWiz unit lying around (and who would be capable of connecting it to the QL) to volunteer to test the driver. I'm not there yet, but hopefully we're not talking months away. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of tobias.froesc...@t-online.de Sent: 11 February 2011 15:11 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Ser-USB Driver Update w/e 11-FEB-2011 Adrian, add me as second entry on that list. Also, I would like to offer help - should you need it. You seem to be making very good progress. Regards, Tobias -Original-Nachricht- Subject: Re: [Ql-Users] Ser-USB Driver Update w/e 11-FEB-2011 Date: Fri, 11 Feb 2011 14:53:41 +0100 From: Urs Koenig (QL) q...@bluewin.ch To: ql-us...@q-v-d.com Adrian Ives wrote: As of today there is a Ser-USB driver that's around 85% complete. The current version can mount, read, write and format SD cards/USB storage with a QLW1 partition, but it doesn't yet support multiple partitions on the same drive. All traps are implemented and some optimisation has been started, delivering a perceived performance at 56K that feels like a floppy disk - but even the default 9600 baud is useable, albeit somewhat pedestrian Sounds very promising. Please Go on! You can put me on the preorder-list for at least the driver. Urs ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] GWASS is updated
btw George, did you know that the links to SUDOKU and UCONFIG on your download page are broken? Are you updating the SUDOKU Solver to support octal as well? ;) -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of gdgqler Sent: 10 February 2011 09:56 To: ql-us...@q-v-d.com Subject: [Ql-Users] GWASS is updated It is gratifying that some have tried to access my website. I can now reveal that: A new version of GWASS is now available from my website http://gwiltprogs.info/ This allows the input of octal numbers by using the prefix AT (@). Thus 46 can now be entered as one of: 46 $2E @56 %101110 George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] File transfers
Peter, I'm afraid it's yet not possible to do SER to USB. There is only one Ser-USB prototype in existence at the moment, and the File Manager software (which would allow this to happen without the need for a special driver) has not been tested with such large volumes of data. Anyway, I'm not sure of the maximum speed of the Q40 serial ports, but unless they can do a sustained 115K+ it would be a slow process - albeit one that could run unattended once started (unlike floppies). Incidentally, the Ser-USB Enhanced File Manager (next on my ToDo list once the native driver is working), besides being a Pointer Environment app, will also be able to copy to/from SD Cards and removeable USB sticks mounted as QDOS devices under QPC or Q-emuLator. It will do this preserving the QDOS file headers, in the same way that it already does for FAT-format devices mounted on the Ser-USB unit. For now, I think it's probably floppies or possibly the serial port QL networking SERNET - which I'm afraid I know very little about. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Peter Baily Sent: 09 February 2011 17:52 To: QL Users Subject: [Ql-Users] File transfers I have a large number of files stored on the hard disk of a Q40 (original version) with two floppy drives: - loads of interesting stuff like Mark Knight's Fractal program. I wish to transfer this to a computer on which I use QPC2. Can anyone suggest a way of doing this? Doing this via HD floppies with a USB floppy drive on the second computer will take forever. e.g. - SER2 to USB stick with a QXL.WIN folder? - via an ethernet link? Has anyone solved this problem? Have I missed something in back issues of Quanta Mag or QLT? Please help! Peter ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] GWASS is updated
George, As I think was mentioned in another posting here, that link isn't working at the moment. Not for me on BT broadband, anyway. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of gdgqler Sent: 09 February 2011 16:21 To: ql-us...@q-v-d.com Subject: [Ql-Users] GWASS is updated A new version of GWASS is now available from my website http://gwiltprogs.com/ This allows the input of octal numbers by using the prefix AT (@). Thus 46 can now be entered as one of: 46 $2E @56 %101110 George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] GWASS is updated
For anyone who has been trying to download this, the correct URL is http://gwiltprogs.info George - Thanks for the update. -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of gdgqler Sent: 09 February 2011 16:21 To: ql-us...@q-v-d.com Subject: [Ql-Users] GWASS is updated A new version of GWASS is now available from my website http://gwiltprogs.com/ This allows the input of octal numbers by using the prefix AT (@). Thus 46 can now be entered as one of: 46 $2E @56 %101110 George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB Driver Update
Heh . talk about bad luck. Build 13 and the completion of the drive_capacity call, which establishes the true physical size of a drive (this was previously hard coded, as the USBWiz module cannot return media size information unless it has mounted a FAT file system). And that's when my old 256MB Bytestor SD card decided that it would no longer be able to read blocks beyond $fff! I think this is actually the first time that an SD card has failed on me and was a sober reminder that when they go bad - they really go BAD! Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] USBWiz Driver Update
Dave, Bill of Materials: Yes Schematics: Yes Plan: This will depend upon the likely demand. My initial question was intended to gauge this ... because, honestly, I don't know how many QLs remain in circulation and, of them, how many owners would consider buying this kind of hardware. Maybe they would like to wait and see if a microdrive-emulating SD card slot comes along ... I know I would buy one of _them_ if they were available today! Anyway, if the demand is only there for a handful of units, I will likely build them myself on an as-needed basis and then, obviously, it won't be possible to pass on the advantage of bulk pricing for the components - the most expensive of which is the USBWiz module. It's worth remembering that the single most important component of this project is the driver. Until that is completed there is really nothing viable to market. Regarding the driver, several I/O traps are still not fully implemented and proper performance and resilience testing cannot begin until that is done, but I'm making good progress. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Plastic Sent: 07 February 2011 10:15 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] USBWiz Driver Update Do you have a BOM for the hardware? A schematic? Or is it only ready-made boards, and if so, what is the bulk cost? How do you plan to make this into a product? Is that your plan? Dave On Mon, Feb 7, 2011 at 2:33 AM, Lee Privett lee.priv...@gmail.com wrote: Well I am definately interested in purchasing such a device, have you considered putting this forward to the Quanta Commitee to get it off the ground commercially? Lee Privett - Sent from my Laptop running XP but emulating the QL using QPC2 - Original Message - From: Malcolm Cadman q...@mcad.demon.co.uk To: ql-us...@q-v-d.com Sent: Sunday, February 06, 2011 8:36 PM Subject: Re: [Ql-Users] USBWiz Driver Update In message 001c01cbc23b$b4caf510$1e60df30$@acanthis.co.uk, Adrian Ives adr...@acanthis.co.uk writes Hi Adrian, Yes, using the USBWiz is a good idea. A new hardware project always creates interest. PS - This list is getting very busy, too. Just catching up on over 100 emails ... :-) I have no idea if anyone is remotely interested in this project to attach USB devices to a QL using a small card called a USBWiz. This device presents a serial interface and accepts AT style commands to communicate with many classes of USB device. I started working on this last year, but was delayed by some family problems and a move to another part of the country. My prototype hardware is a little black block that connects via a serial lead to a QL or Hermes serial port. The box has an SD card slot and two USB ports. In the past two weeks I have turned my original prototype driver inside out (not a trivial task, no wonder I missed an errant me equ 0 statement). The first version suffered from problems encountered when trying to do serial I/O while in supervisor mode (in effect, a driver on top of a driver). Today I successfully completed a test which involved writing a text file to a native QDOS format SD card, then reading it back again. The new driver switches to user mode to do asynchronous I/O over the standard serial port driver through an I/O queue which is managed by a Queue Manager job. In this it is very different from other device drivers and so will need a lot more testing. Not the least of which under QDOS as the driver has been developed under SMSQ. The framework is also in place to support real time communication with the driver core through a pipe mechanism. This is intended to allow queries to be sent to the driver, as opposed to its devices; a variation on a paper that I read about the possibility of implementing meta devices on the QL. Some time in the future I envisage a USB thing to act as the interface to this feature. Anyway, that's where I am. The new device driver has the name USB; USB1 is the SD card slot, USB2 and USB3 are the ports which can mount standard external hard drives or memory sticks. It reads and writes, but the format routine still needs completing (formatting is currently done with a S*BASIC utility) As well as the native QL driver I also have a File Manager which needs no driver (only a free serial port) and can read and write FAT format SD cards and USB hard drives. This software also supports the automatic saving and retrieving of the QDOS 64 byte header. This program currently runs in menu-driven character mode, but it is my intention to migrate it to a GD2 compliant pointer app in the very near future. So, my question is this: Is anyone actually interested in me devoting more time to finish this project? If (and it is still an if) the driver can
Re: [Ql-Users] USBWiz Driver Update
Actually I think that's a shame, Peter. I know there are technical and performance issues with going the MDV emulation route, maybe even insurmountable ones, but it had that kind of Wow Factor about it. I imagined it as the microdrive version of the Hxc Floppy Drive Emulator. But, anyway, if there was already an expansion bus (or ROM port) connected SD card interface then I wouldn't be pursuing the Ser-USB project, which was really the point I was making about product demand. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Peter Sent: 07 February 2011 13:39 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] USBWiz Driver Update Adrian Ives wrote: Maybe they would like to wait and see if a microdrive-emulating SD card slot comes along ... There will definitely be no microdrive-emulating SD card slot from me. What I had mentioned - as one of several ideas - was making an SD card harddisk which can be mechanically mounted at a microdrive slot. This would be just mechanical, no microdrive signals or drivers involved. All the best Peter ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] USBWiz Driver Update
Yes, and I'm not arguing with his eminently sensible decision; simply voicing a whim and an opinion. It's self evident that an SD card interface plugged into the expansion slot or even the ROM port would be a faster and more flexible solution than attempting to emulate a microdrive, and several orders of magnitude faster than a serial USB interface! Thanks for reminding me that it's not just a matter of fitting the SD card carrier into the hole vacated by the microdrive. ;) Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Plastic Sent: 07 February 2011 14:30 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] USBWiz Driver Update On Mon, Feb 7, 2011 at 8:24 AM, Adrian Ives adr...@acanthis.co.uk wrote: Actually I think that's a shame, Peter. I know there are technical and performance issues with going the MDV emulation route, maybe even insurmountable ones, but it had that kind of Wow Factor about it. I imagined it as the microdrive version of the Hxc Floppy Drive Emulator. But, anyway, if there was already an expansion bus (or ROM port) connected SD card interface then I wouldn't be pursuing the Ser-USB project, which was really the point I was making about product demand. It is trivial to design a SD card carrier that fits in the microdrive slots. The harder part is designing the interface, which is what I believe Peter has done. Peter has taken the capacity of SDHC cards and decided that them acting like HDs is better than them acting like microdrives, but this is separate from physically placing them in the microdrive slots - which is quite feasible as a simple adaption of what he has done. Peter, would you be interested in letting your interface use a SDHC carrier that fits in the MDV slot, if someone else designs/builds it? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB (USBWiz) Driver Update
For anyone who is following this project: Build 009 of the driver was completed and tested today. This fully implements the io.formt trap, meaning that you can now issue the command: FORMAT USB1_ Note: The Ser-USB format routine is much simpler than the QUBIDE original; it only prompts the user for a total size in Megabytes and the block size and then does the rest for you. If the combination of total size and block size would result in a partition with more than 65536 blocks, the user is advised and asked to select a larger block size and/or smaller partition size. Formatting is also a background process, meaning that in an S*BASIC session the FORMAT command completes almost immediately, leaving the drive is formatted in the background. As Ser-USB doesn't do low-level formatting the process is as quick as the time it takes to write a new Map and root directory. Adrian (ps Geoff W. - perhaps you could add a footnote to my QL Today article to reflect this latest news. Thanks.) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] USBWiz Driver Update
I have no idea if anyone is remotely interested in this project to attach USB devices to a QL using a small card called a USBWiz. This device presents a serial interface and accepts AT style commands to communicate with many classes of USB device. I started working on this last year, but was delayed by some family problems and a move to another part of the country. My prototype hardware is a little black block that connects via a serial lead to a QL or Hermes serial port. The box has an SD card slot and two USB ports. In the past two weeks I have turned my original prototype driver inside out (not a trivial task, no wonder I missed an errant me equ 0 statement). The first version suffered from problems encountered when trying to do serial I/O while in supervisor mode (in effect, a driver on top of a driver). Today I successfully completed a test which involved writing a text file to a native QDOS format SD card, then reading it back again. The new driver switches to user mode to do asynchronous I/O over the standard serial port driver through an I/O queue which is managed by a Queue Manager job. In this it is very different from other device drivers and so will need a lot more testing. Not the least of which under QDOS as the driver has been developed under SMSQ. The framework is also in place to support real time communication with the driver core through a pipe mechanism. This is intended to allow queries to be sent to the driver, as opposed to its devices; a variation on a paper that I read about the possibility of implementing meta devices on the QL. Some time in the future I envisage a USB thing to act as the interface to this feature. Anyway, that's where I am. The new device driver has the name USB; USB1 is the SD card slot, USB2 and USB3 are the ports which can mount standard external hard drives or memory sticks. It reads and writes, but the format routine still needs completing (formatting is currently done with a S*BASIC utility) As well as the native QL driver I also have a File Manager which needs no driver (only a free serial port) and can read and write FAT format SD cards and USB hard drives. This software also supports the automatic saving and retrieving of the QDOS 64 byte header. This program currently runs in menu-driven character mode, but it is my intention to migrate it to a GD2 compliant pointer app in the very near future. So, my question is this: Is anyone actually interested in me devoting more time to finish this project? If (and it is still an if) the driver can be brought to a release-stable state, is there interest in a commercial product based around this? Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] USBWiz Driver Update
Petri, My aim is to support a standard QL, but I don't want to mislead anybody: there are obviously many limitations of the standard serial ports, not the least of which being the maximum speed! On an Aurora QL with superHermes I was getting reliable working at 56Kbps and intermittent working at 115K - on a standard QL 9.6K is the practical maximum. There will also be limitations caused by the lack of memory on an unexpanded QL, limiting the amount of buffers that the driver can allocate to keep things moving. otoh The standalone File Manager works quite well on a bog standard QL and, with the USBWiz native support of the FAT file system, is ideal for transferring files between machines (QL, PC or Mac). Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Petri Pellinen Sent: 01 February 2011 18:30 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] USBWiz Driver Update Hi Adrian, if this would work on a standard QL I would very interested in a commercial product. Best regards, Petri On Tue, Feb 1, 2011 at 8:13 PM, Adrian Ives adr...@acanthis.co.uk wrote: So, my question is this: Is anyone actually interested in me devoting more time to finish this project? If (and it is still an if) the driver can be brought to a release-stable state, is there interest in a commercial product based around this? ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Help! Reasons for MT.FRJOB Failing
I am in the process of rewriting the USBWiz driver to get around the problems with supervisor mode that I encountered last year. The new driver spawns independent jobs to handle reads and writes asynchronously in the background (because it has to invoke serial IO). I'm doing the work in QPC2 and I've encountered a problem with calls to MT.FRJOB. This is the code that I'm using at the end of my USB_RD (and USB_WR) job: moveq #mt.frjob,d0 moveq #me,d1 moveq #0,d3 trap#1 ; Remove ourselves! The only problem is that it doesn't work! It actually returns err.nc (Not Complete) and the job continues executing. Calls to mt.susjb and mt.prior succeed (d0 is zero on return) but don't actually do what they should. I'm beginning to think it's a QPC2 thing, but before I unpack the Aurora QL from its hermetically sealed casket in the garden shed, can anyone shed any light on the reasons why these traps should fail in this way? Many thanks Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
George, That had occurred to me as well, but this section of code is definitely executing in user mode. The job can be manually removed using an S*BASIC RJOB command or from the QPAC Jobs list. However, I'm sure the clue does lie in the fact that the trap is not guaranteed atomic. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of gdgqler Sent: 30 January 2011 10:37 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing On 30 Jan 2011, at 10:25, Adrian Ives wrote: I am in the process of rewriting the USBWiz driver to get around the problems with supervisor mode that I encountered last year. The new driver spawns independent jobs to handle reads and writes asynchronously in the background (because it has to invoke serial IO). I'm doing the work in QPC2 and I've encountered a problem with calls to MT.FRJOB. This is the code that I'm using at the end of my USB_RD (and USB_WR) job: moveq #mt.frjob,d0 moveq #me,d1 moveq #0,d3 trap#1 ; Remove ourselves! The only problem is that it doesn't work! It actually returns err.nc (Not Complete) and the job continues executing. Calls to mt.susjb and mt.prior succeed (d0 is zero on return) but don't actually do what they should. I'm beginning to think it's a QPC2 thing, but before I unpack the Aurora QL from its hermetically sealed casket in the garden shed, can anyone shed any light on the reasons why these traps should fail in this way? mt.frjob may not work in supervisor mode. The manual (Dickens) says this trap is not guaranteed atomic. Could this be the problem? George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
Well I've worked around the issue (for now). In the end I have had to add an extra step to my driver's 50HZ timer tick service that checks if the I/O job is still running (and is due for removal) and then issues an mt.frjob there. I still have no explanation as to why the job is seemingly unable to remove itself, or why other job control traps are behaving so strangely in the spawned jobs. So ... development of the USBWiz driver project continues. The old version of the driver could mount and read/write a QDOS format SD card, but stalled when doing slaved writes or large reads. This new version uses a totally different architecture but that has introduced a whole new set of problems. I'm hopeful that they can be solved in time ... but then the question is whether anyone would want a USB device that is read/written at the maximum speed of the serial port! :( Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Adrian Ives Sent: 30 January 2011 11:18 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing George, That had occurred to me as well, but this section of code is definitely executing in user mode. The job can be manually removed using an S*BASIC RJOB command or from the QPAC Jobs list. However, I'm sure the clue does lie in the fact that the trap is not guaranteed atomic. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of gdgqler Sent: 30 January 2011 10:37 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing On 30 Jan 2011, at 10:25, Adrian Ives wrote: I am in the process of rewriting the USBWiz driver to get around the problems with supervisor mode that I encountered last year. The new driver spawns independent jobs to handle reads and writes asynchronously in the background (because it has to invoke serial IO). I'm doing the work in QPC2 and I've encountered a problem with calls to MT.FRJOB. This is the code that I'm using at the end of my USB_RD (and USB_WR) job: moveq #mt.frjob,d0 moveq #me,d1 moveq #0,d3 trap#1 ; Remove ourselves! The only problem is that it doesn't work! It actually returns err.nc (Not Complete) and the job continues executing. Calls to mt.susjb and mt.prior succeed (d0 is zero on return) but don't actually do what they should. I'm beginning to think it's a QPC2 thing, but before I unpack the Aurora QL from its hermetically sealed casket in the garden shed, can anyone shed any light on the reasons why these traps should fail in this way? mt.frjob may not work in supervisor mode. The manual (Dickens) says this trap is not guaranteed atomic. Could this be the problem? George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
It's worth bearing in mind that I'm developing under SMSQ/E on QPC2, which post-date Pennel and Dickens, either environment may have an effect. In any case, my job definitely continued to execute after the Trap #1 and even doing the kill_me looping branch didn't solve the problem - it just kept calling mt.frjob ad infinitum! I'll need to dig further into this because even though I now have a solution, I don't like not understanding why the behaviour is there in the first place. Or why, in the same job, calls to mt.susjb or mt.prior all return 0 in d0, apparently indicating success, but don't actually do anything! Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of gdgqler Sent: 30 January 2011 17:07 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing On 30 Jan 2011, at 16:47, Norman Dunbar wrote: Interesting. I've never to my knowledge needed the final branch in any of my programs. With the branch in, the program is not going to do very much until it eventually decides to stop. Without that anything may presumably occur. I have a funny feeling you called me to task many years ago in QL Toady when I wrote some code with it in! ;-) That is highly unlikely. In fact I often use for testing a small program which ends by running through to the suicide code. Each time I look at this I remind myself that nothing can happen after the Trap #1. But it appears it can! Both Pennel and Dickens say that the only error that can occur with mt.frjob is -2, invalid job. So not complete can't occur. H! George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
No, it isn't. me is defined as -1, for the current job. -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Marcel Kilgus Sent: 30 January 2011 21:20 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing Adrian Ives wrote: moveq #mt.frjob,d0 moveq #me,d1 moveq #0,d3 trap#1 Check the disassembly. I guess D1 is set to 0. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing
I was 100% certain, but I went back and checked this and you're right - too much late night editing! This solves the mystery, because Job 0 cannot be removed. However, on the plus side, this problem actually allowed me to develop a tidier method of managing the spawned jobs. Many thanks for your insight! -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Marcel Kilgus Sent: 30 January 2011 21:33 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Help! Reasons for MT.FRJOB Failing Adrian Ives wrote: No, it isn't. me is defined as -1, for the current job. Have you checked that in an actual disassembly or in a debugger or just had a look at the source? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new versionof QDOSMSQ?
Apart from the fact that you would need several orders of magnitude more processor power and a massive operating system rewrite to drive that little lot, it's a grand idea. ;) Honestly, I think the future of the QL - as with most retro computing - lies in emulation, but that doesn't have to be limited to emulation under Windows, MacOS or Linux. ... but I like the sound of an SD card reader emulating a microdrive. Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Lee Privett Sent: 29 January 2011 01:21 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] What would you most like to see in a new versionof QDOSMSQ? Part of the charm of the QL is the distinctive black box look so lets keep it as is (although I do like the 'pimp my QLs' seen here and there), if Quanta or others are looking for new projects to keep the QL alive then emulating everything that the current PC/MAC world has, is hardly exciting if the existing QL hardware doesn't meet even the most of todays basic computer standards (how will that attract new blood to the QL hive?). So shouldn't the expansion slot be revisited with a small harddrive + memory, the display output replaced by an HDMI port, the tv modulator output replaced by USB2 or USB3 connector, the microdrive with an SD card slot, net1 and net1 3.5 sockets replaced by audio in and out and QDOSMSQ is a plugin flashrom, I dont see what the problem is :-) Lee Privett - Sent from my Laptop running XP but emulating the QL using QPC2 - Original Message - From: Malcolm Cadman q...@mcad.demon.co.uk To: ql-us...@q-v-d.com Sent: Thursday, January 27, 2011 10:58 PM Subject: Re: [Ql-Users] What would you most like to see in a new versionof QDOSMSQ? In message 4d415c3e.2020...@dunbar-it.co.uk, Norman Dunbar nor...@dunbar-it.co.uk writes Hi Norman, Something for everyone ... :-) All of the things that you list are quite technical considerations. Most users you want something that does something very well without them having to bother too much about it. Hence the embedded capabilities being shown by mobile phones and ipads, etc. The new way or working is moving towards being a more intuitive interaction between human and machine - hence hand movement and touch, etc. So, a new OS would have to be a new paradigm, in the first place. I may regret starting this, but as the subject says, what would you like to see in QDOSMSQ given that we were starting from scratch with the intention of writing a completely new OS? Disclaimer: No, I'm NOT thinking of writing one! For me, the following: * Ability to hook into the OS from any language, Basic, Assembler, C, whatever. * A windowing system that is simple to use. From any language. * Libraries that applications can link to at run time, as opposed to static linking at compile time. * Multitasking, obviously! * A file system that is not restricted to 36 characters. See http://qdosmsq.dunbar-it.co.uk/blog/2009/05/whats-wrong-with-this-file -system/ for a pseudo-rant on the matter. * Industry standard floating point format. * Industry standard graphics format(s) - PNG, for example. JPG if we must! SVG would be nice. * Speed and efficiency! ;-) Cheers, Norman. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] iPlayer
I doubt QPC is having any effect. There's probably so much demand for that DRM-riddled proprietary media player that half the world are trying to download it simultaneously. I once thought about installing BBC iPlayer ... to recoup some of the cost of the criminally extortionate license tax ... but it never installed and never ran. That was on Windows Vista Home Premium, 32 bit. And ... yeah ... it did have QPC II installed :( -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Dilwyn Jones Sent: 18 January 2011 17:32 To: ql-users@lists.q-v-d.com Subject: [Ql-Users] iPlayer I need to ask a question which is slightly off-topic here. Does anyone use BBC iPlayer on the same PC as the BBC iPlayer? I just can't get it to download or install on this while QPC is running, or even in the same session after I shut down QPC. Anyone know why? (the PC is Windows XP Pro with SP3, 1.4GHz processor, 1GB RAM)) We also tried it on the notebook with Windows 7 Starter. It's just gone into a please wait loop for the last half hour, I don't know how long iPlayer download should take? QPC had been in use on that too. And further, does anyone have experience of it on a slow broadband - in theory we pay for up to 8mbs from Orange. It's never better than 2mbs (in fact BT say that's the best we can hope for here, irrespective of what Orange say). Last time I had iPlayer working, it was very jerky, pausing every few seconds, totally unusable, so I removed it. Anyone with experience of it on 2mb/s able to say if it should work at that speed? The BBC website has a hell of a lot of how good and essential this is but no useful help whatsoever. This is driving me up the wall at the moment because I've got a visitor and we are trying together to see if we can get it to work. Although it's a bit off topic, I know I'll get a quicker and more sensible answer here. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] USBWiz Update
When reading the latest QL Today I noticed a very brief mention of the USBWiz project, so this seems to be an approporiate time to give a brief update of where things stand. Firstly, the last six months or so have been hectic and any development has been impossible, not the least of which being because I and my wife have now moved to Cornwall and all of my QL stuff is awaiting unpacking from its storage crates. Anyway, the current position is this: 1) I have built a prototype USBWiz Black Box that contains the USBWiz and an RS232/TTL serial level converter. This presents two USB ports and one SD Card slot, several status LEDs and a serial connection to the QL. Power is via a generic Maplin 5V PSU intended originally to charge devices via their USB connection. 2) There is a functioning file manager program, written in TURBO'd SuperBasic that allows access to FAT formatted SD Cards and USB Drives. Files may be transferred to and from the QL, and the extended attributes (i.e. the 64 byte header for executables) is preserved. At the moment the program operates in character mode, but my plan is to migrate this to the Pointer Environment very soon. Using an Aurora and a superHermes I have been able to maintain reliable transfers at 115K. 3) There is a part functioning driver that allows SD Cards and USB Drives formatted as native QL volumes to be mounted, although the formatting has to be done with a standalone program. The driver DIR and STAT to function but is not yet capable of reading/writing complete files much larger than a couple of K . . Here is why: The driver is built upon the shell of the QUBIDE ROM, with its hardware access routines stripped out and replaced with calls to a layer that sits above the serial driver and processes Sector Read/Write commands (actually a very simple ATAPI command emulator). Unfortunately, the serial driver has to operate in Supervisor Mode and so does the USBWiz driver, so the result is a deadlock. I really need to go back to first principles to fix this, but just haven't had the time. One solution is to replace the serial driver with a unified driver that handles normal serial IO as well as the meta commands to get/put sectors via the USBWiz. I can't commit to any timescales, but I hope to restart development next month and had planned an article for submission to QL Today. So, in summary, this can be made to work; the question is whether the finished product would be fast enough to bring much benefit. I'm in a frame of mind at the moment that says the best way might be to build a custom board that plugs into the expansion connector . and that's a whole other ball game! Any thoughts or suggestions? Adrian ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
