Xuel
-
Posts
849 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Xuel
-
-
Another trampoline option is to push the target address minus one on the stack and then RTS.
Upside is it only takes stack RAM. Can also be smaller code-wise.
Downside is that your function pointers all need to be one less then the target address since RTS sets PC to the address on the stack, then adds one. Also a little slower.
See also:
https://wiki.nesdev.com/w/index.php/RTS_Trick
-
On 2/12/2020 at 10:59 AM, matosimi said:
Could you add it all to ASMADB? or it would be easier for you if I send you zip with all the modules?
Good question. My main purpose of this thread was to provide a central place for people to congregate to do the conversions but the obvious next step would be to request their addition to the ASMADB. The ASMA has instructions for sending in new contributions:
http://asma.scene.pl/ASMA/browser/trunk/asma/Docs/Contribute.txt
I believe the email address to send them to is asma@scene.pl
I just noticed that I'm listed as a contributor in the ASMA:
http://asma.scene.pl/ASMA/browser/trunk/asma/Docs/Asma.txt
I don't remember explicitly doing this but maybe someone uploaded one of my conversions at one point. Cool.
In any case, you might be better positioned to submit your own tunes since you know all of the relevant meta information. If you need help converting them to SAP, feel free to send them to me. PM is fine.
-
On 2/7/2020 at 2:33 PM, Poison said:
Great! Thank you
I wrote a small program, cmcdecode.pl, to search for CMC tunes in a memory dump and then write them out to separate files. There are seven tunes which are in memory during game play in Jurassic Park II. I've also included cmcdecode.pl:
If you want to try cmcdecode, just load up a program in Altirra which is playing a CMC tune, drop into the debugger and type ".writemem dump.mem 0 L10000". Then run the script as:
cmcdecode.pl dump.mem -out jp2
It will print something like this if it finds the CMC tunes:
INFO: Writing jp231A0.cmc INFO: Writing jp23944.cmc INFO: Writing jp24C00.cmc INFO: Writing jp25300.cmc INFO: Writing jp28650.cmc INFO: Writing jp28DF0.cmc INFO: Writing jp292A0.cmc
You can then load these in Chaos Music Composer as normal. The script also supports -reloc XXXX to set the tune address. It defaults to 8400. You can also use -report instead of -out to get a text dump of the tunes.
-
2
-
1
-
-
22 hours ago, Poison said:
I would like to ask for music press key 0 (zero key) from game. It is in CMC composer. And if is possible to create cmc and sap files, please.
Here are SAP and XEX:
Will see about CMC.
-
2
-
-
13 hours ago, tane said:
Thank you for your comprehensive explanation. Not an expert disassembling, I tried with DIS6502, but it doesn't show segments to the SAP attached.
You have to remove the SAP header in order for dis6502 to recognize it as an object file. I've done that for you here:
BM-stripped.obx is just the object file part of the SAP. I also included BM.asm which is the disassembly that dis produced from the SAP file.
Cheers,
Lyren
-
1
-
-
2 minutes ago, tane said:
Is there a way to convert a SAP to RTM in order to use them in asm codes?
For the most part, the SAP format is just a container for a standard Atari object file. Thus, you can strip off the SAP header and directly include it in your own code if you can place your own code such that it doesn't collide with the SAP code and data. You can use a tool like xex-filter, ataricom to get info about the segments in a SAP file with the header removed. Or you can use my disassembler, dis to examine the segments in a SAP file directly.
If the music in the SAP file happens to have originated as an RMT file, and was converted by ASAP, RMT itself, or another standard tool, then you could theoretically extract the RMT data, throwing out the RMT player code, to reconstruct the RMT file. I don't know of an automated way to do this.
SAP also supports a few other types of content which are not self-contained object files, e.g. TYPE-R which is just a sequence of register values for the POKEY registers. If you have a TYPE-R SAP you can convert it to executable code with dmsc's lzss-sap tool.
-
3
-
-
This is a really nice piece of software! I'm glad it was ported from the C64.
I got it working. You have to give it OS ROMs. Press F9 to get into the Emulation config. Also, you have to change it from the default of an Atari 400 with 16KB of RAM to get most things running. Press Control-Y to enable keyboard joystick with arrow keys and right Alt key as fire.
I think it's already shown me a sort-of bug in Bomber that I never knew existed. It shows a strange memory reading pattern that seems to span the entire address space. Pretty cool.
-
5 hours ago, lotek_style said:
Xuel: Thank you
Interested in doing more SAP conversions?
You're quite welcome. Sure, sounds fun. I've opened a new thread where people can post requests:
-
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:
-
4
-
-
@Poison Here's one with all 9 sub-songs:
It's quite hacky. Hopefully it works in all SAP players.
-
3
-
-
Here you go:
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:
-
2
-
-
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.
-
2 minutes ago, CharlieChaplin said:
Hmmm,
I now have one problem though: So many choices! I am sorry, but stupid as I am, I do not know what all of the configurations and selections mean, e.g.: Preset (4 selections), DC Offset (16 selections), Coarse Levels (16 selections), Fine Levels (16 selections), Bump (4 selections), Non-Linear Pulse (no clue what can be input there), Linear Pulse (again, no cue what can be input there). So all in all we have 4 x 16 x 16 x 16 x4 x X x Y available selections. I do not want to test all possibilities (more than 65,535) to get a good result, so can you suggest some selections for a good PDM result ?!?
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.
-
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.
-
4
-
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!
-
5
-
Added PDM Presets:
-
On 11/26/2019 at 3:56 PM, fox said:
Something's wrong with the RAM option. I convert a ~40 second MP3 changing just the frequency to 15kHz.
The!Cart plays fine, but RAM XEX is trimmed (just the beginning of the audio plays) and with high noises.
I'm testing on Altirra 3.20 XE PAL 320K Rambo and both files are ~230KB.Thanks for the report! Looks like I need to read up on Rambo. It currently works with Compy up to 1088K.
-
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:
-
1
-
-
6 hours ago, Mathy said:
- Why is "freq" and "frequency" different when choosing "The!Cart"?
- Why is the frequency lower when choosing the IDE player when compared to The!Cart? And does that mean the quality of the sound is better when using The!Cart?
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.
-
1
-
Here's brenski's MP3 converted with FujiConvert 0.3. Notice how much less noise is in the beginning:
-
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
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.
-
7
-
2
-
1 hour ago, E474 said:
I think for price and flexibility my best bet is ordering one of the STM32F4 discovery boards - I've seen various boards, such as https://www.aliexpress.com/item/33013274704.html - does anyone know if this board would be able to handle the 5v (TTL?) on the 8-bit bus?
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.
-
1
-
-
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.
-
5
-
-
3 minutes ago, Keatah said:
That happens in NTSC mode. Try PAL.
-
1
-
-
I found a crash in Altirra 3.90-test7 while testing heartlight. Repro:
- Configure System -> Devices -> VBXE -> Settings -> "Use VBXE for PORTB extended memory"
- Start the game and get into the maze
- While the game is running, unset "Use VBXE for PORTB extended memory"
- OK -> OK -> Crash
Dump file:
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Sophia 2 preorder thread
in Atari 8-Bit Computers
Posted
I would like one.