Amiga Coldfire project dead?

[Karlos]

@Piru

One argument for JIT on coldfire would be that you could probably get away with something very lightweight and quick since your JIT will spend most of it's time simply copying the existing opcodes, without transformation, to the translation cache. You might even be able to create something along the lines of HP's Dynamo, which had the amusing property of being able to run code faster than the same CPU it was running on (due to runtime optimised code folding).

[Karlos]

It used to be the case that coldfire was just not compatible enough with M68K object code, not so much because of missing opcodes (which can always be trapped, even if it means a hit) but that there were cases where instructions behaved differently without generating a trap. They were the real killers, since they'd introduce behaviour that would be unexpected and also impossible to work around. As far as I know, these compatibility issues have been mitigated in more recent cores since, though I don't know the technical details as I've not been keeping up.

However, assuming you can make m68k object code run, one oft-cited objection towards coldfire is that for full M68K compatibility you are potentially looking at a big performance hit relative to "native" coldfire code due to whatever emulation work is required to achieve compatibility.

However, how bad is that worst-case performance compared to say 030, which seems to be all that's presently on offer for new accelerator cards?

If it turns out that worst trap-and-emulate required m68k code runs at speeds comparable to a fast 030, or higher, then it is almost a bit of a no-brainer. Not all m68k object code you throw at it is going to be riddled with unimplemented operations and addressing modes.

When the 060 came out for amiga, trap-and-emulate caused a lot of performance issues, but things like CyberPatcher and OxyPatcher demonstrated there are faster solutions than naive trap/emulate.

[Karlos]

Of course, the apple implementation will always choose "poetical" over "political" since it's a word that your average mac user, being a "creative" type is more likely to use :p

[Karlos]

Why does nobody just do this?

To hell with the copyright!

Erm, they have. AROS runs on more than just x86.

[Karlos]

Guys... The falcon used MultiTOS and later MiNT...

I just couldn't use an OS called "TOS"... :lol:

[Karlos]

@Piru

It's Photoshopped, look! :lol:

[Karlos]

To be fair on Atari, MiNT (MiNT Is Not TOS) was actually a pretty good OS... And the Falcon was far better than the A1200 (and the A4000 IMHO)... Had they not cancelled it in favour of the Jaguar it might have run! :-o

Actually, I have to disagree. The principal things the Falcon had going for it were the DSP and chunky/RGB graphics support, both of which were very nice. Unfortunately, the 16MHz 68030 it came with (considered a selling point over the A1200's 14MHz 020) was rather crippled considering it was wired into the rest of the entire system, RAM included, by a 16-bit data bus.

Having said that, a Falcon with one of those CT60 boards is a proposition

[Karlos]

You forgot the proper 16bit audio of the falcon too...

I didn't forget, I just regarded it as a subset of the DSP feature. Of course the DAC was a separate component, but it was the DSP that gave it the capability to do multichannel audio playback at CD quality.

Yeah, the killer was the 16bit bus... But come on, while that is a limitation, it is a VERY easy fix for a future hardware revision... The rest of the falcon hardware was an order of magnitude superior to AGA...

Not sure it was that easy to fix, it can't have been a decision their hardware designers were thrilled about releasing it in that configuration in the first place.

By the same token, the shortcomings of the A1200 were easily remedied by 3rd party expansions. It's all a question of how much you're prepared to pay for it. I'd but an 060+PCI (RTG, soundcard) A1200 up against an equivalently clocked 060 Falcon with it's out-of-the-box hardware any day.

[Karlos]

You know better than most that the DSP was useful for more than just Audio, and given the fact that the A1200 had nothing like a DSP an was stuck with 8bit audio... It is worth mentioning

Hey, don't get your knickers in a twist I'm not knocking the Falcon. Of course the DSP is certainly useful for more than just audio, but since we're talking about the time it was first released, there wasn't a lot (IIRC) that used the DSP for non-audio purposes. Just as much later, the A1200 found new capabilities through third party expansions, so people also found new uses for the Falcon's DSP.

If wikipedia is to be believed then the 16bit was was simply to ensure better compatibilty with the ST... Suggesting this hardware revision was a transitional machine. Seinberg's Falcon clone didn't use a 16Bit bus IIRC...

Not sure how much I believe that. Since we're comparing same era hardware here, AGA managed to retain a respectable degree of backwards compatibility without resorting to using a 16-bit data bus between the CPU/custom chips and certainly not for it's interface to normal (fast) RAM.

Yeah, but A1200 RTG boards came about quite a bit later than 1992, which is the time period I'm talking about here... And also we are taking about base spec machines... Damn... We need to compare a standard Flacon running AROS with a standard A1200 running AROS to really see how the two machines compare

Sure, I acknowledge the time gap, but since we are now in the present, we can compare what the machines have become since. I stand by the observation that you can now build a significantly more powerful A1200 than you can a Falcon, with the exception of which has the fastest 68K processor; there's just nothing comparable to the CT60 board in the Amiga scene. I'd love to see something similar

[Karlos]

Put more simply, had commodore realeased both the A1200 and the falcon (running AmigaOS of course, possibly with a cost option for ECS compatibility)... I would have opted for the Falcon... How about you?

Well, I nearly bought a Falcon instead of my first accelerator card, so I guess I was always a bit on the fence. I'd have absolutely no qualms with an AROS based Falcon / CT060

All things being equal, if we're talking ideals here, I would have preferred an A1200 with at least a SIMM slot on the motherboard, even if it only took a maximum 4MB (for PCMCIA friendliness) with the 020 clocked directly from the motherboard's 28MHz signal, rather than 14. Of course, that might actually have made it a bit faster than some of their big box 030/25MHz machines. It would have been nice if it had some chunky support, even if it was just hardware C2P and not a framebuffer.

Speaking of which, the Akiko's C2P was another massive let-down. Instead of writing 8 32-bit words of chunky data to it and reading it back as 8 32-bit words of planar data then pushing that to your Chip RAM, it should have had 8 address registers that you set up to point to your planes and then write to it and it writes the planar data to those addresses (incrementing as it goes). At worst, you'd need to reset the pointers once per scanline, or more likely once per frame. You might have some wait states whilst it's busy but a properly constructed loop could always find some other useful stuff to do whilst the hardware was converting/writing.

[Karlos]

But we are dreaming again

Considering we were just talking about the "AmigaOS running Falcon", I thought that was the point

[Karlos]

There's a single 32bit register. In order to convert 32 pixels you write 8 32-bit (4 byte) chunky pixels. Then reading back the 32bit register 8 times you get the planar data out. IIRC you get the least significant bits out first so that you can omit reading some planes if you use say 128 or 64 colours.

That's not quite how I remembered it (I thought there were actually 8 registers), but your recollection is probably better than mine. Either way, it was a write and read back mechanism that meant you still had to push the data back to the bitplanes yourself.

[Karlos]

Well either way, it sucks the same

Amen to that, was such a waste. Just being able to write to the chip ram by itself would have made it so much more useful. After all, if you are doing software texture-mapped 3D type stuff, you are going to want to have your accumulation buffer in fast ram. You might just get away with reading that to a set of registers once per frame. However, the amount of shuffling you actually had to do with akiko rendered it all but pointless.

[Karlos]

Or is the AB 3D engine just the same on both and not even bothering to try using AKIKO?

^ this.

[Karlos]

AGA is a Kludge, same rubbish parallax with 8 extra colours wooo, same sound and a slow slow 256 colour mode. It was too little too late and only an idiot would argue otherwise. Even the 1987 Acorn Archimedes had faster 256 colour mode (and faster CPU than A4000/030 with 8 channel stereo sound actually).

Actually, a friend had a first generation Acorn RiscPC. Was a nice system, no question, and the chunky based display a lot faster than AGA but the CPU performance was not that great, depending on the task. My first A1200 accelerator card (25MHz 040), for example, was considerably faster at decoding jpeg images than it was, for example.