Hardware sprites

[h5n1xp]

Hi All,

 

I'm aware the ST has no hardware sprites, so I'm curious as to how GEM generated the mouse pointer? 

[zzip]

3 minutes ago, h5n1xp said:

Hi All,

 

I'm aware the ST has no hardware sprites, so I'm curious as to how GEM generated the mouse pointer? 

It's a software sprite-  basically does everything a hardware sprite would do but doesn't use dedicated hardware to render them-  so it consumes more CPU cycles than a hardware sprite would.     If you have a blitter chip, then that can enhance software sprite rendering.

[TGB1718]

Aline routines, they are built into the OS, there are about 15 of these that do a lot of the

graphics plot/draw/rectangle/polygon drawing etc, one of them is Show Mouse another transform mouse

so you change the mouse to whatever you want,

 

there are also routines to draw and undraw software sprites

[h5n1xp]

Many thanks guys. I guess the GEM drawing routines were synchronised with the pointer drawing then. If it is using the "Save background, Draw sprite, Wait VBL, Clear background" technique then any graphical updates applications made, would need to be carefully timed to void corruption.

 

pseudo code:

do{
    UpdateDesktopGraphics();
    SaveBackground();
    DrawMousePointer();
    WaitVBL();
    RestoreBackground();
}while(forever);

 

 

[Cyprian]

5 hours ago, h5n1xp said:

Many thanks guys. I guess the GEM drawing routines were synchronised with the pointer drawing then. If it is using the "Save background, Draw sprite, Wait VBL, Clear background" technique then any graphical updates applications made, would need to be carefully timed to void corruption.

 

pseudo code:

do{
    UpdateDesktopGraphics();
    SaveBackground();
    DrawMousePointer();
    WaitVBL();
    RestoreBackground();
}while(forever);

actually, drawing of the mouse pointer is done in the VLB code, therefore "WaitVBL()" is not needed and "RestoreBackground()" is done earlier

 

[h5n1xp]

9 hours ago, Cyprian said:

actually, drawing of the mouse pointer is done in the VLB code, therefore "WaitVBL()" is not needed and "RestoreBackground()" is done earlier

Ok, that makes sense the whole mouse pointer drawing could easily be handled in a vertical blanking interrupt, assuming no drawing happens during the raster trace (I'm not sure of the ST's memory timing profile, but I assume it would be similar to the Amiga with the CPU only requiring the bus on the odd cycles, except during a screen draw where the video chip can steal all the cycles).

 

The reason why I'm interested how GEM does this is for my own hobby OS, which (currently) draws the mouse pointer via software since I'm just using the frame buffer provided but GRUB. I am working on a proper (S)VGA driver, which should let me use a real VBL (currently I just fake it with a 16ms timer interrupt), and for it to work I have to synchronise all GUI updates with the mouse drawing code.

 

-Edit- also I might add a GEM theme to my GUI at some point ?

 

-Edit2- Ok, I've just downloaded Hatari (2.3.1), and I notice that using EmuTOS the mouse pointer blanks during the drawing operations! It's been so long since I've used a real ST (I still have Bill Bailey's old music ST in my vintage computer collection, but I've not had time to power it up for well over 10 years) I never realised that it did this!!

Edited September 21, 2021 by h5n1xp

[TGB1718]

Also, there's no need for the SaveBackground as the Draw Sprite routine saves the background in

a user supplied buffer which is then used in the undraw sprite routine to restore the background.

[h5n1xp]

42 minutes ago, TGB1718 said:

Also, there's no need for the SaveBackground as the Draw Sprite routine saves the background in

a user supplied buffer which is then used in the undraw sprite routine to restore the background.

Apologies I wasn't very clear, my pseudo code wasn't meant to be an example of how one would draw a sprite on the ST, but simply the physical steps that need to be undertaken. I'm vaguely aware of the "Sprite" drawing code hidden in the A-Line traps from when I tried to port a game to the ST around 25 years ago, I was just curious how GEM drew it's mouse pointer.

[Justin Payne]

22 hours ago, zzip said:

It's a software sprite-  basically does everything a hardware sprite would do but doesn't use dedicated hardware to render them-  so it consumes more CPU cycles than a hardware sprite would.     If you have a blitter chip, then that can enhance software sprite rendering.

I just watched a video on the blitter and it was mentioned that you generally don't want to use one for moving small amount of memory due to the cycles it would take for setup. What that amount was wasn't defined in the video. I did a quick search for something about this in The Atari Compendium and it looks like the Blitter is used for "The VDI handles raster forms using three commands, vro_cpyfm(), vrt_cpyfm(), and vr_trnfm(). vro_cpyfm() and vrt_cpyfm() are responsible for ‘blitting’ raster images between memory and a workstation." Since the mouse pointer would fall under the VDI, I guess it might used in that process but that doesn't answer the possibly wasted cycles that are required for setup to use the Blitter that the video states is required for using the Blitter. 

 

[zzip]

3 minutes ago, Justin Payne said:

I just watched a video on the blitter and it was mentioned that you generally don't want to use one for moving small amount of memory due to the cycles it would take for setup. What that amount was wasn't defined in the video. I did a quick search for something about this in The Atari Compendium and it looks like the Blitter is used for "The VDI handles raster forms using three commands, vro_cpyfm(), vrt_cpyfm(), and vr_trnfm(). vro_cpyfm() and vrt_cpyfm() are responsible for ‘blitting’ raster images between memory and a workstation." Since the mouse pointer would fall under the VDI, I guess it might used in that process but that doesn't answer the possibly wasted cycles that are required for setup to use the Blitter that the video states is required for using the Blitter. 

 

I don't know the details of when you should/shouldn't use it, but it makes sense that there would be overhead that could make small memory moves a wash (or worse).   But I can say that when you enable blitter for your desktop, it makes a noticeable difference in performance.   It even speeds up text drawing, which is only moving 8 or 16 bytes of data per character.  

[h5n1xp]

3 hours ago, Justin Payne said:

I just watched a video on the blitter and it was mentioned that you generally don't want to use one for moving small amount of memory due to the cycles it would take for setup. What that amount was wasn't defined in the video. I did a quick search for something about this in The Atari Compendium and it looks like the Blitter is used for "The VDI handles raster forms using three commands, vro_cpyfm(), vrt_cpyfm(), and vr_trnfm(). vro_cpyfm() and vrt_cpyfm() are responsible for ‘blitting’ raster images between memory and a workstation." Since the mouse pointer would fall under the VDI, I guess it might used in that process but that doesn't answer the possibly wasted cycles that are required for setup to use the Blitter that the video states is required for using the Blitter. 

 

Curious, but I'm going to give Dr Steve Bagley in that video the benefit of the doubt here, and assume he's keeping it simple for the audience as his explanation isn't entirely correct.

 

I've spent the morning reading about the ST's hardware including the Atari blitter and it seems that it runs in competition with the CPU for RAM cycles, the advantage that it offers over the CPU is that it can perform the memory copy (while simultaneously applying various logic operations) much more efficiently than the CPU can. In such circumstances I would agree that lots of small blits would be very inefficient.

The Amiga's Blitter (which, like most of the Amiga's features, is really just a cleverly modified DMA), also is able to use memory cycles which the CPU can't use, which adds to its efficiency.

 

I would also note that on systems like the ST and Amiga where the pixels are not arranged as bytes (or even sub divisions of bytes), the CPU must perform a lot of reading, shifting, and writing to memory when drawing graphics, where the Blitter can simply perform the same tasks with a few simple memory read/writes.

 

ref:

https://info-coach.fr/atari/hardware/STE-HW.php

Edited September 21, 2021 by h5n1xp

[ijor]

The general consensus is that the Blitter is not very efficient for many operations because of the heavy overhead required. It still can be much faster than the CPU when real time shifting is required, but games and demos can typically use pre shifting. The Blitter can also be very fast for such things as 3D transformations if blitting can be overlapped with CPU computation. Blitter DMA prevents the CPU from performing external accesses, but the CPU can still internally perform divisions and multiplications. This requires some clever and accurate coding to actually take advantage of this.

 

4 hours ago, zzip said:

But I can say that when you enable blitter for your desktop, it makes a noticeable difference in performance.   It even speeds up text drawing, which is only moving 8 or 16 bytes of data per character.  

 

Yes, but this is mostly because TOS code is not very efficient. Some third party VDI and LINE-A replacements can perform as fast as Blitter, or even faster, using pure software.

Edited September 21, 2021 by ijor

[zzip]

25 minutes ago, ijor said:

Yes, but this is mostly because TOS code is not very efficient. Some third party VDI and LINE-A replacements can perform as fast as Blitter, or even faster, using pure software.

Yes I'm aware,   but I've also seen VDI accelerators like Quick-ST which offer a significant drawing boost on their own, but offer an even bigger performance boost when blitter is enabled.

[Cyprian]

On 9/21/2021 at 10:14 PM, ijor said:

The general consensus is that the Blitter is not very efficient for many operations because of the heavy overhead required.

with all due respect for your knowledge and contribution to the Atari world, I see only a few scenarios where the BLiTTER can be beaten by the CPU.

E.g. a really small sprites e.g. 12x12px, or a small number of bytes word aligned and arranged sequentially ("movem" rules).

In other scenarios the BLiTTER can be many times faster than the CPU. e.g. non-sequentially data like interleaved bitplanes plus masking, shifting and ORing.

 

a great example how to use the BLiTTER for sprites is "Metal Slug":

 

Edited September 24, 2021 by Cyprian

[ijor]

21 minutes ago, Cyprian said:

with all due respect for your knowledge and contribution to the Atari world, I see only a few scenarios where the BLiTTER can be beaten by the CPU.

E.g. a really small sprites e.g. 12x12px, or a small number of bytes word aligned and arranged sequentially ("movem" rules).

In other scenarios the BLiTTER can be many times faster than the CPU. e.g. non-sequentially data like interleaved bitplanes plus masking, shifting and ORing.

 

Well, I'm not going to argue with that because I'm definitely not an expert on fast graphic routines. That's why I used the term "consensus", and not a personal statement. But then, why most demos do not use Blitter? Not only that, when you ask them about the Blitter, they claim it is not very efficient.  Again, hence the term consensus. I remember Leonard, with all the demos he coded, talking about that. May be he was wrong, I don't know.

[Cyprian]

29 minutes ago, ijor said:

But then, why most demos do not use Blitter?

 

good question.

In '90 I also was sure it is not so efficient, mainly due to someone told me that and I believed that blindly

After 10 or more years I did some simple tests and I realized that even on the Falcon the BLiTTER can beat the CPU in some cases.

 

IIRC Leonard used the BLiTTER in "WeWere@", Wachu uses it for drawing polygons in "Back to oldschool by Mystic Bytes", DHS demos also use it.

 

Below two more interesting the BLiTTER sprites examples

 

 

 

 

Edited September 24, 2021 by Cyprian

[zzip]

What about this "flying bird" demo that Atari themselves used to show to demostrate the blitter?   It puts a number flapping birds flying across the screen.   On an ST without blitter,  it's a little laggy, but with blitter enabled the animation is very fast and smooth.   A night and day difference.

 

 

 

 

[oky2000]

On 9/27/2021 at 5:33 PM, zzip said:

What about this "flying bird" demo that Atari themselves used to show to demostrate the blitter?   It puts a number flapping birds flying across the screen.   On an ST without blitter,  it's a little laggy, but with blitter enabled the animation is very fast and smooth.   A night and day difference.

 

 

 

 

Do you know where I could find this demo, I think it was called MULTIANI.TOS. Saw this at an Atari show and one of Jack's sons was showing it on the Mega ST explaining it.

 

You can also improve speed by loading in turbo.acc, a software blitter. Yup that's right, somebody came along and replaced all the graphical A-line/Line-A (magazines described it both ways) and speeded up your 520STM GEM applications to almost hardware blitter speeds.

 

Don't have the demo, haven't looked for a few years tbh, both the single and multiple birds animation executable was on the same disk. Was always curious if it would speed it up as much as it isn't in any sort of GEM based screen as such from what I remember. Might have been CP/M 68k .TOS program not a .PRG for all I can remember right.

 

edit: I was also meant to ask was the one I was talking about called TurboST? It's a specific one I had on my 520STM and use with First Word etc for school work.

Edited September 29, 2021 by oky2000
clarity

[zzip]

16 minutes ago, oky2000 said:

Do you know where I could find this demo, I think it was called MULTIANI.TOS. Saw this at an Atari show and one of Jack's sons was showing it on the Mega ST explaining it.

 

You can also improve speed by loading in turbo.acc, a software blitter. Yup that's right, somebody came along and replaced all the graphical A-line/Line-A (magazines described it both ways) and speeded up your 520STM GEM applications to almost hardware blitter speeds.

 

Don't have the demo, haven't looked for a few years tbh, both the single and multiple birds animation executable was on the same disk. Was always curious if it would speed it up as much as it isn't in any sort of GEM based screen as such from what I remember. Might have been CP/M 68k .TOS program not a .PRG for all I can remember right.

I looked online and don't see it, so I've attached my copy of the demo

 

I just tested it with the Line-A accelerator that I have,  Quick ST, and I don't see much of a performance boost, if any.   I guess not all of these accelerators are created equal though.

 

But in general Quick ST will make GEM apps a lot faster.   However, Quick ST + Blitter enabled makes GEM blazing fast.   So the performance gains from the software accelerator and blitter can stack, but again it depends on how they are written.  

multbird.zip

[calimero]

On 9/21/2021 at 9:12 PM, h5n1xp said:

Curious, but I'm going to give Dr Steve Bagley in that video the benefit of the doubt here, and assume he's keeping it simple for the audience as his explanation isn't entirely correct.

 

I've spent the morning reading about the ST's hardware including the Atari blitter and it seems that it runs in competition with the CPU for RAM cycles...

Hi, reading your post I just inspiration to write my conclusion: 

 

[oky2000]

On 9/29/2021 at 8:21 PM, zzip said:

I looked online and don't see it, so I've attached my copy of the demo

 

I just tested it with the Line-A accelerator that I have,  Quick ST, and I don't see much of a performance boost, if any.   I guess not all of these accelerators are created equal though.

 

But in general Quick ST will make GEM apps a lot faster.   However, Quick ST + Blitter enabled makes GEM blazing fast.   So the performance gains from the software accelerator and blitter can stack, but again it depends on how they are written.  

multbird.zip 57.66 kB · 7 downloads

Yeah indeed, and I was counting on my workhorse Mega STE in 16mhz mode + blitter + Turbo ST.acc would be like a dream set up too

 

Many thanks for adding this and saving me looking for it, which I haven't had time to yet as I am doing a one man band double kitchen demolish and new fit project at the minute! 

 

It may be that the demo is not GEM legal routines and some TOS + bespoke 68k ASM code. I should still have my original disk of Turbo ST I used on some weird ST emulator (GEM apps only) and it actually worked and speeded up the emulation amazingly. Was so slow I never bothered to try it with even the single bird demo. 

 

I have had so many of these odd thoughts to try out on camera that are not C64 related that I had to create a separate YT channel lol. But defo a long video all about my MEGA STE I got for dirt cheap but fully loaded (small bit of case damage to 1 or 2 areas) and how good it was for small business/serious work etc with the right specification and trying all sorts of ideas out and what effect they have. I used to write letters and college work on First Word at home, then load them in on some Microsoft PC for printing. Would have loved a Mega STE 4mb setup with the SLM804 Laser back then, my dream set up as I didn't like MACs or PCs at all in the late 80s.

 

 I also plan to play Rescue on Fractalus on my Atari 800XL mint in mint packaging, which I haven't taken out of the box for 12 years, and then after doing an unboxing of my mint sealed cartridge copy which is the only copy I have,  connecting it all up to my DLP projector (120inch image max in this house, booo!) and a nice amp & speakers. I figure in that setup in a dark room it should give quite a boost to the experience and might just make you felt as a kid the first time you saw this game and then tried it out. To be fair as I only had a C64 I should do the same with a tape copy of the C64 game on the same equipment. The ULTIMATE Rescue on Fractalus face-off

[Cyprian]

On 10/2/2021 at 7:36 PM, oky2000 said:

It may be that the demo is not GEM legal routines and some TOS + bespoke 68k ASM code. I should still have my original disk of Turbo ST I used on some weird ST emulator (GEM apps only) and it actually worked and speeded up the emulation amazingly. Was so slow I never bothered to try it with even the single bird demo.

that demo uses a clean TOS routines for a blitting - "Line-A #7". It means it works also without the BLiTTER on a regular ST.

 

 

---EDIT---

I've just checked the performance under the Steem Debugger:

the STE or ST with the BLiTTER: 1VBL

the ST with no the BLiTTER: 2VBL

the ST with QuickST: 1VBL

Edited October 4, 2021 by Cyprian

[+Stephen]

On 9/24/2021 at 5:04 PM, Cyprian said:

Below two more interesting the BLiTTER sprites examples

 

Sorry for the necro-bump.  Can you provide me with the music that was used in that demo?

[Cyprian]

9 hours ago, Stephen said:

Sorry for the necro-bump.  Can you provide me with the music that was used in that demo?

that is not mine, @AnimaInCorpore ca you help @Stephen ?

[AnimaInCorpore]

On 2/14/2023 at 3:19 AM, Stephen said:

Sorry for the necro-bump.  Can you provide me with the music that was used in that demo?

"PUZZLE DREAMS – A contemporary-sounding piece that won’t get in the way of sound effects. Might be nice in a upbeat, non-combative game with lots of motion in it. (:46) Royalty-Free."

 

https://soundimage.org/wp-content/uploads/2017/05/Puzzle-Dreams.mp3