Elite and Frontier on the ST&Blitter chip

[Gunstar]

My question about these games is are they faster on ST's equiped with Blitter chips? I really like both, especially Frontier, but they are quite slow on my STf. I have a spot to upgrade with a Blitter chip, and I will if there is a significant increase in speed for these and other polygon based ST games, as I like to play them alot, but they are a bit too slow.

[Gregory DG]

I guess it would depend on if the game utilized the Blitter. I've only ever played the game on my 1040STe, so I wouldn't know if it's faster. There is still some slow down, especially when approaching a planet or space station.

[Gunstar]

I guess it would depend on if the game utilized the Blitter. I've only ever played the game on my 1040STe, so I wouldn't know if it's faster. There is still some slow down, especially when approaching a planet or space station.

868002[/snapback]

Well, on my ST it's always "slow", even the beginning demo seems to only run at like 2-3 fps, and at some points slow to 1 frame every couple seconds...so I'm guessing that your STE is running it faster for the most part. But I'd still like to know for sure from someone who knows for sure. I will be upgrading to a Blitter sooner or later anyway, but the priority of the upgrade depends on the difference in polygon speeds.

[ijor]

I can't say I know the answer, but I doubt it will be much faster if at all with Blitter. Those program are usually slow because of the 3D computation, not because of video/display speed. Besides, and except for some special type of blits, the Blitter is not much faster than the CPU. Actually, for plain sprite management the CPU can be faster.

 

You can get an idea of the speed with Blitter, by running the game under Steem.

[Goochman]

I wonder how much one of the 16mhz upgrades would help?

[techie_alison]

Why not ask Ian Bell if he knows; http://www.iancgbell.clara.net/elite/index.htm

[Alex H]

I doubt either game will have any speed improvement with a blitter but I don't know that for sure.

 

The blitter is a hardware implementation of the very inefficient A-line draw routines built into the OS. (And is quite a different beast to the Amiga blitter.) Most games didn't use the A-line stuff and used their own much more efficient routines. In general, most games don't benefit from having a blitter installed (unless they're STe specific titles). GEM applications usually run much quicker with a blitter though.

 

I think Elite might have come out before the blitter existed, making it even less likely.

[Gunstar]

I doubt either game will have any speed improvement with a blitter but I don't know that for sure.

 

The blitter is a hardware implementation of the very inefficient A-line draw routines built into the OS.  (And is quite a different beast to the Amiga blitter.)  Most games didn't use the A-line stuff and used their own much more efficient routines.  In general, most games don't benefit from having a blitter installed (unless they're STe specific titles).  GEM applications usually run much quicker with a blitter though.

 

I think Elite might have come out before the blitter existed, making it even less likely.

868090[/snapback]

I was thinking more in the direction of the Blitter doing ANYTHING to help take the load off of the CPU, allowing the CPU itself to run stuff like polygons faster even if it's a side affect of having less to do, therefore allowing what is still does do to be done faster. I thought that some games or other programs may have programmed to check for a Blitter, if one is found to enable it and take some of the load in certain areas off the CPU, making the whole system and subsequently games and other programs that can use it to run faster. I'm sure you are right about Elite not taking advantage of it, but poosibly Frontier and other, newer 3D games may use it for anything, increasing the overall speed for the whole program, I didn't really think the Blitter might directly take over polygonal number crunching or something. Sorry if I seeme dto say the same thing mroe than once, I was just having trouble putting my thoughts into words, since I'm not a programmer, and really don't know the technical specs and exact implementation of the Blitter.

[krupkaj]

I don't know how Elite. But I like Frontier on my Nemesised Falcon. It is much smoother than on ST. So I think it it can benefit from fast CPU. I remember I've seen it also on some accelerated MEGA ST with similar effect as on Falcon.

[Alex H]

I was thinking more in the direction of the Blitter doing ANYTHING to help take the load off of the CPU, allowing the CPU itself to run stuff like polygons faster even if it's a side affect of having less to do, therefore allowing what is still does do to be done faster. I thought that some games or other programs may have programmed to check for a Blitter, if one is found to enable it and take some of the load in certain areas off the CPU, making the whole system and subsequently games and other programs that can use it to run faster. I'm sure you are right about Elite not taking advantage of it, but poosibly Frontier and other, newer 3D games may use it for anything, increasing the overall speed for the whole program, I didn't really think the Blitter might directly take over polygonal number crunching or something. Sorry if I seeme dto say the same thing mroe than once, I was just having trouble putting my thoughts into words, since I'm not a programmer, and really don't know the technical specs and exact implementation of the Blitter.

868207[/snapback]

No no, I understood exactly where you were coming from and it's a very reasonable question.

 

I've just scanned over some of my hardware docs to verify what I was saying (it's been a long time since I programmed the ST) and I was nearly right. In fact the blitter is only a partial hardware implementation of the line-A (not A-line) draw routines.

 

The bottom line is that the blitter only does rectangles. I.e. it's great for filling rectangular areas of the screen and chucking big sprites around but is absolutely no benefit to drawing arbitrary polygons.

 

One of the headaches for ST game programmers was the fact that the screen memory is aligned to 16-pixel chunks on the X-axis. To move a sprite in increments less that 16 pixels requires CPU shift instructions which really slow things down. The usual solution to this was to pre-shift the sprite data - making up to 16 copies of each sprite in RAM so the data is ready prepared to be copied straight to the screen. Whilst this is fast, memory disappears very quickly.

 

The same problem also applies to backgrounds. Scrolling the screen horizontally requires that there are multiple copies of all background tiles in RAM, otherwise the frame rate is hideously slow. Any game wich scrolls the screen horizontally with non-repetative graphics at a decent frame rate is some achievement on the ST.

 

Now the blitter is great because it takes care of all the shift opperations, but from a game programmer's point of view it does more to help with RAM usage than it does for performance. If a game needs to fit in a stock 520ST without blitter anyway, there seems little point in even checking for the blitter's presence. If the blitter had been built in from day one it would be a very different matter. (But still no help for 3D.)

 

Just one final point - the blitter and CPU cannot function at the same time. When the blitter is drawing the CPU is halted. There is a mode where the blitter and CPU take it in turns every 64 clock cycles but this has the same net result as running the both chips at 4MHz - half speed. This all plays havoc with timing critical stuff like sampled sound playback and mid-screen colour palette changes and doesn't do much for performance.

 

Anyway, sorry to ramble on. Hopefully I've explained a little better.

[ijor]

Just one final point - the blitter and CPU cannot function at the same time.

 

This is not exact. They can work at the same time. They just cannot access the bus concurrently. Usually the CPU is accessing the bus all the time (at the very least once per instruction for the prefetch). So typically the CPU is pretty much halted if it cannot access the bus.

 

However bus access is a fraction of the execution time for long shifts, multiplications and specially divisions. So in theory you might arrange code and blits in such a way that you can get quit some good Blitter/Cpu concurrency.

 

But again, even if you could get perfect 100% concurrency, it won't be a significant boost for these games.

[Alex H]

Just one final point - the blitter and CPU cannot function at the same time.

 

This is not exact. They can work at the same time. They just cannot access the bus concurrently. Usually the CPU is accessing the bus all the time (at the very least once per instruction for the prefetch). So typically the CPU is pretty much halted if it cannot access the bus.

 

However bus access is a fraction of the execution time for long shifts, multiplications and specially divisions. So in theory you might arrange code and blits in such a way that you can get quit some good Blitter/Cpu concurrency.

 

But again, even if you could get perfect 100% concurrency, it won't be a significant boost for these games.

868301[/snapback]

 

Oh, right, yes I get you. When the blitter grabs the bus, the CPU can still continue to execute the current instruction to the point at which it next needs to access the bus. So it makes sense to use the blitter whilst doing say a batch of matrix multiplications rather than when moving memory around with movem.l instructions. I'd never thought of that. Seems pretty obvious now. Seems like we've gone way beyond the subject of the original question, but cheers! Might come in handy one day if I start up ST programming again. (Stranger things have happened.)

[Gunstar]

I don't know how Elite. But I like Frontier on my Nemesised Falcon. It is much smoother than on ST. So I think it it can benefit from fast CPU. I remember I've seen it also on some accelerated MEGA ST with similar effect as on Falcon.

868211[/snapback]

Well, I'd probably just be better off getting a TT or Falcon then trying to upgrade my old ST to 16mhz or what ever, I jsut thought that the TT/Falcon's were in compatible with most game software, including the 3D stuff, if Frintier and other 3D stuff like flight simulators, etc. that were made for the ST/STE will work on a Falcon/TT, then I'm more encouraged to lokk into buying one of these machines. From what I'd come to understand was that the new machinges could sitll run most Gem-type applications, but when it came to games it was incompatible 99% of the time if not 100% unless the game was made later and specifically had versions for all the 16/32-bit systems or at least was programmed to be compatible with them all.

[krupkaj]

Frontier, Flight Simulator II and Knight of the sky (maybe other simulators works also) works nice on Falcon. You must switch resolution to ST-Low though. I am not sure about TT. I must try it.

Edited June 10, 2005 by krupkaj

[+Zeptari]

Anyone know where I can find a .pdf of Frontier's manual?

 

-rick

[SofiST]

Most of well written 3D games benefit from faster CPU. And even work good on Falcon in ST low-res mode.

[+CyranoJ]

I wonder how much one of the 16mhz upgrades would help?

 

What an old thread!

 

Anyway, the answer is "a lot" - but probably not much on the MSTE. They're on The D-Bug Website along with approx. 12% of all commercial ST games

[oky2000]

Talking of Blitter chips I remember that when I had both an ST and an Amiga I had this ST emulator (which is a bit of a stretch more like a top level GEM desktop simulation) and that came with a boot disk for the emulator.

 

The boot disk had a program called TurboST on it which turned out to be a software emulator which I copied to a real ST disk and ran it. Boy what a huge difference that was to using things in GEM. Does anyone know where I could possibly get this software blitter from the net to use again?

[techie_alison]

I have it somewhere. The original it is too. Not sure what version it is though.

[oky2000]

Magic

 

I should still have it somewhere, it is a yellow labelled blue DD disk with ST Emu/TurboST written in silver marker on the label in huge letters and the disk is in standard PC 720k format....with the other 5000 or so disk that is

 

edit: I notice the original poster is from NTSC land, would the PAL version of the game allow more CPU time to calculate the polygons over the NTSC version by any chance?

Edited March 29, 2009 by oky2000

[+Stephen Moss]

edit: I notice the original poster is from NTSC land, would the PAL version of the game allow more CPU time to calculate the polygons over the NTSC version by any chance?

I don't know, in theory it should has you have an extra 3mS between VBLs but in reality there is only so much you can do during a VBL and so the programmer probably wrote their code in such a way that it can do everything it needs to within the time of NTSC VBL.

The original poster did not state how much memory their STf had, if it was the stock 512K I don't thinK that was enough as IIRC Frontier really needs 1Meg, I had 2.5Meg in my STfm and AFAIK it run fine on that. I don't know how people can tell what the frame rate is but looking at the screen but I am sure even I would have noticed it slowing to the 2-3 fps as that must have been really jerky.

[oky2000]

edit: I notice the original poster is from NTSC land, would the PAL version of the game allow more CPU time to calculate the polygons over the NTSC version by any chance?

I don't know, in theory it should has you have an extra 3mS between VBLs but in reality there is only so much you can do during a VBL and so the programmer probably wrote their code in such a way that it can do everything it needs to within the time of NTSC VBL.

The original poster did not state how much memory their STf had, if it was the stock 512K I don't thinK that was enough as IIRC Frontier really needs 1Meg, I had 2.5Meg in my STfm and AFAIK it run fine on that. I don't know how people can tell what the frame rate is but looking at the screen but I am sure even I would have noticed it slowing to the 2-3 fps as that must have been really jerky.

 

I have turned up an original NTSC copy of Elite in my collection...and I remember I hacked a PAL version to make my own colour pallette for it (you could edit it in Neochrome ) so if I find that hack I made I could try them both and see now which would be interesting.