vanfanel wrote: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!
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".
ijor wrote: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.
vanfanel wrote: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.
Sorgelig wrote:May be you'll let me work on MiSTer API integration to the core while you can concentrate on ST code?
OzOnE wrote: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.
JimDrew wrote: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.
ijor wrote: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.
ijor wrote: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.
thgill wrote:I just published a video on FX CAST. Instead of gameplay, I went with demoscene productions. https://youtu.be/0KeCrWIQVTY
BBond007 wrote: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?
funkychimp wrote: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?
funkychimp wrote: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?
cacophony wrote:Any update on when you think the source code is likely to be released?
funkychimp wrote:I have no sound using the core.