Implementing cartridges with emulated hardware?

Por asiga

Rookie (21)

imagem de asiga

31-03-2014, 22:16

I don't know the technical details of how it's actually done, but it's clear that a cartridge can replace the internal VDP by another graphics chip (the VDP9990 was marketed that way), and can add more hardware resources to the MSX, like sound chips, video digitizers, and perhaps more stuff, I don't know.

I just had the idea that OpenMSX could have an API so that you could design a cartridge that has such external chips, and you could provide a "cartridge file" with all the necessary code for emulating such hardware.

Would it be hard to provide such API for cartridges with external hardware? Or maybe that's already done and I didn't know?

Entrar ou registrar-se para comentar

Por Manuel

Ascended (18785)

imagem de Manuel

01-04-2014, 10:37

I'm not sure what exactly the requirements of the API should be. What kind of things would you expect to be doing with it?

Por asiga

Rookie (21)

imagem de asiga

01-04-2014, 12:22

I was thinking in graphics and video only, but then realized that there're audio hardware cartridges as well.

What I was thinking for graphics is an API that allowed to redirect the I/O of some ports (so that you could switch the internal VDP off), and get access to the emulator framebuffer (I suppose it's a 24bit FB). For running the cartridge emulation code, I was thinking in a callback function (provided by the "cartridge file") being called by the emulator. Such function should perform all its tasks as fast as possible and return control to OpenMSX (so that the cartridge emulator doesn't hurt OpenMSX performance). This callback would need access to reading and writing I/O ports, and also would need a way for knowing how much time was spent since last call (so that it could time it's work accordingly, in order to properly emulate blitter commands and such with correct timing).

Well, that was what I was thinking about, but are just quick ideas

Por Manuel

Ascended (18785)

imagem de Manuel

01-04-2014, 12:46

It's actually not too hard to add a new device to openMSX.... just look in the code how things are done. It's not an API, but you only need to implement some interfaces (like MSXDevice).

So, just adding your 'extension' in the normal source code, is that an option?

Por asiga

Rookie (21)

imagem de asiga

01-04-2014, 13:00

Yes, it's a solution. The only problem might be that if I do some experiment which can be cool and/or useful, maybe it doesn't qualify as a device worthy of being distributed with the default source tarball. The possibility of doing that as "cartridge files" would open the possibility of distributing your own "hardware mods" without interfering with the OpenMSX source. But, yes, your suggestion would work for trying stuff.

Por Grauw

Ascended (10581)

imagem de Grauw

01-04-2014, 13:04

I would say first make the extension that you have in mind, and once you have something bring it up with the openMSX guys to discuss whether this can be distributed as part of openMSX (probably only if there is a real hardware counterpart) or should be externalised through an API. This way, you will also have better insight in what level of control such an API needs to give you exactly.