[UserReview] Vampire V2-128 received and it's just pure p0rn.

[kolla]

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.

[guest11527]

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.

[kipper2k]

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

[wawrzon]

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!

[wawrzon]

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.

[psxphill]

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.

[guest11527]

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.

[kamelito]

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

[kolla]

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!

[kolla]

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

[Niding]

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.

[guest11527]

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!

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.

[Djole]

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!

AFAIK (and been told) HAM8 is AGA only, a600 is ECS, so what are you talking about ??

[kolla]

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

[kolla]

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

[Djole]

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