On Mon, 24 Apr 2000 11:11:46 +0200, Laurens Holst wrote:
>Most of the instructions you are talking about remained the same as they
>used to be. They are only extended in another operation mode. There are very
>few new specific instructions to cope with the extended address range.
>Most new functions are 16-bit extensions (16-bit add). Those could also have
>been added to the Z180. Not only DIV, but also RLCW HL - ANDW HL,BC - NEGW
>HL - SUB SP,nn and things like PUSH nn - EX BC,DE etcetera.
>So you are still quite wrong here, although I now understand what you mean.
I do not think they are "so" important, since they never were missed by
me... (-; This type of thing will take away the "register selection" task... (-;
>> These I really need to read.
>It's really nothing much new from the Z80. Once you know the Z80, and you
>know which instructions have been added and you know about internal I/O and
>traps, you've pretty much covered it all...
This is very good, because I talked with Ademir and ACE002 will REALLY be
a MSX2+ Ultra Fast... Maybe a MSX TR ultra fast. With some hardware
add-ons that may be placed everywhere. 100% compatible with previous
MSX2+ computers. No new "commands".
BTW, he talked me about some hardware changes on Z180 I already know,
but I was not aware that he was using. A new feature that he will probably
add (and this will be not compatible with computers that doesn't use Z180)
will be the HighSpeed Serial Ports, that are ready inside the computer.
The speed goes up to 2Mbit/s. I think it's pretty nice... to plug on a PC and
share hardware. (-;
>Hmmm... If that's true the it's pretty darn stupid of them. I think it just
>hangs, but doesn't trap. Otherwise, I really believe they would have
>implemented it...
OS/2 reports a trap and in several situations you may stay working as
nothing has happened. Windows do implement this. (Linux also).
OS/2 does. But of course, OS/2 closes the app that caused a Trap...
when it's possible. Not all traps on x86 are regarding to non-existent
ops. Windows ans Linux implement "divide by zero" exception - which on
x86 are treated like a trap. Memory parity errors are also presented
as traps. Of course a memory parity error is not a recoverable trap,
p.e.
>EduCAR is not MSX.
No. But it's based on the same idea... but without all the MSX limitants. (-;
BTW, LPE Z380 "Enhanced Mode" is not MSX also. (-; Or better, it's so MSX
as EduCar.
>And as I stated above, most new instructions could also have been added to
>the Z180... They have nothing to do with the extended address range etc.
Yes, you are right. Some. But they are absolutely NOT 200% more than
Z80 instruction set!
>> That's point of view. (-;
>I am trying to say that although it might execute some turboR programs
>correctly where the Z380 doesn't, that's an advantage. But it must at all
>cost be prevented that those instructions are also being used in newer
>software.
Well... I don't know, because maybe we will have a new MSX, that may
be produced, that supports those instructions. (-; A new FAST MSX2+
(or a new FAST MSX TR!) ((((-;
>> I don't know how this comparison was made.
>Me neither, but it includes the benefit from the extended instruction set.
>I guess they made several small programs, all optimized for their
>appropriate processor, and then measured the results.
If it was, it was not a fair comparison. Look at the restrictions Ricardo has
made to compare ADVRAM with the standard VDP operations. If he do a program without
those restrictions, ADVRAM will look a lot faster, which will be not reality
in the "normal operation". It compares the overal performance, but not the
performance with the same code at the same clockspeed (which would give us
the real boost from changing from one to another processor).
A note: you may notice that code optimized for Z380 (even using only
Z80 code) will be slower on a Z80 than the same code optimized for
Z80. If they have done this, of course Z380 will show a biiiiiiiiiiig
performance compared to Z80 and Z180... (-;
And, of course, for Z380 only programs, this comparison *is* valid.
But it's not Ademir's target.
>I agree. Only through software perhaps...
>And ofcourse the BIOS should be compatible.
Yes. (-;
>> >If it's already there, they must (otherwise they can't run new European
>> >software anymore).
>> I think they're not "that worried" about this. (-;
>Wouldn't they??? I doubt it...
I don't. For years they'd done their own software. And it's good software.
They doesn't like english. Their culture is different. I'm not saying it's
worst or better. I'm just saying it's different. And the same goes for
us, here, in Brazil.
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
****
