Jump to content

U-235 SoundEngine released!


Recommended Posts

too bad, i thought it's a Tracker... :-(


If you want a Tracker, I'd suggest Open ModPlug Tracker, it's very full featured and supports all formats from the original MOD to XM etc. my sound engine is for playing back sounds and modules on the Atari Jaguar, not much point in having a tracker on the Jag itself (that I can see anyway).

Link to comment
Share on other sites

But how will I know, which Instruments and Freq are supported by the Jag?


A tracker module contains the samples for the instruments. If you can create a valid Tracker or Pro-Tracker module, then the U-235 SE will play it (with a few outstanding effects still needing to be implemented, but those will come in time.)


For sample playback, as long as it is 8bit signed, most frequencies should be possible, not worth going much over 20kHz but you can if you want to use that much RAM

Link to comment
Share on other sites

  • 1 month later...
  • 7 months later...
  • 4 weeks later...

hi linko

tryed a little you u235SE

very nice (also padreading/randnr)


just some questions:

dsp.obj is ~30kb

how much of it you load into dsp local ram?

plus 3 buffers? did i understand correctly?

(you know im just curious :D )


is this a .mod only tracker?

(didnt find that info in pdf :-D)


nice work..

cool to have !!

keep on this way



Link to comment
Share on other sites

Glad you liked it :)


the object is 30KB because it has more than just pure code in there. As well as the code there are all the linker labels etc, to allow it to be linked into other peoples code. It also includes the 68K to setup the Mod player (sets up sample banks, tempo, etc) and a lookup table or two. The DSP code is probably around 3-4K, and the rest of it is variables and sound buffers. Once a mod is setup it runs 100% on the DSP, you can test this by starting a mod and then issuing an 'illegal' or 'stop' to the 68K, it will keep playing :D


It would be possible to write a parser for another mod format in 68K land and pass the playback instructions to the SE if you wanted to play something other than a SoundTracker/ProTracker mod. Internally this is how it works, the parser parses the mod and just creates playlists to pass to the SE internally making it nice a modular :D


I bundled it all into the one object to keep things neat and tidy, just need a few files in your own project workspace to make use of it.


You are right it does also have some buffers in the DSP RAM, there are 2 which feed the DACs, and each voice has it's own very small cache buffer.


It is primarily a Sound Engine that just plays samples, A pad reader and RNG. I have also bolted onto it a Module parser so it can parse SoundTracker/ProTracker modules. The big picture would be that this can be switched out for other formats (Octamed etc), or possibly other sound sources (I have got some very rough CD Audio playback code kicking about, and also dabbled a bit with pure synthesis of sounds). There are still plenty of tweaks to be made to the existing codebase, and I think I can possibly improve the performance of the SE itself further and reduce its impact on the system bus hopefully.

  • Like 3
Link to comment
Share on other sites

very cool... sound you on the best way to create the standard jaguar sound library ;-)


is this buffering dynamic? or more static?




mod size: 20 kb

2 x buffer size: 2 kb each, so 4 total


so you have 10 "buffer loads"


are they static?

i mean:

buffer 1 gets kb 0 to kb 2 of the mod

buffer 2 gets kb 2 to kb 4 etc, etc,...


some theory just for my curiosity?



Link to comment
Share on other sites

The buffers are static, they are only about 512bytes each IIRC (would need to go rummaging in code to confirm :) ), all they are used for is precalculating the output to feed to the DAC, once the buffer has been played it is re-computed whilst the 2nd buffer is played, and vice versa.


The cache is only 4bytes per voice, although I am looking to change how most of this works.


Unfortunately for a single pattern within a mod you need 1K of RAM, I did consider caching the pattern data, but given the low frequency that it is read and size of it made that pointless. I am also working on some alternative approaches to reduce the memory footprint of the module format, possibly leading to better caching and playback performance too.



Anyone caught using anything but mod music on the Jag should be strapped to an R-Zone and force fed items from Poundland.


Actually, I disagree :D I have always thought the Jag should be playing stuff that sounds much better than 4channel mods, after all the Amiga (*SPIT*) used 4 channel mods all the time, the Jag is so much more than an Amiga (*SPIT*) so I would like to hear it do more! (Yep I have my own ideas and plans around this :D )

  • Like 2
Link to comment
Share on other sites

Problem with compression is you have to uncompress it to use it, and you have to uncompress it somewhere. I may look into ADPCM, but that is only going to reduce the size of the source data and bus utilisation (potentially depending on LUT size) not the processed data. There are significant savings to be had by reorganizing of data structures as well as reduction in bus bandwidth and CPU utilisation

  • Like 2
Link to comment
Share on other sites

Actually, I disagree :D I have always thought the Jag should be playing stuff that sounds much better than 4channel mods, after all the Amiga (*SPIT*) used 4 channel mods all the time, the Jag is so much more than an Amiga (*SPIT*) so I would like to hear it do more! (Yep I have my own ideas and plans around this :D )


Oops. My lack of 68k computing experience is showing. I was running mods like this on my PC back in the day:

  • Like 1
Link to comment
Share on other sites

I'd certainly like to see what nice noises a Jag could produce with the involvement of a talented musician and some experimentation with synthesis stuff. If the synth sounds can be done entirely in the DSP then the impact to the bus could be very low, and we could have some nice 16bit Stereo audio coming out of our speakers. Not sure if the DSP can match the audio quality of an Ultrasound or anything with a Wave table, but it should be possible to make some really nice sounds.

  • Like 3
Link to comment
Share on other sites

yes i understand the compression problematic

now you maybe understand my previous questions :-D

the dsp speed itselfe would be enough for a simple decompress.. its just about the 8k and the task managing inside..

i am right?

8k of dsp ram and what is possible inside :D :D :D


because... as you say ... compressed data is smaller... also smaller to transfer via bus.. also smaller bus-use by the dsp

thats why i asked for the buffers and size and also dynamic or not


just an idea or vision.. didnt think very deep into the topic yet



Edited by Otto1980
Link to comment
Share on other sites

Yeah runtime decomp could possibly work, but this isn't really going to work for a file structure like a mod. Inside a mod file there are several tables of data. Sample data table, song data, pattern data and the samples themselves. When you play a mod you look in the song data to find what pattern to play, then in the pattern table you need to read each division of that pattern at the appropriate time. So the problem becomes, what do you compress? If you compress pattern data, you are possibly going to need to compress it into small chunks and then decompress those chunks when you read them in to be able to use the data. The smaller the chunk size the easier it will be and less buffer it will need in the DSP, but also the less compression benefits from that compression (depending on compression algorithm will depend on additional overheads of the process too). So compressing the song/pattern data may be too problematic to be of much use (a typical mod with a playspeed of 6 will only read 16 bytes from main RAM once every 0.12 of a second, so not a big hit)


Data like samples which are pulled from the bus constantly typically don't compress very well due to their structure, you would need to read in (most likely) more data to be able to decompress the data you need to mix the samples together.


And as you have mentioned, only 8K of RAM for use as buffer space.


There may be techniques out there I am not aware of that could benefit things (I don't claim to know everything :D ), I am certainly not aware of any, and don't think for the work required there would be significant benefit. I am more interested in pre-caching as much of a sample as possible into the DSP RAM, then feeding the SE from these caches, the SE already does this but only for 4x8bit samples per sample, which doesn't sound much but it's effectively reducing the number of bus reads for a sample by half. (DSP has a 16bit bus, each read fetching 2 8bit samples, twice, possibly some benefit from 1x 32bit read rather than 2x 16bit reads etc).

Link to comment
Share on other sites

yes.. i see we understand each other..

.mod module is already really small and the facts its a tracker (uses tracks) is already a kind of compression (only in view of size, not tech ;-)

splitting a .mod into 2k pices and compress them, compile them into the binary to have memory benefit.. i think to much work for small gain.


maybe now you understand my question about the buffers

because for decompression you must know how huge a datapart is and how decompression algorythm works

e.g. can you read kb for kb and decompress with the algorythm or does the algorythm require the whole datasection for his math.


we do not even have 8kb for buffer.. cause a SoundEngine also needs his space, right?



Link to comment
Share on other sites

Well, not really :).. If you load up a mod in an editor and look at the pattern data, one thing I have noticed is there is often a lot of empty space and repetitions. So quite a lot of the time there is wasted effort reading in instructions that are essentially the musical equivalent of a nop. If we were to remove all those holes we can save a huge (relitively speaking) amount of space, get rid of the duplicate data and save even more. And that's without compression!


If you were going to look at compressing it I would imagine you would decide on a chunk size to break the data into, say 64bytes ;) of data, then compress that. This way at least you will know that the uncompressed data will always be no more than 64bytes. My (basic) understanding of compression is around the Huffman approach and as such a kind of dictionary will be required, I suppose to remove the need to require one for each 64byte chunk you would produce one for the whole dataset, or at least a larger window to gain as much of an optimisation as possible.


there may be some merrit to compressing the pattern data, however I doubt it will be significant, or give a significant gain to performance. I will bear it in mind and if the mood takes me, I may look into it further. There are however bigger gains to be had from much less work first :D


Indeed, the 8KB already holds the actual SoundEngine code, it's variables, as well as some small buffers. It may be possible to allocate some of that for pattern data, but as I said earlier the amount of time spent reading pattern data is very minimal, and given the improvements I already have planned this would be reduced further anyway. Restructuring the mod data, working out a compression scheme and then the code needed to work with that is perhaps an interesting challenge but ultimately for small gains.

Link to comment
Share on other sites

The venerable MOD format can handle more than 4 tracks - I've seen up to 32 tracks. My own MOD player code for the 32X and SCD handles up to 8 tracks, but it's super-easy to add any number of tracks. There's also XM (extended mod) format, which handles up to 32 tracks by default. I made a player for the 32X that works great, so playing XM on the Jaguar should be doable as well. MOD and/or XM should be sufficient for most Jaguar games. When you need a really odd piece of music or sound effects, ADPCM like Tripper plays should be fine.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...