Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Hifi sample player

Reply to topic Goto page 1, 2  Next
Author Message
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Hifi sample player
Post Posted: Wed May 23, 2018 9:28 am
Last edited by sverx on Tue May 29, 2018 11:18 am; edited 1 time in total
[Admin: split from http://www.smspower.org/forums/14834-OffTopicInspiringTechnicalStuff ]

48 KHz digital music player (on a Commodore 64):
https://brokenbytes.blogspot.it/2018/03/a-48khz-digital-music-player-for.html

I think we could try something similar too (possibly using a lower sample rate like 32 KHz) we might end up putting a whole CD on a (large) cart...

I can try to write the replay routines, if someone wants to tackle the encoder ;)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Wed May 23, 2018 11:17 am
I think the main thing here is the compression method, which seems a bit weird to me. Pcmenc could scale up to higher rates, but the data use is quite high.

Looking at it further, the vectorisation needs to operate on the PCM wave, then it looks up values to write at runtime. This is probably going to be quite slow on the Master System, and will lack precision in the output - but in my experience, high sampling rates can make a big difference.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Wed May 23, 2018 2:23 pm
3.58 MHz / 48 KHz =~ 74,5 cycles, which sounds like enough to read a value from ROM, access a LUT and write to PSG port. If it isn't so, we can try with some lower sampling rate - anything above 22KHz should sound pretty well IMHO.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Wed May 23, 2018 3:01 pm
I guess it could be possible. The algorithm here is:

- convert PCM to delta PCM (each sample is the delta to the previous one) with an algorithm to enhance higher frequencies
- use a clustering algorithm against each 60KB of data to reduce it to 256 sequences of 4 values (1KB), and 15KB of indices into this
- At playback, pull back four delta values, convert to PCM (non linearly) and convert to chip values (non linear)

There's scope to inline the computation between the previous four samples' outputs, but it's quite a lot of work (including a multiplication, although that may be easy to do by another lookup).

If you don't care about compression, it's easy to get high sampling rates.

The compression algorithm above will probably do terrible things to pcmenc data.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Thu May 24, 2018 8:36 am
I'm worrying that the 4-bit non linear output of the PSG would make the effort useless - wasn't there a way to output an (almost linear) 8-bit sample using the 3 channels or I'm seeing things?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Thu May 24, 2018 1:27 pm
Last edited by Maxim on Thu May 24, 2018 6:29 pm; edited 1 time in total
Yes and no. You can use a lookup table of triplets of values to use for the three channels which will let you address more levels, but this lacks some precision and suffers glitches because as you are writing the values, new intermediate states are reached which are not intermediate output levels. The alternative is to use the approach taken by pcmenc which considers the intermediate states and optimises for the minimum distortion - at which point you no longer have a PCM data stream and the above compression approach (probably) doesn’t work.

I suppose there may be some mileage in analysing the pcmenc data for potential compression opportunities - but it would have to be very fast, maybe build a 256 entry dictionary as above but reserve some bits for literals to make it lossless. Or maybe the lossy approach is acceptable?
  View user's profile Send private message Visit poster's website
  • Joined: 30 Jun 2016
  • Posts: 132
  • Location: Victoria, Australia
Reply with quote
Post Posted: Thu May 24, 2018 3:39 pm
How big are these samples?

It almost feels like the solution after some point is to just throw more ROM at the problem.
It's not elegant, but, it works.

And I'm not entirely sure I could see any Master System software being sold with streamed PCM soundtracks anyway.
Unlike the Mega Drive scene, hehe.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Thu May 24, 2018 6:22 pm
The 4MB limit of the standard mapper limits emulator compatibility, and the 1MB limit of Everdrive limits you further. 1MB is 47.5s at 44100Hz and four bits per sample.

The goal is to store way more than you would think possible for the quality. Streaming it while doing anything else on the Master System, without having audible glitches, remains a challenge.
  View user's profile Send private message Visit poster's website
  • Joined: 30 Jun 2016
  • Posts: 132
  • Location: Victoria, Australia
Reply with quote
Post Posted: Sat May 26, 2018 2:45 am
Maxim wrote
The 4MB limit of the standard mapper limits emulator compatibility, and the 1MB limit of Everdrive limits you further. 1MB is 47.5s at 44100Hz and four bits per sample.

The 1MByte model has been replaced by a 4MByte model.
Though - I suspect most owners still use the older model of Everdrive anyway.

Especially with that price for the upgrade!
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Mon May 28, 2018 8:24 am
is there some way to emulate (for instance using Audacity) how a 44.1 KHz would sound using a single PSG channel? If it was linear, I would simply set the sample to be 4 bits, but here we also have to deal with a non linear scale...
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Mon May 28, 2018 10:43 am
You can use my https://github.com/maxim-zhao/SampleToWav/ program to convert linear PCM to the SMS output scale.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Mon May 28, 2018 11:14 am
mmm... no compiled exe in the package? :|
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8145
  • Location: Paris, France
Reply with quote
Post Posted: Mon May 28, 2018 5:13 pm
sverx wrote
mmm... no compiled exe in the package? :|

There are binaries if you click the Release tab on github.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Tue May 29, 2018 7:33 am
I should really learn how to use github, shoudn't I?
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 548
  • Location: Spain
Reply with quote
Post Posted: Tue May 29, 2018 7:42 am
sverx wrote
I should really learn how to use github, shoudn't I?

:-D
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Tue May 29, 2018 8:57 am
OK, I tried the converter. I might not be very good at using it, but no matter how I 'optimize' the input, the output is too noisy. Probably using a PSG single non-linear channel output isn't a good idea :(
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Tue May 29, 2018 9:20 am
Make sure the input format is correct...

I have worked a little on increasing the sample rate for pcmenc - 64kHz seems achievable with no compression, more if we don't try as hard to keep the output rate uniform.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Tue May 29, 2018 9:26 am
Maxim wrote
Make sure the input format is correct...


I tried with an 8-bit 22050 Hz PCM - output wave is same format, but using PSG's 4-bit nonlinear resolution - noise is almost as loud as the song itself :(
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Tue May 29, 2018 9:33 pm
Here'a a pcmenc sample at 66kHz. The source sample is 96kHz 32-bit float. It sounds pretty dreadful in an emulator. It actually compresses quite well using the pcmenc RLE method, too.

I think SampleToWav isn't actually doing the conversion I thought it was - so please ignore its result. You should probably instead look at https://github.com/maxim-zhao/wav_to_psg which doesn't have any binaries - so I've attached some here.
66kHz.zip (253.19 KB)
wav_to_psg.zip (39.33 KB)

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Wed May 30, 2018 9:13 pm
Last edited by Maxim on Thu May 31, 2018 3:12 pm; edited 1 time in total
As a purely academic exercise, I have made a cycle-counted version with one output every 38 cycles, corresponding to 94kHz, using some tricks to trade space for speed. However, I can't help but think there's some truth to the theory that >44kHz is pointless - you can't hear the extra samples anyway, and they may introduce worse side effects. See https://people.xiph.org/~xiphmont/demo/neil-young.html for example.

The pcmenc data consists of triplets of nibbles - so you could maybe build 1.5 or 3 bytes codebooks and do the K-means thing with them. I have no experience with that - can anyone provide some pointers?

Edit: this looks pretty good: https://github.com/genbattle/dkm so I will probably give it a go. (Should have asked for an rvalue ref instead of a pointer, I'm showing my age.) In theory we can get 2.12 seconds of audio in 16KB this way, or 4.04 seconds if we can use 6 byte vectors. This is assuming we can make the code fit in the cycle counts.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Thu May 31, 2018 8:01 am
Maxim wrote
I can't help but think there's some truth to the theory that >44kHz is pointless


actually it isn't exactly that - it's the minimum requirement for signals up to 22KHz, which is anyway higher than the typical upper limit for the human ear (20KHz is thought the upper limit). 48KHz audio hardware is quite common nowadays, though, maybe "just because we can" (compare that to 24bpp images and the fact that we probably can't see more than 2 million different colors... I've tested 21bpp images and I can't see any difference...)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Thu May 31, 2018 12:08 pm
Higher sampling rates are analogous to colours outside the visual range, you cannot perceive the extra data. Bit depth is analogous between the two.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Fri Jun 01, 2018 12:04 am
Update: I have integrated a vector compressor into the pcmenc encoder and it seems promising - a 3:55 song compresses at 44.1kHz (mono) to ~1.7MB in about 5 minutes of CPU and 5GB of RAM. That's about 60kbps, which is pretty competitive with MP3.

Next I need to write a playback engine for it to see what effect it has on the sound quality to reduce 16KB of data to 768 bytes of lookups...
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Fri Jun 01, 2018 8:11 am
Can you generate a resulting wav to see what to expect from the SMS output without having to write the whole playback engine?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Fri Jun 01, 2018 1:01 pm
It's tricky because the playback is not at a uniform sampling rate, although it is very close. The engine is not very hard to write, I spent about 15 minutes on it so far but needs a little more.

It requires a few levels of lookup - index to vector table to PSG command table - so it gets tight with the register space, but 44kHz is actually pretty generous for time (81 cycles per sample) making it possible to get the work done with a few tricks taken from the higher sampling rate experiments. Currently it relies on having the data aligned to a 256 byte boundary, it might be good to avoid that requirement, some optimisation might make that possible.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Sun Jun 03, 2018 9:07 am
The results are in - see attached. (Apologies for always using the same song for my pcmenc tests, and also for not being bothered to make nice easy to watch YouTube videos.)

The vector compression saves a ton of data - roughly 65% compared to uncompressed - but the effect on the sound is awful. It's taking a run of 93684 samples (2.12s), chopping it into 15614 chunks (6 samples each), then reducing that to 256 representative chunks (using some fancy K-means clustering) and splicing them together again at playback. This is understandably destructive to the data.

This is vectorising runs of 3 bytes into 256 groups. These parameters directly affect the compression level and also the quality (better compression = worse quality). The C64 demo inspiring this was based on vectorising to 256 4-sample chunks, so I'm going bit beyond that. The playback loop naturally wants to consume data 6 bytes at a time, but it could be modified to work with smaller chunks by unrolling it a bit more. It may after all be a good idea to make a way to preview the effect of the compression - it's somewhat parameterised C++ to compress with different parameters, so a somewhat parameterised reconstructor may be easier to write than a buggy Z80 player each time.

Also, the C64 player is operating in scaled sample space for its clustering pass. The scaling helps avoid the loss of high frequencies which is noticeable in my experiment. The delta space probably helps make the data more amenable to clustering and thus less lossy. I'm operating in PSG attenuation space with packed bytes, which has none of these advantages and even makes it worse by being nonlinear.

One last thing: on some samples, the simplistic RLE algorithm from the original pcmenc can beat this. On others it is worse than uncompressed data.

Code is being pushed to https://github.com/maxim-zhao/pcmenc shortly.

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Mon Jun 04, 2018 9:07 am
well, not so bad at all - but not really hi-fi... I suspect the 4 bit sample resolution is just too much a limit, the output becomes really too noisy.
(voice isn't so bad anyway, I wonder how it would perform with an 'a cappella' choir...)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Mon Jun 04, 2018 7:52 pm
For voice you can drop the sampling rate too, 8kHz is phone quality. I'm not currently set up to try these on real hardware but in an emulator the quality difference seems very clear.

I'm going to try again with less compression to see what difference it makes. I'm now slightly diverted by an idea about how to make it do the first pass in less time and space, though. It could be worth a try to replicate the C64 data model - using lookups to translate 8-bit sample values to PSG writes, even with artifacts - for comparison, because maybe the data transformation has enough impact to cancel any pcmenc benefits.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Thu Jun 07, 2018 9:14 pm
So I finished up the 2-byte vector encoder and it's not really any better. Zooming in on a smooth wave, I can see that it has all sorts of nasty noisy artifacts overlaid. I'm assuming this is due to the vector compression, and that it just doesn't operate very well on this type of data. The C64 one transformed the PCM waveform in order to get a better result there, and we don't have an equivalent.

Still, it was fun to write the code and have it only just fit in the cycle count budget :)

Attached image has the vector compressed wave at the top, the original in the middle, and the uncompressed SMS version at the bottom. The top and bottom waves were created by dumping the emulated output to VGM and then rendering to WAV. It might be interesting to compare to a real system's output.
wave.png (9.03 KB)
wave.png

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Sat Jun 09, 2018 7:31 pm
Just to make sure, I added some code to dump the audio back out in C++ based on the assumption of a perfect player - as there is some aliasing between the 44010Hz output of the player (81 or 82 cycles per output) and the 44100Hz time base of the VGM format. It confirms that vector compression destroys the data :) Below is the original waveform, the uncompressed pcmenc output, and the 4-sample and 6-sample vector compressed versions. The visual difference is not huge, but the audible difference is.

Next steps may be to try making a non-pcmenc version, to compare a raw 4-bit 44kHz player and a lookup-based 8-bit player. The latter is analogous to the C64 one so the vector encoding may come back - if we can make code fast enough for it, 44kHz is 81.3 cycles per sample and it will cost 54 just to update the PSG, leaving only a few to determine the values needed...

As a bonus, I encoded one of the songs from the C64 player here, and added in a similar visual effect.
Cheap Day Return.zip (1006.33 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Mon Jun 11, 2018 8:04 am
not bad, but the background noise is really loud, and we already know the PSG volume isn't much thus the result is very lo-fi. I would love to hear the result *before* the vector compression...
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Mon Jun 11, 2018 8:50 am
That's the non-vector one :( The noise seems to be introduced by the pcmenc mapping onto the non-linear PCM output. I would like to experiment with the preprocessing done by https://github.com/maxim-zhao/wav_to_psg which aims to shift the wave into the area with higher definition. There's also a double bitrate version which may do better.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Mon Jun 18, 2018 2:24 am
Preprocessing can help make the quieter parts less noisy, but it's not a big help. ROM attached, and I made an emulated video:



Real system videos (or even just audio) would be nice to confirm it's not completely fake. Quality can be increased simply by making the audio quieter...

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Mon Jun 18, 2018 8:30 am
It's a too large file for my Master Everdrive - will it work if I just take the 1 MB (if high ROM pages doesn't contain code it should, right?)
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2013
  • Posts: 199
Reply with quote
Post Posted: Mon Jun 18, 2018 6:13 pm
just saw this on indieretronews, that was incredible! Could you do a version with Prodigy's Smack My Bitch Up, so we can compare directly with the C64 version:
  View user's profile Send private message Visit poster's website
  • Joined: 30 Mar 2009
  • Posts: 282
Reply with quote
Post Posted: Mon Jun 18, 2018 6:27 pm
Yeah, that is impressive as f..
If someone posts a everdrive compatible version, i don't mind making a video of the results.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Mon Jun 18, 2018 9:12 pm
You can truncate it at 1MB to get the first ~46 seconds on an Everdrive. Apparently they have 4MB ones now...

I'm concerned that posting copyrighted stuff will get me in trouble on YouTube, hence why I used an existing mashup above. Smack My Bitch Up is not a great comparison because the demo above is doing stuff during the samples, so they are necessarily reduced quality (and I don't intend to compete on that front), and also because it's incredibly redundant - the sample data is very much repeated in the original song :)

I thought maybe posting a YouTube video would attract some interest, but indieretronews seem to have done well to totally misunderstand all this :) this is just a graphical update to my old pcmenc demos from a few years ago, the recent work was to try to use the vector compression from the C64 demo, which is pretty much a complete failure quality wise, and to increase the sampling rate beyond usefulness. And then add pretty colours, which were an afterthought on C64 (a single memory write in a few spare samples) and a bit trickier on SMS (it takes 29 cycles and requires me to abuse a quirk of the VDP so I can reset the palette index with a single byte command).

I have variants which do lower sampling rates to fit more data into the space available, but it's a challenge to get decent quality and length in 1MB.

The colours effect can be overlaid by graphics - it's a raster palette effect - so it would be possible to "float" graphics over the lines, and even to scroll them around a bit - we have ~360000 potentially usable free cycles per second, and could find more if I applied some of the space-for-speed trades I came up with for the earlier experiments.

Edit: another one, nothing really new but I like the song :)


Knight Rider.zip (1.4 MB)

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Tue Jun 19, 2018 8:32 am
somehow it seems like this one sounds much better - did you do something special to achieve this or is it just the tune more 'suitable'?

anyway yesterday I thought about one thing... when you turn the original PCM data to PSG volumes, I think you map the higher value (say 255 in a 8-bit unsigned PCM file) to PSG attenuations [0,0,0] - right?

my concern is: given that the PSG scale is not linear low attenuation values are very apart one from the other thus making for instance 0,0,1 a bit too 'far' from 0,0,0.

My point is, shouldn't you give up a bit on max volume and map the higher PCM value to something quieter (such as 0,1,4 so to say) so that the immediately lower value maps to something closer?

I don't know how feasible for you is to try that, butI think it might make the S/N ratio a bit better, thus going closer to the hi-fi meaning :)

Finally, there's also the clipping in the real hardware to consider - once I read you wrote that attenuation values 0,1 and 2 were (almost?) the same output - we shouldn't forget that too.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Tue Jun 19, 2018 2:51 pm
My experience suggests that old clipping isn't really real - the difference is perceptible in this demo. I've patched my version of Meka to restore it :)

Due to a bug, I used to map the input sample to 0..1 and the SMS output to 0..3, so I was only using 1/3 of the range - which was much quieter but also did indeed have less noise. The big problem with samples is that they struggle to compete on loudness with square wave, so I chose to take the loudness with the noise. The pcmenc command line includes an option to scale the amplitude up or down.

The Knight Rider theme has a lot more dynamic range which means it can avoid the sparse part of the output range more of the time - you can hear the noise getting stronger when the music is louder.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Wed Jun 20, 2018 7:48 am
They sound very nice on my hardware! I had to raise the volume a bit, but not so much after all :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Wed Jun 20, 2018 8:03 am
I'm curious how the colour bars look - the pattern in Emulicious in accurate VDP mode seems to only have two colours per line, but I'd expect more as I change it every 81 cycles.

I keep meaning to encode a VGM as a sample to compare the volume. In theory it ought to sound just as loud...
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Wed Jun 20, 2018 3:06 pm
I'll check the color bars
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 496
Reply with quote
Post Posted: Wed Jun 20, 2018 11:46 pm
Maxim wrote
I'm curious how the colour bars look - the pattern in Emulicious in accurate VDP mode seems to only have two colours per line, but I'd expect more as I change it every 81 cycles

Your raster effect was rendered incorrectly in Emulicious. The update fixes this.
Sorry, I'm afraid it looks worse than you had expected. :/
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Wed Jun 20, 2018 11:49 pm
Awesome :) Any chance you can make it record videos? I'm using BizHawk for those parts, because it does the best job of that out of any emulators I've tried.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2582
Reply with quote
Post Posted: Thu Jun 21, 2018 8:10 am
I was going to say that it seemed to have more than 2 colors on the TV, but I see Calindro has already chimed in :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Thu Jun 21, 2018 8:36 am
Calindro wrote
Sorry, I'm afraid it looks worse than you had expected. :/

It looks pretty much as I'd expected - with the advantage that it seems not to show any palette noise (because it's showing the colour I'm writing at all times). I did notice that the colour bands are being ciipped to the nearest 8px boundary - I was expecting it to be more smooth.

(I don't currently have a way to connect my Master System to a TV to test it myself...)
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 326
Reply with quote
Post Posted: Fri Jun 22, 2018 5:08 am
Color me impressed. That censor demo is pretty insane, before that they used to use samples for credits sections (Wonderland 12 and COMA LIGHT 13 did this for instance) which I imagine this could work with pretty easily on SMS.

Smashed for time right now but hoping to take a closer look soon.
  View user's profile Send private message
  • Joined: 13 Jan 2018
  • Posts: 13
  • Location: London
Reply with quote
Post Posted: Mon Jul 02, 2018 6:55 pm
I'd love to convert one of my audio-based tracks for this (one that i've built to run on a stock Megadrive)

but...and sorry if i'm being really stupid...i'm not sure how to divide the generated .pcmenc format into pieces i can use context to .inc into Master System ROM banks. Am i missing something obvious?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13087
  • Location: London
Reply with quote
Post Posted: Tue Jul 03, 2018 5:35 am
WLA DX doesn't really support including binary chunks that are bigger than a bank. You can do it two ways:

1. Append the data to the ROM manually, like my test. This is not very friendly though.
2. Use incbin with the skip and read parameters to include 16KB each time

While working on my arcade voices patches I've actually written some fairly complex macros which do #2 automatically - see https://github.com/maxim-zhao/sms-hq-samples/blob/master/Common/addfile.asm (which has a bug, I need to push the fix). The actual player doesn't include code to work across banks - the "-r 16" encoding assumes you will start your data on a bank boundary and then put the subsequent data in consecutive banks, but then the player code needs to do the paging around a call to PLAY_SAMPLE for each chunk. So you may decide to use some other mechanism to deal with large data, e.g. a lookup table for each chunk (listing page, offset pairs with a terminator) and then .incbin the chunks to superfree sections and let WLA DX do the packing (which could be more space efficient sometimes).
  View user's profile Send private message Visit poster's website
  • Joined: 13 Jan 2018
  • Posts: 13
  • Location: London
Reply with quote
Post Posted: Fri Jul 06, 2018 12:22 pm
Maxim wrote
WLA DX doesn't really support including binary chunks that are bigger than a bank. You can do it two ways:

1. Append the data to the ROM manually, like my test. This is not very friendly though.
2. Use incbin with the skip and read parameters to include 16KB each time

While working on my arcade voices patches I've actually written some fairly complex macros which do #2 automatically - see https://github.com/maxim-zhao/sms-hq-samples/blob/master/Common/addfile.asm (which has a bug, I need to push the fix). The actual player doesn't include code to work across banks - the "-r 16" encoding assumes you will start your data on a bank boundary and then put the subsequent data in consecutive banks, but then the player code needs to do the paging around a call to PLAY_SAMPLE for each chunk. So you may decide to use some other mechanism to deal with large data, e.g. a lookup table for each chunk (listing page, offset pairs with a terminator) and then .incbin the chunks to superfree sections and let WLA DX do the packing (which could be more space efficient sometimes).


Thanks Maxim! I'll go back to the WLA DX documentation when i have a minute and try this out
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2  Next



Back to the top of this page

Back to SMS Power!