[ql-users] Change of email / new domain name
Hi all, from today onwards I will be using a new email account for everything. this will be phoebus@dokos-grlala.net (Remove the lala before you send any mail ;-) Also update the following links: Provisional QL page is moving from http://www.redoak.net/QL/proforma.html to http://www.dokos-gr.net/~phoebus/ Dilwyn's mirror will be moving sometime within the week to: http://www.dokos-gr.net/~dj/ The main page will be at: http://www.dokos-gr.net/ Thank you all Phoebus
[ql-users] SuperQ Board
Anybody knows what kind of mouse a Sandy Super Q-Board takes? (Also do you know if it works with ICE?) Phoebus
Re: [ql-users] Frank Davis - accident
To get back on topic, it was John Rish that sort of took over the QL and Z88 business from Frank. John started doing Z88 repairs for Frank and then got more into straight sales. I have not heard much from him in a year or two. It's probably safe to say that there are no active US QL dealers in the US. I think Jack Boatwright in Oregon still has a bunch of stuff that he picked up from RMG (a long time Sinclair dealer in the US). Tim Swenson Tim, do you have any info on Jack Boatwright? Phoebus
Re: [ql-users] Hove Workshop (OT)
At 12:33 ìì 24/2/2002 +, you wrote: I used to work for Snowdon Mountain Railway. The company that made their disastrous Mountain Railcar unit went bust, many of the employees now produce sprinter type trains made (I think) by a company called Alstom. Some of their new trains are out of action more than in action on the lines near here, seems anytime you put a computer near a train it's a recipe for disaster. Alstom produces the TGV indeed. (And parts for the Acela too). I wouldn't know about British commissioned high speed railways, however TGV trains are largely computer controlled and never had significant problems (apart from strikes that is ;-))) Actually Acela components that break down most often are the US made power transfer systems (I wonder why didn't they stick with the French tried and proved methods, and power req's and they wanted something different on that part...) (That's extremely weird considering the phrase If it works don't touch it probably originated in the US... and at least it's an alltime favourite here ;-) and the Bombardier / Canadian made TGV modified suspension (TGV uses suspension that's unlike any other train suspension since it is actually located between the cars and not under them -Makes for a really smooth ride-) I wonder what they gonna do with the Maglev they plan on building now... (They need to install a QL so it will run properly... Phew! back on topic) Phoebus -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] compact flash
At 10:20 ìì 24/2/2002 +, you wrote: Advice wanted Have a compact flash adaptor, no problems under SMSQ/E on my Q40, using a 32mb Verbatim card, bought another 32mb maxell card today, cannot partion it using MKpart, but works OK in my Kodak camera, does anyone know if there is a problem with some brands? If it's a CF+ adapter (USB enabled) it's possible there are problems -see www.redoak.net/QL/proforma.html Why don't you try to see it under Linux first to make sure... (Another trick would also be to use the CF as slave (or master) and try a different partition no. Phoebus
Re: [ql-users] compact flash and compatibility
At 04:47 ìì 24/2/2002 -0500, you wrote: At 10:20 ìì 24/2/2002 +, you wrote: Advice wanted Have a compact flash adaptor, no problems under SMSQ/E on my Q40, using a 32mb Verbatim card, bought another 32mb maxell card today, cannot partion it using MKpart, but works OK in my Kodak camera, does anyone know if there is a problem with some brands? If it's a CF+ adapter (USB enabled) it's possible there are problems -see www.redoak.net/QL/proforma.html Why don't you try to see it under Linux first to make sure... (Another trick would also be to use the CF as slave (or master) and try a different partition no. Phoebus Oh I am sorry, that should read CF+ CARD and not adapter... In general, certainly some cards will not work with the adapters (for example Lexar cards) as this happens on PCs as well... Unfortunately complete testing of ALL the cards with the entire range of available QL hardware is not only impossible it is also extremely expensive and that's why I rely on users for more information. If you do not manage to use the card I will have to add them up on the page as a precaution... So far we know the following: Cards that work: (Plain cards non CF+) Verbatim, SanDisk PQI (Ritek) Hitachi Kodak Lexar (non USB enabled) Iomega IBM/Iomega Microdrives Fuji Pentax (Hitachi) Cards that do not work All USB-Enabled (CF+) Lexar cards
Re: [ql-users] Frank Davis - accident
At 06:38 ìì 24/2/2002 -0500, you wrote: They are about only able to worry about each other at this time. They are being closely monitored. I too said they should have remained in the hospital a little longer. Well that's the byproduct of HMOs. They kick you out of the hospital the first chance they get :-( The system sucks and people remain crippled because of them money-hungry care specialists as they call them (All knowing accountants and if so..) Nonetheless best of luck to Frank... I hope he gets well soon. Phoebus
Re: [ql-users] Frank Davis - accident
At 11:44 ìì 24/2/2002 +, you wrote: On Sun, 24 Feb 2002 at 18:38:30, you wrote: (ref: [EMAIL PROTECTED]) I spent part of a day up in Peru with Frank, Both are walking SLOWLY and tenderly but are able to get around a little. But nothing strenious at all. They do have some family up that way and they are there every day as far as I know. I guess they both owe their lives to seat belts (and air bags?) Most likely... although cars/vans/SUV's etc. Stateside have no relation whatsoever with their European counterparts... A lot more dangerous out here than even in Greece (of all places) or France (Hehe worse drivers than even the Greeks!) (Everybody that drove in the beltway (Washington D.C.) knows exactly what I mean) (Ohio and Western PA are not better, not by a longshot... at least a major pile-up in the highway (motorway) every week or so... Phoebus
Re: [ql-users] Frank Davis - accident
At 11:53 ìì 24/2/2002 +, you wrote: On Sun, 24 Feb 2002, Tony Firshman wrote: I guess they both owe their lives to seat belts (and air bags?) I drive a minivan - a Dodge Grand Caravan. These minivans seat 7 with ease, 9 at a pinch. I bought mine after being t-boned by an SUV while driving an Olds - in the US, about half the vehicles on the road are SUVs, trucks or minivans. I bought it because it was high up, so most of the action would be below head height, and because it puts distance between you and the accident - front and rear. I beg to differ Dave, It is now proven that SUVs trucks and minivans are a lot more dangerous to their passengers than regular cars... (Institute of highway safety says it not me ;-) So I am very happy with my Toyota Yaris (Echo they call it in the US) and its 42 mpg ;-) Phoebus
Re: [ql-users] Frank Davis - accident
At 01:44 ðì 25/2/2002 +, you wrote: On Sun, 24 Feb 2002, Phoebus R. Dokos wrote: I beg to differ Dave, It is now proven that SUVs trucks and minivans are a lot more dangerous to their passengers than regular cars... (Institute of highway safety says it not me ;-) So I am very happy with my Toyota Yaris (Echo they call it in the US) and its 42 mpg ;-) My chosen subject: accident investigation. That is a serious mis-statement of the statistics used by governments world-wide to disuade people from driving larger vehicles. Usually, the person killed is the driver of the lighter vehicle. SUVs and minivans are involved in accidents where there is a higher risk of a fatality, but that risk is biased towards the driver of the lighter vehicle. You're far more likely to survive in a minivan. Two vehicles hit each other head on. One weighs 1000 lbs and one weighs 2000 lbs. Assuming no energy absorption by the chassis... The total velocity is 60mph, and the total weight is 3000 lbs. The 2000 lb vehicle will slow from 30 mph to 10 mph. The 1000 lb vehicle will slow from 30 mph to -10 mph. The relative acceleration for the 1000 lb vehicle is twice that of the 2000 lb vehicle. (Granted, this ignores differences in restraint systems, energy absorption systems and etc) I studied accident investigation - I wanted to be an air accident investigator. Dave True, from a physics standpoint the collision favors the larger vehicle from a standpoint of deforming... However newer vehicles have controlled deforming zones. Don't also underestimate inertia on a bigger vehicle (with a greater mass)... Phoebus
Re: [ql-users] Parallax Scrolling IS possible
At 01:33 ìì 23/2/2002 +0100, you wrote: On 22 Feb 2002, at 19:27, Phoebus R. Dokos wrote: Yes you are right. I zipped it directly on dos3_ I'll try it again using win1_ instead Yes, you can't do that, I've always meant to tell Marcel this, but I always forgot (sorry Marcel). Zip onto RAM and then copy onto the dos device.. ' I am afraid is a little more complicated than that. For example the easyptr example Marcel sent me and which I recompressed and sent to you after I compiled it was done the same way and the zip file worked just fine. Phoebus However I'll keep it in mind until I get QPC2 v.3.x (I trust Marcel that he'll fix it (he always does :-))) wolfgang - www.wlenerz.com
Re: [ql-users] Parallax Scrolling IS possible (and Wolfgang is the Oracle of Delphi)
At 01:33 ìì 23/2/2002 +0100, you wrote: On 23 Feb 2002, at 0:28, Marcel Kilgus wrote: Phoebus R. Dokos wrote: 5. New version of commands by Wolfgang Lenerz (using QPTR this time). A LOT faster and smoother... I've cleaned up the commands a bit and sent them to Phoebus today. There is now NPAN (New Pan - uses the PE save restore part window blocks) and NPAN_S ( for_slow) rolls each line individually. One thing I will say and I am not joking! Wolfgang MUST possess ESP , be a mind reader or some other Paranormal ability, else it cannot explain the fact that as I was going to bed last night I was thinking of a way to make nice Simulated LED score numbers... Sure enough I open up the computer, read the mail and here it is included in the NPAN commands!... Ils sont fous ces Français! (Misspelled most probably too ;-) but you get the Idea :-)) THANKS WOLFGANG! Phoebus
[ql-users] Parallax Scrolling IS possible
Hi All, following my previous email, I now (thanks to Wolfgang and Marcel) have five versions of my High-Colour parallax scrolling demo. 1. Is using TurboTK and exists as interpreted and Turbo-Compiled 2. Is using the EXCELLENT PAN_L and PAN_R extensions kindly (and extremely fast) written by Wolfgang Lenerz (included in the Zip file) (again interpreted and Turbo compiled) 3. Is using EasyPTR (as converted by Marcel -Particularly suited for QPC 2 users (as uses the accelerated QPC2 PE routines) - Extremely smooth) - With PAN_L and PAN_R compatible syntax 4. Slightly modified No. 3 again by Marcel with more optimisations (Non PAN_L and PAN_R compatible) - Both No. 3 and 4 also show the achieved frame rate (Again interpreted and Turbo compiled) 5. New version of commands by Wolfgang Lenerz (using QPTR this time). A LOT faster and smoother... All these have been tested with QPC 2 and as of this afternoon, they will include also Mode 33 screens for testing on Q40/60 machines. (One question that I've been meaning to ask for quite awhile now... Does Qx0 support 800 x 600 or only 2:! Resolutions? (512 x 256, 1024 x 512, 800 x 400 etc...???) In any case and at least on QPC2 despite the problems that were discussed in length on this list by Nasta, Marcel and others this proves that at least four levels of parallax scrolling can be achieved even on slow QPC2 machines and up to 16 (As I succeeded VERY smoothly) on very fast ones with not very annoying flickering/frame shearing effects... The results will be posted on my provisional (won't be provisional for very long as I am finally getting my own 1Gb + Web space complete with Telnet ;-) later on this month) page at http://www.redoak.net/QL/proforma.html. For anyone that asked me to test the previous version, please get it from there after 9 o'clock GMT. :-) Thanks, Phoebus P.S. As soon as I get my SGC back, I will test the same for the Aurora (which despite Nasta's objections ;-) will be using direct addressing of the screen memory and enabling of the 256 colour mode by accessing the registers ;- ... Hey after all its a demo...
Re: [ql-users] Parallax Scrolling IS possible
At 04:08 ìì 22/2/2002 +0100, you wrote: Phoebus R. Dokos makes some magical things to make me read } } (One question that I've been meaning to ask for quite awhile now... Does } Qx0 support 800 x 600 or only 2:! Resolutions? (512 x 256, 1024 x 512, 800 } x 400 etc...???) Q40 'only' has: - 512x256 mode 4 - 512x256 mode 8 (classical 256x256 pixels) - 512x256 mode 33 (PE sprite mode 4 and mode (256 colours) are displayed if no mode 33 definition found) - 1024x512 mode 33 (ditto) That's what I thought too :-) Alright, need to get back to work updating the listings and scr files :-) Phoebus
Re: [ql-users] Parallax Scrolling IS possible
At 04:08 ìì 22/2/2002 +0100, you wrote: Phoebus R. Dokos makes some magical things to make me read } } (One question that I've been meaning to ask for quite awhile now... Does } Qx0 support 800 x 600 or only 2:! Resolutions? (512 x 256, 1024 x 512, 800 } x 400 etc...???) Q40 'only' has: - 512x256 mode 4 - 512x256 mode 8 (classical 256x256 pixels) - 512x256 mode 33 (PE sprite mode 4 and mode (256 colours) are displayed if no mode 33 definition found) - 1024x512 mode 33 (ditto) Oh and by the way... 256 colours are only used for sprites correct (under PE)? There's no mode 256 (you know what I mean) on the Q40 (8 bits per pixel) right? Phoebus
Re: [ql-users] Parallax Scrolling IS possible
At 08:56 ìì 22/2/2002 +, you wrote: In An interesting co-operation of software writers ... well done to you all. The kudos go all to Wolfgang, Marcel and the Turbo Team not me (I just had the idea and made the draft and the graphics :-) BTW: Under QPC2 at Athlon 850 now, and 512x384 @ 16bit Marcel's framerate tester (Easyptr version) gives a... (hold on to your hats) 167 fps INTERPRETED! (No flickering as far as I can tell (Okay I am half blind :-) Phoebus
[ql-users] To owners of 486 based QXLs (Exchange pls)
Hi all, if anyone having a QXL that's based inside a 486 DX needs an upgrade and btw has a broken QL (with preferably working membrane) and case in good condition I could exchange it for a Kingston 5x86-133 upgrade (turns your 486 into a Pentium and I get a QL case to house my Aurora ... :-) Phoebus
Re: [ql-users] OT: Re: PIC/SCR Compression
At 10:41 ðì 22/2/2002 +, you wrote: ZN writes: Why not just use iow.xtop? It simply works as a referee. You can still write to the screen any way you please. AFAIK you cannot poke cotrol registers of the hardware to change into modes that the OS does not support yet. Oh, ok. But wouldnt that just require a new screen driver in parallel with the existing one? Years ago I thought about doing something similar to implement vectored Keep on talking ;-) (The word fonts always draws my attention :-) fonts and other facilities. But perhaps thats a different cuppa altogether. Per (Out of his depth)
Re: [ql-users] Hove Workshop
At 11:37 ìì 22/2/2002 +0100, you wrote: Maybe Paris in October? Definitely not! In the eighties I tried to get a bed on the express between Paris and London. After half an hour of charades with the sleeper attendant I had to give up. It turned out that the magic word was 'couchette'. Like Doctor Foster, I 'never went there again'. ;(( I used to enjoy the ZX-fairs in London, though. Those were heady days! Per With Eurostar I managed to travel to QL2000 from Paris and return in 1 day. No need for couchette. You mean 1 day your total trip in France and the Tunnel because from what I hear the TGV drops to 5 km/h (well okay I exaggerate a tad!) after it surfaces in Britain ;-) hehe Phoebus
Re: [ql-users] Parallax Scrolling IS possible
At 12:28 ðì 23/2/2002 +0100, you wrote: Phoebus R. Dokos wrote: 5. New version of commands by Wolfgang Lenerz (using QPTR this time). A LOT faster and smoother... Unfortunately I can't download this one. Correct because it's not up yet... (My daughter is sick and I am back and forth to look over her... but it will be up later tonight) however your first version is there (parallaxeptr.zip) and actually is a little changed to start with the 512x384 screen and correctly define the panned areas (included are remarks on where to set the variables for the 800x600 version) (screens in testpic.zip) (Compiled with Turbo 4.14 gives an ASTOUNDING 192 fps (Maybe the code can't cope!) :-) (One question that I've been meaning to ask for quite awhile now... Does Qx0 support 800 x 600 or only 2:! Resolutions? (512 x 256, 1024 x 512, 800 x 400 etc...???) To answer your other mail: no, no 256 colour mode. 1024x512x16 is the only high colour (and the only high res) mode. Yes I kinda figured that one. The 256 colours therefore apply only to the sprite definition right? Phoebus
Re: [ql-users] Parallax Scrolling IS possible
At 12:28 ðì 23/2/2002 +0100, you wrote: Oh btw: If you have some other kind of windows setup adjust accordingly the INIT routine and the PAN_L PAN_R Phoebus
Re: [ql-users] Parallax Scrolling IS possible
At 01:04 ðì 23/2/2002 +0100, you wrote: Phoebus R. Dokos wrote: however your first version is there (parallaxeptr.zip) ...but the ZIP file seems to be corrupt ;-)' Corrupt? Let's see... I'll send you a notice... BBIAF
Re: [ql-users] Parallax Scrolling IS possible
At 01:30 ðì 23/2/2002 +0100, you wrote: Phoebus R. Dokos wrote: Yes you are right. I zipped it directly on dos3_ I'll try it again using win1_ instead There's a little bug in the DOS device iob.smul routine which will be fixed in the next release (3.02, hope to have it ready before Hove). Might have something to do with this. Marcel Now you tell me :-) Be right back then :-) Phoebus
Re: [ql-users] Parallax Scrolling IS possible
At 01:30 ðì 23/2/2002 +0100, you wrote: Phoebus R. Dokos wrote: Yes you are right. I zipped it directly on dos3_ I'll try it again using win1_ instead There's a little bug in the DOS device iob.smul routine which will be fixed in the next release (3.02, hope to have it ready before Hove). Might have something to do with this. Marcel It's okay now :-) Phoebus
Re: [ql-users] Lost email addresses
At 09:09 ìì 20/2/2002 +, you wrote: Paul Holmgren [EMAIL PROTECTED] I know for a fact that Paul Holmgren's address is valid so probably something is wrong with your smtp maybe? Phoebus
Re: [ql-users] Lost email addresses
At 09:49 ìì 20/2/2002 +, you wrote: On Wed, 20 Feb 2002 at 16:25:05, you wrote: (ref: [EMAIL PROTECTED]) At 09:09 ìì 20/2/2002 +, you wrote: Paul Holmgren [EMAIL PROTECTED] I know for a fact that Paul Holmgren's address is valid so probably something is wrong with your smtp maybe? POP (8-)# Well you know what I meant :-) I am dazed right now thanks to Wolfgang's ASM rendition of my parallax scrolling code :- (So far 4 levels of parallax scrolling). THANKS Wolfgang and YES IT CAN BE DONE ! (Even looks better on my wife's Celeron 433 - No frame shear that is) OK - I will add Paul back in. Mind you I think he bounced last time too.
Re: [ql-users] Hove Workshop
At 11:23 ìì 20/2/2002 +, you wrote: Any shows in Europe after the US show and before the end of June Well say yes! Phoebus
Re: PIC/SCR Compression (Was:Re: [ql-users] DISP_COLOUR)
At 04:33 ìì 19/2/2002 +0100, you wrote: Phoebus R. Dokos wrote: Well some preliminary tests I did through Basic using the Memory Copy facility of Turbo seem to work fine... (No flickering that is up to 48 x 48 sprites - above that hmmm okay ;-) I suspect though that through strict assembler that would disappear too - UNLESS of course the absence of flickering has something to do with my fast PC where I run QPC2). Well, there is just no way to avoid flickering. On fast machines the possibility that flicker appears gets smaller but it's never zero. Well at least I couldn't see it. It's logical that it exists but I didn't see it. Maybe a 256 colour mode would be even more suitable. (It's possible with direct access in Aurora but your compatibility goes out the Window) Is that because of the way the screen is organized/refreshed, because of SMS or what? I suspect that you could probably fix that but then it wouldn't be compatible with anything else... Phoebus Marcel
Re: [ql-users] Re: sprites
At 06:41 ìì 19/2/2002 +0100, you wrote: Well some preliminary tests I did through Basic using the Memory Copy facility of Turbo seem to work fine... (No flickering that is up to 48 x 48 sprites - above that hmmm okay ;-) I suspect though that through strict assembler that would disappear too - UNLESS of course the absence of flickering has something to do with my fast PC where I run QPC2). Well, there is just no way to avoid flickering. On fast machines the possibility that flicker appears gets smaller but it's never zero. Oh yes there is. The trick is not to restore the screen, save and write the sprite at the new position. You have to be more intelligent and shift data in your buffer, restoring what is uncovered and saving what is newly covered. More difficult to write, but always gives good results, independent of execution speed. Yes exactly what I was referring to. The calculations involved won't be TOO demanding for small sprites and the area that is to be shifted could be manipulated. Another possibility is to form some kind of caching in the beginning of the process e.g. for x sprites that move on certain directions you generate ALL possible occurences well in advance (it is possible since the sprite positions are limited to the grid you have). This would definately hold a LOT of memory, but it involves (usually) one operation the write-write (next position, previous position) only instead of read-write, compute, write -read. Phoebus I am pretty sure I wrote something like that for The Painter (long, long ago). Believe it or not I have NEVER seen the Painter (the only Painter I've seen was a VERY addictive game that I used to have on Microdrive which my daughter destroyed and don't have it anywhere else :-~~( Phoebus
Re: [ql-users] Re: sprites
At 02:30 ìì 19/2/2002 -0500, you wrote: At 08:12 ìì 19/2/2002 +0100, you wrote: 100 SIZE = SCR_XLIM*SCR_YLIM*2 110 LENGTH% = SCR_XLIM * 2 120 MAX_SCREEN = SCR_BASE + SIZE 130 buffer_norm = ALLOCATION (SIZE) 140 buffer_rev = ALLOCATION (SIZE) 150 FOR I=0 TO SIZE STEP LENGTH% : REMark Read Pixel line 300 MOVE_MEMORY SCR_BASE+I TO buffer_rev+SIZE-I , LENGTH% : REMark Store Pixel Line Finish to Start 320 END FOR I 330 MOVE_MEMORY SCR_BASE TO buffer_norm, SIZE: REMark Store Full (unreversed) screen 340 FOR f=1 TO 100 350 MOVE_MEMORY buffer_norm TO SCR_BASE, SIZE: REMark Copy The unreversed screen to the screen memory 350 MOVE_MEMORY buffer_rev TO SCR_BASE, SIZE: REMark Copy The reversed screen to the screen memory 360 END FOR f 370 DEALLOCATE buffer_rev 380 DEALLOCATE buffer_norm When compiling don't forget to use a huge buffer. I didn't want to experiment so I put Object Buffer 1024K and Turbo Buffer 1024K as well (It handles them extremely well btw) I also compiled with Fast Phoebus
Re: [ql-users] Re: sprites
Of course, the main problem using MOVE_MEMORY is that it cannot provide a way to XOR memory contents therefore making it impossible to have sprites with transparency. That could be overcome of course using TSPRT from the TurboPTR but that's a non elegant solution, which brings us back to our original problem of moving whole blocks of memory and prioritising. Movement priority is not exactly a necessity but for multi-plane scrolling for example it would be. (eg a moving backgroung (say sky) and a plane moving in an opposite direction) I might have to contact the current developers of Turbo_TK to see if we could update it a tad :-) (Still believe that two are the best toolkits on the QL, Turbo TK and DIY - TK-II IMHO is QDOS capabilities left out due to lack of time) Phoebus
[ql-users] Sprites - Animation and Graphics
Another problem presented is the PAN and SCROLL Commands which do not allow part of the physical screen to be panned or scrolled and only a window or cursor line (which can be pretty damn annoying (and slow) if you ask me... Phoebus
Re: [ql-users] Sprites - Animation and Graphics
At 08:59 ìì 19/2/2002 +, you wrote: Phoebus R. Dokos wrote: Another problem presented is the PAN and SCROLL Commands which do not allow part of the physical screen to be panned or scrolled and only a window or cursor line (which can be pretty damn annoying (and slow) if you ask me... If you set up a window as part of the physical screen, then PAN SCROLL will, shurely; do a OPEN#ps_chan,scr, then just keep doing a WINDOW#ps_chan,area to Pan/scroll : PAN/SCROLL#ps_chan - or am I just missing summat here...I nose, you wanna do this in a single command. I tried that but doesn't work right at least not all the time... The thing is that you PAN (or scroll) and then have to move contents from a memory area to fill the gap. Well it doesn't work exactly right. Additionally and regarding the use of a single scroll (or pan) command, it would take more than one command anyway as things are: 1. You scroll 2. You see which part has scrolled and copy that to the place of the space left by pan(or scroll), then increment a scroll counter, so you'll know where to begin. 3. Return to 1. In any case that can be solved without too much memory waste if your scrolling area is kept to a minimum and you use a lot of repeating patterns (a la Hyperdrive -BTW anybody has that? My MDV died on that too :-((( ) which you alternate using a seemingly random pattern (eg. clouds moving on the sky). Continuous scrolling though is really tough to implement and be at least somewhat believable. I just finished a test for which instead of using PAN/MOVE I use Memory_MOVE throughout a strip of a 100 pixels by 1600 pixels so I get fluid motion. The problem is that because this is severly fragmented (Line at a time and you have to pick and chose from the screen memory) it is VE slow. (Compiled its a little better though) Phoebus
Re: PIC/SCR Compression (Was:Re: [ql-users] DISP_COLOUR)
At 02:08 ðì 20/2/2002 +, you wrote: On Tue, 19 Feb 2002, Marcel Kilgus wrote: Well, there is just no way to avoid flickering. On fast machines the possibility that flicker appears gets smaller but it's never zero. I slightly disagree. Not much, just a little bit. If you know how long it takes to carry out task X, and that you can carry out task X a certain amount of times between each frame being read out for display, simply make the program aware of that interrupt, and carry out the task right after the frame has been drawn, confident of finishing it before the next interrupt. If there's too much activity to redraw in the time available, drop the lower priority redraws. Well something like that can be done on the original QL as both Nasta and Marcel explained. Additionally don't forget that the vanilla QL has two Screen memory areas (SCR0 and SCR1) (Both of them usable with Lau's /TFS Minerva ) and Auroras have 3 (The two standard plus the hi-res one so definately you could do some tricks there) The thing is (I repeat) that there's no legal way to do things like that and that's where toolkits or a QL equivalent of Mac's Quickdraw should come in... (You hear that Nasta? Put it in the pipeline for Aurora II). On other architectures it's easy to have two video buffers, and alternate between them - I don't know how easy it is to move the start of screen memory on the QL and derivitives (on the vanilla QL it's prolly impossible) but hey, no problem - we'll find a way ;) See above. Phoebus Dave ql.spodmail.com
Re: [ql-users] Re: PIC/SCR Compression Sprites
At 09:41 ðì 19/2/2002 -0800, you wrote: With large sprites you can reduce flicker significantly by combining the background redraw and sprite data in memory and write the lot to screen in one go. This eliminates the problem of writing to screen memory twice where the old and new sprite positions overlap. Cheers Malcolm That's the idea anyway isn't it? Suppose we have one big sprite plus it's mask. 1. We grab the screen memory to be occupied during the next redraw. 2. We combine the sprite data and the copied memory using the mask 3. The result is written directly to the screen. 4. We then copyback the screen memory for the previous movement. and so on... The problem is that all these have to be provided as an extension to the OS else it's slow. (My quick example previously on the list could be at least 30% faster if the extensions were already there instead of combining a couple of TK facilities and compile the lot (I am sure Turbo cannot have code templates for everything in Turbo!) Phoebus
[ql-users] OT: Re: PIC/SCR Compression
At 03:31 ðì 20/2/2002 +0100, you wrote: Dave wrote: If you know how long it takes to carry out task X, and that you can carry out task X a certain amount of times between each frame being read out for display, simply make the program aware of that interrupt, and carry out the task right after the frame has been drawn, confident of finishing it before the next interrupt. No, the point is: there is no suitable interrupt. On other architectures it's easy to have two video buffers, and alternate between them - I don't know how easy it is to move the start of screen memory on the QL and derivitives (on the vanilla QL it's prolly impossible) but hey, no problem - we'll find a way ;) Double buffering works quite well on the original hardware (as the (IIRC) KAOS games proved). However, all other platforms don't have a second video buffer (when QPC did still run with Minerva I did actually emulate the second screen, but I removed that for SMSQ/E). Marcel I see you are still UP! Presumably working on QPC v. 5 with Sound, Sprites, Nice CLI and a decent filesystem? Hee Hee Phoebus
Re: PIC/SCR Compression (Was:Re: [ql-users] DISP_COLOUR)
At 10:22 ìì 19/2/2002 -0500, you wrote: Well, there is just no way to avoid flickering. On fast machines the possibility that flicker appears gets smaller but it's never zero. I slightly disagree. Not much, just a little bit. simply make the program aware of that interrupt... No interrupt. Well, actually, yes - only on original QL. And two screen areas to do double buffering. (SCR0 and SCR1) and Auroras have 3 Actually, they don't. They only have the same two. The third area is really a collective area which holds SCR0, SCR1 and the rest of the bitmap up to 1024x960 in mode 4. In it, SCR0 and SCR1 are actually side by side at the top! I originally thought of using the screen flip bit to implement swapping of the two screen halves (top and bottom) in the Aurora high-res mode. That way, any MODE 4 or 8 resolution below 480 vertical could become two screens but I disabled that option in the production version, because it does not have much use unless it does something for 256 and 16 colors, and it doesn't - in those two modes the screen would be limited to 240 vertically, and there is no such mode on the QL. In theory, this could actually be extended to 256 and the flip function could be reintroduced but it would hardly be usefull without a retrace interrupt. My bad... however that's what happens when you DON'T HAVE THE MANUL (hehehe get the hint ';-))) (You hear that Nasta? Put it in the pipeline for Aurora II). It's already there. Along with on-fly 24 to 16 bit color conversion, and maybe some other goodies. With masking out the excessive bits I presume??? BTW: Which bit organization will you maintain? QPC or Qx0 style (or PC style?) (Or something else?) I don't know how easy it is to move the start of screen memory on the QL and derivitives (on the vanilla QL it's prolly impossible) but hey, no problem - we'll find a way ;) Actually, it is ONLY possible on the original and Aurora (and possibly Q40/60) when emulating original QL mode, but you only have a choice between $2 and $28000. By the looks of it, Aurora II will get 4M of video RAM so a movable screen start address for multiple buffers could be a benefit. Still, do not expect it to be moved completely freely, but we'll see. Well how about some extra logic (kinda of a graphics co-pro) to allow for 3D and other goodies (Hey it's not in production yet and I am allowed to dream am I not? :-))) Phoebus P.S. Nasta I will be sending you an email soon re: the hot-swap adapters
[ql-users] Sprites Animation Scrolling etc
I've been doing some tests and frame shearing occurs mostly during panning situations (logical as more calculations are needed). Using interpreted S*Basic this can be annoying unless the background colours you are using match and you find the golden rule between how many pixels you scroll at a time and your machine's speed. The same thing compiled with turbo is a lot faster even non noticeable at times Phoebus
Re: PIC/SCR Compression (Was:Re: [ql-users] DISP_COLOUR)
At 06:49 ìì 18/2/2002 +0100, you wrote: Phoebus R. Dokos wrote: Well, just think of QXL user ! at most 8 Megs. You are right of course. In any case hidden refresh a-la PEX/PICE would solve most problems Solve the problem of memory consumption? How? (at least for the thing I wanna do... -sprites-) Well, where exactly is your problem? I don't see any relation to memory constraints or PEX. Oh you misunderstood me... What I meant is that you won't have to move the ENTIRE screen memory, only a part at a time. And that would be the area of the sprites :-) (Which is by default smaller due to their size) Phoebus
Re: PIC/SCR Compression (Was:Re: [ql-users] DISP_COLOUR)
At 12:57 ìì 18/2/2002 -0500, you wrote: At 06:49 ìì 18/2/2002 +0100, you wrote: Phoebus R. Dokos wrote: Well, just think of QXL user ! at most 8 Megs. You are right of course. In any case hidden refresh a-la PEX/PICE would solve most problems Solve the problem of memory consumption? How? (at least for the thing I wanna do... -sprites-) Well, where exactly is your problem? I don't see any relation to memory constraints or PEX. And also for PEX I was referring to the animation flicker that might be experienced... Sorry for all the confusion, I had a VERY LONG day so far... Phoebus
Re: [ql-users] Things (was Super Sprite Generator 4.0)
At 06:04 ìì 18/2/2002 +, you wrote: That's why I no mention it NormaN... Could we bribe him somehow??? :-) Women, booze, a 68090 processor... HE MUST HAVE A PRICE ;-) (heehee) BTW, an IT chappie by the name of N.Dunbar is due (from Newcastle) at work on fridaY...no relative I suppose (sorry dont know what the N. stands for)? Probably N(otTheOneOnTheList). Dunbar ;-)
Re: [ql-users] IDE switch
At 09:44 ìì 18/2/2002 +, you wrote: Id like to connect both a CD-ROM and a CF-reader to my Q60 (in addition to the main hard disk) - but not necessarily both at the same time. However, I dont like having my beautiful machine lying around with half its guts hanging out so I can easily swap things around when i need to. 1) Would it be possible to use an IDE cable with one master and two parallel slave connectors and an (externally mounted) switch to switch the power between the one device or the other (at switch-on time), to make it do what Im trying to achieve? 2) Can anyone on this list make up such a cable and switch for me? Per Per, There is a device called the Trios (check it out at www.tigerdirect.com) that allows up to 3 IDE devices to be connected on the same place Phoebus
Re: PIC/SCR Compression (Was:Re: [ql-users] DISP_COLOUR)
At 11:11 ìì 18/2/2002 +0100, you wrote: Phoebus R. Dokos wrote: And also for PEX I was referring to the animation flicker that might be experienced... This doesn't make any difference (in fact it's more likely that it makes things worse as the block size is likely to increase). Sooner or later you have to copy the block to screen and then the flicker can occur. Well some preliminary tests I did through Basic using the Memory Copy facility of Turbo seem to work fine... (No flickering that is up to 48 x 48 sprites - above that hmmm okay ;-) I suspect though that through strict assembler that would disappear too - UNLESS of course the absence of flickering has something to do with my fast PC where I run QPC2). Phoebus
Re: [ql-users] Re: PIC/SCR Compression Sprites
At 07:45 ðì 19/2/2002 +0100, you wrote: Marcel Kilgus makes some magical things to make me read } Phoebus R. Dokos wrote: } So what I see is writing some sort of toolkit (a-la SSG) which can do this } in high-colour (and more)... for example clever background redrawing of the } screen on the anticipated movement of the sprite, } } This I don't understand. When doing sprites you only have to save and } redraw the part that is directly under the sprite. Why do you want to } predict where the sprite is moving to? Because he is taking the 'amiga/commodore' approach of game with sprite: he want the system to handle the graphic and the collision detection as well as (de-)synchronisation of the movements, thus leaving the game program with very little thing to do: managing the score and life counter, changing the level display,. Well I wouldn't exactly call the logic of the movements or the controls very little (especially in Shoot-em-up games) But essentially you are right, it's exactly what I want to to do. IMHO, it's not the right approach. He should make his game without sprite, using instead 'Letter' and detecting collision in memory, not on the screen. Once the 'low-level graphic' works, he could replace it with all the fancy sprites he wants. In the mean time, he would have learned that he need to have the moving objects in memory, but also the full background, but not as a monolithic part, rather like an assembled puzzle. Thus moving a sprite is resumed to: draw the background where the sprite is (erasing the sprite), perform movement calculation, draw the sprite, wait for some event/time (or do something else somewhere else), do it again! What you say doesn't negate what I want to do. Indeed I do have the version that I want made character based and of course I detect collision in memory not on screen. Detecting the collision on screen is first of all extremely difficult whenever thousands of colours are involved and very time consuming. I separate the screen memory (well a mockup of the memory) in a grid sized accordingly to the resolution used by the game and the maximum sprite size (so for example for a res of 800 x 600 and 48x48 sprites it's a grid of 16*12 (unless finer movement is desired). All checks are made in that grid. Additionally, yes I do know that and actually it's not that slow not even in basic. What slows the calculation down is the conversion of a linear data stream to places in the screen memory according to lines (and those calculations take a long time in basic) Problems unrelated to not having the sprite managed by a dedicated ship are: - The hero moves according to input stroke, unless input provide only a change in the direction of movement (the 'always-moving' type of pacman vs the 'one touch=one move' type of some other games). - The bad guys usually move in a kind of continuous ways, at least it's not like a chess game (bad guys wait for hero to move, then move themself, and wait again). So the management of the bad guys must be interlaced with the scanning of the input for the hero move. - collision between hero and bad guys: can happen when hero move, when bad guy move or when both move at the same time. Using letters to illustrate: ...HB... : hero(H) is just on the left of the bad guy(B) If hero move right, H B are on the same cell, collision. If bad guy move left, H B are on the same cell, collision if hero move right and bad guy move left, we end up with: ...BH...but a collision really occurs in the 'game logic'. This last case is the most difficult to detect. If hero move right and bad guy move right (at the same time), there should not be any collision (unless the hero is too quick !). - To add fun, the speed of the hero and the bad guy might be different, thus collision detection should use a finer grid and each object occupy more than one cell at the same time in this grid. Anyway, reading the screen to detect collision is just a bad approach, because it means that you are adding contraints to the graphical representation of your objects. It was the easy way with machine like spectrum and other, but it gives really bad habits and empeachs adaptation of the engine for other graphics. True but see what I say above. All these are already done, but I am afraid you misunderstood me too... I seem to have a talent in being misunderstood lately... Phoebus
Re: [ql-users] Turbo TK v3.32 and OT
At 05:33 ìì 15/2/2002 +, you wrote: If you only knew how little needed to be done... Was there any doubt??? (Yes we suck up to you Dear Sir Mighty-Magnificent-QLT Editor-and-Commander-In-Chief-Of-All-the-United-QL-Forces-and-expert- to-all-things-S*Basic Lord(of the Rings and other things) Dilwyn Jones :P~~~ (Yuck that's drool) ) Uhh, what are you after, Phoebus??? Oh nothing just practicing in case I do need something ;-)) Hehe Phoebus
[ql-users] Super Sprite Generator 4.0
Well I had this program for ages and I never even tried it Nasta is right, it doesn't run with anything other than the original QL screen addresses which makes me wonder if QPC2_v3 could run it right. (Screen at $2) It doesn't appear to mess up anything else and I suspect that animations run in the memory space of the original screen. The thing is that QPC doesn't hang! (Also it needs TurboTK instead of the extend_code as most other DP apps which leads me to believe it was originally written in Turbo Compiled S*Basic) so the question is now : Who wrote it? If I could get my hands on the original code :-) It is amazing though, very smooth animation and exactly what I want to do, you can even switch apps and the sprites keep on going (Just the way I want :-) Could it be written by SNG? Phoebus
Re: [ql-users] Super Sprite Generator 4.0
At 04:50 ìì 16/2/2002 +, you wrote: I'm sure I have a sprite generator though that uses hi-res, from Theirry ? no No the Sprite Editor (sprted) is from Jerome actually (and it's extremely good although there's no manual. ) My problem is with the movement though, how to make sprite movements independent of the action... Especially if you use S*Basic complex collision detection can make sprite movement erratic... Phoebus
Re: [ql-users] Sprite movement and relative info.
At 08:00 ìì 15/2/2002 +, you wrote: Norman Dunbar wrote: I have a funny feeling that Digital Precision dod a sprite editor/manager system a long time ago. I can't remember the name though - sorry. there is a slight possibility that it started with SUPER Super Sprite Generator rings a bell ( with a picture of ET on bike ?) all the best - Bill The thing is that I cannot find ANY info on how to move sprites around the screen... I am sure that there was an article SOMEWHERE but I don't seem to find it. IIRC Sprite Movement capability is included with SMS but what about QDOS? HE!!! :-) Phoebus
Re: [ql-users] Super Sprite Generator 4.0
At 09:22 ìì 16/2/2002 +, you wrote: Phoebus R. Dokos wrote: Well I had this program for ages and I never even tried it Nasta is right, it doesn't run with anything other than the original QL screen addresses which makes me wonder if QPC2_v3 could run it right. (Screen at $2) It doesn't appear to mess up anything else and I suspect that animations run in the memory space of the original screen. The thing is that QPC doesn't hang! (Also it needs TurboTK instead of the extend_code as most other DP apps which leads me to believe it was originally written in Turbo Compiled S*Basic) xtra_code contains SUPERCHARGE extensions (SET_PRIORITY, REMOVE_TASK, LIST_TASKS, END_CMD, DEVICE_STATUS, FREE_MEMORY) which are (presumeably) used by the Supercharged DESIGN and CONSTRUCT. Which is subset of Turbo IIRC so works either way :-) so the question is now : Who wrote it? Looking at sprite_code (off DP disk 9!) it contains R.Woodhouse 1986 right at the end. Oh I see... If I could get my hands on the original code :-) I think you'll find that all the code is prob assembler within sprite_code to add the extra procs: SPRITE, SSGON, SSGINIT, SSGSWAP, SSGFILE, SSGMODE, and FNs: SSGEDGE, SSGHIT, SSGEDGE%, SSGHIT%. Given an hour or 8.358 I'm sure I could generate a (tidyish) source for sprite_code (wonderful inventions disassemblers - try IDIS, also on DP disk 9). I was trying to avoid that... It is amazing though, very smooth animation and exactly what I want to do, you can even switch apps and the sprites keep on going (Just the way I want :-) Could it be written by SNG? R.Woodhouse mefinx...funny, I was at school with a R.Woodhouse; wonder if it was same bloke. Phoebus Try also a look at the manual (also on DP disk 9) SSG_DOC. Yes I checked it out but only mentions the procedures nothing regarding where its written at etc.. Or am I just tired from the drive back to Llundain from Glasgow (flat out at 62.5 mph) and have totally misread the problem? Not totally, I am just trying to avoid to reinvent the wheel... but I am afraid I'll have to... at least with a Thing solution I'll be able to use pipes as well to supply the sprite animator with the paths of the sprites... :-) And best of all it would be reusable... :-) Phoebus
[ql-users] Amstrad emailer
Did anybody see the ZX Spectrum games featured in the new Amstrad emailer phone? I thought they didn't have the copyright anymore for ZX technology? Or did they? Phoebus Hehe though the GOOD Empire Strikes back... The wheel is turning eventually :-)
Re: [ql-users] Sprite movement and relative info.
At 08:02 ìì 15/2/2002 +, you wrote: [EMAIL PROTECTED] wrote: I think you're right - was it called Eye-Q? Nope that was a graphics prog, remember the fancy lenslock do dah ??? The lenslock wasn't there any more when I bought the complete collection, right before DP went out of business All the best - Bill
[ql-users] Sprite movement and relative info.
Hi all, does anyone have any sources or tutorial in any form (C, Turbo/S*Basic or Assembly) for independent (or not) Sprite movement? Re: independent sprite movement... Did anybody do it with Basic? I thought of a method involving a Thing that would govern the movements of sprites without interrupting the main program (which provides control) kinda like a sprite server but it seems to me a little complicated. A simpler and more elegant solution must exist Any help? Phoebus
PIC/SCR Compression (Was:Re: [ql-users] DISP_COLOUR)
At 08:04 ðì 13/2/2002 +0100, you wrote: Marcel Kilgus makes some magical things to make me read } } What? That 32bit per pixel is far too memory consuming for a windowing } system that does the saving of backgrounds itself? Nothing proprietary } in this knowledge ;-) } } The PE was designed for 2 bit per pixel with a small resolution and } the concept was good for that purpose. It's however a very bad design } if you have more bits per pixel (one single(!) 800x600 window almost } needs 2MB in 32 bit mode!). It would be better if PE was able to compress the saved area on the fly, or even better, perform no saving and require a (re-)drawing routine from each application. But then this would be trading memory for CPU and more problems for the applications. Well I don't think memory is of any concern for people with hi-colour mode capabilities... I don't think there are users of QPC2 and Qx0 without at least 16 Megs of RAM... As for compression of SCR, I am currently working on a modified variable RLE model (3 bytes or 4 bytes long) with the following specs: 1 bit (RLE code / 0 for 128 repetitions and 1 for 128 repetitions.) 7 bits (repetitions) (if RLE=0) or 15 bits (repetions) (if RLE0) 16 bits (pixel data) However it's insanely slow with Basic (Peculiar thing here... VB 6.0 compiled running Atop a 1GHz Athlon is slower compression-wise than a plain QL working with Peeks and Pokes in Memory compiled with Turbo - The QL version is at least twice as fast!!! Yep the QL always had kick-a## number crunching capabilities). Decompression is extremely fast both places which is really good. Especially if the file is loaded using FS.LOAD it's practically non-noticeable... Phoebus
Re: [ql-users] Turbo TK v3.32 and OT
At 09:35 ìì 13/2/2002 +, you wrote: In article 001501c1b465$d3545320$2f075cc3@default, Dilwyn Jones [EMAIL PROTECTED] writes He didn't send an attachment, just the notes on what to do to correct the zip file. But it's done now anyway///phew! OK ... glad you were up to the task :-) Was there any doubt??? (Yes we suck up to you Dear Sir Mighty-Magnificent-QLT Editor-and-Commander-In-Chief-Of-All-the-United-QL-Forces-and-expert-to-all-things-S*Basic Lord(of the Rings and other things) Dilwyn Jones :P~~~ (Yuck that's drool) ) Ha! Seriously now I've been complaining for that TK for months now and I am really amazed that nobody else noticed that bug :- Thanks (see above for complete characterization :-) Dilwyn for correcting the problem Phoebus
Re: [ql-users] Turbo TK v3.32
At 09:55 ìì 11/2/2002 +, you wrote: I have just uploaded a correction to Turbo Toolkit v3.32 on my website. David Gilham contacted me to say that some incorrect files from a previous version were included in the TURBOTK.ZIP file on my website's Other Software Page. This error has now been corrected. Aha... it turns out I was right after all :-) (God I love it when this happens) If you downloaded Turbo Toolkit v3.32 before tonight (11/2/2002) please download it again - the correct zip file version is about 95KB long rather than about 105KB. Apologies for the error. Actually I don't think the error was yours in the first place (unless you created the zip file). I turned out that the QDOS_code file was fine, but the SMS file had the hiccups ;-) (Among other things sent the Charge command, home for tea! instead of running Turbo :-) Phoebus
Re: [ql-users] DISP_COLOUR
At 10:31 ìì 11/2/2002 +0100, you wrote: Phoebus R. Dokos wrote: There is no support. But due to the way the PE is designed a 24bit mode is no good idea anyway. Care to elaborate on this without revealing too much proprietary info (Pleaseee?) I think the only effect of a DISP_COLOUR 4 call is that the corresponding variable will be set to the wrong value. Applications evaluating this variable may therefore behave strange. Oh I see... So effectively it can just be flipping around byte values or just garbling the contents of the screen memory...? Phoebus
Re: [ql-users] DISP_COLOUR
At 02:44 ìì 9/2/2002 +, you wrote: Does anyone know what Disp_Colour 4,x,y is supposed to do? IIRC from the QPC manual (I don't have it in front on me) it's supposed to switch to 24 bit colour, however I see nowhere a documented Mode xx for 24 bit colour Can someone help? 24-bit colour mode is a 16 million colour mode. As yet does not exist in hardware terms - SMSQ2.98 docs say: 'DISP_COLOUR colour depth Specifies the colour depth to be used - 0 for QL, 3 for 16 bit (65536 colours) also 1 for 4 bit (16 colour) 2 for 8-bit (256 colour) and 4 for 24 bit (16 million colours) - but these do not exist' I don't know if the last part refers to the fact that SMSQ/E has no support (yet) for those colour depth modes, or just that there is no hardware with 24 bit support. The theory for 24 bit (true) colour mode is: MODE number 64, 16 million colours, 24 bits, 8 bit RGB colour definition, organised within the long word as (again, I don't know if the lower 8 bits are used for anything...) Hi Dilwyn, I found out that one of my converted PIC or SCR files that loads great in say 800x600 appears totally distorted when the DISP_COLOUR 4 is given... (If you ask me why in heaven's name I gave DISP_COLOUR 4... well it was a typo!) Nonetheless I observed the following: 1. Organization in that mode must not be 3 bytes per pixel because just the colours appear distorted and not the overall size of the SCR file when loaded with BGIMAGE 2. It turns out to be semi black and white... So my question is: Is that an undocumented 16 bit greyscale or what Phoebus -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] elf compilers
At 07:11 ìì 9/2/2002 +, you wrote: On Sat, 9 Feb 2002, Tony Firshman wrote: I remember a long session with Freddy and Lau in an Eindhoven room Lau? Lau? Lau = Laurence Reeves, author of Minerva :-) Phoebus P.S. Lau-Lau in Turkish (and adopted Greek, that's what 400 of occupation will do to you...) means slowly-slowly :-) Lau is anything but slow (well except in releasing Minerva in the PD ;-)
Re: [ql-users] elf compilers and OT and more OT and extra OT
Tony Firshman wrote: Ah - like me - a young looking fifty plus. Lau you owe me a pint (:-) and now you have to guess my age (8-)# (barely audible) 25 -What do I win? Phoebus
RE: [ql-users] CF Cards and Hot-swapable readers.
At 02:45 ìì 8/2/2002 +0100, you wrote: So a small (mobile ?) QL-compatible system with only solid state devices would be feasable ? It's not only feasible, it has been done previously (with the RomDisq - MPLANE combo) and now (see my page at: http://www.redoak.net/QL/proforma.html ) Phoebus
Re: [ql-users] CF Cards and Hot-swapable readers.
At 08:41 ðì 8/2/2002 -0500, you wrote: Keep in mind that hot-swap will not necessairly work with anything but PC. It still MAY work with QL et al, but provided you: Oh I know that Zeljko, that's why I am sending you one of these to try on Monday :-) (Now if that's not a quick response what is) Phoebus
Re: [ql-users] ms-users-and-smalltalk-list: THE END
At 06:45 ìì 8/2/2002 +, you wrote: - Original Message - From: [EMAIL PROTECTED] Subject: Re: [ql-users] ms-users-and-smalltalk-list Well, perhaps the person using it actually thought that there is such a thing as M$ crap - and I presume that a certain number of people on this list will agree (me, for instance).. May be, but when you use language like that you demean yourself more than you demean M$. Pity because most people who do use it on the group are highly respected within the QL Community and have proved through their QL work that we don't need to use cheap, emotional language in the M$ v QDOS/SMSQ battle. Hello Geoff, there's one thing that may be involved here... and that's English not being the native language for many ql-users contributors (incl. myself). We know as much English as we are taught (and many of us are self taught) and we do not posess the advantage of being born in the US, or the UK etc.. In that aspect (linguistically... sorry about that term :-) many words to many of us do not appear bad or emotionally charged. For example for me although I know the etymology of the C word I have the understanding that at least in the place I am it's a good substitute for trash - which at times sounds a lot harsher-. Nevertheless since I use the word... succesfully :-) for many years with no complaints whatsoever I have to apologize if I offended anyone with it... I always thought it (and other words) to be good substitute for s words :-) However there is now a paradox... some people in this list (names don't matter I am just trying to make a point) do consider that this list is the equivalent of a pub meet after a QL show... well I don't know about anybody else but in a pub environment not only we use C words but also plenty of S, F and so on... The thing is that we need be a little more on the tolerant side but also self-restrained... and that's exactly why I proposed the ql-chat list which Dave promptly created... (thanks Dave). That way everyone's happy and noone is offended. And that's my final contribution to the subject publicly and please as many others suggested let's put the subject to rest now... (I do welcome personal emails on the subject though) Best Regards, Phoebus
[ql-users] DISP_COLOUR
Does anyone know what Disp_Colour 4,x,y is supposed to do? IIRC from the QPC manual (I don't have it in front on me) it's supposed to switch to 24 bit colour, however I see nowhere a documented Mode xx for 24 bit colour Can someone help? Thanks, Phoebus
RE: [ql-users] ms-users-and-smalltalk-list
At 02:25 ìì 7/2/2002 +, you wrote: ql_fetist - interesting. What's one of them ? :o) Probably me (sleep with my Aurora every night - Much to my wife's chagrin...) Phoebus
RE: [ql-users] ms-users-and-smalltalk-list
At 02:59 ìì 7/2/2002 +, you wrote: On Thu, 7 Feb 2002 [EMAIL PROTECTED] wrote: Web-based chat coming soon - much better than the current board... But then I wouldn't be able to read the messages as they arrive throughout the day like I can with email. Our web access is monitored. That would be: better than the board currently at ql.spodmail.com, not better than this list. Can you telnet or SSH? It won't help him much, since I suspect that as companies that size usually do, the keyboard clicks are also monitored (to avoid circumventions like that). Spyware as an art... He's right.. the best way even though not the most secure possible to get his QL news chit-chat etc. would be via email Phoebus
[ql-users] CF Cards and Hot-swapable readers.
Hi, since many people asked me about them: If I can get 20 orders for 64Meg 26x cards, the price will be 32.99 + sh For H/S reader the price right now is 22$ each HOWEVER the H/S readers are h/s only if you start the reader with a card inside (at least on a PC... I havent tested them on ANY QL/QL Compatible machine, but apart from that they are identical to the ones I already sold... Phoebus
Re: [ql-users] Re: Q-less
At 09:44 ìì 7/2/2002 +, you wrote: On Thu, 7 Feb 2002, John Hitchcock wrote: Ok... someone is going to mention 50/60Hz I'm waiting. (:O( I'm building a powered backplane which will take power from a switched mode PSU. Such things as 50/60Hz and voltages won't be an issue. Why don't you ask Nasta for a Q-Plane? or Tony for a M-Plane (not good to re-invent the wheel) I'm also playing with ideas for Goldfire. Nasta's slowly working it through, and one day, it will be here. At that time, I hope to be able to case/package the card in a very interesting way - I think you'll be impressed... Picture a regular almost QL-looking device... ;) Wayy ahead of you there contact me if you are interested :-) Phoebus
[ql-users] QLU Netiquette (was: ms-users-and-smalltalk-list)
At 11:25 ìì 7/2/2002 +0100, you wrote: The fact is: Off topic emails are breaking the rules of this list, see above. Peter (and a lot of others) are the victims, please don't forget that. Converting the victims into gulty ones is perversion. Although I don't think that anyone wants to turn anyone into victim or victor (maybe I am far too idealistic... I don't know), Claus is absolutely right on the rules of Ql-users QL Users welcoming email does set the rules and the rules do not include M$... As I said in a previous email there are ways to settle this once and for all: a. Either the moderator sets clearly the rules and that's that b. The list votes c. We create a couple of separate lists like for example: Ql-chat... This way everyone's happy and we don't have too much trouble I am subscribed to all major ql lists and I don't see a problem being (or not) a part in another one... At least we could give ppl the option :-) Phoebus
[ql-users] List etiquette. (Was: ms-users-and-smalltalk-list)
At 09:14 ðì 6/2/2002 +, you wrote: Norman's rant-mode on message snipped Hi all, No matter how much I understand each side's arguments I think it's a good time to say the following: 1. First of all, our freedom must stop where someone else's freedom stops. This is a fundamental democratic responsibility and I for one, no matter how much I agree or disagree with any side's position have to respect that... 2. It is a shame losing any of our developers from this list. They are a valuable commodity to a small group as we are... Having said that it would bother me just as much to lose you Norman as a contributor as it does to lose Peter or anyone else. Where would we be without Nasta for example, or Tony... and how much more rich our list would be if we had Simon Goodwin among us or Tony Tebby or Jonathan Hudson...? 3. Although going out with a bang as Peter did is my favourite course of action at times (Don't forget that I am Greek ;-))) We invented drama!) I have to admit that it is something that I don't particularly enjoy being done to me (Maybe it's me maturing -finally- or the understanding of people's differences). Nonetheless It's clear that it can be just frustrating to other as the original reason to the affected party... 4. If you want my two cents (which probably you don't ;-) but that's another story) I believe that the list is extremely PC oriented nowadays (and partly because of me too... I don't leave my tail as we say out of it!). It's proven that no matter how much useful advise regarding viruses and other security holes in M$ products has been exchanged in this list, people still do the same mistakes... still use Microsoft products and will still have the same problems which will still beg for the same advise... This repeating of mistakes especially on a foreign -to the subject of the list- platform can be very frustrating.. (Again I don't leave myself out of it... I did it numerous times and I would probably do it again). 5. No matter how much you agree or disagree with Peter, you have to admit that we do not (because it's convenient or because we forget) include the OT: prefix in our mail subject lines when its appropriate... This alone could save a lot of trouble and similar phenomena in the future. 6. Finally, whether we agree or disagree with Peter (or anyone else with the same or different or in general radical ideas) we have to consider voicing our concerns directly to them before going to the list... (That goes both sides and it does not imply anything about ANYONE - Just to make sure I am not misunderstood). All of the above, must not taken as a way of politely taking sides. My opinion on this matter is crystal clear and furthermore I like everyone on this list... else I wouldn't be here... :-) (So don't try to think that I am saying something that I don't). For all the above, I would propose a discussion on the proper etiquette of this list. If we set rules that are impartial, things like that will not happen again and arguments of this sort would be moot anyway :-) So I would accept comments on the above with thanks (And this is ON topic since it concerns the operation of the list). Especially I would like Bruce to voice his opinion on this (list moderator and all...:-) to solve problems like that at their genesis once and for all... Sorry for the extremely long mail, Phoebus
Re: [ql-users] List etiquette. (Was: ms-users-and-smalltalk-list)
I wrote: 1. First of all, our freedom must stop where someone else's freedom stops. This is a fundamental democratic responsibility and I for one, no matter how much I agree or disagree with any side's position have to respect that... Well that would be stops when the other's STARTS anyway you get the message!
Re: [ql-users] Euro character
At 06:22 ðì 5/2/2002 -0500, you wrote: Hi I have installed the 8 fonts which have the euro symbol for Proforma (Prowess) and have tested and they work. Bravo Phoebus (I think), download from http://www.redoak.net/QL/proforma.html Thank you Ian :-) There is a slight side-effect that was reported by Wolfgang (BTW Wolfgang did the fix I proposed work?) At 1024*768 resolution for certain sizes (usually even sizes) the baselines go for a walk (!) so either try to use 800*600 or odd sizes to compensate... I still didn't upload the Verdict font (some way to go there I am afraid) Phoebus
Re: [ql-users] Euro character
At 02:58 ìì 1/2/2002 +0100, you wrote: On 5 Feb 2002, at 8:33, Phoebus R. Dokos wrote: There is a slight side-effect that was reported by Wolfgang (BTW Wolfgang did the fix I proposed work?) At 1024*768 resolution for certain sizes (usually even sizes) the baselines go for a walk (!) so either try to use 800*600 or odd sizes to compensate... I still didn't upload the Verdict font (some way to go there I am afraid) I haven't had time to try - this weekend! Wolfgang Wolfgang, you clock is way of again (4 days!) I had trouble finding your email Phoebus
Re: [ql-users] Virus
At 08:52 ìì 5/2/2002 +, you wrote: I said - 1. The latest Internet Explorer (v6.0) [incorporating Outlook Express] has more inherent security than previous versions. Roy said - Wrong - read the Register (www.theregister.co.uk) it has more holes that a Swiss cheese. I did - Security update download (2.27Mb!) I say - Thanks Roy John in Wales And what exactly do you think that solved? One problem and (most likely) created 200 others :-) (Any good M$ product does that) Phoebus
Re: [ql-users] ms-users-and-smalltalk-list
At 10:41 ìì 5/2/2002 +0100, you wrote: Hi folks, I find it absolutely OK to have some off-topic mails on this list now and then. But in the last weeks there has been a neverending *huge* flood of absolutely non QL-related traffic. PC's, Microsoft, the related software and the related viruses and the related problems will never end, and there are enough forums where they can be discussed. There is no reason why these forums are not used, and the ql-users list is constantly abused instead. Why don't you open a ms-users-and-smalltalk-list? Please see that I'm not talking about just a few mails now and then - that's fine by me! I'm talking about floods of mails. The consequence is, that I will now leave the list, because I don't have the time to handle this anymore. I'll unsubscribe after this mail. All the best Peter Well as a contributor of sorts in this (nicely put) flood, I for one agree totally to quit talking about M$. I certainly wouldn't like to lose Peter from the list :-) Phoebus
RE: [ql-users] Virus
At 08:21 ðì 4/2/2002 +, you wrote: I have just signed up with Demon and got Turnpike 6 for my emails. It is ok, but my wife has problems with it. However, calypso, is excellent. Once installed, my wife was using it in seconds with no problems. It looks a bit like 'lookout' but doesn't have the mail work problems. Highly recommended. (and free) http://10xshooters.com/calypso-free/ One problem though, not supported anymore and with LOTS of problems under Win2K and (I suspect) under Win XP. P.S. Follow the link (Lindows.com) at the bottom of the page... you are in for a big surprise :-) Phoebus
RE: [ql-users] Virus
At 03:01 ìì 4/2/2002 +, you wrote: Works like a dream on Win2k over here then, and Win98 ! And I followed the link, didn't get a surprise - what was I expecting ? Puzzled of Bradford. :o) Linux running Windows... rather cool don't you think? Phoebus - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: Phoebus R. Dokos [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 2:55 PM To: [EMAIL PROTECTED] Subject: RE: [ql-users] Virus At 08:21 ðì 4/2/2002 +, you wrote: One problem though, not supported anymore and with LOTS of problems under Win2K and (I suspect) under Win XP. P.S. Follow the link (Lindows.com) at the bottom of the page... you are in for a big surprise :-) Phoebus This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
RE: [ql-users] Virus
At 03:14 ìì 4/2/2002 +, you wrote: I see, I thought it was something with your picture one, or similar. I do know about Lindows, but unfortunately, it is a bit (a lot) of vapourware at the moment. No-one has seen anything of the product, no downloads etc. WINE, on the other hand, is around and works - mostly. I have... I paid 99$ to be an insider :-) Installed really fast and easy.. still have some quirks but basically it's Linux for the masses :-) (And not only for Thierry, Richard, Claus and Peter ;-) (Just joking!) Example, some Linux guy wanted to run Ecxchange on his Linux server, installed WINE, and got Exchange up and running very quickly. Within an hour, he was hit and trashed by SirCam. Obviously the whole system wasn't trashed, being Linux, but still hugely funny ! Norman.
RE: [ql-users] Virus
At 03:23 ìì 4/2/2002 +, you wrote: Send Linux Format magazine some details - they seem to think it doesn't exist ! They don't want to pay apparently ! I don't honestly think that it will be ready by until April that they say...but nonetheless it's worth an effort I think! Phoebus - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: Phoebus R. Dokos [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 3:21 PM To: [EMAIL PROTECTED] Subject: RE: [ql-users] Virus I have... I paid 99$ to be an insider :-) Installed really fast and easy.. still have some quirks but basically it's Linux for the masses :-) (And not only for Thierry, Richard, Claus and Peter ;-) (Just joking!) This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
Re: [ql-users] Virus
At 03:54 ìì 4/2/2002 +, you wrote: Re: Hi Geoff, the singular MOST important thing you need to do to get rid of worms of that kind is to get rid of Outlook you are using :-) You wouldn't have any trouble with Eudora for example :-) ... or Turnpike. This is Demon's mailer, but is generally usable for about £25 I think. It is a quite superb piece of software. == 1. The latest Internet Explorer (v6.0) [incorporating Outlook Express] has more inherent security than previous versions. Yes... and the Pope is Orthodox :-) 2. It is free. Yes considering how much money they make by stealing your personal info 3. I keep one bogus address in my address-book. That way, if it were returned i.e. - Clever :-) A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:.. In some circumstances at least I would then know that I just left the stable door open! No! - not *yet* I haven't. But a month ago I caught BadTrans in the act. Smug! ;) Which proves the point... You wouldn't have BadTrans have you used a different email client Welsh John
[ql-users] Surplus QL ED drives
Hi all, PC Surplus online has a HUGE stock of Mitsubishi ED drives for $4.00 (Yes 4!) a piece Check it out here http://www.pcsurplusonline.com/cat.cfm?catid=3 Phoebus
Re: [ql-users] Surplus QL ED drives
At 12:33 ìì 4/2/2002 -0500, you wrote: On 2/4/02 at 12:26 PM Phoebus R. Dokos wrote: Hi all, PC Surplus online has a HUGE stock of Mitsubishi ED drives for $4.00 (Yes 4!) a piece Check it out here http://www.pcsurplusonline.com/cat.cfm?catid=3 Well, yes, there's just one problem: they are from IBM Did you call them? On the website it does say Mitsubishi (And that's the one I used to have) Phoebus and have NO jumpers. It still may be possible to get them to work on a GC/SGC, I'm looking into it. My efforts have been thwarted by an unlikely problem: now that I am using a CF card instead of a 'ral' hard drive, the QL's power consumption is too small - in particular, it uses next to no power from the 12V line, which is confusing my power supply :-) Nasta
Re: [ql-users] Virus
At 07:21 ìì 4/2/2002 +, you wrote: In article [EMAIL PROTECTED], Tony Firshman [EMAIL PROTECTED] writes On Sun, 3 Feb 2002 at 16:59:31, Phoebus R. Dokos wrote: (ref: [EMAIL PROTECTED]) At 09:21 ìì 3/2/2002 +, you wrote: I am sorry I have discovered that the BadTrans virus had infected my machine. My apologies if I have infected someone else, but I think I picked it up through the group originally, so there is probably someone else with the problem. Fortunately it was no more than a couple of days, but that is long enough to do damage. Hi Geoff, the singular MOST important thing you need to do to get rid of worms of that kind is to get rid of Outlook you are using :-) You wouldn't have any trouble with Eudora for example :-) ... or Turnpike. This is Demon's mailer, but is generally usable for about £25 I think. It is a quite superb piece of software. I can second that Turnpike is superb piece of software, if you want a good email system ... with great potential for more sophisticated use. However, it all depends with a virus what it is aimed at. The best thing with anything supicious is not to read it ! Yet we all succumb at some time. Another way is to examine it in an editor - only - to check out its contents ... yet you need some expertise there. Usually the virii are written in compiled Visual Basic ... as this is what is available to the authors of this rubbish. So look out for anything with .com or .exe in the file name. Not really mostly interpreted VB for Applications (Comes bundled with every major M$ product) Also the newest trick is to send a .COM file (Most post 95 users nowadays don't know that these are executable files) and the user perceives it as a link :- Phoebus
Re: [ql-users] Virus
At 09:21 ìì 3/2/2002 +, you wrote: I am sorry I have discovered that the BadTrans virus had infected my machine. My apologies if I have infected someone else, but I think I picked it up through the group originally, so there is probably someone else with the problem. Fortunately it was no more than a couple of days, but that is long enough to do damage. BE WARNED! This is a new version of the worm that was not detected in several scans, even with recent scanning software, that I did after getting the suspicious email with a ql-users subject line. I became more suspicious when, during routine maintenance, my hard disk seemed more fragmented than usual. It was only after I had downloaded the latest definitions that I finally tracked it down. Again my apologies for any trouble caused. Geoff Wicks Hi Geoff, the singular MOST important thing you need to do to get rid of worms of that kind is to get rid of Outlook you are using :-) You wouldn't have any trouble with Eudora for example :-) Phoebus
Re: [ql-users] Virus
I retraced the virus that came to me and it's definately from France. So whoever is using wanadoo.fr AND windows, better check your accounts and fast P.S. Norton Antivirus didn't get the Worm but AVC did :-) Phoebus
Re: [ql-users]OT: Launch of new web site
You should talk to Roy Wood about Accept, I think he did their sound on a few tour dates on the continent - In fact, quite a few big german metal bands. He has a list of the ones hes worked with on his website. He was kind enough to get me some T-Shirts and a signed UDO solid album a while ago (he was the lead singer with Accept). Pretty amazing voice for a little fat guy! He can tell some pretty wild roadie stories too.. I toured with Pink Cream too. Where did you put it one (8-)# Where did you put it ON, I meant My fingers really aren't working at the moment (and no comments please (8-)# ) Well considering Pink Cream had a Greek member, it probably hurt if he tried to put IT anywhere ;-))) Oh geez :-) Phoebus
Re: [ql-users] Launch of new web site
At 05:14 ìì 2/2/2002 +0100, you wrote: Tony Firshman wrote: Yes - I have seen that reaction too. Mind you, you are getting older now (8-)# Did you have to say that? :) Oh c'mon... why do YOU complain...? What can I say then? Phoebus Marcel
[ql-users] Virus
Re: my previous email... This was on the header Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto6.wanadoo.fr; 2 Feb 2002 22:01:48 +0100 Probably an edited message by the worm itself, but it had the ql-users signature on it so whoever sent it me is definately reading the list Careful again Phoebus
Re: [ql-users]OT: Launch of new web site
At 09:59 ðì 1/2/2002 +, you wrote: Phoebus Wrote:- Oh I forgot were did you dug up (sic!) Grave Digger ??? hehe Really interesting choice of styles (I'm with ya buddy ;-) -Note: check ME out at: www.mp3.com/silverrisc ) but you really dissappointed me not mentioning my two FAVOURITE German bands of all time ... (Pink Cream 69 and Accept ;-)... all right and Running Wild (they are german aren't they?) You should talk to Roy Wood about Accept, I think he did their sound on a few tour dates on the continent - In fact, quite a few big german metal bands. He has a list of the ones hes worked with on his website. He was kind enough to get me some T-Shirts and a signed UDO solid album a while ago (he was the lead singer with Accept). Pretty amazing voice for a little fat guy! I have actually sang with him back in Greece at a gig organized by my then Record Company... The most memorable thing was that Udo Dirkschneider (If I wrote his last name right)... MAN HE CAN DRINK HIC! (They had to carry me out... and he was going and going and going (We -my band- started calling him Duracell UDO from then on ;-) He can tell some pretty wild roadie stories too.. Cheers, Darren Branagh, Consumer Lending Business, Bank Of Ireland Card Services, Nassau House, 33/35 Nassau Street, Dublin 2. Ireland. Tel: 01-6176368 (Direct Line)Fax: 01-6798717 [EMAIL PROTECTED] This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify us immediately at [EMAIL PROTECTED] and delete this E-mail from your system. Thank you. It is possible for data transmitted by email to be deliberately or accidentally corrupted or intercepted. For this reason, where the communication is by email, the Bank of Ireland Group does not accept any responsibility for any breach of confidence which may arise through the use of this medium. This footnote also confirms that this email message has been swept for the presence of known computer viruses.
Re: [ql-users] BMP2SCR-WIN Add.
At 09:03 ðì 1/2/2002 +0100, you wrote: Phoebus R. Dokos makes some magical things to make me read } A BGIMAGE type of command, with the difference that it will be able to } display on screen and at the point we want RLL encoded BMP files at all } colour depths (if it is 24bit of course it will be slow :-)) If it is for displaying picture, there is already photon available. It is a little bugged with mode 33/32 pic files, but has no problem with BMP. I agree but with one difference, Photon can't mix graphics with text :-) Phoebus
Re: [ql-users] Replacing S*Basic procedures
At 04:39 ìì 1/2/2002 +0100, you wrote: Phoebus R. Dokos wrote: For example we come up with a BGIMAGE command that would be updated to Change Aurora's register's first and then load up a Aurora format SCR file for example, Of course one could do such thing but consider the side effects: after switching to the high colour mode and displaying the background image all other applications including SMSQ/E itself will (oblivious of the new screen format) just write garbage to the screen. Marcel Not necessarily if ALL of the colour affecting procedures are replaced in one single program (That would be useful for full screen apps for sure). Care should also be exercised restoring the mode after you're done... IIRC especially for Aurora with its 3 screen areas, SMSQ/E could still write on SCR0 and the results would be tranlated to the appropriate mode on SCR2 (I do remember fiddling with that (while I still had my SGC which should be back any time now... :-)) and with very good results.) Sure more investigation is needed but the potential is there... I don't expect TT to have Aurora GD2 ready anytime soon (unless v. 2.99 dealt with it) Phoebus
Re: [ql-users] BMP2SCR Windows
At 04:29 ìì 1/2/2002 +0100, you wrote: On 31 Jan 2002, at 15:10, Phoebus R. Dokos wrote: Hi all, After lots of trial and error (Mainly because I had to relearn binary arithmetic ;-) My BMP2SCR-Win program is updated to official version 1.1 Hi, let me have the sources (or at least some doc on the windows BMP format), I'll try to see whather we can't have the same thing under SMSQ... Wolfgang - www.wlenerz.com Sending them over... Careful the source is not fully (well not at all) commented... I'll add some comments and send it over (Don't be alarmed by the string handling though because VB can handle HUGE strings (1 Mbyte long strings is common!) Phoebus P.S. Remarks are noted with a ' (single quote) VB Source begins- '* '* BMP to QL Pointer Environment PIC File Converter for GD2 * '* == * '* © 2001 Phoebus R. Dokos - Original Program © 2001 Malcolm Lear* '* This Program is Freeware * '* Public glbFlagOk As Boolean Sub ConvertFile32(BMPFile As String, PicFile As String) Dim glbWidth As Long Dim glbHeight As Long Dim glbX As Long Dim glbY As Long Dim glbAddress As Long Dim InputFileLength As Long Dim OutFileLength As Long Dim Remaining As Long Dim Maximum As Long Dim glbBlue As Integer Dim glbUgreen As Integer Dim glblGreen As Integer Dim glbRed As Integer Dim glbLoadedBytes(3932214) As Integer Dim glbSavingBytes(3932160) As Integer Dim glbCounter As Long Dim BytesIn As String Dim BytesOut As String Dim TempText As String Dim Counter As Long Dim ReadMsg As String Dim ConvertMsg As String Dim SaveMsg As String Close 'Close all files in case we forgot something main.sbrStatus.Panels(1).Text = Input File: BMPFile - Output File: PicFile 'Put info on status bar on name window 'Initialise Variables ReadMsg = Reading File: BMPFile 'Messages for the Progress bar (frmProgress) ConvertMsg = Converting SaveMsg = Saving File: PicFile frmProgress.Show 'Show the Progress Form Open BMPFile For Binary As 1 'Open the file... Opening in binary format because it is faster than reading text streams InputFileLength = LOF(1) 'Calculating Length Remaining = InputFileLength 'Calculating Remaining and initializing Maximum = Int(InputFileLength / 6) 'Assigning the size of the read block to 1/6 of the size of the file. 'This is done solely because we want to show some progress on the screen with the progress bar. It could be adapted not to show progress at all. 'If we remove all progress crap then we can speed reading by 50% frmProgress.ProgressBar1.Min = 0 'Set limits on the progress bar values frmProgress.ProgressBar1.Max = 100 'same Do Until EOF(1) 'Loop until we reach the end of the bmp file frmProgress.ProgressBar1.Value = Int(Abs((InputFileLength - Remaining) * 100) / InputFileLength) 'We set the value as a percentage 'of the progress frmProgress.Caption = ReadMsg ( frmProgress.ProgressBar1.Value % completed) 'This changes the progress windows title according to how much % of the file we read TempText = Input$(Maximum, 1) 'We read the file in chunks of Maximum from channel 1 and assign it to the temporary variable 'Text' BytesIn = BytesIn + TempText 'We add the read part to the string BytesIn (Don't be confused, the $ sign must not be included since the variable was dimensioned as string above Remaining = Remaining - Maximum 'Now we update the remaining variable If Remaining Maximum Then Maximum = Remaining 'Pretty self explanatory... If Remaining = 0 Then Exit Do 'Get out of the loop immediately (if you don't put that it will crash) if no file remains Loop 'Loop's end Close 'Close the file 'Below we check absolute byte 28 (Strings in VBasic start from 1 not 0 hence the 28 + 1) for the decimal value 24 'If it doesn't exist Show a Critical Error message box and exit 'The actual functions are: 'ASC (it's like CODE in S*Basic): Returns the Decimal value of a character 'MID($): Performs string slicing (Similar to the TO in Sbasic which is a lot more elegant) The $ identifier can be ommited (Only with VB DOS 1.0 and above 'In GWBASIC, QBASIC, QuickBASIC and PDS it has to be there If Asc(Mid(BytesIn, 28 + 1, 1)) 24 Then MsgBox NOT a 24 bit Image, vbCritical, Colour Depth error: bmp2scrWin.glbFlagOk = False: Unload frmProgress: Exit Sub 'Now we get file information 'First Width glbWidth = ((Asc(Mid(BytesIn, 19 + 1, 1))) * 256) + (Asc(Mid(BytesIn, 18 + 1, 1))) 'Then Height glbHeight = ((Asc(Mid(BytesIn, 23 + 1, 1))) * 256) + (Asc(Mid(BytesIn, 22 + 1
Re: [ql-users] BMP2SCR Windows
Also as you may have noticed the REMarked title is wrong since the snipped sent is actually ONLY for SCR files :-) Phoebus
Re: [ql-users] BMP2SCR-WIN Add.
At 08:12 ìì 1/2/2002 +, you wrote: In message [EMAIL PROTECTED], Phoebus R. Dokos [EMAIL PROTECTED] writes Just to add a little something to my previous announcement, The next version will have also support for RLL encoded BMPs... and auto select of conversion method according to colour depth (currently the code supports only 24 bit colour) Also in the works right now (I'll get to the fonts too but right now I've been named official translator of Opera so I'm kinda racing to finish the damn thing) Is that Opera the browser ? Very nice program ... what are you translating it to ? Why in Greek of course (Rolls eyes) what else? Phoebus :-) P.S. We also have one tug-of-war going on with them... I am trying to convince them to compile for m68k (Q40) Linux :-) P.S. (2) For whoever is interest we also prepare (me and the secretary of the Hellenic Language Institute) Ancient Greek and Latin versions ;-) hehehe :-) Didn't start the Latin yet but it will be interesting to say the least :-) (Yeah maybe the Pope will use it :-) -- Malcolm Cadman
Re: [ql-users] nenscript - Postscript file format creator
At 07:19 ðì 31/1/2002 +, you wrote: Don't quote me on this - it's too early in the morning - but I believe that some progress has been made with some winprinters under linux. The problem as I understand it is that unless you are running windows one size definitely does not fit all as the implementation varies bwetween what is in s/ware and what is in h/ware from manufacturer from manufacturer. The problem is, therefore, that the SMS solution would have to emulate the hardware function (just like windows!!) and different (complex) drivers would be needed for each printer. Tony Gordon Hi Tony, this part (in part ...sic!) is already done by ProForma which is in a sense the Windows GDI equivalent... The trick is instead of creating the final output you serve the printer with semi-raw bitmapped GDI data... However ProForma does things a lot different than Windows in that aspect although in principle they are the same... Marcel is right... every printer manufacturer does things differently, the point is though that every manufacturer has a uniform way of addressing their models line (no point of reinventing the wheel even for a company the size of Epson), so if we could emulate at least ONE we would be somewhere... I managed to reverse-engineer part of the format of Lexmark Z series printers by applying a simple technique. In one given paper size I had 1 point printed at the maximum allowed resolution in each corner and the center... Results of this I was able to replicate and create points for virtual every place in that given paper size using the QL... However there is a long way to go still (and I haven't even touched colours) Phoebus
Re: [ql-users] Launch of new web site
At 07:02 ìì 31/1/2002 +0100, you wrote: After all those printer issues I'm proud to announce the launch of my completely new web appearance. It's address is http://www.kilgus.net/ and it contains all the latest news about QPC. The new pages are easier to maintain and therefore there is a good chance that I really will keep them up-to-date (beside the fact that I like how they turned out which was not true for my old page). To all web masters out there linking to my site, please update your links, I did remove the old page. Thank you. Reactions welcome, Marcel One thing I have to say It was needed :-) Congratulations Marcel :-) One little note though. The QPC manual, does or does NOT include the SMSQ/E manual (I have never clarified that). If it does, it would be nice for owners of QPC 2 to dowload it using a code. Phoebus
Re: [ql-users] Launch of new web site
At 07:41 ìì 31/1/2002 +0100, you wrote: Phoebus R. Dokos wrote: One thing I have to say It was needed :-) I know ;-) Congratulations Marcel :-) Thanks. One little note though. The QPC manual, does or does NOT include the SMSQ/E manual (I have never clarified that). Well, QPC comes with two printed manuals, the QPC part and the generic SMSQ/E part. The one on the page is the QPC part only as the generic part is not my business. If it does, it would be nice for owners of QPC 2 to dowload it using a code. The reason I put the manual up is that I have taken them back into my hands and will update them as necessary. The next QPC version will for example have a partly rewritten DOS device so that although the new manuals are not even a month old the paragraph explaining the SMS-PC file name conversion algorithm will already be outdated. The progress on the SMSQ/E side... well, there is none. So the printed manual supplied with QPC is fine (I BTW don't have it in electronic form anyway). Marcel Well that would be good if I had gotten a printed SMSQ manual but with NO VERSION of SMSQ/E I had, I got a manual :-( So how can a poor Greek immigrant get an SMSQ/E manual? Phoebus :-)
Re: [ql-users] Launch of new web site
At 07:53 ìì 31/1/2002 +0100, you wrote: Phoebus R. Dokos wrote: Well that would be good if I had gotten a printed SMSQ manual but with NO VERSION of SMSQ/E I had, I got a manual :-( So how can a poor Greek immigrant get an SMSQ/E manual? Well, to my knowledge it should have been supplied with SMSQ/QPC, so I guess asking your favorite SMSQ/QPC dealer might be the best option. Marcel Ahaaa! Thanks Marcel Phoebus P.S. For QPC2 v. 4.00 ;-) do you plan to access native SMSQ/E or QubIDE partitions??? (Say for QL formatted media like a Zip drive or a. CompactFlash card?)
Re: [ql-users]OT: Launch of new web site
At 08:34 ìì 31/1/2002 +0100, you wrote: Phoebus R. Dokos wrote: Oh I forgot were did you dug up (sic!) Grave Digger ??? Good German band, released a very epic album about the wars between the English and the Scottish (Tunes of war). The The clans are marching song of it came on TV once (when there was still metal on TV...) and I immediately liked it. One has just to get used to the voice. interesting choice of styles (I'm with ya buddy ;-) -Note: check ME out at: www.mp3.com/silverrisc ) Parental Advisory: Lyrics: Dokos. Hehe. Well since I am now a member of the ASCAP I had to add that... You know how crazy things can get here with the Christian Parents... etc associations. One has to be careful even if you just put something up with no intention to be famous or anything... just for fun :-) (Fun could turn easily into tears if I didn't include that an an overzealous parent saw it...) Nice rock indeed. Which one of the guys on the cover is you? Well thanks :-) Guess guess ;-) hehe Well if that helps I am sitting :-) (P.S) The girl in the cover is a Greek-German model :-) (There's the German connection ;-) Phoebus I lack to really know many older rock bands, but that's a hole I'm currently trying to fill. Well Pink Cream 69 is one band you GOTTA hear. all right and Running Wild (they are german aren't they?) Yes, and I just forgot them. Updated :) BTW: To all others and to remain a bit on topic, on the page is also the prove that I did indeed have real QL hardware once ;-) Marcel Haha maybe you should start writing a Windows Emulator for the Q60... that way you'll get once more real QL hardware and do what you know best ;-) Phoebus
[ql-users] BMP2SCR Windows
Hi all, After lots of trial and error (Mainly because I had to relearn binary arithmetic ;-) My BMP2SCR-Win program is updated to official version 1.1 New features. SCR files Mode 32 and 33 selectable (or both with auto renaming of the filenames) (Many thanks to Claus Graf, Wolfgang Lenerz, Duncan Neithercut for the testing, and Malcolm for the original source code and the input on Mode 32 and 33, Also thanks Jerome Grimbert for initaliasing the discussion) PIC files are now possible in both modes (32 and 33) - Thanks to Dilwyn Jones and Jerome Grimbert for the Info :-) Batch convert is finally available. Also speed has increased ten fold over the previous version (I quit using the Select Case... ) Next version will include support for modes 4 and 8 Whoever wants it, please send me a private email... Careful this is a Windows application.,,, Phoebus
[ql-users] BMP2SCR-WIN Add.
Just to add a little something to my previous announcement, The next version will have also support for RLL encoded BMPs... and auto select of conversion method according to colour depth (currently the code supports only 24 bit colour) Also in the works right now (I'll get to the fonts too but right now I've been named official translator of Opera so I'm kinda racing to finish the damn thing) A BGIMAGE type of command, with the difference that it will be able to display on screen and at the point we want RLL encoded BMP files at all colour depths (if it is 24bit of course it will be slow :-)) That's it, Phoebus
