> >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. (-:
k.
> >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.
Nice.
I trust the R800 mode will automatically be enabled when the BIOS-routines
to change to R800 mode. And that those routines will be enhanced to go to
Z180 enhanced mode (hence not making new routines).
> 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.
But first, ADVRAM is again something else which has to be added, and second,
it is only useful for moving large blocks, like when loading from disk
(directly into VRAM). It's nice, but when loading the speed doesn't really
matter. In all other cases, using the VDP is much better, since it can
execute commands independantly from the processor, which can do other stuff.
And third, VDP commands can have various dimensions. To do that using direct
VRAM access is difficult and requires complex routines. I doubt it will be
alot faster. And don't forget, it requires processor power, while the
VDP-commands don't.
> 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.
No. It will only decrease the waiting of the processor. Which is fine,
because the processor is faster anyways. And as long as an (on a Z80) 7
T-states-long wait is added between two VDP OUT's just to make things
compatible with the older MSX computers... (the same goes for the turboR).
It has nothing to do with an entirely new computer at all.
A 15-byte buffer for example would be nice (just enough for a VDP-command to
fit in).
It will not give any problems when reading the status right after the copy,
because the I/O handler will (ofcourse) first process the rest of the buffer
(which is FIFO). Right?
Although I doubt if it is useful to make a speedup for VDP-commands (which
depend on the speed of the VDP)... Okay, bad example...
> 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. (-:
But ADVRAM is quite useless!!! I hardly use (in)direct VRAM access!!!
And if I do, I will use the usual way to do it, because otherwise it will be
incompatible with alot of MSX computers...
I think it sounds nice but it's not a good idea.
> 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.
You can as well with the usual VRAM access.
> This is perfect for tiled based games, even when using screen 10 or 12,
> even without a GFX9k!
Sorry but I can't see why it would. It requires complex routines which will
highly likely be slower than the VDP itself.
>> 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!)
[...]
> 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
[...]
> I think it will be even some time to draw something on the screen... (-:
I still don't see the problem with that, about different frequencies. Or
isn't this a hardware thing you are talking about???
> 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).
True. However, it would be a shame not to use the Z180 enhanced-mode. I
think what you stated in the beginning of the message was very nice.
Although it will indeed be confusing if you want to use optional Z180
enhanced mode instructions (when available) inbetween R800 code.
I think you should only add MULUW and MULUB remapping if it is really easy
to do and doesn't result in concessions. Those instructions are really
hardly used by anything. The IXh and IXl-alike instructions however are
really used alot.
> >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 I get the point.
> >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. (-:
You can always add optional enhanced mode usage, just like the optional MMX
support in a lot of PC software, or like the Nemesis 3's v9938 usage (if
available).
That's a nice use of the enhanced mode.
> >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.
Z180 can switch back, right?
Z380 can be worked around (see other msg).
And if the PC or the SP is set at an adress too high to fit in the 64k
boundary when switching back, well, then it's badly programmed and the
programmer should know that. So then just reset the computer.
> >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! ((((((((((((-:
My current memory mapper is 2MB, so it would still need memory mapping.
> 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.
Mwa... I think in Legacy mode you should have the 64kB range, and in
Enhanced mode there should be an adress range of 1MB.
> 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... (-:
It doesn't have to be 64kB... Why not extend it right away??? (ofcourse only
in enhanced mode, not in legacy mode). It will require some extra
memorymapping logic, but I think that will be all...
Anyway, this 'future version'... could ACE002 be adapted to it or would I
then have to buy an entire new board??? I don't have that much money
y'know... I hope this entire 'enhanced' mode will be there in ACE002.
Btw, I think ACE002 should be named MSX 3. I mean, why not? Then it's easier
to indicate the requirements... Like "MSX2 128kB DD drive required, MSX3
w/HD preferred"...
Or MSX 2.7, if you wish... (nahhh...)
> >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... (-:
True, and it wouldn't be hard either because that's also the way GEM works
now, but the higher adress range would still be great.
> Gee... I think this is more "PC like" than I would like... (-:
If you want to see it that way...
But no, not really. Remember how long Intel got stuck on such an old
instruction set???
The Intel MMX-thing is more like ZiLOG than ZiLOG is like Intel MMX.
~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
****
