> >> Z180 has new instructions.
> >Only very few, which are not that useful.
>
> Well... they are more usefull than those new on Z380... (-;
Not at all. Read the Z380 specs.
> The VERY USEFULL new opcodes on Z380 are just to control
> its new features: the new registers, the loooooooooooooong
> data range... (-; Remember that if its opcodes set is 200%
> larger than Z80 it means that almost a half of this are
> opcodes to do the same as Z80 but in 32 bit address range
> (32 bit LDs, 32 bit ADDs, SUBs, INCs... and so on).
UNTRUE!!!
Those are the same as the Z80 versions, but work different in another mode
(or havea so-called Data Directive (DDIR) opcode).
> The
> other are, mostly, operations with the new set of registers,
> and are equal to the Z380 opcodes for 32 bit LDs, ADDs, INCs,
> etc... So, you have 3 times the instructions of Z80:
>
> 1 time : the same Z80 opcodes
> 1 time : 32 bit opcodes for the same Z80 registers
Those are the same as the first. So this is incorrect.
> 1 time : 32 bit opcodes for the additional registers.
Those are very useful. Included are NOT ONLY instructions for handling the
additional register banks (you are greatly mistaking here, the register
banks are handled by internal I/O). New instructions feature relative calls,
EX almost all register sets, multiplication and dividing, and much more.
> ---------------------------------------------------------
> 3 times: 3 x the same functions in different implementations
It looks nice but it is totally incorrect. Maybe you'd better read the Z380
specs first before stating all this stuff...
> In fact, the USEFULL are not the new instructions, but the
> new registers. Which, of course, is a miss on Z180...
> (Z180 has new registers? I don't really know!)
It is absolutely not the only advantage over the Z180 (instructionset is
also greatly enhanced). But indeed, it has 32-bit registers (which can also
be used from 'legacy' mode using DDIR's (Data Directives)), and a very long
adress range.
> >> Z380 is not, AFAIK, 100% compatible with Z180.
> >The documented instructions are.
>
> This is good to know. So it'll be easier to cooperate them.
It'll open the way for the Z380 board to be compatible with Z180.
> >If this is not true, please consider not to use the extended Z180
> >instructions at all.
>
> (-; This is one option, but use it as "optional" for the program
> working (like MSX1/MSX2 and MSX2/MSX2+ Konami games) is something nice.
(-;
They can be used since they are the same on Z380.
> >Not that much, eh??? The R800 set is even better!!! (it features a 16-bit
> >multiplication!). No trace of a divide-instruction either...
>
> I was told it had... so if hadn't... it's sad... (((-;
You should really (again) read the Z380 docs!!!
(and maybe some Z180 too for comparisation)
> >Well, those instructions can be used, since they are the same on the
Z380.
> >However, preferrably not, because they aren't THAT useful, and it will
cause
> >the software not to work on a 'normal' Z80.
>
> Mult can be used... And it is "that useful". For disk programming,
> per example. (-; The 'times 9' to calc the sector.
No. The multiplication instructions are only faster when both values are
unknown, because that would require a quite slow routine, which can be
replaced by an instruction. However, when one of the values is known (in
this case, the 9), you can do it faster by doing something like:
ld b,a
add a,a
add a,a
add a,a
add a,b
At least, on the R800 that's true.
I just reviewed the docs, and a MLT would take 7 cycly, while the above
would take 10 cycly. But then again, I never said it was unuseful (in fact,
I referred to MLT and TST as being the only useful instructions).
> >On the Z380 they are on
> >the same location as on the Z80. By the way, on the Z380 IXh is renamed
to
> >IXu... Stupid.
>
> ((((-; They like to change names. (-;
It was worse on the R800... Most instructions remained the same (actually,
all, except for IXh(igh) which became IXu(pper)).
> >The Z380 has really too much new opcodes to name here now...
>
> Yes, it has, but almost all of them refers to new resiters...
> (like I said a above).
WRONG!!!
> >IN F,(C) is not available in either of the processors.
>
> Read port on Flag register?
I don't know how it works exacly. It was there on the R800 and also (a bit
more limited) on the Z80 as undocumented instruction.
If I remember correctly it did about the same as IN A,(C) : AND A. But then
without involving A ofcourse.
> >The Z180 as well as the Z380 can 'trap' undefined opcodes...
> >This could be very useful.
>
> Yes... this is VERY usefull if you want to emulate Z380 opcodes on
> Z180, via software. per example! (-;
Indeed. It will be slow, but at least it will work... Haha stupid Intel!!!
If they thought of this (which is really easy to implement in a chip), then
they could have released software-patches for MMX, so that all software
could be released for MMX instead of using MMX-specific parts of code...
> >The R800 multiplication instructions can't be
> >remapped, because there are no 'compatible' ones in the Z180/Z380.
>
> If they cause a trap, we can make a workaround.
On the Z180 they do, on the Z380 there are other instructions there.
> >You should really read the Z380 specs... they're AWESOME!!!
>
> The Z380 specs I had read one or two years ago. Z180 I have never
> read. I know things I hear here and there.
It doesn't appear that you read the Z380 specs... Read them again please...
(thoroughly!).
> >Conclusion:
> >- Z380 is Z180 compatible
> >- Z180 barely has new opcodes, and only one or two of them are really
useful
> >- Some unsupported R800 instructions can be emulated through 'trapping'.
>
> Z180 is more "compatible" with R800 throught trapping. (-;
That is not an advantage.
The R800 instructions are hardly used, and it prevents the ability to
'upgrade'.
> >> On full potential, on complex 32 bit instructions (non-existent on
> >>Z180), Z380 may be faster (a lot faster) than Z180.
> >Z380 is already almost as fast as the Z180 at 18MHz (more than 10x
compared
> >to 12x).
>
> Well... use what you want. ACE002 will be, at first, in Z180. (-;
Certainly.
But the 'new MSX' should feature a Z380, because it's way superior.
>But mind you: there could also be two boards! One with Z180 (like ACE002),
>and one with Z380. Then the people have the choice, the ACE002 is faster,
>but will not run programs with 'enhanced' Z380 instructions (it is a fast
>current-generation board). The Z380-board is a bit slower, but can also run
>the new specialized programs (it is the a-bit-slower next-generation board)
(((-; I'm sure that for programs designes specially for Z380, Z380 will be
*very* faster than Z180. On Z380 you can do LOTS of thing only using
registers, which of course increase A LOT the speed the apps run. But we
are thinking on "legacy" applications... We want to support than in
the "fastest way". (-;
'The fastest way' doesn't matter that much. It's 10.5x compared to 12x.
And when using it to its full potential, according to Zilog:
Relative Performance Z80: 2.5, Z180: 11, Z380: 33
By the way, the Z180 still has got an adress range of 64kB. However, they do
some tricky stuff with some sort of mapping, which enables the user to use
1MB. But there are no new instructions to cope with the extended adress
range. And the Z180 has non 'extended' mode either, by the way. The 'legacy'
mode is the only mode, with a few added instructions.
> Anyone that wants to run video-intensive games. (-; Or play a EVA on a
MSX2)
> What you are saying is the same as "7Mhz is useless. I hope nobody uses
> it, because we have to change inside MSX... And who will do that...?"
7MHz is still compatible.
Anyways, I am already convinced of the use of ADVRAM so all is ok.
> >It would require two boards, and then there are as well the Z180 as the
> >Z380, while the Z380 could very well be stand-alone.
>
> So, there is no point on discussion. (-; The only work Padial has to do
> is: make it's board 100% compatible with MSX2+ or TR... because it's
> what Ademir is doing: a new fast MSX, 100% compatible with MSX2+
> (or TR). So, if both of them are 100% compatible with MSX2+ or TR
> (but faster!), the two boards will be compatible, but using different
> processors.
Yes!!!
> >> 32 bit cartridges slots...? For 4Gb access...?
> >Not all 4 GB are used ofcourse (it's only the upper limit).
>
> The gain using 32 bit slots are 32 bit memory access. (-;
For example. But the memory is put on the Z380 board so that will not be the
main use of 32-bits slots I think... I am rather thinking of the 4GB I/O
port range!!! And the 16-bit databus...
> >> >Ademir's ACE002 is a nice in-between form, but not a new standard. As
he
> >> >himself (through others) repeatedly said by the way.
> >> Create a new standard is something complicated.
> >Hmmm... what are we doing right now?
>
> Discussing a new machine (or two new machines). They'll hardly be
> accepted by all MSX users as new standards. Even if we agree,
> at this time I was told there is some people on Japan (ESE) working on
> a new computer also. I don't know if it's true, but if it is, the
> hardware they are developing will be compatible with ours?
> Will they accept the standard we had defined?
If it's already there, they must (otherwise they can't run new European
software anymore).
> Btw, if there is no div on Z180, it's a good add-on to Z380. Div is
> used sometimes and is slower to implement than mult.
I agree.
~Grauw
--
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
email me: [EMAIL PROTECTED] or ICQ: 10196372
visit my homepage at http://grauw.blehq.org/
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED]
and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in
the body (not the subject) of the message.
Problems? contact [EMAIL PROTECTED]
More information on MSX can be found in the following places:
The MSX faq: http://www.faq.msxnet.org/
The MSX newsgroup: comp.sys.msx
The MSX IRC channel: #MSX on Undernet
****
