DrOG wrote:You're right, but I'm not familiar with FPGA programming, and there are some abandoned cores, like Apple ][ or ColecoVision, which have non-standard (reversed) sync polarity...

I just adjusted the sync polarity of the apple ][ core....But i am too stupid to use it. How does one load/run a nib image? Or has this been broken by firmware updates?

Once it's working it should be rather easy to add YPbPr support. Adding 15kHz support is a little more work as the scandoubler includes vital parts of the video circuitry and cannot just be omitted.

Now sync signal's polarity seems to be OK, but .NIB load does not work, tried it with the earlier core version from 2016 as well, bad also. It certainly worked, I remember that played Choplifter some months (a year?) ago. Perhaps some of the firmware updates broke it as you suspects.

DrOG wrote:NIB load does not work, tried it with the earlier core version from 2016 as well, bad also. It certainly worked, I remember that played Choplifter some months (a year?) ago. Perhaps some of the firmware updates broke it as you suspects.

Someone willing to help may test earlier firmware versions and figure out when exactly NIB loading broke. That may help finding the root cause.

Edit: Nevermind, I "fixed" the problem. There have been recent changes in the firmware which allow to support multiple disk images to be used simultaneously in one core (i think). I hoped this would have been done in a backward compatible way. But now it works again, anyway. So next is YPbPr support for the apple II.

MasterOfGizmo wrote:I hoped this would have been done in a backward compatible way.

Actually it is backward compatible if core uses correct S parameter. Some cores have strange parameter like S1 which never supposed to be correct as indexes are set by submenu number. Actually there are just couple cores used this strange parameters and can be easily corrected (as you already did). Otherwise multiple images are compatible.

DrOG wrote:NIB load does not work, tried it with the earlier core version from 2016 as well, bad also. It certainly worked, I remember that played Choplifter some months (a year?) ago. Perhaps some of the firmware updates broke it as you suspects.

Someone willing to help may test earlier firmware versions and figure out when exactly NIB loading broke. That may help finding the root cause.

Edit: Nevermind, I "fixed" the problem. There have been recent changes in the firmware which allow to support multiple disk images to be used simultaneously in one core (i think). I hoped this would have been done in a backward compatible way. But now it works again, anyway. So next is YPbPr support for the apple II.

When I did the change, I didn't know that cores are using S1 as the first disk. The 1 was simply ignored by the old firmware. It could be used as "1" for the first drive, "2" as second instead of "0" and "1", but it's too late to revert, I think. And as Sorgelig wrote, S1 was not really correct anyway.

Turned out it's not related to that string but a general build-to-build instability of the apple core. I just released a apple ii core that seems to work fine with loading NIBs and also has (untested) support for ypbpr.

MasterOfGizmo wrote:Turned out it's not related to that string but a general build-to-build instability of the apple core.

A proper sdc file in this case can help a lot (decoupling async clocks - but synchronizers still has to be used, which are missing at least from user_io in a lot of cores, this can result in unstable sd reading - , give the delays to the input-output ports, mostly to the SDRAM).

slingshot wrote:A proper sdc file in this case can help a lot (decoupling async clocks - but synchronizers still has to be used, which are missing at least from user_io in a lot of cores, this can result in unstable sd reading - , give the delays to the input-output ports, mostly to the SDRAM).

Yes, the user_io wasn't a master piece and is likely to be the culprit in the apple core as well as the msx core. Are there improved versions?

slingshot wrote:A proper sdc file in this case can help a lot (decoupling async clocks - but synchronizers still has to be used, which are missing at least from user_io in a lot of cores, this can result in unstable sd reading - , give the delays to the input-output ports, mostly to the SDRAM).

Yes, the user_io wasn't a master piece and is likely to be the culprit in the apple core as well as the msx core. Are there improved versions?

Try the one from the C16 core, it should be a drop-in replacement. Or Sorgelig's mist_io version, but it has a slight interface change.

Found in his repository 2 new Sega console cores as well, a Game Gear and an SG-1000. Tried both, although they have a 640x480@60Hz video out, they are not compatible with my picky TV - used my homemade adapter to convert the RGB video to YUV, sorry for the poor picture quality. The second one is not working, but the first works with some games, tried Frogger, but was unable ot start (Start button is inoperational, which is a known bug).

I want to thank to all who are participating in these projects: MasterOfGizmo is back, thanks to him Gehstock has a working MiST again, slingshot is improving the VIC20 core, GreyRogue and Sorgelig are improving the PC Engine core on MiSTer - perhaps someday someone will port their work to MIST. It was untimely to bury this FPGA, maybe this is the beginning of a second Renaissance?

Cheers: Gábor

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

I use my own-manufactured converter described in this topic earlier, if cores are not native compatible with my TV's (rather picky) VGA (or less sensitive) SCART or component input:viewtopic.php?f=115&t=31006&start=50#p333402

It gives a nice sharp picture if input is interlaced, but washed video if the source is progressive.

I noticed that the Core C64 and Amiga are not well synchronized at 50Hz. There is always a drop frame on games with scrolling screen.This happens on VGA 50 (56Hz) too.In RGB > Crt Scart it's ok instead.