Z80 big family

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

By Manuel

Ascended (15452)

Manuel's picture

04-02-2018, 16:53

From what I saw on the web, these would be candidates:
- Memotech MTX
- Tatung Einstein
- Sord M5

But... it depends... is it worth the effort? How much software and interest is there for these systems?
And is anyone interested to actually implement support for these systems in openMSX?

Emulation of these does not come for free, although the CPU (Z80), video chip (TMS99xx) and sound chip (SN DCSG) are already emulated. There's also different memory maps, I/O stuff (keyboard, controllers, cassette stuff), keyboard layouts and mapping, floppy drive interfaces and stuff like that. So, don't think too lightly of all of this.

By TomH

Champion (327)

TomH's picture

05-02-2018, 03:58

Not to mention different timings, due to different manipulations of WAIT and/or the clock. Speaking completely in the abstract, you can be pretty easily be cycle accurate for one machine while having no hope of emulating another accurately just because it uses the same processor.

I don't know what OpenMSX does or doesn't, but in other emulators that I've seen, they do things like weld a memory subsystem into the CPU core, and often make assumptions about the calculations that go into timing that don't carry across. E.g. on an MSX the length of any instruction is fixed and the length of a machine cycle is a function only of its type. On a ZX Spectrum it's a function of type, target address and relative timing with the video. On an Amstrad CPC it's just type and relative timing. On a Sam Coupe it's type, relative timing and video mode. On the ZX80 timing is natural but if you've built-in your memory subsystem then you're not going to be able to get accurate video. On a ZX81 that's still true and you now need properly to be considering WAIT versus NMI. The MSX doesn't even normally encounter an NMI.

Of course, I write this as the author of an emulator that successfully navigates those waters so I'm not arguing it's difficult to build for. It's just very hard to retrofit.

By gdx

Prophet (2775)

gdx's picture

05-02-2018, 08:52

Some computers with same CPU and same VDP as MSX :
Coleco Adam CBS, Casio PV-2000, Sega SC-3000, Sword M5, Tatung Einstein, ZX Spectrum (almost same VDP, only 8 colors and without sprites).

"manuel" wrote:

it depends... is it worth the effort? How much software and interest is there for these systems?
And is anyone interested to actually implement support for these systems in openMSX?

I would like OpenMSX to emulate Coleco Adam but if we had to choose, I prefer that OpenMSX emulates more MSX hardware (eg Franky, Megaflash SCC + SD and other interfaces, MMM, Playsoniq, etc).

Improving the debug mode and an UI that better fits the MSX and emulated hardware would be appreciable. (eg a slot number corresponding to real cartridge slot with the number displayed, options like switches, Digitization, Superimposition, Midi, etc)

A few functions can be improved. For example: memorization in database of last mapper type manually selected of corresponding ROM.

By TomH

Champion (327)

TomH's picture

05-02-2018, 15:17

The Spectrum's video is different from the MSX in a couple of important ways: scan lines are internally linear, and in the normal processor address space. That leads to a shared bus and contended timings: any machine cycle that attempts to access the same physical RAM chips as those containing the display (i.e. the lowest 16kb on a 48kb Spectrum) will have to wait for however long the ULA needs access. Ditto for accessing the ULA register — delays are applied if the ULA is busy.

Possibly of amusement for MSX owners, a recent trend in Spectrum homebrew has been to put the CPU into a busy loop for the visible area pelting the attribute memory with constant changes in order to get 8x1 attributes instead of 8x8. So, to get Screen 2. That's considered sufficiently much of a graphical upgrade to be worth spending some extreme percentage of the processing window on it.

(EDIT: also, the Spectrum has no inherent wait on M1. If your code is at or above 32768 and never touches the screen, it'll run faster than on an MSX. It's then also faster to access video memory, but you need to access it more often without hardware sprites, so...)

By maxis

Champion (512)

maxis's picture

05-02-2018, 16:31

@TomH, @gdx

Spectrum lower 16K shared RAM random access is lightning fast comparing to the VDP I/O. You can scroll the screen in pixel by pixel fashion at frame rate by CPU. Also there is no tiling concept (which is the advantage when the game is different from platformer) and the color attribute memory is lighter.
Actually by knowing the ULA timing precisely some ppl managed to synchronize the shared RAM access with the CPU instruction flow to max out the throughput (from what I remember the CPU wait varies from 0 to 2us approx).

I was always amazed how genius the Spectrum 48K architecture was (and very well balanced between the CPU performance and the gfx complexity). One shocking thing for example is using RESISTORS between the databuses between shared 16K RAM and 32K RAM to have a contention free operation! No bus buffers and complex state machines. Just 8 resistors. Genius.

By TomH

Champion (327)

TomH's picture

05-02-2018, 16:46

Honestly? I have a real physical copy of 'The ZX Spectrum ULA: How to design a microcomputer' sitting in my home, but am still such an analogue dunce that I couldn't adequately explain how the resistors effect a split bus.

What really impresses me about the design is the extent to which it is a leap over the ZX81, yet appeared only a year later and at the same price point. Those guys had an extraordinarily productive year!

By maxis

Champion (512)

maxis's picture

05-02-2018, 18:14

TomH wrote:

Honestly? I have a real physical copy of 'The ZX Spectrum ULA: How to design a microcomputer' sitting in my home,

how the resistors effect a split bus.

Seems to be a very nice book for reading. I wish I would have it 30 years ago...
Sorry for the off topic Wink

About resistors - it's ultra simple:
1. CPU sits on one databus where 32K RAM is also located.
2. Shared 16K RAM databus is connected via 8x 470 Ohm resistors to the CPU databus.
3. CPU can always "talk" to its 32K RAM or 16K ROM or vice versa regardless the situation and the state of the 16K shared RAM. If in this case the CPU data bus has a state '0' and 16K RAM shared state '1', there is no short circuit, since the current is limited via 470 Ohm resistor. This way the "isolation" is achieved because of magic 470 Ohm value is big enough not to cause bus contention.
4. Now when CPU wants to read/write the shared RAM, its cycle is synchronized to the shared bus. In this case 470 Ohm resistor is small enough to keep the correct timing (setup and hold) and to pass the signal ontime from one bus to another.

The above is magically simple and still stable enough for the mass production. Hence simply genius.

By Manuel

Ascended (15452)

Manuel's picture

05-02-2018, 22:23

gdx wrote:

I would like OpenMSX to emulate Coleco Adam but if we had to choose, I prefer that OpenMSX emulates more MSX hardware (eg Franky, Megaflash SCC + SD and other interfaces, MMM, Playsoniq, etc).

MegaFlashROM SCC+ SD is already emulated. MMM is now also emulated (not released yet, but you can try in a developer build). There are plans for Playsoniq and Franky.

Quote:

Improving the debug mode and an UI that better fits the MSX and emulated hardware would be appreciable. (eg a slot number corresponding to real cartridge slot with the number displayed, options like switches, Digitization, Superimposition, Midi, etc)

What would you like to be improved in the debugger? I heard lots of positive sounds about it last Saturday.

Where would you like to see the slot number? On a real MSX you also don't see the actual slot number, just 1 and 2 or A and B...
Digitization and superimposition would be nice indeed. Who wants to help?

MIDI is already fully emulated.

Quote:

A few functions can be improved. For example: memorization in database of last mapper type manually selected of corresponding ROM.

I think Catapult does remember that combination for you. Doesn't it?

By gdx

Prophet (2775)

gdx's picture

06-02-2018, 00:55

"maxis" wrote:

Spectrum lower 16K shared RAM random access is lightning fast comparing to the VDP I/O.

I do not think there's a need for a different VDP to share the VRAM but I am not an expert.
The VDP of the Spectrum is very similar to that of the MSX. Only a few characteristics differ.

"Manuel" wrote:

Where would you like to see the slot number? On a real MSX you also don't see the actual slot number, just 1 and 2 or A and B...

In general we know it on our real machine, it's written in the manual but with OpenMSX, many machines are emulated. We do not know them for all. Furthermore sereral MSX use a slot number other than 1 or 2, some have one slot, others three or four.

"Manuel" wrote:

I think Catapult does remember that combination for you. Doesn't it?

It is not available for Mac.

The debugger is a bit too complex and I will like more conditions to set breakpoints.

By mth

Champion (480)

mth's picture

06-02-2018, 00:24

As Manuel said, there is more work in emulating a system than just the individual chips. There are some assumptions in openMSX that have to be removed, for example for SC-3000 (work in progress) I had to change a lot of the keyboard code, which assumed for example that all modifier keys exist on the same keyboard row.

While the slot structure is not in our Z80 core itself, it is currently an integral part of the device interface. For systems without slots, we currently set up a fake slot selection that is fixed at runtime for the simple reason that no I/O address exists for changing the slot selection in machines like ColecoVision and SG-1000.

Also as TomH mentioned, some systems have delay cycles at certain moments and others do not. Also most systems contain some glue logic that needs to be implemented. So it is quite a bit of work to add a system, even when all its major chips are already emulated.

Another issue is that for a lot of systems, the documentation out there is not very detailed. Most of it is incomplete and some of it is even incorrect. So without access to the real hardware, we're just guessing how a system should be emulated. Actually, lack of hardware was a problem with emulating the Musical Memory Mapper as well, but at least that has pretty good documentation, although I still had to guess a few times. @gdx: If you're interested in reviewing or testing the MMM emulation, that would be very useful. I did test it with VGMPlay and with your ROM loading tools and those seem to work correctly.

So for adding systems, I think we shouldn't do it just to have more systems. The MESS project is already emulating systems with the goal of preservation, we don't have to duplicate that effort. If a system has close ties to MSX, like the SVI 318/328, ColecoVision or SG-1000, that can be a reason to add it. If a system has a scene that would benefit from openMSX features like the debugger or TAS support, that could be a reason to add it. But if there is no particular reason to add a system beyond it containing a Z80, I'd rather not include it.

I want to add support for Franky because Sander said that emulator support is important in attracting developers for MSX expansions. The SN76489 emulation was added to support Franky in the future. I will be looking at PlaySoniq, but since that contains a lot of complex hardware it's likely I'll only implement the Franky subset of it plus the configurable address decoding.

Regarding the debugger, I heard people say they like the functionality, but the UI can be improved. One of those people was Edwin himself Wink

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