Re: [Ql-Users] SMSQmulator
Hi, I think SMSQmulator is a great piece of software. I am not interested in the speed. Derek On 26/01/2013 23:32, jms1 wrote: Dear Wolfgang Regardless of how disappointed you are on the resulting speed I think you have done a great job in producing a java emulation for the QL. At very least it makes it easier for people to try the QL. The java emulations are going to be slow because the Java virtual machine is slow and effectively you are running a virtual machine in a virtual machine. As the java machine has a built in garbage collector timings are going to be erratic as the whole java machine suddenly stop while it does the garbage collection. Would it be possible to increase the speed of the emulation if the keyboard was only checked as often in time as the standard QL does? Could this also be done for the display? As for two core machine the increase in speed over a single core machine is very dependent on how many tasks are running and whether it is possible to allocate a single core to the java machine. The increase in speed of multi processor machines or array of machines is only really produced when you can split the problem into many independent parts such mandlebrot programes or weather simulations. So carry on the good work and bask the glory having done it. John Sadler On 2013-01-26 17:42, Wolfgang Lenerz wrote: Hi, Hmm, the enormous speed differences (w/r to QPC) baffle me. Here, QPC is about 8-10 times faster, but that's it (which is still a great lot faster!). Apparently, a (single core?) Celeron really slows SMSQmulator down. If I had had those speeds when developing - SMSQmulator wouldn't have seen the light of day. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
On 27/01/2013 11:20, Derek Stewart wrote: Hi, I think SMSQmulator is a great piece of software. I am not interested in the speed. Derek I too think that this is a great achievement and a good addition to the QL arsenal. As something to add to the request list - how easy would it be to allow the emulator to support the same headers on executable files as q-emulator - so that the two emulators could easily share files (rather than using a qxl.win file for a small program?) -- Rich Mellor RWAP Services Specialist Enuuk Auction Programming Services www.rwapservices.co.uk ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] GWASL update
Norman Dunbar has found a fault in GWASL which affects the reporting of errors in labels. This is corrected in version 2.05 which can be downloaded from my site at http://gwiltprogs.info/ George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Hi John, Regardless of how disappointed you are on the resulting speed I think you have done a great job in producing a java emulation for the QL. At very least it makes it easier for people to try the QL. Well I'm not that disappointed really at the difference in speed with QPC. What baffles me is that this difference seems to vary so much from machine to machine. Some here have reported of sufficient speed, whereas others (e.g. Bob Spelten, Ian Burkinshaw) reported a totally useless emulation because of its slow speed. Moreover, how come a 2+Ghz machine is so much slower than, say, a Raspberry Pi (even though that, also, is too slow to be useful.? Id like to hear more about Bob's machine : is it also a single core like I think Ian's is? The java emulations are going to be slow because the Java virtual machine is slow Sorry, but no. (And please, let's NOT open that debate)... Mainly, SMSQmulator is slow because: 1 - I'm trying to to things with Java for which is wasn't really designed (painting single pixels to a screen, low level byte,word access to variables and memory, etc). 2 - The emulation core isn't necessarily designed for speed. 3 - I'm by far not the programmer Marcel is. As the java machine has a built-in garbage collector timings are going to be erratic as the whole java machine suddenly stop while it does the garbage collection. Perhaps, but I doubt it. I've yet to see such a phenomenon. Would it be possible to increase the speed of the emulation if the keyboard was only checked as often in time as the standard QL does? The machine only has one single interrupt - a 50 Hz interrupt, just like the QL. There is no way to make that any slower, else things (like the clock) will go wrong etc. Even the keyboard doesn't generate an interrupt as such (so if you could type faster than 50 chars per second, some would get lost...) Could this also be done for the display? Well, drawing to the screen is heavy on the resources, ESPECIALLY when one is in QL compatible mode. Basically, I redraw the ENTIRE screen once for every pixel changed (or every 2 or 4 fixels in QL mode). If anyone could point me to a way to change a wingle pixel in a window I'd be grateful... (...) So carry on the good work and bask the glory having done it. Thanks for your kind words. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Hi John in Wales, Thanks for your kind words. I have not installed your simulator yet, but I have read here so much appreciative feedback that I know that the QL community has received from you something very, very, worthwile. Please don't scrap it in despair... I haven't tried it yet! ;-) No, I'm not going to give up on it, since here it runs sufficiently fast. I use this for all my QL work now, even for doing SMSQ/E stuff on it. I always knew there would be a speed penalty against QPC and that doesn't bother me in the slightest. What does bother me that on some machines SMSQmulator seems to be totally useless... Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Hi Rich, As something to add to the request list - how easy would it be to allow the emulator to support the same headers on executable files as q-emulator - so that the two emulators could easily share files (rather than using a qxl.win file for a small program?) I'm sorry to say that I know nothing about Q-emulator, apart from its existence. Is there some documentation somewhere on its file / header format? Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Wolfgang Lenerz wrote: Well, drawing to the screen is heavy on the resources, ESPECIALLY when one is in QL compatible mode. Basically, I redraw the ENTIRE screen once for every pixel changed (or every 2 or 4 fixels in QL mode). If anyone could point me to a way to change a wingle pixel in a window I'd be grateful... QPC of course has the same problem. I solve this by using a queue that buffers display accesses and only apply the changes to the screen image 62,5 times per seconds. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Marcel Kilgus wrote, on 27/Jan/13 18:05 | Jan27: Wolfgang Lenerz wrote: Well, drawing to the screen is heavy on the resources, ESPECIALLY when one is in QL compatible mode. Basically, I redraw the ENTIRE screen once for every pixel changed (or every 2 or 4 fixels in QL mode). If anyone could point me to a way to change a wingle pixel in a window I'd be grateful... QPC of course has the same problem. I solve this by using a queue that buffers display accesses and only apply the changes to the screen image 62,5 times per seconds. Is there anything to be gained from the (very) old trick of storing the previous screen content and only writing changes? I know when Ben (my son) did this with a javascript application it resulted in a three times speed improvement. Tony -- t...@firshman.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Tony Firshman wrote: QPC of course has the same problem. I solve this by using a queue that buffers display accesses and only apply the changes to the screen image 62,5 times per seconds. Is there anything to be gained from the (very) old trick of storing the previous screen content and only writing changes? Of course that's how its done in the back buffer. You really don't want to translate the strange QL format to PC format for every pixel of the screen on every change. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Hello All, Downloaded and un-zipped the files. .jar file; double click - nothing; try the java instruction from manual; right click and open with offers Java so accept that. Lot of action from hard disk then nothing. It is Vista. Disappointing. and awfully time consuming. Bryan H ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Am 27.01.2013 um 18:34 schrieb Wolfgang Lenerz: Mainly, SMSQmulator is slow because: 1 - I'm trying to to things with Java for which is wasn't really designed (painting single pixels to a screen, low level byte,word access to variables and memory, etc). In Java you also have to shift double the amount of data around, because Java doesn't know about unsigned data types (a serious omission, IMHO) Don't know if this helps you in some way: The logic e.g. uqlx uses is to collect all the changed scan lines (i.e. areas of memory) during a screen operation and update only changed scan lines in one go after the end of the op. (That's done as a bitmap operation, then) 3 - I'm by far not the programmer Marcel is. Considering your day job and judging by the results, you're very, very good for a non-professional ;) As the java machine has a built-in garbage collector timings are going to be erratic as the whole java machine suddenly stop while it does the garbage collection. Perhaps, but I doubt it. I've yet to see such a phenomenon. Those times have long gone by - This used to be a problem in very early Java implementations. The quirk has long gone, but the myth still remains ;) Regards, Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Tobias Fröschle wrote: 3 - I'm by far not the programmer Marcel is. Considering your day job and judging by the results, you're very, very good for a non-professional ;) Outstanding even. SMSQmulator is a great piece of work. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
On 1/27/2013 11:04 AM, Bryan Horstmann wrote: Downloaded and un-zipped the files. .jar file; double click - nothing; try the java instruction from manual; right click and open with offers Java so accept that. Lot of action from hard disk then nothing. It is Vista. Brian, Open a DOS Command Window (Start, Run, CMD), then CD into the SMSQmulator directory. Run this command: java -jar SMSQmulator.jar That will have java execute the SMSQmulator.jar file, which is the main part of the emulator. If that does not work, do you have any other java applications you can test to make sure java is running right? If not, try GenJ http://genj.sourceforge.net/). It's an open source, java-based, genealogy program that I've used for a number of years. It has a .jar file. Tim Swenson ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Downloaded and un-zipped the files. .jar file; double click - nothing; try the java instruction from manual; right click and open with offers Java so accept that. Lot of action from hard disk then nothing. It is Vista. Disappointing. and awfully time consuming. Bryan H Hi Bryan, for some reason, the file association between a .jar file and java wasn't done in your system. I don't have a windows system here right now, but the jar file must be started with the -jar parameter, eg. jave -jar path to filename. DO you know how to open a command prompt under WIndows? If you, do so, and the cd into the directory where you have unzipped SMSQmulator. From there type java -jar SMSQmulator.jar. Report back any errors Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
On 27/01/2013 20:26, Marcel Kilgus wrote: Tobias Fröschle wrote: 3 - I'm by far not the programmer Marcel is. Considering your day job and judging by the results, you're very, very good for a non-professional ;) Outstanding even. SMSQmulator is a great piece of work. High praise indeed, thanks you're both too kind. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SMSQmulator
Hi Daniele, thanks for that detailed info. Do you think you could send me a small file (one line basic would be enough) with that, so that I could test it? I'm thinking of ditching my header for SFA files, and simply use yours. Does anybody on this list already have many files saved on an SFA device? Wolfgang here are the details of how Q-emuLator stores files on the native file system: QL files have a special piece of information associated with them, called the ‘QDOS file header’. The header stores such information as the file name and whether the file is an executable program. Q-emuLator stores part of the header at the beginning of files. The header is present only when it is useful, ie. only if it contains non-default information. The header has the following format: OFFSET LENGTH(bytes) CONTENT 0 18“]!QDOS File Header“ 18 1 0 (reserved) 19 1 total length_of_header, in 16 bit words 20 length_of_header*2-20 QDOS INFO The first 18 bytes are there to detect whether the header is present (ID string). The headers Q-emuLator supports can be 30 bytes or 44 bytes long (the value of the corresponding byte at offset 19 is either 15 or 22). In the first case, there are 10 bytes with the values present in bytes 4 to 13 of the 64 bytes QDOS header. In the second case the same piece of information is followed by 14 bytes containing a microdrive sector header, useful for emulating microdrive protection schemes. Additional header information (file length, name, dates) is obtained directly from the file through the host file system. Daniele ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
