Xuel

Mclaneinc, thanks for tracking that down! Sorry for the wrong filenames and the resulting confusion! Here's a corrected zip file: avgplay-1.1-correct-filenames.zip

Here's an example that I made for ndary in PM: sample.zip The Makefile shows the sox commands that you can use to convert to 8-bit raw files with sample rates of either 4k or 8k. It also shows a Perl one-liner to convert 8-bit raw files to 4-bit raw files. Run test.xex and press 1-5 to hear various techniques and sounds: 4bit 4k sample rate "barrel roll" 8bit 4k sample rate "barrel roll" 2X RAM consumption 4bit 8k sample rate "barrel roll" 2X RAM consumption 4bit 4k sample rate "bubblegum" 8bit 4k sample rate "bubblegum" 2X RAM consumption

Here's an example of manipulating BASIC's variable value table as @Rybags suggested: 10 DIM A$(1024):DIM B$(1024) 20 A$(1024)="X" 30 STARP=PEEK(140)+PEEK(141)*256 40 SRC=57344-STARP 50 DST=32768-STARP 60 VVTP=PEEK(134)+PEEK(135)*256 70 POKE VVTP+3,INT(SRC/256) 80 POKE VVTP+2,SRC-(PEEK(VVTP+3)*256) 90 POKE VVTP+11,INT(DST/256) 100 POKE VVTP+10,DST-(PEEK(VVTP+11)*256) 110 B$=A$ This relies on A$ and B$ being the first variables defined, so it will only work if typed or ENTERed after a NEW. Then you could SAVE and LOAD. This copies the character set at $E000 to $8000 pretty much instantly, but still slower than you can achieve with assembly language.

The resampling window size controls the quality of sinc resampling for all output formats and playback methods. Larger values improve the quality but increase conversion time. The only time the window size doesn't matter is if you input a WAV file with exactly the same sample frequency as the output format, i.e "freq" in the constrained settings sections. In this case resampling is skipped. Choosing "None" tells FujiConvert to use a simple nearest neighbor type of conversion between sample rates which is fast but can be noisy/tinny sounding.

DC offset shifts all sample values by the specified amount. When using 16 fine levels, a value of -8 can help with songs that have quiet sections where the sample values are all near the middle of the dynamic range. The reason is that it shifts these values to be centered in a range of values where only the fine level changes, e.g 112 through 127 or $70 - $7F, instead of centered in a range of values where the bottom half of the values map to one coarse level and the top half map to the next coarse level. You don't want to constantly be moving back and forth between values just below $7F and values just above $80 because the boundaries between coarse level increments are glitchy. So avoiding crossing them reduces noise. This is the similar to the phenomenon that causes the dark line between brightness levels 7 and 8 in GTIA mode 9. DC offset should be set to around -finelevels/2 for maximum benefit for quiet parts. But note that this reduces the available dynamic range and can cause clamping. For consistently loud songs it might be better to set DC offset to 0 to maximize the dynamic range.

@EddyFree Have you written anything about the methods that you use to develop your patches? I would love to read about the process that you go through.

Ack! OK, to add more confusion: The PDM Linear Pulse and Non-linear Pulse settings *only* affect carts and XEXs as these embed the player. They do *not* affect .PDM files. In other words, the pulse that you get depends on the player that you use: flashjazzcat's SIDE player uses a hard-coded pulse of 3/5. The AVGCART firmware player (PDMPLAY) that I wrote uses a hard-coded pulse of 4/6. FujiConvert-generated carts and XEXs use the pulses set in the tool. They let you toggle between linear and non-linear pulse settings by pressing the "L" key. The DC Offset, Coarse Levels, Fine Levels and Bump settings affect all outputs: carts, XEXs and .PDM files. These settings affect how samples are mapped into 8-bit values (4 hi, 4 lo). See this code. Unfortunately, these settings are most useful if you can also control the pulse used by the player. For Altirra in linear POKEY mode, the cleanest output is achieved with coarse=16, fine=16, pulse=4/6. For Altirra in non-linear POKEY mode, which more accurately simulates the hardware, it's not so clear-cut. Maybe coarse=16, fine=16 and then a toss up between pulse=3/5 or 4/6? For real hardware, I don't know. Sounds like @Faicuai is finding fine=14 works well with the SIDE player which is using pulse=3/5. But @Faicuai also says that pdm-test works best with fine=14 and pulse=4/6. Too bad PDM files are just raw 8-bit values. At some point it would be helpful to have a header to declare what settings should be used by the player. It may be nice to have a format where the 8-bit values represent ideal samples and then let the player map them as needed for the playback method. That would allow COVOX playback to use the samples as-is and PDM playback would map them to hi/lo possibly skipping certain hi and/or lo values. This assumes the mapping can be embedded in the lookup tables so that it's fast enough to be done real-time. It still may be the case that offline computation is needed to optimally stimulate the hardware in which case a dedicated PDM format would still be best.

This is poor UI design on my part. Selecting a preset just initially sets the PDM settings to some predefined values. But otherwise it has no effect. You can manually set the dc, coarse, fine, pulse values and ignore the preset. I just pushed v0.3.4 which changes the Preset to "Custom" whenever you change a PDM setting manually. Hopefully this clears up any confusion.

I ported the chess code to XASM and patched calls to OSB EOUTCH to get it working on XL/XE machines. It takes a while to draw the first move: edfries-chess-xasm.xex The code includes a flag you can set to view the moves it is considering which is interesting to watch: edfries-chess-xasm-view.xex Source for the port is here: https://github.com/lybrown/edfries-chess-xasm

Here's my attempt along with disassembly: lulu.zip

I see. That means you're accessing the tool through a file:// URL instead of http://. That won't work because certain web APIs that the tool uses don't work with file:// URLs. If you download the code, then you need access it through an http server. But you can also just use the latest version (v0.3.3) directly at this URL with no need to download it: https://lybrown.github.io/fujiconvert/ I've updated the github latest release to point to v0.3.3 as well. Thanks for the heads up!

@Triads, how big is the mp3 file? Maybe try converting it to WAV first and/or truncating it before loading it into FujiConvert? Can you try opening the browser console window while it's stuck to see if there are any error messages?

Feature request: Some kind of visualization for GTIA audio. Could the audio scope tap off of the audio chain after GTIA has been mixed in?

That would be a function of the AVGCART menu system, not the player itself. The menu system is responsible for setting up the stream for any particular file and then the player just reads it. I'm not sure if @tmp has published any documentation on the hardware registers which are used to interact with the SD card. All I know is that the player enables the stream by writing a "1" to $D510 and then bangs on the read register at $D5F0. To cleanup it should write a "1" followed by a "0" around 250 cycles later to $D511.

When you tried merging, how big were the files? Were they multiples of 8704 bytes? I believe that phaeron's latest 192-line encoder/decoder strategy uses exactly 17 512-byte sectors per frame. So as long as you join two or more AVF files at 17-sector boundaries, then the resulting merged file should play correctly. Please use caution, back up your files etc., but using GNU tools, this could be done as follows: truncate -s /8704 A.avf B.avf C.avf D.avf cat A.avf B.avf C.avf D.avf > E.avf Where "-s /8704" means truncate down to the nearest multiple of 8704 bytes. Again, CAUTION! This will remove up to 8703 bytes of your file! So, please back up if you are unsure. See also: https://atariage.com/forums/topic/211689-60-fps-video-using-side-2/?do=findComment&comment=2744987

What you're describing would happen if the sector reads get out of sync with the screen refresh rate. This could happen if a sector read takes too long or if the file is somehow fragmented on the media such that the file doesn't occupy sequential, contiguous sectors as CharlieChaplin mentioned. How are you transferring the files to the SD Card? Are you using SIDE2 or AVGCART?

I've fixed this. Here are new builds for all default combinations: avgplay-1.1.zip

OK, cool. Thanks Mr. Robot. I will check into it. Here are versions with different defaults: avgplay-mono-covox.xex avgplay-mono-pdm.xex avgplay-stereo-covox.xex avgplay-stereo-pdm.xex

I'll see if I can debug the double return/space issue. Can you walk me through the exact sequence of keypresses that you did starting from the AVGCart menu? Yeah, tmp and I discussed the possibility of storing defaults somewhere. For now, I'll post different versions of the player with different defaults.

So, if you defragment the .pdm files or write them continuously to start, then they'll be ready-to-play for as many playbacks as you want from then on, right?

As tmp said, this plays the same files as FJC's PDM Player. You can generate them here: https://lybrown.github.io/fujiconvert/ The bitrate is pretty much maxed out already. It is limited by the PDM playback method. It's 44KHz for mono and 22KHz for stereo. The AVGCart Player can use three different playback methods: PDM (8-bit), Covox (8-bit), and PCM (4-bit). Covox is probably the clearest if you have that extension in your machine. PDM should be better than PCM but I included PCM just for comparison. Currently .pdm files have no way other than file name to identify mono vs. stereo. I think it would be nice to develop a standard header for these files to include this info in the file itself. This could also contain other metadata like Artist and Title. I'll make a proposal later. You can play a stereo .pdm back as mono or vice versa but ideally you'd play back with the same number of channels as used during encoding with FujiConvert.

Source for the player here: avgpdm-1.0.zip This includes a rudimentary Altirra custom device which implements the AVGCart streaming protocol. I used it to debug my code in Altirra. I included instructions to install it in README.txt. NOTE: You need Altirra 4.0+ (e.g. Altirra 4.0-test5) for custom device support.

Here's a simple way to combine the Image.xex with Game.xex: opt h- ins 'Image.xex' opt h+ ini $2C00 opt h- ins 'Game.xex' ImageGame.xex No need to disable interrupts because Image.xex already does that. It also re-enables them when it exits, so any disk I/O, to continue loading will operate correctly. The important thing is to get the whole Image.xex loaded, then have an INI segment to run it, then the Game.xex, in that order. See also: https://www.atarimax.com/jindroush.atari.org/afmtexe.html

SAP defaults to PAL timings. For TYPE B, C, S and R songs, you can add the following line to the SAP header to make them play back with NTSC timings: FASTPLAY 262 Here is the Donkey Kong SAP from ASMA with that modification: Donkey_Kong_NTSC.sap See also: http://asap.sourceforge.net/sap-format.html

Here is some info: