RE: Re: [ql-users] IDE switch
You can still buy Hot-Swap IDE removable bays but be prepared to pay more than $39 (a lot more) £22.99 SRS-Microsystems, Watford, UK. Quite well built metal caddy with double fan. Not sure if they are designed to be hot-swap; in any case, for data security peace-of-mind (unwritten cache) it would make sense to shutdown the system before swapping devices. Unfortunately, a circuit board between the inner and outer connectors, plus the rear fan makes it about an inch and a half longer than a CD-ROM drive. It won't fit in my Q40 box(AT) because the power supply is too close. Ian. -Original Message- From: webmaster Sent: 20 February 2002 02:01 To: ql-users Cc: webmaster Subject: 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 + pp 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 Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: [ql-users] Re: sprites
I agree completely. The system I described does sometimes suffer from frame shear, but it's nowhere near as objectionable as the flicker from simple sprite redraws. Cheers Malcolm ZN wrote: On 2/19/02 at 8:12 PM Marcel Kilgus wrote: [no way to prefent flicker] Joachim Van der Auwera wrote: Oh yes there is... 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!). Precisely, Marcel is absolutely right. One should also make a difference between flicker and what is called 'frame shear'. Here is an example: a) 16 sprites to draw, by restoring the background then redrawing all 16 sprites in a new place. Effectively, in a short interval of time, there are no sprites on the screen. Suppose that this is what happens: As the screen is traced from top to bottom, the background is first redrawn. If this is fast enough, at some point in the entire screen scan, say right in the middle, the entire background will be restored, and the top half of the screen will show exactly that - no sprites. Next, the sprites are redrawn, however the scanning of the screen continues asynchronously, and the new sprites will not be seen in the top half untill that part is rescanned. You get sprites shown only in the lower half! Now, depending on how fast the drawing process is in comparison with the scanning, you can get all sorts of effects, from flicker, 'banding' horizontal or even slanted bands on the screen where the sprites or the background is visible only), to areas of the screen where the sprites remain invisible - and everything between. It would also change dynamically depending on what else is going on in the system. b) 16 sprites to draw, by precalculation of new positions from background in memory, and updating only the parts of the screen that need to be updated. In this case, as the scan goes from top to bottom, there will bea point up to which the screen will show the 'old' position, and from there on, a point where it will show the new position. If the movement of the sprites is very fast, several updates will occur as the scan of the screen progresses. This is called frame shear, where the diplayed frame frequencey and the update frequency are not the same. The effect is quite common and is actually preferable to the version a) although you can get 'streaking' effects if a sprite moves downn exactly as fast as the scan progresses. Given current hardware (except perhaps the Q40/Q60) this is unlikely. The only way to completely avoid flicker is a screen update that is synchronous with the screen scanning rate, which is usually done using an interrupt that occurs on every vertical retrace (when the screen scan finishes scanning the last - bottom right - pixel). Only original QL hardware can do something like that because the poll interrupt is equivalent to the vertical synch signal, which is a signal generated to tell the monitor to restart tracing of the screen from top left again. As far as I know, no other QL hardware does this. It may be possible (but is probably unduly complex) for QPC to implement tripple buffering, in which case there would not be frame sheer but frame drop or frame jitter effects, which are sometimes preferable but the implementation comes at a very high price. The SSG works as a task linked into the poll interrupt list, controlled through structures in memory that are set up by the basic keywords or calls to the relevant routines in the extension code. If the interrupt driven code is executed fast enough, it will update the screen quickly enough so that the scan will not overtake the update. The scan will therefore always show the current situation, with no frame sheer or flicker or any other artifact. IIRC (it was a long time ago...) the SSG also handles what needs to be updated, transparency, and collision detection using sprite masks. These are one-bit deep structures that define colision boundaries and which sprite pixels should be visible. Also, IIRC the SSG has several modes of operation, and one uses a background reference 'snapshot' to calculate which parts of the screen need to be modified. The modification is performed by pre-calculation and only writing to the actual screen RAM. Something like this would indeed be a nice addition to the screen driver but also a seizable complication once the PE is taken into account. OTOH the PE window save already provides the background reference. While at the subject of the PE - I was always under the impression that: 1) the PE saves the image of the application window, not a background (i.e. what is under the window), except where saving what is
Re: [ql-users] Parallax Scrolling
Phoebus R. Dokos wrote: 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 :-) All drawing on screen should be done as part of an (IIRC) iow.xtop call. This way you ensure that you don't mess up other jobs windows. Marcel
Re: [ql-users] Re: PIC/SCR Compression Sprites
On 19 Feb 2002, at 13:21, Jerome Grimbert wrote: Also, if you intend to foolishly use the same sprite structure, just changing the actual data (not the pointer, but the real data bytes), there is a cache mechanisms which may provide some debugging fun (NOT). Yup, which is why the log in the wall doesn't scroll in high colur mode... Wolfgang
[ql-users] RWAP Software
I am sorry to say I will not be at the Hove show in March but dont forget orders can be placed by snail mail or via Q branch. Best Wishes Rich Mellor RWAP software [EMAIL PROTECTED]
Re: [ql-users] Re: PIC/SCR Compression Sprites
In article [EMAIL PROTECTED], Phoebus R. Dokos [EMAIL PROTECTED] writes 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. Yes, you are right ... so now there is a need, and benefit will be a lot of new and interesting software that makes use of the new systems. 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. No I haven't had the pleasure ... and that is a big file, maybe if it gets put onto a CD at some time I can see the fruits of your work. Although I do recall you describing this late lasy year ( 2001 ). 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) 'Sounds' good :-) Good luck with the work. -- Malcolm Cadman
[ql-users] Hove Workshop
The Dilwyn Jones QL PD Software Library Service and QL CD-ROMs will be at the QL Workshop in Portslade (nr. Brighton/Hove on the south coast of England) on Sunday 3rd March. If anyone wants some PD software disks from me there, to save time at the show I am happy to pre-copy disks ordered by email (catalogue on my website) to be collected and paid for in person at the workshop. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
[ql-users] Lost email addresses
Following the Trader emailshot the following are undeliverable. Help on the correct emails would be appreciated. I get very very few emails from people letting me know their addresses, but the majority on my list have asked to be on it. When people move house, it is an expensive hassle letting everyone know. With emails, it is so easy. Odd. Mind you the list is very much smaller now that the 100 or so I got after the first effort last year! MR GARY M BUSKA [EMAIL PROTECTED] Stan Canton [EMAIL PROTECTED] Andy Barber [EMAIL PROTECTED] Lafe McCorkle [EMAIL PROTECTED] Mr M Jackson [EMAIL PROTECTED] R E Murdoch [EMAIL PROTECTED] Phil Sprotson [EMAIL PROTECTED] Jean charles fouch [EMAIL PROTECTED] David Gilham [EMAIL PROTECTED] Paul Holmgren [EMAIL PROTECTED] Richard Cooke [EMAIL PROTECTED] Herbert Keener [EMAIL PROTECTED] Mike Jonas [EMAIL PROTECTED] Ken O'Donnell [EMAIL PROTECTED] Chris Fowler [EMAIL PROTECTED] David Isaacs [EMAIL PROTECTED] John Sadler [EMAIL PROTECTED] Steve Johnson [EMAIL PROTECTED] albert newell [EMAIL PROTECTED] -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 firstname@surname.demon.co.uk http://www.firshman.demon.co.uk Voice: +44(0)1442-828254Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
[ql-users] RWAP software
I am sorry to say I will not be at the Hove show in March but dont forget orders can be placed by snail mail or viaQ branch. Best Wishes Rich Mellor RWAP software [EMAIL PROTECTED]
Re: [ql-users] Lost email addresses
At 09:09 ìì 20/2/2002 +, you wrote: Paul Holmgren [EMAIL PROTECTED] I know for a fact that Paul Holmgren's address is valid so probably something is wrong with your smtp maybe? Phoebus
Re: [ql-users] Lost email addresses
In article [EMAIL PROTECTED], Tony Firshman [EMAIL PROTECTED] writes Following the Trader emailshot the following are undeliverable. Help on the correct emails would be appreciated. I get very very few emails from people letting me know their addresses, but the majority on my list have asked to be on it. When people move house, it is an expensive hassle letting everyone know. With emails, it is so easy. Odd. Mind you the list is very much smaller now that the 100 or so I got after the first effort last year! David Gilham [EMAIL PROTECTED] I know that this one is no longer valid for David Gilham. When I next see him I will get him to mail you his current one. The info on your mail was very interesting, thanks. -- Malcolm Cadman
Re: [ql-users] Lost email addresses
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-)# I doubt it as about 270 haven't bounced (8-)# OK - I will add Paul back in. Mind you I think he bounced last time too. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 firstname@surname.demon.co.uk http://www.firshman.demon.co.uk Voice: +44(0)1442-828254Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] Lost email addresses
On Wed, 20 Feb 2002 at 21:49:11, you wrote: (ref: [EMAIL PROTECTED]) 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-)# I doubt it as about 270 haven't bounced (8-)# OK - I will add Paul back in. Mind you I think he bounced last time too. He is now [EMAIL PROTECTED] -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 firstname@surname.demon.co.uk http://www.firshman.demon.co.uk Voice: +44(0)1442-828254Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] Hove Workshop
Those of you who are coming to the Hove show and want somewhere to stay might try : The Ship Hotel, Hove, 01273 734936 (twin rooms £55.00) The Kingsway 330, 01273413402 (£25.00 per person) Both had rooms available when I checked today. -- Roy Wood Q Branch, 20 Locks Hill Portslade. Sussex. BN41 2LB. UK Tel : +44 (0)1273 386030 Fax : +44 (0)1273 430501 (New number!) Mobile +44(0)7836 745501 Web : www.qbranch.demon.co.uk
Re: [ql-users] Lost email addresses
At 09:49 ìì 20/2/2002 +, you wrote: On Wed, 20 Feb 2002 at 16:25:05, you wrote: (ref: [EMAIL PROTECTED]) At 09:09 ìì 20/2/2002 +, you wrote: Paul Holmgren [EMAIL PROTECTED] I know for a fact that Paul Holmgren's address is valid so probably something is wrong with your smtp maybe? POP (8-)# Well you know what I meant :-) I am dazed right now thanks to Wolfgang's ASM rendition of my parallax scrolling code :- (So far 4 levels of parallax scrolling). THANKS Wolfgang and YES IT CAN BE DONE ! (Even looks better on my wife's Celeron 433 - No frame shear that is) OK - I will add Paul back in. Mind you I think he bounced last time too.
Re: [ql-users] Hove Workshop
At 11:23 ìì 20/2/2002 +, you wrote: Any shows in Europe after the US show and before the end of June Well say yes! Phoebus
[ql-users] qlay trouble getting qdos files onto _win1
this is 1st attempt at this sort of request-hope its ok want to get progs. files off qdos floppy disks onto _win1 for qlay for windows. I have the tools disk transfer prog. The best I have achieved is a qlay dir. but aside from a 64 byte header there are no files or programs available to qlay on any _win directory. Can anybody point me in the right direction? regards Tony
Re: PIC/SCR Compression (Was:Re: [ql-users] DISP_COLOUR)
On 2/19/02 at 10:29 PM Phoebus R. Dokos wrote: Two screen areas to do double buffering (SCR0 and SCR1) and Auroras have 3 Actually, they don't. They only have the same two... My bad... however that's what happens when you DON'T HAVE THE MANUL (hehehe get the hint ';-))) Well, you have the manual where it says it does not have 3 :-))) (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??? Yes. Maybe even more. It's all just a collection of notes right ow but I'm thinking about a couple of things. Hardware conversion from 1, 2, 3, 4, 8, 16 and 24 bit formats into the actual 16-bit format would be provided, and perhaps some masking. It wouldn't be a true blitter as a full complement of logic operations, and especially a barrel shifter, would just be too much to fit into a cheap enough programmable logic chip. I'm thinking about some tricks using tables in extra RAM, though. BTW: Which bit organization will you maintain? QPC or Qx0 style (or PC style?) (Or something else?) OK, the idea is to have the frame buffer internally always in 16-bit, probably Q40/60 format. The frame buffer is 4M. However, it is accessed through several memory addresses, and depending on which is used, looks differently, but also provides automatic conversion. One address area converts 2-bit QL mode 4 into native 16-bit, the next Aurora 4-bit, then Aurora 8-bit, then there is one where tha actual native 16-bit per pixel memory is accessed directly, and finally, there is an area for 24-bit. Using the GF memory shadow option (and sacrificing 16M of RAM out of 128M) it would even be possible to have ALL modes supported at once, though it would require some added tricks (refresh of the screen) when the mode is changed. As for which kind of native 16-bit is used - there will be a bit in a control register to select wether it's Q40/60 or QPC/QXL, this is quite easy to do. 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? :-))) That would truly be a dream as it would require me to grow two more heads, 4 more arms and come up with several more hours each day, not to mention a trust fund to live off while I do all the work with the extra heads and arms during the extra hours:-)) However... there will be a place for an Analog Devices DSP on board. It will connect to the digital audio interface header on the GF so it's serial ports can use the audio chip as an AD and DA converter (for MP3 and such :-) ), but since it's host port will also be available as a peripheral, given some clever programming, it could certainly do a lot of graphics related stuff (DCT/IDCT for Jpeg, vector and matrix operations for 3D...). Again, puting the chip on there is easy, the programming is the real stumbling block. Nasta
Re: [ql-users] OT: Re: PIC/SCR Compression
On 2/20/02 at 4:27 AM Marcel Kilgus wrote: I can't really answer this without revealing what I'm working on ;-), but anyway there is a general problem: I haven't heard anything from Tony for a long time now, it almost seems that SMSQ/E for QPC is currently the only platform that's still supported. E.g. although my new PE 16bit window shadow code is quite easy to adapt to the Q40, without Tony it will never get integrated there. Which again makes me wonder, what kind of an offer does one have to come up with for Tony to make SMSQ/E open source? Or at least maintainble by someone else... Anyway, having digested what you said about GD2, the conversion of everything to 16 bit is a serious problem (I could use a stronger term). Even applications that use 16-bit color may have large parts of the user interface (menus, borders...) that truly do not need 16 bits per pixel, and many applications do not need it at all. Handling color in a 'largest common denominator' way certainly results in memory waste. IMHO the proper way to do this would be programs in lower modes to still have save areas in that mode. Let me give an example: A program essentially uses mode 4, but now under GD2 they can be chosen from a palette of 65536. All the programs graphic structures are really still in mode 4. When the program's window is on the top of the job stack, the driver can write directly to the screen, in which case it converts 'on fly' from 2 BPP graphical objects using the defined palette, to 16 BPP. At this point two approaches are possible: a) When the window gets burried, a 'reverse palette' conversion into a mode 4 2 BPP save area is performed (This can actually be quite slow). When it gets picked, a 'palette' conversion from the mode 4 save area is performed into the actual screen mode. b) When the driver writes to the screen in the mode the screen uses (16BPP) using on-fly conversion, it also writes to the save area in the mode the program uses (in this case mode 4). AFAIK the routies to handle all hardware supported modes are already there so finding the code that does this should not be a problem, the problem is making it execute both versions for one call. The difference is that a save area is automatically required when the program is running, regardless wether it's window is burried or not. The side-effect is that no save area update is necessary once the program window is burried (in fact, the drivers could happily keep writing into the save area using just mode 4). When the program gets picked again, the save area is palette converted to 16BPP. Approach b) requires one more save area at all times, but guarantees that programs internally using lesser modes only use as much memory for the save areas as they really need. Considering that's a 8-fold saving in most cases it must be worth thinking about? Another thing occurs to me, given the recent discussions on game toolkits. The PE used to handle programs in mode 8 and 4 so that all windows of the same mode would be displayed together. When the cursor would get over an area used by a burried window that is in a mode different than the current mode of the screen, the cursor would show 4 or 8. If that window was picked, the mode was changed and all the windows using a different mode removed. I wonder if this concept is still used, or indeed, if it could be expanded. In particular, give programs the ability to declare a 'user' mode. The point would be to use this for programs that need control of the screen hardware but do not necessairly use the drivers. The standard mode change, screen clear and restore behaviour would be used to prevent such a 'hardware direct' program from corrupting the display by writing out of turn, and other programs from getting to run with the wrong mode selected. A program that would declare user mode would in fact also declare which hardware mode it is using, but the 'user' flag would insure that it gets exclusive use of the display when picked (as if it implied a guardian window the size of the whole screen), no matter if other programs may be using a compatible hardware mode and could in theory be displayed as burried windows. Along with handling games, this would enable programs to support hardware modes that are not yet supported in the screen driver. Nasta
