Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Xuel

  1. Here's a six byte patch that at least stops the flicker on the first level: Yie Another Kung-Fu Xuel Patch.rom I just shortened the double-buffered display lists by one line to avoid the hires bug that phaeron identified in the thread you quoted. Not sure how it works on real hardware.
  2. Xuel

    Atari Beaglebone Expansion

    The existing AVG firmware couldn't support these types of movies. It would need to implement a bank switching scheme similar to ABX. Currently it only supports a streaming mode similar to SIDE or MyIDE. The fundamental requirements for RastaConverter-esque movies is a memory bank where Sally and Antic can intermix reads in a somewhat random access fashion. Ideally it would be large enough to hold both the bitmap data and the 6502 code for a full screen. Otherwise you'll have to dedicate some 6502 instructions mid-screen to bank switching and even then the underlying hardware might not be able to bank switch fast enough. ABX actually streams in the next bank during the vertical blank period.
  3. A simple conversion would not be possible since color register values may be reused as player positions and vice versa. For example, if the program determines that the optimal 6502 instruction stream at some point in the middle of the screen for NTSC is as follows: ... LDA #$3C STA COLPF1 STA HPOSP3 ... Then, you can't simply change the LDA #$3C to LDA #$2C for PAL because that will also change the position of player #3. You pretty much have to rerun from scratch to target a different palette. I suppose the tool could have an option to work on PAL and NTSC versions simultaneously but it will double the amount of computation necessary, so it would anyway be comparable to running the tool twice.
  4. I would need to work with tmp to get that working based on file extensions. I'll work on it.
  5. Done. This is now implemented in 0.3.5. Select "Covox" under "Playback Method" to get "cov" or "cos". All other playback methods are assumed to be "pdm" or "pds". The PDM Settings are now also disabled when selecting Covox. This means .cov and .cos files will have a simple linear mapping from sample values to 8-bit values, i.e. the same as you would get with PDM preset "16 16 0". https://lybrown.github.io/fujiconvert/
  6. Xuel


    Awesome! You are truly making use of the field-programmability of the FPGA! So many options to explore with the same hardware. And kudos for designing the whole cart to support all these possibilities from the start. Nice tease at the end too.
  7. I found and fixed a couple bugs in your compressor (a couple missing GOTOs). I also wrote a version in Perl. I'm attaching both: rle.zip Both compressors reduce Gollum_C64_Rensoupp_Tebe.scr from 1200 bytes to 262 bytes, not the 253 you mentioned earlier. I'm curious if they are missing an optimization that you did in your hand encoding?
  8. @flashjazzcat It looks like the new SIDE loaders (v0.43) don't initialize the second POKEY when playing .PDS files so the right channel is effectively only 4-bit resolution instead of 8-bit since the oscillators are never started.
  9. 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
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. @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.
  15. 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.
  16. 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.
  17. 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
  18. Here's my attempt along with disassembly: lulu.zip
  19. 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!
  20. @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?
  21. 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?
  22. 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.
  23. 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
  24. 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?
  25. Xuel


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