Masjsta's A500 Vampire

[SpaceMonkey]

Not really. The problem is to find a way to handle the vampire *despite* the copyright situation of exec. Actually, if you look back, it was also possible to support the 68060 on AmigaOs, even though exec does not support this CPU.

Hence, if done correctly, there is no need to fiddle with the exec sources at all, or to provide alternative exec sources. A processor library is all it takes - provided the CPU has the necessary properties.

so would be a case of replacing the 040 & 060 libraries with Apollo specific or a new 080 lib

[guest11527]

so would be a case of replacing the 040 & 060 libraries with Apollo specific or a new 080 lib

Yes, indeed.

[wawrzon]

A processor library is all it takes.

aha. ist also in eigener sache. das ist eher vertretbar. ist aber eine sache der vereinbarung zwischen dir und apollo team. wir haben da keine mitsprache..

[majsta]

@spaceman88 here is best tutorial I have published 3 years ago:
https://www.youtube.com/watch?v=6r2RdbMzfQw

[wawrzon]

aha. ist also in eigener sache. das ist eher vertretbar. ist aber eine sache der vereinbarung zwischen dir und apollo team. wir haben da keine mitsprache..

sorrx. have not noticed i answered in german. the essenz here is that even with os sources itself not being the subject the support for the apollo cpu with thors mmu libs are not the subject we can enforce, but rather a subject to agreement between thor and apollo team.

[psxphill]

Not really. The problem is to find a way to handle the vampire *despite* the copyright situation of exec. Actually, if you look back, it was also possible to support the 68060 on AmigaOs, even though exec does not support this CPU.

Hence, if done correctly, there is no need to fiddle with the exec sources at all, or to provide alternative exec sources. A processor library is all it takes - provided the CPU has the necessary properties.

If the vampire FPU, all the exceptions stack frames etc are compatible with the 060 then we already have the software. If you are running old software then the new mmx registers don't need to be saved, obviously task switching would need to be patched to save/restore the registers if you're running new software (like fpu register saving is already patched when an fpu is detected). It may be possible (and even desirable) to include that in the applications that use mmx, to reduce overhead on all task switches. We already have software for fast patching of instructions missing in the 060 as well.

[kolla]

Yes, indeed.

But a new cpu library has specifically been said will _not_ be needed

[spaceman88]

@spaceman88 here is best tutorial I have published 3 years ago:
https://www.youtube.com/watch?v=6r2RdbMzfQw

 :-)

[guest11527]

But a new cpu library has specifically been said will _not_ be needed

Well, and how do you suppose the extended registers will be saved?

[grond]

If the vampire FPU, all the exceptions stack frames etc are compatible with the 060 then we already have the software.

Exception stack frames are and FPU will be compatible with the 040. Contrary to 040 and 060 no instructions need to be trapped. For 882-only instructions there will be essentially what is inside the 040.library for FPU-emulation of those complex FPU-instructions but this will be inside a ROM where it can't be overwritten. Thus, the FPU will appear as being 882-compatible directly after power-on with no libs loaded. However, 040-FPU-code will execute faster than code compiled for 882 as it avoids the internal trapping mechanism.

All in all the 080 is far more compatible than any of 040 or 060.

[guest11527]

Exception stack frames are and FPU will be compatible with the 040. Contrary to 040 and 060 no instructions need to be trapped. For 882-only instructions there will be essentially what is inside the 040.library for FPU-emulation of those complex FPU-instructions but this will be inside a ROM where it can't be overwritten.  

If no instructions are trapped, what is the ROM good for if not for trapping the instructions? Ok, the mechanism is probably not a 68K trap in the strict sense, but why does that make any difference.

I just remember the uproar when Phase5 dared to put their 68060.library into ROM... a RAM-based library is more flexible, and simpler to replace in case of bugs. (Says me, who had bugs in 10 year old code of my 68060.library).

Thus, the FPU will appear as being 882-compatible directly after power-on with no libs loaded. However, 040-FPU-code will execute faster than code compiled for 882 as it avoids the internal trapping mechanism.

Huh, and then how does the CPU reach the ROM code? Why does it make a difference whether the CPU takes a "regular exception vector" or some "hidden vector" in terms of performance or compatibility?  

All in all the 080 is far more compatible than any of 040 or 060.

Really? Just because you put something in ROM that was otherwise in RAM? Sounds like a strange argument to me. Instead, you introduce a potential source of problem with having more registers that somehow have to be saved and restored on a context switch when they are used.

[Cosmos]

I just remember the uproar when Phase5 dared to put their 68060.library into ROM... a RAM-based library is more flexible, and simpler to replace in case of bugs

You are completely unaware of the reality...

Users want a computer easy to start = plug & play, all in rom...

When you use a car, you don't want to add some stuff into the motor to drive away... You want only a turn-key & start...

[SpaceMonkey]

You are completely unaware of the reality...

Users want a computer easy to start = plug & play, all in rom...

When you use a car, you don't want to add some stuff into the motor to drive away... You want only a turn-key & start...

Your sort of right, as an end user i just want to get in my car and drive from Manchester to London and I don't care how my engine work, but if my Sat Nav wants to go via Edinburgh then I would be interested in the reasons why.

I think the Apollo Team and Thomas could have a long discussion, off line on the merits and pit falls of each method.

[Fats]

Users want a computer easy to start = plug & play, all in rom...

I prefer upgradeability over startup speed. I don't part having part of an OS loaded from (SSD) disk.

[psxphill]

All in all the 080 is far more compatible than any of 040 or 060.

It is impossible to be more compatible with an 040 than an 040, any deviation from an 040 makes it less compatible. It might run software that wouldn't run on an 040, but that is a different thing. oxypatcher/cyberpatcher/etc already solved the problem of emulated instructions years ago. So being more compatible in your sense isn't even true.

I've many years experience in emulation and one of the things I've found is that it sounds great to make one thing emulate more than one thing (i.e. a cpu that can run 030, 040 & 060 software), but you eventually run into problems and split it out. Or at least you do if you have the source, or the developer with the source cares about your issue.

[amiadudeorwat]

It is impossible to be more compatible with an 040 than an 040, any deviation from an 040 makes it less compatible. It might run software that wouldn't run on an 040, but that is a different thing. oxypatcher/cyberpatcher/etc already solved the problem of emulated instructions years ago. So being more compatible in your sense isn't even true.

I've many years experience in emulation and one of the things I've found is that it sounds great to make one thing emulate more than one thing (i.e. a cpu that can run 030, 040 & 060 software), but you eventually run into problems and split it out. Or at least you do if you have the source, or the developer with the source cares about your issue.

Not to mention the lack of an FPU and MMU makes any software expecting either crash.  Also the piles of old games which don't require either which crash on the Vampire.