Dottori-Kun core

[ccovell]

Hi, and thanks JimmyStones and Furrtek for bringing the Dottori-Kun core to MiSTer.

Can I make some requests / bug reports?

I run my MiSTer in 15khz RGB, and the core doesn't make my CRT display happy: it shuts off / degausses itself! Is there any way to lock the core to 60Hz or change the sync pulses to something more standard? (I hear the VSync pulse shuts off the Hsync pulse in the real hardware during VBlank, which is nonstandard/bad.)

Also, when I run MiSTer in 31Khz VGA, the core's resolution seems halved, with missing odd pixels and blocky graphics. A screenshot confirms it: The screen is 224 pixels wide (why not 256?) but the active graphics are only 128 pixels in the middle of this area.

Dottori_Mister_Err.png (371 Bytes) Viewed 5671 times

[jimmystones]

Hi, and thanks JimmyStones and Furrtek for bringing the Dottori-Kun core to MiSTer.

Can I make some requests / bug reports?

I run my MiSTer in 15khz RGB, and the core doesn't make my CRT display happy: it shuts off / degausses itself! Is there any way to lock the core to 60Hz or change the sync pulses to something more standard? (I hear the VSync pulse shuts off the Hsync pulse in the real hardware during VBlank, which is nonstandard/bad.)

Also, when I run MiSTer in 31Khz VGA, the core's resolution seems halved, with missing odd pixels and blocky graphics. A screenshot confirms it: The screen is 224 pixels wide (why not 256?) but the active graphics are only 128 pixels in the middle of this area.

Dottori_Mister_Err.png

Hi! Thanks for the info that allowed it to be possible

It seems to run quite happily on my CRT, but it also is happy with cores that others have mentioned having issues with so I guess mine is just more easy going! I'll look into the issues.. I did just notice on reviewing the code that I'm not actually supressing the RGB output during the blanks, so will add that in for starters to see if that helps.

I had to make some guesses with the VGA output for MiSTer, as there were no hblanks/vblanks signals that I could see in the schematic. So I just played with them until it looked about right - the whole h sync cycle is only 256 in total, so I used a 32 cycle blank - hence the 224 pixel width output, and the aspect looked ok to me with that.

Will ping you when I have a new build to try

[jimmystones]

Ping! If you run an update you should get a new version with the scandoubler should be fixed at least. I improved the blanking, but if it doesn't fix your 15Khz issue let me know and I'll look into the sync business.

[ccovell]

Thanks for the update! My setup still doesn't like the 15Khz mode, but that's understandable. Nicole Express did a write-up here about why Dottori-Kun doesn't capture/display well: https://nicole.express/2021/a-lot-of-ef ... -dots.html
Other systems (GB/Lynx...) that have odd refresh rates have modes in their cores that lock them into 15Khz/60Hz, so I was hoping the Dottori core could be nudged that way too.

Anyway, the VGA 31Khz mode looks much nicer! All the pixels are accounted for. Unfortunately, a 128-pixel-wide image is being scaled into 224 pixels, so they are being unevenly stretched. Is there a way to make them integer scale perfectly into a 256 or 512-wide buffer? Or at least 448 pixels across?

Lastly, I have a few of my own test ROMs for the Dottori-Kun hardware. Is there a way to ask MiSTer to ignore MD5 hashes and checksums so I can load my own ROMs?

Thanks!

[jimmystones]

Looking back at the code I ended up not using the composite sync (the MiSTer arcade video module just takes the individual h/v sync signals) so I guess it must just be the slightly out of range frequencies.

I'll have to look through some of the other cores that do it, as I'm still an FPGA noob and my simplistic view tells me I'd have to either change the video clock speed (not ideal) or add more vertical lines (would need to make the counter width bigger and add more logic) to bring it down to 60Hz, but there may be some other way people are using.

Integer scale wise I'm not sure I quite understand! Might need some pictures to help my brain follow what the problem is

If you copy one of the existing MRAs and change it to point at a new ROM you can just put "none" in for the MRA and CRC values and MiSTer should just ignore them and load whatever you provide.

[ccovell]

Yes, I checked with an oscilloscope, and the 15Khz signal in the Dottori core correctly XORs the HSync and VSync signals, unlike the real Dottor-Kun hardware. So at least the MiSTer core is more friendly to TVs/monitors. I guess either the HSync timing is 0.729% too slow, or VSync is 1.71% too fast..... I'm no expert so it's hard to say why it's so hard to sync to.

EDIT: More checking with the scope showed that in 15Khz, the Dottori-Kun core held VSync low for about 8 scanlines, when 3 seems to be normal for other cores & systems. Perhaps that could be the culprit?

At any rate, it seems the video circuitry and CPU core are not synchronized exactly like the real hardware. I had made some timing tests that synchronize colour changes to the raster beam, both to make per-scanline colour changes, and to change the colour about 4 times in a single scanline. These changes should be mostly vertical, or at least match the pictures taken off a CRT that you can see below. Since they're slanted, that means either the CPU or the video circuitry are running at slightly incorrect speeds. (Or some other problem...)

NODATE-screen_0006.png (4.04 KiB) Viewed 5335 times

NODATE-screen_0007.png (5.17 KiB) Viewed 5335 times

[jimmystones]

Ooh, can you send me those test ROMs please? I can run those in the simulation and see if I can work out the issue.. (I had wondered how you generated that test image)

[ccovell]

Okay, some test ROMs are in a single ZIP. I made them 5 years ago now, so I forget exactly what they do, but using the controller L/R (maybe U/D too) you can adjust the number of NOPs for the raster bars, and scanline position for the colour-changing effect ROMs.

[jimmystones]

Any idea what would make it say RAM BAD? That seems like a poor start

I'm a bit confused what the problem might be so far because Dottori-Man Jr. looks fine (the colour scrolling on the title page and the CRT test page) and I presumed that would use the same technique and therefore have the same issue!

[ccovell]

Well, here's the title screen with all graphics filled in. The raster bars are supposed to change offscreen, in a vertical column, but here they are going diagonally down and to the right (with a line added for help). This shows that the CPU is running too slowly compared to the video timing. Perhaps that's some inaccuracy in the Z80 core?

NODATE-screen_0008.png (4.28 KiB) Viewed 5189 times

Anyway, about that weird VSync issue... I'm afraid I know very little about FPGA programming, but I was looking at the schematic, and if, right before the VSync gets combined with HSync, if you ANDed the VSync pulse with the "4Mhz clock/2048" line, that would make the VSync pulse only 4 scanlines long, more in spec. There could be further logic that can be added to get VSync down to 3 scanlines, which looks to be considered "normal"

[dshadoff]

Well, here's the title screen with all graphics filled in. The raster bars are supposed to change offscreen, in a vertical column, but here they are going diagonally down and to the right (with a line added for help). This shows that the CPU is running too slowly compared to the video timing. Perhaps that's some inaccuracy in the Z80 core?

That diagonal seems too consistent to be a Z80 inaccuracy; perhaps each horizontal line is one dot too brief (or hsync period ?). Or clocks have a slightly wrong ratio... but I’m assuming it’s driven by a single clock with a low integer divider, so I’m thinking horiz. pixels.

[jimmystones]

Well, here's the title screen with all graphics filled in. The raster bars are supposed to change offscreen, in a vertical column, but here they are going diagonally down and to the right (with a line added for help). This shows that the CPU is running too slowly compared to the video timing. Perhaps that's some inaccuracy in the Z80 core?


NODATE-screen_0008.png


Anyway, about that weird VSync issue... I'm afraid I know very little about FPGA programming, but I was looking at the schematic, and if, right before the VSync gets combined with HSync, if you ANDed the VSync pulse with the "4Mhz clock/2048" line, that would make the VSync pulse only 4 scanlines long, more in spec. There could be further logic that can be added to get VSync down to 3 scanlines, which looks to be considered "normal"

I've used your suggestion to shorten the vsync in this version, please give it a try:

Arcade-DottoriKun_20210709.zip

(699.09 KiB) Downloaded 155 times

[jimmystones]

Well, here's the title screen with all graphics filled in. The raster bars are supposed to change offscreen, in a vertical column, but here they are going diagonally down and to the right (with a line added for help). This shows that the CPU is running too slowly compared to the video timing. Perhaps that's some inaccuracy in the Z80 core?

That diagonal seems too consistent to be a Z80 inaccuracy; perhaps each horizontal line is one dot too brief (or hsync period ?). Or clocks have a slightly wrong ratio... but I’m assuming it’s driven by a single clock with a low integer divider, so I’m thinking horiz. pixels.

In the MiSTer version it runs a 16Mhz (for video, divided by 2 if scandoubler is off) and a 4Mhz clock for the system. Probably could make them one with enables now you mention it thought. The verilator simulation is essentially the same.

Could be pixel width related, will have a play around with that.

[ccovell]

I've used your suggestion to shorten the vsync in this version, please give it a try:

Arcade-DottoriKun_20210709.zip

Thanks for this. Sadly, it didn't make any difference, and I still haven't a clue why.

[jimmystones]

Dang.. I'll try and build a version with a different clock speed that brings it closer to 60, see if that helps

[ccovell]

Or else, bring the HSync rate up to 15.734kHz...?