Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: TuKo on January 31, 2016, 07:59:51 PM
-
Dear all,
I'm very pleased to announce that I've received my card, from the first batch from majsta. I received it quickly as I'll be demonstrating it within next days in Switzerland to our local Amiga usergroup (http://www.clubamf.org/).
I'll continuously be updating this thread with pictures, comments and videos.
1) Unboxing and first tests
I received it with the SILVER core, which will be the default one everyone should receive. The card was well packaged and it included two mounts. Kipper2k made a small tutorial explaning how to install them (http://kipper2k.com/accel600.html).
The card :
(http://i.imgur.com/DiIdujc.jpg)
(http://i.imgur.com/upLJIVu.jpg)
Physical installation went fine and after some minutes my A600 (rev1.5) booted. My A600 is upgraded with A604n (http://amiga.resource.cx/exp/a604n), RTC clock and I'm using a RGB->VGA adapter and Rys MKII USB (http://retro.7-bit.pl/?lang=en&go=projekty&name=rys_mkii) adapter for my Logitech mouse (http://www.logitech.com/en-ch/product/mouse-m150?crid=7).
(http://i.imgur.com/kRVrdyT.jpg)
As you can see on the picture, my Amiga is showing ROM 3.1. The hardware ROM 3.1 is completely bypassed and only the dumped ROM inside Vampire is used. Why that ? It's because the Apollo team had to patch some routines to get the 128Mb fully adressed and standardize Vampire setups. It's also faster as it's acting more or less like a MapROM. Anyway, this part is not the most interesting one...
Then, I added my CF with 3.9bb2 (without ROM Update as it is known to cause problem) and it booted. After disabling FBlit which also cause graphic corruption at the moment, I then immediatly went to see my old friend Sysinfo.
(http://i.imgur.com/N5tuzGw.jpg)
I then headed to my favourite Amiga game... Simon the Sorcerer, running WHDLoad 18.2. It worked flawlessly and I even had less hickups than with my old ACA620 (http://amiga.resource.cx/exp/aca620).
So... yes, it's alive, it exists and it's just the fastest Amiga accelerator I've ever had.
The magic is there...
(http://files.frido.org/pictures/Simon-the-Sorcerer/simon_the_sorcerer-simon2.gif)
2) Silver core - my impressions
My first impression is exactly the same as the one when I went from my A1200 '030 to my shiny A4000 '060. It boots like a rocket and workbench is snappy as it could be in WinUAE.
Only thing that was a bit hard at start was to understand that the card takes a bit more time (I mean, no more than 1-2 seconds) than with the onboard CPU to boot or reboot. So when you want to shutdown your A600 and quickly power it on back, you'll have to wait some seconds.
I've been amazed to play a MP3 on my A600, it was just impossible until now !
So, at current state, Silver Core provides the user mostly speed and horse power. In the future, we will know how to work with P96 once the licencing thing has been sorted out.
3) Beta cores
I was in discussion with the Apollo team to join the testing team because I naturally love taking risks and testing new things. I'm that kind of user that will take time to push things to get last decimal of performance... adding real-use test case to the team will be my objective as I have no ASM knowledge. Taking this route, I have been warned that it might not be the most stable one, but I'm ok with that.
As I have access to latest beta cores, I installed Quartus software and flashed my card with the latest one and an USB Blaster (http://www.ebay.com/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313.TR3.TRC2.A0.H0.Xusb+blaster+altera.TRS0&_nkw=usb+blaster+altera&_sacat=0). Majsta wrote a tutorial (http://majsta.com/modules.php?name=News&file=article&sid=77)about this. I did it installing the latest version of Quartus on a Windows 10 x64 environnment.
First thing, and not the smallest one, is that it immediatly added about 20% of performance in SysInfo.
(http://i.imgur.com/Y2Iljyr.jpg)
But the big thing is this...
(http://i.imgur.com/KZAmxsd.jpg)
After some days with it and several core tested, I got OS3.9bb4 running (screenshot taken with Sgrab) :
(http://i.imgur.com/eOVI3eN.jpg)
-
Looks great! My card is coming soon I hope.
How compatible is it with games and demo's ?
-
impressive , but when will be this card for sell for example in Amigakit ? retroami to other internet shop ?
today this card is virtual for me :-) I don't like pay for virtual thing
-
haha! the vampire uproar reaches org.. welcome!
-
Looks great! My card is coming soon I hope.
How compatible is it with games and demo's ?
I haven't had time to try it a lot but I can say it's very compatible with most WHDload games. I focused on setting up a working workbench with P96 :-)
-
impressive , but when will be this card for sell for example in Amigakit ? retroami to other internet shop ?
today this card is virtual for me :-) I don't like pay for virtual thing
This review clearly shows it's not virtual.
You can order it from kipper2k (http://kipper2k.com/accel600.html).
-
This review clearly shows it's not virtual.
You can order it from kipper2k (http://kipper2k.com/accel600.html).
pay and then wait for five months or more ! thank for that business
-
pay and then wait for five months or more ! thank for that business
Considering this is a hobby project where cards are being assembled by a couple of people, I dont see how they could do instant delivery like mainstream massconsumption hardware.
Its that knowledge that makes people pre-order, so they are first in line once the cards are developed.
Hardly a new concept.
@Majesta/kipper2k Impressive hardware!
-
"Considering this is a hobby project where cards are being assembled by a couple of people"
exactly , this is big pain-problem Amiga computer !!
like I remember from half 90 years non-stop is the same problem , hobby project and wait wait wait for nothing
ppc shark vel sonnet crescendo 7200 super great card , but where are this card for buy ? :-)
the same problem for twenty year
and this is main reason why Amiga died
always have to wait for nothing
vampire should be now get for big production ! for many waiting people for that hardware
-
Hmmm now I just need an A600. Would be interested in an A1200 version though. Willl it run 060 demos is a question.
-
Would be interested in an A1200 version though. Willl it run 060 demos is a question.
Me too :)
-
Me too :)
Only demos that do not require FPU (FPU is not enabled at the moment).
-
"Considering this is a hobby project where cards are being assembled by a couple of people"
exactly , this is big pain-problem Amiga computer !!
like I remember from half 90 years non-stop is the same problem , hobby project and wait wait wait for nothing
ppc shark vel sonnet crescendo 7200 super great card , but where are this card for buy ? :-)
the same problem for twenty year
and this is main reason why Amiga died
always have to wait for nothing
vampire should be now get for big production ! for many waiting people for that hardware
Large scale production costs alot of money. Alot of money upfront requires *someone* to take that risk.
-
"Considering this is a hobby project where cards are being assembled by a couple of people"
exactly , this is big pain-problem Amiga computer !!
like I remember from half 90 years non-stop is the same problem , hobby project and wait wait wait for nothing
ppc shark vel sonnet crescendo 7200 super great card , but where are this card for buy ? :-)
the same problem for twenty year
and this is main reason why Amiga died
always have to wait for nothing
vampire should be now get for big production ! for many waiting people for that hardware
you may have noticed, that even when some hardware was being on sale in the "official" stores you named, hasnt saved the customers to wait weeks, months or maybe longer for the actual delivery. i think the vampire/apollo team is doing just fine in this comparison and by the way are keeping the price low without the handler margin.
-
Indeed, don't feed the troll please :laughing:
-
Tuko, nice quick review! Thats an impressive card!
The wolfes of Vampire team has done a fantastic job!
Those boys deliver
-
Drooling for an A500/2000 version
-
Indeed, don't feed the troll please :laughing:
Dont call troll just to give a good or bad opinion.
-
@tuko
Nice review and impresive card... the "problem" of this is that there are not enought cards for all with this low production =(
-
@tuko
Nice review and impresive card... the "problem" of this is that there are not enought cards for all with this low production =(
always the same problem welcome to Amiga-World :-) :hammer::hammer::hammer:
-
Hey - hold on a tick!
I thought this thing emulated an extremely fast 68020. The SysInfo shots show 68040. I wonder if with the proper 060 libraries installed what the "CPU" command shows? Any chance you can check this Mr Reviewer?
BTW Majsta / Kipper - this thing appears to be one absofrickenlutely awesome device! Thanks!
-
Hey - hold on a tick!
I thought this thing emulated an extremely fast 68020. The SysInfo shots show 68040. I wonder if with the proper 060 libraries installed what the "CPU" command shows? Any chance you can check this Mr Reviewer?
You don't really need to. The 68040.library adds additional floating point instructions the 68040 FPU does not execute natively. The vampire does not have a FPU, not even an incomplete one, so the motorola FPSP is not needed. The 68040.library also creates the MMU tables. The vampire doesn't have a MMU, so it's not needed either.
The 68060 was in that sense a bit more critical because it also had unsupported integer instructions the 68060.library had to add emulation support for. It also required a new exec scheduler - for the full 68060 - because the FPU stack frame changed.
-
Hey - hold on a tick!
I thought this thing emulated an extremely fast 68020. The SysInfo shots show 68040. I wonder if with the proper 060 libraries installed what the "CPU" command shows? Any chance you can check this Mr Reviewer?
BTW Majsta / Kipper - this thing appears to be one absofrickenlutely awesome device! Thanks!
http://apollo-core.com/knowledge.php?b=4&z=UPbX4l
-
@tuko
Nice review and impresive card... the "problem" of this is that there are not enought cards for all with this low production =(
There will be enough for everybody. People will just have to accept it'll be slow process (majsta and kipper2k can each solder at best 4-5 card per day).
A600 has been some many years without a such powerful upgrade, I'm sure the community can accept to wait some more weeks ;-)
-
Definitely the biggest hardware release for the A600 (and eventually the Amiga) for a very very long time.
The A500 and A1200 versions will be welcomed too.
I see that they have plans, beyond the "Gold" core, to implement more chipset aspects within the FPGA, using the rest of the host Amiga as time goes on. Personally I'd like to see decent AHI audio done before AGA emulation, but I'm not setting the roadmap.
Obviously this leads to a future standalone Vampire Amiga - FPGA and RAM and I/O - in the same lines as MiniMig, Mist and FpgaArcade. Maybe in a couple of years? I guess the clue's in the name here, Vampire :-)
-
I think the main difference between a vampired Amiga and a standalone FPGA Amiga is the possibility for extensions. I know there are ideas and prototypes for networking but what I would like to see is something that can be bought off the shelf with an PCMCIA or Zorro slot. A vampired A600 has at least PCMCIA so I can use network Cards. Even better would be a full Zorro bus board but I'm just dreaming.
-
Another user recived his Vampire 2 today, and have a blog that will be updated as he goes along using it.
http://davka.pl/articles/5/vampire-2-has-arrived
-
That accelerator looks awesome! Any reason why it wouldn't work for us ACA500 users? Looking at the layout, might just fit...
-
Obviously this leads to a future standalone Vampire Amiga - FPGA and RAM and I/O - in the same lines as MiniMig, Mist and FpgaArcade. Maybe in a couple of years? I guess the clue's in the name here, Vampire :-)
Accurate chipset cloaning is very time consuming. If they are to make a standalone board without using open source code, then they have a lot of work ahead of them. The downside of using GPL code is then they must release the CPU source as well, which seems unlikely. Perhaps they have already done all this groundwork from the Natami days.
The open source CPU is catching up - it will be interesting to see side by side comparisons for a real use case with the Replay (FPGAArcade board). Sure the Apollo core is faster, but I prefer being able to slow down and accurately run the A500/A1200 and Atari software as well when required.
/MikeJ
-
That accelerator looks awesome! Any reason why it wouldn't work for us ACA500 users? Looking at the layout, might just fit...
The developers would have to answer the details themselves, but regardless;
http://kipper2k.com/accel500.html
"Coming Soon to an A500 near you".
Soon is obvious a relative term in Amigaland, espesially since they are currently working hard to deliver the pre-ordered A600 boards.
-
@tuko
Nice review and impresive card... the "problem" of this is that there are not enought cards for all with this low production =(
i think that its actually favourable for the users and for the project, that this is an "organic" one, even if it needs some more patience. the product being introduced to public gradually allows enough time for feedback, reconsideration of features and the like.
that there is suddenly so much demand and interest is not the fault of the involved.
-
That accelerator looks awesome! Any reason why it wouldn't work for us ACA500 users? Looking at the layout, might just fit...
why would you want to have both vampire and aca500 built in at the same time?
-
why would you want to have both vampire and aca500 built in at the same time?
Because the 68k ACA500 is 14mhz and the Vampire isn't.
Looks like Kipper is working on an A500/A2000 acceleraror board, so that'll be nice. Might plug directly into the 68000 socket or 500 version externally?
Thing is, I'm using an ACA500 and ACA1221 outside my Phoenix equipped A1000. Hell of a combo (28mhz 020 works great!), but a Vampire solution, with AGA and super speed would be even better. :)
-
If you decide to go with a Vampire, you will put other accelerators in storage. My Blizzard 030/50 has served me well, but will be retired once Vampire A1200 version is developed and available for purchase.
-
Because the 68k ACA500 is 14mhz and the Vampire isn't.
Looks like Kipper is working on an A500/A2000 acceleraror board, so that'll be nice. Might plug directly into the 68000 socket or 500 version externally?
Thing is, I'm using an ACA500 and ACA1221 outside my Phoenix equipped A1000. Hell of a combo (28mhz 020 works great!), but a Vampire solution, with AGA and super speed would be even better. :)
what does 14mhz 68000 or 28mhz clocked 68020 get you, vampire doesnt? i would understand you if you would want to the option to use the genuine onboard 68000/7 cpu for timing/ compatibility reason, but the minor upgrades you mention likely ruin the original timings, some software might rely on, anyway.
-
Accurate chipset cloaning is very time consuming. If they are to make a standalone board without using open source code, then they have a lot of work ahead of them. The downside of using GPL code is then they must release the CPU source as well, which seems unlikely. Perhaps they have already done all this groundwork from the Natami days.
/MikeJ
I recently read that a lot of AGA software did run on the Natami so the groundwork was done already.
-
I recently read that a lot of AGA software did run on the Natami so the groundwork was done already.
Well... Natami was running with speed brakes on, the blitter and the bitplane dma were not running ram bursts at all, making them slower than necessary. The line drawer wasn't implemented either.
-
Drooling for an A500/2000 version
I second that! I'm so jealous for those getting these. Wish I had an a600 right now!
-
I second that! I'm so jealous for those getting these. Wish I had an a600 right now!
i think for those who are doomed to wait things may get even better, while others simply may enjoy them earlier. ;)
-
I received my vampire 600 Saturday, the thing is pretty fast. The board ships limited to the ecs screen modes but that will all change when the gold core is released. The sd slot does not currently work either but is rumored to do about 10MB/s when the new core arrives.
Mech
-
Thanks for sharing! It was great reading about the new Vampire card. Looking forward to read more about it in the future. I'm also waiting for the A1200 version. :) (or perhaps I will go bananas and get a 600... there is room for two Amigas... :python:)
-
There will be enough for everybody. People will just have to accept it'll be slow process (majsta and kipper2k can each solder at best 4-5 card per day).
A600 has been some many years without a such powerful upgrade, I'm sure the community can accept to wait some more weeks ;-)
I can wait to the 1200 version some day i just hope that there will be enough for all.
-
i think that its actually favourable for the users and for the project, that this is an "organic" one, even if it needs some more patience. the product being introduced to public gradually allows enough time for feedback, reconsideration of features and the like.
that there is suddenly so much demand and interest is not the fault of the involved.
I have this patience and now with this kind of reviews, lets see...
-
I can wait to the 1200 version some day i just hope that there will be enough for all.
Same here. I also can't wait for some nice "turbo" :) for A1200..., maybe some day. I just hope that it could be used with Mediator or Zorro... otherwise it will be good only for desktops :(.
-
Did some work on the Vampire socket. According to last majsta's message, I used some sandpaper to get the socket correctly mounted. Now it doesn't move a inch. I took my ACA620 mounting system to secure it ever more.
(http://i.imgur.com/Unf0qTE.jpg)
-
SysSpeed screenshot taken with current beta core (2988) :
(http://i.imgur.com/0UxiLEp.jpg)
-
New screenshot
(http://i.imgur.com/xA1H728.png)
-
I've ordered one of these too. I own the first Vampire-card now, and its freaking amazing too. But I love the new P96 features from V2.
I got the original 3.1 ROM in my A600 since V1 required kickstart3.1 Would not work correctly on 2.x
I read that the reason we have to send a ripped ROM from our A600s as a proof of licensing, but how can Majsta or Kipper2k know that these files are authentic and not pirated from a website?
-
how can Majsta or Kipper2k know that these files are authentic and not pirated from a website?
Does it really matter? :)
-
Does it really matter? :)
simply in case someone was trying to snipe the project from behind a fence because of this. hope they wont dare.
-
http://www.majsta.com/modules.php?name=News&file=article&sid=119
Majsta just posted a update to his site. Work in progress obviously.
-
At last - a screenshot showing OS3.9 Prefs!! That only took 6 months! :)
-
Does KingCON newer than 1.5 work? For example 1.8 or 40.x from Cosmos?
-
I read on the Apollo board, that Gunnar speaks of SAGA - Super AGA. But - will SAGA be AGA compatible? Will it be possible to run old DPaint IV AGA with HAM8 mode on the HDMI output, with plenty of RAM for animation? On the A1200 with old Indivision (mk1), I can run DPaint in nice 1024x768 HAM8 modes, but there is not enough chipram available to do animation at that resolution. Besides, it would be too slow. An implementation on FPGA could be _alot_ faster, and access far more RAM.
-
http://www.majsta.com/modules.php?name=News&file=article&sid=119
Majsta just posted a update to his site. Work in progress obviously.
From IRC
[02/02 20:01] Sooo. how far are you with the design ? all routed and done ???
[02/02 20:04] is it the same size as before ? (looks like it)
[02/02 20:12] slightly smaller
[02/02 20:12] and yes all done
[02/02 20:12] all routed and tested
[02/02 20:12] so now what, prototype?
[02/02 20:14] no prototypes
[02/02 20:14] we are done
-
At last - a screenshot showing OS3.9 Prefs!! That only took 6 months! :)
Jump in 1 min
https://vimeo.com/153621853
-
https://www.youtube.com/watch?v=hh7Yyoc1eD4
This is V1 core tho, as can be seen from the memory available. "only" 64 instead of 128megs.
-
Does KingCON newer than 1.5 work? For example 1.8 or 40.x from Cosmos?
is that stable? not to test beta with beta?
I read on the Apollo board, that Gunnar speaks of SAGA - Super AGA. But - will SAGA be AGA compatible? Will it be possible to run old DPaint IV AGA with HAM8 mode on the HDMI output, with plenty of RAM for animation? On the A1200 with old Indivision (mk1), I can run DPaint in nice 1024x768 HAM8 modes, but there is not enough chipram available to do animation at that resolution. Besides, it would be too slow. An implementation on FPGA could be _alot_ faster, and access far more RAM.
will you ever give them even any tiny credit? they have just fulfilled your postulates, in order to have you complaining about something else and painting dark future for the solution, without even knowing, how do they want to take it at. i doubt its motivating. id hate to think you want to disencourage people, even if in doubt it could be achieved under current circumstances.
-
Jump in 1 min
https://vimeo.com/153621853
Good, appears that Reaction works ok, hopefully the rest of the OS3.9 components in the ROM update will also work soon.
-
is that stable? not to test beta with beta?
It has some rather obscure 020+ asm stuff in it that I so far has not managed to run on FPGA 68k cores - that is exactly why I suggest it ;)
will you ever give them even any tiny credit? they have just fulfilled your postulates, in order to have you complaining about something else and painting dark future for the solution, without even knowing, how do they want to take it at. i doubt its motivating. id hate to think you want to disencourage people, even if in doubt it could be achieved under current circumstances.
You have not paid attention, I have been on and on about OS3.9 components and certain software I know are corner cases in terms of compatibility. I would think that it is a "good thing" to be pointed at such things. However, I never ever got any "yes, we are aware and looking at that" from Gunnar regarding my questions, also never any good answer to whether there is a plan for compatibility with 040 FPU (on MMU the answer has been clearer). Also never got any answer to whether he aims to sell the core outside the Amiga market, since he finds it worth while to compare with other, more "outside compatible" soft cores.
I started out as super enthusiastic, but ended up reluctant. I appreciate the accomplishments, but I am not thrilled about the attitudes and skeptical about the agenda.
Regarding SAGA - "Super AGA" - which we still don't know whether will be AGA compatible or rely on P96. At least I have not seen any clear answers. Personally I do not care about RTG as I want compatible, yet speedy AGA modes for the old software I use on Amiga., P96 was always a PITA to set up. I was always very clear about "more RAM" for animation, and importance of backwards compatibility with AGA software if there is to be a new "native chipset" implementation.
Then there is the question of "the enemy" which was discussed on the Apollo board earlier (whoever the enemy here is, I am guessing Jens), the issue I see of an attempt to "lock in", make the Apollo core "de facto standard" for all future 68k Amiga software, another licensing circus.
-
It has some rather obscure 020+ asm stuff in it that I so far has not managed to run on FPGA 68k cores - that is exactly why I suggest it ;)
If you want to test with really weird +68020 asm stuff I would suggest COP. Some real trickery with assembly.
However, what is really missing is a complete validation of the CPU core. There is currently no complete CPU conformance test and there might be some corner cases left.
However, I never ever got any "yes, we are aware and looking at that" from Gunnar regarding my questions, also never any good answer to whether there is a plan for compatibility with 040 FPU (on MMU the answer has been clearer).
I believe Gunnar is only targetting to an 64bit (double-precision) FPU compared to the full 80 bit extended precision FPU the Motorola CPUs all have. There is not too much software that depends on full extended precision, though, but it leaves a mood feeling.
What 68040 FPU compatibility means is also an open question. After all, the FPU would *also* have to emulate the 68040 FPU traps to implement all the transcendental functions and the 68040 stack frame for that. Which is hard to do, because most of the 68040 FPU stack frame(s) for the unimplemented FPU instructions are (mostly) undocumented.
So I would rather guess he's aiming at a partial FPU as in the 68040, but depend on a custom floating point support package.
Regarding SAGA - "Super AGA" - which we still don't know whether will be AGA compatible or rely on P96.
Currently, there is only a frame buffer that can be driven by P96 compliant driver. Whether there will be AGA in the FPGA at some point is another open question. Basically, it means that copper and blitter requires emulation, and that is *not quite* that simple. Natami missed a bit of blitter support, for example the line mode.
At least I have not seen any clear answers. Personally I do not care about RTG as I want compatible, yet speedy AGA modes for the old software I use on Amiga.,
Well, it depends on the software, but the planar AGA modes are surprisingly hard to manipulate and not very well targetted at high-speed applications. RTG chunky modes are much simpler to handle and it makes a lot of sense to offer them on the core.
Also, os-friendly software runs on RTG screens without change, so its quite a software library that profits from it.
P96 was always a PITA to set up.
Hmm. It's not the first time I hear that, though I had not that much trouble with it, actually. P96Mode has a rather strange user interface that does not conform well to the user-interface style guide, though.
Then there is the question of "the enemy" which was discussed on the Apollo board earlier (whoever the enemy here is, I am guessing Jens), the issue I see of an attempt to "lock in", make the Apollo core "de facto standard" for all future 68k Amiga software, another licensing circus.
Yes, for some reason unclear to me Gunnar considers Jens as "enemy". I don't really know why as he has personally not yet made any business with him. So I can only guess that this is some personal prejustice. I personally haven't had problems with Jens.
-
The project is going to continue and improvements will be made along the way, it will not make everyone happy, and for those that don't like it they obviously have other choices that serve their purposes. You cannot make everyone happy in Amigaland, the people who are happy will support the project and will buy it and those that don't wil probably chastise it and not buy it
-
I never ever got any "yes, we are aware and looking at that" from Gunnar regarding my questions
two things: because when you are busy actually doing things, you may tend not to answer to everybody anbd too every questions, especially doubtsand especially if you think things will clarify anyway in course of time. then as you heard, it may be a question of character. personally i hav not had all my questions answered either, but i dont mind so much. its better like this, rather like gunnar was busy to anwer to a number of remerks by certain á bit misinformed individuals flooding his own forum, you know.
make the Apollo core "de facto standard" for all future 68k Amiga software, another licensing circus.
it depends if the community will play along. i think either way it has dis- and advantages. i would simply lean back and watch, working on aros68k in the meantime. dont you enjoy the show any little bit? ;) do admit!
-
Yes, for some reason unclear to me Gunnar considers Jens as "enemy". I don't really know why as he has personally not yet made any business with him. So I can only guess that this is some personal prejustice. I personally haven't had problems with Jens.
are you sure? in public (a1k) he was mostly rather polite to jens, considering how jens (and a number of others) treated him initially. he even invited them to come over for a beer and demo, which i doubt was only for show, but who knows. its rather igor, who dropped few vague remarks, that might be read like you do. however i wouldnt be surprised if there was a littlke bit anymosity on whichever side. i mean, apollo/vampire may affect some business plans around the scene.
-
Natami missed a bit of blitter support, for example the line mode.
Which is ironic as the line mode was original suggested (IIRC) by r j Michael as it was a simple addition to the blitter engine. However it probably depends on where you start from, so if the Natami blitter didn't internally work exactly like the Amiga blitter then it may have been much harder to add. Plus just because something is simple in hardware, doesn't mean it's simple to figure it out in your head.
-
Which is ironic as the line mode was original suggested (IIRC) by r j Michael as it was a simple addition to the blitter engine. However it probably depends on where you start from, so if the Natami blitter didn't internally work exactly like the Amiga blitter then it may have been much harder to add. Plus just because something is simple in hardware, doesn't mean it's simple to figure it out in your head.
I guess the difference is how the memory works now compared to it worked back then. Back then, you generated the address, from there the RAS/CAS and you got the contents of the memory right away.
This is not so simple nowadays (unless you want to be very slow). You need to open up a page, prepare the page address, start the burst, burst the data in and out, and close the page again. If you just blit a block, it is quite obvious which accesses are linear and how to pipeline them. That's non-obvious with the harder to predict accesses of the line mode that are quite less regular.
Natami also had problems with overlapping blits. For the original Amiga blitter, the memory cycles were exactly documented, i.e. which source read which data when. You could start overlapping blits, i.e. the destination D writing to a memory address that is used as input on the next memory access. If you have a longer pipeline, such overlapping accesses will not work as before.
Thus, as always, there is a tradeoff between speed and compatibility.
-
Which is ironic as the line mode was original suggested (IIRC) by r j Michael as it was a simple addition to the blitter engine. However it probably depends on where you start from, so if the Natami blitter didn't internally work exactly like the Amiga blitter then it may have been much harder to add. Plus just because something is simple in hardware, doesn't mean it's simple to figure it out in your head.
It was Dale Luck not RJ.
Kamelito
-
Also, os-friendly software runs on RTG screens without change, so its quite a software library that profits from it.
Would you consider for example Deluxe Paint OS friendly? How does P96 deal with HAM8 for example? It is really that kind of software that I am thinking of, they are very much OS friendly, yet rely on the chipset.
PS - it is almost scary to see you answer on my long list of issues without really disagreeing with any of them! :D
-
two things: because when you are busy actually doing things, you may tend not to answer to everybody anbd too every questions, especially doubtsand especially if you think things will clarify anyway in course of time. then as you heard, it may be a question of character. personally i hav not had all my questions answered either, but i dont mind so much. its better like this, rather like gunnar was busy to anwer to a number of remerks by certain á bit misinformed individuals flooding his own forum, you know.
Well, but he did have time to edit and delete my questions, funny how that works.
At some point there was an Atari guy on the forum who asked some simple questions regarding compatibility, his question was answered with a small rant about how awesome the Apollo core is, none of which was really relevant to the guy's question. In my attempt to help him, I suggested maybe he should look at the Suska, if he had not already, an FPGA Atari clone with what appears aim for a 68030 compatible soft core. My comment was deleted with some weird excuse.
Anyhow, I have not bothered to sign up to the Apollo forum again, they can for sure do whatever the heck they want, I just hope people know what they are getting into.
it depends if the community will play along. i think either way it has dis- and advantages. i would simply lean back and watch, working on aros68k in the meantime. don't you enjoy the show any little bit? ;) do admit!
Of course I enjoy the spectacle, and in general I enjoy participating too, playing my role as the one who asks questions few others dare or bother to ask, give my opinion on whatever is going on, point out flaws etc. It is a community after all, just like in a family, not everyone can agree about everything all the time, and discussing in itself is a good mental exercise ;)
-
Well, Apollo team IRC channel is active.
As far as "knowing" what they get themselves into; I dont see anything terminally risky with this project ;)
Plus, there are constant releases of videos where people showcase WB and programs.
I guess thats a good baseline for most people.
-
Would you consider for example Deluxe Paint OS friendly?
No, not really. It is more that CBM tried for a long time to stay "Electronic Arts compatible".
How does P96 deal with HAM8 for example?
It replaces it by something far more useful, free color addressing aka "True Color". Can you create a workbench on HAM8 and profit from the additional color encoding?
HAM was a very unique Amiga feature, sort of an "online image compression" to allow colorful images with the limited bandwidth the chipmem bus had at its time. HAM is not very useful except for viewing images, and it is pretty hard to handle from the software side when you want to render images. It was useful to view existing rendered images, i.e. for image viewers.
If you have existing HAM8 images, then displaying them correctly on a rtg hardware is simple. The other direction (true color images on HAM8 screens) will introduce loss, and requires additional computations and approximations.
It is really that kind of software that I am thinking of, they are very much OS friendly, yet rely on the chipset.
Well, *depending on the chipset* actually means *not using the Os abstractions*. Admittedly, the Os "design" is unfortunately very much tight to the chipset, and it is neither the best design either, especially in the graphics areay.
But what DPaint does is that it goes directly on the hardware for some functions. While I do not know for sure, I believe this is partially due to the history of the program. For example, DPaint uses the blitter directly to draw rectangles or circles, even though the Os could do this equally well. Flood fill does not use the Os either. This is *probably* because the graphics algorithm requires one additional plane for filling (the TmpRas) and hence requires more memory for simple fill operations (yet it is more powerful by default as it can fill areas with patterns as well.) DPaint goes partially into private structures of the Os, hence causing compatibility problems.
Actually, the DPaint I source is available for inspection if you want to give it a try (Olsen has hacked it up a little bit, I fixed a couple of issues, now it runs with P96 fine).
PS - it is almost scary to see you answer on my long list of issues without really disagreeing with any of them! :D
Sorry for that. Better now? (-:
I certainly agree that the vampire is in its current state not a "product for end users", and its only half-ready. However, the parts that are ready raise expectations and give hope for more. So I wouldn't be so hard about this hardware. It's impressive what a home-brew design can do.
-
Would you consider for example Deluxe Paint OS friendly? How does P96 deal with HAM8 for example? It is really that kind of software that I am thinking of, they are very much OS friendly, yet rely on the chipset.
PS - it is almost scary to see you answer on my long list of issues without really disagreeing with any of them! :D
AFAIK (and been told) HAM8 is AGA only, a600 is ECS, so what are you talking about ??
-
Can you create a workbench on HAM8 and profit from the additional color encoding?
Yes I can, and you can too. There are even HAM6 and HAM8 icon sets around, and arexx scripts to generate HAM6 and HAM8 icons from images. It was also quite common back in the days to use HAM8 display for IBrowse and AWeb, with HAM8 capable datatypes for images.
If you have existing HAM8 images, then displaying them correctly on a rtg hardware is simple. The other direction (true color images on HAM8 screens) will introduce loss, and requires additional computations and approximations.
For being so simple, it has appeared to be very hard. I have quite a few HAM8 and ILBM24 based animations, but have not found anything that plays them well outside of native chipset and HAM8 mode.
Well, *depending on the chipset* actually means *not using the Os abstractions*. Admittedly, the Os "design" is unfortunately very much tight to the chipset, and it is neither the best design either, especially in the graphics areay.
Very true, but alas - that is where it is.
But what DPaint does is that it goes directly on the hardware for some functions. While I do not know for sure, I believe this is partially due to the history of the program. For example, DPaint uses the blitter directly to draw rectangles or circles, even though the Os could do this equally well. Flood fill does not use the Os either. This is *probably* because the graphics algorithm requires one additional plane for filling (the TmpRas) and hence requires more memory for simple fill operations (yet it is more powerful by default as it can fill areas with patterns as well.) DPaint goes partially into private structures of the Os, hence causing compatibility problems.
Also, AmigaOS never had a set API, over the 9 years the OS was commercially developed, it was changing quite a lot. The easiest way to cover all the OS revisions would be to not rely on the OS.
Actually, the DPaint I source is available for inspection if you want to give it a try (Olsen has hacked it up a little bit, I fixed a couple of issues, now it runs with P96 fine).
But it lacks animation, which is really what I am after.
I certainly agree that the vampire is in its current state not a "product for end users", and its only half-ready. However, the parts that are ready raise expectations and give hope for more. So I wouldn't be so hard about this hardware. It's impressive what a home-brew design can do.
In my view, any Amiga hardware since Phase5 died has been "home-brew", so that is not exactly new.
Speakin of "home-brew", what are your thoughts of the last BB3+4?
Where are the copyright ninjas now?
http://www.amiga.org/forums/showthread.php?t=70426
-
AFAIK (and been told) HAM8 is AGA only, a600 is ECS, so what are you talking about ??
Serisouly? You just arrived to the party or what?
I am talking about SAGA - aka "Super AGA":
http://apollo-core.com/knowledge.php?b=3¬e=275&z=T5Blnq
-
And you have the specifications of SAGA or did you just make things up and assume ?
Serisouly? You just arrived to the party or what?
I am talking about SAGA - aka "Super AGA":
http://apollo-core.com/knowledge.php?b=3¬e=275&z=T5Blnq
-
And you have the specifications of SAGA or did you just make things up and assume ?
Normally, when something is "super bla" it means that is is a superset of "bla", and hence also can do whatever "bla" can do. Compatible. And the specifications, even brief hints for what SAGA is aiming for, are _exactly_ what I have been asking about.
-
"Considering this is a hobby project where cards are being assembled by a couple of people"
exactly , this is big pain-problem Amiga computer !!
like I remember from half 90 years non-stop is the same problem , hobby project and wait wait wait for nothing
ppc shark vel sonnet crescendo 7200 super great card , but where are this card for buy ? :-)
the same problem for twenty year
and this is main reason why Amiga died
always have to wait for nothing
vampire should be now get for big production ! for many waiting people for that hardware
I would take one as a build it yourself project if that would cut down on the wait time..
Rich
-
A4000d, Cyberstorm MK2 128Mb (4x32Mb 50ns) 68060@66MHz
(http://i.imgur.com/EzuGMr4.jpg)
A600, Vampire 2, Dev Core 3024
(http://i.imgur.com/zkhgF2f.jpg)
AIBB :
(http://i.imgur.com/4xHyoBW.jpg)
-
Here is another one, with core 3024 x14
(http://i.imgur.com/6qCYNtw.jpg)
-
Doing some memory tuning with new WIP cores :
(http://i.imgur.com/2S4wWuF.jpg)
400Mb/s is approaching !
-
Yes I can, and you can too. There are even HAM6 and HAM8 icon sets around, and arexx scripts to generate HAM6 and HAM8 icons from images. It was also quite common back in the days to use HAM8 display for IBrowse and AWeb, with HAM8 capable datatypes for images.
Please stop making your own history. HAM8 modes are/were quite slow, and it was far from (quite) common to use them for anything else than showing images.
-
seems memory access is getting at how fast it may actually become theoretically. great.
-
Bustest 68k on AOS 4.1fe (SAM440ep)
(http://i.imgur.com/p5R3c3X.jpg)
-
WinUAE :D
-
Please stop making your own history. HAM8 modes are/were quite slow, and it was far from (quite) common to use them for anything else than showing images.
They are not really much slower than 8 bit plane modes, and I am not making up history, I used it myself on the A1200/060 and it certainly was not unheard of. What is really slow is decoding of jpegs.
-
They are not really much slower than 8 bit plane modes, and I am not making up history, I used it myself on the A1200/060 and it certainly was not unheard of. What is really slow is decoding of jpegs.
If i'm not mistaken shapeshifter (with proper driver) can use the HAM modes to emulate 16bit color MAC, and it was not that bad.
-
If i'm not mistaken shapeshifter (with proper driver) can use the HAM modes to emulate 16bit color MAC, and it was not that bad.
Yes, indeed it could (I even wrote a driver for it), but the mode had its issues - the typical tearing problems HAM causes.
The reason why that "works" is that you have - within Shapeshifter - a "blue print" of the image you want to render, i.e. basically you double the required RAM for the framebuffer.
This makes this mode quite unpractical for any serious image processing. As said, its main use was displaying images and "looking nice", but not so much to run any serious image processing or applications on it.
-
If I recall correctly, it was 15bit Mac display on HAM8 that worked best with Netscape.
-
https://vimeo.com/155866352
A quick AmTelnet test with the Vampire 600 V2
https://www.youtube.com/watch?v=_Y0Ffq8UQfc
Amiga 600 - Vampire V2-128 - Hollywood - Async FX
-
https://vimeo.com/155866352
A quick AmTelnet test with the Vampire 600 V2
https://www.youtube.com/watch?v=_Y0Ffq8UQfc
Amiga 600 - Vampire V2-128 - Hollywood - Async FX
That Hollywood video was Amazing! Vampire 2 really makes me drool :)
-
Please stop making your own history. HAM8 modes are/were quite slow, and it was far from (quite) common to use them for anything else than showing images.
I think people are forgetting *how* HAM modes could and were used in productivity software, because they are thinking of style-guide compliant software ie lots of menus, lots of windows all on a high res screen.
Thats not the best way to use HAM in productivity software.
Has everyone forgotten the split screen HAM modes with ImageFX? Useful even on an A500. I did it that way with 3 meg.
Or the the same HAM-8 mode in Brilliance was more or less indistinguishable from 24 bit, and eminently usable, on the '040 and '060 A1200 and A4000 I had anyway
Useful only for picture viewing? I don't think so, especially at a time when a 24 bit board cost more than a kitchen.
-
WIP Core. 21.5fps on Adoom (640x480x8)
(http://i.imgur.com/LiRr4mu.jpg)
-
Please stop making your own history. HAM8 modes are/were quite slow, and it was far from (quite) common to use them for anything else than showing images.
The thing that sold me on the amiga was Newtek Demo (running on a A2000 in MicroCenter) which if I'm not mistaken ran entirely in HAM mode while doing animations. When I found out the A500 had the same capabilities, I started saving my money.
From Newtek there was also Digipaint with not only used HAM mode but in my opinion was certainly one of the crispest UI of any of the paint programs(Faster than DPAINT). Photon Paint also used HAM as did Brilliance. The UI of those were not as crispy as Digipaint, but certainly not "slow" and certainly not uncommon.
HAM inadvertantly became one of the selling points of the amiga thus a huge part of the history.
Wen you were arguing with an Atari user over which machine was superior, they never had an answer for "What about HAM mode..."
-
http://btcw.me/vampire/MystiCube.mp4
A new little snippet from the world of Vampires.
-
http://btcw.me/vampire/MystiCube.mp4
A new little snippet from the world of Vampires.
Where can I get that backdrop?
-
Here is another one, with some re-sizing of the window.
http://btcw.me/vampire/MystiCube2.mp4
http://btcw.me/vampire/MystiCube3.mp4
FPS counter added.
https://www.youtube.com/watch?v=cuMRUJxRUaE&feature=youtu.be
-
Please stop making your own history. HAM8 modes are/were quite slow, and it was far from (quite) common to use them for anything else than showing images.
Pretty sure I used this back in the 90's
http://aminet.net/package/driver/moni/WBHacksAGA
-
https://www.youtube.com/watch?v=52dgJn0PijM&feature=youtu.be
Amiga 600 - Vampire V2-128 - Trauma by Unique
-
I think people are forgetting *how* HAM modes could and were used in productivity software, because they are thinking of style-guide compliant software ie lots of menus, lots of windows all on a high res screen.
It's a pity that the OS wasn't designed to work around HAM issues.
The left hand side of menus and windows is fine, because the border would use an indexed colour. The problem is in the right hand side where there is no guarantee how many pixels it would take before the r,g & b would get reloaded. Which is why you would often see horizontal lines across ham images when a menu was up.
If the OS extended the right hand edge of the layers by three pixels then it could add extra pixels to get the colour back to where it would be if the menu wasn't there. You could minimize the extra fringing in some circumstances, by using the closest index colour to the pixel to the right of the upper layer.
Unfortunately HAM wasn't taken seriously when the OS was designed. It was left over from when the Amiga was a games machine that output YUV, when it flipped to a computer that output RGB then it wasn't expected to be useful. It was going to be removed, but after all the years juggling to fit the functionality in agnus and denise there wasn't time/money/motivation to go through that again & then they would have spare space to add new functionality which would also have taken time.
It's pretty standard for commodore to build hardware that the software doesn't support.
-
For a great show up on how to use HAM besides a picture viewer you can check the game Kang Fu. Not sure if it's HAM8 or HAM6 (probably ham6)...
Some game features:
- 68020-060 compatibility
- enhanced graphics and sound using optional fastram
- hires gfx (non-interlaced) with approx. 1000 colours on-screen
- dual playfield with HAM (digitised HAM backgrounds in second playfield and digitised objects in foreground)
- 50 FPS update, fullframe scroll and objects
- 22 CDDA soundtracks
- joypad/joystick auto-detection
Too bad the game is not that fun to play, but the clever coding is great.
-
Simon The Sorcerer 2 RTG on 320x240x8
https://youtu.be/ffwPrVcWOwg
ADoom on 320x240x8
https://youtu.be/4DeJ66A-Aeo
-
Some RTG demos, provided by ShK https://vimeo.com/156628050 and https://vimeo.com/156679312
Also AROS bootdisk for those intrested. Not much to look at for the moment https://vimeo.com/156564965
-
first sign of life :)
AROS RTG test (Ignore the speed because Beta Core is in safe mode during on this test)
https://vimeo.com/156826082
-
Here is another one, with core 3024 x14
(http://i.imgur.com/6qCYNtw.jpg)
Ok, ram performance is >10 higher then a Cyberstorm 060, but the Vampire 2 cpu, with current core is <2 times faster.
Higher memory benchmarks does not gain any higher perfomance of the Vampire cpu ?
-
ADoom on 320x240x8
https://youtu.be/4DeJ66A-Aeo
WOW! ADoom is fast!
-
Ok, ram performance is >10 higher then a Cyberstorm 060, but the Vampire 2 cpu, with current core is <2 times faster.
Higher memory benchmarks does not gain any higher perfomance of the Vampire cpu ?
RAM performance only affects stuff that is not cached. Typical Amiga benchmark programs fit entirely into the cache so you don't see much effect of the RAM performance. However, if you look at e.g. the little fire demo effect flype coded, you'll notice that the vampire does something like sixty fps in hires. Just try doing half of that on a cyberstorm... :lol:
-
A podcast interview with BigGun;
http://amicast.ppa.pl/podcast/AMIcast_Episode_10.mp3
http://www.amigapodcast.com/2016/02/amicast-episode-10-biggun-apollo-team.html
-
RAM performance only affects stuff that is not cached. Typical Amiga benchmark programs fit entirely into the cache so you don't see much effect of the RAM performance.
I would hope that busspeedtest would be doing enough to avoid being affected by the data cache. Setpatch hasn't been loaded, so it shouldn't even be active.
As Apollo is super scalar then how fast it runs depends on the program you are running, it's entirely possible that it can run busspeedtest faster than real world programs. I've not looked at whether instructions take a variable number of clocks, but that could also favour one program over another.
Comparing benchmarks between different cpus is often a pointless exercise. The only thing you can take away from it is the speed the benchmark runs at, it would be a mistake to infer any other performance characteristics.
-
I've not looked at whether instructions take a variable number of clocks
Except for some bitfields (2 cycles), movem (1 cycle for each word to be moved), mul (2 cycles) and div (many cycles) all 68k instructions take 1 cycle on apollo. Some instruction combinations can be fused or bonded which makes the second instruction effectively take 0 cycles. EA modes are free (except for braindead double-indirect). As far as I remember all pipelines can execute all single-cycle instructions.
Pretty strong compared to an 68060 that could execute two instructions in one cycle only if they fit into four bytes.
-
Pretty strong compared to an 68060 that could execute two instructions in one cycle only if they fit into four bytes.
Yeah, so you can't take how fast one program runs compared to a 68060 and infer how fast another program will run.
A performance analyser that can show you how full the instruction pipelines are and how much time is spent waiting for memory accesses would be awesome.
-
I Really hope that they make the Vampire 1200 as those speeds are amazing :)
-
http://apollo-core.com/knowledge.php?b=6¬e=499&z=SZnEUD
-
http://apollo-core.com/knowledge.php?b=6¬e=499&z=SZnEUD
As I understand that is a P96 driver for Apollo developed by Jason McMullan. Why does it also exist another P96 driver by Thomas Richter dated 27/12/2015 ?
What happened? I am a bit confused. Two P96 drivers? Why?
Could anyone shed some light on this matter?
-
From EAB, a post by wawa.
here you go:
http://apollo-core.com/knowledge.php...e=499&z=SZnEUD
the new rtg driver is obviously aros based and runs on amiga kickstart. thats what needs to be done instead of stupid arguing. hope some of you will now understand and consider what is this "aros fanboyism runining your threads" about.. sigh..
@Gulliver
Seems like its AROS based, which is founded on the whole AROS and AOS3.x discussions, and potential limitations "enforced" upon Vampire from the operating system as it is without patches.
I copypasted it to here cause it highlits some of the issues if you want to evolve hardware based on Amiga legacy. I personally enjoy AOS3.x as it is (with Boingbag patches), but I have no problem understanding that its viewed as a limited foundation since BigGun (and others) have a roadmap regarding Vampire capabilities that cant be utilized within the current structure.
Then we enter into the whole licensing discussion, and pre-paying licensing, where you have to recoup the cost thru selling a unknown amount of Vampires.
Additionally, it comes at a cost, without any guarrantees of the OS in question will be futher developed.
I generally agree with Thomas's points of view, but I have no problem agreeing with BigGun's hesitation to build upon AOS since its not really being supported/developed, and paying license would just be throwing money into a hole that doesnt provide any guarrentees for advances.
-
Seems like its AROS based, which is founded on the whole AROS and AOS3.x discussions, and potential limitations "enforced" upon Vampire from the operating system as it is without patches.
So if it is Aros based, then it is free from absurd licensing schemes.
And I certainly think, that if it is not a retro project, but more of a project that will be further developed in the future, it is definately understandable why the Apollo Team chose Aros. Whilst AmigaOS 3.x is what I nowadays use, I understand it has little to no future, so choosing Aros was the right desition if you are not relying on nostalgia, but on future.
-
Not sure you listened to BigGuns podcast regarding the future of Vampire.
And the Apollo-Team havent really given alot of information regarding what they plan to do with regards to AROS or AOS, or which way they are going.
But BigGun did follow a train of thought during the podcast that if you want to stick to AOS on Vampire, knock yourself out, but for future ADVANCES AOS could be a problem due to its limitations.
Many will be more than content with the original, AOS, coupled with 060++ level speed and ram. Ive seen many comments along the line of "I use and love C64, Spectrum, Amiga etc with its inherit limitations, and use mainstream PCs for everything else".
BigGun acknowledges this clearly, but also looks at what Vampire potentially CAN do, and then concludes AOS, for its strenghts and weaknesses, will be too limited for his plans.
Listening to the podcast, BigGun seemed inclined to prefer AOS if it could be developed more freely, I guess opensource, but capitulates more or less to the realisation that this will most likely never happen.
Enter AROS.
-
Listening to the podcast, BigGun seemed inclined to prefer AOS if it could be developed more freely, I guess opensource, but capitulates more or less to the realisation that this will most likely never happen.
Enter AROS.
The only downside I can see with this is that they have been pretty clear that they aren't too bothered with 100% compatibility (especially MMU) and using AROS rather than AOS will make that easier.
If they committed to 68060 MMU compatibility then I would be less cynical. I find it morally annoying that Apollo is and never will be opensource, so nobody else can make it compatible either and making it incompatible is made easier by the work put into AROS for free. I suppose one day someone will reverse engineer their FPGA bitstream and fix it.
-
Well, they provide an affordable accelerator that will raise many/most users into 060++ performance range. Ontop of that its new hardware that are not liable to break any second due to age. Not sure whats "more moral"; selling anicent hardware for 100s or 1000s of dollars for that 1% more authenticity, than affordable hardware at a fraction of the price...?
As far as MMU and FPU; they are focusing on the core functionality for the moment. The question "do we want MMU" was raised in Apollo-Team IRC channel last week, and I think only 1 of the people in there showed any real intrest in it (im fully aware that the 56 people on average) that idle there are probarly not representative).
Regardless, there are plenty of software test demostrations released by users that demostrates rather good compability. 100% compability to what tho? I remember many programs I had on A500 didnt work on my A1200. Most issues could be fixed using Relokick or changing parameters in bootup menu, but 100% compability seems like a farfetched goal when the issue could be poorly written programs.
-
As far as MMU and FPU; they are focusing on the core functionality for the moment. The question "do we want MMU" was raised in Apollo-Team IRC channel last week, and I think only 1 of the people in there showed any real intrest in it (im fully aware that the 56 people on average) that idle there are probarly not representative).
Do these people even know what an MMU can be used for?
-
The only downside I can see with this is that they have been pretty clear that they aren't too bothered with 100% compatibility (especially MMU) and using AROS rather than AOS will make that easier.
If they committed to 68060 MMU compatibility then I would be less cynical. I find it morally annoying that Apollo is and never will be opensource, so nobody else can make it compatible either and making it incompatible is made easier by the work put into AROS for free. I suppose one day someone will reverse engineer their FPGA bitstream and fix it.
I would find it highly ironic if Apollo core is to depend on AROS because of compatibility issues. The entire point of Apollo should be to provide a compatible 68k core, right? If it is incompatible to the point where running existing operating systems becomes a hassle, then why bother? We can run AROS on much, much faster and cheaper hardware anyways :)
-
@kolla
Regardless of knowledge of MMU, Ive gotten the impression that Apollo-Team is focusing on other aspects of the core/FPGA at the moment.
There is a old thread regarding MMU on EAB with Toni weighting in;
http://eab.abime.net/showthread.php?t=44003
And again, if people want to run AOS on Vampire, noone is stopping them, now or in the future. But for longterm development of more advanced features, AROS might be the way forward.
-
@kolla
Regardless of knowledge of MMU, Ive gotten the impression that Apollo-Team is focusing on other aspects of the core/FPGA at the moment.
Sure, they never really cared much about MMU.
There is a old thread regarding MMU on EAB with Toni weighting in;
http://eab.abime.net/showthread.php?t=44003
And again, if people want to run AOS on Vampire, noone is stopping them, now or in the future.
Even if the Vampire requires a special kickstart on board, with patched/replaced exec.library?
BTW - that eab-thread is way old, Toni may have other opinions today ;)
-
As I understand that is a P96 driver for Apollo developed by Jason McMullan. Why does it also exist another P96 driver by Thomas Richter dated 27/12/2015 ?
What happened? I am a bit confused. Two P96 drivers? Why?
Could anyone shed some light on this matter?
One is Free with a capital F, the other isn't I guess.
-
@kolla
Regardless of knowledge of MMU, Ive gotten the impression that Apollo-Team is focusing on other aspects of the core/FPGA at the moment.
There is a old thread regarding MMU on EAB with Toni weighting in;
http://eab.abime.net/showthread.php?t=44003
for what i see tonis comments in this thread exactly reflect gunnars and the apollo teams members view on the issue. i dont think anything has changed since then.
And again, if people want to run AOS on Vampire, noone is stopping them, now or in the future. But for longterm development of more advanced features, AROS might be the way forward.
at this point there is no talk about running aros on vampire as default. if im correct, what happens is that there are currently certain extensions to kickstart based on aros code, but still in order to have genuine workbench and whole os run on it, only with additiona features. as soon as aros kickstart be improved, it can wholly replace the genuine one, and then aros can perhaps replace 3.x or whatever system revision one would be running on vampire. this should be left to users and be proposed at a point when using aros has no negative implications for the user in terms of speed or compatibility. but if we want it to happen in the future the work on it must be undertaken immediately.
-
One is Free with a capital F, the other isn't I guess.
No, none of them are legitimate, unfortunately. Gunnar decided against licensing P96, which means that the drivers cannot be used on solid grounds.
-
As I understand that is a P96 driver for Apollo developed by Jason McMullan. Why does it also exist another P96 driver by Thomas Richter dated 27/12/2015 ?
What happened? I am a bit confused. Two P96 drivers? Why?
Could anyone shed some light on this matter?
im not involved or have any internal knowledge, but it looks like that there is a p96 driver (developed by thor) that has been presented previously in high resolution videos about vampire functionality. this driver is subject to licensing issues and was only available for testing so far. the licensing parties could no be found or issues could not be solved to the advantage of parties, so as i have also proposed in another thread about an fpga-arcade rtg driver, apollo team has in the meantime got into an agreement with another developer to develop a free driver. since the developer in question is a core member of aros team, its pretty certain that the driver is based on aros cybergraphics framework which is free but should be compatible to genuine cgx and therefore to p96.
-
So how about the licensing issue with "Workbench kickstarts" on apollo core?
Does the apollo core need a patched exec.library or not?
-
No, none of them are legitimate, unfortunately. Gunnar decided against licensing P96, which means that the drivers cannot be used on solid grounds.
How is an AROS based driver not legitimate?
EDIT - oh, it is still P96? Crap :)
How can it be P96 driver if it is based on AROS? AFAIK AROS does not use P96, but their own RTG based around CGfx3.
-
So how about the licensing issue with "Workbench kickstarts" on apollo core?
Again, Gunnar decided against licensing, so you'll have to use AROS.
Does the apollo core need a patched exec.library or not?
The current version does, due to its inability to implement autoconfig for its on-board RAM.
-
How can it be P96 driver if it is based on AROS? AFAIK AROS does not use P96, but their own RTG based around CGfx3.
If the driver implements the P96 API, the problem remains - no license. If it only uses CGfx, I guess they'll have to deal with whether or not this is a legitimate option for CGfx. The latter I do not know. For P96, the situation is quite clear: No license, not legal.
-
The "Free RTG SAGA Driver" is a P96 card driver. I just had a quick look through and compared it to mine.
"Does the apollo core need a patched exec.library or not?
The current version does, due to its inability to implement autoconfig for its on-board RAM. "
Replay doesn't ;)
-
No, none of them are legitimate, unfortunately. Gunnar decided against licensing P96, which means that the drivers cannot be used on solid grounds.
AROS Cybergraphics is illegal?
Has Frank Mariak claimed so? If so, then is P96 itself illegal for the same reason?
-
If the driver implements the P96 API, the problem remains - no license. If it only uses CGfx, I guess they'll have to deal with whether or not this is a legitimate option for CGfx. The latter I do not know. For P96, the situation is quite clear: No license, not legal.
The current P96 driver is one thing(Though TBH you cannot say what Jason based his design on. I'm sure I could ask and give you his answer.)... the future AROS driver is a completely different story as it is to be based on the AROS hidd design. ;)
-
If the driver implements the P96 API, the problem remains - no license. If it only uses CGfx, I guess they'll have to deal with whether or not this is a legitimate option for CGfx. The latter I do not know. For P96, the situation is quite clear: No license, not legal.
aros includes cybergraphics which is open source reimplementation of cgx standard since ever. aros native drivers are based on this. do you argue that this is illegal? if so you must argue aros is illegal as a whole because it reimplements amiga functionality.
once again. i dont know details, but i doubt the driver jason wrote consists of p96 .card and .chip files. if its aros driver that just iterfaces to the system in form of another patch as cgx or p96 did, but independently of these, i dont see licensing issues.
-
AROS Cybergraphics is illegal?
As long as it is based on the P96 API, it is. There is likely a native CGfx API, though.
Has Frank Mariak claimed so?
I do not know what the conditions are for a third party to offer a CGfx driver. I can only tell you want the conditions for the P96 API are.
Currently, the drivers use the P96 API, and *that* is not valid.
-
As long as it is based on the P96 API, it is. There is likely a native CGfx API, though.
I do not know what the conditions are for a third party to offer a CGfx driver. I can only tell you want the conditions for the P96 API are.
Currently, the drivers use the P96 API, and *that* is not valid.
Doesn't P96 implement the CGFX API too?
Did a lawyer who specialises in Western Intellectual Property law tell you that this is illegal or is it just your opinion as a lay person?
-
Doesn't P96 implement the CGFX API too?
Did a lawyer who specialises in Western Intellectual Property law tell you that this is illegal or is it just your opinion as a lay person?
[troll]
Yes it does therefore P96 is illegal and should not be used period. ;)
[/troll]
-
aros includes cybergraphics which is open source reimplementation of cgx standard since ever. aros native drivers are based on this. do you argue that this is illegal?
No, I do not claim this. I do not know. This is something the AROS team should better check with the CGfx authors.
if so you must argue aros is illegal as a whole because it reimplements amiga functionality.
I do not know what the situation for AROS as a whole is. But my understanding of the situation is the following: Any IPs CBM ever had on the kickstart surely run out by now, and as long as AROS authors weren't stupid enough to copy code from the Kickstart, this should likely be fine.
once again. i dont know details, but i doubt the driver jason wrote consists of p96 .card and .chip files.
That's however how I understand the situation. It is a P96 driver that can be used through the AROS CGfx emulation, which again has a P96 driver emulation. This is *not* legit. It should really go directly through AROS (or, depending on what the situation with the CGfx emulation is, through CGfx).
if its aros driver that just iterfaces to the system in form of another patch as cgx or p96 did, but independently of these, i dont see licensing issues.
Neither CGfx nor P96 drivers interacted with the system through patches. Both have a native interface. The patches are done by P96 and/or CGfx core components.
-
Doesn't P96 implement the CGFX API too?
Did a lawyer who specialises in Western Intellectual Property law tell you that this is illegal or is it just your opinion as a lay person?
What exactly do you expect from me? That I give you a legal opinion? IANAL.
My opinion is simply that: If you're basing your work on the work of others, you'll better have an agreement with this other party. If this other party wants payment, and you don't want to pay, then this agreement does not exist, quite the opposite. Full stop, end of story.
-
That's however how I understand the situation. It is a P96 driver that can be used through the AROS CGfx emulation, which again has a P96 driver emulation. This is *not* legit. It should really go directly through AROS (or, depending on what the situation with the CGfx emulation is, through CGfx).
i see. you must be better informed in this respect, so if it is like you say i fully agree with this statement.
Neither CGfx nor P96 drivers interacted with the system through patches. Both have a native interface. The patches are done by P96 and/or CGfx core components.
my understanding is that rtg systems on amiga were implemented patching appropriate functions of graphics library. is that wrong?
-
my understanding is that rtg systems on amiga were implemented patching appropriate functions of graphics library. is that wrong?
No, that's completely correct. It is, however, not the driver that patches the graphics.library. It is - for P96 - the rtg.library (core component) or - for CGfx - the cybergraphics.library. The driver goes through a well-documented API of the rtg.library.
-
No matter what the legal status is, P96 is crap and should be avoided.
-
This is something the AROS team should better check with the CGfx authors.
Oh my, what rock have you been living under?
As you perhaps know, CGfx merged into MorphOS around 15 years ago, along with MUI etc. MorphOS and AROS have done what "the people with the name" (your side, I presume) never managed - cooperate! The MorphOS team and AROS team have worked together on many things, shell and CLI commands and APIs. The CGfx thing was agreed upon a long time ago.
-
Yeah, so you can't take how fast one program runs compared to a 68060 and infer how fast another program will run.
You never can.
A performance analyser that can show you how full the instruction pipelines are and how much time is spent waiting for memory accesses would be awesome.
They usually don't wait for mem because memory is clocked at twice the core clock and 32 bit wide. The caches prefetch so unless you have a random access pattern, data will be in the caches. The D-cache can provide 8 bytes of data to the ALUs per cycle and accept another 8 bytes from the ALUs in the same cycle. The I-cache can provide 16 bytes worth of instructions to the core per cycle.
As I understand that is a P96 driver for Apollo developed by Jason McMullan. Why does it also exist another P96 driver by Thomas Richter dated 27/12/2015 ?
What happened? I am a bit confused. Two P96 drivers? Why?
The first driver could not be used because of a lacking permission so a second one was written which is not using any knowledge provided by other parties. Jason implemented the driver completely from scratch without inspecting other people's work. The driver works on both AmigaOS and AROS so don't be confused by the "based on AROS" bit.
The only downside I can see with this is that they have been pretty clear that they aren't too bothered with 100% compatibility (especially MMU) and using AROS rather than AOS will make that easier.
Where did you read that? It's bull%&$#?@!%&$#?@!%&$#?@!%&$#?@!. The fact is that the MMU was hardly used in the Amiga. Most Amiga people don't even know what its purpose is. On the other hand some features of an MMU (address translation, to be precise) make memory access MUCH slower. If anyone wants an MMU, there in fact is a chance that it will be implemented. But there's a catch: with so much work do be done on the core, it's a matter of priorisation. FPU and even 64bit processor modes are more important right now that an MMU that isn't even used for anything. Of course, some UNIX or Atari people could be interested in a fast 68k that also has some MMU. But the project is about Amiga. If there is so much interest in an MMU, there needs to be an incentive for the main developers. This incentive is money (yes, sorry, it's a capitalist world). If there is money to be earned (which may be money to be invested in all this again), there must be some interest in an MMU. So set up some sort of funding and it may happen. If you still only want an MMU because the 060 had one, well, I don't think you really need it.
If they committed to 68060 MMU compatibility then I would be less cynical.
Again, what for? The apollo core is more 68k compatible than any other 68k processor. There never even was a standard MMU for 68k, they were all different. The 68000, 68010 and 68020 never even had one, the 68020 could be provided with an extra chip comprising the MMU (68851). I think there was one (1) Amiga processor board that had the 851 and was intended to be used for UNIX. Some but not all 030s, 040s and 060s have an on-chip MMU. There are like three Amiga programs in total making use of it.
I find it morally annoying that Apollo is and never will be opensource
You probably also find it morally annoying that you don't get free housing and food.
making it incompatible is made easier by the work put into AROS for free.
This is utter bull%&$#?@!%&$#?@!%&$#?@!%&$#?@!. You can run DOS on an i7. But you can't use the i7's 64bit mode in DOS. That's the same situation as with AmigaOS 3.1 and the apollo core and the reason why only AROS makes it possible...
I suppose one day someone will reverse engineer their FPGA bitstream and fix it.
It will be the day right after somebody reverse engineers the i7 to make its 64bit mode DOS compatible.
No, none of them are legitimate, unfortunately. Gunnar decided against licensing P96, which means that the drivers cannot be used on solid grounds.
This is not true. You make such statements rather frequently only to then point out that you are not a lawyer. I'm a patent attorney by profession (with a background in microchip development) so I am not a lawyer either but I do understand something about the legal situation. And I don't see a reason why a piece of software that was written without relying on non-disclosed knowledge would be illegal solely for the reason that it is intended to interface somebody else's software. If it were, this would be Microsoft's dream come true.
I understand that you don't like the availability of a free RTG driver. BigGun often stated that the original P96 authors deserved payment for their work that meant important technical progress for the Amiga. He wanted to have them get this money. For reasons unknown to me it was not possible to get an agreement with the original P96 authors (in fact it looks like they never even responded to any request for license but I don't know the details). Now it looks like Hyperion bought the exclusive rights to P96. They do not intend to develop it any further. They just want to use it to make more money. While that is legitimate, it is nothing that the apollo team has to accept if there are legal and cheaper alternatives.
Does the apollo core need a patched exec.library or not?
The 128MB RAM in an A600 need some changes in the standard memory map which are not supported by the A600 ROMs without patching. If you want to run the apollo core in its 64 bit mode, obviously you need to patch the context switching mechanism. These are only two of the issues with an unpatched ROM.
Again, Gunnar decided against licensing, so you'll have to use AROS.
Not true either. The user will be able to flash any ROM you want. But in order to run, it will have to be patched for the apollo core.
If the driver implements the P96 API, the problem remains - no license. If it only uses CGfx, I guess they'll have to deal with whether or not this is a legitimate option for CGfx. The latter I do not know. For P96, the situation is quite clear: No license, not legal.
...and not true.
I do not know what the conditions are for a third party to offer a CGfx driver. I can only tell you want the conditions for the P96 API are.
Let me put it like this: it's not a well thought out licensing model. It is circumvented by the mere fact that the apollo team doesn't agree to the license terms offered. As with any contract, you can simply not agree to the conditions and not sign a contract.
My opinion is simply that: If you're basing your work on the work of others, you'll better have an agreement with this other party. If this other party wants payment, and you don't want to pay, then this agreement does not exist, quite the opposite. Full stop, end of story.
No, the story goes on. You can do the same without basing your work on the work of others. And there is nothing that would stop a user from mixing your work with that of others.
-
What exactly do you expect from me? That I give you a legal opinion? IANAL.
My opinion is simply that: If you're basing your work on the work of others, you'll better have an agreement with this other party. If this other party wants payment, and you don't want to pay, then this agreement does not exist, quite the opposite. Full stop, end of story.
Does WINE have an agreement with Microsoft for cloning the Windows interfaces?
Do the P96 owners have an agreement with Frank Mariak for cloning the CGX interfaces?
The answer is no in both cases.
"ZOMG! Illegal!"
-
No, that's completely correct. It is, however, not the driver that patches the graphics.library. It is - for P96 - the rtg.library (core component) or - for CGfx - the cybergraphics.library. The driver goes through a well-documented API of the rtg.library.
i think its self explanatory that its not the particular driver client but the main library that patches the system. same way it would have to be implemented if aros cybergraphics was to be used instead of p96.
-
No matter what the legal status is, P96 is crap and should be avoided.
How do you come to this conclusion? Or is it just the typical prejudice from your side?
-
Where did you read that? It's bull%&$#?@!%&$#?@!%&$#?@!%&$#?@!. The fact is that the MMU was hardly used in the Amiga.
Excuse me, but apparently, you do not know what you're talking about. You cannot safely transmit data via DMA on an Amiga system without some MMU magic. This is an issue with the cache of the 68060 and 68040 CPUs. The only other alternative is to disable the cache completely while a DMA is running.
Most Amiga people don't even know what its purpose is.
So, people as you, I suppose?
On the other hand some features of an MMU (address translation, to be precise) make memory access MUCH slower.
As in, how much, for example? It creates actually no additional wait states for the 68040 or 68060, and even needs to be enabled for handling DMA correctly, as stated above. It introduces one additional cycle for the 68030, but there also the MMU avoids an issue/a defect of the 68030 cache.
Look, it's ok if you don't know, but please don't make such statements then.
There never even was a standard MMU for 68k, they were all different. The 68000, 68010 and 68020 never even had one, the 68020 could be provided with an extra chip comprising the MMU (68851). I think there was one (1) Amiga processor board that had the 851 and was intended to be used for UNIX. Some but not all 030s, 040s and 060s have an on-chip MMU. There are like three Amiga programs in total making use of it.
There are certainly more than three. Let me count: MuForce, MuGA, MuFastROM, MuFastZero, MuFastChip, MuEVD, MuScan, MuRedox, COP, any device driver going through CachePreDMA and CachePostDMA, the virtual memory hacks I've seen, Enforcer for sure, the series of Cyber-Tools such as CyberGuard and CyperPatcher, the 68060.library and the 68040.library, also the 68030.library. While I haven't counted, that's more than four.
I understand that you don't like the availability of a free RTG driver.
No. I don't like taking other's people's work for selling my own work, even more so when first coming to an agreement with them ("We only use this for testing and come and pay you as soon as we make profit") and then later on run away as soon as it involves payment.
Excuse me, you haven't been involved, so you cannot know, but again, please do not make statements if you do not know.
BigGun often stated that the original P96 authors deserved payment for their work that meant important technical progress for the Amiga. He wanted to have them get this money. For reasons unknown to me it was not possible to get an agreement with the original P96 authors (in fact it looks like they never even responded to any request for license but I don't know the details).
Excuse me, I've been a bit more involved in the whole process. Gunnar didn't want to license. There was an offer on the table by Hyperion, in fact.
Now it looks like Hyperion bought the exclusive rights to P96. They do not intend to develop it any further.
Excuse me, that's neither correct. That's just Gunnar's interpretation of the answer.
They just want to use it to make more money.
And why exactly is that a problem?
While that is legitimate, it is nothing that the apollo team has to accept if there are legal and cheaper alternatives.
Which, by pure coincidence, also use the P96 API? Ok, if they want to go for free, go for AROS completely and do not rely on the P96 API in first place.
The 128MB RAM in an A600 need some changes in the standard memory map which are not supported by the A600 ROMs without patching.
Yes, they are. It's called autoconfig and supported by the Os ROM. Expansion, to be precise. Again, you do not seem to know, but here I am and tell you that it's all possible.
If you want to run the apollo core in its 64 bit mode, obviously you need to patch the context switching mechanism. These are only two of the issues with an unpatched ROM.
No, there are no issues with the original ROM. You just have to know how and why. Guess how an 68060 can work in an original unmodified system? It also requires a change in the context switching mechanism, yet I do not need a custom ROM.
Let me put it like this: it's not a well thought out licensing model. It is circumvented by the mere fact that the apollo team doesn't agree to the license terms offered. As with any contract, you can simply not agree to the conditions and not sign a contract.
It's entirely the choice of Gunnar to sign or not sign a contract, based on personal observations that might or might not be real. But if you do not sign, then you cannot use the work of others. Full stopo. I cannot offer a P96 driver if I don't want to pay for P96. I cannot offer a patched Kickstart if I do not pay for the kickstart. It's really quite simple.
No, the story goes on. You can do the same without basing your work on the work of others.
If that is what would happen, then yes.
And there is nothing that would stop a user from mixing your work with that of others.
Yes, there is. It is called "Copyright" and "licensing conditions". There is "normal use" of a work, i.e. I use the binary as intended. What I cannot do is simply take the binary of somebody else, patch it up and deliver it as part of my product. Or base my product on an API of a closed product that, as intended by the authors, requires licence payments.
If Gunnar wants to go for AROS, that's completely fine. But then, please stick to the AROS work and do not depend on P96 or a (patched) Kickstart.
-
Oh my, what rock have you been living under?
I don't *care* for AROS or CGfx. That's why I said "they probably need to check with the CGfx authors". Is this a wrong statement? No.
As you perhaps know, CGfx merged into MorphOS around 15 years ago, along with MUI etc. MorphOS and AROS have done what "the people with the name" (your side, I presume) never managed - cooperate!
Wait a minute! Just because my software isn't your flavour of "free", you call that "lack of cooperation"? Actually, there have been quite some cooperation in the Amiga land from my side. Look at MuForce, for example. This thing wouldn't have come to life without cooperation with Mike Sinz.
Os 3.9 wouldn't have come to life without cooperation with Haage and Partner, and people like Olaf Barthel.
The MorphOS team and AROS team have worked together on many things, shell and CLI commands and APIs. The CGfx thing was agreed upon a long time ago.
Then that's reluctant to know for AROS and Gunnar's team. I never stated the opposite. I just said "it needs to be clarified".
-
No, that's completely correct. It is, however, not the driver that patches the graphics.library. It is - for P96 - the rtg.library (core component) or - for CGfx - the cybergraphics.library. The driver goes through a well-documented API of the rtg.library.
I'm confused about the whole P96 situation, as I'm sure 90% of the people are on here.
Is "rtg.library" the P96 dynamic interface library? Like a Windows ".DLL" or Linux ".so"?
If so then what's stop anyone from writing an "rtg.library" with the same function signatures & addresses as the P96 version?
Any 3rd party software will see the "rtg.library", load it, map the functions and run without ever using your code or libraries. Why would a license for P96 be required?
I'm asking as I'm genuinely interested since this is a very common case software that doesn't require a license of any kind.
If they did use P96 code, or libraries then of course that's completely different and would absolutely require a license to do that.
Thanks,
Andy
-
I don't *care* for AROS or CGfx. That's why I said "they probably need to check with the CGfx authors". Is this a wrong statement? No.
Wait a minute! Just because my software isn't your flavour of "free", you call that "lack of cooperation"? Actually, there have been quite some cooperation in the Amiga land from my side. Look at MuForce, for example. This thing wouldn't have come to life without cooperation with Mike Sinz.
Os 3.9 wouldn't have come to life without cooperation with Haage and Partner, and people like Olaf Barthel.
Then that's reluctant to know for AROS and Gunnar's team. I never stated the opposite. I just said "it needs to be clarified".
Actually the cooperation that an AROS developer got from Hyperion was something like this. Sure we'll do the AHCI driver for Hyperion any way you could help us with what we need for reaction? response "I'll email you tomorrow" ... silence. ;) and that is why the AHCI driver had to be worked on by someone else. ;)
-
How do you come to this conclusion? Or is it just the typical prejudice from your side?
No, I find the P96 software cumbersome. I always chose CGfx when I can, simply because it is less ridden with annoying bugs and has Prefs interface I can relate to.
-
Is "rtg.library" the P96 dynamic interface library? Like a Windows ".DLL" or Linux ".so"?
Yes, but...
Surely P96 is something like a windows .dll, and so are the chip and card files. However, the rtg.library has two interfaces: One public, for programs calling into the rtg.library, and one private, for the rtg.library calling into the chip and card interfaces. The latter interface is private, has not been publically available, and requires a license.
If so then what's stop anyone from writing an "rtg.library" with the same function signatures & addresses as the P96 version?
In principle yes, if the internal interface would be revealed, or would be reworked. This will/would take some time, though.
But this all aside: How would you feel if you would offer a third party a license to your work you spend three or more years of your life on, providing the work, and its sources, then just receiving an answer saying, "no thanks, I'll just do it all myself and copy your work".
Would you really believe that any follow-up work would really be based on a genuine re-implementation?
Look, it's not as if the work wasn't available for licensing in first place. Authors were there, a seller was there, a potential buyer was there, prototypes were done... Nobody was really trying to harm the Apollo, and everything was done on "good will" basis.
-
You cannot safely transmit data via DMA on an Amiga system without some MMU magic. This is an issue with the cache of the 68060 and 68040 CPUs. The only other alternative is to disable the cache completely while a DMA is running.
So? If you wanted, you could run the DMA on the apollo while keeping the cache updated. Some old SCSI stuff isn't relevant here.
As in, how much, for example? It creates actually no additional wait states for the 68040 or 68060
Since you are the resident MMU guru, you know better than this. There is a thing called translation look-aside buffer which has a finite size. There are many scenarios when an address translation cannot be done transparently which then can require a table walk of the translation table. And you probably also know that it's the TLB that is the most important constraint on overclocking an 060. This shows that the mem access had to be slowed down on the 060 in order to allow address translation.
Look, it's ok if you don't know, but please don't make such statements then.
You frequently do the same about legal issues.
No. I don't like taking other's people's work for selling my own work
Nobody takes other people's work here. Money would have been paid to the people who actually did the work but not to some company buying the rights and using 68k Amigas to milk some money for their main business.
even more so when first coming to an agreement with them ("We only use this for testing and come and pay you as soon as we make profit") and then later on run away as soon as it involves payment.
Excuse me, you haven't been involved, so you cannot know, but again, please do not make statements if you do not know.
So you were involved. How about you tell the story and then I tell it as I heard it and we all compare?
Excuse me, I've been a bit more involved in the whole process. Gunnar didn't want to license. There was an offer on the table by Hyperion, in fact.
Yes. And it was ridiculously overpriced and clearly a desperate attempt to make some money for a company facing economic doom.
Excuse me, that's neither correct. That's just Gunnar's interpretation of the answer.
How can you know better?
Which, by pure coincidence, also use the P96 API?
No, by design and intention. Just like the NTFS driver for linux, for example. Again, what do you think is illegal about this?
Ok, if they want to go for free, go for AROS completely and do not rely on the P96 API in first place.
That is kindergarten reasoning not worthy of a person as intelligent as you are.
Yes, they are. It's called autoconfig and supported by the Os ROM. Expansion, to be precise. Again, you do not seem to know, but here I am and tell you that it's all possible.
Thank you for telling me. How does it work in detail?
But if you do not sign, then you cannot use the work of others. Full stopo. I cannot offer a P96 driver if I don't want to pay for P96.
Yes, I can. It doesn't become true just by repeating it.
I cannot offer a patched Kickstart if I do not pay for the kickstart. It's really quite simple.
I agree for the kickstart under some circumstances because it involves patching (and thus deriving the patched kickstart from the original copyrighted work). However, there is a thing called "exhaustion of rights" which basically means that you don't need to pay a second time for something you already bought. That's also why it is perfectly legal to patch and flash the kickstart already owned by the customer.
Yes, there is. It is called "Copyright" and "licensing conditions".
I think I know more about copyrights in western legislations than you do. As for the licensing conditions, this is just an offer for a licensing contract. The apollo team did not accept that offer so no licensing contract was made. It's as simple as that. If you think about the GPL, it's precisely how it works: it is an offer for licensing which is accepted by the person using and modifying the source code ("konkludent", as we call it in German, or something like "implied by action of the party"). Licensing conditions are not like a law that you yourself made for a specific item you created. They are an offer for a licening contract. And such offers can be accepted or declined.
There is "normal use" of a work, i.e. I use the binary as intended.
That's what users of the vampire RTG subsystem will do.
What I cannot do is simply take the binary of somebody else, patch it up and deliver it as part of my product.
That is true. But not relevant for the picasso drivers as nobody took somebody else's binary.
Or base my product on an API of a closed product that, as intended by the authors, requires licence payments.
And here you are wrong again. I did my best explaining the legal situation. Perhaps I'm not good at it. My experience is that many engineers are not very good at understanding law (and lawyers not good at understanding technology) which is why we patent attorneys are such a rare breed.
-
No, I find the P96 software cumbersome. I always chose CGfx when I can, simply because it is less ridden with annoying bugs and has Prefs interface I can relate to.
Could you please report the bugs so I can fix them? Thank you.
-
I don't *care* for AROS or CGfx. That's why I said "they probably need to check with the CGfx authors". Is this a wrong statement? No.
Yep, it is quite obvious you only bother to have bare minimum knowledge about stuff you do not care about. Linux for example.
Wait a minute! Just because my software isn't your flavour of "free", you call that "lack of cooperation"? Actually, there have been quite some cooperation in the Amiga land from my side. Look at MuForce, for example. This thing wouldn't have come to life without cooperation with Mike Sinz.
What I mean was that "the owners of the name", that be anyone involved with anything officially named "Amiga" has denied to cooperate with the other "camps", AROS and MorphOS. Except for shell and layers.library, I do not "care" about your software :)
Os 3.9 wouldn't have come to life without cooperation with Haage and Partner, and people like Olaf Barthel.
And the colour wheel gadget from AROS, I suppose. :laughing:
But really, OS 3.9 came out before MorphOS 1.0 and AROS was not even booting on hardware at the time. OS4.0 was released about same time, and whether you like it or not, you belong in the Hyperion/OS4 "camp" since that is where OS3.x vanished.
Then that's reluctant to know for AROS and Gunnar's team. I never stated the opposite. I just said "it needs to be clarified".
reluctant? redundant?
-
In principle yes, if the internal interface would be revealed, or would be reworked. This will/would take some time, though.
It is called P*96* - it has been 20 years, for crying out loud! :hammer:
-
Could you please report the bugs so I can fix them? Thank you.
Why? I use CyberGfx4 with my CV64 and CVPPC, the last thing I had that used P96 was Voodoo5 with Mediator - I am not even sure you would bother to help me with such a setup :laughing:
Also - why would I send bug reports to you? You have no rights to develop P96.
-
However, the rtg.library has two interfaces: One public, for programs calling into the rtg.library, and one private, for the rtg.library calling into the chip and card interfaces. The latter interface is private, has not been publically available, and requires a license.
Correction: no documentation of the latter interface is publically available, the interface itself is available on all picasso installations. And without using private information which will only be disclosed as part of a license contract, a license is not necessary to use this interface.
It's like you invent a secret language to speak with your buddy and everybody wanting to converse with your secret language needs to become member of your club of buddies by passing some test of courage. Well, how would that stop me from listening to you conversing publically in your language, deciphering it and then using it for my own entertainment?
But this all aside: How would you feel if you would offer a third party a license to your work
Who's feeling now? I think there is too much hearsay and communication by proxies in all this. If the original picasso authors have not sold all their rights to the software, they should speak up and communicate with the apollo team in person(s) and not by proxy.
Would you really believe that any follow-up work would really be based on a genuine re-implementation?
It's actually documented on github or wherever the new driver is hosted. And you are not going to suspect Jason McMullan for copying other people's work?
Look, it's not as if the work wasn't available for licensing in first place.
You can also license Microsoft's documentation for NTFS. However, if I were to write a filesystem driver for AmigaOS, I would just look into the linux NTFS driver and open-source my own driver.
Authors were there, a seller was there
authors != sellers? Were the authors there in person or representated by somebody, e.g. you?
-
Why? I use CyberGfx4 with my CV64 and CVPPC, the last thing I had that used P96 was Voodoo5 with Mediator - I am not even sure you would bother to help me with such a setup :laughing:
In other words, FUD. Just what I thought. Thank you for confirming.
Also - why would I send bug reports to you? You have no rights to develop P96.
Actually, this might not be quite so...
-
Yes, but...
Surely P96 is something like a windows .dll, and so are the chip and card files. However, the rtg.library has two interfaces: One public, for programs calling into the rtg.library, and one private, for the rtg.library calling into the chip and card interfaces. The latter interface is private, has not been publically available, and requires a license.
In principle yes, if the internal interface would be revealed, or would be reworked. This will/would take some time, though.
But this all aside: How would you feel if you would offer a third party a license to your work you spend three or more years of your life on, providing the work, and its sources, then just receiving an answer saying, "no thanks, I'll just do it all myself and copy your work".
Would you really believe that any follow-up work would really be based on a genuine re-implementation?
Look, it's not as if the work wasn't available for licensing in first place. Authors were there, a seller was there, a potential buyer was there, prototypes were done... Nobody was really trying to harm the Apollo, and everything was done on "good will" basis.
Ok then so the "private" interface is the API for dealing with chipsets (hardware drivers) and various graphics cards.
If I was reimplementing, speculating only here I admit, then I wouldn't bother with that end of it at all. I would just create a very simple system for the one chipset that I was supporting.
I suspect that is what has been done because the Vampire implementation isn't a general purpose system meant to be reused with different chips.
It targets a single design, one done by the same "team" as the author, that supports little more than a framebuffer and some basic operations.
We cannot know more with seeing the source code for it, or at least the team discussing it in more detail, however there's no reason to assume infringment of any license here.
Hooking into "graphics.library" is pretty simple, and writing an "rtg.library" is almost trivial especially if you have access to the hardware designer who's written the underlying chip.
-----
Now as to the second part about how you feel about it, well they took a look at what was offered and the licensing terms. They didn't like them or they decided that they were unnecessary given what they hoped to achieve.
It might be annoying but it's fair on their part to do so, the external interface is public, the private part might simply be far more than they need, so they don't license that part and thus don't use it features. Which is pretty standard stuff.
Sorry that it didn't work out for the P96 API authors but I just can't see what the problem is here. Unless nefarious dealings mean that propriatary code was used in this SAGA P96 implementation it seems that it should be quite legal.
-
Correction: no documentation of the latter interface is publically available, the interface itself is available on all picasso installations. And without using private information which will only be disclosed as part of a license contract, a license is not necessary to use this interface.
I don't think I claimed something else.
Well, how would that stop me from listening to you conversing publically in your language, deciphering it and then using it for my own entertainment?
*Sigh*. Again, you want to find a twist around it. What's so hard to understand? Authors want payment. You don't want to pay, but still use it?
Is this a fair trade in your language?
Who's feeling now? I think there is too much hearsay and communication by proxies in all this. If the original picasso authors have not sold all their rights to the software, they should speak up and communicate with the apollo team in person(s) and not by proxy.
Too tired, not much interested in all this discussion. I can well understand this if I see people like Kolla here.
It's actually documented on github or wherever the new driver is hosted. And you are not going to suspect Jason McMullan for copying other people's work?
I don't know what he did or not did, but one may wonder where the API docs came from. Such information is not on file or on github. It's at least a pretty questionable practise.
You can also license Microsoft's documentation for NTFS. However, if I were to write a filesystem driver for AmigaOS, I would just look into the linux NTFS driver and open-source my own driver.
You could, and you would, and for private applications the result might be good enough. Not as if Microsoft would even sell you.
However, if you were running a company and you would sell products to end-users, you should probably better make sure that everything is working correctly and that you -or whoever reverse-engineered NTFS- haven't mis-interpreted anything when reverse engineering NTFS. If you're running a serious business and depend on stable products, or even have to pay $$$ if your products do not work as requested, licensing is usually the more attractive solution.
There is a difference between a private hobby market, and a professional market. I doubt anyone is using the Linux NTFS implementation on professional systems. If linux runs in a production environment (and yes, we do that), it's running on its own file system.
authors != sellers? Were the authors there in person or representated by somebody, e.g. you?
No. Tobias and Alex didn't want to sell directly to Gunnar. Too much hassle for them. The business was planned indirectly through Hyperion, which would have bought full rights on P96 (or probably even have them bought, right now). Maintenance would have been done through an external team, again to be paid by Hyperion (by people like me, for example). No, I do not represent either Hyperion, nor the P96 developers. I'm only very remotely related to this at all.
-
Sounds like Hyperion feels very threatened by the classic market, especially with products like FPGA Replay and Vampire. A-EON likely feels the same.
I believe the NG market will dry up very quickly if the classic market continues at this pace.
-
The code is up on GitHub by the way here : https://github.com/ezrec/saga-drivers
Looks like a ground up reimplementation.
-
In other words, FUD. Just what I thought. Thank you for confirming.
Oh wow, you know about "FUD"? :D
I did have a PicassoIV card at some point, and I also tried really hard to use P96 with CV64. It was pointless. I got rid of the PIV as it brought more hassle than I needed, was easier to use CSPPC along with CV64 than along with PIV. Then came the Mediator, and I was eyerolling. It took 5 years from I bought the Voodoo5+Mediator for them to work together, and in the meantime I borrowed a Voodoo3. The same stupid artifacts and bugs I had back with CV64 were still there with the Voodoo cards, and the user interface made me dream of editing xorg.conf by hand. Luckily with UAE for most part there is no need to deal with it, I belive last time I messed with it was with FS-UAE on DragonFlyBSD, just to test that PIV emulation was working before I installed OS4.1FE.
Your assumption that I am "just spreading FUD" is rather ignorant.
Actually, this might not be quite so...
I have no reason to believe that you have any rights to currently do any work with P96 unless I hear it from the original authors. I am aware that you are on the "thank you list", but that is not the same as having a license to do official development. The DDK was for hardware developers, and AFAIK you have no hardware that you are selling.
-
Ok then so the "private" interface is the API for dealing with chipsets (hardware drivers) and various graphics cards.
Yes, indeed, tis is the case.
If I was reimplementing, speculating only here I admit, then I wouldn't bother with that end of it at all. I would just create a very simple system for the one chipset that I was supporting.
Unfortunately, there is nothing "simple" about that. The graphics library is really build around the blitter, and planar graphics, minterms, and a couple of blitter functionalities. It uses copperlists, and denise's sprite system.
The Vampire rtg graphics is chunky, not planar, has no hardware sprite and no copper list.
Any replacement of graphics hence has to deal with incompatible pixel formats (chunky, planar), the emulation of blitter min-terms, the emulation of sprites, and other elementary graphics and hardware primitives.
It's really all but simple.
I suspect that is what has been done because the Vampire implementation isn't a general purpose system meant to be reused with different chips.
It targets a single design, one done by the same "team" as the author, that supports little more than a framebuffer and some basic operations.
Yes, the vampire framebuffer is pretty simple indeed, and the driver is rather minimal. Mostly because it already uses many of the services that are natively available within P96.
We cannot know more with seeing the source code for it, or at least the team discussing it in more detail, however there's no reason to assume infringment of any license here.
Once again, if you depend on P96 services for your framebuffer, you're depending on a lot of work somebody has done. You also depend on the calling interface from P96 into the driver, which was only available on a license basis.
Yes, the framebuffer driver itself is pretty simple, but only because somebody else has put an enourmous amount of work into the P96 system to keep it that simple. Call me old fashioned, but I believe this is something worth paying for.
Hooking into "graphics.library" is pretty simple, and writing an "rtg.library" is almost trivial especially if you have access to the hardware designer who's written the underlying chip.
No, not at all. (-: The problem is that graphics doesn't have a well-defined interface for rtg graphics in first place. It really goes down to the blitter. So it's not that you have "just" to implement a handful of graphics primtives and you're done. It's more that you have to re-implement a major part of the graphics.library.
Actually, this is pretty much what P96 is: A better implementation of graphics.
So for example, due to the lack of a customized interface, a lot of work in graphics is replicated in P96, as for example line clipping and line drawing, text drawing, text clipping and so on.
It's really a design problem graphics has of not defining any useful interfaces for other graphics systems than the native one.
Now as to the second part about how you feel about it, well they took a look at what was offered and the licensing terms. They didn't like them or they decided that they were unnecessary given what they hoped to achieve.
Oh, sure, you can simply say that you didn't like the terms. Then you need to come up with better terms and negotiate. It's not that such discussions are quick, and decisions are easily made. It usually takes some time to come up with the result. In this particular case, it only took a week.
The point is not so much whether a decision has been made for or against a given solution. The point is rather that now, at this point, the decision must been accepted with full consequences. And the full consequences are that if you don't want P96, you cannot create a driver that depends upon it. I believe this is a pretty simple consequence.
Sorry that it didn't work out for the P96 API authors but I just can't see what the problem is here. Unless nefarious dealings mean that propriatary code was used in this SAGA P96 implementation it seems that it should be quite legal.
How you can build a code against a proprietary interface is one question. Whether this is legal a second.
But what I don't really like is first to say "we don't want to pay for this interface", but then also use it in first place.
Call me old fashioned, but if the interface was good enough for me to work with, it should also be good enough for me to pay for.
-
Authors want payment.
Not all authors. As for the P96 authors, they want to be left the heck alone, and never be bothered about P96 ever again. I suggest we as a community grant them this wish.
-
All these recent happenings have pretty much made me convinced that the sooner AROS is a drop in replacement for OS3.x the better for the Amiga community.
The death of the proprietary vultures can't come soon enough.
-
Call me old fashioned, but if the interface was good enough for me to work with, it should also be good enough for me to pay for.
As a gesture yeah sure, but legally? No.
Otherwise every header, function interface, dll, library etc would need to be licensed on a case-by-case or batch basis.
The only ones trying that sort of rubbish are Oracle-vs-Google with the Java library headers.
I'm still not sure what's going on with this stuff. I mean what part of P96 is it actually *using* and therefore what is the fuss about? Looking at the source code I see a lot of calls into AROS and... that's it, no P96 specific stuff all.
So what part of P96 does it use? Is it a library loaded by something to do with P96? Is that what the problem is?
I'm still struggling to understand what the back n' forth between you all is actually over.
Yes if someone is using a library or software that needs a license, and that license has a fee, then I think that someone should pay that fee.
However, I can't figure out what software/library is being used that would require someone to be paid.
-
I did have a PicassoIV card at some point, and I also tried really hard to use P96 with CV64. It was pointless. I got rid of the PIV as it brought more hassle than I needed, was easier to use CSPPC along with CV64 than along with PIV. Then came the Mediator, and I was eyerolling. It took 5 years from I bought the Voodoo5+Mediator for them to work together, and in the meantime I borrowed a Voodoo3. The same stupid artifacts and bugs I had back with CV64 were still there with the Voodoo cards, and the user interface made me dream of editing xorg.conf by hand.
So, once again, what are these bugs and stupid artifacts? FUD?
For CGFx, I can point you at particular bugs. For example, its line clipping is incorrect, and it does not adjust the line patterns correctly. That's one of the bugs I remember. I don't know whether this has been fixed at this time, but my GVPSpectrum worked a lot better with P96 than with CGfx.
Picasso96TNG worked pretty well for me for setting up the screen modes, not much of a problem there. There might have been an older configuration tool at some point, but that was much before I entered.
The P96 CV64 driver is probably unmaintained, and indeed, if this was your hardware, CGfx would have been the better choice as its driver came from its manufacturer, no surprise really.
For the PIV and the PII (and the similar GVPSpectrum) the situation was quite reverse, so it's hard to come up with a general recommendation. The P96 PiP-functionality was particularly tuned for the PIV, for example.
I have no reason to believe that you have any rights to currently do any work with P96 unless I hear it from the original authors.
I doubt that they would talk to you. Actually, I do not even know why I'm doing as I would not really expect any particular useful answer from you in first place.
I am aware that you are on the "thank you list", but that is not the same as having a license to do official development. The DDK was for hardware developers, and AFAIK you have no hardware that you are selling.
I've neither hardware nor software to sell, nor was I ever selling hardware for the Amiga.
And no, I don't have a license at this point, but it was part of the discussion to get an official one to work on P96. Actually, I worked on P96 back then, with agreement with the authors. We didn't need a particular written icense back then. A word (or a mail) among honest people was enough in those days. That's not the typical "legal vs. illegal" bullsh*t I see here.
My argument is quite simple: If it's good enough to use it in your products, it should be good enough to pay for. Something Elbox already got particularly wrong.
Anyhow, all of this is history anyhow. My mood to work on anything Amiga related has gone missing lately, even more with folks like you on board.
-
All these recent happenings have pretty much made me convinced that the sooner AROS is a drop in replacement for OS3.x the better for the Amiga community.
True, and this also makes it a lot easier for people to do the mental migration to modern hardware that AROS also runs on :) :laughing:
-
Hooking into "graphics.library" is pretty simple, and writing an "rtg.library" is almost trivial especially if you have access to the hardware designer who's written the underlying chip.
It's not trivial and it is not what was done here. What was done wasn't difficult (for Jason, that is) because indeed there is very little in the apollo RTG subsystem to set up. The documentation is somewhere in the apollo forum. Basically you set some bits in some registers thereby selecting the colourdepth and resolution you want.
The difficult part is indeed the patching of the graphics.library. And that has not been reimplemented by the apollo team which means that you need a standard picasso installation and then install the apollo picasso drivers on top of that picasso installation. This is still legal because the picasso files are distributed freely with permission by their authors (e.g. on aminet).
As already mentioned before the work of the original authors is respected and acknowledged. They are invited to talk to the apollo team directly.
*Sigh*. Again, you want to find a twist around it. What's so hard to understand? Authors want payment. You don't want to pay, but still use it? Is this a fair trade in your language?
It may not be fair but it is legal. That's an important difference.
I don't know what he did or not did, but one may wonder where the API docs came from. Such information is not on file or on github. It's at least a pretty questionable practise.
AFAIK the "documentation" came from looking at the open-source implementation in uaegfx.
No. Tobias and Alex didn't want to sell directly to Gunnar. Too much hassle for them. The business was planned indirectly through Hyperion, which would have bought full rights on P96 (or probably even have them bought, right now).
This is almost funny. First you use the author's hurt feelings as an argument and then you say they weren't even interested enough to take part in the negotiations and of all possible companies left it to Hyperion to make a deal? And Hyperion itself negotiated with a potential licensee while trying to take over the rights to the product to be licensed? Do you understand what you are saying there? I had to look up the English term because I don't deal with penal law: this could be a case of breach of trust on the side of the proxy ("Untreue" in German).
Maintenance would have been done through an external team, again to be paid by Hyperion (by people like me, for example). No, I do not represent either Hyperion, nor the P96 developers. I'm only very remotely related to this at all.
Hyperion pays people? I hope the contractors demand up-front payment. People "like you" but not you? Or do you have an interest in this deal yourself? As you know, the devil fools with the best laid plans. Sorry if it didn't work out.
-
So, once again, what are these bugs and stupid artifacts? FUD?
You expect me to to dig out 10-20 year old screenshots? Sorry, I have not kept them around AFAIK.
For CGFx, I can point you at particular bugs. For example, its line clipping is incorrect, and it does not adjust the line patterns correctly. That's one of the bugs I remember. I don't know whether this has been fixed at this time, but my GVPSpectrum worked a lot better with P96 than with CGfx.
Again - CGfx merged into MorphOS, and to a degree AROS. Where did P96 go? OS4, where you can still mess around with the same darn Prefs thingy as back in the 90ies :laughing:
Picasso96TNG worked pretty well for me for setting up the screen modes, not much of a problem there. There might have been an older configuration tool at some point, but that was much before I entered.
The program that comes with it is called Picasso96Mode, it is even there in OS4.1FE (!!). Picasso96TNG I vaguely remember, it gives me 8 hits on Google.
The P96 CV64 driver is probably unmaintained, and indeed, if this was your hardware, CGfx would have been the better choice as its driver came from its manufacturer, no surprise really.
For the PIV and the PII (and the similar GVPSpectrum) the situation was quite reverse, so it's hard to come up with a general recommendation. The P96 PiP-functionality was particularly tuned for the PIV, for example.
I wanted multimonitor setup, it was a hassle. Eventually when I had CVPPC, the choice was clear - get rid of the PIV and P96 too. Sadly P96 came back when I tried to put together an A4000 with Mediator 4000Di and the voodoo cards.
I doubt that they would talk to you. Actually, I do not even know why I'm doing as I would not really expect any particular useful answer from you in first place.
They do not have to talk with me, they just need to issue an official statement, on behalf of themselves and not via you.
And no, I don't have a license at this point, but it was part of the discussion to get an official one to work on P96. Actually, I worked on P96 back then, with agreement with the authors. We didn't need a particular written icense back then. A word (or a mail) among honest people was enough in those days. That's not the typical "legal vs. illegal" bullsh*t I see here.
This exercise in BS is mostly performed by you though.
My argument is quite simple: If it's good enough to use it in your products, it should be good enough to pay for. Something Elbox already got particularly wrong.
Do you know the difference between "should" and "must"?
Anyhow, all of this is history anyhow. My mood to work on anything Amiga related has gone missing lately, even more with folks like you on board.
Good for you! Take a vacation from Amiga, the world is bigger and life is short! :)
-
As long as it is based on the P96 API, it is. There is likely a native CGfx API, though.
I do not know what the conditions are for a third party to offer a CGfx driver. I can only tell you want the conditions for the P96 API are.
Currently, the drivers use the P96 API, and *that* is not valid.
This is only true if it uses the code, compiled libraries which require a license. If it's reimplementing the API based on the interface definitions, i.e. those exported to shared libraries and headers, then it's perfectly legal.
You can copyright a specific implementation, but there is nothing to stop someone else from implementing it themself without using any of the existing code or libraries and then selling or open sourcing that implementation.
-
It's not trivial and it is not what was done here. What was done wasn't difficult (for Jason, that is) because indeed there is very little in the apollo RTG subsystem to set up. The documentation is somewhere in the apollo forum. Basically you set some bits in some registers thereby selecting the colourdepth and resolution you want.
The difficult part is indeed the patching of the graphics.library. And that has not been reimplemented by the apollo team which means that you need a standard picasso installation and then install the apollo picasso drivers on top of that picasso installation. This is still legal because the picasso files are distributed freely with permission by their authors (e.g. on aminet).
As already mentioned before the work of the original authors is respected and acknowledged. They are invited to talk to the apollo team directly.
Ah, thanks Grond I think that answers it for me :)
-
This is only true if it uses the code, compiled libraries which require a license. If it's reimplementing the API based on the interface definitions, i.e. those exported to shared libraries and headers, then it's perfectly legal.
You can copyright a specific implementation, but there is nothing to stop someone else from implementing it themself without using any of the existing code or libraries and then selling or open sourcing that implementation.
Which is exactly what the P96 authors did with the CGX API, but apparently what's good for the goose is not good for the gander.
-
I don't know what he did or not did, but one may wonder where the API docs came from. Such information is not on file or on github. It's at least a pretty questionable practise.
A quote from Jason...
Well, _I_ didn't get the SDK from Toni nor Cloanto.
and
I would be willing to itemize where I got every line from, if need be.
As a personal friend of mine I take offense to your questioning his ethics.
-
As a personal friend of mine I take offense to your questioning his ethics.
Someone earlier on this thread mention FUD :hammer:
-
As a personal friend of mine I take offense to your questioning his ethics.
Give him a little rest. Thomas wrote the first vampire/apollo RTG driver hoping that the whole project would go the route he favours. His work seems now to have been done in vain because it was replaced by a second driver. I can understand this doesn't feel good. And the new driver was written in such a short time (I'm still awed) that I can also understand that somebody who didn't witness its progress would wonder about whether this could be done without peeking at some illegitimate resource.
Just a few hours ago Jason asked when he will finally get the SDcard hardware documentation. He brought it up only yesterday and I wonder whether BigGun & Co can deliver fast enough to keep him happy. If they do, we can probably expect the Sdcard driver by the end of the week... :lol:
It's such a pity for us that his interests have moved away from AROS/Amiga. Just imagine what he could do if this was his main project.
-
Give him a little rest. Thomas wrote the first vampire/apollo RTG driver hoping that the whole project would go the route he favours. His work seems now to have been done in vain because it was replaced by a second driver. I can understand this doesn't feel good. And the new driver was written in such a short time (I'm still awed) that I can also understand that somebody who didn't witness its progress would wonder about whether this could be done without peeking at some illegitimate resource.
Just a few hours ago Jason asked when he will finally get the SDcard hardware documentation. He brought it up only yesterday and I wonder whether BigGun & Co can deliver fast enough to keep him happy. If they do, we can probably expect the Sdcard driver by the end of the week... :lol:
It's such a pity for us that his interests have moved away from AROS/Amiga. Just imagine what he could do if this was his main project.
His sugar printer is pretty impressive too. But yes Jason's work and speed is very impressive(3 days for the RTG driver).
-
Give him a little rest. Thomas wrote the first vampire/apollo RTG driver hoping that the whole project would go the route he favours. His work seems now to have been done in vain because it was replaced by a second driver. I can understand this doesn't feel good. And the new driver was written in such a short time (I'm still awed) that I can also understand that somebody who didn't witness its progress would wonder about whether this could be done without peeking at some illegitimate resource.
Just a few hours ago Jason asked when he will finally get the SDcard hardware documentation. He brought it up only yesterday and I wonder whether BigGun & Co can deliver fast enough to keep him happy. If they do, we can probably expect the Sdcard driver by the end of the week... :lol:
It's such a pity for us that his interests have moved away from AROS/Amiga. Just imagine what he could do if this was his main project.
A community funded bounty to clone him would be worth every penny! :)
-
As already mentioned before the work of the original authors is respected and acknowledged. They are invited to talk to the apollo team directly.
Which they did not want to...
It may not be fair but it is legal. That's an important difference.
Remind me next time you complain about missing drivers or missing initiative for Amiga development.
AFAIK the "documentation" came from looking at the open-source implementation in uaegfx.
That's what I guessed, yes. Hence, no official API documentation.
This is almost funny. First you use the author's hurt feelings as an argument and then you say they weren't even interested enough to take part in the negotiations and of all possible companies left it to Hyperion to make a deal? And Hyperion itself negotiated with a potential licensee while trying to take over the rights to the product to be licensed? Do you understand what you are saying there? I had to look up the English term because I don't deal with penal law: this could be a case of breach of trust on the side of the proxy ("Untreue" in German).
Not at all. Again, you were not part of the negotiations, so you do not know. But please don't make up nonsense. T&A wanted to license to Hyperion to get a guaranteed stream of income. Hyperion wanted to licence to Gunnar. Everybody was informed on this deal, there was nothing hidden from any party. T&A did not want to make a deal with Gunnar directly. One can speculate why, I don't know. Probably too much hassle. With Hyperion, it would be one-time deal, money paid, deal done. With Gunnar, it means continuously checking the sales numbers and sending invoices. But one way or another: I do not know, but I neither make up my truth.
Hyperion pays people? I hope the contractors demand up-front payment.
Guess what.
People "like you" but not you? Or do you have an interest in this deal yourself?
I *had* an interest in this deal, though it's surely not a task for a single man. I do not have any interest anymore. What for? It's not that there is any market anymore.
Given the reactions here, there is neither an interest in an updated AmigaOs, nor in updates for P96. So why should I invest any work into such an activity? I've a lot of other things to do these days. These ideas are dead, deceased, ceased to be, and have seen its maker. AmigaOs is finally, completely, utterly dead. Whether that's good or bad is of course everybodies choice.
If the community wants to go AROS, why should I stop them? But then, if everyone is begging for OpenSource, please be also so honest and open the source completely, and with full consequences. That means:
*) Do not build on a proprietary interface. Create your own, and open source that interface. You would probably notice how much work went into it and would appreciate the work of the original authors.
*) Do not build on a proprietary FPGA solution. Open source the solution as well.
I *really* wonder whether Gunnar is fair enough to release the sources of his FPGA, or rather whether he wants to sell his own work on the back of free software developers. I personally would not want to work for free to fill somebody else's pocket. But again, that's just me. As said, I'm an old fashioned guy.
-
Amiga 600 with Vampire II running Payback and Foundation in 640x480! :crazy:
http://oldschoolgameblog.com/2016/02/29/amiga-vampire-ii-for-the-amiga-600-in-action/
-
I *really* wonder whether Gunnar is fair enough to release the sources of his FPGA, or rather whether he wants to sell his own work on the back of free software developers. I personally would not want to work for free to fill somebody else's pocket. But again, that's just me. As said, I'm an old fashioned guy.
of course it might be interesting to have open source fpga core. however i dont recall gunnar promising something like that ever and he might have his reasons, its not for me to judge. espacially he is in proud company of almost all hardware developers, including amiga(like) systems. you probably can count the open source hardware projects like tg68 or strims 030 decelerator card on the fingers of one hand.
however there i and probably will be also open source initiatives following. fpga arcade has been announced to be open as example. are they paying license fees for their p96 driver by the way? ao why is gunnar getting all the flak again;)
btw. thomas, i think if anybody feels his rights have been compromised, they will certainly speak up. i think the interested parties have been informed or at least approached. it should be left for them to act.
-
The question is, if Vampire users really need RTG or P96 in future. First, it is only a framebuffer. You can display higher resolution than on AGA. But thats it. This is usefull for software that came out after Commodore went off. It is for compatibility for some stuff, this is the PAST.
Vampire is the future, SAGA offers higher resolution and more colors than AGA and more. Coming software will make use of it. Why should future software call an Famebuffer/P96/RTG for writing into SAGA, when this programm can access direct SAGA? Is P96 such a beautifull API? I don´t know. Does it already support SAGA? Off course not.
Why paying license fee to Hyperion? And how much? I would pay 2€ per license, not more. Thats enough for old software which is only usefull for some compatibility issue. By the way, I think at the time the Vampire is available to all Amigas, that is the end of PPC-Amiga-OS4...
Maybe I am wrong, as I can not know all facts.
-
.... fpga arcade has been announced to be open as example. are they paying license fees for their p96 driver by the way? ao why is gunnar getting all the flak again;)
Yes, firmware and a lot of the hardware is open now, including the T68 CPU changes Till and I have been working on (as required by the license). The rest will be shortly once I've finished tidying it up. I'm rolling back some bits I haven't changed much to align with the MIST codebase, then we can share debug resources. I expect the open source CPU to get to 30-40K Dhrystones, which feels pretty speedy running classic systems. If you want to run a more recent OS, I suggest a RasPI3 will run it far better and cheaper than any FPGA solution. I'm far more interested in accurately cloaning and preserving the old hardware.
I have always been keen to find a fair licensing solution, but the old model of a fee per board is not appropriate for a generic platform such as Replay. I also got the feeling certain parties were trying to hold the remaining community hostage, and milk it for whatever they could get.
Like the Apollo driver, mine is built from the UAE driver and P96 public header files. I have support for hardware sprites and a dedicated blitter, but these are trivial from a software perspective.
I've tried to approach the authors, and all I got back was a "we'll get back to you". I assumed they had already come to a deal elsewhere.
/MikeJ
-
Vampire is the future, SAGA offers higher resolution and more colors than AGA and more. Coming software will make use of it. Why should future software call an Famebuffer/P96/RTG for writing into SAGA, when this programm can access direct SAGA? Is P96 such a beautifull API? I don´t know. Does it already support SAGA? Off course not.
No, P96 is a useful API, and in particular designed to support chips that are designed around the VGA standards. That does not make it particularly beautiful because VGA is not particularly beautiful. It is only useful.
The point is rather that P96 supports *a lot* of useful functions, and avoids a lot of hassle when interfacing to the legacy graphics system of AmigaOs. As said, a lot of work went into this. Graphics is so much tight around the blitter and copper, it is hard to abstract from it.
Why paying license fee to Hyperion?
Because they pay somebody else to do the work? And do all the paperwork around it? And market it? And defend its rights?
I understand that as a pure software developer, such tasks seem boring and not worth any money. I afraid, however, reality is a bit different. You would be astonished how much "overhead" you need to run a company, and how small "R&D" is, even in research driven companies.
And how much? I would pay 2€ per license, not more. Thats enough for old software which is only usefull for some compatibility issue.
Actually, that's really a matter of the negotiations, and neither mine not yours to determine. Saying "only useful for some compatibility issue" is really a bit of an "understatement". It is rather necessary to enable rtg graphics on the legacy AmigaOs, and hence is a key issue for accessing the enhanced graphics capabilities. In the end, do you believe that the Vampire finds less buyers if it costs $170 or $160 instead of $150? I don't.
By the way, I think at the time the Vampire is available to all Amigas, that is the end of PPC-Amiga-OS4...
It is currently available for the "small" Amigas, or some of them. There are quite some problems left to be tackled for the big-boxes. I believe I already mentioned the DMA issues. This is a non-trivial problem, and it requires some form of MMU. But that's another issue.
-
Actually, that's really a matter of the negotiations, and neither mine not yours to determine. Saying "only useful for some compatibility issue" is really a bit of an "understatement". It is rather necessary to enable rtg graphics on the legacy AmigaOs, and hence is a key issue for accessing the enhanced graphics capabilities. In the end, do you believe that the Vampire finds less buyers if it costs $170 or $160 instead of $150? I don't.
I agree: who would not pay ~30-50 euro for a Kickstart/OS 3.1 / RTG licence on a sd-card for the Vampire, just to plug the card in your Amiga and have the thing very easy running.
-
Given the reactions here, there is neither an interest in an updated AmigaOs, nor in updates for P96. So why should I invest any work into such an activity? I've a lot of other things to do these days. These ideas are dead, deceased, ceased to be, and have seen its maker. AmigaOs is finally, completely, utterly dead. Whether that's good or bad is of course everybodies choice.
I do not see it as a choice. For me it is a necessity. Please understand, I for one am very greatful. Even as a developer, I can only guess at the amount of work that has gone into designing and implementing AOS and P96.
But as you demonstrated yourself, legal issues surrounding Amiga are way too complex. We do need to stay clear of it.
If copyrights are violated, we need to fix this. But I wonder, if what you claim is true about APIs, even implementing the instruction set of an 68k CPU can never be legal... so all of this would be pointless...
I *really* wonder whether Gunnar is fair enough to release the sources of his FPGA, or rather whether he wants to sell his own work on the back of free software developers.
So, if Gunnar does not open-source his core, then any time spent developing AROS is not waisted. And looking at AROS, it still needs a lot of work...
We can not force him, and IMHO it is fine if he does not. Linux runs on Intel chips, which are not open-sourced and yes, there is a movement to develop open hardware, but it does not matter too much.
I for one congratulate him and his team on the apparent success and hope no legal battles destroy his plans.... :)
I personally would not want to work for free to fill somebody else's pocket. But again, that's just me. As said, I'm an old fashioned guy.
I fully understand where you are coming from. I used to think that way. But when it comes to a hobby-machine and a comunity-effort, it is paid by other means... and yes some will benefit (see http://www.ares-shop.de/) but that's fine, as long as it is permitted by the license.
-
Im also in the Vampire 2 owners club I love this card!! It doesnt get hot at all and speed is amazing!!!
Many thanx to the FANTASTIC Apollo-team!
https://onedrive.live.com/redir?resid=88EFB8D498C45100!305&authkey=!AMVlKx6qap9_Ju8&v=3&ithint=photo%2cJPG
-
I agree: who would not pay ~30-50 euro for a Kickstart/OS 3.1 / RTG licence on a sd-card for the Vampire, just to plug the card in your Amiga and have the thing very easy running.
Who in their right mind would pay twice for something they already own?
-
Who in their right mind would pay twice for something they already own?
Depends what that extra expense entails.
170-180 for 060++ performance is still dirt cheap.
-
Depends what that extra expense entails.
170-180 for 060++ performance is still dirt cheap.
if one is acustomed to os4 hardware level prices.
then + 50$ for network stack
+50$ for usb stack
+50$ for icon set
...
+50$ for desktop backgrounds pack
...
-
You forgot £70 for tea and buiscuits.
-
Depends what that extra expense entails.
170-180 for 060++ performance is still dirt cheap.
There's no way I'd pay for a bundled kickstart 3.1 when every machine I own already has it.
An empty flash ROM with a bundled patch for the ROM and a copy of transrom is what it should come with. Or AROS by default.
-
You forgot £70 for tea and buiscuits.
And a further 50 quid for a T-shirt and coupon you'll never receive.
-
You forgot £70 for tea and buiscuits.
and 100$ for a meal
-
There's no way I'd pay for a bundled kickstart 3.1 when every machine I own already has it.
An empty flash ROM with a bundled patch for the ROM and a copy of transrom is what it should come with. Or AROS by default.
My tea comment was halfway facetious.
My point is;
IF Apollo Team decided today to go down the AOS route, and thru agreement ends up having to add 20-40 dollars to the Vampire; I still would find the accelerator DIRT cheap and well worth the money.
Gunnar has expressed rather clearly that he wants the ability to develop more advanced features, and as such, I would ASSUME any agreement regarding AOS would entail development of AOS/P96 in one form or another.
Im not privy to the details of the discussion, but I have gotten the impression that Gunnar havent found the details in the agreement satisfactory from his point of view. Thats fine. I wont villify the other side of the discussion for that reason.
Apollo Team got options if they decide against licensing, which is fine with me too, just as an AOS route would be.
Im not fundamentally against developers getting money for their work, which some seems to be.
-
My tea comment was halfway facetious.
My point is;
IF Apollo Team decided today to go down the AOS route, and thru agreement ends up having to add 20-40 dollars to the Vampire; I still would find the accelerator DIRT cheap and well worth the money.
Gunnar has expressed rather clearly that he wants the ability to develop more advanced features, and as such, I would ASSUME any agreement regarding AOS would entail development of AOS/P96 in one form or another.
Im not privy to the details of the discussion, but I have gotten the impression that Gunnar havent found the details in the agreement satisfactory from his point of view. Thats fine. I wont villify the other side of the discussion got that reason.
Apollo Team got options if they decide against licensing, which is fine with me too, just as an AOS route would be.
Im not fundamentally against developers getting money for their work, which some seems to be.
Code that is paid for can also be Free and/or Open too.
But that's a separate issue to companies demanding we pay again for something we already own.
The law is on the side of the consumer, we would be fully within our rights to demand a refund of the cost of any unwanted bundled Kickstart ROM just as we can do with bundled copies of Windows or OS4 (In the case of buying an Acube 460 mobo for example).
Certain grumpy people who shall remain nameless might not like this but it's the law and there is sweet FA they can do about it except throw their toys out of the pram or take their ball home.
-
My tea comment was halfway facetious.
My point is;
IF Apollo Team decided today to go down the AOS route, and thru agreement ends up having to add 20-40 dollars to the Vampire; I still would find the accelerator DIRT cheap and well worth the money.
Gunnar has expressed rather clearly that he wants the ability to develop more advanced features, and as such, I would ASSUME any agreement regarding AOS would entail development of AOS/P96 in one form or another.
Im not privy to the details of the discussion, but I have gotten the impression that Gunnar havent found the details in the agreement satisfactory from his point of view. Thats fine. I wont villify the other side of the discussion got that reason.
Apollo Team got options if they decide against licensing, which is fine with me too, just as an AOS route would be.
Im not fundamentally against developers getting money for their work, which some seems to be.
the problem are not alone sums requested but also to guarantee future development and the rights to the sources and the ability to go a independent route without always asking. Thomas Richter admitted that the results would have been binaries, no source codes
-
I guess one good thing is that you only need one hardware solution for all future projects as it's FPGA. You won't need to worry about future compatability issues as long as you have expandability in mind.
For these kind of projects I also think an open source GPL like solution is the best, so similar projects can flurish unhindered. This threads fight and legal, emotional and monetary issues also shows that using P96 is not the best solution.
Also, I don't think AOS 4 users are going to flee to M68k/Vampire as -- which should be very very obvious by now -- they want something different than M68k users. I bet a lot of them are going to buy an A600 and Vampire and probably enjoy it a lot, but abandoning AOS 4? Most probably not.
-
Also, I don't think AOS 4 users are going to flee to M68k/Vampire as -- which should be very very obvious by now -- they want something different than M68k users. I bet a lot of them are going to buy an A600 and Vampire and probably enjoy it a lot, but abandoning AOS 4? Most probably not.
True, but the problem is the survival of AOS4 depends on the growth of its userbase, which primarily comes from the pool of classic users. With significant growth and advancements on the classic side to keep users interested the move to a NG platfrom is not nearly as enticing.
-
That may be true, but it's a different statement altogether.
-
True, but the problem is the survival of AOS4 depends on the growth of its userbase, which primarily comes from the pool of classic users. With significant growth and advancements on the classic side to keep users interested the move to a NG platfrom is not nearly as enticing.
It depends on what happens next really - and by that, I mean where the few remaining devs we have choose to invest their time.
After all, we already have OS4, MorphOS and AROS competing for users as the 'NG' platforms - Vampire makes 'classic' Amiga's viable for bigger (I won't say 'better') and more modern apps and games but aside from massively accelerating Workbench its current utility is limited by the (mostly old) software available.
If all users wanted was a blazingly fast classic Amiga then that's been available for years in the shape of UAE. Right now the Vampire is a novelty (and a fantastic technical achievement) but it's way too early to say how this is going to pan out.
I'm actually quite concerned this could potentially fragment the Amiga user-base more (if that's possible) since because the Apollo core's proprietary there's no guarantees that anything new it brings to the table will be available in (for example) WinUAE, MorphOS etc. potentially resulting in Vampire-only development that shuts out the wider community.
Time will tell - but in the meantime it's great to have powerful new options for the classic hardware.
-
True, but the problem is the survival of AOS4 depends on the growth of its userbase, which primarily comes from the pool of classic users. With significant growth and advancements on the classic side to keep users interested the move to a NG platfrom is not nearly as enticing.
so who are the actual vampires here? the whole years of indoctrination, that amiga is outdated and obsolete and was never good to start with, and that os4 is a real thing is going to fall in the water now? and it is again our fault or of those who provide alternatives that os4 doesnt grow winning the remaining amiga users over to postpone its decline?
-
All these recent happenings have pretty much made me convinced that the sooner AROS is a drop in replacement for OS3.x the better for the Amiga community.
The death of the proprietary vultures can't come soon enough.
thats exactly how I feel. +100
-
Has anyone tried Chris' Netsurf for OS3.5/9? It starts to be quite fast and most likely even faster with Vampire.
To get colors displayed right with PIcasso96 tester needs to edit user/choices file and put friend_bitmap:1 to it.
-
It depends on what happens next really - and by that, I mean where the few remaining devs we have choose to invest their time.
After all, we already have OS4, MorphOS and AROS competing for users as the 'NG' platforms - Vampire makes 'classic' Amiga's viable for bigger (I won't say 'better') and more modern apps and games but aside from massively accelerating Workbench its current utility is limited by the (mostly old) software available.
There's always the possibility of gaining new developers that were simply not interested in NG and previously bored with classic. I'm not sure how big that possibility is. It will be interesting to see, especially once standalone boards are available which could attract people who don't like messing with old hardware.
If all users wanted was a blazingly fast classic Amiga then that's been available for years in the shape of UAE. Right now the Vampire is a novelty (and a fantastic technical achievement) but it's way too early to say how this is going to pan out.
That's true, but many users do not like emulation and FPGA (either as an upgrade or even standalone) is much closer to real hardware. It feels more "true" than WinUAE does, and for some that matters.
I'm actually quite concerned this could potentially fragment the Amiga user-base more (if that's possible) since because the Apollo core's proprietary there's no guarantees that anything new it brings to the table will be available in (for example) WinUAE, MorphOS etc. potentially resulting in Vampire-only development that shuts out the wider community.
That's very true. This will be a test to see how big the active classic community is. If they continue to advance the platform at a reasonable price and sell lots of units (upgrades and standalones) the upgraded classic market would likely dwarf the NG platform.
-
Interesting times eh? :D
-
True, but the problem is the survival of AOS4 depends on the growth of its userbase, which primarily comes from the pool of classic users. With significant growth and advancements on the classic side to keep users interested the move to a NG platfrom is not nearly as enticing.
People almost forgot it... Amiga world is a market too... very small but a market. If f.e. 4.X covers needs most users do not have then they do not buy it. Simple as that. Vampire or other projects do not change that or do you think people will buy X5000s because of desperation?
-
People almost forgot it... Amiga world is a market too... very small but a market. If f.e. 4.X covers needs most users do not have then they do not buy it. Simple as that. Vampire or other projects do not change that or do you think people will buy X5000s because of desperation?
I don't think people buy NG Amigas out of "needs". I think they buy out of curiosity and entertainment, and boredom with their existing product. They like their Amigas, the current product is stagnant, so they look for the next evolution. Some feel that's AmigaOS 4.x, some feel it's MorphOS, some feel it's AROS, and I think most have not bought into any of the above.
I believe forward-thinking activity on the classic front will keep classic users more entertained with their existing platform.
I thought about an X1000 when it was announced. I exchanged emails with Trevor about beta testing, but when I saw the price I backed off. Not because I can't afford it, but because I couldn't justify it and I have not regretted my decision. Not necessarily because of the money, but because of where the platform has gone (really nowhere). Even today, playing with classic systems is more entertaining to me than NG.
Is there any doubt that Natami would have easily outsold the X1000? Even if priced at $1000? I think it would have outsold it tenfold.
-
People almost forgot it... Amiga world is a market too... very small but a market. If f.e. 4.X covers needs most users do not have then they do not buy it. Simple as that. Vampire or other projects do not change that or do you think people will buy X5000s because of desperation?
There's been a lot of obstacles to OS4 adoption but the most damaging has been a lack of reasonably priced (and specced) hardware.
I bought 4.1 FE to use with WinUAE/Amiga Forever and I've been enjoying using it under emulation - if there was some decent hardware to run it on in the 200 euro range then that's what I'd be doing.
-
I don't think people buy NG Amigas out of "needs". I think they buy out of curiosity and entertainment, and boredom with their existing product. They like their Amigas, the current product is stagnant, so they look for the next evolution. Some feel that's AmigaOS 4.x, some feel it's MorphOS, some feel it's AROS, and I think most have not bought into any of the above.
I believe forward-thinking activity on the classic front will keep classic users more entertained with their existing platform.
I thought about an X1000 when it was announced. I exchanged emails with Trevor about beta testing, but when I saw the price I backed off. Not because I can't afford it, but because I couldn't justify it and I have not regretted my decision. Not necessarily because of the money, but because of where the platform has gone (really nowhere). Even today, playing with classic systems is more entertaining to me than NG.
Is there any doubt that Natami would have easily outsold the X1000? Even if priced at $1000? I think it would have outsold it tenfold.
need is also just using something for hobby like people collecting certain things or using oldtimers in spare time. Need means people want something. For many obviously the NG route never was interesting, they would never buy used macs or expensive PPC hardware even if their existing hardware would break. More propably they would use UAE or drop out at all. My personal view. So I do not think that Vampire harms PPC sales.
-
need is also just using something for hobby like people collecting certain things or using oldtimers in spare time. Need means people want something. For many obviously the NG route never was interesting, they would never buy used macs or expensive PPC hardware even if their existing hardware would break. More propably they would use UAE or drop out at all. My personal view. So I do not think that Vampire harms PPC sales.
Need is not want, but that is not the point. I would say that I "need" a computer that does email and web browsing well - that's why I have a PC. I "want" to have an Amiga, which is why I own my Amiga related hardware.
Even Trevor/AmigaKit/Hyperion admit to survive they need to bring in more users, and the most likely potential new users (by far) are existing classic users. If things progress with FPGA, and especially if AROS gets some steam behind it, I believe it will absolutely hurt PPC sales.
I don't believe the existing user base can sustain the platform. How many people bought X1000s? How many of those will upgrade to X5000s? I believe X5000 sales will be considerably smaller than X1000 sales.
Look at how many users complained that they had to pay for AmigaOS 4.1 Final Edition - and it was cheap. Are these same users going to keep paying to sustain the platform?
We will see!
-
Some people complain about anything. AOS 4.1 FE is dirt cheap.
NG hardware is a whole different ballgame.
As for Vampire fragmenting the community even more;
I think it will have the opposite effect. In the past a "few" had 68060s and more than 32 megs of ram.
Now "everybody" will have 060++ level performance and atleast 2+128 megs of ram.
That will make releasing software even easier, since developers know there are 100s of people out there that can handle quite demanding software.
Take Backbone games. "Requires" 030 to be playable. In the future developers using that rather old gamecreator dont have to worry about speed atleast.
Internet access is faster too. I noticed comments about SERIOUS download speed increases VS old hardware (Vampire vs 060), when downloading to RAM.
Basically; more streamlined hardware which makes it easier for developers to produce more demanding software.
Additionally, people that had gone more or less inactive with their classic gear decides to dust off their old hardware since it got more "modern" performance=more activity.
-
Need is not want, but that is not the point. I would say that I "need" a computer that does email and web browsing well - that's why I have a PC. I "want" to have an Amiga, which is why I own my Amiga related hardware.
Even Trevor/AmigaKit/Hyperion admit to survive they need to bring in more users, and the most likely potential new users (by far) are existing classic users. If things progress with FPGA, and especially if AROS gets some steam behind it, I believe it will absolutely hurt PPC sales.
I don't believe the existing user base can sustain the platform. How many people bought X1000s? How many of those will upgrade to X5000s? I believe X5000 sales will be considerably smaller than X1000 sales.
Look at how many users complained that they had to pay for AmigaOS 4.1 Final Edition - and it was cheap. Are these same users going to keep paying to sustain the platform?
We will see!
Amiga is "want". For "need" you need decent new software, something people really want to have, perhaps even unique. That is much more than recompiled slightly updated old software. Difficult to get there.
-
@Niding
I do not think Vampire is fragmenting the platform very much
when you want to sell you want to cover as much as possible you will use 68020 and use AGA/ECS and/or the OS (3.X or Aros 68k)
there might be some software that will use new apollo commands for more speed (both games and applications) that will only run on Vampire
it is decision of developers
-
I think it will have the opposite effect. In the past a "few" had 68060s and more than 32 megs of ram.
Now "everybody" will have 060++ level performance and atleast 2+128 megs of ram.
That will make releasing software even easier, since developers know there are 100s of people out there that can handle quite demanding software.
I agree with you in principle however, 'Super AGA' is whatever the Vampire devs want it to be - there's been discussions about implementing additional coppers or enhanced blitters and that's great providing these architectural changes can trickle down to UAE (assuming the devs are even interested in supporting them) - if not then Vampire-optimised software will only ever run on a Vampire.
Same deal with Xena really (but that hasn't really been used for anything).
-
Amiga is "want". For "need" you need decent new software, something people really want to have, perhaps even unique. That is much more than recompiled slightly updated old software. Difficult to get there.
I agree. Usually there's a chicken/egg syndrome, but in this case it seems the new hardware will come before the possibility of new software - and the hardware is cheap enough that I think it will sell lots, especially once they release 500/1200 and standalone versions. This works because the hardware is beneficial to all users, even before new software. But if/when new software is written the hardware will be even more beneficial.
In his recent interview Gunnar seemed concerned that people may not have the motivation to write significant new software because the Amiga user base is so small. This is true, but it didn't stop him from working on this project so you never know!
-
I've had Amigas sine 93 with some breaks here and there. In 2010ish, i found acube, but couldn't afford a sam at that time. I found a used sam440ep on a Norwegian auction site a few years ago and bought it immediately.
I then found a sam460ex, which i also bought about a year ago.
Then i learned about the X1000, but it was expensive. 2500 euro, plus 25%VAT, plus import taxes, plus shipping from UK... It amounted to about 40000 Norwegian kroners (5700$) to get it into my living room, ready to tinker with.
Seeing as i've owned 5 cars for which i've paid 8000, 5500, 5000, 7000 and 13000, this ONE computer for which there are no fully functional browser, Office compatibility, no large, modern game titles (Diablo, wow, command&conquer, etc), i could in NO way justify spending more for that than all my cars combined.
Then a friendly Norwegian offered me a barely used one for around 1300$. So i bought it.
Now that i've owned it a year, i must say i love installing the OS, customizing things (yesterday i got back and forward in browsers working with extra buttons on my mouse with allkeys), i love changing backgrounds, and getting things to work, like mplayer, google drive, printer, etc...
But thats about it.
Don't get me wrong, i love my amigas, including this one, and i will buy an X5000 if the price is more down to earth than the X1000. Sure, i understand that they are made in short supply and development costs, but then you end up just selling to die-hards.
I've show my amigas and advocated for amiga to most my friends, but even the most adventurous ones, wont spend what could cover a 3 week family vacation to Spain for it. :-P
-
I agree with you in principle however, 'Super AGA' is whatever the Vampire devs want it to be - there's been discussions about implementing additional coppers or enhanced blitters and that's great providing these architectural changes can trickle down to UAE (assuming the devs are even interested in supporting them) - if not then Vampire-optimised software will only ever run on a Vampire.
Same deal with Xena really (but that hasn't really been used for anything).
I think RTG is much more important for new software than SAGA. And RTG uses OS calls
-
Now that i've owned it a year, i must say i love installing the OS, customizing things (yesterday i got back and forward in browsers working with extra buttons on my mouse with allkeys), i love changing backgrounds, and getting things to work, like mplayer, google drive, printer, etc...
But thats about it.
The software is different now, but that's what I loved most about my Amiga back in the day as well. That and some games, and of course showing off the capabilities of the Amiga vs. the PC.
Nowadays there's nothing to show off since, as you said, even the NG hardware is very outdated and the software is just not there.
So, is it worth the price of an X1000 just to tinker? For some it is, but not for most and not for me. And is tinkering that much more fun on the X1000 vs. the classics? Personally, I enjoy tinkering with classics and FPGA hardware MORE than I would on the X1000. But I can understand that some users are bored tinkering with their classics. For me time is short and I haven't spent much time tinkering in decades, so there are worlds left to explore when I do have the time.
But that's what the Vampire provides even today - lots more room to tinker, even for die hard users who may have been previously bored with their classics.
-
The software is different now, but that's what I loved most about my Amiga back in the day as well. That and some games, and of course showing off the capabilities of the Amiga vs. the PC.
Nowadays there's nothing to show off since, as you said, even the NG hardware is very outdated and the software is just not there.
So, is it worth the price of an X1000 just to tinker? For some it is, but not for most and not for me. And is tinkering that much more fun on the X1000 vs. the classics? Personally, I enjoy tinkering with classics and FPGA hardware MORE than I would on the X1000. But I can understand that some users are bored tinkering with their classics. For me time is short and I haven't spent much time tinkering in decades, so there are worlds left to explore when I have the time.
But that's what the Vampire provides even today - lots more room to tinker on the classics, even for die hard users who may have been previously bored with their classics.
I normally work on Windows... lots of functionality and a huge software base. Perfect for work but also very complicated with registry and so on. Amiga is simplicity, you can easily restore your system. Of course not the professional software but as a hobby it is perfect.
-
So, is it worth the price of an X1000 just to tinker? For some it is, but not for most and not for me. And is tinkering that much more fun on the X1000 vs. the classics? Personally, I enjoy tinkering with classics and FPGA hardware MORE than I would on the X1000.
It's an entirely different world on OS4 (even though it looks and behaves somewhat the same as 3.x) - the software (what little of it there is) is much more modern than the classic 68k stuff which is both a good and bad thing.
I've really enjoyed tinkering with OS4/WinUAE and I've even bought a few things from the AmiStore - it's a bittersweet thing - you see the potential but at the same time realise that its time has been and gone and that in its own way it's as much of a relic as the classic Amigas are.
Which is why it doesn't hold much of a value proposition. None of that prevents it from being fun though - the only question is how much is that fun worth to you? For me it's a purchased copy of the 4.1 FE ISO and WinUAE/Amiga Forever - the only other options currently available aren't justifiable (to me).
The Vampire looks like a wonderful platform to run a pimped-out AmiKit on though :)
I normally work on Windows... lots of functionality and a huge software base. Perfect for work but also very complicated with registry and so on. Amiga is simplicity, you can easily restore your system. Of course not the professional software but as a hobby it is perfect.
Likewise - I have a CD32 stashed away somewhere that I'll happily stick a Vampire in if they ever make one but my day-to-day computing is done on a Windows PC - WinUAE suits all my Amiga needs for the time being until something that offers me an experience that emulation doesn't comes along (at the right price ;)).
-
Regarding open-sourcing the apollo core, this is not going to happen for a reason which we all should agree with: the possibility of an ASIC made from the apollo core (think 2 GHz apollo instead of 100 MHz...). This will definitely not happen if the core were open-sourced because no investor will ever invest the necessary money into an open-sourced core. This is because
a) any competitor could just do the same killing the ASIC economically
b) the investor would have to fear that the open nature of the source will invite patent trolls who could claim that some part of the source infringes some patent (try proving that from the ASIC alone and you'll understand the difference...)
I'm 100% sure that anyone interested will be allowed (or rather encouraged) to replicate the 64-bit 68k mode and the SAGA extensions that apollo core will bring in their respective projects.
-
I'm 100% sure that anyone interested will be allowed (or rather encouraged) to replicate the 64-bit 68k mode and the SAGA extensions that apollo core will bring in their respective projects.
Here's hoping :)
-
If the community wants to go AROS, why should I stop them?
"should"? You clearly "want", since AROS will be "a mess" :)
But then, if everyone is begging for OpenSource, please be also so honest and open the source completely, and with full consequences. That means:
*) Do not build on a proprietary interface. Create your own, and open source that interface. You would probably notice how much work went into it and would appreciate the work of the original authors.
*) Do not build on a proprietary FPGA solution. Open source the solution as well.
Exactly, which is why I really do not have so much interest in apollo core, it is clearly just an attempt at monopolizing "the market".
-
what are you talking about?
there is nothing that would or will be monopolized
every adaption of Aros is benefitting everyone
as long developers do not use specific apollo commands or SAGA features software will run everywhere
-
Vampire is the future, SAGA offers higher resolution and more colors than AGA and more. Coming software will make use of it.
In their dreams - I will pester them online for attempting at monopolizing the Amiga market till they blow off like lemmings.
Apollo core will leak! :laughing:
-
In their dreams - I will pester them online for attempting at monopolizing the Amiga market till they blow off like lemmings.
Apollo core will leak! :laughing:
*sigh* :(
-
i love changing backgrounds, and getting things to work, like mplayer, google drive, printer, etc...
But thats about it.
changing backgrounds.. how weird.. i think its much more interesting and rewarding tryin to help others in a group of people of different interests working towards something independently. instead of sitting there alone pushing icons around you kind of socialize with complete strangers. i just joined the apollo dev irc yesterday, not even having the hardware and it really feels good because you contribute and receive. common problems are being solved.
-
In their dreams - I will pester them online for attempting at monopolizing the Amiga market till they blow off like lemmings.
Apollo core will leak! :laughing:
You wouldnt happen to be Frankos norwegian cousin?
-
Now "everybody" will have 060++ level performance and atleast 2+128 megs of ram.
Dream on.
-
it is decision of developers
Especially developers of compiler backends.
-
I'm 100% sure that anyone interested will be allowed (or rather encouraged) to replicate the 64-bit 68k mode and the SAGA extensions that apollo core will bring in their respective projects.
That is certainly not the impression I got from following this project over a year and a half. For a neat sum of money, the core can be licensed to your FPGA project, of course.
Why is there an Apollo vs. PowerPC vs NION (of all things) soft core speed comparison on the apollo-core website? What/who is Gunnar trying to attract with that?
-
You wouldnt happen to be Frankos norwegian cousin?
We are friends on FB and in contact every now and then, he is really a great guy :)
I was more weirded out by certain other amiga people who wanted to be friends with me there, but maybe it has not dawned on them who I am :laughing:
-
That is certainly not the impression I got from following this project over a year and a half.
"Replicate", not "take the code and use it". I suppose AMD didn't give Intel the VHDL sources to their x64 extension either...
For a neat sum of money, the core can be licensed to your FPGA project, of course.
I don't think for an FPGA project because then the code would spread. For an ASIC? I guess that would be a dream to come true.
Why is there an Apollo vs. PowerPC vs NION (of all things) soft core speed comparison on the apollo-core website?
A comparison against PowerPC makes sense in the Amiga world, even more so since the PPC softcore is actually marketed as an ASIC, too, I just forgot the part number. NIOS is a popular softcore and probably was available to the testers at IBM and serves the role as a neutral third for comparing both apollo and PPC.
What/who is Gunnar trying to attract with that?
I don't know. He may be proud of their 68k implementation which took them seven years and isn't even complete yet? He likes to point out that dropping 68k and going RISC wasn't as wise a move as it seemed in the early 90s. Perhaps he hopes that somebody will license the core for an ASIC?
-
changing backgrounds.. how weird.. i think its much more interesting and rewarding tryin to help others in a group of people of different interests working towards something independently. instead of sitting there alone pushing icons around you kind of socialize with complete strangers. i just joined the apollo dev irc yesterday, not even having the hardware and it really feels good because you contribute and receive. common problems are being solved.
Nothing wrong with tinkering :D I'm pretty OCD when it comes to setting up computers the way I want them and AmigaOS has always been insanely customizable and it doesn't really hold your hand either - the perfect recipe for endless tinkering ;)
And sure, collaborations are good and thanks to Amiga users and devs collaborating over the years we still (amazingly) have new toys to play with but that doesn't mean everyone's interest lies in that direction - I'm more an artist than a techie so I wouldn't bring much to that kind of scene - plus if there's one thing I hate about the Amiga community it's the politics and infighting - I don't have the patience for it any more.
But hey - I'm beta-testing the s**t out of WinUAE 3.3.0 at the moment ;)
-
"Replicate", not "take the code and use it". I suppose AMD didn't give Intel the VHDL sources to their x64 extension either...
It is one of those "I will believe it when I see it" things.
I don't think for an FPGA project because then the code would spread. For an ASIC? I guess that would be a dream to come true.
For Amiga users only, that is a very small market for doing ASIC production of an oddball CPU.
A comparison against PowerPC makes sense in the Amiga world, even more so since the PPC softcore is actually marketed as an ASIC, too, I just forgot the part number.
Are you saying that there are AmigaOne systems around running a FPGA softcore PowerPC?
NIOS is a popular softcore and probably was available to the testers at IBM and serves the role as a neutral third for comparing both apollo and PPC.
However, those other cores have features that appeal to the real world markets and are widely supported outside of Amiga sphere.
I don't know. He may be proud of their 68k implementation which took them seven years and isn't even complete yet? He likes to point out that dropping 68k and going RISC wasn't as wise a move as it seemed in the early 90s. Perhaps he hopes that somebody will license the core for an ASIC?
That could happen if the first products would be truly compatible with existing OSes, toolchains and software. Instead it is a core that is not really compatible enough, and does not yet have any toolchain and compiler backends. Hopefully they will show up, but with an architecture only catering to how Amiga use 68k, what are the odds it will happen? I have asked around in various other 68k camps (NetBSD, Linux, NeXT, Atari), and the answer is always the same - not compatible enough, cannot be bothered.
-
For Amiga users only, that is a very small market for doing ASIC production of an oddball CPU.
The apollo core could be interesting for other applications besides Amiga, Atari and other legacy 68k based devices. After all there are still companies producing 68k processors. Perhaps the company willing to invest into an apollo ASIC wouldn't even be aware of its possible use in an Amiga.
Are you saying that there are AmigaOne systems around running a FPGA softcore PowerPC?
I don't know because I never was interested in PPC-Amigas. But I'm pretty sure Gunnar mentioned that the same VHDL as the PPC Softcore was available as an ASIC.
However, those other cores have features that appeal to the real world markets
Which features do you think the apollo core is lacking that the others offer? PPC/NIOS code compatibility does not count.
That could happen if the first products would be truly compatible with existing OSes, toolchains and software. Instead it is a core that is not really compatible enough
Why do you think so? MMU again? An MMU may be implemented if there is enough interest.
I have asked around in various other 68k camps (NetBSD, Linux, NeXT, Atari), and the answer is always the same - not compatible enough, cannot be bothered.
And they based their assessment on what source of information?
-
As an Atari user I am following development of an Apollo core very closely. It is amazing what have been done. But as Kolla said ... without FPU and MMU it is worthless to me. Some ST users would consider it but they are not "power" users and use their ST-s unaccelerated for playing games.
Most "power" Atari users use MiNT as OS which needs at least minimal implementation of MMU.
FireBee allready uses Coldfire CPU which is comparable fast to Apollo core. Regarding MIPS is about 4 time faster and regarding BUS speed and scalability is a lot slower. But as it seems there wont be MMU to apolo core in near future, we are looking for faster Coldfire solutions. They are available but not in our budget range :)
But we will try to find the agreement with IP-Extreme which is a holder of the Coldfire licences.
As Apollo core is really interesting product for Amiga comunnity I believe as Kolla said, it is a cripled CPU implementation and it will take time to be interesting for other 68k communities (if it wont be only Amiga oriented).
I wish I am wrong and that we would be able to use Apollo core also in our projects as suitable CPU soon ... :)
-
without FPU and MMU it is worthless to me.
All FPU instructions are implemented and tested but the FPU subsystem (e.g. program flow) needs testing which is postponed right now.
As for the MMU, I already mentioned that Gunnar said that it may happen if there is enough interest. However, this interest would have to manifest itself in the form of money. So go collecting and it may get some priority over SAGA (unless Amiga people outbid you... :roflmao:).
BigGun just confirmed to me that they could do a full 68k MMU that would e.g. allow Debian to run on the apollo core. He said that it would take quite a few week-ends worth of work. So what do you think that would be worth?
it is a cripled CPU implementation
IMHO Coldfire is far more a crippled 68k implementation than apollo...
And don't make Gunnar angry or the price for an MMU will double immediately... :lol:
-
As for the MMU, I already mentioned that Gunnar said that it may happen if there is enough interest. However, this interest would have to manifest itself in the form of money. So go collecting and it may get some priority over SAGA (unless Amiga people outbid you... :roflmao:).
That's strange. Now that the vampire depends on open source, wouldn't it be a better or at least more plausible alternative to let open source developers implement it?
Why do you need a MMU? Because you'll need one in big box Amigas with DMA sources that transmit data on memory from one Zorro slot the same Zorro slot. Such transfers are not visible neither snoop-able by the CPU. Or you need to disable caching while DMA is running.
BigGun just confirmed to me that they could do a full 68k MMU that would e.g. allow Debian to run on the apollo core. He said that it would take quite a few week-ends worth of work. So what do you think that would be worth?
Probably the lack of one makes it pretty hard to let the vampire work correctly in some situations that can arise when DMA traffic is running.
IMHO Coldfire is far more a crippled 68k implementation than apollo...
Yes, though crippled in another way. Coldfire does not implement most word and byte-sized instructions, and that is a major show-stopper on the Amiga.
And don't make Gunnar angry or the price for an MMU will double immediately... :lol:
Why? Why should Gunnar implement it in first place? Just open source the core, and somebody else will implement it for him.
-
That's strange. Now that the vampire depends on open source, wouldn't it be a better or at least more plausible alternative to let open source developers implement it?
Why would this be the case?
-
Some general comments on the CPU technology. I have had no direct contact with Gunnar, these are my own views.
The T68K opensource CPU we use in FPGAArcade and Mist runs at 28MHz single cycle when using I&D cache (in replay at least). If I was to build this on a Kintex ultrascale+ 16nm device (which are relatively cheap now) I'm pretty sure it would run at the base clock of 114MHz - which would give it similar performance to the Apollo core for zero effort. I'll try this next week.
With some pipeline efforts which are going on, and new table based designs, 3-4x increase is perhaps possible. An opensource MMU may come at some point. These will likely be licensed under the GPL which would not enable them to be used with a closed source core.
Now - I'm putting on my ASIC manager hat. As a day job I work for a mature startup designing big endian CPUs for telecoms use (!).
I have use of the very expensive Cadence tools used for ASIC layout, and a team of people who can build these things. Even given all this, the numbers don't work out. To fab out a 28nm ASIC the mask costs are horrific.
You could try and find a fab which still made 90nm or even older nodes, and yes these are cheaper, but to be honest a 16nm finfet FPGA will be faster - and cheaper per unit part.
I've sourced IP for ASIC as well. When doing this, you need to be very very sure of your supplier and that you will not run into any GPL or licensing issues down the road. There are several suppliers selling highly tested, ASIC proven 68K class cores on the market already today.
If you want a 1-2GHz big endian CPU, people tend to use QoiIQ (PPC) which is cheap in volume and a complete SOC (memory controller, Ethernet, PCIe etc etc).
I really wish Gunnar well with his project, it's certainly a lot of work, but I don't believe it's going to end up as an ASIC.
/MikeJ
-
Why would this be the case?
Why? Don't you see the problem? There are many helping hands in the open source world that now build on the Os the vampire will depend on, and that is needed to create an income for the vampire. I believe it's really more than fair that *under such conditions* to return the project to the community as well. Fully. I cannot be that a closed source project operates on the back of open source developers. It's not a fair trade.
-
Why? Don't you see the problem? There are many helping hands in the open source world that now build on the Os the vampire will depend on, and that is needed to create an income for the vampire. I believe it's really more than fair that *under such conditions* to return the project to the community as well. Fully. I cannot be that a closed source project operates on the back of open source developers. It's not a fair trade.
Quick you better email Intel and tell them to GPL the source to their CPU's. After all they depend on Linux.
legal@intel.com
-
Quick you better email Intel and tell them to GPL the source to their CPU's. After all they depend on Linux.legal@intel.com
That were my thoughts exactly.
-
That's strange. Now that the vampire depends on open source
It doesn't, why should it?
wouldn't it be a better or at least more plausible alternative to let open source developers implement it?
Why? I don't see a logical connection there.
Why do you need a MMU? Because you'll need one in big box Amigas with DMA sources that transmit data on memory from one Zorro slot the same Zorro slot. Such transfers are not visible neither snoop-able by the CPU. Or you need to disable caching while DMA is running.
Yes, you mentioned that before. Looking at the numbers of Amigas sold, there are not really all that many bigbox Amigas out there. So it would be an economical decision whether they would get to enjoy an apollo or not.
Why? Why should Gunnar implement it in first place? Just open source the core, and somebody else will implement it for him.
I have seen the source code and I know VHDL (I happen to be a microchip developer by first profession although I mainly did high-speed transistor level CMOS design and less synthesised VHDL design). I don't think anybody could pick up development on that giant project easily.
The T68K opensource CPU we use in FPGAArcade and Mist runs at 28MHz single cycle when using I&D cache (in replay at least). If I was to build this on a Kintex ultrascale+ 16nm device (which are relatively cheap now) I'm pretty sure it would run at the base clock of 114MHz - which would give it similar performance to the Apollo core for zero effort. I'll try this next week.
It's about performance per USD or %&$#?@!%&$#?@!%&$#?@!8364;. Gunnar mentioned that he has some Stratix boards available. So what performance could we expect from them? It doesn't really matter as it would be pointless to put a 10,000 USD FPGA on an Amiga accelerator. How much do FPGAArcade and Mist cost and how does their 68k performance compare to the 150%&$#?@!%&$#?@!%&$#?@!8364; vampire?
But let us hear about your results.
EDIT: btw, are you interested in implementing the 64 bit mode in your enhanced tg68 (or SAGA features)?
These will likely be licensed under the GPL which would not enable them to be used with a closed source core.
Aren't you using GPL'ed stuff and thus have to open-source your modifications anyway?
I really wish Gunnar well with his project, it's certainly a lot of work, but I don't believe it's going to end up as an ASIC.
It's not very likely, yes. That doesn't mean that this possibility should be killed from the start by open-sourcing the project.
-
The T68K opensource CPU we use in FPGAArcade and Mist runs at 28MHz single cycle when using I&D cache (in replay at least). If I was to build this on a Kintex ultrascale+ 16nm device (which are relatively cheap now) I'm pretty sure it would run at the base clock of 114MHz - which would give it similar performance to the Apollo core for zero effort. I'll try this next week.
Mike, Mist and Vampire use the same Cyclone 3 FPGA. Mist runs at 28MHz on it when Apollo runs at 100MHz. Running Apollo on Kintex would probably lead to something in the 800MHz range.
-
I cannot be that a closed source project operates on the back of open source developers. It's not a fair trade.
You are correct... Therefore AOS4 should be opensourced and so should AOS 3.5 and 3.9.
-
Quick you better email Intel and tell them to GPL the source to their CPU's. After all they depend on Linux.
Could you please be serious? Since when does an i5 depend on Linux? It's only a relatively small market compared to intel's overall income, and intel *surely* contributes back to the community. They finance an open source support team, provide open source graphics drivers for their CPUs, and open source support tools for their CPU. So it's a "take and give", and it is for me a fair trade. Does any of the income from the vampire go back into open source development? Or is its core open source? I beg your pardon, but I've a bit of a problem with the ethics here.
-
It's about performance per USD or €. Gunnar mentioned that he has some Stratix boards available. So what performance could we expect from them? It doesn't really matter as it would be pointless to put a 10,000 USD FPGA on an Amiga accelerator. How much do FPGAArcade and Mist cost and how does their 68k performance compare to the 150€ vampire?
But let us hear about your results.
Aren't you using GPL'ed stuff and thus have to open-source your modifications anyway?
It's not very likely, yes. That doesn't mean that this possibility should be killed from the start by open-sourcing the project.
Grond - good comments on the RTG earlier by the way, nice to see a reasoned argument for a change.
FPGAArcade Replay board is 199Euro+tax. Currently synthetic performance (benchmarks) is about 1/6th, but we should get to 1/4 to 1/3 of the Apollo core. We need to change to a pipelined architecture to increase performance further. I've had such a core going for years, but it's been easier to debug the T68K so far. System performance is quite speedy - the board has fast hard disk, blitter for RTG etc so it feels faster than the numbers would suggest.
Small modern FPGAs are quite cheap, we are talking more in the 50USD range than 10K.
I am not a fan of the GPL license for hardware - my stuff is usually licensed under a "do what you like style" - and yes it's open. As I am using the T68K core which is GPL, I release any modifications to that immediately (svn.fpgaarcde.com) and I must release the rest of the design - although not necessarily under the same license. The Amiga core is partially released now (I've send files to the Mist team), I'm awaiting some advice on modifying my usual license to prevent use in completely closed source designs.
I have no problem with Gunnar not open-sourcing his code, and I get extremely irritated by people demanding I open source everything as "we have a right to see it" - go write your own.
"Mist and Vampire use the same Cyclone 3 FPGA. Mist runs at 28MHz on it when Apollo runs at 100MHz. Running Apollo on Kintex would probably lead to something in the 800MHz range"
It doesn't quite work like that. Apollo has been pipelined but those benefits do not really carry through to smaller geoms - you run into routing delays etc. I would guess 200-300MHz absolute max.
Even with 28nm ASIC you have to work a bit to get much above 500MHz.
/MikeJ
-
Could you please be serious? Since when does an i5 depend on Linux? It's only a relatively small market compared to intel's overall income, and intel *surely* contributes back to the community. They finance an open source support team, provide open source graphics drivers for their CPUs, and open source support tools for their CPU. So it's a "take and give", and it is for me a fair trade. Does any of the income from the vampire go back into open source development? Or is its core open source? I beg your pardon, but I've a bit of a problem with the ethics here.
The Apollo is a CPU it " depends" on no operating system whatsoever just like an Intel, ARM or any other brand of CPU.
I know your feelings have been hurt and probably your wallet too but you need to get over it.
You can't always get what you want in life. It's not a big deal.
-
The Apollo is a CPU it " depends" on no operating system whatsoever just like an Intel, ARM or any other brand of CPU.
Oh, ok, so you just say that RTG does not depend on AROS? Or the RAM of the vampire of a custom initialization procedure?
I know your feelings have been hurt and probably your wallet too but you need to get over it.
You can't always get what you want in life. It's not a big deal.
No, that's not quite the point. I want to understand the logic here.
Paying part of the income for closed developers from a closed source project is bad. Not paying open source developers from a closed source project is good.
I'm sorry. You lost me.
-
(http://i.imgur.com/AeaVJQE.jpg)
-
https://www.youtube.com/watch?v=Uia6a4LJcNM
-
Why? Why should Gunnar implement it in first place? Just open source the core, and somebody else will implement it for him.
thomas, is this sarcasm?;) outta the suddden you postulate to open everything and start to playing devils advocate for the open source developers who out of their free will and with their own professional knowledge support gunnar and his core?
first thing is none ever said open source is healing all wounds. in our particular situation as community it is means to work together, contribute and preserve code in which companies may not have interest in. this doesnt neccesarily translate to hardware, even if id prefer it to be open as well, but have you ever seen me saying x1000 should be open sourced? however amiga hardware in fact becomes open thanks to private hacking, reverse engeneering, emulation and fpga projects.
now you also need to be pragmatic and justify expenses against contributions. this isnt even an option with os4 or the entities behind. however taking part in apollo irc i sense it helps a good deal to push apollo and aros forwards independently of each other. calculating interests, there might be some better, more satysgfying, more popular and cheaper future solutions for amiga fans than currently. software and hardware wise. and everybody needs to calculate his interests and investments himself. i do, certainly, as much with apollo, which i dont have btw, as with aros.
-
Could you please be serious? Since when does an i5 depend on Linux? It's only a relatively small market compared to intel's overall income, and intel *surely* contributes back to the community. They finance an open source support team, provide open source graphics drivers for their CPUs, and open source support tools for their CPU. So it's a "take and give", and it is for me a fair trade. Does any of the income from the vampire go back into open source development? Or is its core open source? I beg your pardon, but I've a bit of a problem with the ethics here.
So AROS guys have no problem in making it work for the x86 platform, but suddenly if a new chip is used on par with amiga, things eventually change... that's odd.
-
As a person who worked a lot with TG68 I think that I know a lot about it. Only thing I ll say is that TG68 have nice feature to be able to run at higher speeds and shows some nice results. Too bad that in real life we can consider those results as a fake. Maybe bustest can prove me wrong.
-
As a person who worked a lot with TG68 I think that I know a lot about it. Only thing I ll say is that TG68 have nice feature to be able to run at higher speeds and shows some nice results. Too bad that in real life we can consider those results as a fake. Maybe bustest can prove me wrong.
Hi Majsta. Not quite sure I understand what you mean?
Even with the cache logic around the TG68, I don't have any problems (now) getting 28MHz out of it. Executes in single cycle. P&R takes around 3 mins.
Going much faster with the current design on the Spartan FPGA is not going to happen without pipelining it, true.
I'm rebuilding my laptop for some Kintex+ development, I'll give it a run though and see what speed we get.
If Gunnar sends the Apollo code (under NDA obviously) I'll run it through the ASIC toolchain and we can see the predicted performance with TSMC 28nm?
/MikeJ
-
Maybe bustest can prove me wrong.
READL is about 29MB/sec - but I've yet to finish the 32 bit changes to TG68 (The CPU data bus is 16 bit, cache is 128 bit).
I expect to get to around 60MB/sec which is comparable to a 68060.
-
At the time, 3 years ago I had best result with TG68 and I think that no one were able to beat it yet. Those results regarding bustest are exactly 12X lower than slowest compiled version of Apollo is capable of. In standalone system I m making now according to calculations we will double Apollo performance. Exact reason why I stopped messing with TG68...
-
Mike, I also have to say that I doubt that the tg68 can reach anywhere near the speed of the apollo core without rewriting it to become the apollo core. Perhaps you just haven't realised the speed the apollo delivers yet. Just look at the different real world programs and benchmarks out there. What about tg68's adoom fps in 640x480? Riva media player? mp3 decoding?
I saw the tg68 vhdl about a year ago and even just judging from the code size it is the bare minimum for making it execute 68k code. I guess the apollo code is several dozen times bigger, if not 100s of times. Heck, I bet there are more signal declarations in apollo than tg68 has lines of code! Gunnar and the others making the apollo core are professional CPU designers and have been working on the apollo core for seven years!
Obviously the tg68 didn't do any pipelining (as you mentioned). Then what about superscalar code execution? This would mean another order of magnitude of complexity to add. We already had three times superscalar core versions. Has any work been done on an FPU for tg68? I don't remember seeing any code for that (but I only went through the code quickly and, as it seems, there are several variations of it). As already mentioned the apollo FPU was implemented a long time ago but needs testing which is why it's not enabled in the public cores.
Making the buses wider will sure help throughput of the tg68 but it won't make clocking the core higher any easier either. Then what about the 64 bit mode and new instructions (which you are invited to add if you want)? I guess with all the other tasks required to speed up tg68 this would be of low interest. But these enhancements will enable the apollo core to run a whole new range of software while tg68 would still be struggling to reach 030 or even 040 speeds (which would require a lot of progress already).
I think the FPGAArcade has its strong points in being a stand-alone board (of course, this advantage will be rendered moot by the vampire stand-alone board), in emulating other systems for which no such thing as the apollo exists and for people exclusively interested in running legacy code written for unaccelerated A500s or A1200s and WHDload stuff similar to the ACA cards. But it would be a very, very, very long way for the tg68 core to surpass what actual Amigas could do in 1994.
-
At the time, 3 years ago I had best result with TG68 and I think that no one were able to beat it yet. Those results regarding bustest are exactly 12X lower than slowest compiled version of Apollo is capable of. In standalone system I m making now according to calculations we will double Apollo performance. Exact reason why I stopped messing with TG68...
I guess you had not written a cache ?
/MikeJ
-
I saw the tg68 vhdl about a year ago and even just judging from the code size it is the bare minimum for making it execute 68k code. I guess the apollo code is several dozen times bigger, if not 100s of times. Heck, I bet there are more signal declarations in apollo than tg68 has lines of code! Gunnar and the others making the apollo core are professional CPU designers and have been working on the apollo core for seven years!
Hi,
I think you miss understand me a little. I am not suggesting the TG68 will out perform the Apollo core, I am saying then if targeted to a more modern FPGA it will get similar performance for little effort.
I too am an ASIC CPU designer b.t.w.
"But it would be a very, very, very long way for the tg68 core to surpass what actual Amigas could do in 1994. "
It already is petty much, and as I said complete system compatibility is more important to me. I'm sure I could run the a software 68K emulator on a 10$ SOC and surpass the performance of the Apollo core without all the effort. If the CPU core is faster, then what is the difference between an FPGA CPU and an emulated on a different CPU, CPU? Especially if the rest of the hardware is still FPGA based?
http://www.xilinx.com/support/documentation/selection-guides/zynq-ultrascale-plus-product-selection-guide.pdf
Quad core 1.5GHz ARM +16nm FPGA fabric?
/MikeJ
-
I think you miss understand me a little. I am not suggesting the TG68 will out perform the Apollo core, I am saying then if targeted to a more modern FPGA it will get similar performance for little effort.
This is a hare and tortoise type argument. When you put tg68 in a faster FPGA to narrow the gap to apollo, apollo will already be in that faster FPGA and again far ahead of you.
"But it would be a very, very, very long way for the tg68 core to surpass what actual Amigas could do in 1994. "
It already is petty much
"Actual Amigas" meant 060 and graphics cards.
complete system compatibility is more important to me.
Yes, that makes a lot of sense. People that want to "smell and feel" an Amiga will rather put an accelerator board into an Amiga. People bored with software emulation running in some window on their desktop computer but do not want to worry about aging hardware, leaking capacitors and so on will consider an FPGAArcade or vampire stand-alone. Compatibility will be a major factor, though, as it's not very likely that software will be written having workarounds specifically for some incompatibilities of these FPGA Amiga reimplementations. Assuming you have enough Amigas to test compatibility, I wonder whether it would make sense to provide you and/or your team with a few vampires so that we could assure that there is no new software that works only on one of the two reimplementations but not on the other.
EDIT: "new software" as in drivers or any other stuff we write for our projects
-
"This is a hare and tortoise type argument. When you put tg68 in a faster FPGA to narrow the gap to apollo, apollo will already be in that faster FPGA and again far ahead of you."
The gap will be narrower. As I said the routing delays become similar to the logic delay. I'll run some tests next week.
"Actual Amigas" meant 060 and graphics cards.
Yup, we have a HD capable graphics card with dedicated blitter, and ~ 060 performance (sans MMU and FPU) already.
Anyhow, best of luck with the roll out.
/MikeJ
-
On an unrelated note, it would be sweet to have one of these:
http://www.theinquirer.net/inquirer/news/2449101/hacker-turns-floppy-disc-drive-into-128gb-card-reader
-
The gap will be narrower. As I said the routing delays become similar to the logic delay. I'll run some tests next week.
America and Europe are getting closer to each other each year by continental drift... :)
That in itself doesn't mean much. Let us hear about your test results, any progress is good. But right now it doesn't sound like a convincing approach to have a more expensive product which has less processing power than your competition and then trying to solve this by putting in a more expensive component.
Yup, we have a HD capable graphics card with dedicated blitter, and ~ 060 performance (sans MMU and FPU) already.
That must be a very wide interpretation of "approximately". You have 28 MHz clock, the 060 at least 50 MHz. The 060 does simple instructions in one clock cycle and so do you. But the 060 can do a second simple instruction in the same clock cycle while you can't. The 060 has very good branch prediction and fast branches, you have none. The 060 has 32 bit wide buses, you still need to remove the 16 bit limitation. The 060 has fast caches, you still need to add those.
I estimate that you are currently in the 030 range of performance. If you manage to do the caches, the wider buses and improve the clock rate, you'll be entering 040ish performance. Still a long way to go as the apollo core is twice as fast as an 060 right now and still improving. Let's hear your adoom fps, Riva playback, mp3 decoding and how they are improving while you are making the core faster. For us the adoom fps is a standard test because it is more interesting than just some sysinfo MIPS.
BTW, does the fact that you didn't say anything about the offer to try to maintain compatibility between the apollo core and the fpgaarcade's implementation of AGA and 68k that you are going to consider it?
-
But right now it doesn't sound like a convincing approach to have a more expensive product which has less processing power than your competition and then trying to solve this by putting in a more expensive component.
It's slightly more expensive, but it is the complete system. It's also a bit more than a one-trick-pony, so to speak. Who said the newer FPGA would be more expensive than the current one?
"The 060 has fast caches, you still need to add those."
I have full I & D cache with full bus snooping and prefetch already.
"For us the adoom fps is a standard test because it is more interesting than just some sysinfo MIPS."
For sure, I'll give it a go. If I want to play adoom at silly speeds however, I'll dig out UAE and run it on the PI.
"BTW, does the fact that you didn't say anything about the offer to try to maintain compatibility between the apollo core and the fpgaarcade's implementation of AGA and 68k that you are going to consider it?"
If the Apollo core adds non-standard instructions then it's no longer "retro" and of little interest (to me at least) to emulate. The beauty of open source is that it's an option open at any time of course.
/MikeJ
-
If the Apollo core adds non-standard instructions then it's no longer "retro" and of little interest (to me at least) to emulate.
OK, I understand that. How about stuff like device drivers? I think that's something where both strictly retro and enhanced retro implementations can benefit from cooperation. Our device drivers will be open.
-
America and Europe are getting closer to each other each year by continental drift... :)
Not.
-
Farther apart?
-
OK, I understand that. How about stuff like device drivers? I think that's something where both strictly retro and enhanced retro implementations can benefit from cooperation. Our device drivers will be open.
I so no reason not to. My RTG driver will be open too. I have a licensed USB stack so binaries only for that at the moment.
-
Farther apart?
Are you serious?
Yes.
In other news, the earth is orbiting the sun. :laughing:
-
With the Vampire requiring AROS, and only new software being able to make benefit from the improvements Apollo core has over old 68k - what benefits are there in running AROS on Apollo core vs running AROS on a cheap ARM or AMD64 system?
-
With the Vampire requiring AROS, and only new software being able to make benefit from the improvements Apollo core has over old 68k - what benefits are there in running AROS on Apollo core vs running AROS on a cheap ARM or AMD64 system?
What about a seemless 68k compability?
-
With the Vampire requiring AROS, and only new software being able to make benefit from the improvements Apollo core has over old 68k - what benefits are there in running AROS on Apollo core vs running AROS on a cheap ARM or AMD64 system?
Pure awesomeness? o.O
-
With the Vampire requiring AROS, and only new software being able to make benefit from the improvements Apollo core has over old 68k - what benefits are there in running AROS on Apollo core vs running AROS on a cheap ARM or AMD64 system?
First of all, I don't think anyone is saying the Vampire would REQUIRE AROS. Second of all, I believe they are suggesting the possible use of AROS to replace Kickstart. You would still be able to use Workbench.
-
With the Vampire requiring AROS, and only new software being able to make benefit from the improvements Apollo core has over old 68k - what benefits are there in running AROS on Apollo core vs running AROS on a cheap ARM or AMD64 system?
then why running 3.X on Apollo core or more precise why running anything amiga related at all?
-
First of all, I don't think anyone is saying the Vampire would REQUIRE AROS. Second of all, I believe they are suggesting the possible use of AROS to replace Kickstart. You would still be able to use Workbench.
who can proof that he owns original roms gets a system with 3.1. kickstarts, everyone else with roms
3.X will not be developed because no sources, P96 is supported by a driver but nothing else
support for improved hardware will only be available at Aros (of course software can still directly hack the hardware on 3.X)
I hope all was correct
-
I am not a fan of the GPL license for hardware
Maybe have a look at the CERN open hardware license (http://www.ohwr.org/projects/cernohl/wiki) which should be a copyleft type license fit for hardware. At last ORConf (http://openrisc.io/orconf/) it has been shown that the (L)GPL (https://www.youtube.com/watch?v=UOZkiOtmHEQ&index=28&list=PLUg3wIOWD8yoX2ECfeU_QP5snbu2Zs1Wp) is not really a good fit for hardware; especially the standard cell libraries seem to still be poblematic.
-
With the Vampire requiring AROS, and only new software being able to make benefit from the improvements Apollo core has over old 68k - what benefits are there in running AROS on Apollo core vs running AROS on a cheap ARM or AMD64 system?
Apollo is more compatible with 68000/68020 then 68060 so you have no clue what you are talking about..... Troll away....
-
3.X will not be developed because no sources, P96 is supported by a driver but nothing else
Err, what? Of course the sources for 3.X exist. It's not developed because everybody here tells me "go away, we have no interest in it". That's a difference. Again, I've no problem if people prefer AROS - that's a choice everybody can make - but don't tell me that there are no sources for 3.X. There most certainly are, and they would be most certainly be used if there would be interest in a - albeit closed source, paid - development. So please, let's be honest about this. If you prefer Open Source - good. But that doesn't mean that the closed source sources are lost in time and space and that there would be nobody that would work on them. I hope all was correct
I afraid not quite so.
-
Err, what? Of course the sources for 3.X exist. It's not developed because everybody here tells me "go away, we have no interest in it". That's a difference. Again, I've no problem if people prefer AROS - that's a choice everybody can make - but don't tell me that there are no sources for 3.X. There most certainly are, and they would be most certainly be used if there would be interest in a - albeit closed source, paid - development. So please, let's be honest about this. If you prefer Open Source - good. But that doesn't mean that the closed source sources are lost in time and space and that there would be nobody that would work on them.
I afraid not quite so.
cmon. thomas, its not like those sources werent there all this time. has anybody developed anything amiga upon them? nope. you are the only one who ported over some of your own improvements just lately. i dont know on what deal. the people have been approached before with proposintions and there was only one replay if any: they are not interested in supporting or letting others support amiga, come over to os4/ppc. i was banned from amigans sharing some experience because i was simply mentioning 68k in the context.
above all else you yourself said, you had no time to work on amiga, so who would be those people who would? maybe now, seing interest in vampire someone suddenly woke up somewhere there sniffing cash, but we had no any positive experience let alone support from whoever claims the access to the sources for te past years except olsen (who commercially releaed his rapid road for amiga) and you.
this is the result.
-
Err, what? Of course the sources for 3.X exist. It's not developed because everybody here tells me "go away, we have no interest in it". That's a difference. Again, I've no problem if people prefer AROS - that's a choice everybody can make - but don't tell me that there are no sources for 3.X. There most certainly are, and they would be most certainly be used if there would be interest in a - albeit closed source, paid - development.
Err, what? From your answer is unclear (at best) who is interested and who is not. I suppose users are interested for quite a long time. They proved it by buying OS3.5/3.9/AmigaForever/on forums, many many times. Parties who are NOT interested are copyright owners and developers (yes developers too, if we agree that there is the way how to reach the license and sources).
-
Err, what? Of course the sources for 3.X exist. It's not developed because everybody here tells me "go away, we have no interest in it". That's a difference. Again, I've no problem if people prefer AROS - that's a choice everybody can make - but don't tell me that there are no sources for 3.X. There most certainly are, and they would be most certainly be used if there would be interest in a - albeit closed source, paid - development. So please, let's be honest about this. If you prefer Open Source - good. But that doesn't mean that the closed source sources are lost in time and space and that there would be nobody that would work on them.
Please... of course people want OS 3.x 68K further developed, especially with new/fast hardware becoming more and more available. If a new version with significant updates was done it would surely sell more copies than OS 4.x (assuming it was priced reasonably).
-
cmon. thomas, its not like those sources werent there all this time. has anybody developed anything amiga upon them? nope. you are the only one who ported over some of your own improvements just lately. i dont know on what deal.
Unpaid, actually. Released with permission of the owner, no other strings attached. Only done because I had some hope in new developments, new developments that would be triggered by the arrival of new hardware. the people have been approached before with proposintions and there was only one replay if any: they are not interested in supporting or letting others support amiga, come over to os4/ppc. i was banned from amigans sharing some experience because i was simply mentioning 68k in the context.
A company has to work on a profit basis - they saw the market in the PPC area. If you ask me, a stupid decision in first place, but that was their decision. Whether *I* invest my time into PPC is again my decision. I decided against it - as it seems, a wise decision. above all else you yourself said, you had no time to work on amiga, so who would be those people who would? maybe now, seing interest in vampire someone suddenly woke up somewhere there sniffing cash, but we had no any positive experience let alone support from whoever claims the access to the sources for te past years except olsen (who commercially releaed his rapid road for amiga) and you.
You call it "sniffing cash", I call it "a business opportunity". What exactly is wrong with working for money, and earning money? There's a new interesting product on the market that triggers interest in users investing into the classics. Of course that also means that now the owner of the Os sees some interest in investing into the classics. It also means that some developers show again interests in the classics.
Of course, nobody would be getting rich by this development, but in end, everybody could have had what wasn't possible before , a renovated Os, a renovated hardware, new software. Sounds like a win-win situation to me. this is the result.
Yes, it is. Look, if OpenSource should be it, then please do that. No problem either.
But again, then it should be *really* OpenSource. That is, the FPGA should be OpenSource, the interface should not depend on legacy interfaces that are not open. You cannot first negotiate with the owners on licensing the rtg graphics interface, and later on work around this negotiations and ignore the owners and forget the negotiations just because it now suddenly fits better to the plan to do so.
-
@Thomas Richter
So stop complaining and get your act together:
Build and sell a new AmigaOS for 68k and compete with current Aros 68k offerings.
I am sure I, like many other over here that complain, will still buy yours, and try Aros.
I am pretty confident you will get a few thousand sales if you hurry up and deliver a good product at the right price. The more you wait the stronger your competitor gets (Aros).
So in the end it is up to you to stop this wishful thinking and debate of further AmigaOS 68k development (it has been going through a few years already), and start delivering, or your market will migrate to other offerings (Aros).
Competition is always a good thing for the consumer (but not so good for the entrepreneurs).
Good luck!
-
@Thomas Richter
So stop complaining and get your act together:
....
Good luck!
Are you suggesting or are you sarcastic? I *personally* believe it stops making sense at this time. There is a clear indication now, and a clear decision has been made that this is not wanted nor desired.
In the end, nobody trusts Hyperion at this point, given their past decisions. Do I trust them? Honestly - possibly not. The only thing I know is that it cannot work without them, so I personally considered it would be at least worth a try. Unfortunately, as it seems, it neither can work with them.
So here we are.
-
A company has to work on a profit basis - they saw the market in the PPC area. If you ask me, a stupid decision in first place, but that was their decision. Whether *I* invest my time into PPC is again my decision. I decided against it - as it seems, a wise decision.
same as mine. well, they decided, they were stubborn and aggresive about it, now its their problem, not ours.
You call it "sniffing cash", I call it "a business opportunity". What exactly is wrong with working for money, and earning money? There's a new interesting product on the market that triggers interest in users investing into the classics. Of course that also means that now the owner of the Os sees some interest in investing into the classics. It also means that some developers show again interests in the classics.
but it is not their product, they want to cash upon, ist someone elses. looks rather typical. if you ask me they are free to deliver commercial product supporting it, the market will show how succesful it would be. but demanding funding up front has proven wrong with os4 and everything else it was associated with. dont count with me on that.
Of course, nobody would be getting rich by this development, but in end, everybody could have had what wasn't possible before , a renovated Os, a renovated hardware, new software. Sounds like a win-win situation to me.
in contrary to you os4 team has not very good track report of delivering what has been promissed.
Yes, it is. Look, if OpenSource should be it, then please do that. No problem either.
But again, then it should be *really* OpenSource. That is, the FPGA should be OpenSource, the interface should not depend on legacy interfaces that are not open. You cannot first negotiate with the owners on licensing the rtg graphics interface, and later on work around this negotiations and ignore the owners and forget the negotiations just because it now suddenly fits better to the plan to do so.
seriously, i dont care. im working on aros which is open source. whether the hardware is open source is another matter as i really am not associated with it. so far i really only sypmathize with it. what everybody else does is not my affair.
-
Honest question here - not trying to be snarky or incite a flame war: do people honestly believe that potential Vampire 2 owners are more interested in running AROS on their Amigas than 3.x?
I've tinkered with AROS (68k and x86) out of curiosity and I commend the devs for their dedication to the OS and the countless hours they've invested in making it *but* from my perspective the user-base seems tiny even in comparison to OS4 and MorphOS - having used it, I can't think of a single reason to run it on a classic Amiga - even one accelerated by a Vampire.
I can't help but think that those in the Amiga community that don't consider either AmigaOS 4.1 or MorphOS as 'true' Amiga successors would feel exactly the same way about Vampire/AROS. If and when I do buy a Vampire, It'll be to run 3.9 - and if Cloanto, Hyperion or whoever wants to restart development on AmigaOS 3.x then I'd be more than happy to pay for that.
-
I can't think of a single reason to run it on a classic Amiga - even one accelerated by a Vampire.
so what do you need an updated os on 68k? aros has smaller foorprint than os4. difficult to judge if its slower or faster. its likely more buggy on68k, as most devs are on the x86 side. its has potentially more functionality. and it has developers interested in vampire as it occures. very skilled ones. the question is for how long.
I can't help but think that those in the Amiga community that don't consider either AmigaOS 4.1 or MorphOS as 'true' Amiga successors would feel exactly the same way about Vampire/AROS. If and when I do buy a Vampire, It'll be to run 3.9 - and if Cloanto, Hyperion or whoever wants to restart development on AmigaOS 3.x then I'd be more than happy to pay for that.
people who think anything that comes from hyperion is the only legitimate are lost no matter what. others will simply use their rom or buy one with cloanto. others may try aros. doesnt matter, as long as it runs amiga software if you ask me.
-
Are you suggesting or are you sarcastic? I *personally* believe it stops making sense at this time. There is a clear indication now, and a clear decision has been made that this is not wanted nor desired.
In the end, nobody trusts Hyperion at this point, given their past decisions. Do I trust them? Honestly - possibly not. The only thing I know is that it cannot work without them, so I personally considered it would be at least worth a try. Unfortunately, as it seems, it neither can work with them.
So here we are.
No, I was not being sarcastic.
Hyperion may suck, but at the end they want money, as much as you or whoever else might possibly be involved. So this is a simple common ground that can be agreed upon all parties. better have some $$$ than nothing :)
There is still a market for AmigaOS 68k, dont let your hurt feelings get in the way.
We, as users dont need to trust on Hyperion, we need to trust on the developers, like you or whoemever they might be (Olsen?) and their resulting efforts. See it this way: Have we trusted Amiga Inc. in the past when they delivered 3.9? Not by any chance, but we trusted the developers, the resulting work, and bought their products (hey, we are even still buying 3.9 cdroms more than a decade after).
So, you felt you got screwed on Picasso96 and the Apollo Team. Get back to the drawing board, something failed, and it is not the first time, just remember Elbox and their Mediators drivers. Maybe you need to change tactics.
There is still money to be made and customers to satisfy, but as good as you probably are as a software engineer, is that you are flawed in some business related things. Dont get your emotions to be the ones that define your business desitions.
Amiga is my hobby, like probably all of us here, and I just want a better experience with it. So if you have something that will enhance my hobby experience, I will still buy your product even if it was backed by Hyperion (which I really dislike).
Think it over
-
We, as users dont need to trust on Hyperion, we need to trust on the developers, like you or whoemever they might be (Olsen?)
...
Meh.... if money goes through Hyperion to the developers, and they don't get paid, development stops.
I'd prefer to see AmigaOS 3.x in other hands. Does Hyperion truly own AmigaOS 3.x with rights to sell?
Then again considering they wanted $10K to license P96 for use with the Vampire I'm sure their asking price would be ridiculous.
-
so what do you need an updated os on 68k?
Well, we don't 'need' an updated OS but sure, I'd be happy to see some of the functionality of OS4 back-ported into 3.x - display stuff would be good (making the the OS more HD and RTG-centric) - basically bringing as much of 68k up to OS4 spec as is feasible.
I'm no programmer, but I'm guessing there's stuff that could be brought across from OS4 to make porting from 3.x to 4.1 and vice versa easier. Perhaps even officially acknowledging UAE as part of the Amiga family and making things like Wazp3D and native code supported out-of-the-box (more integration with the host OS/hardware?).
people who think anything that comes from hyperion is the only legitimate are lost no matter what. others will simply use their rom or buy one with cloanto. others may try aros. doesnt matter, as long as it runs amiga software if you ask me.
There's plenty of users that choose Hyperion/A-Eon's offerings and are happy with them (more or less) - if the rights holders were to look at improving the ageing 68k OS I can't see that as being a bad thing (note: I doubt it'll happen unless Cloanto instigates it).
And of course, you're right - what people choose to run on their hardware is their business and I hope Vampire users are well catered for irrespective of their choice.
-
Honest question here - not trying to be snarky or incite a flame war: do people honestly believe that potential Vampire 2 owners are more interested in running AROS on their Amigas than 3.x?
I've tinkered with AROS (68k and x86) out of curiosity and I commend the devs for their dedication to the OS and the countless hours they've invested in making it *but* from my perspective the user-base seems tiny even in comparison to OS4 and MorphOS - having used it, I can't think of a single reason to run it on a classic Amiga - even one accelerated by a Vampire.
I can't help but think that those in the Amiga community that don't consider either AmigaOS 4.1 or MorphOS as 'true' Amiga successors would feel exactly the same way about Vampire/AROS. If and when I do buy a Vampire, It'll be to run 3.9 - and if Cloanto, Hyperion or whoever wants to restart development on AmigaOS 3.x then I'd be more than happy to pay for that.
Aros is a reimplementation of the 3.1 API including intuition, gadtools and many others.
Upon it you can use not only the limited default desktop but also Scalos and even Magellan (both old one and new one). When using Magellan you can even use MUI 3.8 on it (what I did). It includes additional several patches by default, moving screen out of window, AHI, CybergraphX and so on, there is PCI support and USB-Stack (Poseidon), both on 68k untested but potentially working, network stack and so on. Wawa managed to get MESA/Gallium working on 68k (though slow but who knows what future brings). I do not make judgements about X86 because I am mainly interested in 68k so I cannot say anything. On 68k what did you use? If my distribution then I tried to include as many features as possible, I orientated at Amikit not 3.1. I know that not everyone liked that but because I do not get money for it I try to do what I like. For me my distribution was a testing field what can be done with Aros 68k. For real hardware and FPGA that would be too much of course. I use the old Magellan on it so where is the difference between Aros and 3.1 if you configure it the 3.1 way? But of course it is called competition, Aros is a offer, you can use it or let it.
-
Well, we don't 'need' an updated OS but sure, I'd be happy to see some of the functionality of OS4 back-ported into 3.x - display stuff would be good (making the the OS more HD and RTG-centric) - basically bringing as much of 68k up to OS4 spec as is feasible.
I'm no programmer, but I'm guessing there's stuff that could be brought across from OS4 to make porting from 3.x to 4.1 and vice versa easier. Perhaps even officially acknowledging UAE as part of the Amiga family and making things like Wazp3D and native code supported out-of-the-box (more integration with the host OS/hardware?).
There's plenty of users that choose Hyperion/A-Eon's offerings and are happy with them (more or less) - if the rights holders were to look at improving the ageing 68k OS I can't see that as being a bad thing (note: I doubt it'll happen unless Cloanto instigates it).
And of course, you're right - what people choose to run on their hardware is their business and I hope Vampire users are well catered for irrespective of their choice.
As I understand it you are not interested in buying a Vampire anyway. If yes and you have a 3.1 license you get 3.1, simple as that. But you get it how it is. They will try to support it with drivers like the P96 driver when it is possible legally but thats it. There will be no new 3.1, and expecially no 4.X for 68k how some (you?) seem to fantasize. Hyperion wants to sell 4.X on real PPC hardware, even the many emulation customers are officially not supported. All that "they will backport 4.X to 68k" are wet dreams distant from any reality. What you might have got (at best) a slightly improved 3.1. Regarding Thomas, I never claimed that the sources do not exist anymore but there is no chance for people outside Hyperion to access or change them. What if Hyperion really goes bankrupt? OS is not really that unimportant for hardware. Aros offers security and the sources are free accessible, that it is free of charge and no license fees is only one part of the picture and Aros devs are even happy if it is used by people even if they get no money. We will see how the cooperation between Vampire devs and Aros devs will develop, I think both sides will benefit from it.
-
As I understand it you are not interested in buying a Vampire anyway.
Just as soon as they make a CD32 version ;)
There will be no new 3.1, and expecially no 4.X for 68k how some (you?) seem to fantasize. Hyperion wants to sell 4.X on real PPC hardware, even the many emulation customers are officially not supported. All that "they will backport 4.X to 68k" are wet dreams distant from any reality. What you might have got (at best) a slightly improved 3.1.
Hyperion wants to sell products that make money - PPC is simply where they've ended up (unfortunately) - and the copyright scenario has changed drastically since the days of the Pegasos. Now the classic hardware market's getting a shake-up that couldn't have happened until products like the Vampire appeared so opportunities are presenting themselves that weren't viable before due to licensing and commercial viability.
That doesn't mean you're wrong - just that if the rights-holders wanted to exploit OS 3.x to make some money, the chances of creating a product that sells are potentially greater now than they've been in a long time (since the Vampire is the first classic Amiga product to come along that's *vastly* more capable than anything we had before).
Clearly there's some will from Cloanto since they've been making minor updates to 3.x for distribution on disk, ROMs and as part as Amiga Forever. I've already stated I highly doubt any of this will result in an updated 68k OS but perhaps if there's a demand for it (due to a product like the Vampire) then it will (and clearly devs like Thomas are open to the idea and as a user I'd be interested in buying it).
Aros is a reimplementation of the 3.1 API including intuition, gadtools and many others.
Upon it you can use not only the limited default desktop but also Scalos and even Magellan (both old one and new one). When using Magellan you can even use MUI 3.8 on it (what I did). It includes additional several patches by default, moving screen out of window, AHI, CybergraphX and so on, there is PCI support and USB-Stack (Poseidon), both on 68k untested but potentially working, network stack and so on. Wawa managed to get MESA/Gallium working on 68k (though slow but who knows what future brings).
Regarding AROS, I tried the Amiga Forever downloadable and it's impressive - really, really great work. But it's not the AmigaOS I grew up with and began a career as a digital artist using - and it never can be. If there's people out there using it and getting enjoyment out of it then that's wonderful and a testament to your hard work - but it's not something I'd personally choose to use - but that's just me.
-
Just as soon as they make a CD32 version ;)
Hyperion wants to sell products that make money - PPC is simply where they've ended up (unfortunately) - and the copyright scenario has changed drastically since the days of the Pegasos. Now the classic hardware market's getting a shake-up that couldn't have happened until products like the Vampire appeared so opportunities are presenting themselves that weren't viable before due to licensing and commercial viability.
That doesn't mean you're wrong - just that if the rights-holders wanted to exploit OS 3.x to make some money, the chances of creating a product that sells are potentially greater now than they've been in a long time (since the Vampire is the first classic Amiga product to come along that's *vastly* more capable than anything we had before).
Clearly there's some will from Cloanto since they've been making minor updates to 3.x for distribution on disk, ROMs and as part as Amiga Forever. I've already stated I highly doubt any of this will result in an updated 68k OS but perhaps if there's a demand for it (due to a product like the Vampire) then it will (and clearly devs like Thomas are open to the idea and a user like myself would be interested in buying it).
Honestly I do not know how the legal situation around Hyperion and Cloanto really is and if Cloanto has all sources. Obviously they are allowed to do changes for their emulation package, but would they be allowed to sell a signficant changed package for hardware like Vampire?
But the decisions are there, officially the NG OS is Aros but nobody is hindering Cloanto or Hyperion to support Vampire and offer updated packages. They want to make money with it (business opportunities like Thomas called it) but that has to be paid by the customers of Vampire. It is not like 3.5 or 3.9 that could be bought and used but not needed to.
-
Well it's just wishful thinking on my part at the moment but if the Vampire is successful enough then perhaps there's money to be made by supporting it - who knows?
I'm glad the Vampire's going to create more exposure for AROS 68k though :)
-
i dont get the whole drama. there is an accelerator that currently apparently needs an updated rom. but the consumers have acquired a license for legitimate use of that rom long ago with their machines. whatever software the users will use on this hardware is their choice. looks like people start being interested in aros in this context, but it remains to be seen what comes out of this. the os4 license holders wanted to collect money on this occasion but apparently again refused any further support. this is simply their decision and their policy not since yesterday. so the ship has sailed without them. thats all. no butthurt necessary..
-
The simple solution is that Apollo Team make sure the Apollo core and Vampire boards are so compatible that they don't *need* patching exec and kickstarts. It is really that simple! With all the touting about compatibility, the Apollo core should run fine with any kickstart, 1.x onwards. Incidentally, I have a MIST, and it has softcore 68000/010/020 that does run unpatched kickstarts just fine. The apollo team can easily fix this situation themselves, it would even create a bigger market for them. But, whatever :)
-
What about a seemless 68k compability?
Hopefully yes.
-
then why running 3.X on Apollo core or more precise why running anything amiga related at all?
Indeed. What I want with "classic" is to use the programs that pushed the chipset, meaning graphics productivity software like DPaint, Brilliance etc and various music generating software. Once RTG enters the picture, I move to faster options with far more RAM anyways. Besides that, I have an interest in Linux and BSD on m68k.
-
i dont get the whole drama. there is an accelerator that currently apparently needs an updated rom. but the consumers have acquired a license for legitimate use of that rom long ago with their machines.
Only A1200, A4000T and CD32 were ever sold with 3.1 kickstarts, AFAIK.
-
Only A1200, A4000T and CD32 were ever sold with 3.1 kickstarts, AFAIK.
you could get 3.1 kickstarts for whatever amiga. i have my all 4000er upgraded. if the kickstarts bought from amiga dealers are legal, that is.
-
The simple solution is that Apollo Team make sure the Apollo core and Vampire boards are so compatible that they don't *need* patching exec and kickstarts. It is really that simple! With all the touting about compatibility, the Apollo core should run fine with any kickstart, 1.x onwards. Incidentally, I have a MIST, and it has softcore 68000/010/020 that does run unpatched kickstarts just fine. The apollo team can easily fix this situation themselves, it would even create a bigger market for them. But, whatever :)
that might be en course, thanks jason again, autoconfig and the like..
-
you could get 3.1 kickstarts for whatever amiga. i have my all 4000er upgraded. if the kickstarts bought from amiga dealers are legal, that is.
Of course, me too, but many never did.
-
that might be en course, thanks jason again, autoconfig and the like..
If that is so, good.
Another obvious limitation is of course the current production line, which from what I understand is kipper2k and his soldering iron.
-
Wow quite the discussion thread! Nice to see the Vampire stirring up some lively discussion.
Here is my take on the situation...
It appears to me that the OS4/PPC vs OS3/68K situation resembles Microsoft's old stance on their software. Windows/PCs only. Only software for Windows. Android and OSX/iOS can go suck rocks. However recently Microsoft has changed their ways realizing there is a bigger market out there than just Windows and PCs. Look at all the work they are now doing with software support for all platforms. It is quite a change to behold. Larger user base = more revenue going forward. Windows or not.
I suggest the PPC hardware may be the equivalent to the "Windows only" mentality.
The clincher here will be users. Hardware shipped. If a lot of Vampires (and MIST and whatever else comes along) get out into the world and a large enough user base is built it starts to become a more attractive platform to the OS3/OS4 owners. Possibly even MorphOS.
At what point does it become attractive? Who knows. But the key to anything really happening on the OS front is shipping hardware. Shipping hardware in volume. VOLUME. Get an installed base of at least a couple thousand users. That will start to show the possible market size.
Until we see volumes of hardware with a mature "gold" core all this thrashing on the operating system front is just that. I can understand Hyperion's resistance at the moment. So many projects go nowhere. This Apollo system has a chance to do well but installed hardware will do all the talking.
-
If that is so, good.
Another obvious limitation is of course the current production line, which from what I understand is kipper2k and his soldering iron.
omg.. what is wrong again??? will you ever run out of complaints? everybody is working here as much he can, but obviously it will never be satisfactory..
-
I can understand Hyperion's resistance at the moment. So many projects go nowhere.
afair its mostly their projects that go nowhere. instead, community based projects tend to succeed. and im a bit confused about what could they offer us under these circumstances.
-
afair its mostly their projects that go nowhere. instead, community based projects tend to succeed. and im a bit confused about what could they offer us under these circumstances.
I should have said "Hardware projects". Why are you a bit confused?
-
omg.. what is wrong again??? will you ever run out of complaints?
I would love to :)
-
I should have said "Hardware projects". Why are you a bit confused?
i see a number of community based hardware projects actually fluorish. mist, fpgaarcade, vampire, a number of projects by strim like the sonnetppc for mediator or 030-decellerator just to name few. okay, there are few projects that were actually obvious to fail like ultimate ppc or tina. but what does any of that has to do with hyperions constant denial of amiga as 68k platform and their habit not to deliver even what they have promissed?
-
i see a number of community based hardware projects actually fluorish. mist, fpgaarcade, vampire, a number of projects by strim like the sonnetppc for mediator or 030-decellerator just to name few. okay, there are few projects that were actually obvious to fail like ultimate ppc or tina. but what does any of that has to do with hyperions constant denial of amiga as 68k platform and their habit not to deliver even what they have promissed?
In Hyperion's case they may never decide to go with updated 68K development. And that's fine and their right. However in the long run I am trying to suggest that supporting a bigger ecosystem of 68K and PPC users is more beneficial to their company in the long run. This taking into consideration that PPC is running out of steam and the Apollo (and other 68k) cores are coming on strong. Maybe sub-licensing would work? Who knows.
But again, until any hardware is shipping in volume it isn't worth the hassle. A large user base opens up options for bounties and such.
Then again AROS may grow up enough to make any further debate pointless.
It will be interesting to watch how things play out this year.
Cheers!
-
In Hyperion's case they may never decide to go with updated 68K development. And that's fine and their right. However in the long run I am trying to suggest that supporting a bigger ecosystem of 68K and PPC users is more beneficial to their company in the long run. This taking into consideration that PPC is running out of steam and the Apollo (and other 68k) cores are coming on strong. Maybe sub-licensing would work? Who knows.
But again, until any hardware is shipping in volume it isn't worth the hassle. A large user base opens up options for bounties and such.
Then again AROS may grow up enough to make any further debate pointless.
It will be interesting to watch how things play out this year.
Cheers!
Yes I agree, if they can get (cheap) Vampire boards out to enough users then it might be just the kick up the bum that AROS 68k needs to become a viable alternative to OS3.x
-
Actually I have an overseas, lol, China contact that has or is making boards for many companies I've worked for and more. Good quality. If so inspired let me know I will give you contact info.
Chris
PS: He's darn cheap
-
Honest question here - not trying to be snarky or incite a flame war: do people honestly believe that potential Vampire 2 owners are more interested in running AROS on their Amigas than 3.x?
This, indeed, is the big question, and for me the final question that needs to be answered before I'm going to invest any more time into this affair.
All I can say is the following: Whenever I mention "closed source commercial software" in this forum, I get an uproar as if this would be something morally wrong, undesired. Unfortunately, "closed source commerical software" is the only option for AmigaOs, due to the contracts of Hyperion with Amiga, Inc, and Hyperion is the only option as far as advancing the classic Os is. Yes, Cloanto has a license for 3.1, but no license to extend upon it - at least none that withstood an investigation under a court. Hyperion did that. Does that mean that I trust them? No. Does that mean that they are the ideal business partner? No. Yet, only option, bad luck.
So, what can we do?
I believe the community made a decision, or at least Gunnar made a decision for the community. The signal is quite clear "Avoid AmigaOs classic, go AROS, ditch Hyperion.". Why? Because the unwillingness to pay for the closed source licenses that go with the closed source development model. And, that in the end, pay development hours. Unfortunately, that's what the legal situation is with AmigaOs classic, and there are no means to fix it.
Then, so might it be. Everybody should know what the decision is, and everybody should be aware of the consequences, good or bad. For me it means that the history of AmigaOs stops right at this point.
-
This, indeed, is the big question, and for me the final question that needs to be answered before I'm going to invest any more time into this affair.
All I can say is the following: Whenever I mention "closed source commercial software" in this forum, I get an uproar as if this would be something morally wrong, undesired. Unfortunately, "closed source commerical software" is the only option for AmigaOs, due to the contracts of Hyperion with Amiga, Inc, and Hyperion is the only option as far as advancing the classic Os is. Yes, Cloanto has a license for 3.1, but no license to extend upon it - at least none that withstood an investigation under a court. Hyperion did that. Does that mean that I trust them? No. Does that mean that they are the ideal business partner? No. Yet, only option, bad luck.
So, what can we do?
I believe the community made a decision, or at least Gunnar made a decision for the community. The signal is quite clear "Avoid AmigaOs classic, go AROS, ditch Hyperion.". Why? Because the unwillingness to pay for the closed source licenses that go with the closed source development model. And, that in the end, pay development hours. Unfortunately, that's what the legal situation is with AmigaOs classic, and there are no means to fix it.
Then, so might it be. Everybody should know what the decision is, and everybody should be aware of the consequences, good or bad. For me it means that the history of AmigaOs stops right at this point.
Only short question back... would you base your whole business model and 7 years of work on Hyperion except they would give you really free and independent access so you are not dependant on the financial, legal situation at Hyperion or decisions done there. I understand that you are legal bound to Hyperion but then admit that and do not all the time claim that you are only talking in the interests of the community. It starts to nerve. Also you would have one of the few candidates doing the adaptions and certainly not without asking for "meals" like you call it. Would have been interesting to hear how big these "meals" would have been.
I have named a number of reasons why the decision was pro Aros. There is also the interview with Gunnar where he explained the project and also talked about Aros. The decisions are rational and result of the negotiations he had, what was requested and offered. Simply as that. Be adult and accept it even if you do not like it. I would not have flooded the threads with moanings when decision would have been pro 3.X
-
The whole AROS VS AOS discussion (and why I initially made a thread about it), was cause BigGun appeared to prefer to use AOS for the Vampire. But there are too much uncertainty attached to it (legal and cost), espesially considering he plans to expand Vampire capabilities beyond what AOS currently supports.
I have no problem understanding that it might be hard for Apollo-Team to risk paying a large slump of money, and HOPE they would be able to recoupe that money thru sales. Yes, the intrest on forums indicates there are alot of intrest, but that doesnt automatically translates into sales.
That said, I think Im not the only one that would purchase new versions of AOS 3.x, and Im not against closed source by default (then again, im not a hardware/software developer, just a "end user")
Since there are none beyond 3.9, many of us install the Boing Bag patches.
And again, I got a feeling that a fair share will stick to AOS on their Vampires, regardless of Apollo-Teams choice, whatever it may be.
-
Only short question back... would you base your whole business model and 7 years of work on Hyperion except they would give you really free and independent access so you are not dependant on the financial, legal situation at Hyperion or decisions done there.
I would look at the market and then make my decision based on the options I have, and I would negotiate with Hyperion to get an access to the sources (P96 & AmigaOs) even in case they go bankrupt. Actually, this is all possible and such a clause could have been added to the contracts.
I'm not sure what you mean by "free and independent". They are the license holders of AmigaOs, so all you can get is a license. That's not "free and independent" in my understanding. I neither see why that is necessary for Vampire in first place.
The vampire should be developed such that it runs under an unmodified AmigaOs and P96. This being said, there is of course the opportunity to add hooks to profit from the extra features it has.
I understand that you are legal bound to Hyperion but then admit that and do not all the time claim that you are only talking in the interests of the community.
No, and that's exactly wrong. I *am not* legally bound to Hyperion in any way. We don't have a contract, I never signed an NDA with Hyperion either. I'm speaking for myself, sole and only.
I only see them as only option when it comes to further development of AmigaOs.
It starts to nerve. Also you would have one of the few candidates doing the adaptions and certainly not without asking for "meals" like you call it. Would have been interesting to hear how big these "meals" would have been.
"meals"? Huh? I don't understand.
I have named a number of reasons why the decision was pro Aros. There is also the interview with Gunnar where he explained the project and also talked about Aros. The decisions are rational and result of the negotiations he had, what was requested and offered. Simply as that. Be adult and accept it even if you do not like it. I would not have flooded the threads with moanings when decision would have been pro 3.X
Again, this was not the question here. Look again above. The question is: "Does it make any sense to offer an updated AmigaOs?".
My question in response to that was "Is there enough interest in the community?"
And my observation is: "There has been so much uproar against closed source development that I don't see this makes sense, and that the decision of the vampire against AmigaOs and for AROS sends a clear signal, so I don't bother to waste my time with it".
Do you or don't you agree with that?
-
Whenever I mention "closed source commercial software" in this forum, I get an uproar as if this would be something morally wrong, undesired.
I have no moral issues, I just find it extremely cumbersome and impractical, as has been proven over and over again, and is the reason why we even have this long tedious discussion. The one screaming about moral all the time is ... you.
Unfortunately, "closed source commerical software" is the only option for AmigaOs, due to the contracts of Hyperion with Amiga, Inc, and Hyperion is the only option as far as advancing the classic Os is.
Exactly, extremely cumbersome and impractical. The OS has been pretty much dead exactly because "the owner" wanted it dead, they have even paid large sums of money to keep it dead. However, nature has a tendency to find its ways, the sources are leaked and people all over are making use of those sources.
Yes, Cloanto has a license for 3.1, but no license to extend upon it - at least none that withstood an investigation under a court. Hyperion did that. Does that mean that I trust them? No. Does that mean that they are the ideal business partner? No. Yet, only option, bad luck.
So what is OS3.X that Cloanto is selling, if not an extension on OS3.1?
So, what can we do?
We can do what people have always been doing, whatever the heck we want, with whatever the heck we can get our hands on. Abstract concepts like copyrights, patents and intellectual property were put in place for the benefit of the society. When these concepts are used against the benefit of the society, to keep knowledge and information hostage for no good reason, most people feel that there are no moral reason to adhere to them. I know this is not how you see it, or how you like it to be, but it is still true for a vast majority of people, not just in Amiga community, but in general.
I believe the community made a decision, or at least Gunnar made a decision for the community.
He made a decision for himself, not for the community as large. It's not as if every Amiga user around will get an apollo core, many are not at all interested, and the hardware doesn't exist for most users. I have two A600 systems that do not have Vampire2. Many are happy with Vampire1, and TG68 will improve too.
The signal is quite clear "Avoid AmigaOs classic, go AROS, ditch Hyperion.". Why? Because the unwillingness to pay for the closed source licenses that go with the closed source development model. And, that in the end, pay development hours. Unfortunately, that's what the legal situation is with AmigaOs classic, and there are no means to fix it.
They were not unwilling to pay for closed source license, or they would not have bothered asking for a license. It was the offer from Hyperion that was unreasonable, it would be a major economical gamble to accept Hyperion's offer. The apollo team is not a company, these are people doing things in their spare time, what you call "unwillingness" is merely "being sensible" - good on them! However, it makes the apollo core even less attractive, but hey... that is exactly what the owner of OS3.x want.
Then, so might it be. Everybody should know what the decision is, and everybody should be aware of the consequences, good or bad. For me it means that the history of AmigaOs stops right at this point.
So long and thanks for all the fish. Now take a vacation :)
-
And again, I got a feeling that a fair share will stick to AOS on their Vampires, regardless of Apollo-Teams choice, whatever it may be.
By "breaking the law"? Gasp! You pirates you! :D
-
By "breaking the law"? Gasp! You pirates you! :D
For you, it seems like a joke, but I consider this really a considerable problem.
Essentially, it means that despite the lack of proper licensing, a group (majority? minority?) of vampire users will use the P96 rtg driver on P96 and not AROS. This is a commercial use and a breach of the P96 license.
Hence, I believe at this point the Vampire can only be used on top of AROS. This is what I mean by "go all the way OpenSource then", and "Users might not be aware of the consequences".
Again, if this is good or bad is your personal perspective, but I doubt that such users are aware of these implications.
-
But again, until any hardware is shipping in volume it isn't worth the hassle. A large user base opens up options for bounties and such.
according to kipper vampire2 will be in hands of 250 users soon. this is aan accel for rather unpopular model of amiga. this is within few weeks of initial release. in what volumes are hyperion accustomed os4 hardware to ship? just to mention, there is some 600 users on haperion forum, the talk about sam batches was by 25 if i remember right, the new os4 hardware like x5k or tabor were mentioned to be ordered like in 500-1000 quantities and everybody wondered if thera are customers for that much.
-
For you, it seems like a joke, but I consider this really a considerable problem.
Essentially, it means that despite the lack of proper licensing, a group (majority? minority?) of vampire users will use the P96 rtg driver on P96 and not AROS. This is a commercial use and a breach of the P96 license.
Hence, I believe at this point the Vampire can only be used on top of AROS. This is what I mean by "go all the way OpenSource then", and "Users might not be aware of the consequences".
Again, if this is good or bad is your personal perspective, but I doubt that such users are aware of these implications.
and what if vampire/apollo doesnt (need to) ship with any rom? will there still be a problem because hyperiuon has no argument to demand licenses?
-
No-one is saying that the Vampire will only run AROS, or use AROS ROMs!
It's running Workbench 3.1 right now and has a licensed 3.1 ROM included.
The fact that they're investigating AROS and it's replacement ROM is just that an investigation, a test to see if it's a viable idea.
I would prefer it if the damn thing just map-rommed whatever ROM you've got and work without having to patch the ROM but that's the current situation not necessarily always going to be the case.
ThomasRichter you are spreading so much FUD about all of this. They (Apollo) do NOT depend on any OpenSource software or hardware in the current Vampire 2 boards for A600.
They do not have to OpenSource the core or board designs unless they desire doing so, they might be making money from these Vampire boards but you don't seem to mind when companies do that so what is your problem with them doing that? (if they are)
It's weird you argue about paying licenses for things that don't need a license because someone "deserves" money, but after 7 years of hard work by a team developing these accelerators and their hardware/FPGA design you then say that they should have to OpenSource it all for no benefit to them.
You are annoyingly inconsistent in this thread depending on who you're discussing.
So, no AROS is not the only way, and Gunnar is not forcing it on anyone, he's impressed by it but nothing more.
OS 3.1 does run on it, people have shown plenty of videos of it doing just that.
It's not 100% final, even their "Silver" core is still in testing and it's the "Gold" core (all of which will be free updates) that will have most of the bugs fixed. The current release is more like an "alpha" quality build with all features implemented but still with bugs.
All this arguing is doing is wasting a lot of time and typing on the internet.
-
"Users might not be aware of the consequences".
Again, if this is good or bad is your personal perspective, but I doubt that such users are aware of these implications.
What are the implications? Being yelled at on random web boards by you? That is really all the "implications" I can imagine happen.
-
It's running Workbench 3.1 right now and has a licensed 3.1 ROM included.
Really? Licensed by whom? If I was to buy a Vampire at some point, I would want to use my own kickstart. Is this possible too?
-
Really? Licensed by whom? If I was to buy a Vampire at some point, I would want to use my own kickstart. Is this possible too?
That is exactly what licensed here mean
people proof that they own a 3.1. license and use it
-
ThomasRichter you are spreading so much FUD about all of this. They (Apollo) do NOT depend on any OpenSource software or hardware in the current Vampire 2 boards for A600.
Yes, it does. P96 support for a commercial platform requires a license. Is the P96 driver licensed? No, it's not.
It's weird you argue about paying licenses for things that don't need a license because someone "deserves" money, but after 7 years of hard work by a team developing these accelerators and their hardware/FPGA design you then say that they should have to OpenSource it all for no benefit to them.
Oh, wait, and P96 is "just there" and "nobody developed it", and "nobody deserves money for it"? I'm not demanding money for my pocket, remember? I'm asking for money for the original developers that also spend a lot of time - probably more than 7 years - to develop it.
You're saying this is worth nothing, and the work can just be taken?
For Apollo, yes of course you can ship this as commercial product, that's all fine and valid. But please, then also share parts of the income to the people that make this product possible (namely, Vampire on AmigaOs, to be precise!), and that are *also* software developers that build the original software stack.
Otherwise, if you believe that your product should depend on open source only, I believe it's only fair to ask to make it open source, too. Hence, open take - open give.
It's really quite simple.
All this arguing is doing is wasting a lot of time and typing on the internet.
Apparently, you don't understand a thing here. It's about honesty and ethnics. If my product depends on somebody else's product to enable its full functionality, and this other product requires licensing, I need to get this license. And no, I don't attempt to simply work around that, I tackle the problem honestly.
If I don't want to pay for the license for P96, I cannot simply provide the P96 driver for AmigaOs. For AROS, the situation might be different because AROS does not use P96, but for AmigaOs, it does.
Try to understand the situation for just a moment from the perspective of the P96 developers, please.
-
Oh, wait, and P96 is "just there" and "nobody developed it", and "nobody deserves money for it"? I'm not demanding money for my pocket, remember? I'm asking for money for the original developers that also spend a lot of time - probably more than 7 years - to develop it.
They got money back in the days for that. And "recently" again with OS4...
Be positive Thomas, you're always defending the indefensible...
-
That is exactly what licensed here mean
people proof that they own a 3.1. license and use it
So it is not included - I get conflicting information here :D
-
Yes, it does. P96 support for a commercial platform requires a license. Is the P96 driver licensed? No, it's not.
And what about people like me who do not even want to use RTG with Vampire2? Should we still be paying the added cost that a "legal" P96 would imply?
-
And what about people like me who do not even want to use RTG with Vampire2? Should we still be paying the added cost that a "legal" P96 would imply?
Depends on the solution Apollo Team decides for.
And I guess thats one of the reasons why they are looking hard at AROS, cause it removes all the headaches of "if, but, maybe" scenarios, and deals with open source only.
Again; I have sympathy with developers getting paid, but the Amiga legal situation have so many twists and turns, plus parties that doesnt really communicate.
Add 10 000 dollars to that equation, and it muddies the water real quick.
No wonder BigGun is just shrugging, and gleaning towards AROS (even tho he indicates he would prefere AOS).
-
and what if vampire/apollo doesnt (need to) ship with any rom? will there still be a problem because hyperiuon has no argument to demand licenses?
I suspect that once the core is finalised it'll just use whatever ROM you have installed like any other accelerator does. Perhaps patching it on the fly and running it from its onboard RAM.
Jason has written a driver for the RTG board that anyone is free to use with the P96 that they already paid for. There is no law in any country that I'm aware of that prevents Jason from writing this driver and distributing it freely for anyone to do with as they see fit.
I challenge anyone to take this to court and see how far they get.
-
I suspect that once the core is finalised it'll just use whatever ROM you have installed like any other accelerator does. Perhaps patching it on the fly and running it from its onboard RAM.
Jason has written a driver for the RTG board that anyone is free to use with the P96 that they already paid for. There is no law in any country that I'm aware of that prevents Jason from writing this driver and distributing it freely for anyone to do with as they see fit.
I challenge anyone to take this to court and see how far they get.
it is basically the same as on real amigas... the aros roms are installed from CF when booting starts or they are preinstalled. Both is possible
-
So it is not included - I get conflicting information here :D
I HAVE no conflict :roflmao:
no there are not different informations
official if you order and do not own 3.1 license yet you would get Aros roms
if you proof that you own 3.1 license you get 3.1
in first case you can use aros or whatever boots with the rom replacements. Who knows what future will bring there...
in second both because aros roms are loaded from CF
-
So it is not included - I get conflicting information here :D
Kipper2k's page indicates they have purchased some Kickstart 3.1 licenses and will include them on all future orders.
-
I challenge anyone to take this to court and see how far they get.
Exactly.
-
if you proof that you own 3.1 license you get 3.1
How is one supposed to prove this? Send photos of the motherboards with something that looks like genuine 3.1 kickstart ROMs on them?
(btw - it is "to prove" and "a proof")
-
How is one supposed to prove this? Send photos of the motherboards with something that looks like genuine 3.1 kickstart ROMs on them?
(btw - it is "to prove" and "a proof")
thanx... as i understand it you have to read it out and upload it. But better to ask kipper there directly about the details
I am personal not interested in that anyway
from someone already done it:
http://eab.abime.net/showthread.php?t=81535&page=9
You grab an image of your Amiga ROM (along with a checksum) with a utility you can download on Aminet.
You then upload to Kippers FTP server where it get validated.
Just for the record, I did this a while ago and it seems my image is in the "valid" folder.
-
Yes, it does. P96 support for a commercial platform requires a license. Is the P96 driver licensed? No, it's not.
Oh, wait, and P96 is "just there" and "nobody developed it", and "nobody deserves money for it"? I'm not demanding money for my pocket, remember? I'm asking for money for the original developers that also spend a lot of time - probably more than 7 years - to develop it.
You're saying this is worth nothing, and the work can just be taken?
The important part is that P96 is optional, the driver is a separate download, it does not *come-with* the Vampire so it does not require a license.
You can argue that someone who does download it, and does use it with AOS3.1, and does use all of the free (from the developers) tools might want to give them something but as Nicholas pointed out, and as we discussed earlier there's no actual license required here.
It's reverse engineered interface, you dislike that, but that doesn't change it's legality, it is legal.
Apparently, you don't understand a thing here. It's about honesty and ethnics. If my product depends on somebody else's product to enable its full functionality, and this other product requires licensing, I need to get this license. And no, I don't attempt to simply work around that, I tackle the problem honestly.
If I don't want to pay for the license for P96, I cannot simply provide the P96 driver for AmigaOs. For AROS, the situation might be different because AROS does not use P96, but for AmigaOs, it does.
Try to understand the situation for just a moment from the perspective of the P96 developers, please.
I am a software developer, I've seen every game that I've ever worked on pirated.
I understand that frustration, but here we're talking about very different things.
All computer hardware depends on other peoples products to "enable its full functionality" to varying degrees. In this case you could use something other than P96 but that doesn't seem necessary.
Your argument here is still spurious, reverse engineering is legal, if they had used the Picasso SDK to develop it then they would have required a license. However they used a reverse engineered interface and so they do not.
If it was easy (or even possible) to contact the original P96 developers, to get that SDK at all, to negotiate with them then maybe that would be a viable route but the case here is that it isn't necessary or legally required.
Why we're having to dispute it is bizarre, we're talking about long established legal facts with every precedent imaginable going for it that is widely done on a daily basis.
The driver can be written without violating the license, and it has been. The tools themselves are freely available from AmiNet. That's both end of the puzzle, the legal tools, the legal driver for it.
-
Yes, it does. P96 support for a commercial platform requires a license. Is the P96 driver licensed? No, it's not.
...
Try to understand the situation for just a moment from the perspective of the P96 developers, please.
please be clear.
are you talking on behalf of p96 developers? have they entiteled you to defend their rights in public? have they in person informed you that gunnar is acting illegally.
or are you just depending on statements from someone from hyperion and actually arguing on their behalf? if the latter is the case, you might actually not know the whole truth, since the source you would be relaying on has proven not to be completely trustworthy.
i as kagain. why do you take issue with gunnar, but dont bother with anybody else developing third party drivers or depending on such without actual p96 license. i mean a number of a1k projects (at least three come to mind), elbox drivers, fpgaarcade and mist and so on..
-
And I guess thats one of the reasons why they are looking hard at AROS, cause it removes all the headaches of "if, but, maybe" scenarios, and deals with open source only.
Indeed it does. P96 licences should likely not apply here since AROS comes with its own implementation. Kickstart licenses do not apply because AROS is not dependent on AmigaOs either.
So in a sense, this works. The big question really is whether users have really understood this consequence and are also willing to follow the road towards AROS.
This is precisely why I'm asking so many stupid questions whether there is interest in AmigaOs or not. Because if there is, you'll run into trouble with the lack of proper licensing with the Vampire. So in a sense, you need to decide: Vampire with AROS, or AmigaOs without the Vampire.
I personally consider this a very hard decision to make.
-
thanx... as i understand it you have to read it out and upload it. But better to ask kipper there directly about the details
Yep, you have to prove that you have a legal ROM image. It's so they can give you "back" a modified version.
I don't understand the reasoning or why they didn't just make it work with any existing 3.1 ROM but then I'm not the one developing the hardware :)
-
So in a sense, you need to decide: Vampire with AROS, or AmigaOs without the Vampire.
But this is false, even if (and most ppl argue it isn't) the P96 driver is a problem you can still use Vampire with AmigaOS just fine, just in that case without P96. It might need something else or maybe the AROS version needs porting to AmigaOS.
Either way everyone's points still stand that you seem to be arguing against something that the developers (P96) themselves don't have a case for.
-
Indeed it does. P96 licences should likely not apply here since AROS comes with its own implementation. Kickstart licenses do not apply because AROS is not dependent on AmigaOs either.
So in a sense, this works. The big question really is whether users have really understood this consequence and are also willing to follow the road towards AROS.
This is precisely why I'm asking so many stupid questions whether there is interest in AmigaOs or not. Because if there is, you'll run into trouble with the lack of proper licensing with the Vampire. So in a sense, you need to decide: Vampire with AROS, or AmigaOs without the Vampire.
I personally consider this a very hard decision to make.
Neither 3.1 nor P96 are preinstalled. The only thing preinstalled is 3.1 kickstart if customer proves that he owns a license already. P96 driver is based on WinUAE implementation and also seperat. The user has to download it when he wants to use and he has to install both 3.1 and P96 on its own. There is no preinstalled configuration with 3.1 and P96. The driver is for Aros and only "accidently" working with P96 like "4.X classic" accidently works with UAE
-
please be clear.
are you talking on behalf of p96 developers? have they entiteled you to defend their rights in public? have they in person informed you that gunnar is acting illegally.
or are you just depending on statements from someone from hyperion and actually arguing on their behalf? if the latter is the case, you might actually not know the whole truth, since the source you would be relaying on has proven not to be completely trustworthy.
Neither - nor. Again, I'm not under NDA from Hyperion, we have no contract. Neither am I under NDA from T&A, nor do I have a contract in this direction. Nobody is paying me, and these are all my sole and only personal opinions.
Call this my personal view on the affairs as an developer who helped once in P96 development, and a developer who saw the demise of P96 due to a dishonest company (Elbox, namely) simply using P96 for their commercial products. I also see that this history just repeats.
i as kagain. why do you take issue with gunnar, but dont bother with anybody else developing third party drivers or depending on such without actual p96 license.
Don't worry, I've made my points more than clear with Gunnar already.
i mean a number of a1k projects (at least three come to mind), elbox drivers, fpgaarcade and mist and so on..
Indeed, same problems all again.
If you ask me where to make the cut (personal opinion): As long as I have a hobby project, and develop a driver for a low-volume series for a couple of friends in a non-profit way, I'll believe I as a developer would be fine. No harm done.
As soon, however, as I sell a product for a commercial interest, I personally see problems. Elbox is such a candidate for sure. They sold products to end-users, including drivers, hence created products for money that clearly depended on third party work, yet didn't want to pay for this third party work.
About the two other products I do not know enough to state a clear position.
-
It's not developed because everybody here tells me "go away, we have no interest in it".
Nobody said that. If you want and can develop OS3.1 further, it would sure be of interest to many people. But why does this depend on the kickstart decision done by the apollo team?
I have seen discussions about morals but nonetheless I wonder what really makes you so angry as to repeat the same points all the time that were already proven to be moot several times.
Again, I've no problem if people prefer AROS - that's a choice everybody can make
And all hardware manufacturers can make their own decisions about which kickstart to include, none, a licensed 3.1 or a free AROS kickstart.
they would be most certainly be used if there would be interest in a - albeit closed source, paid - development.
What would the economical and legal model be for such paid development? So far I have gathered that somebody outside Hyperion would do it. I conclude that this would involve money going from Hyperion to the developer. For the developer the motivation would be clear. For Hyperion the hope would be that money finds its way to them. Where would that money come from and at what point in time?
There's a new interesting product on the market that triggers interest in users investing into the classics.
The new product triggers a lot of interest. Interests that the creators of the product may not share. E.g. people approached BigGun advising him to stop cooperating with Igor and Brian and instead work with somebody more professional. People come and create FPGA accelerator boards nobody had asked them for hoping that the apollo core might become available to them. People come and want to create (and lead?) a committee that decides on the extensions to the 68k ISA. People come and want to bundle an OS yet to be created with the vampire.
What the f***?!?
Of course that also means that now the owner of the Os sees some interest in investing into the classics.
They explicitly said that they had NO interest at all in the classics. They only have interest in PPC. They said that they would use any money they get from the apollo team for their PPC business. Gunnar offered them 10,000€ for the rights to develop 3.1 further but they were not willing to grant any rights or give guaranties about the status of the outcome of this development. There simply was no basis for an agreement nor even preliminary negotiations.
Of course, nobody would be getting rich by this development, but in end, everybody could have had what wasn't possible before , a renovated Os, a renovated hardware, new software.
The problem with this is that we came to the conclusion that a renovated OS seems to be more likely to happen based on AROS than on OS3.1. We'd appreciate either, though.
You cannot first negotiate with the owners on licensing the rtg graphics interface, and later on work around this negotiations and ignore the owners and forget the negotiations just because it now suddenly fits better to the plan to do so.
Well, as a matter of fact you can. If you go to a car dealer and start negotiating with him, you are still free to leave the shop without a new car...
The funny thing is that it isn't even clear who the owners of the RTG interface actually are today. Hey, psst, I sell licenses to walking on the precinct in front of your house! They are cheap but the price will double tomorrow! :roflmao:
I *personally* believe [closed-source OS3.1 development] stops making sense at this time. There is a clear indication now, and a clear decision has been made that this is not wanted nor desired.
Clear indication by whom? OS 3.5 and 3.9 have been sold. I have no idea whether actual money was gained that justified the investment but this isn't changed by the fact that the vampire will be shipped including an AROS kickstart rom. After all the AROS rom does not exclude OS 3.5 and 3.9 from running AFAIK. And if it does, it can and should be changed to be more compatible.
The only thing I know is that it cannot work without them, so I personally considered it would be at least worth a try. Unfortunately, as it seems, it neither can work with them.
Again, why would future development of OS3.1 depend on the vampire?
Honest question here - not trying to be snarky or incite a flame war: do people honestly believe that potential Vampire 2 owners are more interested in running AROS on their Amigas than 3.x?
I think that most people are interested in being able to run both. It will most probably be possible to flash user kickstarts alongside the AROS kickstart and select the rom to be used from an early startup menu. But that needs some work and has relatively low priority.
I've tinkered with AROS (68k and x86) out of curiosity and I commend the devs for their dedication to the OS and the countless hours they've invested in making it *but* from my perspective the user-base seems tiny even in comparison to OS4 and MorphOS - having used it, I can't think of a single reason to run it on a classic Amiga - even one accelerated by a Vampire.
You must not mix up AROS and the AROS kickstart. While we also believe that AROS is an interesting opportunity, all this discussion is mostly about the kickstart to ship with the vampire.
All I can say is the following: Whenever I mention "closed source commercial software" in this forum, I get an uproar as if this would be something morally wrong, undesired.
That may be your personal perception. Or you oversimplify other peoples' statements.
Unfortunately, "closed source commerical software" is the only option for AmigaOs, due to the contracts of Hyperion with Amiga, Inc, and Hyperion is the only option as far as advancing the classic Os is. Yes, Cloanto has a license for 3.1, but no license to extend upon it
Has anybody seen any of those license contracts (except for some judges)? It's clear that a licensee empowered to sublicense may not grant more rights than he himself enjoys but I wouldn't sign a contract with any party anyway without actually seeing proof of their rights. In this case the proof would have to be a gapless chain of contracts reaching back to Commodore.
I believe the community made a decision, or at least Gunnar made a decision for the community. The signal is quite clear "Avoid AmigaOs classic, go AROS, ditch Hyperion."
That may be his preference. But who do you believe him to be that you think he could make such a decision for "the community"?
Why? Because the unwillingness to pay for the closed source licenses that go with the closed source development model. And, that in the end, pay development hours.
So your grudge is that Gunnar decided to not pay the bill for closed-source development of OS3.1?
Unfortunately, that's what the legal situation is with AmigaOs classic, and there are no means to fix it.
We could wait until Hyperion finally bites the dust and buy the relevant rights out of the bankruptcy assets. We might even be able to open-source it at last.
-
The vampire should be developed such that it runs under an unmodified AmigaOs and P96. This being said, there is of course the opportunity to add hooks to profit from the extra features it has.
Then Hyperion can go about and develop and sell an OS3.10 that supports the apollo's 64 bit mode. We are not going to stop them.
And my observation is: "There has been so much uproar against closed source development that I don't see this makes sense, and that the decision of the vampire against AmigaOs and for AROS sends a clear signal, so I don't bother to waste my time with it".
Do you or don't you agree with that?
I can only answer for myself: I legally own OS 3.1 and I never considered nor will I consider buying OS 3.5 or 3.9. It would have to be a really attractive update in order to make be buy that closed-source 3.10.
Essentially, it means that despite the lack of proper licensing, a group (majority? minority?) of vampire users will use the P96 rtg driver on P96 and not AROS. This is a commercial use and a breach of the P96 license.
It is not. I have explained this several times and will not repeat it. If you don't stop this, I might create a textblock to copy'n'paste each time you bring this up...
What's so ridiculous about your ostentatious indignation is this: the authors of Picasso told Gunnar to just go use picasso and in case some serious money is made from it, they could talk again.
That's how much they care. So all your comments about this issue merely serve to show how much you care.
Really? Licensed by whom? If I was to buy a Vampire at some point, I would want to use my own kickstart. Is this possible too?
In fact it is. You will be able to get a vampire with an AROS kickstart. You will also be able to have your personal copy of kick 3.1 patched and flashed to the vampire for you. Eventually you will be able to flash any kickstart you want alongside the AROS kickstart. You can also order a vampire from kipper2k and buy a license for the kick 3.1 if you haven't got it already. Brian bought a bunch of 3.1 rom licenses weeks if not months ago.
I still don't get what all the uproar is about.
I'm asking for money for the original developers that also spend a lot of time - probably more than 7 years - to develop it.
Are you sure you are asking the money for them? They themselves didn't seem to be as interested in it as you are.
But please, then also share parts of the income to the people that make this product possible (namely, Vampire on AmigaOs, to be precise!), and that are *also* software developers that build the original software stack.
OK. But first explain again why that money would have to go through Hyperion in order to reach the picasso authors. I think you mentioned that it was too much hassle for them to accept money personally?
Apparently, you don't understand a thing here. It's about honesty and ethnics.
Sorry, but I just haven't got enough trust in me to still believe it's about ethics.
If I don't want to pay for the license for P96, I cannot simply provide the P96 driver for AmigaOs.
Yes, I can if I wrote it without using copyrighted IP which is the case with the apollo RTG driver written by Jason McMullan.
Since you are so much about honesty, why should I license a product that uses the cybergraphics API without a license? Wouldn't that make me infringe the cybergraphics rights?
Try to understand the situation for just a moment from the perspective of the P96 developers, please.
We do. It looks like you don't. If any money will go from apollo/vampire to the picasso authors, it will be by direct payment.
-
Thomas I thought I should make clear that I'm not against you here, just arguing against you conflating unrelated things namely AmigaOS+Vampire+P96.
These are 3 separate items.
You can buy the Vampie2 for your A600 and use it with AmigaOS or AROS perfectly legally - the totally separate, optional, download of the P96 driver has no bearing on that.
If you want too then you can download the shareware (http://aminet.net/package/driver/video/Picasso96) Picasso96 from AmiNet and use that with the driver.
The driver is an open source, clean room, implementation using reversed engineered headers and so is legal in much the way that AMD cloned x86, or Apollo/TG86k/etc replicates the 680x0 ISA.
The only thing that would need paying for is Picasso96 from AmiNet as it's Shareware and the requested amount is $20... if anyone knows how to pay, or indeed how to contact someone in order too pay them, then that's the only part that needs any money to exchange hands.
I'd be happy to pay that, if there's a way to do so. Paypal? To whom?
-
Neither - nor. Again, I'm not under NDA from Hyperion, we have no contract. Neither am I under NDA from T&A, nor do I have a contract in this direction. Nobody is paying me, and these are all my sole and only personal opinions.
We have understood your personal opinions. We have explained our opinion. I guess it's pointless to continue the discussion about this subject.
Call this my personal view on the affairs as an developer who helped once in P96 development,
I didn't know you were involved in P96 development.
and a developer who saw the demise of P96 due to a dishonest company (Elbox, namely) simply using P96 for their commercial products. I also see that this history just repeats.
What's to be learned from this? Don't be cheap and save the money for legal advise. The picasso license model just doesn't work legally.
-
The important part is that P96 is optional, the driver is a separate download, it does not *come-with* the Vampire so it does not require a license.
You can argue that someone who does download it, and does use it with AOS3.1, and does use all of the free (from the developers) tools might want to give them something but as Nicholas pointed out, and as we discussed earlier there's no actual license required here.
As a matter of fact, the picasso software available for download from aminet was published by the picasso authors as shareware. Clearly hardware manufacturers may either pay a license fee and include the software with their product or may leave it to their customer to collect the software themselves and pay the shareware fee.
EDIT: I just saw you mentioned the shareware issue in another posting. Anyway, as this cannot be pointed out often enough, I just leave this here...
-
I'm not under NDA from Hyperion, we have no contract. Neither am I under NDA from T&A, nor do I have a contract in this direction. Nobody is paying me
BTW, why aren't you taking part in the effort to make AROS a worthy replacement of AOS3.1?
-
I can only answer for myself: I legally own OS 3.1 and I never considered nor will I consider buying OS 3.5 or 3.9. It would have to be a really attractive update in order to make be buy that closed-source 3.10.
With the given resources, I doubt anyone can create something "really attractive". What I had in mind was mostly a really cleaned up version with some improvements here and there. It never got far enough to give you a price point.
What's so ridiculous about your ostentatious indignation is this: the authors of Picasso told Gunnar to just go use picasso and in case some serious money is made from it, they could talk again.
Correct. Which happens at this point. It is sold to end users and now a commercial product. It has left the hobby-project development route.
That's how much they care. So all your comments about this issue merely serve to show how much you care.
Which I understand. If you run the hardware as a hobby project on a non-profit basis, this is one thing. If you sell the hardware, this is another thing.
Are you sure you are asking the money for them? They themselves didn't seem to be as interested in it as you are.
Part of the discussion was that P96 was to be bought completely by Hyerion (they currently only have a license). This money goes from Hyperion to T&A. Where is this money supposed to come from?
OK. But first explain again why that money would have to go through Hyperion in order to reach the picasso authors. I think you mentioned that it was too much hassle for them to accept money personally?
I do not know. They do not seem to be interested in making business with Gunnar directly. I can only speculate why.
Since you are so much about honesty, why should I license a product that uses the cybergraphics API without a license? Wouldn't that make me infringe the cybergraphics rights?
That was what I understood as well. Then Kolla came along, was making again big noise and saying "I must be living under a rock, and everything should be fine with CGfx".
So in the end, all I can say is that I do not know. *If* CGfx requires a development licence, yes, indeed, the problem is right the same. If not, then even better, and just go ahead.
We do. It looks like you don't. If any money will go from apollo/vampire to the picasso authors, it will be by direct payment.
If that would be case, everything would be fine. Maybe the question would arise how to organize then P96 updates, but that's then a secondary question which could be clarified then.
Look, I have little problem excluding Hyperion if T&A are paid directly. I'm not exactly a fan of them either. However, it seems that there is currently no ongoing negotiations between Gunnar and T&A whatsoever. My understanding of the situation is that P96 has been or will be sold in total to Hyperion (by money, of course), in which case T&A would be no longer part of the game because they no longer want to be part of the game. Negotiations are then to be made with Hyperion.
Unfortunately, as long as T&A are the authors and owners of P96, they are part of the story, and you simply cannot ignore license conditions because they don't want to negotiate with you directly. To whom they sell under which conditions is entirely their choice.
The license conditions of P96 do not suddenly disappear. It seemed to me that there were negitations between Hyperion and the P96 authors, so *that* part of the story should have worked, at least. What the outcome of this is I cannot answer because I do not know at present time. It's not my business either.
-
@Thomas
I think many Amiga users are more than willing to pay a decent amount for improved OS, soft/hardware.
Its why we have "harassed" AeonKit about Prisma soundcard. Ofcourse, now they have waited so long that I fear they get stuck with the hardware since "everybody" is using Vampire to play sound since CPU can easily take the load.
Question is ofcourse if Prisma can offload the Vampire freeing it up to get even better performance while multitasking other programs/games.
People bought AOS4.1FE just to emulate it, and from what I understand it sold in relativly good quantities.
Wether or not the "potential" sales due to Vampire is enough for developers to update their software/drivers...Who knows...
But it seems Apollo Team is quite open with information, so if they keep updating us with salesfigures, the potential can be somewhat calculated.
People buying Vampire are of the more active members of this community, and I would expect a share of them are willing to pay a few bucks here and there for new software.
And getting offended by Kolla seems like setting yourself up for constant grief. Hes a loose cannon on deck, shooting at everybody ;) (eg veit du har mykje kunnskap kolla, men du liker å ..diskutere.. franko style :) )
-
With the given resources, I doubt anyone can create something "really attractive". What I had in mind was mostly a really cleaned up version with some improvements here and there. It never got far enough to give you a price point.
So you agree that is nothing that would be worth the 10,000€ Gunnar offered to Hyperion?
Correct. Which happens at this point. It is sold to end users and now a commercial product. It has left the hobby-project development route.
But there is no serious money made. Gunnar&Co haven't earned a single penny. Majsta is still working to deliver the prepaid boards which he offered for a low price and which now are delivered with a much greater (and more expensive) functionality than originally promised. kipper2k builds boards and sells them but has also had to invest in all this. The price point of the vampire is so low that he needs the money from a first batch to buy parts for the next. BTW, he's the guy who also paid for 3.1 licenses.
So what would be a hobby project for you? Should we give away the hardware for free to still qualify?
Part of the discussion was that P96 was to be bought completely by Hyerion (they currently only have a license). This money goes from Hyperion to T&A. Where is this money supposed to come from?
Are you serious? So your idea was that Gunnar buys Hyperion some software they want or need just to be allowed to sell a driver to that same software?
I think Gunnar made a big mistake to show picasso on vampire publically (using your closed-source driver) before there was a final license agreement. This made all this mess with Hyperion and you possible. There suddenly seemed to be an opportunity to put some pressure on Gunnar to go with Hyperion and thus eventually OS3.1. It was mere luck that this problem was solved by the appearance of Jason on the scene who wrote the driver in just three days.
I do not know. They do not seem to be interested in making business with Gunnar directly. I can only speculate why.
Interestingly you seem to only know what suits your needs.
Look, I have little problem excluding Hyperion if T&A are paid directly. I'm not exactly a fan of them either. However, it seems that there is currently no ongoing negotiations between Gunnar and T&A whatsoever. My understanding of the situation is that P96 has been or will be sold in total to Hyperion (by money, of course), in which case T&A would be no longer part of the game because they no longer want to be part of the game.
Then any payment to them from the apollo team would be based on nothing else but good will.
Negotiations are then to be made with Hyperion.
There will be no negotiations with Hyperion.
Unfortunately, as long as T&A are the authors and owners of P96, they are part of the story, and you simply cannot ignore license conditions because they don't want to negotiate with you directly.
YOU are constantly ignoring license conditions! T&A offered two license models: vendor license and distribution of driver through the vendor or shareware to be paid by the user. We have chosen to decline the first and use the second. That's it.
-
Neither - nor. Again, I'm not under NDA from Hyperion, we have no contract. Neither am I under NDA from T&A, nor do I have a contract in this direction. Nobody is paying me, and these are all my sole and only personal opinions.
Call this my personal view on the affairs as an developer who helped once in P96 development, and a developer who saw the demise of P96 due to a dishonest company (Elbox, namely) simply using P96 for their commercial products. I also see that this history just repeats.
Don't worry, I've made my points more than clear with Gunnar already.
Indeed, same problems all again.
If you ask me where to make the cut (personal opinion): As long as I have a hobby project, and develop a driver for a low-volume series for a couple of friends in a non-profit way, I'll believe I as a developer would be fine. No harm done.
As soon, however, as I sell a product for a commercial interest, I personally see problems. Elbox is such a candidate for sure. They sold products to end-users, including drivers, hence created products for money that clearly depended on third party work, yet didn't want to pay for this third party work.
About the two other products I do not know enough to state a clear position.
so, this is your personal opinion. you have no contact to the original developers, who are being reported not to care personally and be fine with situation as is (sounds very likely). the demise of p96 due to dishonest company already happened and therefore wont happen again. and still you go on a crusade agains apparently a honest appointment between gunnar and the original developers, because some third party, that has proven track of record of misinformation, lack of support, broken promisses and the like wanted to chip in in that deal.
really.. why do you care at all. i trust your good will and that you had hope to find some constructive compromise here, but what you are telling only makes it to look more utopic, based on communitys experience with parties involved.
-
@thor
btw. if you have a list of people who would have helped with improving the os for part of money gunnar would pay to hyperion (im sure they would keep some part of it) why not put up some aros bounties the people can work towards and be dependably rewarded that way?
i mean i doubt hyperion is a potential source of investments here, the money must come from elsewhere. so logically, if they are not involved, there is potentially more funds at disposal, as they dont need to be granted a share, for whatever they would do, likely nothing.
-
I will write here my toughts again as outsider (Atari user) as I follow Apollo core development as possible solution for Atari clones/accelerators (it is not in ussable state yet for us by my opinion).
I think the licences are not the problem for accelerators if it is not shipped to the user with preinstalled software which needs lisences. If it would come to the user with preinstalled AROS and user can change that to use AOS instead, it is up to user to take the risk of breaking licence.
If there will be a stanalone clone there could be more problems regardin that but this is to early to discuss that or better to say ... it is not productive at all!
The person who will invest the money into this project will take the risk of being sued because of violating any legal rights. And I believe that person will solve those problems before he will invest his money.
With this discussion here you are not productive, but you are destructive! Dont argue about the things you dont have to! You dont take a risk until you dont violate licences by yourself. If you violate licences, dont talk about that. It is that simple :)
Amiga community (and Atari even more) is so small that dont play any role in computer world (today), but you are thinking as you are big players. Nobody cares about Amiga and Atari except "few" enthusiasts. And Amiga or Atari wont play any role in the future again.
BTW. Apollo core has potential ... also to be commercialy successfull. But ...
-
If that is so, good.
Another obvious limitation is of course the current production line, which from what I understand is kipper2k and his soldering iron.
not to worry, i have a magical soldering iron that can fit underneath the fpga and solder each one of the 484 balls by hand... k, back to work, i need to finish this board by the end of this month, i believe i have a customer :)
-
really.. why do you care at all. i trust your good will and that you had hope to find some constructive compromise here, but what you are telling only makes it to look more utopic, based on communitys experience with parties involved.
Why do I care at all? That is indeed a good question. I care why I saw that the P96 was more or less going down the drain because a dishonest vendor - Elbox namely - just took the P96 core and used it to sell their products, and returned no money whatsoever to the authors.
And now I see all this happening again.
I'm sorry, this really p*sses me off. It's exactly this type of dishonesty that caused a lot of problems in the Amiga world: CBM, essentially stealing ARexx. Elbox stealing P96, Haage & Partner stealing Genesis.And now, yet again?
Oh, please, do we *really* need to repeat history?
It would be really about time that we get things done the right way and the correct way.
-
Why do I care at all? That is indeed a good question. I care why I saw that the P96 was more or less going down the drain because a dishonest vendor - Elbox namely - just took the P96 core and used it to sell their products, and returned no money whatsoever to the authors.
And now I see all this happening again.
I'm sorry, this really p*sses me off. It's exactly this type of dishonesty that caused a lot of problems in the Amiga world: CBM, essentially stealing ARexx. Elbox stealing P96, Haage & Partner stealing Genesis.And now, yet again?
Oh, please, do we *really* need to repeat history?
It would be really about time that we get things done the right way and the correct way.
you saw it going down the drain 20 years ago and now you want make a exempel of gunnar as revenge for what happened 20 years ago? :confused:
Please step back and start thinking... you are intelligent
the computers are delivered with a kickstart, nothing else
the aros driver is recommended for aros but also works with P96 but has to downloaded by the users on its own
there is nothing preinstalled, no 3.1. and no P96
if the P96 owner want shareware fees they should show up and say where people can register. If they offer updates people will certainly spend money on it
-
And now I see all this happening again.
it happened once. under different circumstances. if gunnar has approached the genuine coders and has their approval its all fine. a completely different thing. you have all the time poating as if you have been in contact with those and mediating an agreement. as it turns out, you didint have any contact and are relying on what gunnar and hyperion say. why are you insisting on your personal views based on hearsay as being objective?
I'm sorry, this really p*sses me off. It's exactly this type of dishonesty that caused a lot of problems in the Amiga world: CBM, essentially stealing ARexx. Elbox stealing P96, Haage & Partner stealing Genesis.And now, yet again?
Oh, please, do we *really* need to repeat history?
It would be really about time that we get things done the right way and the correct way.
and yet we are here. doesnt look like gunnar was doing anythig particularly wrong in this context. it may not be exactly by the book, but it isnt incorrect so far, while others are.
i dont like to think like that. but im really starting to feel that you are being pissed off not because the original developers are not getting their share, but because hyperion has missed an opportunity to intermediate and gain on that.
-
So you agree that is nothing that would be worth the 10,000€ Gunnar offered to Hyperion?
You told me that you've some experience in Jura. So what's your hourly rate? I know mine. How much time would 10000€ pay you? How much time would it pay a software developer? How much time would it pay a freelance hobby developer. Please be honest, check the numbers carefully.
If those 10.000€ are somewhere lost in the machinary of Hyperion: I believe we agree, that's not worth it. If the 10.000€ arrive - to some degree - in the pockets of the developers, that's probably not too bad a deal at all.
-
you are being pissed off not because the original developers are not getting their share, but because hyperion has missed an opportunity to intermediate and gain on that.
Bingo!
-
If those 10.000€ are somewhere lost in the machinary of Hyperion: I believe we agree, that's not worth it. If the 10.000€ arrive - to some degree - in the pockets of the developers, that's probably not too bad a deal at all.
but this money is not donated by hyperion. they only want an administrative share. who knows how much. once assumed the money is there, wherever it has been found, isnt that better if all the money arrive in the pockets of actual developers?
-
How much time would 10000€ pay you?
You know the old saying. People that talk about money or sex in public don't have it.
-
Bingo!
What???? I'm sorry, I don't know what you're thinking. I don't mind Hyperions demise, nor do I work for them, nor do I have a contract with them, nor have I received anything from them, nothing. I mind the demise of AmigaOs. There was a window of opportunity that would have allowed an ongoing development of the Os. Unfortuantely, it does not work without Hyperion. No, I do not like this either. If you see any other chance how to work on AmigaOs - let me know.
-
but this money is not donated by hyperion. they only want an administrative share. who knows how much. once assumed the money is there, wherever it has been found, isnt that better if all the money arrive in the pockets of actual developers?
Of course it is. Now tell me, which plan do you have to get it there? Or rather, would you help to make this plan become real?
-
What???? I'm sorry, I don't know what you're thinking. I don't mind Hyperions demise, nor do I work for them, have a contract with them, have received anything from them, nothing. I mind the demise of AmigaOs. There was a window of opportunity that would have allowed an ongoing development of the Os. Unfortuantely, it does not work without Hyperion. No, I do not like this either. If you see any other chance how to work on AmigaOs - let me know.
Yet you advocate for working with Hyperion regarding the P96 deal? Doesn't add up. If you truly cared about the authors' of P96 best interest you would be encouraging them to work with Gunnar on compensation.
Saying they can't be bothered to work with Gunnar and only want to deal with Hyperion seems silly. If they wanted compensation for the license they would deal with Gunnar directly. Who doesn't want 'free' money?
If they wanted to sell the entire product to Hyperion directly and no longer bother with licensing then they should do that irregardless of any deal that Gunnar might or might not make.
The whole thing seems like a shady play by Hyperion to get some cash to stave off starvation. I truly believe that the sooner Hyperion is out of business the better it is for the Amiga community.
I think you misunderstand the whole open source thing, or are putting too much weight on the opinion of 1 or 2 people.
Most prefer AmigaOS being open sourced or AROS over continuing to fund Hyperion for pretty much nothing in return.
If a legitimate update to AmigaOS 3.x was released for a reasonable amount of money I think it would sell, even if the money went to Hyperion, but it would sell more if Hyperion were no longer involved.
-
What???? I'm sorry, I don't know what you're thinking. I don't mind Hyperions demise, nor do I work for them, have a contract with them, have received anything from them, nothing. I mind the demise of AmigaOs. There was a window of opportunity that would have allowed an ongoing development of the Os. Unfortuantely, it does not work without Hyperion. No, I do not like this either. If you see any other chance how to work on AmigaOs - let me know.
I guess we hit the crux of the issue right here;
Gunnar talked to them, and couldnt get a sufficiently good deal with Hyperion.
-Hes concerned with the "roadmap" ahead for Vampire
-He said he prefer to go the AOS direction, but with one entity holding all(?) the cards in that regard, it seems a bit risky to go all in for AOS....again, without a solid deal.
You express issues with Hyperion, so how can you "blame" Gunnar/Apollo team to look at options given "it does not work without Hyperion".
It wont be the demise of AOS anyhow, no more than it has been up to now anyhow. AOS 3.x havent seen any development for many years and people keep tinkering with it.
That wouldnt have changed, with or without Vampire.
If you want to "blame" anyone, how about pointing at Hyperion that seemingly have no intrest in its development? I realise they are knee-deep in demands from AOS 4.x hardware owners.
Which brings me to another thing; AeonKit and Hyperion alike has been extremely quiet the last few months.
-
What???? I'm sorry, I don't know what you're thinking. I don't mind Hyperions demise, nor do I work for them, nor do I have a contract with them, nor have I received anything from them, nothing. I mind the demise of AmigaOs. There was a window of opportunity that would have allowed an ongoing development of the Os. Unfortuantely, it does not work without Hyperion. No, I do not like this either. If you see any other chance how to work on AmigaOs - let me know.
Also, then if there is a window of opportunity make it work. Contact Hyperion and convince them of this opportunity with this new FPGA hardware being released. Even if Vampire did not succeed (seems very unlikely), there's FPGA Arcade and others and these products will only get better and faster. Come up with a deal where you (and/or others) can work to update AmigaOS 3.x and release a new version. If you believe there is a market, and I do too, then make it work.
Perhaps there is a deal to be made where you are compensated based on the # of units sold, which gives you incentive to produce a worthwhile update. If you can then keep Hyperion out of the food chain. Perhaps they money goes through a vendor (Cloanto, AmigaKit) and a portion of the sales go to you and the other portion is paid to Hyperion, otherwise you may be waiting forever for a check from Hyperion. People would also feel better about giving money that goes to you vs. money that goes to the abyss that is Hyperion.
Don't complain because some people on the forum would prefer AROS - it's only because they have no confidence today in Hyperion and AmigaOS 3.x development!
You are right, there is a window of opportunity between now and when AROS is developed to the point where it is a reasonable replacement for AmigaOS 3.x. Without development work on AmigaOS 3.x AROS 68K will likely get lots of attention since this FPGA hardware is gaining so much traction.
Seize the opportunity! If Hyperion will only deal on ridiculous terms you'll get your answer - AmigaOS 3.x is dead while in their hands, and not because of the users but because of them.
-
If you want to "blame" anyone, how about pointing at Hyperion that seemingly have no intrest in its development? I realise they are knee-deep in demands from AOS 4.x hardware owners.
You're right of course. Indeed, I had. I send them a pretty angry email two weeks ago how they could have possibly missed this type of a deal. There was a long talk with Gunnar, and they also f*cked this up. Thank you for pointing this out.
Then later last week send me "we would like to talk to you later, there are other FPGA projects", and my answer was, "thanks, no".
Reason is basically that the best they can do is a "Me, too!" project that comes too late, does too little, and even more - with whom working on the FPGA? It's not that there is any in-house knowledge for that at Hyperion. It requires a knowledgable CPU designer - exactly like Gunnar - to get this job done. Done right.
So whom are they fooling? There's nothing better concering 68K on the market right now.
And yes, the Vampire does a lot of things right, from the technical perspective. It's a brilliant project as such.
Which brings me to another thing; AeonKit and Hyperion alike has been extremely quiet the last few months.
Yes, actually now that you mention it.
-
You told me that you've some experience in Jura. So what's your hourly rate? I know mine. How much time would 10000€ pay you? How much time would it pay a software developer? How much time would it pay a freelance hobby developer. Please be honest, check the numbers carefully.
If those 10.000€ are somewhere lost in the machinary of Hyperion: I believe we agree, that's not worth it. If the 10.000€ arrive - to some degree - in the pockets of the developers, that's probably not too bad a deal at all.
What would that 10.000€ go to ?
Developing of the driver that is already done ?
Development of Picasso96 that is already done ?
Paying for Elbox mistake 15 years ago ?
Make it possible for Hyperion to make more PPC patches ?
IF there still was an active development of Picasso96, which there is not. (last version för 68k is from 1999) and IF that said developer did drivers for you (they dont) then yes this whole thing would look different. Now its just pathetic.
-
This is all so predictable :)
-
@Thomas
Okey, thanks for the insight into the Hyperion correspondance. :)
-
You're right of course. Indeed, I had. I send them a pretty angry email two weeks ago how they could have possibly missed this type of a deal. There was a long talk with Gunnar, and they also f*cked this up. Thank you for pointing this out.
Then later last week send me "we would like to talk to you later, there are other FPGA projects", and my answer was, "thanks, no".
Reason is basically that the best they can do is a "Me, too!" project that comes too late, does too little, and even more - with whom working on the FPGA? It's not that there is any in-house knowledge for that at Hyperion. It requires a knowledgable CPU designer - exactly like Gunnar - to get this job done. Done right.
So whom are they fooling? There's nothing better concering 68K on the market right now.
And yes, the Vampire does a lot of things right, from the technical perspective. It's a brilliant project as such.
Yes, actually now that you mention it.
as you see all they can is ride on tails of others, miss deadlines, oversee opportunities, blame the audience, pretend to own or have licenses for something none can verify.
why would you want to associate yourself with someone like that? to have gallium and multicore promissed and talked about on forums for another twenty years? until maybe someone else achieves this?
no, thanks. i prefer they stay with ppc business and target audience, where they are welcome. they dont bring anything to the table.
-
You're right of course. Indeed, I had. I send them a pretty angry email two weeks ago how they could have possibly missed this type of a deal. There was a long talk with Gunnar, and they also f*cked this up. Thank you for pointing this out.
Then later last week send me "we would like to talk to you later, there are other FPGA projects", and my answer was, "thanks, no".
I guess I shouldn't be surprised, but it takes a special kind of incompetence on Hyperion's part to screw up something like this.
Given that Gunnar *wanted* AOS on Vampire this was a win-win scenario for Hyperion since devs creating new software for a more powerful 68k platform (which could have been updated to make porting to OS4 easier) would've resulted in more software on PPC.
But as others have said, they're not even interested in supporting OS4 WinUAE despite being happy to sell ISOs alongside AF2016. Truly their own worst enemy.
-
IF there still was an active development of Picasso96, which there is not. (last version för 68k is from 1999)
Ehem, no. The latest version I have is probably six month old. A couple of bugs fixed - not only by me, also by others.
This consists of wrong drawing modes for some versions of BltTemplate, wrong detection of fast/chip memory, a somewhat streamlined blitplane copy algorithm, and maybe a couple of other things I don't remember.
Now, what do I do with that? Ignore the license and just throw it to Aminet? No, I do not have a developer license.
Essentially, it is nice to have this on my desktop, but it doesn't really help much there.
I have here an updated audio.device, an updated keymap.library, an updated keyboard.resource and probably a couple of other minor components I might have forgotten that are, in principle, ready to release.
Do I have a developer licence for AmigaOs? No. Can I release it? No.
Do you see a pattern here?
-
Thomas - can you not talk to Cloanto about including them in Amiga Forever? Clearly Mike has some leeway in updating (and distributing) AmigaOS 3.x
-
But as others have said, they're not even interested in supporting OS4 WinUAE despite being happy to sell ISOs alongside AF2016. Truly their own worst enemy.
That's 'cos they jacked Bernie's idea with Amithlon. They'll be "creating" their version in A.L.I.C.E. Gee, a linux kernel that boots straight into UAE and runs AmigaOS? Why does that sound familiar? :roflmao:
-
That's 'cos they jacked Bernie's idea with Amithlon. They'll be "creating" their version in A.L.I.C.E. Gee, a linux kernel that boots straight into UAE and runs AmigaOS? Why does that sound familiar? :roflmao:
Actually that's all A-Eon's doing (with the ROM/OS licensed from Cloanto plus support from Toni Wilen and the AmiKit devs). Trevor's said that A.L.I.C.E. will optionally run OS4 (a paid extra I guess) but on the laptops they've been showing off it'll run like ass (because Hyperion are doing nothing to support UAE).
-
No. Can I release it? No.
Do you see a pattern here?
i feel your pain. any investment there is lost. but you are not a newbie, you know the people and the circumstances, how come you are surprised by this attitude?
-
This become real soap opera...
-
Thomas, how come you have all those programs and the respective sources without being under NDA? It's a pity you can't release this stuff. But that's due to Hyperion's lack of interest and not our fault. Collateral damage, so to say. So the work and disappointed idealism that went into it is the reason why you are so angry? Don't worry, the day will come when AOS will be legally open source (and hopefully merged with AROS).
-
Thomas, how come you have all those programs and the respective sources without being under NDA? It's a pity you can't release this stuff. But that's due to Hyperion's lack of interest and not our fault. Collateral damage, so to say. So the work and disappointed idealism that went into it is the reason why you are so angry? Don't worry, the day will come when AOS will be legally open source (and hopefully merged with AROS).
i dont like myself saying this, but looks so true..
-
This become real soap opera...
With some fresh popcorn it's kind of entertaining. And like any good soap series you'll not get too surprised by the main character's actions.
-
https://www.youtube.com/watch?v=_aQKRIDbtSM
Mpeg test.
-
well, this therad as another on a1k and who knows where yet, illustrates hopefully for everybody rather well, what may usually happen, when coming too close within the vicitnity of some ips, copyrights, assumed ownerships or licenses, especially as soon as some hope for money to be gained of them even remotely (and funny enough upon somone elses work) appear somewhere out there.
is this what the community is served best with?
you tell me..
-
Ehem, no. The latest version I have is probably six month old. A couple of bugs fixed - not only by me, also by others.
This consists of wrong drawing modes for some versions of BltTemplate, wrong detection of fast/chip memory, a somewhat streamlined blitplane copy algorithm, and maybe a couple of other things I don't remember.
Now, what do I do with that? Ignore the license and just throw it to Aminet? No, I do not have a developer license.
Essentially, it is nice to have this on my desktop, but it doesn't really help much there.
I have here an updated audio.device, an updated keymap.library, an updated keyboard.resource and probably a couple of other minor components I might have forgotten that are, in principle, ready to release.
Do I have a developer licence for AmigaOs? No. Can I release it? No.
Do you see a pattern here?
Yes i see a pattern. It sucks as bad as anything closed source in Amiga land.
You could have put all that into AROS and brought it up to speed instead.
Then you would have been free to release it.
Questions:
1. So you don't have developer license and still you have the source code to it all ?
2. And you think that these 10.000 would have magically made it possible for you to release all the above ? (please not the normal maybe because that is in Amiga land a certain no)
-
The second Thomas commits something to AROS, Amiga Inc. and Hyperion will slam AROS for copyright infringement :)
-
1. So you don't have developer license and still you have the source code to it all ?
Yes. 2. And you think that these 10.000 would have magically made it possible for you to release all the above ? (please not the normal maybe because that is in Amiga land a certain no)
It would certainly not have made it possible to release sources and all that. How? But it would have made it possible to start a project about it and release the results.
-
The second Thomas commits something to AROS, Amiga Inc. and Hyperion will slam AROS for copyright infringement :)
Which is pretty much the reason why I stay out of AROS, you got it.
-
I can't speak for AROS but you certainly could contribute to parts that have no antecedent in AOS such as device drivers for modern devices.
-
I can't speak for AROS but you certainly could contribute to parts that have no antecedent in AOS such as device drivers for modern devices.
there is even a "core" os4 developer contributing to aros diskimage device, frederick. or rather he has become core developer at os4 after he has parallelly contributed his work to both for a good while. but i think thomas decision is right and i honour and understand it. he could consult, but then this is up to everybody personally.
-
When i see this thread i expected to finding a nice discussion about the new features of the vampire v2 but is just a legal mambo jumbo war, never expected to see so much lawyers wannabees on Amiga.org. :P
-
When i see this thread i expected to finding a nice discussion about the new features of the vampire v2 but is just a legal mambo jumbo war, never expected to see so much lawyers wannabees on Amiga.org. :P
Opinions are like arseholes, everyone has one. ;)
-
When i see this thread i expected to finding a nice discussion about the new features of the vampire v2 but is just a legal mambo jumbo war, never expected to see so much lawyers wannabees on Amiga.org. :P
+1
The clue is in the title, one would expect this thread to be about the specs of vampire, planned firmware updates, availability, performance etc etc. If people want to get into a pretracted 20 page discussion about OS wars and legal ranglings etc then an appropriate named thread should me created and all that stuff merged into it.
-
Some moderation called for.
-
Part of the discussion was that P96 was to be bought completely by Hyerion (they currently only have a license). This money goes from Hyperion to T&A. Where is this money supposed to come from?
The very moment P96 gets into Hyperion's claws it is essentially lost for 68k anyway. Without magical radical change of thinking in Hyperion, I think it is not possible to collaborate with them on such thing.
-
Lets lighten the mood...
http://www.kipper2k.com/video/x16.jpg
http://www.kipper2k.com/video/x16bus.jpg
http://www.kipper2k.com/video/x16.mp4
-
For god sake that is damn fast faster than 68060 and the p96 support look great, i don't own an amiga 600 when the 1200 version comes out i purchase it straight out make me envious off amiga 600 users ;)
-
yup, it is pretty well the fastest a600 in the world :) (ATM anyway) the video drivers are the old testing ones, there are newer drivers now being worked on to replace the ones seen in the video
-
yup, it is pretty well the fastest a600 in the world :) (ATM anyway) the video drivers are the old testing ones, there are newer drivers now being worked on to replace the ones seen in the video
Good Day Sir,
Please ready research for an A2000 Expansion slot board, at least keep it in mind.
Thanks
Chris
-
It would be good to have Vampire 1200 with some Wifi and USB... and SATA ;)
-
IMHO, modular may be better on most add on but SATA with good DMA support should be standard. Will keep base unit price down and you can add what you want.
-
IMHO, modular may be better on most add on but SATA with good DMA support should be standard. Will keep base unit price down and you can add what you want.
When the stand alone motherboards are eventually released perhaps we'll see an ATX variant form factor with onboard SATA, USB and PCIe slots? Zorro 3 compatible slots for legacy hardware would be the icing on the cake. :)
-
Dear all, as this thread was mainly for my review of the Vampire 600 v2, I've asked moderators to clean this thread by moving the whole licencing discussion to another thread. Posting Vampire review updates in this thread is as of today useless and would be unreadable.
-
Lets lighten the mood...
http://www.kipper2k.com/video/x16.jpg
http://www.kipper2k.com/video/x16bus.jpg
http://www.kipper2k.com/video/x16.mp4
Damn, Kipper. Can't even show us 32bit screens? Sheesh!:furious:
:lol::roflmao:
Good work. Now, make an a500 one, so I can scream, "TAKE MY MONEY!" :)
OT - Hey, does anyone in Amigaland have a spare A500 top they wish to sell? Mine committed suicide. :(
-
Damn, Kipper. Can't even show us 32bit screens? Sheesh!:furious:
:lol::roflmao:
Good work. Now, make an a500 one, so I can scream, "TAKE MY MONEY!" :)
OT - Hey, does anyone in Amigaland have a spare A500 top they wish to sell? Mine committed suicide. :(
I use this WB for testing, it is a fast load (3 seconds) simple with very few addons. a bigger more involved WB will still generate the same numbers so i am happy with this.
A500 boards are pretty well in majsta's hands as we speak
-
When the stand alone motherboards are eventually released perhaps we'll see an ATX variant form factor with onboard SATA, USB and PCIe slots? Zorro 3 compatible slots for legacy hardware would be the icing on the cake. :)
Agree fully. but while still an expansion all add on(s) should be on the accelerator and maybe optional.
-
Agree fully. but while still an expansion all add on(s) should be on the accelerator and maybe optional.
Express Card slot would be nice on the accelerators. :)
-
Or a PCI slot of some flavor....
-
nice wish concierto. already thought about feature creep, a fate of natami, and who would write the drivers?
-
Good Day Sir,
Please ready research for an A2000 Expansion slot board, at least keep it in mind.
Thanks
Chris
Hey yeah, will the A2000 version be a CPU slot adapter or an adjusted A500 design (68k slot drop in)?
-
Hey yeah, will the A2000 version be a CPU slot adapter or an adjusted A500 design (68k slot drop in)?
something like that i guess, but does that matter either way as long it works?
-
Will not purchase with no access to the fast bus......
-
Or a PCI slot of some flavor....
Express Card is a PCIe x16 slot in a small card slot format used in laptops.
-
Will not purchase with no access to the fast bus......
Not sure what you mean by this, it does have a fast bus already, fastest that the a2000 can provide. with video, SD, IDE capabilities isn't everything you need on this board ?
it can be parked either sitting in the cpu slot or sitting in the co-processor slot
-
Not sure what you mean by this, it does have a fast bus already, fastest that the a2000 can provide. with video, SD, IDE capabilities isn't everything you need on this board ?
it can be parked either sitting in the cpu slot or sitting in the co-processor slot
My thinking is SATA with good DMA support standard. If you want Ethernet, plug the expansion in the accelerator, same with usb.
Chris
-
I think the best bet is for the FPGA on the standalone board to expose some I2C or SPI buses (or SDIO), and then to use standard chips that connect to these buses for Ethernet (with TCP offload!), WiFi, BT, etc.
SATA really would require choosing an FPGA with a SATA hardware block already incorporated, or PCIe incorporated to connect an external controller. Could be a lot of work and increase the cost a lot. Personally I'd stick with the SD card readers, maybe have an internal slot and an external slot.
-
My thinking is SATA with good DMA support standard. If you want Ethernet, plug the expansion in the accelerator, same with usb.
Chris
You mean SATA III, so we can use SSDs with 550MB read/write capabilities.
Yeah, no Amiga should use anything less that that.
-
You mean SATA III, so we can use SSDs with 550MB read/write capabilities.
Yeah, no Amiga should use anything less that that.
I'd rather see m.2 slots that support SATA and PCIe, otherwise you're limited to budget SSD's.
-
I'd rather have the cards come out as soon as possible, all these extras will only slow their release.
-
WIP Core progress. SD is coming !
(http://i.imgur.com/vvnNtyj.jpg)
-
SD0:, how nice, that is what I call the card slot device on my MIST too :)
-
@UberFreak,
Why I would like to see a base card and just add on after. Lower initial cost and faster to sales. Just be able to add on the rest!
Chris
-
I would love to see wifi integrated!
-
@pixie,
If small and inexpensive otherwise sounds like another piggyback module.
-
If there was an onboard usb host controller, wifi could come very cheaply.
-
http://i.imgur.com/9LvcPNA.jpg
Performance comparisons.
-
a600 is kick´n big brothas behind there! :)
-
Amiga A600 Vampire II Update - SAGA Driver , HDMI Out, Rise of the Triad, Duke 3D , Speed !
https://www.youtube.com/watch?v=P5imzOM2XFU
-
http://i.imgur.com/9LvcPNA.jpg
Performance comparisons.
daaaammmnnn!! That bad boy kicks the sh** outta even the PPC rig.
-
I doubt PPC was used in those benchmarks, considering how it is so in pair with plain 060. Would be interesting to see comparison against macs running MorphOS, with and without 68k emulation.
-
I'd like to see those test results
-
Want to see Exodus: The Last War, Napalm, Heretic & Hexen!
-
Napalm is AGA only so you'd have to wait for a A1200 Vampire board.
-
Napalm is AGA only so you'd have to wait for a A1200 Vampire board.
Doh, slipt my mind :) Well it's RTG also?
-
Napalm is AGA only so you'd have to wait for a A1200 Vampire board.
What? I run it on my A2000 w/PicIV! Heheheh.
-
Alien Breed 3D II on Amiga 600
https://www.youtube.com/watch?v=-jwt3JSa_jg&feature=youtu.be
-
Anyone tried Nightlong?
http://hol.abime.net/977
-
(http://i.imgur.com/NO5J7BT.jpg)
With todays WIP core, we finally got ScummVM RTG to launch.
-
Vampire 600 V2 - Magic64 (C64 emulator on Amiga)
https://vimeo.com/160902451
-
Someone can try Tomb Raider with PCTask (here on an Apollo 1240 : https://www.youtube.com/watch?v=Ou4LhtKoDLs)
I have the .hd file ready to launch...
Tuko the vieille fripouille, contact-moi sur mon email pour te le donner...
:)
-
Vampire for A500
https://www.dropbox.com/s/93j1ykam7aj8i8i/V500V2_IDE.avi?dl=0
Its somewhat slow for booting, but thats trivial tweaks according to majsta. Work in progress etc.
Vampire+Amikit
https://www.youtube.com/watch?v=9hI4K4uFUzU&feature=youtu.be
-
Someone can try Tomb Raider with PCTask (here on an Apollo 1240 : https://www.youtube.com/watch?v=Ou4LhtKoDLs)
Done with 060 - perhaps 2 - 4 fps at best.
-
Someone can try Tomb Raider with PCTask (here on an Apollo 1240 : https://www.youtube.com/watch?v=Ou4LhtKoDLs)
I have the .hd file ready to launch...
Tuko the vieille fripouille, contact-moi sur mon email pour te le donner...
:)
I've never used PCTask before, but I have a Vampire and if you can make the .hd available to me, I'll give it a try for you :)
-
Someone can try Tomb Raider with PCTask (here on an Apollo 1240 : https://www.youtube.com/watch?v=Ou4LhtKoDLs)
I have the .hd file ready to launch...
Tuko the vieille fripouille, contact-moi sur mon email pour te le donner...
:)
PCTask is old news, DosBox is more interesting :)
When they finally get FPU enabled they'll be able to run my DosBox port at a good speed!
[youtube]sBahgGWG6v0[/youtube]
-
Is it possible to compile a non FPU version of DosBox, and how dependant is it on FPU for speed of emulation?
I guess its moot point since you aint active in amiga development atm.
-
Courtesy of a new Apollo Team member, R_Nev, we got today a new build of ScummVM 1.8.0 running over RTG.
It's unoptimized and a WIP but it's very encouraging.
https://youtu.be/IEtHJfOkRD8
-
AROS booting on Vampire v2
https://youtu.be/FCeMIccENk4
-
AROS booting on Vampire v2
https://youtu.be/FCeMIccENk4
Nice, why did you not press "Cancel" so we could see Workbook running etc? :)
-
AROS booting on Vampire v2
https://youtu.be/FCeMIccENk4
was amazed how long it takes, before i realized that it is booting from floppy..
nevertheless not much to see here. please wait till i upload an actual version to flyppes ftp, hopefully with fixed ide/ata, so that we can see some full blown system, especially on rtg and with some applictions at least being started.
might take the weekend though, aros has moved to gcc6 and adding more compilers like clang/llvm, and while that there is some fix pending, what concerns 040, which will affect vampire since it identifies itself as 040 i assume.
-
Nice, why did you not press "Cancel" so we could see Workbook running etc? :)
To tease you... :)
Haven't had a lot time to play with. I'll do it this weekend.
-
A Vampire2 could be a nice system to do native compilation on, provided that the toolchain doesn't get all confused about the CPU.
-
I was wondering about the HDMI out on the Vampire v2. If a person in the US slaps a vampire on a PAL A600, does that circumvent any PAL/NTSC issues?
Or in other words, is all HDMI the same? Would there still be any need to do the dual mouse button press to switch to NTSC?
-
I was wondering about the HDMI out on the Vampire v2. If a person in the US slaps a vampire on a PAL A600, does that circumvent any PAL/NTSC issues?
Or in other words, is all HDMI the same? Would there still be any need to do the dual mouse button press to switch to NTSC?
If you have a PAL A600 but want to run in 60hz mode then you'll still need to use the boot menu.
Depending on what you mean by "is all HDMI the same" you could either answer yes or no.
-
Mounted my Samsung 32Gb microSD.
(http://i.imgur.com/1pj9c0V.jpg)
-
Hi guys,
I'm very happy to inform you that R_Nev did a new build of ScummVM RTG 1.8.0 based on what NovaCoder left as sources. Kudos to both these two guys.
It still need a bit of polishing but it already works well.
Here is a quick video of it running Sam'n'Max and Curse of Monkey Island :
https://www.youtube.com/watch?v=eGCi3DqJxp8
Link to the exe :
http://www.apollo-accelerators.com/files/ScummVM_RTG_1.8.0.lha
Enjoy it and feel free to show us videos of gameplays and come to discuss it with us on IRC.
-
Amiga A600 Vampire II Update - SILVER6 CORE, HD Screenmodes, Descent, MAME, Fusion, SCUMMVM
https://www.youtube.com/watch?v=TAaWt9nTfP4
-
Very nice I'm told mine will be ready in a couple of weeks.
So they need a logo, I did this and the folks on the team like it.
I'm thinking of getting these printed as stickers on fax metallic uv coated stock.
(http://i.imgur.com/zKu2ANw.jpg)
-
Can I suggest the "V" in Amiga checkmark style :)
-
Very nice sticker logos :)
-
Funny you mention it, I had a concept for a boot screen logo animation where a a heartbeat shaped like the Amiga checkmark flatlines and the V from the Vampire revives the Amiga checkmark into the V with the number 2 bloodstroke logo... (a lousy explantion, better explained visually with an animation) but I think it's best to make a clean break and not infringe upon ANYTHING related to Amiga trademarks. Better that way.
-
imho too overloaded. good desig is simple. if its gonna be based on amiga checkmark and heartbeat, which is imho a right idea, lets see what scheme might be used (schematically):
\ /\____...
\/---\
okay dark colors rpresents vampires;) a rainbow must be a part of checkmark. but why gradient in dark grey?
-
Great logos! Had a bit of a chuckle at the "64-bit" part. Nice that you incorporated the rainbow gradient! :)
-
Teaser screenshot... Testing some things... will you find what it is about ?
(http://i.imgur.com/NU08ItK.jpg)
-
Is that an FPU I see, was there an FPU enabled before? Would that mace it an EC 040 since there is no MMU... I dunno.
-
Kippa just released a video of his first V500
http://www.kipper2k.com/video/helloworld.mp4
-
taking the world by storm, dont we? ;)
-
Kippa just released a video of his first V500
http://www.kipper2k.com/video/helloworld.mp4
Oh boy oh boy oh boy...
I've been lurk-following this thread for months, and as a happy A500 owner, I'm *so psyched* that I might someday have a Vampire board in my faithful old Amiga. I just can't wait for this!
-
Kippa just released a video of his first V500
http://www.kipper2k.com/video/helloworld.mp4
Is that a pass through connector for the original 68K I see there?
-
Teaser screenshot... Testing some things... will you find what it is about ?
I think its time to try some 060 demo-scene productions, now that FPU is active :)
EDIT: and I completely forgot 99.9999% of them require AGA (although some support RTG).
-
Kippa just released a video of his first V500
http://www.kipper2k.com/video/helloworld.mp4
It's an all brave new world! :)
-
Amiga community (and Atari even more) is so small that dont play any role in computer world (today), but you are thinking as you are big players. Nobody cares about Amiga and Atari except "few" enthusiasts. And Amiga or Atari wont play any role in the future again.
BTW. Apollo core has potential ... also to be commercialy successfull. But ...
Yes! Most of these discussions about the legalities seem delusional to me
My definition of non-hobbyist OS is one where people can do things with it for significant commercial gain. Is classic amiga hardware used or OS3 software being used for any significant commercial enterprise. I don't think that has happened in amigaland in about 20 years! Its just a bit of fun with old users seeing how far they can push their old software.
$10,000 for a shareware product like p96 is just opportunistic action to shut down a perceive hardware competitor. No-one I knew back in the day actually paid for 3.1 p96, would not surprise me $10,000 is more than the P96 shareware that was registered! We all use CGX as we all had phase 5 hardware which simply ran better with CGX.
BTW how did the p96 team write the software given that RTG on Amiga was AFAIR something phase 5 implemented?
-
Hi everyone,
I just finished the installation of the Vampire V2 on my A600. This is the link to an article on my blog about the step by step installation plus the HDMI output.
http://arananet-net.kinja.com/instalacion-de-la-aceleradora-vampire-v2-en-mi-a600-c-1782458393?rev=1466635541360
Hope you find this useful.
Regards.
-
I will never understand why I don't like using AmigaOS under UAE..., but on my real Amiga (that is much, much slower) it is something completely different.
I think it is... sound of floppy disc when it is read ;).
I will wait for Vampire 1200 :)
-
I just finished the installation of the Vampire V2 on my A600. This is the link to an article on my blog about the step by step installation plus the HDMI output.
http://arananet-net.kinja.com/instalacion-de-la-aceleradora-vampire-v2-en-mi-a600-c-1782458393?rev=1466635541360
Fantastic! I don't speak this language but your excellent photos speak for themselves. Great job! :pint:
-
I know Vampire includes KS 3.1 but can you boot other Kickstarts with it? Say you wanted to boot KS 1.3 for some old unpatched game?
-
I know Vampire includes KS 3.1 but can you boot other Kickstarts with it? Say you wanted to boot KS 1.3 for some old unpatched game?
From what I understand, they are tuning it for WHDLoad. Should take care of that problem.
-
Vampire 500 V2+ (GOLD2) / Amiga 2000
AmigaOS 3.9 BB2 (Kick 3.9)
NetSurf-nofpu (Arti's build)
Genesis 45.7
X-Surf-100 Zorro-II
Prisma Megamix Zorro II
https://vimeo.com/201636912
Also, from Apollo site;
Gunnar von Boehn
(Apollo Team Member)
Posts 2311
01 Feb 2017 19:54
We hereby announce a new Feature of SAGA chipset
Magic DMA engines
The new DMA engines provide the following features:
* CPU cache coherent.
No nasty cache flushed needed to use them
* fully honoring CPU MPU and MMU.
This means DMA can support virtual memory
Memory can be protected from overwrite by DMA
Bad DMA access can be catched with Enforcer like tools
We work right now on DMA engines/drivers for
* FAST-IDE controller
* SDCard Controller
* Network Controller
The DMA engines are really fast.
This combination of performance and features (as MMU support) was never seen on any Amiga hardware before.
http://www.apollo-core.com/knowledge.php?b=1¬e=3713
-
(http://i.imgur.com/ryLdrsa.jpg)
Post-GOLD2 WIP Core
Getting 5.2MB/s from our good ol' A600 IDE interface ;-)
Who said this was impossible ?
-
yeehaa! time to flash me core!
-
Got some highscores during A600 IDE speedup tests with latest WIP core.
(http://i.imgur.com/ypxq3hP.jpg?1)
-
I agree!
This board looks awesome http://numato.com/waxwing-spartan-6-fpga-development-board/ , its NOT custom and should do MORE than the Vampire like AGA, P96 ect..ect!
Don't understand all this FPGA code being wasted on custom boards that take years for the public to get!
Just My 2 cents forth!
And The Bonus is it's stand alone! No real Amiga Needed other than a Case ;)
-
And The Bonus is it's stand alone! No real Amiga Needed other than a Case ;)
Thats not a bonus but a drawback...
-
Don't understand all this FPGA code being wasted on custom boards that take years for the public to get!
Just My 2 cents forth!
And The Bonus is it's stand alone! No real Amiga Needed other than a Case ;)
everybody has their own bias. but here are practical reasons. developing a cpu accelerator first, instead of a complete system (as for example natami was, admittedly a custom construction, but there are people running minimig on altera de2 and the like), allowed to start with the basics and be able to prove the compatibility of the cpu core against the genuine chipset.
as you see, in result vampire accels are developed further and in a higher demand than other proposals.
but if you want, why not approach the team with a cooperation proposal. maybe they get interested and let you develop a support for your preferred platform.
-
I have been waiting since 6 months to get mine, still no word. Maybe one day...
-
Trying to Keep Old Amiga Computers running is never a BONUS! I own two A1000's, A500, A3000, A1200, Pegasos 1, and a Efika. I've had PPC's in both the A3000 and A1200 in the Past, both Phase5 boards are long Dead and IMHO a big waste of my time and money! It was fun at the time, but time marched on. People still use cr-APPLE today because they let the PPC go and got with the Times!
-
For me, the whole point of this hobby is using the old machines, I dont see the appeal in emulation.
-
everybody has their own bias. but here are practical reasons. developing a cpu accelerator first, instead of a complete system (as for example natami was, admittedly a custom construction, but there are people running minimig on altera de2 and the like), allowed to start with the basics and be able to prove the compatibility of the cpu core against the genuine chipset.
as you see, in result vampire accels are developed further and in a higher demand than other proposals.
but if you want, why not approach the team with a cooperation proposal. maybe they get interested and let you develop a support for your preferred platform.
I have downloaded all the Amiga Miming files and just might start my own project. I don't just want a machine running 30 year old games, I have Amiga/C64 forever for that. I want a ALL In One Amiga running a UAE type BIOS with All Roms, Chip Sets, CPUs, Mem, Graphic, ect..ect FPGA programmed. Boot, Set it up, Run.. I believe the board I posted above could run as Anything from the A1000 to A4000 stock and expanded without a problem. From what I have read it's all about getting the timing down for the Chips, most of that work has already been done so I believe its just tweaking. Some of these boards are 40 bucks with VGA output audio and 512Mb of ram!
-
I fell in Love With The way the Machine Ran, not the Machine. ;)
-
I've had PPC's in both the A3000 and A1200 in the Past, both Phase5 boards are long Dead and IMHO a big waste of my time and money!
that admitted, but ppc boards for amiga were never an integral solution, i would rather conder them a hysteric hack in reaction to no real perspective and sane solution to an end of cpu architecture amiga was dependant upon.
-
I have downloaded all the Amiga Miming files and just might start my own project.
you realy might want to consult gunnar asking if they like to provide you with their core. im not sure how they go about their sources. its obviously a closed source solution, so probably no external developer ever gets a full access to the whole. but admittedly i dont know for sure. but even if you will be provided only with a pre compiled core, you might be able to run it on your board along with the minimig chipset i guess. maybe some interfacing may need attention. otherwise you will have to use tg68 softcore, which is considerably slower, but open source.
-
suffice to mention the appollo team are supporting atari, why shouldnt they support something else. that, given it doesnt cross their own standalone roadmap.
-
Devboards need to be relicensed to be used by end users so maybe not so cheap in the end. There are some devboards that the rest of the team are looking at for higher end models but the Cyclone 3 is not in production so the lower end models need custom design. Besides, the A600 and A500 lack some space for extras inside.
-
For me, the whole point of this hobby is using the old machines, I dont see the appeal in emulation.
If you consider using FPGA emulation, why are you even bothering with this thread?
-
I have downloaded all the Amiga Miming files and just might start my own project. I don't just want a machine running 30 year old games, I have Amiga/C64 forever for that. I want a ALL In One Amiga running a UAE type BIOS with All Roms, Chip Sets, CPUs, Mem, Graphic, ect..ect FPGA programmed.
UAE and Minimig has little to nothing in common, not sure why you mention UAE.
-
@ZXoney
You might look at the MiST version of the MiniMig core since it supports AGA chipset compatibility. If you can get better performance than the Vampire, more power to you! Good luck!
-
If you consider using FPGA emulation, why are you even bothering with this thread?
It is essentially https://en.wikipedia.org/wiki/In-circuit_emulation, although traditionally ICE is slower while Vampire is faster.
Even though it's emulation, it's still cool.
-
It is essentially https://en.wikipedia.org/wiki/In-circuit_emulation, although traditionally ICE is slower while Vampire is faster.
What? No. Nothing like that.
-
In circuit emulation usually involves a microcontroller rather than an FPGA.
-
Anyone using Indivision ECS should know they are using an emulator. According to some.
-
please, not another discussion if fpga is emulation or not!
-
In circuit emulation usually involves a microcontroller rather than an FPGA.
Maybe before FPGA's were available.
Google throws up a lot of results for: in circuit emulation FPGA
https://books.google.co.uk/books?id=Hay1AAAAIAAJ&pg=PA62&lpg=PA62&dq=in+circuit+emulation+using+fpga&source=bl&ots=vRsodFxXzB&sig=Q0OaeukqJfoXVty2HwxGNW-Hykw&hl=en&sa=X&ved=0ahUKEwju1rrm8NDSAhVNOMAKHXTcCtY4ChDoAQgfMAA#v=onepage&q=in%20circuit%20emulation%20using%20fpga&f=false
https://www.aldec.com/en/solutions/hardware_emulation_solutions/co-emulation
What? No. Nothing like that.
Yes, everything like that.
please, not another discussion if fpga is emulation or not!
It's not a discussion, it is emulation. It's really unhelpful that people use the "I don't like emulation, I like FPGA's, therefore FPGA's aren't emulation" logic.
-
It's not a discussion, it is emulation. It's really unhelpful that people use the "I don't like emulation, I like FPGA's, therefore FPGA's aren't emulation" logic.
So, is all use of FPGA emulation?
Does something have to exist to be emulated?
Do you consider Indivision ECS an emulator?
Do you consider C64 DTV an emulator?
Do you consider Akiko an emulator?
Where do you draw the line - when is something no longer emulation?
-
So, is all use of FPGA emulation?
Does something have to exist to be emulated?
Do you consider Indivision ECS an emulator?
Do you consider C64 DTV an emulator?
Do you consider Akiko an emulator?
Where do you draw the line - when is something no longer emulation?
A lot of Amiga expansion cards have CLPDs on them, Picasso IV, X-Surf 100 etc.
X1000 has has a Xilinx CLPD and the X5000 and A1222 boards appear have the same Lattice FPGA, AFAIK they are not user accessible resources, like on the Sam series, and are essential to certain functions of these boards.
Lots of funky emulation going on.
-
please, not another discussion if fpga is emulation or not!
No, no, don't stop! I'll get my popcorn.
-
Yes, Been out of the Amiga Loop for a minute, found the Mist and Order one from Germany yesterday! Thanks!!
-
I like the way uae allows system setup, yes I know FPGA is not software!
-
Devboards need to be relicensed to be used by end users so maybe not so cheap in the end. There are some devboards that the rest of the team are looking at for higher end models but the Cyclone 3 is not in production so the lower end models need custom design. Besides, the A600 and A500 lack some space for extras inside.
If I supply people with the software to program a off the self board for free, I don't see a need for license or re-license. I see nothing about license in this board or cheaper 40 buck dev-boaards!? http://www.robotshop.com/en/nexys4-ddr-artix-7-fpga-board.html?gclid=CIyjzvj3vdICFQkMaQod4UQFAA
-
If I supply people with the software to program a off the self board for free, I don't see a need for license or re-license. I see nothing about license in this board or cheaper 40 buck dev-boaards!? http://www.robotshop.com/en/nexys4-ddr-artix-7-fpga-board.html?gclid=CIyjzvj3vdICFQkMaQod4UQFAA
The reason I designed the FPGAArcade Replay board was non of the off-the-shelf boards were suitable. They also have a short lifetime.
Despite the problems I had with supply, making the board is the easy part. The FPGA and firmware design is a big task. The idea with the Replay system is that both software and hardware components can be re-used between cores - and this is starting to pay off now.
-
So, is all use of FPGA emulation?
Does something have to exist to be emulated?
Do you consider Indivision ECS an emulator?
Do you consider C64 DTV an emulator?
Do you consider Akiko an emulator?
Where do you draw the line - when is something no longer emulation?
You can build an emulator before you build the thing you're emulating.
Indivision ECS uses a real denise, so it's not emulation.
DTV emulates a C64.
Akiko emulates two CIAs.
Old dot matrix printers can emulate Epson and IBM dot matrix printers.
Old PC graphic cards could emulate CGA/EGA/Hercules graphics cards.
Soundcards emulate soundblaster.
There are grey areas, but emulating a CPU isn't one of them.
-
Then everything is emulation.
-
Then everything is emulation.
Only in a world of logical fallacy and trolling.
-
My Hat is off to you! I wish I had time to do these kind of things myself!!!
-
Yes, But Some is Hard and some is Easy(Soft).
If you program a FPGA to function as a Paula Chip yes you are emulating the Paula chip but at a Hardware level. Get over it already.... FPGA is the next best thing! Better than NOTHING!
)777(
-
Then everything is emulation.
Am I the only one who doesn't really care whether it is or isn't emulation?
I just look forward to considerably upgrading the computer I got as a seven year old and seeing what it can do after 30 years.
:)
-
Indivision ECS uses a real denise, so it's not emulation.
You can remove denise and your indivision will replace it. I don't care how you name it: emulation or reimplementation. Who cares? I would have loved amiga MMC+crussoe and Code morphing, this is the closest
-
If you program a FPGA to function as a Paula Chip yes you are emulating the Paula chip but at a Hardware level. Get over it already.... FPGA is the next best thing! Better than NOTHING!
The Paula chip is emulating bits of the original Lorraine prototype then. And AGA is emulation of ECS and OCS.
The point is - the chips are based on designs that you can implement with transistors, with chips, and most conveniently these days, with FPGA. Same for the CPU, implementations of designs.
Emulation is primary about translation and imitating behaviour. Ask Toni Wilen about how UEA works and how it is different than using FPGA.
-
Am I the only one who doesn't really care whether it is or isn't emulation?
Not at all. But I have yet to see emulation work as well as current FPGA options do.
I just look forward to considerably upgrading the computer I got as a seven year old and seeing what it can do after 30 years.
Remember to compare it with emulators then, see if you notice any differences.
-
Only in a world of logical fallacy and trolling.
I am not trolling, at best I am emulating a troll.
-
I am not trolling, at best I am emulating a troll.
Not trolling but voting you for number one making most senseless discussions
-
You can remove denise and your indivision will replace it. I don't care how you name it: emulation or reimplementation. Who cares? I would have loved amiga MMC+crussoe and Code morphing, this is the closest
You can even stack them for too independent displays.
-
Am I the only one who doesn't really care whether it is or isn't emulation?
:)
I also don't give a ...
But I like it how people fill pages full of text discussing the meaning of a word; especially given that meaning of language is non-deterministic anyway, depending on context and evolves over time.
-
So how do one distinguish between using FPGA and using UAE? You can see on this very thread how people are confusing the two, and it is even worse "out there" among more normal people.
-
i am not trolling, at best i am emulating a troll.
lmao.
-
The Paula chip is emulating bits of the original Lorraine prototype then.
It would be more industry practice to say the bread boards emulated the chips.
Emulation is primary about translation and imitating behaviour. Ask Toni Wilen about how UEA works and how it is different than using FPGA.
It's nothing to do with translation, it's only to do with imitating behaviour.
You're assuming that I don't know how emulators written for CPU's work and how emulators written for FPGA's work. I completely understand the difference between them, but they are still emulators.
CPU's are programmable, so are FPGA's. If the programs are both imitating behaviour then how are they not both emulators?
-
Not at all. But I have yet to see emulation work as well as current FPGA options do.
If you ignore latency then UAE works as well as any real Amiga or FPGA emulation.
So how do one distinguish between using FPGA and using UAE? You can see on this very thread how people are confusing the two, and it is even worse "out there" among more normal people.
You distinguish between then by the actual difference. If you need consistent timing and low latency then use real hardware or an FPGA, if you don't then UAE is just as good.
But I like it how people fill pages full of text discussing the meaning of a word; especially given that meaning of language is non-deterministic anyway, depending on context and evolves over time.
Which is why we don't need people trying to twist the words meaning for their own agenda by applying negative connotations to it. We may as well start referring to UAE as a Nazi.
-
Which is why we don't need people trying to twist the words meaning for their own agenda by applying negative connotations to it. We may as well start referring to UAE as a Nazi.
Is it not you who have an agenda by applying negative connotations ("emulator") to the item in topic here?
-
We may as well start referring to UAE as a Nazi.
none said uae or fpga were evil. there is difference of being serial (software) or parallel (hardware) in design. but obviously none is interested discussin it with either of you. ad advise you to take your discussion to pm or create a separate thread where you can quarel at will. leave this thread to people interested in vampire and apollo core. there is enough interesting things to report in contrary to your fruitless discussion.
apparently an own scan doubling solution for vampire:
http://apollo-core.com/knowledge.php?b=1¬e=4173&order=&x=0
new saga functionalities, planar support:
http://apollo-core.com/knowledge.php?b=1¬e=4191
attempt an opengl solution (library):
http://apollo-core.com/knowledge.php?b=2¬e=4142&x=0
-
We may as well start referring to UAE as a Nazi.
You seem to feel attacked by my words; not my intention. It's just that there is no one definition of emulation and the meaning differs by context and by person no matter how hard you claim there is one.
I found definition of emulation in online dictionaries that support your definition but I found also definitions that support the other people's interpretation.
-
Frankly, I'd have to emulate someone who gives a sh*t, to take a position on this one.
If it works, I'm fine with it, no matter what is under the hood.
-
Frankly, I'd have to emulate someone who gives a sh*t, to take a position on this one.
If it works, I'm fine with it, no matter what is under the hood.
I actually prefer the real hardware, even though it can be a pain. But WinUAE can also be a pain with all the options.
The best software emulation (for me at least) is Amithlon, as it's very close to the hardware, and actually uses some drivers that hit the real hardware.
Anyway, I think the Vampire will be in the same boat - it's a FPGA programmed as a super fast 68k. And it also uses real hardware and drivers. So to me that probably will be like Amilthon, in a way, in terms of how it feels. I have a Vampire 500 on order but I'm sure it will be a long wait still.
Darren
-
So to me that probably will be like Amilthon
leaving out evident issue of 68k software emu on x86 host, amithlon didnt provide amiga chipset functionalities. i bet this will make a noticeable difference.
-
I don`t quite see what Amithlon has to offer, WinUAE, FS-UAE and UAE4ALL have way better compatibility and functionality, not to mentional flexibility - as user you can decide yourself how much host OS you want under them. I use FS-UAE on my Powerbook daily, and for most productivity programs that works with RTG it is hands down the best option I have. But for games, animation and music where timing is critical, the only satisfying options are real Amiga, Minimig and the MIST.
-
Back to topic.
First, here is a quick video I made to demonstrate current GOLD3 WIP :
https://www.youtube.com/watch?v=Cyh6HClJK2c
Basically, we are now showing native Amiga chipset over HDMI.
Then, here is a quick and dirty screenshot of SimCity2000 AGA running on Vampire (yes, AGA is around the corner ;-) )
(http://i.imgur.com/0fcKV9o.jpg)
-
@TuKo
Sweet!
-
@TuKo
Sweet!
-
Back to topic.
First, here is a quick video I made to demonstrate current GOLD3 WIP :
https://www.youtube.com/watch?v=Cyh6HClJK2c
Basically, we are now showing native Amiga chipset over HDMI.
Then, here is a quick and dirty screenshot of SimCity2000 AGA running on Vampire (yes, AGA is around the corner ;-) )
(http://i.imgur.com/0fcKV9o.jpg)
To be clear Tuko this is the (WIP) re-implementation of the native Amiga chipset (including AGA) on the Vampire, and not taking the Amiga's own video into the Vampire for example with a Parasite board, correct?
-
Still needs that sweet FPU emulation for games like Quake, more optimized DOOM ports, etc.
-
Gunnar:
Some updates,
today we played with 16bit stereo playback feature of PAMELA.
:-)
The "chanel" is able to output stereo-16bit streams.
Which means it does process 2x16bit.
It also can fetch data 64bit wise from memory.
So if you want you can look at it as 32bit audio feature as it processes 2x16 bit per clock with 64bit data path. ;-)
http://www.apollo-core.com/knowledge.php?b=1¬e=5326&order=&x=5
-
I just received my Vampire 500 V2+!!!!
Now if only someone would be cool enough to send me a complete install with everything working so I dont have to start from scratch!!! Not looking forward to all that.
-
Oh no, you suffer like the rest of us.:rofl:
-
Oh no, you suffer like the rest of us.:rofl:
Right! WTH, Acill :razz: Besides, isn't getting it started all the fun?
I'm actually looking forward to trying mine out on an install. Mine's been sitting here since I got it a few weeks ago just staring at me. I *was* going to install it in my Red A500+, but that'll be a while. My 500+ has a Derringer in it. Guess that'll have to come out :D
-
Yeah, it will go in my personal red 500+ once I bu8ld it. I've tried it in an A2000 too. Will move to the cdtv next.
-
leaving out evident issue of 68k software emu on x86 host, amithlon didnt provide amiga chipset functionalities. i bet this will make a noticeable difference.
Being able to skip emulating different areas of memory and switching between emulating cpu/blitter/copper etc will make a huge difference.
Ditching the OS and letting all the memory accesses through to the hardware would require a bit of work, but you may be able to use the amiga pci drivers.
That would be the ultimate, something bootable that allows you to enable different JIT emulators 68k/ppc/arm etc that can then boot different OS.
-
https://www.youtube.com/watch?v=oYxEFUgWe1o
Vampire 600 V2 / GOLD3 bring-up - no more Turtle Mode
GOLD3 does not contain Turtle Mode for the stock a1200 speed. Here are a couple of WHDLoad games that will benefit of it. Audio and video comes through HDMI.
-
https://www.youtube.com/watch?v=oYxEFUgWe1o
Vampire 600 V2 / GOLD3 bring-up - no more Turtle Mode
GOLD3 does not contain Turtle Mode for the stock a1200 speed. Here are a couple of WHDLoad games that will benefit of it. Audio and video comes through HDMI.
That IS a good trick.
Congradulations.
-
https://youtu.be/1Q_rfkqPymg
Amikit
https://www.youtube.com/watch?v=WfWB0f1DI4c
-
https://youtu.be/1Q_rfkqPymg
Amikit
https://www.youtube.com/watch?v=WfWB0f1DI4c
What is Amikit X for vampire? Is a guide available to get it running on the vampire? I'd like to try it.
-
What is Amikit X for vampire? Is a guide available to get it running on the vampire? I'd like to try it.
I suggest you ask the author of the youtube video. I havent tested AmiKit myself to be honest, but it does look nice!
Amiga 1000 with Vampire V2-500, Apollo Gold 3 team test core.
A1000, with 4 meg ChipRam, AGA, HDMI Video out with Audio.
Meet Pamela the new audio out custom chip.
Youtube links
https://youtu.be/bOaD4EqD9MQ
https://youtu.be/z1RxmhV-4Bg
GOLD 3 Beta
Note the A1000 is loading game from SD card.
the A4000 is loading game over Samba share, this is why the load time is slower.
the comparison is to show the ChipRam and AGA are working on the Gold 3 core even on an A1000
-
https://vimeo.com/222892444
Quick Aros 68k Origyn Web Browser (OWB) test with Vampire 500 V2
Amiga 2000
Vampire 500 V2 (GOLD 2.5/Alternative Kick3.1)
Picasso IV
Ariadne Network card
-
Vampire 500 V2 (Gold 2.5) / MysticView 1.07 020_NoFPU
Vampire 500 V2 / Amiga 2000
Gold 2.5 with the alternative 3.1 Kick ROM
AmigaOS 3.9 BB2 (with ROM updates)
Prisma Megamix Zorro II
Ariadne Network card Zorro II
https://www.youtube.com/watch?v=hLR64W_8v_8&feature=youtu.be
GOLD3 bring-up. Stunt Car Racer
An Amiga 600 with the Vampire 600 V2 accelerator board.
https://www.youtube.com/watch?v=P5oVDYNd_ws
-
Now do a video of 4D Sports Driving (Stunts) please ;)
-
First SoftFPU tests with GOLD2 core
A very early Software Floating Point Unit bring-up for the 68k.
https://www.youtube.com/watch?v=jgW6B9dhkgQ
Its based on the work by Jari Eskelinen, which is being discussed here;
http://www.apollo-core.com/knowledge.php?b=4¬e=5931&x=0&z=jWL3Fm
-
Pretty weak. Why not just release the supposedly finished floating point unit?
And that heavily edited 'discussion' is so one dimensional.
-
Pretty weak.
Yes, but suddenly the old "there is a lot of software that will just crash if there is no FPU"-argument is gone. Pretty soon it's only going to be "but an 040/060 is faster at running non-882 FPU code". And I think getting the rough equivalent of a 50 MHz 68882 in a free software update is pretty nice. The last time I read something about purchasing those chips it seemed like they were pretty expensive and difficult to get...
-
Yes, but suddenly the old "there is a lot of software that will just crash if there is no FPU"-argument is gone. Pretty soon it's only going to be "but an 040/060 is faster at running non-882 FPU code". And I think getting the rough equivalent of a 50 MHz 68882 in a free software update is pretty nice. The last time I read something about purchasing those chips it seemed like they were pretty expensive and difficult to get...
That IS a valid point, and it IS adequate.
So, I'd revise my comments with a cautious congratulations.
It eliminates a talking point/point of contention.
-
So far I have got mine going well and the lack of an FPU isnt as bad as I thought it would be. I have the x-surf 100 and rapidroad working with it very well. Just needed to be sure and select the 68000 device drivers and say no to installing the custom ones when the installer askes. I also have a SCSI card working together with the IDE for a CD-ROM drive. This 2000 has never been better than it currently is.
-
So far I have got mine going well and the lack of an FPU isnt as bad as I thought it would be. I have the x-surf 100 and rapidroad working with it very well. Just needed to be sure and select the 68000 device drivers and say no to installing the custom ones when the installer askes. I also have a SCSI card working together with the IDE for a CD-ROM drive. This 2000 has never been better than it currently is.
That is a platform I can see the argument for fpu free operation on.
My own system topped out with an '020 cpu and a 68882 fpu.
The soft fpu should exceed to operation of that and the core is certainly faster than an '020.
So at this point, I may return my A2000 to service.
-
Hey I'm not going to move my opinionated goalposts if they do an update with the FPU in it. I've been rooting for the Vampire since it was just an A600 thing being knocked out in guy's bedroom. I'm happy to see forward progress on the FPU, rather than no progress at all and handwaving why there wasn't any. So, IMO, this is good, this is great!
-
I'm patiently waiting for the A1200 version myself. I'm hoping that they will release it before the end of the year.
-
For me, FPU emulation is a must. However I'd temper that by saying just the 040 FPU subset, which includes one or two operations missing on the 060fpu and be able to trap properly any missing ones so that a software solution is possible (ala oxypatcher).
To be fair, if the CPU core advertised itself as a basic 020 but silently supported the 040fpu and some other 040+ instructions like move16, lots of software would just work.
-
To be fair, if the CPU core advertised itself as a basic 020 but silently supported the 040fpu and some other 040+ instructions like move16, lots of software would just work.
From what I understand, no 68k CPU "advertise" itself, it's a matter of software trying to identify the CPU based on poking around :)
-
Vampire 600 V2 GOLD3 bring-up / Kioea by Mad Wizards (AGA/FPU-Demo)
Tested on an Amiga 600 with Vampire 600 V2 GOLD3 Beta + SAGA/SoftFPU. Audio and video are played through HDMI.
https://www.youtube.com/watch?v=q7Ye2c5K8GI
-
I dont understand the point of showing an 060 demo at this stage, just to show that "it runs" ?
Its completely unwatchable, the 3D engine runs at slide-show speed.
-
This is a beta preview. A snapshot of a work-in-progress.
-
I dont understand the point of showing an 060 demo at this stage, just to show that "it runs" ?
Its completely unwatchable, the 3D engine runs at slide-show speed.
I do. Clearly shows something key is missing from the acceleration experience in certain situations. So helps interested purchases see more views of performance.
Apart from that I agree with Karlos. Who?......
-
GOLD3 bring-up - Slam Tilt AGA
An Amiga 600 with the Vampire 600 V2 accelerator board. Audio and video are played through HDMI.
https://youtu.be/NRdxh_mVPTs
-
From what I understand, no 68k CPU "advertise" itself, it's a matter of software trying to identify the CPU based on poking around :)
A software fix that just sets the flags in Exec would be enough. The idea is, the CPU looks like a vanilla 020 and that's what is set. However, unlike a vanilla 020 it will silently support the 6888x subset of instructions from the 040 and in addition, some other useful ones like the cache line move. Note that this doesn't mean it needs to emulate it exactly, just move 4 long words at a time without touching any status register bits.
Most executables compiled for 040/060 don't specifically check for it and will work, albeit very slowly on 020/88x.
The CPU emulation in OS4 is similar to this. It looks like a basic 020 but silently supports almost every user mode 68k instruction/addressing mode.
-
I think it be better if Thomas forgot about Picasso96, instead of trying to sell obsolete API's, it be better if Hyperion made a small OS update for 680x0, and new ROM's (with full NSD64 support)and updated Graphics.library, this be good for developers to have common AmigaOS API on 680x0 and PowerPC.
Sure be lot more profitable to sell software to 680x0 and PowerPC users.
-
Valid point, P96 isn't essential. And a common base would be useful.
-
Sound and native resolutions over HDMI
AGA games:
- Street Racer
- Aladdin
- AGA Gloom
- Slam Tilt
- Super Stardust
https://www.youtube.com/watch?v=17mW05leF6A&feature=push-u&attr_tag=XIJ_QqNElX6i1CJH-6
-
https://www.youtube.com/watch?v=TnaghxqdCk0&feature=youtu.be
Dirt by Mystic (AGA)
release date : october 1994
release party : Intel Outside 1994
http://www.pouet.net/prod.php?which=12460
-
Testing of legacy MOD playing with PAMELA AUDIO Chip, which support 24bit mixing precision plus 4-times oversampling. Optional STEREO separation is enabled, it's better for headphones.
https://www.youtube.com/watch?v=o_p5uGbeh98
femu 0.10 + GOLD3 core test / Metropolice
(https://s4.postimg.org/sy9q6huj1/metropolice.png)
https://youtu.be/SqFwz8Uqa74
-
I need GOLD3 on my Vampire now!! ;)
-
Running Metropolice demo on Vampire 600 + AA core (gold3-alpha x11) with CPUMon080 displaying realtime usage of the CPU pipes.
https://www.youtube.com/watch?v=N8OYCUnkuqA
-
agreed. this looks awesome!
-
That is SO cool. Legacy Amiga can now handle modern sound standards!
Keep this kind of stuff coming, the capabilities are very useful.
-
That is SO cool. Legacy Amiga can now handle modern sound standards!
Which standards are those?
Or to be more specific - modern sound processing applications do mixing in 32bit or 64bit internally, and ... floating point at that.
I don't quite see what this AGA demo has to do with any of that?
-
Its the speed its being handled at. That is the impressive thing here. If you dont like the Vampire you dont have to use it.
-
Which standards are those?
Or to be more specific - modern sound processing applications do mixing in 32bit or 64bit internally, and ... floating point at that.
Google the meaning of the word "standard".
-
Which standards are those?
Playing MP3s and multitasking while playing MP3s, is what I'm guessing.
-
Hey, kolla's gonna hate, whatcha wanna do?
-
Which standards are those?
Or to be more specific - modern sound processing applications do mixing in 32bit or 64bit internally, and ... floating point at that.
I don't quite see what this AGA has to do with any of that?
They CAN, but usually DON'T. In the meanwhile, 24bit vs 8 bit...
BTW - You're a big fan of Jen's hardware, SO what kind of sound improvements do you get when you install one of Individual's accelerators?
Oh yeah...none.
That would be 1 vs 0, in favor of the Vampire! :hammer:
-
They CAN, but usually DON'T. In the meanwhile, 24bit vs 8 bit...
Well, they typically do, have done so for quite a while. I was just curious what audio standards you were thinking of, and how that related to a 7 year old AGA demo.
BTW - You're a big fan of Jen's hardware, SO what kind of sound improvements do you get when you install one of Individual's accelerators?
Jen? You mean Jens? No, I am not a big fan of his accelerators, what gave you that impression? Only ACA card I have is the A1221, which I bought for hacking. I just found it ironic that after all the moaning and whining about price of iComp cards, the "team" now find themselves in the situation where their cards are just as expensive, and are likely to cost even more in the future with the V1200. It is all fair though, cost is not so much the parts as it is production.
Ah, but they offer so much more, you say, and refer to all that may or may not come in the future. Remember what Gunnar has said about that.
Oh yeah...none.
Well, his products tend to come with "fast clock port" to which you can attach USB controller that gives you access to audio equipment, such as sound cards, hardware decoders, hardware encoders, mixers and MIDI equipment.
That would be 1 vs 0, in favor of the Vampire! :hammer:
Depends entirely on your use case.
As I may have mentioned, the major reason for me being less than satisfied about the FPU situation is exactly audio processing. How do you deal with floating point data, like audio, when you don't have floating point unit? Rounding up, rounding down, compromise on speed and quality all the time.
-
Hey, kolla's gonna hate, whatcha wanna do?
Hate? I have no hate in this, stop abusing that word, it has a purpose and washing it out is doing no-one any good.
-
I DO wholly agree with you that the floating point issue is vexing.
And Gunnar has proven over the years to be a bit 'eccentric'.
But I'm interested in the performance they are getting out of the Apollo core.
It's a real boon to A2000 owners as the options for those machines have traditionally relied on the CPU slot.
For the A500...there are more alternatives.
And I really don't like the method of attachment for the A600.
Then again, outside of IDE, that system doesn't have much to offer that would make it attractive.
And while I have taken a few shots at Jens, his A1200 project has my attention.
Then again, all of this is just a side interest for me, as I moved on to NG a long time ago.
-
Until the official post by Tuko is out of moderation;
http://forum.apollo-accelerators.com/viewtopic.php?f=8&t=1804
After the big success of the Vampire 600 V2 and Vampire 500 V2+, Apollo Team is proud to announce their next generation FPGA device: the Vampire V4.
The Vampire V4 is made with a standard “one design to fit them all” and comes in three flavors depending on customer need:
The Vampire V4 Standalone System
The Vampire V4 for Amiga Classic compatible with
Amiga 1000/500/2000/CDTV
Amiga 600 with kippa’s adapter (if produced)
The Vampire V4 for Amiga 1200
This new Vampire V4 packs many upgraded specifications and brings Amiga Classic systems to another new performance paradigm thanks to its new Altera Cyclone 5 A5 FPGA and fast DDR3 memory.
The Vampire V4 standalone system will be a complete new Amiga system powered by the 68080 CPU core and the complete SAGA chipset (AGA compatible).
Vampire V4 is powered by:
FPGA : Altera Cyclone V A5 (77k LE, 28nm technology)
RAM : 512MB DDR3 (up to 1GB/s)
And supports:
FastIDE with 40/44-pin connectors
Digital Video-out up to 720p@60Hz
Dual Kickstart-flashrom (for safety)
MicroSD Storage
Certification: Vampire V4 is CE, WEEE and RoHS compliant
(http://www.apollo-accelerators.com/images/v4.jpg)
PCB is populated by:
1. IO Header #1
2. IO Header #2
3. IO Header #3
4. Ethernet
5. USB
6. USB
7. DB9 (standalone only)
8. DB9 (standalone only)
9. FastIDE 40-pin
10. FastIDE 44-pin
11. FPGA
12. Digital Video Amplifier
13. Digital Video Output
14. DDR3 RAM
15. JTAG Header
16. MicroSD slot
17. MicroUSB Power (standalone only)
All other details are documented in attached PDF.
Apollo Team wishes you a GREAT summer :-)
-
Vampire v4 looks awesome, still waiting for my vampire v2 was mailed a month ago no tracking number have me quite nervous.
I could prefer pay extra and have it EMS shipped, Majesta should add a shipping option to the online form.
Vampires are rare and the wait list is long, if lost in the post i will have to cut my bal*s off :P
-
Oh dear. 1 month shippingtime doesnt sound promising at all :(
-
just keep it together man :D
my Vamp 500 took a good while to turn up after I got the "it's been posted" email.
I had "almost" :lol: forgotten about it until one day, there was a package on the kitchen counter with "amiga memory" hand written on the invoice description.
suffice to say, I became rather "busy" that evening and following weekend.
It'll get there
-
a 32gig disk image for vampire users. has most demos/emulators/games general show offy stuff for your new super fast machine
http://apolloos.weebly.com/
games and other bits for Vampire and higher spec miggys (060/RTG/W3D)
https://artishq.wordpress.com/
-
RiVA MPEG-1 player test with Vampire 500 V2 (GOLD 2.7/x15)
Another nice update to the RiVA from Henryk Richter. Powered by AMMX.
SAGA YCbCr422 Color Mode / MPEG-1 848x368 23,976fps VBR 2000 kbps, Layer-1 44100Hz 128 kbps%&$#?@!%&$#?@!%&$#?@!65279;
https://www.youtube.com/watch?v=9eGc6aYcmXg&feature=youtu.be
-
(http://www.apollo-core.com/gfx/GOLD27a_MFlops.png)
FEMU by Jari running on Gold 2.7.
Gunnar hopes/expects that to improve to 3-4 MFLOPS.
And then you have the comment that V4 will have FPU on its own.
-
a 32gig disk image for vampire users. has most demos/emulators/games general show offy stuff for your new super fast machine
http://apolloos.weebly.com/
games and other bits for Vampire and higher spec miggys (060/RTG/W3D)
https://artishq.wordpress.com/
nice links, thanks for posting:)
-
Gunnar hopes/expects that to improve to 3-4 MFLOPS.
And then you have the comment that V4 will have FPU on its own.
Gunnar's latest test shows 3.82 MFlops, so its getting there. :)
-
Gunnar's latest test shows 3.82 MFlops, so its getting there. :)
Make that 5.23. MFlops.
-
Make that 5.23. MFlops.
How does this compare to a 68040?
-
How does this compare to a 68040?
(http://eab.abime.net/attachment.php?attachmentid=27726&d=1296481555)
A3640@33
(http://eab.abime.net/attachment.php?attachmentid=27730&d=1296481571)
Apollo 1240@25
(http://eab.abime.net/attachment.php?attachmentid=27731&d=1296481575)
Apollo 4040@40
Just a few I found on "Performance Gather 2011" thread somewhere else.
-
When are people going to stop using SysInfo? Love how there are much beter benchmarks available and how no one uses them. Typical.
-
Quoted from Gunnars post on apollo forum;
There is a significant FPU performance speed increase in
GOLD 2.7 and latest WIP FEMU.
In some real world FPU benchmarks even results
outclassing 68882 FPU, beating 68040 FPU,
and reaching the speed of 68060+FPU
are achieved.
(http://www.apollo-core.com/gfx/GOLD27_FEMU_FMatrix.jpg)
-
another video with aros on vampire2:
https://www.youtube.com/watch?v=1BbWA8fhgHc&feature=youtu.be
only skipped through it, but it contains a number of apps also amiga ones and the performance looks rather acceptable, except for a few times when it hangs a bit.
-
We should not be surprised that AROS runs better when using chunky modes. That's what it's designed for.
-
Copy paste from Apollo forum;
http://apollo-core.com/knowledge.php?b=1¬e=9840&z=RZQtVG
It’s been a while since release of GOLD2 in January 2017. Apollo Team has been working hard on different topics in parallel to bring Amiga users a great experience with their current and future Vampire accelerators. Let’s sum up a bit what are working on and what is coming next.
-- GOLD2.7 – « The number after the point » release --
Since GOLD2, lot of work has been made on the 68080 core. Even if we released an experimental and interim build called GOLD2.5 which added support for SDNet and library for developers, core part was still GOLD2.
Right now, Apollo Team is working quite hard on testing GOLD2.7 core which will be a major update since GOLD2. The number is small but the changes are big :
- AMMX2 : AMMX has been improved with a full new set of vector instructions
- Full rewrite of the RTG graphics driver, optimized to get benefits from the AMMX2 instruction set
- Added FastIDE functionnality (to speed up Amiga 600 on-board IDE)
- Added hardware sprites support
- Exec now handles AMMX context switching
- Added MapROM functionnality (brings EmuTOS/FreeMint/AROS for example)
- Added hybrid software/hardware FPU (with help of FEMU)
- Added HyperThreading support
- Added Bn register (E0 to E23: Data registers, fully 64bits, accessibles by AMMX)
- Added vampire.resource for developers
- Added processor.resource for developers
- Added BANK instruction
- Speed up of memory clock frequency
This GOLD2.7 will be the last core before the awaited GOLD3 core and will be released for Vampire 600 V2, Vampire 500 V2 and the upcoming Vampire V4.
-- GOLD3 – Lady SAGA on stage --
In parallel to GOLD2.7, lot of efforts have been put into bringing AGA to the 68080 core. Testing methodicaly every single known AGA games to understand how they work and create SAGA as not only an AGA reimplementation but getting it to the next performance level takes a very very long time.
The beauty behind SAGA is the speed benefit brought by the FastRAM speed to ChipRAM. With GOLD3, any AGA screen is fast. Superfast Workbench in PAL feels like your Amiga was waiting for some new fresh air. GOLD3 removed the handbrake.
GOLD3 will also make life easier for everybody as you will be able to use a single digital cable for both AGA/RTG and audio.
The dream of bringing AGA to all OCS/ECS Amigas is being a reality with GOLD3. Remember when you were young how frustrated you were with your A500 when you couldn’t run an AGA game that your friend with A1200 could ? This time will soon be over.
-- Vampire V4 --
Team work has the benefit to let us have several open tasks at the same time without having to finish them sequencially. Vampire V4 was designed silently by ceaich while work continued on the core side. Announced in August and still aiming for a general release in Q4’2017, the Vampire V4 will be a next step into the further development of a standalone product.
We were very impressed seeing how mainstream IT websites relayed the information. It means a lot for us and we are pretty confident that the product could bring old users back into the Amiga scene. That coverage has put a lot of pressure on our shoulders but is also very exciting as we are discovering new lands that were never explored until now.
Small correction by Henryk Richter
Small correction: The Exec bundled with Gold2 and 2.5 had AMMX context switching already built in.
New is: Our new VampireSupport Kickstart module enables AMMX context switching on the fly. So far, Exec 40 (3.1), Exec 45 (3.9BB2) and Exec 34 (1.3) have been successfully tested with the new approach.
-
Some of you might remember the somewhat (very?) laggy Kioea demo a while back.
Now with updated femu 0.11-WIP) and Gold 2.7.
femu 0.11-WIP is Apollo core optimized version (includes HW 040 and 060 FPU).
Kioea demo;
https://www.youtube.com/watch?v=dtCWfmnYOsk
And now for the "benchmark" many use on Amigas; Quake;
https://www.youtube.com/watch?v=OuvwUCNnXl8
FYI; I merely copy paste this info from Apollo Forum. Originally posted by Simo/ShK
-
Amazing :) Always progress always forward. Such a nice fresh breath of air in the amiga comunity.
But now que comments about missing MMU in 1...2........
-
But now que comments about missing MMU in 1...2........
It's not missing, please pay attention.
-
It's not missing, please pay attention.
Sorry can't keep up with the trolls.
Now it's more like.. But still no 68040 compatible mmu..... Right? Or are we past that to?
-
A bit more painful fpswise, but its working!
AmiQuake2 1.06 RTG on GOLD2.7 WIP
https://www.youtube.com/watch?v=oCvydjZVqO4
-
Sorry can't keep up with the trolls.
You should keep up with what the lead developer of the Apollo Core is writing and saying, it is more than a year ago he explained that the Apollo has its own MMU, and why it is what it is. And noone has any problem with that either, but there is a problem if it remains closed, which appears to be the case.
Now it's more like.. But still no 68040 compatible mmu..... Right? Or are we past that to?
Being compatible with 68040 MMU doesn't make much sense, since noone is planning to use the Apollo Core along with a 68040. By not being compatible with existing software that uses 68k MMU, the apollo core is missing out on many opportunities, but considering what it is used for (to host Amiga OS on alien hardware), that is understandable.
-
Btw - "femu 0.11-WIP is Apollo core optimized version (includes HW 040 and 060 FPU)" - what does that mean? HW as in hardware? So, the Apollo Core for V2 now has a 040/060 level FPU (something that was cancelled earlier), and all FEMU 0.11-WIP does is trapping the remaining instructions, very much what the 68040/060 libraries do? If so, maybe it should be implemented as a 68080.library?
-
@Nickman
You know, we might be fussed at time that some people are being overly negative about Vampire, but it doesnt help poking people in the eye at every oppurtunity.
I might not agree with all of kollas comments/view of roadmap, but he does have some good questions overall.
@kolla
grond made a comment on EAB;
"This is the relevant part: "includes HW 040 and 060 FPU".
But the HW FPU parts are still throtled for testing. "
http://eab.abime.net/showpost.php?p=1193992&postcount=167
-
Posted by Gunnar on Apollo forum;
http://www.apollo-core.com/knowledge.php?b=1¬e=10848
Hello Coders,
GOLD 2.7 will come with AMMX2 instruction set.
Please find here a preview of the AMMX Quickreference chart:
CLICK HERE
http://www.apollo-core.com/AMMXQuickRef.pdf
-
Amiga 600 vampire 2 Gold 2.7 testing: Elude - Soliloquy
Camrecording by Mr-Z, so not the most flawless demostration, but shows the performance of the 2.7.
https://youtu.be/xEtd8td2a7o
Amiga 600 Vampire 2 X11 core Gold 2.7 Hires Quake 640X400
https://www.youtube.com/watch?v=GpqSUCm1Fcg
Amiga 600 vampire 2 Gold 2.7 testing: Elude-We Come In Peace
https://www.youtube.com/watch?v=KHFgEo4Ir3Q
-
Thanks for the videos.
What is the framerate in Quake? Can you run a timedemo please.
-
I dont have access to Gold 2.7, so ask Manuel these things via youtube.
Updated play with X12 core:
X12 core
https://youtu.be/w2S4suHf-l8
-
http://www.apollo-core.com/knowledge.php?b=4¬e=11558
Last night we started to play around with some texture mapping code.
Here is a very early result:
http://www.apollo-core.com/gfx/V3_demo34.mp4
The screen is rendered in 640 pixel width.
The texture routine uses bilinear texture filtering.
https://en.wikipedia.org/wiki/Bilinear_filtering
more to come
-
http://www.apollo-core.com/knowledge.php?b=4¬e=11558
Goodness! What's next - mip mapping? :)
-
Well, that's far from smooth...
-
Well, that's far from smooth...
And the texture demo won't even run on a stock Amiga, so what's your point? Was your post simply to reconfirm that you're a Vampire troll, or reconfirming that you're trolling the Vampire?
-
a stock Amiga
Always comparing with "a stock Amiga", I am sure you could aim higher :)
so what's your point? Was your post simply to reconfirm that you're a Vampire troll, or reconfirming that you're trolling the Vampire?
Not at all. As I have repeated for you over and over again - is it not the hardware I have issues with, not the Vampire.
My point is that it was far from smooth, and I am sure the Apollo Core will now be trimmed and the routines hand optimised to fit exactly this use case so that it will be smooth.
-
My point is that it was far from smooth, and I am sure the Apollo Core will now be trimmed and the routines hand optimised to fit exactly this use case so that it will be smooth.
Not quite clear to me what your point is. Of course, if you optimize to a particular target, you get better results. The instruction set has - possibly - been optimized for this particular use case, and the assembly has been particular been optimized to take maximum advantage of the extended instruction set. That seems to be completely legit to me, no problem.
The question would be how generic the instructions are so they can be carried over to another use case. I cannot answer that, but as far as I know, the instruction set is documented, so you can check.
Or, to put it in a different way, all the extended instruction sets of the x86 where obtained in exactly this way, namely by looking at particular use cases (such as 3D rendering) and providing short cuts for exactly such cases. Looks all fine to me.
-
Always comparing with "a stock Amiga", I am sure you could aim higher :)
Again, what's your point? Not smooth compared to what, a PC with an nVidia GTX 1080 card or an X5000 with a Radeon card? The demo is pretty good considering it's all being handled by a CPU with no GPU support, but as usual everything you post in regard to the Apollo core or the Vampire is negative. The Vampire is designed as an upgrade for stock Amigas, so the only reason I'd aim higher is if I was throwing rocks at your head instead of your feet.
-
Well, that's far from smooth...
Actually it's quite impressive if you understand what you are seeing. You may have noticed that in the video smoothness changes with the rotation angle of the texture. This is because the texture is too large to fit into the dcache. This means that the texture needs to be fetched from RAM. The burst reading and the cache prefetching of the 080 are reading ahead in the texture in an attempt to have the next texel ready when needed. This works well when the texture is traversed in a direction matching the cache prefetch and not so well when the texture is traversed backwards. This can be remedied quite easily by using four textures prerotated by 90 degrees so that you can always traverse the texture in a forward direction by picking the right prerotated texture. This is a common trick in texture mapping.
Summing up: we see that texture mapping in hires and with bilinear filtering can be done by the 080 and with a decent frame rate. Not bad for a 90 MHz CPU...
-
That is a very cool demo indeed. I thought it was very smooth except for the cache burps as noted. It really shows off the potential.
Looking forward to V4 with more memory and memory bandwidth. It only gets better from here. :)
-
Here's another update from Gunnar and his texture mapping demo:
Gunnar von Boehn
(Apollo Team Member)
Posts 3017
12 Dec 2017 21:08
Little update
Video:
Click here: http://www.apollo-core.com/gfx/V3_demo124_fox.mp4
The above video uses compressed textures.
In real time the texels are decompressed and bilinear filtered to create calculate screen.
Screen resolution is 640 Width.
Screen bitdepth is 16bit HICOLOR
The ASM rasterizer loop was tuned to be benefit from Super-Scalar and Fusing better, as you can see framerate is very smooth now.
-
The ASM rasterizer loop was tuned to be benefit from Super-Scalar and Fusing better, as you can see framerate is very smooth now.
See? Now it is much smoother.
And again, new instructions have apparently been implemented in AMMX, DXT1 and PIXMRG.
Of course these are not described in http://www.apollo-core.com/AMMX.doc.txt yet.
-
See? Now it is much smoother.
This phenomenon is called "progress". And since you didn't like the previous video, you certainly are happy about it. And again, new instructions have apparently been implemented in AMMX, DXT1 and PIXMRG.
So you gather this much: these instructions are useful because they make texture processing much faster. PIXMRG even has many more uses as it mixes two sets of 8bit data.
Of course these are not described in http://www.apollo-core.com/AMMX.doc.txt yet.
I'm sure in everything you do, the documentation is always at the same level as the actual implementation...
-
Some uploads to Vimeo.
Unique “Singularities” Amiga AGA Demo (Vampire 600 V2)
GOLD3 internal beta core for Vampire FPGA Accelerator. Realtime capture from Amiga 600 (HDMI, both audio and video 720x576@50) with StarTech PEXHDCAP.
https://vimeo.com/247808964
http://www.pouet.net/prod.php?which=69702
Unique “Subside” Amiga AGA Demo (Vampire 600 V2)
GOLD3 internal beta core for Vampire FPGA Accelerator. This demo runs in 640x160 HAM8 screen (15bit). Realtime capture from Amiga 600 (HDMI 720x576@50) with StarTech PEXHDCAP.
https://vimeo.com/247800614
http://ada.untergrund.net/?p=demo&i=853
http://www.pouet.net/prod.php?which=67140
-
What are those ugly horizontal lines on the image, bad capture ?
-
What are those ugly horizontal lines on the image, bad capture ?
Those are fake scanlines.... i really hope they will be optional in the final release...
-
The non-endorsement of ApolloOS by the Apollo Team :)
http://www.apollo-core.com/knowledge.php?b=5¬e=11776&z=tLdgmc
Quotes by Gunnar von Böhn himself:
As OS download APOLLO_OS
But some users might only know AMIGA OS 1.2/1.3... for them having a pre-installed system is very helpful.
-
Looks nothing like scanlines to me, and I'm still using a 1084 monitor with all my Amigas.
What I hope they make optional is the AGA output through HDMI.
I want to keep using the Amiga's chipset and analog video.
-
Looks nothing like scanlines to me, and I'm still using a 1084 monitor with all my Amigas.
What I hope they make optional is the AGA output through HDMI.
I want to keep using the Amiga's chipset and analog video.
It would require some kind of magic trick to get AGA going out through the RGB output with the current Vampire cards, Especially through the respected OCS/ECS chipsets. HDMI is what you got, if you want OCS/ECS going through Analog sure you can just use the native chipsets, AGA will have to be HDMI only.
-
Guess I wasn't clear enough, what I meant is to make AGA emulation optional.
I'm mainly thinking about Vampire for A1200 here.
-
Guess I wasn't clear enough, what I meant is to make AGA emulation optional.
I'm mainly thinking about Vampire for A1200 here.
Most likely can just fall back to Lisa via software.
-
Atari ST emulation on a V600 Gold Core 2
https://www.youtube.com/watch?v=kJHSDnRH3AU
-
Some more demos tested on Gold 2.7
Elude “We Come In Peace” Amiga AGA/RTG Demo (Vampire 600 V2)
https://vimeo.com/251163888
Elude “Lightshaft” Amiga RTG Demo (Vampire 600 V2)
https://vimeo.com/251034564
EPH&KVG&RNO&CF “Software Make the Dance Foam Oil” Amiga AGA/RTG Demo (Vampire 600 V2)
https://vimeo.com/251155969
AMMX enabled datatypes in the works;
http://www.apollo-core.com/knowledge.php?b=1¬e=12181
-
Our AMMX sorcerer Bax did it again !
To show how much AMMX can benefit AmigaOS3 applications and OS, he implemented AMMX decoding instructions into the good old JPEG datatypes.
Results are impressive.
To benchmark it, we used benchmarking protocol used on WarpDT website and current GOLD2.7 WIP :
http://www.warpdt.co.uk/jpeg.html ("visage jordan199b.jpg nojpeg time test". )
and we went from 1.759s
(https://i.imgur.com/O2zlJGW.png) (https://i.imgur.com/O2zlJGW.png)
to a whooping 0.723s !
(https://i.imgur.com/O4pw4uo.png) (https://i.imgur.com/O4pw4uo.png)
You read it right, we are faster at 70MHz than a A1200 603e/240MHz used on original benchmarks.
This new addition to a growing AMMX software collection demonstrates how much AMMX can benefit every part of our beloved OS. Any application using datatypes will instantly benefit from this, like our preferred OS3 browsers.
-
Love the icon set and tool bar icons. Amiga OS is with out a doubt the most configurable OS. Yes you can get fancy Eye candy for windows but I find it bogs it all down.
-
Love the icon set and tool bar icons. Amiga OS is with out a doubt the most configurable OS. Yes you can get fancy Eye candy for windows but I find it bogs it all down.
Ditto - That desktop looks beautiful!
-
Awesome!
-
Nice icons!
-
Sweet desktop . . . I want one! :)
-
Descent Freespace on Vampire 2 Amiga 600 RTG X12 BETA Core
https://www.youtube.com/watch?v=KZn_qD9t0Is
-
GOLD2.7 WIP - FPU showcase with Cosmos Quake 1.10
https://www.youtube.com/watch?v=jpdl5Ek_Rhk
-
Arts latest update to his Patreon page;
https://www.patreon.com/ArtiGamesAmiSoft/posts
NetSurf has got now Ammx2 accelerated jpeg decoding.
Since it uses Ammx2 ,it is going to be released with Gold2.7 core.
(40% faster jpeg loading).
GnuBoy Ammx optimised version of GameBoy Color emulator.
(Works fully and faster than aminet version).
PocketSNES fully working Super Nintendo Entaritainment System emulator.
(Needs optimizations but simple games like Super Mario World are playable).
GnGeo NeoGeo SNK emulator.
(Fully working , needs optimisations ).
And a secret game.
-
Artur Jarosik's GOLD2.7 WIP - GnGeo port work in progress (Partially optimised with AMMX2), video recorded by Tuko
http://www.apollo-core.com/knowledge.php?b=3¬e=12560
https://www.youtube.com/watch?v=_WGpP2MOKUE
-
Some more p0rn movies:
Two great videos showing NEO-GEO
FPS is very good now.
Over 50 FPS.
https://youtu.be/d8YIUTmdUIc
https://youtu.be/e9hHUZw2-J0
-
Yeah, amazing what difference having an FPU can do, huh?
-
Yeah, amazing what difference having an FPU can do, huh?
Eeegh... no, its AMMX... the thing no1 would ever use... do you remember or should you be quoted ?
-
Pretty sure I saw Metal Slug that uses FPU.
And you can quote me on not caring one bit about emulators that run so much better on other, cheaper and more available hardware.
-
Eeegh... no, its AMMX... the thing no1 would ever use... do you remember or should you be quoted ?
Lol! :rofl::rofl::rofl:
-
Pretty sure I saw Metal Slug that uses FPU.
And you can quote me on not caring one bit about emulators that run so much better on other, cheaper and more available hardware.
That was mini-slug an open source Metal Slug clone.
I think you care otherwise you wouldn't go on offensive anytime there is a mention of things going on with the Vampire/Apollo team.
-
Pretty sure I saw Metal Slug that uses FPU.
And you can quote me on not caring one bit about emulators that run so much better on other, cheaper and more available hardware.
Yeah Metal slug port does use FPU... the one that was never going to see day light according to you... remember ? You are too funny to be true...
-
I've not been keeping up so apologise in advance.
Does the Apollo core have a standard FPU now or does FEMU still have to be used?
-
I've not been keeping up so apologise in advance.
Does the Apollo core have a standard FPU now or does FEMU still have to be used?
This statement is for the current Vampire V2s out in circulation, Gold 2.7 will release will come with a full FPU solution, FEMU isn't needed. when Gold 3 is released it will have AGA and other features, so a full FPU solution can't fit at the same time, FEMU can be utilized here. Lucky it's an FPGA and you can easily switch just by reprograming it and reboot with a single mouse click in WB or Amigashell if you prefer.
For the upcoming V4s the FPGA is much larger and can utilize both the AGA, Pamela audio and the full FPU at the same time.
-
Yeah Metal slug port does use FPU... the one that was never going to see day light according to you... remember ? You are too funny to be true...
Please go ahead and quote me - I was quoting Gunnar, who said it was never going to see the light of day. When I bought Vampire cards (one year ago in a few weeks), the FPU was "just around the corner", and so it looks like it still is.
And not only that, he also said no-one really needs FPU, and anyone thinking otherwise is an idiot.
-
This statement is for the current Vampire V2s out in circulation, Gold 2.7 will release will come with a full FPU solution, FEMU isn't needed. when Gold 3 is released it will have AGA and other features, so a full FPU solution can't fit at the same time, FEMU can be utilized here. Lucky it's an FPGA and you can easily switch just by reprograming it and reboot with a single mouse click in WB or Amigashell if you prefer.
Oh nice, new important information - so one will have to chose between SAGA (Gold Core 3) or FPU (Gold Core 2.7). And of course the "full FPU solution" involves trapping of 68882 FPU instructions and feeding them to a software emulator, akin to those pesky 68040/68060 libraries who were so evil a few months ago.
Or is SAGA now out, and just "ordinary AGA" is "it"?
-
Gunnar is also really sarcastic at times, especially on IRC.
-
I think you care otherwise you wouldn't go on offensive anytime there is a mention of things going on with the Vampire/Apollo team.
The same way I care for taking part other sorts of entertainment :)
-
Oh nice, new important information - so one will have to chose between SAGA (Gold Core 3) or FPU (Gold Core 2.7). And of course the "full FPU solution" involves trapping of 68882 FPU instructions and feeding them to a software emulator, akin to those pesky 68040/68060 libraries who were so evil a few months ago.
No SAGA will be on both, AGA features will be on Gold 3.
It's a real FPU solution, no software emulation. Stop spreading %&$#?@!%&$#?@!%&$#?@!%&$#?@! you don't know.
-
Gunnar is also really sarcastic at times, especially on IRC.
It was not sarcasm. It was frustration over the quality of work of those who had the task of implementing the FPU, as he realised he would have to to it himself, something he had no interest in. He would much rather work on the shiny new FPU on the V4. There was quite a raging discussion about this within the team at the time, though they now pretend it never happened.
-
No SAGA will be on both, AGA features will be on Gold 3.
As SAGA is supposed to be a superset of AGA (Super AGA), this makes zero sense.
Sounds like you confuse SAGA with P96 RTG support, which as "working title" goes by the name "SAGA".
It's a real FPU solution, no software emulation. Stop spreading you don't know.
So full support for _all_ 68882 instructions in the FPGA? That is news, as Gunnar has previously said it will only support those of 040 and 060.
-
As SAGA is supposed to be a superset of AGA (Super AGA), this makes zero sense.
For reasons I don't understand SAGA was chosen for the name of the RTG graphics that come out of the HDMI interface. Gold 2.7 will still have that with ECS/OCS still coming out of the RGB port.
Gold 3 will introduce actual AGA support and the new Pamela sound chip over HDMI.
Maybe with the V4s it will make a bit more sense being called SAGA.
-
For reasons I don't understand SAGA was chosen for the name of the RTG graphics that come out of the HDMI interface. Gold 2.7 will still have that with ECS/OCS still coming out of the RGB port.
So nothing new, just at last an FPU of some sort.
So you have no information on whether it will fully implement all 68882 instructions and features on the FPGA, or whether it trap those that are not implemented and feed them to a software emulator, like is done with 68040 and 68060 using their respective libraries? There was such a hoopla over how utterly crap solution it was to need such libraries, yet from what I can see, they're doing the exact same thing themselves.
Gold 3 will introduce actual AGA support and the new Pamela sound chip over HDMI.
So Gold3 will introduce actual SAGA.
I guess there isn't any news after all then, just confusion and hyperbole (AMMX, AMMX2, AMMX2 + undocumented functions... which never seems to settle).
-
So nothing new, just at last an FPU of some sort.
So you have no information on whether it will fully implement all 68882 instructions and features on the FPGA, or whether it trap those that are not implemented and feed them to a software emulator, like is done with 68040 and 68060 using their respective libraries?
As far as I got it, all of the FPU right now is just pure software anyhow, which might be fast enough, though. Given the amount of complexity, and the (in)-frequency of use of the transcendent functions, it is likely that at least the latter part remains in software for quite a while, as for the 68040 and 68060, though probably in a somewhat more robust way (i.e. no external library required). However, as far as I got the story, the integrated FPU is 64 bit only, which is again *often enough* sufficient, but not necessarily always.
-
So nothing new, just at last an FPU of some sort.
So you have no information on whether it will fully implement all 68882 instructions and features on the FPGA, or whether it trap those that are not implemented and feed them to a software emulator, like is done with 68040 and 68060 using their respective libraries? There was such a hoopla over how utterly crap solution it was to need such libraries, yet from what I can see, they're doing the exact same thing themselves.
I can't say for sure, this is what I've seen:
http://www.apollo-core.com/knowledge.php?b=4¬e=12178:
"In Gold 2.7, an MC68882 compatible set of FPU instructions will be available at boot time. It won't be necessary to load 68040.library or femu."
I guess there isn't any news after all then, just confusion and hyperbole (AMMX, AMMX2, AMMX2 + undocumented functions... which never seems to settle).
What do you expect from a small time development team working on this in their spare time. These guys have day jobs. Proper documentation can come when they solidify their cores.
-
I am reticent to criticize the Apollo team given the voluntary nature of the project.
Still, it seems they change direction from where they previously stated they were headed, or so it seems.
-
Gunnar is also really sarcastic at times, especially on IRC.
Unlike Kolla, I'm pretty sure Gunner regularly uses sarcasm.
BUT, around you demanding whiners, can you blame him?:hammer:
-
@kolla: what point is there to explain things if you never understand them or intentionally omit the information provided?
68882-support: As has been explained many times before, the important difference is that all 882 instructions will work from cold-boot. Even though some instructions are emulated (V4: anything that is 882 but not 040, V2: a few instructions more), the emulation code is similar to a ROM but not only write-protected but also not visible to user code running on the CPU. This is a much better solution than the 680x0.library approach which need to be provided by an operating system of some kind and thus is not available during cold-boot. User code cannot tell a difference between a software emulated instruction and a hardware implemented one. A fsin or fcos is equally slow whether microcoded (68882) or emulated (040, 060, 080). Again: the important difference between 040, 060 on the one hand and 080 on the other is that the 080 will not trap on the fsin like the 040 and 060 will but comes with the emulation code included and invisible to anyone but the FPU. This is really a kind of microcode.
Disagreement in the team about the FPU:
I don't know what you are referring to. The work on AGA was already very far when Gunnar put it aside for work on the FPU because Jari showed initiative with his wonderful FEMU. No hard feelings about that. The work on AGA is not lost and will progress soon. There is no conflict over traditional FPU vs. next-gen FPU. You make that up. Again I have explained many times that the advanced FPU is the foundation on which the traditional one is built. It is easier to build something powerful and then add a limiting layer to it than to build something limited and then add functionality to it.
AGA or SAGA:
I have explained to you several times that the RTG part of the core implements the new graphics features in an Amiga-way. I.e. all the registers for the RTG modes are within the address range of the Amiga custom chips and can be written by the copper reimplementation and not only by the CPU as is the case with the P96 software layer. This means that you can have smooth hardware scrolling for chunky screens, chunky screens with copper palette, multiple chunky playfields and probably some more I forgot. All this already in the core. The only thing missing to complete SAGA is in fact lame old AGA. The "S" in "SAGA" is already there.
-
@kolla
Sometimes your comments are worthwhile, and sometimes not. On this thread you are back in the latter category again.
Grond has very diplomatically explained to you the background on some of the developments. This has been explained to you in various forms in the past, but somehow you continue to "forget".
May I suggest taking up a new hobby that doesn't involve posting bullsh!t?
-
A full 882 inplementation is a waste of gates. An 040 compatible FPU is all that is really needed. The 68882 transcendental instructions were so chronically slow anyway that you'd be certifiable to use then over any half decent software solution that uses simpler FPU operations. Some sort of trap and patch like oxypatxher/cyber patcher would be a nice way to get performant support for old 882 dependent code. It was good enough for the 040/060 after all.
-
I'm not the one forgetting here, rewriting history is not the right thing to do, even if you do it "politely". One year ago, there already was FPU for V2, it just needed some "testing". I suppose the testing didn't go so well, because it didn't take so long before it was clear that the very much hyped FPU would not be... and anyways, Amiga don't need FPU, does it. So started the bashing of everyone expressing needs for FPU began. Then Gunnar came with AMMX, as a sort of "look, this is much more useful!". But there were people also inside the team that were unhappy about the lack of FPU, and there was a rather harsh discussion over it. Gunnar decided if he was to implement an FPU it would be the most awesome FPU ever, and it would require bigger FPGA, V2 be damned, let there be V3... heck V4! V2 owners can use some software emulation if they need FPU so badly. And this was the sentiment till Jari came with FEMU, pretty much proving that software FPU emulation is not desired. FEMU is far from perfect, and it was demonstrated how both productivity software and demos did not run well enough. So again focus was changed, to improve FEMU. And this has now been going on since last summer, and had CLEARLY been a priority. Despite previous rantings about how useless FPU is on Amiga and what idiots people are for wanting it. Jari says quite openly that after his initial 0.10 release, he's not really been the one working on improving it. Over time, more and more went into the FPGA, and from what I understand, it's currently on pair with 040. Meaning that there's still a bit of software emulation needed, which is fine. What's less fine is that this software is running outside the operating system, meaning noone else but Apollo Team can ever fix bugs or do improvements. But I suppose, like everything else Apollo Core, the code is perfect already. Like those libraries Phase5 put into ROM on their CPU boards. Bad for Phase5 and others, but good for Apollo Core. Always.
Imagine if Jari had not made FEMU, and where the project would have been now, what the outspoken sentiment would have been.
As for SAGA, it was announced that the SAGA FPGA core would be open source, but now it's not when clear what SAGA is, and half of the time it just refers to P96 support. Originally, SAGA was the Super AGA chipset that was to take over from the AGA Amiga chipset, being a superset of AGA. Pamela is the audio part of SAGA, taking over for Paula.
-
Some sort of trap and patch like oxypatxher/cyber patcher would be a nice way to get performant support for old 882 dependent code. It was good enough for the 040/060 after all.
No, this is not good enough. No patcher or trapper can be used, as this is taken care of outside the scope and reach of the hardware available from the operating system and any software running on the operating system.
-
I'm not the one forgetting here, rewriting history is not the right thing to do, even if you do it "politely". One year ago, there already was FPU for V2, it just needed some "testing". I suppose the testing didn't go so well, because it didn't take so long before it was clear that the very much hyped FPU would not be... and anyways, Amiga don't need FPU, does it. So started the bashing of everyone expressing needs for FPU began. Then Gunnar came with AMMX, as a sort of "look, this is much more useful!". But there were people also inside the team that were unhappy about the lack of FPU, and there was a rather harsh discussion over it. Gunnar decided if he was to implement an FPU it would be the most awesome FPU ever, and it would require bigger FPGA, V2 be damned, let there be V3... heck V4! V2 owners can use some software emulation if they need FPU so badly. And this was the sentiment till Jari came with FEMU, pretty much proving that software FPU emulation is not desired. FEMU is far from perfect, and it was demonstrated how both productivity software and demos did not run well enough. So again focus was changed, to improve FEMU. And this has now been going on since last summer, and had CLEARLY been a priority. Despite previous rantings about how useless FPU is on Amiga and what idiots people are for wanting it. Jari says quite openly that after his initial 0.10 release, he's not really been the one working on improving it. Over time, more and more went into the FPGA, and from what I understand, it's currently on pair with 040. Meaning that there's still a bit of software emulation needed, which is fine. What's less fine is that this software is running outside the operating system, meaning noone else but Apollo Team can ever fix bugs or do improvements. But I suppose, like everything else Apollo Core, the code is perfect already. Like those libraries Phase5 put into ROM on their CPU boards. Bad for Phase5 and others, but good for Apollo Core. Always.
Imagine if Jari had not made FEMU, and where the project would have been now, what the outspoken sentiment would have been.
As for SAGA, it was announced that the SAGA FPGA core would be open source, but now it's not when clear what SAGA is, and half of the time it just refers to P96 support. Originally, SAGA was the Super AGA chipset that was to take over from the AGA Amiga chipset, being a superset of AGA. Pamela is the audio part of SAGA, taking over for Paula.
Here we go again, yes you are re-writing history, your version is skewed from any facts and reality. You seem to have small nuggets of truth in the details, but you spin the version you want, the one where you're always right and the Apollo team is doing evil things to the Amiga community.
-
Nothing evil going on, stop with the hyperbole. I was there on irc when all this went down, I still have the logs.
-
@kolla; I was there too, and to be honest, I would have lost my patience long before Gunnar.
As Ive said countless of times by now; Its work in progress with limited resources/people.
Still we (myself included I should add) kept pushing Gunnar and the team about xyz issue and feature, instead of appriciating their efforts.
Look at what happened with Kipper2k. Flype did say at one point "we are only human, its hard to not get affected by the negativity".
Ive frequented IRC almost daily at times (alot of afk mind you), and Gunnar IS known to poke fun in his own way, be it sarcastic, annoyed or just for lolz.
Thats fine.
In THIS particular timeframe my PERSONAL take on it, the barrage on IRC and forums (apollo included) eventually got to Gunnar, and he just shut down the FPU conversation with "There will be no FPU!". I took the hint, and stopped pushing Gunnar and the team. Basically I thought "Its better to let them work their own roadmap, than to have people like ME that doesnt actually contribute constantly poke them in the eye".
Then Jari came along with his FEMU emulation project, and Gunnar (and team?) took intrest in the FPU again. Gunnar has said REPEATEDLY; "If you decide to actually contribute with actual effort beyond WORDS, we will help/adjust the roadmap".
So in that framing, Gunnar hasnt actually changed his tune. He just reacted to Jaris efforts in a way he has said repeatedly.
TLDR: If you put in REAL effort, they will put in REAL effort.
-
Nothing evil going on, stop with the hyperbole. I was there on irc when all this went down, I still have the logs.
The fact that you keep irc logs tells more about you than about what was said on irc.
-
No, this is not good enough. No patcher or trapper can be used, as this is taken care of outside the scope and reach of the hardware available from the operating system and any software running on the operating system.
I think you are missing the point. Full 882 emulation is just a waste. Can you show me any software released since people first started putting 040 and 060 in their systems that still needs needs a full 882 and doesn't have a version compiled that either does not require an FPU at all or relies only on the 040/060 subset?
Even assuming no software solution could patch an 882 binary at runtime because "reasons", we are now in the realms of programmable hardware. Is there a valid reason why the FPGA implementation could not implement it's own patch to call out to a handler routine when an unimplemented opcode is first encountered?
-
One year ago, there already was FPU for V2, it just needed some "testing".
There was an FPU for *Apollo Core*. How much of it was available in any publically released V2 core is a different question. And testing a CPU is the biggest part of the work because there is an infinite number of possible cases that can go wrong. So your point is based on a false assessment of how much work it is to develop a section of a CPU (a lot and few people can do something like that) and then debug it ("just some testing"). Testing and debuggin a CPU requires: writing lots and lots of testcases (assembly code) which requires a lot of knowledge and pondering about the inner workings of the CPU, simulating every single one of the testcases, looking at hundreds of digital signals in the simulator for millions of clock cycles where you can never see more than a few dozens on the screen for each testcase, modifying the simulation environment because you perhaps don't model a real computing environment accurately and crashes you see in real life just can't show in the simulator, and when you eventually see something odd happening, trace it back to the root cause which means you basically have to dig through the entire CPU logic. It's not as simple as "oh, here we have an uninitialised pointer, let's fix it and then release our App to Goodle Play". I suppose the testing didn't go so well, because it didn't take so long before it was clear that the very much hyped FPU would not be...
Again you are basing your conclusions on false premises. The "just some testing" did NOT mean that testing with the team was started ever. There was NO testing in the team at all until Jari started FEMU! and anyways, Amiga don't need FPU, does it.
What are you trying to say? "Gunnar is stupid because he doesn't know that an FPU can and has been used in an Amiga"??? Do you have some kind of Asperger? The statement was basically "since nobody of you wants to do any work other than talking bull%&$#?@!%&$#?@!%&$#?@!%&$#?@! on forums, you obviously don't need an FPU". Then there was a discussion about V4 which was supposed to be available much earlier and features an FPGA that has 64bit FP macros. These macros mean that you can either have an extended precision (that "nobody needs") FPU at very slow speed (i.e. not using the 64bit FP macros) or an NG FPU with "just" 64 bit precision at one FOP per clock cycle (!!!) per FP macro. With those macros you can build SSE type FPU units easily. Then there was the usual "but it's incompatible!!!" outcry going on (yes, SSE is not 386 compatible, very clever observation...). Summing up, half of what you are mixing into your skewed view of this vicious project was actually discussion about a future hardware base. So started the bashing of everyone expressing needs for FPU began.
No, bashing of people like you who only say "but this old Amiga program does not run without CPU feature X" began. This project is not about Amiga. It is about the 680x0 family of CPUs. It is run by Amiga enthusiasts, though. It does not take any work to point out that some program crashes. It is no valuable input to point out which unit of a CPU, be it MMU or FPU, is used by what software. CPU developers KNOW that kind of thing. But if you really want something, you will have to put some effort into getting it. You don't but still have the time to bicker about the project on all Amiga forums? Then you obviously don't need an FPU. Nobody did? Well, then the Amiga obviously does not need an FPU. Get it? Sometimes "honey, you look gorgeous in that dress" means "you should lose ten pounds but we'll be late if you change again". Then Gunnar came with AMMX, as a sort of "look, this is much more useful!".
Because somebody actually wrote the code for RiVA piece by piece which meant there was somebody willing to put a lot of work into "just testing" AMMX. The same thing that had NOT happened for the FPU. Thus, AMMX was clearly more "needed". Jari came later and then the "just testing the FPU" started. FEMU has been a perfect tool for testing the FPU because you could move FPU instructions into the FPU one by one and test each one separately. But there were people also inside the team that were unhappy about the lack of FPU, and there was a rather harsh discussion over it.
Surprise, surprise, the members of the team are Amiga users. And yes, you are right, an FPU is a useful CPU unit, even in an Amiga. Please save this to your logs, you were right all the time!!!!!! An FPU IS REALLY USEFUL!!! It was created to serve some purpose!!! The situation was that the team members who had written a lot of testcases for the integer part had very little knowledge about writing FPU code. So basically it was the same situation that became a public discussion: if nobody puts any work into it, it means you don't really want it. Gunnar decided if he was to implement an FPU it would be the most awesome FPU ever, and it would require bigger FPGA, V2 be damned, let there be V3... heck V4!
The Vampire V2 known to the public is in fact the V3. There was an unreleased V2 precursor with just 64MB RAM and a 16 bit RAM bus that was "the V2" inside the team (I actually owned one and used it in my Amiga). The 128MB V2 is always referred to as the "V3" inside the team. Majsta named his product V2 anyway and Gunnar prefers V3. Since the V4 was developed by Chris, a friend and colleague of Gunnar's, it is called V4. Majsta would probably have called it V3. So your reading between the lines about how the next card is the V4 because of some personality problem on Gunnar's side fails again. And you knew all this already because I have explained it before why the V4 is the V4 and not the V3. FEMU is far from perfect, and it was demonstrated how both productivity software and demos did not run well enough. So again focus was changed, to improve FEMU. And this has now been going on since last summer, and had CLEARLY been a priority. Despite previous rantings about how useless FPU is on Amiga
So all this is about your hurt feelings? Because you said "an FPU is useful" and Gunnar said "it's useless"? And then history proved what we all knew forever? That FPUs do serve some purpose and have actually been used in the Amiga? Meaning that there's still a bit of software emulation needed, which is fine. What's less fine is that this software is running outside the operating system, meaning noone else but Apollo Team can ever fix bugs or do improvements.
Are you aware that the 68882 is full of software emulation? Only that the software is stored as a ROM inside the CPU and cannot be changed at all? The 080 also has some software FP emulation inside, as you observed, but as the FPGA is flashable, it can be changed. But it is nothing that a user would or should touch. Your argument is basically a pro-open source argument. Well, gifts are always nice but you can't demand them. Imagine if Jari had not made FEMU, and where the project would have been now, what the outspoken sentiment would have been.
Imagine you would actually contribute to the project, where the project could be now. As for SAGA, it was announced that the SAGA FPGA core would be open source, but now it's not when clear what SAGA is, and half of the time it just refers to P96 support. Originally, SAGA was the Super AGA chipset that was to take over from the AGA Amiga chipset, being a superset of AGA. Pamela is the audio part of SAGA, taking over for Paula.
What's the problem here? That you again do not understand what I explained? Pamela is already done and part of SAGA (and clearly not P96, right?). The chunky graphics features that currently are available to the Amiga software through P96 are implemented in a SAGA way. P96 does not know about hardware scrolling and many more features so using P96 you can only perceive this part of SAGA as a normal RTG feature. If you want, you can bang the registers and have chunky Amiga screen modes. It's already there. You can do this TODAY. Do you understand that you could make a P96 driver for AGA? In the case of the Vampire the P96 driver basically is a chunky variant of "P96 for AGA"
-
Nothing evil going on, stop with the hyperbole. I was there on irc when all this went down, I still have the logs.
Kolla you explained already thousands of times how unhappy you are with the direction of vampire and that Gunnar is a liar and you bought it with different expectations. I already asked you several times to sell your vampire so you have no longer reason to moan and cry on every amiga site, you get your money and there is a new vampire owner who is happy with what he gets. A win for everyone. You did not react on it instead you continue the same. To me it looks like spreading nonsense on websites is your main interest in your life. Very poor...
-
The fact that you keep irc logs tells more about you than about what was said on irc.
Kolla will never contribute anything to the project. Crying is his main interest and makes him feel important
-
A full 882 inplementation is a waste of gates. An 040 compatible FPU is all that is really needed. The 68882 transcendental instructions were so chronically slow anyway that you'd be certifiable to use then over any half decent software solution that uses simpler FPU operations.
It is a bit more complicated than that, though. The 68882 has dedicated logic for it, essentially the cordic algorithm, and goes by microcode through the cordic tables. This by itself is not a slow algorithm. The 68040 left this out. The software emulation is using a completely different type of algorithm that is based on polynomial approximations, and it is better suited for software than cordic - which is a hardware/table-driven approach.
Hence, one cannot really say that the software solution is "simpler". It is different, and better suited for software.
Some sort of trap and patch like oxypatxher/cyber patcher would be a nice way to get performant support for old 882 dependent code. It was good enough for the 040/060 after all.
The reason why MuRedox helps improving the speed is not that it uses a more optimized implementation of the FPU core. The main reason is that it avoids the exception overhead (on the 68040) and the need to decode the instruction manually (on the 68060). I suppose neither of that is really necessary on the Apollo core, thus there is likely less to gain by such a solution - at least if Gunnar had the math emulation implemented as I suggested, i.e. with direct access to the CPU pipeline.
As far as I got the story, the part that is otherwise slow in software on the 68060 (namey the manual instruction decoding) is not necessary, and the rather large stack frame of the 68040 is also avoided.
The only drawback may be that the FPU handling is an exception, i.e. multitasking stops.
-
I think you are missing the point. Full 882 emulation is just a waste. Can you show me any software released since people first started putting 040 and 060 in their systems that still needs needs a full 882 and doesn't have a version compiled that either does not require an FPU at all or relies only on the 040/060 subset?
Frankly, I do not believe that anyone has a full overview, but instructions like fsin or fcos are still quite necessary for 3D games. Is it really that people checked for alternatives for them?
I
Is there a valid reason why the FPGA implementation could not implement it's own patch to call out to a handler routine when an unimplemented opcode is first encountered?
Uglyness of the design? I do not see much sense in the CPU core modifying the program it is executing. That can be done by a pure software solution.
The trap solution for less frequently used instructions is not bad per se, and it can surely be done in a better way than on the 68040 or 68060.
-
The only drawback may be that the FPU handling is an exception, i.e. multitasking stops.
How much multitasking is there while the 882 executes a 600 clock cycle fsin? How much multitasking is there while the 040/060 executes a trapped fsin? To how much time do the clock cycles without multitasking amount in any of 030, 040, 060 and 080 considering the different base clock frequencies? I guess we should not forget that instructions that are 882 but not 040 are deprecated and only supported for legacy reasons. Their use is discouraged either way.
-
Frankly, I do not believe that anyone has a full overview, but instructions like fsin or fcos are still quite necessary for 3D games.
Not really. You need sine computations once per frame and perhaps once per lightsource and frame for more complex 3D games, but from then on it is usually all fmul/fadd.
-
How much multitasking is there while the 882 executes a 600 clock cycle fsin?
All of it. The fun part about the 68882 is that it can stop its execution in the middle, save its state to its stack frame and continue from that point on, hence the 68882 is used preemptively and it is preempted as part of the exec task scheduler. Even more so, the 68882 is completely assynchronous, meaning that the FPU instruction only triggers the execution while the 68K is executing its own code in parallel. The 68K has only to wait as soon as you want to access the result, i.e. save it to memory or load it into a 68K register.
How much multitasking is there while the 040/060 executes a trapped fsin?
None of it, as it is executed in supervisor mode, and task switching does not take place while the CPU is in super mode. While it does not sound much, it is noticable by a the mouse pointer no longer moving smoothly if the fpsp is in heavy use. MuRedux can certainly help here. In principle, one can restructure the fpsp such that it switches back to user mode after having done all the supervisor-only business, as in fetching the data and validating the addresses. I tried this once, but the net effect of this wasn't as great as I was hoping as switching back and forth is neither a "for free" operation.
To how much time do the clock cycles without multitasking amount in any of 030, 040, 060 and 080 considering the different base clock frequencies? I guess we should not forget that instructions that are 882 but not 040 are deprecated and only supported for legacy reasons. Their use is discouraged either way.
I never saw a deprecation notice from Motorola, Freescale or NXP on these instructions, so I wouldn't say so. That they didn't put them into silicon is just a tradeoff between completeness and available silicon area/available gates.
-
Some facts:
68882 68080 Clock cycles Latency @50 MHz Clock cycles Latency @80 MHz fadd 56 1120 ns 1 12.5 ns fsub 56 1120 ns 1 12.5 ns fmul 76 1520 ns 1 12.5 ns fdiv 108 2160 ns 2 25 ns fsqrt 110 2200 ns 222 2775 ns fmove 21 420 ns 1 12.5 ns fsin 394 7880 ns 254 3175 ns fcos 394 7880 ns 269 3362.5 ns fsincos 454 9080 ns 317 3962.5 ns Who can add the values for 25 MHz 040 and 50 MHz 060? :)
-
Some facts: 68882 68080 Clock cycles Latency @50 MHz Clock cycles Latency @80 MHz fadd 56 1120 ns 1 12.5 ns fsub 56 1120 ns 1 12.5 ns fmul 76 1520 ns 1 12.5 ns fdiv 108 2160 ns 2 25 ns fsqrt 110 2200 ns 222 2775 ns fmove 21 420 ns 1 12.5 ns fsin 394 7880 ns 254 3175 ns fcos 394 7880 ns 269 3362.5 ns fsincos 454 9080 ns 317 3962.5 ns Who can add the values for a 25 MHz 040 and a 50 MHz 060? :)
-
Some facts:
68882 68080
Clock cycles Latency @50 MHz Clock cycles Latency @80 MHz ratio
fadd 56 1120 ns 1 12.5 ns 89.6x
fsub 56 1120 ns 1 12.5 ns 89.6x
fmul 76 1520 ns 1 12.5 ns 121.6x
fdiv 108 2160 ns 2 25 ns 86.4x
fsqrt 110 2200 ns 222 2775 ns 0.8x
fmove 21 420 ns 1 12.5 ns 33.6x
fsin 394 7880 ns 254 3175 ns 2.5x
fcos 394 7880 ns 269 3362.5 ns 2.3x
fsincos 454 9080 ns 317 3962.5 ns 2.3x
Who can add the values for a 25 MHz 040 and a 50 MHz 060?
-
Again my point has been missed here. Show me any 3D game on the Amiga that requires floating point (as opposed to doom like fixed point which uses approximations for trig etc) that actually uses 68882 transcendental trig functions as opposed to being optimally compiled for 040/060.
Games like Quake that use proper floating point trigonometric operations for vertex processing were already utterly useless on anything less than a 68060. The developers certainly weren't going to make that worse by using unimplemented 882 opcodes in their binaries.
Maybe, just maybe, there's an F1GP or TFX build that uses 882 for this.
-
The above values are for the Gold 2.7 release of the 68080. The V4 release of the 68080 can schedule one fsqrt per cycle and complete it in 20 cycles.
-
Man Kolla sure have lots of free time, he can troll on this vampire thread 24 hours a day 365 a year its quite impressive.
-
Yall poor sods think you can beat Kolla in the truth game? He's squatting in Gunnar's closet, taking notes and saving logs. He even knows what Gunnar mumbles in his sleep. Which, obviously, makes him more knowledgeable about Gunnar than Gunnar himself!
-
Man that Kolla guy is tiring, whining like a little kid that didn't get her cookie.
So next up is he'll start about the MMU (again....)
-
Firstly, IRC logs come for free when you use irc services like znc etc, not like I hang out logging manually using amirc or whatever.
Secondly, I have nothing against software emulation of 68882 instructions, that's after all what we have been doing since 040 and it works well.
Apollo Core has FPU like 68040 and hence need a similar solution as 040 and 060. No problem.
But then, do not run around claiming that NO software emulation is taking place with Apollo Core on V2, because that is simply not true. Unless 68882 is actually implemented, which would be worthy a news item.
Lastly, the software emulation of 68882 instructions are not running within the scope and and reach of the operating system. It's not a task of AmigaOS. It's not visible for any OS running on the Vampire card. If you use old software to try detecting what CPU there is, it may very well say it's a 040+882. Now, one can question wether it is a good or bad thing to have emulation software - or any software at all - running outside, or "under" the operating system. Some would say that is crawling towards using a hypervisor. There has also been talks about hyperthreading. Well, AmigaOS cannot do it by itself, so something else would be needed to do the scheduling etc of "out of bounds" threaded processes. Again, it is tempting to call that a hypervisor. Is this good or bad? I don't care, it just is what it is. I am skeptical though, as all experience says that running software outside the reach of the operating system complicates a number of things.
As for MMU, it is already there, it just isn't compatible with existing software and operating systems, which is a case of lost opportunities for Apollo Core. Not for me, but for Apollo Core and for Gunnar. His problem. Not mine. The MMU of the Apollo Core is used on the Vampire cards, is (among other things) used for mapping memory, so that AmigaOS, drivers and software can run happily. Nice solution and works great. Also it has been mentioned that MMU is involved in for example speed up IDE and do various DMA tricks. Also cool. All this happens outside the scope of the operating system. There are a few libraries and resources giving limited access to the Apollo Core MMU, like softkicking for example. But again, it is starting to look like some hypervisor model.
Social aspect of the Apollp Team, who have more speaks persons than they have people doing actual work, and who contradict each other and Gunnar half of the time... yeah, it speaks to itself. Grong, no testing? Apollo-accelerators.com says/said something else, and luckily there is wayback machine.
-
Apollo Core does like 68040 and hence need a similar solution as 040 and 060. No problem.
But then, do not run around claiming that NO software emulation is taking place with Apollo Core on V2, because that is simply not true. Unless 68882 is actually implemented, which would be worthy a news item.
Nobody has ever claimed that 68882-only FP instructions will be implemented in dedicated hardware. And yet the way these instructions are implemented in the 080 is more similar to the way it is done in the 68882 than to the way it is done in the 040 and 060. There is no trap, no trap handler, there is microcode that uses more fundamental operations such as fmul, fadd, fdiv. The 68882 is exactly like that! It is all microcoded just that in the 68882 the microcode is stored as a metal mask ROM while in the case of the 080 the microcode is stored in flash memory.
Lastly, the software emulation of 68882 instructions are not running within the scope and and reach of the operating system. It's not a task of AmigaOS. It's not visible for any OS running on the Vampire card. If you use old software to try detecting what CPU there is, it may very well say it's a 040+882. Now, one can question wether it is a good or bad thing to have emulation software - or any software at all - running outside, or "under" the operating system.
Even Intel processors are full of microcode. So even if one could question that, the answer to that would be clear anyway: it doesn't matter and it is no problem. There has also been talks about hyperthreading. Well, AmigaOS cannot do it by itself, so something else would be needed to do the scheduling etc of "out of bounds" threaded processes. Again, it is tempting to call that a hypervisor.
And the problem is what? That there is also work done to use a CPU feature in AmigaOS? The alternative would be to not use the CPU feature. Possible but no advantage. I am skeptical though, as all experience says that running software outside the reach of the operating system complicates a number of things.
Actually it is not SOFTWARE running outside the reach of the operating system that complicates things, it is having different processes/functional units operating concurrently that makes things complicated. The Amiga has always suffered from bad handling of blitter tasks running in parallel to the CPU and badly managed DMA. It doesn't change anything if such tasks are handled by dedicated hardware or by software running in a hyperthreaded virtual CPU core invisible to AmigaOS because it doesn't know about hyperthreading or multiprocessor environments.
As for MMU, it is already there, ir just isn't compatible with existing software and operating systems, which is a case of lost opportunities for Apollo Core.
It is NOT a lost opportunity. It is just NOT FINISHED. Is this really so hard to understand? The 68080 has two memory controllers. No other 68k CPU has ever had a memory controller and most certainly not two running concurrently. An MMU running in such a processor needs to be different from the MMUs that previous 68k processors had. This is a technical fact. At the same time a modern MMU needs features such as marking memory as non-executable and such. Again: this project is not about the Amiga, it is about the 68k processor family. It does not matter whether AmigaOS has no concept of memory protection and thus does not need non-executable memory protection. The fact that AmigaOS does not make use of this MMU feature has no influence on the decision whether this feature will be implemented or not. But perhaps if we are lucky and patient, there will eventually be a compatibility MMU-layer on top of the units that are already there. Maybe this layer will support all MMU-features the Amiga has used, maybe only some.
And again: ALL of this has been explained many times before. Also it has been mentioned that MMU is involved in for example speed up IDE and do various DMA tricks.
Um, this sounds like you are mixing things up. I don't think the MMU has anything to do with IDE. The MMU certainly plays a role when dealing with DMA. Grong, no testing? Apollo-accelerators.com says/said something else, and luckily there is wayback machine.
I guess you are referring to the tests of the individual FPU instructions. This is not testing the FPU. This is basically using pseudo-random generators to produce e.g. two sources of input data and feeding that into the hardware unit that does the FADD. Then compare the output of the FP-adder to the expected result (precomputed or some other reference, e.g. calculated by some Intel or 68k FPU). The comparison is done automatically. Such testing was done for millions of testcases by Chris who developed most if not all of the FPU units. This testing took place but was not done by the team. Hence, it is a correct statement that there had never been any FPU testing done by the team until FEMU was started. Furthermore, this automated testing, although certainly difficult to set up, is less work than testing how program flow behaves, whether flags are set and evaluated correctly, whether operand prefetch goes wrong in certain situations, whether pipeline forwarding between consecutive FP instructions works and so on. The latter is what has been going on in the last few months.
Just because you don't understand how the work of developing a CPU is done in general and in this specific project, doesn't mean that there are self-contradicting statements, hidden truths and dirty secrets that would require YOU to unveil them.
-
Nobody has ever claimed that 68882-only FP instructions will be implemented in dedicated hardware. And yet the way these instructions are implemented in the 080 is more similar to the way it is done in the 68882 than to the way it is done in the 040 and 060. There is no trap, no trap handler, there is microcode that uses more fundamental operations such as fmul, fadd, fdiv. The 68882 is exactly like that! It is all microcoded just that in the 68882 the microcode is stored as a metal mask ROM while in the case of the 080 the microcode is stored in flash memory.
That's not how I understood the story, but maybe you want to elaborate. To my understanding, this is just regular 68K code that is stored in ROM, not "microcode". This makes in so far a difference as 68K code will depend on additional resources, i.e. it will require some stack to save back register contents, it might be interrupted... etc. For most practical reasons, this might not make too much of a difference, unless you attempt to do really crazy things such as "fsin.x -(a7),fp0", i.e. instructions that contradict the way how the 68K operates. Of course, the same restrictions apply to the fpsp, so nothing of that is really new. The advantage of the fpsp code is that it can be very easily updated in case someone finds a defect. The same goes, of course, for modern microcode once you have tools how to get it loaded into the CPU and make such tools available to the user.
Actually, this did happen in the past once to me, and we also found a bug in the P5 libraries during beta-testing, so it is not quite academic as an argument as it may sound. It also happened to intel a while ago, as you know. (-: Which was one of the reasons why they made microcode upgradable from external sources.
Second, due to that, the way how the result is computed is certainly different from that how a 68882 performs its job. The latter is cordic, the former is a polynomial approximation. Again, that does not make much of a difference as long as the result is correct, but it is certainly not "the same".
-
Sure, all analogies and comparisons fail if you apply a higher zoom factor. That doesn't prove the point moot. And I wrote that the way it is done on the 080 is more similar to the 882 than to the 040. And this is still correct. The emulation code could not be executed by any of 68000 through 68060 because it makes use of features unique to the 080. E.g. it uses additional FP registers and instructions that do not exist on any previous 68k FPU. In fact the correct technical term is not "microcode" but "millicode" and is widely used in modern CPUs. Did we really need to discuss this?
-
@kolla :
Please, get a life and stop spreading false statement. I reported your post to the admins and I encourage the others that are annoyed too to do the same.
-
Sure, all analogies and comparisons fail if you apply a higher zoom factor. That doesn't prove the point moot. And I wrote that the way it is done on the 080 is more similar to the 882 than to the 040.
This is, of course, very much a matter of personal taste. Again, not saying that it makes much of a practical difference, but microcode operates on quite a different level than (albeit extended) 68K code as it has access to the internal register routing of the CPU.
As in the 68040/68060, we are just executing 68K code, one in ROM, the other loaded in RAM, both triggered through an exception - so for me this brings it pretty close to the 68040/68060 library, except that upgrading the code is probably not quite as straightforeward as it was for the libraries.
Every model has its advantages and drawbacks, I do not make a particular statement for one or the other. But "just like the 68882" is certainly not right. A different algorithm, and a different execution model.
Did we really need to discuss this?
Why not? I think it's fairly interesting. Again, I'm not saying that this is any better or worse. Probably Microcode would have provided more options to mess with the CPU resources, but then again... why bother.
-
Hi Thomas
Some words about "except that upgrading the code is probably not quite as straightforeward as it was for the libraries."
Not sure it really matter since in all cases, such updates would need team collaboration, where of course they know how to update it. And if you meant that it needs a new core to upgrade it, it does not actually. There is a accessible vector for that, and can be 'hot' overwritten.
-
So, my thoughts were based on an assumption that a full 882 implementation is a lot of work and would use up a lot of gates that could be used for other stuff and the fact that most people that really needed FPU had migrated to 040 and 060 based machines and recompiled binaries that no longer used unimplemented FPU operations.
If that's not correct, then great, 882 me up.
Eagerly awaiting an A1200 version!
-
The 080 fpu is the first ever 68k fpu in an (amiga targeted) fpga. Personally i find this a good news and is welcomed. It also was done with constraints in mind. Whatever solution the team selected they did because of constraints they knows and solved and well. The result is a fpu that already reached a nice level of compatibility. It covers all the existing fpu instructions from 881 to 060. The 881/2 instructions are covered with solution that do not 'eat' fpga space while being faster than any existing library.
-
So, my thoughts were based on an assumption that a full 882 implementation is a lot of work and would use up a lot of gates that could be used for other stuff and the fact that most people that really needed FPU had migrated to 040 and 060 based machines and recompiled binaries that no longer used unimplemented FPU operations.
It's neither quite adequate because you seem to assume that the 68882 is a complete hardware implementation. It is not, and has never been. The 68882 has hardware support for some elementary FPU operations, plus a lot of tables, plus some ROM-based microcode. Nobody sane in his mind implements a full FPU in hardware. That was not the case for the 68882, nor for the 68040. The difference was just where "the software runs". For the 68882, it runs as microcode in the ROM of the chip. For the 68040, it is 68K code in the 68040.library. And "what the software does". For the 68882, it uses an algorithm known as "cordic" which is mostly table driven (i.e. very simple software). For the 68040, cordic was replaced by polynomial approximations, which requires fewer steps in software, but more complicated steps like multiplications. There are no multiplications in cordic.
Now, the Apollo core uses another variation of this scheme as it seems. It is again 68K code, though run in a ROM.
Just to complete the picture: Even the 68000 CPU is not a complete hardware implementation. It is driven by microcode that "runs" on a simpler machine. The 68060 was a complete hardware implementation, with known side effects on "correctness". Software is always easier to get right.
Also, "mathtrans.library" on the Amiga is a cordic implementation, because the multiplication on the 68000 is relatively expensive. "mathieeedoubtrans" is polynomial approximation - it is designed for faster CPUs. So you find all the models in AmigaOs as well.
-
The difference was just where "the software runs". For the 68882, it runs as microcode in the ROM of the chip. For the 68040, it is 68K code in the 68040.library.
Only some of it is 68k in the 68040.library, some of it is implemented in hardware. Less of it is implemented in hardware on the 68060, I'd settle for vampire being compatible with the 68060. I'd like to be able to switch to 68040 though because there are times when you can't run any emulation software.
The 080 fpu is the first ever 68k fpu in an (amiga targeted) fpga.
It's a software emulated fpu. Those have existed for years.
So, my thoughts were based on an assumption that a full 882 implementation is a lot of work and would use up a lot of gates that could be used for other stuff and the fact that most people that really needed FPU had migrated to 040 and 060 based machines and recompiled binaries that no longer used unimplemented FPU operations.
If that's not correct, then great, 882 me up.
Eagerly awaiting an A1200 version!
Your assumption is wrong.
The 040 & 060 cpu can still run some of the 68882 instructions & emulates some of them, while vampire can run none of them and emulates all of them. If vampire could run all 060 or 040 instructions without emulation then this discussion wouldn't exist.
-
It's a software emulated fpu. Those have existed for years.
Lol no. Speaking of Gold2.7, it is hardware implemented. Quite all 040 fpu instructions are, all Ea modes are, Registers are. It is clear that only some 881/2 instr are software emulated. And even for the emulated ones they benefits of the hardware implementation. EA computation is done by hw for example, and also castings and primitives, which helps lower (and simplify) the emulation overhead by an important factor.
-
Looks like Kolla has done another fine job of derailing a thread with his rants....
-
Only some of it is 68k in the 68040.library, some of it is implemented in hardware. Less of it is implemented in hardware on the 68060, I'd settle for vampire being compatible with the 68060.
Actually "something different is implemented in hardware in the 68060". If I recall correctly, one instruction was removed from the 68060, and another was added. In general, however, the EA computation was removed from the 68060 completely and has to be done in software. The 68040 does this in hardware, but writes a long and complicated stackframe in exchange. Neither is a perfect solution.
It's a software emulated fpu. Those have existed for years.
Hardly, because then it wouldn't be able to get one clock cycle for elementary arithmetic instructions . However, from what I know, I afraid that this is only a 64bit FPU, i.e. results may differ from the full 80 bit implementation Motorola provided. Again, "in typical applications", this may not make much of a difference.
-
"I started out as super enthusiastic, but ended up reluctant. I appreciate the accomplishments, but I am not thrilled about the attitudes and skeptical about the agenda." -Kolla
So here we are a couple of years later since the start of this thread and the overall mindset of Kolla remains the same.
I am happy with my Vampires, so if you are reading this thread and are on the fence about getting one.
I can say that after having spent the past two years on Vampires and as an owner of every Amiga model out there...Buy the Vampire for the features it has right now, and that feature set is pretty good, better than good actually.
-
You know, there are some of us who agree with Kolla and don't see the need for all this defensiveness about the Vampire.
I, for one, want a compatible CPU, FPU and MMU. I don't see gcc being adapted for the special instruction set of the "080", particularly since the instruction set is still changing. Likewise, there's no way anyone is going to spend even a tiny bit of work caring about the special case of an "080" for LLVM - all energy is going in to generating code than can run on real m68k chips. If an emulation or an FPGA implementation can also run code that runs on real m68k chips, then great!
All this talk about memory controllers requiring a different kind of MMU is bull. You're conflating issues. A memory controller needs access to things that an MMU needs to do, but this does not require a reinvention of an MMU. There's no good reason whatsoever that an m68k compatible MMU can't also support the needs of a memory controller (or multiple controllers) without making the MMU incompatible from the point of view of the running OS.
What I'm getting at here is that there are all of these apologists for the Vampire that are pretending that there are reasons why a non-standard MMU and non-standard FPU are somehow "necessary", when it's nothing but bull. What each and every apologist here is missing is how this is going to mean the Vampire will miss out on helping with real projects such as gcc, LLVM, and all the cool tools and software that come with a proper suite from each of those.
Also, there's no good technical reason that I can imagine or have seen here or anywhere else that suggests that anything but a superset of the m68k instruction set is necessary. Add features all you want, but trying to say that they have to come at the expense of compatibility is specious at best and willfully ignorant at worst.
Kolla has a tremendous amount of patience to deal will all of the apologists. I'd have given up a long time ago. I don't even have anything else to add here besides this until there are Vampire options that can run m68k code properly. It's of interest to me personally when I can run NetBSD on it and work on testing toolchain issues.
One day, we'll make another ixemul library based on modern NetBSD and we'll again have a way to compile and run lots of free and open source software on AmigaDOS.
-
You know, there are some of us who agree with Kolla and don't see the need for all this defensiveness about the Vampire.
I, for one, want a compatible CPU, FPU and MMU. I don't see gcc being adapted for the special instruction set of the "080", particularly since the instruction set is still changing. Likewise, there's no way anyone is going to spend even a tiny bit of work caring about the special case of an "080" for LLVM - all energy is going in to generating code than can run on real m68k chips. If an emulation or an FPGA implementation can also run code that runs on real m68k chips, then great!
All this talk about memory controllers requiring a different kind of MMU is bull. You're conflating issues. A memory controller needs access to things that an MMU needs to do, but this does not require a reinvention of an MMU. There's no good reason whatsoever that an m68k compatible MMU can't also support the needs of a memory controller (or multiple controllers) without making the MMU incompatible from the point of view of the running OS.
What I'm getting at here is that there are all of these apologists for the Vampire that are pretending that there are reasons why a non-standard MMU and non-standard FPU are somehow "necessary", when it's nothing but bull. What each and every apologist here is missing is how this is going to mean the Vampire will miss out on helping with real projects such as gcc, LLVM, and all the cool tools and software that come with a proper suite from each of those.
Also, there's no good technical reason that I can imagine or have seen here or anywhere else that suggests that anything but a superset of the m68k instruction set is necessary. Add features all you want, but trying to say that they have to come at the expense of compatibility is specious at best and willfully ignorant at worst.
Kolla has a tremendous amount of patience to deal will all of the apologists. I'd have given up a long time ago. I don't even have anything else to add here besides this until there are Vampire options that can run m68k code properly. It's of interest to me personally when I can run NetBSD on it and work on testing toolchain issues.
One day, we'll make another ixemul library based on modern NetBSD and we'll again have a way to compile and run lots of free and open source software on AmigaDOS.
This must be another one of Kolla's duplicate accounts. He had a couple of them on the Apollo/Vampire forums too....
-
You know, there are some of us who agree with Kolla and don't see the need for all this defensiveness about the Vampire.
I, for one, want a compatible CPU, FPU and MMU. I don't see gcc being adapted for the special instruction set of the "080", particularly since the instruction set is still changing. Likewise, there's no way anyone is going to spend even a tiny bit of work caring about the special case of an "080" for LLVM - all energy is going in to generating code than can run on real m68k chips. If an emulation or an FPGA implementation can also run code that runs on real m68k chips, then great!
All this talk about memory controllers requiring a different kind of MMU is bull. You're conflating issues. A memory controller needs access to things that an MMU needs to do, but this does not require a reinvention of an MMU. There's no good reason whatsoever that an m68k compatible MMU can't also support the needs of a memory controller (or multiple controllers) without making the MMU incompatible from the point of view of the running OS.
What I'm getting at here is that there are all of these apologists for the Vampire that are pretending that there are reasons why a non-standard MMU and non-standard FPU are somehow "necessary", when it's nothing but bull. What each and every apologist here is missing is how this is going to mean the Vampire will miss out on helping with real projects such as gcc, LLVM, and all the cool tools and software that come with a proper suite from each of those.
Also, there's no good technical reason that I can imagine or have seen here or anywhere else that suggests that anything but a superset of the m68k instruction set is necessary. Add features all you want, but trying to say that they have to come at the expense of compatibility is specious at best and willfully ignorant at worst.
Kolla has a tremendous amount of patience to deal will all of the apologists. I'd have given up a long time ago. I don't even have anything else to add here besides this until there are Vampire options that can run m68k code properly. It's of interest to me personally when I can run NetBSD on it and work on testing toolchain issues.
One day, we'll make another ixemul library based on modern NetBSD and we'll again have a way to compile and run lots of free and open source software on AmigaDOS.
+1
-
You know, there are some of us who agree with Kolla and don't see the need for all this defensiveness about the Vampire.
I, for one, want a compatible CPU, FPU and MMU. I don't see gcc being adapted for the special instruction set of the "080", particularly since the instruction set is still changing. Likewise, there's no way anyone is going to spend even a tiny bit of work caring about the special case of an "080" for LLVM - all energy is going in to generating code than can run on real m68k chips. If an emulation or an FPGA implementation can also run code that runs on real m68k chips, then great!
All this talk about memory controllers requiring a different kind of MMU is bull. You're conflating issues. A memory controller needs access to things that an MMU needs to do, but this does not require a reinvention of an MMU. There's no good reason whatsoever that an m68k compatible MMU can't also support the needs of a memory controller (or multiple controllers) without making the MMU incompatible from the point of view of the running OS.
What I'm getting at here is that there are all of these apologists for the Vampire that are pretending that there are reasons why a non-standard MMU and non-standard FPU are somehow "necessary", when it's nothing but bull. What each and every apologist here is missing is how this is going to mean the Vampire will miss out on helping with real projects such as gcc, LLVM, and all the cool tools and software that come with a proper suite from each of those.
Also, there's no good technical reason that I can imagine or have seen here or anywhere else that suggests that anything but a superset of the m68k instruction set is necessary. Add features all you want, but trying to say that they have to come at the expense of compatibility is specious at best and willfully ignorant at worst.
Kolla has a tremendous amount of patience to deal will all of the apologists. I'd have given up a long time ago. I don't even have anything else to add here besides this until there are Vampire options that can run m68k code properly. It's of interest to me personally when I can run NetBSD on it and work on testing toolchain issues.
One day, we'll make another ixemul library based on modern NetBSD and we'll again have a way to compile and run lots of free and open source software on AmigaDOS.
There is absolutely nothing wrong about having reservations about anything, in this case, the Apollo Core. Britelite for example has laid out what his concerns are without feeling the need to kick sand in the eyes of the developers. I grant you that there are Apollo supporters that resort to personal commentary, just like some people do the other way. Thats not helpful ofcourse.
8bitguy has been in the IRC channel, and said flat out that Vampire wasnt for him (atleast currently), and the obvious question came from someone "what are you doing here then?". The reply "we all like to chat about technical aspects of anything amiga right? :) " And that put that to rest.
So you should ask yourself why Britelite doesnt get any pushback when he makes posts.
And you praise kolla for his patience, which is kinda rich, given all he does is post negative comments. Thats not really hard to do. If he was working on a project that kept getting hammered with negativity, and THEN kept on working and replying to forums, then I would be impressed with his patience. But thats not the case.
I remember when FEMU was in its first stages. The performance and visual quality was less than stellar, and certain people just had run victorylaps onto that fact. Jari/FEMU didnt even bother replying on forums, instead hes been steadily improving FEMU, and from Gold 2.7 and 3, the performance looks greatly improved.
And then there is the whole WORK IN PROGRESS part, that people seem to be missing constantly. There is only so much x people can do. Jari joining with his FEMU/FPU work accelerated that aspect of the core, which is great.
Lastly; its not my project. If I want "true" legacy accelerators, there are several options for me. Ive decided to give Apollo my bucks, but those that decide for other alternatives are not any more wrong or right in their decision. Its what make your userexpirience best for your needs that counts.
Either way, I dont feel the incessive need to kick sand in the eyes of the developers. Take a cue from Britelite about how to approach feedback, if anything.
-
+1 for Niding
-
So you should ask yourself why Britelite doesnt get any pushback when he makes posts.
WTF? You're suggesting that you give him an easy ride because of a personality contest. Nice.
And you praise kolla for his patience, which is kinda rich, given all he does is post negative comments.
If people didn't care then they wouldn't post what they wanted. The sycophantic behaviour just gets in the way of technical discussions.
-
Hardly, because then it wouldn't be able to get one clock cycle for elementary arithmetic instructions .
Gold 2.7 still uses FEMU. It might be tuned for Apollo, but FEMU isn't the first 6888x emulator for fpuless 680x0 systems.
However, from what I know, I afraid that this is only a 64bit FPU, i.e. results may differ from the full 80 bit implementation Motorola provided. Again, "in typical applications", this may not make much of a difference.
Which means it won't bite you in the ass until it's too late.
-
This must be another one of Kolla's duplicate accounts. He had a couple of them on the Apollo/Vampire forums too....
That is a straight out lie, I only had one account and it was closed down.
If you think I have several, I challenge you to point them out and get the team to provide the evidence. And retract your statement, or else, I report you for slander.
-
Gold 2.7 still uses FEMU. It might be tuned for Apollo, but FEMU isn't the first 6888x emulator for fpuless 680x0 systems
Erm.
Then i need quote again what i told here :
Lol no. Speaking of Gold2.7, it is hardware implemented. Quite all 040 fpu instructions are, all Ea modes are, Registers are. It is clear that only some 881/2 instr are software emulated. And even for the emulated ones they benefits of the hardware implementation. EA computation is done by hw for example, and also castings and primitives, which helps lower (and simplify) the emulation overhead by an important factor.
The FPU in GOLD2.7 is HW. Just as 040 and 060 FPU is ! With only little differences. Then the emulated instructions are no more FEMU related, strictly speaking. FEMU was written with F-TRAPS mechanic and with OS MATHLIBS calls. The GOLD2.7 embeds true HW FPU + a VECTOR mechanic for the emulated 881/2 instructions, that benefits also from the HW FPU Core, and do not relies on OS MATHLIBS anymore.
Seems to me you are speaking from old assumptions based on old progress. Since, the team worked hard to fit real FPU in the core. Before telling such assumptions (with so much certainty) you should at mimimum inform yourself on current status.
-
Here are some videos of the Apollo FPU at work in Gold 2.7.
Imagine 4.0 FPU version
https://www.youtube.com/watch?v=6fy7HFNp178&t=37s
CineMorph FPU version
https://www.youtube.com/watch?v=IrYxMsm_Xm8
FPU RTG DEMO
https://www.youtube.com/watch?v=BqvtjONlsD0&t=3s
Mini METAL SLUG FPU in a RTG Workbench Window
https://www.youtube.com/watch?v=FM7F3VLw_lk
Quake FPU
https://www.youtube.com/watch?v=w2S4suHf-l8&t=173s
Vista Pro Makepath FPU
https://www.youtube.com/watch?v=I3XycCr5KRM
-
Gold 2.7 still uses FEMU. It might be tuned for Apollo, but FEMU isn't the first 6888x emulator for fpuless 680x0 systems.
Which means that grond is posting false data, or data from another system, but a software-only emulator will not go down to 1 clock cycle per addition.
Clearly, a hardware FPU is not an easy thing to do - even more so as you have to emulate all the flags and exceptions correctly. And the 68882 has awful many of them. Again, most of the programs do not even bother, but who knows....
Which means it won't bite you in the ass until it's too late.
Pretty much. I do not care too much about the FPU in first place as the number of Amiga programs that depend on it is pretty low, and there is nothing amonst them I personally require. (-:
But anyhow, a solution would be to use the hardware FPU as long as the precision setting of the 68882 is "double" or below, or the "double-only" instructions are used, and fall back to software if it matters - which is not too often.
-
That is a straight out lie, I only had one account and it was closed down.
If you think I have several, I challenge you to point them out and get the team to provide the evidence. And retract your statement, or else, I report you for slander.
Report me for slander? That's pretty funny coming from a guy whose entire life revolves around slandering Gunnar and the Apollo/Vampire project and whose account on the Vampire forums was closed down due to "slander"!
-
I sometime consider kolla as part of Apollo Team considering how much time he invests around it :-)
As OP of this thread, I thank him for bumping it up. It's like free marketing.
-
@ThomasRichter
By "hardware" 882, I'm simply referring to the fact that the transcendenal operations were handled by the 882 itself and not with some CPU exception and call out to software as in the 040/060.
All said, I'm not bothered. My assumption that the 882 implementation came at a large expense in terms of gates which apparently it doesn't, so that's great
-
@ThomasRichter
By "hardware" 882, I'm simply referring to the fact that the transcendenal operations were handled by the 882 itself and not with some CPU exception and call out to software as in the 040/060.
All said, I'm not bothered. My assumption that the 882 implementation came at a large expense in terms of gates which apparently it doesn't, so that's great
-
Firstly, IRC logs come for free when you use irc services like znc etc, not like I hang out logging manually using amirc or whatever.
Secondly, I have nothing against software emulation of 68882 instructions, that's after all what we have been doing since 040 and it works well.
First of all there is nothing in vampire remotely emulating anything. Not the FPU, not the CPU, not the graphics card, not the audio, nothing. Everything is real and custom chipset as Amiga can ever be! This here indicate your true ignorance at of the highest level. Everything you are doing is hurting and bashing a great project, a project that would easily take the Amiga out of the dark ages to the new bright light sunshine.
Second of all, all your posts show how ignorant you are and don't know what you are talking about. Stop it! Your posts are all exhausting and I am tired of reading your posts and all your doing is making it even harder for people to come to the amiga.org and turning this website into nothing more endless troll fast.
YOU ARE THE WEAKEST LINK!
-
This must be another one of Kolla's duplicate accounts. He had a couple of them on the Apollo/Vampire forums too....
It's this. Rather than participate in any technical part of the discussion, you come up with this bull.
If you Google my name, you'll see that I'm not private about who I am and use the same name in many places. So, either you're accusing Kolla of having a VERY elaborate, multi-site, multi-year set of false profiles, or you're accusing me of being Kolla.
In reality, it's easy to dismiss you because 1) you've added literally nothing to the discussion with your comment, and 2) you failed to spend even sixty seconds to look in to anything before posting your comment.
If you can't take ONE MINUTE to look in to something before making an accusation, how can anything else you say be taken seriously?
-
To clarify my position, I'm not saying that a wonderful extended instruction set, MMU and/or FPU are in any way a bad thing. If we're to have a technical discussion, though, I assert:
The CPU's instruction set, the FPU's implementation, and the MMU do not need to be incompatible with existing m68k CPUs in order to implement additional features. If you disagree, please go in to technical detail.
That's all. I'll buy a Vampire when I can use it as a super-speed m68k for software development and testing. Or, if it never becomes a compatible super-speed m68k, I won't buy it. But I'm hoping.
-
It's this. Rather than participate in any technical part of the discussion, you come up with this bull.
If you Google my name, you'll see that I'm not private about who I am and use the same name in many places. So, either you're accusing Kolla of having a VERY elaborate, multi-site, multi-year set of false profiles, or you're accusing me of being Kolla.
In reality, it's easy to dismiss you because 1) you've added literally nothing to the discussion with your comment, and 2) you failed to spend even sixty seconds to look in to anything before posting your comment.
If you can't take ONE MINUTE to look in to something before making an accusation, how can anything else you say be taken seriously?
There's no point in any technical discussion with you or Kolla. Several people who are much more technically inclined have engaged you both and shown your rants and arguments to be fallacies and slander, yet you persist....so I choose not to feed you trolls nor waste my time with you. And it wouldn't be the first time that a user created multiple profiles in a particular forum. It's been done here as well as over at the Vampire forums. They're generally quite easy to pick out. And if you are who you say you are, then why are you even getting riled up about it? Methinks thou dost protest too much.
-
There's no point in any technical discussion with you or Kolla. Several people who are much more technically inclined have engaged you both and shown your rants and arguments to be fallacies and slander, yet you persist....
That is a lie. Nobody technically inclined has engaged and all I get is rants and arguments from those who do.
You must be a Trump supporter.
-
Godwin point isnt far anymore.
-
That is a lie. Nobody technically inclined has engaged and all I get is rants and arguments from those who do.
You must be a Trump supporter.
You're hilarious! Gunnar (and several of the Vampire team) have engaged Kolla on various occasions but I suppose in your world where you believe you're the God-of-all-Things-Tech that Gunnar just isn't worthy, nor his team members. Thomas Richter has also made you look quite foolish but apparently you haven't even realized it.
You must be a Bernie Sanders supporter......or just an Athletic Supporter, AKA Jock Strap. How's that for taking 3 steps back from Godwin's Law! LOL!
-
I invoke the all mighty pancakes.
-
To feed the technical background of this thread, and not the trolls,
this article can help have better overview of the soon to come Vampire FPU :
http://www.apollo-accelerators.com/wiki/doku.php/fpu
For sure it help clarify some questionings.
-
To feed the technical background of this thread, and not the trolls,
this article can help have better overview of the soon to come Vampire FPU :
http://www.apollo-accelerators.com/wiki/doku.php/fpu
For sure it help clarify some questionings.
Nice to see the clarifications regarding precision.
-
Nice to see the clarifications regarding precision.
Yeah, it seems current FPGA is not worth buying if you want full FPU compatibility.
"Reduction is in discussion and depends of the space remaining in FPGA, either 64bits or little less."
So you might not even get 64 bits.
There has obviously been some changes, because only a little while ago gunnar posted
http://www.apollo-core.com/knowledge.php?b=2¬e=8608&z=n_Z6rb
"FPU performance improved a lot with new FEMU and GOLD 2.7
While the wiki says "The current FPU Core is NOT anymore based on the FEMU program."
Which is good that they come round at least in some ways to the correct way of thinking (unless they just did "rename FEMU FPSPcode").
"Those instructions are handled using some optimized FPSP code.
The FPSP code is instantiated using a new dedicated FPU Vector."
I'm not against emulation at all, I consider Apollo an emulator after all, I just want it hidden from view so that it is 100% compatible. So that Vector is a problem to me.
It's not like you need it to be user visible.
So still some time to wait for them to figure out that 100% compatibility is the way forward, who knows what will actually get released though.
"Some of the following specifications might change in final GOLD 2.7 release."
-
Yeah, it seems current FPGA is not worth buying if you want full FPU compatibility.
"Reduction is in discussion and depends of the space remaining in FPGA, either 64bits or little less."
So you might not even get 64 bits.
There has obviously been some changes, because only a little while ago gunnar posted
http://www.apollo-core.com/knowledge.php?b=2¬e=8608&z=n_Z6rb
"FPU performance improved a lot with new FEMU and GOLD 2.7
While the wiki says "The current FPU Core is NOT anymore based on the FEMU program."
Which is good that they come round at least in some ways to the correct way of thinking.
But of course there is still some emulation going on & it's not 040/060 compatible, which for me is still bad.
"Those instructions are handled using some optimized FPSP code.
The FPSP code is instantiated using a new dedicated FPU Vector."
And who knows what will actually get released.
"Some of the following specifications might change in final GOLD 2.7 release."
It really looks like to me you either need buy some better glasses or learn how to read. The FPU is clearly 040/060 fpu. You are tiring man. Remains only the precision which is only a choice related to fpga contrainsts while not impacting compatibility that much according to all videos/witnesses from the beta testers.
-
It really looks like to me you either need buy some better glasses or learn how to read. The FPU is clearly 040/060 fpu. You are tiring man. Remains only the precision which is only a choice related to fpga contrainsts while not impacting compatibility that much according to all videos/witnesses from the beta testers.
Beta testers running existing software does nothing to prove 100% compatibility.
In thirty seconds you could break it by overwriting the FPSP Vector. Real hardware won't care, Apollo will fail to run certain instructions.
I don't actually care whether it uses emulation, I consider Apollo an emulator after all. But that FPSP vector is a problem. If he hides it so that it's no longer visible then that would be fine. Ultimately I'd like to see it compatible with FPSP 040/060 packages, they are software after all.
64 bit precision might not worry you or the beta testers, but it's not 100% compatible. Maybe it runs most scene demos fine, they admit that is all they care about. If they run out of FPGA space and they have to drop down from 64 bits (which they say they might do) then I'm sure they'll start caring less and less about scene demos as well. I also made it clear that I accept the FPGA is limited, which is why I explicitly pointed out that current FPGA isn't for people who want 100% compatibility & it's definitely worth waiting.
Your response is an indication of Apollo trolls. I guess we have to keep putting up with you until Gunnar accepts to make it 100% compatible by hiding the floating point software emulation and the new FPGAs are available.
Of course we'll go back to the MMU and having to listen to all the reasons we can't have a compatible one, then one day magically it will be a good idea after all.
-
@psxphill
You seem to have no understanding of precision and compatibility in this case, these are two totally different concepts.
-
What is a default precision on UAE without Softfloat FPU emulation lib?
-
@phxphill
Indeed the emulation vector access is protected, supervisor mode needed, on a vector that no amiga-land software knows about it. Hard to break. At least not less than an 040/060/HSMath library.
About precision, sure, it then is enough or NOT for a given end-user. Your choice and need, i have no problem with that. That said, even 32 bits of precision would be enough for real life usage / games and demos applications, such as in most of the consoles (PSX,...). For Quake or let's be mad Gran Turismo, 32 is enough, like any games on such machines. If the point was to use the vampire for scientific researches, then sorry about that, it is not intended to.
About emulation, that is for me infinite discussion where FPGA coding is NOT emulation! I wont argue not a single one more on this.
At end, i'm the one who had bring the more technical data here about this fpu topic, I could also bring more about for example the 100% pipelined feature. Hope it helps the people for who the vampire is targeted to. The team is not trying to convince everybody but to bring a fpu solution at best as it could be on a given board for his customers.
-
Hmm..
Maybe Gunnar should consult with phxphill on how to implement the Cpu/Fpu on the Fpga... and Kolla too, they seem to know what they are talking about...
-
It all depends how much lower the precision really. 64-bit and higher is generally not used except for some niches like fractal zooming at high iteration. Games and many graphical applications use 32 bit. Just take a look at modern GPUs to see how much resource is given to single precision compared to double.
-
@psxphill
You seem to have no understanding of precision and compatibility in this case, these are two totally different concepts.
No, they are not different concepts.
100% compatibility means running the same code on real hardware and apollo will yield the same results. If your precision is different then it won't.
Plus the FPSP vector affects compatibility.
Hmm..
Maybe Gunnar should consult with phxphill on how to implement the Cpu/Fpu on the Fpga... and Kolla too, they seem to know what they are talking about...
Well it seems our posts here are having a result (if a little slowly). So maybe that would be a good idea.
It all depends how much lower the precision really. 64-bit and higher is generally not used except for some niches like fractal zooming at high iteration. Games and many graphical applications use 32 bit. Just take a look at modern GPUs to see how much resource is given to single precision compared to double.
If you aim your emulation at a fixed set of software then sure you can get away with it, but then you can't honestly claim 100% compatibility. Some people will of course not care if they are mislead, because they already drunk the kool aid.
-
If you aim your emulation at a fixed set of software then sure you can get away with it, but then you can't honestly claim 100% compatibility. Some people will of course not care if they are mislead, because they already drunk the kool aid.
Who's claiming the opposite ?
That is always a compromise.
One can prefer a real 060 @ 100MHz, i'm happy for those who have such an accelerator. But please keep in mind what the Vampire offers for a much lower price than a '060 accel + graphics board.
The FPU article purpose is to not mislead, so take it as it is, or use another product. We understood clearly this product is not for you, or that it could have been with some different approaches. That's all OK. Everybody is free to choose the product that fits best his tastes. But arguing infinitely is little annoying, i think you understand that.
About "Plus the FPSP vector affects compatibility". Well, FPSP always affected the compatibility, slightely or not, that is already the case with existings 68Ks (a 030 is not a 040 and is not a 060, and all ended in different FPSP supports and so in different compatibility). We are speaking here of obvious things.
Now to deal with real facts than blabla, we could also find some programs that do not works OK in WinUAE and tell which of those are so importants.
WITH "Softfloat FPU emulation lib" == 80bits
WITHOUT "Softfloat FPU emulation lib" == 64bits
All in all, of course, i agree, precision level ends in a different compatibility - in absolute - but in practice this often do not matters a lot, and have to be put in some perspective, to a given priced product.
-
It all depends how much lower the precision really. 64-bit and higher is generally not used except for some niches like fractal zooming at high iteration. Games and many graphical applications use 32 bit. Just take a look at modern GPUs to see how much resource is given to single precision compared to double.
Actually, no. Almost no software uses the single precision libraries, i.e. mathieeesingtrans and mathieeesingbas. Actually, I know exactly zero software that uses it. Then we have mathieeedoubbas, which is somewhat popular. Then, for the quick'n dirty, and for low-end systems, we have mathffp and mathtrans, but these run without FPU, have a bloddy stupid math model, but are fast on FPU-less systems. They are actually in some use.
Then we have those programs that use the FPU directly. It now all depends on how the FPU was configured. If the author did nothing, the FPU runs in full 80bit precision. Whether that precision is really required for the application is another story, of course.
However, multiple things can be said:
- IEEE single precision is in almost no active use
- If single precsion is used, it is mathffp and mathtrans (CPU only)
- If the math libraries are used, it is all double precision.
- If FPU only code is used, chances are better than even that this is 80bit
Hence, results will be (slightly) different on a system that runs only with 64bit instead of 80bit. Whether this matters depends on the application, but there will be a difference.
-
I guess you are referring to the tests of the individual FPU instructions. This is not testing the FPU.
October 4. 2016:
2016-10-04 [16:42:02] We said we our FPU is in testing - correct
-
What is a precision on AmigaOS 4 with PPC 440ep?
-
What is a precision on AmigaOS 4 with PPC 440ep?
64bits
What is a default precision on UAE without Softfloat FPU emulation lib?
64bits
This is called pragmatism.
-
http://forum.apollo-accelerators.com/viewtopic.php?f=9&t=1867
New info.... for the guys stuck in 2016 like kolla
-
I cannot belive you guys are arguing about "100% compatibility" when we all know thats IS, and never was a thing. In the case of future software working on non apollo hardware thats a problem created by the developers and not apollo.
-
@ThomasRichter
I think you are overstating the case. Warp3D, MiniGL etc use 32 bit floating point almost exclusively, as does quake. In fact, there original source assembler hacks in the x87 versions to explicitly set the precision to 32-bit.
Applications using the libraries you describe are by definition not compiled for any FPU as they are relying on libraries which in turn may use FPU. Binaries compiled to use FPU directly generally will use whatever precision their use case demands. For games, that's almost exclusively 32 bit
-
Beta testers running existing software does nothing to prove 100% compatibility.
Unlike forum bitching which improves compatibility by 400%. Therefore Apollo is by far the most compatible thing on this planet.
In thirty seconds you could break it by overwriting the FPSP Vector.
That's all fine and dandy, but what about Vector Sigma?
-
All in all, of course, i agree, precision level ends in a different compatibility - in absolute - but in practice this often do not matters a lot, and have to be put in some perspective, to a given priced product.
Of course it's a personal choice. But there is no point in arguing that a Skoda Fabia is faster than a Bugatti Veyron and then start talking about affordability.
I cannot belive you guys are arguing about "100% compatibility" when we all know thats IS, and never was a thing. In the case of future software working on non apollo hardware thats a problem created by the developers and not apollo.
According to some people the Apollo already is 100% compatible and claiming anything else is heresay lest it might upset the gods.
The FPU article purpose is to not mislead, so take it as it is, or use another product. We understood clearly this product is not for you, or that it could have been with some different approaches. That's all OK. Everybody is free to choose the product that fits best his tastes. But arguing infinitely is little annoying, i think you understand that.
I wasn't suggesting the FPU article was misleading, but people on this thread make various sycophantic claims in support of Apollo which contradict the FPU article.
About "Plus the FPSP vector affects compatibility". Well, FPSP always affected the compatibility, slightely or not, that is already the case with existings 68Ks (a 030 is not a 040 and is not a 060, and all ended in different FPSP supports and so in different compatibility). We are speaking here of obvious things.
Yes, but those things exist already and have existed for 20 years. Creating new incompatibilities when there are alternatives is less than ideal IMO.
Unlike forum bitching which improves compatibility by 400%. Therefore Apollo is by far the most compatible thing on this planet.
In September the 2.7 gold was based on FEMU, much forum bitching later and now 2.7 gold is not based on FEMU.
http://www.apollo-core.com/knowledge.php?b=2¬e=8608
Now I can't conclusively prove that the bitching had any effect, but the people claiming that FEMU was superior to emulating the 6888x natively must feel really silly now.
-
In September the 2.7 gold was based on FEMU, much forum bitching later and now 2.7 gold is not based on FEMU.
http://www.apollo-core.com/knowledge.php?b=2¬e=8608
Now I can't conclusively prove that the bitching had any effect, but the people claiming that FEMU was superior to emulating the 6888x natively must feel really silly now.
That's called progress....
You don't seem to get 080 is a new generation 68k CPU. Like the most of the line, it brings up some incompatibilities or better said, new features... It doesn't seem the goal was to mimic any previous 68k but to improve all of them...
-
http://forum.apollo-accelerators.com/viewtopic.php?f=9&t=1867
New info.... for the guys stuck in 2016 like kolla
"new info" is a constant with this project, very often contradictory and misleading info.
Well, at least one can now point at something when minions are screaming that there is no software emulation taking place. Also I like that it says "host memory", one can then speculate what is meant with "host".
-
In September the 2.7 gold was based on FEMU, much forum bitching later and now 2.7 gold is not based on FEMU.
http://www.apollo-core.com/knowledge.php?b=2¬e=8608
Now I can't conclusively prove that the bitching had any effect, but the people claiming that FEMU was superior to emulating the 6888x natively must feel really silly now.
You really don't understand or don't want understand the fact that the FPU was in a work in progress state at this time.
Let's summing up this once again :
the FPU was always a part of the roadmap of the 68080, as the AGA integration too. At some point, the team decided to begin the work on the AGA integration. In fact, this work is allready advanced. Why the AGA and not the FPU ? Because the team always said that we need some help to write some test cases to begin the work of the integration of the FPU. Yes, the integration and not the creation, because the base of the FPU was already there since a long time. Because we didn't had the resources to make those testcases at this time, we decided to go the AGA integration road. This this as simple as that.
Then, Jari came up with the will and the competence to make FEMU. FEMU was not only a big amount of work letting all Amiga without a FPU running software demanding it, it was the needed basis for testing the hardware FPU integration too. Thanks FEMU, the team could isolate all instruction one after one to test it and to validate it into the hardware implementation. This was a big amount of work, and I can tell you that many hours/week-end was spend on this testing. Like TuKo said in the february update, more than 2400 core was compiled for this testing process.
So, no, this is not the constant bitching on the forums that brought the hardware FPU to the 68080, but the hard work first from Jari then from the whole team to make it real.
-
Another reason why AGA was judged as higher priority... the standalone devices need it
-
@psxphill
you (and obviously kolla) do not understand what the project is about... it is not about a 100% compatible FPGA based excelerator but a kind of NG 68k hardware and it is a moving target so priorities can change over time. SAGA f.e. has higher priority than FPU (or a compatible MMU) have because you need it for all devices, expecially for the standalone versions. Kolla bought it because he expected it more or less as a affordable accelerator with more ram and now realizing that this is not the goal he uses most of his time to badmouth the people behind. Also there are others who requested that vampire would integrate in existing hardware but that is also not the goal because vampire (or future standalone devices) more or less replace existing extensions. People who want that should better not buy vampires but buy existing accelerators. The same is true for people like kolla who are mainly interested in something 100% compatible. That is all nothing new but was explained several times already.
-
In September the 2.7 gold was based on FEMU, much forum bitching later and now 2.7 gold is not based on FEMU.
Yes, this is exactly how Apollo team works. The more you bitch and belittle their work the more they rush to cater to your wishes. It's not like they have their own roadmap and agenda.
One could argue that you are actually the hero everyone should thank for all these wonderful Vampire cards we have now. And you will make them even better gosh darnit!
-
Yes, this is exactly how Apollo team works. The more you bitch and belittle their work the more they rush to cater to your wishes. It's not like they have their own roadmap and agenda.
Did you know that you can induce superstitious behaviour in chicken?
https://www.jstor.org/stable/40032017?seq=1#page_scan_tab_contents
“In one of my college psychology courses we did an experiment that shows how superstitious behavior can be induced in chickens. The routine is to feed the chicken at random intervals. Unaware of what is triggering the appearance of bits of food, the chicken naturally assumes that its behavior is meaningful, so it tends to repeat whatever it was doing in the moment before food appeared. Before long the bamboozied bird is repeating whole series of behaviors in an attempt to do whatever it is that needs to be done to get more eats.”
Replace "Food" with "core release" or "feature" and "behavior" with "forum rants" and it becomes clear that the Apollo project itself is responsible for all those rants from superstitious chickens...
-
So, I figure it is time to go back to what started all this hoopla the last few days....
No SAGA will be on both, AGA features will be on Gold 3.
It's a real FPU solution, no software emulation. Stop spreading %&$#?@!%&$#?@!%&$#?@!%&$#?@! you don't know.
So who was spreading whatever you don't know?
-
@psxphill
Kolla bought it because he expected it more or less as a affordable accelerator with more ram and now realizing that this is not the goal he uses most of his time to badmouth the people behind.
Not true.
* It was never a question of "affordable" for me.
* I already had/have classic systems with more RAM (a lot more)
* I had questions about software compatibility which were consequently refused to be properly answered (or as you say, "bad mouthing")
* I was told "you don't even have a vampire, so what do you know - STFU!"
* I was told that once I had a card and could witness with my own eyes, all my doubts and concerns would vanish. They didn't, rather they confirmed them.
* and maybe most important - when I ordered them, I was at a beer festival.
I had hopes for something that would make the A600 worth while as an animation, audio and music "retro workstation", using old and new Amiga software for music, audio, graphics and animation. This includes using various audio transformation tools, of which quite a lot require, or greatly benefit from FPU. Likewise for graphics.
What really made my "go on a mission" so to speak, was the words and attitudes central people in team used about other hardware manufacturers, and about certain well known developers. The "idiots" and the "enemies".
-
Sorry to disturb this VERY interesting and HIGHLY informative discussion about kolla but...
GOLD2.7 PreRelease JIC :
http://www.apollo-core.com/releases/V500_GOLD2.7pre-4906.jic
(V500 V2(+) only yet)
-
What really made my "go on a mission" so to speak, was the words and attitudes central people in team used about other hardware manufacturers, and about certain well known developers. The "idiots" and the "enemies".
Wow, you're a classic case of obsessive compulsive disorder compounded by paranoia. Seek some professional help for everyone's sake, including your own.
-
So, I figure it is time to go back to what started all this hoopla the last few days....
So who was spreading whatever you don't know?
We both are, you more so. For me it's ignorance, for you it's a mis-information and smear campaign.
-
you guys will need this to flash that JIC
http://dl.altera.com/13.0sp1/
Have fun
-
you guys will need this to flash that JIC
http://dl.altera.com/13.0sp1/
Have fun
and USB-blaster :)
-
also before kolla jumps on it : and a Vampire.
-
Cool!, 2.7 prerelease and i don't own an Altera programmer, ordered one on ebay now only 4 usd :D.
-
First of all there is nothing in vampire remotely emulating anything.
Maybe time to rephrase?
-
We both are, you more so. For me it's ignorance, for you it's a mis-information and smear campaign.
Maybe if you were less ignorant, you'd realize that this is not a smear campaign and more an attempt to open the eyes of people. As I have mentioned quite a few times, I encourage everyone, as many as possible, to buy vampire cards.
-
Wow, you're a classic case of obsessive compulsive disorder compounded by paranoia. Seek some professional help for everyone's sake, including your own.
I am perfectly fine thanks, how about you? And how's it going in your search for my alter egos over at apollo-core forums? How many accounts do I have? Double digits? Maybe ask Gunnar for help.
-
If you want to bash the Vampire as an accelerator that's fine.
However, the average person jumping in this thread is getting a polluted image of the Apollo core.
The Vampire is using a SUB_SET of the full Apollo core because it is using a smaller FPGA and so features were removed. As described in a link a page or so ago, some reworking was done to make space for an FPU in the Vampire accelerator board. No sacrifices will need to be made for future boards with larger FGPAs.
-
The Vampire is using a SUB_SET of the full Apollo core because it is using a smaller FPGA and so features were removed. As described in a link a page or so ago, some reworking was done to make space for an FPU in the Vampire accelerator board. No sacrifices will need to be made for future boards with larger FGPAs.
Alot of the discussion lately is when I was criticised for wanting to wait for a large FPGA.
you (and obviously kolla) do not understand what the project is about... it is not about a 100% compatible FPGA based excelerator
Why am always being told it is 100% compatible?
Then, Jari came up with the will and the competence to make FEMU.
Because he got tired of the bitching. I still remember the times that Gunnar said we don't need a 68k compatible FPU.
-
I am perfectly fine thanks, how about you? And how's it going in your search for my alter egos over at apollo-core forums? How many accounts do I have? Double digits? Maybe ask Gunnar for help.
The only person here needing help is you.
-
The only person here needing help is you.
So please help me - start by finding those accounts you accuse me of having.
-
If you want to bash the Vampire as an accelerator that's fine.
Not really, the Vampire cards are great piece of hardware.
However, the average person jumping in this thread is getting a polluted image of the Apollo core.
Or "nuanced", an image not glorified with only superlatives and hype.
The Vampire is using a SUB_SET of the full Apollo core because it is using a smaller FPGA and so features were removed. As described in a link a page or so ago, some reworking was done to make space for an FPU in the Vampire accelerator board. No sacrifices will need to be made for future boards with larger FGPAs.
Was there ever an FPGA running "the full Apollo core"?
Has anyone seen "the full Apollo core" run?
Does "the full Apollo core" even exist yet?
Will it ever? Or will "the full Apollo core" always be "the next big thing"? Remember, V2 was supposed to support "the full core", and V1 had the "limited edition" (known as Phoenix).
Time will tell.
Oh, did anyone else license Apollo Core yet?
-
@thread
guys, things are getting really personal in this thread, and it needs to stop. here's a pro-tip: if you're accusing someone of mental illness, chances are, you're going too far. if i start seeing these types of insults again, we'll start handing out temporary posting restrictions.
we're all supposed to be friends around here. let's keep it that way. :)
-- eliyahu
-
GOLD 2.7 Release
Files to be used with USB-Blaster
For V500
http://www.apollo-core.com/releases/V500_GOLD2-7.jic
For V600
http://www.apollo-core.com/releases/V600_GOLD2-7.jic
AMIGA Flash-EXE files to allow updating without Blaster will be released in some days.
Main features:
* Fast Hardware FPU (to play some games or Demos)
* AMMX2 (to highly accelerate Video, Jpeg, Workbench, many games)
* High performance Memory controller (Making your Vamp even faster now)
* Workbench Hardware Sprite
* Countless improvements
Matching AMMX2 accelerated RTG driver
http://apollo-accelerators.com/files/SAGA/SAGADriver.v1.0.lha
Original from:
http://www.apollo-core.com/knowledge.php?b=6¬e=12868
-
The Amiga flash exe files for Gold 2.7 Release are available now.
Available in a public release for the first time are x12 (>85MHz) core JIC Files. USB blaster, Quartus software and stable Vampire power circuits required (some boards need capacitor mods).
http://wiki.apollo-accelerators.com/doku.php/start#latest_core (http://wiki.apollo-accelerators.com/doku.php/start#latest_core)
-
Yes, I posted a new, this morning but apparently it was not validated.
-
There's no point in any technical discussion with you or Kolla. Several people who are much more technically inclined have engaged you both and shown your rants and arguments to be fallacies and slander, yet you persist....so I choose not to feed you trolls nor waste my time with you. And it wouldn't be the first time that a user created multiple profiles in a particular forum. It's been done here as well as over at the Vampire forums. They're generally quite easy to pick out. And if you are who you say you are, then why are you even getting riled up about it? Methinks thou dost protest too much.
Ummm... What? You must be confused. Please let me know where this supposed technical discussion can be found.
-
Ummm... What? You must be confused. Please let me know where this supposed technical discussion can be found.
Over at the Apollo/Vampire forums where he was banned for constant trolling, constant arguments with Gunnar and Vampire team members, and for his relentless misinformation campaign.
-
I was blocked from posting unless I send copy of an ID card, but why would I trust them with that kind of information. And... what misinformation specifically?
-
I was blocked from posting unless I send copy of an ID card, but why would I trust them with that kind of information. And... what misinformation specifically?
Because one would assume assume they were trying to determine if certain users had multiple accounts on the same forum....
And what type of misinfo? The same crap that you're spreading on very thick here at this forum.
-
I was blocked from posting unless I send copy of an ID card, but why would I trust them with that kind of information. And... what misinformation specifically?
No prob... use this ID
-
Mjnurney recording of his expriences with the X12 core 2.7.
https://www.youtube.com/watch?v=Vb5fL1ivNMo
-
Over at the Apollo/Vampire forums where he was banned for constant trolling, constant arguments with Gunnar and Vampire team members, and for his relentless misinformation campaign.
So you're still trying to imply that I'm the same person as Kolla?
I'd seriously appreciate it if you didn't reply to my posts unless your reply was about some technical aspect of this discussion. On the other hand, I can't stop you, but keep in mind that you're the one who looks like an idiot for replying to me as if I'm Kolla.
-
@johnklos
OFFTOPIC:
Do you still have those lovely 68k Amiga servers? I remember one of them was a racked based 68060 Amiga called "Lillith". It was a beatifull sight.
-
@johnklos
OFFTOPIC:
Do you still have those lovely 68k Amiga servers? I remember one of them was a racked based 68060 Amiga called "Lillith". It was a beatifull sight.
http://lilith.ziaspace.com (http://lilith.ziaspace.com)
I do! The 1U rackmount Amiga 1200 was recently recapped and is happily compiling away. Yay! It's not the machine hosting that page right now because I'm moving, but it will be on the public Internet again soon.
My Amiga 4000 server still needs a full recap. Trying to compile all 17,000 NetBSD pkgsrc packages with just one m68060 (and a 1U Quadra 605 with a 33 MHz m68040) is a bit impractical. I'm looking forward to getting a Vampire 500 v4 in to the mix.
Since it appears that a fully compatible FPU is now part of the latest software release, the only thing left is the MMU. Of course, that's a huge undertaking, but I'm glad we're no longer splitting hairs about the FPU. In the interest of having great speed and 512 megs of memory, I may even try my hand at redoing the memory management in NetBSD to work with the MMU features that are already implemented, even though they're not Motorola compatible.
Supporting the SD card and ethernet should be straightforward. It might be time to buy one. Does anyone here have any experience installing one in an A1000? I don't have an Amiga 500, but I do have an Amiga 1000...
-
@johnklos
You should wait for v4 so you get a proper FPU, the current one for V2 is _not_ fully compatible.
-
@johnklos
You should wait for v4 so you get a proper FPU, the current one for V2 is _not_ fully compatible.
Good point, as yes the core is continuously improved. I have tested most everything I used back in the day in terms of FPU such as lightwave3d, Imagine, TV paint, Image FX and Cinemorph. I do use newer game / utility port that have the odd FPU support without issue. Remember about a year ago the FPU didn't exist much if at all, now FPU is mature and AGA is being worked on and I have played with it, quite nice so far.
my youtube channel has lots of videos that prove FPU compatibility for those that want to take a look at the proof of a working FPU and form an opinion based on evidence.
https://www.youtube.com/channel/UC-e2UJqyweliyV1CLzhQAiA
Here is a cool video (not mine) of the Vampire 2 Amiga 600 running an RTG demo alongside an A1200 /060, looks compatible enough to me :)
https://www.youtube.com/watch?v=AlvRFTBsi4I&feature=youtu.be
-
http://lilith.ziaspace.com (http://lilith.ziaspace.com)
I do! The 1U rackmount Amiga 1200 was recently recapped and is happily compiling away. Yay! It's not the machine hosting that page right now because I'm moving, but it will be on the public Internet again soon.
My Amiga 4000 server still needs a full recap. Trying to compile all 17,000 NetBSD pkgsrc packages with just one m68060 (and a 1U Quadra 605 with a 33 MHz m68040) is a bit impractical. I'm looking forward to getting a Vampire 500 v4 in to the mix.
That is really cool. I hope you put Lilith back online soon.
I understand the need for a faster system given the workload you put on those machines.
I hope that you can solve it. Looking forward for a detailed review if/when that happens.
Thanks for the update. :)
-
So you're still trying to imply that I'm the same person as Kolla?
I'd seriously appreciate it if you didn't reply to my posts unless your reply was about some technical aspect of this discussion. On the other hand, I can't stop you, but keep in mind that you're the one who looks like an idiot for replying to me as if I'm Kolla.
No, I'm implying that Kolla had multiple accounts at the Apollo/Vampire forums which is ONE of several reasons why he was banned. No one apparently has asked you to produce your ID unless of course you really ARE Kolla. The level of protest that you're mounting here would make one almost suspect you and he are the same....but if you aren't that's fine. And apparently this forum welcomes multiple accounts by the same users. The users "Iggy" and "Beans" on this site are one in the same person and this person uses both of those accounts here quite often. Not sure why he'd want to use 2 accounts but maybe you should ask him.
-
No, I'm implying that Kolla had multiple accounts at the Apollo/Vampire forums which is ONE of several reasons why he was banned. No one apparently has asked you to produce your ID unless of course you really ARE Kolla. The level of protest that you're mounting here would make one almost suspect you and he are the same....but if you aren't that's fine. And apparently this forum welcomes multiple accounts by the same users. The users "Iggy" and "Beans" on this site are one in the same person and this person uses both of those accounts here quite often. Not sure why he'd want to use 2 accounts but maybe you should ask him.
So, i guess there are some on the forum who are not accepting of persons with multiple personalities.
-
No one apparently has asked you to produce your ID unless of course you really ARE Kolla.
Are you seeing things? it WAS Kolla that posted about the ID card.
I was blocked from posting unless I send copy of an ID card, but why would I trust them with that kind of information. And... what misinformation specifically?
-
No, I'm implying that Kolla had multiple accounts at the Apollo/Vampire forums which is ONE of several reasons why he was banned.
I repeat - please provide the proof or even a shred of evidence of this. You are not the moderator of the mentioned forum. Your claim is also _not_ specified as a reason for why I was "banned", and Gunnar has even "renamed" me back to my real name in my postings, which I find a bit amusing.
-
I repeat - please provide the proof or even a shred of evidence of this. You are not the moderator of the mentioned forum. Your claim is also _not_ specified as a reason for why I was "banned", and Gunnar has even "renamed" me back to my real name in my postings, which I find a bit amusing.
Show me some ID and I'll show you some proof. Glad you're amused with yourself because for the rest of us you're about as amusing as a wisdom tooth extraction.
And a rational adult who may or may not have had multiple accounts on the Apollo/Vampire forums or at Amiga.org would just ignore me and move on, but you get enraged and even admit that the Vampire/Apollo moderators asked you to produce your ID, which you refused to do.
-
Are you seeing things? it WAS Kolla that posted about the ID card.
Exactly! He had multiple accounts over at the Apollo/Vampire forums which is why one would suspect the same here.
-
Exactly! He had multiple accounts over at the Apollo/Vampire forums which is why one would suspect the same here.
Kolla posting something about Kolla is not proof that anyone else is Kolla though.
You seem to be jumping to conclusions.
and even admit that the Vampire/Apollo moderators asked you to produce your ID, which you refused to do.
What is that an admission of? Is he supposed to be ashamed that people online creepily asked him for photo id? It sounds more like victim shaming.