@Maijestro

sent u an update in your mail:)

@smarkusg
Quote:

It is possible. I am not sure though which version of SDL did the v2.5wip used. Because if it was the SDL2, then I guess some changes made it work slower.

Your videos look pretty good. It shows there is a huge difference between SDL v1 and v2. But I am not sure if we can compare them. What I mean is that SDL2 might provide more features in the program and the problem might be somewhere else. For example, grafx v2.8 and v2.9 using both SDL2 have a huge difference. It might be a matter of optimisation.

But your port seems to work pretty well. Unfortunately, Kas1e's changes are not available so you and me could include them. Also, maybe it would make sense to have two releases of the app, one with SDL 1 and one with SDL 2. Then the user can choose which one to use.

@Maijestro

There are no SPE builds that I know of. The fastest way to get one would be if some Tabor owner checked out the latest tag, modified makefile for SPE, perhaps ran some tests and send libSDL2.a to Steffen.

For me it would take some hours to install the needed SDK, clib4 etc. And I cannot test it.

@mdcatdad
EU guarantee is 2 years minimum at no cost for the customer, which includes that the seller has to pay shipping costs in case you have to return the computer for repair, replacement or refund.
Check https://europa.eu/youreurope/citizens/ ... tees-returns/index_en.htm

@eliyahu

I just realized that neither AmigaStore.eu, AmigaKit.fr, or Alinea mention anything about warranty, especially warranty service. If someone goes wrong, do I have to ship the entire computer back to Europe?

Current owners: what does your documentation say on this subject?

@walkero

It is possible that SDL2 versions run slower.
I have rebuilt the 2.9 version under SDL1 for my own needs - it runs fast
Comparison of 2.5wip vs 2.8 SDL2 vs 2.9 SDL1
Tested on Qemu A1.



Most noticeable slowdown with LUA demo (2.5wip version doesn't support LUA but runs a bit slower)
You have a sub-version of SDL2 running, so I don't think it's QEMU's fault. Version 2.8 of SDL2 has an additional problem with fonts at my place.

The developer of GoldenCode “Daytona675x” has currently made available all his developments that have been SPE optimized. Tower57/VoxelBird/VoxelNoid/Battle Squadron/Atomic Bomberman. I have already tried the SPE optimized versions and compared them with the standard versions. It runs very well...

For more information and downloads please visit...

https://www.goldencode.de/?page=2

There is also a video on my YouTube channel.

@kas1e
Quote:If you have a G4 CPU WritePixelArray and useExecCopyMem use AltiVec transferring 128 bits at a time, copy64f the FPU with 64 bits at a time, copy64 probably 2 * 32 bit integers and copy32 32 bit integer accesses.
AFAIK copyToVRAM and copyFromVRAM use AltiVec as well.
Each access to VRAM has PCI overhead, more bits transferred per access results in faster speeds.
The useMemcpy and useExecCopyMem results are much slower than they should be, but I don't know what the problem is.

@Hans
Quote:On Classic Amigas, AmigaOne and Pegasos2 there is no OS DMA copy (graphics (Read|Write)PixelArray(), exec CopyMemQuick(), etc.), only Sam4x0, X1000, X5000 and maybe A1222 have DMA based copy functions.
AFAIK GART is disabled in your drivers on AmigaOne and Pegasos2 as well, therefore no DMA at all.

Depending on the CPU the OS copy functions may use AltiVec on AmigaOne and Pegasos2, but for gfx card VRAM accesses that can only be about twice as fast as FPU based copy functions, if at all.
The DRAM read part of an AltiVec based copy between DRAM and VRAM should be more than twice as fast as a FPU one, but DRAM writes shouldn't make a difference (using DCBA or DCBZ with FPU writes is about the same speed as AltiVec writes using the streaming instructions).

@Rob

Thanks for the link. I'm considering it.

@kas1e

Reads are slower because they involve sending a request to the card, and then receiving the response (i.e., the returned value) from the card. This is inherently slower than shoveling data to the card.

DMA transfers can reduce the overhead by sending data in large blocks, so you need much fewer requests.

Hans

@LiveForIt

I know someone did a Mac on Amiga that was based on Mac on Linux, back in the early 4.0 days, but I never got it working, and I don't even know where my copy is. I suspect it would only work on an A1 G3/4

@328gts

Hi for example I created a new entry and renamed frikingshark and just changed wher the fire buttons (CTRL and leftALT keys in game) are mapped to my gamepad buttons.
So I set/remap to may gamepad (has 12 buttons):
...
Button 1 -> CTRL
...
Button 6 -> LALT

no other entry was changed. Then just laucnhing frykinshark in AmigaInputAnywhere's GUI O keep the frikinshark entry selected.
So during game when on my gamepad a push Button 1 is like I was using CTRL key and same with Button 6 (leftALT)

@Reynolds

No, this won’t work, you need prepare emu or simulate patch, to move AmigaOS3.x out of the way. This patched won’t work on AmigaOS4.x

IFusion never supported real cdroms drives, it only worked with raw cd images. Perhaps flat.device can work, but I never tried.

In the past there was

https://pearpc.sourceforge.net

But the project is abandoned

IFusion PPC I believe...?

@Rob

Not sure it has better specifications Sam460 has only DDR2 memory, it also has a cache coherence problem, this causes a performance problem, something A1222 does not have.

the Sam460 issue is perhaps not as critical, but A1222 issue can be overcome, I find hard to say what system is better or worse.

My biggest problem with A1222, is not the hardware, in the sense its not faulty, its different.
the hardware specifications is not that bad, if you do not consider compatibility.

The difference is the problem, developers must spend time making special version of their software for it, wasting time, they can be using on other things.
And I’m sure users of system will find it a bit annoying, seeing one program running really well, while another being really slow.

Sam460 problem will never improve, you never get DDR3 in software update, or the cache coherence problem fixed, but the A1222 problems will grandly improve as software is released.

@mdcatdad

You can use MacOnLinux, not sure how well it runs, we do not have anything similar for AmigaOS4.
Basilisk II and SheepShaver is technically the same source code however, SheepShaver did run on MSDOS, can be run in DOSBOX perhaps, but I guess it will defeat the point.
On AmigaOS4, you pretty much stuck on 680x0 MacOS7.6.1 or MacOS8.x. as far as I know MacOSX requires a more advanced emulator then MacOS9. MacOS9 can perhaps be made to run, but you need a simple JIT compiler, something to virtualize the address space, so that does conflict with host OS. Basically, it only needs to emulate the reads and writes, everything else can be passed on unchanged.

And believe you need to hack branches and return from jumps. To jump into the correct JIT cache block. Illegal opcode can be used, not sure if needed, changing opcode somewhat easier, as does not change codes relative position, however. All that is nice but will there is register conflict with host OS that’s the next question, so basically it can be done, but it’s not without challenges.

If there will be register conflicts, then there will be more code changes needed, to the JIT cache.

Difficulty somewhere between medium to extremely difficult, time consuming, perhaps not worth it, high level of uncertainty.

If someone did it however, then the same code, can perhaps also be used in EUAE, to improve support for Biazzard PPC / CyberStorm PPC. GameCube etc.

The “dolphin” code does have PowerPC interpreter, advantage of using a interpreter, is it won’t conflict with the host OS, it can be a short cut to getting MacOS9 running, disadvantage it will run lot slower, can’t take advantage of native opcodes.

https://github.com/dolphin-emu/dolphin ... /Core/PowerPC/Interpreter

@mdcatdad
Quote:
I've never tried it but maybe this:
Basilisk 2 from OS4Depot

@All

Did i understand correctly, that on pegasos2 we have PCI slots which is 32-bit ones on 33MHZ, and an AGP one which in reality the same PCI 32-bit one, just not on 33MHZ, but on 66 MHZ, and that all difference ?

If so, then did i get it right, that maximum limit of the PCI bus is 133.33 MB/s , while AGP (in our case PCI 66MHZ one) is 266 MB/s ? I.e. with PCI to PCIe bridge, we can only reach the limits of the PCI bus, which is 133 mb/s ?

What i mean, that i tested for now via gfxbench my Radeon9250 in AGP (so 32bit PCI 66mhz one) slot, and have those results:


Copy from RAM to VRAM:
Transfer size: 16296960 bytes
Src: 0x63c3f000, Dest: 0xc27a4160
copy32: 105.892 MiB/s (took 0.146772 seconds)
copy64: 107.069 MiB/s (took 0.145159 seconds)
copy64f: 135.885 MiB/s (took 0.114376 seconds)
copy64x2: 107.573 MiB/s (took 0.144479 seconds)
copy64fx2: 134.772 MiB/s (took 0.115321 seconds)
copy64fx2PF: 141.174 MiB/s (took 0.110091 seconds)
copy64fx4PF: 140.885 MiB/s (took 0.110317 seconds)
useMemcpy: 53.291 MiB/s (took 0.291645 seconds)
useExecCopyMem: 53.431 MiB/s (took 0.290878 seconds)
copyToVRAM: 207.152 MiB/s (took 0.075027 seconds)
WritePixelArray: 216.664 MiB/s (took 0.071733 seconds).


As far as i can see there, only WritePixelArray almost hit the limit of our AGP (216 mib = ~226mb, while limit is 266). But copy32, copy64 and all that are 2 times slower than a limit.

Is it mean Radeon9250 just can't reach AGP's bus maximum then in some cases ?


Then:

Copy from VRAM to RAM:
Transfer size: 16296960 bytes
Src: 0xc27a4160, Dest: 0x63c3f000
copy32: 37.399 MiB/s (took 0.415567 seconds)
copy64: 35.307 MiB/s (took 0.440196 seconds)
copy64f: 49.172 MiB/s (took 0.316077 seconds)
useMemcpy: 36.144 MiB/s (took 0.429999 seconds)
useExecCopyMem: 35.728 MiB/s (took 0.435004 seconds)
copyFromVRAM: 50.216 MiB/s (took 0.309504 seconds)
ReadPixelArray: 48.550 MiB/s (took 0.320125 seconds).


This one absolutely not hit the limits of AGP, as all the values in 5 times less that the AGP limits.

Is it again, because of Radeon9250 which can't reach AGP limits, or, it's just AmigaOS itself and it's kernel/driver/graphics.library cause issues there ?


Basically, if i got it right, with the PCI bridge in PCI (33mhz) slot we can reach at maximum with does not matter what graphics card we will use, a WritePixelArray of ~130MIB/s maximum , but then, copy from VRAM to RAM can be or the same at worst, or faster till 130mb/s in all tests, as even with Radeon9250 they didn't hit the limits.

Did i understand that all correctly ?

I'm not sure this is the right forum for this but I'd like to be able to view some of my old Macintosh CD-ROMs.

I have Macintosh ROMs from my Emplant software, but I would like to be able to read my Macintosh files and CD-ROMs on a new Power PC-based Amiga