@Hypex

Quote:

Hypex wrote: @Karlos I've noticed a modern idea is treating 68K as bytecode. Or, for 68K, it would be wordcode.

Calling it a bytecode simply means it's a sequence of bytes that is intended for interpretation or translation. That it happens to align neatly to 16-bit boundaries is irrelevant.

Quote:

But this presents problems of it's own. If it's used as a generic base code for portability. Since, by comparison 68K code is not always clean.

Any code can be dirty. A requirement for a "universal" 68K standard would be to avoid dirty tricks.

Quote:

For example, 68K can modify itself, and code is mixed with data and variables. PPC, based on ELF, is cleaner since it separates all that by design.

You can write self-modifying code for just about any architecture. It's not considered a good thing. For any "standard" bytecode solution, not modifying your own instruction stream.

ELF is unrelated to the ISA, how do you think 68K linux worked? Equally, there's no *requirement* for code written for the hunk format to mix together code and data either. Nevertheless, there's nothing preventing 68K object code being "clean". In fact, in order to help you design a better runtime environment, being "clean" is mandatory. Your code is going to end up translated to native and you really don't want to be modifying it. Keeping your code and data separate are desirable.

Quote:

Another is that 68K lacks SIMD. Now only specific applications use it and more so since later hardware lacks support. But the OS does use it internally just like the utility library would make use of 68020 code where possible.

PPC also lacks SIMD if you don't have AltiVec (or Cell). Has that prevented it from running on 603, 604, 440, G3, etc?

Nothing theoretically *prevents* clean 68K code under JIT from making use of vector instructions in the translated output. In practise, the significant complexity of analysing what is being done in the 68K code and how it maps to a vector operation is no easy task.

However, lets say you really, really want SIMD as an option. You have a number of possible routes, of varying complexity:

1) Implement a native code passthrough that permits use if host native instructions. The problem here is that you now have a significant number of potential host architectures to worry about.

2) Provide a bunch of libraries and datatypes that are built for (1) to reduce the amount of "native" code any developer needs to write for common tasks. A challenge here is, what's a sensible set of such things?

3) Roll your own vector unit with blackjack and hookers. It's a virtual 68K so in principle you could design a bytecode extension for a hypothetical vector unit that at the very least can be interpreted anywhere but *exists* to be executed via a JIT designed for vector operations. While I can't comment on the efficacy of the specific realisation, even WASM has this one.

Quote:

For a native custom OS with all apps being loaded and binary compiled at load time on a portable CPU there's endian to think about.

Virtual 68K is big endian, end of story. You can run it BE directly on PPC, ARM or with endian conversion and/or big endian memory model (i.e. Amithlon style) on x64. It's really not the huge deal people make it out to be. Furthermore, nobody cares about what the translated code and any read-only looks like, except where it interacts with writeable data, so that's going to remain endian native wherever that makes sense.

_________________
Doing stupid things for fun...

@Kronos

Quote:

If you don't have those reworked sources or if using them in that way would trigger another lawsuit they might as well not exist.

The legal issues might very well be an issue waiting to bite someone in the ass, but I fail to see how source code you've had to write in the first place and need to recompile occasionally whenever you need to fix a defect, add a feature or support some new "not quite compatible PPC" (cough, A1222) that comes along is something you don't retain access to.

_________________
Doing stupid things for fun...

@Kronos

Quote:

The one that made the incompetent SoC choices is not only the one that would stand to loose the most on Mac port (or anything else) but also the one who has (or seems to have) the most reasons to bring Hyperion down. But what he does not have is a legal way to make an Amiga or Amigalike OS without Hyperions consent.

We're talking about a period of about 20 years go, when Dickinson was just another user and was not involved in either SW or HW making.

_________________

@Karlos

Dunno, AFAIK many of those burned with OS4 where it was "no you don't get payed yet it is just a prerelease" to "you should have asked years ago when we released it" in an instant only ever provided binaries. Binaries that might still be unchanged parts today.

Then there is ExecSG which is owned by AEON but is based on old AmigaOS code (at least thats what everybody insisted for years) incensed by Hyperion and owned by Cloanto (or something down the that line).

With these 3 involved it's not question of getting bitten in the ass, but of how big of a chunk is gonna be ripped out.

Actually the worst case scenario would be everybody staying quiet until it gets big enough so that some money is being made.
Thats when the lawsuits stroke in the past and thats when the project is gonna die.

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

@WolfToTheMoon

20 years ago the idea of sensible non Apple PPC-HW was still valid.


But if you insist, replace Dickision with Redhouse and most is still true. Well less moron and quite a bit more scam artist, same difference......

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

@Kronos

Quote:

With these 3 involved it's not question of getting bitten in the ass, but of how big of a chunk is gonna be ripped out. Actually the worst case scenario would be everybody staying quiet until it gets big enough so that some money is being made. Thats when the lawsuits stroke in the past and thats when the project is gonna die.

Yeah, that's the real issue here.

I don't for a second think that any *serious* developer thinks "well, migrating away from PPC to something more people can use and have fun with" is a bad idea.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: I don't for a second think that any *serious* developer thinks "well, migrating away from PPC to something more people can use and have fun with" is a bad idea.

Don't blame the developers, blame the IP Owners.

@Thread

So can you buy an A1222+ off the shelf yet? PPC IS dead if no one can buy a PPC Amiga! They didn't even market the availability of the P5040 version of the X5000 presumably because it was considered EOL on launch!

The RGB cases that the X5000 can in by the end were horrible! What happened to the Boing Ball engraved ones?

Last edited by BigD on 02-Jan-2024 at 07:38 PM.

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

@BigD

LOL, you can buy one. Good point!

@BigD

Quote:

So can you buy an A1222+ off the shelf yet?

Still Pre-order. Last semi-official update on the 14th was that the boards were being tested at the factory.

Quote:

PPC IS dead if no one can buy a PPC Amiga!

Sam460LE and X5000 are still available through various dealers,

Quote:

The RGB cases that the X5000 can in by the end were horrible!

Only Amedia sell them in that case. Everyone else sells or sold X5000 in the Fractal Design case, if you order from Relec you get a screen printed front panel with a different design to the official one.

@OneTimer1

I don't really blame anyone, really. It's just some bizarre, seemingly intractable tarpit of nonsense we find ourselves mired in.

_________________
Doing stupid things for fun...

@Rob

I know some people are excited for the A1222 and I hope it turns out to be far better than I am expecting. I feel very pessimistic about this particular machine, so hopefully that's just me being old and jaded (I guess I'm more like Kronos than either of us would care to admit...)

_________________
Doing stupid things for fun...

@Karlos

there is not virtual 68k it is just emulator

want people to use commodity hardware give them commodity quality os

leave ppc as it is and start working on something new that will be worth of use on commodity hardware

@BigD

Quote:

So can you buy an A1222+ off the shelf yet?

According to this amiga.org post here "AAA Technology" seems to be reaching out to anyone & everyone who they think might buy one. So no, you cannot buy one "off the shelf" and most likely never will be able to.

@Karlos

I don't think they'd have a big deal selling them all if Trevor had the boards produced when he was quoted 300 (whichever currency) per board. A complete system could have been in the same price range as a V4 standalone bundle and been on the market for about the same time already.

At €1200 for a board with software licenses or €1600 for a complete system, maybe they'll sell around 100-200 over a prolonged time scale but I can't see them ever shifting nearly as many boards as they have SOC chips for.

@AmiRich

The distributor contacting the people who bought the AAA bundle, with details on pricing, is surely something most reasonable people would expect to happen.

Last edited by Rob on 03-Jan-2024 at 07:03 PM.

@Hypex

Quote:

Hypex wrote: @Karlos People tend to blame Hyperion for OS4 being on PowerPC but the choice was really made by Phase 5 who produced the PPC accelerator cards. This was around 5 years after those cards were produced so still made sense. Apple were still using PPC so it made sense that way as well but also pointed out a problem that they depended on Apple for the CPU. They couldn't source PPC from Motorola like with the 68K and CPU sourcing problems for the AmigaOne and later for X1000 would prove that anyone wanting to use the PPC would become Apple's bitch.

The blame for PowerPC migration is on Escom-era Amiga Technologies GmbH's Petro Tyschtschenko who collaborated with Phase 5.

Phase 5 was involved with PowerPC upgrades for the Apple Mac market. https://everymac.com/upgrade_cards/phase5/

Gateway 2000 inherited Amiga Technologies GmbH's PowerPC direction.

ARM in 1996 wasn't performance-competitive when compared to other RISC and X86 competitions.

ARM8 was released in 1996.
ARM9 was released in 1998.

DEC's StrongARM was released in 1996 and it focused on portables.

DEC's corporate stability wasn't good in the mid-1990s and Intel wasn't focused on high-performance desktop ARM CPUs since Intel has Itanium.

Last edited by Hammer on 04-Jan-2024 at 01:49 AM.

_________________
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)

@ppcamiga1

Quote:

there is not virtual 68k it is just emulator

An Amiga emulator has a virtual 68k CPU.

Really, anything emulated _is_ virtual, but not everything virtual is emulator.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Rob

Quote:

Rob wrote: ... maybe they'll sell around 100-200 over a prolonged time scale ...

That's fairly optimistic.

After the last run of SAM460LE boards not selling out, I estimate that fewer than 100 will be sold in 2024. On top of which, somewhere between 1/4 and 1/3 will be purchased by those who already own either a working X1000, a X5000, or both.

I estimate that fewer than 1/5 will be sold to users who are entirely new to AmigaOS 4.

_________________
All the way, with 68k

@Kronos

That and developers agreeing to be paid. Only to find their work published. Before they were paid. And if they were paid. They found they were paid a deposit.

There are signs of this with software like AmiDVD. Now AmiDVD is a quirky example because it's freely downloadable on OS4 depot but it won't work on the current release. There's also PartitionWizard, which was included in the OS then suspiciously removed while still being included in the OS, but it didn't load up correctly. Later it appears as a paid extra in Enhancer. PTPTransfer suddenly went buggy, which I recall despite the technical name, was a major new feature to import Android photos when it was introduced. After doing some investigating, it's officially not on the list of programs, no one remembers it even being in the OS and now AEON own it.

Given the kernel brothers stated from the start they only worked for Hyperion it looks like they never had the source. Or only OS3.1. Most of the rest was sub contracted out. Now Trevor owns ExecSG so he has some control in direction but others would need to follow. Not that it's a big issue employing different developers but expecting your users to buy all the pieces separately and put it all together is. There used to be a joke about Unix users needing to gather all the parts of the OS themselves in the 90's. Well now OS4 has become that OS model. Around the time FE came put this happened. You only needed the OS as one product. Then FE comes along, which had a cheaper price, but the cheaper price was a fallacy. You then had to complete it by buying this Enhancer package on top of these confusing graphic packages AEON also sold. And here we are.

@Hypex

Kill it with fire and restart with AROS, then. If you are working for free you might as well be free.

_________________
Doing stupid things for fun...