@cdimauro

I think extremely likely Commodore probably had to break some rules too, if they had not gone bankrupt in 1994. they would have had no other choice then to innovate, and make none popular changes, anyhow it seams to me memory mapped IO and CPU Cache don’t play well together, keep poking chipset, directly like we do, can huge performance impact on cache. It makes more sense to move away from close CPU control, and move control over to a GPU it makes more sense in the END.

Last edited by NutsAboutAmiga on 18-Sep-2022 at 11:36 AM.
Last edited by NutsAboutAmiga on 18-Sep-2022 at 11:33 AM.

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

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro I think extremely likely Commodore probably had to break some rules too, if they had not gone bankrupt in 1994. they would have had no other choice then to innovate, and make none popular changes,

In fact there were plans for Kickstart 4.0 to introduce RTG. And the AAA chipset was only ECS-compatible, to force developers to use the o.s. instead of banging the hardware.
Quote:

anyhow it seams to me memory mapped IO and CPU Cache don’t play well together, keep poking chipset, directly like we do, can huge performance impact on cache.

Yes, but cache can be controlled by page thanks to the PMMU.
Quote:

It makes more sense to move away from close CPU control, and move control over to a GPU it makes more sense in the END.

Depends on the goals.

@NutsAboutAmiga

Quote:

No you can't on AmigaONE, no chipset, unless you emulate with bitzzen and/or ciaagint or something like that. anyhow probley not safe, as 0xDFF000 can not be reserved.

Have you tried in code? I've noticed ExecSG has some useful looking MMU functions? But don't know if they work for custom chip locations.

In any case, $DFFxxx registers can be trapped. Which is what NallePUH and Blitzen do.

And what CIAgent does to detect $BFxxxx.

Quote:

System friendly means API based on AmigaOS4.x, on AmigaOS3.x it might mean check resources first call OwnBitter() etch.

That can be patched easy for arbitration. Catching the hardware requires patching the system interrupt vector. Be good to know if custom chip registers can be MMU mapped or not as system vector traps any access to custom chip space.

Last edited by Hypex on 18-Sep-2022 at 03:23 PM.

@Hypex

Yes you trap the range, but can you guaranty, no program has allocated that memory.

I think problem with NallePUH, is that it tries to read the emulated 68K registers, instead of just using PPC registers. It’s basically relaying undocumented behavior. I believe its fixable.

but yeh... is it safe?

Last edited by NutsAboutAmiga on 18-Sep-2022 at 03:42 PM.

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

@NutsAboutAmiga: I just saw by case that you edited your previous message and added more stuff. Next time please write a NEW message.

Quote:

NutsAboutAmiga wrote: @cdimauro i created libblitter.library so nice frendly alternative why to call the blitter. https://github.com/khval/Libblitter.library If only there was 68k counterpart, it won’t help a lot, but patch hunk files, to use that, might solve alot.

Your library could be useful only for porting existing Amiga applications (not games, because emulating the Blitter in some way isn't enough and isn't a good idea, because there's the whole chipset to be taken into account: better to completely rewrite the game), but... you need the sources or developers to do it.

Sources usually are in 68k assembly, which is completely different from PowerPC. So, just "transplanting" the relevant Blitter part requires time for the adaptation and it might not be enough anyway for the application to work.

Developers might not be interested because of the same reasons (too much effort.. for which benefits?!?) or because they moved away from Amiga and post-Amiga systems.

To me legacy code which deals with the hardware has already its path: through emulation...

@NutsAboutAmiga

Well, there's always AllocAbs(). But I don't think any program can allocate that memory because it is a reserved space. It sits within 24 bit and all ExecSG addresses are 32 bit wide.

NallePUH does read PPC registers. It needs to as the execption handler needed to be ported to OS4 and it has PPC decoder. It decodes word and long writes as well.

As to being safe? I don't think so because it used to crash on me years ago. I examined the trap code recently and I can see flaws with it. For example, it decodes a hit on a Paula register, and immediately sends it to AHI if the channel is playing.

This is not good, as it's taking hardware writes and sending them to a software layer without checking. For example, if the same value is written to hardware, it's redundant to tell AHI about a zero period or volume change. But it doesn't compare the writes.

Another thing is that module players like MED write weird values in registers that are technically corrupt. For example, when MED starts DMA, it tends to write a $FF00 into the period and volume as zero. I don't know if this is intended but this will start playing a very slow sound at no volume. A couple of interrupts later it fixes it with a proper period and an actual volume. But it should really start the sample when it starts the DMA as a couple of ticks later is off the ticks in the module. Unless it purposedly delays module ticks with the weird values.

NalePUH does emulate audio interrupts though.

@cdimauro

Quote:

“better to completely rewrite the game” it might be a lot more time consuming, well depend on what is, some programs are easier to rewrite as you say if they are not to big complicated. [quote]Blitter in some way isn't enough[/quote [quote]and it might not be enough anyway for the application to work.

That’s true, you usually have copperlist as well, and it takes quite bit time to render, end emulate correct. but I guess it depends on result you’re looking for. Replacing it with modern graphics might look out of place, and remove retro feeling / look.

Maybe don’t need to go that far, maybe it be simulated by proximation, its after all just displaying a few bitmaps on the screen, with some coloring.

Quote:

Sources usually are in 68k assembly, which is completely different from PowerPC.

it’s not a requirement. But It’s actually remarkable easy to write few macros that behaves similar to 68K instructions, so you translate 68k assembler to something that looks similar. It will compile into PowerPC assembler, without huge loss of speed. If you are not good with 68K code, you lot time looking up instructions. It's often easy to make mistakes in the process, and your kind need to debug and find mistakes however, maybe possible to automate, removing human errors. Without automation, that process is as time consuming as writing it from scratch. I agree.

But you can learn a lot in the process from debugging the code, trying to understand it, easier to debug when you’re using the C compiler, at least tool I’m quite familiar with. That’s advantage of doing it that way, at least for me.

Quote:

So, just "transplanting" the relevant Blitter part requires time for the adaptation.

Well the JIT compiler can handle it pretty well without being too CPU intensive, time for adaptation is pretty quick, in that case. If it’s just the blitter that is. That’s the more complicated parts interrupts, understanding code that has no comments, the build system, dealing with someone else code. There better 680x0 coders out there then me, that might not have a problem doing it. but you need to have will and the time to do it.

I guess question is if worth doing, as challenge, as something needed, or some that be fun to have, there has to be motivation a carrot, that you keep motivated to do it.

Last edited by NutsAboutAmiga on 18-Sep-2022 at 06:06 PM.
Last edited by NutsAboutAmiga on 18-Sep-2022 at 05:55 PM.
Last edited by NutsAboutAmiga on 18-Sep-2022 at 05:55 PM.

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

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: “better to completely rewrite the game” it might be a lot more time consuming, well depend on what is, some programs are easier to rewrite as you say if they are not to big complicated. [quote]Blitter in some way isn't enough[/quote [quote]and it might not be enough anyway for the application to work. That’s true, you usually have copperlist as well, and it takes quite bit time to render, end emulate correct. but I guess it depends on result you’re looking for.

If we talk about games, yes: it's way complicated to make them "RTG/AHI/os-friendly", because there might be many tricks used.
Quote:

Replacing it with modern graphics might look out of place, and remove retro feeling / look.

Hum. Depends. I'm interested on enhancing existing games with better graphic and/or music and/or sound effects BUT keeping the existing mechanics (game play).
Quote:

Maybe don’t need to go that far, maybe it be simulated by proximation, its after all just displaying a few bitmaps on the screen, with some coloring.

Eh! Not that simple, because the Amiga used bitmaps and tricks to make some special effects (for example, changing colors to characters on games like Street Fighter II).
Quote:

Quote: Sources usually are in 68k assembly, which is completely different from PowerPC. it’s not a requirement. But It’s actually remarkable easy to write few macros that behaves similar to 68K instructions, so you translate 68k assembler to something that looks similar. It will compile into PowerPC assembler, without huge loss of speed. If you are not good with 68K code, you lot time looking up instructions. It's often easy to make mistakes in the process, and your kind need to debug and find mistakes however, maybe possible to automate, removing human errors. Without automation, that process is as time consuming as writing it from scratch. I agree.

I think that writing a 68k assembler which generates PowerPC (or x86, x64, ARM, etc.) assembly (or directly binaries) would be easier and more general and much more useful.
Quote:

But you can learn a lot in the process from debugging the code, trying to understand it, easier to debug when you’re using the C compiler, at least tool I’m quite familiar with. That’s advantage of doing it that way, at least for me.

Yes, it could be interesting... for reversers.
Quote:

Quote: So, just "transplanting" the relevant Blitter part requires time for the adaptation. Well the JIT compiler can handle it pretty well without being too CPU intensive, time for adaptation is pretty quick, in that case. If it’s just the blitter that is.

Ah, ok. So you say that the 68k should be kept as it is and only the Blitter code should be changed to use your library. Then this special 68k binary could be JITed by the host platform AND the Blitter code could work well because no custom registers are hit.

Yes, it works. But, again, who'll do it?
Quote:

That’s the more complicated parts interrupts, understanding code that has no comments, the build system, dealing with someone else code. There better 680x0 coders out there then me, that might not have a problem doing it. but you need to have will and the time to do it.

Indeed.
Quote:

I guess question is if worth doing, as challenge, as something needed, or some that be fun to have, there has to be motivation a carrot, that you keep motivated to do it.

There are manu people which has fun doing it. Especially on EAB.

A small update.

One of the EAB regulars has created a version of the engine that tries to limit the framerate on UAE and also keep the animation speed linked to the VBL. Only the lighting and basic rotation animations are synced this way (so many animations are still too fast) but it shows a lot of promise.

I don't think this level has ever been played this smoothly https://youtu.be/zEivcIx14z0

The occasional drops and dodgy audio are mostly a capture issue.

Last edited by Karlos on 20-Sep-2022 at 06:01 PM.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

If we talk about games, yes: it's way complicated to make them "RTG/AHI/os-friendly", because there might be many tricks used.

We saw this in the latter days so it is possible. RTG versions and AHI support. Mostly for games that were 3d or simple 2d scrollers. So didn't rely on any Amiga chipset features.

But it used to break. Whatever AHI was used for is limited. Most programs still banged Paula. And most module players still banged the hardware as well. Selecting AHI in the game GUI was meaningless if the game didn't use AHI for audio or module playback. Foundation lets you pick AHI, but it is a lie, as it doesn't use any AHI module player and bangs hardware.

I had a go at writing a game engine that supported OS3 68K up to OS4 PPC transparently. I got it working well enough but it was rather too slow to load. A friend did the assets and rendered all the game objects at his screen resolution so it took a while on 68K. And that 68K was my A4000. I used datatypes to load them in and scale to fit. And only used graphics.library functions to render on screen. So, my code is transparent and doesn't need P96/CGX, as I wrote it to use only OS functions that are upwards compatible. Apart from AHI that is. And it was able to display a scrolling background and move some sprites around.

@Karlos

Quote:

Karlos wrote: A small update. One of the EAB regulars has created a version of the engine that tries to limit the framerate on UAE and also keep the animation speed linked to the VBL. Only the lighting and basic rotation animations are synced this way (so many animations are still too fast) but it shows a lot of promise. I don't think this level has ever been played this smoothly https://youtu.be/zEivcIx14z0 The occasional drops and dodgy audio are mostly a capture issue.

That's basically how Doom was implemented: the game has "business logic" at a fixed rate (AFAIR 60 FPS) while the rest is running at whatever the system could achieve.


@Hypex

Quote:

Hypex wrote: @cdimauro Quote: If we talk about games, yes: it's way complicated to make them "RTG/AHI/os-friendly", because there might be many tricks used. We saw this in the latter days so it is possible. RTG versions and AHI support. Mostly for games that were 3d or simple 2d scrollers. So didn't rely on any Amiga chipset features. But it used to break. Whatever AHI was used for is limited. Most programs still banged Paula. And most module players still banged the hardware as well. Selecting AHI in the game GUI was meaningless if the game didn't use AHI for audio or module playback. Foundation lets you pick AHI, but it is a lie, as it doesn't use any AHI module player and bangs hardware. I had a go at writing a game engine that supported OS3 68K up to OS4 PPC transparently. I got it working well enough but it was rather too slow to load. A friend did the assets and rendered all the game objects at his screen resolution so it took a while on 68K. And that 68K was my A4000. I used datatypes to load them in and scale to fit. And only used graphics.library functions to render on screen. So, my code is transparent and doesn't need P96/CGX, as I wrote it to use only OS functions that are upwards compatible. Apart from AHI that is. And it was able to display a scrolling background and move some sprites around.

The point is: how much it costed using AHI and graphics.library in terms of CPU and memory usage?

That made the difference on the original Amigas...

@Karlos

Is this playable on a 'real' Amiga yet? I now have a copy of Amiga Forever so I guess I should try it on FS-UAE using the preconfigured emulators on the disc?

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

Try it. The mod is playable on a real Amiga because it was originally built on one. It's the executable that may have issues. Just use your original TKG executable if you have to (TKG turbo patch recommended).

_________________
Doing stupid things for fun...

@cdimauro

Quote:

The point is: how much it costed using AHI and graphics.library in terms of CPU and memory usage? That made the difference on the original Amigas...

Well, using the OS to display Amiga features can give an answer to that, like an art package. There's an extra software layer using OS routines but the OS still programs the hardware. Obviously poking hardware directly will be faster than working with functions in a multitasking environment.

And unless it's from boot the OS will use more memory. Especially launching games from Workbench. RTG helps if it conserves chip memory. Or installing chip saving patches. There is even a native RTG driver installing screenmodes for the purpose of conserving chip ram. At that point it's more practical for applications than for games.

The idea of using OS and drivers for RTG and audio is best suited to a performance setup. In late Amigas when things got complicated. Not only contending with different CPU models which needed support libraries active but also RTG screens and other sound cards. But, except for early models, sounds cards rarely had hardware channels and a proper AHI driver supporting hardware channels. Which made the combination unlikely. Even with Paula the proper AHI mode was needed or AHI would soft mix. So no wonder Paula was still used directly. Even using audio.device to play sounds became uncommon.

@Karlos

Where do I get the executable? Didn't Team17 offer all their games as freeware? Dream17?

Last edited by BigD on 21-Sep-2022 at 05:08 PM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Hypex

Many of graphic library functions cares about clipping, and they use pens, and the why pens colors / palette where implemented is pretty idiotic with 64bit RGB value, instead of the std 32bit value, all of that effects speed.

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

@BigD

It's probably in the original source release somewhere tbh

You should be able to get the mod from my repo as a zip file and run in UAE / amiga forever. Set it up as 3.1 or similar, 68040 or 68060. If it doesn't work immediately, go to UAE's memory config and add a dollop of "32-bit chip RAM".

Last edited by Karlos on 21-Sep-2022 at 05:43 PM.

_________________
Doing stupid things for fun...

@NutsAboutAmiga

SetRGB32() and friends. Yes that was a rather strange decision by Commodore. When a SetRGB8() was a more practical and logical step up. Supposedly Commodore had somehow predicted that computer graphics would go beyond the 8bit barrier and that each gun would be up to 32 bits wide in advanced hardware. This means each pixel would be 128 bits wide each! I cannot fathom how they came to this decision.

Their own hardware was only 8 bits on AGA. And AFAIK no Amiga display cards go beyond it. Even today 32 bit pixels are still the most common at 8 bits per gun. What were they thinking?

Perhaps it is surprising now they didn't update audio.device to play 32 bit integer and 64 bit float samples. Not supported by Paula. But the norm now in sample processing. Right up their alley.

@Hypex

In their defence the idea of using high precision gun values isn't that insane. Modern hardware supports pixel data formats up to 32-bit float per gun for HDR image processing and using display buffers with more than 8-bits per gun isn't uncommon today.

_________________
Doing stupid things for fun...

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hypex Many of graphic library functions cares about clipping, and they use pens, and the why pens colors / palette where implemented is pretty idiotic with 64bit RGB value, instead of the std 32bit value, all of that effects speed.

Even worse: it was 96bit RGB (3 x 32bit).


@Karlos

Quote:

Karlos wrote: @Hypex In their defence the idea of using high precision gun values isn't that insane. Modern hardware supports pixel data formats up to 32-bit float per gun for HDR image processing and using display buffers with more than 8-bits per gun isn't uncommon today.

Yes, but we have different APIs for that, which evolved during the time according to the specific needs.

Exposing a single API which required 32-bit integer per color component was a complete waste of resources (memory AND CPU which has to deal with it).

Only Commodore engineers made it possible...