PSX cdrom sector buffer capacity

General information to do with the PlayStation 1 Hardware. Including modchips, pinouts, rare or obscure development equipment, etc.
Post Reply
User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

PSX cdrom sector buffer capacity

Post by nocash » April 8th, 2013, 6:36 am

I have been doing some hardware tests on a PSone to find out how many sectors the console can hold in its sector buffer. The result is a bit puzzling: It seems to be able to hold up to EIGHT sectors, BUT: it allows to access only TWO of those sectors. The other sectors are lost - they appear to be in the buffer, but I haven't found a way to read them. Either I am doing something wrong (?) ... or Sony has made a fundamental mistake in their hardware design.

Some more details: The CDROM sector buffer is 32Kx8 SRAM (IC303 on PU-8/PU-18 boards; intergrated in the SPU on later boards). The buffer is apparently divided into 8 slots, theoretically allowing to buffer up to 8 sectors. But, the drive controller seems to allow only 2 of those 8 sectors (the oldest sector, and the current/newest sector), ie. after processing the INT1 for the oldest sector, one would expect the controller to generate another INT1 for next newer sector - but instead it appears to jump directly to INT1 for the newest sector (skipping all other unprocessed sectors).

So far, the big 32Kbyte buffer is entirely useless (the two accessible sectors could have been as well stored in a 8Kbyte chip) (unless, maybe the 32Kbytes have been intended for some error-correction "read-ahead" purposes, rather than as "look-back" buffer for old sectors; one of the unused slots might be also used for XA-ADPCM sectors).

The bottom line is that one should process INT1's as soon as possible (ie. before the cdrom controller receives and skips further sectors). Otherwise sectors would be lost without notice. As far as I know there appear to be absolutely no overrun status flags, nor overrun error interrupts - or are there such overrun notifications?

Code: Select all

Some sector buffer test cases...
  Setloc(0:2:0)+Read
  Process INT1 --> receives sector header for 0:2:0
  Process INT1 --> receives sector header for 0:2:1
  Process INT1 --> receives sector header for 0:2:2
  Process INT1 --> receives sector header for 0:2:3
Above shows the normal flow when processing INT1's as they arise. Now, 
inserting delays (and not processing INT1's during that delays):
  Setloc(0:2:0)+Read
  Process INT1 --> receives sector header for 0:2:0
  delay(1)
  Process INT1 --> receives sector header for 0:2:1 (oldest sector)
  Process INT1 --> receives sector header for 0:2:6 (newest sector)
  Process INT1 --> receives sector header for 0:2:7 (next sector)
Above suggests that the CDROM buffer can hold max 2 sectors (the oldest
and current one). However, using a longer delay:
  Setloc(0:2:0)+Read
  Process INT1 --> receives sector header for 0:2:0
  delay(2)
  Process INT1 --> receives sector header for 0:2:9  (oldest/overwritten)
  Process INT1 --> receives sector header for 0:2:11 (newest sector)
  Process INT1 --> receives sector header for 0:2:12 (next sector)
Above indicates that sector buffer can hold 8 sectors (as the sector 1 slot
is overwritten by sector 9). And, another test with even longer delay:
  Setloc(0:2:0)+Read
  Process INT1 --> receives sector header for 0:2:0
  delay(3)
  Process INT1 --> receives sector header for 0:2:17 (currently received)
  Process INT1 --> receives sector header for 0:2:16 (newest full sector)
  Process INT1 --> receives sector header for 0:2:17 (next sector)
  Process INT1 --> receives sector header for 0:2:18 (next sector)
Above is a special case where sector 17 appears twice; the first one is the
sector 1 slot (which was overwritten by sector 9, and apparently then half
overwritten by sector 17).
Did anybody else see the same lost-sector-problem? And is there a way around it?
Of course the two latters tests (with longer delays, and with overwritten slots) can't work, but the test with short delay should work.

Yuri^Cybdyn
Verified
Cybdyn Systems
Cybdyn Systems
Posts: 406
Joined: Jan 13, 2012
I am a: Embedded Developer (MCU & FPGA)
PlayStation Model: 5502
Location: Belarus (Minsk)

Post by Yuri^Cybdyn » January 5th, 2014, 9:40 am

Hi No$cash, any chance talk w/ you, i sent email to you. i still have couple questions about cdrom emulation

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 6th, 2014, 1:38 pm

I've tried to document everything about the cdrom hardware here: http://nocash.emubase.de/psx-spx.htm#cdromdrive (the doc gets updated alongsides with each new no$psx debugger release).

For the sector buffer capacity, the psxdev.ru people have decapped the cdrom sub-cpu and dumped its BIOS a few months ago, which confirmed that the PSX can really hold only two data sectors in the 32Kbyte buffer (the sub-cpu BIOS gets notified about further incoming sectors, but the poor thing simply doesn't memorize if has received more than 2 sectors, so it can't forward them to the main-cpu).

Yuri^Cybdyn
Verified
Cybdyn Systems
Cybdyn Systems
Posts: 406
Joined: Jan 13, 2012
I am a: Embedded Developer (MCU & FPGA)
PlayStation Model: 5502
Location: Belarus (Minsk)

Post by Yuri^Cybdyn » February 8th, 2014, 5:47 am

actually , i have questions not only about buffer size))
i find many interesting things - your emulator (no$psx) can do, but i didnt find expalnations on cd-rom info page.
also i have questions about info from your pages too.

Yuri^Cybdyn
Verified
Cybdyn Systems
Cybdyn Systems
Posts: 406
Joined: Jan 13, 2012
I am a: Embedded Developer (MCU & FPGA)
PlayStation Model: 5502
Location: Belarus (Minsk)

Post by Yuri^Cybdyn » February 8th, 2014, 6:03 am

also i've heard you did disassembled code from sub-cpu. hope you will add more interesting info...?))

Yuri^Cybdyn
Verified
Cybdyn Systems
Cybdyn Systems
Posts: 406
Joined: Jan 13, 2012
I am a: Embedded Developer (MCU & FPGA)
PlayStation Model: 5502
Location: Belarus (Minsk)

Post by Yuri^Cybdyn » February 16th, 2014, 6:56 am

Hi, no$cash
i see you can know many interesting/useful information, like:

cd/help: added notes on sub-cpu mainloop/response/priority/timing/queue/flags
cd/emu: simplified 1st/2nd/3rd response slots (instead overcomplicated queue)
debug: optional IRQx logging to tty window (plus detailed cdrom INTxx info)
cd/emu: emulates exact filter/realtime handling for adpcm and data sectors
cd/help: added notes on data/adpcm sector filtering/delivery on cdrom-reading
cd/help: added almost perfect xa-adpcm zig-zag-interpolation formula/tables
cd/help: added note on unitialized six-step adpcm interpolation counter
cd/help: added flowchart for using sound map mode (with random 3-slot caution)
cd/emu: emulates 8bit xa-adpcm decompression (unlike normal 4bit xa-adpcm)
cd/emu: emulates xa-adpcm zig-zag-interpolation (37.8 to 44.1kHz resampling)
cd/emu: bugfixed xa-adpcm (did destroy sixstep "extra_offhold" inside of lop)
cd/emu: emulates newly discovered MotorOn command (and its various errors)
cd/help: added some basic notes and waveform example for xa-emphasis feature
cd/emu: emulates invalid xa-adpcm filter=4..15 and invalid shift=13..15 values
cd/emu: added basic soundmap emulation (works at least to play one 900h unit)
cd/help: added notes on invalid xa-adpcm filter=4..15 and shift=13..15 values
spu: bugfixed cd.audio.capture buffer (is NOT affected by cd.audio volume)
cd/help: added notes on newly discovered secret_unlock feature (command 5xh)
cd/myth/help: eliminated "Standby" myth (actual function of cmd 7 is MotorOn)
cd/help: added notes on peak bytes for Play+Report (and incomplete GetQ peak)
cd/help: added details on purpose/function of all cdrom test commands
cd/help: discovered more test commands (supported on older PSX consoles only)
cd/help: added specs for CXA1782BR cdrom servo amplifier registers
cd/help: added specs for CXD2510Q cdrom signal processor registers
cd/help: added specs for CXD2545Q cdrom combined servo + signal processor
cd/help: added specs for CXD1199BQ/CXD1815Q cdrom decoder/fifo registers
cd/help: added specs for MC68HC05 on-chip I/O Ports (and their usage in psx)
cd/help: added notes on GetID's ATIP byte, and on POS0 flag in sub_func 21h
cd/help: removed nonsense sub_function numbers from ancient cdinfo.txt
cd/help: added info on some formerly unknown CD-XA bytes (in the LEN_SU area)
cd/help: added subheader CI coding info bits (adpcm emphasis and 8bit/sample)
cd/help: added notes on more cd-xa fields in primary volume descriptor
poc/help: added some pocketstation details (LED, mirrors, exceptions, etc)
help: added notes on PU-7 chipset (different cdrom/spu/gpu/cpu/bios chips)
bios: added patch_uninstall_early_card_irq_handler_efficient (thanks shendo)
gui: setup uses asia-compatible TabControl instead of unreliable PropertySheet
dma3/cdrom and dma6/otc: treats len=0 as length=10000h words (=256 kbytes)
cdrom data fifo: uses [800h-8] or [924h-4] as padding-byte after sector end
gui: fullscreen mode preserves real aspect ratio (padded with black border)
gui: fullscreen mode moved to context menu (instead of old setup option)
gui: created mouse-shape-less No$helpClass (avoid flickering mouse pointer)
debug: supports MC68HC05.ROM bios loading (16.5K) (for disasm at 50001000h)
debug: re-arranged gte registers in iomap (fixed overlapping text fields)
debug: added dummy-mappings: 50000000h=mc68hc05 memory/mc68hc05 disassembler
debug: added dummy-mappings: 60000000h=vram, and 70000000h=spu-ram
debug/help: added disassembler and specs for mc68hc05 cpu (cdrom coprocessor)
spu/help: corrected spu-irq description (irq9 does trigger also on spu-dma)

can you tell more about all of this ?? or it's on your new revisions of specification?

Yuri^Cybdyn
Verified
Cybdyn Systems
Cybdyn Systems
Posts: 406
Joined: Jan 13, 2012
I am a: Embedded Developer (MCU & FPGA)
PlayStation Model: 5502
Location: Belarus (Minsk)

Post by Yuri^Cybdyn » February 16th, 2014, 7:05 am

question about this info: INT10h Command Start (when INT10h requested via 1F801803h.Index0.Bit5)
..The upper bits however can be ORed with the lower bits (ie. Command Start INT10h and 1st Response INT3 would give INT13h).
i didnt know about it - are you really saw such INT = 0x13 ? what game use such way - what can you advice for example to check it out??

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » February 17th, 2014, 1:40 am

There aren't any games using that INT10 feature. I've only observed that bit4 appears to get set on command start on real hardware.
But, after having discovered the chipset datasheets, it does actually look as if bit4 means something different than "command start".

Yuri^Cybdyn
Verified
Cybdyn Systems
Cybdyn Systems
Posts: 406
Joined: Jan 13, 2012
I am a: Embedded Developer (MCU & FPGA)
PlayStation Model: 5502
Location: Belarus (Minsk)

Post by Yuri^Cybdyn » February 17th, 2014, 6:06 am

can you tell more about question above: where you find many new things about "cd/help" "cd/emu"?

Yuri^Cybdyn
Verified
Cybdyn Systems
Cybdyn Systems
Posts: 406
Joined: Jan 13, 2012
I am a: Embedded Developer (MCU & FPGA)
PlayStation Model: 5502
Location: Belarus (Minsk)

Post by Yuri^Cybdyn » March 18th, 2014, 6:06 am

to NO$CASH: "accordingly, the PSX can use only three of the available eight SRAM slots: One for currently pending INT1, one for undelivered INT1, and one for currently/incompletly received sector)."

so sub-cpu holds space in RAM for only 3 sectors?
then if no reading from Host (ps1) it overwrites data in those sectors?

User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » March 18th, 2014, 11:41 pm

Thanks for all your hard work and documentation NO$CASH in relation to the PlayStation 1.
I have sent you a donation as a personal thank you.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests