What should the one chip MSX look like?

Page 3/12
1 | 2 | | 4 | 5 | 6 | 7 | 8

By Sander

Ambassador (1845)

Sander's picture

11-02-2003, 22:52

Get real

Yeah, realism is what's this topic all about. Hahaha.

By anonymous

incognito ergo sum (109)

anonymous's picture

11-02-2003, 23:19

>>Get real<<

Yeah, realism is what's this topic all about. Hahaha.

Why would you be sarcastic with all the recent happenings?
A "it might actually happen" attitude is currently more realistic than a "it's just a fantasy"!

By snout

Ascended (15187)

snout's picture

11-02-2003, 23:31

hmmm part of the reaction is of course a "It might actually happen, but I don't like what's happening" reaction. However, the argumentation why is not very well founded as of yet imho.

By Grauw

Ascended (8454)

Grauw's picture

13-02-2003, 00:56

But a chip that is an ARM + periphs that emulates the msx I would not call this a new MSX. Because in that case, We can wait 2-3 years that cell phones are enough powerfull to run fMSX, or just make a Pc run automatically on an msx emulator after boot and call this an msx...

Emulation is kind of a weird term. Think of this, all hardware can do stuff, but internally it's mostly some voltages running through connection lines, logical operations (built from transistors), and memory cells, which create the end result. If a piece of hardware can be given commands, it has to interpret the data (or a series of data) given on its 8 data lines into something it understands. It uses some kind of mapping to do that, #FF means this (RST #38), #FE means that, etc. Should you consider simply mapping those values to their appropriate meanings emulation? Yet this is what a (simple) processor-emulator does. Basic does by the way exactly the same, yet people call it 'interpreting' there. Maybe a nice sketch of this situation is the AMD Athlon 64-processor. A 64-bit processor, yet it supports, can understand 32-bit instructions and code. When and where do you draw the line? Anyways, I doubt this is the definition of emulation. So the 'mapping' process the ARM performs on the Z80 instructions before executing them in itself can't be considered emulation.

Or, what do you say, does emulation only exist in software, but not in hardware? I think that is kind of an odd difference, seeing that the software is executed by hardware. If a processor supports a multiplication instruction, would the multiplication on another processor which is constructed from a number of instructions be any different, basically? What happens inside the processor will in the end be the same. And especially when you start looking at programmable hardware the line gets very thin and you enter a grey area. What if you make part of the programmable hardware a 'translator', which reads out the Z80 code and passes ARM (or Thumb) equivalents to the ARM processor? The hardware is a program (it has always been, only now do you have a more direct control over it), so where is the difference? And, if I may bring up Basic again, you are saying that Basic is an emulator? And if that is so, then do you think emulation inherently bad? What if it is done on a precompiled basis instead of by interpreting?

If you say the difference lays in speed, that is definately no issue here since the ARM is fast enough to emulate the Z80 at full speed. Aside from that it's hard to really say how much this difference in speed is. I can very well imagine the Athlon 64 having to sacrifice some performance because of it's 32-bit code compatibility. Would a somewhat slower legacy emulation in favour of better performance perhaps not be a better decision? Anyways, speed is quite a relative term. In computer science classes, when doing efficiency calculations, we *never* look at the speed per iteration. To us, the fast multiplication by hardware and the more elementary software equivalent are the same. We look at the 'order' (n, nlogn, n^2, 2^n, etc.) of the program instead, because we know that computers will get faster and faster anyways. In any case, when you have to choose between an fully up-to-date ARM processor an an already quite old Z380, and you choose the Z380 just because you don't want the translation to happen on the software-layer, it's a pretty bad decision.

One could also describe emulation as a whole combination of software emulated chips, correctly timed and interfaced to eachother. If you use this definition of emulation, an ARM processor mimicking a Z80, and all other devices supported by the programmable hardware, should not be considered emulation. Or what about if you define emulation as one device only having one purpose, and not different purposes like processing, drawing and making sound in one, and having to interleave that. Even if you define it so, the abovementioned scenario would still not be considered emulation. And it's a weird definition anyways, since there are lots of hardware devices having several tasks at once. Take the MSX Engine for example, or the VDP with its VDP commands. And you bet the VDP is interleaving, how else can it speed up its commands when you disable the sprites.

Personally I don't draw such a strict line between hardware and software. In the end, good hardware is nothing without good software. Emulation on a hardware-level basically happens in almost every chip which is a little more advanced than a the most basic chips. Emulation in software doesn't nessecarily have to be a bad thing, it has a huge potential as a means to reduce the need for backwards compatibility, which can impose limits on new designs. Take the v9990 for example, making it v9958-compatible by hardware (hence either adding a translation layer or changing the whole structure of the it) might cost more than it gives. Ofcourse MSX-Association aims to let devices have standard hardware interfaces as much as possible, but you have to draw a line somewhere ^_^.

Hope to have cleared the 'the new MSX will be just like running an emulator on PC/pda/phone' issue from discussion for ever now. Well, at least you have heard my opinion on this ^_^. If case you missed it, here it is: it doesn't matter. In the end it's the 'MSX philosophy' as a whole that counts anyway. Who cares if I use this or that variant of assembly language to program for it, Z80 mnemonics don't make MSX 'better' than for instance ARM mnemonics. Who cares if the functions required for backwards-compatibility are emulated in hardware or software, as long as it works... It's other things that really matter. And yes, software is a big part of that aswell.

~Grauw

By anonymous

incognito ergo sum (109)

anonymous's picture

13-02-2003, 01:38

An even better example are the Transmeta Crusoe processors used in many low-power notebooks. They are VLIW (like Intel's Itanium) processors internally but they have a softwarelayer in embedded ROM/RAM that dynamically translates normal x86 code to their own VLIW instruction set.
This exact technique is used in advanced emulators (and even my own GEM ^_^), yet there is no way for a program to tell it's not running on a real x86 processor.
Even Intel and AMD processors internally translate the x86 opcodes to micro-instructions and internally have several times more registers than they appear to have.

Another thing in emulators that's often wrong in emulators is timing. But even this can be corrected in software (using floating point in the most extreme case)...

I really think legacy MSX compatibility is not an issue with a proper emulator and/or (partial) hardware assistance. The most important thing is that the MSX NT (^_^) carries over the MSX philosophy and makes a difference in the marketplace!

By Sander

Ambassador (1845)

Sander's picture

13-02-2003, 18:01

I was talking not about doubts about the revival, just that some people here dream to far away sometimes. Please understand that I admire most idea's posted here.

By snout

Ascended (15187)

snout's picture

14-02-2003, 01:12

How about a tablet-PC kind of design? (flipping the display over the keyboard when needed)

By Sander

Ambassador (1845)

Sander's picture

14-02-2003, 12:04

Ehrm, I don't think that will be the case. Try making a color tft device for lower than $100.

I think that if there will come such a device it probably will have a lot of connectivity, a nice Japanese case design, but probably no keyboard or any other fancy stuff.

If the device has indeed USB connectors, you will probably have to buy a USB keyboard yourself, so you decide how much you want to spend on that.

It will probably goes this way with most things you can beef up the device with.tin

So I think you will get a tiny, slick box. First version will be in black, with blue leds for power, hd activity etc.

A year from there, they will release the blue and the purper colored cases Wink

By sjoerd

Hero (593)

sjoerd's picture

14-02-2003, 12:23

I think it should be pink, just like my gameboy. With a very big msx-logo on it. And it should run for ages on just 2 batteries LOL! And without display, so everybody can choose the keyboard, display and whatever that they like most.

By snout

Ascended (15187)

snout's picture

14-02-2003, 19:33

Hmm Nishi wants a COMPLETE solution incl. display and keyboard to cost $100. SO uhm.. he must have some more tricks up his sleeve. I dig the black box, blue leds idea Wink

Page 3/12
1 | 2 | | 4 | 5 | 6 | 7 | 8