Atari ST core

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Here's a test version which should solve the menu-with-C64-keyboard problems - could you let me know if this works for you, please?

    (Make sure you download the correct version for your Chameleon - use the V1 version if your Chameleon has a breakout cable for PS/2 keyboard/mouse and power and three blue buttons. Use the V2 version if your Chameleon has three mini-DIN sockets in a row, for IEC, Mouse and Keyboard, and the buttons are black, white and red.)


    Hello,

    The C64 keyboard is very buggy in the OSD. It's impossible to use it.

  • Here's a test version which should solve the menu-with-C64-keyboard problems - could you let me know if this works for you, please?

    (Make sure you download the correct version for your Chameleon - use the V1 version if your Chameleon has a breakout cable for PS/2 keyboard/mouse and power and three blue buttons. Use the V2 version if your Chameleon has three mini-DIN sockets in a row, for IEC, Mouse and Keyboard, and the buttons are black, white and red.)

    C64 keyboard do work fine now. Navigating the menus with no issue.


    Thanks

  • Sorry for the weak bug report from the 20/03/2022 but it was easy to understand that it was unusable.


    Thanks for the fix Alastair.

    You are always so nice Jens...


    root

  • I tried this newest Atari ST core (20220325) with standalone TC64v1 and it didn't boot. There's no Atari-logo, just only graphic garbage. OSD works, so probably has something to do with SD-card initialization? Had same kind of problem with newest Turbografx-core (20220225), whose OSD just reports "SD FAILED". I reverted back to earlier cores (Mistery 20211010 and turbografx 20210627) and those work fine. Newest Minimig-core (20220225) works, didn't see SD or other problems there.

  • I tried this newest Atari ST core (20220325) with standalone TC64v1 and it didn't boot. There's no Atari-logo, just only graphic garbage. OSD works, so probably has something to do with SD-card initialization? Had same kind of problem with newest Turbografx-core (20220225), whose OSD just reports "SD FAILED". I reverted back to earlier cores (Mistery 20211010 and turbografx 20210627) and those work fine. Newest Minimig-core (20220225) works, didn't see SD or other problems there.

    Interesting - there have been some changes to SD card handling in the latest framework, but the Amstrad core has them too, that that one works for you?


    Since the OSD works in MiSTery, could you try loading a ROM manually from the menu?


    For the Turbografx core I did move the controller to a faster clock on TC64v1 because it was having trouble keeping up with CD audio (direct SD card access is a pain on TC64V1, since it has to go through the CPLD Multiplexer.) - I'll see if I can figure out what could be causing it to fail.

  • Yes, Amstrad-core works fine. And just checked, newest Mistery works if I load Rom manually from menu.

    Thank you - so it looks like the problem is related to configuration files. I will investigate... :)

    (Are your ROM files in the root of the SD card or a subdirectory?)

  • There seems to be problems with hdf-files.

    I deleted one subdirectory from hdf and that partly broke directory-structure. TOS couldn't anymore locate directories which came alphabetically later than deleted directory.

    I can delete directories from that same hdf with Hatari-emulator without problems.

    And saving to hdf-file is problematic too. Tried several Klapauzius-HD-adaptations (Arkanoid,Leatherneck etc.)

    When you get high score and return to TOS, saving high score breaks game file.

    Tried same hdf and same games with Hatari-emulator and there saving works.

    Saving to floppy image works with current core, tested briefly Leatherneck.

    Has anybody else problems with saving to hdf? I'm using one 3 gb -file.

  • Thanks for confirming turrican9 and SID-6581. I first thought that there's something wrong with my hdf.

    Just tried to copy 124k file from floppy to hdf, and that failed too. Copied file appeared only 92k in hdf. Also tried earlier cores dated 2021-10-10 and 2021-10-18, but same hdf-problem appeared.

    I recall copying little files (text documents etc.) to hdf worked when testing years ago.

    Hopefully robinsonb5 can take a look at hdf-problems.

  • Here's a beta version which should fix the hard disk image corruption problem.

    (I'm still seeing occasional ROM checksum errors on V2 hardware - no idea why yet - but if you see it, just re-loading the ROM should fix it.)


    For consistency with other cores, the config files are now accessed from a second menu page, to the right of the main menu.

  • Thanks Alastair, I just tried newest core with standalone TC64v1.

    Initializing hard disk was slower than on older ST-cores. But it did find all 6 partitions from my hdf C,D,E,F,G,H.

    Accessing directories of hdf-file now time out frequently.

    At first boot TOS can only display drawers from C-partition. When clicking D,E... TOS tries to load drawer, but after a while waiting it fails. There's no error message, busy-cursor just reverts back to usual pointer.

    Sometimes other partitions than C are slow but accessible, you can start game etc.

    OSD is very slow or doesn't start at all, while trying to access hdf.

    And just one notice: on one occassion I was able to go reach G-partition and start Leatherneck-game.

    It successfully saved highscore and didn't corrupt file. :)

  • That's very weird, since none of the changes should have impacted performance.

    This is definitely with exactly the same SD card and hard file?


    (It's normal for the OSD to be slow during hard disk activity, but if it's non-responsive for long periods then I suspect the problem's with seeking from one part of the hard file to another. I don't suppose you know what the cluster size is on your SD card's FAT filesystem? If you have Linux handy you can check by typing "dosfsck -v -n /dev/<whatever>". The smaller the cluster size the slower seeking will be.)