Atari 2600 / VIC 20

[desUBIKado]

Excellent work!
Thanks slingshot MasterOfGizmo

I tried four .CRT files, first I put these common options

• Enable 8K+: Expansion: Off
• Enable 3K Expansion: On
• Enable 8k ROM: RW

And then

"Visible Solar System" and "A world at war" with:

• CRT with load adress: Yes

"Amidar" and "Videomania" with:

• CRT with load adress: No

All of them work fine.

[MasterOfGizmo]

Most carts seem to be NTSC. I had the image shifted to the top left corner on real hardware as well. This happens because cartridges need to initialize the video hardware themselves and they initialize a PAL VIC as if it was a NTSC one.

One would have to implement a proper NTSC mode for the VIC in which the NTSC cartriges would display centered. But I doubt it's worth the effort ....

[MasterOfGizmo]

For me the floppy has stopped working in this latest core ...

[slingshot]

For me the floppy has stopped working in this latest core ...

Strange, it just blinking for me after a reset with extensions enabled (and with normal DOS), otherwise it's working.

[DanyPPC]

Works here.

[ericgus]

One would have to implement a proper NTSC mode for the VIC in which the NTSC cartriges would display centered. But I doubt it's worth the effort ....

As someone who lives in NTSC land, and grew up with an NTSC Vic20 it would be worth it for me..

[MasterOfGizmo]

For me the floppy has stopped working in this latest core ...

It works. Dunno why i was having problems ....

[DanyPPC]

I think the volume of sound is very high, in some cases distorted.
Tutankham controls needs to be fixed.

Only little fixes to make this core one of the best for the MiST.

[slingshot]

I think the volume of sound is very high, in some cases distorted.
Tutankham controls needs to be fixed.

Tutankham thinks you always want to go right...didn't find the reason yet.

[vebxenon]

Thanks for the updates!!

[MasterOfGizmo]

Tutankham thinks you always want to go right...didn't find the reason yet.

Same with exterminator

[slingshot]

Tutankham thinks you always want to go right...didn't find the reason yet.

Same with exterminator

Exterminator (the Centipede-like game) is OK for me. Maybe because I did something with paddle-handling.

[slingshot]

Anybody knows is there any difference between the sound of the games in PAL/NTSC, or the VIC chip compensates the different clocks?
AFAIK the formula for the sound frequency is frequency = clock / (127 - X), but this makes a difference in tones between NTSC/PAL models.

[goran]

It does make a difference indeed. VIC does not compensate for anything, nor SID nor 6510, they are clocked differently.
6510 - 1.023 MHz NTSC and 0.985 MHz PAL
VIC-II - 17.73447 MHz PAL or 14.31818 MHz NTSC
for SID there is 50Hz PAL or 60HZ NTSC, so PAL song will be faster and pitched higher on NTSC machine

Edit: this is not C64 thread!

[slingshot]

Ok. The CPU clock in the VIC20 has more difference (about 20% between PAL and NTSC), so the tone change is much more obvious.
Nevertheless, here's a release with a separate NTSC build:
https://github.com/gyurco/VIC20_MiST/releases

[MasterOfGizmo]

For a "real" NTSC vic20 the 6561 needs to be replaced by a 6560 which would very likely have a significantly different video timing. Fixing this will make all those cartridge image show a centered screen.

[slingshot]

For a "real" NTSC vic20 the 6561 needs to be replaced by a 6560 which would very likely have a significantly different video timing. Fixing this will make all those cartridge image show a centered screen.

That's no problem, I've fixed the timings for the display. Just didn't touch the audio part.

[MasterOfGizmo]

Ah, cool.

I am in fact not so happy with the fact that there are now different cores for PAL and NTSC. I know you did this for a very good reason to avoid running the clocks through a multiplexor. But there's imho an elegant solution. The reconfigurable PLL block: https://www.intel.com/content/dam/www/p ... config.pdf

That way the clock would come directly from the PLL (which you like) but the clock rate could still be adopted between NTSC and PAL (which i like) ... but i have never used the feature. I'll eventually have a look at that.

[slingshot]

Ah, cool.

I am in fact not so happy with the fact that there are now different cores for PAL and NTSC. I know you did this for a very good reason to avoid running the clocks through a multiplexor. But there's imho an elegant solution. The reconfigurable PLL block: https://www.intel.com/content/dam/www/p ... config.pdf

That way the clock would come directly from the PLL (which you like) but the clock rate could still be adopted between NTSC and PAL (which i like) ... but i have never used the feature. I'll eventually have a look at that.

I also don't like the separete builds, just it significantly lowered the compile time for the C16 core (and fixed the timings, too). But do you think reconfigurable PLL is working on Cyclone III? I didn't see mentioned that in the document. Would be awesome if we could use it. The different clock frequencies are needed anyway.
For the C16 core, there's another problem, not enough BRAM for storing NTSC and PAL kernals in the same build.

PS: Found out the issue with Tuthankam controls, there's a new release with the fix.

[MasterOfGizmo]

But do you think reconfigurable PLL is working on Cyclone III?

Have yet to actually try to use it. But the megawizard lets me pick one for Cyclone III. So i think it works...

For the C16 core, there's another problem, not enough BRAM for storing NTSC and PAL kernals in the same build.

Hmmm ... good point. I wonder how big the differences are. I'd assume they are only a few bytes so one could try to patch those on the fly.[/quote]

[slingshot]

But do you think reconfigurable PLL is working on Cyclone III?

Have yet to actually try to use it. But the megawizard lets me pick one for Cyclone III. So i think it works...

If you can figure out how it works in one core, I can adapt it to the other As I see, it needs an existing PLL's output for the input clock, then put some magic numbers into it, then you can get something on the output clock.

Hmmm ... good point. I wonder how big the differences are. I'd assume they are only a few bytes so one could try to patch those on the fly.

Would be not that big, since you can switch modes via 3 numbers in the monitor (just different values for a TED register). However if you switch ROMs (like to Jiffy), probably another place must be patched. Or move ROMs to SDRAM, the loader is already there for prgs. But then no built-in ROMs are possible (not a big problem I think).
About the clocks I wonder what if the same frequencies are used in C16 for both modes, the difference is so small.

[MasterOfGizmo]

Switching roms means that you place a custom one on the sd card. That one then of course needs to match the pal/ntsc setting you are intending to use. But with a single built-in rom the patching could be hard coded.

[slingshot]

Switching roms means that you place a custom one on the sd card. That one then of course needs to match the pal/ntsc setting you are intending to use. But with a single built-in rom the patching could be hard coded.

Yes, this is an option. I'm not on high priority doing this however, have lots of another things on my todo list

[DanyPPC]

Great update, now Bandits works very well

[SchneiderCPC664]

I have trouble with latest cores and I need your help.
With my oldest VIC core I can launch "Alien Bitz.prg" only by selecting the file in the menu. "Vic-Man.prg" does not run in this core.
In core 180914 I have to execute the "RUN" command to start Vic-Man (the game sound is here very very loud!). But in this core "Alien Blitz.prg" don't run.
In core 181103 no PRG file is running.
I don't know what I make wrong.