Jump to content

Xuel

Members
  • Content Count

    832
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Xuel


  1. On 10/6/2021 at 2:57 PM, MrFish said:

     

    Speaking of RasterConverter... a nice update for it would be the ability to produce PAL & NTSC versions for a single image. Failing that, some type of simple command-line conversion tool that could produce one from the other would suffice.

     

    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.

    • Like 1
    • Thanks 1

  2. 5 hours ago, CharlieChaplin said:

    Would be great to get a new or updated 800/XL/XE player for AVG-cart, so whenever I choose a *.COS file it will automatically set playback to Covox and stereo or when I choose *.PDS it will automatically set playback to PDM and stereo, etc.

    I would need to work with tmp to get that working based on file extensions. I'll work on it.

    • Like 2
    • Thanks 1

  3. On 9/19/2021 at 4:20 PM, CharlieChaplin said:
    *.PDM = mono PDM
    *.PDS = stereo PDM
    *.COV = mono Covox
    *.COS = stereo Covox
     
    Would be nice if Xuel's player for the AVG cart would also use this convention (since we would need only one player and no pre-sets then).
     

    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/

    • Like 2
    • Thanks 1

  4. 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.

    • Like 5

  5. On 9/21/2021 at 6:47 AM, glurk said:

    The BAS program is semi-messy QB64 BASIC, but it works.  It's hard-coded to read a file named TEST.BIN, but this can be changed.  I don't know enough QB64 to make it accept drag-n-drop or command-line input.  I'll figure that out later, I first wanted to get it working.

    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?


  6. On 7/17/2021 at 3:07 PM, Mclaneinc said:

    Yep, that's what I thought, I'll swap around the other XEX's, just incase one was wrongly named..

     

    EDIT

     

    Yep, the Covox pdm mono is actually, the PDM Mono..

     

    Thanks again tmp..At least Xuel can fix the zip..

    On 7/23/2021 at 4:39 AM, Mclaneinc said:

    As far as I know there was never a setting file or the like and it stayed with individual players for each sound system. In the end, for me, it was simply player files wrongly named in the released versions. All fine now after I used the named Covox player which was actually the PDM mono..For once, not my fault, rare I know :)

    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

    • Like 1
    • Thanks 2

  7. 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:

    1. 4bit 4k sample rate "barrel roll"
    2. 8bit 4k sample rate "barrel roll"  2X RAM consumption
    3. 4bit 8k sample rate "barrel roll"  2X RAM consumption 
    4. 4bit 4k sample rate "bubblegum"
    5. 8bit 4k sample rate "bubblegum" 2X RAM consumption
    • Like 1

  8. 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.

    • Like 5

  9. 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.

     


  10. 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.

    • Like 2
    • Thanks 1

  11. 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.

    • Like 3
    • Thanks 2

  12. 5 hours ago, CharlieChaplin said:

    As you can see, it isn't possible to type in 16/14/0 in PDM Setting "Preset", one can only choose between four given presets here, which are 16/16/0,  16/8/0,  8/8/0  and  16/14/1. Or where do you type it in? I am also unsure what value I should use in DC Offset, one can choose values between +7 and -8, the default seems to be -7 and I choose that one and zero for testing purposes.

    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.

    • Like 2

  13. 6 minutes ago, Triads said:

    Yes there is an error -

    Security Error: Content at file:///I:/Altirra%20Test/fujiconvert-0.3/index.html may not load data from file:///I:/Altirra%20Test/fujiconvert-0.3/resample.js.

    Is there a fix for this?

     

    thanks

     

     

     

     

    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!

     


  14. 4 hours ago, Poison said:

    i would like to ask if is possible to add function play next avf automatically to AVFPlayer for AVG cart?

     

    idea: after 1st movie ends player automacically move to the next AVF via press arrow down and than itself hit return :)

    So I mean, that player finish avf play, ends itself, tham arrow down, return and plaaay :) I dont know if it is possible or not, but could be nice feature and it is not necessarry to merge AVF files to one long.

    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.


  15. 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

    • Like 3

  16. 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?


  17. On 7/26/2020 at 4:38 PM, Mr Robot said:

    Power on, wait for menu, press G to go to the PDM directory, Press A to launch first file

     

    now I have to press return or space to get the ui. Space space, return return, space return and return space all work. 
     

    it’s completely repeatable

     

    either a single return or space exits the ui fine


    once it’s been entered once pressing space or return once works

     

    tried it on my 800xl as well. Same result. 

    I've fixed this. Here are new builds for all default combinations:

     

    avgplay-1.1.zip

    • Like 5
×
×
  • Create New...