Jump to content
IGNORED

Elite must be ported to A8


Philsan

Recommended Posts

Seems a tad slow, though. Looks like the Atmos' CPU was clocked to just 1Mhz, which was almost half that of the Atari and BBC Micro.

 

There are not so huge differences:

 

Oric Atmos - 1MHz

C64 - 1Mhz

Acorn Electron - 2MHz (but access to memory with 1 MHz speed)

BBC Micro - 2MHz

Atari - 1.77 MHz (but remember that ANTIC cut it to about 1.3MHz)

Someone hacked the C64 version to run on the Plus/4 (1.76MHz) if you want an idea of how fast it would run on Atari.

http://plus4world.powweb.com/play/elite

Link to comment
Share on other sites

I agree a 2 color bitmapped graphics mode would be faster than a character based mode and the ANTIC could switch modes for the bottom portion of the screen to keep that part colorful.

 

If the Atari had a 256 pixel wide bitmapped mode that would be fastest. It would keep calculations less than 256 so you don't have to use 16 bit math for everything. 160 pixels wide would have the same advantage but wouldn't look very good.

Link to comment
Share on other sites

Seems a tad slow, though. Looks like the Atmos' CPU was clocked to just 1Mhz, which was almost half that of the Atari and BBC Micro.

 

There are not so huge differences:

 

Oric Atmos - 1MHz

C64 - 1Mhz

Acorn Electron - 2MHz (but access to memory with 1 MHz speed)

BBC Micro - 2MHz

Atari - 1.77 MHz (but remember that ANTIC cut it to about 1.3MHz)

 

It's actually quite a big difference given the architecture of the time. In the real world that could amount to a fair difference. It's no coincidence that several games on the C64 are slower than their Atari counterparts. Much of this would be due to the slower clock speed of the C64.

 

There are other issues, of course, depending on the functionality provided by the other chips in the system (which may increase or decrease the number of operations needed to perform a certain task). But where you have a lot of math then clock speed certainly helps, especially with the 6502.icon_wink.gif

 

Comparing a 3Ghz processor with a 2Ghz one often doesn't really show much difference. Comparing a 1Mhz processor with a 2Mhz one and you'd notice it. One is 50% faster and the other is 100% faster.

Edited by Tickled_Pink
Link to comment
Share on other sites

But where you have a lot of math then clock speed certainly helps, especially with the 6502.icon_wink.gif

Comparing a 3Ghz processor with a 2Ghz one often doesn't really show much difference. Comparing a 1Mhz processor with a 2Mhz one and you'd notice it. One is 50% faster and the other is 100% faster.

 

Well, if it would be CPU in the same computer architecture... maybe. But it is not. Look at xxl's movie. Compare Elite game (needed a lot of math) on Atari (6502 1.3MHz) and BBC Micro (6512 2MHz). The first one is faster... Thus, it seems that CPU clock speed is not superior factor in general computer performance.

Link to comment
Share on other sites

I don't think xxl's video does run faster than the beeb version. I've tried them side by side, pausing the beeb emulation and then letting it go as the video starts the single ship animation again, and the beeb (as I'd expect) looks like it's faster. Unless xxl has started working on converting the line-draws to bitmap mode or the beeb version is calling the ROM PLOT routine (I doubt it but they might) I can't see how an A8 version could be faster.

 

 

Pete

Link to comment
Share on other sites

Does the BBC bitmap work the same as on A8? Can't remember if it is linear or if it's line 0, 8... 1, 9 etc.

 

I benched both way back then... as has been mentioned the BBC runs at 2 MHz, the RAM accesses for graphics are interleaved in the odd cycles with an effective overall 4 MHz speed. I'd also assume that Refresh should be transparent too in that case.

 

 

"If Atari had a 256 pixel mode"

 

- it does. I guess it could be one way to grab the "fastest" crown. Another might be to do it as a 130XE compatible only release and use double-buffering and brute force unrolled loops for a bunch of stuff.

Link to comment
Share on other sites

xxl's video is the ported Apple Elite which runs 20% faster than the native version.

 

Aside, at the weekend I revisited the BBC port and fixed up a few things. Well to do this I found and disabled the check that was causing the ship to overheat! This meant I could better debug my replacement keyboard routine and so then I was able to fly around - very nice to watch another ship float past!

 

After I drove out of the station and turned the ship around and saw nothing was there, I found out that the BBC version loads sections of data relating to the planet (e.g. space station co-ords/vectors for drawing). With this fixed the Lave station was then visible again. :)

 

There are a couple of bits left to patch before I'll post up the next image... mainly that I can't seem to get the different view toggles working, e.g. rear/left/right. Also I'll try and add the console in somehow , for now I think I'll just use the 'select' key to toggle it using a second display list). Hope to do these sometime this week.

 

Regards,

Mark

Link to comment
Share on other sites

xxl's video is the ported Apple Elite which runs 20% faster than the native version.

 

 

What screen mode is the Apple then? I wondered why the chars seemed to be reversed but it still looks like a char based screen so who sped up the Apple code but still drawing to chars? 20% faster would get it closer to the beeb version for sure :) I think xxl actually meant his version ran faster than the C64 hacked to Plus/4 version (could be wrong though).

 

 

Pete

Link to comment
Share on other sites

use double-buffering and brute force unrolled loops for a bunch of stuff.

 

Adding double buffering isn't so difficult with the line drawing because the game maintains two lists of line points that get rendered. As it uses XOR line drawing a line is erased by drawing over itself, so the 'whole' screen area is not erased and then drawn. In switching to double buffering, I think you'd only need to maintain another array for the second screen.

 

The issue is with the overlayed text within the view area, e.g. credit messages. Again not too much of a problem because they XOR as well but these would have to be rendered to both views. IIRC they can blink on and off too and so the extra overhead of this could slow the frame-rate a little.

 

Double-buffering is on my list of things to try at some point though.

 

Mark

Link to comment
Share on other sites

yes, apple2 elite,

 

> What screen mode is the Apple then?

 

antic program:

mode equ $f

antic dta $70,$70,$70

:192 dta $40 + mode, a(apple_ekr + ( ( # % 8 ) * $400 ) + ( ( # % $40 ) / 8 ) * $80 + ( # / $40 ) * $28 )

dta $41,a(antic)

 

so it is pure bitmap and it is faster than char based graphics

 

if someone will rewrite line draw routine.... but Wrathchild work on bbc version.

Link to comment
Share on other sites

xxl's video is the ported Apple Elite which runs 20% faster than the native version.

 

 

What screen mode is the Apple then? I wondered why the chars seemed to be reversed but it still looks like a char based screen so who sped up the Apple code but still drawing to chars? 20% faster would get it closer to the beeb version for sure :) I think xxl actually meant his version ran faster than the C64 hacked to Plus/4 version (could be wrong though).

 

 

Pete

The Apple II series hi-res graphics are bitmapped. But the bit order is the opposite as it draws to the screen and the memory has a really weird interleave that Woz used to compensate for number of gates or something. It makes for some ugly programming. Removing the interleave in the line drawing would speed it up a few % but you probably can't catch the beeb.

After all the line drawing optimization, the bottleneck on the Oric seems to be in the math so MHz is going to be king.

*IF* you went to 256 pixels wide then you could simplify some of the math and optimize the line drawing more.

 

Some additional speed could be gained on the Oric by unrolling a few loops in the line drawing routines but the code size gets out of hand and it may start pushing memory limits. The line drawing has special cases for lines of different angles and you'd have to unroll loops in them all to consistently improve the frame rate.

<edit>

BTW, with some patches, the Oric line routines could be used to replace the Apple ones.

Edited by JamesD
Link to comment
Share on other sites

I thought the weird order on the Apple II was to give you memory refresh for free as part of the screen DMA.

 

Linear mapping should give a quicker line-draw on the A8 than the BBC/C64 method. I was in the early stage of doing an optimised draw (before finding out about even better ones like in "Graphics Gems").

 

The idea I had in mind was to rather than continually updating X/Y positions and then having to do lookups for screen addresses anyway, why not just update the screen address and pixel/masks instead.

Link to comment
Share on other sites

I thought the weird order on the Apple II was to give you memory refresh for free as part of the screen DMA.

That sounds about right... hell I don't know... the last time I read about that stuff or programmed the Apple II series in assembly was 1985.

Linear mapping should give a quicker line-draw on the A8 than the BBC/C64 method. I was in the early stage of doing an optimised draw (before finding out about even better ones like in "Graphics Gems").

 

The idea I had in mind was to rather than continually updating X/Y positions and then having to do lookups for screen addresses anyway, why not just update the screen address and pixel/masks instead.

You can go look at the Oric code for the line routines, it's available for download.

The problem with the Oric is that it's 6 bits / pixel and the top 2 are related to color.

 

Even though the Beeb is slower drawing lines... it's still faster at the math and to beat it I think you'd need to do something there.

 

I was working on line drawing routines for the MC-10 (yeah, totally insane idea) and the 256x192 with 1 bit / pixel screen makes things so simple.

Link to comment
Share on other sites

There are not so huge differences:

 

Oric Atmos - 1MHz

C64 - 1Mhz

Acorn Electron - 2MHz (but access to memory with 1 MHz speed)

BBC Micro - 2MHz

Atari - 1.77 MHz (but remember that ANTIC cut it to about 1.3MHz)

When comparing CPU speed you should take the effective speed:

 

Atari: 1.2 - 1.5 MHz (depending on display list / mode chosen)

C64: 0.95 MHz

Plus4: 1.3 MHz

Edited by Lazarus
Link to comment
Share on other sites

Atari is actually a bit quicker than Plus/4 in default screen mode.

 

Plus/4 has less Refresh (5 vs 9 per line normally), but it has two "badlines" per character row rather than one.

 

Fastest "net speed" of Atari should be ~ 1.63 MHz if screen DMA is disabled on PAL.

Edited by Rybags
Link to comment
Share on other sites

Atari is actually a bit quicker than Plus/4 in default screen mode.

 

Plus/4 has less Refresh (5 vs 9 per line normally), but it has two "badlines" per character row rather than one.

 

Fastest "net speed" of Atari should be ~ 1.63 MHz if screen DMA is disabled on PAL.

Um... yeah... but I don't think that would be the case if you want a color control panel on Elite so it's a moot point for this topic.

 

You can disable the screen refresh on the Plus/4 if I remember right... it would let you run full speed but it wouldn't do you much good. Elite would have a much better frame rate but you couldn't actually see it.

 

On the Tandy CoCo 1/2 you CAN actually disable RAM/screen refresh for a fixed number of clock cycles to run at double speed for part of each frame. But if you don't get the clock cycles right the screen is screwed up and you could loose memory. :twisted:

Link to comment
Share on other sites

You can disable the screen refresh on the Plus/4 if I remember right... it would let you run full speed but it wouldn't do you much good. Elite would have a much better frame rate but you couldn't actually see it.

 

You can turn the screen off and get fill processor speed all the time yes, some decompression schemes do that to get the job done more quickly. What you can also do is shorten the screen vertically (as well as expand it) because the raster register is read/write - you can "lie" to the machine about which scanline it's currently on and it'll take your word for it.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...