Re: [ql-users] Manual for Computer One Pascal
Engstler Karsten wrote: im searching for an manual of Computer One Pascal. Unfortunately I only found a news item in QL Today that said that the guy the originally put the pascal package online http://www.westhaven.uklinux.net/qwertyb/ has begun to scan the manual and put it online as well. Perhaps somebody has saved that effort before he removed the page? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Advice
[EMAIL PROTECTED] wrote: Using QPC on a PC I use dir dos1_ to see the content but I would like to look into a folder so I try dir dos1_xx and it works but dir dos1_Program Files does not. Is there a trick or is it not possible? Use quotation marks. die dos1_program files Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Advice
[EMAIL PROTECTED] wrote: I tried dir dos1_Program Files but it does not work. Because Tony did the quotes wrong. Always enclose the whole expression. dos1_program files In DOS one usually uses c:\program files. While Tony's version might actually work there (DOS command line parsing has ceased to amaze me a long time ago), it looks damn weird. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Advice
wolfgang mühlegger wrote: dir 'dos1_progra~1' would work as well One can actually disable this feature, but on most systems it should work just fine, yes. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Advice
Tony Firshman wrote: In DOS one usually uses c:\program files. While Tony's version might actually work there (DOS command line parsing has ceased to amaze me a long time ago), it looks damn weird. Certainly does. That is precisely what the TAB complete does under XP DOS emulation. You actually mean it produces c:\program files ? Sorry, but that's hard to believe. Nonetheless I just checked NT4 SP6, 2000 SP4 and XP SP2. None of them showed this behaviour. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Help on RGB Monitor
Al Feng wrote: I'm not sure about the specific monitor you are referring to, but to use a standard RGB Monitor with the QL, one of the signals has to be inverted. No, I'm pretty sure that was a hack to get CGA monitors working. I think I had the monitor Karsten was referring to (it was definitely some Commodore), but I'm not sure I have the cable anymore. But I just took apart an RGB cable of another monitor, and there the only connected pins are actually R, G, B, H-Sync and ground. H-Sync is connected to the QL's Video-Sync (Pin 4). V-Sync is not connected, even though both the QL and the monitor feature that pin. Probably because those monitors were fixed frequency anyway (just a guess, while I can usually vouch for everything I say about software, the same is not necessarily true for hardware ;-) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Aurora SMSQ 2.99 or previous
Peter Fox wrote: I have been trying to use SMSQ 3.03 on the Aurora and I cannot get Text87 to work with it. If anyone has a copy of SMSQ 2.99 (or previous) for the Aurora that they could let me have I would be most grateful. According to the private mails you've sent me you are trying to run a Text87 version for Mode 16. Mode 16 doesn't even exist until IIRC SMSQ/E 3.02. The driver that supports Mode 16 is a commercial offering, done by me. It is *not* included in the general SMSQ/E release. There was a patched Text87 version for Aurora *QL* mode. This has nothing to do with MY patch, in fact my patch has to *undo* the Aurora QL colour patch in order to work. I have no idea where to get a Text87 version for Aurora in *QL* mode, if that's what you're really looking for, I've never been involved in that. SMSQ/E 2.99 will not help you. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Aurora SMSQ 2.99 or previous
Roy wood wrote: It has just occurred to me that he may be using a 'standard' SMSQ/E to run this. Yeah, for me it was just pretty clear that he was not actually using the high colour mode, not matter what the reason. Simple check for this: if after entering disp_colour 2 (it's BTW really 2, not 1, my mistake in not spotting this in an earlier mail from Peter) the command print disp_type still doesn't print 16, then you don't have the extended driver. He does have the colour one but I net he installed the standard one by mistake when I rebuilt his Aurora a while ago. I have been talking to him about this all week and I had always worked from the assumption he was using a colour version. Damn! It's usually always the basic things that get you :-) Actually the first thing I verify with most customers is that they are really using the software version they *think* they're using. It's almost a somewhat insulting question, but it has happened too many times that somebody got a new QPC release from me but the problem still existed because the version they actually start (usually through a link) is a different one buried somewhere else on the hard drive! Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] QPC2 v3.31
New QPC2 version is out now. Apart perhaps from the small fix in the emulation it's nothing to write home about, though: 3.31 Some cosmetic fixes in the dialogs. The browse directory dialog in the DOS device preferences now defaults to the current setting. Fixed recently introduced bug in ABCD command. It's available as usual from http://www.kilgus.net/qpc/ Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Lost messages [was Turbo]
Fabrizio Diversi wrote: BTW I am here now and I am wondering why Marcel is taking so long to release QPC 3.31, maybe he is having one of his magic moment and he is implementing fantastic new features in SMSQ/E : writing to buried windows, long file name, ..-)-) Sorry to disappoint you, but the delay is actually more related to my laziness and a new build system which has never been used to do a release before. ;-) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: R: [ql-users] Newbie with some questions... (MAC emulator)
Davide Santachiara wrote: There starts the trouble (again). I only have Macs. And even worse, I don't have some classic system anymore, and the emulator runs only with System 9... I can't even install it on my iMac G5 anymore. So this door is closed until someone ports the emulator to X. You can try Q-emuLator for MacOS written by Daniele Terdina: http://users.infoconex.com/~daniele/MacQL.html I do believe that's the one that only works with System 9. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30 and Spectrum Emulators
Davide Santachiara wrote: I am a registered user of Zm128 emulator on Ql I want to ask you if it is incompatible with QPC2 v 3.30 because I tries the simple program 10 for i=1 to 10 20 print i 30 next i Very strange, I'll have a look. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: R: [ql-users] Newbie with some questions... (MAC emulator)
Phoebus R. Dokos wrote: http://users.infoconex.com/~daniele/MacQL.html No it works with OS X (emulation of emulation but it does... at least that's my report) Well, it does need the Classic environment to run, and if you don't have that, as he wrote, it won't work. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL Stick
David Tubbs wrote: Ooops, Device is un-formatted But I was using it last night, QXL_WIN and all. Probably removed it too early without going through the proper device removal procedure. Not sure whether and how one can fix it. But a Linux machine would be my best guess, or a Live-CD like Knoppix that doesn't need installing. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Newbie with some questions...
Alexander Klock wrote: When I bought it in 1989, I was fascinated by this machine, but in this pre-internet-time I was not able to make some contacts to get some news or software. Even though in those days the German QL scene was really buzzing :-) So now, I fell somehow retro and want to make a new start. I already looked through the net and found a lot of unsorted infos, most of it too complicated for me to understand. I'm not interested in excessive hardware expansion. I just want to learn to code this machine, because I think there's a lot of things possible with the standard capabilities... What language? SuperBasic? - Is there a way to get software from the net onto microdrive cartridges, e.g. with a cable or something? This is a bit of a chicken and egg problem, it is possible using a serial lead, but the QL does not come with terminal software... though a simple basic program without much of a protocol might be sufficient for starters. On the other side you could use a PC with my QPC emulator (http://www.kilgus.net/qpc/), the demo can read files and write to the serial ports just fine. I think the max serial speed with an unmodified QL is however 9600 bps. But a disc interface really might be a more of a hassle free solution. - I found some QL-World Scans with some game reviews in it. I'm interested in collecting games for the (standard) QL, as most of them don't seem to be just conversions from other systems but QL-specific developments. Is there some source on the net for this or do I have to buy them all, the real old stuff too? Personally I consider the stuff abandonware and have not much hesitations to giving it away, but I don't really have many games for the QL. - Is anyone out there who would transfer software onto my own microdrive cartridges, if I sent them to him? I could, I guess. If the drives in the basement QL are still working ;-) - Does a normal atari-compatible joystick work with the QL? Yes, German QLs had the right connector and it was plug and play. ;-) - Is there a kind of SCART-cable available? (The TV output is so terrible...) The TV output never was particularly good, I'd always prefer a monitor. I'd be glad if someone could help me for a good start... I'm curious and want to spend some fun time with this machine - don't want to spend much money on hardware and stuff. Understandable. But nowadays it really gets difficult to bootstrap somebody with a vanilla QL because both the hardware and software has moved on quite much. All the best, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QL Stick
David Tubbs wrote: Was not removed, whole machine closed down. Closed down in the sense of crashed, died of power failure or any other fatal end of the computer session or in the sense of a regular shut down by the rules? Medion Laptop, how do you rate them Marcel, got it from Toys-R-Us, used to be sold by Aldi in Germany. Although it is heavy it has the advantage of being like a clone - no proprietary quirks like a Compac or HP et al. I'm pretty ambivalent about them. Actually they might not be bad, Aldi is supposed to be selling pretty good stuff, but all things said I'd prefer some more established brand. Though it mostly boils down to the individual model, all companies feature good and bad apples. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Newbie with some questions...
Alexander Klock wrote: You can use the QL as is, but a lot of decent software needs more memory or additional files (TK2 or SMSQ/E). I thought this SMSQ/E is an emulator or am I wrong? No, SMSQ/E is a rewritten successor of the QDOS OS with many enhancements. It runs on actual QL and Atari hardware, only one emulator (mine, QPC) is also using it as its OS. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] A4 or A5
gwicks wrote: At the moment the magazine is a .pdf file of 2.5 to 3.0Mb. Erm, how is the PDF done? By scanning the magazine or what? If that is indeed the case, how is the original magazine printed? As far as I can see each page requires space in the .pdf file for the page definition. Well, that should be 20 bytes or something, depending on the quality of the PDF generator. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] A4 or A5
gwicks wrote: Erm, how is the PDF done? By scanning the magazine or what? If that is indeed the case, how is the original magazine printed? I don't know how the magazine appears as PDF. Basically it is a series of word processing articles etc that Bruce Nicholls collates, but I don't know what software he uses. The magazine is sent to the printer as a PDF file, which I understand is the format he prefers. Just asking because 3MB sounds like a lot for a magazine like Quanta. Graphics like ads etc can of course add to it, but still. For reference, the whole QPTR manual (160 pages) fits into a 640kb PDF. As far as I can see each page requires space in the .pdf file for the page definition. Well, that should be 20 bytes or something, depending on the quality of the PDF generator. Thanks, an interesting piece of information. Basically PDFs can be very small to very large, even with the same contents and mostly same quality, it all depends on the way the PDF is generated (i.e. it can position every individual character on the page or it can be satisfied with positioning whole lines, it can use data compression or not etc). But page count is usually not a decisive factor (unless the PDF is scanned graphics, in which case the white space at top and bottom of each page can add up considerably). I did a couple of A4 mock ups for my own interest (and also as preparation for the event I was elected as chairman). I had band widths of 1.12 Mb on a 16 page A4 and 789Kb on a 14 page A4. The latter contained several photos and I reduced the quality of these too drastically so in fact that too was probably nearer 1.2 Mb, With photos this sounds reasonable, yes. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] WMAN2 program
Dilwyn Jones wrote: Programs like the one you describe use the System Palette, a method of describing pre-defined colour schemes to help provide standardised appearances for program displays. Although this existed to some extent in older pointer environments (you can see the standardised appearances or 'colourways' in QMenu menus, QPAC2 menus and so on), Actually, there was no support for colour schemes whatsoever in the PE. All programs that supported colour schemes had to do them themselves. The rest sounds fine. Cheers, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] info window colour
Sorry for being incommunicado for a while. Wolfgang Lenerz' response is exactly right. If you want a window to use the system palette colour, simply make a WM_INK/WM_PAPER call with the corresponding system palette colour. What I didn't mention was that I was writing a program to work with and without WMAN2, by having two separate sets of menus in the same program, using the appropriate set of menus depending on whether the program is used on a non-WMAN2 system or not. Why would you want to waste your time doing this? We not only went to great pains updating the old WMAN to be compatible with SMSQ/E's WMAN2, the old PE is even freeware now! Why oh why would anyone still want to support older releases instead of just supplying the newer ones if needed? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Size for QXL.win Files
John Gilpin wrote: Is there a maximum size for a QXL.win file running on QPC2 and if so, what is the maximum size allowed? Actually, I don't know what the maximum size is. I do know that QPC's access routines are currently limited to 4GB per QXL.WIN file, however. It would probably be fairly easy to extend this to 2TB, but I'm not sure how much space the QLWA format itself can handle anyway. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Easymenu menus
Dilwyn Jones wrote: Some blank info windows get converted as titles. DetectTitle% = 0 Thank you for your help. You're welcome :-) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] rom image
Dilwyn Jones wrote: base=respr(48*1024) lbytes filename,base CALL base+peek_l(base+4) At base+4 is a pointer to SBASIC extensions, but most ROMs do the BASIC initialisation themselves, I think. Therefore CALL base+peek_w(base+6) is really the correct code, but in practice it doesn't make a difference with most ROMs. SMSQ/E users can try using the EPROM_LOAD command, but that only accepts ROMs up to 16kb. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SMSQE v3.04 v3.10
[EMAIL PROTECTED] wrote: I have noticed that SMSQE v3.04 will allow such names as end_if to be used as variables or procedure names. So apparently does SMSQE v3.10. However, SMSQE v3.07 sets end_if, end_def, end_when, end_for and end_sel to END IF, END DEF, END WHEN, END FOR and END SEL. My 3.07 here doesn't do that. Also I'm not aware of any changes in this respect, even though I do usually keep an eye on all changes going into SMSQ/E for QPC. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] www.kilgus.net updated
Jeremy Taffel wrote: I think you must store up all these bits of work, keeping quiet about them and just waiting for someone to make a request, so you can blow everyone's minds by the speed of your response. ;-) Nice theory ;-) And in that case not entirely untrue, as said the .WIN file was in the works for years now, I just sometimes need a push to get finished. So what else have you up your sleeve that we don't yet know about? Hm no, sleeve's all empty now. My work here is done ;-) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] www.kilgus.net updated
Roy wood wrote: So much for Roy's response to my plea for a better demo. Thanks for the update; now to have a play.. I was just trying to protect Marcel from too many demands on him. Yes, much appreciated actually. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] WIN_FORMAT command
Derek Stewart wrote: Do I have have to type in WIN_FORMAT 1,0 to protect WIN1_ from being accidentley formatted Yes. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] www.kilgus.net updated
P Witte wrote: I cant download (error 404: Datei nicht gefunden!). Can you check whether the link is working, please? Argh, true. Try again. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Idle thoughts
Wolfgang Lenerz wrote: I've been silent for some time - most of my time was being eaten up by other (and mostly non QL related) things. Me too. Plus, I didn't want to get rude. Jeremy got a bit flamed for his suggestion to make things (QPC in this case) cheaper, even free. Actually Jeremy's argument was ok. It was my idea to sell QPC at a bargain for QL2004 and it will surely happen again. Eventually the price might drop altogether, I guess, but not yet. Regarding the price, it might appear high, but considering the invested time it already is a real bargain. It'd need to be a about 10 times as high to begin to compensate for the work put in, but this is obviously no option. By the way, you are all right that the demo QXL.WIN does not demonstrate QPC2 well enough. I have had a new one in the works for a long time (I last revised the corresponding readme file in June 2003!), but somehow never managed to make it ready for prime time. It's mostly done now, but a few more questions have to be answered first before I can make it available. A major update of my site including a QPCPrint demo version is due anyway. I don't know why Marcel charges for his software, so I can only speak for myself. Primarily I do it for fun. Secondarily unlike most people here writing software is my main and *only* income. I do occasionally sell my man power to some company here, getting more per hour than a QPC sale puts into my pockets, but that's just mercenary work, for me there's not much fun in writing a driver for some obscure Asian automation bus PCI card. On the other hand I've spend almost halve my life(!) developing QPC, I'm very connected to the project. My money needs are pretty low, so it works out so far. Soon I won't be a student anymore and after that the QL scene might have to cope with a lot less of me. But I have accomplished pretty much all of my set targets anyway, so now I'd just like to lean back and watch others pick up the ball. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Turbo v4g21
Just to see how Turbo developed I tried to compile EasyPtr's AppMan with it. I'd like to tell some of my quest in case anybody else wants to try it, too. First of all I'd like to note that whatever feature I thought it would be cool if Turbo could do this Turbo could already do, one just has to read the documentation. It's for example very convenient that all compiler settings can be specified in the BASIC program itself. It pissed me off to no end that I couldn't specify the No winds option, or the job name in Qliberator on a per-program basis. With Turbo it's all there: 100 TURBO_objfil 'ram1_appman' - name of resulting EXE file 110 TURBO_taskn 'APPMan4' - job name 120 TURBO_diags 2 130 TURBO_windo 0 - No winds 140 TURBO_objdat 32- Dataspace size 150 TURBO_buffersz 64 160 REMark %%win1_easy_app_appman_cde,4,82 170 REMark %%win1_easy_app_fapp_cde,0,4 180 REMark %%win1_easy_app_mkapp_cde,0,10 190 REMark %%win1_easy_app_qcfx001_cde,0,10 200 IF NOT(COMPILED) THEN 210 LRESPR win1_easy_app_appman_cde 220 LRESPR win1_easy_app_fapp_cde 230 LRESPR win1_easy_app_mkapp_cde 240 LRESPR win1_easy_app_qcfx001_cde 250 END IF The REMark lines will be quite familiar to QLiberator users and they work exactly the same as $$asmb. With the settings all in the basic file a simple charge , command will automatically compile and create the resulting EXE file. Another feature that I missed for example in Qliberator was support for hexadecimal values using the $ notation. I thought I should probably ask George to include support for them. Once again, after browsing the changes files I saw that Turbo already supports them... After that AppMan did already start, but when trying to access the Files menu the line 1760 MITEM#wdef1,-9,,appnum$ gave an error not found. Changing it to 1760 MITEM#wdef1,-9,0,appnum$ helped, so not much of a problem, but I've told George about it and he has fixed it in 4e21. After this the files menu opened up, I could select something, the file select menu opened up, it loaded the appendix and then booom, another problem. Turned out some variable values were really messed up. To make a very long story short: the application did simply run out of stack space on the file select call and subsequently overwrote some variables of the program. If you do compile programs for EasyPtr, make sure to crank up the stack by configuring codegen_task to a higher value (using MenuConfig). 1024 should be pretty safe, but 2048 can't do any harm either. In any case, Turbo was working correctly, tough a higher default value might be in order. After THAT I could load an appendix and... Sysmon went mad about a memory corruption. God, those are hard to track down! To make an equally long story short, Appman simply had a bug that corrupted the heap! Why it didn't show up in SBasic or in the Qliberated version I don't know, probably chance, but once again Turbo was just fine. After that there was a problem with the MINPUT function of EasyPtr. It has to do with the way Turbo handles strings (only fixed dimensioned strings which EasyPtr didn't accept) but I could easily make the EasyPtr Basic extension compatible, so that's fine then, too. Please note that this EasyPtr version has not yet been released but might be acquired if you really need it. And that really was all of it, Appman works now as fine with Turbo as it did with Qlib, so I think it's really time for you to check out Turbo, too. ;-) This was all some weeks ago, today I did a quick check of the array slicing and it seemed to work perfectly well, too! Well done. One more thing, I tried to compile a very large EasyPtr program with Turbo and got hundreds of errors. The reason being that the same variable names sometimes had different definitions, like 100 DIM a$(10,10): REMark a$ two dimensional 110 Test 120 : 130 DEFine PROCedure Test 140 LOCal a$: REMark a$ is one-dimensional 150 a$=xyz 160 PRINT a$ 170 END DEFine This will be honoured by Turbo with the error ERROR at 100: Ambiguous declaration of name. and some errors ERROR at 150: Ambiguous name used. The reason is simple, consider the extended version of this program 100 DIM a$(10,10) 110 Test 120 Test2 130 : 140 DEFine PROCedure Test 150 LOCal a$ 160 a$=xyz 170 PRINT a$ 180 Test2 190 END DEFine 200 : 210 DEFine PROCedure Test2 220 PRINT a$ 230 END DEFine I guess Turbo cannot know what code to produce for Test2. When called from line 120, a$ is two-dimensional, when called from Test, a$ is one- dimensional. SBasic handles this at runtime, but from a software engineer point of view I actually prefer the way Turbo works, because it can prevent bugs in the code. The downside is that some code probably needs to be rewritten, but usually it's sufficient to just rename some variables, so should not be that big a deal. I hope this description might help some people get a start with Turbo, I
Re: [ql-users] was... Just an idea for a new Product.....
Jeremy Taffel wrote: I've been given so much advice that my head is spinning. In one email I was advised to by QPAC2, but was then told that its the same as the pointer environment I already have. No, PE and QPAC2 are not one and the same. QPAC2 is *based* on the PE, though. As the PE is inbuilt into SMSQ/E, you don't need the ptr_gen, wman etc files there. QPAC2 itself is more a conglomerate of utilities, like a file manager, job manager etc., so one could say it's a successor of the QRAM utility. Up to now, I've assumed that all the developments in the major apps (the above, turboptr, etc ) apply, only to SMSQ/E, and to ensure compatibility with QDOS, I have continued using my old versions. Most things still run under QDOS. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Software Prices.
jms1 wrote: As Dilwyn Jones says in his article in Qtoady that TurboPtr is more flexible than EasyPtr, Well, but mostly in the sense that Assembler is more flexible than Basic. Still most people prefer to program in Basic. EasyPtr is not simply a wrapper around the PE, it actively relieves the user of the more difficult areas of the PE. For example I've seen (and worked on) the code that is responsible for managing the application windows. That are some 1000 lines of code. In any case, the heart of EasyPtr is not the basic toolkit but the EasyMenu generator for graphically designing a menu. That plus the way resources are handled (by appending them to a Basic extension and referring to them by name instead of DATA constructs and the like) is really what distinguishes EasyPtr. All that plus most people are simply set in their ways. They have been programming EasyPtr for years, know how to use it, have existing code using it and don't want to switch to anything else. Not to belittle the efforts in creating TurboPtr, I think most of George's work is much under-appreciated, but those are the reasons why I think it didn't quite take off. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote: As far as I know BP_LET changes a parameter by copying the value on the maths stack to the address at byte 4 of the parameter entry on the Name Table. I had assumed that this 4-byte pointer would be set. Instead MWDEF seems to be copying both the pointer into the name table as well as the 8-byte entry from the name table. Yes, it copies that to ensure that the name table entry is still the same (i.e. it's just used for comparison and as a safety net). Question being, is this check necessary, is there any case where just storing the variable address can corrupt memory because of it being moved or anything? I guess for Turbo the answer is a sound no, but I'm not so sure about the interpreters. It stores the address of the name table instead if the address of the variable itself because it lets BP_LET do the work (and that code is shared with a lot of other possible variants, so I'd need to extract that code path somehow and make it separate). I assume that at the time the code you quote is obeyed A3 still points to the name table entry for the channel parameter, but that A5 has been set to the address of the window definition (perhaps plus a constant). Almost, A5 points to an internal variable space, allocated as a thing (the easymenu01230123 things one can see in the thing list). Ciao, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q60 / 80
Aurélien GÉRÔME wrote: By the way, there is *NO WAY* yet to get a fast emulation of an MMU which is required by Linux. Actually, I wouldn't be so sure. Using decent JIT technology a 68k core (without MMU) with at least 200Mhz (relative to 68060) could be possible on current PCs (my guess is more like 300 to 400Mhz). I cannot believe that an MMU emulation would slow that down to 1/10th. Frankly, I just don't see any market for it, otherwise I would have tried. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q60 / 80
Phoebus R. Dokos wrote: Yes but that would be beyond the scope of QPC (to run Linux) anyway; Of course. Who would want to do that if native Linux is better supported and magnitudes faster? The JIT idea itself I've toyed with often, but I guess most people are already happy with the speed as it is. QemuFast is a remarkable achievement in this respect. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote: 100 adr = MWDEF(#ch%) 110 REPeat loop 120 ch% = 0 130 action = MCALL(#adr) 140 if ch% 0: PRINT 'Error during MCALL:'! ch%: EXIT loop ... How does line 120 indicate that ch% is the variable that MCALL is to return the error code? It doesn't, the MWDEF in line 100 does that. If I knew that I could perhaps tell what Turbo would do!! I guess you should already be fine if the MWDEF gets the variable by reference. EasyPtr will keep the reference and use it on the next error. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote: The only snag I can see is if the code for MWDEF, which has to tell whether the channel is sent by reference or value, gets it wrong for Turbo. This could happen if, for example, MWDEF assumes (wrongly) that the parameter is passed by value if the pointer to the Name List in the Name Table is -1. I imagine this is very unlikely. Oops, I confess I'm pretty new to all this, but for me it looks like actually this IS how it works: move.w 2(a6,a3.l),d0 ;set error return variable blt.s @1 ext.l d0 lsl.l #3,d0 add.l $18(a6),d0 move.l d0,error_var(a5) move.l 0(a6,d0.l),error_id1(a5) move.l 4(a6,d0.l),error_id2(a5) @1 But I can change everything. I guess the right way to do it is to check that the type of the parameter is $0203? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
P Witte wrote: But I can change everything Oh yes? ;)) Can, not will ;-) One very simple improvement that could be made to MAWDRAW would be to allow it to take an address instead of an array. The address would point to a data area with the following structure - which you will recognise as the last part of a Menu Application Window Definition: Well, MAWDRAW are 1000 lines of code that are not exactly easy to understand, I'd rather not dig too deep in there. And quite frankly, I guess nobody except you would know how to use it. Plus if one really needs it, it could probably just be done by a few POKEs, MWDEF does return the working definition after all. This would be the equivalent to MAWSETUP, the menu can then be drawn using MAWDRAW. Just speaking freely, no idea whether it really works, of course. This would allow extra flexibility when needed to produce 1) 2-dimensional lists with the exact number of elements (not rounded up as now) Rounded up? 2) Mixed object type lists, MAWDRAW can do this, can't it? 4) Turbo-compatible lists with DIY slicing, As a workaround for this, how about a command that somehow explicitly creates a header for an array that has sliced indexes? Just a thought. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote:
The latest beta test version of Turbo, v4d21, should soon be on the SQLUG
site. This one has compiled QPTR's demo_bas (after some modifications).
I'm curious, what kind of modifications? Dimensioning of strings?
I've read the readme of v4c21 and it sounds pretty promising. What
grade of compatibility do you think you'll be able to achieve?
EasyPtr has sometimes a very powerful but also very complex syntax,
e.g.
{} = alternative
[] = optional
MAWDRAW [#ch%] {,}{;}{\} num[, [array$][, xst%, yst%[, [under%]
[, [xsz%], [ysz%][, [xju%][, [yju%]]]
MAWDRAW #3,1,array$,0,0,,,16
but I think it only passes back simple integers or integer arrays in
its parameters (with MINPUT being the only exception, it alters a
given string using SB.PUTP). Could Turbo manage all this stuff?
Marcel
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
P Witte wrote: Im aware of the embedded message, but at some point I changed to using 0,82 (ie dont call the initialisation routine at all) No, this is not what's it doing: QLiberator wants 2 parameters, one for the offset of an initialisation routine that should NOT contain a call to sb.inipr and one for the procedure/function table in a format suitable for sb.inipr, so that QLiberator can link in the functions itself. The EasyPtr extensions provide 2 entry points: 0 and 4. 0 does the same initialisation that 4 does, but additionally has a call to sb.inipr so that the file can just be LRESPRed to link in the basic functions. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
P Witte wrote: Im aware of the embedded message, but at some point I changed to using 0,82 (ie dont call the initialisation routine at all) and it has apparently worked. What deos the initialisation code do? Oh dear, you're right. I didn't know 0 means do not call at all and wouldn't have expected it as it seems somewhat of a bad design decision. A quick look shows that the EasyPtr init routine just seems to check whether the THING system is available, so you might well get away with not calling the initialisation. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Dilwyn Jones wrote: The compiler directive is correct, or at least as per what is in ptrmen_cde ($$asmb=filename,4,82) I just had a look and saw that ptrmen is broken, I've had 2 lines in the wrong order. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Roy wood wrote: Shall we annoy Marcel and tell him he's working on QLiberator next ;-)) I think you would be taking your life in your hands You bet! Besides, with all the work George put into Turbo it might start being a real alternative. I've never been a fan of Turbo but I think he's really moving something. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
P Witte wrote: The compiler directive is correct, or at least as per what is in ptrmen_cde ($$asmb=filename,4,82) If the filename above should happen to be ptrmen_cde the correct parameters are $$asmb=filename,0,82 No, 4,82 is the correct one. Address 4 is the entry point without sb_inipr, 0 is the one with it. Qliberator wants the one without it. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Knoware
P Witte wrote: A.. 2005/03/27 Addition and Update a.. D-Miner - Minesweeper clone for high-end SMSQ/E systems Has nobody any comment on this? I thought this thing is freakishly impressive and is really pushing the boundaries on what can be done with the PE. Anybody tried? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Linux QL Emu
Michael Berger wrote: Looks like things have changed - thanks to Ubuntu Linux I haven't been too much around in Windows over the last weeks. The (almost) only thing I miss a lot is QPC2. If you can get access to either Cedega (ex-WineX) or CrossOver Office you could try QPC2 there. They are able to run QPC2 to a degree, normal Wine is catching up but still wasn't quite there last time I had a look. All my linux boxes here are head-less, so I wasn't able to test the emulation much myself. I remember there begin problems with the keyboard mapping, but that might be due to the VNC connection I've used. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC on a Stick
Dilwyn Jones wrote: Anyone got relative paths to work properly for DOS devices? I hope not, they are explicitly forbidden. Not sure about the reason but I probably had a good one. IIRC Ken said it was dot forwardslash for current directory and dot dot forwardslash for root or next step up. No, forward slashes are never used on DOS/Windows. .\ is current directory, but it should be redundant as everything defaults to the current directory anyway. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Re: QPC-On-a-Stick
Ken Bain wrote: It should be possible to have different QPC setups on the same drive by having each in its own copy of your QPC2 folder (suitably renamed) In theory for different setups you just need different smsqe.bin files. For example a smsqe-xyz.bin and then starting QPC using the -os smsqe-xyz.bin option. To avoid using the command line one could create a shortcut that contains the options. But different directories is probably more straight forward to use for most people. If different boot configurations is the only thing you need: determining on which PC you run can be done using the QPC_NETNAME$ function. Just using different configurations can be done using the QPC_CMDLINE$ function and the corresponding command line parameter -cmdline xyz (again can be done using a shortcut to the QPC2.EXE). But can you share files between multiple QCPs? I haven't tried this yet. 3 cases: - Multiple QPCs point to the same QXL.WIN, but don't run at the same time: no problem - Multiple QPCs point to the same QXL.WIN and run at the same time, but do not access the .WIN files at the same time: works if both are told to share the file using WIN_REMV x,1 (only needed if file is local, not if it's on a network share). - Multiple QPCs point to the same QXL.WIN, run at the same time and both want to access files at the same time: works if the QXL.WIN file is write protected. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] GCC on QDOS
Phoebus R. Dokos wrote: Not entirely :-) However your recollection is correct. Thierry, converted gcc with assistance from Dave Walker, Richard Zidlicky and (then) Jonathan Hudson to compile QL programs under Linux/Unix. So it is a cross compiler. It usually achieves a speed up of 20%+ over regular C68 programs due to the better math library. But it doesn't seem to be particularly stable, I've never got it to produce working code on my (back then) Linux 2.6.9/gcc 3.3.4 system. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Rich Mellor wrote: You cannot create an application sub-window menu with MAWDRAW or MAWSETUP which only contains one item in the menu. I need example for that, as simple as possible. MITEM does not allow you to redraw the loose item - it should accept the , or \ separator in line with the other commands to force it to redraw the item. At the moment it ignores the separator. Hmm, in the sources there is a note: ;14.04.97 MITEM nachzeichnen OK (nachzeichen = redraw) So perhaps it is fixed but didn't get properly released. Is this an error? I have a note that WRES does not release MCALL - therefore any attempt to use MCALL after the WRES command will result in an IN USE error If it is a bug I need a small example. Doesn't sound very high priority, though. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
P Witte wrote: 1) Manually added scaling flags are removed on re-loading a menu definition and may even crash the program. 2) System sprites cant be shown and other hicolour sprites are problematic. 3) Application window scroll bar attributes cannot be set or changed without specifying a pre-set menu too. Part of the problem may be with the toolkit which seems to ignore or overwrite attributes added by hand later. 4) When changing the sprite origen of a, if the pointer sprite is moved outside the window EasyMen crashes. OK, noted. But basically I was only going to address high colour problems, though if time permits and the job is simple enough I might look into some others. No promises though. A great stop-gap improvement to this program might be to allow a menu definition to be saved as an assembler file directly from the program (EasyAsm doesnt work in GD2) No, that is much too difficult. But EasySource can easily be made to be GD2 compliant. IIRC all that's needed is to change one branch instruction. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Dilwyn Jones wrote: 1. I can't change the colour of the border or main window unless I cover the main window with an info window. If Easyptr allowed, say, MWINDOW #0,0 for the main outline it might then be possible to change the main menu colour. Use system palette colours in the menu and define a private system palette (somewhat contradictory name, but every job can have its own system palette) before drawing the menu. No flashing, no poking in the window definition. MSETUP #0,mymenu:rem don't show original on screen REMark change colours before originals are drawn MCOLOUR #0,menu_element_number,colour_number MDRAW #0 : REM draw in new colours it might be possible for me to do what I want, whichis to allow users to specify colours in a config block and set these at runtime. Yes, easily possible using the mentioned method. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
François Van Emelen wrote: Some functions/procedures need improvement. For example 'RPXL%' (returns the pixel colour at a given position) only works in QL colours. This is an SMSQ/E limitation. About TurboPtr: the demo George showed us in Eindhoven(QL2004) didn't convince me to abandon EasyMenu. Yes, I think the Menu generator is essential. But perhaps the toolkit could be used together with EasyMenu? I have no idea. the following line doesn't display the high colour sprites at all if they aren't 'glued' to a 4/8 colour sprite. Right, the sprite identifiers are hard coded into MITEM, pretty easy to change this, though. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Dilwyn Jones wrote: I'm not sure I can enter system palette colours in standard Easyptr can I? No, I thought you had the newer one, haven't really kept track of it. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
wolfgang mühlegger wrote: but why did he do it then? Just for fun. and why did he give it to beta-testers then? There were no beta testers. I just gave it to some people and said look, mom, without hands. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
gwicks wrote: At this stage there was some doubt over the legal position, which in itself led to a lot of misunderstanding because no one had thought of asking Albin. I understand that he is quite happy for the program to be upgraded. Yes, he basically said that anything I choose to do is fine with him. When I last saw the upgraded version all it did was allow you to use GD2 colours directly, but nothing else. For example, if you use high resolution sprites you have to load these into EasyMenu every time you make changes to a menu. Right. It was able to load the raw sprites, because then it just took that junk of memory, but when embedded into a menu it tried to make a copy of it and of course completely failed. This can be a bit of a pain in the neck if you have a lot of sprites in a program. (And we should remember that the new sprite technology means that we should be wanting to include more sprites and more sophisticated sprites in our programs.) Actually that was part of the problem. The sprite definition became so complex that it was a pain to support it for EasyMenu. As said, I have done most code now (which should ultimatively be part of SMSQ/E so others in this situation don't have to do it again), but it is not debugged. I am not sure what changes have been made to the upgraded EasyPtr since I last saw it, but I can understand if Marcel says it is not yet ready for release. We have come to expect a high standard from Marcel, and thus we should respect his opinion on this and not pressure him to release an incomplete product. That's exactly the point. At least without working sprite support it was just a nice toy, not fit for anything really. With it, it looks somewhat better. But I do have high standards for myself, especially if ever any money would change hands for it. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] RESET in SMSQE
David Gilham wrote: A solution more than likely lies in the reset code on SMSQE which seems implicitly to assume a vector base register of zero. Very good point. The VBR doesn't seem to be set anywhere in the initialisation code, although it should. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] RESET in SMSQE
jms1 wrote: I have just tried reset on SMSQE 3.07 on my QXL. On a clean machine, it works. However if I run my boot program and then reset it crashes. So there must be something wrong with reset. Good observation, but jumping too fast to the conclusion. Problems in SMSQ/E are almost never this straight forward. For example an extension in your boot could have redefined RESET. Or overwritten the RESET code. Or 1000 more reasons. You cannot blaim RESET for that. As I happen to know that the RESET procedure is clean, I find this theory much more believable. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SERNET revisited
François Van Emelen wrote: Here they are: SBAD%, In my sources it's called SNET_BAD% and returns the number of bad packets. SRES%, In current versions this is called SNET_RETRIES% and returns the number of retries done. SNET_C%, This is probably SNET_CONNECT% now, which returns whether it is connected or not. SNET_N%. No idea. Probably SNET_STATION%, which returns the current station number. There's also SNET_TEST%(X) which returns whether station X is up or not. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] RESET in SMSQE
[EMAIL PROTECTED] wrote: The code for the keyword RESET in SMSQE seems to close all channels and then perform the assembler instruction RESET. Hmm no, in my sources it doesn't (smsq_sbas_procs_reset_asm/ smsq_smsq_reset_asm). It branches to the same place CTRL+ALT+SHIFT+TAB jumps to. Why has RESET not been reprogrammed? Does anyone use it? Do you have another tool that replaces the SMSQ/E RESET command? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] SERNET revisited
François Van Emelen wrote: Thanks for the info, but SNET_BAD%,SNET_RETRIES%, SNET_CONNECT%,SNET_STATION%, SNET_TEST%(X) are not present in my version (2.25). I suppose you are referring to a more recent one, probably available with the next version of SMSQE? The version in my disc is 3.01. However, I have no idea about the history of it, whether it's fit for release, whether it has been released or anything else about it. I am in NO way affiliated with SerNet. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] ProForma Filter
Phoebus Dokos wrote: Actually it is my belief that it should be part of the OS (as a nul device like most OSes have) Erm, what's wrong with SMSQ/E's NUL device? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Testing testing 123 - am I working again ?
Norman Dunbar wrote: Now I've got my reply - but not Dilwyn's. Something amiss here ! Patience. All mails will arrive eventually. At least I didn't miss a single one so far. It could be that according to the web archive, he sent it at 08:33 this morning :o) I suspect Bruce's server is requiring a date/time adjustment. No, think globally. The archive server is located in the US, for it the message DID arrive at 08:33. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Virus [OT]
P Witte wrote: So why did I do it? Well, broadband has finally arrived here in this godforsaken nook of England, (although it will be a few months before I get connected, so please dont mail me all your holiday snaps just yet). Continuing to ride the Internet bare backed would probably be irresponsible, so Ive swallowed my pride and conformed. Right, but usually I suggest the use of a hardware router. The address translation they do protect the machines behind them very well, usually better than the so called personal firewalls, because those can be compromised. Yet despite the dire warnings and the shaking of wise and moral heads, my first complete system scan using all the tools available showed that there was nothing amiss with my system. Yes, it did throw up a couple of viruses (mainly from friends on this list! (Thanks guys)) More modern viruses counterfeit the sender with one of the names in the address book. I know some viruses get send using my e-mail address by 3rd parties, because I occasionally get the bounces, and frankly this pisses me off to no end. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: R: [ql-users] QPC2 v3.30
Davide Santachiara wrote: Sorry if I am a bit late but I went a few days in Barcelona and now I am back with some three hundred message to read... Ah, I already wondered what took you so long :-) The speed increase on my Intel Centrino 1,6 Mhz notebook is impressive. Here are the figures: Now imagine how fast it'd be in a 1,6 GigaHz notebook instead of just 1,6 Mhz ;-) Pre 3.2x QPC2 QSI: 2460 (24,6 times wrt Gold Card) 3.22 QPC2 QSI: 2780 3.30 QPC2 QSI: 3618 +47% wrt pre v3.22 QPC2 I already expected that this processor will gain the most, but this is pretty huge. Very cool. Thanks for the values, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] network installation of QPC2
Phoebus Dokos wrote: The one thing that I can tell you is that at least my QPC will not share a QXL.WIN file with another QPC (or uQLx - Q-emuLator for that matter). Although QPC will start normally, the second another application tries to use the QXL.WIN file, the first QPC will not have access to the QXL.WIN file until the sharing application ceases to operate. Do a WIN_REMV x, x being the drive number, on the PC that hosts the .WIN file (it is automatically done if QPC detects that the .WIN is on a remote server). In short that means that you cannot have one shared qxl.win across the network. Wrong. They can't access it at the same time (i.e. after OPEN#3,win1_boot WIN1 is blocked for the other machine until you do a CLOSE#3), but apart from that they can share it just fine. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] network installation of QPC2
Phoebus Dokos wrote: Hmmm I did not know that WIN_REMV applied to that situation as well (Is it in the QPC manual?) Hey, you expect me to know my manuals? You're the user, you should have read them and be able to tell whether it's in there or not ;-) But actually, it is: When a drive is declared removable, the .WIN file is closed after all SMSQ/E files on it are closed. This can also be used to allow a single .WIN file to be shared over a network. (Files on a remote computer are automatically set to be removable). As long as one instance of QPC has open files on the drive, no other instance can access it. Perhaps this is too technical for most people to follow, I have no clue, but at least it's documented. Hmm then as I recently discovered this only applies if you share the same qxl.win file between QPC and a non QPC emulator... I don't think any other emulator can do this, yes. In any case though, I thought that Dilwyn wanted to run QPC directly from the server (but locally) and all of the copies running would access the one QXL.WIN file. How would that work? Quite normally, I guess. But there will be problems when a) two users trying to start QPC at the same instant (one will get a Cannot open SMSQE.BIN or something like that). b) two users trying to access the .WIN file at the same time. Ffibys Mealrc ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] network installation of QPC2
[EMAIL PROTECTED] wrote: As long as nobody opens a channel to write to it, Doesn't matter whether you open the file for writing or only for reading. The drive will be blocked. But I just remember one other solution. If you set the .WIN file attribute to read only in Windows then the QPCs will open the file in a different mode. In this mode two or more QPCs can actually have the file opened *at the same time* because they can be sure that no other application will be able to corrupt the cached FAT data. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] My Documents
[EMAIL PROTECTED] wrote: Urgently need help (preferably off list) on this one. My Documents on my computer at work usually points to \\server\users\ (can't remember rest fo it from memory) For reasons best known to itself it's decided to put itself onto drive C on this PC, so of course ALL company documents are suddenly lost without trace. I'd like to redirect the My Documents folder back to its original server location but can find no info how to do this. Windows help is meaningless gibberish going on about Group Policy and such things without actually explaining how or where to go about it. Depends on how your network works. In bigger installation the computer is likely to be joined in a Domain, where the Domain administrator controls that stuff. With normal Workstations like mine at home the location can be set using TweakUI (free download from Microsoft). Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] My Documents
Tony Firshman wrote: M$ did something called PC Power Tools sometime ago. Which may help you get control over the PC settings. Those are called Power Toys and the mentioned TweakUI is one of those. The Tools are only what the ordinary enthusiast may expect. I emailed Dilwyn about using regedit. The My Documents location is not stored in the registry (actually you may probably find the string there, but that is only a copy to make some badly written applications happy. The longer story, told by one of the Win95 and incidentally TweakUI developers is here if anybody cares: http://weblogs.asp.net/oldnewthing/archive/2003/11/03/55532.aspx ). Enough of this Windows stuff, however. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Email in SBASIC
- Aucun - wrote: I have not tested it so I do not know if it would work here. But one question: how can you PRINT to a channel open for input? Misleading name, the TCP device has other definitions for the various open keys and make the connection corresponds to open input channel on other devices (I don't quite like that, but I haven't designed it). Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] smsq gold
[EMAIL PROTECTED] wrote: Thanks, will try this when I get home tonight. Do you mind if I put this on my website, to go with the SMSQ/E Modules article? I'm sure people would find a 'module lister' useful. Actually that's where the code is from: http://dilwynjones.topcities.com/qldocs/smsqmodu.zip Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] smsq gold
P Witte wrote: Only way of telling for sure is the file length - maybe Roy can remind us all of the file length for the two versions... Another way of detecting whether you have the colour version is by noting the difference in the price... lol. That's what I originally thought, too ;-) Anyway here's a BASIC program that lists the modules in an SMSQ/E file. In case of the High Colour Aurora driver there should be a module surprisingly named SMSQ GOLD 8 bit CON Driver. 100 REMark - scan bootloader file 110 DIM version$(4): version$(0)=4 120 OPEN #0,CON: CLS: BORDER 1,4 130 height = 17 140 INPUT 'SMSQ file';f$ 150 OPEN_IN #3,f$ 160 fln = FLEN(#3) 170 LGET #3\fln-$18+$4,mod_ptr : REMark - get length of host module 180 LGET #3\fln-$18+$14,bln: REMark - length of bootloader file 190 IF bln: mod_ptr = mod_ptr + fln - bln 200 FOR i=1 to 210 LGET #3\(mod_ptr),mbase,mlength 220 IF NOT mbase: EXIT : REMark - end of file 230 IF NOT i mod height: INPUT a$; : REMark - pause at screen full 240 WGET#3\(mod_ptr+$16),name_rel: REMark - relative pointer to name 250 GET#3\(mod_ptr+$16+name_rel),name$ : REMark - fetch module name 260 IF LEN (name$)1: BGET#3,a : REMark - odd length name is padded 270 BGET #3,version$(1 TO 4): REMark - get version, if any 280 PRINT HEX$(mlength,24) !! version$ ! name$ 290 mod_ptr = mod_ptr + mbase + mlength 300 END FOR i 310 CLOSE #3 320 INPUT a$ Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30
Rich Mellor wrote: Thanks Marcel - the only thing is that the Help function does not work - some files missing?? Yes, the help files... Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30
Rich Mellor wrote: Well yes I guessed that - we need to include them in the package My package is a quick demonstration on how to set it up so that it runs. Nothing more, nothing less. Anybody is welcome to enhance, it of course. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30
Roy wood wrote: Not sure I understand the point here. If you have two machines running QPC2 and connected by ethernet why not just map the drives so they have a letter and then use that letter as one of the QXL.WIN files ? I have done it like this for ages. I believe Marcel has even made it possible for two machines to access the same file although I have not tried it. No, it can't. UDPNet, on the other hand, could do this. Plus, it is a native solution and is basically cross-plattform. If Q40 had IP support, it could be used to sync QPC and Q40. OTOH the more I know about the SERNet/UDPNet code, the less I like it. It probably should be rewritten from scratch (and use TCP instead of UDP). But this is not exactly a minor task. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Level 2 Drivers
Roy wood wrote: Perhaps that was the root of the problem you went to the bank for in the first case?? Oak A, I think it's time to leaf it out now, buddy. Don't tangle with the pun meister! Roy Wood, putting the pun in PUNishment since 19xx ;-) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Old games
Tarquin Mills wrote: I have been thinking about a virtual microdrive for SMSQ/E, as way of making SMSQ/E more compatible with old software, this would solve the above problem. In other words an image filing system. I think software that does need this would probably not run anyway. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] smsq gold
Dilwyn Jones wrote: Is the same smsq-gold v3.06 used for 256 colour on Aurora or is there a separate version for Aurora? DISP_TYPE will change resolution on the Aurora/SGC (a MinisQL) but DISP_COLOUR 2 is ignored Then you probably don't use a version that includes my driver. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Old games
Dilwyn Jones wrote: Use RESPR instead of ALCHP for now, until I know if it's OK to send you a TK2. I think QemuLator and QPC2 can load a Toolkit 2 ROM image, although I can't remember the commands needed from memory. Why oh why should anybody want to load a TK2 image on QPC2? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Email in SBASIC
Dent wrote: It should work on uQLx. soQL doesn't have a TCP_ device as jet. The device driver itself would be quite simple as its not a directory device. But without an underlying operating system as on an emulator it's difficult to see how to get the connection made while the device driver is in supervisor mode and soQLengin (daemon) can't run. Connections on QPC and uQLx are done asynchronously, so it's actually the *next* call to the I/O interface that will block until the connection is done (and blocking just means is it done yet? No? Then back to SMSQ/E). Whether you poll the host OS or your daemon at that point shouldn't really matter, I guess. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30
Rich Mellor wrote: Thanks Marcel - guess the biggest comment which is missing from this announcement is the fact that the full IP support means that QPC2 can at last access the internet directly Ah yes, of course. I can see that not everybody might understand it this way. - just a shame Lynx is the only internet browser we have. Yes, links at least would be much better. But nobody around that can do any porting anymore, it seems. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30
Wolfgang Uhlig wrote: It's different here: 132 times faster for QPC 3.20 101 times faster for QPC 3.30 WHA?? Never heard a case where it got slower. Did the benchs take place under *exactly* the same conditions? This includes colour mode, full screen or not and of course whether other Windows applications were hogging CPU time during the test. In any case TEST909 is too fast to really have much meaning anymore. I think time has come to design a new benchmark for the QL. Something the old black box will have to run hours. Yes, that would be nice. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QPC2 v3.30
wolfgang mühlegger wrote: to me the most exiting thing has not been mentioned by a word: marcel has modified sernet to udpnet. so ql-networking is MUCH faster now and easier too - you do not have to deal with baud rates, cables ... Right, totally forgot about this. I will release it when I come around to it. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Clavier 1.08
Wolfgang Lenerz wrote: www.scp-paulet-lenerz.com/14mljkl24/wolf/download/ Just wanted to say that I think that Clavier is a mightily cool application with which everybody should be able to make a keyboard layout that suits himself. And as it's not an everyday application I will forgive you that it still features the old colour schemes ;-) This said, if anybody has done a new keyboard layout for his region and wants it to be incorporated into SMSQ/E we can probably do that. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Clavier 1.08
Wolfgang Lenerz wrote: Just wanted to say that I think that Clavier is a mightily cool application with which everybody should be able to make a keyboard layout that suits himself. And as it's not an everyday application I will forgive you that it still features the old colour schemes ;-) Thanks,... I think. :-) Redoing this to use new colours will be amajor effort, I'm not surewhether that will be necessary. Nah, probably not. This said, if anybody has done a new keyboard layout for his region and wants it to be incorporated into SMSQ/E we can probably do that. Actually, pretty soon now, we miught have a probem with SMSQ/E for the Qx0, at least in ROM. The Rom is only 256 KB long, and we're pretty near that limit now. Then this has to be dealt with sooner or later anyway, don't you think? Not by me, of course, QPC is long past 256 kb ;- In this case a ZIP file with a library of finished designs might be useful enough, too, of course. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] QPC2 v3.30
After months of development and beta testing I'm proud to announce that QPC2 version 3.30 officially went live. As usual the update is free for all users of QPC2 version 3. Get it from http://www.kilgus.net/qpc/ Main changes are a much faster emulation core and uQLx compatible TCP/IP functionality. Furthermore there are some bug fixes and smaller enhancements. It comes complete with SMSQ/E v3.09. Full changes list: 3.30 Full IP (TCP/UDP) support! Mostly compatible to uQLx TCP/IP interface. 3 little words: Fastest! QPC! Ever! Up to 40% faster than 3.20! Partially re-designed QPC-SMSQ/E interface. Old SMSQ/E version are therefore completely incompatible! Yet another fix in the PAR dialog. Hope that was it now. Raised number of PAR ports to 8. Still only 4 are configurable through the config dialog though, power users with more than 4 printers need to use PAR_SETPRINTER or directly configure the SMSQE.BIN file. Ignores all keys while one of the Windows keys is pressed. New command QPC_WINDOWSIZE x,y to set the size of the QPC window. New commands x=PAR_GETFILTER(port) and PAR_SETFILTER port,x to read/write the use printer filter flag of a PAR port. Fixed some repaint problems (black screen). Does not crash anymore when sound is set to disabled. Fixed problem with volume control sliders. Fixed bug in 8-bit accelerated screen routines. Fixed problem with screen accesses that crossed the VRAM border. *** Needs at least SMSQ/E V3.09 Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Disk Mate 5
Rich Mellor wrote: My guess Marcel is that you have another toolkit loaded which redefines SORT. Of course I did try it with a clean system, too. Maybe you should try loading the extensions_cde AFTER you have loaded all your boot files. I even did it with no boot file at all. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Pointer Environment and TK II
Tony Tebby wrote: Maybe that's out of copyright by now or maybe I'm not dead yet. Ah, uncertainty. Maybe somebody should open the box and have a look then? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Pointer Environment and TK II
Rich Mellor wrote: Maybe that's out of copyright by now or maybe I'm not dead yet. Ah, uncertainty. Maybe somebody should open the box and have a look then? No wonder the QL user list has been so busy this year if we are starting to get contributions from beyond the grave... Well, the boxes I have referred to usually only contain cats. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Disk Mate 5
Pål Monstad wrote: Nice to hear from you! I'm sorry, but I do no longer have the source code for DM5, so I guess it's impossible to make DM5 work with extended colours. I anyone is interested, please put the program into Public Domain. In case you're curious, the result looks like this (with my personal theme colours, look on other systems will differ as colours and even the sprites at the top are not hard wired anymore): http://www.kilgus.net/images/dm5.png Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Disk Mate 5
Pål Monstad wrote: I must say I'm impressed! Thanks. Fortunately you did use EasyMenu, which made things fairly easy. I have not seen DM5 for 8-10 years now, and it looks much better than I can remember. I don't think I have a working version around. Is it possible to mail me DM5? I'd like to try it in the QPC demo. I'll send you a version of my WMAN demo disc (that I've been working on for years but never find the time to finish) with it included, so it's ready to run. It comes with 2 different colour schemes, too. BTW, I do always get a QLib error when starting DM5, but it seems like it can be ignored. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Disk Mate 5
James Hunkins wrote: That was almost too easy. I did design that stuff, of course it is easy :-) Something tells me you may be getting more requests :) Actually I'm starting to learn how to just ignore people ;-) At the rate it is currently going I will be able to celebrate my 1th sent email (of those that are still in my archive, all the BBS years not included) within the next few months. Unbelievable. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Disk Mate 5
James Hunkins wrote: At the rate it is currently going I will be able to celebrate my 1th sent email (of those that are still in my archive, all the BBS years not included) within the next few months. Unbelievable. Where I come from, we would call you an email wimp - only 1? Well, you know, unlike yours those are not just forwarded joke mails. :- And of course it would be much faster to just answer sucks to be you to people with problems instead of spending hours to help them. When I think back to all those mails from a certain James H. for example... ;-) Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Disk Mate 5
Rich Mellor wrote: BTW, I do always get a QLib error when starting DM5, but it seems like it can be ignored. Wonder if that is more to do with the version of the runtimes being used Would be helpful to know which error is reported... Q_ERR_ON illegal parameter Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Disk Mate 5
Roy wood wrote: BTW, I do always get a QLib error when starting DM5, but it seems like it can be ignored. You do need to load the extensions. They are included in the files I sent to you. Of course without the extension it won't start at all... Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Disk Mate 5
Rich Mellor wrote: Now, all the keywords for QLib appear towards the end IIRC, so might be worth casting an eye over the list - if you want to email me a copy of DM5 (send it to the AOL address) I will have a look and see if I can spot it. I will send off what I have to both you and Dilwyn, thus ending my short involvement with DiskMate. But if you do find a solution please let me know, just out of curiosity. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Disk Mate 5
Pål Monstad wrote: Nice to hear from you! I'm sorry, but I do no longer have the source code for DM5, so I guess it's impossible to make DM5 work with extended colours. Actually it's not that much of a problem as you use the standard QPAC2 window scheme. For that I have developed tools that can do most of the conversion automatically on existing binaries. After that only a few manual fixups needed to also make use of the new sprites. If anybody can send me the latest release I see what I can do. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] A bit of a drag
[EMAIL PROTECTED] wrote: It appears under SMSQE v3.07 and probably under v3.04 too Official versions or self-compiled? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
