@Heimdall

>Only about 2 weeks ago, on this very forum, I found out the basic stuff about PPC/MorphOS, so I >have literally zero idea about how to get things running there.
>But, it's supposedly still an Amiga ecosystem, so in theory, my RTG code should work there.

I cannot tell you anything about MorphOS, I am not supporting it. As to PPC I support AmigaOS 4 and WarpUP (WarpUP Executables actually run on MorphOS also)

>That sounds intriguing. Do I interpret it correctly that you have a start-up/initialization code that will >work across multiple OS, regardless of it has RTG ? Including PowerPC HW ? Wow, that must have >taken ages to test, debug and patch. I got stuck on library differences just on Vampire alone, let >alone 040/060 OS!

There are basically different versions. One is for 040, one for 060, one for AmigaOS 4 (currently only in source code, not as library, the one for OS4 PowerPC) and one for WarpOS.

And yes, it can do RTG or AGA (a good c2p is used for AGA). Note it is not a standard Amiga shared library, but a "Hyperion DLL" (was fast to implement ). Basically it is an exe which through message ports shares out the memory address of a function implemented in C, and then other program can accept this memory address and call the code found there. Of course as you use a non-standard programming language if I understood it right, no idea if you can call this (usually the library would be called through a linker library for C/C++, which is basically offering

- Function to open the library
- function to close it
- function to request the address of specific functions

You can find the source code here: https://github.com/SteffenHaeuser/magicsoundsystem

(originally it only offered stuff for sound, in meantime screen refresh and mouse/keyboard access has been added).

The c2p I use currently is the one best for 040+, for 030 as far as I understand you would include the Blitter into the c2p'ing, it is a 1x1 c2p.

I have a set of c2p sources which also include such as you mentioned (2x1 etc.), but I never got those running For the game where I was using this ("Secret Project #1") only a 1x1 c2p really makes sense, though (it is not an action game, using 2x1 or whatever would look weird).

Best regards,
Steffen Haeuser
tirionareonwe@gmail.com

@Heimdall

Example on how my code works:

m_screen = MSS_OpenScreen(320,256,8,1,"Secret Project #1");

// Opens a screen of size 320x256 in 8 Bit depth (currently this lib can only do 8 Bit) in fullscreen (that's the "1").


MSS_DrawArray(m_screen,src,x,y,w,h,srcwidth,m_screen->pitch);

// Puts the data from "src" to position x,y with width/height w/h, srcwidth is the width in the src data, pitch is the bytesperrow (no ASM includes currently).

The function will do RTG (CybergraphX, direct access to video ram using LockBitMap stuff) if gfx board screenmode has been found. On AGA it does c2p. If above the fullscreen flag was 0, it uses WriteChunkyPixels instead (for WB Window).

Similar function for closing the screen.

Loading the functions from the lib looks like:

dll_tImportSymbol DLL_ImportSymbols[]=
{
{(void **)&MSS_LoadStreamFromMemory,(char*)"MSS_LoadStreamFromMemory",(char*)"magicsystem.dll",0},
{(void **)&MSS_LoadSample,(char*)"MSS_LoadSample",(char*)"magicsystem.dll",0},
{(void **)&MSS_SetAudioSystemLoaders,(char*)"MSS_SetAudioSystemLoaders",(char*)"magicsystem.dll",0},
{(void **)&MSS_SoundInit,(char*)"MSS_SoundInit",(char*)"magicsystem.dll",0},
{(void **)&MSS_SoundClose,(char*)"MSS_SoundClose",(char*)"magicsystem.dll",0},
{(void **)&MSS_SoundOnOff,(char*)"MSS_SoundOnOff",(char*)"magicsystem.dll",0},
{(void **)&MSS_GetMusicVolume,(char*)"MSS_GetMusicVolume",(char*)"magicsystem.dll",0},
{(void **)&MSS_SetMusicVolume,(char*)"MSS_SetMusicVolume",(char*)"magicsystem.dll",0},
{(void **)&MSS_SetVolume,(char*)"MSS_SetVolume",(char*)"magicsystem.dll",0},
{(void **)&MSS_SetPan,(char*)"MSS_SetPan",(char*)"magicsystem.dll",0},
{(void **)&MSS_IsPlaying,(char*)"MSS_IsPlaying",(char*)"magicsystem.dll",0},
{(void **)&MSS_Play,(char*)"MSS_Play",(char*)"magicsystem.dll",0},
{(void **)&MSS_Stop,(char*)"MSS_Stop",(char*)"magicsystem.dll",0},
{(void **)&MSS_Free,(char*)"MSS_Free",(char*)"magicsystem.dll",0},
{(void **)&MSS_ConvertAudioFormat,(char*)"MSS_ConvertAudioFormat",(char*)"magicsystem.dll",0},
{(void **)&MSS_SetLog,(char*)"MSS_SetLog",(char*)"magicsystem.dll",0},
{(void **)&MSS_GetPlaytime,(char*)"MSS_GetPlaytime",(char*)"magicsystem.dll",0},
{(void **)&MSS_GetLooped,(char*)"MSS_GetLooped",(char*)"magicsystem.dll",0},
{(void **)&MSS_GetSoundOnOff,(char*)"MSS_GetSoundOnOff",(char*)"magicsystem.dll",0},
{(void **)&MSS_LoadStreamToSoundFX,(char*)"MSS_LoadStreamToSoundFX",(char*)"magicsystem.dll",0},
{(void **)&MSS_SetWAVDirectory,(char*)"MSS_SetWAVDirectory",(char*)"magicsystem.dll",0},
{(void **)&MSS_SetLooped,(char*)"MSS_SetLooped",(char*)"magicsystem.dll",0},
{(void **)&MSS_SetStreamThreshold,(char*)"MSS_SetStreamThreshold",(char*)"magicsystem.dll",0},
{(void **)&MSS_GetTicks,(char*)"MSS_GetTicks",(char*)"magicsystem.dll",0},
{(void **)&MSS_AddTimer,(char*)"MSS_AddTimer",(char*)"magicsystem.dll",0},
{(void **)&MSS_RemoveTimer,(char*)"MSS_RemoveTimer",(char*)"magicsystem.dll",0},
{(void **)&MSS_OpenScreen,(char*)"MSS_OpenScreen",(char*)"magicsystem.dll",0},
{(void **)&MSS_CloseScreen,(char*)"MSS_CloseScreen",(char*)"magicsystem.dll",0},
{(void **)&MSS_Flip,(char*)"MSS_Flip",(char*)"magicsystem.dll",0},
{(void **)&MSS_SetColors,(char*)"MSS_SetColors",(char*)"magicsystem.dll",0},
{(void **)&MSS_GetMouseState,(char *)"MSS_GetMouseState",(char*)"magicsystem.dll",0},
{(void **)&MSS_PeepKeyDownEvent,(char *)"MSS_PeepKeyDownEvent",(char*)"magicsystem.dll",0},
{(void **)&MSS_PumpEvents,(char*)"MSS_PumpEvents",(char*)"magicsystem.dll",0},
{(void **)&MSS_PollEvent,(char*)"MSS_PollEvent",(char*)"magicsystem.dll",0},
{(void **)&MSS_FillRect,(char*)"MSS_FillRect",(char*)"magicsystem.dll",0},
{(void **)&MSS_ShowCursor,(char*)"MSS_ShowCursor",(char*)"magicsystem.dll",0},
{(void **)&MSS_LockScreen,(char*)"MSS_LockScreen",(char*)"magicsystem.dll",0},
{(void **)&MSS_UnlockScreen,(char*)"MSS_UnlockScreen",(char*)"magicsystem.dll",0},
{(void **)&MSS_CloseDown,(char*)"MSS_CloseDown",(char*)"magicsystem.dll",0},
{(void *)&MSS_GetWindow,(char*)"MSS_GetWindow",(char*)"magicsystem.dll",0},
{(void *)&MSS_DrawArray,(char*)"MSS_DrawArray",(char*)"magicsystem.dll",0},
{0,0,0,0}
};

if (!dllImportSymbols())
{
fprintf(stderr,"Could not open magicsystem.dll.\n");
exit(0);
}

dllImportSymbols is linked together using a .a file from gcc.

Of course theoretically a library could be made of it, but remember this is just some stuff I did myselves (to be able to use SDL1 in a commercial project I had to make a dynamic library - as SDL1 is LGPL).

The sound function work the way that you basically have a function to load and play a sample in a range of format, and mixing is done automatically by the system, you do not have to implement mixing yourselves. For lowend systems of course only WAV Files make sense, all other soundformats are too slow unless you have really low sample frequencies.

Best regards,
Steffen

@Heimdall

It's a shame the current Amiga parties just can't work together. for example with more planning Aeon/Amiga kit could have delivered the amistore for TheA500 for a bigger reach in the more casual market, along side their own A600/A1200ng platform for the more hardcore fans. & perhaps a store for classic hardware too.

This could have leveraged the casual market & could have been good for the Amiga scene & the game devs. but instead everybody's got fight & piss around forever & not try to grow the platform. its just sad.

@Deaths_Head

Myselves at least i try to support all sorts of different
systems and will have (choosable at installation time)
executable’s for 040, 060, 080, AmigaOS 4 and WarpOS.
Some of my games of course does not run on all but
that is technical reasons (a platform too slow for
a game), not political reasons. Yes, no direct support
For morphos but the licences are usually for AmigaOS
(WarpOS versions will be tested on Morphos though).

Personally i test on OS4, Pistorm, Vampire,
QEmu, UAE and Pi5+Amiberry

Last edited by MagicSN on 15-Feb-2025 at 10:07 PM.

@g.bude

Quote:

g.bude wrote: @kolla I'm sorry, this requirement is out of target of c2p.library c2p.library is dedicated only to classic Amiga chipset.

I must have been unclear, as that was what I was asking: P96 driver for classic Amiga chipset. So, for example chunky PAL/NTSC screen modes, using c2p.library.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

kolla wrote: All the fuzz about 3D - why not start with plain old 2D games on RTG first?

1. It is absurd to require RTG for a 2D game given 2D games run on OCS
2. Nobody would care if the game ran in higher resolution or colors
3. Everybody would ridicule it that it could have ran on OCS
4. There's 3,746 2D games already

It'd be, basically, a wasted effort.

Games I like playing and creating - they don't exist on the platform. It's bringing something new. It's also very exciting and challenging from coding standpoint - to create a fast 3D SW rasterizer in assembler.


Quote:

Jose wrote: I personally like classic shoot em ups like Battle Squadron, not sure I'd be interested in a 3d one with too pixelated graphics

No textures, thus no pixelation. Not even at 640x400 - this is the advantage of flat-shading.
On WinUAE, I play at 1920x1080, with max. distance setting. Very sharp.


Quote:

NutsAboutAmiga wrote: It does not need to be, but you need to make sure it does not cash. So often bugs exist in 680x0 that does not show up unless you run it on more restricted system. AmigaOS4.x will convert 680x0 into JIT cache, as long as game respect bytes per row, support different RGB formats, and or bitmap formats, it should work. as long stick with high level API’s like AHI, picasso96 or cyber graphics. as long as you read keyboard from a window event, and you read the joystick from lowelevel.library

Can you be more specific on what kind of bugs pass undetected on 680x0 systems ?
I'm using lowlevel.library already, but not processing the window events (yet!) - so this is a good reminder, if my goal is to run on as many systems as possible!

@Heimdall

>1. It is absurd to require RTG for a 2D game given 2D games run on OCS

I disagree. I am working on two games which are not 3D games (one of them pseudo-3D). And of course I support RTG. It is not that much work to support both RTG and AGA. And it definitely would run on a OCS system with Graphics Board.

>2. Nobody would care if the game ran in higher resolution or colors

Again I disagree. What I usually call "Secret project #1" here runs in 320x240 or 320x256 on 40 MHz machines, but in 1024x768 on an AmigaOne x1000 (or 800x600 on a Vampire). There is a lot of point for that. Once I will be able to release the information what game it is you will all agree with me that it was a point porting it. And for this wide range of systems.

>3. Everybody would ridicule it that it could have ran on OCS

I do not think so I will be ridiculed once I release my game. I think it will be Amiga game of the year, actually. Think also something like this can run on an A3000 with GFX Board for example (the game I work on obviously would NOT run on a system not able to display 256 colors, on a OCS system it would only run if it has a Graphics Board).

The game I am making definitely could not run on a unmodified OCS (40 MHz 040 and either AGA or a Graphics Board is minimum - but it would run on a 40 MHz 040 system which is an OCS system, if it has a graphics board).

I personally found it silly in the 90s that game companies ignored graphics boards.

>4. There's 3,746 2D games already

Non-3D Games there is a lot of different genres there which are worthwhile to do.

MagicSN

Quote:

kolla wrote: No need for C2P, just target… eh, re-targetable graphics, if it then works an A2000 with 030 board and a old picasso II, great. But if it doesn’t, no big deal.

Well, I already have RTG support, but to cover more machines, I need to be able to support 040/060.
And as this thread made obvious, it better run on 030 (or not bother with C2P at all) ! I'm starting to lean towards the second option right now, just to not miss the June release (otherwise it's not going to happen in 2025 due to my work and traveling that starts in July).

I think I underestimated the effort to make it run on as many Amiga HW permutations as possible


Quote:

g.bude wrote: Feel free to try my c2p.library available on Aminet under MIT license: http://aminet.net/package/dev/misc/c2plib

Thank you! MIT license! Awesome! I'll keep it in mind, but as I currently have 100% of code written on my own, I may want to keep it that way.
I'd probably make an exception if the C2P library had all kinds of versions covering 4-6 different CPUs and 2x1/1x2 combos.
Especially 030 requires separate version of C2P compared to 040 and 060, from what I'm reading in other threads...

@MagicSN

Quote:

MagicSN wrote: @Heimdall >1. It is absurd to require RTG for a 2D game given 2D games run on OCS I disagree. I am working on two games which are not 3D games (one of them pseudo-3D). And of course I support RTG. It is not that much work to support both RTG and AGA. And it definitely would run on a OCS system with Graphics Board. >2. Nobody would care if the game ran in higher resolution or colors Again I disagree. What I usually call "Secret project #1" here runs in 320x240 or 320x256 on 40 MHz machines, but in 1024x768 on an AmigaOne x1000 (or 800x600 on a Vampire). There is a lot of point for that. Once I will be able to release the information what game it is you will all agree with me that it was a point porting it. And for this wide range of systems. >3. Everybody would ridicule it that it could have ran on OCS I do not think so I will be ridiculed once I release my game. I think it will be Amiga game of the year, actually. Think also something like this can run on an A3000 with GFX Board for example (the game I work on obviously would NOT run on a system not able to display 256 colors, on a OCS system it would only run if it has a Graphics Board). The game I am making definitely could not run on a unmodified OCS (40 MHz 040 and either AGA or a Graphics Board is minimum - but it would run on a 40 MHz 040 system which is an OCS system, if it has a graphics board). I personally found it silly in the 90s that game companies ignored graphics boards. >4. There's 3,746 2D games already Non-3D Games there is a lot of different genres there which are worthwhile to do. MagicSN

I actually agree with you, and I play lots of 2D games on various modern platforms myself, but I was writing it from the point of view of Amiga forums I read those statements on.

This forum made me realize that I probably was hanging out on OCS forum, unbeknownst to me, as the prevailing attitude over there was "OCS or BUST"

There's people out there who will argue to death (!) that 68040 and 68060 are NOT AMIGA, and it's same kind of "abomination" as Emulation! WTF ?!?

Heimdall Quote:

Can you be more specific on what kind of bugs pass undetected on 680x0 systems ? I'm using lowlevel.library already, but not processing the window events (yet!) - so this is a good reminder, if my goal is to run on as many systems as possible!

MagicSN is likely referring to the limited "default" MMU protection of AmigaOS 4. I do not own AmigaOS 4 but my understanding is the following.

1. protection of code segments
2. detection and reporting of unused address space
3. default Grim Reaper reporting tool with more info and settings than the 68k Guru

AmigaOS 4 does not use the MMU to protect the following.

1. no process/task isolation but was planned which would have protected private data
2. shared data would have no MMU protection

Everything PPC AmigaOS 4 does with a MMU is possible with 68k AmigaOS 3, a 68k CPU with MMU and 3rd party tools. Thomas "ThoR" Richter has many MMU and debugging related tools including a more powerful MuForce+MuGuardianAngel replacement for the old Enforcer+MungWall which is like Grim Reaper (SmartCrash can be installed if preferring a Guru requestor over console output).

https://aminet.net/package/util/libs/MMULib
https://aminet.net/package/docs/misc/MuManual
https://aminet.net/package/dev/debug/SmartCrash
https://aminet.net/package/dev/debug/SegTracker (used by programs above to locate hits)
https://aminet.net/package/dev/debug/OsGrind (ThoR arg validator if not in MMULib package)

ThoR's tools may be more powerful and flexible than the AmigaOS 4 MMU support but are not as well integrated with AmigaOS 3 making them more difficult to install and use in some cases. ThoR also has a low level 68k debugger called COP but it is not likely to be the first choice for general debugging. I believe the 68k Amiga is better off for debugging as we have more and better debuggers and 68k assembly is much more readable than PPC assembly. For emulation, the WinUAE built in debugger is convenient and is perhaps the most widely used Amiga debugger today. For real hardware, my preference is BDebug in the Barfly package.

https://aminet.net/package/dev/asm/BarflyDisk2_00

The old SAS/C compiler debugger, MonAm debugger and DevPac debugger are powerful and have some advantages as well. There is a plethora of 68k Amiga debuggers as many 68k Amiga games and programs have been disassembled, patched and enhanced. Ask if you need recommendations. I also recommend grabbing a general purpose system monitor like Scout which is useful for debugging resources, stack overflows, etc.

https://aminet.net/package/util/moni/Scout_os3
https://aminet.net/package/util/moni/Scout_os4
https://aminet.net/util/moni/Scout_mos.lha

For monitoring individual function calls there are programs like SnoopDOS and Snoopy. I expect debugging on the 68k Amiga is easier even though PPC AmigaOS "leaders" have been sabotaging 68k Amiga development for years and continue to do so. ThoR's MuForce will keep the Warp3D memory trashing bug from crashing a 68k Amiga but handling the thousands of hits seriously degrades performance and trying to log the hits to memory or a drive can quickly run out of storage space. I was able to successfully debug the 68k Warp3D libraries to fix bugs that had likely already been fixed in the PPC Warp3D libraries. PPC Warp3D suffers from bugs (and poor optimization) that could not be debugged and has kludges like removing indirect rendering which multitasks better and can be faster on the 68k Warp3D.

https://warpclassic68k.blogspot.com/2013/ Quote:

After some tests, indirect mode gives better results for small objects. On the other side, after a number of triangles to draw, the indirect mode gives the same results than the direct mode with our current versions of Warp3D. Alain Thellier has had a good idea to recompile an indirect version of StarShipW3D and CavalleryW3D (available in the "Download" section), and the results are indeed very interresting with my new beta versions of Warp3D and my GRex 1200 (Config 2). ... With my Config 1, I get : o StarShipW3D indirect : 225 fps o StarShipW3D direct : 167 fps o CavalleryW3D indirect : 43 fps o CavalleryW3D direct : 43 fps We have yet a lot of things to understand on Warp3D operations and 3dfx cards with our Amiga....

Indirect rendering works well after the queue datatype handling is optimized, even on ancient 1990s 68k Amiga and 3dfx silicon (this is the indirect rendering queue code I optimized in 68k assembly). Retaining indirect rendering support for compatibility would be preferable but so would retaining 68k AmigaOS compatibility. The PPC AmigaOS way is to drop compatibility at every opportunity and use a scorched earth policy so the masses can not follow the elitist generals and their tiny entourage. It looks to me like it is PPC that has the optimization and debugging problems with difficult to read and debug assembly code. The optimization problem could be fixed with newer silicon but there has not been new PPC silicon for almost 15 years now. Michael Abrash and other programmer's x86 optimizations killed PPC that was rarely optimized. The 68k ISA is better than the x86 ISA but it has been sabotaged by Motorola and continues with A-EonKit/Hyperion to the detriment of these businesses which promote PPC over the 68k. Motorola is now a Chinese business, Freescale is owned by NXP and pays royalties to ARM, Hyperion would be bankrupt again but the 68k AmigaOS saved the business and A-EonKit constant cash injections are the only things keeping the PPC zombie undead.

Heimdall Quote:

Thank you! MIT license! Awesome! I'll keep it in mind, but as I currently have 100% of code written on my own, I may want to keep it that way. I'd probably make an exception if the C2P library had all kinds of versions covering 4-6 different CPUs and 2x1/1x2 combos. Especially 030 requires separate version of C2P compared to 040 and 060, from what I'm reading in other threads...

Mikael Kalms' C2P collection was released into the public domain and is THE standard for C2P code.

https://github.com/Kalmalyzer/kalms-c2p/

Other programmers may use the code for C2P libraries as well as directly in games. Either way, it is better to save the time and not reinvent the wheel.

Heimdall Quote:

There's people out there who will argue to death (!) that 68040 and 68060 are NOT AMIGA, and it's same kind of "abomination" as Emulation! WTF ?!?

I can see making the argument that the Amiga chipset was not designed for the 68020-68060 but the real problem is that Commodore failed to enhance the Amiga chipset to complement the later 68k CPUs, although the AmigaOS was better updated for later 68k CPUs. Commodore really should have considered the 68k Amiga SoC earlier as problems like locked RMW instructions could be solved as they have been on the AC68080. There are internal lines in a CPU that do not make it out to chip pins but would be useful for the chipset. SMP has a better chance of being added with higher Amiga software compatibility to a 68k Amiga SoC than to PPC AmigaOS 4 hardware for similar reasons. The 68k Amiga was designed like later SoCs but was too large to fit on one chip at that time. Well, maybe the chipset could have fit on one chip if using a modern chip fab process at that time. The first Amiga engineer Ron Nicholson was also an Apple employee and said the story that Steve Jobs came to see the Amiga and commented, "too much hardware", was because Apple was trying to create a simplified single chip chipset like the Amiga chipset but failed. A 6502 CPU with the Amiga chipset instead of a 68000 may have allowed a single chip Amiga SoC possible but it would not have been worth it. Jay Miner understood the advantages of the 68000, left Atari because they would not let him create a 68000 Atari computer and would not have created the Amiga without it. Then there are people like Trevor that tossed the 68k at the first opportunity and seems to understand nothing about computers except that they come in big boxes with lots of expansion cards for the desktop and he loves his PPC. If the 68040 and 68060 are abominations then what is PPC?

Nicholson - Amiwest 2024
https://www.youtube.com/watch?v=OvfxbUQVZOk

@matthey

Quote:

If the 68040 and 68060 are abominations

they are not abominations. Motorola simply decided, the instruction set did not scale, so they created ColdFire, back then, I don’t believe JIT was thing, and did not make lot of effort to make it backwards compatible.

AIM (Apple, IBM and Motorola) decided to create PowerPC instruction set to replace 680x0, Apple being part of the alliance quickly added an emulator to the Power Mac Roms, and accelerators for MacOS and AmigaOS came to market. This established the PowerUP and WarpOS, an early attempt to accelerate AmigaOS. With many drawbacks. Like having big context switch issues, like having to flush CPU cache, on task switches.

A few years later, Motorola decided to focus on other markets, so they split up into Freescale (the chipset maker) and Motorola (the company that’s selling walkie talkies), a few years later the company Symbol buys Motorola.

Motorola was successful company becoming a ghost, Motorola was successful company becoming a ghost, the death of 680x0 was also death of many UNIX systems.

Intel on the other hand did not care that there x86 / Pentiums did not scale, instead they developed CPU coolers.

I have no idea, where thinking about mobile market, or PDA’s or laptops, how Motorola looked at future. Clearly, they did not want to go down the same route. In the low end market you had MIPS & ARM, Texas instruments and others.

Last edited by NutsAboutAmiga on 16-Feb-2025 at 09:50 PM.
Last edited by NutsAboutAmiga on 16-Feb-2025 at 09:44 PM.
Last edited by NutsAboutAmiga on 16-Feb-2025 at 09:40 PM.
Last edited by NutsAboutAmiga on 16-Feb-2025 at 09:40 PM.
Last edited by NutsAboutAmiga on 16-Feb-2025 at 09:38 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Heimdall

Quote:

I'd probably make an exception if the C2P library had all kinds of versions covering 4-6 different CPUs and 2x1/1x2 combos. Especially 030 requires separate version of C2P compared to 040 and 060, from what I'm reading in other threads...

Yep, c2p.library uses different conversions for 68020/030 and 040/060, because the first two have too small instruction cache (only 256 bytes) to contains the entire conversion loop.
Starting with 68040, the instruction cache is 4KB.

2x1 and 1x2 are not yet supported, as well of Blitter conversion, but you can 1x2 simply converting 1x1 and doubling the vertical line with a copperlist.

@Heimdall

Quote:

1. It is absurd to require RTG for a 2D game given 2D games run on OCS

It depends on the 2D game.

Diablo (DevilutionX) port's 256 colors 640x480p+ display resolution would be slow on AGA.

Reshoot Proxima 3 runs well on AGA's retro 320×256 resolution.

Unlike in the 1990s, all wedge Amigas have low-cost RTG upgrade pathways. Thus, the majority of Amiga 500 owners can get involved with RTG gaming.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Heimdall

Quote:

I actually agree with you, and I play lots of 2D games on various modern platforms myself, but I was writing it from the point of view of Amiga forums I read those statements on. This forum made me realize that I probably was hanging out on OCS forum, unbeknownst to me, as the prevailing attitude over there was "OCS or BUST" There's people out there who will argue to death (!) that 68040 and 68060 are NOT AMIGA, and it's same kind of "abomination" as Emulation! WTF ?!?

AmigaOS 2.04 was design with 68040 CPU e.g. C= A3000T/040 ECS and recommended AmigaOS version for Amiga 500's 68040-28 / 68040-33 based 3rd party Progressive Peripherals & Software 040-50 accelerator.

Commodore engineer Dave Haynie wanted to design a new Acutiator chipset for 386DX-25 priced 68EC040-25. Commodore management rejected the Acutiator project. A follow-on from AA1000plus's 68EC020-16.

Amiga 500 Rev6's half ECS is majority Amiga model for golden era 1989, 1990, and 1991. Amiga 500 Rev6 has all ECS Agnus upgrades for copper and blitter. Unlike the Amiga 500 Rev 5 PCB design, the Amiga 500 Rev6 motherboard is a full ECS-ready design.

Commodore engineer Paul Lassa briefly considered using the 68060 in a variation of his A4000T.

On integer performance, 68EC040-25 would beat 68030-50 and similar-priced Am386DX-40.

68EC040 @ 25 Mhz (about $105 to $90) + DSP3210 @ 50Mhz (about $30) is a strong value vs performance combination for the 1992 to 1994 time period.

Motorola offered a good value vs performance with 68EC040-25 and it's up to Commodore to design chipset glue for the Amiga.

Dave Haynie's Acutiator targets 68EC040, and at least three other major RISC CPU families e.g. PA-RISC, PowerPC, and MIPS.

Acutiator chipset + 68EC040-25 would add $125 cost on baseline 32bit Amiga.
Acutiator chipset would also support Amiga chipset cards i.e. AA or AAA. Think of CD32 SBC.

The 68EC040 foundation for "power without the price" Amiga can be done when Commodore didn't reserve the price range between baseline Amiga 1200's USD499 and Amiga 4000/030 USD1600 for Commodore's 32bit PC branded clones. Pro x86 PC fools (e.g. Jeff Franks, Bill Sydne) in Commodore gimped the Amiga.

Vampire (AC68080) and PiStorm (soft 68040) weren't the 1st fat 68040+ CPU accelerators for wedge Amigas.

Amiga OCS absolutists are closet anti-Amigans who don't support Amiga progress and support modern non-Amiga platforms. Amiga OCS absolutists are no better than Jeff Franks and Bill Sydne who argued for keeping Amiga ECS while PC gains SVGA.

Unlike Amithlon x86 or neo-Amiga PPC or AROS camps, additional effort was made for PiStorm-Emu68 to respect classic 68k Amiga games while progressing the Amiga platform as a whole.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey


Quote:

Michael Abrash and other programmer's x86 optimizations killed PPC that was rarely optimized.

PPC has architectural issues with ported PC games.

It's time for another X86 vs PPC from BareFeats.

From https://barefeats.com/doom3.html for Doom 3,

MAC GAME PERFORMANCE BRIEFING FROM THE DOOM 3 DEVELOPERS

Glenda Adams, Director of Development at Aspyr Media, has been involved in Mac game development for over 20 years. I asked her to share a few thoughts on what attempts they had made to optimize Doom 3 on the Mac and what barriers prevented them from getting it to run as fast on the Mac as in comparable Windows PCs. Here's what she wrote:

"Just like the PC version, timedemos should be run twice to get accurate results. The first run the game is caching textures and other data into RAM, so the timedemo will stutter more. Running it immediately a second time and recording that result will give more accurate results.

The performance differences you see between Doom 3 Mac and Windows, especially on high end cards, is due to a lot of factors (in general order from smallest impact to largest):

1. PowerPC architectural differences, including a much higher penalty for float to int conversion on the PPC. This is a penalty on all games ported to the Mac, and can't be easily fixed. It requires re-engineering much of the game's math code to keep data in native formats more often. This isn't 'bad' coding on the PC -- they don't have the performance penalty, and converting results to ints saves memory and can be faster in many algorithms on that platform. It would only be a few percentage points that could be gained on the Mac, so its one of those optimizations that just isn't feasible to do for the speed increase.

2. Compiler differences. gcc, the compiler used on the Mac, currently can't do some of the more complex optimizations that Visual Studio can on the PC. Especially when inlining small functions, the PC has an advantage. Add to this that the PowerPC has a higher overhead for functional calls, and not having as much inlining drops frame rates another few percentage points.

(skip)


Doom 3 benchmarks with 1600x1200 resolution and high quality,
Opteron 252 @ 2.6 Ghz with GeForce 6800 Ultra = 78 fps
K8 Athlon FX55 @ 2.6 Ghz with GeForce 6800 Ultra = 76 fps

Dual Xeon @ 3.4 Ghz (Pentium IV uarch) with GeForce 6800 Ultra = 67 fps

PPC G5 @ 2.5 Ghz with GeForce 6800 Ultra = 53 fps (improvement from the initial 34 fps)


https://barefeats.com/mac2pc.html
K8 Athlon FX55 @ 2.6 Ghz with GeForce 6800 Ultra SLI = 106 fps, the CPU can still push the game engine further when the GPU has additional raster performance. Integrated Northbridge helps with SLI scaling.

Dual Xeon @ 3.4 Ghz with GeForce 6800 Ultra SLI = 77 fps (chipset I/O bottleneck)


The problem with BareFeats' 1600x1200 high resolution is shifting the bottleneck towards the GPU's raster.

Quake 3 Area 1600x1200 Max benchmark
Opteron 252 with GeForce 6800 Ultra = 360 fps
PPC G5 with X800 = 355 fps

One of the lead programmers at Id Software (Graeme Devine) took a personal interest in optimizing the Mac version to take advantage of the Power Mac's Velocity Engine and Dual Processors. - BareFeats

Quake 3 was optimized for PowerMac.

https://pcper.com/2004/10/amd-athlon-64-fx-55-and-4000-processor/4/
Quake 3 demo1 with 1024x768 resolution that shifts bottleneck towards the CPU
AMD FX-55 = 512.9 fps
Intel P4 EE @ 3.4 Ghz = 491.7 fps

Quake 3 demo1 with 640x0480 resolution that shifts bottleneck towards the CPU
AMD FX-55 =529.7 fps
Intel P4 EE @ 3.4 Ghz = 502 fps

The purpose of lower-resolution game benchmarks for CPU is to reduce GPU related bottleneck. BareFeats' high-resolution benchmarks hide the PPC being murdered by similar-era X86 CPUs.

The render pipeline is affected by the CPU, I/O chipset, and GPU. AMD K8 has integrated Northbridge.

My reason why I post high fps game benchmark results from the PC world is to keep things in perspective that the modern X86 murders 68K. There is no fight when gloves are off.

-------------
PPC G5,
16 stages with integer instructions
21 stages with floating-point instructions


K8 Athlon FX55,
12 stage pipeline with integer instructions
17 stage pipeline with integer instructions

Despite K8's shorter pipeline on a similar process node, K8 Athlon FX55's clock speed is higher than PPC G5.


https://www.rcrwireless.com/19980727/archived-articles/motorola-amd-to-share-technologies
From 1998, under terms of the seven-year agreement, Motorola will license to AMD its copper interconnect technology and continue to collaborate on developing future logic process technology using the copper interconnects.


https://www.eetimes.com/amd-deal-with-ibm-appears-to-end-earlier-alliances/
AMD and IBM Microelectronics entered into an alliance for 65 and 45 nm process nodes.

Share process nodes between AMD, Motorola, and IBM Microelectronics.

Don't underestimate personnel engineering skills.


Quote:

The PPC AmigaOS way is to drop compatibility at every opportunity and use a scorched earth policy so the masses can not follow the elitist generals and their tiny entourage.

Price vs performance is the major factor e.g. refer to A500's price vs performance during its golden era.


Quote:

The 68k ISA is better than the x86 ISA

It depends on implementation and generation. X86 ISA evolved with 3D game extensions.

X86-64 Level 3 has 256-bit AVX2 FMA3 and it's standard for AMD Zen 2-based PS5-era games. AVX2 can handle integer and floating formats, scalar and vector.

AVX2 FADD FP32 can have 8 FP32 data processing per instruction.
AVX2 FMUL FP32 can have 8 FP32 data processing per instruction.
PS5 semi-custom Zen 2 didn't compromise on AVX MUL unit count.

68K version is 8 scalar instructions.

SSSE3 has critical instruction that is equivalent to PS3's CELL i.e. 16 8-bit element processing.

68K version is 16 scalar instructions.

X86-64's F16C extension has 8 FP16 processing on SSE registers and this is standard from AMD Jaguar (PS4/XBO era) and Intel Ivybridge. This extension is guaranteed to be available on X86-64 Level 3 (PS5/XSX/Steam Deck era and Intel Haswell).

68K version is 8 scalar instructions.

AMD won the contract for PS6 and its at least Zen 4's AVX-512 (X86-64 Level 4 + Intel IceLake extensions). Zen 5 is X86-64 Level 4 + Intel TigerLake extensions.

Last edited by Hammer on 17-Feb-2025 at 04:50 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Heimdall

>I actually agree with you, and I play lots of 2D games on various modern platforms myself, but I was >writing it from the point of view of Amiga forums I read those statements on.

>This forum made me realize that I probably was hanging out on OCS forum, unbeknownst to me, as >the prevailing attitude over there was "OCS or BUST"

>There's people out there who will argue to death (!) that 68040 and 68060 are NOT AMIGA, and it's >same kind of "abomination" as Emulation! WTF ?!?

Have to admit THAT I never saw. And myselves I was getting a 060 back in the 90s (and also a graphics board, and actually stopped buying software which does not support graphics boards back then - had a practical reason - I did not have a monitor which could display chipset screens anymore Didn't have a flickerfixer, but yes, I theoretically could have bought one ).

I think every Amiga forum has a certain clientele. Over here at AW.net I would say there is both PPC/OS4 fans, MorphOS fans, people who are fans of the original chipset etc.

A higher percentage of PPC/OS4 fans (as well as PiStorm fans) you probably get at amigans.net (though you find them here too), and an even higher percentage of OS4 fans at German-language os4welt.de (no surprise, take alone the name), while on MorphZone you will have an extremely high percentage of MorphOS fans. On English Amiga Board I think there will be a lot of fans of the original chipset. And so on...

@matthey

>MagicSN is likely referring to the limited "default" MMU protection of AmigaOS 4. I do not own >AmigaOS 4 but my understanding is the following.

Nothing as deep. I was referring to that if (early in development for example) your game port crashes, on 68k the system reboots - on OS4 you get instead a Grim Reaper with detailed stack trace which makes it much easier to find the reason. Even not taking the stack trace into account, that the system does not reboot gives you much better debugging options.

That is why when doing a new port I start with the OS4 version and then backport it to 68k later.

Also the 68k gcc still has some issues (which the PPC gcc doesn't), especially as to maths code. And when doing a new port you go for the platform where less issues exist first.

Also if for example the PC code uses SDL2 I can compile this directly, while for 68k I have to replace against SDL1 (for a commercial game I replace with my SDL1-replacement-library instead, for licence reasons).

Another issue 68k has is lack of OpenSource libraries. For one going project I will now actually start a Crowdfunding to get the OpenSource Library it will need (Python 2.7) ported to 68k. I am trying my best to support 68k too but sometimes it is much harder ... on OS4 you just HAVE those libraries. From a programmers point of view OS4 is wastly superior. Still try my best to support both.

MagicSN

Last edited by MagicSN on 17-Feb-2025 at 09:43 AM.

@Hammer

>Diablo (DevilutionX) port's 256 colors 640x480p+ display resolution would be slow on AGA.

I can confirm that with a game I currently have in development. 640x480 on AGA was impossible. On 320x256 the game runs fine (assuming 40 MHz 040 at minimum, maybe 33 MHz would also work).

I am BTW using the Kalms c2p collection for AGA.

MagicSN

@Heimdall

Quote:

Heimdall wrote: @agami I hear you, but the games I am creating do not even exist on the system. There's no 5 clones of Stunrunner or Star Wars 32X. The Formula racing game that I spent 2 months creating GearBox physics for and that has OutRun-style terrain/road stripes - but in 3D - that does not exist on Amiga. It's a very different feel than standard 2D Outrun road and it scales phenomenally with higher resolutions - which makes it a perfect candidate for Vampires, PPC, WinUAE and Pistorm. I really, really enjoy playing it on WinUAE at 1920x1080 on my 48" LG OLED TV. The flatshading looks great. It's sharp, there's no pixelation and you can have a fantastic draw distance. Features that never existed on Amiga before. Unlike the grainy ultra-low res affine texturing of PS1-era, this kind of gfx scales very well and is not disturbing for the eye or the brain.

That's great to hear. There is a noticeable hunger for games in the new 68k+ scene (Apollo 080, PiStorm emu68). Don't get me wrong, it's nice that we have seen some ports of open sourced PC games/engines, such as Diablo and Command & Conquer, but many would like to see something new.

I too like racing games, especially fun arcade racing games and kart racing games. One of my all time favorites was the Motorstorm series on the Playstation 3. Gives a good impression of speed and they've even made failing look fun.
It's a genre that on the Amiga hasn't seen any good entries in a while, so I will be among the first the buy your Formula racing game, if it's as good as you say it is.

The key is for it to be fun to play and have replayability. One of the games I can always play on the Amiga is as simple as it gets, but every time it is different, which is Bally. Avoid a couple of dots in your area, while trying to steal area from the other dots.

Another game that was hella fun to play on the OG Xbox was the arcade flyer Crimson Skies. They don't quite make them like that these days.

Looking forward to your games.

_________________
All the way, with 68k

I'm getting new realizations every day with this thread

Since it's obvious to me now that I won't really be able to quit (hope dies last, eh ) my part-time job this year with the release of the game (as explained to me by the current breakdown of the market), I see no point right now to invest in supporting non-RTG systems as all that effort spent would simply mean removing features from the high-end systems (I can only work on one feature at a time).

Meaning, I'd butcher the game for everybody, for no good reason whatsoever, actually !!!

I now know that I can go bonkers with the particle system, explosions and certain lighting effects, as Vampire will be the slowest config. That removes a lot of anxiety on my end



Tomorrow, I'm flying to Europe for 3 weeks, so when I get back, I'll have 16-18 weeks of ~75% full-time coding before my part-time job becomes full-time (at which point the window for release will close till ~December).