emulator ID I/O port

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

By Tanni

Hero (556)

Tanni's picture

04-06-2009, 17:50

And I do agree with manuel on this...you should not write software which can not be used on the REAL thing!

Sounds a bit like a commandment, isn't it?

If we DO go down this road then pretty soon the hardware will become a bit "dissapointing" to use because you cannot for example create the same stunning effects on it as you can on the emulator(+)

You also use a PC besides your MSX, yes? Did the MSX become a bit ''disappointing'' to use because you cannot create the same stunning effects on it as you can on the PC?

Communicating with your software using special *emulator tricks* during development to speed up development YES ...

During development, I use higher emulation speed (263%), of course, but also for running the software. It would be very annoying to manually switch back to 100% every time I press the compile- or run-key! So even in your sense it would be good to have software-to-emulator-communication to switch back to the real speed if -- for development reasons -- the speed was set higher or lower. So, the software would check if it is emulated and if the speed was changed. If so, it would store the actual speed setting, set the emulation speed to 100% and run. Before terminating, it would reset the actual speed for e.g. faster compiling.

... but releasing finalized software which can only run on a particular emulator? Not such a great idea...
We all still wanna keep the MSX alive !! dont we ?!Smile

If you releasing finalized software for MSX2 using MSX2 features, it wouldn't run on every MSX right? So, what's the difference? That's why certain ID-bytes in the ROM are for. What's the differenct between checking ID-bytes in the ROM (e.g. 50 or 60 Hz version, nationality, MSX version, presence of certain drivers) and checking presence and version of an emulator or asking it about certain features?

From the point of view of an application, the emulator is just another device. The MSX system was designed to be the most flexible and expandable homecomputer system ... so why should it be against the ''flavour'' of MSX to expand it by emulator-based features?

I think that's a very great idea, especially if we all still wanna keep the MSX alive.

All the existing hardware will get defective one day, so from that day on, you only rely on emulation. It is very unlikely that there will be reproduced MSX hardware which is EXACTLY the same as it was in the 80th and 90th. The only thing we can expect is that there will be some FPGA-based new MSX-hardware some day, but which will most likely also differ in some minor details. With emulation-based new features, we can e.g. investigate how to integrate new technology into MSX to find out about the bounds of expanding the system.

Does everyone know how this topic is treated by other retrocomputing communities?

By Tanni

Hero (556)

Tanni's picture

04-06-2009, 18:23

3: This could be useful, but I'm not sure a single emulator detection / control port would be the best way to do it.

We should reserve 8 or 16 ports for emulator access.

In any case I think it is a bad idea to query emulator name and version, because in the future new emulators might appear and existing emulators will get more features and it would be a shame if already released MSX programs could not take advantage of that.

So any kind of probing for emulator extras would have to be feature based: instead of asking "what emulator are you?" the program would ask "what features do you have?". Also, this would not be limited to emulators: new hardware could respond to the same queries.

The software could ask for the emulator's name and version just to display it on the screen. Ok, a little pointless, because the user should know the emulator used. But it would look nice and somewhat ''proper''.

It would ask ''Do you have the required feature?''

If your software requires a certain feature, it would be sufficient to test if it is run on a certain version of a certain emulator. See the LaTeX mechanism for version checking.

However, one super-device might not be the best implementation of this, because it breaks modularity. Instead, virtual hardware could use separate port numbers / slots. That way, it can be implemented in real hardware more easily. And in the case of openMSX, it fits nicely into the existing extensions mechanism.

We can do an approach with function numbers and parameter passing modalities.

By Tanni

Hero (556)

Tanni's picture

04-06-2009, 18:35

Another problem that could arise is that the feature might be specified in a bad way if the specification is driven only by a single new software title. The feature might be too specific for that particular software, while a slightly different specification might be useful for a lot more software. The feature might be specified in a way that is very hard to implement, while a slightly different specification might allow the same effects and be easy to implement.

Of course, things should not get implemented in the quick and dirty way without consulting the community and the developers.

@hap
That is a decent design for a super-device, but you haven't convinced me yet that a super-device would be preferable over extending existing devices and adding new devices with one purpose each.

Basically, what I'm trying to say is that I would prefer to design new features as if they are a new generation of MSX hardware, even if they were never actually implemented in hardware. With FPGA, it might even be feasible to implement them in hardware at some point, either as part of an integrated ESE-style system or as a cartridge containing an FPGA chip.

I agree with that. But to my mind, there may be features which can be seen as new devices, and some don't.

Increasing emulation speed could be implemented in an FPGA as switching clock speed.

By Manuel

Ascended (18066)

Manuel's picture

04-06-2009, 23:02

For something like increasing emulation speed, it would be much easier to use an existing useless Z80 instruction or something similar as a trigger for the emulator. (E.g. the ld b,b or something similar.) The software itself will then automatically run on the real hardware as well. You really don't want to support version X of emulator Y and later find out that emulator Y doesn't even exist anymore and your MSX program won't run properly on any real machine or emulator at all anymore.
At least MSX and MSX2 are quite well established standards and you get what you expect. That's the difference, IMHO.

By flyguille

Prophet (3028)

flyguille's picture

05-06-2009, 06:46

For something like increasing emulation speed, it would be much easier to use an existing useless Z80 instruction or something similar as a trigger for the emulator. (E.g. the ld b,b or something similar.) The software itself will then automatically run on the real hardware as well. You really don't want to support version X of emulator Y and later find out that emulator Y doesn't even exist anymore and your MSX program won't run properly on any real machine or emulator at all anymore.
At least MSX and MSX2 are quite well established standards and you get what you expect. That's the difference, IMHO.

why not an unused opcode?, because ld b,b can be use just for wasting time like NOP.

By Manuel

Ascended (18066)

Manuel's picture

05-06-2009, 16:10

Well, something like that, whatever Smile You know what I mean. (Actually, this is just mth's idea: adding opcodes or registers to existing chips...)

By Tanni

Hero (556)

Tanni's picture

05-06-2009, 16:44

why not an unused opcode?, because ld b,b can be use just for wasting time like NOP.

Because there may be versions of the Z80 in the future which use them.

By Tanni

Hero (556)

Tanni's picture

05-06-2009, 17:54

For something like increasing emulation speed, it would be much easier to use an existing useless Z80 instruction or something similar as a trigger for the emulator. (E.g. the ld b,b or something similar.) The software itself will then automatically run on the real hardware as well.

Increasing the emulation speed is only one exemple. Of course, it could be done in various ways. As flyguille pointed out, using the ld b,b or similar methode also can have undesirable side effects. Using still unused opcodes can conflict with (alas very unlikely) future development of new hardware. You would spend one of the limited unused opcodes for something which is better done another way.

Suppose you have a program which is able to change its emulated speed by communicating with the emulator via a dedicated port. What would happen if it would do so on the real MSX hardware? As the port is not connected to anything, it will happen nothing! The programm will just continue running on its normal speed.

If a program requires emulated devices not present on the real thing, it will detect that it is not emulated and terminate with an errormessage. And because these emulated devices aren't present on the real thing, the programm would be useless there anyways. So you'll get an advantage which were not present on the real hardware. There's no conflict I can think of!

You really don't want to support version X of emulator Y and later find out that emulator Y doesn't even exist anymore and your MSX program won't run properly on any real machine or emulator at all anymore.
At least MSX and MSX2 are quite well established standards and you get what you expect. That's the difference, IMHO.

As all of the emulator developing groups can work together in implementing an MSX-wide standard for emulator-based virtual device access, features present in every emulator can be accessed in the same way in every emulator. We are a community, aren't we? For features specific to a certain emulator, you need to identify the emulator by software. If that specific emulator or version of a specific emulator isn't present, you need to download it. Or get it form a friend. Getting an MSX emulator, even outdated, will be much easier and cheeper than getting the real thing in working conditions. The problem is much the same as if you would access a specific real device not connected to the system by software. You also could argue that blueMSX and openMSX are well established standards at least. I really don't understand your concerns.

Why do you need every software to run on the real thing?

All the MSX computers I own aren't in fully working conditions any more. My disk drive doesn't work anymore. It's very hard -- almost impossible -- to get a working one nowadays. Basix failed to bring the OCM to europe. Today, we are not in the 80th anymore, alas, so you need not protect your source code as a holy secret, so changing it for real device access instead of emulator access would be possible, if that device will ever be available. But if you want to write new software for MSX which needs to access up to day's technology (USB etc.), why sticking to the limitations of the technology form about 20 years ago? To provide access to up to date technology brings MSX up to date, at least virtually.

By ARTRAG

Enlighted (6515)

ARTRAG's picture

05-06-2009, 18:25

IMHO one thing is to develop tools on emulators that help the development for real HW, another thing is to develop fake devices/HW supported only by emulators for actual programs or games.

Emulators interpret the machine code instruction by instruction. If you remove the fact that they behave like real HW, what about developing PC games on a generic interpreted language, say in Blitz Basic ?
Blitz runs on PC machines, resembles a lot the MS-basic, it is easy to program and can do lots of things on the right HW...
It the same thing: an interpret that runs your code and that does not correspond to real machine, but is by far more powerful than what you can get with your proposal.

You proposed to move from emulation to a generic development environment resembling msx...
It is a drastic change in the general philosophy of the thing.
Anyway, not to me to decide... if emulator guys follow you...

Simply it is not my cup of tea, I'm still quarreling with Vejo if we should develop for msx1 or msx2 in msxdev09
Wink

[edit]
nice retrocompetition here
http://www.blitzbasic.com/

By Tanni

Hero (556)

Tanni's picture

05-06-2009, 19:00

I wouldn't consider the access of USB or the host's filesystem via the emulator as fake device or fake HW support (as I interpret your slash correctly). If you accept emulator tools for developement, it's just a small step further to use also other virtual devices. So why not? You need to define an interface anyways. And if the emulator offers the possibility to disable that features, there should be no problems.

Emulators interpret the machine code instruction by instruction.

Even processors interpret the machine code instruction by instruction!

It the same thing: an interpret that runs your code and that does not correspond to real machine, but is by far more powerful than what you can get with your proposal.

It's not a question of being powerful.

You proposed to move from emulation to a generic development environment resembling msx...

Did I?

It is a drastic change in the general philosophy of the thing.

I consider it just a small step! But, what did Armstrong say on the moon?

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