Genesis / Megadrive core ported to MiST

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

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

User avatar
jotego
Captain Atari
Captain Atari
Posts: 187
Joined: Wed May 04, 2016 10:02 am
Location: Valencia (Spain)
Contact:

Re: Genesis / Megadrive core ported to MiST

Postby jotego » Thu Oct 25, 2018 9:48 am

ijor wrote:But I wasn't talking about that. What I meant is that an FPGA is not an ASIC. If you implement, say, a NOR on an FPGA, you are not actually producing a real NOR gate. You will use a table based LUT that, at the transistor level, it's completely different than a real NOR gate. So some might argue that an FPGA is some sort of hardware simulator. You might say that you don't care, the functional behavior is exactly the same. But that's exactly my point, what really matters is accuracy. And you can get, in theory, the same accuracy using plain software if you want.


I agree that the only way to make an exact replica, is to get the original chip masks, go to the foundry and get it done again. There is no other way, not even in an ASIC as modern digital technologies are plain different from those of the 80's. We do not do NMOS logic, we do not do hand layouts, we have on chip scan tests, and a lot of other different things.

So it is fair to say that when you use a different technology you will end up emulating part of the original behaviour in a different fashion. But the distinct point different from software emulation is clock cycle accuracy and electric equivalence. My aim when I do sound synthesizers is to have a core that could actually replace the original part on an original PCB. Could you do that with software? In some cases you can, in others you cannot. Not just because of pure CPU power needed, but also for the need of unusual frequencies either for video or sound. Yamaha chips are usually operated at funny frequencies like 55kHz, which are not the standard 44.1 or 48kHz of today's audio. Converting from one sample rate to another is not a trivial matter and introduces lag and artifacts. Ghosts'n Goblins arcade board has a funny vertical frequency too, not quite 60Hz. To name two examples.

The opposite case are FPGA cores that are really just emulating the system in the sense that they do not follow original timings at all, be it for lack of information or for lack of consciousness. I hear you have made an accurate Atari ST core. Impressive! Is that the one in the MiST repository?
--
Source code of all my cores here.
My Patreon page here.

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

Re: Genesis / Megadrive core ported to MiST

Postby MasterOfGizmo » Thu Oct 25, 2018 12:33 pm

ijor wrote: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.


So I now consider you to be some kind of 68k god :D

There seem to be several games that rely on the fact that the 68k requires some time to process irqs. Some games reportedly expect to be able to read the IRQ from some port before the same signal forces them to enter a irq handler. Slingshot pointed me to this:
http://gendev.spritesmind.net/forum/vie ... 8398#p8398

What i currently see in Fatal Rewind when running it in an emulator is that the game enables both possible irq sources, first the lower prio one and then the higher prio one in two subsequent move's. Then after some time IRQs are processed ... higher prio (VBI) first and then lower prio (HBI).

On the MIST/tg68k the interrupts are ack'd and processed immediately. So the low prio irq is handled immediately when it's enabled. And the higher prio irq happens afterwards when processing resumes after the low prio irq handler. This revereses the oder in which the IRQs are handled.

So i think i need to add some delay to IPL processing. BUT: Is this supposed to affect priority? If a low priority irq is signalled to the 68k and before it's being serviced the ipl level changes to a higher prio irq. Which level is then processed first? The question is basically: Do i delay just the fact that some irq has happened or do i delay the IPLs levels in some queue, so they are still processed in the order they happened?
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

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

Re: Genesis / Megadrive core ported to MiST

Postby ijor » Thu Oct 25, 2018 1:34 pm

jotego wrote:So it is fair to say that when you use a different technology you will end up emulating part of the original behaviour in a different fashion. But the distinct point different from software emulation is clock cycle accuracy and electric equivalence. My aim when I do sound synthesizers is to have a core that could actually replace the original part on an original PCB. Could you do that with software? In some cases you can, in others you cannot. Not just because of pure CPU power needed, but also for the need of unusual frequencies either for video or sound. Yamaha chips are usually operated at funny frequencies like 55kHz, which are not the standard 44.1 or 48kHz of today's audio. Converting from one sample rate to another is not a trivial matter and introduces lag and artifacts. Ghosts'n Goblins arcade board has a funny vertical frequency too, not quite 60Hz. To name two examples.


I don't see custom, unusual frequencies as a particular problem for software. It might be a problem for software running on a standard desktop OS. But you can run software on bare metal or on some microcontroller system. And micro controllers can use PLLs same as an FPGA does, actually many MCU already have configurable PLLs.

I do agree than an FPGA is much more suitable than software for replacing original chips on an original PCB. Software excels more when taking advantage of the huge amount of memory and processing power that you can get on a full system.

My main point is that software can be cycle accurate. It is not easy, and it might not be feasible for emulating the fastest and most complex platform. But it is certainly possible and sooner or later we are going to have them, at least in some cases.

I hear you have made an accurate Atari ST core. Impressive! Is that the one in the MiST repository?


A port for the MiST is planned, but it's only available for MiSTer for the time being. Currently is not in any repository, see this thread: viewtopic.php?f=117&t=34555
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1136
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Thu Oct 25, 2018 1:53 pm

goran wrote:
So, for this core, C button is Select. That solves it. Thanks. :)

Best regards,
Goran

But of course you can remap your buttons in the ini file.

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

Re: Genesis / Megadrive core ported to MiST

Postby ijor » Thu Oct 25, 2018 1:54 pm

MasterOfGizmo wrote:There seem to be several games that rely on the fact that the 68k requires some time to process irqs. Some games reportedly expect to be able to read the IRQ from some port before the same signal forces them to enter a irq handler. Slingshot pointed me to this:
http://gendev.spritesmind.net/forum/vie ... 8398#p8398
...
On the MIST/tg68k the interrupts are ack'd and processed immediately.


That is wrong. The CPU needs several cycles before being able to process an interrupt. In first place the IPL signals are synchronized, remember they are supposed to be ASYNC. Then there is the comparator logic with the interrupt mask on the SR. Only then it arrives to the exception logic ...

Furthermore, the CPU only checks interrupts at certain point on the microcode. It doesn't process interrupts on every cycle, it can't. The exact point depends on the microcode and then it is not constant. But it is never at the last microblock of any instruction because at that point is too late to take the decision if the exception would be processed or not. Let's take the simplest case of NOP that has two microinstructions. The interrupt has to arrive to the exception logic (after being already synchronized and compared) during the first one, or it will postponed to the next macroinstruction.

I can try to run some simulations and provide detailed waveforms. But it won't be too useful without a cycle accurate microcode implementation.

So i think i need to add some delay to IPL processing. BUT: Is this supposed to affect priority? If a low priority irq is signalled to the 68k and before it's being serviced the ipl level changes to a higher prio irq. Which level is then processed first? The question is basically: Do i delay just the fact that some irq has happened or do i delay the IPLs levels in some queue, so they are still processed in the order they happened?


The 68K has no concept of interrupt priority. That must be handled by an external interrupt controller. The CPU only sees a current interrupt request level. There is a precise cycle where the CPU latches the current IPL. If the IPL changes before that cycle it will be honored, otherwise it will be ignored. It is difficult to explain the timing in words. This really have to seen on a waveform.

I wouldn't bother too much fixing TG68K, at least not for this platform. You should be able to use my core shortly. TG68K, and Mike's version could still be very useful for other platforms when you don't care so much for cycle accuracy. My core is plain 68000 only.
Fx Cast: Atari St cycle accurate fpga core

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5085
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Genesis / Megadrive core ported to MiST

Postby Sorgelig » Thu Oct 25, 2018 1:59 pm

Both software and FPGA can make a cycle accurate emulation/replica. Software emulation just requires more resources like high CPU clock.

Software emulators are best for CPU emulation as this part shares many common things between emulator and emulated CPU. FPGA is best in chipset/graphics emulation.
So, from my point of view tight coupling between soft and FPGA emulation is a best combo. MiSTer is exactly this case, so potentially can have hybrid emulation. Just need someone self-motivated to create such emulator.

slingshot
Atari God
Atari God
Posts: 1136
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Thu Oct 25, 2018 2:37 pm

Interesting observations about interrupt delay in M68k:

http://gendev.spritesmind.net/forum/vie ... f=2&t=2202

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

Re: Genesis / Megadrive core ported to MiST

Postby ijor » Thu Oct 25, 2018 3:28 pm

slingshot wrote:Interesting observations about interrupt delay in M68k:
http://gendev.spritesmind.net/forum/vie ... f=2&t=2202


I didn't know the Genesis has 6800 interrupts. Yes, the timing of the interrupt ack cycle is affected in that case and it is synchronized to the E clock signal. That is implemented and well tested in my core because the ST has both types of interrupts.

But 6800 interrupts are defined at the interrupt ack cycle, not before. That means that it affects the timing of the interrupt cycle only. It doesn't affect at all what Till was asking. The delay from the point that the IPL signals an interrupt, until the point that the interrupt cycle starts, it's exactly the same disregarding the type of interrupt.
Fx Cast: Atari St cycle accurate fpga core

goran
Atari freak
Atari freak
Posts: 64
Joined: Sat Feb 27, 2016 4:17 pm

Re: Genesis / Megadrive core ported to MiST

Postby goran » Thu Oct 25, 2018 3:57 pm

slingshot wrote:
goran wrote:
So, for this core, C button is Select. That solves it. Thanks. :)

But of course you can remap your buttons in the ini file.


I know, but I needed the info that Select (in firmware) is C button (in core). ;)

Best regards,
Goran

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

Re: Genesis / Megadrive core ported to MiST

Postby MasterOfGizmo » Thu Oct 25, 2018 4:44 pm

ijor wrote:The 68K has no concept of interrupt priority. That must be handled by an external interrupt controller. The CPU only sees a current interrupt request level. There is a precise cycle where the CPU latches the current IPL. If the IPL changes before that cycle it will be honored, otherwise it will be ignored. It is difficult to explain the timing in words. This really have to seen on a waveform.


Ok, yes, the priority is an external thing but the CPU behaves differently depending on the level reported via IPL. My question was more or less: Are the IPL signals re-evaluated multiple times during one complete INT processing? E.g. there must be one point where the cpu detects that the IPL is != 7 and it thus has to take action. But there's also a moment where the decision which vector to use is done on base of the IPL. So when the IPL changes it may happen that some IPL that was applied at least one previous CPU cycle is ignored. That would rarely happen on the tg68k as it usually reacts immediately since most instructions require one cycle only. The IPL != 7 would always be handled at the end of the current instruction which in 99% of the cases means "now".
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

DanyPPC
Atari Super Hero
Atari Super Hero
Posts: 730
Joined: Tue Feb 21, 2017 7:02 am

Re: Genesis / Megadrive core ported to MiST

Postby DanyPPC » Fri Oct 26, 2018 6:30 am

Excuse me if I write nonsense, , but the MegaDrive also has a Z80 CPU. Perhaps this is used in some games for the audio part.
Could it be a problem related to the not perfect emulation of the Z80 or more simply a synchronism problem between the 68000 CPU and the Z80 ?

It's something I thought this morning.
Sorry if I wrote any nonsense

User avatar
vebxenon
Atari Super Hero
Atari Super Hero
Posts: 826
Joined: Fri Apr 24, 2015 12:10 pm

Re: Genesis / Megadrive core ported to MiST

Postby vebxenon » Fri Oct 26, 2018 6:40 am

DanyPPC wrote:Excuse me if I write nonsense, , but the MegaDrive also has a Z80 CPU. Perhaps this is used in some games for the audio part.
Could it be a problem related to the not perfect emulation of the Z80 or more simply a synchronism problem between the 68000 CPU and the Z80 ?

It's something I thought this morning.
Sorry if I wrote any nonsense


That's why also MegaDrive is compatible with Master System. And it's used for sound in Mega Drive mode. It could be used for having a good SMS core.

And yes, I was thinking also about the synchronism between both CPUs.
Just a computer and videogame lover :)

- Atari Jr 2600 clone
- Atari 7800 Peritel
- Atari XEGS
- Atari Lynx II
- Atari Jaguar
- MiST Board

User avatar
vebxenon
Atari Super Hero
Atari Super Hero
Posts: 826
Joined: Fri Apr 24, 2015 12:10 pm

Re: Genesis / Megadrive core ported to MiST

Postby vebxenon » Fri Oct 26, 2018 6:45 am


A port for the MiST is planned, but it's only available for MiSTer for the time being. Currently is not in any repository, see this thread: http://atari-forum.com/viewtopic.php?f=117&t=34555


Wow! I even sold my Atari MegaSTe when I bought my MiST. Hope this core will be ported :D
Just a computer and videogame lover :)

- Atari Jr 2600 clone
- Atari 7800 Peritel
- Atari XEGS
- Atari Lynx II
- Atari Jaguar
- MiST Board

slingshot
Atari God
Atari God
Posts: 1136
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Sat Oct 27, 2018 11:40 am

DanyPPC wrote:Excuse me if I write nonsense, , but the MegaDrive also has a Z80 CPU. Perhaps this is used in some games for the audio part.
Could it be a problem related to the not perfect emulation of the Z80 or more simply a synchronism problem between the 68000 CPU and the Z80 ?

It's something I thought this morning.
Sorry if I wrote any nonsense

There's no such thing as synchronization between the two CPUs. The FM chip is driven by one or the other, but not both at the same time. And those CPUs clock's are async originally (MCLK/7 and MCLK/15, ok they meet at every 105th cycle, but...). There can be timing problems if they both wants to access the 68k's RAM, but I don't think it's the case - however some rumors and my ears say Jotego fixed a lot of FM problems recently :)

DanyPPC
Atari Super Hero
Atari Super Hero
Posts: 730
Joined: Tue Feb 21, 2017 7:02 am

Re: Genesis / Megadrive core ported to MiST

Postby DanyPPC » Sat Oct 27, 2018 11:55 am

Many thanks for the explanation. So i test the new build.

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

Re: Genesis / Megadrive core ported to MiST

Postby ijor » Sat Oct 27, 2018 1:34 pm

MasterOfGizmo wrote:Ok, yes, the priority is an external thing but the CPU behaves differently depending on the level reported via IPL. My question was more or less: Are the IPL signals re-evaluated multiple times during one complete INT processing? E.g. there must be one point where the cpu detects that the IPL is != 7 and it thus has to take action. But there's also a moment where the decision which vector to use is done on base of the IPL. So when the IPL changes it may happen that some IPL that was applied at least one previous CPU cycle is ignored. That would rarely happen on the tg68k as it usually reacts immediately since most instructions require one cycle only. The IPL != 7 would always be handled at the end of the current instruction which in 99% of the cases means "now".


I'm out of home and currently without access to my stuff. I would give you a more detailed answer in a few days.

But it depends on what exactly you mean by "one complete INT processing". There is one precise cycle that the CPU latches the state of the IPL signals. The interrupt vector and the value signaled at the interrupt ack bus cycle are derived from that latch. IIRC, it is even called "ILL" in some Motorola docs. ILL stands for Interrupt Level Latch. Changes to the IPL signals before the cycle when ILL was written, are ignored. For this purpose the only value of the IPL signals that matters, is the state at the cycle that they were latched at ILL.

There is also one cycle that the CPU takes the decision to take the interrupt. As I said in a previous post, it is at least a couple of cycles before the instruction completes, and it depends on the specific microcode. IIRC, both of these events happen at the same cycle. The two events are the decision to interrupt, and latching the state of the IPL signals into ILL.

I will confirm this exactly when being back at home because the timing here is somewhat tricky.
Fx Cast: Atari St cycle accurate fpga core

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

Re: Genesis / Megadrive core ported to MiST

Postby MasterOfGizmo » Sat Oct 27, 2018 5:02 pm

That's sufficient. So there's one point where the ipl is evaluated.
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

User avatar
jotego
Captain Atari
Captain Atari
Posts: 187
Joined: Wed May 04, 2016 10:02 am
Location: Valencia (Spain)
Contact:

Re: Genesis / Megadrive core ported to MiST

Postby jotego » Sat Oct 27, 2018 8:48 pm

New release of JT12 for my birthday!

Changes:
-Turrican works!
-Amplitude modulation is now accurate
-FNUM-MSB behaviour has now the same implementation reported in original hardware

There are still known bugs, but I now have a good simulation environment and should be able to completely simulate this synthesizer core, feature by feature. So I expect to be able to complete it soon.
--
Source code of all my cores here.
My Patreon page here.

slingshot
Atari God
Atari God
Posts: 1136
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Sat Oct 27, 2018 11:24 pm

jotego wrote:New release of JT12 for my birthday!

Happy birthday!
Uploaded a new birthday edition with the updated FM. Also some improvements made several scenes of the Titan 2 demo actually enjoyable.

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 5085
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Genesis / Megadrive core ported to MiST

Postby Sorgelig » Sun Oct 28, 2018 2:35 am

jotego wrote:New release of JT12 for my birthday!

happy birthday!

User avatar
DrOG
Atari Super Hero
Atari Super Hero
Posts: 651
Joined: Sun Jul 31, 2016 8:23 pm
Location: Gyula, Hungary

Re: Genesis / Megadrive core ported to MiST

Postby DrOG » Sun Oct 28, 2018 4:45 am

:cheers: Boldog szülinapot!

desUBIKado
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Sat Jan 06, 2018 11:49 pm

Re: Genesis / Megadrive core ported to MiST

Postby desUBIKado » Sun Oct 28, 2018 8:24 am

Thank you very much to all of you who are improving this core. You are doing a awesome job. The image is already centered on the RGB output, and a graphic glicht that I had detected in the game Micro Machines 2 has disappeared. Finally, "Muchas felicidades Jotego".

hyperterminal
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 135
Joined: Sun Jul 09, 2017 1:43 pm

Re: Genesis / Megadrive core ported to MiST

Postby hyperterminal » Sun Oct 28, 2018 10:07 am

Just want to join in and say thank you for the latest updates to the Genesis core. I never thought the progress would go that far, especially not after the discontinuation of the MiST.

Attached is a photo of OutRunners running on the latest version of the Genesis core at 31 kHz on my LCD. As you can see, there is one bad flickering line on the screen of the second player, just on top of it's HUD (it can be best seen if you look above the word "TIME"). This bug is not present on the MiSTer version of the Genesis core.
You do not have the required permissions to view the files attached to this post.

desUBIKado
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Sat Jan 06, 2018 11:49 pm

Re: Genesis / Megadrive core ported to MiST

Postby desUBIKado » Sun Oct 28, 2018 10:52 am

Then it's worse ...

20181028_114945.jpg
You do not have the required permissions to view the files attached to this post.

slingshot
Atari God
Atari God
Posts: 1136
Joined: Mon Aug 06, 2018 3:05 pm

Re: Genesis / Megadrive core ported to MiST

Postby slingshot » Sun Oct 28, 2018 12:27 pm

desUBIKado wrote:Then it's worse ...

20181028_114945.jpg


Without a cycle-perfect CPU, it is hard to satisfy everything's timing needs. Try the Japanese version of Outrunners, it doesn't have this bug with the sky.


Return to “MiST”

Who is online

Users browsing this forum: danytyler and 3 guests