VOGONS


First post, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

This is maybe not the proper topic because it's a solution to and not a problem with a specific game/app

DIGPLAY is a AIL3 sample player by RAD Game Tools which was sometimes even shipped with some games (e.g. "Zork").

In advance, i'm not sure if the problem is rooted in "digplay" and the rad sound drivers or if it is rooted in DOSBox.
I elaborated a solution but i'm not completely satisfied with it.

Status:
For DOSBox ECE (while i assume vanilla DOSBox as well but i haven't tested this recently)
If i play a sample with the SB16.DIG driver for DIGPLAY stereo is inverted (left becomes right).
Similar if i play the same sample with the SBP.DIG driver stereo is also inverted (no matter sbtype=sbpro2 or sb16).
If i play a sample using the ULTRA.DIG driver for the GUS stereo is correct (note!).

The Problem seems to be rooted in the AIL3 drivers, because i wasn't sure i made a test right now with the Miles (AIL2) evaluation software, horrible to handle they open a new shell which you have to exit manually (can't be done in a batch except you stuff the keypresses "EXIT" to the keyboard buffer) after playback but to test the function they are alright.
As far as they work at all, rel104 (.adv) stplay plays only 8bit stereo samples @22kHz, vocplay only 8bit @ 22kHz mono .VOC and digiplay plays only .RAW mono samples with the same samplerate and depth, rel105 (.dll) behaves the same the demo players can't handle 16bit samples, they all pop very loud when they initialize the SB.
HOWEVER, THE STEREO IS CORRECT

Dirty solution:
i hacked the drivers so they will playback the stereo channels proper assigned.

Test stuff:

DIGPLAY v1.02
SETSOUND (to select the appropriate driver for your "hardware" and the player)
SB16.DIG (original & hack)
SBP.DIG (original & hack)
ULTRA.DIG (no hack needed)
STEREOG.VOC ("linker kanal - rechter kanal" @11025Hz, 16bit)
STEREOE.VOC ("left channel - right channel" @11025Hz, 16bit)
PLANY (just because it's a very neat sample player with the only drawback that it can't playback in stereo)
Some more absolutely free and homebrew SFX? - perhaps.

DIGPLAY.ZIP

(The other drivers won't make much sense for DOSBox but i guess you will know where to get them from, SB.DIG makes no sense at all because it plays back only in mono and in DOSBox only on the left channel).

Yes the sample freq is low but enough for speech or sfx, they are in 16bit depth because i strongly dislike the 8bit noise.
If the file is .VOC or .WAV makes no difference both behave the same.
(besides if you use SBP.DIG with the sbtype set to sb16 it will play all samples as they would be in 8bit depth but it has no effect on stereo l/r , make sure to use the right driver for your virtual hardware if you like to play back 16bit samples)

Whatever the reason might be this hack will solve it at least temporary but only for the use of this specific AIL3 drivers, if they are used by a game they will produce an inverted stereo field except you exchange the games sfx drivers with my hacked ones (mostly hard to recognize only such a test sample will clearly differ left from right channel, if it's a human voice or a sfx you can't tell that so easy).

Proper i guess would be a feature request to swap the SB channels, but for my personal use to play tiny samples in my batch proggies this solution is good enough.
Perhaps my demo stereo samples give the kick in the right direction (you can test with them any virtual soundcard when you use the appropriate *.DIG drivers), because it's really hard to tell what is left or right from a a sfx sample.

Thoughts:
Most sample players leak of something, until i used "PLANY" (play any) but it fails to play stereo samples (plays them in mono), GUS' Playfile is tard because it can only play as much as space is left for samples in the GUS ram and that's quite little - not enough to let the machine say "hello i'm your friendly machine" (depending on stereo, samplerate and bit depth of course) in fact not enough for "left channel - right channel" @11025Hz 8bit it ends playing at half of the sentence. Also GUS Playfile is limited to stereo @ 22050Hz and of course to the virtual (or real) GUS.

Most sample player enter with a audible "CLICK" and end with the same "CLICK" noise (sample start and sample end), DIGPLAY solves it quite fine with a given offset.
That means DIGPLAY WILL cut your samples a little bit (i experienced it cuts off at least a tenth of a second from the end of the sample, while the finest degree you can fit your sample to this offset is 1/100 second).
"PLANY" solves this very elegant, it doesn't clicks and doesn't cuts off it rather blends in/out, unfortunately PLANY plays back only in mono.
The player(s) i obtained with the AIL2 source are only demos and are not useful in batch programs (it would be needed to build a useful one from the source).
Any sample player i found so far is less good as PLANY and/or will only play 8bit mono or leak of something else.
PLANY is else the most versatile player, it plays back .WAV, .VOC, .SND, Amiga .IFF/8SVX and .AU samples.
As feature you can make standalone executables from your sample (with will boost the sample size by the size of the player program).

Sample players from which i've read that they only playback 8bit samples i didn't tested, there would be a couple of TSR programs but they are all limited to 8bit mono.

I also tested the SBPRO stuff but all of the SBPRO players are unsuitable in DOSBox, mostly because they work only with one specific sb variable, once installed the drivers work only for one specific hardware (resp. with a specific blaster setting). Else They would be the best .VOC players which can even reduce the noise of 8bit samples.
Overall the SBPRO stuff works only with sbtype=sbpro2 so they are already because of this limitation unsuitable.

DIGPLAY has the advantage to play multiple files simultaneously .
DIGPLAY is simple to handle but accepts no commandline switches, it only accepts one argument; "path to file" (multiple files) .
There is no way to specify samplerate or anything else, it also can only playback .VOC or .WAV files (since a headerless sample would need a spec. for samplerate & depth at least).
It can't play any compressed .WAV (like most sample players).

Unfortuantely it seems the SB16 driver enters with a silent "click" while the SBPRO driver doesn't, else the SB16 is to prefere because the SBPRO driver won't work proper with
sbtype=sb16, on the other hand the SB16 driver won't work at all with sbtype=sbpro2 (or less).
Running the SBPRO driver with sbtype=sb16 will cause the player to playback all samples in 8bit depth.
Therefore the ULTRA.DIG driver will always play proper stereo and with 16bit depth (if the file is 16bit).

KEEP IN MIND THIS IS A DIRTY HACK
The hacked drivers won't work with SOUNDSET (it seems it notices the hack) use the original drivers to run SOUNDSET or in the preferred way copy the needed .INI to DIG.INI with a small batch like this:

@ECHO OFF
COPY C:\SB16.INI C:\DIG.INI >NUL
MIXER SB %2 /NOSHOW
C:\DIGPLAY %1.VOC %1.WAV %1 >NUL
MIXER %SETMIXER%
ECHO ON

It copies the "sb16.ini" to "dig.ini" for the player, accepts two variables "path" (%1) and "volume" (%2)
"%SETMIXER%" is a full mixer string i set as global so you can recall at anytime your initial setting (i.e. SET SETMIXER=SB 100 FM 140 GUS 160 /NOSHOW).
Of course if you always and only use the SB16 driver you won't need such and can leave "SB16.INI" as DIG.INI .
It is no problem to have the argument three times present since DIGPLAY only accepts "path\filename" as valid argument, to playback multiple files simultaneous you have to put the string in quotes that it becomes a single argument, and it does play them simultaneous - expect a cacophony.
(this is needed for the advanced use in games, AIL3 XMI and DIG player can both play files simultaneous)
Redirecting to NUL will swallow all warnings caused by the multiple use of the argument "%1", no matter it has to work in any case (or specify only %1 without suffix, this was a last minute edit i did caused by heavy use in the shell to test out the drivers function).
E.g.

CALL DIGIPLAY C:\VOC\STEREOG 50

Will play STEREOG.VOC with a SB volume of 50% and reset the mixer to your initial setting after playback.
(i named the batch simply "DIGIPLAY.BAT" one could make various such batch files for each driver you use, i.e. "DIGIGUS.BAT" or "DIGIPRO.BAT" if needed at all)

Sort of a solution and a feature request because the use of the hacked drivers isn't fully satisfying a soft solution would be better.
But as long as we can't swap stereo for the SB this will solve the problem, like i said it should be possible to use the hacked drivers for the games which use the AIL3 drivers,
but there is no warranty that they will work this i haven't tested yet at all because my main purpose is to use them for batch programs to start the games.

I hope you don't mind if i link a clip of such a batch proggy (wip):
Commander Keen Thingy

Attachments

  • Filename
    DIGPLAY.zip
    File size
    608.67 KiB
    Downloads
    17 downloads
    File license
    Fair use/fair dealing exception

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/

Reply 2 of 12, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

Which was to expect 😀

However that is fine now i can test if my hack is proper because i'm not sure, the SB16.DIG gave me some headache before i found out how to reverse stereo without to swap signed / unsigned. The SBPRO was quite easy and it was very obvious where to swap the channels and it worked out immediately.
But after i recognized that i had to do it different for the SB16 i'm not sure anymore because i assume it should be done in exactly the same manner but i can err.

My fault that i didn't searched for a solution but i didn't expect such brutal hacks here.

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/

Reply 3 of 12, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

ripsaw8080,
Do you got an idea why the SB16 driver (or the player when on a sb16 board) opens with an audible click only on the left channel while the SBPRO won't do that?
And maybe one how to fix that?
It's annoying, it's the only strong drawback of DIGPLAY for my use, it is horrible if every little sfx i use in such a batch like shown in my previous post starts with such a click noise.

Also about the offset of DIGPLAY i'm not very happy, i accept it but it's somehow tard because it's DIGPLAY specific and the samples are by roundabout tenth of a second to long for other players which leads to noise at the silent end of the sample if it's an 8bit sample, which results in that the sfx samples are DIGPLAY specific.
Also this leads to the fact that DIGPLAY can't play a sample shorter as roundabout two tenths of a second, respectively if it's shorter it won't play anything because of the offset.
I.e. a recorded "Go!" is shorter as two tenths of a second if you don't add ~15 1/100 to it won't play back "go".

The worst thing i can imagine is to use a different player such as "PLANY" and to playback only mono samples, nah not the worst but it would be sad.
On the other hand a TSR (plany isn't) could be handy because the batch will proceed while the sfx is played, it's obvious every such TSR plays back only mono, 11kHz, 8bit samples to preserve memory.
Overall using a TSR should be prevented if not really needed even if we don't have to care for DOSBox as much as for a real DOS machine.
Already use of the GUS "Playmidi" as TSR can be problematic, how to terminate the TSR in a batch? there is no "-q(uit)" switch to terminate the TSR and they chose a stupid
key press which can't be virtualized, "left shift + right shift" to terminate the TSR.
I have to use a program to mark the TSR and then release it from memory if i need this i.e. to playback a midi while a GIF animation is running but the music has to end with the animation no matter if it ends naturally or if you quit the anim with a key press.
This brutal termination leads to a still open GUS port which plays the last note endless until you silent this with another call of "playmidi" by playing back an empty midi or a sysex.mid (in my case, i have them ready for several purposes mainly to program the MT-32 to GM).

Due to small differences some TSR produce wrong results in DOSBox, i.e. for FE2 exists a "FFE blacksky" TSR

unwichtig

Usually it is listed as TSR for FFE but this won't make sense in FFE you can set the sky color from blue to black in four degrees, this TSR is meant for FE2 only here it will turn the dark blue sky to black, i assume no one who offers it online has ever used it else they would know that it is for FE2 and not for FFE, no no i told them several times but you know how that is "this nube? ... nah nah nah". Further i'm widely known for confusion and messing up things - DOSBox SB implementation isn't the only one with swapped channels, mine are swapped sometimes too 😉

This TSR often fails while playing and it became useless in DOSBox (my last real doze was a siemens laptop there it worked proper).

note to myself

The offset is most probably in samples and not in milliseconds.
Just 30 seconds on the throne will give you the right idea!
The audible click when i play back a 16bit sample is caused by the offset which is bound to samplerate and bit depth.
I assume for 16 bit @11kHz it is to short and this will leave the initial click audible on the left channel, i assume if i take a 16bit 41kHz sample both channels will produce this click,
because then is the offset far to short if counted on samples.
On the other hand if the offset is longer it will cut off to much of the beginning of a 11kHz sample.
(it needs a hack and it needs a special hack for each samplerate - tard)
Well if i haven't cared for RISP (the open source BARIS) and the miserable sound quality at 11kHz mono for such a revamp i wouldn't know this sample stuff so well.
they chose a stupid way to loop the music, the loop is bound to samples in POT, if you like to loop them seamless they need to have the exact amount of samples,
why they couldn't (won't) loop the .ogg in a simple manner is a riddle to me, no matter the short header and buffer size the snippets loop as well or even better in any player as in RISP even when the duration matches exactly POT samples.
Why they limited the music to mono 11kHz isn't to understand at all (but bound to this stupid system of "loop at POT samples" hacking this to boost it to 22kHz makes no sense since it shifts the POT to much up, the duration has then to match stupid high values, i started this but this behave and the clips in an ogg container make the attempt useless because no problem for the sfx but how to create new avi in an ogg container? Nah overall even if possible it makes no sense) and makes RISP totally useless compared to BARIS played in DOSBox, except for the possibility in RISP to influence the simulation but this never weights up the miserable sound quality, and they recorded the midi with the thin MSWS - horrible for the else fine compositions of BARIS, a rape to be true.
I counteracted to this by recording the "Tandy" resp. PC speaker version of BARIS (yes this game has dedicated pc speaker music, quite interesting to hear a "complete orchestra" on the PC speaker) for RISP, this will suit to 11kHz mono music.
Not bad at all 😉
All tracks have the exact duration of POT samples plus one sample as buffer for the loop itself.
I just have to offer this to the dev team of RISP "here is the fitting music for RISP!" (beep scratch beep).

Last edited by Gernot66 on 2020-02-16, 13:17. Edited 1 time in total.

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/

Reply 4 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
Gernot66 wrote on 2020-02-16, 12:01:

Do you got an idea why the SB16 driver (or the player when on a sb16 board) opens with an audible click only on the left channel while the SBPRO won't do that?
And maybe one how to fix that?

My fix program didn't bother with the click/pop because it only happens when the SB16.DIG driver is initialized, and in the typical game that only happens once at startup, but I can see how it'd get annoying in your use case.

The way I fixed the swapped channels is to change the initialization transfer to use 2 samples instead of 1 -- it is a stereo transfer, after all, and the odd transfer size is what triggers the swap. Using my 2-sample approach, the pop can be eliminated by changing the samples used in the initialization transfer. For example, you'll find code like this in SB16.DIG, though the addresses may vary between different versions of the driver:

MOV [05BD],80
MOV [05BE],80
MOV [05BF],80
MOV [05C0],80

Those would be good signed samples for "center" *IF* the transfer was 8-bit. However, it's a 16-bit transfer, and center is 0x8000 not 0x8080. So, the pop is eliminated by changing to this:

MOV [05BD],00
MOV [05BE],80
MOV [05BF],00
MOV [05C0],80

Well, I can say it works in my use case, which is games, but I haven't tried it in your use case. 😉

Reply 5 of 12, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

hey thanks ripsaw for the prompt reply.

Yes they do differ a bit, this i can tell from far.
the SB16 driver i hacked looks like this:

MOV [0479],80
MOV [0487],00
MOV [0495],00
MOV [04A3],00

by looking at you suggestion i can see now why it appears only on the left channel.
I was suspecting something is wrong because the value won't repeat and a single difference out of four makes no sense it has to be a pair.
Strange-wisely this driver should be the latest release of the AIL3 drivers (should).
It isn't hacked, the first version of DIGPLAY i downloaded from an open source project for a revamp of an old dos game.
But i have also downloaded once a pack of drivers plus the two players from a different source in which different versions of the AIL3 drivers are present and this is marked as "newest". Both drivers are identical, but of course many games use them and of course the releases will differ.
If i get this right one can take the "default" drivers which was done mostly or build specific ones from the source (at least this was the case for john miles ail2).
What caused the small difference and what the initial purpose was if it's not just an error i don't know.
Because even the value at the address before (sorry after) isn't the same for all four even here the first differs from the rest.

00 00 00 11 2B 22 56 44 AC 80 00 00 40 00 00 00 
00 11 2B 22 56 44 AC 00 02 00 40 01 00 00 00 11
2B 22 56 44 AC 00 02 00 40 00 00 00 00 11 2B 22
56 44 AC 00 02 00 40 01 00 00 00 00 00 00 00 00

However, thx again for your work because with this at hand i should be able to solve the tiny problems i have.

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/

Reply 6 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
Gernot66 wrote on 2020-02-16, 13:59:
[…]
Show full quote
MOV [0479],80
MOV [0487],00
MOV [0495],00
MOV [04A3],00

That looks even worse than original for 16-byte samples, because it's 0x0080 not 0x8000. Remember that PCs are little-endian for most things. 😀

Edit: oh, those addresses aren't sequential, so I'm not even sure what I'm looking at. 😒

Reply 7 of 12, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

(caugh) your patch didn't warns if the driver has different addressing?
If i patch this specific version of the SB16 driver nothing happens except that the date of last change is updated, the driver itself stays unaltered.
No problem so far i just liked to compare them i still can do this with a different release.
So far to your request for different releases of the driver this seems to be one.

triple caugh 😀
Dunno but if apply your patch to the driver which was shipped with "Albion" it alters a single value at a complete different address.
It does the trick no question using this patched driver stereo is proper l/r.
Probably i misunderstood something because i assumed the patch alters the stereo similar as i hacked it.
That it is probably not the best way or can cause troubles i expected.
"There is more then one street which leads to rome" (of course and we are on the broadest way to decadence)

Like i stated my first hack was on the SBPRO driver, here i found solution very quick based on this i altered the SB16 driver.

I guess it's safer to use your patch as my hack.

an update will follow soon, just for those who like to use DIGPLAY as standalone sample player.


To your last post; well, i'm not responsible for this 😀
This specific version of the SB16 driver is to find i.e. in "zork" (which i downloaded only for a comparison because i noticed it includes not only the drivers but also the player)
But i assume in other games of the same period to.
Part of the "miles sounddriver" pack i downloaded and marked as "newest", even part of the named open source project. ("A Tool to Help the Creation of Warcraft III Map")

I'm not sure (as usual) but something is very obvious, the version i found in "Albion" (patch able) leaks of the "RAD Game Tools ..." string there is only gibberish to read, while the "unusual" (patch unable) version includes the copyright string. It won't tell much except that the version leaking of the copyright string was probably shipped with RAD Game Tools (RAD won't have to state the copyright holder) while the ones including the copyright string are compiled from source (anyone who compiles it from source has to state the copyright holder in any case).

Most probably it's vice versa? it seems the ones i downloaded are the original MSS release 6.1A, looks like - still the drivers could be re-compiled.

Since you "aren't sure what you are looking at" the rel6.1A driver for a comparison:

Attachments

  • Filename
    SB16.DIG.7z
    File size
    3.6 KiB
    Downloads
    6 downloads
    File license
    Fair use/fair dealing exception
Last edited by Gernot66 on 2020-02-16, 15:45. Edited 1 time in total.

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/

Reply 8 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
Gernot66 wrote on 2020-02-16, 15:19:

(caugh) your patch didn't warns if the driver has different addressing?

It looks for a specific code sequence, and it changes nothing and displays "File unrecognized" if the sequence is not found. The addresses we're discussing here have no bearing on how the program works because, as I mentioned before, it does not try to do anything about the samples used for the initialization transfer.

If you do have a version of SB16.DIG which is not recognized by the patch program then I would be interested in taking a look at it.

Reply 9 of 12, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

Check my last post i attached this specific driver.

I'm a bit slow in posting (i have to read my posts three times).
Perhaps, but only perhaps this was a change for win98?
Because what "actboy168" offers for his project is mostly win related and the DOS drivers and binaries are just present because they are part of mss rel6.1a.
On the other hand it isn't an uncommon version, i guess i will find it in a couple of games on my machine.

Besides like i stated your patch recognizes the driver and didn't warns but didn't does anything to it thus the stereo is still swapped.
I assume if i alter the value similar as your patch does for the "working" version it will do the trick.

However you can check this out for yourself where the devil resides in this driver.
I'm by myself will avoid it and use the patched one, this will be the safest way.

Last edited by Gernot66 on 2020-02-16, 16:08. Edited 1 time in total.

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/

Reply 10 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
Gernot66 wrote on 2020-02-16, 13:59:
the SB16 driver i hacked looks like this: […]
Show full quote

the SB16 driver i hacked looks like this:

MOV [0479],80
MOV [0487],00
MOV [0495],00
MOV [04A3],00

Eh, those instructions don't exist in either of the driver files in your attachment. However, the MOV instructions that put 4 0x80 bytes into sequential memory as samples DO exist in both driver files, so you appear to be looking at something entirely different. In any case, my patch program does work with both of those drivers.

Reply 11 of 12, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

pause

for a while i'm off line again, i have no own web access thus i'm always off for a couple of days.
Just if you guess why i won't reply anymore - next week.

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/

Reply 12 of 12, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

ripsaw8080 thx nonetheless, i didn't managed it to get rid of the pop thus i decided to use "plany" and 8bit mono samples.
It's designed for this purpose, less stressing, works with any blaster setting, doesn't hinders the batch, is more flexible, allows to control replay frequency which is i nice thing if you randomize it.
The only thing it perhaps leaks of is a return of an errorlevel this is always handy in a batch, but no sample player so far has this and for the MIDI players i found only "MegaMID" returns an errorlevel, nor that i see a use for this for a sample player, but the use i will find if i have it.
Perhaps due to my decision for 11kHz 8bit mono i will use even one of the TSR programs i found, but i haven't yet tried one of them, i avoid them if possible.
Because once you started to use them you will probably use this and that to and i think that isn't a good thing.
It's enough that a keyboard stuffer lurks around and that i use sometimes the TSR option of the GUS Playmidi if i like to run an animation and music together.
I don't have to tell you that it could be problematic.
If nothing else is a problem it's still problematic to terminate one if you loaded another one.

-8jy3887B3CMujiSZc4_MQpGeCKNa3ggWMk4QUXwfyNKnFcgvX5uK7117CpWyK3RBl1tYrsQxCYPOos807JMtfzeJuiBd8bLjhok9h36du0WMc37vtMLZI0e4YPOl3mji09iT2vquKK8hQEIneBIjet6k_93BZG1ul9QR-Xf1h3cSDUq6ee1u-WLpqfTDpXLb1PInn0XfNfnihVLqlTuWiwO1EYwMot3ICJzu_71x8027cVcIZLcKRssP-7ZrooZ2qgJa2NlhL0ijKVCi3A9nFUAYrvrDI3fwBJC0ieQqW3KyA-XhyH9n3kG6NvYcDdsPH-53N58Rwcr4i8UExJJz5fbt-NJvO2h5lIy911iPoDCL2hqEqH7Fo7SwtzTN6-ivToBwV2A5x0ntezThKxzpdv03wSzpJ3Ji2aRd52VLBPDpeZi1-GTCHX6p_vF1hnRa85LTwklu0l9GRqNs8VecQitxeKLq_tp1OvX41WujubpsBKn4ZVoGfVVeko2U9hxnj4T9Z-gZ5C0CmeBayzaML3biBs3sDS1nm1wNDsR6pOVhsWqn_Booc_BK2YuGEsW7Lusttx6pBo7ByMLtYXbisLvVOwyDVixtqCM6SjoMwzxDHbcrh2O-40X_PECdS4Rkvct3qTIKJO34FRZZEyquwcB_X7sdKMTU_2D1Sts-USmAJZZZSlT-A=w477-h652-no

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/