Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: Masjsta's A500 Vampire  (Read 1217 times)

0 Members and 1 Guest are viewing this topic.

guest11527

  • Guest
Re: Masjsta's A500 Vampire
« Reply #105 on: October 01, 2016, 06:03:59 PM »
Quote from: SpaceMonkey;814711
so would be a case of replacing the 040 & 060 libraries with Apollo specific or a new 080 lib

Yes, indeed.
 

Offline wawrzon

Re: Masjsta's A500 Vampire
« Reply #106 on: October 01, 2016, 06:22:03 PM »
Quote from: Thomas Richter;814710
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..
 

Offline majsta

Re: Masjsta's A500 Vampire
« Reply #107 on: October 01, 2016, 06:59:14 PM »
@spaceman88 here is best tutorial I have published 3 years ago:
https://www.youtube.com/watch?v=6r2RdbMzfQw
 

Offline wawrzon

Re: Masjsta's A500 Vampire
« Reply #108 on: October 01, 2016, 07:30:18 PM »
Quote from: wawrzon;814714
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.
 

Offline psxphill

Re: Masjsta's A500 Vampire
« Reply #109 on: October 01, 2016, 08:37:40 PM »
Quote from: Thomas Richter;814710
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.
 

Offline kolla

Re: Masjsta's A500 Vampire
« Reply #110 on: October 01, 2016, 09:48:51 PM »
Quote from: Thomas Richter;814712
Yes, indeed.


But a new cpu library has specifically been said will _not_ be needed :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline spaceman88

Re: Masjsta's A500 Vampire
« Reply #111 on: October 01, 2016, 09:49:53 PM »
Quote from: majsta;814717
@spaceman88 here is best tutorial I have published 3 years ago:
https://www.youtube.com/watch?v=6r2RdbMzfQw


 :-)
 

guest11527

  • Guest
Re: Masjsta's A500 Vampire
« Reply #112 on: October 01, 2016, 09:55:52 PM »
Quote from: kolla;814721
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?
 

Offline grond

Re: Masjsta's A500 Vampire
« Reply #113 on: October 02, 2016, 07:43:35 AM »
Quote from: psxphill;814720
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

  • Guest
Re: Masjsta's A500 Vampire
« Reply #114 on: October 02, 2016, 11:21:04 AM »
Quote from: grond;814732
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).
Quote from: grond;814732
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?  
Quote from: grond;814732
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.
 

Offline Cosmos

Re: Masjsta's A500 Vampire
« Reply #115 on: October 02, 2016, 11:55:39 AM »
Quote from: Thomas Richter;814734
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...

Offline SpaceMonkey

Re: Masjsta's A500 Vampire
« Reply #116 on: October 02, 2016, 01:04:17 PM »
Quote from: Cosmos;814735
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.
 

Offline Fats

Re: Masjsta's A500 Vampire
« Reply #117 on: October 02, 2016, 01:19:17 PM »
Quote from: Cosmos;814735
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.
Trust me...                                              I know what I\'m doing
 

Offline psxphill

Re: Masjsta's A500 Vampire
« Reply #118 on: October 02, 2016, 05:49:00 PM »
Quote from: grond;814732
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.
« Last Edit: October 02, 2016, 05:55:16 PM by psxphill »
 

Offline amiadudeorwat

Re: Masjsta's A500 Vampire
« Reply #119 on: October 02, 2016, 06:37:20 PM »
Quote from: psxphill;814745
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.