FX CAST Atari ST core

[BlankVector]

Hats off, ijor

[ijor]

Portable sources for the 68000 core has been released: viewtopic.php?f=28&t=34730

[JanniG]

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.

Many thanks ijor!

Is a build with this sound fix already released?

[ijor]

Is a build with this sound fix already released?

Not yet. I'm holding the release because it fixes sound for some testers, but not for everybody. If you want to check it, please send me a PM.

[Eero Tamminen]

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.

While MIDI composing SW like Cubase and MIDI networking programs are finicky about things like that, I think plain MIDI playback could work fine. There are quite a lot of Atari games that have good music with appropriate MIDI synthesizer.

[ijor]

While MIDI composing SW like Cubase and MIDI networking programs are finicky about things like that, I think plain MIDI playback could work fine. There are quite a lot of Atari games that have good music with appropriate MIDI synthesizer.

Thank Eero, that's useful information. I would think though, that the most interesting part of using MIDI at the ST is precisely MIDI applications, and not just playing game's music. However, it is not too difficult to implement this MIDI serial bridge to the Linux side. So there is no reason to not do it. And if somebody still wants a real MIDI hardware output, then it would be possible to have a configuration switch to select this.

I might use some MIDI diagnostic tools for testing. Are you aware any that could run on Linux and say, dump the MIDI activity? You said there is Linux software to redirect the MIDI to a remote server?

[witchmaster]

While MIDI composing SW like Cubase and MIDI networking programs are finicky about things like that, I think plain MIDI playback could work fine. There are quite a lot of Atari games that have good music with appropriate MIDI synthesizer.

Thank Eero, that's useful information. I would think though, that the most interesting part of using MIDI at the ST is precisely MIDI applications, and not just playing game's music. However, it is not too difficult to implement this MIDI serial bridge to the Linux side. So there is no reason to not do it. And if somebody still wants a real MIDI hardware output, then it would be possible to have a configuration switch to select this.

I might use some MIDI diagnostic tools for testing. Are you aware any that could run on Linux and say, dump the MIDI activity? You said there is Linux software to redirect the MIDI to a remote server?

MIDI music applications might just work fine with the MIDI serial bridge. There could be timing issues with sequencer use (MIDI clock) but it should still work, seems to work fine when outputting to MT-32 for games. If it's simple to do then please do it. I'm willing to test some sequencers etc. if you do.

Would you like to monitor the MIDI activity on the Linux side of MISTer? I guess you could use some serial data monitor in that case, MIDI data is quite simple to interpret: https://www.midi.org/specifications-old ... di-message. A note on message is three bytes for example: 1001nnnn 0kkkkkkk 0vvvvvvv, where 1001 is the id for note on, nnnn is midi channel (0-15), kkkkkkk (0-127) is the note and vvvvvvv (0-127) is the velocity.

[BBond007]

I might use some MIDI diagnostic tools for testing. Are you aware any that could run on Linux and say, dump the MIDI activity? You said there is Linux software to redirect the MIDI to a remote server?

If you want to debug on the MiSTer itself, check out my MidiLink project. It has good debug output and can redirect MIDI over UDP like you asked.

https://github.com/bbond007/MiSTer_MidiLink

[Eero Tamminen]

Thank Eero, that's useful information. I would think though, that the most interesting part of using MIDI at the ST is precisely MIDI applications, and not just playing game's music. However, it is not too difficult to implement this MIDI serial bridge to the Linux side. So there is no reason to not do it. And if somebody still wants a real MIDI hardware output, then it would be possible to have a configuration switch to select this.

I think Music Mouse is one of the more fun MIDI composing software, maybe it would work with such a system as by default it's output only:
http://tamw.exxoshost.co.uk/mmouse.htm

Here's a list of Atari games supporting MIDI music output:
viewtopic.php?f=3&t=21473&start=50

Few additional ones are mentioned later in the thread. Classical music like "In the Hall of the Mountain King" [1] in "Empire" intro definitely sounds better through MIDI than YM bloobers. Same thing with jazzy melodies e.g. in Leasure Suit Larry games.

[1] https://en.wikipedia.org/wiki/In_the_Ha ... ntain_King

I might use some MIDI diagnostic tools for testing. Are you aware any that could run on Linux and say, dump the MIDI activity? You said there is Linux software to redirect the MIDI to a remote server?

You can use "socat" to forward any "file" stream to anywhere else. See "Forwarding MIDI over network" in Hatari instructions:
https://hg.tuxfamily.org/mercurialroot/ ... -linux.txt

[BBond007]

You can use "socat" to forward any "file" stream to anywhere else. See "Forwarding MIDI over network" in Hatari instructions:
https://hg.tuxfamily.org/mercurialroot/ ... -linux.txt

For socat to work (with the Amiga core) /dev/ttyS1 must set to 31250 baud. socat unfortunately does not support a "b32150" switch (just the standard speeds such as b38400, b115200, etc.). I'm guessing Hatari does not so much care about the port speed which is probably why the example makes no reference to it.

For the amiga core:
setserial -v /dev/ttyS1 spd_cust divisor 200 <-- sets speed to 31250 baud
socat -v udp4-datagram:192.168.1.52:1999 open:/dev/ttyS1,raw,nonblock,echo=0,crnl

ao486:
socat -v udp4-datagram:192.168.1.52:1999 open:/dev/ttyS1,raw,nonblock,echo=0,b38400,crnl

When you get into softsynths such as MUNT and FluidSynth running on the ARM, socat won't work - those don't take raw serial data as they expect ALSA 'snd_seq_event_t' structures which are configured differently depending if the data is note-on, note-off or (variable-length) sysex data. To encode/decode the data to and from a serial byte stream you use this API --> https://www.alsa-project.org/alsa-doc/a ... event.html

Hopefully that info is useful...

[ijor]

Hopefully that info is useful...

Very useful! Many thanks

[Eero Tamminen]

You can use "socat" to forward any "file" stream to anywhere else. See "Forwarding MIDI over network" in Hatari instructions:
https://hg.tuxfamily.org/mercurialroot/ ... -linux.txt

For socat to work (with the Amiga core) /dev/ttyS1 must set to 31250 baud. socat unfortunately does not support a "b32150" switch (just the standard speeds such as b38400, b115200, etc.). I'm guessing Hatari does not so much care about the port speed which is probably why the example makes no reference to it.

Hatari examples aren't forwarding serial output, but raw MIDI output from one (emulated) machine to another similar one, over network. So there's no serial protocol or "port speed" for such a thing, (emulated) Atari MIDI interrupts and the (emulated) Atari application doing MIDI IO register writes dictate at what speed the MIDI bytes go out (or get it). Socat & network just adds latency to it. That same data can be written to (Linux kernel) MIDI device as-is.

[ijor]

Hatari examples aren't forwarding serial output, but raw MIDI output from one (emulated) machine to another similar one, over network. So there's no serial protocol or "port speed" for such a thing, (emulated) Atari MIDI interrupts and the (emulated) Atari application doing MIDI IO register writes dictate at what speed the MIDI bytes go out (or get it). Socat & network just adds latency to it. That same data can be written to (Linux kernel) MIDI device as-is.

That approach makes sense for a software emulator. But here it would only complicates things. And you still need to transport the data from (and to) the FPGA to the Linux side one way or the other.

[pstriolo]

Hello,

Just one question :

- is the Bios file needed to boot on the normal green screen of the atari ST ? What kind, name and where to put it if necessary ?

when i start the core actually i just get a white screen instead.

Best regards.

Phil

[ijor]

- is the Bios file needed to boot on the normal green screen of the atari ST ? What kind, name and where to put it if necessary ?
when i start the core actually i just get a white screen instead.

No boot rom is needed. You probably didn't load any disk image. That is the normal behavior with no disk inserted on the drive. It takes close to a minute before it times out and the desktop appears.

Hit F12 to get the OSD menu and load any "ST" disk image. You can do that as soon as you start the core.

[JimDrew]

Is there an update to v1.0? I don't see any links to the core other than the original post you made about this project. I have a ton of SCP images to test.

[Eero Tamminen]

No boot rom is needed. You probably didn't load any disk image. That is the normal behavior with no disk inserted on the drive. It takes close to a minute before it times out and the desktop appears.

Does FX CAST have some ROM builtin? Latest EmuTOS should boot clearly faster than normal TOS with and without floppy image (although it still takes considerably longer without floppy).

[thgill]

No boot rom is needed. You probably didn't load any disk image. That is the normal behavior with no disk inserted on the drive. It takes close to a minute before it times out and the desktop appears.

Does FX CAST have some ROM builtin? Latest EmuTOS should boot clearly faster than normal TOS with and without floppy image (although it still takes considerably longer without floppy).

it has uk tos 1.0 built in AFAIK.

[comatron]

Great work on that ST core. It runs fine on HDMI and over VGA on a CRT. Any chance to get it to work on a standard PAL Scart like the C64 and Amiga Cores do? Would be great as i played the stuff on a Philips Monitor back in the Days. Would be great to hear from you. Greetings from Germany.

[ijor]

Is there an update to v1.0? I don't see any links to the core other than the original post you made about this project. I have a ton of SCP images to test.

Not yet. But I expect a new release shortly.

Does FX CAST have some ROM builtin? Latest EmuTOS should boot clearly faster than normal TOS with and without floppy image (although it still takes considerably longer without floppy).

As thgill is saying, and for maximum compatibility, currently it has Uk 1.0 builtin. In a future release you would be able to choose whatever TOS you want (and provide).

Great work on that ST core. It runs fine on HDMI and over VGA on a CRT. Any chance to get it to work on a standard PAL Scart like the C64 and Amiga Cores do? Would be great as i played the stuff on a Philips Monitor back in the Days.

Do you mean 15KHz video output? Yeah, it is in my plans. There is a problem that I don't have any such capable monitor. So it is a bit difficult to test. But not such a big deal to develop anyway.

[Shamus]

I am glad to read that you are thinking about other video out options for future releases. I would love to use my DVI monitor with the FX CAST core!

[ijor]

I moved all the posts related to the TOS version issue to a new thread: viewtopic.php?f=117&t=34830

[Gunstick]

DEMO : Closure by Sync - MiSTer FPGA - FX CAST - Atari ST

https://www.youtube.com/watch?v=LUEsgcTHlDI

Hi I notice slight sound issues, being an YM perfectionnist I notice when things are sounding off, or too perfect. One SNDH to test is You Bore.
If it sounds strange (i.e. volume changes, faint voice) then the emulation is good, LOL.

https://demozoo.org/music/111053/

You could run the dbug intro for 3 or 5 minutes, as the flanging effect changes with time.
I will do a wav from a real ST.


Also for the overscan stuff, I'm interested in the right border Really to the limit where HBL kicks in. Especially difference of ULM vs all others vs closure.

[917k]

The only issue I have had so far is that in some games the game pad will work for about 30 seconds then is no longer responsive. I have seen this in Star Raiders and Monty Python so far but I only tested a few games. Overall, nice core!

[ijor]

Hi I notice slight sound issues, being an YM perfectionnist I notice when things are sounding off, or too perfect.

Hi Gunstick. It is possible that there are some sound issues. Would need to check it.

Also for the overscan stuff, I'm interested in the right border Really to the limit where HBL kicks in. Especially difference of ULM vs all others vs closure.

Dark side of the Spoon and Parallax Distorter do run fine. I wouldn't date to release a core that fails one my top favorite demos Enchanted Lands, with the known issue at the right border, also runs fine. Or do you mean to be able to actually see more pixels at the right border?

The only issue I have had so far is that in some games the game pad will work for about 30 seconds then is no longer responsive. I have seen this in Star Raiders and Monty Python so far but I only tested a few games.

A couple of people reported something similar. I couldn't reproduce it. But seems to be related to a powering issue. You might need to use a powered usb hub. Or it might help to connect the console output to a PC. See the Terasic manual. Note that you don't need to actually use the console, just connect the cable to provide more power to the board.