Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Performance and Benchmark Results!

Another 68K Coding Challengepage  1 2 

Nixus Minimax

Posts 416
17 Feb 2018 09:48


Gunnar von Boehn wrote:

  The NEO-GEO emulator uses 15bit colors.
 

 
  Ah, okay. In the other coding challenge you wrote:
 
 
Gunnar von Boehn wrote:

  The screen buffer is 16bit hicolor.
 

 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
17 Feb 2018 10:21


Nixus Minimax wrote:

Gunnar von Boehn wrote:

    The NEO-GEO emulator uses 15bit colors.
 

 
  Ah, okay. In the other coding challenge you wrote:
 
 
Gunnar von Boehn wrote:

    The screen buffer is 16bit hicolor.
 


Yes this is correct. The NEO-GEO emulator used to open a 16bit screen but used only 15bit colors.
So one bit was unused all the time.
We changed the emulator to open 15bit screen - this changes nothing on the picture as the used colors were all the time only 15bit.
Now we can use the free bit as mask.




Thellier Alain

Posts 141
19 Feb 2018 14:57


>Reading the background pixel is slow and totally unneeded.

I must explain a few as I was the first to propose to "read the background pixel"
( that IMHO should accelerate some 68k cpus but not the 68080 )

What i was proposing in the other thread  was: using a pointer table (pointer_palette) that contain where is color n.
So color0 is at current screen position and color1 color2 color3 ... color15 are in the palette
So the "read background from the screen bitmap" only occurs for color0 not for all pixels
Of course it add a write/read to pointer_palette for all pixels but as pointer_palette will be certainly in the cache it may still speed up the standard NEO-GEO emulator on non 68080 architectures

Gunnar: You should name that "68080 Coding Challenge" :-)

Alain




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
20 Feb 2018 09:53


thellier alain wrote:

What i was proposing in the other thread  was: using a pointer table (pointer_palette) that contain where is color n.

OK, I understand what you say.
This idea works but it will add the price of an extra pointer fetch.

thellier alain wrote:

  it may still speed up the standard NEO-GEO emulator on non 68080 architectures

 
Yes, but we have to mind that the NEO-GEO emulator is a very costly program. A lot more expensive and CPU intensive than most AMIGA programs. Probably of all AMIGA CPUs only the 68080 has the horse power to run it at sensible speed.



Samuel Devulder

Posts 248
20 Feb 2018 11:27


Gunnar von Boehn wrote:

  This idea works but it will add the price of an extra pointer fetch.

On all amigas, memory access is a slow operation. Always prefer registers. In that algorithm you not only need to fetch the pointer from the cache which may be (relatively) fast, but you still need to update it *for every pixel*. This means that for writing a single pixel you'll have to write the pal pointer as well. So in addition of writing the real data (2bytes), you add 4 more bytes to writes (the pointer). This is 200% extra memory writes. I'd say this is slow, whatever the amiga is.

posts 25page  1 2