It doesn't store CUE Index values?
Yes, that's one of the basic flaws. The CHD format as such could store them in the subchannel data, but CHDMAN is just ignoring most of the CUE Index values.

One could convert CUE/BIN to TOC/BIN (the BIN with 990h-byte sectors) and then to CHD. If there's no tool ...

That CHDs are looking as expected.

The ECC-Filter doesn't work for 920h/980h byte sectors, resulting in very bad compression ratio.

CHDMAN thinks that it stores the Subchannel-data in a separate Deflated block, but it doesn't actually do so for 860h/980h byte sectors:

For 980h-byte sectors:
000h ...

.ISZ is made by UltraISO EZB Systems. They also put the file format specification TXT in their website.

Good to know.
Hmmm, UltraISO? I guess that's crap (going by the corrupted audio test files that you had made with UltraISO).

But they have documentation! That's more thoughful than the CHD ...

Got the "Audio disc in CHD with 247248 hunksize" working!
It's confusing, but I think I've sorted out how it works:
CHD Track/Hunk Padding and Missing Index0 sectors
A normal CDROM contains a series of sectors. The CHD format is violating that
in several ways: It's removing Index0/Pregap sectors ...

I got side-tracked and spent some days on LZMA2 and XZ decompression, whatever that's good for. XZ is just a mess. LZMA2 itself is just a very simple LZMA extension.



Does somebody have a small CUE/BIN image with such smaller sector sizes for testing?

The --sectorsize -ss command is available ...

That's because your timeout is too short for the 7th ACK.
See the "Timings" part in http://problemkaputt.de/psxspx-memory-card-read-write-commands.htm
Alltogether you should get nine ACKs (the 10th byte-pair is also transferred, but doesn't respond with an ACK).

PS. After re-reading the psxspx ...

This is all about the 4-track 1-2-3-4 stereo test files:

Intact: The CUE/BIN version
Intact: The V4 CHD version
Intact: The V5 CHD version
Corrupted: The MDS version (missing pregaps)
Corrupted: The NRG version (missing pregaps)
Corrupted: The PBP version (missing pregaps)
Don't know: The CCD ...

PS. for the IRQ flag to trigger on ACK, enable only that IRQ source (JOY_CTRL.bit12=1, bit10-11=0).

Uhm 11001111 binary would be 207 decimal, not 207h hex.
What you are seeing is bit9 (200h) being set, in the "terrible Nth bit notation" that would be the 9th or 10th or 7th bit (depending whether consider bit0 or bit1 or bit15 as "1st bit").

When waiting...
First, wait for JOY_STAT.bit2=finished ...

Okay... that are quite a lot of tools, I am not quite sure which tool(s) where used for which files...
(originating from the CUE, it might matter if you had first converted the CUE to a corrupted NRG file, and then converted the corrupted NRG to MDS format, or the like).

I've examined the files ...

This link won't show any information with win9x + retrozilla:
https://gitlab.com/chriz2600/ps1-game-id-transmission/-/blob/master/README.md
This link works on win9x:
https://gitlab.com/chriz2600/ps1-game-id-transmission/-/raw/master/README.md
I've had a closer look at the latter README.md document ...

0) There is no difference between sending command bytes and sending data bytes. That said about sending bytes , the README.md is using a different notation: CMND=SendByte, DATA=ReceiveResponseByte.

1) Yes, the memory card determines what it considers as valid. The memcard pro thing should accept ...

Cool, I was afraid that I might have steered you into troubles when suggesting to use the no$psx asm tools.

Yes, .align works for zerofill, or "defs numbytes" does also zerofill, or ".import name,offs,numbytes" does "fill" with original data.
You can also use labels (like the LC0 one you have in ...

Oops, I've got the above import example wrong: There must be a comma between filename and offset. Sorry!

For the data lines, the binary values are looking okay, so the emulator should execute the shift opcode correctly, no matter if the disassembler is showing it as data or not.
No$psx contains a ...

All offsets are in bytes.
ORG is the start offset in the PSX memory space.
The IMPORT offset is a fileoffset within the imported file, starting at 0.

You may need something like +/-base if you want to convert file offsets to PSX memory offsets, or vice versa.

If no$psx does recognize the resulting ...

Cool, thanks! That looks like a complete collection of file formats (apart from the missing CDI format).

Testing the various formats in no$psx, there seem to be some issues (missing gaps between tracks, or completely missing track 2-4). I'll look more into that later... it's very well possible that ...

Entering hex values starting with 0-F require leading 0 to distinguish from symbols starting with A-Z.

Pulling the string out of memory works only if it was already put into memory, it's good to know if/when/where it was put into memory.

Import does import original binary data portions (not ...

Mono Audio Tracks (with CHD V5 FLAC)
That would be also interesting for testing. The overall CHD FLAC data is always 2 channels (stereo), but it could also contain FLAC Frames with only 1 channel. The simple FLAC decoder doesn't handle that case, and I don't know how it should be handled (only ...

Sector Sizes
Decompressed CHD sectors are always 990h bytes tall (930h bytes sector data, plus 60h bytes subchannel data).

For the 930h-byte sector data, all my CUE/BIN disc-images are actually stored in as 930h-byte sectors format, but CHD metadata does also support other sectors like 800h bytes ...

Perfect. That's a wonderful small cdrom-image, very useful for testing things!

Ah, I see, Track 1 should only say "one" (plus silence), not "one two three four hmmmm" as happening in no$psx. I am currently mirroring to "random" sectors during PREGAPs (hence the "two three four") and I am mirroring ...