On Sat, 22 Apr 2000 21:57:34 +0200, Laurens Holst wrote:
>> Z180 has new instructions.
>Only very few, which are not that useful.
Well... they are more usefull than those new on Z380... (-;
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). 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
1 time : 32 bit opcodes for the additional registers.
---------------------------------------------------------
3 times: 3 x the same functions in different implementations
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!)
>> 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.
>The undocumented ones (ld ixh,a etc.) are not. But those will be remapped.
Right.
>At least, that is afaik. In both cases.
>So let's check it out on the ZiLOG site...
((-;
>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. (-;
>Ah... I quote directly from the Z380 manual (copy/paste): "The Z380 CPU, an
>enhanced version of the Z80 CPU, retains the Z80 CPU instruction set to
>maintain complete binary-code compatiblity with present Z80 and Z180 codes."
>That matter is solved.
Very good!
>The Z180 has the following new opcodes over the Z80:
>IN0 r,(n) --- 16-bit I/O instr.
>MLT ss --- 8-bits multiplication (ss=DE=D*E). Not compatible with turboR.
(...)
>'SLL' instruction (on the R800 it is the same, afaik).
>TSTIO n --- Test I/O port (C) with n, or something like that (C/ and n).
>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... (((-;
>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.
>I see nothing about IXh and IXl but they'll probably be there, undocumented,
>just like on the Z80. However, according to Patriek they are on a different
>location, and that explains the nessacary remapping. 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. (-;
>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).
>IN F,(C) is not available in either of the processors.
Read port on Flag register?
>The Z180 as well as the Z380 can 'trap' undefined opcodes...
Yep! (-;
>This could be very useful.
Yes... this is VERY usefull if you want to emulate Z380 opcodes on
Z180, via software. per example! (-;
>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.
> However,
>when installing some kind of TSR you can 'trap' those instructions and
>emulate them (I don't think this should be 'hardwired', that is implemented
>by hardware, but rather as a small COM-file to be loaded from Dos, or as a
>patch. In consideration with future expansions).
Yes, I like more on this way.
> The opcode of IN F,(C) is
>not used in either of them processors. That instruction can be 'emulated' on
>both. The MULUW and MULUB opcodes ARE used on the Z380, but not on the Z180,
>so those can also be trapped on the Z180.
What IN F,(C) is supposed for?
>However, I don't think a lot of programs use them. Illusion City, for
>example, is turboR only. However, the only R800-'specific' instructions used
>are limited to the instructions using IXh, IXl, IYh and IYl. Which will also
>work on a Z80. And on the Z180. And on the Z380.
(-;
>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.
>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. (-;
>> 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. (-;
>Taking the new instruction set in account I would prefer to have a Z380
>board.
Good for you.
>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". (-;
>> ADVRAM will be integrated on the board. It's a new feature that everyone
>> that uses ACE002 will have.
>Well, it can't hurt to have it there.
>But I hope nobody will use it, because it will cause incompatibility for
>MSX2 users. And yes, I know it can also be built-in MSX2 computers. But who
>will do that...
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...?"
>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.
>> 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. (-;
>> >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?
>According to Patriek there are only very few extra instructions... Some
>multiplication and dividing (when do you use them? never). The Z380 has
>instructions like exchange every register (not only DE and HL), multiple
>register sets, 32-bit relative calls (very useful for relocatable stuff),
>etcetera etcetera etcetera.
Yes, like I said, it has more instructions regarding to the registers
and 32 bit things (that are not present on Z180 and there is no reason
to put them there... why will someone put a instruction on a processor
to exchange data between register that are "non-existent" on that processor?)
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.
>> Who said you it's not bakcward compatible? It is... it just doesn't add
>> speed to legacy apps. But legacy apps may work with new apps, that uses
>> ADVRAM.
>I mean, will apps using ADVRAM work on MSX2 computers (unmodified)??? I
>think not.
The app may have to "graphical" routines... at least to show how big
are the benefits from ADVRAM... (((((-;
[ADVRAM]
>I am indeed not enthousiastic about it.
When you see it working, you'll see. Oh, better... when you see how slow
VDP is (working on a faster computer, we always discover this), you'll
se that work with Z180 or Z380 and have to OUT to the VDP is a very
slow process.
>> No, you run it at the full speed, but turn on several Waits.
>Ah... clever indeed...
>So that's the way to let older programs still run at it...
Yep. (-;
Abra�OS/2, Daniel Caetano ([EMAIL PROTECTED])
...!m.tag
OS/2 Sites: http://www.quasarbbs.com/daniel/
http://www.geocities.com/SiliconValley/8752/os2hp/os2index.html
MSX Sites: http://www.fudeba.cjb.net/
Drawings: http://www.djgallery.tsx.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
****
