@Kronos

Quote:

Kronos wrote: @umisef Quote: umisef wrote: the 75 Kombi that's currently my home Is that aussie slang for a T2 bus, or am I getting something wrong here?

A.k.a. Kombi https://en.wikipedia.org/wiki/Volkswagen_Type_2

_________________
All the way, with 68k

@Kronos

Quote:

Is that aussie slang for a T2 bus

From the original German "Kombinationswagen" (multi purpose vehicle). It's what the T2 is called in Australia, yes.


(Full resolution: here)

@umisef

What does that winch looking contraption do?

_________________
All the way, with 68k

@agami

Quote:

agami wrote: What does that winch looking contraption do?

It winches things up the slope I am parked next to. It's not easy to tell from this angle, but the darker outback surface is about 15m lower than the campground, with a 45 degree slope going down.

The winch wasn't mine, obviously, but part of the campground.

Last edited by umisef on 05-Mar-2023 at 09:07 AM.

@umisef

Don't lie RATTER, that looks exactly like the kind of winch you would use to sneak into someone elses opal mine late at night and mine/steal their ore.

(it is just a joke. those kombies are awesome vehicles. this picture is from NT?)
Once on a road trip half a day west of Alice I once saw an camper just like this coming doing well over 100km/h on the corrugated sand/dirt road coming towards me in a sharp turn of the road. He was definitely only on two wheels when he took that corner. Jesus. Flip the car there and might be a week until the next car comes past.

Last edited by V8 on 05-Mar-2023 at 11:07 AM.
Last edited by V8 on 05-Mar-2023 at 10:57 AM.

@V8

Quote:

@umisef Don't lie RATTER, that looks exactly like the kind of winch you would use to sneak into someone elses opal mine late at night and mine/steal their ore.

Hey, I just parked next to it. I have no clue what they had that winch for. And as this picture is, in fact, from Coober Peedy, and the campground owner was also an opal miner... :)

Quote:

Flip the car there and might be a week until the next car comes past.

That's why I am paying Garmin each month for their InReach satellite service, even though I barely ever use it. (And also why I go down dirt roads at 40, not 100, of course).

Last edited by umisef on 05-Mar-2023 at 01:57 PM.

@umisef

What is it that you do? Or is this recreational?

_________________
Doing stupid things for fun...

@Karlos

Quote:

What is it that you do? Or is this recreational?

I have been driving around Australia for the last year, while being on a one-week-on, one-week-off remote work schedule (doing embedded programming/hardware design/product development, with a side of being the team's go-to guy for heavy maths). After almost 2 years of working from home, and with a history of working remotely from Europe, it wasn't too hard to convince my employer that "I can 'work from home' from anywhere!".

It certainly makes for a much more enjoyable work/life balance.

@umisef

Nice. Yeah, working from home doesn't have to mean actually at home. Unfortunately for me it does as I have young kids and all the responsibilities that implies.

_________________
Doing stupid things for fun...

@Karlos

Been a while...

Quote:

OS4 pushed forwards... into a expensive niche cul-de-sac, where it has stagnated for how long now?

It was good for 5 years and by 10 was looking old. I'd say at least by 2015 the OS was stagnating. Not helped by the same problems never solved like USB and constant crashing.

Even today I hear the same old story. Let's do X so we can fix Y. As I call it. Replace Sirion with Poseidon and all the USB problems will be fixed! This assumes Poseidon will fix the USB problems on the same hardware. The right way is to fix Sirion since it's integrated into the system.

Constant crashing is a deeper issue...

Quote:

Let's be realists. There isn't a single feature of OS4 that can't be ported to 68K. The whole OS and almost all software ever written for it has been written in compiled languages, primarily C. Code that depends on AltiVec is a problem but that's also problem for any PPC machine that doesn't have it.

Likely not. Internal optimisations like 64 or 128 bit copies would have to be dropped as would DMA memory copies. But they would need to have an updated compiler system and rejig GCC. Right now 68K still uses old cruft like ixemul. Also any other features like extended ram system would need to be cut. Most OS4 hardware doesn't have AltiVec, only aging XE and the disappearing X1000. It is a strange way to go since, apart from the 68080 core, it would mean going from a modern 64 bit ISA back to a legacy 32-bit ISA. But also, the classic A6 jump could not be relied upon, since OS4 uses the interfaces. So they should be using whatever is the SYSV 68K ABI standard.

Quote:

The only problems for OS4/68K are legal and the fact that the system requirements would be higher. There's no dependency on native chipset, but support exists nevertheless. So where is your more powerful 68K on which to run it? We had it in the palm of our hands with Amithlon.

I preferred an iMac myself!

At the time the gap wasn't as wide. The average Amithlon machine, from which the name was derived and the target, was a 1Ghz AMD Athlon. The XE had an 800 Ghz G4 as did an eMAc which was the closest technical comparison.

The eMac would be better for productivity, could boot and install PPC Linux directly, but lacked expansions. The XE was better for expansion, since lacking a case made it easy haha, but could be customised. I considered an eMac and iMac but chose the XE as I needed more than just a central PPC to satisfy my needs. But, an all in one eMac cost about $1,500 AUD, where as my XE cost $2,000 AUD once fully setup myself. At the time an average PC setup was also about $1,500 I recall to $1,000 about.

Quote:

Today there is a resurgence in 68K and we have OS3.2. I don't know the sales figures but I wouldn't be falling out of my chair to learn it's doing as well or better than OS4 in that regard.

There's always been interest in 68K. Simply because most Amiga users want to play those 68K games on the chipset. And then the high end cards with CPU, sound and especially video. For some reason, no one is really comparing a ZZ9000 running on an old unobtanium Amiga, with a cheap Radeon RX580 even though it would kill it. But, compared to the PC market, the ZZ9000 is very expensive. Why do we limit criticism to only PPC main boards and not expensive 68K expansions? From a practical point of view, including cost involved, both do not make sense.

I was surprised to see OS3.2 (and OS3.1.4 before it) accepted as all I could see was that *cough* Hyperion boing ball. But, because of Amiga the Inc, H&P and OS4 AmigaOS 3.2 is in a strange position. It's under the shadow of OS3.9 and it shows. No doubt a lot of work was put into it, but unfortunately, like OS4 in parts, it just isn't good enough. And that is speaking as an observer. It isn't an upgrade from OS3.9 which is confusing. The CD32 isn't fully supported and installing it will crash and ruin the system. There is no CDFS with installer, no unarchiver , no dock, no internet stack, no updated shell. It is until further notice, 0.7 versions behind OS3.9, until it becomes OS3.9.5 and matches it. It does provide a ROM but it needs burning and installing.

Quote:

With PiStorm, UAE and other high performance 68K systems I suggest there's a bigger market for OS4 than there is clinging to PPC.

There would be in those markets. I don't think UAE is a good example as it's limited to PPC classic, and I keep reading about people who run OS4 on UAE and it just crashes. Indeed, I've seen someone install OS4 fresh, run AmiUpdate and it crashes! I don't think the reason matters, a fresh install crashing is not well designed nor tested. If it does work there is a server error that looks like a crash, with something that didn't update, and how you need to look in this hidden log file it doesn't show you. Bit like crashing on a modern OS really where things just disappear into the ether and it doesn't tell you anything.

We are at the point where the AmiFox idea will be taken further and integrated. A ZZ9000 or PiStorrm. Makes sense to run Linux on internal ARM hardware, run a web proxy or customised Fox that can do the real browsing, sending the result to an Amiga 68K web client with a GUI. An old idea now, tried and tested for other systems, just not with a out of the box solution.

My gripe against going back to 68K would be that the point of PPC and OS4 was to move way from it. On to a fresh platform. Going back means it can't run natively on anything and needs some kind of VM. The Amiga dream wasn't to run the OS in a sandbox. Of course, going 68K means people want to run it on a real 68K, but an artificial limit would need to be imposed so it only runs on a modern virtual 68K with minimum memory and RTG.

I just think it looks silly. At that point, it really is time to give it up. Back porting the OS to run on an even more ancient ISA because it's the original and it can be emulated real fast, are we serious? Now I'm beginning to agree with the guy at the Ace2k show, who shouted out his grievance at the OS3.9 announcement, "Why can't you just let it die?"

I know the comparisons. An old PC emulates 68K faster than the newest X5000. An old Amithlon machine can emulate 68K code faster than a 800Mhz G4 can run a native compile. What is faster than both is running native Windows or Linux programs. But I know what is going to happen. Someone is bound to come along and say that Windows and Linux are so slow, Amithlon could emulate 68K code faster than Windows and Linux could run it natively on the CPU. I'm just waiting for it. At that point:

Last edited by Hypex on 06-Mar-2023 at 09:48 AM.

@kolla

Quote:

No one? Don’t we have good handfull of choices alreade? AmiBerry, AmiDeb… and whatnot, XAmiga..minimalistic Linux with some UAE incarnation have been plenty, from what I recall.

Yes but they are not the same. They don't do the same thing. It's been discussed further but Amithlon used Linux for drivers and ran as close as it could to the hardware. Removing or limiting chipset emulation so that didn't incur a speed penalty. And the ability to compile Amiga sources as a special x86 binary that mostly ran direct on the CPU. It was actually quite similar to what OS4 was doing solo on the AmigaOne. And OS4 lost the lead. OS4 was the trail blazer in this case.

These days, however, we have resources like AROS. AROS should pretty much declare Amithlon obsolete. But AROS x86/64 has no 68K support as much as they've tried. Or we still wouldn't be talking about it.

Sure, AROS isn't exactly AmigaOS, it's a design copy. But, it runs direct on that x86 hardware. So, while the minimum Amithlon is doing would be emulating AmigaOS being it is really an AmigaOS emulator, AROS can run native. The difference is AROS is little endian. What allows Amithlon to work easily with 68K is that the AmigaOS that the x86 apps are working with a big endian OS and Amithlon takes the necessarily steps to convert data in each direction. One idea would be to convert pointers back and forth between 68K and AROS functions but can get messy. Another, similar to my OS4x86 idea, would be to compile AROS as big endian only with a custom compiler. Intel has made a compiler for endian sensitive code able to run on x86. But this endian problem may run more deep.

@Hypex

Quote:

Hypex wrote: The average Amithlon machine, from which the name was derived and the target, was a 1Ghz AMD Athlon. The XE had an 800 Ghz G4

Last edited by agami on 06-Mar-2023 at 10:40 PM.

_________________
All the way, with 68k

@Hypex

I think one of the rather fundamental issues that must be faced is that AmigaOS, in all its incarnations, is firmly stuck in 32 bit. And it's 2023; I got 8GB in the "cheap" laptop I bought to bridge the time until I could get the busted screen on my "real" one repaired. It's hard to buy a gfx card with --- when that laptop comes with 8GB of RAM, and it's actually quite hard to buy a graphics card with less than 4GB, then a 32 bit OS is just not going to cut it. Never mind one that only has a single 32 bit address space.

Anything that wants to claim any kind of future would have to move to 64 bit --- and, as I believe AROS x86_64 has shown, it would take more effort than anyone is willing to invest to create a viable 32 bit AmigaOS sandbox on a 64 bit (where "viable", to me, would require a rather seamless back and forth between the sandboxed and native applications --- like Apple provides when they switch architectures). I am not convinced it's at all possible, given the, uhm, liberties that AmigaOS software is allowed to take with the system. But even if it were, it would be a monumental task, and somewhat of a thankless one at that.

@Hypex

I don't have time for a full reply but I think you missed my point here:

Quote:

There would be in those markets. I don't think UAE is a good example as it's limited to PPC classic

I'm not at all suggesting OS4 PPC for UAE. I'm suggesting UAE 68K is a viable market for the proposed OS4 68K version. Along with PiStorm, Vampire and just regular 68020+ machines, though it goes without saying 040/RTG is likely the minimum viable spec. The performance of the QEMU/softfloat implementation in UAE is pretty lacklustre, at least on my machines.

_________________
Doing stupid things for fun...

@umisef

At the current time I think it's fine for AmigaOS to be a 32-bit, uniprocessor, single user OS. It's fine because unless you are deluded into thinking it has a commercial use case today, it's a hobbyist OS. This is why I find the push for ever more exotic, expensive PPC hardware such a fools endeavour.

The effort required to seamlessly migrate to 64-bit is not something that the current players can realistically pull off. AROS has done it but has failed to flourish. Part of that is the "brand" issue bit a bigger part is likely the lack of compatibility with existing 68K binaries that has been a thing since the beginning of the project. There are some really cool things that have come from AROS, but mass adoption amongst Amiga fans unfortunately doesn't seem to be one of them.

Ironically, AxRt will probably become the closest thing to a bonafide next gen AmigaOS in terms of important new: 64-bit, SMP. You know, being Linux.

Given these current limitations I genuinely believe that the only viable remaining choice is emulation. The only performant, mature emulation we have that approaches anything like raw native performance is JIT 68K. Maintaining an additional PPC emulator for software that mostly exists in a recompilable state seems pointless and takes developmental resource away from improving the 68K side.

And regardless of what I believe, the PiStorm is making it happen anyway - bridging the gap between real hardware and pure emulation via UAE.

Last edited by Karlos on 06-Mar-2023 at 10:12 AM.
Last edited by Karlos on 06-Mar-2023 at 10:06 AM.

_________________
Doing stupid things for fun...

@Hypex

There’s little penalty with the chipset emulation just being there, the penalty only comes when it is used… which you don’t really have to do.

Last edited by kolla on 07-Mar-2023 at 08:59 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

There’s little penalty with the chipset emulation just being there, the penalty only comes when it is used… which you don’t really have to do.

As the guy who made UAE's original JIT work with the chipset emulation, and also the guy who then enjoyed being unshackled by that emulation while adapting that JIT for Amithlon, I have to disagree.

@umisef

Is there any recommended reading you would suggest for anyone interested in implementing a JIT for x64 today?

Just asking for a friend, like...

_________________
Doing stupid things for fun...

@agami

@umisef

Quote:

I think one of the rather fundamental issues that must be faced is that AmigaOS, in all its incarnations, is firmly stuck in 32 bit. And it's 2023; I got 8GB in the "cheap" laptop I bought to bridge the time until I could get the busted screen on my "real" one repaired. It's hard to buy a gfx card with --- when that laptop comes with 8GB of RAM, and it's actually quite hard to buy a graphics card with less than 4GB, then a 32 bit OS is just not going to cut it. Never mind one that only has a single 32 bit address space.

That much is true. It's obvious from the public structures that the core design is locked to 32 bit. Or 32 bit signed so 31 bit in some DOS cases. By itself that's no problem since it was the original 68K design. The problem is they dragged that design over to PPC and kept it largely the same. The main reason is compatibility and a main feature. But, I see compatibility as irrelevant since all 68K applications needed to be emulated anyway. Or course, it was good for native and 68k apps to share the system, since it all worked transparently and 68k apps had a newer look. However, I think they went a bit too far, since 68K interrupts are emulated inside a real PPC interrupt.

What was needed earlier is closing down the system. This happened to an extent. But the global Forbid/Permit system for protecting local data was kept in place. This is causing trouble now with issues on multi core. After thinking about it, I think it was a design flaw, but back then an open shared design was good for speed. The 64 bit problem would run deeper since the whole OS would need a redsign. It might even have been a good idea to use C++ and OOP data hiding features. Since BOOPSI retrofitted the OOP concept onto a C API (in a messy way). And OS4 compiler goes one further with the interfaces that are passed as a hidden parameter to functions in OOP fashion but it wasn't extended to datatypes (to clean it up). Well, so is A6 for 68K, in a similar manner. I don't know if the 68K calling conventions were based on some ABI standard, but with the SYSV ABI standard they had gone from 15 possible parameters to 8 and stack the rest. On a CPU with double the register count.

My X1000 has 4GB RAM. I could have maxed it to 8GB. But it's only useful for Linux and on PPC it doesn't seem to need that much generally. OS4 has some extended subsystem. The RAM disk is supposed to use it. But I still get trouble when I fill it over 1.5GB so I've seen no proof of that yet. I have a laptop I'm typing this on with 8GB. But with my browser tabs now in the hundreds it really needs 16GB.

Quote:

Anything that wants to claim any kind of future would have to move to 64 bit --- and, as I believe AROS x86_64 has shown, it would take more effort than anyone is willing to invest to create a viable 32 bit AmigaOS sandbox on a 64 bit (where "viable", to me, would require a rather seamless back and forth between the sandboxed and native applications --- like Apple provides when they switch architectures). I am not convinced it's at all possible, given the, uhm, liberties that AmigaOS software is allowed to take with the system. But even if it were, it would be a monumental task, and somewhat of a thankless one at that.

For OS4, it would need to box 68K and PPC up together at this stage, with a redesign in the works if ever. AROS does have the benefit of needing no binary compatibility. It just needs source compatibility. So an AROS64 is an easier proposition. Of course, it too is built on the same foundations, since it builds on the same structures. It does have the liberty of being able to have more freedom to change internals. Well, it did. There has been the ABIv0 vs ABIv1 confusion for a while. Or it looks like it. They can change things. It just makes sources incompatible and existing binaries. But, that is the way of the computer world. APIs change and code must change with it. The Amiga design in libraries has backwards compatibility as standard which shouldn't be broken. But versioning does allow for managing it and library bases with jump tables can be created on a client basis.

I must give credit to Linux PPC as I've taken 32-bit apps and they ran fine on a 64 bit kernel. Somehow they got something right with 32 bit user land in 64 bit kernel space. I even tested the custom installed Ubuntu 9.04 from my AmigaOne on my X1000 and it was able to boot, at least on older kernels. I installed AROS hosted on it and tested it on my X1000. It runs great!

Last edited by Hypex on 13-Mar-2023 at 12:46 PM.