Jump to content

Xuel

+AtariAge Subscriber
  • Content Count

    790
  • Joined

  • Last visited

  • Days Won

    2

Xuel last won the day on May 7 2018

Xuel had the most liked content!

Community Reputation

844 Excellent

About Xuel

  • Rank
    Dragonstomper

Profile Information

  • Gender
    Male
  • Location
    US

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You're quite welcome. Sure, sounds fun. I've opened a new thread where people can post requests:
  2. I'm opening a thread where people can post requests for new SAP conversions. In other words, if you can't already find it in the ASMA, and you would like an SAP version of the music in a game, demo or other program, post it here and I or someone else can take a crack at converting it. Here's an example conversion:
  3. @Poison Here's one with all 9 sub-songs: sabath-subsongs.zip It's quite hacky. Hopefully it works in all SAP players.
  4. Here you go: sabath.zip I used Altirra to write out about 6 minutes of the demo to a TYPE R SAP file (Record -> Record SAP type R). Then I used dmsc's lzss code to create a 7K XEX. Then I modified lzss's code to be playable as a TYPE B SAP. Link to dmsc's lzss code:
  5. FujiConvert 0.3.3 https://lybrown.github.io/fujiconvert/ Changes Replaced "8 8 1" preset with "16 8 0" preset. "16 8 0" will produce 16 coarse levels and 8 fine levels as phaeron suggests. @CharlieChaplin It sounds like you might have a ground loop in your audio recording setup. So it's a bit hard to gauge the quality of the output with the distortion that adds. It sounds like the fine levels are working. The waveforms look OK. I don't hear much difference between "PDM16" and "PDM14" which is good. That means the fine channel is properly calibrated for each scenario. The Mfn video sound is quite nice but in addition to the ground hum, it has the 15KHz carrier which drowns out some noise you might otherwise hear. The PWM method probably has the most linear response curve out of PWM, PDM and PCM since it doesn't depend on POKEY's volume levels. It just alternates between the lowest and highest volumes at X kHz and varies the duty cycle. FujiConvert has special handling for PWM at 8kHz, 15kHz and 31kHz to sync to the scan line which should avoid jitter from RAM refresh cycles.
  6. Heh. Yeah, it's getting pretty confusing. You can just choose one of the presets. Notice that when you choose a preset it sets all of the other PDM settings automatically. For Altirra, I recommend "16 14 1". For real hardware, I don't know. Maybe "8 8 0" or "16 16 0", whichever sounds better to you. I have not personally tested any settings on real hardware unfortunately.
  7. FujiConvert 0.3.2 https://lybrown.github.io/fujiconvert/ Changes Added Coarse Levels setting Changed presets to: 16 16 0 - Full dynamic range 8 8 0 - Hardware bit 3 mitigation 16 14 1 - Good for Altirra 8 8 1 - Simulation of 8 8 0 in Altirra Ack! I realized after my last post that the bit 3 issue would affect both coarse and fine levels, so preset "8 8 0" should mitigate this at the cost of reducing the dynamic range to 6 bits instead of the original 8. I remember several years ago reading about some folks who figured out a way to play 16-bit digital sound on an old game console (I can't remember which) which didn't have a proper DAC. I think they had to deal with similar timing issues. I think they ended up doing a brute force search through all possible bit pattern transitions to find the best sequence of register writes to reproduce a given sound waveform. Maybe we could do something similar here. For example, if we know that bit 3 is slow on falling transitions, then we should write an adjusted value to bits 0-2 to account for the latency.
  8. FujiConvert 0.3.1 https://lybrown.github.io/fujiconvert/ Changes Added PDM Presets: PDM16 - Original full dynamic range method PDM8 - Hardware Bit 3 mitigation? Avoids flipping bit 3 of the fine channel PDM14+bump - Sounds good with Altirra 3.20. Eliminates pops due to volume 0 on fine channel. PDM8+bump - Maybe a way to simulate PDM8 in Altirra 3.20. Eliminates pops. Added Bump setting. Fine channel is allowed to play levels X through X+Y where X is Bump and Y is Fine Levels. I'm curious how PDM8 sounds on real hardware as it may avoid the bit 3 latency issue that phaeron describes. I really need to find time to pull my own hardware out of storage!
  9. Thanks for the report! Looks like I need to read up on Rambo. It currently works with Compy up to 1088K.
  10. I created a couple videos using my Altirra hack to illustrate a couple of my observations. The Altirra hack plots Altirra's output waveform on the screen. You can get a standing wave if you use a frequency synced to the screen refresh rate, so it's kinda like an oscilloscope. With finelevels=14, pressing E several times changes the heights of the little bumps on the rising and falling ramps of the triangle wave: With finelevels=16, changing the offset into the sample upon each initialization changes whether or not there are huge spikes in waveform and also where they occur:
  11. The "frequency" is whatever you selected. The "freq" is what the tool determined is the highest possible frequency available for the media/stereo/mono/method that you've selected which is around or less than than the "frequency". The IDE player only has two valid choices: mono 22KHz or stereo 44KHz. So the tool ignores the selected frequency in that case. The max frequency for PDM on other media types depends mainly on the speed of the bank switching mechanism for that media type: RAM: 33KHz mono or 22KHz stereo AtariMax, MegaMax, SIC!: 44KHz mono or 31KHz stereo All others: 47KHz mono or 33KHz stereo In general higher frequency (i.e. sample rate) does equate to better quality all other things being equal. But PDM might throw a wrench in that rule of thumb since the pulse density doesn't change as you ramp up the sample rate so there might be some artifacts at higher frequencies where one sample period may have a very small number of pulses to average over and adjacent sample periods will have different numbers of pulses with different spacings. Another issue is jitter. The player doesn't account for RAM refresh cycles so all frequencies other than 8KHz, 15KHz and 31KHz will have fairly random X cycle jitter depending on where the STA AUDC# instructions land within the scan line. Probably not a big deal when the CPU clock is 1.79MHz.
  12. Here's brenski's MP3 converted with FujiConvert 0.3. Notice how much less noise is in the beginning: complete moon pdm14 mono 31200Hz thecart pal.zip
  13. FujiConvert 0.3 https://github.com/lybrown/fujiconvert Changes [PDM] Replaced all occurrences of "PCM4+4" with "PDM" [PDM] Improved sound quality by restricting fine levels to values 1-14 [PDM] Changed "A" key to toggle between settings optimized for linear/non-linear mixing (black background/white background) [PDM] Improved sound quality at very low volumes by adding small DC offset so that waveforms are centered in the fine level range. This avoids pops associated with coarse level transitions. [PDM] Added option to read old .pdm files for reconversion [PWM] Fixed pops by minimizing sample rate jitter [resampling] Improved resampling performance by precomputing coefficients [resampling] Moved resampling to WebWorker threads. Stereo channels are now resampled in parallel threads [resampling] Resampling effort changed to resampling window. Old "Ultra" setting is equivalent to resampling window of 1024. New 2048 option added. [resampling] Added WAV file parser to avoid resampling done by WebAudio [resampling] Skip resampling altogether if WAV sample rate approximately equals (+/-1Hz) Constrained Setting "freq" [mixing] Added auto-gain option to set gain to largest possible value that results in no clipping [conversion] Improved audio-to-Atari-media conversion performance [The!Cart] Disable The!Cart when OPTION is pressed during power up [The!Cart] Leave IRQs and NMIs enabled in splash screen [cart] Add option to produce either .car or .raw file PDM Improvements As cool as the PDM method is, many have noticed that it suffers from a lot of noise or static in many cases, e.g. quiet parts of a song or pure tones. This vexed me so I studied the problem a bit. So far I've only focused entirely on Altirra and not on real hardware. Though @CharlieChaplin did provide me with some samples from his machine which more or less confirm what I've found with Altirra. What I found was that the waveform appears to "pop" when transitioning from volume 0 to volume 15 on the "fine level" channel, e.g. when gradually rising from coarse/fine levels 0/15 to 1/0. What I found ameliorates this problem is to simply avoid volume 0 on the fine channel. For example instead of transitioning up from coarse/fine levels 0/15, transition directly to 1/1 instead of 1/0. This means there are now only 15 fine volumes and 16 coarse volumes for a total of 240 combinations so you don't get the full 8-bits of dynamic range but rather only ~7.9-bits. So, it actually doesn't make much difference to the dynamic range but greatly reduces the noise and static. This also means that the "pulse density" on the fine channel should be calibrated to as close to 1/15 as possible instead of 1/16. This begs the question of what happens if we restrict the volume values even further, say 1-14 or 1-4. The best sounding settings I've found are 1-14 and 1-8. I created a program to explore different settings: pdm-test.xex I'd be interested to hear from folks with real hardware to see which settings work the best. Also, I made a small hack to Altirra to plot the audio waveform which helped me investigate this: 0001-plot-sound-output-buffer-in-audio-monitor.patch Altirra-plot-audio.zip There are many other interesting things I found with pdm-test.xex. Here are some settings to try in the program: pdm.txt Of particular interest to me is the difference between "16 ok" and "16 pops". The program re-initializes POKEY on every key press so the only difference between these settings is where within the sample that it begins playing after initialization. This indicates some kind of timing-dependent behavior. Also, if you just start the program, it starts out on a clear triangle wave tone using the best settings I've found for Altirra with the linear volume setting. But if you press a do-nothing key like "E" several times you'll notice that the height of the "bumps" in the waveform change every key press. Correspondingly, the amount of background noise or static changes. (I suggest wearing headphones to get the really experience the effect.) I can't figure out what's causing this since I try to re-initialize POKEY in the exact same way on every key press. Is there some hidden un-resettable state which is controlling this? Is it just an artifact of Altirra or does this happen on real hardware as well? If it could be controlled, then I think we could engineer an initialization sequence which always results in the lowest noise possible. Also, I'm interested in whether or not every real Atari responds the same way to the calibration of the fine channel pulse density. If not, I'd be sad because it makes PDM a whole lot less compelling. Oscilloscopes would be valuable here, though decently high sample rate audio recordings could do the trick as well.
  14. This datasheet says the microcontroller itself has 138 5V-tolerant GPIOs. They're probably brought directly out to the connectors on the discovery board, so I guess they should be OK. You'd want to operate them in open-drain mode since there's no 5V supply for the chip to drive onto the GPIO pins. It also says the max toggle rate on GPIOs is 48Mhz which is well beyond what would be needed to talk to the 1.79Mhz PBI bus. But 48Mhz is probably only achievable if all of the IPC (instructions per clock) of the microcontroller are dedicated to writing to the memory-mapped GPIO registers. You'll have to factor in additional instructions to achieve any meaningful functionality. For comparison, the PRUSS on the Beaglebone has a constant, exactly 1 IPC at 200Mhz, with no pipelining, so it's very good for real-time applications like this.
  15. Back in 2012, I interfaced PBI to a Beaglebone to provide a 140MB memory expansion via bank-switching. See github and my blog. The Beaglebone has a dedicated co-processor called the PRUSS which can be used to bit-bang the PBI bus. With an Rpi, you'd probably have to write a bare-metal OS which polls the GPIO pins in a tight loop if you want a full-speed interface. Arduino is already pretty much bare-metal so might be a little easier. Another limitation with both Rpi and Arduino is insufficient GPIO pins.
×
×
  • Create New...