Genesis / Megadrive core ported to MiST

[danialbi]

I see
Then mist.ini I downloaded was just an example...
Then I understand that if I want the settings to apply only to a specific core I have to put in the first line:
[genesis]
instead if I put:
[mist]
then all the mappings will apply to all cores?

What happens if I remove completely mist.ini?

[DanyPPC]

No, no, no... you have to put [mist] for the first, here my mist.ini:

[mist]
scandoubler_disable=0
mouse_boot_mode=0
joystick_disable_shortcuts=0
joystick_ignore_hat=0
joystick_ignore_osd=0
key_menu_as_rgui=0
joystick_remap=0810,E501,1,2,4,8,8,10,20,10,400,800,0,0,40,80
joy_key_map=1000,E2
joy_key_map=2000,E6
joy_key_map=4,51
joy_key_map=8,52

[genesis]
joystick_remap=0810,E501,1,2,4,8,20,40,20,10,10,40,0,0,40,80
;scandoubler_disable=1

[danialbi]

I understand
Sorry to insist, but there is something wrong in latest Core about joystick mapping
Forget about mist.ini for a second - just default mapping
That's what I tried:
Load core, test Joystick1, my But10=START
Load game (frogger)

I have run:
fpgagen-beta_20180930.rbf
fpgagen-beta_20170518.rbf
In both cases, game starts OK by pressing But10

When I try (with exactly same settings, 3button only):
fpgagen-beta_20181013.rbf
Then pressing But10 does nothing. I have tested again Joystick1, My But10=START

Please check...

EDIT:
DanyPPC Are you sure you can start games with joystick? (no keyboard)

[slingshot]

I bet you didn't update the firmware.

Starting from fpgagen-beta_20181013 firmware_181013 or newer is required!

[danialbi]

Thank you very much slingshot
I didn't notice the new MiST FW
... supporting more than 4 buttons on USB gamepads !!
Now it works fine
SOLVED

[DanyPPC]

Oh, well !

[DanyPPC]

Report:

Story of Thor works in PAL mode.

[slingshot]

Report:

Story of Thor works in PAL mode.

Good! As I see, it's a V30 game (the first I met with), so it should not work in NTSC mode at all by design.

[slingshot]

@MasterOfGizmo

I'm debugging a problematic game (Bram Stoker's Drakula), and found out some instructions are _much_ faster in TG68k than in the emulator I'm comparing with. The most notable is MOVEM.l d0-d7/a0-a6, (-a7), with all possible registers (looks like similar to PUSHA on the Z80). The game depends on advancing the time enough, when it checks at a later point, it should read back 225 from the VCOUNT value. But it reads 224 now. It can be fixed with tweaking the VDP with advancing the VINT time, but if the CPU can be fixed, it would be a more proper solution.

[slingshot]

Another strange CPU issue: Fatal Rewind

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?

[MasterOfGizmo]

The most notable is MOVEM.l d0-d7/a0-a6, (-a7),

The tg68k is not cycle exact. So there are differences. But they are usually in the range of +/-5%.

According to http://oldwww.nvg.ntnu.no/amiga/MC680x0 ... mpetc.HTML The "movem.l regs,-(aX)" takes 8+8n clock cycles with n being the number of registers to store. A bus cycles on the real 68000 is four clock cycles, so this is 2+2n bus cycles which makes sense since each register is 32 bits and it takes two bus cycles to write 32 bits via the 16 bit bus. In the genesis the CPU is clocked at 53/7=~7.6 Mhz.

For the TG68 in the fpgagen the clock is additionally divided by 4 resulting in ~1.9MHz. But it runs at full speed. It needs one cycle to fetch the instruction, one to fetch a word containing the register mask and then it writes all registers one 16 bit word per cycle. This results in 2+2n bus cycles.

So the movem.l instruction should be quite exact with respect to the execution time.

[slingshot]

The most notable is MOVEM.l d0-d7/a0-a6, (-a7),

The tg68k is not cycle exact. So there are differences. But they are usually in the range of +/-5%.

According to http://oldwww.nvg.ntnu.no/amiga/MC680x0 ... mpetc.HTML The "movem.l regs,-(aX)" takes 8+8n clock cycles with n being the number of registers to store. A bus cycles on the real 68000 is four clock cycles, so this is 2+2n bus cycles which makes sense since each register is 32 bits and it takes two bus cycles to write 32 bits via the 16 bit bus. In the genesis the CPU is clocked at 53/7=~7.6 Mhz.

For the TG68 in the fpgagen the clock is additionally divided by 4 resulting in ~1.9MHz. But it runs at full speed. It needs one cycle to fetch the instruction, one to fetch a word containing the register mask and then it writes all registers one 16 bit word per cycle. This results in 2+2n bus cycles.

So the movem.l instruction should be quite exact with respect to the execution time.

I calculated as: the cpu clock is roughly the same as the pixel clock. So 8+8*15=128 cycles would be required for this instruction, it's about 128 pixels. But currently the horizontal counter advances much less.

Created a SignalTap capture: INTACK cycle is about 22 pixels, but I read it should be 44 cycles. The long MOVEM instruction is 70 pixels, should be more than 100. So these are 30-50% faster than necessary. At the end, read of the counter happens about 150 cycles(pixels) before it should.

[MasterOfGizmo]

I calculated as: the cpu clock is roughly the same as the pixel clock. So 8+8*15=128 cycles would be required for this instruction, it's about 128 pixels. But currently the horizontal counter advances much less.

Created a SignalTap capture: INTACK cycle is about 22 pixels, but I read it should be 44 cycles. The long MOVEM instruction is 70 pixels, should be more than 100. So these are 30-50% faster than necessary. At the end, read of the counter happens about 150 cycles(pixels) before it should.

The movem.l with 15 registers takes 32 (2*15+2) bus cycles. A bus cycle at 1.9MHz is roughly 500ns, so the movem.l should be 16us. One line at 15khz is 64us. So a movem.l is roughly 1/4 line which at 512 pixel clock per line is roughly 128 pixels. So we agree on that

So something is wrong here. The tg68 is enabled only when TG68_ENA_DIV(1 downto 0) is "11". So that's the CPU clock to bus cycle conversion. The "CPU clock" is MCLK gated by VCLK. VCLK is is '1' whenever VCLKCNT is 3 and VCLKCNT runs from 0 to 6 basically dividing it's clock by seven. That clock it's dividing is MCLK which in turn is a 54MHz clock.

So MCLK is 54 Mhz, VCLK is 7.71 MHz. The tg68k is enabled at 1.92 Mhz. Thus it cannot write the bus faster than 500ns. And thus storing 15 long words cannot happen in less than 16us. Which equals 128 Pixels at 15khz with 512 pixels per line. You say movem.l is less than 70 pixels.

This cannot all be true at the same time ...

[slingshot]

The movem.l with 15 registers takes 32 (2*15+2) bus cycles. A bus cycle at 1.9MHz is roughly 500ns, so the movem.l should be 16us. One line at 15khz is 64us. So a movem.l is roughly 1/4 line which at 512 pixel clock per line is roughly 128 pixels. So we agree on that

So something is wrong here.

Definitely wrong
As I see from the capture, it writes one register in 14 MCLKs, which is 2 CPU clocks - twice as fast as it should be.
Upd.: I was a bit wrong, since they're 32 bit registers, so one write took 28 MCLKs, which is 4 CPU clocks instead of 8. 4 clocks - 1 bus cycle, 8 - 2. It's still in turbo mode.

[jotego]

The game Dragon, the Bruce Lee Story doesn't work with FPGAgen version 2018-10-13. I don't know if it worked with previous versions, I suppose it didn't. It's just a blank screen.

[jotego]

The game Dragon, the Bruce Lee Story doesn't work with FPGAgen version 2018-10-13. I don't know if it worked with previous versions, I suppose it didn't. It's just a blank screen.

[slingshot]

The game Dragon, the Bruce Lee Story doesn't work with FPGAgen version 2018-10-13. I don't know if it worked with previous versions, I suppose it didn't. It's just a blank screen.

It works for me, only found a PAL version. Seems another V30 game.

[Sorgelig]

It works for me, only found a PAL version. Seems another V30 game.

I have both US and EU versions. Both work on MiSTer. EU version is V30 but actually doesn't use the 16 bottom lines.

[MasterOfGizmo]

As I see from the capture, it writes one register in 14 MCLKs, which is 2 CPU clocks - twice as fast as it should be.

As already written in PM it was actually four times as fast as it should have. Although it never really ran that fast because memory access was slowing it down somewhat, Still we now know that most Genesis games cope with a way faster CPU. I wonder if there are games that would benefit from it like giving a faster refresh rate or the like.

[hyperterminal]

As already written in PM it was actually four times as fast as it should have. Although it never really ran that fast because memory access was slowing it down somewhat, Still we now know that most Genesis games cope with a way faster CPU. I wonder if there are games that would benefit from it like giving a faster refresh rate or the like.

Here is a compatibility list for games running with a faster CPU: http://www.sega-16.com/forum/showthread ... ility-List

[MasterOfGizmo]

Here is a compatibility list for games running with a faster CPU: http://www.sega-16.com/forum/showthread ... ility-List

Ah, cool!. Given the fact that we were basically overclocking to 30 Mhz we'd probably see even more games getting problems.

Anyway, Micro Machines now also runs again.

[MasterOfGizmo]

BTW: Did you now that you can place any rom under the name "genesis.rom" in the SD cards root directory and it will be loaded automatically at startup. I have mine permanently set to run Sonic.

For some reason the latest changes prevent the titan overdrive demo to run further than the initial robot progress bar.

[slingshot]

BTW: Did you now that you can place any rom under the name "genesis.rom" in the SD cards root directory and it will be loaded automatically at startup. I have mine permanently set to run Sonic.

For some reason the latest changes prevent the titan overdrive demo to run further than the initial robot progress bar.

I'm using a test rom as a gensis.rom currently
Yes, the clock change and the FM FIFO doesn't play nicely together. Removing the FIFO helps, but then the FM problems which fixed by it return.

[jotego]

I have just pushed a new version of JT12 that is more robust with games that do not check the busy bit. It may remove the need for the FIFO. With correct Z80/bus timing, there should be no need for FIFO.

So master branch of JT12 repository now has PM support and is more robust. I think all features are in place now. Still Turrican sounds horrible, though. The rest of the games I've checked sound good now.

[slingshot]

I've uploaded a new release with this jt12 version. I would add Chaos Engine as a game with horrible sound btw
Besides the sound improvement, there were lots of development in the VDP area, too:
- the VDP passes 95 of the VDPFIFOTestROM now! It's a huge progress compared to the latest beta's 15. Even Titan Overdrive I's timing sensitive parts are OK now, or look at Chaos Engine's scrolling (but my emulator still suxx). Would be good to fix the remaining tests, too (especially the DMA COPY ones).
- M68k CPU speed was fixed, also the T80 core is updated to the same version as proved to be cycle-exact in various 8 bit cores.
- And small minor fixes here and there.