@BigGun

Quote:

How many clocks do you think does the exception take on the Coldfire?

I googled a little and I assume it would be something like 40 cycles until the first instruction of the exception is executed.

Quote:

Sometimes you don't even need to replace them with a jump. For example many often used variants of the DBCC could be replaced in place by SUBQ and BCC

Sometimes, yes. However, DBcc decrements only lower 16 bits of a target register. But subq.w does not exist in Coldfire, only subq.l is supported.

Also, Bcc could only use 8bit offset since there would not be enough space for 16bit offset.

If that loop contains other unsupported instructions which generate an exception (but can not be patched) execution times accumulate quickly.

Quote:

68060 -------- 1 -------- 1 -------- 2 -------- 1 ------ 0/1 (Two instructions per clock!) (...) The timing comparision clearly shows the major performance improvement from 000->020 and from 030->040 and 040->060.

It should be also taken into account that exceptions cause pipeline stalls. For 68060 to run at maximun speed instructions must be interleaved (can not remember rules anymore) properly and some instructions (mul, div) could be executed only by the first execution unit.

I dont know how this applies to Coldfire, though.

As a whole I was maybe little rough on my assumption since and maybe it is possible get Amiga 500 speed from Coldfire after all. Even my BPPC could do that. But I would not expect miracles from Coldfire... it is closely compatible but still little far.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Donar

Quote:

Having a cleaned Kickstart should prevent the coldfitre from trapping out - from my understanding it will be faster then.

Ok, that would make some sense.

Quote:

With "rewrite" i meant AROS Bountys Kickstart Replacement 1/2. So no infringment of Amiga Inc's copyright.

The AROS re-write bounty will still have to be careful to avoid copyrights. You can't just read the current kickstart code, write your own derivitive version and plug it in to a clone. Not by U.S. copyright standards anyway.

Plaz

@mr_a500

Ah, those solid plastic and chrome designs from the 1970s. Definite retro goodness

The biggest advantage to having a separate keyboard (assuming you don't go pounding it or spilling stuff all over it) is that most of us have another computer, so it's very convenient to be able to use a KVM switch.

The last thing the NatAMI needed would be a copyrights owner of some sort (like MC Bill & his crew) smelling the chance of an opportunity to actually earn money without having contributed a flying donkey's to the project, thus laming or even killing it by a court trial or ridiculous demands. It has to be water-proof, I think.

By the way, as @bbrv was talking about a commercial success: I don't believe NatAMI will be. I mean, how many people are likely to buy it? It might sell more or less well to the members of this community and maybe it drags back some of those many that have got lost under all these years but I highly doubt anyone can make a fortune out of this.

Last edited by Krischan76 on 25-Mar-2008 at 04:17 AM.

@Krischan76

Look at post #353 in this thread.

I realise I'm very late to the thread.... and I may have missed some of the discussion.

Can someone explain to me why they can't just licence the 68060 and plonk it on the FPGA with or beside the NATAMI chipset and a decent amount of chip ram?

I can only assume, it is a matter of FPGA not being large enough to do this and the Coldfire is the only 68k compatable chip in production today, that can be incorporated on the mobo.

However, if you're going to build a system on a chip, which you would for mass production, then it will be on silicon in its own right, and not an FPGA in which case the size and speed contraints may disappear entirely.

Are there licensing issues re-implementing the 68060? Coldfire is cool and probably cheaper, but why take the incompatability risk? They aren't on the dev boards I see.

_________________
Leo Nigro, CTO Commodore USA, LLC
Opinions expressed are my own and not those of C= USA.
Commodore/AMIGA "Beautiful, High-Performance, Home Computers for Creativity and Entertainment."

@BigBentheAussie

Quote:

Coldfire is cool and probably cheaper, but why take the incompatability risk?

Seems to me there is a very good reason to take the incompatibility risk. If the risk can be minimized, then very significant that the classic Amiga OS would be running without emulation on modern hardware with a stated future. And the Amiga _community_ would be able to proceed with future design iterations along a hardware roadmap, unencumbered by stupid, extraneous issues.

_________________
Vic-20, C-64, C-128
Amiga 1000, 3000
AmigaOne X1000

@Krischan76

Quote:

bbrv was talking about a commercial success: I don't believe NatAMI will be.

If they can make a real silicon SoC out of it to a reasonable price, I think it could have all possibilities in the world to become a commercial success. Not necessarily as some retro gadget for Amiga nerds (even if it surely would be welcomed here as well), but as a key OEM component in all kinds of consumer electronics that needs some kind of computing and display/multimedia capabilities. In that case, AROS could become a real hit!

Perhaps the correct mindset here is to consider the 68K to be the "virtual processor" - in a similar way to the Intent system.

How that processor instruction set is executed can be:
- by matching standard silicon (680x0)
- by 'close' silicon plus software traps (Coldfire)
- by custom silicon (68K core on an FPGA)
- by emulated silicon (i.e. making an Intel chip emulate 680x0)
- by a JIT compiler (similar to Java or .Net) for the actual processor
(could be PPC, Coldfire, Intel) - perhaps implemented on an FPGA?

This is my thumb-suck in order of escalating complexity.

Lots of choices, no obvious answer. All with trade-offs.

To me I would go with real 68K to start and then jump straight to the JIT. Forget trying to hassle with software traps, custom CPU core emulations, etc, etc... Implement an FPGA-based JIT and watch it fly. In theory with the JIT in silicon even the basic kickstart would be run through the JIT system?

This way if you want to run on a low-cost Coldfire, plug it into the CPU expansion and flash the JIT to match. Same idea for PPC or Intel. Theoretically the JIT for 68K->Coldfire would be fairly straightforward given the small (-ish) differences between the processors?

Food for thought.

Last edited by gregthecanuck on 25-Mar-2008 at 10:31 AM.

@Plaz

Hi Phaz,

Quote:

Plaz wrote: The AROS re-write bounty will still have to be careful to avoid copyrights. You can't just read the current kickstart code, write your own derivitive version and plug it in to a clone.

Your wrote here a number of times post in the spirit
of being afraid of not being allowed to alter or rewrite the Kickstart.

Please mind the following:
The source of the AMIGA Kickstart was published (printed) with the permission of Commodore.
The Kickstart source documented asm listing was published with the intention for other to learn from this. And everybody has the right to just to do this - to see learn and use this.

Please don't panic - using Kickstart, altering Kickstart and reimplementing it AROS is totally legal.

Amiga inc can not prevent any of this.
Please mind that even a much more powerful company (Microsoft) can not prevent people from creating SAMBA, Open Office, Wine and writing a complete Windows clone (REACT OS)

_________________
APOLLO the new 68K : www.apollo-core.com

@BigGun

Quote:

BigGun wrote: Please don't panic - using Kickstart, altering Kickstart and reimplementing it AROS is totally legal. Amiga inc can not prevent any of this.

Since when does Amiga Stink care about minor things like legality?

It didn't stop them filing a bogus 'Manipulation of copy protection' complaint against a1k.org just for hosting a video of an A1000 booting off a custom kickstart disk. [Old amigaword thread]

TBH, I wouldn't be suprised if they got the lawyers involved, just to bully you into signing an IP agreement

_________________

@FrenchShark

Quote:

There is actually a HUGE problem with Exec and the ColdFire : the counter IDNestCnt for Enable() and Disable() is a byte! Since addq.b does not exist on the ColdFire, there is no way of having an atomic instruction for ADDQ.B/SUBQ.B #1,IDNestCnt(A6) in an exec.library ported to ColdFire.

I'm pretty sure IDNestCnt modification does not need to be atomic because it is somewhat special in that even if a context switch (to different task/interrupt) happens in between loading/modifying/writing, the thing is that once my context gets activated again it (IDNestCnt in memory) is (supposed to) once again have the same value it had when the context was left.

Unlike other cases like tc_SigRecvd which when context is left might have one value, and when context is activated again might have another value.

@BigGun

Why go through all this hassle of converting kickstart? Is it really worth all that reverse-engineering and hassle to simply support one type of processor?

As per my earlier message why not implement a JIT instead? Spend your time implementing a good JIT and reuse that.

Set up a foundation for making the platform processor neutral.

@gregthecanuck

Quote:

gregthecanuck wrote: Implement an FPGA-based JIT and watch it fly.

Would be too slow. I've already explained why in an earlier post. If you're talking about an ASIC then you might be on to something workable, but who are you going to find to build one?

@Plaz

Quote:

Plaz wrote: The AROS re-write bounty will still have to be careful to avoid copyrights. You can't just read the current kickstart code, write your own derivitive version and plug it in to a clone. Not by U.S. copyright standards anyway.

Yes you can, but you have to use the 'clean room' technique, which involves at least two people. That's how the original PC BIOS clones were created, Wikipedia can tell you more.

Quote:

Plaz wrote: Only an invalid instruction is trapped, not a vaild instruction that performs differently.

Surely the Coldfire designers know these instructions perform differently?

@Rob

Quote:

Rob wrote: Whereas in UAE the emulated 68K communicates with an emulated Amiga chipset, in this concept the emulated 68K would communicate with a real Amiga chipset.

You seem to keep on changing what you are proposing, so before I discuss this idea with you, let me clarify what you are proposing: a SuperAGA expansion board for PC?

@FrenchShark
Quote:

FrenchShark wrote: Few years ago, I wrote a kickstart disassembly tool called KickDis for Oli_HD. I did re-assemble the source and tried the ROM on UAE and it worked ! I have also ported the exec.library to a ColdFire 5282.

Sounds good. I know you are busy with your own Amiga design, but do you think you could help out the Natami team with your kickstart and Coldfire knowledge when you have the time?

Quote:

Amiga inc can not prevent any of this. Please mind that even a much more powerful company (Microsoft) can not prevent people from creating SAMBA, Open Office, Wine and writing a complete Windows clone (REACT OS)

The difference is that ReactOS didn't took the Win32 libs, disassembled it, and used it as a base. What you're talking about is taking the exec disassembly, and modifying it: this isn't possible.

You have to keep in mind that this OS is closed source. And current owners are anything but cooperative... If you base your project on this OS I'm pretty sure this *will* leed to copyright/whatever problems, sooner or later... especially when you see that they already can't deal with their own partners...

That's my two cents... feel free to prove me I'm wrong...

_________________
http://www.warpdesign.fr/

@Leo

Quote:

The difference is that ReactOS didn't took the Win32 libs, disassembled it, and used it as a base. What you're talking about is taking the exec disassembly, and modifying it: this isn't possible.

How come? How are you so sure?

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Georg

Quote:

I'm pretty sure IDNestCnt modification does not need to be atomic

As long as one were able to recognise that a particular sub.b/add.b with immediate 1 is trying to update a byte-sized counter like ID_NestCnt, it would be relatively simple to replace it with a 32 bit add/sub with an appropriately shifted "1". The counter, AFAIK, is not supposed to ever over or underflow, and if it does, bad things are around the corner, anyway, because the perceived value is off by 256 from the intended value --- so some neighbouring byte having been corrupted would likely not cause any more issues.

The problem, of course, is recognising byte-sized adds/subs which are never going to over/underflow, and tell them apart from those that may, by only looking at trapping instructions.

Of course, one could also disable interrupts during the trap (not sure how high it is in the priority list, anyway).

@HenryCase

Quote:

Yes you can, but you have to use the 'clean room' technique, which involves at least two people. That's how the original PC BIOS clones were created, Wikipedia can tell you more.

Am I correct in assuming that this means the person writing the replacement has to have never used an Amiga before?

While it should (unfortunately) be pretty easy to come across this type of person these days, they're not going to do it out of the goodness of their heart. The two aros bounties for this total just over $1900.

Now I don't know how much work would be involved but I think that any developer taking on the task would ask for a little more than $1900. Plus somebody would need to actively go out and hunt a developer; after all somebody who's never used an Amiga is unlikely to be willing to know about the bounties in the first place.

Interesting to note that Cloanto have invested in bounty 1 even though they already have a license to use kickstart. Does this mean that they are still paying royalties for every copy of Amiga Forever sold? Or does it mean there may be an expiry date on the license that they have already acquired? Or is it just that they are darned nice guys??

Quote:

As long as one were able to recognise that a particular sub.b/add.b with immediate 1 is trying to update a byte-sized counter like ID_NestCnt, it would be relatively simple to replace it with a 32 bit add/sub with an appropriately shifted "1".

Sounds like a simple solution.

_________________
APOLLO the new 68K : www.apollo-core.com

@Pleng

Quote:

Am I correct in assuming that this means the person writing the replacement has to have never used an Amiga before?

No, I think you are not.

Remember the documented ASM listing of the Commodore Kickstart was printed and published !!

When you publish your source code you can NOT deny the people from learning from it, can you?

Even if the Kickstart sources would not have been published, in most parts of the free world its 100% legal to reverse engineer an OS.

_________________
APOLLO the new 68K : www.apollo-core.com