The OCM-PLD Pack v3.3 is out | MSX Resource Center

The One Chip MSX (OCM), first released in 2006, is a Programmable Logic Device (PLD) acting as a true MSX computer. The OCM-PLD pack is all the firmware and software you need to get it up and running. KdL has just released OCM-PLD version 3.3

Here's the change list:

v3.3 [2017.03.12] [KdL's Updates!]
- Updated documentation and DIP-SW User Manual in the [docs\] folder.
- Updated the [msxtools\] folder: use 'eset.com' to add more drive letters and 'ep.com' to mount the disk images.
- New Hex-files 304kB from OCM-SDBIOS Pack v1.9 with MSX3 Final Release and Zemmix Neo logos.
- New IPL-ROM Revision 1.05(K) that it loads fast a 304kB BIOS / 384kB SDBIOS.
- New SDHC support by yuukun-OKEI, thanks to MAX.
- New useful scripts for easy compilation and collection of firmwares.
- Added Brazilian keyboard layout by Fabio Belavenuto, Luis Luca and Emiliano Vaz Fraga.
- Fixed R#0 S5 timing of VDP TH9958 by yuukun: the intro of Dragon Quest 2 MSX2 is ok now, thanks to miyashu.
- Fixed RstEna signal with regression and other minor fixes (RC2_2014.11.20).
- Fixed MainRAM/MegaRAM clear function (RC1_2014.11.16).

Notes:
- The Nextor kernel will be natively supported by future releases.
- As regards the speed of cpu I inform you that 'custom 8.06 MHz' is the same 10.74 MHz of the original firmware.
All the 'custom speed' frequencies were acquired with a comparison benchmark through blueMSX and openMSX.
- The initial VDP-V9938 core is finally deprecated since the VDP-TH9958 has achieved the same stability.

Some known issues:
- VGMPLAY was fixed by Grauw for a inaccuracy of H-SYNC signal.
- The timings of VDP TH9958 are too fast: the intros of Fray and Space Manbow confirm the issue.
Hint! The most of Microcabin games can run better with the 'runit.com' tool.
- The 'Break' command of ESE-PS2 module do not work during the hard reset or if you unplug the keyboard at warm.
- Sometimes the SD-Card is not detected after a hard reset but you can re-insert it on the fly to solve.

Also EXTRA and SDBIOS packs are updated. The package OCM-PLD is for 1chipMSX and Zemmix Neo.

Follow KdL at Twitter , visit his web page or click the direct download link for OCM-PLD pack v3.3

Comments (39)

By mtn

Master (233)

13-03-2017, 10:55

Nice!! Big thanks to KDL and everyone involved.

Expert (122)

13-03-2017, 11:51

A really nice release.
After first tests, a few games run better
Thank you KdL !

By KdL

Paladin (948)

13-03-2017, 16:09

Thanks ro! Please also tag this post to Zemmix Neo.

PS. my nick KdL is with a lowcase 'd' eheh

By ro

Guardian (3892)

13-03-2017, 16:27

KdL wrote:

Thanks ro! Please also tag this post to Zemmix Neo.

yer welcome! But uhm, tagging wot?

KdL wrote:

PS. my nick KdL is with a lowcase 'd' eheh

Fixed, my bad

By KdL

Paladin (948)

13-03-2017, 17:06

The package OCM-PLD is for 1chipMSX and Zemmix Neo.

Topic: Challenges
Tags: OCM, Firmware, 1chipMSX, Zemmix Neo

Enlighted (5809)

13-03-2017, 18:39

Nice work KdL and contributors!

By KdL

Paladin (948)

13-03-2017, 20:04

Thanks Grauw! In June 2016 I sent you a email with a possible fix of H-SYNC for the VGMPLAY.

ELSIF(
   ((REG_R9_Y_DOTS = '0') AND (VDPR9PALMODE = '0') AND (PREDOTCOUNTER_YP_V = 236)) OR
   ((REG_R9_Y_DOTS = '1') AND (VDPR9PALMODE = '0') AND (PREDOTCOUNTER_YP_V = 246)) OR
   ((REG_R9_Y_DOTS = '0') AND (VDPR9PALMODE = '1') AND (PREDOTCOUNTER_YP_V = 260)) OR
   ((REG_R9_Y_DOTS = '1') AND (VDPR9PALMODE = '1') AND (PREDOTCOUNTER_YP_V = 270)) )THEN
PREWINDOW_Y_HS <= '0';

Do you have time to test this fix?
20170313_esemsx3_vgmplay_fix_v1_for_testing_purposes_only.7z

@ro: thanks for editing the tags!

By ro

Guardian (3892)

13-03-2017, 20:23

KdL wrote:

The package OCM-PLD is for 1chipMSX and Zemmix Neo.

Topic: Challenges
Tags: OCM, Firmware, 1chipMSX, Zemmix Neo

Check

Enlighted (5809)

13-03-2017, 22:05

KdL wrote:

Thanks Grauw! In June 2016 I sent you a email with a possible fix of H-SYNC for the VGMPLAY.

Do you have time to test this fix?
20170313_esemsx3_vgmplay_fix_v1_for_testing_purposes_only.7z

Ah KdL, sorry for forgetting about that! I’ve just tested it:

At 60 Hz, it plays at the correct tempo now. At 60 Hz VGMPlay generates interrupts on lines 0, 52, 104, 156 and 208. Screen 0 has 192 lines by default, so it does seem to generate interrupts in vblank now.

At 50 Hz, it still has problems, it’s playing too slow and the tempo is also very irregular. At 50 Hz VGMPlay generates interrupts on lines 0, 51, 102, 153, 204 and 255.

The irregular tempo at 50 Hz is new, suggesting that one out of six interrupts is sometimes-fired, sometimes-not. I’m guessing it has problems with the interrupt at line 255, perhaps it is either not always firing somehow, or maybe it is reset or the flag is masked when it reaches the next line so that it’s easy to miss? Just some guesses…

(Background info: VGMPlay’s OCM workaround option /o switches to 60 Hz and enables 212 lines mode in screen 0 temporarily, so that it can catch that interrupt on line 208.)

Supporter (5)

13-03-2017, 21:47

KdL, Thanks a lot for this release... Keep up with your great and precious work! BR,

By KdL

Paladin (948)

13-03-2017, 23:17

Grauw wrote:

KdL wrote:

Thanks Grauw! In June 2016 I sent you a email with a possible fix of H-SYNC for the VGMPLAY.

Do you have time to test this fix?
20170313_esemsx3_vgmplay_fix_v1_for_testing_purposes_only.7z

Ah KdL, sorry for forgetting about that! I’ve just tested it:

At 60 Hz, it plays at the correct tempo now. At 60 Hz VGMPlay generates interrupts on lines 0, 52, 104, 156 and 208. Screen 0 has 192 lines by default, so it does seem to generate interrupts in vblank now.

At 50 Hz, it still has problems, it’s playing too slow and the tempo is also very irregular. At 50 Hz VGMPlay generates interrupts on lines 0, 51, 102, 153, 204 and 255.

The irregular tempo at 50 Hz is new, suggesting that one out of six interrupts is sometimes-fired, sometimes-not. I’m guessing it has problems with the interrupt at line 255, perhaps it is either not always firing somehow, or maybe it is reset or the flag is masked when it reaches the next line so that it’s easy to miss? Just some guesses…

(Background info: VGMPlay’s OCM workaround option /o switches to 60 Hz and enables 212 lines mode in screen 0 temporarily, so that it can catch that interrupt on line 208.)

Ok. Are you sure on these limits?
60Hz 192lines => (PREDOTCOUNTER_YP_V = 236)
60Hz 212lines => (PREDOTCOUNTER_YP_V = 246)
50Hz 192lines => (PREDOTCOUNTER_YP_V = 260)
50Hz 212lines => (PREDOTCOUNTER_YP_V = 270)

Enlighted (5809)

14-03-2017, 01:21

Yes, looking at appendix 7-2 and 7-3 of the V9938 application manual, those seem correct, those are the number of lines between the first display line and the first top border line.

Anyway, I’m a dummy in VHDL, but maybe I found a few possible problem spots:

-- HSYNC INTERRUPT
HSYNCINT_N  <=  '1' WHEN( ( REG_R0_HSYNC_INT_EN = '0' ) OR ( ENAHSYNC = '0' ) )ELSE
                REQ_HSYNC_INT_N;

Why is that OR ( ENAHSYNC = '0' ) there? If I understand it correctly, when PREDOTCOUNTER_YP_V reaches the end value, ENAHSYNC will reset for a while (to sync with the VGA field?), and because of this /IRQ will go high too...? I think /IRQ should only reset when the status register is read, there should not be a “gap” in the IRQ signal.

IF( CLR_HSYNC_INT = '1' OR ( ( W_VSYNC_INTR_TIMING = '1' ) AND ( V_BLANKING_START = '1' ) ) )THEN
    -- H-BLANKING INTERRUPT CLEAR
    FF_HSYNC_INT_N <= '1';

If I read this correctly, this clears the h-blanking interrupt automatically when v-blanking starts. I don’t think that’s supposed to happen. This might also be the problem.

Note that in VGMPlay, when I set the interrupt to occur at line 255, at 50 Hz 192 lines it occurs on the 9th line of the top erase time of the next field, and at 50 Hz 212 lines it occurs on the 2nd line of the synchronise signal. And because the BIOS ISR also occurs, there can be some delay before I’m actually handling the interrupt, so it is important that it stays active until it’s cleared.

Side note: one other oddity of the V9938 I know about, is that the FH flag behaves differently depending on whether IE1 is set. When IE1 is not set, FH goes up at the start of the right border of IL and goes down at the start of the next left border. But this has nothing to do with VGMPlay’s issue, and it’s probably not so important to emulate, just fyi.

By KdL

Paladin (948)

14-03-2017, 12:45

ok... I write to you in pvt for the next test.

By KdL

Paladin (948)

14-03-2017, 20:16

Grauw wrote:

At 50 Hz, it still has problems, it’s playing too slow and the tempo is also very irregular. At 50 Hz VGMPlay generates interrupts on lines 0, 51, 102, 153, 204 and 255.

All turbo-cpu modes are ok at 50Hz with VGMPLAY. Only at 3.58MHz it plays irregularly.
I think it could be a slow response by the Altera Cyclone I.
A nice idea could be test this fix on a board with Altera Cyclone II.

Note: I could be enable a "special custom-speed 3.58 MHz" when the PAL-MODE is ON.

Enlighted (5809)

14-03-2017, 23:31

Mmhh, I suspect that in turbo mode the BIOS ISR just completes sooner, winning a race condition and letting the VGMPlay ISR intercept the interrupt in time before it’s lost… this would back up the ENAHSYNC or int clear scenario. Except I’ve tested those builds you sent me where you disabled those and they did not change the outcome .

I emailed you some test results. Tests on my turboR seem to confirm that line interrupts stay active until they’re handled (try VDP(20)=100:VDP(0)=VDP(0) OR 16: crashes). (Also that at 60 Hz line interrupts can only go up to line 234, interesting detail for us programmers.)

By spl

Paragon (1435)

15-03-2017, 11:31

Great news! Thanks very much, KdL! :-)

By KdL

Paladin (948)

15-03-2017, 12:01

Grauw wrote:

Mmhh, I suspect that in turbo mode the BIOS ISR just completes sooner, winning a race condition and letting the VGMPlay ISR intercept the interrupt in time before it’s lost… this would back up the ENAHSYNC or int clear scenario. Except I’ve tested those builds you sent me where you disabled those and they did not change the outcome .

I emailed you some test results. Tests on my turboR seem to confirm that line interrupts stay active until they’re handled (try VDP(20)=100:VDP(0)=VDP(0) OR 16: crashes). (Also that at 60 Hz line interrupts can only go up to line 234, interesting detail for us programmers.)

a new fix is ready and it seem to be ok now
pls check your inbox, I'll wait your reply

By KdL

Paladin (948)

16-03-2017, 20:56

OCM-PLD Pack v3.3.1 (2017.03.16) is out!

v3.3.1 [2017.03.16] [KdL's Updates!]

- Updated the scripts to compile and collect the firmwares.
- Fixed the issue of VGMPlay by improving the accuracy of H-SYNC signal, thanks to Grauw.

By spl

Paragon (1435)

17-03-2017, 09:34

KdL wrote:

OCM-PLD Pack v3.3.1 (2017.03.16) is out!

v3.3.1 [2017.03.16] [KdL's Updates!]

- Updated the scripts to compile and collect the firmwares.
- Fixed the issue of VGMPlay by improving the accuracy of H-SYNC signal, thanks to Grauw.

Thanks for your fast fixes :-)

Rookie (19)

18-03-2017, 12:48

mglOcm v1.834f [2017.03.03] - 1chipMsx Romfile Loader for KdL's 1chipMSX is out too!

[Download Link here]
https://drive.google.com/file/d/0B9ug5x4XhMb9bWJ1QkpLM084NDQ/view

By KdL

Paladin (948)

18-03-2017, 15:16

By KdL

Paladin (948)

18-03-2017, 15:19

toughkidCST wrote:

mglOcm v1.834f [2017.03.03] - 1chipMsx Romfile Loader for KdL's 1chipMSX is out too!

[Download Link here]
https://drive.google.com/file/d/0B9ug5x4XhMb9bWJ1QkpLM084NDQ/view

thanks a lot!! :)

Rookie (19)

18-03-2017, 15:23

I always appreciate your great works.
Thanks a lot~~~

By KdL

Paladin (948)

18-03-2017, 19:47

By KdL

Paladin (948)

22-03-2017, 02:24

OCM-PLD Pack v3.3.1 (2017.03.22) "REPACKED"
- Zemmix Neo "BR" variants were recompiled.
- Updated the 'history.txt' and 'mglOcm'.

Quote:

Yesterday Marcelo wrote in pvt of video glitches...

Sometimes random glitches on video or other strange issues could be caused by the optimizations.
This is a very old story with Quatus II because the LEs of 1chipMSX are used to the limits of Cyclone.
On my Zemmix Neo "Red Alluminium Limited Edition" the brazilian firmwares 2017.03.16 were okay.
But the same firmwares on Zemmix Neo "Brazilian Edition" is faulty results.

By KdL

Paladin (948)

23-03-2017, 04:21

OCM-PLD Pack v3.3.2 (2017.03.23) is out!

- Updated the [msxtools\] folder.
- Video luminance adjustments and other minor fixes.

Notes:
- Sometimes random glitches or other strange issues could be caused by the optimizations of Quartus II.
In these situations you can recompile the project with the 'iplrom.vhd.alternative' file.
- Some games go to black screen using 'ep.com'. I suggest to retry enabling two disk drives via 'eset.com'.

By KdL

Paladin (948)

23-03-2017, 13:40

Today, the brazilian user Marcelo have confirmed to me that the Zemmix Neo Bazilian is working with regular version 3.3.2 and not working with the alternative version. This test has confirmed that the issues are bypassed with a trick of the optimizations.

The 'iplrom.vhd' can be used to recompile the entire project by yourself in many variants. Just change the two bytes as shown below.

[ iplrom.vhd ]

-- the next two bytes are used to overcome any issues caused by the optimizations of Quartus II
X"84",X"21"

By KdL

Paladin (948)

23-03-2017, 21:58

By KdL

Paladin (948)

27-03-2017, 02:15

OCM-PLD Pack v3.3.2 (2017.03.27) "REPACKED"
Fully recompiled using var4128 for better compatibility. Luminance is ok now.
Sorry for any inconvenience caused. ^^'

By spl

Paragon (1435)

30-03-2017, 18:39

Thanks again for your work KdL!

Champion (303)

25-04-2017, 23:27

Hi KdL, I got it all working fine today on my Zemmix Neo Brazilian. Love it! Thanks for the great job.

I am curious about the notes: You state that the Nextor kernel will be supported by future releases. I assume that means it's not supported in this one? I saw on your twitter account some Nextor versions but that seams quite expirimental.

By KdL

Paladin (948)

28-04-2017, 00:03

-Neo- wrote:

Hi KdL, I got it all working fine today on my Zemmix Neo Brazilian. Love it! Thanks for the great job.

I am curious about the notes: You state that the Nextor kernel will be supported by future releases. I assume that means it's not supported in this one? I saw on your twitter account some Nextor versions but that seams quite expirimental.

Nextor will be supported from the next release.

Champion (303)

28-04-2017, 11:02

@KdL That's great! Looking forward to it. Thanks.

By KdL

Paladin (948)

07-06-2017, 23:52

OCM-PLD Pack v3.3.3 (2017.06.07) is out!

Minor fixes and improvements in this release.
Sorry, the Nextor support will be out from v3.4

Master (234)

08-06-2017, 06:18

I just saw the note about SDHC support. Does this mean that SDHC cards will now work?

By KdL

Paladin (948)

08-06-2017, 14:31

mfeingol wrote:

I just saw the note about SDHC support. Does this mean that SDHC cards will now work?

yes

Supporter (12)

08-06-2017, 15:11

Sweet

Paladin (756)

08-06-2017, 17:10

Hi KdL, this is also the version where the switched I/O has been fixed ? Can't find it in the above update description....

By KdL

Paladin (948)

08-06-2017, 18:32

yes it is...

v3.3.3 [2017.06.07] [KdL's Updates!]

- New Hex-files 304kB from OCM-SDBIOS Pack v1.9.2 with MSX3 Final Release and Zemmix Neo logos.
"UK layout with backslash" is the default profile from now.
- New 'pld_collector.cmd' script, a simple collector tool for testing more PLDs.

Directory of A:\PLD333

FLASH.BAT            70 
OCM2P-BR.PLD    524.288 
OCM2P-ES.PLD    524.288 
OCM2P-FR.PLD    524.288 
OCM2P-JP.PLD    524.288 
OCM2P-UK.PLD    524.288 
OCMX3-BR.PLD    524.288 
OCMX3-ES.PLD    524.288 
OCMX3-FR.PLD    524.288 
OCMX3-JP.PLD    524.288 
OCMX3-UK.PLD    524.288 
PLDFLASH.COM      2.304 
ZEMBR-BR.PLD    524.288 
ZEMBR-ES.PLD    524.288 
ZEMBR-FR.PLD    524.288 
ZEMBR-JP.PLD    524.288 
ZEMBR-UK.PLD    524.288 
ZEMKR-BR.PLD    524.288 
ZEMKR-ES.PLD    524.288 
ZEMKR-FR.PLD    524.288 
ZEMKR-JP.PLD    524.288 
ZEMKR-UK.PLD    524.288

- Fixed access to port $40 for external cartridges, thanks to WORP3.
- Enabled "Balanced" and "Extra Effort" synthesis settings to improve compatibility, thanks to Fabio Belavenuto.

Notes:
- The Nextor kernel will be natively supported by future releases.
- Sometimes random glitches or other strange issues could be caused by the optimizations of Quartus II.
In these situations it is suggested to recompile the project by replacing 'iplrom.vhd' with the alternative
'iplrom.vhd.var8421' or by replacing 'emsx_top.qsf' with the alternive 'emsx_top.qsf.area'.
- Some games go to black screen using 'ep.com'. I suggest to enable two disk drives via 'eset.com' and retry.

Some known issues:
- The timings of VDP TH9958 are too fast: the intros of Fray and Space Manbow confirm the issue.
Hint! The most of Microcabin games can run better with the 'runit.com' tool.
- The 'Break' command of ESE-PS2 module do not work during the hard reset or if you unplug the keyboard at warm.
- Sometimes the SD-Card is not detected after a hard reset but you can re-insert it on the fly to solve.