Dottori-Kun core

User avatar
ccovell
Posts: 23
Joined: Tue May 26, 2020 4:46 am
Been thanked: 5 times

Dottori-Kun core

Unread post by 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
Dottori_Mister_Err.png (371 Bytes) Viewed 4775 times
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Dottori-Kun core

Unread post by jimmystones »

ccovell wrote: Mon Jul 05, 2021 3:14 pm 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
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Dottori-Kun core

Unread post by 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.
User avatar
ccovell
Posts: 23
Joined: Tue May 26, 2020 4:46 am
Been thanked: 5 times

Re: Dottori-Kun core

Unread post by 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!
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Dottori-Kun core

Unread post by 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.
User avatar
ccovell
Posts: 23
Joined: Tue May 26, 2020 4:46 am
Been thanked: 5 times

Re: Dottori-Kun core

Unread post by 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
NODATE-screen_0006.png (4.04 KiB) Viewed 4439 times
Image
NODATE-screen_0007.png
NODATE-screen_0007.png (5.17 KiB) Viewed 4439 times
Image
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Dottori-Kun core

Unread post by 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)
User avatar
ccovell
Posts: 23
Joined: Tue May 26, 2020 4:46 am
Been thanked: 5 times

Re: Dottori-Kun core

Unread post by 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.
Attachments
DottoriTestMRAs.zip
(9.66 KiB) Downloaded 113 times
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Dottori-Kun core

Unread post by jimmystones »

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

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!
Attachments
Dottoritest1.png
Dottoritest1.png (19.73 KiB) Viewed 4326 times
User avatar
ccovell
Posts: 23
Joined: Tue May 26, 2020 4:46 am
Been thanked: 5 times

Re: Dottori-Kun core

Unread post by 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
NODATE-screen_0008.png (4.28 KiB) Viewed 4293 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
Core Developer
Posts: 534
Joined: Sun May 24, 2020 9:30 pm
Has thanked: 19 times
Been thanked: 141 times

Re: Dottori-Kun core

Unread post by dshadoff »

ccovell wrote: Thu Jul 08, 2021 11:21 pm 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.
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Dottori-Kun core

Unread post by jimmystones »

ccovell wrote: Thu Jul 08, 2021 11:21 pm 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 119 times
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Dottori-Kun core

Unread post by jimmystones »

dshadoff wrote: Fri Jul 09, 2021 12:07 pm
ccovell wrote: Thu Jul 08, 2021 11:21 pm 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.
User avatar
ccovell
Posts: 23
Joined: Tue May 26, 2020 4:46 am
Been thanked: 5 times

Re: Dottori-Kun core

Unread post by ccovell »

jimmystones wrote: Fri Jul 09, 2021 9:12 pm 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.
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Dottori-Kun core

Unread post by jimmystones »

Dang.. I'll try and build a version with a different clock speed that brings it closer to 60, see if that helps
User avatar
ccovell
Posts: 23
Joined: Tue May 26, 2020 4:46 am
Been thanked: 5 times

Re: Dottori-Kun core

Unread post by ccovell »

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