Masjsta's A500 Vampire

[wawrzon]

You're right, I don't see the point. However at various times through development they've said they aren't really bothered about being compatible. The same with the MMU.

last i remember they (gunnar) have said the fpu (wip, not currently included) is compatible what concerns instruction set and precission.

this doesnt currently apply to mmu. even though it even seems to be on a todo list. currentl they are providing another module of similar functionality under acronym of mpu.

btw, experienced amiga hardware architect, krashan, seems to have similar opinion on neccessity of compatible mmu as apollo team..

[wawrzon]

Yeah, so it's neither compatible with the 68040 or the 68060.

i dont have a vampire, but in my eyes it is more compatible with both, then they are with each other. is this the reason to complain? or do you insist on using some particular 68060.library just for the sake of it? seriously, i dont understand your comments except its just nitpicking.. have you complained as well and refused to accept their products, when motorola delivered 040 and 060 without full backward compatibility, that had to be granted with libraries? have you refused to use 68k processors that dont do self modyfying code (without turning off the caches) that apollo seesm to handle transparently? because it sounds like you think, the apollo core is *too good* to be acceptable.

[wawrzon]

This is one addition that I really don't understand. What is the point of having Intel MMX instructions available on an Amiga? It's not like there is any software to take advantage of them is there?

im not that convinced either, though it dosent hurt, i guess..

[wawrzon]

the same as we do :/

then do something different if you are not satisfied with the results delivered for you.

[wawrzon]

Maybe then enough people will refuse to buy it until it's the way it should be done. If not then I'll buy something else.

is this your agenda? to make the people not buy something because you want to buy something else? why dont you do this right away, and tell us if there is a better alternative?

That is how people put pressure on companies to provide them the services they want. Or are you saying I'm not allowed to do that?

it is not a company. it is an initiative composed of volontary members so far. at least thats what i know. do you think you are free to "put pressure" on everyone just in order to deliver you with "services" you expect?

If that is official then I don't see why they haven't made a big fuss over the turn around..

maybe you simply overhear any actual information, while making "big fuss" yourself? you might simply tone down a bit.

I would still like the ability to only emulate 68060 instructions in the fpga though.

why? if actually all instructions are available? i could understand if you asked for an option that fpga core identifies as 060 instead of 040. but why remove instructions in order to be compatible with a cpu that needs libraries to emulate these instructions for compatibility?

however if you insist, why simply not keep the 060. and swap it every time you need physically with another sort of cpu. because next time you will complain that fpga is too fast anyway.

one way or the other i doubt you will stop anyone from buying vampire, its just wasted effort..

[wawrzon]

I'm more worried about "removing potential" by Gunnar making design choices of what he believes "is useful" and "what is not useful".

gunnar and his team have proven capacity to reconsider choices, even if not essential, as soon as they appeared to be within reach. may i mention bitfields again?

Granted, for the majority of Amiga users, the MMU is "not useful" and the FPU is "not useful", but maybe there are a couple of folks out there that believe that these units can be made good use of here and there.

i belong to the minority here. however you have seen gunnars roadmap on a1k i believe, where mmu is even mentioned along milesones, even if not as a priority. mpu being an interim solution.

id like to remind tg68k even if it has some 020 instructions hasnt have a mmu as well and none was much annoyed. some other hardware developer is looking at the tematic of fpga cores in poland and neither him considers mmu necessary. thomas, apollo core may not meet yours or mine expectations in some areas, but it doesnt mean its useless..

The current design is not the end of the story, of course, and I don't want to demand too much too early, but the general attitude seems to be that there is "no need for this nonsense", and that type of attitude is probably a bit dangerous.

no. its how you perceive this. people change their opinion. "no need for this nonsense" is a sensible strategy at a given point simply to silence uncountged requests you would have to consider otherwise. i cant even grasp how much endurence has already flown into this project, i cant see anything comparable in the neighbourhood. ths attitude proves to be succesful in their results.

There are other problems I foresee, as redefining the meaning of some of the Motorola opcodes. The current core puts the 68020 opcodes CALLM/RTM to some completely different use. Again, both instructions are worth nothing on the Amiga, have never been used, and cannot be used productively, but for a "clean room" implementation, I would prefer if the team would stick to the list of opcodes Mot defined in the 68K family guide, and simply trap for instructions that are unsupported, even if unsupported for a reason. The 68030 and up did not support these two (again, for good reason), but that does not mean that this particular opcode "is free for everyone's use". Leave it reserved, do not touch it - it only confuses development software such as debuggers or disassemblers that - with this change - can no longer decide what an opcode means without knowing the host CPU.

i understand the aesthetical aspect, that should probably be discussed but i applaud leaving such issues for later in order to spare ressources. if they are going to license the core outside amiga they might be forced to face the issues either way.

[wawrzon]

@psxphill

i think we all have understood your objections now.

[wawrzon]

You may. Though bitfields were more left out due to a size constraint of the earlier FPGA. It's really a less-used feature and it would have worked equally well to have them emulated in software. May I mention again that I wrote a software emulation for that part? (-:

right, however there have been constant uproar and bitching especially on eab because of missling bitfields, movep and whatever else. and some time after it eventually flattened out gunnar simply quietly delivered on it.

It's not the timing aspect I'm worried about. Whether this happens in two months or four years I do not mind so much, and I surely do not press anyone to have this as early as possible.

I'm a bit more worried about the implications on the design, and that - once such an extension is attempted - a lot of the current pipeline architecture probably has to go into the trash, and has to be re-done from scratch. Which approximately explains the enthusiasm by which this unit is approached. It is not like an FPU which can be implemented relatively orthogonal to the rest of the CPU.

Thus, my speculation rather is "If you do not plan for it right in the beginning, it will never appear". The motivation curve is not right. It seems so minor, but it requires many resources. Instead, I hear a lot of voices from the team why "I do not need this" - this gives me a very mood feeling that nothing in this direction will ever materialize because nobody is motivated enough to attempt a radical design change for something that looks "almost complete" and "good enough".

yes. i understand. but the design choices has been made and the problem exists already. it cannot be avoided anymore, it would have to be taken care properly with the same amount of effort independently whether it happens now or later. hammering on this and trying to force shifting their priorities immediately may only waste the project at this point. as you say, gunnar is professional. he may not share your opinion, but he certainly is aware if there is a problem.

[wawrzon]

I am not spreading false info, I may be saying things that are out of date & I've tried to put everything I've said in that context. However if the out of date info was widely spread and the new info is not, then it is not my fault.

ignorance may not always be taken as excuse;). especially given your insistence on the issue. i have an impression that you are expecting the "unfriendly overlord" to immediately inform you personally about all his doings and intentions. but there are ways to keep in touch (you have been pointed to, even if you missed on them) and i dont see anything around the project being kept secret on a purpose.

i can only ensure, your doubts are taken seriously ; )

[wawrzon]

What is exec.library? Where is that and for what purpose is used?

Its one of the kickstart modules, a kernel so to say, but id expect you to know that better than me;)..

[wawrzon]

Apollo is software and more importantly it's an emulator, it happens to be a not very accurate one but that is by design.

okay. but have you asked yourself, do this statements contribute anything useful to the effort or at least discussion? because if not, then stated once, we know your position on the subject. does that matter if one calls fpga or microcode "emulation"? especially as long as it reaches its goal? and if not, being "inacurate" its a field for improvment, that apparently is both possible and considered.

the actual problem would arise if there was no argumentation on thes subject allowed, or the issue was denied, but ist isnt the case, at least in my book.

[wawrzon]

actually this offtopic should be branched out from the genuine thread. i propose to call it "psxphill vs the rest of the world"

[wawrzon]

I believe I already gave the answer. Here it is again: The original CBM exec versions (or variants, if you prefer) all all based on the same source code, and hence can be maintained jointly. It is, as said, a software maintenance issue, not a general issue.

ah, here is it.. i already wondered what you are going about on a1k. so the issue is that the features of apollo core need (in your eyes) to be officially supported rather than patched in. and gues who has the access to the source code and who actually claims the right to distribute it.

btw. there is exec replacement, fully open with all the sources. it may be a bit slower in few operations. guess where to look for it

[wawrzon]

A processor library is all it takes.

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

[wawrzon]

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

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