LarsDragon wrote:I use Mistica hardware. In other cores that not happen.

Then please ask the Mistica creators for support. It's nice that you guys enjoy your extra cheap boards. But asking us for help because your vendor doesn't care to support you is imho quite impolite by you. It was your explicit choice to buy a board without support.

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

Yeah. The ST chipset has quite some of that stuff. MMU has some ripple counters to reduce the carry chain. The msb of the low byte is the actual clock of the high byte! The DMA chip is even worse!

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.

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 ...

My core does run Enchanted Land. Even the original copy protected version. This game requires a quite accurate GLUE implementation. It is one of the very few commercial titles that uses hardware syncscroll. But that's not the main problem. The problem is that the initialization code has a bug, and it creates a GLUE effect that the programmer didn't expect. I described the behavior long ago when no ST emulator could run Enchanted Land properly.

ijor wrote:The problem is that the initialization code has a bug, and it creates a GLUE effect that the programmer didn't expect. I described the behavior long ago when no ST emulator could run Enchanted Land properly.

I think that was the point where i gave up. It does some switching inside some interrupt here and there and then waits for a specific reaction from the hardware which never happened. I could see it wait forever and tried to figure out what exactly it was waiting for and after a few days i decided that i was too far from the required level of accuracy and gave up.

Seeing all those hypercharged amigas and ataris I am very happy to see something focussing on accuracy.

And yes, you are correct that you can reach the same level of accuracy in software. But as long as there's a modern operating system underneath your emulator you will probably never be able to guarantee that it runs at a 100% constant speed. That's imho one of the key things the FPGA offers.

I actually don't know. But the people who sold you the hardware should be the first ones to ask for help. You seem to expect that we are supposed to fix all the general problems and provide you with updated cores and that the makers of your board are more or less just the last resort when it comes to problems known to be specific to your board.

Did you ask them for support regarding this core? What did they answer?

I actually don't know. But the people who sold you the hardware should be the first ones to ask for help. You seem to expect that we are supposed to fix all the general problems and provide you with updated cores and that the makers of your board are more or less just the last resort when it comes to problems known to be specific to your board.

Did you ask them for support regarding this core? What did they answer?

I should have consulted first those who sold it to me. I contact him as soon as possible, if I know something I will comment it. Thank you.

He was imho talking about a non-linearity (image narrowed on the right side only). The left shift is something I fixed this morning. But since not all screens are equal there may not be that magic setting that works for all of us. But all screens I've seen so far had the image slightly shifted to the left and my adjustment may at least reduce the problem for most of you.

On the other hand the core must be pretty good by now if the biggest problem is a slight left shift

Last edited by MasterOfGizmo on Wed Oct 24, 2018 5:57 am, edited 1 time in total.

This core is great. Hadn't tried it since a 2017 version. The new OSD and everything is just way improved. Only minor sound issues in a few games, could be ROM dump related honestly. Will definitely post some youtube videos when I get proper controllers for this. Gotta get back to some Mutant League.

Same problem on my real MiST and Sony TV with RGB. i.e. shifted slightly to the left on many games.

Does it do it on real hardware? Back in the day I bought a 14" Trinitron and with RGB input selected the picture did shift to the left. So I swapped it for a Panasonic.

A few years back I was given a 14" Trinitron (probably the same model I originally had!) But now with the Internet you can get the service manual and you can move the picture over using onscreen display. It is good because with a CRT I am only using it for RGB gaming and not watching TV so I optimise screen position for games.

I still have my Panasonic 14" but to move the picture I have to take off the cover and adjust a pot. I did think about extending the wires so it was at the back of the case near the SCART connector. But using the Sony instead at the moment.

Haven't noticed the shift to the left on other cores on my Sony Trinitron CRT. fpgagen-beta_20181021.rbf still has the slight shift to the left but I wouldn't call it an issue and I don't have a real megadrive to compare to. Comparing it to Retroarch on my RPi using an RGB SCART interface (rgb-pi.com) and that is centred fine on the same TV. I wouldn't swap my Trinitron for anything else, the picture is stunning! I dread the day it dies.

I have one problem: I can't map button C to my gamepad. In the wiki there is no mention of the C button (or others if You choose 6 button gamepad). It seems that I have the same gamepad as DannyPPC, but his mapping doesn't give me other buttons then A,B,X,Y, select and start.

On my pad SELECT button = C buttonI am using a Sega Saturn USB pad VID:04B4 PID: 010AThe problem I have is that I am not abble to map the physical button A of the pad whatever I try. In windows A button is working OK.

Xtro wrote:On my pad SELECT button = C buttonI am using a Sega Saturn USB pad VID:04B4 PID: 010AThe problem I have is that I am not abble to map the physical button A of the pad whatever I try. In windows A button is working OK.

Try on the OSD joystick test, what button shows up when you press "A".

Xtro wrote:On my pad SELECT button = C buttonI am using a Sega Saturn USB pad VID:04B4 PID: 010AThe problem I have is that I am not abble to map the physical button A of the pad whatever I try. In windows A button is working OK.

Try on the OSD joystick test, what button shows up when you press "A".

This is weird, when I press A doesn't show nothing on MiST OSD but on Windows 10 A button is the "1" button. In Windows when I press START, it says is button "9" (last one). In MiST I think START is mapped as the first button, as by default it maps "A" to the physical button START.I also tried with a clone Megadrine 6 buttons pad in DB9 port but doesn't use all buttons, only and A&B

Last edited by Xtro on Thu Oct 25, 2018 7:30 am, edited 1 time in total.