Reply 20 of 69, by elianda
- Rank
- l33t
Maybe some additions to the things mentioned in your blog (and my comments there):
- The GUS RAM keeps it's content on a cold boot (e.g. pushing the reset button). I noticed this when using the gus as ramdrive with gusdrive.
- Someone at pouet.net mentioned that the GUS PnP has a little bit different timing such that looping samples with long playback times could run out of sync (compared to the behavior on a GUS classic); I have not tested this, maybe this is in most cases not noticeable.
- You write in your blog Megaem uses EMS, I think correct is: It uses VCPI.
- It is worth to mention that Megaem emulation for GM/MT-32 can be loaded on top of a real hardware port (e.g. from a real SB). Then the emulation traps the access.
- Megaem creates a *.bnk file from the *.pat files according to the definition in the ini file on first run. For GM only games this could be exploited by using a custom ini that contains only instruments actually used (or even custom pats) (The bnk file is basically a 1 MB GM soundfont image for the GUS memory build from the ~6.5 MB pats)
- Cubic Player has a method to reduce sample size if the instrument samples of a tracker file does not fit within 1 MB (described in docs). This enables you to play even larger files on GUS in hardware, with a bit lower sample quality though.
- A lot of games bring their own ini files for Ultramid with instrument definitions.
- Use dynamic patch loading wherever possible
And don't forget to check out some demos.
Retronn.de - Vintage Hardware Gallery, Drivers, Guides, Videos. Now with file search
Youtube Channel
FTP Server - Driver Archive and more
DVI2PCIe alignment and 2D image quality measurement tool