TerribleFire accelerator for the QL accelerator card

Nagging hardware related question? Post here!
User avatar
Zarchos
Trump Card
Posts: 152
Joined: Mon May 08, 2017 11:49 am

Re: TerribleFire accelerator for the QL accelerator card

Post by Zarchos »

tofro wrote:Not sure how multiply and add help here - I would use it to shift by 8 bits and mask in a lower byte - But that's not the case here. But maybe I simply don't see it.

You can shift out the upper byte of a long by multiplying with 256, then shift back with an expensive instruction - Not much help, but could replace step 3 above, but costing more than the 1.5 units we had there.

BTW I think the "multiply and add" above that Peter referred to was an FPGA function - The m68k doesn't have such an instruction. I would guess Peter uses it to implement the MULx instructions of the 68k (that "only" multiply) and simply adds 0 - always.

Tobias
Please stay in 16 bit screen modes, otherwise my poor brain just can not follow :|
I believe I start seeing my wrong reasoning anyway.
I need to see the MUL and MUL with addition syntax to make sure.
Last edited by Zarchos on Wed Dec 13, 2017 9:02 pm, edited 1 time in total.


Owner of various QLs including accelerated beasts, and also a happy Q68 owner ;)
Now porting SOTB to the Archies, to then port it to the Q68.
https://www.youtube.com/user/Archimedes ... +%28100%25
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: TerribleFire accelerator for the QL accelerator card

Post by tofro »

It's quite simple - a MOVE Dreg, <EA> can either move one byte, one word, or on long word. If you want to move 3 bytes, you can either move a byte, then a word (or vice versa, depending on odd or even address) or a longword. But if you want to move a longword, you need to use a mask - otherwise you are changing one byte in excess.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Zarchos
Trump Card
Posts: 152
Joined: Mon May 08, 2017 11:49 am

Re: TerribleFire accelerator for the QL accelerator card

Post by Zarchos »

tofro wrote:It's quite simple - a MOVE Dreg, <EA> can either move one byte, one word, or on long word. If you want to move 3 bytes, you can either move a byte, then a word (or vice versa, depending on odd or even address) or a longword. But if you want to move a longword, you need to use a mask - otherwise you are changing one byte in excess.

Tobias
OK I'll read about
' But if you want to move a longword, you need to use a mask - otherwise you are changing one byte in excess.
'
then, I didn't know this.

OK I think I read : you are talking about sign extension, are you ?
Last edited by Zarchos on Wed Dec 13, 2017 9:09 pm, edited 1 time in total.


Owner of various QLs including accelerated beasts, and also a happy Q68 owner ;)
Now porting SOTB to the Archies, to then port it to the Q68.
https://www.youtube.com/user/Archimedes ... +%28100%25
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: TerribleFire accelerator for the QL accelerator card

Post by tofro »

Zarchos wrote: Please stay in 16 bit screen modes, otherwise my poor brain just can not follow :|

I would actually rather use 8-bit modes, looks nearly as good to my old eyes and is 100% faster ;)

But the whole thing doesn't look much different in 16-bit modes

Move 3 pixels from sprite memory into screen:

Code: Select all

	; a1 points to screen, a2 to sprite
	move.l (a2)+,(a1)+
	move.w (a2)+,(a1)+
or (using long transfers only, but needs )

Code: Select all

	move.l (a2)+,(a1)+
	move.l (a2)+,d1
	and.l #$ffff0000,d1 ; clear second pixel in register
	and.l #$0000ffff,(a1)  ; clear first pixel in screen
	or.l d1,(a1)+ ; blend in upper pixel
	; move.l (a2)+,(a1)+    ; would actually set two pixels


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Zarchos
Trump Card
Posts: 152
Joined: Mon May 08, 2017 11:49 am

Re: TerribleFire accelerator for the QL accelerator card

Post by Zarchos »

Q68 has only 1 8 bit per pixel screen mode :
http://www.dilwyn.me.uk/q68/manual.pdf

It is
5. 1024 x 768

That makes twice the amount of memory compared to
6. 512 x 384 16 bit per pixel screen mode ...
and even more compared to
2. 512 x 256 16 bit per pixel screen mode ... which to me is the recommended screen mode to use for fast action games

I fear in 1024 x 768 8 bit per pixel, we are quickly going to break the 50 fps and be at 25 fps for arcade games with a moving background ...
From the documentation :
Note: Due to memory bandwidth limitations, using the video modes 3, 5 and 7 slows down the system siginficantly.
The loss of speed is approximately 37%, 28% and 56%. These modes are not recommended
when speed is relevant.

(btw notice the typo in significantly : sthing to correct in the text).


Owner of various QLs including accelerated beasts, and also a happy Q68 owner ;)
Now porting SOTB to the Archies, to then port it to the Q68.
https://www.youtube.com/user/Archimedes ... +%28100%25
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: TerribleFire accelerator for the QL accelerator card

Post by tofro »

Depends on how we see it:

scrolling a 1024 x 768 x 8 screen by one pixel: 780000 bytes moved (close to impossible without jerky movement)
scrolling a 512 x 384 x 16 screen by one pixel: 390000 bytes moved (maybe possible)

putting a 32 x 32 x 8 sprite onto the screen (regardless of resolution): 1024 bytes moved
putting a 32 x 32 x 16 sprite onto the screen (regardless of resolution): 2048 bytes moved.

A scrolling game I would most probably use the smaller screen, one with countless sprites and no scrolling, you'd be better off with the larger screen in 8-bit mode.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Zarchos
Trump Card
Posts: 152
Joined: Mon May 08, 2017 11:49 am

Re: TerribleFire accelerator for the QL accelerator card

Post by Zarchos »

tofro wrote:Depends on how we see it:

scrolling a 1024 x 768 x 8 screen by one pixel: 780000 bytes moved (close to impossible without jerky movement)
scrolling a 512 x 384 x 16 screen by one pixel: 390000 bytes moved (maybe possible)

putting a 32 x 32 x 8 sprite onto the screen (regardless of resolution): 1024 bytes moved
putting a 32 x 32 x 16 sprite onto the screen (regardless of resolution): 2048 bytes moved.

A scrolling game I would most probably use the smaller screen, one with countless sprites and no scrolling, you'd be better off with the larger screen in 8-bit mode.

Tobias
There is a flaw in your reasoning ;-)
in 8 bit per pixel for the same w by h the sprite will appear to be much smaller compared to any mid or low hi res, so if you want to compare, you must compare plotting with same surface visible.
In that case : impossible, to me, on the Q68 in 8 bit per pixel screen mode : too much data to handle, screen + sprites.


Owner of various QLs including accelerated beasts, and also a happy Q68 owner ;)
Now porting SOTB to the Archies, to then port it to the Q68.
https://www.youtube.com/user/Archimedes ... +%28100%25
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: TerribleFire accelerator for the QL accelerator card

Post by tofro »

Depends on the game, definitely - In case you want to have a game with a large screen with lots of bullets and objects flying around (all sprites), you might be better off with the 8-bit mode.

But it actually doesn't matter much - the principle is the same, regardless of whether you're shoving bytes or words around ;)

I would also guess that any code written for one mode could be easily modified for the other.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: TerribleFire accelerator for the QL accelerator card

Post by Peter »

I would definitely use 512x256 or 512x384 resolution and 16 bit colour. Not only less memory expensive, but also 65280 more colours, which allows anti-aliasing and interpolation.
I agree that the colour limitations of 8 bit could be camouflaged - but 16 bit colour allows to write the game in a way that emphasizes the large number of colours, e.g. with a wonderful background picture. (By the way: I wrote a little C program for optimized conversion of 24 Bit raw images to Q40/Q60/Q68 16 bit colour, delivering better visual results. Totally un-optimized, so more useful on PC than Q68 itself.)

Two comments of personal flavour: I'm not looking for high frame rates, 25 fps would be more than I expect or need. The Q68 has 60 Hz vertical refresh, so maybe 15 Hz or 20 Hz makes sense. Also I don't look for high resolutions in a retro arcade game. The QL had 256x256 and was fun, 512x384 would be three times as much already! 512x384 is my personal favorite for the Q68, but 512x256 has the advantage of being also avaliable (and identical) on Q40 and Q60.

A game where the full screen is scrolling, would touch the Q68 at it's weakest point speed-wise, the non-cached access to main memory. Could still be possible, but may not be so rewarding.


User avatar
Zarchos
Trump Card
Posts: 152
Joined: Mon May 08, 2017 11:49 am

Re: TerribleFire accelerator for the QL accelerator card

Post by Zarchos »

You mean : 30 Hz.
Which is interesting when there are scrollings of slices (Shadow Of The Beast), or entire background (Pacmania).
At 25 fps you can notice there's something not quite right.
At 30 fps things run more smoothly.

For 3D, 30 fps is fantastic, and 20 fps is more than acceptable, 15 fps is bearable.


Owner of various QLs including accelerated beasts, and also a happy Q68 owner ;)
Now porting SOTB to the Archies, to then port it to the Q68.
https://www.youtube.com/user/Archimedes ... +%28100%25
Post Reply