Genesis / Megadrive core ported to MiST

https://github.com/mist-devel/mist-board/wiki

Moderators: Mug UK, Zorro 2, spiny, Greenious, Moderator Team

slingshot
Captain Atari
Captain Atari
Posts: 331
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Sun Oct 21, 2018 5:44 pm

hyperterminal wrote:slingshot, with the new scandoubler of your latest fpgagen beta core I get an out of range message from my VGA monitor.

By the way: Why don't you name the core genesis.rbf like sorgelig did with the MiSTer core?


Strange, anyone else has a problem with the new (actually not new, used from another core) scandoubler?
Feel free to rename it on your SD-card :)

desUBIKado
Atari maniac
Atari maniac
Posts: 79
Joined: Sat Jan 06, 2018 11:49 pm

Re: Genesis / Megadrive core ported to MiST

Postby desUBIKado » Sun Oct 21, 2018 5:50 pm

hyperterminal wrote:slingshot, with the new scandoubler of your latest fpgagen beta core I get an out of range message from my VGA monitor.


The same in VGA mode on my LG Flatron M1917A, but only with Display = PAL. With Display = NTSC works fine.

DanyPPC
Captain Atari
Captain Atari
Posts: 443
Joined: Tue Feb 21, 2017 7:02 am

Re: Genesis / Megadrive core ported to MiST

Postby DanyPPC » Sun Oct 21, 2018 6:26 pm

On my Samsung TV/Monitor VGA PAL/NTSC display are ok.

Now Test Drive II screen is correct on VGA.

User avatar
Xtro
Atari freak
Atari freak
Posts: 55
Joined: Fri Jan 09, 2015 11:47 am
Location: Spain

Re: Genesis / Megadrive core ported to MiST

Postby Xtro » Sun Oct 21, 2018 7:06 pm

For me the new scandoubler version with scanlines works perfect, under PAL and NTSC. I am using a SVGA 31khz CRT monitor.

slingshot
Captain Atari
Captain Atari
Posts: 331
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Sun Oct 21, 2018 8:15 pm

Who has problems with the new scandoubler, please try the attached core.
You do not have the required permissions to view the files attached to this post.

DanyPPC
Captain Atari
Captain Atari
Posts: 443
Joined: Tue Feb 21, 2017 7:02 am

Re: Genesis / Megadrive core ported to MiST

Postby DanyPPC » Sun Oct 21, 2018 8:36 pm

Even this core works well in PAL VGA and NTSC mode.

hyperterminal
Atari maniac
Atari maniac
Posts: 89
Joined: Sun Jul 09, 2017 1:43 pm

Re: Genesis / Megadrive core ported to MiST

Postby hyperterminal » Mon Oct 22, 2018 3:33 am

slingshot wrote:Who has problems with the new scandoubler, please try the attached core.

This core works on my screen on VGA.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3095
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Genesis / Megadrive core ported to MiST

Postby Sorgelig » Mon Oct 22, 2018 6:46 am

MasterOfGizmo wrote:I've done some final minor clock adjustments to the tg68k. It's now running at the same rate it runs in the atari st and amiga cores. It's not cycle exact but as good as possible with the tg68k core.

I don't plan to touch this again unless you guys report a problem with it. So please check if the critical games still run.

You enable 7.6MHz for internal CPU cycles, but TG68_ENA_DIV doesn't stop/reset during internal cycles. This will misbehave as it will skip counter cycles when it exit internal cycle.

also i don't understand why you say BUS access requires 4 cycles. According to MC68000 manual BUS requires 8 cycles to access.

A bus cycle consists of eight states. The various signals are asserted during specific
states of a read cycle, as follows:
STATE 0 The read cycle starts in state 0 (S0). The processor places valid function
codes on FC0–FC2 and drives R/W high to identify a read cycle.
STATE 1 Entering state 1 (S1), the processor drives a valid address on the address
bus.
STATE 2 On the rising edge of state 2 (S2), the processor asserts AS and LDS,
or DS.
STATE 3 During state 3 (S3), no bus signals are altered.
STATE 4 During state 4 (S4), the processor waits for a cycle termination signal
(DTACK or BERR) or VPA, an M6800 peripheral signal. When VPA is
asserted during S4, the cycle becomes a peripheral cycle (refer to
Appendix B M6800 Peripheral Interface). If neither termination signal is
asserted before the falling edge at the end of S4, the processor inserts wait
states (full clock cycles) until either DTACK or BERR is asserted.
STATE 5 During state 5 (S5), no bus signals are altered.
STATE 6 During state 6 (S6), data from the device is driven onto the data bus.
STATE 7 On the falling edge of the clock entering state 7 (S7), the processor latches
data from the addressed device and negates AS and LDS, or DS. At
the rising edge of S7, the processor places the address bus in the high-
impedance state. The device negates DTACK or BERR at this time.


so effective BUS cycle is 1/8 of CPU clock.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3095
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Genesis / Megadrive core ported to MiST

Postby Sorgelig » Mon Oct 22, 2018 7:35 am

ah, they count every clock change as a state. So it's 4 clock cycles.
Btw, if DTACK is not asserted real 68K inserts one wait clock cycle till it will be asserted. Here it inserts the whole bus cycle (4 clock cycles).

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1215
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: Genesis / Megadrive core ported to MiST

Postby MasterOfGizmo » Mon Oct 22, 2018 11:28 am

Sorgelig wrote:You enable 7.6MHz for internal CPU cycles, but TG68_ENA_DIV doesn't stop/reset during internal cycles. This will misbehave as it will skip counter cycles when it exit internal cycle.

That's why TG68_SEL is in the ENA equation. This will make sure that the CPU will always get one full bus cycle and will wait until ENA_DIV reaches "01" before a new bus cycle begins.

Sorgelig wrote:also i don't understand why you say BUS access requires 4 cycles. According to MC68000 manual BUS requires 8 cycles to access.
...
so effective BUS cycle is 1/8 of CPU clock.

These are clock states and not clock cycles. A 68000 clock state is "clock low" or "clock high". So eight clock states (l,h,l,h,l,h,l,h) are four clock cycles. A full bus cycle is four CPU clocks cycles as discussed a few posts earlier when Slingshot mentioned that the tg68k runs too fast.
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1215
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: Genesis / Megadrive core ported to MiST

Postby MasterOfGizmo » Mon Oct 22, 2018 11:32 am

Sorgelig wrote:Btw, if DTACK is not asserted real 68K inserts one wait clock cycle till it will be asserted. Here it inserts the whole bus cycle (4 clock cycles).


That's true. I have tried to adjust that but then i run into problems with the fm sound. But you are correct and this should be fixed.
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1215
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: Genesis / Megadrive core ported to MiST

Postby MasterOfGizmo » Mon Oct 22, 2018 12:06 pm

With the new scandoubler my TV basically doesn't work at all ... But sometimes for a fraction of a second i see a correctly colored image, so the YPbPr conversion still works.

The TV then displays the same image two times side by side which means that it doesn't sync to every hsync but to every second hsync. I see that you resync the clock divider of the scan doubler to the incoming hsync. I am afraid this constantly happens on every incoming hsync and thus affects the clock of every second outgoing VGA hsync. Thus the hsync times of two subsequent scandoubled lines vary slightly. And my TV skips every second hsync since it's slightly out of phase.

The issue is somewhat complex (which is why i so far tried to avoid it): The base clock is 54Mhz. This is divided by 7 to get the 7.6 Mhz pixel clock. But for the scandoubler we need 14.2 Mhz which cannot be divided nicely from the 54Mhz. But without stable clock we get these artifacts like a slight jitter on the VGA hsync. I was already thinking about using a PLL to double the 14.2Mhz from the 7.6Mhz ...
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

slingshot
Captain Atari
Captain Atari
Posts: 331
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Mon Oct 22, 2018 12:31 pm

MasterOfGizmo wrote:With the new scandoubler my TV basically doesn't work at all ... But sometimes for a fraction of a second i see a correctly colored image, so the YPbPr conversion still works.

The TV then displays the same image two times side by side which means that it doesn't sync to every hsync but to every second hsync. I see that you resync the clock divider of the scan doubler to the incoming hsync. I am afraid this constantly happens on every incoming hsync and thus affects the clock of every second outgoing VGA hsync. Thus the hsync times of two subsequent scandoubled lines vary slightly. And my TV skips every second hsync since it's slightly out of phase.

The issue is somewhat complex (which is why i so far tried to avoid it): The base clock is 54Mhz. This is divided by 7 to get the 7.6 Mhz pixel clock. But for the scandoubler we need 14.2 Mhz which cannot be divided nicely from the 54Mhz. But without stable clock we get these artifacts like a slight jitter on the VGA hsync. I was already thinking about using a PLL to double the 14.2Mhz from the 7.6Mhz ...


I've measured the length of the hsync, they should be the same. Also the same amount of clocks should happen in every line (first I had a slight variation of the line lengths, and that caused zigzagged picture). Is it also not working with the update I've posted here? In that version I aligned the vsync negative edge to hsync's, and added a bit more to the length of the vsync. Or maybe the problem can be the scandoubler halves the time of the original hsync, and this is not enough? Fascinating this scandoubler works in lots of cores, just not here :)

Btw, the pixel clock is more complex, sometimes it's MCLK/8, sometimes MCLK/10, but until the line lengths are constant (3420 MCLKs in standard modes), I think it shouldn't cause an issue. The scandoubler reads in MCLK/4, writes in MCLK/2, it should fit nicely into the 3420 MCLKs.

slingshot
Captain Atari
Captain Atari
Posts: 331
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Mon Oct 22, 2018 12:59 pm

MasterOfGizmo wrote:
Sorgelig wrote:Btw, if DTACK is not asserted real 68K inserts one wait clock cycle till it will be asserted. Here it inserts the whole bus cycle (4 clock cycles).


That's true. I have tried to adjust that but then i run into problems with the fm sound. But you are correct and this should be fixed.


As I see, if the M68k affects the FM, that mostly come from the uploading FM code to the Z80's RAM. I think the zram code is currently wrong, it delays RAM access (even asserts WAIT_N), however on the real thing, the RAM is just wired directly to the CPU. M68k can access it only, when it holds reset or acquires the bus, however the exact timings are hidden in the Bus Arbiter chip.

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1215
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: Genesis / Megadrive core ported to MiST

Postby MasterOfGizmo » Mon Oct 22, 2018 3:57 pm

slingshot wrote:Is it also not working with the update I've posted here?


No change. Sometimes for a few seconds this in NTSC mode:
d.jpg


No image at all in PAL mode.
You do not have the required permissions to view the files attached to this post.
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

slingshot
Captain Atari
Captain Atari
Posts: 331
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Mon Oct 22, 2018 4:46 pm

MasterOfGizmo wrote:
slingshot wrote:Is it also not working with the update I've posted here?


No change. Sometimes for a few seconds this in NTSC mode:
d.jpg

No image at all in PAL mode.


:(
No idea then, sent a PR with the latest change, maybe you can try to adjust VS_LINES or the HSYNC_END variables. Is it OK in 15kHz?

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1215
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: Genesis / Megadrive core ported to MiST

Postby MasterOfGizmo » Mon Oct 22, 2018 5:20 pm

slingshot wrote:No idea then


Using the sync from the scandoubler in scandoubled ypbpr mode solved my problems :-)
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

User avatar
DrOG
Captain Atari
Captain Atari
Posts: 448
Joined: Sun Jul 31, 2016 8:23 pm
Location: Gyula, Hungary

Re: Genesis / Megadrive core ported to MiST

Postby DrOG » Mon Oct 22, 2018 5:51 pm

Hi!

First of all, thanks for everybody who participated in this project!

I have recently only very few time to play with my MiST, but today I tested the latest official beta release of the Genesis core (fpgagen-beta_20181020.rbf), and it works flawless on my picky Samsung TV! The only exception is the PAL standard over VGA, all other combinations (NTSC/PAL, VGA/RGB, YUV progressive/interlaced) work flawless! Here are some screenshots from the TV's frame buffer.

Thanks again your devoted work, it's a very nice progress!

Regards: Gábor

fpgagen_scart_ntsc

Image

fpgagen_scart_pal

Image

fpgagen_vga_ntsc

Image

fpgagen_yuv_240p

Image

fpgagen_yuv_480p

Image

fpgagen_yuv_576i

Image

fpgagen_yuv_576p

Image

slingshot
Captain Atari
Captain Atari
Posts: 331
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Mon Oct 22, 2018 6:26 pm

MasterOfGizmo wrote:
slingshot wrote:No idea then


Using the sync from the scandoubler in scandoubled ypbpr mode solved my problems :-)


Good :) Maybe the original hsync is too wide. As the screenshots of DrOG shows, probably shortening them would help on centering, too.

User avatar
DrOG
Captain Atari
Captain Atari
Posts: 448
Joined: Sun Jul 31, 2016 8:23 pm
Location: Gyula, Hungary

Re: Genesis / Megadrive core ported to MiST

Postby DrOG » Mon Oct 22, 2018 7:03 pm

I always thought that badly centered image is a cosmetic problem, on a 16:9 screen there's enough place on both sides anyway... Never supposed I can support core development process this way (making screenshots).

In the case of VGA image I centered the picture manually, but have no such option if I use SCART or RGB input...

desUBIKado
Atari maniac
Atari maniac
Posts: 79
Joined: Sat Jan 06, 2018 11:49 pm

Re: Genesis / Megadrive core ported to MiST

Postby desUBIKado » Mon Oct 22, 2018 7:10 pm

slingshot wrote:Who has problems with the new scandoubler, please try the attached core.

I'm sorry. This core and 181021 version with new scandoubler works in VGA / PAL mode on my LG FLATRON M1917A monitor. I must use RGB-DTV source and not RGB-PC. VGA / NTSC works with RGB-DTV and RGB-PC sources.

ijor
Hardware Guru
Hardware Guru
Posts: 3626
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Genesis / Megadrive core ported to MiST

Postby ijor » Tue Oct 23, 2018 12:33 am

slingshot wrote:This game masks VDP interrupts at the 68k side (SR register: 0x270..., AFAIK the second nibble is the IPL level mask). The VDP generates the interrupts, but since the 68k doesn't ack them, they remain pending.
After a while, a MOVE $2000,SR happens. In the Exodus emulator, it immediately fires the highest pending interrupt (a VINT). The game crash. The same happens in MiST.
In BlastEm, the interrupt doesn't get fired, just later on (didn't find what triggers it yet). The game works.
So what would be the correct behavior? Maybe Supervisor State set would prevent accepting interrupts?


Interrupts on the 68K are level triggered, except NMI (level 7) that is edge triggered. That means that if the interrupt mask is lower than the level currently present on the IPL signals, the CPU will trigger an interrupt disregarding the past events. Only the current state matters.

No, supervisor state won't prevent interrupts.
Fx Cast: Atari St cycle accurate fpga core

ijor
Hardware Guru
Hardware Guru
Posts: 3626
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Genesis / Megadrive core ported to MiST

Postby ijor » Tue Oct 23, 2018 12:37 am

jotego wrote:I'm sure you've heard it already but let me stress it once more. This is not emulation. We are making a hardware clone without using a CPU to simulate via software the original chip behaviour.


I don't want to hijack the thread, but as much as I love FPGA stuff (and I'm a core developer myself), the line between emulation and "clone" is a bit blurred. Some might even argue that FPGA is actually simulation and no the "real hardware". What really matters, IMHO, is accuracy.
Fx Cast: Atari St cycle accurate fpga core

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1215
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: Genesis / Megadrive core ported to MiST

Postby MasterOfGizmo » Tue Oct 23, 2018 6:11 am

ijor wrote:Some might even argue that FPGA is actually simulation and no the "real hardware". What really matters, IMHO, is accuracy.


I like to call it "hardware re-implementation". In the end you actually wire something up. But these are pretty tiny wires inside a chip and you connect them using small switches instead of solder. But physically the difference is pretty small.

But there are certain things you should do differently when using FPGAs over the real hardware even though it would actually be possible to do it exactly like it was in the real thing. E.g. in the "real" world all kinds of signals are used as clocks and there are asynchronous signals everywhere. While you could actually do it that way in an FPGA you would somehow "abuse" it and you should try to use just very few global clocks. Thus the resulting core differs from the real thing somewhat more than theoretically necessary.

But yes, accuracy matters. And i really love your approach of a cycle exact ST. That is actually what the MIST was supposed to be in the first place. So i am really looking forward to run "enchanted land" on an FPGA. If i remember correctly that was the game where i was sure i could never run it correctly on the MIST ...
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

LarsDragon
Atarian
Atarian
Posts: 4
Joined: Sun Dec 10, 2017 12:08 am

Re: Genesis / Megadrive core ported to MiST

Postby LarsDragon » Tue Oct 23, 2018 7:30 am

Hello, I've been testing this core  and I have noticed that the image is not ajustement in my Sony Tv, it is narrowed. The problem not is centered o geometry, I try to center it but it's cut,  in the real hardware is Ok. I use Mistica hardware.
In other cores that not happen.

20181023_081527_resized_1.jpg

20181023_081629_resized_1.jpg
You do not have the required permissions to view the files attached to this post.


Return to “MiST”

Who is online

Users browsing this forum: DanyPPC and 3 guests