On Thu, 20 Apr 2000 22:45:11 +0200, Laurens Holst wrote:
>Cool. I like this. Is eZ80 an option??? (Z180 compatibility, high speed,
>read my other -short- mail)...
Yes, it is when it is ready. For now, it's not. (-:
>Just don't do turboR-specific instructions like MULUB and MULUW!!!
>It will be very confusing when using the official Z180 docs...
If we have "modes of work", we can do R800 mode (R800 mapping), Z80 mode
(Z80 mapping) and Z180 normal mapping, p.e.
>But (as I read below), the IXh and IXl instructions are mapped
>differently...
>Hmmm... sucks. Well, those are used that often, it really should remap
>those.
>Are there other instructions at the Z80-locations of those??? If not, it is
>not such a big deal. If there are however, it not a really nice thing...
The solution proposed above solves this problem. We will be using modes
only for switching the how the opcodes are interpreted.
>That is a very good idea (otherwise a wait is issued every VDP I/O). It
>should not even be considered not to have a buffer!!!
>Even better would be to have a buffer > 1 byte...
On TR this is good so you can send a data to VDP and do something useful
while the VDP displays that data. But this would be only to legacy TR apps.
Remember that ACE002 would come with ADVRAM (which will be not so expensive)
and can be added to any MSX computer. ADVRAM will give us a lot of improvement
on video access, which will be never achieved by ports... not even using a
buffer. And, remember, if we add a big buffer on VDP, only new hardware
(ACE002 and/or Padial's Z380 board) will benefit from it... and will need
an entire new computer. ADVRAM will be an add-on available for everybody.
Of course it is not that kind of thing you do just placing a cartridge
into a slot - it requires some internal changes - but every MSX computer
will be able to run it... and will be a lot better than buffers on I/O.
BTW, as fast as the computer becomes, the faster ADVRAM will be. (-:
Z80 will "see" VRAM as another mapper. Everything you need to change VRAM
is switch a VRAM segment on page 2 of memory and a RAM segment on the page 1 of
memory and LDIR from page 1 to page 2... and voila, you wrote on VRAM.
And yes: this may work while the VDP is processing some command and even
you can write with Z80 on the same VRAM segment as VDP is writing. And
if this segment active on the main bus is the segment selected to be
at the screen on a given moment, you will see how fast Z80 writes on VRAM! (-:
This is perfect for tiled based games, even when using screen 10 or 12,
even without a GFX9k!
>> Yes!! This is the point! I think MegaSCSI (I'm not sure!) support
>> a HIGH speed bus. And also, we can use even 66Mhz SIMMs (the common
>> SIMMs) to the 33Mhz processor and it won't have to wait to disk/memory
>> access! This is why use a fast processor. And on this task, if MegaSCSI
>> supports 33Mhz bus, the data transfer will be faster using Z180 than
>> using Z380, because Z380 will work on a bus with 18Mhz (remember that
>> a bus overclock gives us a better performance than a processor overclock).
>I don't know. IDE works via memory-mapped I/O so that one is not really an
>issue.
Well, in this case we need to see what is faster: OUT using one processor
in a given speed or in another one. (-: Of course, OTIR and OTI should
give us different values, being used on different situations.
>> Read data from drive and transfer it to memory with disk and memory
>> access at 33Mhz will really speed up this task!
>I don't exactly understand it. I think the main output frequency should be
>3.57 MHz (for timing of the music etc., just like on turboR) (I hate the way
>my FM-PAC and SCC sound at 7MHz). And there should be another line with the
>processor freq. on it. And if something needs another freq, then they should
>use an own chrystal I think...
It's something like each hardware working on a different frequency... (geee!)
Well, it's not this, but is something like this. pe.: If you send data to
FM, the main processor will be forced to wait between the first and second
data. So, the music will ALWAYS play perfectly, even on 33Mhz. If you send
a data and another in sequence, the controler circuit will generate wait
states to the main processor, and your system will halt until the new
data can be sent to FM. But you can do your program send a data, calculate
the time needed between one and another out (given the main processor
working frequency) and do some usefull task before send a new data to FM.
On this way, you can do something like:
send data to FM
send data to MSX Audio
send data to MoonSound
send data to PSG
send data to SCC
(loop)
whithout loosing sync, because your main processor will be running at a high
speed comparable to the sound generators... your data will arrive the
sound processors almost at the same time, but when you talk to SCC to
play, FM had already got the data you put a little before, and when you
send a new data to FM, it will get it and will not make the main processor
wait. Of course, if FM is not ready, the main processor will be forced
to wait, but then the play limit will be the slowest sound generator
processor. This make possible to use *really* a lot of channels. BTW,
I think it will be even some time to draw something on the screen... (-:
>> This is a good question. Should we lets the programmer use the
>> non-Z80 and non-R800 opcodes (Z180 or Z380 specific?)
>I think you should.
>However the remapping is not nice.
>Maybe a workaround??? (when in 'enhanced' mode the real Z180 instruction map
>is used???)
I think the "operation modes" of instructions better than "operation modes"
of memory layout. The operation modes of instructions do not affect the
speed... and will assure a high compatibility, avoiding also using conflictants
opcodes (from R800 and Z180 at the same time).
>> I want the faster at all. Remember of the bus "boost" too... ((((-:
>> As I said before, on another mail, there is lots of things involved
>> when we are talking about different frequencies of processors... Not
>> only the internal processment.
>Of what I've heard about the eZ80, it's very cool.
ez80 is a possibility with a few changes on ACE002, since the board
with all peripherals runs in despite of the main processor frequency.
I don't know if this is the right way to call, but it'll act just like
a multi-frequency board. I think it's not right, but I do not know
how to explain in the right way. DalPoz, Ademir, someone can explain
it? (((-:
>I think it's important that my programs work for 'the mass'...
>And if I wouldn't... I could use the Z180 (eZ80?) enhanced instruction set,
>which is more limited than the Z380 set, but still nice...
I like to program using the fewer hardware as possible. (-:
>Switching to high adress-range would be (very!!!) nice.
Give us some troubles also. It would be needed to find a
good way to switch from one to another, remembering that Z380 has
not a switch back to legacy mode... the only way is a hard reset.
>Because IF one is programming Z180 specific, the extended adress range is
>very easy to use.
Z180 can address up to 1Mb linear ram. BTW, I think 1Mb linear ram,
for the proposed MSX hardware, will be enough... But I know someone
that was wrong about a certain 640kb limit, so it's better I shut my
mouth! ((((((((((((-:
But even the 1Mb will cause the same trouble as 4Gb. It's a difficult
point to solve in the hardware point of view. Something was proposed
some time ago was do the following: always run Z380 on 380 mode and
"protect" the lower 4Mb. This would be used in the "mapped" way, because
is where the legacy programs expect to find mapped ram. Above this
value, (from 4Mb to top), this can be addressed linerarly. This may
cause a lot of problems and may be incompatible anyway, but it's
a solution to be studied. But I don't really know if is possible.
But ACE002 will be limited to 64Kb. If, in the future, we decide
something about this, a new version may be made with this barrier
broken... Remember that once the new configuration doesn't hurt the
previous standard, we have nothing to care about... (-:
>I really think (although maybe a bit PC-like) there should be an
>'extended'-mode.
>Even if it were to satisfy people like Patriek... :)
(((-;
>But no really, it's useful. Then a Z180 / Z380 / eZ80-specific version of
>GEM could be made.
>Instead of only having benefit of the increased speed, it could also gain
>extra speed by using the specific instructions and extended adress range.
Well, this is a point. But it is possible to create a emulator for
64Kb of main ram. It's a little more complicated, because you'll
need to simulate the linear access if you are emulating systems with
RAM greater than 32K or something like this. But the work is almost
the same to emulate a mapped system on a linear address system... (-:
>> Good point. Z380/Z180 opcodes may be used just as if they were provided
>> by some kind of "Math CoProcessor".
>Just like on the PC, there are a lot of programs which have an option 'use
>MMX instructions'.
Z180 extensions would be like MMX...
Z380 extensions would be 3D Now! Extensions... ((((-:
Gee... I think this is more "PC like" than I would like... (-:
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
****
