@Rob

The CD tray is more curved than I remember but yeah, that was it ..

Last edited by Karlos on 08-Jan-2024 at 09:49 AM.

_________________
Doing stupid things for fun...

@Hammer

Quote:

Phase 5's R&D ability is still inferior to 3DO's chip design R&D ability.

*was*, not *is*

They are equally as good in 2024 ;)

_________________
Doing stupid things for fun...

@Kronos

Quote:

As soon as it would have meant making new chips, let alone changing any design it needed that NOT to be done.

Without doing anything it remains stagnant. The user base was after new hardware. AGA was made even worse by still lacking a MIDI port that still hadn't appeared a decade after.

Quote:

It needed work on the SW as it was quite clear that "two much HW" was the problem all along.

The Workbench and design sorely needed an update that was looking sloppy at that point. But some things cannot be solved in software. The CIA chips were no match for HD floppy, EPP or fast serial. The world had moved on beyond 5 bit laplnk cables. The Amiga was still stuck at the obsolete PS/2 level bidirectional parallel port.

@Karlos

Quote:

You lose a key benefit of JIT, which is folding out of runtime invariant conditionals. Also, most applications, most of the time are not compute bound, they are waiting for something.

It makes sense to use an updated hunk format then. A compiler can then sort all that out. If the point is to use 68K code as a standardised binary format.

...

Quote:

So I have to preface this with "in my experience". For various reasons the PPC is a bit of a PITA to emulate well, at least 603/604. I had this same conversation recently with a friend. The experience is limited to OS4/WarpOS in UAE, but it seems to depend on integer software emulation for the FPU for best compatibility. There may also be mmu stuff clogging it up.

I can see your point. Possibly QEMU can provide a more accurate estimation of emulation speed. Though the UAE PPC emulation was using QEMU as base code which would be slowed down UAE emulating chipset on top. The new AmigaOne/Sam emulation may provide a more accurate speed. And PPC Mac emulation would be a base reference.


My own experience is running OS4 on UAE/PPC on Linux with FS-UAE. On an i5-8250U laptop. After seeing the real thing action I'd say the emulation speed is roughly that of a CyberStorm 233Mhz PPC. Of course running a benchmark would be better. I wonder of AIBB works?

Last edited by Hypex on 08-Jan-2024 at 12:18 PM.

@NutsAboutAmiga

I have seen it happen myself. I was testing a script which was working fine on my setup. But found it broke on another. It was a test I devised to determine if the running system was 68K, OS4 or MOS. Now I found under some circumstances the test thought OS4 was MOS! The test looks for resident tags like "MorphOS" but Version was reporting an error and giving a false positive. Which confused the script as it checks the return code.

I found out it was due to Enhancer 2.2! The overwritten OS commands were faulty. A return code may seem insignificant but it's needed for proper operation and scripting.

I found similar for MorphOS. The scripts don't run as per AmigaDOS specification and I call it MorphDOS. It has differences in quoting so can make it difficult when doing standard methods like using RequestFile to output to a variable. Writing basic scripts compatible with both AmigaDOS and MorphDOS can be annoying as putting in hack to work with MorphDOS can break in AmigaDOS. Enhancer just made it worse with another Amiga incompatible command set!

@agami

Quote:

Every mainstream(ish) platform that has been around for more than a decade is essentially and ostensibly a "Ship of Theseus".

Sure, but they have a parent company, the Amiga brand hasn't had any since Commodore. The Amiga code base lacks continuance. Without any original developers working on them. The only leg it has to stand on is the original sources from which modern code is descended from. Take away that code and you take away any genuine link to AmigaOS.

Otherwise people would have forgot about OS4 years ago and AROS would have taken over. Which builds from the ground up a portable replacement using a new crew of Theseus.

Or replaced Windows with ReactOS.

@Hypex

Quote:

My own experience is running OS4 on UAE/PPC on Linux with FS-UAE. On an i5-8250U laptop. After seeing the real thing action I'd say the emulation speed is roughly that of a CyberStorm 233Mhz PPC. Of course running a benchmark would be better. I wonder of AIBB works

What I recommend is actually writing some code, specifically for OS4, that you can time with a reliable timer function. I had issues with the EClock in OS4 under UAE, so you need something relatively long running to avoid total red-herrings.

To test it, I used some Mandelbrot type code to compute the area of the set within the limits -2-2i to 2+2i to an arbitrary precision (in this case, as if it was rendered on a 4096*4096 - adjust as necessary).

This has the advantages of not requiring much memory (we are calculating but not plotting), taking an adequate amount of time, and speding that time just doing the sort of multiply and add operations that the FPU should eat for breakfast. You can make the code arbitrarily arithmetically dense by manually unrolling the iteration loop as far as you want and only testing the exit condition once per loop, which is fine because we are doing this to measure FP speed, not plot a Mandelbrot set quickly.

When I did this, I found that the 68K JIT outperformed the 603 FPU implementation significantly on my machine, which is what prompted me to look into it. This is not conclusive proof since the problem could be the specific verison of UAE/qemu.dll I used or some other weird pathology / self-inflicted issue.

However, if you are interested, I'd recommend testing along those lines. Just compare the same binary on a real PPC.

Last edited by Karlos on 08-Jan-2024 at 12:52 PM.

_________________
Doing stupid things for fun...

Why not run OS4 on Qemu/KVM under Linux on an actual PowerPC system?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hypex

Quote:

Hypex wrote: Without doing anything it remains stagnant. The user base was after new hardware. AGA was made even worse by still lacking a MIDI port that still hadn't appeared a decade after.

MIDI port is just a fancy serial port. The only reason it was so essential for the ST is that it had by default.
That ship had long sailed for Amiga as the existing install did not have one.
"The user base" wanted better HW, most didn't care about who made they chips used.

Quote:

The Workbench and design sorely needed an update that was looking sloppy at that point. But some things cannot be solved in software. The CIA chips were no match for HD floppy, EPP or fast serial. The world had moved on beyond 5 bit laplnk cables. The Amiga was still stuck at the obsolete PS/2 level bidirectional parallel port.

We were talking about a no-Amiga-chipset Amiga which yes could have been done is SW.
3rd party (MacroSystems) did it without having access to any sources so no reason ESCOM-Amiga couldn't have done it instead of wasting resources to put rotten meat (AGA) into new sausages (A1200 repro, Walker).

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Draco was a niche machine and the intended audience didn't really need or care about running general Amiga software on it.

I don't think regular Amiga users would have appreciated a machine that cannot run the majority of Amiga software that existed back then, so just throwing out the custom chips all together, even if they were obsolete by then, wasn't a winning proposition either.

_________________
Doing stupid things for fun...

@Karlos

It's not about what it was supposed to it is about what it do.

It did ran most productivity SW of that time just fine and with there still being an active commercial SW scene any gaps would have been filled soon enough.

Sure nothing for "buy a pack of empty disks" gamer market, but that was dying/moving elsewhere anyway with no chance of return.

Would it been an uphill battle? Yep,
Would it have failed? Likely.
Did what they did fail? Hard.

Last edited by Kronos on 08-Jan-2024 at 07:01 PM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

It's not about what it was supposed to it is about what it do. It did ran most productivity SW of that time just fine and with there still being an active commercial SW scene any gaps would have been filled soon enough.

It may have succeeded a bit longer in the US market where most users were productivity users, but here in Europe the user base was younger and more games oriented. If you think about which models sold the most and where they sold, it's clear that neither of those markets were viable alone.

The productivity side was getting crushed by PC and Mac, the gaming side was getting crushed by consoles. That's a no-win squeeze.

I considered myself a productivity user (accelerated, PPC, RTG, wedges of RAM etc and still using the thing exclusively into the 2000's) but I still enjoyed the fact I *could* still fire up the old games catalogue and unwind.

_________________
Doing stupid things for fun...

@kolla

Quote:

kolla wrote: Why not run OS4 on Qemu/KVM under Linux on an actual PowerPC system?

For me at least that is not a very practical approach, because I keep my PowerPC Linux systems on my yacht, which is moored in Neum, on the Adriatic, and I only get to it in the northern hemisphere summer months for a few weeks.

_________________
All the way, with 68k

@Hypex

Quote:

Without doing anything it remains stagnant. The user base was after new hardware. AGA was made even worse by still lacking a MIDI port that still hadn't appeared a decade after.

Built-in MIDI port is a market niche and it didn't save Atari's Digital Research GEM-based TOS platform.

Quote:

The Workbench and design sorely needed an update that was looking sloppy at that point. But some things cannot be solved in software.

For retro UI, without sound card config hassles and small form factor, I prefer the Amiga over PC's DOS/Windows 3.1/mid-tower ATX case.

SBEMU has compatibility issues with many DOS games.

My A1200-PiStorm also has retro MacOS 68K with RTG.

AmigaOS's two-button mouse design is closer to Windows 11's two-button mouse design, hence I'm comfortable with flipping between AmigaOS and Windows 11.

Quote:

The CIA chips were no match for HD floppy, EPP or fast serial. The world had moved on beyond 5 bit laplnk cables. The Amiga was still stuck at the obsolete PS/2 level bidirectional parallel port.

Amiga's Floppy IO performance is linked with Paula. When I owned the A3000, its half-speed high-density floppy drive was satisfactory since SCSI hard disk performance was good.

My A1200's PCMCIA has laptop's WiFi card and it works fine.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Karlos

Quote:

Karlos wrote: @Hammer Quote: Phase 5's R&D ability is still inferior to 3DO's chip design R&D ability. *was*, not *is* They are equally as good in 2024 ;)

Much of Phase5's skill and experience was retained in a new company, bPlan GmbH.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@agami

Sounds perfect then.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@agami

Quote:

@kolla Quote: kolla wrote: Why not run OS4 on Qemu/KVM under Linux on an actual PowerPC system? For me at least that is not a very practical approach, because I keep my PowerPC Linux systems on my yacht, which is moored in Neum, on the Adriatic, and I only get to it in the northern hemisphere summer months for a few weeks.

Isn't that a luxury problem?

OldFart

_________________
More then three levels of indigestion and you're scroomed!

@kolla

Quote:

Why not run OS4 on Qemu/KVM under Linux on an actual PowerPC system?

And then lose all of the threads and posts here in one sweep?
Or perhaps creating yet another one...

Anyways, in my opinion it's too easy a solution, not worthy of the problem.

OldFart

_________________
More then three levels of indigestion and you're scroomed!

@Karlos

Quote:

I recommend is actually writing some code, specifically for OS4, that you can time with a reliable timer function. I had issues with the EClock in OS4 under UAE, so you need something relatively long running to avoid total red-herrings.

There's about 5 choices or something for timers. But, that's on the real thing, so on emulation it's different. Since emulation isn't known to be as accurate as an RTOS. The best I think would be the internal PPC timer but again, the monster raises it's head, since it's emulating a CPU timer.

Quote:

To test it, I used some Mandelbrot type code to compute the area of the set within the limits -2-2i to 2+2i to an arbitrary precision (in this case, as if it was rendered on a 4096*4096 - adjust as necessary).

I haven't exactly looked up the maths lately but I wasn't aware it used complex numbers.

Quote:

This has the advantages of not requiring much memory (we are calculating but not plotting), taking an adequate amount of time, and speding that time just doing the sort of multiply and add operations that the FPU should eat for breakfast. You can make the code arbitrarily arithmetically dense by manually unrolling the iteration loop as far as you want and only testing the exit condition once per loop, which is fine because we are doing this to measure FP speed, not plot a Mandelbrot set quickly.

For FPU code there is a 64 bit FPU in PPC which underlying x87 code simulating it should handle easy in 80 bit or now days in SSE. That's if the code is optimised to convert FPU code to FPU code or best match.

Quote:

When I did this, I found that the 68K JIT outperformed the 603 FPU implementation significantly on my machine, which is what prompted me to look into it. This is not conclusive proof since the problem could be the specific verison of UAE/qemu.dll I used or some other weird pathology / self-inflicted issue.

Whether it makes any difference it would be converting from CISC to CISC. So comparable register file size and stack based CPU. As opposed to RISC to CISC where it needs to handle a larger register file with register based CPU. Of course not all functions would use all GPRs so emulation could block code into sections where it could simulate it using native registers. But, that's likely more advanced than the PPC emulator is doing, so just storing the PPC register in memory in emulation is easier. And given modern x64 memory access speed with caches, even speed of a memory variable with possible cachement, could now be faster than the real thing was. But, by comparison, x64 emulating 68K looks more refined than x64 emulating PPC.

Quote:

However, if you are interested, I'd recommend testing along those lines. Just compare the same binary on a real PPC.

Also of note, there are different FSB speeds, so real hardware will report different clock rates for E clock which I found was based on it in OS4.

@Hypex

Quote:

There's about 5 choices or something for timers. But, that's on the real thing, so on emulation it's different. Since emulation isn't known to be as accurate as an RTOS. The best I think would be the internal PPC timer but again, the monster raises it's head, since it's emulating a CPU timer.

If the process runs long enough, you can just measure it using the standard C routines which are accurate enough, even under emulation. We are talking about very obvious factors difference in performance. If all versions are affected the way mine was, you can't possibly miss it.

Quote:

I haven't exactly looked up the maths lately but I wasn't aware it used complex numbers.

z[n+1] = z[n]^2 - c

It is a complex function but all you are looking for is the modulus (distance from 0) of z exceeding 2.0 (or rather that the square of it exceeds 4.0 so that you don't need a floating point sqrt operation, because damn), since that guarantees the point is outside the set. The maths is actually very simple when you get right down to it and you certainly don't need to use any c99 complex types. I've probably got some example code from that test somewhere still.

Quote:

For FPU code there is a 64 bit FPU in PPC which underlying x87 code simulating it should handle easy in 80 bit or now days in SSE. That's if the code is optimised to convert FPU code to FPU code or best match.

The PPC FPU is supposed to be IEEE-754 compliant to 64-bits, as are the various 64-bit FP vector operations of modern x64 processors. However, I think the issue in my case is that the PPC FPU appears to be being entirely emulated using integer instructions.

Last edited by Karlos on 09-Jan-2024 at 02:36 PM.

_________________
Doing stupid things for fun...