#8895 closed patch
Atari Patch for adding Native MIDI and Fix Compile
| Reported by: | SF/keithscr | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Port: Atari Freemint |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
...The Good...
Removed -lsocket from configure because the latest released libc for the platform integrates that library. It was only needed for Timidity support to build when added in the first place.
Added a native midi driver for the platform which outputs MIDI to the built in MIDI ports of the machines, and at the same time disabled the SEQ driver for the platform. I think I included all of the new plugin code.
...The (Very) Bad...
Added timer manager calls for the platform with IFDEFs in 3 places in the SDL tree (screen update, event polling, and delay) because the SDLTimers for the platform do not work with the midi subsystem (or AGI/SKY engines). This addition has been tested with MIDI from SCUMM, KYRA, QUEEN, and AGOS titles and also with a playthru of Space Quest II (Perfect Score!).
Ticket imported from: #2012839. Ticket imported from: patches/1000.
Attachments (2)
Change History (13)
by , 16 years ago
| Attachment: | atari-mint-scummvm-07072008.patch added |
|---|
comment:1 by , 16 years ago
| Owner: | set to |
|---|
comment:2 by , 16 years ago
Those timer changes are indeed pretty scary. What exactly is the problem with the SDL timer code & MIDI? The Mint/Atari timers in SDL seem to be implemented using the VBL; your MIDI code uses the BIOS; where / how does it clash?
comment:3 by , 16 years ago
SDL timer code does (or did) not work with the AGI or SKY engine either on the platform. I have never encountered problems in the SCUMM code, and have only tried the SGA demo, which works, so I don't know if the timer is actually working there, or never used. SCUMM wise, have only testyed up to Sam N Max and DotT, not the newer titles.
The thought from the SDL port maintainer is that the code is too much for the timer he is using, so it fails to run at all. If I remember correctly, he believed that the code being called back probably had to be less than 8k total because of the way the interrupt works (going into Supervisor mode in the m68k CPU), also, I think the only timer testing he did was the included testtimer with SDL, which really only shows that a timer can be added or removed, not whether it actually did something, besides saying multiple timers are not supported. The only other way he could come up with to try the callback was to use another timer which was already in use for SDL's audio, so that fails as well for the moment.
PTH did not work either, and is not a real option for the target because the binary I create runs on 3 targets, FreeMiNT (Unix like multitasking), MagiC (More windows like multitasking), and TOS (Not multitasking at all, and PTH will not work here). TOS is the base OS built into the ROM of the computers. If it matters, basically a static binary is built, and links in with the libc from FreeMiNT, which then gives most of the needed Unix 'stuff' to the binary for it to operate in the other 2 environments. (I'm probably going into way too much detail here....)
I have been trying to figure out how else to do this since patch 1497254 from about 2 years ago, when the midi code was first written.
Even taking out the actual system calls (or previously using the SEQ driver), the code was never called back via SDL's timer facility. I tried it with just prints to be certain there was no interference, even though the OS, with the Open, said it should be fine to use the midi port.
What I do know is the code does make AGI games work well, and midi music is about 95% accurate. I just picked up an MT32 to test for this because my other 2 keyboards are nowhere near GM compliant.
Anyway, in my opinion, the vbl timers fail to fire, and the code I use for the midi calls (which is near the highest level on the platform, the only higher level is passing a packed string instead of byte by byte) should not affect that, since the problem existed with AGI and SKY.
Sorry about being so verbose....
comment:4 by , 16 years ago
I would recommend to do following:
Create new atari-specific backend and have it inherited from our SDL. In this new backend just override methods updateScreen(), delayMillis() and pollEvent(). Otherwise it really scarily pollutes our SDL code, and there is a big chance that it will be unintentionally broken.
as of the overloading, just something in the manner of:
bool OSystem_Atari::pollEvent(Common::Event &event) {
if (_timer != NULL)
((DefaultTimerManager *)_timer)->handler();
OSystem_SDL::pollEvent(); }
comment:5 by , 16 years ago
What Eugene suggested that sounds indeed a lot better. I am extremly reluctant, not to say unwilling, to pollute the SDL backend with more #ifdefs -- to the contrary, our goal is to get rid of as many of those as possible.
by , 16 years ago
| Attachment: | atari-mint-scummvm.patch added |
|---|
Remaining (not applied) parts of the patch
comment:6 by , 16 years ago
I partially commited this patch now: Namely the stmidi part. I left out the hackish changes to backends/platform/sdl (see the new attached patch, which contains only this remaining part of the patch). File Added: atari-mint-scummvm.patch
comment:7 by , 16 years ago
I never came back and checked, but just got the email for Max's latest comment. I apologize for not responding to the other comments (never got emails for some reason).
Anyway, cutting out the hacks sounds fine with me. The SDL port maintainer is currently looking into reemplementing how the timers work to see if he can get something going for me.
As far as making a separate backend, I am hesitant to do this because I worry it would fall behind especially if I can't find time to work on it. If I can find some time again, I might give Eugene's suggestion some testing, but that will be a few months with my current workload unfortunately.
This can be closed now, right? DO I need to do that?
Thanks
Keith
comment:8 by , 16 years ago
Hi Keith,
glad to hear from you :).
Actually, creating a separate backend may not be as bad as you fear, if done right: Since it would be a subclass of OSystem_SDL, it would automatically get any updates and enhancments the SDL backend receives. The only times at which there would be risk of bad "drift" is when one of the few functions you have to overload gets changed -- but that will happen very *very* rarely, if at all.
I left this item open deliberately, since your patch was not applied completely. But since I got feedback from you now, I will close it. Feel free to contact me and/or sev via email or IRC if you are interested in the "subclass the SDL backend" idea and need more info.
comment:9 by , 16 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → closed |
comment:10 by , 6 years ago
| Component: | → Ports |
|---|
comment:11 by , 6 years ago
| Component: | Ports → Port: Atari Freemint |
|---|
Atari patches from an svn diff