Amstrad CPC emulator for MSX2

Страница 1/2
| 2

By QBee Sam

Master (207)

Аватар пользователя QBee Sam

17-02-2019, 00:25

I've been trying to get run without success for some time, someone was able to make it work in real machine?.
The Spectrum emulator works, losing frames, but works, I think is really an amazing job, and I want to see running on my MSX Turbo R, slower as hell I suppose, but gorgeous anyway IMHO.

Link to the amazing blog of Juan Hernandez, ROMU6 author:
http://romu6.blogspot.com/2018/12/emu6cpc-emulador-de-amstra...

Some videos he posted in his youtube channel:
https://www.youtube.com/watch?v=DVBNQgsm6VI&t=111s
https://www.youtube.com/watch?v=Kciiic2ZL6s
https://www.youtube.com/watch?v=11Ts-lotbRU&t=24s

Для того, чтобы оставить комментарий, необходимо регистрация или !login

By mohai

Paladin (841)

Аватар пользователя mohai

17-02-2019, 13:53

Very interesting. Nice work.
Congratulations and thanks to the authors.
The usual problem is the botleneck with the VDP.
Maybe a special version for V9990 could speed up things.
There are a couple of problems when emulating a CPC: Z80 is clocked at 4 Mhz, but, due to video RAM access, performance is downgraded to 3.3 Mhz (more or less).
The other problem is that there is a 640x200 video mode. I wonder how they solved this?

By PingPong

Prophet (3459)

Аватар пользователя PingPong

17-02-2019, 14:23

Obviously the bottleneck IS THE VDP.
as usual. No one is thinking about converting 16kb if CPC vram on the Fly taking into consideration the differences in non linear screen memory layout and the vdp that is linear all running at decent framerate.
You could also have a v9990 but until you are not able to unload cpu from this task you have not real benefit. and the v9990 cannot help in this situation in an effective way. You still have to push 16kb of data (and on some v9990 modes even more) each frame always through a out on one 8 bit port

By PingPong

Prophet (3459)

Аватар пользователя PingPong

17-02-2019, 14:31

The situation is worse than on speccy because this only have 7kb of vram and a more similar vram layout. but none thinks aboit this. They start the song "how slow is the vdp access it s the root cause of all evil things"
None is considering that the z80 at 3mhz can hardly keep up with the msx 2 vdp even in active area and that a memory store operation plus a increment of a register takes appproximately the same time than a outi

By PingPong

Prophet (3459)

Аватар пользователя PingPong

17-02-2019, 15:07

http://www.cpcmania.com/Docs/Programming/Painting_pixels_int...
Just for fun.
Maybe the only way to do this at a reasobable speed is a precomputed lookup table. But it is expensive
And if one choose this approach parakdoxally maybe that the vdp port style is faster than a straight ram to ram convertion
You setup a high speed cpu ti vram transfer with a bounding rect that is the cpc screen size then out without doing others calcylations to the vdp by only mapping a cpc byte into 1/2 vdp bytes

By TomH

Champion (327)

Аватар пользователя TomH

17-02-2019, 19:16

The problem with trying to use a lookup table would be that the CPC doesn't have a fixed mapping from memory to display. It has a 6845 CRTC, into which one dictates the number of cycles per line, how many of those contain pixels and where the sync should go, plus how many pixel lines makes a complete row, and then how many rows total make an entire frame plus the number of those that have pixels, and where the sync is. It was designed for character-style text displays, though the CPC rearranges its addressing lines to give linear addressing within a pixel line up to a certain limit.

BASIC then might only offer 160, 320 or 640x200, but games and applications use a much wider set of possibilities. So even without considering those that dynamically reprogram the thing for split screens or smooth scrolling*, such an emulator wouldn't support a decent quantity of software.

* including at least some software that changes the length of hsync to get sub-byte scrolling; the Amstrad monitors, and as it turns out most TVs, will move the moment at which they perceive horizontal sync to the middle of the pulse. So a pattern of 3us pulses results in hsync 0.5us before a pattern of 4us pulses, even when the corresponding pulses from each set start at the same time.

By PingPong

Prophet (3459)

Аватар пользователя PingPong

17-02-2019, 21:06

The lookup table i mean is only to convert a byte read into a specific mode to a byet to be written in a msx2 vdp mode
Meaning cpc byte value =156 -> vdp byte value 102 for example not for address calculation.
Only to avoid bit test and set or reset operations.

By TomH

Champion (327)

Аватар пользователя TomH

20-02-2019, 21:52

Ah, yes, I was being dense. Also, I think you're possibly right about the separation of the VDP being helpful here — you get that extra self-incrementing 16-bit pointer register more cheaply than you probably would if trying to do conversions directly in software, given the register juggling you're otherwise in for.

By mohai

Paladin (841)

Аватар пользователя mohai

24-02-2019, 23:27

@PingPong:
You are right. CPC screen layout is a real mess.
Maybe this layout suits better the video hardware, but complicates the software side.
As I use to say, starting from the source code would be the best way to emulate/convert CPC applications.

By Grauw

Ascended (8507)

Аватар пользователя Grauw

08-08-2019, 22:44

How did I completely miss this news? Despite being slow, amazing that it works in the first place!

Super cool project.

By QBee Sam

Master (207)

Аватар пользователя QBee Sam

09-08-2019, 08:50

Well, I'm not sure it really works in real hardware, I could never make it work on my GT Crying

Страница 1/2
| 2