That's excellent news Marcel. Total compatibility and a much better
looking PE.
Malcolm
Marcel Kilgus wrote:
> Norman Dunbar wrote:
>
>> Putting aside any new GUIs for the moment, I would thing that your original
>> proposals are a good idea.
>> The caveat must be that the new colour schems
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 Auw
This sounds the very similar to the system I described in an earlier
post. I have used it several times
and it eliminates flicker.
Cheers
Malcolm
Joachim Van der Auwera wrote:
>>> Well some preliminary tests I did through Basic using the Memory Copy
>>> facility of Turbo seem to work fine...
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
Phoebus R.
Hi Dave
I know that William James worked on a sound sampler board, but I'm not
sure if it plugged in the
ROM socket. I'll contact him and find out.
Dave wrote:
> I recall that a couple of years ago someone was working on a sound
> sampler. I think it could sample sound, and play it back. Basic
Hi
I thought this free Coldfire hardware design might be useful.
It looks like a PC104 graphics card should plug in.
http://www.freeio.org/library/toast.htm
Thanks for all the info Per, this is exactly what I was after. Do you
know why d1.l is
labeled x,y pointer coordinates on both input and output?
Cheers
Malcolm
P Witte wrote:
> Wolfgang Lenerz writes:
>
>> On 22 Nov 2001, at 0:38, P Witte wrote:
>>
>>
>>> Im not sure how much of the docum
colm
P Witte wrote:
> Malcolm Lear writes:
>
>> Has anyone got any info on the low level mouse interface in the PE.
>
> I
>
>> assume it must be a
>> documented Trap which returns both absolute pointer position and the
>> relative position since
>&
Thanks Marcel.
Marcel Kilgus wrote:
> Malcolm Lear wrote:
>
>> Has anyone got any info on the low level mouse interface in the PE.
>> I assume it must be a documented Trap which returns both absolute
>> pointer position and the relative position since the last call.
&
Hi All
Has anyone got any info on the low level mouse interface in the PE. I
assume it must be a
documented Trap which returns both absolute pointer position and the
relative position since
the last call. I also need to determine the mouse button status. Any
help would be greatly
appreciated.
Hi
I'll try to talk to William about Speculator, I'm sure he will be quite
happy to release the full version.
I think he may well be surprised at the way the OS has evolved since he
left the scene.
Cheers
Malcolm
[EMAIL PROTECTED] wrote:
> Hi All,
>
> Simon Goodwin is probably the best
with a bit of glue logic?
Cheers
Malcolm
ZN wrote:
> On 9/24/01 at 10:21 AM Malcolm Lear wrote:
>
>>> It's not only the peripherals that are re-used - in fact,
>>> everything but a part of the PCB slightly larger than the
>>> size of the PGA package is
>
> It's not only the peripherals that are re-used - in fact, everything but a
> part of the PCB slightly larger than the size of the PGA package is reused.
> The PCB was designed that way, it has distinct areas that can be
> re-designed as needed. By now it must be obvious why :-)
>
Any chance
I have the documented sources for the CST SCSI hard drive if anyone
requires them.
[EMAIL PROTECTED] wrote:
> On Sun, 24 Jun 2001, Thierry Godefroy wrote:
>
>> Derek, I am right now writing a device driver for CD-ROM drives on Q40/Q60
>> (I think I can announce it "officially" now as things
testing
Malcolm Lear wrote:
> Sorry about te HTML I think I've solved the problem now.
>
> Norman Dunbar wrote:
>
>> Malcolm,
>>
>> Good to know I'm not the only 'sad' person on this list :o)
>>
>&
URL:http://www.LynxFinancialSystems.com
> --------
>
>
> -Original Message-
> From: Malcolm Lear [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 22, 2001 9:18 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [ql-users] NEXT in FOR-loop
>
>
> I'd also be very interested in such an article.
>
>
URL:http://www.LynxFinancialSystems.com
> --------
>
>
> -Original Message-
> From: Malcolm Lear [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 22, 2001 9:18 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [ql-users] NEXT in FOR-loop
>
>
> I'd also be very interested in such an article.
>
>
I'd also be very interested in such an article.
Norman Dunbar wrote:
[EMAIL PROTECTED]">
Too late, deadline is...
Dilwyn - that might be an 'interesting' article actually, well, maybe notCOBOL, but how about something on the internals of Turbo (or QLib). Irememeber an article by Simon Good
Yes rather annoying. I've come across this problem several times. I
quite often
add a small value to n solve it. i.e. INT(n+0.1). I assume its got
something
to do with internal rounding.
Claude Mourier 00 wrote:
> As I see a question about FOR/NEXT loops, I have mine:
> the subsequent p
The attached program converts 24 bit BMP's to QL mode 4/8 and QPC mode 32. The
BMP file must be 512x256 for a standard QL.
Malcolm
P Witte wrote:
000201c0da5f$db1b4680$a62b40c3@gamma">Malcolm Lear writes:
Sorry I think I misunderstood you. I assumed you wanted a program toco
Sorry I think I misunderstood you. I assumed you wanted a program to
convert bitmaps to
QPC hicolour. It would be quite a feat to convert down from 24 bit to 3.
P Witte wrote:
> If theres anything out there that will convert bmp or png to QL pic
> format I must have missed it! Can anyone help?
Find a Sbasic program attached. It's very slow and only works on 24 bit
bmp's.
P Witte wrote:
> If theres anything out there that will convert bmp or png to QL pic
> format I must have missed it! Can anyone help?
>
> Per
>
>
>
>
100 INPUT 'filename ',file_name$
110 l=LEN(file_name$)
12
I for one would certainly use it with QPC and I don't think it perverse to try and move more
away from windows. For me it's development would be the deciding factor on buying a
Q40/60.
Cheers
Malcolm
Dave Westbury wrote:
004301c0abda$b3a61480$0acf7ad5@default">
Phoebus wrote:
Whoever doe
Dave Westbury wrote:
005e01c0a3db$45515fa0$342b073e@default">
I sent a corrected piece of code using two 16 bit 64k lookup tablesas follows.a0 points to RG table and a1 to B.m33RGBmove.w(a4)+,d2 get B0 move.w(a4)+,d3 get RG move.w(a0,d3.w),d3 use lookup t
Dave Westbury wrote:
009b01c0a26d$8cfe87c0$964e073e@default">Malcolm Lear wrote:
Just a thought on speeding things up.How about using a 16 bit lookup table to rearrange the red and green bits somelike this:m33RGBmove.w(a4)+,d2 get B0 move.w(a4)+,d3 get RG
Hi Dave
Just a thought on speeding things up.
How about using a 16 bit lookup table to rearrange the red and green bits some like this:
m33RGBmove.w(a4)+,d2 get B0 move.w(a4)+,d3 get RG move.w(a0,d3.w),d3 use lookup table to sort RG andi.w#$f8
I forgot the positioning of the Blue bits. That would mean another16 bit 64k table.a0 points to RG table and a1 to B.m33RGBmove.w(a4)+,d2 get B0 move.w(a4)+,d3 get RG move.w(a0,d3.w),d3 use lookup table to sort RG move.w(a1,d2.w),d2 also sort B
It would be a real shame to see all that hard work wasted. Is there any
possibility that the
complete design (Gerber files, PLD equations, schematics, etc.) could be
put on a web site
so anybody could get the PCB made up and buy in all the components.
Obviously this
would be an expensive route
It really is attached this time.
100 a=RESPR(1280*1024*3+54):b=RESPR(1280*3*1024):REMark max size
110 LBYTES image.bin,a
120 IF PEEK(a+28)<>24 THEN PRINT 'Not 24 Bit Image':STOP
130 w=PEEK(a+19)*256+PEEK(a+18):h=PEEK(a+23)*256+PEEK(a+22)
135 PRINT w&' '&h
140 n=0
150 FOR y=h-1 TO 0 STEP -1
160
Hi there
Find attached a small program to convert .BMP files to hicolour desktop
format.
I was a little surprised that we still haven't got logical shift
operators >> and <<,
as these would have speeded things up considerably.
Cheers
Try a system reset and running it again. Due to old protection stuff it will complain
if the cadtk.ext is reloaded without a reset. Meanwhile if I have the time it will be
fixed.
Cheers
Malcolm Cadman wrote:
[EMAIL PROTECTED]">In article [EMAIL PROTECTED]"><[EMAIL PROTEC
Hi there
My mistake, sorry. Renaming the file cadtk.bin to cadtk.ext should solve the
problem. QPCII works quite happily with dot extensions.
Malcolm Cadman wrote:
> Has anyone got the PCBCAD program working ?
>
> I have just downloaded it from Dilwyns 'other' page.
>
> The boot file has som
32 matches
Mail list logo
