Jump to content

Recommended Posts

Just a couple of tough ones (spectrally, and dynamically) I like to use to test audio response, in general:

 

1. NAMCO Sounds, Galaga Legions-DX: 01 Welcome, 033830. pdm14 (4_6) mono 44610Hz ide ntsc.pdm

2. Tron-legacy, Son of Flynn: 03 The Son of Flynn pdm14 (4_6) mono 44610Hz ide ntsc.pdm

3. Tron-Legacy, Solar Sailer: 15 Solar Sailer pdm14 (4_6) mono 44610Hz ide ntsc.pdm

 

#3 seems pretty hard on PDM and effective dynamic range / spectral bandwidth. All meant to be played with IDE player (!)

 

PDM-TEST indicates best playback of almost all waveforms requires 14 for fine-levels, and 4-6 for pulse.

 

All playing here, pretty well, on 800 / Incognito.

Edited by Faicuai

Fortunately the SIDE3 Loader's player uses the exact same interleaved layout as the SIDE2/Incognito/XEL-CF players, so at least there is no need to change the file format.

 

Edited by flashjazzcat
  • Like 2
5 hours ago, flashjazzcat said:

Fortunately the SIDE3 Loader's player uses the exact same interleaved layout as the SIDE2/Incognito/XEL-CF players, so at least there is no need to change the file format.

 

Have a couple of suggestions, hope you find them valuable:

 

  1. There's plenty of inert I/O (CPU-driven, it seems) when mapping target .PDM files, prior to playback-start. If you include a little switch on the options-menu, called "turbo mapping" or whatever you like, you can turn DMA OFF, by setup a one (status) line  Gr.0 display-list, and give the process 95% or more of available CPU bandwidth, thus shortening the pre-mapping stage substantially. Sounds to me like everyone (and every single host-model) will enjoy this, especially after we load 15-25+ MBytes tracks, which is what I am seeing on my latest conversions (and can't play them yet).
  2. Is there I way you can scan and protect existing DOSVEC vectors (by checking $08 / $09 flags) and keep them, so we can exit back to environment through them? Assuming no RAM-area below $1500 is overwritten by Player (I have not checked), it turns out that I can actually launch the existing PDM player right from SDX prompt (even n 80-cols. mode, btw), and since you can have SIDE2 and Incognito's own HD bothpresent on the bus, I can simply invoke SDX's  "X PDMSIDE.XEX" and it will take both Incognito's SDX and SIDE2 out of the $8000-$BFFF footprint, but still access SIDE2 through I/O area, thus being ale to play ANYTHING on the cart's CF (!) So it would be REALLY, REALLY nice to be able to exit safely trough DOSVEC, and return control back to SDX for a safe landing on SDX prompt (!)

Hope these are not too difficult to implement, since both would greatly enhance the versatility of the player.

 

Cheers!

Edited by Faicuai

Ok, put the player through its paces, and it seems that the more "compressed" the aural dynamics (e.g. narrower dynamics between low-and-high amplitude tones) the much better it sounds!

 

Here are a couple that sound VERY competent on our 40+ years old machines:

 

1. Phil Collins, Two Hears: 20 Two Hearts pdm14 mono 44610Hz ide ntsc.pdm

2. New Order, Price of Love: 23 World (Price of Love) pdm14 mono 44610Hz ide ntsc.pdm

 

Simply because of this (impressive) performance, I am now upgrading my shit-sounding tiny speakers to Bose Companion set, to better enjoy the quality that can be delivered through these conversions.

 

KUDOS for such F-amazing work (!!!)

Edited by Faicuai
  • Like 1
3 minutes ago, Faicuai said:

There's plenty of inert I/O (CPU-driven, it seems) when mapping target .PDM files, prior to playback-start. If you include a little switch on the options-menu, called "turbo mapping" or whatever you like, you can turn DMA OFF, by setup a one (status) line  Gr.0 display-list, and give the process 95% or more of available CPU bandwidth, thus shortening the pre-mapping stage substantially. Sounds to me like everyone (and every single host-model) will enjoy this, especially after we load 15-25+ MBytes tracks, which is what I am seeing on my latest conversions (and can't play them yet).

Not really any need. I noticed cluster mapping was inefficient the other night when working on the SIDE3 loader, and changed the 'GetNextCluster' function so that it reads the whole FAT sector into a buffer instead of reusing the XEX loader code (which reads every single byte from a FAT sector, scrapping everything but the bytes comprising the Cluster entry of iterest). Thus - unless a file is massively fragmented - each FAT sector contains 128 or 256 clusters belonging to the same file, cutting down the IO overhead by orders of magnitude. In tests here, a 9MB file is mapped in a couple of seconds.

 

Of course, this change could be ported back to the older player as well, when I actually get time to work on it.

 

As to the other question: I would not be surprised if the stand-alone PDM player had a fairly obnoxious load address. Again: something which can be looked at if I ever get around to it.

 

A similar issue presents itself with the (ROM based) SIDE3 loader, which unpacks all of its FMS code at $700. Without duplicating a lot of low-level IO and FMS code or making it relocatable, it will be necessary to cache low RAM when the loader is eventually able to silently auto-mount cartridges from the DOS prompt/menu (i.e. typing CAR after first power-up to SDX will seamlessly mount and initialise the auto-mount cartridge without displaying anything on the screen at all).

  • Like 1

 

3 minutes ago, flashjazzcat said:

I would not be surprised if the stand-alone PDM player had a fairly obnoxious load address

Because I have been slept-at-the-switch, it occurred to me to run a simple FSTRUCT command on PDMSIDE.XEX.

 

It turns out that lower address is $2000 (NICE!), initializing on $2000 after loading a small package on $A000, and then loading the bulk from $2000 onwards.

 

I do not know how the player eventually gets access to the CF file-system (since I disabled everything on both SIDE2 and Incognito's loaders), and we are not going through the loaders either... but it does work. It would absolutely wonderful to be able to return to SDX command prompt via DOSVEC.

 

NICE to hear the massive improvement on the pre-mapping stage. That sounds like orders of magnitude. Yes,. NO need to turn off DMA under such large optimization.

26 minutes ago, Faicuai said:

It would absolutely wonderful to be able to return to SDX command prompt via DOSVEC.

I'll have make some big changes to allow that to happen. Regardless of the fact the executable loads at $2000, I see that uses RAM at much lower addresses. I was no doubt pushed for space on 48K systems and had no choice at the time.

26 minutes ago, Faicuai said:

NICE to hear the massive improvement on the pre-mapping stage. That sounds like orders of magnitude. Yes,. NO need to turn off DMA under such large optimization.

Ironically, the display is turned off immediately after the mapping is complete since DMA would interfere with audio playback. But the mapping phase is so quick now that it actually makes more sense to display a message and leave the screen on during the mapping process rather than plunging the user into blackness for 1.5 seconds so they didn't have to look at a message for 2 seconds. During audio playback we have no real choice in the matter, but I generally prefer to make code fast with the screen on rather than turning off the display to overcome inefficiency.

Edited by flashjazzcat
2 hours ago, flashjazzcat said:

when the loader is eventually able to silently auto-mount cartridges from the DOS prompt/menu

Siunds like the control-extensions I actually developed for my Ultimate/SD cart (out of necessiy), which now lives happily alongside SDX (or any other dos for this matter) and also allows mounting any cart. image (rom) directly from SDX prompt, and without never leaving it, nor entering the cart. menu or loader. Even shutting the cart off the bus from SDX prompt is fully supported. Bringing the cart back to the bus, once dormant, does not seem possible.

 

One of the changes was to prevent pre-storing the .XEX loader above $700 unless the user was already invoking it from the cart´s menu for final exec-load. That originally obliterated SDX by merely entering the cart menu (now you can go IN and fly-back out to SDX, without ever crushing lomem area).

 

Works beautifully. especially on the 800 architecture.

Edited by Faicuai
26 minutes ago, Faicuai said:

Siunds like the control-extensions I actually developed for my Ultimate/SD cart (out of necessiy), which now lives happily alongside SDX (or any other dos for this matter) and also allows mounting any cart. image (rom) directly from SDX prompt, and without never leaving it, nor entering the cart. menu or loader. Even shutting the cart off the bus from SDX prompt is fully supported. Bringing the cart back to the bus, once dormant, does not seem possible.

Writing a tool to mount the cartridge from the SDX command line would be a much easier proposition than what I am actually trying to describe here: the SIDE3 loader booting completely silently without destroying anything in base memory, reading the configuration, opening a FAT partition on the SD card, reading the cartridge image into SRAM, the exiting without disturbing the graphics 0 display in any way. A simple SDX tool could read a cartridge image file straight off an SDX partition, but the rub there is we wouldn't be using DMA, and thus loading a 1MB image via DOS would be rather slow. Moreoever, if the user wants to run the SIDE3 as a MAC/65 95 per cent of the time, it would be nice if the cartridge would just boot directly into MAC/65 without any user interaction whatsoever.

 

The Ultimate Cart has the advantage of being rather autonomomous, with an MCU which can run procedural code. We can't just tell the SIDE3's FPGA to load a cartridge image off the FAT; the 6502 has to do almost everything. All part of the fun, though, making the Atari do the lion's share of the heavy lifting.

 

As said: I have to contend with the fact the SIDE3 loader installs a complete FAT16/32 file system driver in at $A00 or thereabouts (just above the code which loads XEX files); the reason it is there is that there is a CIO layer which allows XEX files to access the FAT via said FMS driver. The loader also calls the same FMS driver. So, to avoid disturbing an installed DOS, all the code the loader uses to access the FAT file system will have to be moved above $2000 when the loader is called in 'quiet' mode to auto-mount an image. Fortunately, there is almost limitless code space in the ROM.

Edited by flashjazzcat
17 hours ago, Faicuai said:

 

PDM-TEST indicates best playback of almost all waveforms requires 14 for fine-levels, and 4-6 for pulse.

 

All playing here, pretty well, on 800 / Incognito.

 

What pulse? Linear pulse or non-linear pulse? The standard in Fuji Convert 0.3.3 is 2/4 for non-linear pulse and 3/5 for linear pulse. (Also note it uses / instead of - so your example maybe should be / could be 4/6 ?!?)  And since a picture says more than words, can you make a screenshot please with your settings of Fuji Convert ?

 

(I originally converted 550 songs 2x into PDM, but was not that impressed with the stereo-versions playing thru my stereo-Pokey enhancement, so I kept only the mono versions. The PDM stereo versions did not keep the separation of vocals and music which you can find in some old songs, like e.g. California Dreaming and errmm, the white noise was much higher than with the mono versions. Since no-one would listen to so many songs in pseudo-8Bit mono anyways, when all of them are available in much better 16Bit stereo and sometimes even 20Bit or 24Bit surround quality, I kept only 100 songs for demonstration purposes. Some of them are of good quality, e.g. "A Girl like you" by Edwyn Collins and some of them are of bad or very bad quality, e.g. "My Immortal" by Evanescence, "All night long" by Lionel Richie, etc.; some of the PDMs are only 2 minutes short, some of them are over 12 minutes, e.g. "Shine on you crazy diamond" by Pink Floyd or "I would do anything for love" album version by Meat Loaf)

 

42 minutes ago, CharlieChaplin said:

What pulse? Linear pulse or non-linear pulse?

Both set at 4/6 (liner and non-linear). I actually explored (very carefully) these settings on PDM-TEST utility (whatever could be tested).

 

Rest of settings are Auto-gain, 2048, 16/14/0, 44 Khz, Mono, NTSC, IDE-output. Anything else changed.

 

The aural-dynamics (how wide or "compressed" is the amplitude range of original sound-track) seem to determine how well a sound-track fit this encoding+playback model. Already made several target tests and the results seem clear.

 

I have more tracks I would like to play (from Steve Vai, world's best elec. guitar player) and anything above 12.5MB in length does not play here. Maybe later, on a future version.

Edited by Faicuai

Much depends on the cluster size, of course, but the cluster map for a 9MB PDM file tested here consumed only 9KB of SRAM on the SIDE3 (about 2,200 FAT32 clusters). About 800K is available (or 65,535 clusters, whichever happens first).

Thanks a lot for that info! Will convert some songs again into PDM and check (listen) if the quality is better with your given settings. (There is no 16/14/0 in Preset, only 16/16/0 and 16/14/1 - guess you mean 16/14/1 then.)

 

If I remember correctly FJC's PDM player was limited to ~3000 clusters, so try re-formatting your SD or CF card and set the cluster size to 16k or 32k - with 32k cluster size PDM's up to 96MB in length should theoretically play fine. (My largest PDM file is 35MB in size, it is the 14 minute instrumental from Hoverstrike U.L. for the Atari Jaguar.)

 

 

31 minutes ago, CharlieChaplin said:

There is no 16/14/0 in Preset

You type it in. 

 

Make sure BUMP=0, so you can replicate what I got on my end.

 

I am going to experiment with 15/14/0 and 14/14/0, a little later. I am getting pretty decent playback quality, already, and that is through a pair of shitty / tiny PC speakers that I bought dirt-cheap. Not any more, once the Bose Companions arrive.

15 hours ago, Mazzspeed said:

Does this work with SIDE3?

The SIDE3 player has been modified to play PDM files. Update will be released shortly. The SIDE2 player doesn't work on SIDE3.

On 4/23/2021 at 6:08 PM, Faicuai said:

NICE to hear the massive improvement on the pre-mapping stage.

Is this fast enough?

 

https://photos.app.goo.gl/C4EX3W84rZ1dyDML9

  • Like 2
3 hours ago, flashjazzcat said:

The SIDE3 player has been modified to play PDM files. Update will be released shortly. The SIDE2 player doesn't work on SIDE3.

Is this fast enough?

 

https://photos.app.goo.gl/C4EX3W84rZ1dyDML9

Ohhh, that looks exciting. Let me know when it's released FJC, I'll download it in a heartbeat.

  • Like 1
On 4/24/2021 at 12:52 AM, Faicuai said:

You type it in. 

 

Make sure BUMP=0, so you can replicate what I got on my end.

 

I am going to experiment with 15/14/0 and 14/14/0, a little later. I am getting pretty decent playback quality, already, and that is through a pair of shitty / tiny PC speakers that I bought dirt-cheap. Not any more, once the Bose Companions arrive.

 

Hmmm, I am using the following settings:

 

FujiConvert.thumb.jpg.b8f0382c449485c5486de52aeb9b045f.jpg

 

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.

 

The frequency is automatically set to 44khz when I choose IDE player and mono and it is also automatically set to 22khz when I choose IDE player and stereo - so there is no need to set it manually in the frequency menu it seems (in the picture it shows 33khz under frequency on the left side, but it shows 44khz on the right side).

 

2 hours ago, CharlieChaplin said:

As you can see, it isn't possible to type in 16/14/0 in PDM Setting "Preset"

(EDIT): I see what you mean, they don't really change on the right-hand side of constrained parameters... Mhmmm...

 

I am now traveling for the weekend, but will be back tomorrow evening, and will be re-mastering all .PDMs with 5/7 for non-linear pulse and 4/6 for linear pulse, FYI (this is based on last minute tests I conducted on PDM-TEST utility).

 

Will report back then.

Edited by Faicuai
  • Like 1
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

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
4 hours ago, Xuel said:

At some point it would be helpful to have a header to declare what settings should be used by the player

I was going to suggest some kind of sector aligned metadata at the top of the file, perhaps using a new file type (so as not to cause the existing PDM players to play the metadata as junk audio). There are definite limits on what can be accomplished in terms of playback tuning, but right now it would be hard to even discern if the audio data is in stereo format without maybe using a different file extension or parsing the filename for encoding information.

 

  • Like 2
5 hours ago, Xuel said:

But @Faicuai also says that pdm-test works best with fine=14 and pulse=4/6

This is what I noticed in PDM-TEST (took very close attention when testing):

 

1. Fine-levels = 14 (best overall, cleanest sound for any wave-type).

2. Non-linear pulse: 5-7, especially with sine-like wave. I will reconfirm today, night-time.

3. Linear pulse: 4-6 for sure, especially on square / triangle wave-type)

 

NAMCO-sounds Galaga Legions DX soundtrack should definitely improve with these settings.

 

I would suggest Encoder to have what's called an "open" pre-set (in addition to the existing ones) where we can freely change or tune anything, independently, based on PDM-TEST results.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...