[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
[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-gr.net (Remove the 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
Re: [ql-users] atan (SMSQ) & atan2(C68)
At 02:45 ìì 26/2/2002 +, you wrote:
>Has anyone else tried to use the arc tangent function in SMSQ or
>in C68? As far as I can see, its marginal behaviour is
>incorrect. If I enter 'print atan(1,0),atan(0,1)' to SBasic, I
>expect to get PI/2,0 NOT 0,0. Similar misbehaviour is shown by
>atan2 in C68 (I suppose this is only a wrapper for the
>underlying SMSQ module).
>
>Shouldn't atan2 be:
>
>double atan2(double y,double x)
>{
> if (x==0)
> {
> if (y>0) return pi/2;
> else if (y<0) return -PI/2;
> else return 0; /* or an OS error */
> }
> else return atan(y/x);
>}
>
>I know this may seem obscure but try working with angles with a
>defective atan(2) function!
>
>Christopher Cave
I have noticed a weird behaviour on ATAN myself unrelated to that. Many
times it returns rounded values instead of decimal ones but I haven't had
time to pinpoint the circumstances yet.
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] compact flash
At 12:30 ìì 25/2/2002 +, you wrote: >ZN wrote: > > > On 2/24/02 at 4:47 PM Phoebus R. Dokos 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... > > >Phoebus > > > > OK, after having a look with a scope, i can tell you that there is a > > difference depending on manufacturers. The difference stems from the > > compact flash spec - it is not really intended for operation on a cable, > > the drive current for the signals is MUCH lower than IDE. This is why all > > of them will invariably work in a camera or an environment where a cable is > > very short (you can see the adapter I made for the Qubide, it can hardly be > > shorter than that), but may not work on a cable. There are remedies, > > however: > > 1) Use the card with a hard drive at the end of the cable - the drive may > > work as a terminator. > > 2) Use a very short cable with only the CF adapter on it. > > > > The simple adapters are all really just pinout adapters, there is nex to no > > circuitry in them - at least not on the main signal lines. A hot-swap > > adapter may be different in this regard. > > > > Nasta > >Would one of the new 80 something! (not to sure what I'm talking about here) >cables work better. >I recently upgraded my PC and it would not read the 40 gig drive without I >used >the cable provided, it is a much finer cable than the ordinary IDE cable, >maybe >the card reader would work better with one NO! NO! NO! Alone on a ATA 66+ cable the CF adapters will fail miserably! They are to be connected on a ATA 66 cable ONLY if there is an ATA66+ device at the end of the cable and even then they MUST be in the middle of the chain! Phoebus >All the best - Bill
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] 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 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 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] compact flash and compatibility
At 11:48 ìì 24/2/2002 +0100, you wrote: >Phoebus R. Dokos wrote: > > Cards that do not work > > > All USB-Enabled (CF+) Lexar cards > >And the pictures on your page all feature such a card... > >Marcel Yes and it says there that they won't work UNLESS you are a magician (or Nasta which is the same ;- 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] 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] 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] Hove Workshop
At 09:08 ìì 23/2/2002 +, you wrote: >On 22 Feb 2002, at 17:40, Phoebus R. Dokos wrote: > > >> 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 > >And Wolfgang wrote > >yes, and that only if everybody goes and and pushes... > >As an ex-Railway employee I have to protest most strongly about this!! > >That would be completely against the rules. You have to wait >for members of the National Union Of Train Pushers to arrive or >there will be an immediate strike > Given my experience from both Greece and the US I think that this also suggests, that you need to file first an application in triplicate, with a stamp from the Magistrate and expect a blessing from the Pope as well (but only if you are Catholic of course). Phoebus ;-)
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
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] Hove Workshop
At 01:33 ìì 23/2/2002 +0100, you wrote: >On 22 Feb 2002, at 17:40, Phoebus R. Dokos wrote: > > > 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 > >yes, and that only if everybody goes and and pushes... Hehe that's what I've been told too ;-) (Despite what Tony says ;- Can't be all that bad though at least the trains keep on going It could be worse :-) (Example of worse: Having the Acela TGV in the US. You get the world's best train technology and you turn it into an expensive commuter train that breaks down most of the time!) 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] 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: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 ;-) Yes you are right. I zipped it directly on dos3_ I'll try it again using win1_ instead BRB
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 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 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] 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] 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)
[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] 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
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 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
[ql-users] Webpage updated
Hi all, the webpage is updated to include the links and the pictures (Goldfire case) however the files are not there (ie the links point to BlackHole_lzh to use a QL term ;-))) They will be up later on today. Thanks Phoebus
[ql-users] GoldFire Case
Also, on the same page ( http://www.redoak.net/QL/proforma.html ) you will find an artist's (that's me) rendition (front face and top cover views) of what I think a GoldFire case should look like (always IMHO!). Note that there's no real scale apart from the fact that the case will be a little wider than a standard 5 1/4" device. 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] 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: [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] 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
[ql-users] Parallax Scrolling
Hi all, I made a quick "parallax" scrolling demo... Well not exactly parallax scrolling since while the two planes move at different speeds they also move opposite one another. It is for mode 32 but will work with mode 33 if provided with a suitable scr file. (I can do that) Anyone interested to try it for Mode 33? The flickering/frame shearing in Mode 32 is practically unnoticeable but I would like to test how it looks on a q40/60 The zip file contains the source code and a Turbo 4.14 compiled executable For anyone that wants it, note that the bottom scrolling plane effect (the ground) uses TurboTKs PEEK$ and POKE$ while the top (sky and clouds) uses MEMORY_MOVE Phoebus P.S. One of the funniest effects happens if you execute it with EX instead of EW and then start switching windows/jobs... EVERYTHING becomes a mess! Nic :-) I don't know why but Turbo up to v. 4.11 didn't allow stopping execution with CTRL-SPC (Turbo 4.14 does return you to S*Basic with an Incomplete but the task keeps on running happily :-) (I don't know if it's a bug or feature but I like it :-)
[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 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] 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: [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
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] IDE switch
At 08:20 ìì 19/2/2002 -0500, you wrote: >On 2/19/02 at 10:28 PM P Witte wrote: > > >However, all I want is an extra connector on the cable and a switch to > > toggle power to either the one device or the other, ie nothing worth > > $39 + p&p and a big box. Well the box is not that big (5 1/4" form factor IIRC which in any case you are not using right? (Well okay maybe you are using the CD Rom) >You may not want it, but it's the only correct way to do it. Switching the >power supply will eventually do damage to either of the devices and/or the >Qubide (probably the latter) if it works at all. IDE devices are not >hot-swap, in other words, input signals should not be present when the >device is not powered up. Before you point it out: yes, there were a couple >of products that actually did this (usually 5.25" removable drive bays). You can still buy Hot-Swap IDE removable bays but be prepared to pay more than $39 (a lot more) >Ask yourself why you can't buy them any more... > >It is possible to only implement a simple select switch but not just by >adding a connector to the cable - two pins need to be switched and pulled >up to 5V when out of coircuit for both devices that are switch selectable. >Even so, it would not work unless the system is powered down (merely >resetting may not be enough) and the software detected new devices. Well I think that would do the trick for him (or me if I were looking for a similar solution). I mean it's a small "price" to pay if you don't want to spend the money. 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, : 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
[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] 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
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
At 08:12 ìì 19/2/2002 +0100, you wrote: >Joachim Van der Auwera wrote: > > 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. > >Helps, but doesn't solve the problem (I'm talking theoretically here, >possibly with enough effort the effects can be neglected but they are >there!). There is a time when you have to copy everything to screen >and when the screen refresh gets you then (when only halve of the >painting is done) there's nothing you can do about it. > >This is the reason why if you move the mouse cursor using the keyboard >the movement looks a bit more jerky on QPC than on the original >hardware, where the PE can rely on the frame interrupt. I don't know about that since it looks fine to me! Nonetheless to prove my point I used the MEMORY_MOVE command on QPC2 as follows: 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 The full thing was compiled with TURBO 4.9 and the results... well see for your self.. It seems pretty fast and flicker free to me :-) Okay it is "relatively slow" but nonetheless when dealing with 64x64 or less pixel areas, I believe that the flicker would not even be visible If anyone can try this out on a Q40 and Q60 I would very much appreciate it. Phoebus >Marcel
Re: [ql-users] Re: PIC/SCR Compression & Sprites
At 05:20 ìì 19/2/2002 +, you wrote: >In article <[EMAIL PROTECTED]>, Phoebus >R. Dokos <[EMAIL PROTECTED]> writes > >At 07:38 ìì 18/2/2002 +, you wrote: > > > >>What are you writing ? Presumably a game of some type :-) > > > >No comment :-) > >OK ... :-) > > > > > >Kinda like the Allegro library on the PeeCee (which unfortunately contains > >x86 assembly and it's impossible to port else we would be up to our necks > >in games by now :-) > >Yes, the graphics toolkit is a need, I see what you are getting at now. > >Didn't Simon Goodwin do at lot of work on this ? IIRC He did a lot of work on areas like Thumbnail manipulation etc. However there is no "comprehensive" graphics toolkit; one that would incorporate image effects, high-colour screen compression in either LZW or RLE, Sprite and animation and image processing. Pixel/Line/Arc manipulation in odd resolutions etc. Something like that is urgently needed. Many parts of those have been done thanks to the effort of people like Wolfgang or Claus but we're still a long way from being complete. What I concentrate right now is a 2D graphics/games engine that would incorporate many of these things and hopefully in time it will graduate to 3d. That's another reason for me asking about "openess" and exactly why adding up GD2 compatibility to QDOS Classic and/or Minerva is I think urgently needed. >It is interesting that the new capabilities of the QL systems are making >demands on graphics. Have you seen my IFG CD startup animation? (37 Megs).. Now it is available (not yet commercially) for Aurora (256 colours) (with Nasty Hacks) and Mode 33. All of the versions will also take advantage of Thierry's driver CD Audio Capabilities and QPC2's CD Audio commands. I plan on the new version CD to have three sessions. One on a QXL.WIN file, one in ISO9660 format (with saved/restored Headers to ensure maximum compatibility) and an audio track which would provide sound effects :-). Additionally the ISO format track will be readable through the DOS device from QPC2 too. I haven't yet tested the ability of Thierry's driver to read multi-session disks but I don't see why not. If it works I believe it would be the most "multimedia" a QL has ever been (running a QDOSMS variant) Phoebus >-- >Malcolm Cadman
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: 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: 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: 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] 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
[ql-users] Re: PIC/SCR Compression & Sprites
At 07:38 ìì 18/2/2002 +, you wrote: >What are you writing ? Presumably a game of some type :-) No comment :-) >The usual way, despite all your other intentions which are probably >valid, is to only update that part of the screen where new activity >occurs ... and leave the rest alone. The thing is that there is no "standard" way of managing sprites apart from what PE tells us. The problem with that is that (at least I couldn't find it) documentation on how PE handles sprites apart from their format. 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, collision detection and the ability to run as a job that can accept input from pipes (so you can feed the job what do you want the sprite to do on a given level etc..) Of course it would need to be able to handle more than 16 sprites (Ambitious aren't we?) What I think is actually needed, is a form of a graphics only toolkit/library for s*basic and C. (And which would be a good Idea to incorporate something like the Packbits command from the DIY toolkit only with 16 bit / 32 bit capability as Packbits compresses only byte-by-byte which makes it unusable for high-colour) Kinda like the Allegro library on the PeeCee (which unfortunately contains x86 assembly and it's impossible to port else we would be up to our necks in games by now :-) 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: 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: 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 08:59 ðì 18/2/2002 +0100, you wrote: >Phoebus R. Dokos makes some magical things to make me read >} 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... > >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 (at least for the thing I wanna do... -sprites-) The memory there wouldn't matter since you would be only moving a small part of the screen back and forth. Especially in a game-type situation, where movement of sprites can for the most part be anticipated, two or three movements ahead could be precalculated (Most "bad guys" in games move in predetermined positions). A caching of sorts 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
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
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 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
[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] 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] 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 :-)
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 RLE>0) 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
[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
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] 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] 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] 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] 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] 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
[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: 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
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] 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 12:32 ðì 8/2/2002 -0500, you wrote: >Seen this price??? >http://www.ecost.com/ecost/shop/detail.asp?dpno=965874 > >Is this a good $$$ today??? > >-- >Paul Holmgren >Hoosier Corps #33, L-6 >2 57 300-C's in Indy Nope... These are 4x cards... (very very slow) (at least compared to the PQI ones I give.) but nonetheless it's worth it if you want that capacity but can't afford to pay a little extra... (that would be only a little more for you since you're in the US aren't you?) 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
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] 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 + s&h 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:40 ìì 7/2/2002 +, you wrote: >Ok... someone is going to mention 50/60Hz > >I'm waiting. (:O( > >John in Wales Well, that's not really a problem once you replace the PSU and connect your QL to a Monitor :-) 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
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] 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!
[ql-users] List etiquette. (Was: ms-users-and-smalltalk-list)
At 09:14 ðì 6/2/2002 +, you wrote: >Norman's 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] 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: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] 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] 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] BMP2SCR-WIN Add.
At 11:07 ìì 4/2/2002 +0100, you wrote: >On Fri, Feb 01, 2002 at 03:35:10PM -0500, Phoebus R. Dokos wrote: > > 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 :-) > >I can compile it if I get the sources. Oh I know, but it's closed software and that is very very sad indeed I'm working on it though BTW Richard, does gcc compile for different targets? (eg on x86 linux to m68k linux) (I don't see why not especially since we got qdos-gcc) Phoebus >Bye >Richard
[ql-users] Newer Page version (with a little something for Nasta too ;-) plus BMP2SCR-Windows
A slightly edited version of my page is up at: http://www.redoak.net/QL/proforma.html Also a nasty bug on my BMP2SCR windoze program has been corrected and while I was at it, I added the ability for the program to crop automatically or add white (or any other colour that you wish) colour at the edges if the picture is too small. Yesterday in class (Microeconomics is very inspiring honestly :-) I also came up with an algorithm to resize the pictures (currently only in increments of 50% but I'll get round to it) and anotherone for automatic centering... (that's a nice feature)... I am looking someone with a good heart (;- ) to help me make a assembly version on the QL :-) Phoebus P.S. Beg, steal, kill or otherwise do whatever you HAVE TO, in order to get the most useful system resident extension I've seen in the last 10 years... CD is its name and it kicks butt! You need to bug Malcolm Lear to get this (Man! this guy is good!)
[ql-users] Updated pages
Hi all, I updated my provisional page at: http://www.redoak.net/QL/proforma.html It now includes the latest pictures from Nasta, plus some bookmarks to help you go faster down the page :-) Phoebus
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] 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
[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] 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
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: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: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.
