New MSX Core In The Works

[NinjaWarrior]

I checked the colors with a real MSX 1 (SVI-728) and Molekula MSX core seems very accurate on my setup using The Maze of Galious cartridge. The gradient is not present on real MSX, purple is very accurate, so the differences pointed out seems like an emulator artifact to me. I took some photos only realizing that phone camera changed colors and they were inaccurate, so it is just my perception. I tested also F1-Spirit and some other games, and colors seems right to me using an SVI-728. Please note that other MSX 1 models may show different video outputs.

[pgimeno]

Even within the same model you can get different colours due to tolerance of components.

[NinjaWarrior]

Even within the same model you can get different colours due to tolerance of components.

Totally true, and most MSX 1 computers are now almost 40 years old, so we can expect some variations in colors or signal output quality. Overall, I think the MSX 1 palette is fairly accurate and we talked about it in a Retrocrypta Twitch live (in which @molekula fixed "on air" the core with our suggestions regarding color palette btw).

[wark91]

I checked the colors with a real MSX 1 (SVI-728) and Molekula MSX core seems very accurate on my setup using The Maze of Galious cartridge. The gradient is not present on real MSX, purple is very accurate, so the differences pointed out seems like an emulator artifact to me. I took some photos only realizing that phone camera changed colors and they were inaccurate, so it is just my perception. I tested also F1-Spirit and some other games, and colors seems right to me using an SVI-728. Please note that other MSX 1 models may show different video outputs.

Thank you for your response !
It is great !

[aloyisus]

@molekula this is awesome, thanks so much. It's great to be able to load my .CAS files from the OSD now, and everything I've tried so far loads fine.

The only problem I'm having is that the cursor keys aren't working in any of the games I've tried. They work fine in the OSD, and interestingly they work in MSX BASIC, only not in the games themselves. I've tried a couple of different keyboards, but no joy so far...

Anyhow keep up the great work with this core!

[molekula]

@vampier

I would say that PSG sounds almost spot on now. SCC sounds good for a 1st implementation but it seems that waveforms and channels are getting mixed up or something (hard to explain)

If you want to have good test scenarios to see how accurate the core is please run Utopia demo by Dvik and JoyRex or Waves by the same people. The sound playback works great that probably means the PSG and z80 implementation are great already.

Unfortunately, my musical hearing doesn't allow me to tell the difference. But I tried

For future requests if you can implement a 2nd cartridge slot to implement cartridge mixing (used a lot of Konami games)
If you are thinking about implementing cheats let me know I have a massive library that I can extract (I made most of the trainers that can be found in openMSX and blueMSX)

Maybe later. But I don't want to make any promises.

I hope once you feel like the MSX1 core is done you'll continue on an MSX2 core (hey I can dream right? )

That is unlikely to happen. I have no relationship with MSX2.


@pgimeno

- The per-frame cycle count is 71136 instead of the expected 71364 in most PAL machines. That corresponds to 312x228 (lines x cycles per line) instead of the 313x228 it should be. Hopefully this will be an easy fix.

- Polling the VDP status register with interrupts disabled is always guaranteed to return the interrupt status bit set, once per frame; however, in real hardware, there's a small window of 1 to 2 cycles in which if you poll the status register, you miss the bit for the whole frame. For details see the explanation of values A and B in https://codeberg.org/pgimeno/vdptest/sr ... ESULTS.txt and the results for a TMS9129NL (tested on a Philips VG-8020/40).

I looked at VDP interupt. The number of cycles can probably be adjusted relatively well. Looks like there's a missing one line in the VDP implementation.
As for the timing of interrupts in relation to the status bit, the situation is more complicated. This would have to be implemented extra.


@aloyisus

The only problem I'm having is that the cursor keys aren't working in any of the games I've tried. They work fine in the OSD, and interestingly they work in MSX BASIC, only not in the games themselves. I've tried a couple of different keyboards, but no joy so far...

Does the problem persist in the latest version ? Do you have a specific game where the problem occurs ?

[aloyisus]

@molekula

Does the problem persist in the latest version ? Do you have a specific game where the problem occurs ?

This specific issue was fixed a couple of releases back, thanks so much. I've raised another joystick issue on github today, but most of the .CAS games I've tried seem to be running pretty well now, with the exception of some very minor graphical issues.

[pgimeno]

- The per-frame cycle count is 71136 instead of the expected 71364 in most PAL machines. That corresponds to 312x228 (lines x cycles per line) instead of the 313x228 it should be. Hopefully this will be an easy fix.

- Polling the VDP status register with interrupts disabled is always guaranteed to return the interrupt status bit set, once per frame; however, in real hardware, there's a small window of 1 to 2 cycles in which if you poll the status register, you miss the bit for the whole frame. For details see the explanation of values A and B in https://codeberg.org/pgimeno/vdptest/sr ... ESULTS.txt and the results for a TMS9129NL (tested on a Philips VG-8020/40).

I looked at VDP interupt. The number of cycles can probably be adjusted relatively well. Looks like there's a missing one line in the VDP implementation.
As for the timing of interrupts in relation to the status bit, the situation is more complicated. This would have to be implemented extra.

The first issue is quite important, as many programs (demos, most notably) depend on the exact cycle count between interrupts, and it's off by a lot. As for the second issue, don't sweat it, I don't think there's any emulator capable of getting it right, and it's only necessary for the case of developing on MiSTer and then porting the program to a real machine. That's a pretty niche case, so it's OK to leave it as is.

[circletheory]

I've read that some models of MSX support MIDI out -- and there's various videos of MSX Vampire Killer playing a MIDI soundtrack during game play. Will this MSX core support MIDI out to the MT32-pi?

[pgimeno]

I don't know if there are MSX1 games that support MIDI, but there's going to be very few of them if any. Also there are at least three standards, see https://www.msx.org/forum/msx-talk/gene ... ent-328780

I don't think it's worth adding support.

[DucaSP]

I've read that some models of MSX support MIDI out -- and there's various videos of MSX Vampire Killer playing a MIDI soundtrack during game play. Will this MSX core support MIDI out to the MT32-pi?

I believe what you saw was WORP3 MIDPAC v2 ( https://www.worp3.com/MainPage.php ), an interface that "grabs" the I/O calls to PSG and FM chips and translate thoses into midi instruments and send then over the MIDPAC interface to an external MIDI device like Sound Canvas, so it doesn't require games to support MIDI and has a few profiles/configurations on its own... That is a proprietary implementation that would be difficult to implement from the scratch as it is not open source/open hardware as far as I know.

For regular MIDI interface, MISTER MSX core is based on KdL OCM and it has MIDI over joystick port, so it is just a matter of finding a way to export that to an output pin on MiSTER that can connect to a MIDI device, but then, I think it works only with software that supports MSX TURBO-R Midi Interface, and probably is not what you are looking for.

[pgimeno]

For the record, this thread is about molekula's unofficial MSX1 core, and not about the official OCM-based MSX core.

Still, glad to hear that OCM supports Turbo-R MIDI; maybe it's worth posting a feature request issue on GitHub about adding MT32-pi support to the core.

[fierman]

This core allowed me to load in my msx tapes. I am very impressed with the work done so far. Thanks!

[Moondandy]

Been having a go of this core this evening and it's working really well, being able to load the roms from the OSD is great, good effort! Is there much left to do before this can be released officially?

[pgimeno]

- The per-frame cycle count is 71136 instead of the expected 71364 in most PAL machines. That corresponds to 312x228 (lines x cycles per line) instead of the 313x228 it should be. Hopefully this will be an easy fix.

I looked at VDP interupt. The number of cycles can probably be adjusted relatively well. Looks like there's a missing one line in the VDP implementation.

I think the fix is this one:

Code: Select all

diff -ru a/vdp18_pack-p.vhd b/vdp18_pack-p.vhd
--- a/vdp18_pack-p.vhd	2022-10-22 23:47:04.000000000 +0200
+++ b/vdp18_pack-p.vhd	2022-11-01 15:23:13.303453960 +0100
@@ -26,10 +26,10 @@
   -- Constants for first and last vertical line of NTSC and PAL mode.
   --
   constant hv_first_line_ntsc_c : hv_t := to_signed(-40, hv_t'length);
-  constant hv_last_line_ntsc_c  : hv_t := to_signed(221, hv_t'length);
+  constant hv_last_line_ntsc_c  : hv_t := to_signed(222, hv_t'length);
   --
   constant hv_first_line_pal_c  : hv_t := to_signed(-65, hv_t'length);
-  constant hv_last_line_pal_c   : hv_t := to_signed(247, hv_t'length);
+  constant hv_last_line_pal_c   : hv_t := to_signed(248, hv_t'length);
   --
   -----------------------------------------------------------------------------
 

(Please get that fix in before any official release)

[Moondandy]

Would the BIOS need to be stripped out and loaded separately or is there no copyright issue on this one?

[molekula]

Work continues and new fixes and features have been added to the core.

- FDD support
- SYS updates
- Unloading ROM cartridge
- Change video mode PAL/NTSC
- Fixed PSG sound
- Fixed border problem on CRT
- Fixed joystick in some games

[vanfanel]

@molekula

Today's release makes it an awesome and mature MSX1 core already: the PSG sound fixes, the FDD support and the NTSC/PAL switch make it an incredible machine implementation.

As others have said, I can't wait to see this on the main MiSTer repository: this is way more compatible than the old "official" MSX1/2/2+ core which is far less accurate.

This is the MSX1 core we deserve!

[EeDee]

Thank you @molekula, Your Core is very welcome.
An accurate Core with lots of features is so nice for users and fans of old hardware to experience and also interesting for those who would like to see how the old hardware performed. You've given us addons as well

[Chilli_Vibes]

Awesome core, loads every rom file I have thrown at it.
For CAS files, do we need to close the "" ?
For example,
cload"-"

Or can we get away with
cload"-

I know some are bload, or even run. I just can't find the " symbol, I have tried every key combo I can think of, so for now I am doing the CTRL+F2 to load cas files.

[pgimeno]

I know some are bload, or even run. I just can't find the " symbol, I have tried every key combo I can think of, so for now I am doing the CTRL+F2 to load cas files.

Two keys to the right of L, there's the apostrophe '; to get the double quote you need to press LEFT shift and apostrophe.

Don't ask me why it works with left shift only.

[molekula]

Don't ask me why it works with left shift only.

Correction in the next version.

[breiztiger]

hi
thanks for your work !!!
how can i get this demo working ?
https://www.pouet.net/prod.php?which=91909

[pgimeno]

Correction in the next version.

Thanks! Any chance we can get this patch in too?

Code: Select all

diff --git a/vdp18_pack-p.vhd b/vdp18_pack-p.vhd
--- a/vdp18_pack-p.vhd	2022-10-22 23:47:04.000000000 +0200
+++ b/vdp18_pack-p.vhd	2022-11-01 15:23:13.303453960 +0100
@@ -26,10 +26,10 @@
   -- Constants for first and last vertical line of NTSC and PAL mode.
   --
   constant hv_first_line_ntsc_c : hv_t := to_signed(-40, hv_t'length);
-  constant hv_last_line_ntsc_c  : hv_t := to_signed(221, hv_t'length);
+  constant hv_last_line_ntsc_c  : hv_t := to_signed(222, hv_t'length);
   --
   constant hv_first_line_pal_c  : hv_t := to_signed(-65, hv_t'length);
-  constant hv_last_line_pal_c   : hv_t := to_signed(247, hv_t'length);
+  constant hv_last_line_pal_c   : hv_t := to_signed(248, hv_t'length);
   --
   -----------------------------------------------------------------------------
 

I don't know if it will interfere with other options, like V-Integer scaling; I haven't tried the patch myself. But here's a test program that you can use to check the number of Cycles/frame: https://notabug.org/attachments/0702c8d ... fbea3e5a1d

The correct count for PAL is 71364 and for NTSC it's 59736. That's (248-(-65))*228 and (222-(-40))*228 respectively, so I believe that 247 and 221 are incorrect and 248 and 222 are correct.

[wark91]

Correction in the next version.

Thanks! Any chance we can get this patch in too?

Code: Select all

diff --git a/vdp18_pack-p.vhd b/vdp18_pack-p.vhd
--- a/vdp18_pack-p.vhd	2022-10-22 23:47:04.000000000 +0200
+++ b/vdp18_pack-p.vhd	2022-11-01 15:23:13.303453960 +0100
@@ -26,10 +26,10 @@
   -- Constants for first and last vertical line of NTSC and PAL mode.
   --
   constant hv_first_line_ntsc_c : hv_t := to_signed(-40, hv_t'length);
-  constant hv_last_line_ntsc_c  : hv_t := to_signed(221, hv_t'length);
+  constant hv_last_line_ntsc_c  : hv_t := to_signed(222, hv_t'length);
   --
   constant hv_first_line_pal_c  : hv_t := to_signed(-65, hv_t'length);
-  constant hv_last_line_pal_c   : hv_t := to_signed(247, hv_t'length);
+  constant hv_last_line_pal_c   : hv_t := to_signed(248, hv_t'length);
   --
   -----------------------------------------------------------------------------
 

I don't know if it will interfere with other options, like V-Integer scaling; I haven't tried the patch myself. But here's a test program that you can use to check the number of Cycles/frame: https://notabug.org/attachments/0702c8d ... fbea3e5a1d

The correct count for PAL is 71364 and for NTSC it's 59736. That's (248-(-65))*228 and (222-(-40))*228 respectively, so I believe that 247 and 221 are incorrect and 248 and 222 are correct.

You could open an issue on github page to follow your request.
https://github.com/tdlabac/MSX1_MiSTer/issues

[pgimeno]

You could open an issue on github page to follow your request.
https://github.com/tdlabac/MSX1_MiSTer/issues

Unfortunately no, I can't. I've left GitHub.

[molekula]

Would the BIOS need to be stripped out and loaded separately or is there no copyright issue on this one?

I don't know what the BIOS rights are. Before the official release, I would replace the BIOS with C-BIOS, where there is no rights problem.

[molekula]

Correction in the next version.

Thanks! Any chance we can get this patch in too?

Code: Select all

diff --git a/vdp18_pack-p.vhd b/vdp18_pack-p.vhd
--- a/vdp18_pack-p.vhd	2022-10-22 23:47:04.000000000 +0200
+++ b/vdp18_pack-p.vhd	2022-11-01 15:23:13.303453960 +0100
@@ -26,10 +26,10 @@
   -- Constants for first and last vertical line of NTSC and PAL mode.
   --
   constant hv_first_line_ntsc_c : hv_t := to_signed(-40, hv_t'length);
-  constant hv_last_line_ntsc_c  : hv_t := to_signed(221, hv_t'length);
+  constant hv_last_line_ntsc_c  : hv_t := to_signed(222, hv_t'length);
   --
   constant hv_first_line_pal_c  : hv_t := to_signed(-65, hv_t'length);
-  constant hv_last_line_pal_c   : hv_t := to_signed(247, hv_t'length);
+  constant hv_last_line_pal_c   : hv_t := to_signed(248, hv_t'length);
   --
   -----------------------------------------------------------------------------
 

I don't know if it will interfere with other options, like V-Integer scaling; I haven't tried the patch myself. But here's a test program that you can use to check the number of Cycles/frame: https://notabug.org/attachments/0702c8d ... fbea3e5a1d

The correct count for PAL is 71364 and for NTSC it's 59736. That's (248-(-65))*228 and (222-(-40))*228 respectively, so I believe that 247 and 221 are incorrect and 248 and 222 are correct.

You could open an issue on github page to follow your request.
https://github.com/tdlabac/MSX1_MiSTer/issues

I've edited it in the next release.

[molekula]

Today I posted another version.
- SCC sound fix
- adjustment of the number of VDP lines
- support for two cartridges
- BIOS upload support
- firmware/Hangul ROM support

[suww37]

Today I posted another version.
- SCC sound fix
- adjustment of the number of VDP lines
- support for two cartridges
- BIOS upload support
- firmware/Hangul ROM support

Thank you very much, the bios loading feature is very good. Do you happen to have a plan to develop the MSX2 core? I'm very much looking forward to MSX2 or TurboR.