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 first version of the newly-ported Atari ST core for Chameleon.

    http://retroramblings.net/?page_id=1705


    This is a port of the MiSTery core from the MiST platform. It doesn't yet support all features of the upstream core, so there's no support as yet for hard disk images, or for the C64 keyboard - though I do plan to add both in the near future.


    Have fun!

    Does the core use the MIDI ports of the new Docking Station? I'm not an Atari person, but when it comes to ST, MIDI pops up in my head.

    Quote from Jens

    Does the core use the MIDI ports of the new Docking Station? I'm not an Atari person, but when it comes to ST, MIDI pops up in my head.

    It does indeed - getting MIDI working was high on the list of priorities!

    Thanks Alastair, have been looking forward this core :) First impressions: Mouse doesn't seem to work with this core (Turbo Chameleon V1 in standalone mode). Keyboard shortcuts work, at least alt + cursor keys to move mouse pointer.

    Just tried with some automation-gamedisks. Joysticks connected to docking station port 1 and 2 didn't respond.

    Great work!
    tried to run an STE games but it complained about not enough memory.

    Recognized a blister. Also a for a chess game could only start the 512Kb version.

    Changed it in the settings to 1, 2,4 etc and rebooted but it still complained that I did not have 1Mb.

    Should setting the memory size work?


    (stand-alone chameleon v1 in docking)

    Changing the memory size should work, but the ROM only checks for the RAM size on a cold-boot - so a soft-reset isn't enough after changing the memory size. You have to trigger a hard-reset instead.


    To trigger a hard reset, highlight the Reset menu option, and instead of tapping Enter, hold it for a second or two, until the core resets.

    The extra memory should then be recognised.

    Both mouse and joysticks appear to be working on v2 hardware but the options for the core don't save in any way when the TC is powered off and on again. and the stx files i've got don't seem to show up in the file browser, only the st files.

    Patrick: Just curious, that does mouse work in your setup with ST-core? You seem to use TC64v1 standalone. I do too and mouse doesn't respond in my setup. It works with other c64&minimig, but not with ST.

    Quote from JJXB

    Both mouse and joysticks appear to be working on v2 hardware but the options for the core don't save in any way when the TC is powered off and on again. and the stx files i've got don't seem to show up in the file browser, only the st files.

    That's right - there's no support for saving the settings yet. I have to think about the best way to handle options saving within the confines of the compatibility framework.


    Neither .STX files nor .MSA files are supported - I don't know whether it'll be possible to support those in future, but as far as I know they're not supported by the upstream core.


    Quote from el_pasi

    Patrick: Just curious, that does mouse work in your setup with ST-core? You seem to use TC64v1 standalone. I do too and mouse doesn't respond in my setup. It works with other c64&minimig, but not with ST.

    I have some ideas for debugging this - and I have a few more PS/2 mice I can test on my V1 Chameleon - so don't worry, we'll get that working in due course. :)

    Alastair: That's good, and core is already in very good shape. Have been able to play a bunch of ST-games already :)

    There is a few programs with which it is possible to convert MSA to ST-files. I converted whole automation-collection with MSA Converter v2.1 (by Zorg). Probably there is no way to convert from STX to ST, because STX has copyprotection infos etc.

    Quote from el_pasi

    because STX has copyprotection infos etc.

    I did a quick search for Atari ST protections, because I thought that these MFM controller chips can't do much. Turns out they can, and emulation of slower and faster bit rates may be required to make certain games work.


    One tricky thing I heard about on the ST is that a sector header for a 16k-sized block was used, which of course does not fit on a track. Only about the first 11 or 12k will fit and end up in memory when reading, but it's near-impossible to write such a track with a stock ST. I'd have to look up the schematics to see if you can play with the select line while the MFM controller is in write mode...


    I found Markus Fritze's page, who wrote the copy protection of Giana Sisters for the ST. He has some nice articles about copy protection (scroll past the ROM listing - copy protections start below that).


    I happen to know a thing or two about floppy disks (Catweasel...), but I have no knowledge about the way that the MFM controller is embedded in the ST hardware environment. Still, I could assist in some simplifications, as the copy protections appear to call ROM routines fairly often; this indicates that some clever forging of register contents could do the trick for some copy protections.

    As the "latest" of the original authors of the MiSTery core, I would say STX support would be very complicated to add, not just because of the required implementation level of the FDC, but the file format itself is very hard to parse in FPGA. Even ijor, who's the (AFAIK) inventor of the .STX format didn't add it to his CAST FX core on the MiSTer, but used the simpler (however much lengthy) SCP files for 1:1 floppy emulation.

    MSA is basically the same as .ST (sector data area dump), just with a header and optional compression. The compression is not for FPGAs, it's a job for a firmware in a CPU.

    The MFM Controller chip isn't all that complicated - though probably easier emulated in a firmware of the core. Alastair happens to have implemented a tiny CPU that runs his menus. I believe it's idle while the menu isn't switched on, so it may perform that task (while waiting for the magic key?).


    I haven't looked at the floppy format itself, but if it's really too complicated, we might introduce something new that simplifies things. Since floppies are mechanical things, a timing-resolution of .5ms (arbitrary number pulled out of thin air) should do the trick. A file format that essentially holds the MFM bits, along with incremental timing information for every half a millisecond (400 bytes per rotation) should give a sufficient combination of data structure vs. firmware.


    If you leave sufficient space in RAM after every timing-segment (worst-case should be 10% faster than standard bit rate), it may even be possible to implement write-support, which I understand is required for highscore saving of a few games.

    The MFM Controller chip isn't all that complicated


    Hehe, it still took some dozens of hours of debugging all the minor requirements of the flags and behavior of the WD1772 :)

    The file format which holds the MFM stuff ("flux") is the SCP - do you know it's average size is 20-30MB? Doesn't fit into the SDRAM, and I'm not sure if streaming from the SD Card can give adequate latency for copy-protections.