Re: [Ql-Users] Gold card battery...
On Tue, Feb 15, 2011 at 5:47 PM, John Gilpin thegilp...@btinternet.comwrote: Sorry I have been out a bit today and therefore have missed quite a bit of the goings-on on the list. Firstly, my 3 Auroras - all with SGCs attached need new batteries and I even went to the trouble of building a prototype using vero-board, a CR2032 cell and a suitable battery holder - from Maplins - but had to experiment a bit to find something the correct diameter for the mounting pins resulting in a loose connection which is rather unsuitable and unreliable. I need three of any unit successfully produced. I offered to get 50 or 100 produced by QUANTA but didn't think the demand would be worth the efforts. Also, my prototype was too high to enable the SGC to slide into the aperture for the expansion port on the Black Box QL. This restriction does not apply to the Aurora expansion card which is mounted to a standard backplane with a QuBide board for the Hard Drive(s). The 7mm clearance from bottom of battery to the top of the case opening is not the worst limiting factor. The problem is the CPU in socket sat next to it - this puts a width limitation on the PCB that means that the four pins need to be within 0.05 (1.27mm) of the corner/edge of the PCB. One solution to this is to invert the PCB, and have the battery on the bottom of the PCB. I will of course have to have the PCBs made with RED solder resist, so they match the gold cards. Please can you disclose your Surname so we know it's Dave Smith or Jones we're communicating with? Thanks. Dave Park of Austin, Texas, formerly of Bedford (where I worked at Sandy) and Milton Keynes, England. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] [QL-USAers] USA QLs...
On Tue, Feb 15, 2011 at 8:53 PM, David Tubbs davet...@tiscali.co.uk wrote: At 15:40 14/02/2011 -0600, you wrote: On Mon, Feb 14, 2011 at 3:37 PM, David Tubbs davet...@tiscali.co.uk wrote: I could send you photos with which you might reverse engineer. I also have a few dongle boards, some adapted for the 64k eprom, used in the past to slot in diff' QDOS, inside chips removed. Yes, photos would be very helpful. Dave ___ Where to send ? plasticu...@gmail.com is fine :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] The Spring 2011 QL Survery
Hi all! I now have 55 respondents. The results so far have definitely upset a few of my pre-existing views. Fascinating. I will close the survey on February 28th and release the full results on March 1st. I'll be sharing preliminary results with a few people before then, as the trends are fairly well defined at this point, so we can put some interesting commentary and interpretations in before that time. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Wed, Feb 16, 2011 at 4:15 AM, Tony Firshman t...@firshman.co.uk wrote: Plastic wrote, on 16/Feb/11 09:12 | Feb16: Dave/ Please can you disclose your Surname so we know it's Dave Smith or Jones we're communicating with? Thanks. Dave Park of Austin, Texas, formerly of Bedford (where I worked at Sandy) and Milton Keynes, England. That is not comprehensive enough - I want your place of birth, first school, secondary school and uni at the least (8-)# I liked David Tubbs oblique reference. (only joking of course) I was born at platform 11 waiting room, New Street Station, Birmingham. My first school was Stondon Lower School, which is, ironically, in UPPER Stondon, not Lower Stondon. I went to Churchill College in Cambridge. Anything else? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Wed, Feb 16, 2011 at 4:56 AM, Tony Firshman t...@firshman.co.uk wrote: That birthplace is very good isn't it - could be the subject of a David Lean film. Do you like steam trains (8-)# I was born in the same room as my mother in the village post office, Rhydlewis, Wales. Again unusual but not nearly as romantic as yours. Tony Thankfully some little indie British film called Harry Potter has added a mystique to train platforms, so now it has a New Charm(tm) ... On the subject of the Gold Card/SGC battery, the PCB is designed and tested, and I will be ordering the PCBs in about three weeks when I have some money coming to me. After that, things will move quite quickly. The only item I haven't sourced in satisfactory quality is the pins. Dave Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Pic test.
On Wed, Feb 16, 2011 at 6:30 AM, David Tubbs davet...@tiscali.co.uk wrote: If it is present, Modified eprom board, just as easyly hold two full ROM TK2 versions, Mainboard ROMs removed of course. Unfortunately, the lines aren't brought through to the ROM port to select chips outside of the 48-64K memory block, so OS chips can't be read through the port. (strictly speaking, the $8000 upper ROM could be placed in the ROM port and be readable, but that wouldn't be very useful. All that can be done with the ROM port is individual 16K ROM images can be placed there. There could be a choice of images switched in and out, but that's about it. They limited the internal $8000 ROM slot the same way - it only gets a CS signal for that 16K block, so you can't address a full 32k EPROM unless you attach the CS line from the ROM port to the upper ROM slot CS line. For those to whom this is Greek: CS means Chip Select. Take memory for example: there are 8 identical RAM chips, and each has access to the same address line (which tell the chip what address you're looking for) and data lines (where it puts the data for the address you asserted on the data lines.) As every chip is connected to the same address and data bus, you need a way to tell the chips I'm talking to you and so CHIP SELECT was born. So with 8 imaginary chips, and 128K of RAM, each chip stores 16k. You need an address decoder which takes the relevent lines of the address bus and creates an output to each chip as required. If the address bus on this imaginary computer is 16 bits wide (A0 to A15) and this 128K sits at a block from 0-128K (for example) then: A0 to A7 get passed to each chip. A8 thru A10 get passed to an address decoder A11 thru A15 get passed to a chip which makes sure they're all 0. IF they are all zero, and the address isn't over 128K, that chip tells the address decoder this is for you. The address decoder now knows that 1. This address is for you and two, it has three pins which it can now pas through a 3 to 8 line decoder: input output on 8 pins 000 = 0001 001 = 0010 010 = 0100 011 = 1000 100 = 0001 101 = 0010 110 = 0100 111 = 1000 So now the lines A8 through A10 work through the address decoder, permitted by the logic from A11+, to select which memory chip is being addressed. Obviously, this is a gross simplification of memory addressing, and the QL does it in two banks, and uses 4-bit chips so 2 chips need selecting to make the 8 bit wide data bus... But in principle, this is how it works, and this decision tree happens for every single memory access. Fun, huh? :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Pic test.
On Wed, Feb 16, 2011 at 8:27 AM, Tony Firshman t...@firshman.co.uk wrote: Plastic wrote, on 16/Feb/11 14:09 | Feb16: Fun, huh? :) It was particularly good fun with sH using similar decoding chips. Firstly we *knew* we could use three pins only to output the 8 bit keyrow. However Laurence then realised that the *same* three select lines could be used to read 8 separate input lines. This saved us ten Pic pins! It actually was the reason for many extra functions (spare RS232, DCD, Turbo and keylock). We simply wanted to fill all eight input lines! I haven't ever owned a SuperHermes, but I have read the manual. It is a fine piece of efficient and clever design, befitting the QL. Kudos to you and Lau. It's just the sort of thing I'd like to build in due course... Though in this day and age, supporting PS2 keyboards instead of the 5-pin DIN keyboards might be the only worthy upgrade. Any prospect, USBWiz thread, that the USB driver could support a USB class keyboard? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Wed, Feb 16, 2011 at 8:53 AM, gdgqler gdgq...@gmail.com wrote: On 16 Feb 2011, at 10:30, Plastic wrote: was born at platform 11 waiting room, New Street Station, Birmingham. In a handbag? Brummie women didn't 'ave 'andbags in the 60s. They 'ad clubs wi' 'idden compartments. Not saying my mom is tough, but the way she tells it, she was very put out that they wouldn't let her take the train and made her go to hospital to have me checked out. I mean, she paid for the tickets already. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] [ql-users] Backplanes...
Hi all, I have been asked off-list if I could make some backplanes. I have a stack of the connectors already, so, if there was demand, I could do this quite easily. The questions are: Is there any demand for this? Is there any deficiency or design issue with previous ones that needs correcting? (clearances? support? clean power?) How are they normally used/oriented? How could they be improved? How many expansion ports does your backplane have, how many do you use, and how many do you wish you had? Maybe people could send me photos off-list of their backplane set-ups so I can see what people are doing! Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Pic test.
On Wed, Feb 16, 2011 at 10:03 AM, Tony Firshman t...@firshman.co.uk wrote: Plastic wrote, on 16/Feb/11 14:48 | Feb16: On Wed, Feb 16, 2011 at 8:27 AM, Tony Firshmant...@firshman.co.uk wrote: Plastic wrote, on 16/Feb/11 14:09 | Feb16: Fun, huh? :) It was particularly good fun with sH using similar decoding chips. Firstly we *knew* we could use three pins only to output the 8 bit keyrow. However Laurence then realised that the *same* three select lines could be used to read 8 separate input lines. This saved us ten Pic pins! It actually was the reason for many extra functions (spare RS232, DCD, Turbo and keylock). We simply wanted to fill all eight input lines! I haven't ever owned a SuperHermes, but I have read the manual. It is a fine piece of efficient and clever design, befitting the QL. Kudos to you and Lau. It's just the sort of thing I'd like to build in due course... Though in this day and age, supporting PS2 keyboards instead of the 5-pin DIN keyboards might be the only worthy upgrade. Any prospect, USBWiz thread, that the USB driver could support a USB class keyboard? sH was designed and sold many years before PS/2 keyboards were around. It is a tribute to Lau's code that they work out of the box with the std adapter. I wonder whether Di-ren and the others do? Oddly designing code for these keyboards is very far from trivial. There are oddities and bugs. When we came across these, no keyboard manufacturer would assist. We sent a lot of money working on these these and we will not tell you was Cherry's response. http://www.computer-engineering.org/ps2protocol/ http://www.computer-engineering.org/ps2keyboard/ We've come a long way since the 90s ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Wed, Feb 16, 2011 at 10:08 AM, Tony Firshman t...@firshman.co.uk wrote: gdgqler wrote, on 16/Feb/11 14:53 | Feb16: On 16 Feb 2011, at 10:30, Plastic wrote: was born at platform 11 waiting room, New Street Station, Birmingham. In a handbag? Silly - that was Victoria on the Worthing line (8-)# and his name is not Ernest. Maybe here: http://www.travellerspoint.com/photos/stream/photoID/490908/orderByID/ That scares me. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] The Spring 2011 QL Survery
On Wed, Feb 16, 2011 at 10:35 AM, Geoff Wicks gtwi...@btinternet.comwrote: -- From: Plastic plasticu...@gmail.com Sent: Wednesday, February 16, 2011 10:08 AM To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] The Spring 2011 QL Survery Hi all! I now have 55 respondents. The results so far have definitely upset a few of my pre-existing views. Fascinating. I will close the survey on February 28th and release the full results on March 1st. I'll be sharing preliminary results with a few people before then, as the trends are fairly well defined at this point, so we can put some interesting commentary and interpretations in before that time. I don't want to pour cold water on what was a commendable initiative, but just a word of caution. Most respondents, perhaps all, are subscribers to this list. We are not typical of the QL Community. This has been Quanta's big mistake. Everyone, committee and members, assumed Quanta was the definitive voice of the UK QL community. We now know that there are twice as many non-Quanta UK QL-ers than there are Quanta UK QL-ers. All the same I shall look forward to seeing the results, As I discussed with others off-list, yes, I fully acknowledge the limitations of polling a single community. I will just publish the results and invite the list to draw their own conclusions publicly. I think there are some interesting trends that are so strong they would not necessarily be THAT different if polling a different community. So, yes, pinch of salt. Not completely dismissed either. Next time, I will try to co-ordinate with the Quanta magazine so the poll will be open in time for QL users and Quanta members to both access the poll. If Quanta would be interested in that... Next poll will focus on software, OS choices, and emulators. Dave (who can hear the accusations of anti-hardware bias in that poll coming over the horizon now!) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] [ql-users] Backplanes...
On Wed, Feb 16, 2011 at 11:05 AM, Rich Mellor r...@rwapservices.co.ukwrote: I have several backplanes available if anyone needs one: a) A Jurgen Falkenberg 2 slot unbuffered / unpowered backplane b) An unknown unbuffered / unpowered backplane which has a nice blue PCB - oddly it has 2 female connectors and 2 male connectors (any ideas - anyone.) c) A QPlane - powered buffered backplane, with 3 slots d) A Jurgen Falkenberg QL-Bus - see http://www.rwapadventures.com/ql_wiki/index.php?title=QL-Bus Rich, what do you make of the QPlane? I have one and am scared to use it. I wouldn't have used a 2-layer PCB for that purpose. I hear the Falkenburgs are decent, as is the MPlane. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] The Spring 2011 QL Survery
On Wed, Feb 16, 2011 at 11:39 AM, Rich Mellor r...@rwapservices.co.ukwrote: On 16/02/2011 17:13, Plastic wrote: On Wed, Feb 16, 2011 at 10:35 AM, Geoff Wicksgtwi...@btinternet.com wrote: -- From: Plasticplasticu...@gmail.com Sent: Wednesday, February 16, 2011 10:08 AM To:ql-us...@q-v-d.com Subject: Re: [Ql-Users] The Spring 2011 QL Survery Hi all! I now have 55 respondents. The results so far have definitely upset a few of my pre-existing views. Fascinating. I will close the survey on February 28th and release the full results on March 1st. I'll be sharing preliminary results with a few people before then, as the trends are fairly well defined at this point, so we can put some interesting commentary and interpretations in before that time. I don't want to pour cold water on what was a commendable initiative, but just a word of caution. Most respondents, perhaps all, are subscribers to this list. We are not typical of the QL Community. This has been Quanta's big mistake. Everyone, committee and members, assumed Quanta was the definitive voice of the UK QL community. We now know that there are twice as many non-Quanta UK QL-ers than there are Quanta UK QL-ers. All the same I shall look forward to seeing the results, As I discussed with others off-list, yes, I fully acknowledge the limitations of polling a single community. I will just publish the results and invite the list to draw their own conclusions publicly. I think there are some interesting trends that are so strong they would not necessarily be THAT different if polling a different community. So, yes, pinch of salt. Not completely dismissed either. Next time, I will try to co-ordinate with the Quanta magazine so the poll will be open in time for QL users and Quanta members to both access the poll. If Quanta would be interested in that... Next poll will focus on software, OS choices, and emulators. Dave (who can hear the accusations of anti-hardware bias in that poll coming over the horizon now!) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm The other main way of publicising the poll is through my database of QL users and customers. Unfortunately, the timing was poor for this survey, as I had only just sent out a mailshot !! The poll is open until February 28th. :) Next time, I will co-ordinate with you and Quanta if they so desire, and hopefully we'll get over 100 responses. The next poll, I'll also invite submitted questions. I will ask what is it you're trying to find out and try to structure the questions so they get answers that answer what they want to know - instead of answers to a question that doesn't really provide them the data they need. (I have decided a couple of my current questions are flawed in this way...) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] The Spring 2011 QL Survery
On Wed, Feb 16, 2011 at 3:13 PM, Lee Privett lee.priv...@gmail.com wrote: Can I suggest that for any survey done in the future that the QL community are notified through as many channels as possible well in advance so that timing of other such initiatives can be self-regulated or coordinate. For example if two or three main surveys a year are planned, then even if you don't know the exact date you know they are going to fall within a set timeframe e.g. the Christmas survey, the Easter survey, the Halloween survey, the guy fawkes survey these are just obvious suggestions but you get the idea and others would know that around such an such dates there will be a survey in whatever form. Lee Tony, funny coincidence but I was also born in the very same room that my mother was staying in also... This was the first survey so it has been a learning experience. I forgot the strong characters while I was away for seven years. ;) The next survey will be announced in advance. I will coordinate with Quanta and Rich Mellor's mailing list timing. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] The Spring 2011 QL Survery
On Wed, Feb 16, 2011 at 3:58 PM, QL-MyLink (f/fh) q...@mylink.adsl24.co.ukwrote: I've followed this thread... or so I though, but Dave (Plastic) what does this mean please? - strong characters Forceful characters, strong personalities. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Tue, Feb 15, 2011 at 7:31 AM, Bob Spelten b...@chello.nl wrote: 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. There is 7mm of clearance from the top of the ICs below the battery to the top of the tallest component., Most holders are 7.5mm tall. I have selected a surface mount, low profile holder that, with the PCB thickness, will not be taller than the surrounding components - which leaves 1.2mm of clearance. Hope this helps... Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Tue, Feb 15, 2011 at 7:56 AM, Tony Firshman t...@firshman.co.uk wrote: Bryan Horstmann wrote, on 15/Feb/11 13:42 | Feb15: On 15/02/2011 01:39, Plastic wrote: On Tue, Feb 15, 2011 at 7:31 AM, Bob Speltenb...@chello.nl wrote: 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. There is 7mm of clearance from the top of the ICs below the battery to the top of the tallest component., Most holders are 7.5mm tall. I have selected a surface mount, low profile holder that, with the PCB thickness, will not be taller than the surrounding components - which leaves 1.2mm of clearance. Hope this helps... Dave It seems to me that only two pins connect the battery, the other pair being support; am I right? Yes. I have seen some builds of GC/SGC with a plus sign but I don't think it is a=on all of them. Installation instructions will be needed. I will do a 1-off design verification board. Yes, only the top left pin was +3.0v, and the other three were 0v. On the GC only the bottom right pin was connected, but on other designs, other pins may have been used. So the PCB will have the +ve pin, then all the ground pins will be linked. This way, the board will also fit other designs that used the same battery. Later I will remove the ICs and continuity test to confirm the board is electrically the same as appearance, as it is a 4-layer board and there may be a hidden via. I will include full, IKEA-style instructions :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Tue, Feb 15, 2011 at 8:19 AM, Bryan Horstmann b...@newlan.org wrote: On 15/02/2011 02:03, Plastic wrote: On Tue, Feb 15, 2011 at 7:56 AM, Tony Firshmant...@firshman.co.uk wrote: Bryan Horstmann wrote, on 15/Feb/11 13:42 | Feb15: On 15/02/2011 01:39, Plastic wrote: On Tue, Feb 15, 2011 at 7:31 AM, Bob Speltenb...@chello.nl wrote: 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. There is 7mm of clearance from the top of the ICs below the battery to the top of the tallest component., Most holders are 7.5mm tall. I have selected a surface mount, low profile holder that, with the PCB thickness, will not be taller than the surrounding components - which leaves 1.2mm of clearance. Hope this helps... Dave It seems to me that only two pins connect the battery, the other pair being support; am I right? Yes. I have seen some builds of GC/SGC with a plus sign but I don't think it is a=on all of them. Installation instructions will be needed. I will do a 1-off design verification board. Yes, only the top left pin was +3.0v, and the other three were 0v. On the GC only the bottom right pin was connected, but on other designs, other pins may have been used. So the PCB will have the +ve pin, then all the ground pins will be linked. This way, the board will also fit other designs that used the same battery. Later I will remove the ICs and continuity test to confirm the board is electrically the same as appearance, as it is a 4-layer board and there may be a hidden via. I will include full, IKEA-style instructions :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3444 - Release Date: 02/14/11 On my SAFT battery only two pins are connected, + and - , the other two are isolated. Bryan On my SAFT example here (date code 97 12) there is a +ve indication top left but no -ve indication. All three other pins have continuity to each other. Is your different? Mine is labeled: === *+*SAFT memoguard 40 LF 220 Lithium 3V 97 02 === Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SQLUG Site
On Tue, Feb 15, 2011 at 10:10 AM, j...@supanet.com wrote: To all members. I am now able to update the SQLUG site and it should now be up todate. If there are any errors or alterations needed please let me know. John Sadler Link? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Spam, spam and more spam
On Tue, Feb 15, 2011 at 12:36 PM, Tony Firshman t...@firshman.co.uk wrote: David Tubbs wrote, on 15/Feb/11 17:58 | Feb15: So that's why I think such wasteful distribution is equivalent to spamming. Indeed. Top quoting does need some editing and snipping. Tony I suspect some email clients an be set n how he quote rmght be unware of the crud going out, I only use an old Eudora. No frills. ... and no spell checker (8-)# Thunderbird does have a QuoteCollapse extension that hides quoting, but *all* the gory details appear if one clicks 'reply' so no excuses for not ediitng in this case. That said, I think it's more because the list is more active than normal (I lurked before I posted) so now the list is all active, threads are getting longer than people are used to, and the usual way of nesting replies breaks down a little bit. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] The Spring 2011 QL Survery
Good morning all, I currently have 38 responses. For some questions with fewer answer choices, the answers are now statistically significant with a margin of less than +/- 5% but those with more answer choices are still not there yet (+/- 12% or so.) I am very surprised by some of the early results, which overturn some of *my* preconceptions :) Ideally, it would be good to get the number of people responding up to around 75 or so. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Gold card battery...
Hi all, I have a Gold Card which has the discontinued 40LF220 lithium battery. The equivalent MGL0025 is also discontinued, and even with the long shelf life of these lithium batteries, the new old stock ones are now useless. When you can find them, they were manufactured in 2002 and cost $30+ - one place quoted me $140 for a minimum order of 5, plus shipping. Is there a ready-made adaptor PCB available that will allow me to use a CR2032? Does the Super Gold Card use the same battery? If not, 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. I cannot make a guess on price as I have not looked at the cost of short-run PCBs recently. I would be happy to send batches of these to traders in each country at cost price. What is the need/demand for something like this? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Mon, Feb 14, 2011 at 1:41 PM, Tony Firshman t...@firshman.co.uk wrote: Plastic wrote, on 14/Feb/11 19:38 | Feb14: Hi all, I have a Gold Card which has the discontinued 40LF220 lithium battery. The equivalent MGL0025 is also discontinued, and even with the long shelf life of these lithium batteries, the new old stock ones are now useless. When you can find them, they were manufactured in 2002 and cost $30+ - one place quoted me $140 for a minimum order of 5, plus shipping. Is there a ready-made adaptor PCB available that will allow me to use a CR2032? Does the Super Gold Card use the same battery? If not, 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. I cannot make a guess on price as I have not looked at the cost of short-run PCBs recently. I would be happy to send batches of these to traders in each country at cost price. What is the need/demand for something like this? I am sure that would be popular. I keep getting asked about these batteries. All my GC/SGC batteries are dead, but (of course) my systems use the Minerva clock. Is the CR2032 man enough though? The CR2032 is 3V 235ma, and on this card would need to be replaced every three years or so, which would be a simple pop a new one in operation... The 40LF220 had a lower current capacity but was designed for a long shelf life of ten years, hence the bulk. So yes, the CR2032 truly fits this application. The format is standard for battery backed clocks on PCs, but was quite new in the late 80s. I will look at current costs for getting a batch of 100 of these tiny, single layer PCBs made. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Mon, Feb 14, 2011 at 1:57 PM, Tony Firshman t...@firshman.co.uk wrote: Plastic wrote, on 14/Feb/11 19:54 | Feb14: On Mon, Feb 14, 2011 at 1:41 PM, Tony Firshmant...@firshman.co.uk wrote: Plastic wrote, on 14/Feb/11 19:38 | Feb14: Hi all, I have a Gold Card which has the discontinued 40LF220 lithium battery. The equivalent MGL0025 is also discontinued, and even with the long shelf life of these lithium batteries, the new old stock ones are now useless. When you can find them, they were manufactured in 2002 and cost $30+ - one place quoted me $140 for a minimum order of 5, plus shipping. Is there a ready-made adaptor PCB available that will allow me to use a CR2032? Does the Super Gold Card use the same battery? If not, 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. I cannot make a guess on price as I have not looked at the cost of short-run PCBs recently. I would be happy to send batches of these to traders in each country at cost price. What is the need/demand for something like this? I am sure that would be popular. I keep getting asked about these batteries. All my GC/SGC batteries are dead, but (of course) my systems use the Minerva clock. Is the CR2032 man enough though? The CR2032 is 3V 235ma, and on this card would need to be replaced every three years or so, which would be a simple pop a new one in operation... The 40LF220 had a lower current capacity but was designed for a long shelf life of ten years, hence the bulk. So yes, the CR2032 truly fits this application. The format is standard for battery backed clocks on PCs, but was quite new in the late 80s. I will look at current costs for getting a batch of 100 of these tiny, single layer PCBs made. Couldn't the card have a battery socket so that only the battery need be replaced? ( ... and why are you not yet living Texas time - it is 2am (8-)# ) That is exactly what I was describing ;) A simple adaptor card to a CR2032 socket, and a CR2032 battery. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Mon, Feb 14, 2011 at 2:09 PM, Tony Firshman t...@firshman.co.uk wrote: On 14 Feb 2011, at 20:01, Plastic plasticu...@gmail.com wrote: snip Is the CR2032 man enough though? The CR2032 is 3V 235ma, and on this card would need to be replaced every three years or so, which would be a simple pop a new one in operation... The 40LF220 had a lower current capacity but was designed for a long shelf life of ten years, hence the bulk. So yes, the CR2032 truly fits this application. The format is standard for battery backed clocks on PCs, but was quite new in the late 80s. I will look at current costs for getting a batch of 100 of these tiny, single layer PCBs made. Couldn't the card have a battery socket so that only the battery need be replaced? ( ... and why are you not yet living Texas time - it is 2am (8-)# ) That is exactly what I was describing ;) A simple adaptor card to a CR2032 socket, and a CR2032 battery. Ah sorry. 3 years though seems a mite short. I wonder if there is a more beefier battery that is thin enough - or maybe a chargeable one? There is, but it has 50% higher capacity and costs $12 instead of $0.99 at the supermarket. I said three years as a minimum. It's quite possible that it would last 5-6-7 years - I'm just being very conservative. Also, the CR2032socket in bulk is under $1, but the socket for the CR2045 is $7.80 in bulk. I think people will happily pay $15-20 for a 3-5 year battery change at 99p than pay $25-$30 for an extra couple of years. Also, changing the CR2032 batteries is so easy... 15 seconds, including removing and re-inserting the card. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] The Spring 2011 QL Survery
On Mon, Feb 14, 2011 at 2:49 PM, Rich Mellor r...@rwapservices.co.ukwrote: And here, Peter, I have to apologise, in that as a trader I have not completed the survey, as I feel my answers would be pointless (eg. how many QLs do you have? Answer - over 30 but only 2 or 3 which I regularly use, depending on what I need to do!) Rich, That is actually one of the most interesting questions of all. Not because of the question but because of the answer. It seems there is a little hoarding going on, and most QLers have 3 or more QLs that they don't use (or don't use regularly!) This leads me towards wanting to make a considered and well formed appeal to people to release some of these machines back into the wild. Do you know a teenager who has an interest in old computers? Give them a QL and take them under your wing and show them the fun of the platform. Tell them if they don't fall in love with it, they can return it to you and it's all good. If everyone with an extra QL (beyond the necessary spare, of course) found one person to pass our passion on to, two things would happen: First, there would be HUNDREDS of new QL users, filled with enthusiasm, writing new software and making us feel old. Second, these people would want to buy software, add-ons, and new hardware, or if they're taken in by speed, they'll happily buy QPC2. This is good for everyone, all round. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Mon, Feb 14, 2011 at 3:23 PM, Tony Firshman t...@firshman.co.uk wrote: Plastic wrote, on 14/Feb/11 20:50 | Feb14: On Mon, Feb 14, 2011 at 2:09 PM, Tony Firshmant...@firshman.co.uk wrote: On 14 Feb 2011, at 20:01, Plasticplasticu...@gmail.com wrote: snip Is the CR2032 man enough though? The CR2032 is 3V 235ma, and on this card would need to be replaced every three years or so, which would be a simple pop a new one in operation... The 40LF220 had a lower current capacity but was designed for a long shelf life of ten years, hence the bulk. So yes, the CR2032 truly fits this application. The format is standard for battery backed clocks on PCs, but was quite new in the late 80s. I will look at current costs for getting a batch of 100 of these tiny, single layer PCBs made. Couldn't the card have a battery socket so that only the battery need be replaced? ( ... and why are you not yet living Texas time - it is 2am (8-)# ) That is exactly what I was describing ;) A simple adaptor card to a CR2032 socket, and a CR2032 battery. Ah sorry. 3 years though seems a mite short. I wonder if there is a more beefier battery that is thin enough - or maybe a chargeable one? There is, but it has 50% higher capacity and costs $12 instead of $0.99 at the supermarket. I said three years as a minimum. It's quite possible that it would last 5-6-7 years - I'm just being very conservative. Also, the CR2032socket in bulk is under $1, but the socket for the CR2045 is $7.80 in bulk. I think people will happily pay $15-20 for a 3-5 year battery change at 99p than pay $25-$30 for an extra couple of years. Also, changing the CR2032 batteries is so easy... 15 seconds, including removing and re-inserting the card. Yes - in that case the 2032 makes sense. It is a pity the PC has stadardised now on the low capacity non-rechargeable. In the old days they used a Minerva like NiCad pack that lasted for yonks. Tony Well no, it makes perfect sense. The Gold Card was designed with the expectation that it would still be in use in ten years. Can a typical new PC expect to outlast the battery? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] [QL-USAers] USA QLs...
On Mon, Feb 14, 2011 at 3:37 PM, David Tubbs davet...@tiscali.co.uk wrote: Would you be willing to share the details/schematic? Dave I dont mind, only prolem is memory and no documentation. I could send you photos with which you might reverse engineer. I also have a few dongle boards, some adapted for the 64k eprom, used in the past to slot in diff' QDOS, inside chips removed. Yes, photos would be very helpful. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Mon, Feb 14, 2011 at 3:51 PM, Phil Kett pk...@genesis-midi.com wrote: On 14/02/2011 21:23, Tony Firshman wrote: Plastic wrote, on 14/Feb/11 20:50 | Feb14: On Mon, Feb 14, 2011 at 2:09 PM, Tony Firshmant...@firshman.co.uk wrote: On 14 Feb 2011, at 20:01, Plasticplasticu...@gmail.com wrote: snip Is the CR2032 man enough though? The CR2032 is 3V 235ma, and on this card would need to be replaced every three years or so, which would be a simple pop a new one in operation... The 40LF220 had a lower current capacity but was designed for a long shelf life of ten years, hence the bulk. So yes, the CR2032 truly fits this application. The format is standard for battery backed clocks on PCs, but was quite new in the late 80s. I will look at current costs for getting a batch of 100 of these tiny, single layer PCBs made. Couldn't the card have a battery socket so that only the battery need be replaced? ( ... and why are you not yet living Texas time - it is 2am (8-)# ) That is exactly what I was describing ;) A simple adaptor card to a CR2032 socket, and a CR2032 battery. Ah sorry. 3 years though seems a mite short. I wonder if there is a more beefier battery that is thin enough - or maybe a chargeable one? There is, but it has 50% higher capacity and costs $12 instead of $0.99 at the supermarket. I said three years as a minimum. It's quite possible that it would last 5-6-7 years - I'm just being very conservative. Also, the CR2032socket in bulk is under $1, but the socket for the CR2045 is $7.80 in bulk. I think people will happily pay $15-20 for a 3-5 year battery change at 99p than pay $25-$30 for an extra couple of years. Also, changing the CR2032 batteries is so easy... 15 seconds, including removing and re-inserting the card. Yes - in that case the 2032 makes sense. It is a pity the PC has stadardised now on the low capacity non-rechargeable. In the old days they used a Minerva like NiCad pack that lasted for yonks. These NiCad packs are not good in old computers - I've seen far too many amigas destroyed by acid from leaky rechargeables! GC and SGC are scarce enough these days as it is - imagine how bad it would be if they'd had a rechargeable battery on them Okay, I have looked at the parts, PCB design and got a couple of quotes for PCB manufacture. As a rough guide, it looks like the retail price from a trader would be around $20 (€14.83, £12.50) to $25 (€18.54, £15.60) if I made 100. Lead free, gold contacts, includes quality CR2032 battery. Requires soldering four pins to install (or ship your card off for a nominal fee if you're not confident to do this). You may need to change the battery out once every 5 years or so. You can buy CR2032 batteries at your local supermarket. What is the interest in this part? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Gold card battery...
On Mon, Feb 14, 2011 at 4:59 PM, Rich Mellor r...@rwapservices.co.ukwrote: On 14/02/2011 22:53, Plastic wrote: On Mon, Feb 14, 2011 at 3:51 PM, Phil Kettpk...@genesis-midi.com wrote: On 14/02/2011 21:23, Tony Firshman wrote: Plastic wrote, on 14/Feb/11 20:50 | Feb14: On Mon, Feb 14, 2011 at 2:09 PM, Tony Firshmant...@firshman.co.uk wrote: On 14 Feb 2011, at 20:01, Plasticplasticu...@gmail.com wrote: snip Is the CR2032 man enough though? The CR2032 is 3V 235ma, and on this card would need to be replaced every three years or so, which would be a simple pop a new one in operation... The 40LF220 had a lower current capacity but was designed for a long shelf life of ten years, hence the bulk. So yes, the CR2032 truly fits this application. The format is standard for battery backed clocks on PCs, but was quite new in the late 80s. I will look at current costs for getting a batch of 100 of these tiny, single layer PCBs made. Couldn't the card have a battery socket so that only the battery need be replaced? ( ... and why are you not yet living Texas time - it is 2am (8-)# ) That is exactly what I was describing ;) A simple adaptor card to a CR2032 socket, and a CR2032 battery. Ah sorry. 3 years though seems a mite short. I wonder if there is a more beefier battery that is thin enough - or maybe a chargeable one? There is, but it has 50% higher capacity and costs $12 instead of $0.99 at the supermarket. I said three years as a minimum. It's quite possible that it would last 5-6-7 years - I'm just being very conservative. Also, the CR2032socket in bulk is under $1, but the socket for the CR2045 is $7.80 in bulk. I think people will happily pay $15-20 for a 3-5 year battery change at 99p than pay $25-$30 for an extra couple of years. Also, changing the CR2032 batteries is so easy... 15 seconds, including removing and re-inserting the card. Yes - in that case the 2032 makes sense. It is a pity the PC has stadardised now on the low capacity non-rechargeable. In the old days they used a Minerva like NiCad pack that lasted for yonks. These NiCad packs are not good in old computers - I've seen far too many amigas destroyed by acid from leaky rechargeables! GC and SGC are scarce enough these days as it is - imagine how bad it would be if they'd had a rechargeable battery on them Okay, I have looked at the parts, PCB design and got a couple of quotes for PCB manufacture. As a rough guide, it looks like the retail price from a trader would be around $20 (€14.83, £12.50) to $25 (€18.54, £15.60) if I made 100. Lead free, gold contacts, includes quality CR2032 battery. Requires soldering four pins to install (or ship your card off for a nominal fee if you're not confident to do this). You may need to change the battery out once every 5 years or so. You can buy CR2032 batteries at your local supermarket. What is the interest in this part? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm There is probably enough QL user interest for 30-50 batteries that I know of. Could the pins not be ready soldered, so that it is just a direct plug in replacement ? I didn't notice it was socketed and thought it was soldered to the board and those were spacers *laughs* I will have to locate some pins or leads that fit the socket, but yes, Rich is correct: no soldering required. I am prepared to commit to making a batch of 100 if I see any other signs of interest in addition to Rich's observation... Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] [QL-Users] Schematics...
Hi all, I am trying to collect together all the schematics I can for any and all QL-related hardware. Could you please take a few minutes to look through your files and see if you have any schematics for anything at all, from the QL itself to the gold card to the serial to centronics printer interface to the trump card to whatever. This effort will be repaid in full, I promise you. Here's a list of the schematics I currently have: *crickets* That's right. None. So if you have a schematic, rest assured I don't have it. Please, and thank you. :) Dave ___ 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)
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
Re: [Ql-Users] Hardware question
If you buy an EPROM on eBay and it needs erasing, remove the label (you'll find letting the label soak in some lysol is the best way to do this) and then putting the EPROM with the window facing the sun for approx 30 mins should erase it. On a dull day it doesn't take longer, as UV goes right through clouds. To combine the top OS ROM image I suggest you: (pseudo-code alert!) base = ALCHP(32768) copy the upper OS ROM image to base copy the TK2 ROM image to base+16384 save base TO base+32767 to a file that will be your new ROM image. Burn the image to the EPROM. If you have really amazing eyesight you can look in the window while it's burning and what all the bits turning off! [1] Cut yourself a 10x15mm bit of label, and write something descriptive on it, THEN stick it onto the EPROM window. ProTip: leave a bit of backing extra so you can separate it easily. Store programmed EPROMS in a bit of conductive foam or wrapped in aluminium foil when not in a PCB - they're quite hardy, but it only takes 25v on a pin to change a bit, and you walking around generates a lot more than that. Good luck! Dave [1] if you try this, you will go blind. Also, a blank EPROM is all 1's and burning it turns off the 0's you need to be zeros. Neat huh? On Sun, Feb 13, 2011 at 6:13 AM, Lee Privett lee.priv...@gmail.com wrote: Looking on EBay the prices for the EPROM's are just a few pounds if M27C512-15 is the same thing, the 28 pin DIL socket less than a pound, the ROM codes Minerva Toolkit II are freely available so other than getting the code burnt on to the EPROM I have everything or am I missing something? Lee Privett ¦¦ ha Sent from my Laptop running XP but emulating the QL using QPC2 ¦¦ - Original Message - From: Peter Graf To: ql-us...@q-v-d.com Sent: Sunday, February 13, 2011 12:16 AM Subject: Re: [Ql-Users] Hardware question Hi Lee, So I need to look out for a Gc, SGC or Minerva conversion kit, haven't seen those on eBay or sell my retro For Minerva ROM you could try 1. Get an M27C512 and a 28 pin DIL socket (wide, long pins) 2. Program lower 48 KB with Minerva, and upper 16 KB with extension ROM binary of your choice 3. Lift up pin 1, 20, 22. 4. Press M27C512 into an IC socket 5. Wire socket pin 20 to M27C512 pin 1 6. Wire socket pin 22 to M27C512 pin 20 7. Wire M27C512 pin 28 to M27C512 pin 22 8. Remove both QL ROMs from socket 9. Press in the M27C512 with it's socket into one of the QL sockets 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 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] [QL-USAers] USA QLs...
Check out my awesome Apple template kills :) But thank you anyway. Dave On Sun, Feb 13, 2011 at 6:13 AM, Lee Privett lee.priv...@gmail.com wrote: Refreshingly nicely styled website for the QL, Dave. Lee Privett ¦¦ Sent from my Laptop running XP but emulating the QL using QPC2 ¦¦ - Original Message - From: Plastic To: ql-us...@q-v-d.com Sent: Sunday, February 13, 2011 10:28 AM Subject: Re: [Ql-Users] [QL-USAers] USA QLs... Which of course SUCKS. Oddly, the QL manual that came with it refers to the EU style interfaces. Does anyone know the pinouts? I have now posted the photos and the correct URL is: http://www.nonstickglue.com/QL_Hardware_Library/Photos.html Over time I will add extensively to the photos and technical info on the site. You might want to bookmark it. Also, I will be creating a CURRENT list of maintained and active QL sites, which I will maintain to ensure it doesn't become a pile of dead links in a few months like many others :P Dave On Sun, Feb 13, 2011 at 4:15 AM, Tony Firshman t...@firshman.co.uk wrote: Plastic wrote, on 13/Feb/11 06:57 | Feb13: Hi all. I have been looking at my US QL, and noting many differences from UK keyboards. Here's what I have seen so far. The PCB most resembles an Issue 7 board, but with some changes. The first apparent difference is the odd serial and joystick connectors were replaced by standard 9-pin D sockets. The case rear bottom shell was modified so the 4 sockets sit in a metal gasket which plugs the gap. The interior of the top and bottom case were metalised using a vapor deposition technique (the same one used to make toys or CDs shiny). Continuing this theme, a large ferrite ring cuts noise on a pair of wires in the power supply section, tucked under the heatsink. The ROMs are JSU, and are the plastic type. Weirdly, the $ was made in Korea, and the $8000 was made in Mexico. There is a small 2cm x 2.5cm daughter card stuck to the top of the on-board memory with 4 dabs of silicon. There are four wires coming from the board to various points on the PCB. It contains one IC, a 74HCU04B1, two resistors and a disc capacitor. There are a few wires making some changes to the PCB. On the 68008, a wire bridge joins pins 15 and 35. This link is joined via a 22pf cap to pin 13. On the 8301, pin 6 is joined to pins 11, 12, 30, 31 and 32 via five 1n4148 diodes. There are a few other small differences, no greater than the difference between an Iss.5 and Iss.7 board. Photos will be posted at http://www.nonstickglue.com/qlphotos/ in an hour or two. ... and the keyboard metal back plate was far thicker. Also the membrane was more likely to be the good clear plastic type. Unfortunately, although the 9D is the same as a PC, the pinout is different - naturally as this was long before PCs had 9D ports. Tony -- QBBS (QL fido BBS 2:257/67) +441442828255+44(0)1442-828255+441442828255 +441442828255 t...@firshman.co.uk http://firshman.co.uk Voice: +441442828254+44(0)1442-828254 +441442828254+441442828254 Fax: +441442828255+44(0)1442-828255 +441442828255 +441442828255 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 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-You Sir!] The Spring 2011 QL Survery
Hi all, 15 responses so far, and already some definite and surprising trends forming. If anyone with QUANTA or QL Today or any other sites would like to put the survey URL on their site, please feel welcome to do so. The more responses, the more meaningful it is. I'm really surprised by a couple of the answers - not at all what I expected. Dave On Sun, Feb 13, 2011 at 7:16 AM, Plastic plasticu...@gmail.com wrote: Hi all, Please help the community by completing this 24-question survey. It will take less than three minutes to complete. The reason for this survey is that there have been others, but they have either been internal to an organization or the results haven't been made entirely public. This survey will have fully public results, and the questions are designed to see what people are using right now, and what they see themselves using in the future. The information will feed back to programmers and hardware designers, and shine a light on Quanta and QL World and how they can improve too. The questions have been checked and amended by a few of the movers and shakers of the QL community. No personal information is collected (unless you volunteer it) and I will not collect any identifying information or include it. The survey is here: http://www.kwiksurveys.com/online-survey.php?surveyID=IIMDML_e8265930 Please take just three minutes to check it out and give some responses - the whole community will benefit. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] [QL-You Sir!] The Spring 2011 QL Survery
Not at this stage. I plan to do another more detailed survey in a couple of months that looks at the users and their experience levels. This survey is aimed squarely at finding out what people use and how they use it. It's the information that's most urgently needed. I wanted to keep this survey short and informative, and allow it to lead the next survey - along with feedback like this. In the next survey I will look at users' age, sex, how long they have been a QLer, how they came to be a QLer and so forth. Dave On Sun, Feb 13, 2011 at 11:55 AM, gdgqler gdgq...@gmail.com wrote: On 13 Feb 2011, at 17:45, Plastic wrote: 15 responses so far, and already some definite and surprising trends forming. If anyone with QUANTA or QL Today or any other sites would like to put the survey URL on their site, please feel welcome to do so. The more responses, the more meaningful it is. I'm really surprised by a couple of the answers - not at all what I expected. You didn't ask the age of the repliers. Do you think that that variable would have been significant in an analysis of the answers? 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] Hardware question
On Sun, Feb 13, 2011 at 11:58 AM, Lee Privett lee.priv...@gmail.com wrote: as I said, one can never *really* escape the QL scene. Ok Tony, not sure what you mean by that, are you saying you may be making some more? Lee Privett I think he's saying he has a stalker that wants to talk to him about his hard long black thing. *SHOCK!* Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL Forum doesn't seem to like me?
If you email *Robert Heaton **r...@robheaton.co.uk* he can create the account for you manually. He would probably also like to know about your problem registering :) Dave On Sun, Feb 13, 2011 at 12:33 PM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Gents, (and especially to Peter Scott, should you read here) has anyone tried to register with the QL Forum? When I try to do that and Agree to terms and Conditions, it tells me Error: ! Sorry, but that doesn't appear to be a valid API key. - Whatever that should tell me, I can't register. I /think/ I use a pretty standard firefox on an even more standard Linux laptop, so would not expect the problem on my side. Cheers, Tobiass ___ 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] The Spring 2011 QL Survery
On Sun, Feb 13, 2011 at 2:26 PM, QL-MyLink (f/fh) q...@mylink.adsl24.co.ukwrote: As Ralph said - Quite right. It [QPC2] is *the* QL software emulator. John in Wales __ I'm using Q-Emulator for Mac 1.0 which is very good. The broken membrane emulation isn't quite there yet thought - still can type perfectly. I wonder what the shipping time is for a membrane from England to Texas - can't wait for it to get here. 26 responses and it's starting to get statistically significant now :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] The Spring 2011 QL Survery
On Sun, Feb 13, 2011 at 5:42 PM, Marcel Kilgus ql-us...@mail.kilgus.netwrote: Peter Graf wrote: no offense intended at all, but are you not counting the now much faster PC hardware (which you didn't design) and the Windows features (which you didn't write, e.g. TCP/IP) as QPC achievements? So? Does this change the reality in any way? No. I'm inclined to agree with both of you here. The speed of QPC is not an achievement but it is an accomplishment of the platform - it runs on the fastest hardware available. It is really really hard to make new QL hardware possible... I find public statement that QL hardware can not match in features somewhat depressing... It's not that it can't match it. It's that, at this time, it doesn't match it. I think the point here is that emulators have to emulate something. If there's nothing innovative to emulate, even the emulator cannot move forward - it can just go faster at the same old stuff. If there are to be new developments, they NEED to come from native hardware, then be emulated. Emulators introducing new features is a hurdle because it is then harder to implement that in original hardware in a practical and efficient way. My point was simply that brushing QPC aside as just an emulator is wrong. Not more, not less. I have not and will never argue against native hardware. Marcel, it is not my intent to brush QPC aside. In fact, the opposite is true. However, for the purposes of the initial survey, I am simply finding out the proportions of people using paid vs free emulators vs original hardware and replacement hardware. Obviously emulation is far more popular and far more practical, and also obviously, QPC is the premiere emulator - nobody is questioning that or challenging QPC's position. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] The Spring 2011 QL Survery
On Sun, Feb 13, 2011 at 7:16 PM, Marcel Kilgus ql-us...@mail.kilgus.netwrote: Plastic wrote: I think the point here is that emulators have to emulate something. If there's nothing innovative to emulate, even the emulator cannot move forward - it can just go faster at the same old stuff. I think this is a logical fallacy here. Why should an emulator be restricted to the things actual hardware can do? Emulators had TCP/IP on QDOS for years now. *Of course* this is because it's magnitudes easier to implement when the host OS already provides this functionality, but that's hardly the emulator's fault. Should the emulators have waited for the hardware platforms to first have TCP/IP? It IS a logical fallacy if you consider an emulator that doesn't emulate something pre-existing but does something original to still be an emulator for the literal meaning of the word. It's plain reality that emulators were a necessary response to a lack of progress in clock speeds and availability of the M68K architecture. It's true that introducing new features in an emulator does introduce greater hardships for people producing original hardware, as the first good implementation usually becomes the predominant standard. However, that is not the emulator's problem - it's just unfortunate that it is the hardware designer's problem to overcome when an emulator beats him to market and he has a choice of being compatible or 'true to the platform'. That's reality. Marcel, it is not my intent to brush QPC aside. In fact, the opposite is true. However, for the purposes of the initial survey, I am simply finding out the proportions of people using paid vs free emulators vs original hardware and replacement hardware. Point taken. I still somewhat think simply including the 4 or 5 emulators would already have given you a complete and detailed overview of what people use, without the need for a second survey to drill into the details... in any case, I didn't want this here to be such a huge thing. Sorry. I decided not to because it's not that simple. There are emulators that run on only one OS, and emulators that exist in many versions across many OS (like uQLx). All emulators are not equal, but even the same emulator is not equal across version numbers (people sometimes do not upgrade) or operating systems (people sometimes do not upgrade) or hardware specifications (people sometimes do not upgrade, or choose to utilise older hardware) For this reason, I just wanted an indication of how the usage was split across platforms and host OS to give me perspective to write the right questions. The survey is well designed to find out what it is designed to find out - it isn't designed to find out everything - there's plenty of room for that in the Summer, Fall and Winter surveys ;) Let's see what this survey says, and discuss it and see how it informs us about the community and the assorted ecosystems interrelate - remembering always that at the end of the day, all the segments are - equally or unequally - dependent on each other. Think of it as peeking under the skirt instead of ripping all the clothes off ;) The early indications are that there's going to be some interesting surprises, and I have some very good questions forming in my mind already for the next survey. I hope everyone had a great and productive weekend. I did :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] [QL-Musers] OCD things we've done to our QLs...
Hi all, I received a USB floppy drive in the mail today, which will help things along nicely. I just need to find somewhere locally that still sells floppies. However, when I was formatting My First Floppy it reminded me of something I did to my QL back in the Sandy days. I was never satisfied that I usually got 205-209 sectors out of a microdrive cartridge. I wanted more. I often received cartridges with anything from 190 to 222 good sectors! DANG! I wanted the extra 7K or storage. I took off the cover, and ran the microdrives. I just wrote a little program to try to format forever, ignoring any errors. Then, I got the finest nail file my Mum had, and I gently reduced the diameter of the capstan rubber. I did it very evenly and smoothly, and stopped every .002... Sure enough, on testing, each slight reduction got the tape to run just a little slower past the head, and capacity increased. And that's how I got microdrive cartridges that always formatted to 228-230 sectors. I found past about that, the number of format failed responses started to rise dramatically. Also, Mum would start to notice the black rubber all over her expensive emory boards and wonder about me... :) What OCD things have you done to your QL? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] [QL-USAers] USA QLs...
Hi all. I have been looking at my US QL, and noting many differences from UK keyboards. Here's what I have seen so far. The PCB most resembles an Issue 7 board, but with some changes. The first apparent difference is the odd serial and joystick connectors were replaced by standard 9-pin D sockets. The case rear bottom shell was modified so the 4 sockets sit in a metal gasket which plugs the gap. The interior of the top and bottom case were metalised using a vapor deposition technique (the same one used to make toys or CDs shiny). Continuing this theme, a large ferrite ring cuts noise on a pair of wires in the power supply section, tucked under the heatsink. The ROMs are JSU, and are the plastic type. Weirdly, the $ was made in Korea, and the $8000 was made in Mexico. There is a small 2cm x 2.5cm daughter card stuck to the top of the on-board memory with 4 dabs of silicon. There are four wires coming from the board to various points on the PCB. It contains one IC, a 74HCU04B1, two resistors and a disc capacitor. There are a few wires making some changes to the PCB. On the 68008, a wire bridge joins pins 15 and 35. This link is joined via a 22pf cap to pin 13. On the 8301, pin 6 is joined to pins 11, 12, 30, 31 and 32 via five 1n4148 diodes. There are a few other small differences, no greater than the difference between an Iss.5 and Iss.7 board. Photos will be posted at http://www.nonstickglue.com/qlphotos/ in an hour or two. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] [ql-users] SuperBASIC tokens and line numbers...
Hi all, I know QDOS saves SuperBASIC as plain text, and re-parses and tokenises it on the fly when you load a program. Is there any functionality or method to save and load tokenised SuperBASIC? I saved a tokenised program and it was 1/3rd the size and therefore loads much more quickly. Is there anything to be done with this? I found it interesting that even saved tokenised, the original EVERYTHING can be reconstructed by QDOS, down to spacing... It's not lossy. Also, I remember having a toolkit or RESPR that allowed me to edit SuperBASIC without line numbers. Can anyone point me towards it now as I do not remember at all what it was called. I could use the extra screen real-estate, since I am editing what may well end up being a 32,000 line SuperBASIC program. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Wishlist of future SuperBASIC extensions...
I wish I could... count++ instead of count = count + 1 count-- instead of count = count - 1 I wish I could... DEFine PROCedure run_faster(a$) REMark Any procedures called with this wrapper will always execute in a short enough time ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Wishlist of future SuperBASIC extensions...
On Fri, Feb 11, 2011 at 8:16 AM, Rich Mellor r...@rwapservices.co.ukwrote: On 11/02/2011 14:02, Plastic wrote: I wish I could... count++ instead of count = count + 1 count-- instead of count = count - 1 Not possible without re-writing the BASIC parser... How does Jan Jones sleep at night? ;) I wish I could... DEFine PROCedure run_faster(a$) REMark Any procedures called with this wrapper will always execute in a short enough time ;) Now that is easy enough: DEFine PROCedure run_faster(a$) REMark do nothing END DEFine So the problem isn't with the code. It's with the problem! Or, you can use Turbo to compile a suite of procedure and function calls - not something I have ever used it for, but it's there - plus you can compile it for speed, rather than memory on the most intensive sections of code. I have downloaded it. I plan to read the manual tonight. I read it in 1980-something and it made me cry. Hopefully I will do better this time. :) Anyone know what the memory limit on JS ROMs is, and how it exhibits? I configured Q-Emulator to 4MB and wrote a little proggie to copy every 32K page into screen RAM, and it seems to run well, and loop around at 4MB. I notice the SuperBASIC area is... larger. Approx 48K instead of 6K or so. Dave Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Wishlist of future SuperBASIC extensions...
On Fri, Feb 11, 2011 at 8:51 AM, Malcolm Lear malc...@essex.ac.uk wrote: On 11/02/2011 14:02, Plastic wrote: I wish I could... count++ instead of count = count + 1 count-- instead of count = count - 1 How about count++5 instead of count = count + 5 I'll match your increments and raise you referenced pointers... Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] File transfers
On Thu, Feb 10, 2011 at 1:18 PM, matras...@aol.com wrote: Problem is endian. My recollection is Qx0 hard disk format is pretty much QXLwin except that QXLwin on a PC is organised in the PC byte order Duncan How dare you, Sir! How dare you ruin my perfectly good joke with FACTS! *grins* Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Approaches to (lots of things!) in SuperBASIC
Hi all, 1. I would like to be able to identify the hardware and OS my timing critical programs are running on. To this end, I can use ver$ to identify the QDOS version. However, what ver$ returns do Minerva and SMSQ/E give? Is there a surefire way to identify if the execution environment is a QL, Gold Card, Super Gold Card, Aurora, Q40, Q60, etc? This would allow me to create fast, integrated speed-matching code for as many environments as I can get information for. 2. I need to collect input to a variable$ while a wider program loop is running. I'm not sure how to approach this. INKEY$ can tell me what key is pressed, but then I am faced with somehow debouncing the input, and also knowing when someone says flight blah, turn to heading 222 degrees... I don't want to pause the aircraft just to take input. I'm a little stuck on this. 3. I need to be able to draw data blocks to the screen. The data blocks would look something like this: AAL3251 030^24 . / That data block means flight AAL3251 is at 3,000 ft, climbing, at 240 knots. Below it there is a blob for the plane, with a trail that shows by angle the direction it came from, and the speed (faster = longer trail) I have two problems to solve here: ONE: when aircraft approach the edge of the screen, the dot and line can go off, but the text cannot and will generate an error. TWO: I have to often plot these labels overlapping each other. They will also overlap the runways and beacons. I can't avoid the need to redraw the airport and beacons occasionally, but I would like to do so without flicker. It seems the plan will be to draw the positions, store them in old variable copies, do the math, then overdraw the moving tags in black, redraw the fixed items, then plot the new positions, rinse and repeat. This seems wasteful. Is there a smart technique I am missing? (It must apply to SMSQ/E, Minerva and QDOS, so the second screen isn't, unfortunately, an option.) 4. I need to detect proximity violations (three miles.) I have this cracked. A simple reducing nested loop minimises work: FOR first = 0 to (high_slot-1) FOR second = (first+1) to high_slot _proximity (first, second) END FOR second END FOR first This compares each pair of planes just once. Thus, with 4 planes, it will compare: 0 to 1, 0 to 2, 0 to 3, 0 to 4 1 to 2, 1 to 3, 1 to 4 2 to 3, 2 to 4 3 to 4 Sweet! The _proximity() procedure simply sets the color of close plane tags to red, and non-close tags to green. 5. Currently, I am estimating that on an unaccelerated QL each loop through the calculations will be SIX+ SECONDS. This is obviously unacceptable. Given this horrifying realization, I will have to supply the game Turbocharged, and include the source. I have downloaded Turbo, and will be reading ASAP, as I would like to incorporate any special coding at writing time, rather than editing later. What kind of speed-up factor might I obtain by Turbo-ing vs. Supercharging? 6. I am having weirdness with zip-files, and am looking forward to obtaining a floppy so I can put all the files on one floppy. When I release the game, I will try to offer it in as many formats as possible: floppy, zip, qxl.win, and the promising QLPAK file - must find out more about that. 7. I am now intrigued by the idea of internet play. What is the state of the tcp_ option? What good ways are there to get a QL online? If the stack is accessible from SuperBASIC I could do some wonderful things. 8. I have decided to allow people to choose from different airports, not just the default one. I could implement this by reserving lines 3 - 32767 for DATA statements and create a format. Then, I could have many airport files on the storage device, and MERGE the necessary one in. Alternatively, I could create a data format, and load/save the bytes as needed - much more compact, but less friendly to future airport additions by others. I fully intend to allow anyone to read the data format and create/share their own airport description files. I'd simply check them then add them to the program. 9. Network play. How cool would it be to have 3 or 4 QLs playing a grid, and passing off aircraft to each other? I recall the inbuilt NET ports were just slightly better than useless, but I've seen them work, so... 10. I think I need to obtain some form of superior graphics library. It needs to integrate into SuperBASIC, and be compiler-friendly. Is there such a thing? Any and all suggestions and discussion welcome! Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] File transfers
On Wed, Feb 9, 2011 at 4:28 PM, Marcel Kilgus ql-us...@mail.kilgus.netwrote: Tobias Fröschle wrote: Another option already mentioned (and perhaps with the highest probability to actually work) would be sernet. ...talking to myself again??? Sernet is actually a pretty comfortable solution, albeit not the fastest. Isn't it supplied with QPC even? I think there are some articles on how to set it up on Dilwyns site. But: Following the serial route, there would be another option: zip up the files on the Q40, and use one of the ancient terminal programs supporting X/Y/Z-modem on both QPC and Q40 to transfer the zip file over. This will take ages as well, but you wouldn't need to sit and watch (or even juggle around with disks) This is probably significantly faster than Sernet, but also a bit harder to set up. Actually I used this method to debug and streamline the QPC serial port drivers, a PC terminal program on one side and QPC with QTPI on the other (using Z-Modem). I spend days tuning everything to get a constant 10-11kb/s out of the serial ports... Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm Since you're all coming up with such practical solutions, here's what I would do: I would set up the webcam on the destination PC, and aim it at the Q40's display. I would then copy the files in 32 kbyte chunks into the video memory, and have the camera film them. At that point I would write a quick and dirty app to scan the video image and extract the bytes from the video image. If you cannot do that, just run OCR s/w on the destination machine and COPY the drive to the Q40's screen as characters. If that's STILL too complicated, simply put a directory listing of the drive on floppy and present that to the destination machine, put an ethernet card on the Q40, then run the public domain web server, and have the destination machine request all the files from the Q40 web browser ;) Too much coffee. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Wondering...
Norman, It's wonderful that you offer that. I'm in Texas, USA and I'm told by RWAP that shipping a QL from England is over 50 ukp. I couldn't ask you to do that. Let me check out local options first... Dave On Mon, Feb 7, 2011 at 3:16 PM, Norman Dunbar nor...@dunbar-it.co.ukwrote: Evening Dave, I've dug out a QL for you, with no microdrives, but it has a network lead, a TV lead and three original feet. You can have it free. If it's ok with you, I'd rather not send the power supply. :-( I've plugged it in to a LCD TV and it works fine, the picture is a bit out of focus (to my eye) and adjusting the fine tuning around channel 36 makes no difference. I suspect the UHF modulator needs a bit of time to warm up perhaps. Drop me a private email to let me know where you want it sending please: Norman (at) dunbar (hyphen) it (dot) co (dot) uk. I've got two more, one with a really bad picture and one that appears to be dead. :-( I'll worry about them some other time. Just discovered, two microdrives are present after all! Thought it was heavier than the others! I have tested all the keys on the keyboard - thay all work fine with and without shift, ctrl and alt. Looks like it's a runner. However, I have to say that it's s-l-o-o-o-o-o-o-o-w! Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ 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
I seem to recall having a roll of MAX232s around here somewhere. I also recall having 25 or so of the hard-to-find Altera CPLDs in a tray, a box of the QL connectors (I don't remember M or F) and assortments of other SMD components and etc. These were bought for Nasta's aborted Goldfire project. If any of this stuff is any use to anyone, let me know and I'll dig it out. Dave On Tue, Feb 8, 2011 at 4:54 AM, Tony Firshman t...@firshman.co.uk wrote: tobias.froesc...@t-online.de wrote, on 8/Feb/11 09:49 | Feb8: -- Yes indeed you are - it looks good. -- -- I have two USBWIZ modules and I saw another two at the Vienna QL show. -- -- so there is probably a market for firmware/drivers only. -- -- Tony Tony, same with me - got a USBWiz somewhere in a drawer, but never found the time to do something with it. This leads me to another (related) question: How is the current (Super) Hermes availability? Do you still produce it? With the USBWiz being serial, this really calls for a high-speed interface. Rich Mellor has secondhand ones. I have given up QL work but . . I am building some for Rich. One of the reasons I stopped is I am too busy, so I am not sure when these can be made. Adrian is finding, like Laurence and I did, that the fastest speed attainable is somewhere between 56k and 115200. The limiting factor is QL speed, so SGC is needed. This is a real pity as the hardware can go as fast as sH theoretical limit (460800 I think). Its max is 1.5mbps or so. However the limits for the RS232 chips in sH are probably lower than 230400. The high serial speed is for TTL links - ie direct serial links. In fact the RS232 hardware is not on USBWIZ, so a MAX or similar chip needs adding. Tony -- QBBS (QL fido BBS 2:257/67) +441442828255+44(0)1442-828255+441442828255 t...@firshman.co.uk http://firshman.co.uk Voice: +441442828254+44(0)1442-828254 +441442828254 Fax: +441442828255+44(0)1442-828255 +441442828255 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] Game idea...
Hi all, Is it that there's no interest in this kind of a graphical game? Or is anyone interested, but didn't say so? Anyone have any other game ideas? I'm fairly confident I can write one fair to decent game per month for the next six months. I'm sure they'll improve greatly in quality over that time, too. I'm open to any ideas... Dave On Sun, Feb 6, 2011 at 3:12 AM, Plastic plasticu...@gmail.com wrote: Hi all, I had a game idea back in the 80s. I feel like it might be a good followup project after the flight sim, but the idea is fun so I thought I would share it here and see what others might make of it. The game occurs in a two-dimensional gravity well. The yellow sun occupies a fixed point in the middle. The green planet orbits with an eccentricity that increases at higher levels. There will be other red bodies in random orbits too. The objective of the game is to accelerate or decelerate your ship to match orbits with the goal planet. Other bodies will affect your path. You must simply match the target's speed and velocity with a degree of accuracy that increases at higher levels. There will be a time and/or fuel limit. This game employs the N-body problem of gravitational bodies. I programmed the N-body problem in SuperBASIC in the 80s and will be able to recreate it fairly easily. I think it would be quite cool and playable and would be 100% graphical. Does anyone have any ideas to add to this, or suggestions? If you contribute ideas/code with this thread, I will presume you're sharing your ideas with the whole community and that I or others may freely use your ideas. Code, however, would only be used by explicit permission. When the game is completed, I will release it to the community, for free, with source. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] SuperBASIC oddities...
Here are two fun weird things I like about SBASIC. Maybe others on this list will add their quirks too...? 1. the MISTake keyword. If you load a BASIC program that contains an error that would normally provoke a bad line response, it inserts the word MISTake, to indicate that the line will generate an error. The fun thing is, MISTake is a keyword you can enter yourself. It's like REMark, but doesn't prevent parsing of the following text. 2. Re-entrancy limits. Take the following contrived example of bad coding: 100 count=0 : mode 4 110 do_it 120: 130 DEFine PROCedure do_it 140 count = count + 1 150 PRINT count : PRINT #2, FREE_MEM 160 do_it 170 END DEFine do_it In this example, the procedure gets called from within the procedure. This creates a loop, d'uh! Every 20 or so cycles, the return stack fills, and another 512 bytes is reserved. As the recursion goes deeper, memory starts to run low. It takes about 20 loops to use 512 bytes, so it takes around 25,060 loops to use up all the free RAM on a 640K QL. The fun part is, when the program finishes consuming all the memory, FREE_MEM actually goes negative, to -512, and the program manages 20 more loops before generating an out of memory error. Fun times! Anyone got any other little oddities or observations about this quirky little OS that could? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Game idea...
On Tue, Feb 8, 2011 at 8:57 AM, Rich Mellor r...@rwapservices.co.uk wrote: Dave, I think that there is interest in more games for the QL, but the game idea has probably not enthused many people, as it sounds too simplistic - a bit like the old lunar landing types of games that formed the basis of many a magazine listing in the early 80s. I would direct you to have a look at some of the games which have emerged in recent years for the ZX80 and ZX81 - see http://www.rwapsoftware.co.uk/zx81/zx81_software.html and also http://www.rwapsoftware.co.uk/zx80/zx80_software.html This may give you an idea of the types of games which grab attention. I looked at the games there and I think maybe 1/3rd are within my skill range. That said, the third I could do include a lunar lander game ;) The game idea I outlined above is weirdly addictive at the puzzle level, It's also fairy educational. There's a fair amount of skill required. At higher levels, you'd be racing for the planet against an alien UFO and there would be other hazards like asteroids and black holes and comets - it would get quite busy. It'll certainly be visually pretty. I think, overall, there's maybe a world market for a few dozen copies of a new game on the QL, so I'll not get too hung up on people not liking the ideas. I'd rather do six quite different games over the half year and see what people respond to, while still supporting the specialty games. If there were money riding on it, I'd be a little more concerned, but I'm also not completely unconcerned with what people think either. I think that's the goal of this thread - to get people openly talking about new game ideas and seeing what sticks and what doesn't - at the end of the day it's a tricky affair. Some things sound great on paper then are just unplayable or do not hold attention. Other things sound odd on paper but end up freakishly addictive - look at the number of iApps of simple puzzles that get HOURS of gameplay, and the seemingly pointless games on facebook that soak up days of peoples' lives. One thing from this is that by having quirky and novel games on the QL platform, we can promote it to new users, to other retro platforms and maybe someone'll pick up the idea and run with it. I spend a lot of time thinking about app ideas. Like the game where you race to steal land from an opponent by shining light on it (won't work well on a QL without GD2) or the trucking company trading game or the QL version of GB Ltd, or the newsworthy bad taste game where you have to run an animal shelter (the more animals you put down, the less donations and volunteers you get, etc) or Petrol Station Manager!(tm) and so on ;) I know, odd choices, but it's all about the puzzle... :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Game idea...
On Tue, Feb 8, 2011 at 3:25 PM, Malcolm Cadman q...@mcad.demon.co.uk wrote: In message AANLkTimaewh-83aWQGbewJxD86EE=2po5liqz1-es...@mail.gmail.com, Plastic plasticu...@gmail.com writes Hi Dave, Any new game, with graphics at the forefront, would be great for the QL. Generally an area that did not get fully exploited. Perspective/3D illusion would be good, too. Easy there! I remember back in the late 80s buying a utility for sprites and finding it... impenetrable. I have always found the QL display to be hard because the provisions were more simple than on the Amiga or ST. On the other hand, that turned out to be a blessing, because you could achieve quite impressive results with the simpler QL routines. What was it Clive used to say? Keep hardware simple. Do it in software! That said, interpreted BASIC was always too slow to do anything too complicated, and I didn't fancy learning m68k assy. Still don't. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Finally a reply
On Tue, Feb 8, 2011 at 3:53 PM, Malcolm Cadman q...@mcad.demon.co.uk wrote: In message a1ebf150-979b-4e65-b8c2-ca4c97611...@gmail.com, gdgqler gdgq...@gmail.com writes On 7 Feb 2011, at 19:52, Geoff Wicks wrote: Perhaps the entire constitution of Quanta needs altering. Now where did I hear that recently ;-) I once was involved in rewriting an entire constitution. When Works Council Law was changed in the Netherlands all Works Councils had to rewrite their constitutions. We had a choice of either doing it ourselves or employing an outside consultant costing hundreds of pounds. As I was the only member of the council with the relevant skills and experience I was given the job, but at the same time the council appointed another member to be my mentor to check everything I did. In practice I found I could still keep much of the old constitution in the new one and I suspect that would be much the same in Quanta. There were model constitutions published and I also had to keep checking the new Works Council Law. In short in was a bit like pick 'n' mix. Basically Quanta would have to do is: 1: Look through the old constitution and get a rough idea of what you would like to leave in and what you would like to leave out. Then have an extensive consultation period to determine the main details. Do not rush this - it is better to take your time than do a quick botched job. (The lesson of the 2005 amendments.) 2: More than one person should be involved in the drafting. It is a bit like a superbasic program. Few of us could write a superbasic program that is totally bug free and that also applies to constitutions. Even better if the draft constitution is proofread by a person or persons not involved in the drafting. 3: Bear in mind that during the drafting matters could arise that need further consultation or decision by the committee or members. When writing the works council constitution I had to consult the council on whether we should have a personal or list voting system and prepare a paper on the merits and demerits of each. For example in Quanta to maintain continuity the officers currently have a three year period of office. You could have chosen instead for all committee members to serve 2 years with one half of the committee to face re-election in any one year. This is not a decision for the drafters, but the committee and/or members. 4: Publish the draft constitution well in advance to allow time for possible amendments, comments or objections. A very time consuming process, but Quanta may find it worthwhile, When I was involved in producing a new constitution we got an expert to produce one off the shelf. This was, in the main, OK but it had what I thought was a fatal flaw. It required the Committee members to retire after a period of, I think, 3 years and had to wait 1 year before they could be re-elected. I got that altered so that Committee members could stay on indefinitely, subject, of course, to being re-elected every 3 years. My reason for getting that alteration was that I thought it difficult enough to get anyone to do the voluntary work of being a Committee member. I reckon Quanta badly needs that change in the constitution. George Hi George, I agree with you, again ... :-) Good Board/Committee members are very hard to find. So, when you have them, it is best to keep them. As I commented in another email, it is best to have no Time limits. With all Board/Committee members standing down every Year, and then standing again (or not if they so choose). My community group will be holding its AGM, shortly, and this is what we do. This will be out eleventh Year of operation, with a budget of over £100K a Year. Being a Company Not for Profit and Limited by Guarantee, as well as a Registered Charity. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm One organization of which I am a member does not have term limits, but handles it in an interesting way. The only reason for a term limit is to prevent people holding an office indefinitely due to power issues. This organization resolves it by allowing a vote FOR someone and a vote AGAINST someone. FOR votes add one, and AGAINST votes deduct one. This way, if an incumbent goes on long enough to start being closely opposed, dissatisfaction usually focuses the negative votes on them. The downside is if you have three candidates: two popular opposing candidates and a third minor player, the two groups of supporters invalidate the others' votes and the third entrant gets elected. Another (to me, better) way to resolve the issue is to allow someone to be elected past a term limit if they are unopposed. However, if they are opposed, that individual gets a go. Having only half the positions replaced each election allows some continuity. IMHO. Dave
[Ql-Users] Feeding your microdrive...
Hi all, During my time at Sandy, I learned microdrives (the part inside the case, not the cartridge) were surprisingly reliable and fault-free. The only two faults that came up on a regular basis were dirt, and damaged capstans. The capstan, for those not in the know) is the rubber wheel on the motor which contacts the tape. The microdrive capstan has one advantage over capstans from tape decks. Tape deck capstans contact a metal pin when in position. If left for a long time, the capstan rubber acquires a dent which makes the tape change speed as it passed through - also, it slightly stretches the tape. The microdrive design contacts a plastic wheel in the cartridge, so it only touches something when a cartridge is left in. However, some people leave a cartridge permanently in the drive when not in use, and this can cause problems eventually. The wires that enter the motherboard are just tinned stranded wire and quite fragile. I always soldered pins on these as a first act of owning a QL - often, soldering on the pins was quicker than trying to fit that floppy mess of bent wire. I have tons of these pins so if anyone wants some for their QL, I'll happily mail them at no charge. At Sandy, we also found that cartridges would become error prone if not spun once in a while. I got into the practice of, once a month or two, spinning up every cartridge through at least one full loop (about 20-30 seconds) just to prevent print-through and to redistribute the lubricant. You'd be amazed how often we'd get mad microdrive complaints and we'd ask them to send in the computer and the problem cartridges, and they'd ALWAYS have fingerprints, or the computer smelled of cigarettes. Smoking kills cartridges! So does finger grease. If you pen your case to clean anything, it's always a good idea to remove and refit the voltage regulator. That's the small 3-pin device screwed to the heatsink right behind the microdrives. It gets warm regulating the voltage, but a poor connection can also create heat, so reseating the regulator in its socket helps it stay cool. While you're at it, if you have any PC thermal paste/crease/arctic silver, replace that little plastic shim, if there is one, with a tiny dab of that and you'll find it transfers heat to the heatsink FAR better. SOME people would get a tiny fan, hook it across the +9v and ground pins, and have it draw that air out the slots at the back. Nice if you can make it fit, but I don't think it makes much difference - it moves heat, but doesn't make sure it's being generated efficiently in the first place - just addresses the symptom. If I ever designed a QL PCB, it would have a far better power supply (but then, the PCB wouldn't be long and thin like that - it would be a eurocard or double eurocard - 100x160mm or so. I would also give it a proper bus with 4 or 5 expansion sockets. Hindsight. I know this is obvious to many, but not to all, so my apologies to those who consider this obvious. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Game idea...
On Tue, Feb 8, 2011 at 4:09 PM, Lee Privett lee.priv...@gmail.com wrote: Hey I got a great idea based on graphical lines etc. what about a TRON light cycle game playing against the computer but where the computer doesn't cheat against the human player? Anyone remember the TRON lightcycle game lawsuit about unauthorized copies of the game? The studio lost. The lawyers didn't realize the game was a complete rip-off of centipede... What about a jet version of it, where the jet trails kill, but they fade after a while, and you have to catch parachutes and avoid the microbursts? :P I'm all about new games, not remakes :P Originality, even if it isn't! ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Feeding your microdrive...
On Tue, Feb 8, 2011 at 5:03 PM, Tony Firshman t...@firshman.co.uk wrote: Plastic wrote, on 8/Feb/11 22:30 | Feb8: Hi all, During my time at Sandy, I learned microdrives (the part inside the case, not the cartridge) were surprisingly reliable and fault-free. The only two faults that came up on a regular basis were dirt, and damaged capstans. The capstan, for those not in the know) is the rubber wheel on the motor which contacts the tape. The microdrive capstan has one advantage over capstans from tape decks. Tape deck capstans contact a metal pin when in position. If left for a long time, the capstan rubber acquires a dent which makes the tape change speed as it passed through - also, it slightly stretches the tape. The microdrive design contacts a plastic wheel in the cartridge, so it only touches something when a cartridge is left in. However, some people leave a cartridge permanently in the drive when not in use, and this can cause problems eventually. I found a large number of QLs I repaired had migrating capstans. They had nothing other than friction to hold them onto the metal shaft, and they rose up in the majority. Maybe the ones that didn't had unused microdrives! In extreme cases the capstan actually touched the top case - I saw many like this. I did see that often. If you pulled the capstan off, and rubbed the motor shaft with a little rubbing alcohol to degrease it, the capstan was far less prone to sliding up. Also, it should be put on upside down afterward - it may have warn slightly unevenly and if so, it needs to spend the next interval wearing unevenly the opposite way - like rotating your tires. The wires that enter the motherboard are just tinned stranded wire and quite fragile. I always soldered pins on these as a first act of owning a QL - often, soldering on the pins was quicker than trying to fit that floppy mess of bent wire. I have tons of these pins so if anyone wants some for their QL, I'll happily mail them at no charge. If I had to remove microdrives, I always did this. Better than pins though is a SIL socket strip. I cut sections off a DIL turned pin socket. That way re-fitting is a doddle. What I have is the single rows of turned pins that we used to use on the SuperQBoard for the riser 512k memory daughter card. They're like a pre-cut sockets of very high quality. They used turned pins on all the boards I saw until I saw a US QL with the flat blade type socket - ick. At Sandy, we also found that cartridges would become error prone if not spun once in a while. I got into the practice of, once a month or two, spinning up every cartridge through at least one full loop (about 20-30 seconds) just to prevent print-through and to redistribute the lubricant. You'd be amazed how often we'd get mad microdrive complaints and we'd ask them to send in the computer and the problem cartridges, and they'd ALWAYS have fingerprints, or the computer smelled of cigarettes. Smoking kills cartridges! So does finger grease. If you pen your case to clean anything, or even 'open'. You are coming up with some brilliant mistypes, Dave. Wasn't it you who talked about 'dinky cars'? Sorry :) My hands are a little numb still and don't co-ordinate very well, and my eyes don't spot the missing letters. it's always a good idea to remove and refit the voltage regulator. That's the small 3-pin device screwed to the heatsink right behind the microdrives. It gets warm regulating the voltage, but a poor connection can also create heat, so reseating the regulator in its socket helps it stay cool. While you're at it, if you have any PC thermal paste/crease/ and another good mistype (8-)# arctic silver, replace that little plastic shim, if there is one, with a tiny dab of that and you'll find it transfers heat to the heatsink FAR better. Yes indeed. I did that to *every* QL I repaired. I'm thinking that by now a lot of the regulators and IC pins will be quite oxidized and could use a good cleaning. I use a PEN eraser to gently remove the oxide. Pen erasers don't generate static charge when rubbed. ICs do run a little cooler when they have good socket connections. One, the socket to pin contact has lower resistance. Two, better contact conducts heat away into the PCB slightly better. Additionally, a cooler IC draws less current than a hotter IC anyway, so it could make 20-30ma each difference on the 68008 or the copro. SOME people would get a tiny fan, hook it across the +9v and ground pins, and have it draw that air out the slots at the back. Nice if you can make it fit, but I don't think it makes much difference - it moves heat, but doesn't make sure it's being generated efficiently in the first place - just addresses the symptom. If I ever designed a QL PCB, it would have a far better power supply (but then, the PCB wouldn't be long and thin like that - it would be a eurocard or double eurocard
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 be brought to a release-stable state, is there interest in a commercial product based around this? -- 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] Approaches to parsing in SuperBASIC
If it helps any, I have a period of 6 months plus of medically-enforced non-work, so I have LOTS of free time. I would be happy to convert books to PDFs in the style of the manual, if they are in the public domain or if I have permission from the rights holder. I have already made it a project for the future to re-do the manual, make it into a searchable website, etc. Dave On Mon, Feb 7, 2011 at 4:02 AM, Malcolm Lear malc...@essex.ac.uk wrote: The download is 2.2 MB, it is not text searchable at all and is pretty cr4p. However, it's better than nothing! Just! Cheers, Norman. I'm slowly sorting this book out, so it will be searchable. However it's a bigger job that I first imagined. A version that matches the user guide format would also then be possible. Cheers Malcolm ___ 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] Approaches to parsing in SuperBASIC
On Mon, Feb 7, 2011 at 3:41 AM, Norman Dunbar nor...@dunbar-it.co.ukwrote: On 06/02/11 20:14, Plastic wrote:I bought this book years ago from Quanta, and was completely horrified by the quality of print. Nothing to do with Quanta of course, just a commercial book that looks like it was run off on a dot matrix printer! I understand she writes romance fiction now. I bet those books are much better quality. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
On Mon, Feb 7, 2011 at 1:44 AM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Am Sonntag, den 06.02.2011, 17:56 -0600 schrieb Plastic: Let me play with some code and see what I come up with over the next couple of days. I think I can be a lot more computationally economical, but my code will not flex easily to other cases, whereas your code is applicable in a lot of other cases. Dave, you sure can use this however you like. It's been posted to a public mailing list and thus considered public. And I'm sure I've built some nasty bugs in there for you to chew on. I've run the code through TURBO, for example, with the result that the parser is always off by one char in the line, need to have another look into it, that's interesting. Tobias, I am working on a method that splits the input into target, verb, quanta, modifier by simply splitting the string at the spaces. Then, I can simply check the rationality and meaning of the verb, quanta and modifier and aim it at the target. It's not 'sophisticated' but it appears it will execute a lot more quickly. One of my main burdens is I'd like to keep the screen update tick at once per second. Worst case, once per two seconds. Therefore, it would be good if all screen redrawing and one parser run can occur within one second. Can it be done without compiling? I don't know. I'm sure going to try to make it happen though! I hope there aren't any parts of plain old QDOS that aren't supported by Turbo. One thing that simplifies the program a LOT is TURTLE GRAPHICS! I need to draw trails for each plane to show heading and speed. Turtle gfx seems to be the most concise way to do it at this point. I may need to write something faster but more verbose later, but for now, it very neatly and simply solves the problem ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
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] Wondering...
Hi all, I have a US (samsung?) QL with JSA ROMs. I have a replacement membrane coming in a week or so. 1. It has the standard 512x256 resolution, but the font type/size is different than EU QLs. I am looking for some JM or JS ROMs, but meanwhile, does anyone have an easy way for me to load the UK charset and scaling onto it? Or a dead QL with JM or JS ROMs they're willing to part with? 2. I'd like to plug it into a monitor. Being in the US, this is less simple. Any suggestions? I am considering the RGB-VGA converter board, which is ideal but pricey. 3. I have an assortment of expansions which I will photograph. I do not have manuals for any of this stuff, so when I post the photos, any info would be appreciated. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] USBWiz Driver Update
Hehe. Sorry if it came across as pedantic. I just read the thread and saw that some people were seeing a conversation about formatting, and others were seeing a discussion about the esthetics of using the microdrive bays in the way they were intended. ;) Dave On Mon, Feb 7, 2011 at 9:42 AM, Adrian Ives adr...@acanthis.co.uk wrote: 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 Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Wondering...
No, I'm not sure. I assumed. How can I tell, just looking at the ICs? Dave On Mon, Feb 7, 2011 at 9:51 AM, Malcolm Lear malc...@essex.ac.uk wrote: Hi Dave, Are you sure it has a vertical resolution of 256? Maybe the video ULA has been replaced with a UK one. Malcolm On 07/02/2011 15:14, Plastic wrote: Hi all, I have a US (samsung?) QL with JSA ROMs. I have a replacement membrane coming in a week or so. 1. It has the standard 512x256 resolution, but the font type/size is different than EU QLs. I am looking for some JM or JS ROMs, but meanwhile, does anyone have an easy way for me to load the UK charset and scaling onto it? Or a dead QL with JM or JS ROMs they're willing to part with? 2. I'd like to plug it into a monitor. Being in the US, this is less simple. Any suggestions? I am considering the RGB-VGA converter board, which is ideal but pricey. 3. I have an assortment of expansions which I will photograph. I do not have manuals for any of this stuff, so when I post the photos, any info would be appreciated. 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 Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Wondering...
Luckily I have the JS+TK2 Q-Emulator 1.0 for Mac to test on - it behaves just like a real QL. All I need is a mdv_ to USB adaptor and I'm all set! Dave On Mon, Feb 7, 2011 at 9:57 AM, Rich Mellor r...@rwapservices.co.uk wrote: From memory (as both D-Day MKII and War in the East took account of the difference in these ROMs), the JSU still manages 512x256 pixels, but the graphics characters (founts) are smaller than on the European QL. It would take me quite some time to get the details again out of the two programs! Rich On 07/02/2011 15:51, Malcolm Lear wrote: Hi Dave, Are you sure it has a vertical resolution of 256? Maybe the video ULA has been replaced with a UK one. Malcolm On 07/02/2011 15:14, Plastic wrote: Hi all, I have a US (samsung?) QL with JSA ROMs. I have a replacement membrane coming in a week or so. 1. It has the standard 512x256 resolution, but the font type/size is different than EU QLs. I am looking for some JM or JS ROMs, but meanwhile, does anyone have an easy way for me to load the UK charset and scaling onto it? Or a dead QL with JM or JS ROMs they're willing to part with? 2. I'd like to plug it into a monitor. Being in the US, this is less simple. Any suggestions? I am considering the RGB-VGA converter board, which is ideal but pricey. 3. I have an assortment of expansions which I will photograph. I do not have manuals for any of this stuff, so when I post the photos, any info would be appreciated. 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 -- 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] Wondering...
It seems I will have to start saving for a UK spec QL, pronto. Having a real QL to work on is important to me. Dave On Mon, Feb 7, 2011 at 10:48 AM, Malcolm Lear malc...@essex.ac.uk wrote: On 07/02/2011 15:57, Rich Mellor wrote: From memory (as both D-Day MKII and War in the East took account of the difference in these ROMs), the JSU still manages 512x256 pixels, but the graphics characters (founts) are smaller than on the European QL. Ah, that sounds about right. The sort of bodge that only Sinclair would do! I seem to remember they altered the ULA timing for the US 525 system which meant that only around 200 lines were visible, hence the vertically reduced characters. The proper solution would have required an interlaced scan, but that may not have fitted into the ULU space and taken up too much design time. Malcolm ___ 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] Wondering...
I have a US QL, therefore I have a US QL PSU ;) Though I am capable of building a replacement PSU if needed, or converting a UK to US PSU. Also, US houses have 110v and 220v circuits, so 220v is available if I get really stuck (and don't mind QLing on the tumble dryer). The 50/60Hz issue is a non-issue. I would just replace the smoothing capacitor with a slightly larger one. As for the display modes...I would definitely prefer to use a UK/EU spec QL. I'm only aware of two US QL users and they're both ex-pats anyway, I think ;) Dave PS: and I am looking for the PSU, and not finding it. Fate, it mocks me. On Mon, Feb 7, 2011 at 12:00 PM, Malcolm Lear malc...@essex.ac.uk wrote: On 07/02/2011 17:21, tobias.froesc...@t-online.de wrote: -- From memory (as both D-Day MKII and War in the East took account of the -- difference in these ROMs), the JSU still manages 512x256 pixels, but the -- graphics characters (founts) are smaller than on the European QL. The QL Technical Manual says: This is different for countries where the television system is NTSC, which permits the use of fewer raster lines than PAL. In QLs for such countries, the following options are the defaults: For monitor operations, a 50Hz 624 non-interlaced system is used; this is the same system as is used on the English QL. The full 512x256 pixel display is available, and the default windows and character size are the same as for the monitor mode on an English QL. For TV operation, a 60Hz 524-line non-interlaced system is used in which the number of raster lines is limited to 192. In order to ease the task of software conversion, an alternate display font is provided which allows a 6x8 character square instead of the usual 6x10. This ensures approximately the same number of visible rows of text on both PAL and NTSC QLs, at the cost of true descenders and reduced vertical spacing. The default windows and graphics scaling for TV operation are different from those of the English QL. so it looks like only the TV modes would be different from European boxes. Cheers, Tobias Yes, the Mess emulator suggests that this is the case. The vertical timing and font is dependent on the F1/2 selection on bootup. Once in 624 50Hz mode you should be OK both in mode 4 and 8. Cheers Malcolm ___ 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] Wondering...
I know they redesigned the port area for the serial ports and joystick ports, but I wonder if this is a hardware difference, or a software difference, since the hardware can obviously handle both formats... I wonder if there are any other differences between the boards... I'll take this one out and post some high resolution pics of it so people can compare. Dave On Mon, Feb 7, 2011 at 12:17 PM, Timothy Swenson swenso...@sbcglobal.netwrote: On 2/7/2011 10:08 AM, Plastic wrote: I'm only aware of two US QL users and they're both ex-pats anyway, I think Actually, most of the US QLer's that I knew (been out of contact with mostf them for a while) were native born. I'm sure there are a few of the old QL'ers still around (like Herb Schaaf, Bill Cable, Paul Holmgren, etc). As for the US/UK scale issue, test the JSU and JS roms on the emulator and see if there is a difference. If there is, you now have access to the two different systems and can code for both. Tim Swenson ___ 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] Approaches to parsing in SuperBASIC
I'm working on the command parser for my Air Traffic Control sim. I have not written a parser in this sense before. The parser takes input from the user, and parses it into meaningful instructions to pass to an aircraft. It emulates a unified ear for the pilots of all the aircraft. It deals with a limited range of input. Grammar will be strictly enforced. Arguments will be separated by spaces. As an outline to the simple parsing I need to do, there is a standard for ATC sims which I will be following: ABC C NN - 2 digits is an altitude in thousands of feet ABC C NN X - the X modifier expedites the altitude change (where possible/reasonable) ABC C NNN - 3 digits is a heading in degrees ABC C NNN L (or R) - where a course change follows the shortest turn, L or R modifier makes the turn direction explicit ABC C $$$ - where a valid beacon is given, the aircraft will fly to that beacon ABC S NNN - change speed to... ABC L XXX - cleared to land on runway XXX (eg: 14L) ABC T - clearance to take off (an altitude must be set first As there are a maximum ten slots (thus ten aircraft) I will allow the shortcut that keys 1 thru 0 will auto enter the flight number for that slot, with a space appended. The sim continues during data entry so this is faster, but I will also allow manual typing of flight numbers. Are there any established principles of parsing that I should adhere to? I am debating where to make this a procedure or a function. I'd like to keep it sleek. I'd also like, as parsed, that it creates the string for the pilot's response as it goes and if at some point the parsing fails, I can reset the string to Huh? or something more helpful from the pilot... Discussion/ideas/snippets welcomed. Dave *For the purposes of this thread, my program is open-source (duh!) and I will happily share my code here. I will not, however, use anyone else's code without their explicit permission and agreement to have their code included within the sim as open-source. The assumption is I won't use your code. If it's key to the project, I may use the principle, but I would not use the code without the explicit permission above.* ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Game idea...
Hi all, I had a game idea back in the 80s. I feel like it might be a good followup project after the flight sim, but the idea is fun so I thought I would share it here and see what others might make of it. The game occurs in a two-dimensional gravity well. The yellow sun occupies a fixed point in the middle. The green planet orbits with an eccentricity that increases at higher levels. There will be other red bodies in random orbits too. The objective of the game is to accelerate or decelerate your ship to match orbits with the goal planet. Other bodies will affect your path. You must simply match the target's speed and velocity with a degree of accuracy that increases at higher levels. There will be a time and/or fuel limit. This game employs the N-body problem of gravitational bodies. I programmed the N-body problem in SuperBASIC in the 80s and will be able to recreate it fairly easily. I think it would be quite cool and playable and would be 100% graphical. Does anyone have any ideas to add to this, or suggestions? If you contribute ideas/code with this thread, I will presume you're sharing your ideas with the whole community and that I or others may freely use your ideas. Code, however, would only be used by explicit permission. When the game is completed, I will release it to the community, for free, with source. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
For clarity: ABC is the format of the flight number. eg: AAL2123, CAL2260, FDX1001, etc... Sometimes, there are three digit flights like BAA418, etc... I like the way you have the parser call a function to isolate each component. I have until this point been thinking in terms of... (pseudo-code alert!) IF c INSTR(cmd$) then it's a clearance and is rightmost character x?Set expedited flag. if not, a$ = (right 3 characters of cmd$) (eg: 030 or 10) (*note to self - this won't work for single digit altitudes - doh!*) check it makes a number is it a 3-digit number? (including 020 or 000) - it's a heading otherwise, it's an altitude. The other way I thought of doing it was parsing a character at a time and using the spaces as EOFs for each field. I am aware the decision tree for this language is straightforward. However, to me, it's not trivial if only because I haven't coded at this level in many years and this is truly stretching my mental muscles - which is why I am doing this ;) This is wonderful exercise. Thanks! Dave On Sun, Feb 6, 2011 at 4:53 AM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Dave, ABC C NN - 2 digits is an altitude in thousands of feet ABC C NN X - the X modifier expedites the altitude change (where possible/reasonable) ABC C NNN - 3 digits is a heading in degrees ABC C NNN L (or R) - where a course change follows the shortest turn, L or R modifier makes the turn direction explicit ABC C $$$ - where a valid beacon is given, the aircraft will fly to that beacon ABC S NNN - change speed to... ABC L XXX - cleared to land on runway XXX (eg: 14L) ABC T - clearance to take off (an altitude must be set first How would you handle more than one command per plane? (I.e. Climb to xxx and turn left to yyy) Your examples are not clear to me: I guesst the ABC part is some sort of plane identification? A flight #? A typical approach in any language would be a function that breaks a line into syntactical pieces (tokens) and returning the next token (here: anything separated by white space) from the input line as a string. Outside that, you'd have a lexical analyzer that checks whether the token you just got matches anything you'd expect. Your second line example would be handled lke: InitParser(ABC C N X) x$ = getNextToken () - would return ABC, your analyzer checks whether this is a valid flight # the next x$=getNextToken() would return C, you accept this because it is valid here the next x$=getNextToken() would return the new altitude - Your analyzer checks for valid numerical value the next x$=getNextToken() would return the X and the next one an empty string to signal to the analyzer that you're done with this line. obviously, the getNextToken function would need some non-local variables to keep track of where in the input line it currently is Those would need to be initialized along with the input line in initParesr for each new command line. The analyzer would be programmed as finite state machine that holds a non-local variable on where I am currently - i.e a state value that tells tehe analyzer what to expect next. Hope this helps 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] Approaches to parsing in SuperBASIC
Also... One of the major problems I'm having is the manual I downloaded. The QPCKeywords V1_02 document has many keywords missing/ignored that I remember, like RIGHT$, LEFT$ and INSTR... and I don't remember how to use them. I would dig in the garage to find the old printed manual, but it's FREEZING out there! One of the other things that might come out of this process for me is a heavily revised and annotated new manual, with better examples yet more concise instructions. Which I'd post for everyone's benefit. Dave On Sun, Feb 6, 2011 at 5:10 AM, Plastic plasticu...@gmail.com wrote: For clarity: ABC is the format of the flight number. eg: AAL2123, CAL2260, FDX1001, etc... Sometimes, there are three digit flights like BAA418, etc... I like the way you have the parser call a function to isolate each component. I have until this point been thinking in terms of... (pseudo-code alert!) IF c INSTR(cmd$) then it's a clearance and is rightmost character x?Set expedited flag. if not, a$ = (right 3 characters of cmd$) (eg: 030 or 10) (*note to self - this won't work for single digit altitudes - doh!*) check it makes a number is it a 3-digit number? (including 020 or 000) - it's a heading otherwise, it's an altitude. The other way I thought of doing it was parsing a character at a time and using the spaces as EOFs for each field. I am aware the decision tree for this language is straightforward. However, to me, it's not trivial if only because I haven't coded at this level in many years and this is truly stretching my mental muscles - which is why I am doing this ;) This is wonderful exercise. Thanks! Dave On Sun, Feb 6, 2011 at 4:53 AM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Dave, ABC C NN - 2 digits is an altitude in thousands of feet ABC C NN X - the X modifier expedites the altitude change (where possible/reasonable) ABC C NNN - 3 digits is a heading in degrees ABC C NNN L (or R) - where a course change follows the shortest turn, L or R modifier makes the turn direction explicit ABC C $$$ - where a valid beacon is given, the aircraft will fly to that beacon ABC S NNN - change speed to... ABC L XXX - cleared to land on runway XXX (eg: 14L) ABC T - clearance to take off (an altitude must be set first How would you handle more than one command per plane? (I.e. Climb to xxx and turn left to yyy) Your examples are not clear to me: I guesst the ABC part is some sort of plane identification? A flight #? A typical approach in any language would be a function that breaks a line into syntactical pieces (tokens) and returning the next token (here: anything separated by white space) from the input line as a string. Outside that, you'd have a lexical analyzer that checks whether the token you just got matches anything you'd expect. Your second line example would be handled lke: InitParser(ABC C N X) x$ = getNextToken () - would return ABC, your analyzer checks whether this is a valid flight # the next x$=getNextToken() would return C, you accept this because it is valid here the next x$=getNextToken() would return the new altitude - Your analyzer checks for valid numerical value the next x$=getNextToken() would return the X and the next one an empty string to signal to the analyzer that you're done with this line. obviously, the getNextToken function would need some non-local variables to keep track of where in the input line it currently is Those would need to be initialized along with the input line in initParesr for each new command line. The analyzer would be programmed as finite state machine that holds a non-local variable on where I am currently - i.e a state value that tells tehe analyzer what to expect next. Hope this helps 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] Approaches to parsing in SuperBASIC
Tobias, thank you! I have struggled with this for a couple of days. This'll teach me for having started out on a Commodore PET. I couldn't find INSTR in this manual because it's in the wrong place. After IO_PRIORITY. It never crossed my mind to look past the place it would logically be. This is how my memory works: it's not in there. Then you show me it, and it's there like it was never gone, (usually, not always). I never felt RIGHT$ was clumsy, because it was easy and as Phoebus will tell you, I do like to be spoon-fed ;) I do remember missing it so much when I got my QL. Thanks again. Dave On Sun, Feb 6, 2011 at 5:36 AM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Am 06.02.2011 12:19, schrieb Plastic: Also... One of the major problems I'm having is the manual I downloaded. The QPCKeywords V1_02 document has many keywords missing/ignored that I remember, like RIGHT$, LEFT$ and INSTR... and I don't remember how to use them. I would dig in the garage to find the old printed manual, but it's FREEZING out there! One of the other things that might come out of this process for me is a heavily revised and annotated new manual, with better examples yet more concise instructions. Which I'd post for everyone's benefit. Dave, the manual is right here and your memory is wrong ;-). One of the major differences of S*Basic against MS Basic used to be the omission of the keywords you mentioned. All of this somewhat clumsy approach of RIGHT$, LEFT$ is done with the much more elegant string slicing in S*BASIC. Replace LEFT$(x$, n) with x$(TO n) RIGHT$(x$,n) with x$(LEN(x$)-n TO) which is much more elegant, I think. INSTR is actually there. 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] Approaches to parsing in SuperBASIC
On Sun, Feb 6, 2011 at 5:47 AM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Am 06.02.2011 12:10, schrieb Plastic: For clarity: ABC is the format of the flight number. eg: AAL2123, CAL2260, FDX1001, etc... Sometimes, there are three digit flights like BAA418, etc... I like the way you have the parser call a function to isolate each component. I have until this point been thinking in terms of... (pseudo-code alert!) IF c INSTR(cmd$) then it's a clearance and is rightmost character x?Set expedited flag. if not, a$ = (right 3 characters of cmd$) (eg: 030 or 10) (*note to self - this won't work for single digit altitudes - doh!*) check it makes a number is it a 3-digit number? (including 020 or 000) - it's a heading otherwise, it's an altitude. The other way I thought of doing it was parsing a character at a time and using the spaces as EOFs for each field. I am aware the decision tree for this language is straightforward. However, to me, it's not trivial if only because I haven't coded at this level in many years and this is truly stretching my mental muscles - which is why I am doing this ;) Dave, anything using INSTR is probably a bad idea before actually having separated the command line into tokens - It ignores the position of the command and generates a lot of false positives - If you had a C in the flight#, for example, you'd understand Climb. Indeed. Seeing this problem and others is why I asked for help. I don't have an obvious solution and need to learn a better way. About the 'language': Is this really a real life example? The distinction between climbing and turning only done by the number of digits in the value? Sounds a bit too much ambiguity for a high-security approach to me. If the operator misses a single digit, he'd let the plane turn instead of climb, with possibly fatal (lethal) results. This also results in the fact that the decision tree for this language is rather _not_ straightforward. Before having seen the #of digits in the value, the language doesn't decide whether to climb or turn. (CS theory would say It's not a simple LR parser) Yes, that's how most of the keyboard data entered simulators do it. It is prone to typo catastrophes. That's part of the charm of it. If you don't have the concentration to type straight, it's like not speaking clearly. It is the ATC operator's job to follow the aircraft acknowledgements and ensure the pilots heard what you intended, and not what you said ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
On Sun, Feb 6, 2011 at 11:58 AM, QL-MyLink (f/fh) q...@mylink.adsl24.co.ukwrote: Tobias helpfully said - Dave, the manual is right here and your memory is wrong ;-). - Brave Dave, Do you have a copy of Jan Jones? It's great for *all* SBasic INSTR-uctions. John in Wales ___ I don't have anything - restarting from scratch. I have a US QL with funky US fonts and a bad membrane (replacement on way soon), a Gold Card, backplane, QubIDE w/o drivers... and Daniele Terdina's excellent Q-Emulator for Mac 1.0, which gets all the use. I bought SMSQ/E back in the day, on floppy, but can't find it or any of my old software. Dave Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Wow. You really thought about it. 221 lines of code! I have this notion that I need to scan through the characters and split the input into words. I can simplify a lot because the bounds are known and very limited. For example, S INSTR cmd$ is a very simple case and so is L - so for these simply extracting the flight and the target is straightforward. When C INSTR cmd$, if I check for a modifier (X or L) as the last character, it makes it as simple as the previous example. Let me play with some code and see what I come up with over the next couple of days. I think I can be a lot more computationally economical, but my code will not flex easily to other cases, whereas your code is applicable in a lot of other cases. If I can't do it, may I use your code example as a guide? It's well labeled, flexible and explicit. Dave On Sun, Feb 6, 2011 at 2:14 PM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Dave, had a lazy Sunday afternoon and was thinking about your problem - And, being a bit challenged and had nothing else to do, wrote a parser/analyzer for your Language: Ended up with quite a bit of code, the problem is not as simple as it seems (Hope I didn't over-complicate things). But I wanted to have a generic parser that could easily be extended and also probably be used for other purposes. It seems to understand most of the commands you mentioned and could be a starting point for you. Note it's currently only accepting uppercase commands. If you don't use Turbo and its toolkit, just remove the MANIFEST statemens at the beginning of lines 110 to 130, they declare the variables in the lines constant - I just like to use symbolic names for the states and commands instead of values, it's just easier to read. Now go ahead and tear it apart. Cheers, Tobias 100 DIM command$(100) 110 MANIFEST : S_REJECT_LINE = -1 : S_START = 1 : S_HAVE_FNO = 2 : S_DONE = 3 : S_GET_VALUE = 4 120 REMark some constants for the commands 130 MANIFEST : C_INVALID% = -1 : C_CHANGE% = 1 : C_SPEED% = 2 : C_TAKEOFF% = 3 : C_LAND% = 4 140 MANIFEST : C_CHANGEALT% = 5 : C_CHANGEHEAD% = 6 150 REPeat InpLoop 160 INPUT #1,Please enter a command Line:,command$ 170 valid = parseLine(command$) 180 IF (valid) THEN 190 PRINT Flight #;fNo$;, please ; 200 SELect ON command% 210 = C_SPEED% 220 PRINT Change speed to ; value 230 = C_TAKEOFF% 240 PRINT Take off 250 = C_LAND% 260 PRINT Land 270 = C_CHANGEALT% 280 PRINT Change altitude to ; value 290 = C_CHANGEHEAD% 300 PRINT Change heading to ; value 310 END SELect 320 ELSE 330 PRINT Invalid line 340 END IF 350 END REPeat InpLoop 360 : 370 DEFine PROCedure InitParser (l$) 380 linePos = 1 390 lineToParse$ = l$ 400 END DEFine 410 : 430 : 440 REMark 450 REMark * this procedure parses an entered command line into the parts needed 460 REMark * returns 1 in case of success. The variables are set as follows 470 REMark * fno$ holds the flight number 480 REMark * command% holds the command to execute (see line 130) 490 REMark * valueholds numeric value of command 500 REMark 510 DEFine FuNction parseLine(command$) 520 InitParser command$ 530 REMark Set status to Start parsing line 540 state = S_START 550 : 560 REMark enter the loop that walks through the state machine 570 REPeat parseLoop 580 token$ = getNextToken$ 590 REMark did we hit the end of line? 600 IF token$ = CHR$(10) THEN 610 REMark check whether we're done or would have needed more input to be valid 620 REMark anything except S_DONE at the end of input is a wrong line 630 SELect ON state 640 = S_REJECT_LINE 650 PRINT Line cmd$ invalid at line end 660 RETurn 0 670 = S_START 680 PRINT Empty line entered 690 RETurn 0 700 = S_HAVE_FNO 710 PRINT Something after flight number is missing 720 RETurn 0 730 = S_DONE 740 REMark valid end of command line 750 RETurn 1 760 = REMAINDER 770 PRINT Invalid state 780 RETurn 0 790 END SELect 800 ELSE 810 REMark Got a valid token, no line end 820 : 830 SELect ON state 840 = S_REJECT_LINE 850 PRINT Line rejected: Line cmd$ invalid at token$ State is:state 860 RETurn 0 870 = S_START 880 fNo$ = getFlightNo$ (token$) 890 IF fNo$ INVALID THEN 900 state = S_HAVE_FNO 910 ELSE 920 PRINT Invalid Flight number 930 state = S_REJECT_LINE 940 END IF 950 = S_HAVE_FNO 960 command% = getCommand%
Re: [Ql-Users] 12th February 2011
On Sat, Feb 5, 2011 at 3:47 PM, QL-MyLink (f/fh) q...@mylink.adsl24.co.uk wrote: What do I know about Derby? It's where they say Twosdee. That is, unless it isn't. And give over, if you 'avn't. I hear it a lot! John in Wales PS: Off topic? Of course not - it's a space-filler for the Toady Editor ;) ___ ___ Lorem ipsum dolor sit amet, consectetur adipiscing elit. In lacus tellus, accumsan id congue a, bibendum ac urna! Duis congue tortor vitae arcu viverra tristique vestibulum sem bibendum. Integer eleifend mauris a lectus ornare in pellentesque odio aliquam. :) Integer rhoncus, leo ac ullamcorper congue, magna purus dignissim nisi, eget blandit dolor dui sed turpis. :-P Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] IDE versus SD card
On Fri, Feb 4, 2011 at 5:02 AM, Peter pg...@q40.de wrote: Hi, data transfer from an SD card takes 0.4 microsecond per Byte in the most simple mode, while the minimum cycle of the QL bus is 1.0 microsecond. So both IDE and SD card are faster than the QL bus. SD cards are smaller and cheaper than IDE drives. Both offer more size than a QL filesystem can use. If a fast SD card interface driver for the QL was here: Where would be the point in IDE for the QL? Apart from being too laid-back to copy data to SD card once :-) I understand keeping the microdrive for antiquarianism, because it was part of the original QL. But that doesn't count for IDE. Otherwise it would be quite simple for me to implement. All the best Peter Everything you say is true. Common sense. The main problem you have to overcome is 25 years of inertia. People are familiar with hard drives. Also, people seem to think SD cars are dinky like microdrives. The secondary problem is, the format and commands should be universal and should be used broadly in all new hardware - are you interested in licensing your design and code to anyone else? :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Extremely rare example of a Sinclair QL with Dongle
It's interesting that this is a D07- machine. My first QL was a D07- with JM ROMs, and my second was a D13- with JS ROMS. The first was $399 and as reliable as a Lada. The second was $99 and probably still works. Dave On Fri, Feb 4, 2011 at 8:55 AM, Neil Riley neil.ri...@boxclever.co.ukwrote: Remembered last night that my very brief ownership of less than an hour with QL number 1 was an Version FB machine. I was 18. Urs Koenig (QL) q...@bluewin.ch 04 February 2011 14:18 Yesterday Rich Mellor wrote: Urs - what were the issue motherboards you got hold of - was it an issue 2 I sent to you which was missing the expansion connector? I'm still lurking on the mailing-list. Amazing how busy it is those days. Go on! There's a video where I'm talking about this subject. Here's the direct link to the section of this video: http://www.youtube.com/watch?v=MlujA78ERdY#t=9m17s Interested tinkerers please check the links below for more in-depth QL stories... Cheers, Urs - QLvsJAGUAR - Much more than retro! - Always remember: QL forever! Website: http://www.qlvsjaguar.homepage.bluewin.ch Videos: http://www.youtube.com/user/QLvsJaguar Pictures: http://cid-c250d8748980ce5a.photos.live.com/albums.aspx ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm *** The contents of this email are confidential to the intended recipient. It may not be disclosed to or used by anyone other than the addressee, nor may it be copied in any way. If received in error, please contact the company on 01793-715380, then delete it from your system. Please note neither the company nor the sender accepts any responsibility for viruses and it is your responsibility to scan attachments (if any) for viruses. No contract may be concluded on behalf of the company by means of email communications. BC Services (UK) Limited (trading as Boxclever), Technology House, Ampthill Road, Bedford, MK42 9QQ. Registered No. 5290544 England www.boxclever.co.uk *** ___ 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] IDE versus SD card
Also, Tony, how feasible is it to repurpose the RomDisq work for use with removable flash-type storage like CompactFlash or SDHC? Dave On Fri, Feb 4, 2011 at 10:05 AM, Dilwyn Jones dil...@evans1511.fsnet.co.ukwrote: A lot of them nowadays have load balancing code in the hardware. If it notices a hot spot, it reorganises the data to avoid that hot spot. Cheaper ones, probably done. I vaguely remember that Tony Tebby's drivers for RomDisq from TF Services might have had something like this. Tony? (Guess my memory's good at remembering vague things but ain't what it used to be for the details of those things!) 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] Reality Check
On Thu, Feb 3, 2011 at 4:43 PM, Dilwyn Jones dil...@evans1511.fsnet.co.ukwrote: Sad though that, as Tobias said, it seems that Jan has no plans to do any further work on the 'new' Qubide. Dilwyn Jones If I had a schematic and code, I would be happy to (re)design anything out there. I don't have any production ability - but that would change in about six months. I have always wanted to take the existing QL mainboard schematic and do an updated version with improved power, and on-board IDE, floppy and mouse, and a 680X0 and faster memory. Something like Peter Graf's work, but all on one replacement PCB. I understand it's not the most viable project, financially, and it would best be a team effort, but I have a little 80s and 90s experience to bring to bear (nothing CLOSE to Peter Graf's skills) and could do a modest QL PCB redesign... Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Air Traffic Control Sim
And for complete off-topicness, the huge storm just blew through and the temperature just dropped from 68F(20C) to 27F(-3C) in about 150 seconds. Unbelievable - I have never experienced anything like it. Snow flurries in Austin, TX at 3:50am, and 5 minutes ago it was comfortable t-shirt weather. Tonight it's getting down to 15F(-10C) they say. Perfect programming weather! Dave On Tue, Feb 1, 2011 at 2:37 AM, Norman Dunbar nor...@dunbar-it.co.ukwrote: Morning Malcolm, tongue slightly in cheek I find this mailing list to be quaint and archaic in some of its conventions - bottom-replies being the main one. It's all very BRITISH! Yes, we like to read from top to bottom in the UK! ;-) Looking through the archives, it seems bottom replies have always been the preferred way on this list. So best to stay that way. Look at any magazine or book as well, they read from the top down too. Makes sense to most Westerners I suppose. Asia, on the other hand, does read from bottom to top though. But they also use a different characterset too. /tongue slightly in cheek ;-) Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ 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] Air Traffic Control Sim
So, I have started on my ATC project. I thought I'd document here my struggles, learning, and how I did it. I'm hoping it'll engage other BASIC programmers in discussion, and maybe you (yes, YOU!) will help me if you can see me getting stuck. Please remember this is primarily an exercise in improving and restoring my mind after a bump on the noggin. I'm fighting against some short term memory problems. I'm using the Mac version 1.0 of Q-Emulator, and SuperBASIC on JS ROMS with TK2. I'm writing it to run at standard QL speeds, and to run at a consistent speed on faster hardware. So far, I have written out a table of some of the variables I need, and their valid ranges, and how I will auto-generate pseudo-random flight numbers, altitudes and speeds for various aircraft profiles. Next, I will work out a co-ordinate base for a local airport. I have chosen Bergstrom because it is local to me, and I know where all the beacons and VORs are. I have decided that there are hard bits (it's a technical term) in this project for me (I know to some of you, these will be trivial, but to me, the solution isn't obvious): 1. I'll be keeping the aircraft, their altitude, speed, direction, intended alt, speed and direction, etc, in a large DIMmed array that can hold 10 aircraft. Landed or departed aircraft will be removed from the array and any newer aircraft will be scrolled up one spot. Like in real life, the oldest aircraft is always at the top of the stack. There will be inbound and outbound aircraft. Inbound aircraft will be announced and placed at the edge of the screen, and outbound aircraft will originate from the runway when given flight instructions and clearance to take off. The aircraft must always maintain separation of 1000 feet altitude and 3 miles horizontally. Checking all the aircraft against each other to see if any violate airspace of others, or have collided, might be hard to code. 2. I need to write a command parser to accept input from the user, namely instruction for flights. There is a standard way of doing this and I will follow this. This means I need to accept input and add it to a stack, then when it is entered I need to parse it to ensure valid, rational input. Once I know it is within bounds, I need to carry out the action, i.e. instruct the aircraft to follow the instruction. 3. I need to write routines for landing aircraft. Once instructed to land, I need to detect when they cross the glide-slope, and get them to follow it to landing, land, then remove themselves from the stack. 4. I need to write a ticker... No matter the speed of the hardware, the game should run at the same speed. This means events should be triggered at an interval, complete (even on the slowest hardware) before the next interval. This interval should ideally be 1 second, but could be 2 seconds. Despite the ticker, the input routines need to continue unaffected. Responsiveness of keyboard input is essential. 5. I need to plot this on a 512x256 screen. I can't let flights go off the edge of the screen. 6. I need to detect valid landings of arrivals and proper exits of departures. 7. I'd like to add an element of realism where planes, including departures, can declare emergencies. Well, those are the hard bits I can see up front. I can foresee earning a little money next week, so maybe a compiler will be in my future? I'd prefer an easy compiler over a good compiler. I would also love to have an external USB floppy so I could save my stuff somewhere other than my OS X HD... Maybe later... In the mean time, I'll work on this and keep sharing. Hopefully it'll work out. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Air Traffic Control Sim
On Mon, Jan 31, 2011 at 5:08 AM, Petri Pellinen p...@iki.fi wrote: Hi Dave, being a private pilot and an ATC sim fan myself this is a very interesting project. Looks like a nice initial concept. Are you going to share the source code for this somewhere (github, sourceforge, ...) ? Maybe couple of different types of aircraft and related performace values. Would add nice flavour when you can't tell a Cessna to maintain a 2500 fpm climb ;) Or tell a LearJet to slow down to 80 on the final. Best of luck with the project and especially your recovery! Cheers, Petri There will be standard profiles for everything from a 747-400 down to a Cessna 150, which will be listed on the slots and which will limit their speed and rate of climb, etc. I'll also try to keep it rational so Fedex doesn't use Cessnas and Delta doesn't use Learjets ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Air Traffic Control Sim
On Mon, Jan 31, 2011 at 7:19 AM, tobias.froesc...@t-online.de tobias.froesc...@t-online.de wrote: Dave, you asked for it, so see comments below: Am Montag, den 31.01.2011, 04:49 -0600 schrieb Plastic: So, I have started on my ATC project. 1. I'll be keeping the aircraft, their altitude, speed, direction, intended alt, speed and direction, etc, in a large DIMmed array that can hold 10 aircraft. Landed or departed aircraft will be removed from the array and any newer aircraft will be scrolled up one spot. If you coding for speed, shuffling around large amounts of data through array indices is probably a bad idea - Maintain a pointer variable instead that holds the starting index. the one before that is the last. Instead of moving around all the planes through the arrays, you then just increase the pointer by one and the data in the arraysstays where it is (e.g if your pointer variable is 5, your first plane sits in planes(5), the last one in planes(4). to handle the wrap-around, use MOD. I decided to do it this way for two reasons: The first being that t is quite lightweight to code. If the fourth plane in the stack lands, I simply need to call a FuNction to move slots 5-9 up one. This makes a lot of other things simpler. For example, there will never be a plane after the empty slot. Planes would then be self-ordering, and it makes display issues a lot easier. The second reason is that I'd like to process the plane movements together, then process the screen handling, then invoke the ticker to detect the next time I need to process the panes. The only time workload becomes a problem is if the work cannot be done in one tick. At that time, I might need to look at what I have done and re-write it a more efficient, yet obtuse way. I have Lightning on microdrive here, but it's frustrating that I cannot get it onto the mac emulator easily - also, I can't count on everyone else having Lightning. The screen handling is by far the slowest part of this. Like in real life, the oldest aircraft is always at the top of the stack. There will be inbound and outbound aircraft. Inbound aircraft will be announced and placed at the edge of the screen, and outbound aircraft will originate from the runway when given flight instructions and clearance to take off. The aircraft must always maintain separation of 1000 feet altitude and 3 miles horizontally. Checking all the aircraft against each other to see if any violate airspace of others, or have collided, might be hard to code. You should decide what sort of coordinate system your planes live in. You might want to divide the airspace in equally-sized cubes where each cube can only be occupied by one plane - This will simplify programming, but loose the impression of 'continuous movement' for the player - or you might decide to have a coordinate system based on real topograhic data like 5 miles 400 yards south, 3 miles 100 yards east, which will be a bit more complicated to handle. I have decided to simply use 0-432 for the x axis and 0-256 for the x-axis. These are FP values so movement will be quite smooth. [snip] 7. I'd like to add an element of realism where planes, including departures, can declare emergencies. And planes trying to land on the wrong runway, not on the glide path, abort the landing, and so on. A game like this shouldn't be too realistic - otherwise it would become boring. People doing this in real life get a lot of compensation for doing their boring routine job right (Travelling a lot by plane, I hope so, at least) For simplicity, I won't create those situations, but if a plane that is asked to land on a runway never crosses the glide-slope, I need to detect that as the plane passes the runway, and have the plane do something rational, like climb, increase speed, hold heading, and contact you for for a go-around. [snip] Go get yourself the free Turbo compiler and its toolkit and save your money. You can't do much better than that. I'll have to hunt that out. I understand Turbo is the one that requires precise coding. Given I've revoked my old hand status and consider myself a beginner again, it might not be for me. I'll give it a shot though. In any case, I'll be posting my code. For you all to laugh at. Which you will. And that will be educational for me. :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Air Traffic Control Sim
On Mon, Jan 31, 2011 at 4:43 PM, tobias.froesc...@t-online.de tobias.froesc...@t-online.de wrote: Dave, please see more comments below (Using the web-mailer of my ISP, there's really no reasonable way to top-quote. Sorry to anyone willing to complain) I find this mailing list to be quaint and archaic in some of its conventions - bottom-replies being the main one. It's all very BRITISH! Cheers, Tobias -Original-Nachricht- I have decided to simply use 0-432 for the x axis and 0-256 for the x-axis. These are FP values so movement will be quite smooth. --TF: That means you'll need to refer to sin() and cos() to calculate distances in 3D space. Be sure you -- have your maths at hand, then Yup. I once did a three-body gravity algorithm in SuperBASIC - that was an interesting problem, After that, this should be fairly straightforward. [snip]-- Turbo nowadays digests pretty much anything you throw at it (except stuff which is next to complete -- nonsense). George Gwilt et al have done a tremendous job of making it into the best free basic -- compiler i know of. Check out at Dilwyn's site at -- http://www.dilwyn.me.uk/turbo/index.html The best? There's more than one? In any case, the clarity and conciseness of the instructions is probably the most important aspect of this. In any case, I'll be posting my code. For you all to laugh at. Which you will. And that will be educational for me. :) -- Promised we won't laugh. At least not in public ;-) Oh, I can handle harsh criticism - my style is probably going to be unconventional to say the least. However, gentle and constructive criticism, that will go a lot further in helping me to my goals... Dave PS: Thank you *Daniele Terdina* for working on the *Mac Q-Emulator* - it's wonderful and I hope it sells enough to justify further development. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Finally a reply - from the Treasurer
I asked a friend who could give an opinion and she said: The question here is, If a person is appointed to a position in contravention of the Constitution, is the appointment invalid or is it merely improper. If the appointment is invalid, the person is not the position holder and cannot conduct the actions of the position lawfully. If the appointment is improper, they can - the failing not occurring in their actions but in the actions of their election. Another, broader concept applies here. The Constitution is the rules of the organization, and they can be nullified by a vote which ignores or overrides them. In this case, the election of an individual to a position they are explicitly barred from holding is a nullification of those elements of the Constitution, and is improper. It is not illegal. The organization should then revisit and revise the Constitution. The person holding this position in this case can lawfully sign a cheque. Opinion of Jacqui Webb, Head of Commercial Law, Partner. So that's that. I'm sorry to see Quanta falling into this type of problem as the membership shrinks. It would be prudent for Quanta to recognize their new role as Guardian of the Data and to trim the burden of their Constitution to better face the reality of the world in which they now operate. Good luck! Dave Dave ___ 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 version of QDOSMSQ?
On Thu, Jan 27, 2011 at 5:51 AM, Norman Dunbar nor...@dunbar-it.co.ukwrote: 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? I'd like to see: A block sound driver, so we can do interesting and useful things with standard sounds. A windowing system that isn't just easy and cosmetically pretty for application users to understand, but that's also easy to code with. A new OS-supported distribution/save format that permanently resolves the stripped headers issue. A HAL - Hardware Abstraction Layer - to make the OS less dependent on specific elements of the hardware that have held us back for some time. A new boot option to allow us to configure behavior of the system, eg: installed RAM without dropping to a host OS (if emulating) or on genuine Moto hardware so all functions pertaining to configuring hardware are consistent parts of the OS, not variable of assorted emulators. Proper networking. Treating sockets with device independence too, so OPEN #5,tcp_192,168,0,17p80 is valid. Font improvements. Start by calling them fonts - but also by having a choice of bitmapped or outlined fonts with anti-aliasing. Remote desktop. Standard encryption/decryption. Something modern. Unix-style users. It's a multi-tasking OS. If people can never log into it from elsewhere and have it recognize users and privileges, there's only so much it will ever be able to do in the future. Some IO functions. QDOS makes a good RTOS for IO function, data logging etc - everything is there in the OS except good IO and logging functions. It would make a great robotics OS. A group of people to come together to help write drivers for things. There are many hardware projects stalled simply for lack of drivers. People with those skills need to communicate, and take requests for help, then divide and conquer. There are, that I know of, at least two stalled projects now because of these types of issues. OS-driven speech. USB drivers and drivers for certain classes of standard devices like UVC webcams, TWAIN scanners, PCL5 printers, etc. In fact, a whole new printing system, like CUPS, would be nice. Dave ___ 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 version of QDOSMSQ?
On Fri, Jan 28, 2011 at 5:08 AM, gdgqler gdgq...@gmail.com wrote: Compilation by TURBO allows solution of another problem which how to use another routine if the one you want is not loaded on your machine. Apologies for the off-topicness, but one thing I'd like to see from Turbo or other compilers is a command maker that can take a PROCedure or FuNction, compile it, and package it up so it can be loaded to extend BASIC. I think this would result in a mini-renaissance of keyword development, which could act as a suggestion line for additions to SuperBASIC and, more broadly, QDOSMSQ. ___ 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 version ofQDOSMSQ?
On Fri, Jan 28, 2011 at 5:33 AM, Ralf Reköndt ralf.rekoe...@t-online.dewrote: Plastic wrote: Apologies for the off-topicness, but one thing I'd like to see from Turbo or other compilers is a command maker that can take a PROCedure or FuNction, compile it, and package it up so it can be loaded to extend BASIC. Works with QLib (and also Turbo, I think). With QLib, if you start such a resident extension, it results in creating a JOB (even if without windows), so I think, not quite what you want. Cheers...Ralf ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm Yes, not. I was thinking specifically of it creating superbasic extensions deliberately for that purpose, to be LRESPR'd and linked into the keyword list. It would make for an interesting website to host, where people could submit keywords with manual entries, and release updated versions, etc. The commands could be coded in native assembly, or in BASIC, with sources or not. Where sources were offered, people could check for errors, or offer enhancements/patches. By extending this to existing keywords, skilled people could make functionality or performance enhancements that could then feed back into the OS. I would be happy to code and host such a site, if there was interest. Dave ___ 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 version ofQDOSMSQ?
On Fri, Jan 28, 2011 at 9:09 AM, gdgqler gdgq...@gmail.com wrote: This is something I would like too. In my BOOT i have a procedure which prints a given a$, but the format of the fp number is QDOS. For example a$ could be $080004000. Of course in QDOS there are no NANs. I'm pretty sure that my BOOT also has the reverse procedure, but either I never use it or I have not used it for along time. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm Hmmm. a$ = CONVERT$(number, from_base, to_base) from_base and to_base could be eg: 2, 10, 16, FP (for floating point) If the conversion was invalid, simply leave a$ unset or to an impossible value. a$ could be commuted to a if the value was decimal - which would be explicit to the programmer. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL On A Stick
I am looking at uQLx on linux... Just because it can be so small that any box that can boot from the stick can be that. However, I'm also looking at it from the POV that architecture matters a little and weighing up Intel vs. ARM performance. It'll be a slow project due to zero finances, but if I can contribute anything back, I will, happily. Dave On Fri, Jan 28, 2011 at 10:36 AM, Dilwyn Jones dil...@evans1511.fsnet.co.uk wrote: I have been asked about the possibilities of a QL On A Stick version for Linux, or even a version which could be used on both Linux and Windows. The current version of QL On A Stick is for Windows only. Unfotunately, I have no knowledge whatsoever of Linux and wouldn't know where to start. I presume that what was asked for would involve the CD or pen drive having: (1) QLay for Linux (2) uQLx (3) QPC2 demo version with WINE (4) Any other emulators or utilities considered appropriate Would anyone be willing and able to help us with this? I'll gladly send a CD copy of the Windows version to anyone willing to help. 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] Programming project request...
I think what is needed is a manufacturer license that can be extended to people who are developing hardware and who need a close level of integration between the OS and hardware. The license should have a simple per unit fee, and the manufacturer should be responsible for supporting the OS on that hardware, and for supplying updates for that hardware. I don't know who the responsible parties are, but I would be happy to help negotiate such an agreement, if the parties were looking for a non-interested party. Dave On Wed, Jan 26, 2011 at 10:11 AM, Tony Firshman t...@firshman.co.uk wrote: thorsten herbert wrote, on 26/Jan/11 16:01 | Jan26: Major QL hardware is practically impossible as long as the QL operating system situation remains as it has been for almost a decade. The only reasonable way out seems to be a restructured Minerva with new drivers. Work on it continues slowly. I'm not aware of that information. Who is the right person to work on this drivers? One other way, for Peter, is an open source version of SMSQ. Tony -- QBBS (QL fido BBS 2:257/67) tel:+441442828255+44(0)1442-828255tel:+441442828255 t...@firshman.co.uk http://firshman.co.uk Voice: tel:+441442828254+44(0)1442-828254 tel:+441442828254 Fax: tel:+441442828255+44(0)1442-828255 tel:+441442828255 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] Programming project request...
On Tue, Jan 25, 2011 at 5:00 AM, Peter pg...@q40.de wrote: Plastic wrote: The reason I said ARM is because it's readily available extremely cheaply, easy to design with, and there's a plethora of available boards already. You could use any Microcontroller with Linux. It is debatable which non- 68K controller would be the best. I might vote for SuperH instead of ARM, but don't you think all of them are boring mainstream? :-) Boring mainstream means cheap mainstream means long term availability of standard designs at commodity prices. One of the problems hardware developers have faced in the past is they'd pick a suitable programmable logic chip, then it would be superseded, and they'd have to modify their designs. The idea of a QL in a CPLD is nice. The Q60 split it across four - a no-brainer at the time - but I am sure there's lots you could do differently with newer devices on the market. I favor the ARM family for a couple of reasons: it's a standard instruction set that is simple, fast, well documented and incredibly cheap. My 2W power statements are for high end devices with dual cores. Many bottom end system-on-chip ARM devices have standard 500MHz, IDE, SATA, USB, video, I2C, etc and could easily emulate a SGC QL. Inside a QL case, nobody would even know they were not a QL unless told, shown, or very VERY observant ;) This raises the question of what is a real QL. Different people have different answers. I would expect a hardware designer to find a hardware aspect to be primary, and a OS user to favor the OS experience. Finally, ARM Intel. Intel licensed the ARM design when they acquired Digital and the original StrongARM designs. They lost interest in the market segment and sold it off, and not ten minutes later, it got interesting in that segment and they started the mobile designs which led to the current Atom chips. Atom is okay, but it draws an order of magnitude more power than an ARM board and has approx. 3x the hardware cost. Embedded linux is already on ARM, if Clive were active today in this market, I think ARM is what he'd choose. Following the ARM route, we can easily obtain ready made boards for around $100 (70 ukp) complete, or design our own (where are you, Nasta?) and build them for around $150 (100 ukp). Add margin and it sounds expensive compared to a QL on a chip :-) When you add the hard drive, interfaces, PCB, the cost would be about the same. However, the quirky, hardly any of them exist, everything is a little bit experimental, a little bit of a hack, using NOS components with no reliable supply. It would be attractive to some in the community, but nobody outside of it. It's a closed market. ARM (or Intel ;) puts QDOS/SMSQ in an open market of standard, supported hardware where traders can sell the boards into embedded markets too, gain economies of scale, and promote the QDOS aspect to new people who might like an easy programmable device for all kinds of embedded applications - I'm convinced (though not being very realistic) that SuperBASIC is a quick developer's dream, and the SBASIC - C converters etc would do well, also. You say it would be a massive amount of Linux work, but the work has already been done. Linux is there and is self-supported and developing. uQLx is there, and works quite well on Linux. It could use some development to increase options, but that's right up this community's street ;) Same would be possible for x86, and obviously nobody cares. You still boot something which is multitudes the size and complexity of Minerva. I can see no news and no sensation here. ARM or not ARM, running a different OS with emulator will never be as cool as the real thing :-) There aren't ever going to be more new QLs. There may be one last gasp Motorola-based board, but I suspect not because the Q60 already fills that role very well. It's neat. And costs more than a high end laptop here in the States. At some point in the next 5-10 years all these QLs will start to become unreliable and die. We need to replace them with something, or the community will disperse. My heart's desire is that QDOS, in all its forms, carries on and grows and is seen by new people who are not a captive audience. Our poor kids! It's a cool and capable embedded OS that could do need things... like be in micro-sats, robots, washing machine controllers, home monitoring systems, car entertainment system... Anywhere linux on ARM naturally goes. For me, ARM is a no-brainer. For you, the argument is less compelling, and you're *absolutely right* to feel that way. If the QL was ever just one person's direction, we wouldn't all still be using it, and SMSQ/E, the Q60, the pointer environment, and emulations wouldn't exist. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Programming project request...
On Mon, Jan 24, 2011 at 7:59 AM, Peter pg...@q40.de wrote: Hi Dave, how about a commandline tool which can automatically delete a whole directotry tree with all files in it? :-) Never found this yet... All the best Peter You design computers before breakfast, so obviously that sounds a lot easier to you than it does to me ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
