C64 Core

[PiddlyD]

O486]
MIDI_BAUD = 38400
TCP_SOUND_CONNECT = /media/fat/SOUNDS/connect_sav.wav

Looks like this is duplicated & corrupt (missing '[A'), delete that part - Doubt that has anything to do with the problem, but worth fixing...

I'm not sure why its not working. It almost looks like the baud rate is incorrect. What happens if you type commands such as "ATHELP" or "ATVER"?

At one point (a while ago...) the location of the MidiLink.INI changed from '/media/fat/config' to '/media/fat/linux' - are you editing the one in the 'linux' directory? If there is one in 'config' you can delete it...

I was able to connect to Afterlife BBS (afterlife.dynu.com:6400) with both of my MiSTers with the 4/25 C64 core - I have one MiSTer that is more affected by core stability issues than the other.

I noticed that the C64 core does not start when run as 1st after powering on MiSTer. Is this a known issue? After reboot it will start correctly.

I get that on one of my MiSTers but not the other. If i just reload the core it seems to work the 2nd time.

I'm starting to wonder if the Super I/O expansion board could be the problem. I have one from cbmstuff

You can see that he didn't follow the reference design completely. The smaller buttons don't fit the default build for a MiSTer case from Thingiverse, for example.

I'll check your advice and see. There has to be *something* wrong somewhere. It is so strange that my Minimig and AO486 are both able to connect to this BBS with no problem, it is only the C-64 core that gives me issues.

[BBond007]

I'm starting to wonder if the Super I/O expansion board could be the problem.
...

Definitely not the problem. Have the same board in one of my MiSTers...

Its probably something simple I'm overlooking...

[PiddlyD]

O486]
MIDI_BAUD = 38400
TCP_SOUND_CONNECT = /media/fat/SOUNDS/connect_sav.wav

Looks like this is duplicated & corrupt (missing '[A'), delete that part - Doubt that has anything to do with the problem, but worth fixing...

I'm not sure why its not working. It almost looks like the baud rate is incorrect. What happens if you type commands such as "ATHELP" or "ATVER"?

At one point (a while ago...) the location of the MidiLink.INI changed from '/media/fat/config' to '/media/fat/linux' - are you editing the one in the 'linux' directory? If there is one in 'config' you can delete it...

I was able to connect to Afterlife BBS (afterlife.dynu.com:6400) with both of my MiSTers with the 4/25 C64 core - I have one MiSTer that is more affected by core stability issues than the other.

I noticed that the C64 core does not start when run as 1st after powering on MiSTer. Is this a known issue? After reboot it will start correctly.

I get that on one of my MiSTers but not the other. If i just reload the core it seems to work the 2nd time.

So... this is weird... if I just go into the terminal and enter ATHELP or ATVER... I get the same line noise effect. Checkerboard patterns across the screen.

I figured it out... I had User Port set to Joysticks, not UART. I switched that, and everything is now connecting fine.

[Paradroyd]

I figured it out... I had User Port set to Joysticks, not UART. I switched that, and everything is now connecting fine.

That same exact thing got me a month or two ago..whenever the user port setting layout initially changed. It suddenly defaulted to "joysticks" and the modem quit working until I figured out what was going on and changed it.

[BBond007]

I figured it out... I had User Port set to Joysticks, not UART. I switched that, and everything is now connecting fine.

That is good news. I knew it was something simple I was overlooking. Totally forgot about that setting

[Sorgelig]

I have no problem with starting the core. It always starts from the first time.

I'm starting to wonder if the Super I/O expansion board could be the problem.

You need to understand such closed source boards are not supported. It may have different kind problems as it uses different design, especially for SDRAM - so timing may be different.

[BBond007]

I have no problem with starting the core. It always starts from the first time.

I'm starting to wonder if the Super I/O expansion board could be the problem.

You need to understand such closed source boards are not supported. It may have different kind problems as it uses different design, especially for SDRAM - so timing may be different.

I'm not sure if you are implying these issues are related? It was evdberg who mentioned problems with starting the core. PiddlyD mentioned owning the the unsupported AIO board...

My (older) MiSTer that does not always get video on the C64 core first try has a regular SDRAM and no IO board. I have swapped SD cards between both units and the problem follows the DE10-nano, not the SD card configuration. The (newer) DE10-nano with the (unsupported) AIO board has never had the issue. I do have an extra (shorter) SDRAM I can try in my older DE10.

[evdberg]

Also would it be possible to switch the screen frequency to 50Hz of the chosen screen resolution (in my case 1920x1080) when PAL is selected and to 60Hz when NTSC is selected? Vsync=1 does not work for me with the C64 core in combination with my monitor.

Never mind, I tried the vsync_adjust=1 setting again and now it works fine. I guess I got the black screen when I tried it the first time on the C64 core, and when I tried the Xevious arcade core after that, it displayed a garbled screen, so I concluded it did not work with my display.

Sometimes I still get the black screen on boot of the C64 core, but it is not necessarily after startup of the board. Pretty weird. I do not have an IO board, only the XS SDRAM module.

[yellperil]

This is probably a completely useless bug to implement in the core . . .
. . . but the T65 CPU doesn't seem to implement the page boundary bug for shy and shx illegal opcodes.

As per this article http://codebase64.org/doku.php?id=base: ... x_as_stx_y

ldy #$14
ldx #$01
shy $0eff,x

I've checked it in VICE and it works fine there, but not in the MiSTer core.

[slingshot]

This is probably a completely useless bug to implement in the core . . .
. . . but the T65 CPU doesn't seem to implement the page boundary bug for shy and shx illegal opcodes.

Good exercise for some HDL-development VICE tests can be used for validating.

[evdberg]

On the internal scaler the scrolling is 'wobbly'. This is caused because some pixels are multiplied by 4 and some by 3 to scale from 370x280 to fit 1920x1080.
Is it possible to scale by the same multiplier, so 4 for 1920x1080? Then you would get 1480x1120. Fitting this into 1080p would mean loosing 40 pixels, but these are only 10 original pixels, so 5 lines of the top and the bottom of the screen. I would not mind missing these, and get smooth scrolling in return. You could do the same for the sides and fit the picture into 1440x1080 to retain the original 4x3 aspect ratio.

[Sorgelig]

use Lanczos filters, so all pixels will look the same.

[evdberg]

use Lanczos filters, so all pixels will look the same.

All pixels will then get that ugly ringing around it, which the internal filter does not have. That is definitely not the same as what I proposed.

[Sorgelig]

There are several versions - some of them don't have noticeable ringing.
This is the only you can have beside the integer scaling ini option.

What you told is not new and discussed many times already. MiSTer is not locked to single output resolution.

[evdberg]

There are several versions - some of them don't have noticeable ringing.

Lanczos2_15 is indeed pretty good.

This is the only you can have beside the integer scaling ini option.

I have been looking for that option, but must have missed it. I just looked at the ini file again, but do not see what option I need to enable. Can you give a hint?

What you told is not new and discussed many times already.

Sorry for that, I am still pretty new to this.

MiSTer is not locked to single output resolution.

I am aware of that, and have been playing with both video_mode and vsync_adjust. However, my monitor is 1920x1080, so I figured it best to keep it at that resolution.
Just thinking. If the C64 core would render at 360x270 (instead of 370x280) it would automatically scale integer to 1440x1080. Is that a possibility? I am just trying to get the very best image quality for the C64 core. Thanks for all your work and help!

[Sorgelig]

Code: Select all

vscale_mode=0          ; 0 - scale to fit the screen height.
                       ; 1 - use integer scale only.
                       ; 2 - use 0.5 steps of scale.
                       ; 3 - use 0.25 steps of scale.

note it's only for vertical scale. Horizontal scale will depend on aspect ratio.

[evdberg]

I have been testing with that option, but that also does not do what I want. How do I set the scaling to times 4?

[Sorgelig]

Scaling cannot cut the video. So you cannot simply set the magnifier and expect it will cut the parts of video.

[SegaMan]

Dont get stable picture on CRT with the latest core.

[evdberg]

Scaling cannot cut the video. So you cannot simply set the magnifier and expect it will cut the parts of video.

Hence my suggestion to lower the rendered resolution from 370x280 to 360x270 (maybe as option?).
What is the problem for the scaler to cut part of the video?

[funkheld]

Hi good afternoon.
I compiled the source code of the C64 with Quartus 18.1 last night. The quartus shows 100% done. It took 20 minutes.
But I can not find any rbf in the directory. I assume that this compilation is different and somehow Quartus has to
deal with it again. how does that work?

Thank you.
greeting

[yellperil]

If you haven't compiled a core before, have a read of the Wiki. Take note of the Trial vs Full on RBF's.

https://github.com/MiSTer-devel/Main_Mi ... -revisions

Hi good afternoon.
I compiled the source code of the C64 with Quartus 18.1 last night. The quartus shows 100% done. It took 20 minutes.
But I can not find any rbf in the directory. I assume that this compilation is different and somehow Quartus has to
deal with it again. how does that work?

Thank you.
greeting

[Sorgelig]

rbf should be in output_files folder

[evdberg]

I noticed a problem with the sprites in the right border in the demo 'One Quarter' by Fairlight.
It is at this point https://youtu.be/iI8wxyRM8Do?t=202
On the MiSTer there is a white sprite overlapping the text in the right border.

Also, MiSTer does not seem to support the T64 format?

[evdberg]

According to the manual, using JiffyDOS loading a 202 block file should take 12 seconds. However, I noticed that it takes longer, and using a stopwatch I clocked it at twice the time. Any idea what is wrong, or what I am doing wrong? I looked in the manual if there is a way to turn off the screen while loading, since display obviously takes cpu cycles, but I could not find this.

Also JiffyDOS does not seem to work correctly when the C64 is in NTSC mode. After loading a program, running it just hangs the C64.