C64 Core

[Sorgelig]

This is not true.
You can reset with ctrl-lalt-ralt and cart will remain plugged.

[Mares]

thanx I didn't know that

[ericgus]

Anyone have a problem with the c64 core, after say loading a PRG or D64 .. then doing a CTL-ALT-ALT to reset the core (or using the reset button), the keyboard stops working correctly just resulting in gibberish, I tried a few older cores and the problem starts with the 19.02.20 version of the core (version 19,02.16 is the last most recent version that seems ok) and is also this issue seems to be in the current version of the core.. Once you reset the core the keyboard input stops working normally, .. sometimes if you ctl-alt-alt a couple times you might get the keyboard back to responding normally.. its a bit weird.. wondered if anyone notice this too?

edit: I noticed you dont even have to load a program just using the reset button or ctl-alt-alt can trigger the keyboard input problem. but running a program first then doing a reset seems to trigger it for certain.

[Noggin]

Anyone have a problem with the c64 core, after say loading a PRG or D64 .. then doing a CTL-ALT-ALT to reset the core (or using the reset button), the keyboard stops working correctly just resulting in gibberish

Yes, I have the same problem. For example, the usual jiffydos shortcut SHIFT-ESC (Run/Stop) doesn't work after a reset and instead switches between upper- and lowercase.

[ericgus]

Looks like Paradroyd figure out the issue somewhat.. seems the modifier keys get "stuck" and the core thinks the key is being held down (when its not)

seems if you try tapping either (or) both alternatively the left CTL or the left ALT a few times it will eventually restore the functionality when it gets messed up after restarting the core.. He mentioned other cores sometimes are afflicted with this issue as well (FXcast atari st core being one he mentioned).. hopefully he will post a reply and explain his findings in detail but it seems to be a bug with the keyboard handler ..

[Paradroyd]

Looks like Paradroyd figure out the issue somewhat.. seems the modifier keys get "stuck" and the core thinks the key is being held down (when its not)

seems if you try tapping either (or) both alternatively the left CTL or the left ALT a few times it will eventually restore the functionality when it gets messed up after restarting the core.. He mentioned other cores sometimes are afflicted with this issue as well (FXcast atari st core being one he mentioned).. hopefully he will post a reply and explain his findings in detail but it seems to be a bug with the keyboard handler ..

Basically, it's any modifier key that can get stuck. It could be either ALT key. Sometimes the CONTROL key or even one of the shift keys, though if it happens with one of the shift kys things will generally still work, you'll just have caps when you shouldn't. The problem seems to be that it's sometimes missing the key-up event(s) when the core resets. Tapping whichever modifier key is "stuck" will send the proper key-up event and release it.

I've really only seen this particular problem on the 64 core (though it could exist elsewhere).. The input issue I've seen on FXcast is a completely different (probably unrelated) problem.

[Sorgelig]

i will fix it.

[Paradroyd]

i will fix it.

Thanks!

[Sorgelig]

Btw, before i fix, the following way make the reset without sticky keys: press LALT+LCTRL and while holding them quickly press the RALT and release. Then release LALT and LCTRL.
I always reset this way - that's why i never encountered sticky keys. If i release LALT+LCTRL first and the release RALT then i get sticky CTRL.
I have no idea yet which part of system or core causes this problem.

[ericgus]

Btw, before i fix, the following way make the reset without sticky keys: press LALT+LCTRL and while holding them quickly press the RALT and release. Then release LALT and LCTRL.
I always reset this way - that's why i never encountered sticky keys. If i release LALT+LCTRL first and the release RALT then i get sticky CTRL.
I have no idea yet which part of system or core causes this problem.

for what its worth, I tested previous versions of the core and the problem seems to surface with the 19.02.20 version and all the ones after, so perhaps its specific to the core.

[djsquare]

I can't wait to try and load some slow .TAP files tonight! Thank you for this update Sorgelig!

[Lroby74]

I can't wait to try and load some slow .TAP files tonight! Thank you for this update Sorgelig!

Please test both sides of Flimbo's Quest tape and see if accept Side B of it, thank you

[djmartins]

I can't wait to try and load some slow .TAP files tonight! Thank you for this update Sorgelig!

Me too!
Let's hear it for Sorgelig!

[SegaMan]

I can't wait to try and load some slow .TAP files tonight! Thank you for this update Sorgelig!

Me too!
Let's hear it for Sorgelig!

Same here, thx Sorgelig!

[djsquare]

In case everyone forgot by now. Jiffy DOS will not load tapes, you'll need to use the original C64 kernel.

[NegSol]

Just to check if I am the only one - C64_20190415.rbf is not giving HDMI out.
C64_20190413.rbf works just fine. Anybody else having trouble with the latest release?

[BBond007]

Just to check if I am the only one - C64_20190415.rbf is not giving HDMI out.
C64_20190413.rbf works just fine. Anybody else having trouble with the latest release?

I'm getting HDMI video with C64_20190415.rbf on my elgato HD60pro capture card and my Samsung monitor.

After updating with the updater script I did initially have no video (also no power LED) on my older MiSTer, so I deleted the .rbf and replaced it manually and it worked after that. Maybe try that if you have not already...

The problem I have with that release (which is not present in C64_20190413.rbf) is data corruption on the USER port serial UART.

[NegSol]

Yes, I used the update script. Will try a manual write over tomorrow. I would not think the script is the problem. I will report back the result.

[NegSol]

C64_20190415.rbf works now. I had an FS problem with the SD-Card. Maybe this resulted from using an update script and ftp in parallel. So pro tip: make sure the FS on the SD-Card is consistent and be careful not to write ftp while using script.

[slingshot]

The problem I have with that release (which is not present in C64_20190413.rbf) is data corruption on the USER port serial UART.

Maybe the "Timer B bug"?

[Sorgelig]

C64_20190415.rbf works now. I had an FS problem with the SD-Card. Maybe this resulted from using an update script and ftp in parallel. So pro tip: make sure the FS on the SD-Card is consistent and be careful not to write ftp while using script.

I don't think so. Linux is pretty much multitasking system and can easily work with such conditions.
The problem is resets. If you reset too quick after writing then there is a chance not all date will be written. There is a once per 5 second force sync. So, give a time more than 5 seconds after last write before doing the reset.

[Sorgelig]

Maybe the "Timer B bug"?

it seems new flag_n behaviour.

[slingshot]

Maybe the "Timer B bug"?

it seems new flag_n behaviour.

It can be reverted, I only tested the change with tape loading.

[BBond007]

Maybe the "Timer B bug"?

it seems new flag_n behaviour.

It can be reverted, I only tested the change with tape loading.

I tried reverting this change, which did reduce occurrences of the corruption a great deal, but not completely eliminate it.

https://github.com/bbond007/C64_MiSTer/ ... 7100f07103

I have never encountered this corruption with C64_20190413.rbf.

There is some more discussion of the problem starting here -->

http://www.atari-forum.com/viewtopic.ph ... 50#p372322

[BBond007]

There is now a port of Super Mario Bros to the C=64.

It works very well on MiSTer and supports the dual SID option, although the sprites positions do seem to be a little shifted to the right compared to the background. It may be due to the game using the VSP-technique for scrolling?

https://www.lemon64.com/forum/viewtopic ... 62&start=0