FX CAST Atari ST core

[vanfanel]

@Ijor: This core is incredible already. Yesterday I have been testing games and demos to no avail, and everything seems to work with no problems! Viking Child, Ishar, Ween, Amberstar, Stargoose... My favorite ST classics run flawlessly and sound exactly as I remember them! Also in love with the original Pompey Pirates cracktros, which of course run perfect on the core

Would it be possible that the core "respects" the scaler settings? For example, it seems to go 720p always, no matter what is specified in MiSTer.ini. And it's not applying the "vsync_adjust" setting, with causes video hiccups every few seconds because of refresh rate differences bewteen the ST implementation and the physical video mode in use.
Also, some scanlines and aspect ratio correction would be great!

What I admire most about this core is your work on the 68K and custom chipset reverse-engineering, that will give us precise 68K implementation at last! This will be a giant step in FPGA implementation of our classic computers.

[ijor]

Would it be possible that the core "respects" the scaler settings? For example, it seems to go 720p always, no matter what is specified in MiSTer.ini. And it's not applying the "vsync_adjust" setting, with causes video hiccups every few seconds because of refresh rate differences bewteen the ST implementation and the physical video mode in use. Also, some scanlines and aspect ratio correction would be great!

I'm currently not using VIP/Sorgelig scaler, and most of the MiSTer.ini settings are ignored. This will be solved and implemented one way or the other in a future release.

You might see video tearing and artifcats if you are running 60Hz stuff, and even more games or demos on monochrome mode that runs at 70Hz. But most games and demos run at 50Hz, and video output is sync locked at 50Hz. Make sure "Video Frequency" is configured as auto though, or the core will default to output at the "safe" 60Hz frequency disregarding the ST internal refresh rate.

If you are running at 50Hz with Video Frequency in auto, and you still see video refresh artifacts, that means that your monitor is converting the refresh rate (many do). But then I would expect this will also happens if using "vsync_adjust".

[vanfanel]

If you are running at 50Hz with Video Frequency in auto, and you still see video refresh artifacts, that means that your monitor is converting the refresh rate (many do). But then I would expect this will also happens if using "vsync_adjust".

Yes, I am running at 50Hz, and Video Frequency is set to AUTO, and I see these hiccups every 10-15 seconds (does not look like tearing at all, but a hiccup in smooth-scrolling parts in cracktros, demos and fine-scrolling games).
On other cores, "vsync_adjust=1" corrects this, and everything is always smooth (no small hiccups, never).

My guessing here is that some monitors convert some video modes frequencies but not others. I suppose that if the video input is in the monitor native video mode then it's not converted (there's no need to it), and video latency will be smaller. That's why having support for MiSTer.ini video mode settings would be good, since users could have the core run on their monitor's native mode, which is usually among the ones listed on the .ini.

[Sorgelig]

I'm currently not using VIP/Sorgelig scaler, and most of the MiSTer.ini settings are ignored. This will be solved and implemented one way or the other in a future release.

May be you'll let me work on MiSTer API integration to the core while you can concentrate on ST code?

[ijor]

Yes, I am running at 50Hz, and Video Frequency is set to AUTO, and I see these hiccups every 10-15 seconds (does not look like tearing at all, but a hiccup in smooth-scrolling parts in cracktros, demos and fine-scrolling games).

My guessing here is that some monitors convert some video modes frequencies but not others. I suppose that if the video input is in the monitor native video mode then it's not converted (there's no need to it), and video latency will be smaller.

It is possible that some monitors change the refresh rate, but only when its own scaler is involved, yes.

May be you'll let me work on MiSTer API integration to the core while you can concentrate on ST code?

May be Although I did have my reasons that we can talk about in some other thread.

I do will like to say something here. The work Sorgelig did in that regard is amazing and impressive. There is a lot of stuff behind the scenes that most people, even core developers probably don't know. E.g., I had no idea you made your own adaption of the HPS TCL interface.

[breiztiger]

hi

just tested with hdmi_audio_96k=1 but no more sound on hdmi output

other core like genesis work like a charm

[JimDrew]

Ijor, I was thinking about the image size generated by SCP with it's default settings. I could actually cut the image size in half. There is an option to use any number of bits for storing the flux data. By default, the bitcells entries are stored as 16 bits (word) wide. I could make an option to create image files with the 8 bit storage option, and then use a multiplier value in a couple of the unused flag bits. SCP does a 25ns capture, but I have done some experimenting with CopyLock and some other timed protections and found that I could make 100ns bitcells and every copy-protection still seems to work. This would reduce the max bitcell value by 4, making it fit easily into an 8 bit value. So, if it's helpful I can implement the multiplier bits into the image format. I already have an option in the software for doing this (uncheck "preservation), so it's a simple change to define some extra bits. I made this option awhile ago because it dramatically reduces the image file size to less than 10% of it's actual size when using .7zip compression. STeeM and other emulators support using SCP image files in a compressed form to reduce the amount of required disk space.

[OzOnE]

@ijor - Thanks for your reply.

That's some fantastic work, particularly on the 68000, as it's obviously a very iconic and widespread CPU, especially on arcade boards.

The same MFP chip is used in the classic Mac and SGI Indy as well, IIRC? Although I could be remembering that wrong.

I've seen some of the videos of FX CAST by bbond and others, and it looks great.

I'm very glad to hear your core is written in Verilog / SystemVerilog as well. I find VHDL a bit harder to read and visualize.

I haven't yet made the change to SystemVerilog and using the "logic" keyword yet, but I guess it makes sense to.

Regards, OzOnE / ElectronAsh.

[ijor]

The same MFP chip is used in the classic Mac and SGI Indy as well, IIRC? Although I could be remembering that wrong.
I've seen some of the videos of FX CAST by bbond and others, and it looks great.
I'm very glad to hear your core is written in Verilog / SystemVerilog as well. I find VHDL a bit harder to read and visualize.
I haven't yet made the change to SystemVerilog and using the "logic" keyword yet, but I guess it makes sense to.

Yes, early MACs and SGI were based on the 68K. I'm glad you liked the videos. I like your videos a lot!

SystemVerilog is just an extension to Verilog. I'm not using the most advanced and fancy SV features. Should be easy to follow. Being a very lazy typist, I hate the verbosity of VHDL myself!

[ijor]

Ijor, I was thinking about the image size generated by SCP with it's default settings. I could actually cut the image size in half. There is an option to use any number of bits for storing the flux data. By default, the bitcells entries are stored as 16 bits (word) wide. I could make an option to create image files with the 8 bit storage option, and then use a multiplier value in a couple of the unused flag bits. SCP does a 25ns capture, but I have done some experimenting with CopyLock and some other timed protections and found that I could make 100ns bitcells and every copy-protection still seems to work. This would reduce the max bitcell value by 4, making it fit easily into an 8 bit value. So, if it's helpful I can implement the multiplier bits into the image format. I already have an option in the software for doing this (uncheck "preservation), so it's a simple change to define some extra bits. I made this option awhile ago because it dramatically reduces the image file size to less than 10% of it's actual size when using .7zip compression. STeeM and other emulators support using SCP image files in a compressed form to reduce the amount of required disk space.

There are definitely some goods ideas here. And some of this is more or less what I am doing in my core while pre processing the images. Let's open another thread and exchange some ideas.

[thgill]

I just published a video on FX CAST. Instead of gameplay, I went with demoscene productions.

https://youtu.be/0KeCrWIQVTY

[JimDrew]

There are definitely some goods ideas here. And some of this is more or less what I am doing in my core while pre processing the images. Let's open another thread and exchange some ideas.

Done! http://www.atari-forum.com/viewtopic.php?f=102&t=34598

I have also updated the .scp image file spec and have posted it on the downloads page:

http://www.cbmstuff.com/downloads.htm

[Kolchak]

Hello,

I would like to thank you Ijor for the Fx Cast core, great work, I've been waiting for a ST Core as I owned one Atari STe some time ago

[BBond007]

I didn't consider supporting MIDI so far. Using an USB device is of course, possible, but quite complicated. It would need a special driver and/or a server program on the Linux side. It would be much easier if somebody would make a MIDI extension board.

Ijor,

I have re-compiled the kernel to support USB MIDI devices and have written such a server program which I have demonstrated working with the Minimig core (http://www.atari-forum.com/viewtopic.php?f=117&t=34599)

People are asking if it will work with other cores, specifically the Atari ST and ao486.

Do you think you could include an option for the Atari ST MIDI port to map to a device (such as /dev/ttyS1) which is accessible in the MiSTer Linux?

Thanks

[yarko]

For me personally, the most expected feature is now the ability to write to a floppy disk image.

[ijor]

I just published a video on FX CAST. Instead of gameplay, I went with demoscene productions. https://youtu.be/0KeCrWIQVTY

Thank you. Great video!

Do you think you could include an option for the Atari ST MIDI port to map to a device (such as /dev/ttyS1) which is accessible in the MiSTer Linux?

I'm not a MIDI expert, but I'm not sure this is the most suitable method for the ST, I would need to look into this. The problem is that the ST, contrary to other computers, has MIDI built-in. Then most ST MIDI software expects a very specific hardware with very precise predictable timing. As long as we implement MIDI at the FPGA side, everything is exactly like the original implementation, so it should work seamlessly. Not sure how things will behave when working over a software server, timing will probably be altered.

I'm currently out of home. I'll look into this in a few days.

[matt]

Just wanted to wish congrats on this awesome work. Bravo!

[SmokeMonster]

I posted a video about FX CAST last week: https://www.youtube.com/watch?v=VQiDpjVdtb4

[funkychimp]

Hi gents,

Can someone please help me.

I have placed Atari St core on the root on my SD. I can load it and open the F12 options etc but whne I try and load a .st file nothing happens. I just get a black screen with a white border.

Do I have to place any additional bios files etc. in the SD root?

Any help would be most appreciated.

Kind regards

funkychimp

[ijor]

I have placed Atari St core on the root on my SD. I can load it and open the F12 options etc but whne I try and load a .st file nothing happens. I just get a black screen with a white border.
Do I have to place any additional bios files etc. in the SD root?

No BIOS/TOS rom files are needed for this release.

Do you have an SDRAM board, don't you? Other cores work fine?
Did you try different ST images?

[ijor]

I posted a video about FX CAST last week: https://www.youtube.com/watch?v=VQiDpjVdtb4

Thanks a lot!

[funkychimp]

Hi ijor,

Firstly, Thank you for all the hard work that has gone into this core! amazing stuff!

Yes, I am using the the low profile 1.1 SDRAM board.

I decided to unplug the SDRAM and reseat and the core has suddenly started to work. One quirk though. I have no sound using the core.

Any ideas?

Thanks

funkychimp

[cacophony]

Any update on when you think the source code is likely to be released?

[ijor]

I decided to unplug the SDRAM and reseat and the core has suddenly started to work. One quirk though. I have no sound using the core. Any ideas?

A few people reported the same problem. I need to investigate the cause.

In the meantime, some of them found the following workaround. Run a different core, make sure you get sound on your monitor. Then switch and run the ST core. That's just a temporary workaround, and I can't guarantee it will work for you.

Any update on when you think the source code is likely to be released?

I just returned from a trip and sent the source of the 68K core to a couple of developers. That source will be released to the public shortly. The source for the ST core will be released later.

[ijor]

I have no sound using the core.

I think I found and I am fixing the issue that some people had no sound. The fix would be released shortly.