Contributors to Martin Korth's original documentation: +
GPU.TXT by doomed/padua; based on info from K-communications & Nagra/Blackbag
+GTE.TXT by doomed@c64.org / psx.rules.org
+SPU.TXT by doomed@c64.org / psx.rules.org
+CDINFO.TXT by doomed with big thanks to Barubary, who rewrote a large part
+SYSTEM.TXT by doomed with thanx to Herozero for breakpoint info
+PS_ENG.TXT PlayStation PAD/Memory Interface Protocol by HFB03536
+IDT79R3041 Hardware User's Manual by Integrated Device Technology, Inc.
+IDTR3051, R3052 RISController User's Manual by Integrated Device Technology
+PSX.* by Joshua Walker (additional details in various distorted file formats)
+LIBMIRAGE by Rok; info/source code for various cdrom-image formats
+psxdev.ru; cdrom sub-cpu decapping
+All the contributors to the psx-spx.github.io +repo who've helped update, correct and expand this information.
+The following arcade PCBs are known to be based on PlayStation hardware:
+| Manufacturer | +Board | +CPU clock | +GPU | +RAM | +VRAM | +Additional CPUs | +Audio | +Storage | +
|---|---|---|---|---|---|---|---|---|
| Konami | +GV | +33 MHz | +v0 | +2 MB | +1 MB | ++ | SPU, CD-DA | +SCSI CD-ROM, optional flash daughterboard | +
| Konami | +GQ | +33 MHz | +v1 | +4 MB | +2 MB | +68000, TMS57002 | +2x custom PCM chip | +SCSI hard drive | +
| Konami | +System 573 | +33 MHz | +v2 | +4 MB | +2 MB | +H8/3644 | +SPU, CD-DA, optional MP3 decoder | +16 MB flash, optional ATAPI CD-ROM, PCMCIA cards | +
| Konami | +Twinkle System | +33 MHz | +v2 | +4 MB | +2 MB | +68000, DVD player | +SPU, Ricoh RF5C400 | +SCSI CD-ROM, IDE hard drive, VCD/DVD, optional floppy | +
| Namco | +System 11 (COH-100 CPU board) | +33 MHz | +v1 | +4 MB | +2 MB | +Namco C76 | +SPU (unpopulated), custom PCM chip | +Mask ROM daughterboard | +
| Namco | +System 11 (COH-110 CPU board) | +33 MHz | +v2 | +4 MB | +2 MB | +Namco C76 | +Custom PCM chip | +Mask ROM daughterboard | +
| Namco | +System 12 (COH-700 CPU board) | +50 MHz | +v2b | +4 MB | +2 MB | +H8/3002, optional SH-2 | +Custom PCM chip, optional XA-ADPCM | +Mask ROM/flash daughterboard, optional ATAPI CD-ROM | +
| Namco | +System 12 (COH-716 CPU board) | +50 MHz | +v2 | +16 MB | +2 MB | +H8/3002, optional SH-2 | +Custom PCM chip, optional XA-ADPCM | +Mask ROM/flash daughterboard, optional ATAPI CD-ROM | +
| Namco | +System 10 | +50 MHz | +v2 | +16 MB | +2 MB | ++ | SPU, optional MP3 decoder | +Mask ROM/flash daughterboard, optional ATAPI CD-ROM | +
| Sony | +ZN-1 | +33 MHz | +v2 | +4-8 MB | +1-2 MB | +Optional game-specific | +SPU, optional game-specific hardware | +Mask ROM/flash daughterboard | +
| Sony | +ZN-2 | +50 MHz | +v2 or v2b | +4-16 MB | +2 MB | +Optional game-specific | +SPU, optional game-specific hardware | +Mask ROM/flash daughterboard | +
| Taito | +FX-1A (ZN-1 + custom addon board) | +33 MHz | +v2 | +4 MB | +1 MB | +Z80 | +SPU, Yamaha YM2610B | +Mask ROM daughterboard | +
| Taito | +FX-1B (ZN-1 + custom addon board) | +33 MHz | +v2 | +4 MB | +1 MB | ++ | SPU, custom Zoom DSP | +Mask ROM daughterboard | +
| Taito | +G-NET (ZN-2 + custom addon board) | +50 MHz | +v2b | +4 MB | +2 MB | +MN1020012A, TMS57002 | +SPU, custom Zoom DSP | +8 MB flash, custom encrypted PCMCIA/CF card | +
The following boards were mentioned in the original nocash page, but almost +nothing is known about them:
+Currently only documentation for the System 573 exists. More information about +other arcade boards could be obtained from MAME source code.
+Most boards use the same CPUs as retail consoles and development units. The +System 10, System 12 and ZN-2 feature a later CPU revision that allows for up +to 16 MB main RAM (as opposed to 8 MB on the standard CPUs) and clock speeds of +up to 50 MHz. The bus interface and memory control registers on these chips may +behave differently from the ones found on standard CPUs due to the extended +address space.
+Most systems have a regular v2 GPU but expand VRAM to 2 MB, arranged as a +1024x1024 buffer rather than 1024x512. The Konami GQ and COH-100 (CPU + GPU +daughterboard used in early System 11 units) have the v1 "prototype" GPU, which +uses completely different commands from v0/v2 and is generally not compatible +with any known version of Sony's development tools. Most System 11 games seem to +support both GPU types.
+Some System 12 and ZN-2 variants use a later revision of the v2 GPU (v2b). The +differences between v2 and v2b GPUs are currently unknown.
+Almost all boards extend the SPU's functionality with additional hardware, +usually a custom fixed-function DSP and in some cases a separate sound CPU. The +custom audio hardware is typically on a separate board, with some systems +allowing it to be unplugged if the game does not require it. The Konami GQ, +System 11 (both COH-100 and COH-110 variants) and System 12 omit the SPU +entirely.
+Most systems are designed to be connected to a cabinet through a JAMMA board +edge connector, which carries power, a video output, player controls and +coin/service button inputs. These inputs are typically accessed via custom +memory-mapped I/O ports. As control schemes may vary greatly from game to game, +many systems also provide means to connect additional inputs or expansion +boards.
+Some boards feature a JVS port (a standardized serial bus protocol used to +connect controls and peripherals to modern arcade systems), allowing standard +JVS I/O boards to be used if supported by games.
+With the exception of Konami, all manufacturers used mask ROMs or flash memory +for game storage. The wiring and layout of the ROMs varies for each board; on +some systems the BIOS and game are part of the same ROM, while others have +separate BIOS and game ROMs. Graphical and audio assets may also be stored +separately or within the main game ROM.
+Konami systems store game executables and assets on standard SCSI/IDE hard +drives or CD-ROMs. The System 573 can also boot from its built-in flash or a +PCMCIA flash card, using the CD-ROM drive only to install new games, however +the vast majority of 573 games are too large to fit entirely in the flash and +still rely on reading files from the disc after installation. The Twinkle +System is particularly unusual as it has a CD-ROM drive accessed by the main +CPU, a separate hard drive used by the audio board and an external DVD player +unit for background videos.
+The System 10 and System 12 are the only known non-Konami boards with CD-ROM +support. The former can be connected directly to an ATAPI drive, while the +latter requires an expansion module that provides an IDE interface and XA-ADPCM +decoding through an integrated SH-2 CPU. Whether these boards support CD-ROM +booting without any game ROMs installed is currently unknown.
+The implementation of anti-piracy measures varies for each manufacturer.
+CDROM Controller Command Summary
+CDROM - Control Commands
+CDROM - Seek Commands
+CDROM - Read Commands
+CDROM - Status Commands
+CDROM - CD Audio Commands
+CDROM - Test Commands
+CDROM - Secret Unlock Commands
+CDROM - Video CD Commands
+CDROM - Mainloop/Responses
+CDROM - Response Timings
+CDROM - Response/Data Queueing
CDROM Disk Format
+CDROM Subchannels
+CDROM Sector Encoding
+CDROM Scrambling
+CDROM XA Subheader, File, Channel, Interleave
+CDROM XA Audio ADPCM Compression
+CDROM ISO Volume Descriptors
+CDROM ISO File and Directory Descriptors
+CDROM ISO Misc
+CDROM File Formats
+CDROM Video CDs (VCD)
CDROM Protection - SCEx Strings
+CDROM Protection - Bypassing it
+CDROM Protection - Modchips
+CDROM Protection - Chipless Modchips
+CDROM Protection - LibCrypt
CDROM Internal Info on PSX CDROM Controller
| + | 1F801800h | +1F801801h | +1F801802h | +1F801803h | +
|---|---|---|---|---|
| 0 | +Index/Status (RW) | +Response FIFO (R) (Mirror) Command Register (W) |
+Data FIFO (R) Parameter FIFO (W) |
+Interrupt Enable Register (R) Request Register (W) |
+
| 1 | +Index/Status (RW) | +Response FIFO (R) Sound Map Data Out (W) |
+Data FIFO (R) Interrupt Enable Register (W) |
+Interrupt Flag Register (RW) | +
| 2 | +Index/Status (RW) | +Response FIFO (R) (Mirror) Sound Map Coding Info (W) |
+Data FIFO (R) Left-CD to Left-SPU Volume (W) |
+Interrupt Enable Register (R) (Mirror) Left-CD to Right-SPU Volume (W) |
+
| 3 | +Index/Status (RW) | +Response FIFO (R) (Mirror) Right-CD to Right-SPU Volume (W) |
+Data FIFO (R) Right-CD to Left-SPU Volume (W) |
+Interrupt Flag Register (R) (Mirror) Audio Volume Apply Changes (W) |
+
0-1 Index Port 1F801801h-1F801803h index (0..3 = Index0..Index3) (R/W)
+ 2 ADPBUSY XA-ADPCM fifo empty (0=Empty) ;set when playing XA-ADPCM sound
+ 3 PRMEMPT Parameter fifo empty (1=Empty) ;triggered before writing 1st byte
+ 4 PRMWRDY Parameter fifo full (0=Full) ;triggered after writing 16 bytes
+ 5 RSLRRDY Response fifo empty (0=Empty) ;triggered after reading LAST byte
+ 6 DRQSTS Data fifo empty (0=Empty) ;triggered after reading LAST byte
+ 7 BUSYSTS Command/parameter transmission busy (1=Busy)
+ 0-7 Command Byte
+ 0-7 Parameter Byte(s) to be used for next Command
+ 0-4 0 Not used (should be zero)
+ 5 SMEN Want Command Start Interrupt on Next Command (0=No change, 1=Yes)
+ 6 BFWR ...
+ 7 BFRD Want Data (0=No/Reset Data Fifo, 1=Yes/Load Data Fifo)
+After ReadS/ReadN commands have generated INT1, software must set the Want Data
+bit (1F801803h.Index0.Bit7), then wait until Data Fifo becomes not empty
+(1F801800h.Bit6), the datablock (disk sector) can be then read from this
+register.
+
0-7 Data 8bit (one byte), or alternately,
+ 0-15 Data 16bit (LSB=First byte, MSB=Second byte)
+ 0-7 Response Byte(s) received after sending a Command
+ 0-4 Interrupt Enable Bits (usually all set, ie. 1Fh=Enable All IRQs)
+ 5-7 Unknown/unused (write: should be zero) (read: usually all bits set)
+ 0-2 Read: Response Received Write: 7=Acknowledge ;INT1..INT7
+ 3 Read: Unknown (usually 0) Write: 1=Acknowledge ;INT8 ;XXX CLRBFEMPT
+ 4 Read: Command Start Write: 1=Acknowledge ;INT10h;XXX CLRBFWRDY
+ 5 Read: Always 1 ;XXX "_" Write: 1=Unknown ;XXX SMADPCLR
+ 6 Read: Always 1 ;XXX "_" Write: 1=Reset Parameter Fifo ;XXX CLRPRM
+ 7 Read: Always 1 ;XXX "_" Write: 1=Unknown ;XXX CHPRST
+ INT0 No response received (no interrupt request)
+ INT1 Received SECOND (or further) response to ReadS/ReadN (and Play+Report)
+ INT2 Received SECOND response (to various commands)
+ INT3 Received FIRST response (to any command)
+ INT4 DataEnd (when Play/Forward reaches end of disk) (maybe also for Read?)
+ INT5 Received error-code (in FIRST or SECOND response)
+ INT5 also occurs on SECOND GetID response, on unlicensed disks
+ INT5 also occurs when opening the drive door (even if no command
+ was sent, ie. even if no read-command or other command is active)
+ INT6 N/A
+ INT7 N/A
+ INT8 Unknown (never seen that bit set yet)
+ INT10h Command Start (when INT10h requested via 1F801803h.Index0.Bit5)
+IRQ flag changes aren't synced with the MIPS CPU clock. If more than one bit
+gets set (and the CPU is reading at the same time) then the CPU does
+occassionally see only one of the newly bits:
+
0 ----------> 3 ;99.9% normal case INT3's
+ 0 ----------> 5 ;99% normal case INT5's
+ 0 ---> 1 ---> 3 ;0.1% glitch: occurs about once per thousands of INT3's
+ 0 ---> 4 ---> 5 ;1% glitch: occurs about once per hundreds of INT5's
+ @@polling_lop:
+ irq_flags = [1F801803h] AND 07h ;<-- 1st read (may be still unstable)
+ if irq_flags = 00h then goto @@polling_lop
+ irq_flags = [1F801803h] AND 07h ;<-- 2nd read (should be stable now)
+ handle irq_flags and acknowledge them
+Allows to configure the CD for mono/stereo output (eg. values "80h,0,80h,0"
+produce normal stereo volume, values "40h,40h,40h,40h" produce mono output of
+equivalent volume).
+When using bigger values, the hardware does have some incomplete saturation
+support; the saturation works up to double volume (eg. overflows that occur on
+"FFh,0,FFh,0" or "80h,80h,80h,80h" are clipped to min/max levels), however, the
+saturation does NOT work properly when exceeding double volume (eg. mono with
+quad-volume "FFh,FFh,FFh,FFh").
+
0-7 Volume Level (00h..FFh) (00h=Off, FFh=Max/Double, 80h=Default/Normal)
+ 0 ADPMUTE Mute ADPCM (0=Normal, 1=Mute)
+ 1-4 - Unused (should be zero)
+ 5 CHNGATV Apply Audio Volume changes (0=No change, 1=Apply)
+ 6-7 - Unused (should be zero)
+ 0-7 Data
+ 0 Mono/Stereo (0=Mono, 1=Stereo)
+ 1 Reserved (0)
+ 2 Sample Rate (0=37800Hz, 1=18900Hz)
+ 3 Reserved (0)
+ 4 Bits per Sample (0=4bit, 1=8bit)
+ 5 Reserved (0)
+ 6 Emphasis (0=Off, 1=Emphasis)
+ 7 Reserved (0)
+ =============================================================================
+Command/Parameter transmission is indicated by bit7 of 1F801800h.
+When that bit gets zero, the response can be read immediately (immediately for
+MOST commands, but not ALL commands; so better wait for the IRQ).
+Alternately, you can wait for an IRQ (which seems to take place MUCH later),
+and then read the response.
+If there are any pending cdrom interrupts, these MUST be acknowledged before
+sending the command (otherwise bit7 of 1F801800h will stay set forever).
Indicates ready-to-send-new-command,
+
0=Ready to send a new command
+ 1=Busy sending a command/parameters
+Pause -> Wait for INT3 IRQ -> clear IRQ (write 0x1f to 1f801803h.0) -> SetMode/Pause/Stop/SetMode/SeekL/... <br/>
+ReadN/ReadS -> Wait for INT3 IRQ -> clear IRQ (write 0x1f to 1f801803h.0) -> SetMode/SetLoc/... <br/>
+Stop -> Wait for INT3 IRQ -> clear IRQ (write 0x1f to 1f801803h.0) -> SetMode/Pause/...<br/>
+Trying to do a 32bit read from 1F801800h returns the 8bit value at 1F801800h
+multiplied by 01010101h.
-Flush all IRQs
+ -1F801803h.Index0=0
+ -Com_Delay=4901 (=1325h) (Port 1F801020h) (means 16bit or 32bit write?)
+ (the write seems to be 32bit, clearing the upper16bit of the register)
+ -Send two Getstat commands
+ -Send Command 0Ah (Init)
+ -Demute
+Warning: most or all of the info in the sentence below appear to incorrect
+(either that, or I didn't understand that rather confusing sentence).
+REPORTEDLY:
+"You should not send some commands while the CD is seeking (ie. Getstat returns
+with bit6 set). Thing is that stat only gets updated after a new command. I
+haven't tested this for other command, but for the play command (03h) you can
+just keep repeating the [which?] command and checking stat returned by that,
+for bit6 to go low (and bit7 to go high in this case). If you don't and try to
+do a getloc [GetlocP and/or GetlocL?] directly after the play command reports
+it's done [what done? meaning sending start-to-play was "done"? or meaning play
+reached end-of-disc?], the CD will stop. (I guess the CD can't get it's current
+location while it's seeking, so the logic stops the seek to get an exact fix,
+but never restarts..)"
Sound Map mode allows to output XA-ADPCM from Main RAM (rather than from
+CDROM).
+
SPU: Init Master Volume Left/Right (Port 1F801D80h/1F801D82h)
+ SPU: Init CD Audio Volume Left/Right (Port 1F801DB0h/1F801DB2h)
+ SPU: Enable CD Audio (Port 1F801DAAh.Bit0=1)
+ CDROM/CMD: send Stop command (probably better to avoid conflicts)
+ CDROM/CMD: send Demute command (if muted) (but works only if disc inserted)
+ CDROM/HOST: init Codinginfo (Port 1F801801h.Index2)
+ CDROM/HOST: enable ADPCM (Port 1F801803h.Index3.Bit0=0) ;probably needed?
+ ... set dummy addr/len with DISHXFRC=1 ? <-- NOT required !
+ ... set SMEN ... and dummy BFWR? <-- BOTH bits required ?
+ ... maybe SMADPCLR (1F801803h.Index1.bit5) does clear SoundMap ADPCM buf?
+ transfer 900h bytes (same format as ADPCM sectors) (Port 1F801801h.Index1)
+ Note: Before sending a byte, one should wait for DRQs (1F801801h.Bit6=1)
+ Note: ADPCM output doesn't start until the last (900h'th) byte is transferred
+ Command Parameters Response(s)
+ 00h - - INT5(11h,40h) ;reportedly "Sync" uh?
+ 01h Getstat - INT3(stat)
+ 02h Setloc E amm,ass,asect INT3(stat)
+ 03h Play E (track) INT3(stat), optional INT1(report bytes)
+ 04h Forward E - INT3(stat), optional INT1(report bytes)
+ 05h Backward E - INT3(stat), optional INT1(report bytes)
+ 06h ReadN E - INT3(stat), INT1(stat), datablock
+ 07h MotorOn E - INT3(stat), INT2(stat)
+ 08h Stop E - INT3(stat), INT2(stat)
+ 09h Pause E - INT3(stat), INT2(stat)
+ 0Ah Init - INT3(late-stat), INT2(stat)
+ 0Bh Mute E - INT3(stat)
+ 0Ch Demute E - INT3(stat)
+ 0Dh Setfilter E file,channel INT3(stat)
+ 0Eh Setmode mode INT3(stat)
+ 0Fh Getparam - INT3(stat,mode,null,file,channel)
+ 10h GetlocL E - INT3(amm,ass,asect,mode,file,channel,sm,ci)
+ 11h GetlocP E - INT3(track,index,mm,ss,sect,amm,ass,asect)
+ 12h SetSession E session INT3(stat), INT2(stat)
+ 13h GetTN E - INT3(stat,first,last) ;BCD
+ 14h GetTD E track (BCD) INT3(stat,mm,ss) ;BCD
+ 15h SeekL E - INT3(stat), INT2(stat) ;\use prior Setloc
+ 16h SeekP E - INT3(stat), INT2(stat) ;/to set target
+ 17h - - INT5(11h,40h) ;reportedly "SetClock" uh?
+ 18h - - INT5(11h,40h) ;reportedly "GetClock" uh?
+ 19h Test sub_function depends on sub_function (see below)
+ 1Ah GetID E - INT3(stat), INT2/5(stat,flg,typ,atip,"SCEx")
+ 1Bh ReadS E?- INT3(stat), INT1(stat), datablock
+ 1Ch Reset - INT3(stat), Delay ;-not DTL-H2000
+ 1Dh GetQ E adr,point INT3(stat), INT2(10bytesSubQ,peak_lo) ;\not
+ 1Eh ReadTOC - INT3(late-stat), INT2(stat) ;/vC0
+ 1Fh VideoCD sub,a,b,c,d,e INT3(stat,a,b,c,d,e) ;<-- SCPH-5903 only
+ 1Fh..4Fh - - INT5(11h,40h) ;-Unused/invalid
+ 50h Secret 1 - INT5(11h,40h) ;\
+ 51h Secret 2 "Licensed by" INT5(11h,40h) ;
+ 52h Secret 3 "Sony" INT5(11h,40h) ; Secret Unlock Commands
+ 53h Secret 4 "Computer" INT5(11h,40h) ; (not in version vC0, and,
+ 54h Secret 5 "Entertainment" INT5(11h,40h) ; nonfunctional in japan)
+ 55h Secret 6 "<region>" INT5(11h,40h) ;
+ 56h Secret 7 - INT5(11h,40h) ;/
+ 57h SecretLock - INT5(11h,40h) ;-Secret Lock Command
+ 58h..5Fh Crash - Crashes the HC05 (jumps into a data area)
+ 6Fh..FFh - - INT5(11h,40h) ;-Unused/invalid
+Test commands are invoked with command number 19h, followed by a sub_function
+number as first parameter byte. The Kernel seems to be using only sub_function
+20h (to detect the CDROM Controller version).
+
sub params response ;Effect
+ 00h - INT3(stat) ;Force motor on, clockwise, even if door open
+ 01h - INT3(stat) ;Force motor on, anti-clockwise, super-fast
+ 02h - INT3(stat) ;Force motor on, anti-clockwise, super-fast
+ 03h - INT3(stat) ;Force motor off (ignored during spin-up)
+ 04h - INT3(stat) ;Start SCEx reading and reset counters
+ 05h - INT3(total,success);Stop SCEx reading and get counters
+ 06h * n INT3(old) ;\early ;Adjust balance in RAM, send CX(30+n XOR 7)
+ 07h * n INT3(old) ; PSX ;Adjust gain in RAM, send CX(38+n XOR 7)
+ 08h * n INT3(old) ;/only ;Adjust balance in RAM only
+ 06h..0Fh - INT5(11h,10h) ;N/A (11h,20h when NONZERO number of params)
+ 10h - INT3(stat) ;CX(..) ;Force motor on, anti-clockwise, super-fast
+ 11h - INT3(stat) ;CX(03) ;Move Lens Up (leave parking position)
+ 12h - INT3(stat) ;CX(02) ;Move Lens Down (enter parking position)
+ 13h - INT3(stat) ;CX(28) ;Move Lens Outwards
+ 14h - INT3(stat) ;CX(2C) ;Move Lens Inwards
+ 15h - INT3(stat) ;CX(22) ;If motor on: Move outwards,inwards,motor off
+ 16h - INT3(stat) ;CX(23) ;No effect?
+ 17h - INT3(stat) ;CX(E8) ;Force motor on, clockwise, super-fast
+ 18h - INT3(stat) ;CX(EA) ;Force motor on, anti-clockwise, super-fast
+ 19h - INT3(stat) ;CX(25) ;No effect?
+ 1Ah - INT3(stat) ;CX(21) ;No effect?
+ 1Bh..1Fh - INT5(11h,10h) ;N/A (11h,20h when NONZERO number of params)
+ 20h - INT3(yy,mm,dd,ver) ;Get cdrom BIOS date/version (yy,mm,dd,ver)
+ 21h - INT3(n) ;Get Drive Switches (bit0=POS0, bit1=DOOR)
+ 22h *** - INT3("for ...") ;Get Region ID String
+ 23h *** - INT3("CXD...") ;Get Chip ID String for Servo Amplifier
+ 24h *** - INT3("CXD...") ;Get Chip ID String for Signal Processor
+ 25h *** - INT3("CXD...") ;Get Chip ID String for Decoder/FIFO
+ 26h..2Fh - INT5(11h,10h) ;N/A (11h,20h when NONZERO number of params)
+ 30h * i,x,y INT3(stat) ;Prototype/Debug stuff ;\supported on
+ 31h * x,y INT3(stat) ;Prototype/Debug stuff ; early PSX only
+ 4xh * i INT3(x,y) ;Prototype/Debug stuff ;/
+ 30h..4Fh .. INT5(11h,10h) ;N/A always 11h,10h (no matter of params)
+ 50h a[,b[,c]] INT3(stat) ;Servo/Signal send CX(a:b:c)
+ 51h ** 39h,xx INT3(stat,hi,lo) ;Servo/Signal send CX(39xx) with response
+ 51h..5Fh - INT5(11h,10h) ;N/A
+ 60h lo,hi INT3(databyte) ;HC05 SUB-CPU read RAM and I/O ports
+ 61h..70h - INT5(11h,10h) ;N/A
+ 71h *** adr INT3(databyte) ;Decoder Read one register
+ 72h *** adr,dat INT3(stat) ;Decoder Write one register
+ 73h *** adr,len INT3(databytes..);Decoder Read multiple registers, bugged
+ 74h *** adr,len,..INT3(stat) ;Decoder Write multiple registers, bugged
+ 75h *** - INT3(lo,hi,lo,hi);Decoder Get Host Xfer Info Remain/Addr
+ 76h *** a,b,c,d INT3(stat) ;Decoder Prepare Transfer to/from SRAM
+ 77h..FFh - INT5(11h,10h) ;N/A
+ 80h..8Fh a,b ? ;seem to do something on PS2
+INT5 will be returned if the command is unsupported. That, WITHOUT removing the
+Parameters from the FIFO, so the parameters will be accidently passed to the
+NEXT command. To avoid that: clear the parameter FIFO via
+[1F801803h.Index1]=40h after receiving the INT5 error.
Reportedly "command does not succeed until all other commands complete. This
+can be used for synchronization - hence the name."
+Uh, actually, returns error code 40h = Invalid Command...?
Automatic ADPCM (CD-ROM XA) filter ignores sectors except those which have the
+same channel and file numbers in their subheader. This is the mechanism used to
+select which of multiple songs in a single .XA file to play.
+Setfilter does not affect actual reading (sector reads still occur for all
+sectors).
+XXX err... that is... does not affect reading of non-ADPCM sectors (normal
+"data" sectors are kept received regardless of Setfilter).
7 Speed (0=Normal speed, 1=Double speed)
+ 6 XA-ADPCM (0=Off, 1=Send XA-ADPCM sectors to SPU Audio Input)
+ 5 Sector Size (0=800h=DataOnly, 1=924h=WholeSectorExceptSyncBytes)
+ 4 Ignore Bit (0=Normal, 1=Ignore Sector Size and Setloc position)
+ 3 XA-Filter (0=Off, 1=Process only XA-ADPCM sectors that match Setfilter)
+ 2 Report (0=Off, 1=Enable Report-Interrupts for Audio Play)
+ 1 AutoPause (0=Off, 1=Auto Pause upon End of Track) ;for Audio Play
+ 0 CDDA (0=Off, 1=Allow to Read CD-DA Sectors; ignore missing EDC)
+Multiple effects at once. Sets mode=20h, activates drive motor, Standby, abort
+all commands.
Caution: Not supported on DTL-H2000 (v01)
+Activates the drive motor, works ONLY if the motor was off (otherwise fails
+with INT5(stat,20h); that error code would normally indicate "wrong number of
+parameters", but means "motor already on" in this case).
+Commands like Read, Seek, and Play are automatically starting the Motor when
+needed (which makes the MotorOn command rather useless, and it's rarely used by
+any games).
+Myth: Older homebrew docs are referring to MotorOn as "Standby", claiming that
+it would work similar as "Pause", that is wrong: the command does NOT pause
+anything (if the motor is on, then it does simply trigger INT5, but without
+pausing reading or playing).
+Note: The game "Nightmare Creatures 2" does actually attempt to use MotorOn to
+"pause" after reading files, but the hardware does simply ignore that attempt
+(aside from doing the INT5 thing).
Stops motor with magnetic brakes (stops within a second or so) (unlike
+power-off where it'd keep spinning for about 10 seconds), and moves the drive
+head to the begin of the first track. Official way to restart is command 0Ah,
+but almost any command will restart it.
+The first response returns the current status (this already with bit5 cleared),
+the second response returns the new status (with bit1 cleared).
Aborts Reading and Playing, the motor is kept spinning, and the drive head
+maintains the current location within reasonable error.
+The first response returns the current status (still with bit5 set if a Read
+command was active), the second response returns the new status (with bit5
+cleared).
The PSX CDROM BIOS is first trying to send sectors to the ADPCM decoder, and,
+if that didn't work out, then it's trying to send them to the main CPU (and if
+that didn't work out either, then it's silently ignoring the sector).
+
try_deliver_as_adpcm_sector:
+ reject if CD-DA AUDIO format
+ reject if sector isn't MODE2 format
+ reject if adpcm_disabled(setmode.6)
+ reject if filter_enabled(setmode.3) AND selected file/channel doesn't match
+ reject if submode isn't audio+realtime (bit2 and bit6 must be both set)
+ deliver: send sector to xa-adpcm decoder when passing above cases
+ try_deliver_as_data_sector:
+ reject data-delivery if "try_deliver_as_adpcm_sector" did do adpcm-delivery
+ reject if filter_enabled(setmode.3) AND submode is audio+realtime (bit2+bit6)
+ 1st delivery attempt: send INT1+data, unless there's another INT pending
+ delay, and retry at later time... but this time with file/channel checking!
+ reject if filter_enabled(setmode.3) AND selected file/channel doesn't match
+ 2nd delivery attempt: send INT1+data, unless there's another INT pending
+Sets the seek target - but without yet starting the seek operation. The actual
+seek is invoked by certain commands: SeekL (Data) and SeekP (Audio) are doing
+plain seeks (and do Pause after completion). ReadN/ReadS are similar to SeekL
+(and do start reading data after the seek operation). Play is similar to SeekP
+(and does start playing audio after the seek operation).
+The amm,ass,asect parameters refer to the entire disk (not to the current
+track). To seek to a specific location within a specific track, use GetTD to
+get the start address of the track, and add the desired time offset to it.
Seek to Setloc's location in data mode (using data sector header position data,
+which works/exists only on Data tracks, not on CD-DA Audio tracks).
+After the seek, the disk stays on the seeked location forever (namely: when
+seeking sector N, it does stay at around N-8..N-0 in single speed mode, or at
+around N-5..N+2 in double speed mode). This command will stop any current or pending ReadN or ReadS.
+Trying to use SeekL on Audio CDs passes okay on the first response, but (after
+two seconds or so) the second response will return an error (stat+4,04h), and
+stop the drive motor... that error doesn't appear ALWAYS though... works in
+some situations... such like when previously reading data sectors or so...?
Seek to Setloc's location in audio mode (using the Subchannel Q position data,
+which works on both Audio on Data disks).
+After the seek, the disk stays on the seeked location forever (namely: when
+seeking sector N, it does stay at around N-9..N-1 in single speed mode, or at
+around N-2..N in double speed mode). This command will stop any current or pending ReadN or ReadS.
+Note: Some older docs claim that SeekP would recurse only "MM:SS" of the
+"MM:SS:FF" position from Setloc - that is wrong, it does seek to MM:SS:FF
+(verified on a PSone).
+After the seek, status is stat.bit7=0 (ie. audio playback off), until sending a
+new Play command (without parameters) to start playback at the seeked location.
Seeks to session (ie. moves the drive head to the session, with stat bit6 set
+during the seek phase).
+When issued during active-play, the command returns error code 80h.
+When issued during play-spin-up, play is aborted.
+
___Errors___
+ session = 00h causes error code 10h. ;INT5(03h,10h), no 2nd/3rd response
+ ___On a non-multisession-disk___
+ session = 01h passes okay. ;INT3(stat), and once INT2(stat)
+ session = 02h or higher cause seek error ;INT3(stat), and twice INT5(06h,40h)
+ ___On a multisession-disk with N sessions___
+ session = 01h..N+1 passes okay ;where N+1 moves to the END of LAST session
+ session = N+2 or higher cause seek error ;2nd response = INT5(06h,20h)
+Read with retry. The command responds once with "stat,INT3", and then it's
+repeatedly sending "stat,INT1 --> datablock", that is continued even after a
+successful read has occured; use the Pause command to terminate the repeated
+INT1 responses.
+Unknown which responses are sent in case of read errors?
+====
+ReadN and ReadS cause errors if you're trying to read an unlicensed CD or CD-R
+without a mod chip. Sectors on Audio CDs can be read only when CDDA is enabled
+via Setmode (otherwise error code 40h is returned).
+====
+Actually, Read seems to work on unlicensed CD-R's, but the returned data is the
+whole sector or so (the 2048 data bytes preceeded by a 12byte header, and
+probably/maybe followed by error-correction info; in fact the total received
+data in the Data Fifo is 4096 bytes; the last some bytes probably being
+garbage) (however error correction is NOT performed by hardware, so the 2048
+data bytes may be trashy) (however, if the error correction info IS received,
+then error correction could be performed by software) (also Setloc doesn't seem
+to work accurately on unlicensed CD-R's).
+====
+
;Read occasionally returns 11h,40h ..? when TOC isn't loaded?
+ [1F801800h]=00h
+ 00h=[1F801800h]
+ [1F801803h]=00h
+ 00h=[1F801803h]
+ [1F801800h]=00h
+ [1F801803h]=80h
+ [1F801018h]=00020943h ;cdrom_delay
+ [1F801020h]=0000132Ch ;com_delay
+ x=[1F8010F4h] AND 00FFFFFFh ;result is 00840000h
+ [1F8010F4h] = x OR 00880000h
+ [1F8010F0h] = [1F8010F0h] OR 00008000h
+ [1F8010B0h] = A0010000h ;addr
+ [1F8010B4h] = 00010200h ;LSBs=num words, MSBs=ignored/bullshit
+ [1F8010B4h] = 11000000h ;DMA control
+ [1F801800h]=01h
+ [1F801803h]=40h ;reset parameter fifo
+ [0]=00000000h
+ [0]=00000001h
+ [0]=00000002h
+ [0]=00000003h
+ [1F801800h]=00h
+ [1F801801h]=09h ;command9 (pause)
+Read without automatic retry. Not sure what that means... does WHAT on errors?
+Maybe intended for continous streaming video output (to skip bad frames, rather
+than to interrupt the stream by performing read-retrys).
Both ReadN/ReadS are reading data sequentially, starting at the sector
+specified with Setloc, and then automatically reading the following sectors.
The Read commands are continously receiving 75 sectors per second (or 150
+sectors at double speed), and, basically, the software must be fast enough to
+process that amount of incoming data. However, the PSX hardware includes a
+buffer that can hold up to a handful (exact number is unknown?) of sectors, so,
+occasional delays of more than 1/75 seconds between processing two sectors
+aren't causing lost sectors, unless the delay(s) are summing up too much. The
+relevant steps for receiving data are:
+
Wait for Interrupt Request (INT1) ;indicates that data is available
+ Send Data Request (1F801803h.Index0.Bit7=1);accept data
+ Acknowledge INT1 ;
+ Copy Data to Main RAM (via I/O or DMA) ;read data
+ Caution: Supported only in BIOS version vC1 and up. Not supported in vC0.
+A normal CDROM access (such like reading a file) consists of three commands:
+
Setloc, Read, Pause
+The 8bit status code is returned by Getstat command (and many other commands),
+the meaning of the separate stat bits is:
+
7 Play Playing CD-DA ;\only ONE of these bits can be set
+ 6 Seek Seeking ; at a time (ie. Read/Play won't get
+ 5 Read Reading data sectors ;/set until after Seek completion)
+ 4 ShellOpen Once shell open (0=Closed, 1=Is/was Open)
+ 3 IdError (0=Okay, 1=GetID denied) (also set when Setmode.Bit4=1)
+ 2 SeekError (0=Okay, 1=Seek error) (followed by Error Byte)
+ 1 Spindle Motor (0=Motor off, or in spin-up phase, 1=Motor on)
+ 0 Error Invalid Command/parameters (followed by Error Byte)
+ ___These values appear in the FIRST response; with stat.bit0 set___
+ 10h - Invalid Sub_function (for command 19h), or invalid parameter value
+ 20h - Wrong number of parameters
+ 40h - Invalid command
+ 80h - Cannot respond yet (eg. required info was not yet read from disk yet)
+ (namely, TOC not-yet-read or so)
+ (also appears if no disk inserted at all)
+ ___These values appear in the SECOND response; with stat.bit2 set___
+ 04h - Seek failed (when trying to use SeekL on Audio CDs)
+ ___These values appear even if no command was sent; with stat.bit2 set___
+ 08h - Drive door became opened
+When the shell is opened, INT5 is triggered regardless of whether a command was
+executing or not. When this happens, all bits except shell open and error are cleared
+in the status register. The error byte in the INT5 is set to 08h.
Some games send a Stop command before changing discs, but others just wait for the
+user to open the shell, causing the disc to stop. The game can then send GetStat commands,
+looping until bit 4 is cleared to detect when the new disc has been inserted.
There's is only max ONE of the three Seek/Play/Read bits set at a time, ie.
+during Seek, ONLY the seek bit is set (and Read or Play doesn't get until seek
+completion), that is important for Gran Turismo 1, which checks for seek
+completion by waiting for READ getting set (rather than waiting for SEEK
+getting cleared).
Returns stat (like many other commands), and additionally does reset the shell
+open flag (for the following commands; unless the shell is still opened). This
+is different as for most or all other commands (which may return stat, but
+which do not reset the shell open flag).
+In other docs, the command is eventually referred to as "Nop", believing that
+it does nothing than returning stat (ignoring the fact that it's having the
+special shell open reset feature).
Returns stat (see Getstat above), mode (see Setmode), a null byte (always 00h),
+and file/channel filter values (see Setfilter).
Retrieves 4-byte sector header, plus 4-byte subheader of the current sector.
+GetlocL can be send during active Read commands (but, mind that the
+GetlocL-INT3-response can't be received until any pending Read-INT1's are
+acknowledged).
+The PSX hardware can buffer a handful of sectors, the INT1 handler receives the
+\<oldest> buffered sector, the GetlocL command returns the header and
+subheader of the \<newest> buffered sector. Note: If the returned
+\<newest> sector number is much bigger than the expected \<oldest>
+sector number, then it's likely that a buffer overrun has occured.
+GetlocL fails (with error code 80h) when playing Audio CDs (or Audio Tracks on
+Data CDs). These errors occur because Audio sectors don't have any
+header/subheader (instead, equivalent data is stored in Subchannel Q, which can
+be read with GetlocP).
+GetlocL also fails (with error code 80h) when the drive is in Seek phase (such
+like shortly after a new ReadN/ReadS command). In that case one can retry
+issuing GetlocL (until it passes okay, ie. until the seek has completed).
+During Seek, the drive seems to decode only Subchannel position data (but no
+header/subheader data), accordingly GetlocL won't work during seek (however,
+GetlocP does work during Seek).
Retrieves 8 bytes of position information from Subchannel Q with ADR=1. Mainly
+intended for displaying the current audio position during Play. All results are
+in BCD.
+
track: track number (AAh=Lead-out area) (FFh=unknown, toc, none?)
+ index: index number (Usually 01h)
+ mm: minute number within track (00h and up)
+ ss: second number within track (00h to 59h)
+ sect: sector number within track (00h to 74h)
+ amm: minute number on entire disk (00h and up)
+ ass: second number on entire disk (00h to 59h)
+ asect: sector number on entire disk (00h to 74h)
+Get first track number, and last track number in the TOC of the current
+Session. The number of tracks in the current session can be calculated as
+(last-first+1). The first track number is usually 01h in the first (or only)
+session, and "last track of previous session plus 1" in further sessions.
For a disk with NN tracks, parameter values 01h..NNh return the start of the
+specified track, parameter value 00h returns the end of the last track, and
+parameter values bigger than NNh return error code 10h.
+The GetTD values are relative to Index=1 and are rounded down to second
+boundaries (eg. if track=N Index=0 starts at 12:34:56, and Track=N Index=1
+starts at 12:36:56, then GetTD(N) will return 12:36, ie. the sector number is
+truncated, and the Index=0 region is skipped).
Caution: Supported only in BIOS version vC1 and up. Not supported in vC0.
+ Caution: When unsupported, Parameter Fifo isn't cleared after the command.
+ Drive Status 1st Response 2nd Response
+ Door Open INT5(11h,80h) N/A
+ Spin-up INT5(01h,80h) N/A
+ Detect busy INT5(03h,80h) N/A
+ No Disk INT3(stat) INT5(08h,40h, 00h,00h, 00h,00h,00h,00h)
+ Audio Disk INT3(stat) INT5(0Ah,90h, 00h,00h, 00h,00h,00h,00h)
+ Unlicensed:Mode1 INT3(stat) INT5(0Ah,80h, 00h,00h, 00h,00h,00h,00h)
+ Unlicensed:Mode2 INT3(stat) INT5(0Ah,80h, 20h,00h, 00h,00h,00h,00h)
+ Unlicensed:Mode2+Audio INT3(stat) INT5(0Ah,90h, 20h,00h, 00h,00h,00h,00h)
+ Debug/Yaroze:Mode2 INT3(stat) INT2(02h,00h, 20h,00h, 20h,20h,20h,20h)
+ Licensed:Mode2 INT3(stat) INT2(02h,00h, 20h,00h, 53h,43h,45h,4xh)
+ Modchip:Audio/Mode1 INT3(stat) INT2(02h,00h, 00h,00h, 53h,43h,45h,4xh)
+ 1st byte: stat (as usually, but with bit3 same as bit7 in 2nd byte)
+ 2nd byte: flags (bit7=denied, bit4=audio... or reportedly import, uh?)
+ bit7: Licensed (0=Licensed Data CD, 1=Denied Data CD or Audio CD)
+ bit6: Missing (0=Disk Present, 1=Disk Missing)
+ bit4: Audio CD (0=Data CD, 1=Audio CD) (always 0 when Modchip installed)
+ 3rd byte: Disk type (from TOC Point=A0h) (eg. 00h=Audio or Mode1, 20h=Mode2)
+ 4th byte: Usually 00h (or 8bit ATIP from Point=C0h, if session info exists)
+ that 8bit ATIP value is taken form the middle 8bit of the 24bit ATIP value
+ 5th-8th byte: SCEx region (eg. ASCII "SCEE" = Europe) (0,0,0,0 = Unlicensed)
+To play CD-DA Audio CDs, init the following SPU Registers: CD Audio Volume,
+Main Volume, and SPU Control Bit0. Then send Demute command, and Play command.
Turn off audio streaming to SPU (affects both CD-DA and XA-ADPCM).
+Even when muted, the CDROM controller is internally processing audio sectors
+(as seen in 1F801800h.Bit2, which works as usually for XA-ADPCM), muting is
+just forcing the CD output volume to zero.
+Mute is used by Dino Crisis 1 to mute noise during modchip detection.
Turn on audio streaming to SPU (affects both CD-DA and XA-ADPCM). The Demute
+command is needed only if one has formerly used the Mute command (by default,
+the PSX is demuted after power-up (...and/or after Init command?), and is
+demuted after cdrom-booting).
Starts CD Audio Playback. The parameter is optional, if there's no parameter
+given (or if it is 00h), then play either starts at Setloc position (if there
+was a pending unprocessed Setloc), or otherwise starts at the current location
+(eg. the last point seeked, or the current location of the current song; if it
+was already playing). For a disk with N songs, Parameters 1..N are starting the
+selected track. Parameters N+1..99h are restarting the begin of current track.
+The motor is switched off automatically when Play reaches the end of the disk,
+and INT4(stat) is generated (with stat.bit7 cleared).
+The track parameter seems to be ignored when sending Play shortly after
+power-up (ie. when the drive hasn't yet read the TOC).
+===
+"Play is almost identical to CdlReadS, believe it or not. The main difference
+is that this does not trigger a completed read IRQ. CdlPlay may be used on data
+sectors. However, all sectors from data tracks are treated as 00, so no sound
+is played. As CdlPlay is reading, the audio data appears in the sector buffer,
+but is not reliable. Game Shark "enhancement CDs" for the 2.x and 3.x versions
+used this to get around the PSX copy protection."
+Hmmm, what/where is the sector buffer... in the SPU?
+And, what/who are the 2.x and 3.x versions?
After sending the command, the drive is in fast forward/backward mode, skipping
+every some sectors. The skipping rate is fixed (it doesn't increase after some
+seconds) (however, it increases when (as long as) sending the command again and
+again). The sound becomes (obviously) non-continous, and also rather very
+silent, muffled, and almost inaudible (that's making it rather useless; unless
+it's combined with a track/minute/second display). To terminate
+forward/backward, send a new Play command (with no parameters, so play starts
+at the "searched" location). Backward automatically switches to Play when
+reaching the begin of Track 1. Forward automatically Stops the drive motor with
+INT4(stat) when reaching the end of the last track.
+Forward/Backwards work only if the drive was in Play state, and only if Play
+had already started (ie. not shortly/immediately after a Play command); if the
+drive was not in Play state, then INT5(stat+1,80h) occurs.
During Play, only bit 7,2,1 of Setmode are used, all other Setmode bits are
+ignored (that, including bit0, ie. during Play the drive is always in CD-DA
+mode, regardless of that bit).
+Bit7 (double speed) should be usually off, although it can be used for a fast
+forward effect (with audible output). Bit2 (report) activates an optional
+interrupt for Play, Forward, and Backward commands (see below). Bit1
+(autopause) pauses play at the end of the track.
With report enabled via Setmode, the Play, Forward, and Backward commands do
+repeatedly generate INT1 interrupts, with eight bytes response length. The
+interrupt isn't generated on ALL sectors, and the response changes between
+absolute time, and time within current track (the latter one indicated by bit7
+of ss):
+
amm/ass/asect are returned on asect=00h,20h,40h,60h ;-absolute time
+ mm/ss+80h/sect are returned on asect=10h,30h,50h,70h ;-within current track
+ (or, in case of read errors, report may be returned on other asect's)
+Autopause can be enabled/disabled via Setmode.bit1:
+
Setmode.bit1=1: AutoPause=On --> Issue INT4(stat) and PAUSE at end of TRACK
+ Setmode.bit1=0: AutoPause=Off --> Issue INT4(stat) and STOP at end of DISC
+Aside from normal uncompressed CD Audio disks, the PSX can also play XA-ADPCM
+compressed sectors. XA-ADPCM sectors are organized in Files (not in tracks),
+and are "played" with Read command (not Play command).
+To play XA-ADPCM, initialize the SPU for CD Audio input (as described above),
+enable ADPCM via Setmode, then select the sector via Setloc, and issue a Read
+command (typically ReadS).
+XA-ADPCM sectors are interleaved, ie. only each Nth sector should be played
+(where "N" depends on the Motor Speed, mono/stereo format, and sample rate). If
+the "other" sectors do contain XA-ADPCM data too, then the Setfilter command
+(and XA-Filter enable flag in Setmode) must be used to select the desired
+sectors. If the "other" sectors do contain code or data (eg. MDEC video data)
+which is wanted to be send to the CPU, then SetFilter isn't required to be
+enabled (although it shouldn't disturb reading even if it is enabled).
+If XA-ADPCM (and/or XA-Filter) is enabled via Setmode, then INT1 is generated
+only for non-ADPCM sectors.
+The Setmode sector-size selection is don't care for forwarding XA-ADPCM sectors
+to the SPU (the hardware does always decompress all 900h bytes).
CDROM - Test Commands - Version, Switches, Region, Chipset, SCEx
+CDROM - Test Commands - Test Drive Mechanics
+CDROM - Test Commands - Prototype Debug Transmission
+CDROM - Test Commands - Read/Write Decoder RAM and I/O Ports
+CDROM - Test Commands - Read HC05 SUB-CPU RAM and I/O Ports
Indicates the date (Year-month-day, in BCD format) and version of the HC05
+CDROM controller BIOS. Known/existing values are:
+
(unknown) ;DTL-H2000 (with SPC700 instead HC05)
+ 94h,09h,19h,C0h ;PSX (PU-7) 19 Sep 1994, version vC0 (a)
+ 94h,11h,18h,C0h ;PSX (PU-7) 18 Nov 1994, version vC0 (b)
+ 94h,11h,28h,01h ;PSX (DTL-H2000) 28 Nov 1994, version v01 (debug)
+ 95h,05h,16h,C1h ;PSX (LATE-PU-8) 16 May 1995, version vC1 (a)
+ 95h,07h,24h,C1h ;PSX (LATE-PU-8) 24 Jul 1995, version vC1 (b)
+ 95h,07h,24h,D1h ;PSX (LATE-PU-8,debug ver)24 Jul 1995, version vD1 (debug)
+ 96h,08h,15h,C2h ;PSX (PU-16, Video CD) 15 Aug 1996, version vC2 (VCD)
+ 96h,08h,18h,C1h ;PSX (LATE-PU-8,yaroze) 18 Aug 1996, version vC1 (yaroze)
+ 96h,09h,12h,C2h ;PSX (PU-18) (japan) 12 Sep 1996, version vC2 (a.jap)
+ 97h,01h,10h,C2h ;PSX (PU-18) (us/eur) 10 Jan 1997, version vC2 (a)
+ 97h,08h,14h,C2h ;PSX (PU-20) 14 Aug 1997, version vC2 (b)
+ 98h,06h,10h,C3h ;PSX (PU-22) 10 Jun 1998, version vC3 (a)
+ 99h,02h,01h,C3h ;PSX/PSone (PU-23, PM-41) 01 Feb 1999, version vC3 (b)
+ A1h,03h,06h,C3h ;PSone/late (PM-41(2)) 06 Jun 2001, version vC3 (c)
+ (unknown) ;PS2, xx xxx xxxx, late PS2 models...?
+Returns the current status of the POS0 and DOOR switches.
+
Bit0 = HeadIsAtPos0 (0=No, 1=Pos0)
+ Bit1 = DoorIsOpen (0=No, 1=Open)
+ Bit2 = EjectButtonOrOutSwOrSo? (DTL-H2000 only) (always 0 on retail)
+ Bit3-7 = AlwaysZero
+ Caution: Supported only in BIOS version vC1 and up. Not supported in vC0.
+ INT5(11h,10h) --> NTSC, Japan (vC0) --> requires "SCEI" discs
+ INT3("for Europe") --> PAL, Europe --> requires "SCEE" discs
+ INT3("for U/C") --> NTSC, North America --> requires "SCEA" discs
+ INT3("for Japan") --> NTSC, Japan / NTSC, Asia --> requires "SCEI" discs
+ INT3("for NETNA") --> Region-free yaroze version--> requires "SCEx" discs
+ INT3("for US/AEP") --> Region-free debug version --> accepts unlicensed CDRs
+ Caution: Supported only in BIOS version vC1 and up. Not supported in vC0.
+Resets the total/success counters to zero, and does then try to read the SCEx
+string from the current location (the SCEx is stored only in the Lead-In area,
+so, if the drive head is elsewhere, it will usually not find any strings,
+unless a modchip is permanently simulating SCEx strings).
+This is a raw test command (the successful or unsuccessful results do not
+lock/unlock the disk). The results can be read with command 19h,05h (which will
+terminate the SCEx reading), or they can be read from RAM with command
+19h,60h,lo,hi (which doesn't stop reading). Wait 1-2 seconds before expecting
+any results.
+Note: Like 19h,00h, this command forces the drive motor to spin at standard
+speed (synchronized with the data on the disk), works even if the shell is open
+(but stops spinning after a while if the drive is empty).
Returns the total number of "Sxxx" strings received (where at least the first
+byte did match), and the number of full "SCEx" strings (where all bytes did
+match). Typically, the values are "01h,01h" for Licensed PSX Data CDs, or
+"00h,00h" for disk missing, unlicensed data CDs, Audio CDs.
+The counters are reset to zero, and SCEx receive mode is active for a few
+seconds after booting a new disk (on power up, on closing the drive door, on
+sending a Reset command, and on sub_function 04h). The disk is unlocked if the
+"success" counter is nonzero, the only exception is sub_function 04h which does
+update the counters, but does not lock/unlock the disk.
Signal Processor and Servo Amplifier
Sends an 8bit/16bit/24bit command to the hardware, depending on number of
+parameters:
+
1 byte --> send CX(Xx) ;short 8bit command
+ 2 bytes --> send CX(Xxxx) ;longer 16bit command
+ 3 bytes --> send CX(Xxxxxx) ;full 24bit command
+ 4 bytes --> send CX(Xxxxxxxx) ;extended 32bit command (BIOS vC3 only)
+ 4..15 bytes: acts same as max (3 or 4 bytes) (extra bytes are ignored)
+ 0 bytes or more than 15 bytes: generates an error
+Supported by newer CDROM BIOSes only (such that use CXD2545Q or newer chips).
+Works same as 19h,50h, but does additionally receive a response.
+The command is always sending a 24bit CX(Xxxxxx) command, but it doesn't verify
+the number of parameter bytes (when using more than 3 bytes: extra bytes are
+ignored, when using less than 3 bytes: garbage is appended, which is somewhat
+valid because 8bit/16bit commands can be padded to 24bit size by appending
+"don't care" bits).
+The command can be used to send any CX(..) command, but actually it does make
+sense only for the get-status commands, see below "19h,51h,39h,xxh"
+description.
Supported by newer CDROM BIOSes only (such that use CXD2545Q or newer chips).
+Sends CX(39xx) to the hardware, and receives a response (the response.hi byte
+is usually 00h for 8bit responses, or 00h..01h for 9bit responses). For
+example, this can be used to dump the Coefficient RAM.
Forces the motor to stop spinning (ignored during spin-up phase).
Forces the drive motor to spin at maximum speed (which is much faster than
+normal or double speed), in normal (clockwise), or reversed (anti-clockwise)
+direction. The commands work even if the shell is open. The commands do not try
+to synchronize the motor with the data on the disk (and do thus work even if no
+disk is inserted).
This command seems to have effect only if the drive motor was off. If it was
+off, it does FFh-fills the TOC entries in RAM, and seek to the begin of the TOC
+at 98:30:00 or so (where minute=98 means minus two). From that location, it
+follows the spiral on the disk, although it does occassionally jump back some
+seconds. After clearing the TOC, the command does not write new data to the TOC
+buffer in RAM.
+Note: Like 19h,04h, this command forces the drive motor to spin at standard
+speed (synchronized with the data on the disk), works even if the shell is open
+(but stops spinning after a while if the drive is empty).
Moves the laser lens. The inwards/outwards commands do move ONLY the lens (ie.
+unlike as for Seek commands, the overall-laser-unit remains in place, only the
+lens is moved).
Moves the drive head to outer-most and inner-most position. Note that the drive
+doesn't have a switch that'd tell the controller when it has reached the
+outer-most position (so it'll forcefully hit against the outer edge) (ie. using
+this command too often may destroy the drive mechanics).
+Note: The same destructive hit-outer-edge effect happens when using Setloc/Seek
+with too large values (like minute=99h).
Seem to have no effect?
+19h,16h seems to Move Lens Inwards, too.
These commands are supported only by older CDROM BIOS versions (those with
+CXA1782BR Servo Amplifier).
+Later BIOSes will respond with INT5(11h,20h) when trying to use these commands
+(because CXD2545Q and later Servo Amplifiers don't support the CX(30/38+n)
+commands).
Older CDROM BIOSes are supporting debug message transmission via serial bus,
+using lower 3bit of the HC05 "databus" combined with the so-called "ROMSEL" pin
+(which apparently doesn't refer to Read-Only-Memory, but rather something like
+Runtime-Output-Message, or whatever).
+Data is transferred in 24bit units (8bit command/index from HC05, followed by
+16bit data to/from HC05), bigger messages are divided into multiple such 24bit
+snippets.
+There are no connectors for external debug hardware on any PSX mainboards, so
+the whole stuff seems to be dating back to prototypes. And it seems to be
+removed from later BIOSes (which appear to use "ROMSEL" as "SCLK"; for
+receiving status info from the new CXD2545Q chips).
These functions are supported on older CDROM BIOS only; later BIOSes respond by
+INT5(11h,10h).
+The functions do not affect the CDROM operation (they do simple allow to
+transfer data between Main CPU and external debug hardware).
+Sub functions 30h and 31h may fail with INT5(11h,80h) when receiving wrong
+signals on the serial input line.
+Sub function "4xh" value can be 40h..4Fh (don't care).
Alongsides to INT5 errors, the BIOS is usually also sending information via the
+above serial bus (the error info is divided into multiple 8bit+16bit snippets,
+and contains stat, error code, mode, current SubQ position, and most recently
+issued command).
Caution: Below commands 19h,71h..76h are supported only in BIOS version vC1 and
+up. Not supported in vC0.
index can be 00h..1Fh, bigger values seem to be mirrored to "index AND 1Fh",
+with one exception: index 13h in NOT mirrored, instead, index 33h, 53h, 93h,
+B3h, D3h, F3h return INT5(stat+1,10h), and index 73h returns INT5(stat+1,20h).
+Aside from returning a value, the commands seem to DO something (like moving
+the drive head when a disk is inserted). Return values are usually:
+
index value
+ 00h 04h ;04h=empty, 8Eh=licensed, 24h=audio
+ 01h [0B1h] ;DCh=empty/licensed, DDh=audio
+ 02h 00h
+ 03h 00h ;or variable when disk inserted
+ 04h 00h
+ 05h 80h ;or 86h or 89h when disk inserted
+ 06h C0h
+ 07h 02h
+ 08h 8Ah
+ 09h C0h
+ 0Ah 00h
+ 0Bh C0h
+ 0Ch [1F2h]
+ 0Dh [1F3h]
+ 0Eh 00h ;or 8Eh or E6h when disk inserted ;D4h/audio
+ 0Fh 00h ;or sometimes 01h when disk inserted ;50h/audio
+ 10h C0h
+ 11h E0h
+ 12h 71h
+ 13h stat
+ 14h FFh
+ 15h..1Fh C0h-filled ;or 17h --> DEh
+ ;other response on param xx16h,xx18h with xx>00h
+Same as read/write single register, but trying to transfer multiple registers
+at once. BUG: The transfer should range from 00h to len-1, but the loop counter
+is left uninitialized (set to X=48h aka "command number 19h-minus-1-mul-2"
+instead of X=00h). Causing to the function to read/write garbage at index
+48h..FFh, it does then wrap to 00h and do the correct intended transfer, but
+the preceeding bugged part may have smashed RAM or I/O ports.
Returns a 4-byte value. In my early tests, on the first day it returned
+B1h,CEh,4Ch,01h, on the next day 2Ch,E4h,95h,D5h, and on all following days
+00h,C0h,00h,00h (no idea why/where the earlier values came from).
+The first byte seems to be always 00h; no matter of [1F0h].
+The second byte seems to be always C0h; no matter of [1F1h].
+The third,fourth bytes are [1F2h,1F3h].
+That two bytes are 0Ch,08h after Read commands.
+
The first bytes are NOT affected by:
+ destroying [1F0h] via too-many-parameters in command-buffer,
+ changes to [1F1h] which may occur after read command (eg. may be 20h)
+Prepare Transfer to/from 32K SRAM.
+After INT3, data can be read (same way as sector data after INT1).
Reads one byte from the controller's RAM or I/O area, see the memory map below
+for more info. Among others, the command allows to read Subchannel Q data, eg.
+at [200h..209h], including ADR=2/UPC/EAN and ADR=3/ISRC values (which are
+suppressed by GetlocP). Eg. wait for ADR\<>2, then for ADR=2, then read
+the remaining 9 bytes (because of the delayed IRQs, this works only at single
+speed) (at double speed one can read only 5 bytes before the values get
+overwritten by new data). Unknown if older boards (with 4.00MHz oscillators)
+are fast enough to read all 10 SubQ bytes.
First 40h bytes are I/O ports (as in MC68HC05 datasheet):
+
000h 4 FF 7B 00 FF (other when disk inserted)
+ 004h 5 11 00 20 20 0C
+ 009h 1 00 (when disk inserted: changes between 00 or 80)
+ 00Ah 2 71 00
+ 00Ch 1 00 (when disk inserted: changes between 00 or 80)
+ 00Dh 3 20 20 20
+ 010h 8 02 80 00 60 00 00 99(orBB) 98
+ 018h 4 changes randomly (even when no disk inserted)
+ 01Ch 3 40 00 41
+ 01Fh 1 changes randomly (even when no disk inserted)
+ 020h 30 20h-filled
+ 03Eh 2 82h 20h
+ 040h 4 08 00 00 00 ;or 98 07 xx 0B when disk inserted ;[40].Bit1=MUTE
+ 044h 4 00h-filled
+ 048h 3 40 20 00 ;or 58 71 0F when disk inserted
+ 04Bh 1 changes randomly (nodisk: 00 or 80 / disk: BFh)
+ 04Ch 1 Zero (or C0h)
+ 04Dh 3 MM:SS:FF (begin of current track MM:SS:00h) (or increasing addr)
+ 050h 10 Subchannel Q (adjusted position values)
+ 05Ah 2 ...
+ 05Ch 1 00h (or 64h)
+ 05Dh 3 MM:SS:FF (current read address) (sticky address during pause)
+ 060h 1 increments at circa 16Hz or so (or other rate when spinning)
+ 061h 12 00h-filled ;or else when disk inserted
+ 06Dh 1 01 ;or 0C when disk inserted
+ 06Eh 2 SetFilter setting (file,channel)
+ 070h 16 00h-filled ;or else when disk inserted
+ 080h 8 00h-filled
+ 088h 3 03:SS:FF (three, second, fraction)
+ 08Bh 3 03:SS:FF (three, second, fraction)
+ 08Eh 2 01 FF (or other values)
+ 090h 1 00h (or 91h when disk inserted + spinning)
+ 091h 13 Zero
+ 09Eh 1 00h (or 01h when disk inserted + spinning)
+ 09Fh 1 Zero
+ 0A0h 1 Always 23h
+ 0A1h 1 09h (5Dh when disk inserted)
+ 0A2h 7 00h-filled
+ 0A9h 1 40
+ 0AAh 4 00h-filled
+ 0AEh 1 00 (no disk) or 01 (disk) or so
+ 0AFh 1 00 ;or 06 when disk inserted
+ 0B0h 7 00 DC 00 02 00 E0 08 ;\or else when disk inserted
+ 0B7h 1 20 ;Bit6+7=MUTE ;
+ 0B8h 3 DE 00 00 ;/
+ 0BBh 1 SetMode setting (mode)
+ 0BCh 1 GetStat setting (stat)
+ 0BDh 3 00h-filled
+ 0C0h 6 FFh-filled ;stack... ;\
+ 0C6h 1 Usually DFh ;sometimes [0EBh and up] are non-FFh, too
+ 0C7h 15 FFh-filled ;(depending on disk or commands or so)
+ 0D6h 1 Usually FDh (or FFh) ; ;
+ 0D7h 24 FFh-filled ; stack
+ 0EFh 4 on power-up FFh-filled, other once when disk read ;
+ 0F3h 7 changes randomly (even when no disk inserted) ;
+ 0FAh 6 2E 3C 2A D6 10 95 ;/
+ 100h 2x99 TOC Entries for Start of Track 1..99 (MM:SS)
+ 1C6h 1 TOC First Track number (usually 01h)
+ 1C7h 1 TOC Last Track number (usually 01h or higher)
+ 1C8h 3 TOC Entry for Start of Lead-Out (MM:SS:FF)
+ 1CBh 2 Zero
+ 1CDh 1 Depends on disk (01 or 02 or 06) (or 00 when no disk)
+ 1CEh 1 Zero
+ 1CFh 1 Depends on disk (NULL minus N*6) (or 00 when no disk)
+ (maybe reflection level / laser intensity or so)
+ [1CDh..1CFh]
+ 01 00 E8 --> licensed/metalgear/kain
+ 01 00 EE --> licensed/alone2
+ 06 00 E2 or 00 00 02 00 E8 --> licensed/wipeout
+ 02 00 DC --> unlicensed/elo
+ 02 00 D6 --> unlicensed/driver
+ 00 00 EE --> audio/lola
+ 00 00 FA --> audio/marilyn
+ 00 00 F4 --> audio/westen
+ 00 00 00 --> disk missing
+ last byte is always in steps of 6
+ 1D0h 4 SCEx String
+ 1D4h 4 Zero
+ 1D8h 2 SCEx Counters (total,success) ;for command 19h,05h
+ 1DAh 6 00h-filled (or ... SS:FF)
+ 1E0h 6 Command Buffer (usually 19h,60h,E2h,01h = Read RAM Command)
+ 1E6h 7 00h-filled (unless destroyed by more-than-6-byte-commands)
+ 1EDh 3 Setloc setting (MM:SS:FF)
+ 1F0h 1 00h (unless destroyed by more-than-6-byte-commands)
+ 1F1h 3 C0h 00h 00h ;or 20h,0Ch,50h or C0h,0Ch,08h ;for command(19h,75h)
+ ;or 00h,00h,00h for audio
+ ;or 80h,00h,00h for disk missing
+ 1F4h 4 00h-filled ... or SCEx string
+ 1F8h 1 00h
+ 1F9h 1 Selected Target (parameter from Play and SetSession commands)
+ 1FAh 5 00h-filled ;01 01 00 8B 00 00 ;or 01 02 8B 00 00
+ 01 00 8B 00 00 -- audio/unlicensed
+ 01 01 00 00 00 -- licensed
+ 1FFh 1 00h-on power up, changes when disk inserted ;or 01 = Playing
+ 1FDh 3 MM:SS:FF (only during command 19h,00h) (MM=98..99=TOC)
+ 200h 10 Subchannel Q (real values)
+ 20Ah 2 whatever
+ 20Ch 1 Zero
+ 20Dh 1 Desired Session (from SetSession command)
+ 20Eh 1 Current Session (actual location of drive head)
+ 20Fh 1 Zero
+ 210h 10 Subchannel Q (adjusted position values)
+ 21Ah 6 00h-filled
+ 220h 4 Data Sector Header (MM:SS:FF:Mode)
+ 224h 4 Data Sector CD-XA Subheader (file,channel,sm,ci)
+ 228h 1 00h
+ 229h 1 Usually 00h (shortly other value on power-up, and maybe on seek)
+ 22Ah 1 10h (or 00h when no disk)
+ 22Bh 3 00h-filled
+ 22Eh 2 01,03 or 0A,00 or 03,01 (or else for other disk)
+ 230h 3 00h-filled (or other during spin-up / read-toc or so)
+ 233h 0Dh 00h-filled (unused RAM)
+ 240h..2FFh - Invalid (00h-filled) (no ROM, RAM, or I/O mapped here)
+ 300h..3FFh - Mirror of 200h..2FFh ;\the BIOS is doing that
+ 400h..FFFFh - Mirrors of 000h..3FFh ;/mirroring by software
+This version allows to read the whole 64Kbyte memory space (withou mirroring
+everything to first 300h bytes). I/O Ports and Variables are at different
+locations:
+
000h..0DFh RAM Part 1 (C0h bytes)
+ 0E0h..0FFh I/O Area
+ 100h..1DFh RAM Part 2 (C0h bytes)
+ 1E0h..1FFh I/O Area
+ 200h..2DFh RAM Part 3 (100h bytes)
+ 2E0h..7FFFh Unknown
+ 8000h-BFFFh Unknown (lower 16K of 32K EPROM) (or unused?)
+ C000h-FFFFh Firmware (upper 16K of 32K EPROM)
+There is no command for writing to RAM. Except that, one can write to the
+command/parameter buffer at 1E0h and up. Normally, the longest known command
+should have 6 bytes (19h,76h,a,b,c,d), and longer commands results in "bad
+number of parameters" response - however, despite of that error message, the
+controller does still store ALL parameter bytes in RAM (at address 1E1h..2E0h,
+then wrapping back to 1E1h). Whereas, writing more than 16 bytes (FIFO storage
+size) will mirror the FIFO content twice, and more than 32 bytes (FIFO counter
+size) will work only when feeding extra data into the FIFO during transmission.
+Anyways, writing to 1E1h and up doesn't allow to do interesting things (such
+like manipulating the stack and executing custom code on the CPU).
The "adjusted position values" at 050h, 210h, 310h contain only position
+information (with ADR=1) (the PSX seems to check only the lower 2bit of the
+4bit ADR value, so it also treats ADR=5 as ADR=1, too). Additionally, during
+Lead-In, bytes 7..9 are overwritten by the position value from bytes 3..5. The
+"real values" contain unadjusted data, including ADR=2 and ADR=3 etc.
Caution: Supported only in BIOS version vC1 and up. Not supported in vC0.
+ Caution: Supported only in Europe/USA. Nonfunctional in Japan/Asia.
+ Caution: When unsupported, Parameter Fifo isn't cleared after the command.
+ "of America" ;for NTSC/US ;\
+ "(Europe)" ;for PAL/Europe ; handled, and actually working
+ "World wide" ;for Yaroze ;/
+ "Inc." ;for NTSC/JP ;-non-functional
+Undoes the unlocking and restores the normal locked state (same happens when
+sending the Unlocking commands in wrong order or with wrong parameters).
Jumps to a data area and executes random code. Results are more or less
+unpredictable (as they involve executing undefined opcodes). Eventually the CPU
+might hit a RET opcode and recover from the crash.
Caution: Supported only on SCPH-5903, not supported on any other consoles.
+ Caution: When unsupported, Parameter Fifo isn't cleared after the command.
+ 1Fh VideoCD sub,a,b,c,d,e INT3(stat,a,b,c,d,e) ;<-- SCPH-5903 only
+ 1Fh..4Fh - - INT5(11h,40h) ;-Unused/invalid
+The JoyL/JoyH bytes contain 16bit button (and drive door) bits:
+
0 Drive Door (0=Open) (from CDROM stat bit4) ;Open
+ 1 Button /\ (0=Pressed) (from PSX pad bit12) ;N/A ;PBC: Back/LevelUp
+ 2 Button [] (0=Pressed) (from PSX pad bit15) ;Enter Menu
+ 3 Button () (0=Pressed) (from PSX pad bit13) ;Leave Menu ;PBC: Confirm
+ 4 Button >< (0=Pressed) (from PSX pad bit14) ;N/A
+ 5 Start (0=Pressed) (from PSX pad bit3) ;Play/Pause
+ 6 Select (0=Pressed) (from PSX pad bit0) ;Stop (prompt restart/resume)
+ 7 Always 0 (0) (fixed) ;N/A
+ 8 DPAD Up (0=Pressed) (from PSX pad bit4) ;Menu Up ;PBC: +1
+ 9 DPAD Right (0=Pressed) (from PSX pad bit5) ;Menu Right/change ;PBC: +10
+ 10 DPAD Down (0=Pressed) (from PSX pad bit6) ;Menu Down ;PBC: -1
+ 11 DPAD Left (0=Pressed) (from PSX pad bit7) ;Menu Left/change ;PBC: -10
+ 12 Button R1 (0=Pressed) (from PSX pad bit11) ;Prev Track/Restart Track
+ 13 Button R2 (0=Pressed) (from PSX pad bit9) ;Fast Forward (slowly)
+ 14 Button L1 (0=Pressed) (from PSX pad bit10) ;Next Track (if any)
+ 15 Button L2 (0=Pressed) (from PSX pad bit8) ;Fast Backward (slowly)
+ 00h Motor Off (or spin-up) (when stat.bit1=0)
+ 01h Playing (when stat.bit7=1)
+ 02h Paused (and not seeking) (when stat.bit6=0)
+ (note: State remains unchanged when seeking)
+ 00h = Confirms that "Tocread" (aka setsession 1) request was processed
+ 01h = Detect VCD Disc (used on power-up, and after door open) (after spin-up)
+ 02h = Handshake (request ack response)
+ 0Ah = Door opened during play (int5/door error)
+ 80h = No disc
+ FFh = No change (nop)
+ 00h Normal (no special event occured and no action requested)
+ 01h Request CD to Seek_and_play (using mm:ss:ff response parameter bytes)
+ 02h Request CD to Pause ;cmd(09h) -->int3(stat),int2(stat)
+ 03h Request CD to Stop ;cmd(08h) -->int3(stat),int2(stat)
+ 04h Request CD to Tocread (setsession1);cmd(12h,01h)-->int3(stat),int2(stat)
+ 05h Handshake Command was processed, and this is the "ack" response
+ 06h Request CD to Fast Forward ;cmd(04h) -->int3(stat)
+ 07h Request CD to Fast Backward ;cmd(05h) -->int3(stat)
+ 80h Detect Command was processed, and disc was detected as VCD
+ 81h Detect Command was processed, and disc was detected as Non-VCD
+ 00h = Normal PSX Mode (PortF.3=LOW) (Audio/Video from GPU/SPU chips)
+ 01h..FFh = Special VCD Mode (PortF.3=HIGH) (Audio/Video from MDEC/OSD chips)
+The version/date is "15 Aug 1996, version C2h", although the "C2h" is
+misleading: The firmware is nearly identical to version "C1h" from PU-8 boards
+(the stuff added in normal "C2h" versions would be for PU-18 boards with
+different cdrom chipset).
Compared to the original C1h version, there are only a few changes: A
+initialization function for initializing port F on power-up. And new command
+(command 1Fh, inserted in the various command tables), with two subfunctions
+(01h and 02h):
+- Command 1Fh,01h,a,b,c,d,e --> INT3(stat,a,b,c,d,e) Serial 5-byte
+read-write
+- Command 1Fh,02h,v,x,x,x,x --> INT3(stat,0,0,x,x,x) Toggle 1bit (port
+F.bit3)
+Whereas,
+
x = don't care/garbage
+ v = toggle state (00h=normal=PortF.3=LOW, 01h..FFh=special=PortF.3=HIGH)
+ (toggle gpu vs mpeg maybe?)
+ a,b,c,d,e = five bytes sent serially, and five bytes response received
+ serially (send/receive done simultaneously)
+The Port F bits are:
+
Port F.Bit0 = Serial Data In
+ Port F.Bit1 = Serial Data Out
+ Port F.Bit2 = Serial Clock Out
+ Port F.Bit3 = Toggle (0=Normal, 1=Special)
+And that's about all. Ie. essentially, the only change is that the new command
+controls Port F. There is no interaction with the remaining firmware (ie.
+reading, seeking, and everything is working as usually, without any video-cd
+related changes).
+The SCEx stuff is also not affected (ie. Video CDs would be seen as unlicensed
+discs, so the PSX couldn't read anything from those discs, aside from Sub-Q
+position data, of course). The SCEx region is SCEI aka "Japan" (or actually for
+Asia in this case).
The SPU MUTE Flag (SPUCNT.14) does also affect VCD Audio (mute is applied to
+the final analog audio amplifier). All other SPUCNT bits can be zero for VCD.
The SUB-CPU is running a mainloop that is handling hardware events (by simple
+polling, not by IRQs):
+
check for incoming sectors (from CDROM decoder)
+ check for incoming commands (from Main CPU)
+ do maintenance stuff on the drive mechanics
+The order of steps that happen when sending a command to the CD controller look roughly like this: +
e.g. SetMode:
+1. Command busy flag set immediately.
+2. Response FIFO is populated.
+3. Command is being processed.
+4. Command busy flag is unset and parameter fifo is cleared.
+5. Shortly after (around 1000-6000 cycles later), CDROM IRQ is fired.
+The PSX can deliver one INT after another. Instead of using a real queue, it's
+merely using some flags that do indicate which INT(s) need to be delivered.
+Basically, there seem to be two flags: One for Second Response (INT2), and one
+for Data/Report Response (INT1). There is no flag for First Response (INT3);
+because that INT is generated immediately after executing a command.
+The flag mechanism means that the SUB-CPU cannot hold more than one undelivered
+INT1. That, although the CDROM Decoder does notify the SUB-CPU about all newly
+received sectors, and it can hold up to eight sectors in the 32K SRAM. However,
+the SUB-CPU BIOS merely sets a sector-delivery-needed flag (instead of
+memorizing which/how many sectors need to be delivered, and, 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/incompletely
+received sector).
The first response is sent immediately after processing a command. In detail:
+The mainloop checks for incoming commands once every some clock cycles, and
+executes commands under following condition:
+
Main CPU has sent a command, AND, there is no INT pending
+ (if an INT is pending, then the command won't be executed yet, but will be
+ executed in following mainloop cycles; once when INT got acknowledged)
+ (even if no INT is pending, the mainloop may generate INT1/INT2 before
+ executing the command, if so, as said above, the command won't execute yet)
+Some commands do send a second response after actual command execution:
+
07h MotorOn E - INT3(stat), INT2(stat)
+ 08h Stop E - INT3(stat), INT2(stat)
+ 09h Pause E - INT3(stat), INT2(stat)
+ 0Ah Init - INT3(late-stat), INT2(stat)
+ 12h SetSession E session INT3(stat), INT2(stat)
+ 15h SeekL E - INT3(stat), INT2(stat) ;\use prior Setloc
+ 16h SeekP E - INT3(stat), INT2(stat) ;/to set target
+ 1Ah GetID E - INT3(stat), INT2/5(stat,flg,typ,atip,"SCEx")
+ 1Dh GetQ E adr,point INT3(stat), INT2(10bytesSubQ,peak_lo)
+ 1Eh ReadTOC - INT3(late-stat), INT2(stat)
+ 03h Play E (track) INT3(stat), optional INT1(report bytes)
+ 04h Forward E - INT3(stat), optional INT1(report bytes)
+ 05h Backward E - INT3(stat), optional INT1(report bytes)
+ 06h ReadN E - INT3(stat), INT1(stat), datablock
+ 1Bh ReadS E?- INT3(stat), INT1(stat), datablock
+Here are some response timings, measured in 33MHz units on a PAL PSone. The
+CDROM BIOSes mainloop is doing some maintenance stuff once and when, meaning
+that the response time will be higher in such mainloop cycles (max values), and
+less in normal cycles (min values). The maintenance timings do also depend on
+whether the motor is on or off (and probably on various other factors like
+seeking).
The First Response interrupt is sent almost immediately after processing the
+command (that is, when the mainloop sees a new command without any old
+interrupt pending). For GetStat, timings are as so:
+
Command Average Min Max
+ GetStat (normal) 000c4e1h 0004a73h..003115bh
+ GetStat (when stopped) 0005cf4h 000483bh..00093f2h
+ Init 0013cceh 000f820h..00xxxxxh
+ Command Average Min Max
+ GetID 0004a00h 0004922h..0004c2bh
+ Pause (single speed) 021181ch 020eaefh..0216e3ch ;\time equal to
+ Pause (double speed) 010bd93h 010477Ah..011B302h ;/about 5 sectors
+ Pause (when paused) 0001df2h 0001d25h..0001f22h
+ Stop (single speed) 0d38acah 0c3bc41h..0da554dh
+ Stop (double speed) 18a6076h 184476bh..192b306h
+ Stop (when stopped) 0001d7bh 0001ce8h..0001eefh
+ Command Average Min Max
+ Read (single speed) 006e1cdh 00686dah..0072732h
+ Read (double speed) 0036cd2h 00322dfh..003ab2bh
+[Below are some older/outdated test cases]
The CDROM sector buffer is 32Kx8 SRAM (IC303). The buffer is apparently divided
+into 8 slots, theoretically allowing to buffer up to 8 sectors.
+BUG: 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). There is no known way to get around that effect.
+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 (there appear to be absolutely no overrun
+status flags, nor overrun error interrupts).
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
+ 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)
+ 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)
+ 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)
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ GetlocL
+ Process INT3 --> receives getloc info 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
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Delay(1)
+ GetlocL
+ Process INT1 --> receives sector header for 0:2:1
+ Process INT3 --> receives getloc info for 0:2:6
+ Process INT1 --> receives sector header for 0:2:6
+ Process INT1 --> receives sector header for 0:2:7
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ GetlocL
+ Delay(1)
+ Process INT3 --> receives getloc info for 0:2:0
+ Process INT1 --> receives sector header for 0:2:5
+ Process INT1 --> receives sector header for 0:2:6
+ Process INT1 --> receives sector header for 0:2:7
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Delay(1)
+ GetlocL
+ Delay(1)
+ Process INT1 --> receives sector header for 0:2:9
+ Process INT1 --> receives sector header for 0:2:11
+ Process INT3 --> receives getloc info for 0:2:12
+ Process INT1 --> receives sector header for 0:2:12
+ Process INT1 --> receives sector header for 0:2:13
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Pause
+ Process INT3 --> receives stat=22h (first pause response)
+ Process INT2 --> receives stat=02h (second pause response)
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Delay(1)
+ Pause
+ Process INT1 --> receives sector header for 0:2:1 (oldest)
+ Process INT3 --> receives stat=22h (first pause response)
+ Process INT2 --> receives stat=02h (second pause response)
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Pause
+ Delay(1)
+ Process INT3 --> receives stat=22h (first pause response)
+ Process INT2 --> receives stat=02h (second pause response)
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Delay(1)
+ Pause
+ Delay(1)
+ Process INT1 --> receives sector header for 0:2:9 (oldest/overwritten)
+ Process INT3 --> receives stat=22h (first pause response)
+ Process INT2 --> receives stat=02h (second pause response)
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ GetlocL
+ Pause
+ Process INT3 --> receives stat=22h (first pause response)
+ Process INT2 --> receives stat=02h (second pause response)
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Delay(1)
+ GetlocL
+ Pause
+ Process INT1 --> receives sector header for 0:2:1
+ Process INT1 --> receives sector header for 0:2:6
+ Process INT3 --> receives stat=22h (first pause response)
+ Process INT2 --> receives stat=02h (second pause response)
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ GetlocL
+ Delay(1)
+ Pause
+ Process INT3 --> receives getloc info for 0:2:0 (first getloc response)
+ Process INT3 --> receives stat=22h (first pause response)
+ Process INT2 --> receives stat=02h (second pause response)
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Delay(1)
+ GetlocL
+ Delay(1)
+ Pause
+ Process INT1 --> receives sector header for 0:2:9 (oldest/overwritten)
+ Process INT3 --> receives stat=22h (first pause response)
+ Process INT2 --> receives stat=02h (second pause response)
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Pause
+ GetlocL
+ Process INT3 --> receives getloc info for 0:2:0 (first getloc response)
+ 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
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Delay(1)
+ Pause
+ GetlocL
+ Process INT1 --> receives sector header for 0:2:1
+ Process INT3 --> receives getloc info for 0:2:6 (first getloc response)
+ Process INT1 --> receives sector header for 0:2:6
+ Process INT1 --> receives sector header for 0:2:7
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Pause
+ Delay(1)
+ GetlocL
+ Process INT3 --> receives stat=22h (first pause response)
+ Process INT3 --> receives getloc info for 0:2:6 (first getloc response)
+ (No further INT's, ie. read is paused, but second-pause-response is lost).
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Pause
+ Delay(1)
+ GetlocL
+ Delay(1)
+ Process INT3 --> receives stat=22h (first pause response)
+ Process INT3 --> receives getloc info for 0:2:6 (first getloc response)
+ Process INT2 --> receives stat=02h (second pause response)
+ Setloc(0:2:0)+Read
+ Process INT1 --> receives sector header for 0:2:0
+ Delay(1)
+ Pause
+ Delay(1)
+ GetlocL
+ Process INT1 --> receives sector header for 0:2:9
+ Process INT1 --> receives sector header for 0:2:11
+ Process INT3 --> receives getloc info for 0:2:12 (first getloc response)
+ Process INT1 --> receives sector header for 0:2:12
+ Process INT1 --> receives sector header for 0:2:13
+The PSX uses a ISO 9660 filesystem, with data stored on CD-XA (Mode2) Sectors.
+ISO 9660 is standard for CDROM disks, although newer CDROMs may use extended
+filesystems, allowing to use long filenames and lowercase filenames, the PSX
+Kernel doesn't support such stuff, and, in fact, it's putting some restrictions
+on the ISO standard: it's limiting file names to MSDOS-style 8.3 format, and
+it's allowing only a limited number of files and directories per disk.
Originally intended for Mode1 Sectors (but is also used for CD-XA Mode2)
+ Supports "FILENAME.EXT;VERSION" filenames (version is usually "1")
+ Supports all-uppercase filenames and directory names (0-9, A-Z, underscore)
+ For PSX: Max 8-character filenames with max 3-character extensions
+ For PSX: Max 8-character directory names, without extension
+ For PSX: Max one sector per directory (?)
+ For PSX: Max one sector (or less?) per path table (?)
+ Uses Mode2 Sectors (see Sector Encoding chapter)
+ Allows 800h or 914h byte data per sector (with/without error correction)
+ Allows to break interleaved data into separate files/channels
+ Supports XA-ADPCM compressed audio data
+ Stores "CD-XA001" at 400h Primary Volume Descriptor (?)
+ Stores 14 extra bytes in System Use area (LEN_SU) of Directory Entries
+ Defines physical metrics of the CDROM and Audio disks
+ Defines Sub-channels and Track.Index and Minute.Second.Fraction numbering
+ Defines 14bit-per-byte encoding, and splits sectors into frames
+ Defines ECC and EDC (error correction and error detection codes)
+ISO documents are commercial standards (not available for download), however,
+they are based on ECMA standards (which are free for download, however, the
+ECMA stuff is in PDF format, so one may treat it as commercial bullshit, too).
+CD-ROM XA is commercial only (not available for download), and, CD-XA doesn't
+seem to have become very popular outside of the PSX-world, so there's very
+little information available, portions of CD-XA are also used in the CD-i
+standard (which may be a little better or worse documented).
sessions one or more sessions per disk
+ tracks 99 tracks per disk (01h..99h) (usually only 01h on Data Disks)
+ index 99 indices per track (01h..99h) (rarely used, usually always 01h)
+ minutes 74 minutes per disk (00h..73h) (or more, with some restrictions)
+ seconds 60 seconds per minute (00h..59h)
+ sectors 75 sectors per second (00h..74h)
+ frames 98 frames per sector
+ bytes 33 bytes per frame (24+1+8 = data + subchannel + error correction)
+ bits 14 bits per byte (256 valid combinations, and many invalid ones)
+Multiple Tracks are usually used only on Audio Disks (one track for each song,
+numbered 01h and up), a few Audio Disks may also split Tracks into separate
+fragments with different Index values (numbered 01h and up, but most tracks
+have only Index 01h). A simple Data Disk would usually contain only one Track
+(all sectors marked Track=01h and Index=01h), although some more complex Data
+Disks may have multiple Data tracks and/or Audio tracks.
The sectors on CDROMs and CD Audio disks are numbered in Minutes, Seconds, and
+1/75 fragments of a second (where a "second" is referring to single-speed
+drives, ie. the normal CD Audio playback speed).
+Minute.Second.Sector is stored twice in the subchannel (once the "absolute"
+time, and once the "local" time).
+The "absolute" sector number (counted from the begin of the disk) is mainly
+relevant for Seek purposes (telling the controller if the drive head is on the
+desired location, or if it needs to move the head backwards or forwards).
+The "local" sector number (counted from the begin of the track) is mainly
+relevant for Audio Players, allowing to pass the data directly to the
+Minute:Second display, without needing to subtract the start address of the
+track.
+Data disks are additionally storing the "absolute" values in their Data Areas,
+basically that's just the subchannel data duplicated, but more precisely
+assigned - the problem with the subchannel data is that the CD Audio standard
+seems to lack a clear definition that would assign the begin of the sub-channel
+block to the exact begin of a sector; so, when using only the subchannel data,
+some Drive Controllers may assign the begin of a new sector to another location
+as than other Controllers do, for Audio Disks that isn't too much of a problem,
+but for Data Disks it'd be fatal.
Each frame contains 8 subchannel bits (named P,Q,R,S,T,U,V,W). So, a sector
+(with 98 frames) contains 98 bits (12.25 bytes) for each subchannel.
+CDROM Subchannels
Each Frame contains 8 bytes Error Correction information, which is mainly used
+for Audio Disks, but it isn't 100% fail-proof, for that reason, Data Disks are
+containing additional Error Correction in the 930h-byte data area (the audio
+correction is probably focusing on repairing the MSBs of the 16bit samples, and
+gives less priority on the LSBs). Error Correction is some kind of a huge
+complex checksum, which allows to detect the location of faulty bytes, and to
+fix them.
The "user" area for each sector is 930h bytes (2352 bytes). That region is
+combined of the 24-byte data per frame (and excludes the 8-byte audio error
+correction info, and the 1-byte subchannel data).
+Most CDROM Controllers are only giving access to this 930h-byte region (ie.
+there's no way to read the audio error correction info by software, and only
+limited access to the subchannel data, such like allowing to read only the
+Q-channel for showing track/minute/second in audio playback mode).
+On Audio disks, the 930h bytes are plain data, on Data disks that bytes are
+containing headers, error correction, and usually only 800h bytes user data
+(for more info see Sector Encoding chapter).
Multi-Sessions are mainly used on CDR's, allowing to append newer data at the
+end of the disk at a later time. First of, the old session must contain a flag
+indicating that there may be a newer session, telling the CDROM Controller to
+search if one such exists (and if that is equally flagged, to search for an
+even newer session, and so on until reaching the last and newest session).
+Each session contains a complete new ISO Volume Descriptor, and may
+additionally contain new Path Tables, new Directories, and new Files. The
+Driver Controller is usually recursing only the Volume Descriptor of the newest
+session. However, the various Directory Records of the new session may refer to
+old files or old directories from previous sessions, allowing to "import" the
+older files, or to "rename" or "delete" them by assigning new names to that
+files, or by removing them from the directory.
+The PSX is reportedly not supporting multi-session disks, but that doesn't seem
+to be correct, namely, the Setsession command is apparently intended for that
+purpose... though not sure if the PSX Kernel is automatically searching the
+newest session... otherwise the boot executable in the first session would need
+to do that manually by software, and redirect control to the boot executable in
+the last session.
Subchannel P contains some kind of a Pause flag (to indicate muted areas
+between Audio Tracks). This subchannel doesn't have any checksum, so the data
+cannot be trusted to be intact (unless when sensing a longer stream of
+all-one's, or all zero's). Theoretically, the 98 pause bits are somehow
+associated to the 98 audio frames (with 24 audio bytes each) of the sector.
+However, reportedly, Subchannel P does contain two sync bits, if that is true,
+then there'd be only 96 pause flags for 98 audio frames. Strange.
+Note: Another way to indicate "paused" regions is to set Subchannel Q to ADR=1
+and Index=00h.
contains the following information:
+
Bits Expl.
+ 2 Sub-channel synchronization field
+ 8 ADR/Control (see below)
+ 72 Data (content depends on ADR)
+ 16 CRC-16-CCITT error detection code (big-endian: bytes ordered MSB, LSB)
+ Bit0-3 ADR (0=No data, 1..3=see below, 4..0Fh=Reserved)
+ Bit4 Audio Preemphasis (0=No, 1=Yes) (Audio only, must be 0 for Data)
+ Bit5 Digital Copy (0=Prohibited, 1=Allowed)
+ Bit6 Data (0=Audio, 1=Data)
+ Bit7 Four-Channel Audio (0=Stereo, 1=Quad) (Audio only, must be 0 for Data)
+ 8 Track number (fixed, must be 00h=Lead-in)
+ 8 Point (01h..99h or A0h..A2h, see last three bytes for more info)
+ 24 MSF address (incrementing address within the Lead-in area)
+ Note: On some disks, these values are choosen so that the lead-in
+ <starts> at 00:00:00, on other disks so that it <ends> at 99:59:74.
+ 8 Reserved (00h)
+ 24 MSF address (absolute address, start address of the "Point" track)
+ 8 First Track number (BCD)
+ 8 Disk Type Byte (00h=CD-DA or CD-ROM, 10h=CD-I, 20h=CD-ROM-XA)
+ 8 Reserved (00h)
+ 8 Last Track number (BCD)
+ 16 Reserved (0000h)
+ 8 Track number (01h..99h=Track 1..99)
+ 8 Index number (00h=Pause, 01h..99h=Index within Track)
+ 24 Track relative MSF address (decreasing during Pause)
+ 8 Reserved (00h)
+ 24 Absolute MSF address
+ 8 Track number (fixed, must be AAh=Lead-Out)
+ 8 Index number (fixed, must be 01h) (there's no Index=00h in Lead-Out)
+ 24 Track relative MSF address (increasing, 00:00:00 and up)
+ 8 Reserved (00h)
+ 24 Absolute MSF address
+ 52 EAN-13 barcode number (13-digit BCD)
+ 12 Reserved (000h)
+ 8 Absolute Sector number (BCD, 00h..74h) (always 00h during Lead-in)
+(ISO 3901 and DIN-31-621):
+
12 Country Code (two 6bit characters) (ASCII minus 30h) ;eg. "US"
+ 18 Owner Code (three 6bit characters) (ASCII minus 30h)
+ 2 Reserved (zero)
+ 8 Year of recording (2-digit BCD) ;eg. 82h for 1982
+ 20 Serial number (5-digit BCD) ;usually increments by 1 or 10 per track
+ 4 Reserved (zero)
+ 8 Absolute Sector number (BCD, 00h..74h) (always 00h during Lead-in)
+When Point=B0h:
+
8 Track number (fixed, must be 00h=Lead-in)
+ 8 POINT = B0h (multi-session disc)
+ 24 MM:SS:FF = the start time for the next possible session's program area,
+ a final session is indicated by FFh:FFh:FFh,
+ or when the ADR=5 / Point=B0h is absent.
+ 8 Number of different Mode-5 pointers present.
+ 24 MM:SS:FF = the maximum possible start time of the outermost Lead-out
+ 8 Track number (fixed, must be 00h=Lead-in)
+ 8 POINT = C0h (Identifies a Multisession disc, together with POINT=B0h)
+ 24 ATIP values from Special Information 1, ID=101
+ 8 Reserved (must be 00h)
+ 24 MM:SS:FF = Start time of the first Lead-in area of the disc
+ 8 Track number (fixed, must be 00h=Lead-in)
+ 8 POINT=C1h
+ 8x7 Copy of information from A1 point in ATIP
+ 8 Track number (fixed, must be AAh=Lead-out)
+ 8 POINT = D1h (Identifies a Multisession lead-out)
+ 24 Usually zero (or maybe ATIP as in Lead-In with Point=C0h...?)
+ 8 Seems to be the session number?
+ 24 MM:SS:FF = Absolute address of the First data sector of the session
+When Point=01h..40h:
+
8 Track number (fixed, must be 00h=Lead-in)
+ 8 POINT=01h..40h (This identifies a specific playback skip interval)
+ 24 MM:SS:FF Skip interval stop time in 6 BCD digits
+ 8 Reserved (must be 00h)
+ 24 MM:SS:FF Skip interval start time in 6 BCD digits
+ 8 Track number (fixed, must be 00h=Lead-in)
+ 8 POINT=B1h (Audio only: This identifies the presence of skip intervals)
+ 8x4 Reserved (must be 00h,00h,00h,00h)
+ 8 the number of skip interval pointers in POINT=01h..40h
+ 8 the number of skip track assignments in POINT=B2h..B4h
+ 8 Reserved (must be 00h)
+ 8 Track number (fixed, must be 00h=Lead-in)
+ 8 POINT=B2h,B3h,B4h (This identifies tracks that should be skipped)
+ 8 1st Track number to skip upon playback (01h..99h, must be nonzero)
+ 8 2nd Track number to skip upon playback (01h..99h, or 00h=None)
+ 8 3rd Track number to skip upon playback (01h..99h, or 00h=None)
+ 8 Reserved (must be 00h)... unclear... OR... 4th (of 7) skip info's...?
+ 8 4th Track number to skip upon playback (01h..99h, or 00h=None)
+ 8 5th Track number to skip upon playback (01h..99h, or 00h=None)
+ 8 6th Track number to skip upon playback (01h..99h, or 00h=None)
+Subchannels R..W are usually unused, except for some extended formats:
+
CD-TEXT in the Lead-In area (see below)
+ CD-TEXT in the Data area (rarely used)
+ CD plus Graphics (CD+G) (rarely used)
+CD-TEXT is stored in the six Subchannels R..W. Of the 12.25 bytes (98 bits) per
+subchannel, only 12 bytes are used. Together, all 6 subchannels have a capacity
+of 72 bytes (6x12 bytes) per sector. These 72 bytes are divided into four
+CD-TEXT fragments (of 18 bytes each). The format of these 18 bytes is:
+
00h 1 Header Field ID1: Pack Type Indicator
+ 01h 1 Header Field ID2: Track Number
+ 02h 1 Header Field ID3: Sequence Number
+ 03h 1 Header Field ID4: Block Number and Character Position Indicator
+ 04h 12 Text/Data Field
+ 10h 2 CRC-16-CCITT (big-endian) (across bytes 00h..0Fh)
+ 80h Titel (TEXT)
+ 81h Performer (TEXT)
+ 82h Songwriter (TEXT)
+ 83h Composer (TEXT)
+ 84h Arranger (TEXT)
+ 85h Message (TEXT)
+ 86h Disc ID (TEXT?) (content/format/purpose unknown?)
+ 87h Genre (BINARY) (ID codes unknown?)
+ 88h TOC (BINARY) (content/format/purpose unknown?)
+ 89h TOC2 (BINARY) (content/format/purpose unknown?)
+ 8Ah Reserved for future
+ 8Bh Reserved for future
+ 8Ch Reserved for future
+ 8Dh Reserved for "content provider" aka "closed information"
+ 8Eh UPC/EAN and ISRC Codes (TEXT) (content/format/purpose unknown?)
+ 8Fh Blocksize (BINARY) (see below)
+ 00h Title/Performer/etc. for the Disc
+ 01h..63h Title/Performer/etc. for Track 1..99 (Non-BCD) (Bit7=Extension)
+ 00h..FFh Incrementing Number (00h=First 18-byte fragment, 01h=Second, etc.)
+ Bit7 Character Set (0=8bit, 1=16bit)
+ Bit6-4 Block Number (0..7 = Language number, as set by "Blocksize")
+ Bit3-0 Character Position (0..0Eh=Position, 0Fh=Append to prev fragment)
+ ID TR SQ CH <------------Text/Data------------> -CRC- <---Text--->
+ 80 00 00 00 54 65 73 74 44 69 73 6B 54 69 74 6C E2 22 TestDiskTitl
+ 80 00 01 0C 65 00 54 65 73 74 54 72 61 63 6B 54 C9 1B e.TestTrackT
+ 80 01 02 0A 69 74 6C 65 31 00 54 65 73 74 54 72 40 3A itle1.TestTr
+ 80 02 03 06 61 63 6B 54 69 74 6C 65 32 00 00 00 80 E3 ackTitle2...
+ 81 00 04 00 54 65 73 74 44 69 73 6B 50 65 72 66 03 DF TestDiskPerf
+ 81 00 05 0C 6F 72 6D 65 72 00 54 65 73 74 54 72 12 A5 ormer.TestTr
+ 81 01 06 06 61 63 6B 50 65 72 66 6F 72 6D 65 72 BC 5B ackPerformer
+ 81 01 07 0F 31 00 54 65 73 74 54 72 61 63 6B 50 AC 41 1.TestTrackP
+ 81 02 08 0A 65 72 66 6F 72 6D 65 72 32 00 00 00 64 1A erformer2...
+ 8F 00 09 00 01 01 02 00 04 05 00 00 00 00 00 00 6D E2 ............
+ 8F 01 0A 00 00 00 00 00 00 00 00 03 0B 00 00 00 CD 0C ............
+ 8F 02 0B 00 00 00 00 00 09 00 00 00 00 00 00 00 FC 8C ............
+ 00 ;<--- for some reason, CDRWIN stores an ending 00h byte in .CDT files
+ 00h 1 Character set (00h,01h,80h,81h,82h = see below)
+ 01h 1 First track number (usually/always 01h)
+ 02h 1 Last track number (01h..63h)
+ 03h 1 1bit-cd-text-in-data-area-flag, 7bit-copy-protection-flags
+ 04h 16 Number of 18-byte packs for ID1=80h..8Fh
+ 14h 8 Last sequence number of block 0..7 (or 00h=none)
+ 1Ch 8 Language codes for block 0..7 (definitions are unknown)
+ 00h ISO 8859-1
+ 01h ISO 646, ASCII
+ 80h MS-JIS
+ 81h Korean character code
+ 82h Mandarin (standard) Chinese character code
+ Other = reserved
+ lsb=00h, msb=00h ;-initial value (zero for both CD-TEXT and Sub-Q)
+ for i=0 to len-1 ;-len (10h for CD-TEXT, 0Ah for Sub-Q)
+ x = [addr+i] xor msb
+ x = x xor (x shr 4)
+ msb = lsb xor (x shr 3) xor (x shl 4)
+ lsb = x xor (x shl 5)
+ next i
+ [addr+len+0]=msb xor FFh, [addr+len+1]=lsb xor FFh ;inverted / big-endian
+ 000h 930h Audio Data (2352 bytes) (LeftLsb,LeftMsb,RightLsb,RightMsb)
+ 000h 0Ch Sync (00h,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,00h)
+ 00Ch 4 Header (Minute,Second,Sector,Mode=00h)
+ 010h 920h Zerofilled
+ 000h 0Ch Sync (00h,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,00h)
+ 00Ch 4 Header (Minute,Second,Sector,Mode=01h)
+ 010h 800h Data (2048 bytes)
+ 810h 4 EDC (checksum across [000h..80Fh])
+ 814h 8 Zerofilled
+ 81Ch 114h ECC (error correction codes)
+ 000h 0Ch Sync (00h,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,00h)
+ 00Ch 4 Header (Minute,Second,Sector,Mode=02h)
+ 010h 4 Sub-Header (File, Channel, Submode AND DFh, Codinginfo)
+ 014h 4 Copy of Sub-Header
+ 018h 800h Data (2048 bytes)
+ 818h 4 EDC (checksum across [010h..817h])
+ 81Ch 114h ECC (error correction codes)
+ 000h 0Ch Sync (00h,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,00h)
+ 00Ch 4 Header (Minute,Second,Sector,Mode=02h)
+ 010h 4 Sub-Header (File, Channel, Submode OR 20h, Codinginfo)
+ 014h 4 Copy of Sub-Header
+ 018h 914h Data (2324 bytes)
+ 92Ch 4 EDC (checksum across [010h..92Bh]) (or 00000000h if no EDC)
+ sector[000h]=00h,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,00h
+ sector[00ch]=bcd(adr/75/60) ;0..7x
+ sector[00dh]=bcd(adr/75 MOD 60) ;0..59
+ sector[00eh]=bcd(adr MOD 75) ;0..74
+ sector[00fh]=mode
+ if mode=00h then
+ sector[010h..92Fh]=zerofilled
+ if mode=01h then
+ adjust_edc(sector+0, 800h+10h)
+ sector[814h..817h]=00h,00h,00h,00h,00h,00h,00h,00h
+ calc_p_parity(sector)
+ calc_q_parity(sector)
+ if mode=02h and form=1
+ sector[012h]=sector[012h] AND (NOT 20h) ;indicate not form2
+ sector[014h..017h]=sector[010h..013h] ;copy of sub-header
+ adjust_edc(sector+10h,800h+8)
+ push sector[00ch] ;\temporarily clear header
+ sector[00ch]=00000000h ;/
+ calc_p_parity(sector)
+ calc_q_parity(sector)
+ pop sector[00ch] ;-restore header
+ if mode=02h and form=2
+ sector[012h]=sector[012h] OR 20h ;indicate form2
+ sector[014h..017h]=sector[010h..013h] ;copy of sub-header
+ adjust_edc(sector+10h,914h+8) ;edc is optional for form2
+ src=00ch, dst=81ch+offs, srcmax=dst
+ for i=0 to len-1
+ base=src, x=0000h, y=0000h
+ for j=j0 to 42
+ x=x xor GF8_PRODUCT[j,sector[src+0]]
+ y=y xor GF8_PRODUCT[j,sector[src+1]]
+ src=src+step1, if (step1=2*44) and (src>=srcmax) then src=src-2*1118
+ sector[dst+2*len+0]=x AND 0FFh, [dst+0]=x SHR 8
+ sector[dst+2*len+1]=y AND 0FFh, [dst+1]=y SHR 8
+ dst=dst+2, src=base+step2
+ x=00000000h
+ for i=0 to len-1
+ x=x xor byte[addr+i], x=(x shr 8) xor edc_table[x and FFh]
+ word[addr+len]=x ;append EDC value (little endian)
+ for i=0 to FFh
+ x=i, for j=0 to 7, x=x shr 1, if carry then x=x xor D8018001h
+ edc_table[i]=x
+ GF8_LOG[00h]=00h, GF8_ILOG[FFh]=00h, x=01h
+ for i=00h to FEh
+ GF8_LOG[x]=i, GF8_ILOG[i]=x
+ x=x SHL 1, if carry8bit then x=x xor 1dh
+ for j=0 to 42
+ xx=GF8_ILOG[44-j], yy=subfunc(xx xor 1,19h)
+ xx=subfunc(xx,01h), xx=subfunc(xx xor 1,18h)
+ xx=GF8_LOG[xx], yy = GF8_LOG[yy]
+ GF8_PRODUCT[j,0]=0000h
+ for i=01h to FFh
+ x=xx+GF8_LOG[i], if x>=255 then x=x-255
+ y=yy+GF8_LOG[i], if y>=255 then y=y-255
+ GF8_PRODUCT[j,i]=GF8_ILOG[x]+(GF8_ILOG[y] shl 8)
+ if a>0 then
+ a=GF8_LOG[a]-b, if a<0 then a=a+255
+ a=GF8_ILOG[a]
+ return(a)
+Scambling does XOR the data sectors with random values (done to avoid regular
+patterns). The scrambling is applied to Data sector bytes[00Ch..92Fh] (not to
+CD-DA audio sectors, and not to the leading 12-byte Sync mark in Data sectors).
+The (de-)scrambling is done automatically by the CDROM controller, so disc
+images should usually contain unscrambled data (there are some exceptions such
+like CD-i discs that have audio and data sectors mixed inside of the same
+track; which may confuse the CDROM controller about whether or not to apply
+scrambling to which sectors; so one may need to manually XOR the faulty sectors
+in the disc image).
+The scrambling pattern is derived from a 15bit polynomial counter (much like a
+noise generator in sound chips). The data bits are XORed with the counters low
+bit, and the counters lower 2bit are XORed with each other, and shifted in to
+the counters upper bit. To compute 8 bits and once, and store them in a
+924h-byte table:
+
poly=0001h ;init 15bit polynomial counter
+ for i=0 to 924h-1
+ scramble_table[i]=poly AND FFh
+ poly=(((poly XOR poly/2) AND 0FFh)*80h) XOR (poly/100h)
+ next i
+ 01h,80h,00h,60h,00h,28h,00h,1Eh,80h,08h,60h,06h,A8h,02h,FEh,81h,
+ 80h,60h,60h,28h,28h,1Eh,9Eh,88h,68h,66h,AEh,AAh,FCh,7Fh,01h,E0h,
+ etc.
+The Sub-Header for normal data sectors is usually 00h,00h,08h,00h (some PSX
+sectors have 09h instead 08h, indicating the end of "something" or so?
0-7 File Number (00h..FFh) (for Audio/Video Interleave, see below)
+ 0-4 Channel Number (00h..1Fh) (for Audio/Video Interleave, see below)
+ 5-7 Should be always zero
+ 0 End of Record (EOR) (all Volume Descriptors, and all sectors with EOF)
+ 1 Video ;\Sector Type (usually ONE of these bits should be set)
+ 2 Audio ; Note: PSX .STR files are declared as Data (not as Video)
+ 3 Data ;/
+ 4 Trigger (for application use)
+ 5 Form2 (0=Form1/800h-byte data, 1=Form2, 914h-byte data)
+ 6 Real Time (RT)
+ 7 End of File (EOF) (or end of Directory/PathTable/VolumeTerminator)
+When used for Data sectors:
+
0-7 Reserved (00h)
+ 0-1 Mono/Stereo (0=Mono, 1=Stereo, 2-3=Reserved)
+ 2-2 Sample Rate (0=37800Hz, 1=18900Hz, 2-3=Reserved)
+ 4-5 Bits per Sample (0=Normal/4bit, 1=8bit, 2-3=Reserved)
+ 6 Emphasis (0=Normal/Off, 1=Emphasis)
+ 7 Reserved (0)
+The CDROM drive mechanics are working best when continously following the data
+spiral on the disk, that works fine for uncompressed Audio Data at normal
+speed, but compressed Audio Data the disk is spinning much too fast. To avoid
+the drive to need to pause reading or to do permanent backwards seeking, CD-XA
+allows to store data interleaved in separate files/channels. With common
+interleave values like so:
+
Interleave Data Format
+ 1/1 (none) 44100Hz Stereo CD Audio at normal speed
+ 1/8 37800Hz Stereo ADPCM compressed Audio at double speed
+ 1/16 18900Hz Stereo ADPCM compressed Audio at double speed
+ 1/16 37800Hz Mono ADPCM compressed Audio at double speed
+ 1/32 18900Hz Mono ADPCM compressed Audio at double speed
+ 7/8 15fps 320x224 pixel MDEC compressed Videos at double speed
+ Unknown if 1/16 and 1/32 interleaves are actually possible (the PSX cdrom
+ controller seems to overwrite the IC303 sector buffer entries once every
+ eight sectors, so ADPCM data may get destroyed on interleaves above 1/8).
+ (Crash Team Racing uses 37800Hz Mono at Double speed, so 1/16 must work).
+ one file with eight 1/8 audio channels
+ one file with one 1/8 audio channels, plus one 7/8 video channel (*)
+ one file with one 1/8 audio channels, plus 7 unused channels
+ eight different files with one 1/8 audio channel each
+ etc.
+There are different ways to mark unused sectors in interleaved streams. Ace
+Combat 3 uses Channel=FFh=Invalid. Tron Bonne uses Submode=00h=Nothing
+(notably, that game has a 74Mbyte XA file that leaves about 75% unused).
+
Subheader bytes: 01h,FFh,64h,01h ;Ace Combat 3 Electrosphere
+ Subheader bytes: 01h,00h,00h,00h ;Misadventures of Tron Bonne (XA\*.XA)
+With the above Interleave, files can be played continously at real time - that,
+unless read-errors do occur. In that case the drive controller would usually
+perform time-consuming error-correction and/or read-retries. For video/audio
+streaming the resulting delay would be tendencially more annoying as than
+processing or skipping the incorrect data.
+In such cases the drive controller is allowed to ignore read errors; that
+probably on sectors that have the Real Time (RT) flag set in their subheaders.
+The controller is probably doing some read-ahead buffering (so, if it has
+buffered enough data, then it may still perform read retries and/or error
+correction, as long as it doesn't affect real time playback).
CD-ROM XA ADPCM is used for Audio data compression. Each 16bit sample is
+encoded in 4bit nibbles; so the compression rate is almost 1:4 (only almost 1:4
+because there are 16 header bytes within each 128-byte portion). The data is
+usually/always stored on 914h-byte sectors (without error correction).
The Subheader (see previous chapter) contains important info for ADPCM: The
+file/channel numbers for Interleaved data, and the codinginfo flags:
+mono/stereo flag, 37800Hz/18900Hz sampling rate, 4bit/8bit format, and
+emphasis.
Each sector consists of 12h 128-byte portions (=900h bytes) (the remaining 14h
+bytes of the sectors 914h-byte data region are 00h filled).
+The separate 128-byte portions consist of a 16-byte header,
+
00h..03h Copy of below 4 bytes (at 04h..07h)
+ 04h Header for 1st Block/Mono, or 1st Block/Left
+ 05h Header for 2nd Block/Mono, or 1st Block/Right
+ 06h Header for 3rd Block/Mono, or 2nd Block/Left
+ 07h Header for 4th Block/Mono, or 2nd Block/Right
+ 08h Header for 5th Block/Mono, or 3rd Block/Left ;\unknown/unused
+ 09h Header for 6th Block/Mono, or 3rd Block/Right ; for 8bit ADPCM
+ 0Ah Header for 7th Block/Mono, or 4th Block/Left ; (maybe 0, or maybe
+ 0Bh Header for 8th Block/Mono, or 4th Block/Right ;/copy of above)
+ 0Ch..0Fh Copy of above 4 bytes (at 08h..0Bh)
+ 10h..13h 1st Data Word (packed 1st samples for 2-8 blocks)
+ 14h..17h 2nd Data Word (packed 2nd samples for 2-8 blocks)
+ 18h..1Bh 3rd Data Word (packed 3rd samples for 2-8 blocks)
+ ... Nth Data Word (packed Nth samples for 2-8 blocks)
+ 7Ch..7Fh 28th Data Word (packed 28th samples for 2-8 blocks)
+ 0-3 Shift (0..12) (0=Loudest) (13..15=Reserved/Same as 9)
+ 4-5 Filter (0..3) (only four filters, unlike SPU-ADPCM which has five)
+ 6-7 Unused (should be 0)
+ 0-3 Nibble for 1st Block/Mono, or 1st Block/Left (-8h..+7h)
+ 4-7 Nibble for 2nd Block/Mono, or 1st Block/Right (-8h..+7h)
+ 8-11 Nibble for 3rd Block/Mono, or 2nd Block/Left (-8h..+7h)
+ 12-15 Nibble for 4th Block/Mono, or 2nd Block/Right (-8h..+7h)
+ 16-19 Nibble for 5th Block/Mono, or 3rd Block/Left (-8h..+7h)
+ 20-23 Nibble for 6th Block/Mono, or 3rd Block/Right (-8h..+7h)
+ 24-27 Nibble for 7th Block/Mono, or 4th Block/Left (-8h..+7h)
+ 28-31 Nibble for 8th Block/Mono, or 4th Block/Right (-8h..+7h)
+ 0-7 Byte for 1st Block/Mono, or 1st Block/Left (-80h..+7Fh)
+ 8-15 Byte for 2nd Block/Mono, or 1st Block/Right (-80h..+7Fh)
+ 16-23 Byte for 3rd Block/Mono, or 2nd Block/Left (-80h..+7Fh)
+ 24-31 Byte for 4th Block/Mono, or 2nd Block/Right (-80h..+7Fh)
+ src=src+12+4+8 ;skip sync,header,subheader
+ for i=0 to 11h
+ for blk=0 to 3
+ IF stereo ;left-samples (LO-nibbles), plus right-samples (HI-nibbles)
+ decode_28_nibbles(src,blk,0,dst_left,old_left,older_left)
+ decode_28_nibbles(src,blk,1,dst_right,old_right,older_right)
+ ELSE ;first 28 samples (LO-nibbles), plus next 28 samples (HI-nibbles)
+ decode_28_nibbles(src,blk,0,dst_mono,old_mono,older_mono)
+ decode_28_nibbles(src,blk,1,dst_mono,old_mono,older_mono)
+ ENDIF
+ next blk
+ src=src+128
+ next i
+ src=src+14h+4 ;skip padding,edc
+ shift = 12 - (src[4+blk*2+nibble] AND 0Fh)
+ filter = (src[4+blk*2+nibble] AND 30h) SHR 4
+ f0 = pos_xa_adpcm_table[filter]
+ f1 = neg_xa_adpcm_table[filter]
+ for j=0 to 27
+ t = signed4bit((src[16+blk+j*4] SHR (nibble*4)) AND 0Fh)
+ s = (t SHL shift) + ((old*f0 + older*f1+32)/64);
+ s = MinMax(s,-8000h,+7FFFh)
+ halfword[dst]=s, dst=dst+2, older=old, old=s
+ next j
+ pos_xa_adpcm_table[0..4] = (0, +60, +115, +98, +122)
+ neg_xa_adpcm_table[0..4] = (0, 0, -52, -55, -60)
+The incoming old/older values are usually that from the previous part, or
+garbage (in case of decoding errors in the previous part), or whatever (in case
+there was no previous part) (ie. maybe zero on power-up?) (and maybe there's
+also a way to reset the values to zero at the begin of a new file, or *maybe*
+it's silently done automatically when issuing seek commands?).
The CDROM decoder is applying some weird 25-point zigzag interpolation when
+resampling the 37800Hz XA-ADPCM output to 44100Hz. This part is different from
+SPU-ADPCM (which uses 4-point gaussian pitch interpolations). For example,
+XA-ADPCM interpolation applied to a square wave looks like this:
+
. .
+ .--------------. | | | |
+ | | .'.'.'----'.'.'.
+ | | | | | |
+ | | | |
+ | Decompressed | | Final |
+ | XA-ADPCM | | XA-ADPCM |
+ | Waveform | | Output |
+ | | | | | |
+ | | ---.'.'.' '.'.'.---
+ --------' '-------- | | | |
+ ' '
+<B> Output37800Hz(sample):</B>
+ ringbuf[p AND 1Fh]=sample, p=p+1, sixstep=sixstep-1
+ if sixstep=0
+ sixstep=6
+ Ouput44100Hz(ZigZagInterpolate(p,Table1))
+ Ouput44100Hz(ZigZagInterpolate(p,Table2))
+ Ouput44100Hz(ZigZagInterpolate(p,Table3))
+ Ouput44100Hz(ZigZagInterpolate(p,Table4))
+ Ouput44100Hz(ZigZagInterpolate(p,Table5))
+ Ouput44100Hz(ZigZagInterpolate(p,Table6))
+ Ouput44100Hz(ZigZagInterpolate(p,Table7))
+ endif
+<B> ZigZagInterpolate(p,TableX):</B>
+ sum=0
+ for i=1 to 29, sum=sum+(ringbuf[(p-i) AND 1Fh]*TableX[i])/8000h, next i
+ return MinMax(sum,-8000h,+7FFFh)
+<B> Table1, Table2, Table3, Table4, Table5, Table6, Table7 ;Index</B>
+ 0 , 0 , 0 , 0 , -0001h, +0002h, -0005h ;1
+ 0 , 0 , 0 , -0001h, +0003h, -0008h, +0011h ;2
+ 0 , 0 , -0001h, +0003h, -0008h, +0010h, -0023h ;3
+ 0 , -0002h, +0003h, -0008h, +0011h, -0023h, +0046h ;4
+ 0 , 0 , -0002h, +0006h, -0010h, +002Bh, -0017h ;5
+ -0002h, +0003h, -0005h, +0005h, +000Ah, +001Ah, -0044h ;6
+ +000Ah, -0013h, +001Fh, -001Bh, +006Bh, -00EBh, +015Bh ;7
+ -0022h, +003Ch, -004Ah, +00A6h, -016Dh, +027Bh, -0347h ;8
+ +0041h, -004Bh, +00B3h, -01A8h, +0350h, -0548h, +080Eh ;9
+ -0054h, +00A2h, -0192h, +0372h, -0623h, +0AFAh, -1249h ;10
+ +0034h, -00E3h, +02B1h, -05BFh, +0BCDh, -16FAh, +3C07h ;11
+ +0009h, +0132h, -039Eh, +09B8h, -1780h, +53E0h, +53E0h ;12
+ -010Ah, -0043h, +04F8h, -11B4h, +6794h, +3C07h, -16FAh ;13
+ +0400h, -0267h, -05A6h, +74BBh, +234Ch, -1249h, +0AFAh ;14
+ -0A78h, +0C9Dh, +7939h, +0C9Dh, -0A78h, +080Eh, -0548h ;15
+ +234Ch, +74BBh, -05A6h, -0267h, +0400h, -0347h, +027Bh ;16
+ +6794h, -11B4h, +04F8h, -0043h, -010Ah, +015Bh, -00EBh ;17
+ -1780h, +09B8h, -039Eh, +0132h, +0009h, -0044h, +001Ah ;18
+ +0BCDh, -05BFh, +02B1h, -00E3h, +0034h, -0017h, +002Bh ;19
+ -0623h, +0372h, -0192h, +00A2h, -0054h, +0046h, -0023h ;20
+ +0350h, -01A8h, +00B3h, -004Bh, +0041h, -0023h, +0010h ;21
+ -016Dh, +00A6h, -004Ah, +003Ch, -0022h, +0011h, -0008h ;22
+ +006Bh, -001Bh, +001Fh, -0013h, +000Ah, -0005h, +0002h ;23
+ +000Ah, +0005h, -0005h, +0003h, -0001h, 0 , 0 ;24
+ -0010h, +0006h, -0002h, 0 , 0 , 0 , 0 ;25
+ +0011h, -0008h, +0003h, -0002h, +0001h, 0 , 0 ;26
+ -0008h, +0003h, -0001h, 0 , 0 , 0 , 0 ;27
+ +0003h, -0001h, 0 , 0 , 0 , 0 , 0 ;28
+ -0001h, 0 , 0 , 0 , 0 , 0 , 0 ;29
+With XA-Emphasis enabled in Sub-header, output will appear as so:
+
.------------. ....-----.
+ | | .'' |
+ | Raw | .' XA |
+ | ADPCM | | Emphasis '.
+ | Waveform | | Output '..
+ --------' '---------- --------' ''''---
+The hardware does contain some six-step counter (for interpolating 37800Hz to
+44100Hz, ie. to insert one extra sample after each six samples). The 900h-byte
+sectors contain a multiple of six samples, so the counter will be always same
+before & after playing a sector. However, the initial counter value on
+power-up is uninitialized random (and the counter will fallback to that initial
+random setting after each 900h-byte sector).
When reading files that consist of 914h-byte sectors on a PC, the PC seems to
+automatically insert a 2Ch-byte RIFF fileheader. Like so, for ADPCM audio
+files:
+
00h 4 "RIFF"
+ 04h 4 Total Filesize (minus 8)
+ 08h 8 "CDXAfmt "
+ 10h 4 Size of below stuff (10h)
+ 14h 14 Stuff (looks like the "LEN_SU" region from XA-Directory Record)
+ 22h 2 Zero (probably just dummy padding for 32bit alignment)
+ 24h 4 "data"
+ 28h 4 Size of following data (usually N*930h)
+The first 16 sectors on the first track are the system area, for a Playstation
+disk, it contains the following:
+
Sector 0..3 - Zerofilled (Mode2/Form1, 4x800h bytes, plus ECC/EDC)
+ Sector 4 - Licence String
+ Sector 5..11 - Playstation Logo (3278h bytes) (remaining bytes FFh-filled)
+ Sector 12..15 - Zerofilled (Mode2/Form2, 4x914h bytes, plus EDC)
+ 000h 32 Line 1 (" Licensed by ")
+ 020h 32+6 Line 2 (EU) ("Sony Computer Entertainment Euro"," pe ") ;\either
+ 020h 32+1 Line 2 (JP) ("Sony Computer Entertainment Inc.",0Ah) ; one of
+ 020h 32+6 Line 2 (US) ("Sony Computer Entertainment Amer"," ica ") ;/these
+ 041h 1983 Empty (JP) (filled by repeating pattern 62x30h,1x0Ah, 1x30h)
+ 046h 1978 Empty (EU/US) (filled by 00h-bytes)
+ 0000h .. 41h,00h,00h,00h,00h,00h,00h,00h,01h,00h,00h,00h,1Ch,23h,00h,00h
+ 0010h .. 51h,01h,00h,00h,A4h,2Dh,00h,00h,99h,00h,00h,00h,1Ch,00h,00h,00h
+ 0020h .. ...
+ 3278h 588h FF-filled (remaining bytes on sector 11)
+Playstation disks usually have only two Volume Descriptors,
+
Sector 16 - Primary Volume Descriptor
+ Sector 17 - Volume Descriptor Set Terminator
+ 000h 1 Volume Descriptor Type (01h=Primary Volume Descriptor)
+ 001h 5 Standard Identifier ("CD001")
+ 006h 1 Volume Descriptor Version (01h=Standard)
+ 007h 1 Reserved (00h)
+ 008h 32 System Identifier (a-characters) ("PLAYSTATION")
+ 028h 32 Volume Identifier (d-characters) (max 8 chars for PSX?)
+ 048h 8 Reserved (00h)
+ 050h 8 Volume Space Size (2x32bit, number of logical blocks)
+ 058h 32 Reserved (00h)
+ 078h 4 Volume Set Size (2x16bit) (usually 0001h)
+ 07Ch 4 Volume Sequence Number (2x16bit) (usually 0001h)
+ 080h 4 Logical Block Size in Bytes (2x16bit) (usually 0800h) (1 sector)
+ 084h 8 Path Table Size in Bytes (2x32bit) (max 800h for PSX)
+ 08Ch 4 Path Table 1 Block Number (32bit little-endian)
+ 090h 4 Path Table 2 Block Number (32bit little-endian) (or 0=None)
+ 094h 4 Path Table 3 Block Number (32bit big-endian)
+ 098h 4 Path Table 4 Block Number (32bit big-endian) (or 0=None)
+ 09Ch 34 Root Directory Record (see next chapter)
+ 0BEh 128 Volume Set Identifier (d-characters) (usually empty)
+ 13Eh 128 Publisher Identifier (a-characters) (company name)
+ 1BEh 128 Data Preparer Identifier (a-characters) (empty or other)
+ 23Eh 128 Application Identifier (a-characters) ("PLAYSTATION")
+ 2BEh 37 Copyright Filename ("FILENAME.EXT;VER") (empty or text)
+ 2E3h 37 Abstract Filename ("FILENAME.EXT;VER") (empty)
+ 308h 37 Bibliographic Filename ("FILENAME.EXT;VER") (empty)
+ 32Dh 17 Volume Creation Timestamp ("YYYYMMDDHHMMSSFF",timezone)
+ 33Eh 17 Volume Modification Timestamp ("0000000000000000",00h)
+ 34Fh 17 Volume Expiration Timestamp ("0000000000000000",00h)
+ 360h 17 Volume Effective Timestamp ("0000000000000000",00h)
+ 371h 1 File Structure Version (01h=Standard)
+ 372h 1 Reserved for future (00h-filled)
+ 373h 141 Application Use Area (00h-filled for PSX and VCD)
+ 400h 8 CD-XA Identifying Signature ("CD-XA001" for PSX and VCD)
+ 408h 2 CD-XA Flags (unknown purpose) (00h-filled for PSX and VCD)
+ 40Ah 8 CD-XA Startup Directory (00h-filled for PSX and VCD)
+ 412h 8 CD-XA Reserved (00h-filled for PSX and VCD)
+ 41Ah 345 Application Use Area (00h-filled for PSX and VCD)
+ 573h 653 Reserved for future (00h-filled)
+ 000h 1 Volume Descriptor Type (FFh=Terminator)
+ 001h 5 Standard Identifier ("CD001")
+ 006h 1 Terminator Version (01h=Standard)
+ 007h 2041 Reserved (00h-filled)
+ 000h 1 Volume Descriptor Type (00h=Boot Record)
+ 001h 5 Standard Identifier ("CD001")
+ 006h 1 Boot Record Version (01h=Standard)
+ 007h 32 Boot System Identifier (a-characters)
+ 027h 32 Boot Identifier (a-characters)
+ 047h 1977 Boot System Use (not specified content)
+ 000h 1 Volume Descriptor Type (02h=Supplementary Volume Descriptor)
+ 001h .. Same as for Primary Volume Descriptor (see there)
+ 007h 1 Volume Flags (8bit)
+ 008h .. Same as for Primary Volume Descriptor (see there)
+ 058h 32 Escape Sequences (32 bytes)
+ 078h .. Same as for Primary Volume Descriptor (see there)
+ 000h 1 Volume Descriptor Type (03h=Volume Partition Descriptor)
+ 001h 5 Standard Identifier ("CD001")
+ 006h 1 Volume Partition Version (01h=Standard)
+ 007h 1 Reserved (00h)
+ 008h 32 System Identifier (a-characters) (32 bytes)
+ 028h 32 Volume Partition Identifier (d-characters) (32 bytes)
+ 048h 8 Volume Partition Location (2x32bit) Logical Block Number
+ 050h 8 Volume Partition Size (2x32bit) Number of Logical Blocks
+ 058h 1960 System Use (not specified content)
+ 000h 1 Volume Descriptor Type (04h..FEh=Reserved, don't use)
+ 001h 2047 Reserved (don't use)
+The location of the Root Directory is described by a 34-byte Directory Record
+being located in Primary Volume Descriptor entries 09Ch..0BDh. The data therein
+is: Block Number (usually 22 on PSX disks), LEN_FI=01h, Name=00h, and,
+LEN_SU=00h (due to the 34-byte limit).
00h 1 Length of Directory Record (LEN_DR) (33+LEN_FI+pad+LEN_SU) (0=Pad)
+ 01h 1 Extended Attribute Record Length (usually 00h)
+ 02h 8 Data Logical Block Number (2x32bit)
+ 0Ah 8 Data Size in Bytes (2x32bit)
+ 12h 7 Recording Timestamp (yy-1900,mm,dd,hh,mm,ss,timezone)
+ 19h 1 File Flags 8 bits (usually 00h=File, or 02h=Directory)
+ 1Ah 1 File Unit Size (usually 00h)
+ 1Bh 1 Interleave Gap Size (usually 00h)
+ 1Ch 4 Volume Sequence Number (2x16bit, usually 0001h)
+ 20h 1 Length of Name (LEN_FI)
+ 21h LEN_FI File/Directory Name ("FILENAME.EXT;1" or "DIR_NAME" or 00h or 01h)
+ xxh 0..1 Padding Field (00h) (only if LEN_FI is even)
+ xxh LEN_SU System Use (LEN_SU bytes) (see below for CD-XA disks)
+ 00h 2 Owner ID Group (whatever, usually 0000h, big endian)
+ 02h 2 Owner ID User (whatever, usually 0000h, big endian)
+ 04h 2 File Attributes (big endian):
+ 0 Owner Read (usually 1)
+ 1 Reserved (0)
+ 2 Owner Execute (usually 1)
+ 3 Reserved (0)
+ 4 Group Read (usually 1)
+ 5 Reserved (0)
+ 6 Group Execute (usually 1)
+ 7 Reserved (0)
+ 8 World Read (usually 1)
+ 9 Reserved (0)
+ 10 World Execute (usually 1)
+ 11 IS_MODE2 (0=MODE1 or CD-DA, 1=MODE2)
+ 12 IS_MODE2_FORM2 (0=FORM1, 1=FORM2)
+ 13 IS_INTERLEAVED (0=No, 1=Yes...?) (by file and/or channel?)
+ 14 IS_CDDA (0=Data or ADPCM, 1=CD-DA Audio Track)
+ 15 IS_DIRECTORY (0=File or CD-DA, 1=Directory Record)
+ Commonly used Attributes are:
+ 0D55h=Normal Binary File (with 800h-byte sectors)
+ 1555h=Uncommon (fade to black .DPS and .XA files)
+ 2555h=Uncommon (wipeout .AV files) (MODE1 ??)
+ 4555h=CD-DA Audio Track (wipeout .SWP files, alone .WAV file)
+ 3D55h=Streaming File (ADPCM and/or MDEC or so)
+ 8D55h=Directory Record (parent-, current-, or sub-directory)
+ 06h 2 Signature ("XA")
+ 08h 1 File Number (Must match Subheader's File Number)
+ 09h 5 Reserved (00h-filled)
+ - Directory sizes are always rounded up to N*800h-bytes.
+ - Directory entries should not cross 800h-byte sector boundaries.
+ There may be further directory entries on the next sector after the padding.
+ To deal with that, skip 00h-bytes until finding a nonzero LEN_DR value (or
+ slightly faster, upon a 00h-byte, directly jump to next sector instead of
+ doing a slow byte-by-byte skip).
+ Note: Padding between sectors does rarely happen on PSX discs because the
+ PSX kernel supports max 800h bytes per directory (one exception is PSX Hot
+ Shots Golf 2, which has an ISO directory with more than 800h bytes; it does
+ use a lookup file instead of actually parsing the while ISO directory).
+The Path Table contain a summary of the directory names (the same information
+is also stored in the directory records, so programs may either use path tables
+or directory records; the path tables are allowing to read the whole directory
+tree quickly at once, without neeeding to seek from directory to directory).
+Path Table 1 is in Little-Endian format, Path Table 3 contains the same data in
+Big-Endian format. Path Table 2 and 4 are optional copies of Table 1 and 3. The
+size and location of the tables is stored in Volume Descriptor entries
+084h..09Bh. The format of the separate entries within a Path Table is,
+
00h 1 Length of Directory Name (LEN_DI) (01h..08h for PSX)
+ 01h 1 Extended Attribute Record Length (usually 00h)
+ 02h 4 Directory Logical Block Number
+ 06h 2 Parent Directory Number (0001h and up)
+ 08h LEN_DI Directory Name (d-characters, d1-characters) (or 00h for Root)
+ xxh 0..1 Padding Field (00h) (only if LEN_FI is odd)
+If present, an Extended Attribute Record shall be recorded over at least one
+Logical Block. It shall have the following contents.
+
00h 4 Owner Identification (numerical value) ;\used only if
+ 04h 4 Group Identification (numerical value) ; File Flags Bit4=1
+ 08h 2 Permission Flags (16bit, little-endian) ;/
+ 0Ah 17 File Creation Timestamp ("YYYYMMDDHHMMSSFF",timezone)
+ 1Bh 17 File Modification Timestamp ("0000000000000000",00h)
+ 2Ch 17 File Expiration Timestamp ("0000000000000000",00h)
+ 3Dh 17 File Effective Timestamp ("0000000000000000",00h)
+ 4Eh 1 Record Format (numerical value)
+ 4Fh 1 Record Attributes (numerical value)
+ 50h 4 Record Length (numerical value)
+ 54h 32 System Identifier (a-characters, a1-characters)
+ 74h 64 System Use (not specified content)
+ B4h 1 Extended Attribute Record Version (numerical value)
+ B5h 1 Length of Escape Sequences (LEN_ESC)
+ B6h 64 Reserved for future standardization (00h-filled)
+ F6h 4 Length of Application Use (LEN_AU)
+ FAh LEN_AU Application Use
+ xxh LEN_ESC Escape Sequences
+All 16bit and 32bit numbers in the ISO region are stored twice, once in
+Little-Endian order, and then in Big-Endian Order. For example,
+
2x16bit value 1234h ---> stored as 34h,12h,12h,34h
+ 2x32bit value 12345678h ---> stored as 78h,56h,34h,12h,12h,34h,56h,78h
+ "0..9", "A..Z", and "_"
+ "0..9", "A..Z", SPACE, "!"%&'()*+,-./:;<=>?_"
+SEPARATOR 1 = 2Eh (aka ".") (extension; eg. "EXT")
+SEPARATOR 2 = 3Bh (aka ";") (file version; "1".."32767")
The Volume Descriptors contain a number fixed-length string/filename fields
+(unlike the Directory Records and Path Tables which have variable lengths).
+These fields should be padded with SPACE characters if they are empty, or if
+the string is shorter than the maximum length.
+Filename fields in Volume Descriptors are referring to files in the Root
+Directory. On PSX disks, the filename fields are usually empty, but some disks
+are mis-using the Copyright Filename to store the Company Name (although no
+such file exists on the disk).
The various timestamps occupy 17 bytes each, in form of
+
"YYYYMMDDHHMMSSFF",timezone
+ "0000000000000000",00h ;empty timestamp
+Occupy only 7 bytes, in non-ascii format
+
year-1900,month,day,hour,minute,second,timezone
+ 00h,00h,00h,00h,00h,00h,00h ;empty timestamp
+If this Directory Record identifies a directory then bit 2,3,7 shall be set to
+ZERO.
+If no Extended Attribute Record is associated with the File Section identified
+by this Directory Record then bit positions 3 and 4 shall be set to ZERO.
+
0 Existence (0=Normal, 1=Hidden)
+ 1 Directory (0=File, 1=Directory)
+ 2 Associated File (0=Not an Associated File, 1=Associated File)
+ 3 Record
+ If set to ZERO, shall mean that the structure of the information in
+ the file is not specified by the Record Format field of any associated
+ Extended Attribute Record (see 9.5.8).
+ If set to ONE, shall mean that the structure of the information in
+ the file has a record format specified by a number other than zero in
+ the Record Format Field of the Extended Attribute Record (see 9.5.8).
+ 4 Restrictions (0=None, 1=Restricted via Permission Flags)
+ 5 Reserved (0)
+ 6 Reserved (0)
+ 7 Multi-Extent (0=Final Directory Record for the file, 1=Not final)
+ 0-3 Permissions for upper-class owners
+ 4-7 Permissions for normal owners
+ 8-11 Permissions for upper-class users
+ 12-15 Permissions for normal users
+ Bit0 Permission to read the file (0=Yes, 1=No)
+ Bit1 Must be set (1)
+ Bit2 Permission to execute the file (0=Yes, 1=No)
+ Bit3 Must be set (1)
+The discs contains two separate filesystems, the ISO one for backwards
+compatibilty, and the Joliet one with longer filenames and Unicode characters.
+
Sector 16 - Primary Volume Descriptor (with 8bit uppercase ASCII ISO names)
+ Sector 17 - Secondary Volume Descriptor (with 16bit Unicode Joliet names)
+ Sector 18 - Volume Descriptor Set Terminator
+ Sector .. - Path Tables and Directory Records (for ISO)
+ Sector .. - Path Tables and Directory Records (for Joliet)
+ Sector .. - File Data Sectors (shared for ISO and Joliet)
+This is using the same format as ISO Primary Volume Descriptor (but with some
+changed entries).
+CDROM ISO Volume Descriptors
+Changed entries are:
+
000h 1 Volume Descriptor Type (02h=Supplementary instead of 01h=Primary)
+ 007h 1 Volume Flags (whatever, instead of Reserved)
+ 008h 2x32 Identifier Strings (16-char Unicode instead 32-char ASCII)
+ 058h 32 Escape Sequences (see below, instead of Reserved)
+ 08Ch 4x4 Path Tables (point to new tables with Unicode chars)
+ 09Ch 34 Root Directory Record (point to root with Unicode chars)
+ 0BEh 4x128 Identifier Strings (64-char Unicode instead 128-char ASCII)
+ 2BEh 3x37 Filename Strings (18-char Unicode instead 37-char ASCII)
+ %/@ UCS-2 Level 1
+ %/C UCS-2 Level 2
+ %/E UCS-2 Level 3
+This is using the standard ISO format (but with 16bit Unicode characters
+instead of 8bit ASCII chars).
+CDROM ISO File and Directory Descriptors
All characters are stored in 16bit Big Endian format. The LEN_FI filename entry
+contains the length in bytes (ie. numchars*2). Charaters 0000h/0001h are
+current/parent directory. Characters 0020h and up can be used for
+file/directory names, except six reserved characters: */:;?\
+All names must be sorted by their character numbers, padded with zero (without
+attempting to merge uppercase, lowercase, or umlauts to nearby locations).
max 64 chars according to original Joliet specs from 1995
+ max 110 chars (on standard CDROMs, with LEN_SU=0)
+ max 103 chars (on CD-XA discs, with LEN_SU=14)
+Joliet Specification, CD-ROM Recording Spec ISO 9660:1988, Extensions for
+Unicode Version 1; May 22, 1995, Copyright 1995, Microsoft Corporation
+
http://littlesvr.ca/isomaster/resources/JolietSpecification.html
+The heart of the PSX copy-protection is the four-letter "SCEx" string, encoded
+in the wobble signal of original PSX disks, which cannot be reproduced by
+normal CD writers. The last letter varies depending on the region:
+
"SCEI" for Japan
+ "SCEA" for America (and all other NTSC countries except Japan)
+ "SCEE" for Europe (and all other PAL countries like Australia)
+A "blank" CDR contains a pre-formatted spiral on it. The number of windings in
+the spiral varies depending on the number of minutes that can be recorded on
+the disk. The spiral isn't made of a straight line (------), but rather a
+wobbled line (/\/\/), which is used to adjust the rotation speed during
+recording; at normal drive speed, wobble should produce a 22050Hz sine wave.
+Additionally, the CDR wobble is modulated to provide ATIP information, ATIP is
+used for locating and positioning during recording, and contains information
+about the approximate laser power necessary for recording, the last possible
+time location that lead out can start, and the disc application code.
+Wobble is commonly used only on (recordable) CDRs, ie. usually NOT on
+(readonly) CDROMs and Audio Disks. The copyprotected PSX CDROMs are having a
+short CDR-style wobble period in the first some seconds, which seems to contain
+the "SCEx" string instead of ATIP information.
Aside from the SCEx string, PSX disks are required to contain region and
+licence strings (in the ISO System Area, and in the .EXE file headers), and the
+"PS" logo (in the System Area, too). This data can be reproduced with normal CD
+writers, although it may be illegal to distribute unlicensed disks with licence
+strings.
A modchip is a small microcontroller which injects the "SCEx" signal to the
+mainboard, so the PSX can be booted even from CDRs which don't contain the
+"SCEx" string. Some modchips are additionally patching region checks contained
+in the BIOS ROM.
+Note: Although regular PSX disks are black, the hardware doesn't verify the
+color of the disks, and works also with normal silver disks.
Once when the PSX has recognized a disk with the "SCEx" signal, it'll be
+satisfied until a new disk is inserted, which is sensed by the SHELL_OPEN
+switch. When having that switch blocked, it is possible to insert a CDR without
+the PSX noticing that the disk was changed.
+Additionally, the trick requires some boot software that stops the drive motor
+(so the new disk can be inserted, despite of the PSX thinking that the drive
+door is still closed), and that does then start the boot executable on the new
+disk.
+The boot software can be stored on a special boot-disk (that do have the "SCEx"
+string on it). Alternately, a regular PSX game disk could be used, with the
+boot software stored somewhere else (eg. on Expansion ROM, or BIOS ROM
+replacement, or Memory Card).
The PSX can be quite easily booted via Expansion ROM, or BIOS ROM replacements,
+allowing to execute code that is stored in the ROM, or that is received via
+whatever serial or parallel cable connection from a PC.
+However, even with a BIOS replacement, the protection in the CDROM controller
+is still active, so the ROM can't read "clean" data from the CDROM Drive
+(unless the Disk-Swap trick is used).
+Whereas, no "clean" data doens't mean no data at all. The CDROM controller does
+still seem to output "raw" data (without removing the sector header, and
+without handling error correction, and with only limited accuracy on the sector
+position). So, eventually, a customized BIOS could convert the "raw" data to
+"clean" data.
There is an "official" backdoor that allows to disable the SCEx protection by
+software via secret commands (for example, sending those commands can be done
+via BIOS patches, nocash BIOS clone, or Expansion ROMs).
+CDROM - Secret Unlock Commands
Some games that load data from memory cards may get confused if the save data
+isn't formatted as how they expect it - with some fine tuning you can get them
+to "crash" in a manner that they do accidently execute bootcode stored on the
+memory card. This is how tonyhax's game exploits and FreePSXBoot's BIOS shell
+exploit work.
+Requires a tools to write to the memory card (eg. parallel port cable), and the
+memory card data customized for a specific game, and an original CDROM with
+that specific game. Once when the memory card code is booted, the Disk-Swap
+trick can be used.
The Old Crow mod chip source code works like so:
+
entrypoint: ;at power_up
+ gate=input/highz
+ data=input/highz
+ wait 50 ms
+ data=output/low
+ wait 850 ms
+ gate=output/low
+ wait 314 ms
+ loop:
+ wait 72 ms ;pause (eighteen "1=low" bits)
+ sendbyte("S") ;1st letter
+ sendbyte("C") ;2nd letter
+ sendbyte("E") ;3rd letter
+ sendbyte(...) ;4th letter (A, E, or I, depending on region)
+ goto loop
+ sendbyte(char):
+ sendbit(0) ;one start bit (0=highz)
+ for i=0 to 7
+ sendbit(char AND 1) ;output data (LSB first)
+ char=char/2
+ next i
+ sendbit(1) ;1st stop bit (1=low)
+ sendbit(1) ;2nd stop bit (1=low)
+ return
+ sendbit(bit):
+ if bit=1 then data=output/low elseif bit=0 then data=input/highz
+ wait 4 ms ;4ms per bit = 250 bits per second
+ return
+For older PSX boards (data/gate):
+
Board data gate
+ PU-xx unknown? unknown? ;older PSX boards
+ Board data sync
+ PU-23, PM-41 CXD2938Q.Pin42 CXD2938Q.Pin5 ;newer PSX and older PSone
+ PM-41(2) CXD2941R.Pin36 CXD2941R.Pin76 ;newer PSone boards
+Transfers the "SCEx" data. Note that the signal produced by the modchip is
+looking entirly different than the signal produced by original disks, the real
+signal would be modulated 22050Hz wobble, while the modchip is simply dragging
+the signal permanently LOW throughout "1" bits, and leaves it floating for "0"
+bits. Anyways the "faked" signal seems to be accurate enough to work.
The "gate" pin needs to be LOW only for use with original licensed disks
+(reportedly otherwise the SCEx string on that disks would conflict with the
+SCEx string from the modchip).
+At the mainboard side, the "gate" signal is an input, and "data" is an inverted
+output of the gate signal (so dragging gate to low, would cause data to go
+high).
The "sync" pin is a testpoint on the mainboard, which does (at single speed)
+output a frequency of circa 44.1kHz/6 (of which some clock pulses seem to be
+longer or shorter, probably to indicate adjustments to the rotation speed).
+Some modchips are connected directly to "sync" (so they are apparently
+synchronizing the data output with that signal; which is not implemented in the
+above source code).
+Anyways, other modchips are using a more simplified connection: The modchip
+itself connects only to the "data" pin, and "sync" is required to be wired to
+IC723.Pin17.
Modchips that are designed to work in different regions are sending a different
+string (SCEA, SCEE, SCEI) in each loop cycle. Due to the slow 250bps transfer
+rate, it may take a while until the PSX has received the correct string, so
+this multi-region technique may cause a noticeable boot-delay.
The Stealth connection is required for some newer games with anti-modchip
+protection, ie. games that refuse to run if they detect a modchip. The
+detection relies on the fact that the SCEx signal is normally received only
+when booting the disk, whilst older modchips were sending that signal
+permanently. Stealth modchips are sending the signal only on power-up (and when
+inserting a new disk, which can be sensed via SHELL_OPEN signal).
+Modchip detection reportedly works like so (not too sure if all commands are
+required, some seem to be rather offtopic):
+
1. Com 19h,20h ;Retrieve CDROM Controller timestamp
+ 2. Com 01h ;CdlNop: Get CD status
+ 3. Com 07h ;CdlMotorOn: Make CD-ROM drive ready (blah?)
+ 4. Com 02h,1,1,1 ;CdlSetloc(01:01:01) (sector that does NOT have SCEx data)
+ 5. Com 0Eh,1 ;CdlSetmode: Turn on CD-DA read mode
+ 6. Short Delay
+ 7. Com 16h ;CdlSeekP: Seek to Setloc's parameters (4426)
+ 8. Com 0Bh ;CdlMute: Turn off sound so CdlPlay is inaudible
+ 9. Com 03h ;CdlPlay: Start playing CD-DA.
+ 10. Com 19h,04h ;ResetSCExInfo (reset GetSCExInfo response to 0,0)
+ 11. Long Delay ;wait until the modchip (if any) has output SCEx data
+ 12. Com 19h,05h ;GetSCExInfo (returns total,success counters)
+ 13. Com 09h ;CdlPause: Stop command 19h.
+Typically connects to two or three BIOS address/data lines, apparently watching
+that signals, and dragging a data line LOW at certain time, to skip software
+based region checks (eg. allowing to play NTSC games on PAL consoles).
+Aside from the modchip connection, that additionally requires to adjust the
+video signal (in 60Hz NTSC mode, the PSX defaults to generate a NTSC video
+signal) (whilst most PAL screens can handle 60Hz refresh, they can't handle
+NTSC colors) (on PSone boards, this can be fixed simply by grounding the /PAL
+pin; IC502.Pin13) (on older PSX boards it seems to be required to install an
+external color clock generator).
Connection for 8pin "12C508" mod chip from fatcat.co.nz for a PAL PSone with
+PM-41 board (ie. with 208pin SPU CXD2938Q, and 52pin IC304 "C 3060,
+SC430943PB"):
+
1 3.5V (supply)
+ 2 IC304.Pin44 (unknown?) (XLAT)
+ 3 BIOS.Pin15 (D2)
+ 4 BIOS.Pin31 (A18)
+ 5 SPU.Pin5 ("sync")
+ 6 SPU.Pin42 ("data")
+ 7 IC304.Pin19 (SHELL_OPEN)
+ 8 GND (supply)
+The nocash PSX bios outputs the "data" signal on the A20 address line, so
+(aside from the BIOS chip) one only needs to install a 1N4148 diode and two
+wires to unlock the CDROM:
+
SPU.Pin42 "data" -------|>|------ CPU.Pin149 (A20)
+ SPU.Pin5 "sync" ---------------- IC723.Pin17
+The nocash kernel clone outputs a SCEX signal via A20 and A21 address lines,
+(so one won't need a separate modchip/microprocessor):
+
A20 = the normal SCEX signal (inverted ASCII, eg. "A" = BEh) ;all boards
+ A21 = uninverted SCEX signal (uninverted ASCII, eg. "A" = 41h) ;PU-7..PU-20
+ A21 = always 1 during SCEX output ;PU-22 and up
+ .--------.-. .--------.-.
+ GATE--------|C NPN | . DATA--------|C NPN | .
+ A20--[10K]--|B BC | | A21--[10K]--|B BC | |
+ GND---------|E 547 | ' GND---------|E 547 | '
+ '--------'-' '--------'-'
+ .-------------------.
+ A21----|OE1,OE2 |
+ A20----|IN1 74HC126 OUT1|--- DATA
+ WFCK---|IN2 OUT2|--- SYNC
+ '-------------------'
+ GATE---------GND
+ DATA---------A20
+ SYNC--------WFCK
+ DATA---|>|---A20
+ GATE is IC703.Pin2 (?) (8pin chip with marking "082B") ;PU-7? .. PU-16
+ GATE is IC706.Pin7/10 (16pin "118" (uPC5023GR-118) ;PU-18 .. PU-20
+ SYNC is IC723.Pin17(TEO)(20pin "SONY CXA2575N") ;PU-22 .. PM-41(2)
+ DATA is IC???.Pin7 (CG) (8pin chip with marking "2903") ;PU-7? .. PU-16
+ DATA is IC706.Pin1 (CG) (16pin "118" (uPC5023GR-118) ;PU-18 .. PU-20
+ DATA is HC05.Pin17 (CG) (52pin "SONY SC4309xxPB") ;PU-7 .. EARLY-PU-8
+ DATA is HC05.Pin32 (CG) (80pin "SONY E35D, 4246xx 185") ;LATE-PU-8 .. PU-20
+ DATA is SPU.Pin42 (CEI) (208pin "SONY CXD2938Q") ;PU-22 .. PM-41
+ DATA is SPU.Pin36?(CEI) (176pin "SONY CXD2941R") ;PM-41(2)
+ WFCK is SPU.Pin5 (WFCK) (208pin "SONY CXD2938Q") ;PU-22 .. PM-41
+ WFCK is SPU.Pin84(WFCK) (176pin "SONY CXD2941R") ;PM-41(2)
+ A20 is CPU.Pin149(A20) (208-pin CPU CXD8530 or CXD8606) ;PU-7 .. PM-41(2)
+ A20 is EXP.Pin28 (A20) (68-pin Expansion Port) ;PU-7 .. PU-22
+ A21 is CPU.Pin150(A21) (208-pin CPU CXD8530 or CXD8606) ;PU-7 .. PM-41(2)
+ A21 is EXP.Pin62 (A21) (68-pin Expansion Port) ;PU-7 .. PU-22
+LibCrypt is an additional copy-protection, used by about 100 PSX games. The
+protection uses a 16bit decryption key, which is stored as bad position data in
+Subchannel Q. The 16bit key is then used for a simple XOR-decryption on certain
+800h-byte sectors.
There are some variants on how the Subchannel Q data is modified:
+
1. 2 bits from both MSFs are modified,
+ CRC-16 is recalculated and XORed with 0x0080.
+ Games: MediEvil (E).
+ 2. 2 bits from both MSFs are modified,
+ original CRC-16 is XORed with 0x8001.
+ Games: CTR: Crash Team Racing (E) (No EDC), CTR: Crash Team Racing (E)
+ (EDC), Dino Crisis (E), Eagle One: Harrier Attack (E) et al.
+ 3. Either 2 bits or none from both MSFs are modified,
+ CRC-16 is recalculated and XORed with 0x0080.
+ Games: Ape Escape (S) et al.
+The modified sectors could be theoretically located anywhere on the disc,
+however, all known protected games are having them located on the same sectors:
+
No. <------- Minute=03/Normal -------> <------- Minute=09/Backup ------->
+ Bit15 14105 (03:08:05) 14110 (03:08:10) 42045 (09:20:45) 42050 (09:20:50)
+ Bit14 14231 (03:09:56) 14236 (03:09:61) 42166 (09:22:16) 42171 (09:22:21)
+ Bit13 14485 (03:13:10) 14490 (03:13:15) 42432 (09:25:57) 42437 (09:25:62)
+ Bit12 14579 (03:14:29) 14584 (03:14:34) 42580 (09:27:55) 42585 (09:27:60)
+ Bit11 14649 (03:15:24) 14654 (03:15:29) 42671 (09:28:71) 42676 (09:29:01)
+ Bit10 14899 (03:18:49) 14904 (03:18:54) 42813 (09:30:63) 42818 (09:30:68)
+ Bit9 15056 (03:20:56) 15061 (03:20:61) 43012 (09:33:37) 43017 (09:33:42)
+ Bit8 15130 (03:21:55) 15135 (03:21:60) 43177 (09:35:52) 43182 (09:35:57)
+ Bit7 15242 (03:23:17) 15247 (03:23:22) 43289 (09:37:14) 43294 (09:37:19)
+ Bit6 15312 (03:24:12) 15317 (03:24:17) 43354 (09:38:04) 43359 (09:38:09)
+ Bit5 15378 (03:25:03) 15383 (03:25:08) 43408 (09:38:58) 43413 (09:38:63)
+ Bit4 15628 (03:28:28) 15633 (03:28:33) 43634 (09:41:59) 43639 (09:41:64)
+ Bit3 15919 (03:32:19) 15924 (03:32:24) 43963 (09:46:13) 43968 (09:46:18)
+ Bit2 16031 (03:33:56) 16036 (03:33:61) 44054 (09:47:29) 44059 (09:47:34)
+ Bit1 16101 (03:34:51) 16106 (03:34:56) 44159 (09:48:59) 44164 (09:48:64)
+ Bit0 16167 (03:35:42) 16172 (03:35:47) 44312 (09:50:62) 44317 (09:50:67)
+Legacy of Kain (PAL) is reading the LibCrypt data during the title screen, and
+does then display GOT KEY!!! on TTY terminal (this, no matter if the correct
+16bit key was received).
+The actual protection jumps in a bit later (shortly after learning to glide,
+the game will hang when the first enemies appear if the key isn't okay).
+Thereafter, the 16bit key is kept used once and when to decrypt 800h-byte
+sector data via simple XORing.
+The 16bit key (and some other related counters/variables) aren't stored in RAM,
+but rather in COP0 debug registers (which are mis-used as general-purpose
+storage in this case), for example, the 16bit key is stored in LSBs of the
+"cop0r3" register.
+In particuar, the encryption is used for some of the BIGFILE.DAT folder
+headers:
+CDROM File Archive BIGFILE.DAT (Soul Reaver)
CDROM File Official Sony File Formats
CDROM File Playstation EXE and SYSTEM.CNF
+CDROM File PsyQ .CPE Files (Debug Executables)
+CDROM File PsyQ .SYM Files (Debug Information)
CDROM File Video Texture Image TIM/PXL/CLT (Sony)
+CDROM File Video Texture/Bitmap (Other)
+CDROM File Video 2D Graphics CEL/BGD/TSQ/ANM/SDF (Sony)
+CDROM File Video 3D Graphics TMD/PMD/TOD/HMD/RSD (Sony)
+CDROM File Video STR Streaming and BS Picture Compression (Sony)
CDROM File Audio Single Samples VAG (Sony)
+CDROM File Audio Sample Sets VAB and VH/VB (Sony)
+CDROM File Audio Sequences SEQ/SEP (Sony)
+CDROM File Audio Other Formats
+CDROM File Audio Streaming XA-ADPCM
+CDROM File Audio CD-DA Tracks
PSX titles are quite often using virtual filesystems, with numerous custom file
+archive formats.
+CDROM File Archives with Filename
+CDROM File Archives with Offset and Size
+CDROM File Archives with Offset
+CDROM File Archives with Size
+CDROM File Archives with Chunks
+CDROM File Archives with Folders
+CDROM File Archives in Hidden Sectors
+More misc stuff...
+CDROM File Archive HED/DAT/BNS/STR (Ape Escape)
+CDROM File Archive WAD.WAD, BIG.BIN, JESTERS.PKG (Crash/Herc/Pandemonium)
+CDROM File Archive BIGFILE.BIG (Gex)
+CDROM File Archive BIGFILE.DAT (Gex - Enter the Gecko)
+CDROM File Archive FF9 DB (Final Fantasy IX)
+CDROM File Archive Ace Combat 2 and 3
+CDROM File Archive NSD/NSF (Crash Bandicoot 1-3)
+CDROM File Archive STAGE.DIR and *.DAT (Metal Gear Solid)
+CDROM File Archive DRACULA.DAT (Dracula)
+CDROM File Archive Croc 1 (DIR, WAD, etc.)
+CDROM File Archive Croc 2 (DIR, WAD, etc.)
+CDROM File Archive Headerless Archives
+Using archives can avoid issues with the PSX's poorly implemented ISO
+filesystem: The PSX kernel supports max 800h bytes per directory, and lacks
+proper caching for most recently accessed directories (additionally, some
+archives can load the whole file/directory tree from continous sectors, which
+could be difficult in ISO filesystems).
CDROM File XYZ and Dummy/Null Files
CDROM Disk Images CCD/IMG/SUB (CloneCD)
+CDROM Disk Images CDI (DiscJuggler)
+CDROM Disk Images CUE/BIN/CDT (Cdrwin)
+CDROM Disk Images MDS/MDF (Alcohol 120%)
+CDROM Disk Images NRG (Nero)
+CDROM Disk Image/Containers CDZ
+CDROM Disk Image/Containers ECM
+CDROM Subchannel Images
+CDROM Disk Images Other Formats
The BIOS seems to support only (max) 8-letter filenames with 3-letter
+extension, typically all uppercase, eg. "FILENAME.EXT". Eventually, once when
+the executable has started, some programs might install drivers for long
+filenames(?)
The PSX uses the standard CDROM ISO9660 filesystem without any encryption (ie.
+you can put an original PSX CDROM into a DOS/Windows computer, and view the
+content of the files in text or hex editors without problems).
MagDemoNN is short for "Official U.S. Playstation Magazine Demo Disc NN"
https://psx.arthus.net/sdk/Psy-Q/DOCS/Devrefs/Filefrmt.pdf - Sony 1998
+
File Formats
+ (c) 1998 Sony Computer Entertainment Inc.
+ Publication date: November 1998
+ Chapter 1: Streaming Audio and Video Data
+ STR: Streaming (Movie) Data 1-3
+ BS: MDEC Bitstream Data 1-8
+ XA: CD-ROM Voice Data 1-31
+ Chapter 2: 3D Graphics
+ RSD: 3D Model Data [RSD,PLY,MAT,GRP,MSH,PVT,COD,MOT,OGP] 2-3
+ TMD: Modeling Data for OS Library 2-24
+ PMD: High-Speed Modeling Data 2-35
+ TOD: Animation Data 2-40
+ HMD: Hierarchical 3D Model, Animation and Other Data 2-49
+ Chapter 3: 2D Graphics
+ TIM: Screen Image Data 3-3
+ SDF: Sprite Editor Project File 3-8
+ PXL: Pixel Image Data 3-11
+ CLT: Palette Data 3-14
+ ANM: Animation Information 3-16
+ TSQ: Animation Time Sequence 3-22
+ CEL: Cell Data 3-23
+ BGD: BG Map Data 3-27
+ Chapter 4: Sound
+ SEQ: PS Sequence Data 4-3
+ SEP: PS Multi-Track Sequence Data 4-3
+ VAG: PS Single Waveform Data 4-5
+ VAB: PS Sound Source Data [VAB and VH/VB] 4-5
+ DA: CD-DA Data 4-7
+ Chapter 5: PDA and Memory Card
+ FAT: Memory Card File System Specification 5-3
+Contains boot info in ASCII/TXT format, similar to the CONFIG.SYS or
+AUTOEXEC.BAT files for MSDOS. A typical SYSTEM.CNF would look like so:
+
BOOT = cdrom:\abcd_123.45;1 arg ;boot exe (drive:\path\name.ext;version)
+ TCB = 4 ;HEX (=4 decimal) ;max number of threads
+ EVENT = 10 ;HEX (=16 decimal) ;max number of events
+ STACK = 801FFF00 ;HEX (=memtop-256)
+This is a normal executable (exactly as for the .EXE files, described below),
+however, the filename/extension is taken from the game code (the "ABCD-12345"
+text that is printed on the CD cover), but, with the minus replaced by an
+underscore, and due to the 8-letter filename limit, the last two characters are
+stored in the extension region.
+That "XXXX_NNN.NN" naming convention seems to apply for all official licensed
+PSX games. Wild Arms does unconventionally have the file in a separate folder,
+"EXE\SCUS_946.06".
PSX executables are having an 800h-byte header, followed by the code/data.
+
000h-007h ASCII ID "PS-X EXE"
+ 008h-00Fh Zerofilled
+ 010h Initial PC (usually 80010000h, or higher)
+ 014h Initial GP/R28 (usually 0)
+ 018h Destination Address in RAM (usually 80010000h, or higher)
+ 01Ch Filesize (must be N*800h) (excluding 800h-byte header)
+ 020h Data section Start Address (usually 0)
+ 024h Data Section Size in bytes (usually 0)
+ 028h BSS section Start Address (usually 0) (when below Size=None)
+ 02Ch BSS section Size in bytes (usually 0) (0=None)
+ 030h Initial SP/R29 & FP/R30 Base (usually 801FFFF0h) (or 0=None)
+ 034h Initial SP/R29 & FP/R30 Offs (usually 0, added to above Base)
+ 038h-04Bh Reserved for A(43h) Function (should be zerofilled in exefile)
+ 04Ch-xxxh ASCII marker
+ "Sony Computer Entertainment Inc. for Japan area"
+ "Sony Computer Entertainment Inc. for Europe area"
+ "Sony Computer Entertainment Inc. for North America area"
+ (or often zerofilled in some homebrew files)
+ (the BIOS doesn't verify this string, and boots fine without it)
+ xxxh-7FFh Zerofilled
+ 800h... Code/Data (loaded to entry[018h] and up)
+Fade to Black (CINE.EXR) contains ID "PS-X EXR" (instead "PS-X EXE") and string
+"PSX Relocable File - Delphine Software Int.", this is supposedly some custom
+relocatable exe file (unsupported by the PSX kernel).
Some PSX discs contain DOS or Windows .EXE files (with "MZ" headers), eg.
+devkit leftovers, or demos/gimmicks.
00h 4 File ID (01455043h aka "CPE",01h)
+ 00h 1 Chunk ID (00h)
+ 00h 1 Chunk ID (01h)
+ 01h 4 Address (usually 80010000h and up)
+ 05h 4 Size (LEN)
+ 09h LEN Data (binary EXE code/data)
+ 00h 1 Chunk ID (02h)
+ 01h 4 Address
+ 00h 1 Chunk ID (03h..06h)
+ 01h 2 Register (usually 0090h=Initial PC, aka Entrypoint)
+ 03h LEN Value (8bit..32bit)
+ 00h 1 Chunk ID (07h)
+ 01h 4 Workspace number (usually 00000000h)
+ 00h 1 Chunk ID (08h)
+ 01h 1 Unit (usually 00h)
+ 0000h 4 File ID ("CPE",01h)
+ 0004h 2 Select Unit 0 (08h,00h)
+ 0006h 7 Set Entrypoint 8001731Ch (03h,0090h,8001731Ch)
+ 000Dh 0Dh Load (01h,800195F8h,00000004h,0,0,0,0)
+ 001Ah .. Load (01h,80010000h,0000002Bh,...)
+ 004Eh .. Load (01h,8001065Ch,00000120h,...)
+ 0177h ... Load (01h,8001077Ch,0000012Ch,...)
+ 02ACh ... Load (01h,800108A8h,000000A4h,...)
+ ... ... Load (...)
+ 98F4h ... Load (01h,800195F0h,00000008h,...)
+ 9905h 1 End (00h)
+PsyQ .SYM Files contain debug info, usually bundled with PsyQ .MAP and Psy .CPE
+files. Those files are generated by PsyQ tools, which appear to be still in use
+for homebrew PSX titles.
+The files are occassionally also found on PSX CDROMs:
+
Legacy of Kain PAL version (\DEGUG\NTSC\KAIN2.SYM+MAP+CPE)
+ RC Revenge (\RELEASE.SYM)
+ Twisted Metal: Small Brawl (MagDemo54: TMSB\TM.SYM)
+ Jackie Chan Stuntmaster (GAME_REL.SYM+CPE)
+ SnoCross Championship Racing (MagDemo37: SNOCROSS\SNOW.TOC\SNOW.MAP)
+ Sled Storm (MagDemo24: DEBUG\MAIN.MAP)
+ E.T. Interplanetary Mission (MagDemo54: MEGA\MEGA.CSH\* has SYM+CPE+MAP)
+ 00h 4 File ID ("MND",01h)
+ 04h 4 Whatever (0,0,0,0) ;TOMB5: 0,02h,0,0
+ 08h .. Chunks (see below)
+ 00h 4 Address/Value
+ 04h 1 Chunk ID (01h/02h/05h/06h)
+ 05h 1 Symbol Length (LEN)
+ 06h LEN Symbol (eg. "VSync")
+ 00h 4 Address (for 1 line, starting at current line)
+ 04h 1 Chunk ID (80h)
+ 00h 4 Address (for N lines, starting at current line)
+ 04h 1 Chunk ID (82h)
+ 05h 1 Number of Lines (00h=None, or 02h and up?)
+ 00h 4 Address (for N lines, starting at current line)
+ 04h 1 Chunk ID (84h)
+ 05h 2 Number of Lines (?)
+ 00h 4 Address (for 1 line, starting at newly assigned current line)
+ 04h 1 Chunk ID (84h)
+ 05h 4 Absolute Line Number (rather than number of lines) (?)
+ 00h 4 Address (start address)
+ 04h 1 Chunk ID (88h=Filename)
+ 05h 4 First Line Number (after comments/definitions) (32bit?)
+ 09h 1 Filename Length (LEN)
+ 0Ah LEN Filename (eg. "C:\path\main.c")
+ 00h 4 Address (end address)
+ 04h 1 Chunk ID (8Ah)
+ 00h 4 Address
+ 04h 1 Chunk ID (8Ch)
+ 05h 4 Whatever (1Eh,00h,20h,00h) ;or 1Eh,00h,18h,00h
+ 09h 4 Whatever (00h,00h,1Fh,00h)
+ 0Dh 4 Whatever (00h,00h,00h,C0h)
+ 11h 4 Whatever (FCh,FFh,FFh,FFh) ;mask? neg.offset?
+ 15h 4 Whatever (10h,00h,00h,00h) <-- line number (32bit?)
+ 19h 1 Filename Length (LEN1)
+ 1Ah LEN1 Filename (eg. "C:\path\main.c")
+ xxh 1 Symbol Length (LEN2)
+ xxh LEN2 Symbol (eg. "VSync")
+ 00h 4 Address
+ 04h 1 Chunk ID (8Eh)
+ 05h 4 Line Number <-- line number (32bit?)
+Maybe line numbers? Or end of definitions for incoming parameters?
+
00h 4 Address
+ 04h 1 Chunk ID (90h/92h)
+ 05h 4 Whatever (1Fh,00h,00h,00h) <-- line number relative to main.start?
+ 00h 4 Offset (when used within a structure, or stack-N, or otherwise zero)
+ 04h 1 Chunk ID (94h)
+ 05h 2 Class (000Dh=Type.alias, 000Ah=Address, 0001h=Stack, 0002h=Addr)
+ 07h 2 Type (XX = 8bit,16bit,signed,etc.?)
+ 09h 4 Zero, or Size in Bytes (for "memblocks")
+ 0xh 1 Symbol Name Length (LEN)
+ 0xh LEN Symbol Name (eg. "size_t")
+ 00h 4 Offset (when used within a structure, otherwise zero)
+ 04h 1 Chunk ID (96h)
+ 05h 2 Class (02h=Array,08h=RefToStruct,0Dh=DefineAlias,66h=StructEnd)
+ 07h 2 Type (0xh=Small, 3xh=WithArrayStuff?) (same/similar as in chunk 94h)
+ 09h 4 Struct Size in Bytes
+ 0Dh 2 Array Dimensions (DIM) (0=none) ;eg. [3][4] --> 0002h
+ 0Fh DIM*4 Array Entries per Dimension ;eg. [3][4] --> 00000003h,00000004h
+ xxh 1 Internal Fake Name Length (LEN1) (0=none)
+ xxh LEN1 Internal Fake Name (eg. ".1fake")
+ xxh 1 Symbol Name Length (LEN2)
+ xxh LEN2 Symbol Name (eg. "r")
+(looks same/similar as C_xxx class values in COFF files!)
+
0001h = Local variable (with Offset = negative stack offset)
+ 0002h = Global variable or Function (with Offset = address)
+ 0008h = Item in Structure (with Offser = offset within struct)
+ 0009h = Incoming Function param (with Offset = index; 0,4,8,etc.)
+ 000Ah = Type address / struc start? (with Offset = zero)
+ 000Dh = Type alias (with Offset = zero)
+(maybe lower 4bit=type, and next 4bit=usage/variant?)
+(looks same/similar as T_xxx type values in COFF files!)
+
0000h =
+ 0001h =
+ 0002h =
+ 0003h = (16bit signed?)
+ 0004h = int (32bit signed?)
+ 0005h =
+ 0006h =
+ 0007h =
+ 0008h = (address) (32bit unsigned?) (with Definition=000Ah)
+ 0009h =
+ 000Ah =
+ 000Bh =
+ 000Ch = u_char (8bit unsigned?)
+ 000Dh = u_short,ushort (16bit unsigned?)
+ 000Eh = u_int (32bit unsigned?)
+ 000Fh = u_long (64bit unsigned?) (or rather SAME as above?)
+ 0021h = function with 0 params, and/or return="nothing"?
+ 0024h = main function with 2 params, and/or return="int"?
+ 0052h = argv (string maybe?)
+ 0038h = GsOT (huh?)
+ 00F8h = GsOT_TAG (huh?)
+ 00FCh = PACKET (huh?)
+ ?? = float,bool,string,ptr,packet,(un-)signed8/16/32/64bit,etc
+ ?? = custom type/struct (using value 000xh plus "fake" name, or so?)
+The .SYM file is usually bundled with a .MAP file, which is containing a
+summary of the symbolic info as ASCII text (but without info on line numbers or
+data types). For example:
+
Start Stop Length Obj Group Section name
+ 80010000 80012D5B 00002D5C 80010000 text .rdata
+ 80012D5C 800C8417 000B56BC 80012D5C text .text
+ 800C8418 800CDAB7 000056A0 800C8418 text .data
+ 800CDAB8 800CFB63 000020AC 800CDAB8 text .sdata
+ 800CFB64 800D5C07 000060A4 800CFB64 bss .sbss
+ 800D5C08 800DD33F 00007738 800D5C08 bss .bss
+ Address Names alphabetically
+ 800CFE80 ACE_amount
+ 800CFB94 AIMenu
+ 800CDE5C AXIS_LENGTH
+ 8005E28C AddClippedTri
+ 8005DFEC AddVertex
+ ...
+ Address Names in address order
+ 00000000 _cinemax_obj
+ 00000000 _cinemax_header_org
+ 00000000 _cinemax_org
+ 00000000 _mcardx_sbss_size
+ 00000000 _mcardx_org
+ ...
+TIM/PXL/CLT are standard formats from Sony's devkit. TIM is used by many PSX
+games.
+
.TIM contains Pixel data, and (optional) CLUT data ;-all in one file
+ .PXL contains Pixel data only ;\in two separate files
+ .CLT contains CLUT data only (if any) ;/
+ 000h 1 File ID (always 10h=TIM)
+ 001h 1 Version (always 00h)
+ 002h 2 Reserved (always 0000h) (or 1 or 2 for Compressed TIM, see below)
+ 004h 4 Flags (bit0-2=Type; see below, bit3=HasCLUT, bit4-31=Reserved/zero)
+ ... .. Data Section for CLUT (Palette), only exists if Flags.bit3=1, HasCLUT
+ ... .. Data Section for Pixels (Bitmap/Texture)
+ 000h 4 Size of Data Section (Xsiz*2*Ysiz+0Ch) ;maybe rounded to 4-byte?
+ 004h 4 Destination Coord (YyyyXxxxh) ;Xpos counted in halfwords
+ 008h 4 Width+Height (YsizXsizh) ;Xsiz counted in halfwords
+ 00Ch .. VRAM Data (to be DMAed to frame buffer)
+PXL/CLT is very rare. And oddly, with swapped ID values (official specs say
+11h=PXL, 12h=CLT, but the existing games do use 11h=CLT, 12h=PXL).
+Used by Granstream Saga (MagDemo10 GS\)
+Used by Bloody Roar 1 (MagDemo06: BL\)
+Used by Bloody Roar 2 (MagDemo22: ASC,CMN,EFT,LON,SND,ST5,STU\*)
000h 1 File ID (always 11h=CLT) (although Sony's doc says 12h)
+ 001h 1 Version (always 00h)
+ 002h 2 Reserved (always 0000h)
+ 004h 4 Flags (bit0-1=Type=2; bit2-31=Reserved/zero)
+ ... .. Data Section for CLUT (Palette)
+ 000h 1 File ID (always 12h=PXL) (although Sony's doc says 11h)
+ 001h 1 Version (always 00h)
+ 002h 2 Reserved (always 0000h)
+ 004h 4 Flags (bit0-?=Type; see below, bit?-31=Reserved/zero)
+ ... .. Data Section for Pixels (Bitmap/Texture)
+Ape Escape (Sony 1999) is using a customized TIM format with 4bpp compression:
+CDROM File Compression TIM-RLE4/RLE8
+Other than that, TIMs can be compressed via generic compression functions (like
+LZSS, GZIP), or via bitmap dedicated compression formats (like BS, JPG, GIF).
Used by Legacy of Kain: Soul Reaver (eg. BIGFILE.DAT\folder04h\file13h)
+ Used by Gex - Enter the Gecko (eg. BIGFILE.DAT\file0Fh\LZcompressed)
+ 10 00 00 00 02 00 00 00 04 00 08 00 00 02 00 00 00 02 00 02 ;<-- this
+ 10 00 00 00 02 00 00 00 04 00 08 00 00 00 00 00 00 02 00 02 ;<-- or this
+ [04h]=Type should indicated the color depth, but it's always 02h=16bpp.
+ [08h]=Width*2*Height+0Ch should be 8000Ch, but malformed is 80004h.
+ Total filesize should be 80014h, but Gecko files are often MUCH smaller.
+ Used by Pong (MagDemo24: LES02020\*\*.TIM)
+ 10 00 00 00 02 00 00 00 0E 00 08 00 C0 01 00 00 00 02 00 02 ;Pong *.TIM
+ 10 00 00 00 02 00 00 00 0E 00 07 00 00 02 00 00 C0 01 00 02 ;Pong WORLD.TIM
+ 10 00 00 00 02 00 00 00 0E 80 03 00 00 02 00 01 C0 01 00 01 ;Pong ZONE*.TIM
+NBA Basketball 2000 (MagDemo28: FOXBB\TIM\*.TIM) has TIMs with section size
+"0Ch+Xsiz*Ysiz" instead of "0Ch+Xsiz*2*Ysiz".
Bloody Roar 1 (CMN\INIT.DAT\000Eh)
+ Bloody Roar 2 (CMN\SE00.DAT, CMD\SEL00.DAT\0030h and CMN\VS\VS.DAT\0000h)
+ 13 00 00 00 02 00 00 00 0C 20 00 00 00 00 F8 01 00 01 10 00 ;Bloody Roar 1
+ 13 00 00 00 02 00 00 00 0C 20 00 00 00 00 00 00 00 01 10 00 ;Bloody Roar 2
+And, Heart of Darkness has a TIM with Size entry set to Xsiz*2*Ysiz+0Eh
+(instead of +0Ch) (that malformed TIM is found inside of the RNC compressed
+IMAGES\US.TIM file).
+Also, NFL Gameday '99 (MagDemo17: GAMEDAY\PHOTOS.FIL) contains a TIM cropped to
+800h-byte size (containing only the upper quarter of the photo).
+Also, not directly malformed, but uncommon: Final Fantasy IX contains 14h-byte
+0x0 pixel TIMs (eg. FF9.IMG\dir04\file0046\1B-0000\04-0001).
+Klonoa (MagDemo08: KLONOA\FILE.IDX\3\2\0..1) has 0x0pix TIM (plus palette).
Used by Secret of Mana, WM\WEFF\*.CLT
+Apart from Sony's TIM (and PXL/CLT) format, there are a bunch of other
+texture/bitmap formats:
.BS used by several games (and also in most .STR videos)
+ .GIF used by Lightspan Online Connection CD
+ .JPG used by Lightspan Online Connection CD
+ .BMP with RLE4 used by Lightspan Online Connection CD (MONOFONT, PROPFONT)
+ .BMP with RLE8+Delta also used by Online Connection CD (PROPFONT\ARIA6.BMP)
+ .PCX with RLE used by Jampack Vol. 1 (MDK\CD.HED\*.pcx)
+ .BMP
+ .BMP used by Mat Hoffman's Pro BMX (MagDemo39: BMX\BMXCD.HED\*)
+ .BMP used by Mat Hoffman's Pro BMX (MagDemo48: MHPB\BMXCD.HED\*)
+ .BMP used by Thrasher: Skate and Destroy (MagDemo27: SKATE\ASSETS\*.ZAL)
+ .BMP used by Dave Mirra Freestyle BMX (MagDemo36,46: BMX\ASSETS\*.ZAL)
+ .VRM .IMG .TEX .TIM .RAW .256 .COL .4B .15B .R16 .TPG - raw VRAM data
+ "SC" memory card icons
+CDROM File Video Texture/Bitmap (TGA)
+CDROM File Video Texture/Bitmap (PCX)
000h 10h Name 1 ("FILENAME.BMP", zeropadded)
+ 010h 10h Name 2 ("FILENAME.PSI", zeropadded)
+ 020h 4 Bits per pixel (usually 4, 8, or 16)
+ 024h 2 Bitmap VRAM Dest.X ?
+ 026h 2 Bitmap VRAM Dest.Y ?
+ 028h 2 Bitmap Width in pixels
+ 02Ah 2 Bitmap Height in pixels
+ 02Ch 2 Palette VRAM Dest.X ? ;\zero for 16bpp
+ 02Eh 2 Palette VRAM Dest.Y ? ;/
+ 030h 2 Bitmap Width in Halfwords (PixelWidth*bpp/16)
+ 032h 2 Palette Size in Halfwords (0, 10h, 100h for 16bpp,4npp,8bpp)
+ 034h 4 Maybe Bitmap present flag (always 1)
+ 038h 4 Maybe Palette present flag (0=16bpp, 1=4bpp/8bpp)
+ 03Ch .. Bitmap pixels
+ ... .. Palette (if any, for 4bpp: 16x16bit, for 8bpp: 256x16bit)
+This game does use two different (but nearly identical) bitmap formats (with
+either palette or bitmap data stored first).
+
000h 4 Total Filesize (Width*Height+20Ch)
+ 004h 2 Bitmap Width
+ 006h 2 Bitmap Height
+ 008h 4 Unknown, always 1 (maybe 1=8bpp?)
+ In .DAT files (512x192 or 256x64 pix), palette first:
+ 00Ch 200h Palette data
+ 20Ch .. Bitmap data
+ In .PSX files (64x64 pix), bitmap first:
+ 00Ch .. Bitmap data
+ ... 200h Palette data
+ Filename extension is ".DAT"
+ Bitmap Width<>Height (non-square)
+ [00Ch..20Bh] has AllMSBs>=80h, and SomeLSBs<80h
+Used by Alone in the Dark The New Nightmare (FAT.BIN\BOOK,DOC,INTRO,MENU\)
+Used by Rayman (RAY\JUN,MON,MUS\) (but seems to contain map data, not pixels)
+
000h 2 Width (W) ;\usually 320x240 (or 512x240 or 80x13)
+ 002h 2 Height (H) ;/
+ 004h .. Bitmap 16bpp (W*H*2 bytes)
+Used by Championship Motocross (MagDemo25: SMX\RESHAD.BIN\*) ("RAWP")
+
000h 4 ID "RAWP" (this variant has BIG-ENDIAN width/height!)
+ 004h 2 Width (usually 280h=640pix or 140h=320pix) (big-endian!!!)
+ 006h 2 Height (usually 1E0h=480pix or F0h=240pix) (big-endian!!!)
+ 008h .. Bitmap data, 16bpp (width*height*2 bytes)
+Used by CART World Series (MagDemo04: CART\.BIT and *.BIN\)
+Used by NFL Gameday '98 (MagDemo04: GAMEDAY\BUILD\GRBA.FIL\)
+Used by NFL Gameday '99 (MagDemo17: GAMEDAY\.BIT and *.FIL\)
+Used by NFL Gameday 2000 (MagDemo27: GAMEDAY\.BIT)
+Used by NCAA Gamebreaker '98 (MagDemo05: GBREAKER\.BIT and UFLA.BIN\)
+Used by NCAA Gamebreaker 2000 (MagDemo27: GBREAKER\.BIT and *.FIL\)
+Used by Twisted Metal 4 (MagDemo30: TM4DATA\.MR,*.IMG\.bit,*.clt)
+
000h 2 VRAM.X (X) (0..3FFh)
+ 002h 2 VRAM.X (Y) (0..1FFh)
+ 004h 2 Width in halfwords (W) (1..400h)
+ 006h 2 Height (H) (1..200h)
+ 008h .. Bitmap or Palette data (W*H*2 bytes)
+ 000h 2 Hotspot X (signed) (usually 0)
+ 002h 2 Hotspot Y (signed) (usually 0)
+ 004h 2 Width in bytes
+ 006h 2 Height
+ 008h .. Bitmap 8bpp (Width*Height bytes)
+ 000h 2 Width
+ 002h 2 Height
+ 004h 100h*3 Palette 24bit RGB888
+ 304h .. Bitmap 8bpp (Width*Height bytes)
+ .. (1700h) Unknown (only in SMLMAPS\*.BOB, not in GFX\*.BOB)
+ 000h 4 Format 1 (0=8bpp, 1=16bpp)
+ 004h 4 Format 2 (1=8bpp, 2=16bpp)
+ 008h 4 Width in pixels
+ 00Ch 4 Height in pixels
+ 010h .. Bitmap Data
+ ... (300h) Palette 18bit RGB666 (R,G,B range 00h..3Fh) (only if format 8bpp)
+ 000h 4 Unknown (always 1)
+ 004h 4 Unknown (always 8)
+ 008h 4 Unknown (always 2) (maybe 2=16bpp?)
+ 00Ch 4 Width in pixels (3Ah, 140h, or 280h)
+ 010h 4 Height (3Ah, or F0h)
+ 014h .. Bitmap 16bpp (Width*Height*2 bytes)
+ 000h 2 Number if Files (N)
+ 002h 2 Number of VRAM.Slots (less or equal than Number of Files)
+ 004h 4 ID "BLK0"
+ 008h N*10h File List
+ ... .. 1st File Bitmap
+ ... .. 1st File Palette (20h/200h/0 bytes for 4bpp/8bpp/16bpp)
+ ... .. 2nd File Bitmap
+ ... .. 2nd File Palette (only if PaletteID=FileNo=1)
+ ... .. 3rd File Bitmap
+ ... .. 3rd File Palette (only if PaletteID=FileNo=2)
+ ... .. etc.
+ 000h 2 VRAM.X in halfwords (0..1Fh, +bit15=Blank) ;\within current
+ 002h 2 VRAM.Y (0..3Fh) ;/VRAM.Slot
+ 004h 2 Width in pixels (max 80h/40h/20h for 4bpp/8bpp/16bpp)
+ 006h 2 Height (max 40h)
+ 008h 2 VRAM.Slot (0,1,2,3,...,NumSlots-1)
+ 00Ah 2 Unknown (0,1,2,4 in *.vck, 4 in sect*.bin)
+ 00Ch 2 Color Depth (0=4bpp, 1=8bpp, 2=16bpp)
+ 00Eh 2 Palette ID (0..FileNo-1=Old, FileNo=New, FFFFh=None/16bpp)
+ NumFiles-1, or ID of already used palette)
+These are 16bpp bitmaps, stored either in uncompressed .BMR files, or in
+compressed .RLE files:
+CDROM File Compression RLE_16
+
Apocalypse (MagDemo16: APOC\CD.HED\*.RLE and *.BMR)
+ Spider-Man 1 older version (MagDemo31: SPIDEY\CD.HED\*.RLE)
+ Spider-Man 1 newer version (MagDemo40: SPIDEY\CD.HED\*.RLE and .BMR)
+ Spider-Man 2 (MagDemo50: HARNESS\CD.HED\*.RLE)
+ Tony Hawk's Pro Skater (MagDemo22: PROSKATE\CD.HED\*.BMR)
+ 33408h bytes --> 512x205pix, 16bpp (Apocalypse warning.rle)
+ 3C008h bytes --> 512x240pix, 16bpp (most common)
+ 96008h bytes --> 640x480pix, 16bpp (tony hawk's pro skater)
+ 000h 2 Unknown (FFA0h) (ID for files with valid headers?)
+ 002h 2 Dest.Y (usually 0) (11h=(240-205)/2 in Apocalypse warning.rle)
+ 004h 2 Width (usually 200h=512pix)
+ 006h 2 Height (usually F0h=240pix) (CDh=205pix in Apocalypse warning.rle)
+ 008h .. Bitmap data, 16bpp (width*height*2 bytes)
+ 000h .. Bitmap data, 16bpp (width*height*2 bytes)
+ .. 8 Unused (garbage or extra pixels, not transferred to VRAM)
+Contains raw 16bpp bitmaps, with following sizes:
+
25800h bytes = 12C00h pixels (320x240) ;Croc 1 (retail version)
+ 3C000h bytes = 1E000h pixels (512x240)
+ 96000h bytes = 4B000h pixels (640x480)
+ 000h 2 Bits per pixel (4 or 8)
+ 002h 2 Bitmap Width in pixels
+ 004h 2 Bitmap Height in pixels
+ 006h 2 Zero
+ 008h N*2 Palette (with N=(1 SHL bpp))
+ ... .. Bitmap (with Width*Height*bpp/8 bytes)
+ ... (..) Zeropadding to 4-byte boundary (old version only)
+ 000h 2 Type (0=4bpp, 1=8bpp, 2=16bpp)
+ 002h 2 Unknown (usually 0000h, or sometimes CCCCh)
+ 004h 2 Bitmap Width in pixels
+ 006h 2 Bitmap Height in pixels
+ 008h 200h Palette (always 200h-byte, even for 4bpp or 16bpp)
+ 208h .. Bitmap (Width*Height*bpp/8 bytes)
+This format is used in various EA Sports Madden .DAT archives, it contains
+standard TIMs with extra Headers/Footers.
+
000h 4 Offset to TIM (1Ch) (Hdr size) (1Ch) ;\
+ 004h 4 Offset to Footer (Hdr+TIM size)(123Ch,1A3Ch,1830h) ;
+ 008h 2 Bitmap Width in pixels (40h or 60h or 30h) ;
+ 00Ah 2 Bitmap Height in pixels (40h) ;
+ 00Ch 4 Unknown, always 01h (01h) ; Header
+ 010h 4 Unknown, always 23h (23h) ; 1Ch bytes
+ 014h 2 Unknown, always 0101h (101h) ;
+ 016h 1 Bitmap Width in pixels (40h or 60h or 30h) ;
+ 017h 1 Bitmap Height in pixels (40h) ;
+ 018h 4 Unknown, always 00h (0) ;/
+ 01Ch .. TIM (Texture, can be 4bpp, 8bpp, 16bpp) ;-TIM
+ ... 4 Unknown, always C0000222h (C0000222h) ;\
+ ... 2 Unknown, always 0001h (0001h) ;
+ ... 1 Bitmap Width in pixels (40h or 60h or 30h) ; Footer
+ ... 1 Bitmap Height in pixels (40h) ; 12h bytes
+ ... 4 Unknown, always 78000000h (78000000h) ;
+ ... 6 Unknown (0,0,80h,0,0,0) ;/
+ Madden NFL '98 (MagDemo02: TIBURON\PORTRAIT.DAT) (48x64, 16bpp)
+ Madden NFL 2000 (MagDemo27: MADN00\PORTRAIT.DAT) (96x64, 8bpp plus palette)
+ Madden NFL 2001 (MagDemo39: MADN01\PORTRAIT.DAT) (64x64, 8bpp plus palette)
+ 000h 0Ch ID "TEX PSX ",01h,00h,00h,00h ;used in 989 Sports games
+ 00Ch 4 Number of Textures
+ 010h 4 Total Filesize
+ 014h 4 Common Palette Size (0=200h, 1=None, 2=20h)
+ 018h (..) Common Palette, if any (0,20h,200h bytes)
+ ... .. Texture(s)
+ Texture format:
+ 000h 10h Filename (eg. "light1", max 16 chars, zeropadded if shorter)
+ 010h 4 Width in pixels (eg. 40h)
+ 014h 4 Height (eg. 20h or 40h)
+ 018h 4 Unknown (always 0)
+ 01Ch 4 Number of Colors (eg. 10h, 20h or 100h)
+ 020h .. Bitmap (4bpp when NumColors<=10h, 8bpp when NumColors>10h)
+ ... (..) Palette (NumColors*2 bytes, only present if Common Palette=None)
+FIFA - Road to World Cup 98 (with chunk C0h/C1h = RefPack compression)
+NCAA March Madness 2000 (MagDemo32: MM2K\.PSH)
+Need for Speed 3 Hot Pursuit (*.PSH, ZLOAD*.QPS\RefPack.PSH)
+ReBoot (DATA\.PSH) (with chunk 6Bh)
+Sled Storm (MagDemo24: DEBUG,ART,ART2,ART3,SOUND\.PSH) (with Comment, Mipmap)
+WCW Mayhem (MagDemo28: WCWDEMO\.BIG\*.PSH) (with chunk C0h/C1h = RefPack)
+
000h 4 ID "SHPP"
+ 004h 4 Total Filesize (or Filesize-0Ch, eg. FIFA'98 ZLEG*.PSH)
+ 008h 4 Number of Textures (N)
+ 00Ch 4 ID "GIMX"
+ 010h N*8 File List
+ ... .. Data (each File contains a Bitmap chunk, and Palette chunk, if any)
+ File List entries:
+ 000h 4 Name (ascii) (Mipmaps use the same name for each mipmap level)
+ 004h 4 Offset from begin of archive to first Chunk of file
+ Caution: Most PSH files do have the above offsets sorted in increasing order,
+ but some have UNSORTED offsets, eg. Sled Storm (MagDemo24: ART3\LOAD1.PSH),
+ so one cannot easily compute sizes as NextOffset-CurrOffset.
+ Note: Mipmap textures consist of two files with same name and different
+ resolution, eg. in Sled Storm (MagDemo24: ART\WORLD0x.PSH)
+ Bitmap Chunk:
+ 000h 1 Chunk Type (40h=PSX/4bpp, 41h=PSX/8bpp, 42h=PSX/16bpp)
+ 001h 3 Offset from current chunk to next chunk (000000h=None)
+ 004h 2 Bitmap Width in pixels (can be odd, pad lines to 2-byte boundary)
+ 006h 2 Bitmap Height
+ 008h 2 Center X (whatever that is)
+ 00Ah 2 Center Y (whatever that is)
+ 00Ch 2 Position X (whatever that is, plus bit12-15=flags?)
+ 00Eh 2 Position Y (whatever that is, plus bit12-15=flags?)
+ 010h .. Bitmap data (each scanline is padded to 2-byte boundary)
+ ... .. Padding to 8-byte boundary
+ Compressed Bitmap Chunk:
+ 000h 1 Chunk Type (C0h=PSX/4bpp, C1h=PSX/8bpp, and probably C2h=PSX/16bpp)
+ 001h 0Fh Same as in Chunk 40h/41h/42h (see there)
+ 010h .. Compressed Bitmap data (usually/always with Method=10FBh)
+ ... .. Padding to 8-byte boundary
+ Palette Chunk (if any) (only for 4bpp/8bpp bitmaps, not for 16bpp):
+ 000h 1 Chunk Type (23h=PSX/Palette)
+ 001h 3 Offset from current chunk to next chunk (000000h=None)
+ 004h 2 Palette Width in halfwords (10h or 100h)
+ 006h 2 Palette Height (1)
+ 008h 2 Unknown (usually same as Width) (or 80D0h or 9240h)
+ 00Ah 2 Unknown (usually 0000h) (or 0001h or 0002h)
+ 00Ch 2 Unknown (usually 0000h)
+ 00Eh 2 Unknown (usually 00F0h)
+ 010h .. Palette data (16bit per color)
+ Note: The odd 80D0h,0001h values occur in Sled Storm ART\WORKD00.PSH\TBR1)
+ Unknown Chunk (eg. ReBoot (DATA\AREA15.PSH\sp*))
+ 000h 1 Chunk Type (6Bh)
+ 001h 3 Offset from current chunk to next chunk (000000h=None)
+ 004h 8 Unknown (2C,00,00,3C,03,00,00,00)
+ 00Ch - For whatever reason, there is no 8-byte padding here
+ Comment Chunk (eg. Sled Storm (MagDemo24: ART\WORLD0x.PSH))
+ 000h 1 Chunk Type (6Fh=PSX/Comment)
+ 001h 3 Offset from current chunk to next chunk (000000h=None)
+ 004h .. Comment ("Saved in Photoshop Plugin made by PEE00751@...",00h)
+ ... .. Zeropadding to 8-byte boundary
+ Unknown Chunk (eg. Sled Storm (MagDemo24: ART\WORLD09.PSH\ADAA))
+ 000h 1 Chunk Type (7Ch)
+ 001h 3 Offset from current chunk to next chunk (000000h=None)
+ 004h 2Ch Unknown (reportedly Hot spot / Pix region, but differs on PSX?)
+This format can contain one single Bitmap, or a font with several small
+character bitmaps.
+
000h 2 ID "BC" ;\
+ 002h 1 Color Depth (1=4bpp, 2=8bpp, 4=16bpp) ; Header
+ 003h 1 Type (40h=Bitmap, C0h=Font) ;/
+ ... (2) Palette Unknown (0 or 1) ;\only if Bitmap
+ ... (2) Palette Unknown (1) ; 4bpp or 8bpp
+ ... (..) Palette data (20h or 200h bytes for 4bpp/8bpp) ;/
+ ... 2 Bitmap Number of Bitmaps-1 (N-1) ;\
+ ... 2 Bitmap Width in pixels ;
+ ... 2 Bitmap Height in pixels ; Bitmap(s)
+ ... N*1 Bitmap Tilenumbers (eg. "ABCDEFG..." for Fonts);
+ ... N*1 Bitmap Proportional Font widths? (0xh or FFh) ;
+ ... N*BMP Bitmap(s) for all characters ;/
+ ... (20h) Palette Data (20h bytes for 4bpp) ;-only if Font/4bpp
+ INGAME1\BOWL2.PTH\SPRITES.PTH\ST.SPR 30x10x4bpp: 15 --> 16 bytes/line
+ INGAME1\BOWL2.PTH\SPRITES.PTH\STOPW.SPR 75x40x4bpp: 37.5 --> 38 bytes/line
+ 000h 2 ID ("FB") ;\File Header
+ 002h 2 Always 1 (version? 4bpp? num entries?) ;/
+ 004h 2 Palette VRAM Dest X (eg. 300h) ;\
+ 006h 2 Palette VRAM Dest Y (eg. 1CCh,1EDh,1FFh) ; Palette Header
+ 008h 2 Palette Width in halfwords (eg. 100h) ; (all zero when unused)
+ 00Ah 2 Palette Height (eg. 1 or 0Dh) ;/
+ 00Ch 2 Bitmap VRAM Dest X (eg. 140h or 200h) ;\
+ 00Eh 2 Bitmap VRAM Dest Y (eg. 0 or 100h) ; Bitmap Header
+ 010h 2 Bitmap Width in halfwords ;
+ 012h 2 Bitmap Height ;/
+ ... .. Palette Data (if any) ;-Palette Data
+ ... .. Bitmap Data ;-Bitmap Data
+ 000h 1 Image ID Size (00h..FFh, usually 0=None) ;0
+ 001h 1 Palette Present Flag (0=None, 1=Present) ;0 iv=1
+ 002h 1 Data Type code (0,1,2,3,9,10,11,32,33) ;NEBULA=2 iv=1
+ 003h 2 Palette First Color (usually 0) ;0 iv=0
+ 005h 2 Palette Number of Colors (usually 100h) ;0 iv=100h
+ 007h 1 Palette Bits per Color (16,24,32, usually 24) ;0 iv=18h
+ 008h 2 Bitmap X origin (usually 0) ;0
+ 00Ah 2 Bitmap Y origin (usually 0) ;0
+ 00Ch 2 Bitmap Width ;NEBULA=20h LOGO=142h
+ 00Eh 2 Bitmap Height ;NEBULA=20h
+ 010h 1 Bitmap Bits per Pixel (8,16,24,32 exist?) ;NEBULA=18h iv=8
+ 011h 1 Image Descriptor (usually 0) ;0
+ 012h .. Image ID Data (if any, len=[00h], usually 0=None)
+ ... .. Palette
+ ... .. Bitmap
+ ... 1Ah Footer (8x00h, "TRUEVISION-XFILE.", 00h) (not present in iview)
+ 00h = No image data included ;-Unknown purpose
+ 01h = Color-mapped image ;\
+ 02h = RGB image ; Uncompressed
+ 03h = Black and white image ;/
+ 09h = Color-mapped image ;\Runlength
+ 0Ah = RGB image ;/
+ 0Bh = Black and white image ;-Unknown compression method
+ 20h = Color-mapped image ;-Huffman+Delta+Runlength
+ 21h = Color-mapped image ;-Huffman+Delta+Runlength+FourPassQuadTree
+ Type 01h and 09h lack details on supported bits per pixel (8bpp with 100h
+ colors does exist; unknown if less (or more) than 8bpp are supported,
+ and if so, in which bit order.
+ Type 02h and 0Ah are more or less well documented.
+ Type 03h has unknown bit-order, also unknown if/how it differs from type
+ 01h with 1bpp.
+ Type 0Bh, 20h, 21h lack any details on the compression method.
+ 16bpp: Tomb Raider 2 (MagDemo01: TOMBRAID\*.RAW)
+ 24bpp: Tomb Raider 2 (MagDemo05: TOMB2\*.TGA)
+ 24bpp: Colony Wars Venegance (MagDemo14: CWV\GAME.RSC\NEBULA*.TGA, *SKY.TGA)
+ 24bpp: Colony Wars Red Sun (MagDemo31: CWREDSUN\GAME.RSC\000A\*)
+ 16bpp: Colony Wars Venegance (MagDemo14: CWV\GAME.RSC\LOGO.DAT)
+ 16bpp: X-Men: Mutant Academy (MagDemo50: XMEN2\*)
+ 16bpp: Disney's Tarzan (MagDemo42: TARZAN\*)
+ 8bpp+Wrong8bitAttr: SnoCross Championship Racing (MagDemo37: SNOCROSS\*.TGA)
+ 16bpp+WrongYflip: SnoCross Championship Racing (MagDemo37: SNOCROSS\*.TGA)
+ 32bpp: 3DS AR Games (RomFS:\i_ar\tex\hm*.lz77
+Default extension is .PCX (some tools did use .PCX for the "main" image, and
+.PCC for smaller snippets that were clipped/cropped/copied from from a large
+image).
+
000h 1 File ID (always 0Ah=PCX/ZSoft)
+ 001h 1 Version (0,2,3,4,5)
+ 002h 1 Compression (always 01h=RLE) (or inofficial: 00h=Uncompressed)
+ 003h 1 Bits per Pixel (per Plane) (1, 2, 4, or 8)
+ 004h 2 Window X1 ;\
+ 006h 2 Window Y1 ; Width = X2+1-X1
+ 008h 2 Window X2 ; Height = Y2+1-Y1
+ 00Ah 2 Window Y2 ;/
+ 00Ch 2 Horizontal Resolution in DPI ;\often square, but can be also zero,
+ 00Eh 2 Vertical Resolution in DPI ;/or screen size, or other values
+ 010h 30h EGA/VGA Palette (16 colors, 3-byte per color = R,G,B) (or garbage)
+ 010h 1 CGA: Bit7-4=Background Color (supposedly IRGB1111 ?)
+ 013h 1 CGA: Bit7:0=Color,1=Mono,Bit6:0=Yellow,1=White,Bit5:0=Dim,1=Bright
+ 014h 1 Paintbrush IV: New CGA Color1 Green ;\weird new way to encode CGA
+ 015h 1 Paintbrush IV: New CGA Color1 Red ;/palette in these two bytes
+ 040h 1 Reserved (00h) (but is 96h in animals.pcx)
+ 041h 1 Number of color planes (1=Palette, 3=RGB, or 4=RGBI)
+ 042h 2 Bytes per Line (per plane) (must be N*2) (=(Width*Bits+15)/16*2)
+ 044h 2 PaletteInfo? (0000h/xxxxh=Normal, 0001h=Color/BW, 0002h=Grayscale)
+ 046h 2 Horizontal screen size in pixels ;\New fields, found only
+ 048h 2 Vertical screen size in pixels ;/in Paintbrush IV/IV Plus
+ 04Ah 36h Reserved (zerofilled) (or garbage in older files, custom in MGS)
+ 080h .. Bitmap data (RLE compressed)
+ ... 1 VGA Palette ID (0Ch=256 colors) ;\when 8bpp
+ .. 300h VGA Palette (256 colors, 3-byte per color = R,G,B) ;/
+ 00h = Version 2.5 whatever ancient stuff
+ 02h = Version 2.8 with custom 16-color palette
+ 03h = Version 2.8 without palette (uses fixed CGA/EGA palette)
+ 04h = Version ?.? without palette (uses fixed CGA/EGA palette)
+ 05h = Version 3.0 with custom 16-color or 256-color palette or truecolor
+ planes=1, bits=1 P1 ;1bit, HGC 2 color (iview and paint shop pro 2)
+ planes=1, bits=2 P2 ;2bit, CGA 4 color (with old/new palette info)
+ planes=3, bits=1 RGB111 ;3bit, EGA 8 color (official samples) ;\version
+ planes=4, bits=1 IRGB1111 ;4bit, EGA 16 color (paint shop pro 2) ;/03h..04h
+ planes=1, bits=4 P4 ;4bit, BMP 16 color (iview)
+ planes=1, bits=8 P8 ;8bit, VGA 256 color palette
+ planes=1, bits=8 I8 ;8bit, VGA 256 level grayscale (gmarbles.pcx)
+ planes=3, bits=8 BGR888 ;24bit, truecolor (this is official 24bit format)
+ ;planes=1, bits=24 BGR888 ? ;24bit, reportedly exists? poor compression
+ ;planes=4, bits=4 ABGR4444 ;16bit, wikipedia-myth? unlikely to exist
+ ;planes=4, bits=8 ABGR8888 ;32bit, truecolor+alpha (used in abydos.dcx\*)
+These are normally calculated as so:
+
Width = X2+1-X1 ;width for normal files
+ Height = Y2+1-Y1 ;height for normal files
+ Width = X2-X1 ;width for bugged files
+ Height = Y2-Y1 ;height for bugged files
+ (Width*Bits+15)/16*2) > BytesPerLine
+ BeginOfLastScanline >= Filesize (or Filesize-301h for files with palette)
+The official ZSoft PCX specs are - wrongly - describing planes as:
+
plane0 = red ;\
+ plane1 = green ; this is WRONG, NONSENSE, does NOT exist
+ plane2 = blue ;
+ plane3 = intensity ;/
+This format was intended for 640x200pix 2-color CGA graphics, it's also common
+for higher resolution FAX or print images. The general rule for these files is
+to use this colors:
+
color0=black
+ color1=white
+This format was intended for 320x200pix 4-color CGA graphics, and the palette +is closely bound to colors available in CGA graphics modes. Color0 is defined +in [10h], and Color1-3 were originally defined in [13h], and later in
+ color0=[10h].bit7-4 ;(Color0 IRGB) ;CGA Port 3D9h.bit3-0 (usually 0=black)
+ bright=[13h].bit5 ;CGA Port 3D9h.bit4 ;\
+ palette=[13h].bit6 ;CGA Port 3D9h.bit5 ; old method
+ if [13h].bit7 then palette=2 ;CGA Port 3D8h.bit2 ;/
+ if [01h]=05h and [44h]=0001h then ;\new "smart"
+ if [14h]>200 or [15h]>200 then bright=1, else bright=0 ; method used in
+ if [14h]>[15h] then palette=0 else palette=1 :/Paintbrush IV
+ if palette=0 and bright=0 then color1..3=02h,04h,06h ;\green-red-yellow
+ if palette=0 and bright=1 then color1..3=0Ah,0Ch,0Eh ;/
+ if palette=1 and bright=0 then color1..3=03h,05h,07h ;\cyan-magenta-white
+ if palette=1 and bright=1 then color1..3=0Bh,0Dh,0Fh ;/
+ if palette=2 and bright=0 then color1..3=03h,04h,07h ;\cyan-red-white
+ if palette=2 and bright=1 then color1..3=0Bh,0Ch,0Fh ;/
+These images have 3 or 4 planes. Plane0-3 correspond to bit0-3 of the EGA color
+numbers (ie. blue=plane0, green=plane1, red=plane2, and either intensity=plane3
+for 16-color, or intensity=0 for 8-color images).
+Some 8-Color sample images (with version=03h and 04h) can be found bundled with
+PC Paintbrush Plus 1.22 for Windows. A 16-color sample called WINSCR.PCX can be
+found elsewhere in internet.
+Caution 1: Official ZSoft specs are wrongly claiming plane0=red and
+plane2=blue; this is wrong (although Paint Shop Pro 2 is actually implementing
+it that way) (whilst MS Paint for Win95b can properly display them) (most other
+tools are trying to read a palette from [10h..3Fh], which is usually garbage
+filled in version=03h..04h).
+Caution 2: The standard EGA palette is used for version=03h..04h (many docs
+claim it to be used for version=03h only).
These can have 1 plane with 4 bits, or 4 planes with 1 bit. Header[10h..3Fh]
+contains a custom 16-color RGB palette with 3x8bit per R,G,B.
+Classic VGA hardware did only use the upper 6bit of the 8bit values.
+Classic EGA hardware did only use the upper 2bit of the 8bit values (that, only
+when having a special EGA monitor with support for more than 16 colors).
These have 1 plane with 8 bits. And a 256-color RGB palette with 3x8bit per
+R,G,B appended at end of file.
+The appended 256-color palette should normally exist only in 256-color images,
+some PCX tools are reportedly always appending the extra palette to all
+version=05h files (even for 2-color files).
The most obvious and reliable way is to use a palette with grayscale RGB
+values. However, Paintbrush IV is explicetly implementing (or ignoring?) an
+obscure grayscale format with following settings:
+
[01h]=version=05h, and [44h]=0002h=grayscale
+ Color Name IRGB1111 RGB222 RGB888 Windows
+ 00h dark black 0000 000 000000 000000
+ 01h dark blue 0001 002 0000AA 000080
+ 02h dark green 0010 020 00AA00 008000
+ 03h dark cyan 0011 022 00AAAA 008080
+ 04h dark red 0100 200 AA0000 800000
+ 05h dark magenta 0101 202 AA00AA 800080
+ 06h dark yellow (brown) 0110 210!! AA5500!! 808000
+ 07h dark white (light gray) 0111 222 AAAAAA C0C0C0!!
+ 08h bright black (dark gray) 1000 111 555555 808080!!
+ 09h bright blue 1001 113 5555FF 0000FF
+ 0Ah bright green 1010 131 55FF55 00FF00
+ 0Bh bright cyan 1011 133 55FFFF 00FFFF
+ 0Ch bright red 1100 311 FF5555 FF0000
+ 0Dh bright magenta 1101 313 FF55FF FF00FF
+ 0Eh bright yellow 1110 331 FFFF55 FFFF00
+ 0Fh bright white 1111 333 FFFFFF FFFFFF
+ CGA supports 16 colors in text mode (but only max 4 colors in graphics mode).
+ EGA supports the same 16 colors as CGA in both text and graphics mode.
+ EGA-with-special-EGA-monitor supports 64 colors (but only max 16 at once).
+ VGA supports much colors (but can mimmick CGA/EGA colors, or similar colors)
+ .PCX with RLE used by Jampack Vol. 1 (MDK\CD.HED\*.pcx)
+ .PCX with RLE used by Hot Wheels Extreme Racing (MagDemo52: US_01293\MISC\*)
+ .PCX with RLE used by Metal Gear Solid (slightly corrupted PCX files)
+MGS is storing some extra data at [4Ah..57h] (roughly resembling the info in
+TIM files).
+
04Ah 2 Custom MGS ID (always 3039h)
+ 04Ch 2 Display Mode? (08h/18h=4bit, 09h/19h=8bit)
+ 04Eh 2 Bitmap X-coordinate in VRAM (reportedly "divided by 2" ???)
+ 050h 2 Bitmap Y-coordinate in VRAM
+ 052h 2 Palette X-coordinate in VRAM
+ 054h 2 Palette Y-coordinate in VRAM
+ 056h 2 Palette number of actually used colors (can be less than 16/256)
+ 058h 28h Reserved (zerofilled)
+ 080h .. Bitmap data (RLE compressed)
+ ... 1 VGA Palette ID (0Ch=256 colors) ;\when 8bpp
+ .. 300h VGA Palette (256 colors, 3-byte per color = R,G,B) ;/
+ .. .. Padding to 4-byte boundary, ie. palette isn't at filesize-301h !!!
+DCX archives contain multiple PCX files (eg. multi-page FAX documents). The
+standard format is as so:
+
0000h 4 ID (3ADE68B1h) (987654321 decimal)
+ 0004h 4000h File List (32bit offsets) (max 1023 files, plus 0=End of List)
+ 1004h .. File Data area (PCX files)
+https://www.fileformat.info/format/pcx/egff.htm
+CEL/BGD/TSQ/ANM/SDF
This does merely translate Tile Numbers to VRAM Addresses and Attributes (with
+the actual VRAM bitmap data usually being stored in .TIM files).
+
000h 1 File ID (22h)
+ 001h 1 Version (3)
+ 002h 2 Flag (bit15=WithAttr, bit14=AttrDataSize:0=8bit,1=16bit, bit13-0=0)
+ 004h 2 Number of cell data items (in cell units) (N)
+ 006h 1 Sprite Editor Display Window Width (in cell units)
+ 007h 1 Sprite Editor Display Window Height (in cell units)
+ 008h .. Cell Data[N] (64bit entries)
+ ... .. Cell Attr[N] (0bit/8bit/16bit user data? depending on Flag)
+ 0-7 Tex Coord X (8bit)
+ 8-15 Tex Coord Y (8bit)
+ 16-21 Clut X (6bit)
+ 22-30 Clut X (9bit)
+ 31 Semi-transparency enable ;-only in Version>=3
+ 32 Vertical Reversal (Y-Flip) ;\only in Version=0 and Version>=2
+ 33 Horizontal Reversal (X-Flip) ;/
+ 34-47 Unused
+ 48-52 Texture Page (5bit)
+ 53-54 Semi Transparency (0=B/2+F/2, 1=B+F, 2=B-F, 3=B+F/4)
+ 55-56 Texture page colors (0=4bit, 1=8bit, 2=15bit, 3=Reserved)
+ 57-60 Sprite Editor Color Set Number ;\
+ 61 Unused ; only in Version>=3
+ 62-63 Sprite Editor TIM Bank ;/ XXX else hardcoded?
+This is an inofficial hack used by R-Types, the game does use both the official
+CEL and inofficial CEL16 format.
+
000h 1 File ID (22h) ;\same as in official CEL version
+ 001h 1 Version (3) ;/
+ 002h 2 Flag (...unknown meaning in this case...?) ;<-- ?
+ 004h 2 Number of cell data items (in cell units) (N)
+ 006h 2 Sprite Editor Display Window Width (in cell units) ;<-- 16bit!
+ 008h 2 Sprite Editor Display Window Height (in cell units) ;<-- 16bit!
+ 00Ah .. Cell Data[N] (64bit entries)
+ ... .. Cell Attr[N] (16bit/192bit user data, depending on Flag or so...?)
+ 000h 1 File ID (23h)
+ 001h 1 Version (0)
+ 002h 2 Flag (bit15=WithAttr, bit14=AttrDataSize:0=8bit,1=16bit, bit13-0=0)
+ 004h 1 BG Map Width (in cell units) (W)
+ 005h 1 BG Map Height (in cell units) (H)
+ 006h 1 Cell Width (in pixels)
+ 007h 1 Cell Height (in pixels)
+ 008h .. BG Map Data[W*H] (16bit cell numbers)
+ ... .. BG Map Attr[W*H] (0bit/8bit/16bit user data? depending on Flag)
+This is an inofficial hack used by R-Types, the game does use both the official
+BGD and inofficial BGD16 format. Apparently invented to support bigger BG Map
+Widths for huge sidescrolling game maps.
+
000h 1 File ID (23h) ;\same as in official BGD version
+ 001h 1 Version (0) ;/
+ 002h 2 Flag (bit15=WithAttr, bit14=AttrDataSize:0=8bit,1=16bit, bit13-0=0)
+ 004h 2 BG Map Width (in cell units) (W) ;<-- 16bit!
+ 006h 2 BG Map Height (in cell units) (H) ;<-- 16bit!
+ 008h 2 Cell Width (in pixels) ;<-- 16bit!
+ 00Ah 2 Cell Height (in pixels) ;<-- 16bit!
+ 00Ch .. BG Map Data[W*H] (16bit cell numbers)
+ ... .. BG Map Attr[W*H] (0bit/8bit/16bit user data? depending on Flag)
+ ... .. FFh-padding (in case being stored in R-Types' DOT1 archives)
+ 000h 1 File ID (24h)
+ 001h 1 Version (1)
+ 002h 2 Number of Sequence data entries (N)
+ 004h N*8 Sequence Data (64bit entries)
+ 0-15 Sprite Group Number to be displayed
+ 16-23 Display Time
+ 24-27 Unused
+ 28-31 Attribute (user defined) (only in Version>=1)
+ 32-47 Hotspot X Coordinate
+ 48-63 Hotspot Y Coordinate
+ 000h 1 File ID (21h)
+ 001h 1 Version (3=normal) (but see below notes on older versions)
+ 002h 2 Flag (bit0-1=TPF, bit2-11=0, bit12-15=CLT)
+ 0-1 TPF PixFmt (0=4bpp, 1=8bpp, 2/3=Reserved) ;version>=2 only
+ 2-11 - Reserved (0)
+ 12-15 CLT Number of CLUT Groups, for color animation
+ 004h 2 Number of Sprites Groups
+ 006h 2 Number of Sequences (N) (can be 0=None)
+ 008h N*8 Sequence(s) (64bit per entry) ;Num=[004h]
+ ... .. Sprite Group(s) ;Num=[006h]
+ ... .. CLUT Group(s) ;Num=[002h].bit12-15
+ 000h 2 Sprite Group Number to be displayed (range 0..AnimHdr[004h]-1)
+ 002h 1 Display Time (can be 00h or 0Ah or whatever)
+ 003h 1 Attribute (bit0-3=Unused/Zero, bit4-7=User defined) ;version>=3 only
+ 004h 2 Hotspot X Coordinate (usually 0, or maybe can be +/-NN ?)
+ 006h 2 Hotspot Y Coordinate (usually 0, or maybe can be +/-NN ?)
+ Each "Group" seems to represent one animation frame.
+ Each "Group" can contain one or more sprites (aka metatiles).
+ Below stuff is "4+N*14h" bytes, that seems to repeat "AnmHeader[004h] times"
+ XXX... actually below can be "4+N*10h" or "4+N*14h" bytes
+ XXX... so, maybe maybe some entries like width/height are optional?
+ 000h 4 Number of Sprites in this Sprite Group ("sprites per metatile"?)
+ 004h 14h*N Sprite(s) (see below)
+ Sprites:
+ 000h 1 Tex Coord X (8bit)
+ 001h 1 Tex Coord Y (8bit)
+ 002h 1 Offset X from Hotspot within frame (maybe vertex x ?)
+ 003h 1 Offset Y from Hotspot within frame (maybe vertex y ?)
+ 004h 2 CBA Clut Base (bit0-5=ClutX, Bit6-14=ClutY, bit15=SemiTransp)
+ 006h 2 FLAGs (bit0-4, bit5-6, bit7-8, bit9, bit10, bit11, bit12-15)
+ 0-4 TPN Texture Page Number
+ 5-6 ABR Semi-Transparency Rate
+ 7-8 TPF Pixel depth (0=4bpp, 1=8bpp, 2=16bpp)
+ 9 - Reserved
+ 10 RSZ Scaling (0=No, 1=Scaled)
+ 11 ROT Rotation (0=No, 1=Rotated)
+ 12-15 THW Texture Width/Height div8 (0=Other custom width/height)
+ 008h (2) Texture Width "of optional size" (uh?) ;\only present if
+ 00Ah (2) Texture Height "of optional size" (uh?) ;/FLAGs.bit12-15=0 ?)
+ 00Ch 2 Angle of Rotation (in what units?)
+ 00Eh 2 Sprite Editor info (bit0-7=Zero, bit8-13=ClutNo, bit14-15=TimBank)
+ 010h 2 Scaling X (for Vertex?) (as whatever fixed point number) (eg. 1000h)
+ 012h 2 Scaling Y (for Vertex?) (as whatever fixed point number) (eg. 1000h)
+ 000h 4 CLUT size in bytes (Width*Height*2+0Ch)
+ 004h 2 Clut X Coordinate
+ 006h 2 Clut Y Coordinate
+ 008h 2 Clut Width
+ 00Ah 2 Clut Height
+ 00Ch .. CLUT entries (16bit per entry, Width*Height*2 bytes)
+This is an ASCII text file for "artist boards" with following entries:
+
TIM0 file0.tim ;\
+ TIM1 file1.pxl file1.clt ; four TIM banks (with TIM or PXL/CLT files)
+ TIM2 ; (or no filename for empty banks)
+ TIM3 ;/
+ CEL0 file0.cel ;-one CEL (with CEL, or no filename if none)
+ MAP0 file0.bgd ;\
+ MAP1 file1.bgd ; four BG MAP banks (with BGD filenames)
+ MAP2 ; (or no filename for empty banks)
+ MAP3 ;/
+ ANM0 file0.anm ;-one ANM (with ANM, or no filename if none)
+ DISPLAY n ;0-3=256/320/512/640x240, 4-7=256/320/512/640x480
+ COLOR n ;0=4bpp, 1=8bpp ;docs are unclear, is it COLORn or COLOR n?
+ ADDR0 texX texY clutX clutY numColorSets ;\
+ ADDR1 texX texY clutX clutY numColorSets ; four texture/palette offsets
+ ADDR2 texX texY clutX clutY numColorSets ; for the corresponding TIM banks
+ ADDR3 texX texY clutX clutY numColorSets ;/ (or whatever for empty banks?)
+ 000h 4 ID (00000041h)
+ 004h 4 Flags (bit0=FIXP, bit1-31=Reserved/zero)
+ 008h 4 Number of Objects (N) ;"integral value" uh?
+ 00Ch N*1Ch Object List (1Ch-byte per entry)
+ ... .. Data (Vertices, Normals, Primitives)
+ 000h 4 Start address of a Vertex ;\Address values depend on the
+ 004h 4 Number of Vertices ; file header's FIXP flag:
+ 008h 4 Start address of a Normal ; FIXP=0 Addr from begin of Object
+ 00Ch 4 Number of Normals ; FIXP=0 Addr from begin of TMD File
+ 010h 4 Start address of a Primitive ;
+ 014h 4 Number of Primitives ;/
+ 018h 4 Scale (signed shift value, Pos=SHL, Neg=SHR) (not used by LIBGS)
+ 000h 2 Vertex X (signed 16bit)
+ 002h 2 Vertex Y (signed 16bit)
+ 004h 2 Vertex Z (signed 16bit)
+ 006h 2 Unused
+ 000h 2 Normal X (fixed point 1.3.12)
+ 002h 2 Normal Y (fixed point 1.3.12)
+ 004h 2 Normal Z (fixed point 1.3.12)
+ 006h 2 Unused
+ 000h 1 Output Size/4 of the GPU command (after GTE conversion)
+ 001h 1 Input Size/4 of the Packet Data in the TMD file
+ 002h 1 Flag
+ 0 Light source calculation (0=On, 1=Off)
+ 1 Clip Back (0=Clip, 1=Don't clip) (for Polygons only)
+ 2 Shading (0=Flat, 1=Gouraud)
+ (Valid only for the polygon not textured,
+ subjected to light source calculation)
+ 3-7 Reserved (0)
+ 003h 1 Mode (20h..7Fh) (same as GP0(20h..7Fh) command value in packet)
+ 004h .. Packet Data
+ 000h 4 GPU Command+Color for that packet (CcBbGgRrh), see GP0(20h..3Fh)
+ ... (4) Texcoord1+Palette (ClutYyXxh) ;\
+ ... (4) Texcoord2+Texpage (PageYyXxh) ; only if Mode.bit2=1
+ ... (4) Texcoord3 (0000YyXxh) ;
+ ... (4) Texcoord4 (0000YyXxh) ;-quad only ;/
+ ... (4) Color2 (00BbGgRrh) ;\
+ ... (4) Color3 (00BbGgRrh) ; only if Flag.bit2=1
+ ... (4) Color4 (00BbGgRrh) ;-quad only ;/
+ ... (2) Normal1 (index in Normal list?) ;always, unless Flag.bit0=1
+ ... 2 Vertex1 (index in Vertex list?)
+ ... (2) Normal2 (index in Normal list?) ;-only if Mode.bit4=1
+ ... 2 Vertex2 (index in Vertex list?)
+ ... (2) Normal3 (index in Normal list?) ;-only if Mode.bit4=1
+ ... 2 Vertex3 (index in Vertex list?)
+ ... (2) Normal4 (index in Normal list?) ;\quad only ;-only if Mode.bit4=1
+ ... 2 Vertex4 (index in Vertex list?) ;/
+ ... (2) Unused zeropadding (to 4-byte boundary)
+ 000h 4 GPU Command+Color for that packet (CcBbGgRrh), see GP0(40h,50h)
+ ... (4) Color2 (00BbGgRrh) ;-only if Mode.bit4=1
+ ... 2 Vertex1 (index in Vertex list?)
+ ... 2 Vertex2 (index in Vertex list?)
+ 000h 4 GPU Command+Color for that packet (CcBbGgRrh), see GP0(60h..7Fh)
+ ... .. Unknown, reportedy "with 3-D coordinates and the drawing
+ content is the same as a normal sprite."
+This is about same as TMD, with less features, intended to work faster.
+
000h 4 ID (00000042h)
+ 004h 4 Offset to Primitives
+ 008h 4 Offset to Shared Vertices (or 0=None)
+ 00Ch 4 Number of Objects
+ 010h .. Objects (4+N*4 bytes each, with offsets to Primitives)
+ ... .. Primitives
+ ... .. Shared Vertices (8-bytes each, if any)
+ 000h 2 Vertex X (signed 16bit)
+ 002h 2 Vertex Y (signed 16bit)
+ 004h 2 Vertex Z (signed 16bit)
+ 006h 2 Unused
+ 000h 4 Number of Primitives
+ 004h N*4 Offsets to Primitives ... maybe relative to hdr[004h] ?
+ 000h 2 Number of Packets
+ 002h 2 Type flags
+ 0 Polygon (0=Triangle, 1=Quadrilateral)
+ 1 Shading (0=Flat, 1=Gouraud) ;uh, with ONE color?
+ 2 Texture (0=Texture-On, 1=Texture-Off) ;uh, withoutTexCoord?
+ 3 Shared (0=Independent vertex, 1=Shared vertex)
+ 4 Light source calculation (0=Off, 1=On) ;uh, withoutNormal?
+ 5 Clip (0=Back clip, 1=No back clip)
+ 6-15 Reserved for system
+ 004h ... Packet(s)
+ 000h 4 GPU Command+Color for that packet (CcBbGgRrh), see GP0(20h..7Fh)
+ 004h 8 Vertex1 (Xxxxh,Yyyyh,Zzzzh,0000h)
+ 00Ch 8 Vertex2 (Xxxxh,Yyyyh,Zzzzh,0000h)
+ 014h 8 Vertex3 (Xxxxh,Yyyyh,Zzzzh,0000h)
+ 01Ch (8) Vertex4 (Xxxxh,Yyyyh,Zzzzh,0000h) ;<-- only when Type.bit0=1 (quad)
+ 000h 4 GPU Command+Color for that packet (CcBbGgRrh), see GP0(20h..7Fh)
+ 004h 4 Offset to Shared Vertex1 ;offsets are
+ 008h 4 Offset to Shared Vertex2 ;"from the start of a row"
+ 00Ch 4 Offset to Shared Vertex3 ;aka from "Packet+04h" ?
+ 010h (4) Offset to Shared Vertex4 ;<-- only when Type.bit0=1(quad)
+ Cool Boarders 2 (MagDemo02: CB2\DATA3\*.PMD)
+ Cardinal Syn (MagDemo03,09: SYN\*\*.WAD\*.PMD) (4-byte hdr plus PMD file)
+ Sesame Streets Sports (MagDemo52: SSS\LV*\*MRG\*) (4-byte hdr plus PMD file)
+ 000h 1 ID (50h)
+ 001h 1 Version (0)
+ 002h 2 Resolution (time per frame in 60Hz units, can be 0) (60Hz on PAL?)
+ 004h 4 Number of Frames
+ 008h .. Frame1
+ ... .. Frame2
+ ... .. Frame3
+ ... .. etc.
+ 000h 2 Frame Size in words (ie. size/4)
+ 002h 2 Number of Packets (can be 0=None, ie. do nothing this frame)
+ 004h 4 Frame Number (increasing 0,1,2,3,..)
+ 008h ... Packet(s)
+ 000h 2 Object ID
+ 002h 1 Type/Flag (bit0-3=Type, bit4-7=Flags)
+ 003h 1 Packet Size ("in words (4 bytes)")
+ 004h ... Packet Data
+ 000h 4 ID (00000050h) ;same as in TOD, which CAN ALSO have MSBs=zero(!)
+ 004h 4 MAP FLAG (0 or 1, set when mapped via GsMapUnit() function)
+ 008h 4 Primitive Header Section pointer (whut?)
+ 00Ch 4 Number of Blocks
+ 010h 4*N Pointers to Blocks
+ ... Primitive Header section (required)
+ ... Coordinate section (optional)
+ ... Primitive section (required)
+RSD files consist of a set of several files (RSD,PLY,MAT,etc). The files
+contain the "polygon source code" in ASCII text format, generated from Sony's
+"SCE 3D Graphics Tool". For use on actual hardware, the "RSDLINK" utility can
+be used to convert them to binary (TMD, PMD, TOD?, HMB?) files.
+
RSD Main project file
+ PLY Polygon Vertices (Vertices, Normals, Polygons)
+ MAT Polygon Material (Color, Blending, Texture)
+ GRP Polygon Grouping
+ MSH Polygon Linking ;\
+ PVT Pivot Rotation center offsets ; New Extended
+ COD Vertex Coordinate Attributes ; (since RSD version 3)
+ MOT Animation Information ;/
+ OGP Vertex Object Grouping ;-Sub-extended
+ RSD/GRP/MAT/PLY (and DXF=whatever?) used on Yaroze disc (DTL-S3035)
+CDROM File Video Streaming STR (Sony)
+CDROM File Video Streaming STR Variants
+CDROM File Video Streaming Framerate
+CDROM File Video Streaming Audio
+CDROM File Video Streaming Chunk-based formats
+CDROM File Video Streaming Mis-mastered files
+Apart from the 20h-byte STR headers, movies basically consist of a series of BS
+files (see below).
BS stands for bitstream, which might refer to the use in STR files, or to the
+Huffman bitstreams.
+CDROM File Video BS Compression Versions
+CDROM File Video BS Compression Headers
+The header is followed by the bitstream...
+
v1/v2/v3/ea/iki --> first bit in bit15 of first halfword (good for psx)
+ v0 --> first bit in bit7 of first byte (not so good for psx)
+ (to use the same decoder for all version: swap each 2 bytes in v0)
+CDROM File Video Wacwac MDEC Streams
Thanks to Michael Sabin for info on various STR and BS variants:
+https://github.com/m35/jpsxdec/
000h 2 StStatus (0160h) (RV6Rh; R=Reserved=0, V=Version=1, 6=Fixed ID)
+ 002h 2 StType (0000h..7FFFh=User Defined, 8000h..FFFFh=System; 8001h=MDEC)
+ 004h 2 StSectorOffset (Sector number in the frame, 0=First)
+ 006h 2 StSectorSize (Number of sectors in the frame) (eg. 4 or 5)
+ 008h 4 StFrameNo (Frame number, 1=First) (except Viewpoint=0)
+ 00Ch 4 StFrameSize (in bytes, in this frame, excluding headers/padding)
+ When StType=0000h..7FFFh:
+ 010h 10h StUser (user defined data)
+ 020h 7E0h User data (more user defined data)
+ When StType=8001h=MDEC (the only system defined type) (with StStatus=0160h):
+ 010h 2 StMovieWidth (eg. 0140h)
+ 012h 2 StMovieHeight (eg. 00F0h)
+ 014h 4 StHeadM (reserved for system) (eg. 38000720h) ;\same as [020h-027h]
+ 018h 4 StHeadV (reserved for system) (eg. 00020001h) ;/from 1st STR sector
+ 01Ch 4 Unspecified (eg. 00000000h) (except Viewpoint<>0)
+ 020h 7E0h Data (in BS format) (or padding, when image is smaller than frame)
+The video frames consist of BS compressed images (that is, all sectors have STR
+headers at 000h..01Fh, and the first sector of each frame does additionally
+contain a standard BS fileheader at offset 020h..027h).
+
See "CDROM File Video BS Compression" chapters
+The Width/Height entries are almost always multiples of 16 pixels. But there
+are a few exceptions:
+
Height=260 (104h) in Star Wars Rebel Assault II, NTSC (S1\L01_PLAY.STR)
+ Height=200 (0C8h) in Perfect Assassin (DATA.JFS\CDV\*.STR)
+ Height=40 (028h) in Gran Turismo 1 (TITLE.DAT\*, MagDemo10 and MagDemo15)
+ Width=232 (0E8h) in Gran Turismo 1 (TITLE.DAT\*, MagDemo10 only)
+Metal Gear Solid MGS\ZMOVIE.STR contains subtitles as text strings: The first
+sector of the .STR file is something custom (without STR header), the remaining
+movie consists of STR sectors with StType=0001h for subtitles and StType=8001h
+for picture frames.
+Unknown if other games are using the same method, or other methods.
+Obviously, subtitles could be also displayed as part of the compressed image,
+but text strings are much smaller, have better quality, and would also allow to
+support multiple languages.
2-byte 0160h ;Standard STR header
+ 1-byte 01h ;Ace Combat 3 Electrosphere
+ 4-byte "SMJ",01h ;Final Fantasy 8, Video
+ 4-byte "SMN",01h ;Final Fantasy 8, Audio/left
+ 4-byte "SMR",01h ;Final Fantasy 8, Audio/righ
+ 4-byte 0000000xh ;Judge Dredd
+ 4-byte DDCCBBAAh ;Crusader: No Remorse, older Electronic Arts
+ 4-byte 08895574h ;Chunk header in 1st sector only, Best Sports (demo)
+ 4-byte "VLC0" ;Chunk header in 1st sector only, newer Electronic Arts
+ 4-byte "VMNK" ;Chunk header in 1st sector only, Policenauts
+ 4-byte 01h,"XSP" ;Sentient header in 1st sector only
+ N-byre zero(es) ;Polygons? (in last 150Mbyte of PANEKIT.STR)
+The official definition from Sony's File Formats document is as so;
+
0000h..7FFFh=User Defined
+ 8000h..FFFFh=System (with 8001h=MDEC being the only officially defined type)
+ 0000h=Polygon Video, Wacwac as Polygon Stream
+ 0000h=Polygon Video?, Army Men Air Attack 2 (MagDemo40: AMAA2\*.PMB)
+ 0000h=MDEC Video, Alice in Cyberland
+ 0001h=MDEC Video, Ridge Racer Type 4 (PAL version, 320x176 pix)
+ 0001h=Whatever extra data for XA-ADPCM streams (Bits Laboratory games)
+ 0001h=Whatever non-audio waverform? (3D Baseball)
+ 0001h=Subtitles, Metal Gear Solid MGS\ZMOVIE.STR
+ 0002h=Software-rendered video (without using MDEC/GTE) (Cyberia)
+ 0002h=MDEC Video, Wacwac with IntroTableSet
+ 0003h=MDEC Video, Wacwac with EndingTableSet
+ 0004h=MDEC Video, Final Fantasy 9 (MODE2/FORM2)
+ 0008h=SPU-ADPCM, AKAO audio (Final Fantasy 9)
+ 0000h=SPU-ADPCM, AKAO audio (Chrono Cross Disc 1, Legend of Mana)
+ 0001h=SPU-ADPCM, AKAO audio (Chrono Cross Disc 1, Legend of Mana)
+ 0100h=SPU-ADPCM, AKAO audio (Chrono Cross Disc 2)
+ 0101h=SPU-ADPCM, AKAO audio (Chrono Cross Disc 2)
+ 0000h=Whatever special, channel 0 header (Nightmare Project: Yakata)
+ 0400h=Whatever special, channel 1 header (Nightmare Project: Yakata)
+ 0001h=Whatever special, channel 0 data (Nightmare Project: Yakata)
+ 0401h=Whatever special, channel 1 data (Nightmare Project: Yakata)
+ 5349h=MDEC Video, Gran Turismo 1 and 2 (with BS iki)
+ 0078h=MDEC Ending Dummy (Mat Hoffman's Pro BMX (MagDemo48: MHPB\SHORT.STR)
+ 5673h=MDEC Leading Dummy (Mat Hoffman's Pro BMX (MagDemo48: MHPB\SHORT.STR)
+ 8001h=MDEC Video, Standard MDEC (most common type value)
+ 8001h=Polygon Video (Ape Escape) (same ID as standard MDEC)
+ 8001h=Eagle One: Harrier Attack various types (MDEC and other data)
+ 8001h=Dance series SPU-ADPCM streaming (with STR[1Ch]=DDCCBBAAh)
+ 8101h=MDEC Video, Standard MDEC plus bit8=FlagDisc2 (Chrono Cross Disc 2)
+Most movies start with STR video sectors. But a few games start with XA-ADPCM:
+
Ace Combat 3 Electrosphere (*.SPB)
+ Alice in Cyber Land (*.STR)
+ Judge Dredd (*.IXA) ;and very small 4-byte STR header
+ ReBoot (MOVIES\*.WXA)
+ EA videos ;\
+ Crusader ; chunks
+ Policenauts ;/
+ AKAO videos
+This is an archive dedicated to STR movies (with number of frames instead of
+filesize entries). Metal Gear Solid does also have cut-scenes with polygon
+animations (but those are supposedly stored elsewhere?).
+
000h 4 Number of entries (4)
+ 004h N*8 File List
+ ... .. Zerofilled
+ 000h 2 Unknown... decreasing values?
+ 002h 2 Number of Frames (same as last frame number in STR header)
+ 004h 4 Offset/800h (to begin of STR movie, with subtiltes in 1st sector)
+ 04 00 00 00
+ ED 97 9E 01 01 00 00 00 ;num sectors=1439h ;div19Eh=C.81h ;97EDh-6137h=36B6h
+ 37 61 86 01 3A 14 00 00 ;num sectors=0F41h ;div186h=A.03h ;6137h-38D0h=2867h
+ D0 38 10 03 7B 23 00 00 ;num sectors=1EA1h ;div310h=A.00h ;38D0h-2302h=15CEh
+ 02 23 73 02 1C 42 00 00 ;num sectors=1881h ;div273h=A.01h ;2302h-0000h=2302h
+ 000h 2 STR ID (0160h) ;\
+ 002h 2 STR Type (0001h=Subtitles) ;
+ 004h 2 Sector number within Subtitles (0) ; STR
+ 006h 2 Number of Sectors with Subtitles (1) ; header
+ 008h 4 Frame number (1) ;
+ 00Ch 4 Data size counted in 4-byte units (same as [02Ch]/4) ;
+ 010h 10h Zerofilled ;/
+ 020h 4 Unknown (2) ;\
+ 024h 4 Unknown (1AAh, 141h, or 204h) ; Data
+ 028h 4 Unknown (00100000h) ; part
+ 02Ch 4 Size of all Subtitle entries in bytes plus 10h ;
+ 030h .. Subtitle entries ;/
+ ... .. Zeropadding to 800h-byte boundary ;-padding
+ 000h 4 Offset from current subtitle to next subtitle (or 0=Last subtitle)
+ 004h 4 First Frame number when to display the subtitle?
+ 008h 4 Number of frames when to display the subtitle?
+ 00Ch 4 Zero
+ 010h .. Text string, terminated by 00h
+ ... .. Zeropadding to 4-byte boundary
+ 008h 4 Frame number (0=First) ;<-- instead of 1=First
+ 01Ch 2 Unknown (always D351h) ;<-- instead of zero
+ 01Eh 2 Number of Frames in this STR file ;<-- instead of zero
+Resident Evil 2 (ZMOVIE\.STR, PL0\ZMOVIE\.STR)
+Super Puzzle Fighter II Turbo (STR/CAPCOM15.STR)
+
01Ch 4 Sector number of 1st sector of current frame ;<-- instead of zero
+Chrono Cross Disc 1 does have normal STR headers, but Disc 2 has Type.bit8
+toggled:
+
002h 2 STR Type (8101h=Disc 2) ;<-- instead of 8001h
+Need for Speed 3 Hot Pursuit (MOVIES\.XA, contains videos, not raw XA-ADPCM)
+Jackie Chan Stuntmaster (FE\MOVIES\.STR)
+With slightly modified STR headers:
+
014h 4 Number of Frames (..excluding last some frames?) ;-instead BS[0..3]
+ 018h 4 Unlike the above modified entry, this is normal ;-copy of BS[4..7]
+This has leading XA-ADPCM, and customized STR header:
+
014h 2 Type (0000h=Normal, 01FFh=Empty frames at end of video)
+ 016h 2 Number of Frames (excluding empty ones at end of video)
+ 018h 8 Zerofilled
+These two games use BS iki format, and (unlike other iki videos) also special
+STR headers:
+
002h 2 STR Type (5349h) ("IS") ;-special (instead 8001h)
+ 010h 2 Total number of frames in video ;-special (instead width)
+ 012h 2 Flags (bit15=1st, bit14=last) ;-special (instead height)
+ 014h 8 Zero ;-special (instead BS header copy)
+ 020h 7E0h Data (in BS iki format) ;-BS iki header (with width/height)
+ Namely, flags in [012h] are toggled on first/last sector of each frame,
+ and of course [04h] does also increase per sector.
+Used by all movies in PGA Tour 96, 97 (and for the ZZBUFFER\BIGSPY.STR dummy
+padding movie in PGA Tour 98).
+The videos have normal BS v2 data, but the Frame Size entry is 8 smaller than
+usually. As workaround, always load [0Ch]+8 for all movies with standard STR
+headers (unless that would exceed [06h]*7E0h).
+
00Ch 4 Frame Size-8 (ie. excluding 8-byte BS header) ;instead of Size-0
+ ZZBUFFER\SPY256.STR [14h..1Fh]=normal copy of 8-byte BS v2 header and zero
+ ZZBUFFER\SPYGLASS.STR [14h..1Fh]=zerofilled ;\BS v1
+ ZZBUFFER\SPYTEST.STR [14h..1Fh]=00 00 10 00 00 00 00 09 00 00 07 EE ;/
+ ZZBUFFER\BIGSPY.STR Used in PGA Tour 98 (instead of above three files)
+Note: First sector contains XA-ADPCM audio (video starts in 2nd sector).
+
STR Sector Header:
+ 002h 2 STR Type (0000h=Alice in Cyber Land video) ;-special
+ 008h 4 Frame number (1=First) (bit15 set in last frame, or FFFFh)
+ 010h 10h Zerofilled (instead width/height and BS header copy) ;-special
+ 020h 7E0h Data (in BS v2 format)
+ 014h 8 Copy of decrypted BS header (instead of encrypted BS header)
+These files do have BS ID=3000h (except, the first and last some frames have
+nromal ID=3800h). The STR header is quite normal (apart from reflecting the odd
+BS ID):
+
016h 2 Copy of BS ID, 3000h in most frames (instead of 3800h)
+ 020h 7E0h Data (in BS format, also with BS ID 3000h, instead of 3800h)
+These movies have Extra stuff in the data section. The STR header is quite
+normal (apart from reflecting the Extra stuff):
+
00Ch 4 Frame Size in bytes (=size of ExtraHeader + BsData + ExtraData)
+ 014h 4 Copy of Extra Header ;instead of BS[0..3]
+ 018h 4 Copy of BS[0..3] ;instead of BS[4..7]
+ 020h 7E0h Data (ExtraHeader + BsData + ExtraData)
+ 000h 2 Size of BS Data area (S1) ;\Extra Header
+ 002h 2 Size of Extra Data area (S2) ;/
+ 004h S1 BS Data (in BS v3 format) ;-BS Data
+ .. S2 Extra Data (unknown purpose) ;-Extra Data
+This is a somewhat "normal" movie, without audio, and with the STR headers
+moved to the begin of the file:
+
000h Nx20h STR Headers ;size = filesize/800h*20h
+ ... Nx7E0h Data ;size = filesize/800h*7E0h
+ 006h 2 Number of Sectors in this Frame-1 (8..9 = 9..10 sectors)
+ 00Ch 4 Frame Size in bytes (8..9*7E0h = 3F00h or 46E0h)
+ 010h 2 Bitmap Width (always F0h)
+ 012h 2 Bitmap Width (always 50h)
+ 014h 0Ch Zerofilled (instead copy of BS header or copy of Extra header)
+ 020h 7E0h Data (Extra Stuff, BS v2 data, plus Unused stuff)
+ 0000h Extra Stuff (7E0h bytes, whatever, often starts with 00,FF,00,FF,..)
+ 07E0h BS v2 data (3720h or 3F00h bytes, including FFh-padding)
+ ... Unused Sector (7E0h bytes, same as in previous frame or zerofilled)
+ For 9 sectors: Only 1..7 are used, sector 8 is same as in previous frame
+ For 10 sectors: Only 1..8 are used, sector 9 is zerofilled
+The .MV files have 5 sectors/frame: Either 5 video sectors without audio, or
+4-5 video sectors plus XA-ADPCM audio (in the latter case, audio is in each 8th
+sector (07h,0Fh,17h,1Fh,etc), hence having filesize rounded up to N*8 sectors):
+
Filesize = 800h*((NumberOfFrames*5)) ;5 sectors, no xa-adpcm
+ Filesize = 800h*((NumberOfFrames*5+7) AND not 7) ;4-5 sectors, plus xa-adpcm
+ Sector 0: [10h] = Number of Frames, [12h]=Junk
+ Sector 1: [10h] = Junk, [12h]=0
+ Sector 2: [10h] = Junk, [12h]=Junk
+ Sector 3: [10h] = Junk, [12h]=Same as below (Bitmap Height)
+ Below ONLY when having 5 sectors per frame:
+ Sector 4: [10h] = Bitmap Width (140h) [12h]=Bitmap Height (D0h)
+ That is, frames with 4 sectors do NOT have any Bitmap Width entry
+ (the duplicated Height entry in sector 3 exists, so one could compute
+ Width=NumMacroBlocks*100h/Height, or assume fixed Width=320, Height=208).
+Used by Bugriders: The Race of Kings (MOVIE\XB.STR)
+Used by Rugrats Studio Tour (MagDemo32: RUGRATS\DATA\OPEN\B.STR)
+
Each movie file is followed by dummy padding file. For example, in Bugriders:
+ MOVIE\*XA.STR Movie clip (with correct size, 320x192)
+ MOVIE\*XB.STR Black Silence padding (wrong size 640x192, should be 320x192)
+ 00Ch 4 Frame Size (087Ch)
+ 010h 2 Bitmap Width (wrongly set to 640, should be 320)
+ 012h 2 Bitmap Height (192)
+ 014h 2 MDEC Size (05A0h)
+ 016h 2 BS ID (3800h)
+ 018h 2 BS Quant (0001h)
+ 01Ah 2 BS Version (0002h)
+ Filesize is always 44Fh sectors (about 2.2Mbyte per *XB.STR file)
+The 570Mbyte R4.STR file contains XA-ADPCM in first three quarters, and two STR
+movies in last quarter:
+
1st NTSC/US movie: 320x160 pix, 0F61h frames, 4-5 sectors/frame, normal STR
+ 1st PAL/EUR movie: 320x176 pix, 0CD0h frames, 5-6 sectors/frame, special STR
+ 2nd NTSC/US movie: 320x160 pix, 1D6Ah frames, 4-5 sectors/frame, normal STR
+ 2nd PAL/EUR movie: 320x160 pix, 18B5h frames, 5-6 sectors/frame, normal STR
+ 002h 2 STR Type (0001h=Custom, 176pix PAL video) ;instead of 8001h
+ 006h 2 Number of Sectors in this Frame (always 5..6)
+ 00Ch 4 Frame Size (always 2760h or 2F40h, aka 7E0h*5..6)
+ 012h 2 Bitmap Height (00B0h, aka 176 pixels) ;instead of 00A0h
+ 014h 8 Zerofilled ;instead BS[0..7]
+ 020h 7E0h Data (in BS v3 format, plus FFh-padding)
+This contains a normal MDEC movie, but with distorted "garbage" in first and
+last some sectors.
+
1st sector STR Type 5673h (Leading Dummy) ;\
+ 2nd sector STR Type 8001h (distorted/empty MDEC) ; junk
+ 3rd..6th sector STR Type 8001h (distorted/garbage MDEC) ;/
+ 7th sector and up STR Type 8001h (normal MDEC, with odd [01Ch]) ;-movie
+ Last 96h sectors STR Type 0078h (Ending Dummy) ;-junk
+ 002h 2 STR Type (5673h=Leading Dummy)
+ 004h 4 Whatever (0004000Ch)
+ 008h 4 Whatever (0098967Fh)
+ 00Ch 4 Frame Size (always 100h)
+ 010h 7F0h EAh-filled
+ 002h 2 STR Type (8001h=Normal MDEC ID, but content is empty)
+ 004h 4 Whatever (0004000Ch) ;\
+ 008h 4 Whatever (0098967Fh) ; same as in 1st sector
+ 00Ch 4 Frame Size (always 100h) ; (but ID at [002h] differes)
+ 010h 7F0h EAh-filled ;/
+ 002h 2 STR Type (8001h=Normal MDEC ID, but content is distorted)
+ 004h 2 Sector number within current Frame (always 0)
+ 006h 2 Number of Sectors in this Frame (always 1)
+ 008h 4 Frame number (increasing, 1..4 for 3rd..6th sector)
+ 00Ch 4 Frame Size (always 7D0h)
+ 010h 10h EAh-filled
+ 020h 7D0h Unknown (random/garbage?)
+ 7F0h 10h EAh-filled
+ Caution: The STR header values aren't constant throughout the frame:
+ Entry entry [01Ch] is incremented per sector (or wraps to 0 in new section).
+ 01Ch 4 Increasing sector number (within current movie section or so)
+ 002h 2 STR Type (0078h=Ending Dummy)
+ 004h 2 Sector number within current Frame (always 0)
+ 006h 2 Number of Sectors in this Frame (always 1)
+ 008h 4 Frame number (increasing, in last 96h sectors)
+ 00Ch 4 Frame Size (always 20h)
+ 010h 2 Bitmap Width (always 40h)
+ 012h 2 Bitmap Height (always 40h)
+ 014h 7ECh Zerofilled
+These movies have Extra stuff in the data section. The STR header is quite
+normal (apart from reflecting the Extra stuff):
+
00Ch 4 Frame Size in bytes (including 28h-byte extra stuff)
+ 014h 8 Copy of Extra data [0..7] :-instead of BS header[0..7]
+ 020h 7E0h Data (ExtraData + BsData)
+ 000h 28h Extra data (unknown purpose, reportedly "Camera data" ... whut?)
+ 028h .. BS Data (in BS v1 format)
+There are several customized STR header entries:
+
002h 2 STR Type (0004h=FF9/Video) ;instead of 8001h
+ 004h 2 Sector number within current Frame (02h..num-1) (2..9 for video)
+ 006h 2 Total number of Audio+Video sectors in this frame (always 0Ah)
+ 00Ch 4 Frame Size/4 (of BS data, excluding MBG extra) ;instead of Size/1
+ 014h 8 Copy of BS[0..7] from 8th video sector ;instead 1st sector
+ 01Ch 2 Usually 0000h (or 0004h in some MBG sectors) ;inszead of 0000h
+ 01Eh 2 Usually 0000h (or 3xxxh in some MBG sectors) ;inszead of 0000h
+ 020h 8F4h Data (in BS v2 format, plus MBG extra data, if any)
+ Namely, entry [1Ch..1Fh]=nonzero occurs only on the sector that does contain
+ the end of BS data (=and begin of MBG extra data), and of course [04h] does
+ also increase per sector.
+ [04h]=00h-01h 1st-2nd audio sector, SPU-ADPCM (see Audio streaming chapter)
+ [04h]=02h-06h 1st-5th video sector, unused, [020h..913h] is FFh-filled
+ [04h]=07h 6th video sector, contains end of BS data and MBG extra, if any
+ [04h]=08h 7th video sector, contains middle of BS data
+ [04h]=09h 8th video sector, contains begin of BS data
+ Audio sectors are MODE2/FORM1 (800h bytes, with error correction)
+ Video sectors are MODE2/FORM2 (914h bytes, without error correction)
+ 000000000100010 MDEC=001Eh (run=0, level=+1Eh) ;-normal (used)
+ 000000000100011 MDEC=03E1h (run=0, level=-1Eh) ;-normal (not used)
+ 0000010000001111100001 MDEC=03E1h (run=0, level=-1Eh) ;-escape (used)
+ FF FF FF FF FE FF FE 41 AD AD AD AD AD AD AD AD
+ AD AD AD AD AD AD AD AD AD AD AD AD AD AD AD AD
+ AD AD AD AD AD AD AD AD
+ (followed by FF's, which might be padding, or part of the extra data)
+Video frames are always 320x224. The video frames are preceeded by two
+SPU-ADPCM audio sectors.
+
000h 4 ID "SMJ",01h=Video
+ 004h 1 Sector number within current Frame (02h..num-1) (2..9 for video)
+ 005h 1 Total number of Audio+Video sectors in this frame, minus 1 (9)
+ 006h 2 Frame number (0=First)
+ 008h 7F8h Data (in BS v2 format)
+The videos start with one XA-ADPCM sector, followed by the first Video sector.
+
STR Sector Header:
+ 000h 1 Always 01h
+ 001h 1 Sector number within current Frame (00h..num-1) (8bit)
+ 002h 2 Number of Sectors in this Frame
+ 004h 2 Unknown (1 or 3)
+ 006h 2 Frame number (decreasing, 0=Last)
+ 008h 2 Bitmap Width in pixels ;\130hxE0h or 140hxB0h or 80hx60h
+ 00Ah 2 Bitmap Height in pixels ;/
+ 00Ch 4 Zero
+ 010h 2 Zero, or decreasing timer (decreases approx every 2 sectors)
+ 012h 2 Zero, or decreasing timer (decreases approx every 1 sector)
+ 014h 3 Zero
+ 017h 1 Zero, or increases with step 2 every some hundred sectors
+ 018h 2 Zero, or Timer (increments when [1Ah] wraps from 04h to 01h)
+ 01Ah 1 Zero, or Timer (increments when [1Bh] wraps from 5Fh to 00h]
+ 01Bh 1 Zero, or Timer (increments approx every 1 sector)
+ 01Ch 2 Zero, or Whatever (changes to whatever every many hundred sectors)
+ 01Eh 2 Zero, or 0204h
+ 020h 7E0h Data (in BS v3 format)
+ Namely, entry [10h..1Fh] can change within the frame (happens in japanese
+ version), and of course [01h] does also increase per sector.
+This is a lightgun-game with "interactive movies". The gameplay consists of
+running on a fixed path through a scene with pre-recorded background graphics,
+the only player interaction is aiming the gun at other people that show up in
+that movie scene. There are two movie types:
+
LEVELS\*\*.IXA - Interactive gameplay movies
+ CUTS\*.IXA - Non-interactive cut-scene movies
+ 000h 4 Sector number within current Frame (LEVELS=0..8, or CUTS=0..9)
+ 004h 7FCh Data (see below)
+ Note: CUTS videos have 2 leading XA-ADPCM sectors
+ 000h .. BS Data (in BS v2/v3 format) ;-BS picture
+ Note: LEVELS videos have 1 leading XA-ADPCM sector
+ 000h 4 Offset to BS Data (always 28h) ;\
+ 004h 4*6 Offsets to Extra Stuff 1..6 ; extra header
+ 01Ch 0Ch Zerofilled ;/
+ 028h .. BS Data (in BS v2/v3 format) ;-BS picture
+ ... .. Extra Stuff 1..6 ;-extra data
+The .iki video format (found in files with .IKI or .IK2 extension) is used in
+several games made by Sony. iki movie sectors have some different properties:
+
* There are only as many iki video sectors as needed to hold all the
+ frame's data. Remaining sectors are null.
+ * The first sector's Submode.Channel starts at zero, then increments for
+ each sector after that, and resets to zero after an audio sector.
+ * IK2 videos can also have variable frame rates that are very inconsistent.
+According to Sony, BS encoded 320x240pix videos can be played at 30fps (with
+cdrom running at double speed).
As a general rule, the frame rate is implied in CDROM rotation speed (150 or 75
+sectors per second, minus the audio sectors, divided by the number of sectors
+per video frame).
The frame can drop on video frames that contain more sectors than usually.
+Video frames that require fewer sectors than often padded with zerofilled
+sectors. However, some games don't have that padding, so they could end up
+reeceiving up to 150 single-sector frames per second; the actual framerate is
+supposedly slowed down to 60Hz or less via Vblank timer (and with the CDROM
+reading getting paused when the read-ahead buffer gets full).
XA-ADPCM audio contains samplerate info (in the FORM2 subheader), the
+samplerate versus amount of audio sectors can be used to compute the CDROM
+rotation speed.
+There are two exceptions: Some movies don't have any audio at all, and some
+movies use SPU-ADPCM instead of XA-ADPCM. In the latter case, the SPU Pitch
+(samplerate) may (or may not) be found somewhere in the audio sector headers.
As said above, the speed can be often detected via audio sample rate.
+Otherwise, the general rule is that most PSX games are used 2x speed (150
+sectors/second). But, there are a few games with 1x speed (see below).
Here are probably most of the USA games with videos at 1x speed.
+
007 - The World Is Not Enough
+ 1Xtreme
+ Arcade Party Pak
+ Atari Anniversary Edition Redux
+ Blast Radius
+ Blue's Clues - Blue's Big Musical
+ Chessmaster II
+ Chronicles of the Sword
+ Civilization II
+ Colin McRae Rally
+ Creatures - Raised in Space
+ Cyberia
+ Demolition Racer
+ Dune 2000
+ ESPN Extreme Games
+ FIFA Soccer 97
+ Fade to Black
+ Family Connection - A Guide to Lightspan
+ Fear Effect
+ Fox Hunt
+ Interactive CD Sampler Volume 1
+ Jade Cocoon - Story of the Tamamayu
+ Jeopardy! 2nd Edition
+ Juggernaut
+ Krazy Ivan
+ MTV Sports - Skateboarding featuring Andy Macdonald
+ MTV Sports - T.J. Lavin's Ultimate BMX
+ Medal of Honor
+ Medal of Honor - Underground
+ Official U.S. PlayStation Magazine Demo Disc 23
+ Planet of the Apes
+ PlayStation Underground Number 2
+ Shockwave Assault
+ Starblade Alpha
+ Starwinder - The Ultimate Space Race
+ Str.at.e.s. 1 - Match-A-Batch
+ Str.at.e.s. 5 - Parallel Lives!
+ Str.at.e.s. 7 - Riddle Roundup!
+ The X-Files
+ Top Gun - Fire at Will!
+ Um Jammer Lammy
+ Uprising X
+ Wheel of Fortune - 2nd Edition
+ Williams Arcade's Greatest Hits
+STR movies are usually interleaved with XA-ADPCM sectors (the audio sectors are
+automatically decoded by the CDROM hardware and consist of raw ADPCM data
+without STR headers).
+CDROM File Audio Streaming XA-ADPCM
+However, there are also movies without audio. And a few movies with SPU-ADPCM
+audio.
CDROM File Video Streaming Chunk-based formats
Chrono Cross Disc 1 (HiddenDirectory\1793h..17A6h)
+Chrono Cross Disc 2 (HiddenDirectory\1793h..179Dh)
+Legend of Mana (MOVIE\*.STR, except some movies without audio)
+
000h 2 STR ID (0160h)
+ 002h 2 STR Type (0000h, 0001h, 0100h, or 0101h)
+ 0000h=Legend of Mana, Audio normal sectors
+ 0001h=Legend of Mana, Audio sectors near end of movie
+ 0000h=Chrono Cross Disc 1, Audio.left?
+ 0001h=Chrono Cross Disc 1, Audio.right?
+ 0100h=Chrono Cross Disc 2, Audio.left?
+ 0101h=Chrono Cross Disc 2, Audio.right?
+ 004h 2 Sector number in Frame (0=Audio.left?, 1=Audio.right?)
+ 006h 2 Number of Audio sectors in this frame (always 2)
+ 008h 4 Frame number (1=First)
+ 00Ch 4 Unused (Chrono: FFh-filled or Mana: 00000FC0h=2x7E0h=Framesize?)
+ 010h 10h Unused (Chrono: FFh-filled or Mana: 00h-filled)
+ 020h 60h Unused (FFh-filled)
+ 080h 4 ID "AKAO"
+ 084h 4 Frame number (0=First)
+ 088h 8 Unused (zerofilled)
+ 090h 4 Remaining Time (step 690h) (can get stuck at 0340h or 0B20h at end)
+ 094h 4 Zero
+ 098h 4 Unknown (11h)
+ 09Ch 4 Pitch (1000h=44100Hz)
+ 0A0h 4 Number of bytes of audio data (always 690h)
+ 0A4h 2Ch Unused (zerofilled)
+ 0D0h 690h Audio (10h-byte SPU-ADPCM blocks) (1680 bytes)
+ 760h A0h Unused (10h-byte SPU-ADPCM blocks with flag=03h and other bytes=0)
+ 000h 4 ID "SMN",01h=Audio/left, "SMR",01h=Audio/right
+ 004h 1 Sector number in Frame (0=Audio.left, 1=Audio.right)
+ 005h 1 Total number of Audio+Video sectors in this frame, minus 1 (1 or 9)
+ 006h 2 Frame number (0=First)
+ 008h E8h Unknown (camera data?) (232 bytes)
+ 0F0h 6 Audio ID (usually "MORIYA", sometimes "SHUN.M")
+ 0F6h 0Ah Unknown (10 bytes) (reportedly 10 bytes at offset 250 = FAh ?????)
+ 100h 4 ID "AKAO"
+ 104h 4 Frame number (0=First)
+ 108h 14h Unknown (20 bytes)
+ 11Ch 4 Pitch (1000h=44100Hz)
+ 120h 4 Number of bytes of audio data (always 690h)
+ 124h 2Ch Unknown (44 bytes)
+ 150h 20h Unknown (32 bytes)
+ 170h 690h SPU-ADPCM Audio data (690h bytes)
+The FF9 audio sectors are normal MODE2/FORM1 sectors (unlike the FF9 video
+sectors, which are MODE2/FORM2).
+
000h 2 STR ID (0160h)
+ 002h 2 STR Type (0008h=FF9/Audio)
+ 004h 2 Sector number in Frame (0=Audio.left, 1=Audio.right)
+ 006h 2 Total number of Audio+Video sectors in this frame (always 0Ah)
+ 008h 4 Frame number (1=First)
+ 00Ch 4 Zero
+ 010h 1 Audio flag? (00h=No Audio, 01h=Audio)
+ 011h 4Fh Zerofilled --- XXX or whatever (when above is 00h)
+ 060h 4 Number of Frames in this STR file
+ 064h 1Ch EEh-filled
+ Below 780h bytes are all zerofilled when [10h]=00h (no audio)
+ Below 780h bytes are reportedly all ABh-filled "in the last frame of a movie
+ on Disc 4" (unknown which movie, and if that occurs in other movies, too)
+ 080h 4 ID "AKAO"
+ 084h 4 Frame number (0=First)
+ 088h 14h Unknown (20 bytes)
+ 09Ch 4 Pitch (116Ah=48000Hz) (or 1000h=44100Hz in final movie)
+ 0A0h 4 Number of bytes of audio data (0, 720h, 730h, or 690h=final movie)
+ 0A4h 2Ch Unknown (44 bytes)
+ 0D0h 730h SPU-ADPCM audio (plus leftover/padding when less than 730h bytes)
+This format is used for raw SPU-ADPCM streaming (without video).
+SLES-04121 Dance: UK
+SLES-04161 Dance: UK eXtra TraX
+SLES-04129 Dance Europe
+SLES-04162 All Music Dance! (Italy)
+
000h 2 STR ID (0160h)
+ 002h 2 STR Type (8001h, same as MDEC)
+ 004h 2 Sector number within current Frame (0000h..num-1)
+ 006h 2 Number of Sectors in this Frame (always 9)
+ 008h 4 Frame number (0=First)
+ 00Ch 4 Frame Size in bytes (always 4000h)
+ 010h 4 Whatever (always 00A000A0h, would be width/height if it were video)
+ 014h 8 Zerofilled
+ 01Ch 4 Special ID (always DDCCBBAAh for Dance audio)
+ 020h 7E0h Data (in SPU-ADPCM format, mono, 22200Hz aka Pitch=07F5h)
+Some games are using raw SPU-ADPCM for streaming. That is, the file is
+basically a normal .VB file, but it can be dozens of megabytes tall (ie. too
+large to be loaded into RAM all at once).
+
Disney's The Emperor's New Groove (MagDemo39: ENG\STREAM\*.CVS)
+ Disney's Aladdin in Nasira's Revenge (MagDemo46: ALADDIN\STREAM\*.CVS)
+EA videos are chunk based (instead of using 20h-byte .STR headers). The next
+chunk starts right at the end of the previous chunk (without padding to sector
+boundaries).
+
STR Sector Header:
+ No STR Sector header (first sector starts directly with "VLC0" chunk)
+ VLC0 Chunk (at begin of movie file):
+ 000h 4 Chunk ID "VLC0"
+ 004h 4 Chunk Size (always 1C8h) (big-endian)
+ 008h 1C0h 16bit MDEC values for E0h huffman AC codes (little-endian)
+ MDEC Chunks (video frames):
+ 000h 4 Chunk ID "MDEC" ;\
+ 004h 4 Chunk Size (...) (big-endian) ; custom chunk header,
+ 008h 2 Bitmap Width in pixels (big-endian) ; instead of STR header
+ 00Ah 2 Bitmap Height in pixels (big-endian) ;
+ 00Ch 4 Frame Number (starting at 0) (big-endian) ;/
+ 010h .. Data (in BS v2 format, but using custom Huffman codes from VLC0)
+ ... .. Zeropadding to 4-byte boundary
+ Audio Chunks (au00/au01):
+ 000h 4 Chunk ID ("au00"=normal, "au01"=last audio chunk)
+ 004h 4 Chunk Size (...) (big-endian)
+ 008h 4 Total number of 2x4bit samples in previous chunks (big-endian)
+ 00Ch 2 Unknown (always 800h) (maybe Pitch: 800h=22050Hz) (big-endian)
+ 00Eh 2 Unknown (always 200h) (big-endian)
+ ... .. SPU-ADPCM audio data, left (0Fh bytes per sample block)
+ ... .. SPU-ADPCM audio data, right (0Fh bytes per sample block)
+ ... .. Garbagepadding to 4-byte boundary
+ Note: SPU-ADPCM does normally have 10h-byte blocks, but in this case,
+ the 2nd byte (with loop flags) is omitted, hence only 0Fh-byte blocks.
+ Zero Chunk (zeropadding at end of file, exists only in some EA videos):
+ 000h .. Zeropadding
+Crusader: No Remorse (1996 Origin Systems) (MOVIES\*.STR)
+Soviet Strike (1996 Electronic Arts)
+Battle Stations (1997 Electronic Arts)
+Andretti Racing (1996 Electronic Arts)
+
STR Sector Header:
+ 000h 4 ID (DDCCBBAAh) (aka AABBCCDDh big-endian)
+ 004h 4 Sector number within STR file (0=First, up to Filesize/800h-1)
+ 008h 7F8h Data (video and audio chunks, see below) (first chunk is "ad20")
+ Video Chunks (MDEC):
+ 000h 4 Chunk ID "MDEC" ;\
+ 004h 4 Chunk Size (...) (big-endian) ;
+ 008h 2 Bitmap Width in pixels (big-endian) ; custom chunk header
+ 00Ah 2 Bitmap Height in pixels (big-endian) ;
+ 00Ch 4 Frame Number (starting at 0) (big-endian) ;/
+ 010h .. Data (in BS v2 format) ;-standard BS v2 data
+ Audio Chunks (ad20/ad21) (22050Hz stereo):
+ 000h 4 Chunk ID ("ad20"=normal, "ad21"=last audio chunk)
+ 004h 4 Chunk Size (1A50h or 1A70h) (big-endian)
+ 008h 4 Total number of 2x4bit samples in previous chunks (big-endian)
+ 00Ch 2 Unknown (always 800h) (maybe Pitch: 800h=22050Hz) (big-endian)
+ 00Eh 2 Unknown (always 200h) (big-endian)
+ 010h .. SPU-ADPCM audio data, left (10h bytes per sample block)
+ ... .. SPU-ADPCM audio data, right (10h bytes per sample block)
+ Last STR Sector:
+ 000h 18h FFh-filled (aka 8-byte STR header and 10h-byte Chunk header)
+ 018h - Nothing (total STR filesize is N*800h+18h bytes)
+Wing Commander III: Heart of the Tiger (MOVIES1.LIB\*.wve) (1995, EA/Origin)
+
STR Sector Header:
+ No STR Sector header (first sector starts directly with "Ad10" chunk)
+ Video Chunks (MDEC):
+ 000h 4 Chunk ID "MDEC" ;\
+ 004h 4 Chunk Size (2xx0h) (big-endian) ;
+ 008h 2 Bitmap Width in pixels (big-endian) ; custom chunk header
+ 00Ah 2 Bitmap Height in pixels (big-endian) ;
+ 00Ch 2 Unknown (7FFFh) (big-endian) ;
+ 00Eh 2 Unknown (AD14h or AD24h) (big-endian) ;/
+ 010h .. Data (in BS v2 format) ;-standard BS v2 data
+ ... .. Padding, up to circa 20h bytes, FFh-filled
+ Audio Chunks (Ad10/Ad11) (22050Hz stereo):
+ 000h 4 Chunk ID ("ad20"=normal, "ad21"=last audio chunk)
+ 004h 4 Chunk Size (D38h or D28h) (or less in last chunk) (big-endian)
+ 010h .. SPU-ADPCM audio data, left ? (10h bytes per sample block)
+ ... .. SPU-ADPCM audio data, right ? (10h bytes per sample block)
+ STR Sector Header:
+ No STR Sector header (first sector starts directly with "VMNK" chunk)
+ First chunk (800h bytes):
+ 000h 4 ID "VMNK" (aka KNMV backwards, maybe for Konami Video/Movie)
+ 004h 4 Unknown (01h)
+ 008h 4 Unknown (01h)
+ 00Ch 4 Unknown (F0h)
+ 010h 4 Size of KLBS chunks? (40000h)
+ 014h 4 Bitmap X1 (aka left border)? (16pix, 10h)
+ 018h 4 Bitmap Y1 (aka upper border)? (16pix, 10h)
+ 01Ch 4 Bitmap Width (288pix, 120h)
+ 020h 4 Bitmap Height (144pix, 90h)
+ 024h 7E4h Zerofilled
+ Further chunks (40000h bytes, each):
+ 000h 8 Zerofilled
+ 008h 4 Chunk ID "KLBS" (aka SBLK backwards, maybe for Stream Block)
+ 00Ch 4 Chunk Size (usually 40000h)
+ 010h 4 Number of Name List entries
+ 014h 4 Number of Name List entries (same as above)
+ 018h 8 Zerofilled
+ 020h N*30h Name List
+ ... .. Data (referenced from Name List)
+ ... .. Zeropadding (to end of 40000h-byte chunk)
+ Name List entries:
+ 000h 8 Zerofilled
+ 008h 8 Data Type Name (eg. "SCIPPDTS")
+ 010h 4 Time when to play/display the frame (0 and up)
+ 014h 4 Time duration for that frame (usually 14h for Picture frames)
+ 018h 4 Data Offset in bytes (from begin of chunk)
+ 01Ch 4 Data Size in bytes
+ 020h 10h Zerofilled
+ Type "SDNSHDTS" aka SNDS,STDH - SoundStdHeader (Size=800h, Duration=0)
+ 000h 4 Maybe Pitch? (800h) (big-endian)
+ 004h 4 Maybe Pitch? (800h) (big-endian)
+ 008h 4 Total SPU-ADPCM size in bytes (for whole .MOV) (big-endian)
+ 00Ch 4 Unknown (FFFFFFFFh) (whatever)
+ 010h 4 Unknown (00007FFFh) (big-endian)
+ 014h 7ECh Zerofilled
+ Type "SDNSSDTS" aka SNDS,STDS - SoundStdStream (Size=10h..4000h, Duration=9Ch)
+ 000h 4000h SPU-ADPCM data in 10h-byte blocks (last chunk is less than 4000h)
+ Type "SCIPPDTS" aka PICS,STDP - PictureStdPicture (Size=3xxxh, Duration=14h)
+ 000h 3xxxh Picture Frame (in BS v1 format)
+ Type "SCTELLEC" aka ETCS,CELL - ExtraCells? (Size=0Ch, Duration=1)
+ 000h .. Maybe subtitle related...?
+ Type "SCTEGOLD" aka ETCS,DLOG - ExtraD-log? (Size=19h..31h, Duration=27h..44h)
+ 000h .. Maybe subtitle related...?
+This format is used for still images with only frame, and for looping short
+animation sequences in the Demo Disc Menu. There's no audio.
+
Header Chunk:
+ 000h 4 Fixed ID (74h,55h,89h,08h aka 08895574h)
+ 004h 2 Bitmap Width (140h)
+ 006h 2 Bitmap Height (100h)
+ 008h 2 Video Frame Size/4 (17A0h or 13B0h)
+ 00Ah 2 Number of Video Frames (01h or 32h)
+ 00Ch 4 Frame End ID (eg. 62DCCACEh) (random?, but stays same within movie)
+ Video Frame Chunk(s):
+ ... .. Data (in BS v1/v2/v3 format) ;\size = hdr[008h]*4
+ ... .. FFh-filled (padding to Frame Size) ;/
+ ... 4 Frame End ID (eg. 62DCCACEh) ;-same value as in hdr[00Ch]
+This is having neither per-sector STR headers nor Chunk headers, instead it's
+having raw data with fixed size of 10 sectors per frame.
+File Header (sector 0, 800h bytes):
+
000h 4 File ID (01h,"XSP") (aka PSX backwards)
+ 004h 2 Unknown (0001h)
+ 006h 2 Unknown (0040h) (this is used for something...)
+ 008h 2 Bitmap Width (0140h)
+ 00Ah 2 Bitmap Height (00F0h)
+ 00Ch 4 Total number of video frames
+ 010h 4 Number of video sectors per frame (always 8)
+ 014h 4 Total number of video sectors, excluding audio/dummy (=NumFrames*8)
+ 018h 1 Zero
+ 019h 1 Sector List size (28h) (ie. each 4 frames) ;\or zerofilled when
+ 01Ah 28h Sector Types (2=Video, 1=Audio, 0=Dummy) ;/not present
+ 042h .. Zerofilled
+ 7xxh .. Unknown, maybe just garbage ...?
+ ... .. Zerofilled
+ vVvvvvv--vvVvvv--vvvvVv--vvvvvv-Vvvvvvv- Video
+ -------A-------A-------A-------A-------A Audio
+ --------D-------D-------D--------------- Dummy
+ V = 1st sector of video frame
+ v = 2nd..8th sector of video frame (or fileheader in case of sector 0)
+ A = Audio (each 8th sector, ie. sector 07h,0Fh,17h,1Fh,etc.)
+ D = Dummy (occurs after some (not all) audio sectors)
+ Some files have that sector arrangement stored in header[019h..041h], but
+ other files have that header entries zerofilled (despite of using the same
+ arrangement).
+ 0000h 8 Last 8 bytes of BS v1 bitstream ;\or garbage padding
+ 0008h 3FF0h First 3FF0h of BS v1 bitstream ;/
+ 3FF8h 8 Footer (64bit, with squeezed BS header and other info)
+ The footer bits are:
+ 0-4 5bit Quant (00h..1Fh) (only 5bit, not 6bit)
+ 5-15 11bit MDEC Size in 20h-word units (80h-byte units)
+ 16-23 8bit Unknown (lowbits are often same as bit48 and up?)
+ 24-31 8bit BS ID/100h (3800h/100h)
+ 32-47 16bit Frame Number (0=First)
+ 48-63 16bit Next Sector Number (start of next video frame)
+ To decrypt/convert the frame to standard BS v1 format:
+ x=[3FF8h] ;get footer
+ [3FF8h..3FFFh]=[0000h..0007h] ;last 8 bytes of bitstream
+ [0000h]=(x AND FF00FFE0h) ;size and ID=3800h
+ [0004h]=(x AND 1Fh)+10000h ;quant and version=v1
+ The next_sector number is usually current_sector+1 (or +2 if that would be
+ audio), in last frame it does point to end of file.
+ Bitstreams smaller than 3FF8h are garbage padded (initially some 32bit garbage
+ values, and in later frames leftovers from previous bitstream sectors).
+ 000h 4 Always FFFFFFFFh (unfortunately, this isn't a unique ID)
+ 004h 7FCh Garbage (zeroes, random, or even leaked ASM source code)
+ Dummy sectors have the same Subheader as video sectors, the leading FFFFFFFFh
+ could also occur in BS bitstreams or frames with garbage padding, so one must
+ use the sector arrangement pattern to identify dummy sectors.
+There are several discs that have streaming data stored as partial CDROM images
+(instead of as real CDROM sectors).
+
Format Content Where
+ raw 920h-byte STR K9.5 1 - Live in Airedale (ZZBUFFER.STR) ;\
+ raw 920h-byte STR Need for Speed 3 (MOVIES\ZZZZZZZ*.PAD) ;
+ raw 920h-byte STR 3D Baseball (ZZZZZZZZ.ZZZ) ; intended
+ raw 920h-byte STR Wing Commander III (DUMMY.DAT) ; padding
+ raw 920h-byte STR R-Types (DMY\DUMMY.BIN) ;
+ raw 920h+junk STR+junk Grand Slam (DUMMY.BIN) ;
+ raw 920h-byte XA-ADPCM Spec Ops Airborne Commando (PADDING.NUL) ;
+ raw 920h-byte SW-STR Cyberia (ENDFILL\*.STR) (software render) ;
+ RIFFs/CDXAfmt STRs Sonic Wings Special (SW00.DMY = two RIFFs);/
+ raw 920h-byte XA-ADPCM Rugrats (MagDemo19: STREAMS\DB02.ISF) ;\nonsense
+ raw 920h-byte Data BABEh Rugrats (MagDemo19: STREAMS\OPEN.BIN) ; dupes
+ raw ???-byte CDDA Championship Surfer (MagDemo43: HWX\MUSIC);/
+ raw ???-byte CDDA Twisted Metal 2 (MagDemo50: TM2\FRWYSUB.DA) ;-?
+ raw 920h-byte STR Sonic Wings Special (MOV\MQ*.STR) ;-unused?
+ raw 920h-byte STR Apocalypse (MagDemo16: APOC\*.STR)
+ raw 920h-byte XA-ADPCM Apocalypse (MagDemo16: APOC\*.XA)
+ raw 920h-byte XA-ADPCM NFL Xtreme (MagDemo13: NFLX\GAME\SOUND\2PLAYRNO.XA)
+ raw 920h-byte XA-ADPCM Ace Combat 2 (MagDemo01: ACE2.STP)
+ raw 920h-byte XA-ADPCM Colony Wars (MagDemo02: CWARS\DEMO.PAK)
+ raw 920h-byte XA-ADPCM Best Sports demo (AH2\GAMEDATA\COM\MUSIC\MUSIC.IXA)
+ raw 920h-byte XA-ADPCM Tomb Raider: Last Revelation (MagDemo29: TR4\XA1.XA)
+ raw 800h-byte XA-ADPCM Croc 1 demo (MagDemo02: CROC\MAGMUS.STR) (FORM1)
+ RIFF/CDXAfmt XA-ADPCM Best Sports demo (LOMUDEMO\SFX\COMMENT.STR)
+ RIFF/CDXAfmt ?+XA-ADPCM Ace Combat 3 Electrosphere (MagDemo30: AC3\*.SPB)
+ RIFF/CDXAfmt XA-ADPCM Colony Wars Venegance (MagDemo14: CWV\SONYDEMO.PAK)
+ RIFF/WAVEfmt CDDA T'ai Fu (MagDemo16: TAIFU\3_10.WAV, 2x16bit 44100Hz)
+ RIFF/WAVEfmt CDDA Psalm69 (beta) FRONT\FIRE.TRK
+ Data/movie sectors look as so:
+ 000h 4 Sub-Header (File, Channel, Submode OR 20h, Codinginfo)
+ 004h 4 Copy of Sub-Header
+ 008h 800h Data (2048 bytes) ;<-- contains STR movie sectors
+ 808h 4 EDC (zerofilled)
+ 80Ch 114h ECC (zerofilled)
+ And XA-ADPCM sectors look as so:
+ 000h 4 Sub-Header (File, Channel, Submode OR 64h, Codinginfo)
+ 004h 4 Copy of Sub-Header
+ 008h 900h Data (18*128 bytes) ;\contains XA-ADPCM audio sectors
+ 908h 14h Data (zerofilled) ;/
+ 91Ch 4 EDC (zerofilled)
+Legend of Dragoon (MagDemo34: LOD\XA\LODXA00.XA has FIRST SECTOR mis-mastered
+(it has TWO sub-headers (01,00,48,00,01,00,48,00,01,01,64,04,01,01,64,04), the
+remaining sectors are looking okay).
The subheader and data of the 1st sector are accidently overwritten by some
+ASCII string:
+
000h 4 Subheader 01 44 2D 52 ".D-R" ;\distorted
+ 004h 4 Subheader copy 01 4D 20 47 ".M G" ;/"CD-ROM G"
+ 008h 299h Data ASCII 65 6E 65 72 61 ... "enerator for Windows"...
+ 2A1h 567h Data BS bitstream (but lacks BS header and start of bitstream)
+ Version .STR movies .BS pictures
+ BS v2 60% 6% Most games
+ BS v3 20% 4% Some newer games
+ BS v1 15% 0.1% Old games
+ BS ea 2% - (?) Electronic Arts titles
+ BS iki 0.5% 0.1% Several games
+ BS fraquant 0.2% 0.1% Rare (X-Files, Eagle One)
+ BS v0 0.1% - Rare (Serial Experiments Lain)
+ BS v2/v3.crypt 0.2% - Rare (Star Wars games)
+ BS iki.encrypted 0.1% - Rare (Panekit)
+ Wacwac MDEC 0.1% - Rare (Aconcagua)
+ Polygon Streams 0.x% (?) - Some titles
+ Raw MDEC - - Was never used in files?
+ MPEG1 - - VCD Video CDs
+ None ?% (?) 90% No videos or BS pictures
+ v0 used by Serial Experiments Lain
+ v1 used by Wipeout 2097 (MAKE.AV, XTRO*.AV)
+ v1 used by Viewpoint (MOVIES\*.STR) (oddly with [08h]=FirstFrame=0 and
+ [1Ch]=Unspecified=Nonzero) (the game also has ".str" files in
+ VIEW.DIR\streams, but that isn't MDEC/STR stuff)
+ v1 used by Ridge Racer Revolution (MOVIE\*.STR)
+ v1 used by Policenauts
+ v1 used by Final Fantasy VII (FF7)
+ v1? used by Tekken 2
+ v1/v2 used by Final Fantasy Tactics (OPEN*.STR)
+ v1/v2 used by Project Horned Owl (*.STR)
+ v1/v2 used by Gex (*.FMV)
+ (and probably more)
+ v2 used by Gex - Enter the Gecko (*.STR)
+ v2 used by Tomb Raider (FMV\*.FMV)
+ v2 used by Alone (STR*\*.STR)
+ v2 used by Kain (*.STR)
+ v2 used by Fear Effect (BOOT.SID, LOGO.SID, ABGA\ABGA.FLX)
+ v2 used by Parasite Eve 2 (INTERx.STR, and in .CDF's eg. stage1\folder501)
+ v2 used by Witch of Salzburg (MOVIE\*.STR)
+ v2 used by Breath of Fire III (LOGO\*.STR)
+ v2 used by Hear it Now (MOVIE\*.STR)
+ v2 used by Legend of Mana (MOVIE\*.STR)
+ v2 used by Misadventures of Tron Bonne (STR\*.STR)
+ v2 used by Rayman (VIDEO\*.STR)
+ v2 used by Resident Evil 1 (PSX\MOVIE\*.STR) ;\although v3 is
+ v2 used by Resident Evil 2 (PL0\ZMOVIE\*.STR, ZMOVIE\*.STR) ;/used in *.BSS
+ v2 used by Tokimeki Memorial 2 (VX*.STR)
+ v2 used by Spider-Man (CINEMAS\*.STR)
+ v2 used by Perfect Assassin (CDV\*.STR)
+ v2 used by Pandemonium 2 (*.STR)
+ v2 used by Die Hard Trilogy 2 (MOVIE\*.STR)
+ v2 used by Need for Speed 3 (MOVIES\*.STR) (oddly with [14h,18h]<>[20h,24h])
+ v2 used by Wild Arms (STR\*.STR)
+ v2 used by Wild Arms 2 (STR\*.STR)
+ v2 used by Frogger (*.STR)
+ v2 used by Gundam Battle Assault (XA\*.STR)
+ v2 used by Alundra (MOVIE\*.MOV)
+ v2 used by Spec Ops (file 95h,96h within BIGFILE.CAT)
+ v2 used by Crash Team Racing (file 1E1h..1F8h,1FAh within BIGFILE.BIG)
+ (and many more)
+ v2/v3 used by Lemmings Oh No More Lemmings (ANIMS\*.STR)
+ v2/v3 used by Castlevania (*.STR)
+ v3 used by Heart of Darkness (CINE\*.STR, SETUP\*.STR)
+ v3 used by R-Types (MV\*.STR)
+ v3 used by Black Matrix (MOVIE\*.STR)
+ v3 used by Nightmare Creatures II (INTRO\*.STR, LEVEL*\*.STR)
+ (and many more)
+Used by many EA Sports titles and several other titles from Electronic Arts:
+
Castrol Honda Superbike Racing
+ EA Sports Supercross 2000, 2001
+ Future Cop - L.A.P.D. (retail and MagDemo14: FCOPLAPD\*.WVE and *.FSV)
+ Hot Wheels - Turbo Racing
+ Jampack Vol. 2
+ Knockout Kings 99, 2000, 2001
+ Madden NFL 99, 2000, 2001, 2002, 2003, 2004, 2005 (eg. MADN00\FMVIDEO.DAT\*)
+ NASCAR 98, 99, 2000, 2001 (and 98 Collector's Edition, and 99 Legacy)
+ NASCAR Thunder 2002, 2003, 2004 and NASCAR Rumble
+ Nuclear Strike
+ Official U.S. PlayStation Magazine Demo Disc 39 (...XXX which game?)
+ PlayStation Underground Jampack - Winter 2000
+ Road Rash Jailbreak, and Road Rash 3D
+ Tiger Woods PGA Tour Golf, and Tiger Woods USA Tour 2001
+ X-Files (Fox Interactive/Hyperbole Studios, 1999)
+ Eagle One: Harrier Attack (Infogrames/Glass Ghost, 2000)
+ Blue's Clues: Blue's Big Musical (Mattel/Viacom/TerraGlyph, 2000)
+ iki: Gran Turismo 1 (STREAM.DAT) ;\with uncommon STR header
+ iki: Gran Turismo 2 (STREAM.DAT) ;/
+ iki: Hot Shots Golf 2 / Everybody's Golf 2 (MagDemo31: HSG2\MINGOL2X.BIN)
+ iki: Legend of Legaia (MagDemo20: LEGAIA\MOV\MV2.STR)
+ iki: Legend of Dragoon (STR\*.IKI)
+ iki: Omega Boost (MOVIE\*.IKI)
+ iki: Um Jammer Lammy (MagDemo24: UJL\*.IKI) (retail: *\*.IKI and CM\*.IK2)
+ iki: plus a dozen of japanese-only titles
+ Panekit - Infinitive Crafting Toy Case (first 13Mbyte in PANEKIT.STR)
+ v3.xor used by Star Wars Masters of Teras Kasi (MagDemo03: MASTERS\*.STR)
+ v2.xor supported (but not actually used) by Star Wars Masters (MagDemo03)
+ v3.swap used by Star Wars Rebel Assault II (*.STR, *.SED, Stills)
+ v2.swap used by Star Wars Rebel Assault II (*.STR)
+ v3.swap used by BallBlazer Champions (*.STR)
+ Aconcagua (JP) (2000 Sony/WACWAC!) (STR_01_00.STR and STR_09_01.STR)
+ Ape Escape (DEMO\*.STR, STR\*.STR, and KKIIDDZZ.HED\STR\0006h and up)
+ Aconcagua (most STRs are Polygon Streams, except two are Wacwac MDEC streams)
+ Panekit - Infinitive Crafting Toy Case (last 150Mbyte in PANEKIT.STR)
+MPEG1 uses I/P/B-Frames, the I-Frames may reach similar compression as BS
+files. However, P-Frames and B-Frames do compress much better than BS files.
+CDROM Video CDs (VCD)
+MPEG1 isn't used in any PSX games, but VCDs can be viewed on SCPH-5903 consoles
+(or via software decoder in nocash PSX kernel clone).
Most PSX titles do include movies, exceptions are some early launch titles and
+educational titles:
+
Ridge Racer 1 (1994)
+ Lightspan Online Connection CD
+There are several different BS headers. The File ID/Version entries can be used
+to detect the correct type. The MDEC Size entry contains the size after Huffman
+decompression (ie. the half-decompressed size before passing the data to the
+MDEC decompression hardware) (usually divided by 4 and rounded up to 80h/4
+bytes).
000h 2 MDEC Size/4 (after huffman decompression) (rounded to 80h/4 bytes)
+ 002h 2 File ID (3800h)
+ 004h 2 Quantization step/factor (0000h..003Fh, for MDEC "DCT.bit10-15")
+ 006h 2 Version (1, 2, or 3) (2 is most common)
+ 008h ... Huffman compressed data blocks (Cr,Cb,Y1,Y2,Y3,Y4, Cr,Cb,Y1,Y2..)
+Encryption is used in Star Wars games, there are two encryption schemes (XOR
+and SWAP).
+XOR-encrypt: Star Wars Masters of Teras Kasi (MagDemo03: MASTERS\*.STR):
+
000h 2 MDEC Size/4 (rounded to 80h/4 bytes) (unencrypted) ;\same as normal
+ 002h 2 File ID (3800h) (unencrypted) ; BS v1/v2/v3
+ 004h 2 Quant (0..3Fh) (unencrypted) ;/
+ 006h 2 Version (in bit15, plus random in LSBs):
+ 00xxh..7FFFh for v2 (unknown if this could include values 0..3)
+ 8000h..FFFFh for v3 (bit14-0=random, varies in each frame)
+ 008h .. Encrypted bitstream
+ (each halfword XORed by BE67h for v2, or XORed by E67Bh for v3)
+ ... (2) Zeropadding to 4-byte boundary (unencrypted)
+ ... .. Zeropadding to end of sector (unencrypted)
+ The XOR values BE67h/E67Bh are hardcoded in the Star Wars Masters of Teras
+ Kasi .EXE (same XOR values for both retail and demo version), unknown if any
+ other games are also using that kind of encryption (and if yes, if they are
+ using the same XOR values).
+ 000h 2 MDEC Size/4 (rounded to 80h/4 bytes) ;\same as normal
+ 002h 2 File ID (3800h) ; BS v1/v2/v3
+ 004h 2 Quant (0..3Fh) ;/
+ 006h 2 Version (random 16bit, 00xxh..FFFFh) ;-no meaningful version info
+ 008h 2 Bitstream 2nd halfword ;\to "decrypt" the file,
+ 00Ah 2 Bitstream 1st halfword ;/these must be swapped
+ 00Ch .. Bitstream 3rd halfword and up ;-in normal order
+ if header[06h]<=0003h then assume unencrypted v0/v1/v2/v3
+ if header[06h]>=0004h then strip any trailing 0 bits, and check EndOfFrame..
+ if last 10bit = 0111111111 then assume SWAP.v2
+ if last 10bit = 1111111111 then assume SWAP.v3
+ otherwise assume XOR.v2/v3 (and use header[06h].bit15 to distinguish v2/v3)
+IKI videos have a custom .BS header, including some GT-ZIP compressed data:
+
000h 2 MDEC Size/4 (rounded to 80h/4 bytes) ;\same as normal
+ 002h 2 File ID (3800h) ;/BS v1/v2/v3
+ 004h 2 Bitmap Width in pixels ;instead of Quant
+ 006h 2 Bitmap Height in pixels ;instead of Version
+ 008h 2 Size of GT-ZIP compressed data (plus 2-byte alignment padding)
+ 00Ah .. GT-ZIP compressed DC/Quant values (plus 2-byte alignment padding)
+ ... .. Huffman compressed AC data blocks (Cr,Cb,Y1,Y2,Y3,Y4, Cr,Cb,Y1,Y2..)
+The first 20h byte of the iki header & data are encrypted. Among others,
+the ID 3800h is inverted (=C7FFh). To decrypt them:
+
[buf+00h]=[buf+00h] XOR FFFFFFFFh
+ [buf+04h] <--> [buf+08h] ;exchange 2x32bit
+ [buf+0Ch] <--> [buf+0Eh] ;exchange 2x16bit
+ [buf+10h]=[buf+10h]+FFFF6F7Bh
+ [buf+14h]=[buf+14h]+69140000h
+ [buf+18h]=[buf+18h]+FFFF7761h
+ [buf+1Ch]=[buf+1Ch]+6B040000h
+ X-Files, GRAPHICS\*.STR,*.BIN, LOGOS\*.STR,*.BS
+ Eagle One: Harrier Attack (\*.STR, DATA*\*.STR) (leading zerofilled sectors)
+ Blue's Clues: Blue's Big Musical (*.STR) (has one leading zerofilled sector)
+ 004h 2 Quant (0001h..0003h, or fixed-point 8000h..9xxxh)
+ quant=BsHeader[04h] ;get fractional quant value
+ BsHeader[04h]=0001h ;force quant=1 (for use in BS v1/v2/v3 decoder)
+ if quant<8000h then quant=quant*200h else quant=quant AND 7FFFh
+ quant[0]=default_quant_table[0]
+ for i=1 to 3Fh,
+ x=(default_quant_table[i]*quant)/200h
+ if x=00000000h then quant[i]=01h else quant[i]=(x AND FFh)
+ next i
+ use MDEC(2) command to apply quant[0..3Fh] to both Luma and Chroma tables
+ use normal BS v1/v2/v3 decoder to decompress the bitmap
+ 000h 1 Quant for Y1,Y2,Y3,Y4 (00h..3Fh)
+ 001h 1 Quant for Cr,Cb (00h..3Fh)
+ 002h 2 File ID (3800h) (or Frame Number in ENDROLL1.STR on Disc 2)
+ 004h 2 MDEC Size/2 (!), and without padding (!) (unlike v1/v2/v3/iki)
+ 006h 2 BS Version (0) (actually MSBs of above Size, but it's always 0)
+ 008h .. Huffman Bitstream, first bit in bit7 of first byte
+LAPKS.BIN contains several chunks, each chunk contains an animation sequence
+with picture frame(s), each frame starts with following header:
+
000h 2 Bitmap Width in pixels ;\cropped to non-black screen area,
+ 002h 2 Bitmap Height in pixels ;/size can vary within the sequence
+ 004h 2 Quant for Y1,Y2,Y3,Y4 (0000h..003Fh)
+ 006h 2 Quant for Cr,Cb (0000h..003Fh)
+ 008h 4 Size of compressed BS Bitstream plus 4 ;Transparency at [008h]+0Ch
+ 00Ch 2 Size/2 of MDEC data (after huffman decompression, without padding)
+ 00Eh 2 BS Version (0) (actually MSBs of above Size, but it's always 0)
+ 010h .. BS Bitstream with DC and AC values (Huffman compressed MDEC data)
+ ... 4 Transparency Mask Decompressed Size (Width*Height*2/8) (=2bpp)
+ ... .. Transparency Mask LZSS-compressed data
+EA videos are chunk based (instead of using 20h-byte .STR headers).
+CDROM File Video Streaming Chunk-based formats
+VLC0 Chunk: Custom MDEC values (to be assigned to normal BS v2 Huffman codes).
+MDEC Chunks: Width/Height and BS v2 data (using MDEC values from VLC0 chunk).
There aren't any known pictures or movies in raw MDEC format. However, the
+Huffman decompression functions do usually output raw data in this format:
+
000h 2 MDEC Size/4 (after huffman decompression) (rounded to 80h/4 bytes)
+ 002h 2 File ID (3800h)
+ 004h .. MDEC data (16bit DC/AC/EOB codes)
+ ... .. Padding (FE00h-filled to 80h-byte DMA transfer block size boundary)
+ nnnnnnnnnn DC Value (signed 10bit, -200h..+1FFh)
+ If output_size=NumberOfMdecCodes*2 then EndOfFrame
+ If BlockIsCrCb then QuantDC=DC+QuantC*400h else QuantDC=DC+QuantY*400h
+ nnnnnnnnnn DC Value (signed 10bit, -200h..+1FEh)
+ 0111111111 End of Frame (+1FFh, that, in place of Cr)
+ If DC=+1FFh then EndOfFrame
+ QuantDC=DC+Quant*400h
+Similar as v1/v2, but DC values (and End code) are now Huffman compressed
+offsets relative to old DC, with different Huffman codes for Cr/Cb and Y1-Y4:
+
For Cr/Cb For Y1..Y4 Offset (added to old DC of Y/Cr/Cb block)
+ 00 100 +(00h) ;\
+ 01s 00s -(01h)*4 ,+(01h)*4 ;
+ 10sn 01sn -(03h..02h)*4,+(02h..03h)*4 ; required
+ 110snn 101snn -(07h..04h)*4,+(04h..07h)*4 ; codes
+ 1110snnn 110snnn -(0Fh..08h)*4,+(08h..0Fh)*4 ; for 10bit
+ 11110snnnn 1110snnnn -(1Fh..10h)*4,+(10h..1Fh)*4 ; range
+ 111110snnnnn 11110snnnnn -(3Fh..20h)*4,+(20h..3Fh)*4 ;
+ 1111110snnnnnn 111110snnnnnn -(7Fh..40h)*4,+(40h..7Fh)*4 ;/
+ 11111110snnnnnnn 1111110snnnnnnn -(FFh..80h)*4,+(80h..FFh)*4 ;-11bit (!)
+ - 11111110 Unused ;\
+ 111111110 111111110 Unused ; unused
+ 1111111110 1111111110 Unused ;/
+ 1111111111 1111111111 End of Frame ;-end code
+ Note: the "snnn" bits are indexing the values in right column,
+ with s=0 for negative values, and s=1 for positive values.
+ If bits=1111111111 then EndOfFrame
+ If BlockIsCr then DC=DecodeHuffman(HuffmanCodesCbCr)+oldDcCr, oldDcCr=DC
+ If BlockIsCb then DC=DecodeHuffman(HuffmanCodesCbCr)+oldDcCb, oldDcCb=DC
+ If BlockIsY1234 then DC=DecodeHuffman(HuffmanCodesY1234)+oldDcY, oldDcY=DC
+ If older_version AND DC>=0 then QuantDC=Quant*400h or (DC) ;\requires
+ If older_version AND DC<0 then QuantDC=Quant*400h or (DC+400h) ;/11bit
+ If newer_version then QuantDC=Quant*400h+(DC AND 3FFh) ;-wrap 10bit
+The DC values (including Quant values for each block) are separately stored as
+GT-ZIP compressed data in the IKI .BS header.
+CDROM File Compression GT-ZIP (Gran Turismo 1 and 2)
+Calculate NumBlocks=(Width+15)/16*(height+15)/16*6, decompress the DC values
+(until DecompressedSize=NumBlocks*2). During Huffman decompression, read the DC
+values from the decompressed DC buffer (instead of from the Huffman bitstream):
+
If BlockNo>=NumBlocks then EndOfFrame
+ QuantDC = DCbuf[BlockNo]*100h + DCbuf[BlockNo+NumBlocks]
+Below shows the huffman codes and corresponding 16bit MDEC values; the "xx"
+bits contain an index in the list of 16bit MDEC values, the "s" bit means to
+negate the AC level (in lower 10bit of the 16bit MDEC value) when s=1.
10 FE00h ;End of Block, EOB
+ 11s 0001h
+ 011s 0401h
+ 010xs 0002h,0801h
+ 0011xs 1001h,0C01h
+ 00101s 0003h
+ 00100xxxs 3401h,0006h,3001h,2C01h,0C02h,0403h,0005h,2801h
+ 0001xxs 1C01h,1801h,0402h,1401h
+ 00001xxs 0802h,2401h,0004h,2001h
+ 000001xxxxxxxxxxxxxxxx 0000h..FFFFh ;Escape code for raw 16bit values
+ 000001xxxxxx0000000000 0000h..FC00h ;Escape nonsense level=0 (used in v1)
+ 0000001xxxs 4001h,1402h,0007h,0803h,0404h,3C01h,3801h,1002h
+ 00000001xxxxs 000Bh,2002h,1003h,000Ah,0804h,1C02h,5401h,5001h,
+ 0009h,4C01h,4801h,0405h,0C03h,0008h,1802h,4401h
+ 000000001xxxxs 2802h,2402h,1403h,0C04h,0805h,0407h,0406h,000Fh,
+ 000Eh,000Dh,000Ch,6801h,6401h,6001h,5C01h,5801h
+ 0000000001xxxxs 001Fh,001Eh,001Dh,001Ch,001Bh,001Ah,0019h,0018h,
+ 0017h,0016h,0015h,0014h,0013h,0012h,0011h,0010h
+ 00000000001xxxxs 0028h,0027h,0026h,0025h,0024h,0023h,0022h,0021h,
+ 0020h,040Eh,040Dh,040Ch,040Bh,040Ah,0409h,0408h
+ 000000000001xxxxs 0412h,0411h,0410h,040Fh,1803h,4002h,3C02h,3802h,
+ 3402h,3002h,2C02h,7C01h,7801h,7401h,7001h,6C01h
+ 000000000000 Unused
+ 10 FE00h ;End of Block, EOB
+ 11s 0001h
+ 011s 0002h
+ 010xs 0401h,0003h
+ 0011xs 0801h,0005h
+ 00101s 0004h
+ 00100xxxs 000Ah,000Bh,0403h,1801h,000Ch,000Dh,1C01h,000Eh
+ 0001xxs 0006h,0C01h,0402h,0007h
+ 00001xxs 0008h,1001h,0009h,1401h
+ 000001xxxxxx0xxxxxxx 0000h..FC00h+(+001h..+07Fh AND 3FFh) ;\
+ 000001xxxxxx000000001xxxxxxx 0000h..FC00h+(+080h..+0FFh AND 3FFh) ; Escape
+ 000001xxxxxx000000000xxxxxxx Unused ; codes
+ 000001xxxxxx1xxxxxxx 0000h..FC00h+(-080h..-001h AND 3FFh) ;
+ 000001xxxxxx100000000xxxxxxx 0000h..FC00h+(-100h..-081h AND 3FFh) ;
+ 000001xxxxxx100000001xxxxxxx Unused ;/
+ 0000001xxxs 000Fh,0802h,2001h,0404h,0010h,0011h,2401h,0012h
+ 00000001xxxxs 0013h,0405h,0014h,2801h,0015h,0C02h,3001h,0017h,
+ 0016h,2C01h,0018h,001Ch,0019h,0406h,0803h,001Bh
+ 000000001xxxxs 001Ah,3401h,001Dh,0407h,1002h,001Fh,001Eh,3801h,
+ 0020h,0021h,0408h,0023h,0022h,1402h,0024h,0025h
+ 0000000001xxxxs 0804h,0409h,0418h,0026h,3C01h,0027h,0C03h,1C03h,
+ 0028h,0029h,002Ah,002Bh,040Ah,002Ch,1802h,002Dh
+ 00000000001xxxxs 002Fh,002Eh,4001h,0805h,0030h,040Bh,0031h,0033h,
+ 0032h,1C02h,0034h,1003h,0035h,4401h,040Ch,0037h
+ 000000000001xxxxs 0036h,0038h,0039h,5401h,003Ah,0C04h,040Dh,5C01h,
+ 2002h,003Bh,0806h,4C01h,003Ch,2402h,6001h,4801h
+ 000000000000 Unused
+This is using custom MDEC values from VLC0 chunk, and assigns them to the
+standard Huffman codes. There are two special MDEC values:
+
FE00h End of Block (EOB)
+ 7C1Fh Escape code (huffman code will be followed by v2-style 16bit value)
+ 10 00
+ 11x 01,02
+ 011x 03,04
+ 010xx 05,06,07,08
+ 0011xx 0D,0E,0B,0C
+ 00101x 09,0A
+ 00100xxxx 2E,2F,22,23,2C,2D,2A,2B,26,27,24,25,20,21,28,29
+ 0001xxx 15,16,13,14,0F,10,11,12
+ 00001xxx 1A,1B,1E,1F,18,19,1C,1D
+ 000001 17h
+ 0000001xxxx 3E,3F,38,39,30,31,34,35,32,33,3C,3D,3A,3B,36,37
+ 00000001xxxxx 46,47,54,55,4E,4F,44,45,4A,4B,52,53,5E,5F,5C,5D,
+ 42,43,5A,5B,58,59,48,49,4C,4D,40,41,50,51,56,57
+ 000000001xxxxx 74,75,72,73,70,71,6E,6F,6C,6D,6A,6B,68,69,66,67,
+ 64,65,62,63,60,61,7E,7F,7C,7D,7A,7B,78,79,76,77
+ 0000000001xxxxx 9E,9F,9C,9D,9A,9B,98,99,96,97,94,95,92,93,90,91,
+ 8E,8F,8C,8D,8A,8B,88,89,86,87,84,85,82,83,80,81
+ 00000000001xxxxx B0,B1,AE,AF,AC,AD,AA,AB,A8,A9,A6,A7,A4,A5,A2,A3,
+ A0,A1,BE,BF,BC,BD,BA,BB,B8,B9,B6,B7,B4,B5,B2,B3
+ 000000000001xxxxx C6,C7,C4,C5,C2,C3,C0,C1,C8,C9,D4,D5,D2,D3,D0,D1,
+ CE,CF,CC,CD,CA,CB,DE,DF,DC,DD,DA,DB,D8,D9,D6,D7
+ 000000000000 Unused
+All BS versions are using the same Huffman codes (the different BS versions do
+just assign different 16bit MDEC codes to them).
+The huffman codes can be neatly decoded by "counting leading zeroes" (without
+needing bitwise node-by-node processing; this is done in IKI video decoders via
+GTE registers LZCS and LZCR). Sony's normal v2/v3 decoders are using a yet
+faster method: A large table to interprete the next 13bit of the bitstream, the
+table lookup can decode up to 3 huffman codes at once (if the 13bit contain
+several small huffman codes).
A couple of games are storing single pictures in .BS files:
+
Alice in Cyberland (ALICE.PAC\*.BS)
+ BallBlazer Champions (BBX_EXTR.DAT\Pics\*) (SWAP-encrypted)
+ Bugriders: The Race of Kings (*\*.BS and STILLS\MENUS.BS\*)
+ Die Hard Trilogy 2 (DATA\*.DHB, DATA\DH*\L*\*.DHB, MOVIE\*.DHB)
+ Dino Crisis 2 (PSX\DATA\ST*.DBS\*)
+ Duke Nukem (MagDemo12: DN_TTK\*)
+ Final Fantasy VII (FF7) (MOVIE\FSHIP2*.BIN\*) (BS v1)
+ Gran Turismo 1 (retail TITLE.DAT\* and MagDemo10/15) (in BS iki format)
+ Jet Moto 2 (MagDemo03: JETMOTO2\*)
+ Mary-Kate and Ashley Crush Course (MagDemo52: CRUSH\SCRN\*.BS)
+ Mat Hoffman's Pro BMX (MagDemo48: MHPB\STILLS.BIN\*) (with width/height info)
+ NFL Gameday '99 (MagDemo17: GAMEDAY\FE\GD98DATA.DAT)
+ Official U.S. PlayStation Magazine Demo Disc 01-02 (MENU\DATA\*.BSS)
+ Official U.S. PlayStation Magazine Demo Disc 03-54 (MENU.FF\*)
+ Parasite Eve 2 (INIT.BS, and within .HED/.CDF archives)
+ Resident Evil 1 (PSX\STAGE*\*.BSS, headerless archive, 8000h-byte align)
+ Resident Evil 2 (COMMON\BSS\*.BSS, headerless archive, 10000h-byte align)
+ Rugrats (MagDemo19: RUGRATS\*)
+ Rugrats Studio Tour (MagDemo32: RUGRATS\DATA\RAW\*.BS)
+ Starwars Demolition (MagDemo39+MagDemo41: STARWARS\SHELL\.BS+.TBL\*)
+ Star Wars Rebel Assault 2 (RESOURCE.000\Stills\*) (SWAP-encrypted)
+ Ultimate Fighting Championship (MagDemo38: UFC\CU00.RBB\390h..3E2h)
+ Vigilante 8 (MagDemo09: EXAMPLE\*)
+ Witch of Salzburg (PICT\PIC*\*.BS and DOT1 archives *.BSS, *.DAT, *.BIN)
+ X-Files (LOGOS\*.BS and GRAPHICS\GRAPHICS.BIN and GRAPHICS\PACKEDBS.BIN\*)
+ You Don't Know Jack 2 (MagDemo41: YDKJV2\RES\UI\*.BS)
+Movies have Width/Height entries (in the .STR header). Raw .BS picture files
+don't have any such information. However, there are ways to guess the correct
+resolution:
+
For BS iki format, use resolution from iki header (eg. Gran Turismo 1)
+ For MHPB\STILLS.BIN, there's width/height in chunk headers
+ Count the number of blocks (EOB codes) during Huffman decompression
+ Divide that number by 6 to get the number of Macroblocks
+ Search matches for Height=NumBlocks/Width with Width>=Height and Remainder=0
+ If Height=300..400, assume double H-resolution, repeat with Width/2>=Height
+ And/or use a list of known common resoltions (see below examples)
+ Search arrangements with many similar colors on adjacent macroblocks
+ Blocks Pixels Example
+ F0h 256x240 any?
+ 12Ch 320x240 Resident Evil 2 (COMMON\BSS\*.BSS)
+ 1E0h 512x240 Demo Disc 03-54 (MENU.FF\*), Duke Nukem (MagDemo12)
+ 1E0h 640x192 Less common than above (but used by Witch of Salzburg)
+ 4B0h 640x480 Vigilante 8 (MagDemo09), Jet Moto 2 (MagDemo03)
+ var random Witch of Salzburg has various random resolutions
+ iki ikihdr Gran Turismo 1 has A0hxA0h and odd size (!) E8hx28h
+ ? ? Final Fantasy VII (FF7)
+ ? ? Ultimate Fighting Championship (UFC\CU00.RBB\3B7h..3E2h)
+ 118h 320x224 Alice in Cyberland (most files; or two such as panorama)
+ 230h ? Alice in Cyberland (AD_115.BS and AD_123A.BS)
+ C8h 320x160 Unlikely for pictures (but used for STR videos, eg. Alone)
+ F0h 320x192 Unlikely for pictures (but used for STR videos, eg. Wipeout)
+ 1E0h 384x320 Very unlikely to see that vertical resolution on PSX
+Starwars Demolition (MagDemo39: STARWARS\SHELL\DEMOLOGO.BS+RESOURCE.TBL\)
+Starwars Demolition (MagDemo41: STARWARS\SHELL\DEMOLOGO.BS+RESOURCE.TBL\)
+
000h 2 Width (280h) ;\extra header
+ 002h 2 Height (1E0h) ;/
+ 004h 2 MDEC Size/4 (after huffman decompression) (rounded to 80h/4 bytes)
+ 006h 2 File ID (3800h)
+ 008h 2 Quantization step/factor (0000h..003Fh, for MDEC "DCT.bit10-15")
+ 00Ah 2 Version (1, 2, or 3) (2 is most common)
+ 00Ch ... Huffman compressed data blocks (Cr,Cb,Y1,Y2,Y3,Y4, Cr,Cb,Y1,Y2..)
+Wacwac uses different Huffman codes than BS videos, the decoder has some
+promising ideas that might yield slightly better compression than BS v3.
+However, it is used by only one known game:
+
Aconcagua (JP) (2000 Sony/WACWAC!)
+ 000h 2 STR ID (0160h)
+ 002h 2 STR Type WACWAC Tables (0002h=IntroTableSet, 0003h=EndingTableSet)
+ 004h 2 Sector number within current Frame (0000h..num-1)
+ 006h 2 Number of Sectors in this Frame
+ 008h 4 Frame number (6 or 11 and up, because 1st some frames are Polygons)
+ 00Ch 4 Frame Size in bytes
+ 010h 2 Bitmap Width (always 140h) ;\always 320x208 (in fact, the
+ 012h 2 Bitmap Height (always 0D0h) ;/decoder is hardcoded as so)
+ 014h 4 Quant (0..3Fh) (same for all sectors within the frame)
+ 018h 8 Zerofilled
+ 020h 7E0h Raw Bitstream data (without Quant or BS header) (garbage padded)
+ Intro=Disc1:\ST01_01\STR_01_00.STR Ending=Disc2:\ST09_01\STR_09_01.STR
+ Leading zeroes (150 sectors) Leading zeroes (150 sectors)
+ Frame 0001h..0005h Polygon Frames Frame 0001h..000Ah Polygon Frames
+ Frame 0006h..0545h MDEC Frames 20MB Frame 000Bh..0D79h MDEC Frames 50MB
+ Frame 0546h..1874h Polygon Frames 48MB
+Wacwac uses little-endian bitstreams (starting with low bit in bit0 of first
+byte). To decode the separate blocks in the bitstream:
+
Read Huffman code for DC, and output Quant*400h+(DC AND 3FFh)
+ Read Huffman code for Size, aka num1,num2,num3 values for below reads
+ Repeat num1 times: Read Huffman code for AC1, and output AC
+ Repeat num2 times: Read Huffman code for AC2, and output AC
+ Repeat num3 times: Read Huffman code for AC3, and output AC
+ Output EOB (end of block)
+ 14h*0Dh*6*41h*2+Align(80h)+Header(4) = 31880h+4 bytes
+Aconcagua has two table sets, stored in PROGRAM.BIN (in compressed form,
+appearing as so: FF,90,16,2E,06,20,03,D6,etc). While watching the intro movie,
+the uncompressed sets can be found at these RAM locations:
+
80112AF8h (1690h bytes) ;Table Set for Intro Scene
+ 80114188h (1B68h bytes) ;Table Set for Ending Scene
+ 000h 4 Table Set size (1690h or 1B68h)
+ 004h 4 Table Set exploded size (when allocating 16bit/DC, 32bit/Size/AC)
+ 008h 2 Size Table max Huffman size in bits (0Ah or 09h) ;\Size
+ 00Ah 2 Size Table number of entries (40h) ;/
+ 00Ch 2 DC Table max Huffman size in bits (0Bh) ;\
+ 00Eh 2 DC Table number of entries (100h) ; DC
+ 010h 2 DC Huffman code Escape 10bit (non-relative 10bit DC value) ;
+ 012h 2 DC Huffman size Escape 10bit (3 or 6, escape prefix size) ;/
+ 014h 2 AC1 Table max Huffman size in bits (0Eh or 0Bh) ;\
+ 016h 2 AC1 Table number of entries (0DAh or 100h) ;
+ 018h 2 AC1 Huffman code Escape 7bit (run=0bit, level=signed7bit) ; AC1
+ 01Ah 2 AC1 Huffman code Escape 16bit (run=6bit, level=10bit) ;
+ 01Ch 2 AC1 Huffman size Escape 7bit (9 or 7, escape prefix size) ;
+ 01Eh 2 AC1 Huffman size Escape 16bit (9 or 7, escape prefix size) ;/
+ 020h 2 AC2 Table max Huffman size in bits (0Eh) ;\
+ 022h 2 AC2 Table number of entries (AAh or F4h) ;
+ 024h 2 AC2 Huffman code Escape 8bit (run=3bit, level=signed5bit) ; AC2
+ 026h 2 AC2 Huffman code Escape 16bit (run=6bit, level=10bit) ;
+ 028h 2 AC2 Huffman size Escape 8bit (10 or 9, escape prefix size) ;
+ 02Ah 2 AC2 Huffman size Escape 16bit (10 or 9, escape prefix size) ;/
+ 02Ch 2 AC3 Table max Huffman size in bits (0Eh) ;\
+ 02Eh 2 AC3 Table number of entries (87h or B2h) ;
+ 030h 2 AC3 Huffman code Escape 8bit (run=4bit, level=signed4bit) ; AC3
+ 032h 2 AC3 Huffman code Escape 16bit (run=6bit, level=10bit) ;
+ 034h 2 AC3 Huffman size Escape 8bit (10 or 9, escape prefix size) ;
+ 036h 2 AC3 Huffman size Escape 16bit (10 or 9, escape prefix size) ;/
+ 038h .. Size Table (64bit per entry) ;\
+ ... .. DC Table (32bit per entry) ;
+ ... .. AC1 Table (64bit per entry) ; Tables
+ ... .. AC2 Table (64bit per entry) ;
+ ... .. AC3 Table (64bit per entry) ;/
+ 0-1 Zero
+ 2-31 Huffman code (10bit max)
+ 32-39 Number of AC1 codes in this block ;\implies End of Block (EOB)
+ 40-47 Number of AC2 codes in this block ; after those AC codes
+ 48-55 Number of AC3 codes in this block ;/
+ 56-63 Huffman size (1..10 bits)
+ 0-9 Relative DC Value (relative to old DC from memorized Cr,Cb,Y)
+ 10-15 Huffman size (1..11 bits)
+ 16-31 Huffman code (11bit max)
+ Notes: For the relative DC's, the decoder does memorize DC for Cr,Cb,Y upon
+ decoding Cr,Cb,Y1,Y3 (but does NOT memorize DC when decoding Y2,Y4).
+ Initial DC for Cr,Cb,Y is zero at begin of each 16x208pix slice.
+ Obscurities: The decoder does accidentally use bit10 to sign-expand the
+ DC value in bit0-9 (but does mask-off those bugged sign bits thereafter),
+ and the decoder does uselessly memorize Y1 and Y3 separately (but uses only
+ the most recently memorized value).
+ 0-1 Zero
+ 2-31 Huffman code (14bit max)
+ 32-47 MDEC code (6bit run, and 10bit AC level)
+ 48-63 Huffman size (1..14 bits)
+Used by Ape Escape (Sony 1999) (DEMO\.STR and some STR\.STR files and
+KKIIDDZZ.HED\STR\0006h and up).
+The files start with zerofilled sectors (without STR headers), followed by
+sectors with STR headers with [00h]=0160h, [02h]=8001h (same values as for
+MDEC), but with [10h..1Fh]=zero (without resolution/header info). And the data
+at [20h] starts with something like 14h,00h,03h,FFh,2Ah,02h,00h,00h.
+That data seems to consist of polygon coordinates/attributes that are rendered
+as movie frames. The texture seems to be stored elsewhere (maybe in the .ALL
+files that are bundled with some .STR files).
Panekit STR seems to use Polygon Streaming (except 1st some Megabytes are
+MDEC).
Aconcagua STR does use Polygon Streaming (except first+last movie are MDEC).
Cyberia is using Software-rendering for both movies and in-game graphics. That
+is, PSX hardware features like MDEC, GTE, and GPU-Polygons are left all unused,
+and the GPU is barely used for transferring data from CPU to VRAM.
+The STR header for software-rendered movie frames looks as so:
+
000h 2 STR ID (0160h)
+ 002h 2 STR Type (0002h=Custom, Software rendering)
+ 004h 2 Sector number within current Frame (0..num-1)
+ 006h 2 Number of Sectors in this Frame (varies)
+ 008h 4 Frame Number (1=First)
+ 00Ch 4 Frame Size in Bytes/4 (note: first frame in MAP*.STR is quite big)
+ 010h 2 Rendering Width (0140h)
+ 012h 2 Rendering Height (00C0h)
+ 014h 0Ch Unknown (zerofilled or random garbage)
+ 020h 7E0h Custom data for software rendering
+Probably cut-scenes with polygon animations. The files seem to contain
+2300h-byte data frames (plus XA-ADPCM sectors inserted here and there).
+
000h 4 Number of remaining frames
+ ... 22FCh Unknown data (zeropadded if smaller)
+ _______________ Unknown Streaming Data (Polygons or whatever) ________________
+This is used for several files in 3D Baseball (BIGFILE.FOO):
+
BIGFILE.FOO\0151h\0005h,0009h,000Fh,0017h,001Bh, 02E5h,02E9h,..,0344h,0348h
+ BIGFILE.FOO\0152h\0186h,018Ch,0192h,0198h)
+ BIGFILE.FOO\0153h\029Ah,02A0h,02A6h,02ACh)
+ 000h 2 STR ID (0160h)
+ 002h 2 STR Type (0001h=Custom)
+ 004h 2 Sector number within current Frame (always 0)
+ 006h 2 Number of Sectors in this Frame (always 1)
+ 008h 4 Frame Number (1=First)
+ 00Ch 4 Frame Size (6FAh or 77Ah, sometimes 17Ah or 1FAh or 20Ah)
+ 010h 2 Unknown (280h, or sometimes 300h or 340h)
+ 012h 2 Frame Time (0=First, increases with step [19h], usually +5 or +7)
+ 014h 2 Unknown (280h, or sometimes 300h or 3C0h, or 0)
+ 016h 1 Frame Time (same as [012h] AND FFh)
+ 017h 1 Unknown (0 or 1)
+ 018h 1 Unknown (40h, or 80h, or C0h)
+ 019h 1 Duration? (5 or 7, or sometimes less, step for Frame Time)
+ 01Ah 1 Unknown (3, or less in last some frames)
+ 01Bh 5 Zerofilled
+ 020h 7E0h Data (increasing/decreasing bytes... maybe non-audio waveforms?)
+ 000h 2 STR ID (0160h)
+ 002h 2 STR Type (0000h=Custom)
+ 004h 2 Sector number within current Frame (0..2)
+ 006h 2 Number of Sectors in this Frame (always 4) (3xSTR + 1xADPCM)
+ 008h 4 Frame Number (1=First)
+ 00Ch 4 Frame Size? (800h, despite of having 3 sectors with 7E0h each?)
+ 010h 2 Unknown (00h or 01h)
+ 012h 2 Unknown (A3h or ABh ... 6Ch or 7Bh ... or 43h or 49h)
+ 014h 2 Sector number within current Frame (0..2) (same as [004h])
+ 016h 0Ah Zerofilled
+ 020h 7E0h Data (polygon streaming or so?)
+ Charumera ENDING.XA (with dummy/zero data)
+ True Love Story TLS\MULTI.XA (with nonzero data)
+ True Love Story 2 TLS2\ENDING.STR and TLS2\MULTI.XA
+ True Love Story Fan Disc ;\probably use that format, too
+ True Love Story: Remember My Heart ;/(not verified)
+This game has normal MDEC Streams, and Special Streams in non-MDEC format (eg.
+Disc1, File 0E9h-16Eh and 985h-B58h), perhaps containing Polygon Streams or
+whatever.
+There are two channels (file=1/channel=00h-01h), each channel contains data
+that consists of 5 sectors per frame (1xHeader plus 4xData). The sectors have
+STR ID=0160h, and STR Type as follows:
+
0000h=Whatever special, channel 0 header (sector 0)
+ 0400h=Whatever special, channel 1 header (sector 1)
+ 0001h=Whatever special, channel 0 data (sector 2,4,6,8)
+ 0401h=Whatever special, channel 1 data (sector 3,5,7,9)
+ \*.STR MDEC movies ;\BS fraquant (except, demo version
+ \DATA*\*.STR MDEC movies ;/ on MagDemo31 uses mormal BS v2)
+ \DATA*\M*\L*.STR Multi-language TXT files with STR header on each sector
+ \DATA*\M*\I*.STR unknown binary data (whatever and SPU-ADPCM)
+ \LANGN.STR unknown binary data (whatever)
+PSX Lightspan Online Connection CD, cdrom:\CD.TOC:\UI*\.VAG
+PSX Wipeout 2097, cdrom:\WIPEOUT2\SOUND\SAMPLES.WAD:\.vag (version=02h)
+PSX Perfect Assassin, DATA.JFS:\AUDIO\.VAG and DATA.JFS:\SND\.VAG
+
000h 4 File ID (usually "VAGp")
+ 004h 4 Version (usually 02h, or 20h) (big-endian)
+ 008h 4 Reserved (0) (except when ID="VAGi") (big-endian)
+ 00Ch 4 Channel Size (data size... per channel?) (big-endian)
+ 010h 4 Sample Rate (in Hertz) (eg. 5622h=22050Hz) (big-endian)
+ 014h 0Ch Reserved (0) (except when version=2)
+ 020h 10h Name (ASCII, zeropadded)
+ ... (..) Optional ID string (eg. "STEREO" in upper/lowercase)
+ ... (..) Optional Padding to Data start
+ ... .. ADPCM Data for channel(s) (usually at offset 030h)
+ .vag default (eg. many PSX games)
+ .vig 2-channel with interleave=10h (eg. PS2 MX vs ATV Untamed)
+ .vas 2-channel with interleave=10h (eg. PS2 Kingdom Hearts II)
+ .swag 2-channel with interleave=filesize/2 (eg. PSP Frantix)
+ .l and .r 2-channel in l/r files (eg. PS2 Gradius V, PS2 Crash Nitro Kart)
+ .str whatever (eg. P?? Ben10 Galactic Racing)
+ .abc whatever (eg. PSP F1 2009 (v6), according to wiki.xentax.com)
+ "VAGp" default (eg. many PSX games)
+ "VAG1" 1-channel (eg. PS2 Metal Gear Solid 3)
+ "VAG2" 2-channel (eg. PS2 Metal Gear Solid 3)
+ "VAGi" 2-channel interleaved (eg. ?)
+ "pGAV" little endian with extended header (eg. PS2 Jak 3, PS2 Jak X)
+ "AAAp" extra header, followed by "VAGp" header (eg. PS2 The Red Star)
+ 00000000h v1.8 PC
+ 00000002h v1.3 Mac (eg. PSX Wipeout 2097, in SAMPLES.WAD)
+ 00000003h v1.6+ Mac
+ 00000020h v2.0 PC (most common, eg. PSX Perfect Assassin)
+ 00000004h ? (later games, uh when/which?)
+ 00000006h ? (vagconf, uh when/which?)
+ 00020001h v2.1 (vagconf2) ;\with HEVAG coding instead SPU-ADPCM
+ 00030000h v3.0 (vagconf2) ;/(eg. PS4/Vita)
+ 40000000h ? (eg. PS2 Killzone) (1-channel, little endian header)
+ 008h 4 Interleave (little endian) (the other header entries are big endian)
+This does reportedly contain some default "base" settings for the PSX SPU:
+
014h 2 Volume left 4Eh,82h ;-Port 1F801C00h
+ 016h 2 Volume right 4Eh,82h ;-Port 1F801C02h
+ 018h 2 Pitch (includes fs modulation) A8h,88h ;-Port 1F801C04h +extra bit?
+ 01Ah 2 ADSR1 00h,00h ;-Port 1F801C08h
+ 01Ch 2 ADSR2 00h,E1h ;-Port 1F801C0Ah
+ 01Eh 2 ? A0h,23h ;-Port 1F801C0xh maybe?
+ 01Eh 1 Number of channels (0 or 1=Mono, 2=Stereo)
+ 01Ch 2 Zero ;if non-zero: force Mono
+ 01Eh 1 Number of channels (0 or 1=Mono, 2=Stereo ;if 10h..FFh: force Mono
+ 01Fh 1 Zero ;if non-zero: force Mono
+The ADPCM data uses PSX SPU-ADPCM encoding (even on PS2 and up, except PS4 with
+Version=0002001h or Version=00030000h, which do use HEVAG encoding).
+SPU ADPCM Samples
+The data does usually start at offset 0030h (except, some files have extra
+header data or padding at that location).
+The first 10h-byte ADPCM block is usually all zero (used to initialize the
+SPU).
+2-channel (stereo) files are usually interleaved in some way.
The file header entries are almost always big-endian (even so when used on
+little endian consoles). There are a few exceptions:
+ID="VAG1" has little endian [008h]=Interleave (remaining header is big-endian).
+ID="pVAG" has (some?) header entries in little endian.
+Version=40000000h has most or all header entries in little endian (perhaps
+including the version being meant to be 00000040h).
VAGs can be 1-channel (mono) or 2-channel (stereo). There is no standarized way
+to detect the number of channels (it can be implied in the Filename Extension,
+Header ID, in Reserved Header entries, in the Name string at [020h..02Fh], in
+optional stuff at [030h], or in a separate VAG Header in the middle of the
+file).
None default (for 1-channel mono) (and separate .l .r stereo files)
+ 800h when ID="VAG2"
+ [008h] when ID="VAGi" (little-endian 32bit header[008h])
+ 1000h when ID="pGAV" and [020h]="Ster" and this or that
+ 2000h when ID="pGAV" and [020h]="Ster" and that or this
+ 10h when filename extension=".vig"
+ 10h when Version=0002001h or Version=00030000h (and channels=2)
+ filesize/2 when filename extension=".swag"
+ 6000h when [6000h]="VAGp" (eg. PSX The Simpsons Wrestling)
+ 1000h when [1000h]="VAGp" (eg. PS2 Sikigami no Shiro)
+ ...
+ 000h 4 ID "AAAp"
+ 004h 2 Interleave
+ 006h 2 Number of Channels (can be 1 or 2?)
+ 008h 30h*N VAGp header(s) for each channel, with Version=00000020h
+ ... .. ADPCM Data (interleaved when multiple channels)
+http://github.com/vgmstream/vgmstream/blob/master/src/meta/vag.c ;very detailed
+http://wiki.xentax.com/index.php/VAG_Audio ;rather incomplete and perhaps wrong
.VAB contains VAB header, and ADPCM binaries ;-all in one file
+ .VH contains only the VAB header ;\in two separate files
+ .VB contains only the ADPCM binaries ;/
+ 0000h 4 File ID ("pBAV")
+ 0004h 4 Version (usually 7) (reportedly 6 exists, too) (5, 20h exists)
+ 0008h 4 VAB ID (usually 0)
+ 000Ch 4 Total .VAB filesize in bytes (or sum of .VH and .VB filesizes)
+ 0010h 2 Reserved (EEEEh)
+ 0012h 2 Number of Programs, minus 1 (0000h..007Fh = 1..128 programs)
+ 0014h 2 Number of Tones, minus? (max 0800h?) (aka max 10h per program)
+ 0016h 2 Number of VAGs, minus? (max 00FEh)
+ 0018h 1 Master Volume (usually 7Fh)
+ 0019h 1 Master Pan (usually 40h)
+ 001Ah 1 Bank Attribute 1 (user defined) (usually 00h)
+ 001Bh 1 Bank Attribute 2 (user defined) (usually 00h)
+ 001Ch 4 Reserved (FFFFFFFFh)
+ 0020h 800h Program Attributes 10h-byte per Program 00h..7Fh (fixed size)
+ 0820h P*200h Tone Attributes 200h-byte per Program 00h..P-1 (variable size)
+ xx20h 200h 16bit VAG Sizes (div8) for VAG 00h..FFh (fixed size)
+ xx20h (...) ADPCM data (only in .VAB files, otherwise in separate .VB file)
+ 000h 1 tones Number of Tones in the Program (Yaroze: 4) (uh?)
+ 001h 1 mvol Master Volume (Yaroze: 0..127)
+ 002h 1 prior (Yaroze: N/A)
+ 003h 1 mode (Yaroze: N/A)
+ 004h 1 mpan Master Panning (Yaroze: 0..127)
+ 005h 1 reserved0
+ 006h 2 attr (Yaroze: N/A)
+ 008h 4 reserved1
+ 00Ch 4 reserved2
+ 000h 1 prior Tone Priority (Yaroze: 0..127, 127=highest)
+ 001h 1 mode Mode (Yaroze: 0=Normal, 4=Reverberation)
+ 002h 1 vol Tone Volume (Yaroze: 0..127)
+ 003h 1 pan Tone Panning (Yaroze: 0..127)
+ 004h 1 center Centre note (in semitone units) (Yaroze: 0..127)
+ 005h 1 shift Centre note fine tuning (Yaroze: 0..127)
+ 006h 1 min Note limit minimum value (Yaroze: 0..127)
+ 007h 1 max Note limit maximum value (Yaroze: 0..127)
+ 008h 1 vibW (Yaroze: N/A)
+ 009h 1 vibT (Yaroze: N/A)
+ 00Ah 1 porW (Yaroze: N/A)
+ 00Bh 1 porT (Yaroze: N/A)
+ 00Ch 1 pbmin Max? value for downwards pitchbend (Yaroze: 0..127)
+ 00Dh 1 pbmax Max value for upwards pitchbend (Yaroze: 0..127)
+ 00Eh 1 reserved1
+ 00Fh 1 reserved2
+ 010h 2 ADSR1 Attack,Decay (Yaroze: 0..127,0..15)
+ 012h 2 ADSR2 Release,Sustain (Yaroze: 0..127,0..31)
+ 014h 2 prog Program number that tone belongs to (Yaroze: 0..127)
+ 016h 2 vag VAG number (Yaroze: 0..254)
+ 018h 8 reserved
+This can contain max 254 "VAG files" (maybe because having two (?) reserved
+8bit numbers?).
+Sony wants the total size of the ADPCM data to be max 7E000h bytes (which would
+occupy most of the 512Kbyte SPU RAM, leaving little space for the echo buffer
+or additional effects).
+Note: The "VAG files" inside of VAB/VB are actually raw SPU-ADPCM data, without
+any VAG file header. The first 10h-byte ADPCM block is usually zerofilled.
.SEQ contains MIDI-style sequences, the samples for the instruments can be
+stored in a separate .VAB file (or .VH and .VB files).
+Used by Perfect Assassin, DATA.JFS:\SND\*.SEQ (bundled with *.VH and *.VB)
+Used by Croc (MagDemo02: CROC\CROCFILE.DIR\AMBI*.BIN, MAP*.BIN, JRHYTHM.BIN)
+Used by many other games.
+
000h 4 File ID "pQES"
+ 004h 4 Version (1) (big endian?)
+ 008h 2 Resolution per quarter note (01h,80h)
+ 00Ah 3 Tempo 24bit (8bit:16bit maybe?) (07h,27h,0Eh)
+ 00Dh 2 Rhythm (NN/NN) (04h,02h)
+ 00Fh ... Score data, uh? (with many MIDI KeyOn's: xx,9x,xx,xx)
+ ... 3 End of SEQ (2Fh=End of Track) (FFh,2Fh,00h)
+This is a simple "archive" with several SEQ-like sequences.
+
000h 4 File ID "pQES" ;same ID as in .SEQ files (!)
+ 004h 2 Version (0) ;value 0, and only 16bit, unlike .SEQ files
+ 006h .. 1st Sequence
+ ... .. 2nd Sequence
+ ... .. etc.
+ 000h 2 Sequence ID (0000h and up) (big endian) ;-ID number
+ 002h 2 Resolution per quarter note (01h,80h) ;\
+ 004h 3 Tempo 24bit (07h,27h,0Eh) ; as in SEQ files
+ 007h 2 Rhythm (NN/NN) (04h,02h) ;/
+ 009h 4 Data size (big endian, from 00Dh up to including End of SEQ(
+ 00Dh ... Score data, uh? (...) ;\as in SEQ files
+ ... 3 End of SEQ (2Fh=End of Track) (FFh,2Fh,00h) ;/
+This is a newer Sony format from 1999 (resembling the older .SEQ .VH .VB
+format).
+Used by Alundra 2, Ape Escape, Arc the Lad 3, Koukidou Gensou - Gunparade
+March, Omega Boost, PoPoLoCrois Monogatari II, The Legend of Dragoon, Wild Arms
+2.
+
.SQ Sequence Data (with ID "SSsq")
+ .HD Voice Header (with ID "SShd")
+ .BD Voice Binary (raw SPU-ADPCM, same as .VB)
+ 000h 2 Unknown (always 64h)
+ 002h 2 Unknown (always 1E0h)
+ 004h 1? Unknown (varies)
+ 005h 7 Zerofilled
+ 00Ch 4 ID "SSsq"
+ 010h 10h*10h Unknown Table
+ 110h .. Unknown Data
+ 000h 4 Size of the .HD file itself
+ 004h 4 Size of the corresponding .BD file
+ 008h 4 Zero
+ 00Ch 4 ID "SShd"
+ 010h 1Ch*4 Offsets to data (or FFFFFFFFh=None)
+ 080h .. Data
+ 000h .. SPU-ADPCM data (usually starting with zerofilled 10h-byte block)
+There are four four file types:
+
"DNSa" (aka SouND backwards) ;sequence data
+ "PMSa" (aka SaMPles backwards) ;samples with small header
+ "FMSa" (aka SaMples-F... backwards) ;samples with bigger header ;\Legacy
+ "FNSa" (aka SouNd-F... backwards) ;whatever tiny file ;/of Kain
+ Akuji (MagDemo18: AKUJI\BIGFILE.DAT\*) (DNSa,PMSa)
+ Gex 2 (MagDemo08: GEX3D\BIGFILE.DAT\*) (DNSa)
+ Gex 3: Deep Cover Gecko (MagDemo20: G3\BIGFILE.DAT\*) (DNSa,PMSa)
+ Legacy of Kain 2 (MagDemo13: KAIN2\BIGFILE.DAT\*) (DNSa)
+ Legacy of Kain 2 (MagDemo26: KAIN2\BIGFILE.DAT\*) (DNSa,PMSa,FNSa,FMSa)
+ Walt Disney World Racing Tour (MagDemo35: GK\BIGFILE.DAT\*) (DNSa,PMSa)
+ 000h 4 ID "PMSa"
+ 004h 4 Total Filesize
+ 008h 8 Zerofilled
+ 010h .. SPU-ADPCM data (usually starting with zerofilled 10h-byte block)
+ 000h 4 ID "DNSa" ;aka SND backwards
+ 004h 2 Offset from DNSa+4 to 8-byte entries (can be odd)
+ 006h 1 Unknown (3)
+ 007h 1 Number of 8-byte entries (N1)
+ 008h 1? Number of 10h-byte entries (N2)
+ ... .. Unknown (..)
+ ... N1*8 Whatever 8-byte entries
+ ... N2*10h Whatever 10h-byte entries
+ ... .. ... circa 40h 4-byte entries...?
+ ... .. Unknown (..)
+ ... .. Several blocks with ID "QESa" or "QSMa" ;supposedly MIDI-style?
+These are whatever tiny files (with filesize 1Ch or 2Ch).
+
000h 4 ID "FNSa"
+ ... .. Unknown
+ 000h 4 ID "FMSa"
+ 008h .. Unknown..
+ ... .. SPU-ADPCM data (usually starting with zerofilled 10h-byte block)
+There a several games that have sound files with ID "AKAO".
+
XXX does that include different AKAO formats... for Samples and Midi?
+Alone in the Dark IV has MIDB and DSND chunks (which contain sound files).
The page below does mention several PSX sound formats, plus some open source
+& closed source tools for handling those files.
+https://github.com/loveemu/vgmdocs/blob/master/Conversion_Tools_for_Video_Game_Music.md
Audio streaming is usually done by interleaving the .STR or .BS file's Data
+sectors with XA-ADPCM audio sectors (the .STR/.BS headers don't contain any
+audio info; because XA-ADPCM sectors are automatically decoded by the CDROM
+controller).
+Raw XA-ADPCM files (without video) are usually have .XA file extension.
The eleven .SWP files in Wipeout 2097 seem to be CD-DA audio tracks.
+The one TRACK01.WAV in Alone in the Dark, too?
+Other than that, tracks can be accessed via TOC instead of filenames.
000h 4 ID ("DPAC") ;\
+ 004h 4 Unknown (100h) ;
+ 008h 4 Number of files (N) ;
+ 00Ch 4 Directory Size (N*8) ; Header
+ 010h 4 File Data area size (SIZE = Totalsize-Headersize) ;
+ 014h 4 Unknown (1) ;
+ 018h 7E8h Zerofilled (padding to 800h-byte boundary) ;
+ 800h N*8 File List ;
+ ... .. Zerofilled (padding to 800h-byte boundary) ;/
+ ... SIZE File Data area ;-Data area
+ File List entries:
+ 000h 8 Filename ("NAME")
+ 004h 2 File Offset/800h (increasing)
+ 006h 2 File Size/800h
+RESHEAD.BIN:
+
000h N*10h File List (220h bytes)
+ File List entries:
+ 000h 8 Filename ("FILENAME", if shorter: terminated by 00h plus garbage)
+ 008h 4 Filesize in bytes
+ 00Ch 4 Offset/800h in RESBODY.BIN (increasing) (or FFFFFFFFh if Size=0)
+ 000h .. File Data (referenced from RESHEAD.BIN)
+ 000h N*10h File List
+ ... .. File Data area
+ File List entries:
+ 000h 0Ch Filename (eg. "FILENAME 001") ;for last entry: "END 000"
+ 00Ch 4 Offset (increasing, N*10h and up) ;for last entry: zero
+MCD.DIR:
+
000h N*10h File List
+ ... 10h End marker (FFh-filled)
+ File List entries:
+ 000h 8 Filename (zeropadded if less than 8 chars)
+ 008h 2 Zero (0000h)
+ 00Ah 2 Size/800h
+ 00Ch 4 Offset/800h in MCD.IMG
+ Note: Filenames are truncated to 8 chars (eg. "FOREST.T" instead "FOREST.TIM")
+ 000h .. File Data area (encrypted in True Love Story 2)
+ init_key_by_filename(name): ;for MCD.IMG (using filenames from MCD.DIR)
+ i=0, key0=0001h, key1=0001h, key2=0001h
+ while i<8 and name[i]<>00h
+ key0=(key0 XOR name[i])
+ key1=(key1 * name[i]) AND FFFFh
+ key2=(key2 + name[i]) AND FFFFh
+ ret
+ init_key_by_numeric_32bit_seed(seed): ;maybe for LINEAR.IMG and PICT.IMG ?
+ key0=(seed) AND FFFFh
+ key1=(seed - (seed*77975B9h/400000000h)*89h) AND FFFFh
+ key2=(seed - (seed*9A1F7E9h/20000000000h)*3527h) AND FFFFh
+ ret
+ decrypt_data(addr,len):
+ for i=1 to len/2
+ key2=key2/2 + (key0 AND 1)*8000h
+ key0=key0/2 + (key1 AND 1)*8000h
+ key1=key1/2 + ((key1/2 OR key0) AND 1)*8000h
+ key0=((((key1+47h) AND FFFFh)/4) XOR key0)+key2+(((key1+47h)/2) AND 1)
+ halfword[addr]=halfword[addr] XOR key0, addr=addr+2
+ ret
+ Item Unencrypted Encrypted
+ Parent Folder name "TLS" "TLS2"
+ First name in MCD.DIR "BACKTILE" "TEST.RPS"
+ First word in MCD.IMG 00000010h 074D4C8Ah
+The Rebel RESOURCE.* files start with name "bigEx" or "fOFS", BallBlazer *.DAT
+start with "SFXbase" or "tpage", nested files start with whatever other names.
+
000h N*10h File List
+ ... (4) CRC32 on above header (Top-level only, not in Nested archives)
+ ... .. File Data area
+ ... (..) Huge optional padding to xx000h-byte boundary (in BallBlazer .DAT)
+ File List entries in Top-level archives (with [0Ch].bit31=1):
+ 000h 8 Filename (zeropadded if less than 8 chars)
+ 008h 4 Decompressed Size (or 0=File isn't compressed)
+ 00Ch 4 Offset, self-relative from current List entry (plus bit31=1)
+ File List entries in Nested archives (with [0Ch].bit31=0):
+ 000h 0Ch Filename (zeropadded if less than 12 chars)
+ 00Ch 4 Offset, self-relative from current List entry (plus bit31=0)
+ Last File List entry has [00h..0Bh]=zerofilled, and Offset to end of file.
+ 000h .. Uncompressed Data
+ ... .. CRC32 on above Data (Top-level only, not in Nested archives)
+ 000h 1 Compression Method (01h=LZ/16bit, 02h=LZ/24bit)
+ 001h 3 Decompressed Size (big-endian)
+ 004h .. Compressed Data
+ ... .. Zeropadding to 4-byte boundary
+ ... .. CRC32 on above bytes (method, size, compressed data, padding)
+ 000h 4 Number of files (big endian)
+ 004h N*14h File List
+ ... .. File Data
+ 000h 0Ch Filename ("FILENAME.EXT", zeropadded if shorter than 12 chars)
+ 00Ch 4 Filesize in bytes (can be odd) (big endian)
+ 010h 4 Fileoffset in bytes (increasing, 4-byte aligned) (big endian)
+ 0000h 2000h Folder 1
+ 2000h .. File Data for Folder 1
+ ... 2000h Folder 2
+ ... .. File Data for Folder 2
+ ... 2000h Folder End marker (FFFFFFFFh, plus zeropadding)
+ 0000h 4 Folder ID (increasing, 1,2,3, or FFFFFFFFh=End)
+ 0004h 4 Number of files (max 198h) (N)
+ 0008h 4 File Data Area size/800h (S)
+ 000Ch 4 Zero (0)
+ 0010h N*14h File List
+ ... .. Zeropadding to 2000h
+ 2000h S*800h File Data Area for this folder
+ 000h 4 Filesize in bytes
+ 004h 10h Filename (FILENAME.EXT, zeropadded)
+These are child archives found inside of the main GT-ARC and DATA.DAT archives.
+
000h 4 Number of Files (eg. 26h) (usually at least 02h or higher)
+ 004h N*14h File List
+ ... .. File Data area
+ File List entries:
+ 000h 10h Filename ("FILENAME.EXT", zeropadded if shorter)
+ 010h 4 Offset in bytes (increasing, 4-byte-aligned?)
+ DIR:
+ 000h 4 Number of Entries (0Eh)
+ 004h N*14h File List
+ DAT:
+ 000h .. File Data (referenced from CROCII.DIR)
+ 000h 0Ch Filename ("FILENAME.EXT", zeropadded if shorter)
+ 00Ch 4 File Size in bytes
+ 010h 4 File Offset in .DAT file (800h-byte aligned, increasing)
+ 000h N*14h File List
+ ... 14h Zerofilled (File List end marker)
+ ... .. File Data area
+ File List entries:
+ 000h 0Ch Filename ("FILENAME.EXT", zeropadded if shorter)
+ 00Ch 4 Offset (increasing, 4-byte aligned)
+ 010h 4 Filesize in bytes (can be odd, eg. for .FA2 files)
+ 000h N*14h File List (3Ch*14b bytes, unused entries are zeropadded)
+ 4B0h .. Data area (TIM files for player uniforms)
+ File List entries:
+ 000h 10h Filename ("FILENAME.EXT", zeropadded)
+ 010h 4 Offset (zerobased, from begin of Data area, increasing)
+ 000h 0Ch Fixed ID (always "KotJCo01Dir ") (always that same string)
+ 00Ch 4 Number of Files
+ 010h N*18h File List
+ ... .. File Data area
+ 000h 10h Filename ("FILENAME.EXT", zeropadded)
+ 010h 4 Offset in bytes (increasing, 1-byte or 4-byte aligned)
+ 014h 4 Filesize in bytes (can be odd)
+ 000h N*18h File List (18h-bytes each)
+ ... 18h File List end marker (zerofilled)
+ ... .. File Data
+ 000h 1 Filename Checksum (sum of bytes at [001h..00Dh])
+ 001h 1 Filename Length (excluding ending zeroes) (eg. 8, 9, 10, 12)
+ 002h 0Ch Filename ("FILENAME.EXT", zeropadded if less than 12 chars)
+ 00Eh 2 Unknown (2000h) (maybe attr and/or ending zero for filename)
+ 010h 4 Filesize in bytes (can be odd)
+ 014h 4 Offset (increasing, 4-byte aligned)
+ 000h 4 Header Size in bytes (2800h) (can be MUCH bigger than needed)
+ 004h 4 Zero
+ 008h 4 ID "Indx"
+ 00Ch 4 Zero
+ 010h 4 Number of Files (N) (CEh) (can be zero=empty in .IDX files)
+ 014h 4 Header Size/800h (05h)
+ 018h 4 Zero
+ 01Ch 4 Zero
+ 020h N*18h File List
+ ... .. Zeropadding to end of Headersize
+ ... .. File Data area
+ 000h 0Ch Filename ("FILENAME.EXT", zeropadded if shorter)
+ 00Ch 4 Offset/800h
+ 010h 4 File Size/800h
+ 014h 4 File Size in bytes
+ IDX files use the same File List entry format as LVL, but the offsets
+ seem to refer to an external file with corresponding name, for example:
+ cdrom:\ABE2\CR.LVL\CR.IDX ;directory info
+ cdrom:\ABE2\CR.MOV ;external data (the .MOV being a .STR video)
+ XXX: That's not tested/verified, and not implemented in no$psx file viewer.
+ 000h 4 Unknown (6)
+ 004h 4 Total Filesize (1403800h)
+ 008h 2 Unknown, Alignment? (800h)
+ 00Ah 2 Number of Files, excluding zerofilled File List entries (ACh)
+ 00Ch 4 Header Size (1800h)
+ 010h 4 Unknown, Entrysize? (18h)
+ 014h 4 Unknown, Entrysize? (18h)
+ 018h N*18h File List (can contain unused zerofilled entries here and there!)
+ ... .. File Data area
+ 000h 10h Filename ("FILENAME.EXT", zeropadded)
+ 010h 4 File Offset in bytes (800h-byte aligned, unusorted/not increasing)
+ 014h 4 File Size in bytes
+ 000h 4 ID "KGB",00h
+ 004h 4 Number of Files (N)
+ 008h (4) Number of Files negated (-N) ;<-- optional, not in LITESHOW.KGB
+ ... N*18h File List
+ ... (..) CBh-padding to alignment boundary (only if align=800h)
+ ... .. File Data area
+ 000h 10h Filename ("FILENAME.EXT", terminated by 00h, padded with CDh)
+ 010h 4 File Size in bytes
+ 014h 4 File Offset (800h-byte or 1/4-byte? aligned)
+ 000h 4 Unknown (80000001h)
+ 004h 4 Offset/800h to Final Padding area
+ 008h 8 Zerofilled
+ 010h N*18h File List
+ ... (..) CDh-padding to 800h-byte alignment boundary
+ ... .. File Data area
+ ... 800h Some text string talking about "last-sector bug"
+ ... 40BEh Final Padding area (CDh-filled)
+ 000h 10h Filename ("FILENAME.EXT", terminated by 00h, padded with CDh)
+ 010h 4 File Offset/800h (increasing)
+ 014h 4 File Size/800h
+ 000h 0Fh ID ("Art", zeropadded) ;\
+ 00Fh 1 Type or so ("?") ; sorts of File List entry
+ 010h 4 Number of entries plus 1 (N+1) ; for root folder
+ 014h 4 Total Size in bytes (can be odd) ;/
+ 018h N*18h File List
+ ... ... File Data area
+ File List entries:
+ 000h 0Fh Filename ("FILENAME", zeropadded)
+ 00Fh 1 Type/extension or so ("X" or "D")
+ 010h 4 File Offset (unaligned, increasing)
+ 014h 4 File Size in bytes (can be odd)
+ 000h 4 Unknown (301h)
+ 004h 4 Zero (0)
+ 008h 4 Number of files (N)
+ 00Ch N*18h File List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ File List entries:
+ 000h 4 Offset (800h-byte aligned, increasing)
+ 004h 4 Filesize in bytes
+ 008h 1 Unknown (01h)
+ 009h 0Fh Filename ("FILENAME.EXT",00h, plus garbage padding)
+ Texsize is 6900Eh, but should be 6900Ch = 200h*1A4h*2+0Ch
+ Filesize is 6A000h, but should be 69014h = 200h*1A4h*2+14h
+ 000h 2 Number of Files (C9h)
+ 002h N*18h File List
+ ... (..) Padding to 800h-byte boundary (if any, eg. in MOVIES.LIB)
+ ... .. File data area (800h-byte aligned, or unaligned)
+ File List entries:
+ 000h 4 Filesize in bytes
+ 004h 4 Offset (increasing, 800h-byte aligned, or unaligned)
+ 008h 10h Filename ("filename.ext", zeropadded)
+ 000h 4 ID "DCAT"
+ 004h 4 Number of Entries
+ 008h N*18h File List
+ ... .. Zerofilled (padding to 800h-byte boundary)
+ ... .. File Data area
+ File List entries:
+ 000h 10h Filename ("FILENAME.EXT", terminated by 00h, plus garbage padding)
+ 010h 4 Filesize in bytes
+ 014h 4 Offset (increasing, 800h-byte aligned)
+ 000h 4 ID "FRID"
+ 004h 4 Always E0000000h
+ 008h 4 Always 800h (...maybe alignment)
+ 00Ch 4 Number of Entries (N)
+ 010h 4 Header Size (N*18h+20h, plus padding to 800h-byte boundary)
+ 014h 4 Always 18h (...maybe entry size)
+ 018h 8 Zerofilled
+ 020h N*18h File List
+ ... .. Zerofilled (padding to 800h-byte boundary)
+ ... .. File Data area
+ File List entries:
+ 000h 0Ch Filename ("FILENAME.EXT", zeropadded if shorter)
+ 00Ch 4 Offset (increasing, 800h-byte aligned)
+ 010h 4 Filesize in bytes
+ 014h 4 Unknown (checksum? random?)
+ 000h N*18h File List
+ ... .. File Data area (directly after File List, without end-code)
+ Note: There is no file-list end-marker (instead, the Offset in 1st File
+ entry does imply the end of File List).
+ File List entries:
+ 000h 10h Filename ("FILENAME.EXT", zeropadded)
+ 010h 4 Offset (increasing, 4-byte aligned, or unaligned for TXT files)
+ 014h 4 Filesize in bytes (or weird nonsense in SFX.MAD)
+ SFX.MAD has nonsense Filesize entries (eg. 164h for a 15150h-byte file).
+ FACES.MAD contains only one TIM file... but as 3Mbyte junk appended?
+ RINKS.MAD and TEAMS.MAD start with 0Dh,0Ah,1Ah followed by 4Mbyte junk.
+ MISCFILE.MAD contains several nested .mad files.
+ MISCFILE.MAD\panfont.mad\*.txt --> starts with FF,FE --> that's 16bit Unicode?
+ INF:
+ 000h N*18h File List
+ WAD:
+ 000h .. File Data area
+ 000h 4 File Offset/800h in .WAD file
+ 004h 4 File Size in bytes
+ 008h 10h Filename ("FILENAME.EXT", zeropadded)
+ 000h 4 Number of entries (N)
+ 004h N*18h File List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ File List entries:
+ 000h 10h Filename ("FILENAME.EXT", zeropadded)
+ 010h 4 Fileoffset (800h-byte aligned, increasing)
+ 014h 4 Filesize in bytes
+ 000h 2 Type (31h=TPF with TIMs, 32=PPF with PMDs)
+ 002h 2 Number of entries (N) (can be 0=None, eg. STAGE*\MORT.PPF)
+ 004h 4 File List Size (N*18h)
+ 008h 4 Header Size (always 14h)
+ 00Ch 4 Data area Size (Filesize-14h-N*18h)
+ 010h 4 Data area Offset (14h+N*18h)
+ 014h N*18h File List
+ ... .. File Data area
+ File List entries:
+ 000h 10h Filename ("FILENAME.EXT", zeropadded)
+ 010h 4 Filesize in bytes
+ 014h 4 Fileoffset (from begin of Data area, increasing)
+ 000h 4 ID "BACR" (aka RCAB backwards)
+ 004h 4 Number of entries (N)
+ 008h N*18h File List
+ ... .. File Data area
+ File List entries:
+ 000h 10h Filename ("FILENAME.EXT", zeropadded)
+ 020h 4 Offset (from begin of Data area, increasing, 4-byte aligned)
+ 024h 4 Filesize in bytes (can be odd)
+PSX Wipeout 2097, cdrom:\WIPEOUT2\SOUND\SAMPLES.WAD:\.vag
+PSX Wipeout 2097, cdrom:\WIPEOUT2\TRACK*\TRACK.WAD:\.*
+PSX Wipeout 3 (MagDemo25: WIPEOUT3\*)
+
000h 2 Number of files
+ 002h N*19h Directory Entries for all files
+ ... .. Data for all files (without any alignment, in same order as above)
+ 000h 10h Filename (ASCII, can be lowercase), terminated by 00h, plus garbage
+ 010h 4 Filesize in bytes ;\maybe compressed/uncompressed, or rounded,
+ 014h 4 Filesize in bytes ;/always both same
+ 018h 1 Unknown (always 00h)
+ 000h 4 Number of entries with location 0=MIX (M=65h)
+ 000h 4 Number of entries with location 1=XA (X=1)
+ 008h M*1Ch File List for location 0=MIX
+ ... X*1Ch File List for location 1=XA
+ 000h 10h Filename (terminated by 00h, padded with garbage)
+ 010h 4 Offset/800h in DATA.MIX or Offset/930h DATA.XA file (increasing)
+ 014h 4 Filesize in bytes
+ 018h 4 File Location (0=DATA.MIX, 1=DATA.XA)
+ 000h 4 Unknown (80000001h)
+ 004h 4 Offset/800h to Final Padding area
+ 008h 8 Zerofilled
+ 010h N*1Ch File List
+ ... (..) CDh-padding to 800h-byte alignment boundary
+ ... .. File Data area
+ ... 3394h Final Padding area (CDh-filled)
+ 000h 14h Filename ("FILENAME.EXT", terminated by 00h, padded with CDh)
+ 014h 4 File Offset/800h (increasing)
+ 018h 4 File Size/800h
+ v1 (Syphon Filter 1) has filename_len=10h (and filelist_entrysize=18h)
+ v2 (Syphon Filter 2) has filename_len=14h (and filelist_entrysize=1Ch)
+ 000h 4 Number of Files
+ 004h N*20h File List
+ ... 10h File List End: Name (zerofilled)
+ ... 4 File List End: Offset (total filesize, aka end of last file)
+ ... 0Ch File List End: Padding (zerofilled)
+ ... .. File Data area
+ 000h 10h Filename ("FILENAME.EXT", terminated by 00h, padded with garbage)
+ 010h 4 File Offset in bytes (increasing, 4-byte aligned)
+ 014h 0Ch Padding (garbage) (usually 800F68A0h,800F68A0h,800F68A0h)
+ 000h 4 Number of Files (1C3h)
+ 004h N*20h File List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ 000h 10h Filename ("FILENAME.EXT", zeropadded, sorted alphabetically)
+ 010h 4 File Offset/800h (unsorted, not increasing)
+ 014h 4 File Size in bytes
+ 018h 4 File Size/800h
+ 01Ch 4 Zero
+ 000h N*20h File List
+ ... 4 File List End Offset/800h (end of last file)
+ ... 4 File List End Size (zero)
+ ... 18h File List End Name (zerofilled)
+ ... .. Padding to 800h-byte boundary (each 20h-byte: 01h, and 1Fh zeroes)
+ ... .. File Data
+ 000h 4 Offset/800h (increasing)
+ 004h 4 Filesize in bytes
+ 008h 18h Filename ("FILENAME.EXT" or ":NAME" or ":NAME:NAME", zeropadded)
+About same as the other Test Drive games, but with shorter filenames.
+
000h N*20h File List (1920h bytes used; with padding: 5800h bytes in total)
+ ... .. Zeropadding to Headersize (5800h)
+ ... .. File Data area
+ File List entries:
+ 000h 18h Filename ("FILENAME.EXT" or "PATH\FILENAME.EXT", zeropadded)
+ 018h 4 Filesize in bytes
+ 01Ch 4 File (Offset-Headersize)/800h
+ 000h 4 ID ("TDSK") ;\
+ 004h 4 Number of Files (1Bh) ; Directory
+ 008h N*20h File List ;/
+ ... 4 1st File Size (same as Size entry in File List) ;\File Data area
+ ... .. 1st File Data ; (each file os
+ ... 4 2nd File Size (same as Size entry in File List) ; preceeded by
+ ... .. 2nd File Data ; a size entry)
+ ... .. etc. ;/
+ File List entries:
+ 000h 10h Filename ("FILENAME.EXT", zeropadded)
+ 010h 4 File Size in bytes
+ 014h 4 Unknown (35xxxxxxh..372xxxxxh)
+ 018h 4 Unknown (3724xxxxh) (Timestamp maybe?)
+ 01Ch 4 File Offset in bytes (increasing, 4-byte aligned)
+ 000h N*20h File List (B60h bytes)
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area (files are AAh-padded to 800h-byte boundary)
+ File List entries:
+ 000h 4 Filesize in bytes
+ 004h 2 File Offset/800h (16bit) (increasing)
+ 006h 1Ah Filename ("FILENAME.EXT" or "PATH\FILENAME.EXT", zeropadded)
+ 000h 2 Zero (0000h)
+ 002h 2 Number of Files (N)
+ 004h 4 Data Base (N*20h+10h)
+ 008h 4 Unknown (20h) ;-maybe File List entry size?
+ 00Ch 2 Unknown (10h) ;\maybe filename length and/or header size?
+ 00Eh 2 Unknown (10h) ;/
+ 010h N*20h File List
+ ... .. File Data area
+ 000h 4 Zero
+ 004h 4 File Offset (increasing, 4-byte aligned, relative to Data Base)
+ 008h 4 File Size in bytes (can be odd)
+ 00Ch 4 Zero
+ 010h 10h Filename ("FILENAME.EXT", zeropadded)
+ WAD:
+ 000h N*20h File List
+ STR:
+ 000h .. File Data (MagDemo39: 4.5Mbyte, MagDemo48: compressed/2.8Mbyte)
+ File List entries:
+ 000h 14h Filename ("FILENAME.EXT", zeropadded)
+ 014h 4 Offset in bytes, 4-byte aligned, in STR file
+ 018h 4 Filesize, compressed (always rounded to multiple of 4 bytes)
+ 01Ch 4 Filesize, decompressed (zero when not compressed)
+ - end flag is processed immediately (instead of after the block)
+ - blocktype is only 1bit wide (instead of 2bit)
+ - stored blocks have plain 16bit len (without additional 16bit inverse len)
+ bmx_tinf_style_uncompress(dst,src)
+ tinf_init() ;init constants (needed to be done only once)
+ @@lop:
+ if tinf_getbit()=0 then goto @@done ;end flag, 1bit
+ if tinf_getbit()=0 then ;blocktype, 1bit
+ tinf_align_src_to_byte_boundary()
+ len=LittleEndian16bit[src], src=src+2 ;get len (without inverse len)
+ for i=0 to len-1, [dst]=[src], dst=dst+1, src=src+1, next i ;uncompressed
+ else
+ tinf_decode_dynamic_trees(), tinf_inflate_compressed_block() ;compressed
+ gpto @@lop
+ @@done:
+ ret
+Used on most PlayStation Magazine Demo Discs (Disc 03-54, except Disc 01-02)
+Used on PlayStation Underground 3.1 (and maybe other issues)
+Used on Interactive CD Sampler Disc Volume 10 (maybe others, but not Vol 4,5)
+
000h 4 Number of entries (eg. 20h or 28h)
+ 004h N*28h File List
+ ... .. Garbage padding to 800h-byte boundary
+ ... .. File Data
+ ... .. Huge zeropadding to 200000h or 2EE000h (2048Kbyte or 3000Kbyte)
+ 000h 20h Filename (terminated by 00h, padded with... looks like garbage)
+ 020h 4 Size/800h
+ 024h 4 Offset/800h (increasing)
+This is used by several games, with different Headersizes (2000h or 3000h or
+5000h), with Offsets relative to the Headersize. To detect the Headersize, skip
+used entries, skip following zeropadding, then round-down to 800h-byte boundary
+(in case the 1st file contains some leading zeroes).
+
000h N*28h File List (less than 0C00h bytes used in TD4 demo)
+ ... .. Zeropadding to Headersize (2000h or 3000h or 5000h)
+ ... .. File Data
+ 000h 20h Filename ("PATH\FILENAME.EXT", zeropadded)
+ 020h 4 Size in bytes
+ 024h 4 (Offset-Headersize)/800h (increasing)
+ 0000h N*28h File List
+ 21C0h ... Unknown random gibberish? (23h,E8h,0Ch,1Dh,79h,C5h,24h,...)
+ 4000h ... File Data area
+ 000h 1Ch Filename ("\PATH\FILENAME.EXT;0", zeropadded)
+ 01Ch 4 Filesize in bytes
+ 020h 4 Fileoffset in bytes (4000h and up, increasing)
+ 024h 4 Filechecksum (32bit sum of all bytes in the file)
+ 000h 4 ID "BIND"
+ 004h 4 Number of files (N)
+ 008h N*28h File List
+ ... .. File Data area
+ 000h 20h Filename ("\FILENAME.EXT", zeropadded)
+ 020h 4 File Offset (increasing, 4-byte aligned) ;\see note
+ 024h 4 File Size in bytes (always a multiple of 4) ;/
+ size=((filesize+3) AND not 3) ;size entry for curr file (plus 3)
+ offs=((filesize+4) AND not 3)+offs ;offs entry for next file (plus 4 !!!)
+ 000h 4 Number of entries (N)
+ 004h 4 Number of entries (same as above)
+ 008h 4 Number of entries (same as above)
+ 00Ch 4 Number of entries (same as above)
+ 010h N*28 File List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ File List entries:
+ 000h 20h Filename ("\PATH\FILENAME.EXT", zeropadded)
+ 020h 4 Offset/800h, from begin of Data area (increasing)
+ 024h 4 Filesize in bytes
+ 000h 4 Number of Files
+ 004h N*34h File List
+ ... .. Zeropadding to 4000h
+ 4000h .. File Data area
+ File List entries:
+ 000h 10h Filename ("FILENAME.EXT", zeropadded)
+ 010h 4 Filesize in bytes ;\always both same, always
+ 014h 4 Filesize in bytes ;/both multiple of 800h
+ 018h 4 Zero
+ 01Ch 4 Type (07h..1Ah)
+ 020h 4 Subtype (00h..01h)
+ 024h 10h Zero
+ 07h.0 .TIM (*.TIM)
+ 07h.01h .TIM (HUD_*.TIM)
+ 08h.0 .TIM (PSTART.TIM)
+ 09h.0 .TIM (FONT.TIM)
+ 0Ah.0 .SFX
+ 0Eh.0 .MBL
+ 10h.0 .ATR
+ 11h.0 .RLC
+ 13h.0 .AST
+ 15h.0 .SCD
+ 16h.0 .TXT (PAUSED.TXT)
+ 17h.0 .TXT (OBJECT*.TXT)
+ 18h.0 .BIN
+ 1Ah.0 Misc (.3DO=TIM, .V=TXT, and TERRAIN.CLP .HI .LIT .MAP .PAT .POB .TER)
+ 000h 4 Number of Files (N)
+ 004h 4 Size of File Data area (SIZ) (total filesize-8-N*40h)
+ 008h N*40h File List
+ ... SIZ File Data area
+ File List entries:
+ 000h 4 Filesize in bytes
+ 004h 4 Fileoffset in bytes (zerobased, from begin of File Data area)
+ 008h 38h Filename, zeropadded
+ 000h 4 ID ("GLUE")
+ 004h 4 Unknown (always 400h)
+ 008h 4 Number of Files (N)
+ 00Ch 4 Header Size (40h+N*40h)
+ 010h 30h Zerofilled
+ 040h N*40h File List
+ ... .. Garbage padding to alignment boundary
+ ... .. File Data area
+ File List entries:
+ 000h 20h Filename ("FILENAME.EXT", zeropadded)
+ 020h 4 File Offset in bytes (increasing, 800h-byte aligned)
+ 024h 4 File Size in bytes
+ 028h 2 File ID Number 1 (eg. 1-71 for C01.GLU-C71.GLU)
+ 02Ah 2 Unknown (random, checksum, ?)
+ 02Ch 4 File ID Number 2 (eg. increasing: 1, 2, 3)
+ 030h 10h Zerofilled
+ 000h 4 Number of entries (N)
+ 010h N*60h File List
+ ... .. Zeropadding to 2000h
+ 2000h .. File Data area
+ File List entries:
+ 000h 4 Timestamp? (BFxxxxh..C0xxxxh) (or zero, in first file)
+ 004h 4 Unknown (always 421C91h)
+ 008h 4 Unknown (200h or 60200h)
+ 00Ch 4 Filesize (uncompressed)
+ 010h 4 Filesize (compressed, or 0 when not compressed)
+ 014h 4 File Checksum (sum of all bytes in uncompressed file data)
+ 018h 4 Unknown (random 32bit value?)
+ 01Ch 10h Filename ("FILENAME.EXT", zeropadded)
+ 02Ch 4 Zerofilled
+ 030h 4 Unknown (0 or 1 or 8)
+ 034h 4 File Type (see below)
+ 038h 8 Zerofilled
+ 040h 4 Offset MSBs (Fileoffset-2000h)/800h ;\increasing, 4-byte aligned
+ 044h 4 Offset LSBs (Fileoffset AND 7FFh) ;/(or zero when filesize=0)
+ 048h 18h Zerofilled
+ 000h 4 ID (A69AA69Ah)
+ 004h 4 Number of files (N)
+ 008h N*90h File List
+ ... .. File Data area
+ File List entries:
+ 000h 80h Filename ("DATA\FILENAME.EXT",00h, plus CDh-padding)
+ 080h 4 File Offset in bytes (increasing, 4-byte aligned)
+ 084h 4 File Size in bytes
+ 088h 8 Unknown (random/checksum?)
+ Used by Spider-Man (MagDemo31,40: SPIDEY\CD.HED and CD.WAD)
+ Used by Spider-Man 2 (MagDemo52: SPIDEY\CD.HED and CD.WAD)
+ Used by Tony Hawk's Pro Skater (MagDemo22: PROSKATE\CD.HED and CD.WAD)
+ Used by Apocalypse (MagDemo16: APOC\CD.HED and CD.WAD) ;with PADBUG
+ Used by MDK (Jampack Vol. 1: MDK\CD.HED and CD.WAD) ;without ENDCODE
+ Used by Mat Hoffman's Pro BMX (old demo) (MagDemo39: BMX\BMXCD.HED+WAD)
+ 000h .. File Entries (see below)
+ ... (1) End code (FFh) (if any, not present in MDK)
+ 000h .. Filename (ASCII, terminated by 00h, zeropadded to 4-byte boundary)
+ ... 4 Offset in CD.WAD (in bytes, usually 800h-byte aligned)
+ ... 4 Filesize (in bytes)
+ 000h 4 Number of Files (N) (1ADh)
+ 004h 4 Unknown (7) (maybe HeaderSize/800h, same as first Offset/800h ?)
+ 008h 4 Unknown (1430h = 14h+N*0Ch, same as first Name pointer)
+ 00Ch 4 Unknown (1430h = 14h+N*0Ch, same as first Name pointer)
+ 010h 4 Unknown (1430h = 14h+N*0Ch, same as first Name pointer)
+ 014h N*4 Name List (pointers to name strings, 1430h and up) 6B4h bytes
+ ... N*4 Size List (filesize in bytes) 6B4h bytes
+ ... N*4 Offset List (Offset/800h) 6B4h bytes
+ ... N*var Name Strings (ASCII strings, "folder\filename.ext",00h)
+ ... .. Zerofilled (padding to 800h-byte boundary)
+ ... .. File Data area
+ 000h 4 Number of Files (N)
+ 004h N*8 File List (2x32bit entries: Offset, Size) (unaligned, can be odd)
+ ... N*4 File Name Offsets
+ ... N*var File Name Strings ("FILE NN",0Ah,00h)
+ ... .. Garbage-padding to 4-byte boundary
+ ... (4) Optional extra garbage? ("MON " in ATLANTFI.PAK, MARSFI.PAK, etc.)
+ ... .. File Data area (ZLIB compressed, starting with big-endian 789Ch)
+ 000h 4 ID (12h,34h,56h,78h) (aka 12345678h in big endian)
+ 004h 4 Header Size (offset to File Data area)
+ 008h 4 Number of Entries (can be 0=None, eg. LEVELS\LARGO07.DCF\Z16.CAT)
+ 00Ch N*var Name List (Filenames in form "FILENAME.EXT",00h)
+ ... .. Zeropadding to 4-byte boundary
+ ... N*4 Size List (Filesizes in bytes)
+ ... .. File Data area
+ 000h 4 Number of files (N) (3..EBh) (big-endian)
+ 004h N*Var File List (list size is implied in first file offset)
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ File List entries:
+ 000h 4 File Type (ascii, .LLN .TXI .TPG .RCI .RCP .WDB .PCI .PCP .BLK)
+ 004h 4 File Size (can be odd) (big-endian)
+ 008h 4 File Offset (increasing, 800h-byte aligned) (big-endian)
+ 00Ch 4 Extra Size (0 or 4 or 8) (big-endian)
+ 010h .. Extra Data (if any) (32bit number, or "TEXTURES")
+ 000h 4 Timestamp? (36xxxxxxh=v1?, 38xxxxxxh=v2?, other=SLF.RFF)
+ 004h 4 Number of Files (N)
+ 008h 4 Base for Offset List (always 14h)
+ 00Ch 4 Base for String Table (v1=N*4+14h, or v2=N*4+18h)
+ 010h 4 Base for File Data (end of String Table plus align 4/800h/920h)
+ 014h N*4 Offsets to File(s) (increasing, first=0, relative to above [010h])
+ ... (4) v2 only: End Offset for Last File (HOG filesize minus [010h])
+ ... .. String Table (filename list in form of "FILENAME.EXT",00h)
+ ... .. Zeropadding to 4-byte or 800h-byte boundary
+ ... .. File Data area
+ v1 has [0Ch]=N*4+14h (without end-of-last-file entry; use end=total_size)
+ v2 has [0Ch]=N*4+18h (and does have end-of-last-file entry)
+ v1 has STR files in ISO filesystem (not in HOG archives)
+ v2 has STR files in MOVIES.HOG (with [10h]=920h and [14h and up]=sectors)
+ v1/v2 has [10h]=data base, aligned to 4 or 800h
+ v1/v2 has [14h and up] in BYTE-offsets, relative to base=[10h]
+ v1/v2 uses HOG format in .HOG files also in SLF.RFF
+ v1/v2 has further .RFF files (but that aren't in HOG format)
+ v2 MOVIE.HOG has [10h]=920h (which is meant to mean base="after 1st sector")
+ v2 MOVIE.HOG has [14h and up] in SECTOR-units, with base="after 1st sector"
+ v2 SLF.RFF does contain two HOG archives badged together (plus final padding)
+ v2 has some empty 0-byte .HOG files (at least so in demo version)
+ 000h 4 ID "BIGF" (normal case, all big-endian, 4-byte aligned) ;\
+ ID "BIGH" (with [04h]=little-endian instead big-endian) ;
+ ID "BIG4" (with 40h-byte alignment padding instead 4-byte) ;
+ 004h 4 Sum of Header+Filesizes (excluding Padding's!) (big-endian) ; Header
+ 008h 4 Number of entries (N) ;11h (big-endian) ;
+ 00Ch 4 Size of Header (including File List) ;11Fh (big-endian) ;
+ 010h .. File List ;/
+ ... .. Padding to 1/4/8-byte boundary (optional, before each file) ;\Data ... .. File Data ;/
+ 000h 4 Offset in bytes (increasing, often 4/8-byte aligned) (big-endian)
+ 004h 4 Size in bytes (can be odd, but often rounded to 4-byte) (big-endian)
+ 008h .. Filename (ASCII, terminated by 00h) ;variable length
+ Note: Filenames can be empty ("",00h) (eg. in WCWDEMO\ZSOUND.BIG)
+http://wiki.xentax.com/index.php/EA_BIG_BIGF_Archive
+Other Electronic Arts file formats (used inside or alongside big archives):
https://wiki.multimedia.cx/index.php/Electronic_Arts_Formats_(2) - BNK etc
+ 000h 2 ID C0FBh (C0h,FBh) (big-endian) ;\
+ 002h 2 Size of Header-4 (00h,15h) (big-endian) ; Header
+ 004h 2 Number of Files (00h,01h) (big-endian) ;
+ 006h .. File List ;/
+ 019h .. Padding to 4-byte boundary? ;-Padding
+ 01Ch .. File Data ;-Data
+ ... 4 "CRCF" ;\
+ ... 4 Unknown (0C,00,00,00) (chunk-size little-endian?) ; Footer
+ ... 4 Unknown (3B,2E,00,00) (checksum maybe?) ;/
+ 000h 3 Offset in bytes (increasing) ;(big-endian, 24bit)
+ 004h 3 Size in bytes ;(big-endian, 24bit)
+ 008h .. Filename (ASCII, terminated by 00h) ;variable length
+ PTH File:
+ 000h N*var File List
+ DAT File:
+ 000h .. File Data area
+ 000h .. Filename ("FILENAME.EXT",00h) (variable length)
+ ... 4 File Size in bytes (can be odd)
+ ... 4 File Offset in bytes in DAT file (increasing, unaligned)
+ TOC:
+ 000h N*var File List
+ IMG:
+ 000h .. File Data area
+ 000h .. Filename ("DATA\FILENAME.EXT",00h) (variable length)
+ ... 4 File Offset (increasing, 800h-byte aligned, in .IMG file)
+ ... 4 File Size in bytes
+ TGA[10h..11h] = 08h,08h ;bpp=8 (okay) and attr=8 (nonsense)
+ TGA[10h..11h] = 10h,01h ;bpp=16 (okay) and attr=1 (okay) but it's yflipped
+ 000h 4 Zero
+ 004h 4 Number of Files (260h)
+ 010h N*8 File entries
+ ... .. Zeropadding to 800h byte boundary
+ ... .. File Data
+ 000h 4 Fileoffset/800h (increasing)
+ 004h 4 Filesize in bytes
+ MDEC v2 STR's (file 1E1h..1F8h,1FAh)
+ TIM textures (file 01FBh..0200h and others)
+ empty files (file 01F9h and others)
+ small archives with named entries (file B5h,124h,125h,126h and others)
+ stuff with date string and names (file 253h,256h)
+ there seem to be no nested BIG files inside of the main BIG file
+ 000h 4 Number of files (N) (eg. 196h)
+ 004h 4 Unknown (always 0Bh) (maybe sector size shift?)
+ 008h N*4 File List
+ ... .. Zeropadding to 800h-byte boudary
+ ... .. File Data
+ 000h 2 Offset/800h (increasing)
+ 002h 2 Size/800h (can be zero)
+ 000h N*4 File List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ File List entries:
+ 000h 1 Size/800h (8bit)
+ 001h 3 Offset/800h (24bit, increasing)
+ 000h N*8 File List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data
+ ... .. Garbage padding (can be several megabytes tall)
+ 000h 2 Offset/800h (increasing)
+ 002h 2 Size/800h (same as below, rounded up to sector units)
+ 004h 4 Size in bytes
+Similar as .CDB archives (but with 32bit offset, and without duplicated size).
+
000h N*8 File List
+ ... 4 File List end marker (00000000h)
+ ... .. Garbage padding to 800h-byte boundary
+ ... .. File Data
+ 000h 4 Offset/800h (increasing)
+ 004h 4 Size in bytes (often zero; for unused file numbers)
+ 000h X*4 File List for BINPACK0.BIN ;\
+ ... .. Zeropadding ; BINPACK0
+ 410h .. Unknown (some/all of it looks like garbage) ;/
+ 800h Y*4 File List for BINPACK1.BIN ;\
+ ... .. Zeropadding ; BINPACK1
+ C10h .. Unknown (some/all of it looks like garbage) ;/
+ 000h 2 Offset/800h in BINPACK0.BIN or BINPACK1.BIN
+ 002h 2 Size/800h
+Resembles .BZE (in terms of duplicated size entry).
+
000h 4 Number of Files
+ 004h 4 Size of File Data area (total filesize-N*0Ch-8)
+ 008h N*0Ch File List
+ ... .. File Data area
+ 000h 4 Offset (zerobased, from begin of File Data area)
+ 004h 4 Size in bytes
+ 008h 4 Size rounded to mutiple of 4-bytes
+ 000h 0Ch ID "@(#)GT-ARC",00h,00h
+ 00Ch 2 Content Type (8001h=Compressed, 0001h=Uncompressed)
+ 00Eh 2 Number of Files (eg. 0Fh)
+ 010h N*0Ch File List
+ ... .. File Data area
+ File List entries:
+ 000h 4 Offset in bytes (increasing, unaligned)
+ 004h 4 Compressed File Size (can be odd) ;\both same when uncompressed
+ 008h 4 Decompressed File Size ;/(ie. when [00Ch]=0001h)
+ 000h 4 Number of Files (N)
+ 004h N*8 File List
+ ... .. File Data area
+ 000h 4 Offset in bytes (increasing, 1/4-byte? aligned)
+ 004h 4 File Size in bytes (usually N*4, TXT's in ODT are padded as so)
+Same as in O.D.T. with extra "DFS_" ID at start of file.
+
000h 4 ID "DFS_" (with align 4) or "DF2_" (with align 800h)
+ 004h 4 Number of Files (N)
+ 008h N*8 File List
+ ... .. File Data area
+ File List entries:
+ 000h 4 Fileoffset in bytes (4-byte or 800h-byte aligned, increasing)
+ 004h 4 Filesize in bytes (can be odd, eg. in BUSTGR_A\SELECT.BPE\*)
+Same as DFS, but with Total Filesize instead of "DFS_".
+
000h 4 Total used filesize (excluding zeropadding to 2EE000h)
+ 004h 4 Number of Files (N)
+ 008h N*8 File List
+ ... .. File Data area
+ ... (..) In some files: Zeropadding to 2EE000h (3072Kbytes)
+ 000h 4 Offset (increasing, 4-byte aligned, see note)
+ 004h 4 Filesize in bytes (can be odd in Monaco)
+ If (Size AND 3)=0 then NextOffset=Offset+Size ;Align4
+ If (Size AND 3)>0 then NextOffset=Offset+Size+Align800h ;Align800h
+ Namely, Monaco has files with Size=3BC5h.
+ Rollcage 1 uses a single IMG file that contains both directory and data:
+ 000h 4 Header offset (0) ;\
+ 004h 4 Header size (10h+N*10h) ; this seems to be a File List entry
+ 008h 4 Header size (10h+N*10h) ; for the header itself
+ 00Ch 4 Zero ;/
+ 010h N*10h File List ;-File List for actual files
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ Number of files is "IMG[04h]/10h" (minus 1 for excluding the header itself)
+ The other titles have seaparate IDX and IMG files for directory and data:
+ SPEED.IDX = Directory (N*10h bytes File List with offsets into SPEED.IMG)
+ SPEED.IMG = File data
+ Number of files is "Filesize(SPEED.IDX)/10h"
+ 000h 4 Fileoffset in bytes (800h-byte aligned, increasing)
+ 004h 4 Filesize in bytes
+ 008h 4 When compressed: GT20 Header [004h] (decompressed size)
+ When uncompressed: Same as filesize
+ 00Ch 4 When compressed: GT20 Header [008h] (overlap, usuallly 3, or 7)
+ When uncompressed: Zero
+ 000h 4 Number of Entries
+ 004h N*0Ch File List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ File List entries:
+ 000h 4 Unknown (random/checksum?)
+ 004h 4 File Offset (800h-byte aligned, increasing)
+ 008h 4 File Size in bytes
+ 000h N*0Ch File List (154h entries)
+ ... N*4 Filename Checksums (?) (154h entries)
+ ... .. Zerofilled (padding to 800h-byte boundary)
+ ... .. File Data area
+ 000h 4 Number of entries (including the 1st entry itself)
+ 004h 4 Offset/800h (always 0, relative from begin of directory)
+ 008h 4 Type (always 3=Directory)
+ 000h 4 For Files: Size in bytes, for Directories: Number of entries
+ 004h 4 Offset/800h (from begin of current directory, increasing)
+ 008h 4 Type (0=File, 3=Directory)
+ 000h 4 File ID (always 01h,02h,04h,08h)
+ 004h 4 Maybe Version? (always 01h,00h,01h,00h)
+ 008h 4 Header Size (18h+N*8+ArchiveNameLength) ;eg. 4ECh
+ 00Ch 4 Sector Alignment (can be 4 or 800h)
+ 010h 4 Number of Files (N) ;eg. 99h
+ 014h 4 Length of Archive Name (including ending 00h)
+ 018h N*8 File entries (see below)
+ ... .. Archive Name, ASCII, terminated by 00h ;eg. "bigfile.dir",00h
+ ... .. Zeropadding to Sector Alignment boundary
+ ... .. File Data
+ 000h 4 Fileoffset (with above Sector Alignment) (increasing)
+ 004h 4 Filesize in bytes
+ nested CAT archives (file 07h,0Ch,11h,16h,1Bh,20h,25h,etc)
+ empty files (file 3Eh,5Ah-5Fh,62h-67h,etc)
+ MDEC v2 STR's (file 95h-96h)
+ XA-ADPCM's (inside of nested CAT, in file94h\file*)
+The DATA directory is 13800h bytes tall. But, the PSX kernel supports max 800h
+bytes per ISO directory (so the kernel can only see the first 33 files in that
+directory). The game isn't actually trying to parse the ISO directory entries,
+instead, it's using the 2800h-byte offset/size list in F0000.BIN to access the
+directory content:
+
0000h+N*4 1 Sector MM in BCD ;\based at 00:06:00 for file 0
+ 0001h+N*4 1 Sector SS in BCD ; (unused files are set to 00:00:00)
+ 0002h+N*4 1 Sector FF in BCD ;/
+ 0003h+N*4 1 Size MSB in hex (Size/800h/100h)
+ 2000h+N 1 Size LSB in hex (Size/800h AND FFh)
+ 2800h (..) Data area for file 001h..590h (demo version only)
+ Sector 000ADh SCUS_944.76 ;exefile ;\
+ Sector 00130h SYSTEM.CNF ; iso root folder
+ Sector 00131h DATA (sub-folder, 27h sectors) ;/
+ Sector 00158h (padding) ;-padding to 00:06:00
+ Sector 001C2h DATA\F0000.BIN ;file 000h ;\
+ Sector 001C7h DATA\F0001.BIN ;file 001h ;
+ ... ; iso data folder
+ Sector 00B54h DATA\F0032.BIN ;file 020h ;
+ Sector 00B9Bh DATA\F0033.BIN ;file 021h ; ;\files exceeding the 800h
+ ... ... ; ; directory size limit, not
+ Sector 1A0C9h DATA\F1907.BIN ;file 773h ;/ ;/accessible via PSX kernel
+ Sector 1AAF1h DUMMY.BIN ;-iso root folder (padding)
+ Sector 07148h HSG2\MINGOL2.BIN ;file 000h..590h ;demo binary files
+ Sector 0AC1Dh HSG2\MINGOL2X.BIN ;file 76Ch ;demo streaming file(s)
+ Sector 0B032h HSG2\SCUS_944.95 ;exefile ;demo exe file
+The demo version uses "Virtual Sectors" in HED+EXE+IMG files. Apart from that,
+the format is same as for the "Hidden Sectors" in retail version:
+CDROM File Archives in Hidden Sectors
These "PAC " files are found in the main archives (which use a separate archive
+format, with ID "DPAC").
+
000h 4 ID ("PAC ") ;\
+ 004h 4 Number of files (N) ; Header
+ 008h N*8 File List ;/
+ ... .. File Data area ;-Data area
+ 000h 2 File ID (inreasing, but may skip numbers, ie. non-linear)
+ 002h 3 File Offset (increasing, relative to begin of Data area)
+ 005h 3 File Size
+ 000h 4 Unknown (1)
+ 004h 4 Filelist Offset (800h)
+ 008h 4 Filelist Size (N*8+4) (7ACh)
+ ... .. Padding to 800h-byte boundary (see note)
+ 800h 4 Number of files (N) (F5h)
+ 804h N*8 File List
+ ... .. Padding to 800h-byte boundary (see note)
+ ... .. File Data area
+ 000h 4 File Offset in bytes (increasing, 800h-byte aligned)
+ 004h 4 File Size in bytes
+ Step 1: Zeropadding to 200h-byte boundary (first 0..1FFh bytes)
+ Step 2: Garbagepadding to 800h-byte boundary (last 0..600h bytes)
+ 000h 2 ID ("BD")
+ 002h 2 Number of files (N)
+ 004h N*8 File List
+ ... .. Zeropadding to 3000h
+ 3000h .. File Data area
+ 000h 4 File Offset/800h (increasing)
+ 004h 4 File Size in bytes
+ 000h 4 ID ("add",00h)
+ 004h 4 Fixed (4)
+ 008h 4 Offset to File List (usually/always 20h)
+ 00Ch 4 Number of Files (N)
+ 010h 4 Fixed (10h)
+ 014h 0Ch Zerofilled
+ 020h N*10h File List
+ ... .. File Data area
+ 000h 4 Offset (increasing, 4-byte aligned) ;\or both zero
+ 004h 4 Size (can be odd) ;/
+ 008h 4 Unknown (0) (or 00h,10h,11h,20h,30h,40h when Offset/Size=0)
+ 00Ch 4 Zero (0)
+ 000h 4 Number of files (N)
+ 004h N*4 File List
+ ... .. Zeropadding to 800h-byte boundary
+ 000h 2 File Offset/800h (increasing)
+ 002h 2 File Size/800h
+ 000h 5*4 File Sizes (can be odd) (can be 0 for 2nd and 5th file)
+ 014h 5*4 File Offsets (28h and up, increasing by sizes rounded to N*10h)
+ 028h .. File Data area (first file usually/always contains "SShd")
+ 0000h 4 ID "siff" ;\Header
+ 0004h 4 Total Filesize (DADB1Ch) ;/
+ 0008h 4 ID "RSRC" ;\
+ 000Ch 4 String Size (70h) ; ASCII string
+ 0010h 70h String "RC ver1.0 Copyright",...,00h ;/
+ 0080h 4 ID "RIDX" ;\
+ 0084h 4 File List Size (1F78h) (3EFh*8) ; Directory
+ 0088h N*8 File List (Offset, Size1) ;/
+ 2000h 4 ID "EXIX" ;\
+ 2004h 4 Extended List Size (FBCh) (3EFh*4) ; Extended
+ 2008h N*4 Extended List (Size2) ;/
+ 2FC4h 4 ID "GAP0" ;\Alignment Padding
+ 2FC8h 4 Padding Size (2Ch) ; (so that next chunk
+ 2FCCh 2Ch Padding (1Ah-filled) ;/starts at boundary-8)
+ 2FF8h 4 ID "RBB0" ;\
+ 2FFCh 4 File Data area Size (DAAB1Ch) ; Data area
+ 3000h .. File Data area ;/
+ 000h 4 File Offset (increasing, 4-byte aligned, from ID "RBB0" plus 8)
+ 004h 4 File Size in bytes (can be odd)
+ 000h 4 File Size in bytes (always the same size as in RIDX chunk)
+ 000h 4 ID "OIFF" ;\Header
+ 004h 4 Total Filesize ;/
+ 008h 4 ID "TIMT" or "ANMT" ;\
+ 00Ch 4 Size (N*4) ; Directory Table
+ 010h N*4 File List (offsets from begin of Data ID+8);/
+ ... 4 ID "TIMD" or "ANMD" ;\
+ ... 4 Data Area size (SIZ) (Filesize-18h-N*4) ; Data area
+ ... SIZ Data Area ;/
+ MEGA.CSH:
+ 000h N*0Ch File List
+ MEGA.BIN:
+ 000h .. File Data area
+ 000h 4 Offset (in MEGA.BIN file, 800h-byte aligned, increasing)
+ 004h 4 Unknown (32bit id/random/checksum/whatever)
+ 008h 4 Filesize in bytes
+ 000h 4 Number of entries (1 or more)
+ 004h N*10h File List
+ ... .. File Data area (.VB aka SPU-ADPCM)
+ File List entries:
+ 000h 4 Offset from begin of Data area, increasing
+ 004h 4 Filesize in bytes
+ 008h 4 Unknown (0 or 1)
+ 00Ch 4 Unknown (AC44h, 0FA0h, 2EE0h, 2710h, 2B11h, 3E80h, 1F40h, etc.)
+ Note: Above AC44h might 44100Hz, or just file number 44100 decimal?
+ 000h 4 ID (always 2A81511Ch)
+ 004h 0Ch Zerofilled
+ 010h 1 Unknown (1)
+ 011h 1 Compression Flag for all files (00h=Uncompressed, 80h=Compressed)
+ 012h 2 Number of files (bit0-13?=N, bit14=Unknown, can be set)
+ 014h N*0Ch File List, 12 bytes/entry ;<-- when [11h]=00h=uncompressed
+ 014h N*10h File List, 16 bytes/entry ;<-- when [11h]=80h=compressed
+ ... .. File Data area
+ 000h 4 File ID (usually 0=first, increasing) (or 0001h,7531h,7532h,...)
+ 004h 4 Offset-10h in bytes (increasing, 4h-byte aligned)
+ 008h 4 Filesize, uncompressed (can be odd)
+ 00Ch (4) Filesize, compressed (can be odd) ;<-- exists only if compressed
+ 000h 4 ID "0FDG XSP" (aka PSX GDF0 backwards)
+ 008h 4 Header Size (N*10h+10h)
+ 00Ch 4 Number of files (N)
+ 010h N*10h File List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ File List entries:
+ 000h 4 ID/Type ("MARV", "MARS", "MARD", "PMET", "COLR", "MROF")
+ 004h 4 ID/Num (usually 1 SHL N, or all zero)
+ 008h 4 Offset (800h-byte aligned, increasing)
+ 00Ch 4 Size in bytes
+ 000h 4 ID "MRG",1Ah
+ 004h 4 Number of Files (eg. 0, 1, 2, 193h, 2E7h, or 1DBBh)
+ 008h N*8 File List
+ ... .. Padding to 800h-byte boundary (8Ch-filled) (not in nested MRG's)
+ ... .. File Data area
+ File List entries:
+ 000h 4 Offset/800h, or 4-byte aligned Offset/1 (increasing)
+ 004h 4 Size (can be odd, and can be zero)
+ Size oddities:
+ Empty files in demo version have Size=0 and Offset=0.
+ Empty files in retail version have Size=0 and Offset=OffsetOfNextFile.
+ MRG archives can start or end with Empty files.
+ All files can be empty (eg. retail DRAGN0.BIN\1190h).
+ NumFiles can be zero (eg. retail DRAGN0.BIN\1111h, demo DRAGN0.BIN\10E2h).
+ Offset oddities:
+ SECT\*.BIN have Offset/800h
+ Nested MRGs have 4-byte aligned Offset/1
+ The two variants can be detected as:
+ if FirstOffset=(NumFiles*8+8) then NestedVariant
+ if FirstOffset=(NumFiles*8+8+7FFh) AND NOT 7FFh then RootVariant
+ Whereas, FirstOffset is the first NONZERO offset in file list (important
+ for demo version, which has archives that start with ZERO offsets).
+This does basically contain four large files (and four info blocks with info on
+the content of those files).
+
000h 4 Random/Checksum?
+ 004h 4 Faded ID (FADED007h)
+ 008h 4 Part 1 Offset (Sound) (always E5Ch)
+ 00Ch 4 Part 2 Offset (Texture) (when Type=01h: Offset-E5Ch)
+ 010h 4 Part 3 Offset (?) (when Type=01h: Offset-E5Ch)
+ 014h 4 Part 4 Offset (?) (when Type=01h: Offset-E5Ch)
+ 018h 4 Type (10h or 20h=Normal) (or 01h=Special in BB\8\*.BBK)
+ 01Ch B0Ch Part 1 Info (Sound) (when Type=01h: garbage-filled)
+ B28h 314h Part 2 Info (Texture)
+ E3Ch 14h Part 3 Info (?)
+ E50h 0Ch Part 4 Info (?)
+ E5Ch .. Part 1 Data (Sound, SPU-ADPCM data, if any)
+ ... .. Part 2 Data (Texture data) (starts with BDEF1222h or BDEF1111h)
+ ... .. Part 3 Data (?) ;\maybe map, models, and/or whatever
+ ... .. Part 4 Data (?) ;/
+ 01Ch 4 Random/Checksum?
+ 020h 4 Faded ID (FADED007h)
+ 024h 4 Part 1 Size (eg.7C7F0h)
+ 028h 4 SPU Start Addr (1010h) (for data from file offset E5Ch)
+ 02Ch 4 SPU Middle Addr (eg. 58F70h)
+ 030h 4 SPU End Addr (eg. 7D800h) (start+size)
+ 034h 2 Middle entry number (often 3Ch)
+ 036h 2 Number of used entries-1 (eg. 50h means that 51h entries are used)
+ 038h AF0h Sample List (100 entries, unused ones are zerofilled)
+ 914h 214h Zerofilled (unused 1Ch-byte entries) (total is 1Ch*64h)
+ Sample List entries:
+ 000h 4 SPU Offset (1010h and up) (SpuOffset=1010h is FileOffset=E5Ch)
+ 004h 4 Sample Size in bytes
+ 008h 4 Unknown (0)
+ 00Ch 4 Unknown (0)
+ 010h 4 Pitch (400h=11025Hz, 800h=22050Hz, 2E7h=8000Hz, 8B5h=24000Hz)
+ 014h 4 Unknown (0 or 1)
+ 018h 4 File ID (00001F08h and up)
+ B28h 4 Random/Checksum?
+ B2Ch 4 Faded ID (FADED007h)
+ B30h 4 Part 2 Size (N*16000h) ;Width=2C0h halfwords, Height=N*64
+ B34h 4 Zero (0h)
+ B38h 4 Some RAM Address (8010xxxxh)
+ B3Ch 4 Unknown (eg. 195h or E3h) ;same as at [DA4h]
+ B40h 4+4 VRAM Address X,Y (140h,0) ;maybe load target
+ B48h 4+4 VRAM Address X,Y (140h,0) ;maybe palette base?
+ B50h 4+4 VRAM Address X,Y (xx0h,Height-40h) ;often at/near end of used area
+ B58h 4 Unknown (eg. 1D0h or 1E0h)
+ B5Ch 4 Unknown (eg. 1Ah or 0Dh)
+ B60h 200h Some halfwords? (most are FFFFh, some are 0000h)
+ D60h 40h Zerofilled (0)
+ DA0h 4 Unknown (eg. 185h or E2h)
+ DA4h 4 Unknown (eg. 195h or E3h) ;same as at [B3Ch]
+ DA8h 9x10h Special Texpages (VramX,Y, SizeX,Y, StepX,Y, Flag/Type/Num or so?)
+ E38h 4 Some RAM Address (800Axxxxh)
+ E3Ch 4 Random/Checksum?
+ E40h 4 Faded ID (FADED007h)
+ E44h 4 Part 3 Size (eg. A9728h or 51264h)
+ E48h 4 RAM End Address (start+size) (eg. 801Fxxxxh) (near memtop)
+ E4Ch 4 RAM Start Address (end-size) (eg. 801xxxxxh)
+ E50h 4 Random/Checksum?
+ E54h 4 Faded ID (FADED007h)
+ E58h 4 Part 4 Size (usually 10CCCh) (or 105E0h in demo version)
+Below are archives that start with a simple Offset list. The DOT1 and DOTLESS
+types are "standard" archives used by many PSX games (although the "standard"
+was probably independently created by different developers).
Used by various titles:
+
R-Types (CG.1, PR\PR.1, and nested inside CG.1)
+ Final Fantasy IX (nested inside FF9.IMG, FF9.IMG\DB, FF9.IMG\DB\DOT1)
+ Legend of Mana (*.EFF,*.SET,*.BTP(?) in folders SND*,SOUND,WM(?))
+ Witch of Salzburg (*.ANM/BIN/BSS/DAT/MDL/SCE)
+ Rayman (RAY\*.XXX, RAY\SND\*.ALL, and nested inside *.XXX)
+ Pandemonium II (JESTERS.PKG\0101\0008 and JESTERS.PKG\0101\000D)
+ Incredible Crisis (MagDemo38: IC\TAN_DAT.CDB\<DOTLESS>\<DOT1>\<SHIFTJIS>)
+ Various games on PlayStation Magazine Demo Discs (Disc 03-54)
+ 000h 4 Number of Files (N) (eg. 2..18)
+ 004h N*4 File List (offsets to each file, increasing, aligned)
+ ... (4) Optional: Total filesize (aka end-offset for last list entry)
+ ... .. Optional: Zeropadding to alignment boundary (when alignment>4)
+ ... .. File Data
+ Align800h, no extra entry R-Types (CG.1 and PR\PR.1)
+ Align4, no extra entry R-Types (nested in CG.1), FF9 (in IMG, IMG\DB)
+ Align2, no extra entry Incredible Crisis (IC\TAN_DAT.CDB\*\*)
+ Align800h, with extra entry MLB 2000 (DATA.WAD)
+ Align10h, with extra entry Witch of Salzburg (*.ANM/BIN/BSS/DAT/MDL/SCE)
+ Align4, with extra entry Rayman (*.XXX, *.ALL)
+FIL/32bit (with [02h]=FFFFh):
+
000h 2 Number of Files (N)
+ 002h 2 ID for 32bit version (FFFFh=32bit entries)
+ 004h N*4 File List (offsets to each file, increasing, 4-byte aligned)
+ ... .. File Data
+ 000h 2 Number of Files (N)
+ 002h N*2 File List (offsets to each file, increasing, 4-byte aligned)
+ ... .. Zeropadding to 4-byte boundary
+ ... .. File Data
+Like DOT1, but with Total Filesize being oddly stored at begin of file.
+
000h 4 Total Filesize (aka end-offset for last list entry)
+ 004h 4 Number of Files (N)
+ 008h N*4 File List (offsets to each file, increasing, 4-byte aligned)
+ ... .. File Data
+Armored Core (MagDemo02, AC10DEMP\*.T)
+
000h 2 Number of Files
+ 002h N*2 File List (Offset/800h to file data, increasing)
+ ... 2 Total Size/800h (end-offset for last file)
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data
+Hot Shots Golf (MagDemo07: HSG\.DAT)
+Hot Shots Golf 2 (retail: DATA\F0000.BIN\, MagDemo31/42: HSG2\MINGOL2.BIN\)
+Starblade Alpha (FLT\.DAT, TEX\.DAT)
+Incredible Crisis (MagDemo38: IC\TAN_DAT.CDB\<DOTLESS>)
+
+Like DOT1, but without Number of Files entry (instead, the first offset does
+imply the end of file list). There's no extra entry for end of last file
+(instead, that's implied in the total filesize). Most files have at least 5
+entries, but HSG\TITLE0.DAT seems to contain only one entry (ie. the whole
+header contains only one value, 00000004h, followed by something that looks
+like raw bitmap data). 000h N*4 Offsets to File data (increasing, usually 4-byte aligned)
+ ... (4) Filesize (end-offset for last file) (only in Ape Escape)
+ ... ... File Data
+
+Also used by Ape Escape (MINIGAME\ included nested ones), the Ape Escape files
+do have an end-marker with last-offset (that will appear as an empty 0-byte
+file at end of list when not specifically handling it).
+MINIGAME\MINI2\BXTIM.BIN does also have several 0-byte files inside of the file
+list.
000h 4 Size of Data Area (total filesize minus 0D0h)
+ 004h 4 Number of files
+ 008h N*4 File List (zerobased offsets from begin of Data Area)
+ ... .. Zeropadding to 0D0h
+ 0D0h .. File Data Area
+Basically, this is alike DOT1, but SECTOR numbers, and with extra entries...
+
000h 4 Number of Files (N) (3C9h)
+ 004h N*4 File List (Offset/800h)
+ ... 4 Total Size/800h ;<-- last offset
+ ... 4 Unknown (00,E8,82,2E) ;<-- ??? maybe chksum*800h or so?
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ 000h 4 Zero
+ 004h 4 Number of Entries (4D3h)
+ 008h N*4 File List (Offset/800h)
+ ... 4 Total Size/800h (aka end Offset/800h of last file)
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ #define init_data 0 ;for file 0000h
+ #define gameover_data 1 ;for file 0001h
+ #define town01 3 ;for file 0003h
+ #define town0b 12 ;for file 000Ch
+ ... ;...
+ #define other6 1222 ;for file 04C6h
+ #define other7 1228 ;for file 04CCh
+ 000h 4 Number of Entries (N)
+ 004h N*4 File List (Offset-(4+N*4), increasing) (or FFFFFFFFh=Unused entry)
+ ... .. File Data area
+ 000h 4 ID "OA05"
+ 004h N*4 Offset List (usually/always 5 used entries, plus zeropadding)
+ 030h .. File Data area (usually/always starting at offset 30h)
+ 000h 4 ID "SEGG"
+ 004h 4 Offset to .VH file
+ 008h 4 Offset to .VB file
+ 00Ch 4 Number of .SEQ files (N) (usually 6Eh, or 08h in MENU.SGG)
+ 010h N*4 Offsets to .SEQ files (increasing, unaligned)
+ ... .. SEQ files
+ ... .. Padding to 4-byte boundary
+ ... .. VH file
+ ... .. VB file
+ 000h 8 ID "VRAM-WAD" (here as archive ID, although same as compress ID)
+ 004h N*4 File List (offsets to Data) ;NumFiles=(FirstOffset-8)/4
+ ... .. Data (compressed .PAK files, which do ALSO have ID="VRAM-WAD")
+ 000h 4 Unknown (3)
+ 004h 4 Total Size
+ 008h 4 Number of Files (N) (max 40h, for max 40h*4 bytes in file list)
+ 00Ch N*4 File List (increasing offsets, 800h-byte aligned)
+ ... .. Unknown (looks like garbage padding for unused File List entries)
+ 10Ch 6F4h 42h-filled padding to 800h-byte boundary
+ 800h .. File Data area
+ 000h 8 Fixed (88h,0,0,0,0,0,0,0)
+ 008h 4 Number of Files (eg. 1Dh or 585h, including last/end file)
+ 00Ch N*4 File List (increasing offsets, 800h-byte aligned)
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ 000h 4 Total Filesize (3E800h in Spyro)
+ 004h N*8 File List (1B0h bytes in Spyro)
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data (4-byte aligned, despite of above 800h-byte hdr padding)
+ 000h 4 Fileoffset (increasing, 4-byte aligned)
+ 004h 4 File ID? (unsorted, not increasing, used range is 000h..1FAh)
+ 000h 4 Zero (0)
+ 004h 4 Type/ID (27100h=160000, 2BF20h=180000, 30D40h=200000 decimal)
+ 008h 4 Number of files
+ 00Ch N*0Ch File List
+ ... .. Zeropadding to 7FCh
+ 7FCh 4 Checksum (32bit sum of SIGN-EXPANDED bytes at [000h..7FBh])
+ ... .. File Data
+ 000h 4 File Type/ID or so (roughly increasing, eg. 1,3,6,5,7,8,9,A,B)
+ 004h 4 Filesize in bytes
+ 008h 4 Filesize rounded up to multiple of 800h bytes
+Resembles .BZE, but without the Type entry in Header.
+
000h 4 Fixed 1 (maybe version, or compression flag)
+ 004h (4) Unknown (000xxxx0h) ;<-- Extra in The Grinch only (not Bunny)
+ ... 4 Number of files
+ ... N*0Ch File List
+ ... .. Zeropadding to 7FCh
+ 7FCh 4 Checksum (32bit sum of SIGN-EXPANDED bytes at [000h..7FBh])
+ ... .. File Data
+ 000h 4 File Type/ID or so (roughly increasing, eg. 1,2,3,6,5,7,8,9,A)
+ 004h 4 Filesize in bytes (rounded to N*4 even if compressed data is less)
+ 008h 4 Filesize rounded up to multiple of 800h bytes
+Resembles .BZE, but without the Type entries in Header and File List, and
+without Header checksum.
+
000h 4 Fixed 1 (maybe version, or compression flag)
+ 004h 4 Number of files (4)
+ 008h N*8 File List
+ ... .. Zeropadding to 800h-byte boundary (without checksum, unlike .BZE)
+ ... .. File Data
+ 000h 4 Size in bytes
+ 004h 4 Size rounded to multiple of 800h
+ 000h 2 ID ("PX")
+ 002h 2 Unknown (1 or 3)
+ 004h 4 Header Size (eg. 80h, 7C0h, or 1730h) (N*8+8)
+ 008h N*8 File List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data area
+ File List entries:
+ 000h 4 Offset (increasing, 800h-byte aligned)
+ 004h 1 Zero
+ 005h 3 Filesize in bytes (24bit) (can be odd)
+ XXX detect this WITH extension=".RC" check before OBJ
+ (else type=1 could be mistaken as offs=1) (eg RC1\BP0*.RC)
+ 000h N*8 File List
+ ... 8 File List end (zerofilled)
+ ... .. Garbage padding to 800h-byte boundary
+ 000h 4 Filetype (see below)
+ 004h 4 Filesize in bytes
+ 00h = End of File List (at least so when Type and Size are both zero)
+ 01h = .TIM
+ 02h = Unknown
+ 03h = Unknown
+ 05h = .VH
+ 06h = .VB
+ 09h = Unknown
+ 0Ah = .TIM (left half of a larger image) (right half has type 01h)
+ 0Bh = Unknown
+ 0Ch = Unknown
+This format is used by the NEW demo version on MagDemp48 (the OLD demo version
+on MagDemo39 did use Spider-Man-style HED/WAD format with filenames).
+
HED:
+ 000h 2 Number of entries (N)
+ 002h N*6 File List
+ WAD:
+ 000h ... File data (at 800h-byte aligned locations)
+ 000h 3 File ID (24bit)
+ 003h 3 File Size in bytes (21bit, max 2Mbyte) (upper 3bit=unused?)
+ 000h 4 Header Size (N*SectorSize) (xxh, 800h, 1000h, 4800h, or 920h)
+ 004h 4 Sector Size (4=ChildArchive, 800h=MainArchive, 920h=FMV/MADN00)
+ 008h 4 File List entrysize (0=32bit, 1=16bit/MADN00, 4=16bit/MADN01)
+ 00Ch N*2/4 File List (16bit or 32bit filesizes in bytes)
+ ... .. Zeropadding to SectorSize boundary
+ ... .. Files (with above sizes, each zeropadded to SectorSize boundary)
+ 000h 4 Total Filesize-4
+ 004h N*14h File List (2 entries in Croc2, 3 entries in Aladdin/Emperor)
+ ... .. File Data area (SPU-ADPCM( (.VB files with leading zeroes)
+ File List entries: (Aladdin/Emperor) (Croc2)
+ 000h 4 Sample Rate in Hertz (AC44h=44100Hz) (5622h=22050Hz)
+ 004h 2 Sample Rate Pitch (1000h=44100Hz) (0800h=22050Hz)
+ 006h 2 Unknown (7Fh) (32h)
+ 008h 4 Unknown (1) (8)
+ 00Ch 4 Unknown (1FC0001Fh) (40008Fh)
+ 010h 4 Filesize (xxx0h) (xxx0h)
+ 000h 800h File List (with 10h or 20h bytes per entry)
+ 800h .. File Data (each file is zeropadded to 800h-byte boundary)
+ Dino Crisis 1 --> always size 10h
+ Dino Crisis 2 --> usually size 20h
+ Dino Crisis 2 --> sometimes size 10h (eg. SC24.DAT, SC48.DAT, WEP_*.DAT)
+ File List entries, type 0 and 7:
+ 000h 4 Type (0=Data (or .BS pictures), 7=CompressedData)
+ 004h 4 Size
+ 008h 4 RAM Addresss (80000000h..801FFFFFh)
+ 00Ch 4 Zero
+ 010h (10h) Zerofilled
+ File List entries, type 1 and 2 and 8:
+ 000h 4 Type (1=Bitmap, 2=Palette, 8=CompressedBitmap)
+ 004h 4 Size (see below Size Notes)
+ 008h 2 VRAM Address X (0..3FFh)
+ 00Ah 2 VRAM Address Y (0..1FFh) (or 280h in Dino 2 ST703.DAT)
+ 00Ch 2 Width in halfwords (1..400h)
+ 00Eh 2 Height (1..200h)
+ 010h (10h) Zerofilled
+ File List entries, type 3 and 4:
+ 000h 4 Type (3=VoiceHeader("Gian"), 4=VoiceData(SPU-ADPCM))
+ 004h 4 Size
+ 008h 4 SPU Address (0..7FFF0h)
+ 00Ch 2 Unknown (0..7) ;\usually both same (or val1=0, val2>0)
+ 00Eh 2 Unknown (0..7) ;/
+ 010h (10h) Zerofilled
+ File List entries, type 5 (eg. ME*.DAT):
+ 000h 4 Type (5=Unknown... maybe Midi-style or so)
+ 004h 4 Size
+ 008h 4 Load Address (0, or on next 4-byte boundary after previous file)
+ 00Ch 2 Unknown (0..2) ;\always both same
+ 00Eh 2 Unknown (0..2) ;/
+ 010h (10h) Zerofilled
+ File List entries, type 6 and 9:
+ The EXE code does also accept type 6 and 9 (type 6 is handled same as
+ type 0, and type 9 is ignored), but the actual archives don't seem to
+ contain any files with those types.
+ File List entries, padding for unused entries:
+ 000h 10h Type ("dummy header ")
+ 010h (10h) Zerofilled
+ Bitmaps and Palettes can have following sizes:
+ Width*Height*2 ;normal case
+ Width*Height*2 + Align(1000h) ;eg. Dino Crisis 1 DOOR*.DAT
+ Width*Height*2 + Align(800h) ;eg. Dino Crisis 2 DOOR27.DAT
+ CompressedBitmaps can have following sizes in compressed form:
+ Less than Width*Height*2 ;normal case
+ Less than Width*Height*2 + 1000h ;eg. Dino Crisis 2 M_RESULT,ST002.DAT
+ CompressedBitmaps can have following sizes after decompression:
+ Width*Height*2 + 8 ;normal case
+ Width*Height*2 + Align(1000h?) + 8 ;eg. Dino Crisis 2 M_RESULT,ST002.DAT
+Chunk-based archives have chunk headers for each file, but don't have a central
+directory. That's mainly useful when loading the whole archive to memory.
IFF has been invented by Electronic Arts in 1985 on Amiga (hence using 2-byte
+alignment and big-endian size values).
+IFF does mainly define a standarized file structure for use with custom
+group/chunk types (it does also define some Amiga-specific standard audio/video
+types, but those are barely useful on PSX).
+The files are starting with a Group Header, followed by Chunks:
+
Group Header:
+ 000h 4 Group ID ("FORM") (or "LIST" or "CAT " or "PROP")
+ 004h 4 Group Size-08h (SIZ) (filesize-8) (big-endian)
+ 008h 4 Group Type (4-character ASCII) (should be an unique identifier)
+ 00Ch SIZ-4 Chunk(s), and/or nested Group(s)
+ Chunk Format:
+ 000h 4 Chunk Type (4-character ASCII) (meaning depends on Group Type)
+ 004h 4 Chunk Size (SIZ) (big-endian)
+ 00Ch SIZ Data (eg. .TIM, .VB, .VH or custom data)
+ ... .. Zeropadding to 2-byte boundary
+Unlike real IFF, these are using little-endian, and don't have a Group Type
+entry. There seem to be no nested FORMs. Alignment is kept as 2-byte.
+
Group Header:
+ 000h 4 Group ID ("FORM" or "BODY")
+ 004h 4 Group Size-08h (SIZ) (little-endian)
+ 008h SIZ Chunk(s)
+ Chunk Format:
+ 000h 4 Chunk Type (4-character ASCII)
+ 004h 4 Chunk Size (SIZ) (little-endian)
+ 00Ch SIZ Data
+ ... .. Zeropadding to 2-byte boundary
+Same as Z-Axis IFF variant, except Group IDs are different, and the Header
+sizes are included in the Group/Chunk sizes.
+
Group Header:
+ 000h 4 Group ID ("hTIX","hFNT","hMBD","hHBS")
+ 004h 4 Group Size (total filesize) (little-endian)
+ ... (8) Unknown extra (0,0,0,0,0Ch,0,0,0) ;<-- only in "hHBS" files
+ ... .. Chunk(s)
+ Chunk Format:
+ 000h 4 Chunk Type ("cCLT","cBIT","cSTR","cMAP","cIDX","cVAB","cSEQ")
+ 004h 4 Chunk Size (SIZ) (little-endian)
+ 00Ch SIZ-8 Data
+ ... .. Maybe Zeropadding to boundary? (Chunk Size is always N*4 anyways)
+Contains several simple chunks:
+
000h 4 Chunksize in bytes (SIZ) (usually a multiple of 4)
+ 004h SIZ Chunkdata (eg. .TIM file or other stuff)
+Contains several simple chunks with filenames:
+
000h 0Ch Chunk Filename ("filename.ext", zeropadded if shorter)
+ 00Ch 4 Chunk Data Size in bytes (SIZ)
+ 010h SIZ Chunk Data (usually VAGp files, in VAG.WAD)
+Contains .BS files in several chunks:
+
000h .. Chunk(s) (.BS files with extra header info)
+ ... 4 End Marker (00000000h)
+ Chunk format:
+ 000h 4 Chunk size (including whole chunk header)
+ 004h 2 Bitmap Width (eg. F0h)
+ 006h 2 Bitmap Height (eg. 80h)
+ 008h 2 Data Size/4 (same as (Chunksize-0Ch-filenamelen)/4)
+ 00Ah 2 MDEC Size/4 (same as at Data[0])
+ 00Ch .. Filename (eg. "lsFact",00h or "bsRooftop1",00h) ;\filename field
+ ... .. Filename Zeropadding to 4-byte boundary ;/
+ ... .. Data (in BS v2 format) (MDEC Size/4, BS ID 3800h, etc.)
+ 000h 4 ID (100h)
+ 004h .. Chunk(s)
+ ... 4 Zero (Chunk Size=0=End)
+ ... .. Optional zeropadding to 800h-byte boundary (in R4.BIN\*)
+ 000h 4 Chunk Size (SIZ)
+ 004h SIZ Chunk Data (TIM file) (note: includes 0x0pix TIMs with palette)
+Contains a fileheader and .TIM files in several chunks:
+
000h 8 ID "TXSPC",0,0,0 (aka CPSXT backwards)
+ 008h 4 Timestamp? (32A5C8xxh)
+ 00Ch 4 Number of Chunks (N) (can be 0=None, eg. TM2\SCREEN\ARROWS.TMS)
+ 010h N*4 Unknown
+ ... N*var Chunks
+ Chunk format:
+ 000h 4 Chunk Size-4 (SIZ)
+ 004h SIZ Chunk Data (TIM file)
+The BDY\*.BD files do simply contain several chunks:
+
000h .. Chunk(s)
+ 000h .. Chunk(s) for 1st folder ;\Foldersizes are:
+ ... .. Zeropadding to Foldersize-boundary ; 20000h (PM.DT0 and PM.PCC)
+ ... .. Chunk(s) for 2nd folder ; 28000h (PM.MAP)
+ ... .. Zeropadding to Foldersize-boundary ; 42000h (PM.SD0)
+ ... .. etc. ;/
+ 000h 4 Chunk ID (800000xxh)
+ 004h 4 Chunk Size (size of Data part, excluding ID+Size)
+ 008h .. Data
+ 80000004h x(2),y(2),width(2),height(2) Bitmap 8bpp ;PM.PCC,MAP
+ 80000005h w(2),h(2),zero(4) Array32bit(w,h) ;PM.MAP
+ 80000006h x(2),width(2) Bitmap Palette ;PM.*
+ 80000007h x(2),y(2),w(1),h(1),zero(2) Array8bit(w,h) ;PM.MAP
+ 80000010h width(2),height(2),x(2),y(2) Bitmap 16bpp ;*.BD
+ 80000012h zero(0) ? ;*.BD
+ 80000014h x(2),y(2),width(2),height(2) Bitmap 4bpp ;PM.DT0
+ 80000016h x(2),y(2),w(1),h(1),n(1),3Fh(1) BitmapArray4bpp(n*2) ;PM.DT0
+ 80000018h ... ? ;PM.PCC
+ 8000001Ah zero(8) ? ;PM.PCC
+ 8000001Ch x(2),y(2),width(2),height(2) Bitmap 1bpp flags? ;*.BD
+ 80000020h zero(8) Sound .SEQ file ;PM.SD0
+ 80000021h zero(8) Sound .VH file ;PM.SD0
+ 80000022h zero(8) Sound .VB file ;PM.SD0
+ 80000024h x(2),zero(6) ? ;PM.DT0\4\0
+ 00000000h Zeropadding to next folder Zeropadding ;PM.*
+ 000h .. Chunks
+ 000h 1 Chunk Type (see below)
+ 001h 3 Unknown (some flags or file ID, or zero in many files)
+ 004h 4 Chunk Size (SIZ)
+ 008h SIZ Chunk Data (eg. SEQ file)
+ 02h unknown ST*.BIN
+ 05h .TXT ROLL.BIN
+ 05h LZ-compressed TIM DEMODATA.BIN, ST*.BIN (except ST1*.BIN)
+ 06h DOT1 with stuff and TSQ?? ST*.BIN
+ 07h .TMD DEMODATA.BIN, ST*.BIN (except ST1*.BIN)
+ 08h unknown ST*.BIN
+ 09h "PRM:" ST*.BIN
+ 0Ah unknown ST*.BIN
+ 0Bh DOT1 with stuff ST*.BIN (except ST1*.BIN) (odd: ST3*.BIN)
+ 0Ch .SEQ ROLL.BIN, ST*.BIN
+ 0Dh unknown COMDATA.BIN
+ 0Eh unknown ST*.BIN
+ 0Fh DOT1 with LZ-compressed TIMs ST*.BIN
+ 10h DEFLATE-compressed TIM COMDATA.BIN, ROLL.BIN, ST*.BIN
+ 11h DOT1 with stuff ST*.BIN
+ Note: Type=05h can be uncompressed TXT or compressed TIM.
+ 07 00 00 00 xx xx 00 00 41 00 00 00 .. TMD Model ("A")
+ 0C 00 00 00 xx xx 00 00 70 51 45 53 .. SEQ Midi ("pQES")
+ 0E xx 00 00 08 00 00 00 xx xx xx xx .. Whatever in ST7DATA.BIN (see note)
+ 10 01 00 00 24 28 00 00 EC 9B 7F 70 .. Deflated TIM in COMDATA.BIN
+ 10 08 1A 00 30 0C 00 00 ED 58 4F 88 .. Deflated TIM in ROLL.BIN
+ ST7DATA.BIN has 2 chunks with Type=0Eh, followed by SEQ chunk at offset=20h.
+DATA\GRP.IDX, DATA\MAP.IDX, DATA\SEQ.IDX DATA\VAB.IDX:
+
000h N*2 Chunk List (16bit Offset/800h to Part-1-Chunks in .DAT files)
+ ... .. Zeropadding to 800h-byte boundary
+ Notes:
+ The Chunk List can contain zeroes (as first entry at offset 0, and as
+ unused entries; in VAB.IDX those can be followed by further USED entries).
+ For 2-part DAT files, the Chunk List contains offsets for Part 1 only.
+ 000h 4 Chunksize/800h ;\
+ 004h 4 Datasize in bytes ; Single
+ 008h 4 Always 015A5A01h or 015A5A00h ; Part
+ 00Ch 4 Always 2803h ; with
+ 010h .. Midi data .SEQ file ; 1 file
+ ... .. Zeropadding to 800h-byte boundary ;/
+ 000h 4 Chunksize/800h ;\
+ 004h 4 Size of .VH Voice Header in bytes ; Single
+ 008h 4 Size of .VB Voice Binary in bytes ; Part
+ 00Ch .. Voice Header .VH file ; with
+ ... .. Zeropadding to 800h-byte boundary ; 2 files
+ ... .. Voice Binary .VB file ;
+ ... .. Zeropadding to 800h-byte boundary ;/
+ 000h 4 Part 1 Chunksize/800h ;\
+ 004h 4 Size of all TIM files in bytes (can be 0=None) ; Part 1
+ 008h .. Texture data (several TIMs appended after each other) ;
+ ... .. Zeropadding to 800h-byte boundary ;/
+ ... 4 Number of Files (N) ;\
+ ... 4 Part 2 Chunksize/800h ;
+ ... N*8 File List ; Part 2
+ ... .. Garbage-padding to 800h-byte boundary? ;
+ ... .. File Data area (each file Garbage-padded to 800h-byte) ;
+ File List entries: ;
+ 000h 4 File Type/ID ;
+ 004h 4 Size in bytes ;/
+CDROM File Archive Darkworks Chunks (Alone in the Dark)
+CDROM File Archive Blue Chunks (Blue's Clues)
+CDROM File Archive HED/CDF (Parasite Eve 2)
+CDROM File Compression LZSS (Serial Experiments Lain)
+CDROM File Compression SLZ/01Z (chunk-based compressed archive)
There are several ways to implement folder-like directory trees:
+
- Using multiple archive files nested within each other
+ - Using filenames with path string (eg. "path\filename.ext")
+CDROM File Archive HUG/IDX/BIZ (Power Spike)
+CDROM File Archive TOC/DAT/LAY
+CDROM File Archive WAD (Doom)
+CDROM File Archive WAD (Cardinal Syn/Fear Effect)
+CDROM File Archive DIR/DAT (One/Viewpoint)
+CDROM File Archive HED/CDF (Parasite Eve 2)
+CDROM File Archive IND/WAD (MTV Music Generator)
+CDROM File Archive GAME.RSC (Colonly Wars Red Sun)
+CDROM File Archive BIGFILE.DAT (Soul Reaver)
+CDROM File Archive FF8 IMG (Final Fantasy VIII)
+CDROM File Archive FF9 IMG (Final Fantasy IX)
+CDROM File Archive GTFS (Gran Turismo 2)
+CDROM File Archive Nightmare Project: Yakata
+CDROM File Archive FAdj0500 (Klonoa)
+See also: PKG (a WAD.WAD variant with folders)
Overall File Structure
+ JFS for root ;\
+ JFS for 1st folder ;\these are dupicated, ; header with complete list
+ JFS for 2nd folder ; also stored in below ; of all file/folder names
+ JFS for 3rd folder ; data area ;
+ etc. ;/ ;/
+ JFS for 1st folder, plus data for files in that folder ;\
+ JFS for 2nd folder, plus data for files in that folder ; data area
+ JFS for 3rd folder, plus data for files in that folder ;
+ etc. ;/
+ 00h 4 ID "JFS",00h
+ 04h 4 Size in bytes (for root: including nearby child JFS's)
+ 08h 4 Number of file/folder entries in this folder (N)
+ 0Ch N*14h File/Folder entries
+ 00h 12 "FILENAME.EXT" (or zeropadded if shorter)
+ 0Ch 4 Offset from begin of JFS in data area (without any alignment)
+ 10h 4 Size in bytes, plus 00000000h=File
+ 00h 12 "DIRNAME.EXT" (or zeropadded if shorter)
+ 0Ch 4 Offset to child JFS in data area
+ 10h 4 Offset to child JFS in header area, plus 80000000h=ChildFolder
+ FAT.BIN:
+ 00h 2 Number of folders (X) (43h)
+ 02h 2 Number of files (Y) (8F0h)
+ 04h 4 Unknown (1000h)
+ 08h X*10h Directory Entry 0000h..X-1 (entry 0000h is named "ROOT")
+ .. Y*10h File Entry 0000h..Y-1
+ DATA.BIN:
+ 00h .. File Data area
+ 00h 8 Name (terminated by 00h if less than 8 chars)
+ 08h 2 First Subdirectory number (0001h and up, 0000h would be root)
+ 0Ah 2 Number of Subdirectories (0000h=None, if so above is usually 00FFh)
+ 0Ch 2 First File number (0000h and up)
+ 0Eh 2 Number of files (0000h=None, if so above is usually 00FFh)
+ 00h 8 Name (terminated by 00h if less than 8 chars)
+ 08h 4 Offset/800h to DATA.BIN
+ 0Ch 4 Size in bytes (when compressed: decompressed size+02000000h)
+ HOG.TOC:
+ 000h N*14h Folder/File List (starting with root folder)
+ HOG.DAT:
+ 000h .. File Data (referenced from HOG.TOC)
+ 000h 1 Type ("D"=Directory)
+ 001h 8 Name ("FILENAME", zeropadded if shorter) (or "\" for root)
+ 009h 3 Extension (usually zero for directories)
+ 00Ch 4 Folder Offset/14h in .TOC file (aka 1st child file/folder index)
+ 010h 4 Folder Size/14h (aka number of child files/folders)
+ 000h 1 Type ("F"=File)
+ 001h 8 Name ("FILENAME", zeropadded if shorter)
+ 009h 3 Extension ("EXT", zeropadded if shorter)
+ 00Ch 4 File Offset/800h in .DAT file (increasing)
+ 010h 4 File Size in bytes
+ 000h 4 Unknown (demo=A0409901h, us/retail=A0617023h)
+ 004h 4 Unknown (0h)
+ 008h 4 Number of files (F) (demo=B7h, us/retail=1294h)
+ 00Ch 4 Number of folders (D) (demo=0Fh, us/retail=3Eh)
+ 010h D*8 Folder List
+ ... .. Zerofilled (padding to 800h-byte boundary)
+ 800h F*10h File List
+ ... .. Zerofilled (padding to 800h-byte boundary)
+ ... .. File Data area
+ 000h 4 Folder ID (Random, maybe folder name checksum?)
+ 004h 4 First file number in this folder (0=first, increasing)
+ 000h 4 File Offset/800h
+ 004h 4 File Size in bytes
+ 008h 4 Folder ID (same as Parent Folder ID in Folder List)
+ 00Ch 4 File ID (Random, maybe file name checksum?)
+ LFS:
+ 000h N*18h File/Folder List
+ DAT:
+ 000h .. File data
+ 000h 10h Filename ("FILENAME.EXT", zeropadded)
+ 010h 4 Offset in bytes, in BLASTO.DAT
+ 014h 4 Size in bytes
+ 000h 10h Foldername ("DIRNAME", zeropadded)
+ 010h 4 Index to first child (at Offset=(-Index)*18h in BLASTO.LFS)
+ 014h 4 Zero
+ 000h 1 End marker, at end of root & child directories (00h or 80h)
+ 001h 17h Unknown
+These are relative small archives with hundreds of tiny chunks (with registry
+style Symbol=Value assignments), and a few bigger chunks (with .mod .vab .bit
+.clt files).
+
000h 4 Fixed ID (CCCC0067h)
+ 004h .. Root Folder (with Name="Root",00h,FDh,FDh,FDh)
+ Folder Chunk format:
+ 000h 1 Length of Name (including 4-byte padding)
+ 001h 1 Number of Child Folders
+ 002h 2 Number of Child Files
+ 004h .. Name ("name",00h, CDh-padded to 4-byte boundary; Root=FDh-padded)
+ ... .. Child File(s)
+ ... .. Child Folder(s)
+ File Chunk format:
+ 000h 1 Length of filename (including 4-byte padding)
+ 001h 1 Filetype (see below)
+ 002h 2 Array Size (or FFFFh for non-array filetypes)
+ 004h 4 Filesize (SIZ) (including 4-byte padding)
+ 008h 4 Decompressed Size (or 0=Uncompressed)
+ 00Ch .. Filename/Symbol ("name.ext",00h, CDh-padded to 4-byte boundary)
+ ... SIZ Data/Value (CDh-padded to 4-byte boundary)
+ "AXEL.MR\display\resolution\r3\Groups\Combined_Polyset",1Ah,01h,04h,00h
+ "CALYPSO.MR\display\resolution\r3\Groups\Combined_Polyset",A8h,00h, CDh,CDh
+ Typ Size Expl.
+ 02h var Text String (terminated by 00h, garbage-or-00h-padded to 4-byte)
+ 03h 8 Misc (*.IMG\textures\*) ;\
+ 03h 20h Misc (*.MR\display\resolution\r*\Groups\*) ; these are all
+ 03h var Misc (*.MR\display\resolution\*List) ; filetype=03h
+ 03h file Misc (*.MR\display\*.bit) (same as type=0Ch) ;/
+ 04h 4 Numeric 32bit
+ 05h 8 Numeric 4x16bit point (X,Y,Z,CDCDh)
+ 06h file Model (*.mod) (DOTLESS archive with model data)
+ 0Bh 4 Numeric 32bit repeat,light
+ 0Ch file XYWH Bitmap/Palette (*.bit, *.clt) (in GAME.IMG, MENU\menu)
+ 0Dh 4 Numeric 32bit delay
+ 0Eh 4 Numeric 32bit color (maybe 24bit RGB plus 00h-padding?)
+ 0Fh 10h Whatever 10h-byte "pos"
+ 10h file Sony .VAB file (*.vab)
+ 12h N*1 Array? (with Arraysize=0014h)
+ 16h N*?? Array Text Strings (with Arraysize=0001h) (in MAIN.MR\worlds)
+ 1Ah N*10h Array Guns,startpoints (RCCAR.MR\*, NEON.MR\world)
+ 1Bh 4 Numeric 2x16bit (X,Y) (in MENU.MR)
+ 1Ch N*4 Array lloc (in MENU.MR\menu\screens) (with Arraysize=04h or 1Fh)
+ 25h 8 Whatever 8-byte (in GAME.MR\dualShock)
+ 26h N*8 Array CollideArray (in GAME.MR\dualShock) (with Arraysize=4 or 6)
+ 000h .. ZLIB compressed data (usually starting with big-endian 789Ch)
+ (compression is used for almost all files, except VERY small ones)
+POWER\GAME.HUG
+
000h .. File Data
+ 000h 4 ID "HUGE"
+ 004h 4 Checksum (sum of all bytes at [010h and up])
+ 008h 4 Number of Folders (D) (87h)
+ 00Ch 4 Number of Files (F) (F9h)
+ 010h D*1Ch Folder List (Folder 0..D-1)
+ ... F*18h File List (File 0..F-1)
+ 000h 0Ch Folder Name ("DIRNAME", zeropadded)
+ 00Ch 4 First Child File (or FFFFFFFFh=None)
+ 010h 4 Number of Child Files (or 00000000h=None)
+ 014h 4 First Child Folder (or FFFFFFFFh=None)
+ 018h 4 Next Sibling Folder (or FFFFFFFFh=None)
+ 000h 0Ch File Name ("FILENAME.EXT", zeropadded if shorter than 12)
+ 00Ch 4 File Checksum (sum of all bytes in file added together)
+ 010h 4 File Offset/800h in GAME.HUG
+ 014h 4 File Size in bytes
+ 000h 4 ID "BIG!"
+ 004h 4 Number of entries (N)
+ 008h N*1Ch File List
+ ... .. BIZ compressed File Data
+ 000h 10h Filename (zeropadded)
+ 010h 4 File Offset (increasing, unaligned, can be odd)
+ 014h 4 File Size decompressed
+ 018h 4 File Size compressed
+Used in PSX Lightspan Online Connection CD (CD.TOC, CD.DAT, CD.LAY).
+
CD.TOC contains File/Folder entries
+ CD.DAT contains the actual File bodies
+ CD.LAY devkit leftover (list of filenames to be imported from PC to TOC/DAT)
+ 00h 4 Offset to next Sibling File/Folder/Final entry
+ 04h 4 Filesize in bytes
+ 08h 4 Filedata Offset/800h in CD.DAT
+ 0Ch .. Filename (ASCII, terminated by 00h)
+ ... .. Padding to 4-byte boundary (garbage)
+ 00h 4 Offset to next Sibling File/Folder/Final entry
+ 04h 4 Filesize (always FFFFFFFFh in Folder entries)
+ 08h 4 Offset to first File/Folder in Child directory
+ 0Ch .. Name of Child directory (ASCII, terminated by 00h)
+ ... .. Padding to 4-byte boundary (garbage)
+ 00h 4 Offset to next Sibling entry (00000000h=None)
+ 04h 4 Filesize (FFFFFFFFh in child folders, FFFFFFFEh in root folder)
+ 08h 4 Offset to first File/Folder in Parent directory (or to self for root)
+ 0Ch 1 Empty Name ("",00h)
+ 0Dh 3 Padding to 4-byte boundary (garbage)
+The .WAD format is used by Doom (for DOS, Jaguar, PSX, etc), various homebrew
+Doom hacks, and some other developers have adopted the format and used .WAD in
+other game engines.
+
000h 4 ID "IWAD" (or "PWAD" for homebrew patches, or "PACK" in A.D. Cop)
+ 004h 4 Number of File List entries (N) (including final ENDOFWAD entry)
+ 008h 4 Offset to Directory Area (filesize-N*10h)
+ 00Ch .. File Data area
+ ... N*10h File List
+ 000h 4 Offset to file data (increasing by compressed size, 4-byte aligned)
+ 004h 4 Filesize in bytes (uncompressed size) (zero in ENDOFWAD file)
+ 008h 8 Filename (uppercase ASCII, zeropadded if less than 8 chars)
+The directory can contain names like F_START, F_END, P1_START, P1_END with
+filesize=0 to mark begin/end of something; that stuff can be considered as
+subdirectories with 1- or 2-character names.
+Notes: There are also regular files with underscores which are unrelated to
+folders (eg. F_SKY01). There are also 0-byte dummy files (eg. MAP17 in first
+entry MAP17.WAD). And there's a 0-byte dummy file with name ENDOFWAD in last
+file list entry (at least, it's present versions with compression support).
Compression is indicated by Filename[0].bit7=1. The compressed size is
+NextFileOffset-FileOffset (that requires increasing offsets in File List,
+including valid offsets for 0-byte files like F_START, F_END, ENDOFWAD).
+
@@collect_more:
+ flagbits=[src]+100h, src=src+1 ;8bit flags
+ @@decompress_lop:
+ flagbits=flagbits SHR 1
+ if zero then goto @@collect_more
+ if carry=0 then
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ disp=([src]*10h)+([src+1]/10h)+1, len=([src+1] AND 0Fh)+1, src=src+2
+ if len=1 then goto @@decompress_done
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ endif
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+More info: http://doomwiki.org/wiki/WAD
+This format exists in two version:
+
Old format: Without leading Header Size entry (Cardinal Syn MagDemo03: SYN\*)
+ New format: With leading Header Size entry (eg. Fear Effect)
+ if [04h]*1Ch+8 >= [00h] then OLD version
+ 000h (4) Header Size (including folder/type/file directories) (new version)
+ ... 4 Number of Folders
+ ... .. Folder List (root)
+ ... .. Type Lists (for each folder)
+ ... .. File Lists (for each folder\type)
+ ... .. File Data (for each folder\type\file)
+ Folder List Entries:
+ 000h 14h Folder name (ASCII, zeropadded)
+ 014h 4 Offset to Type List
+ 018h 4 Number of different Types in this folder
+ Type List Entries:
+ 000h 4 Offset to file entries (of same type, eg. .TIM files)
+ 004h 4 Number of file entries (of same type, eg. .TIM files)
+ 008h 4 Sum of all Filesizes with that type
+ 00Ch 4 Group Type (0000000xh)
+ File List entries (Files within Type list):
+ 000h 14h Name (ASCII, terminated by 00h, plus garbage padding)
+ 014h 4 Offset to File Data (seems 4-byte aligned... always?)
+ 018h 4 File Type (000x00xxh)
+ 01Ch 4 Filesize in bytes ;\maybe compressed/uncompressed, or rounded,
+ 020h 4 Filesize in bytes ;/always both same
+The Type List, Group Type and File Type stuff seems to have no function, apart
+from faster look up (the types are also implied in the filename extension).
+Except, Fear Effect .RMD .VB .VH have some unknown stuff encoded in File Type
+bit16-19.
+Group Type is usually 0 (except for .TIM .VB .VH .MSG .SPU .OFF).
+The .TIM .VB .VH .SEQ files are using standard Sony file formats. The .PMD file
+seems to be also Sony standard (except that it contains a 00000000h prefix,
+then followed by the 00000042h PMD format ID).
.BGD FileType=00000001h
+ .ANM FileType=00000003h
+ .TIM FileType=00000004h (GroupType=1)
+ .SP2 FileType=00000005h
+ .PMD FileType=00000007h
+ .MOV FileType=00000008h
+ .SPR FileType=0000000Ch
+ .PVT FileType=0000000Dh
+ .DB FileType=0000000Eh
+ .VH FileType=00000010h (GroupType=1) ;only in OLDER demo version MagDemo03
+ .VB FileType=00000011h (GroupType=1)
+ .MSG FileType=00000012h (GroupType=1) (actually, this is .TIM, too)
+ .KMD FileType=00000013h
+ .OC FileType=00000018h
+ .EMD FileType=00000019h
+ .COL FileType=0000001Bh
+ .CF FileType=0000001Ch
+ .CFB FileType=0000001Dh
+ .CL FileType=0000001Eh
+ .SPU FileType=0000001Fh (GroupType=1) ;added in newer demo version MagDemo09
+ .OFF FileType=00000020h (GroupType=1) ;added in newer demo version MagDemo09
+ .RCT FileType=00000021h ;added in newer demo version MagDemo09
+ .TIM FileType=00000000h (GroupType=1)
+ .RMD FileType=000x0001h
+ .DB FileType=00000002h
+ .ANM FileType=00000003h
+ .SYM FileType=00000004h
+ .VB FileType=000x0008h (GroupType=1)
+ .SEQ FileType=00000010h
+ .BIN FileType=00000012h
+ .SFX FileType=00000013h
+ .VH FileType=000x0014h (GroupType=2)
+ .TM FileType=00000015h
+ .NRM FileType=00000017h
+ .WPD FileType=00000018h
+ Used by One (DATAFILE.BIN and DIRFILE.BIN)
+ Used by Viewpoint (VIEW.DAT and VIEW.DIR)
+ 000h 60h Extension List (20h x 3-char ASCII, zeropadded if shorter than 3)
+ 060h .. Root Directory (can contain folders and files)
+ ... .. Child Directories (can contain files) (maybe also sub-folders?)
+ In Viewpoint: "...VCSVCFBINTXTVH.VB.STRST1ST2ST3......//..."
+ In One: "...VCTVCKSNDBINCPEINI..................//..."
+ 000h 1 Length of Filename and Extension index
+ bit7-3 File Extension Index (0..1Fh = Offset I*3 in DIR file)
+ bit2-0 Filename Length-1 (0..7 = 1..8 chars)
+ 001h .. Filename in 6bit chars (N*6+7/8 bytes = 1..6 bytes for 1..8 chars)
+ bit7-2 1st character, whole 6bit ;\1st byte
+ bit1-0 2nd character, upper 2bit (if any) ;/
+ bit7-4 2nd character, lower 4bit (if any) ;\2nd byte (if any)
+ bit3-0 3rd character, upper 4bit (if any) ;/
+ bit7-6 3rd character, lower 2bit (if any) ;\3rd byte (if any)
+ bit5-0 4th character, whole 6bit (if any) ;/
+ bit7-2 5th character, whole 6bit (if any) ;\4th byte (if any)
+ bit1-0 6th character, upper 2bit (if any) ;/
+ bit7-4 6th character, lower 4bit (if any) ;\5th byte (if any)
+ bit3-0 7th character, upper 4bit (if any) ;/
+ bit7-6 7th character, lower 2bit (if any) ;\6th byte (if any)
+ bit5-0 8th character, whole 6bit (if any) ;/
+ bitN-0 Zeropadding in LSBs of last byte ;-zeropadding
+ The 6bit characters codes are:
+ 00h..09h="0..9", 0Ah..23h="a..z", 24h="_", 25h..3Fh=Unused
+ ... 4 Filesize and End Flag
+ bit31 End of Directory Flag (0=Not last entry, 1=Last entry)
+ bit30-0 Filesize 31bit (or 0=Child Folder)
+ ... 4 Offset and fixed bit
+ bit31 Unknown (always 1)
+ bit30-0 File Offset in DAT file (or Folder offset in DIR file)
+The files in FAT.BIN are using a messy chunk format: There's no clear ID+Size
+structure. There are 7 different chunk types (DRAM, DSND, MIDB, G3DB, VRAM,
+WEAP, HAND), each type requires different efforts to compute the chunk size.
000h 4 ID "VRAM"
+ 004h 4 With Tags (0=No, 1=Yes) (or "DRAM" when empty 4-byte chunk)
+ 008h (4) Number of Tagged items (N) (0=None) ;\only when [4]=1
+ 00Ch N*10h Tagged Item(s) ;/(not so in LEVELS\*\VIEW*)
+ ... .. Scanline Rows(s)
+ ... 4 End code (00000000h) (aka final Scanline Row with width=0)
+ Tagged Item(s) (IMG, LINE, GLOW, FLARE, BALLE, BLINK, COURIER7, BMP_xxx):
+ 000h 8 Tag (ASCII, if less than 8 chars: terminate by 00h, pad by FDh)
+ 008h 8 Data
+ Scanline Row(s) (bitmap scanlines and palette data):
+ 000h 4 Header (bit0-8=Width, bit10-18=Y, bit20-29=X, bit9,19,30,31=?)
+ 004h W*2 Data (Width*2 bytes, to be stored at VRAM(X,Y))
+ 000h 4 ID "G3DB"
+ 004h 4 Unknown (0, 1, or 2)
+ 008h 4 Size of Data part (SIZ)
+ 00Ch 4 Number of List entries (eg. 6 or 0Ah or 117Ch) (N)
+ 010h SIZ Data (supposedly LibGDX models in G3DB format)
+ ... N*4 List
+ 000h 4 ID "DRAM"
+ 004h 4 Size of Data part (SIZ) (can be odd)
+ 008h 4 Number of List entries (N)
+ 00Ch SIZ Data (raw data, and/or tags TEXT, SPC, COURIER7)
+ ... N*4 List
+ 000h 4 ID "WEAP"
+ 004h 4 Size-10h?
+ 008h .. Data
+ 000h 4 ID "HAND"
+ 004h 4 Size-0Ch? (18h)
+ 008h 8 Zerofilled
+ 010h 4x4 Unknown (FFh,FF00h,xF0000h,FF3232h,FF6464h,FFDCDCh,FFFFFFh,..)
+ 020h 4 Unknown (0, 1, 101h, or 201h)
+ 000h 4 ID "MIDB"
+ 004h 1 Unknown (0 or 1)
+ 005h 1 Number of SEQ blocks (1..4) (S)
+ 006h 1 Number of Unknown 80h-byte blocks (1..2) (U)
+ 007h U*80h Unknown Blocks (mostly FFh-filled)
+ ... S*Var SEQ Block(s)
+ ... .. VAB Block
+ SEQ Blocks:
+ Probably some MIDI sequence data, similar to Sony's .SEQ format.
+ 000h 4 Size-0Ch (can be odd)
+ 004h 8 Name (zeropadded if less than 8 chars)
+ 00Ch 4 ID "DSEQ" ;\Size
+ 010h .. Data ;/
+ VAB Blocks:
+ Apparently inspired on Sony's .VAB format (but the ID is spelled other way
+ around, Lists have variable size, and entries have different format).
+ 000h 4 ID "VABp" (this is: not pBAV, unlike normal .VAB files)
+ 004h 4 Unknown (0)
+ 008h 4 Unknown (0)
+ 00Ch 4 Size of all SPU-ADPCM samples (SIZ)
+ 010h 2 Number of List 1 entries (N1)
+ 012h 2 Number of List 2 entries (N2)
+ 014h 2 Number of Samples (N3)
+ 016h 6 Unused? (CCh-filled)
+ 01Ch N1*10h List 1
+ ... N2*10h List 2
+ ... N3*2 Sample Size List (size of each SPU-ADPCM sample)
+ ... SIZ SPU-APDCM Sample(s)
+ 000h 4 ID "DSND"
+ 004h 4 Unknown (0 or 2)
+ 008h .. VAB Block (same as in MIDB chunks, see there)
+DRAM and MIDB chunks can have odd size; there isn't any alignment padding, so
+all following chunks can start at unaligned locations.
000h 4 Size of AUDD+SEPD+VABB chunks ;\for quick look-up only
+ 004h 4 Size of all VRAM chunks ; (can be ignored by chunk crawlers)
+ 008h 4 Size of STGE+ANIM+FRAM chunks ;/(note: sum is total filesize-0Ch)
+ ... .. AUDD Chunk (contains .VH) ;\
+ ... .. SEPD Chunk(s) (contains .SEP) ; sound
+ ... .. VABB Chunk (contains .VB) ;/
+ ... (..) VRAM Chunk(s) (not in IN\FE2.TXD) ;-textures/palettes
+ ... (..) STGE Chunk (if any, not in IN\FE*.TXD) ;-stage data?
+ ... (..) ANIM Chunk (if any, not in IN\FE*.TXD) ;\animation
+ ... (..) FRAM Chunk(s) (if any, not in IN\FE*.TXD) ;/
+ ... (..) Further groups with ANIM+FRAM Chunks (if any) ;-more animation(s)
+ AUDD Chunks:
+ 000h 4 Chunk ID ("AUDD")
+ 004h 4 Chunk Size (of whole chunk from Chunk ID and up)
+ 008h 4 Compression Flag (0=Uncompressed)
+ 00Ch 4 Zero
+ 010h .. VH File (Sony Voice Header, starting with ID "pBAV")
+ SEPD Chunks:
+ 000h 4 Chunk ID ("SEPD")
+ 004h 4 Chunk Size (of whole chunk from Chunk ID and up)
+ 008h 4 Compression Flag (0=Uncompressed)
+ 00Ch 2 Zero
+ 00Eh 2 Number of sequences (in the SEP sequence archive)
+ 010h 4 Zero
+ 014h .. SEP File (Sony Sequence archive, starting with ID "pQES")
+ ... .. Zeropadding to 4-byte boundary
+ VABB Chunks:
+ 000h 4 Chunk ID ("VABB")
+ 004h 4 Chunk Size (of whole chunk from Chunk ID and up)
+ 008h 4 Compression Flag (0=Uncompressed)
+ 00Ch .. VB File (Sony Voice Binary, with raw SPU-ADPCM samples)
+ VRAM Chunks:
+ 000h 4 Chunk ID ("VRAM")
+ 004h 4 Chunk Size (of whole chunk from Chunk ID and up)
+ 008h 4 Compression Flag (1=Compressed)
+ 00Ch 2 VRAM.X
+ 00Eh 2 VRAM.Y
+ 010h 2 Width in halfwords
+ 012h 2 Height
+ 014h 4 Decompressed Size (Width*Height*2) ;\Texture Bitmaps 8bpp
+ 018h .. Compressed Data ; (or Palettes, in last VRAM
+ ... .. Zeropadding to 4-byte boundary ;/chunk)
+ STGE Chunks:
+ 000h 4 Chunk ID ("STGE")
+ 004h 4 Chunk Size (of whole chunk from Chunk ID and up)
+ 008h 4 Compression Flag (0=Uncompressed)
+ 00Ch .. Unknown (stage data?)
+ ANIM Chunks:
+ 000h 4 Chunk ID ("ANIM")
+ 004h 4 Chunk Size (of whole chunk from Chunk ID and up)
+ 008h 4 Compression Flag (0=Uncompressed)
+ 00Ch .. Unknown (animation sequence info?)
+ FRAM Chunks:
+ 000h 4 Chunk ID ("FRAM")
+ 004h 4 Chunk Size (of whole chunk from Chunk ID and up)
+ 008h 4 Compression Flag (0=When Chunksize=14h, 1=When Chunksize>14h)
+ 00Ch 1 Width in bytes
+ 00Dh 1 Height
+ 00Eh 6 Unknown, looks like three signed 16bit values (maybe X,Y,Z)?
+ 014h (4) Decompressed Size (Width*Height*1) ;\Animation Frame Bitmap 8bpp
+ 018h (..) Compressed Data ; (only if Chunksize>14h)
+ ... (..) Zeropadding to 4-byte boundary ;/
+Crazy Data Format (CDF) is used by Parasite Eve 2, on Disc 1 and 2:
+1: PE_Disk.01 Stage0.hed Stage0.cdf Stage1.cdf Stage2.cdf Stage3.cdf Inter0.str
+2: PE_Disk.02 Stage0.hed Stage0.cdf Stage3.cdf Stage4.cdf Stage5.cdf Inter1.str
This uses separate header/data files. The directory is stored in STAGE0.HED:
+
0000h 78h Streaming List (03h entries, 28h-bytes each, all entries used)
+ 0078h 1B00h File List (360h entries, 8 bytes each, all entries used)
+ 1B78b 8 File List End Code (FFFFFFFFh,FFFFFFFFh)
+ 0000h 800h Root: Folder List (100h entries, 8-byte each, unused=zeropadded)
+ 0800h .. 1st Folder (File/Streaming List and Data)
+ ... .. 2nd Folder (File/Streaming List and Data)
+ ... .. etc.
+ 000h 4 Folder ID (usually N*100+1 decimal, increasing, eg. 101,201,301,etc.)
+ 004h 4 Folder Size/800h (of whole folder, with File/Stream List and Data)
+ The Folder List ends with unused/zeropadded entries with ID/Size=00000000h.
+ 0000h 510h File List (A2h entries, 8-bytes each, unused=zeropadded)
+ 0510h 4 Zero (padding to decimally-minded offset 1300 aka 514h)
+ 0514h 2D0h Streaming List (12h entries, 28h-bytes each, unused=zeropadded)
+ 07E4h 1Ch Zero (padding to end of sector)
+ 0800h ... Data (for Files, Audio streams, and sometimes also Movie streams)
+ 000h 4 File ID (increasing, eg. 0,1,2,3,4,etc.) (or 99) (or N*100+x)
+ 004h 4 File Offset/800h in in .CDF (from begin of current Folder)
+ The offset of next File in File List (same as CurrOffset for 0-byte files)
+ The offset of next Audio stream in Streaming List
+ The offset of next Movie stream in Streaming List (if it's in .CDF, not .STR)
+ The size of the current Folder (for STAGE1-5)
+ The size of the whole .CDF file (for STAGE0)
+Most CDF files in STAGE0 and STAGE1-5 do contain one or more chunks with
+10h-byte chunk headers (this can be considered as an additional filesystem
+layer, with the chunk data being the actual files).
+
000h 1 Chunk Type (see below)
+ 001h 1 End Flag (01h=More Chunks follow, FFh=Last Chunk)
+ 002h 2 Unknown (usually 800h, sometimes 500h or 600h)
+ (eg. 500h in stage0\file30301\chunkX)
+ (eg. 600h in stage1\folder1201\file0\chunkXYZ)
+ 004h 4 Chunk Size/800h
+ 008h 4 Unknown (usually zero) (or 80xxxx00h in Chunk Type 0 files?)
+ 00Ch 4 Zero (0)
+ 010h .. Data (Chunk Size-10h bytes)
+ 00h=Room package .pe2pkg
+ 01h=Image .pe2img
+ 02h=CLUT .pe2clut
+ 04h=CAP2 Text .pe2cap2
+ 05h=Room backgrounds .bs
+ 06h=SPK/MPK music program .spk ;stereo/mono, sound/music, single/multiple?
+ 07h=ASCII text .txt (eg. stage0\20101..20132)
+ ;Reportedy also (but wrong):
+ ;60h=Sounds .pe2snd (but nope, that's wrong, see below)
+ ;60h is a MDEC movie from Streaming List (unrelated to File List chunks),
+ ;60h is 20h-byte .STR header each 800h-bytes (occurs in "stage1\folder501")
+ stage0\40105...40198 are raw hMPK files without chunks
+ stage0\11000, 20213, 20214, 20300, .., 660800 and 900000 are empty 0-byte
+ 000h 2 Stream Type (0001h=Movie)
+ 002h 2 Unknown (8000h or 0000h)
+ 004h 4 Offset/800h in current Folder of .CDF file ;<-- used when [024h]=0
+ 008h 4 Offset/800h in INTERx.STR file ;<-- used when [024h]>0
+ 00Ch 2 Unknown (0000h)
+ 00Eh 2 Stream ID (increasing, usually starting at 64h aka 100 decimal)
+ 010h 2 Stream sub.ID (usually 0, increases +1 upon multiple same IDs)
+ 012h 2 Picture Width (0140h = 320 decimal)
+ 014h 2 Picture Height (00F0h = 224 decimal)
+ 016h 2 Unknown (0000h)
+ 018h 2 Unknown (0000h or 0018h) maybe 24bpp or 24fps
+ 01Ah 2 Unknown (73Ah or 359h or 3DCh) (Size? but it's slighty too large?)
+ 01Ch 6 Unknown (zero)
+ 022h 2 Unknown (0 or 1) (often 1 when [024h]>0, but not always)
+ 024h 2 Movie number in INTERx.STR, 1 and up? (or 0=Movie is in STAGEx.CDF)
+ 026h 2 Unknown (0 or 1)
+ 000h 2 Stream Type (0002h=Audio)
+ 002h 2 Unknown (806Ah or increasing 0133h,0134h,0135h)
+ 004h 4 Offset/800h in STAGEx.CDF file (increasing offsets)
+ 008h 4 Unknown (0 or 13000h or E000h)
+ 00Ch 2 Stage Number (0..5 = STAGE0-5)
+ 00Eh 2 Stream ID (1, or increasing 3Ah,3Bh,3Ch)
+ 010h 4 Stream sub.ID (usually 0Bh, increases +0Ah upon multiple same IDs)
+ 014h 2 Unknown (0 or 2B0h or 3ADh or 398h) (Size/800h minus something?)
+ 016h 2 Unknown (usually 20h, sometimes 0Fh)
+ 018h 4 Unknown (2 or 1) ... maybe num channels ?
+ 01Ch 2+2 Unknown (0,0 or 800h,800h)
+ 020h 8 Unknown (0)
+This contains a 800h-byte header a list of 32bit indices:
+
000h 800h Whatever increasing 32bit index/timing values? FFFFFFFFh=special?
+ ;That header exists in stage0\ and stage3\folder101\
+ ;That header doesn't exist in all files (eg. not in stage1\folder301\)
+ 000h 4 Chunk Index (increases each second chunk, from 0 and up)
+ 004h 4 Number of Chunk Indices
+ 008h 4 Fixed (02h,"STM") ;2-channel Stream?
+ 00Ch 1 Chunk Subindex (toggles 00h or 01h per each chunk) ;ch left/right?
+ 00Dh 1 Chunk Size/800h
+ 00Eh 4 Unknown (can be 00h, 01h, 11h, 20h, 21h)
+ 00Fh 4 Unknown (can be A0h or C0h)
+ 010h .. Data (Chunk Size-10h bytes) (looks like SPU-ADPCM audio)
+ 000h 0 Number of ADPCM blocks? (eg. 28h or 49h)
+ 004h 4 Size of extra data block in bytes (eg. 13900h or 24200h)
+ 008h 38h Zerofilled
+ 040h 8 Zerofilled (maybe 1st sample of 1st SPU-ADPCM block)
+ 048h .. Looks like more SPU-ADPCM block(s), terminated by ADPCM end flag(s)
+ ... .. Zerofilled (padding to end of last 800h-byte sector)
+The movies are usually stored in INTERx.STR (except, some have them stored in
+STAGEx.CDF, eg. stage1\folder501, stage1\folder801, stage2\folder2101,
+stage2\folder3001).
+The data consists of standard .STR files (with 20h-byte headers on each
+800h-byte sector), with the MDEC data being in huffman .BS format (with .BS
+header... per frame?).
+And, supposedly interleaved with XA-ADPCM audio sectors...?
The presence of these files is probably used to detect which disc is inserted.
+The file content is unknown (looks like 800h-byte random values).
Reportedly "Files inside archive may be compressed with custom LZSS
+compression" (unknown if/when/where/really/which files).
ECTS.IND contains FOLDER info:
+
0000h 20h Name/ID ("Music 2", zeropadded)
+ 0020h 4 Unknown (110000h)
+ 0024h 4 Filesize-1000h (size excluding last 1000h-byte padding)
+ 0028h 4 Unknown (17E0h)
+ 002Ch 4 Unknown (5)
+ 0030h N*10h Folder List, starting with Root in first 10h-byte
+ 2CF0h 4 Small Padding (34h-filled)
+ 2CF4h 1000h Final Padding (34h-filled)
+ Folder List entries that refer to Child Folders in ECTS.IND:
+ 000h 8 Folder Name ("EXTRA*~*", zeropadded if less than 8) ("" for root)
+ 008h 2 Self-relative Index to first Child folder (positive)
+ 00Ah 2 Number of Child Folders (0..7FFFh)
+ 00Ch 4 Always 0007FFFFh (19bit Offset=7FFFFh, plus 13bit Size=0000h)
+ Folder List entries that refer to File Folders in ECTS.WAD:
+ 000h 8 Folder Name ("EXTRA*~*", zeropadded if less than 8)
+ 008h 2 Self-relative Index to Parent folder (negative)
+ 00Ah 2 Number of Child Folders (always 8000h=None)
+ 00Ch 4 Offset and Size in ECTS.WAD
+ The 32bit "Offset and Size" entry consists of:
+ 0-18 19bit Offset/800h in ECTS.WAD
+ 19-31 13bit Size/800h-1 in ECTS.WAD
+ There are several File Folders (at the locations specified in ECTS.IND).
+ The separate File Folders look as so:
+ 000h 4 Number of files (N)
+ 004h N*10h File List
+ ... .. 34h-Padding to 800h-byte boundary
+ ... .. File Data area
+ File List entries:
+ 000h 8 File Name ("NAMELIST", "ACIDWO~1", etc.) (00h-padded if shorter)
+ 008h 4 Offset/800h (always from begin of WAD, not from begin of Folder)
+ 00Ch 4 Filesize in bytes
+ The first file in each folder is called "NAMELIST" and contains this:
+ 000h 20h Long Name for Parent Folder (eg. "Backgrounds", zeropadded)
+ 020h 20h Long Name for this Folder (eg. "Extra 1", zeropadded)
+ 040h N*20h Long Names for all files in folder (except for NAMELIST itself)
+ For example, Long name for "ACIDWO~1" would be "Acidworld". Short names are
+ uppercase, max 8 chars, without spaces (with "~N" suffix if the long name
+ contains spaces or more than 8 chars). Many folder names are truncated to
+ one char (eg. "D" for Long name "DTex"), in such cases short names CAN be
+ lowercase (eg. "z" for Long name "zTrans").
+ The Long Names are scattered around in the NAMELIST files in ECTS.WAD file,
+ so they aren't suitable for lookup (unless when loading all NAMELIST's).
+ 0000h 4 Offset to Bonkers List (2794h)
+ 0004h F*8 Folder List (80h bytes, 10h entries)
+ 0084h N*14h File List(s) for each folder (2710h bytes, 1F4h entries)
+ 2794h 4 Number of Bonkers (FE3h)
+ 2798h B*8 Bonkers List (7F18h bytes, FE3h entries)
+ A6B0h 8 Unknown (zerofilled)
+ A6B8h .. File Data area
+ 000h 4 Offset to File List for this folder ;\both zero when empty
+ 004h 4 Number of Files in this folder ;/
+ 000h 10h Filename ("FILENAME_EXT", zeropadded)
+ 010h 3 Index (in Bonkers list) (000h..Fxxh)
+ 013h 1 Folder Number where the file is stored (00h..0Fh)
+ 000h 4 File Offset (to Data, inreasing, 4-byte aligned, A6B8h and up)
+ 004h 4 Folder Number where the file is stored (00h..0Fh)
+ 000h 2 Number of Folders (175h in retail, 0Ah in demo)
+ 002h 2 Zero
+ 004h N*8 Folder List (8-byte per Folder)
+ ... .. Zeropadding (to 800h-byte boundary)
+ ... .. 1st Folder (with File List, and File Data for that folder)
+ ... .. 2nd Folder (with File List, and File Data for that folder)
+ ... .. 3rd Folder (with File List, and File Data for that folder)
+ ... .. etc.
+ 000h 2 Unknown (somehow randomly increases from -8000h to +7E8Fh)
+ 002h 2 Number of Files in this Folder (eg. 97h)
+ 004h 4 Offset to Folder (usually 800h-aligned)
+ 000h 2 Number of Files (same value as FolderistEntry[002h]) ;\encrypted
+ 002h 2 Zero ; by 16bit
+ 004h N*10h File List (10h-byte per Folder) ; XOR value
+ ... .. Zeropadding (to 800h-byte boundary) ;/
+ ... .. File Data for this folder ;-unencrypted
+ 000h 4 Unknown (random? filename hash? encrypted name?)
+ 004h 4 File Size in bytes
+ 008h 4 File Offset (usually 800h-aligned)
+ 00Ch 4 Unknown (random? filename hash? encrypted name?)
+ key = FileListEntry[000h] XOR FolderListEntry[002h] ;encrypted num entries
+ key = FileListEntry[002h] ;encrypted Zero
+ key = FileListEntry[zeropadding, if any] ;encrypted Zeropadding
+FF8 is quite a mess without clear directory structure. Apart from SYSTEM.CNF
+and boot EXE, there is only one huge IMG file. There are at least two central
+directories: The Root directory (usually at the start of the IMG file), and the
+Fields directory (hidden in a compressed file that can be found in the Root
+directory). Moreover, there are files that exist in neither of the directories
+(most notably the Movies at the end of the IMG file).
The IMG file doesn't have a unique file header, it can be best detected by
+checking the filename: FF8DISCn.IMG with n=1-4 for Disc 1-4 (or only
+FF8DISC1.IMG or FF8.EXE+FF8TRY.IMG for demo versions).
+The directories contain ISO sector numbers (originated from begin of the ISO
+area at sector 00:02:00). Accordingly, it's best to extract data from the whole
+disc image (in CUE/BIN format or the like). When having only the raw IMG file,
+one most know/guess the starting sector number (eg. assume that the first Root
+File is located on the sector after the Root Directory, and convert sector
+numbers ISO-to-IMG accordingly).
+Another oddity is that many files contain RAM addresses (80000000h-801FFFFFh),
+unknown how far that's relevant, and if there are cases where one would need to
+convert RAM addresses to IMG offsets.
The Root Directory is found at:
+
Offset 0000h in FF8DISCn.IMG in NTSC retail versions
+ Offset 2800h in FF8DISCn.IMG in PAL retail versions
+ Offset 0000h in FF8DISC1.IMG in french demo version
+ Offset ?????h in FF8.EXE in MagDemo23 (...maybe offset 3357Ch ?)
+ Offset 33510h in FF8.EXE in japanese demo version ?
+ Offset 33584h in FF8.EXE in other demo versions ?
+ if FF8DISCn.IMG starts with 000003xxh --> assume Root at IMG offset 0
+ if FF8DISCn.IMG starts with xxxxxxxxh --> assume Root at IMG offset 2800h
+ if FF8TRY.IMG starts with "SmCdReadCore" --> assume Root somewhere in EXE
+ 000h N*8 File List entries
+ ... .. Zeropadding to end of 800h-byte sector
+ 000h 4 ISO Sector Number (origin at 00:02:00) (unsorted, not increasing)
+ 004h 4 Filesize in bytes
+The Fields Directory is located in Root file 0002h. First of, decompress that
+file, then search the following byte sequences to find the start/end of the
+directory:
+
retail.start 040005241800bf8f1400b18f1000b08f2000bd270800e00300000000
+ retail.end 0000010002000300
+ demo.start 76DF326F34A8D0B863C8C0EC4BE817F8
+ demo.end 0000000000000000000000000000000000100010
+ 000h 4 ISO Sector Number (origin at 00:02:00)
+ 004h 4 Filesize in bytes
+There is no known central directory for the movies (unknown if such a thing
+exists, or if the movie sector numbers are scattered around, stored in separate
+files). However, a movie list can be generated by crawling the movie headers,
+starting at end of IMG file:
+
sector = NumSectors(IMG file)
+ @@lop:
+ seek(sector-1), read(buf,08h bytes)
+ if first4byte[buf+0]=("SMJ",01h), or ("SMN",01h) then
+ num_sectors=(byte[buf+5]+1)*(halfword[buf+6]+1)
+ sector=sector-num_sectors
+ AddToMovieFileList(sector, num_sectors)
+ goto @@lop
+ endif
+PADBUG archives are used in Root files 001Eh..007Fh, most of them contain two
+AKAO files (except file 004Bh contains one AKAO and one TXT file).
+
000h 4 Number of Files (N) (usually 2)
+ 004h N*8 File List
+ ... .. File Data area
+ 000h 4 Offset in bytes (increasing, 4-byte aligned, see Quirk)
+ 004h 4 File Size in bytes (can be odd)
+CDROM File Compression LZ5 and LZ5-variants
+FF8 does reportedly also use GZIP (unknown in which files).
root sectors: 27CBh ;\
+ field sectors: D466h ; total known sectors: 36D13h
+ movie sectors: 270E2h ;/
+ unknown sectors: 14F49h
+ total IMG sectors: 4BC5Ch
+https://github.com/myst6re/deling/blob/master/FF8DiscArchive.cpp
+https://ff7-mods.github.io/ff7-flat-wiki/FF8/PlaystationMedia.html
+ 000h Root Directory
+ 800h 1st Child Folder
+ ... 2nd Child Folder
+ ... 3rd Child Folder
+ ... ...
+ 8000h ? Last folder, with Type3, contains 1FFh x increasing 16bit numbers
+ ... Data for files in 1st Child Folder
+ ... Data for files in 2nd Child Folder
+ ... Data for files in 3rd Child Folder
+ ...
+ 000h 4 ID "FF9 "
+ 004h 4 Unknown (06h on Disc 1 of 4) (maybe version, or disc id?)
+ 008h 4 Number of Folder List entries (0Fh)
+ 00Ch 4 Unknown (01h on Disc 1 of 4) (maybe version, or disc id?)
+ (or Offset/800h to first file list?)
+ 010h N*10h Folder List
+ ... .. Padding to 800h-byte boundary ("FF9 FF9 FF9 FF9 ")
+ 000h 4 FolderType (2=Normal, 3=Special, 4=Last entry)
+ 004h 4 Number of entries in File List (0..1FFh ?)
+ 008h 4 Offset/800h to Child Folder with File List
+ 00Ch 4 Offset/800h to File Data (same as 1st offs in File List) (0=Last)
+ 000h N*8 File List entries (N=Number of files, from Root directory)
+ N*8 8 File List END entry (ID=FFFFh, Attr=FFFFh, Offs=EndOfLastFile)
+ ... .. Zeropadding to 800h-byte boundary
+ 000h 2 File ID (increasing, often decimal 0,10,100, or FFFFh=Last)
+ 002h 2 Attr (unknown purpose, eg. 0,2,3,4,8,21h,28h,2Fh,44h,114h,FFFFh)
+ 004h 4 Offset/800h to File Data (increasing, implies end of prev entry)
+ 000h N*2 File Offsets/800h, from File Data Offset in Root (or FFFFh=None)
+ N*2 2 End Offset for last file
+Most of the files in FF9.IMG are DB archives, there are also some DOT1
+archives.
+CDROM File Archive FF9 DB (Final Fantasy IX)
+There are various combinations of IMG, DB, DOT1 archives nested up to 4 levels
+deep:
+
IMG\DOT1 (eg. dir01\file003C)
+ IMG\DB (eg. dir01\file2712)
+ IMG\DB\DOT1 (eg. dir01\file2712\00-0411)
+ IMG\DB\DOT1\DOT1 (eg. dir01\file2712\00-0443\*)
+ IMG\DB\DB (eg. dir03\file2328\1B-000*)
+ dir00 - Status/Menu/Battle/... -Text and random stuff.
+ dir01 - Misc Images (Logos, Fonts, World 'mini' Map images, etc).
+ dir02 - Dialog Text
+ dir03 - Map models (Mini-zidane, airships, save point moogle, tent...)
+ dir04 - Field models
+ dir05 - Monster Data (Part I, stats, names, etc).
+ dir06 - Location Data (Dungeon, Cities, etc).
+ dir07 - Monster Data (Part II, 3d models)
+ dir08 - Weapon Data (including models)
+ dir09 - Samplebanks and Sequencer Data (ie music).
+ dir0A - party members Data (including models)
+ dir0B - Sound effects
+ dir0C - World Map Data
+ dir0D - Special effects (magic, summons...)
+https://ninjatoes.blogspot.com/2020/07/
+https://wiki.ffrtt.ru/index.php?title=Main_Page
+ 000h 4 ID "GTFS" ;\
+ 004h 4 Zero ;
+ 008h 2 Number of 4-byte File Offset List entries (N) ; File(0)
+ 00Ah 2 Number of 20h-byte File/Folder Name List entries (F) ;
+ 00Ch 4 Zero ;
+ 010h N*4 File Offset List (see below) ;/
+ ... .. Zeropadding to 800h-byte boundary
+ ... F*20h File/Folder Name List (see below) ;-File(1)
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. File Data ;-File(2)
+ ... .. Zeropadding to 800h-byte boundary
+ ... File Data ;-File(3)
+ ... .. ...
+ ... File Data ;-File(N-2)
+ ... .. Zeropadding to 800h-byte boundary
+ EOF 0 End of File ;-File(N-1)
+ File(0) and File(1) = Directory information
+ File(2)..File(N-2) = Regular data files
+ File(N-1) = Offset List entry points to the end of .VOL file
+ Bit0-10 = Number of padding bytes in last sector of this file (0..7FFh)
+ Bit11-31 = Offset/800h to first sector of this file (increasing)
+ To compute the filesize: Size=(Entry[N+1] AND FFFFF800h)-Entry[N]
+ 000h 4 Unknown (379xxxxxh) (maybe timestamp?)
+ 004h 2 When Flags.bit0=0: Index of File in File Offset List (2 and up)
+ When Flags.bit0=1: Index of first child in Name List, or...
+ When Flags.bit0=1: Index of 1st? parent in Name List (Name="..")
+ 006h 1 Flags (bit0:0=File, 1=Directory; bit7:1=Last Child entry)
+ 007h 19h Name (ASCII, zeropadded)
+ size=gz_filesize
+ size=size-GzipHeader(including ExtraHeader, Filename, Comment, HeaderCrc)
+ size=size-GzipFooter(8) ;initially assuming 8-byte footer (without padding)
+ i=gz_filesize-4
+ @@search_footer:
+ if buf[i]<size then i=i-1, size=size-1 goto @@search_footer
+ decompressed_size = buf[i]
+ISO Files:
+
CD.IMG 550Mbyte Contains file 004h..FFFh
+ CDRTBL.DAT 32Kbyte Alias for file 000h (File List for file 000h..FFFh)
+ FDTBL.DAT 2Kbyte Alias for file 001h (Folder List and Disc ID)
+ SLPS_010.4* 500Kbyte Alias for file 003h (Boot EXE)
+ SYSTEM.CNF 72bytes Alias for file 002h (Boot Info)
+ XXXXXXXX. 27Mbyte Padding (zerofilled)
+ FDLTBL.DAT seems to be used to divide the file list in CDRTBL.DAT into
+ separate folders. The Folder List entries are containing the first file number
+ for each folder. Empty folders have same file number as next entry.
+ The last folder contains the specified file number plus all remaining files.
+ 000h 56h*2 Folder List (16bit File Numbers, increasing from 0004h to 0xxxh)
+ 0ACh 748h Zerofilled
+ 7F4h 0Ah Game ID (ASCII "SLPS1045",00h,00h; always so on Disc 1..3)
+ 7FEh 2 Disc ID (1..3 = Disc 1..3)
+ 000h 8000h File List (1000h x 8-byte entries)
+ File List entries:
+ 000h 4 Sector (MM:SS:FF:00 in BCD, increasing) ;\all zero for
+ 004h 2 Size1 (NumFramesCh1 or NumSectors) ; unused entries
+ 006h 2 Size0 (NumFramesCh0 or Zero) ;/
+ The meaning of the Size entries depends on the file type:
+ Normal binaries: [004h]=NumSectors [006h]=0 (1 channel)
+ XA-ADPCM streams: [004h]=NumSectors-50h [006h]=0 (16 channels)
+ MDEC streams: [004h]=NumFrames [006h]=0 (audio+video)
+ Special streams: [004h]=NumFramesCh1 [006h]=NumFramesCh0 (2 channels)
+ To determine the actual filesize, one must compute the difference between
+ sectors for current and next used file entry (or end of CD.IMG for last file;
+ or alternately assume last file to be a Normal Binary with Size=NumSectors).
+ Normal Binaries:
+ Contains single files (file=0/channel=0). Filetypes include TIM, VB, VH,
+ other/custom file formats, and DOT1 archives.
+ The DOT1 archives have 4-byte aligned offsets, but, unconventionally, with
+ some offsets set to ZERO (usually the last entry, and sometimes also other
+ entries):
+ SEQ files (Disc1:Dir08h\File173h) ;with ZERO entries (=uncommon)
+ SEQ files (Disc1:Dir09h\File176h..3D7h) ;with ZERO entries (=uncommon)
+ SEQ files (Disc1:Dir0Ah\File3DAh..3E6h) ;with ZERO entries (=uncommon)
+ TIM files (Disc1:Dir4Fh\File962h..983h) ;with ZERO entries (=uncommon)
+ TIM files (Disc1:Dir0Ch\File414h..426h) ;without ZERO entries (=normal DOT1)
+ XA-ADPCM Streams (Disc1:Dir0Bh\File3E7h..413h):
+ These contain 16 audio streams (file=1/channel=00h-0Fh). The Size entry is
+ set to total size in sectors for all streams, minus 50h (ie. there appears
+ to be 50h sectors appended as padding before next file).
+ MDEC Streams (Disc1:Dir53h\FileBD1h..BEBh):
+ These are standard STR files with MDEC video (file=0/channel=1) and
+ XA-ADPCM (file=1/channel=1). There are 10 sectors per frame (8-9 video
+ sectors plus 1-2 audio sectors). The total filesize is NumFrames*10+Align(8)
+ sectors; the Align(8) might be there to include one final audio sector.
+ Special Streams (Disc1:Dir07h\File0E9h-16Eh and Dir50h\File985h..B58h):
+ These are custom STR files (non-MDEC format), perhaps containing Polygon
+ streams or whatever.
+ There are two channels (file=1/channel=00h-01h), each channel contains
+ data that consists of 5 sectors per frame (1xHeader plus 4xData).
+ The sectors have STR ID=0160h, and STR Type as follows:
+ 0000h=Whatever special, channel 0 header (sector 0)
+ 0400h=Whatever special, channel 1 header (sector 1)
+ 0001h=Whatever special, channel 0 data (sector 2,4,6,8)
+ 0401h=Whatever special, channel 1 data (sector 3,5,7,9)
+ The File List size entries contain Number of Frames for each channel (either
+ of these entries may be zero, or bigger/smaller/same than the other entry).
+ The smaller channel is padded to same size as bigger channel (ie. total
+ filesize is "max(NumFramesCh0,NumFramesCh1)*10 sectors"; though that formula
+ doesn't always hold true, for example, Disc1:Dir50h\FileA2Dh and FileB1Bh
+ are bigger or smaller than expected).
+ FILE.IDX
+ 000h 8 ID "FAdj0500"
+ 008h 38h RAM addresses (80xxxxxxh, 0Ch words)
+ 038h 4 Zero
+ 03Ch 4 RAM address (80xxxxxxh)
+ 040h N*10h File List (including Folder start/end markers)
+ FILE.BIN
+ 000h .. File Data area (split into filesizes from FILE.IDX)
+ Type 0 (Folder End):
+ 000h 4 Type (0=Folder End)
+ 000h 4 Zero
+ 008h 4 RAM address (always 801EAF8Ch)
+ 00Ch 4 Zero
+ Type 1.a (Folder Start):
+ 000h 4 Type (1=Folder Start)
+ 000h 4 Folder Offset/800h (offset of FIRST file in this Folder)
+ 008h 4 RAM address (always 801EAF8Ch)
+ 00Ch 4 Folder Size/800h (size of ALL files in this Folder)
+ Type 1.b (Force Offset, can occur between Files within a Folder):
+ 000h 4 Type (1=Same as Folder Start)
+ 000h 4 Folder Offset/800h (offset of NEXT file in this Folder)
+ 008h 4 RAM address (always 801EAF8Ch)
+ 00Ch 4 Folder Size/800h (zero for Force Offset)
+ Type 2 (File entries, within Folder Start/End):
+ 000h 4 Type (2=File)
+ 004h 4 Filesize in bytes (4-byte aligned?)
+ 008h 4 RAM address 1 (80xxxxxxh, or zero)
+ 00Ch 4 RAM address 2 (80xxxxxxh)
+Xenogears, Chrono Cross, and Threads of Fate contain only two files in the ISO
+filesystem (SYSTEM.CNF and the boot executable). The CDROMs contain standard
+ISO data in Sector 10h-16h, followed by Hidden stuff in Sector 17h and up:
+
Sector 10h (00:02:16) Volume Descriptor (CD001) ;\
+ Sector 11h (00:02:17) Volume Terminator (CD001) ;
+ Sector 12h (00:02:18) Path Table 1 ;
+ Sector 13h (00:02:19) Path Table 2 ; standard ISO
+ Sector 14h (00:02:20) Path Table 3 ;
+ Sector 15h (00:02:21) Path Table 4 ;
+ Sector 16h (00:02:22) Root Directory ;/
+ Sector 17h (00:02:23) Hidden ID ;\
+ Sector 18h (00:02:24) Hidden Directory ; hidden directory
+ Sector .. (00:02:xx) Hidden Unknown ;/
+ Sector .. (00:02:xx) Hidden Files... (referenced via Hidden Directory)
+ Sector 17h (Hidden.ID)
+ 000h 0Eh ID ("DS01_XENOGEARS"=Disc 1, or "DS02_XENOGEARS"=Disc 2)
+ 00Eh 7F2h Zerofilled
+ Sector 18h..27h
+ 000h N*7 File List entries
+ Sector 28h (Hidden.Unknown)
+ Seems to contain a list of 16bit indices 0000h..1037h,FFFFh in File List
+ (that, as raw list indices, regardless of the directory structure)
+ 000h Unknown 0016 0018 FFFF FFFF 01A8 FFFF FFFF FFFF ;\
+ 010h Unknown FFFF FFFF FFFF FFFF 0A35 0A3A 0D35 0AD3 ; as so on Disc 2
+ 020h Unknown 0A22 0A2E 0A2F FFFF FFFF FFFF FFFF FFFF ; (values<>FFFFh
+ 030h Unknown 0014 0001 0013 FFFF 0075 FFFF FFFF FFFF ; on Disc 1
+ 040h Unknown 0C10 0C14 0C15 0C19 0F52 FFFF FFFF FFFF ; are 5 less, eg.
+ 050h Unknown 0F4C 0B6E 0C4D 1037 0C09 0BAD FFFF FFFF ; 0011,0013,FFFF..)
+ 060h Unknown 002E 0034 FFFF FFFF FFFF FFFF FFFF FFFF ;
+ 070h Unknown FFFF FFFF FFFF FFFF ;/
+ 078h 2 Disc Number (0001h=Disc 1, 0002h=Disc 2)
+ 07Ah 786h Zerofilled
+ Sector 29h 1st file
+ 000h 3 24bit Offset (increasing sector number, or 0=special)
+ 003h 4 32bit Size (filesize in bytes, or negative or 0=special)
+ offset=curr, size=+N file at sector=curr, size N bytes
+ offset=curr, size=-N begin of sub-directory, with N files
+ offset=curr, size=0 empty file, size 0 bytes
+ offset=0, size=0 unused file entry
+ offset=FFFFFFh, size=0 end of root-directory
+ Sector 17h (Hidden.ID)
+ 000h 2 Disc Number (0001h=Disc 1, 0002h=Disc 2)
+ 002h 2 Number of Discs? (0002h) (always 2, even if only 1 disc)
+ 004h 2+2 Sector and Size for Hidden.ID (Sector=0017h, Size=002Ch)
+ 008h 2+2 Sector and Size for Hidden.Directory (Sector=0018h, Size=60E0h)
+ 00Ch 2+2 Sector and Size for Hidden.Unknown (Sector=0025h, Size=0022h)
+ 010h 10h Zerofilled
+ 020h 0Ch Title ID ("CHRONOCROSS",00h) ;Chrono Cross (retail)
+ 09h Title ID ("DEWPRISM",00h) ;Threads of Fate (retail)
+ 10h Title ID ("DEWPRISM_TAIKEN",00h) ;Threads of Fate (demo)
+ 0xxh 7xxh Zerofilled (unused, since Hidden.ID has only Size=2Ch/29h/30h)
+ Sector 18h..24h (Hidden.Directory)
+ 000h N*4 File List entries
+ ... .. Zeropadding (till Size=60E0h, aka 6200 entries)
+ ... 720h Zeropadding (till end of 800h-byte sector)
+ Sector 25h (Hidden.Unknown)
+ Seems to contain a list of 16bit indices 0000h..1791h,FFFFh in File List
+ (though many of the listed indices are unused file list entries)
+ 000h 2 Disc Number (0001h=Disc 1, 0002h=Disc 2)
+ 002h 10h Unknown 0000 1791 1777 1775 00ED 09DF FFFF 0002 ;\same on
+ 012h 10h Unknown 0025 0943 10E3 FFFF FFFF 0C77 0FD9 0FA3 ;/Disc 1+2
+ 022h .. Zerofilled (unused, since Hidden.ID has only Size=0022h)
+ Sector 26h 1st file (same as boot EXE in ISO)
+ 0-22 Sector number
+ 23 Flag (0=Normal, 1=Unused entry)
+ 24-31 Number of unused bytes in last sector, div8 (0..FFh = 0..7F8h bytes)
+ filesize = ([addr+4]-[addr] AND 7FFFFFh)*800h - ([addr+3] AND FFh)*8
+The demo version is using the same directory format as retail version (but with
+Virtual Sector numbers in HED+EXE+IMG files instead of Hidden Sectors).
+
TOF\DEWPRISM.HED (6000h bytes) VirtSector=1Ah, PhysSector=A0A5h
+ TOF\DEWPRISM.EXE (97800h bytes) VirtSector=26h, PhysSector=A0B1h
+ TOF\DEWPRISM.IMG (19EA800h bytes) VirtSector=155h, PhysSector=A1E0h
+ 000h 52Ch List for .DAT file ;value 0000h..6FFFh = sector 0..6FFFh in DAT
+ 52Ch D4h Zerofilled
+ 600h C4h List for .BNS file ;value 7000h..71AFh = sector 0..1AFh in BNS
+ 6C4h 3Ch Zerofilled
+ 700h 50h List for .STR file(s) ;raw CDROM sector numbers from 00:02:00
+ 750h B0h Zerofilled
+ 0-19 File Offset/800h (20bit)
+ 20-31 File Size/800h (12bit)
+ .HED is 2048 bytes
+ .DAT is 58720256 bytes = 3800000h bytes ;div800h would be 7000h
+ .BNS is 884736 bytes = D8000h bytes ;div800h would be 1B0h
+ .STR's: 7D3Bh+150 = 7DD1h = sector for STR\LAB.STR
+Below are two slightly different formats. WAD.WAD has unused entries
+00h-filled. The PKG format has them FFh-filled, and does additionally support
+Folders, and does have a trailing ASCII string. There's also a difference on
+whether or not to apply alignment to empty 0-byte files.
+However, the formats can appear almost identical (unused entries, 0-byte files,
+and folders are optional, without them, the only difference would be the
+presence of the ASCII string; which does exist only in 800h-byte aligned PKG's
+though).
Used by Crash Bandicoot 3 (DRAGON\WAD.WAD, plus nested WADs inside of WAD.WAD)
+Used by Crash Team Racing (SPYR02\WAD.WAD, plus nested WADs inside of WAD.WAD)
+Used by Madden NFL'98 (MagDemo02: TIBURON.DAT except PORTRAIT,SPRITES,XA.DAT)
+Used by N2O (MagDemo09, N2O\PSXMAP.TRM and N2O\PSXSND.SND)
+Used by Speed Racer (MagDemo10: SPDRACER\ALL1.BIN, with 0-byte, unpadded eof)
+Used by Gran Turismo 2 (MagDemo27: GT2\GT2.OVL = 128Kbyte WAD.WAD with GZIP's)
+Used by Jonah Lomu Rugby (LOMUDEMO\SFX\.VBS, ENGLISH\.VBS)
+Used by Judge Dredd (*.CAP and *.MAD)
+Used by Spyro 2 Ripto's Rage (SPYRO2\WAD.WAD, and nested WAD's therein)
+Used by Spyro 3 Year of the Dragon (SPYRO3\WAD.WAD, and nested WAD's therein)
+Used by Men: Mutant Academy (MagDemo33: PSXDATA\WAD.WAD\*, childs in PWF)
+
000h N*8 File List
+ ... .. Zeropadding to 4-byte or 800h-byte boundary (or garbage padding)
+ ... .. File Data...
+ 000h 4 Offset in bytes (4- or 800h-byte aligned, increasing) ;\both zero
+ 004h 4 Size in bytes (always multiples of 800h bytes) ;/when Unused
+This does resemble standard WAD.WAD, but with leading 800h-byte extra stuff.
+
000h 4 ID ("PWF ") ;\
+ 004h 4 Total Filesize (707800h) ;
+ 008h 4 Unknown (1) ; extra stuff
+ 00Ch 4 Number of files (N) ;
+ 010h 7F0h Zerofilled ;/
+ 800h N*8 File List ;\
+ ... .. Zerofilled (padding to 800h-byte boundary) ; standard WAD.WAD
+ ... .. File Data area ;/
+ File List entries:
+ 000h 4 File Offset in bytes (increasing, 800h-byte aligned)
+ 004h 4 File Size in bytes
+Used by Pandemonium II (JESTERS.PKG, with Files+Folders+Unused entries)
+Used by Herc's Adventure (BIG.BIN, with Files+Unused entries, without Folders)
+Used by Unholy War (MagDemo12:CERBSAMP.PKG, with 0-byte files and nested PKG's)
+Used by 102 Dalmatians (MagDemo40: PTTR\PSXDEMO.PKG)
+
000h N*8 File List
+ ... .. ASCII string (junk, but somewhat needed as nonzero end marker)
+ ... .. Zeropadding to 800h-byte boundary; not in 4-byte aligned nested PKG
+ ... .. File Data...
+ 000h 4 Offset in bytes (increasing, or 0=First child) ;\both FFFFFFFFh
+ 004h 4 Size in bytes (always nonzero) ;/when Unused
+<B> Example</B>
+ 00003800h,00000666h ;root00h (file 666h bytes, padded=800h)
+ 00004000h,00000300h ;root01h\.. (folder 300h bytes, padded=800h)
+ 00000000h,000000FDh ;root01h\child00h (file FDh bytes, padded=100h) ;\300h
+ FFFFFFFFh,FFFFFFFFh ;root01h\child01h (unused) ; byte
+ 00000100h,000001FDh ;root01h\child02h (file 1FDh bytes, padded=200h) ;/
+ 00004800h,00001234h ;root02h (file 1234h bytes, padded=1800h)
+ 00006000h,00001234h ;root03h (file 1234h bytes, padded=1800h)
+ FFFFFFFFh,FFFFFFFFh ;root04h (unused)
+ 00007800h,00001234h ;root05h (file 1234h bytes, padded=1800h)
+ etc.
+ 000h 4 Number of Files (eg. F4h)
+ 004h 0Ch Zero
+ 010h N*10h File entries
+ ... 4 Archive ID (eg. 00000000h, FF53EC8Bh, or 83FFFFFFh)
+ ... .. Zeropadding to 800h byte boundary
+ ... .. File Data
+ 000h 4 Archive ID (same value as in above header)
+ 004h 4 Filename checksum or so (randomly ordered, not increasing)
+ 008h 4 Filesize in bytes
+ 00Ch 4 Fileoffset (800h-byte aligned) (increasing)
+ looks like a lot of raw data without meaningful file headers...
+ file C3h,ECh are raw SPU-ADPCM
+ file 08h,09h are nested BIG archives, but with FileEntry[00h]=FF53EC8Bh
+ file D9h,DAh are nested BIG archives, but with FileEntry[00h]=83FFFFFFh
+Used by Gex 2: Enter the Gecko (BIGFILE.DAT)
+Used by Gex 3: Deep Cover Gecko (MagDemo20: G3\BIGFILE.DAT) -- UNSORTED
+Used by Akuji (MagDemo18: AKUJI\BIGFILE.DAT)
+Used by Walt Disney World Racing Tour (MagDemo35: GK\BIGFILE.DAT) -- UNSORTED
+
000h 4 Number of Files (C0h)
+ 004h N*18h File entries
+ ... .. Zeropadding to 800h byte boundary
+ ... .. File Data
+ 000h 4 Random
+ 004h 4 Filesize in bytes (uncompressed size)
+ 008h 4 Filesize in bytes (compressed size, or 0=uncompressed)
+ 00Ch 4 Fileoffset (800h-byte aligned) (increasing, unless UNSORTED)
+ 010h 4 Random
+ 014h 4 Random (or ascii in 1st file)
+ @@collect_more:
+ flagbits=[src]+[src+1]*100h+10000h, src=src+2 ;16bit flags, unaligned
+ @@decompress_lop:
+ if dst>=dst.end then goto @@decompress_done
+ flagbits=flagbits SHR 1
+ if zero then goto @@collect_more
+ if carry=0 then
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ len=([src] AND 0Fh)+1), disp=([src] AND 0F0h)*10h+[src+1], src=src+2
+ if len=1 or disp=0 then goto invalid ;weirdly, these are left unused
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ endif
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+ standard TIM (eg. file 01h,02h)
+ malformed TIM (eg. file 0Fh,14h) (with [8]=2*cx*cy+4 instead 2*cx*cy+0Ch)
+ crippled VAB (eg. file 0Eh,13h) (with hdr=filesize-4 plus raw ADPCM samples)
+ several DNSa (eg. file 0Dh,12h,17h,BCh) SND sound? (also used by kain)
+ PMSa (eg. Gex 3, World Racing) (SMP spu-adpcm samples)
+ there seem to be no nested DAT files inside of the main DAT file
+ 000h 1 ID (DBh)
+ 001h 1 Number of Types
+ 002h 2 Zero (0)
+ 004h N*4 Type List
+ ... .. File Lists & File Data for each Type
+ 000h 3 Offset to File List (self-relative, from current entry in Type List)
+ 003h 1 Data Type (00h..1Fh)
+ 000h 1 Data type (00h..1Fh) (same as in Type List)
+ 001h 1 Number of Files
+ 002h 2 Zero (0)
+ 004h N*2 File ID List (unique ID per type) (different types may have same ID)
+ ... .. Zeropadding to 4-byte boundary
+ ... N*4 Offset List (self-relative, from current entry in Offset List)
+ ... 4 End Offset (first-relative, from first entry in Offset List)
+ ... .. File Data (referenced from above Offset List)
+ 00h Misc (DOT1 Archives, or other files)
+ 01h Unused?
+ 02h Reportedly 3D Model data (vertices,quads,triangles,texcoords)
+ 03h Reportedly 3D Animation sequences
+ 04h TIM Texture
+ 05h Reportedly Scripts (hdr="EV") (eg. dir04\file32\1B-0001)
+ 06h ? (eg. dir02\file*)
+ 07h Sound "Sequencer Data" (hdr="AKAO") (eg. dir09\file*)
+ 08h Sound? tiny files (hdr="AKAO") (eg. dir04\file32\1B-0001)
+ 09h Sound Samples (hdr="AKAO") (eg. dir0B\file*)
+ 0Ah Reportedly Field Tiles and Field Camera parameters
+ 0Bh Reportedly Field Walkmesh (eg. dir04\file32\1B-0001)
+ 0Ch Reportedly Battle Scene geometry (eg. dir06\file*)
+ 0Dh ? (eg. dir01\file01)
+ 0Eh Unused?
+ 0Fh Unused?
+ 10h ? (eg. dir05\file*)
+ 11h ? (eg. dir05\file*)
+ 12h Reportedly CLUT and TPage info for models (eg. dir04\file32\1B-0001)
+ 13h Unused?
+ 14h ? (eg. dir05\file*)
+ 15h Unused?
+ 16h ? (eg. dir04\file32\1B-0001)
+ 17h ? (eg. dir04\file32\1B-0000)
+ 18h Sound (hdr="AKAO") (eg. dir04\file32\1B-0001)
+ 19h ? (eg. dir04\file32\1B-0001)
+ 1Ah ? (eg. dir06\file*)
+ 1Bh DB Archives (ie. further DB's nested inside of the parent DB archive)
+ 1Ch ? (eg. dir04\file32\1B-0001)
+ 1Dh ? (eg. dir03\file2328\1B-0001)
+ 1Eh ? (eg. dir04\file32\1B-0001)
+ 1Fh ? (eg. dir04\file32\1B-0001)
+ 20h..FFh Unused?
+There are two archives, stored in three files:
+
ACE2.DAT Directory for Data in ACE2.DAT itself ;normal binary data
+ ACE2.STH Directory for Data in separate ACE2.STP file ;streaming data
+ 000h 4 Unknown (1)
+ 004h 4 Number of entries (N)
+ 008h N*8 File List
+ 0-27 28bit Size/N (DAT=Size/4, STP=Size/800h)
+ 28-31 4bit Type or Channel Number (see below)
+ 32-63 32bit Offset/800h in ACE2.STP or ACE2.DAT file
+ File Bit28-31 Channel Sector types... Interleave Notes
+ DAT 0 ch=0 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 1:1 data (normal)
+ DAT 2 ch=0 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 1:1 data (exe)
+ STH 0-6 ch=0-6 S.......S.......S.......S....... 1:8 stereo
+ STH 8 ch=1 vvvvvvvSvvvvvvvSvvvvvvvSvvvvvvvS 1:1 video+stereo
+ Whereas D=data, S=Stereo/Audio, v=video, .=other channels
+There are two archives, stored in four files:
+
ACE.BPH Directory for Data in separate ACE.BPB file ;normal binary data
+ ACE.SPH Directory for Data in separate ACE.SPB file ;streaming data
+ 000h 4 ID "AC3E" (=Ace Combat 3 Electrosphere)
+ 004h 4 Type (BPH=3=Data?, SPH=1=Streaming?)
+ 008h 2 BCD Month/Day? (Japan=0427h, US=1130h)
+ 00Ah 2 BCD Year (or zero) (SPH=1999h, BPH=0)
+ 00Ch 4 Unknown (SPH=0, BPH/US=16CFh or BPH/JP=1484h)
+ 010h 4 Number of entries (N)
+ 014h N*8 File List
+ 0-18 19bit Size/N (BPH=Size/4, SPB=Size/800h)
+ 19-23 5bit Channel Number (BPH=0, SPH=0..1Fh)
+ 24-26 3bit Channel Interval (BPH=0, SPH=1 SHL N, eg. 3=Interval 1:8)
+ 27 1bit Video Flag (0=No, 1=Has Video sectors)
+ 28 1bit Audio Flag (0=No, 1=Has Audio sectors)
+ 29 1bit Always 1 (except special entries with Bit31=0, see below)
+ 30 1bit Unknown (US: Always 1, Japan: 0 or 1)
+ 31 1bit Always 1 (except special entries with Bit31=0, see below)
+ 32-63 32bit Offset/800h in ACE.BPB or ACE.SPB file (or 0 when bit31=0 ?)
+ For unknown purpose, the normal entries with Bit31=1 are occassionally followed by one or more entries with Bit31=0.
+ Unknown if those entries do affect the actual storage (like switching to
+ different channel numbers, or jumping to non-continous sector numbers).
+ That unknown stuff exists in Japanese version only, not in US version.
+ 0-18 19bit Unknown (maybe some snippet size value in whatever units?)
+ 19-23 5bit Always 0 (instead of Channel)
+ 24-27 4bit Same as in most recent entry with Bit31=1
+ 28-31 4bit Always 5 (instead of Flags)
+ 32-63 32bit Always 0 (instead of Offset)
+ File Bit24-31 Sector types... Interval Content
+ BPH.US E0h DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 1:1 data
+ SPH.US F8h SvvvvvvvSvvvvvvvSvvvvvvvSvvvvvvv 1:1 stereo+video
+ SPH.US FBh S.......v.......S.......v....... 1:8 stereo+video
+ SPH.US F3h S.......S.......S.......S....... 1:8 stereo
+ SPH.US F4h S...............S............... 1:16 stereo
+ SPH.US F5h M............................... 1:32 mono
+ BPH.JAP E0h DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 1:1 data
+ SPH.JAP B8h,F8h SvvvvvvvSvvvvvvvSvvvvvvvSvvvvvvv 1:1 stereo+video
+ SPH.JAP B9h Svvv....vvvv....Svvv....vvvv.... 1:2 (4:8) stereo+video
+ SPH.JAP BAh,FAh Mv......vv......vv......vv...... 1:4 (2:8) mono+video
+ SPH.JAP BBh,FBh S.......v.......S.......v....... 1:8 stereo+video
+ SPH.JAP B3h,F3h S.......S.......S.......S....... 1:8 stereo
+ SPH.JAP B5h,F5h M............................... 1:32 mono
+ Whereas D=data, S=Stereo/Audio, M=Mono/Audio, v=Video, .=Other channels
+ v0 Crash Bandicoot Prototype (oldest known prototype from 08 Apr 1996)
+ v1 Crash Bandicoot 1 (retail: S*\*.NSD and .NSF)
+ v2 Crash Bandicoot 2 (MagDemo02: CRASH\S0\*.NSD and .NSF)
+ v3 Crash Bandicoot 3 Warped (MagDemo26,50: (S0\*.NSD and .NSF)
+ 0000h 100h*4 Lookup Table, using index=((Filename/8000h) AND FFh) ;\
+ 0400h 4 Number of Chunks in .NSF file ; Lookup
+ 0404h 4 Number of Files in Lookup File List (N) ;/
+ 0408h 4 Level Data Filename (eg. 4F26E8DFh="DATh.L") ;-LevelDat
+ 040Ch 4 Bitmap Number of Colors (100h) (P) (0=None) ;\
+ 0410h 4 Bitmap Width (200h or 1B0h) (X) (0=None) ; Bitmap
+ 0414h 4 Bitmap Height (0D8h or 090h) (Y) (0=None) ;/
+ 0418h 4 Compression: Offset/800h of first uncompressed chunk ;\
+ 041Ch 4 Compression: Number of compressed chunks (0..40h) ; Compress
+ 0420h 40h*4 Compression: Compressed Chunk List (0=unused entry) ;/
+ ... N*8 Lookup File List ;-Lookup
+ ... .. Level Data (size/format varies, see below) ;-LevelDat
+ ... P*2 Bitmap Palette (16bit values, 8000h..FFFFh) ;\Bitmap
+ ... X*Y Bitmap Pixels (0D8h*200h) ;/
+ v0 NSD Filesize=408h + N*8 ;-Lookup only
+ v1 NSD Filesize=520h + N*8 + P*2+X*Y + 210h ;\
+ v2 NSD Filesize=520h + N*8 + P*2+X*Y + 1DCh+S*18h ; with extra stuff
+ v3 NSD Filesize=520h + N*8 + P*2+X*Y + 2DCh+S*18h ;/
+The lookup table allows to find files (by filenames) in the NSF files. It does
+merely contain the NSF chunk number, so one must load/decompress that chunk to
+find the file's exact size/location in that chunk.
+One can create a complete file list by scanning the whole NSF file without
+using the NDS lookup table.
+
Lookup File List entries (indexed via Lookup Table):
+ 00h 4 Chunk Number in .NSF file
+ 04h 4 Filename (five 6bit characters)
+ 0 Type (always 1=Filename) (as opposed to 0=Memory Pointer)
+ 1-6 5th character ;-Extension ;\character set is:
+ 7-12 4th character ;\ ; 00h..09h="0..9"
+ 13-18 3rd character ; Name ; 0Ah..23h="a..z"
+ 19-24 2nd character ; ; 24h..3Dh="A..Z"
+ 25-30 1st character ;/ ;/3Eh..3Fh="_" and "!"
+ 31 Always zero?
+Level Data exists in NSD v1-v3 (v0 does also have Level Data, but it's stored
+in NSF file "DAT*.L" instead of in the NSD file). There are two major versions:
+
Level Data in NSD v1 (or NSF v0 file DAT*.L):
+ 000h 4 01h ;\
+ 004h 4 Level Number (xxh) (same as xx in S00000xx.NSD/NSF) ;
+ 008h 4 3807C8FBh = "s0_h.Z" ? ; LevelDat
+ 00Ch 4 Zero ; v1
+ 010h 4 Zero ;
+ 014h L*4 Namelist (40h*4) ;
+ ... 4 5Ah ;
+ ... F8h Zerofilled ;/
+ Level Data in NSD v2-v3:
+ 000h 4 Number of Spawn Points (S) ;\
+ 004h 4 Zero ;
+ 008h 4 Level Number (xxh) (same as xx in S00000xx.NSD/NSF) ; LevelDat
+ 00Ch 4 Number of Objects? (can be bigger than below list) ; v2/v3
+ (eg. 1BDh or A5h or E4h) ;
+ 010h L*4 Namelist for Objects? (v2=40h*4, or v3=80h*4) ;
+ ... 4 Unknown, always 5Ah (maybe just list end marker?) ;
+ ... C8h Zerofilled ;
+ ... S*18h Spawn Points ;/
+This bitmap is displayed while loading the level.
Compression is only used in v1 (v2-v3 do also have the compression entries at
+[418h..51Fh], but they are always zerofilled).
+
Compressed Chunk List entries at [420h..51Fh]:
+ 0-5 Compressed Chunk Size/800h (1..1Fh=800h..F800h bytes, 20h..3Fh=Bad?)
+ 6-31 Compressed Chunk Offset/800h
+NSF files consist of 64Kbyte chunks (compressed chunks are smaller, but will be
+64Kbyte after decompression). Each chunk can contain one or more file(s). That
+implies that all files must be smaller than 64Kbyte (larger textures or ADPCM
+samples must be broken into multiple smaller files).
+All files (except Textures) are NSF Child Archives which contain one or more
+smaller files/items.
N*8Kbyte-Compressed-chunks:
+ 000h 2 ID, always 1235h (instead of 1234h)
+ 002h 2 Zero
+ 004h 4 Decompressed Size (max 10000h) (usually 9xxxh..Fxxxh, often Fxxxh)
+ 008h 4 Skip Size (max 40h or so, when last LZSS_len was 40h)
+ 00Ch .. Compressed data
+ ... SK Unused (Skip size)
+ ... .. Final uncompressed bytes (10000h-compressed_size-skip_size)
+ 64Kbyte-Texture-chunks:
+ 000h 2 ID, always 1234h
+ 002h 2 Chunk Family (1=Texture)
+ 004h 4 Filename (five 6bit characters)
+ 008h 4 File Type (5=Texture)
+ 00Ch 4 Checksum (sum of bytes ar [0..FFFFh], with initial [0Ch]=00000000h)
+ 010h ... Zerofilled
+ 020h ... Texture data (raw VRAM data, FFE0h bytes?)
+ 64Kbyte-NonTexture-chunks:
+ 000h 2 ID, always 1234h
+ 002h 2 Chunk Family (0=Misc or 2..5=Sound)
+ 004h 4 Chunk Number*2+1
+ 008h 4 Number of Files (N) (can be 0, eg. prototype S0000003 chunk21h)
+ 00Ch 4 Checksum (sum of bytes ar [0..FFFFh], with initial [0Ch]=00000000h)
+ 010h N*4 File List (Offsets from ID=1234h to entries) (4-byte aligned)
+ ... .. Offset for end of last File
+ ... .. File Data (NSF Child Archives) (includes Type/Filename)
+ ... .. Padding to 10000h-byte boundary
+ 000h 4 ID, always 0100FFFFh
+ 004h 4 Filename (five 6bit characters)
+ 008h 4 File Type (01h..04h, or 06h..15h)
+ 00Ch 4 Item Count (I)
+ 010h I*4 Item List (Offsets from ID=0100FFFFh to items) (...unaligned?)
+ ... .. Offset for end last item
+ ... .. Data (Items)
+The compression is a mixup of LZSS and RLE. Compressed chunks are max F800h
+bytes tall (10000h bytes after decompression).
+
dst=chunk_buffer_64kbyte
+ if chunksize is known (from NSD file)
+ src=dest=dst+10000h-chunksize
+ diskread(fpos,src,chunksize)
+ else (when parsing raw NSF file without NSD file)
+ src=temp_buffer_64kbyte
+ diskread(fpos,src,10000h)
+ dst_start=dst, src_start=src
+ if halfword[src+00h]<>1234h then ;check ID (1234h=raw, or 1235h=compressed)
+ dst_end=dst+word[src+04h]
+ skip_size=word[src+08h]
+ src=src+0Ch
+ while dst<dst_end
+ x=[src], src=src+1
+ if x<80h then
+ for i=0 to x-1, [dst]=[src], dst=dst+1, src=src+1, next i ;uncompressed
+ else
+ x=(x AND 7Fh)*100h+[src], src=src+1
+ disp=x/8, len=(x AND 7)+3, if len=0Ah then len=40h
+ for i=0 to len-1, [dst]=[dst-disp], dst=dst+1, next i ;compressed
+ src=src+src_skip
+ if src<>dst then
+ while dst<dst_start+10000h, [dst]=[src], dst=dst+1, src=src+1 ;uncompressed
+ chunksize=src-src_start ;<-- compute (when chunksize was unknown)
+ fpos=fpos+chunksize ;<-- fileposition of next chunk
+Below shows File Type, Chunk Family, Extension (5th character of filename), the
+version where the type is used, 4-letter type names (as found in the EXE
+files), and a more verbose description.
+
Typ Family Ext Ver Name Description
+ 00h - ! - NONE Nothing
+ 01h 0 V all SVTX Misc.Vertices
+ 02h 0 G all TGEO Misc.Model ;\changed format in v2-v3 ?
+ 03h 0 W all WGEO Misc.WorldScenery ;/
+ 04h 0 S all SLST Misc.UnknownSLST
+ 05h 01h T all TPAG Texture.VRAM
+ 06h 0 L v0 LDAT Misc.LevelData ;-stored in NSD in v1-v3
+ 07h 0 Z all ZDAT Misc.Entity ;-changed format in v2-v3 ?
+ 08h - - - CPAT Internal?
+ 09h - - - BINF Internal?
+ 0Ah - - - OPAT Internal?
+ 0Bh 0 C all GOOL Misc.GoolBytecode
+ 0Ch 02h A v0 ADIO OldSound.Adpcm ;\type 0Ch
+ 0Ch 03h A all ADIO Sound.Adpcm ;/
+ 0Dh 0 M all MIDI Misc.MidiMusic ;-changed format in v1-v3 ?
+ 0Eh 04h N all INST Sound.Instruments
+ 0Fh 0 D v0-1 IMAG Misc.UnknownIMAG ;\type 0Fh
+ 0Fh 0 X v2-3 VCOL Misc.UnknownVCOL ;/
+ 10h - - - LINK Internal?
+ 11h 0 P v0-1 MDAT Misc.UnknownMDAT ;\type 11h
+ 11h 0 R v3 RAWD Misc.UnknownRAWD ;/
+ 12h 0 U v0-1 IPAL Misc.Unknown ;-Crash 1 only? (eg. S0000019.NSF)
+ 13h 0 B v1-3 PBAK Misc.DemoPlayback ;-eg. in MagDemo02
+ 14h 0 V v0-1 CVTX Misc.UnknownCVTX ;\type 14h
+ 14h 05h O v2-3 SDIO Speech.Adpcm ;/
+ 15h 0 D v2-3 VIDO Misc.UnknownVIDO
+https://gist.github.com/ughman/3170834
+https://dl.dropbox.com/s/fu29g6xn97sa4pl/crash2fileformat.html
+"Sound entries don't need to be aligned as strictly for most (all?) emulators."
+What does that mean???
+Is there a yet unknown 16-byte DMA alignment requirement on real hardware?
Metal Gear Solid (MagDemo13: MGS\)
+Metal Gear Solid (MagDemo25: MGS\)
+Metal Gear Solid (MagDemo44: MGS\) (looks same as in MagDemo13)
+Metal Gear Solid (Retail: MGS\)
File MagDemo13/44 MagDemo25 Retail/PAL
+ .EXE 9C000h 9C800h 9D800h ;-executable
+ STAGE.DIR 590800h 11A7800h 42AE000h ;-main archive
+ FACE.DAT 2CA000h 3Dh (txt) 358800h ;-face animation archive
+ ZMOVIE.STR - - 2D4E800h ;-movie archive
+ DEMO.DAT 149B000h 3Dh (txt) EC20000h ;\DAT/SYM combos (the .SYM
+ DEMO.SYM 88h - - ; files were leaked in
+ VOX.DAT 14F2000h 9F800h B054800h ; MagDemo13/MagDemo44 only)
+ VOX.SYM 988h - - ;/
+ BRF.DAT - 66800h 575800h ;\whatever, unknown format(s)
+ RADIO.DAT 16CB8h 3Dh (txt) 1AA956h ;/
+ 000h 4 Size of File List (N*0Ch)
+ 004h N*0Ch Folder List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. Folder Data
+ Folder List entries:
+ 000h 8 Foldername (zeropadded if less than 8 chars) ;nickname=stg
+ 008h 4 Offset/800h to File List
+ Folder Data (per folder):
+ 000h 2 Unknown (always 1) (maybe File List size/800h?)
+ 002h 2 Folder Size/800h (of whole folder, with file list plus file data)
+ 004h N*8 File List
+ ... Zeropadding to 800h-byte
+ 800h Data (for files in current folder)
+ File List entries:
+ 000h 2 File ID (checksum on name)
+ 002h 1 File Family (one of following chars: "cnrs")
+ 003h 1 File Type (one of following chars: "abcdeghiklmoprswz",FFh)
+ 004h 4 File Size (or File Offset, when File Family="c")
+ .?a ???? if any ???? (does NOT exist on PAL disc 1) ;nickname=azm
+ .sb MIPS binary code (leading) ;nickname=bin
+ .cc Whatever (eg. vr10\*, s01a\*) ;nickname=con
+ .nd Texture Archive (leading) (contains PCX files) ;nickname=dar
+ .rd Misc Archive (leading) (eg. init\*) ;nickname=dar
+ .se Sound Effects? (trailing) ;nickname=efx
+ .cg Whatever, reportedly bytecode functions ;nickname=gcx
+ .ch Whatever ;nickname=hzm
+ .ci Whatever (eg. ending\*, s01a\*) ;nickname=img
+ .ck Whatever, model? aka "pat_xxx" files ;nickname=kmd
+ .cl Lights, first word = size/10h ;nickname=lit
+ .sm Sound Music? Nested DOT1+DOTLESS Archives ;nickname=mt3
+ .co Whatever "OARa" (eg. d16e\*, s00a\*, s02c\*) ;nickname=oar
+ .cp PCX bitmap (eg. init\*) ;nickname=pcc
+ .cr Whatever "sNRJ1F" (eg. roll\*) ;nickname=rar
+ .cs Whatever (eg. d16e\*, s01a\*) ;nickname=sgt
+ .sw Wave Archive (trailing) ;nickname=wvx
+ .cz Whatever "KMDa" (eg. s11a, a11c, s14e, s15a) ;nickname=zmd
+ .c,FFh End of Family="c" area ;nickname=dar?
+This contains several large blocks (supposedly one per stage, each block having
+its own file list). There is no directory to find the begin of the separate
+blocks, but one can slowly crawl through the file:
+
NextBlock = CurrBlock + 4 + Offset(lastfile)+Size(lastfile) + Align800h
+ 000h 4 Number of Files in this block (eg. 19h or 1Ch)
+ 004h N*0Ch File List for this block
+ ... .. File Data for this block
+ ... .. Zeropadding to 800h-byte boundary (followed by next block, if any)
+ File List entries:
+ 000h 2 File Type (0=Main/Eye/Mouth frames, 1=All frames are full size)
+ 002h 2 File ID (name checksum?)
+ 004h 4 Filesize in bytes
+ 008h 4 Offset in bytes, minus 4
+ This type use a single palette for all frames, and only the first frame is
+ full 52x89pix, the other frames contain only the update sections (eg. eyes).
+ 000h 4 Offset to 200h-byte palette (usually 20h) ;\Main
+ 004h 4 Offset to Main Bitmap (52x89pix) (usually 220h) ;/
+ 008h 4 Offset to 4th Bitmap (usually xxxxh or 0=None) ;\Eyes
+ 00Ch 4 Offset to 5th Bitmap (usually xxxxh or 0=None) ;/
+ 010h 4 Zero
+ 014h 4 Offset to 2nd Bitmap (usually 143Ch or 0=None) ;\Mouth
+ 018h 4 Offset to 3rd Bitmap (usually xxxxh or 0=None) ;/
+ 01Ch 4 Zero
+ 020h 200h Palette (256 colors) ;\Main
+ 220h 1218h Main Bitmap ;/
+ 1438h 4 Zero
+ 143Ch .. 2nd Bitmap (if any) ;\Mouth
+ ... .. 3rd Bitmap (if any) ;/
+ ... .. 4th Bitmap (if any) ;\Eyes
+ ... .. 5th Bitmap (if any) ;/
+ This type use separate palettes for each frame, all frames are full 52x89pix.
+ 000h 4 Number of frames
+ 004h N*0Ch Frame List
+ ... 200h 1st Frame Palette
+ ... 1218h 1st Frame Bitmap (52x89pix)
+ ... 4 ?
+ ... 200h 2nd Frame Palette
+ ... 1218h 2nd Frame Bitmap (52x89pix)
+ ... 4 ?
+ ... .. 3rd Frame ...
+ Frame List entries:
+ 000h 4 Offset to Palette
+ 004h 4 Offset to Bitmap (usually at Palette+200h)
+ 008h 4 Unknown (often 000x000xh)
+ 000h 1 Offset X (always 00h in Main Bitmap)
+ 001h 1 Offset Y (always 00h in Main Bitmap)
+ 002h 1 Width (always 34h in Main Bitmap, or less in 2nd-5th bitmap)
+ 003h 1 Height (always 59h in Main Bitmap, or less in 2nd-5th bitmap)
+ 004h .. Bitmap Pixels at 8bpp (Width*Height bytes)
+The .DAT files contain several huge blocks, found on 800h-boundaries starting
+with:
+
10 08 00 00 0x 00 00 00 ..
+ "0xNNNNNNNN name",0Ah
+Whatever, contains chunks with text messages, chunks are about as so:
+
000h 4 Unknown (eg. 36h,BFh,5Eh,00h)
+ 004h 4 Unknown (eg. 03h,13h,00h,00h)
+ 008h 1 Unknown (eg. 80h)
+ 009h 2 Chunk Size (eg. 0xh,xxh) ;big-endian
+ .. .. Chunk Data (Chunk Size-2 bytes) (binary stuff, and text strings)
+Contains several "folders" in this format:
+
000h 4 Number of files in this folder
+ 004h .. File(s)
+ ... .. 01h-padding to 800h-byte boundary
+ Files have this format:
+ 000h .. Filename ("name.pll",00h)
+ ... .. Zeropadding to 4-byte boundary (aligned to begin of BRF.DAT)
+ ... 4 File data size (usually a multiple of 4)
+ ... .. File data
+ ... 1 Zero (00h)
+ 000h .. PCX file (starting with 0A,05,01,01 or 0A,05,01,08)
+ ... .. 01h-padding to 800h-byte boundary
+CDROM File Video Streaming STR Variants
This is the first file in most folders (except "init*" folders).
+The file contains MIPS binary program code. And, there are ascii strings near
+end of .sb files, which include filenames, alike:
+
"name.c",00h + garbage-padding to 4-byte boundary ;<-- maybe source code?
+ "pat_lamp",00h + zero- padding to 4-byte boundary ;<-- name for File ID !
+MGS is using customized/corrupted PCX files as standard texture format (in
+STAGE.DIR\\.cp, STAGE.DIR\\.nd\.p, and BRF.DAT\).
+For details on PCX format (and MGS-specific customizations), see:
+CDROM File Video Texture/Bitmap (PCX)
+Apart from PCX, there's also custom texture format for animated bitmaps (in
+FACE.DAT), and a few TIM images (in STAGE.DIR\init*\.rd\.r)
These archives contain several chunks in following format:
+
000h 2 File ID (checksum on name?)
+ 002h 1 File Type (one of following chars: "p" for .nd, or "kors" for .rd)
+ 003h 1 Zero (00h)
+ 004h 4 Chunk Size (rounded to 4-byte boundary)
+ 008h .. Chunk Data
+ .p PCX bitmap ;-in *\*.nd archives
+ .k Whatever ;\
+ .o Whatever "OARa" ; in init*\*.rd archives
+ .a Whatever ;
+ .r Misc (TIM and other stuff) ;/
+There can be one or more .sw files per stage folder (eg. two sw's in
+"vr*\*.sw").
+
000h 4 Unknown (800h or C00h) ;big-endian
+ 004h 4 Size of File List (N*10h) ;big-endian
+ 008h 8 Zerofilled
+ 010h N*10h File List (xx,xx,xx,00,00,00,00,7F,00,00,00,0F,00,19,0A,00)
+ ... 4 Unknown (40000h or 60000h) ;big-endian
+ ... 4 Size of SPU-ADPCM Data area ;big-endian
+ ... 8 Zerofilled
+ ... .. SPU-ADPCM Data area (indexed from File List)
+ File List entries:
+ 000h 4 Offset+Flags ;little-endian!
+ bit0-16 Offset (from begin of SPU-ADPCM Data area)
+ bit17 Unknown (0 or 1)
+ bit18 Unknown (1)
+ bit19-31 Unknown (0)
+ 004h 12 Whatever (always 00,00,00,7F,00,00,00,0F,00,19,0A,00)
+ 000h 80h*10h List (unused entries are 1x00000000h,3xFFFFFFFFh)
+ 800h .. Data (whatever, usually 14h or more bytes per list entry)
+ List entries:
+ 000h 1 Unknown (eg. 01h,10h,20h,A0h,80h,FFh) ;\
+ 001h 1 Number of Voices? (1..3) ; all zero for
+ 002h 1 Unknown (1 or 0) ; unused list entries
+ 003h 1 Unknown (2 or 0 or 1) ;/
+ 004h 4 Offset-800h for 1st Voice? ;-FFFFFFFFh=Unused
+ 008h 4 Offset-800h for 2nd Voice? (if any) ;-FFFFFFFFh=Unused
+ 00Ch 4 Offset-800h for 3rd Voice? (if any) ;-FFFFFFFFh=Unused
+ Data:
+ Seems to contain 4-byte entries (last entry being 00,00,FE,FF).
+This does resemble a DOT1 Parent archive with 1-4 DOTLESS Child archives.
+Except, the offsets in Child archives are counted from begin of Parent archive.
+
Data:
+ Seems to contain 4-byte entries (last entry being 00,00,FE,FF).
+File IDs in STAGE.DIR (and maybe elsewhere, too) are computed as so:
+
sum=0,
+ for i=0 to len(filename)-1
+ sum=sum*20h+filename[i] ;\or so, 16bit overflows might be
+ sum=(sum+sum/10000h) AND FFFFh ;/cropped slightly differently
+ 000h 4 Zero
+ 004h 4 Number of Entries (503h)
+ 008h 4 Zero
+ 00Ch 4 Random
+ 010h 10h Zero
+ 020h N*10h File List
+ ... .. Zeropadding to 800h-byte boundary
+ ... .. Fild Data area
+ 000h 4 Offset/800h
+ 004h 4 Type (see below for info on different file types)
+ 008h 4 Filesize in bytes
+ 00Ch 4 Random (or 0 when Filesize=0)
+ Type=00000001h Cubemap ;\either one of these
+ Type=00000040h Cubemap.empty ;/
+ Type=00000020h Cubemap.overlay? ;\these have size=0 when unused
+ Type=00000400h Cubemap.sounds ;/
+ Type=00000000h Archive with TIMs (Size=AB74h) (" RSC3.1V")
+ Type=00000004h Unknown (Size=16164h) (00000064h)
+ Type=00000008h Related to DRACULA1.STR (Size=1000h) (" RTS1.1V")
+ Type=00001000h Unknown (Size=2000h) ("BXFS1.1V")
+ Type=00008000h Unknown (Size=71Dh) (" CM1.1V")
+ Type=00020000h Unknown (Size=3B9h) (" GSM0.1V")
+ Type=02000000h Unknown (Size=0h) (empty)
+ Type=00000100h Related to DRACULA1.XA (Size=1000h) ("RAAX1.1V")
+ Type=00000010h Unknown (Size=450h) (" HYP0.1V")
+ Type=00100000h Unknown (Size=4014h) (" xFS1.1V") (x=A1h)
+ Type=00000080h Unknown (Size=258F4h) (00000010h)
+ Type=00000200h TIM (gui charset) (Size=6E9Eh) (TIM)
+ Type=00010000h TIM (gui buttons) (Size=10220h) (TIM)
+ Type=00040000h Unknown (Size=2C4h) (" TES0.1V")
+ Type=00002000h TIM (gui book pages) (Size=1040h) (TIM)
+ Type=00000800h Cubemap ;\as Type 01h, (Size=4092Ch) (" RIV3.1V")
+ Type=00004000h Cubemap ;/but [10h,14h]=0 (Size=4092Ch) (" RIV3.1V", too)
+ 000h 8 Name, ASCII, padded with leading spaces (eg. " RIV3.1V")
+ 008h 4 Something (0, 1 or 2) (unknown, this isn't number of list entries)
+ 00Ch 4 Zero
+ 010h 4 Offset to Ext data (ACh) ;\ext data
+ 014h 4 Size of Ext data (eg. 0 or 84h) ;/
+ 018h 6*4 Offsets to Side 0-5 ;\cubemap sides
+ 030h 6*4 Sizes of Side 0-5 (0, 10220h, or 10820h) ;/
+ 048h 44h Zerofilled
+ 08Ch 20h Name, ASCII (eg. "DEBUT0.VR", zeropadded)
+ 0ACh .. Ext Data (if any)
+ ... .. Cubemap TIM sides (if any)
+ Note: The cubemap TIMs have 100h or 400h colors (in the latter case: 100h colors for each quarter of the 8bpp bitmap).
+ Note: The TIMs can be arranged as 3D-cubemap with six sides, or as hires
+ 2D-bitmap (composed of four TIMs, and 2 empty TIMs with size=0).
+ Same as Type 01h, but size is always 0ACh (and all seven Size entries are 0)
+ 000h 8 Name, ASCII, padded with leading spaces (eg. " XFS0.1V")
+ 008h 4 Zero
+ 00Ch 4 Number of Files (N) (max 10h)
+ 010h N*10h File List (100h bytes, zeropadded when less than 10h files)
+ 110h .. File Data (VAG files)
+ File List entries:
+ 000h 4 Unknown (55F0h, 255F0h or 20000h)
+ 004h 4 File ID (01010000h, increasing, or other when above=2xxxxh)
+ 008h 4 Offset in bytes ;\.VAG files
+ 00Ch 4 Filesize in bytes ;/
+ 000h 8 Name, ASCII, padded with leading dot (eg. ".MNA4.1V")
+ 008h 4 Zero
+ 00Ch 4 Random
+ 010h 4 Unknown 01h
+ 014h 4 Total Number of 40h-byte blocks (01h..[018h]) (H)
+ 018h 4 Total Number of 120h-byte blocks (eg. 1Fh,31h) (N)
+ 01Ch 4 Total Number of 1Ch-byte blocks (eg. 1Eh, 50h, F7h) (M)
+ 020h 4 Unknown 0 or 1 (in file 4EAh)
+ 024h 4 Unknown 01h
+ 028h 6*4 Offsets to Side 0-5 (at end of file and up) (or 0) ;\cubemap
+ 040h 6*4 Sizes of Side 0-5 (10220h, or 10820h) (or 0) ;/sides
+ 058h H*40h 40h-byte blocks
+ ... N*120h 120h-byte blocks (related to offsets in 40h-byte blocks)
+ ... M*1Ch 1Ch-byte blocks (related to offsets in 120h-byte blocks)
+ ... .. Unknown data (related to offsets in 1Ch-byte blocks)
+ ... .. Ext data (related to Ext offsets in 40h-byte blocks)
+ FILE DOES END HERE!
+ (below is allocated in above header, but not actually stored in the file)
+ (maybe allocated as rendering buffer?)
+ ... - Cubemap TIM sides
+ The 40h-byte blocks are:
+ 000h 20h Name (eg. "FLAMMES", zeropadded)
+ 020h 4 Unknown 01h or 00h
+ 024h 4 Offset to 120h-byte blocks (usually 98h, or higher)
+ 028h 4 Unknown 00h
+ 02Ch 4 Number of 120h-byte blocks (01h..[018h])
+ 030h 4 Unknown 01h
+ 034h 4 Ext Offset ;\usually all zero
+ 038h 4 Ext Size (3C000h) ; (except, nonzero in file 4EAh)
+ 03Ch 4 Ext Random (checksum?) ;/
+ The 120h-byte blocks are:
+ 000h 18h*4 List with Offsets to 1Ch-byte blocks (usually 4 entries nonzero)
+ 060h 18h*4 List with Zeroes
+ 0C0h 18h*4 List with Numbers of 1Ch-byte blocks (usually max 4 entries)
+ The 1Ch-byte blocks are:
+ 000h 4 Unknown 04h
+ 004h 4 Width 20h or 10h
+ 008h 4 Height 20h or 10h or 30h
+ 00Ch 4 Unknown 60h or 10h
+ 010h 4 Unknown 00h or 30h
+ 014h 4 Offset to Unknown Data
+ 018h 4 Size of Unknown Data (Width*Height*1)
+ 000h 8 Name (" RSC3.1V")
+ 008h 8 Zerofilled
+ 010h 4 Number of used entries (1Fh) (max 80h)
+ 014h 80h*4 Offset List (offsets to files) (A14h and up)
+ 214h 80h*4 Zero List (zerofilled)
+ 414h 80h*4 Size List (filesizes)
+ 614h 80h*4 Width List (0Ch,18h,34h,2Ch) (in pixels)
+ 814h 80h*4 Height List (0Ch,24h,34h,2Ch)
+ A14h .. Data (TIM files, with mouse pointers)
+CROCFILE.DIR and CROCFILE.1:
+
CROCFILE.DIR:
+ 000h 4 Number of Entries (N)
+ 004h N*18h File List
+ ... 4 Checksum (sum of all of the above bytes)
+ CROCFILE.1:
+ 000h .. File Data (referenced from .DIR)
+ File List entries:
+ 000h 0Ch Filename ("FILENAME.EXT", zeropadded if shorter)
+ 00Ch 4 File Size in bytes (can be odd) (including 8 byte for size/chksum)
+ 010h 4 File Offset in .1 file (unaligned, can be odd, increasing)
+ 014h 4 Zero (0)
+ 000h 4 Size-8 of whole file (or Size-0 for those in MP*.WAD)
+ 004h 4 Flags? (usually 0Ch or 14h)
+ 008h 1 Filename length (including trailing 00h, if any)
+ 009h .. Filename ("P:\CROC\EDITOR\MAPS\..\*.MAP") (+00h in MAP05*.WAD)
+ ... .. Unknown
+ ... 1 Description length
+ ... .. Description (eg. "Default New Map")
+ ... .. Unknown
+ ... (4) Checksum of whole file (sum of all bytes) (not in MP*.WAD)
+ MAP*.WAD:
+ 000h 4 Size-8 of whole file
+ 004h .. MAP file(s) (each with size/checksum, same format as MP*.MAP)
+ ... 4 Checksum of whole file (sum of all of the above bytes)
+ CROC.WAD, CROCSLID.WAD, EXCLUDE.WAD, MP*.WAD, OPTIONS.WAD, SWIMCROC.WAD:
+ 000h 4 Size-8 of whole file
+ 004h 4 Offset-8 to SPU-ADPCM data area
+ 008h .. Data File area (model.MOD anim.ANI, bytecode.BIN, header.CVG, etc.)
+ ... .. SPU-ADPCM data area (if any, note in CROCSLID.WAD and OPTIONS.WAD)
+ The Data File area contains several "files" but doesn't have any directory
+ with filename/offset/size. The only way to find the separate files seems to
+ be to detect the type/filesize of each file, and then advance to next file
+ (bytecode.BIN files start with a size entry, but files like .MOD or .ANI
+ require parsing their fileheader for computing filesize).
+ Note: The PC version reportedly has .WAD files bundled with .IDX file (that
+ makes it easier to find files and filenames).
+ Note: The STRAT.DIR file contains a list of filenames used in .WAD files
+ (but lacks info on offset/size, so it isn't really useful).
+ Sound.BIN Files (CROCFILE.DIR\AMBI*.BIN, MAP*.BIN, JRHYTHM.BIN, REVERB.BIN):
+ 000h 4 Size of .SEQ file ;\if any (not in REVERB.BIN)
+ 004h .. SEQ file (starting with ID "pQES") ;/
+ ... 4 Size of .VH file ;\always present
+ ... .. VH file (starting with ID "pBAV") ;/
+ ... .. VB file (sample data, SPU-ADPCM data, up to end of file)
+ Music.BIN files (MAGMUS.BIN, MUSIC.BIN):
+ 000h 4 Size-8 of whole file (118h)
+ 004h .. Increasing 32bit values ;sector numbers in PACK*.STR files or so?
+ ... 4 Unknown (2EEh or 258h) (aka 750 or 600 decimal)
+ ... .. Zeropadding
+ 11Ch 4 Checksum (sum of all of the above bytes)
+ Note: MUSIC.BIN has an extra copy (without chksum) in EXCLUDE.WAD\MUSIC.BIN
+ Ascii.BIN files (CREDITS*.BIN, MNAME.BIN):
+ 000h 4 Size-8 of whole file
+ 004h (2) Type or so? (02h,01h) (only in CREDITS*.BIN, not in MNAME.BIN)
+ ... .. Ascii strings (each string is: len,"text string",unknown)
+ ... 4 Checksum (sum of all of the above bytes)
+ Texture.BIN files (type 4) (STILLGO.BIN, STILLST.BIN, STILLTL.BIN):
+ 000h 2 Type (4=Texture/uncompressed, with 0Eh-byte list entries)
+ 002h 1 Zero (maybe Extra6byte as in type 5,6 Texture.BIN files)
+ 003h 2 Number of List entries (N) (always 4B0h in all three files)
+ 005h 2 Number of Texture Pages (usually 2)
+ 007h 2 Zero (maybe Unknown/Animation as in type 5,6 Texture.BIN files)
+ 009h N*0Eh Polygon List (?,?,?,?,?,?, x1,y1, x2,y1, x1,y2, x2,y2)
+ ... 40000h Texture Page uncompressed data (two pages, 20000h bytes each)
+ ... 4 Checksum (sum of all of the above bytes)
+ Texture.BIN files (type 5,6) (ENDTEXT*.BIN, FONT.BIN, FRONTEND.BIN,
+ OUTRO.BIN, PUBLISH.BIN, STILL*.BIN, TB*.BIN, TK*.BIN, TPAGE213.BIN):
+ 000h 4 Zero (0) (in TPAGE213.BIN: Size-8 of whole file)
+ 004h 2 Type (6=Texture/RLE16) (in TPAGE213.BIN: 5=Texture/uncompressed)
+ 006h 1 Extra6byte flag/size (0=None, 3=Extra6byte: TB*.BIN, TPAGE*.BIN)
+ ... (6) Extra6byte data (unknown purpose, only present when [006h]=3)
+ ... 2 Number of Polygon List entries (N)
+ ... 2 Number of Texture Pages (usually 1) (in TK*_ENM.BIN: usually 2)
+ ... 2 Number of Unknown Blocks (0=None, or 1,2,4,8)
+ ... (..) Unknown Block(s), if any
+ ... 2 Number of Animation Blocks (0=None)
+ ... (..) Animation Block(s), if any
+ ... N*0Ch Polygon List (?,?,?,?, x1,y1, x2,y1, x1,y2, x2,y2) ;x,y or y,x?
+ ... (4) Texture Page compressed size (T1) ;\only when [004h]=Type=6
+ ... (T1) Texture Page compressed data ;/
+ ... (4) Texture Page compressed size (T2) ;\only when [004h]=Type=6
+ ... (T2) Texture Page compressed data ;/ and NumPages=2
+ ... 20000h Texture Page uncompressed data ;-only when [004h]=Type=5
+ ... 4 Checksum (sum of all of the above bytes)
+ Unknown Block(s):
+ (Unknown purpose, each Unknown Block has the format shown below)
+ 000h 2 Unknown (looks like some index value, different for each entry)
+ 002h 2 Number of Unknown Items (eg. 1 or 2 or 4)
+ 004h .. Unknown Items (NumItems*6 bytes) (three halfwords each?)
+ Animation Block(s):
+ (This is supposedly used to update portions of the Texture Page for
+ animated textures, each Animation Block has the format shown below)
+ 000h 2 Number of Bitmap Frames in this Animation (usually 8)
+ 002h 2 Bitmap Width (in halfword units)
+ 004h 2 Bitmap Height
+ 006h 2 Unknown (1 or 3) ;\
+ 008h 2 Unknown (C10h, CC8h, 1E8h, or xxxh) ; maybe vram X,Y address?
+ 00Ah 2 Unknown (0) ;/
+ 00Ch .. Bitmap Frames (Width*2*Height*NumFrames bytes, uncompressed)
+ Croc 1 RLE16 compression:
+ This is using unsigned little-endian 16bit LEN/DATA pairs, LEN can be:
+ 0000h..7FFFh --> Load one halfword, fill 1..8000h halfwords
+ 8000h..FFFFh --> Copy 1..8000h uncompressed halfwords
+ BUG: Texture pages should be 20000h bytes (256x256 halfwords), but for
+ whatever reason, the size of decompressed data can be 1FFEAh, 1FFF0h,
+ 1FFFAh, 20000h, or 20002h.
+ Bytecode.BIN (inside of .WAD files):
+ 000h 4 Size of whole file
+ 004h .. Whatever bytecode (starting with initial 16bit program counter?)
+ Unknown.BIN (last 1-2 file(s) in EXCLUDE.WAD file):
+ 000h 4 Number of entries (N)
+ 004h N*18h Whatever
+ ... 4 Checksum (sum of above bytes)
+ Unknown purpose, retail version has one such file (with 0Ah entries), demo
+ version has two such files (with 0Ah and 4Eh entries. The files start with:
+ 0A,00,00,00,00,00,00,00,00,00,64,00,00,00,EB,FF,... ;demo+retail
+ 4E,00,00,00,00,00,64,00,00,00,50,00,00,00,64,00,... ;demo
+ Demo version has one .MOD file in CROCFILE.DIR (retail has more such files):
+ 000h 2 Number of Models (N) (1 or more) (up to ECh exists) ;\header
+ 002h 2 Flags (0 or 1) ;/
+ 004h N*Var SubHeadersWithData ;see below ;-data
+ ... 4 Checksum (sum of all of the above bytes) ;-checksum
+ SubHeadersWithData(N*Var):
+ 004h 4 Radius ;\
+ 008h 48h Bounding Box[9*8] (each 8byte are 4x16bit: X,Y,Z,0) ; for each
+ 050h 4 Number of Vertices (V) ; model
+ 054h V*8 Vectors (4x16bit: X,Y,Z,0) ;
+ ... V*8 Normals (4x16bit: X,Y,Z,0) ;
+ ... 4 Number of Faces (F) (aka Polygons?) ;
+ ... F*14h Faces (8x16bit+4x8bit: X,Y,Z,0,V1,V2,V3,V4, Tex/RGB) ;
+ ... 2 Number of collision info 1? (X) ;\ ;
+ ... 2 Number of collision info 2? (Y) ; only if ;
+ ... X*2Ch Collision info 1? ; Flags.bit0=1 ;
+ ... Y*2Ch Collision info 2? ;/ ;/
+ There are further .MOD models inside of .WAD files, with slightly
+ re-arranged entries (and additional reserved/garbage fields):
+ 000h 2 Number of Models (N) (1 or more) (up to ECh exists) ;\
+ 002h 2 Flags (0 or 1) ; header
+ 004h 4 Reserved/garbage (usually 224460h) (or 22C9F4h/22DF54h) ;/
+ 008h (4) Number of Models WITH Data arrays (M) ;\
+ 00Ch (M*2) Model Numbers WITH Data arrays (increasing, 0..N-1) ; ext.hdr
+ ... (..) Padding to 4-byte boundary (garbage, usually=M) ;/
+ ... N*68h Subheader(s) ;see below ;-part 1
+ ... N*Var DataArray(s) ;see below ;-part 2
+ Subheaders(N*68h):
+ 000h 4 Radius ;\
+ 004h 48h Bounding Box[9*8] (each 8byte are 4x16bit: X,Y,Z,0) ; for each
+ 04Ch 4 Number of Vertices (V) ; model
+ 050h 4 Reserved/garbage (usually 0022xxxxh) ;
+ 054h 4 Reserved/garbage (usually 0022xxxxh) ;
+ 058h 4 Number of Faces (F) (aka Polygons?) ;
+ 05Ch 4 Reserved/garbage (usually 0022xxxxh) ;
+ 060h 2 Number of collision info1? (X) ;
+ 062h 2 Number of collision info2? (Y) ;
+ 064h 4 Reserved/garbage (usually 0022xxxxh) or xxxxxxxxh) ;/
+ DataArrays(N*Var) with sizes V,F,X,Y from corresponding Subheader:
+ (if ext.hdr is present, then below exists only for models listed in ext.hdr)
+ 000h V*8 Vectors (4x16bit: X,Y,Z,0) ;\
+ ... V*8 Normals (4x16bit: X,Y,Z,0) ; for each
+ ... F*14h Faces (8x16bit+4x8bit: X,Y,Z,0,V1,V2,V3,V4, Tex/RGB) ; model
+ ... X*2Ch Collision info 1? ;
+ ... Y*2Ch Collision info 2? ;/
+ The ext.hdr mentioned above exists only in some .MOD files (usually in one of
+ the last chunks of MP*.WAD). Files with ext.hdr have N>1, Flags=1 (but files
+ without ext.hdr can also have those settings). Files with ext.hdr do usually
+ have uncommon garbage values at hdr[4], which isn't too helpful for detection.
+ The only way to detect models with ext.hdr seems to be to check if the ext.hdr
+ contains valid increasing entries in range 0..N-1.
+ WAD's that do contain a model with ext.hdr do usually also contain an extra
+ 100h-byte file, that file contains N bytes for model 0..N-1 (plus zeropadding
+ to 100h-byte size), the bytes are supposedly redirecting models without Data
+ Arrays to some other data source.
+ The 100h-byte files don't have any header or checksum, they contain up to 9Ch
+ entries (so there's always some zeropadding to 100h), the existing 100h-byte
+ files contain following values in first 4 bytes (as 32bit value):
+ 04141401h, 0C040017h, 01010101h, 09030503h, 0A0B0A0Bh, 03020102h, 0C060900h,
+ 00060501h, 04040201h, 01010203h, 01030201h, 05000302h, 0C040317h, or Zero.
+ To distinguish from other files: BIN/MAP files start with a 4-byte aligned
+ Size value; if Size=0 or (Size AND 3)>0 or Size>RemainingSize then it's
+ probably a 100h-byte file. Best also check if last some bytes are zeropadded.
+ Exceptions:
+ Retail MP090..MP100_*.WAD has model with ext.hdr, but no 100h-byte file
+ Demo MP041_00.WAD has model with ext.hdr, with zerofilled 100h-byte file
+ Note: Some models have ALL models listed in ext.hdr (which is about same as
+ not having any ext.hdr at all; except, they ARE bundled with 100h-byte file).
+ Some (not all) MP*.WAD files are bundled with MP*.DEM files, supposedly
+ containing data for demonstration mode. There are two versions:
+ demo version: size 2584h (9604 decimal) (some files with partial checksum)
+ retail version: size 0E10h (3600 decimal) (without checksum)
+ Animation data, there is only one such file in CROCFILE.DIR:
+ 000h 2 Value (100h)
+ 002h 2 Number of Triggers (T) (2)
+ 004h (T*2) Trigger List (with 2x8bit entries: FrameNo, TriggerID)
+ ... .. Probably, Padding to 4-byte boundary (when T=odd)
+ ... 4 Number of entries 1 (X)
+ ... X*18h Whatever Array 1
+ ... 4 Number of entries 2 (Y) (usually/always 64h)
+ ... X*Y*4 Whatever Array 2
+ ... 4 Number of entries 3 (Z) (usually/always 0Ah)
+ ... X*Z*18h Whatever Array 3
+ There are further .ANI files inside of .WAD files:
+ 000h 2 Value (100h or 200h) ;Animation Speed?
+ 002h 2 Number of Triggers (T) (0, 1, 2, 3, 5, or 9)
+ 004h 4 Garbage/Pointer (usually 224460h) (or zero)
+ 008h 4 Number of entries 1 (X) (1 or more) ;Num Frames
+ 00Ch 4 Garbage/Pointer (usually 22C9F4h) (or 224460h or 22DF54h)
+ 010h 4 Number of entries 2 (Y) (usually 64h) (or 0) ;Num Vertices (?)
+ 014h 4 Garbage/Pointer
+ 018h 4 Number of entries 3 (Z) (usually 0Ah) (or 6 or 9)
+ 01Ch 4 Garbage/Pointer
+ 020h (T*2) Trigger List (with 2x8bit entries: FrameNo, TriggerID)
+ ... .. Padding to 4-byte boundary (garbage, usually=X)
+ ... X*18h Whatever Array 1
+ ... X*4 Garbage/Pointers (0021EE74h,0021EE74h,xxx,...)
+ ... X*Y*4 Whatever Array 2 ;Vertex 3x10bit? ;only if Y>0
+ ... (X*4) Garbage/Pointers (0021EE74h,0021EE74h,xxx,...) ;only if Y>0
+ ... X*Z*18h Whatever Array 3
+ There is only one such file in CROCFILE.DIR:
+ 000h 4 Size-8 of whole file
+ 004h 4 Unknown (0)
+ 008h 4 Unknown (1)
+ 00Ch .. SPU-ADPCM data
+ ... 4 Checksum (sum of all of the above bytes)
+ There are further .CVG files inside of .WAD files, these consist of two
+ parts; 0Ch-byte Headers (in the data file area), and raw SPU-ADPCM data
+ (in the spu-adpcm data area at end of the .WAD file):
+ Header(0Ch):
+ 000h 4 Size+8 of data part
+ 004h 4 Unknown (0)
+ 008h 4 Unknown (0 or 1)
+ Data(xxxx0h):
+ 000h .. SPU-ADPCM data (starting with sixteen 00h bytes)
+ This file contains a list of filenames for files inside of .WAD files, but
+ it does NOT tell where those files are (in which WAD at which offset).
+ 000h 4 Number of Entries (N)
+ 004h N*xxh File List (retail=14h bytes, or demo=18h bytes per entry)
+ ... 4 Checksum (sum of all of the above bytes)
+ List entries are:
+ demo: entrysize=18h ;Filename(0Ch)+Size(4)+Zeroes(8)
+ retail: entrysize=14h ;Filename(0Ch)+ Zeroes(8)
+ The list contains hundreds of filenames, with following extensions:
+ *.BIN byte-code strategies
+ *.MOD models
+ *.ANI animations
+ *.CVG spu-adpcm voice data
+ These "filenames" seem to be actually solely used as "memory handle names":
+ MemoryHandle(#1) = LoadFile("FILENAME.BIN") ;<-- names NOT used like this
+ MemoryHandle("FILENAME.BIN") = LoadFile(#1) ;<-- names used like this
+ Huge files with XA-ADPCM audio data
+ Huge mis-mastered 24Mbyte file (contains several smaller XA-ADPCM blocks,
+ accidentally stored in 800h-byte FORM1 data sectors, instead of 914h-byte
+ FORM2 audio sectors).
+ MDEC movies
+ Raw bitmaps (25800h bytes, uncompressed, 320x240x16bpp)
+Overall .WAD format:
+
000h 4 Total Filesize+/-xx (-4 or +800h or +1800h)
+ 004h 4+4+.. XSPT Chunk ;Textures
+ ... 4+4+.. XSPS Chunk ;SPU-ADPCM Sound (if any, not in all .WAD's)
+ ... 4+4+.. XSPD Chunk ;...whatever Data...?
+ ... 4+4 DNE Chunk ;End marker (in Harry Potter: with data!)
+ 000h 4 Chunk Name "XSPT" (aka TPSX backwards)
+ 004h 4 Chunk Size (excluding 8-byte Name+Size)
+ 008h 4 Chunk Flags (02h or 06h or 0Eh) ;02h in Croc 2
+ 00Ch (20h) Name (eg. "Default new map", zeropadded) ;\if Flags bit2=1
+ ... (804h) Unknown ... SAME as in XSPD chunk !!! ;/
+ ... 4 Number of List 1 entries (N1) (xxh..xxxh) ;\
+ ... 4 Number of Texture Pages (1..4) ; List 1 and NumPages
+ ... N1*0Ch List 1 Whatever (6B 2F xx 00..) ;/
+ ... 4 Number of List 2 entries (N2) (0..xxh) ;\
+ ... 4 Unknown (2 or 7) ; List 2
+ ... N2*04h List 2 Whatever (halfwords?) (if N2>0) ;/
+ ... (5*C00h) Whatever, 5*C00h, Palette+Stuff? ;-if Flags bit3=1
+ ... .. RLE16 compressed Texture Pages ;-Texture bitmap
+ RLE16 Texture notes:
+ Compressed data consists of signed little-endian 16bit LEN+DATA pairs:
+ LEN=0000h --> invalid/unused
+ LEN=0001h..7FFFh --> copy LEN halfwords from src
+ LEN=8000h..FFFFh --> load ONE halfword as fillvalue, fill -LEN halfwords
+ Compressed size is everything up to end of XSPT chunk
+ Decompressed size is 20000h*NumTexturePages (=20000h,40000h,60000h or 80000h)
+ That is: Width=256 halfwords, height 256*NumTexturePages lines. There seems
+ to be only one RLE16 compression block for all Texture Pages, rather than one
+ RLE16 block for each Page.
+ BUG #1: Decompressed data in Aladding/Emperor does often contain only
+ 1FFFEh,3FFFEh,5FFFEh,7FFFEh bytes (the decompressed data has correct size
+ when appending ONE halfword with random/zero value).
+ BUG #2: Compressed data in Croc 2 ends with a RLE16 length value (-LEN), but
+ lacks the corresponding RLE16 filldata (the decompressed data is 7FFFEh when
+ filling those LEN halfwords with random/zero values).
+ 000h 4 Chunk Name "XSPS" (aka SPSX backwards) ;\
+ 004h 4 Chunk Size (excluding 8-byte Name+Size) ; header
+ 008h 4 Chunk Flags (0 or 3 or 7) ;/
+ 00Ch 4 Number of Sounds (N1) (1..xxh) ;\always present
+ 010h N1*14h Sound List ;/
+ ... (4) VAB/VH Size ;\if Flags=3 or 7
+ ... (..) VAB/VH Header ;/ (bit0 or bit1?)
+ ... (4) Unknown (2 or 4) ;-if Flags=3 or 7
+ ... (4) Whut (N2) ;\if Flags.bit2=1
+ ... (N2*10h) Whut List (4 words: xxh,10h,xxxx00h,xxxx0h);/
+ ... 4 Size of all Part 1 Sound Data blocks ;\always
+ ... .. SPU-ADPCM Sound Data (referenced from Sound List) ;/
+ ... (4) Size of all Part 2 Sound Data blocks (+8) ;\if Flags=
+ ... (..) SPU-ADPCM Sound Data (referenced from Sound List?) ; 3 or 7
+ ... (8) Zero ;/
+ Sound List entries (as in FESOUND.WAD):
+ 000h 4 Sample Rate in Hertz (AC44h=44100Hz, 5622h=22050Hz, 3E80h=16000Hz)
+ 004h 2 Sample Rate Pitch (1000h=44100Hz, 0800h=22050Hz, 05CEh=16000Hz)
+ 006h 2 Unknown (7Fh)
+ 008h 4 Unknown (1) (1) (8)
+ 00Ch 4 Unknown (42008Fh) (1FC0001Fh) (40008Fh)
+ 010h 4 Filesize (xxx0h) (xxx0h)
+ 000h 4 Chunk Name "XSPD" (aka DPSX backwards)
+ 004h 4 Chunk Size (excluding 8-byte Name+Size)
+ 008h 4 Flags-and/or-other stuff ? (eg. 00000094h or 0A801094h)
+ 00Ch 804h Unknown ... SAME as in XSPT chunk !!!
+ 810h .. Unknown ...
+ 000h 4 Chunk Name " DNE" (aka END backwards)
+ 004h 4 Chunk Size (0) (except, in Harry Potter: nonzero)
+ ... .. Data (usually none such) (except, in Harry Potter: with data!)
+ 000h 4 Number of entries (N) (always 2EEh, aka 750 decimal)
+ 004h N*8 Whatever entries... maybe data for demonstration mode?
+Some games use files that contain several files badged together. For example,
+
PSX Resident Evil 2, COMMON\DATA\*.DIE contains TIM+VAB badged together
+ PSX Resident Evil 2, COMMON\DATA\*.ITP contains 1000h-byte aligned TIMs
+ Blaster Master, DATA\MENU\*\*.PRT contains three smaller TIMs badged together
+ Blaster Master, DATA\MENU\*\*.BG contains three bigger TIMs badged together
+ Misadventures of Tron Bonne, KATWA\*.BIN contains headerless archives (with TIMs and audio)
+ Headerless BSS files contain several BS files with huge padding inbetween
+ .BS used by several games (and also in most .STR videos)
+ .GIF used by Lightspan Online Connection CD
+ .JPG used by Lightspan Online Connection CD
+ .BMP with RLE4 used by Lightspan Online Connection CD (MONOFONT, PROPFONT)
+ .BMP with RLE8+Delta also used by Online Connection CD (PROPFONT\ARIA6.BMP)
+ .PCX with RLE used by Jampack Vol. 1 (MDK\CD.HED\*.pcx)
+ .PCX with RLE used by Hot Wheels Extreme Racing (MagDemo52: US_01293\MISC\*)
+ .PCX with RLE used by Metal Gear Solid (slightly corrupted PCX files)
+ .XA uses XA-ADPCM (and also used in .STR videos)
+ .VAG .VB .VAB uses SPU-ADPCM
+CDROM File Compression LZSS (Moto Racer 1 and 2)
+CDROM File Compression LZSS (Dino Crisis 1 and 2)
+CDROM File Compression LZSS (Serial Experiments Lain)
+CDROM File Compression ZOO/LZSS
+CDROM File Compression Ulz/ULZ (Namco)
+CDROM File Compression SLZ/01Z (chunk-based compressed archive)
+CDROM File Compression LZ5 and LZ5-variants
+CDROM File Compression PCK (Destruction Derby Raw)
+CDROM File Compression GT-ZIP (Gran Turismo 1 and 2)
+CDROM File Compression GT20 and PreGT20
+CDROM File Compression HornedLZ
+CDROM File Compression LZS (Gundam Battle Assault 2)
+CDROM File Compression BZZ
+CDROM File Compression RESOURCE (Star Wars Rebel Assault 2)
+CDROM File Compression TIM-RLE4/RLE8
+CDROM File Compression RLE_16
+CDROM File Compression PIM/PRS (Legend of Mana)
+CDROM File Compression BPE (Byte Pair Encoding)
+CDROM File Compression RNC (Rob Northen Compression)
+CDROM File Compression Darkworks
+CDROM File Compression Blues
+CDROM File Compression Z (Running Wild)
+CDROM File Compression ZAL (Z-Axis)
+CDROM File Compression EA Methods
+CDROM File Compression ZIP/GZIP/ZLIB (Inflate/Deflate)
+CDROM File Compression LArc/LHarc/LHA (LZS/LZH)
+CDROM File Compression UPX
+CDROM File Compression LZMA
+CDROM File Compression FLAC audio
+Some other archvies that aren't used by any PSX games, but, anyways...
+CDROM File Compression ARJ
+CDROM File Compression ARC
+CDROM File Compression RAR
+CDROM File Compression ZOO
+CDROM File Compression nCompress.Z
+CDROM File Compression Octal Oddities (TAR, CPIO, RPM)
+CDROM File Compression MacBinary, BinHex, PackIt, StuffIt, Compact Pro
Some Archives have "built-in" compression.
+CDROM File Archive WAD (Doom)
+CDROM File Archive BIGFILE.DAT (Gex - Enter the Gecko)
000h 4 ID "LZSS"
+ 004h 4 Decompressed Size
+ 008h .. Compressed Data
+ @@collect_more:
+ flagbits=[src]+100h, src=src+1 ;8bit flags
+ @@decompress_lop:
+ flagbits=flagbits SHR 1
+ if zero then goto @@collect_more
+ if carry=1 then
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ disp=([src]+[src+1]*100h) AND 3FFh, len=([src+1]/4)+2_or_3, src=src+2
+ if disp=0 then goto @@decompress_done
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ endif
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+Dino Crisis LZSS Decompression for files with type 7 and 8:
+
@@collect_more:
+ flagbits=[src]+100h, src=src+1 ;8bit flags
+ @@decompress_lop:
+ flagbits=flagbits SHR 1
+ if zero then goto @@collect_more
+ if carry=1 then
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ disp=[src]+[src+1]*100h AND FFFh, len=[src+1]/10h+2, src=src+2
+ if disp=0 then error
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ endif
+ if src<src_end then goto @@decompress_lop
+ ret
+Serial Experiments Lain is using LZSS compression for TIMs (in SITEA.BIN,
+SITEN.BIN), and for Transparency Masks (in LAPKS.BIN).
These are huge 5-7 Mbyte files with hundreds of chunks. Each chunk contains one
+compressed TIM.
+
Each chunk is having this format:
+ 000h 4 Chunk ID "napk"
+ 004h 4 Decompressed size
+ 008h .. LZSS compressed TIM data
+ ... .. Zeropadding to 800h-byte boundary
+This a huge 14Mbyte file with 59 chunks. Each chunk contains one or more 24bpp
+.BS images with black background (the images in each chunk are forming a short
+animation sequence; width/height may vary because all images are cropped to
+rectangles containing non-black pixels).
+
Each chunk is having this format:
+ 000h 4 Chunk ID "lapk"
+ 004h 4 Chunk size (excluding 8-byte chunk header, excluding zeropadding)
+ 008h 4 Number of Files in this Chunk (N)
+ 00Ch N*0Ch File List
+ ... .. File Data (bitmaps in .BS v0 format with uncommon headers)
+ ... .. Zeropadding to 800h-byte boundary
+ File List entries:
+ 000h 4 Offset in bytes (zerobased, from begin of File Data area)
+ 004h 2 Bitmap Width/2 + some 3bit value in LSBs?
+ 006h 2 Bitmap Height
+ 00Ch 4 Zero
+ File Data (bitmaps in .BS v0 format with uncommon headers):
+ 000h 2 Bitmap Width
+ 002h 2 Bitmap Height
+ 004h 2 Quant for Y1,Y2,Y3,Y4
+ 006h 2 Quant for Cr,Cb
+ 008h 4 Size of compressed BS Bitstream plus 4 ;Transparency at [008h]+0Ch
+ 00Ch 2 Size/2 of MDEC data (after huffman decompression, without padding)
+ 00Eh 2 BS Version (0) (actually MSBs of above Size, but it's always 0)
+ 010h .. BS Bitstream with DC and AC values (Huffman compressed MDEC data)
+ ... 4 Transparency Mask Decompressed Size (Width*Height*2/8) (=2bpp)
+ ... .. Transparency Mask LZSS-compressed data
+This LZSS variant is unusually using 8bit len and 8bit disp.
+
dst_end=dst+[src], src=src+4 ;decompressed size
+ @@collect_more:
+ flagbits=([src] SHL 24)+800000h, src=src+1 ;8bit flags
+ @@decompress_lop:
+ if dst=dst_end then goto @@decompress_done
+ flagbits=flagbits SHL 1 ;32bit shift with carry-out/zeroflag
+ if zero then goto @@collect_more
+ if carry=0 then
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ disp=[src]+1, len=[src+1]+3, src=src+2
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ endif
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+ 0000h 4 Decompressed Size ;\1st sector
+ 0004h 7FCh Garbage ;/
+ 0800h 4 Decompressed Size (same as above) ;\2nd sector
+ 0804h 7FCh LZSS compressed data, part 1 ;/
+ 1000h 800h LZSS compressed data, part 2 ;-3rd sector
+ 1800h 800h LZSS compressed data, part 3 ;-4th sector
+ ... .. etc.
+ decompress_file:
+ if LittleEndian32bit[src+14h]=FDC4A7DCh then goto error ;refuse ZOO archives
+ if LittleEndian32bit[src]<>LittleEndian32bit[src+800h] then goto error
+ curr=src+800h
+ src=curr+4
+ @@sector_lop:
+ call decompress_sector
+ curr=curr+800h
+ src=curr
+ if src<src_end then goto @@sector_lop
+ ret
+ ;---
+ decompress_sector:
+ @@collect_more:
+ flagbits=([src] SHL 24)+800000h, src=src+1 ;8bit flags
+ @@decompress_lop:
+ flagbits=flagbits SHL 1 ;32bit shift with carry-out/zeroflag
+ if zero then goto @@collect_more
+ if carry=0 then
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ disp=[src]*100h+[src+1], src=src+2
+ if disp=FFFFh then goto @@decompress_done
+ len=(disp/800h)+3, disp=(disp AND 7FFh)+1
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ endif
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+Ulz/ULZ uses fairly normal LZSS compression, unusually with variable Len/Disp
+ratio, three separate data streams (flg/lz/dta), and rather weird end check in
+version=0.
000h 4 ID ("Ulz",1Ah) (parts lowercase)
+ 004h 3 Decompressed Size in bytes
+ 007h 1 Version (0 or 2)
+ 008h 3 Offset to Uncompressed data <-- reportedly can be 0 in version=0?
+ 00Bh 1 Number of Disp bits (DispBits=N, LenBits=16-N) (usually 0Ah..0Dh)
+ 00Ch 4 Offset to Compressed data
+ 010h .. Compression Flags (32bit entries)
+ ... .. Uncompressed data (8bit entries)
+ ... .. Zeropadding to 4-byte boundary
+ ... .. Compressed data (16bit entries)
+ 000h 4 ID ("ULZ",1Ah) (all uppercase)
+ 004h 2 Zero
+ 006h 1 Version (0 or 2)
+ 007h 1 Number of Disp bits (DispBits=N, LenBits=16-N) (usually 0Ah..0Dh)
+ 008h 4 Offset to Uncompressed data
+ 00Ch 4 Offset to Compressed data
+ 010h 4 Decompressed Size in bytes
+ 014h .. Compression Flags (32bit entries)
+ ... .. Uncompressed data (8bit entries)
+ ... .. Zeropadding to 4-byte boundary
+ ... .. Compressed data (16bit entries)
+ if [src+00h]="Ulz",1Ah then
+ version = Byte[src+07h]
+ disp_bits = Byte[src+0Bh]
+ dst_end = LittleEndian24bit[src+04h] + dst
+ src_dta = LittleEndian24bit[src+08h] + src
+ src_lz = LittleEndian32bit[src+0Ch] + src
+ src_flg = src + 10h
+ add_len = 3
+ flg_1st = 31 ;process flag bit31 first
+ if [src+00h]="ULZ",1Ah then
+ version = Byte[src+06h]
+ disp_bits = Byte[src+07h]
+ src_dta = LittleEndian32bit[src+08h] + src
+ src_lz = LittleEndian32bit[src+0Ch] + src
+ dst_end = LittleEndian32bit[src+10h] + dst
+ src_flg = src + 14h
+ add_len = 2
+ flg_1st = 0 ;process flag bit0 first
+ collected = 80000000h ;initially empty, plus stop bit
+ @@decompress_lop:
+ if version=2 AND dst=dst_end then goto @@decompress_done
+ flag = collected AND 80000000h
+ collected=collected*2
+ if collected=0
+ collected = LittleEndian32bit[src_flg], src_flg=src_flg+4
+ if flg_1st=0 then ReverseBitOrder(collected) ;or make custom/faster code
+ flag = collected AND 80000000h
+ if version=0 AND collected=0 then goto @@decompress_done
+ if version=0 then collected=collected*2 ;<-- has implied stop bit
+ if version=2 then collected=collected*2 + 1 ;<-- shift-in stop bit
+ if flag=0 ;compressed
+ disp = LittleEndian16bit[src_lz], src_lz=src_lz+2
+ len = (disp SHR disp_bits) + add_len
+ disp = (disp AND ((1 shl disp_bits)-1)) + 1
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ else ;uncompressed
+ [dst]=[src_dta], dst=dst+1, src_dta=src_dta+1
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+SLZ/01Z files are Chunk-based archives with one or more compressed chunk(s).
+Used by Hot Shots Golf 2 (retail: DATA\F0000.BIN\, MagDemo31/42:
+HSG2\MINGOL2.BIN\)
The archive consists of Chunk(s) in following format:
+
000h 3 ID (either "01Z" or "SLZ", both are used)
+ 003h 1 Method (00h=Uncompressed, 01h=LZSS, 02h=LZSS+FILL)
+ 004h 4 Compressed size (SIZ) (same as decompressed when Method=0)
+ 008h 4 Decompressed size
+ 00Ch 4 Distance to next chunk, if any (SIZ+10h+Align4, or 0=None)
+ 010h SIZ Compressed data
+ method=byre[src+3]
+ len=word[src+8]
+ src=src+10h
+ if method=0 then
+ for i=1 to len, [dst]=[src], dst=dst+1, src=src+1, next i
+ goto @@decompress_done
+ dst_end = dst+len
+ @@collect_more:
+ flagbits=[src]+100h, src=src+1 ;8bit flags
+ @@decompress_lop:
+ if method=2 AND dst=dst_end then goto @@decompress_done
+ flagbits=flagbits SHR 1
+ if zero then goto @@collect_more
+ if carry=1 then
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ disp=([src]+[src+1]*100h) AND 0FFFh, len=([src+1]/10h)+3, src=src+2
+ if method=1 AND disp=0 then goto @@decompress_done
+ if method=2 AND len=12h then ;special fill mode...
+ len=disp/100h+3, val=disp AND FFh ;len=3..12h
+ if len=3 then len=val+13h, val=[src], src=src+1 ;len=13h..112h
+ for i=1 to len, [dst]=val, dst=dst+1, next i ;len=4..112h
+ else
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ endif
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+LZ5 was used by LArc compression tool from 1988/1989, decompression is also
+supported by LHarc/LHA. LZ5 is basically LZSS compression, but with some
+oddities:
+
LZ5 is often implemented with a ringbuf (instead of actual sliding window)
+ LZ5 uses absolute ringbuf indices (instead of relative sliding dest indices)
+ LZ5 requires the ringbuf to be initially prefilled with constants
+ LZ5 ringbuf is 1000h bytes tall and starts with write index FEEh
+ INFO.DAT
+ encrypted directory with filename, offset and compressed/uncompressed size
+ GAME.DAT
+ 000h 4 ID "ALZ1"
+ 004h ... ALZ1 Compressed data (with size as defined in INFO.DAT)
+ ... 4 ID "ALZ1"
+ ... ... ALZ1 Compressed data (with size as defined in INFO.DAT)
+ ...
+ALZ1 compression is used in various folders (ENEMY*, STAGE*, STARTUP, MAGIC,
+FIELD, MINI, MOVIE, WORLD) with various filename extensions (.LZS .BSX .DAT
+.MIM .TIZ .PRE .BSZ .TXZ).
+
000h 4 Compressed Size ;=Filesize-4
+ 004h .. ALZ1 Compressed data (Filesize-4 bytes)
+About same as FF7, but detection is less reliable because there are no
+filenames or extensions, and the file header is somewhat randomly set to
+[000h]=(Filesize-4)+0..7, unknown why, maybe it's allocating dummy bytes to
+last some compression flags.
+
000h 4 Compressed Size+0..7 ;=(Filesize-4)+0..7
+ 004h .. ALZ1 Compressed data (Filesize-4 bytes)
+ 000h 8 ID "00zLATAD" (aka DATALz00 backwards) ;\PreHeader
+ 008h 4 Total Filesize excluding PreHeader+Padding (SIZ+0Ch) ;/
+ 00Ch 4 Unknown (always 1000h) ;\
+ 010h 4 Compressed data size (SIZ) ; Header
+ 014h 4 Decompressed data size ;/
+ 018h SIZ zLATAD Compressed data ;-Data
+ ... .. Padding to 4-byte boundary ;-Padding
+ 000h 8 ID "VRAM-WAD"
+ 008h 4 Compressed size (Filesize-Padding-10h)
+ 00Ch 4 Decompressed size (18000h, 28000h, 40000h bytes)
+ 010h .. VRAMWAD Compressed data (192x256, 320x256, 512x256 halfwords)
+ ... (..) Padding to 4-byte boundary (if any, in files in .VRW archives)
+BIZ compression is used in BIZ archives (which are nested in IDX/HUG archive).
+The compressed & decompressed size is stored in the BIZ archive.
+Note: Power Spike 20h-filled initial BIZ ringbuf is required for sky pixels in:
+
MagDemo43: POWER\GAME.IDX\PERSOS\PSX\CUSTOM\\TEXTURE\NFIELD.BIZ\LPORJ.PSI
+SCRATCH compression is used in PAK archives (which are nested in PCK archive).
+The compressed & decompressed size is stored in the PAK archive.
+Note: The decompressor uses half of the 1Kbyte Scratchpad RAM at 1F800000h as
+ringbuf (hence the name and unusual small 200h-byte ringbuf size).
000h .. FA2 Compressed .FA archive
+ DEFAULT = ALZ1 or BIZ or LZ5
+ if DEFAULT then wr=0FEEh, mask=FFFh ;\
+ if VRAMWAD then wr=0FEEh, mask=FFFh ; initial ringbuf write index
+ if zLATAD then wr=0000h, mask=FFFh ; and ringbuf mask (size-1)
+ if SCRATCH then wr=01BEh, mask=1FFh ;
+ if FA2 then wr=00EFh, mask=0FFh ;/
+ if FA2 then len2=0
+ initialize_ringbuf_content (see below)
+ numbits=0
+ @@decompress_lop:
+ if dst>=dst.end then goto @@decompress_done
+ if numbits=0
+ flagbits=[src], numbits=8, src=src+1 ;8bit flags
+ numbits=numbits-1
+ if VRAMWAD or FA2 then flagbits SHL 1, else flagbits=flagbits SHR 1
+ if carry=1 then
+ dta=[src], [dst]=dta, ringbuf[wr AND mask]=dta
+ dst=dst+1, wr=wr+1, src=src+1
+ else
+ if DEFAULT then rd=[src]+([src+1]/10h)*100h), len=([src+1] AND 0Fh)+3
+ if zLATAD then rd=[src]+([src+1] AND 0Fh)*100h), len=([src+1]/10h)+3
+ if SCRATCH then rd=[src]+([src+1]/80h)*100h), len=([src+1] AND 7Fh)+3
+ if VRAMWAD then rd=[src+1]+([src]/10h)*100h), len=([src] AND 0Fh)+3
+ if FA2 then rd=[src], len=len2, len2=0, src=src+1
+ if FA2 and len=0 then len=[src]/10h+2, len2=([src] AND 0Fh)+2, src=src+1
+ if FA2=0 then src=src+2
+ for i=1 to len ;read ringbuf[rd] (instead of relative [dst-rd])
+ dta=ringbuf[rd AND mask], [dst]=dta, ringbuf[wr AND mask]=dta
+ dst=dst+1, wr=wr+1, rd=rd+1
+ next i
+ endif
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+ if ALZ1 or zLATAD then
+ ringbuf[000h..FFFh]=(00h) ;zeroes
+ if VRAMWAD then
+ ringbuf[000h..FEDh]=(00h) ;zeroes
+ ringbuf[FEEh..FFFh]=(uninitialized) ;uninitialized, don't use
+ if BIZ then
+ ringbuf[000h..FEDh]=(20h) ;ascii space
+ ringbuf[FEEh..FFFh]=(uninitialized) ;uninitialized, don't use
+ if SCRATCH then
+ ringbuf[000h..1BFh]=(00h) ;zeroes
+ ringbuf[1C0h..1FFh]=(uninitialized) ;uninitialized, don't use
+ if FA2 then
+ ringbuf[000h..0FFh]=(00h) ;zeroes
+ if LZ5 then
+ ringbuf[000h..CFFh]=(000h..CFFh)/0Dh ;increasing, repeated 0Dh times each
+ ringbuf[D00h..DFFh]=(00h..FFh) ;increasing
+ ringbuf[E00h..EFFh]=(FFh..00h) ;decreasing
+ ringbuf[F00h..F7Fh]=(00h) ;zeroes
+ ringbuf[F80h..FEDh]=(20h) ;ascii space
+ ringbuf[FEEh..FFFh]=(should be 00h) ;see note, better don't use
+ 000h 3 Decompressed size (24bit, little-endian)
+ 003h 1 Unused (0)
+ 004h ... LZSS compressed data, starting with 30bit+2bit flags
+ [03h]=00h, [04h]=00h, [08h]="PS-X EXE" ;DDRAW\*.EXE
+ [03h]=00h, [04h] AND FCh=00h, [08h]="BC",04h,40h,0,0 ;DDRAW\LDPICS\*.PCK
+The PSX BIOS seems to use the same LZSS format for the self-decompressing GUI
+code (with GUI/decompression starting at 80030000h).
dst_end=dst+LittleEndian24bit[src], src=src+4
+ @@collect_more:
+ flagbits=BigEndian32bit([src]), src=src+4
+ dispbits=14-(flagbits AND 03h), flagbits=(flagbits OR 3)-1
+ dispmask=(1 SHL dispbits)-1
+ @@decompress_lop:
+ flagbits=flagbits SHL 1 ;32bit shift with carry-out/zeroflag
+ if zero then goto @@collect_more
+ if carry=0 then
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ disp=BigEndian16bit[src], src=src+2
+ len=(disp SHR dispbits)+3
+ disp=(disp AND dispmask)+1
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ endif
+ id dst<dst_end then goto @@decompress_lop
+ @@decompress_done:
+ ret
+IKI is a rather uncommon variant of the .STR video format (used by Gran Turismo
+1 and 2, Legend of Legaia, Legend of Dragoon, Omega Boost, Um Jammer Lammy).
+IKI videos have a custom .BS header, including some GT-ZIP compressed data:
+
000h 2 MDEC Size/4 (after huffman decompression) (rounded to 80h/4 bytes)
+ 002h 2 File ID (3800h)
+ 004h 2 Bitmap Width in pixels ;instead quant
+ 006h 2 Bitmap Height in pixels ;instead version
+ 008h 2 Size of GT-ZIP compressed data (plus 2-byte alignment padding)
+ 00Ah .. GT-ZIP compressed DC/Quant values (plus 2-byte alignment padding)
+ ... .. Huffman compressed AC data blocks (Cr,Cb,Y1,Y2,Y3,Y4, Cr,Cb,Y1,Y2..)
+ 000h .. Compressed Data (without header)
+ 000h 0Ch ID "@(#)GT-ZIP",0,0
+ 00Ch 4 Decompressed Size
+ 010h .. Compressed Data (unknown compressed size due to below padding)
+ ... .. Zeropadding to 4-byte boundary (when stored in DOT1 archives)
+ if [src]="@(#)GT-ZIP",0,0 then dst.end=dst+[src+0Ch], src=src+10h
+ @@collect_more:
+ flagbits=[src]+100h, src=src+1 ;8bit flags
+ @@decompress_lop:
+ if src>=src.end then goto @@decompress_done ;(when src.end is known)
+ if dst>=dst.end then goto @@decompress_done ;(when dst.end is known)
+ flagbits=flagbits SHR 1
+ if zero then goto @@collect_more
+ if carry=0 then
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ len=[src], src=src+1, disp=[src], src=src+1 ;len, disp
+ if disp>=80h then disp=(disp-80h)*100h+[src], src=src+1 ;longer disp
+ for i=1 to (len+3), [dst]=[dst-(disp+1)], dst=dst+1, next i
+ endif
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+Depending on the source, only the compressed or decompressed size may be known:
+
Source Compressed Size Decompressed Size
+ Compressed GAMEFONT.DAT In ISO Filesystem Unknown (n/a)
+ Compressed GT-ARC In ISO Filesystem Unknown (n/a)
+ Files in GT-ARC In GT-ARC In GT-ARC
+ Files with GT-ZIP header Unknown (due to padding) In GT-ZIP
+ DC values in IKI videos Unknown (due to padding) From Width*Height
+Used by Rollcage (MagDemo19: ROLLCAGE\SPEED.IMG\*)
+Used by Rollcage Stage II (MagDemo31: ROLLCAGE\SPEED.IDX\*)
+Used by Sydney 2000 (MagDemo37: OLY2000\DEMO.IDX\* and OLY2000\GTO\*.GTO)
+Reportedly also Chill (PS1) (*.GTO)
+Reportedly also Ducati World: Racing Challenge
+Reportedly also Martian Gothic: Unification (PS1) (*.GT20)
+
000h 4 ID ("GT20"=Compressed) (or reportedly "NOGT"=Uncompressed)
+ 004h 4 Size of decompressed data in bytes
+ 008h 4 Overlap for in-situ decompression (usually 3, or sometimes 7)
+ 00Ch 4 Size of Leading Zeropadding in bytes (0..7FFh)
+ 010h .. Leading Zeropadding (0..7FFh bytes)
+ ... .. Compressed Data
+ DecompressGT20:
+ src=src+word[src+0Ch]+10h ;skip header and any leading zeropadding
+ collected=00000001h ;end-bit
+ @@lop:
+ if GetBit=0
+ [dst]=[src], dst=dst+1, src=src+1 ;uncompressed byte
+ else
+ if GetBit=0
+ disp=byte[src]-100h, src=src+1 ;disp=(-100h..-1)
+ len=(GetBit*2)+(GetBit*1)+2 ;len=(2..5)
+ else
+ tmp=halfword[src], src=src+2
+ disp=(tmp/8)-2000h ;disp=(-2000h..-1)
+ len=(tmp AND 7)+2 ;len=(2..9)
+ if len=2
+ tmp=byte[src], src=src+1
+ if (tmp AND 80h) then disp=disp-2000h ;disp=(-4000h..-1)
+ len=(len AND 7Fh)+2 ;len=(2..81h)
+ if len=3 then goto decompression_done
+ if len=2 then len=halfword[src], src=src+2 ;len=(0..FFFFh)
+ for i=1 to len, [dst]=[dst+disp], dst=dst+1, next i
+ goto @@lop
+ ;---
+ GetBit:
+ collected=collected SHR 1
+ if zero then collected=(word[src] SHR 1)+80000000h, src=src+4
+ return carry (from shift right)
+Used by Bloody Roar 1 (MagDemo06: BL\.DAT\)
+Used by Bloody Roar 2 (MagDemo22: ASC,CMN,EFT,LON,SND,ST5,STU\.DAT\)
+
000h 4 Compression Method (0=None, 2=Compressed, Other=Invalid)
+ 004h 4 Compressed Size (SIZ) (same as decompressed when method=0)
+ 008h 4 Decompressed Size
+ 00Ch SIZ Compressed Data
+ ... .. Garbagepadding to 4-byte boundary (in 4-byte aligned DAT files)
+ DecompressPreGT20:
+ src=src+0Ch ;skip header
+ collected=80h ;end-bit
+ @@lop:
+ if GetBit=1
+ [dst]=[src], dst=dst+1, src=src+1 ;uncompressed byte
+ else
+ if GetBit=0
+ len=(GetBit*2)+(GetBit*1)+2 ;len=(2..5)
+ disp=byte[src]-100h, src=src+1 ;disp=(-100h..-1)
+ else
+ tmp=bigendian_halfword[src], src=src+2
+ disp=(tmp/8)-2000h ;disp=(-2000h..-1)
+ len=(tmp AND 7)+2 ;len=(2..9)
+ if len=2
+ len=byte[src]+1, src=src+1 ;len=(1..100h)
+ if len=1 then goto decompression_done
+ for i=1 to len, [dst]=[dst+disp], dst=dst+1, next i
+ goto @@lop
+ ;---
+ GetBit:
+ collected=collected SHL 1 ;8bit shift
+ if zero then collected=(byte[src] SHL 1)+01h, src=src+1
+ return carry (from 8bit shift left)
+Used by Project Horned Owl (*.BIN\*) (and within self-decompressing EXE)
The easiest way to detect HornedLZ files is to check first 4 bytes:
+
B3 10 00 4F .. Compressed TIM with TIM Type=00h (4bpp without CLUT)
+ DB 10 00 3F .. Compressed TIM with TIM Type=08h,09h,etc.
+ Type=05h can be uncompressed .TXT or HornedLZ-compressed .TIM
+ (check if 2nd data byte is ASCII or 10h)
+ Type=0Fh is a DOT1 archive with HornedLZ-compressed .TIMs
+ (parse the DOT1 archive and treat its contents as compressed .TIMs)
+ Type=10h contains Deflated TIMs
+ (a completely different compression method)
+ collected=01h ;end-bit
+ @@lop:
+ if GetBit=1
+ [dst]=[src], dst=dst+1, src=src+1 ;uncompressed byte
+ else
+ if GetBit=1
+ tmp=[src], src=src+1
+ len=tmp/40h+2, disp=tmp or (-40h) ;len=(2..05h), disp=(-40h..-1)
+ else
+ tmp=[src]*100h+[src+1], src=src+2
+ len=tmp/1000h+2, disp=tmp or (-1000h) ;len=(2..11h), disp=(-1000h..-1)
+ if len=2 then
+ len=[src]+2, src=src+1 ;len=(2..101h)
+ if len=2 then goto decompression_done
+ for i=1 to len, [dst]=[dst+disp], dst=dst+1, next i
+ goto @@lop
+ ;---
+ GetBit:
+ collected=collected SHR 1
+ if zero then collected=([src] SHR 1)+80h, src=src+1
+ return carry (from shift right)
+ 000h 4 ID ("lzs",00h)
+ 004h 4 Zerofilled
+ 008h 4 Fixed (must be 1) (method/version?)
+ 00Ch 14h Zerofilled
+ 020h 2 Fixed (must be 3) (method/version?)
+ 022h 2 Offset to Compressed Data minus 20h (usually 38h-20h)
+ 024h 4 Decompressed Size
+ 028h 2 Flagsize (must be 08h, 10h, or 20h) (usually 20h=32bit)
+ 02Ah 2 Lensize (must be 02h..07h) (usually 05h=5bit)
+ 02Ch 4 Compressed Size (total filesize, including "lzs" header)
+ 030h 8 Name? (always "000000",00h,00h)
+ 038h .. Compressed data (usually at offset 38h)
+ dst_end = dst+littleendian32bit[src+24h]
+ flg_bits = littleendian16bit[src+28h] ;8,16,32
+ len_bits = littleendian16bit[src+2Ah] ;2..7
+ len_mask = (1 shl len_bits)-1 ;03h..7Fh
+ src=src+littleendian16bit[src+22h]+20h
+ collected_bits=0
+ @@collect_more:
+ for i=0 to flg_bits/8-1 ;read 8bit/16bit/32bit little-endian
+ collected_bits=collected_bits+([src] SHL (i*8)), src=src+1
+ num_collected=flg_bits
+ @@decompress_lop:
+ if dst=dst_end then goto @@decompress_done
+ if num_collected=0 then goto @@collect_more
+ num_collected=num_collected-1
+ flagbits=flagbits SHR 1
+ if carry=1 then
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ temp=bigendian16bit[src], src=src+2
+ len=(temp AND len_mask)+3
+ disp=(temp SHR len_bits), if disp=0 then goto @@decompress_error
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ endif
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+Used in .BZZ archives. Note that there are three slightly different .BZZ
+archive formats (they are all using the same BZZ compression, only the BZZ
+archive headers are different).
+
Jersey Devil .BZZ (MagDemo10: JD\*.BZZ)
+ Bugs Bunny: Lost in Time (MagDemo25: BBLIT\*.BZZ)
+ The Grinch (MagDemo40: GRINCH\*.BZZ)
+The compression is fairly standard LZSS, except that it supports non-linear
+length values, and it does support uncommon Len/Disp pairs like
+7bitLen/9bitDisp (though usually, it does use standard 4bitLen/12bitDisp).
+
decompress_bzz:
+ method=byte[src], src=src+1 ;method (00h..1Fh) ;usually/always 0Bh)
+ shifter = ((method/8) and 3) ;00h..03h ;usually 1
+ len_bits = ((method and 7) xor 7) ;07h..00h ;usually 4
+ len_mask = (1 shl len_bits)-1 ;7Fh..00h ;usually 0Fh
+ threshold=len_mask/2, if threshold>07h then threshold=13h ;usually 07h
+ for i=0 to len_mask
+ if i>threshold then len_table[i] = ((i-threshold) shl shifter)+threshold+3
+ else len_table[i] = i+3 ;method=18h max=(7Fh-13h)*8+13h+3=376h=886 decimal
+ next i ;method=0Hh max=(0Fh-07h)*2+07h+3=1Ah=26 decimal
+ num_flags=bigendian24bit[src]+1, src=src+3 ;NUM24+1
+ @@collect_more:
+ if src>=src_end then goto @@decompress_error
+ flagbits=[src]+100h, src=src+1 ;8bit flags
+ @@decompress_lop:
+ flagbits=flagbits SHR 1
+ if zero then goto @@collect_more
+ if carry=1 then
+ if src>=src_end then goto @@decompress_error
+ [dst]=[src], dst=dst+1, src=src+1
+ else
+ if src+1>=src_end then goto @@decompress_error
+ temp=bigendian16bit[src], src=src+2
+ len=len_table[temp AND len_mask]
+ disp=temp SHR len_bits, if disp=0 then goto @@decompress_error
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ endif
+ num_flags=num_flags-1, if num_flags>0 then goto @@decompress_lop
+ @@decompress_error:
+ ret
+ Case 1) source has NUM24+1 codes
+ --> decode all NUM24+1 codes (otherwise output will be too small)
+ Case 2) source has NUM24 codes (and enough padding for another code)
+ --> decode all NUM24+1 codes (for compatibility with case 1)
+ --> output will have some constant garbage byte(s) appended
+ --> exception: omit last code if it contains invalid disp=0
+ Case 3) source has NUM24 codes (and not enough padding for another code)
+ --> decode only NUM24 codes (abort if NUM24+1 exceeds src_end)
+ --> output should (probably) have correct size
+ --> never exceed src_end which would be highly unstable
+ decompression function:
+ base=src, method=[src], dst_end=dst+BigEndian24bit[src+1], src=src+4
+ @@decompress_lop:
+ if dst>=dst_end then goto @@decompress_done
+ if [src] AND 80h then
+ if method=01h then
+ len=([src]-80h)/8+3, disp=(BigEndian16bit[src] AND 7FFh)+1, src=src+2
+ else ;method=02h
+ len=([src]-80h)+4, disp=(BigEndian16bit[src+1])+1, src=src+3
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1
+ else ;uncompressed
+ len=[src]+1, src=src+1
+ for i=1 to len, [dst]=[src], src=src+1, dst=dst+1
+ goto @@decompress_lop
+ @@decompress_done:
+ src=(src+3) AND NOT 3
+ if LittleEndian32bit[src]<>crc(base, src-base) then error
+ ret
+Normally only Top-level archives contain compression, however, there are also
+some Nested archives with compression in BallBlazer Champions:
+
STD_BBX.DAT\s*t\tp_a\* ;\double compression, Top-level is ALSO compressed
+ BBX_INTR.DAT\data1\pics\* ;/
+ BBX_INTR.DAT\Stad\pics\* ;\
+ BBX_INTR.DAT\Stad\wire\* ; Nested archives with compression
+ BBX_INTR.DAT\Subtitl\* ;
+ BBX_INTR.DAT\Subtitl\sub\*;/
+Ape Escape (Sony 1999) (MagDemo22: KIDZ\) has several compressed and
+uncompressed TIMs in headerless archives, the archives can contain:
+
+The compression method is indicated by changing a reserved halfword in the TIM
+header: Compressed 4bpp RLE4-TIM with uncompressed CLUT ;\only 4bpp can be compressed
+ Compressed 4bpp RLE8-TIM with uncompressed CLUT ;/
+ Uncompressed 4bpp TIM with uncompressed CLUT ;\only this type/combinations
+ Uncompressed 8bpp TIM with uncompressed CLUT ; are allowed if uncompressed
+ Uncompressed 16pp TIM without CLUT ;/
+ End code 00000000h (plus more zeropadding) ;-end of headerless archive
+
+
+The rest of the bytes in TIM header and in CLUT section are same as for normal
+TIMs. The Bitmap section is as follows: hdr[02h]=Method (0000h=Uncompressed, 0001h=RLE4, 0002h=RLE8)
+
+Decompressed size must be computed as Width*Height*2. The Section Size entry
+contains Section header size, plus compressed size, plus padding to 4-byte
+boundary.
+Method=0001h (RLE4):
+
+Method=0002h (RLE8): @@decompress_lop:
+ color=[src]/10h, len=([src] AND 0Fh)+1, src=src+1
+ for i=1 to len, putpixel(color), next i ;len=1..10h
+ if numpixels<Width*Height*4 then goto @@decompress_lop
+
+
+The decompression functions in Ape Escape (MagDemo22: KIDZ\) are found at: @@decompress_lop:
+ color1=[src]/10h, color2=[src] AND 0Fh, src=src+1
+ if color1=color2
+ len=[src]+2, src=src+1
+ for i=1 to len, putpixel(color1), next i ;len=2..101h
+ else
+ putpixel(color1), if numpixels<Width*Height*4 then putpixel(color2)
+ for i=1 to len, putpixel(color) ;len=1..10h
+ if numpixels<Width*Height*4 then goto @@decompress_lop
+
+
80078760h ape_escape_load_tim_archive
+ 8007894Ch ape_escape_decompress_with_4bit_lengths
+ 800789FCh ape_escape_decompress_with_8bit_lengths
+ RLE8: Ape Escape, MagDemo22: KIDZ\KKIIDDZZ.HED\DAT\file004h\1stTIM
+ RLE4: Ape Escape, MagDemo22: KIDZ\KKIIDDZZ.HED\DAT\file135h\1stTIM
+ RLE8: Ape Escape, MagDemo22: KIDZ\KKIIDDZZ.HED\DAT\file139h\1stTIM
+ 000h 8 ID "_RLE_16_"
+ 008h 4 Decompressed Size (usually 3C008h) (33408h=Apocalypse warning.rle)
+ 00Ch .. RLE Compressed Data (usually a .BMR bitmap)
+ src=src+0Ch ;skip ID and size
+ @@decompress_lop:
+ len=halfword[src], src=src+2
+ if len=0000h then goto @@decompress_done ;end-code
+ if (len AND 8000h)=0 then
+ for i=1 to len, halfword[dst]=halfword[src], dst=dst+2, src=src+2, next i
+ else
+ fillvalue=halfword[src], src=src+2
+ for i=1 to len-8000h, halfword[dst]=fillvalue, dst=dst+2, next i
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+A similar RLE16 variant is used in Croc 1, and another variant in Croc 2.
+CDROM File Archive Croc 1 (DIR, WAD, etc.)
+CDROM File Archive Croc 2 (DIR, WAD, etc.)
000h 1 Unknown (always 01h) (maybe File ID or Compression method)
+ 001h .. Compressed data ;for TIM: usually 00,10, F0,00, 00,0x, F0,00, ...
+ nn,data[nn+1] ;nn=00..EF len=nn+1 [dst]=data[1] ;-uncompressed
+ F0,xn len=n+3 [dst]=0x ;1x4bit ;\
+ F1,nn,xx len=nn+4 [dst]=xx ;1x8bit ;
+ F2,nn,yx len=nn+2 [dst]=0x,0y ;2x4bit ; RLE fill
+ F3,nn,xx,yy len=nn+2 [dst]=xx,yy ;2x8bit ;
+ F4,nn,xx,yy,zz len=nn+2 [dst]=xx,yy,zz ;3x8bit ;/
+ F5,nn,xx,data[nn+4] len=nn+4 [dst]=xx,data[1] ;\interleaved
+ F6,nn,xx,yy,data[nn+3] len=nn+3 [dst]=xx,yy,data[1] ; fill combo
+ F7,nn,xx,yy,zz,data[nn+2] len=nn+2 [dst]=xx,yy,zz,data[1] ;/
+ F8,nn,xx len=nn+4 [dst]=xx ;xx=xx+1 ;\
+ F9,nn,xx len=nn+4 [dst]=xx ;xx=xx-1 ; fill with
+ FA,nn,xx,ss len=nn+5 [dst]=xx ;xx=xx+ss ; signed step
+ FB,nn,xx,yy,ss ;ss=signed len=nn+3 [dst]=xx,yy ;yyxx=yyxx+ss ;/
+ FC,xx,ny len=n+4 [dst]=[dst-yxx-1] ;\
+ FD,xx,nn len=nn+14h [dst]=[dst-xx-1] ; LZ compress
+ FE,xn len=n+3 [dst]=[dst-x*8-8] ;/
+ FF len=0 end ;-end code
+ BIN\*.BIN ---> packed misc binary
+ MAP\*\FDATA.PRS ---> packed resource, whatever
+ MAP\*\MAP*.PRS ---> packed MPD resource, "SKmapDat"
+ WM\WMTIM\*.PIM ---> packed TIM image, 384x384x4bpp, bad compression ratio
+ WM\WMAP\*.PAT ---> packed loaddata
+ WM\WMAP\*.PIM ---> packed TIM image, 320x256x16bit, with UNCOMPRESSED dupe
+Byte Pair Encoding (BPE) does replace the most common byte-pairs with bytes
+that don't occur in the data. That does work best if there are unused bytes
+(eg. ASCII text, or 8bpp bitmaps with less than 256 colors).
000h 4 ID "BPE_"
+ 004h 4 Total Filesize of compressed file including header (big-endian)
+ ... .. Compression block(s)
+ Each compression block contains:
+ 000h .. Dictionary info
+ ... 2 Size of compressed data (big-endian)
+ ... .. Compressed data
+ 000h 4 Decompressed size (little-endian)
+ 004h 4 ID "BPE",1Ah
+ 008h .. Compression block(s)
+ ... .. End code (00000000h) (aka last block with Blocksize=0)
+ Each compression block contains:
+ 000h 4 Size of decompressed block (little-endian) (or 0=End code)
+ 004h .. Dictionary info
+ ... .. Compressed data
+ ... .. Padding to 4-byte boundary
+ if [src+0]="BPE_" then type=GROOVE ;\
+ if [src+4]="BPE",1Ah then type=DRAGOON ;
+ if type=GROOVE then src_end = src+BigEndian32bit[src+4] ; hdr
+ if type=DRAGOON then dst_end = dst+LittleEndian32bit[src+0] ;
+ src=src+8 ;/
+ @@block_lop:
+ if type=DRAGOON then ;\blk
+ dst_blk_end = dst+LittleEndian32bit[src]+4, src=src+4 ; len
+ if dst=dst_blk_end then goto @@decompress_done ;/
+ for i=00h to FFh, dict1[i]=i, next i ;\
+ i=00h ;
+ @@dict_lop: ; dict
+ num=[src], src=src+1 ;
+ if num>7Fh then i=i+(num-7Fh), num=0, if i=100h then goto @@dict_done ;
+ for j=0 to num ;
+ a=[src], src=src+1 ;
+ if a<>i then b=[src], src=src+1, dict1[i]=a, dict2[i]=a ;
+ i=i+1 ;
+ if i<100h then goto @@dict_lop ;
+ @@dict_done: ;/
+ if type=GROOVE then ;\blk
+ src_blk_end = src+BigEndian16bit[src]+2, src=src+2 ;/len
+ i=0 ;\
+ @@data_lop: ;
+ if i=0 then ;\ ; data
+ if type=GROOVE and src=src_blk_end then goto @@data_done ; get data ;
+ if type=DRAGOON and dst=dst_blk_end then goto @@data_done; from src ;
+ x=[src], src=src+1 ; or heap ;
+ else ; ;
+ i=i-1, x=heap[i] ;/ ;
+ a=dict1[x] ;-xlat ;
+ if a=x then ;\ ;
+ [dst]=x, dst=dst+1 ; output data to ;
+ else ; dst or heap ;
+ b=dict2[x], heap[i]=b, heap[i+1]=a, i=i+2 ;/ ;
+ goto @@data_lop ;
+ @@data_done: ;/
+ if type=GROOVE and src<src_end then goto @@block_lop ;\next
+ if type=DRAGOON then src=(src+3) AND not 3, goto @@block_lop ;/blk
+ @@decompress_done:
+ if type=DRAGOON and dst<>dst_end then error
+ ret
+Electronic Arts games support several compression methods, including a BPE
+variant. That BPE variant is a bit unusual: It does have only one compression
+block (with a single dictionary for the whole file), and uses escape codes for
+rarely used bytes.
+CDROM File Compression EA Methods
Rob Northen compression (RNC) is a LZ/Huffman compression format used by
+various games for PC, Amiga, PSX, Mega Drive, Game Boy, SNES and Atari Lynx.
+Most RNC compressed files come in a standard 12h-byte header:
+
000h 3 Signature ("RNC") (short for Rob Northen Computing compression)
+ 003h 1 Compression Method (01h or 02h)
+ 004h 4 Size of Uncompressed Data ;big-endian
+ 008h 4 Size of Compressed Data (SIZ) ;big-endian
+ 00Ch 2 CRC16 on Uncompressed Data (with initial value 0000h) ;big-endian
+ 00Eh 2 CRC16 on Compressed Data (with initial value 0000h) ;big-endian
+ 010h 1 Leeway (difference between compressed and uncompressed data in
+ largest pack chunk, if larger than decompressed data)
+ 011h 1 Number of pack chunks
+ 012h SIZ Compressed Data
+ ... (..) Zeropadding to 800h-byte boundary-4 ;\as so in PSX Heart of Darkness
+ ... (4) Unknown ;/
+The bit-stream is read in 16bit units (the 1st bit being in bit0 of 1st byte).
+
Each pack chunk contains the following:
+ * 3 Huffman trees (one for literal data sizes, one for distance values,
+ and one for length values) in the bit stream. These consist of:
+ o A 5 bit value for the amount of leaf nodes in the tree
+ o 4 bit values for each node representing their bit depth.
+ * One 16 bit value in the bitstream for the amount of subchunks in the
+ pack chunk.
+ * The subchunk data, which contains for each subchunk:
+ o A Huffman code value from the first tree in the bit stream for the
+ amount of literals in the byte stream.
+ o Literals from the byte stream.
+ o A Huffman code from the bit stream that represents the distance - 1
+ of a distance/length pair.
+ o A Huffman code from the bit stream that represents the length - 2
+ of a distance/length pair.
+The bit-stream is read in 8bit units (the 1st bit being in bit7).
+
0 + Byte(DATA[1]) Copy 1 Byte from Source
+ 1000 + Dist + Byte(X) Copy 4 Bytes from Dest-(Dist+X+1)
+ 10010 + Dist + Byte(X) Copy 6 Bytes from Dest-(Dist+X+1)
+ 10011 + Dist + Byte(X) Copy 7 Bytes from Dest-(Dist+X+1)
+ 1010 + Dist + Byte(X) Copy 5 Bytes from Dest-(Dist+X+1)
+ 10110 + Dist + Byte(X) Copy 8 Bytes from Dest-(Dist+X+1)
+ 10111 + nnnn + Byte(DATA[12..72]) Copy nnnn*4+12 Bytes from Source
+ 110 + Byte(X) Copy 2 Bytes from Dest-(X+1)
+ 1110 + Dist + Byte(X) Copy 3 bytes from Dest-(Dist+X+1)
+ 1111 + Byte(0) + 0 + zeropadding End of last pack chunk
+ 1111 + Byte(0) + 1 End of non-last pack chunk
+ 1111 + Byte(L) + Dist + Byte(X) Copy L+8 Bytes from Dest-(Dist+X+1) ;L>00h
+ 0 = 0000h 1000 = 0200h
+ 110 = 0100h 1001 = 0300h
+ 111000 = 0C00h 101000 = 0800h
+ 111001 = 0D00h 101001 = 0900h
+ 11101 = 0600h 10101 = 0400h
+ 111100 = 0E00h 101100 = 0A00h
+ 111101 = 0F00h 101101 = 0B00h
+ 11111 = 0700h 10111 = 0500h
+http://aminet.net/package/util/pack/RNC_ProPack - official tool & source code
+https://segaretro.org/Rob_Northen_compression - description (contains bugs)
RNC is used in a number of games by UK developers (notably Bullfrog and
+Traveller's Tales), including Sonic 3D: Flickies' Island, Blam! Machinehead,
+Dungeon Keeper 2, Magic Carpet, Syndicate and Syndicate Wars.
Method 2: Demolition Racer (MagDemo27: DR\DD.DAT\*.RNC)
+ Method 2: Heart of Darkness (IMAGES\US.TIM)
+ Method 2: Jonah Lomu Rugby (LOMUDEMO\GFX\*.PAK)
+ Method 2: NBA Jam: Tournament Edition (*.RNC, headerless .BIN/.GFX archives)
+ Method 2: Test Drive 5 (MagDemo13: TD5.DAT\*.RNC)
+ Method 2: Test Drive Off-Road 3 (MagDemo27: TDOR3\TDOR3.DAT\*.rnc)
+ 3 Ninjas Kick Back
+ Addams Family
+ Addams Family Values
+ The Adventures of Mighty Max
+ Asterix and the Great Rescue
+ Asterix and the Power of the Gods
+ The Incredible Hulk
+ The Itchy & Scratchy Game (unreleased)
+ Marsupilami
+ Mortal Kombat
+ Mr. Nutz
+ Outlander
+ The Pagemaster
+ RoboCop 3
+ Spirou
+ Spot Goes to Hollywood
+ Stargate
+ Street Racer
+ Tinhead
+ Tintin in Tibet
+ World Championship Soccer II
+Used by Alone in the Dark The New Nightmare (FAT.BIN\LEVELS\*\chunks)
The decompressor is designed to hook the sector loading function: It does
+decompress incoming sectors during loading, and forwards the decompressed data
+to the original sector loading function. The decompressed data is temporarily
+stored in two small Dict buffers (which do also serve as compression
+dictionary).
+
decompress:
+ dictsize=1000h, dict0=alloc(dictsize), dict1=alloc(dictsize)
+ src=load_next_800h_byte_sector ;load first sector
+ dst=dict0 ;temp dest in current dict
+ dst_base=dst ;memorize start of newly decompressed data
+ @@decompress_lop:
+ if [src]=00h then ;\
+ esc=[src+1], src=src+1 ;
+ forward_to_actual_dest(source=dst_base, len=dst-dst_base) ; escape
+ if esc=0 or esc>4 then esc=2 (or warn_invalid_escape_code) ;
+ if esc=1 then goto @@decompress_done ;
+ if esc=2 or esc=4 then src=load_next_800h_byte_sector ;
+ if esc=3 or esc=4 then swap(dict0,dict1), dst=dict0 ;
+ dst_base=dst ;/
+ elseif ([src] AND 03h)=0 then ;\
+ len=[src]/4+2, dat=[src+1], src=src+2 ; fill 8bit
+ for i=1 to len, [dst]=dat, dst=dst+1 ;/
+ elseif ([src] AND 03h)=1 then ;\
+ len=[src]/4+([src+2] AND 40h)+4 ;
+ ptr=[src+1]+([src+2] AND 3Fh)*100h ; LZ compressed
+ if ptr+len>dictsize then error (exceeds allocated dictsize) ;
+ if ([src+2] AND 80h) then ptr=ptr=dict1 else ptr=ptr=dict0 ;
+ src=src+3 ;
+ for i=1 to len, [dst]=[ptr], ptr=ptr+1, dst=dst+1 ;/
+ elseif ([src] AND 03h)=2 then ;\
+ len=[src]/4+3, dat0=[src+1], dat1=[src+2], src=src+3 ; fill 16bit
+ for i=1 to len, [dst]=dat0, [dst+1]=dat1, dst=dst+2 ;/
+ elseif ([src] AND 03h)=3 then ;\
+ len=[src]/4+1, src=src+1 ; uncompressed
+ for i=1 to len, [dst]=[src], src=src+1, dst=dst+1 ;/
+ goto @@decompress_lop
+ @@decompress_done:
+ dealloc(dict0), dealloc(dict1)
+ ret
+Decompression function:
+
if LittleEndian32bit[src+08h]<>1 then error ;compression flag
+ dst_end=dst+LittleEndian32bit[src+14h], src=src+18h, num_collected=0
+ @@decompress_lop:
+ if GetBit=1 then
+ [dst]=[src], src=src+1, dst=dst+1 ;code 1 uncompressed byte
+ elseif GetBit=1 then
+ len=[src], src=src+1 ;code 01 fill or end code
+ if len=00h then goto @@decompress_done
+ len=len+1, fillvalue=[dst-1]
+ for i=1 to len, [dst]=fillvalue, dst=dst+1
+ else
+ len=GetBit*2+GetBit
+ if len=0 then ;code 0000 long LZ range
+ len=[src] AND 0Fh, disp=[src]/10h+[src+1]*10h-1000h, src=src+2
+ else ;code 00xx short LZ range
+ disp=[src]-100h, src=src+1
+ len=len+1
+ for i=1 to len, [dst]=[dst+disp], dst=dst+1
+ goto @@decompress_lop
+ @@decompress_done:
+ if dst<>dst_end then error
+ ret
+ ;---
+ GetBit:
+ if num_collected=0 then collected=[src], src=src+1, num_collected=8
+ collected=collected*2
+ return (collected/100h) AND 1
+ decompress_z:
+ src=src+4 ;skip 32bit decompressed size entry
+ @@reload_lop:
+ load_table1 ;table for first 9bits
+ load_table2 ;table for codes longer than 9bits
+ @@decompress_lop:
+ sym=get_symbol()
+ if sym<100h then [dst]=sym, dst=dst+1, goto @@decompress_lop
+ if sym=100h then goto @@escape
+ len=sym-0FCh ;change 101h..140h to 05h..44h
+ disp=((get_symbol()-101h)*40h) ;change 101h..140h to 00h..3Fh*40h
+ disp=((get_symbol()-101h) or disp)+1 ;change 101h..140h to 00h..3Fh+above+1
+ copy len bytes from dst-disp to dst
+ goto @@decompress_lop
+ @@escape:
+ if GetBits(1)=0 then goto @@reload_lop
+ ret
+ ;-----
+ load_table1:
+ t=0
+ @@load_lop:
+ x=GetBits(10h)
+ if x and 8000h then num=1 else num=(1 shl (9-(x/400h)))
+ for i=1 to num, table1[t]=x, t=t+1, next i
+ if t<200h then goto @@load_lop
+ ret
+ ;-----
+ load_table2:
+ num=GetBits(9)*2 ;can be 0=none, max=3FEh
+ if num>0 then for i=0 to num-1, table2[i]=GetBits(9), next i
+ ret
+ ;-----
+ get_symbol:
+ ;returns a value in range 0..140h:
+ ; 00h..FFh = data 00h..FFh (or unused for disp codes)
+ ; 100h = escape (or unused for disp codes)
+ ; 101h..140h = length 05h..44h (or 6bit fraction of 12bit disp)
+ ; 141h..3FFh = would be possible for short codes, but shouldn't be used
+ x=table1[PeekBits(9)]
+ if (x and 8000h)=0 then SkipBits(x/400h), return (x and 3FFh) ;-short code
+ SkipBits(9) ;skip first 9 bits, and process futher bit(s).. ;\
+ x=x-0C000h ;change C000h..C1FFh and up to 000h..1FFh ; long code
+ @@lop: ; (with more
+ x=table2[x*2+GetBits(1)] ;branch node0/node1 ; than 9bit)
+ if x>=141h then x=x-141h, goto @@lop ;
+ return x ;/
+ZAL compression is used in ZAL archives. The archive header contains compressed
+and decompressed size for each file (and a compression flag indicating whether
+the archive is compressed at all).
if src_len=0 then goto @@decompress_done ;empty (without end code)
+ lzlen=0, rawlen=0
+ if [src]=10h..FFh then ;\special handling
+ rawlen=[src]-11h, src=src+1 ; for code=10h..FFh
+ if rawlen<=0 then goto @@decompress_error ;/at begin of source
+ @@decompress_lop:
+ memcopy(dst-disp,dst,lzlen) ;copy compressed bytes
+ memcopy(src,dst,rawlen) ;copy uncompressed bytes
+ code=[src], src=src+1
+ if code=00h..0Fh then
+ if rawlen=0 ;when OLD rawlen=0...
+ lzlen=0, rawlen=code+3 ;\
+ if rawlen=3 then ;
+ while [src]=00h, rawlen=rawlen+FFh, src=src+1 ;
+ rawlen=rawlen+[src]+0Fh, src=src+1 ;/
+ else ;when OLD rawlen>0, and depending on OLD lzlen...
+ rawlen=code AND 03h
+ disp=code/4+[src]*4, src=src+1
+ if lzlen=0 then disp=disp+801h, lzlen=3, else then disp=disp+1h, lzlen=2
+ if code=10h..1Fh then
+ lzlen=(code AND 07h)+2
+ if lzlen=2 then
+ while [src]=00h, lzlen=lzlen+FFh, src=src+1
+ lzlen=lzlen+[src]+07h, src=src+1
+ rawlen=[src] AND 03h, disp=[src]/4+[src+1]*40h+(code/8 AND 1)*4000h+4000h
+ src=src+2
+ if disp=4000h AND code=11h then goto @@decompress_done ;end code
+ if disp=4000h AND code<>11h then goto @@decompress_error
+ if code=20h..3Fh then
+ lzlen=code-20h+2
+ if lzlen=2 then
+ while [src]=00h, lzlen=lzlen+FFh, src=src+1
+ lzlen=lzlen+[src]+1Fh, src=src+1
+ rawlen=[src] AND 03h, disp=[src]/4+[src+1]*40h+1, src=src+2
+ if code=40h..FFh then
+ rawlen=code AND 03h
+ lzlen=(code/20h)+1
+ disp=((code/4) AND 07h)+([src]*8)+1, src=src+1
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+The files start with a 16bit big-endian Method value, with following bits:
+
0-7 ID (usually FBh) (or 31h for Method 4A31h with 16bit sizes)
+ 8 Extended Header (usually 0) (or 1 for headers with extra entries)
+ 9-14 Used to distinguish different methods
+ 15 Extended Size (usually 0 for 24bit sizes) (or 1 for 32bit sizes)
+ 10FBh = LZSS Compression (RefPack)
+ 90FBh = LZSS Compression (RefPack, with 32bit size) (not on PSX)
+ 30FBh = Huffman Compression
+ 32FBh = Huffman Compression with filter
+ 34FBh = Huffman Compression with dual filter
+ 46FBh = BPE Byte-Pair Encoding
+ 4AFBh = RLE Run-Length Encoding
+ 4A31h = RLE Run-Length Encoding, with 16bit size
+ C0FBh = File Archive (not a compression method)
+CDROM File Compression EA Methods (LZSS RefPack)
+CDROM File Compression EA Methods (Huffman)
+CDROM File Compression EA Methods (BPE)
+CDROM File Compression EA Methods (RLE)
The compression can be used to compress whole files:
+
PGA Tour 96, 97, 98 (*.* and *.VIV\*) (with method 10FBh)
+ Need for Speed 3 Hot Pursuit (*.Q* with method 10FBh, 30FBh, 32FBh)
+ FIFA - Road to World Cup 98 (*.PSH chunk C0h/C1h with method 10FBh)
+ Sled Storm (MagDemo24: ART3\LOAD*.PSH chunk C0h/C1h with method 10FBh)
+ WCW Mayhem (MagDemo28: WCWDEMO\*.BIG\*.PSH with chunk C0h/C1h with 10FBh)
+Note: Some compressed files are slightly larger than uncompressed files (eg.
+filesizes for PGA Tour 96, 97, 98 COURSES\\.VIV\*.mis are compressed=58h,
+uncompressed=50h).
http://wiki.niotso.org/RefPack - LZ method
000h 2 Method (10FBh, or 11FBh,90FBh,91FBh) (big-endian)
+ ... (3/4) Compressed size (24bit or 32bit) (optional)
+ ... 3/4 Uncompressed size (24bit or 32bit) (big-endoan)
+ ... .. Compressed data
+ 0ddzzzrrdddddddd rawlen=r(2), lzlen=z(3)+3, disp=d(10)+1
+ 10zzzzzzrrdddddddddddddd rawlen=r(2), lzlen=z(6)+4, disp=d(14+1
+ 110dzzrrddddddddddddddddzzzzzzzz rawlen=r(2), lzlen=z(10)+5, disp=d(17)+1
+ 111rrrrr rawlen=r(5)*4+4, lzlen=0
+ 111111rr rawlen=r(2), lzlen=0, endflag=1
+ method=BigEndian16bit[src], src=src+2
+ if (method AND 100h)>0 then src=src+3+method/8000h ;compressed size, if any
+ if (method AND 8000h]=0 then dst_size=BigEndian24bit[src], src=src+3
+ if (method AND 8000h)>0 then dst_size=BigEndian32bit[src], src=src+4
+ endflag=0
+ @@decompress_lop:
+ if ([src] AND 80h)=0 then
+ rawlen=[src] AND 03h
+ lzlen=([src] AND 1Fh)/4+3
+ disp=([src] AND 60h)*8+[src+1]+1
+ src=src+2
+ elseif ([src] AND 40h)=0 then
+ rawlen=[src+1]/40h
+ lzlen=[src] AND 3Fh+4
+ disp=([src+1] AND 3Fh)*100h+[src+2]+1
+ src=src+3
+ elseif ([src] AND 20h)=0 then
+ rawlen=[src] AND 03h
+ lzlen=([src] AND 0Ch)*40h+[src+3]+5
+ disp=([src] AND 10h)*1000h+[src+1]*100h+[src+2]+1
+ src=src+4
+ elseif ([src] AND FCh)=FCh then
+ rawlen=[src] AND 03h
+ lzlen=0
+ src=src+1, endflag=1
+ else
+ rawlen=([src] AND 1Fh)*4+4
+ lzlen=0
+ src=src+1
+ for i=1 to rawlen, [dst]=[src], src=src+1, dst=dst+1, next i
+ for i=1 to lzlen, [dst]=[dst-disp], dst=dst+1, next i
+ if endflag=0 then goto @@decompress_lop
+ if (dst-dst_base)<>dst_size then error
+ ret
+ 000h 2 Method (30FBh..35FBh) (big-endian)
+ ... (3) Extra 3 bytes (only present if Method.bit8=1)
+ ... 3 Decompressed Size (big-endian)
+ ... 1 Escape code
+ ... .. Number of codes per width
+ ... .. Data placement for each code
+ ... .. Compressed Data
+ decompress_ea_huffman:
+ method=GetBits(16) ;3xFBh ;-get method (30FBh..35FBh)
+ if method AND 100h then dummy=GetBits(24) ;-skip extra (if any)
+ dst_size=GetBits(24) ;-get uncompressed size
+ ESC=GetBits(8) ;-get escape code
+ huffwidth=0, huffcode=0, totalnumcodes=0 ;\
+ while (huffcode shl (10h-huffwidth))<10000h ;
+ num=GetVarLenCode ; get num codes per width
+ huffwidth=huffwidth+1 ;
+ numcodes_per_width[width]=num ;
+ totalnumcodes=totalnumcodes+num ;
+ huffcode=(huffcode*2)+num ;/
+ for i=0 to FFh, data_defined_flags[i]=00h ;\
+ dat=FFh, index=0 ;
+ while index<totalnumcodes ;
+ n=GetVarLenCode+1 ;- ; get/assign data values
+ while n>0 ;search Nth notyet defined entry ;
+ dat=(dat+1) AND FFh ;wrap in 8bit range! ;
+ if data_defined_flags[dat]=0 then n=n-1 ;
+ data_defined_flags[dat]=1 ;
+ data_values[index]=dat, index=index+1 ;/
+ huffcode=0000h, index=0 ;\
+ InitEmptyHuffTree(data_tree) ;
+ for width=1 to huffwidth ;
+ for i=1 to numcodes_per_width[width] ; create huffman tree
+ dat=data_values[index], index=index+1 ;
+ CreateHuffCode(data_tree,dat,huffcode,width) ;
+ huffcode=huffcode+(1 shl (10h-width) ;/
+ @@decompress_lop: ;\
+ dat=GetHuffCode(data_tree) ;
+ if dat<>ESC ;
+ [dst]=dat, dst=dst+1 ; decompress
+ else ;
+ num=GetVarLenCode ;
+ if num=0 then ;
+ if GetBits(1)=1 then goto @@decompress_done ;
+ [dst]=GetBits(8), dst=dst+1 ;
+ else ;
+ dat=[dst-1] ;
+ for i=0 to num-1, [dst]=dat, dst=dst+1 ;
+ goto @@decompress_lop ;/
+ @@decompress_done:
+ if (dst-dst_base)<>dst_size then error ;-error check
+ dst=dst_base, x=00h, y=00h ;\
+ if (method AND FEFFh)=32FBh ; optional final
+ for i=0 to dst_size-1, x=x+[dst+i], [dst+i]=x ; unfiltering
+ if (method AND FEFFh)=34FBh ;
+ for i=0 to dst_size-1, x=x+[dst+i], y=y+x, [dst+i]=y ;/
+ ret
+ ;------------------
+ GetVarLenCode:
+ num=2
+ while GetBits(1)=0, num=num+1
+ return (GetBits(num)+(1 shl num)-4)
+ GetBits(num):
+ return "num" bits, fetched from big-endian bitstream
+ GetHuffCode(data_tree):
+ ...
+ InitEmptyHuffTree(data_tree):
+ ...
+ CreateHuffCode(data_tree,dat,huffcode,width):
+ ...
+ numcodes_per_width[10h] ;9bit numcodes per width 0..15 (entry[0]=unused)
+ data_values[100h] ;8bit data values for up to 100h huffman codes
+ data_defined_flags[100h] ;1bit flags for data(00h..FFh)
+ 000h 2 Method (46FBh or 47FBh) (big-endian)
+ ... (5) Extra 5 bytes (only present if Method=47FBh)
+ ... 3 Decompressed Size (big-endian)
+ ... 1 Escape code
+ ... 1 Number of Dict entries (N)
+ ... N*3 Dict (each 3 bytes: Index,Dat1,Dat2)
+ ... .. Compressed Data
+ method=BigEndian16bit[src], src=src+2
+ if method=47FBh then src=src+5
+ dst_size=BigEndian24bit[src], src=src+3
+ esc=[src], src=src+1
+ num=[src], src=src+1
+ for i=0 to FFh, dict1[i]=i ;initially default=self (uncompressed bytes)
+ for i=1 to num, j=[src], dict1[j]=[src+1], dict2[j]=[src+2], src=src+3
+ @@decompress_lop:
+ x=[src], src=src+1
+ if x=dict1[x] then
+ if x=esc then x=[src], src=src+1, if x=00h then goto @@decompress_done
+ [dst]=x, dst=dst+1
+ else
+ heap[0]=x, i=1
+ while i>0
+ i=i-1, x=heap[i], a=dict1[x]
+ if a=x then [dst]=x, dst=dst+1 ;\output data to
+ else b=dict2[x], heap[i]=b, heap[i+1]=a, i=i+2 ;/dst or heap
+ goto @@decompress_lop
+ @@decompress_done:
+ if (dst-dst_base)<>dst_size then error
+ ret
+ 000h 2 Method (4AFBh=24bit or 4A31h=16bit) (big-endian)
+ ... 2/3 Decompressed Size (24bit or 16bit) (big-endian)
+ ... .. Compressed Data
+ 00h..3Fh Copy 0..3Fh uncompressed bytes
+ 40h..7Fh Load new fillbyte and fill 0..3Fh bytes
+ 80h..BFh Use old fillbyte and fill 0..3Fh bytes (initial fillbyte=00h)
+ C0h..FFh Copy 0..3Fh bytes with constant value in upper 4bit
+ method=BigEndian16bit[src], src=src+2
+ if (method AND 00FFh)=31h then dst_size=BigEndian16bit[src], src=src+2
+ if (method AND 00FFh)<>31h then dst_size=BigEndian24bit[src], src=src+3
+ fillbyte=00h ;initially zero
+ @@decompress_lop:
+ type=[src]/40h, len=[src] AND 3Fh, src=src+1, dst_size=dst_size-len
+ if type=0 then ;\uncompressed bytes
+ for i=1 to len, [dst]=[src], src=src+1, dst=dst+1 ;/
+ elseif type=1 then ;\
+ fillbyte=[src], src=src+1 ; fill with new dat
+ for i=1 to len, [dst]=fillbyte, dst=dst+1 ;/
+ elseif type=2 then ;\fill with old dat
+ for i=1 to len, [dst]=fillbyte, dst=dst+1 ;/
+ elseif type=3 then
+ x=[src], [dst]=x, src=src+1, dst=dst+1, x=x AND F0h
+ for i=2 to len ;<-- or so?
+ if (i AND 1)=0 then [dst]=x+([src]/10h) dst=dst+1
+ if (i AND 1)=1 then [dst]=x+([src] AND 0Fh), dst=dst+1, src=src+1
+ if dst_size<>0 then goto @@decompress_lop
+ ret
+Inflate/Deflate is a common (de-)compression algorithm, used by ZIP, ZLIB, and
+GZIP.
Inflate - Core Functions
+Inflate - Initialization & Tree Creation
+Inflate - Headers and Checksums
In PSX cdrom-images, ZLIB is used by the .CDZ cdrom-image format:
+CDROM Disk Image/Containers CDZ
+In PSX cdrom-images, Inflate is used by .PBP and .CHD cdrom-image formats:
+CDROM Disk Images PBP (Sony)
+CDROM Disk Images CHD (MAME)
In PSX games, ZLIB is used by:
+
Twisted Metal 4 (MagDemo30: TM4DATA\*.MR\* and *.IMG\*)
+ Kula Quest / Kula World / Roll Away (*.PAK) (*.PAK\*)
+ (and probably more games... particulary files starting with "x")
+ Final Fantasy VII (FF7) (BATTLE\TITLE.BIN)
+ Gran Turismo 2 (MagDemo27: GT2\*) (with corrupted/zeropadded GZIP footers)
+ Mat Hoffman's Pro BMX (old demo) (MagDemo39: BMX\BMXCD.HED\TITLE_H.ZLB)
+ Mat Hoffman's Pro BMX (new demo) (MagDemo48: MHPB\FE.WAD+STR)
+ Project Horned Owl (COMDATA.BIN, DEMODATA.BIN, ROLL.BIN, ST*DATA.BIN)
+ tinf_init() ;init constants (needed to be done only once)
+ tinf_align_src_to_byte_boundary()
+ repeat
+ bfinal=tinf_getbit() ;read final block flag (1 bit)
+ btype=tinf_read_bits(2) ;read block type (2 bits)
+ if btype=0 then tinf_inflate_uncompressed_block()
+ if btype=1 then tinf_build_fixed_trees(), tinf_inflate_compressed_block()
+ if btype=2 then tinf_decode_dynamic_trees(), tinf_inflate_compressed_block()
+ if btype=3 then ERROR ;reserved
+ until bfinal=1
+ tinf_align_src_to_byte_boundary()
+ ret
+ tinf_align_src_to_byte_boundary()
+ len=LittleEndian16bit[src+0] ;get len
+ if LittleEndian16bit[src+2]<>(len XOR FFFFh) then ERROR ;verify inverse len
+ src=src+4 ;skip len values
+ for i=0 to len-1, [dst]=[src], dst=dst+1, src=src+1, next i ;copy block
+ ret
+ repeat
+ sym1=tinf_decode_symbol(tinf_len_tree)
+ if sym1<256
+ [dst]=sym1, dst=dst+1
+ if sym1>256
+ len = tinf_read_bits(length_bits[sym1-257])+length_base[sym1-257]
+ sym2 = tinf_decode_symbol(tinf_dist_tree)
+ dist = tinf_read_bits(dist_bits[sym2])+dist_base[sym2]
+ for i=0 to len-1, [dst]=[dst-dist], dst=dst+1, next i
+ until sym1=256
+ ret
+ sum=0, cur=0, len=0
+ repeat ;get more bits while code value is above sum
+ cur=cur*2 + tinf_getbit()
+ len=len+1
+ sum=sum+tree.table[len]
+ cur=cur-tree.table[len]
+ until cur<0
+ return tree.trans[sum+cur]
+ val=0
+ for i=0 to num-1, val=val+(tinf_getbit() shl i), next i
+ return val
+ bit=tag AND 01h, tag=tag/2
+ if tag=00h then tag=[src], src=src+1, bit=tag AND 01h, tag=tag/2+80h
+ return bit
+ tag=01h ;empty/end-bit (discard any bits, align src to byte-boundary)
+ ret
+ tinf_build_bits_base(length_bits, length_base, 4, 3)
+ length_bits[28]=0, length_base[28]=258
+ tinf_build_bits_base(dist_bits, dist_base, 2, 1)
+ ret
+ for i=0 to 29
+ bits[i]=min(0,i-delta)/delta
+ base[i]=base_val
+ base_val=base_val+(1 shl bits[i])
+ ret
+ for i=0 to 6, tinf_len_tree.table[i]=0, next i ;[0..6]=0 ;len tree...
+ tinf_len_tree.table[7,8,9]=24,152,112 ;[7..9]=24,152,112
+ for i=0 to 23, tinf_len_tree.trans[i+0] =i+256, next i ;[0..23] =256..279
+ for i=0 to 143, tinf_len_tree.trans[i+24] =i+0, next i ;[24..167] =0..143
+ for i=0 to 7, tinf_len_tree.trans[i+168]=i+280, next i ;[168..175]=280..287
+ for i=0 to 111, tinf_len_tree.trans[i+176]=i+144, next i ;[176..287]=144..255
+ for i=0 to 4, tinf_dist_tree.table[i]=0, next i ;[0..4]=0,0,0,0,0 ;\dist
+ tinf_dist_tree.table[5]=32 ;[5]=32 ; tree
+ for i=0 to 31, tinf_dist_tree.trans[i]=i, next i ;[0..31]=0..31 ;/
+ ret
+ hlit = tinf_read_bits(5)+257 ;get 5 bits HLIT (257-286)
+ hdist = tinf_read_bits(5)+1 ;get 5 bits HDIST (1-32)
+ hclen = tinf_read_bits(4)+4 ;get 4 bits HCLEN (4-19)
+ for i=0 to 18, lengths[i]=0, next i
+ for i=0 to hclen-1 ;read lengths for code length alphabet
+ lengths[clcidx[i]]=tinf_read_bits(3) ;get 3 bits code length (0-7)
+ tinf_build_tree(code_tree, lengths, 19) ;build code length tree
+ for num=0 to hlit+hdist-1 ;decode code lengths for dynamic trees
+ sym = tinf_decode_symbol(code_tree)
+ len=1, val=sym ;default (for sym=0..15)
+ if sym=16 then len=tinf_read_bits(2)+3, val=lengths[num-1] ;3..6 previous
+ if sym=17 then len=tinf_read_bits(3)+3, val=0 ;3..10 zeroes
+ if sym=18 then len=tinf_read_bits(7)+11, val=0 ;11..138 zeroes
+ for i=1 to len, lengths[num]=val, num=num+1, next i
+ tinf_build_tree(tinf_len_tree, 0, hlit) ;\build trees
+ tinf_build_tree(tinf_dist_tree, 0+hlit, hdist) ;/
+ ret
+ for i=0 to 15, tree.table[i]=0, next i ;clear code length count table
+ ;scan symbol lengths, and sum code length counts...
+ for i=0 to num-1, x=lengths[i+first], tree.table[x]=tree.table[x]+1, next i
+ tree.table[0]=0
+ sum=0 ;compute offset table for distribution sort
+ for i=0 to 15, offs[i]=sum, sum=sum+tree.table[i], next i
+ for i=0 to num-1 ;create code to symbol xlat table (symbols sorted by code)
+ x=lengths[i+first], if x<>0 then tree.trans[offs[x]]=i, offs[x]=offs[x]+1
+ next i
+ ret
+ clcidx[0..18] = 16,17,18,0,8,7,9,6,10,5,11,4,12,3,13,2,14,1,15 ;constants
+ typedef struct TINF_TREE:
+ unsigned short table[16] ;table of code length counts
+ unsigned short trans[288] ;code to symbol translation table
+ TINF_TREE tinf_len_tree ;length/symbol tree
+ TINF_TREE tinf_dist_tree ;distance tree
+ TINF_TREE code_tree ;temporary tree (for generating the dynamic trees)
+ unsigned char lengths[288+32] ;temporary 288+32 x 8bit ;\for dynamic tree
+ unsigned short offs[16] ;temporary 16 x 16bit ;/creation
+ unsigned char length_bits[30]
+ unsigned short length_base[30]
+ unsigned char dist_bits[30]
+ unsigned short dist_base[30]
+ src_start=src, dst_start=dst ;memorize start addresses
+ if (src[0]<>1fh or src[1]<>8Bh) then ERROR ;check id bytes
+ if (src[2]<>08h) then ERROR ;check method is deflate
+ flg=src[3] ;get flag byte
+ if (flg AND 0E0h) then ERROR ;verify reserved bits
+ src=src+10 ;skip base header
+ if (flg AND 04h) then src=src+2+LittleEndian16bit[src] ;skip extra data
+ if (flg AND 08h) then repeat, src=src+1, until [src-1]=00h ;skip file name
+ if (flg AND 10h) then repeat, src=src+1, until [src-1]=00h ;skip file comment
+ hcrc=(tinf_crc32(src_start, src-src_start) & 0000ffffh)) ;calc header crc
+ if (flg AND 02h) then x=LittleEndian16bit[src], src=src+2 ;get header crc
+ if (flg AND 02h) then if x<>hcrc then ERROR ;verify header
+ tinf_uncompress(dst, destLen, src, src_start+sourceLen-src-8) ;----> inflate
+ crc32=LittleEndian32bit[src], src=src+4 ;get crc32 of decompressed data
+ dlen=LittleEndian32bit[src], src=src+4 ;get decompressed length
+ if (dlen<>destLen) then ERROR ;verify dest len
+ if (crc32<>tinf_crc32(dst_start,dlen)) then ERROR ;verify crc32
+ ret
+ src_start=src, dst_start=dst ;memorize start addresses
+ hdr=BigEndian16bit[src], src=src+2 ;get header
+ if (hdr MOD 31)<>0 then ERROR ;check header checksum (modulo)
+ if (hdr AND 20h)>0 then ERROR ;check there is no preset dictionary
+ if (hdr AND 0F00h)<>0800h then ERROR ;check method is deflate
+ if (had AND 0F000h)>7000h then ERROR ;check window size is valid
+ tinf_uncompress(dst, destLen, src, sourceLen-6) ;------> inflate
+ chk=BigEndian32bit[src], src=src+4 ;get data checksum
+ if src-src_start<>sourceLen then ERROR ;verify src len
+ if dst-dst_start<>destLen then ERROR ;verify dst len
+ if a32<>tinf_adler32(dst_start,destLen)) then ERROR ;verify data checksum
+ ret
+ s1=1, s2=0
+ while (length>0)
+ k=max(length,5552) ;max length for avoiding 32bit overflow before mod
+ for i=0 to k-1, s1=s1+[src], s2=s2+s1, src=src+1, next i
+ s1=s1 mod 65521, s2=s2 mod 65521, length=length-k
+ return (s2*10000h+s1)
+LHA (formerly LHarc) is an old DOS compression tool with backwards
+compatibility for LArc. LHA appears to have been particulary popular in Japan,
+and in the Amiga scene.
+LHA archives are used by at least one PSX game:
+
PSX Championship Surfer (MagDemo43: HWX\*.DAT) ;method lh5
+Default archive filename extension is .LZH for LHarc/LHA (lh*-methods), or .LZS
+for LArc (lz*-methods).
+Archives can contain multiple files, and are usually terminated by a 00h-byte:
+
LHA Header+Data for 1st file
+ LHA Header+Data for 2nd file
+ End Marker (00h)
+ 00h 1 Header Size (Method up to including Extended Area) (=16h+F+E)
+ 01h 1 Header Checksum, sum of bytes at [02h+(0..15h+F+E)]
+ 02h 5 Compression Method (eg. "-lh0-"=Uncompressed)
+ 07h 4 Compressed Size
+ 0Bh 4 Uncompressed Size
+ 0Fh 2 Last modified time (in MS-DOS format)
+ 11h 2 Last modified date (in MS-DOS format)
+ 13h 1 MS-DOS File attribute (usually 20h)
+ 14h 1 Header level (must be 00h for v0)
+ 15h 1 Path\Filename Length
+ 16h (F) Path\Filename (eg. "PATH\FILENAME.EXT")
+ '\' may apper in the 2nd byte of Shift_JIS, processing
+ of Shift_JIS is indispensable when you need full
+ implementation of reading Pathname.
+ 16h+F 2 CRC16 (with initial value 0000h) on uncompressed file
+ 18h+F (E) Extended area (used by UNIX in v0)
+ 18h+F+E .. Compressed data
+ 00h 1 Header Size (Method up to including 1st Ext Size) (=19h+F+E)
+ 01h 1 Base Header Checksum, sum of bytes at [02h+(0..18h+F+E)]
+ 02h 5 Compression Method (eg. "-lh0-"=Uncompressed)
+ 07h 4 Skip size (size of all Extended Headers plus Uncompressed Size)
+ 0Bh 4 Uncompressed Size
+ 0Fh 2 Last modified time (in MS-DOS format)
+ 11h 2 Last modified date (in MS-DOS format)
+ 13h 1 Reserved (must be 20h) (but is 02h on Amiga)
+ 14h 1 Header level (must be 01h for v1)
+ 15h 1 Length of Filename (or 00h when name is in Extended Header)
+ 16h (F) Filename (eg. "FILENAME.EXT; path (if any) is in Extended Header)
+ 16h+F 2 CRC16 (with initial value 0000h) on uncompressed file
+ 18h+F 1 Compression Tool OS ID (eg. "M"=MSDOS)
+ 19h+F (E) Extended area (unused in v1, use Ext Headers instead)
+ 19h+F+E 2 Size of 1st Extended Header (0000h=None)
+ 1Bh+F+E .. Extended Header(s) (optional stuff)
+ ... .. Compressed data
+ 00h 2 Header Size (whole Header including all Extended Headers)
+ 02h 5 Compression Method (eg. "-lh0-"=Uncompressed)
+ 07h 4 Compressed Size
+ 0Bh 4 Uncompressed Size
+ 0Fh 4 Last modified date and time (seconds since 1st Jan 1970 UTC)
+ 13h 1 Reserved (must be 20h) (but is 02h on Amiga)
+ 14h 1 Header level (must be 02h for v2)
+ 15h 2 CRC16 (with initial value 0000h) on uncompressed file
+ 17h 1 Compression Tool OS ID (eg. "M"=MSDOS)
+ 18h 2 Size of first Extended Header (0000h=None)
+ 1Ah .. Extended Header(s) (filename and optional stuff)
+ ... 0/1 Nullbyte (End-Marker conflict: change Headersize xx00h to xx01h)
+ ... .. Compressed data
+Kinda non-standard (supported only in late japanese LHA beta versions): Allows
+Header and Ext.Headers to exceed 64Kbyte, which is rather useless.
+
00h 2 Word size for 32bit Header entries (always 4=32bit)
+ 02h 5 Compression Method (eg. "-lh0-"=Uncompressed)
+ 07h 4 Compressed Size
+ 0Bh 4 Uncompressed Size
+ 0Fh 4 Last modified date and time (seconds since 1st Jan 1970 UTC)
+ 13h 1 Reserved (must be 20h)
+ 14h 1 Header level (must be 03h for v3)
+ 15h 2 CRC16 (with initial value 0000h) on uncompressed file
+ 17h 1 Compression Tool OS ID (eg. "M"=MSDOS)
+ 18h 4 Header Size (whole Header including all Extended Headers)
+ 1Ch 4 Size of first Extended Header (00000000h=None)
+ 20h .. Extended Header(s) (filename and optional stuff)
+ ... .. Compressed data
+ Method Len Window
+ -lz4- - - - LArc Uncompressed File
+ -lh0- - - - LHA Uncompressed File
+ -lhd- - - - LHA Uncompressed Directory name entry
+ -lzs- 2..17 2Kbyte LArc LZSS-Compressed (rare, very-very old) ;-15bit
+ -lz5- 3..17 4Kbyte LArc LZSS-Compressed (LArc srandard) ;-16bit
+ -lh1- 3..60 4Kbyte LHA LZHUF-Compressed (old LHA standard)
+ -lh2- 3..256 8Kbyte LHA Obscure test (used in self-extractor)
+ -lh3- 3..256 8Kbyte LHA Obscure test (experimental)
+ -lh4- 3..256 4Kbyte LHA AR002-Compressed (rare, for small RAM) ;\4bit
+ -lh5- 3..256 8Kbyte LHA AR002-Compressed (new LHA standard) ;/
+ -lh6- 3..256 32Kbyte LHA AR002-Compressed (rare) ;\
+ -lh7- 3..256 64Kbyte LHA AR002-Compressed (rare) ; 5bit
+ -lh8- 3..256 64Kbyte LHA AR002-Compressed (accidently same as lh7) ;
+ -lh9- 3..256 128Kbyte LHA AR002-Compressed (unimplemented proposal) ;
+ -lha- 3..256 256Kbyte LHA AR002-Compressed (unimplemented proposal) ;
+ -lhb- 3..256 512Kbyte LHA AR002-Compressed (unimplemented proposal) ;
+ -lhc- 3..256 1Mbyte LHA AR002-Compressed (unimplemented proposal) ;
+ -lhe- 3..256 2Mbyte LHA AR002-Compressed (unimplemented proposal) ;
+ -lhx- 3..256 512Kbyte LHA AR002-Compressed (rare) ;/
+ 00h 1 Extension Type (00h..FFh, eg. 01h=Filename)
+ 01h .. Extension Data
+ ... 2/4 Size of next Extended Header (0=None) (v1/v2=16bit, v3=32bit)
+ 00h CRC16 on whole Header with InitialValue=0000h and InitialCrcEntry=0000h
+ 01h Filename
+ 02h Directory name (with FFh instead of "\", and usually with trailing FFh)
+ 3Fh Comment (unspecified format/purpose)
+ 40h MS-DOS File attribute of MS-DOS format
+ 41h Windows FILETIME for last access, creation, and modification
+ 42h Filesize (uncompressed and compressed size, when exceeding 32bit)
+ 50h Unix Permission
+ 51h Unix User ID and Group ID
+ 52h Unix Group name
+ 53h Unix User name (owner)
+ 54h Unix Last modified time in time_t format
+ 7Dh Capsule offs/size (if the OS adds extra header/footer to the filebody)
+ 7Eh OS/2 Extended attribute
+ 7Fh Level 3 Attribute in Unix form and MS-DOS form
+ FFh Level 3 Attribute in Unix form
+The site below has useful links with info about headers (see LHA Notes), source
+code, and test archives:
+http://fileformats.archiveteam.org/wiki/LHA
UPX is a tool for creating self-decompressing executables. It's most commonly
+used for DOS/Windows EXE files, but it does also support consoles like PSX. The
+PSX support was added in UPX version 1.90 beta (11 Nov 2002).
+
000h 88h Standard PS-X EXE header
+ 088h 20h Unknown
+ 0A8h 4 ASCII ID "UPX!"
+ 0ACh 1Eh Unknown
+ 0CAh 9Ah ASCII "$info: This file is ..."
+ 164h 69Ch Zerofilled
+ 800h .. Leading zeropadding (to make below end on 800h-byte boundary)
+ ... .. Decompression stub
+ ... .. Compressed data (ending on 800h-byte boundary)
+LZMA is combining LZ+Huffman+Probabilities. The LZ+Huffman bitstream is rather
+simple (using hardcoded huffman trees), the high compression ratio is reached
+by predicting probabilities for the bitstream values (that is, the final
+compressed data is smaller than the bitstream).
000h 1 Ignored byte (usually 00h, unknown purpose)
+ 001h .. Bitstream with actual compression codes
+ ... .. EOS end code (end of stream) (optional)
+ ... .. Ignored byte (present in case of Normalization after last code)
+ ... .. Padding to byte-boundary
+ Three decompression parameters: lc, lp, pb
+ Decompressed size (required if the bitstream has no EOS end code)
+ Dictionary size (don't care when decompressing the whole file to memory)
+ Presence/Absence of EOS end code
+ 000h 1 Parameters (((pb*5)+lp)*9)+lc (usually 5Dh) ;\
+ 001h 4 Dictionary Size in bytes (usually 10000h) ; Header
+ 005h 8 Decompressed Size in bytes (or -1=Unknown) ;/
+ 00Dh 1 LZMA ignored 1st byte of bitstream (00h) ;\LZMA
+ 00Eh .. LZMA bitstream (with optional EOS end code) ;/
+LZIP files can contain one or more "LZIP Members" plus optional extra data:
+
000h .. LZIP Member(s)
+ ... .. Optional extra data (if any) (eg. zeropadding or some SHA checksum)
+ 000h 5 ID and version ("LZIP",01h) ;\LZIP Header
+ 005h 1 Dictionary size (5bit+3bit code, see below) ;/
+ 006h .. LZMA bitstream (with lc=3, lp=0, pb=2) (with EOS end code)
+ ... 4 CRC32 on uncompressed data ;\
+ ... 8 Size of uncompressed data ; LZIP Footer
+ ... 8 Size of compressed data (including header+footer) ;/
+ temp = 1 SHL (hdr[005h] AND 1Fh)
+ dict_size = temp - (temp/10h)*(hdr[005h]/20h)
+The CHD format has its own headers and supports several compression methods
+including LZMA. Leaving apart the CHD specific headers, the raw LZMA bitstreams
+are stored as so:
+
000h .. LZMA bitstream (with lc=3, lp=0, pb=2) (without EOS end code)
+This is a slightly overcomplicated format with LZMA2 compression and optional
+filters.
+CDROM File Compression XZ
000h 6 ID ("7z",BCh,AFh,27h,1Ch)
+ ... .. ..
+LZMA2 is a container format with LZMA chunks. The LZMA function is slightly
+customized: It can optionally skip some LZMA initialization steps (and thereby
+re-use the dictionary/state from previous chunks). The chunks are:
+
ChunkID=00h - Last chunk:
+ 000h 1 Chunk ID (00h=End)
+ ChunkID=01h..02h - Uncompressed chunks:
+ 000h 1 Chunk ID (01h=Uncompressed+ResetDictionary, 02h=Uncompressed)
+ 001h 2 Uncompressed Data Size-1 (big-endian)
+ 003h .. Uncompressed Data (to be copied to destination and dictionary)
+ Note: The uncompressed data is stored in LZMA dictionary, and
+ the last uncompressed byte is updating the LZMA prevbyte.
+ ChunkID=03h..7Fh - Invalid chunks:
+ 000h 1 Chunk ID (03h..7Fh=Invalid)
+ ChunkID=80h..FFh - LZMA-compressed chunks:
+ 000h 1 Chunk ID (80h/A0h/C0h/E0h + Upper5bit(UncompressedSize-1))
+ 001h 2 LSBs(UncompressedSize-1) (big-endian)
+ 003h 2 CompressedSize-1 (big-endian)
+ 005h (1) Parameters (((pb*5)+lp)*9)+lc (only present if ChunkID=C0h..FFh)
+ ... .. LZMA bitstream (without EOS end code)
+ ChunkID dict/prev lc/lp/pb state dist[0-3] probabilities code/range
+ 01h reset - - - - -
+ 02h - - - - - -
+ 80h+n - - - - - reset
+ A0h+n - - reset reset reset reset
+ C0h+n - reset reset reset reset reset
+ E0h+nn reset reset reset reset reset reset
+ (Note: Those resets occur before processing the chunk data)
+ Dictionary Size byte (00h..28h = 4K,6K,8K,12K,16K,24K,..,2G,3G,4G)
+ Which can be decoded as so:
+ if (param AND 1)=0 then dict_size=1000h shl (param/2)
+ if (param AND 1)=1 then dict_size=1800h shl (param/2)
+ if param=28h then dict_size=FFFFFFFFh ;4GB-1
+ if param>28h then error
+ In .xz files, that byte is stored alongsides with the Filter ID.
+Compact LZMA decompression ASM code can be found here:
https://github.com/ilyakurdyukov/micro-lzmadec
+Above code is for self-decompressing executables (for plain LZMA, ignore the
+stuff about EXE/ELF headers). The two "static" versions are size-optimized
+(they contain weird and poorly commented programming tricks, and do require
+additional initialization code from "test_static.c"). For normal purposes, it's
+probably better to port the 64bit fast version to 32bit (instead of dealing
+with the trickery in the 32bit static version).
000h .. Stream(s)
+ 000h 6 Header ID (FDh,"7zXZ",00h) (FDh,37h,7Ah,58h,5Ah,00h) ;\
+ 006h 2 Checksum Type (0000h, 0100h, 0400h or 0A00h) ; Header
+ 008h 4 Header CRC32 on above 2 bytes ;/
+ 00Ch .. Compressed Block(s) ;-Block(s)
+ ... .. Index List ;-Index
+ ... 4 Footer CRC32 on below 6 bytes ;\
+ ... 4 Index List Size/4-1 ; Footer
+ ... 2 Checksum Type (must be same as in Header) ;
+ ... 2 Footer ID ("YZ") (59h,5Ah) ;/
+ ... .. Optional Zeropadding (multiple of 4 bytes) ;-Padding
+ Checksum Type (for Block checksums):
+ 0000h=None
+ 0100h=CRC32 (little-endian)
+ 0400h=CRC64 (little-endian)
+ 0A00h=SHA256 (big-endian)
+ Other=Reserved
+ 000h 1 Index Indicator (00h) (as opposed to 01h..FFh in Block Headers)
+ 001h VL Number of Records (must be same as number of Blocks in Stream)
+ ... .. Index Record(s)
+ ... .. Zeropadding to 4-byte boundary
+ ... 4 CRC32 on above bytes
+ Index Record:
+ 000h VL Unpadded Block Size (BlockHeader + CompressedData + 0 + Checksum)
+ ... VL Uncompressed Block Size
+ 000h 1 Block Header Size/4-1 (01h..FFh = 8..400h bytes) ;\
+ 001h 1 Block Flags ;
+ 002h (VL) Compressed Size ;present if Flags.bit6 = 1 ; Header
+ ... (VL) Uncompressed Size ;present if Flags.bit7 = 1 ;
+ ... .. Filter Info 0 (LAST filter when DECOMPRESSING) ;
+ ... (..) Filter Info 1 ;present if Flags.bit0-1 = 1,2,3 ;
+ ... (..) Filter Info 2 ;present if Flags.bit0-1 = 2,3 ;
+ ... (..) Filter Info 3 ;present if Flags.bit0-1 = 3 ;
+ ... .. Zeropadding to 4-byte boundary ;
+ ... (..) Optional Zeropadding (multiple of 4 bytes) ;
+ ... 4 CRC32 on above bytes ;/
+ ... .. Compressed Data ;-Data
+ ... .. Zeropadding to 4-byte boundary ;-Pad
+ ... (..) Checksum on uncompressed Data (None/CRC32/CRC64/SHA256) ;-Check
+ Block Flags:
+ 0-1 Number of filters-1 (0..3 = 1..4 filters)
+ 2-5 Reserved (0)
+ 6 Compressed Size field is present (0=No, 1=Present)
+ 7 Uncompressed Size field is present (0=No, 1=Present)
+ Filter Info:
+ 000h VL Filter ID
+ ... VL Size of Filter Properties
+ ... .. Filter Properties
+ Filter IDs:
+ 03h Delta Filter (with 1 byte param)
+ 04h..09h Executable Filters (with 0 or 4 byte param)
+ 21h LZMA2 Compression (with 1 byte param)
+ 300h..4FFh Reserved to ease .7z compatibility
+ 20000h..7FFFFh Reserved to ease .7z compatibility
+ 2000000h..7FFFFFFh Reserved to ease .7z compatibility
+ xxxxxxxxxxxxxxxxh Custom Registered IDs (obtained from Lasse Collin)
+ 3Frrrrrrrrrriiiih Custom Random IDs (40bit random+16bit filterno)
+ 4000000000000000h and up Reserved for internal use (don't use in xz files)
+This "filter" is the actual compression method (XZ supports only one method).
+It can be combined with BCJ/Delta filters (whereas, LZMA2 must be always used
+as LAST compression filter, aka FIRST decompression filter).
+
The filter parameter is 1 byte tall:
+ Dictionary Size byte (00h..28h = 4K,6K,8K,12K,16K,24K,..,2G,3G,4G)
+ The compressed data contains:
+ LZMA2 chunks (with LZMA-compressed data and/or uncompressed data)
+The filter parameter is 1 byte tall:
+
Distance-1 (00h..FFh = distance 1..100h)
+<B> unfilter_delta(buf,len,param_byte):</B>
+ dist=byte(param)+1, i=dist ;init dist and skip first some unfiltered bytes
+ while i<len, byte(buf[i]) = buf[i]+buf[i-dist], i=i+1
+These filters can replace relative jump addresses by absolute values.
+
ID Parameters Alignment Description
+ 04h 0 or 4 bytes 1 byte 80x86 filter (32bit or 64bit)
+ 05h 0 or 4 bytes 4 bytes PowerPC filter (big endian)
+ 06h 0 or 4 bytes 16 bytes IA64 filter
+ 07h 0 or 4 bytes 4 bytes ARM filter (little endian)
+ 08h 0 or 4 bytes 2 bytes ARM Thumb filter (little endian)
+ 09h 0 or 4 bytes 4 bytes SPARC filter
+ 0Ah,0Bh Inofficial hacks/proposals for ARM64?
+ if param_size=0 then offset=00000000h
+ if param_size=4 then offset=LittleEndian32bit(param)
+ Nonzero offsets are intended for executables with multiple sections and
+ cross-section jumps. The offset shall/must match the filter's alignment.
+<B> unfilter_bcj_x86(buf,len,offset):</B>
+ i=0, len=len-4, offset=offset+4
+ while i<len
+ x=byte[buf+i], i=i+1
+ if (x AND FEh)=E8h ;Opcode=E8h or E9h
+ x=LittleEndian32bit[buf+i]
+ if ((x+01000000h) AND FE000000h)=0 ;MSB=00h or FFh
+ LittleEndian32bit[buf+i]=SignExpandLower25bit(x-i-offset)
+ i=i+4
+<B> unfilter_bcj_arm(buf,len,offset):</B>
+ i=0, len=len/4, offset=(offset+8)/4
+ while i<len
+ x=LittleEndian32bit[buf+i*4]
+ if (x AND FF000000h)=EB000000h
+ LittleEndian32bit[buf+i*4]=((x-i-offset) and 00FFFFFFh)+EB000000h
+ i=i+1
+<B> unfilter_bcj_armthumb(buf,len,offset):</B>
+ i=0, len=len/2-1, offset=(offset+4)/2
+ while i<len
+ x=LittleEndian32bit[buf+i*2]
+ if (x AND F800F800h)=F800F000h
+ msw=LittleEndian16bit[buf+i*2+0] AND 7FFh
+ lsw=LittleEndian16bit[buf+i*2+2] AND 7FFh
+ x=msw*800h+lsw-i-offset
+ LittleEndian16bit[buf+i*2+0]=F000h+(7FFh and (x/800h))
+ LittleEndian16bit[buf+i*2+2]=F800h+(7FFh and (x/1))
+ i=i+1
+<B> unfilter_bcj_sparc(buf,len,offset):</B>
+ i=0, len=len/4, offset=offset/4
+ while i<len
+ x=BigEndian32bit[buf+i*4]
+ if (x AND FFC00000h)=40000000h or (x AND FFC00000h)=7FC00000h
+ x=SignExpandLower23bit(x-i-offset)
+ BigEndian32bit[buf+i*4]=(x AND 3FFFFFFFh)+40000000h
+ i=i+1
+<B> unfilter_bcj_powerpc(buf,len,offset):</B>
+ i=0, len=len/4, offset=offset/4
+ while i<len
+ x=BigEndian32bit[buf+i*4]
+ if (x AND FC000003h)=48000001h
+ BigEndian32bit[buf+i*4]=(((x/4-i-offset) AND 00FFFFFFh)*4)+48000001h
+ i=i+1
+<B> unfilter_bcj_ia64(buf,len,offset):</B>
+ i=0, len=len/10h, offset=offset/10h
+ xlat[0..1Fh]=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,4,6,6,0,0,7,7,4,4,0,0,4,4,0,0
+ while i<len
+ flags=xlat[byte[buf] and 1Fh] ;shared 5bit for three 41bit opcodes
+ for slot=0 to 2
+ if flags and (1 shl slot) ;process three 41bit opcodes
+ bitbase=slot*41+5
+ hi=byte[buf+(bitbase+37)/8] shr ((bitbase+37) and 7) and 0Fh
+ lo=LittleEndian16bit[buf+(bitbase+9)/8] shr ((bitbase+9) and 7) and 07h
+ if hi=5 and lo=0
+ mid=LittleEndian32bit[buf+(bitbase+13)/8]
+ x=mid shr ((bitbase+13) and 7)
+ x=x and 8FFFFFh, if (x and 800000h) then x=x-700000h
+ x=x-i-offset
+ x=x and 1FFFFFh, if (x and 100000h) then x=x+700000h
+ mid=mid AND NOT (8FFFFFh shl ((bitbase+13) and 7)) ;strip old
+ mid=mid OR x shl ((bitbase+13) and 7)) ;place new
+ LittleEndian32bit[buf+(bitbase+13)/8]=mid ;apply
+ i=i+1, buf=buf+10h
+CRC32 uses 32bit (with polynomial=EDB88320h). CRC64 does basically use the same
+function (with 64bit values and polynomial=C96C5795D7870F42h).
Little-endian is used for 16bit/32bit/64bit values (Flags, Sizes, CRCs).
+Big-endian is used for 256bit SHA256 and for values within LZMA2 chunks.
+Variable length integers (marked VL in above tables) are used for Sizes and
+IDs, these values may contain max 63bit, stored in 1-9 bytes:
+
decode_variable_len_integer:
+ i=0, num=0
+ @@lop:
+ x=[src], src=src+1, num=num+((x and 7Fh) shl i), i=i+7
+ if x AND 80h then goto @@lop
+ return num
+XZ Utils for Windows is claimed to work on Win98 (that is, it will throw an
+error about missing MSVCRT.DLL:___mb_cur_max_func). XZ Utils for DOS does work
+on Win98.
+Official XZ file format specs for can be found at:
https://tukaani.org/xz/format.html
+The BCJ filters aren't documented in XZ specs, but are defined in XZ source
+code, see src\liblzma\simple\*.c). There's also this mail thread about
+semi-official ARM64 filters:
https://www.mail-archive.com/xz-devel@tukaani.org/msg00537.html
+FLAC is a lossless audio compression format.
000h 4 FLAC ID ("fLaC")
+ 004h .. Metadata block with STREAMINFO
+ ... .. Metadata block(s) with further info (optional)
+ ... .. FLAC Frame(s)
+ 1bit Last Metadata block flag (1=Last, 0=More blocks follow)
+ 7bit Block Type (see below)
+ 24bit Size of following metadata in bytes (N)
+ N*8bit Metadata (depending on Type)
+ 00h = STREAMINFO
+ 01h = PADDING
+ 02h = APPLICATION
+ 03h = SEEKTABLE
+ 04h = VORBIS_COMMENT
+ 05h = CUESHEET
+ 06h = PICTURE
+ .. = Reserved
+ 7Fh = Invalid (to avoid confusion with a frame sync code)
+ 16bit Minimum Block size in samples (10h..FFFFh) ;\min=max implies
+ 16bit Maximum Block size in samples (10h..FFFFh) ;/fixed blocksize
+ 24bit Minimum Frame size in bytes (or 0=Unknown)
+ 24bit Maximum Frame size in bytes (or 0=Unknown)
+ 20bit Sample rate in Hertz (01h..9FFF6h = 1..655350 Hz)
+ 3bit Number of channels-1 (00h..07h = 1..8 channels)
+ 5bit Bits per sample-1 (03h..1Fh = 4..32 bits) (max 24bit implemented)
+ 36bit Total number of samples per channel (or 0=Unknown)
+ 128bit MD5 on unencoded audio data (...in which format? endian/interleave?)
+The FLAC file format is documented here:
https://xiph.org/flac/format.html
+Source code for a compact FLAC decoder can be found here:
https://www.nayuki.io/page/simple-flac-implementation
+ Main header chunk
+ Local file chunk(s)
+ Chapter chunk(s), backup related, exist only in newer archives
+ End Marker
+This is stored at the begin of the archive. The format is same as for local
+file header (but with file-related entries set to zero, or to global security
+settings).
+
000h 2 ARJ ID (EA60h, aka 60000 decimal)
+ 002h 2 Header size (from 004h up to including Filename+Comment) (max 2600)
+ 004h 1 Header size (from 004h up to including Extra Data) (1Eh+extra)
+ 005h 1 Archiver version number (01h..0xh)
+ 006h 1 Minimum archiver version to extract (usually 01h)
+ 007h 1 Host OS
+ 008h 1 ARJ Flags (bit0-7, see below)
+ 009h 1 Security version (2 = current)
+ 00Ah 1 File Type (must be 2=ARJ Comment in main header)
+ 00Bh 1 Reserved/Garbage (LSB of Archive creation Date/Time, same as [00Ch])
+ 00Ch 4 Date/Time when archive was created
+ 010h 4 Date/Time when archive was last modified
+ 014h 4 Zero (or Secured Archive size, excluding Security and Protection)
+ 018h 4 Zero (or Security envelope file position) (after End Marker)
+ 01Ch 2 Zero (or Filespec position in filename) (0) (what is that??)
+ 01Eh 2 Zero (or Security envelope size in bytes) (78h, if any)
+ 020h 1 Zero (or >2.50?: Encryption version, 0-1=Old, 2=New, 4=40bit GOST)
+ 021h 1 Zero (or >2.50?: Last chapter (eg. 4 when having chapter 1..4)
+ 022h (1) Extra data: ARJ Protection factor ;\extra,
+ 023h (1) Extra data: ARJ Flags (bit0=ALTVOLNAME, bit1=ReservedBit) ; if any
+ 024h (2) Extra data: Spare bytes ;/
+ ... .. Filename, max 500 bytes ("FILENAME.ARJ",00h)
+ ... .. Comment, max 2048 bytes ("ASCII Comment",00h)
+ ... 4 CRC32 on Header (from 004h up to including Comment)
+ ... 2 Size of 1st extended header (usually 0=none)
+ ... (0) Extended Header(s?) (usually none such)
+This occurs at the begin of each file in the archive.
+
000h 2 ARJ ID (EA60h, aka 60000 decimal)
+ 002h 2 Header size (from 004h up to including Filename+Comment) (max 2600)
+ 004h 1 Header size (from 004h up to including Extra Data) (1Eh+extra)
+ 005h 1 Archiver version number
+ 006h 1 Minimum archiver version to extract (usually 01h)
+ 007h 1 Host OS
+ 008h 1 ARJ Flags (bit0,2-5)
+ 009h 1 Method
+ 00Ah 1 File Type (0=Binary, 1=Text, 3=Directory Name, 4=Volume Name)
+ 00Bh 1 Reserved/Garbage (LSB of Archive update Date/Time?)
+ 00Ch 4 Date/Time modified
+ 010h 4 Filesize, compressed (max 7FFFFFFFh)
+ 014h 4 Filesize, uncompressed
+ 018h 4 CRC32 on uncompressed file data
+ 01Ch 2 Zero (or Filespec position in filename) (what is that??)
+ 01Eh 2 File access mode (aka MSDOS file attribute) (20h=Normal)
+ 020h 1 Zero (or >2.50?: first chapter of file's lifespan)
+ 021h 1 Zero (or >2.50?: last chapter of file's lifespan)
+ 022h (4) Extra data: Extended file position (maybe for split?) ;\extra,
+ 026h (4) Extra data: Date/Time accessed ;\ARJ ; 0,4 or 10h
+ 03Ah (4) Extra data: Date/Time created ; 2.62 ; bytes
+ 03Eh (4) Extra data: Original file size even for volumes ;/ ;/
+ ... .. Filename, max 500 bytes ("PATH/FILENAME.EXT",00h)
+ ... .. Comment, max 2048 bytes ("ASCII Comment",00h)
+ ... 4 CRC32 on Header (from 004h up to including Comment)
+ ... 2 Size of 1st extended header (usually 0=none)
+ ... (0) Extended Header(s?) (usually none such)
+ ... .. Compressed file data
+This is rarely used and supported only in newer ARJ versions. The format is
+same as for local file header (but with file-related entries being nonsense in
+TECHNOTE; in practice, those nonsense values seem to be zero).
+
000h 2 ARJ ID (EA60h, aka 60000 decimal)
+ 002h 2 Header size (from 004h up to including Filename+Comment) (max 2600)
+ 004h 1 Header size (from 004h up to including Extra Data) (1Eh+extra)
+ 005h 1 Archiver version number (eg. 0Ah=2.75a)
+ 006h 1 Minimum archiver version to extract (usually 01h)
+ 007h 1 Host OS
+ 008h 1 ARJ Flags (usually 00h)
+ 009h 1 Method (usually 01h, although chapters have no data) what file???
+ 00Ah 1 File Type (must be 5=ARJ Chapter)
+ 00Bh 1 Reserved/Garbage (LSB of Chapter Date/Time, same as [00Ch])
+ 00Ch 4 Date/Time stamp created
+ 010h 4 Zero (or reportedly, ?) what question?
+ 014h 4 Zero (or reportedly, ?) what question?
+ 018h 4 Zero (or reportedly, original file's CRC32) what file???
+ 01Ch 2 Zero (or reportedly, entryname position in filename) what file???
+ 01Eh 2 Zero (or reportedly, file access mode) what file???
+ 020h 1 Chapter range start (01h=First chapter?) what range???
+ 021h 1 Chapter range end (contains same value as above) what range???
+ 022h (4) Extra data: Extended file position (usually none such)what extra???
+ ... .. Filename ("<<<001>>>",00h for First chapter)
+ ... .. Comment ("",00h)
+ ... 4 CRC32 on Header (from 004h up to including Comment)
+ ... 2 Size of 1st extended header (usually 0=none)
+ ... (0) Extended Header(s?) (usually none such)
+This is stored at the end of the archive.
+
000h 2 ARJ ID (EA60h, aka 60000 decimal)
+ 002h 2 Header size (0=End)
+ 0 = stored (uncompressed)
+ 1 = compressed most (default) (Window=6800h=26Kbyte, Chars=255, Tree=31744)
+ 2 = compressed medium (Window=5000h=20Kbyte, Chars=72, Tree=30720)
+ 3 = compressed less (Window=2000h=8Kbyte, Chars=32, Tree=30720)
+ 4 = compressed least/fastest (Window=6800h? or 8000h?)
+ 8 = no data, no CRC ;\unknown if/where that is used (maybe only used
+ 9 = no data ;/internally, and never stored in actual files?)
+ 0 = binary file (default)
+ 1 = text file (with converted line breaks, via -t1 switch)
+ 2 = ARJ comment header (aka ARJ main file header)
+ 3 = directory name
+ 4 = volume label (aka disc name)
+ 5 = ARJ chapter label (aka begin of newer backup sections)
+ 0 GARBLED
+ 1 OLD_SECURED has old signature (with signature in Main Header?)
+ 1 ANSIPAGE ANSI codepage used by ARJ32 (for what? for "FILENAME.ARJ"?)
+ 2 VOLUME presence of succeeding volume
+ 3 ARJPROT
+ 4 PATHSYM archive name translated ("\" changed to "/")
+ 5 BACKUP obsolete
+ 6 SECURED has new signature (in security envelope?)
+ 7 ALTNAME dual-name archive
+ 0 GARBLED passworded file
+ 1 NOT USED
+ 2 VOLUME continued file to next volume (file is split)
+ 3 EXTFILE file starting position field (for split files)
+ 4 PATHSYM filename translated ("\" changed to "/")
+ 5 BACKUP_FLAG obsolete
+ 0 GARBLED ;\
+ 1 RESERVED ;
+ 2 VOLUME ; what does that mean in Chapters???
+ 3 EXTFILE ;
+ 4 PATHSYM ;/
+ 5 BACKUP obsolete < 2.50a ;-how can obsolete exist in Chapters???
+ 6 RESERVED
+ 0=MSDOS, 1=PRIMOS, 2=UNIX, 3=AMIGA, 4=MACDOS (aka MAC-OS)
+ 5=OS/2, 6=APPLE GS, 7=ATARI ST, 8=NEXT
+ 9=VAX VMS, 10=WIN95, 11=WIN32 (aka WinNT or so?)
+These methods are same as LHA's "-lh6-" compression method (albeit the three
+ARJ methods are allocating slighly less memory for the sliding window).
@@decompress_lop:
+ if dst>=dst_end then goto @@decompress_done
+ width=count_ones(max=7), len = get_bits(width) + (1 shl width)+1
+ if len=2 then
+ [dst]=get_bits(8), dst=dst+1
+ else ;len>=3
+ width=count_ones(max=4)+9, disp = get_bits(width) + (1 shl width)-1FFh
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+ ;---
+ count_ones(max):
+ num=0
+ @@lop:
+ if get_bits(1)=1 then
+ num=num+1, if num<max then goto @@lop
+ return num
+BACKUPs seem to keep old files (instead overwrting them by newer files)
+CHAPTERs seems to be a new backup type (instead of [008h].Bit5=Backup flag).
+COMMENTS can be text... with ANSI.SYS style ANSI escape codes?
+DATE/TIME stamps seem to be MSDOS format (16bit date plus 16bit time)
+EXTENDED headers seem to be unused, somewhat inspired on LHA format but with
+CRC32 instead CRC16 (unknown if the "1st extended header" can be followed by
+2nd, 3rd, and further extended headers in LHA fashion) (bug: older ARJ versions
+are reportedly treating the extended CRC32 as 16bit value).
+GARBLED seems to refer to encrypted password protected archives.
+PROTECTED seems to mean Error Correction added in newer ARJ archives.
+SECURED seems to mean archive with signature from registered manufacturers.
+SPLIT aka VOLUMEs means large ARJ's stored in fragments on multiple disks.
+TEXT (aka [00Ah]=1 aka -t1 switch aka "C Text" aka "7-bit text") converts
+linebreaks from CR,LF to LF to save memory (the uncompressed size and
+uncompressed CRC32 entries refer to that converted LF format, not to the
+original CR,LF format; the official name "7-bit text" is nonsense: All
+characters are stored as 8bit values, not 7bit values).
+TIMEBOMB causes newer ARJ versions to refuse to work (and request the user to
+check for non-existing newer updates) (eg. ARJ 2.86 is no longer working, ARJ
+2.75a does still work without timebomb).
The various ARJ versions include .TXT or .DOC files (notably, ARJ.TXT is user
+manual, TECHNOTE.TXT contains hints on the ARJ file format). There's also an
+open source version.
ARC is an old DOS and CP/M compression tool from 1985-1990. ARC files contain
+chunks in following format:
+
000h 1 Fixed ID (1Ah)
+ 001h 1 Compression Method (00h..1Fh)
+ 002h 13 Filename ("FILENAME.EXT",00h) (garbage-padded if shorter)
+ 00Fh 4 Filesize, compressed
+ 013h 4 File Timestamp in MSDOS format
+ 017h 2 CRC16 with initial value 0000h on uncompressed/decrypted file
+ 019h (4) Filesize, uncompressed ;<-- not present for Method=1
+ ... .. Compressed file data (size as stored in [00Fh])
+ Method 00h and 1Fh --> Chunksize=02h (archive/subdir end markers)
+ Method 01h --> Chunksize=19h+[0Fh] (old uncompressed ARC archives)
+ Others Methods --> Chunksize=1Dh+[0Fh] (normal case)
+ 00h End-of-archive marker (1Ah,00h)
+ 01h ARC v? Uncompressed (with short 19h-byte header)
+ 02h ARC v? Uncompressed (with normal 1Dh-byte header)
+ 03h ARC v? Packed (RLE90) Used for small files
+ 04h ARC v? Squeezed (RLE90+Huffman) Based on CP/M Squeeze
+ 05h ARC v4.00 Crunched (OldRandomizedLZW) Derived from LZWCOM
+ 06h ARC v4.10 Crunched (RLE90+OldRandomizedLZW) Alike CP/M Crunch v1.x
+ 07h ARC vBeta? Crunched (RLE90+NewRandomizedLZW) Leaked beta version?
+ 08h ARC v5.00 Crunched (RLE90+ClearGap12bitLZW) Most common ARC method
+ 09h Inofficial Squashed (ClearGap13bitLZW) Used by PKARC/PKPAK
+ 0Ah ARC v7.xx Trimmed (RLE90+LZHUF) Based on LHArc lh1
+ 0Ah Inofficial Crushed (RLE90+LZW/LZMW?) PAK
+ 0Bh Inofficial Distilled (LZ77+Huffman) PAK v2.0
+ 14h-1Dh ARC v6.0 Used/reserved for Information items:
+ 14h Archive info
+ 15h Extended File info (maybe a prefix(?) for actual file entries?)
+ 16h OS-specific info
+ 1Eh-27h ARC v6.0 Used/reserved for Control items:
+ 1Eh ARC v6.00 Subdir (nested ARC-like format, created by the "z" option)
+ 1Fh ARC v6.00 End-of-subdir marker (1Ah,1Fh)
+ 48h Not used in ARC ;\Hyper archives start with 1Ah,48h or 1Ah,53h
+ 53h Not used in ARC ;/(an unrelated format that also starts with 1Ah)
+ 80h-xxh Not used in ARC ;-Spark archives (ARC-like, with extended headers)
+ 000h 2 Item size (LEN)
+ 002h 1 Item Subtype
+ 003h .. Item Data (LEN-3 bytes)
+ Method=14h, Subtype=0 Archive description (eg. "Comment blah",00h)
+ Method=14h, Subtype=1 Archive creator program name (eg. "ARC 7.12 ...",00h)
+ Method=14h, Subtype=2 Archive modifier program name
+ Method=15h, Subtype=0 File description (eg. "Comment blah",00h)
+ Method=15h, Subtype=1 File long filename (if not MS-DOS "8.3" filename)
+ Method=15h, Subtype=2 File extended date-time info (reserved)
+ Method=15h, Subtype=3 File Icon (reserved)
+ Method=15h, Subtype=4 File attributes (see below) (eg. "RWHSN",00h)
+ Method=16h, Subtype=.. Operating system info (reserved)
+ R=ReadAccess, W=WriteAccess, H=HiddenFile, 1=SystemFile, N=NetworkShareable
+Sub-directories are implemented as nested ARC files - about same as when
+storing the sub-directory files in SUBDIR.ARC, and including that SUBDIR.ARC
+file in the main archive with Method 02h. Except that:
+It's using Method 1Eh (instead Method 02h), with filename SUBDIR (instead
+SUBDIR.ARC), and with [019h]=Nonsense (instead uncompressed size), and the
+nested file ends with Method 1Fh (instead Method 00h).
ARC does use raw RLE90 for small files (eg. 4-byte "aaaa"). ARC does also use
+RLE90 combined with other methods (perhaps because ARC wasn't very fast,
+compressing 100Kbytes could reportedly take several minutes; and without RLE90
+pre-compression it might have been yet slower).
+
90h,00h Output 90h, but DON'T change prevbyte ;<-- ARC
+ 90h,00h Output 90h, and DO set prevbyte=90h ;<-- BinHex
+ 90h,00h Output 90h, and UNKNOWN what to do ;<-- StuffIt
+ 90h,01h..03h Output prevbyte 00h..02h times (this is not useful)
+ 90h,04h..FFh Output prevbyte 03h..FEh times (this does save memory)
+ xxh Output xxh, and memorize prevbyte=xxh
+ arc_decompress_rle90:
+ src_end = src+src_size
+ prevbyte = <initially undefined in ARC source code>
+ @@decompress_lop:
+ if src>=src_end then goto @@decompress_done
+ x=[src], src=src+1
+ if x<>90h then
+ [dst]=x, dst=dst+1, prevbyte=x ;output x, and memorize prevbyte=x
+ else ;x=90h
+ x=[src], src=src+1
+ if x=00h then
+ [dst]=90h, dst=dst+1 ;output 90h, but DO NOT change prevbyte
+ if BinHex then prevbyte=90h ;for BinHex, DO change prevbyte
+ else
+ for i=1 to x-1, [dst]=prevbyte, dst=dst+1, next i
+ goto @@decompress_lop
+ 000h 2 Number of Tree entries (0..100h) (when 0, assume tree=FEFFh,FEFFh)
+ 002h N*4 Tree entries (16bit node0, 16bit node1)
+ ... .. Huffman bitstream (starting in bit0 of first byte)
+ ... .. Maybe supposedly padding to byte boundary?
+ The 16bit nodes are:
+ 0000h..00FFh Next Tree index
+ 0100h..FEFEh Invalid
+ FEFFh End of compressed data
+ FF00h..FFFFh Data values FFh..00h (these are somewhat inverted/reversed)
+ arc_decumpress_squeeze:
+ if [src]=0000h then tree=empty_tree, else tree=src+2 ;-start tree
+ InitBitstreamLsbFirst(src+2+[src]*4) ;-start bitstream
+ @@decompress_lop:
+ index=0000h ;\
+ while index<FEFFh ; huffman decode
+ index=[tree+index*4+GetBits(1)*2] ;/
+ if index>FEFFh then ;-check end code
+ [dst]=(index XOR FFh) AND FFh), dst=dst+1 ;-store data
+ goto @@decompress_lop
+ return
+ empty_tree dw FEFFh,FEFFh ;upen empty tree, ARC defines two 1bit END codes
+ arc_decompress_randomized_lzw:
+ num_free=1000h, stack=empty, oldcode=-1
+ for i=0 to FFFh, lzw_parent[i]=EEEEh ;mark all codes as unused
+ for i=0 to FFh, create_code(FFFFh,i) ;codes for 00h..FFh with parent=none
+ @@decompress_lop:
+ if src>=src_end then goto @@decompress_done
+ code=GetBitsMsbFirst(12), i=code
+ if lzw_parent[i]=EEEEh then i=oldcode, push(oldbyte) ;-for KwKwK strings
+ while lzw_parent[i]<>FFFFh, push(lzw_data[i]), i=lzw_parent[i]
+ oldbyte=lzw_data[i], [dst]=oldbyte, dst=dst+1
+ if oldcode<>-1 then create_code(oldcode,oldbyte)
+ oldcode=code
+ while stack<>empty, [dst]=pop(), dst=dst+1
+ goto @@decompress_lop
+ @@decompress_done:
+ ret
+ ;---
+ create_code(parent,data):
+ if num_free=0 then goto @@no_further_codes, else num_free=num_free-1 ;-full
+ i=(parent+data) AND 0000FFFFh ;\
+ if method=7 then i=(i*3AE1h) AND FFFh ;new "fast" randomizer ;
+ else i=(sqr(i OR 800h)/40h) AND FFFh ;old "slow" randomizer ;
+ if lzw_parent[i]=EEEEh then goto @@found_free ; alloc
+ while lzw_sibling[i]>0000h, do i=lzw_sibling[i] ;find chain end ; code
+ e=i, i=(i+65h) AND FFFh ;memorize chain end & do some random skip ;
+ while lzw_parent[i]<>EEEEh, do i=(i+1) AND FFFh ;find a free code ;
+ lzw_sibling[e]=i ;weirdly, i=0 will make it behave as sibling=none ;
+ @@found_free: ;/
+ lzw_data[i]=data, lzw_parent[i]=parent, lzw_sibling[i]=0000h ;-apply
+ @@no_further_codes:
+ ret
+This is more straight non-randomized LZW with Clear codes (and weird gaps after
+Clear codes). The compression (and gaps) are same as for nCompress (apart from
+different headers):
+CDROM File Compression nCompress.Z
+
ARC Method 8 with 1-byte header (0Ch) --> nCompress 3-byte header 1Fh,9Dh,8Ch
+ ARC Method 9 without header --> nCompress 3-byte header 1Fh,9Dh,8Dh
+This is based on LHArc lh1. Like lh1, it does have 13Ah data/len codes, and
+1000h distance codes. There are two differences:
+
Differences LHArc method lh1 ARC method 0Ah
+ Data/len codes: 100h..139h=Len(3..3Ch) 100h=End, 101h..139h=Len(3..3Bh)
+ Initial dictionary: 20h-filled Uninitialized
+ARC file/directory names are alphabetically sorted, that does apply even when
+adding files to an existing archive (they are inserted at alphabetically sorted
+locations rather than being appended at end of archive).
+ARC files can be encrypted/garbled with password (via "g" option), the chunk
+header doesn't contain any flags for indicating encrypted files (except, the
+CRC16 will be wrong when not supplying the correct password).
+ARC end-marker (1Ah,00h) may be followed by additional padding bytes, or by
+additional information from third-party tools:
+
PKARC/PKPAK adds comments (starting with "PK",AAh,55h)
+ PAK adds extended records (described in PAK.DOC file in the v2.51)
+http://fileformats.archiveteam.org/wiki/ARC_(compression_format)
+https://www.fileformat.info/format/arc/corion.htm
+http://cd.textfiles.com/pcmedic/utils/compress/arc520s.zip - source code
https://github.com/ani6al/arc - source code, upgraded with method 9 and 4
https://entropymine.wordpress.com/2021/05/11/arcs-trimmed-compression-scheme/
http://www.textfiles.com/programming/FORMATS/arc-lbr.pro - benchmarks
RAR is a compression format for enthusiastic users (who love to download the
+latest RAR version before being able to decompress those RAR files).
This format was only used by RAR 1.402, and discontinued after three months
+when RAR 1.5 got released.
+
File Header:
+ 000h 4 ID "RE~^" (aka 52h,45h,7Eh,5Eh)
+ 004h 2 Header Size (usually 0007h, or bigger when Comment/Ext1 exist)
+ 006h 1 Archive Flags (80h or xxh)
+ ... (2) Archive Comment Size ;\Only present when ArchiveFlags.bit1=1
+ ... (..) Archive Comment Data ;/
+ ... (2) Ext1 Size ;\Only present when ArchiveFlags.bit5=1
+ ... (..) Ext1 Data ;/
+ ... .. Unknown (TECHNOTE hints sth can be here, when bigger HeaderSize?)
+ Archive Flags:
+ 0 Volume (maybe related to split-volume on several floppies?)
+ 1 Comment
+ 2 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
+ 3 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
+ 4 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
+ 5 EXT1
+ 6 Unspecified (maybe unused)
+ 7 Unspecified (maybe unused, but... it's usually 1)
+ File Data blocks:
+ 000h 4 Filesize, compressed
+ 004h 4 Filesize, uncompressed
+ 008h 2 Checksum on uncompressed? file (sum=LeftRotate16bit(sum+byte[i])
+ 00Ah 2 Header Size (usually 0015h+FilenameLength)
+ 00Ch 4 File Modification Timestamp in MSDOS format
+ 010h 1 File Attribute in MSDOS format (20h=Normal)
+ 011h 1 Flags
+ 012h 1 Version (0=0.99, 1=1.00, 2=1.30) (always 2 in public version)
+ 013h 1 Filename Length
+ 014h 1 Method (00h=m0a=Stored, 03h=m3a=Default) (1..5 = fastest..best)
+ ... (2) File Comment Length ;\Only present if FileFlags.bit3=1
+ ... (..) File Comment Data ;/
+ ... .. Filename ("PATH\FILENAME.EXT", without any end marker)
+ ... .. Unknown (TECHNOTE hints sth can be here, when bigger HeaderSize?)
+ ... .. Compressed file data
+ File Flags:
+ 0 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
+ 1 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
+ 2 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
+ 3 Comment (non-english description is in 1.402's TECHNOTE.DOC)
+ 4-7 Unspecified (maybe unused)
+Overall Chunk Format:
+
000h 2 Chunk Header CRC; Lower 16bit of CRC32 on [002h..HdrSize-1 or less]
+ 002h 1 Chunk Type (72h..7Ah)
+ 003h 2 Chunk Flags
+ 005h 2 Chunk Header Size
+ 007h (4) Data block size ;<-- Only present if Flags.bit15=1
+ ... .. Header values (depending on Chunk Type and Chunk Header Size)
+ ... .. Data block ;<-- Only present if Flags.bit15=1
+ Chunk Types:
+ 72h="r"=Marker block (with "r" being 3rd byte in ID "Rar!",1Ah)
+ 73h="s"=Archive header
+ 74h="t"=File header
+ 75h="u"=Old style Comment header (nested within Type 73h/74h)
+ 76h="v"=Old style Authenticity information
+ 77h="w"=Old style Subblock
+ 78h="x"=Old style Recovery record
+ 79h="y"=Old style Authenticity information
+ 7AH="z"=Subblock
+ Chunk Flags:
+ 0-13 Flags, meaning depends on Chunk Type
+ 14 If set, older RAR versions (before 1.52 or so?) will ignore the
+ block and remove it when the archive is updated. If clear, the
+ block is copied to the new archive file when the archive is
+ updated;
+ or does "older" mean older than the "archiver version"?
+ 15 Data Block present (0=No, 1=Yes, with size at [007h])
+Type 72h, Marker Block (MARK_HEAD)
+This 7-byte ID occurs at the begin of RAR files (or after the executable in
+case of self-extracting files).
+
000h 7 ID ("Rar!",1Ah,07h,00h) (or "Rar!",1Ah,07h,01h for RAR 5.0)
+ The above ID can be somewhat parsed as normal chunk header, as so:
+ 000h 2 Faux CRC (6152h, no actual valid CRC)
+ 002h 1 Chunk Type (72h)
+ 003h 2 Faux Flags (1A21h, no actual meaning)
+ 005h 2 Chunk Header size (0007h)
+Type 73h, Archive Header (MAIN_HEAD)
+
000h 2 CRC32 AND FFFFh of fields HEAD_TYPE to RESERVED2
+ 002h 1 Chunk Type: 73h
+ 003h 2 Archive HeaderFlags
+ 005h 2 Header size (usually 000Dh) (plus Comment Block, if any)
+ 007h 2 RESERVED1 (0000h)
+ 009h 4 RESERVED2 (0000011Dh)
+ ... (..) Comment block ;<-- only present if Flags.bit1=1
+ ... (..) Reserved for additional blocks
+ Archive Header Chunk Flags:
+ 0 Volume attribute (archive volume) (split-volume? volume-label? what?)
+ 1 Archive comment present ;<-- used only before RAR 3.x
+ RAR 3.x uses "the separate comment block" and does not set this flag.
+ 2 Archive lock attribute
+ 3 Solid attribute (solid archive)
+ 4 New volume naming scheme (0=Old="name.???", 1=New="name.partN.rar")
+ 5 Authenticity information present ;<-- used only before RAR 3.x
+ 6 Recovery record present
+ 7 Chunk headers are encrypted
+ 8 First volume ;<-- set only by RAR 3.0 and later
+ 9-13 Reserved for internal use
+ 14-15 See overall Chunk Format
+Type 74h, File Header (File in Archive)
+
000h 2 CRC32 AND FFFFh on HEAD_TYPE to FILEATTR and file name
+ 002h 1 Header Type: 74h
+ 003h 2 Bit Flags
+ 005h 2 File header full size including file name and comments
+ 007h 4 Compressed file size (can be bigger than uncompressed)
+ 00Bh 4 Uncompressed file size
+ 00Fh 1 Operating system used for archiving
+ 010h 4 CRC32 on uncompressed file
+ 014h 4 File Modification Timestamp in MSDOS format
+ 018h 1 RAR version needed to extract file (Major*10+Minor) (min=0Fh=1.5)
+ 019h 1 Compression Method (usually 35h in RAR 1.52)
+ 01Ah 2 Filename size
+ 01Ch 4 File Attribute in MSDOS format (20h=Normal, Upper24bit=whatever=0)
+ ... (..) Comment block ;-Only present if Flags.bit3=1
+ ... (4) MSBs of compressed file size ;\Only present if Flags.Bit8=1
+ ... (4) MSBs of uncompressed file size ;/
+ ... .. Filename ("PATH\FILENAME.EXT")
+ ... (..) Filename extra fields (see Flags.bit9+bit11)
+ ... (8) Encryption SALT ;-Only present if Flags.Bit10=1
+ ... (..) Extended Time, variable size ;-Only present if Flags.Bit12=1
+ ... (..) * other new fields may appear here.
+ ... .. Compressed file data
+ File Chunk Flags:
+ 0 File continued from previous volume
+ 1 File continued in next volume
+ 2 File encrypted with password
+ 3 File comment present ;<-- used only before RAR 3.x
+ RAR 3.x uses the separate comment block and does not set this flag.
+ 4 Information from previous files is used (solid flag) ;RAR 2.0 and later
+ 5-7 Dictionary bits (for RAR 2.0 and later)
+ 8 64bit Filesizes (for files "larger than 2Gb")
+ 9 Unicode Filename, this can be in Dual or Single name form:
+ Dual name: "NormalName",00h,"UnicodeName" ;<-- in UTF-8 or what?
+ Single name: "UnicodeName" ;<-- in UTF-8
+ 10 Header contains 8-byte Encryption SALT entry
+ 11 Backup File (with version number ";n" appended to filename)
+ 12 Extended Time field present
+ 13-14 -
+ 15 Data Block present (always 1=With 32bit size at [007h], or 64bit size)
+ Dictionary Bits (bit5-7)
+ 00h=Dictionary Size 64 Kbyte
+ 01h=Dictionary Size 128 Kbyte ;\
+ 02h=Dictionary Size 256 Kbyte ; RAR 2.0 and up
+ 03h=Dictionary Size 512 Kbyte ;
+ 04h=Dictionary Size 1024 Kbyte ;/
+ 05h=Dictionary Size 2048 Kbyte ;\RAR ?? and up
+ 06h=Dictionary Size 4096 Kbyte ;/
+ 07h=File is a directory ;-RAR 2.0 and up
+ Operating System Indicators:
+ 00h=MS DOS
+ 01h=OS/2
+ 02h=Windows
+ 03h=Unix
+ 04h=Mac OS
+ 05h=BeOS
+ ??h=Android?
+ Compression Method:
+ 35h=Default in RAR 1.52 (used even when file is too small to be compressed)
+ xxh=Other methods (unknown values)
+ 30h=Stored (RAR 2.00 supports uncompressed small files and -m0 switch)
+ N/A=Stored (RAR 1.52 simply ignores "-m0" switch, and enforces "-m1" or so)
+Type 75h, Comment block:
+
000h 2 Header CRC of fields from HEAD_TYPE to COMM_CRC
+ 002h 1 Chunk Type: 75h
+ 003h 2 Chunk Flags (unknown if/which flags are used)
+ 005h 2 Chunk Header size (0Eh+Compressed comment size)
+ 007h 2 Uncompressed comment size
+ 009h 1 RAR version needed to extract comment
+ 00Ah 1 Packing Method
+ 00Ch 2 Comment CRC
+ 00Eh .. Compressed comment data
+Sub-formats
+The RAR format is comprised of many sub-formats that have changed over the
+years. The different formats and their descriptions are as follows:
+
* 1.3 (Does not have the RAR! signature)
+ o There is difficulty finding information regarding this sub-format.
+ * 1.5
+ o Utilizes a proprietary compression method that is not public.
+ o Considered the root model of subsequent formats.
+ o A detailed list of information can be found here.
+ * 2.0
+ o Utilizes a proprietary compression method that is not public.
+ o Based off of version 1.5 of the RAR file format.
+ * 3.0
+ o Utilizes the PPMII and Lempel-Ziv (LZSS)] algorithms.
+ o Encryption now uses cipher block chaining (AES?-CBC) instead of AES
+ o Based off of version 1.5 of the RAR file format.
+Older RAR versions did include a TECHNOTE file describing the file format of
+those versions (TECHNOTE for 1.402 exist in unknown-language only, perhaps
+russian, and TECHNOTE was discontinued somewhere between 2.5 and 2.9).
+There is official decompression source code for newer RAR versions.
File Header:
+ 000h 20 Text Message (usually "ZOO #.## Archive.",1Ah,00h,00h)
+ 014h 4 ID (FDC4A7DCh) (use this ID for detection, and ignore above text)
+ 018h 4 Offset to first Chunk (22h or 2Ah+commentsize?)
+ 01Ch 4 Offset to first Chunk, negated (-22h or -2Ah-commentsize?)
+ 020h 1+1 Version needed to extract (Major,Minor) (usually 1,01 or 2,00)
+ 022h (1) Archive Header Type (01h) ;\
+ 023h (4) Offset to Archive Comment (0=None) ; v2.00 and
+ 027h (2) Length of Archive Comment (0=None) ; up only
+ 029h (1) Version Data (01h or 03h) "HVDATA" ;/
+ File Chunks:
+ 000h 4 ID (FDC4A7DCh)
+ 004h 1 Type of directory entry (1=Old, 2=New, with extra entries)
+ 005h 1 Compression method (0=Stored, 1=LZW/default, 2=LZH)
+ 006h 4 Offset to next Chunk
+ 00Ah 4 Offset to File Data
+ 00Eh 4 File Modification Date/time in MSDOS format
+ 012h 2 CRC16 on uncompressed file (with initial value 0000h)
+ 014h 4 Filesize, uncompressed
+ 018h 4 Filesize, compressed
+ 01Ch 1+1 Version needed to extract (Major,Minor) (usually 1,00 or 2,01)
+ 01Eh 1 Deleted flag (0=Normal, 1=Deleted)
+ 01Fh 1 File structure (unknown purpose)
+ 020h 4 Offset of comment field (0=None)
+ 024h 2 Length of comment field (0=None)
+ 026h 13 Short Filename ("FILENAME.EXT",00h, garbage padded if shorter)
+ 033h (1) Unknown (4Fh) (or 00h when with comment?) ;-Type=1
+ 033h (2) Length of 038h and up (0Ah+longname+dirname) ;\
+ 035h (1) Timezone (signed) (7Fh=Unknown) ;
+ 036h (2) CRC16 on Header (000h..037h+[033h], with [036h]=0000h) ;
+ 038h (1) Length of Long Filename (0=None, use Short Filename) ;
+ 039h (1) Length of Directory name (0=None) ; Type=2
+ 03Ah (..) Long Filename ("longfilename.ext",00h) (if any) ;
+ ... (..) Directory name ("/path",00h) (if any) ;
+ ... (2) System ID (0=Unix, 1=DOS, 2=Portable) (but for DOS=0) ;
+ ... (3) File Attributes (24bit) (but for DOS=0) ;
+ ... (1) Backup Flags (bit7=On, bit6=Last, bit0-3=Generation) ;
+ ... (2) Backup File Version Number (for backup copies) ;/
+ ... 5 File Leader aka Fudge Factor ("@)#(",00h) ;\
+ ... .. File Data ; All types
+ ... .. File Comment (if any) (ASCII, "Text string",0Ah) ;/
+ Last Chunk:
+ 000h 4 ID (FDC4A7DCh)
+ 004h (30h) Zerofilled ;-Type 1
+ 004h (1) Fixed (02h) ;\
+ 005h (31h) Zerofilled ; Tyoe 2
+ 036h (2) CRC16 on Header (with [036h]=0000h) (always 83FCh) ;/
+ ... (..) Comments may be stored here (if added after archive creation)
+ ... (..) Padding, if any (1Ah-filled in some files)
+Notes:
+Method LZW is quite straight, the bitstream is fetched LSB first, codesize is
+initially 9bit, max 13bit, with two special codes (100h=Clear, 101h=Stop),
+there aren't any gaps after clear codes, the unusual part is that the bitstream
+does start with a clear code.
+Method LZH is slower, requires Zoo 2.10, and is used only when specifiying "h"
+option in commandline. LZH has 8Kbyte window, same as LHA's "lh5", with an
+extra end marker (blocksize=0000h=end).
+Comments may be stored anywhere in the middle or at the end of the archive
+(even after the zerofilled last chunk) (depending on whether the comment or
+further files where last added to the archive).
+Zoo is from 1986-1991, long filenames were supported only for OSes that did
+support them at that time (ie. not for DOS/Windows).
+When adding new files, Zoo defaults to maintain backups of old files in the
+archive (older files are marked as "deleted" via [01Eh]=1, but are kept in the
+archive; until the user issues command "P" for repacking/removing deleted
+files) (Zoo 2.xx can additionally use a "generation" limit of 0..15, which
+means to keep 0..15 older copies).
+All offsets are originated from begin of archive.
This format is called Tiny in Zoo source code, but isn't documented in the Zoo
+manual or Zoo help screen. Tiny can contain only a single file (alike gzip).
+The purpose appears to be using Tiny as temporary files when moving files from
+one archive to another (without needing to decompress & recompress the
+file), for example:
+
zoo xz source.too testfile.txt ;extract to tiny/temp file testfile.tzt
+ zoo az dest.zoo testfile.txt ;import from tiny/temp file testfile.tzt
+ 000h 2 Zoo Tiny ID (07FEh)
+ 002h 1 Type (01h)
+ 003h 1 Compression Method
+ 004h 4 Date/time in MSDOS format
+ 008h 2 CRC16 on uncompressed file, or what (?)
+ 00Ah 4 Filesize, uncompressed
+ 00Eh 4 Filesize, compressed
+ 012h 1 Major_ver
+ 013h 1 Minor_ver
+ 014h 2 Comment size (0=None)
+ 016h 13 Short Filename
+ 023h .. File data ... plus comment, if any?
+This command is documented in the Zoo manual, although it isn't actually
+supported in Zoo DOS version. The intended purpose is to use Zoo as a filter to
+speedup modem transfers.
+Going by some information snippets, the transfer format appears to be somewhat
+as so:
+
000h 2 Zoo Filter ID (32h,5Ah)
+ ... .. Compressed data
+ ... 2 CRC16 on uncompressed file, or what (?)
+nCompress is some kind of a Gzip predecessor. The program was originally called
+"compress" and later renamed to "ncompress" (and sometimes called
+"(n)compress"). Compressed files have uppercase ".Z" attached to their original
+name.
The header is rather small and lacks info on decompressed size (ie. the one
+must process the whole bitstream to determine the size, and accordingly, the
+fileformat doesn't allow padding to be appended at end of file). To detect .Z
+files, examine the first three bytes, and best also check that the leading 9bit
+codes don't exceed num_codes (with num_codes increasing from 101h and up for
+each new code).
+
000h 2 ID (1Fh,9Dh)
+ 002h 1 Mode (MaxBits(9..16) + bit7=WithClearCode) (usually 90h)
+ 003h .. ClearGap LZW compressed data (or raw LZW when mode.bit7=0)
+Below are file formats with unix/linux-style octal numbers (unknown if they are
+serious about using that formats, or if they do consider them as decently
+amusing, or whatever).
TAR and CPIO are uncompressed archives, however, they are usually enclosed in a
+compressed Gzip file (or some other compression format like nCompress, Bzip2).
0000h .. TAR Chunk(s)
+ ... 400h TAR End Marker (400h bytes zerofilled)
+ ... .. Zerofilled (whatever further padding)
+ 000h 100 text Filename ("path/filename.ext",00h)
+ 064h 8 octal Mode Flags
+ 06Ch 8 octal User ID
+ 074h 8 octal Group ID
+ 07Ch 12 octal Filesize
+ 088h 12 octal File modification time (seconds since 01 Jan 1970)
+ 094h 8 octal Header Checksum (sum of byte[0..1F3h], with [94h..9Bh]=20h)
+ 09Ch 1 text Type (00h or "0" for normal files)
+ 09Dh 100 text Whatever link name
+ 101h 8 text Tar ID (6x00h or "ustar",00h,"00" or "ustar ",00h)
+ 109h 32 text User Name (owner)
+ 129h 32 text Group Name
+ 149h 8 octal Device major ;\device number (when Type="4")
+ 151h 8 octal Device minor ;/
+ 159h 155 ? Whatever prefix ;-when ID="ustar",00h,"00" or 6x00h
+ 159h 131 ? Whatever prefix ;\
+ 1DCh 12 octal File access time ; when ID="ustar ",00h
+ 1E8h 12 octal File status-change time ;/
+ 1F4h 12 - Zeropadding to 200h-byte boundary
+ 200h .. - File data (Filesize bytes)
+ ... .. - Zeropadding to 200h-byte boundary
+ "0000123." <-- normal weirdness, with leading zeroes and end-byte ("."=00h)
+ " 123 . " <-- extra weird, leading/trailing spaces, mis-placed end-byte
+ " 123 " <-- extra weird, leading/trailing spaces, without end-byte
+ 0000h .. CPIO Chunk(s) (with actual files)
+ ... 57h CPIO Chunk (with filename "TRAILER!!!",00h)
+ ... .. Zeropadding to 200h-byte boundary (not always present)
+ Align 2, Binary, little-endian (but partial "big-endian" for 2x16bit pairs)
+ Align 2, Binary, big-endian
+ Align 1, Ascii, octal strings
+ Align 4, Ascii, hexadecimal lowercase strings, checksum=0)
+ Align 4, Ascii, hexadecimal lowercase strings, checksum=sum of bytes in file)
+ 000h 2 binary 16bit ID (71C7h) ;-little-or big endian
+ 002h 2 binary 16bit dev ;\
+ 004h 2 binary 16bit ino ; same
+ 006h 2 binary 16bit mode ; endianness
+ 008h 2 binary 16bit uid ; as in ID
+ 00Ah 2 binary 16bit gid ;
+ 00Ch 2 binary 16bit nlink ; (but be aware
+ 00Eh 2 binary 16bit rdev ; of the fixed
+ 010h 2 binary 16bit File modification time, upper 16bit ;\ ; upper/lower
+ 012h 2 binary 16bit File modification time, lower 16bit ;/ ; 16bit order
+ 014h 2 binary 16bit Filename size (including ending 00h) ; for time and
+ 016h 2 binary 16bit Filesize, upper 16bit ;\ ; filesize)
+ 018h 2 binary 16bit Filesize, lower 16bit ;/ ;/
+ 01Ah .. text Filename, terminated by 00h ("path/filename",00h)
+ ... .. binary Zeropadding to 2-byte boundary
+ ... .. binary File data (Filesize bytes)
+ ... .. binary Zeropadding to 2-byte boundary
+ 000h 6 octal 18bit ID "070707" (=71C7h)
+ 006h 6 octal 18bit dev ;\unique file id
+ 00Ch 6 octal 18bit ino ;/within archive
+ 012h 6 octal 18bit Mode (file attributes)
+ 018h 6 octal 18bit User ID of owner
+ 01Eh 6 octal 18bit Group ID
+ 024h 6 octal 18bit nlink (related to duplicated dev/ino?)
+ 02Ah 6 octal 18bit rdev (system-defined info on char/blk devices)
+ 030h 11 octal 33bit File modification time
+ 03Bh 6 octal 18bit Filename size (including ending 00h)
+ 041h 11 octal 33bit Filesize
+ 04Ch .. text Filename, terminated by 00h ("path/filename",00h)
+ ... .. binary File data (Filesize bytes)
+ 000h 6 hex 24bit ID "070701"=Without Checksum, or "070702"=With Checksum
+ 006h 8 hex 32bit ino (does that 32bit value include 16bit "dev"?)
+ 00Eh 8 hex 32bit mode
+ 016h 8 hex 32bit uid
+ 01Eh 8 hex 32bit gid
+ 026h 8 hex 32bit nlink
+ 02Eh 8 hex 32bit mtime
+ 036h 8 hex 32bit Filesize
+ 03Eh 8 hex 32bit devmajor
+ 046h 8 hex 32bit devminor
+ 04Eh 8 hex 32bit rdevmajor
+ 056h 8 hex 32bit rdevminor
+ 05Eh 8 hex 32bit Filename size (including ending 00h)
+ 066h 8 hex 32bit Checksum, sum of all bytes in file, zero when ID=070701
+ 06Eh .. text Filename, terminated by 00h ("path/filename",00h)
+ ... .. binary Zeropadding to 4-byte boundary
+ ... .. binary File data (Filesize bytes)
+ ... .. binary Zeropadding to 4-byte boundary
+RPM files contain Linux installation packages. The RPM does basically contain a
+CPIO archive bundled with additional header/records with installation
+information.
+
000h 60h File Header (officially called "Lead" instead of "Header")
+ 060h .. Signature Record (contains "Header Record" in "Signature format")
+ ... .. Padding (to 8-byte boundary)
+ ... .. Info Record (called "Header" and also uses "Signature format")
+ ... .. Archive file (usually a GZIP compressed CPIO) (called "Payload")
+ 000h 4 File ID (EDh,ABh,EEh,DBh) (aka octal string "\355\253\356\333")
+ 004h 1 Major version (3)
+ 005h 1 Minor version (0)
+ 006h 2 Type (0=Binary Package, 1=Source Package)
+ 008h 2 Architecture ID (defined in ISO/IEC 23360)
+ 00Ah 66 Package name, terminated by 00h
+ 04Ch 2 Operating System ID (1)
+ 04Eh 2 Signature Type (5)
+ 050h 16 Reserved space (officially undefined, usually zerofilled)
+ 000h 4 Record ID (8Eh,ADh,E8h,01h) (aka octal string "\216\255\350\001")
+ 004h 4 Reserved (zerofilled) (aka octal string "\000\000\000\000")
+ 008h 4 Number of Item List entries (N)
+ 00Ch 4 Size of Item Data (SIZ)
+ 010h N*10h Item List (4x32bit each: Tag, Type, Offset, Size)
+ ... SIZ Item Data (referenced via Offset/Size entries in above list)
+ 00h=NULL Not Implemented
+ 01h=CHAR Unknown, maybe unsigned 8bit (unaligned)
+ 02h=INT8 Unknown, maybe signed 8bit (unaligned)
+ 03h=INT16 Unknown, maybe signed 16bit (align2)
+ 04h=INT32 Unknown, maybe signed 323bit (align4)
+ 05h=INT64 Reserved, maybe signed 643bit (maybe align8)
+ 06h=STRING Variable, NUL terminated string (unaligned)
+ 07h=BIN Unknown, reportedly 1-byte size??? (unaligned)
+ 08h=STRING_ARRAY Variable, Sequence of NUL terminated strings (unaligned)
+ 09h=I18NSTRING Variable, Sequence of NUL terminated strings (unaligned)
+ There are dozens of required & optional tag values defined.
+ Basic extensions:
+ .cpio (CPIO)
+ .pax (CPIO for MAC)
+ .rpm (RPM installation package for RPM package manager)
+ .spec (RPM source file for creating RPM header/records)
+ .tar (TAR, tape archive)
+ Double extensions (and short forms like tgz):
+ .tgz short for .tar.gz (gzip)
+ .tbz short for .tar.bz2 (bzip2)
+ .txz short for .tar.xz (XZ)
+ .tlz short for .tar.lz (Lzip) or .tar.lzma (LZMA_Alone)
+ .tzst short for .tar.zst (zstandard)
+ .tsz short for .tar.sz (Sunzip)
+ .taz short for .tar.Z (nCompress or possibly some other compressed format)
+ .tz short for .tar.Z (nCompress or possibly some other compressed format)
+ .spm short for .src.rpm (RPM source code package)
+Below are related to MAC filesystems (where the file body consists of separate
+Data and Resource forks), and file type/creator values (resembling filename
+extensions).
MacBinary contains a single uncompressed file, used for transferring MAC files
+via network, or storing MAC files on non-MAC filesystems.
+PackIt/StuffIt archives do often have leading MacBinary headers. MacBinary
+doesn't have any unique filename extension (.bin may be used, more often it's
+using the same extension as the enclosed file, eg. .sit if it contains a
+StuffIt archive).
+Also, archives without explicit MAC support may use MacBinary format within
+compressed files (eg. LZH archives created with LHA MAC version).
+
000h 1 Old version number, must be kept at zero for compatibility
+ 001h 1 Length of filename (1..63) (though v3 says 1..31)
+ 002h 63 Filename (only "length" bytes are significant)
+ 041h 4 File type (normally expressed as four characters)
+ 045h 4 File creator (normally expressed as four characters)
+ 049h 1 Finder flags, bit8-15 (see [065h] for bit0-7)
+ 04Ah 1 Zero (must be 00h for compatibility)
+ 04Bh 2 File Vertical position within its window
+ 04Dh 2 File Horizontal position within its window
+ 04Fh 2 File Window or folder ID
+ 051h 1 Protected flag (bit0=Protected, whatever that is)
+ 052h 1 Zero (must be 00h for compatibility)
+ 053h 4 Filesize, Data Fork (0=None)
+ 057h 4 Filesize, Resource Fork (0=None)
+ 05Bh 4 File Timestamp, creation
+ 05Fh 4 File Timestamp, last modification
+ 063h 27 v1: Reserved (zerofilled)
+ 063h 2 v2/v3: Length of Get Info comment (if any, usually 0000h)
+ 065h 1 v2/v3: Finder Flags, bit0-7 (see [049h] for bit8-15)
+ 066h 6 v2: Reserved (zerofilled)
+ 066h 4 v3: ID ("mBIN"=MacBinary III)
+ 06Ah 1 v3: Script of file name (from fdScript field of an fxInfo record)
+ 06Bh 1 v3: Extended Finder flags (from fdXFlags field of fxInfo record)
+ 06Ch 8 v2/v3: Reserved (zerofilled)
+ 074h 4 v2/v3: Length of "total files" when "packed files are unpacked", uh?
+ 078h 2 v2/v3: Extended Header size (reserved for future, always 0000h)
+ 07Ah 1 v2/v3: MacBinary II uploader version (81h=v2, 82h=v3)
+ 07Bh 1 v2/v3: MacBinary II downloader minimum version (81h=v2)
+ 07Ch 2 v2/v3: CRC16-XMODEM on [000h..07Bh]
+ 07Eh 2 Reserved for computer type and OS ID (0000h)
+ ... .. Extended Header (if any, maybe stored here? when [078h]>0)
+ ... .. Padding to 80h-byte boundary
+ ... .. Data Fork (if any)
+ ... .. Padding to 80h-byte boundary
+ ... .. Resource Fork (if any)
+ ... .. Padding to 80h-byte boundary
+ ... .. Get Info comment (if any, usually none)
+Decoding binhex files is done via following steps (in that order):
+
1) ASCII to BINARY conversion (similar to BASE64)
+ 2) RLE90 decompression of whole file (header+data+resource+crc's)
+ 3) Processing the header+data+resource from the decompressed binary
+ 4) For Multipart files, repeat above steps for each part
+ The file may start with some text message, comments, description. Skip any
+ such text lines until reaching a line that contains this 45-byte ID string:
+ (This file must be converted with BinHex 4.0)
+ That line should be followed by following characters (each char representing
+ 6bit binary value, MSB first, first char is bit7-2 of first byte):
+ !"#$%&'()*+,- char(21h..2Dh) --> bin(00h..0Ch)
+ 0123456 char(30h..36h) --> bin(0Dh..13h)
+ 89 char(38h..39h) --> bin(14h..15h)
+ @ABCDEFGHIJKLMN char(40h..4Eh) --> bin(16h..24h)
+ PQRSTUV char(50h..56h) --> bin(25h..2Bh)
+ XYZ[ char(58h..5Bh) --> bin(2Ch..2Fh)
+ `abcdef char(60h..66h) --> bin(30h..36h)
+ hijklm char(68h..6Dh) --> bin(37h..3Ch)
+ pqr char(70h..72h) --> bin(3Dh..3Fh)
+ : char(3Ah) --> start/end marker
+ CR/LF char(0Dh/0Ah) --> linebreaks per 64 chars (CR and/or LF)
+ SPC/TAB char(09h/20h) --> blanks (reportedly in some files)
+ RLE90 decompression is same as in ARC files, except, code 90h,00h is handled
+ differently: ARC keeps prevbyte=unchanged, BinHex sets prevbyte=90h.
+ RLE90 compression is somewhat optional: 90h must be encoded as 90h,00h,
+ but many encoders don't bother to compress repeating bytes (eg. many files
+ contain "!!!!!!!!" chars aka uncompressed 00h-filled bytes).
+ There is no way to know the decompressed size before decompression (either
+ decompress the whole file and allocate more memory as needed, or decompress
+ only the header (filename+16h bytes) and then compute decompressed size as
+ filename+16h+data+2+resource+2 bytes).
+ The decompressed binary contains following data (similar as MacBinary):
+ 00h 1 Length of Filename (1..63)
+ 01h .. Filename ("FILENAME.EXT")
+ 01h+N 1 Version (00h)
+ 02h+N 4 File Type
+ 06h+N 4 File Creator
+ 0Ah+N 2 Finder Flags
+ 0Ch+N 4 Filesize, uncompressed, Data Fork
+ 10h+N 4 Filesize, uncompressed, Resource Fork
+ 14h+N 2 Header CRC16-XMODEM on uncompressed 14h+N bytes
+ 16h+N .. Data Fork
+ ... 2 Data Fork CRC16-XMODEM on uncompressed Data Fork
+ ... .. Resource Fork
+ ... 2 Resource Fork CRC16-XMODEM on uncompressed Resource Fork
+ ... .. Padding (might reportedly occur in some files)
+ Caution: There is a document that does claim that the CRC field should be be
+ set to 0000h before CRC calculation, and that the CRC would be computed on
+ Size+2 bytes (up to including he CRC field), that appears to be nonsense,
+ the CRC is computed on Size+0 bytes, not Size+2.
+ Emails or other text documents may contain multiple binhex files, if so,
+ each part should be reportedly followed by a line containing:
+ --- end of part NN ---
+ Unknown if there are any .hqx files with such multipart stuff.
+ Unknown if the next part starts with "(This file must.." or just with ":".
+MAC File Type,Creator IDs = "PIT ","PIT " \<-- normal (=uncompressed?)
+MAC File Type,Creator IDs = "PIT ","UPIT" \<-- other (=compressed?)
+
Bitstream for Uncompressed File Entries:
+ 32bits Uncompressed Header[000h..003h] (Method/Crypto="PMag")
+ ..bits Uncompressed Header[004h..061h] (uncompressed size = 5Eh)
+ ..bits Uncompressed Data+Resource+CRC (uncompressed size = Data+Rsrc+2)
+ Bitstream for Compressed File Entries:
+ 32bits Uncompressed Header[000h..003h] (Method/Crypto="PMa4")
+ ..bits Compressed Huffman Tree (for decoding following bits)
+ ..bits Compressed Header[004h..061h] (uncompressed size = 5Eh)
+ ..bits Compressed Data+Resource+CRC (uncompressed size = Data+Rsrc+2)
+ ..bits Padding to 8bit-boundary (byte align next File Entry)
+ Bitstream for Archive End Marker (after last file):
+ 32bits Uncompressed Header[000h..003h] (Method/Crypto="PEnd")
+ File Entry Format:
+ 000h 4 Method/Crypto (usually "PMag"=Uncompressed, "PMa4"=Huffman)
+ 004h 1 Filename length
+ 005h 63 Filename ("FILENAME", garbage padded)
+ 044h 4 File Type
+ 048h 4 File Creator
+ 04Ch 2 Finder flags
+ 04Eh 2 Locked?
+ 050h 4 Filesize, uncompressed, Data fork
+ 054h 4 Filesize, uncompressed, Resource fork
+ 058h 4 Timestamp, creation
+ 05Ch 4 Timestamp, modification
+ 060h 2 CRC16-XMODEM on [004h..05Fh]
+ ... .. Data Fork
+ ... .. Resource Fork
+ ... 2 CRC16-XMODEM on uncompressed Data+Resource forks
+ Method/Crypto:
+ "PEnd" = Archive End marker (4-byte end marker, without filename etc.)
+ "PMag" = Uncompressed
+ "PMa1" = Uncompressed, Encrypted Simple
+ "PMa2" = Uncompressed, Encrypted DES
+ "PMa3" = Uncompressed, Encrypted reserved
+ "PMa4" = Huffman
+ "PMa5" = Huffman, Encrypted Simple
+ "PMa6" = Huffman, Encrypted DES
+ "PMa7" = Huffman, Encrypted reserved
+ Decompression: ;for PackIt (and also for StuffIt method 03h)
+ InitBitstreamMsbFirst(src) ;-src is after "PMa4" PackIt ID
+ tree=GetMem(200h*4) ;-alloc tree (probably less needed)
+ num_entries=0 ;\init tree
+ root=GetTreeEntry ;/
+ while dst<dst_end ;-decompress, till end...
+ index=root ;\
+ while index<FF00h ; huffman decode
+ index=[tree+index*4+GetBits(1)*2] ;/
+ [dst]=index AND FFh, dst=dst+1 ;-store data
+ return
+ ;---
+ GetTreeEntry:
+ if GetBits(1)=1 then
+ return GetBits(8)+FF00h ;-final data entry
+ else
+ index=num_entries ;-current index
+ num_entries=num_entries+1 ;-alloc next index
+ [tree+index*4+0*2] = GetTreeEntry ;-recursive call for node0
+ [tree+index*4+1*2] = GetTreeEntry ;-recursive call for node1
+ return index
+MAC File Type,Creator IDs = "SIT!","SIT!" (version=01h).
+MAC File Type,Creator IDs = "SITD","SIT!" (version=02h).
+MAC File Type,Creator IDs = "APPL","STi0" (whatever, with ID="ST65")
+
StuffIt Archive Header:
+ 000h 4 ID ("SIT!", short for StuffIt)
+ Reportedly, there are several alternate IDs:
+ "SIT!","ST46","ST50","ST60","ST65","STin","STi2","STi3","STi4"
+ Unknown why, and if some do differ somehow (ST65 appears to be
+ same as SIT!) (for STi, the "i" might be short for it? installer?)
+ 004h 2 Number of entries in root directory
+ 006h 4 Total size of archive
+ 00Ah 4 ID ("rLau", short for Raymond Lau)
+ 00Eh 1 Version number (01h=v1.x-v1.5.x, 02h=v1.6-v4.5)
+ 00Fh 7 Reserved (zerofilled) ;-when version=01h
+ 00Fh 1 Unknown (C6h or FFh) ;\
+ 010h 4 Offset to first root entry (16h or elsewhere!) ; when version=02h
+ 014h 2 Unknown (0001h or FFFFh) ;/
+ File Entries:
+ 000h 1 Compression method, Resource fork
+ 001h 1 Compression method, Data fork
+ 002h 1 Filename length (1..63 for version=01h, 1..31 for version=02h)
+ 003h 1Fh Filename ("FILENAME.EXT", garbage padding)
+ 022h 20h Filename further chars ;-when version=01h
+ 022h 2 Filename+size CRC ;\
+ 024h 2 Unknown (always 0000h or 0986h?) ; when version=02h
+ 026h 4 Unknown Resource fork related ;maybe window ;
+ 02Ah 4 Unknown Data fork related ;coords ? ;
+ 02Eh 1 Unknown Data fork related ;
+ 02Fh 1 Unknown Resource fork related ;
+ 030h 2 Number of child entries (excluding End marker) ;
+ 032h 4 Offset to previous entry ;
+ 036h 4 Offset to next entry ;
+ 03Ah 4 Offset to parent entry ;
+ 03Eh 4 Offset to first child (or -1 for file entries) ;/
+ 042h 4 File type (eg. "APPL")
+ 046h 4 File creator (eg. "ACTA")
+ 04Ah 2 Finder flags (2100h)
+ 04Ch 4 Creation date
+ 050h 4 Modification date
+ 054h 4 Filesize, uncompressed, Resource fork (0=None)
+ 058h 4 Filesize, uncompressed, Data fork (0=None)
+ 05Ch 4 Filesize, compressed, Resource fork (0=None)
+ 060h 4 Filesize, compressed, Data fork (0=None)
+ 064h 2 CRC16 on uncompressed(?) Resource fork (0=None)
+ 066h 2 CRC16 on uncompressed(?) Data fork (0=None)
+ 068h 1 Pad bytes for encrypted Resource? (00h)
+ 069h 1 Pad bytes for encrypted Data? (00h)
+ 06Ah 2 Unknown Data fork related (0000h, or 0004h=Encrypted?)
+ 06Ch 2 Unknown Resource fork related (0000h, or 0004h=Encrypted?)
+ 06Eh 2 CRC16 on Header [000h..06Dh] with initial=0000h
+ 070h .. Compressed Data, Resource fork (if any) (size=[05Ch])
+ ... .. Compressed Data, Data fork (if any) (size=[060h])
+ StuffIt Methods:
+ 00h Uncompressed
+ 01h RLE90 (same as... unknown if this is like BinHex, or like ARC)
+ 02h ClearGap LZW (same as nCompress, 14bit, with Clear(+gap), no Stop code)
+ 03h Huffman (same as PackIt "PMa4" method)
+ 05h LZHUF (same as LHA "lh1" method)
+ 06h Fixed Huffman Segmented. PackBits, then optional Huffman coding.
+ The set of Huffman codes is predefined, but the meaning
+ of a code can be different in each segment
+ 08h MW (Miller-Wegman, presumably LZMW)
+ 0Dh LZ+Huffman (?) ;-StuffIt and StuffIt5
+ 0Eh Installer (uh?)
+ 0Fh Arsenic (BWT and arithmetic coding) ;-StuffIt5 only?
+ 1xh Encrypted methods (same as above, plus encryption)
+ 20h Folder start ;\StuffIt (not StuffIt5)
+ 21h Folder end ;/
+ Folder start
+ Child entries
+ Folder end
+ Folder start
+ Child entries
+ Folder end
+ StuffIt Archive Header:
+ 000h 82 ID "StuffIt (c)1997",...,"/StuffIt/",0Dh,0Ah,1Ah,00h)
+ 052h 1 Version (always 05h)
+ 053h 1 Flags (can be 00h, 10h, 80h) (bit4=what?, bit7=Encrypted)
+ 054h 4 Total size of archive
+ 058h 4 Offset to first entry in root directory (64h, plus Extra Data)
+ 05Ch 2 Number of entries in root directory
+ 05Eh 4 Same as [058h] (maybe one is 1st entry, and other is Header size)?
+ 062h 2 Header CRC16 on [000h..[05xh]-1] with [062h]=0000h and initial=0
+ 064h .. Extra Data (see below)
+ ... .. File/Folder entries
+ Extra data can be:
+ None (when [58h]=64h) ;with Flags=00h
+ 05h,76h,35h,B9h,87h,11h ;maybe 05h=Length? ;with Flags=80h=crypto
+ 0Dh,A5h,A5h,"Reserved",A5h,A5h,00h) ;maybe 0Dh=Length? ;with Flags=10h=what?
+ File/Folder entries:
+ 000h .. Base Header
+ ... .. OS Header (depending on OS Type in Base Header)
+ ... .. Resource fork (if any) (MAC only, not Windows)
+ ... .. Data fork (if any)
+ Base Header:
+ 000h 4 ID (A5A5A5A5h) (or B4B4B4B4h=corrupted charset conversion maybe?)
+ 004h 1 OS Type (1=Mac, 3=Windows)
+ 005h 1 Unknown (0)
+ 006h 2 Base Header size (41h) (30h+IV?+Filename+Comment)
+ 008h 1 Unknown (0) (maybe Flags MSB?)
+ 009h 1 Flags (bit3=Comment, bit6=Folder, bit5=Encrypted)
+ 00Ah 4 Timestamp, Creation (Mac OS format, seconds since 1904)
+ 00Eh 4 Timestamp, Modification (Mac OS format, seconds since 1904)
+ 012h 4 Offset of previous entry (0=None)
+ 016h 4 Offset of next entry (0=None)
+ 01Ah 4 Offset of parent folder entry (0=None)
+ 01Eh 2 Filename size (F)
+ 020h 2 Base Header CRC-16 on [000h..[006h]-1]
+ 022h (4) Offset of first child entry in folder (FFFFFFFFh=End) ;\Folder
+ 026h (4) Size of complete directory ; (if Flags
+ 02Ah (4) Unknown ; bit6=1)
+ 02Eh (2) Number of child entries (excluding folder End marker) ;/
+ 022h (4) Data fork uncompressed size ;\
+ 026h (4) Data fork compressed size ;
+ 02Ah (2) Data fork CRC-16 (0 for method 0Fh) ; File
+ 02Ch (2) Data fork Unknown (0000h) ; (if Flags
+ 02Eh (1) Data fork compression method (00h,0Dh,0Fh) ; bit6=0)
+ 02Fh (1) Data fork Encryption IV? size ;
+ ... (..) Data fork Encryption IV? data ;/
+ ... .. File/Folder name ("FILENAME.EXT")
+ ... (2) Comment size (K) ;\Comment
+ ... (2) Comment Unknown (0) ; (if Flags
+ ... (..) Comment data ;/bit3=1)
+ OS Header for Mac (OS=1):
+ 000h 2 Flags2 (bit0=HasResource, bit4=same as archive header [053h] ?)
+ 002h 2 CRC16 on OS Header (with [002h]=0000h, initial=0)
+ 004h 4 Mac OS file type ;\
+ 008h 4 Mac OS file creator ; as so for Files
+ 00Ch 2 Mac OS Finder flags ; (seems to contain
+ 00Eh 2 Mac OS Unknown ; other stfuff/junk
+ 010h 4 Mac OS Unknown ; for Folders)
+ 014h 4 Mac OS Unknown ;
+ 018h 4 Mac OS Unknown ;
+ 01Ch 4 Mac OS Unknown ;
+ 020h 4 Mac OS Unknown ;/
+ 024h (4) Resource fork uncompressed size ;\
+ 028h (4) Resource fork compressed size ; only if
+ 02Ch (2) Resource fork CRC-16 (0 for method 0Fh) ; Flags2
+ 02Eh (2) Resource fork Unknown ; bit0=1
+ 030h (1) Resource fork compression method ;
+ 031h (1) Resource fork Encryption IV? size ;
+ ... (..) Resource fork Encryption IV? data ;/
+ OS Header for Windows (OS=3):
+ 000h 2 Flags 2 (bit4=same as archive header [053h] ?)
+ 002h 2 CRC16 on OS Header (with [002h]=0000h, initial=0)
+ 004h 4 Windows File Attribute (20h=Normal, 10h=Folder)
+ 008h 08h Windows Zerofilled
+ 010h 4 Windows Timestamp last accessed?
+ 014h 4 Windows Unknown (0005xxxxh)
+ 018h 08h Windows Zerofilled
+ StuffIt Archive Header:
+ 000h 8 ID "StuffIt!" (reportedly "StuffIt?" also exists)
+ 008h .. Unknown...
+MAC File Type,Creator IDs = "PACT","CPCT".
+Compact Pro (originally called Compactor) was a MAC archiver competing with
+StuffIt. There's also a DOS tool (ExtractorPC) for extracting .cpt files on PCs
+(albeit released in .EXE.sit.hqx format, making it unlikely that PC users could
+have used it).
+
Archive header:
+ 000h 1 File ID (always 01h)
+ 001h 1 Volume number (01h for single-volume, Other=Unknown)
+ 002h 2 Random Volume ID? (...must be same in all split volume files?)
+ 004h 4 Offset to Footer (from begin of file)
+ 008h .. Compressed files (resource+data fork pairs)
+ ... .. Footer (directory information)
+ Footer format:
+ 000h 4 CRC32 XOR FFFFFFFFh on following bytes
+ 004h 2 Number of entries in root folder (including all child entries)
+ 006h 1 Comment length (usually 00h=None)
+ 007h N Comment
+ 007h+N .. File/Folder entries
+ Folder entries, with [000h].bit=1:
+ 000h 1 Foldername length (N), plus bit7=Type (1=Folder)
+ 001h N Foldername ("FOLDERNAME")
+ 001h+N 2 Number of entries in this folder (including all child entries)
+ File entries, with [000h].bit=0:
+ 000h 1 Filename length (N), plus bit7=Type (0=File)
+ 001h N Filename ("FILENAME.EXT")
+ 001h+N 1 Volume number (01h for single-volume, Other=Unknown)
+ 002h+N 4 Offset to compressed Resource (followed by compressed Data)
+ 006h+N 4 File type
+ 00Ah+N 4 File creator
+ 00Eh+N 4 Timestamp, creation (seconds since 1904)
+ 012h+N 4 Timestamp, modification (seconds since 1904)
+ 016h+N 2 Finder flags
+ 018h+N 4 CRC32 XOR FFFFFFFFh on uncompressed Resource + Data forks
+ 01Ch+N 2 Method/Flags (see below)
+ 01Eh+N 4 Filesize, uncompressed, Resource fork
+ 022h+N 4 Filesize, uncompressed, Data fork
+ 026h+N 4 Filesize, compressed, Resource fork
+ 02Ah+N 4 Filesize, compressed, Data fork
+ Method/Flags:
+ 0 Encryption (0=None, 1=Encrypted, unknown how)
+ 1 Method for Resource fork (0=RLE8182, 1=RLE8182+LZSSHUF)
+ 2 Method for Data fork (0=RLE8182, 1=RLE8182+LZSSHUF)
+ 3-15 Unknown/unused (0)
+ Note: RLE8182 and RLE8182+LZSSHUF are also used by Mac DiskDoubler.
+ This is same as RLE90, with two-byte escape code (81h,82h instead of 90h):
+ 81h,82h,00h Output 81h,82h
+ 81h,82h,01h..03h Output prevbyte 00h..02h times (this is not useful)
+ 81h,82h,04h Output prevbyte 03h times (useful if prev=81h, next=82h)
+ 81h,82h,05h..FFh Output prevbyte 04h..FEh times (this does save memory)
+ 81h,xxh Output 81h, and then process xxh
+ 81h,padding Output 81h, at end of file (with padding<>82h)
+ xxh Output xxh (unless it is 81h)
+ Note: prevbyte is the previous output byte (ie. that stored at [dst-1]).
+ If the uncompressed file ends with 81h, then the compressed file MUST contain
+ a dummy padding byte (the RLE decoder in macutils sets a prefix flag upon 81h,
+ but doesn't output it to dst until receiving the padding byte, which could be
+ 81h, or any value other than 82h).
+ This uses LZSS-style flag bits (to distinguish between data and len/disp),
+ combined with three Huffman trees (for data, len, disp values). The sliding
+ window is 2000h bytes (8Kbytes). The format appears to be a simplified variant
+ or LHA compression (but gets complicated by inventing weird corner cases).
+ if uncompressed_size=0 then goto @@all_done ;-empty (eg. for unused forks)
+ [dst+0000h..1FFCh]=uninitialized ;\
+ [dst+1FFDh..1FFFh]=00h,00h,00h ; prefill sliding window
+ dst+dst+2000h ;/
+ @@block_lop:
+ InitBitstreamMsbFirst(src)
+ GetLzsshufTree(data_tree,100h) ;tree for data=00h..FFh
+ GetLzsshufTree(len_tree,40h) ;tree for len=00h..3Fh (0,1 usually unused)
+ GetLzsshufTree(disp_tree,80h) ;tree for dispUpper7bit=00h..7Fh
+ block_org=src, blocksize=0 ;block origin (after above trees)
+ @@decompress_lop:
+ if src>=src_end then goto @@all_done ;<-- this may overshoot on padding bits
+ if out>=out_end then goto @@all_done ;<-- more precise; if RleOnTheFly
+ if blocksize>=1FFF0h AND type=CompactPro then goto @@block_done
+ if blocksize>=0FFF0h AND type=Disc Double then goto @@block_done
+ if GetBits(1)=1 then
+ [dst]=GetHuffCode(data_tree), dst=dst+1, blocksize=blocksize+2
+ else
+ len=GetHuffCode(len_tree)+0, blocksize=blocksize+3
+ disp=GetHuffCode(disp_tree)*40h+GetBits(6), if disp=0000h then disp=2000h
+ for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
+ if RleOnTheFly then forward above byte(s) to RLE (which advances "out" ptr)
+ goto @@decompress_lop
+ @@block_done:
+ ;the decoder does prefetch data in 16bit units, and it does always have
+ ;16..31 bits prefetched, these bits are discarded at block end...
+ src=src+2+((src-block_org) AND 1) ;discard 16..31 bits (till 16bit-boundary)
+ goto @@block_lop ;start next block, with new trees
+ @@all_done:
+ ret
+ num=GetBits(8)*2, if num>max then goto error ;number of symbols (00h and up)
+ for i=0 to num-1, codesizes[i]=GetBits(4) ;sizes (1..15 bits, or 0=unused)
+ lzh_explode_tree(tree,codesizes,num) ;alike LHA trees
+ ret
+ Disp=0 acts as Disp=2000h (don't care when using ringbuf[index AND 1FFFh])
+ Len=0..1 could be definied in the len_tree (but are usually size=0bit=unused)
+ Unknown if disp_tree & len_tree can be empty (when using data_tree only)?
+ RLE ending with 81h,padding should only output 81h (see RLE8182 description)
+ A few .cpt files (eg. ABC's-1.09.cpt.hqx\..\Colin's ABC's\Message.h) have
+ incomplete trees (like only one disp code, "0"=DispUpper7bit=00h, without
+ defining any further huffman codes like "1" or "1xxx").
+ This isn't much of a problem (except, one may need to remove incomplete tree
+ error checking in the "lzh_explode_tree" function).
+ End of Last Block is usually determined by forwarding the LZSSHUF output
+ directly to the RLE8182 decompressor (which does then check if uncompressed
+ size is reached) (marked "RleOnTheFly" in above sample code).
+ Alternately, one could decompress in separate steps (LZSSHUF to tempbuf, and
+ then tempbuf to RLE8182), but that requires to deal with padding bits.
+ - padding seems to be 16..31 bits (?) alike at end of blocksize
+ - padding bits are (always?) zeroes, which act as flag=0=compressed
+ - compressed data occupies at least flg(1),len(1),disp(1),displsbs(6)=9bits
+ That can lead to decoding a few extra codes (with lengths up to 3Fh each),
+ so the tempbuf must have trailing space for writing that garbage padding.
+ And, those padding bits tend to translate to disp=0000h (aka disp=2000h),
+ which can cause reads from the whole sliding window, so tempbuf requires
+ 2000h leading bytes to avoid page faults (not just the 3 initialized bytes).
+The abbreviation SEA (and extension .sea) is used for several self-extracting
+MAC archives. The Resource fork contains an executable (as indicated by
+Type="APPL") which contains the decompressor, and the Data fork contains the
+archive.
+
MAC File Type,Creator IDs = "APPL","aust" (StuffIt).
+ MAC File Type,Creator IDs = "APPL","EXTR" (CompactPro).
+ MAC File Type,Creator IDs = "APPL","DSEA" (DiskDoubler).
+ StuffIt .sea files: These are often raw StuffIt archives (apparently
+ somebody had removed the MacBinary header and the resource fork with
+ the decompressor).
+ CompactPro .sea files: These are often stored as MacBinary without 80h-byte
+ padding appended to the Data and Resource forks.
+ That applies to "Santa.sea" but other such files have OTHER corruptions,
+ which may include wrong Size and/or garbage in reserved MacBinary fields?
+The Data fork contains the "normal data" part of the file (eg. anything like
+.TXT .DOC .GIF .JPG .WAV .ZIP .LZH .SIT .PIT .CPT etc).
The Resource fork can contain executable code resources (similar to .EXE files;
+with File Type="APPL"), and various other resources (fonts, icons, text strings
+for dialog boxes, etc). Those resources are stored in a filesystem-style
+archive and can be accessed with IDs and/or name strings.
+
Resource fork Header:
+ 000h 4 Offset to Resource Data section (from start of file) (100h)
+ 004h 4 Offset to Resource Map section (from start of file) (100h+DataSiz)
+ 008h 4 Size of Resource Data section (can be 0=None)
+ 00Ch 4 Size of Resource Map section
+ 010h F0h Unknown (can contain filename/type.. MAYBE just garbage padding?)
+ 100h .. Resource Data section, contains Data Record(s)
+ ... .. Resource Map section
+ Data Record(s) in Resource Data section (usually at offset 100h and up):
+ 000h 4 Size of Data for this record
+ 004h .. Data for this record
+ Resource Map section:
+ 000h 4 Offset to Resource Data section (from start of file) ;\
+ 004h 4 Offset to Resource Map section (from start of file) ; same as in
+ 008h 4 Size of Resource Data section ; header
+ 00Ch 4 Size of Resource Map section ;/
+ 010h 4 Zero (internally used by Resource Manager, nextResourceMap)
+ 014h 2 Zero (internally used by Resource Manager, fileRef)
+ 016h 2 Map Attributes
+ 0-4 Zero (reserved)
+ 5 Zero (internally used by Resource Manager, changed)
+ 6 Zero (internally used by Resource Manager, need compression)
+ 7 Resource map is read-only
+ 8-15 Zero (reserved)
+ 018h 2 Offset to Type List (from start of resource map) (usually 1Ch ?)
+ 01Ah 2 Offset to Name List (from start of resource map)
+ ... .. Type List
+ ... .. Resource List (with one or more entry for each entry in Type List)
+ ... .. Name List (each name consists of 8bit NameLength, plus name string)
+ Type List follows the header and contains an array of resource type records.
+ 000h 2 Number of Type Records, minus one (FFFFh=None, 0000h=One, etc.)
+ 002h N*8 Type Records
+ Type Record format:
+ 000h 4 Resource Type (four-character constant)
+ 004h 2 Number of Resource List entries, minus one (0000h=One, etc.)
+ 006h 2 Offset to first Resource List entry (from start of Type List)
+ Resource List entries:
+ 000h 2 Resource ID (C000h..FFFFh=Special/Owned)
+ 002h 2 Offset to Resource Name (from start of Name List) (FFFFh=None)
+ 004h 1 Attributes
+ 0 Resource data is compressed (0=No, 1=Compressed)
+ 1 Zero (internally used by Resource Manager, changed)
+ 2 Load Resource as soon as file is opened (0=No, 1=Preload)
+ 3 Resource is read-only (0=No, 1=Protected)
+ 4 Resource may not be moved in memory (0=No, 1=Locked)
+ 5 Resource may be paged out of memory (0=No, 1=Purgeable)
+ 6 Load Resource to (0=Application heap, 1=System Heap)
+ 7 Zero (reserved)
+ 005h 3 Offset to Resource Data (from start of Resource Data section)
+ 008h 4 Zero (internally used by Resource Manager, resourcePtr)
+ Note: Some (or all?) 16bit offsets are reportedly signed (max 32Kbyte), the
+ 24bit offsets are reportedly unsigned (max 16Mbyte).
+ Compressed resource have a standarized header, the decompression function(s)
+ are supposed to be stored in separate "dmcp" resource (unknown if the OS is
+ also providing standard decompression functions).
+ 000h 4 ID (always A89F6572h for compressed resource)
+ 004h 2 Always 0012h (maybe compression header size)
+ 006h 1 Type (08h=Type8, 09h=Type9)
+ 007h 1 Always 01h
+ 008h 4 Uncompressed resource size
+ 00Ch 1 For Type8: workingBufferFractionalSize ;\
+ 00Dh 1 For Type8: expansionBufferSize ; Type8
+ 00Eh 2 For Type8: dcmpID (ID in "dmcp" decompress resource) ;
+ 010h 2 For Type8: Zero (reserved?) ;/
+ 00Ch 2 For Type9: dcmpID (ID in "dmcp" decompress resource) ;\Type9
+ 00Eh 4 For Type9: decompressor_specific_parameters_with_io ;/
+ 012h .. Compressed Resource Data
+Owned Resources (with Resource ID=C000h..FFFFh):
https://github.com/kreativekorp/ksfl/wiki/Macintosh-Resource-File-Format
+The upper 5bit (mask F800h) indicate the resource type of the owner, the middle
+6bit (mask 07E0h) indicate the resource id of the owner, and the lower 5bit
+(mask 001Fh) indicate the "sub-id" of the owned resource.
+
ID MSBs Owner Type Notes
+ C000h DRVR driver or desk accessory
+ C800h WDEF window definition: code to draw windows
+ D000h MDEF menu definition: code to draw menus
+ D800h CDEF control definition: code to draw UI widgets
+ E000h PDEF printer driver
+ E800h PACK utility code package/library used by the Mac OS
+ F000h cdev control panel; owner id is set to 1
+ F800h reserved reserved for future use
+Most PSX discs have huge zerofilled dummy files with about 32Mbytes, using
+filenames like DUMMY, NUL, NULL, or ZNULL, this is probably done to tweak the
+disc to have valid sector numbers at the end of disc (to help the drive head to
+know which sector it is on).
+Of course, Sony could as well pad the discs with longer Lead-Out areas, but the
+dummy files may have been needed during development with CDRs (though burning
+such large files doesn't exactly speed up development).
+There are different ways to make sure that the file is at end of the disc:
+- Some CDROM burning tools may allow to specify which file is where
+- Some games have the file alphabetically sorted as last file in last folder
+- Some games have the file declared as audio track
+- Some games (additionally) have large zeropadding at end of their archive file
To reduce seek times, it can make sense to have the boot files & small
+files at the begin of the disc.
+Some games seem to use alphabetically sorted file/folder names to tweak Movies
+and XA-audio to be located at the end of disc (eg. using ZMOVIE as folder
+name).
Contains the sector data, recorded at 930h bytes per sector. Unknown if other
+sizes are also used/supported (like 800h bytes/sector, or even images with
+mixed sizes of 800h and 930h for different tracks).
Contains subchannel data, recorded at 60h bytes per sector.
+
00h..0Bh 12 Subchannel P (Pause-bits, usually all set, or all cleared)
+ 0Ch..17h 12 Subchannel Q (ADR/Control, custom info, CRC-16-CCITT)
+ 18h..5Fh .. Subchannel R..W (usually zero) (can be used for CD-TEXT)
+Contains Lead-in info in ASCII text format. Lines should be terminated by
+0Dh,0Ah. The overall CCD filestructure is:
+
[CloneCD] ;File ID and version
+ [Disc] ;Overall Disc info
+ [CDText] ;CD-TEXT (included only if present)
+ [Session N] ;Session(s) (numbered 1 and up)
+ [Entry N] ;Lead-in entries (numbered 0..."TocEntries-1")
+ [TRACK N] ;Track info (numbered 1 and up)
+ Version=3 ;-version (usually 3) (rarely 2)
+ TocEntries=4 ;-number of [Entry N] fields (lead-in info blocks)
+ Sessions=1 ;-number of sessions (usually 1)
+ DataTracksScrambled=0 ;-unknown purpose (usually 0)
+ CDTextLength=0 ;-total size of 18-byte CD-TEXT chunks (usually 0)
+ CATALOG=NNNNNNNNNNNNN ;-13-digit EAN-13 barcode (included only if present)
+ Entries=N ;number of following entries (CDTextLength/18) (not /16)
+ Entry 0=80 00 NN NN NN NN NN NN NN NN NN NN NN NN NN NN ;entry 0
+ Entry 1=80 NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN ;entry 1
+ ...
+ Entry XX=8f NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN ;entry N-1
+ Note: Each entry contains 16 bytes (ie. "18-byte CD-TEXT" with CRC excluded)
+ "NN NN NN.." consists of 2-digit lowercase HEX numbers (without leading "0x")
+ PreGapMode=2 ;-unknown purpose (usually 1 or 2) (or 0)
+ PreGapSubC=1 ;-unknown purpose (usually 0 or 1)
+[Entry 0..2] are usually containing Point A0h..A2h info. [Entry 3..N] are
+usually TOC info for Track 1 and up.
+
Session=1 ;-session number that this entry belongs to (usually 1)
+ Point=0xa0 ;-point (0..63h=Track, non-BCD!) (A0h..XXh=specials) Q2
+ ADR=0x01 ;-lower 4bit of ADR/Control (usually 1) Q0.lo
+ Control=0x04 ;-upper 4bit of ADR/Control (eg. 0=audio, 4=data) Q0.hi
+ TrackNo=0 ;-usually/always 0 (as [Entry N]'s are in Lead-in) Q1
+ AMin=0 ;\current MSF address Q3
+ ASec=0 ; (dummy zero values) (actual content Q4
+ AFrame=0 ; would be current lead-in position) Q5
+ ALBA=-150 ;/ALBA=((AMin*60+ASec)*75+AFrame)-PreGapSize
+ Zero=0 ;-probably reserved byte from Q channel Q6
+ PMin=1 ;\referenced MSF address (non-BCD!), for certain Q7
+ PSec=32 ; Point's, PMin may contain a Track number, and PSec Q8
+ PFrame=0 ; the disc type value (that without non-BCD-glitch) Q9
+ PLBA=6750 ;/PLBA=((PMin*60+PSec)*75+PFrame)-PreGapSize
+ MODE=2 ;-mode (0=Audio, 1=Mode1, 2=Mode2)
+ ISRC=XXXXXNNNNNNN ;-12-letter/digit ISRC code (included only if present)
+ INDEX 0=N ;-1st sector with index 0, missing EVEN if any?
+ INDEX 1=N ;-1st sector with index 1, usually same as track's PLBA
+ INDEX 2=N ;-1st sector with index 2, if any
+ etc.
+The .CCD file doesn't define the "PreGapSize" (the number of missing sectors at
+begin of first track). It seems to be simply constant "PreGapSize=150". Unless
+one is supposed to calculate it as
+"PreGapSize=((PMin*60+PSec)*75+PFrame)-PLBA".
+The SectorSize seems to be also constant, "SectorSize=930h".
All Min/Sec/Frame/Track/Index values are expressed in non-BCD, ie. they must be
+converted to BCD to get the correct values (as how they are stored on real
+CDs). Exceptions are cases where those bytes have other meanings: For example,
+"PSec=32" does normally mean BcdSecond=32h, but for Point A0h it would mean
+DiscType=20h=CD-ROM-XA).
+The Point value is also special, it is expressed in hex (0xNN), but nonetheless
+it is non-BCD, ie. Point 1..99 are specified as 0x01..0x63, whilst, Point
+A0h..FFh are specified as such (ie. as 0xA0..0xFF).
Version=1 doesn't seem to exist (or it is very rare). Version=2 is quite rare,
+and it seems to lack the [TRACK N] entries (meaning that there is no MODE and
+INDEX information, except that the INDEX 1 location can be assumed to be same
+as PLBA). Version=3 is most common, this version includes [TRACK N] entries,
+but often only with INDEX=1 (and up, if more indices), but without INDEX 0 (on
+Track 1 it's probably missing due to pregap, on further Tracks it's missing
+without reason) (so, only ways to reproduce INDEX=0 would be to guess it being
+located 2 seconds before INDEX=1, or, to use the information from the separate
+.SUB file, if that file is present; note: presence of index 0 is absolutely
+required for some games like PSX Tomb Raider 2).
The [Entry N] fields are usually containing Point A0h,A1h,A2h, followed by
+Point 1..N (for N tracks). For multiple sessions: The session is terminated by
+Point B0h,C0h. The next session does then contain Point A0h,A1h,A2h, and Point
+N+1..X (for further tracks). The INDEX values in the [TRACK N] entries are
+originated at the begin of the corresponding session, whilst PLBA values in
+[Entry N] entries are always originated at the begin of the disk.
Sector Data (sector 00:00:00 and up) ;-body
+ Number of Sessions (1 byte) <--- located at "Filesize-Footersize"
+ Session Block for 1st session (15 bytes) ;\
+ nnn-byte info for 1st track ; 1st session
+ nnn-byte info for 2nd track (if any) ;
+ etc. ;/
+ Session Block for 2nd session (15 bytes) ;\
+ nnn-byte info for 1st track ; 2nd session (if any)
+ nnn-byte info for 2nd track (if any) ;
+ etc. ;/
+ etc. ;-further sessions (if any)
+ Session Block for no-more-sessions (15 bytes) ;-end marker
+ nnn-byte Disc Info Block ;-general disc info
+ Entrypoint (4 bytes) <--- located at "Filesize-4"
+Contains Sector Data for sector 00:00:00 and up (ie. all sectors are stored in
+the file, there are no missing "pregap" sectors).
+Sector Size can be 800h..990h bytes/sector (sector size may vary per track).
00h 1 Number of Sessions (usually 1)
+ 00h 1 Unknown (00h)
+ 01h 1 Number of Tracks in session (01h..63h) (or 00h=No More Sessions)
+ 02h 7 Unknown (00h-filled)
+ 09h 1 Unknown (01h)
+ 0Ah 3 Unknown (00h-filled)
+ 0Dh 2 Unknown (FFh,FFh)
+ 00h 12 Unknown (FFh,FFh,00h,00h,01h,00h,00h,00h,FFh,FFh,FFh,FFh)
+ 0Ch 3 Unknown (DAh,0Ah,D5h or 64h,05h,2Ah) (random/id/chksum?)
+ 0Fh 1 Total Number of Tracks on Disc (00h..63h) (non-BCD)
+ 10h 1 Length of below Path/Filename (F)
+ 11h (F) Full Path/Filename (eg. "C:\folder\file.cdi")
+ 11h+F 11 Unknown (00h-filled)
+ 1Ch+F 1 Unknown (02h)
+ 1Dh+F 10 Unknown (00h-filled)
+ 27h+F 1 Unknown (80h)
+ 28h+F 4 Unknown (00057E40h) (=360000 decimal) (disc capacity 80 minutes?)
+ 2Ch+F 2 Unknown (00h,00h)
+ 2Eh+F 2 Medium Type (0098h=CD-ROM, 0038h=DVD-ROM)
+ 00h 30h+F Track/Disc Header (see above)
+ 30h+F 02h Number of Indices (usually 0002h) (I=Num*4)
+ 32h+F (I) 32bit Lengths (per index) (eg. 00000096h,00007044h)
+ 32h+FI 04h Number of CD-Text blocks (usually 0) (T=Num*18+VariableLen's)
+ 36h+FI (T) CD-Text (if any) (see "mirage_parser_cdi_parse_cdtext")
+ 36h+FIT 02h Unknown (00h,00h)
+ 38h+FIT 01h Track Mode (0=Audio, 1=Mode1, 2=Mode2/Mixed)
+ 39h+FIT 07h Unknown (00h,00h,00h,00h,00h,00h,00h)
+ 40h+FIT 04h Session Number (starting at 0) (usually 00h)
+ 44h+FIT 04h Track Number (non-BCD, starting at 0) (00h..62h)
+ 48h+FIT 04h Track Start Address (eg. 00000000h)
+ 4Ch+FIT 04h Track Length (eg. 000070DAh)
+ 50h+FIT 0Ch Unknown (00h-filled)
+ 5Ch+FIT 04h Unknown (00000000h or 00000001h)
+ 60h+FIT 04h read_mode (0..4)
+ 0: Mode1, 800h, 2048
+ 1: Mode2, 920h, 2336
+ 2: Audio, 930h, 2352
+ 3: Raw+PQ, 940h, 2352+16 non-interleaved (P=only 1bit)
+ 4: Raw+PQRSTUVW, 990h, 2352+96 interleaved
+ 64h+FIT 4 Control (Upper 4bit of ADR/Control, eg. 00000004h=Data)
+ 68h+FIT 1 Unknown (00h)
+ 69h+FIT 4 Track Length (eg. 000070DAh) (same as above)
+ 6Dh+FIT 4 Unknown (00h,00h,00h,00h)
+ 71h+FIT 12 ISRC Code 12-letter/digit (ASCII?) string (00h-filled if none)
+ 7Dh+FIT 4 ISRC Valid Flag (0=None, Other?=Yes?)
+ 81h+FIT 1 Unknown (00h)
+ 82h+FIT 8 Unknown (FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh)
+ 8Ah+FIT 4 Unknown (00000001h)
+ 8Eh+FIT 4 Unknown (00000080h)
+ 92h+FIT 4 Unknown (00000002h) (guess: maybe audio num channels??)
+ 96h+FIT 4 Unknown (00000010h) (guess: maybe audio bits/sample??)
+ 9Ah+FIT 4 Unknown (0000AC44h) (44100 decimal, ie. audio sample rate?)
+ 9Eh+FIT 2Ah Unknown (00h-filled)
+ C8h+FIT 4 Unknown (FFh,FFh,FFh,FFh)
+ CCh+FIT 12 Unknown (00h-filled)
+ D8h+FIT 1 session_type ONLY if last track of a session (else 0)
+ (0=Audio/CD-DA, 1=Mode1/CD-ROM, 2=Mode2/CD-XA)
+ D9h+FIT 5 Unknown (00h-filled)
+ DEh+FIT 1 Not Last Track of Session Flag (0=Last Track, 1=Not Last)
+ DFh+FIT 1 Unknown (00h)
+ E0h+FIT 4 address for last track of a session? (otherwise 00,00,FF,FF)
+ 00h 30h+F Track/Disc Header (see above)
+ 30h+F 4 Disc Size (total number of sectors)
+ 34h+F 1 Volume ID Length (V) ;\from Primary Volume Descriptor[28h..47h]
+ 35h+F (V) Volume ID String ;/(ISO Data discs) (unknown for Audio)
+ 35h+FV 1 Unknown (00h)
+ 36h+FV 4 Unknown (01h,00h,00h,00h)
+ 3Ah+FV 4 Unknown (01h,00h,00h,00h)
+ 3Eh+FV 13 EAN-13 Code 13-digit (ASCII?) string (00h-filled if none)
+ 4Bh+FV 4 EAN-13 Valid Flag (0=None, Other?=Yes?)
+ 4Fh+FV 4 CD-Text Length in bytes (T=Num*1)
+ 53h+FV (T) CD-Text (for Lead-in) (probably 18-byte units?)
+ 53h+FVT 8 Unknown (00h-filled)
+ 5Bh+FVT 4 Unknown (06h,00h,00h,80h)
+ 00h 4 Footer Size in bytes
+CDRWIN stores disk images in two separate files. The .BIN file contains the raw
+disk image, starting at sector 00:02:00, with 930h bytes per sector, but
+without any TOC or subchannel information. The .CUE file contains additional
+information about the separate track(s) on the disk, in ASCII format, for
+example:
+
FILE "PATH\FILENAME.BIN" BINARY
+ TRACK 01 MODE2/2352
+ INDEX 01 00:00:00 ;real address = 00:02:00 (+2 seconds)
+ TRACK 02 AUDIO
+ PREGAP 00:02:00 ;two missing seconds (NOT stored in .BIN)
+ INDEX 01 08:09:29 ;real address = 08:13:29 (+2 seconds +pregap)
+ TRACK 03 AUDIO
+ INDEX 00 14:00:29 ;real address = 14:04:29 (+2 seconds +pregap)
+ INDEX 01 14:02:29 ;real address = 14:06:29 (+2 seconds +pregap)
+ TRACK 04 AUDIO
+ INDEX 00 18:30:20 ;real address = 18:34:20 (+2 seconds +pregap)
+ INDEX 01 18:32:20 ;real address = 18:36:20 (+2 seconds +pregap)
+ (must appear before any other commands, except CATALOG)
+ (uh, may also appear before further tracks)
+ AUDIO ;930h ;bytes 000h..92Fh
+ CDG ;? ;?
+ MODE1/2048 ;800h ;bytes 010h..80Fh
+ MODE1/2352 ;930h ;bytes 000h..92Fh
+ MODE2/2336 ;920h ;bytes 010h..92Fh
+ MODE2/2352 ;930h ;bytes 000h..92Fh
+ CDI/2336 ;920h ;?
+ CDI/2352 ;930h ;bytes 000h..92Fh
+Duration of silence at the begin (PREGAP) or end (POSTGAP) of a track. Even if
+it isn't specified, the first track will always have a 2-second pregap.
+The gaps are NOT stored in the BIN file.
Allows to insert comments/remarks (which are usually ignored). Some third-party
+tools are mis-using REM to define additional information.
(ISRC must be after TRACK, and before INDEX)
+These entries allow to define basic CD-Text info directly in the .CUE file.
+Some third-party utilites allow to define additional CD-Text info via REM
+lines, eg. "REM GENRE Rock".
+Alternately, more complex CD-Text data can be stored in a separate .CDT file.
Specifies an optional file which may contain CD-TEXT. The .CDT file consists of
+raw 18-byte CD-TEXT fragments (which may include any type of information,
+including exotic one's like a "Message" from the producer). For whatever
+reason, there's a 00h-byte appended at the end of the file. Alternately to the
+.CDT file, the less exotic types of CD-TEXT can be defined by PERFORMER, TITLE,
+and SONGWRITER commands in the .CUE file.
Unknown if newer CUE/BIN versions do also support subchannel data.
Some .CCD files are bundled with uncommon/corrupted .CUE files, with entries as
+so:
+
TRACK 1 MODE2/2352 ;three spaces indent, and 1-digit track
+ INDEX 1 00:00:00 ;three spaces indent, and 1-digit index
+ TRACK 01 MODE2/2352 ;two spaces indent, and 2-digit track
+ INDEX 01 00:00:00 ;four spaces indent, and 2-digit index
+Contains the sector data, recorded at 800h..930h bytes per sector, optionally
+followed by 60h bytes subchannel data (appended at the end of each sector). The
+stuff seems to be start on 00:02:00 (ie. the first 150 sectors are missing; at
+least it is like so when "Session Start Sector" is -150).
+The subchannel data (if present) consists of 8 subchannels, stored in 96 bytes
+(each byte containing one bit per subchannel).
+
Bit7..0 = Subchannel P..W (in that order, eg. Bit6=Subchannel Q)
+ 1st..8th bit = Bit7..Bit0 of 1st byte (in that order, ie. MSB/Bit7 first)
+ 9st..16th bit = Bit7..Bit0 of 2nd byte ("")
+ 17th.. = etc.
+An MDS file's structure consists of the following stuff ...
+
Header (58h bytes)
+ Session block(s) (usually one 18h byte entry)
+ Data blocks (N*50h bytes)
+ Index blocks (usually N*8 bytes)
+ Filename blocks(s) (usually one 10h byte entry)
+ Filename string(s) (usually one 6 byte string)
+ Read error(s) (usually none such)
+ 00h 16 File ID ("MEDIA DESCRIPTOR")
+ 10h 2 Unknown (01h,03h or 01h,04h or 01h,05h) (Fileformat version?)
+ 12h 2 Media Type (0=CD-ROM, 1=CD-R, 2=CD-RW, 10h=DVD-ROM, 12h=DCD-R)
+ 14h 2 Number of sessions (usually 1)
+ 16h 4 Unknown (02h,00h,00h,00h)
+ 1Ah 2 Zero (for DVD: Length of BCA data)
+ 1Ch 8 Zero
+ 24h 4 Zero (for DVD: Offset to BCA data)
+ 28h 18h Zero
+ 40h 4 Zero (for DVD: Offset to Disc Structures) (from begin of .MDS file)
+ 44h 0Ch Zero
+ 50h 4 Offset to First Session-Block (usually 58h) (from begin of .MDS file)
+ 54h 4 Offset to Read errors (usually 0=None) (from begin of .MDS file)
+ 00h 4 Session Start Sector (starting at FFFFFF6Ah=-150 in first session)
+ 04h 4 Session End Sector (XXX plus 150 ?)
+ 08h 2 Session number (starting at 1) (non-BCD)
+ 0Ah 1 Number of Data Blocks with any Point value (Total Data Blocks)
+ 0Bh 1 Number of Data Blocks with Point>=A0h (Special Lead-In info)
+ 0Ch 2 First Track Number in Session (01h..63h, non-BCD!)
+ 0Eh 2 Last Track Number in Session (01h..63h, non-BCD!)
+ 10h 4 Zero
+ 14h 4 Offset to First Data-Block (usually 70h) (from begin of .MDS file)
+Block 0..2 are usually containing Point A0h..A2h info. Block 3..N are usually
+TOC info for Track 1 and up.
+
00h 1 Track mode (see below for details)
+ 01h 1 Number of subchannels in .MDF file (0=None, 8=Sector has +60h bytes)
+ 02h 1 ADR/Control (but with upper/lower 4bit swapped, ie. MSBs=ADR!) Q0
+ 03h 1 TrackNo (usually/always 00h; as this info is in Lead-in area) Q1
+ 04h 1 Point (Non-BCD!) (Track 01h..63h) (or A0h and up=Lead-in info) Q2
+ 05h 4 Zero (probably dummy MSF and reserved byte from Q channel) Q3..Q6?
+ 09h 1 Minute (Non-BCD!) ;\MM:SS:FF of Point'ed track Q7
+ 0Ah 1 Second (Non-BCD!) ; (or disc/lead-out info when Point>=A0h) Q8
+ 0Bh 1 Frame (Non-BCD!) ;/ Q9
+ 0Ch 4 Offset to Index-block for this track (from begin of .MDS file)
+ 10h 2 Sector size (800h..930h) (or 860h..990h if with subchannels)
+ 12h 1 Unknown (02h) (maybe number of indices?)
+ 13h 11h Zero
+ 24h 4 Track start sector, PLBA (00000000h=00:02:00)(or 00000096h=00:02:00?)
+ 28h 8 Track start offset (from begin of .MDF file)
+ 30h 4 Number of Filenames for this track (usually 1)
+ 34h 4 Offset to Filename Block for this track (from begin of .MDS file)
+ 38h 18h Zero
+ (upper 4bit seem to be meaningless?)
+ 00h=None (used for entries with Point=A0h..FF)
+ A9h=AUDIO ;sector size = 2352 930h ;bytes 000h..92Fh
+ AAh=MODE1 ;sector size = 2048 800h ;bytes 010h..80Fh
+ ABh=MODE2 ;sector size = 2336 920h ;bytes 010h..92Fh
+ ACh=MODE2_FORM1 ;sector size = 2048 800h ;bytes 018h..817h (incomplete!)
+ ADh=MODE2_FORM2 ;sector size = 2324+0? 914h ;bytes 018h..91Bh (incomplete!)
+ ADh=MODE2_FORM2 ;sector size = 2324+4? 918h ;bytes ??..?? (contains what?)
+ ECh=MODE2 ;sector size = 2448 990h ;(930h+60h) (with subchannels)
+ 00h 4 Number of sectors with Index 0 (usually 96h or zero)
+ 04h 4 Number of sectors with Index 1 (usually size of main-track area)
+ 00h 4 Offset to Filename (from begin of .MDS file)
+ 04h 1 Filename format (0=8bit, 1=16bit characters)
+ 05h 11 Zero
+ 00h 6 Filename, terminated by zero (usually "*.mdf",00h)
+ 00h 4 Unknown (1)
+ 04h 4 Offset to following stuff
+ 08h 4 Unknown (2)
+ 0Ch 4 Unknown (7)
+ 10h 4 Unknown (1)
+ 14h 4 Number of read errors (E)
+ 18h E*4 LBA's for sectors with read errors (0 and up)
+Unknown if/how this format supports EAN-13, ISRC, CD-TEXT.
Nero is probably the most bloated and most popular CD recording software. The
+first part of the file contains the disk image, starting at sector 00:00:00,
+with 800h..930h bytes per sector. Additional chunk-based information is
+appended at the end of the file, usually consisting of only four chunks:
+CUES,DAOI,END!,NERO (in that order).
4 File ID "NERO"/"NER5"
+ 4/8 Fileoffset of first chunk
+ 4 Chunk ID "CUES"/"CUEX"
+ 4 Chunk size (bytes)
+ 1 ADR/Control from TOC (usually LSBs=ADR=1=fixed, MSBs=Control=Variable)
+ 1 Track (BCD) (00h=Lead-in, 01h..99h=Track N, AAh=Lead-out)
+ 1 Index (BCD) (usually 00h=pregap, 01h=actual track)
+ 1 Zero
+ 1 Zero
+ 1 Minute (BCD) ;starting at 00:00:00 = 2 seconds before ISO vol. descr.
+ 1 Second (BCD)
+ 1 Sector (BCD)
+ 4 Logical Sector Number (HEX) ;starting at FFFFFF6Ah (=00:00:00)
+ 4 Chunk ID "DAOI"/"DAOX"
+ 4 Chunk size (bytes)
+ 4 Garbage (usually same as above Chunk size)
+ 13 EAN-13 Catalog Number (13-digit ASCII) (or 00h-filled if none/unknown)
+ 1 Zero
+ 1 Disk type (00h=Mode1 or Audio, 20h=XA/Mode2) (and probably 10h=CD-I?)
+ 1 Unknown (01h)
+ 1 First track (Non-BCD) (01h..63h)
+ 1 Last track (Non-BCD) (01h..63h)
+ 12 ISRC in ASCII (eg. "USXYZ9912345") (or 00h-filled if none/unknown)
+ 2 Sector size (usually 800h, 920h, or 930h) (see Mode entry for more info)
+ 1 Mode:
+ 0=Mode1/800h ;raw mode1 data (excluding sync+header+edc+errorinfo)
+ 3=Mode2/920h ;almost full sector (exluding first 16 bytes; sync+header)
+ 6=Mode2/930h ;full sector (including first 16 bytes; sync+header)
+ 7=Audio/930h ;full sector (plain audio data)
+ Mode values from wikipedia:
+ 00h for data Mode1/800h
+ 02h
+ 03h for Mode 2 Form 1 data eh? FORM1??? Mode2/920h
+ 05h for raw data Mode1?/930h
+ 06h for raw Mode 2/form 1 data Mode2/930h
+ 07h for audio Audio/930h
+ 0Fh for raw data with sub-channel Mode1?/930h+WHAT?
+ 10h for audio with sub-channel Audio/930h+WHAT?
+ 11h for raw Mode 2/form 1 data with sub-channel Mode2/WHAT?+WHAT?
+ Note: Some newer files do actually use different sector sizes for each
+ track (eg. 920h for the data track, and 930h for any following audio
+ tracks), older files were using the same sector size for all tracks
+ (eg. if the disk contained 930-byte Audio tracks, then Data tracks
+ were stored at the same size, rather than at 800h or 920h bytes).
+ 3 Unknown (always 00h,00h,01h)
+ 4/8 Fileoffset 1 (Start of Track's Pregap) (with Index=00h)
+ 4/8 Fileoffset 2 (Start of actual Track) (with Index=01h and up)
+ 4/8 Fileoffset 3 (End of Track) (aka begin of next track's pregap)
+ 4 Chunk ID "END!"
+ 4 Chunk size (always zero)
+ 4 Chunk ID "TINF"/"ETNF"/"ETN2"
+ 4 Chunk size (bytes)
+ 4/4/8 Track fileoffset ;\32bit in TINF/ETNF chunks,
+ 4/4/8 Track length (bytes) ;/64bit in ETN2 chunks
+ 4 Mode (should be same as in DAO chunks, see there) (implies sector size)
+ 0/4/4 Start lba on disc ;\only in ETNF/ETN2 chunks,
+ 0/4/4 Unknown? ;/not in TINF chunks
+ 4 Chunk ID "RELO"
+ 4 Chunk size (bytes)
+ 4 Zero
+ 4 Chunk ID "TOCT"
+ 4 Chunk size (bytes)
+ 1 Disk type (00h=Mode1 or Audio, 20h=XA/Mode2) (and probably 10h=CD-I?)
+ 1 Zero (00h)
+ 4 Chunk ID "SINF"
+ 4 Chunk size (bytes)
+ 4 Number of tracks in session
+ 4 Chunk ID None/"CDTX"
+ 4 Chunk size (bytes) (must be a multiple of 18 bytes)
+ 18 Raw 18-byte CD-text data fragments
+ 4 Chunk ID "MTYP"
+ 4 Chunk size (bytes)
+ 4 Unknown? (00000001h for CDROM) (maybe other value for DVD)
+ 4 Chunk ID "AFNM"
+ 4 Chunk size (bytes)
+ .. Track Filenames (eg. "Track1.wav",0,"Track2.wav",0)
+ 4 Chunk ID "VOLM"
+ 4 Chunk size (bytes)
+ .. Name (eg. "Audio CD",00h)
+Newer/older .NRG files may contain 32bit/64bit values (and use "OLD"/"NEW"
+chunk names) (as indicated by the "/" slashes).
+CAUTION: All 16bit/32bit/64bit values are in big endian byte-order.
Unknown if newer NRG versions do also support subchannel data.
.CDZ is a compressed disk image container format (developed by pSX Author, and
+used only by the pSX emulator). The disk is split into 64kbyte blocks, which
+allows fast random access (without needing to decompress all preceeding
+sectors).
+However, the compression ratio is surprisingly bad (despite of being
+specifically designed for cdrom compression, the format doesn't remove
+redundant sector headers, error correction information, and EDC checksums).
FileID ("CDZ",00h for cdztool v0/v1, or "CDZ",01h for cdztool v2 and up)
+ One or two Chunk(s)
+Chunk Header in v0 (unreleased prototype):
+
4 32bit Decompressed Size (of all blocks) (must be other than "ZLIB")
+ 4 ZLIB ID ("ZLIB")
+ 8 64bit Decompressed Size (of all blocks)
+ 4 Chunk ID (eg. "CUE",00h)
+ 8 Chunk Size in bytes (starting at "ZLIB" up to including Footer, if any)
+ 4 ZLIB ID ("ZLIB")
+ 8 64bit Decompressed Size (of all blocks)
+ 4 Number of Blocks (N)
+ 4 Block 1 Compressed Size (CS.1)
+ 4 Block 1 Decompressed Size (always 00010000h, except last block)
+ CS.1 Block 1 Compressed ZLIB Data (starting with 78h,9Ch)
+ ... ... ;\
+ 4 Block N Compressed Size (CS.N) ; further block(s)
+ 4 Block N Decompressed Size ; (if any)
+ CS.N Block N Compressed ZLIB Data ;/
+ 4*N Directory Entries for N blocks ;-this ONLY for BIN chunk
+ BPD*(N-1) Directory Entries for N-1 blocks ;\this ONLY for BIN chunk
+ 1 Bytes per Directory Entry (BPD) ;/(not for CUE/CCD/MDS)
+The chunk(s) have following content:
+
noname+noname --> .CUE+.BIN (cdztool v1 and below)
+ "BIN",0 --> .ISO (cdztool v2? and up)
+ "CUE",0+"BIN",0 --> .CUE+.BIN (cdztool v2 and up)
+ "CCD",0+"BIN",0 --> .CCD+.IMG (cdztool v2 and up)
+ "CCD",0+"BIN",01h --> .CCD+.IMG+.SUB (930h sectors, plus 60h subchannels)
+ "MDS",0+"BIN",0 --> .MDS+.MDF (cdztool v5 only)
+ cdztool.exe v0, unrelased prototype
+ cdztool.exe v1, 22 May 2005, CRC32=620dbb08, 102400 bytes, pSX v1.0-5
+ cdztool.exe v2, 02 Jul 2006, CRC32=bcb29c1e, 110592 bytes, pSX v1.6
+ cdztool.exe v3, 22 Jul 2006, CRC32=4062ba82, 110592 bytes, pSX v1.7
+ cdztool.exe v4, 13 Aug 2006, CRC32=7388dd3d, 118784 bytes, pSX v1.8-11
+ cdztool.exe v5, 22 Jul 2007, CRC32=f25c1659, 155648 bytes, pSX v1.12-13
+ECM (Error Code Modeler by Neill Corlett) is a utility that removes
+unneccessary ECC error correction and EDC error detection values from
+CDROM-images. This is making the images a bit smaller, but the real size
+reduction isn't gained until subsequently compressing the images via tools like
+ZIP. Accordingly, these files are extremly uncomfortable to use: One most first
+UNZIP them, and then UNECM them.
ECM can be applied to various CDROM-image formats (like .BIN, .CDI, .IMG, .ISO,
+.MDF, .NRG), as indicated by the double-extension. Most commonly it's applied
+to .BIN files (hence using extension .BIN.ECM).
45 43 4D 00 ;FileID "ECM",00h
+ 3C ;Type 0, Len=10h (aka 0Fh+1)
+ 00 FF FF FF FF FF FF FF FF FF FF 00 00 02 00 02 ;16 data bytes
+ 02 ;Type 2, Len=1 (aka 00h+1)
+ 00 00 08 00 00 00 00 00 00 00 00 ..... 00 00 00 ;804h data bytes
+ 3C ;Type 0, Len=10h (aka 0Fh+1)
+ 00 FF FF FF FF FF FF FF FF FF FF 00 00 02 01 02 ;16 data bytes
+ 02 ;Type 2, Len=1 (aka 00h+1)
+ 00 00 08 00 00 00 00 00 00 00 00 ..... 00 00 00 ;804h data bytes
+ ...
+ FC FF FF FF 3F ;End Code (Len=FFFFFFFFh+1)
+ NN NN NN NN ;EDC (on decompressed data)
+Type/Length is encoded in 1..5 byte(s), with "More=1" indicating that further
+length byte(s) follow:
+
1st Byte: Bit7=More, Bit6-2=LengthBit4-0, Bit1-0=Type(0..3)
+ 2nd Byte: Bit7=More, Bit6-0=LengthBit5-11
+ 3rd Byte: Bit7=More, Bit6-0=LengthBit12-18
+ 4th Byte: Bit7=More, Bit6-0=LengthBit19-25
+ 5th Byte: Bit7-6=Reserved/Zero, Bit5-0=LengthBit26-31
+Below is repeated LEN times (with LEN being the Length value plus 1):
+
Type 0: load 1 byte, save 1 byte
+ Type 1: load 803h bytes [0Ch..0Eh,10h..80Fh], save 930h bytes [0..92Fh]
+ Type 2: load 804h bytes [14h..817h], save 920h bytes [10h..92Fh]
+ Type 3: load 918h bytes [14h..91Bh], save 920h bytes [10h..92Fh]
+There's a lot of wrong with the ECM format. The two central problems are that
+it doesn't support data-compression (and needs external compression tools like
+zip/rar), and, that it doesn't contain a sector look-up table (meaning that
+random access isn't possible unless when scanning the whole file until reaching
+the desired sector).
As if ECM as such wouldn't be uncomfortable enough, you may expect typical ECM
+users to get more things messed up. For example:
+
A RAR file containing a 7Z file containing a ECM file containing a BIN file.
+ The BIN containing only Track 1, other tracks stored in APE files.
+ And, of course, the whole mess without including the required CUE file.
+SBI Files start with a 4-byte FileID:
+
4 bytes FileID ("SBI",00h)
+ 3 bytes real absolute MM:SS:FF address where the sub q data was bad
+ 1 byte Format: the format can be 1, 2 or 3:
+ Format 1: complete 10 bytes sub q data (Q0..Q9)
+ Format 2: 3 bytes wrong relative MM:SS:FF address (Q3..Q5)
+ Format 3: 3 bytes wrong absolute MM:SS:FF address (Q7..Q9)
+M3S files are containing Subchannel Q data for all sectors on Minute=03 (the
+region where PSX libcrypt data is located) (there is no support for storing the
+(unused) libcrypt backup copy on Minute=09). The .M3S filesize is 72000 bytes
+(60 seconds * 75 sectors * 16 bytes). The 16 bytes per sector are:
+
Q0..Q9 Subchannel Q data (normally position data)
+ Q10..Q11 Subchannel Q checksum
+ Q12..Q15 Dummy/garbage/padding (usually 00000000h or FFFFFFFFh)
+ 1. With CRC (Q0..Q11 intact) (and Q12..Q15 randomly 00000000h or FFFFFFFFh)
+ 2. Without CRC (only Q0..Q9 intact, but Q10..Q15 zerofilled)
+ 3. Without anything (only Q0 intact, but Q1..Q15 zerofilled)
+Most CDROM-Image formats can (optionally) contain subchannel recordings. The
+downsides are: Storing all 8 subchannels for a full CDROM takes up about
+20MBytes. And, some entries may contain 'wrong' data (read errors caused by
+scratches cannot be automatically repaired since subchannels do not contain
+error correction info).
+If present, the subchannel data is usually appended at the end of each sector
+in the main binary file (one exception is CloneCD, which stores it in a
+separate .SUB file instead of in the .IMG file).
+
CCD/IMG/SUB (CloneCD) P-W 60h-bytes Non-interleaved (in separate .SUB file)
+ CDI (DiscJuggler) P-Q 10h-bytes Non-interleaved (in .CDI file)
+ "" P-W 60h-bytes Interleaved (in .CDI file)
+ CUE/BIN/CDT (Cdrwin) N/A
+ ISO (single-track) N/A
+ MDS/MDF (Alcohol 120%) P-W 60h-bytes Interleaved (in .MDF file)
+ NRG (Nero) P-W 60h-bytes Interleaved (in .NRG file)
+ 00h-07h 80 C0 80 80 80 80 80 C0 ;P=FFh, Q=41h=ADR/Control, R..W=00h
+ 08h-0Fh 80 80 80 80 80 80 80 C0 ;P=FFh, Q=01h=Track, R..W=00h
+ 10h-17h 80 80 80 80 80 80 80 C0 ;P=FFh, Q=01h=Index, R..W=00h
+ 18h-1Fh 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=RelMinute, R..W=00h
+ 20h-27h 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=RelSecond, R..W=00h
+ 28h-2Fh 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=RelSector, R..W=00h
+ 30h-37h 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=Reserved, R..W=00h
+ 38h-3Fh 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=AbsMinute, R..W=00h
+ 40h-47h 80 80 80 80 80 80 C0 80 ;P=FFh, Q=02h=AbsSecond, R..W=00h
+ 48h-4Fh 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=AbsSector, R..W=00h
+ 50h-57h 80 80 C0 80 C0 80 80 80 ;P=FFh, Q=28h=ChecksumMsb, R..W=00h
+ 58h-5Fh 80 80 C0 C0 80 80 C0 80 ;P=FFh, Q=32h=ChecksumLsb, R..W=00h
+ 00h-0Bh FF FF FF FF FF FF FF FF FF FF FF FF ;Subchannel P (Pause)
+ 0Ch-17h 41 01 01 00 00 00 00 00 02 00 28 32 ;Subchannel Q (Position)
+ 18h-23h 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel R
+ 24h-2Fh 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel S
+ 30h-3Bh 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel T
+ 3Ch-47h 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel U
+ 48h-53h 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel V
+ 54h-5Fh 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel W
+ This is probably based on MMC protocol, which would be as crude as this:
+ The 96 pause bits are summarized in 1 bit. Pause/Checksum are optional.
+ 00h-09h 41 01 01 00 00 00 00 00 02 00 ;Subchannel Q (Position)
+ 0Ah-0Bh 28 32 ;<-- OPTIONAL, can be zero! ;Subchannel Q (Checksum)
+ 0Ch-0Eh 00 00 00 ;Unused padding (zero)
+ 0F 80 ;<-- OPTIONAL, can be zero! ;Subchannel P (Bit7=Pause)
+Sony's disc image format used on PSP. Can store multi-disc images in a single
+file. Supports deflate data compression and some yet unknown audio compression.
+A homebrew compressor can compress whole discs with deflate (which works, but
+it isn't very good to compress audio sectors that way).
000000h 4 ID (00h,"PBP")
+ 000004h 4 Version? (10000h) (but, reportedly "always 100h or 1000100h")
+ 000008h 4 Offset of the file PARAM.SFO (28h)
+ 00000Ch 4 Offset of the file ICON0.PNG (3D8h)
+ 000010h 4 Offset of the file ICON1.PMF (3D8h) or ICON1.PNG
+ 000014h 4 Offset of the file PIC0.PNG (3D8h) or UNKNOWN.PNG
+ 000018h 4 Offset of the file PIC1.PNG (3D8h) or PICT1.PNG
+ 00001Ch 4 Offset of the file SND0.AT3 (3D8h)
+ 000020h 4 Offset of the file DATA.PSP (3D8h)
+ 000024h 4 Offset of the file DATA.PSAR (10000h)
+ 000028h .. PARAM.SFO file (zerofilled in homebrew PBP)
+ 0003D8h .. PNG files etc (zerofilled in homebrew PBP)
+ 010000h 0Ch ID "PSISOIMG0000"
+ 01000Ch 4 PBP Size-10000h (144740h)
+ 010010h 4 PBP Size-6420h (???) (14E320h)
+ 010014h .. Zerofilled
+ 010400h 0Bh Game ID ("_SCUS_94476" for Hot Shots Golf 2)
+ 01040Bh .. Zerofilled
+ 010800h A00h TOC List (0Ah-byte per entry) (unused entries are zerofilled)
+ 011200h 20h Zerofilled
+ 011220h 4 PBP Size-D2CFh (???) (147471h)
+ 011224h 4 Zero
+ 011228h 4 Unknown (7FFh)
+ 01122Ch 11h Game Name ("Hot Shots Golf",C2h,AEh,"2")
+ 01123Dh .. Zerofilled
+ 014000h .. Sector List (20h-byte per entry) (unused entries are zerofilled)
+ ... .. Zerofilled
+ 110000h .. Deflated sectors (9300h bytes after decompression)
+ 15467Dh B8h One extra compression block that is NOT in Sector List ???
+ 154735h 0Bh Weird padding with ASCII "00000000000"
+ 154740h - End of file
+ TOC List (Subchannel Q with ADR=1 during Lead-In):
+ 000h 1 ADR/Control (eg. 41h=Data Track)
+ 001h 1 Track (always 00h=Lead-in for all TOC List entries)
+ 002h 1 Point (A0h, A1h, A2h, or Track 01h and up) (BCD?)
+ 003h 3 Dummy MSF (usually 00:00:00 or weirdly 00:02:01) (BCD?)
+ 006h 1 Reserved (00h)
+ 007h 3 Actual MSF (or TOC info for Point=A0h,A1h) (BCD?)
+ Example TOC (DBALL.PBP):
+ 41 00 A0 00 00 00 00 01 20 00 ;First Track (1) and Type (20h=CDROM-XA)
+ 41 00 A1 00 00 00 00 01 00 00 ;Last Track Number (1)
+ 41 00 A2 00 00 00 00 27 19 22 ;Lead-Out, uh at 27:19:22 in DBALL.PBP ???
+ 41 00 01 00 02 01 00 00 02 00 ;Track 1 at 00:02:00
+ (remaining entries are zerofilled)
+ Example TOC (PSALM69.PBP):
+ 01 00 01 00 02 00 00 00 00 00 ;Track 1 as audio <-- why that ???
+ 01 00 02 02 37 44 00 00 00 00 ;Track 2 as audio
+ 01 00 03 03 25 45 00 00 00 00 ;Track 3 as audio
+ 41 00 01 00 02 01 00 00 02 00 ;Track 1 as data <-- listed last?
+ (remaining entries are zerofilled)
+ (weirdly, most MM:SS:FF values are stored in byte[3..5] instead [7..9])
+ (there are no point=A0h,A1h,A2h entries)
+ Example TOC (GOOGLE_AI_TTS.PBP):
+ 01 00 01 00 02 00 00 00 00 00 ;Track 1 as audio
+ 01 00 02 00 02 30 00 00 00 00 ;Track 2 as audio, but without pregap?
+ 01 00 03 00 02 60 00 00 00 00 ;Track 3 as audio, but without pregap?
+ 01 00 04 00 03 15 00 00 00 00 ;Track 4 as audio, but without pregap?
+ (remaining entries are zerofilled)
+ Sector List:
+ 000h 4 Offset-110000h to Sector(N*10h)
+ 004h 2 Compressed size of Sector(N*10h+(0..0Fh)) ;9300h=uncompressed?
+ 006h 2 Zero (but, reportedly "usually 1... and 0 for the last entry")
+ 008h 10h Zero (but, reportedly "first 10h bytes of SHA1 sum of 10h sectors")
+ 018h 8 Zero (padding)
+ ?
+ ?
+ ?
+All numbers are stored in Motorola (big-endian) byte ordering.
V1/V2 contains harddisk related header entries (and apparently does't support
+cdroms).
+
000h 08h ID "MComprHD" (MAME Compressed Hunks of Data)
+ 008h 4 Header size (4Ch=V1, 50h=V2)
+ 00Ch 4 Header version (probably 01h=V1, 02h=V2)
+ 010h 4 Flags (bit0=DriveHasParent, bit1=AllowWrites)
+ 014h 4 Compression type (0=None, 1=ZLIB)
+ 018h 4 Number of sectors per hunk
+ 01Ch 4 Total number of hunks represented
+ 020h 4 Number of cylinders on hard disk
+ 024h 4 Number of heads on hard disk
+ 028h 4 Number of sectors on hard disk
+ 02Ch 10h MD5 checksum on raw data
+ 03Ch 10h MD5 checksum on parent file
+ N/A - V1: Uses fixed 200h-byte Sector size
+ 04Ch (4) V2: Number of bytes per sector
+ ... ? Supposedly followed by map and/or data at whatever locations
+V3/V4 are inventing new "metadata" for info about harddisks or cdroms.
+
000h 08h ID "MComprHD" (MAME Compressed Hunks of Data)
+ 008h 4 Header size (78h=V3, 6Ch=V4)
+ 00Ch 4 Header version (03h=V3, 04h=V4)
+ 010h 4 Flags (bit0=DriveHasParent, bit1=AllowWrites)
+ 014h 4 Compression type (0=None, 1=ZLIB, 2=ZLIB_PLUS) (V4: 3=AV)
+ 018h 4 Total number of hunks represented (N) (92h)
+ 01Ch 08h Total size of all uncompressed hunks (N*2640h) (15D080h)
+ 024h 08h Offset to the first blob of metadata
+ 02Ch 10h V3: MD5 checksum on raw data ;\
+ 03Ch 10h V3: MD5 checksum on parent file ;
+ 04Ch 4 V3: Number of bytes per hunk (2640h=990h*4) ; V3
+ 050h 14h V3: SHA1 checksum on raw data ;
+ 064h 14h V3: SHA1 checksum on parent file ;/
+ 02Ch 4 V4: Number of bytes per hunk (2640h=990h*4) ;\
+ 030h 14h V4: SHA1 checksum on raw+meta ; V4
+ 044h 14h V4: SHA1 checksum on raw+meta of parent ;
+ 058h 14h V4: SHA1 checksum on raw data ;/
+ ... N*10h Map entries (for each hunk)
+ ... 10h Map end marker ("EndOfListCookie",00h)
+ ... .. Metadata Chunk(s)
+ ... .. Compressed Sectors (aka hunks)
+ 000h 8 ID "MComprHD" (MAME Compressed Hunks of Data)
+ 008h 4 Header size (7Ch=V5)
+ 00Ch 4 Header version (05h=V5)
+ 010h 4 Compressor 0 (usually "cdlz"=cdrom/lzma)
+ 014h 4 Compressor 1 (usually "cdzl"=cdrom/zlib)
+ 018h 4 Compressor 2 (usually "cdfl"=cdrom/flac)
+ 01Ch 4 Compressor 3 (usually 0=none)
+ 020h 8 Total size of all uncompressed hunks (N*4C80h-HunkPadding)
+ 028h 8 Offset to Map (3D797h)
+ 030h 8 Offset to first Metadata chunk (7Ch)
+ 038h 4 Number of bytes per hunk (512k maximum) (990h*8) (4C80h)
+ 03Ch 4 Number of bytes per sector (990h) (30h+60h)
+ 040h 14h SHA1 on raw data
+ 054h 14h SHA1 on raw+meta
+ 068h 14h SHA1 on raw+meta of parent (0=No parent)
+ ... .. Metadata Chunk(s)
+ ... .. Padding to BytesPerHunk-boundary ;\when uncompressed
+ ... .. Uncompressed Sectors (aka hunks) ;/
+ ... .. Compressed Sectors (aka hunks) ;-when compressed
+ ... .. Map
+Overall Metadata chunk format:
+
000h 4 Chunk ID (aka Blob Tag) (eg. "CHT2" for each CDROM track)
+ 004h 1 Flags (00h=V3, 01h=V4/V5) ;maybe some kind of flag/type/version?
+ 005h 3 Chunk Data Size (24bit)
+ 008h 8 Offset to next Chunk (or 0=Last chunk)
+ 010h .. Chunk Data (eg. "TRACK:1 TYPE:MODE2_RAW ... POSTGAP:0",00h for CHT2)
+ Summary of Chunk IDs and corresponding Data entries:
+ ID_______Data_______________________________________________________
+ "GDDD" "CYLS,HEADS,SECS,BPS" ;-hard disk standard info ;\
+ "IDNT" ? ;-hard disk identify info ; HDD
+ "KEY " ? ;-hard disk key info ;/
+ "CIS " ? ;-pcmcia CIS info ;-PCMCIA
+ "CHCD" 94Ch-byte binary (4+99*24 bytes) ;\
+ "CHTR" "TRACK TYPE SUBTYPE FRAMES" ; CD-ROM
+ "CHT2" "TRACK TYPE SUBTYPE FRAMES PREGAP PGTYPE PGSUB POSTGAP" ;/
+ "CHGT" ? ;\Sega
+ "CHGD" "TRACK TYPE SUBTYPE FRAMES PAD PREGAP PGTYPE PGSUB POSTGAP" ;/GD-ROM
+ "AVAV" "FPS WIDTH HEIGHT INTERLACED CHANNELS SAMPLERATE" ;\AV
+ "AVLD" ? (A/V Laserdisc frame) ;/
+The ASCII items are separated by spaces as shown above (or commas for GDDD).
+The last item in each chunk is terminated by 00h (at least so for CHTR/CHT2).
+Most items are followed by a colon and decimal string (eg. TRACK:1), except,
+TYPE,PGTYPE,SUBTYPE,PGSUB are followed by text strings (eg. TYPE:MODE2_RAW).
+
CYLS:# Hard disc number of cylinders
+ HEADS:# Hard disc number of heads
+ SECS:# Hard disc number of sectors
+ BPS:# Hard disc bytes per sector
+ TRACK:# CDROM current track number (1..99)
+ TYPE:string CDROM sector type/size
+ SUBTYPE:string CDROM subchannel info (usually "NONE")
+ FRAMES:# CDROM number of sectors per track (with/without pregap?)
+ PAD:# Sega GDROM only: whatever pad value?
+ PREGAP:# CDROM ... maybe number of pregap sectors? (can be HUGE !!??)
+ PGTYPE:string CDROM ... whatever type? (usually "MODE1"??)
+ PGSUB:string CDROM ... whatever subchannel (usually "RW"??)
+ POSTGAP:# CDROM ... maybe number of pstgap sectors? (usually 0)
+ FPS:#.###### AV Video(?)-frames per second? with 6-digit fraction? (.avi?)
+ WIDTH:# AV Width (maybe in pixels?)
+ HEIGHT:# AV Height (maybe in pixels?) (with/without interlace?)
+ INTERLACED:# AV Interlace (maybe a flag that might be maybe 0 or 1?)
+ CHANNELS:# AV Channels (maybe audio mono/stereo or so?)
+ SAMPLERATE:# AV Samplerate (maybe audio samplerate, maybe in Hertz?)
+ For SUBTYPE and PGSUB:
+ "RW" 60h-byte interleaved ;normal "cooked" 96 bytes per sector
+ "RW_RAW" 60h-byte uninterleaved ;raw uninterleaved 96 bytes per sector
+ "NONE" 0-byte ;no subcode data stored (default)
+ (unknown how RAW and RW_RAW differ, one format does probably store 8 bits
+ for 8 subchannels per byte... but unknown which format is doing so?)
+ For TYPE and PGTYPE (and CHCD numeric type 0..7):
+ "MODE1/2048" or "MODE1" CHCD=0 800h-byte ;\Data Mode1
+ "MODE1/2352" or "MODE1_RAW" CHCD=1 930h-byte ;/
+ "MODE2/2336" or "MODE2" ;\dupe? CHCD=2 920h-byte ;\
+ "MODE2/2336" or "MODE2_FORM_MIX" ;/ CHCD=5 920h-byte ;
+ "MODE2/2048" or "MODE2_FORM1" CHCD=3 800h-byte ; Data Mode2
+ "MODE2/2324" or "MODE2_FORM2" CHCD=4 914h-byte ;
+ "MODE2/2352" or "MODE2_RAW" or "CDI/2352" CHCD=6 930h-byte ;/
+ "AUDIO" (stored as big-endian samples!!!) CHCD=7 930h-byte ;-Audio CD-DA
+ 000h 4 Number of tracks (N) (1..99)
+ 004h N*18h Track entries
+ ... .. Zeropadding to 94Ch-byte size (when less than 99 tracks)
+ Track entries:
+ 000h 4 Track Type (0..7, CHCD=# in above table) (eg. 6=MODE2_RAW)
+ 004h 4 Subchannel Type (0=RW, 1=RW_RAW, 2=None)
+ 008h 4 Sector Size (800h, 914h, 920h or 930h)
+ 00Ch 4 Subchannel Size (0 or 60h)
+ 010h 4 Number of Frames (aka number of sectors)
+ 014h 4 Padding Frames (0..3) (to make Total Frames a multiple of 4)
+The Maps contain info (offset, size, compression method, etc.) for the separate
+compression blocks.
44bit Offset to compressed data
+ 20bit Size of compressed data (or uncompressed data when size=hunksize)
+ 000h 8 Offset to compressed data (64bit big-endian)
+ 008h 4 CRC32 on uncompressed data (32bit big-endian)
+ 00Ch 3 Size of compressed data (24bit mixed-endian: Mid, Low, High)
+ 00Fh 1 Flags, indicating compression info (=whut? maybe below V34 stuff?)
+ V34_MAP_ENTRY_TYPE_INVALID = 0 invalid type
+ V34_MAP_ENTRY_TYPE_COMPRESSED = 1 standard compression
+ V34_MAP_ENTRY_TYPE_UNCOMPRESSED = 2 uncompressed data
+ V34_MAP_ENTRY_TYPE_MINI = 3 mini: use offset as raw data
+ V34_MAP_ENTRY_TYPE_SELF_HUNK = 4 same as another hunk in this file
+ V34_MAP_ENTRY_TYPE_PARENT_HUNK = 5 same as a hunk in the parent file
+ V34_MAP_ENTRY_TYPE_2ND_COMPRESSED = 6 compressed with secondary algorithm
+ V5 uncompressed map format (when [filehdr+10h]=00000000h):
+ 000h N*4 Hunk List (32bit offsets: Offset/BytesPerHunk) (usually 1,2,3..)
+ V5 compressed map format (when [filehdr+10h]<>00000000h):
+ 000h 4 Length of compressed map
+ 004h 6 Offset of first block (48bit) (E4h, after meta)
+ 00Ah 2 CRC16 on decompressed map entries
+ 00Ch 1 bits used to encode complength
+ 00Dh 1 bits used to encode self-refs
+ 00Eh 1 bits used to encode parent unit refs
+ 00Fh 1 Reserved for future use (probably zero)
+ 010h .. Compressed Map entries (bitstream with Huffman/RLE encoding)
+ The decompressed map entries should look as shown below (one could store them
+ differently, eg. as 32bit little endian values; however, they must be stored
+ exactly as shown below when computing the CRC16 on decompressed map entries):
+ 000h 1 Compression type (0..3=Codec0..3, 4=Uncompressed, 5=Self, 6=Parent)
+ 001h 3 Compressed length (24bit big-endian)
+ 004h 6 Offset to compressed data (48bit big-endian)
+ 00Ah 2 CRC16 on decompressed data (big-endian)
+ V5 compression codecs:
+ 0,0,0,0 = CHD_CODEC_NONE ;-unused (when using less than 4 codecs)
+ "zlib" = CHD_CODEC_ZLIB ;\
+ "lzma" = CHD_CODEC_LZMA ; general codecs
+ "huff" = CHD_CODEC_HUFFMAN ;
+ "flac" = CHD_CODEC_FLAC ;/
+ "cdzl" = CHD_CODEC_CD_ZLIB ;\
+ "cdlz" = CHD_CODEC_CD_LZMA ; general codecs with CD frontend
+ "cdfl" = CHD_CODEC_CD_FLAC ;/
+ "avhu" = CHD_CODEC_AVHUFF ;-A/V codecs
+ readfile(src,NumberOfHunks*4) ;\
+ i=0 ; load uncomoressed
+ while i<NumberOfHunks ; map (needed only
+ ofs=bigendian32bit[src+i*4]*BytesPerHunk ; for uncompressed
+ byte[map+i*0Ch+00h]=04h ;typ=Uncompressed ; files, which can
+ bigendian24bit[map+i*0Ch+01h]=BytesPerHunk ; be created via
+ bigendian48bit[map+i*0Ch+04h]=ofs ; chdman commandline
+ bigendian16bit[map+i*0Ch+0Ah]=none ;no crc ; options)
+ ofs=ofs+len, i=i+1 ;/
+ readfile(hdr,10h) ;\read map hdr and
+ readfile(src,bigendian32bit[hdr+0]) ; compressed map
+ InitBitstream(src,BigEndianMsbFirst) ;/
+ i=0 ;\
+ while i<10h ;
+ val=GetBits(4), num=1 ;
+ if val=01h then ; read huffman tree
+ val=GetBits(4) ;
+ if val<>01h then num=GetBits(4)+3 ;
+ for j=1 to num, codesizes[i]=val, i=i+1 ;
+ nonlzh_explode_tree(codetree,codesizes,10h) ;/
+ i=0, typ=0, num=0 ;\
+ while i<NumberOfHunks ;
+ if num=0 ; load huffman coded
+ x=GetHuffCode(codetree) ; map type values
+ if x=07h then ;COMPRESSION_RLE_SMALL ;
+ num=GetHuffCode(codetree)+03h ;
+ elseif x=08h then ;COMPRESSION_RLE_LARGE ;
+ num=GetHuffCode(codetree)*10h ;
+ num=GetHuffCode(codetree)+num+13h ;
+ else typ=x, num=1 ;
+ byte[map+i*0Ch+0]=typ, i=i+1, num=num-1 ;/
+ i=0, s=0, p=0 ;index,self,parent ;\
+ o=bigendian48bit[hdr+4] ;offset ; load other
+ while i<NumberOfHunks ; map items
+ typ=byte[map+i*0Ch+00h], ofs=o, len=0, crc=0 ;
+ if typ<04h then len=GetBits([hdr+0Ch]), crc=GetBits(16); ;Method 0..3
+ elseif typ=04h then len=BytesPerHunk, crc=GetBits(16) ; ;Uncompressed
+ elseif typ=05h then s=GetBits([hdr+0Dh]), ofs=s ; ;New Self
+ elseif typ=06h then p=GetBits([hdr+0Eh]), ofs=p ; ;New Parent
+ elseif typ=09h then typ=05h, ofs=s ; ;Old Self
+ elseif typ=0Ah then typ=05h, s=s+1, ofs=s ; ;Old Self+1
+ elseif typ=0Bh then typ=06h, p=i*SectorsPerHunk, ofs=p ; ;Direct Parent
+ elseif typ=0Ch then typ=06h, ofs=p ; ;Old Parent
+ elseif typ=0Dh then typ=06h, p=p+SectorsPerHunk, ofs=p ; ;Old Parent+1
+ else goto error ;
+ byte[map+i*0Ch+00h]=typ ;
+ bigendian24bit[map+i*0Ch+01h]=len ;
+ bigendian48bit[map+i*0Ch+04h]=ofs ;
+ bigendian16bit[map+i*0Ch+0Ah]=crc ;
+ o=o+len, i=i+1 ;/
+ if bigendian16bit[hdr+0Ah]<>noncrc16(map,i*0Ch) then error ;-final crc check
+ 000h .. Uncompressed data
+ 000h .. Deflate-compressed data
+ 000h .. LZMA-compressed data (with lc=3, lp=0, pb=2) (without EOS end code)
+ 000h 1 Output format for 16bit samples ("L"=Little-endian, "B"=Big-endian)
+ 001h .. FLAC-compressed data frame(s)
+ 000h .. Huffman-compressed data (small tree, large tree, plus data)
+ 000h .. ECC Flags, (SectorsPerHunk+7)/8 bytes ;little-endian, bit0=1st flag
+ ... 2/3 Size of compressed Data part (SIZ) ;big-endian, 16bit or 24bit
+ ... SIZ Deflate compressed Data part ;uncompressed=930h*N bytes
+ ... .. Deflate compressed Subchannel part ;uncompressed=60h*N bytes
+ 000h .. ECC Flags, (SectorsPerHunk+7)/8 bytes ;little-endian, bit0=1st flag
+ ... 2/3 Size of compressed Data part (SIZ) ;big-endian, 16bit or 24bit
+ ... SIZ LZMA compressed Data part ;uncompressed=930h*N bytes
+ ... .. Deflate compressed Subchannel part ;uncompressed=60h*N bytes
+ 000h .. FLAC-compressed Data Frame(s) ;uncompressed=930h*N bytes
+ ... .. Deflate compressed Subchannel part ;uncompressed=60h*N bytes
+This isn't used on CDROMs and details are unknown/untested. It does reportedly
+exist in different versions, and does combine different compression methods for
+audio and video data.
Unknown, maybe same/similar as "avhu".
CHD source code claims that V3-V4 maps support "FLAC CDDA", but it doesn't
+actually seem to support that (audio discs compressed with chdman v0.145 are
+merely using Deflate).
If the sector's ECC flag is set:
+
Fix the 0Ch-byte Sync mark at [000h..00Bh]
+ Fix the 114h-byte ECC data at [81Ch..92Fh] in relation to Mode at [00Fh]
+ Fixing just means to overwrite those values (there's no XOR-filter or so).
+ CHD doesn't filter EDC values, MM:SS:FF:Mode Sector headers, nor Subheaders.
+ decompressing the subchannel part without decompressing the whole data part,
+ and for using libraries that don't return the end of the compressed data part
+There are no ECC flags (since Audio sectors don't have ECC).
+There is no size entry (one must decompress the whole FLAC part to find the
+begin of the Subchannel part).
+The FLAC output is always stored in BIG-ENDIAN format (because CHD likes to use
+big-endian for audio sectors, unlike formats like CUE/BIN).
The Data part and Subchannel part must be interleaved after decompression (to
+form 990h-byte sectors with 930h+60h bytes). The CHD map's CRC is then computed
+on that interleaved data.
+Most CHD files use metadata SUBTYPE:NONE which means that the 60h-byte
+subchannel data is simply zerofilled and one must replace it by default
+Index/Position values (AFTER the above CRC check). The CHD metadata lacks
+accurate info about Index values; the PREGAP part is supposedly meant to have
+Index=0 and the remaining sectors Index=1).
+Although CHD files can contain subchannel data, CHDMAN has very limited support
+for creating such files (the most practical way seems to be to convert
+CCD/IMG/SUB to TOC/BIN and then convert that to CHD format).
Decompressed CHD CDROM Sectors are always 990h bytes tall (930h+60h). However,
+the Metadata TYPE/SUBTYPE entries may specify smaller sizes (corresponding to
+the format of the original TOC/BIN or CUE/BIN image). CHD does arrange that
+data as so:
+
000h Sector Data (800h, 914h, 920h or 930h bytes)
+ ... Subchannel Data (0 or 60h bytes)
+ ... Zeropadding to 990h-byte size (0..190h bytes)
+ - The ECC-Filter works only for 930h-byte sectors (920h does also contain
+ ECC, but CHD can't filter that, resulting in very bad compression ratio)
+ - The last 60h-byte are supposed to be Deflate-compressed Subchannel Data
+ (but 800h..920h+60h sectors actually contain Zeropadding in that location)
+This is raw Deflate (despite of being called "zlib" in chd headers and source
+code; there aren't any ZLIB headers nor Adler checksums). V1-V4 does
+distinguish between "zlib" and "zlib+" (both are using normal Deflate) (V3/V4
+are always using "zlib+") (the "+" does probably just mean that file was
+compressed with improved compression ratio).
+CDROM File Compression ZIP/GZIP/ZLIB (Inflate/Deflate)
This contains a raw LZMA bitstream (without .lzma or .lz headers). The LZMA
+bitstream starts with 8 ignored bits, if Normalization occurs after last
+compression code, then it will also end with 8 ignored bits (those ignored bits
+aren't CHD-specific, they do also occur in other LZMA-based formats).
+CDROM File Compression LZMA
The data consists of raw FLAC Frames (without FLAC file header or FLAC metadata
+blocks), the format is always signed 16bit/stereo (NumChannels=2
+SampleDepth=16), the sample rate is don't care for compression purposes (the
+FLAC Frame headers have it set to 09h=44100Hz).
+Each FLAC Frame starts with a 14bit Sync mark (3FFEh), and ends with 16bit CRC.
+There are usually several FLAC frames per CHD hunk (one must decompress all
+FLAC frames, until reaching the decompressed hunk size).
+Each FLAC Frame contains Left samples, followed by Right samples. After
+decompression, CHD does store them in interleaved form (L,R,L,R,etc.)
+CDROM File Compression FLAC audio
This is using some custom CHD-specific Huffman compression.
+
decompress_chd_huffman_hunk:
+ InitBitstream(src,BigEndianMsbFirst) ;-init
+ codesizes[0..17h]=00h ;initially all unused ;\
+ codesizes[0]=GetBits(3) ;get first entry ;
+ i=GetBits(3)+1 ;leading unused entries ; small
+ @@small_tree_lop: ; tree
+ val=GetBits(3) ;
+ if val=07h then goto @@small_tree_done ;trailing unused entries ;
+ codesizes[i]=val, i=i+1 ;apply entry ;
+ if i<18h then goto @@small_tree_lop ;
+ @@small_tree_done: ;
+ nonlzh_explode_tree(codetree,codesizes,18h) ;/
+ data=00h ;\
+ @@large_tree_lop: ;
+ val=GetHuffCode(codetree)-1 ;using small tree codes ; large
+ if val>=00h then ; tree
+ data=val, codesizes[i]=data, i=i+1 ;
+ else ;
+ len=GetBits(3)+2 ;
+ if len=7+2 then len=GetBits(8)+7+2 ;
+ for n=1 to len, codesizes[i]=datal, i=i+1 ;
+ if i<100h then goto @@large_tree_lop ;
+ nonlzh_explode_tree(codetree,codesizes,100h) ;/
+ for n=1 to decompressed_size ;\data
+ [dst]=GetHuffCode(codetree), dst=dst+1 ;using large tree codes ;/
+A normal CDROM contains a series of sectors. The CHD format is violating that
+in several ways: It's removing Index0/Pregap sectors, and it's instead
+inserting dummy/padding sectors between tracks.
+
Track <---- Track1---------> <---- Track2---------> <--End-->
+ Section Index0 IndexN TrackPad Index0 IndexN TrackPad HunkPad
+ Real Disc Yes Yes - Yes Yes - -
+ CHD Header - Yes Yes - Yes Yes -
+ CHD Data - Yes Yes - Yes Yes Yes
+ Index0/pregap: Metadata PREGAP:sectors isn't stored in compressed data
+ Track padding: Metadata FRAMES:sectors is rounded up to N*4 sectors
+ Hunk padding: The last hunk is additionally rounded up to hunksize
+Parent files are only used for writeable media like harddisks. The idea is to
+store the original installation and operating system in a readonly Parent file,
+and to store changes that file in a writeable Child file.
+Unknown what determines which parent belongs to which child, and if parents can
+be nested with other grandparents. Anyways, Parents aren't needed for CDROMs
+(except, one could theoretically store CDROM patches in child files).
This can be used to reference to another identical hunk in the same file (eg.
+zerofilled sectors or other duplicated data). There are some restrictions for
+CDROMs: Data sector headers contain increasing sector numbers, so there won't
+be any identical sectors. However, Audio sectors can be identical (unless they
+are stored with subchannel info, which does also contain increasing sector
+numbers).
Mini is only used in V3/V4 maps. It does apparently store the "data" directly
+in the 8-byte Map offset field.
+
XXX Unknown what kind of "data" that is
+ (probably "normal compressed data", that happens to be 8 bytes or smaller).
+CHD files can (cannot) be generated with the CHDMAN.EXE tool:
+
chdman hdr meta features/requirements/bugs/quirks/failures...
+ v0.58 - - - ;-CHD didn't exist in older MAME versions
+ v0.59 V1 - - ;\
+ v0.71 V2 - - ; supports harddisk CHD files only, not cdrom
+ v0.78 V3 xxxx - ;/
+ v0.81 V3 CHCD bad ;-crashes after creating the CHD file header
+ v0.90 V3 CHCD ok ;\
+ v0.110 V3 CHCD ok ; requires cdrdao TOC/BIN as input (CUE/BIN does crash)
+ v0.111 V3 CHTR ok ; (warning: BIN filenames may not contain space chars!)
+ v0.112 V3 CHTR bug ; ;\works, but compression is somewhat bugged (files
+ v0.118 V3 CHTR bug ; ;/are BIGGER instead of SMALLER after compression)
+ v0.120 V3 CHTR ok ;
+ v0.130 V3 CHTR ok ;
+ v0.131 V4 CHTR ok ;/
+ v0.140 V4 CHT2 ok ;\requires "unicows.dll" (=Quintessential Media Player)
+ v0.145 V4 CHT2 ok ;/
+ v0.146 V5 CHT2 bad ;\says output file already exists (crashes on -f force)
+ v0.154 V5 CHT2 bad ;/
+ v0.155 V5 CHT2 bad ;\crashes instantly (shortly before CreateEventW)
+ v0.160 V5 CHT2 bad ;/
+ v0.161 V5 CHT2 bad ;\says output file already exists (crashes on -f force)
+ v0.169 V5 CHT2 bad ;/
+ v0.170 V5 CHT2 bad ;\missing KERNEL32.DLL:AddVectoredExceptionHandler
+ v0.217 V5 CHT2 bad ;/
+ v0.218 V5 CHT2 bad ;\requires "newer version of windows" (64bit)
+ v0.247 V5 CHT2 bad ;/
+CHD source code (see files cdrom.*, chd*.*, etc):
https://github.com/mamedev/mame/tree/master/src/lib/util
+CHDMAN commandline tool for generating chd files:
https://github.com/mamedev/mame/blob/master/src/tools/chdman.cpp
+CHD decompression clone with useful comments:
https://github.com/SnowflakePowered/chd-rs/tree/master/chd-rs/src
+CHD format reverse-engineering thread:
http://www.psxdev.net/forum/viewtopic.php?f=70&t=3980
+Contains raw sectors without any sub-channel information (and thus it's
+restricted to the ISO filesystem region only, and cannot contain extras like
+additional audio tracks or additional sessions). The image should start at
+00:02:00 (although I wouldn't be surprised if some \<might> start at
+00:00:00 or so). Obviously, all sectors must have the same size, either 800h or
+930h bytes (if the image contains only Mode1 or Mode2/Form1 sectors then 800h
+bytes would usually enough; if it contains one or more Mode2/Form2 sectors then
+all sectors should be 930h bytes).
+Handling .ISO files does thus require to detect the image's sector size, and to
+search the sector that contains the first ISO Volume Descriptor. In case of
+800h byte sectors it may be additionally required to detect if it is a Mode1 or
+Mode2/Form1 image; for PSX images (and any CD-XA images) it'd be Mode2.
Something. Can contain compressed or uncompressed CDROM-images. Fileformat and
+compression ratio are unknown. Also unknown if it allows random-access.
+Some info on (uncompressed) .C2D files can be found in libmirage source code.
This contains a compressed ISO filesystem, without supporting any CD-specific
+features like Tracks, FORM2 sectors, or CD-DA Audio.
http://www.ezbsystems.com/isz/iszspec.txt
+The format might be suitable for PC CDROMs, but it's useless for PSX CDROMs.
Reportedly a "compressed" MDS/MDF file, supported by Daemon Tools.
+Other info says that MDX is just MDS/MDF merged into a single file, without
+mentioning any kind of "compression" support.
+Basically... Daemon Tools is Adware that can merge MDS+MDF into one MDX file...
+with additional Advertising?
+However, the MDS+MDF format is completely different than MDX format:
+
000h 10h ID ("MEDIA DESCRIPTOR") (weirdly, same as in Alcohol .MDS)
+ 010h 2 Unknown (02h,01h) (maybe version or so)
+ 012h 1Ah Copyright string (A9h," 2000-2015 Disc Soft Ltd.")
+ 02Ch 4 Unknown (FFFFFFFFh)
+ 030h 4 Offset to Unknown Footer (322040h) (N*800h+40h)
+ 034h 4 Unknown (0)
+ 038h 4 Unknown (B0h)
+ 03Ch 4 Unknown (0)
+ 040h N*800h Sector Data
+ 322040h 270h Unknown (Advertising IDs? CRCs? Encrypted CUE sheet? Garbage?)
+Custom format used by PSIO (an SD-card based CDROM-drive emulator connected to
+PSX expansion port). The .CU2 file is somewhat intended to be smaller and
+easier to parse than normal .CUE files, the drawback is that it's kinda
+non-standard, and doesn't support INDEX and ADSR information. A sample .CUE
+file looks as so:
+
ntracks 3
+ size 39:33:17
+ data1 00:02:00
+ track02 31:36:46
+ track03 36:03:17
+ ;(insert 2 blanks lines here, and insert 1 leading space in next line)
+ trk end 39:37:17
+This is a rather crude file format, used only by the Xe Emulator. The files are
+meant to be generated by a utility called CDR (CD Image Ripper), which, in
+practice merely displays an "Unable to read TOC." error message.
+The overall file structure is, according to "Xe User's Manual":
+
header: 200h bytes header (see below)
+ data: 990h bytes per sector (2352 Main, 96 Sub), 00:00:00->Lead Out
+ 000h 00
+ 001h 00
+ 002h First Track
+ 003h Last Track
+ 004h Track 1 (ADR << 4) | CTRL ;\
+ 005h Track 1 Start Minutes ; Track 1
+ 006h Track 1 Start Seconds ;
+ 007h Track 1 Start Frames ;/
+ ... ... ;-Probably Further Tracks (?)
+ n+0 Last Track Start Minutes ;\
+ n+1 Last Track Start Seconds ; Last Track
+ n+2 Last Track Start Frames ;
+ n+3 Last Track (ADR << 4) | CTRL ;/
+ n+4 Lead-Out Track Start Minutes ;\
+ n+5 Lead-Out Track Start Seconds ; Lead-Out
+ n+6 Lead-Out Track Start Frames ;
+ n+7 Lead-Out Track (ADR << 4) | CTRL ;/
+ ... 00
+ 1FFh 00
+PSX software can access the CDROM via Port 1F801800h..1F801803h (as described
+in the previous chapters). The following chapters describe the inner workings
+of the PSX CDROM controller - this information is here for curiosity only -
+normally PSX software cannot gain control of those lower-level stuff (although
+some low level registers can be manipulated via Test commands, but that will
+usually conflict with normal operation).
The Playstation CDROM drive is controlled by a MC68HC05 8bit CPU with on-chip
+I/O ports and on-chip BIOS ROM. There is no way to reprogram that BIOS, nor to
+tweak it to execute custom code in RAM.
+CDROM Internal HC05 Instruction Set
+CDROM Internal HC05 On-Chip I/O Ports
+CDROM Internal HC05 I/O Port Usage in PSX
+CDROM Internal HC05 Motorola Selftest Mode
+The PSX can read HC05 I/O Ports and RAM via Test Commands:
+CDROM - Test Commands - Read HC05 SUB-CPU RAM and I/O Ports
This chip handles error correction and ADPCM decoding, and acts as some sort of
+FIFO interface between main/sub CPUs and incoming cdrom sector data. On the
+MIPS Main CPU it is controlled via Port 1F801800h..1F801803h.
+CDROM Controller I/O Ports
+On the HC05 Sub CPU it is controlled via Port A (data in/out), Port E
+(address/index), and Port D (read/write/select signals); the HC05 doesn't have
+external address/data bus, so one must manually access the CXD1815Q via those
+ports.
+CDROM Internal CXD1815Q Sub-CPU Configuration Registers
+CDROM Internal CXD1815Q Sub-CPU Sector Status Registers
+CDROM Internal CXD1815Q Sub-CPU Address Registers
+CDROM Internal CXD1815Q Sub-CPU Misc Registers
+The PSX can read/write the Decoder I/O Ports and SRAM via Test commands:
+CDROM - Test Commands - Read/Write Decoder RAM and I/O Ports
+The sector buffer used in the PSX is 32Kx8 SRAM. Old PU-7 boards are using
+CXD1199BQ chips, later boards are using CXD1815Q, and even later boards have
+the stuff intergrated in the SPU. Note: The CXD1199BQ/CXD1815Q are about 99%
+same as described in CXD1199AQ datasheet.
Older PSX mainboards are using two separate chips:
+CDROM Internal Commands CX(0x..3x) - CXA1782BR Servo Amplifier
+CDROM Internal Commands CX(4x..Ex) - CXD2510Q Signal Processor
+Later PSX mainboards have the above intergrated in a single chip, with some
+extended features:
+CDROM Internal Commands CX(0x..Ex) - CXD2545Q Servo/Signal Combo
+Later version is CXD1817R (Servo/Signal/Decoder Combo).
+Even later PSX mainboards have it integrated in the Sound Chip: CXD2938Q
+(SPU+CDROM) with some changed bits and New SCEx transfer:
+CDROM Internal Commands CX(0x..Ex) - CXD2938Q Servo/Signal/SPU Combo
+Finally, PM-41(2) boards are using a CXD2941R chip (SPU+CDROM+SPU_RAM), unknown
+if/how far the CDROM part of that chip differs from CXD2938Q.
+Some general notes:
+CDROM Internal Commands CX(xx) - Notes
+CDROM Internal Commands CX(xx) - Summary of Used CX(xx) Commands
+The PSX can manipulate the CX(..) registers via some test commands:
+CDROM - Test Commands - Test Drive Mechanics
+Note: Datasheets for CXD2510Q/CXA1782BR/CXD2545Q do exist.
Pinouts - DRV Pinouts
+Pinouts - HC05 Pinouts
Opcode Clk HINZC Name Syntax
+ x6 ... 2-5 --NZ- LDA MOV A,<op> ;A=op
+ xE ... 2-5 --NZ- LDX MOV X,<op> ;X=op
+ x7 ... 4-6 --NZ- STA MOV <op>,A ;op=A
+ xF ... 4-6 --NZ- STX MOV <op>,X ;op=X
+ xC ... 2-4 ----- JMP JMP <op> ;PC=op
+ xD ... 5-7 ----- JSR CALL <op> ;[SP]=PC, PC=op
+ xB ... 2-5 H-NZC ADD ADD A,<op> ;A=A+op
+ x9 ... 2-5 H-NZC ADC ADC A,<op> ;A=A+op+C
+ x0 ... 2-5 --NZC SUB SUB A,<op> ;A=A-op
+ x2 ... 2-5 --NZC SBC SBC A,<op> ;A=A-op-C
+ x4 ... 2-5 --NZ- AND AND A,<op> ;A=A AND op
+ xA ... 2-5 --NZ- ORA OR A,<op> ;A=A OR op
+ x8 ... 2-5 --NZ- EOR XOR A,<op> ;A=A XOR op
+ x1 ... 2-5 --NZC CMP CMP A,<op> ;A-op
+ x3 ... 2-5 --NZC CPX CMP X,<op> ;X-op
+ x5 ... 2-5 --NZ- BIT TEST A,<op> ;A AND op
+ A7,AF,AC = Reserved (no STA/STX/JMP with immediate operand)
+ Opcode Clk ALU/LDA/LDX Clk STA/STX Clk JMP/CALL
+ Ax nn 2 cmd r,nn - N/A -/6 call relative (BSR)
+ Bx nn 3 cmd r,[nn] 4 mov [nn],r 2/5 cmd nn
+ Cx nn mm 4 cmd r,[nnmm] 5 mov [nnmm],r 3/6 cmd nnmm
+ Dx nn mm 5 cmd r,[X+nnmm] 6 mov [X+nnmm],r 4/7 cmd X+nnmm
+ Ex nn 4 cmd r,[X+nn] 5 mov [X+nn],r 3/6 cmd X+nn
+ Fx 3 cmd r,[X] 4 mov [X],r 2/5 cmd X
+ Opcode Clk HINZC Name Syntax
+ xC ... 3-6 --NZ- INC INC op ;increment ;op=op+1
+ xA ... 3-6 --NZ- DEC DEC op ;decrement ;op=op-1
+ xF ... 3-6 --01- CLR ?? op,00h ;clear ;op=op AND 00h
+ x3 ... 3-6 --NZ1 COM NOT op ;complement ;op=op XOR FFh
+ x0 ... 3-6 --NZC NEG NEG op ;negate ;op=00h-op
+ x9 ... 3-6 --NZC ROL RCL op ;rotate left through carry
+ x6 ... 3-6 --NZC ROR RCR op ;rotate right through carry
+ x8 ... 3-6 --NZC LSL SHL op ;shift left logical
+ x4 ... 3-6 --0ZC LSR SHR op ;shift right logical
+ x7 ... 3-6 --NZC ASR SAR op ;shift right arithmetic
+ xD ... 3-5 --NZ- TST TEST op,FFh ;test for negative or zero (AND FFh?)
+ x1,x2,x5,xB,xE = Reserved (except for: 42 = MUL)
+ Opcode Clk RMW Clk CLR Clk TST
+ 3x nn 5 cmd [nn] 5 MOV [nn],00h 4 TEST [nn],0FFh
+ 4x 3 cmd A 3 MOV A,00h,slow 3 TEST A,0FFh,slow
+ 5x 3 cmd X 3 MOV X,00h,slow 3 TEST X,0FFh
+ 6x nn 6 cmd [X+nn] 6 MOV [X+nn],00h 5 TEST [X+nn],0FFh
+ 7x 5 cmd [X] 5 MOV [X],00h 4 TEST [X],0FFh
+ Opcode Clk HINZC Name Syntax
+ 00h+i*2 nn dd 5 ----C BRSET JNZ [nn].i,dest ;C=[nn].i, branch if set
+ 01h+i*2 nn dd 5 ----C BRCLR JZ [nn].i,dest ;C=[nn].i, branch if clear
+ 10h+i*2 nn 5 ----- BSET SET [nn].i ;set [nn].i
+ 11h+i*2 nn 5 ----- BCLR RES [nn].i ;clear [nn].i
+ Opcode Clk HINZC Name Syntax
+ 20 nn 3 ----- BRA JR nn ;branch always
+ 21 nn 3 ----- BRN NUL nn ;branch never
+ 22 nn 3 ----- BHI JA nn ;if C=0 and Z=0, higher ?
+ 23 nn 3 ----- BLS JBE nn ;if C=1 or Z=1, lower or same ?
+ 24 nn 3 ----- BCC/BHS JNC/JAE nn ;if C=0, carry clear, higher.same
+ 25 nn 3 ----- BCS/BLO JC/JB nn ;if C=1, carry set, lower
+ 26 nn 3 ----- BNE JNZ/JNE nn ;if Z=0, not equal / not zero
+ 27 nn 3 ----- BEQ JZ/JE nn ;if Z=1, equal / zero
+ 28 nn 3 ----- BHCC JNH nn ;if H=0, half-carry clear
+ 29 nn 3 ----- BHCS JH nn ;if H=1, half-carry set
+ 2A nn 3 ----- BPL JNS nn ;if S=0, plus / not signed
+ 2B nn 3 ----- BMI JS nn ;if S=1, minus / signed
+ 2C nn 3 ----- BMC JEI nn ;if I=0, interrupt mask clear
+ 2D nn 3 ----- BMS JDI nn ;if I=1, interrupt mask set
+ 2E nn 3 ----- BIL JIL nn ;if XX=LO, interrupt line low
+ 2F nn 3 ----- BIH JIH nn ;if XX=HI, interrupt line high
+ AD nn 6 ----- BSR CALL relative nn ;branch to subroutine always
+ Opcode Clk HINZC Name Syntax
+ 9D 2 ----- NOP NOP ;no operation
+ 97 2 ----- TAX MOV X,A ;transfer A to X
+ 9F 2 ----- TXA MOV A,X ;transfer X to A
+ 9C 2 ----- RSP MOV SP,00FFh ;reset stack pointer (SP=00FFh)
+ 42 11 0---0 MUL MUL X,A ;X:A=X*A (unsigned multiply)
+ 81 6 ----- RTS RET ;return from subroutine
+ 80 9 xxxxx RTI RETI ;return from interrupt
+ 99 2 ----1 SEC STC ;set carry flag
+ 98 2 ----0 CLC CLC ;clear carry flag
+ 9B 2 -1--- SEI DI ;set interrupt mask (disable ints)
+ 9A 2 -0--- CLI EI ;clear interrupt mask (enable ints)
+ 8E ..2 -0--- STOP STOP ;?
+ 8F ..2 -0--- WAIT WAIT ;?
+ 83 10 -1--- SWI SWI ;software interrupt ...? PC=[FFFCh]
+ <IRQ> ? ????? Interrupt ;? PC=[FFFxh]
+ <RESET> ? ????? Reset ;? PC=[FFFEh]
+ 82,84..8D,90..96,9E = Reserved
+ A 8bit accumulator
+ X 8bit index register
+ SP 6bit stack pointer (range 00C0h..00FFh)
+ PC 16bit program pointer (range 0000h..FFFFh)
+ CCR 5bit condition code register (flags) (111HINZC)
+ SP.highest PC.lo
+ PC.hi
+ X
+ A
+ SP.lowest Flags (CCR, 5bit condition code register) (111HINZC)
+ nn immediate ;00h..FFh
+ [nn] direct address ;[0000h..00FFh]
+ [nnmm] extended address ;[0000h..FFFFh]
+ [X] indexed, no offset ;[0000h..00FFh]
+ [X+nn] indexed, 8bit offset ;[0000h..01FEh]
+ [X+nnmm] indexed, 16bit offset ;[0000h..FFFFh]
+ [nn].i bit ;[0000h..00FFh].bit0..7
+ dd relative ;$+2..3+(-80h..+7Fh)
+ operand "X+nn" performs an unsigned addition, and can address 0000h..01FEh.
+ 16bit operands (nnmm) are encoded in BIG-ENDIAN format (same for pushed PC).
+Exception vectors are 16bit BIG-ENDIAN values at FFF0h-FFFFh (or at FFE0h-FFEFh
+when running in Motorola Bootstrap mode).
+
Vector Prio Usage
+ FFF0h 7=lo TBI Vector (Timebase)
+ FFF2h 6 SSPI Vector (SPI bus) (SPI1 and SPI2)
+ FFF4h 5 Timer 2 Interrupt Vector (Timer 2 Input/Compare)
+ FFF6h 4 Timer 1 Interrupt Vector (Timer 1 Input/Compare/Overflow)
+ FFF8h 3 KWI Vector (Key Wakeup) (KWI0..7 pins)
+ FFFAh 2 External Interrupt Vector (/IRQ1 and /IRQ2 pins)
+ FFFCh none Software Interrupt Vector (SWI opcode) ;\regardless of
+ FFFEh 1=hi Reset Vector (/RESET signal and COP) ;/CPU's "I"
+ .hc05 select HC05 instruction set (default would be .mips)
+ .nocash select nocash syntax (default would be .native opcode names)
+ db ... define 8bit byte(s), or quoted ascii strings
+ dw ... define 16bit word(s) in BIG ENDIAN (for HC05 exception vectors)
+ org nnnn change origin for following opcodes
+ end end of file
+ mov c,[nn].i alias for "jnz [nn].i,$+3" (dummy jump & set carry=[nn].i)
+ 0 OPTM Option Map Select (bank-switching for Port 00h..0Fh)
+ 1 FOSCE Fast (Main) Oscillator Enable (0=Disable OSC, 1=Normal)
+ 2-3 SYS System Clock Select (0=OSC/2, 1=OSC/4, 2=OSC/64, 3=XOSC/2)
+ 4-5 - Not used (0)
+ 6 STUP XOSC Time Up Flag (R)
+ 7 FTUP OSC Time Up Flag (R) (0=Busy, 1=Ready/Good/Stable)
+These are general purpose I/O ports (controlling external pins). Some ports are
+Input-only, and some can be optionally used for special things (like IRQs,
+SPI-bus, or as Timer input/output).
+
PA.0-7 PAn Port A Bit0..7 Input/Output (0=Low, 1=High) (R/W)
+ PB.0-7 PBn Port B Bit0..7 Input /KWI0..7 (0=Low, 1=High) (R)
+ PC.0 PC0 Port C Bit0 Input/Output /SDI1 (SPI)(0=Low, 1=High) (R/W)
+ PC.1 PC1 Port C Bit1 Input/Output /SDO1 (SPI)(0=Low, 1=High) (R/W)
+ PC.2 PC2 Port C Bit2 Input/Output /SCK1 (SPI)(0=Low, 1=High) (R/W)
+ PC.3 PC3 Port C Bit3 Input/Output /TCAP (T1) (0=Low, 1=High) (R/W)
+ PC.4 PC4 Port C Bit4 Input/Output /EVI (T2) (0=Low, 1=High) (R/W)
+ PC.5 PC5 Port C Bit5 Input/Output /EVO (T2) (0=Low, 1=High) (R/W)
+ PC.6 PC6 Port C Bit6 Input/Output /IRQ2 (0=Low, 1=High) (R/W)
+ PC.7 PC7 Port C Bit7 Input/Output /IRQ1 (0=Low, 1=High) (R/W)
+ PD.0-7 PDn Port D Bit0..7 Input/Output (0=Low, 1=High) (R/W)
+ PE.0-7 PEn Port E Bit0..7 Input/Output (0=Low, 1=High) (R/W)
+ PF.0-7 PFn Port F Bit0..7 Input/Undoc A/D-input (0=Low, 1=High) (R)(R/W)
+ DDRX.0-7 DDRXn Port X Data Direction Bit0..7 (0=Input, 1=Output) (R/W)
+ RCR1.0 RAL Port A.Bit0-3 Pullup Resistors (0=Off, 1=On)
+ RCR1.1 RAH Port A.Bit4-7 Pullup Resistors (0=Off, 1=On)
+ RCR1.2 RBL Port B.Bit0-3 Pullup Resistors (0=Off, 1=On)
+ RCR1.3 RBH Port B.Bit4-7 Pullup Resistors (0=Off, 1=On)
+ RCR1.4 RGL Port G.Bit0-3 Pullup Resistors (0=Off, 1=On) ;\
+ RCR1.5 RGH Port G.Bit4-7 Pullup Resistors (0=Off, 1=On) ; on chips
+ RCR1.6 RHL Port H.Bit0-3 Pullup Resistors (0=Off, 1=On) ; with Port G,H
+ RCR1.7 RHH Port H.Bit4-7 Pullup Resistors (0=Off, 1=On) ;/
+ RCR2.0-7 RCn Port C.Bit0-7 Pullup Resistors (0=Off, 1=On)
+ WOM1.0 AWOML Port A.Bit0-3 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
+ WOM1.1 AWOMH Port A.Bit4-5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
+ WOM1.2 GWOML Port G.Bit0-3 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
+ WOM1.3 GWOMH Port G.Bit4-5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
+ WOM1.4 HWOML Port H.Bit0-3 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
+ WOM1.5 HWOMH Port H.Bit4-5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
+ WOM1.6-7 - Not used (0)
+ WOM2.0-5 CWOMn Port C.Bit0..5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
+ WOM2.6-7 - Not used (always both bits set)
+==== Interrupts =====
0-1 - Not used (0)
+ 2 IRQ2S IRQ2 Select Edge-Sensitive Only (0=LowLevelAndNegEdge, 1=NegEdge)
+ 3 IRQ1S IRQ1 Select Edge-Sensitive Only (0=LowLevelAndNegEdge, 1=NegEdge)
+ 4 KWIE Key Wakeup Interrupt Enable (0=Disable, 1=Enable)
+ 5 - Not used (0)
+ 6 IRQ2E IRQ2 Interrupt Enable (0=Disable, 1=Enable)
+ 7 IRQ1E IRQ1 Interrupt Enable (0=Disable, 1=Enable)
+ 0 RKWIF Reset Key Wakeup Interrupt Flag (0=No Change, 1=Reset) (W)
+ 1 - Not used (0)
+ 2 RIRQ2 Reset IRQ2 Interrupt Flag (0=No Change, 1=Reset) (W)
+ 3 RIRQ1 Reset IRQ1 Interrupt Flag (0=No Change, 1=Reset) (W)
+ 4 KWIF Key Wakeup Interrupt Flag (PB/KWI) (0=No, 1=IRQ) (R)
+ 5 - Not used (0)
+ 6 IRQ2F IRQ2 Interrupt Flag (PC6) (0=No, 1=IRQ) (R)
+ 7 IRQ1F IRQ1 Interrupt Flag (PC7) (0=No, 1=IRQ) (R)
+ 0-7 KWIEn Port B.Bit0..7 Key Wakeup Interrupt Enable (0=Disable, 1=Enable)
+==== SPI Bus ====
0 SPRn SPI Clock Rate (0=ProcessorClock/2, 1=ProcessorClock/16)
+ 1-3 - Not used (0)
+ 4 MSTRn SPI Master Mode Select (0=Slave/SCK.In, 1=Master/SCK.Out)
+ 5 DORDn SPI Data Transmission Order (0=MSB First, 1=LSB First)
+ 6 SPEn SPI Enable (SPI1:PortC, SPI2:PortG) (0=Disable, 1=Enable)
+ 7 SPIEn SPI Interrupt Enable (... ack HOW?) (0=Disable, 1=Enable)
+ 0-5 - Not used (0)
+ 6 DCOLn SPI Data Collision Occurred (0=No, 1=Collision)
+ 7 SPIFn SPI Transfer Complete Flag (0=Busy, 1=Complete) (R)
+ 0-7 BITn Data to be sent / being received
+==== Time Base / Config ====
0-1 T2R Timer2 Prescaler (0=SysClk, 1=SysClk/4, 2=SysClk/32, 3=SysClk/256)
+ 2-3 T3R PWM Prescaler (0=CLK3, 1=CLK3/2, 2=CLK3/8, 3=Timer2compare)
+ 4-6 - Not used (0)
+ 7 TBCLK Time Base Clock (0=XOSC, 1=OSC/128) ;<-- write-able only ONCE
+ 0 COPC COP Clear 2bit COP timeout divider (0=No Change, 1=Clear) (W)
+ 1 COPE COP Enable ;<-- write-able only ONCE
+ 2 - Not used (0)
+ 3 RTBIF Reset Time Base Interrupt Flag (0=No Change, 1=Clear TBIF) (W)
+ 4-5 TBR Time Base Interrupt Rate (0=TBCLK/128, 1=/4096, 2=/8192, 3=/16384)
+ 6 TBIE Time Base Interrupt Enable (0=Disable, 1=Enable)
+ 7 TBIF Time Base Interrupt Flag (0=No, 1=IRQ) (R)
+ 0-4 - Not used (0)
+ 5 XOSCR XOSC Feedback Resistor (0=None, 1=Implemented)
+ 6 OSCR OSC Feedback Resistor (0=None, 1=Implemented)
+ 7 RSTR /RESET Pullup Resistor (0=None, 1=Implemented)
+==== Timer 1 ====
0 OLVL Output Level on TCMP pin on Compare Match? (0=Low, 1=High)
+ 1 IEDG Input Edge on TCAP pin (0=NegativeEdge, 1=PositiveEdge)
+ 2-4 - Not used (0)
+ 5 TOIE Timer Overflow Interrupt Enable (0=Disable, 1=Enable)
+ 6 OC1IE Output Compare Interrupt Enable (0=Disable, 1=Enable)
+ 7 ICIE Input Capture Interrupt Enable (0=Disable, 1=Enable)
+ 0-4 - Not used (0)
+ 5 TOF Timer Overflow Flag (0=No, 1=Yes) (R) ;clear by Port 19h access
+ 6 OC1F Output Compare Flag (0=No, 1=Yes) (R) ;clear by Port 17h access
+ 7 ICF Input Capture Flag (0=No, 1=Yes) (R) ;clear by Port 15h access
+ 0-15 Capture Value
+ 0-15 Compare Value
+ 0-15 Counter
+ 0-15 Alternate Counter (uh, what?)
+==== Timer 2 ====
0 OL2 Timer Output 2 Edge (0=Falling, 1=Rising)
+ 1 OE2 Timer Output 2 Enable (EVO) (0=Disable, 1=Enable)
+ 2 IL2 Timer Input 2 Edge/Level (0=Low/Falling, 1=High/Rising)
+ 3 IM2 Timer Input 2 Mode Select for EVI (0=EventMode, 1=GatedByCLK2)
+ 4 T2CLK Timer 2 Clock Select (0=CLK2 from Prescaler, 1=EXCLK from EVI)
+ 5 - Not used (0)
+ 6 OC2IE Output Compare 2 Interrupt Enable (0=Disable, 1=Enable)
+ 7 TI2IE Timer Input 2 Interrupt Enable (EVI) (0=Disable, 1=Enable)
+ 0-1 - Not used (0)
+ 2 ROC2F Reset Output Compare 2 Interrupt Flag (0=No Change, 1=Clear) (W)
+ 3 RTI2F Reset Timer Input 2 Interrupt Flag (0=No Change, 1=Clear) (W)
+ 4-5 - Not used (0)
+ 6 OC2F Output Compare 2 Interrupt Flag (0=No, 1=Yes) (R)
+ 7 TI2F Timer Input 2 Interrupt Flag (EVI) (0=No, 1=Yes) (R)
+ 0-7 Compare Value ("Transferred to buffer on certain events?")
+ 0-7 Counter Value, incremented at T2R (set to 01h on Compare Matches)
+==== Reserved ====
Reading this port via Sony's test command returns 20h (same as openbus), but
+reading it via Motorola's selftest function returns 00h (unlike openbus), so it
+seems to have some unknown/undocumented function; bit5 might indicate selftest
+mode, or it might reflect initialization of whatever other ports.
These ports are unused/reserved. Trying to read them on a PSone does return 20h
+(possibly the prefetched next opcode value from the RAM test command). Other
+HC05 variants contain some extra features in these ports:
+CDROM Internal HC05 On-Chip I/O Ports - Extras
+The PSX CDROM BIOS doesn't use any of these ports - execpt, it is writing
+[20h]=2Eh (possibly to disable unused LCD hardware; which might be actually
+present in the huge 80pin HC05 chips on old PU-7 mainboards).
Openbus values can be read from invalid memory locations, on PSX with 52pin
+chips:
+
I/O bank 0: 0:06h..07h, 0:0Dh..0Fh
+ I/O bank 1: 1:01h, 1:06h..07h, 1:0Ch..0Dh, and upper 4bit of 1:05h
+ Unbanked I/O: 20h..3Dh
+ Unused Memory: 0240h..0FFFh, 5000h..FDFFh
+ [nn],[mmnn],[nn+x],[mmnn+x] --> returns LAST byte of current opcode (=nn)
+ [x] --> returns FIRST byte of following opcode
+This is a second SPI channel, works same as first SPI channel, but using the
+lower 3bits of Port G (instead of Port C) for the SPI signals.
PG.0 PG0 Port G Bit0 Input/Output /SDI2 (0=Low, 1=High) (R/W)
+ PG.1 PG1 Port G Bit1 Input/Output /SDO2 (0=Low, 1=High) (R/W)
+ PG.2 PG2 Port G Bit2 Input/Output /SCK2 (0=Low, 1=High) (R/W)
+ PG.3 PG3 Port G Bit3 Input/Output /TCMP (0=Low, 1=High) (R/W)
+ PG.4 PG4 Port G Bit4 Input/Output /PWM0 (0=Low, 1=High) (R/W)
+ PG.5 PG5 Port G Bit5 Input/Output /PWM1 (0=Low, 1=High) (R/W)
+ PG.6 PG6 Port G Bit6 Input/Output /PWM2 (0=Low, 1=High) (R/W)
+ PG.7 PG7 Port G Bit7 Input/Output /PWM3 (0=Low, 1=High) (R/W)
+ PH.0-7 PHn Port H Bit0..7 Input/Output (0=Low, 1=High) (R/W)
+ PJ.0-3 PJn Port J Bit0..3 Output (0=Low, 1=High) (R/W)
+ PJ.4-7 - Not used (0)
+ 0-7 DDRXn Port X Data Direction Bit0..7 (0=Input, 1=Output) (R/W)
+ 0 - Not used (0)
+ 1 PDH Select Port D (H) (0=FP35-FP38 pins, 1=PD7-PD4 pins)
+ 2 PEL Select Port E (L) (0=FP31-FP34 pins, 1=PE3-PE0 pins)
+ 3 PEH Select Port E (H) (0=FP27-FP30 pins, 1=PE7-PE4 pins)
+ 4 - Not used (0)
+ 5-6 DUTY LCD Duty Select (...)
+ 7 LCDE LCD Output Enable BP and FP pins (0=Disable, 1=Enable)
+ 0-3 First Data Unit ;\Fourty 4bit LCD values (in the twenty registers)
+ 4-7 Second Data Unit ;/(some duties use only the LSBs of that 4bit values)
+ 0-3 CH0-3 PWM Channel 0..3 on Port G.Bit4-7 Enable (0=Disable, 1=Enable)
+ 4-7 - Not used (0)
+ 0-7 PWM Counter, incremented at PHI2 (range 01h..FFh)
+ 0-7 Duty (N cycles High, 255-N cycles Low)
+ 0-3 A/D Conversion result (probably unsigned, 00h=Lowest, FFh=Max voltage?)
+ 0-3 CH0-3 A/D Channel (0..7=PortF.Bit0-7, 8..0Fh=Reserved/Vref/FactorTest)
+ 4 - Not used (0)
+ 5 ADON A/D Charge Pump enable (0=Disable, 1=Enable)
+ 6 ADRC A/D RC Oscillator On (0=Normal/Use CPU Clock, 1=Use RC Clock)
+ 7 COCO A/D Conversion Complete (0=Busy, 1=Complete) (R)
+ 0 PGM EPROM Program Command (0=Normal, 1=Apply Programming Power)
+ 1 ELAT EPROM Latch Control (0=Normal/Read, 1=Latch/Write)
+ 2-7 RES Reserved for Factory Testing (always 0 in user mode)
+ porta.0-7 i/o CXD1815Q.Data (indexed via Port E)
+ porta.0 in debug.dta.serial.in ;\normally unused (exists in early bios)
+ porta.1 out debug.dta.serial.out ; (prototype/debug_status stuff)
+ porta.2 out debug.clk.serial.out ;/(with portc.5 = debug.select)
+ portb.0 in F-BIAS ;unused
+ portb.1 in SCEx input (serial 250 baud, received via 1000Hz timer2 irq)
+ portb.2 in LMTSW aka /POS0 ;\pos0 and door switches
+ portb.3 in DOOR aka SHELL_OPEN ;/
+ portb.4 in TEST2
+ portb.5 in TEST1 (CL316) enter test mode (instead of mainloop)
+ portb.6 in COUT ;<-- unused, extra pin, not "SENSE=COUT"
+ portb.7 in CXD2510Q.SENSE ;-from CXD2510Q (and forwarded from CXA1782BR)
+ portc.0 in CXD2510Q.SUBQ ;\
+ portc.1 in? NC (SPI.OUT) ; used via SPDR1 to receive SPI bus SUBQ data
+ portc.2 out CXD2510Q.SQCK ;/
+ portc.3 out SPEED
+ portc.4 out ="SPEED XOR 1" ... AL/TE ... or CG ... or MIRR ?
+ portc.5 out ROMSEL: debug.select (or "SCLK" on later boards???)
+ portc.6 in CXD1815Q.XINT/IRQ2 ;unused (instead INTSTS bits are polled)
+ portc.7 in CXD2510Q.SCOR/IRQ1 ;used via polling INTSR.7 (not as irq)
+ portd.0 out NC ;-unused (always 1)
+ portd.1 out CXD2510Q.DATA ;\serial bus for CXD2510Q
+ portd.2 out CXD2510Q.XLAT ; (and also forwarded to CXA1782BR)
+ portd.3 out CXD2510Q.CLOK ;/
+ portd.4 out CXD1815Q.DECCS ;\
+ portd.5 out CXD1815Q.DECWR ; control for data/index on Port A/E
+ portd.6 out CXD1815Q.DECRD ;/
+ portd.7 out LDON ... IC723.Pin11 ... maybe "laser on" ?
+ porte.0-4 out CXD1815Q.Index (for data on Port A)
+ porte.5 out NC, not used
+ porte.6 out NC, see "idx_4xh" maybe test signal ???
+ porte.7 out? NC, TEST? configured as OUTPUT... but used as INPUT?
+ portf.0 out NC, TX ;\
+ portf.1 in NC, RX ; not used by sony's cdrom bios
+ portf.2 out NC, RTS ; (but used by motorola's bootstrap rom)
+ portf.3 out NC, DTR ;/
+ portf.0 in Serial Data In (from daughterboard) ;\
+ portf.1 out Serial Data Out (to daughterboard) ; usage in SCPH-5903
+ portf.2 out Serial Clock Out (to daughterboard) ; (PSX with Video CD)
+ portf.3 out Audio/Video Select (0=Normal, 1=VCD) ;/
+ portf.4-7 - NC, not used (probably pins don't even exist)
+ SPI 1 - used for receiving SUBQ (via Port C)
+ IRQ 1 - used for latching/polling SUBQ's "SCOR" (not used as interrupt)
+ IRQ 2 - connects to CXD1815Q.XINT, but isn't actually used at all
+ Timer 1 - unused
+ Timer 2 - generates 1000Hz interrupts (for 250 baud "SCEx" string transfers)
+ DDRx - data directions for Port A-F (as listed above)
+52-pin chips are used on LATE-PU-8 boards, and on later boards ranging from
+PU-18 up to PM-41(2).
+CDROM Internal HC05 Motorola Selftest Mode (52pin chips)
80-pin chips are used PU-7, EARLY-PU-8, and PU-9 boards.
+CDROM Internal HC05 Motorola Selftest Mode (80pin chips)
Sony's Digital Joypad and Mouse are using 32pin chips (with TQFP-32 package),
+which are probably containing Motorola HC05 CPUs, too. Unknown if/how those
+chips can be switched into bootstrap/dumping modes.
The Motorola MC68HC05 chips are including a small bootstrap ROM which gets
+activated upon /RESET when having two pins strapped to following levels:
+
Pin30 PortC.6 (/IRQ2) (/XINT) ----> wire to 3.5V (VCC)
+ Pin31 PortC.7 (/IRQ1) (SCOR) ----> wire to 7V (2xVCC)
+ Pin16 PortB.0 ----> ModeSelectBit0 (0=GND, 1=3.5V)
+ Pin17 PortB.1 ----> ModeSelectBit1 (0=GND, 1=3.5V)
+ Mode0: Jump to RAM Address 0040h (useless when RAM is empty)
+ Mode1: Semifunctional Selftest (useless)
+ Mode2: Upload 200h bytes to RAM & jump to 0040h (allows fast/custom dumping)
+ Mode3: Download ROM as ASCII hexdump (nice, but very slow)
+ Pin50 PortF.0 ----> TX output (11bytes: 0Dh,0Ah," AAAA DD ")
+ Pin51 PortF.1 <---- RX input (1byte: "!" to request next 11 bytes)
+ Pin52 PortF.2 ----> RTS output or so (not needed)
+ Pin1 PortF.3 ----> DTR output or so (not needed)
+ Ground ------------ GND for RX/TX
+This mode is very simple and powerful: After /RESET, you send 200h bytes to the
+RX input (without any response on TX output), the bytes are stored at
+0040h..023Fh in RAM, and the chip jumps to 0040h after transferring the last
+byte. The uploaded program can contain a custum highspeed dumping function, or
+perform hardware tests, etc. A custom dumping function for PSX/PSone can be
+found at:
+
http://www.psxdev.net/forum/viewtopic.php?f=70&t=557
+ .------------ pin31, PC7, SCOR, cut the connection
+ 39 | 27 to Signal Processor,
+ .-----------------. then wire Pin31 to 7.5V
+ 40 | | 26
+ | C nnnn |
+ | SC4309nnPB |
+ | G63C 185 |
+ pin50, TX <--- | | ---- pin17, PB1, SCEX, wire to 3.5V,
+ pin51, RX ---> | | for Mode2 Selection
+ 52 | O | 14
+ '-----------------'
+ 1 13
+ CN602.Pin1 = 7.5V ;\on PSX boards (with either 5pin or
+ CN602.Pin3 = 3.5V ;/ 7pin CN602 connectors)
+ IC601.Pin1 = 7.5V ;-on PSone boards (3pin 78M05 voltage regulator)
+ IC102.Pin32 = 3.5V ;-on PSone boards (32pin Main BIOS ROM chip)
+ CXD2510Q.Pin63 (eg. on PU-8 boards) ;\
+ CXD2545Q.Pin74 (eg. on PU-18 boards) ; either one of these, depending
+ CXD1817R.Pin49 (eg. on PU-20 boards) ; on which chipset you have
+ CXD2938Q.Pin77 (eg. on PM-41 boards) ;
+ CXD2941R.Pin85 (eg. PM-41(2) boards) ;/
+This mode is very slow and not too powerful. But it may useful if you can't get
+Mode2 working for whatever reason. Wiring for Mode3 is same as above, plus
+PortB.0=3.5V. In this mode, the chip will send one 0Dh,0Ah," AAAA DD " string
+immediately after /RESET (with 16bit address "AAAA" (initially 1000h), and 8bit
+data "DD"). Thereafter the chip will wait for incoming commands:
+
4-digit ASCII HEX address --> change address, and return 0Dh,0Ah," AAAA DD "
+ chr(00h) --> increment address, and return 0Dh,0Ah," AAAA DD "
+ chr(07h) --> jump to current address (not so useful)
+ other characters --> same as chr(00h)
+ All digits/characters sent to RX input will produce an echo on TX output.
+And for anyone else planning to try this, these are the connections:
+
Pin PortC
+ 46 PC7/IRQ1 (SCOR) disconnect from PCB, then wire the pin to Vtst (7.6V)
+ 45 PC6/IRQ2 (/XINT) wire to Vdd (3.5V) (you have to solder to the pin)
+ Pin PortA DDRA Usage
+ 23 PA0 in RXD
+ 24 PA1 out TXD
+ 25 PA2 in -
+ 26 PA3 in Testmode.bit0 (GND=0, 3.5V=1)
+ 27 PA4 in Testmode.bit1 (GND=0, 3.5V=1)
+ 28 PA5 in Testmode.bit2 (GND=0, 3.5V=1)
+ 29 PA6 out RTS (don't care)
+ 30 PA7 out -
+ PA5 PA4 PA3 Effect
+ 0 x x Jump to 0040h ;\
+ 1 0 0 Test (complex) ; not so useful
+ 1 0 1 Test (simple loop) ;/
+ 1 1 0 ROM Dump 4200h bytes (plain binary, non-ASCII)
+ 1 1 1 RAM Upload 100h bytes to 0040h..013Fh, then jump to 0040h
+ .------------ pin46, PC7/IRQ1, SCOR, cut & wire to 7.5V
+ |.----------- pin45, PC6/IRQ2, wire to 3.5V
+ 60 || 41
+ .-----------------.
+ 61 | o | 40
+ | Sony Computer | ,----- pin28, PA5, wire to 3.5V
+ | Entertainment | _________/ ,--- pin27, PA4, wire to 3.5V
+ | Inc. (C) E35D | ==========='---- pin26, PA3, mode select
+ | 4246xx 185 | ----> pin24, PA1, TXD (for ROM dump)
+ | | <---- pin23, PA0, RXD (for RAM upload)
+ 80 | O | 21
+ '-----------------'
+ 1 20
+ CN602.Pin1 = 7.5V ;\on PSX boards (with 7pin CN602 connectors)
+ CN602.Pin3 = 3.5V ;/
+DTL-H100x uses 80pin chip with onchip PROM (chip text "(M) MC68HC705L15",
+instead of "Sony [...] 4246xx"), wiring for serial dumping on that is unknown
+(the bootstrap ROM may be a little different because it should contain PROM
+burning functions). PU-9 boards boards seem to use a similar PROM (with some
+sticker on it).
+DTL-H2000 uses 80pin CXP82300 chip with socketed piggyback 32pin EPROM - that
+chip is a Sony SPC700 CPU, not a Motorola HC05 CPU. Accordingly there's no
+Motorola Bootstrap mode in it, but of course one can simply dump the EPROM with
+standard eprom utilities, as done by TriMesh).
0-1 "L" Reserved (should be 0)
+ 2 LSB 1st CD DSP DATA order (0=MSB first, 1=LSB first)
+ 3-4 BCK MD CD DSP Number of BCLKs per WCLK (0=16, 1=24, 2=32, 3=Reserved)
+ 5 BCK RED Strobe DATA on BLCK Edge (0=Falling Edge, 1=Rising Edge)
+ 6 LCH LOW Channel on LRCK=Low (0=Right, 1=Left)
+ 7 C2PL1st ... C2PO lower byte 1st
+ 0 HCLKDIS HCLK Pin Output (0=8.4672MHz, 1=Disable; Fixed Low)
+ 1 CLKDIS CLK Pin Output (0=16.9344MHz, 1=Disable; Fixed Low)
+ 2 9BITRAM SRAM Databus width (0=8bit/normal, 1=9bit)
+ 3-4 RAM SZ SRMA Address bus (0=32K, 1=64K, 2=128K, 3=Reserved)
+ 5 PRTYCTL ... Priority Control
+ 6 XSLOW Number of clock cycles per DMA cycle (0=12, 1=4) (for SRAM)
+ 7 "L" Reserved (should be 0)
+ 0 "L" Reserved (should be 0)
+ 1 DACODIS .... DAC Out Disable
+ 2 DAMIXEN Digital Audio Mixer Enable (0=Attentuator/Mixer for CD-DA, 1=No)
+ 3 SMBF2 Number of Sound Map Buffer Surfaces (0=Three, 1=Two)
+ 4 SPMCTL Sound Parameter Majority Control (0=?) ;\for ADPCM params
+ 5 SPECTL Sound Parameter Error Control (0=?) ;/
+ 6-7 "L" Reserved (should be 0)
+ 0-2 DECMD Decoder Mode (0-7)
+ 0 or 1 Decoder Disable ;-disable sector reading
+ 2 or 3 Monitor-only Mode ;\no error correction
+ 4 Write-only Mode ;/
+ 5 Real-time Correction Mode ;\with error correction
+ 6 Repeat Correction Mode ;/
+ 7 CD-DA Mode ;-audio
+ 3 AUTODIST Auto Distinction (0=Use MODESEL/FORMSEL bits, 1=Use Sector Hdr)
+ (Error Correction is done according to above MODE/FORM values)
+ 4 FORMSEL Form Select (0=FORM1, 1=FORM2) (must be 0 for MODE1)
+ 5 MODESEL Mode Select (0=MODE1, 1=MODE2)
+ 6 ECCSTR ECC Strategy (0=Normal, 1=Use Error Flags; requires 9bit SRAM)
+ 7 ENDLADR Enable Drive Last Address ...
+ 0 "L" Reserved (should be 0)
+ 1 DBLSPD Double Speed Mode (0=Normal, 1=Double) (init CD DSP first)
+ 2 RPSTART Repeat Correction Start (0=No, 1=Start) (automatically cleared)
+ 3 SWOPEN Sync Window Open (0=SyncControlledByIC, 1=OpenDetectionWindow)
+ 4 CD-DA CD-DA Play (0=No, 1=Playback CD-DA as audio)
+ 5 CDDAMUTE CD-DA Mute (0=Normal, 1=Mute CD-DA Audio)
+ 6 RTMUTE Real-time Mute (0=Normal, 1=Mute CDROM ADPCM)
+ 7 SMMUTE Sound Map Mute (0=Normal, 1=Mute Sound Map ADPCM)
+ 0 CFORM FORM assumed by Error Correction (0=FORM1, 1=FORM2)
+ 1 CMODE MODE assumed by Error Correction (0=MODE1, 1=MODE2)
+ 2 ECCOK ECC Okay (0=Bad, 1=Okay)
+ 3 EDCOK EDC Okay (0=Bad, 1=Okay)
+ 4 CORDONE Correction Done (0=None, 1=Error occurred and was corrected)
+ 5 CORINH Correction Inhibit (0=Okay,1=AUTODIST couldn't determine MODE/FORM)
+ 6 ERINBLK Erasure in Block (0=Okay, 1=At least 1 byte is wrong & uncorrected)
+ 7 EDCALL0 EDC all-zero (0=No/EDC Exists, 1=Yes/All four EDC bytes are 00h)
+ 0 NOSYNC No Sync (0=Okay, 1=Sector Sync Mark Missing)
+ 1 SHRTSCT Short Sector (0=Okay, 1=Sector Sync Mark within Sector Data)
+ 2-4 - Reserved (undefined)
+ 5 RTADPBSY Real-time ADPCM Busy (0=No, 1=Busy/playback)
+ 6-7 - Reserved (undefined)
+ 0 CI Error in 4th Subheader byte (Coding Info) (0=Okay, 1=Error)
+ 1 SUBMODE Error in 3rd Subheader byte (Submode) (0=Okay, 1=Error)
+ 2 CHANNEL Error in 2nd Subheader byte (Channel) (0=Okay, 1=Error)
+ 3 FILE Error in 1st Subheader byte (File) (0=Okay, 1=Error)
+ 4 MODE Error in 4th Header byte (MODE) (0=Okay, 1=Error)
+ 5 BLOCK Error in 3rd Header byte (FF) (0=Okay, 1=Error)
+ 6 SEC Error in 2nd Header byte (SS) (0=Okay, 1=Error)
+ 7 MIN Error in 1st Header byte (MM) (0=Okay, 1=Error)
+ 1st read: 1st Header byte (MM)
+ 2nd read: 2nd Header byte (SS)
+ 3rd read: 3rd Header byte (FF)
+ 4th read: 4th Header byte (MODE)
+ 1st read: 1st Subheader byte (File)
+ 2nd read: 2nd Subheader byte (Channel)
+ 3rd read: 3rd Subheader byte (Submode) (SM)
+ 4th read: 4th Subheader byte (Coding Info) (CI)
+ (1) The corrected value in the real-time correction or
+ repeat correction mode
+ (2) Value of the raw data from the drive in the monitor-only
+ or write-only mode
+ The CMOME? and CMODE bits (bits 1, 0) of ECCSTS indicate the FORM and MODE
+ of the sector the decoder has discriminated by the raw data from the drive.
+ Due to erroneous correction, the values of these bits may be at variance
+ with those of the HDR register MODE byte and SHDR register submode byte
+ bit5.
+Unknown when 1st..4th read indices are reset for HDR and SHDR (maybe on access
+to certain I/O ports, or maybe anytime when receiving a new sector), also
+unknown what happens on 5th read and up.
Drive Address -- used for storing incoming CDROM sectors in Buffer RAM
+Host Address -- used for transferring Buffer RAM to (or from) Main CPU
+ADPCM Address -- used for Real-time ADPCM audio output from Buffer RAM
0-6 CMADR Address bit10-16 (in 1Kbyte steps)
+ 7 - Reserved (undefined)
+ HADR = (CMADR AND 7Fh)*400h+offset
+ HXFR = length OR 4000h
+ ADPMNT = (CMADR AND 7Fh) OR 80h
+ 0-6 ADPxxx ADPCM source Address bit10-16 (in 1Kbyte-steps)
+ 7 RTADPEN Real-time ADPCM Enable (0=Disable, 1=Enable Real-time ADPCM)
+ 0-16 DLADR Addr. bit0-16 ...
+ 17-23 "L" Reserved (should be 0)
+ 0-16 DADRC Incrementing Drive-to-Buffer Write Address, bit0-16
+ 17-23 "L" Reserved (should be 0)
+ 0-15 DADRC Address bit0-15 ;bit16 is in Port 0Bh ...
+ 0-11 HXFR number of data bytes, bit0-11 (0..FFFh) ...
+ 12 HADR.16 HADR bit16
+ 13 "L" Reserved (should be 0)
+ 14 "L" ?? Reserved (should be 0) ;<-- XXX but on PSX: Always 1 !?!
+ ; seems to Disable INT8 ?!!!
+ 15 DISHXFRC Disable HXFRC (0=Use HXFRC, 1=Disable, Infinite-or-Zero Len?)
+ 0-15 HADR Addr. bit0-15 ;bit16 in Port 0Dh ...
+ 0-11 HXFRC Host Transfer Counter bit0-11 (number of remaining bytes)
+ 12 HADRC bit16 ;MSB of Port 0Ch/0Dh
+ 13 DADRC bit16 ;MSB of Port 0Eh/0Fh
+ 14-15 - Reserved (undefined) (usually both bits set)
+ 0-15 HADRC Address bit0-15 ;bit16 is in Port 0Bh
+When reading from SRAM, data seems to go through a 8-byte data fifo, the HXFRC
+(remain) and HADRC (addr) values aren't aware of that FIFO (ie. if there's data
+in the fifo, then addr will be 8 bigger and remain 8 smaller than what has
+arrived at the host).
"If sound map data is to be transferred before the data is transferred
+(immediately after the host has set the BFRD and BFWR bits (bits 7 and 6) of
+the HCHPCTL register high)":
+
900h is loaded into HXFRC
+ and 600Ch, 6A0Ch, or 740Ch is loaded into HADRC
+ (at least, supposedly, above addresses , for cases when using 32K SRAM)
+ HADR and HXFR are loaded into HADRC and HXFRC
+ 0000h 1st Sector (at 0000h..0923h) (unused gap at 0924h..0BFFh)
+ 0C00h 2nd Sector (at 0C00h..1523h) (unused gap at 1524h..17FFh)
+ 1800h 3rd Sector (at 1800h..2123h) (unused gap at 2124h..23FFh)
+ 2400h 4th Sector (at 2400h..2D23h) (unused gap at 2D24h..2FFFh)
+ 3000h 5th Sector (at 3000h..3923h) (unused gap at 3924h..3BFFh)
+ 3C00h 6th Sector (at 3C00h..4523h) (unused gap at 4524h..47FFh)
+ 4800h 7th Sector (at 4800h..5123h) (unused gap at 5124h..53FFh)
+ 5400h 8th Sector (at 5400h..5D23h) (unused gap at 5D24h..5FFFh)
+ 6000h Soundmap ADPCM Buffer (at 600Ch..690Bh) (gaps at 6000h and 690Ch)
+ 6A00h Soundmap ADPCM Buffer (at 6A0Ch..730Bh) (gaps at 6A00h and 730Ch)
+ 7400h Soundmap ADPCM Buffer (at 740Ch..7D0Bh) (gaps at 7400h and 7D0Ch)
+ 7E00h Unknown/Unused
+ 0-2 HINT Request Host Interrupt (INT1..INT7, or 0=None/No change)
+ 3-7 "L" Reserved (should be 0)
+ 0-2 HINTSTS Pending Host Interrupt (INT1..INT7, or 0=None/All acknowledged)
+ 3 DMABUSY DMA Busy (0=Data FIFO Empty and HXFRC=0, 1=Data Transfer Busy)
+ 4 PRMRRDY Parameter Read Ready (0=Parameter FIFO Empty, 1=Ready/Not Empty)
+ 5 RSLEMPT Result Empty (0=Response FIFO Not Empty, 1=Empty)
+ 6 RSLWRDY Result Write Ready (0=Response FIFO Full, 1=Ready/Not Full)
+ 7 BUSYSTS Command Busy Status (0=Command Not Empty, 1=Ack'ed by CLRBUSY)
+ 0 RESYNC Sync with CD DSP (0=No change, 1=Resync, eg. after speed change)
+ 1-3 "L" Reserved (should be 0)
+ 4 RTADPCLR Abort Real-time ADPCM (0=No Change, 1=Abort; when ADPMNT.7=0)
+ 5 CLRRSLT Clear Reply FIFO (0=No change, 1=Acknowledge; clear FIFO)
+ 6 CLRBUSY Acknowledge Command (0=No change, 1=Acknowledge; clear BUSYSTS)
+ 7 CHPRST Chip Reset (0=No change, 1=Do Chip Initialization)
+ 0 HCRISD Host Chip Reset Issued
+ 1 HSTCMND Host Command ...
+ 2 DECINT Decoder Interrupt ..
+ 3 HDMACMP Host DMA Complete . <-- PSX: used for retry ?!?!!!
+ 4 RTADPEND Real-time ADPCM end
+ 5 RSLTEMPT Result Empty
+ 6 DECTOUT Decoder Time Out
+ 7 DRVOVRN Drive Overrun
+ 0-7 Param FIFO (check HIFSTS.4 to see if the FIFO is empty)
+ 0-7 Command (check INTSTS.1 or HIFSTS.7 to see if a command was sent)
+ 0-7 Data (has 8-byte FIFO)
+ 0 S/M ADPCM Stereo/Mono (0=Mono, 1=Stereo)
+ 1 - Reserved (undefined)
+ 2 FS ADPCM Sampling Frequency (0=37.8kHz, 1=18.9kHz)
+ 3 - Reserved (undefined)
+ 4 BITLNGTH ADPCM Sample Bit Length (0=Normal/4bit, 1=8bit)
+ 5 ADPBUSY ADPCM Decoding (0=No, 1=Yes/Busy)
+ 6 EMPHASIS ADPCM Emphasis (0=Normal/Off, 1=On)
+ 7 MUTE DA Data is Muted (uh?) (0=No, 1=Yes/Muted)
+ 0 S/M ADPCM Stereo/Mono (0=Mono, 1=Stereo)
+ 1 "L" Reserved (should be 0)
+ 2 FS ADPCM Sampling Frequency (0=37.8kHz, 1=18.9kHz)
+ 3 "L" Reserved (should be 0)
+ 4 BITLNGTH ADPCM Sample Bit Length (0=Normal/4bit, 1=8bit)
+ 5 "L" Reserved (should be 0)
+ 6 EMPHASIS ADPCM Emphasis (0=Normal/Off, 1=On)
+ 7 "L" Reserved (should be 0)
+ 0-7 Reserved (undefined)
+ 0-7 Reserved (should be 00h) (or don't write at all)
+ 23-20 4bit Command (00h)
+ 19 1bit FS4 Focus Servo (0=Off, 1=On)
+ 18 1bit FS3 DEFECT
+ 17 1bit FS2 Enable Focus Search Voltage (0=Off, 1=On)
+ 16 1bit FS1 Select Focus Search Voltage (0=Falling, 1=Rising)
+ 15-0 16bit Unused (don't care)
+ 23-20 4bit Command (01h)
+ 19 1bit TG1,TG2 ON/OFF Tracking Servo Gain Up/Normal (hmmm?)
+ 18 1bit Brake Circuit ON/OFF
+ 17-16 2bit PS Sled Kick Height (0=+/-1, 1=+/-2, 2=Undoc, 3="Don't use"?)
+ 15-0 16bit Unused (don't care)
+ 23-20 4bit Command (02h)
+ 19-18 2bit Tracking Control (0=Off, 1=Servo On, 2=F-Jump, 3=R-Jump) ;TM1,3,4
+ 17-16 2bit Sled Control (0=Off, 1=Servo On, 2=F-Fast, 3=R-Fast) ;TM2,5,6
+ 15-0 16bit Unused (don't care)
+ 23-20 4bit Command (03h)
+ 19 1bit Value to be adjusted (0=Balance, 1=Gain)
+ 18-16 3bit New Balance or Gain value (depending on above bit)
+ 15-0 16bit Unused (don't care)
+ N-N 4bit Command (04h..07h)
+ N-N 4bit Command (08h..0Fh)
+The Servo Amplifier isn't directly connected to the CPU. Instead, it's
+connected as a slave device to the Signal Processor. There are two ways to
+access the Servo Amplifier:
+1) The CPU can send CX(0X..3X) commands to the Signal Processor (which will
+then forward them to the Servo Amplifier).
+2) The Signal Processor can send CX(0X..3X) commands to the Servo Amplifier
+(this happens during CX(4xxx) Auto Sequence command).
23-20 4bit Command (4)
+ 19-16 4bit AS3-0 Auto Sequence Command (see below)
+ 15-12 4bit MT3-0 Max Timer Value (N timer units, or 0=Invalidate Timer)
+ 11 1bit LSSL Timer Units (0=2.9ms, 1=186ms) (for above MT value)
+ 10-8 3bit Unused (zero)
+ 7-0 8bit Unused (don't care)
+ 00h Cancel
+ 04h/05h Forward/Reverse Fine Search ;<--sends CX(25h) ;\these do internally
+ 07h Focus-On ;<--sends CX(02h) ; send commands to
+ 08h/09h Forward/Reverse 1 Track Jump ;\ ; CXA1782BR
+ 0Ah/0Bh Forward/Reverse 10 Track Jump ; sends CX(25h) ; and, auto sequence
+ 0Ch/0Dh Forward/Reverse 2N Track Jump ;/ ;/is interrupted?
+ 0Eh/0Fh Forward/Reverse 1N Track Move ;<--CXD2545Q only(Reserved on CXD2510Q)
+ 01h..03h,06h = Reserved
+ 23-20 4bit Command (5)
+ 19-16 4bit TR3-0 Timer (N*0.022ms for Blind/Overflow, N*0.045ms for Brake)
+ 15-8 8bit Unused (don't care on CXD2510Q, zero on CXD2545Q)
+ 7-0 8bit Unused (don't care)
+ 23-20 4bit Command (6)
+ 19-16 4bit SD3-0 Timer KICK.D (N*2.9ms for Fine Search? else N*1.45ms?)
+ 15-12 4bit KF3-0 Timer KICK.F (N*0.09ms)
+ 11-8 4bit Unused (don't care on CXD2510Q, zero on CXD2545Q)
+ 7-0 8bit Unused (don't care)
+ 23-20 4bit Command (7)
+ 19-4 16bit Track Jump Count Setting (0..65535) for Command 4x
+ 3-0 4bit Unused (don't care)
+ 23-20 4bit Command (8)
+ 19 1bit CDROM (0=Audio, 1=CDROM; no average and pre-value stuff)
+ 18 1bit DOUT Mute (0=Not muted, 1=Mute DOUT)
+ 17 1bit D.out Mute-F (0=Not muted, 1=Mute DA)
+ 16 1bit WSEL (0=Enhanced Sync Window, 1=Enhanced Anti-Rolling)
+ 15 1bit VCO SEL (0=Double Correction, 1=Quadruple Correction)
+ 14 1bit ASHS (0=Double Correction, 1=Quadruple Correction)
+ 13 1bit SOCT (0=Output SubQ to SQSO, 1=Output Each? to SQSO)
+ 12 1bit Unused (zero)
+ 11-8 4bit Unused (don't care on CXD2510Q, zero on CXD2545Q)
+ 7-0 8bit Unused (don't care)
+ 23-20 4bit Command (9)
+ 19 1bit DCLV ON-OFF (complex stuff, related to gain and frequencies)
+ 18 1bit DSPB ON-OFF (0=Normal Speed, 1=Double Speed; fixed pitch)
+ 17 1bit ASEQ ON-OFF (select output on SENS pin)
+ 16 1bit DPLL ON-OFF (0=Analog RFPLL, 1=Digital RFPLL)
+ 15-14 1bit Bilingual Audio (0=Stereo, 1=RightOnly, 2=LeftOnly, 3=Mute)
+ 13 1bit FLFC (normally 0)
+ 12 1bit Unused (zero)
+ 11-8 4bit Unused (don't care on CXD2510Q, zero on CXD2545Q)
+ 7-0 8bit Unused (don't care)
+ 23-20 4bit Command (0Ah)
+ 19 1bit Vari Up (write 1-then-0 to increase pitch by +0.1%)
+ 18 1bit Vari Down (write 1-then-0 to decrease pitch by -0.1%)
+ 17 1bit Mute (0=Not muted; unless muted elsewhere, 1=Mute & Peak=0)
+ 16 1bit ATT (0=Attentuation off, 1=Minus 12 dB)
+ 15-14 2bit PCT (0=Normal, 1=LevelMeter, 2=PeakMeter, 3=Normal) (0-1=QuadC2)
+ 13-12 2bit Unused (zero)
+ 11-8 4bit Unused (don't care on CXD2510Q, zero on CXD2545Q)
+ 7-0 8bit Unused (don't care)
+ 23-20 4bit Command (0Bh)
+ 19-4 16bit Traverse Monitor Count (used when monitored by COMP and COUT) (?)
+ 3-0 4bit Unused (don't care)
+ 23-20 4bit Command (0Ch)
+ 19-18 2bit Gain MDP for CLVP mode (0=-6db, 1=0dB, 1=+6dB, 3=Reserved)
+ 17-16 2bit Gain MDS for CLVS/CLVP (0=-12dB, 1=-6dB, 2=0dB, 3=Reserved)
+ 15 1bit Zero (zero)
+ 14 1bit Gain DCLV0 overall gain (0=0dB, 1=+6dB
+ 13-12 2bit Unused (zero)
+ 11-8 4bit Unused (don't care on CXD2510Q, zero on CXD2545Q)
+ 7-0 8bit Unused (don't care)
+ 23-20 4bit Command (0Dh)
+ 19 1bit DCLV PWM MD Digital CLV PWM mode (0=Use MDS+MDP, 1=Ternary MDP)
+ 18 1bit TB Bottom Hold in CLVS/CLVH modes (0=At cycle RFCK/32, 1=RFCK/16)
+ 17 1bit TP Peak Hold in CLVS mode (0=At cycle RFCK/4, 1=RFCK/2)
+ 16 1bit Gain CLVS for CLVS mode (0=0dB, 1=+6dB)(always +6dB in CLVP mode)
+ 15-8 8bit Unused (don't care on CXD2510Q, zero on CXD2545Q)
+ 7-0 8bit Unused (don't care)
+ 23-20 4bit Command (0Eh)
+ 19-16 4bit CM3-0
+ 15-8 8bit Unused (don't care on CXD2510Q, zero on CXD2545Q)
+ 7-0 8bit Unused (don't care)
+ 00h Stop Spindle Motor Stop mode
+ 06h CLVA Automatic CLVS/CLVP switching mode, normally used for playback
+ 08h Kick Spindle Motor Forward rotation mode
+ 0Ah Brake Spindle Motor Reverse rotation mode
+ 0Ch CLVH Peak hold at 34kHz
+ 0Eh CLVS Rough Servo Mode, RF-PLL related
+ 0Fh CLVP PLL Servo mode
+ 23-0 N/A Don't use
+ 80bit subq
+ 15bit peak level (lsb first) (absolute/unsigned value)
+ 1bit peak l/r flag (aka appears as "MSB" of peak level)
+ Index ASEQ=0 ASEQ=1 ;<-- ASEQ can be set via CX(9xx)
+ 0X HighZ SEIN (FZC) ;\aka SENS output
+ 1X HighZ SEIN (A.S) ... aka DEFECT ; from CXA1782BR
+ 2X HighZ SEIN (T.Z.C) ... aka TZC ; forwarded through
+ 3X HighZ SEIN (SSTOP) ... aka Gain/Bal ;/CXD2510Q
+ 4X HighZ XBUSY
+ 5X HighZ FOK
+ 6X HighZ SEIN (HighZ)
+ AX GFS GFS
+ BX COMP COMP
+ CX COUT COUT
+ EX /OV64 /OV64
+ 7X-9X,DX,FX HighZ 0
+ FZC Focus Zero Cross
+ DEFECT Defect?
+ TZC Tracking Zero Cross
+ SSTOP Gain or Balance adjust reached wanted level
+ XBUSY Low while the auto sequencer operation is busy
+ FOK High for "focus OK" (same as FOK pin)
+ GFS High when the played back frame sync is obtained with correct timing
+ COMP Measures the number of tracks set with Reg B. High when Reg B is
+ latched, low when the initial Reg B number is input by CNIN
+ COUT Measures the number of tracks set with Reg B. High when Reg B is
+ latched, toggles each time the Reg B number is input by CNIN. While
+ $44 and $45 are being executed, toggles with each CNIN 8-count
+ instead of the Reg B number
+ OV64 Low when filtered EFM signal is lengthened by 64 channel clock
+ pulses or more
+CDROM Internal Commands CX(0x..3x) - CXA1782BR Servo Amplifier
CDROM Internal Commands CX(4x..Ex) - CXD2510Q Signal Processor
+One small difference is that the CXD2545Q supports a new "M Track Move"
+function as part of the CX(4xxx) command. And, some "don't care" bits are now
+reserved (ie. some commands need to be padded with additional leading "0"
+bits).
23-20 4bit Command (01h)
+ 19 1bit Anti Shock (0=Off, 1=On)
+ 18 1bit Brake (0=Off, 1=On)
+ 17 1bit Tracking Gain (0=Normal, 1=Up)
+ 16 1bit Tracking Gain Filter (0=Select 1, 1=Select 2)
+ 15-0 16bit Unused (don't care)
+ 23-20 4bit Command (03h)
+ 19-18 2bit Subcommand (0)
+ 17-16 2bit Sled Kick Level (0=+/-1, 1=+/-2, 2=+/-3, 3=+/-4)
+ 15-0 16bit Unused (don't care)
+ 23-16 8bit Command (34h)
+ 15 1bit Zero (0)
+ 14-8 7bit Address (00h..4Fh = Select Coefficient K00..K4F)
+ 7-0 8bit Data (00h..FFh = New value)
+ PLUS 8bit Eight more bits on PSone (!)
+ 23-12 12bit Command (34Fh)
+ 11-10 2bit Index (0=TRVSC, 1=FBIAS, 2=?, 3=?)
+ 9-0 10bit Data (for FBIAS: bit0=don't care)
+ 23-16 8bit Command (35h)
+ 15-14 2bit FT Focus Search-up speed 1
+ 13-8 6bit FS Focus Search limit voltage (default 011000b) (+/-1.875V)
+ 7 1bit FTZ Focus Search-up speed 2
+ 6-0 7bit FG AGF Convergence Gain Setting (default 0101101b)
+ 23-16 8bit Command (36h)
+ 15 1bit Zero (0)
+ 14 1bit DTZC DTZC Delay (0=4.25us/Default, 1=8.5us)
+ 13-8 6bit TJ Track Jump voltage (default 001110b) (+/-1.09V)
+ 7 1bit Zero (0)
+ 6-0 7bit TG AGT Convergence Gain Setting (default 0101110b)
+ 23-16 8bit Command (37h)
+ 15-14 2bit FZS XXX pg. 84
+ 13-8 6bit SM Sled Move Voltage
+ 7 1bit AGS
+ 6 1bit AGJ
+ 5 1bit AGGF
+ 4 1bit AGGT
+ 3 1bit AGV1
+ 2 1bit AGV2
+ 1 1bit AGHS
+ 0 1bit AGHT
+ 23-16 8bit Command (38h)
+ 15 1bit VCLM VC level measurement on/off
+ 14 1bit VCLC VC level compensation for FCS_In Register on/off
+ 13 1bit FLM Focus zero level measurement on/off
+ 12 1bit FLC0 Focus zero level compensation for FZC Register on/off
+ 11 1bit RFLM RF zero level measurement on/off
+ 10 1bit RFLC RF zero level compensation on/off
+ 9 1bit AGF Focus automatic gain adjustment on/off
+ 8 1bit AGT Tracking automatic gain adjustment on/off
+ 7 1bit DFSW Defect switch disable (1=disable defect measurement)
+ 6 1bit LKSW Lock switch (1=disable sled free-running prevention)
+ 5 1bit TBLM Traverse center measurement on/off
+ 4 1bit TCLM Tracking zero level measurement on/off
+ 3 1bit FLC1 Focus zero level compensation for FCS_In Register on/off
+ 2 1bit TLC2 Traverse center compensation on/off
+ 1 1bit TLC1 Tracking zero level compensation on/off
+ 0 1bit TLC0 VC level compensation for TRK/SLD_In register on/off
+ 23-16 8bit Command (39h)
+ 15 1bit DAC Serial data readout DAC mode on/off
+ 14-8 7bit SD Serial readout data select (see below)
+ 7-0 8bit Unused (don't care)
+ Addr Data Content
+ 00h 8bit VC input signal
+ 01h 8bit SE input signal
+ 02h 8bit TE input signal
+ 03h 8bit FE input signal
+ 04h-07h 9bit TE AVRG register (mirrored to 04h-07h)
+ 08h-0Bh 9bit FE AVRG register (mirrored to 08h-0Bh)
+ 0Ch-0Fh 9bit VC AVRG register (mirrored to 0Ch-0Fh)
+ 12h 8bit RFDC envelope (peak)
+ 13h 8bit RFDC envelope (bottom)
+ 1Ch 9bit TRVSC register
+ 1Dh 9bit FBIAS register
+ 1Eh 8bit RFDC input signal
+ 1Fh 8bit RF AVRG register
+ 20h-3Fh 16bit Data RAM (M00-M1F)
+ 40h-7Fh 8bit Coefficient RAM (K00-K3F) (note: K40-K4F cannot be read out)
+ 23-16 8bit Command (3Ah)
+ 15 1bit Zero (0)
+ 14 1bit FBON: FBIAS register addition (0=off, 1=Add FBIAS to FCS)
+ 13-0 14bit Zero (0)
+ 23-16 8bit Command (3Bh)
+ 15-14 2bit SFO FOK Slice Level (...depends on SFOX)
+ 13-12 2bit SDF DFCT Slice Level (0=89mV, 1=134mV, 2=179mV, 3=224mV)
+ 11-10 2bit MAX DFCT Maximum Time (0=No Limit, 1=2ms, 2=2.36ms, 3=2.72ms)
+ 9 1bit SFOX FOK Slice Level (...depends on SFO)
+ 8 1bit BTF Bottom Hold Double-Speed Count-Up mode for MIRR (0=off)
+ 7-6 2bit D2V Peak Hold 2 for DFCT (0=22.05kHz, 1=44.1, 2=88.2, 3=176.4)
+ 5-4 2bit D1V Peak Hold 1 for DFCT (0=176.4kHz, 1=352.8, 2=705.6, 3=1411)
+ 3-0 4bit Zero (0)
+ 23-16 8bit Command (3Ch)
+ 15-0 16bit Unused (don't care)
+ 23-16 8bit Command (3Dh)
+ 15-0 16bit Unused (don't care)
+ 23-16 8bit Command (3Eh)
+ 15-14 2bit F1NDM FCS servo filter 1st stage (1=normal, 2=down)
+ 13-12 2bit F3NUM FCS servo filter 3rd stage (1=normal, 2=up)
+ 11-10 2bit T1NDM TRK servo filter 1st stage (1=normal, 2=down)
+ 9-8 2bit T3NUM TRK servo filter 3rd stage (1=normal, 2=up)
+ 7 1bit DFIS FCS hold filter input extraction node (0=M05, 1=M04)
+ 6 1bit TLCD Mask TLC2 set by D2 of CX(38) only when FOK low
+ 5 1bit RFLP Pass signal from RFDC pin through low-pass-filter
+ 4-0 5bit Zero (0)
+ 23-16 8bit Command (3Fh) ... XXX pg. 89
+ 15-14 2bit Unused (0)
+ 13-12 2bit XTD
+ 11 1bit Unused (0)
+ 10-8 3bit DRR
+ 7 1bit Unused (0)
+ 6 1bit ASFG
+ 5 1bit Unused (0)
+ 4 1bit LPAS
+ 3-2 2bit SRO
+ 1-0 2bit Unused (0)
+XXX
Index ASEQ=0 ASEQ=1 Length
+ $0X Z FZC -
+ $1X Z AS -
+ $2X Z TZC -
+ $38 Z AGOK*1 -
+ $38 Z XAVEBSY*1 -
+ $30-37,$3A-3F Z SSTP -
+ $3904 Z TE Avrg Reg. 9 bit
+ $3908 Z FE Avrg Reg. 9 bit
+ $390C Z VC Avrg Reg. 9 bit
+ $391C Z TRVSC Reg. 9 bit
+ $391D Z FB Reg. 9 bit
+ $391F Z RFDC Avrg Reg. 8 bit
+ $4X Z XBUSY -
+ $5X Z FOK -
+ $6X Z 0 -
+ $AX GFS GFS -
+ $BX COMP COMP -
+ $CX COUT COUT -
+ $EX OV64 OV64 -
+ $7X-9X,DX,FX Z 0 -
+Most commands are same as on CXD2545Q. New/changed commands are:
Older PSX consoles have received the "SCEx" string at 250 baud via HC05
+PortB.bit1, which allowed modchips to injected faked "SCEx" signals to that
+pin. To prevent that, the CXD2938Q contains some new 32bit commands that allow
+to receive somewhat encrypted "SCEx" strings via SPI bus. The used commands
+are:
+
CX(34910000) NewScexStopReading
+ CX(3491xy80) NewScexRandomKey(xy)
+ CX(34920000) NewScexFlushResyncOrSo
+ CX(34944A00) NewScexInitValue1
+ CX(3498C000) NewScexInitValue2
+ CX(349C1000) NewScexThis ;\inverse ;\use CX(3C2080) for COUT selection
+ CX(349D1000) NewScexThat ;/of COUT ;/
+ 1st byte: Unknown/unused (normally ADR/Control) ;\these should be probably
+ 2nd byte: Unknown/unused (normally Track) ; set to some invalid values
+ 3rd byte: Unknown/unused (normally Index/Point) ;/to avoid SUB-Q confusion
+ 4th..10th byte: SCEx data or Dummy bytes (depending on xy.bit7..1)
+ 11th..12th byte: Unknown/unused (normally Audio Peak level)
+Same as in older version, but initialized slightly differently: CXD2545Q used
+CX(3B2250) whilst CXD2938Q is using CX(3B7250).
The CXD2545Q used two 8bit commands, CX(3C) and CX(3D), for TzcOut selection,
+which are now replaced by a single 24bit command, CX(3Cxxxx), and which do
+include a new mode related to New SCEx.
+
CXD2545Q CXD2938Q
+ CX(3C) CX(3C0080) TzcCoutSelectHPTZC;\ <--formerly CX(3C)
+ - CX(3C2080) TzcCoutSelectSCEX ; <--special NewScex mode
+ CX(3D) CX(3C4080) TzcCoutSelectDTZC ;/ <--formerly CX(3D)
+Command CX(8xx) has been 12bit wide on CXD2545Q, and is now expanded 24bit
+width (with some changed/unknown bits).
+
CXD2545Q CXD2938Q
+ CX(8180) CX(810408) MODE = Audio (CD-DA)
+ CX(8120) CX(812400) MODE = Audio (CD-DA) (manual SPI bus access)
+ CX(8980) CX(890408) MODE = CDROM (Data)
+ - CX(898000) MODE = CDROM (Data) (used on RESET)
+Command CX(9xx) has been 12bit wide on CXD2545Q (with bit12=reserved/zero), and
+is now expanded 24bit width (with bit12=unknown/one and bit11-0=unknown/zero).
Commands CX(Dx) and CX(Ex) have been 8bit wide on CXD2545Q, and are now
+zeropadded to 24bit width, ie. CX(Dx0000) and CX(Ex0000). Unknown if the extra
+bits are hiding any extra features. In practice, the CDROM BIOS is always
+setting them zero (except in some test commands which are accidently still
+using the old 8bit form, resulting in garbage in lower 16bits).
Commands are sent serially LSB first via DATA,CLOK,XLAT pins: DATA+CLOK are
+used to send commands to the chip, command execution is then applied by
+dragging XLAT low for a moment.
+Commands can be up to 24bits in length, but unused LSBs (the "don't care" bits)
+can be omitted; the PSX BIOS clips the length to 8bit/16bit where possible (due
+to the LSB-first transfer order, the chip does treat the most recently
+transferred bit as MSB=bit23, and there's no need to transfer the LSBs if they
+aren't used).
+Aside from being used as command number, the four most recently transferred
+bits are also used to select SENS status feedback (for the SENS selection it
+doesn't matter if the four bits were terminated by XLAT or not).
The Sled motor moves the drive head to the current read position. On a Compact
+Disc, the term "Track" does normally refer to Audio tracks (songs). But the
+drive hardware uses the terms "Track" and "Tracking" for different purposes:
+Tracking appears to refer to moving the Optics via magnets (ie. moving only the
+laser/lens, without actually moving the whole sled) (this is done for fine
+adjustments, and it seems to happen more or less automatically; emulators can
+just return increasing sectors without needing to handle special tracking
+commands).
+Track jumps refer to moving the entire Sled, one "track" is equal to one spiral
+winding (1.6 micrometers). One winding contains between 9 sectors on innermost
+windings, and 22.5 sectors on outermost windings (the PSX cdrom bios is
+translating the sector-distance to non-linear track-distance, and emulators
+must undo that translation; otherwise the sled doesn't arrive at the intended
+location; the cdrom bios will retry seeking a couple of times and eventually
+settle down at the desired location - but it will timeout if the sled emulation
+is too inaccurate).
+The PSX hardware uses two mechanisms for moving the Sled:
+Command CX(4xxx) Forward/Reverse Track Jump: allows to move the sled by
+1..131070 tracks (ie. max 210 millimeters), and the hardware does stop
+automatically after reaching the desired distance.
+Command CX(2x) Forward/Reverse Fast Sled: moves the sled continously until it
+gets stopped by another command (in this mode, software can watch the COUT
+signal, which gets toggled each "N" tracks; whereas "N" can be selected via
+Command CX(Bxxxx), which is configured to N=100h in PSX).
+The PSX cdrom bios is issuing another Fast Sled command (in opposite direction)
+after Fast Sled commands, emulators must somehow interprete this as "sled
+slowdown" (rather than as actually moving the sled in opposite direction, which
+could move the sled miles away from the target). For some reason vC1 BIOS is
+using a relative short slowdown period, whilst vC2/vC3 are using much longer
+slowdown periods (probably related to different SledKickHeight aka
+SledKickLevel settings and/or to different Sled Move Voltage settings).
The hardware includes commands for adjusting & measuring
+focus/gain/balance. Emulators can just omit that stuff, and can always
+signalize good operation (except that one should emulate failures for Disc
+Missing; and eventually also for cases like Laser=Off, or Spindle=Stopped).
+Focus does obviously refer to moving the lens up/down. Gain does probably refer
+to reflection level/laser intensity. Balance might refer to tracking
+adjustments or so.
The PSX CDROM BIOS versions vC1, vC2, and vC3 are using following CX()
+commands:
+
<B> <--vC1--> <--vC2--> <--vC3--></B>
+<B> CXD2510Q CXD2545Q CXD2938Q</B>
+ CX(00) CX(00) CX(00) AllFocusSwitchesOff
+ CX(02) CX(02) CX(02) FocusSearchVoltageFalling
+ CX(03) CX(03) CX(03) FocusSearchVoltageRising ;ForTestOnly
+ CX(08) CX(08) CX(08) FocusServoOn
+ CX(0C) CX(0C) CX(0C) FocusServoOnAndDefectOn ;diff.usage vC# ?
+ -----
+ CX(11) - - SledKickHeight2
+ CX(12) - - SledKickHeightInvalid
+ CX(19) - - TrackingGainAndSledKickHeight2
+ CX(1D) - - TrackingGainBrakeAndSledKickHeight2
+ CX(1E) - - TrackingGainBrakeAndSledKickHeightInvalid
+ -----
+ - CX(11) CX(11) AntiShockOff ;\
+ - CX(13) CX(13) AntiShockOffGainUp ;
+ - CX(17) CX(17) AntiShockOffGainUpBrake ;/
+ -----
+ CX(20) CX(20) CX(20) SledAndTrackingOff
+ CX(21) CX(21) CX(21) SledServoOn ;ForTestOnly
+ CX(22) CX(22) CX(22) SledFastForward
+ CX(23) CX(23) CX(23) SledFastReverse
+ CX(24) - - TrackingServoOn
+ CX(25) CX(25) CX(25) SledAndTrackingServoOn
+ - CX(26) CX(26) SledFastForwardAndTrackingServoOn
+ CX(28) CX(28) CX(28) TrackingForwardJump ;ForTestOnly
+ CX(2C) CX(2C) CX(2C) TrackingReverseJump ;ForTestOnly
+ -----
+ CX(30+n) - - BalanceAdjust(0..7)
+ CX(38+n) - - GainAdjust(0..7)
+ -----
+ - CX(30) CX(30) SetSledKickLevel1 ;\
+ - CX(31) CX(31) SetSledKickLevel2 ;
+ - CX(32) CX(32) SetSledKickLevel3 ;/
+ -----
+ - CX(3400E6) CX(3400E6) SetK00toE6hSledInputGain ;def=E0h
+ - CX(340730) CX(340730) SetK07to30hSledAutoGain ;blah ;def=30h
+ - CX(34114A) CX(34114A) SetK11to4AhFocusOutputGain ;def=32h
+ - CX(341330) CX(341330) SetK13to30hFocusAutoGain ;blah ;def=30h
+ - CX(341D6F) CX(341D6F) SetK1Dto6FhTrackingLowBoostFilterAL ;def=44h
+ - CX(341F64) CX(341F64) SetK1Fto64hTrackingLowBoostFilterBL ;def=5Eh
+ - CX(342220) CX(342220) SetK22to20hTrackingOutputGain ;def=18h
+ - CX(342330) CX(342330) SetK23to30hTrackingAutoGain ;blah ;def=30h
+ - CX(342D28) CX(342D28) SetK2Dto28hFocusGainDownOutputGain ;def=1Bh
+ - CX(343E70) CX(343E70) SetK3Eto70hTrackingGainUpOutputGain ;def=57h
+ - - CX(34910000) NewScexStopReading ;\
+ - - CX(3491x180) NewScexRandomKey(x) ;
+ - - CX(34920000) NewScexFlushResyncOrSo ; SCEX SPECIAL
+ - - CX(34944A00) NewScexInitValue1 ; see also:
+ - - CX(3498C000) NewScexInitValue2 ; CX(3C2080)
+ - - CX(349C1000) NewScexThis ;\inverse ;
+ - - CX(349D1000) NewScexThat ;/of COUT ;/
+ - CX(34F000) CX(34F000) SetTRVSCto000h
+ - CX(34Fxxx) CX(34Fxxx) SetFBIAStoNNNh
+ -----
+ - CX(3740AA) CX(3740AA) SetSMto00h ;\set SM to 0,6,7,9
+ - CX(3746AA) CX(3746AA) SetSMto06h ; (sled move voltage)
+ - CX(3747AA) CX(3747AA) SetSMto07h ; (and init several
+ - CX(3749AA) CX(3749AA) SetSMto09h ;/fixed settings)
+ -----
+ - CX(380010) CX(380010) ModeMeasureTrackingZeroLevel ;\Measure modes
+ - CX(380800) CX(380800) ModeMeasureRfZeroLevel ; (accepted
+ - CX(382000) CX(382000) ModeMeasureFocusZeroLevel ; every 2.9ms)
+ - CX(388000) CX(388000) ModeMeasureVcLevel ;/
+ - CX(38140A) CX(38140A) ModeCompensate
+ - CX(38140E) CX(38140E) ModeCompensateAndTraverseCenter
+ - CX(38148A) CX(38148A) ModeCompensateAndDefectOff
+ - CX(38148E) CX(38148E) ModeCompensateAndDefectOffTraverseCenter
+ - CX(3814AA) CX(3814AA) ModeCompensateAndStuffAndMeasureTraverse ;!
+ - CX(38150A) CX(38150A) ModeCompensateAndTrackingAutoGain
+ - CX(38150E) CX(38150E) ModeCompensateAndTrackingAutoGain
+ - CX(38160A) CX(38160A) ModeCompensateAndFocusAutoGain
+ -----
+ - CX(391E) - SenseRFDCinputSignalWithoutDAC ;\rather
+ - CX(3983) - SenseFEinputSignalWithDAC ;/unused
+ - CX(399C) - SenseTRVSCregisterWithDAC ;\only if
+ - CX(399D) - SenseFBIASregisterWithDAC ;/TEST1=LOW
+ -----
+ - CX(3A0000) CX(3A0000) FocusBiasAdditionOff ;\
+ - CX(3A4000) CX(3A4000) FocusBiasAdditionOn ;/
+ - CX(3B2250)!CX(3B7250)!InitOperationForMirrDfctFok <-- vC2/vC3 DIFF
+ - CX(3C) !!!CX(3C0080) TzcCoutSelectHPTZC;\ <--formerly CX(3C)
+ - - !!!CX(3C2080) TzcCoutSelectSCEX ; <--special NewScex mode
+ - CX(3D) !!!CX(3C4080) TzcCoutSelectDTZC ;/ <--formerly CX(3D)
+ - CX(3E0000) CX(3E0000) InitFilterBits ;\
+ - CX(3E0008) CX(3E0008) InitFilterBitsInvalid ;/
+ - CX(3F0008) CX(3F0008) InitOtherStuff ;-
+ -----
+ CX(4000) CX(4000) CX(4000) AutoSeqCancel
+ CX(4700) CX(4700) CX(4700) AutoSeqFocusOn
+ CX(4800) CX(4800) CX(4800) Forward1track
+ CX(4900) CX(4900) CX(4900) Reverse1track
+ CX(4C00) CX(4C00) CX(4C00) Forward2Ntrack
+ CX(4D00) CX(4D00) CX(4D00) Reverse2Ntrack
+ -----
+ CX(54) CX(54) CX(54) BlindBrakeOverflowTimer=4
+ CX(5A) CX(5A) CX(5A) BlindBrakeOverflowTimer=A
+ CX(6100) CX(6100) CX(6100) SledKickBrakeKickTimer
+ CX(70xxx0) CX(70xxx0) CX(70xxx0) TrackJumpCountSetting
+ CX(8180) CX(8180)!!!CX(810408) MODE = Audio (CD-DA)
+ - CX(8120)!!!CX(812400) MODE = Audio (CD-DA) (manual SPI bus access)
+ - - CX(810000/UNUSED)
+ - - CX(812000/UNUSED)
+ CX(8980) CX(8980) CX(890408) MODE = CDROM (Data)
+ - - CX(898000) MODE = CDROM (Data) (used on RESET)
+ CX(9B00) CX(9B00)!!!CX(9B1000) NormalSpeed
+ CX(9F00) CX(9F00)!!!CX(9F1000) DoubleSpeed
+ CX(A040) CX(A040) CX(A040) Attentuation Off
+ CX(A140) CX(A140) CX(A140) Attentuation -12 dB
+ CX(B01000) CX(B01000) CX(B01000) TraverseMonitorCounterSetting
+ CX(C600) CX(C600) CX(C600) SpindleServoCoefficientSetting
+ CX(D7) CX(D7) CX(D70000) ClvControl (fixed)
+ CX(E0) CX(E0) CX(E00000) SpindleMotorStop
+ - - CX(E02000) <-- aka bugged CX(E0) with CRAP=2000h
+ CX(E6) CX(E6) CX(E60000) AutomaticNormal
+ CX(E8) CX(E8) CX(E80000) SpindleMotorForward
+ - - CX(E8crap) <-- aka bugged CX(E8) with CRAP=xxxxh
+ CX(EA) CX(EA) CX(EA0000) SpindleMotorReverse
+ - - CX(EAcrap) <-- aka bugged CX(EA) with CRAP=xxxxh
+ CX(EE) CX(EE) CX(EE0000) RoughServo
+ -----
+ CX(F) CX(F) CX(F) Unused (N/A)
+ -----
+ CX(Xx) CX(Xx) CX(Xx) ;\
+ CX(Xxxx) CX(Xxxx) CX(Xxxx) ; TestCommand (cmd_19h_50h)
+ CX(Xxxxxx) CX(Xxxxxx) CX(Xxxxxx) ;
+ - - CX(Xxxxxxxx) ;/
+ - CX(Xxxxxx) CX(Xxxxxx) SerialSense, CX(Xxxx) with extra 8bit junk
+ sense(30) SEIN.BAL ;vC2: SSTP
+ sense(38) SEIN.GAIN ;vC2: AGOK(AGT/AGF) or XAVEBSY(AVRG) or SSTP(else?)
+ sense(40) XBUSY (low=AutoSeqBusy)
+ sense(50) FOK (high=FokusOkay)
+ sense(A0) GFS (high=GoodFrameSync, ie. CorrectPlaybackSpeed)
+ sense(C5) COUT (toggles each 100h 'tracks') (100h=selected via CX(B01000))
+ sense(EA) /OV64 (low=EFM too long?)
+The CXD2545Q contains Preset Coefficients in internal ROM, which are copied to
+internal Coefficient RAM shortly after Reset. CX(34xxxx) allows to change those
+RAM settings, and CX(39xxxx) allows to readout some of those values serially.
Addr Val Expl.
+ K00 E0 Sled input gain
+ K01 81 Sled low boost filter A-H
+ K02 23 Sled low boost filter A-L
+ K03 7F Sled low boost filter B-H
+ K04 6A Sled low boost filter B-L
+ K05 10 Sled output gain
+ K06 14 Focus input gain
+ K07 30 Sled auto gain
+ K08 7F Focus high cut filter A
+ K09 46 Focus high cut filter B
+ K0A 81 Focus low boost filter A-H
+ K0B 1C Focus low boost filter A-L
+ K0C 7F Focus low boost filter B-H
+ K0D 58 Focus low boost filter B-L
+ K0E 82 Focus phase compensate filter A
+ K0F 7F Focus defect hold gain
+ K10 4E Focus phase compensate filter B
+ K11 32 Focus output gain
+ K12 20 Anti shock input gain
+ K13 30 Focus auto gain
+ K14 80 HPTZC / Auto Gain High pass filter A
+ K15 77 HPTZC / Auto Gain High pass filter B
+ K16 80 Anti shock high pass filter A
+ K17 77 HPTZC / Auto Gain low pass filter B
+ K18 00 Fix (should not change this preset value)
+ K19 F1 Tracking input gain
+ K1A 7F Tracking high cut filter A
+ K1B 3B Tracking high cut filter B
+ K1C 81 Tracking low boost filter A-H
+ K1D 44 Tracking low boost filter A-L
+ K1E 7F Tracking low boost filter B-H
+ K1F 5E Tracking low boost filter B-L
+ K20 82 Tracking phase compensate filter A
+ K21 44 Tracking phase compensate filter B
+ K22 18 Tracking output gain
+ K23 30 Tracking auto gain
+ K24 7F Focus gain down high cut filter A
+ K25 46 Focus gain down high cut filter B
+ K26 81 Focus gain down low boost filter A-H
+ K27 3A Focus gain down low boost filter A-L
+ K28 7F Focus gain down low boost filter B-H
+ K29 66 Focus gain down low boost filter B-L
+ K2A 82 Focus gain down phase compensate filter A
+ K2B 44 Focus gain down defect hold gain
+ K2C 4E Focus gain down phase compensate filter B
+ K2D 1B Focus gain down output gain
+ K2E 00 Not used
+ K2F 00 Not used
+ K30 80 Fix (should not change this preset value)
+ K31 66 Anti shock low pass filter B
+ K32 00 Not used
+ K33 7F Anti shock high pass filter B-H
+ K34 6E Anti shock high pass filter B-L
+ K35 20 Anti shock filter comparate gain
+ K36 7F Tracking gain up2 high cut filter A
+ K37 3B Tracking gain up2 high cut filter B
+ K38 80 Tracking gain up2 low boost filter A-H
+ K39 44 Tracking gain up2 low boost filter A-L
+ K3A 7F Tracking gain up2 low boost filter B-H
+ K3B 77 Tracking gain up2 low boost filter B-L
+ K3C 86 Tracking gain up phase compensate filter A
+ K3D 0D Tracking gain up phase compensate filter B
+ K3E 57 Tracking gain up output gain
+ K3F 00 Not used
+ K40 04 Tracking hold filter input gain
+ K41 7F Tracking hold filter A-H
+ K42 7F Tracking hold filter A-L
+ K43 79 Tracking hold filter B-H
+ K44 17 Tracking hold filter B-L
+ K45 6D Tracking hold filter output gain
+ K46 00 Not used
+ K47 00 Not used
+ K48 02 Focus hold filter input gain
+ K49 7F Focus hold filter A-H
+ K4A 7F Focus hold filter A-L
+ K4B 79 Focus hold filter B-H
+ K4C 17 Focus hold filter B-L
+ K4D 54 Focus hold filter output gain
+ K4E 00 Not used
+ K4F 00 Not used
+VCDs are Video CDs with MPEG compression, yielding a playtime of 72 minutes per
+disc (whole movies usually being stored on two CDs). VCDs are popular in asia
+(as opposed to VHS tapes used in western world).
For the Playstation, the asian SCPH-5903 model includes a special daughterboard
+with MPEG decoding hardware for playing VCDs.
+CDROM - Video CD Commands
+Pinouts - VCD Pinouts
+Without that hardware it has been widely believed to be impossible to play VCDs
+on Playstations, although, as of 2017, it turned out that the Playstation's CPU
+and MDEC decoder are fast enough for that purpose (when skipping B-frames,
+rendering the movie in monochrome without colors, and reducing audio output to
+11kHz/mono).
VCD ISO Basic Files (INFO, ENTRIES, AVSEQnn, ISO Filesystem)
+VCD ISO Playback Control PBC Files (PSD, LOT, ITEMnnnn)
+VCD ISO Search Files (SCANDATA, SEARCH, TRACKS, SPICONTX)
+VCD ISO Misc files (CAPTnn, AUDIOnn, KARINFO, PICTURES, CDI)
VCD MPEG-1 Multiplex Stream
+VCD MPEG-1 Video Stream
+XXX MPEG-1 Macroblocks
+VCD MP2 Audio Stream
XXX
VCDs are having a standard ISO Primary Volume Descriptor, with some VCD
+specific entries:
+
008h 32 System Identifier (always "CD-RTOS CD-BRIDGE" for VCDs)
+ 028h 32 Volume Identifier (often nonsense, eg. "" or "__" or "VolumeLabel")
+ 23Eh 128 Application Identifier ("CDI/CDI_APPL.VCD;1" or "CDI/CDI_VCD.APP;1")
+ 400h 8 CD-XA Identifying Signature ("CD-XA001" for PSX and VCD)
+ VCDs are using MODE2 (with 800h-byte and 914h-byte sectors)
+ MPEG videos are on extra data tracks (outside of the ISO area on Track 1)
+ Files in VCD or SVCD folders use fixed sectors numbers (00:04:00 and up)
+ All 16bit/32bit values in files in VCD,SVCD,EXT,etc are BIG-ENDIAN
+ 000h 8 ID "VIDEO_CD" for VCD (or "SUPERVCD"/"HQ-VCD " for SVCD)
+ 008h 1 Version ;Version Major (01h) (or 02h for VCD 2.0)
+ 009h 1 System Profile Tag ;Version Minor (00h) (or 01h for VCD 1.1 or HQ)
+ 00Ah 16 Album ID/Desc (name in ASCII, padded with SPC) (usually empty)
+ 01Ah 2 Total Number of CDs in Album (1..N) ;\usually always 1,1 (even
+ 01Ch 2 Number of this CD in Album (1..N) ;/for movies with 2 discs)
+ 01Eh 13 PAL Flags, 98x1bit, for each Track? (0=NTSC, 1=PAL)
+ 02Bh 1 InfoStatusFlags (see below)
+ Below is usually zero-filled when not using PBC
+ 02Ch 4 Size of PSD.VCD file (or PSD.SVD?) (0=None)
+ 030h 3 First segment addr MM:SS:00 in BCD (00:02:00 ???)
+ 033h 1 Offset Multiplier for "PsdOffset" values in PSD.VCD (must be 8)
+ 034h 2 Number of ListIDs in LOT.VCD file (1..7FFFh, plus 1 in some discs)
+ 036h 2 Number of ITEMnnnn.DAT files (plus nonsense in some discs?)
+ Below is usually zero-filled (maybe exists on SVCD only?)
+ 038h 1980 SegmentContent[1..1980] (b0-1=Audio, b2-4=Video, b5=Cont, b6-7=OGT)
+ 7F4h 5*2 volume start time[0]: 5x16bit ;aka playing_time[5] in seconds (?)
+ 7FEh 2 Reserved (0)
+ bit0 Reserved, must be zero
+ bit1-2 Restriction (0=No, 1..3=Restricted category 1..3) (eg. "not for kids")
+ bit3 Special Information is encoded in the pictures, uh?
+ bit4 MPEG User Data is used for Closed Caption (user_data_cc) (0=No, 1=Yes)
+ bit5 Next Disc with PBC (0=Start at ListID#1, 1=Start at ListID#2)
+ bit6 Next Disc without PBC (0=Start at Track #2, 1=Start at Track #3)
+ bit7 Extended PBC available (0=No, 1=Yes... aka EXT\PSD_X exists?)
+ 000h 8 ID "ENTRYVCD" for VCD and SVCD (or "ENTRYSVD" for VCD30)
+ 008h 1 Version ;\same as in INFO.VCD/SVD
+ 009h 1 System Profile Tag ;/
+ 00Ah 2 Number of Entries/Chapters (1..500)
+ 00Ch 4*500 Entry[N] (Track 02h..99h, and MM:SS:FF) (all 4 bytes in BCD)
+ 7DCh 36 Reserved (0)
+ 0x02 --- VCD2.0
+ 0x01 --- SVCD, should be same as version in INFO.SVD
+ 0x01 if VCD1.1
+ 0x00 else
+These filesystem entries contain pointers to the video tracks (that is, outside
+of the ISO area on Track 1).
+Commercially made SVCDs can reportedly contain 7 folders: Autorun, Data, Ext,
+Mpegav, Segment, Svcd and Vmp (ie. there's no MPEG2 folder on all SVCDs? though
+that MPEGAV folder is said to contain a .MPG file instead of .DAT file).
Playback Control (PBC) is an optional feature that allows to define menues,
+pictures or text pages (whereas all those is internally just consisting of MPEG
+compressed bitmaps; rather than of text characters).
+Presence of the PBC feature is indicated by PSD.VCD filesize entry (in
+INFO.VCD) being nonzero. PBC seems to be supported by most VCDs (except older
+discs from around 1997), however, many VCDs are merely including a single
+PlayList entry for the movie track, without any further menues/extras.
The Descriptors in this file can be considered as being "program code". The
+program is usually stuck on "executing" the current descriptor (eg. playing a
+movie, or showing a selection menu) without automatically increasing the
+program counter. Actual program flow occurs only if the user presses a button
+(or upon selection timeouts), causing the program to "goto" to a new PsdOffset.
+And, something does probably happen upon end-of-track/item... maybe that does
+automatically trigger the Next button handler?
+
<B> PsdPlayListDescriptor (14+2*N bytes):</B>
+ 00h 1 Type (10h=PlayList)
+ 01h 1 Number of Items (noi) ;for Start-of-Movie and Numeric-Input?
+ 02h 2 ListID for this Descriptor (1..7FFFh)
+ 04h 2 PsdOffset for Prev button (FFFFh=Disable)
+ 06h 2 PsdOffset for Next button (FFFFh=Disable)
+ 08h 2 PsdOffset for Return/back button (FFFFh=Disable)
+ 0Ah 2 Play time in 1/15s (=max 72.8 minutes) (or 0000h=full item)
+ 0Ch 1 Delay time in "1s/10s" units after ;<-- uh, after? after what?
+ 0Dh 1 Auto pause time in "1s/10s" units (used for each item in list if
+ the auto pause flag in a sector is true) [WHAT is that? Trigger bit?]
+ 0Eh 2*N ItemID[N] ;item number (0..599 or 1000..2979)
+ Entry 0 is for "start of movie" (usually 0002h=Track 2)
+ Entry 1..N-1 is for numeric input ?
+<B> PsdSelectionListDescriptor (20+2*N bytes, or 36+6*N bytes):</B>
+ 00h 1 Type (18h=SELECTION_LIST, or 1Ah=EXT_SELECTION_LIST)
+ 01h 1 Flags (bit0=SelectionArea, bit1=CommandList, bit2-7=Reserved)
+ 02h 1 nos <-- aka Number of Numeric-input selections ?
+ 03h 1 bsn <-- ?
+ 04h 2 ListID for this Descriptor (1..7FFFh)
+ 06h 2 PsdOffset for Prev button
+ 08h 2 PsdOffset for Next button
+ 0Ah 2 PsdOffset for Return/back button
+ 0Ch 2 PsdOffset for Default button (uh, what is that?)
+ 0Eh 2 PsdOffset for Timeout
+ 10h 1 totime <-- aka Timeout Time maybe? in WHAT units?
+ 11h 1 loop <-- aka ?
+ 12h 2 itemid <-- aka Item to be displayed during the selection?
+ 14h 2*N PsdOffset[N] for Numeric-input ?
+ Below only for SVCDs (with Type=18h), or for Extended VCDs (with Type=1Ah):
+ (14h+2*N) 4 Area for Prev (x1,y1,x2,y2) ;\these extra entries exist for
+ (18h+2*N) 4 Area for Next (x1,y1,x2,y2) ; SVCDs with Type=18h, and
+ (1Ch+2*N) 4 Area for Return (x1,y1,x2,y2) ; Extended VCDs with Type=1Ah
+ (20h+2*N) 4 Area for Default (x1,y1,x2,y2) ; (but do NOT exist for
+ (24h+2*N) 4*N Area[N] (x1,y1,x2,y2) ;/older VCDs with Type=18h)
+<B> PsdEndListDescriptor (8 bytes)</B>
+ 00h 1 Type (1Fh=EndList)
+ 01h 1 Next_disc ;00h to stop PBC or NNh to switch to disc no NN (BCD!?)
+ 02h 2 Item (0 or 1000..2979, should be still image, eg. Change Disc pic)
+ 04h 4 Reserved (0)
+ N/A - This descriptor doesn't have a ListID (unlike as other descriptors)
+<B> PsdCommandListDescriptor (5+2*N bytes)</B>
+ 00h 1 Type (20h=CommandList)
+ 01h 2 Command_count
+ 03h 2 ListID for this Descriptor (1..7FFFh)
+ 05h 2*N command[EMPTY_ARRAY_SIZE] ;uh, WHAT is a command?
+<B> PsdAlignmentPadding (after each list entry)</B>
+ 00h 0..7 Padding to next 8-byte PsdOffset boundary (00h-filled)
+ 1..60 --> wait "N" seconds
+ 61..254 --> wait "(N-60)*10+60" seconds
+ 255 --> wait infinite
+ 0..1 - Play nothing
+ 2..99 - Play Track 2..99 (TOC tracks, for AVSEQnn.DAT and AUDIOnn.DAT?)
+ 100..599 - Play Entry 1..500 from table in ENTRIES file up to end of track
+ 600..999 - Reserved
+ 1000..2979 - Play SPI Segment Play Item 1..1980 (ITEMnnnn.DAT file)
+ 2980..65535 - Reserved
+ 0..N Offset within PSD.VCD file, in 8-byte units
+ FFFDh PSD_OFS_MULTI_DEF_NO_NUM ;\uh, what is that?
+ FFFEh PSD_OFS_MULTI_DEF ;/
+ FFFFh PSD_OFS_DISABLED ;-no function assigned to the button
+The ListID Offset Table (LOT) allows to translate ListIDs to PsdOffsets. The
+file is always 64Kbyte in size (unused entries should be set to FFFFh).
+The PSD.VCD file does also assign ListIDs to each descriptor (ie. instead of
+using the LOT.VCD file, one could also scan all descriptors in PSD.VCD when
+searching a specific ListID).
+
0000h 2 Reserved (0)
+ 0002h 2*7FFFh PsdOffset[1..7FFFh] ;for ListID 1..7FFFh
+These files contain Pictures/Menu screens referenced from PSD.VCD. The files
+seem to be stored in FORM2 sectors (not FORM1). Unknown if the files are
+located on Track 1.
+The content of the files seems to resemble short MPEG video clips (with only
+one picture frame, or eventually with a few frames for short animations,
+including audio in some cases). Still images are said to be allowed to use
+twice the resolution of MPEG videos.
The "extended" files are often identical to the normal PSD/LOT files. The
+difference is that, if disc uses SelectionLists, then PSD should use the normal
+descriptor (18h), and PSD_X should use the extended descriptor (1Ah), the
+latter one seems to be intended to allow to highlight the current menu
+selection (particulary useful when using +/- buttons instead of Numeric Keypad
+input). Note: Nethertheless, Muppets from Space uses descriptor 18h in PSD_X.
+Unknown if SVCDs do really have "extended" files, too (theoretically the VCD
+extension should be a default feature for SVCDs).
Although PBC was intended as "nice extra feature", many VCDs are containing
+faulty PSD files. In general, VCD players should either leave PBC unsupported
+(or at the very least, provide an option for disabling it).
+Red Dragon from 2003 uses extended selection lists, but crops PSD_X.VCD to the
+same filesize as PSD.VCD.
+Muppets from Space from 1999 assigns weird functions to Prev/Next buttons (Next
+wraps from Last Track to First Track, but Prev doesn't wrap from First to Last;
+default Non-PBC Prev/Next functions are more user friendly).
+Sony's SCPH-5903 console refuses to display the HH:MM:SS playback time when
+using PBC (instead it does only display a "PBC" logo).
Below files can help searching I-frames, and provide some info about the
+content of Tracks and Segments.
+Essentially, searching I-frames is possible without these files - however, if
+present, then the files may be useful in two cases: For discs with variable
+bitrates (which isn't allowed on VCDs though), and, for CDROM firmwares that
+don't support "inaccurate" seeking (like telling it to start reading anywhere
+NEAR some MM:SS:FF value, so one could skip sectors till reaching an I-frame)
+(ie. if the firmware insists on a "accurate" seek position, then it's best to
+give it a known I-frame address).
Reportedly the new SVCD files TRACKS.SVD and SEARCH.DAT are on these sectors:
+
TRACKS_SVD_SECTOR = (PSD_VCD_SECTOR+1) ;aka 2nd sector in PSD.SVD?
+ SEARCH_DAT_SECTOR = (TRACKS_SVD_SECTOR+1) ;aka 3rd..Nth sector in PSD.SVD?
+This file fulfills much the same purpose of the SEARCH.DAT file except that
+this file is mandatory only if the System Profile Tag of the INFO.SVD file is
+0x01 (HQ-VCD) and also that it contains sector addresses also for each video
+Segment Play Items in addition to the regular MPEG tracks.
+
SCANDATA.DAT Format for VCD 2.0 (12+3*N bytes):
+ 000h 8 ID "SCAN_VCD"
+ 008h 1 Version (02h for VCD 2.0)
+ 009h 1 Reserved (0)
+ 00Ah 2 Number of scan points (in 0.5s units) (max FFFFh = ca. 9.1 hours)
+ 00Ch 3*N Scan Point[0..N-1] ;MM:SS:FF of closest I-frame
+ SCANDATA.DAT Format for SVCD (16+3*N+2*X+3*Y+3*Z bytes):
+ 000h 8 ID "SCAN_VCD"
+ 008h 1 Version (01h for SVCD)
+ 009h 1 Reserved (0)
+ 00Ah 2 scandata_count ;number of 3-byte entries in the table
+ 00Ch 2 track_count ;number of MPEG tracks on disc
+ 00Eh 2 spi_count ;number of consecutively recorded play item segments
+ ; (as opposed to the number of segment play items).
+ 010h 3*N msf_t cum_playtimes[N] ;cumulative playing time up to track N.
+ ; (track time just wraps at 99:59:74)
+ xxxh 2*X spi_indexes[X] ;Indexes into the following scandata table
+ xxxh 2 mpegtrack_start_index ;Index into the following scandata table
+ ; (where the MPEG track scan points start)
+ xxxh 3*Y The scandata table... [Y] ;8bit Track Number and 16bit Index
+ uint8_t track_num; /* Track number as in TOC
+ uint16_t table_offset; /* Index into scandata table
+ xxxh 3*Z msf_t scandata_table[Z] ;MM:SS:FF
+This file defines where the scan points are. It covers all mpeg tracks
+together. A scan point at time T is the nearest I-picture in the MPEG stream to
+the given time T. Scan points are given at every half-second for the entire
+duration of the disc.
+
000h 8 ID "SEARCHSV"
+ 008h 1 Version (01h)
+ 009h 1 Reserved (0)
+ 00Ah 2 Number of scan points
+ 00Ch 1 Time_interval (in units of 0.5 seconds) (must be 01h)
+ 00Dh 3*N Scan Point[0..N-1] ;MM:SS:FF of closest I-frame
+The TRACKS.SVD file contains a series of structures, one for each track, which
+indicates the track's playing time (in sectors, not actually real time) and
+contents.
+SVCD\TRACKS.SVD is a mandatory file which describes the numbers and types of
+MPEG tracks on the disc.
+
SVCD\TRACKS.SVD Format for SVCD (11+4*N bytes):
+ 000h 8 ID "TRACKSVD"
+ 008h 1 Version (01h)
+ 009h 1 Reserved (0)
+ 00Ah 1 Number of MPEG tracks (N)
+ 00Bh 3*N Track playing_time[N] (MM:SS:FF, in BCD)(in sectors, not real time)
+ 0xxh 1*N TrackContent[N] ;bit0-1=Audio,bit2-4=Video,bit5=Reserved,bit6-7=OGT
+ SVCD\TRACKS.SVD Format for VCD30 (11+5*N bytes) (some sort of SVCD-prototype):
+ 000h 8 ID "TRACKSVD"
+ 008h 1 Version (01h)
+ 009h 1 Reserved (0)
+ 00Ah 1 Number of MPEG tracks (N)
+ 00Bh 5*N Cum_Playing_time and Content (MM:SS:FF in BCD, and OGT, Audio)
+Unknown if/when/where/why this file exists, possibly only on VCD30?
+Note: The same info can be stored in INFO.SVD at offsets [038h..7F3h].
+
0000h 8 ID "SPICONSV"
+ 0008h 1 Version (01h)
+ 0009h 1 Reserved (0)
+ 000Ah 2*1980 Segment Content[1..1980] (1st byte=OGT, 2nd byte=Audio)
+ 0F82h 126 Reserved (0)
+For SVCD\INFO.SVD and SVCD\TRACKS.SVD (on SVCD) these are encoded in 1 byte:
+
bit0-1 Audio characteristics:
+ 0 = No MPEG audio stream
+ 1 = One MPEG1 or MPEG2 audio stream without extension
+ 2 = Two MPEG1 or MPEG2 audio streams without extension
+ 3 = One MPEG2 multi-channel audio stream with extension
+ bit2-4 Video characteristics:
+ In TRACKS.SVD this must be 0,3,7 (no still pictures)
+ 0 = No MPEG video data
+ 1 = NTSC still picture
+ 2 = NTSC Reserved (NTSC still pic hires?)
+ 3 = NTSC motion picture
+ 4 = Reserved
+ 5 = PAL still picture
+ 6 = PAL Reserved (PAL still pic hires?)
+ 7 = PAL motion picture
+ bit5 Indicates segment is continuation of an item
+ In TRACKS.SVD this must be 0 (reserved)
+ 0 = First or only segment of item
+ 1 = Second or later segment of item
+ bit6-7 Overlay Graphics/Text (OGT):
+ 0 = No OGT substream
+ 1 = Sub-stream 0 available
+ 2 = Sub-stream 0 & 1 available
+ 3 = All OGT sub-substreams available
+ 1st byte = Audio characteristics ;\probably same values as
+ 2nd byte = Overlay Graphics/Text (OGT) ;/in above bitfields?
+VCDs with subtitles are usually/always having the subtitles encoded directly in
+the picture frames (ie. in the MPEG macroblocks, rather than using the Closed
+Caption feature).
+These CAPTnn.DAT files are intended for Closed Captions (eg. subtitles in
+different languages and/or for deaf people).
+Alternately, the "user_data_cc" flag in INFO.VCD?/INFO.SVD can indicate to
+store Closed Captions in MPEG User Data (with START_CODE=000001B2h=User Data)
+instead of in EXT\CAPTnn.DAT. Either way, the format of those Closed Captions
+is unknown.
+Moreover, Content can be flagged to have Overlay Graphics/Text (OGT), whatever
+that is: it might be related to Closed Captions.
+Note: Reportedly CAPTnn.DAT can exist on VCDs and SVCDs (although the same
+person reported that VCDs do not support subtitles, so that info sounds wrong).
These filesystem entries contain pointers to uncompressed audio tracks tracks
+(that is, outside of the ISO area on Track 1).
+Most VCDs don't have audio tracks (though some VCDs do contain empty CDDA
+folders).
+Maybe the feature is occassionally used the other way around: Music discs
+containing VCD clips as bonus feature?
The KARAOKE folder exists on many VCDs (about 50%), but it's usually/always
+empty on all discs.
+Reportedly the folder can contain "KARINFO.xxx" files, but the purpose/format
+of that files is unknown.
+Reportedly there are Midi VCDs (MVCDs) for karaoke, maybe those discs have
+"KARINFO.xxx" files(?)
Unknown purpose. The PICTURES folder has been spotted on one VCD (Wallace and
+Gromit), but the folder was just empty.
The CDI folder is some relict for Philips CDI Players, it isn't used by normal
+VCD players, however, the CDI folder & files are included on most or all
+VCDs.
+The path/name for the CDI executable is stored at offset 23Eh in the ISO
+Primary Volume Descriptor (usually "CDI/CDI_APPL.VCD;1" or "CDI/CDI_VCD.APP;1")
+(or accidentally "CDI_CDI_VCD.APP;1" on homebrew Nero discs).
+The files in the CDI folder are usually just some standard files (without any
+customizations), however, there are some different revisions of these files:
+
<B> Revision A (spotted on two discs from 1997 and 1999):</B>
+ CDI_APPL.VCD 80702 bytes, 04-Mar-1996, CRC32=AE8FC5D0h ;executable
+ VCD_BACK.DYV 92572 bytes, 18-Jul-1995, CRC32=00693E5Eh ;whatever?
+ VCD_BTN.C8 93719 bytes, 18-Jul-1995, CRC32=FF0A636Ah ;whatever?
+<B> Revision B (spotted on a disc from 2003):</B>
+ CDI_VCD.APP 20648 bytes, 00-Nul-0000 CRC32=DC885F70h ;executable
+ CDI_FONT.FNT 145388 bytes, 00-Nul-0000 CRC32=FB4D63F4h ;font?
+ CDI_ALL.RTF ? bytes, CRC32=? ;realtimefile?
+ CDI_BUM.RTF ? bytes, CRC32=? ;realtimefile?
+<B> Revision C (spotted on a disc from 2006, and homebrews from 2001 and 2017):</B>
+ CDI_VCD.APP 102400 bytes, 00-Nul-0000 CRC32=E91E128Dh ;executable
+ CDI_VCD.CFG 193 bytes, 00-Nul-0000 CRC32=D1C6F7ADh ;config/ascii
+ CDI_TEXT.FNT 13616 bytes, 00-Nul-0000 CRC32=BDC55E86h ;font?
+ CDI_IMAG.RTF 1510028 bytes, 00-Nul-0000 CRC32=(RIFF) ;realtimefile?
+The Multiplex stream is some higher level stream, intended to help to
+distinguish between Audio- and Video-streams (which are enclosed in the
+Multiplex stream). MPEG's are somewhat organized in "sectors", with sector size
+varying for normal .mpg files and VCDs:
+
VCD discs --> Sector Size = 914h bytes (the discs MODE2/FORM2 sector size)
+ .mpg files --> Sector Size = 800h bytes (regardless of physical sector size)
+The Pack Header is found at the begin of the stream (on VCDs, it's also found
+at the begin of each sector). The SCR values might help on identifying the
+current playback position, and, with the bitrate value, this could be also used
+to compute the distance to another position (though there are other ways to
+determine the position/bitrate, so the Pack is kinda useless).
+
32bit PACK_START_CODE (000001BAh) ;-4byte
+ 2bit Fixed (00b for MPEG-1) (would be 01b for MPEG-2) ;\
+ 2bit Fixed (10b) ;
+ 3bit System Clock Reference, bit32-30 ;\ ;
+ 1bit Marker (1) ; System Clock Reference (SCR) ;
+ 15bit System Clock Reference, bit29-15 ; (intended Time, ; 5byte
+ 1bit Marker (1) ; in 90kHz clock cycles) ;
+ 15bit System Clock Reference, bit14-0 ;/ ;
+ 1bit Marker (1) ;/
+ 1bit Marker (1) ;\
+ 22bit Multiplex Rate (total bitrate of the stream, in 400bit/s units) ; 3byte
+ 1bit Marker (1) ;/
+The System Header is usally found after the first Pack at the begin of the
+stream.
+
32bit SYSTEM_HEADER_START_CODE (000001BBh) ;\6byte
+ 16bit Header Length minus 6 (in bytes) (0006h+N*3) ;/
+ 1bit Marker (1) ;\
+ 22bit Rate bound (max multiplex rate of all packs in the stream, ; 3byte
+ 1bit Marker (1) in 400bit/s units) ;/
+ 6bit Audio Bound (max number of audio streams in this ISO stream) ;\
+ 1bit Fixed Flag (1=Fixed bitrate) ; 1byte
+ 1bit CSPS Flag (1=Constrained) ;/
+ 1bit System Audio Lock Flag XXX ;\
+ 1bit System Video Lock Flag XXX ; 1byte
+ 1bit Marker (1) ;
+ 5bit Video Bound (max number of video streams in this ISO stream) ;/
+ 8bit Reserved (FFh) ;-1byte
+ 8bit Stream ID (C0h..DFh=Audio, E0h..EFh=Video) ;\
+ 2bit Fixed (11b) ; 3byte
+ 1bit STD buffer scale (0=Mul128/audio, 1=Mul1024/video) ;
+ 13bit STD buffer size (largest required buffer over all packets) ;/
+These packets are encapsulating the lower-level Video/Audio streams.
+
32bit START (000001xxh BDh-BFh=Special, C0h-DFh=Audio, E0h-EFh=Video);\6byte
+ 16bit Packet Length minus 6 (in bytes) (1..18, plus data) ;/
+ (2bit) Fixed (11b, indicates presence of stuffing) ;\optional 0..16byte
+ (6bit) Fixed (111111b) ;/
+ (2bit) Fixed (01b, indicates presence of buffer size) ;\
+ (1bit) STD Buffer Scale (0=Mul128/audio, 1=Mul1024/video) ; optional 2byte
+ (13bit) STD Buffer Size (for decoding, in above scale units) ;/
+ 2bit Fixed (00b, indicates no further stuffing/buffer info);\
+ 1bit PTS Flag (Presentation Time Stamp) ; 0.5 bytes
+ 1bit DTS Flag (Decoding Time Stamp) ;/
+ (3bit) Presentation Time Stamp, bit32-30 ;\
+ (1bit) Marker (1) ; optional 4.5 bytes
+ (15bit) Presentation Time Stamp, bit29-15 ; (time when to output the
+ (1bit) Marker (1) ; the packet to audio/video
+ (15bit) Presentation Time Stamp, bit14-0 ; hardware, in 90kHz cycles)
+ (1bit) Marker (1) ;/
+ (4bit) Fixed (0001b) ;\
+ (3bit) Decoding Time Stamp, bit32-30 ; optional 5 bytes
+ (1bit) Marker (1) ; (recommended time when
+ (15bit) Decoding Time Stamp, bit29-15 ; to decode the block,
+ (1bit) Marker (1) ; in 90kHz cycles)
+ (15bit) Decoding Time Stamp, bit14-0 ;
+ (1bit) Marker (1) ;/
+ (4bit) Fixed (1111b) ;-optional 0.5 bytes
+ ... packet data bytes ;-data...(not crossing sector)
+ 32bit END_CODE (000001B9h) ;-4byte
+The Video stream is part of the Multiplex stream, meaning that the Video
+packets preceeded (and interrupted) by Multiplex headers. Ie. before processing
+the Video packets, one must first extract the video snippets from the Multiplex
+stream (see previous chapter).
32bit SEQUENCE_HEADER_CODE (000001B3h) ;-4byte
+ 12bit Width in pixels (1..4095) ;\3byte
+ 12bit Height in pixels (1..2800, for max AFh slices) ;/
+ 4bit Aspect Ratio (01h..0Eh, see below) ;\1byte
+ 4bit Framerate (01h..08h, see below) ;/
+ 18bit Bitrate (in 400bit/s units, 3FFFFh=variable rate) ;\
+ 1bit Marker (1) ; 3byte
+ 10bit VBV (required decoding memory size, in "16 kB" units) ; +6bit
+ 1bit Constrained Parameter Flag ;/
+ 1bit Load Intra Q Matrix (0=No, use Standard Matrix, 1=Yes, Custom)
+ (64byte) Intra Quantizer Matrix (64 x 8bit, unsigned) (in zigzag order)
+ 1bit Load Non-Intra Q Matrix (0=No, use Standard Matrix, 1=Yes, Custom)
+ (64byte) Non-Intra Quantizer Matrix (64 x 8bit, unsigned) (in zigzag order)
+ 0 - ;forbidden
+ 1 1.0 ;square pixels
+ 2 0.6735 ;0.6735
+ 3 0.7031 ;16:9, 625 line, PAL
+ 4 0.7615 ;0.7615
+ 5 0.8055 ;0.8055
+ 6 0.8437 ;16:9, 525 line, NTSC
+ 7 0.8935 ;0.8935
+ 8 0.9157 ;4:3, 625 line, PAL, CCIR601
+ 9 0.9815 ;0.9815
+ 10 1.0255 ;1.0255
+ 11 1.0695 ;1.0695
+ 12 1.0950 ;4:3, 525 line, NTSC, CCIR601
+ 13 1.1575 ;1.1575
+ 14 1.2015 ;1.2015
+ 15 - ;reserved
+ 0 - ;forbidden
+ 1 23.976 (24000/1001) ;NTSC encapsulated film rate
+ 2 24.0 ;Standard international cinema film rate
+ 3 25.0 ;PAL video frame rate (625/50)
+ 4 29.97 (30000/1001) ;NTSC video frame rate
+ 5 30.0 ;NTSC video frame rate drop-frame (525/60)
+ 6 50.0 ;PAL double frame rate/progressive
+ 7 59.94 (60000/1001) ;NTSC double frame rate
+ 8 60.0 ;NTSC double frame rate drop-frame
+ 9-15 - ;reserved
+ 32bit GROUP_START_CODE (000001B8h)
+ 1bit Drop Frame (1=drop this frame; for reducing 30 fps to 29.97 fps)
+ 5bit Time Code Hours (0..23)
+ 6bit Time Code Minutes (0..59)
+ 1bit Marker (1)
+ 6bit Time Code Seconds (0..59)
+ 6bit Time Code Picture (0..59)
+ 1bit Closed GOP
+ 1bit Broken Link
+ 32bit PICTURE_START_CODE (00000100h) ;\
+ 10bit Temporal Reference (display order, 0..3FFh) ; 61bit
+ 3bit Coding Type (0=Invalid, 1=I, 2=P, 3=B, 4=D, 5-7=Reserved);
+ 16bit VBV Delay (in 90kHz cycles, FFFFh=variable bitrate) ;/
+ (1bit) full fel forward vector (0=half pix, 1=full pix) ;\optional 4bit
+ (3bit) forward f code (0=invalid, 1..7=0..6bits) ;/
+ (1bit) full backward vector ;\optional 4bit
+ (3bit) backward f code ;/
+ (1bit) Fixed (1, indicates presence of Extra Info) ;\opt. N*9bit
+ (8bit) Extra Information ;/
+ 1bit Fixed (0, indicates no further Extra Info) ;-1bit
+ 0-7bit Padding to byte boundary (0) ;-0..7bit
+ 0 Forbidden
+ 1 I - Intra Coded (full image)
+ 2 P - Predictive Coded (based on prev I or P frame)
+ 3 B - Bidirectionally Predictive Coded (based on prev+next I or P frame)
+ 4 D - DC Intra Coded (don't care, lowres thumbnail)
+ 5 Reserved
+ 6 Reserved
+ 7 Reserved
+ DISPLAY ORDER:
+ I B B B P B B B P B B B P B B B I B B B P B B B P B B B P B B B ...
+ | |_______|_______| | |_______|_______|
+ | | | |
+ I-Frame P-frames I-Frame P-frames
+ STORAGE ORDER:
+ I P B B B P B B B P B B B I B B B P B B B P B B B P B B B ...
+ | |_______|_______| | |_______|_______|
+ | | | |
+ I-Frame P-frames I-Frame P-frames
+Slices are containing the actual 16x16 pixel Macro Blocks. Usually a Slice
+contains one horizontal line - although, theoretically, it could be longer or
+shorter, ie. a slice could wrap to next line, or a line could be split into
+several slices (with the leading "MBA Increment" value greater than 1 to define
+the horizontal start offset).
+
32bit PACK_START_CODE (000001xxh; xx=01h..AFh; vertical index) ;-4byte
+ 5bit Quantizer Scale (1..31) (may be later changed by blocks) ;-5bit
+ (1bit) Fixed (1, indicates presence of Extra Info) ;\opt. N*9bit
+ (8bit) Extra Information ;/
+ 1bit Fixed (0, indicates no further Extra Info) ;-1bit
+ ... Macroblock (within horizontal line) ;...
+ 0-7bit Padding to byte boundary (0) ;-0..7bit
+ 32bit START_CODE (000001B2h=User Data, 000001B5h=Extension Data) ;-4byte
+ ... data (end is signaled by presence of next 000001xxh code) ;-data
+ 32bit SEQUENCE_END_CODE (000001B7h) ;-4byte
+ N*11bit Macroblock_address_increase escape/stuffing codes (if any)
+ 1..11bit Macroblock_address_increase
+ 1-6bit Macroblock_type
+ 5bit Quantizer_scale
+ ... Motion_vector
+ 3-9bit Coded_block_pattern
+ ... Block(i)
+ Addr Incr
+ Type
+ Motion Vector
+ QScale
+ CBP
+ Block b0 (Y1)
+ Block b1 (Y2)
+ Block b2 (Y3)
+ Block b3 (Y4)
+ Block b4 (Cb)
+ Block b5 (Cr)
+VCD video discs and .mpg movie files are having the MP2 Audio Stream enclosed
+in the Multiplex stream (whilst .mp2 audio files may contain raw MP2 data
+without Multiplex stream).
Each MP2 frame is starting with a FFFh syncword (which is always located on a
+byte boundary). Unfortunately, the value FFFh can also occur anywhere in the
+audio data (eg. a 16bit sample with value 3FFCh).
+So, when starting mid-stream, one will need some guessing when searching a
+valid syncword. The best method is to compute the frame size (based on the
+supposed frame header), and then to check if supposed frame begins AND ends
+with a sync word. Moreover, one could check for invalid sample rate values in
+the frame header, or invalid "groupings" in the frame's data part.
+VCDs are conventionally having three audio frames encoded in one CDROM sector,
+so the first syncword can be simply found right after the multiplex packet
+header (though that might differ in some cases: VCD2.0 allows different audio
+bitrates, and a CDROM sector could be theoretically shared for Audio and Video
+data).
Header (32bit)
+ Optional CRC (16bit) (or 0bit if none)
+ Allocation Information
+ Scale Factor Selector Information
+ Scale Factors
+ Data
+ 12bit Syncword (FFFh) ;\
+ 1bit Revision (0=MPEG-2, 1=MPEG-1) ; 2 bytes
+ 2bit Layer (2=Audio LayerII) ;for VCDs ;
+ (3=LayerI, 1=LayerIII, 0=reserved) ;not on VCDs ;
+ 1bit Protection_bit (1=no crc) ;/
+ 4bit Bitrate_index (1..14) ;\
+ (0=free format, 15=reserved) ;
+ 2bit Sampling_frequency ; 1 byte
+ 1bit Padding_bit ;
+ 1bit Private_bit ;/
+ 2bit Mode ;\
+ 2bit Mode_extension (aka bound) ;
+ 1bit Copyright ; 1 byte
+ 1bit Original/home ;
+ 2bit Emphasis ;/
+ 16bit CRC
+ XXX...
+The Datel devices exist in various official/cloned hardware revisions, the DB25
+connector requires a special Comms Link ISA card (or a "FiveWire" mod for
+making it compatible with normal PC parallel ports). Later "PAR3" models are
+said to not require Comms Link, and do thus probably work directly with normal
+parallel ports).
+Cheat Devices - Datel I/O
+Cheat Devices - Datel DB25 Comms Link Protocol
+Cheat Devices - Datel Chipset Pinouts
+Cheat Devices - Datel Cheat Code Format
The FCD/Blaze devices are all same hardware-wise (with some cosmetic PCB
+revisions, and with extra SRAM and bigger FLASH installed in some carts). The
+DB25 connector can be directly connected to a PC parallel port.
+Cheat Devices - Xplorer Memory and I/O Map
+Cheat Devices - Xplorer DB25 Parallel Port Function Summary
+Cheat Devices - Xplorer DB25 Parallel Port Command Handler
+Cheat Devices - Xplorer DB25 Parallel Port Low Level Transfer Protocol
+Cheat Devices - Xplorer Versions
+Cheat Devices - Xplorer Chipset Pinouts
+Cheat Devices - Xplorer Cheat Code Format
+Cheat Devices - Xplorer Cheat Code and ROM-Image Decryption
http://gamehacking.org/faqs/hackv500c.html - cheat code formats
+http://doc.kodewerx.org/hacking_psx.html - cheat code formats
+http://xianaix.net/museum.htm - around 64 bios versions
+http://www.murraymoffatt.com/playstation-xplorer.html - xplorer bioses
First Digit Usage
+ 3,8 Same for Gameshark & Xplorer (for Xplorer: can be encrypted)
+ 1,2,C,D,E Gameshark
+ 4,6,7,9,B,F Xplorer
+ 0,5 Meaning differs for Gameshark & Xplorer
+ A Unused
+Codebreaker
+Megacom Power Replay III Game Enhancer
1F000000h-1F01FFFFh R/W Flash (first 128K)
+ 1F020010h R Comms Link STB pin state (bit0)
+ 1F020018h R Switch Setting (bit0: 0=Off, 1=On)
+ 1F040000h-1F05FFFFh R/W Flash (second 128K) + feedback area (see below)
+ 1F060000h R Comms Link data in (byte)
+ 1F060008h W Comms Link data out (byte, pulses ACK to Comms Link)
+Original PAR1 might have supported only 128K FLASH (?) if so, the I/O ports are
+probably same as above, but without the "second 128K" FLASH area.
The PAR3 version is said to work with parallel ports (not needing the Comms
+Link IDA card), and said to support more FLASH with bankswitching, so the I/O
+ports must work somehow entirely different as described above.
+Some notes from a (poorly translated) japanese document:
+PAR3 Memory:
+
1f000000-1f01ffff ROM. Change in bank switching.
+ 1f020000-1f03ffff ROM. Change in bank switching.
+ 1f040000-1f05ffff whopping RAM. It is able to use.
+ 1f060000-1f06003f I/O. Intently mirror to the subsequent 1f07ffff.
+ 1f060000 for reception. (1f060000 use only.) All bytes same treatment like.
+ It is 01h in the state that does not connected anything.
+ 1f060008 for transmission. (1f060008 use only.) This is ffh in the state
+ that does not connected anything.
+ 1f060010 during data reception it will stand the least significant bit.
+ Usually is fe.
+ 1f060018 state of the push button. In not pressed and fefefefefefefefe,
+ it will Ost ffffffffffffffff.
+ 1f060020 I think 1f060020 unused. It is ffffffffffffffff.
+ 1f060028 I think 1f060028 unused. It is ffffffffffffffff.
+ 1f060030 bank switching. 1 put and run-time of the ROM, and changes to the
+ 3's and the start-up of the ROM.
+ 1f060038 would be what? It is lbu. Like there is a meaning bits 0 and 1.
+ It was fcfcfcfcfcfcfcfc. I think that it is bank cult.
+The Boot Command Handler is executed once at Pre-Boot, and also (at least in
+some firmware versions) once before displaying the GUI. Following command(s)
+can be sent from PC side:
+
Repeatedly send 8bit "W", until receiving "R"
+ Repeatedly send 8bit "B", until receiving "W"
+ Send 8bit command "X" (upload/exec) or "U" (upload/flash), and receive ECHO
+ Send 32bit ADDRESS, and receive ECHO or "BX" (bad command)
+ Send 32bit LENGTH, and receive ECHO
+ Send DATA[LENGTH], and receive ECHO
+ Send 16bit CHECKSUM, and receive ECHO
+ (for upload/flash and if checksum was good, PSX will now BURN ADDR,LENGTH)
+ Send 16bit DUMMY, and receive "OK"/"BC"/"BF" (okay, bad chksum, bad flash)
+ (for upload/exec and if checksum was good, PSX will now CALL ADDR)
+ (thereafter, PAR2.0 and up will reboot via jmp BFC00000h)
+There must be some further command handler(s) after the Boot Command Handler,
+with support for additional cheat related commands, and (at least in Caetla)
+with support for uploading EXE files with Kernel functions installed (the Boot
+Command Handler at Pre-Boot time can also upload EXE code, but doesn't have
+Kernel installed).
+Original Datel commands for Menu/Game mode are unknown. The Caetla commands are
+documented in japanese, and there are also two english translations:
+http://www.psxdev.net/forum/viewtopic.php?f=49&t=370 - good (though
+incomplete)
+http://www.psxdev.net/forum/viewtopic.php?f=53&t=462#p6849 - very bad
+(beware)
There appear to be numerous Datel hardware revisions (and possibly numerous
+Datel clones). So this chapter is unlikely to cover all hardware revisions.
+
PSX Expansion cards:
+ PCB Controller FLASH DB25 spotted by
+ DATEL REF 1215 GAL + 74HC245 128K+128K yes Type79
+ DATEL REF 1288 DATEL ASIC1 256K yes nocash
+ DATEL xxx? GAL + PIC + HC245 128K yes CharlesMacD
+ noname? GAL + 74HC245 256K+0K yes Type79
+ DATEL REF 1324 lots of chips? lots? no CyrusDevX
+ DATEL REF 1326 lots of chips? lots? yes Type79
+ PS-121 ZISAN GAL + PIC? + HC245 128K yes Kryptonick
+ Comms Link ISA cards:
+ PCB Chipset spotted by
+ DATEL COMMS LINK, XXX? blurry SMD chipset? lowres photo
+ DATEL REF 1113, IBM SATURN LINK 1x74HC74, 2x74HC373, 1xXXX? Type79
+ EMS, PCCOM 1x74HC74, 2x74HC373, 1xXXX? jokergameth
+ DIY Alternatives to Comms Link
+ FiveWire ;simple hardware mod for use with parallel ports, for SPP/EPP
+ FreeWing ;parallel port adaptor, lots of 74xxx TTL chips, for SPP/EPP
+ ExStand ;parallel port adaptor, lots of 74xxx TTL chips, for EPP
+ CommLinkUSB ;USB adaptor, Buy-and-Diy technology (adafruit/teensy based)
+The ASIC1 chip is found in this hardware:
+
Label: "EQUALIZER, EVEN THE ODDS" (sticker on outside of case)
+ Case: "DATEL ENGLAND" (printed inside of case)
+ PCB: "DATEL REF1288 SONY SONYPSX2meg"
+ U: 44pin "DATEL, ASIC1, A8B1944A, 9832" ;custom logic chip
+ U: 32pin "SST, 29EE020, 150-4C-NH, 981918-D" ;256Kx8 EEPROM
+ U: 8pin "83BA, LM78L, 05ACM" ;5V voltage regulator
+ CN: 25pin DB25 connector (for Comms Link ISA card)
+ CN: 68pin PSX expansion port connector
+ SW: 3pin Switch
+ 7 D0 18 DB25.2.DATA0 29 D0 (same as pin7) 40 A3
+ 8 D1 19 DB25.3.DATA1 30 EERPROM./WE 41 A4
+ 9 D2 20 DB25.4.DATA2 31 /WR 42 /EXP
+ 10 GND 21 GND 32 GND 43 GND
+ 11 D3 22 DB25.5.DATA3 33 /RD 44 A17
+ 12 D4 23 DB25.6.DATA4 34 /MODE ("jumper") 1 A18
+ 13 D5 24 DB25.7.DATA5 35 VCC 2 GND
+ 14 VCC 25 VCC 36 DB25.11.ACK 3 VCC
+ 15 D6 26 DB25.8.DATA6 37 ? 4 EEPROM./OE
+ 16 VCC 27 DB25.9.DATA7 38 VCC 5 DB25.10.STB
+ 17 D7 28 EEPROM./CS 39 ? 6 SWITCH
+ 1-NC 8-NC 15-NC 22-NC
+ 2-FBIN 9-CPU.A4 16-GNDed 23-FLASH./WE
+ 3-CPU.A17 10-CPU./EXP 17-DB25.pin10 (PAR.STB) 24-FBOUT
+ 4-CPU./WR 11-CPU.A3 18-FLASH./CS 25-FLASH./OE (and BUF.DIR)
+ 5-CPU./RD 12-CPU.A5 19-DB25.pin11 (PAR.ACK) 26-BUF./EN
+ 6-CPU.A18 13-SWITCH 20-CPU.D0 27-unused
+ 7-CPU.A20 14-GND 21-FLASH.A17 28-VCC
+ 1-FBIN 7-CPU.A4.NC? 13-GNDed 19-FLASH./WE
+ 2-PIC.RC1 8-CPU./EXP.NC? 14-PAR.STB 20-FBOUT
+ 3-CPU./WR 9-CPU.A3 15-PIC.RA0 21-BUF.DIR
+ 4-CPU./RD 10-CPU.A2 16-PAR.ACK 22-BUF./OE
+ 5-CPU.A18 11-SWITCH 17-CPU.D0 23-PIC.RC0
+ 6-CPU.A17 12-GND 18-FLASH./OE 24-VCC
+ 1-FBIN 6-CPU.A17 11-CPU.A2 16-FBOUT
+ 2-SWITCH 7-CPU.A4.NC? 12-PAR.ACK 17-CPU.A20
+ 3-CPU./WR 8-CPU./EXP.NC? 13-CPU.D0 18-PAR.STB
+ 4-CPU./RD 9-CPU.A3 14-FLASH./OE 19-BUF./OE
+ 5-CPU.A18 10-GND 15-FLASH./WE 20-VCC
+PAL
+
1-/STATUS 7-ISA.A6 13-JP2 19-NC
+ 2-ISA.A1 8-ISA.A7 14-ISA.A9 20-PCWR
+ 3-ISA.A2 9-ISA.A8 15-NC 21-/PCRD
+ 4-ISA.A3 10-ISA.AEN 16-ISA./IOW 22-NC
+ 5-ISA.A4 11-JP1 17-/IRQ 23-ISA./IOR
+ 6-ISA.A5 12-GND 18-ISA.D0 24-VCC
+ Pin Parallel Port CommsLink (PC) cable PAR (PSX)
+ 1 /STB ----> "strobe" ----.---o-------------o-- -- NC
+ 2-9 DATA <-/----> DATA <-- | --o-------------o-------> DATA
+ 10 /ACK <---- "strobe" ----'---o-------------o-------> "strobe"
+ 11 BUSY <---- "ack" <-------o-------------o-------- "ack"
+ 12 PE <---- NC -- --o-------------o-- -- NC
+ 13 SLCT <---- NC -- --o-------------o-- -- NC
+ 14 /AUTOLF ----> NC -- --o-------------o--. .-- GNDed
+ 15 /ERROR <---- NC -- --o-------------o--. .-- GNDed
+ 16 /INIT ----> NC -- --o-------------o--. .-- GNDed
+ 17 /SELECT ----> GNDed --. .--o-------------o--. .-- GNDed
+ 18-25 GND ----- GND --'--'--o-------------o--'--'-- GND
+ disconnect DB25.pin14,15,16,17 from GND (may require to desolder the DB25)
+ repair any GND connections that were "routed through" above pins
+ wire DB25.pin1./STB to DB25.pin10./ACK
+ wire DB25.pin16./INIT to PSX.EXPANSION.pin2./RESET
+ wire DB25.pin15./ERROR to PSX.EXPANSION.pin28.A20
+ wire DB25.pin13.SLCT to PSX.EXPANSION.pin62.A21
+ wire DB25.pin12.PE to PSX.EXPANSION.pin29.A22
+ 30aaaaaa 00dd ;-8bit Write [aaaaaa]=dd
+ 80aaaaaa dddd ;-16bit Write [aaaaaa]=dddd
+ D0aaaaaa dddd ;-16bit/Equal If dddd=[aaaaaa] then (exec next code)
+ D1aaaaaa dddd ;-16bit/NotEqual If dddd<>[aaaaaa] then (exec next code)
+ D2aaaaaa dddd ;-16bit/Less If dddd<[aaaaaa] then (exec next code)
+ D3aaaaaa dddd ;-16bit/Greater If dddd>[aaaaaa] then (exec next code)
+ E0aaaaaa 00dd ;-8bit/Equal If dd=[aaaaaa] then (exec next code)
+ E1aaaaaa 00dd ;-8bit/NotEqual If dd<>[aaaaaa] then (exec next code)
+ E2aaaaaa 00dd ;-8bit/Less If dd<[aaaaaa] then (exec next code)
+ E3aaaaaa 00dd ;-8bit/Greater If dd>[aaaaaa] then (exec next code)
+ 10aaaaaa dddd ;-16bit Increment [aaaaaa]=[aaaaaa]+dddd
+ 11aaaaaa dddd ;-16bit Decrement [aaaaaa]=[aaaaaa]-dddd
+ 20aaaaaa 00dd ;-8bit Increment [aaaaaa]=[aaaaaa]+dd
+ 21aaaaaa 00dd ;-8bit Decrement [aaaaaa]=[aaaaaa]-dd
+ D4000000 dddd ;-Buttons/If If dddd=JoypadButtons then (exec next code)
+ D5000000 dddd ;-Buttons/On If dddd=JoypadButtons then (turn on all codes)
+ D6000000 dddd ;-Buttons/Off If dddd=JoypadButtons then (turn off all codes)
+ C0aaaaaa dddd ;-If/On If dddd=[aaaaaa] (turn on all codes)
+ 5000nnbb dddd ;\Slide Code aka Patch Code aka Serial Repeater
+ aaaaaaaa ??ee ;/for i=0 to nn-1, [aaaaaaaa+(i*bb)]=dddd+(i*??ee), next i
+ 00000000 0000 ;-Dummy (do nothing?) needed between slides (CD version only)
+ C1000000 nnnn ;-Delays activation of codes by nnnn (4000-5000 = 20-30 sec)
+ C2ssssss nnnn ;\Copy ssss bytes from 80ssssss to 80tttttt
+ 80tttttt 0000 ;/
+These are probably caetla-specific, not official Datel-codes. In fact, Caetla
+.341 itself might be an inofficial hacked version of Caetla .34 (?) so below
+might be totally inofficial stuff:
+
C3aaaaaa 0000 ;\Indirect 8bit Write [[aaaaaa]+bbbb]=dd
+ 9100bbbb 000000dd ;/
+ C3aaaaaa 0001 ;\Indirect 16bit Write [[aaaaaa]+bbbb]=dddd (Tomb Raider 2)
+ 9100bbbb 0000dddd ;/
+ C3aaaaaa 0002 ;\Indirect 32bit Write [[aaaaaa]+bbbb]=dddddddd
+ 9100bbbb dddddddd ;/
+ FFFFFFFF 0001 ;-Optional prefix for GameShark 2.2 codes(force non-caetla)
+ 12aaaaaa dddddddd ;-32bit Increment [aaaaaa]=[aaaaaa]+dddddddd
+ 22aaaaaa dddddddd ;-32bit Decrement [aaaaaa]=[aaaaaa]-dddddddd
+A maximum of 30 increment/decrement codes can be used at a time.
+A maximum of 60 conditionals can be used at a time (this includes Cx codes).
+Increment/decrement codes should (must?) be used with conditionals.
+Unknown if greater/less conditionals are signed or unsigned.
+Unclear if greater/less compare dddd by [aaaaaa], or vice-versa.
+Unknown if 16bit codes do require memory alignment.
1F000000h-1F03FFFFh.RW First 256K of FLASH (fixed mapping)
+ 1F040000h-1F05FFFFh.RW Map-able: 2x128K FLASH or 4x128K SRAM (if any)
+ 1F060000h-1F060007h.xx I/O Ports
+ 1F060008h-1F06FFFFh Mirrors of I/O at 1F060000h..1F060007h
+ 1F070000h-1F07FFFFh Unused (open bus)
+ 1F005555h.W FLASH Cmd 1st/3rd byte ;\for first FLASH chip
+ 1F002AAAh.W FLASH Cmd 2nd byte ;/
+ 1F045555h.W FLASH Cmd 1st/3rd byte ;\for 2nd FLASH chip (if any)
+ 1F042AAAh.W FLASH Cmd 2nd byte ;/
+ 1F060000h.R I/O - Switch Setting (bit0: 0=Off, 1=On)
+ 1F060001h.R I/O - 8bit Data from PC (bit0-7)
+ 1F060001h.W I/O - 8bit Latch (Data to PC, and Memory Mapping)
+ 0 DB25.pin13.SLCT ;\
+ 1 DB25.pin12.PE ; used for data to PC
+ 2 DB25.pin11.BUSY ;/
+ 3 DB25.pin10./ACK ;-used for handshake to PC
+ 4 Memory Mapping (0=EEPROM, 1=SRAM)
+ 5 Memory Mapping (EEPROM A17 when A18=1)
+ 6 Memory Mapping (SRAM A17 or SRAM CE2)
+ 7 Memory Mapping (SRAM A18 or NC)
+ 1F060002h.R I/O - Handshake from PC (bit0) (DB25.pin17./SEL)
+ 1F060005h.W I/O - Unknown (used by Xplorer v4.52, set to 03h)
+ 1F060006h.R I/O - Unknown (used by Xplorer v4.52, bit0 used)
+ 1F060007h.R I/O - Unknown (used by Xplorer v4.52, bit0 used)
+ GetByteByAddr32 Tx(5702h,Addr32), Rx(Data8)
+ OldMenuBuReadFile Tx(5703h), TxFilename, RxDataFFEEh
+ OldMenuBuDeleteFile Tx(5704h), TxFilename
+ OldMenuBuWriteFile Tx(5705h), TxFilename, TxFiledata
+ OldMenuBuGetFileHdr Tx(5706h), TxFilename, Rx(00h,00h), RxTurbo, Rx(02h)
+ OldMenuBuOpenEvents Tx(5707h)
+ SetCop0Breakpoint Tx(5708h,Addr32,Mask32,Ctrl32) ;Menu: Dummy?
+ OldMenuBuCopyFile Tx(5709h), TxFilename ;to other memcard
+ OldMenuBuFormat Tx(570Ah,Port8)
+ OldMenuBuGetStatus2x Tx(570Bh), Rx(Stat8,Stat8) ;\different in old/new
+ NewMenuBuGetStatus1x Tx(570Bh,Port8), Rx(Stat8) ;/
+ MenuGetSetFlag Tx(570Ch), Rx(Flag8) ;get old flg, then set flg=01h
+ NewMenuBuReadSector Tx(570Dh,Port8,Sector16), Rx(Data[80h])
+ NewMenuBuWriteSector Tx(570Eh,Port8,Sector16,Data[80h])
+ NewRawExecute Tx(570Fh,Addr32) ;call Addr
+ MidMenuBuggedExecJump Tx(5710h,ORra32,ORgp32,ORsp32,pc32) ;aka r31,r28,r29,pc
+ MidMenuSendComment Tx(5711h,Len8,AsciiMessage[Len])
+ NewMenuFillVram Tx(5712h,Xloc32,Yloc32,Xsiz32,Ysiz32,FillValue32)
+ NewGetVram Tx(5713h,Xloc32,Yloc32), Rx(Data[800h]) ;32x32pix
+ NewGetSetIrqMask Tx(5714h), Rx(OldMask16), Tx(NewMask16) ;Menu: Dummy
+ NewSetVram Tx(5715h,Xloc8,Yloc8,Data[800h]) ;X/Y=div32 ;32x32pix
+ NewMenuGetFlgAndOrVal Tx(5716h), Rx(00h, or 01h,Val32) ;\
+ NewMenuGetTwoValues Tx(5717h), Rx(Val32,Val32) ;
+ NewMenu... Tx(5718h), ... ;
+ NewMenuGet2kGarbage Tx(5719h,Dummy32), Rx(Garbage[800h]) ; whatever
+ NewMenuGetSomeValue Tx(571Ah), Rx(Val32) ;
+ NewMenu... Tx(571Bh,Data[4]) ;similar to 5763h ;
+ NewMenuNoLongerSupp. Tx(571Ch) ;probably WAS supported someday ;/
+ GameAddCheatCode Tx(5741h,Addr32,Data16), Rx(Index8)
+ MenuReBootKernel Tx(5742h) ;jumps to BFC00000h
+ GameDelCheatCode Tx(5744h,Index8)
+ GetMem Tx(5747h,Addr32,Len32), Rx(Data[Len]), TxRxChksum
+ Lock/Freeze Tx(574Ch)
+ OldMenuBuGetDirectory Tx(574Dh), RxTurbo
+ MenuTestDB25Handshake Tx(574Eh), ...
+ MenuOptimalGetMem Tx(574Fh,Addr32,Len32), RxFaster(Data[Len]), TxRxChksum
+ OldMenuGetWhatever Tx(5750h), RxDataFFEEh ;-whatever
+ Release/Unfreeze Tx(5752h)
+ SetMem Tx(5753h,Addr32,Len32,Data[Len]), TxRxChksum
+ TurboGetMem Tx(5754h,Addr32,Len32), RxFast(Data[Len]), TxRxChksum
+ MenuSetMemAndBurnFirm Tx(5755h,Addr32,Len32,Data[Len]), TxRxChksum ;burnFlash
+ GetStateGameOrMenu Tx(5757h), Rx(47h=Game, or 58h=Menu)
+ SetMemAndExecute Tx(5758h,Addr32,Len32,Data[Len]), TxRxChksum ;call Addr
+ NewMenu... Tx(5763h,Val32) ;similar to 571Bh ;-whatever
+ GetByteByAddr24 Tx(5767h,Addr24), Rx(Data8)
+ NewMenuBuggedExecJump Tx(577Ah,ORra32,ORgp32,ORsp32,pc32) ;formerly 5710h
+ NewMenuFlashAndReboot Tx(57C7h,Dest32,Len32,DataXorD3h[Len])
+The only useful command is SetMemAndExecute, which works in ALL versions, and
+which can be used to do whatever one wants to do (unfortunately, most of the
+official & inoffical tools are relying on other weird commands, which are
+working only with specific xplorer firmware versions).
The command handler is called once and then during booting, during xplorer GUI,
+and during Game execution.
+Each call to the command handler does allow to execute ONLY ONE command,
+however, the "Freeze" command can be used to force the xplorer to stay in the
+command handler, so one can send MORE commands, until leaving the command
+handler by sending the "Unfreeze" command.
+The command handling can vary depending on current boot phase (see below
+cautions on Pre-Boot, Mid-Boot, and In-Game phases).
This is called shortly after the kernel has done some basic initialization, and
+after the xplorer has relocated its EEPROM content to RAM (which means it may
+called about a second after reset when using official PSX kernel and Xplorer
+Firmware).
+
OLD Explorer Firmware: Call command handler ONCE (in MENU mode)
+ NEW Explorer Firmware: Call command handler TWICE (in MENU mode)
+ if SWITCH=ON or [80000030h]="WHB." then
+ NEW Explorer Firmware: Call command handler ONCE AGAIN (in MENU mode)
+ Install Mid-Boot hook
+ endif
+The Xplorer GUI is called only if the Pre-Boot handler has installed it (eg. if
+the SWITCH was ON). The handler is called alongsides with joypad reading (which
+does NOT take place during the Xplorer intro, so there will be a long dead spot
+between Pre-Boot and Mid-Boot command handling).
+
Call command handler ONCE (in MENU mode) alongsides with each joypad read
+This is called when starting CDROM booting.
+
Install GAME mode hook for the B(17h) ReturnFromException() handler
+ OLD Explorer Firmware: Call command handler ONCE (still in MENU mode)
+ NEW Explorer Firmware: Call command handler ONCE (already in GAME mode)
+This is called via the hooked B(17h) ReturnFromException() handler.
+
if SWITCH=ON
+ Call command handler ONCE (in GAME mode) upon each B(17h)
+ And, process game cheat codes (if any) upon each B(17h)
+ endif
+All 16bit/24bit/32bit parameters are transferred MSB first.
Output 8bit data to DATA0-7 (DB25.pin2-9) ;-Send Data (D0-D7)
+ Output /SEL=HIGH (DB25.pin17) ;\Handshake High
+ Wait until /ACK=HIGH (DB25.pin10) ;/
+ Output /SEL=LOW (DB25.pin17) ;\Handshake Low
+ Wait until /ACK=LOW (DB25.pin10) ;/
+ Wait until /ACK=HIGH (DB25.pin10) ;\
+ Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 1st Part (D6,D7,HIGH)
+ Output /SEL=HIGH (DB25.pin17) ;/
+ Wait until /ACK=LOW (DB25.pin10) ;\
+ Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 2nd Part (D3,D4,D5)
+ Output /SEL=LOW (DB25.pin17) ;/
+ Wait until /ACK=HIGH (DB25.pin10) ;\
+ Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 3rd Part (D0,D1,D2)
+ Output /SEL=HIGH (DB25.pin17) ;/
+ Wait until /ACK=LOW (DB25.pin10) ;\4th Part (ver,LOW,LOW)
+ Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; (ver=LOW for v1.091)
+ Output /SEL=LOW (DB25.pin17) ;/ (ver=HIGH for v4.52)
+ Wait until all 4bits LOW (DB25.pin13,12,11,10);-xlink95 fails if not
+First, for invoking the Turbo transfer:
+
Wait for BUSY=LOW (DB25.pin11)
+ Output DATA = 00h (DB25.pin2-9)
+ Wait for BUSY=HIGH (DB25.pin11)
+ Output DATA = ECh (DB25.pin2-9)
+ Wait for /ACK transition (DB25.pin10) ;\
+ Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 1st Part (D6,D7,LOW)
+ Output DATA = 02h (DB25.pin2-9) ;/
+ Wait for /ACK transition (DB25.pin10) ;\
+ Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 2nd Part (D3,D4,D5)
+ Output DATA = 04h (DB25.pin2-9) ;/
+ Wait for /ACK transition (DB25.pin10) ;\
+ Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 3rd Part (D0,D1,D2)
+ Output DATA = 01h (DB25.pin2-9) ;/
+First, for invoking the Turbo transfer:
+
Output DATA = 00h ;<-- crap (DB25.pin2-9) ;-BUGGY, but REQUIRED
+ Get 4bit from SLCT,PE,BUSY,/ACK (DB25.pin13,12,11,10);\1st Part (D4,D5,D6,D7)
+ Output DATA = 00h (DB25.pin2-9) ;/
+ Get 4bit from SLCT,PE,BUSY,/ACK (DB25.pin13,12,11,10);\2nd Part (D0,D1,D2,D3)
+ Output DATA = 01h (DB25.pin2-9) ;/
+ Tx(chkMsb), Rx(chkMsb), Tx(chkLsb), Rx(chkLsb), Rx("OK" or "CF" or "BG")
+ Rx(Addr32), Tx(Addr32,Len32,Data[Len]), TxRxChksum
+ Rx(Filename[26h]) ;-name from TxFilename, echo'ed back
+ Rx(Addr32) ;-buffer address for fragments
+ Tx(NumFragments8) ;-number of fragments
+ Tx(Addr32,Len32,Data[Len]), TxRxChksum ;<-- repeat this for each fragment
+ Rx(FileHandle8) ;-ending dummy byte (filehandle)
+ Rx(FFEEh,"W",Len32,Data[Len] ;<-- can be repeated for several fragments
+ Rx(FFEEh,"CA") ;<-- End Code (after last fragment)
+ Rx(Addr32), Tx(Addr32,Len32), RxFast(Data[Len]), TxRxChksum
+ Xploder (Germany/USA)
+ Xplorer (England/Spain/Netherlands)
+ X-Terminator (Japan)
+ V1/V2/V3 normal boards (256K EEPROM, no SRAM, no DB25 resistor)
+ FX/DX extended boards (512K EEPROM, 128K SRAM, with DB25 resistor)
+ PRO meaningless suffix
+ 1) PXT6 ;original board
+ 2) Nameless ;with alternate solder pads for smaller SRAM/GAL
+ 3) PXT6-3 ;with alternate solder pads for smaller SRAM/GAL and 2nd EEPROM
+The three PCB versions are functionally identical, and do differ only by
+cosmetic changes for alternate/smaller chip packages.
+However, some things that can make difference in functionality are the
+installed components and installed firmware version:
+
- FX carts have some extra components & more memory installed.
+ (needed for "bigger" firmwares, mainly needed for the X-Assist add-on)
+ - FLASH chips from different manufacturers can occassionally cause problems
+ (eg. older software not knowing how to program newer FLASH chips).
+ - DB25 transfer protocol has some changed commands in each firmware version
+ (and most transfer tools tend to rely on such commands, so most tools will
+ fail unless the cart is flashed with a certain firmware version).
+The X-Assist is a quity huge clumsy controller with DPAD, plus 4 buttons, plus
+small LCD screen. The thing connects to the Xplorer's DB25 connector, allowing
+to enter/search cheat codes without using a PC.
+The device works only with "FX" Xplorer boards (which contain an extra resistor
+for outputting supply power on the DB25 connector, plus more memory which is
+somewhat intended for use by the X-Assist thing).
1 IN0 (DB25.pin17./SEL)
+ 2 IN1 (PSX.pin14.A0)
+ 3 IN2 (PSX.pin48.A1)
+ 4 IN3 (PSX.pin15.A2)
+ 5 IN4 (74373.pin15.Q5)
+ 6 IN5 (PSX.pin4./EXP)
+ 7 IN6 (74373.pin12.Q4)
+ 8 IN7 (PSX.pin26.A16) (EEPROM.pin2.A16) (SRAM.pin2.A16) (10000h)
+ 9 IN8 (PSX.pin60.A17) (20000h)
+ 10 IN9 (PSX.pin27.A18) (EEPROM.pin1.A18 or NC) (40000h)
+ 11 IN10 (PSX.pin30./RD)
+ 12 GND
+ ---
+ 13 IN11 (GND)
+ 14 IN12 (/SWITCH_ON)
+ 15 IO (74373.pin11.LE)
+ 16 IO (PSX.pin6.D0)
+ 17 IO (SRAM./CE.pin22)
+ 18 IO (EEPROM2./CE.pin22) (for 2nd EEPROM chip, if any)
+ 19 IO (EEPROM1./CE.pin22) (for 1st EEPROM chip)
+ 20 IO (NC) (reportedly has wire?)
+ 21 IO (EEPROM.pin30.A17) (reportedly A14 ?)
+ 22 IO (74245.pin19./E)
+ 23 IN13 (PSX.pin64./WR) (SRAM.29, EEPROM.31)
+ 24 VCC
+ 1 /OE (GND)
+ 2 Q0 (DB25.pin13.SLCT)
+ 3 D0 (PSX)
+ 4 D1 (PSX)
+ 5 Q1 (DB25.pin12.PE)
+ 6 Q2 (DB25.pin11.BUSY)
+ 7 D2 (PSX)
+ 8 D3 (PSX)
+ 9 Q3 (DB25.pin10./ACK)
+ 10 GND
+ 11 LE (GAL.pin15.LatchEnable)
+ 12 Q4 (GAL.pin7) (0=EEPROM, 1=SRAM)
+ 13 D4 (PSX)
+ 14 D5 (PSX)
+ 15 Q5 (GAL.pin5) (EEPROM bank 2/3)
+ 16 Q6 (SRAM.pin30.A17 or CE2)
+ 17 D6 (PSX)
+ 18 D7 (PSX)
+ 19 Q7 (SRAM.pin1.A18 or NC)
+ 20 VCC
+ 1 DIR (GNDed)
+ 2 D7 (PSX)
+ 3 D6 (PSX)
+ 4 D5 (PSX)
+ 5 D4 (PSX)
+ 6 D3 (PSX)
+ 7 D2 (PSX)
+ 8 D1 (PSX)
+ 9 D0 (PSX)
+ 10 GND
+ 11 D0 (DB25.pin2)
+ 12 D1 (DB25.pin3)
+ 13 D2 (DB25.pin4)
+ 14 D3 (DB25.pin5)
+ 15 D4 (DB25.pin6)
+ 16 D5 (DB25.pin7)
+ 17 D6 (DB25.pin8)
+ 18 D7 (DB25.pin9)
+ 19 /E (GAL.pin22)
+ 20 VCC
+ 1 5V (VCC)
+ 2 GND (GND)
+ 3 7.5V (PSX.pin18,52)
+ OFF NC
+ COM PAL.pin14 (with 10K pull-up to VCC)
+ ON GND
+ 1 In /STB (NC)
+ 2 In DATA0 (74245.pin11)
+ 3 In DATA1 (74245.pin12)
+ 4 In DATA2 (74245.pin13)
+ 5 In DATA3 (74245.pin14)
+ 6 In DATA4 (74245.pin15)
+ 7 In DATA5 (74245.pin16)
+ 8 In DATA6 (74245.pin17)
+ 9 In DATA7 (74245.pin18)
+ 10 Out /ACK (74373.Q3)
+ 11 Out BUSY (74373.Q2)
+ 12 Out PE (74373.Q1)
+ 13 Out SLCT (74373.Q0)
+ ---
+ 14 In /LF (NC)
+ 15 Out /ERR (VCC via 0.47ohm) (installed only on carts with SRAM)
+ 16 In /INIT (NC)
+ 17 In /SEL (GAL.IN0.pin1)
+ 18..25 GND (Ground)
+EEPROM.pin1 is NC on 256Kx8 chip (however it is wired to A18 for use with
+512Kx8 chips).
+EEPROM.pin30 is A17 from GAL.pin21 (not from PSX.A17), accordingly GAL.pin21 is
+EEPROM.A17 (not A14).
+Boards with solder pads for TWO EEPROMs are leaving A18 not connected on the
+2nd EEPROM (but do connect A18 to the first EEPROM, so one could either use one
+512K chip or two 256K chips).
+DB25.pin15./ERR is VCC via 0.47ohm (installed only on carts with SRAM, intended
+as supply for the X-ASSIST thing).
+SRAM (if any) is wired to GAL.pin17 (/CE), 74373.Q6 (A17 or CE2), 74373.Q7 (A18
+or NC), other SRAM pins are wired straight to D0-D7, A0-A16, /RD, /WR.
+VCC is 5V, derived from a 7805 voltage converter (with 7.5V used as input).
+Existing boards seem to have 128K SRAM (if any), so SRAM A17/A18 aren't
+actually used (unless a board would have 512K SRAM), however, for 128K SRAMs
+one should switch SRAM CE2 (aka A17) high.
3taaaaaa 00dd ;-8bit write [aaaaaa]=dd
+ 8taaaaaa dddd ;-16bit write [aaaaaa]=dddd
+ 00aaaaaa dddd ;-32bit write [aaaaaa]=0000dddd <-- not "0taaaaaa dddd" ?
+ 4t000000 000x ;-Slow Motion (delay "x" whatever/ns,us,ms,frames?)
+ 7taaaaaa dddd ;-IF [aaaaaa]=dddd then <execute following code>
+ 9taaaaaa dddd ;-IF [aaaaaa]<>dddd then <execute following code>
+ Ftaaaaaa dddd ;-IF [aaaaaa]=dddd then activate "other selected" codes (uh?)
+ 5taaaaaa ?nnn ;\
+ d0d1d2d3 d4d5 ; write "?nnn" bytes to [aaaaaa] ;ordered d0,d1,d2... ?
+ d6d7d8.. .... ;/
+ 6t000000 nnnn ;\COP0 hardware breakpoint
+ aaaaaaaa cccc ; aaaaaaaa=break_address, mmmmmmmm=break_mask
+ mmmmmmmm d0d1 ; nnnn=num_bytes (d0,d1,d2,etc.), cccc=break_type (see below)
+ d2d3d4.. .... ;/
+ B?nnbbbb eeee ;\Slide/Patch Code, with unclear end: "end=?nn+/-1" ?
+ 10aaaaaa dddd ;/for i=0 to end, [aaaaaa+(i*bbbb)]=dddd+(i*eeee), next i
+ C0aaaaaa dddd ;-garbage/mirror of 70aaaaaa dddd ? ;\or maybe meant to be
+ D0aaaaaa dddd ;-garbage/mirror of 70aaaaaa dddd ? ;/same as on GameShark?
+ E180 (instruction gotton by CPU but not yet implemented) (uh, gotton what?)
+ EE80 (data to be read or written) ;<--looks okay
+ E680 (data to be read) ;<--looks okay
+ EA80 (data to be wrtten) ;<--looks okay
+ EF80 (instruction) ;<-- looks crap, should be probably E180
+The "Slide" code shall be used only with even addresses, unknown if other
+16bit/32bit codes do also require aligned addresses.
key = x[0] and 07h ;'''''''' AABBCCDD EEFF '''''''';
+ x[0] = x[0] xor key ; / / / \ \ \ ;
+ if key=0 ; x[0] --' / / \ \ '-- x[5] ;
+ ;unencrypted (keep as is) ; x[1] ---' / \ '--- x[4] ;
+ elseif key=4 ; x[2] ----' '----- x[3] ;
+ x[1] = x[1] xor (025h) ;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,;
+ x[2] = x[2] xor (0FAh + (x[1] and 11h))
+ x[3] = x[3] xor (0C0h + (x[2] and 11h) + (x[1] xor 12h))
+ x[4] = x[4] xor (07Eh + (x[3] and 11h) + (x[2] xor 12h) + x[1])
+ x[5] = x[5] xor (026h + (x[4] and 11h) + (x[3] xor 12h) + x[2] + x[1])
+ elseif key=5
+ x[1] = (x[1] + 057h) ;"W"ayne
+ x[2] = (x[2] + 042h) ;"B"eckett
+ x[3] = (x[3] + 031h) ;"1"
+ x[4] = (x[4] + 032h) ;"2"
+ x[5] = (x[5] + 033h) ;"3"
+ elseif key=6
+ x[1] = (x[1] + 0ABh) xor 01h
+ x[2] = (x[2] + 0ABh) xor 02h
+ x[3] = (x[3] + 0ABh) xor 03h
+ x[4] = (x[4] + 0ABh) xor 04h
+ x[5] = (x[5] + 0ABh) xor 05h
+ elseif key=7
+ x[5] = x[5] + 0CBh
+ x[4] = x[4] + 0CBh + (x[5] and 73h)
+ x[3] = x[3] + 05Ah + (x[4] and 73h) - (x[5] xor 90h)
+ x[2] = x[2] + 016h + (x[3] and 73h) - (x[4] xor 90h) + x[5]
+ x[1] = x[1] + 0F5h + (x[2] and 73h) - (x[3] xor 90h) + x[4] + x[5]
+ else
+ error ;(key=1,2,3)
+ endif
+ for i=0 to romsize-1
+ x=45h
+ y=(i and 37h) xor 2Ch
+ if (i and 001h)=001h then x=x xor 01h
+ if (i and 002h)=002h then x=x xor 01h
+ if (i and 004h)=004h then x=x xor 06h
+ if (i and 008h)=008h then x=x xor 04h
+ if (i and 010h)=010h then x=x xor 18h
+ if (i and 020h)=020h then x=x xor 30h
+ if (i and 040h)=040h then x=x xor 60h
+ if (i and 080h)=080h then x=x xor 40h
+ if (i and 100h)=100h then x=x xor 80h
+ if (i and 006h)=006h then x=x xor 0ch
+ if (i and 00Eh)=00Eh then x=x xor 08h
+ if (i and 01Fh)>=016h then x=x-10h
+ rom[i]=(rom[i] XOR x)+y
+ next i
+Below commands should work on all chips (for write: page size may vary, eg. 1
+byte, 128 bytes, or 256 bytes). Some chips do have some extra commands (eg. an
+alternate older get id command, or sector erase commands, or config commands),
+but those extras aren't needed for basic erase/write operations.
+
[5555h]=AAh, [2AAAh]=55h, [5555h]=A0h, [addr..]=byte(s) ;write page
+ [5555h]=AAh, [2AAAh]=55h, [5555h]=90h, id=[0000h..0001h] ;enter id mode
+ [5555h]=AAh, [2AAAh]=55h, [5555h]=F0h ;exit id mode
+ [5555h]=AAh, [2AAAh]=55h, [5555h]=80h ;erase chip, step 1
+ [5555h]=AAh, [2AAAh]=55h, [5555h]=10h ;erase chip, step 2
+Waiting is required after chip erase and page write (after writing the last
+byte at page end), and on some chips it's also required after enter/exit id
+mode. Some chips indicate busy state via a toggle bit (bit6 getting inverted on
+each 2nd read), and/or by outputting a value different than the written data,
+and/or do require hardcoded delays (eg. AM29F040). Using the following 3-step
+wait mechanism should work with all chips:
+
Wait 10us (around 340 cpu cycles on PSX) ;-step 1, hardcoded delay
+ Wait until [addr]=[addr] ;-step 2, check toggle bit
+ Wait until [addr]=data ;-step 3, check data
+First of, one should detect the expansion board type, this can be done as so:
+
Enter Chip ID mode (at 1F000000h)
+ Compare 400h bytes at 1F000000h vs 1F020000h
+ If different --> assume Datel PAR1/PAR2 hardware
+ If same --> assume Xplorer hardware (or Datel PAR3, whatever that is)
+ Exit Chip ID mode (at 1F000000h)
+ Enter Chip ID mode (at 1F000000h)
+ Read the two ID bytes (at 1F00000xh)
+ Exit Chip ID mode (at 1F000000h)
+ If cart=xplorer AND 1st_chip=256K --> might have a 2nd 256K chip
+ If cart=datel AND 1st_chip=128K --> might have a 2nd 128K chip
+ Enter Chip ID (at 1F000000h) and Enter Chip ID (at 1F400000h) ;id1+id2
+ Exit Chip ID (at 1F000000h) and Enter Chip ID (at 1F400000h) ;id2
+ Exit Chip ID (at 1F400000h) and Enter Chip ID (at 1F000000h) ;id1
+ Exit Chip ID (at 1F400000h) and Exit Chip ID (at 1F000000h) ;none
+ If they are all same --> there is only one chip (mirrored to both areas)
+ If different --> 1F400000h is either garbage, or a 2nd chip
+ ChipID Kbyte Page Maker/Name ;notes
+ 1Fh,D5h 128K 128 ATMEL AT29C010A ;xplorer/prototypes?
+ 1Fh,35h 128K 128 ATMEL AT29LV010A ;-
+ 1Fh,DAh 256K 256 ATMEL AT29C020 ;xplorer
+ 1Fh,BAh 256K 256 ATMEL AT29BV020 ;xplorer
+ 1Fh,A4h 512K 256 ATMEL AT29C040A ;xplorer
+ 1Fh,C4h 512K 256 ATMEL AT29xV040A ;-
+ BFh,07h 128K 128 SST SST29EE010 ;-
+ BFh,08h 128K 128 SST SST29xE010 ;-
+ BFh,22h 128K 128 SST SST29EE010A ;-
+ BFh,23h 128K 128 SST SST29xE010A ;-
+ BFh,10h 256K 128 SST SST29EE020 ;xplorer
+ BFh,12h 256K 128 SST SST29xE020 ;xplorer
+ BFh,24h 256K 128 SST SST29EE020A ;-
+ BFh,25h 256K 128 SST SST2xEE020A ;-
+ BFh,04h 512K 256 SST SST28SF040 ;said to be used in "AR/GS Pro"
+ DAh,C1h 128K 128 WINBOND W29EE01x ;-
+ DAh,45h 256K 128 WINBOND W29C020 ;-
+ DAh,46h 512K 256 WINBOND W29C040 ;xplorer
+ 01h,A4h 512K 1 AMD AM29F040 ;nocash psone bios (intact console)
+ 20h,20h 128K 1 ST M29F010B ;nocash psone bios (broken console)
+ 31h,B4h 128K ?? CATALYST CAT28F010 ;NEEDS VPP=12V !!! ("PS-121 ZISAN")
+Controller and Memory Card Overview
+Controller and Memory Card Signals
+Controller and Memory Card Multitap Adaptor
Controllers - Communication Sequence
+Controllers - Standard Digital/Analog Controllers
+Controllers - Mouse
+Controllers - Racing Controllers
+Controllers - Lightguns
+Controllers - Configuration Commands
+Controllers - Vibration/Rumble Control
+Controllers - Analog Buttons (Dualshock2)
+Controllers - Dance Mats
+Controllers - Pop'n Controllers
+Controllers - Densha de Go! / Jet de Go! Controllers
+Controllers - Fishing Controllers
+Controllers - PS2 DVD Remote
+Controllers - I-Mode Adaptor (Mobile Internet)
+Controllers - Additional Inputs
+Controllers - Misc
Memory Card Read/Write Commands
+Memory Card Data Format
+Memory Card Images
+Memory Card Notes
Pinouts - Controller Ports and Memory-Card Ports
Controllers and memory cards connect to the console using a serial protocol and
+are accessed through SIO0 registers:
+Serial Interfaces (SIO)
+The protocol used is similar to standard SPI, with no start/stop bytes and no
+parity (even though SIO0 has support for it). Unlike typical SPI, only one byte
+is transferred at a time and a separate wire (/ACK) is used by the device to
+signal the PS1 that it is ready to exchange the next byte. For more details see:
+Controller and Memory Card Signals
Each controller port and its respective memory card slot are wired in parallel,
+and the /CSn signals select both the controller and the memory card when
+asserted. This selection is narrowed down through a simple addressing scheme,
+where the first byte sent by the console after asserting /CSn is the address of
+the device that shall reply. All devices must keep the DAT line idle before
+receiving this byte. Once the address is sent, the device that was addressed
+shall pull /ACK low to signal its presence and start exchanging bytes.
+The following addresses are known to be used:
| Device | +Address | +
|---|---|
| Standard controller | +01h |
+
| Yaroze Access Card | +21h |
+
| PS2 multitap (incompatible with PS1) | +21h |
+
| PS2 DVD remote receiver | +61h |
+
| Memory card | +81h |
+
Gets set after receiving a data byte - that only if an /ACK has been received
+from the peripheral (ie. there will be no IRQ if the peripheral fails to send
+an /ACK, or if there's no peripheral connected at all).
+
Actually, DSR means "more-data-request",
+ accordingly, it does NOT get triggered after receiving the LAST byte.
+Pin 8 on Controller Port. Routed directly to the Interrupt Controller (at
+1F80107xh). There are no status/enable bits in the SIO0_registers (at
+1F80104xh).
During plugging and unplugging, the Serial Data line may be dragged LOW for a
+moment; this may also affect other connected devices because the same Data line
+is shared for all controllers and memory cards (for example, connecting a
+joypad in slot 1 may corrupt memory card accesses in slot 2).
+Moreover, the Sony Mouse does power-up with /ACK=LOW, and stays stuck in that
+state until it is accessed at least once (by at least sending one 01h byte to
+its controller port); this will also affect other devices (as a workaround one
+should always access BOTH controller ports; even if a game uses only one
+controller, and, code that waits for /ACK=HIGH should use timeouts).
After sending a byte, the Kernel waits 100 cycles or so, and does THEN
+acknowledge any old IRQ7, and does then wait for the new IRQ7. Due to that
+bizarre coding, emulators can't trigger IRQ7 immediately within 0 cycles after
+sending the byte.
Controllers can be probably accessed via InitPad and StartPad functions,
+BIOS Joypad Functions
+Memory cards can be accessed by the filesystem (with device names "bu00:"
+(slot1) and "bu10:" (slot2) or so). Before using that device names, it seems to
+be required to call InitCard, StartCard, and _bu_init (?).
The data is transferred in units of bytes, via separate input and output lines.
+So, when sending byte, the hardware does simultaneously receive a response
+byte.
+One exception is the address byte (which selects either the controller,
+or the memory card) until that byte has been sent, neither the controller nor
+memory card are selected (and so the first "response" byte should be ignored;
+probably containing more or less stable high-z levels).
+The other exception is, when you have send all command bytes, and still want to
+receive further data, then you'll need to send dummy command bytes (should be
+usually 00h) to receive the response bytes.
____ _____
+ /CS \____________________________________________________________/
+ ______ ____ ____ ____ ____ _________
+ SCK |||||||| |||||||| |||||||| |||||||| ||||||||
+ ____ _____
+ MOSI '=[ Addr ]====[ Cmd ]====[ Tap ]====[Param ]====[Param ]==='
+
+ MISO ---------------===[ IDlo ]====[ IDhi ]====[ Data ]====[ Data ]===------
+ _______________ _________ _________ _________ _________________
+ /ACK |_| |_| |_| |_|
+
+--- High impedance
+=== Any state (don't care)
+ ____
+ /CS \__________________________________________________________________
+ ______ _ _ _ _ _ _ _ __________________ _ _ _ _
+ SCK |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
+ __________ ___
+ MOSI 1 |_0___0___0___0___0___0___0____________________0_| 1 |_0___0_
+ ____
+ MISO -----------------------------------------------=======' 1 |_0___0___0_
+ ______________________________________________ ____________________
+ /ACK |___|
+
+--- High impedance
+=== Any state (don't care)
+Notes:
+The Multitap is an external adaptor that allows to connect 4 controllers, and 4
+memory cards to one controller port. When using two adaptors (one on each
+slot), up to 8 controllers and 8 memory cards can be used.
Normally joypad reading is done by sending this bytes to the pad:
+
01 42 00 00 .. ;normal read
+ 01 42 01 00 .. ;method 1: receive special ID and data from ALL four pads
+ 0n 42 00 00 .. ;method 2: receive data from pad number "n" (1..4)
+Below LONG response is activated by sending "01h" as third command byte;
+observe that sending that byte does NOT affect the current response. Instead,
+it does request that the NEXT command shall return special data, as so:
+
Halfword 0 --> Controller ID for MultiTap (5A80h=Multitap)
+ Halfword 1..4 --> Player A (Controller ID, Buttons, Analog Inputs, if any)
+ Halfword 5..8 --> Player B (Controller ID, Buttons, Analog Inputs, if any)
+ Halfword 9..12 --> Player C (Controller ID, Buttons, Analog Inputs, if any)
+ Halfword 13..16 --> Player D (Controller ID, Buttons, Analog Inputs, if any)
+ Previous access had REQ=0 and returned Slot A data ---> returns Slot A data
+ Previous access had REQ=0 and returned Slot A-D data -> returns Slot A data
+ Previous access had REQ=1 and returned Slot A data ---> returns Slot A-D data
+ Previous access had REQ=1 and returned Slot A-D data -> returns garbage
+ Previous access had REQ=1 and returned garbage -------> returns Slot A-D data
+Normally memory card access is done by sending this bytes to the card:
+
80 xx .. .. ;normal access
+ 8n xx .. .. ;access memory card in slot "n" (1..4)
+ Bomberman / Bomberman Party Edition (requires Multitap on Port 2 instead of 1)
+ Bomberman World
+ Breakout: Off the Wall Fun
+ Circuit Breakers
+ Crash Team Racing
+ FIFA series soccer games
+ Frogger
+ Gauntlet: Dark Legacy
+ Hot Shots Golf 2 & 3
+ Jigsaw Island: Japan Graffiti / Jigsaw Madness (requires Multitap on Port 2 instead of 1)
+ NBA Live (any year) (up to 8 players with two multitaps)
+ Need For Speed 3
+ Need For Speed 5
+ Poy Poy (4 players hitting each other with rocks and trees)
+ Running Wild
+ S.C.A.R.S. (requires Multitap on Port 2 instead of 1)
+ Zen Nippon Pro Wrestling: Ouja no Tamashii (requires Multitap on Port 2 instead of 1)
+ .------.
+ SCPH-1070 | | SCPH-111
+ (gray case) | | (white case)
+ (for PSX) | D | (for PSone)
+ | | .----------------.
+ cable | | cable .' D C '.
+ ''--.. | C | '''--..__| |
+ \| | | |
+ .----------------' | '. A B .'
+ | | '----------------'
+ | |
+ | A B /
+ '---------------------'
+Halfword 0 is parsed (by the BIOS) as usually, ie. the LSB is moved to MSB, and
+LSB is replaced by status byte (so ID 5A80h becomes 8000h=Multitap/okay, or
+xxFFh=bad). Halfwords 1,5,9,13 are NOT parsed (neither by the BIOS nor by the
+Multitap hardware), however, some info in the internet is hinting that Sony's
+libraries might be parsing these IDs too (so for example 5A41h would become
+4100h=DigitalPad/okay, or xxFFh=bad).
The Multitap is powered by the PSX controller port. Unknown if there are any
+power supply restrictions (up to eight controllers and eight cards may scratch
+some limits, especially when doing things like activating rumble on all
+joypads). However, the Multitap hardware itself doesn't do much on supply
+restrictions (+3.5V is passed through something; maybe some fuse, loop, or 1
+ohm resistor or so) (and +7.5V is passed without any restrictions).
Sony made a multitap adapter for the PS2, however it is not compatible with the
+PS1 as it plugs into both the controller and memory card ports (which are not
+wired in parallel on the PS2). The protocol is also different: rather than
+modifying packets it seems to act as a mostly-passive port multiplexer,
+accepting switching commands with address 61h. Unknown if the PS2 multitap is
+backwards compatible with the SCPH-1070 protocol.
Pinouts - Component List and Chipset Pin-Outs for Multitap, SCPH-1070
Send Reply Comment
+ 01h Hi-Z Controller address
+ 42h idlo Receive ID bit0..7 (variable) and Send Read Command (ASCII "B")
+ TAP idhi Receive ID bit8..15 (usually/always 5Ah)
+ MOT swlo Receive Digital Switches bit0..7
+ MOT swhi Receive Digital Switches bit8..15
+ --- transfer stops here for digital pad (or analog pad in digital mode) ---
+ 00h adc0 Receive Analog Input 0 (if any) (eg. analog joypad or mouse)
+ 00h adc1 Receive Analog Input 1 (if any) (eg. analog joypad or mouse)
+ --- transfer stops here for analog mouse ----------------------------------
+ 00h adc2 Receive Analog Input 2 (if any) (eg. analog joypad)
+ 00h adc3 Receive Analog Input 3 (if any) (eg. analog joypad)
+ --- transfer stops here for analog pad (in analog mode) -------------------
+ --- transfer stops here for nonstandard devices (steering/twist/paddle) ---
+ 0-3 Number of following halfwords (01h..0Fh=1..15, or 00h=16 halfwords)
+ 4-7 Controller Type (or currently selected Controller Mode)
+ 8-15 Fixed (5Ah)
+ xx00h=N/A (initial buffer value from InitPad BIOS function)
+ 5A12h=Mouse (two button mouse)
+ 5A23h=NegCon (steering twist/wheel/paddle)
+ 5A31h=Konami Lightgun (IRQ10-type)
+ 5A41h=Digital Pad (or analog pad/stick in digital mode; LED=Off)
+ 5A53h=Analog Stick (or analog pad in "flight mode"; LED=Green)
+ 5A63h=Namco Lightgun (Cinch-type)
+ 5A73h=Analog Pad (in normal analog mode; LED=Red)
+ 5A7xh=Dualshock2 (with variable number of inputs enabled)
+ 5A79h=Dualshock2 (with all analog/digital inputs enabled)
+ 5A80h=Multitap (multiplayer adaptor) (when activated)
+ 5A96h=Keyboard (rare lightspan keyboard)
+ 5AE3h=Jogcon (steering dial)
+ 5AE8h=Keyboard/Sticks (rare homebrew keyboard/segasticks adaptor)
+ 5AF3h=Config Mode (when in config mode; see rumble command 43h)
+ FFFFh=High-Z (no controller connected, pins floating High-Z)
+ ___ ___ ___ ___
+ __/_L_\__ Analog Pad __/_R_\__ __/_L_\__ Digital Pad __/_R_\__
+ / _ \--------------/ \ / _ \--------------/ \
+ | _| |_ | | /\ | | _| |_ | | /\ |
+ | |_ X _| |SEL STA| [] () | | |_ X _| | | [] () |
+ | |_| ___ ANALOG ___ >< | | |_| | SEL STA | >< |
+ |\______ / L \ LED / R \ ______/| |\_________/--------------\_________/|
+ | | Joy |--------| Joy | | | | | |
+ | / \___/ \___/ \ | | / \ |
+ \____/ \____/ \____/ \____/
+ __Halfword 0 (Controller Info)_______________________________________________
+ 0-15 Controller Info (5A41h=digital, 5A73h=analog/pad, 5A53h=analog/stick)
+ __Halfword 1 (Digital Switches)______________________________________________
+ 0 Select Button (0=Pressed, 1=Released)
+ 1 L3/Joy-button (0=Pressed, 1=Released/None/Disabled) ;analog mode only
+ 2 R3/Joy-button (0=Pressed, 1=Released/None/Disabled) ;analog mode only
+ 3 Start Button (0=Pressed, 1=Released)
+ 4 Joypad Up (0=Pressed, 1=Released)
+ 5 Joypad Right (0=Pressed, 1=Released)
+ 6 Joypad Down (0=Pressed, 1=Released)
+ 7 Joypad Left (0=Pressed, 1=Released)
+ 8 L2 Button (0=Pressed, 1=Released) (Lower-left shoulder)
+ 9 R2 Button (0=Pressed, 1=Released) (Lower-right shoulder)
+ 10 L1 Button (0=Pressed, 1=Released) (Upper-left shoulder)
+ 11 R1 Button (0=Pressed, 1=Released) (Upper-right shoulder)
+ 12 /\ Button (0=Pressed, 1=Released) (Triangle, upper button)
+ 13 () Button (0=Pressed, 1=Released) (Circle, right button)
+ 14 >< Button (0=Pressed, 1=Released) (Cross, lower button)
+ 15 [] Button (0=Pressed, 1=Released) (Square, left button)
+ __Halfword 2 (Right joystick) (analog pad/stick in analog mode only)_________
+ 0-7 adc0 RightJoyX (00h=Left, 80h=Center, FFh=Right)
+ 8-15 adc1 RightJoyY (00h=Up, 80h=Center, FFh=Down)
+ __Halfword 3 (Left joystick) (analog pad/stick in analog mode only)__________
+ 0-7 adc2 LeftJoyX (00h=Left, 80h=Center, FFh=Right)
+ 8-15 adc3 LeftJoyY (00h=Up, 80h=Center, FFh=Down)
+ __Further Halfword(s) (Dualshock2 only, and only if enabled)_________________
+ 0-7 .. Analog Button (if enabled) (00h=Released, FFh=Max Pressure)
+ 8-15 .. Analog Button (if enabled) (00h=Released, FFh=Max Pressure)
+ .. .. ..
+On power-up, the controllers are in digital mode (with analog inputs disabled).
+Analog mode can be (de-)activated manually by pushing the Analog button.
+Alternately, analog mode can be (de-)activated by software via rumble
+configuration commands (though that's supported only on newer pads; those with
+two rumble motors). It is essential that emulators and any third-party hardware have a way of manually toggling analog mode, similar to original analog controllers, as certain games like Gran Turismo 1 will not attempt to enter analog mode on their own, even if they support analog controls and detect an analog controller.
+Since analog pads boot in digital mode and will return the same ID byte as digital controllers, the most common way of distinguishing between the 2 is to send a Dualshock-only command (Typically command 43h - enter/exit config mode) and seeing how the controller responds to it.
+The analog sticks are mechanically restricted to a "circular field of motion"
+(most joypads can reach "min/max" values only in "straight" horizontal or
+vertical directions, but not in "diagonal" directions).
...''''''''''...
+ ____ .''________________''._____ ___ 00h
+ | .'' ''. |
+ |.' '.| ___ 10h
+ .' '.
+ :| |:
+ : | | : ___ 60h
+ .' | .''''''. | '.
+ : | .' '. | :
+ : | : : | : ___ 80h
+ : | : : | :
+ : | '. .' | :
+ '. | '......' | .' ___ A0h
+ : | | :
+ :| |:
+ '. .' ___ F0h
+ |'. .'|
+ |__'..______________________..'__| ___ FFh
+ . '.. ..' .
+ 00h '''..........''' FFh
+ Big Circle --> Mechanically possible field of motion
+ Square Area --> Digitally visible 8bit field of motion
+ Small Circle --> Resting position when releasing the joystick
+ SCPH-1150 Min=(00,00), Mid: (72..90,79..AC), Max=(FF,FF) at 25'C
+ SCPH-1200 Min=(0E,0E), Mid: (6C..8A,75..79), Max=(ED,ED) at 16'C
+ SCPH-110 Min=(11,11), Mid: (8A..9F,70..96), Max=(FD,FD) at 16'C
+Basically same as normal analog LED=Red mode, with following differences:
+
ID is 5A53h (identifying itself as analog stick) (rather than analog pad)
+ Left/right joy-buttons disabled (as for real analog stick, bits are always 1)
+ Some buttons are re-arranged: bit9=L1 bit10=[] bit11=/\ bit12=R1 bit15=R2
+Pinouts - Component List and Chipset Pin-Outs for Digital Joypad, SCPH-1080
+Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-1150
+Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-1200
+Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-110
__Halfword 0 (Controller Info)________________
+ 0-15 Controller Info (5A12h=Mouse)
+ __Halfword 1 (Mouse Buttons)__________________
+ 0-7 Not used (All bits always 1)
+ 8-9 Unknown (Seems to be always 0) (maybe SNES-style sensitivity?)
+ 10 Right Button (0=Pressed, 1=Released)
+ 11 Left Button (0=Pressed, 1=Released)
+ 12-15 Not used (All bits always 1)
+ __Halfword 2 (Mouse Motion Sensors)___________
+ 0-7 Horizontal Motion (-80h..+7Fh = Left..Right) (00h=No motion)
+ 8-15 Vertical Motion (-80h..+7Fh = Up..Down) (00h=No motion)
+On Power-on (or when newly connecting it), the Sony mouse does draw /ACK to LOW
+on power-on, and does then hold /ACK stuck in the LOW position.
+For reference: Normal controllers and memory cards set /ACK=LOW only for around
+100 clk cycles, and only after having received a byte from the console.
+The /ACK pin is shared for both controllers and both memory cards, so the stuck
+/ACK is also "blocking" all other connected controllers/cards. To release the
+stuck /ACK signal: Send a command (at least one 01h byte) to both controller
+slots.
3D Lemmings
+ Alien Resurrection
+ Area 51
+ Ark of Time
+ Atari Anniversary Edition
+ Atlantis: The Lost Tales
+ Breakout: Off the Wall Fun
+ Broken Sword: The Shadow of the Templars
+ Broken Sword II: The Smoking Mirror
+ Clock Tower: The First Fear
+ Clock Tower II: The Struggle Within
+ Command & Conquer: Red Alert
+ Command & Conquer: Red Alert - Retaliation
+ Constructor (Europe)
+ Die Hard Trilogy
+ Die Hard Trilogy 2: Viva Las Vegas
+ Discworld
+ Discworld II: Missing Presumed...!?
+ Discworld Noir
+ Dune 2000
+ Final Doom
+ Galaxian 3
+ Ghoul Panic
+ Klaymen Klaymen: Neverhood no Nazon (Japan)
+ Lemmings and Oh No! More Lemmings
+ Monopoly
+ Music 2000
+ Myst
+ Neorude (Japan)
+ Perfect Assassin
+ Policenauts (Japan)
+ Puchi Carat
+ Quake II
+ Railroad Tycoon II
+ Rescue Shot
+ Risk
+ Riven: The Sequel to Myst
+ RPG Maker
+ Sentinel Returns
+ SimCity 2000
+ Syndicate Wars
+ Tempest 2000 (Tempest X3)
+ Theme Aquarium (Japan)
+ Transport Tycoon
+ Warhammer: Dark Omen
+ Warzone 2100
+ X-COM: Enemy Unknown
+ X-COM: Terror from the Deep
+ Z
+PCB "TD-T41V/\, MITSUMI"
+Component Side:
+
1x 3pin 4.00MHz "[M]4000A, 85 2"
+ 2x 2pin button (left/right)
+ 1x 8pin connector (to cable with shield and 7 wires)
+ 1x 3pin "811, T994I"
+ 2x 3pin photo transistor (black) ;\or so, no idea which one is
+ 2x 2pin photo diode (transparent) ;/sender and which is sensor
+ 1x 2pin electrolyt capacitor 16V, 10uF
+ 1x 32pin "(M), SC442116, FB G22K, JSAA815B"
+ 1x 14pin "BA10339F, 817 L67" (Quad Comparator)
+ 2x 3pin "LC" (amplifier for photo diodes)
+ 1x 3pin "24-" (looks like a dual-diode or so)
+ plus many SMD resistors/capacitors
+ PSX.Controller.Pin1 DAT ---- brown -- Mouse.Pin4
+ PSX.Controller.Pin2 CMD ---- red -- Mouse.Pin3
+ PSX.Controller.Pin3 +7.5V ---- N/A
+ PSX.Controller.Pin4 GND ---- orange -- Mouse.Pin7 GND (G)
+ PSX.Controller.Pin5 +3.5V ---- yellow -- Mouse.Pin1
+ PSX.Controller.Pin6 /CSn ---- green -- Mouse.Pin5
+ PSX.Controller.Pin7 SCK ---- blue -- Mouse.Pin2
+ PSX.Controller.Pin8 /IRQ ---- N/A
+ PSX.Controller.Pin9 /ACK ---- purple -- Mouse.Pin6
+ PSX.Controller.Shield -------- shield -- Mouse.Pin8 GND (SHIELD)
+Some keyboard adaptors are also including a mouse adaptor feature (either by
+simulating normal Sony Mouse controller data, or via more uncommon ways like
+using the PSX expansion port).
+Controllers - Keyboards
Below is some info on RS232 serial mice. That info isn't directly PSX related
+as the PSX normally doesn't support those mice.
+With some efforts, one can upgrade the PSX SIO port to support RS232 voltages,
+and with such a modded console one could use RS232 mice (in case one wants to
+do that).
+The nocash PSX bios can map a RS232 mouse to a spare controller slot (thereby
+simulating a Sony mouse), that trick may work with various PSX games.
A serial mouse should be read at 1200 bauds, 7 data bits, no parity, 1 stop bit
+(7N1) with DTR and RTS on. For best compatibility, the mouse should output 2
+stop bits (so it could be alternately also read as 7N2 or 8N1). When the mouse
+gets moved, or when a button gets pressed/released, the mouse sends 3 or 4
+characters:
+
__First Character____________________
+ 6 First Character Flag (1)
+ 5 Left Button (1=Pressed)
+ 4 Right Button (1=Pressed)
+ 2-3 Upper 2bit of Vertical Motion
+ 0-1 Upper 2bit of Horizontal Motion
+ __Second Character___________________
+ 6 Non-first Character Flag (0)
+ 5-0 Lower 6bit of Horizontal Motion
+ __Third Character____________________
+ 6 Non-first Character Flag (0)
+ 5-0 Lower 6bit of Vertical Motion
+ __Fourth Character (if any)__________
+ 6 Non-first Character Flag (0)
+ 5 Middle Button (1=Pressed)
+ 4 Unused ???
+ 3-0 Wheel ???
+ "M" = Two-Button Mouse (aka "Microsoft" mouse)
+ "3" = Three-Button Mouse (aka "Logitech" mouse)
+ "Z" = Mouse-Wheel
+Accessed at 1200 bauds, just like standard serial mouse, but with 8N1 instead
+7N1, and with different data bytes.
+
__First Byte_________________________
+ 7-3 First Byte Code (10000b)
+ 2 Left? Button (0=Pressed)
+ 1 Middle? Button (0=Pressed)
+ 0 Right? Button (0=Pressed)
+ __Second Byte________________________
+ 7-0 Horizontal Motion (X1)
+ __Third Byte_________________________
+ 7-0 Vertical Motion (Y1)
+ __Fourth Byte________________________
+ 7-0 Horizontal Motion (X2)
+ __Fifth Byte_________________________
+ 7-0 Vertical Motion (Y2)
+The Sony Mouse connects directly to the PSX controller port. Alternately serial
+RS232 mice can be connected to the SIO port (with voltage conversion adaptor)
+(most or all commercial games don't support SIO mice, nor does the original
+BIOS do so, however, the nocash BIOS maps SIO mice to unused controller slots,
+so they can be used even with commercial games; if the game uses BIOS functions
+to read controller data).
+Serial Mice (and maybe also the Sony mouse) do return raw mickeys, so effects
+like double speed threshold must (should) be implemented by software. Mice are
+rather rarely used by PSX games. The game "Perfect Assassin" includes
+ultra-crude mouse support, apparently without threshold, and without properly
+matching the cursor range to the screen resolution.
__Halfword 0 (Controller Info)_______________________________________________
+ 0-15 Controller Info (5A23h=neGcon)
+ __Halfword 1 (Digital Switches)______________________________________________
+ 0-2 Not used (always 1) (would be Select, L3, R3 on other pads)
+ 3 Start Button (0=Pressed, 1=Released)
+ 4 Joypad Up (0=Pressed, 1=Released)
+ 5 Joypad Right (0=Pressed, 1=Released)
+ 6 Joypad Down (0=Pressed, 1=Released)
+ 7 Joypad Left (0=Pressed, 1=Released)
+ 8-10 Not used (always 1) (would be L2, R2, L1 on other pads)
+ 11 R Button (0=Pressed, 1=Released) (would be R1 on other pads)
+ 12 B Button (0=Pressed, 1=Released) (would be /\ on other pads)
+ 13 A Button (0=Pressed, 1=Released) (would be () on other pads)
+ 14-15 Not used (always 1) (would be ><, [] on other pads)
+ __Halfword 2 (Right joystick) (analog pad/stick in analog mode only)_________
+ 0-7 Steering Axis (00h=Left, 80h=Center, FFh=Right) (or vice-versa?)
+ 8-15 Analog I button (00h=Out ... FFh=In) (Out=released, in=pressed?)
+ __Halfword 3 (Left joystick) (analog pad/stick in analog mode only)__________
+ 0-7 Analog II button (00h=Out ... FFh=In) (Out=released, in=pressed?)
+ 8-15 Analog L button (00h=Out ... FFh=In) (Out=released, in=pressed?)
+ _____ _ _ _____ ____
+ |__L__\_______/ || \_______/__R__| / \
+ / _ namco || neGcon \ / \
+ | _| |_ || B | | |
+ | |_ X _| ....||.... II A | .... Rotation Axis ... | ... \|/
+ | |_| || I | |
+ | START || | \
+ | ________ || ________ | \__\
+ | / \_||_/ \ | /
+ \____/ \____/
+This is a cut-down variant of the neGcon, just a featureless small box. It does
+have the same ID value as neGcon (ID=5A23h), but, it excludes most digital, and
+all analog buttons.
+
_______
+ | namco | Halfword 1 (digital buttons):
+ | | Bit3 Button A (0=Pressed) (aka neGcon Start button)
+ | A B | Bit13 Button B (0=Pressed) (aka neGcon A button aka () button)
+ | | Other bits (not used, always 1)
+ | _ | Halfword 2 and 3 (analog inputs):
+ | (_) | Steering Axis (00h..FFh) (as for neGcon)
+ |_______| Analog I,II,L button values (not used, always 00h)
+Another cut-down variant of the neGcon (with ID=5A23h, too). But, this one
+seems to have only one button. Unlike Namco's volume controller it doesn't look
+featureless. It looks pretty much as shown in the ascii-arts image below. Seems
+to be supported by several irem titles. No idea what exactly it is used for,
+it's probably not a sewing machine controller, nor an electronic amboss.
+
____ ____ Halfword 1 (digital buttons):
+ | / _ \ Bit12 Button (0=Pressed) (aka neGcon B button aka /\ button)
+ |_ / (_) ) Other bits (not used, always 1)
+ |_|___ /\ Halfword 2 and 3 (analog inputs):
+ ____| |_ Steering Axis (00h..FFh) (as for neGcon)
+ |__________| Analog I,II,L button values (not used, always 00h)
+A neGcon compatible controller. The Twist-feature has been replaced by a
+steering wheel (can be turned by 270 degrees), and the analog I and II buttons
+by foot pedals. The analog L button has been replaced by a digital button (ie.
+in neGcon mode, the last byte of the controller data can be only either 00h or
+FFh). When not using the pedals, the I/II buttons on the wheel can be used
+(like L button, they aren't analog though).
+
__________________________
+ / ____________________ \ Stick
+ / / \ \ ___ Brakes Gas
+ / ( ) \ ( ) II I
+ / I \ / A \ \ / ___ ___
+ / /\ II \____________MODE__/ B /\ \ | | | | |
+ | | \ L _ R / | | | |!!!|_|!!!|___
+ | | ) _| |_ MadCatz ( | |_|_ /|!!!| |!!!| /
+ | | | |_ X _| | | | | | / |___| |___| /
+ | | | |_| | | | / / =========== /
+ | | \ SEL STA / | | / / =========== /
+ \ \__/ ______________________ \__/ / / /_____________/
+ \____/ \____/_/
+ |___________________________|
+Unlike the neGon, the controller has Select, >\< and [] buttons, and a
+second set of L/R buttons (at the rear-side of the wheel) (no idea if L1/R1 or
+L2/R2 are at front?). Aside from the neGcon mode, the controller can be also
+switched to Digital mode (see below for button chart).
Same as above, but with a new Analog mode (additionally to Digital and neGcon
+modes). The new mode is for racing games that support only Analog Joypads
+(instead of neGcon). Additionally it supports vibration feedback.
Same as above, but with a redesigned wheel with rearranged buttons, the digital
+pad moved to the center of the wheel, the L/R buttons at the rear-side of the
+wheel have been replaced by 2-way butterfly buttons ("pull towards user" acts
+as normal, the new "push away from user" function acts as L3/R3).
+
____________________
+ / ________________ \ ___ Stick Brakes Gas
+ / / MC2 \ \ ( ) ___ ___
+ / /__________________\ \ \ / | | | |
+ | A () _|_ I >< | | |!!!|_|!!!|___
+ | B /\ _ | _ II [] | | /|!!!| |!!!| /
+ ___| L2 / \ STA / \ R2 |_|_ / |___| |___| /
+ / \ / | SEL | \ / \ / =========== /
+ / ____\ |___| |___| /____ \ / =========== /
+ /__/ \____________________/ \__\ /_____________/
+ Mode Buttons...................... Gas Brake Stick Wheel
+ Digital >< [] () /\ L1 R1 L2 R2 L1 R1 >< () L1/R1 lt/rt
+ Analog >< [] () /\ L1 R1 L2 R2 L3 R3 UP DN L1/R1 LT/RT
+ Negcon I II A B L R L R L R I II up/dn Twist
+ __Halfword 0 (Controller Info)___________________
+ 0-15 Controller Info (5AE3h=Jogcon in Jogcon mode) (ie. not Digital mode)
+ halfword1: buttons: same as digital pad
+ halfword2:
+ 0 unknown (uh, this isn't LSB of rotation?)
+ 1-15 dial rotation (signed offset since last read?) (or absolute position?)
+ halfword3:
+ 0 flag: dial was turned left (0=no, 1=yes)
+ 1 flag: dial was turned right (0=no, 1=yes)
+ 2-15 unknown
+ ___ ________ ___
+ __/_L_\__ / \ __/_R_\__
+ / _ \ / LED MODE \-/ \
+ | _| |_ | SEL STA | /\ |
+ | |_ X _| | ________ | [] () |
+ | |_| | / \ | >< |
+ |\_________/\/ \/\__ ______/|
+ | | | JOGCON | | |
+ | | | DIAL | | |
+ | | \ / | |
+ | | \________/ | |
+ | | | |
+ | | | |
+ \_____/ \_____/
+There are two different types of PSX lightguns (which are incompatible with
+each other).
Namco's Cinch-based lightguns are extracting Vsync/Hsync timings from the video
+signal (via a cinch adaptor) (so they are working completely independed of
+software timings).
+Controllers - Lightguns - Namco (GunCon)
Konami's IRQ10-based lightguns are using the lightgun input on the controller
+slot (which requires IRQ10/timings being properly handled at software side).
+Controllers - Lightguns - Konami Justifier/Hyperblaster (IRQ10)
+The IRQ10-method is reportedly less accurate (although that may be just due to
+bugs at software side).
There are also a lot of unlicensed lightguns which are either IRQ10-based, or
+Cinch-based, or do support both.
+For example, the Blaze Scorpion supports both IRQ10 and Cinch, and it does
+additionally have a rumble/vibration function; though unknown how that rumble
+feature is accessed, and which games are supporting it).
Controllers - Lightguns - PSX Lightgun Games
Some lightguns are reportedly working only with PAL or only with NTSC games
+(unknown which guns, and unknown what is causing problems; the IRQ10 method
+should be quite hardware independed, the GunCon variant, too, although
+theoretically, some GunCon guns might have problems to extract Vsync/Hsync from
+either PAL or NTSC composite signals).
+Lightguns from different manufacturers are reportedly returning slightly
+different values, so it would be recommended to include a calibration function
+in the game, using at least one calibration point (that would also resolve
+different X/Y offsets caused by modifying GP1 display control registers).
+Lightguns are needing to sense light from the cathode ray beam; as such they
+won't work on regions of the screen that contain too dark/black graphics.
__Halfword 0 (Controller Info)___________________
+ 0-15 Controller Info (5A63h=Namco Lightgun; GunCon/Cinch Type)
+ __Halfword 1 (Buttons)___________________________
+ 0-2 Not used (All bits always 1)
+ 3 Button A (Left Side) (0=Pressed, 1=Released) ;aka Joypad Start
+ 4-12 Not used (All bits always 1)
+ 13 Trigger Button (0=Pressed, 1=Released) ;aka Joypad O-Button
+ 14 Button B (Right Side) (0=Pressed, 1=Released) ;aka Joypad X-Button
+ 15 Not used (All bits always 1)
+ __Halfword 2 (X)_________________________________
+ 0-15 8MHz clks since HSYNC (01h=Error, or 04Dh..1CDh)
+ __Halfword 3 (Y)_________________________________
+ 0-15 Scanlines since VSYNC (05h/0Ah=Error, PAL=20h..127h, NTSC=19h..F8h)
+Coordinates X=0001h, Y=0005h indicates "unexpected light":
+
ERROR: Sensed light during VSYNC (eg. from a Bulb or Sunlight).
+ ERROR: no light sensed at all (not aimed at screen, or screen too dark).
+ BUSY: no light sensed yet (when trying to read gun during rendering).
+Below are some average minimum brightness values, the gun may be unable to
+return position data near/below that limits (especially coordinates close to
+left screen border are most fragile). The exact limits may vary from gun to
+gun, and will also depend on the TV Set's brightness setting.
+
666666h Minimum Gray
+ 770000h Minimum Blue
+ 007700h Minimum Green
+ 000099h Minimum Red
+The coordinates are updated in all frames (as opposed to some lightguns which
+do update them only when pulling the trigger).
+The absolute min/max coordinates may vary from TV set to TV set (some may show
+a few more pixels than others). The relation of the gun's Screen Coodinates to
+VRAM Coordinates does (obviously) depend on where the VRAM is located on the
+screen; ie. on the game's GP1(06h) and GP1(07h) settings.
+Vertical coordinates are counted in scanlines (ie. equal to pixels). Horizontal
+coordinates are counted in 8MHz units (which would equal a resolution of 385
+pixels; which can be, for example, converted to 320 pixel resolution as
+X=X*320/385).
__Halfword 2 (X)_________________________________
+ 0-7 X-Coordinate (actual: see X-Offset) ;\with unspecified
+ 8-15 X-Offset (00h: X=X-80, Nonzero: X=X-80+220) ;/dotclock?
+ __Halfword 3 (Y)_________________________________
+ 0-7 Y-Coordinate (actual: Y=Y-25) (but then, max is only 230, not 263 ?)
+ 8-15 Pad ID (uh, what id?) (reportedly too dark/bright error flag?)
+ _-_______________________--_
+ -----> | namco \\\\ \ Namco G-Con 45 (light gray) (cinch)
+ sensor |............ .. .....\\\\...|_
+ |_ : :.. _____ _\
+ | O :__../ )))| (
+ \__________/ |_\____/| \
+ : : | |
+ : : | | NPC-103
+ A-Button (Left) Trigger | | SLPH-00034/SLEH-0007/SLUH-00035
+ B-Button (Right) |______|
+Pinouts - Component List and Chipset Pin-Outs for Namco Lightgun, NPC-103
Send 01h 42h 00h x0h 00h
+ Reply HiZ 31h 5Ah buttons
+The Controller Data simply consists of the ID and buttons states:
+
__Halfword 0 (Controller Info)___________________
+ 0-15 Controller Info (5A31h=Konami Lightgun; Timer/IRQ10 type)
+ __Halfword 1 (Buttons)
+ 0-2 Not used (All bits always 1)
+ 3 Start Button (Left Side) (0=Pressed, 1=Released) ;aka Joypad Start
+ 4-13 Not used (All bits always 1)
+ 14 Back Button (Rear End) (0=Pressed, 1=Released) ;aka Joypad X-Button
+ 15 Trigger Button (0=Pressed, 1=Released) ;aka Joypad []-Button
+ __ ______ _
+ _|__\_______________/ ___ \ \ Konami Justifier/Hyperblaster (light green)
+ | _______________ __ / \ \ \
+ |__| _ _ _ _ |==| O| \O\ .... Back Button (Rear End)
+ |__:_:_:_:_:__ |___\__ / ( (
+ |_| ) \ : \ \
+ Trigger ...... \___/| :...|.|.... Start Button (Left Side)
+ | | |
+ | | | SLPH-00013/SLPH-00014/SLEH-0005/SLUH-00017
+ / _|_|
+ \___--
+The PSX does have a lightgun input (Pin 8 of the controller), but, Sony did
+apparently "forget" to latch the current cathode ray beam coordinates by
+hardware when sensing the lightgun signal (quite strange, since that'd be a
+simple, inexpensive, and very obvious feature for a gaming console).
+Instead, the lightgun signal triggers IRQ10, and the interrupt handler is
+intended to "latch" the coordinates by software (by reading Timer 0 and 1
+values, which must configured to be synchronized with the GPU).
+That method requires IRQ handling to be properly implemented in software
+(basically, IRQs should not be disabled for longer periods, and DMA transfers
+should not block the bus for longer periods). In practice, most programmers
+probably don't realize how to do that, to the worst, Sony seems to have
+delivered a slightly bugged library (libgun) to developers.
+For details on Timers, see:
+Timers
+In some consoles, IRQ10 seems to be routed through a Secondary IRQ Controller,
+see:
+EXP2 DTL-H2000 I/O Ports
For processing IRQ10 as soon as possible, it should be assigned higher priority
+than all other IRQs (ie. when using the SysEnqIntRP BIOS function, it should be
+the first/newest element in priority chain 0). The libgun stuff assigns an even
+higher priority by patching the BIOS exception handler, causing IRQ10 to be
+processed shortly before processing the priority chains (the resulting IRQ
+priority isn't actually higher as when using 1st element of chain 0; the main
+difference is that it skips some time consuming code which pushes registers
+R4..R30). For details on that patch, see:
+BIOS Patches
+Even if IRQ10 has highest priority, execution of (older) other IRQs may cause a
+new IRQ10 to be executed delayed (because IRQs are disabled during IRQ
+handling), to avoid that problem: Best don't enable any other IRQs except IRQ0
+and IRQ10, or, if you need other IRQs, best have them enabled only during
+Vblank (there are no scanlines drawn during vblank, so IRQ10 should never
+trigger during that period). DMAs might also slow down IRQ execution, so best
+use them only during Vblank, too.
To read the current timer values the IRQ10 handler would be required to be
+called \<immediately> after receiving the IRQ10 signal, which is more or
+less impossible; if the main program is trying to read a mul/div/gte result
+while the mul/div/gte operation is still busy may stop the CPU for some dozens
+of clock cycles, and active DMA transfers or cache hits and misses in the IRQ
+handler may cause different timings, moreover, timings may become completely
+different if IRQs are disabled (eg. while another IRQ is processed).
+However, IRQ10 does also get triggered in the next some scanlines, so the first
+IRQ10 is used only as a notification that the CPU should watch out for further
+IRQ10's. Ie. the IRQ10 handler should disable all DMAs, acknowledge IRQ10, and
+then enter a waitloop that waits for the IRQ10 bit in I_STAT to become set
+again (or abort if a timeout occurs) and then read the timers, reportedly like
+so:
+
IF NTSC then X=(Timer0-140)*0.198166, Y=Timer1
+ IF PAL then X=(Timer0-140)*0.196358, Y=Timer1
+BUG: The "libgun" library doesn't acknowledge the old IRQ10 \<immediately>
+before waiting for a new IRQ10, so the timer values after sensing the new IRQ10
+are somewhat random (especially for the first processed scanline) (the library
+allows to read further IRQ10's in further scanlines, which return more stable
+results).
+No idea how many times IRQ10 gets typically repeated? Sporting Clays allocates
+a buffer for up to 20 scanlines (which would cause pretty much of a slowdown
+since the CPU is just waiting during that period) (nethertheless, the game uses
+only the first timer values, ie. the bugged libgun-random values).
Unknown if/how two-player games (with 2 lightguns) are working with the IRQ10
+method... if IRQ10 is generated ONLY after pressing the trigger button, then it
+may work, unless both players have Trigger pressed at the same time... and,
+maybe one can enable/disable the lightguns by whatever commmand being sent to
+the controller (presumably that "x0h" byte, see above), so that gun 1 generates
+IRQ10 only in each second frame, and gun 2 only in each other frame...?
Some games are working only with IRQ10 or only with Cinch, some games support
+both methods:
+
Area 51 (Mesa Logic/Midway) (IRQ10)
+ Crypt Killer (Konami) (IRQ10)
+ Die Hard Trilogy 1: (Probe Entertainment) (IRQ10)
+ Die Hard Trilogy 2: Viva Las Vegas (n-Space) (IRQ10/Cinch)
+ Elemental Gearbolt (Working Designs) (IRQ10/Cinch)
+ Extreme Ghostbusters: Ultimate Invasion (LSP) (Cinch)
+ Galaxian 3 (Cinch)
+ Ghoul Panic (Namco) (Cinch)
+ Gunfighter: The Legend of Jesse James (Rebellion) (Cinch)
+ Judge Dredd (Gremlin) (Cinch)
+ Lethal Enforcers 1-2 (Konami) (IRQ10)
+ Maximum Force (Midway) (IRQ10/Cinch)
+ Mighty Hits Special (Altron) (EU/JPN) (Cinch)
+ Moorhuhn series (Phenomedia) (Cinch)
+ Point Blank 1-3 (Namco) (Cinch)
+ Project Horned Owl (Sony) (IRQ10)
+ Rescue Shot (Namco) (Cinch)
+ Resident Evil: Gun Survivor (Capcom) (JPN/PAL versions) (Cinch)
+ Silent Hill (IRQ10) ("used for an easter egg")
+ Simple 1500 Series Vol.024 - The Gun Shooting (unknown type)
+ Simple 1500 Series Vol.063 - The Gun Shooting 2 (unknown type)
+ Snatcher (IRQ10)
+ Sporting Clays (Charles Doty) (homebrew with buggy source code) (IRQ10/Cinch)
+ Star Wars Rebel Assault II (IRQ10)
+ Time Crisis, and Time Crisis 2: Project Titan (Namco) (Cinch)
+Some controllers can be switched from Normal Mode to Config Mode. The Config
+Mode was invented for activating the 2nd rumble motor in SCPH-1200 analog
+joypads. Additionally, the Config commands can switch between analog/digital
+inputs (without needing to manually press the Analog button), activate more
+analog inputs (on Dualshock2), and read some type/status bytes.
42h "B" Read Buttons (and analog inputs when in analog mode)
+ 43h "C" Enter/Exit Configuration Mode (stay normal, or enter)
+ 40h "@" Unused, or Dualshock2: Get/Set ButtonAttr?
+ 41h "A" Unused, or Dualshock2: Get Reply Capabilities
+ 42h "B" Read Buttons AND analog inputs (even when in digital mode)
+ 43h "C" Enter/Exit Configuration Mode (stay config, or exit)
+ 44h "D" Set LED State (analog mode on/off)
+ 45h "E" Get LED State (and Type/constants)
+ 46h "F" Get Variable Response A (depending on incoming bit)
+ 47h "G" Get whatever values (response HiZ F3h 5Ah 00h 00h 02h 00h 01h 00h)
+ 48h "H" Unknown (response HiZ F3h 5Ah 00h 00h 00h 00h 01h 00h)
+ 49h "I" Unused
+ 4Ah "J" Unused
+ 4Bh "K" Unused
+ 4Ch "L" Get Variable Response B (depending on incoming bit)
+ 4Dh "M" Get/Set RumbleProtocol
+ 4Eh "N" Unused
+ 4Fh "O" Unused, or Dualshock2: Set ReplyProtocol
+ Send 01h 42h 00h xx yy (00h 00h 00h 00h) (...)
+ Reply HiZ id 5Ah buttons ( analog-inputs ) (dualshock2 buttons...)
+ yy.bit0-7 ---> Left/Large Motor M1 (analog slow/fast) (00h=stop, FFh=fastest)
+ xx.bit0 ---> Right/small Motor M2 (digital on/off) (0=off, 1=on)
+ Send 01h 43h 00h xx 00h (zero padded...) (...)
+ Reply HiZ id 5Ah buttons (analog inputs...) (dualshock2 buttons...)
+ xx=00h Stay in Normal mode
+ xx=01h Enter Configuration mode
+ Send 01h 42h 00h M2 M1 00h 00h 00h 00h
+ Reply HiZ F3h 5Ah buttons analog-inputs
+ Send 01h 43h 00h xx 00h 00h 00h 00h 00h
+ Reply HiZ F3h 5Ah 00h 00h 00h 00h 00h 00h
+ xx=00h Enter Normal mode (Exit Configuration mode)
+ xx=01h Stay in Configuration mode
+ Send 01h 44h 00h Led Key 00h 00h 00h 00h
+ Reply HiZ F3h 5Ah 00h 00h Err 00h 00h 00h
+ When Led=00h --> Digital mode, with LED=Off
+ When Led=01h --> Analog mode, with LED=On/red
+ When Led=02h..FFh --> Ignored (and, in case of dualshock2: set Err=FFh)
+ When Key=00h..02h --> Unlock (allow user to push Analog button)
+ When Key=03h --> Lock (stay in current mode, ignore Analog button)
+ When Key=04h..FFh --> Acts same as (Key AND 03h)
+ Send 01h 45h 00h 00h 00h 00h 00h 00h 00h
+ Reply HiZ F3h 5Ah Typ 02h Led 02h 01h 00h
+ Led: Current LED State (00h=Off, 01h=On/red)
+ Typ: Controller Type (01h=PSX/Analog Pad, 03h=PS2/Dualshock2)
+ Send 01h 46h 00h ii 00h 00h 00h 00h 00h
+ Reply Hiz F3h 5Ah 00h 00h cc dd ee ff
+ Send 01h 47h 00h 00h 00h 00h 00h 00h 00h
+ Reply HiZ F3h 5Ah 00h 00h 02h 00h 01h 00h
+ Send 01h 4Ch 00h ii 00h 00h 00h 00h 00h
+ Reply Hiz F3h 5Ah 00h 00h 00h dd 00h 00h
+ Send 01h 48h 00h ii 00h 00h 00h 00h 00h
+ Reply HiZ F3h 5Ah 00h 00h 00h 00h ee 00h
+Controllers - Vibration/Rumble Control
Controllers - Analog Buttons (Dualshock2)
Send 01h 4xh 00h 00h 00h 00h 00h 00h 00h
+ Reply HiZ F3h 5Ah 00h 00h 00h 00h 00h 00h
+Something called "Guitar Hero controller" does reportedly also support Config
+commands. Unknown if that thing does have the same inputs & rumble motors
+as normal analog PSX joypads, and if it does return special type values.
Rumble (aka "Vibration Function") is basically controlled by two previously
+unused bytes of the standard controller Read command.
+There are two methods to control the rumble motors, the old method is very
+simple (but supports only one motor), the new method envolves a bunch of new
+configuration commands (and supports two motors).
+
SCPH-1150 DualAnalog Pad with 1 motor ;-old rumble method
+ SCPH-1200 DualAnalog Pad with 2 motors, PSX-design ;\new rumble method
+ SCPH-110 DualAnalog Pad with 2 motors, PSone-design ;/
+ SCPH-10010 DualAnalog Pad with 2 motors, PS2/Dualshock2 ;-plus analog buttons
+ Blaze Scorpion Lightgun with rumble ;\unknow how to control rumble
+ Fishing controllers with rumble ;/
+ SCPH-1180 Analog Pad without rumble ;\unknow if there're config commands
+ SCPH-1110 Analog Stick without rumble ;/for analog mode (probably not)
+The SCPH-1150 doesn't support any special config commands, instead, rumble is
+solely done via the normal joypad read command:
+
Send 01h 42h 00h xx yy (00h 00h 00h 00h)
+ Reply HiZ id 5Ah buttons ( analog-inputs )
+ xx --> must be 40h..7Fh (ie. bit7=0, bit6=1) ;\switches motor on
+ yy --> must be 01h,03h,...,FDh,FFh (ie. bit0=1) ;/
+For using the new rumble method, one must unlock the new rumble mode, for that
+purpose Sony has invented a "slightly" overcomplicated protocol with not less
+than 16 new commands (the rumble relevant commands are 43h and 4Dh, also,
+command 44h may be useful for activating analog inputs by software, and, once
+when rumble is unlocked, command 42h is used to control the rumble motors).
+Anyways, here's the full command set...
+Controllers - Configuration Commands
+And, the rumble-specific config command is described below...
Send 01h 4Dh 00h aa bb cc dd ee ff ;<-- set NEW aa..ff values
+ Reply Hiz F3h 5Ah aa bb cc dd ee ff ;<-- returns OLD aa..ff values
+ 00h = Map Right/small Motor (Motor M2) to bit0 of this byte
+ 01h = Map Left/Large Motor (Motor M1) to bit0-7 of this byte
+ 02h..FEh = Unknown (can be mapped, maybe for extra motors/outputs)
+ FFh = Map nothing to this byte
+ Send 01h 4Dh 00h 00h 01h FFh FFh FFh FFh ;enable new method (two motors)
+ Send 01h 4Dh 00h FFh FFh FFh FFh FFh FFh ;disable motor control
+Dualshock2 does reportedly have "two more levels of vibration", unknown what
+that means and if it's used by any PSX or PS2 games... it might refer to the
+small motor which usually has only 2 levels (on/off) and might have 4 levels
+(fast/med/slow/off) on dualshock2... but, if so, it's unknown how to
+control/unlock that feature.
+Also, the PSone controller (SCPH-110) appear to have been released shortly
+after Dualshock2, unknown if that means that it might have that feature, too.
Rumble is a potentially annoying feature, so games that do support rumble
+should also include an option to disable it.
Dualshock2 has three new commands (40h,41h,4Fh) for configuring analog buttons.
+Additionally, Command 45h does return a different type byte for Dualshock2.
+Dualshock2 is a PS2 controller. However, it can be also used with PSX games
+(either by connecting the controller to a PSX console, or by playing a PSX game
+on a PS2 console).
+The analog button feature is reportedly rarely used by PS2 games (and there
+aren't any PSX games known to use it).
Send 01h 40h 00h Idx Val 00h 00h 00h 00h ;<-- Set NEW Val, array[Idx]=Val
+ Reply HiZ F3h 5Ah 00h 00h Val 00h 00h 00h ;<-- Old Val (or FFh when Idx>0Bh)
+ Digital button sensitivity, or Analog button sensitivity, or
+ Analog button bit-depth/conversion speed, or something else?
+ Send 01h 41h 00h 00h 00h 00h 00h 00h 00h
+ Reply HiZ F3h 5Ah FFh FFh 03h 00h 00h 00h
+ Send 01h 41h 00h aa bb cc dd ee ff
+ Reply HiZ F3h 5Ah 00h 00h 00h 00h 00h 00h
+ - HighZ (always transferred) 1st byte
+ - ID/Mode/Len (always transferred) 2nd byte
+ - 5Ah (always transferred) 3rd byte
+ 0 LSB of digital buttons (0=No, 1=Yes) 4th byte
+ 1 MSB of digital buttons (0=No, 1=Yes) 5th byte
+ 2 RightJoyX (0=No, 1=Yes) 6th byte
+ 3 RightJoyY (0=No, 1=Yes) 7th byte
+ 4 LeftJoyX (0=No, 1=Yes) 8th byte
+ 5 LeftJoyY (0=No, 1=Yes) 9th byte
+ 6 DPAD Right (0=No, 1=Yes) button 00h 10th byte
+ 7 DPAD Left (0=No, 1=Yes) button 01h 11th byte
+ 8 DPAD Uup (0=No, 1=Yes) button 02h 12th byte
+ 9 DPAD Down (0=No, 1=Yes) button 03h 13th byte
+ 10 Button /\ (0=No, 1=Yes) button 04h 14th byte
+ 11 Button () (0=No, 1=Yes) button 05h 15th byte
+ 12 Button >< (0=No, 1=Yes) button 06h 16th byte
+ 13 Button [] (0=No, 1=Yes) button 07h 17th byte
+ 14 Button L1 (0=No, 1=Yes) button 08h 18th byte
+ 15 Button R1 (0=No, 1=Yes) button 09h 19th byte
+ 16 Button L2 (0=No, 1=Yes) button 0Ah 20th byte
+ 17 Button R2 (0=No, 1=Yes) button 0Bh 21st byte
+ 18-39 Must be 0 (otherwise command is ignored)
+ 40-47 Unknown (no effect?)
+ Send 01h 41h 00h 03h 00h 00h 00h 00h 00h Digital buttons
+ Send 01h 41h 00h 3Fh 00h 00h 00h 00h 00h Digital buttons + analog sticks
+ Send 01h 41h 00h FFh FFh 03h 00h 00h 00h Enable all 18 input bytes
+Note: Some Dualshock2 Config Mode commands do occassionally send 00h, 5Ah, or
+FFh as last (9th) reply byte (unknown if that is some error/status thing, or
+garbage).
The pressure sensors are rather imprecise and results may vary on various
+factors, including the pressure angle.
+
00h Button released
+ 01h..2Fh Normal (soft) pressure
+ 30h..FEh Medium pressure
+ FFh Hard pressure
+Digital inputs are converting the analog inputs as so:
+
Analog=00h --> not pressed
+ Analog=01h..FFh --> pressed (no matter if soft, medium, or hard pressure)
+[https://gist.github.com/scanlime/5042071] - tech (=mentions unknown details) +[https://store.curiousinventor.com/guides/PS2/] - guide (=omits unknown stuff)
+PSX Dance Mats are essentially normal joypads with uncommonly arranged buttons,
+the huge mats are meant to be put on the floor, so the user could step on them.
There are some differences to normal joypads: First of, the L1/L2/R1/R2
+shoulder buttons are missing in most variants. And, the mats are allowing to
+push Left+Right and Up+Down at once, combinations that aren't mechanically
+possible on normal joypads (some dancing games do actually require those
+combinations, whilst some joypad games may get confused on them).
Unknown if the mat was sold in japan, and if so, with which SLPH/SCPH number.
+Unknown if the mat's middle field is also having a button assigned.
+Unknown if the mat is having a special controller ID, or if there are other
+ways to detect mats (the mats are said to be compatible with skateboard games,
+so the mats are probably identifying themselves as normal digital joypad;
+assuming that those skateboard games haven't been specifically designed for
+mats).
D.D.R. Dance Dance Revolution 2nd Remix
+ (and maybe whatever further games)
+There is the US version (DDR Dance Pad, SLUH-00071), and a slightly different
+European version (Official Dance Mat, SLEH-00023: shiny latex style with
+perverted colors, and Start/Select arranged differently). The japanese version
+(RU017) resembles the US version, but without Triangle/Square symbols drawn in
+lower left/right edges.
+And there is a handheld version (with additional L1/L2/R2/R1 buttons; maybe
+unlicensed; produced as MINI DDR, and also as Venom Mini Dance Pad).
US Version (white/black/red/blue) Handheld Version (blue/gray)
+ __________.---------.___________ _____/ MINI \_____
+ | \ / | | D.D.R. |
+ | SELECT '-------' START | |L1 L2 SEL STA R2 R1|
+ |------------.------.------------| | ___ ___ ___ |
+ | .''''. / \ .''''. | || X | | ^ | | O ||
+ | | \/ | | /\ | | .''. | | ||___| |___| |___||
+ | | /\ | | /..\ | | '..' | | | ___ .---. ___ |
+ | '....' '. || .' '....' | || < | |Stay | | > ||
+ | .-------. .''''''''. .-------. | ||___| |Cool!| |___||
+ |/ /| .' '. |\ \| | ___ '___' ___ |
+ | / |-- | | --| \ | || []| | v | | /\||
+ | \ |-- | Stay Cool! | --| / | ||___| |___| |___||
+ |\ \| '. .' |/ /| |___________________|
+ | '-------' '........' '-------' |
+ | .''''. .' || '. .''''. | Gothic Dance Mat (black/silver)
+ | | /\ | | \''/ | | |''| | | _.----------._
+ | | /__\ | | \/ | | |..| | | | \ SEL STA / | This one
+ | '....' \ / '....' | | '--------' | wasn't ever
+ '------------'------'------------' | .----------. | produced,
+ | | .''''. | | as cool as
+ European Version (pink/blue/yellow) | | | /\ | | | it could have
+ __________.---------.___________ | | | /..\ | | | been, the lame
+ | \ SEL STA / | | | '.||.' | | marketing
+ | '-------' | | +----------+ | people didn't
+ |----------.----------.----------| | | .''''. | | even think
+ | .''''. | .''''. | .''''. | | | | /\ | | | about it.
+ | | \/ | | | /\ | | | .''. | | | | | /..\ | | |
+ | | /\ | | | /..\ | | | '..' | | | | '.||.' | |
+ | '....' | '.||.' | '....' | | +----------+ |
+ |----------+-.. ..-+----------| | | .'||'. | |
+ | .'/|'. / '''' \ .'|\'. | | | | \''/ | | |
+ | | / |--|/ \|--| \ | | | | | \/ | | |
+ | | \ |--|\ /|--| / | | | | '....' | |
+ | '.\|.' \ .... / '.|/.' | | +----------+ |
+ |----------+-'' ''-+----------| | | .'||'. | |
+ | .''''. | .'||'. | .''''. | | | | \''/ | | |
+ | | /\ | | | \''/ | | | |''| | | | | | \/ | | |
+ | | /__\ | | | \/ | | | |..| | | | | '....' | |
+ | '....' | '....' | '....' | | '----------' '
+ '----------|----------|----------' '--------------'
+Despite of the "Stay Cool!" slogan, the mat wasn't very cool - not at all! It
+offered only two steps back-and-forth, and also allowed to do extremly uncool
+side-steps. Not to mention that it would melt when dropping a burning cigarette
+on it. Stay Away!
Controllers used for Konami's Pop'n Music series. At least a few different +versions of the controller (Pop'n Controller, Pop'n Controller 2, larger +arcade-size version, possibly others and in different color variations) have +been released for the PS1 and PS2. Unknown if the controllers released in the +PS2 era have any additional commands not present in the original Pop'n +Controller, but they are supposedly fully compatible with PS1 Pop'n Music games.
+Pop'n Controllers report as digital controllers (ID byte 41h), but the left, +right, and down d-pad controls are not connected to any physical buttons and are +always reported as pressed (in the first transferred button byte, bits 5-7 are +always 0). Pop'n Music games check these bits to determine if a Pop'n Controller +is connected and will change the in-game controls accordingly if so.
+Controllers used for Taito's Densha de Go! and Jet de Go! series. Unknown what +method is being used by Densha de Go! and Jet de Go! games for detecting these +controllers.
+The fishing rods are (next to lightguns) some of the more openly martial
+playstation controllers - using the credo that "as long as you aren't using
+dynamite: it's okay to kill them cause they don't have any feelings."
Action Bass (Syscom Entertainment) (1999) (SLPH-00100)
+ Bass Landing (ASCII/agetec) (1999) (SLPH-00100, SLUH-00063)
+ Bass Rise, Fishing Freaks (Bandai) (1999) (BANC-0001)
+ Bass Rise Plus, Fishing Freaks (Bandai) (2000) (BANC-0001, SLPH-00100)
+ Breath of Fire IV (Capcom) (SLUH-00063)
+ Championship Bass (EA Sports) (2000) (SLUH-00063)
+ Fish On! Bass (Pony Canyon) (1999) (BANC-0001, SLPH-00100)
+ Fisherman's Bait 2/Exiting Bass2 - Big Ol'Bass(Konami)(SLPH-00100,SLUH-00063)
+ Fishing Club: (series with 3 titles) (have "headset-logo" on back?)
+ Lake Masters II (1999) (Dazz/Nexus) (SLPH-00100)
+ Lake Masters Pro (1999) (Dazz/Nexus) (BANC-0001, SLPH-00100)
+ Let's Go Bassfishing!: Bass Tsuri ni Ikou! (Banpresto) (1999) (SLPH-00100)
+ Matsukata Hiroki no World Fishing (BPS The Choice) (1999) (SLPH-00100)
+ Murakoshi Seikai-Bakuchou Nihon Rettou (Victor) (SLPH-00100)
+ Murakoshi Masami-Bakuchou Nippon Rettou:TsuriConEdition (1999) (SLPH-00100)
+ Pakuchikou Seabass Fishing (JP, 03/25/99) (Victor) (SLPH-00100)
+ Perfect Fishing: Bass Fishing (2000) (Seta) (yellow/green logo)
+ Perfect Fishing: Rock Fishing (2000) (Seta) (yellow/green logo)
+ Oyaji no Jikan: Nechan, Tsuri Iku De! (2000) (Visit) (BANC-0001, SLPH-00100)
+ Reel Fishing II / Fish Eyes II (2000)(Natsume/Victor)(SLPH-00100, SLUH-00063)
+ Simple 1500 Series Vol. 29: The Tsuri (2000) (yellow/green logo)
+ Suizokukan Project: Fish Hunter e no Michi (1999)(Teichiku)(SLPH-00100)
+ Super Bass Fishing (1999) (King) (BANC-0001, SLPH-00100, yellow/green logo)
+ Super Black Bass X2 (2000) (Starfish) (SLPH-00100)
+ Tsuwadou Keiryuu Mizuumihen (Best Edition)(2000) (ASCII PS1+PS2 controllers?)
+ Tsuwadou Seabass Fishing (PlayStation the Best) (1999) (Oz Club) (SLPH-00100)
+ Uki Uki Tsuri Tengoku Nagami/Uokami Densetsu Oe (2000) (Teichiku)(SLPH-00100)
+ Umi no Nushi Tsuri-Takarajima ni Mukatte (1999)(Victor)(BANC-0001,SLPH-00100)
+ Winning Lure (Hori) (2000) (for Hori HPS-97 controller) AKA HPS-98 ?
+US Fishing games should have a "SLUH-00063" logo. European Fishing games don't
+have any fishing logos; apparently fishing controllers haven't been officially
+released/supported in Europe.
+Japanese Fishing games can have a bunch of logos: Usually BANC-0001 or
+SLPH-00100 (or both).
+Moreover, some japanese games have a yellow/green fishing logo with japanese
+text (found on Perfect Fishing: Bass Fishing, Perfect Fishing: Rock Fishing,
+Simple 1500 Series Vol. 29: The Tsuri, Super Bass Fishing) (unknown if that
+logo refer to other special hardware, or if it means the "normal" BANC-0001 or
+SLPH-00100 controllers.
+And Moreover, some japanese games have some sort of "headset" logos with
+japanese text, these seem to have same meaning as SLPH-00100; as indicated by
+photos on CD cover of Tsuwadou Keiryuu Mizuumihen (Best Edition) (2000); that
+CD cover also has a "headset 2" logo, which seems to mean a newer PS2 variant
+of the SLPH-00100.
ASCII Tsuricon SLPH-00100 (also marked with a second serial, ASC-0514TR, on the packaging box)
+ ASCII Tsuricon 2 ASC-0521TR2 (has a mode switch with 3 settings. "1" is original Tsuricon mode, "2" is Tsuricon 2 mode. Unknown what the unnumbered mode does)
+ Sammy Tsuricon 2 SMY-0506FS (looks to be identical to the ASCII Tsuricon 2)
+ Sammy Tsuricon 2+ SMY-0511FS (unknown what the differences between this and the Tsuricon 2 are)
+ Agetec Bass Landing Fishing Controller SLUH-00063 (US version of ASCII's SLPH-00100 controller)
+ Bandai Fishing Controller BANC-0001 (dark gray/blue) (has less buttons than ASCII/agetec)
+ Interact Fission (light gray/blue)(similar to ASCII/agetec, 2 extra buttons?)
+ Naki (transparent blue) (looks like a clone of the ASCII/agetec controllers)
+ Hori HPS-97/HPS-98 (black/gray) (a fishing rod attached to a plastic fish)
+Unknown how to detect fishing controllers.
+Unknown how to read buttons, joystick, crank, motion sensors.
+Unknown how to control rumble/vibration.
+Unknown if/how Bandai differs from ASCII/agetec (aside from less buttons).
+Unknown how the Hori thing works.
___
+ __|___|__
+ _| |_ _ __
+ | | | | | |=|__| <--- crank handle
+ | | SEL STA | | | |
+ | | | |---| \ ASCII SLPH-00100
+ | \ / |---| / agetec SLUH-00063
+ / L1 R1 \ | | __
+ | L2 .---. R2 | |_|=|__|
+ | | joy | |
+ | |stick| | <------- analog thumb controlled joystick
+ | /\ '---' >< |
+ | [] () |
+ \ ASCII /
+ '.___________.' \___ 10 buttons (SEL,STA,L1,L2,R1,R2,/\,[],(),><)
+ \ _____ /
+ | | Note: many (not all) agetec controllers
+ | | have the >< and () buttons exchanged
+ | |
+ | | Aside from the crank/buttons/joystick,
+ | | the controller reportedly contains:
+ | | some sort of motion sensors?
+ | | some kind of rumble/vibration?
+ | |
+ '.___.'
+ '--...___ cable
+ ___
+ __|___|__
+ _| | _ __
+ | .---. |\ | |=|__| <--- crank handle
+ || joy | | | | |
+ ||stick| | |-#-| \
+ | '---' | |-#-| /
+ / \ | \ | | __
+ | | ... | | |_|=|__|
+ | | : : | ()|
+ | |O :___: O| | <--- two buttons: () and ><
+ | |- |___| -| ><| and some slide switch with I and 0 positions?
+ | | | |
+ \ | BANDAI | / unknown if the joystick is digital or analog
+ '._\_______/_.'
+ | | unknown if there are motion sensors and/or rumble
+ '. .'
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ '.___.'
+ '--...___ cable
+ ....----------------O
+ .'' \ HPS-97 (controller bundled with game)
+ _:_ \ \ HPS-98 (controller only, for HPS-96 game)
+ __|___|__ \ short \
+ _| |_ elastic \
+ | | pole \
+ | | \ <--- string (from pole to
+ | SW? | _ __ \ reel inside of fish)
+ / \ | |=|__| \
+ | .---. | | | \
+ | ( ) | joy | |--| \ \ ___
+ | |stick| |--| / \ / /
+ | ( ) '---' | | | __ \ ...---''''''--. /|
+ | | |_|=|__| <--- crank \ ' '/ |
+ \ ( ) ( ) / handle '..| |.
+ '.___________.' |__________________| :
+ \ / \ plastic fish :
+ | | joystick, (presumable some heavy :
+ | | four buttons, stationary thing that :
+ | | and a switch? rests on floor) :
+ | | (presumably with :
+ | | motor-driven reel?) :
+ | | :
+ | | the two cables do probably connect :
+ | | to both of the PSX controller slots :
+ '.___.' cable 2 ---'
+ '--...___ cable 1
+An accessory released by Sony for the PS2, consisting of an infrared remote
+control and a receiver dongle that plugs into a controller port. The remote
+features all standard controller buttons (including L3/R3) as well as additional
+controls for the PS2's DVD player.
+The receiver behaves very differently from any other known device: it does not
+respond to any command until a button on the remote is pressed. When a valid IR
+code is received it will start accepting commands for about 2000-2500 ms, then
+become unresponsive again. It will initially behave as two different devices,
+one with address 01h acting like a standard digital controller and the other
+with address 61h exposing IR codes as received from the remote.
Send Reply Comment
+ 61h N/A IR receiver address
+ 04h 12h Receive ID bits 0-7, send command byte
+ 00h 5Ah Receive ID bits 8-15
+ 00h len Receive code length (20 for DVD remote, 0 if no button is pressed)
+ 00h code Receive code bits 16-23
+ 00h code Receive code bits 8-15
+ 00h code Receive code bits 0-7
+ Code sent by remote (first bit after preamble to last bit):
+ 0000 0000 1011 1001 0010
+ Code sent by remote (MSB to LSB):
+ 0100 1001 1101 0000 0000
+ Data returned by receiver:
+ code[16:23] = 01001001
+ code[8:15] = 11010000
+ code[0:7] = 0000xxxx ; xxxx = (24 - len) bits of padding (all zeroes)
+ Reassembled MSB-aligned code (MSB to LSB):
+ 0100 1001 1101 0000 0000 xxxx
+ Send Reply Comment
+ 61h N/A IR receiver address
+ 06h 12h Receive ID bits 0-7, send command byte 1
+ 03h 5Ah Receive ID bits 8-15, send command byte 2
+ 00h ? Receive unknown data, send padding
+ 00h ?
+ 00h ?
+ 00h ?
+This command exists (the receiver will keep pulling /ACK low) but its purpose is
+currently unknown. It could possibly be an alternate poll command that does not
+disable controller mode.
The DVD remote always emits 20-bit IR codes. The receiver does return the length
+of the code, but it's unclear if it can receive codes with lengths other than 20
+bits.
+All non-controller buttons on the remote are arranged in an 8x16 button matrix,
+shown below (transposed for readability):
| Col | +Row 0 | +Row 1 | +Row 2 | +Row 3 | +Row 4 | +Row 5 | +Row 6 | +Row 7 | +
|---|---|---|---|---|---|---|---|---|
| 0 | +1 | ++ | + | Previous | ++ | + | Slow << | ++ |
| 1 | +2 | ++ | + | Next | ++ | + | Slow >> | ++ |
| 2 | +3 | ++ | + | Play | ++ | + | + | + |
| 3 | +4 | ++ | + | Scan << | ++ | + | Subtitle | ++ |
| 4 | +5 | ++ | + | Scan >> | ++ | Display | +Audio | ++ |
| 5 | +6 | ++ | + | Shuffle | ++ | + | Angle | ++ |
| 6 | +7 | ++ | + | + | + | + | + | + |
| 7 | +8 | ++ | + | + | + | + | + | + |
| 8 | +9 | ++ | Time | +Stop | ++ | + | + | + |
| 9 | +0 | ++ | + | Pause | ++ | + | + | Up | +
| 10 | ++ | Title | +A<->B | ++ | + | + | + | Down | +
| 11 | +Enter | +DVD Menu | ++ | + | + | + | + | Left | +
| 12 | ++ | + | Repeat | ++ | + | + | + | Right | +
| 13 | ++ | + | + | + | + | + | + | + |
| 14 | +Return | ++ | + | + | + | + | + | + |
| 15 | +Clear | +Program | ++ | + | + | + | + | + |
Each button in the matrix is assigned a code as follows:
+
code = 49D00h OR (row << 4) OR (column) ; sent LSB first
+
+ ; where row = 0..7, column = 0..15
+ code = DAD50h OR (id) ; sent LSB first
+
+ ; where id = 0..15, index of the bit that would normally represent the button
+ ; in the bitfield returned by a controller poll command
+ ; (i.e. 0=Select, 1=L3, 2=R3, 3=Start, 4=Up, 5=Right, etc.)
+The remote emits IR pulses modulated with a 38 kHz carrier, as most remotes do.
+Codes are sent as a 2460 µs "preamble" pulse followed by 24 data pulses, each of
+which can be either 1250 µs (if the respective bit is 1) or 650 µs (if the
+respective bit is 0) long. After each pulse including the preamble, the remote
+waits 530 µs before sending the next pulse.
+Every code is always sent at least 3 times in a row (more if the button is held
+down but not necessarily a multiple of 3), approximately every 45 ms. For arrow
+buttons the matrix code is sent 3 times first, then the respective controller
+button code is sent 3 times, then the sequence repeats until the button is
+released (with the total number of codes sent always being a multiple of 6 in
+this case).
In later PS2 models, Sony integrated the IR receiver into the console. Assuming
+the built-in receivers used the same circuitry as the external dongle, this may
+explain its weird behavior: the receiver was likely designed to be wired in
+parallel with one of the controller ports, and to be unresponsive until the
+remote is actually in use to avoid interfering with another controller plugged
+into the same port. Whether or not the integrated receivers are connected this
+way has not been confirmed.
+There is a second revision of the DVD remote with power and eject buttons, meant
+to be used with the PS2 models that have a built-in receiver. Weirdly enough,
+however, it seems to be incompatible with the older receiver dongle.
The I-Mode Adaptor cable (SCPH-10180) allows to connect an I-mode compatible
+mobile phone to the playstation's controller port; granting a mobile internet
+connection to japanese games.
Doko Demo Issyo (PlayStation the Best release only) (Sony) 2000
+ Doko Demo Issyo Deluxe Pack (Bomber eXpress/Sony) 2001
+ Hamster Club-I (SLPS-03266) (Jorudan) 2002
+ iMode mo Issyo: Dokodemo Issho Tsuika Disc (Bomber/Sony) 2001
+ Keitai Eddy (iPC) 2000 (but, phone connects to SIO port on REAR side of PSX?)
+ Komocchi (Victor) 2001
+ Mobile Tomodachi (Hamster) 2002
+ Motto Trump Shiyouyo! i-Mode de Grand Prix (Pure Sound) 2002
+ One Piece Mansion (Capcom) 2001 (japanese version only)
+Unknown how to detect the thing, and how to do the actual data transfers.
+The cable does contain a 64pin chip, an oscillator, and some smaller components
+(inside of the PSX controller port connector).
Keitai Eddy seems to have the phone connect to the SIO port (on rear side of
+the PSX, at least it's depicted like so on the CD cover). This is apparently
+something different than the SCPH-10180 controller-port cable. Unknown what it
+is exactly - probably some mobile internet connection too, maybe also using
+I-mode, or maybe some other protocol.
There isn't any official retail keyboard for PSX, however, there is a shitload
+of obscure ways to connect keyboards...
A PS/2 to PSX controller port adaptor. Maybe for educational Lightspan titles?
+There are two hardware variants of the adaptor:
+
Adaptor with short cable to PSX-controller port (and prototype marking)
+ Adaptor without cable, directly plugged into controller port (final version?)
+The Online Connection CD is a web browser from the educational Lightspan
+series, the CD is extremly rare (there's only one known copy of the disc).
+The thing requires a dial-up modem connected to the serial port (maybe simply
+using the same RS232 adaptor as used by Yaroze). User input can be done via
+joypad, or optionally, via some external keyboard (or keyboard adaptor)
+hardware:
+
Send 01h 42h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 06h
+ Reply HiZ 96h 5Ah num dat dat dat dat dat dat dat dat dat dat dat
+ Send .. .. .. 01h xxh FFh FFh FFh FFh FFh 00h .. .. .. ..
+ Send .. .. .. 00h .. .. .. .. .. .. 00h .. .. .. ..
+Made by Anthony Ball. [http://www.sinistersoft.com/psxkeyboard]
+ [1F801058h]=00CEh ;SIO_MODE 8bit, no parity, 2 stop bits (8N2)
+ [1F80105Ah]=771Ch ;SIO_CTRL rx enable (plus whatever nonsense bits)
+ [1F80105Eh]=006Ch ;SIO_BAUD 19200 bps
+ RX Keyboard Scancode (same ASCII-style as in later versions?)
+ CTS Caps-Lock state
+ DSR Num-Lock state
+Made by Anthony Ball. [http://www.sinistersoft.com/psxkeyboard]
+This adaptor can send pad/stick data,
+
Send 01h 42h 00h 0h 0h
+ Reply HiZ 41h 5Ah PadA
+ Send 01h 42h 00h 0h 0h 0h 0h 0h 0h 0h 0h 00h 00h 0h 0h 0h 0h 0h 0h
+ Reply HiZ E8h 5Ah PadA PadB PadC PadD Ver Lock Buffer(0..5)
+ Version=1 ; version number
+ 0 SCROLL ; scroll lock on
+ 1 NUM ; num lock on
+ 2 CAPS ; caps lock on
+ 3 DONETEST ; keyboard has just done a selftest
+ 4 EMUA ; emulation mode a
+ 5 EMUB ; emulation mode b
+ 01 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 69 1F
+ 60 21 22 68 24 25 5E 26 2A 28 29 5F 3D 2D 0B 0E 0F 67 2F 1E 2D
+ 27 51 57 45 52 54 59 55 49 4F 50 5B 5D 0D 10 61 62 37 38 39
+ 3B 41 53 44 46 47 48 4A 4B 4C 3A 40 23 34 35 36 2B
+ 02 5C 5A 58 43 56 42 4E 4D 3C 3E 3F 03 63 31 32 33
+ 04 05 06 20 07 08 09 0A 65 64 66 30 2E 6A
+ Send 01h 42h 00h 00h 00h 00h 00h
+ Reply HiZ 12h 5Ah key flg dx dy
+ bit0-1 = Always 11b (unlike Sony mouse)
+ bit2 = Left Mouse Button (0=Pressed, 1=Released)
+ bit3 = Right Mouse Button (0=Pressed, 1=Released)
+ bit4-5 = Always 11b (like Sony mouse)
+ bit6 = Key Release (aka F0h prefix) (0=Yes)
+ bit7 = Key Extended (aka E0h prefix) (0=Yes)
+Runix is a homebrew linux kernel for PSX, it can be considered being the holy
+grail of the open source scene because nobody has successfully compiled it in
+the past 16 years.
+- USB host controller SL811H driver with keyboard and mouse support;
+- RTC support.
+file: drivers/usb/sl811h.c
The PSX kernel allows to output "printf" debug messages via stdout. In the
+opposite direction, it's supporting to receive ASCII user input via
+"std_in_gets" (there isn't any software actually using that feature though,
+except maybe debug consoles like DTL-H2000).
PSX only (not PSone). Reboots the PSX via /RESET signal. Probably including for
+forcefully getting through the WHOLE BIOS Intro, making it rather
+useless/annoying? No idea if it clears ALL memory during reboot?
Status bit of the CDROM controller. Can be used to sense if the shell is opened
+(and also memorizes if the shell was opened since last check; allowing to sense
+possible disk changes).
Memory Card with built-in LCD screen and Buttons (which can be used as
+miniature handheld console). However, when it is connected to the PSX, the
+buttons are vanishing in the cartridge slot, so the buttons cannot be used as
+additional inputs for PSX games.
With an external adaptor (voltage conversion), the serial port can be used
+(among others) to connect a RS232 Serial Mouse. Although, most or all
+commercial games with mouse input are probably (?) supporting only Sony's Mouse
+(on the controller port) (rather than standard RS232 devices on the serial
+port).
If present, the external DUART can be used for external keyboard input, at the
+BIOS side, this is supported as "std_in".
SCPH-1010 digital joypad (with short cable)
+ SCPH-1080 digital joypad (with longer cable)
+ SCPH-1030 mouse (with short cable)
+ SCPH-1090 mouse (with longer cable)
+ SCPH-1092 mouse (european?)
+ SCPH-1110 analog joystick
+ SCPH-1150 analog joypad (with one vibration motor, with red/green led)
+ SCPH-1180 analog joypad (without vibration motors, with red/green led)
+ SCPH-1200 analog joypad (with two vibration motors) (dualshock)
+ SCPH-110 analog joypad (with two vibration motors) (dualshock for psone)
+ SCPH-10010 dualshock2 (analog buttons, except L3/R3/Start/Select) (for ps2)
+ SCPH-1070 multitap
+ SCPH-4010 VPick (guitar-pick controller) (for Quest for Fame, Stolen Song)
+ __________ __________
+ | | | ^ | ^
+ | L1 R1 | | X <+> O | <+> = Digital Stick
+ \ ___| <--- L2 [] ---> |___ v / v
+ | | <--- R2 /\ ---> | |
+ ___| |___________________________| |___ Not sure if all buttons
+ | | | SEL STA =?= | | | are shown at their
+ | | | | | | correct locations?
+ | | |_ [] /\ _| | | (drawing is based on
+ | _| / L1 R1 \ |_ | below riddle/lyrics)
+ | \_____/ X O \_____/ |
+ | /___\ L2 R2 /___\ |
+ | |
+ | |
+ \___________________________________________/
+ The thumb buttons on the left act as L1 and R1,
+ the trigger is L2, the pinky button is R2
+ The thumb buttons on the right act as X and O,
+ the trigger is Square and the pinky button is Triangle.
+ I find this odd as the triggers should've been L1 and R1,
+ the pinkies L2 and R2.
+ The buttons are redundantly placed on the base as large buttons like what
+ you'd see on a fight/arcade stick. Also with Start and Select.
+ There is also a physical analog mode switch,
+ not a button like on dual shock.
+The MX4SIO is a homebrew microSD card adapter for the PS2 that plugs into a
+memory card slot, taking advantage of the fact that SD cards support an SPI mode
+which is more or less compatible with SIO0. The adapter is completely passive
+and has the card wired up as follows:
| uSD pin | +Name | +Wired to MC pin | +
|---|---|---|
| 1 | +D2/NC |
+- | +
| 2 | +D3//CS |
+/CS |
+
| 3 | +CMD/MOSI |
+CMD/MOSI |
+
| 4 | +VCC |
++3.5V |
+
| 5 | +SCK |
+SCK |
+
| 6 | +GND |
+GND, /ACK |
+
| 7 | +D0/MISO |
+DAT/MISO |
+
| 8 | +D1/NC |
+- | +
Unfortunately, this design has a fatal flaw that makes it unusable as-is on the
+PS1: /ACK is permanently shorted to ground, taking down the entire controller
+bus. However, it should be possible to use the MX4SIO on a PS1 with custom
+driver code once the MX4SIO's /ACK pin is masked out with some tape, or if no
+other controllers or memory cards are plugged in.
+Note that, as SD cards do not employ the addressing scheme used by standard
+controllers and memory cards, the MX4SIO should get its own dedicated /CSn pin
+and not share the port with a controller (i.e. if the MX4SIO is plugged in slot
+2, then controller port 2 shall be left unused).
Send Reply Comment
+ 81h N/A Memory card address
+ 52h FLAG Send Read Command (ASCII "R"), Receive FLAG Byte
+ 00h 5Ah Receive Memory Card ID1
+ 00h 5Dh Receive Memory Card ID2
+ MSB (00h) Send Address MSB ;\sector number (0..3FFh)
+ LSB (pre) Send Address LSB ;/
+ 00h 5Ch Receive Command Acknowledge 1 ;<-- late /ACK after this byte-pair
+ 00h 5Dh Receive Command Acknowledge 2
+ 00h MSB Receive Confirmed Address MSB
+ 00h LSB Receive Confirmed Address LSB
+ 00h ... Receive Data Sector (128 bytes)
+ 00h CHK Receive Checksum (MSB xor LSB xor Data bytes)
+ 00h 47h Receive Memory End Byte (should be always 47h="G"=Good for Read)
+ Send Reply Comment
+ 81h N/A Memory card address
+ 57h FLAG Send Write Command (ASCII "W"), Receive FLAG Byte
+ 00h 5Ah Receive Memory Card ID1
+ 00h 5Dh Receive Memory Card ID2
+ MSB (00h) Send Address MSB ;\sector number (0..3FFh)
+ LSB (pre) Send Address LSB ;/
+ ... (pre) Send Data Sector (128 bytes)
+ CHK (pre) Send Checksum (MSB xor LSB xor Data bytes)
+ 00h 5Ch Receive Command Acknowledge 1
+ 00h 5Dh Receive Command Acknowledge 2
+ 00h 4xh Receive Memory End Byte (47h=Good, 4Eh=BadChecksum, FFh=BadSector)
+ Send Reply Comment
+ 81h N/A Memory card address
+ 53h FLAG Send Get ID Command (ASCII "S"), Receive FLAG Byte
+ 00h 5Ah Receive Memory Card ID1
+ 00h 5Dh Receive Memory Card ID2
+ 00h 5Ch Receive Command Acknowledge 1
+ 00h 5Dh Receive Command Acknowledge 2
+ 00h 04h Receive 04h
+ 00h 00h Receive 00h
+ 00h 00h Receive 00h
+ 00h 80h Receive 80h
+ Send Reply Comment
+ 81h N/A Memory card address
+ xxh FLAG Send Invalid Command (anything else than "R", "W", or "S")
+The initial value of the FLAG byte on power-up (and when re-inserting the
+memory card) is 08h.
+Bit3=1 is indicating that the directory wasn't read yet (allowing to sense
+memory card changes). For some strange reason, bit3 is NOT reset when reading
+from the card, but rather when writing to it. To reset the flag, games are
+usually issuing a dummy write to sector number 003Fh, more or less
+unneccessarily stressing the lifetime of that sector.
+Bit2=1 seems to be intended to indicate write errors, however, the write
+command seems to be always finishing without setting that bit, instead, the
+error flag may get set on the NEXT command.
+Note: Some (not all) non-sony cards also have Bit5 of the FLAG byte set.
IRQ7 is usually triggered circa 1500 cycles after sending a byte (counted from
+the begin of the first bit), except, the last byte doesn't trigger IRQ7, and,
+after the 7th byte of the Read command, an additional delay of circa 31000
+cycles occurs before IRQ7 gets triggered (that strange extra delay occurs only
+on original Sony cards, not on cards from other manufacturers).
+There seems to be no extra delays in the Write command, as it seems, the data
+is written on the fly, and one doesn't need to do any write-busy handling...
+although, theoretically, the write shouldn't start until verifying the
+checksum... so it can't be done on the fly at all...?
Responses in brackets are don't care, (00h) means usually zero, (pre) means
+usually equal to the previous command byte (eg. the response to LSB is MSB).
Memory cards are reportedly "Flash RAM" which sounds like bullshit, might be
+battery backed SRAM, or FRAM, or slower EEPROM or FLASH ROM, or vary from card
+to card...?
Total Memory 128KB = 131072 bytes = 20000h bytes
+ 1 Block 8KB = 8192 bytes = 2000h bytes
+ 1 Frame 128 bytes = 80h bytes
+ 00h-01h Memory Card ID (ASCII "MC")
+ 02h-7Eh Unused (zero)
+ 7Fh Checksum (all above bytes XORed with each other) (usually 0Eh)
+ 00h-03h Block Allocation State
+ 00000051h - In use ;first-or-only block of a file
+ 00000052h - In use ;middle block of a file (if 3 or more blocks)
+ 00000053h - In use ;last block of a file (if 2 or more blocks)
+ 000000A0h - Free ;freshly formatted
+ 000000A1h - Free ;deleted (first-or-only block of file)
+ 000000A2h - Free ;deleted (middle block of file)
+ 000000A3h - Free ;deleted (last block of file)
+ 04h-07h Filesize in bytes (2000h..1E000h; in multiples of 8Kbytes)
+ 08h-09h Pointer to the NEXT block number (minus 1) used by the file
+ (ie. 0..14 for Block Number 1..15) (or FFFFh if last-or-only block)
+ 0Ah-1Eh Filename in ASCII, terminated by 00h (max 20 chars, plus ending 00h)
+ 1Fh Zero (unused)
+ 20h-7Eh Garbage (usually 00h-filled)
+ 7Fh Checksum (all above bytes XORed with each other)
+The first some letters of the filename should indicate the game to which the
+file belongs, in case of commercial games this is conventionally done like so:
+Two character region code:
+
"BI"=Japan, "BE"=Europe, "BA"=America
+ in "AAAA-NNNNN" form ;for Pocketstation executables replace "-" by "P"
+ "abcdefgh"
+ 00h-03h Broken Sector Number (Block*64+Frame) (FFFFFFFFh=None)
+ 04h-7Eh Garbage (usually 00h-filled) (some cards have [08h..09h]=FFFFh)
+ 7Fh Checksum (all above bytes XORed with each other)
+ 00h-7Fh Data (usually FFh-filled, if there's no broken sector)
+ 00h-7Fh Unused (usually FFh-filled)
+Reportedly "write test". Usually same as Block 0 ("MC", 253 zero-bytes, plus
+checksum 0Eh).
00h-01h ID (ASCII "SC")
+ 02h Icon Display Flag
+ 11h...Icon has 1 frame (static) (same image shown forever)
+ 12h...Icon has 2 frames (animated) (changes every 16 PAL frames)
+ 13h...Icon has 3 frames (animated) (changes every 11 PAL frames)
+ Values other than 11h..13h seem to be treated as corrupted file
+ (causing the file not to be listed in the bootmenu)
+ 03h Block Number (1-15) "icon block count" Uh?
+ (usually 01h or 02h... might be block number within
+ files that occupy 2 or more blocks)
+ (actually, that kind of files seem to HAVE title frames
+ in ALL of their blocks; not only in their FIRST block)
+ (at least SOME seem to have such duplicated title frame,
+ but not all?)
+ 04h-43h Title in Shift-JIS format (64 bytes = max 32 characters)
+ 44h-4Fh Reserved (00h)
+ 50h-5Fh Reserved (00h) ;<-- this region is used for the Pocketstation
+ 60h-7Fh Icon 16 Color Palette Data (each entry is 16bit CLUT)
+ 00h-7Fh Icon Bitmap (16x16 pixels, 4bit color depth)
+ 00h-7Fh Data
+Can contain japanese or english text, english characters are encoded like so:
+
81h,40h --> SPC
+ 81h,43h..97h --> punctuation marks
+ 82h,4Fh..58h --> "0..9"
+ 82h,60h..79h --> "A..Z"
+ 82h,81h..9Ah --> "a..z"
+There are a lot of different ways to get a save from a memory card onto your
+PC's hard disk, and these ways sometimes involve sticking some additional
+information into a header at the beginning of the file.
SmartLink .PSM,
+ WinPSM .PS,
+ DataDeck .DDF,
+ FPSX .MCR,
+ ePSXe .MCD...
+All of these headers contain a signature at the top of the file. The three most
+common formats and their signatures are:
Connectix Virtual Game Station format (.MEM): "VgsM", 64 bytes
+ PlayStation Magazine format (.PSX): "PSV", 256 bytes
+some programs will OMIT any blank or unallocated blocks from the end of the
+memory card -- if only three save blocks on the card are in use, for example,
+saving the other twelve is pointless.
00h..14h Filename in ASCII, terminated by 00h (max 20 chars, plus ending 00h)
+ 15h..35h Title in ASCII, terminated by 00h (max 32 chars, plus ending 00h)
+ 36h.. File Block(s) (starting with the Title sector)
+MCS files consist of the 128 byte directory frame for the savefile's first block followed by all of that savefile's blocks in linked list order. When importing this format, the directory frame should be parsed for the save filename and the filesize while other fields should be ignored. The rest of the directory frame fields and any extra directory frames, in the case of multi-block saves, should be reconstructed based on the destination memory card.
+InterAct GME format, produced by the DexDrive.
+
000h 12 ASCII String "123-456-STD",00h
+ 00Ch 4 Usually zerofilled (or meaningless garbage in some files)
+ 010h 5 Always 00h,00h,01h,00h,01h
+ 015h 16 Copy of Sector 0..15 byte[00h] ;"M", followed by allocation states
+ 025h 16 Copy of Sector 0..15 byte[08h] ;00h, followed by next block values
+ 035h 11 Usually zerofilled (or meaningless garbage in some files)
+ 040h F00h Fifteen Description Strings (each one 100h bytes, padded with 00h)
+ F40h 128K Memory Card Image (128K) (unused sectors 00h or FFh filled)
+Sony has manufactured only 128KByte memory cards for PSX, no bigger/smaller
+ones.
A special case would be PS2 cards, these are bigger, but PS2 cards won't fit
+into PSX cards slots (unless when cutting an extra notch in the card edge
+connector), a PSX game played on a PS2 console could theoretically access PS2
+cards (if it supports the different directory structure on that cards).
Some third party cards contain larger memory chips, however, the PSX
+games/kernel are supporting only regular 128Kbyte cards, so the extra memory
+can be used only by dividing it into several 128Kbyte memory card images.
+Selecting a different memory card image can be done by a switch or button on
+the card, or via joypad key combinations (joypad/card are sharing the same
+signals, so the card could watch the traffic on joypad bus, provided that the
+MIPS CPU is actually reading the joypad).
Some cards are additionally using data compression to increase the card
+capacity, but that techinque is having rather bad reputation and could result
+in data loss. For example, if a game has allocated four blocks on the memory
+card, then it'll expect to be able to overwrite that four blocks at any time
+(without needing to handle "memory card full" errors), however, if the card is
+full, and if the newly written data has worse compression ratio, then the card
+will be unable to store the new game position (and may have already overwritten
+parts of the old game position). As a workaround, such cards may use a LED to
+warn users when running low on memory (ideally, there should be always at least
+128Kbytes of free memory).
The smart card adaptor plugs into memory card slot, and allows to use special
+credit card-shaped memory cards. There don't seem to be any special features,
+ie. the hardware setup does just behave like normal PSX memory cards.
The Datel/Interact VMEM exists as standalone VMEM cartridge, and some Datel
+Cheat Devices do also include the VMEM feature. Either way, the VMEM connects
+to expansion port, and contain some large FLASH memory, for storing multiple
+memory cards on it. Unknown, how that memory is accessed (maybe it must be
+copied to a regular memory card, or maybe they've somehow hooked the Kernel (or
+even the hardware signals?) so that games could directly access the VMEM?
Some older games are using passwords instead of memory cards to allow the user
+to continue at certain game positions. That's nice for people without memory
+card, but unfortunately many of that games are restricted to it - it'd be more
+user friendly to support both passwords, and, optionally, memory cards.
The Yaroze Access Card connects to memory card slot, the card resembles regular
+memory cards, but it doesn't contain any storage memory. Instead, it does
+merely support a very basic Access Card detection command:
+
Send Reply Comment
+ 21h N/A? Probably replies HighZ (ie. probably reads FFh)?
+ 53h 0xh? Replies unknown 8bit value (upper 4bit are known to be zero)?
+CPU Registers
+CPU Opcode Encoding
+CPU Load/Store Opcodes
+CPU ALU Opcodes
+CPU Jump Opcodes
+CPU Coprocessor Opcodes
+CPU Pseudo Opcodes
COP0 - Register Summary
+COP0 - Exception Handling
+COP0 - Misc
+COP0 - Debug Registers
All registers are 32bit wide.
+
Name Alias Common Usage
+ R0 zero Constant (always 0)
+ R1 at Assembler temporary (destroyed by some assembler pseudoinstructions!)
+ R2-R3 v0-v1 Subroutine return values, may be changed by subroutines
+ R4-R7 a0-a3 Subroutine arguments, may be changed by subroutines
+ R8-R15 t0-t7 Temporaries, may be changed by subroutines
+ R16-R23 s0-s7 Static variables, must be saved by subs
+ R24-R25 t8-t9 Temporaries, may be changed by subroutines
+ R26-R27 k0-k1 Reserved for kernel (destroyed by some IRQ handlers!)
+ R28 gp Global pointer (rarely used)
+ R29 sp Stack pointer
+ R30 fp(s8) Frame Pointer, or 9th Static variable, must be saved
+ R31 ra Return address (used so by JAL,BLTZAL,BGEZAL opcodes)
+ - pc Program counter
+ - hi,lo Multiply/divide results, may be changed by subroutines
+The CPU doesn't explicitly have stack-related registers or opcodes, however,
+conventionally, R29 is used as stack pointer (SP). The stack can be accessed
+with normal load/store opcodes, which do not automatically increase/decrease
+SP, so the SP register must be manually modified to (de-)allocate data.
+The PSX BIOS is using "Full Decrementing Wasted Stack".
+Decrementing means that SP gets decremented when allocating data (that's common
+for most CPUs) - Full means that SP points to the first ALLOCATED word on the
+stack, so the allocated memory is at SP+0 and above, free memory at SP-1 and
+below, Wasted means that when calling a sub-function with N parameters, then
+the caller must pre-allocate N works on stack, and the sub-function may freely
+use and destroy these words; at [SP+0..N*4-1].
For example, "push ra,r16,r17" would be implemented as:
+
sub sp,20h
+ mov [sp+14h],ra
+ mov [sp+18h],r16
+ mov [sp+1Ch],r17
+ [sp+00h..0Fh] wasted stack (may, or may not, be used by sub-functions)
+ [sp+10h..13h] 8-byte alignment padding (not used)
+ [sp+14h..1Fh] pushed registers
+ 00h=SPECIAL 08h=ADDI 10h=COP0 18h=N/A 20h=LB 28h=SB 30h=LWC0 38h=SWC0
+ 01h=BcondZ 09h=ADDIU 11h=COP1 19h=N/A 21h=LH 29h=SH 31h=LWC1 39h=SWC1
+ 02h=J 0Ah=SLTI 12h=COP2 1Ah=N/A 22h=LWL 2Ah=SWL 32h=LWC2 3Ah=SWC2
+ 03h=JAL 0Bh=SLTIU 13h=COP3 1Bh=N/A 23h=LW 2Bh=SW 33h=LWC3 3Bh=SWC3
+ 04h=BEQ 0Ch=ANDI 14h=N/A 1Ch=N/A 24h=LBU 2Ch=N/A 34h=N/A 3Ch=N/A
+ 05h=BNE 0Dh=ORI 15h=N/A 1Dh=N/A 25h=LHU 2Dh=N/A 35h=N/A 3Dh=N/A
+ 06h=BLEZ 0Eh=XORI 16h=N/A 1Eh=N/A 26h=LWR 2Eh=SWR 36h=N/A 3Eh=N/A
+ 07h=BGTZ 0Fh=LUI 17h=N/A 1Fh=N/A 27h=N/A 2Fh=N/A 37h=N/A 3Fh=N/A
+ 00h=SLL 08h=JR 10h=MFHI 18h=MULT 20h=ADD 28h=N/A 30h=N/A 38h=N/A
+ 01h=N/A 09h=JALR 11h=MTHI 19h=MULTU 21h=ADDU 29h=N/A 31h=N/A 39h=N/A
+ 02h=SRL 0Ah=N/A 12h=MFLO 1Ah=DIV 22h=SUB 2Ah=SLT 32h=N/A 3Ah=N/A
+ 03h=SRA 0Bh=N/A 13h=MTLO 1Bh=DIVU 23h=SUBU 2Bh=SLTU 33h=N/A 3Bh=N/A
+ 04h=SLLV 0Ch=SYSCALL 14h=N/A 1Ch=N/A 24h=AND 2Ch=N/A 34h=N/A 3Ch=N/A
+ 05h=N/A 0Dh=BREAK 15h=N/A 1Dh=N/A 25h=OR 2Dh=N/A 35h=N/A 3Dh=N/A
+ 06h=SRLV 0Eh=N/A 16h=N/A 1Eh=N/A 26h=XOR 2Eh=N/A 36h=N/A 3Eh=N/A
+ 07h=SRAV 0Fh=N/A 17h=N/A 1Fh=N/A 27h=NOR 2Fh=N/A 37h=N/A 3Fh=N/A
+ 31..26 |25..21|20..16|15..11|10..6 | 5..0 |
+ 6bit | 5bit | 5bit | 5bit | 5bit | 6bit |
+ -------+------+------+------+------+--------+------------
+ 000000 | N/A | rt | rd | imm5 | 0000xx | shift-imm
+ 000000 | rs | rt | rd | N/A | 0001xx | shift-reg
+ 000000 | rs | N/A | N/A | N/A | 001000 | jr
+ 000000 | rs | N/A | rd | N/A | 001001 | jalr
+ 000000 | <-----comment20bit------> | 00110x | sys/brk
+ 000000 | N/A | N/A | rd | N/A | 0100x0 | mfhi/mflo
+ 000000 | rs | N/A | N/A | N/A | 0100x1 | mthi/mtlo
+ 000000 | rs | rt | N/A | N/A | 0110xx | mul/div
+ 000000 | rs | rt | rd | N/A | 10xxxx | alu-reg
+ 000001 | rs | 00000| <--immediate16bit--> | bltz
+ 000001 | rs | 00001| <--immediate16bit--> | bgez
+ 000001 | rs | 10000| <--immediate16bit--> | bltzal
+ 000001 | rs | 10001| <--immediate16bit--> | bgezal
+ 00001x | <---------immediate26bit---------> | j/jal
+ 00010x | rs | rt | <--immediate16bit--> | beq/bne
+ 00011x | rs | N/A | <--immediate16bit--> | blez/bgtz
+ 001xxx | rs | rt | <--immediate16bit--> | alu-imm
+ 001111 | N/A | rt | <--immediate16bit--> | lui-imm
+ 100xxx | rs | rt | <--immediate16bit--> | load rt,[rs+imm]
+ 101xxx | rs | rt | <--immediate16bit--> | store rt,[rs+imm]
+ x1xxxx | <------coprocessor specific------> | coprocessor (see below)
+ 31..26 |25..21|20..16|15..11|10..6 | 5..0 |
+ 6bit | 5bit | 5bit | 5bit | 5bit | 6bit |
+ -------+------+------+------+------+--------+------------
+ 0100nn |0|0000| rt | rd | N/A | 000000 | MFCn rt,rd_dat ;rt = dat
+ 0100nn |0|0010| rt | rd | N/A | 000000 | CFCn rt,rd_cnt ;rt = cnt
+ 0100nn |0|0100| rt | rd | N/A | 000000 | MTCn rt,rd_dat ;dat = rt
+ 0100nn |0|0110| rt | rd | N/A | 000000 | CTCn rt,rd_cnt ;cnt = rt
+ 0100nn |0|1000|00000 | <--immediate16bit--> | BCnF target ;jump if false
+ 0100nn |0|1000|00001 | <--immediate16bit--> | BCnT target ;jump if true
+ 0100nn |1| <--------immediate25bit--------> | COPn imm25
+ 010000 |1|0000| N/A | N/A | N/A | 000001 | COP0 01h ;=TLBR, unused on PS1
+ 010000 |1|0000| N/A | N/A | N/A | 000010 | COP0 02h ;=TLBWI, unused on PS1
+ 010000 |1|0000| N/A | N/A | N/A | 000110 | COP0 06h ;=TLBWR, unused on PS1
+ 010000 |1|0000| N/A | N/A | N/A | 001000 | COP0 08h ;=TLBP, unused on PS1
+ 010000 |1|0000| N/A | N/A | N/A | 010000 | COP0 10h ;=RFE
+ 1100nn | rs | rt | <--immediate16bit--> | LWCn rt_dat,[rs+imm]
+ 1110nn | rs | rt | <--immediate16bit--> | SWCn rt_dat,[rs+imm]
+All opcodes that are marked as "N/A" in the Primary and Secondary opcode tables
+are causing a Reserved Instruction Exception (excode=0Ah).
+The unused operand bits (eg. Bit21-25 for LUI opcode) should be usually zero,
+but do not necessarily trigger exceptions if set to nonzero values.
lb rt,imm(rs) rt=[imm+rs] ;byte sign-extended
+ lbu rt,imm(rs) rt=[imm+rs] ;byte zero-extended
+ lh rt,imm(rs) rt=[imm+rs] ;halfword sign-extended
+ lhu rt,imm(rs) rt=[imm+rs] ;halfword zero-extended
+ lw rt,imm(rs) rt=[imm+rs] ;word
+The loaded data is NOT available to the next opcode, ie. the target register
+isn't updated until the next opcode has completed. So, if the next opcode tries
+to read from the load destination register, then it would (usually) receive the
+OLD value of that register (unless an IRQ occurs between the load and next
+opcode, in that case the load would complete during IRQ handling, and so, the
+next opcode would receive the NEW value).
+MFC2/CFC2 also have a 1-instruction delay until the target register is loaded with its new value (more info in the GTE section).
sb rt,imm(rs) [imm+rs]=(rt AND FFh) ;store 8bit
+ sh rt,imm(rs) [imm+rs]=(rt AND FFFFh) ;store 16bit
+ sw rt,imm(rs) [imm+rs]=rt ;store 32bit
+During an 8-bit or 16-bit store, all 32 bits of the GPR are placed on the bus.
+As such, when writing to certain 32-bit IO registers with an 8 or 16-bit store, it will behave like a 32-bit store, using the register's full value.
+The soundscope on some shells is known to rely on this, as it uses sh to write to certain DMA registers.
+If this is not properly emulated, the soundscope will hang, waiting for an interrupt that will never be fired.
Halfword addresses must be aligned by 2, word addresses must be aligned by 4,
+trying to access mis-aligned addresses will cause an exception. There's no
+alignment restriction for bytes.
lwr rt,imm(rs) load right bits of rt from memory (usually imm+0)
+ lwl rt,imm(rs) load left bits of rt from memory (usually imm+3)
+ swr rt,imm(rs) store right bits of rt to memory (usually imm+0)
+ swl rt,imm(rs) store left bits of rt to memory (usually imm+3)
+ lwl r2,$0003(t0) ;\no delay required between these
+ lwr r2,$0000(t0) ;/(although both access r2)
+ nop ;-requires load delay HERE (before reading from r2)
+ and r2,r2,0ffffh ;-access r2 (eg. reducing it to unaligned 16bit data)
+LWR/SWR transfers the right (=lower) bits of Rt, up-to 32bit memory boundary:
+
lwr/swr [N*4+0] transfer whole 32bit of Rt to/from [N*4+0..3]
+ lwr/swr [N*4+1] transfer lower 24bit of Rt to/from [N*4+1..3]
+ lwr/swr [N*4+2] transfer lower 16bit of Rt to/from [N*4+2..3]
+ lwr/swr [N*4+3] transfer lower 8bit of Rt to/from [N*4+3]
+ lwl/swl [N*4+0] transfer upper 8bit of Rt to/from [N*4+0]
+ lwl/swl [N*4+1] transfer upper 16bit of Rt to/from [N*4+0..1]
+ lwl/swl [N*4+2] transfer upper 24bit of Rt to/from [N*4+0..2]
+ lwl/swl [N*4+3] transfer whole 32bit of Rt to/from [N*4+0..3]
+Note: The aligned variant can also misused for blocking memory access on
+aligned addresses (in that case, if the address is known to be aligned, only
+one of the opcodes are needed, either LWL or LWR).... Uhhhhhhhm, OR is that NOT
+allowed... more PROBABLY that doesn't work?
add rd,rs,rt rd=rs+rt (with overflow trap)
+ addu rd,rs,rt rd=rs+rt
+ sub rd,rs,rt rd=rs-rt (with overflow trap)
+ subu rd,rs,rt rd=rs-rt
+ addi rt,rs,imm rt=rs+(-8000h..+7FFFh) (with ov.trap)
+ addiu rt,rs,imm rt=rs+(-8000h..+7FFFh)
+ slt rd,rs,rt if rs<rt (signed comparison) then rd=1 else rd=0
+ sltu rd,rs,rt if rs<rt (unsigned comparison) then rd=1 else rd=0
+ slti rt,rs,imm if rs<(sign-extended immediate in range [-8000h..+7FFFh], signed comparison) then rt=1 else rt=0
+ sltiu rt,rs,imm if rs<(sign-extended immediate in range [0..7FFFh] U [FFFF8000h..FFFFFFFFh], unsigned comparison) then rt=1 else rt=0
+ and rd,rs,rt rd = rs AND rt
+ or rd,rs,rt rd = rs OR rt
+ xor rd,rs,rt rd = rs XOR rt
+ nor rd,rs,rt rd = FFFFFFFFh XOR (rs OR rt)
+ andi rt,rs,imm rt = rs AND (0000h..FFFFh)
+ ori rt,rs,imm rt = rs OR (0000h..FFFFh)
+ xori rt,rs,imm rt = rs XOR (0000h..FFFFh)
+ sllv rd,rt,rs rd = rt SHL (rs AND 1Fh)
+ srlv rd,rt,rs rd = rt SHR (rs AND 1Fh)
+ srav rd,rt,rs rd = rt SAR (rs AND 1Fh)
+ sll rd,rt,imm rd = rt SHL (00h..1Fh)
+ srl rd,rt,imm rd = rt SHR (00h..1Fh)
+ sra rd,rt,imm rd = rt SAR (00h..1Fh)
+ lui rt,imm rt = (0000h..FFFFh) SHL 16
+ mult rs,rt hi:lo = rs*rt (signed)
+ multu rs,rt hi:lo = rs*rt (unsigned)
+ div rs,rt lo = rs/rt, hi=rs mod rt (signed)
+ divu rs,rt lo = rs/rt, hi=rs mod rt (unsigned)
+ mfhi rd rd=hi ;move from hi
+ mflo rd rd=lo ;move from lo
+ mthi rs hi=rs ;move to hi
+ mtlo rs lo=rs ;move to lo
+ __multu_execution_time_____________________________________________________
+ Fast (6 cycles) rs = 00000000h..000007FFh
+ Med (9 cycles) rs = 00000800h..000FFFFFh
+ Slow (13 cycles) rs = 00100000h..FFFFFFFFh
+ __mult_execution_time_____________________________________________________
+ Fast (6 cycles) rs = 00000000h..000007FFh, or rs = FFFFF800h..FFFFFFFFh
+ Med (9 cycles) rs = 00000800h..000FFFFFh, or rs = FFF00000h..FFFFF801h
+ Slow (13 cycles) rs = 00100000h..7FFFFFFFh, or rs = 80000000h..FFF00001h
+ __divu/div_execution_time________________________________________________
+ Fixed (36 cycles) no matter of rs and rt values
+ Opcode Rs Rt Hi/Remainder Lo/Result
+ divu 0..FFFFFFFFh 0 --> Rs FFFFFFFFh
+ div 0..+7FFFFFFFh 0 --> Rs -1
+ div -80000000h..-1 0 --> Rs +1
+ div -80000000h -1 --> 0 -80000000h
+Note that the instruction following the branch will always be executed.
+
j dest pc=(pc and F0000000h)+(imm26bit*4)
+ jal dest pc=(pc and F0000000h)+(imm26bit*4),ra=$+8
+ jr rs pc=rs
+ jalr (rd,)rs(,rd) pc=rs, rd=$+8 ;see caution
+ beq rs,rt,dest if rs=rt then pc=$+4+(-8000h..+7FFFh)*4
+ bne rs,rt,dest if rs<>rt then pc=$+4+(-8000h..+7FFFh)*4
+ bltz rs,dest if rs<0 then pc=$+4+(-8000h..+7FFFh)*4
+ bgez rs,dest if rs>=0 then pc=$+4+(-8000h..+7FFFh)*4
+ bgtz rs,dest if rs>0 then pc=$+4+(-8000h..+7FFFh)*4
+ blez rs,dest if rs<=0 then pc=$+4+(-8000h..+7FFFh)*4
+ bltzal rs,dest if rs<0 then pc=$+4+(..)*4; ra=$+8;
+ bgezal rs,dest if rs>=0 then pc=$+4+(..)*4; ra=$+8;
+jr/jalr can be used to jump to an unaligned address, in which case an address error (AdEL) exception will be raised on the next instruction fetch.
+Additionally, bltzal/bgezal will always place the return address in $ra, whether or not the branch is taken. Additionally, if rs is $ra, then the value used for the comparison is $ra's value before linking.
Caution: The JALR source code syntax varies (IDT79R3041 specs say "jalr rs,rd",
+but MIPS32 specs say "jalr rd,rs"). Moreover, JALR may not use the same
+register for both operands (eg. "jalr r31,r31") (doing so would destroy the
+target address; which is normally no problem, but it can be a problem if an IRQ
+occurs between the JALR opcode and the following branch delay opcode; in that
+case BD gets set, and EPC points "back" to the JALR opcode, so JALR is executed
+twice, with destroyed target address in second execution).
Unlike for jump/branch opcodes, exception opcodes are immediately executed (ie.
+without executing the following opcode).
+
syscall imm20 generates a system call exception
+ break imm20 generates a breakpoint exception
+ mfc# rt,rd ;rt = cop#datRd ;data regs
+ cfc# rt,rd ;rt = cop#cntRd ;control regs
+ mtc# rt,rd ;cop#datRd = rt ;data regs
+ ctc# rt,rd ;cop#cntRd = rt ;control regs
+ cop# imm25 ;exec cop# command 0..1FFFFFFh
+ lwc# rt,imm(rs) ;cop#dat_rt = [rs+imm] ;word
+ swc# rt,imm(rs) ;[rs+imm] = cop#dat_rt ;word
+ bc#f dest ;if cop#flg=false then pc=$+disp
+ bc#t dest ;if cop#flg=true then pc=$+disp
+ rfe ;return from exception (COP0)
+ tlb<xx> ;virtual memory related (COP0), unused in the PS1
+When reading from a coprocessor register, the next opcode cannot use the
+destination register as operand (much the same as the Load Delays that occur
+when reading from memory; see there for details).
+Reportedly, the Load Delay applies for the next TWO opcodes after coprocessor
+reads, but, that seems to be nonsense (the PSX does finish both COP0 and COP2
+reads after ONE opcode).
In some cases, a similar delay occurs when writing to a coprocessor register.
+COP0 is more or less free of store delays (eg. one can read from a cop0
+register immediately after writing to it), the only known exception is the cop2
+enable bit in cop0r12.bit30 (setting that cop0 bit acts delayed, and cop2 isn't
+actually enabled until after 2 clock cycles or so).
+Writing to cop2 registers has a delay of 2..3 clock cycles. In most cases, that
+is probably (?) only 2 cycles, but special cases like writing to IRGB (which
+does additionally affect IR1,IR2,IR3) take 3 cycles until the result arrives in
+all registers).
+Note that Store Delays are counted in numbers of clock cycles (not in numbers
+of opcodes). For 3 cycle delay, one must usually insert 3 cached opcodes (or
+one uncached opcode).
nop ;alias for sll r0,r0,0
+ move rd,rs ;alias for addu rd,rs,r0
+ la rx,imm32 ;load address (alias for lui rx / addiu rx)
+ li rx,imm32 ;load immediate (alias for lui rx / ori rx)
+ li rx,imm16 ;load immediate (alias for ori, range 0..FFFFh)
+ li rx,-imm15 ;load immediate (alias for addiu, range -1..-8000h)
+ li rx,imm16*10000h ;load immediate (alias for lui)
+ lw rx,imm32 ;load from address (lui rx / lw rx,rx)
+ sw rx,imm32 ;store to address (lui r1 / sw rx,r1) (destroys r1!)
+ lb,lh,lwl,lwr,lbu,lhu;as above pseudo lw
+ sb,sh,swl,swr ;as above pseudo sw (ie. also destroys r1!)
+ alu rx,op ;alias for alu rx,rx,op
+ alu(u) rx,rx,imm ;alias for alui(u) rx,rx,imm
+ jalr rx ;alias for jalr (RA,)rx(,RA)
+ subi(u) rt,rs,imm ;alias for addi(u) rt,rs,-imm
+ beqz rx,dest ;alias for beq rx,r0,dest
+ bnez rx,dest ;alias for bne rx,r0,dest
+ b dest ;alias for beq r0,r0,dest (jump relative/spasm)
+ bra dest ;alias for bgez r0, r0, dest
+ bal dest ;alias for bgezal r0, r0, dest
+ mov rx,NNNN0000h ;alias for lui rx,NNNNh
+ mov rx,0000NNNNh ;alias for or rx,r0,NNNNh ;max +FFFFh
+ mov rx,-imm15 ;alias for add rx,r0,-NNNNh ;min -8000h
+ mov rx,ry ;alias for or rx,ry,0 (or "addiu")
+ jrel dest ;alias for blez R0,dest ;relative jump
+ crel dest ;alias for callns R0,dest ;relative call
+ jz rx,dest ;alias for je rx,R0,dest
+ jnz rx,dest ;alias for jne rx,R0,dest
+ call rx ;alias for call rx,ret=RA
+ ret ;alias for jmp ra
+ subt rt,rs,imm ;alias for addt rt,rs,-imm
+ sub rt,rs,imm ;alias for add rt,rs,-imm
+ alu rx,op ;alias for alu rx,rx,op
+ neg(t) rx,ry ;alias for sub(t) rx,R0,ry
+ not rx,ry ;alias for nor rx,R0,ry
+ neg(t)/not rx ;alias for neg(t)/not rx,rx
+ setz rx,ry ;alias for setb rx,ry,1 (set if zero)
+ setnz rx,ry ;alias for setb rx,R0,ry (set if nonzero)
+ syscall/break ;alias for syscall/break 000000h
+ movp rx,imm32 ;alias for lui rx,imm16 -plus- or rx,rx,imm16)
+ mov(bhs)p rx,[imm32] ;load from address (lui rx,imm16 / mov rx,[rx+imm16])
+ movu [rs+imm] ;alias for lwr/swr [rs+imm] plus lwl/swl [rs+imm+3]
+ reti ;alias for jmp k0 plus rfe
+ push rlist ;alias for sub sp,n*4 -- mov [sp+(1..n)*4],r1..rn
+ pop rlist ;alias for mov r1..rn,[sp+(1..n)*4] -- add sp,n*4
+ pop pc,rlist ;alias for pop ra,rlist -- jmp ra
+ .mips ;select MIPS instruction set (alternately .hc05 for MC68HC05)
+ .bios ;create a .ROM file (instead of .EXE)
+ .auto_nop ;append NOPs to jumps ;unless next opcode starts with a +
+ org imm ;assume following code to be originated at address "imm"
+ db n(,n(..))) ;define 8bit data values(s) or quoted ASCII strings
+ dw n(,n(..))) ;define 16bit data values(s) (not 32bit data!)
+ dd n(,n(..))) ;define 32bit data values(s)
+ .align imm
+ 0 ;alias for immediate 0 and register R0 (whichever fits)
+ org imm ;self-explaining (but, default=$80010000 for spasm!)
+ align imm ;self-explaining (probably zeropadded?)
+ db n(,n(..))) ;define 8bit data values(s) or quoted ASCII strings
+ dh n(,n(..))) ;define 16bit data values(s)
+ dw n(,n(..))) ;define 32bit data values(s) (not 16bit data!)
+ dcb len,value ;fill <len> bytes by <value> (different as DCB on ARM CPUs)
+ xyz ;define label "xyz" at current address (without colon)
+ xyz equ n ;assign value n to xyz
+ xyz = n ;probably same/sililar as "equ"
+ ;xyz ;comments invoked with semicolon (spasm)
+ incbin file.bin ;import binary file
+ include file.asm ;import asm file
+ zero ;alias for r0
+ >imm32 ;alias for (i-(i AND 8000h))/10000h, and/or i/10000h ?
+ <imm32 ;alias for (i AND 0FFFFh), used for SW(+/-) and ORI(+)?
+ end ;N/A ;no "end" or ".end" directive needed/used by spasm
+ r1 aka at ;N/A ;some assemblers may (optionally) reject to use r1/at
+It uses "0x" for HEX values (but doesn't use "$" for registers).
+It uses "#" instead of ";" for comments.
+It uses ":" for labels (fortunately).
+The assembler has at least one directive: ".byte" (equivalent to "db" on other
+assemblers).
+I've no clue which assembler is used for that syntax... could that be the Psy-Q
+assembler?
cop0r0-r2 - N/A
+ cop0r3 - BPC - Breakpoint on execute (R/W)
+ cop0r4 - N/A
+ cop0r5 - BDA - Breakpoint on data access (R/W)
+ cop0r6 - JUMPDEST - Randomly memorized jump address (R)
+ cop0r7 - DCIC - Breakpoint control (R/W)
+ cop0r8 - BadVaddr - Bad Virtual Address (R)
+ cop0r9 - BDAM - Data Access breakpoint mask (R/W)
+ cop0r10 - N/A
+ cop0r11 - BPCM - Execute breakpoint mask (R/W)
+ cop0r12 - SR - System status register (R/W)
+ cop0r13 - CAUSE - Describes the most recently recognised exception (R)
+ cop0r14 - EPC - Return Address from Trap (R)
+ cop0r15 - PRID - Processor ID (R)
+ cop0r16-r31 - Garbage
+ cop0r32-r63 - N/A - None such (Control regs)
+Describes the most recently recognised exception
+
0-1 - Not used (zero)
+ 2-6 Excode Describes what kind of exception occured:
+ 00h INT Interrupt
+ 01h MOD Tlb modification (none such in PSX)
+ 02h TLBL Tlb load (none such in PSX)
+ 03h TLBS Tlb store (none such in PSX)
+ 04h AdEL Address error, Data load or Instruction fetch
+ 05h AdES Address error, Data store
+ The address errors occur when attempting to read
+ outside of KUseg in user mode and when the address
+ is misaligned. (See also: BadVaddr register)
+ 06h IBE Bus error on Instruction fetch
+ 07h DBE Bus error on Data load/store
+ 08h Syscall Generated unconditionally by syscall instruction
+ 09h BP Breakpoint - break instruction
+ 0Ah RI Reserved instruction
+ 0Bh CpU Coprocessor unusable
+ 0Ch Ov Arithmetic overflow
+ 0Dh-1Fh Not used
+ 7 - Not used (zero)
+ 8-15 Ip Interrupt pending field. Bit 8 and 9 are R/W, and
+ contain the last value written to them. As long
+ as any of the bits are set they will cause an
+ interrupt if the corresponding bit is set in IM.
+ 16-27 - Not used (zero)
+ 28-29 CE Contains the coprocessor number if the exception
+ occurred because of a coprocessor instuction for
+ a coprocessor which wasn't enabled in SR.
+ 30 - Not used (zero)
+ 31 BD Is set when last exception points to the
+ branch instuction instead of the instruction
+ in the branch delay slot, where the exception
+ occurred.
+ 0 IEc Current Interrupt Enable (0=Disable, 1=Enable) ;rfe pops IUp here
+ 1 KUc Current Kernel/User Mode (0=Kernel, 1=User) ;rfe pops KUp here
+ 2 IEp Previous Interrupt Enable ;rfe pops IUo here
+ 3 KUp Previous Kernel/User Mode ;rfe pops KUo here
+ 4 IEo Old Interrupt Enable ;left unchanged by rfe
+ 5 KUo Old Kernel/User Mode ;left unchanged by rfe
+ 6-7 - Not used (zero)
+ 8-15 Im 8 bit interrupt mask fields. When set the corresponding
+ interrupts are allowed to cause an exception.
+ 16 Isc Isolate Cache (0=No, 1=Isolate)
+ When isolated, all load and store operations are targetted
+ to the Data cache, and never the main memory.
+ (Used by PSX Kernel, in combination with Port FFFE0130h)
+ 17 Swc Swapped cache mode (0=Normal, 1=Swapped)
+ Instruction cache will act as Data cache and vice versa.
+ Use only with Isc to access & invalidate Instr. cache entries.
+ (Not used by PSX Kernel)
+ 18 PZ When set cache parity bits are written as 0.
+ 19 CM Shows the result of the last load operation with the D-cache
+ isolated. It gets set if the cache really contained data
+ for the addressed memory location.
+ 20 PE Cache parity error (Does not cause exception)
+ 21 TS TLB shutdown. Gets set if a programm address simultaneously
+ matches 2 TLB entries.
+ (initial value on reset allows to detect extended CPU version?)
+ 22 BEV Boot exception vectors in RAM/ROM (0=RAM/KSEG0, 1=ROM/KSEG1)
+ 23-24 - Not used (zero)
+ 25 RE Reverse endianness (0=Normal endianness, 1=Reverse endianness)
+ Reverses the byte order in which data is stored in
+ memory. (lo-hi -> hi-lo)
+ (Affects only user mode, not kernel mode) (?)
+ (The bit doesn't exist in PSX ?)
+ 26-27 - Not used (zero)
+ 28 CU0 COP0 Enable (0=Enable only in Kernel Mode, 1=Kernel and User Mode)
+ 29 CU1 COP1 Enable (0=Disable, 1=Enable) (none in PSX)
+ 30 CU2 COP2 Enable (0=Disable, 1=Enable) (GTE in PSX)
+ 31 CU3 COP3 Enable (0=Disable, 1=Enable) (none in PSX)
+ 0-31 Return Address from Exception
+If an interrupt occurs "on" a GTE command (cop2cmd), then the GTE command is
+executed, but nethertheless, the return address in EPC points to the GTE
+command. So, if the exeception handler would return to EPC as usually, then the
+GTE command would be executed twice. In best case, this would be a waste of
+clock cycles, in worst case it may lead to faulty result (if the results from
+the 1st execution are re-used as incoming parameters in the 2nd execution). To
+fix the problem, the exception handler must do:
+
if (cause AND 7Ch)=00h ;if excode=interrupt
+ if ([epc] AND FE000000h)=4A000000h ;and opcode=cop2cmd
+ epc=epc+4 ;then skip that opcode
+The RFE opcode moves some bits in cop0r12 (SR): bit2-3 are copied to bit0-1,
+and bit4-5 are copied to bit2-3, all other bits (including bit4-5) are left
+unchanged.
+The RFE opcode does NOT automatically jump to EPC. Instead, the exception
+handler must copy EPC into a register (usually R26 aka K0), and then jump to
+that address. Because of branch delays, that would look like so:
+
mov k0,epc ;get return address
+ push k0 ;save epc in memory (if you expect nested exceptions)
+ ... ;whatever (ie. process CAUSE)
+ pop k0 ;restore from memory (if you expect nested exceptions)
+ jmp k0 ;jump to K0 (after executing the next opcode)
+ +rfe ;move SR bit4/5 --> bit2/3 --> bit0/1
+Contains the address whose reference caused an exception. Set on any MMU type
+of exceptions, on references outside of kuseg (in User mode) and on any
+misaligned reference. BadVaddr is updated ONLY by Address errors (Excode 04h
+and 05h), all other exceptions (including bus errors) leave BadVaddr unchanged.
Exception BEV=0 BEV=1
+ Reset BFC00000h BFC00000h (Reset)
+ UTLB Miss 80000000h BFC00100h (Virtual memory, none such in PSX)
+ COP0 Break 80000040h BFC00140h (Debug Break)
+ General 80000080h BFC00180h (General Interrupts & Exceptions)
+ Reset At any time (highest) ;-reset
+ AdEL Memory (Load instruction) ;\
+ AdES Memory (Store instruction) ; memory (data load/store)
+ DBE Memory (Load or store) ;/
+ MOD ALU (Data TLB) ;\
+ TLBL ALU (DTLB Miss) ; none such
+ TLBS ALU (DTLB Miss) ;/
+ Ovf ALU ;-overflow
+ Int ALU ;-interrupt
+ Sys RD (Instruction Decode) ;\
+ Bp RD (Instruction Decode) ;
+ RI RD (Instruction Decode) ;
+ CpU RD (Instruction Decode) ;/
+ TLBL I-Fetch (ITLB Miss) ;-none such
+ AdEL IVA (Instruction Virtual Address) ;\memory (opcode fetch)
+ IBE RD (end of I-Fetch, lowest) ;/
+ 0-7 Revision
+ 8-15 Implementation
+ 16-31 Not used
+The is a rather strange totally useless register. After certain exceptions, the
+CPU does memorize a jump destination address in the register. Once when it has
+memorized an address, the register becomes locked, and the memorized value
+won't change until it becomes unlocked by a new exception. Exceptions that do
+unlock the register are Reset and Interrupts (cause.bit10). Exceptions that do
+NOT unlock the register are syscall/break opcodes, and software generated
+interrupts (eg. cause.bit8).
+In the unlocked state, the CPU does more or less randomly memorize one of the
+next some jump destinations - eg. the destination from the second jump after
+reset, or from a jump that occured immediately before executing the IRQ
+handler, or from a jump inside of the IRQ handler, or even from a later jump
+that occurs shortly after returning from the IRQ handler.
+The register seems to be read-only (although the Kernel initialization code
+writes 0 to it for whatever reason).
Registers 0,1,2,4,10 control virtual memory on some MIPS processors (but
+there's none such in the PSX), and Registers 32..63 (aka "control registers")
+aren't used in any MIPS processors. Trying to read any of these registers
+causes a Reserved Instruction Exception (excode=0Ah).
The PSX supports only one cop0cmd (cop0cmd=10h aka RFE). Trying to execute the
+TLBxx opcodes causes a Reserved Instruction Exception (excode=0Ah).
Not supported by the CPU. Trying to execute these opcodes causes a Coprocessor
+Unusable Exception (excode=0Bh, ie. unlike above, not 0Ah).
Trying to read these registers returns garbage (but does not trigger an
+exception). When reading one of the garbage registers shortly after reading a
+valid cop0 register, the garbage value is usually the same as that of the valid
+register. When doing the read later on, the return value is usually 00000020h,
+or when reading much later it returns 00000040h, or even 00000100h. No idea
+what is causing that effect...?
+Note: The garbage registers can be accessed (without causing an exception) even
+in "User mode with cop0 disabled" (SR.Bit1=1 and SR.Bit28=0); accessing any
+other existing cop0 registers (or executing the rfe opcode) in that state is
+causing Coprocessor Unusable Exceptions (excode=0Bh).
The COP0 debug registers seem to be PSX specific, normal R30xx CPUs like IDT's
+R3041 and R3051 don't have anything similar.
0 Automatically set by hardware upon Any break (R/W)
+ 1 Automatically set by hardware upon BPC Code break (R/W)
+ 2 Automatically set by hardware upon BDA Data break (R/W)
+ 3 Automatically set by hardware upon BDA Data-Read break (R/W)
+ 4 Automatically set by hardware upon BDA Data-Write break (R/W)
+ 5 Automatically set by hardware upon any-jump break (R/W)
+ 6-11 Not used (always zero)
+ 12-13 Jump Redirection (0=Disable, 1..3=Enable) (see note) (R/W)
+ 14-15 Unknown? (R/W)
+ 16-22 Not used (always zero)
+ 23 Super-Master Enable 1 for bit24-29
+ 24 Execution breakpoint (0=Disabled, 1=Enabled) (see BPC, BPCM)
+ 25 Data access breakpoint (0=Disabled, 1=Enabled) (see BDA, BDAM)
+ 26 Break on Data-Read (0=No, 1=Break/when Bit25=1)
+ 27 Break on Data-Write (0=No, 1=Break/when Bit25=1)
+ 28 Break on any-jump (0=No, 1=Break on branch/jump/call/etc.)
+ 29 Master Enable for bit28 (..and/or exec-break at address>=80000000h?)
+ 30 Master Enable for bit24-27
+ 31 Super-Master Enable 2 for bit24-29
+If one or both of these bits are nonzero, then the PSX seems to check for the
+following opcode sequence,
+
mov rx,[mem] ;load rx from memory
+ ... ;one or more opcodes that do not change rx
+ jmp/call rx ;jump or call to rx
+Break condition is "((addr XOR BDA) AND BDAM)=0".
Break condition is "((PC XOR BPC) AND BPCM)=0".
Additionally, the BREAK opcode can be used to create further breakpoints by
+patching the executable code. The BREAK opcode uses the same Excode value (09h)
+in CAUSE register. However, the BREAK opcode jumps to the normal exception
+handler at 80000080h (not 80000040h).
The debug registers are mis-used by "Legacy of Kain: Soul Reaver" (and maybe
+also other games) for storing libcrypt copy-protection related values (ie. just
+as a "hidden" location for storing data, not for actual debugging purposes).
+CDROM Protection - LibCrypt
The Expansion ROM header supports only Pre-Boot and Post-Boot vectors, but no
+Mid-Boot vector. Cheat Devices are often using COP0 breaks for Mid-Boot Hooks,
+either with BPC=BFC06xxxh (break address in ROM, used in older cheat
+firmwares), or with BPC=80030000h (break address in RAM aka relocated GUI
+entrypoint, used in later cheat firmwares). Moreover, aside from the Mid-Boot
+Hook, the Xplorer cheat device is also supporting a special cheat code that
+uses the COP0 break feature.
Note: COP0 debug registers are described in LSI's "L64360" datasheet, chapter
+14. And in their LR33300/LR33310 datasheet, chapter 4.
1F80108xh DMA0 channel 0 MDECin (RAM to MDEC)
+ 1F80109xh DMA1 channel 1 MDECout (MDEC to RAM)
+ 1F8010Axh DMA2 channel 2 GPU (lists + image data)
+ 1F8010Bxh DMA3 channel 3 CDROM (CDROM to RAM)
+ 1F8010Cxh DMA4 channel 4 SPU
+ 1F8010Dxh DMA5 channel 5 PIO (Expansion Port)
+ 1F8010Exh DMA6 channel 6 OTC (reverse clear OT) (GPU related)
+ 1F8010F0h DPCR - DMA Control register
+ 1F8010F4h DICR - DMA Interrupt register
+ 0-23 Memory Address where the DMA will start reading from/writing to
+ 24-31 Not used (always zero)
+For SyncMode=0 (ie. for OTC and CDROM):
+
0-15 BC Number of words (0001h..FFFFh) (or 0=10000h words)
+ 16-31 0 Not used (usually 0 for OTC, or 1 ("one block") for CDROM)
+ 0-15 BS Blocksize (words) ;for GPU/SPU max 10h, for MDEC max 20h
+ 16-31 BA Amount of blocks ;ie. total length = BS*BA words
+ 0-31 0 Not used (should be zero) (transfer ends at END-CODE in list)
+ 0 Transfer direction (0=device to RAM, 1=RAM to device)
+ 1 MADR increment per step (0=+4, 1=-4)
+ 2-7 Unused
+ 8 When 1:
+ -Burst mode: enable "chopping" (cycle stealing by CPU)
+ -Slice mode: Causes DMA to hang
+ -Linked-list mode: Transfer header before data?
+ 9-10 Transfer mode (SyncMode)
+ 0=Burst (transfer data all at once after DREQ is first asserted)
+ 1=Slice (split data into blocks, transfer next block whenever DREQ is asserted)
+ 2=Linked-list mode
+ 3=Reserved
+ 11-15 Unused
+ 16-18 Chopping DMA window size (1 << N words)
+ 19 Unused
+ 20-22 Chopping CPU window size (1 << N cycles)
+ 23 Unused
+ 24 Start transfer (0=stopped/completed, 1=start/busy)
+ 25-27 Unused
+ 28 Force transfer start without waiting for DREQ
+ 29 In forced-burst mode, pauses transfer while set.
+ In other modes, stops bit 28 from being cleared after a slice is transferred.
+ No effect when transfer was caused by a DREQ.
+ 30 Perform bus snooping (allows DMA to read from -nonexistent- cache?)
+ 31 Unused
+ 0-2 DMA0, MDECin Priority (0..7; 0=Highest, 7=Lowest)
+ 3 DMA0, MDECin Master Enable (0=Disable, 1=Enable)
+ 4-6 DMA1, MDECout Priority (0..7; 0=Highest, 7=Lowest)
+ 7 DMA1, MDECout Master Enable (0=Disable, 1=Enable)
+ 8-10 DMA2, GPU Priority (0..7; 0=Highest, 7=Lowest)
+ 11 DMA2, GPU Master Enable (0=Disable, 1=Enable)
+ 12-14 DMA3, CDROM Priority (0..7; 0=Highest, 7=Lowest)
+ 15 DMA3, CDROM Master Enable (0=Disable, 1=Enable)
+ 16-18 DMA4, SPU Priority (0..7; 0=Highest, 7=Lowest)
+ 19 DMA4, SPU Master Enable (0=Disable, 1=Enable)
+ 20-22 DMA5, PIO Priority (0..7; 0=Highest, 7=Lowest)
+ 23 DMA5, PIO Master Enable (0=Disable, 1=Enable)
+ 24-26 DMA6, OTC Priority (0..7; 0=Highest, 7=Lowest)
+ 27 DMA6, OTC Master Enable (0=Disable, 1=Enable)
+ 28-30 CPU memory access priority (0..7; 0=Highest, 7=Lowest)
+ 31 No effect, should be CPU memory access enable (R/W)
+ 0-6 Controls channel 0-6 completion interrupts in bits 24-30.
+ When 0, an interrupt only occurs when the entire transfer completes.
+ When 1, interrupts can occur for every slice and linked-list transfer.
+ No effect if the interrupt is masked by bits 16-22.
+ 7-14 Unused
+ 15 Bus error flag. Raised when transferring to/from an address outside of RAM. Forces bit 31. (R/W)
+ 16-22 Channel 0-6 interrupt mask. If enabled, channels cause interrupts as per bits 0-6.
+ 23 Master channel interrupt enable.
+ 24-30 Channel 0-6 interrupt flags. (R, write 1 to reset)
+ 31 Master interrupt flag (R)
+ IF b15=1 OR (b23=1 AND (b16-22 AND b24-30)>0) THEN b31=1 ELSE b31=0
+ (changes to 7FE358D1h after DMA transfer)
+ (stays so even after DMA transfer)
+ DMA0 MDEC.IN 01000201h (always)
+ DMA1 MDEC.OUT 01000200h (always)
+ DMA2 GPU 01000200h (VramRead), 01000201h (VramWrite), 01000401h (List)
+ DMA3 CDROM 11000000h (normal), 11400100h (chopped, rarely used)
+ DMA4 SPU 01000201h (write), 01000200h (read, rarely used)
+ DMA5 PIO 11150100h (System 573 ATAPI read), ? (System 573 ATAPI write)
+ DMA6 OTC 11000002h (always)
+GPU commands are usually sent from RAM to GP0 using DMA2 in linked list mode. In
+this mode, the DMA controller transfers words in "nodes", with the first node
+starting in the address indicated by D2_MADR.
+Each node is composed of a header word (the very first word in the node) and
+some extra words to be DMA'd before moving on to the next node. The node header
+is formatted like this:
0-23 Address of the next node (or end marker)
+ 24-31 Number of extra words to transfer for this node
+The transfer is stopped once an end marker is reached. On some (earlier?) CPU
+revisions any address with bit 23 set will be interpreted as an end marker,
+while on other revisions all bits must be set (i.e. the address must be FFFFFF).
+This change was probably necessary as later CPU versions added support for up to
+16 MB RAM addressing, which made addresses in the 800000-FFFFFC range valid.
DMA0 MDEC.IN 1 clk/word ;0110h clks per 100h words ;\plus whatever
+ DMA1 MDEC.OUT 1 clk/word ;0110h clks per 100h words ;/decompression time
+ DMA2 GPU 1 clk/word ;0110h clks per 100h words ;-plus ...
+ DMA3 CDROM/BIOS 24 clks/word ;1800h clks per 100h words ;\plus single/double
+ DMA3 CDROM/GAMES 40 clks/word ;2800h clks per 100h words ;/speed sector rate
+ DMA4 SPU 4 clks/word ;0420h clks per 100h words ;-plus ...
+ DMA5 PIO 20 clks/word ;1400h clks per 100h words ;-not actually used
+ DMA6 OTC 1 clk/word ;0110h clks per 100h words ;-plus nothing
+DMA is using DRAM Hyper Page mode, allowing it to access DRAM rows at 1 clock
+cycle per word (effectively around 17 clks per 16 words, due to required row
+address loading, probably plus some further minimal overload due to refresh
+cycles). This is making DMA much faster than CPU memory accesses (CPU DRAM
+access takes 1 opcode cycle plus 6 waitstates, ie. 7 cycles in total)
CPU is running during DMA within very strict rules. It can be kept running when
+accessing only cache, scratchpad, COP0 and GTE.
+It can also make use of the 4 entry Write queue for both RAM and I/O registers,
+see:
+Write queue
+Any read access from RAM or I/O registers or filling more than 4 entries into
+the write queue will stall the CPU until the DMA is finished.
+Additionally, the CPU operation resumes during periods when DMA gets interrupted
+(ie. after SyncMode 1 blocks, after SyncMode 2 list entries) (or in SyncMode 0
+with Chopping enabled).
The PS2's IOP has an extended DMA unit with more channels, new control registers
+and an additional chain mode (SyncMode=3). For more details, see:
+ps2tek - IOP DMA
Expansion Port can contain ROM, RAM, I/O Ports, etc. For ROM, the first 256
+bytes would contain the expansion ROM header.
For region 1, the CPU outputs a chip select signal (CPU Pin 98, /EXP).
+For region 2, the CPU doesn't produce a chip select signal (the region is
+intended to contain multiple I/O ports, which require an address decoder
+anyways, that address decoder could treat any /RD or /WR with A13=Hi and A23=Hi
+and A22=Lo as access to expansion region 2 (for /WR, A22 may be ignored;
+assuming that the BIOS is read-only).
The BIOS initalizes Expansion Region 1 to 512Kbyte with 8bit bus, and Region 2
+to 128 bytes with 8bit bus. However, the size and data bus-width of these
+regions can be changed, see:
+Memory Control
+For Region 1, 32bit reads are supported even in 8bit mode (eg. 32bit opcode
+fetches are automatically processed as four 8bit reads).
+For Region 2, only 8bit access seems to be supported (except that probably
+16bit mode allows 16bit access), anyways, larger accesses seem to cause
+exceptions... not sure if that can be disabled...?
EXP2 Dual Serial Port (for TTY Debug Terminal)
+EXP2 DTL-H2000 I/O Ports
+EXP2 Post Registers
+EXP2 Nocash Emulation Expansion
Not used by BIOS nor by any games. Seems to contain 1Mbyte RAM with 16bit
+databus (ie. 512Kx16) in DTL-H2000.
Aside from the above, the Expansion regions can be used for whatever purpose,
+however, mind that the BIOS is reading from the ROM header region, and is
+writing to the POST register (so 1F000000h-1F0000FFh and 1F802041h should be
+used only if the hardware isn't disturbed by those accesses).
+Most arcade boards have their custom I/O registers (and sometimes game ROMs)
+mapped into the EXP1 and/or EXP2 regions.
The expansion port is installed only on older PSX boards, newer PSX boards and
+all PSone boards don't have that port. However, the CPU should still output all
+expansion signals, and there should be big soldering points on the board, so
+it'd be easy to upgrade the console.
Note that A0..A23 are latched outputs, so they can be used as general purpuse
+24bit outputs, provided that the system bus isn't used for other purposes (such
+like /BIOS, /SPU, /CD accesses) (A0..A23 are not affected by Main RAM and GPU
+addressing, nor by internal I/O ports like Timer and IRQ registers).
Address Size Content
+ 1F000000h 4 Post-Boot Entrypoint (eg. 1F000100h and up)
+ 1F000004h 2Ch Post-Boot ID ("Licensed by Sony Computer Entertainment Inc.")
+ 1F000030h 50h Post-Boot TTY Message (must contain at least one 00h byte)
+ 1F000080h 4 Pre-Boot Entrypoint (eg. 1F000100h and up)
+ 1F000084h 2Ch Pre-Boot ID ("Licensed by Sony Computer Entertainment Inc.")
+ 1F0000B0h 50h Not used (should be zero, but may contain code/data/io)
+ 1F000100h .. Code, Data, I/O Ports, etc.
+The Pre-Boot function is called almost immediately after Reset, with only some
+Memory Control registers initialized, the BIOS function vectors at A0h, B0h,
+and C0h are NOT yet initialized, so the Pre-Boot function can't use them.
The Post-Boot function gets called while showing the "PS" logo, but before
+loading the .EXE file. The BIOS function vectors at A0h, B0h, and C0h are
+already installed and can be used by the Post-Boot Function.
+Note that the Post-Boot Function is called ONLY when the "PS" logo is shown
+(ie. not if the CDROM drive is empty, or if it contains an Audio CD).
One common trick to hook the Kernel after BIOS initialization, but before CDROM
+loading is to use the Pre-Boot handler to set a COP0 opcode fetch hardware
+breakpoint at 80030000h (after returning from the Pre-Boot handler, the Kernel
+will initialize important things like A0h/B0h/C0h tables, and will then break
+again when starting the GUI code at 80030000h) (this trick is used by Action
+Replay v2.0 and up).
Expansion ROMs are most commonly used in cheat devices,
+Cheat Devices
The PSX/PSone retail BIOS contains some TTY Debug Terminal code; using an
+external SCN2681 chip which can be connected to the expansion port.
+Whilst supported by all PSX/PSone retail BIOSes on software side, there aren't
+any known PSX consoles/devboards/expansions actually containing DUARTs on
+hardware side.
7-0 Data (aka Character)
+ 7 RxRTS Control (0=No, 1=Yes)
+ 6 RxINT Select (0=RxRDY, 1=FFULL)
+ 5 Error Mode (0=Char, 1=Block)
+ 4-3 Parity Mode (0=With Parity, 1=Force Parity, 2=No Parity, 3=Multidrop)
+ 2 Parity Type (0=Even, 1=Odd)
+ 1-0 Bits per Character (0=5bit, 1=6bit, 2=7bit, 3=8bit)
+ 7-6 Channel Mode (0=Normal, 1=Auto-Echo, 2=Local loop, 3=Remote loop)
+ 5 TxRTS Control (0=No, 1=Yes) (when 1 --> OP0=RTSA / OP1=RTSB)
+ 4 CTS Enable (0=No, 1=Yes) (when 1 --> IP0=CTSA / IP1=CTSB)
+ 3-0 Tx Stop Bit Length (00h..0Fh = see below)
+ 0=0.563 1=0.625 2=0.688 3=0.750 4=0.813 5=0.875 6=0.938 7=1.000
+ 8=1.563 9=1.625 A=1.688 B=1.750 C=1.813 D=1.875 E=1.938 F=2.000
+ 7-4 Rx Clock Select (0..0Ch=See Table, 0Dh=Timer, 0Eh=16xIP, 0Fh=1xIP)
+ 3-0 Tx Clock Select (0..0Ch=See Table, 0Dh=Timer, 0Eh=16xIP, 0Fh=1xIP)
+ Rate 00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch
+ Set1 50 110 134.5 200 300 600 1200 1050 2400 4800 7200 9600 38400
+ Set2 75 110 134.5 150 300 600 1200 2000 2400 4800 1800 9600 19200
+ Set3 4800 880 1076 19200 28800 57600 115200 1050 57600 4800 57600 9600 38400
+ Set4 7200 880 1076 14400 28800 57600 115200 2000 57600 4800 14400 9600 19200
+ 7 Not used (should be 0)
+ 6-4 Miscellaneous Commands (0..7 = see below)
+ 3 Disable Tx (0=No change, 1=Disable)
+ 2 Enable Tx (0=No change, 1=Enable) ;Don't use with Command 3 (Reset Rx)
+ 1 Disable Rx (0=No change, 1=Disable)
+ 0 Enable Rx (0=No change, 1=Enable) ;Don't use with Command 2 (Reset Tx)
+ 0 No command ;no effect
+ 1 Reset MR pointer ;force "FirstAccess" state for MR1A (or MR1B) access
+ 2 Reset receiver ;reset RxA (or RxB) registers, disable Rx, flush Fifo
+ 3 Reset transmitter ;reset TxA (or TxB) registers
+ 4 Reset Error Flags ;reset SRA.7-4 (or SRB.7-4) to zero
+ 5 Reset Break-Change IRQ Flag ;reset ISR.2 (or ISR.6) to zero
+ 6 Start break ;after current char, pause Tx with TxDA=Low (or TxDB=Low)
+ 7 Stop break ;output one High bit, then continue Tx (ie. undo pause)
+ 7 Input Port Change (0=No, 1=Yes) (Ack via reading IPCR) ;see ACR.3-0
+ 6 Break Change B (0=No, 1=Yes) (Ack via CRB/Command5)
+ 5 RxRDYB/FFULLB (0=No, 1=Yes) (Ack via reading data) ;see MR1B.6
+ 4 THRB Empty (TxRDYB) (0=No, 1=Yes) (Ack via writing data) ;same as SRB.2
+ 3 Counter Ready (0=No, 1=Yes) (Ack via CT_STOP)
+ 2 Break Change A (0=No, 1=Yes) (Ack via CRA/Command5)
+ 1 RxRDYA/FFULLA (0=No, 1=Yes) (Ack via reading data) ;see MR1A.6
+ 0 THRA Empty (TxRDYA) (0=No, 1=Yes) (Ack via writing data) ;same as SRA.2
+ 7 Rx Received Break* (0=No, 1=Yes) ;received 00h without stop bit
+ 6 Rx Framing Error* (0=No, 1=Yes) ;received data without stop bit
+ 5 Rx Parity Error* (0=No, 1=Yes) ;received data with bad parity
+ 4 Rx Overrun Error (0=No, 1=Yes) ;Rx FIFO full + RxShiftReg full
+ 3 Tx Underrun (TxEMT) (0=No, 1=Yes) ;both TxShiftReg and THR empty
+ 2 Tx THR Empty (TxRDY) (0=No, 1=Yes) ;same as ISR.0 / ISR.4
+ 1 Rx FIFO Full (FFULL) (0=No, 1=Yes) ;set upon 3 or more characters
+ 0 Rx FIFO Not Empty (RxRDY) (0=No, 1=Yes) ;set upon 1 or more characters
+ 7 Select Baud Rate Generator (BRG) Set (0=Set1/Set3, 1=Set2/Set4)
+ 6-4 Counter/Timer Mode and Source (see below)
+ 3-0 IP3..IP0 Change Interrupt Enable Flags (0=Off, 1=On)
+ Num Mode Clock Source
+ 0h Counter External (IP2)
+ 1h Counter TxCA - 1x clock of Channel A transmitter
+ 2h Counter TxCB - 1x clock of Channel B transmitter
+ 3h Counter Crystal or external clock (x1/CLK) divided by 16
+ 4h Timer External (IP2)
+ 5h Timer External (IP2) divided by 16
+ 6h Timer Crystal or external clock (x1/CLK)
+ 7h Timer Crystal or external clock (x1/CLK) divided by 16
+ 7-4 IP3..IP0 Change Occured Flags (0=No, 1=Yes) ;auto reset after read
+ 3-0 Current IP3-IP0 Input states (0=Low, 1=High) ;Same as IP.3-0
+ 7 Not used (always 1)
+ 6-0 Current IP6-IP0 Input states (0=Low, 1=High) ;LSBs = Same as IPCR.3-0
+ IP6 External RxB Clock ;see CSRB.7-4
+ IP5 External TxB Clock ;see CSRB.3-0
+ IP4 External RxA Clock ;see CSRA.7-4
+ IP3 External TxA Clock ;see CSRA.3-0
+ IP2 External Timer Input ;see AUX.6-4
+ IP1 Clear to Send B (CTSB) ;see MR2B.5
+ IP0 Clear to Send A (CTSA) ;see MR2A.5
+ 7-0 Change "OPR" OP7-OP0 Output states (0=No change, 1=Set/Reset)
+ 7 OP7 (0=OPR.7, 1=TxRDYB)
+ 6 OP6 (0=OPR.6, 1=TxRDYA)
+ 5 OP5 (0=OPR.5, 1=RxRDY/FFULLB)
+ 4 OP4 (0=OPR.4, 1=RxRDY/FFULLA)
+ 3-2 OP3 (0=OPR.3, 1=Clock/Timer Output, 2=TxCB(1x), 3=RxCB(1x))
+ 1-0 OP2 (0=OPR.2, 1=TxCA(16x), 2=TxCA(1x), 3=RxCA(1x))
+ 7-0 Not used (just issue a dummy-read to toggle the test mode on/off)
+ 7-0 Not used (just issue a dummy-read to strobe start/stop command)
+The CTLR/CTUR reload value is copied to CTL/CTU upon Start Counter Command. In
+Timer mode (not in Counter mode), it is additionally copied automatically when
+the timer undeflows.
Reserved.
The SCN2681 is manufactured with 24..44 pins, the differences are:
+
24pin basic cut-down version ;without IP0-1/OP0-1 = without CTS/RTS
+ 28pin additional IP2,OP0,OP1,X2 ;without IP0-1 = without CTS
+ 40pin additional IP0-IP6,OP0-OP7,X2 ;full version
+ 44pin same as 40pin with four NC pins ;full version (SMD)
+Unknown if the Interrupt signal is connected to the PSX... there seems to be no
+spare IRQ for it, though it \<might> share an IRQ with whatever other
+hardware...?
+The BIOS seems to use only one of the two channels; for the std_io functions:
+BIOS TTY Console (std_io)
+Aside from the external DUART, the PSX additionally contains an internal UART,
+Serial Interfaces (SIO)
+The DTL-H2000 devboard uses a non-serial "ATCONS" channel for TTY stuff,
+EXP2 DTL-H2000 I/O Ports
The DTL-H2000 contains extended 8Mbyte Main RAM (instead of normal 2Mbyte),
+plus additional 1MByte RAM in Expansion Area at 1FA00000h, plus some I/O ports
+at 1F8020xxh:
0 Unknown, used for something
+ 1 Unknown/unused
+ 2 Unknown, used for something
+ 3 TTY/Atcons TX Ready (0=Busy, 1=Ready)
+ 4 TTY/Atcons RX Available (0=None, 1=Yes)
+ 5-7 Unknown/unused
+ 0-7 TTY/Atcons RX/TX Data
+ 0-15 Data...?
+This register does expand IRQ10 (Lightgun) to more than one IRQ source. The
+register contains only Secondary IRQ Flags (there seem to be no Secondary IRQ
+Enable bits; at least not for Lightguns).
+
0 ... used for something
+ 1 Lightgun IRQ (write: 0=No change, 1=Acknowledge) (read: 0=None, 1=IRQ)
+ 2-3 Unknown/unused (write: 0=Normal)
+ 4 ... acknowledged at 1FA00B04h, otherwise unused
+ 5 ... TTY RX ?
+ 6-7 Unknown/unused (write: 0=Normal)
+ 8-31 Not used by DTL-H2000 BIOS (but Lightgun games write 0 to these bits)
+ IF [BFC00104h]=00002000h then Port 1F802030h does exist (DTL-H2000)
+ IF [BFC00104h]=00002500h then Port 1F802030h does NOT exist
+ IF [BFC00104h]=00000003h then Port 1F802030h does NOT exist (default)
+ IF [BFC00104h]= <other> then Port 1F802030h does NOT exist
+ 0 Used for something (CLEARED on some occassions)
+ 1-3 Unknown/unused
+ 4 Used for something (SET on some occassions)
+ 5-7 Unknown/unused
+ 0-7 DIP Value (00h..FFh, but should be usually 00h..02h)
+ DIP=0 --> .. long delay before TTY? with "PSX>" prompt, throws CDROM cmds
+ DIP=1 --> .. long delay before TTY? no "PSX>" prompt PSY-Q?
+ DIP=2 --> .. instant TTY? with "PSX>" prompt
+ DIP=3 --> Lockup
+ DIP=04h..FFh --> Lockup with POST=04h..FFh
+ 0-3 Current Boot Status (00h..0Fh)
+ 4-7 Not used by BIOS (always set to 0)
+ 0-7 Post/LED value
+Might be a configuration port, or it's another POST register (which is used
+prior to writing the normal POST bytes to 1FA00000h).
+The first write to 1F802070h is 32bit, all further writes seem to be 8bit.
Similar to POST, but PS2 BIOS uses this address.
Contains ID and Version.
Activates the Halt and Turbo Registers (when set to "ON").
When enabled (see above), doing an 8bit read from this address stops the CPU
+emulation unless/until an Interrupt occurs (when "CAUSE AND SR AND FF00h"
+becomes nonzero). Can be used to reduce power consumption, and to make the
+emulation faster.
When enabled (see above), writing to this register activates/deactivates
+"turbo" mode, which is causing new data to arrive immediately after
+acknowledging the previous interrupt.
+
0 CDROM Turbo (0=Normal, 1=Turbo)
+ 1 Memory Card Turbo (0=Normal, 1=Turbo)
+ 2 Controller Turbo (0=Normal, 1=Turbo)
+ 3-7 Reserved (must be zero)
+PCSX-Redux contains some specific hardware registers for the purpose of testing and debugging. +They are located past the 1F802080h address, which means that accessing them on the real +hardware will cause an exception, unless the 1F80101Ch register has been set to +be at least twice its normal size.
+Identification string. Use this to query that your binary is running under PCSX-Redux.
+Adds this character to the console output. This is an easier way to write to the console than using the BIOS.
+Causes a debug breakpoint to be triggered. PCSX-Redux will pause and the user will be alerted of a software breakpoint.
+Sets the exit code for the program. When in test mode, PCSX-Redux will exit with this code.
+Displays a pop-up message to the user with the specified string.
+See PCSX-Redux's documentation for more details and examples.
+ + + + + + +GTE Overview
+GTE Registers
+GTE Saturation
+GTE Opcode Summary
+GTE Coordinate Calculation Commands
+GTE General Purpose Calculation Commands
+GTE Color Calculation Commands
+GTE Division Inaccuracy
The GTE doesn't have any memory or I/O ports mapped to the CPU memory bus,
+instead, it's solely accessed via coprocessor opcodes:
+
mov cop0r12,rt ;-enable/disable COP2 (GTE) via COP0 status register
+ mov cop2r0-63,rt ;\write parameters to GTE registers
+ mov cop2r0-31,[rs+imm] ;/
+ mov cop2cmd,imm25 ;-issue GTE command
+ mov rt,cop2r0-63 ;\read results from GTE registers
+ mov [rs+imm],cop2r0-31 ;/
+ jt cop2flg,dest ;-jump never ;\implemented (no exception), but,
+ jf cop2flg,dest ;-jump always ;/flag seems to be always "false"
+Using CFC2/MFC2 has a delay of 1 instruction until the GPR is loaded with its new value.
+Certain games are sensitive to this, with the notable example of Tekken 2
+which will be filled with broken geometry on emulators which don't emulate this properly.
+GTE (memory-?) load and store instructions have a delay of 2 instructions, for
+any GTE commands or operations accessing that register. Any? That's wrong!
+GTE instructions and functions should not be used in
+
- Delay slots of jumps and branches
+ - Event handlers or interrupts (sounds like nonsense?) (need push/pop though)
+ 31-25 Must be 0100101b for "COP2 imm25" instructions
+ 20-24 Fake GTE Command Number (00h..1Fh) (ignored by hardware)
+ 19 sf - Shift Fraction in IR registers (0=No fraction, 1=12bit fraction)
+ 17-18 MVMVA Multiply Matrix (0=Rotation. 1=Light, 2=Color, 3=Reserved)
+ 15-16 MVMVA Multiply Vector (0=V0, 1=V1, 2=V2, 3=IR/long)
+ 13-14 MVMVA Translation Vector (0=TR, 1=BK, 2=FC/Bugged, 3=None)
+ 11-12 Always zero (ignored by hardware)
+ 10 lm - Saturate IR1,IR2,IR3 result (0=To -8000h..+7FFFh, 1=To 0..+7FFFh)
+ 6-9 Always zero (ignored by hardware)
+ 0-5 Real GTE Command Number (00h..3Fh) (used by hardware)
+ cop2r0-1 3xS16 VXY0,VZ0 Vector 0 (X,Y,Z)
+ cop2r2-3 3xS16 VXY1,VZ1 Vector 1 (X,Y,Z)
+ cop2r4-5 3xS16 VXY2,VZ2 Vector 2 (X,Y,Z)
+ cop2r6 4xU8 RGBC Color/code value
+ cop2r7 1xU16 OTZ Average Z value (for Ordering Table)
+ cop2r8 1xS16 IR0 16bit Accumulator (Interpolate)
+ cop2r9-11 3xS16 IR1,IR2,IR3 16bit Accumulator (Vector)
+ cop2r12-15 6xS16 SXY0,SXY1,SXY2,SXYP Screen XY-coordinate FIFO (3 stages)
+ cop2r16-19 4xU16 SZ0,SZ1,SZ2,SZ3 Screen Z-coordinate FIFO (4 stages)
+ cop2r20-22 12xU8 RGB0,RGB1,RGB2 Color CRGB-code/color FIFO (3 stages)
+ cop2r23 4xU8 (RES1) Prohibited
+ cop2r24 1xS32 MAC0 32bit Maths Accumulators (Value)
+ cop2r25-27 3xS32 MAC1,MAC2,MAC3 32bit Maths Accumulators (Vector)
+ cop2r28-29 1xU15 IRGB,ORGB Convert RGB Color (48bit vs 15bit)
+ cop2r30-31 2xS32 LZCS,LZCR Count Leading-Zeroes/Ones (sign bits)
+ cop2r32-36 9xS16 RT11RT12,..,RT33 Rotation matrix (3x3) ;cnt0-4
+ cop2r37-39 3x 32 TRX,TRY,TRZ Translation vector (X,Y,Z) ;cnt5-7
+ cop2r40-44 9xS16 L11L12,..,L33 Light source matrix (3x3) ;cnt8-12
+ cop2r45-47 3x 32 RBK,GBK,BBK Background color (R,G,B) ;cnt13-15
+ cop2r48-52 9xS16 LR1LR2,..,LB3 Light color matrix source (3x3) ;cnt16-20
+ cop2r53-55 3x 32 RFC,GFC,BFC Far color (R,G,B) ;cnt21-23
+ cop2r56-57 2x 32 OFX,OFY Screen offset (X,Y) ;cnt24-25
+ cop2r58 BuggyU16 H Projection plane distance. ;cnt26
+ cop2r59 S16 DQA Depth queing parameter A (coeff) ;cnt27
+ cop2r60 32 DQB Depth queing parameter B (offset);cnt28
+ cop2r61-62 2xS16 ZSF3,ZSF4 Average Z scale factors ;cnt29-30
+ cop2r63 U20 FLAG Returns any calculation errors ;cnt31
+Note in some functions format is different from the one that's given here.
Rotation matrix (RT) Light matrix (LLM) Light Color matrix (LCM)
+ cop2r32.lsbs=RT11 cop2r40.lsbs=L11 cop2r48.lsbs=LR1
+ cop2r32.msbs=RT12 cop2r40.msbs=L12 cop2r48.msbs=LR2
+ cop2r33.lsbs=RT13 cop2r41.lsbs=L13 cop2r49.lsbs=LR3
+ cop2r33.msbs=RT21 cop2r41.msbs=L21 cop2r49.msbs=LG1
+ cop2r34.lsbs=RT22 cop2r42.lsbs=L22 cop2r50.lsbs=LG2
+ cop2r34.msbs=RT23 cop2r42.msbs=L23 cop2r50.msbs=LG3
+ cop2r35.lsbs=RT31 cop2r43.lsbs=L31 cop2r51.lsbs=LB1
+ cop2r35.msbs=RT32 cop2r43.msbs=L32 cop2r51.msbs=LB2
+ cop2r36 =RT33 cop2r44 =L33 cop2r52 =LB3
+ cop2r37 (cnt5) - TRX - Translation vector X (R/W?)
+ cop2r38 (cnt6) - TRY - Translation vector Y (R/W?)
+ cop2r39 (cnt7) - TRZ - Translation vector Z (R/W?)
+ cop2r45 (cnt13) - RBK - Background color red component
+ cop2r46 (cnt14) - GBK - Background color green component
+ cop2r47 (cnt15) - BBK - Background color blue component
+ cop2r53 (cnt21) - RFC - Far color red component
+ cop2r54 (cnt22) - GFC - Far color green component
+ cop2r55 (cnt23) - BFC - Far color blue component
+ cop2r56 (cnt24) - OFX - Screen offset X
+ cop2r57 (cnt25) - OFY - Screen offset Y
+ cop2r58 (cnt26) - H - Projection plane distance
+ cop2r59 (cnt27) - DQA - Depth queing parameter A.(coeff.)
+ cop2r60 (cnt28) - DQB - Depth queing parameter B.(offset.)
+ cop2r61 (cnt29) ZSF3 | 0|ZSF3 1,3,12| Z3 average scale factor (normally 1/3)
+ cop2r62 (cnt30) ZSF4 | 0|ZSF4 1,3,12| Z4 average scale factor (normally 1/4)
+ cop2r7 OTZ (R) | |OTZ 0,15, 0| Average Z value (for Ordering Table)
+ cop2r12 - SXY0 rw|SY0 1,15, 0|SX0 1,15, 0| Screen XY fifo (older)
+ cop2r13 - SXY1 rw|SY1 1,15, 0|SX1 1,15, 0| Screen XY fifo (old)
+ cop2r14 - SXY2 rw|SY2 1,15, 0|SX2 1,15, 0| Screen XY fifo (new)
+ cop2r15 - SXYP rw|SYP 1,15, 0|SXP 1,15, 0| SXY2-mirror with move-on-write
+ cop2r16 - SZ0 rw| 0|SZ0 0,16, 0| Screen Z fifo (oldest)
+ cop2r17 - SZ1 rw| 0|SZ1 0,16, 0| Screen Z fifo (older)
+ cop2r18 - SZ2 rw| 0|SZ2 0,16, 0| Screen Z fifo (old)
+ cop2r19 - SZ3 rw| 0|SZ3 0,16, 0| Screen Z fifo (new)
+ Vector 0 (V0) Vector 1 (V1) Vector 2 (V2) Vector 3 (IR)
+ cop2r0.lsbs - VX0 cop2r2.lsbs - VX1 cop2r4.lsbs - VX2 cop2r9 - IR1
+ cop2r0.msbs - VY0 cop2r2.msbs - VY1 cop2r4.msbs - VY2 cop2r10 - IR2
+ cop2r1 - VZ0 cop2r3 - VZ1 cop2r5 - VZ2 cop2r11 - IR3
+ cop2r6 - RGBC rw|CODE |B |G |R | Color/code
+ cop2r20 - RGB0 rw|CD0 |B0 |G0 |R0 | Characteristic color fifo.
+ cop2r21 - RGB1 rw|CD1 |B1 |G1 |R1 |
+ cop2r22 - RGB2 rw|CD2 |B2 |G2 |R2 |
+ cop2r23 - (RES1) | | Prohibited
+ cop2r8 IR0 rw|Sign |IR0 1, 3,12| Intermediate value 0.
+ cop2r24 MAC0 rw|MAC0 1,31,0 | Sum of products value 0
+ cop2r25 MAC1 rw|MAC1 1,31,0 | Sum of products value 1
+ cop2r26 MAC2 rw|MAC2 1,31,0 | Sum of products value 2
+ cop2r27 MAC3 rw|MAC3 1,31,0 | Sum of products value 3
+Expands 5:5:5 bit RGB (range 0..1Fh) to 16:16:16 bit RGB (range 0000h..0F80h).
+
0-4 Red (0..1Fh) (R/W) ;multiplied by 80h, and written to IR1
+ 5-9 Green (0..1Fh) (R/W) ;multiplied by 80h, and written to IR2
+ 10-14 Blue (0..1Fh) (R/W) ;multiplied by 80h, and written to IR3
+ 15-31 Not used (always zero) (Read only)
+Collapses 16:16:16 bit RGB (range 0000h..0F80h) to 5:5:5 bit RGB (range
+0..1Fh). Negative values (8000h..FFFFh/80h) are saturated to 00h, large
+positive values (1000h..7FFFh/80h) are saturated to 1Fh, there are no overflow
+or saturation flags set in cop2r63 though.
+
0-4 Red (0..1Fh) (R) ;IR1 divided by 80h, saturated to +00h..+1Fh
+ 5-9 Green (0..1Fh) (R) ;IR2 divided by 80h, saturated to +00h..+1Fh
+ 10-14 Blue (0..1Fh) (R) ;IR3 divided by 80h, saturated to +00h..+1Fh
+ 15-31 Not used (always zero) (Read only)
+Reading LZCR returns the leading 0 count of LZCS if LZCS is positive and the
+leading 1 count of LZCS if LZCS is negative. The results are in range 1..32.
See GTE Saturation chapter.
Maths overflows are indicated in FLAG register. In most cases, the result is
+saturated to MIN/MAX values (except MAC0,MAC1,MAC2,MAC3 which aren't
+saturated). For IR1,IR2,IR3 many commands allow to select the MIN value via
+"lm" bit of the GTE opcode (though not all commands, RTPS/RTPT always act as if
+lm=0).
31 Error Flag (Bit30..23, and 18..13 ORed together) (Read only)
+ 30 MAC1 Result larger than 43 bits and positive
+ 29 MAC2 Result larger than 43 bits and positive
+ 28 MAC3 Result larger than 43 bits and positive
+ 27 MAC1 Result larger than 43 bits and negative
+ 26 MAC2 Result larger than 43 bits and negative
+ 25 MAC3 Result larger than 43 bits and negative
+ 24 IR1 saturated to +0000h..+7FFFh (lm=1) or to -8000h..+7FFFh (lm=0)
+ 23 IR2 saturated to +0000h..+7FFFh (lm=1) or to -8000h..+7FFFh (lm=0)
+ 22 IR3 saturated to +0000h..+7FFFh (lm=1) or to -8000h..+7FFFh (lm=0)
+ 21 Color-FIFO-R saturated to +00h..+FFh
+ 20 Color-FIFO-G saturated to +00h..+FFh
+ 19 Color-FIFO-B saturated to +00h..+FFh
+ 18 SZ3 or OTZ saturated to +0000h..+FFFFh
+ 17 Divide overflow. RTPS/RTPT division result saturated to max=1FFFFh
+ 16 MAC0 Result larger than 31 bits and positive
+ 15 MAC0 Result larger than 31 bits and negative
+ 14 SX2 saturated to -0400h..+03FFh
+ 13 SY2 saturated to -0400h..+03FFh
+ 12 IR0 saturated to +0000h..+1000h
+ 0-11 Not used (always zero) (Read only)
+ Opc Name Clk Expl.
+ 00h - N/A (modifies similar registers than RTPS...)
+ 01h RTPS 15 Perspective Transformation single
+ 0xh - N/A
+ 06h NCLIP 8 Normal clipping
+ 0xh - N/A
+ 0Ch OP(sf) 6 Cross product of 2 vectors
+ 0xh - N/A
+ 10h DPCS 8 Depth Cueing single
+ 11h INTPL 8 Interpolation of a vector and far color vector
+ 12h MVMVA 8 Multiply vector by matrix and add vector (see below)
+ 13h NCDS 19 Normal color depth cue single vector
+ 14h CDP 13 Color Depth Que
+ 15h - N/A
+ 16h NCDT 44 Normal color depth cue triple vectors
+ 1xh - N/A
+ 1Bh NCCS 17 Normal Color Color single vector
+ 1Ch CC 11 Color Color
+ 1Dh - N/A
+ 1Eh NCS 14 Normal color single
+ 1Fh - N/A
+ 20h NCT 30 Normal color triple
+ 2xh - N/A
+ 28h SQR(sf)5 Square of vector IR
+ 29h DCPL 8 Depth Cue Color light
+ 2Ah DPCT 17 Depth Cueing triple (should be fake=08h, but isn't)
+ 2xh - N/A
+ 2Dh AVSZ3 5 Average of three Z values
+ 2Eh AVSZ4 6 Average of four Z values
+ 2Fh - N/A
+ 30h RTPT 23 Perspective Transformation triple
+ 3xh - N/A
+ 3Dh GPF(sf)5 General purpose interpolation
+ 3Eh GPL(sf)5 General purpose interpolation with base
+ 3Fh NCCT 39 Normal Color Color triple vector
+The fake opcode number in bit20-24 has absolutely no effect on the hardware, it
+seems to be solely used to (or not to) confuse developers. Having the opcodes
+sorted by their fake numbers gives a more or less well arranged list:
+
Fake Name Clk Expl.
+ 00h - N/A
+ 01h RTPS 15 Perspective Transformation single
+ 02h RTPT 23 Perspective Transformation triple
+ 03h - N/A
+ 04h MVMVA 8 Multiply vector by matrix and add vector (see below)
+ 05h - N/A
+ 06h DCPL 8 Depth Cue Color light
+ 07h DPCS 8 Depth Cueing single
+ 08h DPCT 17 Depth Cueing triple (should be fake=08h, but isn't)
+ 09h INTPL 8 Interpolation of a vector and far color vector
+ 0Ah SQR(sf)5 Square of vector IR
+ 0Bh - N/A
+ 0Ch NCS 14 Normal color single
+ 0Dh NCT 30 Normal color triple
+ 0Eh NCDS 19 Normal color depth cue single vector
+ 0Fh NCDT 44 Normal color depth cue triple vectors
+ 10h NCCS 17 Normal Color Color single vector
+ 11h NCCT 39 Normal Color Color triple vector
+ 12h CDP 13 Color Depth Que
+ 13h CC 11 Color Color
+ 14h NCLIP 8 Normal clipping
+ 15h AVSZ3 5 Average of three Z values
+ 16h AVSZ4 6 Average of four Z values
+ 17h OP(sf) 6 Cross product of 2 vectors
+ 18h - N/A
+ 19h GPF(sf)5 General purpose interpolation
+ 1Ah GPL(sf)5 General purpose interpolation with base
+ 1Bh - N/A
+ 1Ch - N/A
+ 1Dh - N/A
+ 1Eh - N/A
+ 1Fh - N/A
+The LZCS/LZCR registers offer a Count-Leading-Zeroes/Leading-Ones function.
+The IRGB/ORGB registers allow to convert between 48bit and 15bit RGB colors.
+These registers work without needing to send any COP2 commands. However, unlike
+for commands (which do automatically halt the CPU when needed), one must insert
+dummy opcodes between writing and reading the registers.
RTPS performs final Rotate, translate and perspective transformation on vertex
+V0. Before writing to the FIFOs, the older entries are moved one stage down.
+RTPT is same as RTPS, but repeats for V1 and V2. The "sf" bit should be usually
+set.
+
IR1 = MAC1 = (TRX*1000h + RT11*VX0 + RT12*VY0 + RT13*VZ0) SAR (sf*12)
+ IR2 = MAC2 = (TRY*1000h + RT21*VX0 + RT22*VY0 + RT23*VZ0) SAR (sf*12)
+ IR3 = MAC3 = (TRZ*1000h + RT31*VX0 + RT32*VY0 + RT33*VZ0) SAR (sf*12)
+ SZ3 = MAC3 SAR ((1-sf)*12) ;ScreenZ FIFO 0..+FFFFh
+ MAC0=(((H*20000h/SZ3)+1)/2)*IR1+OFX, SX2=MAC0/10000h ;ScrX FIFO -400h..+3FFh
+ MAC0=(((H*20000h/SZ3)+1)/2)*IR2+OFY, SY2=MAC0/10000h ;ScrY FIFO -400h..+3FFh
+ MAC0=(((H*20000h/SZ3)+1)/2)*DQA+DQB, IR0=MAC0/1000h ;Depth cueing 0..+1000h
+ MAC0 = SX0*SY1 + SX1*SY2 + SX2*SY0 - SX0*SY2 - SX1*SY0 - SX2*SY1
+ MAC0 = ZSF3*(SZ1+SZ2+SZ3) ;for AVSZ3
+ MAC0 = ZSF4*(SZ0+SZ1+SZ2+SZ3) ;for AVSZ4
+ OTZ = MAC0/1000h ;for both (saturated to 0..FFFFh)
+Multiply vector by matrix and vector addition.
+
Mx = matrix specified by mx ;RT/LLM/LCM - Rotation, light or color matrix
+ Vx = vector specified by v ;V0, V1, V2, or [IR1,IR2,IR3]
+ Tx = translation vector specified by cv ;TR or BK or Bugged/FC, or None
+ MAC1 = (Tx1*1000h + Mx11*Vx1 + Mx12*Vx2 + Mx13*Vx3) SAR (sf*12)
+ MAC2 = (Tx2*1000h + Mx21*Vx1 + Mx22*Vx2 + Mx23*Vx3) SAR (sf*12)
+ MAC3 = (Tx3*1000h + Mx31*Vx1 + Mx32*Vx2 + Mx33*Vx3) SAR (sf*12)
+ [IR1,IR2,IR3] = [MAC1,MAC2,MAC3]
+ [MAC1,MAC2,MAC3] = [IR1*IR1,IR2*IR2,IR3*IR3] SHR (sf*12)
+ [IR1,IR2,IR3] = [MAC1,MAC2,MAC3] ;IR1,IR2,IR3 saturated to max 7FFFh
+ [MAC1,MAC2,MAC3] = [IR3*D2-IR2*D3, IR1*D3-IR3*D1, IR2*D1-IR1*D2] SAR (sf*12)
+ [IR1,IR2,IR3] = [MAC1,MAC2,MAC3] ;copy result
+The LZCS/LZCR registers offer a Count-Leading-Zeroes/Leading-Ones function.
In: V0=Normal vector (for triple variants repeated with V1 and V2),
+BK=Background color, RGBC=Primary color/code, LLM=Light matrix, LCM=Color
+matrix, IR0=Interpolation value.
+
[IR1,IR2,IR3] = [MAC1,MAC2,MAC3] = (LLM*V0) SAR (sf*12)
+ [IR1,IR2,IR3] = [MAC1,MAC2,MAC3] = (BK*1000h + LCM*IR) SAR (sf*12)
+ [MAC1,MAC2,MAC3] = [R*IR1,G*IR2,B*IR3] SHL 4 ;<--- for NCDx/NCCx
+ [MAC1,MAC2,MAC3] = MAC+(FC-MAC)*IR0 ;<--- for NCDx only
+ [MAC1,MAC2,MAC3] = [MAC1,MAC2,MAC3] SAR (sf*12) ;<--- for NCDx/NCCx
+ Color FIFO = [MAC1/16,MAC2/16,MAC3/16,CODE], [IR1,IR2,IR3] = [MAC1,MAC2,MAC3]
+In: [IR1,IR2,IR3]=Vector, RGBC=Primary color/code, LCM=Color matrix,
+BK=Background color, and, for CDP, IR0=Interpolation value, FC=Far color.
+
[IR1,IR2,IR3] = [MAC1,MAC2,MAC3] = (BK*1000h + LCM*IR) SAR (sf*12)
+ [MAC1,MAC2,MAC3] = [R*IR1,G*IR2,B*IR3] SHL 4
+ [MAC1,MAC2,MAC3] = MAC+(FC-MAC)*IR0 ;<--- for CDP only
+ [MAC1,MAC2,MAC3] = [MAC1,MAC2,MAC3] SAR (sf*12)
+ Color FIFO = [MAC1/16,MAC2/16,MAC3/16,CODE], [IR1,IR2,IR3] = [MAC1,MAC2,MAC3]
+In: [IR1,IR2,IR3]=Vector, FC=Far Color, IR0=Interpolation value, CODE=MSB of
+RGBC, and, for DCPL, R,G,B=LSBs of RGBC.
+
[MAC1,MAC2,MAC3] = [R*IR1,G*IR2,B*IR3] SHL 4 ;<--- for DCPL only
+ [MAC1,MAC2,MAC3] = [IR1,IR2,IR3] SHL 12 ;<--- for INTPL only
+ [MAC1,MAC2,MAC3] = [R,G,B] SHL 16 ;<--- for DPCS/DPCT
+ [MAC1,MAC2,MAC3] = MAC+(FC-MAC)*IR0
+ [MAC1,MAC2,MAC3] = [MAC1,MAC2,MAC3] SAR (sf*12)
+ Color FIFO = [MAC1/16,MAC2/16,MAC3/16,CODE], [IR1,IR2,IR3] = [MAC1,MAC2,MAC3]
+ [MAC1,MAC2,MAC3] = [0,0,0] ;<--- for GPF only
+ [MAC1,MAC2,MAC3] = [MAC1,MAC2,MAC3] SHL (sf*12) ;<--- for GPL only
+ [MAC1,MAC2,MAC3] = (([IR1,IR2,IR3] * IR0) + [MAC1,MAC2,MAC3]) SAR (sf*12)
+ Color FIFO = [MAC1/16,MAC2/16,MAC3/16,CODE], [IR1,IR2,IR3] = [MAC1,MAC2,MAC3]
+ [IR1,IR2,IR3] = (([RFC,GFC,BFC] SHL 12) - [MAC1,MAC2,MAC3]) SAR (sf*12)
+ [MAC1,MAC2,MAC3] = (([IR1,IR2,IR3] * IR0) + [MAC1,MAC2,MAC3])
+Works like MVMVA command (see there), but with fixed Tx/Vx/Mx parameters, the
+sf/lm bits can be changed and do affect the results (although normally both
+bits should be set for use with color matrices).
The 8bit RGB values written to the top of Color Fifo are the 32bit MACn values
+divided by 16, and saturated to +00h..+FFh, and of course, the older Fifo
+entries are moved downwards. Note that, at the GPU side, the meaning of the RGB
+values depends on whether or not texture blending is used (for untextured
+polygons FFh is max brightness) (for texture blending FFh is double brightness
+and 80h is normal brightness).
+The 8bit CODE value is intended to contain a GP0(20h..7Fh) Rendering command,
+allowing to automatically merge the 8bit command number, with the 24bit color
+value.
+The IRGB/ORGB registers allow to convert between 48bit and 15bit RGB colors.
+Although the result of the commands in this chapter is written to the Color
+FIFO, some commands like GPF/GPL may be also used for other purposes (eg. to
+scale or scale/translate single vertices).
Basically, the GTE division does (attempt to) work as so (using 33bit maths):
+
n = (((H*20000h/SZ3)+1)/2)
+ n = ((H*10000h+SZ3/2)/SZ3)
+ if n>1FFFFh or division_by_zero then n=1FFFFh, FLAG.Bit17=1, FLAG.Bit31=1
+ if (H < SZ3*2) then ;check if overflow
+ z = count_leading_zeroes(SZ3) ;z=0..0Fh (for 16bit SZ3)
+ n = (H SHL z) ;n=0..7FFF8000h
+ d = (SZ3 SHL z) ;d=8000h..FFFFh
+ u = unr_table[(d-7FC0h) SHR 7] + 101h ;u=200h..101h
+ d = ((2000080h - (d * u)) SHR 8) ;d=10000h..0FF01h
+ d = ((0000080h + (d * u)) SHR 8) ;d=20000h..10000h
+ n = min(1FFFFh, (((n*d) + 8000h) SHR 16)) ;n=0..1FFFFh
+ else n = 1FFFFh, FLAG.Bit17=1, FLAG.Bit31=1 ;n=1FFFFh plus overflow flag
+ FFh,FDh,FBh,F9h,F7h,F5h,F3h,F1h,EFh,EEh,ECh,EAh,E8h,E6h,E4h,E3h ;\
+ E1h,DFh,DDh,DCh,DAh,D8h,D6h,D5h,D3h,D1h,D0h,CEh,CDh,CBh,C9h,C8h ; 00h..3Fh
+ C6h,C5h,C3h,C1h,C0h,BEh,BDh,BBh,BAh,B8h,B7h,B5h,B4h,B2h,B1h,B0h ;
+ AEh,ADh,ABh,AAh,A9h,A7h,A6h,A4h,A3h,A2h,A0h,9Fh,9Eh,9Ch,9Bh,9Ah ;/
+ 99h,97h,96h,95h,94h,92h,91h,90h,8Fh,8Dh,8Ch,8Bh,8Ah,89h,87h,86h ;\
+ 85h,84h,83h,82h,81h,7Fh,7Eh,7Dh,7Ch,7Bh,7Ah,79h,78h,77h,75h,74h ; 40h..7Fh
+ 73h,72h,71h,70h,6Fh,6Eh,6Dh,6Ch,6Bh,6Ah,69h,68h,67h,66h,65h,64h ;
+ 63h,62h,61h,60h,5Fh,5Eh,5Dh,5Dh,5Ch,5Bh,5Ah,59h,58h,57h,56h,55h ;/
+ 54h,53h,53h,52h,51h,50h,4Fh,4Eh,4Dh,4Dh,4Ch,4Bh,4Ah,49h,48h,48h ;\
+ 47h,46h,45h,44h,43h,43h,42h,41h,40h,3Fh,3Fh,3Eh,3Dh,3Ch,3Ch,3Bh ; 80h..BFh
+ 3Ah,39h,39h,38h,37h,36h,36h,35h,34h,33h,33h,32h,31h,31h,30h,2Fh ;
+ 2Eh,2Eh,2Dh,2Ch,2Ch,2Bh,2Ah,2Ah,29h,28h,28h,27h,26h,26h,25h,24h ;/
+ 24h,23h,22h,22h,21h,20h,20h,1Fh,1Eh,1Eh,1Dh,1Dh,1Ch,1Bh,1Bh,1Ah ;\
+ 19h,19h,18h,18h,17h,16h,16h,15h,15h,14h,14h,13h,12h,12h,11h,11h ; C0h..FFh
+ 10h,0Fh,0Fh,0Eh,0Eh,0Dh,0Dh,0Ch,0Ch,0Bh,0Ah,0Ah,09h,09h,08h,08h ;
+ 07h,07h,06h,06h,05h,05h,04h,04h,03h,03h,02h,02h,01h,01h,00h,00h ;/
+ 00h ;<-- one extra table entry (for "(d-7FC0h)/80h"=100h) ;-100h
+The GPU can render Polygons, Lines, or Rectangles to the Drawing Buffer, and
+sends the Display Buffer to the Television Set. Polygons are useful for 3D
+graphics (or rotated/scaled 2D graphics), Rectangles are useful for 2D graphics
+and Text output.
GPU I/O Ports, DMA Channels, Commands, VRAM
+GPU Render Polygon Commands
+GPU Render Line Commands
+GPU Render Rectangle Commands
+GPU Rendering Attributes
+GPU Memory Transfer Commands
+GPU Other Commands
+GPU Display Control Commands (GP1)
+GPU Status Register
+GPU Versions
+GPU Depth Ordering
+GPU Video Memory (VRAM)
+GPU Texture Caching
+GPU Timings
+GPU (MISC)
Port Name Expl.
+ 1F801810h-Write GP0 Send GP0 Commands/Packets (Rendering and VRAM Access)
+ 1F801814h-Write GP1 Send GP1 Commands (Display Control) (and DMA Control)
+ 1F801810h-Read GPUREAD Receive responses to GP0(C0h) and GP1(10h) commands
+ 1F801814h-Read GPUSTAT Receive GPU Status Register
+Most of the Timers are bound to GPU timings, see
+Timers
+Interrupts
Channel Recommended for
+ DMA2 in Linked Mode - Sending rendering commands ;GP0(20h..7Fh,E1h..E6h)
+ DMA2 in Continuous Mode - VRAM transfers to/from GPU ;GP0(A0h,C0h)
+ DMA6 - Initializing the Link List ;Main RAM
+While it is probably more simple for the MIPS software to see GPU commands
+as a collection of bytes, the GPU will only see 32 bits words being sent to it.
+Therefore, while the Sony libraries will fill up structures to send to the GPU
+using byte-level granularity, it is much more simple to see these as bitmasks
+from the GPU's point of view.
+So when processing commands on GP0, the GPU will first inspect the top 3 bits
+of the 32 bits command being sent. Depending on the value of these 3 bits,
+further decoding of the other bits can be done.
+Commands sent to GP1 are more simple in nature to decode.
+
+Top 3 bits of a GP0 command:
+
0 (000) Misc commands
+ 1 (001) Polygon primitive
+ 2 (010) Line primitive
+ 3 (011) Rectangle primitive
+ 4 (100) VRAM-to-VRAM blit
+ 5 (101) CPU-to-VRAM blit
+ 6 (110) VRAM-to-CPU blit
+ 7 (111) Environment commands
+The astute reader will realize that there are shared bits between primitives, such +as the gouraud shading flag.
+Unlike all the others, the environment commands are more clear to be seen as a single +8 bits command, therefore the rest of the document will refer to them by their +full 8 bits value.
+ 1st Command (01000000h)
+ 1st Color+Command (02BbGgRrh) ;24bit RGB value (see note)
+ 2nd Top Left Corner (YyyyXxxxh) ;Xpos counted in halfwords, steps of 10h
+ 3rd Width+Height (YsizXsizh) ;Xsiz counted in halfwords, steps of 10h
+VRAM can be 1 MB or 2 MB (not mapped to the CPU bus) (it can be read/written
+only via I/O or DMA). The memory is used for:
+
Framebuffer(s) ;Usually 2 buffers (Drawing Area, and Display Area)
+ Texture Page(s) ;Required when using Textures
+ Texture Palette(s) ;Required when using 4bit/8bit Textures
+ Unit = 4bit 8bit 16bit 24bit Halfwords | Unit = Lines
+ Width = 4096 2048 1024 682.66 1024 | Height = 512/1024
+When the upper 3 bits of the first GP0 command are set to 1 (001), then the command can +be decoded using the following bitfield: +
bit number value meaning
+ 31-29 001 polygon render
+ 28 1/0 gouraud / flat shading
+ 27 1/0 4 / 3 vertices
+ 26 1/0 textured / untextured
+ 25 1/0 semi-transparent / opaque
+ 24 1/0 raw texture / modulation
+ 23-0 rgb first color value.
+Subsequent data sent to GP0 to complete this command will be the vertex data for the +command. The meaning and count of these words will be altered by the initial flags +sent in the first command.
+If doing flat rendering, no further color will be sent. If doing gouraud shading, +there will be one more color per vertex sent, and the initial color will be the +one for vertex 0.
+If doing textured rendering, each vertex sent will also have a U/V texture coordinate +attached to it, as well as a CLUT index.
+So each vertex data can be seen as the following set of words: +
Color xxBBGGRR - optional, only present for gouraud shading
+Vertex YYYYXXXX - required, two signed 16 bits values
+UV ClutVVUU or PageVVUU - optional, only present for textured polygons
+The upper 16 bits of the first two UV words contain extra information. The first +word holds the Clut index. The second word contains texture page information. +Any further clut/page bits should be set to 0.
+So for example, a solid flat blue triangle of coordinate (10, 20), (30, 40), (50, 60) +will be drawn using the following draw call data: +
200000FF
+00100020
+00300040
+00500060
+And a quad with gouraud shading texture-blend will have the following structure: +
2CR1G1B1
+Yyy1Xxx1
+ClutV1U1
+00R2G2B2
+Yyy2Xxx2
+PageV2U2
+00R3G3B3
+Yyy3Xxx3
+0000V3U3
+00R4G4B4
+Yyy4Xxx4
+0000V4U4
+Some combination of these flags can be seen as nonsense however, but it's important +to realize that the GPU will still process them properly. For instance, specifying +gouraud shading without modulation will force the user to send the colors for +each vertex to satisfy the GPU's state machine, without them being actually used for +the rendering.
+Polygons are displayed up to \<excluding> their lower-right coordinates.
+Quads are internally processed as two triangles, the
+first consisting of vertices 1,2,3, and the second of vertices 2,3,4. This is an
+important detail, as splitting the quad into triangles affects the way colours
+are interpolated.
+Within the triangle, the ordering of the vertices doesn't matter on
+the GPU side (a front-back check, based on clockwise or anti-clockwise
+ordering, can be implemented at the GTE side).
+Dither enable (in Texpage command) affects ONLY polygons that do use gouraud
+shading or modulation.
When the upper 3 bits of the first GP0 command are set to 2 (010), then the command can +be decoded using the following bitfield: +
bit number value meaning
+ 31-29 010 line render
+ 28 1/0 gouraud / flat shading
+ 27 1/0 polyline / single line
+ 25 1/0 semi-transparent / opaque
+ 23-0 rgb first color value.
+So each vertex can be seen as the following list of words: +
Color xxBBGGRR - optional, only present for gouraud shading
+Vertex YYYYXXXX - required, two signed 16 bits values
+When polyline mode is active, at least two vertices must be sent to the GPU.
+The vertex list is terminated by the bits 12-15 and 28-31 equaling 0x5, or
+(word & 0xF000F000) == 0x50005000. The terminator value occurs on the first
+word of the vertex (i.e. the color word if it's a gouraud shaded).
If the 2 vertices in a line overlap, then the GPU will draw a 1x1 rectangle in
+the location of the 2 vertices using the colour of the first vertex.
Lines are displayed up to \<including> their lower-right coordinates (ie.
+unlike as for polygons, the lower-right coordinate is not excluded).
+If dithering is enabled (via Texpage command), then both monochrome and shaded
+lines are drawn with dithering (this differs from monochrome polygons and
+monochrome rectangles).
Poly-Lines can be used (among others) to create Wire-Frame polygons (by setting
+the last Vertex equal to Vertex 1).
Rectangles are drawn much faster than polygons. Unlike polygons, gouraud
+shading is not possible, dithering isn't applied, the rectangle must forcefully
+have horizontal and vertical edges, textures cannot be rotated or scaled, and,
+of course, the GPU does render Rectangles as a single entity, without splitting
+them into two triangles.
The Rectangle command can be decoded using the following bitfield: +
bit number value meaning
+ 31-29 011 rectangle render
+ 28-27 sss rectangle size
+ 26 1/0 textured / untextured
+ 25 1/0 semi-transparent / opaque
+ 24 1/0 raw texture / modulation
+ 23-0 rgb first color value.
+The size parameter can be seen as the following enum:
0 (00) variable size
+ 1 (01) single pixel (1x1)
+ 2 (10) 8x8 sprite
+ 3 (11) 16x16 sprite
+Therefore, the whole draw call can be seen as the following sequence of words: +
Color ccBBGGRR - command + color; color is ignored when textured
+Vertex1 YYYYXXXX - required, indicates the upper left corner to render
+UV ClutVVUU - optional, only present for textured rectangles
+Width+Height YsizXsiz - optional, dimensions for variable sized rectangles (max 1023x511)
+Unlike for Textured-Polygons, the "Texpage" must be set up separately for
+Rectangles, via GP0(E1h). Width and Height can be up to 1023x511, however, the
+maximum size of the texture window is 256x256 (so the source data will be
+repeated when trying to use sizes larger than 256x256).
Vertex & Texcoord specify the upper-left edge of the rectangle. And,
+normally, screen coords and texture coords are both incremented during
+rendering the rectangle pixels.
+Optionally, X/Y-Flip bits can be set in Texpage.Bit12/13, these bits cause the
+texture coordinates to be decremented (instead of incremented). The X/Y-Flip
+bits do affect only Rectangles (not Polygons, nor VRAM Transfers).
+Caution: Reportedly, the X/Y-Flip feature isn't supported on old PSX consoles
+(unknown which ones exactly, maybe such with PU-7 mainboards, and unknown how
+to detect flipping support; except of course by reading VRAM).
There are also two VRAM Transfer commands which work similar to GP0(60h) and
+GP0(65h). Eventually, that commands might be even faster... although not sure
+if they do use the Texture Cache?
+The difference is that VRAM Transfers do not clip to the Drawig Area boundary,
+do not support fully-transparent nor semi-transparent texture pixels, and do
+not convert color depths (eg. without 4bit texture to 16bit framebuffer
+conversion).
0-10 X-coordinate (signed, -1024..+1023)
+ 11-15 Not used (usually sign-extension, but ignored by hardware)
+ 16-26 Y-coordinate (signed, -1024..+1023)
+ 26-31 Not used (usually sign-extension, but ignored by hardware)
+ 0-7 Red (0..FFh)
+ 8-15 Green (0..FFh)
+ 16-23 Blue (0..FFh)
+ 24-31 Command (in first paramter) (don't care in further parameters)
+ 0-8 Same as GP0(E1h).Bit0-8 (see there)
+ 9-10 Unused (does NOT change GP0(E1h).Bit9-10)
+ 11 Same as GP0(E1h).Bit11 (see there)
+ 12-13 Unused (does NOT change GP0(E1h).Bit12-13)
+ 14-15 Unused (should be 0)
+This attribute is used in all Textured Polygon/Rectangle commands. Of course,
+it's relevant only for 4bit/8bit textures (don't care for 15bit textures).
+
0-5 X coordinate X/16 (ie. in 16-halfword steps)
+ 6-14 Y coordinate 0-511 (ie. in 1-line steps) ;\on v0 GPU (max 1 MB VRAM)
+ 15 Unused (should be 0) ;/
+ 6-15 Y coordinate 0-1023 (ie. in 1-line steps) ;on v2 GPU (max 2 MB VRAM)
+ 0-3 Texture page X Base (N*64) (ie. in 64-halfword steps) ;GPUSTAT.0-3
+ 4 Texture page Y Base 1 (N*256) (ie. 0, 256, 512 or 768) ;GPUSTAT.4
+ 5-6 Semi-transparency (0=B/2+F/2, 1=B+F, 2=B-F, 3=B+F/4) ;GPUSTAT.5-6
+ 7-8 Texture page colors (0=4bit, 1=8bit, 2=15bit, 3=Reserved);GPUSTAT.7-8
+ 9 Dither 24bit to 15bit (0=Off/strip LSBs, 1=Dither Enabled) ;GPUSTAT.9
+ 10 Drawing to display area (0=Prohibited, 1=Allowed) ;GPUSTAT.10
+ 11 Texture page Y Base 2 (N*512) (only for 2 MB VRAM) ;GPUSTAT.15
+ 12 Textured Rectangle X-Flip (BIOS does set this bit on power-up...?)
+ 13 Textured Rectangle Y-Flip (BIOS does set it equal to GPUSTAT.13...?)
+ 14-23 Not used (should be 0)
+ 24-31 Command (E1h)
+ 0-4 Texture window Mask X (in 8 pixel steps)
+ 5-9 Texture window Mask Y (in 8 pixel steps)
+ 10-14 Texture window Offset X (in 8 pixel steps)
+ 15-19 Texture window Offset Y (in 8 pixel steps)
+ 20-23 Not used (zero)
+ 24-31 Command (E2h)
+ Texcoord = (Texcoord AND (NOT (Mask*8))) OR ((Offset AND Mask)*8)
+ 0-9 X-coordinate (0..1023)
+ 10-18 Y-coordinate (0..511) ;\on v0 GPU (max 1 MB VRAM)
+ 19-23 Not used (zero) ;/
+ 10-19 Y-coordinate (0..1023) ;\on v2 GPU (max 2 MB VRAM)
+ 20-23 Not used (zero) ;/
+ 24-31 Command (Exh)
+ 0-10 X-offset (-1024..+1023) (usually within X1,X2 of Drawing Area)
+ 11-21 Y-offset (-1024..+1023) (usually within Y1,Y2 of Drawing Area)
+ 22-23 Not used (zero)
+ 24-31 Command (E5h)
+ 0 Set mask while drawing (0=TextureBit15, 1=ForceBit15=1) ;GPUSTAT.11
+ 1 Check mask before draw (0=Draw Always, 1=Draw if Bit15=0) ;GPUSTAT.12
+ 2-23 Not used (zero)
+ 24-31 Command (E6h)
+GP0(E3h..E5h) do not take up space in the FIFO, so they are probably executed
+immediately (even if there're still other commands in the FIFO). Best use them
+only if you are sure that the FIFO is empty (otherwise the new Drawing Area
+settings might accidentally affect older Rendering Commands in the FIFO).
The next three commands being described are when the high 3 bits are set to the +values 4 (100), 5 (101), and 6 (110). For them, the remaining 29 bits are ignored, +and can be set to any arbitrary value.
+ 1st Command
+ 2nd Source Coord (YyyyXxxxh) ;Xpos counted in halfwords
+ 3rd Destination Coord (YyyyXxxxh) ;Xpos counted in halfwords
+ 4th Width+Height (YsizXsizh) ;Xsiz counted in halfwords
+ 1st Command
+ 2nd Destination Coord (YyyyXxxxh) ;Xpos counted in halfwords
+ 3rd Width+Height (YsizXsizh) ;Xsiz counted in halfwords
+ ... Data (...) <--- usually transferred via DMA
+ 1st Command ;\
+ 2nd Source Coord (YyyyXxxxh) ; write to GP0 port (as usually)
+ 3rd Width+Height (YsizXsizh) ;/
+ ... Data (...) ;<--- read from GPUREAD port (or via DMA)
+ Xpos=(Xpos AND 3F0h) ;range 0..3F0h, in steps of 10h
+ Ypos=(Ypos AND 1FFh) ;range 0..1FFh
+ Xsiz=((Xsiz AND 3FFh)+0Fh) AND (NOT 0Fh) ;range 0..400h, in steps of 10h
+ Ysiz=((Ysiz AND 1FFh)) ;range 0..1FFh
+Note that because of the height (Ysiz) masking, a maximum of 511 rows can be +filled in a single command. Calling a fill with a full VRAM height of 512 rows +will be ineffective as the height will be masked to 0.
+ Xpos=(Xpos AND 3FFh) ;range 0..3FFh
+ Ypos=(Ypos AND 1FFh) ;range 0..1FFh
+ Xsiz=((Xsiz-1) AND 3FFh)+1 ;range 1..400h
+ Ysiz=((Ysiz-1) AND 1FFh)+1 ;range 1..200h
+The coordinates for the above VRAM transfer commands are absolute framebuffer
+addresses (not relative to Draw Offset, and not clipped to Draw Area).
+Non-DMA transfers seem to be working at any time, but GPU-DMA Transfers seem to
+be working ONLY during V-Blank (outside of V-Blank, portions of the data appear
+to be skipped, and the following words arrive at wrong addresses), unknown if
+it's possible to change that by whatever configuration settings...? That
+problem appears ONLY for continous DMA aka VRAM transfers (linked-list DMA aka
+Ordering Table works even outside V-Blank).
If the Source/Dest starting points plus the width/height value exceed the
+1024x512 pixel VRAM size, then the Copy/Fill operations wrap to the opposite
+memory edge (without any carry-out from X to Y, nor from Y to X).
1st Command (Cc000000h) ;GPUSTAT.24
+Unknown. Doesn't seem to be used by any games. Unlike the "NOP" commands,
+GP0(03h) does take up space in FIFO, so it is apparently not a NOP.
This command doesn't take up space in the FIFO (eg. even if a VRAM-to-VRAM
+transfer is still busy, one can send dozens of GP0(00h) commands, without the
+command FIFO becoming full. So, either the command is ignored (or, if it has a
+function, it is executed immediately, even while the transfer is busy).
+...
+GP0(00h) unknown, used with parameter = 08A16Ch... or rather 08FDBCh ... the
+written value seems to be a bios/ram memory address, anded with 00FFFFFFh...
+maybe a bios bug?
+GP0(00h) seems to be often inserted between Texpage and Rectangle commands,
+maybe it acts as a NOP, which may be required between that commands, for timing
+reasons...?
Like GP0(00h), these commands don't take up space in the FIFO. So, maybe, they
+are same as GP0(00h), however, the Drawing Area/Offset commands GP0(E3h..E5h)
+don't take up FIFO space either, so not taking up FIFO space doesn't
+neccessarily mean that the command has no function.
GP1 Display Control Commands are sent by writing the 8bit Command number
+(MSBs), and 24bit parameter (LSBs) to Port 1F801814h. Unlike GP0 commands, GP1
+commands are passed directly to the GPU (ie. they can be sent even when the
+FIFO is full).
0-23 Not used (zero)
+ GP1(01h) ;clear fifo
+ GP1(02h) ;ack irq (0)
+ GP1(03h) ;display off (1)
+ GP1(04h) ;dma off (0)
+ GP1(05h) ;display address (0)
+ GP1(06h) ;display x1,x2 (x1=200h, x2=200h+256*10)
+ GP1(07h) ;display y1,y2 (y1=010h, y2=010h+240)
+ GP1(08h) ;display mode 320x200 NTSC (0)
+ GP0(E1h..E6h) ;rendering attributes (0)
+ 0-23 Not used (zero)
+ 0-23 Not used (zero) ;GPUSTAT.24
+ 0 Display On/Off (0=On, 1=Off) ;GPUSTAT.23
+ 1-23 Not used (zero)
+ 0-1 DMA Direction (0=Off, 1=FIFO, 2=CPUtoGP0, 3=GPUREADtoCPU) ;GPUSTAT.29-30
+ 2-23 Not used (zero)
+Specifies where the display area is positioned on the screen, and how much data
+gets sent to the screen. The screen sizes of the display area are valid only if
+the horizontal/vertical start/end values are default. By changing these you can
+get bigger/smaller display screens. On most TV's there is some black around the
+edge, which can be utilised by setting the start of the screen earlier and the
+end later. The size of the pixels is NOT changed with these settings, the GPU
+simply sends more data to the screen. Some monitors/TVs have a smaller display
+area and the extended size might not be visible on those sets. "(Mine is
+capable of about 330 pixels horizontal, and 272 vertical in 320*240 mode)"
0-9 X (0-1023) (halfword address in VRAM) (relative to begin of VRAM)
+ 10-18 Y (0-511) (scanline number in VRAM) (relative to begin of VRAM)
+ 19-23 Not used (zero)
+ 0-11 X1 (260h+0) ;12bit ;\counted in video clock units,
+ 12-23 X2 (260h+320*8) ;12bit ;/relative to HSYNC
+ 0-9 Y1 (NTSC=88h-(240/2), (PAL=A3h-(288/2)) ;\scanline numbers on screen,
+ 10-19 Y2 (NTSC=88h+(240/2), (PAL=A3h+(288/2)) ;/relative to VSYNC
+ 20-23 Not used (zero)
+ 0-1 Horizontal Resolution 1 (0=256, 1=320, 2=512, 3=640) ;GPUSTAT.17-18
+ 2 Vertical Resolution (0=240, 1=480, when Bit5=1) ;GPUSTAT.19
+ 3 Video Mode (0=NTSC/60Hz, 1=PAL/50Hz) ;GPUSTAT.20
+ 4 Display Area Color Depth (0=15bit, 1=24bit) ;GPUSTAT.21
+ 5 Vertical Interlace (0=Off, 1=On) ;GPUSTAT.22
+ 6 Horizontal Resolution 2 (0=256/320/512/640, 1=368) ;GPUSTAT.16
+ 7 Flip screen horizontally (0=Off, 1=On, v1 only) ;GPUSTAT.14
+ 8-23 Not used (zero)
+After sending the command, the result can be read (immediately) from GPUREAD
+register (there's no NOP or other delay required) (namely GPUSTAT.Bit27 is used
+only for VRAM reads, but NOT for register reads, so do not try to wait for that
+flag).
+
0-23 Register index (via following GPUREAD)
+ 00h-01h = Returns Nothing (old value in GPUREAD remains unchanged)
+ 02h = Read Texture Window setting ;GP0(E2h) ;20bit/MSBs=Nothing
+ 03h = Read Draw area top left ;GP0(E3h) ;19bit/MSBs=Nothing
+ 04h = Read Draw area bottom right ;GP0(E4h) ;19bit/MSBs=Nothing
+ 05h = Read Draw offset ;GP0(E5h) ;22bit
+ 06h-07h = Returns Nothing (old value in GPUREAD remains unchanged)
+ 08h-FFFFFFh = Mirrors of 00h..07h
+ 00h-01h = Returns Nothing (old value in GPUREAD remains unchanged)
+ 02h = Read Texture Window setting ;GP0(E2h) ;20bit/MSBs=Nothing
+ 03h = Read Draw area top left ;GP0(E3h) ;20bit/MSBs=Nothing
+ 04h = Read Draw area bottom right ;GP0(E4h) ;20bit/MSBs=Nothing
+ 05h = Read Draw offset ;GP0(E5h) ;22bit
+ 06h = Returns Nothing (old value in GPUREAD remains unchanged)
+ 07h = Read GPU version (1 or 2)
+ 08h = Unknown (Returns 00000000h) (lightgun? VRAM size set via GP1(09h)?)
+ 09h-0Fh = Returns Nothing (old value in GPUREAD remains unchanged)
+ 10h-FFFFFFh = Mirrors of 00h..0Fh
+ 0 Allow Y coordinates in 512-1023 range (0=No/wrap to 0-511, 1=Yes)
+ 1-23 Unknown (seems to have no effect)
+ 0-23 Unknown (501h=1 MB, 504h=2 MB, or so?)
+ 0-10 Unknown (GPU crashes after a while when set to 274h..7FFh)
+ 11-23 Unknown (seems to have no effect)
+Not used?
Mirrors of GP1(00h..3Fh).
NTSC games are typically well centered (using X1=260h, and Y1/Y2=88h+/-N).
+PAL games should be centered as X1=260h, and Y1/Y2=A3h+/-N) - these values
+would be looking well on a Philips Philetta TV Set, and do also match up with
+other common picture positions (eg. as used by Nintendo's SNES console).
+However, most PAL games are using completely different "random" centering
+values (maybe caused by different developers trying to match the centering to
+the different TV Sets) (although it looks more as if the PAL developers just
+went amok: Many PAL games are even using different centerings for their Intro,
+Movie, and actual Game sequences).
+In result, most PAL games are looking like crap when playing them on a real
+PSX. For PSX emulators it may be recommended to ignore the GP1(06h)/GP1(07h)
+centering, and instead, apply auto-centering to PAL games.
+For PAL game developers, it may be recommended to add a screen centering option
+(as found in Tomb Raider 3, for example). Unknown if this is really required...
+or if X1=260h, and Y1/Y2=A3h+/-N would work fine on most or all PAL TV Sets?
0-3 Texture page X Base (N*64) ;GP0(E1h).0-3
+ 4 Texture page Y Base 1 (N*256) (ie. 0, 256, 512 or 768) ;GP0(E1h).4
+ 5-6 Semi-transparency (0=B/2+F/2, 1=B+F, 2=B-F, 3=B+F/4) ;GP0(E1h).5-6
+ 7-8 Texture page colors (0=4bit, 1=8bit, 2=15bit, 3=Reserved)GP0(E1h).7-8
+ 9 Dither 24bit to 15bit (0=Off/strip LSBs, 1=Dither Enabled);GP0(E1h).9
+ 10 Drawing to display area (0=Prohibited, 1=Allowed) ;GP0(E1h).10
+ 11 Set Mask-bit when drawing pixels (0=No, 1=Yes/Mask) ;GP0(E6h).0
+ 12 Draw Pixels (0=Always, 1=Not to Masked areas) ;GP0(E6h).1
+ 13 Interlace Field (or, always 1 when GP1(08h).5=0)
+ 14 Flip screen horizontally (0=Off, 1=On, v1 only) ;GP1(08h).7
+ 15 Texture page Y Base 2 (N*512) (only for 2 MB VRAM) ;GP0(E1h).11
+ 16 Horizontal Resolution 2 (0=256/320/512/640, 1=368) ;GP1(08h).6
+ 17-18 Horizontal Resolution 1 (0=256, 1=320, 2=512, 3=640) ;GP1(08h).0-1
+ 19 Vertical Resolution (0=240, 1=480, when Bit22=1) ;GP1(08h).2
+ 20 Video Mode (0=NTSC/60Hz, 1=PAL/50Hz) ;GP1(08h).3
+ 21 Display Area Color Depth (0=15bit, 1=24bit) ;GP1(08h).4
+ 22 Vertical Interlace (0=Off, 1=On) ;GP1(08h).5
+ 23 Display Enable (0=Enabled, 1=Disabled) ;GP1(03h).0
+ 24 Interrupt Request (IRQ1) (0=Off, 1=IRQ) ;GP0(1Fh)/GP1(02h)
+ 25 DMA / Data Request, meaning depends on GP1(04h) DMA Direction:
+ When GP1(04h)=0 ---> Always zero (0)
+ When GP1(04h)=1 ---> FIFO State (0=Full, 1=Not Full)
+ When GP1(04h)=2 ---> Same as GPUSTAT.28
+ When GP1(04h)=3 ---> Same as GPUSTAT.27
+ 26 Ready to receive Cmd Word (0=No, 1=Ready) ;GP0(...) ;via GP0
+ 27 Ready to send VRAM to CPU (0=No, 1=Ready) ;GP0(C0h) ;via GPUREAD
+ 28 Ready to receive DMA Block (0=No, 1=Ready) ;GP0(...) ;via GP0
+ 29-30 DMA Direction (0=Off, 1=?, 2=CPUtoGP0, 3=GPUREADtoCPU) ;GP1(04h).0-1
+ 31 Drawing even/odd lines in interlace mode (0=Even or Vblank, 1=Odd)
+Further GPU status information can be retrieved via GP1(10h) and GP0(C0h).
Bit28: Normally, this bit gets cleared when the command execution is busy (ie.
+once when the command and all of its parameters are received), however, for
+Polygon and Line Rendering commands, the bit gets cleared immediately after
+receiving the command word (ie. before receiving the vertex parameters). The
+bit is used as DMA request in DMA Mode 2, accordingly, the DMA would probably
+hang if the Polygon/Line parameters are transferred in a separate DMA block
+(ie. the DMA probably starts ONLY on command words).
+Bit27: Gets set after sending GP0(C0h) and its parameters, and stays set until
+all data words are received; used as DMA request in DMA Mode 3.
+Bit26: Gets set when the GPU wants to receive a command. If the bit is cleared,
+then the GPU does either want to receive data, or it is busy with a command
+execution (and doesn't want to receive anything).
+Bit25: This is the DMA Request bit, however, the bit is also useful for non-DMA
+transfers, especially in the FIFO State mode.
Differences... v0 (160-pin) v1 (208-pin prototype) v2 (208-pin)
+ GPU Chip CXD8514Q CXD8538Q CXD8561Q/BQ/CQ/CXD9500Q
+ Mainboard EARLY-PU-8 and below Arcade boards only LATE-PU-8 and up
+ Memory Type Dual-ported VRAM Dual-ported VRAM? Normal DRAM
+ GPUSTAT.13 when interlace=off always 0 unknown always 1
+ GPUSTAT.14 always 0 screen flip nonfunctional screen flip
+ GPUSTAT.15 always 0 always 0? bit1 of texpage Y base
+ GP1(10h:index3..4) 19-bit (1 MB VRAM) 22-bit (2 MB VRAM) 20-bit (2 MB VRAM)
+ GP1(10h:index7) N/A 00000001h version 00000002h version
+ GP1(10h:index8) mirror of index0 00000000h zero 00000000h zero
+ GP1(10h:index9..F) mirror of index1..7 unknown N/A
+ GP1(09h) N/A N/A VRAM size
+ GP1(20h) N/A VRAM size/settings N/A
+ GP0(E1h).bit11 N/A N/A bit1 of texpage Y base
+ GP0(E1h).bit12/13 without x/y-flip without x/y-flip with x/y-flip
+ GP0(03h) N/A (no stored in fifo) unknown unknown/unused command
+ Shaded Textures ((color/8)*texel)/2 unknown (color*texel)/16
+ GP0(02h) FillVram xpos.bit0-3=0Fh=bugged unknown xpos.bit0-3=ignored
+
+ dma-to-vram: doesn't work with blksiz>10h (v2 gpu works with blksiz=8C0h!)
+ dma-to-vram: MAYBE also needs extra software-handshake to confirm DMA done?
+ 320*224 pix = 11800h pix = 8C00h words
+The v0 GPU crops 8:8:8 bit gouraud shading color to 5:5:5 bit before multiplying
+it with the texture color, resulting in rather poor graphics. For example, the
+snow scence in the first level of Tomb Raider I looks a lot smoother on v2 GPUs.
+This bug was presumably already fixed on the v1 prototype GPU (unconfirmed).
+The cropped colors are looking a bit as if dithering would be disabled
+(although, technically dithering works fine, but due to the crippled color
+input, it's always using the same dither pattern per 8 intensities, instead of
+using 8 different dither patterns).
The v0 GPU uses two Dual-ported VRAM chips (each with two 16bit databusses,
+one for CPU/DMA/rendering access, and one for output to the video DAC). The New
+GPU uses s normal DRAM chip (with single 32bit databus).
+The exact timing differences are unknown, but the different memory types should
+result in quite different timings:
+The v0 GPU might perform better on non-32bit aligned accesses, and on memory
+accesses performed simultaneously with DAC output.
+On the other hand, the v2 GPU's DRAM seems to be faster in some cases (for
+example, during Vblank, it's fast enough to perform DMA's with blksiz>10h,
+which exceeds the GPU's FIFO size, and causes lost data on v0 GPUs).
The X/Y-flipping feature may be used by arcade games (provided that the arcade
+board is fitted with v2 GPUs). The flipping feature does also work on retail
+consoles with v2 GPUs, but PSX games should never use that feature (for
+maintaining compatiblity with older PSX consoles).
+Some PSone consoles seem to be fitted with 2 MB VRAM chips (maybe because
+smaller chips had not been in production anymore), but only the first 1 MB
+region is accessible. However, as all PSone models use a v2 GPU which supports
+2 MB VRAM, it should be possible to rewire the chip selects to make the upper
+half accessible.
Below is slightly customized GPU Detection function taken from Perfect Assassin
+(the index7 latching works ONLY on v1/v2 GPUs, whilst v0 GPUs would leave the
+latched value unchanged; as a workaround, the index4 latching is used to ensure
+that the latch won't contain 000002h on v0 GPUs, assuming that index4 is never
+set to 000002h).
+
[1F801814h]=10000004h ;GP1(10h).index4 (latch draw area bottom right)
+ [1F801814h]=10000007h ;GP1(10h).index7 (latch GPU version, if any)
+ if ([1F801810h] AND 00FFFFFFh)=00000002h then goto @@gpu_v2
+ [1F801810h]=([1F801814h] AND 3FFFh) OR E1001000h ;change GPUSTAT via GP0(E1h)
+ dummy=[1F801810h] ;dummy read (unknown purpose)
+ if ([1F801814h] AND 00001000h) then goto @@gpu_v1 else goto @@gpu_v0
+ ;---
+ @@gpu_v0:
+ return 0
+ ;---
+ @@gpu_v1:
+ if want_2mb_vram then [1F801814h]=20000504h ;GP1(20h)
+ return 1
+ ;---
+ @@gpu_v2:
+ if want_2mb_vram then [1F801814h]=09000001h ;GP1(09h)
+ return 2
+The FillVram command does normally ignore the lower 4bit of the x-coordinate
+(and software should always set those bits to zero). However, if the 4bits are
+all set, then the old v0 GPU does write each 2nd pixel to wrong memory address.
+For example, a 32x4 pixel fill produces following results for x=0..1Fh:
+
0h 10h 20h 30h 40h
+ | | | | |
+ ################################ ;\x=00h..0Eh
+ ################################ ; and, x=0Fh
+ ################################ ; on v2 GPU
+ ################################ ;/
+ # # # # # # # ################## # # # # # # # ;\
+ # # # # # # # ################## # # # # # # # ; x=0Fh
+ # # # # # # # ################## # # # # # # # ; on v0 GPU
+ # # # # # # # ################## # # # # # # # ;/
+ ################################ ;\x=10h..1Eh
+ ################################ ; and, x=1Fh
+ ################################ ; on v2 GPU
+ ################################ ;/
+ # # # # # # # ################## # # # # # # # ;\
+ # # # # # # # ################## # # # # # # # ; x=1Fh
+ # # # # # # # ################## # # # # # # # ; on v0 GPU
+ # # # # # # # ################## # # # # # # # ;/
+The PlayStation's GPU stores only RGB colors in the framebuffer (ie. unlike
+modern 3D processors, it's NOT buffering Depth values; leaving apart the Mask
+bit, which could be considered as a tiny 1bit "Depth" or "Priority" value). In
+fact, the GPU supports only X,Y coordinates, and it's totally unaware of Z
+coordinates. So, when rendering a polygon, the hardware CANNOT determine which
+of the new pixels are in front/behind of the old pixels in the buffer.
The rendering simply takes place in the ordering as the data is sent to the GPU
+(ie. the most distant objects should be sent first). For 2D graphics, it's
+fairly easy follow that order (eg. even multi-layer 2D graphics can be using
+DMA2-continous mode).
For 3D graphics, the ordering of the polygons may change more or less randomly
+(eg. when rotating/moving the camera). To solve that problem, the whole
+rendering data is usually first stored in a Depth Ordering Table (OT) in Main
+RAM, and, once when all polygons have been stored in the OT, the OT is sent to
+the GPU via "DMA2-linked-list" mode.
DMA channel 6 can be used to set up an empty linked list, in which each entry
+points to the previous:
+
DPCR - enable bits ;Example=x8xxxxxxh
+ D6_MADR - pointer to the LAST table entry ;Example=8012300Ch
+ D6_BCR - number of list entries ;Example=00000004h
+ D6_CHCR - control bits (should be 11000002h) ;Example=11000002h
+ [80123000h]=00FFFFFFh ;1st entry, points to end code (xxFFFFFFh)
+ [80123004h]=00123000h ;2nd entry, points to 1st entry
+ [80123008h]=00123004h ;3rd entry, points to 2nd entry
+ [8012300Ch]=00123008h ;last entry, points to 3rd entry (table entrypoint)
+The GTE commands AVSZ3 and AVSZ4 can be used to calculate the Average Z
+coordinates of a polygon (based on its three or four Z coordinates). The result
+is returned as a 16bit Z value in GTE register OTZ, the commands do also allow
+to divide the result, to make it less than 16bit (the full 16bit would require
+an OT of 256KBytes - for the EMPTY table, which would be a waste of memory, and
+which would slowdown the DMA2/DMA6 operations) (on the other hand, a smaller
+table means less depth resolution).
+
[PacketAddr+0] = [80123000h+OTZ*4] + (N SHL 24) <--internal link chain
+ [PacketAddr+4..N*4] = GP0 Command(s) and Parameters <--data (send to GP0)
+ [80123000h+OTZ*4] = PacketAddr AND FFFFFFh <--internal link chain
+ 1 - Wait until GPU is ready to receive commands ;GPUSTAT.28
+ 2 - Enable DMA channel 2 ;DPCR
+ 3 - Set GPU to DMA cpu->gpu mode ;[GP1]=04000002h aka GP1(04h)
+ 3 - Set D2_MADR to the start of the list ;(LAST Entry) ;Example=80123010h
+ 4 - Set D2_BCR to zero ;(length unused, end at END-CODE)
+ 5 - Set D2_CHCR to link mode, mem->GPU and dma enable ;=01000401h
+The framebuffer contains the image that is to be output to the Television Set.
+The GPU supports 10 resolutions, with 16bit or 24bit per pixel.
+
Resolution 16bit 24bit | Resolution 16bit 24bit
+ 256x240 120Kbytes 180Kbytes | 256x480 240Kbytes 360Kbytes
+ 320x240 150Kbytes 225Kbytes | 320x480 300Kbytes 450Kbytes
+ 368x240 xx0Kbytes xx0Kbytes | 368x480 xx0Kbytes xx0Kbytes
+ 512x240 240Kbytes 360Kbytes | 512x480 480Kbytes 720Kbytes
+ 640x240 300Kbytes 450Kbytes | 640x480 600Kbytes 900Kbytes
+<B> 15bit Direct Display (default) (works with polygons, lines, rectangles)</B>
+ 0-4 Red (0..31)
+ 5-9 Green (0..31)
+ 10-14 Blue (0..31)
+ 15 Mask flag (0=Normal, 1=Do not allow to overwrite this pixel)
+<B> 24bit Direct Display (works ONLY with direct vram transfers)</B>
+ 0-7 Red (0..255)
+ 8-15 Green (0..255)
+ 16-23 Blue (0..255)
+A texture is an image put on a polygon or sprite. The data of a texture can be
+stored in 3 different modes:
+
<B> 16bit Texture (Direct Color) ;(One 256x256 page = 128Kbytes)</B>
+ 0-4 Red (0..31) ;\Color 0000h = Fully-transparent
+ 5-9 Green (0..31) ; Color 0001h..7FFFh = Non-transparent
+ 10-14 Blue (0..31) ; Color 8000h..FFFFh = Semi-transparent (*)
+ 15 Semi-transparency Flag ;/(*) or Non-transparent for opaque commands
+<B> 8bit Texture (256 Color Palette) ;(One 256x256 page = 64Kbytes)</B>
+ 0-7 Palette index for 1st pixel (left)
+ 8-15 Palette index for 2nd pixel (right)
+<B> 4bit Texture (16 Color Palette) ;(One 256x256 page = 32Kbytes)</B>
+ 0-3 Palette index for 1st pixel (left)
+ 4-7 Palette index for 2nd pixel (middle/left)
+ 8-11 Palette index for 3rd pixel (middle/right)
+ 12-15 Palette index for 4th pixel (right)
+The clut is a the table where the colors are stored for the image data in the
+CLUT modes. The pixels of those images are used as indexes to this table. The
+clut is arranged in the frame buffer as a 256x1 image for the 8bit clut mode,
+and a 16x1 image for the 4bit clut mode.
+
0-4 Red (0..31) ;\Color 0000h = Fully-transparent
+ 5-9 Green (0..31) ; Color 0001h..7FFFh = Non-transparent
+ 10-14 Blue (0..31) ; Color 8000h..FFFFh = Semi-transparent (*)
+ 15 Semi-transparency Flag ;/(*) or Non-transparent for opaque commands
+On the PSX, texture color 0000h is fully-transparent, that means textures
+cannot contain Black pixels. However, in some cases, Color 8000h (Black with
+semi-transparent flag) can be used, depending on the rendering command:
+
opaque command, eg. GP0(24h) --> 8000h = Non-Transparent Black
+ semi-transp command, eg. GP0(26h) --> 8000h = Semi-Transparent Black
+The GPU has 2 Kbyte Texture Cache
+There is also a CLUT cache that is preserved between GPU drawing commands. The
+CLUT cache is invalidated when different CLUT index values are used or when
+GP0(01h) is issued.
+If polygons with texture are displayed, the GPU needs to read these from the
+frame buffer. This slows down the drawing process, and as a result the number
+of polygons that can be drawn in a given timespan. To speed up this process the
+GPU is equipped with a texture cache, so a given piece of texture needs not to
+be read multiple times in succession.
+The texture cache size depends on the color mode used for the textures.
+In 4 bit CLUT mode it has a size of 64x64, in 8 bit CLUT it's 32x64 and in
+15bitDirect is 32x32. A general speed up can be achieved by setting up textures
+according to these sizes. For further speed gain a more precise knowledge of
+how the cache works is necessary.
The texture page is divided into non-overlapping cache blocks, each of a unit
+size according to color mode. These cache blocks are tiled within the texture
+page.
+
+-----+-----+-----+--
+ |cache| | |
+ |block| |
+ | 0| 1 | 2 ..
+ +-----+-----+--
+ |.. | |
+Each cache block is divided into 256 cache entries, which are numbered
+sequentially, and are 8 bytes wide. So a cache entry holds 16 4bit clut pixels
+8 8bit clut pixels, or 4 15bitdirect pixels.
+
4bit and 8bit clut: 15bitdirect:
+ +----+----+----+----+ +----+----+----+----+----+----+----+----+
+ | 0| 1| 2| 3| | 0| 1| 2| 3| 4| 5| 6| 7|
+ +----+----+----+----+ +----+----+----+----+----+----+----+----+
+ | 4| 5| 6| 7| | 8| 9| a| b| c| d| e| f|
+ +----+----+----+----+ +----+----+----+----+----+----+----+----+
+ | 8| 9| .. | 10| 11| ..
+ +----+----+-- +----+----+--
+ | c| ..| | 18| ..|
+ +----+-- +----+--
+ | .. | ..
+ NTSC video clock = 53.693175 MHz
+ PAL video clock = 53.203425 MHz
+ 263 scanlines per field for NTSC non-interlaced
+ 262.5 scanlines per field for NTSC interlaced
+
+ 314 scanlines per field for PAL non-interlaced
+ 312.5 scanlines per field for PAL interlaced
+ NTSC mode on NTSC video clock
+ Interlaced: 59.940 Hz
+ Non-interlaced: 59.826 Hz
+
+ PAL mode on PAL video clock
+ Interlaced: 50.000 Hz
+ Non-interlaced: 49.761 Hz
+
+ NTSC mode on PAL video clock
+ Interlaced: 59.393 Hz
+ Non-interlaced: 59.280 Hz
+
+ PAL mode on NTSC video clock
+ Interlaced: 50.460 Hz
+ Non-interlaced: 50.219 Hz
+TODO: Derivations for vertical refresh rates; horizontal timing notes
+Nocash's original GPU Timings notes:
+The PSone/PAL video clock is the cpu clock multiplied by 11/7.
+
CPU Clock = 33.868800MHz (44100Hz*300h)
+ Video Clock = 53.222400MHz (44100Hz*300h*11/7)
+ PAL: 314 scanlines per frame (13Ah)
+ NTSC: 263 scanlines per frame (107h)
+ PAL: 3406 video cycles per scanline (or 3406.1 or so?)
+ NTSC: 3413 video cycles per scanline (or 3413.6 or so?)
+ PSX.256-pix Dotclock = 5.322240MHz (44100Hz*300h*11/7/10)
+ PSX.320-pix Dotclock = 6.652800MHz (44100Hz*300h*11/7/8)
+ PSX.368-pix Dotclock = 7.603200MHz (44100Hz*300h*11/7/7)
+ PSX.512-pix Dotclock = 10.644480MHz (44100Hz*300h*11/7/5)
+ PSX.640-pix Dotclock = 13.305600MHz (44100Hz*300h*11/7/4)
+ Namco GunCon 385-pix = 8.000000MHz (from 8.00MHz on lightgun PCB)
+ 320pix/PAL: 3406/8 = 425.75 dots 320pix/NTSC: 3413/8 = 426.625 dots
+ 640pix/PAL: 3406/4 = 851.5 dots 640pix/NTSC: 3413/4 = 853.25 dots
+ 256pix/PAL: 3406/10 = 340.6 dots 256pix/NTSC: 3413/10 = 341.3 dots
+ 512pix/PAL: 3406/5 = 681.2 dots 512pix/NTSC: 3413/5 = 682.6 dots
+ 368pix/PAL: 3406/7 = 486.5714 dots 368pix/NTSC: 3413/7 = 487.5714 dots
+ PAL: 53.222400MHz/314/3406 = ca. 49.76 Hz (ie. almost 50Hz)
+ NTSC: 53.222400MHz/263/3413 = ca. 59.29 Hz (ie. almost 60Hz)
+Above values include "hidden" dots and scanlines (during horizontal and
+vertical blanking/retrace).
0-23 Color for (first) Vertex (Not for Raw-Texture)
+ 24 Texture Mode (0=Blended, 1=Raw) (Textured-Polygon/Rect only)
+ 25 Semi-transparency (0=Off, 1=On) (All Render Types)
+ 26 Texture Mapping (0=Off, 1=On) (Polygon/Rectangle only)
+ 27-28 Rect Size (0=Var, 1=1x1, 2=8x8, 3=16x16) (Rectangle only)
+ 27 Num Vertices (0=Triple, 1=Quad) (Polygon only)
+ 27 Num Lines (0=Single, 1=Poly) (Line only)
+ 28 Shading (0=Flat, 1=Gouroud) (Polygon/Line only)
+ 29-31 Primitive Type (1=Polygon, 2=Line, 3=Rectangle)
+The PSX doesn't support perspective correct rendering: Assume a polygon to be
+rotated so that it's right half becomes more distant to the camera, and it's
+left half becomes closer. Due to the GTE's perspective division, the right half
+should appear smaller than the left half.
+The GPU supports only linear interpolations for rendering - that is correct
+concerning the X and Y screen coordinates (which are still linear to each
+other, even after perspective division, since both are divided by the same
+value).
+However, texture coordinates (and Gouraud shaded colors) are NOT linear to the
+screen coordinates, and so, the linear interpolated PSX graphics are often
+looking rather distorted, that especially for textures that contain straight
+lines. For color shading the problem is less obvious (since shading is kinda
+blurry anyways).
For perspective correct rendering, the polygon's Z-coordinates would be needed
+to be passed from the GTE to the GPU, and, the GPU would then need to use that
+Z-coordinates to "undo" the perspective division for each pixel (that'd require
+some additional memory, and especially a powerful division unit, which isn't
+implemented in the hardware).
+As a workaround, you can try to reduce the size of your polygons (the
+interpolation errors increase in the center region of larger polygons).
+Reducing the size would be only required for polygons that occupy a larger
+screen region (which may vary depending on the distance to the camera).
+Ie. you may check the size AFTER perspective division, if it's too large, then
+break it into smaller parts (using the original coordinates, NOT the screen
+coordinates), and then pass the fragments to the GTE another time.
+Again, perspective correction would be relevant only for certain textures (not
+for randomly dithered textures like sand, water, fire, grass, and not for
+untextured polygons, and of course not for 2D graphics, so you may exclude
+those from size reduction).
For dithering, VRAM is broken to 4x4 pixel blocks, depending on the location in
+that 4x4 pixel region, the corresponding dither offset is added to the 8bit
+R/G/B values, the result is saturated to +00h..+FFh, and then divided by 8,
+resulting in the final 5bit R/G/B values.
+
-4 +0 -3 +1 ;\dither offsets for first two scanlines
+ +2 -2 +3 -1 ;/
+ -3 +1 -4 +0 ;\dither offsets for next two scanlines
+ +3 -1 +2 -2 ;/(same as above, but shifted two pixels horizontally)
+The GPU has a shading function, which will scale the color of a primitive to a
+specified brightness. There are 2 shading modes: Flat shading, and gouraud
+shading. Flat shading is the mode in which one brightness value is specified
+for the entire primitive. In Gouraud shading mode, a different brightness value
+can be given for each vertex of a primitive, and the brightness between these
+points is automatically interpolated.
When semi-transparency is set for a pixel, the GPU first reads the pixel it
+wants to write to, and then calculates the color it will write from the 2
+pixels according to the semi-transparency mode selected. Processing speed is
+lower in this mode because additional reading and calculating are necessary.
+There are 4 semi-transparency modes in the GPU.
+
B=Back (the old pixel read from the frame buffer)
+ F=Front (the new semi-transparent pixel)
+ * 0.5 x B + 0.5 x F ;aka B/2+F/2
+ * 1.0 x B + 1.0 x F ;aka B+F
+ * 1.0 x B - 1.0 x F ;aka B-F
+ * 1.0 x B +0.25 x F ;aka B+F/4
+Modulation is a colour effect that can be applied to textured primitives.
+For each pixel of the primitive it combines every colour channel of the fetched
+texel with the corresponding channel of the interpolated vertex colour according
+to this formula (Assuming all channels are 8-bit).
+
finalChannel.rgb = (texel.rgb * vertexColour.rgb) / vec3(128.0)
+This will enable/disable any drawing to the area that is currently displayed.
+Not sure yet WHY one should want to disable that?
+Also not sure HOW and IF it works... the SIZE of the display area is implied by
+the screen size - which is horizontally counted in CLOCK CYCLES, so, to obtain
+the size in PIXELS, the hardware would require to divide that value by the
+number of cycles per pixel, depending on the current resolution...?
SCPH-1000 PlayStation (1994) (NTSC-J) (with S-Video)
+ SCPH-1001 PlayStation (1995) (NTSC-U/C) (without S-Video)
+ SCPH-1002 PlayStation (199x) (PAL) (without S-Video)
+ SCPH-1010 Digital joypad (with short cable) (1994)
+ SCPH-1020 Memory Card 1Mbits (1994)
+ SCPH-1030 2-button Mouse (with short cable) (1994)
+ SCPH-1040 Serial Link Cable
+ SCPH-1050 RGB Cable (21-pin RGB Connector)
+ SCPH-1060 RFU Cable/Adaptor (antennae connector) (NTSC-JP?) (1995)
+ SCPH-1061 RFU Cable/Adaptor (antennae connector) (NTSC-US?)
+ SCPH-1062 RFU Cable/Adaptor (antennae connector) (PAL)
+ SCPH-1070 Multitap adaptor (four controllers/memory cards on one slot) (1995)
+ SCPH-1080 Digital joypad (with longer cable) (1996)
+ SCPH-1090 2-button Mouse (with longer cable) (1998)
+ SCPH-1100 S Video Cable (1995)
+ SCPH-1110 Analog Joystick (1996)
+ SCPH-1120 RFU Adaptor (antennae connector) (NTSC-JP?) (1996)
+ SCPH-1121 RFU Adaptor (antennae connector) (NTSC-US?)
+ SCPH-1122 RFU Adaptor (antennae connector) (PAL)
+ SCPH-1130 AC Power Cord (1996)
+ SCPH-1140 AV Cable (1997)
+ SCPH-1150 Analog Joypad (with one vibration motor, with red/green led) (1997)
+ SCPH-1160 AV Adaptor (1997)
+ SCPH-1170 Memory Card Triple Pack (three Memory Cards) (1996)
+ SCPH-1180 Analog Joypad (without vibration motors, with red/green led)
+ SCPH-119X Memory Card (X=different colors) (1997)
+ SCPH-1200 Analog Joypad (with two vibration motors) (dualshock) (1997)
+ SCPH-1210 Memory Card Case (1998)
+ SCPH-2000 Keyboard/Mouse adapter (PS/2 to PSX controller port; for Lightspan)
+ SCPH-3000 PlayStation (1995) (NTSC-J) (with the S-video output removed)
+ SCPH-3500 PlayStation Fighting Box (console bundled with 2 controllers)(1996)
+ SCPH-4000 PocketStation (Memory Card with LCD-screen) (1999)
+ SCPH-4010 VPick (guitar-pick controller) (for Quest for Fame, Stolen Song)
+ SCPH-4020 Long Strap for PocketStation (1999)
+ SCPH-4030 Wrist Strap for PocketStation (1999)
+ SCPH-5000 PlayStation (cost reduced) (Japan) (1996) ;\exists in these three
+ SCPH-5001 PlayStation (cost reduced) (North America) ; regions only (not
+ SCPH-5003 PlayStation (Asia) ;/in Europe)
+ SCPH-5500 PlayStation without Cinch sockets (ie. AV Multi Out only) (1996)(J)
+ SCPH-5501 "" North American version of the 5500
+ SCPH-5502 "" European version of the 5500 (shipped with 1 digital joypad)
+ SCPH-5552 Same as SCPH-5502 (but shipped with memcard and 2 digital joypads)
+ SCPH-5903 PlayStation with built-in MPEG Video-CD decoder (Asia-only)
+ SCPH-7000 PlayStation with Dualshock (1997) (Japan)
+ SCPH-7001 PlayStation with Dualshock (199x) (North America)
+ SCPH-7002 PlayStation with Dualshock (199x) (Europe)
+ SCPH-7003 PlayStation with Dualshock (199x) (Asia)
+ SCPH-7000W PlayStation (10 million model, not for sale, blue, region free)
+ SCPH-7500 PlayStation with Dualshock, cost reduced (1999) (Japan)
+ SCPH-7501 PlayStation with Dualshock, cost reduced (199x) (North America)
+ SCPH-7502 PlayStation with Dualshock, cost reduced (199x) (Europe)
+ SCPH-7503 PlayStation with Dualshock, cost reduced (199x) (Asia)
+ SCPH-9000 PlayStation without Parallel I/O port (1999) (Japan)
+ SCPH-9001 PlayStation without Parallel I/O port (199x) (North America)
+ SCPH-9002 PlayStation without Parallel I/O port (199x) (Europe)
+ SCPH-9003 PlayStation without Parallel I/O port (199x) (Asia)
+ SCPH-9903 Rare SCEx-free PSX (Property of Sony Computer Entertainment, U/C)
+ SFX-100 PlayStation Super Disc Prototype (with SNES chipset, no PSX chips)
+ SCPH-100 PSone (miniaturized PlayStation) (2000) (Japan)
+ SCPH-101 PSone (miniaturized PlayStation) (200x) (North America)
+ SCPH-102 PSone (miniaturized PlayStation) (200x) (Europe)
+ SCPH-103 PSone (miniaturized PlayStation) (200x) (Asia)
+ SCPH-102A PSone Europe (UK/AU, with A/V cable) ;\revision of "SCPH-102"
+ SCPH-102B PSone Europe (UK, with RFU adaptor) ; with PM-41(2) board ?
+ SCPH-102C PSone Europe (Continent, with A/V cable) ;/
+ SCPH-110 Dual Analog Pad (for PSone) (Dualshock) (2000)
+ SCPH-111 Multitap for PSone (seems to be quite rare, except in brazil)
+ SCPH-112 AC adapter for PSone (In: 110-220VAC, Out: 7.5VDC, 2.0A, Japan)
+ SCPH-113 AC adapter for PSone (In: 120VAC/60Hz, Out: 7.5VDC, 2.0A, USA)
+ SCPH-114 AC adapter for PSone (In: 220-240VAC, Out: 7.5VDC, 2.0A, Europe)
+ SCPH-115 AC adapter for PSone (In: 220-240VAC, Out: 7.5VDC, 2.0A, UK)
+ SCPH-116 AC adapter for PSone (In: 220-240VAC, Out: 7.5VDC, 2.0A, Australia)
+ SCPH-117 AC adapter for PSone (In: 110VAC, Out: 7.5VDC, 2.0A, Asia?)
+ SCPH-120 AC adapter for PSone with LCD Screen (In: 100VAC, Out: 7.5VDC, 3.0A)
+ SCPH-130 LCD Screen for PSone (to be attached to the console) (2001)
+ SCPH-140 PSone and LCD screen combo (2001)
+ SCPH-152 LCD screen for PSone (PAL SCPH-152C)
+ SCPH-162 PSone and LCD screen (PAL SCPH-162C)
+ SCPH-170 Car Adapter for PSone from car cigarette lighter (2001)
+ SCPH-180 AV Connection Cable for LCD-screen's AV IN
+ SCPH-10180K DoCoMo I-Mode Adaptor Cable (for internet via mobile phones)
+ SCPH-10150 PS2 DVD remote
+ SCPH-10160 IR receiver dongle for PS2 DVD remote
+ DTL-H201A Graphic Artist Board (ISA bus) (with NTSC video out)
+ DTL-H240 PS-X RGB Cable
+ DTL-H500C Digital joypad prototype (SNES-style design, with DB9 connector)
+ DTL-H505 PS-X (Code Name) Target Box ? (PSX prototype, SCSI instead CDROM?)
+ DTL-H700 Sound Artist Board (NuBus for Mac)
+ DTL-H800 Sound Artist Board (PCI Bus for IBM) (with optical fibre sound out)
+ DTL-H1000 Debugging Station (CD-R compatible PSX console) (Japan)
+ DTL-H1001 Debugging Station (CD-R compatible PSX console) (North America)
+ DTL-H1002 Debugging Station (CD-R compatible PSX console) (Europe)
+ DTL-H1030 Mouse ?
+ DTL-H1040 Link Cable ?
+ DTL-H1050 RGB Cable ?
+ DTL-H110x Debugging Station revision? (DC-powered)
+ DTL-H120x Debugging Station revision? (AC-powered)
+ DTL-H1500 Stand-Alone Box ? With ethernet, for SGI Workstation ?
+ DTL-H2000 Dev board v1 (PSX on two ISA carts) (old pre-retail)
+ DTL-H2010 Black External CDROM Drive for DTL-H2000 (CD-R compatible)
+ DTL-H2040 Memory Box ?
+ DTL-H2050 Adaptor for Controller port ?
+ DTL-H2060 Serial Link cable
+ DTL-H2070 RGB Cable ?
+ DTL-H2080 Controller Box (joypad/memcard adaptor for DTL-H2000/DTL-xxxx?)
+ DTL-H2500 Dev board (PCI bus)
+ DTL-H2510 Gray Internal CDROM Drive for DTL-H2500/DTL-H2700 (CD-R compatible)
+ DTL-H2700 Dev board (ISA bus) (CPU, ANALYZER ...?)
+ DTL-H3000 Net Yaroze (hobby programmer dev kit) (Japan)
+ DTL-H3001 Net Yaroze (hobby programmer dev kit) (North America)
+ DTL-H3002 Net Yaroze (hobby programmer dev kit) (Europe)
+ DTL-H3020 Access Card (for yaroze)
+ DTL-H3050 Communication Cable (link port to rs232, for yaroze)
+ DTL-D2020 Documentation: BUILD CD (Manual of Programmer's Tool)
+ DTL-D2120 Documentation: (Manual of Programmer's Tool)
+ DTL-D2130 Documentation: PsyQ (Manual of Programmer's Tool)
+ DTL-D2130 Documentation: SdevTC (Manual of Programmer's Tool)
+ DTL-D2140A Documentation: Ver.1.0 (Manual of Programmer's Tool)
+ DTL-D2150A Documentation: Ver.2.0 (Manual of Programmer's Tool)
+ DTL-S510B Unknown (another CDROM emulator version?)
+ DTL-S2020 CD-ROM EMULATOR for DTL-H2000/DTL-H2500/DTL-H2700
+ SLPH-00001 Namco neGcon (white) (NPC-101), Twist controller (SLEH-0003)
+ SLPH-00002 Hori Fighting stick, digital stick with autofire/slowmotion/rumble
+ SLPH-00003 ASCII Fighter stick V, psx-shaped digital stick (SLEH-0002)
+ SLPH-00004 Sunsoft Sunstation pad, digital pad with autofire/slowmotion
+ SLPH-00005 ASCII ASCIIPAD V, digital pad with autofire/slowmotion
+ SLPH-00006 Imagineer Sandapaddo ThunderPad
+ SLPH-00007 SANKYO N.ASUKA aka Nasca Pachinco Handle, bizarre paddle
+ SLPH-00008 Spital SANGYO Programmable joystick
+ SLPH-00009 Hori Fighting commander 2way controller
+ SLPH-00010 Optec Super Pro Commander
+ SLPH-00011 Super Pro Commander Accessory / Extended memo repack memory
+ SLPH-00012 Hori Fighting Commander 10B Pad (gray), digital pad with extras
+ SLPH-00013 Konami Hyper Blaster (green) ;\IRQ10-based Lightgun
+ SLPH-00014 Konami Hyper Blaster (black) ;/(SLEH-0005/SLUH-00017)
+ SLPH-00015 Namco Volume controller, paddle with 2 buttons
+ SLPH-00016 Waka Up Scan Converter "[chiyo] clean! peripheral equipment?"
+ SLPH-00017 Hori Fighting Commander 10B Pad (black), digital pad with extras
+ SLPH-00018 Hori Real Arcade Stick, digital stick, small L1/L2 (HPS-10)
+ SLPH-00019 Konami Hyperstick
+ SLPH-00020 Imagineer Thunder Pad Transparent
+ SLPH-00021 Imagineer Imagegun
+ SLPH-00022 Optec AI Commander Pro, digital pad with extras / lcd display
+ SLPH-00023 Namco Joystick (SLEH-00004)
+ SLPH-00024 Optec Cockpit Wheel, analog joystick/analog pedals or so
+ SLPH-00025 Optec AI Commander Accessory (extended memo repack ZERO2 version)
+ SLPH-00026 Hori Command Stick PS (SLPH-00026 aka HPS11)
+ SLPH-00027 ASCII Grip, single-handed digital pad (SLEH-00008)
+ SLPH-00028 Hori Grip (gray) (see also: SLPH-00040, and 00086..00088)
+ SLPH-00029 Hori Horipad (clear), digital pad
+ SLPH-00030 Hori Horipad (black), digital pad
+ SLPH-00031 Hori Horipad (gray), digital pad
+ SLPH-00032 Hori Horipad (white), digital pad
+ SLPH-00033 Hori Horipad (blue), digital pad
+ SLPH-00034 Namco G-CON 45, Cinch-based Lightgun (SLEH-0007/SLUH-00035)
+ SLPH-00035 ASCII Fighter stick V Jr. (SLEH-00009)
+ SLPH-00036 Optec Wireless Dual Shot, digital pad with turbo button
+ SLPH-00037 ?
+ SLPH-00038 ASCII Pad V Jr., digital pad without any extras
+ SLPH-00039 ASCII Pad V2 (gray), digital pad with turbo switches (SLEH-00010)
+ SLPH-00040 Hori Grip (black)
+ SLPH-00041 ASCII Grip V
+ SLPH-00042 ASCII Grip V plus (Derby Stallion'99 supplement set), single-hand
+ SLPH-00043 ASCII Pad V2 (clear pink)
+ SLPH-00044 ASCII Pad V2 (clear white)
+ SLPH-00045 ASCII Pad V2 (clear blue)
+ SLPH-00046 ASCII Pad V2 (clear green)
+ SLPH-00047 ASCII Pad V2 (clear black)
+ SLPH-00048 ASCII Pad V2 (clear red/lead?)
+ SLPH-00049 ASCII Pad V2 (clear yellow)
+ SLPH-00050 ASCII Pad V2 (clear orange)
+ SLPH-00051 Taito Streetcar GO! Controller 2 steering "wheel?" tie toe strange
+ SLPH-00052 Koei Video Capture, Ergosoft EGWord, and Lexmark Printer bundle
+ SLPH-00053 Koei Word Processor Ergosoft September EGWORD Ver.2.00
+ SLPH-00054 Hori Zerotech Steering Controller (black)
+ SLPH-00055 Hori Grip (clear blue)
+ SLPH-00056 Hori Grip (clear pink)
+ SLPH-00057 Hori Grip (clear yellow)
+ SLPH-00058 ASCII Pad V2 (gold)
+ SLPH-00059 ASCII Pad V2 (silver)
+ SLPH-00060 ASCII Biohazard, digital pad with re-arranged buttons (SLEH-0011)
+ SLPH-00061 ASCII Pad V2 (pearl white)
+ SLPH-00062 ASCII Pad V2 (pearl blue)
+ SLPH-00063 ASCII Pad V2 (pearl pink)
+ SLPH-00064 ASCII Pad V2 (pearl green)
+ SLPH-00065 ASCII Pad V Pro, with lcd for button-combinations (ASC-0508GX)
+ SLPH-00066 ASCII Arcade Stick 3 "Ultimate"
+ SLPH-00067 ASCII Pad V2 (purple metallic)
+ SLPH-00068 ASCII Pad V2 (lead metallic)
+ SLPH-00069 Namco neGcon (black) (NPC-104), Twist controller (SLEH-0003)
+ SLPH-00070 Sankyo Pachinko FF Controller (alternate to SLPH-00007)
+ SLPH-00071 Hori Command Stick PS Custom
+ SLPH-00072 ASCII Command Pack (memory card add-on or so)
+ SLPH-00073 Optec Wireless digital set (gray) ;\
+ SLPH-00074 Optec Wireless digital set (black) ; pad with receiver
+ SLPH-00075 Optec Wireless digital set (clear) ;
+ SLPH-00076 Optec Wireless digital set (clear blue) ;
+ SLPH-00077 Optec Wireless digital set (clear black) ;/
+ SLPH-00078 Optec Wireless digital shot (gray) ;\
+ SLPH-00079 Optec Wireless digital shot (black) ; extra pad for
+ SLPH-00080 Optec Wireless digital shot (clear) ; second player
+ SLPH-00081 Optec Wireless digital shot (clear blue) ; (without receiver)
+ SLPH-00082 Optec Wireless digital shot (clear black) ;/
+ SLPH-00083 ASCII Stick Justice controller
+ SLPH-00084 Hori ZeroTech Steering Controller (clear)
+ SLPH-00085 Hori Compact joystick (black)
+ SLPH-00086 Hori Compact joystick (clear)
+ SLPH-00087 Hori Compact joystick (clear blue)
+ SLPH-00088 Hori Multi Analog Pad (clear) or Hori Grip (pink?)
+ SLPH-00089 Hori AV Cable with selector
+ SLPH-00090 Hori Multi Analogue Pad (clear black)
+ SLPH-00091 Hori AV Multi-Out Converter
+ SLPH-00092 ASCII Pad V2 (margin green)
+ SLPH-00093 ASCII Pad V2 (margin blue)
+ SLPH-00094 ASCII Pad V2 (margin pink)
+ SLPH-00095 ASCII Pad V2 (margin orange)
+ SLPH-00096 ASCII Hyper Steering V ("high pass tear ring V controller?")
+ SLPH-00097 Hori S Cable with selector (uh, maybe S-video or so?) (HPS-36)
+ SLPH-00098 NSYSCOM Pachinko slot controller (NSC-1)
+ SLPH-00099 ASCII Pad V2 (rainbow)
+ SLPH-00100 ASCII 'Hanging' Fishing Controller, controller for fishing games
+ SLPH-00101 Optec Cockpit big shock
+ SLPH-00102 ASCII Grip V (set for mars story)
+ SLPH-00103 Hori Pad V2 (clear)
+ SLPH-00104 Hori Pad V2 (clear blue)
+ SLPH-00105 Hori Pad V2 (clear pink)
+ SLPH-00106 Hori Pad V2 (black)
+ SLPH-00107 Hori Compact Joystick (camouflage)
+ SLPH-00108 Hori Rumble Digital Pad (clear blue)
+ SLPH-00109 Hori Monoaural AV Cable
+ SLPH-00110 ASCII Pad V2 (marble)
+ SLPH-00111 ASCII Pad V2 (camouflage)
+ SLPH-00112 ASCII Pad V3
+ SLPH-00113 ASCII Pad V3 with cable reel
+ SLPH-00114 ASCII Pad V3 with V2 (pearl white) bundle
+ SLPH-00115 ASCII Pad V3 with V2 (pearl pink) bundle
+ SLPH-00116 ASCII Pad V3 with V2 (pearl blue) bundle
+ SLPH-00117 ASCII Pad V3 (blue) with V2 (pearl green) bundle
+ SLPH-00118 Hori Pad V3
+ SLPH-00119 Hori Pad V3 (white)
+ SLPH-00120 Hori Analog Rumble Pad (clear pink)
+ SLPH-00121 Hori Analog Rumble Pad (clear)
+ SLPH-00122 Hori Analog Rumble Pad (clear blue)
+ SLPH-00123 Hori Analog Rumble Pad (clear red)
+ SLPH-00124 Hori Analog Rumble Pad (clear black)
+ SLPH-00125 Hori Analog Rumble Pad (clear yellow)
+ SLPH-00126 Namco Jogcon, digital pad, steering dial (SLEH-0020/SLUH-00059)
+ SLPH-00127 ?
+ SLPH-00128 ASCII stick ZERO3
+ SLPH-00129 ASCII Pad V2 (wood grain pitch)
+ SLPH-00130 Hori Real Arcade (camouflage)
+ SLPH-00131 Hori Ehrgeiz Stick
+ SLPH-00132 ASCII Pad V3 (blue)
+ SLPH-00133 ASCII Fighter Stick V Jr. (limited edition)
+ SLPH-00134 ASCII Pad V3 (blue) with cable reel
+ SLPH-00135 ASCII Pad V3 (blue) with V2 (silver)
+ SLPH-00136 ASCII Pad V3 with V2 (purple metallic)
+ SLPH-00137 ASCII Pad V3 with V2 (gold)
+ SLPH-00138 ASCII Pad V3 with "VPRO. aka Ascii Fighter Stick V"
+ SLPH-00139 Hori Analog Rumble Pad (gray)
+ SLPH-00140 Hori Analog Rumble Pad (black)
+ SLPH-00141 Hori Analog Rumble Pad (blue)
+ ASC-05158B ASCII Beatmania Junk (similar to SLEH-0021)
+ ASC-0528T Sammy Shakkato Tambourine
+ BANC-0001 Bandai Fishing Controller
+ BANC-0002 Bandai Kids Station
+ RU017 Konami Dance Dance Revolution Controller (Dance Mat)
+ GAE001 G.A.E. Baton stick with 2 buttons (for The Maestromusic)
+ RU029 Konami Beatmania IIDX
+ RU014 Konami Pop'n Music (buttons A,B,C,D,E,F,G,H,I, and Select/Start)
+ RU014-J2 Konami Pop'n Controller 2
+ RU036 Konami Pop'n Controller (Arcade Style)
+ ? Produce! Paca Paca Passion
+ ? Sega/Ascii Minimoni Shakatto Tambourine
+ SLEH-00001 Ascii Specialized Pad (similar to SLPH-00005: ASCII ASCIIPAD V)
+ SLEH-00002 Ascii Arcade Stick, psx-shaped digital stick (SLPH-00003)
+ SLEH-00003 Namco Negcon, Twist controller (SLPH-00001)
+ SLEH-00004 Namco Arcade Stick (SLPH-00023)
+ SLEH-00005 Konami Hyper Blaster, IRQ10-based Lightgun (SLPH-00014/SLUH-00017)
+ SLEH-00006 Mad Catz Steering Wheel (SLPH-?)
+ SLEH-00007 Namco G-Con 45, Cinch-based Lightgun (SLPH-00034/SLUH-00035)
+ SLEH-00008 Ascii Grip, single-handed digital pad (SLPH-00027/SLUH-00038)
+ SLEH-00009 Ascii Arcade Stick v2 (SLPH-00035)
+ SLEH-00010 Ascii Enhanced Control Pad (similar as SLEH-00001) (SLPH-00039)
+ SLEH-00011 Resident Evil Pad (aka SLPH-00060 ASCII Biohazard)
+ SLEH-00012 Reality-Quest The Glove (right-handed only) (SLUH-00045/SLPH-?)
+ SLEH-00013 CD Case (small nylon bag for fourteen CDs) (SLPH-?)
+ SLEH-00014 ?
+ SLEH-00015 PlayStation Case (bigger bag for the console) (SLPH-?)
+ SLEH-00016 PlayStation Case + Digital Joypad + Memory Card
+ SLEH-00017 ?
+ SLEH-00018 Ascii Sphere 360 (SLUH-00028/SLPH-?)
+ SLEH-00019 Interact V3 Racing Wheel (SLPH-?)
+ SLEH-00020 Namco JogCon, digital pad, steering dial (SLPH-00126/SLUH-00059)
+ SLEH-00021 Konami Beatmania Controller (SLPH-?)
+ SLEH-00022 ?
+ SLEH-00023 Official Dance Mat (RU017/SLUH-00071) (for PSone and PS2)
+ SLEH-00024 Fanatec Speedster 2 (wheel with pedals) (for PSone and PS2)
+ SLEH-00025 Mad Catz 8MB Memory Card (for PS2)
+ SLEH-00026 Olympus Eye-Trek FMD-20P Game/DVD glasses (for PS2)
+ SLEH-00027 Logitech Cordless Controller... or Eye-Trek FMD-20P, too? (PSx?)
+ SLEH-00028 ?
+ SLEH-00029 Fanatec Speedster 3 (for PS2)
+ SLEH-00030 Logitech Eye Toy (camera?) (for PS2)
+ Mad Catz Wrist Rumbler (rumble add-on for pre-dualshock controllers)
+ SLUH-00001 Specialized Joystick (single-axis, digital?)
+ SLUH-00002 Control Pad (redesigned joypad)
+ SLUH-00003 InterAct Piranha Pad, digital pad, autofire/slowmotion
+ SLUH-00017 Konami Justifier, IRQ10-based Lightgun (Hyperblaster/SLPH-00014)
+ SLUH-00018 Enhanced Pad (joypad with whatever extra functions)
+ SLUH-00022 Analog and Digital Steering Wheel with pedals (for testdrive 4?)
+ SLUH-00026 Optec Mach 1 (gray steering/flight controller with pedals)
+ SLUH-00028 Ascii Sphere 360 (SLEH-00018)
+ SLUH-00029 Namco NPC-102 Joystick (single-axis, digital?)
+ SLUH-00031 Interact Program Pad
+ SLUH-00033 Piranha Pad (redesigned joypad)
+ SLUH-00034 NUBY Manufacturing The Heater, white lightgun (irq10 or cinch?)
+ SLUH-00035 Namco G-CON 45, Cinch-based Lightgun (SLEH-0007/SLPH-00034)
+ SLUH-00037 Arcade Stick (single-axis, digital?)
+ SLUH-00038 ASCII Grip V, single-handed digital pad (SLPH-00027/SLEH-00008)
+ SLUH-00040 System Organizer (huh? looks like... a black storage box?)
+ SLUH-00041 V3 Racing Wheel with pedals
+ SLUH-00043 GunCon (bundled with Time Crisis 1)
+ SLUH-00044 Remote Wizard (looks like wireless joypad or so)
+ SLUH-00045 Reality-Quest The Glove (right-handed only) (SLEH-00012/SLPH-?)
+ SLUH-00046 GunCon (bundled with Point Blank)
+ SLUH-00055 Aftershock Wheel with pedals
+ SLUH-00056 UltraRacer Steering Controller (grip-style)
+ SLUH-00057 EA Sports Game Pad (redesigned joypad)
+ SLUH-00058 something for point blank 2 (?) (maybe a lightgun)
+ SLUH-00059 Namco Jogcon, digital pad, steering dial (SLEH-0020/SLPH-00126)
+ SLUH-00061 MadCatz MC2 Racing Wheel (black/gray)
+ SLUH-00063 Bass Landing Fishing Reel controller
+ SLUH-00066 Sportster racing wheel
+ SLUH-00068 Jungle Book Rhythm N Groove Dance Pack
+ SLUH-00071 Konami Dance Pad (DDR Dance Pad) (RU017)
+ SLUH-00072 GunCon (bundled with Point Blank 3)
+ SLUH-00073 GunCon (bundled with Time Crisis 2 - Project Titan)
+ SLUH-00077 Logitech Cordless Controller, analog pad (ps1/ps2)
+ SLUH-00081 Logitech NetPlay Controller, pad with keyboard (usb/ps2)
+ SLUH-00083 Konami Dance Dance Revolution Controller (for PS1 and PS2)
+ SLUH-00084 NYKO iType2, pad with keyboard (usb/ps2)
+ SLUH-00085 Logitech Cordless Action Controller (for PS2)
+ SLUH-00086 Namco/Taiko Drum Master (Taiko Controller Pack) (for PS2)
+ SLUH-00088 RedOctane In the Groove Dance Pad Controller ?
+ SLUH-00090 Dance Pad (bundled with Pump It Up) (for PS2)
+ Unknown (if any)
+ SCEH-0001 SingStar (USB to Microfon) (for PS2)
+Early SLEH/SLUH devices used 4-digit numbers (eg. the "official" name for
+SLEH-00003 is SLEH-0003; unlike as shown in the above list).
CPCS-00701 Dino Crisis 5th Anniversary Box Serial
+ DTL-NNNNN Development Tool Licensed (Net Yaroze)
+ ESPM-NNNNN Sony Music Entertainment Japan (Music Video Discs)
+ LSP-NNNNNN Lightspan series (non-retail educational games)
+ PAPX-NNNNN Japanese Demos/Rental Editions/Taikenban
+ PBPX-NNNNN Official Playstation Sampler Discs (USA/UK)
+ PCPX-NNNNN Japanese Otameshi Discs (Samplers)
+ PEPX-NNNNN Analog Controller Service Disc
+ PUPX-NNNNN Analog controller Service Disc
+ PSRM-017100 Syphon Filter 2 Disc 2 Preview Version
+ PSXCDCLEAN Laser Clean
+ PTPX-NNNNN Aging Disk
+ SCAJ-NNNNN Sony Computer Entertainment America ... ?
+ SCED-NNNNN Sony Computer Europe Demo
+ SCES-NNNNN Sony Computer Europe Software
+ SCPM-NNNNN Sony Computer Japan ...?
+ SCPS-NNNNN Sony Computer Japan Software
+ SCUS-NNNNN Sony Computer USA Software
+ SCZS-NNNNN Sony Computer ... Software? (Fan Books)
+ SIPS-NNNNN Sony Imports ...? (All Imports to Japan)
+ SLED-NNNNN Sony Licensed Europe Demo
+ SLES-NNNNN Sony Licensed Europe Software
+ SLKA-NNNNN Sony Licensed Korea ...? (3 Korean Releases)
+ SLPM-NNNNN Sony Licensed Japan ... ?
+ SLPS-NNNNN Sony Licensed Japan Software
+ SLUS-NNNNN Sony Licensed USA Software
+ SPUS-NNNNN Sony Playstation US ...? (Playstation Picks Disc)
+On the 20th of August 2022, Martin surprisingly released a new version of this documentation. While this fork will try to incorporate the changes, one important footnote that got added is the following:
+++I am homeless in Hamburg, please help me out!
+
The authors of this fork thought that this deserves more than a footnote, hence this notice here.
+This is a conversion/edition of Martin "nocash" Korth's Playstation specs document originally hosted at https://problemkaputt.de/psx-spx.htm. See https://github.com/psx-spx/psx-spx.github.io#readme for more details.
+You can also download this website as a single-page pdf.
Martin is a difficult individual to reach (see https://problemkaputt.de/email.htm, especially the part about gmail), and so far, any attempt at contacting him about collaborating on this document failed.
+Therefore, no copyright or license have been properly acquired to republish and alter this document. However, since this repository will accept and proceed to issue corrections, amendments, and additions to the original work, the fair use and derivative work doctrine is believed to be applicable in this case.
+An important detail to know about this current document, as well as the original from Martin, is that it isn't a clean room reverse engineering project, as some people may seem to believe or repeat. A good chunk of the original document has been either directly copy/pasted from the confidential code and documentation from Sony, or summarized and rephrased. As this document isn't clean room, any work derived from it shouldn't be considered clean, and anyone saying otherwise is misguided at best. The reference source material, code, and documentation used to make this document can be found at https://psx.arthus.net/sdk/Psy-Q/
+To discuss the contents of this document, or hang out with likely minded people on development, hacking, and reverse engineering of Sony's first console, feel free to join the PSX.Dev Discord Server.
+Memory Map
+I/O Map
+Graphics Processing Unit (GPU)
+Geometry Transformation Engine (GTE)
+Macroblock Decoder (MDEC)
+Sound Processing Unit (SPU)
+Interrupts
+DMA Channels
+Timers
+CDROM Drive
+CDROM File Formats
+Controllers and Memory Cards
+Pocketstation
+Serial Interfaces (SIO)
+Expansion Port (PIO)
+Memory Control
+Unpredictable Things
+CPU Specifications
+Kernel (BIOS)
+Arcade Cabinets
+Konami System 573
+Cheat Devices
+PSX Dev-Board Chipsets
+Hardware Numbers
+Pinouts
+About & Credits
+CDROM Video CDs (VCD)
+CDROM Internal Info on PSX CDROM Controller
Status: Read I_STAT (0=No IRQ, 1=IRQ)
+Acknowledge: Write I_STAT (0=Clear Bit, 1=No change)
+Mask: Read/Write I_MASK (0=Disabled, 1=Enabled)
+
0 IRQ0 VBLANK (PAL=50Hz, NTSC=60Hz)
+ 1 IRQ1 GPU Can be requested via GP0(1Fh) command (rarely used)
+ 2 IRQ2 CDROM
+ 3 IRQ3 DMA
+ 4 IRQ4 TMR0 Timer 0 aka Root Counter 0 (Sysclk or Dotclk)
+ 5 IRQ5 TMR1 Timer 1 aka Root Counter 1 (Sysclk or H-blank)
+ 6 IRQ6 TMR2 Timer 2 aka Root Counter 2 (Sysclk or Sysclk/8)
+ 7 IRQ7 Controller and Memory Card - Byte Received Interrupt
+ 8 IRQ8 SIO
+ 9 IRQ9 SPU
+ 10 IRQ10 Controller - Lightpen Interrupt. Also shared by PIO and DTL cards.
+ 11-15 Not used (always zero)
+ 16-31 Garbage
+The interrupt request bits in I_STAT are edge-triggered, ie. the get set ONLY
+if the corresponding interrupt source changes from "false to true".
+If one or more interrupts are requested and enabled, ie. if "(I_STAT AND
+I_MASK)=nonzero", then cop0r13.bit10 gets set, and when cop0r12.bit10 and
+cop0r12.bit0 are set, too, then the interrupt gets executed.
To acknowledge an interrupt, write a "0" to the corresponding bit in I_STAT.
+Most interrupts (except IRQ0,4,5,6) must be additionally acknowledged at the
+I/O port that has caused them (eg. JOY_CTRL.bit4).
+Observe that the I_STAT bits are edge-triggered (they get set only on
+High-to-Low, or False-to-True edges). The correct acknowledge order is:
+
First, acknowledge I_STAT (eg. I_STAT.bit7=0)
+ Then, acknowledge corresponding I/O port (eg. JOY_CTRL.bit4=1)
+Relevant COP0 registers are cop0r13 (CAUSE, reason flags), and cop0r12 (SR,
+control flags), and cop0r14 (EPC, return address), and, cop0cmd=10h (aka RFE
+opcode) is used to prepare the return from interrupts. For more info, see
+COP0 - Exception Handling
COP0 has six hardware interrupt bits, of which, the PSX uses only cop0r13.bit10
+(the other ones, cop0r13.bit11-15 are always zero). cop0r13.bit10 is NOT a
+latch, ie. it gets automatically cleared as soon as "(I_STAT AND I_MASK)=zero",
+so there's no need to do an acknowledge at the cop0 side. COP0 additionally has
+two software interrupt bits, cop0r13.bit8-9, which do exist in the PSX, too,
+these bits are read/write-able latches which can be set/cleared manually to
+request/acknowledge exceptions by software.
The PS2's IOP has the same interrupt controller as the PS1 but with more
+channels. For more details, see:
+ps2tek - IOP Interrupts
1F000000h 80000h Expansion Region (default 512 Kbytes, max 8 MBytes)
+ 1F000000h 100h Expansion ROM Header (IDs and Entrypoints)
+ 1F800000h 400h Scratchpad (1K Fast RAM) (Data Cache mapped to fixed address)
+ 1F801000h 4 Expansion 1 Base Address (usually 1F000000h)
+ 1F801004h 4 Expansion 2 Base Address (usually 1F802000h)
+ 1F801008h 4 Expansion 1 Delay/Size (usually 0013243Fh; 512Kbytes 8bit-bus)
+ 1F80100Ch 4 Expansion 3 Delay/Size (usually 00003022h; 1 byte)
+ 1F801010h 4 BIOS ROM Delay/Size (usually 0013243Fh; 512Kbytes 8bit-bus)
+ 1F801014h 4 SPU_DELAY Delay/Size (usually 200931E1h)
+ 1F801018h 4 CDROM_DELAY Delay/Size (usually 00020843h or 00020943h)
+ 1F80101Ch 4 Expansion 2 Delay/Size (usually 00070777h; 128-bytes 8bit-bus)
+ 1F801020h 4 COM_DELAY / COMMON_DELAY (00031125h or 0000132Ch or 00001325h)
+ 1F801040h 1/4 JOY_DATA Joypad/Memory Card Data (R/W)
+ 1F801044h 4 JOY_STAT Joypad/Memory Card Status (R)
+ 1F801048h 2 JOY_MODE Joypad/Memory Card Mode (R/W)
+ 1F80104Ah 2 JOY_CTRL Joypad/Memory Card Control (R/W)
+ 1F80104Eh 2 JOY_BAUD Joypad/Memory Card Baudrate (R/W)
+ 1F801050h 1/4 SIO_DATA Serial Port Data (R/W)
+ 1F801054h 4 SIO_STAT Serial Port Status (R)
+ 1F801058h 2 SIO_MODE Serial Port Mode (R/W)
+ 1F80105Ah 2 SIO_CTRL Serial Port Control (R/W)
+ 1F80105Ch 2 SIO_MISC Serial Port Internal Register (R/W)
+ 1F80105Eh 2 SIO_BAUD Serial Port Baudrate (R/W)
+ 1F801060h 4/2 RAM_SIZE (usually 00000B88h; 2MB RAM mirrored in first 8MB)
+ 1F801070h 2 I_STAT - Interrupt status register
+ 1F801074h 2 I_MASK - Interrupt mask register
+ 1F80108xh DMA0 channel 0 - MDECin
+ 1F80109xh DMA1 channel 1 - MDECout
+ 1F8010Axh DMA2 channel 2 - GPU (lists + image data)
+ 1F8010Bxh DMA3 channel 3 - CDROM
+ 1F8010Cxh DMA4 channel 4 - SPU
+ 1F8010Dxh DMA5 channel 5 - PIO (Expansion Port)
+ 1F8010Exh DMA6 channel 6 - OTC (reverse clear OT) (GPU related)
+ 1F8010F0h DPCR - DMA Control register
+ 1F8010F4h DICR - DMA Interrupt register
+ 1F8010F8h unknown
+ 1F8010FCh unknown
+ 1F80110xh Timer 0 Dotclock
+ 1F80111xh Timer 1 Horizontal Retrace
+ 1F80112xh Timer 2 1/8 system clock
+ 1F801800h.x.x 1 CD Index/Status Register (Bit0-1 R/W, Bit2-7 Read Only)
+ 1F801801h.R.x 1 CD Response Fifo (R) (usually with Index1)
+ 1F801802h.R.x 1/2 CD Data Fifo - 8bit/16bit (R) (usually with Index0..1)
+ 1F801803h.R.0 1 CD Interrupt Enable Register (R)
+ 1F801803h.R.1 1 CD Interrupt Flag Register (R/W)
+ 1F801803h.R.2 1 CD Interrupt Enable Register (R) (Mirror)
+ 1F801803h.R.3 1 CD Interrupt Flag Register (R/W) (Mirror)
+ 1F801801h.W.0 1 CD Command Register (W)
+ 1F801802h.W.0 1 CD Parameter Fifo (W)
+ 1F801803h.W.0 1 CD Request Register (W)
+ 1F801801h.W.1 1 Unknown/unused
+ 1F801802h.W.1 1 CD Interrupt Enable Register (W)
+ 1F801803h.W.1 1 CD Interrupt Flag Register (R/W)
+ 1F801801h.W.2 1 Unknown/unused
+ 1F801802h.W.2 1 CD Audio Volume for Left-CD-Out to Left-SPU-Input (W)
+ 1F801803h.W.2 1 CD Audio Volume for Left-CD-Out to Right-SPU-Input (W)
+ 1F801801h.W.3 1 CD Audio Volume for Right-CD-Out to Right-SPU-Input (W)
+ 1F801802h.W.3 1 CD Audio Volume for Right-CD-Out to Left-SPU-Input (W)
+ 1F801803h.W.3 1 CD Audio Volume Apply Changes (by writing bit5=1)
+ 1F801810h.Write 4 GP0 Send GP0 Commands/Packets (Rendering and VRAM Access)
+ 1F801814h.Write 4 GP1 Send GP1 Commands (Display Control)
+ 1F801810h.Read 4 GPUREAD Read responses to GP0(C0h) and GP1(10h) commands
+ 1F801814h.Read 4 GPUSTAT Read GPU Status Register
+ 1F801820h.Write 4 MDEC Command/Parameter Register (W)
+ 1F801820h.Read 4 MDEC Data/Response Register (R)
+ 1F801824h.Write 4 MDEC Control/Reset Register (W)
+ 1F801824h.Read 4 MDEC Status Register (R)
+ 1F801C00h+N*10h 4 Voice 0..23 Volume Left/Right
+ 1F801C04h+N*10h 2 Voice 0..23 ADPCM Sample Rate
+ 1F801C06h+N*10h 2 Voice 0..23 ADPCM Start Address
+ 1F801C08h+N*10h 4 Voice 0..23 ADSR Attack/Decay/Sustain/Release
+ 1F801C0Ch+N*10h 2 Voice 0..23 ADSR Current Volume
+ 1F801C0Eh+N*10h 2 Voice 0..23 ADPCM Repeat Address
+ 1F801D80h 4 Main Volume Left/Right
+ 1F801D84h 4 Reverb Output Volume Left/Right
+ 1F801D88h 4 Voice 0..23 Key ON (Start Attack/Decay/Sustain) (W)
+ 1F801D8Ch 4 Voice 0..23 Key OFF (Start Release) (W)
+ 1F801D90h 4 Voice 0..23 Channel FM (pitch lfo) mode (R/W)
+ 1F801D94h 4 Voice 0..23 Channel Noise mode (R/W)
+ 1F801D98h 4 Voice 0..23 Channel Reverb mode (R/W)
+ 1F801D9Ch 4 Voice 0..23 Channel ON/OFF (status) (R)
+ 1F801DA0h 2 Unknown? (R) or (W)
+ 1F801DA2h 2 Sound RAM Reverb Work Area Start Address
+ 1F801DA4h 2 Sound RAM IRQ Address
+ 1F801DA6h 2 Sound RAM Data Transfer Address
+ 1F801DA8h 2 Sound RAM Data Transfer Fifo
+ 1F801DAAh 2 SPU Control Register (SPUCNT)
+ 1F801DACh 2 Sound RAM Data Transfer Control
+ 1F801DAEh 2 SPU Status Register (SPUSTAT) (R)
+ 1F801DB0h 4 CD Volume Left/Right
+ 1F801DB4h 4 Extern Volume Left/Right
+ 1F801DB8h 4 Current Main Volume Left/Right
+ 1F801DBCh 4 Unknown? (R/W)
+ 1F801DC0h 2 dAPF1 Reverb APF Offset 1
+ 1F801DC2h 2 dAPF2 Reverb APF Offset 2
+ 1F801DC4h 2 vIIR Reverb Reflection Volume 1
+ 1F801DC6h 2 vCOMB1 Reverb Comb Volume 1
+ 1F801DC8h 2 vCOMB2 Reverb Comb Volume 2
+ 1F801DCAh 2 vCOMB3 Reverb Comb Volume 3
+ 1F801DCCh 2 vCOMB4 Reverb Comb Volume 4
+ 1F801DCEh 2 vWALL Reverb Reflection Volume 2
+ 1F801DD0h 2 vAPF1 Reverb APF Volume 1
+ 1F801DD2h 2 vAPF2 Reverb APF Volume 2
+ 1F801DD4h 4 mSAME Reverb Same Side Reflection Address 1 Left/Right
+ 1F801DD8h 4 mCOMB1 Reverb Comb Address 1 Left/Right
+ 1F801DDCh 4 mCOMB2 Reverb Comb Address 2 Left/Right
+ 1F801DE0h 4 dSAME Reverb Same Side Reflection Address 2 Left/Right
+ 1F801DE4h 4 mDIFF Reverb Different Side Reflection Address 1 Left/Right
+ 1F801DE8h 4 mCOMB3 Reverb Comb Address 3 Left/Right
+ 1F801DECh 4 mCOMB4 Reverb Comb Address 4 Left/Right
+ 1F801DF0h 4 dDIFF Reverb Different Side Reflection Address 2 Left/Right
+ 1F801DF4h 4 mAPF1 Reverb APF Address 1 Left/Right
+ 1F801DF8h 4 mAPF2 Reverb APF Address 2 Left/Right
+ 1F801DFCh 4 vIN Reverb Input Volume Left/Right
+ 1F801E00h+N*04h 4 Voice 0..23 Current Volume Left/Right
+ 1F801E60h 20h Unknown? (R/W)
+ 1F801E80h 180h Unknown? (Read: FFh-filled) (Unused or Write only?)
+ 1F802000h 80h Expansion Region (8bit data bus, crashes on 16bit access?)
+ 1F802020h/1st DUART Mode Register 1.A (R/W)
+ 1F802020h/2nd DUART Mode Register 2.A (R/W)
+ 1F802021h/Read DUART Status Register A (R)
+ 1F802021h/Write DUART Clock Select Register A (W)
+ 1F802022h/Read DUART Toggle Baud Rate Generator Test Mode (Read=Strobe)
+ 1F802022h/Write DUART Command Register A (W)
+ 1F802023h/Read DUART Rx Holding Register A (FIFO) (R)
+ 1F802023h/Write DUART Tx Holding Register A (W)
+ 1F802024h/Read DUART Input Port Change Register (R)
+ 1F802024h/Write DUART Aux. Control Register (W)
+ 1F802025h/Read DUART Interrupt Status Register (R)
+ 1F802025h/Write DUART Interrupt Mask Register (W)
+ 1F802026h/Read DUART Counter/Timer Current Value, Upper/Bit15-8 (R)
+ 1F802026h/Write DUART Counter/Timer Reload Value, Upper/Bit15-8 (W)
+ 1F802027h/Read DUART Counter/Timer Current Value, Lower/Bit7-0 (R)
+ 1F802027h/Write DUART Counter/Timer Reload Value, Lower/Bit7-0 (W)
+ 1F802028h/1st DUART Mode Register 1.B (R/W)
+ 1F802028h/2nd DUART Mode Register 2.B (R/W)
+ 1F802029h/Read DUART Status Register B (R)
+ 1F802029h/Write DUART Clock Select Register B (W)
+ 1F80202Ah/Read DUART Toggle 1X/16X Test Mode (Read=Strobe)
+ 1F80202Ah/Write DUART Command Register B (W)
+ 1F80202Bh/Read DUART Rx Holding Register B (FIFO) (R)
+ 1F80202Bh/Write DUART Tx Holding Register B (W)
+ 1F80202Ch/None DUART Reserved Register (neither R nor W)
+ 1F80202Dh/Read DUART Input Port (R)
+ 1F80202Dh/Write DUART Output Port Configuration Register (W)
+ 1F80202Eh/Read DUART Start Counter Command (Read=Strobe)
+ 1F80202Eh/Write DUART Set Output Port Bits Command (Set means Out=LOW)
+ 1F80202Fh/Read DUART Stop Counter Command (Read=Strobe)
+ 1F80202Fh/Write DUART Reset Output Port Bits Command (Reset means Out=HIGH)
+ 1F802000h 1 DTL-H2000: ATCONS STAT (R)
+ 1F802002h 1 DTL-H2000: ATCONS DATA (R and W)
+ 1F802004h 2 DTL-H2000: Whatever 16bit data ?
+ 1F802030h 1/4 DTL-H2000: Secondary IRQ10 Flags
+ 1F802032h 1 DTL-H2000: Whatever IRQ Control ?
+ 1F802040h 1 DTL-H2000: Bootmode "Dip switches" (R)
+ 1F802041h 1 PSX: POST (external 7 segment display, indicate BIOS boot status)
+ 1F802042h 1 DTL-H2000: POST/LED (similar to POST) (other addr, 2-digit wide)
+ 1F802070h 1 PS2: POST2 (similar to POST, but PS2 BIOS uses this address)
+ 1F802060h Emu-Expansion ID1 "E" (R)
+ 1F802061h Emu-Expansion ID2 "X" (R)
+ 1F802062h Emu-Expansion ID3 "P" (R)
+ 1F802063h Emu-Expansion Version (01h) (R)
+ 1F802064h Emu-Expansion Enable1 "O" (R/W)
+ 1F802065h Emu-Expansion Enable2 "N" (R/W)
+ 1F802066h Emu-Expansion Halt (R)
+ 1F802067h Emu-Expansion Turbo Mode Flags (R/W)
+ 1F802080h 4 Redux-Expansion ID "PCSX" (R)
+ 1F802080h 1 Redux-Expansion Console putchar (W)
+ 1F802081h 1 Redux-Expansion Debug break (W)
+ 1F802082h 1 Redux-Expansion Exit code (W)
+ 1F802084h 4 Redux-Expansion Notification message pointer (W)
+ 1FA00000h - Not used by BIOS or any PSX games
+ 1FA00000h - POST3 (similar to POST, but PS2 BIOS uses this address)
+ 1FC00000h 80000h BIOS ROM (512Kbytes) (Reset Entrypoint at BFC00000h)
+ FFFE0130h 4 Cache Control
+ COP0 System Control Coprocessor - 32 registers (not all used)
+ COP1 N/A
+ COP2 Geometry Transformation Engine (GTE) - 64 registers (most are used)
+ COP3 N/A
+BIOS Overview
+BIOS Memory Map
+BIOS Function Summary
+BIOS File Functions
+BIOS File Execute and Flush Cache
+BIOS CDROM Functions
+BIOS Memory Card Functions
+BIOS Interrupt/Exception Handling
+BIOS Event Functions
+BIOS Event Summary
+BIOS Thread Functions
+BIOS Timer Functions
+BIOS Joypad Functions
+BIOS GPU Functions
+BIOS Memory Allocation
+BIOS Memory Fill/Copy/Compare (SLOW)
+BIOS String Functions
+BIOS Number/String/Character Conversion
+BIOS Misc Functions
+BIOS Internal Boot Functions
+BIOS More Internal Functions
+BIOS PC File Server
+BIOS TTY Console (std_io)
+BIOS Character Sets
+BIOS Control Blocks
+BIOS Versions
+BIOS Patches
The main purpose of the BIOS is to boot games from CDROM, unfortunately, before
+doing that, it displays the Sony intro. It's also doing some copy protection
+and region checks, and refuses to boot unlicensed games, or illegal copies, or
+games for other regions.
The bootmenu shows up when starting the Playstation without CDROM inserted. The
+menu allows to play Audio CDs, and to erase or copy game positions on Memory
+Cards.
The BIOS contains a number of more or less useful, and probably more or less
+inefficient functions that can be used by software.
+No idea if it's easy to take full control of the CPU, ie. to do all hardware
+access and interrupt handling by software, without using the BIOS at all?
+Eventually the BIOS functions for accessing the CDROM drive are important, not
+sure how complicated/compatible it'd be to access the CDROM drive directly via
+I/O ports... among others, there might be different drives used in different
+versions of the Playstation, which aren't fully compatible with each other?
The BIOS occupies 512Kbyte ROM with 8bit address bus (so the BIOS ROM is rather
+slow, for faster execution, portions of it are relocated to the first 64K of
+RAM). For some very strange reason, the original PSX BIOS executes all ROM
+functions in uncached ROM, which is incredible slow (nocash BIOS uses cached
+ROM, which does work without problems).
+The first 64Kbyte of the 2Mbyte Main RAM are reserved for the BIOS (containing
+exception handlers, jump tables, other data, and relocated code). That reserved
+region does unfortunately include the "valuable" first 32Kbytes (valuable
+because that memory could be accessed directly via [R0+immediate], without
+needing to use R1..R31 as base register).
BFC00000h Kernel Part 1 (code/data executed in uncached ROM)
+ BFC10000h Kernel Part 2 (code/data relocated to cached RAM)
+ BFC18000h Intro/Bootmenu (code/data decompressed and relocated to RAM)
+ BFC64000h Character Sets
+ BFC00100h Kernel BCD date (YYYYMMDDh)
+ BFC00104h Console Type (see Port 1F802030h, Secondary IRQ10 Controller)
+ BFC00108h Kernel Maker/Version Strings (separated by one or more 00h bytes)
+ BFC7FF32h GUI Version/Copyright Strings (if any) (separated by one 00h byte)
+ 00000000h 10h Garbage Area (see notes below)
+ 00000010h 30h Unused/reserved
+ 00000040h 20h COP0 debug-break vector (not used by Kernel) (in KSEG0)
+ 00000060h 4 RAM Size (in megabytes) (2 or 8)
+ 00000064h 4 Unknown (set to 00000000h)
+ 00000068h 4 Unknown (set to 000000FFh)
+ 0000006Ch 14h Unused/reserved
+ 00000080h 10h Exception vector (actually in KSEG0, ie. at 80000080h)
+ 00000090h 10h Unused/reserved
+ 000000A0h 10h A(nnh) Function Vector
+ 000000B0h 10h B(nnh) Function Vector
+ 000000C0h 10h C(nnh) Function Vector
+ 000000D0h 30h Unused/reserved
+ 00000100h 58h Table of Tables (BIOS Control Blocks) (see below)
+ 00000158h 28h Unused/reserved
+ 00000180h 80h Command line argument from SYSTEM.CNF; BOOT = fname argument
+ 00000200h 300h A(nnh) Jump Table
+ 00000500h ... Kernel Code/Data (relocated from ROM)
+ 0000Cxxxh ... Unused/reserved
+ 0000DF80h 80h Used for BIOS Patches (ie. used by games, not used by BIOS)
+ 0000DFFCh 4 Response value from Intro/Bootmenu
+ 0000E000h 2000h Kernel Memory; ExCBs, EvCBs, and TCBs allocated via B(00h)
+ 00010000h ... Begin of User RAM (Exefile, Data, Heap, Stack, etc.)
+ 001FFF00h ... Default Stacktop (usually in KSEG0)
+ 1F800000h 400h Scratchpad (Data-Cache mis-used as Fast RAM)
+Each table entry consists of two 32bit values; containing the base address, and
+total size (in bytes) of the corresponding control blocks.
+
00000100h ExCB Exception Chain Entrypoints (addr=var, size=4*08h)
+ 00000108h PCB Process Control Block (addr=var, size=1*04h)
+ 00000110h TCB Thread Control Blocks (addr=var, size=N*C0h)
+ 00000118h - Unused/reserved
+ 00000120h EvCB Event Control Blocks (addr=var, size=N*1Ch)
+ 00000128h - Unused/reserved
+ 00000130h - Unused/reserved
+ 00000138h - Unused/reserved
+ 00000140h FCB File Control Blocks (addr=fixed, size=10h*2Ch)
+ 00000148h - Unused/reserved
+ 00000150h DCB Device Control Blocks (addr=fixed, size=0Ah*50h)
+The first some bytes of memory address 00000000h aren't actually used by the
+Kernel, except for storing some garbage at that locations. However, this
+garbage is actually important for bugged games like R-Types and Fade to Black
+(ie. games that do read from address 00000000h due to using uninitialized
+pointers).
+Initially, the garbage area is containing a copy of the 16-byte exception
+handler at address 80h, but the first 4-bytes are typically smashed (set to
+00000003h from some useless dummy writes in some useless CDROM delays). Ie. the
+16-bytes should have these values:
+
[00000000h]=3C1A0000h ;<-- but overwritten by 00000003h after soon
+ [00000004h]=275A0C80h ;<-- or 275A0C50h (in older BIOS)
+ [00000008h]=03400008h
+ [0000000Ch]=00000000h
+Argument(s) are passed in R4,R5,R6,R7,[SP+10h],[SP+14h],etc.
+Caution: When calling a sub-function with N parameters, the caller MUST always
+allocate N words on the stack, and, although the first four parameters are
+passed in registers rather than on stack, the sub-function is allowed to
+use/destroy these words at [SP+0..N*4-1].
+BIOS Functions (and custom callback functions) are allowed to destroy registers
+R1-R15, R24-R25, R31 (RA), and HI/LO. Registers R16-R23, R29 (SP), and R30 (FP)
+must be left unchanged (if the function uses that registers, then it must
+push/pop them). R26 (K0) is reserved for exception handler and should be
+usually not used by other functions. R27 (K1) and R28 (GP) are left more or
+less unused by the BIOS, so one can more or less freely use them for whatever
+purpose.
+The return value (if any) is stored in R2 register.
A(00h) or B(32h) open(filename,accessmode)
+ A(01h) or B(33h) lseek(fd,offset,seektype)
+ A(02h) or B(34h) read(fd,dst,length)
+ A(03h) or B(35h) write(fd,src,length)
+ A(04h) or B(36h) close(fd)
+ A(05h) or B(37h) ioctl(fd,cmd,arg)
+ A(06h) or B(38h) exit(exitcode)
+ A(07h) or B(39h) isatty(fd)
+ A(08h) or B(3Ah) getc(fd)
+ A(09h) or B(3Bh) putc(char,fd)
+ A(0Ah) todigit(char)
+ A(0Bh) atof(src) ;Does NOT work - uses (ABSENT) cop1 !!!
+ A(0Ch) strtoul(src,src_end,base)
+ A(0Dh) strtol(src,src_end,base)
+ A(0Eh) abs(val)
+ A(0Fh) labs(val)
+ A(10h) atoi(src)
+ A(11h) atol(src)
+ A(12h) atob(src,num_dst)
+ A(13h) setjmp(buf)
+ A(14h) longjmp(buf,param)
+ A(15h) strcat(dst,src)
+ A(16h) strncat(dst,src,maxlen)
+ A(17h) strcmp(str1,str2)
+ A(18h) strncmp(str1,str2,maxlen)
+ A(19h) strcpy(dst,src)
+ A(1Ah) strncpy(dst,src,maxlen)
+ A(1Bh) strlen(src)
+ A(1Ch) index(src,char)
+ A(1Dh) rindex(src,char)
+ A(1Eh) strchr(src,char) ;exactly the same as "index"
+ A(1Fh) strrchr(src,char) ;exactly the same as "rindex"
+ A(20h) strpbrk(src,list)
+ A(21h) strspn(src,list)
+ A(22h) strcspn(src,list)
+ A(23h) strtok(src,list) ;use strtok(0,list) in further calls
+ A(24h) strstr(str,substr) ;Bugged
+ A(25h) toupper(char)
+ A(26h) tolower(char)
+ A(27h) bcopy(src,dst,len)
+ A(28h) bzero(dst,len)
+ A(29h) bcmp(ptr1,ptr2,len) ;Bugged
+ A(2Ah) memcpy(dst,src,len)
+ A(2Bh) memset(dst,fillbyte,len)
+ A(2Ch) memmove(dst,src,len) ;Bugged
+ A(2Dh) memcmp(src1,src2,len) ;Bugged
+ A(2Eh) memchr(src,scanbyte,len)
+ A(2Fh) rand()
+ A(30h) srand(seed)
+ A(31h) qsort(base,nel,width,callback)
+ A(32h) strtod(src,src_end) ;Does NOT work - uses (ABSENT) cop1 !!!
+ A(33h) malloc(size)
+ A(34h) free(buf)
+ A(35h) lsearch(key,base,nel,width,callback)
+ A(36h) bsearch(key,base,nel,width,callback)
+ A(37h) calloc(sizx,sizy) ;SLOW!
+ A(38h) realloc(old_buf,new_siz) ;SLOW!
+ A(39h) InitHeap(addr,size)
+ A(3Ah) _exit(exitcode)
+ A(3Bh) or B(3Ch) getchar()
+ A(3Ch) or B(3Dh) putchar(char)
+ A(3Dh) or B(3Eh) gets(dst)
+ A(3Eh) or B(3Fh) puts(src)
+ A(3Fh) printf(txt,param1,param2,etc.)
+ A(40h) SystemErrorUnresolvedException()
+ A(41h) LoadTest(filename,headerbuf)
+ A(42h) Load(filename,headerbuf)
+ A(43h) Exec(headerbuf,param1,param2)
+ A(44h) FlushCache()
+ A(45h) init_a0_b0_c0_vectors
+ A(46h) GPU_dw(Xdst,Ydst,Xsiz,Ysiz,src)
+ A(47h) gpu_send_dma(Xdst,Ydst,Xsiz,Ysiz,src)
+ A(48h) SendGP1Command(gp1cmd)
+ A(49h) GPU_cw(gp0cmd) ;send GP0 command word
+ A(4Ah) GPU_cwp(src,num) ;send GP0 command word and parameter words
+ A(4Bh) send_gpu_linked_list(src)
+ A(4Ch) gpu_abort_dma()
+ A(4Dh) GetGPUStatus()
+ A(4Eh) gpu_sync()
+ A(4Fh) SystemError
+ A(50h) SystemError
+ A(51h) LoadExec(filename,stackbase,stackoffset)
+ A(52h) GetSysSp
+ A(53h) SystemError ;PS2: set_ioabort_handler(src)
+ A(54h) or A(71h) _96_init()
+ A(55h) or A(70h) _bu_init()
+ A(56h) or A(72h) _96_remove() ;does NOT work due to SysDeqIntRP bug
+ A(57h) return 0
+ A(58h) return 0
+ A(59h) return 0
+ A(5Ah) return 0
+ A(5Bh) dev_tty_init() ;PS2: SystemError
+ A(5Ch) dev_tty_open(fcb,and unused:"path\name",accessmode) ;PS2: SystemError
+ A(5Dh) dev_tty_in_out(fcb,cmd) ;PS2: SystemError
+ A(5Eh) dev_tty_ioctl(fcb,cmd,arg) ;PS2: SystemError
+ A(5Fh) dev_cd_open(fcb,"path\name",accessmode)
+ A(60h) dev_cd_read(fcb,dst,len)
+ A(61h) dev_cd_close(fcb)
+ A(62h) dev_cd_firstfile(fcb,"path\name",direntry)
+ A(63h) dev_cd_nextfile(fcb,direntry)
+ A(64h) dev_cd_chdir(fcb,"path")
+ A(65h) dev_card_open(fcb,"path\name",accessmode)
+ A(66h) dev_card_read(fcb,dst,len)
+ A(67h) dev_card_write(fcb,src,len)
+ A(68h) dev_card_close(fcb)
+ A(69h) dev_card_firstfile(fcb,"path\name",direntry)
+ A(6Ah) dev_card_nextfile(fcb,direntry)
+ A(6Bh) dev_card_erase(fcb,"path\name")
+ A(6Ch) dev_card_undelete(fcb,"path\name")
+ A(6Dh) dev_card_format(fcb)
+ A(6Eh) dev_card_rename(fcb1,"path\name1",fcb2,"path\name2")
+ A(6Fh) ? ;card ;[r4+18h]=00000000h ;card_clear_error(fcb) or so
+ A(70h) or A(55h) _bu_init()
+ A(71h) or A(54h) _96_init()
+ A(72h) or A(56h) _96_remove() ;does NOT work due to SysDeqIntRP bug
+ A(73h) return 0
+ A(74h) return 0
+ A(75h) return 0
+ A(76h) return 0
+ A(77h) return 0
+ A(78h) CdAsyncSeekL(src)
+ A(79h) return 0 ;DTL-H: Unknown?
+ A(7Ah) return 0 ;DTL-H: Unknown?
+ A(7Bh) return 0 ;DTL-H: Unknown?
+ A(7Ch) CdAsyncGetStatus(dst)
+ A(7Dh) return 0 ;DTL-H: Unknown?
+ A(7Eh) CdAsyncReadSector(count,dst,mode)
+ A(7Fh) return 0 ;DTL-H: Unknown?
+ A(80h) return 0 ;DTL-H: Unknown?
+ A(81h) CdAsyncSetMode(mode)
+ A(82h) return 0 ;DTL-H: Unknown?
+ A(83h) return 0 ;DTL-H: Unknown?
+ A(84h) return 0 ;DTL-H: Unknown?
+ A(85h) return 0 ;DTL-H: Unknown?, or reportedly, CdStop (?)
+ A(86h) return 0 ;DTL-H: Unknown?
+ A(87h) return 0 ;DTL-H: Unknown?
+ A(88h) return 0 ;DTL-H: Unknown?
+ A(89h) return 0 ;DTL-H: Unknown?
+ A(8Ah) return 0 ;DTL-H: Unknown?
+ A(8Bh) return 0 ;DTL-H: Unknown?
+ A(8Ch) return 0 ;DTL-H: Unknown?
+ A(8Dh) return 0 ;DTL-H: Unknown?
+ A(8Eh) return 0 ;DTL-H: Unknown?
+ A(8Fh) return 0 ;DTL-H: Unknown?
+ A(90h) CdromIoIrqFunc1()
+ A(91h) CdromDmaIrqFunc1()
+ A(92h) CdromIoIrqFunc2()
+ A(93h) CdromDmaIrqFunc2()
+ A(94h) CdromGetInt5errCode(dst1,dst2)
+ A(95h) CdInitSubFunc()
+ A(96h) AddCDROMDevice()
+ A(97h) AddMemCardDevice() ;DTL-H: SystemError
+ A(98h) AddDuartTtyDevice() ;DTL-H: AddAdconsTtyDevice ;PS2: SystemError
+ A(99h) add_nullcon_driver()
+ A(9Ah) SystemError ;DTL-H: AddMessageWindowDevice
+ A(9Bh) SystemError ;DTL-H: AddCdromSimDevice
+ A(9Ch) SetConf(num_EvCB,num_TCB,stacktop)
+ A(9Dh) GetConf(num_EvCB_dst,num_TCB_dst,stacktop_dst)
+ A(9Eh) SetCdromIrqAutoAbort(type,flag)
+ A(9Fh) SetMem(megabytes)
+ A(A0h) _boot()
+ A(A1h) SystemError(type,errorcode)
+ A(A2h) EnqueueCdIntr() ;with prio=0 (fixed)
+ A(A3h) DequeueCdIntr() ;does NOT work due to SysDeqIntRP bug
+ A(A4h) CdGetLbn(filename) ;get 1st sector number (or garbage when not found)
+ A(A5h) CdReadSector(count,sector,buffer)
+ A(A6h) CdGetStatus()
+ A(A7h) bufs_cb_0()
+ A(A8h) bufs_cb_1()
+ A(A9h) bufs_cb_2()
+ A(AAh) bufs_cb_3()
+ A(ABh) _card_info(port)
+ A(ACh) _card_load(port)
+ A(ADh) _card_auto(flag)
+ A(AEh) bufs_cb_4()
+ A(AFh) card_write_test(port) ;CEX-1000: jump_to_00000000h
+ A(B0h) return 0 ;CEX-1000: jump_to_00000000h
+ A(B1h) return 0 ;CEX-1000: jump_to_00000000h
+ A(B2h) ioabort_raw(param) ;CEX-1000: jump_to_00000000h
+ A(B3h) return 0 ;CEX-1000: jump_to_00000000h
+ A(B4h) GetSystemInfo(index) ;CEX-1000: jump_to_00000000h
+ A(B5h..BFh) N/A ;jump_to_00000000h
+ B(00h) alloc_kernel_memory(size)
+ B(01h) free_kernel_memory(buf)
+ B(02h) init_timer(t,reload,flags)
+ B(03h) get_timer(t)
+ B(04h) enable_timer_irq(t)
+ B(05h) disable_timer_irq(t)
+ B(06h) restart_timer(t)
+ B(07h) DeliverEvent(class, spec)
+ B(08h) OpenEvent(class,spec,mode,func)
+ B(09h) CloseEvent(event)
+ B(0Ah) WaitEvent(event)
+ B(0Bh) TestEvent(event)
+ B(0Ch) EnableEvent(event)
+ B(0Dh) DisableEvent(event)
+ B(0Eh) OpenTh(reg_PC,reg_SP_FP,reg_GP)
+ B(0Fh) CloseTh(handle)
+ B(10h) ChangeTh(handle)
+ B(11h) jump_to_00000000h
+ B(12h) InitPAD2(buf1,siz1,buf2,siz2)
+ B(13h) StartPAD2()
+ B(14h) StopPAD2()
+ B(15h) PAD_init2(type,button_dest,unused,unused)
+ B(16h) PAD_dr()
+ B(17h) ReturnFromException()
+ B(18h) ResetEntryInt()
+ B(19h) HookEntryInt(addr)
+ B(1Ah) SystemError ;PS2: return 0
+ B(1Bh) SystemError ;PS2: return 0
+ B(1Ch) SystemError ;PS2: return 0
+ B(1Dh) SystemError ;PS2: return 0
+ B(1Eh) SystemError ;PS2: return 0
+ B(1Fh) SystemError ;PS2: return 0
+ B(20h) UnDeliverEvent(class,spec)
+ B(21h) SystemError ;PS2: return 0
+ B(22h) SystemError ;PS2: return 0
+ B(23h) SystemError ;PS2: return 0
+ B(24h) jump_to_00000000h
+ B(25h) jump_to_00000000h
+ B(26h) jump_to_00000000h
+ B(27h) jump_to_00000000h
+ B(28h) jump_to_00000000h
+ B(29h) jump_to_00000000h
+ B(2Ah) SystemError ;PS2: return 0
+ B(2Bh) SystemError ;PS2: return 0
+ B(2Ch) jump_to_00000000h
+ B(2Dh) jump_to_00000000h
+ B(2Eh) jump_to_00000000h
+ B(2Fh) jump_to_00000000h
+ B(30h) jump_to_00000000h
+ B(31h) jump_to_00000000h
+ B(32h) or A(00h) open(filename,accessmode)
+ B(33h) or A(01h) lseek(fd,offset,seektype)
+ B(34h) or A(02h) read(fd,dst,length)
+ B(35h) or A(03h) write(fd,src,length)
+ B(36h) or A(04h) close(fd)
+ B(37h) or A(05h) ioctl(fd,cmd,arg)
+ B(38h) or A(06h) exit(exitcode)
+ B(39h) or A(07h) isatty(fd)
+ B(3Ah) or A(08h) getc(fd)
+ B(3Bh) or A(09h) putc(char,fd)
+ B(3Ch) or A(3Bh) getchar()
+ B(3Dh) or A(3Ch) putchar(char)
+ B(3Eh) or A(3Dh) gets(dst)
+ B(3Fh) or A(3Eh) puts(src)
+ B(40h) cd(name)
+ B(41h) format(devicename)
+ B(42h) firstfile2(filename,direntry)
+ B(43h) nextfile(direntry)
+ B(44h) rename(old_filename,new_filename)
+ B(45h) erase(filename)
+ B(46h) undelete(filename)
+ B(47h) AddDrv(device_info) ;subfunction for AddXxxDevice functions
+ B(48h) DelDrv(device_name_lowercase)
+ B(49h) PrintInstalledDevices()
+ B(4Ah) InitCARD2(pad_enable) ;uses/destroys k0/k1 !!!
+ B(4Bh) StartCARD2()
+ B(4Ch) StopCARD2()
+ B(4Dh) _card_info_subfunc(port) ;subfunction for "_card_info"
+ B(4Eh) _card_write(port,sector,src)
+ B(4Fh) _card_read(port,sector,dst)
+ B(50h) _new_card()
+ B(51h) Krom2RawAdd(shiftjis_code)
+ B(52h) SystemError ;PS2: return 0
+ B(53h) Krom2Offset(shiftjis_code)
+ B(54h) _get_errno()
+ B(55h) _get_error(fd)
+ B(56h) GetC0Table
+ B(57h) GetB0Table
+ B(58h) _card_chan()
+ B(59h) testdevice(devicename)
+ B(5Ah) SystemError ;PS2: return 0
+ B(5Bh) ChangeClearPAD(int)
+ B(5Ch) _card_status(slot)
+ B(5Dh) _card_wait(slot)
+ B(5Eh..FFh) N/A ;jump_to_00000000h ;CEX-1000: B(5Eh..F6h) only
+ B(100h....) N/A ;garbage ;CEX-1000: B(F7h.....) and up
+ C(00h) EnqueueTimerAndVblankIrqs(priority) ;used with prio=1
+ C(01h) EnqueueSyscallHandler(priority) ;used with prio=0
+ C(02h) SysEnqIntRP(priority,struc) ;bugged, use with care
+ C(03h) SysDeqIntRP(priority,struc) ;bugged, use with care
+ C(04h) get_free_EvCB_slot()
+ C(05h) get_free_TCB_slot()
+ C(06h) ExceptionHandler()
+ C(07h) InstallExceptionHandlers() ;destroys/uses k0/k1
+ C(08h) SysInitMemory(addr,size)
+ C(09h) SysInitKernelVariables()
+ C(0Ah) ChangeClearRCnt(t,flag)
+ C(0Bh) SystemError ;PS2: return 0
+ C(0Ch) InitDefInt(priority) ;used with prio=3
+ C(0Dh) SetIrqAutoAck(irq,flag)
+ C(0Eh) return 0 ;DTL-H2000: dev_sio_init
+ C(0Fh) return 0 ;DTL-H2000: dev_sio_open
+ C(10h) return 0 ;DTL-H2000: dev_sio_in_out
+ C(11h) return 0 ;DTL-H2000: dev_sio_ioctl
+ C(12h) InstallDevices(ttyflag)
+ C(13h) FlushStdInOutPut()
+ C(14h) return 0 ;DTL-H2000: SystemError
+ C(15h) _cdevinput(circ,char)
+ C(16h) _cdevscan()
+ C(17h) _circgetc(circ) ;uses r5 as garbage txt for _ioabort
+ C(18h) _circputc(char,circ)
+ C(19h) _ioabort(txt1,txt2)
+ C(1Ah) set_card_find_mode(mode) ;0=normal, 1=find deleted files
+ C(1Bh) KernelRedirect(ttyflag) ;PS2: ttyflag=1 causes SystemError
+ C(1Ch) AdjustA0Table()
+ C(1Dh) get_card_find_mode()
+ C(1Eh..7Fh) N/A ;jump_to_00000000h
+ C(80h.....) N/A ;mirrors to B(00h.....)
+ SYS(00h) NoFunction()
+ SYS(01h) EnterCriticalSection()
+ SYS(02h) ExitCriticalSection()
+ SYS(03h) ChangeThreadSubFunction(addr) ;syscall with r4=03h, r5=addr
+ SYS(04h..FFFFFFFFh) calls DeliverEvent(F0000010h,4000h)
+BRK opcodes may be used within devkits, however, the standard BIOS simply calls
+DeliverEvent(F0000010h,1000h) and SystemError_A_40h upon any BRK opcodes (as
+well as on any other unresolved exceptions).
+
BRK(1C00h) Division by zero (commonly checked/invoked by software)
+ BRK(1800h) Division overflow (-80000000h/-1, sometimes checked by software)
+ BRK(1h) Whatever lockup or so?
+ BRK(101h) PCInit() Inits the fileserver.
+ BRK(102h) PCCreat(filename, fileattributes)
+ BRK(103h) PCOpen(filename, accessmode)
+ BRK(104h) PCClose(filehandle)
+ BRK(105h) PCRead(filehandle, length, memory_destination_address)
+ BRK(106h) PCWrite(filehandle, length, memory_source_address)
+ BRK(107h) PClSeek(filehandle, file_offset, seekmode)
+ BRK(3C400h) User has typed "break" command in debug console
+ out: V0 File handle (00h..0Fh), or -1 if error.
+ bit0 1=Read ;\These bits aren't actually used by the BIOS, however, at
+ bit1 1=Write ;/least 1 should be set; won't work when all 32bits are zero
+ bit2 1=Exit without waiting for incoming data (when TTY buffer empty)
+ bit9 0=Open Existing File, 1=Create New file (memory card only)
+ bit15 1=Asynchronous mode (memory card only; don't wait for completion)
+ bit16-31 Number of memory card blocks for a new file on the memory card
+ seektype 0 = from start of file (with positive offset)
+ 1 = from current file pointer (with positive/negative offset)
+ 2 = Bugs. Should be from end of file.
+ out: V0 Number of bytes actually read, -1 if failed.
+ out: V0 Number of bytes written.
+Returns r2=fd (or r2=-1 if failed).
out: R2=character (sign-expanded) or FFFFFFFFh=error
+Observe that "fd" is the 2nd paramter (not the 1st paramter as usually).
+
out: R2=Number of bytes actually written, -1 if failed
+Changes the current directory on the specified device, which should be "cdrom:"
+(memory cards don't support directories). The PSX supports only a current
+directory, but NOT a current device (ie. after cd, the directory name may be
+ommited from filenames, but the device name must be still included in all
+filenames).
+
in: A0 Pointer to new directory path (eg. "cdrom:\path")
+Returns r2=direntry (or r2=0 if no matching files).
+Searches for the first file to match the specified filename; the filename may
+contain "?" and "*" wildcards. "*" means to ignore ALL following characters;
+accordingly one cannot specify any further characters after the "*" (eg.
+"DATA*" would work, but "*.DAT" won't work). "?" is meant to ignore a single
+character cell. Note: The "?" wildcards (but not "*") can be used also in all
+other file functions; causing the function to use the first matching name (eg.
+erase "????" would erase the first matching file, not all matching files).
+Start the name with the device you want to address. (ie. pcdrv:) Different
+drives can be accessed as normally by their drive names (a:, c:, huh?) if path
+is omitted after the device, the current directory will be used.
+A direntry structure looks like this:
+
00h 14h Filename, terminated with 00h
+ 14h 4 File attribute (always 0 for cdrom) (50h=norm or A0h=del for card)
+ 18h 4 File size
+ 1Ch 4 Pointer to next direntry? (not used?)
+ 20h 4 First Sector Number
+ 24h 4 Reserved (not used)
+Returns r2=direntry (or r2=0 if no more matching files).
+Uses the settings of a previous firstfile2/nextfile command.
Returns 1=okay, or 0=failed.
Returns 1=okay, or 0=failed.
Returns 1=okay, or 0=failed.
Erases all files on the device (ie. for formatting memory cards).
+Returns 1=okay, or 0=failed.
Indicates the reason of the most recent file function error (open,
+lseek, read, write, close, _get_error, ioctl, cd,
+testdevice, erase, undelete, format, rename). Use
+_get_errno() ONLY if an error has occured (the error code isn't reset to zero
+by functions that are passing okay). firstfile2/nextfile do NOT affect
+_get_errno(). See below list of File Error Numbers for more info.
Basically same as B(54h), but allowing to specify a file handle for which error
+information is to be received; accordingly it doesn't work for functions that
+do use 'hidden' internal file handles (eg. erase, or unsuccessful
+open). Returns FCB[18h], or FFFFFFFFh if the handle is invalid/unused.
Used only for TTY.
Returns bit1 of the file's DCB flags. That bit is set only for Duart/TTY, and
+is cleared for Dummy/TTY, Memory Card, and CDROM.
Whatever. Checks the devicename, and if it's accepted, calls a device specific
+function. For the existing devices (cdrom,bu,tty) that specific function simply
+returns without doing anything. Maybe other devices (like printers or modems)
+would do something more interesting.
00h okay (though many successful functions leave old error code unchanged)
+ 02h file not found
+ 06h bad device port number (tty2 and up)
+ 09h invalid or unused file handle
+ 10h general error (physical I/O error, unformatted, disk changed for old fcb)
+ 11h file already exists error (create/undelete/rename)
+ 12h tried to rename a file from one device to another device
+ 13h unknown device name
+ 16h sector alignment error, or fpos>=filesize, unknown seektype or ioctl cmd
+ 18h not enough free file handles
+ 1Ch not enough free memory card blocks
+ FFFFFFFFh invalid or unused file handle passed to B(55h) function
+Loads the 800h-byte exe file header to an internal sector buffer, and does then
+copy bytes [10h..4Bh] of that header to headerbuf[00h..3Bh].
Same as LoadTest (see there for details), but additionally loads the body
+of the executable (using the size and destination address in the file header),
+and does call FlushCache. The exe can be then started via Exec (this isn't
+done automatically by LoadTest). Unlike "LoadExec", the
+"LoadTest/Exec" combination allows to return the new exe file to return
+to the old exe file (instead of restarting the boot executable).
+BUG: Uses the unstable FlushCache function (see there for details).
Can be used to start a previously loaded executable. The function saves
+R16,R28,R30,SP,RA in the reserved region of headerbuf (rather than on stack),
+more or less slowly zerofills the memfill region specified in headerbuf, reads
+the stack base and offset values and sets SP and FP to base+offset (or leaves
+them unchanged if base=0), reads the GP value from headerbuf and sets GP to
+that value. Then calls the excecutables entrypoint, with param1 and param2
+passed in r4,r5.
+If the executable (should) return, then R16,R28,R30,SP,RA are restored from
+headerbuf, and the function returns with r2=1.
This is a rather bizarre function. In short, it does load and execute the
+specified file, and thereafter, it (tries to) reload and restart to boot
+executable.
+Part1: Takes a copy of the filename, with some adjustments: Everything up to
+the first ":" or 00h byte is copied as is (ie. the device name, if it does
+exist, or otherwise the whole path\filename.ext;ver), the remaining characters
+are copied and converted to uppercase (ie. the path\filename.ext;ver part, or
+none if the device name didn't exist), finally, checks if a ";" exists (ie. the
+version suffix), if there's none, then it appends ";1" as default version.
+CAUTION: The BIOS allocates ONLY 28 bytes on stack for the copy of the
+filename, that region is followed by 4 unused bytes, so the maximum length
+would be 32 bytes (31 characters plus EOL) (eg.
+"device:\pathname\filename.ext;1",00h).
+Part2: Enables IRQs via ExitCriticalSection, memorizes the stack base/offset
+values from the previously loaded executable (which should have been the boot
+executable, unless LoadExec should have been used in nested fashion),
+does then use LoadTest to load the desired file, replaces the stack
+base/offset values in its headerbuf by the LoadExec parameter values, and
+does then execute it via Exec(headerbuf,1,0).
+Part3: If the exefile returns, or if it couldn't be loaded, then the boot file
+is (unsuccessfully) attempted to be reloaded: Enables IRQs via
+ExitCriticalSection, loads the boot file via LoadTest, replaces the stack
+base/offset values in its headerbuf by the values memorized in Part2 (which
+\<should> be the boot executable's values from SYSTEM.CNF, unless the
+nesting stuff occurred), and does then execute the boot file via
+Exec(headerbuf,1,0).
+Part4: If the boot file returns, or if it couldn't be loaded, then the function
+looks up in a "JMP $" endless loop (normally, returning from the boot exe
+causes SystemError("B",38Ch), however, after using
+LoadExec, this functionality is replaced by the "JMP $" lockup.
+BUG: Uses the unstable FlushCache function (see there for details).
+BUG: Part3 accidently treats the first 4 characters of the exename as memory
+address (causing an invalid memory address exception on address 6F726463h, for
+"cdrom:filename.exe").
Changes the number of EvCBs and TCBs, and the stacktop. These values are usually
+initialized from the settings in the SYSTEM.CNF file, so using this function
+usually shouldn't ever be required.
+The function deallocates all old ExCBs, EvCBs, TCBs (so all Exception handlers,
+Events, and Threads (except the current one) are lost, and all other memory
+that may have been allocated via alloc_kernel_memory(size) is deallocated, too.
+It does then allocate the new control blocks, and enqueue the default handlers.
+Despite of the changed stacktop, the current stack pointer is kept intact, and
+the function returns to the caller.
Returns the number of EvCBs, TCBs, and the initial stacktop. There's no return
+value in the R2 register, instead, the three 32bit return values are stored at
+the specified "dst" addresses.
Flushes the Code Cache, so opcodes are ensured to be loaded from RAM. This is
+required when loading program code via DMA (ie. from CDROM) (the cache
+controller apparently doesn't realize changes to RAM that are caused by DMA).
+The LoadTest and LoadExec functions are automatically calling
+FlushCache (so FlushCache is required only when loading program code via
+"read" or via "CdReadSector").
+FlushCache may be also required when relocating or modifying program code by
+software (the cache controller doesn't seem to realize modifications to memory
+mirrors, eg. patching the exception handler at 80000080h seems to be work
+without FlushCache, but patching the same bytes at 00000080h doesn't).
+Note: The PSX doesn't have a Data Cache (or actually, it has, but it's misused
+as Fast RAM, mapped to a fixed memory region, and which isn't accessable by
+DMA), so FlushCache isn't required for regions that contain data.
+BUG: The FlushCache function contains a handful of opcodes that do use the k0
+register without having IRQs disabled at that time, if an IRQ occurs during
+those opcodes, then the k0 value gets destroyed by the exception handler,
+causing FlushCache to get trapped in an endless loop.
+One workaround would be to disable all IRQs before calling FlushCache, however,
+the BIOS does internally call the function without IRQs disabled, that applies
+to:
+
load_file A(42h)
+ load_exec A(51h)
+ add_device B(47h) (and all "add_xxx_device" functions)
+ init_card B(4Ah)
+ and by intro/boot code
+LoadTest and LoadExec are simply loading the file to the address
+specified in the exe file header. There's absolutely no verification whether
+that memory is (or isn't) allocated via malloc, or if it is used by the boot
+executable, or by the kernel, or if it does contain RAM at all.
+When using the "malloc" function combined with loading exe files, it may be
+recommended not to pass all memory to InitHeap (ie. to keep a memory region
+being reserved for loading executables).
For more info about EXE files and their headers, see
+CDROM File Formats
CDROMs are basically accessed via normal file functions, with device name
+"cdrom:" (which is an abbreviation for "cdrom0:", anyways, the port number is
+ignored).
+BIOS File Functions
+BIOS File Execute and Flush Cache
+Before starting the boot executable, the BIOS automatically calls _96_init(), so
+the game doesn't need to do any initializations before using CDROM file
+functions.
The Kernel doesn't include any functions for playing Audio tracks. Also,
+there's no BIOS function for setting the XA-ADPCM file/channel filter values.
+So CD Audio can be used only by directly programming the CDROM I/O ports.
The normal File functions are always using synchroneous access for CDROM (ie.
+the functions do wait until all data is transferred) (unlike as for memory
+cards, accessmode.bit15 cannot be used to activate asynchronous cdrom access).
+However, one can read files in asynchrouneous fashion via CdGetLbn,
+CdAsyncSeekL, and CdAsyncReadSector. CDROM files are non-fragmented, so they
+can be read simply from incrementing sector numbers.
Returns the first sector number used by the file, or -1 in case of error.
+BUG: The function accidently returns -1 for the first file in the directory
+(the first file should be a dummy entry for the current or parent directory or
+so, so that bug isn't much of a problem), if the file is not found, then the
+function accidently returns garbage (rather than -1).
Reads \<count> sectors, starting at \<sector>, and writes data to
+\<buffer>. The read is done in mode=80h (double speed, 800h-bytes per
+sector). The function waits until all sectors are transferred, and does then
+return the number of sectors (ie. count), or -1 in case of error.
Retrieves the cdrom status via CdAsyncGetStatus(dst) (see there for details;
+especially for cautions on door-open flag). The function waits until the event
+indicates completion, and does then return the status byte (or -1 in case of
+error).
Issues Setloc and SeekL commands. The parameter (src) is a pointer to a 3-byte
+sector number (MM,SS,FF) (in BCD format).
+The function returns 0=failed, or 1=okay. Completion is indicated by events
+(class=F0000003h, and spec=20h, or 8000h).
Issues a GetStat command. The parameter (dst) is a pointer to a 1-byte location
+that receives the status response byte.
+The function returns 0=failed, or 1=okay. Completion is indicated by events
+(class=F0000003h, and spec=20h, or 8000h).
+Caution: The command acknowledges the door-open flag, but doesn't automatically
+reload the path table (which is required if a new disk is inserted); if the
+door-open flag was set, one should call a function that does forcefully load
+the path table (like cd).
Issues SetMode and ReadN (when mode.bit8=0), or ReadS (when mode.bit8=1)
+commands. count is the number of sectors to be read, dst is the destination
+address in RAM, mode.bit0-7 are passed as parameter to the SetMode command,
+mode.bit8 is the ReadN/ReadS flag (as described above). The sector size (for
+DMA) depends on the mode value: 918h-bytes (bit4=1, bit5=X), 924h-bytes
+(bit4=0, bit5=1), or 800h-bytes (bit4,5=0).
+Before CdAsyncReadSector, the sector number should be set via
+CdAsyncSeekL(src).
+The function returns 0=failed, or 1=okay. Completion is indicated by events
+(class=F0000003h, and spec=20h, 80h, or 8000h).
Similar to CdAsyncReadSector (see there for details), but issues only the
+SetMode command, without any following ReadN/ReadS command.
Returns the first two response bytes from the most recent INT5 error:
+[dst1]=status, [dst2]=errorcode. The BIOS doesn't reset these values in case of
+successful completion, so the values are quite useless.
Internally used CDROM functions for initialization and IRQ handling.
Memory Cards aka Backup Units (bu) are basically accessed via normal file
+functions, with device names "bu00:" (Slot 1) and "bu10:" (Slot 2),
+BIOS File Functions
+Before using the file functions for memory cards, first call
+InitCARD2(pad_enable), then StartCARD2(), and then _bu_init().
The first 100h..200h bytes (2..4 sectors) of the file must contain the title
+and icon bitmap(s). For details, see:
+Memory Card Data Format
+The filesize must be a multiple of 2000h bytes (one block), the maximum size
+would be 1E000h bytes (when using all 15 blocks on the memory card). The
+filesize must be specified when creating the file (ie. accessmode bit9=1, and
+bit16-31=number of blocks). Once when the file is created, the BIOS does NOT
+allow to change the filesize (unless by deleting and re-creating the file).
+When reading/writing files, the amount of data must be a multiple of 80h bytes
+(one sector), and the file position must be aligned to a 80h-byte boundary,
+too. There's no restriction on fragmented files (ie. one may cross 2000h-byte
+block boundaries within the file).
PSX memory card accesses are typically super-slow. That, not so much because
+the hardware would be slow, but rather because of improper inefficent code at
+the BIOS side. The original BIOS tries to synchronize memory card accesses with
+joypad accesses simply by accessing only one sector per frame (although it
+could access circa two sectors). To the worst, the BIOS accesses Slot 1 only on
+each second frame, and Slot 2 only each other frame (although in 99% of all
+cases only one slot is accessed at once, so the access time drops to 0.5
+sectors per frame).
+Moreover, the memory card id, directory, and broken sector list do occupy 26
+sectors (although the whole information would fit into 4 or 5 sectors) (a
+workaround would be to read only the first some bytes, and to skip the
+additional unused bytes - though that'd also mean to skip the checksums which
+are unfortunately stored at the end of the sector).
+And, anytime when opening a file (in synchronous mode), the BIOS does
+additionally read sector 0 (which is totally useless, and gets especially slow
+when opening a bunch of files; eg. when extracting the title/icon from all
+available files on the card).
The BIOS supports synchronous and asynchronous memory card access. Synchronous
+means that the BIOS function doesn't return until the access has completed
+(which means, due to the poor performance, that the function spends about 75%
+of the time on inactivity) (except in nocash PSX bios, which has better
+performance), whilst asynchronous access means that the BIOS function returns
+immediately after invoking the access (which does then continue on interrupt
+level, and does return an event when finished).
+The file "read" and "write" functions act asynchronous when accessmode
+bit15 is set when opening the file. Additionally, the A(ACh)
+_card_load(port) function can be used to tell the BIOS to load
+the directory entries and broken sector list to its internal RAM buffers (eg.
+during the games title screen, so the BIOS doesn't need to load that data once
+when the game enters its memory card menu). All other functions like erase
+or format always act synchronous. The open/findfirst/findnext
+functions do normally complete immediately without accessing the card at all
+(unless the directory wasn't yet read; in that case the directory is loading in
+synchronous fashion).
+Unfortunately, the asynchronous response doesn't rely on a single callback
+event, but rather on a bunch of different events which must be all allocated
+and tested by the game (and of which, one event is delivered on completion)
+(which one depends on whether function completed okay, or if an error
+occurred).
The BIOS does have some partial support for accessing more than two memory
+cards (via Multitap adaptors). Device/port names "bu01:", "bu02:", "bu03:"
+allow to access extra memory carts in slot1 (and "bu11:", "bu12:", "bu13:" in
+slot2). Namely, those names will send values 82h, 83h, 84h to the memory card
+slot (instead of the normal 81h value).
+However, the BIOS directory_buffer and broken_sector_list do support only two
+memory cards (one in slot1 and one in slot2). So, trying to access more memory
+cards may cause great data corruption (though there might be a way to get the
+BIOS to reload those buffers before accessing a different memory card).
+Aside from that problem, the BIOS functions are very-very-very slow even when
+accessing only two memory cards. Trying to use the BIOS to access up to eight
+memory cards would be very-extremly-very slow, which would be more annoying
+than useful.
--- Below are some lower level memory card functions ---
+Can be used to check if the most recent call to _card_write has completed
+okay. Issues an incomplete dummy read command (similar to B(4Fh) -
+_card_read). The read command is aborted once when receiving the status
+byte from the memory card (the actual data transfer is skipped).
Resets the card changed flag. For some strange reason, this flag isn't
+automatically reset after reading the flag, instead, the flag is reset upon
+sector writes. To do that, this function issues a dummy write to sector 3Fh.
Normally any memory card read/write functions fail if the BIOS senses the card
+change flag to be set. Calling this function tells the BIOS to ignore the card
+change flag on the next read/write operation (the function is internally used
+when loading the "MC" ID from sector 0, and when calling the card_write_test
+function to acknowledge the card change flag).
Invokes asynchronous reading/writing of a single sector. The function returns
+1=okay, or 0=failed (on invalid sector numbers). The actual I/O is done on IRQ
+level, completion of the I/O command transmission can be checked, among others,
+via get/wait_card_status(slot) functions (with slot=port/10h).
+In case of the write function, completion of the \<transmission> does NOT
+mean that the actual \<writing> has completed, instead, write errors are
+indicated upon completion of the \<next sector> read/write transmission
+(or, if there are no further sectors to be accessed; one can use _card_info to
+verify completion of the last written sector).
+The sector number should be in range of 0..3FFh, for some strange reason,
+probably a BUG, the function also accepts sector 400h. The specified sector
+number is directly accessed (it is NOT parsed through the broken sector
+replacement list).
Returns the status of the most recent I/O command, possible values are:
+
01h=ready
+ 02h=busy/read
+ 04h=busy/write
+ 08h=busy/info
+ 11h=failed/timeout (eg. when no cartridge inserted)
+ 21h=failed/general error
+These five callback functions are internally used by the BIOS, notifying other
+BIOS functions about (un-)successful completion of memory card I/O commands.
This is a subfunction for the five bufs_cb__xxx functions (indicating
+whether the callback occured for a slot1 or slot2 access).
Invokes asynchronous reading of the memory card directory. The function isn't
+too useful because the BIOS tends to read the directory automatically in
+various places in synchronous mode, so there isn't too much chance to replace
+the automatic synchronous reading by asynchronous reading.
Can be used to enable/disable auto format (0=off, 1=on). The _bu_init function
+initializes auto format as disabled. If auto format is enabled, then the BIOS
+does automatically format memory cards if it has failed to read the "MC" ID
+bytes on sector 0. Although potentially useful, activating this feature is
+rather destructive (for example, read errors on sector 0 might occur accidently
+due to improperly inserted cards with dirty contacts, so it'd be better to
+prompt the user whether or not to format the card, rather than doing that
+automatically).
Allows to get/set the card find mode (0=normal, 1=find deleted files), the mode
+setting affects only the firstfile2/nextfile functions. All other file functions
+are used fixed mode settings (always mode=0 for open, rename,
+erase, and mode=1 for undelete).
The Playstation's Kernel uses an uncredible inefficient and unstable exception
+handler; which may have been believed to be very powerful and flexible.
For a maximum of slowness, it does always save and restore all CPU registers
+(including such that aren't used in the exception handler). It does then go
+through a list of installed interrupt handlers - and executes ALL of them. For
+example, a Timer0 IRQ is first passed to the Cdrom and Vblank handlers (which
+must reject it, no thanks), before it does eventually reach the Timer0 handler.
A fundamental mistake in the exception handler is that it doesn't memorize the
+incoming IRQ flags. So the various interrupt handlers must check Port 1F801070h
+one after each other. That means, if a high priority handler has rejected IRQ
+processing (because the desired IRQ flag wasn't set at that time), then a lower
+priority handler may process it (assuming that the IRQ flag got set in the
+meantime), and, in worst case it may even acknowledge it (so the high priority
+handler does never receive it).
+To avoid such problems, there should be only ONE handler installed for each IRQ
+source. However, that isn't always possible because the Kernel automatically
+installs some predefined handlers. Most noteworthy, the totally bugged
+DefaultInterruptHandlers is always installed (and cannot be removed), so it
+does randomly trigger Events. Fortunately, it does not acknowledge the IRQs
+(unless SetIrqAutoAck was used to enable that fatal behaviour).
Applies the default "Exit" structure (which consists of a pointer to
+ReturnFromException, and the Kernel's exception stacktop (minus 4, for whatever
+reason), and zeroes for the R16..R23,R28,R30 registers. Returns the address of
+that structure.
+See HookEntryInt for details.
addr points to a structure (with same format as for the setjmp function):
+
00h 4 r31/ra,pc ;usually ptr to ReturnFromException function
+ 04h 4 r28/sp ;usually exception stacktop, minus 4, for whatever reason
+ 08h 4 r30/fp ;usually 0
+ 0Ch 4x8 r16..r23 ;usually 0
+ 2Ch 4 r28/gp ;usually 0
+The Kernel's exception handler has four priority chains, each may contain one
+or more Interrupt or Exception handlers. The default handlers are:
+
Prio Chain Content
+ 0 CdromDmaIrq, CdromIoIrq, SyscallException
+ 1 CardSpecificIrq, VblankIrq, Timer2Irq, Timer1Irq, Timer0Irq
+ 2 PadCardIrq
+ 3 DefInt
+Inserts a new element in the specified priority chain. The new element is
+inserted at the begin of the chain, so (within that priority chain) the new
+element has highest priority.
+
00h 4 pointer to next element (0=none) ;this pointer is inserted by BIOS
+ 04h 4 pointer to SECOND function (0=none) ;executed if func1 returns r2<>0
+ 08h 4 pointer to FIRST function (0=none) ;executed first
+ 0Ch 4 Not used (usually zero)
+Removes the specified element from the specified priority chain.
+BUG: The function tries to search the whole chain (and to remove the element if
+it finds it). However, it does only check the first element properly, and,
+thereafter it reads a garbage value from an uninitialized stack location, and
+acts more or less unpredictable. So, it can remove only the first element in
+the chain, ie. it should be called only if you are SURE that there's no newer
+element in the chain, and only if you are SURE that the element IS in the
+chain.
Disables interrupts by clearing SR (cop0r12) Bit 2 and 10 (of which, Bit2 gets
+copied to Bit0 once when returning from the syscall exception). Returns 1 if
+both bits were set, returns 0 if one or both of the bits were already zero.
Enables interrupts by set SR (cop0r12) Bit 2 and 10 (of which, Bit2 gets copied
+to Bit0 once when returning from the syscall exception). There's no return
+value (all registers except SR and K0 are unchanged).
Specifies if the DefaultInterruptHandler shall automatically acknowledge IRQs.
+The "irq" paramter is the number of the interrupt, ie. 00h..0Ah = IRQ0..IRQ10.
+The "flag" value should be 0 to disable AutoAck, or non-zero to enable AutoAck.
+By default, AutoAck is disabled for all IRQs.
+Mind that the DefaultInterruptHandler is totally bugged. Especially the AutoAck
+feature doesn't work very well: It may cause higher priority handlers to miss
+their IRQ, and it may even cause the DefaultInterruptHandler to miss its own
+IRQs.
The C(06h) vector points to the exception handler, ie. to the function that is
+invoked from the 4 opcodes at address 80000080h, that opcodes jump directly to
+the exception handler, so patching the C(06h) vector has no effect.
+Reading the C(06h) entry can be used to let a custom 80000080h handler pass
+control back to the default handler (that, by a "direct" jump, not by the usual
+"MOV R9,06h / CALL 0C0h" method, which would destroy main programs R9
+register).
+Also, reading C(06h) may be useful for patching the exception handler (which
+contains a bunch of NOP opcodes, which seem to be intended to insert additional
+opcodes, such like debugger exception handling) (Note: some of that NOPs are
+reserved for Memory Card IRQ handling).
+BUG: Early BIOS versions did try to examine a copy of cop0r13 in r2 register,
+but did forgot cop0r13 to r2 (so they examined garbage), this was fixed in
+newer BIOS versions, additionally, most commercial games still include patches
+for compatibility with the old BIOS.
Restores the CPU registers (R1-R31,HI,LO,SR,PC) (except R26/K0) from the
+current TCB. This function is usually executed automatically at the end of the
+ExceptionHandler, however, functions in the exception chain may call
+ReturnFromException to return immediately, without processing chain elements of
+lower priority.
Internally used to add some default IRQ and Exception handlers.
The Kernel doesn't support nested exceptions, that would require a decreasing
+exception stack, however, the kernel saves the incoming CPU registers in the
+current TCB, and an exception stack with fixed start address for internal
+push/pop during exception handling. So, nesting would overwrite these values.
+Do not enable IRQs, and don't trap other exceptions (like break or syscall
+opcodes, or memory or overlow errors) during exception handling.
+Note: The execption stack has a fixed size of 1000h bytes (and is located
+somewhere in the first 64Kbytes of memory).
Adds an event structure to the event table.
+
class,spec - triggers if BOTH values match
+ mode - (1000h=execute function/stay busy, 2000h=no func/mark ready)
+ func - Address of callback function (0=None) (used only when mode=1000h)
+ out: R2 = Event descriptor (F1000000h and up), or FFFFFFFFh if failed
+Always returns 1 (even if the event handle is unused or invalid).
Always returns 1 (even if the event handle is unused or invalid).
Always returns 1 (even if the event handle is unused or invalid).
Returns 0 if the event is disabled. Otherwise hangs in a loop until the event
+becomes ready, and returns 1 once when it is ready (and automatically switches
+the event back to busy status). Callback events (mode=1000h) do never set the
+ready flag (and thus WaitEvent would hang forever).
+The main program simply hangs during the wait, so when using multiple threads,
+it may be more recommended to create an own waitloop that checks TestEvent, and
+to call ChangeTh when the event is busy.
+BUG: The return value is unstable (sometimes accidently returns 0=disabled if
+the event status changes from not-ready to ready shortly after the function
+call).
Returns 0 if the event is busy or disabled. Otherwise, when it is ready,
+returns 1 (and automatically switches the event back to busy status). Callback
+events (mode=1000h) do never set the ready flag.
This function is usually called by the kernel, it triggers all events that are
+enabled/busy, and that have the specified class and spec values. Depending on
+the mode, either the callback function is called (mode=1000h), or the event is
+marked as enabled/ready (mode=2000h).
This function is usually called by the kernel, undelivers all events that are
+enabled/ready, and that have mode=2000h, and that have the specified class and
+spec values. Undeliver means that the events are marked as enabled/busy.
A subfunction for OpenEvent.
File Events:
+
0000000xh memory card (for file handle fd=x)
+ F0000001h IRQ0 VBLANK
+ F0000002h IRQ1 GPU
+ F0000003h IRQ2 CDROM Decoder
+ F0000004h IRQ3 DMA controller
+ F0000005h IRQ4 RTC0 (timer0)
+ F0000006h IRQ5/IRQ6 RTC1 (timer1 or timer2)
+ F0000007h N/A Not used (this should be timer2)
+ F0000008h IRQ7 Controller (joypad/memcard)
+ F0000009h IRQ9 SPU
+ F000000Ah IRQ10 PIO ;uh, does the PIO have an IRQ signal? (IRQ10 is joypad)
+ F000000Bh IRQ8 SIO
+ F0000010h Exception ;CPU crashed (BRK,BadSyscall,Overflow,MemoryError, etc.)
+ F0000011h memory card (lower level BIOS functions)
+ F0000012h memory card (not used by BIOS; maybe used by Sony's devkit?)
+ F0000013h memory card (not used by BIOS; maybe used by Sony's devkit?)
+ F1xxxxxxh event (not used by BIOS; maybe used by Sony's devkit?)
+ F2000000h Root counter 0 (Dotclock) (hardware timer)
+ F2000001h Root counter 1 (horizontal retrace?) (hardware timer)
+ F2000002h Root counter 2 (one-eighth of system clock) (hardware timer)
+ F2000003h Root counter 3 (vertical retrace?) (this is a software timer)
+ F3xxxxxxh user (not used by BIOS; maybe used by games and/or Sony's devkit?)
+ F4000001h memory card (higher level BIOS functions)
+ F4000002h libmath (not used by BIOS; maybe used by Sony's devkit?)
+ FFxxxxxxh thread (not used by BIOS; maybe used by Sony's devkit?)
+ 0001h counter becomes zero
+ 0002h interrupted
+ 0004h end of i/o
+ 0008h file was closed
+ 0010h command acknowledged
+ 0020h command completed
+ 0040h data ready
+ 0080h data end
+ 0100h time out
+ 0200h unknown command
+ 0400h end of read buffer
+ 0800h end of write buffer
+ 1000h general interrupt
+ 2000h new device
+ 4000h system call instruction ;SYS(04h..FFFFFFFFh)
+ 8000h error happened
+ 8001h previous write error happened
+ 0301h domain error in libmath
+ 0302h range error in libmath
+ 1000h Execute callback function, and stay busy (do NOT mark event as ready)
+ 2000h Do NOT execute callback function, and mark event as ready
+Below is a list of all events (class,spec values) that are delivered and/or
+undelivered by the BIOS in one way or another. The BIOS does internally open
+five events for cdrom (class=F0000003h with spec=10h,20h,40h,80h,8000h). The
+various other class/spec's are only delivered by the BIOS (but not received by
+the BIOS) (ie. a game may open/enable memory card events to receive
+notifications from the BIOS).
F0000003h,10h cdrom DMA finished (all sectors finished)
+ F0000003h,20h cdrom ?
+ F0000003h,40h cdrom dead feature (delivered only by unused functions)
+ F0000003h,80h cdrom INT4 (reached end of disk)
+ F0000003h,100h n/a ? ;undelivered, but not opened, nor delivered
+ F0000003h,200h ;undelivered, but not opened
+ F0000003h,8000h
+ 0000000xh,4 card file handle (x=fd) done okay
+ F4000001h,4 card done okay (len=0)
+ F4000001h,100h card err busy ;A(A9h)
+ F4000001h,2000h card err eject ;A(AAh) or unformatted (bad "MC" id)
+ F4000001h,8000h card err write ;A(A8h) or A(AEh) or general error
+ F0000011h,4 finished okay
+ F0000011h,100h err busy
+ F0000011h,200h n/a ?
+ F0000011h,2000h err
+ F0000011h,8000h err
+ F0000011h,8001h err (this one is NOT undelivered!)
+ F2000000h,2 Timer0 (IRQ4)
+ F2000001h,2 Timer1 (IRQ5)
+ F2000002h,2 Timer2 (IRQ6)
+ F2000003h,2 Vblank (IRQ0) (unstable since IRQ0 is also used for joypad)
+ F0000001h,1000h ;IRQ0 (VBLANK)
+ F0000002h,1000h ;IRQ1 (GPU)
+ F0000003h,1000h ;IRQ2 (CDROM)
+ F0000004h,1000h ;IRQ3 (DMA)
+ F0000005h,1000h ;IRQ4 (TMR0)
+ F0000006h,1000h ;IRQ5 (TMR1)
+ F0000006h,1000h ;IRQ6 (TMR2) (accidently uses same event as TMR1)
+ F0000008h,1000h ;IRQ7 (joypad/memcard)
+ F0000009h,1000h ;IRQ9 (SPU)
+ F000000Ah,1000h ;IRQ10 (Joypad and PIO)
+ F000000Bh,1000h ;IRQ8 (SIO)
+ F0000010h,1000h unknown exception ;neither IRQ nor SYSCALL
+ F0000010h,4000h unknown syscall ;syscall(04h..FFFFFFFFh)
+Searches a free TCB, marks it as used, and stores the inital program counter
+(PC), global pointer (GP aka R28), stack pointer (SP aka R29), and frame
+pointer (FP aka R30) (using the same value for SP and FP). All other registers
+are left uninitialized (eg. may contain values from an older closed thread,
+that includes the SR register, see note).
+The return value is the new thread handle (in range FF000000h..FF000003h,
+assuming that 4 TCBs are allocated) or FFFFFFFFh if there's no free TCB. The
+function returns to the old current thread, use "ChangeTh" to switch to the
+new thread.
+Note: The desired max number of TCBs can be specified in the SYSTEM.CNF boot
+file (the default is "TCB = 4", one initially used for the boot executable,
+plus 3 free threads).
OpenTh does NOT initialize the SR register (cop0r12) of the new thread.
+Upon powerup, the bootcode zerofills the TCB memory (so, the SR of new threads
+will be initially zero; ie. Kernel Mode, IRQ's disabled, and COP2 disabled).
+However, when closing/reopening threads, the SR register will have the value of
+the old closed thread (so it may get started with IRQs enabled, and, in worst
+case, if the old thread should have switched to User Mode, even without access
+to KSEG0, KSEG1 memory).
+Or, ACTUALLY, the memory is NOT zerofilled on powerup... so SR is total random?
Marks the TCB for the specified thread as unused. The function can be used for
+any threads, including for the current thread.
+Closing the current thread doesn't terminate the current thread, so it may
+cause problems once when opening a new thread, however, it should be stable to
+execute the sequence "DisableInterrupts, CloseCurrentThread,
+ChangeOtherThread".
+The return value is always 1 (even if the handle was already closed).
Pauses the current thread, and activates the selected new thread (or crashes if
+the specified handle was unused or invalid).
+The return value is always 1 (stored in the R2 entry of the TCB of the old
+thread, so the return value will be received once when changing back to the old
+thread).
+Note: The BIOS doesn't automatically switch from one thread to another. So, all
+other threads remain paused until the current thread uses ChangeTh to pass
+control to another thread.
+Each thread is having it's own CPU registers (R1..R31,HI,LO,SR,PC), the
+registers are stored in the TCB of the old thread, and restored when switching
+back to that thread. Mind that other registers (I/O Ports or GTE registers
+aren't stored automatically, so, when needed, they need to be pushed/popped by
+software before/after ChangeTh).
Subfunction for OpenTh, returns the number of the first free TCB (usually
+in range 0..3) or FFFFFFFFh if there's no free TCB.
Subfunction for ChangeTh, R5 contains the address of the new TCB, just like
+all exceptions, the syscall exception is saving the CPU registers in the
+current TCB, but does then apply the new TCB as current TCB, and so, it does
+then enter the new thread when returning from the exception.
The three hardware timers aren't internally used by any BIOS functions, so they
+can be freely used by the game, either via below functions, or via direct I/O
+access.
Some of the below functions are allowing to use Vblank IRQs as a fourth
+"timer". However, Vblank IRQs are internally used by the BIOS for handling
+joypad and memory card accesses. One could theoretically use two separate
+Vblank IRQ handlers, one for joypad, and one as "timer", but the BIOS is much
+too unstable for such "shared" IRQ handling (it may occassionally miss one of
+the two handlers).
+So, although Vblank IRQs are most important for games, the PSX BIOS doesn't
+actually allow to use them for purposes other than joypad access. A possible
+workaround is to examine the status byte in one of the joypad buffers (ie. the
+InitPAD2(buf1,22h,buf2,22h) buffers). Eg. a wait_for_vblank function could look
+like so: set buf1[0]=55h, then wait until buf1[0]=00h or buf1[0]=FFh.
When t=0..2, resets the old timer mode by setting [1F801104h+t*16]=0000h,
+applies the reload value by [1F801108h+t*16]=reload, computes the new mode:
+
if flags.bit4=0 then mode=0048h else mode=0049h
+ if flags.bit0=0 then mode=mode OR 100h
+ if flags.bit12=1 then mode=mode OR 10h
+Reads the current timer value: Returns halfword[1F801100h+t*16] for t=0..2.
+Does nothing and returns zero for t>2.
Enables/disables timer or vblank interrupt enable bits in [1F801074h], bit4,5,6
+for t=0,1,2, or bit0 for t=3, or random/garbage bits for t>3. The enable
+function returns 1 for t=0..2, and 0 for t=3. The disable function returns
+always 1.
Sets the current timer value to zero: Sets [1F801100h+t*16]=0000h and returns 1
+for t=0..2. Does nothing and returns zero for t>2.
Selects what the kernel's timer/vblank IRQ handlers shall do after they have
+processed an IRQ (t=0..2: timer 0..2, or t=3: vblank) (flag=0: do nothing; or
+flag=1: automatically acknowledge the IRQ and immediately return from
+exception). The function returns the old (previous) flag value.
Joypads should be initialized via InitPAD2(buf1,22h,buf2,22h), and StartPAD2().
+The main program can read the pad data from the buf1/buf2 addresses (including
+Status, ID1, button states, and any kind of analogue inputs). For more info on
+ID1, Buttons and analogue inputs, see
+Controllers and Memory Cards
+Note: The BIOS doesn't include any functions for sending custom data to the
+pads (such like for controlling rumble motors).
Memorizes the desired buf1/buf2 addresses, zerofills the buffers by using the
+siz1/siz2 buffer size values (which should be 22h bytes each). And does some
+initialization on the PadCardIrq element (but doesn't enqueue it, that must be
+done by a following call to StartPAD2), and does set the "pad_enable_flag", that
+flag can be also set/cleared via InitCARD2(pad_enable), where it selects if the
+Pads are kept handled together with Memory Cards. buf1/buf2 are having the
+following format:
+
00h Status (00h=okay, FFh=timeout/wrong ID2)
+ 01h ID1 (eg. 41h=digital_pad, 73h=analogue_pad, 12h=mouse, etc.)
+ 02h..21h Data (max 16 halfwords, depending on lower 4bit of ID1)
+Should be used after InitPAD2. Enqueues the PadCardIrq handler, and does
+additionally initialize some flags.
Dequeues the PadCardIrq handler. Note that this handler is also used for memory
+cards, so it'll "stop" cards, too.
This is an extremely bizarre and restrictive function - don't use! The function
+fails unless type is 20000000h or 20000001h (the type value has no other
+function). The function uses "buf1/buf2" addresses that are located somewhere
+"hidden" within the BIOS variables region, the only way to read from that
+internal buffers is to use the ugly "PAD_dr()" function. For
+some strange reason it FFh-fills buf1/buf2, and does then call
+InitPAD2(buf1,22h,buf2,22) (which does immediately 00h-fill the previously
+FFh-filled buffers), and does then call StartPAD2().
+Finally, it does memorize the "button_dest" address (see
+PAD_dr() for details on that value). The two unused parameters
+have no function, however, they are internally written back to the stack
+locations reserved for parameter 2 and 3, ie. at [SP+08h] and [SP+0Ch] on the
+caller's stack, so the function MUST be called with all four parameters
+allocated on stack. Return value is 2 (or 0 if type was disliked).
This is a very ugly function, using the internal "buf1/buf2" values from
+"PAD_init2" and the "button_dest" value that was passed to that
+function.
+If "button_dest" is non-zero, then this function is automatically called by the
+PadCardIrq handler, and stores it's return value at [button_dest] (where it may
+be read by the main program). If "button_dest" is zero, then it isn't called
+automatically, and it \<can> be called manually (with return value in R2),
+however, it does additionally write the return value to [button_dest], ie. to
+[00000000h] in this case, destroying that memory location.
+The return value itself is useless garbage: The lower 16bit contain the pad1
+buttons, the upper 16bit the pad2 buttons, of which, both values have reversed
+byte-order (ie. the first button byte in upper 8bit). The function works only
+with controller IDs 41h (digital joypad) and 23h (nonstandard device). For
+ID=23h, the halfword is ORed with 07C7h, and bit6,7 are then cleared if the
+analogue inputs are greater than 10h. For ID=41h the data is left intact. Any
+other ID values, or disconnected joypads, cause the halfword to be set to FFFFh
+(same as when no buttons are pressed), that includes newer analogue pads
+(unless they are switched to "digital" mode).
Writes [1F801814h]=gp1cmd. There's no return value (r2 is left unchanged).
Calls gpu_sync(), and does then write [1F801810h]=gp0cmd. Returns the return
+value from the gpu_sync() call.
Calls gpu_sync(), and does then copy "num" words from [src and up] to
+[1F801810h], src should usually point to a command word, followed by num-1
+parameter words. Transfer is done by software (without DMA). Always returns 0.
Transfer an OT via DMA. Calls gpu_sync(), and does then write
+[1F801814h]=4000002h, [1F8010F4h]=0, [1F8010F0h]=[1F8010F0h] OR 800h,
+[1F8010A0h]=src, [1F8010A4h]=0, [1F8010A8h]=1000401h. The function does
+additionally output a bunch of TTY status messages via printf. The function
+doesn't wait until the DMA is completed. There's no return value.
Writes [1F8010A8h]=401h, [1F801814h]=4000000h, [1F801814h]=2000000h,
+[1F801814h]=1000000h. Ie. stops GPU DMA, and issues GP1(4), GP1(2), GP1(1).
+Returns 1F801814h, ie. the I/O address.
Reads [1F801814h] and returns that value.
Waits until GPUSTAT.Bit26 is set (unlike gpu_sync, which waits for Bit28), and
+does then [1F801810h]=A0000000h, [1F801810h]=YdstXdst, [1F801810h]=YsizXsiz,
+and finally transfers "N" words from [src and up] to [1F801810h], where "N" is
+"Xsiz*Ysiz/2". The data is transferred by software (without DMA) (by code
+executed in the uncached BIOS region with high waitstates, so the data transfer
+is very SLOW).
+Caution: If "Xsiz*Ysiz" is odd, then the last halfword is NOT transferred, so
+the GPU stays waiting for the last data value.
+Returns [SP+04h]=Ydst, [SP+08h]=Xsiz, [SP+0Ch]=Ysiz, [SP+10h]=src+N*4, and
+R2=src=N*4.
Calls gpu_sync(), writes [1F801810h]=A0000000h, [1F801814h]=4000002h,
+[1F8010F0h]=[1F8010F0h] OR 800h, [1F8010A0h]=src, [1F8010A4h]=N*10000h+10h
+(where N="Xsiz*Ysiz/32"), [1F8010A8h]=1000201h.
+Caution: If "Xsiz*Ysiz" is not a multiple of 32, then the last halfword(s) are
+NOT transferred, so the GPU stays waiting for that values.
+Returns R2=1F801810h, and [SP+04h]=Ydst, [SP+08h]=Xsiz, [SP+0Ch]=Ysiz.
If DMA is off (when GPUSTAT.Bit29-30 are zero): Waits until GPUSTAT.Bit28=1 (or
+until timeout).
+If DMA is on: Waits until D2_CHCR.Bit24=0 (or until timeout), and does then
+wait until GPUSTAT.Bit28=1 (without timeout, ie. may hang forever), and does
+then turn off DMA via GP1(04h).
+Returns 0 (or -1 in case of timeout, however, the timeout values are very big,
+so it may take a LOT of seconds before it returns).
Allocates size bytes on the heap, and returns the memory handle (aka the
+address of the allocated memory block). The address of the block is guaranteed
+to by aligned to 4-byte memory boundaries. Size is rounded up to a multiple of
+4 bytes. The address may be in KUSEG, KSEG0, or KSEG1, depending on the address
+passed to InitHeap.
+Caution: The BIOS (tries to) initialize the heap size to 0 bytes (actually it
+accidently overwrites that initial setting by garbage during relocation), so
+any call to malloc will fail, unless InitHeap has been used to initialize the
+address/size of the heap.
Deallocates the memory block. There's no return value, and no error checking.
+The function simply sets [buf-4]=[buf-4] OR 00000001h, so if buf is an invalid
+handle it may destroy memory at [buf-4], or trigger a memory exception (for
+example, when buf=0).
Allocates xsiz*ysiz bytes by calling malloc(xsiz*ysiz), and, unlike malloc, it
+does additionally zerofill the memory via SLOW "bzero" function. Returns the
+address of the memory block (or zero if failed).
If "old_buf" is zero, executes malloc(new_size), and returns r2=new_buf (or
+0=failed). Else, if "new_size" is zero, executes free(old_buf), and returns
+r2=garbage. Else, executes malloc(new_size), bcopy(old_buf,new_buf,new_size),
+and free(old_buf), and returns r2=new_buf (or 0=failed).
+Caution: The bcopy function is SLOW, and realloc does accidently copy
+"new_size" bytes from old_buf, so, if the old_size was smaller than new_size
+then it'll copy whatever garbage data - in worst case, if it exceeds the top of
+the 2MB RAM region, it may crash with a locked memory exception, although
+that'd happen only if SetMem(2) was used to restrict RAM to 2MBs.
Initializes the address and size of the heap - the BIOS does not automatically
+do this, so, before using the heap, InitHeap must be called by software.
+Usually, the heap would be memory region between the end of the boot
+executable, and the bottom of the executable's stack. InitHeap can be also used
+to deallocate all memory handles (eg. when a new exe file has been loaded, it
+may use it to deallocate all old memory).
+The heap is used only by malloc/realloc/calloc/free, and by the "qsort"
+function.
Same as malloc/free, but, instead of the heap, manages the 8kbyte control block
+memory at A000E000h..A000FFFFh. This region is used by the kernel to allocate
+ExCBs (4x08h bytes), EvCBs (N*1Ch bytes), TCBs (N*0C0h bytes), and the process
+control block (1x04h bytes). Unlike the heap, the BIOS does automatically
+initialize this memory region via SysInitMemory(addr,size), and does
+autimatically allocate the above data (where the number of EvCBs and TCBs is as
+specified in the SYSTEM.CNF file). Note: FCBs and DCBs are located elsewhere,
+at fixed locations in the kernel variables area.
The kernel doesn't include any allocation functions for the scratchpad (nor do
+any kernel functions use that memory area), so the executable can freely use
+the "fast" memory at 1F800000h..1F8003FFh.
Changes the effective RAM size (2 or 8 megabytes) by manipulating port
+1F801060h, and additionally stores the size in megabytes in RAM at [00000060h].
+Note: The BIOS bootcode accidently sets the RAM value to 2MB (which is the
+correct physical memory size), but initializes the I/O port to 8MB (which
+mirrors the physical 2MB within that 8MB region), so the initial values don't
+match up with each other.
+Caution: Applying the correct size of 2MB may cause the "realloc" function to
+crash (that function may accidently access memory above 2MB).
Like most A(NNh) functions, below functions are executed in uncached BIOS ROM,
+the ROM has very high waitstates, and the 32bit opcodes are squeezed through an
+8bit bus. Moreover, below functions are restricted to process the data
+byte-by-byte. So, they are very-very-very slow, don't even think about using
+them.
+Of course, that applies also for most other BIOS functions. But it's becoming
+most obvious for these small functions; memcpy takes circa 160 cycles per byte
+(reasonable would be less than 4 cycles), and bzero takes circa 105 cycles per
+byte (reasonable would be less than 1 cycles).
Copies len bytes from [src..src+len-1] to [dst..dst+len-1]. Refuses to copy any
+data when dst=00000000h or when len>7FFFFFFFh. The return value is always
+the incoming "dst" value.
Fills len bytes at [dst..dst+len-1] with the fillbyte value. Refuses to fill
+memory when dst=00000000h or when len>7FFFFFFFh. The return value is the
+incoming "dst" value (or zero, when len=0 or len>7FFFFFFFh).
Same as memcpy, but (attempts) to support overlapping src/dst regions, by using
+a backwards transfer when src\<dst (and, for some reason, only when
+dst>=src+len).
+BUG: The backwards variant accidently transfers len+1 bytes from [src+len..src]
+down to [dst+len..dst].
Compares len bytes at [src1..src1+len-1] with [src2..src2+len-1], and
+(attempts) to return the difference between the first mismatching bytes, ie.
+[src1+N]-[src2+N], or 0 if there are no mismatches. Refuses to compare data
+when src1 or src2 is 00000000h, and returns 0 in that case.
+BUG: Accidently returns the difference between the bytes AFTER the first
+mismatching bytes, ie. [src1+N+1]-[src2+N+1].
+That means that a return value of 0 can mean absolutely anything: That the
+memory blocks are identical, or that a mismatch has been found (but that the
+NEXT byte after the mismatch does match), or that the function has failed (due
+to src1 or src2 being 00000000h).
Scans [src..src+len-1] for the first occurence of scanbyte. Refuses to scan any
+data when src=00000000h or when len>7FFFFFFFh. Returns the address of that
+first occurence, or 0 if the scanbyte wasn't found.
Same as "memcpy", but with "src" and "dst" exchanged. That is, the first
+parameter is "src", the refuse occurs when "src" is 00000000h, and, returns the
+incoming "src" value (whilst "memcpy" uses "dst" in that places).
Same as memset, but uses 00h as fixed fillbyte value.
Same as "memcmp", with exactly the same bugs.
Appends src to the end of dst. Searches the ending 00h byte in dst, and copies
+src to that address, up to including the ending 00h byte in src. Returns the
+incoming dst value. Refuses to do anything if src or dst is 00000000h (and
+returns 0 in that case).
Same as "strcat", but clipped to "MaxSrc=(min(0,maxlen)+1)" characters, ie. the
+total length is max "length(dst)+min(0,maxlen)+1". If src is longer or equal to
+"MaxSrc", then only the first "MaxSrc" chars are copied (with the last byte
+being replaced by 00h). If src is shorter, then everything up to the ending 00h
+byte gets copied, but without additional padding (unlike as in "strncpy").
Compares the strings up to including ending 00h byte. Returns 0 if they are
+identical, or otherwise [str1+N]-[str2+N], where N is the location of the first
+mismatch, the two bytes are sign-expanded to 32bits before doing the
+subtraction. The function rejects str1/str2 values of 00000000h (and returns
+0=both are zero, -1=only str1 is zero, and +1=only str2 is zero).
Same as "strcmp" but stops after comparing "maxlen" characters (and returns 0
+if they did match). If the strings are shorter, then comparision stops at the
+ending 00h byte (exactly as for strcmp).
Copies data from src to dst, up to including the ending 00h byte. Refuses to
+copy anything if src or dst is 00000000h. Returns the incoming dst address (or
+0 if copy was refused).
Same as "strcpy", but clipped to "maxlen" characters. If src is longer or equal
+to maxlen, then only the first "maxlen" chars are copied (but without appending
+an ending 00h byte to dst). If src is shorter, then the remaining bytes in dst
+are padded with 00h bytes.
Returns the length of the string up to excluding the ending 00h byte (or 0 when
+src is 00000000h).
Scans for the first (index) or last (rindex) occurence of char in the string.
+Returns the memory address of that occurence (or 0 if there's no occurence, or
+if src is 00000000h). Char may be 00h (returns the end address of the string).
+Note that, despite of the function names, the return value is always a memory
+address, NOT an index value relative to src.
Scans for the first occurence of a character that is contained in the list. The
+list contains whatever desired characters, terminated by 00h.
+Returns the address of that occurence, or 0 if there was none. BUG: If there
+was no occurence, it returns 0 only if src[0]=00h, and otherwise returns the
+incoming "src" value (which is the SAME return value as when a occurence did
+occur on 1st character).
Scans for the first occurence of a character that is (strspn), or that isn't
+(strcspn) contained in the list. The list contains whatever desired characters,
+terminated by 00h.
+Returns the index (relative to src) of that occurence. If there was no
+occurence, then it returns the length of src. That silly return values do not
+actually indicate if an occurence has been found or not (unless one checks for
+[src+index]=00h or so).
+***
+"The strcspn() function shall compute the length (in bytes) of the maximum
+initial segment of the string pointed to by s1 which consists entirely of bytes
+not from the string pointed to by s2."
+"The strspn() function shall compute the length (in bytes) of the maximum
+initial segment of the string pointed to by s1 which consists entirely of bytes
+from the string pointed to by s2."
+***
+Hmmmm, that'd be vice-versa?
Used to split a string into fragments, list contains a list of characters that
+are to be treated as separators, terminated by 00h.
+The first call copies the incoming string to a buffer in the BIOS variables
+area (the buffer size is 100h bytes, so the string should be max 255 bytes
+long, plus the ending 00h byte, otherwise the function destroys other BIOS
+variables), it does then search the first fragment, starting at the begin of
+the buffer. Further calls (with src=00000000h) are searching further fragments,
+starting at the buffer address from the previous call. The internal buffer is
+used only for strtok, so its contents (and the returned string fragments)
+remain intact until a new first call to strtok takes place.
+The separate fragments are processed by searching the first separator, starting
+at the current buffer address, the separator is then replaced by a 00h byte,
+and the old buffer address is returned to the caller. Moreover, the function
+tries to skip all continously following separators, until reaching a
+non-separator, and does memorize that address for the next call (due to that
+skipping further calls won't return empty fragments, the first call may do so
+though). That skipping seems to be bugged, if list contains two or more
+different characters, then additional separators aren't skipped.
+
",,TEXT,,,END" with list="," returns "", "TEXT", "END"
+ ",,TEXT,,,END" with list=",." returns "", "", "TEXT", "", "", "END"
+Scans for the first occurence of substr in the string. Returns the memory
+address of that occurence (or 0 if it was unable to find an occurence).
+BUG: After rejecting incomplete matches, the function doesn't fallback to the
+old str address plus 1, but does rather continue at the current str address.
+Eg. it doesn't find substr="aab" in str="aaab" (in that example, it does merely
+realize that "aab"\<>"aaa" and then that "aab"\<>"b").
Returns the absolute value (if val\<0 then R2=-val, else R2=val).
Takes the incoming character, ANDed with FFh, and returns 0..9 for characters
+"0..9" and 10..35 for "A..Z" or "a..z", or 0098967Fh (9,999,999 decimal) for
+any other 7bit characters, or garbage for characters 80h..FFh.
Returns the incoming character, ANDed with FFh, with letters "A..Z" converted
+to uppercase/lowercase format accordingly. Works only for char 00h..7Fh (some
+characters in range 80h..FFh are left unchanged, others are randomly "adjusted"
+by adding/subtracting 20h, and by sign-expanding the result to 32bits).
Converts a string to a number. The function skips any leading "blank"
+characters (that are, 09h..0Dh, and 20h) (ie. TAB, CR, LF, SPC, and some
+others) (some characters in range 80h..FFh are accidently treated as "blank",
+too).
+The incoming base value should be in range 2..11, although the function does
+also accept the buggy values in range of 12..36 (for values other than 2..36 it
+defaults to decimal/base10). The used numeric digits are "0..9" and "A..Z" (or
+less when base is smaller than 36).
+The string may have a negative sign prefix "-" (negates the result) (a "+" is
+NOT recognized; and will be treated as the end of the string). Additionally,
+the string may contain prefixes "0b" (binary/base2), "0x" (hex/base16), or "o"
+(octal/base8) (only "o", not "0o"), allowing to override the incoming "base"
+value.
+BUG: Incoming base values greater than 11 don't work due to the prefix feature
+(eg. base=16 with string "0b11" will be treated as 11 binary, and base=36 with
+string "o55" will be treated as 55 octal) (the only workaround would be to
+add/remove leading "0" characters, ie. "b11" or "00b11" or "0o55" would work
+okay).
+Finally, the function initializes result=0, and does then process the digits as
+"result=result*base+digit" (without any overflow checks) unless/until it
+reaches an unknown digit (or when digit>=base) (ie. the string may end with
+00h, or with any other unexpected characters).
+The function accepts both uppercase and lowercase characters (both as prefixes,
+and as numeric digits). The function returns R2=result, and
+[src_end]=end_address (ie. usually the address of the ending 00h byte; or of
+any other unexpected end-byte). If src points to 00000000h, then the function
+returns r2=0, and leaves [src_end] unchanged.
Same as "strtol" except that it doesn't recognize the "-" sign prefix (ie.
+works only for unsigned numbers).
Same as "strtol", except that it doesn't return the string end address in
+[src_end], and except that it defaults to base=10, but still supports prefixes,
+allowing to use base2,8,16. CAUTION: For some super bizarre reason, this
+function treats "0" (a leading ZERO digit) as OCTAL prefix (unlike strtol,
+which uses the "o" letter as octal prefix) (the "0x" and "0b" prefixes are
+working as usually).
Calls "strtol(str,src_end,10)", and does then exchange the two return values
+(ie. sets R2=[src_end], and [num_dst]=value_32bit).
These functions are intended to convert strings to floating point numbers,
+however, the functions are accidently compiled for MIPS processors with COP1
+floating point unit (which is not installed in the PSX, nor does the BIOS
+support a COP1 software emulation), so calling these functions will produce a
+coprocessor exception, causing the PSX to lockup via A(40h)
+SystemErrorUnresolvedException.
On other systems (eg. 8bit computers), "abs/atoi" (integer) and "labs/atol"
+(long) may act differently. However, on the Playstation, both use signed 32bit
+values.
Advances the random generator as "x=x*41C64E6Dh+3039h" (aka plus 12345
+decimal), and returns a 15bit random value "R2=(x/10000h) AND 7FFFh".
Changes the current 32bit value of the random generator.
Returns a word, halfword, or string, depending on the selected index value:
+
00h Get Kernel BCD Date (eg. 19951204h) (YYYYMMDDh)
+ 01h Get Kernel Flags or so (usually/always 000000003h)
+ 02h Get Kernel Version String (eg. "CEX-3000/1001/1002 by K.S.",0)
+ 03h Get whatever halfword (usually 0) ;PS2: returns cop0r15
+ 04h Get whatever halfword (usually 0)
+ 05h Get RAM Size in kilobytes (usually 2048) ;=[00000060h] SHL 10
+ 06h..0Eh Get whatever halfwords (usually 0,400h,0,200h,0,0,1,1,1)
+ 0Fh N/A (returns zero) ;PS2: returns 0000h (effectively = same as zero)
+ 10h..FFFFFFFFh Not used (returns zero)
+Retrieves the address of the jump lists for B(NNh) and C(NNh) functions,
+allowing to patch entries in that lists (however, the BIOS does often jump
+directly to the function addresses, rather than indirectly via the list, so
+patching may have little effect in such cases). Note: There's no function to
+retrieve the address of the A(NNh) jump list, however, that list is
+usually/always at 00000200h.
Sorts an array, using a super-slow implementation of the "quick sort"
+algorithm. base is the address of the array, nel is the number of elements in
+the array, width is the size in bytes of each element, callback is a function
+that receives pointers to two elements which need to be compared; callback
+should return return zero if the elements are identical, or a positive/negative
+number to indicate which element is bigger.
+The qsort function rearranges the contents of the array, ie. depending on the
+callback result, it may swap the contents of the two elements, for some bizarre
+reason it doesn't swap them directly, but rather stores one of the elements
+temporarily on the heap (that means, qsort works only if the heap was
+initialized with InitHeap, and only if "width" bytes are free). There's no
+return value.
Searches an element in an array (key is the pointer to the searched element,
+the other parameters are same as for "qsort"). "lsearch" performs a slow linear
+search in an unsorted array, by simply comparing one array element after each
+other. "bsearch" assumes that the array contains sorted elements (eg. via
+qsort), which is allowing to skip some elements, and to jump back and forth in
+the array, until it has found the desired element (or the location where it'd
+be, if it'd be in the array). Both functions return the address of the element
+(or 0 if it wasn't found).
Displays the two strings on the TTY (in some cases the BIOS does accidently
+pass garbage instead of the 2nd string though). And does then execute
+_ioabort_raw(1), see there for more details.
Executes "longjmp(ioabortbuffer,param)". Internally used to recover from
+failed I/O operations, param should be nonzero to notify the setjmp caller
+that the abort has occurred.
This is a somewhat incomplete implementation of posix's setjmp, by storing the ABI-saved CPU registers in the specified buffer (30h bytes):
+
00h 4 r31 (ra) (aka caller's pc)
+ 04h 4 r29 (sp)
+ 08h 4 r30 (fp)
+ 0Ch 4x8 r16..r23
+ 2Ch 4 r28 (gp)
+Restores the R16-R23,GP,SP,FP,RA registers from a previously recorded
+jmp_buf buffer, and "returns" to that new RA address (rather than to the caller of the
+longjmp function). The "param" value is passed as "return value" to the
+code at RA, ie. usually to the caller of the original setjmp call. Noteworthy difference
+from a conformant longjmp implementation is that the "param" value won't be clamped to 1 if
+you pass 0 to it. So since setjmp returns 0 on the first call, the caller of longjmp must take
+care that "param" is non-zero, so the callsite of setjmp can make the difference between the first
+call and a rollback. See setjmp for further details.
Normally the _ioabort handler is changed only internally during booting, with
+this new function, games can install their own _ioabort handler. src is pointer
+to a 30h-byte "savestate" structure, which will be copied to the actual _ioabort
+structure.
Terminates the program and returns control to the BIOS; which does then lockup
+itself via A(3Ah) _exit.
Performs a warmboot (resets the kernel and reboots from CDROM). Unlike the
+normal coldboot procedure, it doesn't display the "\<S>" and "PS" intro
+screens (and doesn't verify the "PS" logo in the ISO System Area), and, doesn't
+enter the bootmenu (even if the disk drive is empty, or if it contains an Audio
+disk). And, it doesn't reload the SYSTEM.CNF file, so the function works only
+if the same disk is still inserted (or another disk with identical SYSTEM.CNF,
+such like Disk 2 of the same game).
These functions jump to address 00000000h. For whatever reason, that address
+does usually contain a copy of the exception handler (ie. same as at address
+80000080h). However, since there's no return address stored in EPC register,
+the functions will likely crash when returning from the exception handler.
No function. Simply returns with r2=00000000h.
+Reportedly, A(85h) is CdStop, but that seems to be nonsense?
No function. Simply returns without changing any registers or memory locations
+(except that, of course, the exception handler destroys k0).
These are syscalls with invalid function number in R4. For whatever reason that
+is handled by issuing DeliverEvent(F0000010h,4000h). Thereafter, the syscall
+returns to the main program (ie. it doesn't cause a SystemError).
These are used "SystemError" functions. The functions are repeatedly jumping to
+themselves, causing the system to hang. Possibly useful for debugging software
+which may hook that functions.
These are additional "SystemError" functions, but they are never used. The
+functions are repeatedly jumping to themselves, causing the system to hang.
The CPU does not generate any exceptions upon divide overflows, because of
+that, the Kernel code and many games are commonly checking if the divider is
+zero (by software), and, if so, execute a BRK 1C00h opcode. The default BIOS
+exception handler doesn't handle BRK exceptions, and does simply redirect them
+to SystemErrorUnresolvedException().
Copies the three default four-opcode handlers for the A(NNh),B(NNh),C(NNh)
+functions to A00000A0h..A00000CFh.
Copies the default four-opcode exception handler to the exception vector at
+80000080h..8000008Fh, and, for whatever reason, also copies the same opcodes to
+80000000h..8000000Fh.
Initializes the address (A000E000h) and size (2000h) of the allocate-able
+Kernel Memory region, and, seems to deallocate any memory handles which may
+have been allocated via B(00h).
Zerofills all Kernel variables; which are usually at [00007460h..0000891Fh].
+Note: During the boot process, the BIOS accidently overwrites the first opcode
+of this function (by the last word of the A0h table), so, thereafter, this
+function won't work anymore (nor would it be of any use).
Initializes the size and address of the File and Device Control Blocks (FCBs
+and DCBs). Adds the TTY device by calling "KernelRedirect(ttyflag)", and the
+CDROM and Memory Card devices by calling "AddCDROMDevice()" and
+"AddMemCardDevice()".
Copies the B(32h..3Bh) and B(3Ch..3Fh) function addresses to A(00h..09h) and
+A(3Bh..3Eh). Apparently Sony's compiler/linker can't insert the addresses in
+the A0h table directly at compilation time, so this function is used to insert
+them during execution of the boot code.
Below are mainly internally used device related subfunctions.
A(5Bh) dev_tty_init() ;PS2: SystemError
+ A(5Ch) dev_tty_open(fcb,and unused:"path\name",accessmode) ;PS2: SystemError
+ A(5Dh) dev_tty_in_out(fcb,cmd) ;PS2: SystemError
+ A(5Eh) dev_tty_ioctl(fcb,cmd,arg) ;PS2: SystemError
+ A(5Fh) dev_cd_open(fcb,"path\name",accessmode)
+ A(60h) dev_cd_read(fcb,dst,len)
+ A(61h) dev_cd_close(fcb)
+ A(62h) dev_cd_firstfile(fcb,"path\name",direntry)
+ A(63h) dev_cd_nextfile(fcb,direntry)
+ A(64h) dev_cd_chdir(fcb,"path")
+ A(65h) dev_card_open(fcb,"path\name",accessmode)
+ A(66h) dev_card_read(fcb,dst,len)
+ A(67h) dev_card_write(fcb,src,len)
+ A(68h) dev_card_close(fcb)
+ A(69h) dev_card_firstfile(fcb,"path\name",direntry)
+ A(6Ah) dev_card_nextfile(fcb,direntry)
+ A(6Bh) dev_card_erase(fcb,"path\name")
+ A(6Ch) dev_card_undelete(fcb,"path\name")
+ A(6Dh) dev_card_format(fcb)
+ A(6Eh) dev_card_rename(fcb1,"path\name1",fcb2,"path\name2")
+ A(6Fh) ? ;card ;[r4+18h]=00000000h ;card_clear_error(fcb) or so
+ A(96h) AddCDROMDevice()
+ A(97h) AddMemCardDevice()
+ A(98h) AddDuartTtyDevice() ;PS2: SystemError
+ A(99h) add_nullcon_driver()
+ B(47h) AddDrv(device_info) ;subfunction for AddXxxDevice functions
+ B(48h) DelDrv(device_name_lowercase)
+ B(5Bh) ChangeClearPAD(int) ;pad AND card (ie. used also for Card)
+ C(15h) _cdevinput(circ,char)
+ C(16h) _cdevscan()
+ C(17h) _circgetc(circ) ;uses r5 as garbage txt for _ioabort
+ C(18h) _circputc(char,circ)
+Device Names are case-sensitive (usually lowercase, eg. "bu" for memory cards).
+In filenames, the device name may be followed by a hexadecimal 32bit
+non-case-sensitive port number (eg. "bu00:" for selecting the first memory card
+slot). Accordingly, the device name should not end with a hexdigit (eg. "usb:"
+would be treated as device "us" with port number 0Bh).
+Standard device names are "cdrom:", "bu00:", "bu10:", "tty00:". Other,
+nonstandard devices are:
+
Castlevania is trying to access an unknown device named "sim:".
+ Caetla (a firmware replacement for Cheat Devices) supports "pcdrv:" device.
+Below BRK's are internally used in DTL-H2000 BIOS for two devices: "mwin:"
+(Message Window) and "sim:" (CDROM Sim).
Caetla (a firmware replacement for Cheat Devices) supports "pcdrv:" device, the
+SN systems (=what?) device extension to access files on the drive of the pc.
+This fileserver can be accessed by using the kernel functions, with the
+"pcdrv:" device name prefix to the filenames or using the SN system calls.
+The following SN system calls for the fileserver are provided. Accessed by
+setting the registers and using the break command with the specified field.
+The break functions have argument(s) in A1,A2,A3 (ie. unlike normal BIOS
+functions not in A0,A1,A2), and TWO return values (in V0, and V1).
No parameters.
out: V0 0 = success, -1 = failure
+ V1 file handle or error code if V0 is negative
+ bit0 Read only file (R)
+ bit1 Hidden file (H)
+ bit2 System file (S)
+ bit3 Not used (zero)
+ bit4 Directory (D)
+ bit5 Archive file (A)
+ bit6-31 Not used (zero)
+ out: V0 0 = success, -1 = failure
+ V1 file handle or error code if V0 is negative
+ out: V0 0 = success, -1 = failure
+ V1 0 = success, error code if V0 is negative
+ out: V0 0 = success, -1 = failure
+ V1 number of read bytes or error code if V0 is negative.
+ out: V0 0 = success, -1 = failure
+ V1 number of written bytes or error code if V0 is negative.
+seekmode may be from 0=Begin of file, 1=Current fpos, or 2=End of file.
+
out: V0 0 = success, -1 = failure
+ V1 file pointer
+ in: A0 Pointer to 0 terminated string
+ A1,A2,A3,[SP+10h..] Argument(s)
+ c display ASCII character
+ s display ASCII string
+ i,d,D display signed Decimal number (d/i=default32bit, D=force32bit)
+ u,U display unsigned Decimal number (u=default32bit, U=force32bit)
+ o,O display unsigned Octal number (o=default32bit, O=force32bit)
+ p,x,X display unsigned Hex number (p=lower/force32bit, x=lower, X=upper)
+ n write 32bit/16bit string length to [parameter] (default32bit)
+ + or SPC show leading plus or space character in positive signed numbers
+ NNN fixed width (for padding or so) (first digit must be 1..9) (not 0)
+ .NNN fixed width (for clipping or so)
+ * variable width (using one of the parameters) (negative=ending_spc)
+ .* variable width
+ - force ending space padding (in case of width being specified)
+ # show leading "0x" or "0X" (hex), or ensure 1 leading zero (octal)
+ 0 show leading zero's
+ L unknown/no effect?
+ h,l force 16bit (h=halfword), or 32bit (l=long/word)
+ in: R4=address of string (terminated by 00h)
+ in: r4=dst (pointer to a 128-byte buffer) - out: r2=dst (same is incoming r4)
+Reads one character from the TTY console, by internally redirecting to
+"read(0,tempbuf,1)". The returned character is ANDed by 7Fh (so, to read a
+fully intact 8bit character, "read(0,tempbuf,1)" must be used instead of
+this function).
Writes the character to the TTY console, by internally redirecting to
+"write(1,tempbuf,1)". Char 09h (TAB) is expanded to one or more SPC
+characters, until reaching the next tabulation boundary (every 8 characters).
+Char 0Ah (LF) is expanded to 0Dh,0Ah (CR,LF). Other special characters (which
+should be handled at the remote terminal side) are 08h (BS, backspace, move
+cursor one position to the left), and 07h (BELL, produce a short beep sound).
Closes and re-opens the std_in (fd=0) and std_out (fd=1) file handles.
Removes, re-mounts, and flushes the TTY device, the parameter selects whether
+to mount the real DUART-TTY device (r4=1), or a Dummy-TTY device (r4=0), the
+latter one sends any std_out to nowhere. Values other than r4=0 or r4=1 do
+remove the device, but do not re-mount it (which might result in problems).
+Caution: Trying to use r4=1 on a PSX that does not has the DUART hardware
+installed causes the BIOS to hang (so one should first detect the DUART
+hardware, eg. by writing two different bytes to Port 1F802020h.1st/2nd access,
+and the read and verify that two bytes).
The std_io functions can be enabled via C(1Bh) KernelRedirect(ttyflag), the
+BIOS is unable to detect the presence of the TTY hardware, by default the BIOS
+bootcode disables std_io by setting the initial KernelRedirect value at
+[A000B9B0h] to zero, this is hardcoded shortly after the POST(E) output:
+
call output_post_r4 ;\output POST(E)
+ +mov r4,0Eh ;/
+ mov r1,0A0010000h ;\set [0A000B9B0h]=0 ;TTY=dummy/off
+ call reset_cont_d_3 ; and call reset_cont_d_3
+ +mov [r1-4650h],0 ;/
+ mov r1,1h ;\set [0A000B9B0h]=1 ;TTY=duart/on
+ call reset_cont_d_3 ; and call reset_cont_d_3
+ +mov [r28-4650h-0ff0h],r1 ;/
+Uses printf to display the long and short names from the DCB of the currently
+installed devices. Doesn't do anything else. There's no return value.
Several BIOS functions are internally using printf to output status
+information, timeout, and error messages, etc. So, trying to close the TTY file
+handles (fd=0 and fd=1) would cause such functions to work unstable.
In: r4 = 16bit Shift-JIS character code
+ Out: r2 = address in BIOS ROM of the desired character (or -1 = error)
+ In: r4 = 16bit Shift-JIS character code
+ Out: r2 = offset within charset (without charset base address)
+The character sets are located at BFC64000h and up, intermixed with some other
+stuff:
+
BFC64000h Charset 1 (16x15 pix, letters with accent marks) (NOT in JAPAN)
+ BFC65CB6h Garbage (four-and-a-half reverb tables, ioports, printf strings)
+ BFC66000h Charset 2 (16x15 pix, various alphabets, english, greek, etc.)
+ BFC69D68h Charset 3 (16x15 pix, japanese or chinese symbols or so)
+ BFC7F8DEh Charset 4 (8x15 pix, mainly ASCII letters)
+ BFC7FE6Fh Charset 5 (8x15 pix, additional punctuation marks) (NOT in PS2)
+ BFC7FF32h Version (Version and Copyright strings) (NOT in SCPH1000)
+ BFC7FF8Ch Charset 6 (8x15 pix, seven-and-a-half japanese chars) (NOT in PS2)
+ BFC80000h End (End of 512kBYTE BIOS ROM)
+ 00h 4 ptr to first element of exception chain
+ 04h 4 not used (zero)
+ 00h 4 class (events are triggered when class and spec match)
+ 04h 4 status (0=free,1000h=disabled,2000h=enabled/busy,4000h=enabled/ready)
+ 08h 4 spec (events are triggered when class and spec match)
+ 0Ch 4 mode (1000h=execute function/stay busy, 2000h=no func/mark ready)
+ 10h 4 ptr to function to be executed when ready (or 0=none)
+ 14h 8 not used (uninitialized)
+ 00h 4 status (1000h=Free TCB, 4000h=Used TCB)
+ 04h 4 not used (set to 1000h by OpenTh) (not for boot executable?)
+ 08h 80h r0..r31 (entries for r0/zero and r26/k0 are unused)
+ 88h 4 cop0r14/epc (aka r26/k0 and pc when returning from exception)
+ 8Ch 8 hi,lo (the mul/div registers)
+ 94h 4 cop0r12/sr (stored/restored by exception, NOT init by OpenTh)
+ 98h 4 cop0r13/cause (stored when entering exception, NOT restored on exit)
+ 9Ch 24h not used (uninitialized)
+ 00h 4 ptr to TCB of current thread
+ 00h 4 status (0=Free FCB) (nonzero=accessmode)
+ 04h 4 cdrom: disk_id (checksum across path table of the corresponding disk),
+ memory card: port number (00h=slot1, 10h=slot2)
+ 08h 4 transfer address (for dev_in_out function)
+ 0Ch 4 transfer length (for dev_in_out function)
+ 10h 4 current file position
+ 14h 4 device flags (copy of DCB[04h])
+ 18h 4 error ;used by B(55h) - _get_error(fd)
+ 1Ch 4 Pointer to DCB for the file
+ 20h 4 filesize
+ 24h 4 logical block number (start of file) (for cdrom: at least)
+ 28h 4 file control block number (simply 0..15 for FCB number 0..15)
+ 00h 4 ptr to lower-case short name ("cdrom", "bu", "tty") (or 0=Free DCB)
+ 04h 4 device flags (cdrom=14h, bu=14h, tty/dummy=1, tty/duart=3)
+ 08h 4 sector size (cdrom=800h, bu=80h, tty=1)
+ 0Ch 4 ptr to upper-case long name ("CD-ROM", "MEMORY CARD", "CONSOLE")
+ 10h 4 ptr to init() (TTY only)
+ 14h 4 ptr to open(fcb,"path\name",accessmode)
+ 18h 4 ptr to in_out(fcb,cmd) (TTY only)
+ 1Ch 4 ptr to close(fcb)
+ 20h 4 ptr to ioctl(fcb,cmd,arg) (TTY only)
+ 24h 4 ptr to read(fcb,dst,len)
+ 28h 4 ptr to write(fcb,src,len)
+ 2Ch 4 ptr to erase(fcb,"path\name")
+ 30h 4 ptr to undelete(fcb,"path\name")
+ 34h 4 ptr to firstfile2(fcb,"path\name",direntry)
+ 38h 4 ptr to nextfile(fcb,direntry)
+ 3Ch 4 ptr to format(fcb)
+ 40h 4 ptr to cd(fcb,"path") (CDROM only)
+ 44h 4 ptr to rename(fcb1,"path\name1",fcb2,"path\name2")
+ 48h 4 ptr to remove()
+ 4Ch 4 ptr to testdevice(fcb,"path\name")
+For the actual kernel, there seem to be only a few different versions. Most
+PSX/PSone's are containing the version from 1995 (which is kept 1:1 the same in
+all consoles; without any PAL/NTSC related customizations).
+
28-Jul-1994 "DTL-H2000" ;v0.x (pre-retail devboard)
+ 22-Sep-1994 "CEX-1000 KT-3 by S.O." ;v1.0 through v2.0
+ no-new-date "CEX-3000 KT-3 by K.S." ;v2.1 only (old Port 1F801060h)
+ 27-Jul-1995 "Konami OS by T.H." ;Twinkle System
+ 01-Sep-1995 "Konami OS by T.H." ;Konami GV, GQ, System 573
+ 04-Dec-1995 "CEX-3000/1001/1002 by K.S." ;v2.2 through v4.5 (except v4.0)
+ 29-May-1997 "CEX-7000/-7001 by K.S. " ;v4.0 only (new Port 1F801010h)
+ 17-Jan-2000 "PS compatible mode by M.T." ;v5.0 (Playstation 2)
+This portion was updated more often. It's customized for PAL/NTSC displays,
+japanese/english language, and (maybe?) region/licence string checks. The
+SCPH1000 uses uncompressed Bootmenu/Intro code with "\<S>" intro, but
+without "PS" intro (or, "PS" is shown only on region matches?), newer versions
+are using selfdecompressing code, with both intro screens. The GUI in older PSX
+models looks like a drawing program for children, the GUI in newer PSX models
+and in PSone's looks more like a modernized bathroom furniture, unknown how the
+PS2 GUI looks like?
+Games are communicating only with the Kernel, so the differences in the
+Bootmenu/Intro part should have little or effect on compatibility (although
+some I/O ports might be initialized differently, and although some games might
+(accidently) read different (garbage) values from the ROM).
+
Ver CRC32 Used in System ROM Version Kernel
+ 0.xj 18D0F7D8 DTL-H2000 (no version string) dtlh2000
+ 1.0j 3B601FC8 SCPH-1000 and DTL-H1000 (no version string) cex1000
+ 1.1j 3539DEF6 SCPH-3000 and DTL-H1000H "1.1 01/22/95" ""
+ 2.0a 55847D8C DTL-H1001 "2.0 05/07/95 A" ""
+ 2.0e 9BB87C4B SCPH-1002 and DTL-H1002 "2.0 05/10/95 E" ""
+ 2.1j BC190209 SCPH-3500 "2.1 07/17/95 J" cex3000
+ 2.1a AFF00F2F SCPH-1001 and DTL-H1101 "2.1 07/17/95 A" ""
+ 2.1e 86C30531 SCPH-1002 and DTL-H1102 "2.1 07/17/95 E" ""
+ 2.2j 24FC7E17 SCPH-5000 and DTL-H1200 "2.2 12/04/95 J" cex3000/100x
+ 2.2a 37157331 SCPH-1001 and DTL-H1201/3001 "2.2 12/04/95 A" ""
+ 2.2e 1E26792F SCPH-1002 and DTL-H1202/3002 "2.2 12/04/95 E" ""
+ 2.2v 446EC5B2 SCPH-5903 (VCD, 1Mbyte) "2.2 12/04/95 J" ""
+ 2.2d DECB22F5 DTL-H1100 "2.2 03/06/96 D" ""
+ 3.0j FF3EEB8C SCPH-5500 "3.0 09/09/96 J" ""
+ 3.0a 8D8CB7E4 SCPH-5501/7003 "3.0 11/18/96 A" ""
+ 3.0e D786F0B9 SCPH-5502/5552 "3.0 01/06/97 E" ""
+ 4.0j EC541CD0 SCPH-7000/9000 "4.0 08/18/97 J" cex7000
+ 4.1w B7C43DAD SCPH-7000W ...XXX...
+ 4.1a 502224B6 SCPH-7001/7501/7503/9001 "4.1 12/16/97 A" cex3000/100x
+ 4.1e 318178BF SCPH-7002/7502/9002 "4.1 12/16/97 E" ""
+ 4.3j F2AF798B SCPH-100 (PSone) "4.3 03/11/00 J" ""
+ 4.4a 6A0E22A0 SCPH-101 (PSone) "4.4 03/24/00 ..XXX..
+ 4.4e 0BAD7EA9 SCPH-102 (PSone) "4.4 03/24/00 E" ""
+ 4.5a 171BDCEC SCPH-101 (PSone) "4.5 05/25/00 A" ""
+ 4.5e 76B880E5 SCPH-102 (PSone) "4.5 05/25/00 E" ""
+ 5.0t B7EF81A9 SCPH10000 (Playstation 2) "5.0 01/17/00 T" PS compatible
+v2.2j/a/e use exactly the same GUI as v2.1 (only the kernel was changed). v2.2d
+is almost same as v2.2j (but with some GUI patches or so).
+v4.1 and v4.5 use exactly the same GUI code for "A" and "E" regions (the only
+difference is the last byte of the version string; which does specify whether
+the GUI shall use PAL or NTSC).
+v5.0 is playstation 2 bios (4MB) with more or less backwards compatible kernel.
The 16x15 pixel charsets at BFC66000h and BFC69D68h are included in all BIOSes,
+however, the 16x15 portion for letters with accent marks at BFC64000h is
+included only in non-japanese BIOSes, and in some newer japanese BIOSes (not
+included in v4.0j, but they are included in v4.3j).
+The 8x15 pixel charset with characters 21h..7Fh is included in all BIOSes. In
+the SCPH1000, this region is followed by additional 8x15 punctuation marks at
+char 80h and up, however, this region is missing in PS2 BIOS. Moreover, some
+BIOSes include an incomplete 8x15 japanese character set (which ends abruptly
+at BF7FFFFFh), in newer BIOSes, some of theses chars are replaced by the
+version string at BFC7FF32h, and, the remaining 8x15 japanese chars were
+removed in the PS2 BIOS version.
The original PSX Kernel mainly consists of messy and unstable compiler
+generated code, and, to the worst, the \<same> author seems to have
+attempted to use assembler code in some places. In result, most commercial
+games are causing a greater mess by inserting patches in the kernel code...
+Which has been a nasty surprise when making the nocash PSX bios; which
+obviously wasn't compatible with these patches. The only solutions would have
+been to insert hundreds of NOPs to make my bios \<exactly> as bloated as
+the original bios (which I really didn't want to do), or to create
+anti-patch-patches.
As shown below, all known patches are invoked by a B(56h) or B(57h) function
+call. In the nocash PSX bios, these two functions are examining the following
+opcodes, if the opcodes are a known patch, then the BIOS reproduces the desired
+behaviour, and does then continue normal execution after those opcodes. If the
+opcodes are unknown, then the BIOS simply locks up; and shows an error message
+with the address of that opcodes in the TTY window; info about any such unknown
+opcodes would be welcome!
If you want to (or need to) use patches, please use byte-identical opcodes as
+commercial games do (as shown below; only the "xxxx" address digits are don't
+care), so the nocash PSX bios (or other homebrewn BIOSes) can detect and
+reproduce them. Or alternately, don't use the BIOS, and access I/O ports
+directly, which is much better and faster anyways.
In newer Kernel version, the exception handler reads cop0r13/cause to r2,
+examines the Excode value in r2, and if the exception was caused by an
+interrupt, and if the next opcode (at EPC) is a GTE/COP2 command, then it does
+increment EPC by 4. The GTE commands are executed even if an interrupt occurs
+simultaneously, so, without adjusting EPC, the command would be executed twice.
+With some commands that'd just waste some clock cycles, with other commands it
+may cause data to be written twice to the GTE FIFOs, or may re-use the result
+from the 1st command execution as input to the 2nd execution.
+The old "CEX-1000 KT-3" Kernel version did examine r2, but it "forgot" to
+previously load cop0r13 to r2, so it did randomly examine a garbage value. The
+patch inserts the missing opcode, used in elo2 at 80033740h, and in Pandemonium
+II at 8007F3FCh:
+
240A00B0 mov r10,0B0h ;\ 00000000 nop
+ 0140F809 call r10 ; 00000000 nop
+ 24090056 +mov r9,56h ;/ 241A0100 mov k0,100h
+ 3C0Axxxx mov r10,xxxx0000h ;\ 8F5A0008 mov k0,[k0+8h]
+ 3C09xxxx mov r9,xxxx0000h ; 00000000 nop
+ 8C420018 mov r2,[r2+06h*4] ;=C(06h) ; 8F5A0000 mov k0,[k0]
+ 254Axxxx add r10,xxxxh ;=@@new_data ; 00000000 nop
+ 2529xxxx add r9,xxxxh ;=@@new_data_end ;/ 235A0008 addt k0,8h
+ @@copy_lop: ;\ AF410004 mov [k0+4h],r1
+ 8D430000 mov r3,[r10] ; AF420008 mov [k0+8h],r2
+ 254A0004 add r10,4h ; AF43000C mov [k0+0Ch],r3
+ 24420004 add r2,4h ; AF5F007C mov [k0+7Ch],ra
+ 1549FFFC jne r10,r9,@@copy_lop ; 40026800 mov r2,cop0r13
+ AC43FFFC +mov [r2-4h],r3 ;/ 00000000 nop
+ 240A00B0 mov r10,0B0h ;\ 00000000 nop
+ 0140F809 call r10 ; 00000000 nop
+ 24090056 +mov r9,56h ;/ 241A0100 mov k0,100h
+ 3C1Axxxx mov k0,xxxx0000h ;\ 8F5A0008 mov k0,[k0+8h]
+ 3C1Bxxxx mov k1,xxxx0000h ; 00000000 nop
+ 8C420018 mov r2,[r2+06h*4] ;=C(06h) ; 8F5A0000 mov k0,[k0]
+ 275Axxxx add k0,xxxxh ;=@@new_data ; 00000000 nop
+ 277Bxxxx add k1,xxxxh ;=@@new_data_end ;/ 235A0008 addt k0,8h
+ @@copy_lop: ;\ AF410004 mov [k0+4h],r1
+ 8F430000 mov r3,[k0] ; AF420008 mov [k0+8h],r2
+ 275A0004 add k0,4h ; AF43000C mov [k0+0Ch],r3
+ 24420004 add r2,4h ; AF5F007C mov [k0+7Ch],ra
+ 175BFFFC jne k0,k1,@@copy_lop ; 40026800 mov r2,cop0r13
+ AC43FFFC +mov [r2-4h],r3 ;/ 00000000 nop
+ 24090056 mov r9,56h ;\
+ 240A00B0 mov r10,0B0h ; B(56h) GetC0Table
+ 0140F809 call r10 ;
+ 00000000 +nop ;/
+ 8C420018 mov r2,[r2+06h*4] ;=00000C80h = exception_handler = C(06h)
+ 00000000 nop
+ 24420028 add r2,28h
+ 00407821 mov r15,r2
+ 3C0Axxxx lui r10,xxxxh ;\@@ori_data ;\
+ 254Axxxx add r10,xxxxh ;/ ;
+ 3C09xxxx lui r9,xxxxh ;\@@ori_data_end ; @@ori_data:
+ 2529xxxx add r9,xxxxh ;/ ; AF410004 mov [k0+4h],r1
+ @@verify_lop: ; AF420008 mov [k0+8h],r2
+ 8D430000 mov r3,[r10] ; AF43000C mov [k0+0Ch],r3
+ 8C4B0000 mov r11,[r2] ; AF5F007C mov [k0+7Ch],ra
+ 254A0004 add r10,4h ; 40037000 mov r3,cop0r14
+ 146B000E jne r3,r11,@@verify_mismatch ; 00000000 nop
+ 24420004 +add r2,4h ;
+ 1549FFFA jne r10,r9,@@verify_lop ;
+ 00000000 +nop ;/
+ 01E01021 mov r2,r15
+ 3C0Axxxx lui r10,xxxxh ;\@@new_data ;\
+ 254Axxxx add r10,xxxxh ;/ ;
+ 3C09xxxx lui r9,xxxxh ;\@@new_data_end ; @@new_data:
+ 2529xxxx add r9,xxxxh ;/ ; AF410004 mov [k0+4h],r1
+ @@copy_lop: ; AF420008 mov [k0+8h],r2
+ 8D430000 mov r3,[r10] ; 40026800 mov r2,cop0r13
+ 00000000 nop ; AF43000C mov [k0+0Ch],r3
+ AC430000 mov [r2],r3 ; 40037000 mov r3,cop0r14
+ 254A0004 add r10,4h ; AF5F007C mov [k0+7Ch],ra
+ 1549FFFB jne r10,r9,@@copy_lop ;
+ 24420004 +add r2,4h ;/
+ @@verify_mismatch:
+ ;BUG1: 8bit "movb r6" should be 32bit "mov r6"
+ ;BUG2: @@copy_lop should transfer 6 words (not 7 words)
+ ;BUG3: and, asides, the minimum demo works only with PAL BIOS (not NTSC)
+ 0xxxxxxx call xxxxxxxxh ;\B(56h) GetC0Table
+ 00000000 +nop ;/(mov r8,0B0h, jmp r8, +mov r9,56h)
+ 3C04xxxx mov r4,xxxx0000h ;\@@ori_data
+ 2484xxxx add r4,xxxxh ;/
+ 90460018 movb r6,[r2+06h*4] ;BUG1 ;exception_handler = C(06h)
+ 24870018 add r7,r4,18h ;@@ori_end ;\
+ 24C50028 add r5,r6,28h ;C(06h)+28h ;
+ 00A03021 mov r6,r5 ; @@ori_data:
+ @@verify_lop: ; 80086520 AF410004 mov [k0+4h],r1
+ 8CA30000 mov r3,[r5] ; 80086524 AF420008 mov [k0+8h],r2
+ 8C820000 mov r2,[r4] ; 80086528 AF43000C mov [k0+0Ch],r3
+ 00000000 nop ; 8008652C AF5F007C mov [k0+7Ch],ra
+ 1462000C jne r3,r2,@@verify_mismatch ; 80086530 40037000 mov r3,cop0r14
+ 24840004 +add r4,4h ; 80086534 00000000 nop
+ 1487FFFA jne r4,r7,@@verify_lop ; @@ori_end:
+ 24A50004 +add r5,4h ;/
+ 00C02821 mov r5,r6 ;\ @@new_data:
+ 3C04xxxx mov r4,xxxx0000h ;\@@new_data; 80086538 AF410004 mov [k0+4h],r1
+ 2484xxxx add r4,xxxxh ;/ ; 8008653C AF420008 mov [k0+8h],r2
+ 2483001C add r3,r4,1Ch ;@@bugged_end ; 80086540 40026800 mov r2,cop0r13
+ @@copy_lop: ; 80086544 AF43000C mov [k0+0Ch],r3
+ 8C820000 mov r2,[r4] ; 80086548 40037000 mov r3,cop0r14
+ 24840004 add r4,4h ; 8008654C AF5F007C mov [k0+7Ch],ra
+ ACA20000 mov [r5],r2 ; @@new_end:
+ 1483FFFC jne r4,r3,@@copy_lop ; 80086550 00000000 nop ;BUG2
+ 24A50004 +add r5,4h ;/ @@bugged_end:
+ @@verify_mismatch:
+Because of a hardware glitch the card IRQ cannot be acknowledged while the
+external IRQ signal is still LOW, making it neccessary to insert a delay that
+waits until the signal gets HIGH before acknowledging the IRQ.
+The original BIOS is so inefficient that it takes hundreds of clock cycles
+between the interrupt request and the IRQ acknowledge, so, normally, it doesn't
+require an additional delay.
+However, the central mistake in the IRQ handler is that it doesn't memorize
+which IRQ has originally triggered the interrupt. For example, it may get
+triggered by a timer IRQ, but a newer card IRQ may occur during IRQ handling,
+in that case, the card IRQ may get processed and acknowledged without the
+required delay.
+Used in Metal Gear Solid at 8009AA5Ch, and in alone1 at 800AE2F8h:
+
24090056 mov r9,56h ;\ ; @@new_data:
+ 240A00B0 mov r10,0B0h ; B(56h) GetC0Table ;3C02A001 lui r2,0A001h
+ 0140F809 call r10 ; ;2442DFAC sub r2,2054h
+ 00000000 +nop ;/ ;00400008 jmp r2 ;=@@new_cont_d
+ 8C420018 mov r2,[r2+06h*4] ;\get C(06h) ;00000000 +nop ;=A000DFACh
+ 00000000 nop ;/ ;00000000 nop
+ 8C430070 mov r3,[r2+70h] ;\ ; @@new_data_end:
+ 00000000 nop ; get ; @@new_cont_d:
+ 3069FFFF and r9,r3,0FFFFh ; early_card ;8C621074 mov r2,[r3+1074h]
+ 00094C00 shl r9,10h ; irq_handler ;00000000 nop
+ 8C430074 mov r3,[r2+74h] ; ;30420080 and r2,80h ;I_STAT.7
+ 00000000 nop ; ;1040000B jz r2,@@ret
+ 306AFFFF and r10,r3,0FFFFh ;/ ;00000000 +nop
+ 012A1821 add r3,r9,r10 ; @@wait_lop:
+ 24620028 add r2,r3,28h ;=early+28h ;8C621044 mov r2,[r3+1044h]
+ 3C0Axxxx lui r10,xxxxh ;\@@new_data ;00000000 nop
+ 254Axxxx sub r10,xxxxh ;/ ;30420080 and r2,80h ;JOY_STAT.7
+ 3C09xxxx lui r9,xxxxh ;\@@new_data_end ;1440FFFC jnz r2,@@wait_lop
+ 2529xxxx sub r9,xxxxh ;/ ;00000000 +nop
+ @@copy_lop: ;3C020001 lui r2,0001h
+ 8D430000 mov r3,[r10] ;8C42DFFC mov r2,[r2-2004h]
+ 00000000 nop ;00000000 nop
+ AC430000 mov [r2],r3 ;00400008 jmp r2 ;=[0000DFFCh]
+ 254A0004 add r10,4h ;00000000 +nop
+ 1549FFFB jne r10,r9,@@copy_lop ; @@ret:
+ 24420004 +add r2,4h ;03E00008 ret
+ 3C010001 lui r1,0001h ;\[DFFCh]=r2 ;00000000 +nop
+ 0xxxxxxx call xxxxxxxxh ; and call ... ;
+ AC22DFFC +mov [r1-2004h],r2 ;/ ;
+ 240A00B0 mov r10,0B0h ;\ ; @@new_data:
+ 0140F809 call r10 ; B(56h) GetC0Table ;3C02xxxx lui r2,8xxxh
+ 24090056 +mov r9,56h ;/ ;2442xxxx sub r2,xxxxh
+ 8C420018 mov r2,[r2+06h*4] ;\get C(06h) ;00400008 jmp r2 ;=@@new_cont_d
+ 00000000 nop ;/ ;00000000 +nop ;=8xxxxxxxh
+ 8C430070 mov r3,[r2+70h] ;\ ;00000000 nop
+ 00000000 nop ; get ; @@new_data_end:
+ 3069FFFF and r9,r3,0FFFFh ; early_card ; @@new_cont_d:
+ 8C430074 mov r3,[r2+74h] ; irq_handler ;8C621074 mov r2,[r3+1074h]
+ 00094C00 shl r9,10h ; ;00000000 nop
+ 306AFFFF and r10,r3,0FFFFh ; ;30420080 and r2,80h ;I_STAT.7
+ 012A1821 add r3,r9,r10 ;/ ;1040000B jz r2,@@ret
+ 3C0Axxxx mov r10,xxxx0000h ;00000000 +nop
+ 3C09xxxx mov r9,xxxx0000h ; @@wait_lop:
+ 24620028 add r2,r3,28h ;=early+28h ;8C621044 mov r2,[r3+1044h]
+ 254Axxxx sub r10,xxxxh ;=@@new_data ;00000000 nop
+ 2529xxxx sub r9,xxxxh ;=@@new_data_end ;30420080 and r2,80h ;JOY_STAT.7
+ @@copy_lop: ;1440FFFC jnz r2,@@wait_lop
+ 8D430000 mov r3,[r10] ;00000000 +nop
+ 254A0004 add r10,4h ;3C02xxxx lui r2,8xxxh
+ 24420004 add r2,4h ;8C42xxxx mov r2,[r2-xxxxh]
+ 1549FFFC jne r10,r9,@@copy_lop ;00000000 nop
+ AC43FFFC +mov [r2-4h],r3 ;00400008 jmp r2 ;=[8xxxxxxxh]
+ 3C018xxx mov r1,8xxx0000h ;\[...]=r2, ;00000000 +nop
+ 0xxxxxxx call xxxxxxxxh ; and call ... ; @@ret:
+ AC22xxxx +mov [r1+xxxxh],r2 ;/ ;03E00008 ret
+ ... ;00000000 +nop
+Used to uninstall the "early_card_irq_vector" (the BIOS installs that vector
+from inside of B(4Ah) InitCARD2(pad_enable), and, without patches, the BIOS
+doesn't allow to uninstall it thereafter).
+Used in Breath of Fire III (SLES-01304) at 8017E790, and also in Ace Combat 2
+(SLUS-00404) at 801D23F4:
+
240A00B0 mov r10,0B0h ;\
+ 0140F809 call r10 ; B(56h) GetC0Table
+ 24090056 +mov r9,56h ;/
+ 3C0Axxxx mov r10,xxxx0000h
+ 3C09xxxx mov r9,xxxx0000h
+ 8C420018 mov r2,[r2+06h*4] ;=00000C80h = exception_handler = C(06h)
+ 254Axxxx add r10,xxxxh ;@@new_data
+ 2529xxxx add r9,xxxxh ;@@new_data_end
+ @@copy_lop: ;\ @@new_data:
+ 8D430000 mov r3,[r10] ; 00000000 nop
+ 254A0004 add r10,4h ; 00000000 nop
+ 24420004 add r2,4h ; 00000000 nop
+ 1549FFFC jne r10,r9,@@copy_lop ; @@new_data_end:
+ AC43006C +mov [r2+70h-4],r3 ;/
+ 24090056 mov r9,56h ;\
+ 240A00B0 mov r10,0B0h ; B(56h) GetC0Table
+ 0140F809 call r10 ;
+ 00000000 +nop ;/
+ 8C420018 mov r2,[r2+06h*4] ;=00000C80h = exception_handler = C(06h)
+ 3C0Axxxx mov r10,xxxx0000h ;\@@new_data
+ 254Axxxx add r10,xxxxh ;/
+ 3C09xxxx mov r9,xxxx0000h ;\@@new_data_end
+ 2529xxxx add r9,xxxxh ;/
+ @@copy_lop: ;\
+ 8D430000 mov r3,[r10] ; @@new_data:
+ 00000000 nop ; 00000000 nop
+ AC430070 mov [r2+70h],r3 ; 00000000 nop
+ 254A0004 add r10,4h ;src ; 00000000 nop
+ 1549FFFB jne r10,r9,@@copy_lop ; @@new_data_end:
+ 24420004 +add r2,4h ;dst ;/
+Same purpose as the "early_card_irq_patch" (but for the command/status bytes
+rather than for the data bytes). The patch looks buggy since it inserts the
+delay AFTER the acknowledge, but it DOES work (the BIOS accidently acknowledges
+the IRQ twice; and the delay occurs PRIOR to 2nd acknowledge).
+Used in Metal Gear Solid at 8009AAF0h, and in Legacy of Kain at 801A56D8h, and
+in alone1 at 800AE38Ch:
+
24090057 mov r9,57h ;\ ; @@new_data:
+ 240A00B0 mov r10,0B0h ; B(57h) GetB0Table ; 3C08A001 lui r8,0A001h
+ 0140F809 call r10 ;/ ; 2508DF80 sub r8,2080h
+ 00000000 +nop ; 0100F809 call r8 ;=A000DF80h
+ 8C42016C mov r2,[r2+5Bh*4] ;B(5Bh) ; 00000000 +nop
+ 00000000 nop ; 00000000 nop
+ 8C4309C8 mov r3,[r2+9C8h] ;blah ; @@new_data_end:
+ 3C0Axxxx lui r10,xxxxh ;\@@new_data ; 946F000A movh r15,[r3+0Ah]
+ 254Axxxx sub r10,xxxxh ;/ ; 3C080000 mov r8,0h
+ 3C09xxxx lui r9,xxxxh ;\@@new_data_end ; 01E2C025 or r24,r15,r2
+ 2529xxxx sub r9,xxxxh ;/ ; 37190012 or r25,r24,12h
+ @@copy_lop: ; A479000A movh [r3+0Ah],r25
+ 8D480000 mov r8,[r10] ; 24080028 mov r8,28h
+ 00000000 nop ; @@wait_lop:
+ AC4809C8 mov [r2+9C8h],r8 ;B(5Bh)+9C8h.. ; 2508FFFF sub r8,1h
+ 254A0004 add r10,4h ; 1500FFFE jnz r8,@@wait_lop
+ 1549FFFB jne r10,r9,@@copy_lop ; 00000000 +nop
+ 24420004 +add r2,4h ; 03E00008 ret ;above delay is
+ ... ; 00000000 +nop ;in UNCACHED RAM
+ 240A00B0 mov r10,0B0h ;\ ; @@swap_begin:
+ 0140F809 call r10 ; B(57h) GetB0Table ; 3C088xxx lui r8,8xxxh
+ 24090057 +mov r9,57h ;/ ; 2508xxxx sub r8,xxxxh
+ 8C42016C mov r2,[r2+5Bh*4] ;B(5Bh) ; 0100F809 call r8 ;=8xxxxxxxh
+ 3C0Axxxx mov r10,xxxx0000h ; 00000000 +nop
+ 3C09xxxx mov r9,xxxx0000h ; 00000000 nop
+ 8C4309C8 mov r3,[r2+9C8h] ;blah ; @@swap_end:
+ 254Axxxx sub r10,xxxxh ;=@@swap_begin ; ;- - -
+ 2529xxxx sub r9,xxxxh ;=@@swap_end ; 00000000 nop
+ @@swap_lop: ; 240800C8 mov r8,0C8h
+ 8C4309C8 mov r3,[r2+9C8h] ;B(5Bh)+9C8h.. ; @@wait_lop:
+ 8D480000 mov r8,[r10] ; 2508FFFF sub r8,1h
+ 254A0004 add r10,4h ; 1500FFFE jnz r8,@@wait_lop
+ AD43FFFC mov [r10-4h],r3 ; 00000000 +nop
+ 24420004 add r2,4h ; 03E00008 ret ;above delay is
+ 1549FFFA jne r10,r9,@@swap_lop ; 00000000 +nop ;in CACHED RAM
+ AC4809C4 +mov [r2+9C4h],r8 ;
+The "card_info" function sends an incomplete read command to the card; in order
+to receive status information. After receiving the last byte, the function does
+accidently send a further byte to the card, so the card responds by another
+byte (and another IRQ7), which is not processed nor acknowledged by the BIOS.
+This patch kills the opcode that sends the extra byte.
+Used in alone1 at 800AE214h:
+
24090057 mov r9,57h ;\
+ 240A00B0 mov r10,0B0h ; B(57h) GetB0Table
+ 0140F809 call r10 ;
+ 00000000 +nop ;/
+ 240A0009 mov r10,9h ;=blah
+ 8C42016C mov r2,[r2+5Bh*4] ;=B(5Bh)
+ 00000000 nop
+ 20431988 addt r3,r2,1988h ;=B(5Bh)+1988h ;\store a NOP,
+ 0xxxxxxx call xxxxxxxxh ; and call ...
+ AC600000 +mov [r3],0 ;=nop ;/
+If a transmission error occurs (or if there's no controller connected), then
+the Pad handler handler does usually issue a strange chip select signal to the
+OTHER controller slot, and does then execute the bizarre_pad_delay function.
+The patch below overwrites that behaviour by NOPs. Purpose of the original (and
+patched) behaviour is unknown.
+Used by Perfect Assassin at 800519D4h:
+
240A00B0 mov r10,0B0h ;\
+ 0140F809 call r10 ; B(57h) GetB0Table
+ 24090057 +mov r9,57h ;/
+ 8C42016C mov r2,[r2+5Bh*4] ;=B(5Bh)
+ 3C01xxxx mov r1,xxxx0000h
+ 20430884 addt r3,r2,884h ;B(5Bh)+884h
+ AC23xxxx mov [r1+xxxxh],r3 ;<--- SetPadEnableFlag()
+ 3C01xxxx mov r1,xxxx0000h
+ 20430894 addt r3,r2,894h ;B(5Bh)+894h
+ 2409000B mov r9,0Bh ;len
+ AC23xxxx mov [r1+xxxxh],r3 ;<--- ClearPadEnableFlag()
+ @@fill_lop: ;\
+ 2529FFFF sub r9,1h ;
+ AC400594 mov [r2+594h],0 ;B(5Bh)+594h.. ; erase error handling
+ 1520FFFD jnz r9,@@fill_lop ;
+ 24420004 +add r2,4h ;/
+ 24090057 mov r9,57h ;\
+ 240A00B0 mov r10,0B0h ; B(57h) GetB0Table
+ 0140F809 call r10 ;
+ 00000000 +nop ;/
+ 8C42016C mov r2,[r2+5Bh*4]
+ 2409000B mov r9,0Bh ;len
+ 20430884 addt r3,r2,884h
+ 3C01xxxx mov r1,xxxx0000h
+ AC23xxxx mov [r1+xxxxh],r3 ;<--- SetPadEnableFlag()
+ 20430894 addt r3,r2,894h
+ 3C01xxxx mov r1,xxxx0000h
+ AC23xxxx mov [r1+xxxxh],r3 ;<--- ClearPadEnableFlag()
+ @@fill_lop: ;\
+ AC400594 mov [r2+594h],0 ;
+ 24420004 add r2,4h ; erase error handling
+ 2529FFFF sub r9,1h ;
+ 1520FFFC jnz r9,@@fill_lop ;
+ 00000000 +nop ;/
+ 240A00B0 mov r10,0B0h ;\
+ 0140F809 call r10 ; B(57h) GetB0Table
+ 24090057 +mov r9,57h ;/
+ 8C42016C mov r2,[r2+5Bh*4] ;=B(5Bh)
+ 2409000B mov r9,0Bh ;len ;\
+ @@fill_lop: ;
+ 2529FFFF sub r9,1h ; erase error handling
+ AC400594 mov [r2+594h],0 ;B(5Bh)+594h.. ;
+ 1520FFFD jnz r9,@@fill_lop ;
+ 24420004 +add r2,4h ;/
+The normal BIOS functions are only allowing to READ from the controllers, but
+not to SEND data to them (which would be required to control Rumble motors, and
+to auto-activate Analog mode without needing the user to press the Analog
+button). Internally, the BIOS does include some code for sending data to the
+controller, but it doesn't offer a function vector for setting up the data
+source address, and, even if that would be supported, it clips the data bytes
+to 00h or 01h. The patch below retrieves the required SetPadOutput function
+address (in which only the src1/src2 addresses are relevant, the blah1/blah2
+values aren't used), and suppresses clipping (ie. allows to send any bytes in
+range 00h..FFh).
+Used in Resident Evil 2 at 80091914h:
+
240A00B0 mov r10,0B0h ;\
+ 0140F809 call r10 ; B(57h) GetB0Table
+ 24090057 +mov r9,57h ;/
+ 8C42016C mov r2,[r2+5Bh*4] ;B(5Bh)
+ 3C0Axxxx mov r10,xxxx0000h
+ 3C09xxxx mov r9,xxxx0000h
+ 3C01xxxx mov r1,xxxx0000h
+ 204307A0 addt r3,r2,7A0h ;B(5Bh)+7A0h
+ 254Axxxx add r10,xxxxh ;=@@new_data
+ 2529xxxx add r9,xxxxh ;=@@new_data_end
+ AC23xxxx mov [r1-xxxxh],r3 ;<--- SetPadOutput(src1,blah1,src2,blah2)
+ @@double_copy_lop: ;\
+ 8D430000 mov r3,[r10] ; @@new_data:
+ 254A0004 add r10,4h ; 00551024 and r2,r21
+ AC4303D8 mov [r2+3D8h],r3 ;<--- here ; 00000000 nop
+ 24420004 add r2,4h ; 00000000 nop
+ 1549FFFB jne r10,r9,@@double_copy_lop ; 00000000 nop
+ AC4304DC +mov [r2+4DCh],r3 ;<--- here ;/ @@new_data_end:
+ 24090057 mov r9,57h ;\
+ 240A00B0 mov r10,0B0h ; B(57h) GetB0Table
+ 0140F809 call r10 ;
+ 00000000 +nop ;/
+ 3C0Axxxx mov r10,xxxx0000h
+ 254Axxxx add r10,xxxxh ;=@@new_data
+ 3C09xxxx movp r9,xxxx0000h
+ 2529xxxx add r9,xxxxh ;=@@new_data_end
+ 8C42016C mov r2,[r2+5Bh*4] ;B(5Bh)
+ 00000000 nop
+ 204307A0 addt r3,r2,7A0h ;B(5Bh)+7A0h
+ 3C01xxxx mov r1,xxxx0000h
+ AC23xxxx mov [r1+xxxxh],r3 ;<--- SetPadOutput(src1,blah1,src2,blah2)
+ @@double_copy_lop: ;\
+ 8D430000 mov r3,[r10] ; @@new_data:
+ 00000000 nop ; 00551024 and r2,r21
+ AC4303D8 mov [r2+3D8h],r3 ; 00000000 nop
+ AC4304E0 mov [r2+4E0h],r3 ; 00000000 nop
+ 24420004 add r2,4h ; 00000000 nop
+ 254A0004 add r10,4h ; @@new_data_end:
+ 1549FFF9 jne r10,r9,@@double_copy_lop ;
+ 00000000 +nop ;/
+This patch suppresses automatic IRQ0 (vblank) acknowleding in the Pad/Card IRQ
+handler, that, even if auto-ack is enabled. Obviously, one could as well
+disable auto-ack via B(5Bh) ChangeClearPAD(int), so this patch is total
+nonsense. Used in Resident Evil 2 at 800919ACh:
+
240A00B0 mov r10,0B0h ;\
+ 0140F809 call r10 ; B(57h) GetB0Table
+ 24090057 +mov r9,57h ;/
+ 8C42016C mov r2,[r2+5Bh*4] ;=B(5Bh)
+ 240A0009 mov r10,9h ;len ;\
+ 2043062C addt r3,r2,62Ch ;=B(5Bh)+62Ch ;
+ @@fill_lop: ;
+ 254AFFFF sub r10,1h ;
+ AC600000 mov [r3],0 ;
+ 1540FFFD jnz r10,@@fill_lop ;
+ 24630004 +add r3,4h ;/
+ 24090057 mov r9,57h ;\
+ 240A00B0 mov r10,0B0h ; B(57h) GetB0Table
+ 0140F809 call r10 ;
+ 00000000 +nop ;/
+ 240A0009 mov r10,9h ;len
+ 8C42016C mov r2,[r2+5Bh*4]
+ 00000000 nop
+ 2043062C addt r3,r2,62Ch
+ @@fill_lop: ;\
+ AC600000 mov [r3],0 ;
+ 24630004 add r3,4h ;
+ 254AFFFF sub r10,1h ;
+ 1540FFFC jnz r10,@@fill_lop ;
+ 00000000 +nop ;/
+Used in Sporting Clays at 80027D68h (when Konami Lightgun connected):
+
240A00B0 mov r10,0B0h ;\
+ 0140F809 call r10 ; B(56h) GetC0Table
+ 24090056 +mov r9,56h ;/
+ 3C0Axxxx mov r10,xxxx0000h ;src
+ 3C09xxxx mov r9,xxxx0000h ;src.end
+ 8C420018 mov r2,[r2+06h*4] ;C(06h)
+ 254Axxxx add r10,xxxxh ;src
+ 2529xxxx add r9,xxxxh ;src.end (=src+10h)
+ @@copy_lop: ;\ ; @@src:
+ 8D430000 mov r3,[r10] ; ;3C02xxxx mov r2,xxxx0000h
+ 254A0004 add r10,4h ; ;2442xxxx add r2,xxxxh
+ 24420004 add r2,4h ; ;0040F809 call r2 ;lightgun_proc
+ 1549FFFC jne r10,r9,@@copy_lop ; ;00000000 +nop
+ AC43007C +mov [r2+80h-4],r3 ;/ @@src_end:
+ 24090056 mov r9,56h ;\
+ 240A00B0 mov r10,0B0h ; B(56h) GetC0Table
+ 0140F809 call r10 ;
+ 00000000 +nop ;/
+ 8C420018 mov r2,[r2+06h*4] ;=00000C80h = exception_handler = C(06h)
+ 3C0Axxxx mov r10,xxxx0000h ;\@@new_data (3xNOP)
+ 254Axxxx add r10,-xxxxh ;/
+ 3C09xxxx mov r9,xxxx0000h ;\@@new_data_end
+ 2529xxxx add r9,-xxxxh ;/
+ @@copy_lop: ;\
+ 8D430000 mov r3,[r10] ; @@new_data: ;for (un-)install...
+ 00000000 nop ; 00000000 nop / 3C02xxxx mov r2,xxxx0000h
+ AC430080 mov [r2+80h],r3 ; 00000000 nop / 2442xxxx add r2,-xxxxh
+ 254A0004 add r10,4h ; 00000000 nop / 0040F809 call r2 ;proc
+ 1549FFFB jne r10,r9,@@copy_lop ; @@new_data_end:
+ 24420004 +add r2,4h ;/
+Used in Spec Ops Airborne Commando at 80070AE8h, and also in the homebrew game
+Roll Boss Rush at 80010B68h and 8001B85Ch. Purpose is unknown (maybe to
+override improperly defined .EXE headers).
+
8C030474 mov r3,[200h+(9Dh*4)] ;\get ptr to A(9Dh) GetConf (done so,
+ 00000000 nop ;/as there's no "GetA0Table" funtion)
+ 94620000 movh r2,[r3+0h] ;lui msw ;\
+ 84630004 movhs r3,[r3+4h] ;lw lsw+8 ; extract ptr to "boot_cnf_values"
+ 00021400 shl r2,10h ;msw*10000h ; (from first 2 opcodes of GetConf)
+ 2442FFF8 sub r2,8h ;undo +8 ;
+ 00431021 add r2,r3 ;lsw ;/
+ AC450000 mov [r2+0h],r5 ;num_TCB ;\set num_EvCB,num_TCB,stacktop
+ AC440004 mov [r2+4h],r4 ;num_EvCB ; (unlike A(9Ch) SetConf, without
+ 03E00008 ret ; actually reallocting anything)
+ AC460008 +mov [r2+8h],r6 ;stacktop ;/
+CAETLA detects the PSX BIOS version by checksumming BFC06000h..BFC07FFFh and
+does then use some hardcoded BIOS addresses based on that checksum. The reason
+for doing that is probably that the Pre-Boot Expansion ROM vector is called
+with the normal A0h/B0h/C0h vectors being still uninitialized.
+Problems are that the hardcoded addresses won't work with all BIOSes (eg. not
+with the no$psx bios clone, probably also not with the newer PS2 BIOS),
+moreover, the checksumming can fail with patched original BIOSes (eg. no$psx
+allows to enable TTY debug messages and to skip the BIOS intro).
+The Cheat Firmwares are probably also hooking the Vblank handler, and maybe
+also some other functions.
+ACTION REPLAY (at least later versions like 2.81) uses the Pre-Boot handler to
+set a COP0 hardware breakpoint at 80030000h and does then resume normal BIOS
+booting (which will then initialize important things like A0h/B0h/C0h tables,
+and will then break when starting the GUI code at 80030000h).
+XPLORER searches opcode 24040385h at BFC06000h and up, and does then place a
+COP0 opcode fetch breakpoint at the opcode address+10h (note: this is within a
+branch delay slot, which makes COP0 emulation twice as complicated). XPLORER
+does also require space in unused BIOS RAM addresses (eg. Xplorer v3.20: addr
+7880h at 1F002280h, addr 017Fh at 1F006A58h).
Most games include two or three patches. The only game that I've seen so far
+that does NOT use any patches is Wipeout 2097.
The System 573 is a PlayStation-based system used in a number of Konami arcade +games from the late 90s and early 2000s, most notably Dance Dance Revolution and +other titles from the Bemani series of rhythm games.
+This document is currently work-in-progress. Here is an incomplete list of +things that need more research:
+/CE1 and /CE2 are tied together, even
+ though the CPU actually exposes them as separate signals!), have no DMA and
+ don't expose the PCMCIA I/O and configuration space (/IORD and /IOWR are
+ not connected at all). This makes them incompatible with CF cards and most
+ PCMCIA devices.All standard PS1 registers, with the exception of the CD-ROM drive's, are
+present and accessible. System 573-specific hardware is mapped into the EXP1
+region at 0x1f000000. IRQ10 and DMA5, normally reserved for the expansion bus
+(and lightguns) on a regular PS1, are used to access the ATAPI drive, while IRQ2
+and DMA3 go unused.
NOTE: EXP1 must be configured prior to accessing any of these registers. The
+configuration value written by Konami's code to the EXP1 delay/size register at
+0x1f801008 is 0x24173f47. Afterwards, all bus writes shall be 16 or 32
+bits wide. The behavior of 8-bit writes is undefined, but 8-bit reads work as
+intended.
| Address range | +Description | +
|---|---|
0x1f000000-0x1f3fffff |
+Bank switched, can be mapped to flash or PCMCIA slots | +
0x1f400000-0x1f40000f |
+Konami ASIC registers | +
0x1f480000-0x1f48000f |
+IDE register bank 0 | +
0x1f4c0000-0x1f4c000f |
+IDE register bank 1 | +
0x1f620000-0x1f623fff |
+RTC registers and battery-backed RAM | +
0x1f640000-0x1f6400ff |
+I/O board registers | +
0x1f500000-0x1f6a0001 |
+Other registers | +
Registers in the 0x1f400000-0x1f40000f region are handled by the Konami 056879
+I/O ASIC, consisting of a single 8-bit output port and at least six 16-bit input
+ports. The same chip was used in other Konami arcade boards of the time.
0x1f400000 (ASIC register 0): ADC / Coin counters / Audio control| Bits | +RW | +Description | +
|---|---|---|
| 0 | +W | +Data input to ADC (DI) |
+
| 1 | +W | +Chip select to ADC (/CS) |
+
| 2 | +W | +Data clock to ADC (CLK) |
+
| 3 | +W | +Coin counter 1 (1 = energize counter coil) | +
| 4 | +W | +Coin counter 2 (1 = energize counter coil) | +
| 5 | +W | +Built-in audio amplifier enable (0 = muted) | +
| 6 | +W | +External audio input enable (0 = muted) | +
| 7 | +W | +SPU DAC output enable (0 = muted) | +
| 8 | +W | +JVS MCU reset output (0 = pull reset low) | +
| 9-15 | ++ | Unused | +
The ADC chip is an ADC0834 from TI, which uses a proprietary SPI-like protocol.
+Its four inputs are wired to the ANALOG connector on the 573 motherboard.
+Refer to the ADC083x datasheet for details on how to bitbang the protocol.
Mechanical coin counters are incremented by games whenever a coin is inserted by +setting bit 3 or 4 for a fraction of a second and then clearing them. Bit 5 +controls whether the onboard audio amp is enabled but does not affect the RCA +line level outputs, which are always enabled. Setting bit 5 has no effect +immediately as the amplifier takes about a second to turn on.
+Bit 6 is used by games to mute audio from the CD-ROM drive or digital I/O board. +However, testing on real hardware seems to suggest it is actually some sort of +attenuation control, as the audio is still audible (albeit at a very low volume) +when the bit is cleared. Note that some games, such as GuitarFreaks, break the +CD/MP3 output to separate jacks on the front I/O panel rather than routing it +through the motherboard, making bit 6 meaningless.
+Bit 8 resets the JVS MCU. Since the reset pin is active-low, resetting is done
+by writing 0, waiting at least 10 H8 clock cycles (the BIOS waits 2 hblanks)
+and writing 1 again. Resetting the MCU will clear JVSDRDY but not JVSIRDY.
+As the 056879 ASIC's output register is only 8 bits wide, bit 8 is actually
+handled by a discrete flip-flop on the motherboard.
Unknown what reading from this port does.
+0x1f400004 (ASIC register 2): DIP switches / JVS status / Security cartridge| Bits | +RW | +Description | +
|---|---|---|
| 0-3 | +R | +DIP switch 1-4 status (0 = on, 1 = off) | +
| 4-5 | +R | +Current JVS MCU status code | +
| 6-7 | +R | +Current JVS MCU error code | +
| 8-15 | +R | +I0-I7 from security cartridge |
+
The MCU status code can be one of the following values:
+| Code | +Description | +
|---|---|
| 0 | +Waiting for the 573 to read or write the first word of a packet | +
| 1 | +Busy (sending a packet or waiting for a response) | +
| 2 | +Waiting for the 573 to finish reading or writing a packet | +
| 3 | +Unused | +
The MCU error code can be one of the following values:
+| Code | +Description | +
|---|---|
| 0 | +Unused | +
| 1 | +Packet written by the 573 has an invalid checksum | +
| 2 | +Packet written by the 573 does not start with a 0xe0 sync byte |
+
| 3 | +No error | +
Once an error is reported, the MCU will enter an endless loop and become
+unresponsive. In order to clear the error the MCU must be reset using bit 8 in
+register 0x1f400000.
The highest 8 bits read from this register are the current state of the security
+cartridge's I0-I7 pins. See the security cartridge section for an explanation
+of what each bit is wired to. Unknown whether reading from this register will
+clear the IRDY flag, if previously set by the cartridge.
Bit 3 (DIP switch 4) is used by the BIOS to determine whether to boot from +flash. If set, the BIOS will attempt to search for a valid executable on the +internal flash and both PCMCIA cards prior to falling back to the CD-ROM.
+0x1f400006 (ASIC register 3): Misc. inputs| Bits | +RW | +Description | +
|---|---|---|
| 0 | +R | +Data output from ADC (DO) |
+
| 1 | +R | +SAR status from ADC (SARS) |
+
| 2 | +R | +From SDA on security cartridge |
+
| 3 | +R | +Sense input from JVS port | +
| 4 | +R | +JVSIRDY status from JVS MCU |
+
| 5 | +R | +JVSDRDY status from JVS MCU |
+
| 6 | +R | +IRDY status from security cartridge |
+
| 7 | +R | +DRDY status from security cartridge |
+
| 8 | +R | +Coin switch input 1 (0 = coin being inserted) | +
| 9 | +R | +Coin switch input 2 (0 = coin being inserted) | +
| 10 | +R | +PCMCIA card 1 insertion (0 = card present) | +
| 11 | +R | +PCMCIA card 2 insertion (0 = card present) | +
| 12 | +R | +Service button (JAMMA pin R, 0 = pressed) | +
| 13-15 | ++ | Unused? | +
See the security cartridge section for more details about IRDY and DRDY. In
+order for bit 2 to be valid, SDA should be set as an input by clearing the
+respective bit in register 0x1f500000.
0x1f400008 (ASIC register 4): JAMMA controls| Bits | +RW | +Description | +
|---|---|---|
| 0 | +R | +Player 2 joystick left (JAMMA pin X) | +
| 1 | +R | +Player 2 joystick right (JAMMA pin Y) | +
| 2 | +R | +Player 2 joystick up (JAMMA pin V) | +
| 3 | +R | +Player 2 joystick down (JAMMA pin W) | +
| 4 | +R | +Player 2 button 1 (JAMMA pin Z) | +
| 5 | +R | +Player 2 button 2 (JAMMA pin a) | +
| 6 | +R | +Player 2 button 3 (JAMMA pin b) | +
| 7 | +R | +Player 2 start button (JAMMA pin U) | +
| 8 | +R | +Player 1 joystick left (JAMMA pin 20) | +
| 9 | +R | +Player 1 joystick right (JAMMA pin 21) | +
| 10 | +R | +Player 1 joystick up (JAMMA pin 18) | +
| 11 | +R | +Player 1 joystick down (JAMMA pin 19) | +
| 12 | +R | +Player 1 button 1 (JAMMA pin 22) | +
| 13 | +R | +Player 1 button 2 (JAMMA pin 23) | +
| 14 | +R | +Player 1 button 3 (JAMMA pin 24) | +
| 15 | +R | +Player 1 start button (JAMMA pin 17) | +
As buttons are active-low (wired between JAMMA pins and ground), all bits are 0 +when a button is pressed and 1 otherwise. The BIOS and games often read from +this register and discard the result as a way of (inefficiently) flush the CPU's +write queue.
+0x1f40000a (ASIC register 5): Data from JVS MCU| Bits | +RW | +Description | +
|---|---|---|
| 0-15 | +R | +Current data word from MCU | +
This register is only valid when the JVSIRDY flag is set. After reading, a
+dummy write to 0x1f520000 shall be issued to clear JVSIRDY. If the MCU has
+more data available, it will update the register and set the flag again.
0x1f40000c (ASIC register 6): JAMMA controls / External inputs| Bits | +RW | +Description | +
|---|---|---|
| 0-7 | ++ | Unused? | +
| 8 | +R | +Player 1 button 4 (JAMMA pin 25) | +
| 9 | +R | +Player 1 button 5 (JAMMA pin 26) | +
| 10 | +R | +Test button (built-in and JAMMA pin 15) | +
| 11 | +R | +Player 1 button 6 | +
| 12-15 | ++ | Unused? | +
As buttons are active-low (wired between JAMMA pins and ground), all bits are 0 +when a button is pressed and 1 otherwise.
+The signals for buttons 4 and 5 are wired in parallel to both JAMMA and the
+EXT-IN connector, while button 6 can only be connected through EXT-IN and is
+usually unused.
0x1f40000e (ASIC register 7): JAMMA controls / External inputs| Bits | +RW | +Description | +
|---|---|---|
| 0-7 | ++ | Unused? | +
| 8 | +R | +Player 2 button 4 (JAMMA pin c) | +
| 9 | +R | +Player 2 button 5 (JAMMA pin d) | +
| 10 | ++ | Unused? | +
| 11 | +R | +Player 2 button 6 | +
| 12-15 | ++ | Unused? | +
As buttons are active-low (wired between JAMMA pins and ground), all bits are 0 +when a button is pressed and 1 otherwise.
+The signals for buttons 4 and 5 are wired in parallel to both JAMMA and the
+EXT-IN connector, while button 6 can only be connected through EXT-IN and is
+usually unused.
The IDE interface consists of a 16-bit parallel data bus with a 3-bit address
+bus and two bank select pins (/CS0 and /CS1), giving a total of sixteen
+16-bit registers of which only nine are typically used. On the 573 the two IDE
+banks are mapped to two separate memory regions at 0x1f480000 and 0x1f4c0000
+respectively. The IDE interrupt pin is routed into IRQ10 through the CPLD, while
+all other signals on the 40-pin connector (DMA handshaking lines, status pins,
+etc.) go unused.
Most 573 games, with the exception of those that run entirely from the internal +flash or PCMCIA cards, expect an ATAPI CD-ROM drive to be always connected and +configured as the primary (master) drive. Connecting an additional ATA hard +drive, CF card, IDE-to-SATA bridge or other device configured as secondary will +not interfere with the BIOS or games, thus homebrew games and apps can leverage +such a drive to store data separately from the currently installed game.
+Note that IDE and ATAPI give slightly different meanings to each register. Refer +to the ATA and ATAPI specifications for more details.
+0x1f480000 (IDE bank 0, address 0): Data| Bits | +RW | +Description | +
|---|---|---|
| 0-15 | +RW | +Current packet or data word | +
Data transfers can also be performed through DMA. See below for details.
+0x1f480002 (IDE bank 0, address 1): Error / FeaturesWhen read:
+| Bits | +RW | +Description (ATA) | +Description (ATAPI) | +
|---|---|---|---|
| 0 | +R | +Unused | +Illegal length flag (ILI) |
+
| 1 | +R | +No media flag (NM) |
+End of media flag (EOM) |
+
| 2 | +R | +Command aborted flag (ABRT) |
+Command aborted flag (ABRT) |
+
| 3 | +R | +Media change request flag (MCR) |
+Unused | +
| 4 | +R | +Address not found flag (IDNF) |
+SCSI sense key bit 0 | +
| 5 | +R | +Media changed flag (MC) |
+SCSI sense key bit 1 | +
| 6 | +R | +Uncorrectable error flag (UNC) |
+SCSI sense key bit 2 | +
| 7 | +R | +DMA CRC error flag (ICRC) |
+SCSI sense key bit 3 | +
| 8-15 | ++ | Unused | +Unused | +
When written:
+| Bits | +RW | +Description | +
|---|---|---|
| 0-7 | +W | +Command-specific feature index or flags | +
| 8-15 | ++ | Unused | +
0x1f480004 (IDE bank 0, address 2): Sector count| Bits | +RW | +Description (ATA) | +Description (ATAPI) | +
|---|---|---|---|
| 0-7 | +W | +Transfer sector count | +Unused | +
| 8-15 | ++ | Unused | +Unused | +
In ATA 48-bit LBA mode, bits 8-15 of the number of sectors to transfer must be +written to this register first, followed by bits 0-7.
+In ATA CHS or 28-bit LBA mode, setting this register to 0 will cause 256 sectors +to be transferred.
+0x1f480006 (IDE bank 0, address 3): Sector number| Bits | +RW | +Description (ATA) | +Description (ATAPI) | +
|---|---|---|---|
| 0-7 | +W | +CHS sector index or LBA bits 0-7 | +Unused | +
| 8-15 | ++ | Unused | +Unused | +
In ATA 48-bit LBA mode, bits 24-31 of the target LBA must be written to this +register first, followed by bits 0-7.
+0x1f480008 (IDE bank 0, address 4): Cylinder number low| Bits | +RW | +Description (ATA) | +Description (ATAPI) | +
|---|---|---|---|
| 0-7 | +RW | +CHS cylinder index bits 0-7 or LBA bits 8-15 | +Transfer chunk size bits 0-7 | +
| 8-15 | ++ | Unused | +Unused | +
In ATA 48-bit LBA mode, bits 32-39 of the target LBA must be written to this +register first, followed by bits 8-15.
+0x1f48000a (IDE bank 0, address 5): Cylinder number high| Bits | +RW | +Description (ATA) | +Description (ATAPI) | +
|---|---|---|---|
| 0-7 | +RW | +CHS cylinder index bits 8-15 or LBA bits 16-23 | +Transfer chunk size bits 8-15 | +
| 8-15 | ++ | Unused | +Unused | +
In ATA 48-bit LBA mode, bits 40-47 of the target LBA must be written to this +register first, followed by bits 16-23.
+0x1f48000c (IDE bank 0, address 6): Head number / Drive select| Bits | +RW | +Description (ATA) | +Description (ATAPI) | +
|---|---|---|---|
| 0-3 | +W | +CHS head index or 28-bit LBA bits 24-27 | +Reserved (should be 0) | +
| 4 | +RW | +Drive select (0 = primary, 1 = secondary) | +Drive select (0 = primary, 1 = secondary) | +
| 5 | ++ | Reserved (should be 1?) | +Reserved (should be 1?) | +
| 6 | +W | +Sector addressing mode (0 = CHS, 1 = LBA) | +Reserved (should be 0) | +
| 7 | ++ | Reserved (should be 1?) | +Reserved (should be 1?) | +
| 8-15 | ++ | Unused | +Unused | +
Bits 0-3 are not used in ATA 48-bit LBA mode.
+0x1f48000e (IDE bank 0, address 7): Status / CommandWhen read:
+| Bits | +RW | +Description (ATA) | +Description (ATAPI) | +
|---|---|---|---|
| 0 | +R | +Error flag (ERR) |
+Error flag (CHK) |
+
| 1 | +R | +Unused | +Unused | +
| 2 | +R | +Unused | +Unused | +
| 3 | +R | +Data request flag (DRQ) |
+Data request flag (DRQ) |
+
| 4 | +R | +Drive write error flag (DWE) |
+Overlapped service flag (SERV) |
+
| 5 | +R | +Drive fault flag (DF) |
+Drive fault flag (DF) |
+
| 6 | +R | +Drive ready flag (DRDY) |
+Drive ready flag (DRDY) |
+
| 7 | +R | +Drive busy flag (BSY) |
+Drive busy flag (BSY) |
+
| 8-15 | ++ | Unused | +Unused | +
When written:
+| Bits | +RW | +Description | +
|---|---|---|
| 0-7 | +W | +Command index | +
| 8-15 | ++ | Unused | +
In order to issue a command, the features, sector, cylinder and head registers +must be set up appropriately before writing the command ID to this register. +Refer to the ATA specification for a list of available commands and their +parameters.
+DRDY is set by the drive when it is ready to execute an ATA command. Note that
+ATAPI drives will not set DRDY initially, while still accepting ATAPI
+commands, in order to prevent misdetection as a hard drive. Before sending any
+command, a polling loop shall be used to wait until BSY is cleared.
DRQ is set when the drive is waiting for data to be read or written. Depending
+on the drive and command, an interrupt may also be fired when DRQ goes high
+after a command is issued. ERR/CHK is set if the last command executed
+resulted in an error; in that case the error register will contain more
+information about the cause of the error.
Reading from this register will acknowledge any pending drive interrupt and +deassert IRQ10. Note that, as with all PS1 interrupts, IRQ10 must additionally +be acknowledged at the interrupt controller side in order for it to fire again.
+0x1f4c000c (IDE bank 1, address 6): Alternate status| Bits | +RW | +Description (ATA) | +Description (ATAPI) | +
|---|---|---|---|
| 0 | +R | +Error flag (ERR) |
+Error flag (CHK) |
+
| 1 | +R | +Unused | +Unused | +
| 2 | +R | +Unused | +Unused | +
| 3 | +R | +Data request flag (DRQ) |
+Data request flag (DRQ) |
+
| 4 | +R | +Drive write error flag (DWE) |
+Overlapped service flag (SERV) |
+
| 5 | +R | +Drive fault flag (DF) |
+Drive fault flag (DF) |
+
| 6 | +R | +Drive ready flag (DRDY) |
+Drive ready flag (DRDY) |
+
| 7 | +R | +Drive busy flag (BSY) |
+Drive busy flag (BSY) |
+
| 8-15 | ++ | Unused | +Unused | +
Read-only mirror of the status register at 0x1f48000e that returns the same
+flags, but does not acknowledge any pending IRQ when read.
DMA channel 5, normally reserved for the expansion port on a PS1, can be used to
+transfer data to/from the IDE bus... with some caveats. The "correct" way to
+connect an IDE drive to the PS1's DMA controller would to be to wire up DMARQ
+and /DMACK from the drive directly to the respective pins on the CPU, allowing
+the DMA controller to synchronize transfers to the drive's internal buffer in
+chunked mode.
However, Konami being Konami, they did not do this on the 573. IDE drives will
+instead interpret DMA reads or writes as a burst of regular ("PIO", as defined
+in the ATA specification) CPU-issued reads or writes. As such, the drive shall
+be configured for PIO data transfers rather than DMA using the "set features"
+ATA command, and bits 9-10 in the DMA5_CHCR register shall be cleared to put
+the channel in manual synchronization mode. The DRQ bit in the status register
+must also be polled manually prior to starting a transfer, to ensure the drive
+is ready for it.
The RTC is an ST M48T58. This chip behaves like an 8 KB 8-bit static RAM, wired +to the lower 8 bits of the 16-bit data bus. It must thus be accessed by +performing 16-bit bus accesses and ignoring/masking out the upper 8 bits (as +with IDE control registers).
+The first 8184 bytes are mapped to the 0x1f620000-0x1f623fef region and are
+simply battery-backed SRAM, which will retain its contents across power cycles
+as long as the RTC's battery is not dead. The last 8 bytes are used as clock and
+control registers.
The values of the clock registers are buffered: they are stored in intermediate
+registers rather than being read from or written to the clock counters directly.
+Bits 6 and 7 in the control register at 0x1f623ff0 are used to control
+transfers between the registers and clock counters. All clock values are
+returned in BCD format.
0x1f623ff0 (M48T58 register 0x1ff8): Calibration / Control| Bits | +RW | +Buffered | +Description | +
|---|---|---|---|
| 0-4 | +RW | +Unknown | +Calibration offset (0-31), adjusts oscillator frequency | +
| 5 | +RW | +Unknown | +Sign bit for calibration offset (1 = positive) | +
| 6 | +W | +No | +Read mutex (1 = prevent buffered register updates) | +
| 7 | +W | +No | +Write mutex and trigger | +
| 8-15 | ++ | + | Unused | +
The values of all buffered clock registers are updated automatically. Setting +bit 6 will disable this behavior while keeping the counters running, allowing +for the registers to be read reliably without the RTC updating them at the same +time. The bit shall be cleared after reading the registers.
+Setting bit 7 will also halt buffered register updates, so that they can be +overwritten manually with new values. Clearing it afterwards will result in the +registers' values being copied back to the clock counters.
+0x1f623ff2 (M48T58 register 0x1ff9): Seconds / Stop| Bits | +RW | +Buffered | +Description | +
|---|---|---|---|
| 0-3 | +RW | +Yes | +Second units (0-9) | +
| 4-6 | +RW | +Yes | +Second tens (0-5) | +
| 7 | +RW | +Unknown | +Stop flag (0 = clock paused, 1 = clock running) | +
| 8-15 | ++ | + | Unused | +
0x1f623ff4 (M48T58 register 0x1ffa): Minute| Bits | +RW | +Buffered | +Description | +
|---|---|---|---|
| 0-3 | +RW | +Yes | +Minute units (0-9) | +
| 4-6 | +RW | +Yes | +Minute tens (0-5) | +
| 7 | ++ | + | Reserved (must be 0) | +
| 8-15 | ++ | + | Unused | +
0x1f623ff6 (M48T58 register 0x1ffb): Hour| Bits | +RW | +Buffered | +Description | +
|---|---|---|---|
| 0-3 | +RW | +Yes | +Hour units (0-9, or 0-3 if tens = 2) | +
| 4-5 | +RW | +Yes | +Hour tens (0-2) | +
| 6-7 | ++ | + | Reserved (must be 0) | +
| 8-15 | ++ | + | Unused | +
Hours are always returned in 24-hour format, as there is no way to switch to +12-hour format.
+0x1f623ff8 (M48T58 register 0x1ffc): Day of week / Century| Bits | +RW | +Buffered | +Description | +
|---|---|---|---|
| 0-2 | +RW | +Yes | +Day of week (1-7) | +
| 3 | ++ | + | Reserved (must be 0) | +
| 4 | +RW | +Yes | +Century flag | +
| 5 | +RW | +Unknown | +Century flag toggling enable (1 = enabled) | +
| 6 | +RW | +Unknown | +Enable 512 Hz clock signal output on pin 1 | +
| 7 | ++ | + | Reserved (must be 0) | +
| 8-15 | ++ | + | Unused | +
The day of week register is a free-running counter incremented alongside the day +counter. There is no logic for calculating the day of the week, so it must be +updated manually when setting the time. Konami games use 1 as Sunday, 2 as +Monday and so on.
+Bit 4 is a single-bit "counter" that gets toggled each time the year counter +overflows. It can be frozen by clearing bit 5. Konami games do not use the +century flag, as they interpret any year counter value in 70-99 range as +1970-1999 and all other values as a year after 2000.
+0x1f623ffa (M48T58 register 0x1ffd): Day of month / Battery state| Bits | +RW | +Buffered | +Description | +
|---|---|---|---|
| 0-3 | +RW | +Yes | +Day of month units (range depends on tens and month) | +
| 4-5 | +RW | +Yes | +Day of month tens (range depends on month) | +
| 6 | +R | +No | +Low battery flag (1 = battery voltage is below 2.5V) | +
| 7 | +RW | +Unknown | +Battery monitoring enable (1 = enabled) | +
| 8-15 | ++ | + | Unused | +
Bit 6 is updated when the system is power cycled, if bit 7 has previously been +set.
+0x1f623ffc (M48T58 register 0x1ffe): Month| Bits | +RW | +Buffered | +Description | +
|---|---|---|---|
| 0-3 | +RW | +Yes | +Month units (1-9, or 0-2 if tens = 1) | +
| 4 | +RW | +Yes | +Month tens (0-1) | +
| 5-7 | ++ | + | Reserved (must be 0) | +
| 8-15 | ++ | + | Unused | +
0x1f623ffe (M48T58 register 0x1fff): Year| Bits | +RW | +Buffered | +Description | +
|---|---|---|---|
| 0-3 | +RW | +Yes | +Year units (0-9) | +
| 4-7 | +RW | +Yes | +Year tens (0-9) | +
| 8-15 | ++ | + | Unused | +
The year counter covers a full century, going from 00 to 99. On each overflow +the century flag in the day of week register is toggled.
+These registers are implemented almost entirely using 74-series logic and the +XC9536 CPLD on the main board.
+0x1f500000: Bank switch / Security cartridge| Bits | +RW | +Description | +
|---|---|---|
| 0-5 | +W | +Bank number (0-47, see below) | +
| 6 | +W | +SDA direction on security cartridge (0 = input/high-z) |
+
| 7 | ++ | Unknown (goes into CPLD) | +
| 8-15 | ++ | Unused | +
Bit 6 controls whether SDA on the security cartridge is an input or an output.
+If set, SDA will output the same logic level as D0, otherwise the pin will
+be floating. Bits 0-5 are used to switch the device mapped to the 4 MB
+0x1f000000-0x1f3fffff region:
| Bank | +Mapped to | +
|---|---|
| 0 | +Internal flash 1 (chips 31M, 27M) |
+
| 1 | +Internal flash 2 (chips 31L, 27L) |
+
| 2 | +Internal flash 3 (chips 31J, 27J) |
+
| 3 | +Internal flash 4 (chips 31H, 27H) |
+
| 4-15 | +Unused | +
| 16-31 | +PCMCIA card slot 1 | +
| 32-47 | +PCMCIA card slot 2 | +
| 48-63 | +Unused | +
0x1f520000: JVSIRDY clear| Bits | +RW | +Description | +
|---|---|---|
| 0-15 | ++ | Unused | +
This register is a dummy write-only port that clears the JVSIRDY flag when any
+value is written to it. The flag is set by the JVS MCU whenever a new data word
+is available for reading from 0x1f40000a.
0x1f560000: IDE reset control| Bits | +RW | +Description | +
|---|---|---|
| 0 | +W | +Reset pin output (0 = pull reset low) | +
| 1-15 | ++ | Unused | +
Since the IDE reset pin is active-low, a reset is performed by writing 0 to this
+register, then waiting a few milliseconds and writing 1 again. Note that the IDE
+specification also defines a way to "soft-reset" devices (e.g. to abort
+execution of a command) using the SRST bit in the device control register.
0x1f5c0000: Watchdog clear| Bits | +RW | +Description | +
|---|---|---|
| 0-15 | ++ | Unused | +
This register is a dummy write-only port that clears the watchdog timer embedded +in the Konami 058232 power-on reset and coin counter driver chip when any value +is written to it. The BIOS and games write to this port roughly once per frame.
+If the watchdog is not cleared at least every 350-400 ms, it will pull the
+system's reset line low for about 50 ms in order to force a reboot. The watchdog
+can be disabled without affecting power-on reset by placing a jumper on S86
+(see the pinouts section).
0x1f600000: External outputs| Bits | +RW | +Description | +
|---|---|---|
| 0-7 | +W | +To OUT0-OUT7 on EXT-OUT connector |
+
| 8-15 | ++ | Unused | +
The lower 8 bits written to this register are latched on pins OUT0-OUT7 of the
+external output connector (see the pinouts section). This connector is used by
+some games to control cabinet lights without using an I/O board.
0x1f680000: Data to JVS MCU| Bits | +RW | +Description | +
|---|---|---|
| 0-15 | +W | +Data word to MCU | +
In order to prevent overruns, this register shall only be accessed when
+JVSDRDY is cleared. Writing to it will set JVSDRDY.
0x1f6a0000: Security cartridge outputs| Bits | +RW | +Description | +
|---|---|---|
| 0-7 | +W | +To D0-D7 on security cartridge |
+
| 8-15 | ++ | Unused | +
The lower 8 bits written to this register are latched on pins D0-D7 of the
+cartridge slot. See the security cartridge section for an explanation of what
+each pin is wired to. Bit 0 additionally controls the SDA pin when configured
+as an output through the bank switch register. Writing to this register will set
+the DRDY flag, which can then be cleared by the cartridge.
Some games may rely on reads from this register returning the last value written +to it. This behavior is unconfirmed.
+The System 573 is equipped with a JVS host interface, allowing for connection of +I/O modules, controllers and other devices that implement the JVS protocol +commonly used in arcade cabinets.
+JVS uses a single RS-485 bus running at 115200 bits per second, shared by all
+devices. The standard JVS connector is a single USB-A port, with the data lines
+used as the RS-485 differential pair and the VBUS pin as a sensing line (see
+the JVS specification for details). JVS devices typically have a full size USB-B
+port for connection to the host, plus optionally another USB-A port for daisy
+chaining additional devices. The RS-485 bus needs to be terminated; some boards
+will automatically insert a termination resistor when connected as the last node
+in a daisy chain.
A JVS packet can be up to 258 bytes long and is made up of the following fields:
+| Byte | +Description | +
|---|---|
| 0 | +Synchronization byte, must be 0xe0 |
+
| 1 | +Destination address | +
| 2 | +Length (number of payload bytes including checksum) | +
| 3- | +Payload | +
| + | Checksum (sum of address, length and payload bytes modulo 256) | +
NOTE: when a JVS packet is sent over the RS-485 bus, any 0xd0 or 0xe0
+byte other than the synchronization byte must be escaped as 0xd0 0xcf or
+0xd0 0xdf respectively, in order to allow downstream devices to reliably
+determine the end of a packet. On the 573, the JVS MCU handles escaping outbound
+packets and unescaping inbound packets automatically. The escaping process does
+not update the length field to reflect the escaped length of the packet.
Refer to the JVS specification for details on the contents of standard and +vendor-specific payloads.
+The system's JVS interface is managed by a dedicated H8/3644 microcontroller, +interfaced through two 16-bit latches and handshaking lines (in a similar way to +the 8-bit ports on the security cartridge slot). The MCU's firmware is stored in +OTP ROM and consists of a simple loop that buffers the data written by the 573, +sends it, waits for a response to be received and lets the 573 read it.
+In order to perform a JVS transaction the 573 must:
+0x1f400000, clear JVSIRDY by writing to
+ 0x1f520000 then wait for the status and error codes in register
+ 0x1f400004 to be set to 0 and 3 respectively.0x1f680000, waiting for JVSDRDY
+ to go low before each write. Words are little endian, so for instance the
+ first word of a packet with destination address 0x01 would be 0x01e0. If
+ the total length of the packet is odd, the last byte shall still be written
+ as a word (with the upper byte zeroed out).0x1f40000a, waiting for
+ JVSIRDY to go high before each read and clearing it by writing to
+ 0x1f520000 after each read. The status code will be set to 2 after the
+ first word is read and back to 0 once no more data is available to read.The MCU does not allow for non-JVS packets to be sent as it validates the sync +byte, checksum and uses the length field to determine packet length. Responses +cannot be received without sending a packet first either. The MCU will also +insert a 200 us minimum delay between the last byte of a received packet and the +first byte of the next packet.
+The System 573 was designed to be expanded with game-specific hardware using I/O
+expansion boards mounted on top of the main board, and/or custom security
+cartridges. I/O boards have access to the 16-bit system bus and are accessible
+through the 0x1f640000-0x1f6400ff region.
GX700-PWB(F))GX894-PWB(B)A)GX700-PWB(K))GE765-PWB(B)A)GX921-PWB(B))PWB0000073070)GX700-PWB(F))Used in early Bemani games such as DDR 1stMIX and 2ndMIX, as well as some +non-Bemani games. The name is misleading as the board does not deal with any +analog signals whatsoever; the name was given retroactively to distinguish it +from the digital I/O board. It provides up to 28 optoisolated open-drain outputs +typically used to control cabinet lights, split across 4 banks:
+CN33): 8 outputs (A0-A7)CN34): 8 outputs (B0-B7)CN35): 8 outputs (C0-C7)CN36): 4 outputs (D0-D3)Some games shipped with partially populated analog I/O boards, thus not all +banks may be available. See the game-specific information section for details on +how lights are wired up on each cabinet type.
+0x1f640080: Bank A| Bits | +RW | +Description | +
|---|---|---|
| 0 | +W | +Output A1 (0 = grounded) | +
| 1 | +W | +Output A3 (0 = grounded) | +
| 2 | +W | +Output A5 (0 = grounded) | +
| 3 | +W | +Output A7 (0 = grounded) | +
| 4 | +W | +Output A6 (0 = grounded) | +
| 5 | +W | +Output A4 (0 = grounded) | +
| 6 | +W | +Output A2 (0 = grounded) | +
| 7 | +W | +Output A0 (0 = grounded) | +
| 8-15 | ++ | Unused | +
0x1f640088: Bank B| Bits | +RW | +Description | +
|---|---|---|
| 0 | +W | +Output B1 (0 = grounded) | +
| 1 | +W | +Output B3 (0 = grounded) | +
| 2 | +W | +Output B5 (0 = grounded) | +
| 3 | +W | +Output B7 (0 = grounded) | +
| 4 | +W | +Output B6 (0 = grounded) | +
| 5 | +W | +Output B4 (0 = grounded) | +
| 6 | +W | +Output B2 (0 = grounded) | +
| 7 | +W | +Output B0 (0 = grounded) | +
| 8-15 | ++ | Unused | +
0x1f640090: Bank C| Bits | +RW | +Description | +
|---|---|---|
| 0 | +W | +Output C1 (0 = grounded) | +
| 1 | +W | +Output C3 (0 = grounded) | +
| 2 | +W | +Output C5 (0 = grounded) | +
| 3 | +W | +Output C7 (0 = grounded) | +
| 4 | +W | +Output C6 (0 = grounded) | +
| 5 | +W | +Output C4 (0 = grounded) | +
| 6 | +W | +Output C2 (0 = grounded) | +
| 7 | +W | +Output C0 (0 = grounded) | +
| 8-15 | ++ | Unused | +
0x1f640098: Bank D| Bits | +RW | +Description | +
|---|---|---|
| 0 | +W | +Output D3 (0 = grounded) | +
| 1 | +W | +Output D2 (0 = grounded) | +
| 2 | +W | +Output D1 (0 = grounded) | +
| 3 | +W | +Output D0 (0 = grounded) | +
| 4-15 | ++ | Unused | +
GX894-PWB(B)A)Used by later Bemani games, such as DDR from Solo onwards. This board features +the same 28 isolated open-drain outputs as the analog I/O board, plus a Xilinx +XCS40XL Spartan-XL FPGA and a Micronas MAS3507D audio decoder ASIC used to play +encrypted MP3 files. The FPGA has 24 MB of dedicated DRAM into which the files +are preloaded on startup, then decrypted on the fly and fed to the decoder. The +board also features 128 KB of SRAM used as a cache, RS-232 and ARCnet +transceivers for communication with other hardware and a DS2401 serial number +chip, used to prevent usage of the same security cartridge on more than one 573.
+The vast majority of the registers provided by this board (including some but
+not all light outputs) are handled by its FPGA, which requires a configuration
+bitstream to be uploaded to it in order to work. Registers in the
+0x1f6400f0-0x1f6400ff region are handled by a CPLD and are functional even if
+no bitstream is loaded. There are several known versions of Konami's bitstream:
| SHA-1 (LSB first) | +First used by | +
|---|---|
32d455a25eb26fe4e4b577cb0f0e3bebd0f82959 |
+Dance Dance Revolution Solo Bass Mix | +
a53b8906de95c34b6e3f053bd7488c888bc904b6 |
+Dance Dance Revolution 3rdMIX | +
450b12627b7eacd3ea3f8b0b7a16589a13010c41 |
+Mambo a Go-Go | +
53d0c1e3f6ae042d7d45ce889b79a12f1be5eabd |
+Martial Beat e-Amusement | +
d1d0f123bbb9d5abfefbd556c366f9ded0779e41 |
+Martial Beat (leftover file 1, unused) | +
f354619fe1a80cabe0b774784181b3bfeff0a3e9 |
+Martial Beat (leftover file 2, unused) | +
The DDR and Mambo bitstreams all implement the same registers (listed below) and +seem to only differ in the MP3 decryption algorithm, while the unused Martial +Beat bitstreams seem to behave in a completely different way. Homebrew tools may +also load custom bitstreams, which can be developed using the Xilinx ISE +toolchain. See the pinouts section for a list of all devices connected to the +FPGA.
+0x1f640080 (FPGA, DDR/Mambo bitstream): Magic number| Bits | +RW | +Description | +
|---|---|---|
| 0-15 | +R | +Magic number (0x1234) |
+
This register is checked by Konami's digital I/O board driver to make sure the +bitstream was properly loaded into the FPGA.
+0x1f640090 (FPGA, DDR/Mambo bitstream): Network board address0x1f640092 (FPGA, DDR/Mambo bitstream): Unknown (network related)0x1f6400a0 (FPGA, DDR/Mambo bitstream): MP3 data start address high0x1f6400a2 (FPGA, DDR/Mambo bitstream): MP3 data start address low0x1f6400a4 (FPGA, DDR/Mambo bitstream): MP3 data end address high0x1f6400a6 (FPGA, DDR/Mambo bitstream): MP3 data end address low0x1f6400a8 (FPGA, DDR/Mambo bitstream): MP3 frame counter / Decryption key 10x1f6400aa (FPGA, DDR/Mambo bitstream): MP3 playback status0x1f6400ac (FPGA, DDR/Mambo bitstream): MAS3507D I2C0x1f6400ae (FPGA, DDR/Mambo bitstream): MP3 data feeder control0x1f6400b0 (FPGA, DDR/Mambo bitstream): RAM write address high0x1f6400b2 (FPGA, DDR/Mambo bitstream): RAM write address low0x1f6400b4 (FPGA, DDR/Mambo bitstream): RAM data0x1f6400b6 (FPGA, DDR/Mambo bitstream): RAM read address high0x1f6400b8 (FPGA, DDR/Mambo bitstream): RAM read address low0x1f6400c0 (FPGA, DDR/Mambo bitstream): Network data0x1f6400c2 (FPGA, DDR/Mambo bitstream): Network output buffer size0x1f6400c4 (FPGA, DDR/Mambo bitstream): Network input buffer size0x1f6400c8 (FPGA, DDR/Mambo bitstream): Unknown (network related)0x1f6400ca (FPGA, DDR/Mambo bitstream): DAC sample counter high0x1f6400cc (FPGA, DDR/Mambo bitstream): DAC sample counter low0x1f6400ce (FPGA, DDR/Mambo bitstream): DAC sample counter delta0x1f6400e0 (FPGA, DDR/Mambo bitstream): Bank A| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +W | +Output A4 (0 = grounded) | +
| 13 | +W | +Output A5 (0 = grounded) | +
| 14 | +W | +Output A6 (0 = grounded) | +
| 15 | +W | +Output A7 (0 = grounded) | +
0x1f6400e2 (FPGA, DDR/Mambo bitstream): Bank A| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +W | +Output A0 (0 = grounded) | +
| 13 | +W | +Output A1 (0 = grounded) | +
| 14 | +W | +Output A2 (0 = grounded) | +
| 15 | +W | +Output A3 (0 = grounded) | +
0x1f6400e4 (FPGA, DDR/Mambo bitstream): Bank B| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +W | +Output B4 (0 = grounded) | +
| 13 | +W | +Output B5 (0 = grounded) | +
| 14 | +W | +Output B6 (0 = grounded) | +
| 15 | +W | +Output B7 (0 = grounded) | +
0x1f6400e6 (FPGA, DDR/Mambo bitstream): Bank D| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +W | +Output D0 (0 = grounded) | +
| 13 | +W | +Output D1 (0 = grounded) | +
| 14 | +W | +Output D2 (0 = grounded) | +
| 15 | +W | +Output D3 (0 = grounded) | +
0x1f6400e8 (FPGA, DDR/Mambo bitstream): Initialization/reset related| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +W | +Unknown (0 = reset?) | +
| 13 | +W | +Unknown (0 = reset?) | +
| 14 | +W | +Unknown (0 = reset?) | +
| 15 | +W | +Unknown (0 = reset?) | +
Konami's code writes 0xf000, followed by 0x0000, a delay and 0xf000 again,
+to this register after uploading the bitstream.
0x1f6400ea (FPGA, DDR/Mambo bitstream): Decryption key 20x1f6400ec (FPGA, DDR/Mambo bitstream): Decryption key 30x1f6400ee (FPGA, DDR/Mambo bitstream): 1-wire busWhen read:
+| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +R | +DS2401 1-wire bus readout | +
| 13-15 | ++ | Unused? (see note) | +
When written:
+| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +W | +Drive DS2401 1-wire bus low (1 = pull low, 0 = release) | +
| 13-15 | ++ | Unused? (see note) | +
In addition to the DS2401 the board has an unpopulated footprint for a DS2433 +1-wire EEPROM, connected to a separate FPGA pin. Bit 13, 14 or 15 may actually +be mapped to the unused DS2433 bus.
+0x1f6400f0 (CPLD): Unknown (unused?)Konami's code does not write to this CPLD register.
+0x1f6400f2 (CPLD): Unknown (unused?)Konami's code does not write to this CPLD register.
+0x1f6400f4 (CPLD): Unknown (reset?)| Bits | +RW | +Description | +
|---|---|---|
| 0-14 | ++ | Unused | +
| 15 | +W | +Unknown (0 = reset?) | +
Probably controls the MAS3507D or DAC's reset pin. Bit 15 is cleared before +uploading the bitstream and set again once the FPGA is initialized.
+0x1f6400f6 (CPLD): FPGA status and controlWhen read:
+| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +R | +Possibly /INIT from FPGA |
+
| 13 | +R | +Possibly DONE from FPGA |
+
| 14 | +R | +Board identification? (always 1) | +
| 15 | +R | +Board identification? (always 0) | +
NOTE: all registers in the 0x1f6400f0-0x1f6400ff region seem to return the
+same value as this register when read, possibly due to incomplete address
+decoding in the CPLD. Konami's driver only ever reads from this register and
+treats all other CPLD registers as write-only.
When written:
+| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +W | +Possibly /INIT to FPGA |
+
| 13 | +W | +Possibly DONE to FPGA |
+
| 14 | +W | +Possibly /PROGRAM to FPGA |
+
| 15 | +W | +Unused? (always 1) | +
This register is only written to 3 times when resetting the FPGA prior to
+loading the bitstream. The values written are 0x8000 first, then 0xc000 and
+finally 0xf000.
0x1f6400f8 (CPLD): FPGA bitstream upload| Bits | +RW | +Description | +
|---|---|---|
| 0-14 | ++ | Unused | +
| 15 | +W | +Bit to send to the FPGA | +
Bits written to this register are sent to the FPGA's configuration interface
+(DIN and CCLK pins, see the XCS40XL datasheet). There is no separate bit to
+control the CCLK pin as clocking is handled automatically. The FPGA is wired
+to boot in "slave serial" mode and wait for a bitstream to be loaded by the 573
+through this port.
All known games load the bitstream from an array embedded in the executable or a
+file on the internal flash (usually named data/fpga/fpga_mp3.bin), then write
+its contents to this port LSB first and monitor the FPGA status register. The
+bitstream is always 330696 bits (41337 bytes) long as per the XCS40XL datasheet.
0x1f6400fa (CPLD): Bank C| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +W | +Output C0 (0 = grounded) | +
| 13 | +W | +Output C1 (0 = grounded) | +
| 14 | +W | +Output C2 (0 = grounded) | +
| 15 | +W | +Output C3 (0 = grounded) | +
0x1f6400fc (CPLD): Bank C| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +W | +Output C4 (0 = grounded) | +
| 13 | +W | +Output C5 (0 = grounded) | +
| 14 | +W | +Output C6 (0 = grounded) | +
| 15 | +W | +Output C7 (0 = grounded) | +
0x1f6400fe (CPLD): Bank B| Bits | +RW | +Description | +
|---|---|---|
| 0-11 | ++ | Unused | +
| 12 | +W | +Output B0 (0 = grounded) | +
| 13 | +W | +Output B1 (0 = grounded) | +
| 14 | +W | +Output B2 (0 = grounded) | +
| 15 | +W | +Output B3 (0 = grounded) | +
GX700-PWB(K))Used by Kick & Kick. Has several optocouplers, plus a DS2401 serial number +chip and several unpopulated footprints.
+This board is currently undocumented.
+GE765-PWB(B)A)Used by the Fisherman's Bait series. Uses an NEC uPD4701 mouse/trackball chip to +track motion of the fishing reel's rotary encoders and contains PWM drivers for +the feedback motors. Along with the analog I/O board, it is the only known board +that does not have a DS2401.
+This board is currently undocumented.
+GX921-PWB(B))Used by DDR Karaoke Mix 1 and 2. Similarly to the digital I/O board, this board +features several optoisolated light outputs, an ARCnet PHY and a DS2401 serial +number chip. It also has composite video inputs and outputs, a video encoder to +convert the 573's native RGB output to composite and additional circuitry to +superimpose it onto the video feed from an external karaoke machine. An onboard +PC16552 UART is provided to communicate with the machine (the security cartridge +also exposes SIO1).
+This board is currently undocumented.
+PWB0000073070)Used by GunMania and GunMania Zone Plus. Contains an RGB to S-video converter +which drives the cabinet's projector, several motor drivers, optoisolators, a +PC16552 UART and a DS2401 serial number chip. A DB25 connector on the side of +the board is used to interface to the resistive matrix used to detect bullet +shots.
+This board is currently undocumented.
+There is no proof whatsoever of this board having ever existed, but the BIOS and +some games attempt to access the hardware on it. It seems to contain at least a +Fujitsu MB89371 UART and a 7-segment display, although these may have actually +been on two separate boards (or built into a prototype board used by Konami +during development).
+The MB89371 does not have a publicly available datasheet.
+0x1f640000: UART data0x1f640002: UART control0x1f640004: UART baud rate select0x1f640006: UART mode0x1f640010: 7-segment display| Bits | +RW | +Description | +
|---|---|---|
| 0 | +W | +Right digit segment G (0 = on) | +
| 1 | +W | +Right digit segment F (0 = on) | +
| 2 | +W | +Right digit segment E (0 = on) | +
| 3 | +W | +Right digit segment D (0 = on) | +
| 4 | +W | +Right digit segment C (0 = on) | +
| 5 | +W | +Right digit segment B (0 = on) | +
| 6 | +W | +Right digit segment A (0 = on) | +
| 7 | ++ | Unused | +
| 8 | +W | +Left digit segment G (0 = on) | +
| 9 | +W | +Left digit segment F (0 = on) | +
| 10 | +W | +Left digit segment E (0 = on) | +
| 11 | +W | +Left digit segment D (0 = on) | +
| 12 | +W | +Left digit segment C (0 = on) | +
| 13 | +W | +Left digit segment B (0 = on) | +
| 14 | +W | +Left digit segment A (0 = on) | +
| 15 | ++ | Unused | +
The BIOS shell shows "00" on this display (but contains a function to show any +hexadecimal value). Kick & Kick shows an animated spinner, some other games +show error or status codes on it. This may have been meant to be a POST display +integrated into the 573 main board at some point.
+Most System 573 games use cartridges that plug into the slot on the right side +of the main board as an anti-piracy measure and/or to add game specific I/O +functionality (particularly for games that do not otherwise require any I/O +board). Cartridges typically contain a password protected EEPROM, used to store +game and installation information, and in some cases a DS2401 unique serial +number chip.
+All communication with the cartridge is performed through the following means:
+I0-I7), readable via register 0x1f400004;D0-D7), controlled by register
+ 0x1f6a0000;SDA), which can be either configured as a
+ floating input or set to output the same logic level as D0 through register
+ 0x1f500000;TX, RX, /RTS, /CTS, /DTR, /DSR);IRDY, DRDY, /IREQ, /DACK).As all EEPROMs used in cartridges have an I2C interface rather than a parallel
+one, SDA is used in combination with individual bits of the parallel I/O ports
+to bitbang I2C. The SIO1 interface either goes unused or is translated to RS-232
+voltage levels and broken out to a connector on the cartridge.
See the pinouts section for more information on the security cartridge slot.
+The cartridge slot carries two status lines unofficially known as IRDY and
+DRDY plus two inputs named /IREQ and /DACK, probably meant for
+synchronization with cartridges that would actually use D0-D7 and I0-I7 as a
+parallel data bus rather than to bitbang serial protocols. No currently known
+cartridge uses these pins.
DRDY is set whenever the 573 writes to the output port, even if no bits have
+actually changed. The cartridge can monitor this signal to know when to read a
+byte from the port and then pull /DACK low to reset it. To send a byte to the
+573 the cartridge can pulse /IREQ, which will cause IRDY to go high until
+the 573 accesses the input port. The 573 can read the status of IRDY (as well
+as DRDY) through the Konami ASIC and wait for it to be set before reading the
+next byte.
The cartridge I/O ports can basically be thought of as a single-byte FIFO, with
+DRDY being the "TX buffer full" flag and IRDY the "RX buffer not empty"
+flag. The handshaking lines are implemented using a handful of 74LS74 flip
+flops.
NOTE: the JVS MCU also has its own handshaking lines, JVSIRDY and
+JVSDRDY, which are actually used and work in pretty much the same way. See the
+JVS interface section for more information on communicating with the MCU.
The PS1 CPU's SIO1 UART has hardware flow control and will not transmit data +until CTS is asserted. In order to get around this most cartridges tie CTS to +RTS, allowing it to be controlled in software. Cartridges that use the serial +port (i.e. ones with a network port) have the pins tied together on the PCB, +while other cartridge types usually break them out to a shorted 2-pin jumper.
+Some earlier games that do not use SIO1 for networking purposes redirect their
+debug logging output to it (by calling the AddSIO() function provided by the
+Sony SDK) if CTS and RTS are shorted on startup. On later 573 motherboard
+revisions, the SIO1 pins are additionally broken out to a separate connector
+(CN24) and made accessible even when a cartridge without a network port is
+inserted.
Konami's security cartridge driver supports the following EEPROMs:
+| Manufacturer | +Chip | +"Response to reset" ID | +Capacity | +
|---|---|---|---|
| Xicor | +X76F041 | +19 55 aa 55 (LSB first) |
+512 bytes | +
| Xicor | +X76F100 | +19 00 aa 55 (LSB first) |
+112 bytes | +
| Konami/Microchip | +ZS01 (PIC16CE625) | +5a 53 00 01 (MSB first) |
+112 bytes | +
NOTE: Konami seems to have never manufactured X76F100 cartridges, however +most games that expect an X76F041 can also use the X76F100 interchangeably. ZS01 +support was only added in later versions of the driver.
+The "ZS01" EEPROM is actually a PIC16 microcontroller that mostly replicates the +X76F100's functionality, allowing the 573 to store up to 112 bytes of data +protected by a 64-bit password. Unlike the X76F041 and X76F100, which use +plaintext commands, all communication with the ZS01 is obfuscated using a +rudimentary scrambling algorithm. A CRC16 is attached to each packet and used to +detect attempts to tamper with the obfuscation. Attempting to send too many +requests with an invalid CRC16 will cause the ZS01 to self-erase and reset the +password.
+A ZS01 transaction can be broken down into the following steps:
+The 573 prepares a 12-byte packet to be sent to the ZS01, containing a + command, address and payload:
+| Bytes | +Description | +
|---|---|
| 0 | +Command flags | +
| 1 | +Address bits 0-7 | +
| 2-9 | +Payload (data for writes, response key for reads) | +
| 10-11 | +CRC16 of bytes 0-9, big endian | +
The first byte is a 3-bit bitfield encoding the command and access type:
+| Bits | +Description | +
|---|---|
| 0 | +Command (0 = write/erase, 1 = read) | +
| 1 | +Address bit 8 (unused, should be 0) | +
| 2 | +Access type (0 = unprivileged, 1 = privileged) | +
| 3-7 | +Unused? (should be 0) | +
The access type bit specifies whether the command is privileged. Privileged +commands require the ZS01's current password, while unprivileged commands do +not.
+The address must be one of the following values:
+| Address | +Length | +Privileged | +Description | +
|---|---|---|---|
0x00-0x03 |
+32 bytes | +No | +Unprivileged data area | +
0x04-0x0e |
+80 bytes | +Yes | +Privileged data area | +
0xfc |
+8 bytes | +No | +Internal ZS01 serial number | +
0xfd |
+8 bytes | +No | +External DS2401 serial number | +
0xfd |
+8 bytes | +Yes | +Erases data area when written (write-only) | +
0xfe |
+8 bytes | +Yes | +Configuration registers | +
0xff |
+8 bytes | +Yes | +New password (write-only) | +
Data is always read or written in aligned 8 byte blocks. Unprivileged areas +can be read using either a privileged or unprivileged read command, but +writing to them still requires a privileged write command.
+If the command is a read command, a random 8-byte "response key" is + generated (typically as an MD5 hash of the current time from the RTC) and + written to the payload field; the ZS01 will later use it to encrypt the + returned data as a replay attack prevention measure. For write commands, the + payload field is populated with the 8 bytes to be written.
+A CRC16 is calculated over the first 10 bytes of the packet and stored in + the last 2 bytes in big endian format. The CRC is computed as follows:
+#define ZS01_CRC16_POLYNOMIAL 0x1021
+
+uint16_t zs01_crc16(const uint8_t *data, size_t length) {
+ uint16_t crc = 0xffff;
+
+ for (; length; length--) {
+ crc ^= *(data++) << 8;
+
+ for (int bit = 8; bit; bit--) {
+ uint16_t temp = crc;
+
+ crc <<= 1;
+ if (temp & (1 << 15))
+ crc ^= ZS01_CRC16_POLYNOMIAL;
+ }
+ }
+
+ return (~crc) & 0xffff;
+}
+If the command is privileged, the 573 scrambles the payload field with the + chip's currently set password, using the following algorithm:
+// Note that this state is preserved across calls to zs01_scramble_payload()
+// and must be updated when a response is received (see step 8).
+uint8_t zs01_scrambler_state = 0;
+
+void zs01_scramble_payload(
+ uint8_t *output, const uint8_t *input, size_t length,
+ const uint8_t *password
+) {
+ for (; length; length--) {
+ int value = *(input++) ^ zs01_scrambler_state;
+ value = (value + password[0]) & 0xff;
+
+ for (int i = 1; i < 8; i++) {
+ int add = password[i] & 0x1f;
+ int shift = password[i] >> 5;
+
+ int shifted = value << shift;
+ shifted |= value >> (8 - shift);
+ shifted &= 0xff;
+
+ value = (shifted + add) & 0xff;
+ }
+
+ zs01_scrambler_state = value;
+ *(output++) = value;
+ }
+}
+The CRC16 is not updated to reflect the new data. This step is skipped for +unprivileged read commands.
+All 12 bytes of the packet are scrambled with a fixed "command key", using + the following algorithm:
+static const uint8_t ZS01_COMMAND_ADD[] = { 237, 8, 16, 11, 6, 4, 8, 30 };
+static const uint8_t ZS01_COMMAND_SHIFT[] = { 0, 3, 2, 2, 6, 2, 2, 1 };
+
+void zs01_scramble_packet(
+ uint8_t *output, const uint8_t *input, size_t length
+) {
+ // Unlike zs01_scramble_payload(), this state is *not* preserved across
+ // calls.
+ uint8_t state = 0xff;
+
+ output += length;
+ input += length;
+
+ for (; length; length--) {
+ int value = *(--input) ^ state;
+ value = (value + ZS01_COMMAND_ADD[0]) & 0xff;
+
+ for (int i = 1; i < 8; i++) {
+ int shifted = value << ZS01_COMMAND_SHIFT[i];
+ shifted |= value >> (8 - ZS01_COMMAND_SHIFT[i]);
+ shifted &= 0xff;
+
+ value = (shifted + ZS01_COMMAND_ADD[i]) & 0xff;
+ }
+
+ state = value;
+ *(--output) = value;
+ }
+}
+The scrambled packet is sent to the ZS01, which will respond to the first 11 + bytes immediately with an I2C ACK and to the last byte with an ACK after a + short delay. The 573 then proceeds to read 12 bytes from the ZS01, issuing + an I2C ACK for each byte received up until the last one.
+The 573 uses the response key generated in step 2 to unscramble the packet + returned by the ZS01. The unscrambling algorithm is the same one used in + step 5, applied in reverse:
+void zs01_unscramble_packet(
+ uint8_t *output, const uint8_t *input, size_t length,
+ const uint8_t *response_key
+) {
+ uint8_t state = 0xff;
+
+ output += length;
+ input += length;
+
+ for (; length; length--) {
+ int value = *(--input);
+ int last_state = state;
+ state = value;
+
+ for (int i = 1; i < 8; i++) {
+ int add = response_key[i] & 0x1f;
+ int shift = response_key[i] >> 5;
+
+ int subtracted = (value - add) & 0xff;
+
+ value = subtracted >> shift;
+ value |= subtracted << (8 - shift);
+ value &= 0xff;
+ }
+
+ value = (value - response_key[0]) & 0xff;
+ *(--output) = value ^ last_state;
+ }
+}
+For write commands, the response key required to unscramble the packet is +the one sent as part of the last read command issued. For read commands, the +ZS01 may either use the key provided in the payload field or the one from +the last read command issued; Konami's code tries unscrambling responses +with both.
+The unscrambled packet will contain the following fields:
+| Bytes | +Description | +
|---|---|
| 0 | +Status code (0 = success, 1-5 = error) | +
| 1 | +New payload scrambler state | +
| 2-9 | +Payload (empty for writes, data for reads) | +
| 10-11 | +CRC16 of bytes 0-9, big endian | +
The 573 proceeds to compute the CRC16 of the first 10 bytes. If it does not
+match the one in the packet, it will try unscrambling the packet with a
+different response key (see step 7) before giving up. Otherwise, the global
+zs01_scrambler_state variable from step 4 is set to the value of byte 1,
+regardless of whether the status code is zero or not.
The exact meaning of non-zero status codes is currently unknown.
+GX700-PWB(E))This is the only known cartridge type that has no EEPROM (although the PCB does +have an unpopulated X76F041 footprint). It has no plastic case, as it's meant to +be enclosed in the same case as the 573 itself. It has open-drain outputs for +driving up to 12 lights, arranged as 3 banks of 4 outputs each (one bank for +each player's buttons), plus an RS-232 transceiver for SIO1. The following pins +are used:
+| Name | +Dir | +Usage | +
|---|---|---|
TX |
+O | +TX to network port (via RS-232 transceiver) |
+
RX |
+I | +RX from network port (via RS-232 transceiver) |
+
/RTS |
+O | +Shorted to /CTS to enable SIO1 |
+
/CTS |
+I | +Shorted to /RTS to enable SIO1 |
+
/DSR |
+I | +Cartridge insertion detection (grounded) | +
D0 |
+O | +Updates/latches bank 3 when pulsed | +
D1 |
+O | +Updates/latches bank 2 when pulsed | +
D3 |
+O | +Updates/latches bank 1 when pulsed | +
D4 |
+O | +Data for light output 0 (green button) | +
D5 |
+O | +Data for light output 1 (blue button) | +
D6 |
+O | +Data for light output 2 (red button) | +
D7 |
+O | +Data for light output 3 (start button) | +
? |
+O | +DTR to network port (via RS-232 transceiver) |
+
? |
+I | +DSR from network port (via RS-232 transceiver) |
+
This cartridge has three connectors:
+CN2 (5-pin): RS-232 port. Note that this port is not electrically isolated
+ and shares its ground with the 573, unlike all other cartridges with an RS-232
+ connector.CN3 (16-pin): breaks out the light outputs and the incoming 12V supply from
+ CN4.CN4 (4-pin): 12V power input, connected through a short cable to CN17 on
+ the 573 main board.All X76F041 cartridges use the following pins:
+| Name | +Dir | +Usage | +
|---|---|---|
/DSR |
+I | +Cartridge insertion detection (grounded) | +
D0 |
+O | +Drives X76F041 I2C SDA when SDA is set as output |
+
D1 |
+O | +X76F041 I2C SCL | +
D2 |
+O | +X76F041 chip select (/CS) |
+
D3 |
+O | +X76F041 reset (RST) |
+
SDA |
+IO | +X76F041 I2C SDA readout | +
X76F041 cartridges equipped with a DS2401 additionally use the following pins:
+| Name | +Dir | +Usage | +
|---|---|---|
D4 |
+O | +Drives 1-wire bus low when pulled high | +
I6 |
+I | +DS2401 1-wire bus readout | +
GX700-PWB(D))Rectangular cartridge used by the earliest 573 games and as a separate +installation key for some later games. Contains only the X76F041 EEPROM and no +DS2401, but the PCB has an unpopulated footprint for an unknown 64-pin TQFP +part.
+GX894-PWB(D))Rectangular cartridge similar to GX700-PWB(D) but equipped with a DS2401. The
+PCB has two unpopulated SOIC footprints, one of which may possibly be for an
+X76F100 or another I2C EEPROM.
GX896-PWB(A)A)Seems to be an older variant of the more common GX883-PWB(D) cartridge, with
+the same ports but no DS2401. As with the 3-player Bishi Bashi cartridge, it has
+no case and is instead meant to sit inside the 573's own case.
| Name | +Dir | +Usage | +
|---|---|---|
TX |
+O | +TX to network port (via RS-232 transceiver) |
+
RX |
+I | +RX from network port (via RS-232 transceiver) |
+
/RTS |
+O | +Shorted to /CTS to enable SIO1 |
+
/CTS |
+I | +Shorted to /RTS to enable SIO1 |
+
? |
+O | +CTRL0 to control port |
+
? |
+O | +CTRL1 to control port |
+
? |
+O | +CTRL2 to control port |
+
? |
+O | +DTR to network port (via RS-232 transceiver) |
+
? |
+I | +DSR from network port (via RS-232 transceiver) |
+
This cartridge has two connectors:
+CN2 (5-pin): electrically isolated RS-232 port. The transceiver is powered
+ by an isolated DC-DC module and all signals going from/to the 573 are
+ optoisolated.CN3 (6-pin): three 5V logic level signals, used in some cabinets to control
+ lights or the speaker amplifier.GX883-PWB(D))T-shaped cartridge with a DS2401, a "network" (RS-232) port and a "control" or +"amp box" port, commonly used by pre-ZS01 Bemani games. Uses the following pins:
+| Name | +Dir | +Usage | +
|---|---|---|
TX |
+O | +TX to network port (via RS-232 transceiver) |
+
RX |
+I | +RX from network port (via RS-232 transceiver) |
+
/RTS |
+O | +Shorted to /CTS to enable SIO1 |
+
/CTS |
+I | +Shorted to /RTS to enable SIO1 |
+
? |
+O | +CTRL0 to control port |
+
? |
+O | +CTRL1 to control port |
+
? |
+O | +CTRL2 to control port |
+
? |
+O | +DTR to network port (via RS-232 transceiver) |
+
? |
+I | +DSR from network port (via RS-232 transceiver) |
+
This cartridge has two connectors:
+GX700-PWB(J))T-shaped cartridge used only by PunchMania/Fighting Mania series. Contains an +X76F041, a DS2401 and an ADC0838 used to measure up to 8 analog inputs. The ADC +uses the following pins:
+| Name | +Dir | +Usage | +
|---|---|---|
D0 |
+O | +Chip select to ADC (/CS), shared with X76F041 SDA |
+
D1 |
+O | +Data clock to ADC (CLK), shared with X76F041 SCL |
+
D5 |
+O | +Data input to ADC (DI) |
+
I0 |
+I | +Data output from ADC (DO) |
+
I1 |
+I | +SAR status from ADC (SARS) |
+
This cartridge has two connectors:
+CN4 (10-pin): unknown purpose. Seems to be always unpopulated.PWB0000068819)T-shaped cartridge with open-drain outputs for driving up to 8 lights, arranged
+as 2 banks of 4 outputs each. Unlike the GX700-PWB(E) 3-player variant, it has
+an X76F041 (but no DS2401), lacks the RS-232 port and does not seem to be
+designed to be mounted inside the 573. The latches driving the light outputs use
+the following pins:
| Name | +Dir | +Usage | +
|---|---|---|
? |
+O | +Updates/latches bank 1 when pulsed | +
? |
+O | +Updates/latches bank 2 when pulsed | +
? |
+O | +Data for light output 0 (green button) | +
? |
+O | +Data for light output 1 (blue button) | +
? |
+O | +Data for light output 2 (red button) | +
? |
+O | +Data for light output 3 (start button) | +
This cartridge has two connectors:
+CN2 (16-pin): breaks out the light outputs and the incoming 12V supply from
+ CN3.CN3 (4-pin): 12V power input, presumably connected to the power supply
+ externally (i.e. not through the main board).PWB0000088954)T-shaped cartridge with open-drain outputs for driving up to 8 lights (although +only 6 outputs seem to be populated). Contains an X76F041, a DS2401 and two 4094 +shift registers, presumably chained. The shift registers use the following pins:
+| Name | +Dir | +Usage | +
|---|---|---|
D5 |
+O | +Shift register clock | +
D6 |
+O | +Shift register reset | +
D7 |
+O | +Shift register data | +
This cartridge has two connectors:
+All ZS01 cartridges use the following pins:
+| Name | +Dir | +Usage | +
|---|---|---|
/DSR |
+I | +Cartridge insertion detection (grounded) | +
D0 |
+O | +Drives ZS01 I2C SDA when SDA is set as output |
+
D1 |
+O | +ZS01 I2C SCL | +
D3 |
+O | +ZS01 reset | +
SDA |
+IO | +ZS01 I2C SDA readout | +
All cartridges are fitted with a DS2401, however it is connected to a GPIO pin +on the ZS01 rather than being directly exposed to the 573. The ZS01 additionally +provides its own unique serial number, which seems to be unused by games.
+GE949-PWB(D)A)ZS01 variant of the GX883-PWB(D) cartridge. Uses the following pins:
| Name | +Dir | +Usage | +
|---|---|---|
TX |
+O | +TX to network port (via RS-232 transceiver) |
+
RX |
+I | +RX from network port (via RS-232 transceiver) |
+
/RTS |
+O | +Shorted to /CTS to enable SIO1 |
+
/CTS |
+I | +Shorted to /RTS to enable SIO1 |
+
? |
+O | +CTRL0 to control port |
+
? |
+O | +CTRL1 to control port |
+
? |
+O | +CTRL2 to control port |
+
? |
+O | +DTR to network port (via RS-232 transceiver) |
+
? |
+I | +DSR from network port (via RS-232 transceiver) |
+
This cartridge has two connectors:
+GE949-PWB(D)B)T-shaped cartridge that uses the same PCB as GE949-PWB(D)A but only has the
+ZS01, DS2401 and supporting parts are populated. Used by games that do not need
+the RS-232 interface.
Most games use the security cartride's EEPROM to store, among other data such as +the game code and region, a set of up to four 8-byte identifiers.
+The serial number of the cartridge's DS2401, always present in cartridges that +have one. As per the 1-wire specification it has the following format:
+| Bytes | +Description | +
|---|---|
| 0 | +1-wire family code (0x01 for DS2401) |
+
| 1-6 | +48-bit progressive serial number, little endian | +
| 7 | +CRC8 of bytes 0-6 | +
The CRC is computed as follows:
+#define DS2401_CRC8_POLYNOMIAL 0x8c
+
+uint8_t ds2401_crc8(const uint8_t *data, size_t length) {
+ uint8_t crc = 0;
+
+ for (; length; length--) {
+ uint8_t value = *(data++);
+
+ for (int bit = 8; bit; bit--) {
+ uint8_t temp = crc ^ value;
+
+ value >>= 1;
+ crc >>= 1;
+ if (temp & 1)
+ crc ^= DS2401_CRC8_POLYNOMIAL;
+ }
+ }
+
+ return crc & 0xff;
+}
+Refer to the DS2401 datasheet and Maxim 1-wire documentation for more details.
+Seems to be a cartridge-type-agnostic serial number. On cartridges without a +DS2401 the trace ID is assigned by Konami at manufacture time (see the master +calendar section) and has the following format:
+| Bytes | +Description | +
|---|---|
| 0 | +Trace ID type (0x81) |
+
| 1-2 | +16-bit "main" serial number, big endian | +
| 3-6 | +32-bit "sub" serial number, big endian | +
| 7 | +Checksum (sum of bytes 0-6 xor'd with 0xff) |
+
On cartridges with a DS2401 the trace ID is instead derived from the SID:
+| Bytes | +Description | +
|---|---|
| 0 | +Trace ID type (0x82) |
+
| 1-2 | +DS2401 serial number hash, big or little endian depending on game | +
| 3-6 | +Reserved (must be 0) | +
| 7 | +Checksum (sum of bytes 0-6 xor'd with 0xff) |
+
The hash is calculated over bytes 1-6 of the SID (excluding the family code and +CRC8) using the following algorithm:
+// Note that some games set this to 14 instead of 16.
+#define TRACE_ID_HASH_BIT_WIDTH 16
+
+uint16_t trace_id_hash(const uint8_t *data, size_t length) {
+ uint16_t hash = 0;
+
+ for (size_t i = 0; i < (length * 8); i += 8) {
+ uint8_t value = *(data++);
+
+ for (size_t j = i; j < (i + 8); j++, value >>= 1) {
+ if (value & 1)
+ hash ^= 1 << (j % TRACE_ID_HASH_BIT_WIDTH);
+ }
+ }
+
+ return hash;
+}
+Seems to be some kind of cartridge type flag, possibly indicating whether the +cartridge shall be used during or after game installation, or if it was used +when performing a game upgrade and shall no longer be usable to run the game it +initially shipped with.
+| Bytes | +Description | +
|---|---|
| 0 | +Cartridge type? (always 0x00, 0x01 or 0x02) |
+
| 1-6 | +Reserved (must be 0) | +
| 7 | +Checksum (sum of bytes 0-6 xor'd with 0xff) |
+
NOTE: 00 00 00 00 00 00 00 00 seems to be a valid MID value, despite
+having an otherwise invalid checksum, and to have a different meaning from
+00 00 00 00 00 00 00 ff.
The serial number of the digital I/O board's DS2401, written to the cartridge
+during installation by most games that use it in order to prevent reinstallation
+on a different system. Has the same format as the SID. On a cartridge that has
+not yet been paired to a 573 the XID is set to 00 00 00 00 00 00 00 00.
When finishing installation or attempting to use a cartridge with a mismatching
+XID the game will display the digital I/O board's serial number as an 8-digit
+value (XXXX-YYYY), generated as follows:
// Some games seem to only use the lower 32 bits of the DS2401's serial number,
+// while others use all 48 bits.
+size_t xid_to_string_32(char *output, const uint8_t *xid) {
+ uint32_t value = 0
+ | (xid[1] << 0)
+ | (xid[2] << 8)
+ | (xid[3] << 16)
+ | (xid[4] << 24);
+
+ int high = (value / 10000) % 10000;
+ int low = value % 10000;
+
+ return sprintf(output, "%04d-%04d", high, low);
+}
+
+size_t xid_to_string_48(char *output, const uint8_t *xid) {
+ uint64_t value = 0
+ | (xid[1] << 0)
+ | (xid[2] << 8)
+ | (xid[3] << 16)
+ | (xid[4] << 24)
+ | (xid[5] << 32)
+ | (xid[6] << 40);
+
+ int high = (int) ((value / 10000) % 10000);
+ int low = (int) (value % 10000);
+
+ return sprintf(output, "%04d-%04d", high, low);
+}
+Cartridges for games that use the digital I/O board typically come with a blank +label onto which the 8-digit ID can be written by the operator, to help keep +track of which cartridge goes into which system after installation.
+Note that games that use other I/O boards with a DS2401, such as Kick & Kick +and DDR Karaoke Mix, do not seem to write those boards' serial numbers to the +cartridge; they are stored in the internal flash memory instead.
+Over the 573's lifetime Konami introduced several add-ons that extended its +functionality. Unlike the I/O boards, these were external to the 573 unit and +not always mandatory. Not much is currently known about any of these.
+GN845-PWB(A))A relatively simple lamp driver board, controlled by the optoisolated outputs +from the analog or digital I/O board. Commonly mounted in a metal box alongside +audio amplifier boards in most cabinets.
+GN845-PWB(B))Sits between the 573 and the sensors in each stage's arrow panels in Dance +Dance Revolution cabinets. It is based on a Xilinx XC9536 CPLD and allows the +573 to check the status of a specific pressure sensor (each panel has 4 +sensors, one along each edge), in addition to ensuring DDR games can only be +played with an actual stage rather than just a joystick or buttons wired up to +the 573's JAMMA connector. Konami kept using the same board long after the 573 +was discontinued, with the last game to use it being DDR X/X2 (PC based).
+Each stage's board communicates with the 573 over 6 wires, of which 4 are the +up/down/left/right signals going to the JAMMA connector and 2 are light outputs +from the I/O board being misused as data and clock lines (see above). The board +initially asserts the right and up signals and waits for the 573 to issue an +initialization command by bitbanging it over the light outputs. Received bits +are acknowledged by the board by echoing them on the right signal and toggling +the up signal.
+Once initialization is done the board goes into passthrough mode, asserting the +up/down/left/right signals whenever any of the respective arrow panels' sensors +are pressed. The 573 can issue another command to retrieve the status of each +sensor separately, which is then sent by the board in serialized form over the +right and up signals. DDR games only use this command to display sensor status +in the operator menu, no commands are sent to the board during actual gameplay.
+The initialization protocol is currently unknown. The protocol used after +initialization is partially known (see links) but needs to be verified and +documented properly.
+GE885-PWB(A))A ridiculously overengineered JVS board providing support for accessing PS1 +controllers and memory cards plugged into ports on the front of the cabinet. +Contains a Toshiba TMPR3904 CPU, a Xilinx XCS10XL Spartan-XL FPGA, 512 KB of RAM +and a 512 KB boot ROM; the ROM is only a small bootloader and the actual +firmware is downloaded from the 573 into RAM. There are also two connectors for +security dongles. Returns the following JVS identifier string:
+KONAMI CO.,LTD.;White I/O;Ver1.0;White I/O PCB
+Memory card support became common in later Bemani games, allowing players to +save their scores and play custom charts. GuitarFreaks is the only game known +to support external controllers through this board.
+PWB0000085445)Combines two 32 MB PCMCIA flash cards into the same address space, allowing them +to be accessed as if they were a single 64 MB card. Connects to the 573 through +a cable that plugs into a passive PCMCIA slot adapter. Only used by PunchMania +2.
+PWB0000100991)Used by some Bemani games, in particular later GuitarFreaks and DrumMania +releases. Provides networking functionality (DHCP and TCP/UDP sockets) as well +as a 10 or 20 GB IDE hard drive for storage of downloaded content. The module +contains a Toshiba TMPR3927 CPU, a Xilinx XC2S100 Spartan-2 FPGA, 16 MB of RAM, +a 512 KB boot ROM and a DP83815 PCI Ethernet MAC. As with the controller and +memory card adapter, the bulk of the firmware seems to be loaded from the 573. +Connects through PCMCIA slot 2, using the same cable and adapter as the +PunchMania PCMCIA splitter.
+GXA25-PWB(A))A fairly large box containing a Toshiba TMPR3927 CPU, a Xilinx XC2S200 Spartan-2 +FPGA and four (!) hardware MP3 decoders. It comes with up to four daughterboards +installed, each of which hosts a stereo DAC and has RCA jacks for audio input +and output plus a mini-DIN connector for RS-232 communication with a cabinet. +The box also has its own ATAPI CD-ROM drive and power supply.
+Its purpose is to enable "session mode" in later Bemani games, which allows for +the same song to be played on multiple games at the same time with the box +playing the backing tracks and routing audio between the machines. It connects +to each cabinet's 573 using RS-232, through the "network" port on the security +cartridge.
+A JVS device used internally by Konami to initialize motherboards and security +cartridges during manufacturing. The exact hardware Konami used is unknown, but +the protocol can be inferred from game code. All games search the JVS bus on +startup and enter a "factory test" mode if any device with the following +identifier string is present:
+KONAMI CO.,LTD.;Master Calendar;<any value>;<any value>
+The game will then proceed to request the current date, time, game and region +information from the master calendar, initialize the RTC and program the +security cartridge. The master calendar also returns a unique trace ID (see the +cartridge data formats section) for each 573, used for identification purposes +on cartridges that lack a DS2401.
+0x70: Get date and time0x71: Get game region or initialization data0x7c, 0x7f, 0x00: Get trace ID "main" serial number0x7c, 0x80, 0x00: Get trace ID "sub" serial number0x7d, 0x80, 0x10: Get next ID0x7e: Set DS2401 identifiers0x7f: Unknown0xf0: Reset master calendarThe System 573's BIOS is based on a slightly modified version of Sony's standard
+PS1 kernel, plus a custom shell executable. The kernel identifies itself as
+Konami OS by T.H. and seems to have been used across all Konami PS1-based
+arcade boards. The kernels used by other manufacturers' arcade boards also
+contain the same T.H. initials, possibly hinting at the fact there was a
+single Sony employee in charge of providing customized kernels to all arcade
+system manufacturers.
The only meaningful difference from the PS1 kernel is that most CD-ROM APIs, the
+ISO9660 driver and the cdrom: device are missing, as the 573 lacks the PS1's
+CD-ROM hardware. All other functionality, such as controller and memory card
+drivers, is still present and no new functionality was added (drivers for
+573-specific hardware are simply statically linked into the shell and game
+executables instead).
There seem to be either three or four different versions of the BIOS, all of +which share the same kernel but feature different shells:
+| ROM marking | +MAME ROM name | +SHA-1 | +Used by | +
|---|---|---|---|
700A01 |
+700a01.22g |
+e1284add4aaddd5337bd7f4e27614460d52b5b48 |
+Most games | +
700A01 |
+700a01,gchgchmp.22g |
+9aab8c637dd2be84d79007e52f108abe92bf29dd |
+Gachagachamp | +
700A01 |
++ | + | Unknown (undumped, see below) | +
700B01 |
+700b01.22g |
+a2421d0a494892c0e71003c96995ce8f945064dd |
+Dancing Stage EuroMIX 2 | +
700A01 is the earliest and most common version. The only difference between
+the two known variants of it is that they were linked to slightly different Sony
+SDK releases; Konami's own code is identical across the two. There reportedly is
+a third variant that shipped on systems that came with the JVS MCU unpopulated
+(presumably it would skip the check for it), however no evidence of its
+existence has ever been found. The shell is stored in ROM in both variants at
+0xbfc40000, in the form of a standard PS1 executable (including the header)
+that gets loaded at 0x803c0000 by the kernel.
700B01 has a more complicated structure: it is split up into two separate
+executables, one (at 0xbfc28000, loaded at 0x80010000) in charge of running
+the self-test sequence and the other (at 0xbfc60000, loaded at 0x80380000)
+handling CD-ROM or flash booting. The overall coding style suggests that it was
+developed alongside the installers/launchers used by later Bemani games, but
+dropped as the main feature it would have introduced over the 700A01 shell -
+CF card support - was broken due to a PCB wiring mistake.
All variants of the shell are far simpler than their PS1 counterparts, as they +lack any kind of UI (aside from a non-interactive status screen) and have no +copy protection or anti-piracy checks of any kind. Once loaded by the kernel, +they start by initializing the system bus and proceed to run a hardware +self-test. The outcome of all checks is displayed on screen, with the following +ones being performed:
+22G: BIOS ROM integrity check. A checksum is calculated and compared to the
+ one stored at the end of the ROM;16H, 16G, 14H, 14G: main RAM read/write test (first row of chips on
+ the board, closest to the CPU);12H, 12G, 9H, 9G: main RAM read/write test (second row of chips on the
+ board, closest to the JAMMA connector);4L, 4P: VRAM read/write test. This causes the 573 to briefly display
+ random pixels as framebuffers are overwritten during the check;10Q: SPU RAM read/write test;18E: JVS MCU reset and status check;CDR: ATAPI CD-ROM drive initialization and executable loading.NOTE: 700A01 shells do not actually test 4P! The GPU starts up in 1 MB
+VRAM mode by default and the shell does not enable the chip select for the
+second bank, so the first VRAM chip is tested twice instead. This bug was fixed
+in the 700B01 shell, which initializes the GPU correctly.
If any check fails the shell locks up, shows a blinking "HARDWARE ERROR... +RESET" prompt and stops clearing the watchdog after a few seconds, causing the +573 to reboot. Otherwise, the state of DIP switch 4 is checked and the shell +attempts to load an executable from four different sources in the following +order:
+PSX.EXE in the root directory of the disc inserted in the CD-ROM drive. The
+ drive is only initialized after booting from flash or PCMCIA fails or if DIP
+ switch 4 is off, thus the shell will not error out if a drive is not connected
+ but a boot executable is present on the flash. Note that the drive must be set
+ up as an IDE primary/master device using the appropriate jumpers.As with Sony's PS1 shell, the 573 shell's ISO9660 filesystem driver only
+implements a minimal subset of the specification and may not properly support
+non-8.3 file names. It also only allocates 2 KB for the disc's path table,
+so the total number of directories on the disc must be kept to a minimum in
+order to prevent the shell from crashing. Unlike the PS1, however, the 573
+ignores SYSTEM.CNF completely regardless of whether or not it is present on
+the disc; the shell is hardcoded to always load PSX.EXE. Homebrew discs can
+take advantage of this behavior to provide separate PS1 and 573 executables
+instead of detecting the system type at runtime.
If DIP switch 4 is on, the shell expects to find a standard PS1 executable
+(including the full 2048-byte header) at offset 0x24 on either the built-in
+flash memory or one of the two PCMCIA flash cards, preceded by a CRC32 checksum
+of it at offset 0x20. The CRC is stored in little endian format and is not
+calculated on the whole executable, but rather only on bytes whose offsets are a
+power of two (i.e. on bytes at 0x24 + 0, 0x24 + 1, 0x24 + 2, 0x24 + 4
+and so on). The check is implemented as follows:
#define EXE_CRC32_POLYNOMIAL 0xedb88320 // 0x04c11db7 bit-reversed
+
+uint32_t exe_crc32(const uint8_t *data, size_t length) {
+ size_t offset = 0;
+ uint32_t crc = 0xffffffff;
+
+ while (offset < length) {
+ crc ^= data[offset];
+
+ for (int bit = 8; bit; bit--) {
+ uint16_t temp = crc;
+
+ crc >>= 1;
+ if (temp & 1)
+ crc ^= EXE_CRC32_POLYNOMIAL;
+
+ if (offset)
+ offset <<= 1;
+ else
+ offset = 1;
+ }
+ }
+
+ return ~crc;
+}
+
+#define DIP_SWITCH_PTR ((const uint32_t *) 0x1f400004)
+#define EXE_CRC32_PTR ((const uint32_t *) 0x1f000020)
+#define EXE_HEADER_PTR ((const uint8_t *) 0x1f000024)
+// Offset of the "text section size" field within the executable header
+#define EXE_TEXT_SIZE_PTR ((const uint32_t *) 0x1f000040)
+
+bool is_exe_valid(void) {
+ if (*DIP_SWITCH_PTR & (1 << 3)) // 1 = DIP switch off
+ return false;
+ if (memcmp(EXE_HEADER_PTR, "PS-X EXE", 8))
+ return false;
+
+ size_t length = 2048 + *EXE_TEXT_SIZE_PTR;
+ uint32_t crc = exe_crc32(EXE_HEADER_PTR, length);
+
+ return (crc == *EXE_DATA_PTR);
+}
+Installing a new game usually involves inserting the installation disc and +turning off DIP switch 4 in order to prevent the shell from booting the game +currently installed on the internal flash.
+PS1 executables are generally launched with CPU registers $a0 and $a1 set to
+zero, in order to make sure programs that interpret them as argc and argv
+respectively will not crash by trying to parse invalid data. The 700A01 shell
+follows this convention.
The 700B01 shell, however, does pass two arguments to the executable it loads.
+$a0 is thus set to 2, while $a1 is set to point to an array containing
+pointers to the following strings:
boot.rom=700B01boot.from=<device>, where <device> is one of the following:flash.0 (internal flash memory)flash.1 (PCMCIA flash card in slot 1)flash.2 (PCMCIA flash card in slot 2)ata.2 (CF card in slot 2)cdromThe launchers used by later Bemani games use these arguments if present to +determine where to load the main game executable from, and fall back to +autodetecting the game's installation location otherwise.
+The JVS MCU check is implemented in a different way between the two shell
+revisions. While the 700A01 shell simply resets the MCU and validates the
+status and error codes, the 700B01 self-test sequence performs 35 (!)
+different checks, each validating the codes returned under different conditions.
+The following tests are done:
JVSIRDY, ensure that:JVSIRDY = 0JVSDRDY = 00x00000x00e0), ensure that:0x001f), ensure that:0x1fe0, 0x0004, 1 << i, checksum),
+ for each packet ensure that:It is currently unclear if any data is actually sent to the JVS bus during step +4, as the shell may reset the MCU it before it starts sending the packet.
+Even though neither of the shell versions was explicitly designed with DVD-ROM +support in mind, it is possible to run games from a DVD-ROM thanks to the fact +that the ATAPI commands used by the shell and games to read sectors from the +disc are medium-agnostic. Games that rely on CD-DA playback obviously cannot be +put on a DVD, however all other games (including ones that rely on the digital +I/O board for MP3 playback) will work as long as the disc is formatted as if it +were a typical 573 CD-ROM (ISO9660 with no extensions, no UDF, 8.3 file names +and a path table smaller than 2 KB).
+NOTE: due to ATAPI incompatibility issues only a very limited number of +DVD-ROM drives will actually be recognized and work properly with the shells and +games. This is unrelated to the DVD format itself and is purely due to the fact +that, unlike CD-ROM drives, most DVD drives were manufactured after the ATAPI +specification got updated in a way that broke the 573's compatibility.
+This accidental capability was greatly abused by bootleg Bemani "superdiscs" +that bundled multiple games on a single DVD-ROM and shipped with a modified +installation menu, allowing the user to pick which game to install. Each game on +a superdisc is patched to load its files from a subdirectory rather than from +the DVD's root.
+Homebrew 573 software can be distributed as an ISO9660 image larger than 650 MB
+meant to be burned to a DVD-R, if sacrificing PS1 compatibility and CD-DA
+support is an option. In such case the image shall be distributed as an .iso
+file with 2048-byte sectors, rather than the typical .bin and .cue file pair
+used for PS1 games with 2352-byte Mode 2 sectors.
In addition to booting from "linear" memory mapped PCMCIA flash cards, the
+700B01 shell features a driver for CF cards and a FAT filesystem parser that
+allows it to mount a CF card inserted in PCMCIA slot 2 (via a passive
+CF-to-PCMCIA adapter), search for a flash card image file and interpret its
+contents as if it were an actual flash card, loading the executable directly
+from it. Or at least, that would allow it to do so, had Konami not screwed up
+the wiring of the PCMCIA slots.
CF cards can operate in three different interfacing modes: memory mapped, I/O
+mapped and IDE compatibility mode. On the 573 only memory mapped mode is
+accessible as the other modes require usage of I/O chip select pins that are not
+connected. This mode, however, requires the host to issue 8-bit writes to the
+card's 16-bit bus through the use of individual chip select lines for each byte
+(/CE1 and /CE2). While the PS1's CPU does have separate lower (/WR0) and
+upper (/WR1) byte write strobes that could have been easily adapted to the
+appropriate signals, Konami decided to cut this specific corner and shorted
+/CE1 and /CE2 on each PCMCIA slot together, making it impossible to issue a
+single-byte write.
NOTE: later revisions of the 573 main board seem to have unpopulated jumpers +next to the PCMCIA slots that can be used to rewire the chip select signals. It +is currently unclear if these jumpers are actually sufficient to enable CF card +booting without any additional hardware or BIOS modifications.
+It is not uncommon to find 573s fitted with a bootleg BIOS "mod board" in place
+of the stock 700A01 or 700B01 mask ROM. These boards used to be bundled
+alongside bootleg game CD-ROMs and were apparently required in order to bypass
+the "anti-piracy checks" in Konami's BIOS.
Of course, since neither version of the shell has any such checks, the claims +were completely misleading. The actual purpose of these boards was not to tamper +with the BIOS, but rather to piggyback on the system bus and provide a crude +authentication mechanism to the bootleg game, allowing it to verify that it was +indeed running on a 573 equipped with an appropriate mod board. In other words, +mod boards were actually the bootleggers' implementation of Konami's +security cartridge system, meant to prevent people from simply burning +copies of a bootleg CD-ROM and forcing them to buy bootleg kits from whoever +produced them instead. Oh the irony.
+The added authentication circuitry will not create any issues with official nor +homebrew software, however most of these boards feature an additional party +trick: the shell executable is altered to load a differently named executable, +making bootleg discs unable to boot on a stock 573 and vice versa. The following +names have been found so far in modified BIOS ROMs:
+QSY.DXDSSW.BXFTSV.AXGGSE.NXXNSE.GXXThe following names have been found on unofficial game discs, but are not +confirmed to have ever been used in modified BIOS ROMs:
+OSE.FXXQSU.DXHQSX.DXEQSZ.DXCRSU.CXHRSV.CXGRSW.CXFRSZ.CXCSSX.BXESSY.BXDTSW.AXFTSX.AXETSY.AXDTSZ.AXCHomebrew software should thus place multiple copies of the boot executable on +the CD-ROM to ensure any BIOS, modded or not, can successfully load it. An +interesting side note is that, for any of these names, summing the ASCII codes +of each character will always yield the same result. Presumably bootleggers were +unable to find the code in charge of BIOS ROM checksum validation and found it +easier to just turn the string into random nonsense whose checksum collided with +the original one.
+Fisherman's Bait and a few other non-Bemani games use a 573 housed in a black +case with blue front and back panels. Unlike the gray metal cases used by other +games, this case model has no cutouts for removable front and back panels that +hold game-specific connectors and instead has a fixed set of ports exposed:
+CN17.CN3 on
+ the main board.CN5 on the
+ motherboard.GE765-PWB(B)A fishing controller I/O board. Probably missing on systems that
+ that did not come with Fisherman's Bait.Dance Dance Revolution uses a 573 enclosed in a gray metal case, with either an +analog or digital I/O board installed. The front panel has a cutout covered by a +metal plate, which in turn holds the following connectors:
+The back panel has a similar cutout, covered by a plate with holes for the +digital I/O board's RCA networking jacks.
+Dance Dance Revolution cabinets (standard 2-player ones, not Solo) have lights +wired up to the analog or digital I/O board as follows:
+| Output | +Connected to | +
|---|---|
| A0 | +Player 1 up arrow | +
| A1 | +Player 1 down arrow | +
| A2 | +Player 1 left arrow | +
| A3 | +Player 1 right arrow | +
| A4 | +Data to player 1 stage I/O | +
| A5 | +Clock to player 1 stage I/O | +
| A6-A7 | +Unused | +
| B0 | +Player 2 up arrow | +
| B1 | +Player 2 down arrow | +
| B2 | +Player 2 left arrow | +
| B3 | +Player 2 right arrow | +
| B4 | +Data to player 2 stage I/O | +
| B5 | +Clock to player 2 stage I/O | +
| B6-B7 | +Unused | +
| C0-C1 | +Unused | +
| C2 | +Player 1 buttons | +
| C3 | +Player 2 buttons | +
| C4 | +Bottom right marquee light | +
| C5 | +Top right marquee light | +
| C6 | +Bottom left marquee light | +
| C7 | +Top left marquee light | +
| D0 | +Speaker neon | +
| D1-D3 | +Unused | +
Light outputs A4, A5, B4 and B5 do not actually control any lamps, but are used +to communicate with each stage's I/O board. See the external modules section +for more details.
+Dance Dance Revolution Solo cabinets, unlike 2-player cabinets, do not use a +stage I/O board to multiplex the sensors as each arrow panel only has 2 sensors +(rather than 4). Each sensor is instead wired directly to the JAMMA connector, +making use of most of the available inputs.
+| JAMMA input | +Connected to | +
|---|---|
| Player 1 left | +Left sensor A | +
| Player 1 right | +Right sensor A | +
| Player 1 up | +Up sensor A | +
| Player 1 down | +Down sensor A | +
| Player 1 button 1 | +Up-left sensor B | +
| Player 1 button 2 | +Left sensor B | +
| Player 1 button 3 | +Down sensor B | +
| Player 1 button 4 | +Unused | +
| Player 1 button 5 | +Left button | +
| Player 1 start | +Start button | +
| Player 2 left | +Up-left sensor A | +
| Player 2 right | +Up-right sensor A | +
| Player 2 up | +Unused | +
| Player 2 down | +Unused | +
| Player 2 button 1 | +Up sensor B | +
| Player 2 button 2 | +Right sensor B | +
| Player 2 button 3 | +Up-right sensor B | +
| Player 2 button 4 | +Unused | +
| Player 2 button 5 | +Right button | +
| Player 2 start | +Unused (shorted?) | +
The light mapping is currently unknown. Solo cabinets have less lights compared +to their 2-player counterparts (e.g. arrow panel lamps are missing).
+First-generation DrumMania cabinets have lights wired up to the I/O board as +follows:
+| Output | +Connected to | +
|---|---|
| A0-A7 | +Unused | +
| B0-B7 | +Unused | +
| C0 | +Hi-hat | +
| C1 | +Snare | +
| C2 | +High tom | +
| C3 | +Low tom | +
| C4 | +Cymbal | +
| C5 | +Unused | +
| C6 | +Start button | +
| C7 | +Select button | +
| D0 | +Spotlight | +
| D1 | +Top neon | +
| D2 | +Unused | +
| D3 | +Bottom neon | +
The wiring was changed in later cabinets, which use the following mapping +instead:
+| Output | +Connected to | +
|---|---|
| A0 | +Hi-hat | +
| A1 | +Snare | +
| A2 | +High tom | +
| A3 | +Low tom | +
| A4-A7 | +Unused | +
| B0 | +Spotlight | +
| B1 | +Bottom neon | +
| B2 | +Top neon | +
| B3 | +Unused | +
| B4 | +Cymbal | +
| B5 | +Unused | +
| B6 | +Start button | +
| B7 | +Select button | +
| C0-C7 | +Unused | +
| D0-D3 | +Unused | +
It is relatively easy to develop homebrew games that can run on both a System +573 and a regular PlayStation 1, or to port existing PS1 homebrew to the 573. +Nevertheless, there are some significant differences between the two systems +and a game meant to run on both shall avoid using any feature that is only +available on one. "Hybrid" PS1/573 games shall adhere to the following +guidelines:
+SYSTEM.CNF while the 573 BIOS ignores it, a disc can have two different
+ executables, one named PSX.EXE (which will be launched on a 573) and the
+ other (which will run on a PS1) referenced by SYSTEM.CNF. This makes it
+ easier to have two separate builds of the game rather than having to detect
+ system type at runtime. Additional copies of PSX.EXE with the file names
+ commonly used by BIOS mod boards (QSY.DXD, TSV.AXG and so on) shall also
+ be present.The 573 only supports 60 Hz mode (i.e. "NTSC", even though the video DAC has no
+composite or S-video output so no color modulation is involved). Attempting to
+switch the GPU into 50 Hz PAL mode using the GP1(0x08) command will result in
+a crash, as only the NTSC clock input pin is wired up.
Support for 50 Hz can be added back by shorting pins 192 and 196 on the GPU +(which will give "PAL-on-NTSC" timings) or by connecting pin 192 to an external +oscillator tuned to generate a PAL clock. See the timings section of the GPU +page for more details.
+The PCMCIA flash cards required by most 573 games are "linear" (memory mapped) +cards consisting of one or more parallel flash memory chips wired directly to +the bus, rather than CF or ATA-compatible cards. As neither linear cards nor +parallel flash command sets are fully standardized, working with these cards may +be difficult without some prior knowledge.
+There are two main variants of such cards:
+0x9090 to issue the
+ 0x90 JEDEC ID command). Issuing 8-bit writes to a single chip is not
+ supported on the 573 due to the way chip select lines are wired up; see the
+ BIOS CF card support section for more details.Konami's flash driver only supports 8-bit cards that use one of the following +chips:
+| Manufacturer | +Chip | +Capacity | +Manuf. ID | +Device ID | +
|---|---|---|---|---|
| Fujitsu | +MBM29F016A | +2 MB | +0x04 |
+0xad |
+
| Fujitsu | +MBM29F017A | +2 MB | +0x04 |
+0x3d |
+
| Fujitsu | +MBM29F040A | +512 KB | +0x04 |
+0xa4 |
+
| Intel | +28F016S5 | +2 MB | +0x89 |
+0xaa |
+
| Sharp | +LH28F016S | +2 MB | +0x89 |
+0xaa |
+
Most games, including the launchers used by later Bemani games, will check the +JEDEC IDs of the cards' chips on startup and reject any unsupported chip, +even if valid game data is otherwise present on the card. This makes it +impossible to manually install a game onto an unsupported card (e.g. through +homebrew tools) without also patching the launcher in order to skip the check.
+The 573 main board seems to always be fitted with either MBM29F016A or LH28F016S +chips. The internal flash memory is accessed using the same driver as the flash +cards and has the same caveats (having to issue commands to two chips at once +and so on).
+This is an incomplete list of PCMCIA flash cards that are known to work, or not +to work, with Konami's flash driver. Due to the JEDEC ID checks, only cards that +contain flash chips listed in the previous section will work.
+| Manufacturer | +Model | +Flash chips | +Capacity | +Bus type | +Manuf. ID | +Device ID | +Working | +Notes | +
|---|---|---|---|---|---|---|---|---|
| Centennial | +PM24265, FL32M-20-*-67 | +16x 28F016S5 | +32 MB | +8-bit | +0x8989 |
+0xaaaa |
+Yes | ++ |
| 4x 28F640J5 | +32 MB | +16-bit | +0x0089 |
+0x0015 |
+No | ++ | ||
| 16x AM29F016 | +32 MB | +8-bit | +0x0101 |
+0xadad |
+No | +Same command set as Fujitsu cards, may work with minimal game patching | +||
| Fujitsu | +"32MB Flash Card" (no model number) | +16x MBM29F016A | +32 MB | +8-bit | +0x0404 |
+0xadad |
+Yes | +Stock card (Konami "FLASH CARD" sticker covers Fujitsu logo) | +
| Fujitsu | +"32MB Flash Card" (no model number) | +16x MBM29F017A | +32 MB | +8-bit | +0x0404 |
+0x3d3d |
+Yes | +Stock card (Konami "FLASH CARD" sticker covers Fujitsu logo) | +
| Sharp | +ID245P01 | +16x LH28F016S | +32 MB | +8-bit | +0x8989 |
+0xaaaa |
+Yes | +Stock card (Konami "FLASH CARD" sticker covers Sharp logo) | +
Note that all Centennial cards have identical labels and can only be told apart +from the model number printed on the bottom side.
+This is an incomplete list of drives that are known to work, or to be +incompatible, with the ATAPI driver Konami used in the BIOS shell and games. The +driver was likely written using an old version of the ATAPI specification as a +reference; CD-ROM drives manufactured in the late 1990s and very early 2000s +have a higher chance of being compatible than drives manufactured later, +possibly due to changes introduced in later revisions of the ATAPI specification +that broke the assumptions Konami's driver makes.
+CD-DA playback is particularly problematic as Konami's code seems to be unable +to handle the subtle implementation differences across different drives. To add +insult to injury, some of the few drives that do work have bugs in their +subchannel handling that result in incorrect playback status data being reported +to the 573, completely breaking pre-digital-I/O Bemani titles that rely heavily +on audio timing.
+| Manufacturer | +Model | +Type | +BIOS | +CD-DA | +Notes | +
|---|---|---|---|---|---|
| ASUSTeK | +DVD-E616P3 | +DVD | +Yes | +Unknown | ++ |
| Compaq | +CRN-8241B | +CD | +Yes | +Yes | +Laptop drive, has CD-DA sync issues | +
| Creative | +CD4832E | +CD | +Yes | +No | ++ |
| Hitachi | +CDR-7930 | +CD | +Yes | +No | ++ |
| LG | +GCE-8160B | +CD | +Yes | +No | ++ |
| LG | +GCR-8523B | +CD | +Yes | +Unknown | ++ |
| LG | +GDR-8163B | +DVD | +Yes | +Yes | ++ |
| LG | +GDR-8164B | +DVD | +Yes | +Yes | ++ |
| LG | +GH22LP20 | +DVD | +Yes | +Unknown | ++ |
| LG | +GH22NP20 | +DVD | +Yes | +Unknown | ++ |
| DVD | +No | ++ | + | ||
| Lite-On | +LH-18A1H | +DVD | +Yes | +Yes | ++ |
| Lite-On | +LTD-163 | +DVD | +Yes | +Unknown | ++ |
| Lite-On | +LTD-165H | +DVD | +Yes | +Unknown | ++ |
| Lite-On | +LTR-40125S | +CD | +Yes | +Unknown | ++ |
| Lite-On | +SHW-160P6S | +DVD | +Yes | +Unknown | ++ |
| Lite-On | +XJ-HD166S | +DVD | +Yes | +Unknown | ++ |
| Matsushita | +CR-583 | +CD | +Yes | +Yes | +Stock drive | +
| Matsushita | +CR-587 | +CD | +Yes | +Yes | +Stock drive, can't read CD-R | +
| Matsushita | +CR-589B | +CD | +Yes | +Yes | +Stock drive | +
| Matsushita | +SR8589B | +DVD | +Yes | +Unknown | ++ |
| Mitsumi | +CRMC-FX4830T | +CD | +Yes | +Unknown | ++ |
| NEC | +CDR-1900A | +CD | +Yes | +Unknown | ++ |
| DVD | +No | ++ | + | ||
| Panasonic | +CR-594C | +CD | +Yes | +Unknown | ++ |
| Panasonic | +UJDA770 | +CD? | +Yes | +Unknown | +Laptop drive | +
| Sony | +CRX217E | +CD | +Yes | +Unknown | ++ |
| Sony | +DRU-510A | +DVD | +Yes | +Unknown | ++ |
| Sony | +DRU-810A | +DVD | +Yes | +Unknown | ++ |
| TDK | +AI-CDRW241040B | +CD | +Yes | +Unknown | ++ |
| TDK | +AI-481648B | +CD | +Yes | +Unknown | ++ |
| TEAC | +CD-W552E | +CD | +Yes | +Unknown | ++ |
| Toshiba | +TS-H292C | +CD | +Yes | +Unknown | ++ |
| Toshiba | +XM-5702B | +CD | +Yes | +Unknown | ++ |
| Toshiba | +XM-6102B | +CD | +Yes | +No | +Has issues with homebrew | +
| Toshiba | +XM-7002B | +CD | +Yes | +Unknown | +Stock drive, laptop drive | +
NOTE: Konami shipped some units with a Toshiba XM-7002B laptop drive and a
+passive adapter board (GX874-PWB(B)) to break out the drive's signals to a
+regular 40-pin IDE connector. Laptop drives seem to have been first used by
+Konami in the GXA25-PWB(A) multisession unit.
The installers and launchers used by Bemani titles that require the digital I/O +board have an extensive error and status reporting system. Launcher messages are +easily recognizable as they are always displayed in a blue window and have a +3-digit status code, however Japanese versions of the games will show them in +Japanese with no way to switch language (short of patching the launcher; all +launcher variants contain both English and Japanese strings).
+Below is a list of all messages in both English and Japanese, along with the +respective status codes and indices in the launcher's internal message array.
+| Index | +Type | +Status codes | +Description (English) | +Description (Japanese) | +
|---|---|---|---|---|
| 0 | +Error | +100 | +Boot is not available from this device. |
+このデバイスからのブートはできません. |
+
| 1 | +Error | +101 | +Digital Sound PCB intialization failed. |
+デジタルサウンド基板の初期化に失敗しました. |
+
| 2 | +Error | +102 | +Digital Sound PCB ROM error. |
+デジタルサウンド基板ROMエラー. |
+
| 4 | +Error | +104 | +CD-ROM initialization failed. |
+CD-ROMドライブの初期化に失敗しました. |
+
| 7 | +Error | +107 | +File system mounting failed. |
+ファイルシステムのマウントに失敗しました. |
+
| 9 | +Error | +109 | +File system mounting failed. |
+ファイルシステムのマウントに失敗しました. |
+
| 10 | +Error | +110 | +File system mounting failed. |
+ファイルシステムのマウントに失敗しました. |
+
| 11 | +Error | +111 | +File system mounting failed. |
+ファイルシステムのマウントに失敗しました. |
+
| 12 | +Error | +112 | +File system mounting failed. |
+ファイルシステムのマウントに失敗しました. |
+
| 13 | +Error | +113 | +Disc device initialization failed. |
+ディスクデバイスの初期化に失敗しました. |
+
| 14 | +Error | +114 | +You are using an incorrect CD-ROM. |
+CD-ROMが違います. |
+
| 15 | +Error | +115 | +Disc device initialization failed. |
+ディスクデバイスの初期化に失敗しました. |
+
| 16 | +Error | +116 | +Disc device initialization failed. |
+ディスクデバイスの初期化に失敗しました. |
+
| 17 | +Error | +117 | +Config file error. |
+コンフィグファイルエラー. |
+
| 19 | +Error | +119 | +You are using an incorrect CD-ROM. |
+CD-ROMが違います. |
+
| 20 | +Error | +120 | +Cassette is not installed. |
+カセットがセットされていません. |
+
| 21 | +Error | +121 | +Cassette error. (%d1) |
+カセットエラー (%d1) |
+
| 25 | +Error | +125 | +Boot is not available from this device. |
+このデバイスからゲームのブートはできません. |
+
| 26 | +Error | +126 | +Cassette error (%d1) |
+カセットエラー (%d1) |
+
| 27 | +Error | +127 | +Master Calendar network error. |
+マスターカレンダー通信エラー. |
+
| 28 | +Error | +128 | +Master Calendar network error. |
+マスターカレンダー通信エラー. |
+
| 29 | +Error | +129 | +Master Calendar network error. |
+マスターカレンダー通信エラー. |
+
| 30 | +Error | +130 | +Installation boot device error. |
+インストールブートデバイスエラー. |
+
| 31 | +Error | +131 | +Installation Cassette does not correspond |
+インストールカセットと本体との対応がとれて |
+
| 32 | +Error | +132 | +Cassette error (%d1) |
+カセットエラー (%d1) |
+
| 35 | +Error | +135 | +This cassette is used to convert another |
+このカセットはいちど次機種への |
+
| 36 | +Error | +136 | +Cassette error (%d1) |
+カセットエラー (%d1) |
+
| 38 | +Error | +138 | +File not found. |
+ファイルが見つかりません. |
+
| 39 | +Error | +139 | +File reading error. |
+ファイルリードエラー. |
+
| 40 | +Error | +140 | +File not found. |
+ファイルが見つかりません. |
+
| 41 | +Error | +141 | +File reading error. |
+ファイルリードエラー. |
+
| 42 | +Error | +142 | +File reading error. |
+ファイルリードエラー. |
+
| 43 | +Error | +143 | +File reading error. |
+ファイルリードエラー. |
+
| 44 | +Error | +144 | +File data error. |
+ファイルデータエラー. |
+
| 45 | +Error | +145 | +File data error. |
+ファイルデータエラー. |
+
| 46 | +Error | +146 | +Turn off the power and check if the Flash |
+電源を切り, フラッシュカードが正しくセット |
+
| 47 | +Error | +147 | +Checksum error. If you have the latest |
+チェックサムエラー. 最新のCD-ROMがあれば, |
+
| 48 | +Error | +148 | +Area specification error. |
+仕向地指定エラー. |
+
| 49 | +Error | +149 | +Cassette initialization error. |
+カセット初期化エラー. |
+
| 50 | +Error | +150 | +Cassette initialization error. |
+カセット初期化エラー. |
+
| 51 | +Error | +151 | +File not found. |
+ファイルが見つかりません. |
+
| 52 | +Error | +152 | +Turn off the power and check if the Flash |
+電源を切り, フラッシュカードが正しくセット |
+
| 53 | +Error | +153 | +Installation failed. (%d1) |
+インストールに失敗しました (%d1) |
+
| 54 | +Error | +154 | +Assertion failed. |
+アサーションフェイル. |
+
| 55 | +Error | +155 | +Argument buffer overflow. |
+引数バッファオーバーフロー. |
+
| 56 | +Error | +156 | +File not found. |
+ファイルが見つかりません. |
+
| 57 | +Error | +157 | +File data error. |
+ファイルデータエラー. |
+
| 58 | +Error | +158 | +File reading error. |
+ファイルリードエラー. |
+
| 59 | +Error | +159 | +Security Chip error. (%d1) |
+セキュリティチップエラー.(%d1) |
+
| 60 | +Error | +160 | +CD-ROM drive error |
+CD-ROMドライブエラー. |
+
| 61 | +Error | +161 | +RTC error |
+RTCエラー. |
+
| 62 | +Error | +162 | +Specification selection error |
+商品仕様指定エラー. |
+
| 64 | +Error | +164 | +Operating Cassette is not corresponding |
+運用カセットと本体との対応がとれていません. |
+
| 66 | +Error | +166 | +Incorrect cassette installed. |
+不当なカセットです. |
+
| 67 | +Error | +167 | +Security Chip initialization failed. (%d1) |
+セキュリティチップ初期化エラー. (%d1) |
+
| 69 | +Error | +169 | +Cannot use this security cassette |
+このセキュリティカセットはインストール |
+
| 70 | +Error | +170 | +Cannot use this security cassette |
+このセキュリティカセットはインストール |
+
| 71 | +Error | +171 | +This version cannot initialize a cassette. |
+このバージョンはカセットを初期化できません. |
+
| 72 | +Error | +172 | +You are using an incorrect CD-ROM. |
+CD-ROMが違います. |
+
| 73 | +Error | +173 | +Cannot use this security cassette. |
+このセキュリティカセットは使用できません. |
+
| 74 | +Error | +174 | +Cannot use this security cassette. |
+このセキュリティカセットは使用できません. |
+
| 75 | +Error | +175 | +Cassette is not corresponding with the |
+カセットと本体との対応がとれていません. |
+
| 76 | +Error | +176 | +Cassette is not corresponding with the |
+カセットと本体との対応がとれていません. |
+
| 77 | +Error | +177 | +Checksum error. |
+チェックサムエラー. |
+
| 78 | +Error | +178 | +This cassette is used to convert another |
+このカセットは次機種へのコンバージョンに |
+
| 79 | +Error | +179 | +Boot is not available from this device. |
+このデバイスからゲームのブートはできません. |
+
| 80 | +Error | +180 | +You are using an incorrect CD-ROM. |
+CD-ROMが違います. |
+
| 81 | +Error | +181 | +File system mounting failed. |
+ファイルシステムのマウントに失敗しました. |
+
| 82 | +Error | +182 | +File system mounting failed. |
+ファイルシステムのマウントに失敗しました. |
+
| 83 | +Error | +183 | +Installation boot device error. |
+インストールブートデバイスエラー. |
+
| 84 | +Error | +184 | +CD-ROM drive error |
+CD-ROMドライブエラー. |
+
| 85 | +Error | +185 | +CD-ROM drive version update failed. (%d1) |
+CD-ROMドライブのバージョンアップに失敗 |
+
| 86 | +Error | +186 | +Cassette error (%d1) |
+カセットエラー (%d1) |
+
| 87 | +Error | +187 | +You are using the cassette of another |
+異なる本体向けのカセットを使用しています. |
+
| 88 | +Error | +188 | +You are using the cassette of another |
+異なる本体向けのカセットを使用しています. |
+
| 89 | +Error | +189 | +You are using unknown cabinet. |
+不明な本体を使用しています. |
+
| 90 | +Error | +190 | +You are using unknown cabinet. |
+不明な本体を使用しています. |
+
| 91 | +Error | +191 | +Non-applicable game installed. |
+異なるゲームがインストールされています. |
+
| 92 | +Error | +192 | +This software is for the e-Amusement |
+このゲームソフトはe-Amusement(レンタル)用 |
+
| 93 | +Error | +193 | +This software is not for the e-Amusement |
+このゲームソフトはe-Amusement(レンタル)用 |
+
| 94 | +Error | +194 | +Non-applicable game installed. |
+異なるゲームがインストールされています. |
+
| 95 | +Error | +195 | +Cassette initialization error. |
+カセット初期化エラー. |
+
| 96 | +Error | +196 | +Cassette initialization error. |
+カセット初期化エラー. |
+
| 97 | +Error | +197 | +Cassette initialization error. |
+カセット初期化エラー. |
+
| 98 | +Info | +198, 500 | +Installation completed. |
+インストール完了. |
+
| 99 | +Info | +199, 501 | +Installation complete. Please write down |
+インストール完了. カセットと本体に認証番号 |
+
| 100 | +Info | +200, 502 | +Operating cassette initialized. |
+運用カセット初期化完了. |
+
| 101 | +Info | +201, 503 | +Installation cassette initialized. |
+インストールカセット初期化完了. |
+
| 102 | +Info | +202, 504 | +Initialized Operating Cassette |
+初期化済み運用カセット. |
+
| 103 | +Info | +203, 505 | +Initialized Installation Cassette |
+初期化済みインストールカセット. |
+
| 104 | +Info | +204, 506 | +Installation completed. |
+インストール完了. |
+
| 105 | +Info | +205, 507 | +Installation complete. Please write down |
+インストール完了. カセットと本体に認証番号 |
+
| 106 | +Info | +206, 508 | +Installation completed. |
+インストール完了. |
+
| 107 | +Info | +207, 509 | +Installation complete. |
+インストール完了. |
+
| 108 | +Info | +208, 510 | +Security cassette initialized. |
+セキュリティカセット初期化完了. |
+
| 109 | +Info | +209, 511 | +Initialized Security Cassette |
+初期化済みセキュリティカセット. |
+
| 110 | +Info | +210, 512 | +SERVICE button is pressed. |
+サービスボタンが押されています. |
+
| 111 | +Note | +211, 513, 602 | +CD-ROM drive version update in progress. |
+現在CD-ROMドライブのバージョンアップを |
+
| 112 | +Note | +212, 514, 603 | +CD-ROM drive version update completed. |
+CD-ROMドライブのバージョンアップが完了 |
+
| 113 | +Note | +213, 515, 604 | +Starting CD-ROM drive version update. |
+CD-ROMドライブのバージョンアップを行います. |
+
| 114 | +Note | +214, 516, 605 | +Cleared RTC-RAM. |
+RTC-RAMをクリアしました. |
+
GX700-PWB(A))GX700-PWB(F))GX894-PWB(B)A)GX700-PWB(A))ANALOG, CN3)The inputs are wired directly to the 573's built-in ADC with no protection, so +they can only accept voltages in 0-5V range. This connector is usually used for +potentiometers and similar resistive analog controls.
+| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +5V |
++ |
| 2 | +5V |
++ |
| 3 | +5V |
++ |
| 4 | +5V |
++ |
| 5 | +CH0 |
+I | +
| 6 | +GND |
++ |
| 7 | +CH1 |
+I | +
| 8 | +CH2 |
+I | +
| 9 | +CH3 |
+I | +
| 10 | +GND |
++ |
EXT-OUT, CN4)Unlike the light output ports on most I/O boards, these are unisolated 5V logic +level outputs.
+| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +5V |
++ |
| 2 | +5V |
++ |
| 3 | +OUT7 |
+O | +
| 4 | +OUT6 |
+O | +
| 5 | +OUT5 |
+O | +
| 6 | +OUT4 |
+O | +
| 7 | +OUT3 |
+O | +
| 8 | +OUT2 |
+O | +
| 9 | +OUT1 |
+O | +
| 10 | +OUT0 |
+O | +
| 11 | +GND |
++ |
| 12 | +GND |
++ |
EXT-IN, CN5)Unlike EXT-OUT, this port is not a separate input port. It piggybacks on the
+JAMMA button inputs instead, exposing the button 4 and 5 pins for both players
+as well as a sixth button input which is not available on the JAMMA connector.
+All inputs have a pullup resistor to 5V.
| Pin | +Name | +Dir | +JAMMA pin | +
|---|---|---|---|
| 1 | +5V |
++ | + |
| 2 | +5V |
++ | + |
| 3 | +P1_B4 |
+I | +25 | +
| 4 | +P1_B5 |
+I | +26 | +
| 5 | +P1_B6 |
+I | ++ |
| 6 | +GND |
++ | + |
| 7 | +P2_B4 |
+I | +c | +
| 8 | +P2_B5 |
+I | +d | +
| 9 | +P2_B6 |
+I | ++ |
| 10 | +GND |
++ | + |
SOUND-OUT, CN9)The pinout of this connector is currently unknown.
+CN10)Used by I/O boards to connect to the motherboard. Note that the address and data +bus are 3.3V, while all other signals are 5V as they go through the CPLD.
+| Pin | +Name | +Dir | +Pin | +Name | +Dir | +
|---|---|---|---|---|---|
| A1 | +5V |
++ | B1 | +5V |
++ |
| A2 | +5V |
++ | B2 | +5V |
++ |
| A3 | +5V |
++ | B3 | +5V |
++ |
| A4 | +5V |
++ | B4 | +5V |
++ |
| A5 | +5V |
++ | B5 | +5V |
++ |
| A6 | +/RD |
+O | +B6 | +/WR0 |
+O | +
| A7 | +/WR1 |
+O | +B7 | +GND |
++ |
| A8 | +GND |
++ | B8 | +SYSCLK |
+O | +
| A9 | +GND |
++ | B9 | +GND |
++ |
| A10 | +/RESET |
+O | +B10 | +/RESET |
+O | +
| A11 | +GND |
++ | B11 | +GND |
++ |
| A12 | +/CS1 |
+O | +B12 | +DMARQ5 |
+I | +
| A13 | +GND |
++ | B13 | +GND |
++ |
| A14 | +DMARQ5 |
+I | +B14 | +/CS1 |
+O | +
| A15 | +/CS2 |
+O | +B15 | +NC |
++ |
| A16 | +/IRQ10 |
+I | +B16 | +/IRQ10 |
+I | +
| A17 | +A22 |
+O | +B17 | +A23 |
+O | +
| A18 | +A20 |
+O | +B18 | +A21 |
+O | +
| A19 | +A14 |
+O | +B19 | +A15 |
+O | +
| A20 | +A12 |
+O | +B20 | +A13 |
+O | +
| A21 | +A6 |
+O | +B21 | +A7 |
+O | +
| A22 | +A4 |
+O | +B22 | +A5 |
+O | +
| A23 | +A2 |
+O | +B23 | +A3 |
+O | +
| A24 | +A0 |
+O | +B24 | +A1 |
+O | +
| A25 | +D14 |
+IO | +B25 | +D15 |
+IO | +
| A26 | +D12 |
+IO | +B26 | +D13 |
+IO | +
| A27 | +D10 |
+IO | +B27 | +D11 |
+IO | +
| A28 | +D8 |
+IO | +B28 | +D9 |
+IO | +
| A29 | +D6 |
+IO | +B29 | +D7 |
+IO | +
| A30 | +D4 |
+IO | +B30 | +D5 |
+IO | +
| A31 | +D2 |
+IO | +B31 | +D3 |
+IO | +
| A32 | +D0 |
+IO | +B32 | +D1 |
+IO | +
| A33 | +GND |
++ | B33 | +GND |
++ |
| A34 | +GND |
++ | B34 | +GND |
++ |
| A35 | +GND |
++ | B35 | +GND |
++ |
| A36 | +3.3V |
++ | B36 | +3.3V |
++ |
| A37 | +3.3V |
++ | B37 | +3.3V |
++ |
| A38 | +3.3V |
++ | B38 | +3.3V |
++ |
| A39 | +3.3V |
++ | B39 | +3.3V |
++ |
| A40 | +3.3V |
++ | B40 | +3.3V |
++ |
CD-DA IN, CN12)Connected to either the CD-ROM drive's audio output or to CN16 on the digital
+I/O board on systems equipped with a drive.
| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +LIN |
+I | +
| 2 | +AGND |
++ |
| 3 | +AGND |
++ |
| 4 | +RIN |
+I | +
CN14)All signals are 5V as they go through level shifters.
+| Pin | +Name | +Dir | +Notes | +Pin | +Name | +Dir | +Notes | +
|---|---|---|---|---|---|---|---|
| 1 | +GND |
++ | + | 23 | +GND |
++ | + |
| 2 | +GND |
++ | + | 24 | +GND |
++ | + |
| 3 | +/DSR |
+I | +Usually shorted to ground | +25 | +MCUCLK |
+O | +7.3728 MHz JVS MCU clock | +
| 4 | +NC |
++ | May actually be /DTR? |
+26 | +GND |
++ | + |
| 5 | +TX |
+O | ++ | 27 | +DRDY |
+O | +Goes high when 573 updates D0-D7 |
+
| 6 | +RX |
+I | ++ | 28 | +SDA |
+IO | ++ |
| 7 | +/RESET |
+IO | +System reset (from watchdog) | +29 | +/IREQ |
+I | +Sets IRDY when pulsed low |
+
| 8 | +GND |
++ | + | 30 | +/DACK |
+I | +Clears DRDY when pulsed low |
+
| 9 | +GND |
++ | + | 31 | +IRDY |
+O | +Goes low when 573 reads I0-I7 |
+
| 10 | ++ | + | Key (missing pin) | +32 | ++ | + | Key (missing pin) | +
| 11 | +? |
++ | Not connected? | +33 | +I7 |
+I | ++ |
| 12 | +? |
++ | Not connected? | +34 | +I6 |
+I | ++ |
| 13 | +D7 |
+O | ++ | 35 | +I5 |
+I | ++ |
| 14 | +D6 |
+O | ++ | 36 | +I4 |
+I | ++ |
| 15 | +D5 |
+O | ++ | 37 | +I3 |
+I | ++ |
| 16 | +D4 |
+O | ++ | 38 | +I2 |
+I | ++ |
| 17 | +D3 |
+O | ++ | 39 | +I1 |
+I | ++ |
| 18 | +D2 |
+O | ++ | 40 | +I0 |
+I | ++ |
| 19 | +D1 |
+O | ++ | 41 | +5V |
++ | + |
| 20 | +D0 |
+O | ++ | 42 | +5V |
++ | + |
| 21 | +5V |
++ | + | 43 | +/RTS |
+O | +Usually shorted to /CTS |
+
| 22 | +5V |
++ | + | 44 | +/CTS |
+I | +Usually shorted to /RTS |
+
CN17)Commonly used to distribute the 12V rail to security cartridges with built-in +light drivers or external modules, but it can also used instead of the JAMMA +connector to supply power to the 573. The pinout is silkscreened on the board.
+| Pin | +Name | +
|---|---|
| 1 | +12V |
+
| 2 | +12V |
+
| 3 | +GND |
+
| 4 | +GND |
+
| 5 | +5V |
+
| 6 | +5V |
+
DIGITAL-AUDIO, CN19)Always unpopulated. Pin 4 outputs a 16.9344 MHz master clock (system clock +divided by 2, or 44100 Hz sampling rate multiplied by 384). This port does not +output audio from the CD-DA/MP3 input, which is not routed through the SPU.
+| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +BCLK |
+O | +
| 2 | +SDOUT |
+O | +
| 3 | +GND |
++ |
| 4 | +MCLK |
+O | +
| 5 | +LRCK |
+O | +
CN21)The address lines not wired to CN10, as well as the otherwise unused SIO0
+controller and memory card bus, are broken out to this connector. No currently
+known I/O board uses it. All signals are 3.3V.
| Pin | +Name | +Dir | +Pin | +Name | +Dir | +
|---|---|---|---|---|---|
| A1 | +A8 |
+O | +B1 | +A9 |
+O | +
| A2 | +A10 |
+O | +B2 | +A11 |
+O | +
| A3 | +A16 |
+O | +B3 | +A17 |
+O | +
| A4 | +A18 |
+O | +B4 | +A19 |
+O | +
| A5 | +GND |
++ | B5 | +? |
++ |
| A6 | +GND |
++ | B6 | +? |
++ |
| A7 | +GND |
++ | B7 | +GND |
++ |
| A8 | +GND |
++ | B8 | +DOTCLK |
+O | +
| A9 | +GND |
++ | B9 | +GND |
++ |
| A10 | +GND |
++ | B10 | +/DSR |
+I | +
| A11 | +GND |
++ | B11 | +/DTR2 |
+O | +
| A12 | +GND |
++ | B12 | +/DTR1 |
+O | +
| A13 | +GND |
++ | B13 | +RX |
+I | +
| A14 | +GND |
++ | B14 | +TX |
+O | +
| A15 | +GND |
++ | B15 | +SCK |
+O | +
WD-CHECK, CN22)Always unpopulated. Exposes the watchdog's clear input (pulsed whenever the CPU
+writes to the watchdog clear register) as well as the reset output. Injecting
+pulses to forcefully clear the watchdog should work, although it's much easier
+to simply disable it by placing a jumper on S86.
| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +WDCLR |
+IO | +
| 2 | +/RESET |
+O | +
| 3 | +5V |
++ |
| 4 | +GND |
++ |
CN23)Only present on later revisions of the main board and only populated on DDR +Karaoke Mix, which uses the semitransparency plane of the currently displayed +framebuffer as an alpha mask in order to composite the 573's output on top of +the incoming karaoke video feed.
+| Pin | +Name | +Dir | +GPU pin | +
|---|---|---|---|
| 1 | +FSC |
+O | +153 | +
| 2 | +DMASK |
+O | +202 | +
| 3 | +GND |
++ | + |
CN24)Only present on later revisions of the main board and always unpopulated. +Exposes the same 5V SIO1 signals as the security cartridge slot.
+| Pin | +Name | +Dir | +Cart pin | +
|---|---|---|---|
| 1 | +TX |
+O | +5 | +
| 2 | +RX |
+I | +6 | +
| 3 | +GND |
++ | + |
| 4 | +GND |
++ | + |
| 5 | +/RTS |
+O | +43 | +
| 6 | +/CTS |
+I | +44 | +
CN25)Only present on later revisions of the main board and only populated on GunMania +and DDR Karaoke Mix, whose I/O boards feature RGB to S-video and composite +converters respectively. Exposes the same RGB signals as the JAMMA and DB15 +connectors.
+| Pin | +Name | +Dir | +JAMMA pin | +
|---|---|---|---|
| 1 | +GND |
+O | ++ |
| 2 | +CSYNC |
+O | +P | +
| 3 | +BOUT |
+O | +13 | +
| 4 | +GOUT |
+O | +N | +
| 5 | +ROUT |
+O | +12 | +
S86)Always unpopulated. Shorting pin 1 and 2 will disable the watchdog while keeping +power-on reset functional. Pin 3 is an active-high reset output, unused by the +573.
+| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +WDEN |
+I | +
| 2 | +GND |
++ |
| 3 | +RESET |
+O | +
| Pin | +H8 GPIO | +Dir | +Connected to | +Usage | +
|---|---|---|---|---|
| 11 | +P9_0 |
+I | ++ | Unused | +
| 12 | +P9_1-2 |
+O | +Konami ASIC | +Status code (readable from 0x1f400004) |
+
| 12 | +P9_3-4 |
+O | +Konami ASIC | +Error code (readable from 0x1f400004) |
+
| 16 | +IRQ0 |
+I | ++ | Unused | +
| 17-24 | +P6_0-7 |
+O | +Konami ASIC | +Low byte of value readable from 0x1f40000a |
+
| 25-32 | +P5_0-7 |
+O | +Konami ASIC | +High byte of value readable from 0x1f40000a |
+
| 34 | +P7_3 |
+I | +Handshaking logic | +Current JVSDRDY status |
+
| 35 | +P7_4 |
+I | +Handshaking logic | +Current JVSIRDY status |
+
| 36 | +P7_5 |
+I | ++ | Unused | +
| 37 | +P7_6 |
+I | ++ | Unused | +
| 38 | +P7_7 |
+I | ++ | Unused | +
| 39-46 | +P8_0-7 |
+I | +Bus (via latch) | +High byte of value written to 0x1f680000 |
+
| 47 | +P2_0 |
+O | +RS-485 transceiver | +JVS driver output enable | +
| 48 | +P2_1 |
+I | +RS-485 transceiver | +JVS serial port RX | +
| 49 | +P2_2 |
+O | +RS-485 transceiver | +JVS serial port TX | +
| 50 | +P3_2 |
+I | ++ | Unused | +
| 51 | +P3_1 |
+I | ++ | Unused | +
| 52 | +P3_0 |
+I | ++ | Unused | +
| 53 | +P1_0 |
+O | +Handshaking logic | +/JVSDACK (clears JVSDRDY when pulsed low) |
+
| 54 | +P1_4 |
+O | +Handshaking logic | +JVSIREQ (sets JVSIRDY when pulsed high) |
+
| 55 | +P1_5 |
+I | ++ | Unused | +
| 56 | +P1_6 |
+I | ++ | Unused | +
| 57 | +P1_7 |
+I | ++ | Unused | +
| 59-2 | +PB_7-0 |
+I | +Bus (via latch) | +Low byte of value written to 0x1f680000 |
+
GX700-PWB(F))CN33, CN34 respectively)All outputs are open-drain. Pins 1 and 10 are tied together and connected to the +optocouplers' emitters.
+| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +ACOM/BCOM |
++ |
| 2 | +A0/B0 |
+O | +
| 3 | +A1/B1 |
+O | +
| 4 | +A2/B2 |
+O | +
| 5 | +A3/B3 |
+O | +
| 6 | +A4/B4 |
+O | +
| 7 | +A5/B5 |
+O | +
| 8 | +A6/B6 |
+O | +
| 9 | +A7/B7 |
+O | +
| 10 | +ACOM/BCOM |
++ |
CN35)All outputs are open-drain. Unlike banks A and B, pin 10 is not tied to pin 1
+but is instead connected to the EMI filters' ground (FGND), isolated from the
+system ground but shared across all output banks.
| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +CCOM |
++ |
| 2 | +C0 |
+O | +
| 3 | +C1 |
+O | +
| 4 | +C2 |
+O | +
| 5 | +C3 |
+O | +
| 6 | +C4 |
+O | +
| 7 | +C5 |
+O | +
| 8 | +C6 |
+O | +
| 9 | +C7 |
+O | +
| 10 | +FGND |
++ |
CN36)All outputs are open-drain.
+| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +DCOM |
++ |
| 2 | +D0 |
+O | +
| 3 | +D1 |
+O | +
| 4 | +D2 |
+O | +
| 5 | +D3 |
+O | +
| 6 | +FGND |
++ |
GX894-PWB(B)A)CN10)All outputs are open-drain. The optocouplers driving C0-C3 have their emitters
+wired to CCOM0, while those driving C4-C7 have their emitters wired to
+CCOM1.
| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +CCOM0 |
++ |
| 2 | +C0 |
+O | +
| 3 | +C1 |
+O | +
| 4 | +C2 |
+O | +
| 5 | +C3 |
+O | +
| 6 | +CCOM1 |
++ |
| 7 | +C4 |
+O | +
| 8 | +C5 |
+O | +
| 9 | +C6 |
+O | +
| 10 | +C7 |
+O | +
CN11)All outputs are open-drain. The optocouplers driving B0-B3 have their emitters
+wired to BCOM0, while those driving B4-B7 have their emitters wired to
+BCOM1.
| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +BCOM0 |
++ |
| 2 | +B0 |
+O | +
| 3 | +B1 |
+O | +
| 4 | +B2 |
+O | +
| 5 | +B3 |
+O | +
| 6 | +BCOM1 |
++ |
| 7 | +B4 |
+O | +
| 8 | +B5 |
+O | +
| 9 | +B6 |
+O | +
| 10 | +B7 |
+O | +
| 11 | +NC |
++ |
| 12 | +NC |
++ |
CN12)All outputs are open-drain. The optocouplers driving A0-A3 have their emitters
+wired to ACOM0, while those driving A4-A7 have their emitters wired to
+ACOM1.
| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +ACOM0 |
++ |
| 2 | +A0 |
+O | +
| 3 | +A1 |
+O | +
| 4 | +A2 |
+O | +
| 5 | +A3 |
+O | +
| 6 | +ACOM1 |
++ |
| 7 | +A4 |
+O | +
| 8 | +A5 |
+O | +
| 9 | +A6 |
+O | +
| 10 | +A7 |
+O | +
| 11 | +NC |
++ |
| 12 | +NC |
++ |
| 13 | +NC |
++ |
CN13)All outputs are open-drain.
+| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +DCOM |
++ |
| 2 | +D0 |
+O | +
| 3 | +D1 |
+O | +
| 4 | +D2 |
+O | +
| 5 | +D3 |
+O | +
CN14)The pinout of this connector is currently unknown.
+CN15)| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +TX |
+O | +
| 2 | +RX |
+O | +
| 3 | +GND |
++ |
| 4 | +GND |
++ |
| 5 | +RTS |
+O | +
| 6 | +CTS |
+O | +
| 7 | +DTR |
+O | +
| 8 | +DSR |
+O | +
CN16)Usually connected to CN12 on the main board. GuitarFreaks routes this output
+to a separate set of RCA jacks on the front I/O panel instead.
| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +LOUT |
+O | +
| 2 | +AGND |
++ |
| 3 | +AGND |
++ |
| 4 | +ROUT |
+O | +
CN17)The pinout of this connector is currently unknown.
+CN18)| Pin | +Name | +Dir | +FPGA pin | +
|---|---|---|---|
| 1 | +MCLK |
+O | +97 | +
| 2 | +BCLK |
+O | +94 | +
| 3 | +SDOUT |
+O | +96 | +
| 4 | +LRCK |
+O | +95 | +
| 5 | +? |
++ | + |
| 6 | +? |
++ | + |
| Pin | +JTAG | +FPGA alt. | +Dir | +Connected to | +Usage | +
|---|---|---|---|---|---|
| 2 | +170 | +GCK1 |
+IO | +DRAM | +Data bus bit 4 | +
| 3 | +173 | ++ | IO | +DRAM | +Data bus bit 8 | +
| 4 | +176 | ++ | IO | +DRAM | +Data bus bit 9 | +
| 5 | +179 | ++ | IO | +DRAM | +Data bus bit 10 | +
| 6 | +182 | +TDI |
++ | + | Unused | +
| 7 | +185 | +TCK |
++ | + | Unused | +
| 8 | +194 | ++ | IO | +DRAM | +Data bus bit 3 | +
| 9 | +197 | ++ | IO | +DRAM | +Data bus bit 11 | +
| 10 | +200 | ++ | IO | +DRAM | +Data bus bit 2 | +
| 11 | +203 | ++ | IO | +DRAM | +Data bus bit 12 | +
| 12 | +206 | ++ | + | + | Unused | +
| 14 | +212 | ++ | IO | +DRAM | +Data bus bit 1 | +
| 15 | +215 | ++ | IO | +DRAM | +Data bus bit 0 | +
| 16 | +218 | +TMS |
++ | + | Unused | +
| 17 | +221 | ++ | IO | +DRAM | +Data bus bit 13 | +
| 19 | +236 | ++ | IO | +DRAM | +Data bus bit 14 | +
| 20 | +239 | ++ | IO | +DRAM | +Data bus bit 15 | +
| 21 | +242 | ++ | IO | +SRAM | +Data bus bit 3 | +
| 22 | +245 | ++ | IO | +SRAM | +Data bus bit 2 | +
| 23 | +248 | ++ | IO | +SRAM | +Data bus bit 4 | +
| 24 | +251 | ++ | IO | +SRAM | +Data bus bit 1 | +
| 27 | +254 | ++ | IO | +SRAM | +Data bus bit 5 | +
| 28 | +257 | ++ | IO | +SRAM | +Data bus bit 0 | +
| 29 | +260 | ++ | IO | +SRAM | +Data bus bit 6 | +
| 30 | +263 | ++ | O | +SRAM | +Address bus bit 0 | +
| 31 | +266 | ++ | IO | +SRAM | +Data bus bit 7 | +
| 32 | +269 | ++ | O | +SRAM | +Address bus bit 1 | +
| 34 | +284 | ++ | O | +SRAM | +Chip select | +
| 35 | +287 | ++ | O | +SRAM | +Address bus bit 2 | +
| 36 | +290 | ++ | O | +SRAM | +Address bus bit 10 | +
| 37 | +293 | ++ | O | +SRAM | +Address bus bit 3 | +
| 39 | +299 | ++ | + | + | Unused | +
| 40 | +302 | ++ | O | +SRAM | +Output enable | +
| 41 | +305 | ++ | O | +SRAM | +Address bus bit 4 | +
| 42 | +308 | ++ | O | +SRAM | +Address bus bit 11 | +
| 43 | +311 | ++ | O | +SRAM | +Address bus bit 5 | +
| 44 | +320 | ++ | O | +SRAM | +Address bus bit 9 | +
| 45 | +323 | ++ | O | +SRAM | +Address bus bit 6 | +
| 46 | +326 | ++ | O | +SRAM | +Address bus bit 8 | +
| 47 | +329 | ++ | O | +SRAM | +Address bus bit 7 | +
| 48 | +332 | ++ | O | +SRAM | +Address bus bit 13 | +
| 49 | +335 | +GCK2 |
+O | +SRAM | +Address bus bit 12 | +
| 55 | +342 | +GCK3 |
+O | +SRAM | +Write enable | +
| 56 | +345 | +/HDC |
+O | +SRAM | +Address bus bit 14 | +
| 57 | +348 | ++ | O | +SRAM | +Address bus bit 16 | +
| 58 | +351 | ++ | O | +SRAM | +Address bus bit 15 | +
| 59 | +354 | ++ | O | +Light bank D | +Output D3 | +
| 60 | +357 | +LDC |
+O | +Light bank D | +Output D2 | +
| 61 | +366 | ++ | I | +Input bank | +Unknown input | +
| 62 | +369 | ++ | I | +Input bank | +Unknown input | +
| 63 | +372 | ++ | I | +Input bank | +Unknown input | +
| 64 | +375 | ++ | I | +Input bank | +Unknown input | +
| 65 | +378 | ++ | + | + | + |
| 67 | +384 | ++ | O | +Light bank D | +Output D1 | +
| 68 | +387 | ++ | O | +Light bank D | +Output D0 | +
| 69 | +390 | ++ | O | +Light bank ? | +Unknown output | +
| 70 | +393 | ++ | O | +Light bank ? | +Unknown output | +
| 72 | +396 | ++ | O | +Light bank ? | +Unknown output | +
| 73 | +399 | ++ | O | +Light bank ? | +Unknown output | +
| 74 | +414 | ++ | O | +Light bank ? | +Unknown output | +
| 75 | +417 | ++ | O | +Light bank ? | +Unknown output | +
| 76 | +420 | ++ | O | +Light bank ? | +Unknown output | +
| 77 | +423 | +/INIT |
+IO | +CPLD | +FPGA reset/status | +
| 80 | +426 | ++ | O | +Light bank ? | +Unknown output | +
| 81 | +429 | ++ | O | +Light bank ? | +Unknown output | +
| 82 | +432 | ++ | O | +Light bank ? | +Unknown output | +
| 83 | +435 | ++ | O | +Light bank ? | +Unknown output | +
| 84 | +438 | ++ | O | +Light bank ? | +Unknown output | +
| 85 | +441 | ++ | I | +RS-232 transceiver | +Unknown pin | +
| 87 | +456 | ++ | O | +RS-232 transceiver | +Unknown pin | +
| 88 | +459 | ++ | I | +RS-232 transceiver | +Unknown pin | +
| 89 | +462 | ++ | O | +RS-232 transceiver | +Unknown pin | +
| 90 | +465 | ++ | I | +RS-232 transceiver | +Unknown pin | +
| 92 | +471 | ++ | + | + | + |
| 93 | +474 | ++ | O | +RS-232 transceiver | +Unknown pin | +
| 94 | +477 | ++ | O | +Audio DAC | +I2S bit clock (BCLK) |
+
| 95 | +480 | ++ | O | +Audio DAC | +I2S frame clock (LRCK) |
+
| 96 | +483 | ++ | O | +Audio DAC | +I2S data input (SDIN) |
+
| 97 | +492 | ++ | O | +Audio DAC | +I2S master clock (MCLK) |
+
| 98 | +495 | ++ | O | +ARCnet transceiver | +Network TX enable? | +
| 99 | +498 | ++ | O | +ARCnet transceiver | +Network TX? | +
| 100 | +501 | ++ | I | +ARCnet transceiver | +Network RX | +
| 101 | +504 | ++ | + | + | + |
| 102 | +507 | +GCK4 |
++ | + | + |
| 104 | ++ | DONE |
+IO | +CPLD | +FPGA configuration status | +
| 106 | ++ | /PROGRAM |
+I | +CPLD | +FPGA configuration reset | +
| 107 | +510 | +D7 |
+IO | +DS2433 (unpopulated) | +Unused 1-wire bus (open drain) | +
| 108 | +513 | +GCK5 |
++ | + | Unused | +
| 109 | +516 | ++ | IO | +DS2401 | +1-wire bus (open drain) | +
| 110 | +519 | ++ | I | +573 bus | +Address bus bit 7 | +
| 111 | +525 | ++ | + | + | Unused | +
| 112 | +534 | +D6 |
+I | +573 bus | +Address bus bit 6 | +
| 113 | +537 | ++ | I | +573 bus | +Address bus bit 5 | +
| 114 | +540 | ++ | I | +573 bus | +Address bus bit 4 | +
| 115 | +543 | ++ | I | +573 bus | +Address bus bit 3 | +
| 116 | +546 | ++ | I | +573 bus | +Address bus bit 2 | +
| 117 | +549 | ++ | I | +573 bus | +Address bus bit 1 | +
| 119 | +558 | ++ | O | ++ | Unused? | +
| 120 | +561 | ++ | IO | +573 bus | +Data bus bit 15 | +
| 122 | +564 | +D5 |
+IO | +573 bus | +Data bus bit 14 | +
| 123 | +567 | ++ | IO | +573 bus | +Data bus bit 13 | +
| 124 | +576 | ++ | IO | +573 bus | +Data bus bit 12 | +
| 125 | +579 | ++ | IO | +573 bus | +Data bus bit 11 | +
| 126 | +582 | ++ | IO | +573 bus | +Data bus bit 10 | +
| 127 | +585 | ++ | IO | +573 bus | +Data bus bit 9 | +
| 128 | +588 | +D4 |
+IO | +573 bus | +Data bus bit 8 | +
| 129 | +591 | ++ | IO | +573 bus | +Data bus bit 7 | +
| 132 | +594 | +D3 |
+IO | +573 bus | +Data bus bit 6 | +
| 133 | +597 | ++ | IO | +573 bus | +Data bus bit 5 | +
| 134 | +600 | ++ | IO | +573 bus | +Data bus bit 4 | +
| 135 | +603 | ++ | IO | +573 bus | +Data bus bit 3 | +
| 136 | +606 | ++ | IO | +573 bus | +Data bus bit 2 | +
| 137 | +609 | ++ | IO | +573 bus | +Data bus bit 1 | +
| 138 | +618 | +D2 |
+IO | +573 bus | +Data bus bit 0 | +
| 139 | +621 | ++ | + | + | + |
| 141 | +624 | ++ | + | + | + |
| 142 | +627 | ++ | I | +573 bus | +I/O board chip select | +
| 144 | +639 | ++ | + | + | + |
| 145 | +642 | ++ | I | +573 bus | +Write strobe (/WR0) |
+
| 146 | +645 | ++ | I | +573 bus | +Read strobe (/RD) |
+
| 147 | +648 | ++ | + | + | + |
| 148 | +651 | ++ | I | +MAS3507D | +MP3 data request flag (PI19) |
+
| 149 | +654 | +D1 |
+O | +MAS3507D | +PIO chip select (/PCS) |
+
| 150 | +657 | ++ | IO | +MAS3507D | +I2C SDA | +
| 151 | +666 | ++ | IO | +MAS3507D | +I2C SCL | +
| 152 | +669 | ++ | O | +MAS3507D | +Chip reset (/POR) |
+
| 153 | +672 | +D0/DIN |
+I | +CPLD | +FPGA configuration data | +
| 154 | +675 | +GCK6/DOUT |
++ | + | Unused | +
| 155 | ++ | CCLK |
+I | +CPLD | +FPGA configuration clock | +
| 157 | +0 | +TDO |
++ | + | Unused | +
| 159 | +2 | ++ | I | +MAS3507D | +Master clock ready flag (WRDY) |
+
| 160 | +5 | +GCK7 |
+I | +Crystal oscillator | +29.45 MHz clock | +
| 161 | +8 | ++ | I | +MAS3507D | +MP3 frame sync flag (PI4) |
+
| 162 | +11 | ++ | I | +MAS3507D | +I2S master clock (CLKO/MCLK) |
+
| 163 | +14 | +CS1 |
+O | +MAS3507D | +Main clock input (CLKI) |
+
| 164 | +17 | ++ | O | +MAS3507D | +MP3 stream bit clock (SIC) |
+
| 165 | +26 | ++ | + | + | + |
| 166 | +32 | ++ | O | +MAS3507D | +MP3 stream frame clock (SII) |
+
| 167 | +35 | ++ | O | +MAS3507D | +MP3 stream data input (SID) |
+
| 168 | +38 | ++ | I | +MAS3507D | +MP3 error flag (PI8) |
+
| 169 | +41 | ++ | I | +MAS3507D | +I2S bit clock (SOC/BCLK) |
+
| 171 | +44 | ++ | I | +MAS3507D | +I2S frame clock (SOI/LRCK) |
+
| 172 | +47 | ++ | I | +MAS3507D | +I2S data output (SOD/SDOUT) |
+
| 174 | +62 | ++ | O | +DRAM | +Address bus bit 5 | +
| 175 | +65 | ++ | O | +DRAM | +Address bus bit 6 | +
| 176 | +68 | ++ | O | +DRAM | +Address bus bit 4 | +
| 177 | +71 | ++ | O | +DRAM | +Address bus bit 7 | +
| 178 | +74 | ++ | O | +DRAM | +Address bus bit 3 | +
| 179 | +77 | ++ | O | +DRAM | +Address bus bit 8 | +
| 180 | +80 | ++ | O | +DRAM | +Address bus bit 2 | +
| 181 | +83 | ++ | O | +DRAM | +Address bus bit 9 | +
| 184 | +86 | ++ | O | +DRAM | +Address bus bit 1 | +
| 185 | +89 | ++ | O | +DRAM | +Address bus bit 10 | +
| 186 | +92 | ++ | O | +DRAM | +Address bus bit 0 | +
| 187 | +95 | ++ | O | +DRAM | +Address bus bit 11 | +
| 188 | +98 | ++ | O | +DRAM | +Unknown (22J?) pin | +
| 189 | +101 | ++ | O | +DRAM | +Unknown (22J?) pin | +
| 190 | +104 | ++ | O | +DRAM | +Unknown (22H?) pin | +
| 191 | +107 | ++ | O | +DRAM | +Unknown (22H?) pin | +
| 193 | +122 | ++ | O | +DRAM | +Unknown (22G?) pin | +
| 194 | +125 | ++ | O | +DRAM | +22G CAS | +
| 196 | +128 | ++ | O | +DRAM | +Write strobe | +
| 197 | +131 | ++ | O | +DRAM | +22G output enable | +
| 198 | +134 | ++ | O | +DRAM | +22H CAS | +
| 199 | +137 | ++ | O | +DRAM | +22H output enable | +
| 200 | +140 | ++ | O | +DRAM | +22J CAS | +
| 201 | +143 | ++ | O | +DRAM | +22J output enable | +
| 202 | +152 | ++ | + | + | Unused | +
| 203 | +155 | ++ | + | + | Unused | +
| 204 | +158 | ++ | IO | +DRAM | +Data bus bit 7 | +
| 205 | +161 | ++ | IO | +DRAM | +Data bus bit 6 | +
| 206 | +164 | ++ | IO | +DRAM | +Data bus bit 5 | +
| 207 | +167 | +GCK8 |
+I | +Crystal oscillator | +19.6608 MHz clock | +
The 1-wire pins have external pullup resistors, so enabling the FPGA's built-in
+pullups is not necessary. The FPGA's M0, M1 and /PWRDWN pins are hardwired
+to 3.3V.
Present on GX700-PWB(E), GX896-PWB(A)A, GX883-PWB(D) and GE949-PWB(D)A
+cartridges. All signals use RS-232 voltage levels. Note that DTR and DSR are
+not wired to the respective SIO1 pins but to the security cartridge I/O pins.
On the GX700-PWB(E) cartridge the signals are referenced to the 573's ground
+and not isolated. On all other cartridge types, the RS-232 transceiver is
+powered through an isolated DC-DC module and fully eletrically isolated from the
+573; the GND pin is the transceiver's isolated ground.
| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +TX |
+O | +
| 2 | +RX |
+I | +
| 3 | +DTR |
+O | +
| 4 | +DSR |
+I | +
| 5 | +GND |
++ |
Present on GX896-PWB(A)A, GX883-PWB(D) and GE949-PWB(D)A cartridges.
+Unlike the RS-232 connector these are unisolated 5V logic level signals driven
+through open-drain buffers, with pullup resistors to 5V.
| Pin | +Name | +Dir | +
|---|---|---|
| 1 | +GND |
++ |
| 2 | +CTRL0 |
+O | +
| 3 | +GND |
++ |
| 4 | +CTRL1 |
+O | +
| 5 | +CTRL2 |
+O | +
| 6 | +5V |
++ |
This document is the result of a joint effort consisting of years' worth of +research, brought to you by:
+Traced schematics, images, datasheets and additional resources are available in +Naoki's 573 repo. Shiz also maintains +a general documentation repo for +several arcade systems including the 573.
+Some information has been aggregated from the following sources:
+Huge thanks to the Rhythm Game Cabs Discord server and everyone who provided +valuable information about the 573!
+ + + + + + +The MDEC is a JPEG-style Macroblock Decoder, that can decompress pictures (or a
+series of pictures, for being displayed as a movie).
MDEC I/O Ports
+MDEC Commands
+MDEC Decompression
+MDEC Data Format
31-0 Command or Parameters
+ 31-0 Macroblock Data (or Garbage if there's no data available)
+ 31 Data-Out Fifo Empty (0=No, 1=Empty)
+ 30 Data-In Fifo Full (0=No, 1=Full, or Last word received)
+ 29 Command Busy (0=Ready, 1=Busy receiving or processing parameters)
+ 28 Data-In Request (set when DMA0 enabled and ready to receive data)
+ 27 Data-Out Request (set when DMA1 enabled and ready to send data)
+ 26-25 Data Output Depth (0=4bit, 1=8bit, 2=24bit, 3=15bit) ;CMD.28-27
+ 24 Data Output Signed (0=Unsigned, 1=Signed) ;CMD.26
+ 23 Data Output Bit15 (0=Clear, 1=Set) (for 15bit depth only) ;CMD.25
+ 22-19 Not used (seems to be always zero)
+ 18-16 Current Block (0..3=Y1..Y4, 4=Cr, 5=Cb) (or for mono: always 4=Y)
+ 15-0 Number of Parameter Words remaining minus 1 (FFFFh=None) ;CMD.Bit0-15
+ 31 Reset MDEC (0=No change, 1=Abort any command, and set status=80040000h)
+ 30 Enable Data-In Request (0=Disable, 1=Enable DMA0 and Status.bit28)
+ 29 Enable Data-Out Request (0=Disable, 1=Enable DMA1 and Status.bit27)
+ 28-0 Unknown/Not used - usually zero
+MDEC decompression uses a lot of DMA channels,
+
1) DMA3 (CDROM) to send compressed data from CDROM to RAM
+ 2) DMA0 (MDEC.In) to send compressed data from RAM to MDEC
+ 3) DMA1 (MDEC.Out) to send uncompressed macroblocks from MDEC to RAM
+ 4) DMA2 (GPU) to send uncompressed macroblocks from RAM to GPU
+ 31-29 Command (1=decode_macroblock)
+ 28-27 Data Output Depth (0=4bit, 1=8bit, 2=24bit, 3=15bit) ;STAT.26-25
+ 26 Data Output Signed (0=Unsigned, 1=Signed) ;STAT.24
+ 25 Data Output Bit15 (0=Clear, 1=Set) (for 15bit depth only) ;STAT.23
+ 24-16 Not used (should be zero)
+ 15-0 Number of Parameter Words (size of compressed data)
+ 31-29 Command (2=set_iqtab)
+ 28-1 Not used (should be zero) ;Bit25-28 are copied to STAT.23-26 though
+ 0 Color (0=Luminance only, 1=Luminance and Color)
+ 31-29 Command (3=set_scale)
+ 28-0 Not used (should be zero) ;Bit25-28 are copied to STAT.23-26 though
+This command has no function. Command bits 25-28 are reflected to Status bits
+23-26 as usually. Command bits 0-15 are reflected to Status bits 0-15 (similar
+as the "number of parameter words" for MDEC(1), but without the "minus 1"
+effect, and without actually expecting any parameters).
These commands act identical as MDEC(0).
rl_decode_block(Crblk,src,iq_uv) ;Cr (low resolution)
+ rl_decode_block(Cbblk,src,iq_uv) ;Cb (low resolution)
+ rl_decode_block(Yblk,src,iq_y), yuv_to_rgb(0,0) ;Y1 (and upper-left Cr,Cb)
+ rl_decode_block(Yblk,src,iq_y), yuv_to_rgb(0,8) ;Y2 (and upper-right Cr,Cb)
+ rl_decode_block(Yblk,src,iq_y), yuv_to_rgb(8,0) ;Y3 (and lower-left Cr,Cb)
+ rl_decode_block(Yblk,src,iq_y), yuv_to_rgb(8,8) ;Y4 (and lower-right Cr,Cb)
+ rl_decode_block(Yblk,src,iq_y), y_to_mono ;Y
+ for i=0 to 63, blk[i]=0, next i ;initially zerofill all entries (for skip)
+ @@skip:
+ n=[src], src=src+2, k=0 ;get first entry, init dest addr k=0
+ if n=FE00h then @@skip ;ignore padding (FE00h as first halfword)
+ q_scale=(n SHR 10) AND 3Fh ;contains scale value (not "skip" value)
+ val=signed10bit(n AND 3FFh)*qt[k] ;calc first value (without q_scale/8) (?)
+ @@lop:
+ if q_scale=0 then val=signed10bit(n AND 3FFh)*2 ;special mode without qt[k]
+ val=minmax(val,-400h,+3FFh) ;saturate to signed 11bit range
+ val=val*scalezag[i] ;<-- for "fast_idct_core" only
+ if q_scale>0 then blk[zagzig[k]]=val ;store entry (normal case)
+ if q_scale=0 then blk[k]=val ;store entry (special, no zigzag)
+ n=[src], src=src+2 ;get next entry (or FE00h end code)
+ k=k+((n SHR 10) AND 3Fh)+1 ;skip zerofilled entries
+ val=(signed10bit(n AND 3FFh)*qt[k]*q_scale+4)/8 ;calc value for next entry
+ if k<=63 then jump @@lop ;should end with n=FE00h (that sets k>63)
+ idct_core(blk)
+ return (with "src" address advanced)
+Fast code with only 80 multiplications, works only if the scaletable from
+MDEC(3) command contains standard values (which is the case for all known PSX
+games).
+
src=blk, dst=temp_buffer
+ for pass=0 to 1
+ for i=0 to 7
+ if src[(1..7)*8+i]=0 then ;when src[(1..7)*8+i] are all zero:
+ dst[i*8+(0..7)]=src[0*8+i] ;quick fill by src[0*8+i]
+ else
+ z10=src[0*8+i]+src[4*8+i], z11=src[0*8+i]-src[4*8+i]
+ z13=src[2*8+i]+src[6*8+i], z12=src[2*8+i]-src[6*8+i]
+ z12=(1.414213562*z12)-z13 ;=sqrt(2)
+ tmp0=z10+z13, tmp3=z10-z13, tmp1=z11+z12, tmp2=z11-z12
+ z13=src[3*8+i]+src[5*8+i], z10=src[3*8+i]-src[5*8+i]
+ z11=src[1*8+i]+src[7*8+i], z12=src[1*8+i]-src[7*8+i]
+ z5 =(1.847759065*(z12-z10)) ;=sqrt(2)*scalefactor[2]
+ tmp7=z11+z13
+ tmp6=(2.613125930*(z10))+z5-tmp7 ;=scalefactor[2]*2
+ tmp5=(1.414213562*(z11-z13))-tmp6 ;=sqrt(2)
+ tmp4=(1.082392200*(z12))-z5+tmp5 ;=sqrt(2)/scalefactor[2]
+ dst[i*8+0]=tmp0+tmp7, dst[i*8+7]=tmp0-tmp7
+ dst[i*8+1]=tmp1+tmp6, dst[i*8+6]=tmp1-tmp6
+ dst[i*8+2]=tmp2+tmp5, dst[i*8+5]=tmp2-tmp5
+ dst[i*8+4]=tmp3+tmp4, dst[i*8+3]=tmp3-tmp4
+ endif
+ next i
+ swap(src,dst)
+ next pass
+Low level code with 1024 multiplications, using the scaletable from the MDEC(3)
+command. Computes dst=src*scaletable (using normal matrix maths, but with "src"
+being diagonally mirrored, ie. the matrices are processed column by column,
+instead of row by column), repeated with src/dst exchanged.
+
src=blk, dst=temp_buffer
+ for pass=0 to 1
+ for x=0 to 7
+ for y=0 to 7
+ sum=0
+ for z=0 to 7
+ sum=sum+src[y+z*8]*(scaletable[x+z*8]/8)
+ next z
+ dst[x+y*8]=(sum+0fffh)/2000h ;<-- or so?
+ next y
+ next x
+ swap(src,dst)
+ next pass
+ for y=0 to 7
+ for x=0 to 7
+ R=[Crblk+((x+xx)/2)+((y+yy)/2)*8], B=[Cbblk+((x+xx)/2)+((y+yy)/2)*8]
+ G=(-0.3437*B)+(-0.7143*R), R=(1.402*R), B=(1.772*B)
+ Y=[Yblk+(x)+(y)*8]
+ R=MinMax(-128,127,(Y+R))
+ G=MinMax(-128,127,(Y+G))
+ B=MinMax(-128,127,(Y+B))
+ if unsigned then BGR=BGR xor 808080h ;aka add 128 to the R,G,B values
+ dst[(x+xx)+(y+yy)*16]=BGR
+ next x
+ next y
+ for i=0 to 63
+ Y=[Yblk+i]
+ Y=Y AND 1FFh ;clip to signed 9bit range
+ Y=MinMax(-128,127,Y) ;saturate from 9bit to signed 8bit range
+ if unsigned then Y=Y xor 80h ;aka add 128 to the Y value
+ dst[i]=Y
+ next i
+ iqtab_core(iq_y,src), src=src+64 ;luminance quant table
+ if command_word.bit0=1
+ iqtab_core(iq_uv,src), src=src+64 ;color quant table (optional)
+ endif
+ for i=0 to 63, iq[i]=src[i], next i
+ 1.000000000, 1.387039845, 1.306562965, 1.175875602,
+ 1.000000000, 0.785694958, 0.541196100, 0.275899379
+ 0 ,1 ,5 ,6 ,14,15,27,28,
+ 2 ,4 ,7 ,13,16,26,29,42,
+ 3 ,8 ,12,17,25,30,41,43,
+ 9 ,11,18,24,31,40,44,53,
+ 10,19,23,32,39,45,52,54,
+ 20,22,33,38,46,51,55,60,
+ 21,34,37,47,50,56,59,61,
+ 35,36,48,49,57,58,62,63
+ for y=0 to 7
+ for x=0 to 7
+ scalezag[zigzag[x+y*8]] = scalefactor[x] * scalefactor[y] / 8
+ next x
+ next y
+ for i=0 to 63, zagzig[zigzag[i]]=i, next i
+This command defines the IDCT scale matrix, which should be usually/always:
+
5A82 5A82 5A82 5A82 5A82 5A82 5A82 5A82
+ 7D8A 6A6D 471C 18F8 E707 B8E3 9592 8275
+ 7641 30FB CF04 89BE 89BE CF04 30FB 7641
+ 6A6D E707 8275 B8E3 471C 7D8A 18F8 9592
+ 5A82 A57D A57D 5A82 5A82 A57D A57D 5A82
+ 471C 8275 18F8 6A6D 9592 E707 7D8A B8E3
+ 30FB 89BE 7641 CF04 CF04 7641 89BE 30FB
+ 18F8 B8E3 6A6D 8275 7D8A 9592 471C E707
+ +s0 +s0 +s0 +s0 +s0 +s0 +s0 +s0
+ +s1 +s3 +s5 +s7 -s7 -s5 -s3 -s1
+ +s2 +s6 -s6 -s2 -s2 -s6 +s6 +s2
+ +s3 -s7 -s1 -s5 +s5 +s1 +s7 -s3
+ +s4 -s4 -s4 +s4 +s4 -s4 -s4 +s4
+ +s5 -s1 +s7 +s3 -s3 -s7 +s1 -s5
+ +s6 -s2 +s2 -s6 -s6 +s2 -s2 +s6
+ +s7 -s5 +s3 -s1 +s1 -s3 +s5 -s7
+Each macroblock consists of six blocks: Two low-resolution blocks with color
+information (Cr,Cb) and four full-resolution blocks with luminance (grayscale)
+information (Y1,Y2,Y3,Y4). The color blocks are zoomed from 8x8 to 16x16 pixel
+size, merged with the luminance blocks, and then converted from YUV to RGB
+format.
+
.-----. .-----. .-----. .-----.
+ | | | | |Y1|Y2| | |
+ | Cr | + | Cb | + |--+--| ----> | RGB |
+ | | | | |Y3|Y4| | |
+ '-----' '-----' '-----' '-----'
+Each macroblock consist of only one block: with luminance (grayscale)
+information (Y), the data comes out as such (it isn't converted to RGB).
+
.--. .--.
+ |Y | ----> |Y |
+ '--' '--'
+An (uncompressed) block consists of 64 values, representing 8x8 pixels. The
+first (upper-left) value is an absolute value (called "DC" value), the
+remaining 63 values are relative to the DC value (called "AC" values). After
+decompression and zig-zag reordering, the data in unfiltered horizontally and
+vertically (IDCT conversion, ie. the relative "AC" values are converted to
+absolute "DC" values).
PSX Video files are usually having file extension .STR (for "Streaming").
The MDEC data format is very similar to the JPEG file format, the main
+difference is that JPEG uses Huffman compressed blocks, whilst MDEC uses
+Run-Length (RL) compressed blocks.
+The (uncompressed) blocks are same as in JPEGs, using the same zigzag ordering,
+AC to DC conversion, and YUV to RGB conversion (ie. the MDEC hardware can be
+also used to decompress JPEGs, when handling the file header and huffman
+decompression by software).
+Some other differences are that MDEC has only 2 fixed-purpose quant tables,
+whilst JPEGs \<can> use up to 4 general-purpose quant tables. Also, JPEGs
+\<can> use other color resolutions than the 8x8 color info for 16x16
+pixels. Whereas, JPEGs \<can> do that stuff, but most standard JPEG files
+aren't actually using 4 quant tables, nor higher color resolution.
Within each block the DCT information and RLE compressed data is stored:
+
DCT ;1 halfword
+ RLE,RLE,RLE,etc. ;0..63 halfwords
+ EOB ;1 halfword
+DCT data has the quantization factor and the Direct Current (DC) reference.
+
15-10 Q Quantization factor (6 bits, unsigned)
+ 9-0 DC Direct Current reference (10 bits, signed)
+ 15-10 LEN Number of zero AC values to be inserted (6 bits, unsigned)
+ 9-0 AC Relative AC value (10 bits, signed)
+Indicates the end of a 8x8 pixel block, causing the rest of the block to be
+padded with zero AC values.
+
15-0 End-code (Fixed, FE00h)
+Data is sent in units of words (or, when using DMA, even in units of 32-words),
+which is making it neccessary to send some dummy halfwords (unless the
+compressed data size should match up the transfer unit). The value FE00h can be
+used as dummy value: When FE00h appears at the begin of a new block, or after
+the end of block, then it is simply ignored by the hardware (if it occurs
+elsewhere, then it acts as EOB end code, as described above).
The Memory Control registers are initialized by the BIOS, and, normally
+software doesn't need to change that settings. Some registers are useful for
+expansion hardware (allowing to increase the memory size and bus width).
0-23 Base Address (Read/Write)
+ 24-31 Fixed (Read only, always 1Fh)
+ 0-3 Write Delay (00h..0Fh=01h..10h Cycles)
+ 4-7 Read Delay (00h..0Fh=01h..10h Cycles)
+ 8 Recovery Period (0=No, 1=Yes, uses COM0 timings)
+ 9 Hold Period (0=No, 1=Yes, uses COM1 timings)
+ 10 Floating Period (0=No, 1=Yes, uses COM2 timings)
+ 11 Pre-strobe Period (0=No, 1=Yes, uses COM3 timings)
+ 12 Data Bus-width (0=8bits, 1=16bits)
+ 13 Auto Increment (0=No, 1=Yes)
+ 14-15 Unknown (R/W)
+ 16-20 Memory Window Size (1 SHL N bytes) (0..1Fh = 1 byte ... 2 gigabytes)
+ 21-23 Unknown (always zero)
+ 24-27 DMA timing override
+ 28 Address error flag. Write 1 to it to clear it.
+ 29 DMA timing select (0=use normal timings, 1=use bits 24-27)
+ 30 Wide DMA (0=use bit 12, 1=override to full 32 bits)
+ 31 Wait (1=wait on external device before being ready)
+bfc00000 lui $t0, 0x0013
+bfc00004 ori $t0, 0x243f
+bfc00008 lui $at, 0x1f80
+bfc0000c sw $t0, 0x1010($at)
+bfc00010 nop
+bfc00014 li $t0, 0x0b88
+bfc00018 lui $at, 0x1f80
+bfc0001c sw $t0, 0x1060($at)
+bfc00020 nop
+When using a logic analyzer to monitor the boot sequence, the instruction at +bfc00014 is still read using the old timings since reset, and then the instruction +at bfc00018 is finally read using the sped up timings.
+Reads and writes access times aren't symmetrical, and are each controlled with +their own values. By default, EXP1 will be set to 16 cycles when writing, which +is the slowest possible. If the programmer wants to write to a flash chip on +EXP1, or communicate with a computer, speeding up write access is recommended.
+The fastest a port could go would be by setting the lowest 16 bits to zero, which +will result in 3 CPU cycles for a single byte access.
+!CS always goes active at least one cycle before !WR or !RD go active. The various +timing changes are between all the events inside the data read/write waveform. The +whole formula for computing the total access time is fairly complex overall, and +difficult to properly describe.
+The data bus width will influence if the CPU does full 16 bits reads, or only +8 bits. When doing 32 bits operations, the CPU will issue 2 16-bits operations, +or 4 8-bits operations, keeping !CS active the whole time, and strobing !WR or +!RD accordingly. When doing these sequences, the address bus will also increment +automatically between each operation, if the auto-increment bit is active.
+This means it is possible to slightly shorten the read time of 4 bytes off the +same address by disabling auto-increment, and reading a full word. The CPU will +then read 4 bytes off the same address, and place them all into each byte of +the loaded register.
+The DMA timing override portion will replace the access timing when doing DMA, +only if the DMA override flag is set.
+The Wide DMA flag will enable full 32 bits DMA operations on the bus, by reusing +the low 16-bits address signals as the high 16-bits data. This means that if +the CPU is doing Wide DMA reads, the low 16-bits of the address bus will become +inputs.
+Trying to access addresses that exceed the selected size causes a bus exception.
+Maximum size would be Expansion 1 = 17h (8MB), BIOS = 16h (4MB), Expansion 2 =
+0Dh (8KB), Expansion 3 = 15h (2MB). Trying to select larger sizes would overlap
+the internal I/O ports, and crash the PSX. The Size bits seem to be ignored for
+SPU/CDROM. The SPU timings seem to be applied for both the 200h-byte SPU region
+at 1F801C00h and for the 200h-byte unknown region at 1F801E00h.
0-3 COM0 - Recovery period cycles
+ 4-7 COM1 - Hold period cycles
+ 8-11 COM2 - Floating release cycles
+ 12-15 COM3 - Strobe active-going edge delay
+ 16-31 Unknown/unused (read: always 0000h)
+ 1ST=0, SEQ=0, MIN=0
+ IF Use_COM0 THEN 1ST=1ST+COM0-1, SEQ=SEQ+COM0-1
+ IF Use_COM2 THEN 1ST=1ST+COM2, SEQ=SEQ+COM2
+ IF Use_COM3 THEN MIN=COM3
+ IF 1ST<6 THEN 1ST=1ST+1 ;(somewhat like so)
+ 1ST=1ST+AccessTime+2, SEQ=SEQ+AccessTime+2
+ IF 1ST<(MIN+6) THEN 1ST=(MIN+6)
+ IF SEQ<(MIN+2) THEN SEQ=(MIN+2)
+ 0-2 Unknown (no effect)
+ 3 Crashes when zero (except PU-7 and EARLY-PU-8, which <do> set bit3=0)
+ 4-6 Unknown (no effect)
+ 7 Delay on simultaneous CODE+DATA fetch from RAM (0=None, 1=One Cycle)
+ 8 Unknown (no effect) (should be set for 8MB, cleared for 2MB)
+ 9-11 Define 8MB Memory Window (first 8MB of KUSEG,KSEG0,KSEG1)
+ 12-15 Unknown (no effect)
+ 16-31 Unknown (Garbage)
+ 0 = 1MB Memory + 7MB Locked
+ 1 = 4MB Memory + 4MB Locked
+ 2 = 1MB Memory + 1MB HighZ + 6MB Locked
+ 3 = 4MB Memory + 4MB HighZ
+ 4 = 2MB Memory + 6MB Locked ;<--- would be correct for PSX
+ 5 = 8MB Memory ;<--- default by BIOS init
+ 6 = 2MB Memory + 2MB HighZ + 4MB Locked ;<-- HighZ = Second /RAS
+ 7 = 8MB Memory
+ 0-2 Unknown (Read/Write) (R/W)
+ 3 Scratchpad Enable 1 (0=Disable, 1=Enable when Bit7 is set, too) (R/W)
+ 4-5 Unknown (Read/Write) (R/W)
+ 6 Unknown (read=always zero) (R) or (W) or unused..?
+ 7 Scratchpad Enable 2 (0=Disable, 1=Enable when Bit3 is set, too) (R/W)
+ 8 Unknown (R/W)
+ 9 Crash (0=Normal, 1=Crash if code-cache enabled) (R/W)
+ 10 Unknown (read=always zero) (R) or (W) or unused..?
+ 11 Code-Cache Enable (0=Disable, 1=Enable) (R/W)
+ 12-31 Unknown (R/W)
+ Init Cache Step 1:
+ [FFFE0130h]=00000804h, then set cop0_sr=00010000h, then
+ zerofill each FOURTH word at [0000..0FFFh], then set cop0_sr=zero.
+ Init Cache Step 2:
+ [FFFE0130h]=00000800h, then set cop0_sr=00010000h, then
+ zerofill ALL words at [0000h..0FFFh], then set cop0_sr=zero.
+ Finish Initialization:
+ read 8 times 32bit from [A0000000h], then set [FFFE0130h]=0001E988h
+BIU = (BIU & ~0x0483) | 0x0804. With the normal
+BIU value of 0x001e988, this results in writing the value 0x001e90c
+- Then, it writes 0x00010000 to cop0's Status register. This order is
+important, as it would otherwise not take the BIU change, and still write
+to main ram instead of the i-cache region.
+- At this point, it proceeds with the step 1 of the flushcache procedure
+of clearing every fourth word.
+- Finally, it restores both the original value of the BIU and Status
+registers it had previously saved.
+A usable version of this code +is available.
+Note: FFFE0130h is described in LSI's "L64360" datasheet, chapter 14 (and
+probably also in their LR33300/LR33310 datasheet, if it were available in
+internet).
KUSEG KSEG0 KSEG1
+ 00000000h 80000000h A0000000h 2048K Main RAM (first 64K reserved for BIOS)
+ 1F000000h 9F000000h BF000000h 8192K Expansion Region 1 (ROM/RAM)
+ 1F800000h 9F800000h -- 1K Scratchpad (D-Cache used as Fast RAM)
+ 1F801000h 9F801000h BF801000h 4K I/O Ports
+ 1F802000h 9F802000h BF802000h 8K Expansion Region 2 (I/O Ports)
+ 1FA00000h 9FA00000h BFA00000h 2048K Expansion Region 3 (SRAM BIOS region for DTL cards)
+ 1FC00000h 9FC00000h BFC00000h 512K BIOS ROM (Kernel) (4096K max)
+ FFFE0000h (in KSEG2) 0.5K Internal CPU control registers (Cache Control)
+ 1024K VRAM (Framebuffers, Textures, Palettes) (with 2KB Texture Cache)
+ 512K Sound RAM (Capture Buffers, ADPCM Data, Reverb Workspace)
+ 0.5K CDROM controller RAM (see CDROM Test commands)
+ 16.5K CDROM controller ROM (Firmware and Bootstrap for MC68HC05 cpu)
+ 32K CDROM Buffer (IC303) (32Kx8) (BUG: only two sectors accessible?)
+ 128K External Memory Card(s) (EEPROMs)
+ Address Name i-Cache Write-Queue
+ 00000000h KUSEG Yes Yes
+ 80000000h KSEG0 Yes Yes
+ A0000000h KSEG1 No No
+ C0000000h KSEG2 (No code) No
+The i-Cache can hold 4096 bytes, or 1024 instructions.
+It is only active in the cached regions (KUSEG and KSEG0).
+There are reportedly some restrictions... not sure there... eventually it is
+using the LSBs of the address as cache-line number... so, for example, it
+couldn't simultaneously memorize opcodes at BOTH address 80001234h, AND at
+address 800F1234h (?)
MIPS CPUs usually have a d-Cache, but, in the PSX, Sony has assigned it as
+what's referenced as the "Scratchpad", mapped to a fixed memory location at
+1F800000h..1F8003FFh, ie. it's used as Fast RAM, rather than as cache.
+There \<might> be a way to disable that behavior (via Port FFFE0130h or
+so), but, the Kernel is accessing I/O ports via KUSEG, so activating Data Cache
+would cause the Kernel to access cached I/O ports.
+The purpose of the scratchpad is to have a more flexible cache system available
+to the programmer. Neither the kernel nor the Sony libraries will try to make use
+of it, so it is therefore completely up for grabs to the programmer. A good example
+would be if you were to write a piece of code that's doing a lot of CRC computation,
+to use the 1KB scratchpad to initially load the CRC lookup tables, which incidentally,
+is exactly 1KB large. Doing this will relieve SDRAM page changes overhead while reading
+the data to checksum linearly, while also keeping the whole CRC code in the i-Cache,
+hence being more optimal than what you'd get with an automatic d-Cache system.
As described above, the 512Mbyte KUSEG, KSEG0, and KSEG1 regions are mirrors of
+each other. Additional mirrors within these 512MB regions are:
+
2MB RAM can be mirrored to the first 8MB (strangely, enabled by default)
+ 512K BIOS ROM can be mirrored to the last 4MB (disabled by default)
+ Expansion hardware (if any) may be mirrored within expansion region
+ The seven DMA Control Registers at 1F8010x8h are mirrored to 1F8010xCh
+ Memory Error ------> Misalignments
+ (and probably also KSEG access in User mode)
+ Bus Error ------> Unused Memory Regions (including Gaps in I/O Region)
+ (unless RAM/BIOS/Expansion mirrors are mapped to "unused" area)
+The MIPS CPU has a 4-words deep pass-through write queue, in order to relieve
+some bus contention when writing to memory. If reading the same memory location
+that just got written into the write queue, it will first be flushed before
+being read back from memory.
+It is important to realize that the write queue's mechanism is only viable for
+normal memory attached to the main CPU, and that any hardware register state machine
+will get messed up by it.
+The typical example is the typical JEDEC standard to access flash, which usually does
+the following sequence to read the ID of a flash chip:
+
base[0xAAA] = 0xAA;
+ base[0x555] = 0x55;
+ base[0xAAA] = 0x90;
+ uint8_t mnfctrID = base[0x000];
+ uint8_t deviceId = base[0x002];
+In this example above, if base is located in a memory segment that has the write queue
+enabled, even if the low level assembly code will do the first 3 stores before doing 2 loads,
+the physical signals sent to that device through the CPU bus will be seen in the sequence:
+
store(0xaaa, 0xaa)
+load(0x000)
+store(0x555, 0x55)
+load(0x002)
+store(0xaaa, 0x90)
+Therefore, using KSEG1 that disables the write queue is the only way to ensure that the +operations are done in the proper way.
+The above is valid for most of the hardware connected to the main CPU, such as the CDROM +controller, exp1, exp2, the SPU, or the GPU. Therefore, using BF80180xh to access the +CDROM registers is more correct than using 1F80180xh.
+It is noteworthy that the Sony code will still incorrectly use KUSEG as the memory map +for all hardware registers, and they then spend a lot of time writing 4 dummy values +somewhere, in order to ensure the write queue has been flushed.
+The SN debugger in contrast is properly using the KSEG1 memory map for all the hardware +registers, nullifying the need to flush the write queue when accessing it.
+It's also noteworthy that doing ANY KSEG1 access (read OR write) will automatically stall +the CPU in order to flush the whole write queue before proceeding with the operation. +Therefore, all BIOS ROM operations will naturally and effectively have the write queue +disabled, as this code requires the CPU to read from KSEG1 constantly.
+This also means that if using KUSEG for the hardware registers, another method to flush +the write queue, albeit potentially slightly less efficient, would be to simply read +the first byte located at BFC00000h. The latter is what is effectively described as the +official method to flush the write queue in the MIPS handbook. This could be potentially +useful to flush the write queue all at once, instead of flushing it word by word.
+For Info on Exception vectors, Unused/Garbage memory locations, I/O Ports,
+Expansion ROM Headers, and Memory Waitstate Control, etc. see:
+I/O Map
+Memory Control
+EXP1 Expansion ROM Header
+BIOS Memory Map
+BIOS Memory Allocation
+COP0 - Exception Handling
+Unpredictable Things
Pinouts - Controller Ports and Memory-Card Ports
+Pinouts - Audio, Video, Power, Expansion Ports
+Pinouts - SIO Pinouts
Pinouts - Chipset Summary
+Pinouts - CPU Pinouts
+Pinouts - GPU Pinouts (for old 160-pin GPU)
+Pinouts - GPU Pinouts (for new 208-pin GPU)
+Pinouts - SPU Pinouts
+Pinouts - DRV Pinouts
+Pinouts - VCD Pinouts
+Pinouts - HC05 Pinouts
+Pinouts - MEM Pinouts
+Pinouts - CLK Pinouts
+Pinouts - PWR Pinouts
+Pinouts - Component List and Chipset Pin-Outs for Digital Joypad, SCPH-1080
+Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-1150
+Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-1200
+Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-110
+Pinouts - Component List and Chipset Pin-Outs for Namco Lightgun, NPC-103
+Pinouts - Component List and Chipset Pin-Outs for Multitap, SCPH-1070
+Pinouts - Memory Cards
Mods - Nocash PSX-XBOO Upload
+Mods - PAL/NTSC Color Mods
_______________________
+Memory card slot: | 9 7 6 | 5 4 3 | 2 1 |
+ |_=_=_=_|_=_=_=_|__=_=__|
+ _______________________
+ | 9 8 7 | 6 5 4 | 3 2 1 |
+Controller port: | * * * | * * * | * * * |
+ '\______|_______|______/'
+| Pin | +Dir | +Name | +SIO0 pin | +Description | +
|---|---|---|---|---|
| 1 | +In | +DAT/MISO |
+RX |
+Serial data from device | +
| 2 | +Out | +CMD/MOSI |
+TX |
+Serial data to device | +
| 3 | ++ | +7.5V |
++ | Supply for rumble motors | +
| 4 | ++ | GND |
++ | Ground | +
| 5 | ++ | +3.5V |
++ | Supply for main logic | +
| 6 | +Out | +/CSn |
+DTRn |
+Port select | +
| 7 | +Out | +SCK |
+SCK |
+Serial data clock | +
| 8 | +In | +/IRQ |
+/IRQ10 |
+Lightgun IRQ (controller only) | +
| 9 | +In | +/ACK |
+DSR |
+Data acknowledge IRQ | +
/CSn are two separate signals (/CS1 for controller/memory card port 1, /CS2 for
+port 2). All other signals are exactly the same on all four connectors (with the
+memory card slots lacking the /IRQ pin and shield).
Most or all controllers leave pin 8 unused, the pin can be used as lightpen
+input (not sure if the CPU is automatically latching a timer somewhere?), if
+there's no auto-latched timer, then the interrupt would be required to be
+handled as soon as possible; ie. don't disable interrupts, and don't "halt" the
+CPU for longer periods (as far as I understood, the GTE can halt the CPU when
+trying to read results of incomplete operations; to avoid that, one could wait
+by software, eg. inserting NOPs, before reading GTE results...?)
+(Some (or maybe all?) existing psx lightguns are reportedly connected to the
+Video output on the Multiout port for determining the current cathode ray
+position though).
1 RGB-Video Green
+ 2 RGB-Video Red
+ 3 Supply +5.0V (eg. supply for external RF adaptor)
+ 4 RGB-Video Blue
+ 5 Supply Ground
+ 6 S-Video C (chrominance)
+ 7 Composite Video (yellow cinch)
+ 8 S-Video Y (luminance) ____________________________
+ 9 Audio Left (white cinch) | |
+ 10 Audio Left Ground | 12 11 10 9 8 7 6 5 4 3 2 1 |
+ 11 Audio Right (red cinch) |____________________________|
+ 12 Audio Right Ground
+ Shield Video Ground
+This port exists only on older PSX boards (not on newer PSX boards, and not on
+PSone boards).
+The parallel port is used by various third-party unlicensed cheat cartridges and
+VCD player addons, as well as by the PSIO optical drive emulator (see below).
+
________
+ | | Console Rear View
+ GND ==| 1 35 |== GND .-------------------------.
+ /RESET =| 2 36 |= DACK5 |1 2 3 ... ... 32 33 34|
+ DREQ5 =| 3 37 |= /IRQ10 |35 36 37 ... ... 66 67 68|
+ /CS0 =| 4 38 |= /WR1 |__.-------------------.__|
+(SBEN)GND =| 5 39 |= GND(CS2)
+ D0 =| 6 40 |= D1
+ D2 =| 7 41 |= D3
+ D4 =| 8 42 |= D5
+ D6 =| 9 43 |= D7
+ D8 =|10 44 |= D9
+ D10 =|11 45 |= D11
+ D12 =|12 46 |= D13
+ D14 =|13 47 |= D15
+ A0 =|14 48 |= A1
+ A2 =|15 49 |= A3
+ GND =|16 50 |= GND
+ +3.5V ==|17 51 |== +3.5V
+ +7.5V ==|18 52 |== +7.5V
+ GND =|19 53 |= GND
+ A4 =|20 54 |= A5
+ A6 =|21 55 |= A7
+ A8 =|22 56 |= A9
+ A10 =|23 57 |= A11
+ A12 =|24 58 |= A13
+ A14 =|25 59 |= A15
+ A16 =|26 60 |= A17
+ A18 =|27 61 |= A19
+ A20 =|28 62 |= A21
+ A22 =|29 63 |= A23
+ /RD =|30 64 |= /WR0
+(/IRQ2)NC =|31 65 |= NC(/CS5)
+ SYSCK =|32 66 |= LRCK
+ BCLK =|33 67 |= SDIN
+ GND ==|34 68 |== GND
+ |________|
+The PSX contains an internal power supply, however, like the PSone, it's only
+having a "Standby" button, which merely disconnects 3.5V and 7.9V from the
+mainboard. The actual power supply remains powered, and wastes energy day and
+night, thanks Sony!
Inner +7.5V DC 2.0A (inside diameter 0.8mm)
+ Outer GND (outside diameter 5.0mm)
+That port exists only on original Playstation (not on the PSone). The shape of
+the Serial Port is identical to the 12pin Multiout (audio/video) port, but with
+only 8pins.
+
1 SIO1 In RXD receive data (from remote TXD)
+ 2 SIO2 - VCC +3.5VDC (supply, eg. for voltage conversion)
+ 3 SIO3 In DSR (from remote DTR) _________________
+ 4 SIO4 Out TXD transmit data (to remote RXD) | |
+ 5 SIO5 In CTS clear to send (from remote RTS) | 8 7 6 5 4 3 2 1 |
+ 6 SIO6 Out DTR (to remote DSR) |_________________|
+ 7 SIO7 - GND Ground (supply, eg. for voltage conversion)
+ 8 SIO8 Out RTS request to send (to remote CTS)
+ Shield GND Ground (to/from remote GND)
+The PSone doesn't have an external serial connector, however, easy to use
+soldering points for serial port signals are found as cluster of 5 soldering
+points (below CPU pin52), and a single soldering point (below CPU pin100),
+arranged like so (on PM-41 boards) (might be different on PM-41(2) boards):
+
CPU70.RTS
+ CPU71.CTS CPU74.TxD
+ CPU72.DTR CPU75.RxD CPU73.DSR
+The PSX serial circuit basically consists of a few transistors, diodes, and
+resistors. The relevant part is that most of the signals are inverted -
+compared with RS232 signals, the CPU uses normal high/low levels (of course
+with 0V and 3.5V levels, not -12V and +12V), and the signals at the serial port
+socket are inverted. Ie. if you want to built a RS232 adaptor, you must either
+externally undo the inversion, or, disconnect the transistors, and wire your
+circuit directly to the CPU signals.
+
SIO8 SIO6 SIO4 SIO1 SIO3 SIO5 SIO2 SIO7---GND
+ | | | | | | |
+ FB112 FB114 FB116 FB115 FBnnn FBnnn o--L102-------3.5V
+ | | | | | |
+ | | o-------|-------|-------|--------diode-------GND
+ | | | o-------|-------|--------diode-------GND
+ | | | | o-------|--------diode-------GND
+ | | | | | o--------diode-------GND
+ | | | | | |
+ | | | o-------|-------|--------[1K]--------3.5V
+ | | | | o-------|--------[1K]--------3.5V
+ [22] [22] [22] [22] | o--------[1K]--------3.5V
+ | | | | | |
+ Q105-----|-------|-------|-------|-------|--------------------GND
+ | Q105-----|-------|-------|-------|--------------------GND
+ | | | | Q106-----|--------------------GND
+ | | | | | Q106------------------GND
+ | | | | | |
+ | | | | o-------|--------[470]-------3.5V
+ | | | | | o--------[470]-------3.5V
+ | | | | | |
+ RTS DTR TxD RxD DSR CTS
+ CPU70 CPU72 CPU74 CPU75 CPU73 CPU71 <-- CPU Pin Numbers
+ out out out in in in
+The PSX serial port uses 0V/3.5V logic, whilst RS232 uses -5V/+5V...-15V/+15V
+logic. An example circuit for converting the logic levels would be:
+
PSX.VCC--+||--PSX.GND PSX.GND----DSUB.5.GND----DSUB.SHIELD DSUB.1,9----NC
+ ______ ______
+ ,-----------||+-|1 16|-------PSX.VCC ,-----------||+-|1 16|-------PSX.VCC
+ | PSX.GND---||+-|2 15|-------PSX.GND | PSX.GND---||+-|2 15|-------PSX.GND
+ '---------------|3 14|----DSUB.3.TXD '---------------|3 14|--- N/A
+ ,---+||--|4 13|----DSUB.2.RXD ,---+||--|4 13|--- N/A
+ '--------|5 12|-------PSX.RXD '--------|5 12|--- N/A
+ PSX.GND--+||--|6 11|-------PSX.TXD PSX.GND--+||--|6 11|--- N/A
+ DSUB.7.RTS----|7 10|--o<|--PSX.RTS DSUB.4.DTR----|7 10|--o<|--PSX.DTR
+ DSUB.8.CTS----|8 9|--|>o--PSX.CTS DSUB.6.DSR----|8 9|--|>o--PSX.DSR
+ |______| |______|
+ Board Expl.
+ PU-7 PSX, with AV multiout+cinch+svideo, GPU in two chips (160+64pins)
+ PU-8 PSX, with AV multiout+cinch, four 8bit Main RAM chips
+ EARLY-PU-8: "PU-8 1-658-467-11, N4" --> old chipset, resembles PU-7
+ LATE-PU-8: "PU-8 1-658-467-22, N6" --> new chipset, other as PU-7
+ PU-9 PSX, without SCPH-number (just sticker saying "NOT FOR SALE, SONY)
+ PU-16 PSX, with extra Video CD daughterboard (for SCPH-5903)
+ PU-18 PSX, with AV multiout only, single 32bit Main RAM (instead 4x8bit)
+ PU-20 PSX, unknown if/how it differs from PU-18
+ PU-22 PSX, unknown if/how it differs from PU-18
+ PU-23 PSX, with serial port, but without expansion port
+ PM-41 PSone, older PSone, for GPU/SPU with RAM on-board (see revisions)
+ PM-41(2) PSone, newer PSone, for GPU/SPU with RAM on-chip
+ PM-41, 1-679-335-21 PSone with incomplete RGB signals on multiout port
+ PM-41, 1-679-335-51 PSone with complete RGB signals on multiout port
+ IC103 - 208pin - "SONY CXD8530BQ" ;seen on PU-7 board
+ IC103 - 208pin - "SONY CXD8530CQ" ;seen on PU-7 and PU-8 boards
+ IC103 - 208pin - "SONY CXD8606Q" ;seen in PU-18 schematic
+ IC103 - 208pin - "SONY CXD8606AQ" ;seen on PU-xx? board
+ IC103 - 208pin - "SONY CXD8606BQ" ;seen on PM-41, PU-23, PU-20 boards
+ IC103 - 208pin - "SONY CXD8606CQ" ;seen on PM-41 board, too
+ IC203 - 160pin - "SONY CXD8514Q" ;seen on PU-7 and EARLY-PU-8 boards
+ IC203 - 208pin - "SONY CXD8561Q" ;seen on LATE-PU-8 board
+ IC203 - 208pin - "SONY CXD8561BQ" ;seen on PU-18, PU-20 boards
+ IC203 - 208pin - "SONY CXD8561CQ" ;seen on PM-41 board
+ IC203 - 208pin - "SONY CXD9500Q" ;with on-chip RAM ;for PM-41(2) board
+ IC21 - 208pin - "SONY CXD8538Q" ;seen on GP-11 (namco System 11) boards
+ IC103 - 208pin - "SONY CXD8654Q" ;seen on GP-15 (namco System 12) boards
+ IC308 - 100pin - "SONY CXD2922Q" (SPU) ;PU-7 and EARLY-PU-8
+ IC308 - 100pin - "SONY CXD2922BQ"(SPU) ;EARLY-PU-8
+ IC308 - 100pin - "SONY CXD2925Q" (SPU) ;LATE-PU-8, PU-18, PU-20
+ IC732 - 208pin - "SONY CXD2938Q" (SPU+CDROM) ;PSone/PM-41 Board
+ IC732 - 176pin - "SONY CXD2941R" (SPU+CDROM+SPU_RAM) ;PSone/PM-41(2) Board
+ IC402 - 24pin - "AKM AK4309VM" (Serial 2x16bit DAC);older boards only
+ IC405 - 8pin - "NJM2100E (TE2)" Audio Amplifier ;PU-8 and PU-22 boards
+ IC405 - 14pin - "NJM2174" Audio Amplifier with Mute ;later boards
+ IC106/IC107/IC108/IC109 - NEC 424805AL-A60 (28pin, 512Kx8) (PU-8 board)
+ IC106 - "Samsung K4Q153212M-JC60" (70pin, 512Kx32) (newer boards)
+ IC106 - "Toshiba T7X16 (70pin, 512Kx32) (newer boards, too)
+ IC201 - 64pin NEC uPD482445LGW-A70-S ;VRAM ;\on PU-7 and EARLY-PU-8 board
+ IC202 - 64pin NEC uPD482445LGW-A70-S ;VRAM ;/split into 2 chips !
+ IC201 - 64pin SEC KM4216Y256G-60 ;VRAM ;\on other PU-7 board
+ IC202 - 64pin SEC KM4216Y256G-60 ;VRAM ;/split into 2 chips !
+ IC201 - 100pin - Samsung KM4132G271BQ-10 (128Kx32x2) ;-on later boards
+ IC201 - 100pin - Samsung K4G163222A-PC70 (256Kx32x2) ;-on PM-41
+ IC310 - 40pin - "TOSHIBA TC51V4260DJ-70" ;seen on PU-8 board
+ IC310 - 40pin - EliteMT M11B416256A-35J (256K x 16bit)
+ IC102 - 40pin - "SONY ..." ;seen on PU-7 & early-PU-8 board (40pin!)
+ IC102 - 44pin - "SONY M538032E-02" ;seen on PU-16 (video CD, 1Mbyte BIOS)
+ IC102 - 32pin - "SONY M534031C-25" ;seen on later-PU-8 board
+ IC102 - 32pin - "SONY 2022" ;seen on PU-8 (1-658-467-23)
+ IC102 - 32pin - "SONY 2030" ;seen on PU-18 board
+ IC102 - 32pin - "SONY M534031E-47" ;seen on PM-41 board and PM-41(2)
+ IC102 - 32pin - "SONY M27V401D-41" ;seen on PM-41 board, too
+ X101 - 4pin - "67.737" (NTSC, presumably) ;PU-7 .. PU-20
+ X201 - 2pin - "17.734" (PAL) or "14.318" (NTSC) ;PU-22 .. PM-41(2)
+ IC204 - 8pin - "2294A" (PAL) or <unknown?> (NTSC) ;PU-22 .. PM-41(2)
+ IC601 - 3pin - "78M05" or "78005" ;used in PSone
+ IC606 16pin/10mm "TL594CD" (alternately to IC607) ;seen on PM-41 board
+ IC607 16pin/5mm "T594" (alternately to IC606) ;seen on PM-41 board, too
+ IC002 - 8pin - <not installed> (would be alternately to IC003) ;\on PSone
+ IC003 - 5pin - <usually installed> ;/
+ IC101 - 5pin - M51957B (Reset Generator) (on PSX-power supply boards)
+ U42 80pin SUB-CPU (CXP82300) with piggyback EPROM ;DTL-H2000
+ IC304 80pin SUB-CPU (MC68HC05L16) 80pin package ;PU-7 and EARLY-PU-8
+ IC304 52pin SUB-CPU (MC68HC05G6) 52pin package ;LATE-PU-8 and up
+ IC305 - 100pin SONY CXD1199BQ (Decoder/FIFO) ;PU-7
+ IC305 - 100pin SONY CXD1815Q (Decoder/FIFO) ;PU-8, PU-18
+ IC309 - 100pin SONY CXD2516Q (Signal Processor) ;PU-7 (100pin!)
+ IC309 - 80pin SONY CXD2510Q (Signal Processor) ;PU-8 and DTL-H2510
+ IC702 - 48pin SONY CXA1782BR (Servo Amplifier) ;PU-7, PU-8
+ IC101 - 100pin SONY CXD2515Q (=CXD2510Q+CXA1782BR) ;DTL-H2010
+ IC701 - 100pin SONY CXD2545Q (=CXD2510Q+CXA1782BR) ;PU-18
+ IC720 - 144pin SONY CXD1817R (=CXD2545Q+CXD1815Q) ;PU-20
+ IC102 - 28pin - "BA6297AFP" ;seen on DTL-H2010 drives
+ IC704 - 28pin - "BA6398FP" ;seen on PU-7
+ IC722 - 28pin - "BA6397FP" ;seen on late PU-8
+ IC722 - 28pin - "BA5947FP" ;seen on PM-41 and various boards
+ IC722 - 28pin - "Panasonic AN8732SB" ;seen on PM-41 board
+ ICxxx - 20pin SONY CXA1571N (RF Amplifier) (on DTL-H2010 drives)
+ IC703 - 20pin SONY CXA1791N (RF Amplifier) (on PU-18 boards)
+ IC723 - 20pin SONY CXA2575N-T4 (RF Matrix Amplifier) (on PU-22 .. PM-41(2))
+ IC207 64pin "SONY CXD2923AR" VRAM Data to Analog RGB ;\oldest
+ IC501 24pin "SONY CXA1645M" Analog RGB to Composite ;/
+ IC202 44pin "Philips TDA8771H" Digital RGB to Analog RGB ;\old boards
+ IC202 44pin "Motorola MC141685FT" Digital RGB to Analog RGB ;/
+ IC? 48pin "H7240AKV" 24bit RGB to Analog+Composite ;-SCPH-7001?
+ IC502 48pin "SONY CXA2106R-T4" 24bit RGB to Analog+Composite ;-newer boards
+ CDROM Drive: "KSM-440BAM" ;seen used with PM-41 board
+ IC602 5pin "L/\1B" or "<symbol> 3DR"
+ U? 24pin "9625H, CFS8121" ;SCPH-1080, digital pad (alternate?)
+ U? ?pin "SC438001" ;SCPH-1080, digital pad (alternate?)
+ U? 32pin "(M), SC401800" ;SCPH-1080, digital pad
+ U? 32pin "(M), SC442116" ;SCPH-xxxx, mouse
+ IC? 64pin "SONY CXD103, -166Q" ;SCPH-1070, multitap
+ U1 42pin "SD657, 9702K3006" ;SCPH-1150, analog pad, single motor
+ U1 42pin "SD657, 9726K3002" ;SCPH-1180, analog pad, without motor
+ U1 44pin "SONY CXD8771Q" ;SCPH-1200, analog pad, two motors (PSX)
+ U1 44pin "SD707, 039 107" ;SCPH-110, analog pad, two motors (PSone)
+ U1 44pin "SD787A" ;SCPH-xxx, analog pad, two motors (PS2?)
+ U? 64pin "SONY CXD8732AQ" ;SCPH-1020, memory card, on-chip FLASH
+ U? XXpin other chips ;SCPH-xxxx, memory card, external FLASH
+ U1 44pin "NAMCO103P" ;NPC-103, namco lightgun
+| Pin | +Name | +Pin | +Name | +Pin | +Name | +Pin | +Name | +
|---|---|---|---|---|---|---|---|
| 1 | +VDD |
+53 | +VDD |
+105 | +VDD |
+157 | +VDD |
+
| 2 | +VDD |
+54 | +VDD |
+106 | +VDD |
+158 | +VDD |
+
| 3 | +CRYSTALN |
+55 | +RAM.A11 |
+107 | +SBUS.D0 |
+159 | +TIMER1.CLK |
+
| 4 | +CRYSTALP |
+56 | +RAM.A10 |
+108 | +SBUS.D1 |
+160 | +TIMER0.CLK |
+
| 5 | +RAM.D31 |
+57 | +RAM.A9 |
+109 | +SBUS.D2 |
+161 | +GPU.D0 |
+
| 6 | +RAM.D30 |
+58 | +RAM.A8 |
+110 | +SBUS.D3 |
+162 | +GPU.D1 |
+
| 7 | +RAM.D29 |
+59 | +RAM.A7 |
+111 | +SBUS.D4 |
+163 | +GPU.D2 |
+
| 8 | +RAM.D28 |
+60 | +RAM.A6 |
+112 | +SBUS.D5 |
+164 | +GPU.D3 |
+
| 9 | +RAM.D27 |
+61 | +RAM.A5 |
+113 | +SBUS.D6 |
+165 | +GPU.D4 |
+
| 10 | +RAM.D26 |
+62 | +RAM.A4 |
+114 | +SBUS.D7 |
+166 | +GPU.D5 |
+
| 11 | +RAM.D25 |
+63 | +RAM.A3 |
+115 | +SBUS.D8 |
+167 | +GPU.D6 |
+
| 12 | +RAM.D24 |
+64 | +RAM.A2 |
+116 | +SBUS.D9 |
+168 | +GPU.D7 |
+
| 13 | +RAM.D23 |
+65 | +GND |
+117 | +GND |
+169 | +GPU.D8 |
+
| 14 | +VDD |
+66 | +VDD |
+118 | +VDD |
+170 | +GND |
+
| 15 | +GND |
+67 | +RAM.A1 |
+119 | +SBUS.D10 |
+171 | +VDD |
+
| 16 | +RAM.D22 |
+68 | +RAM.A0 |
+120 | +SBUS.D11 |
+172 | +GPU.D9 |
+
| 17 | +RAM.D21 |
+69 | +/RC_NET |
+121 | +SBUS.D12 |
+173 | +GPU.D10 |
+
| 18 | +RAM.D20 |
+70 | +SIO1./RTS |
+122 | +SBUS.D13 |
+174 | +GPU.D11 |
+
| 19 | +RAM.D19 |
+71 | +SIO1./CTS |
+123 | +SBUS.D14 |
+175 | +GPU.D12 |
+
| 20 | +RAM.D18 |
+72 | +SIO1./DTR |
+124 | +SBUS.D15 |
+176 | +GPU.D13 |
+
| 21 | +RAM.D17 |
+73 | +SIO1./DSR |
+125 | +SBUS.A0 |
+177 | +GPU.D14 |
+
| 22 | +RAM.D16 |
+74 | +SIO1.TX |
+126 | +SBUS.A1 |
+178 | +GPU.D15 |
+
| 23 | +RAM.D15 |
+75 | +SIO1.RX |
+127 | +SBUS.A2 |
+179 | +GPU.D16 |
+
| 24 | +RAM.D14 |
+76 | +/EXT_RESET |
+128 | +SBUS.A3 |
+180 | +GPU.D17 |
+
| 25 | +RAM.D13 |
+77 | +SIO0./DTR2 |
+129 | +SBUS.A4 |
+181 | +GPU.D18 |
+
| 26 | +VDD |
+78 | +GND |
+130 | +GND |
+182 | +GND |
+
| 27 | +GND |
+79 | +VDD |
+131 | +VDD |
+183 | +VDD |
+
| 28 | +RAM.D12 |
+80 | +SIO0./DTR1 |
+132 | +SBUS.A5 |
+184 | +GPU.D19 |
+
| 29 | +RAM.D11 |
+81 | +SIO0./SCK |
+133 | +SBUS.A6 |
+185 | +GPU.D20 |
+
| 30 | +RAM.D10 |
+82 | +SIO0./DSR |
+134 | +SBUS.A7 |
+186 | +GPU.D21 |
+
| 31 | +RAM.D9 |
+83 | +SIO0.TX |
+135 | +SBUS.A8 |
+187 | +GPU.D22 |
+
| 32 | +RAM.D8 |
+84 | +SIO0.RX |
+136 | +SBUS.A9 |
+188 | +GPU.D23 |
+
| 33 | +RAM.D7 |
+85 | +SBUS.DACK5_PIO |
+137 | +SBUS.A10 |
+189 | +GPU.D24 |
+
| 34 | +RAM.D6 |
+86 | +SBUS.DREQ5_PIO |
+138 | +SBUS.A11 |
+190 | +GPU.D25 |
+
| 35 | +RAM.D5 |
+87 | +SBUS.DACK4_SPU |
+139 | +SBUS.A12 |
+191 | +GPU.D26 |
+
| 36 | +RAM.D4 |
+88 | +SBUS.DREQ4_SPU |
+140 | +SBUS.A13 |
+192 | +GPU.D27 |
+
| 37 | +RAM.D3 |
+89 | +/IRQ10_PIO |
+141 | +SBUS.A14 |
+193 | +GPU.D28 |
+
| 38 | +VDD |
+90 | +/IRQ9_SPU |
+142 | +SBUS.A15 |
+194 | +GPU.D29 |
+
| 39 | +GND |
+91 | +GND |
+143 | +GND |
+195 | +GND |
+
| 40 | +RAM.D2 |
+92 | +VDD |
+144 | +VDD |
+196 | +VDD |
+
| 41 | +RAM.D1 |
+93 | +/CSHTST |
+145 | +SBUS.A16 |
+197 | +GPU.D30 |
+
| 42 | +RAM.D0 |
+94 | +/IRQ2_CDROM |
+146 | +SBUS.A17 |
+198 | +GPU.D31 |
+
| 43 | +RAM./WE |
+95 | +SBUS./CS5_CDROM |
+147 | +SBUS.A18 |
+199 | +/IRQ0 |
+
| 44 | +RAM./RAS1 |
+96 | +SBUS./CS4_SPU |
+148 | +SBUS.A19 |
+200 | +GPU.DREQ2 |
+
| 45 | +RAM./RAS0 |
+97 | +SBUS./CS2_BIOS |
+149 | +SBUS.A20 |
+201 | +SYSCK0 |
+
| 46 | +RAM./CAS3 |
+98 | +SBUS./CS0_EXP1 |
+150 | +SBUS.A21 |
+202 | +GPU.DACK2 |
+
| 47 | +RAM./CAS2 |
+99 | +SBUS./WR1 |
+151 | +SBUS.A22 |
+203 | +GPU./WR |
+
| 48 | +RAM./CAS1 |
+100 | +SBUS./WR0 |
+152 | +SBUS.A23 |
+204 | +GPU./RD |
+
| 49 | +RAM./CAS0 |
+101 | +SBUS./RD |
+153 | +GPU.A0 |
+205 | +GPU./CS7 |
+
| 50 | +VDD |
+102 | +/IRQ1_GPU |
+154 | +SYSCK1 |
+206 | +DSYSCK0 |
+
| 51 | +GND |
+103 | +GND |
+155 | +GND |
+207 | +GND |
+
| 52 | +GND |
+104 | +GND |
+156 | +GND |
+208 | +GND |
+
Pin5-68 = Main RAM bus. Pin 95-152 = System bus. Pin 102,153,159-206 = Video
+bus.
RAM.A11 is wired to the RAM chips' A8 line,
+ while RAM.A8 and RAM.A10 are left unconnected.RAM./RAS1 is only used on systems with 4 or 8 MB RAM./RC_NET is tied to 3.5V, while /CSHTST (test pin?) is wired to ground.SYSCK0 (33 MHz), DSYSCK0 (67 MHz) and SYSCK1 (33 MHz) are clock outputs
+ from the CPU to the rest of the system.TIMER0.CLK is fed from the GPU's DOTCK output, while TIMER1.CLK is fed
+ from its HBLANK output.CRYSTALP and CRYSTALN are meant to be connected to a crystal, however all
+ known console models feed CRYSTALP with the clock generated by an external
+ oscillator and leave CRYSTALN open.SBUS./WR1 (upper byte write strobe) is routed to the expansion port but
+ otherwise left unused, as all system bus devices are either 8-bit (CD-ROM,
+ BIOS ROM) or only support 16-bit writes (SPU).SBUS.A0-SBUS.A23 are latched outputs and are not affected by RAM and GPU
+ addressing.Old 160-pin GPU is used on PU-7 boards and EARLY-PU-8 boards.
Unlike the later 208pin GPU's, the old 160pin GPU has less supply pins, and, it
+doesn't have a 24bit RGB output (nor any other video output at all), instead,
+it's used with a RGB D/A converter that reads the video data directly from the
+Dual-ported VRAM chips (ie. from special RAM chips with two data busses, one
+bus for GPU read/write access, and one for the RGB video output).
+
1-VCC 21-GND 41-D16 61-D2 81-D12'a 101-GND 121-D7'b 141-GND
+ 2-GND 22-D31 42-D15 62-D1 82-D11'a 102-DT/OE'b 122-D6'b 142-53MHz
+ 3-/GPUCS 23-D30 43-VCC 63-D0 83-D10'a 103-DT/OE'a 123-D5'b 143-VCC
+ 4-GPU.A2 24-D29 44-GND 64-GND 84-D9'a 104-/RAS 124-D4'b 144-GND
+ 5-/GPURD 25-D28 45-D14 65-VCC 85-D8'a 105-/WE'a 125-D3'b 145-FSC
+ 6-/GPUWR 26-D27 46-D13 66-A8'a 86-VCC 106-/WE'b 126-D2'b 146-VCC
+ 7-DACK2 27-D26 47-D12 67-A7'a 87-GND 107-/SE 127-D1'b 147-GND
+ 8-/RESET 28-VCC 48-D11 68-A6'a 88-D7'a 108-SC 128-D0'b 148-DOTCLK
+ 9-VCC 29-GND 49-D10 69-A5'a 89-D6'a 109-VCC 129-VCC 149-VCC
+ 10-GND 30-D25 50-GND 70-GND 90-D5'a 110-GND 130-GND 150-GND
+ 11-SYSCK0 31-D24 51-VCC 71-A4'a 91-D4'a 111-D15'b 131-A8'b 151-MEMCK1
+ 12-VCC 32-D23 52-D9 72-A3'a 92-D3'a 112-D14'b 132-A7'b 152-MEMCK2
+ 13-GND 33-D22 53-D8 73-A2'a 93-D2'a 113-D13'b 133-A6'b 153-BLANK
+ 14-DREQ2 34-D21 54-D7 74-A1'a 94-D1'a 114-D12'b 134-A5'b 154-/24BPP
+ 15-/IRQ1 35-D20 55-D6 75-A0'a 95-D0'a 115-D11'b 135-A4'b 155-/CSYNC
+ 16-HBLANK 36-VCC 56-D5 76-GND 96-VCC 116-D10'b 136-A3'b 156-/HSYNC
+ 17-VBLANK 37-GND 57-D4 77-VCC 97-DSF 117-D9'b 137-A2'b 157-/VSYNC
+ 18-high? 38-D19 58-D3 78-D15'a 98-/CAS'b 118-D8'b 138-A1'b 158-VCC
+ 19-high? 39-D18 59-GND 79-D14'a 99-/CAS'a 119-VCC 139-A0'b 159-GND
+ 20-VCC 40-D17 60-VCC 80-D13'a 100-VCC 120-GND 140-VCC 160-DSYSCK0
+ 151-? --- (mem clock?)
+ 152-? (mem clock?)
+ 153-BLANK (high in HBLANK & VBLANK)
+ 154-/24BPP (high=15bpp, low=24bpp)
+ 156-/HSYNC rate:65us=15KHz, low:3.5us
+ 157-/VSYNC rate:20ms=50Hz, low:130us=TwoLines
+This chip is used with the old 160pin GPU and two Dual-ported VRAM chips. The
+2x16bit databus is capable of reading up to 32bits of VRAM data, and the chip
+does then extract the 15bit or 24bit RGB values from that data (depending on
+the GPU's current color depth).
+The RGB outputs (pin 5,7,9) seem to be passed through transistors and
+capacitors... not sure how the capacitors could output constant voltage
+levels... unless the RGB signals are actually some kind of edge-triggering PWM
+pulses rather than real analog levels(?)
+
1-test? 9-BLUE 17-GND 25-D0'a 33-D8'a 41-D15'a 49-D7'b 57-D13'b
+ 2-test? 10-Vxx 18-MEMCK1 26-D1'a 34-D9'a 42-D0'b 50-D8'b 58-D14'b
+ 3-Vxx 11-test? 19-/24BPP 27-D2'a 35-D10'a 43-D1'b 51-D9'b 59-D15'b
+ 4-Vxx 12-test? 20-MEMCK2 28-D3'a 36-D11'a 44-D2'b 52-D10'b 60-GND
+ 5-RED 13-test? 21-BLANK 29-D4'a 37-D12'a 45-D3'b 53-D11'b 61-GND
+ 6-Vxx 14-aGND? 22-DOTCLK 30-D5'a 38-D13'a 46-D4'b 54-D12'b 62-GND
+ 7-GREEN 15-aGND? 23-GND 31-D6'a 39-D14'a 47-D5'b 55-GND 63-test?
+ 8-GND 16-aGND? 24-Vxx 32-D7'a 40-GND 48-D6'b 56-Vxx 64-GND
+These are special Dual-ported VRAM chips (with two data busses), the D0-D15
+pins are wired to the GPU (for read/write access), the Q0-Q15 pins are wired to
+the RGB D/A converter (for sequential video output).
+
1-VCC 9-Q2 17-D5 25-/UWE 33-GND 41-DSF 49-Q10 57-VCC
+ 2-/DT/OE 10-D2 18-VCC 26-/RAS 34-A3 42-GND 50-D11 58-D14
+ 3-GND 11-Q3 19-Q6 27-A8 35-A2 43-D8 51-Q11 59-Q14
+ 4-Q0 12-D3 20-D6 28-A7 36-A1 44-Q8 52-GND 60-D15
+ 5-D0 13-GND 21-Q7 29-A6 37-A0 45-D9 53-D12 61-Q15
+ 6-Q1 14-Q4 22-D7 30-A5 38-QSF 46-Q9 54-Q12 62-GND
+ 7-D1 15-D4 23-GND 31-A4 39-/CAS 47-VCC 55-D13 63-/SE
+ 8-VCC 16-Q5 24-/LWE 32-VCC 40-NC 48-D10 56-Q13 64-SC
+ 1-GND1 4-BIN 7-NPIN 10-SYNCIN 13-IREF 16-YOUT 19-VCC2 22-GOUT
+ 2-RIN 5-NC 8-BFOUT 11-BC 14-VREF 17-YTRAP 20-CVOUT 23-ROUT
+ 3-GIN 6-SCIN 9-YCLPC 12-VCC1 15-COUT 18-FO 21-BOUT 24-GND2
+ GPU pin 145 (old 160-pin GPU)
+ GPU pin 154 (new 208-pin GPU)
+ IC204 (on later boards, eg. PSone)
+New 206-pin GPU is used LATE-PU-8 boards and up.
| Pin | +Name | +Pin | +Name | +Pin | +Name | +Pin | +Name | +
|---|---|---|---|---|---|---|---|
| 1 | +HOST./CS |
+53 | +HOST.D10 |
+105 | +GND |
+157 | +NTSC/PAL |
+
| 2 | +HOST.A0 |
+54 | +HOST.D9 |
+106 | +VDD |
+158 | +/VSYNC |
+
| 3 | +HOST./RD |
+55 | +HOST.D8 |
+107 | +SGRAM.D9 |
+159 | +/HSYNC |
+
| 4 | +HOST./WR |
+56 | +HOST.D7 |
+108 | +SGRAM.D8 |
+160 | +DAC.B0 |
+
| 5 | +HOST.DACK |
+57 | +HOST.D6 |
+109 | +SGRAM.D7 |
+161 | +DAC.B1 |
+
| 6 | +/RESET |
+58 | +HOST.D5 |
+110 | +SGRAM.D6 |
+162 | +DAC.B2 |
+
| 7 | +VDD |
+59 | +HOST.D4 |
+111 | +SGRAM.D5 |
+163 | +DAC.B3 |
+
| 8 | +GND |
+60 | +GND |
+112 | +SGRAM.D4 |
+164 | +GND |
+
| 9 | +/SYSCLK |
+61 | +VDD |
+113 | +GND |
+165 | +VDD |
+
| 10 | +VDD |
+62 | +HOST.D3 |
+114 | +VDD |
+166 | +DAC.B4 |
+
| 11 | +GND |
+63 | +HOST.D2 |
+115 | +SGRAM.D3 |
+167 | +DAC.B5 |
+
| 12 | +HOST.DREQ |
+64 | +HOST.D1 |
+116 | +SGRAM.D2 |
+168 | +DAC.B6 |
+
| 13 | +HOST./IRQ |
+65 | +HOST.D0 |
+117 | +SGRAM.D1 |
+169 | +DAC.B7 |
+
| 14 | +HBLANK |
+66 | +GND |
+118 | +SGRAM.D0 |
+170 | +DAC.G0 |
+
| 15 | +GND |
+67 | +VDD |
+119 | +GND |
+171 | +DAC.G1 |
+
| 16 | +VDD |
+68 | +PCKSL2 |
+120 | +VDD |
+172 | +DAC.G2 |
+
| 17 | +VBLANK |
+69 | +PCKSL1 |
+121 | +SGRAM./CS1 |
+173 | +DAC.G3 |
+
| 18 | +HVHLD |
+70 | +PCKSL0 |
+122 | +SGRAM./CS0 |
+174 | +GND |
+
| 19 | +GND |
+71 | +TEST3 |
+123 | +SGRAM.DSF |
+175 | +VDD |
+
| 20 | +GND |
+72 | +TEST2 |
+124 | +SGRAM./RAS |
+176 | +DAC.G4 |
+
| 21 | +NC |
+73 | +TEST1 |
+125 | +SGRAM./CAS |
+177 | +DAC.G5 |
+
| 22 | +VDD |
+74 | +TEST0 |
+126 | +SGRAM./WE |
+178 | +DAC.G6 |
+
| 23 | +VDD |
+75 | +VDD |
+127 | +SGRAM.DQMH |
+179 | +DAC.G7 |
+
| 24 | +HOST.D31 |
+76 | +GND |
+128 | +SGRAM.DQML |
+180 | +DAC.R0 |
+
| 25 | +HOST.D30 |
+77 | +SGRAM.D31 |
+129 | +GND |
+181 | +DAC.R1 |
+
| 26 | +HOST.D29 |
+78 | +SGRAM.D30 |
+130 | +VDD |
+182 | +DAC.R2 |
+
| 27 | +HOST.D28 |
+79 | +SGRAM.D29 |
+131 | +MCLKOUT |
+183 | +DAC.R3 |
+
| 28 | +HOST.D27 |
+80 | +VDD |
+132 | +GND |
+184 | +GND |
+
| 29 | +VDD |
+81 | +GND |
+133 | +VDD |
+185 | +VDD |
+
| 30 | +GND |
+82 | +SGRAM.D28 |
+134 | +MCLKIN |
+186 | +DAC.R4 |
+
| 31 | +HOST.D26 |
+83 | +SGRAM.D27 |
+135 | +GND |
+187 | +DAC.R5 |
+
| 32 | +HOST.D25 |
+84 | +SGRAM.D26 |
+136 | +VDD |
+188 | +DAC.R6 |
+
| 33 | +HOST.D24 |
+85 | +SGRAM.D25 |
+137 | +SGRAM.A9 |
+189 | +DAC.R7 |
+
| 34 | +HOST.D23 |
+86 | +SGRAM.D24 |
+138 | +SGRAM.A8 |
+190 | +GND |
+
| 35 | +HOST.D22 |
+87 | +VDD |
+139 | +SGRAM.A7 |
+191 | +VDD |
+
| 36 | +HOST.D21 |
+88 | +GND |
+140 | +SGRAM.A6 |
+192 | +VCLK_NTSC |
+
| 37 | +VDD |
+89 | +SGRAM.D23 |
+141 | +VDD |
+193 | +VDD |
+
| 38 | +GND |
+90 | +SGRAM.D22 |
+142 | +GND |
+194 | +GND |
+
| 39 | +HOST.D20 |
+91 | +SGRAM.D21 |
+143 | +SGRAM.A5 |
+195 | +VDD |
+
| 40 | +HOST.D19 |
+92 | +SGRAM.D20 |
+144 | +SGRAM.A4 |
+196 | +VCLK_PAL |
+
| 41 | +HOST.D18 |
+93 | +SGRAM.D19 |
+145 | +SGRAM.A3 |
+197 | +VDD |
+
| 42 | +HOST.D17 |
+94 | +SGRAM.D18 |
+146 | +GND |
+198 | +GND |
+
| 43 | +VDD |
+95 | +SGRAM.D17 |
+147 | +VDD |
+199 | +PCK |
+
| 44 | +GND |
+96 | +GND |
+148 | +SGRAM.A2 |
+200 | +GND |
+
| 45 | +HOST.D16 |
+97 | +VDD |
+149 | +SGRAM.A1 |
+201 | +VDD |
+
| 46 | +HOST.D15 |
+98 | +SGRAM.D16 |
+150 | +SGRAM.A0 |
+202 | +DMASK |
+
| 47 | +HOST.D14 |
+99 | +SGRAM.D15 |
+151 | +VDD |
+203 | +ODE2 |
+
| 48 | +HOST.D13 |
+100 | +SGRAM.D14 |
+152 | +GND |
+204 | +GND |
+
| 49 | +HOST.D12 |
+101 | +SGRAM.D13 |
+153 | +FSC |
+205 | +VDD |
+
| 50 | +HOST.D11 |
+102 | +SGRAM.D12 |
+154 | +VDD |
+206 | +/DSYSCK |
+
| 51 | +VDD |
+103 | +SGRAM.D11 |
+155 | +GND |
+207 | +GND |
+
| 52 | +GND |
+104 | +SGRAM.D10 |
+156 | +CSYNC |
+208 | +VDD |
+
Pin 77..150 = Video RAM Bus. Pin 156..189 = Video Out Bus. Other = CPU Bus. Pin
+153: Sub Carrier (NC on newer boards whick pick color clock from IC204).
SGRAM./CS1 is only used on arcade boards with 2 MB VRAM (two 1 MB chips).HVHLD has a 4.7k pullup to 3.5V.TEST0-TEST3 are tied to 3.5V. PCKSL0-PCKSL2 (outputs possibly related to
+ the current resolution/pixel clock?) are left unconnected.MCLKIN and MCLKOUT are tied together and wired to the DAC's clock input.
+ MCLKIN could possibly be an external clock input for genlocking purposes.VCLK_PAL or
+ VCLK_NTSC is wired up, depending on the console's region. On later boards
+ both are tied together and connected to a programmable clock generator, which
+ is preprogrammed to generate the appropriate frequency./VSYNC and /HSYNC are only connected to test points./CSYNC = (/VSYNC AND /HSYNC). BLANK = (VBLANK OR HBLANK).SGRAM.DQML is wired to both DQM0 and DQM2 on the SGRAM, while
+ SGRAM.DQMH is wired to both DQM1 and DQM3.DMASK outputs the mask/"alpha" bit of the current pixel and is used by some
+ arcade boards to composite the GPU's output on top of an external video
+ source. ODE2 indicates which field is currently being output in interlaced
+ mode.Region Japan+Europe: TDA8771AN
+Region America+Asia: MC151854FLTEG or so?
+
1-IREF 6-GNDd1 11-R1 16-G4 21-B7 26-B2 31-CLK 36-OUTB 41-NC
+ 2-GNDa1 7-VDDd1 12-R0 17-G3 22-B6 27-VDDd2 32-VDDa1 37-NC 42-GNDa2
+ 3-R7 8-R4 13-G7 18-G2 23-B5 28-GNDd2 33-VREF 38-NC 43-VDDa4
+ 4-R6 9-R3 14-G6 19-G1 24-B4 29-B1 34-NC 39-VDDa3 44-OUTR
+ 5-R5 10-R2 15-G5 20-G0 25-B3 30-B0 35-VDDa2 40-OUTG
+| Pin | +Name | +Pin | +Name | +Pin | +Name | +Pin | +Name | +
|---|---|---|---|---|---|---|---|
| 1 | +BCLAMP |
+13 | +NTSC/PAL |
+25 | +G7 |
+37 | +B3 |
+
| 2 | +AGND2 |
+14 | +SYNCIN |
+26 | +G6 |
+38 | +B2 |
+
| 3 | +ROUT |
+15 | +SCIN |
+27 | +G5 |
+39 | +B1 |
+
| 4 | +GOUT |
+16 | +R7 |
+28 | +G4 |
+40 | +B0 |
+
| 5 | +BOUT |
+17 | +R6 |
+29 | +G3 |
+41 | +VCLK |
+
| 6 | +YOUT |
+18 | +R5 |
+30 | +G2 |
+42 | +DGND |
+
| 7 | +COUT |
+19 | +R4 |
+31 | +G1 |
+43 | +VREFIN |
+
| 8 | +VOUT |
+20 | +DVDD |
+32 | +G0 |
+44 | +VREFOUT |
+
| 9 | +AVCC2 |
+21 | +R3 |
+33 | +B7 |
+45 | +AGND1 |
+
| 10 | +YTRAP |
+22 | +R2 |
+34 | +B6 |
+46 | +RCRAMP |
+
| 11 | +NC |
+23 | +R1 |
+35 | +B5 |
+47 | +AVCC1 |
+
| 12 | +POWER_SAVE |
+24 | +R0 |
+36 | +B4 |
+48 | +GCLAMP |
+
Pin 3..8 (analogue outputs) are passed via external 75 ohm resistors.
+Pin 6,7 additionally via 220uF. Pin 8 additionally via smaller capacitor.
+Pin 10 (YTRAP) wired via 2K7 to 5.0V.
+Pin 1,44,46,48 (can) connect via capacitors to ground (only installed for 44).
+The 4.4MHz clock is obtained via 2K2 from IC204.Pin6.
+The /PAL pin can be reportedly GROUNDED to force PAL colors in NTSC mode, when
+doing that, you may first want to disconnect the pin from the GPU.
+Note: Rohm BH7240AKV has same pinout (XXX but with pin7/pin8 swapped?)
Measuring in the region near GPU Pin10 is the nocash number one source for
+blowing up components on the mainboard. If you want to measure that signals
+while power is on, better measure them at the CPU side.
1-D0 14-D11 27-A8 40-GND 53-3.5V 66-A15 79-5V 92-LRIA
+ 2-D1 15-GND 28-3.5V 41-SYSCK 54-GND 67-A14 80-A3 93-DTIA
+ 3-3.5V 16-D12 29-GND 42-GND 55-D7 68-A13 81-A2 94-BCIB
+ 4-GND 17-D13 30-A9 43-TEST 56-D6 69-A12 82-A1 95-LRIB
+ 5-D2 18-D14 31-/SPU 44-TES2 57-D5 70-A11 83-A0 96-DTIB
+ 6-D3 19-D15 32-/RD 45-D15 58-D4 71-A10 84-/WE0 97-BCKO
+ 7-D4 20-A1 33-/WR 46-D14 59-D3 72-A9 85-/OE0 98-LRCO
+ 8-D5 21-A2 34-DACK 47-D13 60-D2 73-A8 86-/WE1 99-DATO
+ 9-D6 22-A3 35-/IRQ 48-D12 61-D1 74-A7 87-/OE1 100-WCKO
+ 10-D7 23-A4 36-DREQ 49-D11 62-D0 75-A6 88-GND
+ 11-D8 24-A5 37-MUTE 50-D10 63-/RAS 76-A5 89-XCK
+ 12-D9 25-A6 38-/RST 51-D9 64-/CAS 77-A4 90-GND
+ 13-D10 26-A7 39-NC 52-D8 65-GND 78-GND 91-BCIA
+ 1-DA16 23-FILO 45-LOCK 67-FSTO 89-SCSY 111-XCS 133-HD9 155-VSS5
+ 2-DA15 24-FILI 46-SSTP 68-COUT 90-SCLK 112-XRD 134-HD8 156-HA1
+ 3-DA14 25-PCO 47-SFDR 69-XDRST 91-SQSO 113-XWR 135-HD7 157-HA0
+ 4-VDDM0 26-CLTV 48-SRDR 70-DA11 92-SENS 114-HINT 136-HD6 158-VDDM3
+ 5-DA13 27-AVSSO 49-TFDR 71-DA10 93-DATA 115-XIRQ 137-VDD4 159-XCK
+ 6-DA12 28-RFAC 50-TRDR 72-DA09 94-XLAT 116-VDDM2 138-HD5 160-DTIB
+ 7-LRCK 29-BIAS 51-VSSM1 73-DA08 95-CLOK 117-XSCS 139-HD4 161-BCKO
+ 8-WDCK 30-ASYI 52-FFDA 74-AVSMO 96-XINT 118-XHCS 140-HD3 162-LRCO
+ 9-VDD0 31-AVDDO 53-FRDA 75-AVDMO 97-A4 119-XHRD 141-HD2 163-DAVDD0
+ 10-VSS0 32-ASYO 54-MDP 76-DA07 98-A3 120-XHWR 142-VSS4 164-DAREFL
+ 11-PSSL 33-VC 55-MDS 77-DA06 99-A2 121-DACK 143-HD1 165-AOUTL
+ 12-ASYE 34-CE 56-VDD2 78-VDDM1 100-A1 122-DREQ 144-HD0 166-DAVSS0
+ 13-GND 35-CEO 57-VSS2 79-DA05 101-A0 123-XRST 145-VSSM3 167-DAVSS1
+ 14-C4M 36-CEI 58-MIRR 80-DA04 102-D7 124-VDD3 146-HA9 168-AOUTR
+ 15-C16M 37-RFDC 59-DFCT 81-DA03 103-D6 125-SYSCK 147-HA8 169-DAREFR
+ 16-FSOF 38-ADIO 60-AVSM1 82-DA02 104-D5 126-VSS3 148-HA7 170-DAVDD1
+ 17-XTSL 39-AVDD1 61-AVDM1 83-DA01 105-D4 127-HD15 149-HA6 171-MUTO
+ 18-VDD1 40-IGEN 62-FOK 84-WFCK 106-VSSM2 128-HD14 150-HA5 172-DATO
+ 19-GND 41-AVSS1 63-PWMI 85-SCOR 107-D3 129-HD13 151-HA4 173-MTS3
+ 20-VPCO1 42-TE 64-FSW 86-SBSO 108-D2 130-HD12 152-VDD5 174-MTS2
+ 21-VPCO2 43-SE 65-MON 87-EXCK 109-D1 131-HD11 153-HA3 175-MTS1
+ 22-VCTL 44-FE 66-ATSK 88-SQCK 110-D0 132-HD10 154-HA2 176-MTS0
+ 1-SCLK 27-RFAC 53-TrckR 79-/XINT 105-A0 131-3.5V 157-(tst) 183-A8
+ 2-GNDed 28-GNDed 54-TrckF 80-SQCK 106-3.5V 132-D9 158-(tst) 184-A7
+ 3-GNDed 29-CLTV 55-FocuR 81-SQSO 107-A1 133-D8 159-GND 185-A6
+ 4-SBSO 30-PCO 56-3.5V 82-SENSE 108-A2 134-D7 160-D15 186-A5
+ 5-WFCK 31-FILI 57-FocuF 83-GND 109-A3 135-D6 161-D0 187-GND
+ 6-GNDed 32-FILO 58-SledR 84-GND 110-A4 136-D5 162-D14 188-A4
+ 7-C16M 33-VCTL 59-SledF 85-CD.D7 111-A5 137-3.5V 163-D1 189-A3
+ 8-3.5V 34-VPC02 60-NC 86-CD.D6 112-3.5V 138-D4 164-D13 190-A2
+ 9-C4M 35-VPC01 61-GND 87-CD.D5 113-A6 139-D3 165-3.5V 191-A1
+ 10-GNDed 36-VC 62-NC 88-CD.D4 114-A7 140-D2 166-D2 192-A0
+ 11-4.3MHz 37-FE 63-GND 89-CD.D3 115-A8 141-D1 167-D12 193-3.5V
+ 12-12MHz 38-SE 64-(tst) 90-CD.D2 116-A9 142-D0 168-D3 194-NC
+ 13-V16M 39-TE 65-(tst) 91-CD.D1 117-/IRQ2 143-GND 169-D11 195-(tst)
+ 14-DOUT 40-CE 66-note 92-CD.D0 118-/IRQ9 144-33MHzS 170-D10 196-GND
+ 15-LACK 41-CEO 67-note 93-3.5V 119-/RD 145- 171-D4 197-(tst)
+ 16-WDCK 42-CEI 68-(tst) 94-CD/CS 120-/WR 146-3.48V 172-D9 198-NC
+ 17-3.5Ved 43-RFDC 69-3.5V 95-CD/WR 121-DMA4 147-ZZ11 173-GND 199-NC
+ 18-LOCK 44-ADIO 70-(tst) 96-CD/RD 122-GND 148-GND 174-D5 200-NC
+ 19-GND 45-GND 71-(tst) 97-CD.A0 123-GND 149-GND 175-D8 201-3.5V
+ 20-MDS 46-IGEN 72-(tst) 98-CD.A1 124-/SPUW 150-ZZ7 176-D6 202-NC
+ 21-MDP 47-AVD1 73-(tst) 99-CD.A2 125-D15 151-3.48V 177-D7 203-NC
+ 22-3.5Ved 48-GNDed 74-DATA 100-GND 126-D14 152-/RES 178-/CAS 204-NC
+ 23-AVDO 49-GNDed 75-XLAT 101-CDA3 127-D13 153-3.5V 179-/WE 205-GND
+ 24-ASYO 50-GND 76-CLOK 102-CDA4 128-D12 154-ZZ5 180-3.5V 206-(tst)
+ 25-ASYI 51-GNDed 77-SCOR 103-/CD 129-D11 155-(tst) 181-/OE 207-(tst)
+ 26-BIAS 52-GNDed 78-GND 104-/SPU 130-D10 156-(tst) 182-/RAS 208-GND
+Pin 74,75,76,119,120 are connected via 22 ohm.
+Pin 103,104 are connected via 100 ohm.
+ZZnn = IC405 Pin nn (analog audio related, L/R/MUTE).
+Pin 103..142 = System Bus (BIOS,CPU). Pin 160..192 = Sound RAM Bus.
+Pin 178 used for both /CASL and /CASH (which are shortcut with each other).
+Pin 146 and 151 are 3.48V (another supply, not 3.5V).
+Pin 147 and 150 are connected via capacitors.
+Pin 195 and 197 testpoints are found below of the pin 206/207 testpoints.
+
SPU155 (tst) always low ;=maybe external audio (serial) this?
+ SPU156 (tst) 45kHz (22us) ;=probably 44.1kHz (ext audio sample-rate)
+ SPU157 (tst) 2777kHz (0.36us) ;=probably 64*44.1kHz (ext audio bit-rate)
+ SPU158 (tst) always high ;=maybe external audio (serial) or this?
+ SPU197 (*) 7.35kHz (44.1kHz/6) (stable clock, maybe DESIRED drive speed)
+ SPU5 (*) 7.35kHz (44.1kHz/6) (unstable clock, maybe ACTUAL drive speed)
+ SPU15 (*) 44.1kHz (44.1kHz*1)
+ SPU16 (*) 88.2kHz (44.1kHz*2)
+ SPU206 (*) circa 2.27MHz
+ SPU70 (*) whatever clock (with SHORT low pulses)
+ SPU207 fastsignal?
+ SPU195 slowsignal?
+ SPU18 usually high, low during seek or spinup or so
+ SPU44 superslow hi/lo with superfast noise on it
+ SPU73 mainly LOW with occasional HIGH levels...
+ SPU71 LOW=SPIN_OK, PULSE=SPIN_UP/DOWN_OR_STOPPED
+ SPU72 similar as SPU71
+ SPU64 LOW=STOP, HI=SPIN
+ SPU68 always low...?
+ SPU65 whatever?
+ SPU75 mainly HIGH, short LOW pulses when changing speed up/down/break
+ | | SPU73
+ | CXD2938Q (SPU) | SPU72
+ | (on PM-41 board) | SPU70 SPU71
+ | | SPU64 SPU65 SPU68
+ SPU206 SPU207 |_______________________________________|
+ SPU197
+ SPU195 SPU16 SPU44
+ SPU18 SPU5 SPU15
+ SPU12
+ 1-TST? 4-/PD 7-CKS 10-LRCK 13-NC? 16-AOUTL 19-GNDa 22-VREFH
+ 2-VCCd 5-/RST 8-BICK 11-NC? 14-NC? 17-VCOM 20-NC? 23-VREFL
+ 3-GNDd 6-MCLK 9-SDATA 12-NC? 15-AOUTR 18-VCCa 21-NC? 24-DZF?
+Called "NJM2174" in service manual. Audio Amplifier with Mute.
+
1 GND
+ 2 NC ? via 100ohm to multiout pin 9 ;Audio Left (white cinch)
+ 3 OUT-R ?
+ 4 MUTE1 ;specified as LOW = Mute
+ 5 MUTE2 ;specified as HIGH = Mute
+ 6 MUTEC ;unspecified, maybe capacitor, or output based on MUTE1+MUTE2?
+ 7 IN-R via capacitor to SPU.150
+ 8 BIAS
+ 9 NC
+ 10 NC
+ 11 IN-L via capacitor to SPU.147
+ 12 OUT-L ?
+ 13 NC ? via 100ohm to multiout pin 11 ;Audio Right (red cinch)
+ 14 VCC +5.0V (via L401)
+ 1-ROUT
+ 2-RIN- IC732.SPU.150
+ 3-RIN+
+ 4-GND
+ 5-LIN+
+ 6-LIN- IC732.SPU.147
+ 7-LOUT
+ 8-VCC 4.9V (+5.0V via L401)
+ 1-D0 14-/XINT 27-/HRD 40-GND 53-VDD 66-/MWR 79-GND 92-LRCO
+ 2-D1 15-GND 28-VDD 41-HDRQ 54-GND 67-MDB0 80-CLK 93-WCKO
+ 3-VDD 16-A0 29-GND 42-/HAC 55-MA8 68-MDB1 81-HCLK 94-BCKO
+ 4-GND 17-A1 30-/HWR 43-MA0 56-MA9 69-MDB2 82-CKSL 95-MUTE
+ 5-D2 18-A2 31-HD0 44-MA1 57-MA10 70-MDB3 83-RMCK 96-TD7
+ 6-D3 19-A3 32-HD1 45-MA2 58-MA11 71-MDB4 84-LRCK 97-TD6
+ 7-D4 20-A4 33-HD2 46-T01 59-MA12 72-MDB5 85-DATA 98-TD5
+ 8-D5 21-TD0 34-HD3 47-T02 60-MA13 73-MDB6 86-BCLK 99-TD4
+ 9-D6 22-/HRS 35-HD4 48-MA3 61-MA14 74-MDB7 87-C2PO 100-TD3
+ 10-D7 23-/HCS 36-HD5 49-MA4 62-MA15 75-MDBP 88-EMP
+ 11-/CS 24-HA0 37-HD6 50-MA5 63-MA16 76-XTL2 89-/RST
+ 12-/RD 25-HA1 38-HD7 51-MA6 64-/MOE 77-XTL1 90-GND
+ 13-/WR 26-HINT 39-HDP 52-MA7 65-GND 78-VDD 91-DATO
+ 1-FEO 7-FE_M 13-RA_O 19-CLK 25-FOK 31-RF_O 37-FE_BIAS 43-LPFI
+ 2-FEI 8-SRCH 14-SL_P 20-XLT 26-CC2 32-RF_M 38-F 44-TEI
+ 3-FDFCT 9-TGU 15-SL_M 21-DATA 27-CC1 33-LD 39-E 45-ATSC
+ 4-FGD 10-TG2 16-SL_O 22-XRST 28-CB 34-PD 40-EI 46-TZC
+ 5-FLB 11-FSET 17-ISET 23-C.OUT 29-CP 35-PD1 41-GND 47-TDFCT
+ 6-FE_O 12-TA_M 18-VCC 24-SENS 30-RF_I 36-PD2 42-TEO 48-VC
+ 1-FOK 11-PDO 21-GNDa 31-WDCK 41-DA09-XPLCK 51-APTL 61-EMPH 71-DATA
+ 2-FSW 12-GND 22-VLTV 32-LRCK 42-DA08-GFS 52-GND 62-WFCK 72-XLAT
+ 3-MON 13-TEST0 23-VDDa 33-VDD 5V 43-DA07-RFCK 53-XTAI 63-SCOR 73-VDD
+ 4-MDP 14-NC 24-RF 34-DA16-SDTA48 44-DA06-C2PO 54-XTAO 64-SBSO 74-CLOK
+ 5-MDS 15-NC 25-BIAS 35-DA15-SCLK48 45-DA05-XRAOF 55-XTSL 65-EXCK 75-SEIN
+ 6-LOCK 16-VPCO 26-ASYI 36-DA14-SDTA64 46-DA04-MNT3 56-FSTT 66-SQSO 76-CNIN
+ 7-NC 17-VCKI 27-ASYO 37-DA13-SCLK64 47-DA03-MNT2 57-FSOF 67-SQCK 77-DATO
+ 8-VCOO 18-FILO 28-ASYE 38-DA12-LRCK64 48-DA02-MNT1 58-C16M 68-MUTE 78-XLTO
+ 9-VCOI 19-FILI 29-NC 39-DA11-GTOP 49-DA01-MNT0 59-MD2 69-SENS 79-CLKO
+ 10-TEST 20-PCO 30-PSSL 40-DA10-XUGF 50-APTR 60-DOUT 70-XRST 80-MIRR
+ 1-SRON 14-TEST 27-TE 40-VDDa 53-DA09-XPLCK 66-FSTI 79-MUTE 92-DFCT
+ 2-SRDR 15-GND 28-SE 41-VDD 54-DA08-GFS 67-FSTO 80-SENS 93-FOK
+ 3-SFON 16-TES2 29-FE 42-ASYE 55-DA07-RFCK 68-FSOF 81-XRST 94-FSW
+ 4-TFDR 17-TES3 30-VC 43-PSSL 56-DA06-C2PO 69-C16M 82-DIRC 95-MON
+ 5-TRON 18-PDO 31-FILO 44-WDCK 57-DA05-XRAOF 70-MD2 83-SCLK 96-MDP
+ 6-TRDR 19-VPCO 32-FILI 45-LRCK 58-DA04-MNT3 71-DOUT 84-DFSW 97-MDS
+ 7-TFON 20-VCKI 33-PCO 46-DA16-SDTA48 59-DA03-MNT2 72-EMPH 85-ATSK 98-LOCK
+ 8-FFDR 21-VDDa 34-CLTV 47-DA15-SCLK48 60-DA02-MNT1 73-WFCK 86-DATA 99-SSTP
+ 9-FRON 22-IGEN 35-GNDa 48-DA14-SDTA64 61-DA01-MNT0 74-SCOR 87-XLAT 100-SFDR
+ 10-FRDR 23-GNDa 36-RFAC 49-DA13-SCLK64 62-XTAI 75-SBSO 88-CLOK
+ 11-FFON 24-ADIO 37-BIAS 50-DA12-LRCK64 63-XTAO 76-EXCK 89-COUT
+ 12-VCOO 25-RFC 38-ASYI 51-DA11-GTOP 64-XTSL/GNDed 77-SQSO 90-VDD
+ 13-VCOI 26-RFDC 39-ASYO 52-DA10-XUGF 65-GND 78-SQCK 91-MIRR
+Pinouts are same as CXD2545Q, except, three pins are different: Pin24=ADII
+(instead of ADIO), Pin25=ADIO (instead of RFC), Pin68=C4M (instead of FSOF).
1..48 - unknown
+ 49 - SCOR
+ 50..144 - unknown
+ 1-8 Unknown (maybe CDROM related, at least it's near other CDROM chips)
+Drive Motor related.
+
1 to pin24,27
+ 2 SPINDLE - via 15K to SPU21
+ 3 SW (ON/OFF) - IC304.27
+ 4 TRACKING FORWARD
+ 5 TRACKING REVERSE
+ 6 FOCUS FORWARD
+ 7 FOCUS REVERSE
+ 8 GND - CN702 pin 11
+ 9 NC (INTERNAL) - via C731 (10uF) to GND
+ 10 +7.5V (Pow VCC ch1,2)
+ 11 FOCUS COIL (1) - CN702 pin 15
+ 12 FOCUS COIL (2) - CN702 pin 14
+ 13 TRACKING COIL (1) - CN702 pin 16
+ 14 TRACKING COIL (2) - CN702 pin 13
+ 15 SPINDLE MOTOR (1) - CN701 pin 4
+ 16 SPINDLE MOTOR (2) - CN701 pin 3
+ 17 SLED MOTOR (1) - CN701 pin 1
+ 18 SLED MOTOR (2) - CN701 pin 2
+ 19 +7.5V (Pow VCC ch3,4)
+ 20 MUTE - /RES (via 5K6)
+ 21 GND
+ 22 SLED REVERSE
+ 23 SLED FORWARD
+ 24 to pin1
+ 25 via capacitors to pin1
+ 26 BIAS 1.75V
+ 27 to pin1
+ 28 +7.5V (Pre VCC)
+ 1 LD O APC amplifier output
+ 2 PD I APC amplifier input
+ 3 PD1 I Input 1 for RF I-V amplifiers
+ 4 PD2 I Input 2 for RF I-V amplifiers
+ 5 GND/VEE - Supply Ground
+ 6 F I Input F for I-V amplifier
+ 7 E I Input E for I-V amplifier
+ 8 VR O DC Voltage Output (VCC+VEE)/2
+ 9 VC I Center Voltage Input
+ 10 NC - NC
+ 11 NC - NC
+ 12 EO O Monitoring Output for I-V amplifier E
+ 13 EI - Gain Adjust for I-V amplifier E
+ 14 TE O Tracking Error Amplifier Output
+ 15 FE_BIAS I BIAS Adjustment for Focus Error
+ 16 FE O Focus Error Amplifier Output
+ 17 RFO O RF Amplifier Output
+ 18 RFI I RF Amplifier Input
+ 19 /LD_ON I APC amplifier ON=GND, OFF=VCC
+ 20 VCC - Supply
+ 1-TEIM
+ 2-TEIG
+ 3-VEE GND
+ 4-E via 33K to CN702 pin 4
+ 5-F via 33K to CN702 pin 8
+ 6-PD2 via 36K to CN702 pin 6
+ 7-PD1 via 36K to CN702 pin 7
+ 8-PD to CN702 pin 9
+ 9-LD
+ 10-VC CL710, and CN702.Pin3, and via resistor?/diode? to SPU42
+ 11-LD_ON IC304.Pin49 "LDON" ..... XXX or is that Pin 20 "LD_ON" ?
+ 12-G_CONT ;or AL/TE?
+ 13-RF0 CL704, and...
+ 14-RFM
+ 15-FE CL708, and... (maybe focus error?)
+ 16-TE CL709, and via 15K to SPU.39 (maybe tracking error?)
+ 17-TE0
+ 18-COMP+
+ 19-MIRR via 4K7 to SPU66
+ 20-VCC 3.48V (not 3.5V)
+ 1-LD to Q701
+ 2-VCC to Q701
+ 3-VC to IC723.Pin10 (and CL710)
+ 4-F- to IC723.Pin4 (via 33K ohm)
+ 5-NC to CL776
+ 6-PD2 to IC723.Pin6 (via 33K ohm)
+ 7-PD1 to IC723.Pin7 (via 33K ohm)
+ 8-E- to IC723.Pin5 (via 33K ohm)
+ 9-M1 to IC723.Pin8
+ 10-VR via 91 ohm to GND
+ 11-GND GND
+ 12-LS /POS0 (switch, GNDed when at head is at inner-most position)
+ 13-FCS+ TRACKING COIL (2) ;\
+ 14-TRK+ FOCUS COIL (2) ; or swapped?
+ 15-TRK FOCUS COIL (1) ;
+ 16-FCS TRACKING COIL (1) ;/
+ 1-SL- SLED MOTOR (1)
+ 2-SL+ SLED MOTOR (2)
+ 3-SP+ SPINDLE MOTOR (2)
+ 4-SP- SPINDLE MOTOR (1)
+ CL616 +7.5V (PM-41 only, not PM-23) (before power switch)
+ CL617 GND (PM-41 only, not PM-23)
+ CL316 to IC304 pin 21
+ CL704 to IC723.Pin13
+ CL706 GND
+ CL708 to IC723.Pin15
+ CL709 to IC723.Pin16
+ CL710 to IC723.Pin10, and CN702.Pin3
+ CL711 via 1K to IC723.Pin15
+ CL776 to CN702.Pin5
+SCPH-5903 Video CD PlayStation
The overall design is very close to LATE-PU-8 boards (1-658-467-2x). Changed
+components are IC102/IC304 (different kernel and cdrom firmware),
+C318/C325/C327 (height reduced capacitors for mounting the daughterboard above
+of them). Plus some extra components: Three triple multiplexors (for switching
+between PSX and VCD audio/video), and the daughterboard connector.
+
IC102 44pin SONY, M538032E-02, JAPAN 6465401 (uncommonly big BIOS, 1Mx8)
+ IC304 52pin C 4021 SC430924PB (HC05 sub-cpu, with extra Video CD command 1Fh)
+ C318 2pin S5 ;\tantalum capacitors with lower height (instead
+ C325 2pin CA7 ; of the electrolytic capacitors on PU-8 boards)
+ C327 2pin CA7 ;/
+ ICnnn 16pin 4053C (Triple multiplexor, for Audio LRCK,BCLK,DATA) (PCB top)
+ ICnnn 16pin 4053C (Triple multiplexor, for Video FSC,CSYNC) (PCB bottom)
+ ICnnn 16pin 2283 (Triple multiplexor, for Video R,G,B) (PCB bottom)
+ CNnnn 30pin Connector to daughterboard (PCB top)
+ IC102 3pin TA78M05F voltage regulator (7.5V to 5V) (Toshiba)
+ IC104 120pin CXD1852AQ Video CD decoder (Sony)
+ IC106 40pin MB814260-70 (256Kx16 DRAM) (Fujitsu) ;see also: IC114
+ IC107 20pin 6230FV 649 115 (OSD, similar to BU6257AFV-E2) (PCB back)
+ IC109 14pin Y2932 (TLC2932 PLL) (TI) (for RGB.DAC.CLK)
+ IC110 44pin TDA8771AH Triple Video DAC for RGB (Philips) (PCB back)
+ IC111 64pin CXP10224-603R 732A02E (MCU) (Sony)
+ IC112 14pin HCT32A (74HCT32 Quad OR gate) (TI) (PCB back) (for RGB.DAC.CLK)
+ IC113 8pin H74 7H (single D-type flip-flop; OSD clock divider) (PCB back)
+ IC114 40pin MB814260-70 (256Kx16 DRAM) (Fujitsu) ;see also: IC106
+ CN101 30pin Male Connector (to female 30pin socket on PU-16 mainboard)
+ X103 2pin 45.00MHz (for VCD decoder chip)
+ X104 4pin 12.000MHz (for MCU chip)
+ X105 2pin 28.636MHz (for VCD decoder chip) (8*3.579545 NTSC clock)
+ .--.---.
+ GND / 1 2 | GND
+ (CXD1815Q.86) CD.BCLK | 3 4 | CD.LRCK (CXD1815Q.84)
+ (CXD1815Q.87) CD.C2PO | 5 6 | CD.DATA (CXD1815Q.85)
+ GND | 7 8 | CD.SQCK (CXD2510Q.67) CXP.31
+ (TDA.44) VIDEO.OUTR | 9 10 | CD.SQSO (CXD2510Q.66) CXP.29
+ GND | 11 12 | SIO.OUT (HC05.51.PORTF1 to CXP.47)
+ (TDA.40) VIDEO.OUTG | 13 14 | SIO.IN (HC05.50.PORTF0 from CXP.48)
+ GND | 15 16 | SIO.CLK (HC05.52.PORTF2 to CXP.49)
+ (TDA.36) VIDEO.OUTB | 17 18 | VIDEO.FSC (CXD1852AQ.95)
+ GND | 19 20 | VIDEO.CSYNC(CXD1852AQ.96)
+ (PSU.3) 3.5V | 21 22 | 3.5V (PSU.3)
+ (PSU.1) 7.5V | 23 24 | AUDIO.FSXI (CXD1852AQ.103 to VCD)
+ (PSU.7) /RES | 25 26 | AUDIO.DATA (CXD1852AQ.100)
+ (CXD1852AQ.102) AUDIO.BCLK | 27 28 | AUDIO.LRCK (CXD1852AQ.101)
+ GND | 29 30 | GND
+ '--------'
+ 1-GND 16-HD7 31-GND 46-MD4 61-GND 76-G/Y3 91-GND 106-XTL2O
+ 2-XTL0O 17-MA3 32-MA7 47-MD11 62-/VOE 77-G/Y4 92-HSYNC 107-XTL2I
+ 3-XTL0I 18-MA4 33-MA8 48-MD3 63-R/Cr0 78-G/Y5 93-VSYNC 108-VDD
+ 4-VDD 19-MA2 34-/RAS 49-MD12 64-R/Cr1 79-G/Y6 94-FID/FHREF 109-C2PO
+ 5-HA2 20-MA5 35-/MWE 50-MD2 65-R/Cr2 80-G/Y7 95-CBLNK/FSC 110-LRCI
+ 6-HA3 21-MA1 36-/CAS2 51-MD13 66-R/Cr3 81-B/Cb0 96-CSYNC 111-DATI
+ 7-HD0 22-GND 37-/CAS0 52-MD1 67-R/Cr4 82-B/Cb1 97-/SGRST 112-BCKI
+ 8-HD1 23-MA6 38-MD7 53-MD14 68-R/Cr5 83-B/Cb2 98-CLK0O 113-DOIN
+ 9-HD2 24-MA0 39-MD8 54-MD0 69-R/Cr6 84-B/Cb3 99-DOUT 114-/HCS
+ 10-HD3 25-BC 40-MD6 55-MD15 70-R/Cr7 85-B/Cb4 100-DATO 115-/HDT
+ 11-HD4 26-TCKI 41-MD9 56-OSDEN 71-G/Y0 86-B/Cb5 101-LRCO 116-HRW
+ 12-HD5 27-TDI 42-MD5 57-OSDB 72-G/Y1 87-B/Cb6 102-BCKO 117-/HIRQ
+ 13-HD6 28-TENA1 43-MD10 58-OSDG 73-G/Y2 88-B/Cb7 103-FSXI 118-/RST
+ 14-VDD 29-TDO 44-VDD 59-OSDR 74-VDD 89-DCLK 104-VDD 119-HA0
+ 15-GND 30-VST 45-GND 60-VDD 75-GND 90-VDD 105-GND 120-HA1
+ 1-SIO.CLK 5-VDD 9-TEST 13-BLK2 17-OSDG
+ 2-SIO./CS 6-/CKOUT 10-GND 14-VC2 18-OSDB
+ 3-SIO.DTA 7-OSCOUT 11-BLK1 15-OSDEN 19-/VSYNC
+ 4-/RESET 8-OSCIN 12-VC1 16-OSDR 20-/HSYNC
+ 1-PB5=TP 17-PD5=/HCS 33-AVREF=VDD 49-PG5/SCK1=HC05.PF2
+ 2-PB4=TP 18-PD4=TP 34-AVDD=VDD 50-PG4=/RST.OUT
+ 3-PB3=HA3 19-PD3=TP 35-PF7/AN7=TP 51-PG3/TO=TP
+ 4-PB2=HA2 20-PD2=TP 36-PF6/AN6=OSD.DTA 52-PA7=TP
+ 5-PB1=HA1 21-PD1=TP 37-PF5/AN5=OSD./CS 53-PA6=TP
+ 6-PB0=HA0 22-PD0=TP 38-PF4/AN4=OSD.CLK 54-PA5=TP
+ 7-PC7=HD7 23-MP/TEST=GND 39-PF3/AN3=GND 55-PA4=TP
+ 8-PC6=HD6 24-XTAL=12MHZ 40-PF2/AN2=GND 56-VPP=VDD
+ 9-PC5=HD5 25-EXTAL=12MHZ 41-PF1/AN1=GND 57-VDD=VDD
+ 10-PC4=HD4 26-VSS=GND 42-PF0/AN0=10KtoGND 58-VSS=GND
+ 11-PC3=HD3 27-/RST=/RES 43-PE3/PWM1=TP 59-PA3=TP
+ 12-PC2=HD2 28-/CS0=VDD 44-PE2/PWM0=TP 60-PA2=TP
+ 13-PC1=HD1 29-SI0=CD.SQSO 45-PE1/INT2/EC=/VSYNC 61-PA1=TP
+ 14-PC0=HD0 30-SO0=TP 46-PE0/INT0=/HIRQ 62-PA0=TP
+ 15-PD7=HRW 31-/SCK0=CD.SQCK 47-PG7/SI1/INT1=HC05.PF1 63-PB7=TP
+ 16-PD6=/HDT 32-AVSS=GND 48-PG6/SO1=HC05.PF0 64-PB6=TP
+ 1-LOGIC_VDD=5V 5-FIN-B=HSYNC.PLL 9-PFD_INHIBIT=GND 13-BIAS
+ 2-SELECT=5V 6-PFD_OUT 10-VCO_INHIBIT=GND 14-VCO_VDD=5V
+ 3-VCO_OUT=RGB.DAC.CLK.PLL 7-LOGIC_GND=GND 11-VCO_GND=GND
+ 4-FIN-A=FID/FHREF.PLL 8-NC 12-VCO_IN
+ 1-FID/FHREF.MPEG 4-HSYNC.MPEG 8-(low) 11-RGB.DAC.CLK.TDA 7-GND
+ 2-FID/FHREF.MPEG 5-HSYNC.MPEG 9-GNDed 12-RGB.DAC.CLK.PLL 14-VCC/5V
+ 3-FID/FHREF.PLL 6-HSYNC.PLL 10-GNDed 13-RGB.DAC.CLK.PLL
+ 1-CLK 2-D 3-/Q 4-GND 5-Q 6-/RES 7-/SET 8-VCC
+ 1-IN2B=DATA.VCD 5-IN3A=LRCK.SPU 9-SEL3=LRCK.SEL 13-IN1B=BCLK.VCD
+ 2-IN2A=DATA.SPU 6-/OE=GNDed 10-SEL2=DATA.SEL 14-OUT1=BCLK.OUT
+ 3-IN3B=LRCK.VCD 7-VEE=GNDed 11-SEL1=BCLK.SEL 15-OUT2=DATA.OUT
+ 4-OUT3=LRCK.OUT 8-GND=GND 12-IN1A=BCLK.SPU 16-VDD=VDD/3.5V
+ 1-IN2B=FSC.VCD 5-IN3A=CSYNC.PSX 9-SEL3=CSYNC.SEL 13-IN1B=GNDed
+ 2-IN2A=FSC.PSX 6-/OE=GNDed 10-SEL2=FSC.SEL 14-OUT1=NCed
+ 3-IN3B=CSYNC.VCD 7-VEE=GNDed 11-SEL1=DUMMY.SEL 15-OUT2=FSC.OUT
+ 4-OUT3=CSYNC.OUT 8-GND=GND 12-IN1A=GNDed 16-VDD=VCC/5V
+ 1-IN1B=R.VCD 5-OUT2=G.OUT 9-IN3B=B.VCD 13-V=VCC/5V
+ 2-SEL1=R.SEL 6-OUT3=B.OUT 10-GND3=81ohm/GND 14-IN2B=G.VCD
+ 3-OUT1=R.OUT 7-SEL3=B.SEL 11-IN2A=G.PSX 15-GND1=GND
+ 4-GND2=GND 8-IN3A=B.PSX 12-SEL2=G.SEL 16-IN1A=R.PSX
+ 80pin "4246xx" - MC68HC05L16, on-chip ROM (DTL-H120x & old retail consoles)
+ 80pin "MC68HC705L16CFU" - MC68HC705L16, on-chip ROM (DTL-H100x, and PU-9)
+ 52pin "SC4309xx" - MC68HC05G6, on-chip ROM (newer retail consoles)
+Called "MC68HC05G6PB" in service manual (=8bit CPU).
+
1 NC NC (TEST:DTR/out) (VCD:AVSEL/out) ;-Port F ;PortF.Bit3
+ 2 VDD 3.5V
+ 3 NC NC ;\ ;maybe PortE.Bit7?
+ 4 NC NC ; maybe MSBs of Port E ;maybe PortE.Bit6?
+ 5 NC NC ;/ ;maybe PortE.Bit5?
+ 6 DECA4 SPU102 ;\ ;PortE.Bit4
+ 7 DECA3 SPU101 ; Port E [04h], aka Address/Index ;PortE.Bit3
+ 8 DECA2 SPU99 ; ;PortE.Bit2
+ 9 DECA1 SPU98 ; ;PortE.Bit1
+ 10 DECA0 SPU97 ;/ ;PortE.Bit0
+ 11 VSS GND
+ 12 NDLY GND reserved for factory test, should be wired to VDD, not GND?
+ 13 /RES /RES (via 5K6)
+ 14 OSC1 4.3MHz (SPU11)(used as external clock for some modchips)(low volts)
+ 15 OSC2 NC
+ 16 F-BIAS aka FOK=NC (in SCPH-5500) ;PortB.Bit0
+ 17 CG NC aka CG=CG (in SCPH-5500) ;this IS portb.1! ;PortB.Bit1
+ 18 LMTSW /POS0 (switch, GNDed when head at inner-most position) ;PortB.Bit2
+ 19 DOOR SHELL_OPEN ;PortB.Bit3
+ 20 TEST2 NC ;PortB.Bit4
+ 21 TEST1 to CL316 ;PortB.Bit5
+ 22 COUT NC ;PortB.Bit6
+ 23 SENSE SPU82 ;CXD2510Q.69 ;PortB.Bit7
+ 24 SUBQ SPU81 ;CXD2510Q.66 ;PortC.Bit0
+ 25 NC NC ;NC ;PortC.Bit1
+ 26 SQCK SPU80 ;CXD2510Q.67 ;PortC.Bit2
+ 27 SPEED IC722.Pin3 (SW) ;PortC.Bit3
+ 28 AL/TE ;transisor aka MIRROR=.. (in SCPH-5500);ISN'T PortB.Bit1 !
+ 29 ROMSEL ;NC aka ROMSEL=SCLK (in SCPH-5500) ;PortC.Bit5
+ 30 /XINT SPU79 ;CXD1815Q.14 ;PortC.Bit6
+ 31 SCOR SPU77 ;CXD2510Q.63 ;PortC.Bit7
+ 32 VDD 3.5V
+ 33 DECD0 CD.D0 ;\ ;PortA.Bit0
+ 34 DECD1 CD.D1 ; ;PortA.Bit1
+ 35 DECD2 CD.D2 ; ;PortA.Bit2
+ 36 DECD3 CD.D3 ; Port A [00h], aka Data ;PortA.Bit3
+ 37 DECD4 CD.D4 ; ;PortA.Bit4
+ 38 DECD5 CD.D5 ; ;PortA.Bit5
+ 39 VSS GND ;
+ 40 DECD6 CD.D6 ; ;PortA.Bit6
+ 41 DECD7 CD.D7 ;/ ;PortA.Bit7
+ 42 NC NC ;maybe PortD.Bit0?
+ 43 DATA SPU74 (via 22 ohm) ;PortD.Bit1
+ 44 XLAT SPU75 (via 22 ohm) ;PortD.Bit2
+ 45 CLOK SPU76 (via 22 ohm) ;PortD.Bit3
+ 46 DECCS SPU94 ;PortD.Bit4
+ 47 DECWR SPU95 ;PortD.Bit5
+ 48 DECRD SPU96 ;PortD.Bit6
+ 49 LDON IC723.Pin11 ;PortD.Bit7
+ 50 NC NC (TEST:TX/out) (VCD:SIO.IN/in) ;\PortF (used by ;PortF.Bit0
+ 51 NC NC (TEST:RX/in) (VCD:SIO.OUT/out) ; Motorola Testmode;PortF.Bit1
+ 52 NC NC (TEST:RTS/out) (VCD:SIO.CLK/out) ;/and VCD version) ;PortF.Bit2
+ PU-8 4.0000MHz from separate 4.000MHz oscillator (X302)
+ PU-16 4.0000MHz from separate 4.000MHz oscillator (X302)
+ DTL-H2000 4.1900MHz from separate 4.1900MHz oscillator (SPC700, not HC05)
+ PU-18 4.2336MHz from CXD2545Q.pin68 (Servo+Signal) (FSOF=16.9344MHz/4)
+ PU-20 4.2xxxMHz from CXD1817R.pin? (Servo+Signal+Decoder)
+ PM-41 4.2xxxMHz from CXD2938Q.pin11 (Servo+Signal+Decoder+SPU)
+ 1 VDD
+ 2 FP28/PE6 ;\
+ 3 FP29/PE5 ;
+ 4 FP30/PE4 ;
+ 5 FP31/PE3 ; Port E LSBs
+ 6 FP32/PE2 ;
+ 7 FP33/PE1 ;
+ 8 FP34/PE0 ;/
+ 9 FP35/PD7 ;\
+ 10 FP36/PD6 ; Port D MSBs
+ 11 FP37/PD5 ;
+ 12 FP38/PD4 ;/
+ 13 VLCD3
+ 14 VLCD2
+ 15 VLCD1
+ 16 VSS
+ 17 NDLY
+ 18 XOSC1
+ 19 XOSC2
+ 20 /RESET
+ ---
+ 21 OSC1
+ 22 OSC2
+ 23 PA0 ;\
+ 24 PA1 ;
+ 25 PA2 ;
+ 26 PA3 ; Port A
+ 27 PA4 ;
+ 28 PA5 ;
+ 29 PA6 ;
+ 30 PA7 ;/
+ 31 PB0/KWI0 ;\
+ 32 PB1/KWI1 ;
+ 33 PB2/KWI2 ;
+ 34 PB3/KWI3 ; Port B
+ 35 PB4/KWI4 ;
+ 36 PB5/KWI5 ;
+ 37 PB6/KWI6 ;
+ 38 PB7/KWI7 ;/
+ 39 PC0/SDI ;\
+ 40 PC1/SDO ;
+ --- ;
+ 41 PC2/SCK ; Port C
+ 42 PC3/TCAP ;
+ 43 PC4/EVI ;
+ 44 PC5/EVO ;
+ 45 PC6/IRQ2 ;
+ 46 PC7/IRQ1 ;/
+ 47 VDD
+ 48 BP3/PD3 ;\
+ 49 BP2/PD2 ; Port D LSBs
+ 50 BP1/PD1 ;
+ 51 BP0 (no "PD0") ;/
+ 52 FP0
+ 53 FP1
+ 54 FP2
+ 55 FP3
+ 56 FP4
+ 57 FP5
+ 58 FP6
+ 59 FP7
+ 60 VSS
+ ---
+ 61 FP8
+ 62 FP9
+ 63 FP10
+ 64 FP11
+ 65 FP12
+ 66 FP13
+ 67 FP14
+ 68 FP15
+ 69 FP16
+ 70 FP17
+ 71 FP18
+ 72 FP19
+ 73 FP20
+ 74 FP21
+ 75 FP22
+ 76 FP23
+ 77 FP24
+ 78 FP25
+ 79 FP26
+ 80 FP27/PE7 ;- Port E MSB
+Sony's Digital Joypad and Mouse contain 32pin CPUs, which are probably also
+HC05's:
+Pinouts - Component List and Chipset Pin-Outs for Digital Joypad, SCPH-1080
+Moreover, some old memory cards contain a 64pin Motorola SC419510FU (probably
+also a HC05) with separate Atmel AT29LV010A (128Kx8 FLASH).
1-A19 5-A7 9-A3 13-D0 17-D3 21-D7 25-A11 29-A14
+ 2-A16 6-A6 10-A2 14-D1 18-D4 22-/CE 26-A9 30-A17 ;/CE=/BIOS
+ 3-A15 7-A5 11-A1 15-D2 19-D5 23-A10 27-A8 31-A18
+ 4-A12 8-A4 12-A0 16-GND 20-D6 24-/OE 28-A13 32-3.5V ;/OE=/RD
+ 1-A18 6-A4 11-GND 16-D9 21-VCC 26-D6 31-GND(/BYTE) 36-A13
+ 2-A8 7-A3 12-/OE 17-D2 22-D4 27-D14 32-A17 37-A12
+ 3-A7 8-A2 13-D0 18-D10 23-D12 28-D7 33-A16 38-A11
+ 4-A6 9-A1 14-D8 19-D3 24-D5 29-A0(D15) 34-A15 39-A10
+ 5-A5 10-/CS 15-D1 20-D11 25-D13 30-GND 35-A14 40-A9
+ 1-NC 5-A7 9-A3 13-GND 17-D1 21-D3 25-D12 29-D14 33-/BYT 37-A14 41-A10
+ 2-A19 6-A6 10-A2 14-/OE 18-D9 22-D11 26-D5 30-D7 34-A17 38-A13 42-A9
+ 3-A18 7-A5 11-A1 15-D0 19-D2 23-VCC 27-D13 31-D15/A0 35-A16 39-A12 43-NC
+ 4-A8 8-A4 12-/CE 16-D8 20-D10 24-D4 28-D6 32-GND 36-A15 40-A11 44-NC
+Unknown.
+Note: The newer 70pin RAM comes up without external /REFRESH signal, but maybe
+the 28pin RAMs required refresh (the CPU has some odd delays once and when).
"Samsung K4Q153212M-JC60" (70pin, 512Kx32) (newer boards)
+"Toshiba T7X16" (70pin, 512Kx32) (newer boards, too)
+
1-VCC 11-N.C 21-DQ15 31-A3 41-N.C 51-DQ17 61-DQ24
+ 2-DQ0 12-VCC 22-N.C 32-A4 42-N.C 52-DQ18 62-DQ25
+ 3-DQ1 13-DQ8 23-N.C! 33-A5 43-/OE 53-DQ19 63-DQ26
+ 4-DQ2 14-DQ9 24-N.C 34-A6 44-/W 54-VSS 64-DQ27
+ 5-DQ3 15-DQ10 25-N.C 35-VCC 45-/CAS3 55-DQ20 65-VSS
+ 6-VCC 16-DQ11 26-N.C 36-VSS 46-/CAS2 56-DQ21 66-DQ28
+ 7-DQ4 17-VCC 27-/RAS 37-A7 47-/CAS1 57-DQ22 67-DQ29
+ 8-DQ5 18-DQ12 28-A0 38-A8 48-/CAS0 58-DQ23 68-DQ30
+ 9-DQ6 19-DQ13 29-A1 39-A9 49-N.C 59-VSS 69-DQ31
+ 10-DQ7 20-DQ14 30-A2 40-N.C 50-DQ16 60-N.C 70-VSS
+SEC KM48V514BJ-6 (DRAM 512Kx8) (four pieces = 512Kx32 = 2Mbyte)
+
1-VCC 5-DQ3 9-A9 13-A3 17-A5 21-NC 25-DQ5
+ 2-DQ0 6-NC 10-A0 14-VCC 18-A6 22-/OE 26-DQ6
+ 3-DQ1 7-/W 11-A1 15-GND 19-A7 23-/CAS 27-DQ7
+ 4-DQ2 8-/RAS 12-A2 16-A4 20-A8 24-DQ4 28-GND
+EliteMT M11B416256A-35J (256K x 16bit) (40pin SOJ, PM-41 boards)
+Nippon Steel NN514256ALTT-50 (256K x 16bit) (40pin TSOP-II, PU-23 boards)
+Toshiba TC51V4260DJ-70 (40pin, PU-8 board) (PseudoSRAM)
+
1-5.0V 6-5.0V 11-NC 16-A0 21-VSS 26-A8 31-I/O8 36-I/O12
+ 2-I/O0 7-I/O4 12-NC 17-A1 22-A4 27-/OE 32-I/O9 37-I/O13
+ 3-I/O1 8-I/O5 13-/WE 18-A2 23-A5 28-/CASH 33-I/O10 38-I/O14
+ 4-I/O2 9-I/O6 14-/RAS 19-A3 24-A6 29-/CASL 34-I/O11 39-I/O15
+ 5-I/O3 10-I/O7 15-NC 20-5.0V 25-A7 30-NC 35-VSS 40-VSS
+"HM62W256LFP-7T" (SRAM 32Kx8) (PCB bottom side) (PU-8)
+"SONY CXK5V8257BTM" 32Kx8 SRAM (PU-18)
+
1-A14 4-A6 7-A3 10-A0 13-D2 16-D4 19-D7 22-/OE 25-A8 28-VCC
+ 2-A12 5-A5 8-A2 11-D0 14-GND 17-D5 20-/CS 23-A11 26-A13
+ 3-A7 6-A4 9-A1 12-D1 15-D3 18-D6 21-A10 24-A9 27-/WE
+Samsung KM4132G271BQ-10 (128K x 32bit x 2 Banks, Synchronous Graphic RAM) 1MB
+Samsung K4G163222A-PC70 (256K x 32bit x 2 Banks, Synchronous Graphic RAM) 2MB
+
1-DQ3 13-DQ19 25-/WE 37-N.C 49-A6 61-DQ9 73-VDDQ 85-VSS 97-DQ0
+ 2-VDDQ 14-VDDQ 26-/CAS 38-N.C 50-A7 62-VSSQ 74-DQ24 86-N.C 98-DQ1
+ 3-DQ4 15-VDD 27-/RAS 39-N.C 51-A8 63-DQ10 75-DQ25 87-N.C 99-VSSQ
+ 4-DQ5 16-VSS 28-/CS 40-N.C 52-N.C 64-DQ11 76-VSSQ 88-N.C 100-DQ2
+ 5-VSSQ 17-DQ20 29-A9(BA) 41-N.C 53-DSF 65-VDD 77-DQ26 89-N.C
+ 6-DQ6 18-DQ21 30-NC(GND) 42-N.C 54-CKE 66-VSS 78-DQ27 90-N.C
+ 7-DQ7 19-VSSQ 31-A0 43-N.C 55-CLK 67-VDDQ 79-VDDQ 91-N.C
+ 8-VDDQ 20-DQ22 32-A1 44-N.C 56-DQM1 68-DQ12 80-DQ28 92-N.C
+ 9-DQ16 21-DQ23 33-A2 45-N.C 57-DQM3 69-DQ13 81-DQ29 93-N.C
+ 10-DQ17 22-VDDQ 34-A3 46-VSS 58-NC 70-VSSQ 82-VSSQ 94-N.C
+ 11-VSSQ 23-DQM0 35-VDD 47-A4 59-VDDQ 71-DQ14 83-DQ30 95-N.C
+ 12-DQ18 24-DQM2 36-N.C 48-A5 60-DQ8 72-DQ15 84-DQ31 96-VDD
+The "should-be" CPU clock is 33.868800 Hz (ie. the 44100Hz CDROM/Audio clock,
+multiplied by 300h). However, the different PSX/PSone boards are using
+different oscillators, multipliers and dividers, which aren't exactly reaching
+that "should-be" value. The PSone are using a single oscillator for producing
+CPU/GPU clocks, and for producing the TV/color signal:
+
For PAL, Fsc=4.43361875MHz (5^6*283.75Hz+25Hz) --> 4*Fsc=17.734MHz
+ For NTSC, Fsc=3.579545MHz (4.5*455/572 MHz) --> 4*Fsc=14.318MHz
+Clock Multiplier/Divider
+
1 53MHz ;17.734MHz*3 = 53.202 MHz (?)
+ 2 GND
+ 3 X1 17.734MHz
+ 4 X2 17.734MHz
+ 5 67MHz ;17.734MHz*3*2*7/11 = 67.711636 MHz (?)
+ 6 4.4Mhz ;17.734MHz/4 = 4.4335MHz (?) ;via 2K2 to IC502.pin15
+ 7 3.5V
+ 8 3.5V
+Unknown. Uses a 14.318MHz oscillator, so multiply/divide factors must be
+somehow different.
+
3*3*7*5/2/11 = 14.3181818
+ 3*3*7*7*100 = 44100
+ 14.3181818 * 3*7*11*64 / (5*5*5*5*5) = 67.737600
+ 14.3181818 * 2*2*13/11 ... or so?
+PU-7 and PU-8 boards are using three separate oscillators:
+
X101: 67.737MHz (div2 = CPU Clock = 33.8685MHz) (div600h = 44.1kHz audio)
+ X201: 53.20MHz (GPU Clock) (div12 = PAL color clock)
+ X302: 4.000MHz (for CDROM SUB CPU)
+PU-7 and PU-8 boards are using three separate oscillators:
+
X101: 67.737MHz (div2 = CPU Clock = 33.8685MHz) (div600h = 44.1kHz audio)
+ X201: 53.69MHz (GPU Clock) (div15 = NTSC color clock)
+ X302: 4.000MHz (for CDROM SUB CPU)
+ +7.5V Used to generate other voltages and CDROM/Joypad/MemoryCard/Expansion
+ +5.0V Used for Multiout, IC405, and IC502, and IC602
+ +3.5V Used for most ICs, and for Joypad/MemoryCard/Expansion
+ +3.48V Used for SPU and CDROM
+ GND Ground, shared for all voltages
+There are a lot of SMD elements marked FBnnn, these are NOT fuses (at least
+they don't seem to blow-up whatever you do). The actual fuses are marked PSnnn,
+found near the power switch and near the power socket.
1 +7.5V
+ 2 GND
+ 3 +5.0V (used for Multiout, IC405, and IC502)
+Called "LP29851MX-3.5" in service manual.
+
1 VIN 5.0V (in)
+ 2 GND GND
+ 3 ON/OFF 5.0V (in)
+ 4 NOISE ?
+ 5 VOUT 3.48V (out)
+ IC002 IC003 Expl.
+ 2 2 connected to Q002 (reset input?)
+ 5 5 connected via capacitor to GND
+ 6 1 reset-output (IC002=wired to /RES, IC003: via Q004 to /RES)
+ 7 - 7.5V
+ 4 3 GND
+ 1,3,8 4 NC
+ 1 1IN+
+ 2 1IN-
+ 3 FEEDBACK
+ 4 DTC
+ 5 CT
+ 6 RT
+ 7 GND
+ 8 C1
+ 9 E1
+ 10 E2
+ 11 C2
+ 12 VCC
+ 13 OUTPUT CTRL
+ 14 REF
+ 15 2IN-
+ 16 2IN+
+ x +7.5V
+ y +3.5V
+ z REG
+ 1 Brown 7.5V (actually 7.69V)
+ 2 Red GND Ground
+ 3 Orange 3.5V (actually 3.48V)
+ 4 Yellow GND Ground
+ 5 White STAND-BY (3.54V, always ON, even if power switch is off)
+ 6 Blue GND Ground
+ 7 Magenta /RES Reset input (from power-on logic and reset button)
+ 1 Brown 7.5V (actually 7.92V or so) (ie. higher than in PSone)
+ 2 Red GND Ground
+ 3 Orange 3.5V (actually 3.53V or so) (ie. quite same as PSone)
+ 4 Yellow GND Ground
+ 5 White /RES Reset input (from power-on logic and reset button)
+ 1 /IRQ10 (/IRQ10)
+ 2 /ACK (/IRQ7)
+ 3 /JOY2
+ 4 7.5V (or actually 7.92V)
+ 5 /JOY1
+ 6 DAT
+ 7 GND
+ 8 CMD
+ 9 3.5V
+ 10 CLK
+ Case: "SONY, CONTROLLER, Sony Computer Entertainment Inc. H"
+ Case: "SCPH-1080 Made in China"
+ PCB: "CMK-PIHB /\, CFS8121-200010-01"
+ U?: 32pin "(M), SC401800, FB C37B, JSJD520C" (Motorola) (TQFP-32 package)
+ U?: 14pin "BA10339F, 528 293" (Quad Comparator) (/ACK,JOYDAT,and reset or so)
+ X?: 3pin "4.00G1f" (on PCB bottom side)
+ Z1: 2pin z-diode or so (on PCB bottom side) (+1.7V VREF for BA10339F)
+ CN?: 7pin cable to controller port (plus shield; but not connected to PCB)
+ C1 2pin to GND and R5
+ C2 2pin capacitor for power supply input (between +3.5V and GND)
+ C3 2pin between BA.pin8 and (via R6) BA.pin15
+ R1 2pin 1M ohm (for X1)
+ R2 2pin 2.7K
+ R3 2pin 8xK ohm?
+ R4 2pin 100K
+ R5 2pin 22K ohm
+ R6 2pin 56K ohm
+ RN1 8pin 4x200 ohm (/JOYn,JOYCMD,JOYCLK)
+ RN2 8pin 4x22K ohm (pull-ups for button bit0..3)
+ RN3 8pin 4x22K ohm (pull-ups for button bit12..15)
+ RN4 8pin 4x22K ohm (pull-ups for button bit8..11)
+ RN5 8pin 4x22K ohm (pull-ups for button bit4..7)
+ PSX.1 -------brown---- PAD.2 JOYDAT
+ PSX.2 -------orange--- PAD.6 JOYCMD
+ PSX.3 --- NC +7.5V
+ PSX.4 -------black---- PAD.3 GND
+ PSX.5 -------red------ PAD.4 +3.5V
+ PSX.6 -------yellow--- PAD.5 /JOYn
+ PSX.7 -------blue----- PAD.7 JOYCLK
+ PSX.8 --- NC /IRQ10
+ PSX.9 -------green---- PAD.1 /ACK
+ PSX.Shield --shield--- NC (cable is shielded but isn't connected in joypad)
+ 1 Bit14 SW-X
+ 2 Bit13 SW-O
+ 3 Bit12 SW-/\
+ 4 Bit11 SW-R1 (via cable pin1, white wire)
+ 5 Bit10 SW-L1 (via cable pin1, white wire)
+ 6 Bit9 SW-R2 (via cable pin3, black wire)
+ 7 Bit8 SW-L2 (via cable pin3, black wire)
+ 8 via BA10339F.pin7 to cn.2 JOYDAT (PSX.1)
+ ---
+ 9 via RN1 (200 ohm) to cn.5 /JOYn (PSX.6)
+ 10 via RN1 (200 ohm) to cn.6 JOYCMD (PSX.2)
+ 11 via RN1 (200 ohm) to cn.7 JOYCLK (PSX.7)
+ 12 GND to cn.3 (PSX.4)
+ 13 Bit7 SW-LEFT
+ 14 Bit6 SW-DOWN
+ 15 Bit5 SW-RIGHT
+ 16 via BA10339F.pin5 to cn.1 /ACK (PSX.9)
+ ---
+ 17 Bit4 SW-UP
+ 18 Bit3 SW-START
+ 19 Bit2 (HI) (would be R3 on Analog Pads) ;\unused, but working button inputs
+ 20 Bit1 (HI) (would be L3 on Analog Pads) ;/(each fitted with a RN2 pullup)
+ 21 Bit0 SW-SELECT
+ 22
+ 23
+ 24 wired to SC401800.pin25
+ ---
+ 25 wired to SC401800.pin24
+ 26 4.00MHz'a
+ 27 4.00MHz'b
+ 28 +3.5V to cn.4 (PSX.5)
+ 29 wired to SC401800.pin32, and via 22K ohm to +3.5V, and to BA.14
+ 30
+ 31 Bit15 SW-[]
+ 32 wired to SC401800.pin29
+ 1 OUT2 CN.2 JOYDAT (PSX.1)
+ 2 OUT1 CN.1 /ACK (PSX.9)
+ 3 VCC +3.5V
+ 4 -IN1 +1.7V VREF via Z1 to GND
+ 5 +IN1 CXD.16 /ACK
+ 6 -IN2 +1.7V VREF via Z1 to GND
+ 7 +IN2 CXD.8 JOYDAT
+ ---
+ 8 -IN3 +1.7V VREF via Z1 to GND
+ 9 +IN3 C3,R3,R4
+ 10 -IN4 C1 to +3.5V
+ 11 +IN4 GND
+ 12 GND GND
+ 13 OUT4 NC ??
+ 14 OUT3 CXD.29/32
+This applies for two controller versions:
+
SCPH-1150 Analog Pad with Single Rumble Motor (japan only)
+ SCPH-1180 Analog Pad without Rumble Motor
+ Case "SONY, ANALOG, CONTROLLER, SonyCompEntInc. A, SCPH-1150 MADE IN CHINA"
+ PCB1 "DD1P09A" (mainboard with digital buttons)
+ PCB2 "DD1Q14A" (daughterboard with analog joysticks)
+ PCB3 "DD1Q15A-R" (daughterboard with R-1, R-2 buttons) (J3)
+ PCB4 "DD1Q15A-L" (daughterboard with L-1, L-2 buttons) (J2)
+ U1 42pin "SD657, 9702K3006" (2x21pins, L=17.8mm, W=7mm, W+Pins=11mm)
+ U2 3pin "DR, 4.Z"
+ Q1 3pin "BQ03" or so (motor post-amp)
+ Q2 3pin "S6","SG","9S" or so (motor pre-amp)
+ Y1 3pin "400CMA"
+ CN1 8pin cable to PSX controller port
+ CN2 8pin ribbon cable to analog-joystick daughterboard (not so robust cable)
+ J1 2pin wires to rumble motor (in left handle) (digital, on/off)
+ J2 3pin ribbon cable to L-1, L-2 button daughterboard
+ J3 3pin ribbon cable to R-1, R-2 button daughterboard
+ LED1 4pin red/green LED (optics without mirror)
+ D1,D2 diodes
+ plus resistors/capacitors
+CN1 (cable to PSX controller port) (same for SCPH-1150 and SCPH-1200)
+
PSX.1 -------brown---- PAD.2 JOYDAT
+ PSX.2 -------orange--- PAD.6 JOYCMD
+ PSX.3 -------magenta-- PAD.8 +7.5V
+ PSX.4 -------black---- PAD.3 GND
+ PSX.5 -------red------ PAD.4 +3.5V
+ PSX.6 -------yellow--- PAD.5 /JOYn
+ PSX.7 -------blue----- PAD.7 JOYCLK
+ PSX.8 --- NC /IRQ10
+ PSX.9 -------green---- PAD.1 /ACK
+ PSX.Shield --shield--- NC (cable is shielded but isn't connected in joypad)
+ 8 +3.5V to POT pins
+ 7 Button L3 pins A,C
+ 6 GND to POT pins and Button L3/R3 pins B,D
+ 5 Button R3 pins A,C
+ 4 Axis R_Y middle POT pin (SD657.18)
+ 3 Axis R_X middle POT pin (SD657.17)
+ 2 Axis L_Y middle POT pin (SD657.16)
+ 1 Axis L_X middle POT pin (SD657.15)
+ 1 (red) R1
+ 2 (gray) GND
+ 3 (gray) R2
+ 1 (red) L1
+ 2 (gray) GND
+ 3 (gray) L2
+ 1 (red) +7.5V
+ 2 (black) Q1
+U1 42pin "SD657, 9702K3006"
+
1 NC?
+ 2 NC?
+ 3 /RESET? (U2.3)
+ 4 OSC
+ 5 OSC
+ 6 BUTTON Bit3 START SW1
+ 7 BUTTON Bit2 R3 (via CN2.5)
+ 8 BUTTON Bit1 L3 (via CN2.7)
+ 9 BUTTON Bit0 SELECT SW3
+ 10 GND
+ 11 BUTTON Bit7 LEFT SW4
+ 12 BUTTON Bit6 DOWN SW5
+ 13 BUTTON Bit5 RIGHT SW6
+ 14 BUTTON Bit4 UP SW7
+ 15 Analog Axis L_X (via CN2.1)
+ 16 Analog Axis L_Y (via CN2.2)
+ 17 Analog Axis R_X (via CN2.3)
+ 18 Analog Axis R_Y (via CN2.4)
+ 19 NC?
+ 20 3.5V
+ 21 3.5V
+ ---
+ 22 BUTTON Bit15 [] SW11
+ 23 BUTTON Bit14 >< SW10
+ 24 BUTTON Bit13 () SW9
+ 25 BUTTON Bit11 R1 (via J3.1)
+ 26 BUTTON Bit12 /\ SW8
+ 27 BUTTON Bit10 L1 (via J3.1)
+ 28 BUTTON Bit9 R2 (via J3.3)
+ 29 BUTTON Bit8 L2 (via J3.3)
+ 30 PSX.2/CN1.6 JOYCMD orange (via 220 ohm R14)
+ 31 PSX.1/CN1.2.JOYDAT brown (via 22 ohm R13 and diode D2)
+ 32 PSX.7/CN1.7 JOYCLK blue (via 220 ohm R12)
+ 33 PSX.6/CN1.5./JOYn yellow (via 220 ohm R11)
+ 34 LED.GREEN (LED.4)
+ 35 LED.RED (LED.3)
+ 36 MOTOR (via 4.7Kohm R8 to Q2, then via Q1 to motor)
+ 37 NC?
+ 38 NC?
+ 39 PSX.9/CN1.1./ACK green (via 22 ohm R10)
+ 40 NC?
+ 41 MODE SW2 (analog button)
+ 42 GND
+ 1 from 3.5V (via R1,D1,R2)
+ 2 to U1.3 (/RESET?) (U2.rear contact = same as U2.pin2)
+ 3 GND
+ 1 Q2.2 (via 1Kohm R7)
+ 2 to Motor (-)
+ 3 GND
+ 1 SD657.36 (via 4.7Kohm R8)
+ 2 Q1.1 (via 1Kohm R7) (and via 100Kohm R13 to GND)
+ 3 3.5V
+Left/Single Motor (SCPH-1150)
+
27.5mm Total Length (18.5mm Motor, 2mm Axis, 7mm Weight/block)
+ 12.0mm Width/Diameter (of Weight, and of Motor at flat side)
+ Case "SONY, ANALOG, CONTROLLER, SonyCompEntInc. H, SCPH-1200 MADE IN CHINA"
+ PCB1 "01, /\YG-H2, (r)RU" (mainboard with digital buttons)
+ PCB2 "M-29-01, YG-H3, (r)RU" (daughterboard with analog joysticks)
+ PCB3 "E, /\YG-H2, (r)RU, 01" (daughterboard with R-1, R-2 buttons) (J1)
+ PCB4 "01, W, /\YG-H2, (r)RU" (daughterboard with L-1, L-2 buttons) (J2)
+ U1 44pin "SONY, CXD8771Q 4A03, JAPAN 9840 HAL, 148896"
+ U2 4pin ",\\ 29" (PST9329) (System Reset with 2.9V detection voltage)
+ U3 8pin "2904, 8346G, JRC" (NJM2904) (Dual Operational Amplifier)
+ Q1 3pin ".Y S'" (big transistor for big M1 rumble motor)
+ Q2 3pin "Z" (small transistor for small M2 rumble motor)
+ Y1 3pin "800CMLX" or so (hides underneath of the CN2 ribbon cable)
+ CN1 8pin cable to PSX controller port
+ CN2 8pin ribbon cable to analog-joystick daughterboard
+ J1 3pin ribbon cable to R-1, R-2 button daughterboard
+ J2 3pin ribbon cable to L-1, L-2 button daughterboard
+ M1 2pin wires to left/big rumble motor (analog, slow/fast)
+ M2 2pin wires to right/small rumble motor (digital, on/off)
+ ZD1,ZD2 some Z-diodes
+ D1,D2 diodes near M1,M2 motors (these diodes aren't installed)
+ LED1 red analog mode LED (with transparent optics/light direction mirror)
+ plus resistors/capacitors
+Note: There's also a different SCPH-1200 revision, which having a smaller
+mainboard with analog joysticksonboard, plus a single sided PCB for the digital
+buttons (that is, similar to SCPH-110, but with the single sided PCB instead of
+membrane foil).
CN1 (cable to PSX controller port) (same for SCPH-1150 and SCPH-1200)
+
PSX.1 -------brown---- PAD.2 JOYDAT
+ PSX.2 -------orange--- PAD.6 JOYCMD
+ PSX.3 -------magenta-- PAD.8 +7.5V
+ PSX.4 -------black---- PAD.3 GND
+ PSX.5 -------red------ PAD.4 +3.5V
+ PSX.6 -------yellow--- PAD.5 /JOYn
+ PSX.7 -------blue----- PAD.7 JOYCLK
+ PSX.8 --- NC /IRQ10
+ PSX.9 -------green---- PAD.1 /ACK
+ PSX.Shield --shield--- NC (cable is shielded but isn't connected in joypad)
+ 1 +3.5V to POT pins
+ 2 Button L3 pins C,D
+ 3 GND to POT pins and Button L3/R3 pins A,B
+ 4 Button R3 pins C,D
+ 5 Axis R_Y middle POT pin (CXD.20)
+ 6 Axis R_X middle POT pin (CXD.19)
+ 7 Axis L_X middle POT pin (CXD.21)
+ 8 Axis L_Y middle POT pin (CXD.22)
+ 1 (red) R1
+ 2 (gray) GND
+ 3 (gray) R2
+ 1 (red) L1
+ 2 (gray) GND
+ 3 (gray) L2
+ + (red) Q1.E
+ - (black) GND
+ + (red) +7.5V
+ - (black) Q2.C
+U1 SONY CXD8771Q
+
1 PSX.7/CN1.7 JOYCLK (via 220 ohm R2)
+ 2 via R10 to U3.3 (for big M1 motor)
+ 3 via R15 to Q2.B (for small M2 motor)
+ 4 GND
+ 5 BUTTON Bit15 []
+ 6 BUTTON Bit14 ><
+ 7 BUTTON Bit13 ()
+ 8 BUTTON Bit12 /\
+ 9 BUTTON Bit11 R1 (via J1.1)
+ 10 BUTTON Bit10 L1 (via J2.1)
+ 11 BUTTON Bit9 R2 (via J1.3)
+ ---
+ 12 BUTTON Bit8 L2 (via J2.3)
+ 13 GND
+ 14 U2.Pin3 (reset)
+ 15 Y1'a
+ 16 Y1'b
+ 17 GND
+ 18 +3.5V
+ 19 Analog Axis R_X via CN2.6
+ 20 Analog Axis R_Y via CN2.5
+ 21 Analog Axis L_X via CN2.7
+ 22 Analog Axis L_Y via CN2.8
+ ---
+ 23 GND
+ 24 GND
+ 25 GND
+ 26 GND
+ 27 GND
+ 28 +3.5V
+ 29 BUTTON Bit0 SELECT
+ 30 BUTTON Bit1 L3 (via CN2.2)
+ 31 BUTTON Bit2 R3 (via CN2.4)
+ 32 BUTTON Bit3 START
+ 33 BUTTON Bit4 UP
+ ---
+ 34 BUTTON Bit5 RIGHT (aka spelled RIHGT on the PCB)
+ 35 BUTTON Bit6 DOWN
+ 36 BUTTON Bit7 LEFT
+ 37 PSX.6/CN1.5./JOYn (via 220 ohm R1)
+ 38 ANALOG BUTTON
+ 39 GND
+ 40 +3.5V
+ 41 /LED (to LED1, and from there via 300 ohm R6 to +3.5V)
+ 42 PSX.9/CN1.1./ACK (via 22 ohm R5)
+ 43 PSX.1/CN1.2.JOYDAT (via 22 ohm R3)
+ 44 PSX.2/CN1.6 JOYCMD (via 220 ohm R4)
+ 1 NC GND
+ 2 GND GND
+ 3 Vout U1.14
+ 4 VCC +3.5V
+ 1 A.OUTPUT Q1.B (big motor M1 transistor)
+ 2 A.INPUT- to R11/R12
+ 3 A.INPUT+ to R10/R17
+ 4 GND PSX.4/CN1.3 GND
+ 5 B.INPUT+ GND
+ 6 B.INPUT- NC?
+ 7 B.OUTPUT NC?
+ 8 VCC PSX.3/CN1.8 +7.5V
+ E M1+
+ B U3.1 (NJM2904)
+ C +7.5V
+ E GND
+ B via 1K ohm R15 to U1.3 (CXD), and via 100K ohm R16 to GND
+ C M2-
+ Left/Large Motor (SCPH-1200)
+ 24.0mm Total Length (12.0mm Motor, 2.5mm Axis, 9.5mm Weight/plates)
+ 24.0mm Diameter (Motor), 20.0mm Diameter (Weight/plates)
+ Right/Small Motor (SCPH-1200)
+ 25.4mm Total Length (18.7mm Motor, 2mm Axis, 4.7mm Weight/plates)
+ 12.0mm Width/Diameter (of Weight, and of Motor at flat side)
+ Case "SONY, ANALOG CONTROLLER, SonyCompEntInc. A, SCPH-110 MADE IN CHINA"
+ PCB1 "SA1Q22A, <PF-LP>, KPC, 7694V-0" (mainboard with joysticks onboard)
+ PCB2 "..." (membrane/foil with digital buttons)
+ U1 44pin "SD707, 039 107"" (4x11pin)
+ Q1 3pin "KA" (big transistor for left/big M1 rumble motor)
+ Q2 3pin "LG" (small transistor for right/small M2 rumble motor)
+ D1 2pin diode (for large motor, reference Z-diode with pull-up?)
+ D2 3pin dual-diode (R5/IRQ7 to GND and R3/DAT to GND)
+ CN1 9pin cable to PSX controller port
+ J1 16pin ribbon cable from membrane/foil
+ M1 2pin wires to left/big rumble motor (analog, slow/fast)
+ M2 2pin wires to right/small rumble motor (digital, on/off)
+ LED1 2pin red analog mode LED (with long legs, without mirror/optics)
+ plus resistors/capacitors
+CN1 (cable to PSX controller port)
+
1 +3.5V (logic supply)
+ 2 GND3 (logic supply)
+ 3 /IRQ7
+ 4 /SEL
+ 5 CMD
+ 6 DAT
+ 7 CLK
+ 8 GND7 (motor supply)
+ 9 +7.5V (motor supply)
+ 1 BUTTON Bit8 L2
+ 2 BUTTON Bit10 L1
+ 3 BUTTON Bit4 UP
+ 4 BUTTON Bit5 RIGHT
+ 5 BUTTON Bit6 DOWN
+ 6 BUTTON Bit7 LEFT
+ 7 GND3
+ 8 ANALOG BUTTON
+ 9 BUTTON Bit0 SELECT
+ 10 BUTTON Bit3 START
+ 11 BUTTON Bit15 SQUARE []
+ 12 BUTTON Bit14 CROSS ><
+ 13 BUTTON Bit13 CIRCLE ()
+ 14 BUTTON Bit12 TRIANGLE /\
+ 15 BUTTON Bit11 R1
+ 16 BUTTON Bit9 R2
+ 1 (red) Q1
+ 2 (black) GND (via some ohm)
+ 1 (red) +7.5V
+ 2 (black) Q2
+ 1 via R9/Q2 to M2 (right/small) (digital 0V=off, 3V=on)
+ 2 via "JP1" to LED (330 ohm)
+ 3 +3.5V
+ 4 BUTTON Bit2 R3
+ 5 vr2 RX (lt/rt)
+ 6 vr1 RY (up/dn)
+ 7 vr4 LX (lt/rt)
+ 8 vr3 LY (up/dn)
+ 9 BUTTON Bit1 L3
+ 10 GND3
+ 11 GND7
+ ---
+ 12 via Q1 to M1 (left/large) (1V=off, 6V=fast)
+ 13 via D1/R7 to M1 (left/large) (6.7V)
+ 14 +7.5V
+ 15 +7.5V
+ 16 BUTTON Bit8 L2
+ 17 BUTTON Bit10 L1
+ 18 BUTTON Bit4 UP
+ 19 BUTTON Bit5 RIGHT
+ 20 BUTTON Bit6 DOWN
+ 21 BUTTON Bit7 LEFT
+ 22 GND3
+ ---
+ 23 BUTTON Bit9 R2
+ 24 BUTTON Bit11 R1
+ 25 BUTTON Bit12 TRIANGLE /\
+ 26 BUTTON Bit13 CIRCLE ()
+ 27 BUTTON Bit14 CROSS ><
+ 28 BUTTON Bit15 SQUARE []
+ 29 BUTTON Bit3 START
+ 30 BUTTON Bit0 SELECT
+ 31 ANALOG BUTTON
+ 32 NC
+ 33 +3.5V
+ ---
+ 34 GND3
+ 35 NC
+ 36 via R5 to /IRQ7
+ 37 via R1 to /SEL
+ 38 via R4 to CMD
+ 39 via R3 to DAT
+ 40 via R2 to CLK
+ 41 +7.5V
+ 42 +7.5V
+ 43 GND7
+ 44 GND7
+VR1..VR4 -- analog inputs
+R1..R5 -- signals to/from psx
+R6 ?
+R7 M1
+R8
+R9
+R10
+JP1
+C1 3.5V to GND3 (22uF)
+C2 3.5V to GND3 (U1)
+C3 VR1 to GND3
+C4 VR2 to GND3
+C5 VR3 to GND3
+C6 VR4 to GND3
+C7 M2+ to M2-
+C8 M1+ to M1-
+C9 M1 related
+S5
+S6
Left/Large Motor (SCPH-110)
+ 23.0mm Total Length (12.0mm Motor, 3mm Axis, 8.0mm Weight/plates)
+ 24.0mm Diameter (Motor), 20.0mm Diameter (Weight/plates)
+ Right/Small Motor (SCPH-110)
+ 25.4mm Total Length (18.7mm Motor, 2mm Axis, 4.7mm Weight/plates)
+ 12.0mm Width/Diameter (of Weight, and of Motor at flat side)
+ M1+ --o---Q1---o--------- U1.12
+ | | | analog
+ Left | | C9
+ Large | | |
+ | o----o--------- 7.5V
+ | |
+ C8 R7
+ | D1 | 6.7V
+ o---|>|--o--------- U1.13
+ |
+ M1- --o------------------ GND7
+D1 is probably a Z-diode with R7 as pull-up, creating a reference/source
+voltage at U1.13 for the analog output at U1.12.
M2+ --o------------------ 7.5V
+ |
+ Right | o-------o--R9-- U1.1
+ Small | | | on/off
+ C7 | R10
+ | | |
+ M2- --o---Q2------o------ GND7
+ ___ ___ ____
+ axis | | / \ \
+ __/___ ______| m | __.____________|__. | |
+ /__/__/ | | w | | | | | | axis | | |
+ | |/ weight |___| |___| \___/_/ \___/____/
+ \____/ weight motor
+http://www.nicolaselectronics.be/reverse-engineering-the-playstation-g-con45/
PCB "DNP-0500A, NPC10300, namco, CMK-P3X"
+
U1 44pin "NAMCO103P, 1611U1263, JAPAN 9847EAI, D0489AAF"
+ U2 8pin "7071, 8C19" (=BA7071F, Sync Separator IC with AFC)
+ XTAL 2pin "CSA 8.00WT"
+ PS1 3pin Light sensor with metal shielding
+ J1 9pin Connector for 9pin cable to PSX controller and GunCon plugs
+ plus resistors and capacitors, and A1,A2,B1,B2,T1,T2 wires to buttons
+ DIP Button (with black T1,T2 wires) (trigger)
+ Button A (with red A1,A2 wires) (left side)
+ Button B (with white B1,B2 wires) (right side)
+ Lens (20mm)
+ J1.Pin1 green PSX.Controller.Pin5 +3.5V
+ J1.Pin2 brown PSX.Controller.Pin4 GND
+ J1.Pin3 black PSX.Controller.Pin9 /ACK/IRQ7
+ J1.Pin4 red PSX.Controller.Pin6 /JOYn
+ J1.Pin5 yellow PSX.Controller.Pin1 JOYDAT
+ J1.Pin6 orange PSX.Controller.Pin2 JOYCMD
+ J1.Pin7 blue PSX.Controller.Pin7 JOYCLK
+ J1.Pin8 gray GunCon shield (GND)
+ J1.Pin9 white GunCon composite video
+ N/A PSX.Controller.Pin3 +7.5V
+ N/A PSX.Controller.Pin8 /IRQ10
+ N/A PSX.Controller Shield
+ 1 GND 12 SYNC (from U2) 23 3.5V 34 SW1 (A)
+ 2 GND 13 3.5V 24 3.5V 35 3.5V
+ 3 GND 14 3.5V 25 3.5V 36 3.5V
+ 4 GND 15 SW3 (TRIGGER) 26 GND 37 SW2 (B)
+ 5 GND 16 JOYCLK (J1.Pin7 via 220 ohm R7) 27 GND 38 3.5V
+ 6 GND 17 3.5V 28 GND 39 3.5V
+ 7 GND 18 JOYCMD (J1.Pin6 via 220 ohm R8) 29 GND 40 LIGHT (from PS1)
+ 8 GND 19 JOYDAT (J1.Pin5 via 0 ohm R10) 30 - 41 GND
+ 9 - 20 /JOYn (J1.Pin4 via 220 ohm R9) 31 GND 42 GND
+ 10 GND 21 /ACK/IRQ7 (J1.Pin3 via 0 ohm R11) 32 GND 43 OSC 8MHz
+ 11 GND 22 GND 33 GND 44 OSC 8MHz
+ 1 VIN = SYNC.IN from J1.Pin9 Composite Video (via C5/C6/C7/R6)
+ 2 HD_OUT = NC
+ 3 GND = GND
+ 4 PD_OUT = NC
+ 5 HOSC_R = via 100K to GND
+ 6 VCC = 3.5V
+ 7 VD_OUT = NC
+ 8 SYNC_OUT = SYNC.OUT to U1.pin12 (with R4 pull-up)
+ Case "SONY, MULTITAP, SonyComputerEntertainmentInc, SCPH-1070 MADE IN CHINA"
+ PCB1 "SONY 1-659-343-11" (mainboard with Slot A,B, ICs, X1, PSX-cable)
+ PCB2 "SONY 1-711-414-11" (daughterboard with Slot C,D)
+ IC? 64pin "SONY JAPAN, CXD103, -166Q, 550D66E" (smd/back side)
+ IC02 8pin "7W14, 5K" some tiny SMD chip (for JOYCLK) (smd/back side)
+ X1 2pin "4.00G CMj" oscillator (front side)
+ J34 2pin fuse or 1 ohm resistor or so (for +3.5V input) (front side)
+ Jxx 2pin normal wire bridges (except: J34 is NOT a wire) (front side)
+ 1pin black wire Shield/GND (lower edge)
+ 1pin black wire Shield/GND (upper edge)
+ 2x8pin red/gray ribbon cable (side edge)
+ 2x2pin red/gray ribbon cable (lower edge)
+ 2pin red/gray ribbon cable (upper middle) (gray=+3.3V, red=+7.5V)
+ PSX.1 -------brown------ TAP.1 JOYDAT ;via 47 ohm (R57) to CXD.35
+ PSX.2 -------orange----- TAP.2 JOYCMD ;via 220 ohm (R58) to CXD.37
+ PSX.3 -------magenta---- TAP.3 +7.5V ;directly to +7.5V on JOY/CARD's
+ PSX.4 -------black------ TAP.4 GND ;directly to GND
+ PSX.5 -------red-------- TAP.5 +3.5V ;via 1 ohm or so (J34) to +3.3V
+ PSX.6 -------yellow----- TAP.6 /JOYn ;via 220 ohm (R59) to CXD.46
+ PSX.7 -------blue------- TAP.7 JOYCLK ;via 220 ohm (R60) to IC02.pin6
+ PSX.8 -------gray------- TAP.8 /IRQ10 ;via 47 ohm (R02/R16/R30/R44) to JOY's
+ PSX.9 -------green------ TAP.9 /ACK ;via 47 ohm (R61) to CXD.51
+ PSX.Shield --shield----- TAP.shielding.plate (GND)
+ 1 JOYDAT Via 47 ohm (R11/R25/R38/R5x) to CXD.18/29/60/5 (and to JOY slot)
+ 2 JOYCMD Via 220 ohm (R10/R24/R39/R52) to CXD.19/30/62/6
+ 3 +7.5V Directly to PSX.3
+ 4 GND Directly to PSX.4
+ 5 +3.3V Via J34 to PSX.5 (+3.5V)
+ 6 /JOYn Via 220 ohm (R09/R2x/Rxx/R51) to CXD.11/22/52/61
+ 7 JOYCLK Via 220 ohm (R08/R2x/Rxx/R50) to CXD.33/33/47/47
+ 9 /ACK Via 47 ohm (R07/R2x/Rxx/R49) to CXD.12/21/45/64
+ 1 JOYDAT Via 47 ohm (R06/Rxx/R34/R5x) to CXD.18/29/60/5 (and to CARD slot)
+ 2 JOYCMD Via 220 ohm (R05/R19/R35/R5x) to CXD.17/28/59/4
+ 3 +7.5V Directly to PSX.3
+ 4 GND Directly to PSX.4
+ 5 +3.3V Via 1 ohm or so (J34) to PSX.5 (+3.5V)
+ 6 /JOYn Via 220 ohm (R04/R18/R32/R4x) to CXD.16/20/55/63
+ 7 JOYCLK Via 220 ohm (R03/R17/R31/R45) to CXD.15/23/56/2
+ 8 /IRQ10 Via 47 ohm (R02/R16/R30/R44) to PSX.8
+ 9 /ACK Via 47 ohm (R01/R15/R29/R43) to CXD.13/27/54/7
+ Shield Directly to Shield/GND
+ 1
+ 2
+ 3
+ 4 GND
+ 5
+ 6 via 220 ohm (R60) to PSX.7 (JOYCLK)
+ 7 to CXD.Pin48
+ 8 +3.3V, aka via 1 ohm (J34) to PSX.5 (+3.5V)
+ 1 via to 10K (R63) to +3.3V, and via C13 to GND (probably power-on reset)
+ 2 JOY.D.7.JOYCLK
+ 3
+ 4 JOY.D.2.JOYCMD
+ 5 JOY/CARD.D.1.JOYDAT
+ 6 CARD.D.2.JOYCMD
+ 7 JOY.D.9./ACK
+ 8 4MHz X1/C12
+ 9 4MHz X1/C11
+ 10 GND
+ 11 CARD.A.6./JOYn
+ 12 CARD.A.9./ACK
+ 13 JOY.A.9./ACK
+ 14
+ 15 JOY.A.7.JOYCLK
+ 16 JOY.A.6./JOYn
+ 17 JOY.A.2.JOYCMD
+ 18 JOY/CARD.A.1.JOYDAT
+ 19 CARD.A.2.JOYCMD
+ ---
+ 20 JOY.B.6./JOYn
+ 21 CARD.B.9./ACK
+ 22 CARD.B.6./JOYn
+ 23 JOY.B.7.JOYCLK
+ 24
+ 25 GND
+ 26 +3.3V
+ 27 JOY.B.9./ACK
+ 28 JOY.B.2.JOYCMD
+ 29 JOY/CARD.B.1.JOYDAT
+ 30 CARD.B.2.JOYCMD
+ 31 GND
+ 32
+ ---
+ 33 CARD.A/B.7.JOYCLK
+ 34
+ 35 PSX.1.JOYDAT
+ 36
+ 37 PSX.2.JOYCMD
+ 38
+ 39
+ 40
+ 41
+ 42 GND
+ 43
+ 44 GND
+ 45 CARD.C.9./ACK
+ 46 PSX.6./JOYn
+ 47 CARD.C/D.7.JOYCLK
+ 48 IC02.Pin7.PSX.JOYCLK
+ 49
+ 50
+ 51 PSX.9./ACK
+ ---
+ 52 CARD.C.6./JOYn
+ 53
+ 54 JOY.C.9./ACK
+ 55 JOY.C.6./JOYn
+ 56 JOY.C.7.JOYCLK
+ 57 GND
+ 58 +3.3V
+ 59 JOY.C.2.JOYCMD
+ 60 JOY/CARD.C.1.JOYDAT
+ 61 CARD.D.6./JOYn
+ 62 CARD.C.2.JOYCMD
+ 63 JOY.D.6./JOYn
+ 64 CARD.D.9./ACK
+The "SONY CXD8732AQ" chip is installed on memory cards with "SPC02K1020B"
+boards, however, the text layer on the board says that it's an "LC86F8604A"
+chip. So, the CXD8732AQ is most probably a standard LC86F8604A chip (more on
+that below) with a Sony Memory Card BIOS ROM on it.
+The "SONY CXD8732AQ" comes in a huge 64pin package, but it connects only to:
+
5 = /IRQ7 (via 22 ohm) 2 = /RESET (from U2)
+ 6 = JOYCLK (via 220 ohm) 30,31 = CF1,CF2 (12 clock pulses per 2us)
+ 7 = /JOYn (via 220 ohm) 14,16,25,32,38,39,61 = 3.5V (via 3.3 ohm)
+ 12 = JOYCMD (via 220 ohm) 8,15,28,29 = GND
+ 13 = JOYDAT (via 22 ohm) All other pins = Not connected
+8bit CPU with 132Kbyte EEPROM, 4Kbyte ROM, 256 bytes RAM, 2 timers, serial
+port, and general purpose parallel ports. The 132K EEPROM is broken into 128K
+plus 4K, the 4K might be internally used by the CPU, presumably containing the
+BIOS (not too sure if it's really containing 4K EEPROM plus 4K ROM, or if it's
+meant to be only either one).
+
1=P40/A0 9=P13 17=TP0 25=VDD 33=A11 41=NC 49=A7 57=NC
+ 2=/RES 10=P14 18=TP1 26=NC 34=A9 42=NC 50=A6 58=NC
+ 3=TEST2 11=P15 19=TP2 27=NC 35=A8 43=NC 51=A5 59=NC
+ 4=TEST1 12=P16 20=TP3 28=NC 36=A13 44=NC 52=A4 60=NC
+ 5=P10 13=P17 21=TP4 29=VSS 37=A14 45=A17 53=NC 61=NC61
+ 6=P11 14=/CE 22=TP5 30=CF1 38=/WE 46=A16 54=NC 62=P43/A3
+ 7=P12 15=A10 23=TP6 31=CF2 39=VDD 47=A15 55=NC 63=P42/A2
+ 8=VSS 16=/OE 24=TP7 32=VDD 40=EP 48=A12 56=NC 64=P41/A1
+ P10/DQ0/SEPMOD P12/DQ2/FSI0 P14/DQ4 P16/DQ6/SI0/FSTART
+ P11/DQ1/SCLK0/FSCLK P13/DQ3 P15/DQ5 P17/DQ7/SO0/FRW
+For the actual pin-outs of the cart-edge connector, see
+Pinouts - Controller Ports and Memory-Card Ports
GND (BOARD) --------- GND (SUBD.18-25, CNTR.19-30)
+ A16 (ROM.2) --------- SLCT (SUBD.13, CNTR.13) ;\
+ A17 (ROM.30) --------- PE (SUBD.12, CNTR.12) ; 4bit.dta.out
+ A18 (ROM.31) --------- /ACK (SUBD.10, CNTR.10) ;
+ A19 (ROM.1) --------- BUSY (SUBD.11, CNTR.11) ;/
+ /RESET ---|>|--- /INIT (SUBD.16, CNTR.31) ;-reset.in
+ D0..D7 (74HC541) --------- DATA (SUBD.2-9, CNTR.2-9) ;\
+ Y0..Y7 (74HC541) --------- D0..D7 (ROM.13-15,17-21) ; 7bit.dta.in, and
+ /OE1 (74HC541.1) --------- /EXP (CPU.98) ; 1bit.dta.clk.in
+ /OE2 (74HC541.19) --------- /OE (ROM.24) ;
+ GND (74HC541.10) --------- GND (BOARD) ;
+ VCC (74HC541.20) --------- +5V (BOARD) ;/
+ A0..A19 (ROM) --------- A0..A19 (EPROM)
+ D0..D7 (ROM) --------- D0..D7 (EPROM)
+ /BIOS (CPU.97)--------- /CS (EPROM.22)
+ /OE (ROM.24) --------- /OE (EPROM.24)
+ +5V (BOARD) --------- VCC (EPROM.32)
+ GND (BOARD) --------- GND (EPROM.16)
+ /CS (ROM.22) --/cut/-- /BIOS (CPU.97)
+ /CS (ROM.22) --------- +5V (BOARD) (direct, or via 100k ohm)
+ SPU.Pin42 "data" -------|>|------ CPU.Pin149 (A20)
+ SPU.Pin5 "sync" ---------------- IC723.Pin17
+ 32pin socket for EPROM
+ EPROM (or FLASH)
+ 74HC541 (8-bit 3-state noninverting buffer/line driver)
+ 1N4148 diode (for reset signal)
+ 1N4148 diode (for optional "modchip" feature)
+ 36pin Centronics socket for printer cable (or 25pin dsub)
+The required BIOS is contained in no$psx (built-in in the no$psx.exe file), the
+Utility menu contains a function for creating a standalone ROM-image (file
+PSX-XBOO.ROM in no$psx folder; which can be then burned to FLASH or EPROM).
______ ______ ____ ____
+ | \/ | | \/ |
+ A19,VPP12 | 1 32 | VCC6 /OE1 |1 20| VCC
+ A16 | 2 31 | A18,/PGM D0 |2 19| /OE2
+ A15 | 3 30 | A17 D1 |3 18| Y0
+ A12 | 4 29 | A14 D2 |4 17| Y1
+ A7 | 5 28 | A13 D3 |5 74541 16| Y2
+ A6 | 6 27 | A8 D4 |6 15| Y3
+ A5 | 7 26 | A9,IDENT12 D5 |7 14| Y4
+ A4 | 8 25 | A11 D6 |8 13| Y5
+ A3 | 9 24 | /OE,VPP12 D7 |9 12| Y6
+ A2 | 10 23 | A10 GND |10 11| Y7
+ A1 | 11 22 | /CE,(/PGM) |__________|
+ A0 | 12 21 | D7
+ D0 | 13 20 | D6
+ D1 | 14 19 | D5
+ D2 | 15 18 | D4
+ GND | 16 17 | D3
+ |______________|
+Instead of the above internal mod, the nocash kernel clone can be also
+installed on cheat devices, which do also include DB25 connectors for parallel
+port uploads, too.
+For DB25 parallel port uploads, do the following mods to the cheat device:
+
- Datel: use the FiveWire mod to get it parallel port compatible
+ - Xplorer: simply wire DB25./INIT to EXP./RESET (with diode, if needed)
+The PSX hardware is more or less capable of generating both PAL and NTSC
+signals. However, it's having the bad habbit to do this automatically depending
+on the game's frame rate. And worse, it's doing it regardless of whether the
+board is having matching oscillators installed (eg. a PAL board in 60Hz mode
+will produce NTSC encoding with faulty NTSC color clock).
+
color encoding PAL NTSC
+ color clock 4.43361875MHz 3.579545MHz
+ frame rate 50Hz 60Hz
+RGB cables don't rely on composite PAL/NTSC color encoding, and thus don't need
+any color mods (except, see the caution on GNDed pins for missing
+53.20MHz/53.69MHz oscillators below).
These consoles have 17.734MHz (PAL) or 14.318MHz (NTSC) oscillators with
+constant dividers, so the color clock will be always constant, and one does
+only need to change the color encoding:
+
/PAL (IC502.pin13) ---/cut/--- /PAL (GPU.pin157)
+ /PAL (IC502.pin13) ----------- GND (PAL) or VCC (NTSC)
+These consoles have 53.20MHz (PAL) or 53.69MHz (NTSC) oscillators and the GPU
+does try to change the clock divider depending on the frame rate (thereby
+producing a nonsense clock signal that's neither PAL nor NTSC). Best workaround
+is to install an extra 4.43361875MHz (PAL) or 3.579545MHz (NTSC) oscillator
+(with internal amplifier, ie. in 4pin package, which resembles DIP14, hence the
+pin 1,7,8,14 numbering):
+
GPU ------------------/cut/--- CXA1645M.pin6 SCIN
+ GPU ------------------/cut/--- CXA1645M.pin7 /PAL
+ Osc.pin14 VCC ---------------- CXA1645M.pin12 VCC (5V)
+ Osc.pin7 GND ---------------- CXA1645M.pin1 GND
+ Osc.pin8 OUT ---------------- CXA1645M.pin6 SCIN
+ Osc.pin1 NC --
+ GND (PAL) or VCC (NTSC) ------ CXA1645M.pin7 /PAL
+External 4.433MHz/3.579MHz osciallors won't be synchronized with the GPU frame
+rate (normally you don't want them to be synchronized, but there's some small
+risk that they might get close to running in sync, which could result in static
+or crawling color artifacts).
+For the CXA1645 chip modded to a different console region, one should also
+change one of the resistors (see datasheet), there's no noticable difference on
+the TV picture though.
Some kernel versions contain regions checks (additionally to the SCEx check),
+particulary for preventing NTSC games to run on PAL consoles, or non-japanese
+games on japanese consoles. Some PAL modchips can bypass that check (by
+patching the region byte in BIOS). Expansions ROMs or nocash kernel clone could
+be also used to avoid such checks.
Pocketstation Overview
+Pocketstation I/O Map
+Pocketstation Memory Map
+Pocketstation IO Video and Audio
+Pocketstation IO Interrupts and Buttons
+Pocketstation IO Timers and Real-Time Clock
+Pocketstation IO Infrared
+Pocketstation IO Memory-Control
+Pocketstation IO Communication Ports
+Pocketstation IO Power Control
+Pocketstation SWI Function Summary
+Pocketstation SWI Misc Functions
+Pocketstation SWI Communication Functions
+Pocketstation SWI Execute Functions
+Pocketstation SWI Date/Time/Alarm Functions
+Pocketstation SWI Flash Functions
+Pocketstation SWI Useless Functions
+Pocketstation BU Command Summary
+Pocketstation BU Standard Memory Card Commands
+Pocketstation BU Basic Pocketstation Commands
+Pocketstation BU Custom Pocketstation Commands
+Pocketstation File Header/Icons
+Pocketstation File Images
+Pocketstation XBOO Cable
The Pocketstation is a memory card with built-in LCD screen and buttons; aside
+from using it as memory storage device, it can be also used as miniature
+handheld console.
CPU ARM7TDMI (32bit RISC Processor) (variable clock, max 7.995MHz)
+ Memory 2Kbytes SRAM (battery backed), 16Kbytes BIOS ROM, 128Kbytes FLASH
+ Display 32x32 pixel LCD (black and white) (without any grayscales)
+ Sound Mini Speaker "(12bit PCM) x 1 unit" / "8bit PCM with 12bit range"
+ Controls 5 input buttons, plus 1 reset button
+ Infrared Bi-directional (IrDA based)
+ Connector Playstation memory card interface
+ RTC Battery backed Real-Time Clock with time/date function
+ Supply CR2032 Battery (3VDC) (used in handheld mode, and for SRAM/RTC)
+ _________
+ / _______ \
+ | | | |
+ | | LCD | | __
+ | |_______| | Side Views | _|
+ |\_________/| || <-------- Button Cover
+ | O | (Closed) (Open) ||
+ | O O O | ____________ _____|| .------- Reset Button
+ | O | | LCD \____ | | LCD \|__|_
+ |___________| |___________|| |___________| <--- Memory card plug
+The main problem of the Pocketstation seems to be that it tends to reset the
+RTC to 1st January 1999 with time 00:00:00 whenever possible.
+The BIOS contains so many RTC-reset functions, RTC-reset buttons, RTC-reset
+flags, RTC-reset communication commands, RTC-reset parameters, RTC-reset
+exceptions, RTC-reset sounds, and RTC-reset animations that it seems as if Sony
+actually WANTED the Time/Date to be destroyed as often as possible.
+The only possible reason for doing this is that the clock hardware is so
+inaccurate that Sony must have decided to "solve" the problem at software
+engineering side, by erasing the RTC values before the user could even notice
+time inaccuracies.
For details on the ARM7TDMI CPUs opcodes and exceptions, check GBATEK at,
+http://problemkaputt.de/gbatek.htm (or .txt)
+The GBA uses an ARM7TDMI CPU, too.
Thanks to Exophase, Orion, Fezzik, Dr.Hell for Pocketstation info.
00000000h RAM (2KB RAM) (first 512 bytes bytes reserved for kernel)
+ 02000000h FLASH1 Flash ROM (virtual file-mapped addresses in this region)
+ 04000000h BIOS_ROM Kernel and GUI (16KB)
+ 06000000h F_CTRL Control of Flash ROM
+ 06000004h F_STAT Unknown?
+ 06000008h F_BANK_FLG FLASH virtual bank mapping enable flags(16 bits)(R/W)
+ 0600000Ch F_WAIT1 waitstates...?
+ 06000010h F_WAIT2 waitstates, and FLASH-Write-Control-and-Status...?
+ 06000100h F_BANK_VAL FLASH virtual bank mapping addresses (16 words) (R/W)
+ 06000300h F_EXTRA Extra FLASH (256 bytes, including below F_SN, F_CAL)
+ 06000300h F_SN_LO Extra FLASH Serial Number LSBs (nocash: 6BE7h)
+ 06000302h F_SN_HI Extra FLASH Serial Number MSBs (nocash: 426Ch)
+ 06000304h F_? Extra FLASH Unknown ? (nocash: 05CAh)
+ 06000306h F_UNUSED1 Extra FLASH Unused halfword (nocash: FFFFh)
+ 06000308h F_CAL Extra FLASH LCD Calibration (nocash: 001Ah)
+ 0600030Ah F_UNUSED2 Extra FLASH Unused halfword (nocash: FFFFh)
+ 0600030Ch F_? Extra FLASH Unknown ? (nocash: 0010h)
+ 0600030Eh F_UNUSED3 Extra FLASH Unused halfword (nocash: FFFFh)
+ 06000310h F_UNUSED4 Extra FLASH Unused (310..3FFh) (nocash: FFFFh-filled)
+ 08000000h FLASH2 Flash ROM (128KB) (physical addresses in this region)
+ 08002A54h F_KEY1 Flash Unlock Address 1 (W)
+ 080055AAh F_KEY2 Flash Unlock Address 2 (W)
+ 0A000000h INT_LATCH Interrupt hold (R)
+ 0A000004h INT_INPUT Interrupt Status (R)
+ 0A000008h INT_MASK_READ Read Interrupt Mask (R)
+ 0A000008h INT_MASK_SET Set Interrupt Mask (W)
+ 0A00000Ch INT_MASK_CLR Clear Interrupt Mask (W)
+ 0A000010h INT_ACK Clear Interrupt hold (W)
+ 0A800000h T0_RELOAD Timer 0 Maximum value
+ 0A800004h T0_COUNT Timer 0 Current value
+ 0A800008h T0_MODE Timer 0 Mode
+ 0A800010h T1_RELOAD Timer 1 Maximum value
+ 0A800014h T1_COUNT Timer 1 Current value
+ 0A800018h T1_MODE Timer 1 Mode
+ 0A800020h T2_RELOAD Timer 2 Maximum value
+ 0A800024h T2_COUNT Timer 2 Current value
+ 0A800028h T2_MODE Timer 2 Mode
+ 0B000000h CLK_MODE Clock control (CPU and Timer Speed) (R/W)
+ 0B000004h CLK_STOP Clock stop (Sleep Mode)
+ 0B800000h RTC_MODE RTC Mode
+ 0B800004h RTC_ADJUST RTC Adjust
+ 0B800008h RTC_TIME RTC Time (R)
+ 0B80000Ch RTC_DATE RTC Date (R)
+ 0C000000h COM_MODE Com Mode
+ 0C000004h COM_STAT1 Com Status Register 1 (Bit1=Error)
+ 0C000008h COM_DATA Com RX Data (R) and TX Data (W)
+ 0C000010h COM_CTRL1 Com Control Register 1
+ 0C000014h COM_STAT2 Com Status Register 2 (Bit0=Ready)
+ 0C000018h COM_CTRL2 Com Control Register 2
+ 0C800000h IRDA_MODE Infrared Control (R/W)
+ 0C800004h IRDA_DATA Infrared TX Data
+ 0C80000Ch IRDA_MISC Infrared Unknown/Reserved
+ 0D000000h LCD_MODE Video Control (R/W)
+ 0D000004h LCD_CAL Video Calibration (?)
+ 0D000100h LCD_VRAM Video RAM (80h bytes; 32x32bit) (R/W)
+ 0D800000h IOP_CTRL IOP control
+ 0D800004h IOP_STAT Read Current Start/Stop bits? (R)
+ 0D800004h IOP_STOP Stop bits? (W)
+ 0D800008h IOP_START Start bits? (W)
+ 0D80000Ch IOP_DATA IOP data? (not used by bios)
+ 0D800010h DAC_CTRL DAC Control (R/W)
+ 0D800014h DAC_DATA DAC data
+ 0D800020h BATT_CTRL Battery Monitor Control
+Memory Access Time for Opcode Fetch:
+
WRAM 1 cycle (for ARM and THUMB)
+ FLASH 2 cycles (for ARM), or 1 cycle (for THUMB)
+ BIOS ?
+ WRAM (and some F_xxx ports) 1 cycle
+ VIRT/PHYS/XTRA_FLASH, BIOS, VRAM, I/O 2 cycles
+ 00000800h-00FFFFFFh Mirrors of 00000000h-000007FFh (2K RAM)
+ 01000000h-01FFFFFFh Invalid (read causes data abort) (unused 16MB area)
+ 020xxxxxh-0201FFFFh Invalid (read causes data abort) (disabled FLASH banks)
+ 02020000h-02FFFFFFh Invalid (read causes data abort) (no Virt FLASH mirrors)
+ 03000000h-03FFFFFFh Invalid (read causes data abort) (unused 16MB area)
+ 04004000h-04FFFFFFh Mirrors of 04000000h-04003FFFh (16K BIOS)
+ 05000000h-05FFFFFFh Invalid (read causes data abort)
+ 06000014h-060000FFh Zerofilled (or maybe mirror of a ZERO port?) (F_xxx)
+ 06000140h-060002FFh Zerofilled (or maybe mirror of a ZERO port?) (F_xxx)
+ 06000400h-06FFFFFFh Zerofilled (or maybe mirror of a ZERO port?) (F_xxx)
+ 07000000h-07FFFFFFh Invalid (read causes data abort) (unused 16MB area)
+ 08020000h-08FFFFFFh Mirrors of 08000000h-0801FFFFh (128K Physical FLASH)
+ 09000000h-09FFFFFFh Invalid (read causes data abort) (unused 16MB area)
+ 0A000014h-0A7FFFFFh Mirrors of 0A000008h-0A00000Bh (INT_MASK_READ) (I_xxx)
+ 0A80000Ch Mirror of 0A800000h-0A800003h (T0_RELOAD) (T0_xxx)
+ 0A80001Ch Mirror of 0A800000h-0A800003h (T0_RELOAD) (T1_xxx)
+ 0A80002Ch Mirror of 0A800000h-0A800003h (T0_RELOAD) (T2_xxx)
+ 0A800030h-0AFFFFFFh Mirrors of 0A800000h-0A800003h (T0_RELOAD) (T_xxx)
+ 0B000008h-0B7FFFFFh Mirrors of .... ? (CLK_xxx)
+ 0B800010h-0BFFFFFFh Mirrors of 0B800008h-0B80000Bh (RTC_TIME)
+ 0C00000Ch-0C00000Fh Zero (COM_xxx)
+ 0C00001Ch-0C7FFFFFh Zerofilled (or maybe mirror of a ZERO port?) (COM_xxx)
+ 0C800008h-0CFFFFFFh ? (IRDA_xxx)
+ 0D000008h-0D0000FFh Zerofilled (or maybe mirror of a ZERO port?) (LCD_xxx)
+ 0D000180h-0D7FFFFFh Zerofilled (or maybe mirror of a ZERO port?) (LCD_xxx)
+ 0D800018h ? (DAC_xxx)
+ 0D80001Ch ? (DAC_xxx)
+ 0D800024h-0DFFFFFFh Zerofilled (or maybe mirror of a ZERO port?) (BATT_xxx)
+ 0E000000h-FFFFFFFFh Invalid (read causes data abort) (unused 3872MB area)
+ 02000000h-0201FFFFh VIRT_FLASH ;\
+ 04000000h-04FFFFFFh BIOS_ROM ; "garbage_byte" (see below)
+ 06000300h-060003FFh EXTRA_FLASH ;
+ 08000000h-08FFFFFFh PHYS_FLASH ;/
+ 0A800001h-0AFFFFFFh Timer area, odd addresses (with A0=1) mirror to 0A800001h
+ 0B800001h-0BFFFFFFh RTC area, odd addresses (with A0=1) mirror to ...?
+ 0B800002h-0BFFFFFEh RTC area, odd addresses (with A1=1) mirror to 0B80000Ah
+The "garbage_byte" depends on the LSBs of the read address, prefetched opcodes,
+and recent data fetches:
+
garbage_word = (prefetch OR (ramdata AND FFFFFFD0h))
+ garbage_byte = (garbage_word shr (8*(addr and 3))) AND FFh
+ prefetch.bit0-31 = [curr_arm_opcode_addr+8] ;-eg. from arm LDRB
+ prefetch.bit0-15 = [recent_arm_opcode_addr+8] ;-eg. from arm BX to thumb
+ prefetch.bit16-31 = [curr_thumb_opcode_addr+4] ;-eg. from thumb LDRB
+ ramdata.bit0-31 = [recent_ram_read_addr] ;-eg. from LDR/POP from RAM
+ 00000000h RAM RAM (2K) (or mirror of BIOS ROM upon reset)
+ 02000000h FLASH1 Flash ROM (virtual file-mapped addresses in this region)
+ 04000000h BIOS_ROM BIOS (16K) (Kernel and GUI)
+ 06000300h F_SN... Seems to contain a bunch of additional FLASH bytes?
+ 08000000h FLASH2 Flash ROM (128K) (physical addresses in this region)
+ 0D000100h LCD_VRAM Video RAM (128 bytes) (32x32 pixels, 1bit per pixel)
+The first 200h bytes of RAM are reserved for the kernel.
+
0000000h 20h Exception handler opcodes (filled with LDR R15,[$+20h] opcodes)
+ 0000020h 20h Exception handler addresses (in ARM state, no THUMB bit here)
+ 0000040h 80h Sector buffer (and BU command parameter work space)
+ 00000C0h 8 ComFlags (see GetPtrToComFlags(), SWI 06h for details)
+ 00000C8h 2 BU Command FUNC3 Address (see GetPtrToFunc3addr() aka SWI 17h)
+ 00000CAh 1 Value from BU Command_50h, reset by SWI 05h (sense_auto_com)
+ 00000CBh 2 Not used
+ 00000CDh 1 Old Year (BCD, 00h..99h) (for sensing wrapping to new century)
+ 00000CEh 1 Alternate dir_index (when [0D0h]=0) (see SWI 15h and SWI 16h)
+ 00000CFh 1 Current Century (BCD, 00h..99h) (see GetBcdDate() aka SWI 0Dh)
+ 00000D0h 2 Current dir_index (for currently executed file, or 0=GUI)
+ 00000D2h 2 New dir_index (PrepareExecute(flag,dir_index,param), SWI 08h)
+ 00000D4h 4 New param (PrepareExecute(flag,dir_index,param), SWI 08h)
+ 00000D8h 8 Alarm Setting (see GetPtrToAlarmSetting() aka SWI 13h)
+ 00000E0h 4 Pointer to SWI table (see GetPtrToPtrToSwiTable() aka SWI 14h)
+ 00000E4h 3x4 Memory Card BU Command variables
+ 00000F0h 1 Memory Card FLAG byte (bit3=new_card, bit2=write_error)
+ 00000F1h 1 Memory Card Error offhold (0=none, 1=once)
+ 00000F2h 6 Not used
+ 00000F8h 4x4 Callback Addresses (set via SetCallbacks(index,proc), SWI 01h)
+ 0000108h 4 Snapshot ID (0xh,00h,"SE")
+ 000010Ch 74h IRQ and SWI stack (stacktop at 180h)
+ 0000180h 80h FIQ stack (stacktop at 200h)
+This region can be freely used by the game. The memory is zerofilled when the
+game starts.
This region usually contains the currently selected file (including its title
+and icon sectors), used to execute the file in this region, mapped to continous
+addresses at 2000000h and up.
This region is used by the BIOS when reading the memory card directory (and
+when writing data to the FLASH memory). The banking granularity is 2000h bytes
+(one memory card block), that means that the hardware cannot map Replacement
+Sectors which may be specified in the for Broken Sector List.
4000000h 1E00h Begin of Kernel (usually 1E00h bytes)
+ 4000014h 4 BCD Date in YYYYMMDDh format (19981023h for ALL versions)
+ 4001DFCh 4 Core Kernel Version (usually "C061" or "C110")
+ 4001E00h 2200h Begin of GUI (usually 2200h bytes)
+ 4003FFCh 4 Japanese GUI Version (usually "J061" or "J110")
+FLASH and BIOS ROM seem to be allowed to be read only in 16bit and 32bit units,
+not in 8bit units? Similar restrictions might apply for some I/O ports...? RAM
+can be freely read/written in 8bit, 16bit, and 32bit units.
Unknown if and how many waitstates are applied to the different memory regions.
+The F_WAIT1 and F_WAIT2 registers seem to be somehow waitstate related. FLASH
+memory does probably have a 16bit bus, so 32bit data/opcode fetches might be
+slower then 16bit reads...? Similar delays might happen for other memory and
+I/O regions...?
0-2 Draw mode; seems to turn off bits of the screen;
+ 0: All 32 rows on ;\
+ 1: First 8 rows on ;
+ 2: Second 8 rows on ;
+ 3: Third 8 rows on ; (these are not necessarily all correct?)
+ 4: Fourth 8 rows on ;
+ 5: First 16 rows on ;
+ 6: Middle 16 rows on ;
+ 7: Bottom 16 rows on ;/
+ 3 CPEN (0=Does some weird fade out of the screen, 1=Normal)
+ 4-5 Refresh rate
+ 0: Makes a single blue (yes, blue, yes, on a black/white display)
+ line appear at the top or middle of the screen - don't use!
+ 1: 64Hz? (might be 32Hz too, like 2)
+ 2: 32Hz
+ 3: 16Hz (results in less intensity on black pixels)
+ 6 Display active (0=Off, 1=On)
+ 7 Rotate display by 180 degrees (0=For Handheld Mode, 1=For Docked Mode)
+ 8-31 Unknown (should be zero)
+Upon the reset, the kernel sets LCD_CAL = F_CAL AND 0000003Fh. Aside from that,
+it doesn't use LCD_CAL.
This region consists of 32 words (32bit values),
+
[D000100h]=Top, through [D00017Ch]=Bottom-most scanline
+ Bit0=Left, through Bit31=Right-most Pixel (0=White, 1=Black)
+ 0 Audio Enable enable (0=Off, 1=On)
+ 1-31 Unknown, usually zero
+Unknown how many bits are passed to the D/A converter, probably bit8-15, ie. 8
+bits...?
+
0-7 Probably unused, usually zero (or fractional part when lowered volume)
+ 8-15 Signed Audio Outut Level (usually -7Fh..+7Fh) (probably -80h works too)
+ 16-31 Probably unused, usually sign-expanded from bit15
+ Bit Type Meaning
+ 0 IRQ Button Fire (0=Released, 1=Pressed)
+ 1 IRQ Button Right (0=Released, 1=Pressed)
+ 2 IRQ Button Left (0=Released, 1=Pressed)
+ 3 IRQ Button Down (0=Released, 1=Pressed)
+ 4 IRQ Button Up (0=Released, 1=Pressed)
+ 5 ? Unknown? (?)
+ 6 FIQ (!) COM ;for the COM_registers? (via /SEL Pin?)
+ 7 IRQ Timer 0
+ 8 IRQ Timer 1
+ 9 IRQ RTC (square wave) (usually 1Hz) (when RTC paused: 4096Hz)
+ 10 IRQ Battery Low (0=Normal, 1=Battery Low)
+ 11 IRQ Docked ("IOP") (0=Undocked, 1=Docked to PSX) (via VCC Pin?)
+ 12 IRQ Infrared Rx
+ 13 FIQ (!) Timer 2
+ 14-15 N/A Not used
+ INT_MASK_SET Enable Interrupt Flags (0=No change, 1=Enable) (W)
+ INT_MASK_CLR Disable Interrupt Flags (0=No change, 1=Disable) (W)
+ INT_MASK_READ Current Interrupt Enable Flags (0=Disabled, 1=Enabled) (R)
+ INT_LATCH Latched Interrupt Requests (0=None, 1=Interrupt Request) (R)
+ INT_ACK Clear Interrupt Requests (0=No change, 1=Acknowledge) (W)
+ATTENTION: The GUI doesn't acknowledge Fire Button interrupts on wakeup... so,
+it seems as if button interrupts are NOT latched... ie. the button "INT_LATCH"
+bits seem to be just an unlatched mirror of the "INT_INPUT" bits... that might
+also apply for some other interrupt...?
+However, after wakeup, the gui does DISABLE the Fire Button interrupt, MAYBE
+that does automatically acknowledge it... in that case it might be latched...?
Reading outside the readable region (that is where exactly?) seems to mirror to
+0A000008h. Enabling IRQs for the buttons seems to make it impossible to poll
+them... is that really true?
INT_INPUT.7 Timer 0 IRQ ;used as 30Hz frame rate IRQ by GUI
+ INT_INPUT.8 Timer 1 IRQ ;used as Audio square wave IRQ by GUI
+ INT_INPUT.13 Timer 2 FIQ (this one via FIQ vector, not IRQ vector)
+ INT_INPUT.9 RTC IRQ (usually 1Hz) (or 4096Hz when RTC paused)
+ 0-15 Reload Value (when timer becomes less than zero)
+ 0-15 Current value (decrementing)
+ 0-1 Timer Divider (0=Div2, 1=Div32, 2=Div512, 3=Div2 too)
+ 2 Timer Enable (0=Stop, 1=Decrement)
+ 3-15 Unknown (should be zero)
+ 0 Pause RTC (0=Run/1Hz, 1=Pause/4096Hz)
+ 1-3 Select value to be modified via RTC_ADJUST
+ 4-31 Not used?
+ 00h = Second ;\
+ 01h = Minute ;
+ 02h = Hour ; used in combination with RTC_ADJUST
+ 03h = Day of Week ; while RTC is paused
+ 04h = Day ;
+ 05h = Month ;
+ 06h = Year ;/
+ 07h = Unknown ;-usually used when RTC isn't paused
+Writing a value here seems to increment the current selected parameter (by the
+RTC control). What is perhaps (?) clear is that you have to wait for the RTC
+interrupt signal to go low before writing to this.
0-7 Seconds (00h..59h, BCD)
+ 8-15 Minutes (00h..59h, BCD)
+ 16-23 Hours (00h..23h, BCD)
+ 24-31 Day of week (1=Sunday, ..., 7=Saturday)
+ 0-7 Day (01h..31h, BCD)
+ 8-11 Month (01h..12h, BCD)
+ 16-23 Year (00h..99h, BCD)
+ 24-31 Unknown? (this is NOT used as century)
+The BIOS doesn't contain any IR functions (aside from doing some basic
+initialization and power-down stuff).
+IR is used in Final Fantasy 8's Chocobo World (press Left/Right in the Map
+screen to go to the IR menu), and in Metal Gear Solid Integral (Press Up in the
+main screen), and in PDA Remote 1 & 2 (one-directional TV remote control).
0 Transfer Direction (0=Receive, 1=Transmit)
+ 1 Disable IRDA (0=Enable, 1=Disable)
+ 2 Unknown (reportedly IR_SEND_READY, uh?)
+ 3 Unknown (reportedly IR_RECV_READY, uh?)
+ 4-31 Unknown (should be zero)
+ 0 Transmit Data in Send Direction (0=LED Off, 1=LED On)
+ 1-31 Unknown (should be zero)
+Unknown? Reportedly reserved.
Seems to get triggered on raising or falling (?) edges of incoming data. The
+interrupt handler seems to read the current counter value from one of the
+timers (usually Timer 2, with reload=FFFFh) to determine the length of the
+incoming IR pulse.
Mind that IR hardware usually adopts itself to the normal light conditions, so
+if it receives an IR signal for a longer period, then it may treat that as the
+normal light conditions (ie. as "OFF" state). To avoid that, one would usually
+send a group of ON-OFF-ON-OFF pulses, instead of sending a single long ON
+pulse:
+
___------------------___ One HIGH bit send as SINGLE-LONG-ON pulse (BAD)
+ ___-_-_-_-_-_-_-_-_-____ One HIGH bit send as MULTIPLE-ON-OFF pulses (OK)
+Reportedly, Bit4 of Port 0D80000Ch (IOP_DATA) is also somewhat IR related...?
0-31 Unknown
+ 00000000h Used when disabling all virtual flash banks
+ 00000001h Used before setting new virtual bank values
+ 00000002h Used after setting virtual bank enable bits
+ 03h Replace ROM at 00000000h by RAM (used after reset)
+ 0-31 Unknown
+ 0-15 Enable physical banks 0..15 in virtual region (0=Disable, 1=Enable)
+ 16-31 Unknown (should be zero)
+This region contains 16 words, the first word at 06000100h for physical bank 0,
+the last word at 0600013Ch for physical bank 15. Each word is:
+
0-3 Virtual bank number
+ 4-31 Should be 0
+ 0..3 Unknown/not tested
+ 4 hangs hardware? but that bit is used in some cases!
+ 5..31 Unknown/not tested
+ F_WAIT1=00000000h when CPU Speed = 00h..07h
+ F_WAIT1=00000010h when CPU Speed = 08h..0Fh
+ 0 no effect? but that bit is used in some cases! maybe write-enable?
+ 1 hangs hardware?
+ 2 no effect? READ: indicates 0=write-busy, 1=ready? (R)
+ 3 hangs hardware?
+ 4 makes FLASH slower?
+ 5 makes WRAM and F_xxx as slow as other memory (0=1 cycle, 1=2 cycles)
+ 6 hangs hardware? but that bit is used in some cases!
+ 7 no effect?
+ 8..31 Unknown/not tested
+ F_WAIT2=00000000h when CPU Speed = 00h..07h ;\same as F_WAIT1
+ F_WAIT2=00000010h when CPU Speed = 08h..0Fh ;/
+ F_WAIT2=00000021h ;SWI 10h, FlashWritePhysical(sector,src)
+ F_WAIT2=00000041h ;SWI 0Fh, FlashWriteSerial(serial_number)
+ wait until reading returns F_WAIT2.Bit2 = 1
+ and then set F_WAIT2=00000000h
+Unlocks FLASH memory for writing. The complete flowchart for writing sector
+data (or header values) is:
+
if write_sector ;\
+ F_WAIT2=00000021h ; write enable or so
+ if write_header ;
+ F_WAIT2=00000041h ;/
+ [80055AAh]=FFAAh ;\
+ [8002A54h]=FF55h ; unlock flash
+ [80055AAh]=FFA0h ;/
+ if write_sector ;\
+ for i=0 to 3Fh ;
+ [8000000h+sector*80h+i*2]=src[i*2] ; write data
+ if write_header ;
+ [8000000h]=new F_SN_LO value ;
+ [8000002h]=new F_SN_HI value ;
+ [8000008h]=new F_CAL value ;/
+ first, wait 4000 clock cycles ;\wait
+ then, wait until F_WAIT2.Bit2=1 ;/
+ F_WAIT2=00000000h ;-write disable or so
+ 0-15 Data
+Observe that the physical_bank number (p) is used as array index, and that the
+virtual bank number (v) is stored in that location, ie. table[p]=v, which is
+unlike as one may have expected it (eg. on a 80386 CPU it'd be vice-versa:
+table[v]=p).
+Due to the table[p]=v assignment, a physical block cannot be mirrored to
+multiple virtual blocks, instead, multiple physical blocks can be mapped to the
+same virtual block (unknown what happens in that case, maybe the data becomes
+ANDed together).
0 Data Output Enable (0=None/HighZ, 1=Output Data Bits)
+ 1 /ACK Output Level (0=None/HighZ, 1=Output LOW)
+ 2 Unknown (should be set when expecting a NEW command...?)
+ 3-31 Unknown (should be zero)
+ 0-7 Data (Write: to be transmitted to PSX, Read: been received from PSX)
+ 8-31 Unknown
+ 0 Unknown
+ 1 Error flag or so (0=Okay, 1=Error)
+ 2-31 Unknown
+ 0 Ready flag (0=Busy, 1=Ready) (when 8bits have been transferred)
+ 1-31 Unknown
+ 0 Unknown (should be set AT BEGIN OF A NEW command...?)
+ 1 Unknown (0=Disable something, 1=Enable something)
+ 2-31 Unknown (should be zero)
+ 00000000h = unknown? disable
+ 00000002h = unknown? enable
+ 00000003h = unknown? at BEGIN of a new command
+ 0 Unknown (should be set, probably starts or acknowledges something)
+ 1 Unknown (should be set when expecting a NEW command...?)
+ 2-31 Unknown (should be zero)
+ 00000001h = unknown? used before AND after each byte-transfer
+ 00000003h = unknown? used after LAST byte of command (and when init/reset)
+ (via FIQ vector, not IRQ vector)
+Probably senses the voltage on the cartridge slots VCC Pin. Becomes zero when
+Undocked (and probably also when the PSX is switched off).
+The Kernel uses IRQ-11 for BOTH sensing docking and undocking, ie. as if the
+IRQ would be triggered on both 0-to-1 and 1-to-0 transistions... though maybe
+that feature just relies on switch-bounce. For the same reason (switch bounce),
+the IRQ-11 handler performs a delay before it checks the new INT_INPUT.11
+setting (ie. the delay skips the unstable switch bound period, and allows the
+signal to stabilize).
The BIOS adjusts this bit somehow in relation to communication. Unknown
+when/why/how it must be used. For details on IOP_START/IOP_STOP see Power
+Control chapter.
This opcode is used by the SN Systems emulator to write chr(r0) to a TTY style
+text window. r0 can be ASCII characters 20h and up, or 0Ah for CRLF. Using that
+opcode is a not too good idea because the default BIOS undef instruction
+handler simply runs into an endless loop, so games that are using it (eg.
+Break-Thru by Jason) won't work on real hardware. That, unless the game would
+change the undef instruction vector at [04h] in Kernel RAM, either replacing it
+by a MOVS R15,R14 opcode (ignore exception and return to next opcode), or by
+adding exception handling that outputs the character via IR or via whatever
+cable connection. Observe that an uninitialized FUNC3 accidently destroys
+[04h], so first init FUNC3 handler via SWI 17h, before trying to change [04h],
+moreover, mind that SWI 05h may reset FUNC3, causing the problem to reappear.
+Altogether, it'd be MUCH more stable to write TTY characters to an unused I/O
+port... only problem is that it's still unknown which I/O ports are unused...
+ie. which do neither trap data aborts, nor do mirror to existing ports...?
0-3 Clock Ratio (01h..08h, see below) (usually 7 = 3.99MHz) (R/W)
+ 4 Clock Change State (0=Busy, 1=Ready) (Read-only)
+ 5-15 ?
+ 00h = hangs hardware ;-don't use
+ 01h = 0.063488 MHz ;\
+ 02h = 0.126976 MHz ;
+ 03h = 0.253952 MHz ; 31*8000h / 1,2,4,8,16
+ 04h = 0.507904 MHz ;
+ 05h = 1.015808 MHz ;/
+ 06h = 1.998848 MHz ;\
+ 07h = 3.997696 MHz ; 61*8000h * 1,2,4
+ 08h = 7.995392 MHz ;/
+ 09h..0Fh = same as 08h ;-aliases
+Stops the CPU until an interrupt occurs. The pocketstation doesn't have a
+power-switch nor standby button, the closest thing to switch "power off" is to
+enter sleep mode. Software should do that when the user hasn't pressed buttons
+for 1-2 seconds (that, only in handheld mode, not when docked to the PSX; where
+it's using the PSX power supply instead of the battery).
+
0 Stop Clock (1=Stop)
+ 1-15 ?
+ DAC_CTRL=0 ;\disable sound
+ IOP_STOP=20h ;/
+ LCD_MODE=0 ;-disable video
+ IRDA=whatever ;-disable infrared (if it was used)
+ BATT_CTRL=BATT_CTRL AND FFFFFFFCh ;-do whatever
+ INT_MASK_SET=801h ;-enable Docking/Fire wakeup interrupts
+ 0-3 Probably Direction for IOP_DATA bit0..3 (0=Input, 1=Output)
+ 4-31 Unknown/Unused (seems to be always zero)
+These two ports are probably accessing a single register, writing "1" bits to
+IOP_STOP sets bits in that register, and writing "1" bits to IOP_START clears
+bits... or vice-versa...? Writing "0" bits to either port seems to leave that
+bits unchanged. The meaning of most bits is still unknown:
+
0 Unknown, STARTED by Kernel upon reset
+ 1 Red LED, Communication related (START=Whatever, STOP=Whatelse) (?)
+ 2 Unknown, STARTED by Kernel upon reset
+ 3 Unknown, STARTED by Kernel upon reset
+ 4 Never STARTED nor STOPPED by BIOS (maybe an INPUT, read via IOP_DATA)
+ 5 Sound Enable (START=On, STOP=Off)
+ 6 Unknown, STOPPED by Kernel upon reset
+ 7-31 Unknown, never STARTED nor STOPPED by BIOS
+ 0 ?
+ 1 Red LED (0=On, 1=Off)
+ 2 ?
+ 3 ?
+ 4 Seems to be always 1 (maybe Infrared input?)
+ 5-31 Unknown/Unused (seems to be always zero)
+Unknown. Somehow battery saving related. Upon reset, and upon leaving sleep
+mode, the BIOS does set BATT_CTRL=00000000h. Before entering sleep mode, it
+does set BATT_CTRL=BATT_CTRL AND FFFFFFFCh, whereas, assuming that BATT_CTRL
+was 00000000h, ANDing it with FFFFFFFCh would simply leave it unchanged...
+unless the hardware (or maybe a game) sets some bits in BATT_CTRL to nonzero
+values...?
INT_INPUT.10 IRQ Battery Low (0=Normal, 1=Battery Low)
+BIOS functions can be called via SWI opcodes (from both ARM and THUMB mode) (in
+ARM mode, the SWI function number is in the lower 8bit of the 24bit field;
+unlike as for example on the GBA, where it'd be in the upper 8bit). Parameters
+(if any) are passed in r0,r1,r2. Return value is stored in r0 (all other
+registers are left unchanged).
+
SWI 00h - Reset() ;don't use out: everything destroyed
+ SWI 01h - SetCallbacks(index,proc) out: old proc
+ SWI 02h - CustomSwi2(r0..r6,r8..r10) out: r0
+ SWI 03h - FlashWriteVirtual(sector,src) out: 0=okay, 1=failed
+ SWI 04h - SetCpuSpeed(speed) out: old_speed
+ SWI 05h - SenseAutoCom() out: garbage
+ SWI 06h - GetPtrToComFlags() out: ptr (usually 0C0h)
+ SWI 07h - ChangeAutoDocking(flags.16-18) out: incoming flags AND 70000h
+ SWI 08h - PrepareExecute(flag,dir_index,param) out: dir_index (new or old)
+ SWI 09h - DoExecute(snapshot_saving_flag) out: r0=r0 (failed) or r0=param
+ SWI 0Ah - FlashReadSerial() out: F_SN
+ SWI 0Bh - ClearComFlagsBit10() out: new [ComFlags] (with bit10=0)
+ SWI 0Ch - SetBcdDateTime(date,time) out: garbage (RTC_DATE/10000h)
+ SWI 0Dh - GetBcdDate() out: date (with century in MSBs)
+ SWI 0Eh - GetBcdTime() out: time and day-of-week
+ SWI 0Fh - FlashWriteSerial(serial_number) out: garbage (r0=0) ;old BIOS only!
+ SWI 10h - FlashWritePhysical(sector,src) out: 0=okay, 1=failed
+ SWI 11h - SetComOnOff(flag) out: garbage retadr to swi handler
+ SWI 12h - TestSnapshot(dir_index) out: 0=normal, 1=MCX1 with 1,0,"SE"
+ SWI 13h - GetPtrToAlarmSetting() out: ptr to alarm_setting
+ SWI 14h - GetPtrToPtrToSwiTable() out: ptr-to-ptr to swi_table
+ SWI 15h - MakeAlternateDirIndex(flag,dir_index) out: alt_dir_index (new/old)
+ SWI 16h - GetDirIndex() out: dir_index (or alternate)
+ SWI 17h - GetPtrToFunc3addr() out: ptr to func3 address
+ SWI 18h - FlashReadWhateverByte(sector) out: [8000000h+sector*80h+7Eh]
+ SWI 19h..FFh - garbage
+ SWI 100h..FFFFFFh - mirrors of SWI 00h..FFh
+ r0=0 Set SWI 02h callback (r1=proc, or r1=0=reset/default)
+ r0=1 Set IRQ callback (r1=proc, or r1=0=none/default)
+ r0=2 Set FIQ callback (r1=proc, or r1=0=none/default)
+ r0=3 Set Download Notification callback (r1=proc, or r1=0=bugged/default)
+Registers r0,r1,r12 are pushed by the kernels FIQ/IRQ handlers (so the
+callbacks can use that registers without needing to push them). The FIQ handler
+can additionally use r8..r11 without pushing them (the CPU uses a separate set
+of r8..r12 registers in FIQ mode, nethertheless, the kernel DOES push r12 in
+FIQ mode, without reason). Available stack is 70h bytes for the FIQ callback,
+and 64h bytes for the IRQ callback.
+The callbacks don't receive any incoming parameters, and don't need to respond
+with a return value. The callback should return to the FIQ/IRQ handler (via
+normal BX r14) (ie. it should not try to return to User mode).
+The kernel IRQ handler does (after the IRQ callback) process IRQ-11 (IOP)
+(which does mainly handle docking/undocking), and IRQ-9 (RTC) (which increments
+the century if the year wrapped from 99h to 00h).
+And the kernel FIQ handler does (before the FIQ callback) process IRQ-6 (COM)
+(which does, if ComFlags.Bit9 is set, handle bu_cmd's) (both IRQs and FIQs are
+disabled, and the main program is stopped until the bu_cmd finishes, or until a
+joypad command is identified irrelevant, among others that means that
+sound/timer IRQs aren't processed during that time, so audio output may become
+distorted when docked).
+When docked, the FIQ callback should consist of only a handful of opcodes, eg.
+it may contain a simple noise, square wave generator, or software based sound
+"DMA" function, but it should not contain more time-consuming code like sound
+envelope processing; otherwise IRQ-6 (COM) cannot be executed fast enough to
+handle incoming commands.
Calls the SWI2 callback function (which can be set via SWI 01h). The default
+callback address is 00000000h (so, by default, it behaves identically as SWI
+00h). Any parameters can be passed in r0..r6 and r8..r10 (the other registers
+aren't passed to the callback function). Return value can be stored in r0 (all
+other registers are pushed/popped by the swi handler, as usually). Available
+space on the swi stack is 38h bytes.
+SWI2 can be useful to execute code in privileged mode (eg. to initialize FIQ
+registers r8..r12 for a FIQ based sound engine) (which usually isn't possible
+because the main program runs in non-privileged user mode).
Changes the CPU speed. The BIOS uses it with values in range 01h..07h. Unknown
+if value 00h can be also used? The function also handles values bigger than
+07h, of which, some pieces of BIOS code look as if 08h would be the maximum
+value...?
+Before setting the new speed, the function sets F_WAIT1 and F_WAIT2 to
+00000000h (or to 00000010h if speed.bit3=1). After changing the speed (by
+writing the parameter to CLK_MODE) it does wait until the new speed is applied
+(by waiting for CLK_MODE.bit4 to become zero). The function returns the old
+value of CLK_MODE, anded with 0Fh.
Communication (aka BU Commands, received from the PSX via the memory card slot)
+can be handled by the pocketstations kernel even while a game is running.
+However, communications are initially disabled when starting a game, so the
+game should enable them via SWI 11h, and/or via calling SWI 05h once per frame.
Can be used to enable/disable communication. When starting an executable,
+communication is initially disabled, so it'd be a good idea to enable them
+(otherwise the PSX cannot communicate with the Pocketstation while the game is
+running).
+When flag=0, disables communication: Intializes the COM_registers, disables
+IRQ-6 (COM), and clears ComFlags.9. When flag=1, enables communication:
+Intializes the COM_registers, enables IRQ-6 (COM), sets ComFlags.9 (when
+docked), or clears Sys.Flags.9 (when undocked), and sets FAST cpu_speed=7 (only
+when docked). The function returns garbage (r0=retadr to swi_handler).
Returns a pointer to the ComFlags word in RAM, which contains several
+communication related flags (which are either modified upon docking/undocking,
+or upon receiving certain bu_cmd's). The ComFlags word consists of the
+following bits:
+
0-3 Whatever (set/cleared when docked/undocked, and modified by bu_cmd's)
+ 4-7 Not used (should be zero)
+ 8 IRQ-11 (IOP) occurred (set by irq handler, checked/cleared by SWI 05h)
+ 9 Communication Enabled And Docked (0=No, 1=Yes; prevents DoExecute)
+ 10 Reject writes to Broken Sector Region (sector 16..55) (0=No, 1=Yes)
+ 11 Start file request (set by bu_cmd_59h, processed by GUI, not by Kernel)
+ 12-15 Not used (should be zero)
+ 16 Automatically power-down DAC audio on insert/removal (0=No, 1=Yes)
+ 17 Automatically power-down IRDA infrared on insert/removal (0=No, 1=Yes)
+ 18 Automatically adjust LCD screen rotate on insert/removal (0=No, 1=Yes)
+ 19-27 Not used (should be zero)
+ 28 Indicates if a standard bu_cmd (52h/53h/57h) was received (0=No, 1=Yes)
+ 29 Set date/time request (set by bu_cmd FUNC0, processed by BIOS)
+ 30 Destroy RTC and Start GUI request (set by bu_cmd_59h, dir_index=FFFEh)
+ 31 Not used (should be zero)
+ 0-15 Not used (should be zero)
+ 16 Automatically power-down DAC audio on insert/removal (0=No, 1=Yes)
+ 17 Automatically power-down IRDA infrared on insert/removal (0=No, 1=Yes)
+ 18 Automatically adjust LCD screen rotate on insert/removal (0=No, 1=Yes)
+ 19-31 Not used (should be zero)
+Resets ComFlags.Bit10, ie. enables bu_cmd_57h (write_sector) to write to the
+Broken Sector region in FLASH memory (sector 16..55). SWI 0Bh returns the
+current ComFlags value (the new value, with bit10=0).
+Aside from calling SWI 0Bh, ComFlags.10 is also automatically cleared upon
+IRQ-10 (IOP) (docking/undocking). ComFlags.10 can get set/cleared by the
+Download Notification callback.
Checks if docking/undocking has occurred (by examining ComFlags.8, which gets
+set by the kernel IRQ-11 (IOP) handler). If that flag was set, then the
+function does reset it, and does then reset FUNC3=0000h and [0CAh]=00h (both
+only if docked, not when undocked), and, no matter if docked or undocked, it
+enables communication; equivalent to SetComOnOff(1); which sets/clears
+ComFlags.9. The function returns garbage (r0=whatever).
+The GUI is calling SWI 05h once per frame. The overall purpose is unknown. It's
+a good idea to reset FUNC3 and to Enable Communication (although that'd be
+required only when docked, not when undocked), but SWI 05h is doing that only
+on (un-)docking transitions (not when it was already docked). In general, it'd
+make more sense to do proper initializations via SWI 11h and SWI 17h as than
+trusting SWI 05h to do the job. The only possibly useful effect is that SWI 05h
+does set/clear ComFlags.9 when docked/undocked.
Returns a pointer to a halfword in RAM which contains the FUNC3 address (for
+bu_cmd_5bh and bu_cmd_5ch). The address is only 16bit, originated at 02000000h
+in FLASH (ie. it can be only in the first 64K of the file), bit0 can be set for
+THUMB code. The default address is zero, which behaves bugged: It accidently
+sets [00000004h]=00000000h, ie. replaces the Undefined Instruction exception
+vector by a "andeq r0,r0,r0" opcode, due to that NOP-like opcode, any Undefined
+Instruction exceptions will run into the SWI vector at [00000008h], and
+randomly execute an SWI function; with some bad luck that may execute one of
+the FlashWrite functions and destroy the saved files.
+Although setting 0000h acts bugged, one should restore that setting before
+returning control to GUI or other executables; otherwise the address would
+still point to the FUNC3 address of the old unloaded executable, which is worse
+than the bugged effect.
+The FUNC3 address is automatically reset to 0000h when (if) SWI 05h
+(SenseAutoCom) senses new docking.
Can be used to mute sound during communication, see SWI 01h,
+SetCallbacks(index,proc), and BU Command 5Dh for details.
dir_index should be 0=GUI, or 1..15=First block of game. When calling
+DoExecute, param is passed to the entrypoint of the game or GUI in r0 register
+(see notes on GUI \<param> values belows). For games, param may be
+interpreted in whatever way.
+When flag=0, the function simply returns the old dir_index value. When flag=1,
+the new dir_index and param values are stored in Kernel RAM (for being used by
+DoExecute); the values are stored only if dir_index=0 (GUI), or if dir_index
+belongs to a file with "SC" and "MCX0" or "MCX1" IDs in it's title sector. If
+dir_index was accepted, then the new dir_index value is returned, otherwise the
+old dir_index is returned.
PrepareExecute(1,0,param) prepares to execute the GUI (rather than a file).
+When executing the GUI, \<param> consists of the following destructive
+bits:
+
0-7 Command number (see below, MSBs=Primary command, LSBs=another dir_index)
+ 8 Do not store Alarm setting in Kernel RAM (0=Normal, 1=Don't store)
+ 9-31 Not used (should be zero)
+ Command 0xh --> Erase RTC time/date
+ Command 1xh --> Enter GUI Time Screen with speaker symbol
+ Command 20h --> Enter GUI Time Screen with alarm symbol
+ Command 2xh --> Prompt for new Date/Time, then start dir_index (x)
+ Command 3xh --> Enter GUI File Selection Screen, with dir_index (x) selected
+ Command xxh --> Erase RTC time/date (same as Command 0xh)
+Allows to return control to the GUI (when dir_index=0), or to start an
+executable (when dir_index=1..15). Prior to calling DoExecute, parameters
+should be set via PrepareExecute(1,dir_index,param), when not doing that,
+DoExecute would simply restart the current executable (which may be a desired
+effect in some cases).
+The "snapshot_saving_flag" can be ommited for normal (MCX0) files, that
+parameter is used only for special (MCX1) files (see Snapshot Notes for
+details).
+Caution: DoExecute fails (and returns r0=unchanged) when ComFlags.9=1 (which
+indicates that communications are enabled, and that the Pocketstation is
+believed to be docked to the PSX). ComFlags.9 can be forcefully cleared by
+calling SetComOnOff(0), or it can be updated according to the current
+docking-state by calling SetComOnOff(1) or SenseAutoCom().
Returns the dir_index for the currently executed file. If that value is zero,
+ie. if there is no file executed, ie. if the function is called by the GUI,
+then it does instead return the "alternate" dir_index (as set via SWI 15h).
Applies the specified dir_index as "alternate" dir_index (for being retrieved
+via SWI 16h for whatever purpose). The dir_index is applied only when flag=1,
+and only if dir_index is 0=none, or if it is equal to the dir_index of the
+currently executed file (ie. attempts to make other files being the "alternate"
+one are rejected). If successful, the new dir_index is returned, otherwise the
+old dir_index is returned (eg. if flag=0, or if the index was rejected).
Tests if the specified file contains a load-able snapshot, ie. if it does have
+the "SC" and "MCX1" IDs in the title sector, and the 01h,00h,"SE" ID in the
+snapshot header. If so, it returns r0=1, and otherwise returns r0=0.
Snapshots are somewhat automatically loaded/saved when calling DoExecute:
+If the old file (the currently executed file) contains "SC" AND "MCX1" IDs in
+the title sector, then the User Mode CPU registers and User RAM at 200h..7FFh
+are automatically saved in the files snapshot region in FLASH memory, with the
+snapshot_saving_flag being applied as bit0 of the 0xh,00h,"SE" ID of the
+snapshot header).
+If the new file (specified in dir_index) contains load-able snapshot data (ie.
+if it has "SC" and "MCX1" IDs in title sector, and 01h,00h,"SE" ID in the
+snapshot region), then the BIOS starts the saved snapshot data (instead of
+restarting the executable at its entrypoint). Not too sure if that feature is
+really working... the snapshot loader seems to load User RAM from the wrong
+sectors... and it seems to jump directly to User Mode return address... without
+removing registers that are still stored on SWI stack... causing the SWI stack
+to underflow after loading one or two snapshots...?
Sets the time and date, the parameters are having the same format as SWI 0Dh
+and SWI 0Eh return values (see there). The SWI 0Ch return value contains only
+garbage (r0=RTC_DATE/10000h).
0-7 Day (01h..31h, BCD)
+ 8-11 Month (01h..12h, BCD)
+ 16-31 Year (0000h..9999h, BCD)
+ 0-7 Seconds (00h..59h, BCD)
+ 8-15 Minutes (00h..59h, BCD)
+ 16-23 Hours (00h..23h, BCD)
+ 24-31 Day of week (1=Sunday, ..., 7=Saturday)
+Returns a pointer to a 64bit value in Kernel RAM, the upper word (Bit32-63)
+isn't actually used by the BIOS, except that, the bu_cmd FUNC3 does transfer
+the whole 64bits. The meaning of the separate bits is:
+
0-7 Alarm Minute (00h..59h, BCD)
+ 8-15 Alarm Hour (00h..23h, BCD)
+ 16 Alarm Enable (0=Off, 1=On)
+ 17 Button Lock (0=Normal, 1=Lock) (pressing all 5 buttons in GUI)
+ 18-19 Volume Shift (0=Normal/Loud, 1=Medium/Div4, 2=Mute/Off)
+ 20-22 Not used (should be zero)
+ 23 RTC Initialized (0=Not yet, 1=Yes, was initialized from within GUI)
+ 24-31 Not used (should be zero)
+ 32-63 Pointer to 8x8 BIOS Charset (characters "0"..."9" plus strange symbols)
+ CHR(00h..09h) = Digits "0..9"
+ CHR(0Ah) = Space " "
+ CHR(0Bh) = Colon ":"
+ CHR(0Ch) = Button Lock (used by Final Fantasy 8's Chocobo World)
+ CHR(0Dh) = Speaker Medium; or loud if followed by chr(0Eh)
+ CHR(0Eh) = Speaker Loud; to be appended to chr(0Dh)
+ CHR(0Fh) = Speaker Off
+ CHR(10h) = Battery Low (used by PocketMuuMuu's Cars)
+ CHR(11h) = Alarm Off
+ CHR(12h) = Alarm On
+ CHR(13h) = Memory Card symbol
+Writes 80h-bytes at src to the physical sector number (0..3FFh, originated at
+08000000h), and does then compare the written data with the source data.
+Returns 0=okay, or 1=failed.
The sector number (0..3FFh) is a virtual sector number (originated at
+02000000h), the function uses the F_BANK_VAL settings to translate it to a
+physical sector number, and does then write the 80h-bytes at src to that
+location (via the FlashWritePhysical function). Returns 0=okay, or 1=failed (if
+the write failed, or if the sector number exceeded the filesize aka the
+virtually mapped memory region).
Returns the 32bit value from the two 16bit F_SN registers (see F_SN for
+details).
Changes the 32bit F_SN value in the "header" region of the FLASH memory. The
+function also rewrites the F_CAL value (but it simply rewrites the old value,
+so it's left unchanged). The function isn't used by the BIOS, no idea if it is
+used by any games. No return value (always returns r0=0).
+This function is supported by the old "061" version BIOS only (the function is
+padded with jump opcodes which hang the CPU in endless loops on newer "110"
+version).
Returns [8000000h+sector*80h+7Eh] AND 00FFh. Purpose is totally unknown... the
+actual FLASH memory doesn't contain any relevant information at that locations
+(eg. the in the directory sectors, that byte is unused, usually zero)... and,
+reading some kind of status or manufacturer information would first require to
+command the hardware to output that info...?
Reboots the pocketstation, similar as when pressing the Reset button. Don't
+use! The BIOS bootcode does (without any good reason) reset the RTC registers
+and alarm/century settings in RAM to Time 00:00:00, Date 01 Jan 1999, and Alarm
+00:00 disabled, so, after reset, the user would need to re-enter these values.
+Aside from the annoying destroyed RTC settings, the function is rather
+unstable: it does jump to address 00000000h in RAM, which should usually
+redirect to 04000000h in ROM, however, most pocketstation games are programmed
+in C language, where "pointer" is usually pronounced "pointer?" without much
+understanding of whether/why/how to initialize that "strange things", so
+there's a good probability that one of the recently executed games has
+accidently destroyed the reset vector at [00000000h] in battery-backed RAM.
Returns a pointer to a word in RAM, which contains another pointer which
+usually points to SWI table in ROM. Changing that word could be (not very)
+useful for setting up a custom SWI table in FLASH or in RAM. When doing that,
+one must restore the original setting before returning control to the GUI or to
+another executable (the setting isn't automatically restored).
The default SWI service routine is slightly finicky
+
push {r1-r12, lr} @ Backup SVC-mode registers
+mrs r12, spsr @ Old CPSR in r12
+nop
+
+@ Check if we were previously in Thumb mode
+@ And adjust LR accordingly to fetch the SWI comment field
+tst r12, #0x20
+subeq lr, #2
+sub lr, #2
+
+@ Fetch the comment field
+ldrh r12, [lr]
+and r12, #0xFF
+
+@ Load function pointer for SWI handler and call it
+mov lr, #0xE0 ; Pointer to SWI table in LR
+ldr r11, [lr]
+add r11, r11, r12, lsl #2 @ r11 = &swi_table[comment]
+ldr r11, [r11] @ Get function pointer
+mov lr, pc @ Set LR to return address
+bx r11 @ Call SWI handler
+
+@ Restore SVC regs, return from SWI service routine and restore SPSR into CPSR
+pop {r1-r12, pc}^
+ldrb. Any custom handler needs to do the same, otherwise it won't work on real hardware. Also, for emulator developers, be wary of the last pop as it abuses an ldm edge case (S bit set with r15 in rlist - restores registers properly and then does CPSR = SPSR)The Pocketstation supports the standard Memory Card commands (Read Sector,
+Write Sector, Get Info), plus a couple of special commands.
50h Change a FUNC 03h related value or so
+ 51h N/A
+ 52h Standard Read Sector command
+ 53h Standard Get ID command
+ 54h N/A
+ 55h N/A
+ 56h N/A
+ 57h Standard Write Sector command
+ 58h Get an ID or Version value or so
+ 59h Prepare File Execution with Dir_index, and Parameter
+ 5Ah Get Dir_index, ComFlags, F_SN, Date, and Time
+ 5Bh Execute Function and transfer data from Pocketstation to PSX
+ 5Ch Execute Function and transfer data from PSX to Pocketstation
+ 5Dh Execute Custom Download Notification Function ;via SWI 01h with r0=3
+ 5Eh Get-and-Send ComFlags.bit1,3,2
+ 5Fh Get-and-Send ComFlags.bit0
+ FUNC 00h - Get or Set Date/Time
+ FUNC 01h - Get or Set Memory Block
+ FUNC 02h - Get or Set Alarm/Flags
+ FUNC 03h - Custom Function 3 ;via SWI 17h, GetPtrToFunc3addr()
+ FUNC 80h..FFh - Custom Functions 80h..FFh ;via Function Table in File Header
+For general info on the three standard memory card commands (52h, 53h, 57h),
+and for info on the FLAG response value, see:
+Memory Card Read/Write Commands
Works much as on normal memory cards, except that, on the Pocketstation, the
+Read Sector command return 00h as dummy values; instead of the "(pre)" dummies
+that occur on normal memory cards.
+The Read Sector command does reproduce the strange delay (that occurs between
+5Ch and 5Dh bytes), similar as on normal original Sony memory cards, maybe
+original cards did (maybe) actually DO something during that delay period, the
+pocketstation BIOS simply blows up time in a wait loop (maybe for compatibility
+with original cards).
The Get ID command (53h) returns exactly the same values as normal original
+Sony memory cards.
The Write Sector command has two new error codes (additonally to the normal
+47h="G"=Good, 4Eh="N"=BadChecksum, FFh=BadSector responses). The new error
+codes are (see below for details):
+
FDh Reject write to Directory Entries of currently executed file
+ FEh Reject write to write-protected Broken Sector region (sector 16..55)
+The FDh error code is intended to prevent the PSX bootmenu (or other PSX games)
+to delete the currently executed file (which would crash the pocketstation -
+once when the deleted region gets overwritten by a new file), because the PSX
+bootmenu and normal PSX games do not recognize the new FDh error code the
+pocketstation does additionally set FLAG.3 (new card), which should be
+understood by all PSX programs.
+The FDh error code occurs only on directory sectors of the file (not on its
+data blocks). However, other PSX games should never modify files that belong to
+other games (so there should be no compatibility problem with other PSX
+programs that aren't aware of the file being containing currently executed
+code).
+However, the game that has created the executable pocketstation file must be
+aware of that situation. If the file is broken into a Pocketstation Executable
+region and a PSX Gameposition region, then it may modify the Gameposition stuff
+even while the Executable is running. If the PSX want to overwrite the
+executable then it must first ensure that it isn't executed (eg. by retrieving
+the dir_index of the currently executed file via BU Command 5Ah, and comparing
+it against the first block number in the files FCB at the PSX side; for file
+handle "fd", the first block is found at "[104h]+fd*2Ch+24h" in PSX memory).
The write-protection is enabled by ComFlags.bit10 (which can be set/cleared via
+BU Command 5Dh). That bit should be set before writing Pocketstation
+excecutables (the Virtual Memory banking granularity is 2000h bytes, which
+allows to map whole blocks only, but cannot map single sectors, which would be
+required for files with broken sector replacements).
+Unlike Error FDh, this error code doesn't set FLAG.3 for notifying normal PSX
+programs about the error (which is no problem since normally Error FEh should
+never occur since ComFlags.10 is usually zero). For more info on ComFlags.10,
+see SWI 0Bh aka ClearComFlagsBit10(), and BU Command 5Dh.
Send Reply Comment
+ 81h N/A Memory Card Access
+ 50h FLAG Send Command 50h
+ VAL 00h Send new [0CAh], receive length of following data (00h)
+ Send Reply Comment
+ 81h N/A Memory Card Access
+ 58h FLAG Send Command 58h
+ (0) 02h Send dummy/zero, receive length of following data (02h)
+ (0) 01h Send dummy/zero, receive whatever value (01h)
+ (0) 01h Send dummy/zero, receive another value (01h)
+ Send Reply Comment
+ 81h N/A Memory Card Access
+ 59h FLAG Send Command 59h
+ (0) 06h Send dummy/zero, receive length of following data (06h)
+ NEW OLD Send new dir_index.8-15, receive old dir_index.8-15
+ NEW OLD Send new dir_index.0-7, receive old dir_index.0-7
+ PAR (0) Send exec_parameter.0-7, receive dummy/zero
+ PAR (0) Send exec_parameter.8-15, receive dummy/zero
+ PAR (0) Send exec_parameter.16-23, receive dummy/zero
+ PAR (0) Send exec_parameter.24-31, receive dummy/zero
+ 0000h..000Fh --> Request to Start GUI or File (with above parameter bits)
+ 0010h..FFFDh --> Not used, acts same as FFFFh (see below)
+ FFFEh --> Request to Destroy RTC and Start GUI (with parameter 00000000h)
+ FFFFh --> Do nothing (transfer all bytes, but don't store the new values)
+ Send Reply Comment
+ 81h N/A Memory Card Access
+ 5Ah FLAG Send Command 5Ah
+ (0) 12h Send dummy/zero, receive length of following data (12h)
+ (0) INDX Send dummy/zero, receive curr_dir_index.bit8-15 (00h)
+ (0) INDX Send dummy/zero, receive curr_dir_index.bit0-7 (00h..0Fh)
+ (0) FLG Send dummy/zero, receive ComFlags.bit0 (00h or 01h)
+ (0) FLG Send dummy/zero, receive ComFlags.bit1 (00h or 01h)
+ (0) FLG Send dummy/zero, receive ComFlags.bit3 (00h or 01h)
+ (0) FLG Send dummy/zero, receive ComFlags.bit2 (00h or 01h)
+ (0) SN Send dummy/zero, receive F_SN.bit0-7 (whatever)
+ (0) SN Send dummy/zero, receive F_SN.bit8-15 (whatever)
+ (0) SN Send dummy/zero, receive F_SN.bit16-23 (whatever)
+ (0) SN Send dummy/zero, receive F_SN.bit24-31 (whatever)
+ (0) DATE Send dummy/zero, receive BCD Day (01h..31h)
+ (0) DATE Send dummy/zero, receive BCD Month (01h..12h)
+ (0) DATE Send dummy/zero, receive BCD Year (00h..99h)
+ (0) DATE Send dummy/zero, receive BCD Century (00h..99h)
+ (0) TIME Send dummy/zero, receive BCD Second (00h..59h)
+ (0) TIME Send dummy/zero, receive BCD Minute (00h..59h)
+ (0) TIME Send dummy/zero, receive BCD Hour (00h..23h)
+ (0) TIME Send dummy/zero, receive BCD Day of Week (01h..07h)
+ Send Reply Comment
+ 81h N/A Memory Card Access
+ 5Eh FLAG Send Command 5Eh
+ (0) 03h Send dummy/zero, receive length of following data (03h)
+ NEW OLD Send new ComFlags.bit1, receive old ComFlags.bit1 (00h or 01h)
+ NEW OLD Send new ComFlags.bit3, receive old ComFlags.bit3 (00h or 01h)
+ NEW OLD Send new ComFlags.bit2, receive old ComFlags.bit2 (00h or 01h)
+ Send Reply Comment
+ 81h N/A Memory Card Access
+ 5Fh FLAG Send Command 5Fh
+ (0) 01h Send dummy/zero, receive length of following data (01h)
+ NEW OLD Send new ComFlags.bit0, receive old ComFlags.bit0 (00h or 01h)
+ Send Reply Comment
+ 81h N/A Memory Card Access
+ 5Bh FLAG Send Command 5Bh
+ FUNC FFh Send Function Number, receive FFh (indicating variable length)
+ (0) LEN1 Send dummy/zero, receive length of parameters (depending on FUNC)
+ ... (0) Send parameters (LEN1 bytes), and receive dummy/zero
+ <-------- at this point, the function is executed for the first time
+ (0) LEN2 Send dummy/zero, receive length of data (depending on FUNC)
+ (0) ... Send dummy/zero, receive data (LEN2 bytes) from pocketstation
+ (0) FFh Send dummy/zero, receive FFh
+ <-------- at this point, the function is executed for the second time
+ Send Reply Comment
+ 81h N/A Memory Card Access
+ 5Ch FLAG Send Command 5Ch
+ FUNC FFh Send Function Number, receive FFh (indicating variable length)
+ (0) LEN1 Send dummy/zero, receive length of parameters (depending on FUNC)
+ ... (0) Send parameters (LEN1 bytes), and receive dummy/zero
+ <-------- at this point, the function is executed for the first time
+ (0) LEN2 Send dummy/zero, receive length of data (depending on FUNC)
+ ... (0) Send data (LEN2 bytes) to pocketstation, receive dummy/zero
+ (0) FFh Send dummy/zero, receive FFh
+ <-------- at this point, the function is executed for the second time
+Can be used to notify the GUI (or games that do support this function) about
+following "download" operations (or uploads or other BU commands).
+BU commands are handled inside of the kernels FIQ handler, that means both IRQs
+and FIQs are disabled during a BU command transmission, so any IRQ or FIQ based
+audio frequency generators will freeze during BU commands. To avoid distorted
+noise, it's best to disable sound for the duration specified in bit0-7. If the
+PSX finishes before the originally specified duration has expired, then it can
+resend this command with bit8=1 to notify the pocketstation that the "download"
+has completed.
+
Send Reply Comment
+ 81h N/A Memory Card Access
+ 5Dh FLAG Send Command 5Dh
+ (0) 03h Send dummy/zero, receive length of following data (03h)
+ VAL (0) Send receive value.16-23 (whatever), receive dummy/zero
+ VAL (0) Send receive value.8-15 (download flags), receive dummy/zero
+ VAL (0) Send receive value.0-7 (download duration), receive dummy/zero
+ If value.8-15 = 00h, then ComFlags.bit10=1, else ComFlags.bit10=0.
+ If download_callback<>0 then call download_callback with r0=value.0-23.
+ bit0-7 download duration (in whatever units... 30Hz, RTC, seconds...?)
+ bit8 download finished (0=no, 1=yes, cancel any old/busy duration)
+ bit9-23 not used by gui
+LEN1 is 00h (no parameters), and LEN2 is 08h (eight data bytes):
+
DATE Get or Send BCD Day (01h..31h)
+ DATE Get or Send BCD Month (01h..12h)
+ DATE Get or Send BCD Year (00h..99h)
+ DATE Get or Send BCD Century (00h..99h)
+ TIME Get or Send BCD Second (00h..59h)
+ TIME Get or Send BCD Minute (00h..59h)
+ TIME Get or Send BCD Hour (00h..23h)
+ TIME Get or Send BCD Day of Week (01h..07h)
+LEN1 is 05h (five parameters bytes):
+
ADDR Send Pocketstation Memory Address.bit0-7
+ ADDR Send Pocketstation Memory Address.bit8-15
+ ADDR Send Pocketstation Memory Address.bit16-23
+ ADDR Send Pocketstation Memory Address.bit24-31
+ LEN2 Send Desired Data Length (00h..80h, automatically clipped to max=80h)
+ ... Get or Send LEN2 Data byte(s), max 80h bytes
+LEN1 is 00h (no parameters), and LEN2 is 08h (eight data bytes):
+
DATA Get or Send Alarm.bit0-7, Alarm Minute (00h..59h, BCD)
+ DATA Get or Send Alarm.bit8-15, Alarm Hour (00h..23h, BCD)
+ DATA Get or Send Alarm.bit16-23, Flags, see SWI 13h, GetPtrToAlarmSetting()
+ DATA Get or Send Alarm.bit24-31, Not used (usually 00h)
+ DATA Get or Send Alarm.bit32-39, BIOS Charset Address.0-7
+ DATA Get or Send Alarm.bit40-47, BIOS Charset Address.8-15
+ DATA Get or Send Alarm.bit48-55, BIOS Charset Address.16-23
+ DATA Get or Send Alarm.bit56-63, BIOS Charset Address.24-31
+LEN1 is 04h (fixed) (four parameters bytes):
+
VAL Send Parameter Value.bit0-7
+ VAL Send Parameter Value.bit8-15
+ VAL Send Parameter Value.bit16-23
+ VAL Send Parameter Value.bit24-31
+ ... Get or Send LEN2 Data byte(s)
+LEN1 is variable (depends on the LEN1 value in Function Table in File Header):
+
... Send LEN1 Parameter Value(s), max 80h bytes (destroys Kernel when >80h)
+ ... Get or Send LEN2 Data byte(s), max 80h bytes (clipped to max=80h)
+ ;above LEN1 should be 00h..80h (the parameters are stored
+ ;in a 80h-byte buffer in kernel RAM, so len LEN1=81h..FFh would
+ ;destroy the kernel RAM that is located after that buffer)
+Incoming parameters on 1st Function Call:
+
r0=flags (09h=Pre-Data to PSX, or 0Ah=Pre-Data from PSX)
+ r1=pointer to parameter buffer (which contains LEN1 bytes) (in Kernel RAM)
+ r0 = Pointer to 64bit memory location (or r0=00000000h=Failed)
+ 0-31 BUF2 address of data buffer (src/dst)
+ 32-63 LEN2 (00000000h..00000080h) (clipped to max 00000080h if bigger)
+Incoming parameters on 2nd Function Call:
+
r0=flags (11h=Post-Data to PSX, 12h=Post-Data from PSX; plus 04h if Bad-Data)
+ r1=pointer to data buffer (which contains LEN2 bytes) (BUF2 address)
+ There's no return value required on 2nd call (although the kernel
+ functions seem to return the same stuff as on 1st call).
+For each function, there is only one single function vector which is called for
+both To- and From-PSX, and both Pre- and Post-Data, and also on errors. The
+function must decipher the flags in r0 to figure out which of that operations
+it should handle:
+
0 To-PSX (when used by Command 5Bh)
+ 1 From-PSX (when used by Command 5Ch)
+ 2 Error occurred during Data transfer
+ 3 Pre-Data
+ 4 Post-Data
+ 5-31 Not used (zero)
+ 09h Pre-Data to PSX
+ 0Ah Pre-Data from PSX
+ 11h Post-Data to PSX
+ 12h Post-Data from PSX
+ 15h Post-Bad-Data to PSX
+ 16h Post-Bad-Data from PSX
+Pocketstation files consists of the following elements (in that order):
+
PSX Title Sector ;80h bytes
+ PSX Colored Icon(s) ;(hdr[02h] AND 0Fh)*80h bytes
+ Pocketstation Saved Snapshot ;800h bytes if hdr[52h]="MCX1", else 0 bytes
+ Pocketstation Function Table ;(hdr[57h]*8+7Fh) AND NOT 7Fh bytes
+ Pocketstation File Viewer Mono Icon ;hdr[50h]*80h bytes
+ Pocketstation Executable Mono Icon List ;hdr[56h]*8 bytes
+ Body (Pocketstation Executable Code/Data, PSX Game Position, Exec-Icons)
+For pocketstation executables, the 7th byte of the filename must be a "P" (for
+other files that location does usually contain a "-", assuming the file uses a
+standard filename, eg. "BESLES-12345abcdefgh" for a Sony licensed european
+title).
50h 2 Number of File Viewer Mono Icon Frames (or 0000h=Use Exec-Icons)
+ 52h 4 Pocketstation Identifier ("MCX0"=Normal, "MCX1"=With Snapshot)
+ 56h 1 Number of entries in Executable Mono Icon List (01h..FFh)
+ 57h 1 Number of BU Command 5Bh/5Ch Get/Set Functions (00h..7Fh, usually 00h)
+ 58h 4 Reserved (zero)
+ 5Ch 4 Entrypoint in FLASH1 (ie. Fileoffset plus 02000000h) (bit0=THUMB)
+For a load-able snapshot the Snapshot ID must be 01h,00h,"SE", the Kernel uses
+snapshots only once (after loading a snapshot, it forcefully changes the ID to
+00h,00h,"SE" in FLASH memory).
+
000h r1..r12 (ie. without r0)
+ 030h r13_usr (sp_usr)
+ 034h r14_usr (lr_usr)
+ 038h r15 (pc)
+ 03Ch psr_fc
+ 040h Snapshot ID (0xh,00h,"SE")
+ 044h unused (3Ch bytes)
+ 200h Copy of user RAM at 200h..7FFh
+The table can contain 00h..7Fh entries, for FUNC 80h..FFh. Each entry occupies
+8 bytes:
+
00h 4 LEN1 (00000000h..00000080h) (destroys Kernel RAM if bigger)
+ 04h 4 Function Address (bit0 can be set for THUMB code)
+Animation Length (0001h..any number) (icon frames) is stored in hdr[50h], for
+the File Viewer Icon, the Animation Delay is fixed (six 30Hz units per frame).
+The File Viewer Icon is shown in the Directory Viewer (which is activated when
+holding the Down-button pressed for some seconds in the GUI screen with the
+speaker and memory card symbols, and which shows icons for all files, including
+regular PSX game positions, whose colored icons are converted without any
+contrast optimizations to unidentify-able dithered monochrome icons). If the
+animation length of the File Viewer Icon is 0000h, then the Directory Viewer
+does instead display the first Executable Mono Icon.
+Each icon frame is 32x32 pixels with 1bit color depth (32 words, =128 bytes),
+
1st word = top-most scanline, 31st word = bottom-most scanline
+ bit0 = left-most pixel, bit31 = right-most pixel (0=white, 1=black)
+The number of entries in the Executable Mono Icon List is specified in hdr[56h]
+(usually 01h). Each entry in the Icon List occupies 8 bytes:
+
00h 2 Animation Length (0001h..any number) (icon frames)
+ 02h 2 Animation Delay (N 30Hz units per icon frame)
+ 04h 4 Address of icon frame(s) in Virtual FLASH (at 02000000h and up)
+The whole file (including the header and icons) gets mapped to 02000000h and
+up. The entrypoint can be anywhere in the file Body, and it gets called with a
+parameter value in r0 (when started by the GUI, that parameter is always zero,
+but it may be nonzero when the executable was started by a game, ie. the
+\<param> from SWI 08h, PrepareExecute, or the \<param> from BU
+Command 59h).
+Caution: Games (and GUI) are started with the ARM CPU running in Non-privileged
+User Mode (however, there are several ways to hook IRQ/FIQ handlers, and from
+there one can switch to Privileged System Mode).
Games should always include a way to return to the GUI (eg. an option in the
+game over screen, a key combination, a watchdog timer, and/or the docking
+signal) (conventionally, games should prompt Exit/Continue when holding Fire
+pressed for 5 seconds), otherwise it wouldn't be possible to start other games
+- except by pushing the Reset button (which is no good idea since the bizarre
+BIOS reset handler does reset the RTC time for whatever reason).
+The kernel doesn't pass any return address to the entrypoint (neither in R14,
+nor on stack). To return control to the GUI, use SWI functions
+PrepareExecute(1,0,GetDirIndex()+30h), and then DoExecute(0).
Pocketstation files are normally stored in standard Memory Card images,
+Memory Card Images
Aside from that standard formats, there are two Pocketstation specific formats,
+the "SC" and "SN" variants. Both contain only the raw file, without any
+Directory sectors, and thus not including a "BESLESP12345"-style filename
+string. The absence of the filename means that a PSX game couldn't (re-)open
+these files via filenames, so they are suitable only for "standalone"
+pocketstation games.
Contains the raw Pocketstation Executable (ie. starting with the "SC" bytes in
+the title sector, followed by icons, etc.), the filesize should be padded to a
+2000h-byte block boundary.
This is a strange incomplete .BIN file variant which starts with a 4-byte ID
+("SN",00h,00h), which is directly followed by executable code, without any
+title sector, and without any icons.
+
It seems as if the file (including the 4-byte ID) is intended to be
+ mapped to address 02000000h, and that the entrypoint is fixed at
+ 02000004h (in ARM state).
+ Since the File doesn't have a valid file header with "SC" and "MCXn" IDs,
+ it won't be recognized by real hardware, the PSX BIOS would treat it as
+ a corrupted/deleted file, the Pocketstation BIOS would treat it as a
+ non-executable file.
+ So, that fileformat is apparently working only on whatever emulators,
+ apparently on the one developed by SN Systems.
+ If one should want to use that files on real hardware, one could add
+ a 2000h byte stub at the begin of the file; with valid headers, and
+ with a small executable that remaps the "SN" stuff to 02000000h via
+ the F_BANK_VAL registers.
+ Ah, and the "SN" files seem to access RAM at 01000000h and up, unknown
+ if RAM is mirrored to that location on real hardware, reportedly that
+ region is unused... and doesn't contain RAM...?
+ Some games use The Undefined Instruction for TTY Output.
+ Most games do strange 8bit writes to LCD_MODE+0 and LCD_MODE+1
+ The games usually don't allow to return to the GUI (except by Reset).
+This circuit allows to connect a pocketstation to PC parallel port, allowing to
+upload executables to real hardware, and also allowing to download TTY debug
+messages (particulary useful as the 32x32 pixel LCD screen is way too small to
+display any detailed status info).
Use a standard parallel port cable (with 36pin centronics connector or 25pin DB
+connector) and then build a small adaptor like this:
+
Pin CNTR DB25 Pocketstation _______________________
+ ACK 10 10 --------- 1 JOYDTA | | | |
+ D0 2 2 --------- 2 JOYCMD | 9 7 6 | 5 4 3 | 2 1 | CARD
+ GND 19-30 18-25 ------- 4 GND |_______|_______|_______|
+ D1 3 3 --------- 6 /JOYSEL _______________________
+ D2 4 4 --------- 7 JOYCLK | | | |
+ PE 12 12 --------- 9 /JOYACK (/IRQ7) | 9 8 7 | 6 5 4 | 3 2 1 | PAD
+ NC -------------------- 8 /JOYGUN (/IRQ10) \______|_______|______/
+ NC -------------------- 3 7.5V (rumble.supply)
+ SUPPLY.5V --|>|---|>|-- 5 3.5V (VCC) (eg. PC's +5V via two 1N4001 diodes)
+ SUPPLY.0V ------------- 4 GND (not needed when same as GND on CNTR/DB25)
+The upload function is found in no$gba "Utility" menu. It does upload the
+executable and autostart it via standard memory card/pocketstation commands
+(ie. it doesn't require any special transmission software installed on the
+pocketstation side).
+Notes: Upload is overwriting ALL files on the memory card, and does then
+autostart the first file. Upload is done as "read and write only if different",
+this provides faster transfers and higher lifetime.
TTY output is conventionally done by executing the ARM CPU's Undefined Opcode
+with an ASCII character in R0 register (for that purpose, the undef opcode
+handler should simply point to a MOVS PC,LR opcode).
+That kind of TTY output works in no$gba's pocketstation emulation. It can be
+also used via no$gba's POC-XBOO cable, but requires some small customization in
+the executable:
+First of, the executable needs "TTY+" ID in some reserved bytes of the title
+sector (telling the xboo uploader to stay in transmission mode and to keep
+checking for TTY messages after the actual upload):
+
TitleSector[58h] = "TTY+"
+ ;------------------
+ .data?
+ org 200h
+ ...
+ tty_bufsiz equ 128 ;max=128=fastest (can be smaller if you are short of RAM)
+ func3_info: ;\ ;\
+ func3_buf_base dd 0 ;fixed="func3_buf" ; ; func3_info+00h
+ func3_buf_len dd 0 ;range=0..128 ;/ ; func3_info+04h
+ func3_stack dd 0 ; func3_info+08h
+ func3_buffer: defs tty_bufsiz ;/ func3_info+0Ch
+ ptr_to_comflags dd 0
+ ...
+ .code
+ ...
+ ;------------------
+ tty_wrchr: ;in: r0=char
+ dd 0e6000010h ;=undef opcode ;-Write chr(r0) to TTY
+ bx lr
+ ;------------------
+ init_tty: ;in: r0=param (from entrypoint)
+ ldr r1,=2B595454h ;"TTY+" ;\check if xboo-cable present
+ cmp r1,r0 ; (r0=incoming param from
+ beq @@tty_by_xboo_cable ;/executable's entrypoint)
+ ;- - -
+ mov r1,0 ;\dummy und_handler
+ ldr r2,=0e1b0f00eh ;=movs r15,r14 ; (just return from exception,
+ str r2,[r1,04h] ;und_handler ;/for normal cable-less mode)
+ b @@finish
+ ;---
+ @@tty_by_xboo_cable:
+ swi 17h ;GetPtrToFunc3addr() ;\
+ ldr r1,=(tty_func3_handler AND 0ffffh) ; init FUNC3 aka TTY handler
+ strh r1,[r0] ;/
+ ldr r1,=func3_info ;\
+ mov r0,0 ;\ ; mark TTY as len=empty
+ str r0,[r1,4] ;func3_buf_len ;/ ; and
+ add r0,r1,0ch ;=func3_buffer ;\ ; init func3 base
+ str r0,[r1,0] ;func3_buf_base ;/ ;/
+ mov r1,0 ;\
+ ldr r2,=0e59ff018h ;=ldr r15,[pc,NN] ;
+ str r2,[r1,04h] ;und_handler ; special xboo und_handler
+ add r2,=tty_xboo_und_handler ;
+ str r2,[r1,24h] ;und_vector ;/
+ @@finish:
+ swi 06h ;GetPtrToComFlags() ;\
+ ldr r1,=ptr_to_comflags ; get ptr to ComFlags
+ str r0,[r1] ;/
+ bx lr
+ ;------------------
+ tty_xboo_und_handler: ;in: r0=char
+ ldr r13,=func3_info ;aka sp_und ;-base address (in sp_und)
+ str r12,[r13,8] ;func3_stack ;-push r12
+ @@wait_if_buffer_full: ;\
+ ldr r12,=ptr_to_comflags ; ;\exit if execute file request
+ ldr r12,[r12] ;ptr to ComFlags ; ; ComFlg.Bit11 ("bu_cmd_59h"),
+ ldr r12,[r12] ;read ComFlags ; ; ie. allow that flag to be
+ tst r12,1 shl 11 ;test bit11 ; ; processed by main program,
+ bne @@exit ; ;/without hanging here
+ ldrb r12,[r13,4] ;func3_buf_len ; wait if buffer full
+ cmp r12,tty_bufsiz ; (until drained by FIQ)
+ beq @@wait_if_buffer_full ;/
+ mov r12,1bh+0c0h ;mode=und, FIQ/IRQ=off ;\disable FIQ (no COMMUNICATION
+ mov cpsr_ctl,r12 ;/interrupt during buffer write)
+ ldrb r12,[r13,4] ;func3_buf_len ;\
+ add r12,1 ;raise len ; write char to buffer
+ strb r12,[r13,4] ;func3_buf_len ; and raise buffer length
+ add r12,0ch-1 ;=func3_buffer+INDEX ;
+ strb r0,[r13,r12] ;append char to buf ;/
+ @@exit:
+ ldr r12,[r13,8] ;func3_stack ;-pop r12
+ movs r15,r14 ;return from exception (and restore old IRQ/FIQ state)
+ ;------------------
+ tty_func3_handler: ;in: r0=flags, r1=ptr
+ tst r0,10h ;test if PRE/POST data (pre: Z, post: NZ)
+ ;ldreq r1,[r1] ;read 32bit param (aka the four LEN1 bytes of FUNC3)
+ ldr r0,=func3_info ;ptr to two 32bit values (FUNC3 return value)
+ movne r1,0 ;\for POST data: mark buffer empty
+ strne r1,[r0,4] ;func3_buf_len=0 ;/
+ bx lr ;-for PRE data: return r0=func3_info
+ CL825 20pin pin test points (2x10 pins)
+ CL827 20pin pin test points (2x10 pins)
+ U83 64pin SEC KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM
+ U84 64pin SEC KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM
+ CL828 20pin pin test points (2x10 pins)
+ CL826 20pin pin test points (2x10 pins)
+ X10 4pin JC53.20 (PAL, 53.203425MHz)
+ X2 4pin 53.69317MHz (NTSC, 53.693175MHz)
+ U62 20pin LVT244 (dual 4-bit 3-state noninverting buffer/line driver)
+ U27 64pin Sony CXD2923AR ;GPU'b
+ CL813 20pin pin test points (2x10 pins)
+ CL814 20pin pin test points (2x10 pins) (with one resistor or so installed)
+ U16 160pin Sony CXD8514Q ;GPU'a
+ X7 4pin 67.73760 MHz
+ CL807 20pin pin test points (2x10 pins)
+ CL809 20pin pin test points (2x10 pins)
+ CL811 20pin pin test points (2x10 pins)
+ U801 208pin Sony CXD8530BQ ;CPU
+ U11 28pin SEC KM48V2104AJ-6 (DRAM 2Mx8) ;Main RAM
+ U10 28pin SEC KM48V2104AJ-6 (DRAM 2Mx8) ;Main RAM
+ U9 28pin SEC KM48V2104AJ-6 (DRAM 2Mx8) ;Main RAM
+ U8 28pin SEC KM48V2104AJ-6 (DRAM 2Mx8) ;Main RAM
+ CN801 100pin Blue connector (to other ISA board)
+ U66 48pin LVT16244? (quad 4-bit 3-state noninverting buffer/line driver)
+ U65 48pin LVT16244? (quad 4-bit 3-state noninverting buffer/line driver)
+ U64 48pin LVT16245? (dual 8-bit 3-state noninverting bus transceiver)
+ U34 100pin Sony CXD2922Q ;SPU
+ U63 14pin 74F74N (dual flipflop)
+ U32 44pin SEC KM416V256B1-8 (DRAM 256Kx16) ;SoundRAM
+ CL801 20pin pin test points (2x10 pins)
+ CL802 20pin pin test points (2x10 pins)
+ Q881 3pin voltage stuff?
+ U31 20pin 74ACT244P (dual 4-bit 3-state noninverting buffer/line driver)
+ U35 18pin Sony CXD2554P or OKI M6538-01 (aka MSM6538-01?) (audio related?)
+ U36 20pin Sanyo LC78815 ;16bit D/A Converter
+ U37 8pin NEC ...? C4558C? D426N0B or 9426HOB or so?
+ J806 8pin solder pads...
+ J805 9pin solder pads...
+ J804 10pin solder pads... (11pins, with only 10 contacts?)
+ - 48pin solder pads (12x4pin config jumpers or so)
+ U26 20pin SN74ALSxxx logic?
+ U71 24pin Sony CXA1xxxx? ;RGB?
+ JPxx 9pin PAL/NTSC Jumpers (three 3pin jumpers)
+ J801 24pin solder pads...
+ J803 9pin rear connector: Serial Port (3.3V) (aka "J308") (DB9) (5+4pin)
+ J802 15pin rear connector: AV Multi-out (5+5+5pin)
+ CN881 98pin ISA Bus Cart-edge (2x31 basic pins, plus 2x18 extended pins)
+ JP72x 68pin Black connector (maybe equivalent to 68pin PSX expansion port?)
+ SWI 5pin solder pads...
+ U371 40pin HN27C4000G-12 (512Kx8 / 256Kx16 EPROM) (sticker: "94/7/27")
+ U370 84pin Altera EPM7160ELC84-12 (sticker: "U730, cntl 1")
+ U3 14pin SN74ALS1004N (hex inverters)
+ U43 44pin Altera EPM7032LC44-10 (sticker: "U43, add 1")
+ U716 28pin Sharp LH5498D-35 (FIFO 2Kx9)
+ U717 28pin Sharp LH5498D-35 (FIFO 2Kx9)
+ U719 28pin Sharp LH5498D-35 (FIFO 2Kx9)
+ U720 28pin Sharp LH5498D-35 (FIFO 2Kx9)
+ U724 20pin SN74ALS688N (8bit inverting identity comparator with enable)
+ U722 20pin SN74ALS245AN (8bit tristate noninverting bus transceiver)
+ U47 20pin 74FCT244ATP (dual 4-bit 3-state noninverting buffer/line driver)
+ U732 48pin LVT16245? (dual 8-bit 3-state noninverting bus transceiver)
+ U711 20pin SN74ALS244BN (dual 4-bit 3-state noninverting buffer/line driver)
+ U712 20pin SN74ALS244BN (dual 4-bit 3-state noninverting buffer/line driver)
+ U713 20pin 74HC244AP (dual 4-bit 3-state noninverting buffer/line driver)
+ U714 20pin 74HC244AP (dual 4-bit 3-state noninverting buffer/line driver)
+ U721 20pin SN74ALS244BN (dual 4-bit 3-state noninverting buffer/line driver)
+ U55 14pin SN74ALS08N (quad 2-input AND gates)
+ U726 20pin SN74ALS245AN (8bit tristate noninverting bus transceiver)
+ U715 20pin 74HC244AP (dual 4-bit 3-state noninverting buffer/line driver)
+ JPxx 100pin Blue connector (to other ISA board)
+ U738 20pin LVT244 (SMD) (dual 4-bit 3-state noninverting buffer/line driver)
+ U734 32pin KM684000G-7 (SRAM 512Kx8) ;\maybe 1Mbyte EXP3 RAM ?
+ U733 32pin KM684000G-7 (SRAM 512Kx8) ;/
+ U725 20pin SN74ALS688N (8bit inverting identity comparator with enable)
+ S700 24pin 12bit DIP switch (select I/O Address bits A15..A4)
+ JP700 8pin Jumper (4x2 pins) (select IRQ15/IRQ12/IRQ11/IRQ10)
+ JP7xx 12pin Jumper (3x4 pins) (select DMA7/DMA6/DMA5)
+ U64 48pin LVT16245? (dual 8-bit 3-state noninverting bus transceiver)
+ U65 48pin LVT16244? (quad 4-bit 3-state noninverting buffer/line driver)
+ U66 48pin LVT16244? (quad 4-bit 3-state noninverting buffer/line driver)
+ U737 48pin LVT16244? (quad 4-bit 3-state noninverting buffer/line driver)
+ U710 20pin SN74ALS244BN (dual 4-bit 3-state noninverting buffer/line driver)
+ U709 20pin HD74HC245P (8bit tristate noninverting bus transceiver)
+ U723 14pin SN74ALS38AN (quad open-collector NAND gates with buffered output)
+ U2 14pin SN74LS19AN (hex inverters with schmitt-trigger)
+ U1 8pin Dallas DS1232 (MicroMonitor Chip) ;power-good-detect ?
+ U708 20pin HD74HC245P (8bit tristate noninverting bus transceiver)
+ X3 2pin 4.1900 (4.19MHz for SPC700 CPU)
+ U42 80pin P823, U01Q (Sony CXP82300 SPC700 CPU with piggyback EPROM socket)
+ U42' 32pin 27C256A-15 (EPROM 32Kx8) (sticker: "94/11/28")
+ U706 10pin some slim chip with 1x10 pins
+ BT700 2pin battery (or super-cap?) for DS1302S (?) (not installed)
+ U729? 5pin voltage stuff?
+ U40 8pin Dallas DS1302S (real time clock)
+ X4 2pin small crystal (32.768kHz for DS1302S)
+ JP702 34pin Black connector (maybe for internal CDROM Emulator ISA cart?)
+ U736 28pin Sony CXK58257ASP-70L (SRAM 32Kx8) ;CDROM Sector Buffer?
+ U735 100pin Sony CXD1199BQ ;CDROM Decoder/FIFO
+ JP715 40pin Blue connector... to external DTL-H2010 CDROM drive?
+ JP721 9pin rear connector: Joypad/Memcard 2 (DB9)
+ JP719 9pin rear connector: Joypad/Memcard 1 (DB9)
+ ? - rear hole for cdrom-cable to Blue 40pin connector?
+ J70x 98pin ISA Bus Cart-edge (2x31 basic pins, plus 2x18 extended pins)
+Newer revision of the DTL-H2000 board. Consists of a single PCI card (plus tiny
+daughterboard with Controller ports).
+
Mainboard "PI-27 1-589-867-11, DTL-H2500, MAIN BOARD 1575E01A0, SONY"
+ Daughterboard "SONY,CN-102 1-589-865-11,CONNECTOR BOARD,DTL-H2500,1575E02A0"
+ CJ1 9pin rear connector: DB9
+ CJ2? 15pin rear connector: AV Multi-out (5+5+5pin)
+ CJ3 10pin gray connector (to controller daughterboard with two DB9's)
+ CJ4 34pin black connector (maybe for internal CDROM Emulator ISA cart?)
+ CJ5 50pin black connector (to DTL-H2510, Gray Internal CDROM Drive?)
+ CJ6 68pin black connector (maybe equivalent to 68pin PSX expansion port?)
+ - 124pin PCI bus cart edge connector
+ CJ1' 9pin rear connector: DB9 (CTR1, joypad 1) ;\
+ CJ2' 9pin rear connector: DB9 (CTR2, joypad 2) ; on daughterboard
+ CJ3' 10pin gray ribbon cable (to CJ3 on main board) ;/
+ IC103 208pin Sony CXD8530CQ (CPU)
+ IC106 28pin SEC KM48V2104AT-6 (DRAM 2Mx8)
+ IC107 28pin SEC KM48V2104AT-6 (DRAM 2Mx8)
+ IC108 28pin SEC KM48V2104AT-6 (DRAM 2Mx8)
+ IC109 28pin SEC KM48V2104AT-6 (DRAM 2Mx8)
+ IC201 64pin SEC KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM
+ IC202 64pin SEC KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM
+ IC203 160pin Sony CXD8514Q ;GPU'a
+ IC207 64pin Sony CXD2923AR ;GPU'b
+ IC303 28pin HM62W256LFP-7T (CDROM SRAM 32Kx8) ;on back side
+ IC304 52pin "D 2021, SC430920PB, G64C 185, JSAA9618A" (Sub-CPU) ;on back
+ IC305 100pin Sony CXD1199BQ (CDROM Decoder/FIFO) ;on back side
+ IC308 100pin Sony CXD2922BQ (SPU) ;on back side
+ IC310 44pin SEC KM416V256BLT-7 (DRAM 256Kx16) ;SoundRAM ;on back side
+ IC402 24pin something bigger
+ IC404 8pin something small
+ IC405 8pin something small
+ IC501 24pin Sony CXA1645M (Analog RGB to Composite) ;on back side
+ IC701 4pin "RD, 5B" or so ;on back side
+ IC801 +++pin "ALTERA, FLEX, EPF8820ARC208-3, A9607"
+ IC802 20pin LVT245A <-- ;on back side
+ IC803 52pin "IDT71321, LA35J, S9704P" (2Kx8 dual port SRAM)
+ IC804 20pin LVT244A
+ IC805 8pin something with socket (sticker: "PD3")
+ IC807-2 32pin MX 27C1000MC-90 (PROM) ;\on back side
+ IC808 32pin F 29F040A-90 (FLASH) ;/BIOS on these chip(s) or so?
+ IC901 4pin 37, 69 ;\on back side
+ IC902 4pin 37, 69 ;/
+ ICxxx? 28pin "DALLAS, DS1230Y-100, NONVOLATILE SRAM"
+ U28 20pin LVT244A
+ Z1 20pin LVT244A ;\on back side
+ Z2 20pin LVT245A <-- ;/
+ Z3 20pin LVT244A
+ Z4 20pin LVT244A ;\
+ Z5 20pin LVT245A <-- ; on back side
+ Z6 20pin LVT244A ;/
+ Z7 20pin LVT244A
+ Z8 20pin LVT244A
+ Z9 20pin LVT244A
+ X101 4pin RC67.73, JVC 5L (67.7376MHz oscillator for main cpu)
+ X201 4pin JC53.20, JVC 6A (for GPU, PAL)
+ X202 4pin JC53.69, JVC 6A (for GPU, NTSC)
+ X302 3pin 4.000MHz (for sub-cpu)
+Another revision of the DTL-H2000/DTL-H2500 boards. Consists of a single ISA
+card stacked together with two huge daughterboards, and probably additionally
+having a small connector daughterboard. Exact chipset is unknown (there might
+be components on both sides of the PCBs, most of them not visible due to the
+PCB stacking, so taking photos/scans of the PCBs would require advanced
+techniques with screwdrivers).
+Currently the only known chip name is an EPROM (MX 27C1000DC-90, with sticker
+"Title=DTL-H2700, Ver=1.00, Date=96.12.4, Sum=046B No."). The ISA card is
+having markings: "SONY HCD MWB-7? MADE IN JAPAN, PA47 1-589-003-01 1642E03A0".
+One uncommon feature is an extra connector for a "trigger switch" (foot pedal),
+which is reportedly used for activating performance analyzer logging.
X2 xpin TXC-2 OSC 66.000MHz
+ X1 xpin TXC-2AOSC 53.693MHz
+ U16 14pin 74F74 (dual flipflop)
+ U29 14pin 74AS04 (hex inverters)
+ U14 20pin LVT244 (dual 4-bit 3-state noninverting buffer/line driver)
+ U18 20pin LVT244 (dual 4-bit 3-state noninverting buffer/line driver)
+ U15 20pin ACT244 (dual 4-bit 3-state noninverting buffer/line driver)
+ U11 84pin Altera EPM7096LC84-12 (sticker: "artpc13" or "ARTPC13")
+ U13 160pin Sony CXD8514Q ;GPU'a
+ U5 14pin ALS38A ? (quad open-collector NAND gates with buffered output)
+ U27 20pin ALS244AJ ? (dual 4bit tristate noninverting buffer/line driver)
+ Q1 3pin T B596
+ U23 64pin KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM
+ U22 64pin KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM
+ U28 64pin Sony CXD2923AR ;GPU'b
+ S1 16pin 8bit DIP switch (select I/O address A15..A8)
+ S2 8pin 4bit DIP switch (select I/O address A7..A4)
+ U1 20pin SN74ALS688N (8bit inverting identity comparator with enable)
+ U2 20pin SN74ALS688N (8bit inverting identity comparator with enable)
+ U3 20pin ALS245A (8bit tristate noninverting bus transceiver)
+ JP9 12pin Jumper (6x2 pins) (select IRQ15/IRQ11/IRQ10/IRQ9/IRQ5/IRQ3)
+ U26 24pin Sony CXA1145M ? ;RGB?
+ JP10 3pin Jumper ;\
+ JP12 3pin Jumper ; select "S" or "O" (?)
+ JP11 3pin Jumper ;/
+ J3 2pin? Yellow connector (composite video out?)
+ J2? pin? Mini DIN? connector (maybe S-video out?)
+ J1 15pin High Density SubD (maybe video multi out?)
+ CJx 98pin ISA Bus Cart-edge (2x31 basic pins, plus 2x18 extended pins)
+ Yellow PCB "CD Emulator System, (C) Cirtech & SN Systems Ldt, 1994 v1.2"
+ IC 24pin GAL20V8B
+ IC 68pin Analog Devices ADSP-2101 (16bit DSP Microprocessor)
+ IC 20pin HD74HC244P
+ IC15 20pin HD74HC244P
+ IC14 20pin CD74HCT245E
+ IC7 28pin 27C512-10 (EPROM 64Kx8) (yellow sticker, without text)
+ IC 28pin HY62256ALP-70 (SRAM 32Kx8)
+ IC12 28pin HY62256ALP-70 (SRAM 32Kx8)
+ IC 28pin HY62256ALP-70 (SRAM 32Kx8)
+ IC13 84pin Emulex/QLogic FAS216 (Fast Architecture SCSI Processor)
+ IC5 84pin Emulex/QLogic FAS216 (Fast Architecture SCSI Processor)
+ IC4 24pin GAL20V8B (near IO Addr jumpers)
+ IC 20pin 74LS244B1 (near lower 8bit of ISA databus)
+ IC 20pin SN74LS245N? (near lower 8bit of ISA databus)
+ IC 20pin SN74LS245N (near upper 8bit of ISA databus)
+ DMA 12pin Jumpers (select DMA7/6/5)
+ IRQ 12pin Jumpers (select IRQ15/12/11/10/7/5)
+ IO 16pin Jumpers (select IO Addr 300/308/310/318/380/388/390/398)
+ SCSI 6pin Jumpers (select SCSI ID 4/2/1) (aka 3bit 0..7 ?)
+ PL3 34pin Connector to DTL-H2000 ?
+ PL1 50pin Connector to INTERNAL SCSI hardware ?
+ PL2 50pin? Connector to EXTERNAL SCSI hardware ? (25pin plug/50pin cable?)
+ Jx 98pin ISA Bus Cart-edge (2x31 basic pins, plus 2x18 extended pins)
+ 32pin GM76C8128ALLFW85 (SRAM 128Kx8)
+ 44pin ALTERA EPM7032LC44-15T
+ 34pin EMULEX FAS101 (SCSI Interface Processor)
+ 28pin 27C64 (EPROM 8Kx8) (green sticker, without text)
+ 20pin LCX245 (=74245?)
+ 8pin 2112, CPA, H9527 (?)
+ 3pin transistor? voltage regulator?
+ 20pin DIP socket (containing two 10pin resistor networks)
+ 20pin DIP socket (containing two 10pin resistor networks)
+ 2pin CR2032 Battery 3V
+ 68pin Connector to PSX "Parallel I/O" expansion port
+ 25pin Connector to SCSI hardware (to DTL-S510B or DTL-S2020 ISA cart or so?)
+ U15 24pin ?
+ U5 28pin 27C256 (EPROM 32Kx8) (not installed)
+ U7 4pin 67.7376MHz oscillator
+ U8 14pin ?
+ U11 44pin SEC KM416V256B1-8 (DRAM 256Kx16) ;SoundRAM
+ (44pin package with middle 4pin missing, 40pins used)
+ U10 100pin Sony CXD2925Q ;SPU
+ U4 160pin Lattice IspLSI 3256 (sticker: "VER3")
+ U6 128pin Lattice IspLSI xxxx ?
+ U12 48pin ?
+ U13 48pin ?
+ U3 20pin 74ACT244
+ U14 5pin "LM25755, -3.3 P+" ?
+ U2 54pin ?
+ U1 54pin ?
+ U9 ?pin GP1F31T (light transmitting unit for optical fibre cable)
+ ? 124pin PCI bus cart edge connector
+ ? 8pin internal jumper/connector? (7pin installed, 1pin empty)
+ U1 14pin SN74ALS388N ?
+ U2 20pin SN74ALS688N (8bit inverting identity comparator with enable)
+ U3 20pin SN74ALS688N (8bit inverting identity comparator with enable)
+ U4 24pin PALxxx ?
+ U5 20pin SN74ALS245AN
+ U6 20pin SN74ALS245AN
+ U7 20pin SN74ALS244N
+ U8 20pin SN74ALS244N
+ U9 20pin SN74ALS245AN
+ U10 20pin SN74ALS245AN
+ U11 20pin SN74ALS244N
+ S2 16pin 8bit DIP switch (ISA 15/14/13/12/11/10/9/8) ;I/O address bit15-8
+ S1 8pin 4bit DIP switch (ISA 7/6/5/4) ;I/O address bit7-4
+ S3 8pin 4bit DIP switch (BISO? 3/2/1/0) ;BISO? or BISD? or 8150?
+ JPxx .... several jumpers (unknown purpose)
+ Jx 98pin ISA Bus Cart-edge (2x31 basic pins, plus 2x18 extended pins)
+ J5 68pin Connector on rear side (unknown purpose)
+External front loading CDROM drive with Eject button. Connects to the blue
+40pin connector on DTL-H2000 boards.
+
IC101 100pin SONY CXD2515Q (Signal Processor + Servo Amp) ;\
+ IC102 28pin BA6297AFP ; on mainboard
+ ICxx 20pin SONY CXA1571N (RF Amp) (on tiny daughtboard) ; (HCMK-81X)
+ CN101 21pin connector to DEX2010.SCH board ;
+ CN10x 12pin connector to KSS-240A (laser pickup) ;
+ S101 2pin pos0 switch or so? ;
+ M101 2pin spindle motor ;/
+ U1 20pin 74ALS244BN ;\
+ U2 20pin 74ALS244BN ;
+ U3 20pin 74ALS244BN ; on DEX2010.SCH board
+ J1 2pin connector to EJECT BUTTON ;
+ J2 5pin connector to LOADING MOTOR ;
+ J3 21pin connector to mainboard ;
+ JP1 40pin external connector to DTL-H2000 ;/
+ CN151 5pin connector to DEX2010.SCH board ;\
+ M151 2pin loading motor (eject motor) ; on CDM 14, CMK PSX board
+ S151 2pin OUT SW ;\switches, probably to ;
+ S152 2pin IN SW ;/sense load/eject status ;/
+ CN1 2pin connector to DEX2010.SCH board ;\on DTL-H2010(1) board
+ SW1 2pin eject button ;/
+This is some sort of a mimmicked front loading PC CDROM drive (consisting of a
+tray that contains a normal (top-loading) PSX cdrom drive unit).
+
IC309 80pin Sony CXD2510Q (CDROM Signal Processor)
+ ICxx ?pin Unknown if there are further ICs (eg. CXA1782BR should exist?)
+ CN1 10pin Connector to daughterboard (with drive unit)
+ CN2 4pin Connector to PC power supply (12V/5V and 2xGND)
+ CN3 50pin Connector to DTL-H2500 or so? (need "PCS-E50FC" plug?)
+A rare SCEx-free Playstation that can boot from CDR's without SCEx strings;
+maybe intended for beta-testers. Marked "Property of Sony Computer
+Entertainment", "U/C".
On the 20th of August 2022, Martin surprisingly released a new version of this documentation. While this fork will try to incorporate the changes, one important footnote that got added is the following:
I am homeless in Hamburg, please help me out!
The authors of this fork thought that this deserves more than a footnote, hence this notice here.
"},{"location":"#home_1","title":"Home","text":"This is a conversion/edition of Martin \"nocash\" Korth's Playstation specs document originally hosted at https://problemkaputt.de/psx-spx.htm. See https://github.com/psx-spx/psx-spx.github.io#readme for more details. You can also download this website as a single-page pdf.
Martin is a difficult individual to reach (see https://problemkaputt.de/email.htm, especially the part about gmail), and so far, any attempt at contacting him about collaborating on this document failed.
Therefore, no copyright or license have been properly acquired to republish and alter this document. However, since this repository will accept and proceed to issue corrections, amendments, and additions to the original work, the fair use and derivative work doctrine is believed to be applicable in this case.
An important detail to know about this current document, as well as the original from Martin, is that it isn't a clean room reverse engineering project, as some people may seem to believe or repeat. A good chunk of the original document has been either directly copy/pasted from the confidential code and documentation from Sony, or summarized and rephrased. As this document isn't clean room, any work derived from it shouldn't be considered clean, and anyone saying otherwise is misguided at best. The reference source material, code, and documentation used to make this document can be found at https://psx.arthus.net/sdk/Psy-Q/
To discuss the contents of this document, or hang out with likely minded people on development, hacking, and reverse engineering of Sony's first console, feel free to join the PSX.Dev Discord Server.
Memory Map I/O Map Graphics Processing Unit (GPU) Geometry Transformation Engine (GTE) Macroblock Decoder (MDEC) Sound Processing Unit (SPU) Interrupts DMA Channels Timers CDROM Drive CDROM File Formats Controllers and Memory Cards Pocketstation Serial Interfaces (SIO) Expansion Port (PIO) Memory Control Unpredictable Things CPU Specifications Kernel (BIOS) Arcade Cabinets Konami System 573 Cheat Devices PSX Dev-Board Chipsets Hardware Numbers Pinouts About & Credits CDROM Video CDs (VCD) CDROM Internal Info on PSX CDROM Controller
"},{"location":"aboutcredits/","title":"About & Credits","text":""},{"location":"aboutcredits/#credits","title":"Credits","text":"Contributors to Martin Korth's original documentation:
GPU.TXT by doomed/padua; based on info from K-communications & Nagra/Blackbag\nGTE.TXT by doomed@c64.org / psx.rules.org\nSPU.TXT by doomed@c64.org / psx.rules.org\nCDINFO.TXT by doomed with big thanks to Barubary, who rewrote a large part\nSYSTEM.TXT by doomed with thanx to Herozero for breakpoint info\nPS_ENG.TXT PlayStation PAD/Memory Interface Protocol by HFB03536\nIDT79R3041 Hardware User's Manual by Integrated Device Technology, Inc.\nIDTR3051, R3052 RISController User's Manual by Integrated Device Technology\nPSX.* by Joshua Walker (additional details in various distorted file formats)\nLIBMIRAGE by Rok; info/source code for various cdrom-image formats\npsxdev.ru; cdrom sub-cpu decapping\nAll the contributors to the psx-spx.github.io repo who've helped update, correct and expand this information.
"},{"location":"aboutcredits/#psxspx-homepage","title":"PSXSPX homepage","text":"The following arcade PCBs are known to be based on PlayStation hardware:
Manufacturer Board CPU clock GPU RAM VRAM Additional CPUs Audio Storage Konami GV 33 MHz v0 2 MB 1 MB SPU, CD-DA SCSI CD-ROM, optional flash daughterboard Konami GQ 33 MHz v1 4 MB 2 MB 68000, TMS57002 2x custom PCM chip SCSI hard drive Konami System 573 33 MHz v2 4 MB 2 MB H8/3644 SPU, CD-DA, optional MP3 decoder 16 MB flash, optional ATAPI CD-ROM, PCMCIA cards Konami Twinkle System 33 MHz v2 4 MB 2 MB 68000, DVD player SPU, Ricoh RF5C400 SCSI CD-ROM, IDE hard drive, VCD/DVD, optional floppy Namco System 11 (COH-100 CPU board) 33 MHz v1 4 MB 2 MB Namco C76 SPU (unpopulated), custom PCM chip Mask ROM daughterboard Namco System 11 (COH-110 CPU board) 33 MHz v2 4 MB 2 MB Namco C76 Custom PCM chip Mask ROM daughterboard Namco System 12 (COH-700 CPU board) 50 MHz v2b 4 MB 2 MB H8/3002, optional SH-2 Custom PCM chip, optional XA-ADPCM Mask ROM/flash daughterboard, optional ATAPI CD-ROM Namco System 12 (COH-716 CPU board) 50 MHz v2 16 MB 2 MB H8/3002, optional SH-2 Custom PCM chip, optional XA-ADPCM Mask ROM/flash daughterboard, optional ATAPI CD-ROM Namco System 10 50 MHz v2 16 MB 2 MB SPU, optional MP3 decoder Mask ROM/flash daughterboard, optional ATAPI CD-ROM Sony ZN-1 33 MHz v2 4-8 MB 1-2 MB Optional game-specific SPU, optional game-specific hardware Mask ROM/flash daughterboard Sony ZN-2 50 MHz v2 or v2b 4-16 MB 2 MB Optional game-specific SPU, optional game-specific hardware Mask ROM/flash daughterboard Taito FX-1A (ZN-1 + custom addon board) 33 MHz v2 4 MB 1 MB Z80 SPU, Yamaha YM2610B Mask ROM daughterboard Taito FX-1B (ZN-1 + custom addon board) 33 MHz v2 4 MB 1 MB SPU, custom Zoom DSP Mask ROM daughterboard Taito G-NET (ZN-2 + custom addon board) 50 MHz v2b 4 MB 2 MB MN1020012A, TMS57002 SPU, custom Zoom DSP 8 MB flash, custom encrypted PCMCIA/CF cardThe following boards were mentioned in the original nocash page, but almost nothing is known about them:
Currently only documentation for the System 573 exists. More information about other arcade boards could be obtained from MAME source code.
"},{"location":"arcadecabinets/#cpu","title":"CPU","text":"Most boards use the same CPUs as retail consoles and development units. The System 10, System 12 and ZN-2 feature a later CPU revision that allows for up to 16 MB main RAM (as opposed to 8 MB on the standard CPUs) and clock speeds of up to 50 MHz. The bus interface and memory control registers on these chips may behave differently from the ones found on standard CPUs due to the extended address space.
"},{"location":"arcadecabinets/#gpu","title":"GPU","text":"Most systems have a regular v2 GPU but expand VRAM to 2 MB, arranged as a 1024x1024 buffer rather than 1024x512. The Konami GQ and COH-100 (CPU + GPU daughterboard used in early System 11 units) have the v1 \"prototype\" GPU, which uses completely different commands from v0/v2 and is generally not compatible with any known version of Sony's development tools. Most System 11 games seem to support both GPU types.
Some System 12 and ZN-2 variants use a later revision of the v2 GPU (v2b). The differences between v2 and v2b GPUs are currently unknown.
"},{"location":"arcadecabinets/#audio","title":"Audio","text":"Almost all boards extend the SPU's functionality with additional hardware, usually a custom fixed-function DSP and in some cases a separate sound CPU. The custom audio hardware is typically on a separate board, with some systems allowing it to be unplugged if the game does not require it. The Konami GQ, System 11 (both COH-100 and COH-110 variants) and System 12 omit the SPU entirely.
"},{"location":"arcadecabinets/#controls","title":"Controls","text":"Most systems are designed to be connected to a cabinet through a JAMMA board edge connector, which carries power, a video output, player controls and coin/service button inputs. These inputs are typically accessed via custom memory-mapped I/O ports. As control schemes may vary greatly from game to game, many systems also provide means to connect additional inputs or expansion boards.
Some boards feature a JVS port (a standardized serial bus protocol used to connect controls and peripherals to modern arcade systems), allowing standard JVS I/O boards to be used if supported by games.
"},{"location":"arcadecabinets/#storage","title":"Storage","text":"With the exception of Konami, all manufacturers used mask ROMs or flash memory for game storage. The wiring and layout of the ROMs varies for each board; on some systems the BIOS and game are part of the same ROM, while others have separate BIOS and game ROMs. Graphical and audio assets may also be stored separately or within the main game ROM.
Konami systems store game executables and assets on standard SCSI/IDE hard drives or CD-ROMs. The System 573 can also boot from its built-in flash or a PCMCIA flash card, using the CD-ROM drive only to install new games, however the vast majority of 573 games are too large to fit entirely in the flash and still rely on reading files from the disc after installation. The Twinkle System is particularly unusual as it has a CD-ROM drive accessed by the main CPU, a separate hard drive used by the audio board and an external DVD player unit for background videos.
The System 10 and System 12 are the only known non-Konami boards with CD-ROM support. The former can be connected directly to an ATAPI drive, while the latter requires an expansion module that provides an IDE interface and XA-ADPCM decoding through an integrated SH-2 CPU. Whether these boards support CD-ROM booting without any game ROMs installed is currently unknown.
"},{"location":"arcadecabinets/#security","title":"Security","text":"The implementation of anti-piracy measures varies for each manufacturer.
CDROM Controller I/O Ports
"},{"location":"cdromdrive/#playstation-cdrom-commands","title":"Playstation CDROM Commands","text":"CDROM Controller Command Summary CDROM - Control Commands CDROM - Seek Commands CDROM - Read Commands CDROM - Status Commands CDROM - CD Audio Commands CDROM - Test Commands CDROM - Secret Unlock Commands CDROM - Video CD Commands CDROM - Mainloop/Responses CDROM - Response Timings CDROM - Response/Data Queueing
"},{"location":"cdromdrive/#general-cdrom-disk-format","title":"General CDROM Disk Format","text":"CDROM Disk Format CDROM Subchannels CDROM Sector Encoding CDROM Scrambling CDROM XA Subheader, File, Channel, Interleave CDROM XA Audio ADPCM Compression CDROM ISO Volume Descriptors CDROM ISO File and Directory Descriptors CDROM ISO Misc CDROM File Formats CDROM Video CDs (VCD)
"},{"location":"cdromdrive/#playstation-cdrom-protection","title":"Playstation CDROM Protection","text":"CDROM Protection - SCEx Strings CDROM Protection - Bypassing it CDROM Protection - Modchips CDROM Protection - Chipless Modchips CDROM Protection - LibCrypt
"},{"location":"cdromdrive/#playstation-cdrom-coprocessor","title":"Playstation CDROM Coprocessor","text":"CDROM Internal Info on PSX CDROM Controller
"},{"location":"cdromdrive/#cdrom-controller-io-ports","title":"CDROM Controller I/O Ports","text":"1F801800h 1F801801h 1F801802h 1F801803h 0 Index/Status (RW) Response FIFO (R) (Mirror)Command Register (W) Data FIFO (R)Parameter FIFO (W) Interrupt Enable Register (R)Request Register (W) 1 Index/Status (RW) Response FIFO (R)Sound Map Data Out (W) Data FIFO (R)Interrupt Enable Register (W) Interrupt Flag Register (RW) 2 Index/Status (RW) Response FIFO (R) (Mirror)Sound Map Coding Info (W) Data FIFO (R)Left-CD to Left-SPU Volume (W) Interrupt Enable Register (R) (Mirror)Left-CD to Right-SPU Volume (W) 3 Index/Status (RW) Response FIFO (R) (Mirror)Right-CD to Right-SPU Volume (W) Data FIFO (R)Right-CD to Left-SPU Volume (W) Interrupt Flag Register (R) (Mirror)Audio Volume Apply Changes (W)"},{"location":"cdromdrive/#1f801800h-indexstatus-register-bit0-1-rw-bit2-7-read-only","title":"1F801800h - Index/Status Register (Bit0-1 R/W) (Bit2-7 Read Only)","text":" 0-1 Index Port 1F801801h-1F801803h index (0..3 = Index0..Index3) (R/W)\n 2 ADPBUSY XA-ADPCM fifo empty (0=Empty) ;set when playing XA-ADPCM sound\n 3 PRMEMPT Parameter fifo empty (1=Empty) ;triggered before writing 1st byte\n 4 PRMWRDY Parameter fifo full (0=Full) ;triggered after writing 16 bytes\n 5 RSLRRDY Response fifo empty (0=Empty) ;triggered after reading LAST byte\n 6 DRQSTS Data fifo empty (0=Empty) ;triggered after reading LAST byte\n 7 BUSYSTS Command/parameter transmission busy (1=Busy)\n 0-7 Command Byte\n 0-7 Parameter Byte(s) to be used for next Command\n 0-4 0 Not used (should be zero)\n 5 SMEN Want Command Start Interrupt on Next Command (0=No change, 1=Yes)\n 6 BFWR ...\n 7 BFRD Want Data (0=No/Reset Data Fifo, 1=Yes/Load Data Fifo)\nAfter ReadS/ReadN commands have generated INT1, software must set the Want Data bit (1F801803h.Index0.Bit7), then wait until Data Fifo becomes not empty (1F801800h.Bit6), the datablock (disk sector) can be then read from this register.
0-7 Data 8bit (one byte), or alternately,\n 0-15 Data 16bit (LSB=First byte, MSB=Second byte)\n 0-7 Response Byte(s) received after sending a Command\n 0-4 Interrupt Enable Bits (usually all set, ie. 1Fh=Enable All IRQs)\n 5-7 Unknown/unused (write: should be zero) (read: usually all bits set)\n 0-2 Read: Response Received Write: 7=Acknowledge ;INT1..INT7\n 3 Read: Unknown (usually 0) Write: 1=Acknowledge ;INT8 ;XXX CLRBFEMPT\n 4 Read: Command Start Write: 1=Acknowledge ;INT10h;XXX CLRBFWRDY\n 5 Read: Always 1 ;XXX \"_\" Write: 1=Unknown ;XXX SMADPCLR\n 6 Read: Always 1 ;XXX \"_\" Write: 1=Reset Parameter Fifo ;XXX CLRPRM\n 7 Read: Always 1 ;XXX \"_\" Write: 1=Unknown ;XXX CHPRST\n INT0 No response received (no interrupt request)\n INT1 Received SECOND (or further) response to ReadS/ReadN (and Play+Report)\n INT2 Received SECOND response (to various commands)\n INT3 Received FIRST response (to any command)\n INT4 DataEnd (when Play/Forward reaches end of disk) (maybe also for Read?)\n INT5 Received error-code (in FIRST or SECOND response)\n INT5 also occurs on SECOND GetID response, on unlicensed disks\n INT5 also occurs when opening the drive door (even if no command\n was sent, ie. even if no read-command or other command is active)\n INT6 N/A\n INT7 N/A\n INT8 Unknown (never seen that bit set yet)\n INT10h Command Start (when INT10h requested via 1F801803h.Index0.Bit5)\nIRQ flag changes aren't synced with the MIPS CPU clock. If more than one bit gets set (and the CPU is reading at the same time) then the CPU does occassionally see only one of the newly bits:
0 ----------> 3 ;99.9% normal case INT3's\n 0 ----------> 5 ;99% normal case INT5's\n 0 ---> 1 ---> 3 ;0.1% glitch: occurs about once per thousands of INT3's\n 0 ---> 4 ---> 5 ;1% glitch: occurs about once per hundreds of INT5's\n @@polling_lop:\n irq_flags = [1F801803h] AND 07h ;<-- 1st read (may be still unstable)\n if irq_flags = 00h then goto @@polling_lop\n irq_flags = [1F801803h] AND 07h ;<-- 2nd read (should be stable now)\n handle irq_flags and acknowledge them\nAllows to configure the CD for mono/stereo output (eg. values \"80h,0,80h,0\" produce normal stereo volume, values \"40h,40h,40h,40h\" produce mono output of equivalent volume). When using bigger values, the hardware does have some incomplete saturation support; the saturation works up to double volume (eg. overflows that occur on \"FFh,0,FFh,0\" or \"80h,80h,80h,80h\" are clipped to min/max levels), however, the saturation does NOT work properly when exceeding double volume (eg. mono with quad-volume \"FFh,FFh,FFh,FFh\").
0-7 Volume Level (00h..FFh) (00h=Off, FFh=Max/Double, 80h=Default/Normal)\n 0 ADPMUTE Mute ADPCM (0=Normal, 1=Mute)\n 1-4 - Unused (should be zero)\n 5 CHNGATV Apply Audio Volume changes (0=No change, 1=Apply)\n 6-7 - Unused (should be zero)\n 0-7 Data\n 0 Mono/Stereo (0=Mono, 1=Stereo)\n 1 Reserved (0)\n 2 Sample Rate (0=37800Hz, 1=18900Hz)\n 3 Reserved (0)\n 4 Bits per Sample (0=4bit, 1=8bit)\n 5 Reserved (0)\n 6 Emphasis (0=Off, 1=Emphasis)\n 7 Reserved (0)\n =============================================================================\nCommand/Parameter transmission is indicated by bit7 of 1F801800h. When that bit gets zero, the response can be read immediately (immediately for MOST commands, but not ALL commands; so better wait for the IRQ). Alternately, you can wait for an IRQ (which seems to take place MUCH later), and then read the response. If there are any pending cdrom interrupts, these MUST be acknowledged before sending the command (otherwise bit7 of 1F801800h will stay set forever).
"},{"location":"cdromdrive/#command-busy-flag-1f801800hbit7","title":"Command Busy Flag - 1F801800h.Bit7","text":"Indicates ready-to-send-new-command,
0=Ready to send a new command\n 1=Busy sending a command/parameters\nPause -> Wait for INT3 IRQ -> clear IRQ (write 0x1f to 1f801803h.0) -> SetMode/Pause/Stop/SetMode/SeekL/... <br/>\nReadN/ReadS -> Wait for INT3 IRQ -> clear IRQ (write 0x1f to 1f801803h.0) -> SetMode/SetLoc/... <br/>\nStop -> Wait for INT3 IRQ -> clear IRQ (write 0x1f to 1f801803h.0) -> SetMode/Pause/...<br/>\nTrying to do a 32bit read from 1F801800h returns the 8bit value at 1F801800h multiplied by 01010101h.
"},{"location":"cdromdrive/#to-init-the-cd","title":"To init the CD","text":" -Flush all IRQs\n -1F801803h.Index0=0\n -Com_Delay=4901 (=1325h) (Port 1F801020h) (means 16bit or 32bit write?)\n (the write seems to be 32bit, clearing the upper16bit of the register)\n -Send two Getstat commands\n -Send Command 0Ah (Init)\n -Demute\nWarning: most or all of the info in the sentence below appear to incorrect (either that, or I didn't understand that rather confusing sentence). REPORTEDLY: \"You should not send some commands while the CD is seeking (ie. Getstat returns with bit6 set). Thing is that stat only gets updated after a new command. I haven't tested this for other command, but for the play command (03h) you can just keep repeating the [which?] command and checking stat returned by that, for bit6 to go low (and bit7 to go high in this case). If you don't and try to do a getloc [GetlocP and/or GetlocL?] directly after the play command reports it's done [what done? meaning sending start-to-play was \"done\"? or meaning play reached end-of-disc?], the CD will stop. (I guess the CD can't get it's current location while it's seeking, so the logic stops the seek to get an exact fix, but never restarts..)\"
"},{"location":"cdromdrive/#sound-map-flowchart","title":"Sound Map Flowchart","text":"Sound Map mode allows to output XA-ADPCM from Main RAM (rather than from CDROM).
SPU: Init Master Volume Left/Right (Port 1F801D80h/1F801D82h)\n SPU: Init CD Audio Volume Left/Right (Port 1F801DB0h/1F801DB2h)\n SPU: Enable CD Audio (Port 1F801DAAh.Bit0=1)\n CDROM/CMD: send Stop command (probably better to avoid conflicts)\n CDROM/CMD: send Demute command (if muted) (but works only if disc inserted)\n CDROM/HOST: init Codinginfo (Port 1F801801h.Index2)\n CDROM/HOST: enable ADPCM (Port 1F801803h.Index3.Bit0=0) ;probably needed?\n ... set dummy addr/len with DISHXFRC=1 ? <-- NOT required !\n ... set SMEN ... and dummy BFWR? <-- BOTH bits required ?\n ... maybe SMADPCLR (1F801803h.Index1.bit5) does clear SoundMap ADPCM buf?\n transfer 900h bytes (same format as ADPCM sectors) (Port 1F801801h.Index1)\n Note: Before sending a byte, one should wait for DRQs (1F801801h.Bit6=1)\n Note: ADPCM output doesn't start until the last (900h'th) byte is transferred\n Command Parameters Response(s)\n 00h - - INT5(11h,40h) ;reportedly \"Sync\" uh?\n 01h Getstat - INT3(stat)\n 02h Setloc E amm,ass,asect INT3(stat)\n 03h Play E (track) INT3(stat), optional INT1(report bytes)\n 04h Forward E - INT3(stat), optional INT1(report bytes)\n 05h Backward E - INT3(stat), optional INT1(report bytes)\n 06h ReadN E - INT3(stat), INT1(stat), datablock\n 07h MotorOn E - INT3(stat), INT2(stat)\n 08h Stop E - INT3(stat), INT2(stat)\n 09h Pause E - INT3(stat), INT2(stat)\n 0Ah Init - INT3(late-stat), INT2(stat)\n 0Bh Mute E - INT3(stat)\n 0Ch Demute E - INT3(stat)\n 0Dh Setfilter E file,channel INT3(stat)\n 0Eh Setmode mode INT3(stat)\n 0Fh Getparam - INT3(stat,mode,null,file,channel)\n 10h GetlocL E - INT3(amm,ass,asect,mode,file,channel,sm,ci)\n 11h GetlocP E - INT3(track,index,mm,ss,sect,amm,ass,asect)\n 12h SetSession E session INT3(stat), INT2(stat)\n 13h GetTN E - INT3(stat,first,last) ;BCD\n 14h GetTD E track (BCD) INT3(stat,mm,ss) ;BCD\n 15h SeekL E - INT3(stat), INT2(stat) ;\\use prior Setloc\n 16h SeekP E - INT3(stat), INT2(stat) ;/to set target\n 17h - - INT5(11h,40h) ;reportedly \"SetClock\" uh?\n 18h - - INT5(11h,40h) ;reportedly \"GetClock\" uh?\n 19h Test sub_function depends on sub_function (see below)\n 1Ah GetID E - INT3(stat), INT2/5(stat,flg,typ,atip,\"SCEx\")\n 1Bh ReadS E?- INT3(stat), INT1(stat), datablock\n 1Ch Reset - INT3(stat), Delay ;-not DTL-H2000\n 1Dh GetQ E adr,point INT3(stat), INT2(10bytesSubQ,peak_lo) ;\\not\n 1Eh ReadTOC - INT3(late-stat), INT2(stat) ;/vC0\n 1Fh VideoCD sub,a,b,c,d,e INT3(stat,a,b,c,d,e) ;<-- SCPH-5903 only\n 1Fh..4Fh - - INT5(11h,40h) ;-Unused/invalid\n 50h Secret 1 - INT5(11h,40h) ;\\\n 51h Secret 2 \"Licensed by\" INT5(11h,40h) ;\n 52h Secret 3 \"Sony\" INT5(11h,40h) ; Secret Unlock Commands\n 53h Secret 4 \"Computer\" INT5(11h,40h) ; (not in version vC0, and,\n 54h Secret 5 \"Entertainment\" INT5(11h,40h) ; nonfunctional in japan)\n 55h Secret 6 \"<region>\" INT5(11h,40h) ;\n 56h Secret 7 - INT5(11h,40h) ;/\n 57h SecretLock - INT5(11h,40h) ;-Secret Lock Command\n 58h..5Fh Crash - Crashes the HC05 (jumps into a data area)\n 6Fh..FFh - - INT5(11h,40h) ;-Unused/invalid\nTest commands are invoked with command number 19h, followed by a sub_function number as first parameter byte. The Kernel seems to be using only sub_function 20h (to detect the CDROM Controller version).
sub params response ;Effect\n 00h - INT3(stat) ;Force motor on, clockwise, even if door open\n 01h - INT3(stat) ;Force motor on, anti-clockwise, super-fast\n 02h - INT3(stat) ;Force motor on, anti-clockwise, super-fast\n 03h - INT3(stat) ;Force motor off (ignored during spin-up)\n 04h - INT3(stat) ;Start SCEx reading and reset counters\n 05h - INT3(total,success);Stop SCEx reading and get counters\n 06h * n INT3(old) ;\\early ;Adjust balance in RAM, send CX(30+n XOR 7)\n 07h * n INT3(old) ; PSX ;Adjust gain in RAM, send CX(38+n XOR 7)\n 08h * n INT3(old) ;/only ;Adjust balance in RAM only\n 06h..0Fh - INT5(11h,10h) ;N/A (11h,20h when NONZERO number of params)\n 10h - INT3(stat) ;CX(..) ;Force motor on, anti-clockwise, super-fast\n 11h - INT3(stat) ;CX(03) ;Move Lens Up (leave parking position)\n 12h - INT3(stat) ;CX(02) ;Move Lens Down (enter parking position)\n 13h - INT3(stat) ;CX(28) ;Move Lens Outwards\n 14h - INT3(stat) ;CX(2C) ;Move Lens Inwards\n 15h - INT3(stat) ;CX(22) ;If motor on: Move outwards,inwards,motor off\n 16h - INT3(stat) ;CX(23) ;No effect?\n 17h - INT3(stat) ;CX(E8) ;Force motor on, clockwise, super-fast\n 18h - INT3(stat) ;CX(EA) ;Force motor on, anti-clockwise, super-fast\n 19h - INT3(stat) ;CX(25) ;No effect?\n 1Ah - INT3(stat) ;CX(21) ;No effect?\n 1Bh..1Fh - INT5(11h,10h) ;N/A (11h,20h when NONZERO number of params)\n 20h - INT3(yy,mm,dd,ver) ;Get cdrom BIOS date/version (yy,mm,dd,ver)\n 21h - INT3(n) ;Get Drive Switches (bit0=POS0, bit1=DOOR)\n 22h *** - INT3(\"for ...\") ;Get Region ID String\n 23h *** - INT3(\"CXD...\") ;Get Chip ID String for Servo Amplifier\n 24h *** - INT3(\"CXD...\") ;Get Chip ID String for Signal Processor\n 25h *** - INT3(\"CXD...\") ;Get Chip ID String for Decoder/FIFO\n 26h..2Fh - INT5(11h,10h) ;N/A (11h,20h when NONZERO number of params)\n 30h * i,x,y INT3(stat) ;Prototype/Debug stuff ;\\supported on\n 31h * x,y INT3(stat) ;Prototype/Debug stuff ; early PSX only\n 4xh * i INT3(x,y) ;Prototype/Debug stuff ;/\n 30h..4Fh .. INT5(11h,10h) ;N/A always 11h,10h (no matter of params)\n 50h a[,b[,c]] INT3(stat) ;Servo/Signal send CX(a:b:c)\n 51h ** 39h,xx INT3(stat,hi,lo) ;Servo/Signal send CX(39xx) with response\n 51h..5Fh - INT5(11h,10h) ;N/A\n 60h lo,hi INT3(databyte) ;HC05 SUB-CPU read RAM and I/O ports\n 61h..70h - INT5(11h,10h) ;N/A\n 71h *** adr INT3(databyte) ;Decoder Read one register\n 72h *** adr,dat INT3(stat) ;Decoder Write one register\n 73h *** adr,len INT3(databytes..);Decoder Read multiple registers, bugged\n 74h *** adr,len,..INT3(stat) ;Decoder Write multiple registers, bugged\n 75h *** - INT3(lo,hi,lo,hi);Decoder Get Host Xfer Info Remain/Addr\n 76h *** a,b,c,d INT3(stat) ;Decoder Prepare Transfer to/from SRAM\n 77h..FFh - INT5(11h,10h) ;N/A\n 80h..8Fh a,b ? ;seem to do something on PS2\nINT5 will be returned if the command is unsupported. That, WITHOUT removing the Parameters from the FIFO, so the parameters will be accidently passed to the NEXT command. To avoid that: clear the parameter FIFO via [1F801803h.Index1]=40h after receiving the INT5 error.
"},{"location":"cdromdrive/#cdrom-control-commands","title":"CDROM - Control Commands","text":""},{"location":"cdromdrive/#sync-command-00h-intxstat140h","title":"Sync - Command 00h --> INTx(stat+1,40h) (?)","text":"Reportedly \"command does not succeed until all other commands complete. This can be used for synchronization - hence the name.\" Uh, actually, returns error code 40h = Invalid Command...?
"},{"location":"cdromdrive/#setfilter-command-0dhfilechannel-int3stat","title":"Setfilter - Command 0Dh,file,channel --> INT3(stat)","text":"Automatic ADPCM (CD-ROM XA) filter ignores sectors except those which have the same channel and file numbers in their subheader. This is the mechanism used to select which of multiple songs in a single .XA file to play. Setfilter does not affect actual reading (sector reads still occur for all sectors). XXX err... that is... does not affect reading of non-ADPCM sectors (normal \"data\" sectors are kept received regardless of Setfilter).
"},{"location":"cdromdrive/#setmode-command-0ehmode-int3stat","title":"Setmode - Command 0Eh,mode --> INT3(stat)","text":" 7 Speed (0=Normal speed, 1=Double speed)\n 6 XA-ADPCM (0=Off, 1=Send XA-ADPCM sectors to SPU Audio Input)\n 5 Sector Size (0=800h=DataOnly, 1=924h=WholeSectorExceptSyncBytes)\n 4 Ignore Bit (0=Normal, 1=Ignore Sector Size and Setloc position)\n 3 XA-Filter (0=Off, 1=Process only XA-ADPCM sectors that match Setfilter)\n 2 Report (0=Off, 1=Enable Report-Interrupts for Audio Play)\n 1 AutoPause (0=Off, 1=Auto Pause upon End of Track) ;for Audio Play\n 0 CDDA (0=Off, 1=Allow to Read CD-DA Sectors; ignore missing EDC)\nMultiple effects at once. Sets mode=20h, activates drive motor, Standby, abort all commands.
"},{"location":"cdromdrive/#reset-command-1ch-int3stat-delay18-seconds","title":"Reset - Command 1Ch,(...) --> INT3(stat) --> Delay(1/8 seconds)","text":" Caution: Not supported on DTL-H2000 (v01)\nActivates the drive motor, works ONLY if the motor was off (otherwise fails with INT5(stat,20h); that error code would normally indicate \"wrong number of parameters\", but means \"motor already on\" in this case). Commands like Read, Seek, and Play are automatically starting the Motor when needed (which makes the MotorOn command rather useless, and it's rarely used by any games). Myth: Older homebrew docs are referring to MotorOn as \"Standby\", claiming that it would work similar as \"Pause\", that is wrong: the command does NOT pause anything (if the motor is on, then it does simply trigger INT5, but without pausing reading or playing). Note: The game \"Nightmare Creatures 2\" does actually attempt to use MotorOn to \"pause\" after reading files, but the hardware does simply ignore that attempt (aside from doing the INT5 thing).
"},{"location":"cdromdrive/#stop-command-08h-int3stat-int2stat","title":"Stop - Command 08h --> INT3(stat) --> INT2(stat)","text":"Stops motor with magnetic brakes (stops within a second or so) (unlike power-off where it'd keep spinning for about 10 seconds), and moves the drive head to the begin of the first track. Official way to restart is command 0Ah, but almost any command will restart it. The first response returns the current status (this already with bit5 cleared), the second response returns the new status (with bit1 cleared).
"},{"location":"cdromdrive/#pause-command-09h-int3stat-int2stat","title":"Pause - Command 09h --> INT3(stat) --> INT2(stat)","text":"Aborts Reading and Playing, the motor is kept spinning, and the drive head maintains the current location within reasonable error. The first response returns the current status (still with bit5 set if a Read command was active), the second response returns the new status (with bit5 cleared).
"},{"location":"cdromdrive/#dataadpcm-sector-filteringdelivery","title":"Data/ADPCM Sector Filtering/Delivery","text":"The PSX CDROM BIOS is first trying to send sectors to the ADPCM decoder, and, if that didn't work out, then it's trying to send them to the main CPU (and if that didn't work out either, then it's silently ignoring the sector).
try_deliver_as_adpcm_sector:\n reject if CD-DA AUDIO format\n reject if sector isn't MODE2 format\n reject if adpcm_disabled(setmode.6)\n reject if filter_enabled(setmode.3) AND selected file/channel doesn't match\n reject if submode isn't audio+realtime (bit2 and bit6 must be both set)\n deliver: send sector to xa-adpcm decoder when passing above cases\n try_deliver_as_data_sector:\n reject data-delivery if \"try_deliver_as_adpcm_sector\" did do adpcm-delivery\n reject if filter_enabled(setmode.3) AND submode is audio+realtime (bit2+bit6)\n 1st delivery attempt: send INT1+data, unless there's another INT pending\n delay, and retry at later time... but this time with file/channel checking!\n reject if filter_enabled(setmode.3) AND selected file/channel doesn't match\n 2nd delivery attempt: send INT1+data, unless there's another INT pending\nSets the seek target - but without yet starting the seek operation. The actual seek is invoked by certain commands: SeekL (Data) and SeekP (Audio) are doing plain seeks (and do Pause after completion). ReadN/ReadS are similar to SeekL (and do start reading data after the seek operation). Play is similar to SeekP (and does start playing audio after the seek operation). The amm,ass,asect parameters refer to the entire disk (not to the current track). To seek to a specific location within a specific track, use GetTD to get the start address of the track, and add the desired time offset to it.
"},{"location":"cdromdrive/#seekl-command-15h-int3stat-int2stat","title":"SeekL - Command 15h --> INT3(stat) --> INT2(stat)","text":"Seek to Setloc's location in data mode (using data sector header position data, which works/exists only on Data tracks, not on CD-DA Audio tracks). After the seek, the disk stays on the seeked location forever (namely: when seeking sector N, it does stay at around N-8..N-0 in single speed mode, or at around N-5..N+2 in double speed mode). This command will stop any current or pending ReadN or ReadS. Trying to use SeekL on Audio CDs passes okay on the first response, but (after two seconds or so) the second response will return an error (stat+4,04h), and stop the drive motor... that error doesn't appear ALWAYS though... works in some situations... such like when previously reading data sectors or so...?
"},{"location":"cdromdrive/#seekp-command-16h-int3stat-int2stat","title":"SeekP - Command 16h --> INT3(stat) --> INT2(stat)","text":"Seek to Setloc's location in audio mode (using the Subchannel Q position data, which works on both Audio on Data disks). After the seek, the disk stays on the seeked location forever (namely: when seeking sector N, it does stay at around N-9..N-1 in single speed mode, or at around N-2..N in double speed mode). This command will stop any current or pending ReadN or ReadS. Note: Some older docs claim that SeekP would recurse only \"MM:SS\" of the \"MM:SS:FF\" position from Setloc - that is wrong, it does seek to MM:SS:FF (verified on a PSone). After the seek, status is stat.bit7=0 (ie. audio playback off), until sending a new Play command (without parameters) to start playback at the seeked location.
"},{"location":"cdromdrive/#setsession-command-12hsession-int3stat-int2stat","title":"SetSession - Command 12h,session --> INT3(stat) --> INT2(stat)","text":"Seeks to session (ie. moves the drive head to the session, with stat bit6 set during the seek phase). When issued during active-play, the command returns error code 80h. When issued during play-spin-up, play is aborted.
___Errors___\n session = 00h causes error code 10h. ;INT5(03h,10h), no 2nd/3rd response\n ___On a non-multisession-disk___\n session = 01h passes okay. ;INT3(stat), and once INT2(stat)\n session = 02h or higher cause seek error ;INT3(stat), and twice INT5(06h,40h)\n ___On a multisession-disk with N sessions___\n session = 01h..N+1 passes okay ;where N+1 moves to the END of LAST session\n session = N+2 or higher cause seek error ;2nd response = INT5(06h,20h)\nRead with retry. The command responds once with \"stat,INT3\", and then it's repeatedly sending \"stat,INT1 --> datablock\", that is continued even after a successful read has occured; use the Pause command to terminate the repeated INT1 responses. Unknown which responses are sent in case of read errors? ==== ReadN and ReadS cause errors if you're trying to read an unlicensed CD or CD-R without a mod chip. Sectors on Audio CDs can be read only when CDDA is enabled via Setmode (otherwise error code 40h is returned). ==== Actually, Read seems to work on unlicensed CD-R's, but the returned data is the whole sector or so (the 2048 data bytes preceeded by a 12byte header, and probably/maybe followed by error-correction info; in fact the total received data in the Data Fifo is 4096 bytes; the last some bytes probably being garbage) (however error correction is NOT performed by hardware, so the 2048 data bytes may be trashy) (however, if the error correction info IS received, then error correction could be performed by software) (also Setloc doesn't seem to work accurately on unlicensed CD-R's). ====
;Read occasionally returns 11h,40h ..? when TOC isn't loaded?\n [1F801800h]=00h\n 00h=[1F801800h]\n [1F801803h]=00h\n 00h=[1F801803h]\n [1F801800h]=00h\n [1F801803h]=80h\n [1F801018h]=00020943h ;cdrom_delay\n [1F801020h]=0000132Ch ;com_delay\n x=[1F8010F4h] AND 00FFFFFFh ;result is 00840000h\n [1F8010F4h] = x OR 00880000h\n [1F8010F0h] = [1F8010F0h] OR 00008000h\n [1F8010B0h] = A0010000h ;addr\n [1F8010B4h] = 00010200h ;LSBs=num words, MSBs=ignored/bullshit\n [1F8010B4h] = 11000000h ;DMA control\n [1F801800h]=01h\n [1F801803h]=40h ;reset parameter fifo\n [0]=00000000h\n [0]=00000001h\n [0]=00000002h\n [0]=00000003h\n [1F801800h]=00h\n [1F801801h]=09h ;command9 (pause)\nRead without automatic retry. Not sure what that means... does WHAT on errors? Maybe intended for continous streaming video output (to skip bad frames, rather than to interrupt the stream by performing read-retrys).
"},{"location":"cdromdrive/#readnreads","title":"ReadN/ReadS","text":"Both ReadN/ReadS are reading data sequentially, starting at the sector specified with Setloc, and then automatically reading the following sectors.
"},{"location":"cdromdrive/#cdrom-incoming-data-buffer-overrun-timings","title":"CDROM Incoming Data / Buffer Overrun Timings","text":"The Read commands are continously receiving 75 sectors per second (or 150 sectors at double speed), and, basically, the software must be fast enough to process that amount of incoming data. However, the PSX hardware includes a buffer that can hold up to a handful (exact number is unknown?) of sectors, so, occasional delays of more than 1/75 seconds between processing two sectors aren't causing lost sectors, unless the delay(s) are summing up too much. The relevant steps for receiving data are:
Wait for Interrupt Request (INT1) ;indicates that data is available\n Send Data Request (1F801803h.Index0.Bit7=1);accept data\n Acknowledge INT1 ;\n Copy Data to Main RAM (via I/O or DMA) ;read data\n Caution: Supported only in BIOS version vC1 and up. Not supported in vC0.\nA normal CDROM access (such like reading a file) consists of three commands:
Setloc, Read, Pause\nThe 8bit status code is returned by Getstat command (and many other commands), the meaning of the separate stat bits is:
7 Play Playing CD-DA ;\\only ONE of these bits can be set\n 6 Seek Seeking ; at a time (ie. Read/Play won't get\n 5 Read Reading data sectors ;/set until after Seek completion)\n 4 ShellOpen Once shell open (0=Closed, 1=Is/was Open)\n 3 IdError (0=Okay, 1=GetID denied) (also set when Setmode.Bit4=1)\n 2 SeekError (0=Okay, 1=Seek error) (followed by Error Byte)\n 1 Spindle Motor (0=Motor off, or in spin-up phase, 1=Motor on)\n 0 Error Invalid Command/parameters (followed by Error Byte)\n ___These values appear in the FIRST response; with stat.bit0 set___\n 10h - Invalid Sub_function (for command 19h), or invalid parameter value\n 20h - Wrong number of parameters\n 40h - Invalid command\n 80h - Cannot respond yet (eg. required info was not yet read from disk yet)\n (namely, TOC not-yet-read or so)\n (also appears if no disk inserted at all)\n ___These values appear in the SECOND response; with stat.bit2 set___\n 04h - Seek failed (when trying to use SeekL on Audio CDs)\n ___These values appear even if no command was sent; with stat.bit2 set___\n 08h - Drive door became opened\nWhen the shell is opened, INT5 is triggered regardless of whether a command was executing or not. When this happens, all bits except shell open and error are cleared in the status register. The error byte in the INT5 is set to 08h.
Some games send a Stop command before changing discs, but others just wait for the user to open the shell, causing the disc to stop. The game can then send GetStat commands, looping until bit 4 is cleared to detect when the new disc has been inserted.
"},{"location":"cdromdrive/#stat-seekplayread-bits","title":"Stat Seek/Play/Read bits","text":"There's is only max ONE of the three Seek/Play/Read bits set at a time, ie. during Seek, ONLY the seek bit is set (and Read or Play doesn't get until seek completion), that is important for Gran Turismo 1, which checks for seek completion by waiting for READ getting set (rather than waiting for SEEK getting cleared).
"},{"location":"cdromdrive/#getstat-command-01h-int3stat","title":"Getstat - Command 01h --> INT3(stat)","text":"Returns stat (like many other commands), and additionally does reset the shell open flag (for the following commands; unless the shell is still opened). This is different as for most or all other commands (which may return stat, but which do not reset the shell open flag). In other docs, the command is eventually referred to as \"Nop\", believing that it does nothing than returning stat (ignoring the fact that it's having the special shell open reset feature).
"},{"location":"cdromdrive/#getparam-command-0fh-int3statmodenullfilechannel","title":"Getparam - Command 0Fh --> INT3(stat,mode,null,file,channel)","text":"Returns stat (see Getstat above), mode (see Setmode), a null byte (always 00h), and file/channel filter values (see Setfilter).
"},{"location":"cdromdrive/#getlocl-command-10h-int3ammassasectmodefilechannelsmci","title":"GetlocL - Command 10h --> INT3(amm,ass,asect,mode,file,channel,sm,ci)","text":"Retrieves 4-byte sector header, plus 4-byte subheader of the current sector. GetlocL can be send during active Read commands (but, mind that the GetlocL-INT3-response can't be received until any pending Read-INT1's are acknowledged). The PSX hardware can buffer a handful of sectors, the INT1 handler receives the \\<oldest> buffered sector, the GetlocL command returns the header and subheader of the \\<newest> buffered sector. Note: If the returned \\<newest> sector number is much bigger than the expected \\<oldest> sector number, then it's likely that a buffer overrun has occured. GetlocL fails (with error code 80h) when playing Audio CDs (or Audio Tracks on Data CDs). These errors occur because Audio sectors don't have any header/subheader (instead, equivalent data is stored in Subchannel Q, which can be read with GetlocP). GetlocL also fails (with error code 80h) when the drive is in Seek phase (such like shortly after a new ReadN/ReadS command). In that case one can retry issuing GetlocL (until it passes okay, ie. until the seek has completed). During Seek, the drive seems to decode only Subchannel position data (but no header/subheader data), accordingly GetlocL won't work during seek (however, GetlocP does work during Seek).
"},{"location":"cdromdrive/#getlocp-command-11h-int3trackindexmmsssectammassasect","title":"GetlocP - Command 11h - INT3(track,index,mm,ss,sect,amm,ass,asect)","text":"Retrieves 8 bytes of position information from Subchannel Q with ADR=1. Mainly intended for displaying the current audio position during Play. All results are in BCD.
track: track number (AAh=Lead-out area) (FFh=unknown, toc, none?)\n index: index number (Usually 01h)\n mm: minute number within track (00h and up)\n ss: second number within track (00h to 59h)\n sect: sector number within track (00h to 74h)\n amm: minute number on entire disk (00h and up)\n ass: second number on entire disk (00h to 59h)\n asect: sector number on entire disk (00h to 74h)\nGet first track number, and last track number in the TOC of the current Session. The number of tracks in the current session can be calculated as (last-first+1). The first track number is usually 01h in the first (or only) session, and \"last track of previous session plus 1\" in further sessions.
"},{"location":"cdromdrive/#gettd-command-14htrack-int3statmmss-bcd","title":"GetTD - Command 14h,track --> INT3(stat,mm,ss) ;BCD","text":"For a disk with NN tracks, parameter values 01h..NNh return the start of the specified track, parameter value 00h returns the end of the last track, and parameter values bigger than NNh return error code 10h. The GetTD values are relative to Index=1 and are rounded down to second boundaries (eg. if track=N Index=0 starts at 12:34:56, and Track=N Index=1 starts at 12:36:56, then GetTD(N) will return 12:36, ie. the sector number is truncated, and the Index=0 region is skipped).
"},{"location":"cdromdrive/#getq-command-1dhadrpoint-int3stat-int210bytessubqpeak_lo","title":"GetQ - Command 1Dh,adr,point --> INT3(stat) --> INT2(10bytesSubQ,peak_lo)","text":" Caution: Supported only in BIOS version vC1 and up. Not supported in vC0.\n Caution: When unsupported, Parameter Fifo isn't cleared after the command.\n Drive Status 1st Response 2nd Response\n Door Open INT5(11h,80h) N/A\n Spin-up INT5(01h,80h) N/A\n Detect busy INT5(03h,80h) N/A\n No Disk INT3(stat) INT5(08h,40h, 00h,00h, 00h,00h,00h,00h)\n Audio Disk INT3(stat) INT5(0Ah,90h, 00h,00h, 00h,00h,00h,00h)\n Unlicensed:Mode1 INT3(stat) INT5(0Ah,80h, 00h,00h, 00h,00h,00h,00h)\n Unlicensed:Mode2 INT3(stat) INT5(0Ah,80h, 20h,00h, 00h,00h,00h,00h)\n Unlicensed:Mode2+Audio INT3(stat) INT5(0Ah,90h, 20h,00h, 00h,00h,00h,00h)\n Debug/Yaroze:Mode2 INT3(stat) INT2(02h,00h, 20h,00h, 20h,20h,20h,20h)\n Licensed:Mode2 INT3(stat) INT2(02h,00h, 20h,00h, 53h,43h,45h,4xh)\n Modchip:Audio/Mode1 INT3(stat) INT2(02h,00h, 00h,00h, 53h,43h,45h,4xh)\n 1st byte: stat (as usually, but with bit3 same as bit7 in 2nd byte)\n 2nd byte: flags (bit7=denied, bit4=audio... or reportedly import, uh?)\n bit7: Licensed (0=Licensed Data CD, 1=Denied Data CD or Audio CD)\n bit6: Missing (0=Disk Present, 1=Disk Missing)\n bit4: Audio CD (0=Data CD, 1=Audio CD) (always 0 when Modchip installed)\n 3rd byte: Disk type (from TOC Point=A0h) (eg. 00h=Audio or Mode1, 20h=Mode2)\n 4th byte: Usually 00h (or 8bit ATIP from Point=C0h, if session info exists)\n that 8bit ATIP value is taken form the middle 8bit of the 24bit ATIP value\n 5th-8th byte: SCEx region (eg. ASCII \"SCEE\" = Europe) (0,0,0,0 = Unlicensed)\nTo play CD-DA Audio CDs, init the following SPU Registers: CD Audio Volume, Main Volume, and SPU Control Bit0. Then send Demute command, and Play command.
"},{"location":"cdromdrive/#mute-command-0bh-int3stat","title":"Mute - Command 0Bh --> INT3(stat)","text":"Turn off audio streaming to SPU (affects both CD-DA and XA-ADPCM). Even when muted, the CDROM controller is internally processing audio sectors (as seen in 1F801800h.Bit2, which works as usually for XA-ADPCM), muting is just forcing the CD output volume to zero. Mute is used by Dino Crisis 1 to mute noise during modchip detection.
"},{"location":"cdromdrive/#demute-command-0ch-int3stat","title":"Demute - Command 0Ch --> INT3(stat)","text":"Turn on audio streaming to SPU (affects both CD-DA and XA-ADPCM). The Demute command is needed only if one has formerly used the Mute command (by default, the PSX is demuted after power-up (...and/or after Init command?), and is demuted after cdrom-booting).
"},{"location":"cdromdrive/#play-command-03h-track-int3stat-optional-int1report-bytes","title":"Play - Command 03h (,track) --> INT3(stat) --> optional INT1(report bytes)","text":"Starts CD Audio Playback. The parameter is optional, if there's no parameter given (or if it is 00h), then play either starts at Setloc position (if there was a pending unprocessed Setloc), or otherwise starts at the current location (eg. the last point seeked, or the current location of the current song; if it was already playing). For a disk with N songs, Parameters 1..N are starting the selected track. Parameters N+1..99h are restarting the begin of current track. The motor is switched off automatically when Play reaches the end of the disk, and INT4(stat) is generated (with stat.bit7 cleared). The track parameter seems to be ignored when sending Play shortly after power-up (ie. when the drive hasn't yet read the TOC). === \"Play is almost identical to CdlReadS, believe it or not. The main difference is that this does not trigger a completed read IRQ. CdlPlay may be used on data sectors. However, all sectors from data tracks are treated as 00, so no sound is played. As CdlPlay is reading, the audio data appears in the sector buffer, but is not reliable. Game Shark \"enhancement CDs\" for the 2.x and 3.x versions used this to get around the PSX copy protection.\" Hmmm, what/where is the sector buffer... in the SPU? And, what/who are the 2.x and 3.x versions?
"},{"location":"cdromdrive/#forward-command-04h-int3stat-optional-int1report-bytes","title":"Forward - Command 04h --> INT3(stat) --> optional INT1(report bytes)","text":""},{"location":"cdromdrive/#backward-command-05h-int3stat-optional-int1report-bytes","title":"Backward - Command 05h --> INT3(stat) --> optional INT1(report bytes)","text":"After sending the command, the drive is in fast forward/backward mode, skipping every some sectors. The skipping rate is fixed (it doesn't increase after some seconds) (however, it increases when (as long as) sending the command again and again). The sound becomes (obviously) non-continous, and also rather very silent, muffled, and almost inaudible (that's making it rather useless; unless it's combined with a track/minute/second display). To terminate forward/backward, send a new Play command (with no parameters, so play starts at the \"searched\" location). Backward automatically switches to Play when reaching the begin of Track 1. Forward automatically Stops the drive motor with INT4(stat) when reaching the end of the last track. Forward/Backwards work only if the drive was in Play state, and only if Play had already started (ie. not shortly/immediately after a Play command); if the drive was not in Play state, then INT5(stat+1,80h) occurs.
"},{"location":"cdromdrive/#setmode-bits-used-for-play-command","title":"Setmode bits used for Play command","text":"During Play, only bit 7,2,1 of Setmode are used, all other Setmode bits are ignored (that, including bit0, ie. during Play the drive is always in CD-DA mode, regardless of that bit). Bit7 (double speed) should be usually off, although it can be used for a fast forward effect (with audible output). Bit2 (report) activates an optional interrupt for Play, Forward, and Backward commands (see below). Bit1 (autopause) pauses play at the end of the track.
"},{"location":"cdromdrive/#report-int1stattrackindexmmammss80hasssectasectpeaklopeakhi","title":"Report --> INT1(stat,track,index,mm/amm,ss+80h/ass,sect/asect,peaklo,peakhi)","text":"With report enabled via Setmode, the Play, Forward, and Backward commands do repeatedly generate INT1 interrupts, with eight bytes response length. The interrupt isn't generated on ALL sectors, and the response changes between absolute time, and time within current track (the latter one indicated by bit7 of ss):
amm/ass/asect are returned on asect=00h,20h,40h,60h ;-absolute time\n mm/ss+80h/sect are returned on asect=10h,30h,50h,70h ;-within current track\n (or, in case of read errors, report may be returned on other asect's)\nAutopause can be enabled/disabled via Setmode.bit1:
Setmode.bit1=1: AutoPause=On --> Issue INT4(stat) and PAUSE at end of TRACK\n Setmode.bit1=0: AutoPause=Off --> Issue INT4(stat) and STOP at end of DISC\nAside from normal uncompressed CD Audio disks, the PSX can also play XA-ADPCM compressed sectors. XA-ADPCM sectors are organized in Files (not in tracks), and are \"played\" with Read command (not Play command). To play XA-ADPCM, initialize the SPU for CD Audio input (as described above), enable ADPCM via Setmode, then select the sector via Setloc, and issue a Read command (typically ReadS). XA-ADPCM sectors are interleaved, ie. only each Nth sector should be played (where \"N\" depends on the Motor Speed, mono/stereo format, and sample rate). If the \"other\" sectors do contain XA-ADPCM data too, then the Setfilter command (and XA-Filter enable flag in Setmode) must be used to select the desired sectors. If the \"other\" sectors do contain code or data (eg. MDEC video data) which is wanted to be send to the CPU, then SetFilter isn't required to be enabled (although it shouldn't disturb reading even if it is enabled). If XA-ADPCM (and/or XA-Filter) is enabled via Setmode, then INT1 is generated only for non-ADPCM sectors. The Setmode sector-size selection is don't care for forwarding XA-ADPCM sectors to the SPU (the hardware does always decompress all 900h bytes).
"},{"location":"cdromdrive/#cdrom-test-commands","title":"CDROM - Test Commands","text":"CDROM - Test Commands - Version, Switches, Region, Chipset, SCEx CDROM - Test Commands - Test Drive Mechanics CDROM - Test Commands - Prototype Debug Transmission CDROM - Test Commands - Read/Write Decoder RAM and I/O Ports CDROM - Test Commands - Read HC05 SUB-CPU RAM and I/O Ports
"},{"location":"cdromdrive/#cdrom-test-commands-version-switches-region-chipset-scex","title":"CDROM - Test Commands - Version, Switches, Region, Chipset, SCEx","text":""},{"location":"cdromdrive/#19h20h-int3yymmddver","title":"19h,20h --> INT3(yy,mm,dd,ver)","text":"Indicates the date (Year-month-day, in BCD format) and version of the HC05 CDROM controller BIOS. Known/existing values are:
(unknown) ;DTL-H2000 (with SPC700 instead HC05)\n 94h,09h,19h,C0h ;PSX (PU-7) 19 Sep 1994, version vC0 (a)\n 94h,11h,18h,C0h ;PSX (PU-7) 18 Nov 1994, version vC0 (b)\n 94h,11h,28h,01h ;PSX (DTL-H2000) 28 Nov 1994, version v01 (debug)\n 95h,05h,16h,C1h ;PSX (LATE-PU-8) 16 May 1995, version vC1 (a)\n 95h,07h,24h,C1h ;PSX (LATE-PU-8) 24 Jul 1995, version vC1 (b)\n 95h,07h,24h,D1h ;PSX (LATE-PU-8,debug ver)24 Jul 1995, version vD1 (debug)\n 96h,08h,15h,C2h ;PSX (PU-16, Video CD) 15 Aug 1996, version vC2 (VCD)\n 96h,08h,18h,C1h ;PSX (LATE-PU-8,yaroze) 18 Aug 1996, version vC1 (yaroze)\n 96h,09h,12h,C2h ;PSX (PU-18) (japan) 12 Sep 1996, version vC2 (a.jap)\n 97h,01h,10h,C2h ;PSX (PU-18) (us/eur) 10 Jan 1997, version vC2 (a)\n 97h,08h,14h,C2h ;PSX (PU-20) 14 Aug 1997, version vC2 (b)\n 98h,06h,10h,C3h ;PSX (PU-22) 10 Jun 1998, version vC3 (a)\n 99h,02h,01h,C3h ;PSX/PSone (PU-23, PM-41) 01 Feb 1999, version vC3 (b)\n A1h,03h,06h,C3h ;PSone/late (PM-41(2)) 06 Jun 2001, version vC3 (c)\n (unknown) ;PS2, xx xxx xxxx, late PS2 models...?\nReturns the current status of the POS0 and DOOR switches.
Bit0 = HeadIsAtPos0 (0=No, 1=Pos0)\n Bit1 = DoorIsOpen (0=No, 1=Open)\n Bit2 = EjectButtonOrOutSwOrSo? (DTL-H2000 only) (always 0 on retail)\n Bit3-7 = AlwaysZero\n Caution: Supported only in BIOS version vC1 and up. Not supported in vC0.\n INT5(11h,10h) --> NTSC, Japan (vC0) --> requires \"SCEI\" discs\n INT3(\"for Europe\") --> PAL, Europe --> requires \"SCEE\" discs\n INT3(\"for U/C\") --> NTSC, North America --> requires \"SCEA\" discs\n INT3(\"for Japan\") --> NTSC, Japan / NTSC, Asia --> requires \"SCEI\" discs\n INT3(\"for NETNA\") --> Region-free yaroze version--> requires \"SCEx\" discs\n INT3(\"for US/AEP\") --> Region-free debug version --> accepts unlicensed CDRs\n Caution: Supported only in BIOS version vC1 and up. Not supported in vC0.\nResets the total/success counters to zero, and does then try to read the SCEx string from the current location (the SCEx is stored only in the Lead-In area, so, if the drive head is elsewhere, it will usually not find any strings, unless a modchip is permanently simulating SCEx strings). This is a raw test command (the successful or unsuccessful results do not lock/unlock the disk). The results can be read with command 19h,05h (which will terminate the SCEx reading), or they can be read from RAM with command 19h,60h,lo,hi (which doesn't stop reading). Wait 1-2 seconds before expecting any results. Note: Like 19h,00h, this command forces the drive motor to spin at standard speed (synchronized with the data on the disk), works even if the shell is open (but stops spinning after a while if the drive is empty).
"},{"location":"cdromdrive/#19h05h-int3totalsuccess-get-scex-counters","title":"19h,05h --> INT3(total,success) ;Get SCEx Counters","text":"Returns the total number of \"Sxxx\" strings received (where at least the first byte did match), and the number of full \"SCEx\" strings (where all bytes did match). Typically, the values are \"01h,01h\" for Licensed PSX Data CDs, or \"00h,00h\" for disk missing, unlicensed data CDs, Audio CDs. The counters are reset to zero, and SCEx receive mode is active for a few seconds after booting a new disk (on power up, on closing the drive door, on sending a Reset command, and on sub_function 04h). The disk is unlocked if the \"success\" counter is nonzero, the only exception is sub_function 04h which does update the counters, but does not lock/unlock the disk.
"},{"location":"cdromdrive/#cdrom-test-commands-test-drive-mechanics","title":"CDROM - Test Commands - Test Drive Mechanics","text":"Signal Processor and Servo Amplifier
"},{"location":"cdromdrive/#19h50hmsbmidlsbxlo-int3stat","title":"19h,50h,msb[,mid,[lsb[,xlo]]] --> INT3(stat)","text":"Sends an 8bit/16bit/24bit command to the hardware, depending on number of parameters:
1 byte --> send CX(Xx) ;short 8bit command\n 2 bytes --> send CX(Xxxx) ;longer 16bit command\n 3 bytes --> send CX(Xxxxxx) ;full 24bit command\n 4 bytes --> send CX(Xxxxxxxx) ;extended 32bit command (BIOS vC3 only)\n 4..15 bytes: acts same as max (3 or 4 bytes) (extra bytes are ignored)\n 0 bytes or more than 15 bytes: generates an error\nSupported by newer CDROM BIOSes only (such that use CXD2545Q or newer chips). Works same as 19h,50h, but does additionally receive a response. The command is always sending a 24bit CX(Xxxxxx) command, but it doesn't verify the number of parameter bytes (when using more than 3 bytes: extra bytes are ignored, when using less than 3 bytes: garbage is appended, which is somewhat valid because 8bit/16bit commands can be padded to 24bit size by appending \"don't care\" bits). The command can be used to send any CX(..) command, but actually it does make sense only for the get-status commands, see below \"19h,51h,39h,xxh\" description.
"},{"location":"cdromdrive/#19h51h39hxxh-int3stathilo-bios-vc2vc3-only","title":"19h,51h,39h,xxh --> INT3(stat,hi,lo) ;BIOS vC2/vC3 only","text":"Supported by newer CDROM BIOSes only (such that use CXD2545Q or newer chips). Sends CX(39xx) to the hardware, and receives a response (the response.hi byte is usually 00h for 8bit responses, or 00h..01h for 9bit responses). For example, this can be used to dump the Coefficient RAM.
"},{"location":"cdromdrive/#19h03h-int3stat-force-motor-off","title":"19h,03h --> INT3(stat) ;force motor off","text":"Forces the motor to stop spinning (ignored during spin-up phase).
"},{"location":"cdromdrive/#19h17h-int3stat-force-motor-on-clockwise-super-fast","title":"19h,17h --> INT3(stat) ;force motor on, clockwise, super-fast","text":""},{"location":"cdromdrive/#19h01h-int3stat-force-motor-on-anti-clockwise-super-fast","title":"19h,01h --> INT3(stat) ;force motor on, anti-clockwise, super-fast","text":""},{"location":"cdromdrive/#19h02h-int3stat-force-motor-on-anti-clockwise-super-fast","title":"19h,02h --> INT3(stat) ;force motor on, anti-clockwise, super-fast","text":""},{"location":"cdromdrive/#19h10h-int3stat-force-motor-on-anti-clockwise-super-fast","title":"19h,10h --> INT3(stat) ;force motor on, anti-clockwise, super-fast","text":""},{"location":"cdromdrive/#19h18h-int3stat-force-motor-on-anti-clockwise-super-fast","title":"19h,18h --> INT3(stat) ;force motor on, anti-clockwise, super-fast","text":"Forces the drive motor to spin at maximum speed (which is much faster than normal or double speed), in normal (clockwise), or reversed (anti-clockwise) direction. The commands work even if the shell is open. The commands do not try to synchronize the motor with the data on the disk (and do thus work even if no disk is inserted).
"},{"location":"cdromdrive/#19h00h-int3stat-force-motor-on-clockwise-even-if-shell-open","title":"19h,00h --> INT3(stat) ;force motor on, clockwise (even if shell open)","text":"This command seems to have effect only if the drive motor was off. If it was off, it does FFh-fills the TOC entries in RAM, and seek to the begin of the TOC at 98:30:00 or so (where minute=98 means minus two). From that location, it follows the spiral on the disk, although it does occassionally jump back some seconds. After clearing the TOC, the command does not write new data to the TOC buffer in RAM. Note: Like 19h,04h, this command forces the drive motor to spin at standard speed (synchronized with the data on the disk), works even if the shell is open (but stops spinning after a while if the drive is empty).
"},{"location":"cdromdrive/#19h11h-int3stat-move-lens-up-leave-parking-position","title":"19h,11h --> INT3(stat) ;Move Lens Up (leave parking position)","text":""},{"location":"cdromdrive/#19h12h-int3stat-move-lens-down-enter-parking-position","title":"19h,12h --> INT3(stat) ;Move Lens Down (enter parking position)","text":""},{"location":"cdromdrive/#19h13h-int3stat-move-lens-outwards-away-from-center-of-disk","title":"19h,13h --> INT3(stat) ;Move Lens Outwards (away from center of disk)","text":""},{"location":"cdromdrive/#19h14h-int3stat-move-lens-inwards-towards-center-of-disk","title":"19h,14h --> INT3(stat) ;Move Lens Inwards (towards center of disk)","text":"Moves the laser lens. The inwards/outwards commands do move ONLY the lens (ie. unlike as for Seek commands, the overall-laser-unit remains in place, only the lens is moved).
"},{"location":"cdromdrive/#19h15h-if-motor-on-move-head-outwards-inwards-motor-off","title":"19h,15h - if motor on: move head outwards + inwards + motor off","text":"Moves the drive head to outer-most and inner-most position. Note that the drive doesn't have a switch that'd tell the controller when it has reached the outer-most position (so it'll forcefully hit against the outer edge) (ie. using this command too often may destroy the drive mechanics). Note: The same destructive hit-outer-edge effect happens when using Setloc/Seek with too large values (like minute=99h).
"},{"location":"cdromdrive/#19h16h-int3stat-unknown-makes-some-noise-if-motor-is-on","title":"19h,16h --> INT3(stat) ;Unknown / makes some noise if motor is on","text":""},{"location":"cdromdrive/#19h19h-int3stat-unknown-no-effect","title":"19h,19h --> INT3(stat) ;Unknown / no effect","text":""},{"location":"cdromdrive/#19h1ah-int3stat-unknown-makes-some-noise-if-motor-is-on","title":"19h,1Ah --> INT3(stat) ;Unknown / makes some noise if motor is on","text":"Seem to have no effect? 19h,16h seems to Move Lens Inwards, too.
"},{"location":"cdromdrive/#19h06hnew-int3old-adjust-balance-in-ram-and-apply-it-via-cx30n","title":"19h,06h,new --> INT3(old) ;Adjust balance in RAM, and apply it via CX(30+n)","text":""},{"location":"cdromdrive/#19h07hnew-int3old-adjust-gain-in-ram-and-apply-it-via-cx38n","title":"19h,07h,new --> INT3(old) ;Adjust gain in RAM, and apply it via CX(38+n)","text":""},{"location":"cdromdrive/#19h08hnew-int3old-adjust-balance-in-ram-only","title":"19h,08h,new --> INT3(old) ;Adjust balance in RAM only","text":"These commands are supported only by older CDROM BIOS versions (those with CXA1782BR Servo Amplifier). Later BIOSes will respond with INT5(11h,20h) when trying to use these commands (because CXD2545Q and later Servo Amplifiers don't support the CX(30/38+n) commands).
"},{"location":"cdromdrive/#cdrom-test-commands-prototype-debug-transmission","title":"CDROM - Test Commands - Prototype Debug Transmission","text":""},{"location":"cdromdrive/#serial-debug-messages","title":"Serial Debug Messages","text":"Older CDROM BIOSes are supporting debug message transmission via serial bus, using lower 3bit of the HC05 \"databus\" combined with the so-called \"ROMSEL\" pin (which apparently doesn't refer to Read-Only-Memory, but rather something like Runtime-Output-Message, or whatever). Data is transferred in 24bit units (8bit command/index from HC05, followed by 16bit data to/from HC05), bigger messages are divided into multiple such 24bit snippets. There are no connectors for external debug hardware on any PSX mainboards, so the whole stuff seems to be dating back to prototypes. And it seems to be removed from later BIOSes (which appear to use \"ROMSEL\" as \"SCLK\"; for receiving status info from the new CXD2545Q chips).
"},{"location":"cdromdrive/#19h30hindexdat1dat2-int3stat-prototypedebug-stuff","title":"19h,30h,index,dat1,dat2 --> INT3(stat) ;Prototype/Debug stuff","text":""},{"location":"cdromdrive/#19h31hdat1dat2-int3stat-prototypedebug-stuff","title":"19h,31h,dat1,dat2 --> INT3(stat) ;Prototype/Debug stuff","text":""},{"location":"cdromdrive/#19h4xhindex-int3dat1dat2-prototypedebug-stuff","title":"19h,4xh,index --> INT3(dat1,dat2) ;Prototype/Debug stuff","text":"These functions are supported on older CDROM BIOS only; later BIOSes respond by INT5(11h,10h). The functions do not affect the CDROM operation (they do simple allow to transfer data between Main CPU and external debug hardware). Sub functions 30h and 31h may fail with INT5(11h,80h) when receiving wrong signals on the serial input line. Sub function \"4xh\" value can be 40h..4Fh (don't care).
"},{"location":"cdromdrive/#int5-debug-messages","title":"INT5 Debug Messages","text":"Alongsides to INT5 errors, the BIOS is usually also sending information via the above serial bus (the error info is divided into multiple 8bit+16bit snippets, and contains stat, error code, mode, current SubQ position, and most recently issued command).
"},{"location":"cdromdrive/#cdrom-test-commands-readwrite-decoder-ram-and-io-ports","title":"CDROM - Test Commands - Read/Write Decoder RAM and I/O Ports","text":"Caution: Below commands 19h,71h..76h are supported only in BIOS version vC1 and up. Not supported in vC0.
"},{"location":"cdromdrive/#19h71hindex-int3databyte-read-single-register","title":"19h,71h,index --> INT3(databyte) ;Read single register","text":"index can be 00h..1Fh, bigger values seem to be mirrored to \"index AND 1Fh\", with one exception: index 13h in NOT mirrored, instead, index 33h, 53h, 93h, B3h, D3h, F3h return INT5(stat+1,10h), and index 73h returns INT5(stat+1,20h). Aside from returning a value, the commands seem to DO something (like moving the drive head when a disk is inserted). Return values are usually:
index value\n 00h 04h ;04h=empty, 8Eh=licensed, 24h=audio\n 01h [0B1h] ;DCh=empty/licensed, DDh=audio\n 02h 00h\n 03h 00h ;or variable when disk inserted\n 04h 00h\n 05h 80h ;or 86h or 89h when disk inserted\n 06h C0h\n 07h 02h\n 08h 8Ah\n 09h C0h\n 0Ah 00h\n 0Bh C0h\n 0Ch [1F2h]\n 0Dh [1F3h]\n 0Eh 00h ;or 8Eh or E6h when disk inserted ;D4h/audio\n 0Fh 00h ;or sometimes 01h when disk inserted ;50h/audio\n 10h C0h\n 11h E0h\n 12h 71h\n 13h stat\n 14h FFh\n 15h..1Fh C0h-filled ;or 17h --> DEh\n ;other response on param xx16h,xx18h with xx>00h\nSame as read/write single register, but trying to transfer multiple registers at once. BUG: The transfer should range from 00h to len-1, but the loop counter is left uninitialized (set to X=48h aka \"command number 19h-minus-1-mul-2\" instead of X=00h). Causing to the function to read/write garbage at index 48h..FFh, it does then wrap to 00h and do the correct intended transfer, but the preceeding bugged part may have smashed RAM or I/O ports.
"},{"location":"cdromdrive/#19h75h-int3remainloremainhiaddrloaddrhi-get-host-xfer-info","title":"19h,75h --> INT3(remain.lo,remain.hi,addr.lo,addr.hi) ;Get Host Xfer Info","text":"Returns a 4-byte value. In my early tests, on the first day it returned B1h,CEh,4Ch,01h, on the next day 2Ch,E4h,95h,D5h, and on all following days 00h,C0h,00h,00h (no idea why/where the earlier values came from). The first byte seems to be always 00h; no matter of [1F0h]. The second byte seems to be always C0h; no matter of [1F1h]. The third,fourth bytes are [1F2h,1F3h]. That two bytes are 0Ch,08h after Read commands.
The first bytes are NOT affected by:\n destroying [1F0h] via too-many-parameters in command-buffer,\n changes to [1F1h] which may occur after read command (eg. may be 20h)\nPrepare Transfer to/from 32K SRAM. After INT3, data can be read (same way as sector data after INT1).
"},{"location":"cdromdrive/#cdrom-test-commands-read-hc05-sub-cpu-ram-and-io-ports","title":"CDROM - Test Commands - Read HC05 SUB-CPU RAM and I/O Ports","text":""},{"location":"cdromdrive/#19h60haddr_loaddr_hi-int3data-read-one-byte-from-drive-ram-or-io","title":"19h,60h,addr_lo,addr_hi --> INT3(data) ;Read one byte from Drive RAM or I/O","text":"Reads one byte from the controller's RAM or I/O area, see the memory map below for more info. Among others, the command allows to read Subchannel Q data, eg. at [200h..209h], including ADR=2/UPC/EAN and ADR=3/ISRC values (which are suppressed by GetlocP). Eg. wait for ADR\\<>2, then for ADR=2, then read the remaining 9 bytes (because of the delayed IRQs, this works only at single speed) (at double speed one can read only 5 bytes before the values get overwritten by new data). Unknown if older boards (with 4.00MHz oscillators) are fast enough to read all 10 SubQ bytes.
"},{"location":"cdromdrive/#cdrom-controller-io-area-and-ram-memory-map","title":"CDROM Controller I/O Area and RAM Memory Map","text":"First 40h bytes are I/O ports (as in MC68HC05 datasheet):
000h 4 FF 7B 00 FF (other when disk inserted)\n 004h 5 11 00 20 20 0C\n 009h 1 00 (when disk inserted: changes between 00 or 80)\n 00Ah 2 71 00\n 00Ch 1 00 (when disk inserted: changes between 00 or 80)\n 00Dh 3 20 20 20\n 010h 8 02 80 00 60 00 00 99(orBB) 98\n 018h 4 changes randomly (even when no disk inserted)\n 01Ch 3 40 00 41\n 01Fh 1 changes randomly (even when no disk inserted)\n 020h 30 20h-filled\n 03Eh 2 82h 20h\n 040h 4 08 00 00 00 ;or 98 07 xx 0B when disk inserted ;[40].Bit1=MUTE\n 044h 4 00h-filled\n 048h 3 40 20 00 ;or 58 71 0F when disk inserted\n 04Bh 1 changes randomly (nodisk: 00 or 80 / disk: BFh)\n 04Ch 1 Zero (or C0h)\n 04Dh 3 MM:SS:FF (begin of current track MM:SS:00h) (or increasing addr)\n 050h 10 Subchannel Q (adjusted position values)\n 05Ah 2 ...\n 05Ch 1 00h (or 64h)\n 05Dh 3 MM:SS:FF (current read address) (sticky address during pause)\n 060h 1 increments at circa 16Hz or so (or other rate when spinning)\n 061h 12 00h-filled ;or else when disk inserted\n 06Dh 1 01 ;or 0C when disk inserted\n 06Eh 2 SetFilter setting (file,channel)\n 070h 16 00h-filled ;or else when disk inserted\n 080h 8 00h-filled\n 088h 3 03:SS:FF (three, second, fraction)\n 08Bh 3 03:SS:FF (three, second, fraction)\n 08Eh 2 01 FF (or other values)\n 090h 1 00h (or 91h when disk inserted + spinning)\n 091h 13 Zero\n 09Eh 1 00h (or 01h when disk inserted + spinning)\n 09Fh 1 Zero\n 0A0h 1 Always 23h\n 0A1h 1 09h (5Dh when disk inserted)\n 0A2h 7 00h-filled\n 0A9h 1 40\n 0AAh 4 00h-filled\n 0AEh 1 00 (no disk) or 01 (disk) or so\n 0AFh 1 00 ;or 06 when disk inserted\n 0B0h 7 00 DC 00 02 00 E0 08 ;\\or else when disk inserted\n 0B7h 1 20 ;Bit6+7=MUTE ;\n 0B8h 3 DE 00 00 ;/\n 0BBh 1 SetMode setting (mode)\n 0BCh 1 GetStat setting (stat)\n 0BDh 3 00h-filled\n 0C0h 6 FFh-filled ;stack... ;\\\n 0C6h 1 Usually DFh ;sometimes [0EBh and up] are non-FFh, too\n 0C7h 15 FFh-filled ;(depending on disk or commands or so)\n 0D6h 1 Usually FDh (or FFh) ; ;\n 0D7h 24 FFh-filled ; stack\n 0EFh 4 on power-up FFh-filled, other once when disk read ;\n 0F3h 7 changes randomly (even when no disk inserted) ;\n 0FAh 6 2E 3C 2A D6 10 95 ;/\n 100h 2x99 TOC Entries for Start of Track 1..99 (MM:SS)\n 1C6h 1 TOC First Track number (usually 01h)\n 1C7h 1 TOC Last Track number (usually 01h or higher)\n 1C8h 3 TOC Entry for Start of Lead-Out (MM:SS:FF)\n 1CBh 2 Zero\n 1CDh 1 Depends on disk (01 or 02 or 06) (or 00 when no disk)\n 1CEh 1 Zero\n 1CFh 1 Depends on disk (NULL minus N*6) (or 00 when no disk)\n (maybe reflection level / laser intensity or so)\n [1CDh..1CFh]\n 01 00 E8 --> licensed/metalgear/kain\n 01 00 EE --> licensed/alone2\n 06 00 E2 or 00 00 02 00 E8 --> licensed/wipeout\n 02 00 DC --> unlicensed/elo\n 02 00 D6 --> unlicensed/driver\n 00 00 EE --> audio/lola\n 00 00 FA --> audio/marilyn\n 00 00 F4 --> audio/westen\n 00 00 00 --> disk missing\n last byte is always in steps of 6\n 1D0h 4 SCEx String\n 1D4h 4 Zero\n 1D8h 2 SCEx Counters (total,success) ;for command 19h,05h\n 1DAh 6 00h-filled (or ... SS:FF)\n 1E0h 6 Command Buffer (usually 19h,60h,E2h,01h = Read RAM Command)\n 1E6h 7 00h-filled (unless destroyed by more-than-6-byte-commands)\n 1EDh 3 Setloc setting (MM:SS:FF)\n 1F0h 1 00h (unless destroyed by more-than-6-byte-commands)\n 1F1h 3 C0h 00h 00h ;or 20h,0Ch,50h or C0h,0Ch,08h ;for command(19h,75h)\n ;or 00h,00h,00h for audio\n ;or 80h,00h,00h for disk missing\n 1F4h 4 00h-filled ... or SCEx string\n 1F8h 1 00h\n 1F9h 1 Selected Target (parameter from Play and SetSession commands)\n 1FAh 5 00h-filled ;01 01 00 8B 00 00 ;or 01 02 8B 00 00\n 01 00 8B 00 00 -- audio/unlicensed\n 01 01 00 00 00 -- licensed\n 1FFh 1 00h-on power up, changes when disk inserted ;or 01 = Playing\n 1FDh 3 MM:SS:FF (only during command 19h,00h) (MM=98..99=TOC)\n 200h 10 Subchannel Q (real values)\n 20Ah 2 whatever\n 20Ch 1 Zero\n 20Dh 1 Desired Session (from SetSession command)\n 20Eh 1 Current Session (actual location of drive head)\n 20Fh 1 Zero\n 210h 10 Subchannel Q (adjusted position values)\n 21Ah 6 00h-filled\n 220h 4 Data Sector Header (MM:SS:FF:Mode)\n 224h 4 Data Sector CD-XA Subheader (file,channel,sm,ci)\n 228h 1 00h\n 229h 1 Usually 00h (shortly other value on power-up, and maybe on seek)\n 22Ah 1 10h (or 00h when no disk)\n 22Bh 3 00h-filled\n 22Eh 2 01,03 or 0A,00 or 03,01 (or else for other disk)\n 230h 3 00h-filled (or other during spin-up / read-toc or so)\n 233h 0Dh 00h-filled (unused RAM)\n 240h..2FFh - Invalid (00h-filled) (no ROM, RAM, or I/O mapped here)\n 300h..3FFh - Mirror of 200h..2FFh ;\\the BIOS is doing that\n 400h..FFFFh - Mirrors of 000h..3FFh ;/mirroring by software\nThis version allows to read the whole 64Kbyte memory space (withou mirroring everything to first 300h bytes). I/O Ports and Variables are at different locations:
000h..0DFh RAM Part 1 (C0h bytes)\n 0E0h..0FFh I/O Area\n 100h..1DFh RAM Part 2 (C0h bytes)\n 1E0h..1FFh I/O Area\n 200h..2DFh RAM Part 3 (100h bytes)\n 2E0h..7FFFh Unknown\n 8000h-BFFFh Unknown (lower 16K of 32K EPROM) (or unused?)\n C000h-FFFFh Firmware (upper 16K of 32K EPROM)\nThere is no command for writing to RAM. Except that, one can write to the command/parameter buffer at 1E0h and up. Normally, the longest known command should have 6 bytes (19h,76h,a,b,c,d), and longer commands results in \"bad number of parameters\" response - however, despite of that error message, the controller does still store ALL parameter bytes in RAM (at address 1E1h..2E0h, then wrapping back to 1E1h). Whereas, writing more than 16 bytes (FIFO storage size) will mirror the FIFO content twice, and more than 32 bytes (FIFO counter size) will work only when feeding extra data into the FIFO during transmission. Anyways, writing to 1E1h and up doesn't allow to do interesting things (such like manipulating the stack and executing custom code on the CPU).
"},{"location":"cdromdrive/#subchannel-q-notes","title":"Subchannel Q Notes","text":"The \"adjusted position values\" at 050h, 210h, 310h contain only position information (with ADR=1) (the PSX seems to check only the lower 2bit of the 4bit ADR value, so it also treats ADR=5 as ADR=1, too). Additionally, during Lead-In, bytes 7..9 are overwritten by the position value from bytes 3..5. The \"real values\" contain unadjusted data, including ADR=2 and ADR=3 etc.
"},{"location":"cdromdrive/#cdrom-secret-unlock-commands","title":"CDROM - Secret Unlock Commands","text":""},{"location":"cdromdrive/#secretunlockpart1-command-50h-int511h40h","title":"SecretUnlockPart1 - Command 50h --> INT5(11h,40h)","text":""},{"location":"cdromdrive/#secretunlockpart2-command-51hlicensed-by-int511h40h","title":"SecretUnlockPart2 - Command 51h,\"Licensed by\" --> INT5(11h,40h)","text":""},{"location":"cdromdrive/#secretunlockpart3-command-52hsony-int511h40h","title":"SecretUnlockPart3 - Command 52h,\"Sony\" --> INT5(11h,40h)","text":""},{"location":"cdromdrive/#secretunlockpart4-command-53hcomputer-int511h40h","title":"SecretUnlockPart4 - Command 53h,\"Computer\" --> INT5(11h,40h)","text":""},{"location":"cdromdrive/#secretunlockpart5-command-54hentertainment-int511h40h","title":"SecretUnlockPart5 - Command 54h,\"Entertainment\" --> INT5(11h,40h)","text":""},{"location":"cdromdrive/#secretunlockpart6-command-55hregion-int511h40h","title":"SecretUnlockPart6 - Command 55h,\\<region> --> INT5(11h,40h)","text":""},{"location":"cdromdrive/#secretunlockpart7-command-56h-int511h40h","title":"SecretUnlockPart7 - Command 56h --> INT5(11h,40h)","text":" Caution: Supported only in BIOS version vC1 and up. Not supported in vC0.\n Caution: Supported only in Europe/USA. Nonfunctional in Japan/Asia.\n Caution: When unsupported, Parameter Fifo isn't cleared after the command.\n \"of America\" ;for NTSC/US ;\\\n \"(Europe)\" ;for PAL/Europe ; handled, and actually working\n \"World wide\" ;for Yaroze ;/\n \"Inc.\" ;for NTSC/JP ;-non-functional\nUndoes the unlocking and restores the normal locked state (same happens when sending the Unlocking commands in wrong order or with wrong parameters).
"},{"location":"cdromdrive/#secretcrash-command-58h5fh-crash","title":"SecretCrash - Command 58h..5Fh --> Crash","text":"Jumps to a data area and executes random code. Results are more or less unpredictable (as they involve executing undefined opcodes). Eventually the CPU might hit a RET opcode and recover from the crash.
"},{"location":"cdromdrive/#cdrom-video-cd-commands","title":"CDROM - Video CD Commands","text":" Caution: Supported only on SCPH-5903, not supported on any other consoles.\n Caution: When unsupported, Parameter Fifo isn't cleared after the command.\n 1Fh VideoCD sub,a,b,c,d,e INT3(stat,a,b,c,d,e) ;<-- SCPH-5903 only\n 1Fh..4Fh - - INT5(11h,40h) ;-Unused/invalid\nThe JoyL/JoyH bytes contain 16bit button (and drive door) bits:
0 Drive Door (0=Open) (from CDROM stat bit4) ;Open\n 1 Button /\\ (0=Pressed) (from PSX pad bit12) ;N/A ;PBC: Back/LevelUp\n 2 Button [] (0=Pressed) (from PSX pad bit15) ;Enter Menu\n 3 Button () (0=Pressed) (from PSX pad bit13) ;Leave Menu ;PBC: Confirm\n 4 Button >< (0=Pressed) (from PSX pad bit14) ;N/A\n 5 Start (0=Pressed) (from PSX pad bit3) ;Play/Pause\n 6 Select (0=Pressed) (from PSX pad bit0) ;Stop (prompt restart/resume)\n 7 Always 0 (0) (fixed) ;N/A\n 8 DPAD Up (0=Pressed) (from PSX pad bit4) ;Menu Up ;PBC: +1\n 9 DPAD Right (0=Pressed) (from PSX pad bit5) ;Menu Right/change ;PBC: +10\n 10 DPAD Down (0=Pressed) (from PSX pad bit6) ;Menu Down ;PBC: -1\n 11 DPAD Left (0=Pressed) (from PSX pad bit7) ;Menu Left/change ;PBC: -10\n 12 Button R1 (0=Pressed) (from PSX pad bit11) ;Prev Track/Restart Track\n 13 Button R2 (0=Pressed) (from PSX pad bit9) ;Fast Forward (slowly)\n 14 Button L1 (0=Pressed) (from PSX pad bit10) ;Next Track (if any)\n 15 Button L2 (0=Pressed) (from PSX pad bit8) ;Fast Backward (slowly)\n 00h Motor Off (or spin-up) (when stat.bit1=0)\n 01h Playing (when stat.bit7=1)\n 02h Paused (and not seeking) (when stat.bit6=0)\n (note: State remains unchanged when seeking)\n 00h = Confirms that \"Tocread\" (aka setsession 1) request was processed\n 01h = Detect VCD Disc (used on power-up, and after door open) (after spin-up)\n 02h = Handshake (request ack response)\n 0Ah = Door opened during play (int5/door error)\n 80h = No disc\n FFh = No change (nop)\n 00h Normal (no special event occured and no action requested)\n 01h Request CD to Seek_and_play (using mm:ss:ff response parameter bytes)\n 02h Request CD to Pause ;cmd(09h) -->int3(stat),int2(stat)\n 03h Request CD to Stop ;cmd(08h) -->int3(stat),int2(stat)\n 04h Request CD to Tocread (setsession1);cmd(12h,01h)-->int3(stat),int2(stat)\n 05h Handshake Command was processed, and this is the \"ack\" response\n 06h Request CD to Fast Forward ;cmd(04h) -->int3(stat)\n 07h Request CD to Fast Backward ;cmd(05h) -->int3(stat)\n 80h Detect Command was processed, and disc was detected as VCD\n 81h Detect Command was processed, and disc was detected as Non-VCD\n 00h = Normal PSX Mode (PortF.3=LOW) (Audio/Video from GPU/SPU chips)\n 01h..FFh = Special VCD Mode (PortF.3=HIGH) (Audio/Video from MDEC/OSD chips)\nThe version/date is \"15 Aug 1996, version C2h\", although the \"C2h\" is misleading: The firmware is nearly identical to version \"C1h\" from PU-8 boards (the stuff added in normal \"C2h\" versions would be for PU-18 boards with different cdrom chipset).
Compared to the original C1h version, there are only a few changes: A initialization function for initializing port F on power-up. And new command (command 1Fh, inserted in the various command tables), with two subfunctions (01h and 02h): - Command 1Fh,01h,a,b,c,d,e --> INT3(stat,a,b,c,d,e) Serial 5-byte read-write - Command 1Fh,02h,v,x,x,x,x --> INT3(stat,0,0,x,x,x) Toggle 1bit (port F.bit3) Whereas,
x = don't care/garbage\n v = toggle state (00h=normal=PortF.3=LOW, 01h..FFh=special=PortF.3=HIGH)\n (toggle gpu vs mpeg maybe?)\n a,b,c,d,e = five bytes sent serially, and five bytes response received\n serially (send/receive done simultaneously)\nThe Port F bits are:
Port F.Bit0 = Serial Data In\n Port F.Bit1 = Serial Data Out\n Port F.Bit2 = Serial Clock Out\n Port F.Bit3 = Toggle (0=Normal, 1=Special)\nAnd that's about all. Ie. essentially, the only change is that the new command controls Port F. There is no interaction with the remaining firmware (ie. reading, seeking, and everything is working as usually, without any video-cd related changes). The SCEx stuff is also not affected (ie. Video CDs would be seen as unlicensed discs, so the PSX couldn't read anything from those discs, aside from Sub-Q position data, of course). The SCEx region is SCEI aka \"Japan\" (or actually for Asia in this case).
"},{"location":"cdromdrive/#note","title":"Note","text":"The SPU MUTE Flag (SPUCNT.14) does also affect VCD Audio (mute is applied to the final analog audio amplifier). All other SPUCNT bits can be zero for VCD.
"},{"location":"cdromdrive/#cdrom-mainloopresponses","title":"CDROM - Mainloop/Responses","text":""},{"location":"cdromdrive/#sub-cpu-mainloop","title":"SUB-CPU Mainloop","text":"The SUB-CPU is running a mainloop that is handling hardware events (by simple polling, not by IRQs):
check for incoming sectors (from CDROM decoder)\n check for incoming commands (from Main CPU)\n do maintenance stuff on the drive mechanics\nThe order of steps that happen when sending a command to the CD controller look roughly like this:
e.g. SetMode:\n1. Command busy flag set immediately.\n2. Response FIFO is populated.\n3. Command is being processed.\n4. Command busy flag is unset and parameter fifo is cleared.\n5. Shortly after (around 1000-6000 cycles later), CDROM IRQ is fired.\nThe PSX can deliver one INT after another. Instead of using a real queue, it's merely using some flags that do indicate which INT(s) need to be delivered. Basically, there seem to be two flags: One for Second Response (INT2), and one for Data/Report Response (INT1). There is no flag for First Response (INT3); because that INT is generated immediately after executing a command. The flag mechanism means that the SUB-CPU cannot hold more than one undelivered INT1. That, although the CDROM Decoder does notify the SUB-CPU about all newly received sectors, and it can hold up to eight sectors in the 32K SRAM. However, the SUB-CPU BIOS merely sets a sector-delivery-needed flag (instead of memorizing which/how many sectors need to be delivered, and, 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/incompletely received sector).
"},{"location":"cdromdrive/#first-response-int3-or-int5-if-failed","title":"First Response (INT3) (or INT5 if failed)","text":"The first response is sent immediately after processing a command. In detail: The mainloop checks for incoming commands once every some clock cycles, and executes commands under following condition:
Main CPU has sent a command, AND, there is no INT pending\n (if an INT is pending, then the command won't be executed yet, but will be\n executed in following mainloop cycles; once when INT got acknowledged)\n (even if no INT is pending, the mainloop may generate INT1/INT2 before\n executing the command, if so, as said above, the command won't execute yet)\nSome commands do send a second response after actual command execution:
07h MotorOn E - INT3(stat), INT2(stat)\n 08h Stop E - INT3(stat), INT2(stat)\n 09h Pause E - INT3(stat), INT2(stat)\n 0Ah Init - INT3(late-stat), INT2(stat)\n 12h SetSession E session INT3(stat), INT2(stat)\n 15h SeekL E - INT3(stat), INT2(stat) ;\\use prior Setloc\n 16h SeekP E - INT3(stat), INT2(stat) ;/to set target\n 1Ah GetID E - INT3(stat), INT2/5(stat,flg,typ,atip,\"SCEx\")\n 1Dh GetQ E adr,point INT3(stat), INT2(10bytesSubQ,peak_lo)\n 1Eh ReadTOC - INT3(late-stat), INT2(stat)\n 03h Play E (track) INT3(stat), optional INT1(report bytes)\n 04h Forward E - INT3(stat), optional INT1(report bytes)\n 05h Backward E - INT3(stat), optional INT1(report bytes)\n 06h ReadN E - INT3(stat), INT1(stat), datablock\n 1Bh ReadS E?- INT3(stat), INT1(stat), datablock\nHere are some response timings, measured in 33MHz units on a PAL PSone. The CDROM BIOSes mainloop is doing some maintenance stuff once and when, meaning that the response time will be higher in such mainloop cycles (max values), and less in normal cycles (min values). The maintenance timings do also depend on whether the motor is on or off (and probably on various other factors like seeking).
"},{"location":"cdromdrive/#first-response","title":"First Response","text":"The First Response interrupt is sent almost immediately after processing the command (that is, when the mainloop sees a new command without any old interrupt pending). For GetStat, timings are as so:
Command Average Min Max\n GetStat (normal) 000c4e1h 0004a73h..003115bh\n GetStat (when stopped) 0005cf4h 000483bh..00093f2h\n Init 0013cceh 000f820h..00xxxxxh\n Command Average Min Max\n GetID 0004a00h 0004922h..0004c2bh\n Pause (single speed) 021181ch 020eaefh..0216e3ch ;\\time equal to\n Pause (double speed) 010bd93h 010477Ah..011B302h ;/about 5 sectors\n Pause (when paused) 0001df2h 0001d25h..0001f22h\n Stop (single speed) 0d38acah 0c3bc41h..0da554dh\n Stop (double speed) 18a6076h 184476bh..192b306h\n Stop (when stopped) 0001d7bh 0001ce8h..0001eefh\n Command Average Min Max\n Read (single speed) 006e1cdh 00686dah..0072732h\n Read (double speed) 0036cd2h 00322dfh..003ab2bh\n[Below are some older/outdated test cases]
"},{"location":"cdromdrive/#sector-buffer","title":"Sector Buffer","text":"The CDROM sector buffer is 32Kx8 SRAM (IC303). The buffer is apparently divided into 8 slots, theoretically allowing to buffer up to 8 sectors. BUG: 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). There is no known way to get around that effect. 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 (there appear to be absolutely no overrun status flags, nor overrun error interrupts).
"},{"location":"cdromdrive/#sector-buffer-test-cases","title":"Sector Buffer Test Cases","text":" Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Process INT1 --> receives sector header for 0:2:1\n Process INT1 --> receives sector header for 0:2:2\n Process INT1 --> receives sector header for 0:2:3\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n delay(1)\n Process INT1 --> receives sector header for 0:2:1 (oldest sector)\n Process INT1 --> receives sector header for 0:2:6 (newest sector)\n Process INT1 --> receives sector header for 0:2:7 (next sector)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n delay(2)\n Process INT1 --> receives sector header for 0:2:9 (oldest/overwritten)\n Process INT1 --> receives sector header for 0:2:11 (newest sector)\n Process INT1 --> receives sector header for 0:2:12 (next sector)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n delay(3)\n Process INT1 --> receives sector header for 0:2:17 (currently received)\n Process INT1 --> receives sector header for 0:2:16 (newest full sector)\n Process INT1 --> receives sector header for 0:2:17 (next sector)\n Process INT1 --> receives sector header for 0:2:18 (next sector)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n GetlocL\n Process INT3 --> receives getloc info for 0:2:0\n Process INT1 --> receives sector header for 0:2:1\n Process INT1 --> receives sector header for 0:2:2\n Process INT1 --> receives sector header for 0:2:3\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Delay(1)\n GetlocL\n Process INT1 --> receives sector header for 0:2:1\n Process INT3 --> receives getloc info for 0:2:6\n Process INT1 --> receives sector header for 0:2:6\n Process INT1 --> receives sector header for 0:2:7\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n GetlocL\n Delay(1)\n Process INT3 --> receives getloc info for 0:2:0\n Process INT1 --> receives sector header for 0:2:5\n Process INT1 --> receives sector header for 0:2:6\n Process INT1 --> receives sector header for 0:2:7\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Delay(1)\n GetlocL\n Delay(1)\n Process INT1 --> receives sector header for 0:2:9\n Process INT1 --> receives sector header for 0:2:11\n Process INT3 --> receives getloc info for 0:2:12\n Process INT1 --> receives sector header for 0:2:12\n Process INT1 --> receives sector header for 0:2:13\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Pause\n Process INT3 --> receives stat=22h (first pause response)\n Process INT2 --> receives stat=02h (second pause response)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Delay(1)\n Pause\n Process INT1 --> receives sector header for 0:2:1 (oldest)\n Process INT3 --> receives stat=22h (first pause response)\n Process INT2 --> receives stat=02h (second pause response)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Pause\n Delay(1)\n Process INT3 --> receives stat=22h (first pause response)\n Process INT2 --> receives stat=02h (second pause response)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Delay(1)\n Pause\n Delay(1)\n Process INT1 --> receives sector header for 0:2:9 (oldest/overwritten)\n Process INT3 --> receives stat=22h (first pause response)\n Process INT2 --> receives stat=02h (second pause response)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n GetlocL\n Pause\n Process INT3 --> receives stat=22h (first pause response)\n Process INT2 --> receives stat=02h (second pause response)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Delay(1)\n GetlocL\n Pause\n Process INT1 --> receives sector header for 0:2:1\n Process INT1 --> receives sector header for 0:2:6\n Process INT3 --> receives stat=22h (first pause response)\n Process INT2 --> receives stat=02h (second pause response)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n GetlocL\n Delay(1)\n Pause\n Process INT3 --> receives getloc info for 0:2:0 (first getloc response)\n Process INT3 --> receives stat=22h (first pause response)\n Process INT2 --> receives stat=02h (second pause response)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Delay(1)\n GetlocL\n Delay(1)\n Pause\n Process INT1 --> receives sector header for 0:2:9 (oldest/overwritten)\n Process INT3 --> receives stat=22h (first pause response)\n Process INT2 --> receives stat=02h (second pause response)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Pause\n GetlocL\n Process INT3 --> receives getloc info for 0:2:0 (first getloc response)\n Process INT1 --> receives sector header for 0:2:1\n Process INT1 --> receives sector header for 0:2:2\n Process INT1 --> receives sector header for 0:2:3\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Delay(1)\n Pause\n GetlocL\n Process INT1 --> receives sector header for 0:2:1\n Process INT3 --> receives getloc info for 0:2:6 (first getloc response)\n Process INT1 --> receives sector header for 0:2:6\n Process INT1 --> receives sector header for 0:2:7\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Pause\n Delay(1)\n GetlocL\n Process INT3 --> receives stat=22h (first pause response)\n Process INT3 --> receives getloc info for 0:2:6 (first getloc response)\n (No further INT's, ie. read is paused, but second-pause-response is lost).\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Pause\n Delay(1)\n GetlocL\n Delay(1)\n Process INT3 --> receives stat=22h (first pause response)\n Process INT3 --> receives getloc info for 0:2:6 (first getloc response)\n Process INT2 --> receives stat=02h (second pause response)\n Setloc(0:2:0)+Read\n Process INT1 --> receives sector header for 0:2:0\n Delay(1)\n Pause\n Delay(1)\n GetlocL\n Process INT1 --> receives sector header for 0:2:9\n Process INT1 --> receives sector header for 0:2:11\n Process INT3 --> receives getloc info for 0:2:12 (first getloc response)\n Process INT1 --> receives sector header for 0:2:12\n Process INT1 --> receives sector header for 0:2:13\nThe PSX uses a ISO 9660 filesystem, with data stored on CD-XA (Mode2) Sectors. ISO 9660 is standard for CDROM disks, although newer CDROMs may use extended filesystems, allowing to use long filenames and lowercase filenames, the PSX Kernel doesn't support such stuff, and, in fact, it's putting some restrictions on the ISO standard: it's limiting file names to MSDOS-style 8.3 format, and it's allowing only a limited number of files and directories per disk.
"},{"location":"cdromdrive/#cdrom-filesystem-iso-9660-aka-ecma-119","title":"CDROM Filesystem (ISO 9660 aka ECMA-119)","text":" Originally intended for Mode1 Sectors (but is also used for CD-XA Mode2)\n Supports \"FILENAME.EXT;VERSION\" filenames (version is usually \"1\")\n Supports all-uppercase filenames and directory names (0-9, A-Z, underscore)\n For PSX: Max 8-character filenames with max 3-character extensions\n For PSX: Max 8-character directory names, without extension\n For PSX: Max one sector per directory (?)\n For PSX: Max one sector (or less?) per path table (?)\n Uses Mode2 Sectors (see Sector Encoding chapter)\n Allows 800h or 914h byte data per sector (with/without error correction)\n Allows to break interleaved data into separate files/channels\n Supports XA-ADPCM compressed audio data\n Stores \"CD-XA001\" at 400h Primary Volume Descriptor (?)\n Stores 14 extra bytes in System Use area (LEN_SU) of Directory Entries\n Defines physical metrics of the CDROM and Audio disks\n Defines Sub-channels and Track.Index and Minute.Second.Fraction numbering\n Defines 14bit-per-byte encoding, and splits sectors into frames\n Defines ECC and EDC (error correction and error detection codes)\nISO documents are commercial standards (not available for download), however, they are based on ECMA standards (which are free for download, however, the ECMA stuff is in PDF format, so one may treat it as commercial bullshit, too). CD-ROM XA is commercial only (not available for download), and, CD-XA doesn't seem to have become very popular outside of the PSX-world, so there's very little information available, portions of CD-XA are also used in the CD-i standard (which may be a little better or worse documented).
"},{"location":"cdromdrive/#stuff","title":"Stuff","text":" sessions one or more sessions per disk\n tracks 99 tracks per disk (01h..99h) (usually only 01h on Data Disks)\n index 99 indices per track (01h..99h) (rarely used, usually always 01h)\n minutes 74 minutes per disk (00h..73h) (or more, with some restrictions)\n seconds 60 seconds per minute (00h..59h)\n sectors 75 sectors per second (00h..74h)\n frames 98 frames per sector\n bytes 33 bytes per frame (24+1+8 = data + subchannel + error correction)\n bits 14 bits per byte (256 valid combinations, and many invalid ones)\nMultiple Tracks are usually used only on Audio Disks (one track for each song, numbered 01h and up), a few Audio Disks may also split Tracks into separate fragments with different Index values (numbered 01h and up, but most tracks have only Index 01h). A simple Data Disk would usually contain only one Track (all sectors marked Track=01h and Index=01h), although some more complex Data Disks may have multiple Data tracks and/or Audio tracks.
"},{"location":"cdromdrive/#minutesecondsector-stored-in-subchannel-and-in-data-sectors-bcd-format","title":"Minute.Second.Sector (stored in subchannel, and in Data sectors, BCD format)","text":"The sectors on CDROMs and CD Audio disks are numbered in Minutes, Seconds, and 1/75 fragments of a second (where a \"second\" is referring to single-speed drives, ie. the normal CD Audio playback speed). Minute.Second.Sector is stored twice in the subchannel (once the \"absolute\" time, and once the \"local\" time). The \"absolute\" sector number (counted from the begin of the disk) is mainly relevant for Seek purposes (telling the controller if the drive head is on the desired location, or if it needs to move the head backwards or forwards). The \"local\" sector number (counted from the begin of the track) is mainly relevant for Audio Players, allowing to pass the data directly to the Minute:Second display, without needing to subtract the start address of the track. Data disks are additionally storing the \"absolute\" values in their Data Areas, basically that's just the subchannel data duplicated, but more precisely assigned - the problem with the subchannel data is that the CD Audio standard seems to lack a clear definition that would assign the begin of the sub-channel block to the exact begin of a sector; so, when using only the subchannel data, some Drive Controllers may assign the begin of a new sector to another location as than other Controllers do, for Audio Disks that isn't too much of a problem, but for Data Disks it'd be fatal.
"},{"location":"cdromdrive/#subchannels","title":"Subchannels","text":"Each frame contains 8 subchannel bits (named P,Q,R,S,T,U,V,W). So, a sector (with 98 frames) contains 98 bits (12.25 bytes) for each subchannel. CDROM Subchannels
"},{"location":"cdromdrive/#error-correction","title":"Error Correction","text":"Each Frame contains 8 bytes Error Correction information, which is mainly used for Audio Disks, but it isn't 100% fail-proof, for that reason, Data Disks are containing additional Error Correction in the 930h-byte data area (the audio correction is probably focusing on repairing the MSBs of the 16bit samples, and gives less priority on the LSBs). Error Correction is some kind of a huge complex checksum, which allows to detect the location of faulty bytes, and to fix them.
"},{"location":"cdromdrive/#930h-byte-sectors","title":"930h-Byte Sectors","text":"The \"user\" area for each sector is 930h bytes (2352 bytes). That region is combined of the 24-byte data per frame (and excludes the 8-byte audio error correction info, and the 1-byte subchannel data). Most CDROM Controllers are only giving access to this 930h-byte region (ie. there's no way to read the audio error correction info by software, and only limited access to the subchannel data, such like allowing to read only the Q-channel for showing track/minute/second in audio playback mode). On Audio disks, the 930h bytes are plain data, on Data disks that bytes are containing headers, error correction, and usually only 800h bytes user data (for more info see Sector Encoding chapter).
"},{"location":"cdromdrive/#sessions","title":"Sessions","text":"Multi-Sessions are mainly used on CDR's, allowing to append newer data at the end of the disk at a later time. First of, the old session must contain a flag indicating that there may be a newer session, telling the CDROM Controller to search if one such exists (and if that is equally flagged, to search for an even newer session, and so on until reaching the last and newest session). Each session contains a complete new ISO Volume Descriptor, and may additionally contain new Path Tables, new Directories, and new Files. The Driver Controller is usually recursing only the Volume Descriptor of the newest session. However, the various Directory Records of the new session may refer to old files or old directories from previous sessions, allowing to \"import\" the older files, or to \"rename\" or \"delete\" them by assigning new names to that files, or by removing them from the directory. The PSX is reportedly not supporting multi-session disks, but that doesn't seem to be correct, namely, the Setsession command is apparently intended for that purpose... though not sure if the PSX Kernel is automatically searching the newest session... otherwise the boot executable in the first session would need to do that manually by software, and redirect control to the boot executable in the last session.
"},{"location":"cdromdrive/#cdrom-subchannels","title":"CDROM Subchannels","text":""},{"location":"cdromdrive/#subchannel-p","title":"Subchannel P","text":"Subchannel P contains some kind of a Pause flag (to indicate muted areas between Audio Tracks). This subchannel doesn't have any checksum, so the data cannot be trusted to be intact (unless when sensing a longer stream of all-one's, or all zero's). Theoretically, the 98 pause bits are somehow associated to the 98 audio frames (with 24 audio bytes each) of the sector. However, reportedly, Subchannel P does contain two sync bits, if that is true, then there'd be only 96 pause flags for 98 audio frames. Strange. Note: Another way to indicate \"paused\" regions is to set Subchannel Q to ADR=1 and Index=00h.
"},{"location":"cdromdrive/#subchannel-q","title":"Subchannel Q","text":"contains the following information:
Bits Expl.\n 2 Sub-channel synchronization field\n 8 ADR/Control (see below)\n 72 Data (content depends on ADR)\n 16 CRC-16-CCITT error detection code (big-endian: bytes ordered MSB, LSB)\n Bit0-3 ADR (0=No data, 1..3=see below, 4..0Fh=Reserved)\n Bit4 Audio Preemphasis (0=No, 1=Yes) (Audio only, must be 0 for Data)\n Bit5 Digital Copy (0=Prohibited, 1=Allowed)\n Bit6 Data (0=Audio, 1=Data)\n Bit7 Four-Channel Audio (0=Stereo, 1=Quad) (Audio only, must be 0 for Data)\n 8 Track number (fixed, must be 00h=Lead-in)\n 8 Point (01h..99h or A0h..A2h, see last three bytes for more info)\n 24 MSF address (incrementing address within the Lead-in area)\n Note: On some disks, these values are choosen so that the lead-in\n <starts> at 00:00:00, on other disks so that it <ends> at 99:59:74.\n 8 Reserved (00h)\n 24 MSF address (absolute address, start address of the \"Point\" track)\n 8 First Track number (BCD)\n 8 Disk Type Byte (00h=CD-DA or CD-ROM, 10h=CD-I, 20h=CD-ROM-XA)\n 8 Reserved (00h)\n 8 Last Track number (BCD)\n 16 Reserved (0000h)\n 8 Track number (01h..99h=Track 1..99)\n 8 Index number (00h=Pause, 01h..99h=Index within Track)\n 24 Track relative MSF address (decreasing during Pause)\n 8 Reserved (00h)\n 24 Absolute MSF address\n 8 Track number (fixed, must be AAh=Lead-Out)\n 8 Index number (fixed, must be 01h) (there's no Index=00h in Lead-Out)\n 24 Track relative MSF address (increasing, 00:00:00 and up)\n 8 Reserved (00h)\n 24 Absolute MSF address\n 52 EAN-13 barcode number (13-digit BCD)\n 12 Reserved (000h)\n 8 Absolute Sector number (BCD, 00h..74h) (always 00h during Lead-in)\n(ISO 3901 and DIN-31-621):
12 Country Code (two 6bit characters) (ASCII minus 30h) ;eg. \"US\"\n 18 Owner Code (three 6bit characters) (ASCII minus 30h)\n 2 Reserved (zero)\n 8 Year of recording (2-digit BCD) ;eg. 82h for 1982\n 20 Serial number (5-digit BCD) ;usually increments by 1 or 10 per track\n 4 Reserved (zero)\n 8 Absolute Sector number (BCD, 00h..74h) (always 00h during Lead-in)\nWhen Point=B0h:
8 Track number (fixed, must be 00h=Lead-in)\n 8 POINT = B0h (multi-session disc)\n 24 MM:SS:FF = the start time for the next possible session's program area,\n a final session is indicated by FFh:FFh:FFh,\n or when the ADR=5 / Point=B0h is absent.\n 8 Number of different Mode-5 pointers present.\n 24 MM:SS:FF = the maximum possible start time of the outermost Lead-out\n 8 Track number (fixed, must be 00h=Lead-in)\n 8 POINT = C0h (Identifies a Multisession disc, together with POINT=B0h)\n 24 ATIP values from Special Information 1, ID=101\n 8 Reserved (must be 00h)\n 24 MM:SS:FF = Start time of the first Lead-in area of the disc\n 8 Track number (fixed, must be 00h=Lead-in)\n 8 POINT=C1h\n 8x7 Copy of information from A1 point in ATIP\n 8 Track number (fixed, must be AAh=Lead-out)\n 8 POINT = D1h (Identifies a Multisession lead-out)\n 24 Usually zero (or maybe ATIP as in Lead-In with Point=C0h...?)\n 8 Seems to be the session number?\n 24 MM:SS:FF = Absolute address of the First data sector of the session\nWhen Point=01h..40h:
8 Track number (fixed, must be 00h=Lead-in)\n 8 POINT=01h..40h (This identifies a specific playback skip interval)\n 24 MM:SS:FF Skip interval stop time in 6 BCD digits\n 8 Reserved (must be 00h)\n 24 MM:SS:FF Skip interval start time in 6 BCD digits\n 8 Track number (fixed, must be 00h=Lead-in)\n 8 POINT=B1h (Audio only: This identifies the presence of skip intervals)\n 8x4 Reserved (must be 00h,00h,00h,00h)\n 8 the number of skip interval pointers in POINT=01h..40h\n 8 the number of skip track assignments in POINT=B2h..B4h\n 8 Reserved (must be 00h)\n 8 Track number (fixed, must be 00h=Lead-in)\n 8 POINT=B2h,B3h,B4h (This identifies tracks that should be skipped)\n 8 1st Track number to skip upon playback (01h..99h, must be nonzero)\n 8 2nd Track number to skip upon playback (01h..99h, or 00h=None)\n 8 3rd Track number to skip upon playback (01h..99h, or 00h=None)\n 8 Reserved (must be 00h)... unclear... OR... 4th (of 7) skip info's...?\n 8 4th Track number to skip upon playback (01h..99h, or 00h=None)\n 8 5th Track number to skip upon playback (01h..99h, or 00h=None)\n 8 6th Track number to skip upon playback (01h..99h, or 00h=None)\nSubchannels R..W are usually unused, except for some extended formats:
CD-TEXT in the Lead-In area (see below)\n CD-TEXT in the Data area (rarely used)\n CD plus Graphics (CD+G) (rarely used)\nCD-TEXT is stored in the six Subchannels R..W. Of the 12.25 bytes (98 bits) per subchannel, only 12 bytes are used. Together, all 6 subchannels have a capacity of 72 bytes (6x12 bytes) per sector. These 72 bytes are divided into four CD-TEXT fragments (of 18 bytes each). The format of these 18 bytes is:
00h 1 Header Field ID1: Pack Type Indicator\n 01h 1 Header Field ID2: Track Number\n 02h 1 Header Field ID3: Sequence Number\n 03h 1 Header Field ID4: Block Number and Character Position Indicator\n 04h 12 Text/Data Field\n 10h 2 CRC-16-CCITT (big-endian) (across bytes 00h..0Fh)\n 80h Titel (TEXT)\n 81h Performer (TEXT)\n 82h Songwriter (TEXT)\n 83h Composer (TEXT)\n 84h Arranger (TEXT)\n 85h Message (TEXT)\n 86h Disc ID (TEXT?) (content/format/purpose unknown?)\n 87h Genre (BINARY) (ID codes unknown?)\n 88h TOC (BINARY) (content/format/purpose unknown?)\n 89h TOC2 (BINARY) (content/format/purpose unknown?)\n 8Ah Reserved for future\n 8Bh Reserved for future\n 8Ch Reserved for future\n 8Dh Reserved for \"content provider\" aka \"closed information\"\n 8Eh UPC/EAN and ISRC Codes (TEXT) (content/format/purpose unknown?)\n 8Fh Blocksize (BINARY) (see below)\n 00h Title/Performer/etc. for the Disc\n 01h..63h Title/Performer/etc. for Track 1..99 (Non-BCD) (Bit7=Extension)\n 00h..FFh Incrementing Number (00h=First 18-byte fragment, 01h=Second, etc.)\n Bit7 Character Set (0=8bit, 1=16bit)\n Bit6-4 Block Number (0..7 = Language number, as set by \"Blocksize\")\n Bit3-0 Character Position (0..0Eh=Position, 0Fh=Append to prev fragment)\n ID TR SQ CH <------------Text/Data------------> -CRC- <---Text--->\n 80 00 00 00 54 65 73 74 44 69 73 6B 54 69 74 6C E2 22 TestDiskTitl\n 80 00 01 0C 65 00 54 65 73 74 54 72 61 63 6B 54 C9 1B e.TestTrackT\n 80 01 02 0A 69 74 6C 65 31 00 54 65 73 74 54 72 40 3A itle1.TestTr\n 80 02 03 06 61 63 6B 54 69 74 6C 65 32 00 00 00 80 E3 ackTitle2...\n 81 00 04 00 54 65 73 74 44 69 73 6B 50 65 72 66 03 DF TestDiskPerf\n 81 00 05 0C 6F 72 6D 65 72 00 54 65 73 74 54 72 12 A5 ormer.TestTr\n 81 01 06 06 61 63 6B 50 65 72 66 6F 72 6D 65 72 BC 5B ackPerformer\n 81 01 07 0F 31 00 54 65 73 74 54 72 61 63 6B 50 AC 41 1.TestTrackP\n 81 02 08 0A 65 72 66 6F 72 6D 65 72 32 00 00 00 64 1A erformer2...\n 8F 00 09 00 01 01 02 00 04 05 00 00 00 00 00 00 6D E2 ............\n 8F 01 0A 00 00 00 00 00 00 00 00 03 0B 00 00 00 CD 0C ............\n 8F 02 0B 00 00 00 00 00 09 00 00 00 00 00 00 00 FC 8C ............\n 00 ;<--- for some reason, CDRWIN stores an ending 00h byte in .CDT files\n 00h 1 Character set (00h,01h,80h,81h,82h = see below)\n 01h 1 First track number (usually/always 01h)\n 02h 1 Last track number (01h..63h)\n 03h 1 1bit-cd-text-in-data-area-flag, 7bit-copy-protection-flags\n 04h 16 Number of 18-byte packs for ID1=80h..8Fh\n 14h 8 Last sequence number of block 0..7 (or 00h=none)\n 1Ch 8 Language codes for block 0..7 (definitions are unknown)\n 00h ISO 8859-1\n 01h ISO 646, ASCII\n 80h MS-JIS\n 81h Korean character code\n 82h Mandarin (standard) Chinese character code\n Other = reserved\n lsb=00h, msb=00h ;-initial value (zero for both CD-TEXT and Sub-Q)\n for i=0 to len-1 ;-len (10h for CD-TEXT, 0Ah for Sub-Q)\n x = [addr+i] xor msb\n x = x xor (x shr 4)\n msb = lsb xor (x shr 3) xor (x shl 4)\n lsb = x xor (x shl 5)\n next i\n [addr+len+0]=msb xor FFh, [addr+len+1]=lsb xor FFh ;inverted / big-endian\n 000h 930h Audio Data (2352 bytes) (LeftLsb,LeftMsb,RightLsb,RightMsb)\n 000h 0Ch Sync (00h,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,00h)\n 00Ch 4 Header (Minute,Second,Sector,Mode=00h)\n 010h 920h Zerofilled\n 000h 0Ch Sync (00h,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,00h)\n 00Ch 4 Header (Minute,Second,Sector,Mode=01h)\n 010h 800h Data (2048 bytes)\n 810h 4 EDC (checksum across [000h..80Fh])\n 814h 8 Zerofilled\n 81Ch 114h ECC (error correction codes)\n 000h 0Ch Sync (00h,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,00h)\n 00Ch 4 Header (Minute,Second,Sector,Mode=02h)\n 010h 4 Sub-Header (File, Channel, Submode AND DFh, Codinginfo)\n 014h 4 Copy of Sub-Header\n 018h 800h Data (2048 bytes)\n 818h 4 EDC (checksum across [010h..817h])\n 81Ch 114h ECC (error correction codes)\n 000h 0Ch Sync (00h,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,00h)\n 00Ch 4 Header (Minute,Second,Sector,Mode=02h)\n 010h 4 Sub-Header (File, Channel, Submode OR 20h, Codinginfo)\n 014h 4 Copy of Sub-Header\n 018h 914h Data (2324 bytes)\n 92Ch 4 EDC (checksum across [010h..92Bh]) (or 00000000h if no EDC)\n sector[000h]=00h,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh,00h\n sector[00ch]=bcd(adr/75/60) ;0..7x\n sector[00dh]=bcd(adr/75 MOD 60) ;0..59\n sector[00eh]=bcd(adr MOD 75) ;0..74\n sector[00fh]=mode\n if mode=00h then\n sector[010h..92Fh]=zerofilled\n if mode=01h then\n adjust_edc(sector+0, 800h+10h)\n sector[814h..817h]=00h,00h,00h,00h,00h,00h,00h,00h\n calc_p_parity(sector)\n calc_q_parity(sector)\n if mode=02h and form=1\n sector[012h]=sector[012h] AND (NOT 20h) ;indicate not form2\n sector[014h..017h]=sector[010h..013h] ;copy of sub-header\n adjust_edc(sector+10h,800h+8)\n push sector[00ch] ;\\temporarily clear header\n sector[00ch]=00000000h ;/\n calc_p_parity(sector)\n calc_q_parity(sector)\n pop sector[00ch] ;-restore header\n if mode=02h and form=2\n sector[012h]=sector[012h] OR 20h ;indicate form2\n sector[014h..017h]=sector[010h..013h] ;copy of sub-header\n adjust_edc(sector+10h,914h+8) ;edc is optional for form2\n src=00ch, dst=81ch+offs, srcmax=dst\n for i=0 to len-1\n base=src, x=0000h, y=0000h\n for j=j0 to 42\n x=x xor GF8_PRODUCT[j,sector[src+0]]\n y=y xor GF8_PRODUCT[j,sector[src+1]]\n src=src+step1, if (step1=2*44) and (src>=srcmax) then src=src-2*1118\n sector[dst+2*len+0]=x AND 0FFh, [dst+0]=x SHR 8\n sector[dst+2*len+1]=y AND 0FFh, [dst+1]=y SHR 8\n dst=dst+2, src=base+step2\n x=00000000h\n for i=0 to len-1\n x=x xor byte[addr+i], x=(x shr 8) xor edc_table[x and FFh]\n word[addr+len]=x ;append EDC value (little endian)\n for i=0 to FFh\n x=i, for j=0 to 7, x=x shr 1, if carry then x=x xor D8018001h\n edc_table[i]=x\n GF8_LOG[00h]=00h, GF8_ILOG[FFh]=00h, x=01h\n for i=00h to FEh\n GF8_LOG[x]=i, GF8_ILOG[i]=x\n x=x SHL 1, if carry8bit then x=x xor 1dh\n for j=0 to 42\n xx=GF8_ILOG[44-j], yy=subfunc(xx xor 1,19h)\n xx=subfunc(xx,01h), xx=subfunc(xx xor 1,18h)\n xx=GF8_LOG[xx], yy = GF8_LOG[yy]\n GF8_PRODUCT[j,0]=0000h\n for i=01h to FFh\n x=xx+GF8_LOG[i], if x>=255 then x=x-255\n y=yy+GF8_LOG[i], if y>=255 then y=y-255\n GF8_PRODUCT[j,i]=GF8_ILOG[x]+(GF8_ILOG[y] shl 8)\n if a>0 then\n a=GF8_LOG[a]-b, if a<0 then a=a+255\n a=GF8_ILOG[a]\n return(a)\nScambling does XOR the data sectors with random values (done to avoid regular patterns). The scrambling is applied to Data sector bytes[00Ch..92Fh] (not to CD-DA audio sectors, and not to the leading 12-byte Sync mark in Data sectors). The (de-)scrambling is done automatically by the CDROM controller, so disc images should usually contain unscrambled data (there are some exceptions such like CD-i discs that have audio and data sectors mixed inside of the same track; which may confuse the CDROM controller about whether or not to apply scrambling to which sectors; so one may need to manually XOR the faulty sectors in the disc image). The scrambling pattern is derived from a 15bit polynomial counter (much like a noise generator in sound chips). The data bits are XORed with the counters low bit, and the counters lower 2bit are XORed with each other, and shifted in to the counters upper bit. To compute 8 bits and once, and store them in a 924h-byte table:
poly=0001h ;init 15bit polynomial counter\n for i=0 to 924h-1\n scramble_table[i]=poly AND FFh\n poly=(((poly XOR poly/2) AND 0FFh)*80h) XOR (poly/100h)\n next i\n 01h,80h,00h,60h,00h,28h,00h,1Eh,80h,08h,60h,06h,A8h,02h,FEh,81h,\n 80h,60h,60h,28h,28h,1Eh,9Eh,88h,68h,66h,AEh,AAh,FCh,7Fh,01h,E0h,\n etc.\nThe Sub-Header for normal data sectors is usually 00h,00h,08h,00h (some PSX sectors have 09h instead 08h, indicating the end of \"something\" or so?
"},{"location":"cdromdrive/#1st-subheader-byte-file-number-fn","title":"1st Subheader byte - File Number (FN)","text":" 0-7 File Number (00h..FFh) (for Audio/Video Interleave, see below)\n 0-4 Channel Number (00h..1Fh) (for Audio/Video Interleave, see below)\n 5-7 Should be always zero\n 0 End of Record (EOR) (all Volume Descriptors, and all sectors with EOF)\n 1 Video ;\\Sector Type (usually ONE of these bits should be set)\n 2 Audio ; Note: PSX .STR files are declared as Data (not as Video)\n 3 Data ;/\n 4 Trigger (for application use)\n 5 Form2 (0=Form1/800h-byte data, 1=Form2, 914h-byte data)\n 6 Real Time (RT)\n 7 End of File (EOF) (or end of Directory/PathTable/VolumeTerminator)\nWhen used for Data sectors:
0-7 Reserved (00h)\n 0-1 Mono/Stereo (0=Mono, 1=Stereo, 2-3=Reserved)\n 2-2 Sample Rate (0=37800Hz, 1=18900Hz, 2-3=Reserved)\n 4-5 Bits per Sample (0=Normal/4bit, 1=8bit, 2-3=Reserved)\n 6 Emphasis (0=Normal/Off, 1=Emphasis)\n 7 Reserved (0)\nThe CDROM drive mechanics are working best when continously following the data spiral on the disk, that works fine for uncompressed Audio Data at normal speed, but compressed Audio Data the disk is spinning much too fast. To avoid the drive to need to pause reading or to do permanent backwards seeking, CD-XA allows to store data interleaved in separate files/channels. With common interleave values like so:
Interleave Data Format\n 1/1 (none) 44100Hz Stereo CD Audio at normal speed\n 1/8 37800Hz Stereo ADPCM compressed Audio at double speed\n 1/16 18900Hz Stereo ADPCM compressed Audio at double speed\n 1/16 37800Hz Mono ADPCM compressed Audio at double speed\n 1/32 18900Hz Mono ADPCM compressed Audio at double speed\n 7/8 15fps 320x224 pixel MDEC compressed Videos at double speed\n Unknown if 1/16 and 1/32 interleaves are actually possible (the PSX cdrom\n controller seems to overwrite the IC303 sector buffer entries once every\n eight sectors, so ADPCM data may get destroyed on interleaves above 1/8).\n (Crash Team Racing uses 37800Hz Mono at Double speed, so 1/16 must work).\n one file with eight 1/8 audio channels\n one file with one 1/8 audio channels, plus one 7/8 video channel (*)\n one file with one 1/8 audio channels, plus 7 unused channels\n eight different files with one 1/8 audio channel each\n etc.\nThere are different ways to mark unused sectors in interleaved streams. Ace Combat 3 uses Channel=FFh=Invalid. Tron Bonne uses Submode=00h=Nothing (notably, that game has a 74Mbyte XA file that leaves about 75% unused).
Subheader bytes: 01h,FFh,64h,01h ;Ace Combat 3 Electrosphere\n Subheader bytes: 01h,00h,00h,00h ;Misadventures of Tron Bonne (XA\\*.XA)\nWith the above Interleave, files can be played continously at real time - that, unless read-errors do occur. In that case the drive controller would usually perform time-consuming error-correction and/or read-retries. For video/audio streaming the resulting delay would be tendencially more annoying as than processing or skipping the incorrect data. In such cases the drive controller is allowed to ignore read errors; that probably on sectors that have the Real Time (RT) flag set in their subheaders. The controller is probably doing some read-ahead buffering (so, if it has buffered enough data, then it may still perform read retries and/or error correction, as long as it doesn't affect real time playback).
"},{"location":"cdromdrive/#cdrom-xa-audio-adpcm-compression","title":"CDROM XA Audio ADPCM Compression","text":"CD-ROM XA ADPCM is used for Audio data compression. Each 16bit sample is encoded in 4bit nibbles; so the compression rate is almost 1:4 (only almost 1:4 because there are 16 header bytes within each 128-byte portion). The data is usually/always stored on 914h-byte sectors (without error correction).
"},{"location":"cdromdrive/#subheader","title":"Subheader","text":"The Subheader (see previous chapter) contains important info for ADPCM: The file/channel numbers for Interleaved data, and the codinginfo flags: mono/stereo flag, 37800Hz/18900Hz sampling rate, 4bit/8bit format, and emphasis.
"},{"location":"cdromdrive/#adpcm-sectors","title":"ADPCM Sectors","text":"Each sector consists of 12h 128-byte portions (=900h bytes) (the remaining 14h bytes of the sectors 914h-byte data region are 00h filled). The separate 128-byte portions consist of a 16-byte header,
00h..03h Copy of below 4 bytes (at 04h..07h)\n 04h Header for 1st Block/Mono, or 1st Block/Left\n 05h Header for 2nd Block/Mono, or 1st Block/Right\n 06h Header for 3rd Block/Mono, or 2nd Block/Left\n 07h Header for 4th Block/Mono, or 2nd Block/Right\n 08h Header for 5th Block/Mono, or 3rd Block/Left ;\\unknown/unused\n 09h Header for 6th Block/Mono, or 3rd Block/Right ; for 8bit ADPCM\n 0Ah Header for 7th Block/Mono, or 4th Block/Left ; (maybe 0, or maybe\n 0Bh Header for 8th Block/Mono, or 4th Block/Right ;/copy of above)\n 0Ch..0Fh Copy of above 4 bytes (at 08h..0Bh)\n 10h..13h 1st Data Word (packed 1st samples for 2-8 blocks)\n 14h..17h 2nd Data Word (packed 2nd samples for 2-8 blocks)\n 18h..1Bh 3rd Data Word (packed 3rd samples for 2-8 blocks)\n ... Nth Data Word (packed Nth samples for 2-8 blocks)\n 7Ch..7Fh 28th Data Word (packed 28th samples for 2-8 blocks)\n 0-3 Shift (0..12) (0=Loudest) (13..15=Reserved/Same as 9)\n 4-5 Filter (0..3) (only four filters, unlike SPU-ADPCM which has five)\n 6-7 Unused (should be 0)\n 0-3 Nibble for 1st Block/Mono, or 1st Block/Left (-8h..+7h)\n 4-7 Nibble for 2nd Block/Mono, or 1st Block/Right (-8h..+7h)\n 8-11 Nibble for 3rd Block/Mono, or 2nd Block/Left (-8h..+7h)\n 12-15 Nibble for 4th Block/Mono, or 2nd Block/Right (-8h..+7h)\n 16-19 Nibble for 5th Block/Mono, or 3rd Block/Left (-8h..+7h)\n 20-23 Nibble for 6th Block/Mono, or 3rd Block/Right (-8h..+7h)\n 24-27 Nibble for 7th Block/Mono, or 4th Block/Left (-8h..+7h)\n 28-31 Nibble for 8th Block/Mono, or 4th Block/Right (-8h..+7h)\n 0-7 Byte for 1st Block/Mono, or 1st Block/Left (-80h..+7Fh)\n 8-15 Byte for 2nd Block/Mono, or 1st Block/Right (-80h..+7Fh)\n 16-23 Byte for 3rd Block/Mono, or 2nd Block/Left (-80h..+7Fh)\n 24-31 Byte for 4th Block/Mono, or 2nd Block/Right (-80h..+7Fh)\n src=src+12+4+8 ;skip sync,header,subheader\n for i=0 to 11h\n for blk=0 to 3\n IF stereo ;left-samples (LO-nibbles), plus right-samples (HI-nibbles)\n decode_28_nibbles(src,blk,0,dst_left,old_left,older_left)\n decode_28_nibbles(src,blk,1,dst_right,old_right,older_right)\n ELSE ;first 28 samples (LO-nibbles), plus next 28 samples (HI-nibbles)\n decode_28_nibbles(src,blk,0,dst_mono,old_mono,older_mono)\n decode_28_nibbles(src,blk,1,dst_mono,old_mono,older_mono)\n ENDIF\n next blk\n src=src+128\n next i\n src=src+14h+4 ;skip padding,edc\n shift = 12 - (src[4+blk*2+nibble] AND 0Fh)\n filter = (src[4+blk*2+nibble] AND 30h) SHR 4\n f0 = pos_xa_adpcm_table[filter]\n f1 = neg_xa_adpcm_table[filter]\n for j=0 to 27\n t = signed4bit((src[16+blk+j*4] SHR (nibble*4)) AND 0Fh)\n s = (t SHL shift) + ((old*f0 + older*f1+32)/64);\n s = MinMax(s,-8000h,+7FFFh)\n halfword[dst]=s, dst=dst+2, older=old, old=s\n next j\n pos_xa_adpcm_table[0..4] = (0, +60, +115, +98, +122)\n neg_xa_adpcm_table[0..4] = (0, 0, -52, -55, -60)\nThe incoming old/older values are usually that from the previous part, or garbage (in case of decoding errors in the previous part), or whatever (in case there was no previous part) (ie. maybe zero on power-up?) (and maybe there's also a way to reset the values to zero at the begin of a new file, or *maybe* it's silently done automatically when issuing seek commands?).
"},{"location":"cdromdrive/#25-point-zigzag-interpolation","title":"25-point Zigzag Interpolation","text":"The CDROM decoder is applying some weird 25-point zigzag interpolation when resampling the 37800Hz XA-ADPCM output to 44100Hz. This part is different from SPU-ADPCM (which uses 4-point gaussian pitch interpolations). For example, XA-ADPCM interpolation applied to a square wave looks like this:
. .\n .--------------. | | | |\n | | .'.'.'----'.'.'.\n | | | | | |\n | | | |\n | Decompressed | | Final |\n | XA-ADPCM | | XA-ADPCM |\n | Waveform | | Output |\n | | | | | |\n | | ---.'.'.' '.'.'.---\n --------' '-------- | | | |\n ' '\n<B> Output37800Hz(sample):</B>\n ringbuf[p AND 1Fh]=sample, p=p+1, sixstep=sixstep-1\n if sixstep=0\n sixstep=6\n Ouput44100Hz(ZigZagInterpolate(p,Table1))\n Ouput44100Hz(ZigZagInterpolate(p,Table2))\n Ouput44100Hz(ZigZagInterpolate(p,Table3))\n Ouput44100Hz(ZigZagInterpolate(p,Table4))\n Ouput44100Hz(ZigZagInterpolate(p,Table5))\n Ouput44100Hz(ZigZagInterpolate(p,Table6))\n Ouput44100Hz(ZigZagInterpolate(p,Table7))\n endif\n<B> ZigZagInterpolate(p,TableX):</B>\n sum=0\n for i=1 to 29, sum=sum+(ringbuf[(p-i) AND 1Fh]*TableX[i])/8000h, next i\n return MinMax(sum,-8000h,+7FFFh)\n<B> Table1, Table2, Table3, Table4, Table5, Table6, Table7 ;Index</B>\n 0 , 0 , 0 , 0 , -0001h, +0002h, -0005h ;1\n 0 , 0 , 0 , -0001h, +0003h, -0008h, +0011h ;2\n 0 , 0 , -0001h, +0003h, -0008h, +0010h, -0023h ;3\n 0 , -0002h, +0003h, -0008h, +0011h, -0023h, +0046h ;4\n 0 , 0 , -0002h, +0006h, -0010h, +002Bh, -0017h ;5\n -0002h, +0003h, -0005h, +0005h, +000Ah, +001Ah, -0044h ;6\n +000Ah, -0013h, +001Fh, -001Bh, +006Bh, -00EBh, +015Bh ;7\n -0022h, +003Ch, -004Ah, +00A6h, -016Dh, +027Bh, -0347h ;8\n +0041h, -004Bh, +00B3h, -01A8h, +0350h, -0548h, +080Eh ;9\n -0054h, +00A2h, -0192h, +0372h, -0623h, +0AFAh, -1249h ;10\n +0034h, -00E3h, +02B1h, -05BFh, +0BCDh, -16FAh, +3C07h ;11\n +0009h, +0132h, -039Eh, +09B8h, -1780h, +53E0h, +53E0h ;12\n -010Ah, -0043h, +04F8h, -11B4h, +6794h, +3C07h, -16FAh ;13\n +0400h, -0267h, -05A6h, +74BBh, +234Ch, -1249h, +0AFAh ;14\n -0A78h, +0C9Dh, +7939h, +0C9Dh, -0A78h, +080Eh, -0548h ;15\n +234Ch, +74BBh, -05A6h, -0267h, +0400h, -0347h, +027Bh ;16\n +6794h, -11B4h, +04F8h, -0043h, -010Ah, +015Bh, -00EBh ;17\n -1780h, +09B8h, -039Eh, +0132h, +0009h, -0044h, +001Ah ;18\n +0BCDh, -05BFh, +02B1h, -00E3h, +0034h, -0017h, +002Bh ;19\n -0623h, +0372h, -0192h, +00A2h, -0054h, +0046h, -0023h ;20\n +0350h, -01A8h, +00B3h, -004Bh, +0041h, -0023h, +0010h ;21\n -016Dh, +00A6h, -004Ah, +003Ch, -0022h, +0011h, -0008h ;22\n +006Bh, -001Bh, +001Fh, -0013h, +000Ah, -0005h, +0002h ;23\n +000Ah, +0005h, -0005h, +0003h, -0001h, 0 , 0 ;24\n -0010h, +0006h, -0002h, 0 , 0 , 0 , 0 ;25\n +0011h, -0008h, +0003h, -0002h, +0001h, 0 , 0 ;26\n -0008h, +0003h, -0001h, 0 , 0 , 0 , 0 ;27\n +0003h, -0001h, 0 , 0 , 0 , 0 , 0 ;28\n -0001h, 0 , 0 , 0 , 0 , 0 , 0 ;29\nWith XA-Emphasis enabled in Sub-header, output will appear as so:
.------------. ....-----.\n | | .'' |\n | Raw | .' XA |\n | ADPCM | | Emphasis '.\n | Waveform | | Output '..\n --------' '---------- --------' ''''---\nThe hardware does contain some six-step counter (for interpolating 37800Hz to 44100Hz, ie. to insert one extra sample after each six samples). The 900h-byte sectors contain a multiple of six samples, so the counter will be always same before & after playing a sector. However, the initial counter value on power-up is uninitialized random (and the counter will fallback to that initial random setting after each 900h-byte sector).
"},{"location":"cdromdrive/#riff-headers-on-pcs","title":"RIFF Headers (on PCs)","text":"When reading files that consist of 914h-byte sectors on a PC, the PC seems to automatically insert a 2Ch-byte RIFF fileheader. Like so, for ADPCM audio files:
00h 4 \"RIFF\"\n 04h 4 Total Filesize (minus 8)\n 08h 8 \"CDXAfmt \"\n 10h 4 Size of below stuff (10h)\n 14h 14 Stuff (looks like the \"LEN_SU\" region from XA-Directory Record)\n 22h 2 Zero (probably just dummy padding for 32bit alignment)\n 24h 4 \"data\"\n 28h 4 Size of following data (usually N*930h)\nThe first 16 sectors on the first track are the system area, for a Playstation disk, it contains the following:
Sector 0..3 - Zerofilled (Mode2/Form1, 4x800h bytes, plus ECC/EDC)\n Sector 4 - Licence String\n Sector 5..11 - Playstation Logo (3278h bytes) (remaining bytes FFh-filled)\n Sector 12..15 - Zerofilled (Mode2/Form2, 4x914h bytes, plus EDC)\n 000h 32 Line 1 (\" Licensed by \")\n 020h 32+6 Line 2 (EU) (\"Sony Computer Entertainment Euro\",\" pe \") ;\\either\n 020h 32+1 Line 2 (JP) (\"Sony Computer Entertainment Inc.\",0Ah) ; one of\n 020h 32+6 Line 2 (US) (\"Sony Computer Entertainment Amer\",\" ica \") ;/these\n 041h 1983 Empty (JP) (filled by repeating pattern 62x30h,1x0Ah, 1x30h)\n 046h 1978 Empty (EU/US) (filled by 00h-bytes)\n 0000h .. 41h,00h,00h,00h,00h,00h,00h,00h,01h,00h,00h,00h,1Ch,23h,00h,00h\n 0010h .. 51h,01h,00h,00h,A4h,2Dh,00h,00h,99h,00h,00h,00h,1Ch,00h,00h,00h\n 0020h .. ...\n 3278h 588h FF-filled (remaining bytes on sector 11)\nPlaystation disks usually have only two Volume Descriptors,
Sector 16 - Primary Volume Descriptor\n Sector 17 - Volume Descriptor Set Terminator\n 000h 1 Volume Descriptor Type (01h=Primary Volume Descriptor)\n 001h 5 Standard Identifier (\"CD001\")\n 006h 1 Volume Descriptor Version (01h=Standard)\n 007h 1 Reserved (00h)\n 008h 32 System Identifier (a-characters) (\"PLAYSTATION\")\n 028h 32 Volume Identifier (d-characters) (max 8 chars for PSX?)\n 048h 8 Reserved (00h)\n 050h 8 Volume Space Size (2x32bit, number of logical blocks)\n 058h 32 Reserved (00h)\n 078h 4 Volume Set Size (2x16bit) (usually 0001h)\n 07Ch 4 Volume Sequence Number (2x16bit) (usually 0001h)\n 080h 4 Logical Block Size in Bytes (2x16bit) (usually 0800h) (1 sector)\n 084h 8 Path Table Size in Bytes (2x32bit) (max 800h for PSX)\n 08Ch 4 Path Table 1 Block Number (32bit little-endian)\n 090h 4 Path Table 2 Block Number (32bit little-endian) (or 0=None)\n 094h 4 Path Table 3 Block Number (32bit big-endian)\n 098h 4 Path Table 4 Block Number (32bit big-endian) (or 0=None)\n 09Ch 34 Root Directory Record (see next chapter)\n 0BEh 128 Volume Set Identifier (d-characters) (usually empty)\n 13Eh 128 Publisher Identifier (a-characters) (company name)\n 1BEh 128 Data Preparer Identifier (a-characters) (empty or other)\n 23Eh 128 Application Identifier (a-characters) (\"PLAYSTATION\")\n 2BEh 37 Copyright Filename (\"FILENAME.EXT;VER\") (empty or text)\n 2E3h 37 Abstract Filename (\"FILENAME.EXT;VER\") (empty)\n 308h 37 Bibliographic Filename (\"FILENAME.EXT;VER\") (empty)\n 32Dh 17 Volume Creation Timestamp (\"YYYYMMDDHHMMSSFF\",timezone)\n 33Eh 17 Volume Modification Timestamp (\"0000000000000000\",00h)\n 34Fh 17 Volume Expiration Timestamp (\"0000000000000000\",00h)\n 360h 17 Volume Effective Timestamp (\"0000000000000000\",00h)\n 371h 1 File Structure Version (01h=Standard)\n 372h 1 Reserved for future (00h-filled)\n 373h 141 Application Use Area (00h-filled for PSX and VCD)\n 400h 8 CD-XA Identifying Signature (\"CD-XA001\" for PSX and VCD)\n 408h 2 CD-XA Flags (unknown purpose) (00h-filled for PSX and VCD)\n 40Ah 8 CD-XA Startup Directory (00h-filled for PSX and VCD)\n 412h 8 CD-XA Reserved (00h-filled for PSX and VCD)\n 41Ah 345 Application Use Area (00h-filled for PSX and VCD)\n 573h 653 Reserved for future (00h-filled)\n 000h 1 Volume Descriptor Type (FFh=Terminator)\n 001h 5 Standard Identifier (\"CD001\")\n 006h 1 Terminator Version (01h=Standard)\n 007h 2041 Reserved (00h-filled)\n 000h 1 Volume Descriptor Type (00h=Boot Record)\n 001h 5 Standard Identifier (\"CD001\")\n 006h 1 Boot Record Version (01h=Standard)\n 007h 32 Boot System Identifier (a-characters)\n 027h 32 Boot Identifier (a-characters)\n 047h 1977 Boot System Use (not specified content)\n 000h 1 Volume Descriptor Type (02h=Supplementary Volume Descriptor)\n 001h .. Same as for Primary Volume Descriptor (see there)\n 007h 1 Volume Flags (8bit)\n 008h .. Same as for Primary Volume Descriptor (see there)\n 058h 32 Escape Sequences (32 bytes)\n 078h .. Same as for Primary Volume Descriptor (see there)\n 000h 1 Volume Descriptor Type (03h=Volume Partition Descriptor)\n 001h 5 Standard Identifier (\"CD001\")\n 006h 1 Volume Partition Version (01h=Standard)\n 007h 1 Reserved (00h)\n 008h 32 System Identifier (a-characters) (32 bytes)\n 028h 32 Volume Partition Identifier (d-characters) (32 bytes)\n 048h 8 Volume Partition Location (2x32bit) Logical Block Number\n 050h 8 Volume Partition Size (2x32bit) Number of Logical Blocks\n 058h 1960 System Use (not specified content)\n 000h 1 Volume Descriptor Type (04h..FEh=Reserved, don't use)\n 001h 2047 Reserved (don't use)\nThe location of the Root Directory is described by a 34-byte Directory Record being located in Primary Volume Descriptor entries 09Ch..0BDh. The data therein is: Block Number (usually 22 on PSX disks), LEN_FI=01h, Name=00h, and, LEN_SU=00h (due to the 34-byte limit).
"},{"location":"cdromdrive/#format-of-a-directory-record","title":"Format of a Directory Record","text":" 00h 1 Length of Directory Record (LEN_DR) (33+LEN_FI+pad+LEN_SU) (0=Pad)\n 01h 1 Extended Attribute Record Length (usually 00h)\n 02h 8 Data Logical Block Number (2x32bit)\n 0Ah 8 Data Size in Bytes (2x32bit)\n 12h 7 Recording Timestamp (yy-1900,mm,dd,hh,mm,ss,timezone)\n 19h 1 File Flags 8 bits (usually 00h=File, or 02h=Directory)\n 1Ah 1 File Unit Size (usually 00h)\n 1Bh 1 Interleave Gap Size (usually 00h)\n 1Ch 4 Volume Sequence Number (2x16bit, usually 0001h)\n 20h 1 Length of Name (LEN_FI)\n 21h LEN_FI File/Directory Name (\"FILENAME.EXT;1\" or \"DIR_NAME\" or 00h or 01h)\n xxh 0..1 Padding Field (00h) (only if LEN_FI is even)\n xxh LEN_SU System Use (LEN_SU bytes) (see below for CD-XA disks)\n 00h 2 Owner ID Group (whatever, usually 0000h, big endian)\n 02h 2 Owner ID User (whatever, usually 0000h, big endian)\n 04h 2 File Attributes (big endian):\n 0 Owner Read (usually 1)\n 1 Reserved (0)\n 2 Owner Execute (usually 1)\n 3 Reserved (0)\n 4 Group Read (usually 1)\n 5 Reserved (0)\n 6 Group Execute (usually 1)\n 7 Reserved (0)\n 8 World Read (usually 1)\n 9 Reserved (0)\n 10 World Execute (usually 1)\n 11 IS_MODE2 (0=MODE1 or CD-DA, 1=MODE2)\n 12 IS_MODE2_FORM2 (0=FORM1, 1=FORM2)\n 13 IS_INTERLEAVED (0=No, 1=Yes...?) (by file and/or channel?)\n 14 IS_CDDA (0=Data or ADPCM, 1=CD-DA Audio Track)\n 15 IS_DIRECTORY (0=File or CD-DA, 1=Directory Record)\n Commonly used Attributes are:\n 0D55h=Normal Binary File (with 800h-byte sectors)\n 1555h=Uncommon (fade to black .DPS and .XA files)\n 2555h=Uncommon (wipeout .AV files) (MODE1 ??)\n 4555h=CD-DA Audio Track (wipeout .SWP files, alone .WAV file)\n 3D55h=Streaming File (ADPCM and/or MDEC or so)\n 8D55h=Directory Record (parent-, current-, or sub-directory)\n 06h 2 Signature (\"XA\")\n 08h 1 File Number (Must match Subheader's File Number)\n 09h 5 Reserved (00h-filled)\n - Directory sizes are always rounded up to N*800h-bytes.\n - Directory entries should not cross 800h-byte sector boundaries.\n There may be further directory entries on the next sector after the padding.\n To deal with that, skip 00h-bytes until finding a nonzero LEN_DR value (or\n slightly faster, upon a 00h-byte, directly jump to next sector instead of\n doing a slow byte-by-byte skip).\n Note: Padding between sectors does rarely happen on PSX discs because the\n PSX kernel supports max 800h bytes per directory (one exception is PSX Hot\n Shots Golf 2, which has an ISO directory with more than 800h bytes; it does\n use a lookup file instead of actually parsing the while ISO directory).\nThe Path Table contain a summary of the directory names (the same information is also stored in the directory records, so programs may either use path tables or directory records; the path tables are allowing to read the whole directory tree quickly at once, without neeeding to seek from directory to directory). Path Table 1 is in Little-Endian format, Path Table 3 contains the same data in Big-Endian format. Path Table 2 and 4 are optional copies of Table 1 and 3. The size and location of the tables is stored in Volume Descriptor entries 084h..09Bh. The format of the separate entries within a Path Table is,
00h 1 Length of Directory Name (LEN_DI) (01h..08h for PSX)\n 01h 1 Extended Attribute Record Length (usually 00h)\n 02h 4 Directory Logical Block Number\n 06h 2 Parent Directory Number (0001h and up)\n 08h LEN_DI Directory Name (d-characters, d1-characters) (or 00h for Root)\n xxh 0..1 Padding Field (00h) (only if LEN_FI is odd)\nIf present, an Extended Attribute Record shall be recorded over at least one Logical Block. It shall have the following contents.
00h 4 Owner Identification (numerical value) ;\\used only if\n 04h 4 Group Identification (numerical value) ; File Flags Bit4=1\n 08h 2 Permission Flags (16bit, little-endian) ;/\n 0Ah 17 File Creation Timestamp (\"YYYYMMDDHHMMSSFF\",timezone)\n 1Bh 17 File Modification Timestamp (\"0000000000000000\",00h)\n 2Ch 17 File Expiration Timestamp (\"0000000000000000\",00h)\n 3Dh 17 File Effective Timestamp (\"0000000000000000\",00h)\n 4Eh 1 Record Format (numerical value)\n 4Fh 1 Record Attributes (numerical value)\n 50h 4 Record Length (numerical value)\n 54h 32 System Identifier (a-characters, a1-characters)\n 74h 64 System Use (not specified content)\n B4h 1 Extended Attribute Record Version (numerical value)\n B5h 1 Length of Escape Sequences (LEN_ESC)\n B6h 64 Reserved for future standardization (00h-filled)\n F6h 4 Length of Application Use (LEN_AU)\n FAh LEN_AU Application Use\n xxh LEN_ESC Escape Sequences\nAll 16bit and 32bit numbers in the ISO region are stored twice, once in Little-Endian order, and then in Big-Endian Order. For example,
2x16bit value 1234h ---> stored as 34h,12h,12h,34h\n 2x32bit value 12345678h ---> stored as 78h,56h,34h,12h,12h,34h,56h,78h\n \"0..9\", \"A..Z\", and \"_\"\n \"0..9\", \"A..Z\", SPACE, \"!\"%&'()*+,-./:;<=>?_\"\nSEPARATOR 1 = 2Eh (aka \".\") (extension; eg. \"EXT\") SEPARATOR 2 = 3Bh (aka \";\") (file version; \"1\"..\"32767\")
"},{"location":"cdromdrive/#fixed-length-stringsfilenames","title":"Fixed Length Strings/Filenames","text":"The Volume Descriptors contain a number fixed-length string/filename fields (unlike the Directory Records and Path Tables which have variable lengths). These fields should be padded with SPACE characters if they are empty, or if the string is shorter than the maximum length. Filename fields in Volume Descriptors are referring to files in the Root Directory. On PSX disks, the filename fields are usually empty, but some disks are mis-using the Copyright Filename to store the Company Name (although no such file exists on the disk).
"},{"location":"cdromdrive/#volume-descriptor-timestamps","title":"Volume Descriptor Timestamps","text":"The various timestamps occupy 17 bytes each, in form of
\"YYYYMMDDHHMMSSFF\",timezone\n \"0000000000000000\",00h ;empty timestamp\nOccupy only 7 bytes, in non-ascii format
year-1900,month,day,hour,minute,second,timezone\n 00h,00h,00h,00h,00h,00h,00h ;empty timestamp\nIf this Directory Record identifies a directory then bit 2,3,7 shall be set to ZERO. If no Extended Attribute Record is associated with the File Section identified by this Directory Record then bit positions 3 and 4 shall be set to ZERO.
0 Existence (0=Normal, 1=Hidden)\n 1 Directory (0=File, 1=Directory)\n 2 Associated File (0=Not an Associated File, 1=Associated File)\n 3 Record\n If set to ZERO, shall mean that the structure of the information in\n the file is not specified by the Record Format field of any associated\n Extended Attribute Record (see 9.5.8).\n If set to ONE, shall mean that the structure of the information in\n the file has a record format specified by a number other than zero in\n the Record Format Field of the Extended Attribute Record (see 9.5.8).\n 4 Restrictions (0=None, 1=Restricted via Permission Flags)\n 5 Reserved (0)\n 6 Reserved (0)\n 7 Multi-Extent (0=Final Directory Record for the file, 1=Not final)\n 0-3 Permissions for upper-class owners\n 4-7 Permissions for normal owners\n 8-11 Permissions for upper-class users\n 12-15 Permissions for normal users\n Bit0 Permission to read the file (0=Yes, 1=No)\n Bit1 Must be set (1)\n Bit2 Permission to execute the file (0=Yes, 1=No)\n Bit3 Must be set (1)\nThe discs contains two separate filesystems, the ISO one for backwards compatibilty, and the Joliet one with longer filenames and Unicode characters.
Sector 16 - Primary Volume Descriptor (with 8bit uppercase ASCII ISO names)\n Sector 17 - Secondary Volume Descriptor (with 16bit Unicode Joliet names)\n Sector 18 - Volume Descriptor Set Terminator\n Sector .. - Path Tables and Directory Records (for ISO)\n Sector .. - Path Tables and Directory Records (for Joliet)\n Sector .. - File Data Sectors (shared for ISO and Joliet)\nThis is using the same format as ISO Primary Volume Descriptor (but with some changed entries). CDROM ISO Volume Descriptors Changed entries are:
000h 1 Volume Descriptor Type (02h=Supplementary instead of 01h=Primary)\n 007h 1 Volume Flags (whatever, instead of Reserved)\n 008h 2x32 Identifier Strings (16-char Unicode instead 32-char ASCII)\n 058h 32 Escape Sequences (see below, instead of Reserved)\n 08Ch 4x4 Path Tables (point to new tables with Unicode chars)\n 09Ch 34 Root Directory Record (point to root with Unicode chars)\n 0BEh 4x128 Identifier Strings (64-char Unicode instead 128-char ASCII)\n 2BEh 3x37 Filename Strings (18-char Unicode instead 37-char ASCII)\n %/@ UCS-2 Level 1\n %/C UCS-2 Level 2\n %/E UCS-2 Level 3\nThis is using the standard ISO format (but with 16bit Unicode characters instead of 8bit ASCII chars). CDROM ISO File and Directory Descriptors
"},{"location":"cdromdrive/#file-and-directory-name-characters","title":"File and Directory Name Characters","text":"All characters are stored in 16bit Big Endian format. The LEN_FI filename entry contains the length in bytes (ie. numchars*2). Charaters 0000h/0001h are current/parent directory. Characters 0020h and up can be used for file/directory names, except six reserved characters: */:;?\\ All names must be sorted by their character numbers, padded with zero (without attempting to merge uppercase, lowercase, or umlauts to nearby locations).
"},{"location":"cdromdrive/#file-and-directory-name-length","title":"File and Directory Name Length","text":" max 64 chars according to original Joliet specs from 1995\n max 110 chars (on standard CDROMs, with LEN_SU=0)\n max 103 chars (on CD-XA discs, with LEN_SU=14)\nJoliet Specification, CD-ROM Recording Spec ISO 9660:1988, Extensions for Unicode Version 1; May 22, 1995, Copyright 1995, Microsoft Corporation
http://littlesvr.ca/isomaster/resources/JolietSpecification.html\nThe heart of the PSX copy-protection is the four-letter \"SCEx\" string, encoded in the wobble signal of original PSX disks, which cannot be reproduced by normal CD writers. The last letter varies depending on the region:
\"SCEI\" for Japan\n \"SCEA\" for America (and all other NTSC countries except Japan)\n \"SCEE\" for Europe (and all other PAL countries like Australia)\nA \"blank\" CDR contains a pre-formatted spiral on it. The number of windings in the spiral varies depending on the number of minutes that can be recorded on the disk. The spiral isn't made of a straight line (------), but rather a wobbled line (/\\/\\/), which is used to adjust the rotation speed during recording; at normal drive speed, wobble should produce a 22050Hz sine wave. Additionally, the CDR wobble is modulated to provide ATIP information, ATIP is used for locating and positioning during recording, and contains information about the approximate laser power necessary for recording, the last possible time location that lead out can start, and the disc application code. Wobble is commonly used only on (recordable) CDRs, ie. usually NOT on (readonly) CDROMs and Audio Disks. The copyprotected PSX CDROMs are having a short CDR-style wobble period in the first some seconds, which seems to contain the \"SCEx\" string instead of ATIP information.
"},{"location":"cdromdrive/#other-protections","title":"Other Protections","text":"Aside from the SCEx string, PSX disks are required to contain region and licence strings (in the ISO System Area, and in the .EXE file headers), and the \"PS\" logo (in the System Area, too). This data can be reproduced with normal CD writers, although it may be illegal to distribute unlicensed disks with licence strings.
"},{"location":"cdromdrive/#cdrom-protection-bypassing-it","title":"CDROM Protection - Bypassing it","text":""},{"location":"cdromdrive/#modchips","title":"Modchips","text":"A modchip is a small microcontroller which injects the \"SCEx\" signal to the mainboard, so the PSX can be booted even from CDRs which don't contain the \"SCEx\" string. Some modchips are additionally patching region checks contained in the BIOS ROM. Note: Although regular PSX disks are black, the hardware doesn't verify the color of the disks, and works also with normal silver disks.
"},{"location":"cdromdrive/#disk-swap-trick","title":"Disk-Swap-Trick","text":"Once when the PSX has recognized a disk with the \"SCEx\" signal, it'll be satisfied until a new disk is inserted, which is sensed by the SHELL_OPEN switch. When having that switch blocked, it is possible to insert a CDR without the PSX noticing that the disk was changed. Additionally, the trick requires some boot software that stops the drive motor (so the new disk can be inserted, despite of the PSX thinking that the drive door is still closed), and that does then start the boot executable on the new disk. The boot software can be stored on a special boot-disk (that do have the \"SCEx\" string on it). Alternately, a regular PSX game disk could be used, with the boot software stored somewhere else (eg. on Expansion ROM, or BIOS ROM replacement, or Memory Card).
"},{"location":"cdromdrive/#booting-via-bios-rom-or-expansion-rom","title":"Booting via BIOS ROM or Expansion ROM","text":"The PSX can be quite easily booted via Expansion ROM, or BIOS ROM replacements, allowing to execute code that is stored in the ROM, or that is received via whatever serial or parallel cable connection from a PC. However, even with a BIOS replacement, the protection in the CDROM controller is still active, so the ROM can't read \"clean\" data from the CDROM Drive (unless the Disk-Swap trick is used). Whereas, no \"clean\" data doens't mean no data at all. The CDROM controller does still seem to output \"raw\" data (without removing the sector header, and without handling error correction, and with only limited accuracy on the sector position). So, eventually, a customized BIOS could convert the \"raw\" data to \"clean\" data.
"},{"location":"cdromdrive/#secret-unlock-commands","title":"Secret Unlock Commands","text":"There is an \"official\" backdoor that allows to disable the SCEx protection by software via secret commands (for example, sending those commands can be done via BIOS patches, nocash BIOS clone, or Expansion ROMs). CDROM - Secret Unlock Commands
"},{"location":"cdromdrive/#booting-via-memory-card","title":"Booting via Memory Card","text":"Some games that load data from memory cards may get confused if the save data isn't formatted as how they expect it - with some fine tuning you can get them to \"crash\" in a manner that they do accidently execute bootcode stored on the memory card. This is how tonyhax's game exploits and FreePSXBoot's BIOS shell exploit work. Requires a tools to write to the memory card (eg. parallel port cable), and the memory card data customized for a specific game, and an original CDROM with that specific game. Once when the memory card code is booted, the Disk-Swap trick can be used.
"},{"location":"cdromdrive/#cdrom-protection-modchips","title":"CDROM Protection - Modchips","text":""},{"location":"cdromdrive/#modchip-source-code","title":"Modchip Source Code","text":"The Old Crow mod chip source code works like so:
entrypoint: ;at power_up\n gate=input/highz\n data=input/highz\n wait 50 ms\n data=output/low\n wait 850 ms\n gate=output/low\n wait 314 ms\n loop:\n wait 72 ms ;pause (eighteen \"1=low\" bits)\n sendbyte(\"S\") ;1st letter\n sendbyte(\"C\") ;2nd letter\n sendbyte(\"E\") ;3rd letter\n sendbyte(...) ;4th letter (A, E, or I, depending on region)\n goto loop\n sendbyte(char):\n sendbit(0) ;one start bit (0=highz)\n for i=0 to 7\n sendbit(char AND 1) ;output data (LSB first)\n char=char/2\n next i\n sendbit(1) ;1st stop bit (1=low)\n sendbit(1) ;2nd stop bit (1=low)\n return\n sendbit(bit):\n if bit=1 then data=output/low elseif bit=0 then data=input/highz\n wait 4 ms ;4ms per bit = 250 bits per second\n return\nFor older PSX boards (data/gate):
Board data gate\n PU-xx unknown? unknown? ;older PSX boards\n Board data sync\n PU-23, PM-41 CXD2938Q.Pin42 CXD2938Q.Pin5 ;newer PSX and older PSone\n PM-41(2) CXD2941R.Pin36 CXD2941R.Pin76 ;newer PSone boards\nTransfers the \"SCEx\" data. Note that the signal produced by the modchip is looking entirly different than the signal produced by original disks, the real signal would be modulated 22050Hz wobble, while the modchip is simply dragging the signal permanently LOW throughout \"1\" bits, and leaves it floating for \"0\" bits. Anyways the \"faked\" signal seems to be accurate enough to work.
"},{"location":"cdromdrive/#note-on-gate-pin-older-psx-boards-only","title":"Note on \"gate\" pin (older PSX boards only)","text":"The \"gate\" pin needs to be LOW only for use with original licensed disks (reportedly otherwise the SCEx string on that disks would conflict with the SCEx string from the modchip). At the mainboard side, the \"gate\" signal is an input, and \"data\" is an inverted output of the gate signal (so dragging gate to low, would cause data to go high).
"},{"location":"cdromdrive/#note-on-sync-pin-newer-psx-and-psone-boards-only","title":"Note on \"sync\" pin (newer PSX and PSone boards only)","text":"The \"sync\" pin is a testpoint on the mainboard, which does (at single speed) output a frequency of circa 44.1kHz/6 (of which some clock pulses seem to be longer or shorter, probably to indicate adjustments to the rotation speed). Some modchips are connected directly to \"sync\" (so they are apparently synchronizing the data output with that signal; which is not implemented in the above source code). Anyways, other modchips are using a more simplified connection: The modchip itself connects only to the \"data\" pin, and \"sync\" is required to be wired to IC723.Pin17.
"},{"location":"cdromdrive/#note-on-multi-region-chips","title":"Note on Multi-Region chips","text":"Modchips that are designed to work in different regions are sending a different string (SCEA, SCEE, SCEI) in each loop cycle. Due to the slow 250bps transfer rate, it may take a while until the PSX has received the correct string, so this multi-region technique may cause a noticeable boot-delay.
"},{"location":"cdromdrive/#stealth-hidden-modchip","title":"Stealth (hidden modchip)","text":"The Stealth connection is required for some newer games with anti-modchip protection, ie. games that refuse to run if they detect a modchip. The detection relies on the fact that the SCEx signal is normally received only when booting the disk, whilst older modchips were sending that signal permanently. Stealth modchips are sending the signal only on power-up (and when inserting a new disk, which can be sensed via SHELL_OPEN signal). Modchip detection reportedly works like so (not too sure if all commands are required, some seem to be rather offtopic):
1. Com 19h,20h ;Retrieve CDROM Controller timestamp\n 2. Com 01h ;CdlNop: Get CD status\n 3. Com 07h ;CdlMotorOn: Make CD-ROM drive ready (blah?)\n 4. Com 02h,1,1,1 ;CdlSetloc(01:01:01) (sector that does NOT have SCEx data)\n 5. Com 0Eh,1 ;CdlSetmode: Turn on CD-DA read mode\n 6. Short Delay\n 7. Com 16h ;CdlSeekP: Seek to Setloc's parameters (4426)\n 8. Com 0Bh ;CdlMute: Turn off sound so CdlPlay is inaudible\n 9. Com 03h ;CdlPlay: Start playing CD-DA.\n 10. Com 19h,04h ;ResetSCExInfo (reset GetSCExInfo response to 0,0)\n 11. Long Delay ;wait until the modchip (if any) has output SCEx data\n 12. Com 19h,05h ;GetSCExInfo (returns total,success counters)\n 13. Com 09h ;CdlPause: Stop command 19h.\nTypically connects to two or three BIOS address/data lines, apparently watching that signals, and dragging a data line LOW at certain time, to skip software based region checks (eg. allowing to play NTSC games on PAL consoles). Aside from the modchip connection, that additionally requires to adjust the video signal (in 60Hz NTSC mode, the PSX defaults to generate a NTSC video signal) (whilst most PAL screens can handle 60Hz refresh, they can't handle NTSC colors) (on PSone boards, this can be fixed simply by grounding the /PAL pin; IC502.Pin13) (on older PSX boards it seems to be required to install an external color clock generator).
"},{"location":"cdromdrive/#modchip-connection-example","title":"MODCHIP Connection Example","text":"Connection for 8pin \"12C508\" mod chip from fatcat.co.nz for a PAL PSone with PM-41 board (ie. with 208pin SPU CXD2938Q, and 52pin IC304 \"C 3060, SC430943PB\"):
1 3.5V (supply)\n 2 IC304.Pin44 (unknown?) (XLAT)\n 3 BIOS.Pin15 (D2)\n 4 BIOS.Pin31 (A18)\n 5 SPU.Pin5 (\"sync\")\n 6 SPU.Pin42 (\"data\")\n 7 IC304.Pin19 (SHELL_OPEN)\n 8 GND (supply)\nThe nocash PSX bios outputs the \"data\" signal on the A20 address line, so (aside from the BIOS chip) one only needs to install a 1N4148 diode and two wires to unlock the CDROM:
SPU.Pin42 \"data\" -------|>|------ CPU.Pin149 (A20)\n SPU.Pin5 \"sync\" ---------------- IC723.Pin17\nThe nocash kernel clone outputs a SCEX signal via A20 and A21 address lines, (so one won't need a separate modchip/microprocessor):
A20 = the normal SCEX signal (inverted ASCII, eg. \"A\" = BEh) ;all boards\n A21 = uninverted SCEX signal (uninverted ASCII, eg. \"A\" = 41h) ;PU-7..PU-20\n A21 = always 1 during SCEX output ;PU-22 and up\n .--------.-. .--------.-.\n GATE--------|C NPN | . DATA--------|C NPN | .\n A20--[10K]--|B BC | | A21--[10K]--|B BC | |\n GND---------|E 547 | ' GND---------|E 547 | '\n '--------'-' '--------'-'\n .-------------------.\n A21----|OE1,OE2 |\n A20----|IN1 74HC126 OUT1|--- DATA\n WFCK---|IN2 OUT2|--- SYNC\n '-------------------'\n GATE---------GND\n DATA---------A20\n SYNC--------WFCK\n DATA---|>|---A20\n GATE is IC703.Pin2 (?) (8pin chip with marking \"082B\") ;PU-7? .. PU-16\n GATE is IC706.Pin7/10 (16pin \"118\" (uPC5023GR-118) ;PU-18 .. PU-20\n SYNC is IC723.Pin17(TEO)(20pin \"SONY CXA2575N\") ;PU-22 .. PM-41(2)\n DATA is IC???.Pin7 (CG) (8pin chip with marking \"2903\") ;PU-7? .. PU-16\n DATA is IC706.Pin1 (CG) (16pin \"118\" (uPC5023GR-118) ;PU-18 .. PU-20\n DATA is HC05.Pin17 (CG) (52pin \"SONY SC4309xxPB\") ;PU-7 .. EARLY-PU-8\n DATA is HC05.Pin32 (CG) (80pin \"SONY E35D, 4246xx 185\") ;LATE-PU-8 .. PU-20\n DATA is SPU.Pin42 (CEI) (208pin \"SONY CXD2938Q\") ;PU-22 .. PM-41\n DATA is SPU.Pin36?(CEI) (176pin \"SONY CXD2941R\") ;PM-41(2)\n WFCK is SPU.Pin5 (WFCK) (208pin \"SONY CXD2938Q\") ;PU-22 .. PM-41\n WFCK is SPU.Pin84(WFCK) (176pin \"SONY CXD2941R\") ;PM-41(2)\n A20 is CPU.Pin149(A20) (208-pin CPU CXD8530 or CXD8606) ;PU-7 .. PM-41(2)\n A20 is EXP.Pin28 (A20) (68-pin Expansion Port) ;PU-7 .. PU-22\n A21 is CPU.Pin150(A21) (208-pin CPU CXD8530 or CXD8606) ;PU-7 .. PM-41(2)\n A21 is EXP.Pin62 (A21) (68-pin Expansion Port) ;PU-7 .. PU-22\nLibCrypt is an additional copy-protection, used by about 100 PSX games. The protection uses a 16bit decryption key, which is stored as bad position data in Subchannel Q. The 16bit key is then used for a simple XOR-decryption on certain 800h-byte sectors.
"},{"location":"cdromdrive/#protected-sectors-generation-schemas","title":"Protected sectors generation schemas","text":"There are some variants on how the Subchannel Q data is modified:
1. 2 bits from both MSFs are modified,\n CRC-16 is recalculated and XORed with 0x0080.\n Games: MediEvil (E).\n 2. 2 bits from both MSFs are modified,\n original CRC-16 is XORed with 0x8001.\n Games: CTR: Crash Team Racing (E) (No EDC), CTR: Crash Team Racing (E)\n (EDC), Dino Crisis (E), Eagle One: Harrier Attack (E) et al.\n 3. Either 2 bits or none from both MSFs are modified,\n CRC-16 is recalculated and XORed with 0x0080.\n Games: Ape Escape (S) et al.\nThe modified sectors could be theoretically located anywhere on the disc, however, all known protected games are having them located on the same sectors:
No. <------- Minute=03/Normal -------> <------- Minute=09/Backup ------->\n Bit15 14105 (03:08:05) 14110 (03:08:10) 42045 (09:20:45) 42050 (09:20:50)\n Bit14 14231 (03:09:56) 14236 (03:09:61) 42166 (09:22:16) 42171 (09:22:21)\n Bit13 14485 (03:13:10) 14490 (03:13:15) 42432 (09:25:57) 42437 (09:25:62)\n Bit12 14579 (03:14:29) 14584 (03:14:34) 42580 (09:27:55) 42585 (09:27:60)\n Bit11 14649 (03:15:24) 14654 (03:15:29) 42671 (09:28:71) 42676 (09:29:01)\n Bit10 14899 (03:18:49) 14904 (03:18:54) 42813 (09:30:63) 42818 (09:30:68)\n Bit9 15056 (03:20:56) 15061 (03:20:61) 43012 (09:33:37) 43017 (09:33:42)\n Bit8 15130 (03:21:55) 15135 (03:21:60) 43177 (09:35:52) 43182 (09:35:57)\n Bit7 15242 (03:23:17) 15247 (03:23:22) 43289 (09:37:14) 43294 (09:37:19)\n Bit6 15312 (03:24:12) 15317 (03:24:17) 43354 (09:38:04) 43359 (09:38:09)\n Bit5 15378 (03:25:03) 15383 (03:25:08) 43408 (09:38:58) 43413 (09:38:63)\n Bit4 15628 (03:28:28) 15633 (03:28:33) 43634 (09:41:59) 43639 (09:41:64)\n Bit3 15919 (03:32:19) 15924 (03:32:24) 43963 (09:46:13) 43968 (09:46:18)\n Bit2 16031 (03:33:56) 16036 (03:33:61) 44054 (09:47:29) 44059 (09:47:34)\n Bit1 16101 (03:34:51) 16106 (03:34:56) 44159 (09:48:59) 44164 (09:48:64)\n Bit0 16167 (03:35:42) 16172 (03:35:47) 44312 (09:50:62) 44317 (09:50:67)\nLegacy of Kain (PAL) is reading the LibCrypt data during the title screen, and does then display GOT KEY!!! on TTY terminal (this, no matter if the correct 16bit key was received). The actual protection jumps in a bit later (shortly after learning to glide, the game will hang when the first enemies appear if the key isn't okay). Thereafter, the 16bit key is kept used once and when to decrypt 800h-byte sector data via simple XORing. The 16bit key (and some other related counters/variables) aren't stored in RAM, but rather in COP0 debug registers (which are mis-used as general-purpose storage in this case), for example, the 16bit key is stored in LSBs of the \"cop0r3\" register. In particuar, the encryption is used for some of the BIGFILE.DAT folder headers: CDROM File Archive BIGFILE.DAT (Soul Reaver)
"},{"location":"cdromfileformats/","title":"CDROM File Formats","text":""},{"location":"cdromfileformats/#official-psx-file-formats","title":"Official PSX File Formats","text":"CDROM File Official Sony File Formats
"},{"location":"cdromfileformats/#executables","title":"Executables","text":"CDROM File Playstation EXE and SYSTEM.CNF CDROM File PsyQ .CPE Files (Debug Executables) CDROM File PsyQ .SYM Files (Debug Information)
"},{"location":"cdromfileformats/#video-files","title":"Video Files","text":"CDROM File Video Texture Image TIM/PXL/CLT (Sony) CDROM File Video Texture/Bitmap (Other) CDROM File Video 2D Graphics CEL/BGD/TSQ/ANM/SDF (Sony) CDROM File Video 3D Graphics TMD/PMD/TOD/HMD/RSD (Sony) CDROM File Video STR Streaming and BS Picture Compression (Sony)
"},{"location":"cdromfileformats/#audio-files","title":"Audio Files","text":"CDROM File Audio Single Samples VAG (Sony) CDROM File Audio Sample Sets VAB and VH/VB (Sony) CDROM File Audio Sequences SEQ/SEP (Sony) CDROM File Audio Other Formats CDROM File Audio Streaming XA-ADPCM CDROM File Audio CD-DA Tracks
"},{"location":"cdromfileformats/#virtual-filesystem-archives","title":"Virtual Filesystem Archives","text":"PSX titles are quite often using virtual filesystems, with numerous custom file archive formats. CDROM File Archives with Filename CDROM File Archives with Offset and Size CDROM File Archives with Offset CDROM File Archives with Size CDROM File Archives with Chunks CDROM File Archives with Folders CDROM File Archives in Hidden Sectors More misc stuff... CDROM File Archive HED/DAT/BNS/STR (Ape Escape) CDROM File Archive WAD.WAD, BIG.BIN, JESTERS.PKG (Crash/Herc/Pandemonium) CDROM File Archive BIGFILE.BIG (Gex) CDROM File Archive BIGFILE.DAT (Gex - Enter the Gecko) CDROM File Archive FF9 DB (Final Fantasy IX) CDROM File Archive Ace Combat 2 and 3 CDROM File Archive NSD/NSF (Crash Bandicoot 1-3) CDROM File Archive STAGE.DIR and *.DAT (Metal Gear Solid) CDROM File Archive DRACULA.DAT (Dracula) CDROM File Archive Croc 1 (DIR, WAD, etc.) CDROM File Archive Croc 2 (DIR, WAD, etc.) CDROM File Archive Headerless Archives Using archives can avoid issues with the PSX's poorly implemented ISO filesystem: The PSX kernel supports max 800h bytes per directory, and lacks proper caching for most recently accessed directories (additionally, some archives can load the whole file/directory tree from continous sectors, which could be difficult in ISO filesystems).
"},{"location":"cdromfileformats/#compression","title":"Compression","text":"CDROM File Compression
"},{"location":"cdromfileformats/#misc","title":"Misc","text":"CDROM File XYZ and Dummy/Null Files
"},{"location":"cdromfileformats/#general-cdrom-disk-images","title":"General CDROM Disk Images","text":"CDROM Disk Images CCD/IMG/SUB (CloneCD) CDROM Disk Images CDI (DiscJuggler) CDROM Disk Images CUE/BIN/CDT (Cdrwin) CDROM Disk Images MDS/MDF (Alcohol 120%) CDROM Disk Images NRG (Nero) CDROM Disk Image/Containers CDZ CDROM Disk Image/Containers ECM CDROM Subchannel Images CDROM Disk Images Other Formats
"},{"location":"cdromfileformats/#filenameext","title":"FILENAME.EXT","text":"The BIOS seems to support only (max) 8-letter filenames with 3-letter extension, typically all uppercase, eg. \"FILENAME.EXT\". Eventually, once when the executable has started, some programs might install drivers for long filenames(?)
The PSX uses the standard CDROM ISO9660 filesystem without any encryption (ie. you can put an original PSX CDROM into a DOS/Windows computer, and view the content of the files in text or hex editors without problems).
"},{"location":"cdromfileformats/#note","title":"Note","text":"MagDemoNN is short for \"Official U.S. Playstation Magazine Demo Disc NN\"
"},{"location":"cdromfileformats/#cdrom-file-official-sony-file-formats","title":"CDROM File Official Sony File Formats","text":""},{"location":"cdromfileformats/#official-sony-file-formats","title":"Official Sony File Formats","text":"https://psx.arthus.net/sdk/Psy-Q/DOCS/Devrefs/Filefrmt.pdf - Sony 1998
File Formats\n (c) 1998 Sony Computer Entertainment Inc.\n Publication date: November 1998\n Chapter 1: Streaming Audio and Video Data\n STR: Streaming (Movie) Data 1-3\n BS: MDEC Bitstream Data 1-8\n XA: CD-ROM Voice Data 1-31\n Chapter 2: 3D Graphics\n RSD: 3D Model Data [RSD,PLY,MAT,GRP,MSH,PVT,COD,MOT,OGP] 2-3\n TMD: Modeling Data for OS Library 2-24\n PMD: High-Speed Modeling Data 2-35\n TOD: Animation Data 2-40\n HMD: Hierarchical 3D Model, Animation and Other Data 2-49\n Chapter 3: 2D Graphics\n TIM: Screen Image Data 3-3\n SDF: Sprite Editor Project File 3-8\n PXL: Pixel Image Data 3-11\n CLT: Palette Data 3-14\n ANM: Animation Information 3-16\n TSQ: Animation Time Sequence 3-22\n CEL: Cell Data 3-23\n BGD: BG Map Data 3-27\n Chapter 4: Sound\n SEQ: PS Sequence Data 4-3\n SEP: PS Multi-Track Sequence Data 4-3\n VAG: PS Single Waveform Data 4-5\n VAB: PS Sound Source Data [VAB and VH/VB] 4-5\n DA: CD-DA Data 4-7\n Chapter 5: PDA and Memory Card\n FAT: Memory Card File System Specification 5-3\nContains boot info in ASCII/TXT format, similar to the CONFIG.SYS or AUTOEXEC.BAT files for MSDOS. A typical SYSTEM.CNF would look like so:
BOOT = cdrom:\\abcd_123.45;1 arg ;boot exe (drive:\\path\\name.ext;version)\n TCB = 4 ;HEX (=4 decimal) ;max number of threads\n EVENT = 10 ;HEX (=16 decimal) ;max number of events\n STACK = 801FFF00 ;HEX (=memtop-256)\nThis is a normal executable (exactly as for the .EXE files, described below), however, the filename/extension is taken from the game code (the \"ABCD-12345\" text that is printed on the CD cover), but, with the minus replaced by an underscore, and due to the 8-letter filename limit, the last two characters are stored in the extension region. That \"XXXX_NNN.NN\" naming convention seems to apply for all official licensed PSX games. Wild Arms does unconventionally have the file in a separate folder, \"EXE\\SCUS_946.06\".
"},{"location":"cdromfileformats/#psxexe-boot-executable-default-filename-when-systemcnf-doesnt-exist","title":"PSX.EXE (Boot-Executable) (default filename when SYSTEM.CNF doesn't exist)","text":""},{"location":"cdromfileformats/#xxxx_nnnnn-boot-executable-with-filename-as-specified-in-systemcnf","title":"XXXX_NNN.NN (Boot-Executable) (with filename as specified in SYSTEM.CNF)","text":""},{"location":"cdromfileformats/#filenameexe-general-purpose-executable","title":"FILENAME.EXE (General-Purpose Executable)","text":"PSX executables are having an 800h-byte header, followed by the code/data.
000h-007h ASCII ID \"PS-X EXE\"\n 008h-00Fh Zerofilled\n 010h Initial PC (usually 80010000h, or higher)\n 014h Initial GP/R28 (usually 0)\n 018h Destination Address in RAM (usually 80010000h, or higher)\n 01Ch Filesize (must be N*800h) (excluding 800h-byte header)\n 020h Data section Start Address (usually 0)\n 024h Data Section Size in bytes (usually 0)\n 028h BSS section Start Address (usually 0) (when below Size=None)\n 02Ch BSS section Size in bytes (usually 0) (0=None)\n 030h Initial SP/R29 & FP/R30 Base (usually 801FFFF0h) (or 0=None)\n 034h Initial SP/R29 & FP/R30 Offs (usually 0, added to above Base)\n 038h-04Bh Reserved for A(43h) Function (should be zerofilled in exefile)\n 04Ch-xxxh ASCII marker\n \"Sony Computer Entertainment Inc. for Japan area\"\n \"Sony Computer Entertainment Inc. for Europe area\"\n \"Sony Computer Entertainment Inc. for North America area\"\n (or often zerofilled in some homebrew files)\n (the BIOS doesn't verify this string, and boots fine without it)\n xxxh-7FFh Zerofilled\n 800h... Code/Data (loaded to entry[018h] and up)\nFade to Black (CINE.EXR) contains ID \"PS-X EXR\" (instead \"PS-X EXE\") and string \"PSX Relocable File - Delphine Software Int.\", this is supposedly some custom relocatable exe file (unsupported by the PSX kernel).
"},{"location":"cdromfileformats/#msdosexe-and-windowsexe-files","title":"MSDOS.EXE and WINDOWS.EXE Files","text":"Some PSX discs contain DOS or Windows .EXE files (with \"MZ\" headers), eg. devkit leftovers, or demos/gimmicks.
"},{"location":"cdromfileformats/#cdrom-file-psyq-cpe-files-debug-executables","title":"CDROM File PsyQ .CPE Files (Debug Executables)","text":""},{"location":"cdromfileformats/#fileheader","title":"Fileheader","text":" 00h 4 File ID (01455043h aka \"CPE\",01h)\n 00h 1 Chunk ID (00h)\n 00h 1 Chunk ID (01h)\n 01h 4 Address (usually 80010000h and up)\n 05h 4 Size (LEN)\n 09h LEN Data (binary EXE code/data)\n 00h 1 Chunk ID (02h)\n 01h 4 Address\n 00h 1 Chunk ID (03h..06h)\n 01h 2 Register (usually 0090h=Initial PC, aka Entrypoint)\n 03h LEN Value (8bit..32bit)\n 00h 1 Chunk ID (07h)\n 01h 4 Workspace number (usually 00000000h)\n 00h 1 Chunk ID (08h)\n 01h 1 Unit (usually 00h)\n 0000h 4 File ID (\"CPE\",01h)\n 0004h 2 Select Unit 0 (08h,00h)\n 0006h 7 Set Entrypoint 8001731Ch (03h,0090h,8001731Ch)\n 000Dh 0Dh Load (01h,800195F8h,00000004h,0,0,0,0)\n 001Ah .. Load (01h,80010000h,0000002Bh,...)\n 004Eh .. Load (01h,8001065Ch,00000120h,...)\n 0177h ... Load (01h,8001077Ch,0000012Ch,...)\n 02ACh ... Load (01h,800108A8h,000000A4h,...)\n ... ... Load (...)\n 98F4h ... Load (01h,800195F0h,00000008h,...)\n 9905h 1 End (00h)\nPsyQ .SYM Files contain debug info, usually bundled with PsyQ .MAP and Psy .CPE files. Those files are generated by PsyQ tools, which appear to be still in use for homebrew PSX titles. The files are occassionally also found on PSX CDROMs:
Legacy of Kain PAL version (\\DEGUG\\NTSC\\KAIN2.SYM+MAP+CPE)\n RC Revenge (\\RELEASE.SYM)\n Twisted Metal: Small Brawl (MagDemo54: TMSB\\TM.SYM)\n Jackie Chan Stuntmaster (GAME_REL.SYM+CPE)\n SnoCross Championship Racing (MagDemo37: SNOCROSS\\SNOW.TOC\\SNOW.MAP)\n Sled Storm (MagDemo24: DEBUG\\MAIN.MAP)\n E.T. Interplanetary Mission (MagDemo54: MEGA\\MEGA.CSH\\* has SYM+CPE+MAP)\n 00h 4 File ID (\"MND\",01h)\n 04h 4 Whatever (0,0,0,0) ;TOMB5: 0,02h,0,0\n 08h .. Chunks (see below)\n 00h 4 Address/Value\n 04h 1 Chunk ID (01h/02h/05h/06h)\n 05h 1 Symbol Length (LEN)\n 06h LEN Symbol (eg. \"VSync\")\n 00h 4 Address (for 1 line, starting at current line)\n 04h 1 Chunk ID (80h)\n 00h 4 Address (for N lines, starting at current line)\n 04h 1 Chunk ID (82h)\n 05h 1 Number of Lines (00h=None, or 02h and up?)\n 00h 4 Address (for N lines, starting at current line)\n 04h 1 Chunk ID (84h)\n 05h 2 Number of Lines (?)\n 00h 4 Address (for 1 line, starting at newly assigned current line)\n 04h 1 Chunk ID (84h)\n 05h 4 Absolute Line Number (rather than number of lines) (?)\n 00h 4 Address (start address)\n 04h 1 Chunk ID (88h=Filename)\n 05h 4 First Line Number (after comments/definitions) (32bit?)\n 09h 1 Filename Length (LEN)\n 0Ah LEN Filename (eg. \"C:\\path\\main.c\")\n 00h 4 Address (end address)\n 04h 1 Chunk ID (8Ah)\n 00h 4 Address\n 04h 1 Chunk ID (8Ch)\n 05h 4 Whatever (1Eh,00h,20h,00h) ;or 1Eh,00h,18h,00h\n 09h 4 Whatever (00h,00h,1Fh,00h)\n 0Dh 4 Whatever (00h,00h,00h,C0h)\n 11h 4 Whatever (FCh,FFh,FFh,FFh) ;mask? neg.offset?\n 15h 4 Whatever (10h,00h,00h,00h) <-- line number (32bit?)\n 19h 1 Filename Length (LEN1)\n 1Ah LEN1 Filename (eg. \"C:\\path\\main.c\")\n xxh 1 Symbol Length (LEN2)\n xxh LEN2 Symbol (eg. \"VSync\")\n 00h 4 Address\n 04h 1 Chunk ID (8Eh)\n 05h 4 Line Number <-- line number (32bit?)\nMaybe line numbers? Or end of definitions for incoming parameters?
00h 4 Address\n 04h 1 Chunk ID (90h/92h)\n 05h 4 Whatever (1Fh,00h,00h,00h) <-- line number relative to main.start?\n 00h 4 Offset (when used within a structure, or stack-N, or otherwise zero)\n 04h 1 Chunk ID (94h)\n 05h 2 Class (000Dh=Type.alias, 000Ah=Address, 0001h=Stack, 0002h=Addr)\n 07h 2 Type (XX = 8bit,16bit,signed,etc.?)\n 09h 4 Zero, or Size in Bytes (for \"memblocks\")\n 0xh 1 Symbol Name Length (LEN)\n 0xh LEN Symbol Name (eg. \"size_t\")\n 00h 4 Offset (when used within a structure, otherwise zero)\n 04h 1 Chunk ID (96h)\n 05h 2 Class (02h=Array,08h=RefToStruct,0Dh=DefineAlias,66h=StructEnd)\n 07h 2 Type (0xh=Small, 3xh=WithArrayStuff?) (same/similar as in chunk 94h)\n 09h 4 Struct Size in Bytes\n 0Dh 2 Array Dimensions (DIM) (0=none) ;eg. [3][4] --> 0002h\n 0Fh DIM*4 Array Entries per Dimension ;eg. [3][4] --> 00000003h,00000004h\n xxh 1 Internal Fake Name Length (LEN1) (0=none)\n xxh LEN1 Internal Fake Name (eg. \".1fake\")\n xxh 1 Symbol Name Length (LEN2)\n xxh LEN2 Symbol Name (eg. \"r\")\n(looks same/similar as C_xxx class values in COFF files!)
0001h = Local variable (with Offset = negative stack offset)\n 0002h = Global variable or Function (with Offset = address)\n 0008h = Item in Structure (with Offser = offset within struct)\n 0009h = Incoming Function param (with Offset = index; 0,4,8,etc.)\n 000Ah = Type address / struc start? (with Offset = zero)\n 000Dh = Type alias (with Offset = zero)\n(maybe lower 4bit=type, and next 4bit=usage/variant?) (looks same/similar as T_xxx type values in COFF files!)
0000h =\n 0001h =\n 0002h =\n 0003h = (16bit signed?)\n 0004h = int (32bit signed?)\n 0005h =\n 0006h =\n 0007h =\n 0008h = (address) (32bit unsigned?) (with Definition=000Ah)\n 0009h =\n 000Ah =\n 000Bh =\n 000Ch = u_char (8bit unsigned?)\n 000Dh = u_short,ushort (16bit unsigned?)\n 000Eh = u_int (32bit unsigned?)\n 000Fh = u_long (64bit unsigned?) (or rather SAME as above?)\n 0021h = function with 0 params, and/or return=\"nothing\"?\n 0024h = main function with 2 params, and/or return=\"int\"?\n 0052h = argv (string maybe?)\n 0038h = GsOT (huh?)\n 00F8h = GsOT_TAG (huh?)\n 00FCh = PACKET (huh?)\n ?? = float,bool,string,ptr,packet,(un-)signed8/16/32/64bit,etc\n ?? = custom type/struct (using value 000xh plus \"fake\" name, or so?)\nThe .SYM file is usually bundled with a .MAP file, which is containing a summary of the symbolic info as ASCII text (but without info on line numbers or data types). For example:
Start Stop Length Obj Group Section name\n 80010000 80012D5B 00002D5C 80010000 text .rdata\n 80012D5C 800C8417 000B56BC 80012D5C text .text\n 800C8418 800CDAB7 000056A0 800C8418 text .data\n 800CDAB8 800CFB63 000020AC 800CDAB8 text .sdata\n 800CFB64 800D5C07 000060A4 800CFB64 bss .sbss\n 800D5C08 800DD33F 00007738 800D5C08 bss .bss\n Address Names alphabetically\n 800CFE80 ACE_amount\n 800CFB94 AIMenu\n 800CDE5C AXIS_LENGTH\n 8005E28C AddClippedTri\n 8005DFEC AddVertex\n ...\n Address Names in address order\n 00000000 _cinemax_obj\n 00000000 _cinemax_header_org\n 00000000 _cinemax_org\n 00000000 _mcardx_sbss_size\n 00000000 _mcardx_org\n ...\nTIM/PXL/CLT are standard formats from Sony's devkit. TIM is used by many PSX games.
.TIM contains Pixel data, and (optional) CLUT data ;-all in one file\n .PXL contains Pixel data only ;\\in two separate files\n .CLT contains CLUT data only (if any) ;/\n 000h 1 File ID (always 10h=TIM)\n 001h 1 Version (always 00h)\n 002h 2 Reserved (always 0000h) (or 1 or 2 for Compressed TIM, see below)\n 004h 4 Flags (bit0-2=Type; see below, bit3=HasCLUT, bit4-31=Reserved/zero)\n ... .. Data Section for CLUT (Palette), only exists if Flags.bit3=1, HasCLUT\n ... .. Data Section for Pixels (Bitmap/Texture)\n 000h 4 Size of Data Section (Xsiz*2*Ysiz+0Ch) ;maybe rounded to 4-byte?\n 004h 4 Destination Coord (YyyyXxxxh) ;Xpos counted in halfwords\n 008h 4 Width+Height (YsizXsizh) ;Xsiz counted in halfwords\n 00Ch .. VRAM Data (to be DMAed to frame buffer)\nPXL/CLT is very rare. And oddly, with swapped ID values (official specs say 11h=PXL, 12h=CLT, but the existing games do use 11h=CLT, 12h=PXL). Used by Granstream Saga (MagDemo10 GS\\) Used by Bloody Roar 1 (MagDemo06: BL\\) Used by Bloody Roar 2 (MagDemo22: ASC,CMN,EFT,LON,SND,ST5,STU\\*)
"},{"location":"cdromfileformats/#clt-format","title":"CLT Format","text":" 000h 1 File ID (always 11h=CLT) (although Sony's doc says 12h)\n 001h 1 Version (always 00h)\n 002h 2 Reserved (always 0000h)\n 004h 4 Flags (bit0-1=Type=2; bit2-31=Reserved/zero)\n ... .. Data Section for CLUT (Palette)\n 000h 1 File ID (always 12h=PXL) (although Sony's doc says 11h)\n 001h 1 Version (always 00h)\n 002h 2 Reserved (always 0000h)\n 004h 4 Flags (bit0-?=Type; see below, bit?-31=Reserved/zero)\n ... .. Data Section for Pixels (Bitmap/Texture)\nApe Escape (Sony 1999) is using a customized TIM format with 4bpp compression: CDROM File Compression TIM-RLE4/RLE8 Other than that, TIMs can be compressed via generic compression functions (like LZSS, GZIP), or via bitmap dedicated compression formats (like BS, JPG, GIF).
"},{"location":"cdromfileformats/#malformed-files","title":"Malformed Files","text":""},{"location":"cdromfileformats/#malformed-tims-in-bigfiledat","title":"Malformed TIMs in BIGFILE.DAT","text":" Used by Legacy of Kain: Soul Reaver (eg. BIGFILE.DAT\\folder04h\\file13h)\n Used by Gex - Enter the Gecko (eg. BIGFILE.DAT\\file0Fh\\LZcompressed)\n 10 00 00 00 02 00 00 00 04 00 08 00 00 02 00 00 00 02 00 02 ;<-- this\n 10 00 00 00 02 00 00 00 04 00 08 00 00 00 00 00 00 02 00 02 ;<-- or this\n [04h]=Type should indicated the color depth, but it's always 02h=16bpp.\n [08h]=Width*2*Height+0Ch should be 8000Ch, but malformed is 80004h.\n Total filesize should be 80014h, but Gecko files are often MUCH smaller.\n Used by Pong (MagDemo24: LES02020\\*\\*.TIM)\n 10 00 00 00 02 00 00 00 0E 00 08 00 C0 01 00 00 00 02 00 02 ;Pong *.TIM\n 10 00 00 00 02 00 00 00 0E 00 07 00 00 02 00 00 C0 01 00 02 ;Pong WORLD.TIM\n 10 00 00 00 02 00 00 00 0E 80 03 00 00 02 00 01 C0 01 00 01 ;Pong ZONE*.TIM\nNBA Basketball 2000 (MagDemo28: FOXBB\\TIM\\*.TIM) has TIMs with section size \"0Ch+Xsiz*Ysiz\" instead of \"0Ch+Xsiz*2*Ysiz\".
"},{"location":"cdromfileformats/#nontims-in-bloody-roar-1-and-2","title":"NonTIMs in Bloody Roar 1 and 2","text":" Bloody Roar 1 (CMN\\INIT.DAT\\000Eh)\n Bloody Roar 2 (CMN\\SE00.DAT, CMD\\SEL00.DAT\\0030h and CMN\\VS\\VS.DAT\\0000h)\n 13 00 00 00 02 00 00 00 0C 20 00 00 00 00 F8 01 00 01 10 00 ;Bloody Roar 1\n 13 00 00 00 02 00 00 00 0C 20 00 00 00 00 00 00 00 01 10 00 ;Bloody Roar 2\nAnd, Heart of Darkness has a TIM with Size entry set to Xsiz*2*Ysiz+0Eh (instead of +0Ch) (that malformed TIM is found inside of the RNC compressed IMAGES\\US.TIM file). Also, NFL Gameday '99 (MagDemo17: GAMEDAY\\PHOTOS.FIL) contains a TIM cropped to 800h-byte size (containing only the upper quarter of the photo). Also, not directly malformed, but uncommon: Final Fantasy IX contains 14h-byte 0x0 pixel TIMs (eg. FF9.IMG\\dir04\\file0046\\1B-0000\\04-0001). Klonoa (MagDemo08: KLONOA\\FILE.IDX\\3\\2\\0..1) has 0x0pix TIM (plus palette).
"},{"location":"cdromfileformats/#malformed-clts","title":"Malformed CLTs","text":" Used by Secret of Mana, WM\\WEFF\\*.CLT\nApart from Sony's TIM (and PXL/CLT) format, there are a bunch of other texture/bitmap formats:
"},{"location":"cdromfileformats/#compressed-bitmaps","title":"Compressed Bitmaps","text":" .BS used by several games (and also in most .STR videos)\n .GIF used by Lightspan Online Connection CD\n .JPG used by Lightspan Online Connection CD\n .BMP with RLE4 used by Lightspan Online Connection CD (MONOFONT, PROPFONT)\n .BMP with RLE8+Delta also used by Online Connection CD (PROPFONT\\ARIA6.BMP)\n .PCX with RLE used by Jampack Vol. 1 (MDK\\CD.HED\\*.pcx)\n .BMP\n .BMP used by Mat Hoffman's Pro BMX (MagDemo39: BMX\\BMXCD.HED\\*)\n .BMP used by Mat Hoffman's Pro BMX (MagDemo48: MHPB\\BMXCD.HED\\*)\n .BMP used by Thrasher: Skate and Destroy (MagDemo27: SKATE\\ASSETS\\*.ZAL)\n .BMP used by Dave Mirra Freestyle BMX (MagDemo36,46: BMX\\ASSETS\\*.ZAL)\n .VRM .IMG .TEX .TIM .RAW .256 .COL .4B .15B .R16 .TPG - raw VRAM data\n \"SC\" memory card icons\nCDROM File Video Texture/Bitmap (TGA) CDROM File Video Texture/Bitmap (PCX)
"},{"location":"cdromfileformats/#psi-bitmap-power-spike-magdemo43-powergameidxbizpsi","title":"PSI bitmap - Power Spike (MagDemo43: POWER\\GAME.IDX\\.BIZ\\.PSI)","text":" 000h 10h Name 1 (\"FILENAME.BMP\", zeropadded)\n 010h 10h Name 2 (\"FILENAME.PSI\", zeropadded)\n 020h 4 Bits per pixel (usually 4, 8, or 16)\n 024h 2 Bitmap VRAM Dest.X ?\n 026h 2 Bitmap VRAM Dest.Y ?\n 028h 2 Bitmap Width in pixels\n 02Ah 2 Bitmap Height in pixels\n 02Ch 2 Palette VRAM Dest.X ? ;\\zero for 16bpp\n 02Eh 2 Palette VRAM Dest.Y ? ;/\n 030h 2 Bitmap Width in Halfwords (PixelWidth*bpp/16)\n 032h 2 Palette Size in Halfwords (0, 10h, 100h for 16bpp,4npp,8bpp)\n 034h 4 Maybe Bitmap present flag (always 1)\n 038h 4 Maybe Palette present flag (0=16bpp, 1=4bpp/8bpp)\n 03Ch .. Bitmap pixels\n ... .. Palette (if any, for 4bpp: 16x16bit, for 8bpp: 256x16bit)\nThis game does use two different (but nearly identical) bitmap formats (with either palette or bitmap data stored first).
000h 4 Total Filesize (Width*Height+20Ch)\n 004h 2 Bitmap Width\n 006h 2 Bitmap Height\n 008h 4 Unknown, always 1 (maybe 1=8bpp?)\n In .DAT files (512x192 or 256x64 pix), palette first:\n 00Ch 200h Palette data\n 20Ch .. Bitmap data\n In .PSX files (64x64 pix), bitmap first:\n 00Ch .. Bitmap data\n ... 200h Palette data\n Filename extension is \".DAT\"\n Bitmap Width<>Height (non-square)\n [00Ch..20Bh] has AllMSBs>=80h, and SomeLSBs<80h\nUsed by Alone in the Dark The New Nightmare (FAT.BIN\\BOOK,DOC,INTRO,MENU\\) Used by Rayman (RAY\\JUN,MON,MUS\\) (but seems to contain map data, not pixels)
000h 2 Width (W) ;\\usually 320x240 (or 512x240 or 80x13)\n 002h 2 Height (H) ;/\n 004h .. Bitmap 16bpp (W*H*2 bytes)\nUsed by Championship Motocross (MagDemo25: SMX\\RESHAD.BIN\\*) (\"RAWP\")
000h 4 ID \"RAWP\" (this variant has BIG-ENDIAN width/height!)\n 004h 2 Width (usually 280h=640pix or 140h=320pix) (big-endian!!!)\n 006h 2 Height (usually 1E0h=480pix or F0h=240pix) (big-endian!!!)\n 008h .. Bitmap data, 16bpp (width*height*2 bytes)\nUsed by CART World Series (MagDemo04: CART\\.BIT and *.BIN\\) Used by NFL Gameday '98 (MagDemo04: GAMEDAY\\BUILD\\GRBA.FIL\\) Used by NFL Gameday '99 (MagDemo17: GAMEDAY\\.BIT and *.FIL\\) Used by NFL Gameday 2000 (MagDemo27: GAMEDAY\\.BIT) Used by NCAA Gamebreaker '98 (MagDemo05: GBREAKER\\.BIT and UFLA.BIN\\) Used by NCAA Gamebreaker 2000 (MagDemo27: GBREAKER\\.BIT and *.FIL\\) Used by Twisted Metal 4 (MagDemo30: TM4DATA\\.MR,*.IMG\\.bit,*.clt)
000h 2 VRAM.X (X) (0..3FFh)\n 002h 2 VRAM.X (Y) (0..1FFh)\n 004h 2 Width in halfwords (W) (1..400h)\n 006h 2 Height (H) (1..200h)\n 008h .. Bitmap or Palette data (W*H*2 bytes)\n 000h 2 Hotspot X (signed) (usually 0)\n 002h 2 Hotspot Y (signed) (usually 0)\n 004h 2 Width in bytes\n 006h 2 Height\n 008h .. Bitmap 8bpp (Width*Height bytes)\n 000h 2 Width\n 002h 2 Height\n 004h 100h*3 Palette 24bit RGB888\n 304h .. Bitmap 8bpp (Width*Height bytes)\n .. (1700h) Unknown (only in SMLMAPS\\*.BOB, not in GFX\\*.BOB)\n 000h 4 Format 1 (0=8bpp, 1=16bpp)\n 004h 4 Format 2 (1=8bpp, 2=16bpp)\n 008h 4 Width in pixels\n 00Ch 4 Height in pixels\n 010h .. Bitmap Data\n ... (300h) Palette 18bit RGB666 (R,G,B range 00h..3Fh) (only if format 8bpp)\n 000h 4 Unknown (always 1)\n 004h 4 Unknown (always 8)\n 008h 4 Unknown (always 2) (maybe 2=16bpp?)\n 00Ch 4 Width in pixels (3Ah, 140h, or 280h)\n 010h 4 Height (3Ah, or F0h)\n 014h .. Bitmap 16bpp (Width*Height*2 bytes)\n 000h 2 Number if Files (N)\n 002h 2 Number of VRAM.Slots (less or equal than Number of Files)\n 004h 4 ID \"BLK0\"\n 008h N*10h File List\n ... .. 1st File Bitmap\n ... .. 1st File Palette (20h/200h/0 bytes for 4bpp/8bpp/16bpp)\n ... .. 2nd File Bitmap\n ... .. 2nd File Palette (only if PaletteID=FileNo=1)\n ... .. 3rd File Bitmap\n ... .. 3rd File Palette (only if PaletteID=FileNo=2)\n ... .. etc.\n 000h 2 VRAM.X in halfwords (0..1Fh, +bit15=Blank) ;\\within current\n 002h 2 VRAM.Y (0..3Fh) ;/VRAM.Slot\n 004h 2 Width in pixels (max 80h/40h/20h for 4bpp/8bpp/16bpp)\n 006h 2 Height (max 40h)\n 008h 2 VRAM.Slot (0,1,2,3,...,NumSlots-1)\n 00Ah 2 Unknown (0,1,2,4 in *.vck, 4 in sect*.bin)\n 00Ch 2 Color Depth (0=4bpp, 1=8bpp, 2=16bpp)\n 00Eh 2 Palette ID (0..FileNo-1=Old, FileNo=New, FFFFh=None/16bpp)\n NumFiles-1, or ID of already used palette)\nThese are 16bpp bitmaps, stored either in uncompressed .BMR files, or in compressed .RLE files: CDROM File Compression RLE_16
Apocalypse (MagDemo16: APOC\\CD.HED\\*.RLE and *.BMR)\n Spider-Man 1 older version (MagDemo31: SPIDEY\\CD.HED\\*.RLE)\n Spider-Man 1 newer version (MagDemo40: SPIDEY\\CD.HED\\*.RLE and .BMR)\n Spider-Man 2 (MagDemo50: HARNESS\\CD.HED\\*.RLE)\n Tony Hawk's Pro Skater (MagDemo22: PROSKATE\\CD.HED\\*.BMR)\n 33408h bytes --> 512x205pix, 16bpp (Apocalypse warning.rle)\n 3C008h bytes --> 512x240pix, 16bpp (most common)\n 96008h bytes --> 640x480pix, 16bpp (tony hawk's pro skater)\n 000h 2 Unknown (FFA0h) (ID for files with valid headers?)\n 002h 2 Dest.Y (usually 0) (11h=(240-205)/2 in Apocalypse warning.rle)\n 004h 2 Width (usually 200h=512pix)\n 006h 2 Height (usually F0h=240pix) (CDh=205pix in Apocalypse warning.rle)\n 008h .. Bitmap data, 16bpp (width*height*2 bytes)\n 000h .. Bitmap data, 16bpp (width*height*2 bytes)\n .. 8 Unused (garbage or extra pixels, not transferred to VRAM)\nContains raw 16bpp bitmaps, with following sizes:
25800h bytes = 12C00h pixels (320x240) ;Croc 1 (retail version)\n 3C000h bytes = 1E000h pixels (512x240)\n 96000h bytes = 4B000h pixels (640x480)\n 000h 2 Bits per pixel (4 or 8)\n 002h 2 Bitmap Width in pixels\n 004h 2 Bitmap Height in pixels\n 006h 2 Zero\n 008h N*2 Palette (with N=(1 SHL bpp))\n ... .. Bitmap (with Width*Height*bpp/8 bytes)\n ... (..) Zeropadding to 4-byte boundary (old version only)\n 000h 2 Type (0=4bpp, 1=8bpp, 2=16bpp)\n 002h 2 Unknown (usually 0000h, or sometimes CCCCh)\n 004h 2 Bitmap Width in pixels\n 006h 2 Bitmap Height in pixels\n 008h 200h Palette (always 200h-byte, even for 4bpp or 16bpp)\n 208h .. Bitmap (Width*Height*bpp/8 bytes)\nThis format is used in various EA Sports Madden .DAT archives, it contains standard TIMs with extra Headers/Footers.
000h 4 Offset to TIM (1Ch) (Hdr size) (1Ch) ;\\\n 004h 4 Offset to Footer (Hdr+TIM size)(123Ch,1A3Ch,1830h) ;\n 008h 2 Bitmap Width in pixels (40h or 60h or 30h) ;\n 00Ah 2 Bitmap Height in pixels (40h) ;\n 00Ch 4 Unknown, always 01h (01h) ; Header\n 010h 4 Unknown, always 23h (23h) ; 1Ch bytes\n 014h 2 Unknown, always 0101h (101h) ;\n 016h 1 Bitmap Width in pixels (40h or 60h or 30h) ;\n 017h 1 Bitmap Height in pixels (40h) ;\n 018h 4 Unknown, always 00h (0) ;/\n 01Ch .. TIM (Texture, can be 4bpp, 8bpp, 16bpp) ;-TIM\n ... 4 Unknown, always C0000222h (C0000222h) ;\\\n ... 2 Unknown, always 0001h (0001h) ;\n ... 1 Bitmap Width in pixels (40h or 60h or 30h) ; Footer\n ... 1 Bitmap Height in pixels (40h) ; 12h bytes\n ... 4 Unknown, always 78000000h (78000000h) ;\n ... 6 Unknown (0,0,80h,0,0,0) ;/\n Madden NFL '98 (MagDemo02: TIBURON\\PORTRAIT.DAT) (48x64, 16bpp)\n Madden NFL 2000 (MagDemo27: MADN00\\PORTRAIT.DAT) (96x64, 8bpp plus palette)\n Madden NFL 2001 (MagDemo39: MADN01\\PORTRAIT.DAT) (64x64, 8bpp plus palette)\n 000h 0Ch ID \"TEX PSX \",01h,00h,00h,00h ;used in 989 Sports games\n 00Ch 4 Number of Textures\n 010h 4 Total Filesize\n 014h 4 Common Palette Size (0=200h, 1=None, 2=20h)\n 018h (..) Common Palette, if any (0,20h,200h bytes)\n ... .. Texture(s)\n Texture format:\n 000h 10h Filename (eg. \"light1\", max 16 chars, zeropadded if shorter)\n 010h 4 Width in pixels (eg. 40h)\n 014h 4 Height (eg. 20h or 40h)\n 018h 4 Unknown (always 0)\n 01Ch 4 Number of Colors (eg. 10h, 20h or 100h)\n 020h .. Bitmap (4bpp when NumColors<=10h, 8bpp when NumColors>10h)\n ... (..) Palette (NumColors*2 bytes, only present if Common Palette=None)\nFIFA - Road to World Cup 98 (with chunk C0h/C1h = RefPack compression) NCAA March Madness 2000 (MagDemo32: MM2K\\.PSH) Need for Speed 3 Hot Pursuit (*.PSH, ZLOAD*.QPS\\RefPack.PSH) ReBoot (DATA\\.PSH) (with chunk 6Bh) Sled Storm (MagDemo24: DEBUG,ART,ART2,ART3,SOUND\\.PSH) (with Comment, Mipmap) WCW Mayhem (MagDemo28: WCWDEMO\\.BIG\\*.PSH) (with chunk C0h/C1h = RefPack)
000h 4 ID \"SHPP\"\n 004h 4 Total Filesize (or Filesize-0Ch, eg. FIFA'98 ZLEG*.PSH)\n 008h 4 Number of Textures (N)\n 00Ch 4 ID \"GIMX\"\n 010h N*8 File List\n ... .. Data (each File contains a Bitmap chunk, and Palette chunk, if any)\n File List entries:\n 000h 4 Name (ascii) (Mipmaps use the same name for each mipmap level)\n 004h 4 Offset from begin of archive to first Chunk of file\n Caution: Most PSH files do have the above offsets sorted in increasing order,\n but some have UNSORTED offsets, eg. Sled Storm (MagDemo24: ART3\\LOAD1.PSH),\n so one cannot easily compute sizes as NextOffset-CurrOffset.\n Note: Mipmap textures consist of two files with same name and different\n resolution, eg. in Sled Storm (MagDemo24: ART\\WORLD0x.PSH)\n Bitmap Chunk:\n 000h 1 Chunk Type (40h=PSX/4bpp, 41h=PSX/8bpp, 42h=PSX/16bpp)\n 001h 3 Offset from current chunk to next chunk (000000h=None)\n 004h 2 Bitmap Width in pixels (can be odd, pad lines to 2-byte boundary)\n 006h 2 Bitmap Height\n 008h 2 Center X (whatever that is)\n 00Ah 2 Center Y (whatever that is)\n 00Ch 2 Position X (whatever that is, plus bit12-15=flags?)\n 00Eh 2 Position Y (whatever that is, plus bit12-15=flags?)\n 010h .. Bitmap data (each scanline is padded to 2-byte boundary)\n ... .. Padding to 8-byte boundary\n Compressed Bitmap Chunk:\n 000h 1 Chunk Type (C0h=PSX/4bpp, C1h=PSX/8bpp, and probably C2h=PSX/16bpp)\n 001h 0Fh Same as in Chunk 40h/41h/42h (see there)\n 010h .. Compressed Bitmap data (usually/always with Method=10FBh)\n ... .. Padding to 8-byte boundary\n Palette Chunk (if any) (only for 4bpp/8bpp bitmaps, not for 16bpp):\n 000h 1 Chunk Type (23h=PSX/Palette)\n 001h 3 Offset from current chunk to next chunk (000000h=None)\n 004h 2 Palette Width in halfwords (10h or 100h)\n 006h 2 Palette Height (1)\n 008h 2 Unknown (usually same as Width) (or 80D0h or 9240h)\n 00Ah 2 Unknown (usually 0000h) (or 0001h or 0002h)\n 00Ch 2 Unknown (usually 0000h)\n 00Eh 2 Unknown (usually 00F0h)\n 010h .. Palette data (16bit per color)\n Note: The odd 80D0h,0001h values occur in Sled Storm ART\\WORKD00.PSH\\TBR1)\n Unknown Chunk (eg. ReBoot (DATA\\AREA15.PSH\\sp*))\n 000h 1 Chunk Type (6Bh)\n 001h 3 Offset from current chunk to next chunk (000000h=None)\n 004h 8 Unknown (2C,00,00,3C,03,00,00,00)\n 00Ch - For whatever reason, there is no 8-byte padding here\n Comment Chunk (eg. Sled Storm (MagDemo24: ART\\WORLD0x.PSH))\n 000h 1 Chunk Type (6Fh=PSX/Comment)\n 001h 3 Offset from current chunk to next chunk (000000h=None)\n 004h .. Comment (\"Saved in Photoshop Plugin made by PEE00751@...\",00h)\n ... .. Zeropadding to 8-byte boundary\n Unknown Chunk (eg. Sled Storm (MagDemo24: ART\\WORLD09.PSH\\ADAA))\n 000h 1 Chunk Type (7Ch)\n 001h 3 Offset from current chunk to next chunk (000000h=None)\n 004h 2Ch Unknown (reportedly Hot spot / Pix region, but differs on PSX?)\nThis format can contain one single Bitmap, or a font with several small character bitmaps.
000h 2 ID \"BC\" ;\\\n 002h 1 Color Depth (1=4bpp, 2=8bpp, 4=16bpp) ; Header\n 003h 1 Type (40h=Bitmap, C0h=Font) ;/\n ... (2) Palette Unknown (0 or 1) ;\\only if Bitmap\n ... (2) Palette Unknown (1) ; 4bpp or 8bpp\n ... (..) Palette data (20h or 200h bytes for 4bpp/8bpp) ;/\n ... 2 Bitmap Number of Bitmaps-1 (N-1) ;\\\n ... 2 Bitmap Width in pixels ;\n ... 2 Bitmap Height in pixels ; Bitmap(s)\n ... N*1 Bitmap Tilenumbers (eg. \"ABCDEFG...\" for Fonts);\n ... N*1 Bitmap Proportional Font widths? (0xh or FFh) ;\n ... N*BMP Bitmap(s) for all characters ;/\n ... (20h) Palette Data (20h bytes for 4bpp) ;-only if Font/4bpp\n INGAME1\\BOWL2.PTH\\SPRITES.PTH\\ST.SPR 30x10x4bpp: 15 --> 16 bytes/line\n INGAME1\\BOWL2.PTH\\SPRITES.PTH\\STOPW.SPR 75x40x4bpp: 37.5 --> 38 bytes/line\n 000h 2 ID (\"FB\") ;\\File Header\n 002h 2 Always 1 (version? 4bpp? num entries?) ;/\n 004h 2 Palette VRAM Dest X (eg. 300h) ;\\\n 006h 2 Palette VRAM Dest Y (eg. 1CCh,1EDh,1FFh) ; Palette Header\n 008h 2 Palette Width in halfwords (eg. 100h) ; (all zero when unused)\n 00Ah 2 Palette Height (eg. 1 or 0Dh) ;/\n 00Ch 2 Bitmap VRAM Dest X (eg. 140h or 200h) ;\\\n 00Eh 2 Bitmap VRAM Dest Y (eg. 0 or 100h) ; Bitmap Header\n 010h 2 Bitmap Width in halfwords ;\n 012h 2 Bitmap Height ;/\n ... .. Palette Data (if any) ;-Palette Data\n ... .. Bitmap Data ;-Bitmap Data\n 000h 1 Image ID Size (00h..FFh, usually 0=None) ;0\n 001h 1 Palette Present Flag (0=None, 1=Present) ;0 iv=1\n 002h 1 Data Type code (0,1,2,3,9,10,11,32,33) ;NEBULA=2 iv=1\n 003h 2 Palette First Color (usually 0) ;0 iv=0\n 005h 2 Palette Number of Colors (usually 100h) ;0 iv=100h\n 007h 1 Palette Bits per Color (16,24,32, usually 24) ;0 iv=18h\n 008h 2 Bitmap X origin (usually 0) ;0\n 00Ah 2 Bitmap Y origin (usually 0) ;0\n 00Ch 2 Bitmap Width ;NEBULA=20h LOGO=142h\n 00Eh 2 Bitmap Height ;NEBULA=20h\n 010h 1 Bitmap Bits per Pixel (8,16,24,32 exist?) ;NEBULA=18h iv=8\n 011h 1 Image Descriptor (usually 0) ;0\n 012h .. Image ID Data (if any, len=[00h], usually 0=None)\n ... .. Palette\n ... .. Bitmap\n ... 1Ah Footer (8x00h, \"TRUEVISION-XFILE.\", 00h) (not present in iview)\n 00h = No image data included ;-Unknown purpose\n 01h = Color-mapped image ;\\\n 02h = RGB image ; Uncompressed\n 03h = Black and white image ;/\n 09h = Color-mapped image ;\\Runlength\n 0Ah = RGB image ;/\n 0Bh = Black and white image ;-Unknown compression method\n 20h = Color-mapped image ;-Huffman+Delta+Runlength\n 21h = Color-mapped image ;-Huffman+Delta+Runlength+FourPassQuadTree\n Type 01h and 09h lack details on supported bits per pixel (8bpp with 100h\n colors does exist; unknown if less (or more) than 8bpp are supported,\n and if so, in which bit order.\n Type 02h and 0Ah are more or less well documented.\n Type 03h has unknown bit-order, also unknown if/how it differs from type\n 01h with 1bpp.\n Type 0Bh, 20h, 21h lack any details on the compression method.\n 16bpp: Tomb Raider 2 (MagDemo01: TOMBRAID\\*.RAW)\n 24bpp: Tomb Raider 2 (MagDemo05: TOMB2\\*.TGA)\n 24bpp: Colony Wars Venegance (MagDemo14: CWV\\GAME.RSC\\NEBULA*.TGA, *SKY.TGA)\n 24bpp: Colony Wars Red Sun (MagDemo31: CWREDSUN\\GAME.RSC\\000A\\*)\n 16bpp: Colony Wars Venegance (MagDemo14: CWV\\GAME.RSC\\LOGO.DAT)\n 16bpp: X-Men: Mutant Academy (MagDemo50: XMEN2\\*)\n 16bpp: Disney's Tarzan (MagDemo42: TARZAN\\*)\n 8bpp+Wrong8bitAttr: SnoCross Championship Racing (MagDemo37: SNOCROSS\\*.TGA)\n 16bpp+WrongYflip: SnoCross Championship Racing (MagDemo37: SNOCROSS\\*.TGA)\n 32bpp: 3DS AR Games (RomFS:\\i_ar\\tex\\hm*.lz77\nDefault extension is .PCX (some tools did use .PCX for the \"main\" image, and .PCC for smaller snippets that were clipped/cropped/copied from from a large image).
000h 1 File ID (always 0Ah=PCX/ZSoft)\n 001h 1 Version (0,2,3,4,5)\n 002h 1 Compression (always 01h=RLE) (or inofficial: 00h=Uncompressed)\n 003h 1 Bits per Pixel (per Plane) (1, 2, 4, or 8)\n 004h 2 Window X1 ;\\\n 006h 2 Window Y1 ; Width = X2+1-X1\n 008h 2 Window X2 ; Height = Y2+1-Y1\n 00Ah 2 Window Y2 ;/\n 00Ch 2 Horizontal Resolution in DPI ;\\often square, but can be also zero,\n 00Eh 2 Vertical Resolution in DPI ;/or screen size, or other values\n 010h 30h EGA/VGA Palette (16 colors, 3-byte per color = R,G,B) (or garbage)\n 010h 1 CGA: Bit7-4=Background Color (supposedly IRGB1111 ?)\n 013h 1 CGA: Bit7:0=Color,1=Mono,Bit6:0=Yellow,1=White,Bit5:0=Dim,1=Bright\n 014h 1 Paintbrush IV: New CGA Color1 Green ;\\weird new way to encode CGA\n 015h 1 Paintbrush IV: New CGA Color1 Red ;/palette in these two bytes\n 040h 1 Reserved (00h) (but is 96h in animals.pcx)\n 041h 1 Number of color planes (1=Palette, 3=RGB, or 4=RGBI)\n 042h 2 Bytes per Line (per plane) (must be N*2) (=(Width*Bits+15)/16*2)\n 044h 2 PaletteInfo? (0000h/xxxxh=Normal, 0001h=Color/BW, 0002h=Grayscale)\n 046h 2 Horizontal screen size in pixels ;\\New fields, found only\n 048h 2 Vertical screen size in pixels ;/in Paintbrush IV/IV Plus\n 04Ah 36h Reserved (zerofilled) (or garbage in older files, custom in MGS)\n 080h .. Bitmap data (RLE compressed)\n ... 1 VGA Palette ID (0Ch=256 colors) ;\\when 8bpp\n .. 300h VGA Palette (256 colors, 3-byte per color = R,G,B) ;/\n 00h = Version 2.5 whatever ancient stuff\n 02h = Version 2.8 with custom 16-color palette\n 03h = Version 2.8 without palette (uses fixed CGA/EGA palette)\n 04h = Version ?.? without palette (uses fixed CGA/EGA palette)\n 05h = Version 3.0 with custom 16-color or 256-color palette or truecolor\n planes=1, bits=1 P1 ;1bit, HGC 2 color (iview and paint shop pro 2)\n planes=1, bits=2 P2 ;2bit, CGA 4 color (with old/new palette info)\n planes=3, bits=1 RGB111 ;3bit, EGA 8 color (official samples) ;\\version\n planes=4, bits=1 IRGB1111 ;4bit, EGA 16 color (paint shop pro 2) ;/03h..04h\n planes=1, bits=4 P4 ;4bit, BMP 16 color (iview)\n planes=1, bits=8 P8 ;8bit, VGA 256 color palette\n planes=1, bits=8 I8 ;8bit, VGA 256 level grayscale (gmarbles.pcx)\n planes=3, bits=8 BGR888 ;24bit, truecolor (this is official 24bit format)\n ;planes=1, bits=24 BGR888 ? ;24bit, reportedly exists? poor compression\n ;planes=4, bits=4 ABGR4444 ;16bit, wikipedia-myth? unlikely to exist\n ;planes=4, bits=8 ABGR8888 ;32bit, truecolor+alpha (used in abydos.dcx\\*)\nThese are normally calculated as so:
Width = X2+1-X1 ;width for normal files\n Height = Y2+1-Y1 ;height for normal files\n Width = X2-X1 ;width for bugged files\n Height = Y2-Y1 ;height for bugged files\n (Width*Bits+15)/16*2) > BytesPerLine\n BeginOfLastScanline >= Filesize (or Filesize-301h for files with palette)\nThe official ZSoft PCX specs are - wrongly - describing planes as:
plane0 = red ;\\\n plane1 = green ; this is WRONG, NONSENSE, does NOT exist\n plane2 = blue ;\n plane3 = intensity ;/\nThis format was intended for 640x200pix 2-color CGA graphics, it's also common for higher resolution FAX or print images. The general rule for these files is to use this colors:
color0=black\n color1=white\nThis format was intended for 320x200pix 4-color CGA graphics, and the palette is closely bound to colors available in CGA graphics modes. Color0 is defined in [10h], and Color1-3 were originally defined in [13h], and later in
color0=[10h].bit7-4 ;(Color0 IRGB) ;CGA Port 3D9h.bit3-0 (usually 0=black)\n bright=[13h].bit5 ;CGA Port 3D9h.bit4 ;\\\n palette=[13h].bit6 ;CGA Port 3D9h.bit5 ; old method\n if [13h].bit7 then palette=2 ;CGA Port 3D8h.bit2 ;/\n if [01h]=05h and [44h]=0001h then ;\\new \"smart\"\n if [14h]>200 or [15h]>200 then bright=1, else bright=0 ; method used in\n if [14h]>[15h] then palette=0 else palette=1 :/Paintbrush IV\n if palette=0 and bright=0 then color1..3=02h,04h,06h ;\\green-red-yellow\n if palette=0 and bright=1 then color1..3=0Ah,0Ch,0Eh ;/\n if palette=1 and bright=0 then color1..3=03h,05h,07h ;\\cyan-magenta-white\n if palette=1 and bright=1 then color1..3=0Bh,0Dh,0Fh ;/\n if palette=2 and bright=0 then color1..3=03h,04h,07h ;\\cyan-red-white\n if palette=2 and bright=1 then color1..3=0Bh,0Ch,0Fh ;/\nThese images have 3 or 4 planes. Plane0-3 correspond to bit0-3 of the EGA color numbers (ie. blue=plane0, green=plane1, red=plane2, and either intensity=plane3 for 16-color, or intensity=0 for 8-color images). Some 8-Color sample images (with version=03h and 04h) can be found bundled with PC Paintbrush Plus 1.22 for Windows. A 16-color sample called WINSCR.PCX can be found elsewhere in internet. Caution 1: Official ZSoft specs are wrongly claiming plane0=red and plane2=blue; this is wrong (although Paint Shop Pro 2 is actually implementing it that way) (whilst MS Paint for Win95b can properly display them) (most other tools are trying to read a palette from [10h..3Fh], which is usually garbage filled in version=03h..04h). Caution 2: The standard EGA palette is used for version=03h..04h (many docs claim it to be used for version=03h only).
"},{"location":"cdromfileformats/#16-color-with-custom-egavga-palettes-version02h-or-05h","title":"16-Color, with custom EGA/VGA Palettes (version=02h or 05h)","text":"These can have 1 plane with 4 bits, or 4 planes with 1 bit. Header[10h..3Fh] contains a custom 16-color RGB palette with 3x8bit per R,G,B. Classic VGA hardware did only use the upper 6bit of the 8bit values. Classic EGA hardware did only use the upper 2bit of the 8bit values (that, only when having a special EGA monitor with support for more than 16 colors).
"},{"location":"cdromfileformats/#256-color-vga-palettes-version05h","title":"256-Color VGA Palettes (version=05h)","text":"These have 1 plane with 8 bits. And a 256-color RGB palette with 3x8bit per R,G,B appended at end of file. The appended 256-color palette should normally exist only in 256-color images, some PCX tools are reportedly always appending the extra palette to all version=05h files (even for 2-color files).
"},{"location":"cdromfileformats/#256-level-grayscale-images-version05h-and-44h0002h","title":"256-Level Grayscale Images (version=05h and [44h]=0002h)","text":"The most obvious and reliable way is to use a palette with grayscale RGB values. However, Paintbrush IV is explicetly implementing (or ignoring?) an obscure grayscale format with following settings:
[01h]=version=05h, and [44h]=0002h=grayscale\n Color Name IRGB1111 RGB222 RGB888 Windows\n 00h dark black 0000 000 000000 000000\n 01h dark blue 0001 002 0000AA 000080\n 02h dark green 0010 020 00AA00 008000\n 03h dark cyan 0011 022 00AAAA 008080\n 04h dark red 0100 200 AA0000 800000\n 05h dark magenta 0101 202 AA00AA 800080\n 06h dark yellow (brown) 0110 210!! AA5500!! 808000\n 07h dark white (light gray) 0111 222 AAAAAA C0C0C0!!\n 08h bright black (dark gray) 1000 111 555555 808080!!\n 09h bright blue 1001 113 5555FF 0000FF\n 0Ah bright green 1010 131 55FF55 00FF00\n 0Bh bright cyan 1011 133 55FFFF 00FFFF\n 0Ch bright red 1100 311 FF5555 FF0000\n 0Dh bright magenta 1101 313 FF55FF FF00FF\n 0Eh bright yellow 1110 331 FFFF55 FFFF00\n 0Fh bright white 1111 333 FFFFFF FFFFFF\n CGA supports 16 colors in text mode (but only max 4 colors in graphics mode).\n EGA supports the same 16 colors as CGA in both text and graphics mode.\n EGA-with-special-EGA-monitor supports 64 colors (but only max 16 at once).\n VGA supports much colors (but can mimmick CGA/EGA colors, or similar colors)\n .PCX with RLE used by Jampack Vol. 1 (MDK\\CD.HED\\*.pcx)\n .PCX with RLE used by Hot Wheels Extreme Racing (MagDemo52: US_01293\\MISC\\*)\n .PCX with RLE used by Metal Gear Solid (slightly corrupted PCX files)\nMGS is storing some extra data at [4Ah..57h] (roughly resembling the info in TIM files).
04Ah 2 Custom MGS ID (always 3039h)\n 04Ch 2 Display Mode? (08h/18h=4bit, 09h/19h=8bit)\n 04Eh 2 Bitmap X-coordinate in VRAM (reportedly \"divided by 2\" ???)\n 050h 2 Bitmap Y-coordinate in VRAM\n 052h 2 Palette X-coordinate in VRAM\n 054h 2 Palette Y-coordinate in VRAM\n 056h 2 Palette number of actually used colors (can be less than 16/256)\n 058h 28h Reserved (zerofilled)\n 080h .. Bitmap data (RLE compressed)\n ... 1 VGA Palette ID (0Ch=256 colors) ;\\when 8bpp\n .. 300h VGA Palette (256 colors, 3-byte per color = R,G,B) ;/\n .. .. Padding to 4-byte boundary, ie. palette isn't at filesize-301h !!!\nDCX archives contain multiple PCX files (eg. multi-page FAX documents). The standard format is as so:
0000h 4 ID (3ADE68B1h) (987654321 decimal)\n 0004h 4000h File List (32bit offsets) (max 1023 files, plus 0=End of List)\n 1004h .. File Data area (PCX files)\nhttps://www.fileformat.info/format/pcx/egff.htm
"},{"location":"cdromfileformats/#cdrom-file-video-2d-graphics-celbgdtsqanmsdf-sony","title":"CDROM File Video 2D Graphics CEL/BGD/TSQ/ANM/SDF (Sony)","text":"CEL/BGD/TSQ/ANM/SDF
"},{"location":"cdromfileformats/#cel-cell-data-official-format-with-8bit-header-entries","title":"CEL: Cell Data (official format with 8bit header entries)","text":"This does merely translate Tile Numbers to VRAM Addresses and Attributes (with the actual VRAM bitmap data usually being stored in .TIM files).
000h 1 File ID (22h)\n 001h 1 Version (3)\n 002h 2 Flag (bit15=WithAttr, bit14=AttrDataSize:0=8bit,1=16bit, bit13-0=0)\n 004h 2 Number of cell data items (in cell units) (N)\n 006h 1 Sprite Editor Display Window Width (in cell units)\n 007h 1 Sprite Editor Display Window Height (in cell units)\n 008h .. Cell Data[N] (64bit entries)\n ... .. Cell Attr[N] (0bit/8bit/16bit user data? depending on Flag)\n 0-7 Tex Coord X (8bit)\n 8-15 Tex Coord Y (8bit)\n 16-21 Clut X (6bit)\n 22-30 Clut X (9bit)\n 31 Semi-transparency enable ;-only in Version>=3\n 32 Vertical Reversal (Y-Flip) ;\\only in Version=0 and Version>=2\n 33 Horizontal Reversal (X-Flip) ;/\n 34-47 Unused\n 48-52 Texture Page (5bit)\n 53-54 Semi Transparency (0=B/2+F/2, 1=B+F, 2=B-F, 3=B+F/4)\n 55-56 Texture page colors (0=4bit, 1=8bit, 2=15bit, 3=Reserved)\n 57-60 Sprite Editor Color Set Number ;\\\n 61 Unused ; only in Version>=3\n 62-63 Sprite Editor TIM Bank ;/ XXX else hardcoded?\nThis is an inofficial hack used by R-Types, the game does use both the official CEL and inofficial CEL16 format.
000h 1 File ID (22h) ;\\same as in official CEL version\n 001h 1 Version (3) ;/\n 002h 2 Flag (...unknown meaning in this case...?) ;<-- ?\n 004h 2 Number of cell data items (in cell units) (N)\n 006h 2 Sprite Editor Display Window Width (in cell units) ;<-- 16bit!\n 008h 2 Sprite Editor Display Window Height (in cell units) ;<-- 16bit!\n 00Ah .. Cell Data[N] (64bit entries)\n ... .. Cell Attr[N] (16bit/192bit user data, depending on Flag or so...?)\n 000h 1 File ID (23h)\n 001h 1 Version (0)\n 002h 2 Flag (bit15=WithAttr, bit14=AttrDataSize:0=8bit,1=16bit, bit13-0=0)\n 004h 1 BG Map Width (in cell units) (W)\n 005h 1 BG Map Height (in cell units) (H)\n 006h 1 Cell Width (in pixels)\n 007h 1 Cell Height (in pixels)\n 008h .. BG Map Data[W*H] (16bit cell numbers)\n ... .. BG Map Attr[W*H] (0bit/8bit/16bit user data? depending on Flag)\nThis is an inofficial hack used by R-Types, the game does use both the official BGD and inofficial BGD16 format. Apparently invented to support bigger BG Map Widths for huge sidescrolling game maps.
000h 1 File ID (23h) ;\\same as in official BGD version\n 001h 1 Version (0) ;/\n 002h 2 Flag (bit15=WithAttr, bit14=AttrDataSize:0=8bit,1=16bit, bit13-0=0)\n 004h 2 BG Map Width (in cell units) (W) ;<-- 16bit!\n 006h 2 BG Map Height (in cell units) (H) ;<-- 16bit!\n 008h 2 Cell Width (in pixels) ;<-- 16bit!\n 00Ah 2 Cell Height (in pixels) ;<-- 16bit!\n 00Ch .. BG Map Data[W*H] (16bit cell numbers)\n ... .. BG Map Attr[W*H] (0bit/8bit/16bit user data? depending on Flag)\n ... .. FFh-padding (in case being stored in R-Types' DOT1 archives)\n 000h 1 File ID (24h)\n 001h 1 Version (1)\n 002h 2 Number of Sequence data entries (N)\n 004h N*8 Sequence Data (64bit entries)\n 0-15 Sprite Group Number to be displayed\n 16-23 Display Time\n 24-27 Unused\n 28-31 Attribute (user defined) (only in Version>=1)\n 32-47 Hotspot X Coordinate\n 48-63 Hotspot Y Coordinate\n 000h 1 File ID (21h)\n 001h 1 Version (3=normal) (but see below notes on older versions)\n 002h 2 Flag (bit0-1=TPF, bit2-11=0, bit12-15=CLT)\n 0-1 TPF PixFmt (0=4bpp, 1=8bpp, 2/3=Reserved) ;version>=2 only\n 2-11 - Reserved (0)\n 12-15 CLT Number of CLUT Groups, for color animation\n 004h 2 Number of Sprites Groups\n 006h 2 Number of Sequences (N) (can be 0=None)\n 008h N*8 Sequence(s) (64bit per entry) ;Num=[004h]\n ... .. Sprite Group(s) ;Num=[006h]\n ... .. CLUT Group(s) ;Num=[002h].bit12-15\n 000h 2 Sprite Group Number to be displayed (range 0..AnimHdr[004h]-1)\n 002h 1 Display Time (can be 00h or 0Ah or whatever)\n 003h 1 Attribute (bit0-3=Unused/Zero, bit4-7=User defined) ;version>=3 only\n 004h 2 Hotspot X Coordinate (usually 0, or maybe can be +/-NN ?)\n 006h 2 Hotspot Y Coordinate (usually 0, or maybe can be +/-NN ?)\n Each \"Group\" seems to represent one animation frame.\n Each \"Group\" can contain one or more sprites (aka metatiles).\n Below stuff is \"4+N*14h\" bytes, that seems to repeat \"AnmHeader[004h] times\"\n XXX... actually below can be \"4+N*10h\" or \"4+N*14h\" bytes\n XXX... so, maybe maybe some entries like width/height are optional?\n 000h 4 Number of Sprites in this Sprite Group (\"sprites per metatile\"?)\n 004h 14h*N Sprite(s) (see below)\n Sprites:\n 000h 1 Tex Coord X (8bit)\n 001h 1 Tex Coord Y (8bit)\n 002h 1 Offset X from Hotspot within frame (maybe vertex x ?)\n 003h 1 Offset Y from Hotspot within frame (maybe vertex y ?)\n 004h 2 CBA Clut Base (bit0-5=ClutX, Bit6-14=ClutY, bit15=SemiTransp)\n 006h 2 FLAGs (bit0-4, bit5-6, bit7-8, bit9, bit10, bit11, bit12-15)\n 0-4 TPN Texture Page Number\n 5-6 ABR Semi-Transparency Rate\n 7-8 TPF Pixel depth (0=4bpp, 1=8bpp, 2=16bpp)\n 9 - Reserved\n 10 RSZ Scaling (0=No, 1=Scaled)\n 11 ROT Rotation (0=No, 1=Rotated)\n 12-15 THW Texture Width/Height div8 (0=Other custom width/height)\n 008h (2) Texture Width \"of optional size\" (uh?) ;\\only present if\n 00Ah (2) Texture Height \"of optional size\" (uh?) ;/FLAGs.bit12-15=0 ?)\n 00Ch 2 Angle of Rotation (in what units?)\n 00Eh 2 Sprite Editor info (bit0-7=Zero, bit8-13=ClutNo, bit14-15=TimBank)\n 010h 2 Scaling X (for Vertex?) (as whatever fixed point number) (eg. 1000h)\n 012h 2 Scaling Y (for Vertex?) (as whatever fixed point number) (eg. 1000h)\n 000h 4 CLUT size in bytes (Width*Height*2+0Ch)\n 004h 2 Clut X Coordinate\n 006h 2 Clut Y Coordinate\n 008h 2 Clut Width\n 00Ah 2 Clut Height\n 00Ch .. CLUT entries (16bit per entry, Width*Height*2 bytes)\nThis is an ASCII text file for \"artist boards\" with following entries:
TIM0 file0.tim ;\\\n TIM1 file1.pxl file1.clt ; four TIM banks (with TIM or PXL/CLT files)\n TIM2 ; (or no filename for empty banks)\n TIM3 ;/\n CEL0 file0.cel ;-one CEL (with CEL, or no filename if none)\n MAP0 file0.bgd ;\\\n MAP1 file1.bgd ; four BG MAP banks (with BGD filenames)\n MAP2 ; (or no filename for empty banks)\n MAP3 ;/\n ANM0 file0.anm ;-one ANM (with ANM, or no filename if none)\n DISPLAY n ;0-3=256/320/512/640x240, 4-7=256/320/512/640x480\n COLOR n ;0=4bpp, 1=8bpp ;docs are unclear, is it COLORn or COLOR n?\n ADDR0 texX texY clutX clutY numColorSets ;\\\n ADDR1 texX texY clutX clutY numColorSets ; four texture/palette offsets\n ADDR2 texX texY clutX clutY numColorSets ; for the corresponding TIM banks\n ADDR3 texX texY clutX clutY numColorSets ;/ (or whatever for empty banks?)\n 000h 4 ID (00000041h)\n 004h 4 Flags (bit0=FIXP, bit1-31=Reserved/zero)\n 008h 4 Number of Objects (N) ;\"integral value\" uh?\n 00Ch N*1Ch Object List (1Ch-byte per entry)\n ... .. Data (Vertices, Normals, Primitives)\n 000h 4 Start address of a Vertex ;\\Address values depend on the\n 004h 4 Number of Vertices ; file header's FIXP flag:\n 008h 4 Start address of a Normal ; FIXP=0 Addr from begin of Object\n 00Ch 4 Number of Normals ; FIXP=0 Addr from begin of TMD File\n 010h 4 Start address of a Primitive ;\n 014h 4 Number of Primitives ;/\n 018h 4 Scale (signed shift value, Pos=SHL, Neg=SHR) (not used by LIBGS)\n 000h 2 Vertex X (signed 16bit)\n 002h 2 Vertex Y (signed 16bit)\n 004h 2 Vertex Z (signed 16bit)\n 006h 2 Unused\n 000h 2 Normal X (fixed point 1.3.12)\n 002h 2 Normal Y (fixed point 1.3.12)\n 004h 2 Normal Z (fixed point 1.3.12)\n 006h 2 Unused\n 000h 1 Output Size/4 of the GPU command (after GTE conversion)\n 001h 1 Input Size/4 of the Packet Data in the TMD file\n 002h 1 Flag\n 0 Light source calculation (0=On, 1=Off)\n 1 Clip Back (0=Clip, 1=Don't clip) (for Polygons only)\n 2 Shading (0=Flat, 1=Gouraud)\n (Valid only for the polygon not textured,\n subjected to light source calculation)\n 3-7 Reserved (0)\n 003h 1 Mode (20h..7Fh) (same as GP0(20h..7Fh) command value in packet)\n 004h .. Packet Data\n 000h 4 GPU Command+Color for that packet (CcBbGgRrh), see GP0(20h..3Fh)\n ... (4) Texcoord1+Palette (ClutYyXxh) ;\\\n ... (4) Texcoord2+Texpage (PageYyXxh) ; only if Mode.bit2=1\n ... (4) Texcoord3 (0000YyXxh) ;\n ... (4) Texcoord4 (0000YyXxh) ;-quad only ;/\n ... (4) Color2 (00BbGgRrh) ;\\\n ... (4) Color3 (00BbGgRrh) ; only if Flag.bit2=1\n ... (4) Color4 (00BbGgRrh) ;-quad only ;/\n ... (2) Normal1 (index in Normal list?) ;always, unless Flag.bit0=1\n ... 2 Vertex1 (index in Vertex list?)\n ... (2) Normal2 (index in Normal list?) ;-only if Mode.bit4=1\n ... 2 Vertex2 (index in Vertex list?)\n ... (2) Normal3 (index in Normal list?) ;-only if Mode.bit4=1\n ... 2 Vertex3 (index in Vertex list?)\n ... (2) Normal4 (index in Normal list?) ;\\quad only ;-only if Mode.bit4=1\n ... 2 Vertex4 (index in Vertex list?) ;/\n ... (2) Unused zeropadding (to 4-byte boundary)\n 000h 4 GPU Command+Color for that packet (CcBbGgRrh), see GP0(40h,50h)\n ... (4) Color2 (00BbGgRrh) ;-only if Mode.bit4=1\n ... 2 Vertex1 (index in Vertex list?)\n ... 2 Vertex2 (index in Vertex list?)\n 000h 4 GPU Command+Color for that packet (CcBbGgRrh), see GP0(60h..7Fh)\n ... .. Unknown, reportedy \"with 3-D coordinates and the drawing\n content is the same as a normal sprite.\"\nThis is about same as TMD, with less features, intended to work faster.
000h 4 ID (00000042h)\n 004h 4 Offset to Primitives\n 008h 4 Offset to Shared Vertices (or 0=None)\n 00Ch 4 Number of Objects\n 010h .. Objects (4+N*4 bytes each, with offsets to Primitives)\n ... .. Primitives\n ... .. Shared Vertices (8-bytes each, if any)\n 000h 2 Vertex X (signed 16bit)\n 002h 2 Vertex Y (signed 16bit)\n 004h 2 Vertex Z (signed 16bit)\n 006h 2 Unused\n 000h 4 Number of Primitives\n 004h N*4 Offsets to Primitives ... maybe relative to hdr[004h] ?\n 000h 2 Number of Packets\n 002h 2 Type flags\n 0 Polygon (0=Triangle, 1=Quadrilateral)\n 1 Shading (0=Flat, 1=Gouraud) ;uh, with ONE color?\n 2 Texture (0=Texture-On, 1=Texture-Off) ;uh, withoutTexCoord?\n 3 Shared (0=Independent vertex, 1=Shared vertex)\n 4 Light source calculation (0=Off, 1=On) ;uh, withoutNormal?\n 5 Clip (0=Back clip, 1=No back clip)\n 6-15 Reserved for system\n 004h ... Packet(s)\n 000h 4 GPU Command+Color for that packet (CcBbGgRrh), see GP0(20h..7Fh)\n 004h 8 Vertex1 (Xxxxh,Yyyyh,Zzzzh,0000h)\n 00Ch 8 Vertex2 (Xxxxh,Yyyyh,Zzzzh,0000h)\n 014h 8 Vertex3 (Xxxxh,Yyyyh,Zzzzh,0000h)\n 01Ch (8) Vertex4 (Xxxxh,Yyyyh,Zzzzh,0000h) ;<-- only when Type.bit0=1 (quad)\n 000h 4 GPU Command+Color for that packet (CcBbGgRrh), see GP0(20h..7Fh)\n 004h 4 Offset to Shared Vertex1 ;offsets are\n 008h 4 Offset to Shared Vertex2 ;\"from the start of a row\"\n 00Ch 4 Offset to Shared Vertex3 ;aka from \"Packet+04h\" ?\n 010h (4) Offset to Shared Vertex4 ;<-- only when Type.bit0=1(quad)\n Cool Boarders 2 (MagDemo02: CB2\\DATA3\\*.PMD)\n Cardinal Syn (MagDemo03,09: SYN\\*\\*.WAD\\*.PMD) (4-byte hdr plus PMD file)\n Sesame Streets Sports (MagDemo52: SSS\\LV*\\*MRG\\*) (4-byte hdr plus PMD file)\n 000h 1 ID (50h)\n 001h 1 Version (0)\n 002h 2 Resolution (time per frame in 60Hz units, can be 0) (60Hz on PAL?)\n 004h 4 Number of Frames\n 008h .. Frame1\n ... .. Frame2\n ... .. Frame3\n ... .. etc.\n 000h 2 Frame Size in words (ie. size/4)\n 002h 2 Number of Packets (can be 0=None, ie. do nothing this frame)\n 004h 4 Frame Number (increasing 0,1,2,3,..)\n 008h ... Packet(s)\n 000h 2 Object ID\n 002h 1 Type/Flag (bit0-3=Type, bit4-7=Flags)\n 003h 1 Packet Size (\"in words (4 bytes)\")\n 004h ... Packet Data\n 000h 4 ID (00000050h) ;same as in TOD, which CAN ALSO have MSBs=zero(!)\n 004h 4 MAP FLAG (0 or 1, set when mapped via GsMapUnit() function)\n 008h 4 Primitive Header Section pointer (whut?)\n 00Ch 4 Number of Blocks\n 010h 4*N Pointers to Blocks\n ... Primitive Header section (required)\n ... Coordinate section (optional)\n ... Primitive section (required)\nRSD files consist of a set of several files (RSD,PLY,MAT,etc). The files contain the \"polygon source code\" in ASCII text format, generated from Sony's \"SCE 3D Graphics Tool\". For use on actual hardware, the \"RSDLINK\" utility can be used to convert them to binary (TMD, PMD, TOD?, HMB?) files.
RSD Main project file\n PLY Polygon Vertices (Vertices, Normals, Polygons)\n MAT Polygon Material (Color, Blending, Texture)\n GRP Polygon Grouping\n MSH Polygon Linking ;\\\n PVT Pivot Rotation center offsets ; New Extended\n COD Vertex Coordinate Attributes ; (since RSD version 3)\n MOT Animation Information ;/\n OGP Vertex Object Grouping ;-Sub-extended\n RSD/GRP/MAT/PLY (and DXF=whatever?) used on Yaroze disc (DTL-S3035)\nCDROM File Video Streaming STR (Sony) CDROM File Video Streaming STR Variants CDROM File Video Streaming Framerate CDROM File Video Streaming Audio CDROM File Video Streaming Chunk-based formats CDROM File Video Streaming Mis-mastered files Apart from the 20h-byte STR headers, movies basically consist of a series of BS files (see below).
"},{"location":"cdromfileformats/#bs-files-huffman-compressed-mdec-codes","title":"BS Files (Huffman compressed MDEC codes)","text":"BS stands for bitstream, which might refer to the use in STR files, or to the Huffman bitstreams. CDROM File Video BS Compression Versions CDROM File Video BS Compression Headers The header is followed by the bitstream...
v1/v2/v3/ea/iki --> first bit in bit15 of first halfword (good for psx)\n v0 --> first bit in bit7 of first byte (not so good for psx)\n (to use the same decoder for all version: swap each 2 bytes in v0)\nCDROM File Video Wacwac MDEC Streams
"},{"location":"cdromfileformats/#credits","title":"Credits","text":"Thanks to Michael Sabin for info on various STR and BS variants: https://github.com/m35/jpsxdec/
"},{"location":"cdromfileformats/#cdrom-file-video-streaming-str-sony","title":"CDROM File Video Streaming STR (Sony)","text":""},{"location":"cdromfileformats/#str-sectors-with-20h-byte-headers-for-mdec-movies-or-user-data","title":".STR Sectors (with 20h-byte headers) (for MDEC Movies, or User data)","text":" 000h 2 StStatus (0160h) (RV6Rh; R=Reserved=0, V=Version=1, 6=Fixed ID)\n 002h 2 StType (0000h..7FFFh=User Defined, 8000h..FFFFh=System; 8001h=MDEC)\n 004h 2 StSectorOffset (Sector number in the frame, 0=First)\n 006h 2 StSectorSize (Number of sectors in the frame) (eg. 4 or 5)\n 008h 4 StFrameNo (Frame number, 1=First) (except Viewpoint=0)\n 00Ch 4 StFrameSize (in bytes, in this frame, excluding headers/padding)\n When StType=0000h..7FFFh:\n 010h 10h StUser (user defined data)\n 020h 7E0h User data (more user defined data)\n When StType=8001h=MDEC (the only system defined type) (with StStatus=0160h):\n 010h 2 StMovieWidth (eg. 0140h)\n 012h 2 StMovieHeight (eg. 00F0h)\n 014h 4 StHeadM (reserved for system) (eg. 38000720h) ;\\same as [020h-027h]\n 018h 4 StHeadV (reserved for system) (eg. 00020001h) ;/from 1st STR sector\n 01Ch 4 Unspecified (eg. 00000000h) (except Viewpoint<>0)\n 020h 7E0h Data (in BS format) (or padding, when image is smaller than frame)\nThe video frames consist of BS compressed images (that is, all sectors have STR headers at 000h..01Fh, and the first sector of each frame does additionally contain a standard BS fileheader at offset 020h..027h).
See \"CDROM File Video BS Compression\" chapters\nThe Width/Height entries are almost always multiples of 16 pixels. But there are a few exceptions:
Height=260 (104h) in Star Wars Rebel Assault II, NTSC (S1\\L01_PLAY.STR)\n Height=200 (0C8h) in Perfect Assassin (DATA.JFS\\CDV\\*.STR)\n Height=40 (028h) in Gran Turismo 1 (TITLE.DAT\\*, MagDemo10 and MagDemo15)\n Width=232 (0E8h) in Gran Turismo 1 (TITLE.DAT\\*, MagDemo10 only)\nMetal Gear Solid MGS\\ZMOVIE.STR contains subtitles as text strings: The first sector of the .STR file is something custom (without STR header), the remaining movie consists of STR sectors with StType=0001h for subtitles and StType=8001h for picture frames. Unknown if other games are using the same method, or other methods. Obviously, subtitles could be also displayed as part of the compressed image, but text strings are much smaller, have better quality, and would also allow to support multiple languages.
"},{"location":"cdromfileformats/#cdrom-file-video-streaming-str-variants","title":"CDROM File Video Streaming STR Variants","text":""},{"location":"cdromfileformats/#str-id-values","title":"STR ID Values","text":" 2-byte 0160h ;Standard STR header\n 1-byte 01h ;Ace Combat 3 Electrosphere\n 4-byte \"SMJ\",01h ;Final Fantasy 8, Video\n 4-byte \"SMN\",01h ;Final Fantasy 8, Audio/left\n 4-byte \"SMR\",01h ;Final Fantasy 8, Audio/righ\n 4-byte 0000000xh ;Judge Dredd\n 4-byte DDCCBBAAh ;Crusader: No Remorse, older Electronic Arts\n 4-byte 08895574h ;Chunk header in 1st sector only, Best Sports (demo)\n 4-byte \"VLC0\" ;Chunk header in 1st sector only, newer Electronic Arts\n 4-byte \"VMNK\" ;Chunk header in 1st sector only, Policenauts\n 4-byte 01h,\"XSP\" ;Sentient header in 1st sector only\n N-byre zero(es) ;Polygons? (in last 150Mbyte of PANEKIT.STR)\nThe official definition from Sony's File Formats document is as so;
0000h..7FFFh=User Defined\n 8000h..FFFFh=System (with 8001h=MDEC being the only officially defined type)\n 0000h=Polygon Video, Wacwac as Polygon Stream\n 0000h=Polygon Video?, Army Men Air Attack 2 (MagDemo40: AMAA2\\*.PMB)\n 0000h=MDEC Video, Alice in Cyberland\n 0001h=MDEC Video, Ridge Racer Type 4 (PAL version, 320x176 pix)\n 0001h=Whatever extra data for XA-ADPCM streams (Bits Laboratory games)\n 0001h=Whatever non-audio waverform? (3D Baseball)\n 0001h=Subtitles, Metal Gear Solid MGS\\ZMOVIE.STR\n 0002h=Software-rendered video (without using MDEC/GTE) (Cyberia)\n 0002h=MDEC Video, Wacwac with IntroTableSet\n 0003h=MDEC Video, Wacwac with EndingTableSet\n 0004h=MDEC Video, Final Fantasy 9 (MODE2/FORM2)\n 0008h=SPU-ADPCM, AKAO audio (Final Fantasy 9)\n 0000h=SPU-ADPCM, AKAO audio (Chrono Cross Disc 1, Legend of Mana)\n 0001h=SPU-ADPCM, AKAO audio (Chrono Cross Disc 1, Legend of Mana)\n 0100h=SPU-ADPCM, AKAO audio (Chrono Cross Disc 2)\n 0101h=SPU-ADPCM, AKAO audio (Chrono Cross Disc 2)\n 0000h=Whatever special, channel 0 header (Nightmare Project: Yakata)\n 0400h=Whatever special, channel 1 header (Nightmare Project: Yakata)\n 0001h=Whatever special, channel 0 data (Nightmare Project: Yakata)\n 0401h=Whatever special, channel 1 data (Nightmare Project: Yakata)\n 5349h=MDEC Video, Gran Turismo 1 and 2 (with BS iki)\n 0078h=MDEC Ending Dummy (Mat Hoffman's Pro BMX (MagDemo48: MHPB\\SHORT.STR)\n 5673h=MDEC Leading Dummy (Mat Hoffman's Pro BMX (MagDemo48: MHPB\\SHORT.STR)\n 8001h=MDEC Video, Standard MDEC (most common type value)\n 8001h=Polygon Video (Ape Escape) (same ID as standard MDEC)\n 8001h=Eagle One: Harrier Attack various types (MDEC and other data)\n 8001h=Dance series SPU-ADPCM streaming (with STR[1Ch]=DDCCBBAAh)\n 8101h=MDEC Video, Standard MDEC plus bit8=FlagDisc2 (Chrono Cross Disc 2)\nMost movies start with STR video sectors. But a few games start with XA-ADPCM:
Ace Combat 3 Electrosphere (*.SPB)\n Alice in Cyber Land (*.STR)\n Judge Dredd (*.IXA) ;and very small 4-byte STR header\n ReBoot (MOVIES\\*.WXA)\n EA videos ;\\\n Crusader ; chunks\n Policenauts ;/\n AKAO videos\nThis is an archive dedicated to STR movies (with number of frames instead of filesize entries). Metal Gear Solid does also have cut-scenes with polygon animations (but those are supposedly stored elsewhere?).
000h 4 Number of entries (4)\n 004h N*8 File List\n ... .. Zerofilled\n 000h 2 Unknown... decreasing values?\n 002h 2 Number of Frames (same as last frame number in STR header)\n 004h 4 Offset/800h (to begin of STR movie, with subtiltes in 1st sector)\n 04 00 00 00\n ED 97 9E 01 01 00 00 00 ;num sectors=1439h ;div19Eh=C.81h ;97EDh-6137h=36B6h\n 37 61 86 01 3A 14 00 00 ;num sectors=0F41h ;div186h=A.03h ;6137h-38D0h=2867h\n D0 38 10 03 7B 23 00 00 ;num sectors=1EA1h ;div310h=A.00h ;38D0h-2302h=15CEh\n 02 23 73 02 1C 42 00 00 ;num sectors=1881h ;div273h=A.01h ;2302h-0000h=2302h\n 000h 2 STR ID (0160h) ;\\\n 002h 2 STR Type (0001h=Subtitles) ;\n 004h 2 Sector number within Subtitles (0) ; STR\n 006h 2 Number of Sectors with Subtitles (1) ; header\n 008h 4 Frame number (1) ;\n 00Ch 4 Data size counted in 4-byte units (same as [02Ch]/4) ;\n 010h 10h Zerofilled ;/\n 020h 4 Unknown (2) ;\\\n 024h 4 Unknown (1AAh, 141h, or 204h) ; Data\n 028h 4 Unknown (00100000h) ; part\n 02Ch 4 Size of all Subtitle entries in bytes plus 10h ;\n 030h .. Subtitle entries ;/\n ... .. Zeropadding to 800h-byte boundary ;-padding\n 000h 4 Offset from current subtitle to next subtitle (or 0=Last subtitle)\n 004h 4 First Frame number when to display the subtitle?\n 008h 4 Number of frames when to display the subtitle?\n 00Ch 4 Zero\n 010h .. Text string, terminated by 00h\n ... .. Zeropadding to 4-byte boundary\n 008h 4 Frame number (0=First) ;<-- instead of 1=First\n 01Ch 2 Unknown (always D351h) ;<-- instead of zero\n 01Eh 2 Number of Frames in this STR file ;<-- instead of zero\nResident Evil 2 (ZMOVIE\\.STR, PL0\\ZMOVIE\\.STR) Super Puzzle Fighter II Turbo (STR/CAPCOM15.STR)
01Ch 4 Sector number of 1st sector of current frame ;<-- instead of zero\nChrono Cross Disc 1 does have normal STR headers, but Disc 2 has Type.bit8 toggled:
002h 2 STR Type (8101h=Disc 2) ;<-- instead of 8001h\nNeed for Speed 3 Hot Pursuit (MOVIES\\.XA, contains videos, not raw XA-ADPCM) Jackie Chan Stuntmaster (FE\\MOVIES\\.STR) With slightly modified STR headers:
014h 4 Number of Frames (..excluding last some frames?) ;-instead BS[0..3]\n 018h 4 Unlike the above modified entry, this is normal ;-copy of BS[4..7]\nThis has leading XA-ADPCM, and customized STR header:
014h 2 Type (0000h=Normal, 01FFh=Empty frames at end of video)\n 016h 2 Number of Frames (excluding empty ones at end of video)\n 018h 8 Zerofilled\nThese two games use BS iki format, and (unlike other iki videos) also special STR headers:
002h 2 STR Type (5349h) (\"IS\") ;-special (instead 8001h)\n 010h 2 Total number of frames in video ;-special (instead width)\n 012h 2 Flags (bit15=1st, bit14=last) ;-special (instead height)\n 014h 8 Zero ;-special (instead BS header copy)\n 020h 7E0h Data (in BS iki format) ;-BS iki header (with width/height)\n Namely, flags in [012h] are toggled on first/last sector of each frame,\n and of course [04h] does also increase per sector.\nUsed by all movies in PGA Tour 96, 97 (and for the ZZBUFFER\\BIGSPY.STR dummy padding movie in PGA Tour 98). The videos have normal BS v2 data, but the Frame Size entry is 8 smaller than usually. As workaround, always load [0Ch]+8 for all movies with standard STR headers (unless that would exceed [06h]*7E0h).
00Ch 4 Frame Size-8 (ie. excluding 8-byte BS header) ;instead of Size-0\n ZZBUFFER\\SPY256.STR [14h..1Fh]=normal copy of 8-byte BS v2 header and zero\n ZZBUFFER\\SPYGLASS.STR [14h..1Fh]=zerofilled ;\\BS v1\n ZZBUFFER\\SPYTEST.STR [14h..1Fh]=00 00 10 00 00 00 00 09 00 00 07 EE ;/\n ZZBUFFER\\BIGSPY.STR Used in PGA Tour 98 (instead of above three files)\nNote: First sector contains XA-ADPCM audio (video starts in 2nd sector).
STR Sector Header:\n 002h 2 STR Type (0000h=Alice in Cyber Land video) ;-special\n 008h 4 Frame number (1=First) (bit15 set in last frame, or FFFFh)\n 010h 10h Zerofilled (instead width/height and BS header copy) ;-special\n 020h 7E0h Data (in BS v2 format)\n 014h 8 Copy of decrypted BS header (instead of encrypted BS header)\nThese files do have BS ID=3000h (except, the first and last some frames have nromal ID=3800h). The STR header is quite normal (apart from reflecting the odd BS ID):
016h 2 Copy of BS ID, 3000h in most frames (instead of 3800h)\n 020h 7E0h Data (in BS format, also with BS ID 3000h, instead of 3800h)\nThese movies have Extra stuff in the data section. The STR header is quite normal (apart from reflecting the Extra stuff):
00Ch 4 Frame Size in bytes (=size of ExtraHeader + BsData + ExtraData)\n 014h 4 Copy of Extra Header ;instead of BS[0..3]\n 018h 4 Copy of BS[0..3] ;instead of BS[4..7]\n 020h 7E0h Data (ExtraHeader + BsData + ExtraData)\n 000h 2 Size of BS Data area (S1) ;\\Extra Header\n 002h 2 Size of Extra Data area (S2) ;/\n 004h S1 BS Data (in BS v3 format) ;-BS Data\n .. S2 Extra Data (unknown purpose) ;-Extra Data\nThis is a somewhat \"normal\" movie, without audio, and with the STR headers moved to the begin of the file:
000h Nx20h STR Headers ;size = filesize/800h*20h\n ... Nx7E0h Data ;size = filesize/800h*7E0h\n 006h 2 Number of Sectors in this Frame-1 (8..9 = 9..10 sectors)\n 00Ch 4 Frame Size in bytes (8..9*7E0h = 3F00h or 46E0h)\n 010h 2 Bitmap Width (always F0h)\n 012h 2 Bitmap Width (always 50h)\n 014h 0Ch Zerofilled (instead copy of BS header or copy of Extra header)\n 020h 7E0h Data (Extra Stuff, BS v2 data, plus Unused stuff)\n 0000h Extra Stuff (7E0h bytes, whatever, often starts with 00,FF,00,FF,..)\n 07E0h BS v2 data (3720h or 3F00h bytes, including FFh-padding)\n ... Unused Sector (7E0h bytes, same as in previous frame or zerofilled)\n For 9 sectors: Only 1..7 are used, sector 8 is same as in previous frame\n For 10 sectors: Only 1..8 are used, sector 9 is zerofilled\nThe .MV files have 5 sectors/frame: Either 5 video sectors without audio, or 4-5 video sectors plus XA-ADPCM audio (in the latter case, audio is in each 8th sector (07h,0Fh,17h,1Fh,etc), hence having filesize rounded up to N*8 sectors):
Filesize = 800h*((NumberOfFrames*5)) ;5 sectors, no xa-adpcm\n Filesize = 800h*((NumberOfFrames*5+7) AND not 7) ;4-5 sectors, plus xa-adpcm\n Sector 0: [10h] = Number of Frames, [12h]=Junk\n Sector 1: [10h] = Junk, [12h]=0\n Sector 2: [10h] = Junk, [12h]=Junk\n Sector 3: [10h] = Junk, [12h]=Same as below (Bitmap Height)\n Below ONLY when having 5 sectors per frame:\n Sector 4: [10h] = Bitmap Width (140h) [12h]=Bitmap Height (D0h)\n That is, frames with 4 sectors do NOT have any Bitmap Width entry\n (the duplicated Height entry in sector 3 exists, so one could compute\n Width=NumMacroBlocks*100h/Height, or assume fixed Width=320, Height=208).\nUsed by Bugriders: The Race of Kings (MOVIE\\XB.STR) Used by Rugrats Studio Tour (MagDemo32: RUGRATS\\DATA\\OPEN\\B.STR)
Each movie file is followed by dummy padding file. For example, in Bugriders:\n MOVIE\\*XA.STR Movie clip (with correct size, 320x192)\n MOVIE\\*XB.STR Black Silence padding (wrong size 640x192, should be 320x192)\n 00Ch 4 Frame Size (087Ch)\n 010h 2 Bitmap Width (wrongly set to 640, should be 320)\n 012h 2 Bitmap Height (192)\n 014h 2 MDEC Size (05A0h)\n 016h 2 BS ID (3800h)\n 018h 2 BS Quant (0001h)\n 01Ah 2 BS Version (0002h)\n Filesize is always 44Fh sectors (about 2.2Mbyte per *XB.STR file)\nThe 570Mbyte R4.STR file contains XA-ADPCM in first three quarters, and two STR movies in last quarter:
1st NTSC/US movie: 320x160 pix, 0F61h frames, 4-5 sectors/frame, normal STR\n 1st PAL/EUR movie: 320x176 pix, 0CD0h frames, 5-6 sectors/frame, special STR\n 2nd NTSC/US movie: 320x160 pix, 1D6Ah frames, 4-5 sectors/frame, normal STR\n 2nd PAL/EUR movie: 320x160 pix, 18B5h frames, 5-6 sectors/frame, normal STR\n 002h 2 STR Type (0001h=Custom, 176pix PAL video) ;instead of 8001h\n 006h 2 Number of Sectors in this Frame (always 5..6)\n 00Ch 4 Frame Size (always 2760h or 2F40h, aka 7E0h*5..6)\n 012h 2 Bitmap Height (00B0h, aka 176 pixels) ;instead of 00A0h\n 014h 8 Zerofilled ;instead BS[0..7]\n 020h 7E0h Data (in BS v3 format, plus FFh-padding)\nThis contains a normal MDEC movie, but with distorted \"garbage\" in first and last some sectors.
1st sector STR Type 5673h (Leading Dummy) ;\\\n 2nd sector STR Type 8001h (distorted/empty MDEC) ; junk\n 3rd..6th sector STR Type 8001h (distorted/garbage MDEC) ;/\n 7th sector and up STR Type 8001h (normal MDEC, with odd [01Ch]) ;-movie\n Last 96h sectors STR Type 0078h (Ending Dummy) ;-junk\n 002h 2 STR Type (5673h=Leading Dummy)\n 004h 4 Whatever (0004000Ch)\n 008h 4 Whatever (0098967Fh)\n 00Ch 4 Frame Size (always 100h)\n 010h 7F0h EAh-filled\n 002h 2 STR Type (8001h=Normal MDEC ID, but content is empty)\n 004h 4 Whatever (0004000Ch) ;\\\n 008h 4 Whatever (0098967Fh) ; same as in 1st sector\n 00Ch 4 Frame Size (always 100h) ; (but ID at [002h] differes)\n 010h 7F0h EAh-filled ;/\n 002h 2 STR Type (8001h=Normal MDEC ID, but content is distorted)\n 004h 2 Sector number within current Frame (always 0)\n 006h 2 Number of Sectors in this Frame (always 1)\n 008h 4 Frame number (increasing, 1..4 for 3rd..6th sector)\n 00Ch 4 Frame Size (always 7D0h)\n 010h 10h EAh-filled\n 020h 7D0h Unknown (random/garbage?)\n 7F0h 10h EAh-filled\n Caution: The STR header values aren't constant throughout the frame:\n Entry entry [01Ch] is incremented per sector (or wraps to 0 in new section).\n 01Ch 4 Increasing sector number (within current movie section or so)\n 002h 2 STR Type (0078h=Ending Dummy)\n 004h 2 Sector number within current Frame (always 0)\n 006h 2 Number of Sectors in this Frame (always 1)\n 008h 4 Frame number (increasing, in last 96h sectors)\n 00Ch 4 Frame Size (always 20h)\n 010h 2 Bitmap Width (always 40h)\n 012h 2 Bitmap Height (always 40h)\n 014h 7ECh Zerofilled\nThese movies have Extra stuff in the data section. The STR header is quite normal (apart from reflecting the Extra stuff):
00Ch 4 Frame Size in bytes (including 28h-byte extra stuff)\n 014h 8 Copy of Extra data [0..7] :-instead of BS header[0..7]\n 020h 7E0h Data (ExtraData + BsData)\n 000h 28h Extra data (unknown purpose, reportedly \"Camera data\" ... whut?)\n 028h .. BS Data (in BS v1 format)\nThere are several customized STR header entries:
002h 2 STR Type (0004h=FF9/Video) ;instead of 8001h\n 004h 2 Sector number within current Frame (02h..num-1) (2..9 for video)\n 006h 2 Total number of Audio+Video sectors in this frame (always 0Ah)\n 00Ch 4 Frame Size/4 (of BS data, excluding MBG extra) ;instead of Size/1\n 014h 8 Copy of BS[0..7] from 8th video sector ;instead 1st sector\n 01Ch 2 Usually 0000h (or 0004h in some MBG sectors) ;inszead of 0000h\n 01Eh 2 Usually 0000h (or 3xxxh in some MBG sectors) ;inszead of 0000h\n 020h 8F4h Data (in BS v2 format, plus MBG extra data, if any)\n Namely, entry [1Ch..1Fh]=nonzero occurs only on the sector that does contain\n the end of BS data (=and begin of MBG extra data), and of course [04h] does\n also increase per sector.\n [04h]=00h-01h 1st-2nd audio sector, SPU-ADPCM (see Audio streaming chapter)\n [04h]=02h-06h 1st-5th video sector, unused, [020h..913h] is FFh-filled\n [04h]=07h 6th video sector, contains end of BS data and MBG extra, if any\n [04h]=08h 7th video sector, contains middle of BS data\n [04h]=09h 8th video sector, contains begin of BS data\n Audio sectors are MODE2/FORM1 (800h bytes, with error correction)\n Video sectors are MODE2/FORM2 (914h bytes, without error correction)\n 000000000100010 MDEC=001Eh (run=0, level=+1Eh) ;-normal (used)\n 000000000100011 MDEC=03E1h (run=0, level=-1Eh) ;-normal (not used)\n 0000010000001111100001 MDEC=03E1h (run=0, level=-1Eh) ;-escape (used)\n FF FF FF FF FE FF FE 41 AD AD AD AD AD AD AD AD\n AD AD AD AD AD AD AD AD AD AD AD AD AD AD AD AD\n AD AD AD AD AD AD AD AD\n (followed by FF's, which might be padding, or part of the extra data)\nVideo frames are always 320x224. The video frames are preceeded by two SPU-ADPCM audio sectors.
000h 4 ID \"SMJ\",01h=Video\n 004h 1 Sector number within current Frame (02h..num-1) (2..9 for video)\n 005h 1 Total number of Audio+Video sectors in this frame, minus 1 (9)\n 006h 2 Frame number (0=First)\n 008h 7F8h Data (in BS v2 format)\nThe videos start with one XA-ADPCM sector, followed by the first Video sector.
STR Sector Header:\n 000h 1 Always 01h\n 001h 1 Sector number within current Frame (00h..num-1) (8bit)\n 002h 2 Number of Sectors in this Frame\n 004h 2 Unknown (1 or 3)\n 006h 2 Frame number (decreasing, 0=Last)\n 008h 2 Bitmap Width in pixels ;\\130hxE0h or 140hxB0h or 80hx60h\n 00Ah 2 Bitmap Height in pixels ;/\n 00Ch 4 Zero\n 010h 2 Zero, or decreasing timer (decreases approx every 2 sectors)\n 012h 2 Zero, or decreasing timer (decreases approx every 1 sector)\n 014h 3 Zero\n 017h 1 Zero, or increases with step 2 every some hundred sectors\n 018h 2 Zero, or Timer (increments when [1Ah] wraps from 04h to 01h)\n 01Ah 1 Zero, or Timer (increments when [1Bh] wraps from 5Fh to 00h]\n 01Bh 1 Zero, or Timer (increments approx every 1 sector)\n 01Ch 2 Zero, or Whatever (changes to whatever every many hundred sectors)\n 01Eh 2 Zero, or 0204h\n 020h 7E0h Data (in BS v3 format)\n Namely, entry [10h..1Fh] can change within the frame (happens in japanese\n version), and of course [01h] does also increase per sector.\nThis is a lightgun-game with \"interactive movies\". The gameplay consists of running on a fixed path through a scene with pre-recorded background graphics, the only player interaction is aiming the gun at other people that show up in that movie scene. There are two movie types:
LEVELS\\*\\*.IXA - Interactive gameplay movies\n CUTS\\*.IXA - Non-interactive cut-scene movies\n 000h 4 Sector number within current Frame (LEVELS=0..8, or CUTS=0..9)\n 004h 7FCh Data (see below)\n Note: CUTS videos have 2 leading XA-ADPCM sectors\n 000h .. BS Data (in BS v2/v3 format) ;-BS picture\n Note: LEVELS videos have 1 leading XA-ADPCM sector\n 000h 4 Offset to BS Data (always 28h) ;\\\n 004h 4*6 Offsets to Extra Stuff 1..6 ; extra header\n 01Ch 0Ch Zerofilled ;/\n 028h .. BS Data (in BS v2/v3 format) ;-BS picture\n ... .. Extra Stuff 1..6 ;-extra data\nThe .iki video format (found in files with .IKI or .IK2 extension) is used in several games made by Sony. iki movie sectors have some different properties:
* There are only as many iki video sectors as needed to hold all the\n frame's data. Remaining sectors are null.\n * The first sector's Submode.Channel starts at zero, then increments for\n each sector after that, and resets to zero after an audio sector.\n * IK2 videos can also have variable frame rates that are very inconsistent.\nAccording to Sony, BS encoded 320x240pix videos can be played at 30fps (with cdrom running at double speed).
"},{"location":"cdromfileformats/#str-frame-rate","title":"STR Frame Rate","text":"As a general rule, the frame rate is implied in CDROM rotation speed (150 or 75 sectors per second, minus the audio sectors, divided by the number of sectors per video frame).
"},{"location":"cdromfileformats/#fixedvariable-framerates","title":"Fixed/Variable Framerates","text":"The frame can drop on video frames that contain more sectors than usually. Video frames that require fewer sectors than often padded with zerofilled sectors. However, some games don't have that padding, so they could end up reeceiving up to 150 single-sector frames per second; the actual framerate is supposedly slowed down to 60Hz or less via Vblank timer (and with the CDROM reading getting paused when the read-ahead buffer gets full).
"},{"location":"cdromfileformats/#audio-samplerate","title":"Audio Samplerate","text":"XA-ADPCM audio contains samplerate info (in the FORM2 subheader), the samplerate versus amount of audio sectors can be used to compute the CDROM rotation speed. There are two exceptions: Some movies don't have any audio at all, and some movies use SPU-ADPCM instead of XA-ADPCM. In the latter case, the SPU Pitch (samplerate) may (or may not) be found somewhere in the audio sector headers.
"},{"location":"cdromfileformats/#cdrom-rotation-speed","title":"CDROM Rotation speed","text":"As said above, the speed can be often detected via audio sample rate. Otherwise, the general rule is that most PSX games are used 2x speed (150 sectors/second). But, there are a few games with 1x speed (see below).
"},{"location":"cdromfileformats/#cdrom-single-speed-75-sectorsframe","title":"CDROM Single speed (75 sectors/frame)","text":"Here are probably most of the USA games with videos at 1x speed.
007 - The World Is Not Enough\n 1Xtreme\n Arcade Party Pak\n Atari Anniversary Edition Redux\n Blast Radius\n Blue's Clues - Blue's Big Musical\n Chessmaster II\n Chronicles of the Sword\n Civilization II\n Colin McRae Rally\n Creatures - Raised in Space\n Cyberia\n Demolition Racer\n Dune 2000\n ESPN Extreme Games\n FIFA Soccer 97\n Fade to Black\n Family Connection - A Guide to Lightspan\n Fear Effect\n Fox Hunt\n Interactive CD Sampler Volume 1\n Jade Cocoon - Story of the Tamamayu\n Jeopardy! 2nd Edition\n Juggernaut\n Krazy Ivan\n MTV Sports - Skateboarding featuring Andy Macdonald\n MTV Sports - T.J. Lavin's Ultimate BMX\n Medal of Honor\n Medal of Honor - Underground\n Official U.S. PlayStation Magazine Demo Disc 23\n Planet of the Apes\n PlayStation Underground Number 2\n Shockwave Assault\n Starblade Alpha\n Starwinder - The Ultimate Space Race\n Str.at.e.s. 1 - Match-A-Batch\n Str.at.e.s. 5 - Parallel Lives!\n Str.at.e.s. 7 - Riddle Roundup!\n The X-Files\n Top Gun - Fire at Will!\n Um Jammer Lammy\n Uprising X\n Wheel of Fortune - 2nd Edition\n Williams Arcade's Greatest Hits\nSTR movies are usually interleaved with XA-ADPCM sectors (the audio sectors are automatically decoded by the CDROM hardware and consist of raw ADPCM data without STR headers). CDROM File Audio Streaming XA-ADPCM However, there are also movies without audio. And a few movies with SPU-ADPCM audio.
"},{"location":"cdromfileformats/#spu-adpcm-in-chunk-based-formats","title":"SPU-ADPCM in Chunk-based formats","text":"CDROM File Video Streaming Chunk-based formats
"},{"location":"cdromfileformats/#spu-adpcm-in-chrono-crosslegend-of-mana-audio-sector","title":"SPU-ADPCM in Chrono Cross/Legend of Mana Audio Sector","text":"Chrono Cross Disc 1 (HiddenDirectory\\1793h..17A6h) Chrono Cross Disc 2 (HiddenDirectory\\1793h..179Dh) Legend of Mana (MOVIE\\*.STR, except some movies without audio)
000h 2 STR ID (0160h)\n 002h 2 STR Type (0000h, 0001h, 0100h, or 0101h)\n 0000h=Legend of Mana, Audio normal sectors\n 0001h=Legend of Mana, Audio sectors near end of movie\n 0000h=Chrono Cross Disc 1, Audio.left?\n 0001h=Chrono Cross Disc 1, Audio.right?\n 0100h=Chrono Cross Disc 2, Audio.left?\n 0101h=Chrono Cross Disc 2, Audio.right?\n 004h 2 Sector number in Frame (0=Audio.left?, 1=Audio.right?)\n 006h 2 Number of Audio sectors in this frame (always 2)\n 008h 4 Frame number (1=First)\n 00Ch 4 Unused (Chrono: FFh-filled or Mana: 00000FC0h=2x7E0h=Framesize?)\n 010h 10h Unused (Chrono: FFh-filled or Mana: 00h-filled)\n 020h 60h Unused (FFh-filled)\n 080h 4 ID \"AKAO\"\n 084h 4 Frame number (0=First)\n 088h 8 Unused (zerofilled)\n 090h 4 Remaining Time (step 690h) (can get stuck at 0340h or 0B20h at end)\n 094h 4 Zero\n 098h 4 Unknown (11h)\n 09Ch 4 Pitch (1000h=44100Hz)\n 0A0h 4 Number of bytes of audio data (always 690h)\n 0A4h 2Ch Unused (zerofilled)\n 0D0h 690h Audio (10h-byte SPU-ADPCM blocks) (1680 bytes)\n 760h A0h Unused (10h-byte SPU-ADPCM blocks with flag=03h and other bytes=0)\n 000h 4 ID \"SMN\",01h=Audio/left, \"SMR\",01h=Audio/right\n 004h 1 Sector number in Frame (0=Audio.left, 1=Audio.right)\n 005h 1 Total number of Audio+Video sectors in this frame, minus 1 (1 or 9)\n 006h 2 Frame number (0=First)\n 008h E8h Unknown (camera data?) (232 bytes)\n 0F0h 6 Audio ID (usually \"MORIYA\", sometimes \"SHUN.M\")\n 0F6h 0Ah Unknown (10 bytes) (reportedly 10 bytes at offset 250 = FAh ?????)\n 100h 4 ID \"AKAO\"\n 104h 4 Frame number (0=First)\n 108h 14h Unknown (20 bytes)\n 11Ch 4 Pitch (1000h=44100Hz)\n 120h 4 Number of bytes of audio data (always 690h)\n 124h 2Ch Unknown (44 bytes)\n 150h 20h Unknown (32 bytes)\n 170h 690h SPU-ADPCM Audio data (690h bytes)\nThe FF9 audio sectors are normal MODE2/FORM1 sectors (unlike the FF9 video sectors, which are MODE2/FORM2).
000h 2 STR ID (0160h)\n 002h 2 STR Type (0008h=FF9/Audio)\n 004h 2 Sector number in Frame (0=Audio.left, 1=Audio.right)\n 006h 2 Total number of Audio+Video sectors in this frame (always 0Ah)\n 008h 4 Frame number (1=First)\n 00Ch 4 Zero\n 010h 1 Audio flag? (00h=No Audio, 01h=Audio)\n 011h 4Fh Zerofilled --- XXX or whatever (when above is 00h)\n 060h 4 Number of Frames in this STR file\n 064h 1Ch EEh-filled\n Below 780h bytes are all zerofilled when [10h]=00h (no audio)\n Below 780h bytes are reportedly all ABh-filled \"in the last frame of a movie\n on Disc 4\" (unknown which movie, and if that occurs in other movies, too)\n 080h 4 ID \"AKAO\"\n 084h 4 Frame number (0=First)\n 088h 14h Unknown (20 bytes)\n 09Ch 4 Pitch (116Ah=48000Hz) (or 1000h=44100Hz in final movie)\n 0A0h 4 Number of bytes of audio data (0, 720h, 730h, or 690h=final movie)\n 0A4h 2Ch Unknown (44 bytes)\n 0D0h 730h SPU-ADPCM audio (plus leftover/padding when less than 730h bytes)\nThis format is used for raw SPU-ADPCM streaming (without video). SLES-04121 Dance: UK SLES-04161 Dance: UK eXtra TraX SLES-04129 Dance Europe SLES-04162 All Music Dance! (Italy)
000h 2 STR ID (0160h)\n 002h 2 STR Type (8001h, same as MDEC)\n 004h 2 Sector number within current Frame (0000h..num-1)\n 006h 2 Number of Sectors in this Frame (always 9)\n 008h 4 Frame number (0=First)\n 00Ch 4 Frame Size in bytes (always 4000h)\n 010h 4 Whatever (always 00A000A0h, would be width/height if it were video)\n 014h 8 Zerofilled\n 01Ch 4 Special ID (always DDCCBBAAh for Dance audio)\n 020h 7E0h Data (in SPU-ADPCM format, mono, 22200Hz aka Pitch=07F5h)\nSome games are using raw SPU-ADPCM for streaming. That is, the file is basically a normal .VB file, but it can be dozens of megabytes tall (ie. too large to be loaded into RAM all at once).
Disney's The Emperor's New Groove (MagDemo39: ENG\\STREAM\\*.CVS)\n Disney's Aladdin in Nasira's Revenge (MagDemo46: ALADDIN\\STREAM\\*.CVS)\nEA videos are chunk based (instead of using 20h-byte .STR headers). The next chunk starts right at the end of the previous chunk (without padding to sector boundaries).
STR Sector Header:\n No STR Sector header (first sector starts directly with \"VLC0\" chunk)\n VLC0 Chunk (at begin of movie file):\n 000h 4 Chunk ID \"VLC0\"\n 004h 4 Chunk Size (always 1C8h) (big-endian)\n 008h 1C0h 16bit MDEC values for E0h huffman AC codes (little-endian)\n MDEC Chunks (video frames):\n 000h 4 Chunk ID \"MDEC\" ;\\\n 004h 4 Chunk Size (...) (big-endian) ; custom chunk header,\n 008h 2 Bitmap Width in pixels (big-endian) ; instead of STR header\n 00Ah 2 Bitmap Height in pixels (big-endian) ;\n 00Ch 4 Frame Number (starting at 0) (big-endian) ;/\n 010h .. Data (in BS v2 format, but using custom Huffman codes from VLC0)\n ... .. Zeropadding to 4-byte boundary\n Audio Chunks (au00/au01):\n 000h 4 Chunk ID (\"au00\"=normal, \"au01\"=last audio chunk)\n 004h 4 Chunk Size (...) (big-endian)\n 008h 4 Total number of 2x4bit samples in previous chunks (big-endian)\n 00Ch 2 Unknown (always 800h) (maybe Pitch: 800h=22050Hz) (big-endian)\n 00Eh 2 Unknown (always 200h) (big-endian)\n ... .. SPU-ADPCM audio data, left (0Fh bytes per sample block)\n ... .. SPU-ADPCM audio data, right (0Fh bytes per sample block)\n ... .. Garbagepadding to 4-byte boundary\n Note: SPU-ADPCM does normally have 10h-byte blocks, but in this case,\n the 2nd byte (with loop flags) is omitted, hence only 0Fh-byte blocks.\n Zero Chunk (zeropadding at end of file, exists only in some EA videos):\n 000h .. Zeropadding\nCrusader: No Remorse (1996 Origin Systems) (MOVIES\\*.STR) Soviet Strike (1996 Electronic Arts) Battle Stations (1997 Electronic Arts) Andretti Racing (1996 Electronic Arts)
STR Sector Header:\n 000h 4 ID (DDCCBBAAh) (aka AABBCCDDh big-endian)\n 004h 4 Sector number within STR file (0=First, up to Filesize/800h-1)\n 008h 7F8h Data (video and audio chunks, see below) (first chunk is \"ad20\")\n Video Chunks (MDEC):\n 000h 4 Chunk ID \"MDEC\" ;\\\n 004h 4 Chunk Size (...) (big-endian) ;\n 008h 2 Bitmap Width in pixels (big-endian) ; custom chunk header\n 00Ah 2 Bitmap Height in pixels (big-endian) ;\n 00Ch 4 Frame Number (starting at 0) (big-endian) ;/\n 010h .. Data (in BS v2 format) ;-standard BS v2 data\n Audio Chunks (ad20/ad21) (22050Hz stereo):\n 000h 4 Chunk ID (\"ad20\"=normal, \"ad21\"=last audio chunk)\n 004h 4 Chunk Size (1A50h or 1A70h) (big-endian)\n 008h 4 Total number of 2x4bit samples in previous chunks (big-endian)\n 00Ch 2 Unknown (always 800h) (maybe Pitch: 800h=22050Hz) (big-endian)\n 00Eh 2 Unknown (always 200h) (big-endian)\n 010h .. SPU-ADPCM audio data, left (10h bytes per sample block)\n ... .. SPU-ADPCM audio data, right (10h bytes per sample block)\n Last STR Sector:\n 000h 18h FFh-filled (aka 8-byte STR header and 10h-byte Chunk header)\n 018h - Nothing (total STR filesize is N*800h+18h bytes)\nWing Commander III: Heart of the Tiger (MOVIES1.LIB\\*.wve) (1995, EA/Origin)
STR Sector Header:\n No STR Sector header (first sector starts directly with \"Ad10\" chunk)\n Video Chunks (MDEC):\n 000h 4 Chunk ID \"MDEC\" ;\\\n 004h 4 Chunk Size (2xx0h) (big-endian) ;\n 008h 2 Bitmap Width in pixels (big-endian) ; custom chunk header\n 00Ah 2 Bitmap Height in pixels (big-endian) ;\n 00Ch 2 Unknown (7FFFh) (big-endian) ;\n 00Eh 2 Unknown (AD14h or AD24h) (big-endian) ;/\n 010h .. Data (in BS v2 format) ;-standard BS v2 data\n ... .. Padding, up to circa 20h bytes, FFh-filled\n Audio Chunks (Ad10/Ad11) (22050Hz stereo):\n 000h 4 Chunk ID (\"ad20\"=normal, \"ad21\"=last audio chunk)\n 004h 4 Chunk Size (D38h or D28h) (or less in last chunk) (big-endian)\n 010h .. SPU-ADPCM audio data, left ? (10h bytes per sample block)\n ... .. SPU-ADPCM audio data, right ? (10h bytes per sample block)\n STR Sector Header:\n No STR Sector header (first sector starts directly with \"VMNK\" chunk)\n First chunk (800h bytes):\n 000h 4 ID \"VMNK\" (aka KNMV backwards, maybe for Konami Video/Movie)\n 004h 4 Unknown (01h)\n 008h 4 Unknown (01h)\n 00Ch 4 Unknown (F0h)\n 010h 4 Size of KLBS chunks? (40000h)\n 014h 4 Bitmap X1 (aka left border)? (16pix, 10h)\n 018h 4 Bitmap Y1 (aka upper border)? (16pix, 10h)\n 01Ch 4 Bitmap Width (288pix, 120h)\n 020h 4 Bitmap Height (144pix, 90h)\n 024h 7E4h Zerofilled\n Further chunks (40000h bytes, each):\n 000h 8 Zerofilled\n 008h 4 Chunk ID \"KLBS\" (aka SBLK backwards, maybe for Stream Block)\n 00Ch 4 Chunk Size (usually 40000h)\n 010h 4 Number of Name List entries\n 014h 4 Number of Name List entries (same as above)\n 018h 8 Zerofilled\n 020h N*30h Name List\n ... .. Data (referenced from Name List)\n ... .. Zeropadding (to end of 40000h-byte chunk)\n Name List entries:\n 000h 8 Zerofilled\n 008h 8 Data Type Name (eg. \"SCIPPDTS\")\n 010h 4 Time when to play/display the frame (0 and up)\n 014h 4 Time duration for that frame (usually 14h for Picture frames)\n 018h 4 Data Offset in bytes (from begin of chunk)\n 01Ch 4 Data Size in bytes\n 020h 10h Zerofilled\n Type \"SDNSHDTS\" aka SNDS,STDH - SoundStdHeader (Size=800h, Duration=0)\n 000h 4 Maybe Pitch? (800h) (big-endian)\n 004h 4 Maybe Pitch? (800h) (big-endian)\n 008h 4 Total SPU-ADPCM size in bytes (for whole .MOV) (big-endian)\n 00Ch 4 Unknown (FFFFFFFFh) (whatever)\n 010h 4 Unknown (00007FFFh) (big-endian)\n 014h 7ECh Zerofilled\n Type \"SDNSSDTS\" aka SNDS,STDS - SoundStdStream (Size=10h..4000h, Duration=9Ch)\n 000h 4000h SPU-ADPCM data in 10h-byte blocks (last chunk is less than 4000h)\n Type \"SCIPPDTS\" aka PICS,STDP - PictureStdPicture (Size=3xxxh, Duration=14h)\n 000h 3xxxh Picture Frame (in BS v1 format)\n Type \"SCTELLEC\" aka ETCS,CELL - ExtraCells? (Size=0Ch, Duration=1)\n 000h .. Maybe subtitle related...?\n Type \"SCTEGOLD\" aka ETCS,DLOG - ExtraD-log? (Size=19h..31h, Duration=27h..44h)\n 000h .. Maybe subtitle related...?\nThis format is used for still images with only frame, and for looping short animation sequences in the Demo Disc Menu. There's no audio.
Header Chunk:\n 000h 4 Fixed ID (74h,55h,89h,08h aka 08895574h)\n 004h 2 Bitmap Width (140h)\n 006h 2 Bitmap Height (100h)\n 008h 2 Video Frame Size/4 (17A0h or 13B0h)\n 00Ah 2 Number of Video Frames (01h or 32h)\n 00Ch 4 Frame End ID (eg. 62DCCACEh) (random?, but stays same within movie)\n Video Frame Chunk(s):\n ... .. Data (in BS v1/v2/v3 format) ;\\size = hdr[008h]*4\n ... .. FFh-filled (padding to Frame Size) ;/\n ... 4 Frame End ID (eg. 62DCCACEh) ;-same value as in hdr[00Ch]\nThis is having neither per-sector STR headers nor Chunk headers, instead it's having raw data with fixed size of 10 sectors per frame. File Header (sector 0, 800h bytes):
000h 4 File ID (01h,\"XSP\") (aka PSX backwards)\n 004h 2 Unknown (0001h)\n 006h 2 Unknown (0040h) (this is used for something...)\n 008h 2 Bitmap Width (0140h)\n 00Ah 2 Bitmap Height (00F0h)\n 00Ch 4 Total number of video frames\n 010h 4 Number of video sectors per frame (always 8)\n 014h 4 Total number of video sectors, excluding audio/dummy (=NumFrames*8)\n 018h 1 Zero\n 019h 1 Sector List size (28h) (ie. each 4 frames) ;\\or zerofilled when\n 01Ah 28h Sector Types (2=Video, 1=Audio, 0=Dummy) ;/not present\n 042h .. Zerofilled\n 7xxh .. Unknown, maybe just garbage ...?\n ... .. Zerofilled\n vVvvvvv--vvVvvv--vvvvVv--vvvvvv-Vvvvvvv- Video\n -------A-------A-------A-------A-------A Audio\n --------D-------D-------D--------------- Dummy\n V = 1st sector of video frame\n v = 2nd..8th sector of video frame (or fileheader in case of sector 0)\n A = Audio (each 8th sector, ie. sector 07h,0Fh,17h,1Fh,etc.)\n D = Dummy (occurs after some (not all) audio sectors)\n Some files have that sector arrangement stored in header[019h..041h], but\n other files have that header entries zerofilled (despite of using the same\n arrangement).\n 0000h 8 Last 8 bytes of BS v1 bitstream ;\\or garbage padding\n 0008h 3FF0h First 3FF0h of BS v1 bitstream ;/\n 3FF8h 8 Footer (64bit, with squeezed BS header and other info)\n The footer bits are:\n 0-4 5bit Quant (00h..1Fh) (only 5bit, not 6bit)\n 5-15 11bit MDEC Size in 20h-word units (80h-byte units)\n 16-23 8bit Unknown (lowbits are often same as bit48 and up?)\n 24-31 8bit BS ID/100h (3800h/100h)\n 32-47 16bit Frame Number (0=First)\n 48-63 16bit Next Sector Number (start of next video frame)\n To decrypt/convert the frame to standard BS v1 format:\n x=[3FF8h] ;get footer\n [3FF8h..3FFFh]=[0000h..0007h] ;last 8 bytes of bitstream\n [0000h]=(x AND FF00FFE0h) ;size and ID=3800h\n [0004h]=(x AND 1Fh)+10000h ;quant and version=v1\n The next_sector number is usually current_sector+1 (or +2 if that would be\n audio), in last frame it does point to end of file.\n Bitstreams smaller than 3FF8h are garbage padded (initially some 32bit garbage\n values, and in later frames leftovers from previous bitstream sectors).\n 000h 4 Always FFFFFFFFh (unfortunately, this isn't a unique ID)\n 004h 7FCh Garbage (zeroes, random, or even leaked ASM source code)\n Dummy sectors have the same Subheader as video sectors, the leading FFFFFFFFh\n could also occur in BS bitstreams or frames with garbage padding, so one must\n use the sector arrangement pattern to identify dummy sectors.\nThere are several discs that have streaming data stored as partial CDROM images (instead of as real CDROM sectors).
Format Content Where\n raw 920h-byte STR K9.5 1 - Live in Airedale (ZZBUFFER.STR) ;\\\n raw 920h-byte STR Need for Speed 3 (MOVIES\\ZZZZZZZ*.PAD) ;\n raw 920h-byte STR 3D Baseball (ZZZZZZZZ.ZZZ) ; intended\n raw 920h-byte STR Wing Commander III (DUMMY.DAT) ; padding\n raw 920h-byte STR R-Types (DMY\\DUMMY.BIN) ;\n raw 920h+junk STR+junk Grand Slam (DUMMY.BIN) ;\n raw 920h-byte XA-ADPCM Spec Ops Airborne Commando (PADDING.NUL) ;\n raw 920h-byte SW-STR Cyberia (ENDFILL\\*.STR) (software render) ;\n RIFFs/CDXAfmt STRs Sonic Wings Special (SW00.DMY = two RIFFs);/\n raw 920h-byte XA-ADPCM Rugrats (MagDemo19: STREAMS\\DB02.ISF) ;\\nonsense\n raw 920h-byte Data BABEh Rugrats (MagDemo19: STREAMS\\OPEN.BIN) ; dupes\n raw ???-byte CDDA Championship Surfer (MagDemo43: HWX\\MUSIC);/\n raw ???-byte CDDA Twisted Metal 2 (MagDemo50: TM2\\FRWYSUB.DA) ;-?\n raw 920h-byte STR Sonic Wings Special (MOV\\MQ*.STR) ;-unused?\n raw 920h-byte STR Apocalypse (MagDemo16: APOC\\*.STR)\n raw 920h-byte XA-ADPCM Apocalypse (MagDemo16: APOC\\*.XA)\n raw 920h-byte XA-ADPCM NFL Xtreme (MagDemo13: NFLX\\GAME\\SOUND\\2PLAYRNO.XA)\n raw 920h-byte XA-ADPCM Ace Combat 2 (MagDemo01: ACE2.STP)\n raw 920h-byte XA-ADPCM Colony Wars (MagDemo02: CWARS\\DEMO.PAK)\n raw 920h-byte XA-ADPCM Best Sports demo (AH2\\GAMEDATA\\COM\\MUSIC\\MUSIC.IXA)\n raw 920h-byte XA-ADPCM Tomb Raider: Last Revelation (MagDemo29: TR4\\XA1.XA)\n raw 800h-byte XA-ADPCM Croc 1 demo (MagDemo02: CROC\\MAGMUS.STR) (FORM1)\n RIFF/CDXAfmt XA-ADPCM Best Sports demo (LOMUDEMO\\SFX\\COMMENT.STR)\n RIFF/CDXAfmt ?+XA-ADPCM Ace Combat 3 Electrosphere (MagDemo30: AC3\\*.SPB)\n RIFF/CDXAfmt XA-ADPCM Colony Wars Venegance (MagDemo14: CWV\\SONYDEMO.PAK)\n RIFF/WAVEfmt CDDA T'ai Fu (MagDemo16: TAIFU\\3_10.WAV, 2x16bit 44100Hz)\n RIFF/WAVEfmt CDDA Psalm69 (beta) FRONT\\FIRE.TRK\n Data/movie sectors look as so:\n 000h 4 Sub-Header (File, Channel, Submode OR 20h, Codinginfo)\n 004h 4 Copy of Sub-Header\n 008h 800h Data (2048 bytes) ;<-- contains STR movie sectors\n 808h 4 EDC (zerofilled)\n 80Ch 114h ECC (zerofilled)\n And XA-ADPCM sectors look as so:\n 000h 4 Sub-Header (File, Channel, Submode OR 64h, Codinginfo)\n 004h 4 Copy of Sub-Header\n 008h 900h Data (18*128 bytes) ;\\contains XA-ADPCM audio sectors\n 908h 14h Data (zerofilled) ;/\n 91Ch 4 EDC (zerofilled)\nLegend of Dragoon (MagDemo34: LOD\\XA\\LODXA00.XA has FIRST SECTOR mis-mastered (it has TWO sub-headers (01,00,48,00,01,00,48,00,01,01,64,04,01,01,64,04), the remaining sectors are looking okay).
"},{"location":"cdromfileformats/#porsche-challenge-usa-srcmenustreamstr","title":"Porsche Challenge (USA) (SRC\\MENU\\STREAM\\*.STR)","text":"The subheader and data of the 1st sector are accidently overwritten by some ASCII string:
000h 4 Subheader 01 44 2D 52 \".D-R\" ;\\distorted\n 004h 4 Subheader copy 01 4D 20 47 \".M G\" ;/\"CD-ROM G\"\n 008h 299h Data ASCII 65 6E 65 72 61 ... \"enerator for Windows\"...\n 2A1h 567h Data BS bitstream (but lacks BS header and start of bitstream)\n Version .STR movies .BS pictures\n BS v2 60% 6% Most games\n BS v3 20% 4% Some newer games\n BS v1 15% 0.1% Old games\n BS ea 2% - (?) Electronic Arts titles\n BS iki 0.5% 0.1% Several games\n BS fraquant 0.2% 0.1% Rare (X-Files, Eagle One)\n BS v0 0.1% - Rare (Serial Experiments Lain)\n BS v2/v3.crypt 0.2% - Rare (Star Wars games)\n BS iki.encrypted 0.1% - Rare (Panekit)\n Wacwac MDEC 0.1% - Rare (Aconcagua)\n Polygon Streams 0.x% (?) - Some titles\n Raw MDEC - - Was never used in files?\n MPEG1 - - VCD Video CDs\n None ?% (?) 90% No videos or BS pictures\n v0 used by Serial Experiments Lain\n v1 used by Wipeout 2097 (MAKE.AV, XTRO*.AV)\n v1 used by Viewpoint (MOVIES\\*.STR) (oddly with [08h]=FirstFrame=0 and\n [1Ch]=Unspecified=Nonzero) (the game also has \".str\" files in\n VIEW.DIR\\streams, but that isn't MDEC/STR stuff)\n v1 used by Ridge Racer Revolution (MOVIE\\*.STR)\n v1 used by Policenauts\n v1 used by Final Fantasy VII (FF7)\n v1? used by Tekken 2\n v1/v2 used by Final Fantasy Tactics (OPEN*.STR)\n v1/v2 used by Project Horned Owl (*.STR)\n v1/v2 used by Gex (*.FMV)\n (and probably more)\n v2 used by Gex - Enter the Gecko (*.STR)\n v2 used by Tomb Raider (FMV\\*.FMV)\n v2 used by Alone (STR*\\*.STR)\n v2 used by Kain (*.STR)\n v2 used by Fear Effect (BOOT.SID, LOGO.SID, ABGA\\ABGA.FLX)\n v2 used by Parasite Eve 2 (INTERx.STR, and in .CDF's eg. stage1\\folder501)\n v2 used by Witch of Salzburg (MOVIE\\*.STR)\n v2 used by Breath of Fire III (LOGO\\*.STR)\n v2 used by Hear it Now (MOVIE\\*.STR)\n v2 used by Legend of Mana (MOVIE\\*.STR)\n v2 used by Misadventures of Tron Bonne (STR\\*.STR)\n v2 used by Rayman (VIDEO\\*.STR)\n v2 used by Resident Evil 1 (PSX\\MOVIE\\*.STR) ;\\although v3 is\n v2 used by Resident Evil 2 (PL0\\ZMOVIE\\*.STR, ZMOVIE\\*.STR) ;/used in *.BSS\n v2 used by Tokimeki Memorial 2 (VX*.STR)\n v2 used by Spider-Man (CINEMAS\\*.STR)\n v2 used by Perfect Assassin (CDV\\*.STR)\n v2 used by Pandemonium 2 (*.STR)\n v2 used by Die Hard Trilogy 2 (MOVIE\\*.STR)\n v2 used by Need for Speed 3 (MOVIES\\*.STR) (oddly with [14h,18h]<>[20h,24h])\n v2 used by Wild Arms (STR\\*.STR)\n v2 used by Wild Arms 2 (STR\\*.STR)\n v2 used by Frogger (*.STR)\n v2 used by Gundam Battle Assault (XA\\*.STR)\n v2 used by Alundra (MOVIE\\*.MOV)\n v2 used by Spec Ops (file 95h,96h within BIGFILE.CAT)\n v2 used by Crash Team Racing (file 1E1h..1F8h,1FAh within BIGFILE.BIG)\n (and many more)\n v2/v3 used by Lemmings Oh No More Lemmings (ANIMS\\*.STR)\n v2/v3 used by Castlevania (*.STR)\n v3 used by Heart of Darkness (CINE\\*.STR, SETUP\\*.STR)\n v3 used by R-Types (MV\\*.STR)\n v3 used by Black Matrix (MOVIE\\*.STR)\n v3 used by Nightmare Creatures II (INTRO\\*.STR, LEVEL*\\*.STR)\n (and many more)\nUsed by many EA Sports titles and several other titles from Electronic Arts:
Castrol Honda Superbike Racing\n EA Sports Supercross 2000, 2001\n Future Cop - L.A.P.D. (retail and MagDemo14: FCOPLAPD\\*.WVE and *.FSV)\n Hot Wheels - Turbo Racing\n Jampack Vol. 2\n Knockout Kings 99, 2000, 2001\n Madden NFL 99, 2000, 2001, 2002, 2003, 2004, 2005 (eg. MADN00\\FMVIDEO.DAT\\*)\n NASCAR 98, 99, 2000, 2001 (and 98 Collector's Edition, and 99 Legacy)\n NASCAR Thunder 2002, 2003, 2004 and NASCAR Rumble\n Nuclear Strike\n Official U.S. PlayStation Magazine Demo Disc 39 (...XXX which game?)\n PlayStation Underground Jampack - Winter 2000\n Road Rash Jailbreak, and Road Rash 3D\n Tiger Woods PGA Tour Golf, and Tiger Woods USA Tour 2001\n X-Files (Fox Interactive/Hyperbole Studios, 1999)\n Eagle One: Harrier Attack (Infogrames/Glass Ghost, 2000)\n Blue's Clues: Blue's Big Musical (Mattel/Viacom/TerraGlyph, 2000)\n iki: Gran Turismo 1 (STREAM.DAT) ;\\with uncommon STR header\n iki: Gran Turismo 2 (STREAM.DAT) ;/\n iki: Hot Shots Golf 2 / Everybody's Golf 2 (MagDemo31: HSG2\\MINGOL2X.BIN)\n iki: Legend of Legaia (MagDemo20: LEGAIA\\MOV\\MV2.STR)\n iki: Legend of Dragoon (STR\\*.IKI)\n iki: Omega Boost (MOVIE\\*.IKI)\n iki: Um Jammer Lammy (MagDemo24: UJL\\*.IKI) (retail: *\\*.IKI and CM\\*.IK2)\n iki: plus a dozen of japanese-only titles\n Panekit - Infinitive Crafting Toy Case (first 13Mbyte in PANEKIT.STR)\n v3.xor used by Star Wars Masters of Teras Kasi (MagDemo03: MASTERS\\*.STR)\n v2.xor supported (but not actually used) by Star Wars Masters (MagDemo03)\n v3.swap used by Star Wars Rebel Assault II (*.STR, *.SED, Stills)\n v2.swap used by Star Wars Rebel Assault II (*.STR)\n v3.swap used by BallBlazer Champions (*.STR)\n Aconcagua (JP) (2000 Sony/WACWAC!) (STR_01_00.STR and STR_09_01.STR)\n Ape Escape (DEMO\\*.STR, STR\\*.STR, and KKIIDDZZ.HED\\STR\\0006h and up)\n Aconcagua (most STRs are Polygon Streams, except two are Wacwac MDEC streams)\n Panekit - Infinitive Crafting Toy Case (last 150Mbyte in PANEKIT.STR)\nMPEG1 uses I/P/B-Frames, the I-Frames may reach similar compression as BS files. However, P-Frames and B-Frames do compress much better than BS files. CDROM Video CDs (VCD) MPEG1 isn't used in any PSX games, but VCDs can be viewed on SCPH-5903 consoles (or via software decoder in nocash PSX kernel clone).
"},{"location":"cdromfileformats/#titles-without-movies","title":"Titles without movies","text":"Most PSX titles do include movies, exceptions are some early launch titles and educational titles:
Ridge Racer 1 (1994)\n Lightspan Online Connection CD\nThere are several different BS headers. The File ID/Version entries can be used to detect the correct type. The MDEC Size entry contains the size after Huffman decompression (ie. the half-decompressed size before passing the data to the MDEC decompression hardware) (usually divided by 4 and rounded up to 80h/4 bytes).
"},{"location":"cdromfileformats/#bs-v1v2v3-header","title":"BS v1/v2/v3 header","text":" 000h 2 MDEC Size/4 (after huffman decompression) (rounded to 80h/4 bytes)\n 002h 2 File ID (3800h)\n 004h 2 Quantization step/factor (0000h..003Fh, for MDEC \"DCT.bit10-15\")\n 006h 2 Version (1, 2, or 3) (2 is most common)\n 008h ... Huffman compressed data blocks (Cr,Cb,Y1,Y2,Y3,Y4, Cr,Cb,Y1,Y2..)\nEncryption is used in Star Wars games, there are two encryption schemes (XOR and SWAP). XOR-encrypt: Star Wars Masters of Teras Kasi (MagDemo03: MASTERS\\*.STR):
000h 2 MDEC Size/4 (rounded to 80h/4 bytes) (unencrypted) ;\\same as normal\n 002h 2 File ID (3800h) (unencrypted) ; BS v1/v2/v3\n 004h 2 Quant (0..3Fh) (unencrypted) ;/\n 006h 2 Version (in bit15, plus random in LSBs):\n 00xxh..7FFFh for v2 (unknown if this could include values 0..3)\n 8000h..FFFFh for v3 (bit14-0=random, varies in each frame)\n 008h .. Encrypted bitstream\n (each halfword XORed by BE67h for v2, or XORed by E67Bh for v3)\n ... (2) Zeropadding to 4-byte boundary (unencrypted)\n ... .. Zeropadding to end of sector (unencrypted)\n The XOR values BE67h/E67Bh are hardcoded in the Star Wars Masters of Teras\n Kasi .EXE (same XOR values for both retail and demo version), unknown if any\n other games are also using that kind of encryption (and if yes, if they are\n using the same XOR values).\n 000h 2 MDEC Size/4 (rounded to 80h/4 bytes) ;\\same as normal\n 002h 2 File ID (3800h) ; BS v1/v2/v3\n 004h 2 Quant (0..3Fh) ;/\n 006h 2 Version (random 16bit, 00xxh..FFFFh) ;-no meaningful version info\n 008h 2 Bitstream 2nd halfword ;\\to \"decrypt\" the file,\n 00Ah 2 Bitstream 1st halfword ;/these must be swapped\n 00Ch .. Bitstream 3rd halfword and up ;-in normal order\n if header[06h]<=0003h then assume unencrypted v0/v1/v2/v3\n if header[06h]>=0004h then strip any trailing 0 bits, and check EndOfFrame..\n if last 10bit = 0111111111 then assume SWAP.v2\n if last 10bit = 1111111111 then assume SWAP.v3\n otherwise assume XOR.v2/v3 (and use header[06h].bit15 to distinguish v2/v3)\nIKI videos have a custom .BS header, including some GT-ZIP compressed data:
000h 2 MDEC Size/4 (rounded to 80h/4 bytes) ;\\same as normal\n 002h 2 File ID (3800h) ;/BS v1/v2/v3\n 004h 2 Bitmap Width in pixels ;instead of Quant\n 006h 2 Bitmap Height in pixels ;instead of Version\n 008h 2 Size of GT-ZIP compressed data (plus 2-byte alignment padding)\n 00Ah .. GT-ZIP compressed DC/Quant values (plus 2-byte alignment padding)\n ... .. Huffman compressed AC data blocks (Cr,Cb,Y1,Y2,Y3,Y4, Cr,Cb,Y1,Y2..)\nThe first 20h byte of the iki header & data are encrypted. Among others, the ID 3800h is inverted (=C7FFh). To decrypt them:
[buf+00h]=[buf+00h] XOR FFFFFFFFh\n [buf+04h] <--> [buf+08h] ;exchange 2x32bit\n [buf+0Ch] <--> [buf+0Eh] ;exchange 2x16bit\n [buf+10h]=[buf+10h]+FFFF6F7Bh\n [buf+14h]=[buf+14h]+69140000h\n [buf+18h]=[buf+18h]+FFFF7761h\n [buf+1Ch]=[buf+1Ch]+6B040000h\n X-Files, GRAPHICS\\*.STR,*.BIN, LOGOS\\*.STR,*.BS\n Eagle One: Harrier Attack (\\*.STR, DATA*\\*.STR) (leading zerofilled sectors)\n Blue's Clues: Blue's Big Musical (*.STR) (has one leading zerofilled sector)\n 004h 2 Quant (0001h..0003h, or fixed-point 8000h..9xxxh)\n quant=BsHeader[04h] ;get fractional quant value\n BsHeader[04h]=0001h ;force quant=1 (for use in BS v1/v2/v3 decoder)\n if quant<8000h then quant=quant*200h else quant=quant AND 7FFFh\n quant[0]=default_quant_table[0]\n for i=1 to 3Fh,\n x=(default_quant_table[i]*quant)/200h\n if x=00000000h then quant[i]=01h else quant[i]=(x AND FFh)\n next i\n use MDEC(2) command to apply quant[0..3Fh] to both Luma and Chroma tables\n use normal BS v1/v2/v3 decoder to decompress the bitmap\n 000h 1 Quant for Y1,Y2,Y3,Y4 (00h..3Fh)\n 001h 1 Quant for Cr,Cb (00h..3Fh)\n 002h 2 File ID (3800h) (or Frame Number in ENDROLL1.STR on Disc 2)\n 004h 2 MDEC Size/2 (!), and without padding (!) (unlike v1/v2/v3/iki)\n 006h 2 BS Version (0) (actually MSBs of above Size, but it's always 0)\n 008h .. Huffman Bitstream, first bit in bit7 of first byte\nLAPKS.BIN contains several chunks, each chunk contains an animation sequence with picture frame(s), each frame starts with following header:
000h 2 Bitmap Width in pixels ;\\cropped to non-black screen area,\n 002h 2 Bitmap Height in pixels ;/size can vary within the sequence\n 004h 2 Quant for Y1,Y2,Y3,Y4 (0000h..003Fh)\n 006h 2 Quant for Cr,Cb (0000h..003Fh)\n 008h 4 Size of compressed BS Bitstream plus 4 ;Transparency at [008h]+0Ch\n 00Ch 2 Size/2 of MDEC data (after huffman decompression, without padding)\n 00Eh 2 BS Version (0) (actually MSBs of above Size, but it's always 0)\n 010h .. BS Bitstream with DC and AC values (Huffman compressed MDEC data)\n ... 4 Transparency Mask Decompressed Size (Width*Height*2/8) (=2bpp)\n ... .. Transparency Mask LZSS-compressed data\nEA videos are chunk based (instead of using 20h-byte .STR headers). CDROM File Video Streaming Chunk-based formats VLC0 Chunk: Custom MDEC values (to be assigned to normal BS v2 Huffman codes). MDEC Chunks: Width/Height and BS v2 data (using MDEC values from VLC0 chunk).
"},{"location":"cdromfileformats/#raw-mdec","title":"Raw MDEC","text":"There aren't any known pictures or movies in raw MDEC format. However, the Huffman decompression functions do usually output raw data in this format:
000h 2 MDEC Size/4 (after huffman decompression) (rounded to 80h/4 bytes)\n 002h 2 File ID (3800h)\n 004h .. MDEC data (16bit DC/AC/EOB codes)\n ... .. Padding (FE00h-filled to 80h-byte DMA transfer block size boundary)\n nnnnnnnnnn DC Value (signed 10bit, -200h..+1FFh)\n If output_size=NumberOfMdecCodes*2 then EndOfFrame\n If BlockIsCrCb then QuantDC=DC+QuantC*400h else QuantDC=DC+QuantY*400h\n nnnnnnnnnn DC Value (signed 10bit, -200h..+1FEh)\n 0111111111 End of Frame (+1FFh, that, in place of Cr)\n If DC=+1FFh then EndOfFrame\n QuantDC=DC+Quant*400h\nSimilar as v1/v2, but DC values (and End code) are now Huffman compressed offsets relative to old DC, with different Huffman codes for Cr/Cb and Y1-Y4:
For Cr/Cb For Y1..Y4 Offset (added to old DC of Y/Cr/Cb block)\n 00 100 +(00h) ;\\\n 01s 00s -(01h)*4 ,+(01h)*4 ;\n 10sn 01sn -(03h..02h)*4,+(02h..03h)*4 ; required\n 110snn 101snn -(07h..04h)*4,+(04h..07h)*4 ; codes\n 1110snnn 110snnn -(0Fh..08h)*4,+(08h..0Fh)*4 ; for 10bit\n 11110snnnn 1110snnnn -(1Fh..10h)*4,+(10h..1Fh)*4 ; range\n 111110snnnnn 11110snnnnn -(3Fh..20h)*4,+(20h..3Fh)*4 ;\n 1111110snnnnnn 111110snnnnnn -(7Fh..40h)*4,+(40h..7Fh)*4 ;/\n 11111110snnnnnnn 1111110snnnnnnn -(FFh..80h)*4,+(80h..FFh)*4 ;-11bit (!)\n - 11111110 Unused ;\\\n 111111110 111111110 Unused ; unused\n 1111111110 1111111110 Unused ;/\n 1111111111 1111111111 End of Frame ;-end code\n Note: the \"snnn\" bits are indexing the values in right column,\n with s=0 for negative values, and s=1 for positive values.\n If bits=1111111111 then EndOfFrame\n If BlockIsCr then DC=DecodeHuffman(HuffmanCodesCbCr)+oldDcCr, oldDcCr=DC\n If BlockIsCb then DC=DecodeHuffman(HuffmanCodesCbCr)+oldDcCb, oldDcCb=DC\n If BlockIsY1234 then DC=DecodeHuffman(HuffmanCodesY1234)+oldDcY, oldDcY=DC\n If older_version AND DC>=0 then QuantDC=Quant*400h or (DC) ;\\requires\n If older_version AND DC<0 then QuantDC=Quant*400h or (DC+400h) ;/11bit\n If newer_version then QuantDC=Quant*400h+(DC AND 3FFh) ;-wrap 10bit\nThe DC values (including Quant values for each block) are separately stored as GT-ZIP compressed data in the IKI .BS header. CDROM File Compression GT-ZIP (Gran Turismo 1 and 2) Calculate NumBlocks=(Width+15)/16*(height+15)/16*6, decompress the DC values (until DecompressedSize=NumBlocks*2). During Huffman decompression, read the DC values from the decompressed DC buffer (instead of from the Huffman bitstream):
If BlockNo>=NumBlocks then EndOfFrame\n QuantDC = DCbuf[BlockNo]*100h + DCbuf[BlockNo+NumBlocks]\nBelow shows the huffman codes and corresponding 16bit MDEC values; the \"xx\" bits contain an index in the list of 16bit MDEC values, the \"s\" bit means to negate the AC level (in lower 10bit of the 16bit MDEC value) when s=1.
"},{"location":"cdromfileformats/#huffman-codes-for-ac-values-bs-v1v2v3iki","title":"Huffman codes for AC values BS v1/v2/v3/iki","text":" 10 FE00h ;End of Block, EOB\n 11s 0001h\n 011s 0401h\n 010xs 0002h,0801h\n 0011xs 1001h,0C01h\n 00101s 0003h\n 00100xxxs 3401h,0006h,3001h,2C01h,0C02h,0403h,0005h,2801h\n 0001xxs 1C01h,1801h,0402h,1401h\n 00001xxs 0802h,2401h,0004h,2001h\n 000001xxxxxxxxxxxxxxxx 0000h..FFFFh ;Escape code for raw 16bit values\n 000001xxxxxx0000000000 0000h..FC00h ;Escape nonsense level=0 (used in v1)\n 0000001xxxs 4001h,1402h,0007h,0803h,0404h,3C01h,3801h,1002h\n 00000001xxxxs 000Bh,2002h,1003h,000Ah,0804h,1C02h,5401h,5001h,\n 0009h,4C01h,4801h,0405h,0C03h,0008h,1802h,4401h\n 000000001xxxxs 2802h,2402h,1403h,0C04h,0805h,0407h,0406h,000Fh,\n 000Eh,000Dh,000Ch,6801h,6401h,6001h,5C01h,5801h\n 0000000001xxxxs 001Fh,001Eh,001Dh,001Ch,001Bh,001Ah,0019h,0018h,\n 0017h,0016h,0015h,0014h,0013h,0012h,0011h,0010h\n 00000000001xxxxs 0028h,0027h,0026h,0025h,0024h,0023h,0022h,0021h,\n 0020h,040Eh,040Dh,040Ch,040Bh,040Ah,0409h,0408h\n 000000000001xxxxs 0412h,0411h,0410h,040Fh,1803h,4002h,3C02h,3802h,\n 3402h,3002h,2C02h,7C01h,7801h,7401h,7001h,6C01h\n 000000000000 Unused\n 10 FE00h ;End of Block, EOB\n 11s 0001h\n 011s 0002h\n 010xs 0401h,0003h\n 0011xs 0801h,0005h\n 00101s 0004h\n 00100xxxs 000Ah,000Bh,0403h,1801h,000Ch,000Dh,1C01h,000Eh\n 0001xxs 0006h,0C01h,0402h,0007h\n 00001xxs 0008h,1001h,0009h,1401h\n 000001xxxxxx0xxxxxxx 0000h..FC00h+(+001h..+07Fh AND 3FFh) ;\\\n 000001xxxxxx000000001xxxxxxx 0000h..FC00h+(+080h..+0FFh AND 3FFh) ; Escape\n 000001xxxxxx000000000xxxxxxx Unused ; codes\n 000001xxxxxx1xxxxxxx 0000h..FC00h+(-080h..-001h AND 3FFh) ;\n 000001xxxxxx100000000xxxxxxx 0000h..FC00h+(-100h..-081h AND 3FFh) ;\n 000001xxxxxx100000001xxxxxxx Unused ;/\n 0000001xxxs 000Fh,0802h,2001h,0404h,0010h,0011h,2401h,0012h\n 00000001xxxxs 0013h,0405h,0014h,2801h,0015h,0C02h,3001h,0017h,\n 0016h,2C01h,0018h,001Ch,0019h,0406h,0803h,001Bh\n 000000001xxxxs 001Ah,3401h,001Dh,0407h,1002h,001Fh,001Eh,3801h,\n 0020h,0021h,0408h,0023h,0022h,1402h,0024h,0025h\n 0000000001xxxxs 0804h,0409h,0418h,0026h,3C01h,0027h,0C03h,1C03h,\n 0028h,0029h,002Ah,002Bh,040Ah,002Ch,1802h,002Dh\n 00000000001xxxxs 002Fh,002Eh,4001h,0805h,0030h,040Bh,0031h,0033h,\n 0032h,1C02h,0034h,1003h,0035h,4401h,040Ch,0037h\n 000000000001xxxxs 0036h,0038h,0039h,5401h,003Ah,0C04h,040Dh,5C01h,\n 2002h,003Bh,0806h,4C01h,003Ch,2402h,6001h,4801h\n 000000000000 Unused\nThis is using custom MDEC values from VLC0 chunk, and assigns them to the standard Huffman codes. There are two special MDEC values:
FE00h End of Block (EOB)\n 7C1Fh Escape code (huffman code will be followed by v2-style 16bit value)\n 10 00\n 11x 01,02\n 011x 03,04\n 010xx 05,06,07,08\n 0011xx 0D,0E,0B,0C\n 00101x 09,0A\n 00100xxxx 2E,2F,22,23,2C,2D,2A,2B,26,27,24,25,20,21,28,29\n 0001xxx 15,16,13,14,0F,10,11,12\n 00001xxx 1A,1B,1E,1F,18,19,1C,1D\n 000001 17h\n 0000001xxxx 3E,3F,38,39,30,31,34,35,32,33,3C,3D,3A,3B,36,37\n 00000001xxxxx 46,47,54,55,4E,4F,44,45,4A,4B,52,53,5E,5F,5C,5D,\n 42,43,5A,5B,58,59,48,49,4C,4D,40,41,50,51,56,57\n 000000001xxxxx 74,75,72,73,70,71,6E,6F,6C,6D,6A,6B,68,69,66,67,\n 64,65,62,63,60,61,7E,7F,7C,7D,7A,7B,78,79,76,77\n 0000000001xxxxx 9E,9F,9C,9D,9A,9B,98,99,96,97,94,95,92,93,90,91,\n 8E,8F,8C,8D,8A,8B,88,89,86,87,84,85,82,83,80,81\n 00000000001xxxxx B0,B1,AE,AF,AC,AD,AA,AB,A8,A9,A6,A7,A4,A5,A2,A3,\n A0,A1,BE,BF,BC,BD,BA,BB,B8,B9,B6,B7,B4,B5,B2,B3\n 000000000001xxxxx C6,C7,C4,C5,C2,C3,C0,C1,C8,C9,D4,D5,D2,D3,D0,D1,\n CE,CF,CC,CD,CA,CB,DE,DF,DC,DD,DA,DB,D8,D9,D6,D7\n 000000000000 Unused\nAll BS versions are using the same Huffman codes (the different BS versions do just assign different 16bit MDEC codes to them). The huffman codes can be neatly decoded by \"counting leading zeroes\" (without needing bitwise node-by-node processing; this is done in IKI video decoders via GTE registers LZCS and LZCR). Sony's normal v2/v3 decoders are using a yet faster method: A large table to interprete the next 13bit of the bitstream, the table lookup can decode up to 3 huffman codes at once (if the 13bit contain several small huffman codes).
"},{"location":"cdromfileformats/#cdrom-file-video-bs-picture-files","title":"CDROM File Video BS Picture Files","text":""},{"location":"cdromfileformats/#bs-picture-files","title":"BS Picture Files","text":"A couple of games are storing single pictures in .BS files:
Alice in Cyberland (ALICE.PAC\\*.BS)\n BallBlazer Champions (BBX_EXTR.DAT\\Pics\\*) (SWAP-encrypted)\n Bugriders: The Race of Kings (*\\*.BS and STILLS\\MENUS.BS\\*)\n Die Hard Trilogy 2 (DATA\\*.DHB, DATA\\DH*\\L*\\*.DHB, MOVIE\\*.DHB)\n Dino Crisis 2 (PSX\\DATA\\ST*.DBS\\*)\n Duke Nukem (MagDemo12: DN_TTK\\*)\n Final Fantasy VII (FF7) (MOVIE\\FSHIP2*.BIN\\*) (BS v1)\n Gran Turismo 1 (retail TITLE.DAT\\* and MagDemo10/15) (in BS iki format)\n Jet Moto 2 (MagDemo03: JETMOTO2\\*)\n Mary-Kate and Ashley Crush Course (MagDemo52: CRUSH\\SCRN\\*.BS)\n Mat Hoffman's Pro BMX (MagDemo48: MHPB\\STILLS.BIN\\*) (with width/height info)\n NFL Gameday '99 (MagDemo17: GAMEDAY\\FE\\GD98DATA.DAT)\n Official U.S. PlayStation Magazine Demo Disc 01-02 (MENU\\DATA\\*.BSS)\n Official U.S. PlayStation Magazine Demo Disc 03-54 (MENU.FF\\*)\n Parasite Eve 2 (INIT.BS, and within .HED/.CDF archives)\n Resident Evil 1 (PSX\\STAGE*\\*.BSS, headerless archive, 8000h-byte align)\n Resident Evil 2 (COMMON\\BSS\\*.BSS, headerless archive, 10000h-byte align)\n Rugrats (MagDemo19: RUGRATS\\*)\n Rugrats Studio Tour (MagDemo32: RUGRATS\\DATA\\RAW\\*.BS)\n Starwars Demolition (MagDemo39+MagDemo41: STARWARS\\SHELL\\.BS+.TBL\\*)\n Star Wars Rebel Assault 2 (RESOURCE.000\\Stills\\*) (SWAP-encrypted)\n Ultimate Fighting Championship (MagDemo38: UFC\\CU00.RBB\\390h..3E2h)\n Vigilante 8 (MagDemo09: EXAMPLE\\*)\n Witch of Salzburg (PICT\\PIC*\\*.BS and DOT1 archives *.BSS, *.DAT, *.BIN)\n X-Files (LOGOS\\*.BS and GRAPHICS\\GRAPHICS.BIN and GRAPHICS\\PACKEDBS.BIN\\*)\n You Don't Know Jack 2 (MagDemo41: YDKJV2\\RES\\UI\\*.BS)\nMovies have Width/Height entries (in the .STR header). Raw .BS picture files don't have any such information. However, there are ways to guess the correct resolution:
For BS iki format, use resolution from iki header (eg. Gran Turismo 1)\n For MHPB\\STILLS.BIN, there's width/height in chunk headers\n Count the number of blocks (EOB codes) during Huffman decompression\n Divide that number by 6 to get the number of Macroblocks\n Search matches for Height=NumBlocks/Width with Width>=Height and Remainder=0\n If Height=300..400, assume double H-resolution, repeat with Width/2>=Height\n And/or use a list of known common resoltions (see below examples)\n Search arrangements with many similar colors on adjacent macroblocks\n Blocks Pixels Example\n F0h 256x240 any?\n 12Ch 320x240 Resident Evil 2 (COMMON\\BSS\\*.BSS)\n 1E0h 512x240 Demo Disc 03-54 (MENU.FF\\*), Duke Nukem (MagDemo12)\n 1E0h 640x192 Less common than above (but used by Witch of Salzburg)\n 4B0h 640x480 Vigilante 8 (MagDemo09), Jet Moto 2 (MagDemo03)\n var random Witch of Salzburg has various random resolutions\n iki ikihdr Gran Turismo 1 has A0hxA0h and odd size (!) E8hx28h\n ? ? Final Fantasy VII (FF7)\n ? ? Ultimate Fighting Championship (UFC\\CU00.RBB\\3B7h..3E2h)\n 118h 320x224 Alice in Cyberland (most files; or two such as panorama)\n 230h ? Alice in Cyberland (AD_115.BS and AD_123A.BS)\n C8h 320x160 Unlikely for pictures (but used for STR videos, eg. Alone)\n F0h 320x192 Unlikely for pictures (but used for STR videos, eg. Wipeout)\n 1E0h 384x320 Very unlikely to see that vertical resolution on PSX\nStarwars Demolition (MagDemo39: STARWARS\\SHELL\\DEMOLOGO.BS+RESOURCE.TBL\\) Starwars Demolition (MagDemo41: STARWARS\\SHELL\\DEMOLOGO.BS+RESOURCE.TBL\\)
000h 2 Width (280h) ;\\extra header\n 002h 2 Height (1E0h) ;/\n 004h 2 MDEC Size/4 (after huffman decompression) (rounded to 80h/4 bytes)\n 006h 2 File ID (3800h)\n 008h 2 Quantization step/factor (0000h..003Fh, for MDEC \"DCT.bit10-15\")\n 00Ah 2 Version (1, 2, or 3) (2 is most common)\n 00Ch ... Huffman compressed data blocks (Cr,Cb,Y1,Y2,Y3,Y4, Cr,Cb,Y1,Y2..)\nWacwac uses different Huffman codes than BS videos, the decoder has some promising ideas that might yield slightly better compression than BS v3. However, it is used by only one known game:
Aconcagua (JP) (2000 Sony/WACWAC!)\n 000h 2 STR ID (0160h)\n 002h 2 STR Type WACWAC Tables (0002h=IntroTableSet, 0003h=EndingTableSet)\n 004h 2 Sector number within current Frame (0000h..num-1)\n 006h 2 Number of Sectors in this Frame\n 008h 4 Frame number (6 or 11 and up, because 1st some frames are Polygons)\n 00Ch 4 Frame Size in bytes\n 010h 2 Bitmap Width (always 140h) ;\\always 320x208 (in fact, the\n 012h 2 Bitmap Height (always 0D0h) ;/decoder is hardcoded as so)\n 014h 4 Quant (0..3Fh) (same for all sectors within the frame)\n 018h 8 Zerofilled\n 020h 7E0h Raw Bitstream data (without Quant or BS header) (garbage padded)\n Intro=Disc1:\\ST01_01\\STR_01_00.STR Ending=Disc2:\\ST09_01\\STR_09_01.STR\n Leading zeroes (150 sectors) Leading zeroes (150 sectors)\n Frame 0001h..0005h Polygon Frames Frame 0001h..000Ah Polygon Frames\n Frame 0006h..0545h MDEC Frames 20MB Frame 000Bh..0D79h MDEC Frames 50MB\n Frame 0546h..1874h Polygon Frames 48MB\nWacwac uses little-endian bitstreams (starting with low bit in bit0 of first byte). To decode the separate blocks in the bitstream:
Read Huffman code for DC, and output Quant*400h+(DC AND 3FFh)\n Read Huffman code for Size, aka num1,num2,num3 values for below reads\n Repeat num1 times: Read Huffman code for AC1, and output AC\n Repeat num2 times: Read Huffman code for AC2, and output AC\n Repeat num3 times: Read Huffman code for AC3, and output AC\n Output EOB (end of block)\n 14h*0Dh*6*41h*2+Align(80h)+Header(4) = 31880h+4 bytes\nAconcagua has two table sets, stored in PROGRAM.BIN (in compressed form, appearing as so: FF,90,16,2E,06,20,03,D6,etc). While watching the intro movie, the uncompressed sets can be found at these RAM locations:
80112AF8h (1690h bytes) ;Table Set for Intro Scene\n 80114188h (1B68h bytes) ;Table Set for Ending Scene\n 000h 4 Table Set size (1690h or 1B68h)\n 004h 4 Table Set exploded size (when allocating 16bit/DC, 32bit/Size/AC)\n 008h 2 Size Table max Huffman size in bits (0Ah or 09h) ;\\Size\n 00Ah 2 Size Table number of entries (40h) ;/\n 00Ch 2 DC Table max Huffman size in bits (0Bh) ;\\\n 00Eh 2 DC Table number of entries (100h) ; DC\n 010h 2 DC Huffman code Escape 10bit (non-relative 10bit DC value) ;\n 012h 2 DC Huffman size Escape 10bit (3 or 6, escape prefix size) ;/\n 014h 2 AC1 Table max Huffman size in bits (0Eh or 0Bh) ;\\\n 016h 2 AC1 Table number of entries (0DAh or 100h) ;\n 018h 2 AC1 Huffman code Escape 7bit (run=0bit, level=signed7bit) ; AC1\n 01Ah 2 AC1 Huffman code Escape 16bit (run=6bit, level=10bit) ;\n 01Ch 2 AC1 Huffman size Escape 7bit (9 or 7, escape prefix size) ;\n 01Eh 2 AC1 Huffman size Escape 16bit (9 or 7, escape prefix size) ;/\n 020h 2 AC2 Table max Huffman size in bits (0Eh) ;\\\n 022h 2 AC2 Table number of entries (AAh or F4h) ;\n 024h 2 AC2 Huffman code Escape 8bit (run=3bit, level=signed5bit) ; AC2\n 026h 2 AC2 Huffman code Escape 16bit (run=6bit, level=10bit) ;\n 028h 2 AC2 Huffman size Escape 8bit (10 or 9, escape prefix size) ;\n 02Ah 2 AC2 Huffman size Escape 16bit (10 or 9, escape prefix size) ;/\n 02Ch 2 AC3 Table max Huffman size in bits (0Eh) ;\\\n 02Eh 2 AC3 Table number of entries (87h or B2h) ;\n 030h 2 AC3 Huffman code Escape 8bit (run=4bit, level=signed4bit) ; AC3\n 032h 2 AC3 Huffman code Escape 16bit (run=6bit, level=10bit) ;\n 034h 2 AC3 Huffman size Escape 8bit (10 or 9, escape prefix size) ;\n 036h 2 AC3 Huffman size Escape 16bit (10 or 9, escape prefix size) ;/\n 038h .. Size Table (64bit per entry) ;\\\n ... .. DC Table (32bit per entry) ;\n ... .. AC1 Table (64bit per entry) ; Tables\n ... .. AC2 Table (64bit per entry) ;\n ... .. AC3 Table (64bit per entry) ;/\n 0-1 Zero\n 2-31 Huffman code (10bit max)\n 32-39 Number of AC1 codes in this block ;\\implies End of Block (EOB)\n 40-47 Number of AC2 codes in this block ; after those AC codes\n 48-55 Number of AC3 codes in this block ;/\n 56-63 Huffman size (1..10 bits)\n 0-9 Relative DC Value (relative to old DC from memorized Cr,Cb,Y)\n 10-15 Huffman size (1..11 bits)\n 16-31 Huffman code (11bit max)\n Notes: For the relative DC's, the decoder does memorize DC for Cr,Cb,Y upon\n decoding Cr,Cb,Y1,Y3 (but does NOT memorize DC when decoding Y2,Y4).\n Initial DC for Cr,Cb,Y is zero at begin of each 16x208pix slice.\n Obscurities: The decoder does accidentally use bit10 to sign-expand the\n DC value in bit0-9 (but does mask-off those bugged sign bits thereafter),\n and the decoder does uselessly memorize Y1 and Y3 separately (but uses only\n the most recently memorized value).\n 0-1 Zero\n 2-31 Huffman code (14bit max)\n 32-47 MDEC code (6bit run, and 10bit AC level)\n 48-63 Huffman size (1..14 bits)\nUsed by Ape Escape (Sony 1999) (DEMO\\.STR and some STR\\.STR files and KKIIDDZZ.HED\\STR\\0006h and up). The files start with zerofilled sectors (without STR headers), followed by sectors with STR headers with [00h]=0160h, [02h]=8001h (same values as for MDEC), but with [10h..1Fh]=zero (without resolution/header info). And the data at [20h] starts with something like 14h,00h,03h,FFh,2Ah,02h,00h,00h. That data seems to consist of polygon coordinates/attributes that are rendered as movie frames. The texture seems to be stored elsewhere (maybe in the .ALL files that are bundled with some .STR files).
"},{"location":"cdromfileformats/#panekit-polygon-streaming","title":"Panekit - Polygon Streaming","text":"Panekit STR seems to use Polygon Streaming (except 1st some Megabytes are MDEC).
"},{"location":"cdromfileformats/#aconcagua-polygon-streaming","title":"Aconcagua - Polygon Streaming","text":"Aconcagua STR does use Polygon Streaming (except first+last movie are MDEC).
"},{"location":"cdromfileformats/#cyberia-1996-tfstrstr","title":"Cyberia (1996) (TF\\STR\\*.STR)","text":"Cyberia is using Software-rendering for both movies and in-game graphics. That is, PSX hardware features like MDEC, GTE, and GPU-Polygons are left all unused, and the GPU is barely used for transferring data from CPU to VRAM. The STR header for software-rendered movie frames looks as so:
000h 2 STR ID (0160h)\n 002h 2 STR Type (0002h=Custom, Software rendering)\n 004h 2 Sector number within current Frame (0..num-1)\n 006h 2 Number of Sectors in this Frame (varies)\n 008h 4 Frame Number (1=First)\n 00Ch 4 Frame Size in Bytes/4 (note: first frame in MAP*.STR is quite big)\n 010h 2 Rendering Width (0140h)\n 012h 2 Rendering Height (00C0h)\n 014h 0Ch Unknown (zerofilled or random garbage)\n 020h 7E0h Custom data for software rendering\nProbably cut-scenes with polygon animations. The files seem to contain 2300h-byte data frames (plus XA-ADPCM sectors inserted here and there).
000h 4 Number of remaining frames\n ... 22FCh Unknown data (zeropadded if smaller)\n _______________ Unknown Streaming Data (Polygons or whatever) ________________\nThis is used for several files in 3D Baseball (BIGFILE.FOO):
BIGFILE.FOO\\0151h\\0005h,0009h,000Fh,0017h,001Bh, 02E5h,02E9h,..,0344h,0348h\n BIGFILE.FOO\\0152h\\0186h,018Ch,0192h,0198h)\n BIGFILE.FOO\\0153h\\029Ah,02A0h,02A6h,02ACh)\n 000h 2 STR ID (0160h)\n 002h 2 STR Type (0001h=Custom)\n 004h 2 Sector number within current Frame (always 0)\n 006h 2 Number of Sectors in this Frame (always 1)\n 008h 4 Frame Number (1=First)\n 00Ch 4 Frame Size (6FAh or 77Ah, sometimes 17Ah or 1FAh or 20Ah)\n 010h 2 Unknown (280h, or sometimes 300h or 340h)\n 012h 2 Frame Time (0=First, increases with step [19h], usually +5 or +7)\n 014h 2 Unknown (280h, or sometimes 300h or 3C0h, or 0)\n 016h 1 Frame Time (same as [012h] AND FFh)\n 017h 1 Unknown (0 or 1)\n 018h 1 Unknown (40h, or 80h, or C0h)\n 019h 1 Duration? (5 or 7, or sometimes less, step for Frame Time)\n 01Ah 1 Unknown (3, or less in last some frames)\n 01Bh 5 Zerofilled\n 020h 7E0h Data (increasing/decreasing bytes... maybe non-audio waveforms?)\n 000h 2 STR ID (0160h)\n 002h 2 STR Type (0000h=Custom)\n 004h 2 Sector number within current Frame (0..2)\n 006h 2 Number of Sectors in this Frame (always 4) (3xSTR + 1xADPCM)\n 008h 4 Frame Number (1=First)\n 00Ch 4 Frame Size? (800h, despite of having 3 sectors with 7E0h each?)\n 010h 2 Unknown (00h or 01h)\n 012h 2 Unknown (A3h or ABh ... 6Ch or 7Bh ... or 43h or 49h)\n 014h 2 Sector number within current Frame (0..2) (same as [004h])\n 016h 0Ah Zerofilled\n 020h 7E0h Data (polygon streaming or so?)\n Charumera ENDING.XA (with dummy/zero data)\n True Love Story TLS\\MULTI.XA (with nonzero data)\n True Love Story 2 TLS2\\ENDING.STR and TLS2\\MULTI.XA\n True Love Story Fan Disc ;\\probably use that format, too\n True Love Story: Remember My Heart ;/(not verified)\nThis game has normal MDEC Streams, and Special Streams in non-MDEC format (eg. Disc1, File 0E9h-16Eh and 985h-B58h), perhaps containing Polygon Streams or whatever. There are two channels (file=1/channel=00h-01h), each channel contains data that consists of 5 sectors per frame (1xHeader plus 4xData). The sectors have STR ID=0160h, and STR Type as follows:
0000h=Whatever special, channel 0 header (sector 0)\n 0400h=Whatever special, channel 1 header (sector 1)\n 0001h=Whatever special, channel 0 data (sector 2,4,6,8)\n 0401h=Whatever special, channel 1 data (sector 3,5,7,9)\n \\*.STR MDEC movies ;\\BS fraquant (except, demo version\n \\DATA*\\*.STR MDEC movies ;/ on MagDemo31 uses mormal BS v2)\n \\DATA*\\M*\\L*.STR Multi-language TXT files with STR header on each sector\n \\DATA*\\M*\\I*.STR unknown binary data (whatever and SPU-ADPCM)\n \\LANGN.STR unknown binary data (whatever)\nPSX Lightspan Online Connection CD, cdrom:\\CD.TOC:\\UI*\\.VAG PSX Wipeout 2097, cdrom:\\WIPEOUT2\\SOUND\\SAMPLES.WAD:\\.vag (version=02h) PSX Perfect Assassin, DATA.JFS:\\AUDIO\\.VAG and DATA.JFS:\\SND\\.VAG
000h 4 File ID (usually \"VAGp\")\n 004h 4 Version (usually 02h, or 20h) (big-endian)\n 008h 4 Reserved (0) (except when ID=\"VAGi\") (big-endian)\n 00Ch 4 Channel Size (data size... per channel?) (big-endian)\n 010h 4 Sample Rate (in Hertz) (eg. 5622h=22050Hz) (big-endian)\n 014h 0Ch Reserved (0) (except when version=2)\n 020h 10h Name (ASCII, zeropadded)\n ... (..) Optional ID string (eg. \"STEREO\" in upper/lowercase)\n ... (..) Optional Padding to Data start\n ... .. ADPCM Data for channel(s) (usually at offset 030h)\n .vag default (eg. many PSX games)\n .vig 2-channel with interleave=10h (eg. PS2 MX vs ATV Untamed)\n .vas 2-channel with interleave=10h (eg. PS2 Kingdom Hearts II)\n .swag 2-channel with interleave=filesize/2 (eg. PSP Frantix)\n .l and .r 2-channel in l/r files (eg. PS2 Gradius V, PS2 Crash Nitro Kart)\n .str whatever (eg. P?? Ben10 Galactic Racing)\n .abc whatever (eg. PSP F1 2009 (v6), according to wiki.xentax.com)\n \"VAGp\" default (eg. many PSX games)\n \"VAG1\" 1-channel (eg. PS2 Metal Gear Solid 3)\n \"VAG2\" 2-channel (eg. PS2 Metal Gear Solid 3)\n \"VAGi\" 2-channel interleaved (eg. ?)\n \"pGAV\" little endian with extended header (eg. PS2 Jak 3, PS2 Jak X)\n \"AAAp\" extra header, followed by \"VAGp\" header (eg. PS2 The Red Star)\n 00000000h v1.8 PC\n 00000002h v1.3 Mac (eg. PSX Wipeout 2097, in SAMPLES.WAD)\n 00000003h v1.6+ Mac\n 00000020h v2.0 PC (most common, eg. PSX Perfect Assassin)\n 00000004h ? (later games, uh when/which?)\n 00000006h ? (vagconf, uh when/which?)\n 00020001h v2.1 (vagconf2) ;\\with HEVAG coding instead SPU-ADPCM\n 00030000h v3.0 (vagconf2) ;/(eg. PS4/Vita)\n 40000000h ? (eg. PS2 Killzone) (1-channel, little endian header)\n 008h 4 Interleave (little endian) (the other header entries are big endian)\nThis does reportedly contain some default \"base\" settings for the PSX SPU:
014h 2 Volume left 4Eh,82h ;-Port 1F801C00h\n 016h 2 Volume right 4Eh,82h ;-Port 1F801C02h\n 018h 2 Pitch (includes fs modulation) A8h,88h ;-Port 1F801C04h +extra bit?\n 01Ah 2 ADSR1 00h,00h ;-Port 1F801C08h\n 01Ch 2 ADSR2 00h,E1h ;-Port 1F801C0Ah\n 01Eh 2 ? A0h,23h ;-Port 1F801C0xh maybe?\n 01Eh 1 Number of channels (0 or 1=Mono, 2=Stereo)\n 01Ch 2 Zero ;if non-zero: force Mono\n 01Eh 1 Number of channels (0 or 1=Mono, 2=Stereo ;if 10h..FFh: force Mono\n 01Fh 1 Zero ;if non-zero: force Mono\nThe ADPCM data uses PSX SPU-ADPCM encoding (even on PS2 and up, except PS4 with Version=0002001h or Version=00030000h, which do use HEVAG encoding). SPU ADPCM Samples The data does usually start at offset 0030h (except, some files have extra header data or padding at that location). The first 10h-byte ADPCM block is usually all zero (used to initialize the SPU). 2-channel (stereo) files are usually interleaved in some way.
"},{"location":"cdromfileformats/#vag-endiannes","title":"VAG Endiannes","text":"The file header entries are almost always big-endian (even so when used on little endian consoles). There are a few exceptions: ID=\"VAG1\" has little endian [008h]=Interleave (remaining header is big-endian). ID=\"pVAG\" has (some?) header entries in little endian. Version=40000000h has most or all header entries in little endian (perhaps including the version being meant to be 00000040h).
"},{"location":"cdromfileformats/#vag-channels","title":"VAG Channels","text":"VAGs can be 1-channel (mono) or 2-channel (stereo). There is no standarized way to detect the number of channels (it can be implied in the Filename Extension, Header ID, in Reserved Header entries, in the Name string at [020h..02Fh], in optional stuff at [030h], or in a separate VAG Header in the middle of the file).
"},{"location":"cdromfileformats/#vag-interleave","title":"VAG Interleave","text":" None default (for 1-channel mono) (and separate .l .r stereo files)\n 800h when ID=\"VAG2\"\n [008h] when ID=\"VAGi\" (little-endian 32bit header[008h])\n 1000h when ID=\"pGAV\" and [020h]=\"Ster\" and this or that\n 2000h when ID=\"pGAV\" and [020h]=\"Ster\" and that or this\n 10h when filename extension=\".vig\"\n 10h when Version=0002001h or Version=00030000h (and channels=2)\n filesize/2 when filename extension=\".swag\"\n 6000h when [6000h]=\"VAGp\" (eg. PSX The Simpsons Wrestling)\n 1000h when [1000h]=\"VAGp\" (eg. PS2 Sikigami no Shiro)\n ...\n 000h 4 ID \"AAAp\"\n 004h 2 Interleave\n 006h 2 Number of Channels (can be 1 or 2?)\n 008h 30h*N VAGp header(s) for each channel, with Version=00000020h\n ... .. ADPCM Data (interleaved when multiple channels)\nhttp://github.com/vgmstream/vgmstream/blob/master/src/meta/vag.c ;very detailed http://wiki.xentax.com/index.php/VAG_Audio ;rather incomplete and perhaps wrong
"},{"location":"cdromfileformats/#cdrom-file-audio-sample-sets-vab-and-vhvb-sony","title":"CDROM File Audio Sample Sets VAB and VH/VB (Sony)","text":""},{"location":"cdromfileformats/#vab-vs-vhvb","title":"VAB vs VH/VB","text":" .VAB contains VAB header, and ADPCM binaries ;-all in one file\n .VH contains only the VAB header ;\\in two separate files\n .VB contains only the ADPCM binaries ;/\n 0000h 4 File ID (\"pBAV\")\n 0004h 4 Version (usually 7) (reportedly 6 exists, too) (5, 20h exists)\n 0008h 4 VAB ID (usually 0)\n 000Ch 4 Total .VAB filesize in bytes (or sum of .VH and .VB filesizes)\n 0010h 2 Reserved (EEEEh)\n 0012h 2 Number of Programs, minus 1 (0000h..007Fh = 1..128 programs)\n 0014h 2 Number of Tones, minus? (max 0800h?) (aka max 10h per program)\n 0016h 2 Number of VAGs, minus? (max 00FEh)\n 0018h 1 Master Volume (usually 7Fh)\n 0019h 1 Master Pan (usually 40h)\n 001Ah 1 Bank Attribute 1 (user defined) (usually 00h)\n 001Bh 1 Bank Attribute 2 (user defined) (usually 00h)\n 001Ch 4 Reserved (FFFFFFFFh)\n 0020h 800h Program Attributes 10h-byte per Program 00h..7Fh (fixed size)\n 0820h P*200h Tone Attributes 200h-byte per Program 00h..P-1 (variable size)\n xx20h 200h 16bit VAG Sizes (div8) for VAG 00h..FFh (fixed size)\n xx20h (...) ADPCM data (only in .VAB files, otherwise in separate .VB file)\n 000h 1 tones Number of Tones in the Program (Yaroze: 4) (uh?)\n 001h 1 mvol Master Volume (Yaroze: 0..127)\n 002h 1 prior (Yaroze: N/A)\n 003h 1 mode (Yaroze: N/A)\n 004h 1 mpan Master Panning (Yaroze: 0..127)\n 005h 1 reserved0\n 006h 2 attr (Yaroze: N/A)\n 008h 4 reserved1\n 00Ch 4 reserved2\n 000h 1 prior Tone Priority (Yaroze: 0..127, 127=highest)\n 001h 1 mode Mode (Yaroze: 0=Normal, 4=Reverberation)\n 002h 1 vol Tone Volume (Yaroze: 0..127)\n 003h 1 pan Tone Panning (Yaroze: 0..127)\n 004h 1 center Centre note (in semitone units) (Yaroze: 0..127)\n 005h 1 shift Centre note fine tuning (Yaroze: 0..127)\n 006h 1 min Note limit minimum value (Yaroze: 0..127)\n 007h 1 max Note limit maximum value (Yaroze: 0..127)\n 008h 1 vibW (Yaroze: N/A)\n 009h 1 vibT (Yaroze: N/A)\n 00Ah 1 porW (Yaroze: N/A)\n 00Bh 1 porT (Yaroze: N/A)\n 00Ch 1 pbmin Max? value for downwards pitchbend (Yaroze: 0..127)\n 00Dh 1 pbmax Max value for upwards pitchbend (Yaroze: 0..127)\n 00Eh 1 reserved1\n 00Fh 1 reserved2\n 010h 2 ADSR1 Attack,Decay (Yaroze: 0..127,0..15)\n 012h 2 ADSR2 Release,Sustain (Yaroze: 0..127,0..31)\n 014h 2 prog Program number that tone belongs to (Yaroze: 0..127)\n 016h 2 vag VAG number (Yaroze: 0..254)\n 018h 8 reserved\nThis can contain max 254 \"VAG files\" (maybe because having two (?) reserved 8bit numbers?). Sony wants the total size of the ADPCM data to be max 7E000h bytes (which would occupy most of the 512Kbyte SPU RAM, leaving little space for the echo buffer or additional effects). Note: The \"VAG files\" inside of VAB/VB are actually raw SPU-ADPCM data, without any VAG file header. The first 10h-byte ADPCM block is usually zerofilled.
"},{"location":"cdromfileformats/#cdrom-file-audio-sequences-seqsep-sony","title":"CDROM File Audio Sequences SEQ/SEP (Sony)","text":""},{"location":"cdromfileformats/#seq-single-sequence","title":"SEQ - Single Sequence","text":".SEQ contains MIDI-style sequences, the samples for the instruments can be stored in a separate .VAB file (or .VH and .VB files). Used by Perfect Assassin, DATA.JFS:\\SND\\*.SEQ (bundled with *.VH and *.VB) Used by Croc (MagDemo02: CROC\\CROCFILE.DIR\\AMBI*.BIN, MAP*.BIN, JRHYTHM.BIN) Used by many other games.
000h 4 File ID \"pQES\"\n 004h 4 Version (1) (big endian?)\n 008h 2 Resolution per quarter note (01h,80h)\n 00Ah 3 Tempo 24bit (8bit:16bit maybe?) (07h,27h,0Eh)\n 00Dh 2 Rhythm (NN/NN) (04h,02h)\n 00Fh ... Score data, uh? (with many MIDI KeyOn's: xx,9x,xx,xx)\n ... 3 End of SEQ (2Fh=End of Track) (FFh,2Fh,00h)\nThis is a simple \"archive\" with several SEQ-like sequences.
000h 4 File ID \"pQES\" ;same ID as in .SEQ files (!)\n 004h 2 Version (0) ;value 0, and only 16bit, unlike .SEQ files\n 006h .. 1st Sequence\n ... .. 2nd Sequence\n ... .. etc.\n 000h 2 Sequence ID (0000h and up) (big endian) ;-ID number\n 002h 2 Resolution per quarter note (01h,80h) ;\\\n 004h 3 Tempo 24bit (07h,27h,0Eh) ; as in SEQ files\n 007h 2 Rhythm (NN/NN) (04h,02h) ;/\n 009h 4 Data size (big endian, from 00Dh up to including End of SEQ(\n 00Dh ... Score data, uh? (...) ;\\as in SEQ files\n ... 3 End of SEQ (2Fh=End of Track) (FFh,2Fh,00h) ;/\nThis is a newer Sony format from 1999 (resembling the older .SEQ .VH .VB format). Used by Alundra 2, Ape Escape, Arc the Lad 3, Koukidou Gensou - Gunparade March, Omega Boost, PoPoLoCrois Monogatari II, The Legend of Dragoon, Wild Arms 2.
.SQ Sequence Data (with ID \"SSsq\")\n .HD Voice Header (with ID \"SShd\")\n .BD Voice Binary (raw SPU-ADPCM, same as .VB)\n 000h 2 Unknown (always 64h)\n 002h 2 Unknown (always 1E0h)\n 004h 1? Unknown (varies)\n 005h 7 Zerofilled\n 00Ch 4 ID \"SSsq\"\n 010h 10h*10h Unknown Table\n 110h .. Unknown Data\n 000h 4 Size of the .HD file itself\n 004h 4 Size of the corresponding .BD file\n 008h 4 Zero\n 00Ch 4 ID \"SShd\"\n 010h 1Ch*4 Offsets to data (or FFFFFFFFh=None)\n 080h .. Data\n 000h .. SPU-ADPCM data (usually starting with zerofilled 10h-byte block)\nThere are four four file types:
\"DNSa\" (aka SouND backwards) ;sequence data\n \"PMSa\" (aka SaMPles backwards) ;samples with small header\n \"FMSa\" (aka SaMples-F... backwards) ;samples with bigger header ;\\Legacy\n \"FNSa\" (aka SouNd-F... backwards) ;whatever tiny file ;/of Kain\n Akuji (MagDemo18: AKUJI\\BIGFILE.DAT\\*) (DNSa,PMSa)\n Gex 2 (MagDemo08: GEX3D\\BIGFILE.DAT\\*) (DNSa)\n Gex 3: Deep Cover Gecko (MagDemo20: G3\\BIGFILE.DAT\\*) (DNSa,PMSa)\n Legacy of Kain 2 (MagDemo13: KAIN2\\BIGFILE.DAT\\*) (DNSa)\n Legacy of Kain 2 (MagDemo26: KAIN2\\BIGFILE.DAT\\*) (DNSa,PMSa,FNSa,FMSa)\n Walt Disney World Racing Tour (MagDemo35: GK\\BIGFILE.DAT\\*) (DNSa,PMSa)\n 000h 4 ID \"PMSa\"\n 004h 4 Total Filesize\n 008h 8 Zerofilled\n 010h .. SPU-ADPCM data (usually starting with zerofilled 10h-byte block)\n 000h 4 ID \"DNSa\" ;aka SND backwards\n 004h 2 Offset from DNSa+4 to 8-byte entries (can be odd)\n 006h 1 Unknown (3)\n 007h 1 Number of 8-byte entries (N1)\n 008h 1? Number of 10h-byte entries (N2)\n ... .. Unknown (..)\n ... N1*8 Whatever 8-byte entries\n ... N2*10h Whatever 10h-byte entries\n ... .. ... circa 40h 4-byte entries...?\n ... .. Unknown (..)\n ... .. Several blocks with ID \"QESa\" or \"QSMa\" ;supposedly MIDI-style?\nThese are whatever tiny files (with filesize 1Ch or 2Ch).
000h 4 ID \"FNSa\"\n ... .. Unknown\n 000h 4 ID \"FMSa\"\n 008h .. Unknown..\n ... .. SPU-ADPCM data (usually starting with zerofilled 10h-byte block)\nThere a several games that have sound files with ID \"AKAO\".
XXX does that include different AKAO formats... for Samples and Midi?\nAlone in the Dark IV has MIDB and DSND chunks (which contain sound files).
"},{"location":"cdromfileformats/#see-also_1","title":"See also","text":"The page below does mention several PSX sound formats, plus some open source & closed source tools for handling those files. https://github.com/loveemu/vgmdocs/blob/master/Conversion_Tools_for_Video_Game_Music.md
"},{"location":"cdromfileformats/#cdrom-file-audio-streaming-xa-adpcm","title":"CDROM File Audio Streaming XA-ADPCM","text":""},{"location":"cdromfileformats/#audio-streaming-xa-adpcm","title":"Audio Streaming (XA-ADPCM)","text":"Audio streaming is usually done by interleaving the .STR or .BS file's Data sectors with XA-ADPCM audio sectors (the .STR/.BS headers don't contain any audio info; because XA-ADPCM sectors are automatically decoded by the CDROM controller). Raw XA-ADPCM files (without video) are usually have .XA file extension.
"},{"location":"cdromfileformats/#cdrom-file-audio-cd-da-tracks","title":"CDROM File Audio CD-DA Tracks","text":"The eleven .SWP files in Wipeout 2097 seem to be CD-DA audio tracks. The one TRACK01.WAV in Alone in the Dark, too? Other than that, tracks can be accessed via TOC instead of filenames.
"},{"location":"cdromfileformats/#cdrom-file-archives-with-filename","title":"CDROM File Archives with Filename","text":""},{"location":"cdromfileformats/#entrysize08h","title":"Entrysize=08h","text":""},{"location":"cdromfileformats/#wwf-smackdown-magdemo33-taipac","title":"WWF Smackdown (MagDemo33: TAI\\*.PAC)","text":" 000h 4 ID (\"DPAC\") ;\\\n 004h 4 Unknown (100h) ;\n 008h 4 Number of files (N) ;\n 00Ch 4 Directory Size (N*8) ; Header\n 010h 4 File Data area size (SIZE = Totalsize-Headersize) ;\n 014h 4 Unknown (1) ;\n 018h 7E8h Zerofilled (padding to 800h-byte boundary) ;\n 800h N*8 File List ;\n ... .. Zerofilled (padding to 800h-byte boundary) ;/\n ... SIZE File Data area ;-Data area\n File List entries:\n 000h 8 Filename (\"NAME\")\n 004h 2 File Offset/800h (increasing)\n 006h 2 File Size/800h\nRESHEAD.BIN:
000h N*10h File List (220h bytes)\n File List entries:\n 000h 8 Filename (\"FILENAME\", if shorter: terminated by 00h plus garbage)\n 008h 4 Filesize in bytes\n 00Ch 4 Offset/800h in RESBODY.BIN (increasing) (or FFFFFFFFh if Size=0)\n 000h .. File Data (referenced from RESHEAD.BIN)\n 000h N*10h File List\n ... .. File Data area\n File List entries:\n 000h 0Ch Filename (eg. \"FILENAME 001\") ;for last entry: \"END 000\"\n 00Ch 4 Offset (increasing, N*10h and up) ;for last entry: zero\nMCD.DIR:
000h N*10h File List\n ... 10h End marker (FFh-filled)\n File List entries:\n 000h 8 Filename (zeropadded if less than 8 chars)\n 008h 2 Zero (0000h)\n 00Ah 2 Size/800h\n 00Ch 4 Offset/800h in MCD.IMG\n Note: Filenames are truncated to 8 chars (eg. \"FOREST.T\" instead \"FOREST.TIM\")\n 000h .. File Data area (encrypted in True Love Story 2)\n init_key_by_filename(name): ;for MCD.IMG (using filenames from MCD.DIR)\n i=0, key0=0001h, key1=0001h, key2=0001h\n while i<8 and name[i]<>00h\n key0=(key0 XOR name[i])\n key1=(key1 * name[i]) AND FFFFh\n key2=(key2 + name[i]) AND FFFFh\n ret\n init_key_by_numeric_32bit_seed(seed): ;maybe for LINEAR.IMG and PICT.IMG ?\n key0=(seed) AND FFFFh\n key1=(seed - (seed*77975B9h/400000000h)*89h) AND FFFFh\n key2=(seed - (seed*9A1F7E9h/20000000000h)*3527h) AND FFFFh\n ret\n decrypt_data(addr,len):\n for i=1 to len/2\n key2=key2/2 + (key0 AND 1)*8000h\n key0=key0/2 + (key1 AND 1)*8000h\n key1=key1/2 + ((key1/2 OR key0) AND 1)*8000h\n key0=((((key1+47h) AND FFFFh)/4) XOR key0)+key2+(((key1+47h)/2) AND 1)\n halfword[addr]=halfword[addr] XOR key0, addr=addr+2\n ret\n Item Unencrypted Encrypted\n Parent Folder name \"TLS\" \"TLS2\"\n First name in MCD.DIR \"BACKTILE\" \"TEST.RPS\"\n First word in MCD.IMG 00000010h 074D4C8Ah\nThe Rebel RESOURCE.* files start with name \"bigEx\" or \"fOFS\", BallBlazer *.DAT start with \"SFXbase\" or \"tpage\", nested files start with whatever other names.
000h N*10h File List\n ... (4) CRC32 on above header (Top-level only, not in Nested archives)\n ... .. File Data area\n ... (..) Huge optional padding to xx000h-byte boundary (in BallBlazer .DAT)\n File List entries in Top-level archives (with [0Ch].bit31=1):\n 000h 8 Filename (zeropadded if less than 8 chars)\n 008h 4 Decompressed Size (or 0=File isn't compressed)\n 00Ch 4 Offset, self-relative from current List entry (plus bit31=1)\n File List entries in Nested archives (with [0Ch].bit31=0):\n 000h 0Ch Filename (zeropadded if less than 12 chars)\n 00Ch 4 Offset, self-relative from current List entry (plus bit31=0)\n Last File List entry has [00h..0Bh]=zerofilled, and Offset to end of file.\n 000h .. Uncompressed Data\n ... .. CRC32 on above Data (Top-level only, not in Nested archives)\n 000h 1 Compression Method (01h=LZ/16bit, 02h=LZ/24bit)\n 001h 3 Decompressed Size (big-endian)\n 004h .. Compressed Data\n ... .. Zeropadding to 4-byte boundary\n ... .. CRC32 on above bytes (method, size, compressed data, padding)\n 000h 4 Number of files (big endian)\n 004h N*14h File List\n ... .. File Data\n 000h 0Ch Filename (\"FILENAME.EXT\", zeropadded if shorter than 12 chars)\n 00Ch 4 Filesize in bytes (can be odd) (big endian)\n 010h 4 Fileoffset in bytes (increasing, 4-byte aligned) (big endian)\n 0000h 2000h Folder 1\n 2000h .. File Data for Folder 1\n ... 2000h Folder 2\n ... .. File Data for Folder 2\n ... 2000h Folder End marker (FFFFFFFFh, plus zeropadding)\n 0000h 4 Folder ID (increasing, 1,2,3, or FFFFFFFFh=End)\n 0004h 4 Number of files (max 198h) (N)\n 0008h 4 File Data Area size/800h (S)\n 000Ch 4 Zero (0)\n 0010h N*14h File List\n ... .. Zeropadding to 2000h\n 2000h S*800h File Data Area for this folder\n 000h 4 Filesize in bytes\n 004h 10h Filename (FILENAME.EXT, zeropadded)\nThese are child archives found inside of the main GT-ARC and DATA.DAT archives.
000h 4 Number of Files (eg. 26h) (usually at least 02h or higher)\n 004h N*14h File List\n ... .. File Data area\n File List entries:\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded if shorter)\n 010h 4 Offset in bytes (increasing, 4-byte-aligned?)\n DIR:\n 000h 4 Number of Entries (0Eh)\n 004h N*14h File List\n DAT:\n 000h .. File Data (referenced from CROCII.DIR)\n 000h 0Ch Filename (\"FILENAME.EXT\", zeropadded if shorter)\n 00Ch 4 File Size in bytes\n 010h 4 File Offset in .DAT file (800h-byte aligned, increasing)\n 000h N*14h File List\n ... 14h Zerofilled (File List end marker)\n ... .. File Data area\n File List entries:\n 000h 0Ch Filename (\"FILENAME.EXT\", zeropadded if shorter)\n 00Ch 4 Offset (increasing, 4-byte aligned)\n 010h 4 Filesize in bytes (can be odd, eg. for .FA2 files)\n 000h N*14h File List (3Ch*14b bytes, unused entries are zeropadded)\n 4B0h .. Data area (TIM files for player uniforms)\n File List entries:\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 010h 4 Offset (zerobased, from begin of Data area, increasing)\n 000h 0Ch Fixed ID (always \"KotJCo01Dir \") (always that same string)\n 00Ch 4 Number of Files\n 010h N*18h File List\n ... .. File Data area\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 010h 4 Offset in bytes (increasing, 1-byte or 4-byte aligned)\n 014h 4 Filesize in bytes (can be odd)\n 000h N*18h File List (18h-bytes each)\n ... 18h File List end marker (zerofilled)\n ... .. File Data\n 000h 1 Filename Checksum (sum of bytes at [001h..00Dh])\n 001h 1 Filename Length (excluding ending zeroes) (eg. 8, 9, 10, 12)\n 002h 0Ch Filename (\"FILENAME.EXT\", zeropadded if less than 12 chars)\n 00Eh 2 Unknown (2000h) (maybe attr and/or ending zero for filename)\n 010h 4 Filesize in bytes (can be odd)\n 014h 4 Offset (increasing, 4-byte aligned)\n 000h 4 Header Size in bytes (2800h) (can be MUCH bigger than needed)\n 004h 4 Zero\n 008h 4 ID \"Indx\"\n 00Ch 4 Zero\n 010h 4 Number of Files (N) (CEh) (can be zero=empty in .IDX files)\n 014h 4 Header Size/800h (05h)\n 018h 4 Zero\n 01Ch 4 Zero\n 020h N*18h File List\n ... .. Zeropadding to end of Headersize\n ... .. File Data area\n 000h 0Ch Filename (\"FILENAME.EXT\", zeropadded if shorter)\n 00Ch 4 Offset/800h\n 010h 4 File Size/800h\n 014h 4 File Size in bytes\n IDX files use the same File List entry format as LVL, but the offsets\n seem to refer to an external file with corresponding name, for example:\n cdrom:\\ABE2\\CR.LVL\\CR.IDX ;directory info\n cdrom:\\ABE2\\CR.MOV ;external data (the .MOV being a .STR video)\n XXX: That's not tested/verified, and not implemented in no$psx file viewer.\n 000h 4 Unknown (6)\n 004h 4 Total Filesize (1403800h)\n 008h 2 Unknown, Alignment? (800h)\n 00Ah 2 Number of Files, excluding zerofilled File List entries (ACh)\n 00Ch 4 Header Size (1800h)\n 010h 4 Unknown, Entrysize? (18h)\n 014h 4 Unknown, Entrysize? (18h)\n 018h N*18h File List (can contain unused zerofilled entries here and there!)\n ... .. File Data area\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 010h 4 File Offset in bytes (800h-byte aligned, unusorted/not increasing)\n 014h 4 File Size in bytes\n 000h 4 ID \"KGB\",00h\n 004h 4 Number of Files (N)\n 008h (4) Number of Files negated (-N) ;<-- optional, not in LITESHOW.KGB\n ... N*18h File List\n ... (..) CBh-padding to alignment boundary (only if align=800h)\n ... .. File Data area\n 000h 10h Filename (\"FILENAME.EXT\", terminated by 00h, padded with CDh)\n 010h 4 File Size in bytes\n 014h 4 File Offset (800h-byte or 1/4-byte? aligned)\n 000h 4 Unknown (80000001h)\n 004h 4 Offset/800h to Final Padding area\n 008h 8 Zerofilled\n 010h N*18h File List\n ... (..) CDh-padding to 800h-byte alignment boundary\n ... .. File Data area\n ... 800h Some text string talking about \"last-sector bug\"\n ... 40BEh Final Padding area (CDh-filled)\n 000h 10h Filename (\"FILENAME.EXT\", terminated by 00h, padded with CDh)\n 010h 4 File Offset/800h (increasing)\n 014h 4 File Size/800h\n 000h 0Fh ID (\"Art\", zeropadded) ;\\\n 00Fh 1 Type or so (\"?\") ; sorts of File List entry\n 010h 4 Number of entries plus 1 (N+1) ; for root folder\n 014h 4 Total Size in bytes (can be odd) ;/\n 018h N*18h File List\n ... ... File Data area\n File List entries:\n 000h 0Fh Filename (\"FILENAME\", zeropadded)\n 00Fh 1 Type/extension or so (\"X\" or \"D\")\n 010h 4 File Offset (unaligned, increasing)\n 014h 4 File Size in bytes (can be odd)\n 000h 4 Unknown (301h)\n 004h 4 Zero (0)\n 008h 4 Number of files (N)\n 00Ch N*18h File List\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n File List entries:\n 000h 4 Offset (800h-byte aligned, increasing)\n 004h 4 Filesize in bytes\n 008h 1 Unknown (01h)\n 009h 0Fh Filename (\"FILENAME.EXT\",00h, plus garbage padding)\n Texsize is 6900Eh, but should be 6900Ch = 200h*1A4h*2+0Ch\n Filesize is 6A000h, but should be 69014h = 200h*1A4h*2+14h\n 000h 2 Number of Files (C9h)\n 002h N*18h File List\n ... (..) Padding to 800h-byte boundary (if any, eg. in MOVIES.LIB)\n ... .. File data area (800h-byte aligned, or unaligned)\n File List entries:\n 000h 4 Filesize in bytes\n 004h 4 Offset (increasing, 800h-byte aligned, or unaligned)\n 008h 10h Filename (\"filename.ext\", zeropadded)\n 000h 4 ID \"DCAT\"\n 004h 4 Number of Entries\n 008h N*18h File List\n ... .. Zerofilled (padding to 800h-byte boundary)\n ... .. File Data area\n File List entries:\n 000h 10h Filename (\"FILENAME.EXT\", terminated by 00h, plus garbage padding)\n 010h 4 Filesize in bytes\n 014h 4 Offset (increasing, 800h-byte aligned)\n 000h 4 ID \"FRID\"\n 004h 4 Always E0000000h\n 008h 4 Always 800h (...maybe alignment)\n 00Ch 4 Number of Entries (N)\n 010h 4 Header Size (N*18h+20h, plus padding to 800h-byte boundary)\n 014h 4 Always 18h (...maybe entry size)\n 018h 8 Zerofilled\n 020h N*18h File List\n ... .. Zerofilled (padding to 800h-byte boundary)\n ... .. File Data area\n File List entries:\n 000h 0Ch Filename (\"FILENAME.EXT\", zeropadded if shorter)\n 00Ch 4 Offset (increasing, 800h-byte aligned)\n 010h 4 Filesize in bytes\n 014h 4 Unknown (checksum? random?)\n 000h N*18h File List\n ... .. File Data area (directly after File List, without end-code)\n Note: There is no file-list end-marker (instead, the Offset in 1st File\n entry does imply the end of File List).\n File List entries:\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 010h 4 Offset (increasing, 4-byte aligned, or unaligned for TXT files)\n 014h 4 Filesize in bytes (or weird nonsense in SFX.MAD)\n SFX.MAD has nonsense Filesize entries (eg. 164h for a 15150h-byte file).\n FACES.MAD contains only one TIM file... but as 3Mbyte junk appended?\n RINKS.MAD and TEAMS.MAD start with 0Dh,0Ah,1Ah followed by 4Mbyte junk.\n MISCFILE.MAD contains several nested .mad files.\n MISCFILE.MAD\\panfont.mad\\*.txt --> starts with FF,FE --> that's 16bit Unicode?\n INF:\n 000h N*18h File List\n WAD:\n 000h .. File Data area\n 000h 4 File Offset/800h in .WAD file\n 004h 4 File Size in bytes\n 008h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 000h 4 Number of entries (N)\n 004h N*18h File List\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n File List entries:\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 010h 4 Fileoffset (800h-byte aligned, increasing)\n 014h 4 Filesize in bytes\n 000h 2 Type (31h=TPF with TIMs, 32=PPF with PMDs)\n 002h 2 Number of entries (N) (can be 0=None, eg. STAGE*\\MORT.PPF)\n 004h 4 File List Size (N*18h)\n 008h 4 Header Size (always 14h)\n 00Ch 4 Data area Size (Filesize-14h-N*18h)\n 010h 4 Data area Offset (14h+N*18h)\n 014h N*18h File List\n ... .. File Data area\n File List entries:\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 010h 4 Filesize in bytes\n 014h 4 Fileoffset (from begin of Data area, increasing)\n 000h 4 ID \"BACR\" (aka RCAB backwards)\n 004h 4 Number of entries (N)\n 008h N*18h File List\n ... .. File Data area\n File List entries:\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 020h 4 Offset (from begin of Data area, increasing, 4-byte aligned)\n 024h 4 Filesize in bytes (can be odd)\nPSX Wipeout 2097, cdrom:\\WIPEOUT2\\SOUND\\SAMPLES.WAD:\\.vag PSX Wipeout 2097, cdrom:\\WIPEOUT2\\TRACK*\\TRACK.WAD:\\.* PSX Wipeout 3 (MagDemo25: WIPEOUT3\\*)
000h 2 Number of files\n 002h N*19h Directory Entries for all files\n ... .. Data for all files (without any alignment, in same order as above)\n 000h 10h Filename (ASCII, can be lowercase), terminated by 00h, plus garbage\n 010h 4 Filesize in bytes ;\\maybe compressed/uncompressed, or rounded,\n 014h 4 Filesize in bytes ;/always both same\n 018h 1 Unknown (always 00h)\n 000h 4 Number of entries with location 0=MIX (M=65h)\n 000h 4 Number of entries with location 1=XA (X=1)\n 008h M*1Ch File List for location 0=MIX\n ... X*1Ch File List for location 1=XA\n 000h 10h Filename (terminated by 00h, padded with garbage)\n 010h 4 Offset/800h in DATA.MIX or Offset/930h DATA.XA file (increasing)\n 014h 4 Filesize in bytes\n 018h 4 File Location (0=DATA.MIX, 1=DATA.XA)\n 000h 4 Unknown (80000001h)\n 004h 4 Offset/800h to Final Padding area\n 008h 8 Zerofilled\n 010h N*1Ch File List\n ... (..) CDh-padding to 800h-byte alignment boundary\n ... .. File Data area\n ... 3394h Final Padding area (CDh-filled)\n 000h 14h Filename (\"FILENAME.EXT\", terminated by 00h, padded with CDh)\n 014h 4 File Offset/800h (increasing)\n 018h 4 File Size/800h\n v1 (Syphon Filter 1) has filename_len=10h (and filelist_entrysize=18h)\n v2 (Syphon Filter 2) has filename_len=14h (and filelist_entrysize=1Ch)\n 000h 4 Number of Files\n 004h N*20h File List\n ... 10h File List End: Name (zerofilled)\n ... 4 File List End: Offset (total filesize, aka end of last file)\n ... 0Ch File List End: Padding (zerofilled)\n ... .. File Data area\n 000h 10h Filename (\"FILENAME.EXT\", terminated by 00h, padded with garbage)\n 010h 4 File Offset in bytes (increasing, 4-byte aligned)\n 014h 0Ch Padding (garbage) (usually 800F68A0h,800F68A0h,800F68A0h)\n 000h 4 Number of Files (1C3h)\n 004h N*20h File List\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded, sorted alphabetically)\n 010h 4 File Offset/800h (unsorted, not increasing)\n 014h 4 File Size in bytes\n 018h 4 File Size/800h\n 01Ch 4 Zero\n 000h N*20h File List\n ... 4 File List End Offset/800h (end of last file)\n ... 4 File List End Size (zero)\n ... 18h File List End Name (zerofilled)\n ... .. Padding to 800h-byte boundary (each 20h-byte: 01h, and 1Fh zeroes)\n ... .. File Data\n 000h 4 Offset/800h (increasing)\n 004h 4 Filesize in bytes\n 008h 18h Filename (\"FILENAME.EXT\" or \":NAME\" or \":NAME:NAME\", zeropadded)\nAbout same as the other Test Drive games, but with shorter filenames.
000h N*20h File List (1920h bytes used; with padding: 5800h bytes in total)\n ... .. Zeropadding to Headersize (5800h)\n ... .. File Data area\n File List entries:\n 000h 18h Filename (\"FILENAME.EXT\" or \"PATH\\FILENAME.EXT\", zeropadded)\n 018h 4 Filesize in bytes\n 01Ch 4 File (Offset-Headersize)/800h\n 000h 4 ID (\"TDSK\") ;\\\n 004h 4 Number of Files (1Bh) ; Directory\n 008h N*20h File List ;/\n ... 4 1st File Size (same as Size entry in File List) ;\\File Data area\n ... .. 1st File Data ; (each file os\n ... 4 2nd File Size (same as Size entry in File List) ; preceeded by\n ... .. 2nd File Data ; a size entry)\n ... .. etc. ;/\n File List entries:\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 010h 4 File Size in bytes\n 014h 4 Unknown (35xxxxxxh..372xxxxxh)\n 018h 4 Unknown (3724xxxxh) (Timestamp maybe?)\n 01Ch 4 File Offset in bytes (increasing, 4-byte aligned)\n 000h N*20h File List (B60h bytes)\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area (files are AAh-padded to 800h-byte boundary)\n File List entries:\n 000h 4 Filesize in bytes\n 004h 2 File Offset/800h (16bit) (increasing)\n 006h 1Ah Filename (\"FILENAME.EXT\" or \"PATH\\FILENAME.EXT\", zeropadded)\n 000h 2 Zero (0000h)\n 002h 2 Number of Files (N)\n 004h 4 Data Base (N*20h+10h)\n 008h 4 Unknown (20h) ;-maybe File List entry size?\n 00Ch 2 Unknown (10h) ;\\maybe filename length and/or header size?\n 00Eh 2 Unknown (10h) ;/\n 010h N*20h File List\n ... .. File Data area\n 000h 4 Zero\n 004h 4 File Offset (increasing, 4-byte aligned, relative to Data Base)\n 008h 4 File Size in bytes (can be odd)\n 00Ch 4 Zero\n 010h 10h Filename (\"FILENAME.EXT\", zeropadded)\n WAD:\n 000h N*20h File List\n STR:\n 000h .. File Data (MagDemo39: 4.5Mbyte, MagDemo48: compressed/2.8Mbyte)\n File List entries:\n 000h 14h Filename (\"FILENAME.EXT\", zeropadded)\n 014h 4 Offset in bytes, 4-byte aligned, in STR file\n 018h 4 Filesize, compressed (always rounded to multiple of 4 bytes)\n 01Ch 4 Filesize, decompressed (zero when not compressed)\n - end flag is processed immediately (instead of after the block)\n - blocktype is only 1bit wide (instead of 2bit)\n - stored blocks have plain 16bit len (without additional 16bit inverse len)\n bmx_tinf_style_uncompress(dst,src)\n tinf_init() ;init constants (needed to be done only once)\n @@lop:\n if tinf_getbit()=0 then goto @@done ;end flag, 1bit\n if tinf_getbit()=0 then ;blocktype, 1bit\n tinf_align_src_to_byte_boundary()\n len=LittleEndian16bit[src], src=src+2 ;get len (without inverse len)\n for i=0 to len-1, [dst]=[src], dst=dst+1, src=src+1, next i ;uncompressed\n else\n tinf_decode_dynamic_trees(), tinf_inflate_compressed_block() ;compressed\n gpto @@lop\n @@done:\n ret\nUsed on most PlayStation Magazine Demo Discs (Disc 03-54, except Disc 01-02) Used on PlayStation Underground 3.1 (and maybe other issues) Used on Interactive CD Sampler Disc Volume 10 (maybe others, but not Vol 4,5)
000h 4 Number of entries (eg. 20h or 28h)\n 004h N*28h File List\n ... .. Garbage padding to 800h-byte boundary\n ... .. File Data\n ... .. Huge zeropadding to 200000h or 2EE000h (2048Kbyte or 3000Kbyte)\n 000h 20h Filename (terminated by 00h, padded with... looks like garbage)\n 020h 4 Size/800h\n 024h 4 Offset/800h (increasing)\nThis is used by several games, with different Headersizes (2000h or 3000h or 5000h), with Offsets relative to the Headersize. To detect the Headersize, skip used entries, skip following zeropadding, then round-down to 800h-byte boundary (in case the 1st file contains some leading zeroes).
000h N*28h File List (less than 0C00h bytes used in TD4 demo)\n ... .. Zeropadding to Headersize (2000h or 3000h or 5000h)\n ... .. File Data\n 000h 20h Filename (\"PATH\\FILENAME.EXT\", zeropadded)\n 020h 4 Size in bytes\n 024h 4 (Offset-Headersize)/800h (increasing)\n 0000h N*28h File List\n 21C0h ... Unknown random gibberish? (23h,E8h,0Ch,1Dh,79h,C5h,24h,...)\n 4000h ... File Data area\n 000h 1Ch Filename (\"\\PATH\\FILENAME.EXT;0\", zeropadded)\n 01Ch 4 Filesize in bytes\n 020h 4 Fileoffset in bytes (4000h and up, increasing)\n 024h 4 Filechecksum (32bit sum of all bytes in the file)\n 000h 4 ID \"BIND\"\n 004h 4 Number of files (N)\n 008h N*28h File List\n ... .. File Data area\n 000h 20h Filename (\"\\FILENAME.EXT\", zeropadded)\n 020h 4 File Offset (increasing, 4-byte aligned) ;\\see note\n 024h 4 File Size in bytes (always a multiple of 4) ;/\n size=((filesize+3) AND not 3) ;size entry for curr file (plus 3)\n offs=((filesize+4) AND not 3)+offs ;offs entry for next file (plus 4 !!!)\n 000h 4 Number of entries (N)\n 004h 4 Number of entries (same as above)\n 008h 4 Number of entries (same as above)\n 00Ch 4 Number of entries (same as above)\n 010h N*28 File List\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n File List entries:\n 000h 20h Filename (\"\\PATH\\FILENAME.EXT\", zeropadded)\n 020h 4 Offset/800h, from begin of Data area (increasing)\n 024h 4 Filesize in bytes\n 000h 4 Number of Files\n 004h N*34h File List\n ... .. Zeropadding to 4000h\n 4000h .. File Data area\n File List entries:\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 010h 4 Filesize in bytes ;\\always both same, always\n 014h 4 Filesize in bytes ;/both multiple of 800h\n 018h 4 Zero\n 01Ch 4 Type (07h..1Ah)\n 020h 4 Subtype (00h..01h)\n 024h 10h Zero\n 07h.0 .TIM (*.TIM)\n 07h.01h .TIM (HUD_*.TIM)\n 08h.0 .TIM (PSTART.TIM)\n 09h.0 .TIM (FONT.TIM)\n 0Ah.0 .SFX\n 0Eh.0 .MBL\n 10h.0 .ATR\n 11h.0 .RLC\n 13h.0 .AST\n 15h.0 .SCD\n 16h.0 .TXT (PAUSED.TXT)\n 17h.0 .TXT (OBJECT*.TXT)\n 18h.0 .BIN\n 1Ah.0 Misc (.3DO=TIM, .V=TXT, and TERRAIN.CLP .HI .LIT .MAP .PAT .POB .TER)\n 000h 4 Number of Files (N)\n 004h 4 Size of File Data area (SIZ) (total filesize-8-N*40h)\n 008h N*40h File List\n ... SIZ File Data area\n File List entries:\n 000h 4 Filesize in bytes\n 004h 4 Fileoffset in bytes (zerobased, from begin of File Data area)\n 008h 38h Filename, zeropadded\n 000h 4 ID (\"GLUE\")\n 004h 4 Unknown (always 400h)\n 008h 4 Number of Files (N)\n 00Ch 4 Header Size (40h+N*40h)\n 010h 30h Zerofilled\n 040h N*40h File List\n ... .. Garbage padding to alignment boundary\n ... .. File Data area\n File List entries:\n 000h 20h Filename (\"FILENAME.EXT\", zeropadded)\n 020h 4 File Offset in bytes (increasing, 800h-byte aligned)\n 024h 4 File Size in bytes\n 028h 2 File ID Number 1 (eg. 1-71 for C01.GLU-C71.GLU)\n 02Ah 2 Unknown (random, checksum, ?)\n 02Ch 4 File ID Number 2 (eg. increasing: 1, 2, 3)\n 030h 10h Zerofilled\n 000h 4 Number of entries (N)\n 010h N*60h File List\n ... .. Zeropadding to 2000h\n 2000h .. File Data area\n File List entries:\n 000h 4 Timestamp? (BFxxxxh..C0xxxxh) (or zero, in first file)\n 004h 4 Unknown (always 421C91h)\n 008h 4 Unknown (200h or 60200h)\n 00Ch 4 Filesize (uncompressed)\n 010h 4 Filesize (compressed, or 0 when not compressed)\n 014h 4 File Checksum (sum of all bytes in uncompressed file data)\n 018h 4 Unknown (random 32bit value?)\n 01Ch 10h Filename (\"FILENAME.EXT\", zeropadded)\n 02Ch 4 Zerofilled\n 030h 4 Unknown (0 or 1 or 8)\n 034h 4 File Type (see below)\n 038h 8 Zerofilled\n 040h 4 Offset MSBs (Fileoffset-2000h)/800h ;\\increasing, 4-byte aligned\n 044h 4 Offset LSBs (Fileoffset AND 7FFh) ;/(or zero when filesize=0)\n 048h 18h Zerofilled\n 000h 4 ID (A69AA69Ah)\n 004h 4 Number of files (N)\n 008h N*90h File List\n ... .. File Data area\n File List entries:\n 000h 80h Filename (\"DATA\\FILENAME.EXT\",00h, plus CDh-padding)\n 080h 4 File Offset in bytes (increasing, 4-byte aligned)\n 084h 4 File Size in bytes\n 088h 8 Unknown (random/checksum?)\n Used by Spider-Man (MagDemo31,40: SPIDEY\\CD.HED and CD.WAD)\n Used by Spider-Man 2 (MagDemo52: SPIDEY\\CD.HED and CD.WAD)\n Used by Tony Hawk's Pro Skater (MagDemo22: PROSKATE\\CD.HED and CD.WAD)\n Used by Apocalypse (MagDemo16: APOC\\CD.HED and CD.WAD) ;with PADBUG\n Used by MDK (Jampack Vol. 1: MDK\\CD.HED and CD.WAD) ;without ENDCODE\n Used by Mat Hoffman's Pro BMX (old demo) (MagDemo39: BMX\\BMXCD.HED+WAD)\n 000h .. File Entries (see below)\n ... (1) End code (FFh) (if any, not present in MDK)\n 000h .. Filename (ASCII, terminated by 00h, zeropadded to 4-byte boundary)\n ... 4 Offset in CD.WAD (in bytes, usually 800h-byte aligned)\n ... 4 Filesize (in bytes)\n 000h 4 Number of Files (N) (1ADh)\n 004h 4 Unknown (7) (maybe HeaderSize/800h, same as first Offset/800h ?)\n 008h 4 Unknown (1430h = 14h+N*0Ch, same as first Name pointer)\n 00Ch 4 Unknown (1430h = 14h+N*0Ch, same as first Name pointer)\n 010h 4 Unknown (1430h = 14h+N*0Ch, same as first Name pointer)\n 014h N*4 Name List (pointers to name strings, 1430h and up) 6B4h bytes\n ... N*4 Size List (filesize in bytes) 6B4h bytes\n ... N*4 Offset List (Offset/800h) 6B4h bytes\n ... N*var Name Strings (ASCII strings, \"folder\\filename.ext\",00h)\n ... .. Zerofilled (padding to 800h-byte boundary)\n ... .. File Data area\n 000h 4 Number of Files (N)\n 004h N*8 File List (2x32bit entries: Offset, Size) (unaligned, can be odd)\n ... N*4 File Name Offsets\n ... N*var File Name Strings (\"FILE NN\",0Ah,00h)\n ... .. Garbage-padding to 4-byte boundary\n ... (4) Optional extra garbage? (\"MON \" in ATLANTFI.PAK, MARSFI.PAK, etc.)\n ... .. File Data area (ZLIB compressed, starting with big-endian 789Ch)\n 000h 4 ID (12h,34h,56h,78h) (aka 12345678h in big endian)\n 004h 4 Header Size (offset to File Data area)\n 008h 4 Number of Entries (can be 0=None, eg. LEVELS\\LARGO07.DCF\\Z16.CAT)\n 00Ch N*var Name List (Filenames in form \"FILENAME.EXT\",00h)\n ... .. Zeropadding to 4-byte boundary\n ... N*4 Size List (Filesizes in bytes)\n ... .. File Data area\n 000h 4 Number of files (N) (3..EBh) (big-endian)\n 004h N*Var File List (list size is implied in first file offset)\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n File List entries:\n 000h 4 File Type (ascii, .LLN .TXI .TPG .RCI .RCP .WDB .PCI .PCP .BLK)\n 004h 4 File Size (can be odd) (big-endian)\n 008h 4 File Offset (increasing, 800h-byte aligned) (big-endian)\n 00Ch 4 Extra Size (0 or 4 or 8) (big-endian)\n 010h .. Extra Data (if any) (32bit number, or \"TEXTURES\")\n 000h 4 Timestamp? (36xxxxxxh=v1?, 38xxxxxxh=v2?, other=SLF.RFF)\n 004h 4 Number of Files (N)\n 008h 4 Base for Offset List (always 14h)\n 00Ch 4 Base for String Table (v1=N*4+14h, or v2=N*4+18h)\n 010h 4 Base for File Data (end of String Table plus align 4/800h/920h)\n 014h N*4 Offsets to File(s) (increasing, first=0, relative to above [010h])\n ... (4) v2 only: End Offset for Last File (HOG filesize minus [010h])\n ... .. String Table (filename list in form of \"FILENAME.EXT\",00h)\n ... .. Zeropadding to 4-byte or 800h-byte boundary\n ... .. File Data area\n v1 has [0Ch]=N*4+14h (without end-of-last-file entry; use end=total_size)\n v2 has [0Ch]=N*4+18h (and does have end-of-last-file entry)\n v1 has STR files in ISO filesystem (not in HOG archives)\n v2 has STR files in MOVIES.HOG (with [10h]=920h and [14h and up]=sectors)\n v1/v2 has [10h]=data base, aligned to 4 or 800h\n v1/v2 has [14h and up] in BYTE-offsets, relative to base=[10h]\n v1/v2 uses HOG format in .HOG files also in SLF.RFF\n v1/v2 has further .RFF files (but that aren't in HOG format)\n v2 MOVIE.HOG has [10h]=920h (which is meant to mean base=\"after 1st sector\")\n v2 MOVIE.HOG has [14h and up] in SECTOR-units, with base=\"after 1st sector\"\n v2 SLF.RFF does contain two HOG archives badged together (plus final padding)\n v2 has some empty 0-byte .HOG files (at least so in demo version)\n 000h 4 ID \"BIGF\" (normal case, all big-endian, 4-byte aligned) ;\\\n ID \"BIGH\" (with [04h]=little-endian instead big-endian) ;\n ID \"BIG4\" (with 40h-byte alignment padding instead 4-byte) ;\n 004h 4 Sum of Header+Filesizes (excluding Padding's!) (big-endian) ; Header\n 008h 4 Number of entries (N) ;11h (big-endian) ;\n 00Ch 4 Size of Header (including File List) ;11Fh (big-endian) ;\n 010h .. File List ;/\n ... .. Padding to 1/4/8-byte boundary (optional, before each file) ;\\Data ... .. File Data ;/\n 000h 4 Offset in bytes (increasing, often 4/8-byte aligned) (big-endian)\n 004h 4 Size in bytes (can be odd, but often rounded to 4-byte) (big-endian)\n 008h .. Filename (ASCII, terminated by 00h) ;variable length\n Note: Filenames can be empty (\"\",00h) (eg. in WCWDEMO\\ZSOUND.BIG)\nhttp://wiki.xentax.com/index.php/EA_BIG_BIGF_Archive
Other Electronic Arts file formats (used inside or alongside big archives):
https://wiki.multimedia.cx/index.php/Electronic_Arts_Formats_(2) - BNK etc
"},{"location":"cdromfileformats/#electronic-arts-24bit-c0fb-archives","title":"Electronic Arts 24bit C0FB archives","text":" 000h 2 ID C0FBh (C0h,FBh) (big-endian) ;\\\n 002h 2 Size of Header-4 (00h,15h) (big-endian) ; Header\n 004h 2 Number of Files (00h,01h) (big-endian) ;\n 006h .. File List ;/\n 019h .. Padding to 4-byte boundary? ;-Padding\n 01Ch .. File Data ;-Data\n ... 4 \"CRCF\" ;\\\n ... 4 Unknown (0C,00,00,00) (chunk-size little-endian?) ; Footer\n ... 4 Unknown (3B,2E,00,00) (checksum maybe?) ;/\n 000h 3 Offset in bytes (increasing) ;(big-endian, 24bit)\n 004h 3 Size in bytes ;(big-endian, 24bit)\n 008h .. Filename (ASCII, terminated by 00h) ;variable length\n PTH File:\n 000h N*var File List\n DAT File:\n 000h .. File Data area\n 000h .. Filename (\"FILENAME.EXT\",00h) (variable length)\n ... 4 File Size in bytes (can be odd)\n ... 4 File Offset in bytes in DAT file (increasing, unaligned)\n TOC:\n 000h N*var File List\n IMG:\n 000h .. File Data area\n 000h .. Filename (\"DATA\\FILENAME.EXT\",00h) (variable length)\n ... 4 File Offset (increasing, 800h-byte aligned, in .IMG file)\n ... 4 File Size in bytes\n TGA[10h..11h] = 08h,08h ;bpp=8 (okay) and attr=8 (nonsense)\n TGA[10h..11h] = 10h,01h ;bpp=16 (okay) and attr=1 (okay) but it's yflipped\n 000h 4 Zero\n 004h 4 Number of Files (260h)\n 010h N*8 File entries\n ... .. Zeropadding to 800h byte boundary\n ... .. File Data\n 000h 4 Fileoffset/800h (increasing)\n 004h 4 Filesize in bytes\n MDEC v2 STR's (file 1E1h..1F8h,1FAh)\n TIM textures (file 01FBh..0200h and others)\n empty files (file 01F9h and others)\n small archives with named entries (file B5h,124h,125h,126h and others)\n stuff with date string and names (file 253h,256h)\n there seem to be no nested BIG files inside of the main BIG file\n 000h 4 Number of files (N) (eg. 196h)\n 004h 4 Unknown (always 0Bh) (maybe sector size shift?)\n 008h N*4 File List\n ... .. Zeropadding to 800h-byte boudary\n ... .. File Data\n 000h 2 Offset/800h (increasing)\n 002h 2 Size/800h (can be zero)\n 000h N*4 File List\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n File List entries:\n 000h 1 Size/800h (8bit)\n 001h 3 Offset/800h (24bit, increasing)\n 000h N*8 File List\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data\n ... .. Garbage padding (can be several megabytes tall)\n 000h 2 Offset/800h (increasing)\n 002h 2 Size/800h (same as below, rounded up to sector units)\n 004h 4 Size in bytes\nSimilar as .CDB archives (but with 32bit offset, and without duplicated size).
000h N*8 File List\n ... 4 File List end marker (00000000h)\n ... .. Garbage padding to 800h-byte boundary\n ... .. File Data\n 000h 4 Offset/800h (increasing)\n 004h 4 Size in bytes (often zero; for unused file numbers)\n 000h X*4 File List for BINPACK0.BIN ;\\\n ... .. Zeropadding ; BINPACK0\n 410h .. Unknown (some/all of it looks like garbage) ;/\n 800h Y*4 File List for BINPACK1.BIN ;\\\n ... .. Zeropadding ; BINPACK1\n C10h .. Unknown (some/all of it looks like garbage) ;/\n 000h 2 Offset/800h in BINPACK0.BIN or BINPACK1.BIN\n 002h 2 Size/800h\nResembles .BZE (in terms of duplicated size entry).
000h 4 Number of Files\n 004h 4 Size of File Data area (total filesize-N*0Ch-8)\n 008h N*0Ch File List\n ... .. File Data area\n 000h 4 Offset (zerobased, from begin of File Data area)\n 004h 4 Size in bytes\n 008h 4 Size rounded to mutiple of 4-bytes\n 000h 0Ch ID \"@(#)GT-ARC\",00h,00h\n 00Ch 2 Content Type (8001h=Compressed, 0001h=Uncompressed)\n 00Eh 2 Number of Files (eg. 0Fh)\n 010h N*0Ch File List\n ... .. File Data area\n File List entries:\n 000h 4 Offset in bytes (increasing, unaligned)\n 004h 4 Compressed File Size (can be odd) ;\\both same when uncompressed\n 008h 4 Decompressed File Size ;/(ie. when [00Ch]=0001h)\n 000h 4 Number of Files (N)\n 004h N*8 File List\n ... .. File Data area\n 000h 4 Offset in bytes (increasing, 1/4-byte? aligned)\n 004h 4 File Size in bytes (usually N*4, TXT's in ODT are padded as so)\nSame as in O.D.T. with extra \"DFS_\" ID at start of file.
000h 4 ID \"DFS_\" (with align 4) or \"DF2_\" (with align 800h)\n 004h 4 Number of Files (N)\n 008h N*8 File List\n ... .. File Data area\n File List entries:\n 000h 4 Fileoffset in bytes (4-byte or 800h-byte aligned, increasing)\n 004h 4 Filesize in bytes (can be odd, eg. in BUSTGR_A\\SELECT.BPE\\*)\nSame as DFS, but with Total Filesize instead of \"DFS_\".
000h 4 Total used filesize (excluding zeropadding to 2EE000h)\n 004h 4 Number of Files (N)\n 008h N*8 File List\n ... .. File Data area\n ... (..) In some files: Zeropadding to 2EE000h (3072Kbytes)\n 000h 4 Offset (increasing, 4-byte aligned, see note)\n 004h 4 Filesize in bytes (can be odd in Monaco)\n If (Size AND 3)=0 then NextOffset=Offset+Size ;Align4\n If (Size AND 3)>0 then NextOffset=Offset+Size+Align800h ;Align800h\n Namely, Monaco has files with Size=3BC5h.\n Rollcage 1 uses a single IMG file that contains both directory and data:\n 000h 4 Header offset (0) ;\\\n 004h 4 Header size (10h+N*10h) ; this seems to be a File List entry\n 008h 4 Header size (10h+N*10h) ; for the header itself\n 00Ch 4 Zero ;/\n 010h N*10h File List ;-File List for actual files\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n Number of files is \"IMG[04h]/10h\" (minus 1 for excluding the header itself)\n The other titles have seaparate IDX and IMG files for directory and data:\n SPEED.IDX = Directory (N*10h bytes File List with offsets into SPEED.IMG)\n SPEED.IMG = File data\n Number of files is \"Filesize(SPEED.IDX)/10h\"\n 000h 4 Fileoffset in bytes (800h-byte aligned, increasing)\n 004h 4 Filesize in bytes\n 008h 4 When compressed: GT20 Header [004h] (decompressed size)\n When uncompressed: Same as filesize\n 00Ch 4 When compressed: GT20 Header [008h] (overlap, usuallly 3, or 7)\n When uncompressed: Zero\n 000h 4 Number of Entries\n 004h N*0Ch File List\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n File List entries:\n 000h 4 Unknown (random/checksum?)\n 004h 4 File Offset (800h-byte aligned, increasing)\n 008h 4 File Size in bytes\n 000h N*0Ch File List (154h entries)\n ... N*4 Filename Checksums (?) (154h entries)\n ... .. Zerofilled (padding to 800h-byte boundary)\n ... .. File Data area\n 000h 4 Number of entries (including the 1st entry itself)\n 004h 4 Offset/800h (always 0, relative from begin of directory)\n 008h 4 Type (always 3=Directory)\n 000h 4 For Files: Size in bytes, for Directories: Number of entries\n 004h 4 Offset/800h (from begin of current directory, increasing)\n 008h 4 Type (0=File, 3=Directory)\n 000h 4 File ID (always 01h,02h,04h,08h)\n 004h 4 Maybe Version? (always 01h,00h,01h,00h)\n 008h 4 Header Size (18h+N*8+ArchiveNameLength) ;eg. 4ECh\n 00Ch 4 Sector Alignment (can be 4 or 800h)\n 010h 4 Number of Files (N) ;eg. 99h\n 014h 4 Length of Archive Name (including ending 00h)\n 018h N*8 File entries (see below)\n ... .. Archive Name, ASCII, terminated by 00h ;eg. \"bigfile.dir\",00h\n ... .. Zeropadding to Sector Alignment boundary\n ... .. File Data\n 000h 4 Fileoffset (with above Sector Alignment) (increasing)\n 004h 4 Filesize in bytes\n nested CAT archives (file 07h,0Ch,11h,16h,1Bh,20h,25h,etc)\n empty files (file 3Eh,5Ah-5Fh,62h-67h,etc)\n MDEC v2 STR's (file 95h-96h)\n XA-ADPCM's (inside of nested CAT, in file94h\\file*)\nThe DATA directory is 13800h bytes tall. But, the PSX kernel supports max 800h bytes per ISO directory (so the kernel can only see the first 33 files in that directory). The game isn't actually trying to parse the ISO directory entries, instead, it's using the 2800h-byte offset/size list in F0000.BIN to access the directory content:
0000h+N*4 1 Sector MM in BCD ;\\based at 00:06:00 for file 0\n 0001h+N*4 1 Sector SS in BCD ; (unused files are set to 00:00:00)\n 0002h+N*4 1 Sector FF in BCD ;/\n 0003h+N*4 1 Size MSB in hex (Size/800h/100h)\n 2000h+N 1 Size LSB in hex (Size/800h AND FFh)\n 2800h (..) Data area for file 001h..590h (demo version only)\n Sector 000ADh SCUS_944.76 ;exefile ;\\\n Sector 00130h SYSTEM.CNF ; iso root folder\n Sector 00131h DATA (sub-folder, 27h sectors) ;/\n Sector 00158h (padding) ;-padding to 00:06:00\n Sector 001C2h DATA\\F0000.BIN ;file 000h ;\\\n Sector 001C7h DATA\\F0001.BIN ;file 001h ;\n ... ; iso data folder\n Sector 00B54h DATA\\F0032.BIN ;file 020h ;\n Sector 00B9Bh DATA\\F0033.BIN ;file 021h ; ;\\files exceeding the 800h\n ... ... ; ; directory size limit, not\n Sector 1A0C9h DATA\\F1907.BIN ;file 773h ;/ ;/accessible via PSX kernel\n Sector 1AAF1h DUMMY.BIN ;-iso root folder (padding)\n Sector 07148h HSG2\\MINGOL2.BIN ;file 000h..590h ;demo binary files\n Sector 0AC1Dh HSG2\\MINGOL2X.BIN ;file 76Ch ;demo streaming file(s)\n Sector 0B032h HSG2\\SCUS_944.95 ;exefile ;demo exe file\nThe demo version uses \"Virtual Sectors\" in HED+EXE+IMG files. Apart from that, the format is same as for the \"Hidden Sectors\" in retail version: CDROM File Archives in Hidden Sectors
"},{"location":"cdromfileformats/#wwf-smackdown-magdemo33-taipac-and-nested-therein","title":"WWF Smackdown (MagDemo33: TAI\\.PAC\\, and nested therein)","text":"These \"PAC \" files are found in the main archives (which use a separate archive format, with ID \"DPAC\").
000h 4 ID (\"PAC \") ;\\\n 004h 4 Number of files (N) ; Header\n 008h N*8 File List ;/\n ... .. File Data area ;-Data area\n 000h 2 File ID (inreasing, but may skip numbers, ie. non-linear)\n 002h 3 File Offset (increasing, relative to begin of Data area)\n 005h 3 File Size\n 000h 4 Unknown (1)\n 004h 4 Filelist Offset (800h)\n 008h 4 Filelist Size (N*8+4) (7ACh)\n ... .. Padding to 800h-byte boundary (see note)\n 800h 4 Number of files (N) (F5h)\n 804h N*8 File List\n ... .. Padding to 800h-byte boundary (see note)\n ... .. File Data area\n 000h 4 File Offset in bytes (increasing, 800h-byte aligned)\n 004h 4 File Size in bytes\n Step 1: Zeropadding to 200h-byte boundary (first 0..1FFh bytes)\n Step 2: Garbagepadding to 800h-byte boundary (last 0..600h bytes)\n 000h 2 ID (\"BD\")\n 002h 2 Number of files (N)\n 004h N*8 File List\n ... .. Zeropadding to 3000h\n 3000h .. File Data area\n 000h 4 File Offset/800h (increasing)\n 004h 4 File Size in bytes\n 000h 4 ID (\"add\",00h)\n 004h 4 Fixed (4)\n 008h 4 Offset to File List (usually/always 20h)\n 00Ch 4 Number of Files (N)\n 010h 4 Fixed (10h)\n 014h 0Ch Zerofilled\n 020h N*10h File List\n ... .. File Data area\n 000h 4 Offset (increasing, 4-byte aligned) ;\\or both zero\n 004h 4 Size (can be odd) ;/\n 008h 4 Unknown (0) (or 00h,10h,11h,20h,30h,40h when Offset/Size=0)\n 00Ch 4 Zero (0)\n 000h 4 Number of files (N)\n 004h N*4 File List\n ... .. Zeropadding to 800h-byte boundary\n 000h 2 File Offset/800h (increasing)\n 002h 2 File Size/800h\n 000h 5*4 File Sizes (can be odd) (can be 0 for 2nd and 5th file)\n 014h 5*4 File Offsets (28h and up, increasing by sizes rounded to N*10h)\n 028h .. File Data area (first file usually/always contains \"SShd\")\n 0000h 4 ID \"siff\" ;\\Header\n 0004h 4 Total Filesize (DADB1Ch) ;/\n 0008h 4 ID \"RSRC\" ;\\\n 000Ch 4 String Size (70h) ; ASCII string\n 0010h 70h String \"RC ver1.0 Copyright\",...,00h ;/\n 0080h 4 ID \"RIDX\" ;\\\n 0084h 4 File List Size (1F78h) (3EFh*8) ; Directory\n 0088h N*8 File List (Offset, Size1) ;/\n 2000h 4 ID \"EXIX\" ;\\\n 2004h 4 Extended List Size (FBCh) (3EFh*4) ; Extended\n 2008h N*4 Extended List (Size2) ;/\n 2FC4h 4 ID \"GAP0\" ;\\Alignment Padding\n 2FC8h 4 Padding Size (2Ch) ; (so that next chunk\n 2FCCh 2Ch Padding (1Ah-filled) ;/starts at boundary-8)\n 2FF8h 4 ID \"RBB0\" ;\\\n 2FFCh 4 File Data area Size (DAAB1Ch) ; Data area\n 3000h .. File Data area ;/\n 000h 4 File Offset (increasing, 4-byte aligned, from ID \"RBB0\" plus 8)\n 004h 4 File Size in bytes (can be odd)\n 000h 4 File Size in bytes (always the same size as in RIDX chunk)\n 000h 4 ID \"OIFF\" ;\\Header\n 004h 4 Total Filesize ;/\n 008h 4 ID \"TIMT\" or \"ANMT\" ;\\\n 00Ch 4 Size (N*4) ; Directory Table\n 010h N*4 File List (offsets from begin of Data ID+8);/\n ... 4 ID \"TIMD\" or \"ANMD\" ;\\\n ... 4 Data Area size (SIZ) (Filesize-18h-N*4) ; Data area\n ... SIZ Data Area ;/\n MEGA.CSH:\n 000h N*0Ch File List\n MEGA.BIN:\n 000h .. File Data area\n 000h 4 Offset (in MEGA.BIN file, 800h-byte aligned, increasing)\n 004h 4 Unknown (32bit id/random/checksum/whatever)\n 008h 4 Filesize in bytes\n 000h 4 Number of entries (1 or more)\n 004h N*10h File List\n ... .. File Data area (.VB aka SPU-ADPCM)\n File List entries:\n 000h 4 Offset from begin of Data area, increasing\n 004h 4 Filesize in bytes\n 008h 4 Unknown (0 or 1)\n 00Ch 4 Unknown (AC44h, 0FA0h, 2EE0h, 2710h, 2B11h, 3E80h, 1F40h, etc.)\n Note: Above AC44h might 44100Hz, or just file number 44100 decimal?\n 000h 4 ID (always 2A81511Ch)\n 004h 0Ch Zerofilled\n 010h 1 Unknown (1)\n 011h 1 Compression Flag for all files (00h=Uncompressed, 80h=Compressed)\n 012h 2 Number of files (bit0-13?=N, bit14=Unknown, can be set)\n 014h N*0Ch File List, 12 bytes/entry ;<-- when [11h]=00h=uncompressed\n 014h N*10h File List, 16 bytes/entry ;<-- when [11h]=80h=compressed\n ... .. File Data area\n 000h 4 File ID (usually 0=first, increasing) (or 0001h,7531h,7532h,...)\n 004h 4 Offset-10h in bytes (increasing, 4h-byte aligned)\n 008h 4 Filesize, uncompressed (can be odd)\n 00Ch (4) Filesize, compressed (can be odd) ;<-- exists only if compressed\n 000h 4 ID \"0FDG XSP\" (aka PSX GDF0 backwards)\n 008h 4 Header Size (N*10h+10h)\n 00Ch 4 Number of files (N)\n 010h N*10h File List\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n File List entries:\n 000h 4 ID/Type (\"MARV\", \"MARS\", \"MARD\", \"PMET\", \"COLR\", \"MROF\")\n 004h 4 ID/Num (usually 1 SHL N, or all zero)\n 008h 4 Offset (800h-byte aligned, increasing)\n 00Ch 4 Size in bytes\n 000h 4 ID \"MRG\",1Ah\n 004h 4 Number of Files (eg. 0, 1, 2, 193h, 2E7h, or 1DBBh)\n 008h N*8 File List\n ... .. Padding to 800h-byte boundary (8Ch-filled) (not in nested MRG's)\n ... .. File Data area\n File List entries:\n 000h 4 Offset/800h, or 4-byte aligned Offset/1 (increasing)\n 004h 4 Size (can be odd, and can be zero)\n Size oddities:\n Empty files in demo version have Size=0 and Offset=0.\n Empty files in retail version have Size=0 and Offset=OffsetOfNextFile.\n MRG archives can start or end with Empty files.\n All files can be empty (eg. retail DRAGN0.BIN\\1190h).\n NumFiles can be zero (eg. retail DRAGN0.BIN\\1111h, demo DRAGN0.BIN\\10E2h).\n Offset oddities:\n SECT\\*.BIN have Offset/800h\n Nested MRGs have 4-byte aligned Offset/1\n The two variants can be detected as:\n if FirstOffset=(NumFiles*8+8) then NestedVariant\n if FirstOffset=(NumFiles*8+8+7FFh) AND NOT 7FFh then RootVariant\n Whereas, FirstOffset is the first NONZERO offset in file list (important\n for demo version, which has archives that start with ZERO offsets).\nThis does basically contain four large files (and four info blocks with info on the content of those files).
000h 4 Random/Checksum?\n 004h 4 Faded ID (FADED007h)\n 008h 4 Part 1 Offset (Sound) (always E5Ch)\n 00Ch 4 Part 2 Offset (Texture) (when Type=01h: Offset-E5Ch)\n 010h 4 Part 3 Offset (?) (when Type=01h: Offset-E5Ch)\n 014h 4 Part 4 Offset (?) (when Type=01h: Offset-E5Ch)\n 018h 4 Type (10h or 20h=Normal) (or 01h=Special in BB\\8\\*.BBK)\n 01Ch B0Ch Part 1 Info (Sound) (when Type=01h: garbage-filled)\n B28h 314h Part 2 Info (Texture)\n E3Ch 14h Part 3 Info (?)\n E50h 0Ch Part 4 Info (?)\n E5Ch .. Part 1 Data (Sound, SPU-ADPCM data, if any)\n ... .. Part 2 Data (Texture data) (starts with BDEF1222h or BDEF1111h)\n ... .. Part 3 Data (?) ;\\maybe map, models, and/or whatever\n ... .. Part 4 Data (?) ;/\n 01Ch 4 Random/Checksum?\n 020h 4 Faded ID (FADED007h)\n 024h 4 Part 1 Size (eg.7C7F0h)\n 028h 4 SPU Start Addr (1010h) (for data from file offset E5Ch)\n 02Ch 4 SPU Middle Addr (eg. 58F70h)\n 030h 4 SPU End Addr (eg. 7D800h) (start+size)\n 034h 2 Middle entry number (often 3Ch)\n 036h 2 Number of used entries-1 (eg. 50h means that 51h entries are used)\n 038h AF0h Sample List (100 entries, unused ones are zerofilled)\n 914h 214h Zerofilled (unused 1Ch-byte entries) (total is 1Ch*64h)\n Sample List entries:\n 000h 4 SPU Offset (1010h and up) (SpuOffset=1010h is FileOffset=E5Ch)\n 004h 4 Sample Size in bytes\n 008h 4 Unknown (0)\n 00Ch 4 Unknown (0)\n 010h 4 Pitch (400h=11025Hz, 800h=22050Hz, 2E7h=8000Hz, 8B5h=24000Hz)\n 014h 4 Unknown (0 or 1)\n 018h 4 File ID (00001F08h and up)\n B28h 4 Random/Checksum?\n B2Ch 4 Faded ID (FADED007h)\n B30h 4 Part 2 Size (N*16000h) ;Width=2C0h halfwords, Height=N*64\n B34h 4 Zero (0h)\n B38h 4 Some RAM Address (8010xxxxh)\n B3Ch 4 Unknown (eg. 195h or E3h) ;same as at [DA4h]\n B40h 4+4 VRAM Address X,Y (140h,0) ;maybe load target\n B48h 4+4 VRAM Address X,Y (140h,0) ;maybe palette base?\n B50h 4+4 VRAM Address X,Y (xx0h,Height-40h) ;often at/near end of used area\n B58h 4 Unknown (eg. 1D0h or 1E0h)\n B5Ch 4 Unknown (eg. 1Ah or 0Dh)\n B60h 200h Some halfwords? (most are FFFFh, some are 0000h)\n D60h 40h Zerofilled (0)\n DA0h 4 Unknown (eg. 185h or E2h)\n DA4h 4 Unknown (eg. 195h or E3h) ;same as at [B3Ch]\n DA8h 9x10h Special Texpages (VramX,Y, SizeX,Y, StepX,Y, Flag/Type/Num or so?)\n E38h 4 Some RAM Address (800Axxxxh)\n E3Ch 4 Random/Checksum?\n E40h 4 Faded ID (FADED007h)\n E44h 4 Part 3 Size (eg. A9728h or 51264h)\n E48h 4 RAM End Address (start+size) (eg. 801Fxxxxh) (near memtop)\n E4Ch 4 RAM Start Address (end-size) (eg. 801xxxxxh)\n E50h 4 Random/Checksum?\n E54h 4 Faded ID (FADED007h)\n E58h 4 Part 4 Size (usually 10CCCh) (or 105E0h in demo version)\nBelow are archives that start with a simple Offset list. The DOT1 and DOTLESS types are \"standard\" archives used by many PSX games (although the \"standard\" was probably independently created by different developers).
"},{"location":"cdromfileformats/#dot1-archives-named-after-the-1-extension-in-r-types","title":"DOT1 Archives (named after the \".1\" extension in R-Types)","text":"Used by various titles:
R-Types (CG.1, PR\\PR.1, and nested inside CG.1)\n Final Fantasy IX (nested inside FF9.IMG, FF9.IMG\\DB, FF9.IMG\\DB\\DOT1)\n Legend of Mana (*.EFF,*.SET,*.BTP(?) in folders SND*,SOUND,WM(?))\n Witch of Salzburg (*.ANM/BIN/BSS/DAT/MDL/SCE)\n Rayman (RAY\\*.XXX, RAY\\SND\\*.ALL, and nested inside *.XXX)\n Pandemonium II (JESTERS.PKG\\0101\\0008 and JESTERS.PKG\\0101\\000D)\n Incredible Crisis (MagDemo38: IC\\TAN_DAT.CDB\\<DOTLESS>\\<DOT1>\\<SHIFTJIS>)\n Various games on PlayStation Magazine Demo Discs (Disc 03-54)\n 000h 4 Number of Files (N) (eg. 2..18)\n 004h N*4 File List (offsets to each file, increasing, aligned)\n ... (4) Optional: Total filesize (aka end-offset for last list entry)\n ... .. Optional: Zeropadding to alignment boundary (when alignment>4)\n ... .. File Data\n Align800h, no extra entry R-Types (CG.1 and PR\\PR.1)\n Align4, no extra entry R-Types (nested in CG.1), FF9 (in IMG, IMG\\DB)\n Align2, no extra entry Incredible Crisis (IC\\TAN_DAT.CDB\\*\\*)\n Align800h, with extra entry MLB 2000 (DATA.WAD)\n Align10h, with extra entry Witch of Salzburg (*.ANM/BIN/BSS/DAT/MDL/SCE)\n Align4, with extra entry Rayman (*.XXX, *.ALL)\nFIL/32bit (with [02h]=FFFFh):
000h 2 Number of Files (N)\n 002h 2 ID for 32bit version (FFFFh=32bit entries)\n 004h N*4 File List (offsets to each file, increasing, 4-byte aligned)\n ... .. File Data\n 000h 2 Number of Files (N)\n 002h N*2 File List (offsets to each file, increasing, 4-byte aligned)\n ... .. Zeropadding to 4-byte boundary\n ... .. File Data\nLike DOT1, but with Total Filesize being oddly stored at begin of file.
000h 4 Total Filesize (aka end-offset for last list entry)\n 004h 4 Number of Files (N)\n 008h N*4 File List (offsets to each file, increasing, 4-byte aligned)\n ... .. File Data\nArmored Core (MagDemo02, AC10DEMP\\*.T)
000h 2 Number of Files\n 002h N*2 File List (Offset/800h to file data, increasing)\n ... 2 Total Size/800h (end-offset for last file)\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data\nHot Shots Golf (MagDemo07: HSG\\.DAT) Hot Shots Golf 2 (retail: DATA\\F0000.BIN\\, MagDemo31/42: HSG2\\MINGOL2.BIN\\) Starblade Alpha (FLT\\.DAT, TEX\\.DAT) Incredible Crisis (MagDemo38: IC\\TAN_DAT.CDB\\<DOTLESS>)
000h N*4 Offsets to File data (increasing, usually 4-byte aligned)\n ... (4) Filesize (end-offset for last file) (only in Ape Escape)\n ... ... File Data\n 000h 4 Size of Data Area (total filesize minus 0D0h)\n 004h 4 Number of files\n 008h N*4 File List (zerobased offsets from begin of Data Area)\n ... .. Zeropadding to 0D0h\n 0D0h .. File Data Area\nBasically, this is alike DOT1, but SECTOR numbers, and with extra entries...
000h 4 Number of Files (N) (3C9h)\n 004h N*4 File List (Offset/800h)\n ... 4 Total Size/800h ;<-- last offset\n ... 4 Unknown (00,E8,82,2E) ;<-- ??? maybe chksum*800h or so?\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n 000h 4 Zero\n 004h 4 Number of Entries (4D3h)\n 008h N*4 File List (Offset/800h)\n ... 4 Total Size/800h (aka end Offset/800h of last file)\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n #define init_data 0 ;for file 0000h\n #define gameover_data 1 ;for file 0001h\n #define town01 3 ;for file 0003h\n #define town0b 12 ;for file 000Ch\n ... ;...\n #define other6 1222 ;for file 04C6h\n #define other7 1228 ;for file 04CCh\n 000h 4 Number of Entries (N)\n 004h N*4 File List (Offset-(4+N*4), increasing) (or FFFFFFFFh=Unused entry)\n ... .. File Data area\n 000h 4 ID \"OA05\"\n 004h N*4 Offset List (usually/always 5 used entries, plus zeropadding)\n 030h .. File Data area (usually/always starting at offset 30h)\n 000h 4 ID \"SEGG\"\n 004h 4 Offset to .VH file\n 008h 4 Offset to .VB file\n 00Ch 4 Number of .SEQ files (N) (usually 6Eh, or 08h in MENU.SGG)\n 010h N*4 Offsets to .SEQ files (increasing, unaligned)\n ... .. SEQ files\n ... .. Padding to 4-byte boundary\n ... .. VH file\n ... .. VB file\n 000h 8 ID \"VRAM-WAD\" (here as archive ID, although same as compress ID)\n 004h N*4 File List (offsets to Data) ;NumFiles=(FirstOffset-8)/4\n ... .. Data (compressed .PAK files, which do ALSO have ID=\"VRAM-WAD\")\n 000h 4 Unknown (3)\n 004h 4 Total Size\n 008h 4 Number of Files (N) (max 40h, for max 40h*4 bytes in file list)\n 00Ch N*4 File List (increasing offsets, 800h-byte aligned)\n ... .. Unknown (looks like garbage padding for unused File List entries)\n 10Ch 6F4h 42h-filled padding to 800h-byte boundary\n 800h .. File Data area\n 000h 8 Fixed (88h,0,0,0,0,0,0,0)\n 008h 4 Number of Files (eg. 1Dh or 585h, including last/end file)\n 00Ch N*4 File List (increasing offsets, 800h-byte aligned)\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n 000h 4 Total Filesize (3E800h in Spyro)\n 004h N*8 File List (1B0h bytes in Spyro)\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data (4-byte aligned, despite of above 800h-byte hdr padding)\n 000h 4 Fileoffset (increasing, 4-byte aligned)\n 004h 4 File ID? (unsorted, not increasing, used range is 000h..1FAh)\n 000h 4 Zero (0)\n 004h 4 Type/ID (27100h=160000, 2BF20h=180000, 30D40h=200000 decimal)\n 008h 4 Number of files\n 00Ch N*0Ch File List\n ... .. Zeropadding to 7FCh\n 7FCh 4 Checksum (32bit sum of SIGN-EXPANDED bytes at [000h..7FBh])\n ... .. File Data\n 000h 4 File Type/ID or so (roughly increasing, eg. 1,3,6,5,7,8,9,A,B)\n 004h 4 Filesize in bytes\n 008h 4 Filesize rounded up to multiple of 800h bytes\nResembles .BZE, but without the Type entry in Header.
000h 4 Fixed 1 (maybe version, or compression flag)\n 004h (4) Unknown (000xxxx0h) ;<-- Extra in The Grinch only (not Bunny)\n ... 4 Number of files\n ... N*0Ch File List\n ... .. Zeropadding to 7FCh\n 7FCh 4 Checksum (32bit sum of SIGN-EXPANDED bytes at [000h..7FBh])\n ... .. File Data\n 000h 4 File Type/ID or so (roughly increasing, eg. 1,2,3,6,5,7,8,9,A)\n 004h 4 Filesize in bytes (rounded to N*4 even if compressed data is less)\n 008h 4 Filesize rounded up to multiple of 800h bytes\nResembles .BZE, but without the Type entries in Header and File List, and without Header checksum.
000h 4 Fixed 1 (maybe version, or compression flag)\n 004h 4 Number of files (4)\n 008h N*8 File List\n ... .. Zeropadding to 800h-byte boundary (without checksum, unlike .BZE)\n ... .. File Data\n 000h 4 Size in bytes\n 004h 4 Size rounded to multiple of 800h\n 000h 2 ID (\"PX\")\n 002h 2 Unknown (1 or 3)\n 004h 4 Header Size (eg. 80h, 7C0h, or 1730h) (N*8+8)\n 008h N*8 File List\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data area\n File List entries:\n 000h 4 Offset (increasing, 800h-byte aligned)\n 004h 1 Zero\n 005h 3 Filesize in bytes (24bit) (can be odd)\n XXX detect this WITH extension=\".RC\" check before OBJ\n (else type=1 could be mistaken as offs=1) (eg RC1\\BP0*.RC)\n 000h N*8 File List\n ... 8 File List end (zerofilled)\n ... .. Garbage padding to 800h-byte boundary\n 000h 4 Filetype (see below)\n 004h 4 Filesize in bytes\n 00h = End of File List (at least so when Type and Size are both zero)\n 01h = .TIM\n 02h = Unknown\n 03h = Unknown\n 05h = .VH\n 06h = .VB\n 09h = Unknown\n 0Ah = .TIM (left half of a larger image) (right half has type 01h)\n 0Bh = Unknown\n 0Ch = Unknown\nThis format is used by the NEW demo version on MagDemp48 (the OLD demo version on MagDemo39 did use Spider-Man-style HED/WAD format with filenames).
HED:\n 000h 2 Number of entries (N)\n 002h N*6 File List\n WAD:\n 000h ... File data (at 800h-byte aligned locations)\n 000h 3 File ID (24bit)\n 003h 3 File Size in bytes (21bit, max 2Mbyte) (upper 3bit=unused?)\n 000h 4 Header Size (N*SectorSize) (xxh, 800h, 1000h, 4800h, or 920h)\n 004h 4 Sector Size (4=ChildArchive, 800h=MainArchive, 920h=FMV/MADN00)\n 008h 4 File List entrysize (0=32bit, 1=16bit/MADN00, 4=16bit/MADN01)\n 00Ch N*2/4 File List (16bit or 32bit filesizes in bytes)\n ... .. Zeropadding to SectorSize boundary\n ... .. Files (with above sizes, each zeropadded to SectorSize boundary)\n 000h 4 Total Filesize-4\n 004h N*14h File List (2 entries in Croc2, 3 entries in Aladdin/Emperor)\n ... .. File Data area (SPU-ADPCM( (.VB files with leading zeroes)\n File List entries: (Aladdin/Emperor) (Croc2)\n 000h 4 Sample Rate in Hertz (AC44h=44100Hz) (5622h=22050Hz)\n 004h 2 Sample Rate Pitch (1000h=44100Hz) (0800h=22050Hz)\n 006h 2 Unknown (7Fh) (32h)\n 008h 4 Unknown (1) (8)\n 00Ch 4 Unknown (1FC0001Fh) (40008Fh)\n 010h 4 Filesize (xxx0h) (xxx0h)\n 000h 800h File List (with 10h or 20h bytes per entry)\n 800h .. File Data (each file is zeropadded to 800h-byte boundary)\n Dino Crisis 1 --> always size 10h\n Dino Crisis 2 --> usually size 20h\n Dino Crisis 2 --> sometimes size 10h (eg. SC24.DAT, SC48.DAT, WEP_*.DAT)\n File List entries, type 0 and 7:\n 000h 4 Type (0=Data (or .BS pictures), 7=CompressedData)\n 004h 4 Size\n 008h 4 RAM Addresss (80000000h..801FFFFFh)\n 00Ch 4 Zero\n 010h (10h) Zerofilled\n File List entries, type 1 and 2 and 8:\n 000h 4 Type (1=Bitmap, 2=Palette, 8=CompressedBitmap)\n 004h 4 Size (see below Size Notes)\n 008h 2 VRAM Address X (0..3FFh)\n 00Ah 2 VRAM Address Y (0..1FFh) (or 280h in Dino 2 ST703.DAT)\n 00Ch 2 Width in halfwords (1..400h)\n 00Eh 2 Height (1..200h)\n 010h (10h) Zerofilled\n File List entries, type 3 and 4:\n 000h 4 Type (3=VoiceHeader(\"Gian\"), 4=VoiceData(SPU-ADPCM))\n 004h 4 Size\n 008h 4 SPU Address (0..7FFF0h)\n 00Ch 2 Unknown (0..7) ;\\usually both same (or val1=0, val2>0)\n 00Eh 2 Unknown (0..7) ;/\n 010h (10h) Zerofilled\n File List entries, type 5 (eg. ME*.DAT):\n 000h 4 Type (5=Unknown... maybe Midi-style or so)\n 004h 4 Size\n 008h 4 Load Address (0, or on next 4-byte boundary after previous file)\n 00Ch 2 Unknown (0..2) ;\\always both same\n 00Eh 2 Unknown (0..2) ;/\n 010h (10h) Zerofilled\n File List entries, type 6 and 9:\n The EXE code does also accept type 6 and 9 (type 6 is handled same as\n type 0, and type 9 is ignored), but the actual archives don't seem to\n contain any files with those types.\n File List entries, padding for unused entries:\n 000h 10h Type (\"dummy header \")\n 010h (10h) Zerofilled\n Bitmaps and Palettes can have following sizes:\n Width*Height*2 ;normal case\n Width*Height*2 + Align(1000h) ;eg. Dino Crisis 1 DOOR*.DAT\n Width*Height*2 + Align(800h) ;eg. Dino Crisis 2 DOOR27.DAT\n CompressedBitmaps can have following sizes in compressed form:\n Less than Width*Height*2 ;normal case\n Less than Width*Height*2 + 1000h ;eg. Dino Crisis 2 M_RESULT,ST002.DAT\n CompressedBitmaps can have following sizes after decompression:\n Width*Height*2 + 8 ;normal case\n Width*Height*2 + Align(1000h?) + 8 ;eg. Dino Crisis 2 M_RESULT,ST002.DAT\nChunk-based archives have chunk headers for each file, but don't have a central directory. That's mainly useful when loading the whole archive to memory.
"},{"location":"cdromfileformats/#interchange-file-format-iff","title":"Interchange File Format (IFF)","text":"IFF has been invented by Electronic Arts in 1985 on Amiga (hence using 2-byte alignment and big-endian size values). IFF does mainly define a standarized file structure for use with custom group/chunk types (it does also define some Amiga-specific standard audio/video types, but those are barely useful on PSX). The files are starting with a Group Header, followed by Chunks:
Group Header:\n 000h 4 Group ID (\"FORM\") (or \"LIST\" or \"CAT \" or \"PROP\")\n 004h 4 Group Size-08h (SIZ) (filesize-8) (big-endian)\n 008h 4 Group Type (4-character ASCII) (should be an unique identifier)\n 00Ch SIZ-4 Chunk(s), and/or nested Group(s)\n Chunk Format:\n 000h 4 Chunk Type (4-character ASCII) (meaning depends on Group Type)\n 004h 4 Chunk Size (SIZ) (big-endian)\n 00Ch SIZ Data (eg. .TIM, .VB, .VH or custom data)\n ... .. Zeropadding to 2-byte boundary\nUnlike real IFF, these are using little-endian, and don't have a Group Type entry. There seem to be no nested FORMs. Alignment is kept as 2-byte.
Group Header:\n 000h 4 Group ID (\"FORM\" or \"BODY\")\n 004h 4 Group Size-08h (SIZ) (little-endian)\n 008h SIZ Chunk(s)\n Chunk Format:\n 000h 4 Chunk Type (4-character ASCII)\n 004h 4 Chunk Size (SIZ) (little-endian)\n 00Ch SIZ Data\n ... .. Zeropadding to 2-byte boundary\nSame as Z-Axis IFF variant, except Group IDs are different, and the Header sizes are included in the Group/Chunk sizes.
Group Header:\n 000h 4 Group ID (\"hTIX\",\"hFNT\",\"hMBD\",\"hHBS\")\n 004h 4 Group Size (total filesize) (little-endian)\n ... (8) Unknown extra (0,0,0,0,0Ch,0,0,0) ;<-- only in \"hHBS\" files\n ... .. Chunk(s)\n Chunk Format:\n 000h 4 Chunk Type (\"cCLT\",\"cBIT\",\"cSTR\",\"cMAP\",\"cIDX\",\"cVAB\",\"cSEQ\")\n 004h 4 Chunk Size (SIZ) (little-endian)\n 00Ch SIZ-8 Data\n ... .. Maybe Zeropadding to boundary? (Chunk Size is always N*4 anyways)\nContains several simple chunks:
000h 4 Chunksize in bytes (SIZ) (usually a multiple of 4)\n 004h SIZ Chunkdata (eg. .TIM file or other stuff)\nContains several simple chunks with filenames:
000h 0Ch Chunk Filename (\"filename.ext\", zeropadded if shorter)\n 00Ch 4 Chunk Data Size in bytes (SIZ)\n 010h SIZ Chunk Data (usually VAGp files, in VAG.WAD)\nContains .BS files in several chunks:
000h .. Chunk(s) (.BS files with extra header info)\n ... 4 End Marker (00000000h)\n Chunk format:\n 000h 4 Chunk size (including whole chunk header)\n 004h 2 Bitmap Width (eg. F0h)\n 006h 2 Bitmap Height (eg. 80h)\n 008h 2 Data Size/4 (same as (Chunksize-0Ch-filenamelen)/4)\n 00Ah 2 MDEC Size/4 (same as at Data[0])\n 00Ch .. Filename (eg. \"lsFact\",00h or \"bsRooftop1\",00h) ;\\filename field\n ... .. Filename Zeropadding to 4-byte boundary ;/\n ... .. Data (in BS v2 format) (MDEC Size/4, BS ID 3800h, etc.)\n 000h 4 ID (100h)\n 004h .. Chunk(s)\n ... 4 Zero (Chunk Size=0=End)\n ... .. Optional zeropadding to 800h-byte boundary (in R4.BIN\\*)\n 000h 4 Chunk Size (SIZ)\n 004h SIZ Chunk Data (TIM file) (note: includes 0x0pix TIMs with palette)\nContains a fileheader and .TIM files in several chunks:
000h 8 ID \"TXSPC\",0,0,0 (aka CPSXT backwards)\n 008h 4 Timestamp? (32A5C8xxh)\n 00Ch 4 Number of Chunks (N) (can be 0=None, eg. TM2\\SCREEN\\ARROWS.TMS)\n 010h N*4 Unknown\n ... N*var Chunks\n Chunk format:\n 000h 4 Chunk Size-4 (SIZ)\n 004h SIZ Chunk Data (TIM file)\nThe BDY\\*.BD files do simply contain several chunks:
000h .. Chunk(s)\n 000h .. Chunk(s) for 1st folder ;\\Foldersizes are:\n ... .. Zeropadding to Foldersize-boundary ; 20000h (PM.DT0 and PM.PCC)\n ... .. Chunk(s) for 2nd folder ; 28000h (PM.MAP)\n ... .. Zeropadding to Foldersize-boundary ; 42000h (PM.SD0)\n ... .. etc. ;/\n 000h 4 Chunk ID (800000xxh)\n 004h 4 Chunk Size (size of Data part, excluding ID+Size)\n 008h .. Data\n 80000004h x(2),y(2),width(2),height(2) Bitmap 8bpp ;PM.PCC,MAP\n 80000005h w(2),h(2),zero(4) Array32bit(w,h) ;PM.MAP\n 80000006h x(2),width(2) Bitmap Palette ;PM.*\n 80000007h x(2),y(2),w(1),h(1),zero(2) Array8bit(w,h) ;PM.MAP\n 80000010h width(2),height(2),x(2),y(2) Bitmap 16bpp ;*.BD\n 80000012h zero(0) ? ;*.BD\n 80000014h x(2),y(2),width(2),height(2) Bitmap 4bpp ;PM.DT0\n 80000016h x(2),y(2),w(1),h(1),n(1),3Fh(1) BitmapArray4bpp(n*2) ;PM.DT0\n 80000018h ... ? ;PM.PCC\n 8000001Ah zero(8) ? ;PM.PCC\n 8000001Ch x(2),y(2),width(2),height(2) Bitmap 1bpp flags? ;*.BD\n 80000020h zero(8) Sound .SEQ file ;PM.SD0\n 80000021h zero(8) Sound .VH file ;PM.SD0\n 80000022h zero(8) Sound .VB file ;PM.SD0\n 80000024h x(2),zero(6) ? ;PM.DT0\\4\\0\n 00000000h Zeropadding to next folder Zeropadding ;PM.*\n 000h .. Chunks\n 000h 1 Chunk Type (see below)\n 001h 3 Unknown (some flags or file ID, or zero in many files)\n 004h 4 Chunk Size (SIZ)\n 008h SIZ Chunk Data (eg. SEQ file)\n 02h unknown ST*.BIN\n 05h .TXT ROLL.BIN\n 05h LZ-compressed TIM DEMODATA.BIN, ST*.BIN (except ST1*.BIN)\n 06h DOT1 with stuff and TSQ?? ST*.BIN\n 07h .TMD DEMODATA.BIN, ST*.BIN (except ST1*.BIN)\n 08h unknown ST*.BIN\n 09h \"PRM:\" ST*.BIN\n 0Ah unknown ST*.BIN\n 0Bh DOT1 with stuff ST*.BIN (except ST1*.BIN) (odd: ST3*.BIN)\n 0Ch .SEQ ROLL.BIN, ST*.BIN\n 0Dh unknown COMDATA.BIN\n 0Eh unknown ST*.BIN\n 0Fh DOT1 with LZ-compressed TIMs ST*.BIN\n 10h DEFLATE-compressed TIM COMDATA.BIN, ROLL.BIN, ST*.BIN\n 11h DOT1 with stuff ST*.BIN\n Note: Type=05h can be uncompressed TXT or compressed TIM.\n 07 00 00 00 xx xx 00 00 41 00 00 00 .. TMD Model (\"A\")\n 0C 00 00 00 xx xx 00 00 70 51 45 53 .. SEQ Midi (\"pQES\")\n 0E xx 00 00 08 00 00 00 xx xx xx xx .. Whatever in ST7DATA.BIN (see note)\n 10 01 00 00 24 28 00 00 EC 9B 7F 70 .. Deflated TIM in COMDATA.BIN\n 10 08 1A 00 30 0C 00 00 ED 58 4F 88 .. Deflated TIM in ROLL.BIN\n ST7DATA.BIN has 2 chunks with Type=0Eh, followed by SEQ chunk at offset=20h.\nDATA\\GRP.IDX, DATA\\MAP.IDX, DATA\\SEQ.IDX DATA\\VAB.IDX:
000h N*2 Chunk List (16bit Offset/800h to Part-1-Chunks in .DAT files)\n ... .. Zeropadding to 800h-byte boundary\n Notes:\n The Chunk List can contain zeroes (as first entry at offset 0, and as\n unused entries; in VAB.IDX those can be followed by further USED entries).\n For 2-part DAT files, the Chunk List contains offsets for Part 1 only.\n 000h 4 Chunksize/800h ;\\\n 004h 4 Datasize in bytes ; Single\n 008h 4 Always 015A5A01h or 015A5A00h ; Part\n 00Ch 4 Always 2803h ; with\n 010h .. Midi data .SEQ file ; 1 file\n ... .. Zeropadding to 800h-byte boundary ;/\n 000h 4 Chunksize/800h ;\\\n 004h 4 Size of .VH Voice Header in bytes ; Single\n 008h 4 Size of .VB Voice Binary in bytes ; Part\n 00Ch .. Voice Header .VH file ; with\n ... .. Zeropadding to 800h-byte boundary ; 2 files\n ... .. Voice Binary .VB file ;\n ... .. Zeropadding to 800h-byte boundary ;/\n 000h 4 Part 1 Chunksize/800h ;\\\n 004h 4 Size of all TIM files in bytes (can be 0=None) ; Part 1\n 008h .. Texture data (several TIMs appended after each other) ;\n ... .. Zeropadding to 800h-byte boundary ;/\n ... 4 Number of Files (N) ;\\\n ... 4 Part 2 Chunksize/800h ;\n ... N*8 File List ; Part 2\n ... .. Garbage-padding to 800h-byte boundary? ;\n ... .. File Data area (each file Garbage-padded to 800h-byte) ;\n File List entries: ;\n 000h 4 File Type/ID ;\n 004h 4 Size in bytes ;/\nCDROM File Archive Darkworks Chunks (Alone in the Dark) CDROM File Archive Blue Chunks (Blue's Clues) CDROM File Archive HED/CDF (Parasite Eve 2) CDROM File Compression LZSS (Serial Experiments Lain) CDROM File Compression SLZ/01Z (chunk-based compressed archive)
"},{"location":"cdromfileformats/#cdrom-file-archives-with-folders","title":"CDROM File Archives with Folders","text":"There are several ways to implement folder-like directory trees:
- Using multiple archive files nested within each other\n - Using filenames with path string (eg. \"path\\filename.ext\")\nCDROM File Archive HUG/IDX/BIZ (Power Spike) CDROM File Archive TOC/DAT/LAY CDROM File Archive WAD (Doom) CDROM File Archive WAD (Cardinal Syn/Fear Effect) CDROM File Archive DIR/DAT (One/Viewpoint) CDROM File Archive HED/CDF (Parasite Eve 2) CDROM File Archive IND/WAD (MTV Music Generator) CDROM File Archive GAME.RSC (Colonly Wars Red Sun) CDROM File Archive BIGFILE.DAT (Soul Reaver) CDROM File Archive FF8 IMG (Final Fantasy VIII) CDROM File Archive FF9 IMG (Final Fantasy IX) CDROM File Archive GTFS (Gran Turismo 2) CDROM File Archive Nightmare Project: Yakata CDROM File Archive FAdj0500 (Klonoa) See also: PKG (a WAD.WAD variant with folders)
"},{"location":"cdromfileformats/#perfect-assassin-jfs","title":"Perfect Assassin (*.JFS)","text":" Overall File Structure\n JFS for root ;\\\n JFS for 1st folder ;\\these are dupicated, ; header with complete list\n JFS for 2nd folder ; also stored in below ; of all file/folder names\n JFS for 3rd folder ; data area ;\n etc. ;/ ;/\n JFS for 1st folder, plus data for files in that folder ;\\\n JFS for 2nd folder, plus data for files in that folder ; data area\n JFS for 3rd folder, plus data for files in that folder ;\n etc. ;/\n 00h 4 ID \"JFS\",00h\n 04h 4 Size in bytes (for root: including nearby child JFS's)\n 08h 4 Number of file/folder entries in this folder (N)\n 0Ch N*14h File/Folder entries\n 00h 12 \"FILENAME.EXT\" (or zeropadded if shorter)\n 0Ch 4 Offset from begin of JFS in data area (without any alignment)\n 10h 4 Size in bytes, plus 00000000h=File\n 00h 12 \"DIRNAME.EXT\" (or zeropadded if shorter)\n 0Ch 4 Offset to child JFS in data area\n 10h 4 Offset to child JFS in header area, plus 80000000h=ChildFolder\n FAT.BIN:\n 00h 2 Number of folders (X) (43h)\n 02h 2 Number of files (Y) (8F0h)\n 04h 4 Unknown (1000h)\n 08h X*10h Directory Entry 0000h..X-1 (entry 0000h is named \"ROOT\")\n .. Y*10h File Entry 0000h..Y-1\n DATA.BIN:\n 00h .. File Data area\n 00h 8 Name (terminated by 00h if less than 8 chars)\n 08h 2 First Subdirectory number (0001h and up, 0000h would be root)\n 0Ah 2 Number of Subdirectories (0000h=None, if so above is usually 00FFh)\n 0Ch 2 First File number (0000h and up)\n 0Eh 2 Number of files (0000h=None, if so above is usually 00FFh)\n 00h 8 Name (terminated by 00h if less than 8 chars)\n 08h 4 Offset/800h to DATA.BIN\n 0Ch 4 Size in bytes (when compressed: decompressed size+02000000h)\n HOG.TOC:\n 000h N*14h Folder/File List (starting with root folder)\n HOG.DAT:\n 000h .. File Data (referenced from HOG.TOC)\n 000h 1 Type (\"D\"=Directory)\n 001h 8 Name (\"FILENAME\", zeropadded if shorter) (or \"\\\" for root)\n 009h 3 Extension (usually zero for directories)\n 00Ch 4 Folder Offset/14h in .TOC file (aka 1st child file/folder index)\n 010h 4 Folder Size/14h (aka number of child files/folders)\n 000h 1 Type (\"F\"=File)\n 001h 8 Name (\"FILENAME\", zeropadded if shorter)\n 009h 3 Extension (\"EXT\", zeropadded if shorter)\n 00Ch 4 File Offset/800h in .DAT file (increasing)\n 010h 4 File Size in bytes\n 000h 4 Unknown (demo=A0409901h, us/retail=A0617023h)\n 004h 4 Unknown (0h)\n 008h 4 Number of files (F) (demo=B7h, us/retail=1294h)\n 00Ch 4 Number of folders (D) (demo=0Fh, us/retail=3Eh)\n 010h D*8 Folder List\n ... .. Zerofilled (padding to 800h-byte boundary)\n 800h F*10h File List\n ... .. Zerofilled (padding to 800h-byte boundary)\n ... .. File Data area\n 000h 4 Folder ID (Random, maybe folder name checksum?)\n 004h 4 First file number in this folder (0=first, increasing)\n 000h 4 File Offset/800h\n 004h 4 File Size in bytes\n 008h 4 Folder ID (same as Parent Folder ID in Folder List)\n 00Ch 4 File ID (Random, maybe file name checksum?)\n LFS:\n 000h N*18h File/Folder List\n DAT:\n 000h .. File data\n 000h 10h Filename (\"FILENAME.EXT\", zeropadded)\n 010h 4 Offset in bytes, in BLASTO.DAT\n 014h 4 Size in bytes\n 000h 10h Foldername (\"DIRNAME\", zeropadded)\n 010h 4 Index to first child (at Offset=(-Index)*18h in BLASTO.LFS)\n 014h 4 Zero\n 000h 1 End marker, at end of root & child directories (00h or 80h)\n 001h 17h Unknown\nThese are relative small archives with hundreds of tiny chunks (with registry style Symbol=Value assignments), and a few bigger chunks (with .mod .vab .bit .clt files).
000h 4 Fixed ID (CCCC0067h)\n 004h .. Root Folder (with Name=\"Root\",00h,FDh,FDh,FDh)\n Folder Chunk format:\n 000h 1 Length of Name (including 4-byte padding)\n 001h 1 Number of Child Folders\n 002h 2 Number of Child Files\n 004h .. Name (\"name\",00h, CDh-padded to 4-byte boundary; Root=FDh-padded)\n ... .. Child File(s)\n ... .. Child Folder(s)\n File Chunk format:\n 000h 1 Length of filename (including 4-byte padding)\n 001h 1 Filetype (see below)\n 002h 2 Array Size (or FFFFh for non-array filetypes)\n 004h 4 Filesize (SIZ) (including 4-byte padding)\n 008h 4 Decompressed Size (or 0=Uncompressed)\n 00Ch .. Filename/Symbol (\"name.ext\",00h, CDh-padded to 4-byte boundary)\n ... SIZ Data/Value (CDh-padded to 4-byte boundary)\n \"AXEL.MR\\display\\resolution\\r3\\Groups\\Combined_Polyset\",1Ah,01h,04h,00h\n \"CALYPSO.MR\\display\\resolution\\r3\\Groups\\Combined_Polyset\",A8h,00h, CDh,CDh\n Typ Size Expl.\n 02h var Text String (terminated by 00h, garbage-or-00h-padded to 4-byte)\n 03h 8 Misc (*.IMG\\textures\\*) ;\\\n 03h 20h Misc (*.MR\\display\\resolution\\r*\\Groups\\*) ; these are all\n 03h var Misc (*.MR\\display\\resolution\\*List) ; filetype=03h\n 03h file Misc (*.MR\\display\\*.bit) (same as type=0Ch) ;/\n 04h 4 Numeric 32bit\n 05h 8 Numeric 4x16bit point (X,Y,Z,CDCDh)\n 06h file Model (*.mod) (DOTLESS archive with model data)\n 0Bh 4 Numeric 32bit repeat,light\n 0Ch file XYWH Bitmap/Palette (*.bit, *.clt) (in GAME.IMG, MENU\\menu)\n 0Dh 4 Numeric 32bit delay\n 0Eh 4 Numeric 32bit color (maybe 24bit RGB plus 00h-padding?)\n 0Fh 10h Whatever 10h-byte \"pos\"\n 10h file Sony .VAB file (*.vab)\n 12h N*1 Array? (with Arraysize=0014h)\n 16h N*?? Array Text Strings (with Arraysize=0001h) (in MAIN.MR\\worlds)\n 1Ah N*10h Array Guns,startpoints (RCCAR.MR\\*, NEON.MR\\world)\n 1Bh 4 Numeric 2x16bit (X,Y) (in MENU.MR)\n 1Ch N*4 Array lloc (in MENU.MR\\menu\\screens) (with Arraysize=04h or 1Fh)\n 25h 8 Whatever 8-byte (in GAME.MR\\dualShock)\n 26h N*8 Array CollideArray (in GAME.MR\\dualShock) (with Arraysize=4 or 6)\n 000h .. ZLIB compressed data (usually starting with big-endian 789Ch)\n (compression is used for almost all files, except VERY small ones)\nPOWER\\GAME.HUG
000h .. File Data\n 000h 4 ID \"HUGE\"\n 004h 4 Checksum (sum of all bytes at [010h and up])\n 008h 4 Number of Folders (D) (87h)\n 00Ch 4 Number of Files (F) (F9h)\n 010h D*1Ch Folder List (Folder 0..D-1)\n ... F*18h File List (File 0..F-1)\n 000h 0Ch Folder Name (\"DIRNAME\", zeropadded)\n 00Ch 4 First Child File (or FFFFFFFFh=None)\n 010h 4 Number of Child Files (or 00000000h=None)\n 014h 4 First Child Folder (or FFFFFFFFh=None)\n 018h 4 Next Sibling Folder (or FFFFFFFFh=None)\n 000h 0Ch File Name (\"FILENAME.EXT\", zeropadded if shorter than 12)\n 00Ch 4 File Checksum (sum of all bytes in file added together)\n 010h 4 File Offset/800h in GAME.HUG\n 014h 4 File Size in bytes\n 000h 4 ID \"BIG!\"\n 004h 4 Number of entries (N)\n 008h N*1Ch File List\n ... .. BIZ compressed File Data\n 000h 10h Filename (zeropadded)\n 010h 4 File Offset (increasing, unaligned, can be odd)\n 014h 4 File Size decompressed\n 018h 4 File Size compressed\nUsed in PSX Lightspan Online Connection CD (CD.TOC, CD.DAT, CD.LAY).
CD.TOC contains File/Folder entries\n CD.DAT contains the actual File bodies\n CD.LAY devkit leftover (list of filenames to be imported from PC to TOC/DAT)\n 00h 4 Offset to next Sibling File/Folder/Final entry\n 04h 4 Filesize in bytes\n 08h 4 Filedata Offset/800h in CD.DAT\n 0Ch .. Filename (ASCII, terminated by 00h)\n ... .. Padding to 4-byte boundary (garbage)\n 00h 4 Offset to next Sibling File/Folder/Final entry\n 04h 4 Filesize (always FFFFFFFFh in Folder entries)\n 08h 4 Offset to first File/Folder in Child directory\n 0Ch .. Name of Child directory (ASCII, terminated by 00h)\n ... .. Padding to 4-byte boundary (garbage)\n 00h 4 Offset to next Sibling entry (00000000h=None)\n 04h 4 Filesize (FFFFFFFFh in child folders, FFFFFFFEh in root folder)\n 08h 4 Offset to first File/Folder in Parent directory (or to self for root)\n 0Ch 1 Empty Name (\"\",00h)\n 0Dh 3 Padding to 4-byte boundary (garbage)\nThe .WAD format is used by Doom (for DOS, Jaguar, PSX, etc), various homebrew Doom hacks, and some other developers have adopted the format and used .WAD in other game engines.
000h 4 ID \"IWAD\" (or \"PWAD\" for homebrew patches, or \"PACK\" in A.D. Cop)\n 004h 4 Number of File List entries (N) (including final ENDOFWAD entry)\n 008h 4 Offset to Directory Area (filesize-N*10h)\n 00Ch .. File Data area\n ... N*10h File List\n 000h 4 Offset to file data (increasing by compressed size, 4-byte aligned)\n 004h 4 Filesize in bytes (uncompressed size) (zero in ENDOFWAD file)\n 008h 8 Filename (uppercase ASCII, zeropadded if less than 8 chars)\nThe directory can contain names like F_START, F_END, P1_START, P1_END with filesize=0 to mark begin/end of something; that stuff can be considered as subdirectories with 1- or 2-character names. Notes: There are also regular files with underscores which are unrelated to folders (eg. F_SKY01). There are also 0-byte dummy files (eg. MAP17 in first entry MAP17.WAD). And there's a 0-byte dummy file with name ENDOFWAD in last file list entry (at least, it's present versions with compression support).
"},{"location":"cdromfileformats/#lzss-decompression","title":"LZSS Decompression","text":"Compression is indicated by Filename[0].bit7=1. The compressed size is NextFileOffset-FileOffset (that requires increasing offsets in File List, including valid offsets for 0-byte files like F_START, F_END, ENDOFWAD).
@@collect_more:\n flagbits=[src]+100h, src=src+1 ;8bit flags\n @@decompress_lop:\n flagbits=flagbits SHR 1\n if zero then goto @@collect_more\n if carry=0 then\n [dst]=[src], dst=dst+1, src=src+1\n else\n disp=([src]*10h)+([src+1]/10h)+1, len=([src+1] AND 0Fh)+1, src=src+2\n if len=1 then goto @@decompress_done\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n endif\n goto @@decompress_lop\n @@decompress_done:\n ret\nMore info: http://doomwiki.org/wiki/WAD
"},{"location":"cdromfileformats/#cdrom-file-archive-wad-cardinal-synfear-effect","title":"CDROM File Archive WAD (Cardinal Syn/Fear Effect)","text":""},{"location":"cdromfileformats/#wad-files-cardinal-synfear-effect","title":".WAD files (Cardinal Syn/Fear Effect)","text":"This format exists in two version:
Old format: Without leading Header Size entry (Cardinal Syn MagDemo03: SYN\\*)\n New format: With leading Header Size entry (eg. Fear Effect)\n if [04h]*1Ch+8 >= [00h] then OLD version\n 000h (4) Header Size (including folder/type/file directories) (new version)\n ... 4 Number of Folders\n ... .. Folder List (root)\n ... .. Type Lists (for each folder)\n ... .. File Lists (for each folder\\type)\n ... .. File Data (for each folder\\type\\file)\n Folder List Entries:\n 000h 14h Folder name (ASCII, zeropadded)\n 014h 4 Offset to Type List\n 018h 4 Number of different Types in this folder\n Type List Entries:\n 000h 4 Offset to file entries (of same type, eg. .TIM files)\n 004h 4 Number of file entries (of same type, eg. .TIM files)\n 008h 4 Sum of all Filesizes with that type\n 00Ch 4 Group Type (0000000xh)\n File List entries (Files within Type list):\n 000h 14h Name (ASCII, terminated by 00h, plus garbage padding)\n 014h 4 Offset to File Data (seems 4-byte aligned... always?)\n 018h 4 File Type (000x00xxh)\n 01Ch 4 Filesize in bytes ;\\maybe compressed/uncompressed, or rounded,\n 020h 4 Filesize in bytes ;/always both same\nThe Type List, Group Type and File Type stuff seems to have no function, apart from faster look up (the types are also implied in the filename extension). Except, Fear Effect .RMD .VB .VH have some unknown stuff encoded in File Type bit16-19. Group Type is usually 0 (except for .TIM .VB .VH .MSG .SPU .OFF). The .TIM .VB .VH .SEQ files are using standard Sony file formats. The .PMD file seems to be also Sony standard (except that it contains a 00000000h prefix, then followed by the 00000042h PMD format ID).
"},{"location":"cdromfileformats/#cardinal-syn-types","title":"Cardinal Syn Types","text":" .BGD FileType=00000001h\n .ANM FileType=00000003h\n .TIM FileType=00000004h (GroupType=1)\n .SP2 FileType=00000005h\n .PMD FileType=00000007h\n .MOV FileType=00000008h\n .SPR FileType=0000000Ch\n .PVT FileType=0000000Dh\n .DB FileType=0000000Eh\n .VH FileType=00000010h (GroupType=1) ;only in OLDER demo version MagDemo03\n .VB FileType=00000011h (GroupType=1)\n .MSG FileType=00000012h (GroupType=1) (actually, this is .TIM, too)\n .KMD FileType=00000013h\n .OC FileType=00000018h\n .EMD FileType=00000019h\n .COL FileType=0000001Bh\n .CF FileType=0000001Ch\n .CFB FileType=0000001Dh\n .CL FileType=0000001Eh\n .SPU FileType=0000001Fh (GroupType=1) ;added in newer demo version MagDemo09\n .OFF FileType=00000020h (GroupType=1) ;added in newer demo version MagDemo09\n .RCT FileType=00000021h ;added in newer demo version MagDemo09\n .TIM FileType=00000000h (GroupType=1)\n .RMD FileType=000x0001h\n .DB FileType=00000002h\n .ANM FileType=00000003h\n .SYM FileType=00000004h\n .VB FileType=000x0008h (GroupType=1)\n .SEQ FileType=00000010h\n .BIN FileType=00000012h\n .SFX FileType=00000013h\n .VH FileType=000x0014h (GroupType=2)\n .TM FileType=00000015h\n .NRM FileType=00000017h\n .WPD FileType=00000018h\n Used by One (DATAFILE.BIN and DIRFILE.BIN)\n Used by Viewpoint (VIEW.DAT and VIEW.DIR)\n 000h 60h Extension List (20h x 3-char ASCII, zeropadded if shorter than 3)\n 060h .. Root Directory (can contain folders and files)\n ... .. Child Directories (can contain files) (maybe also sub-folders?)\n In Viewpoint: \"...VCSVCFBINTXTVH.VB.STRST1ST2ST3......//...\"\n In One: \"...VCTVCKSNDBINCPEINI..................//...\"\n 000h 1 Length of Filename and Extension index\n bit7-3 File Extension Index (0..1Fh = Offset I*3 in DIR file)\n bit2-0 Filename Length-1 (0..7 = 1..8 chars)\n 001h .. Filename in 6bit chars (N*6+7/8 bytes = 1..6 bytes for 1..8 chars)\n bit7-2 1st character, whole 6bit ;\\1st byte\n bit1-0 2nd character, upper 2bit (if any) ;/\n bit7-4 2nd character, lower 4bit (if any) ;\\2nd byte (if any)\n bit3-0 3rd character, upper 4bit (if any) ;/\n bit7-6 3rd character, lower 2bit (if any) ;\\3rd byte (if any)\n bit5-0 4th character, whole 6bit (if any) ;/\n bit7-2 5th character, whole 6bit (if any) ;\\4th byte (if any)\n bit1-0 6th character, upper 2bit (if any) ;/\n bit7-4 6th character, lower 4bit (if any) ;\\5th byte (if any)\n bit3-0 7th character, upper 4bit (if any) ;/\n bit7-6 7th character, lower 2bit (if any) ;\\6th byte (if any)\n bit5-0 8th character, whole 6bit (if any) ;/\n bitN-0 Zeropadding in LSBs of last byte ;-zeropadding\n The 6bit characters codes are:\n 00h..09h=\"0..9\", 0Ah..23h=\"a..z\", 24h=\"_\", 25h..3Fh=Unused\n ... 4 Filesize and End Flag\n bit31 End of Directory Flag (0=Not last entry, 1=Last entry)\n bit30-0 Filesize 31bit (or 0=Child Folder)\n ... 4 Offset and fixed bit\n bit31 Unknown (always 1)\n bit30-0 File Offset in DAT file (or Folder offset in DIR file)\nThe files in FAT.BIN are using a messy chunk format: There's no clear ID+Size structure. There are 7 different chunk types (DRAM, DSND, MIDB, G3DB, VRAM, WEAP, HAND), each type requires different efforts to compute the chunk size.
"},{"location":"cdromfileformats/#vram-chunks-texturepalette-in-various-files","title":"VRAM Chunks (Texture/Palette) (in various files)","text":" 000h 4 ID \"VRAM\"\n 004h 4 With Tags (0=No, 1=Yes) (or \"DRAM\" when empty 4-byte chunk)\n 008h (4) Number of Tagged items (N) (0=None) ;\\only when [4]=1\n 00Ch N*10h Tagged Item(s) ;/(not so in LEVELS\\*\\VIEW*)\n ... .. Scanline Rows(s)\n ... 4 End code (00000000h) (aka final Scanline Row with width=0)\n Tagged Item(s) (IMG, LINE, GLOW, FLARE, BALLE, BLINK, COURIER7, BMP_xxx):\n 000h 8 Tag (ASCII, if less than 8 chars: terminate by 00h, pad by FDh)\n 008h 8 Data\n Scanline Row(s) (bitmap scanlines and palette data):\n 000h 4 Header (bit0-8=Width, bit10-18=Y, bit20-29=X, bit9,19,30,31=?)\n 004h W*2 Data (Width*2 bytes, to be stored at VRAM(X,Y))\n 000h 4 ID \"G3DB\"\n 004h 4 Unknown (0, 1, or 2)\n 008h 4 Size of Data part (SIZ)\n 00Ch 4 Number of List entries (eg. 6 or 0Ah or 117Ch) (N)\n 010h SIZ Data (supposedly LibGDX models in G3DB format)\n ... N*4 List\n 000h 4 ID \"DRAM\"\n 004h 4 Size of Data part (SIZ) (can be odd)\n 008h 4 Number of List entries (N)\n 00Ch SIZ Data (raw data, and/or tags TEXT, SPC, COURIER7)\n ... N*4 List\n 000h 4 ID \"WEAP\"\n 004h 4 Size-10h?\n 008h .. Data\n 000h 4 ID \"HAND\"\n 004h 4 Size-0Ch? (18h)\n 008h 8 Zerofilled\n 010h 4x4 Unknown (FFh,FF00h,xF0000h,FF3232h,FF6464h,FFDCDCh,FFFFFFh,..)\n 020h 4 Unknown (0, 1, 101h, or 201h)\n 000h 4 ID \"MIDB\"\n 004h 1 Unknown (0 or 1)\n 005h 1 Number of SEQ blocks (1..4) (S)\n 006h 1 Number of Unknown 80h-byte blocks (1..2) (U)\n 007h U*80h Unknown Blocks (mostly FFh-filled)\n ... S*Var SEQ Block(s)\n ... .. VAB Block\n SEQ Blocks:\n Probably some MIDI sequence data, similar to Sony's .SEQ format.\n 000h 4 Size-0Ch (can be odd)\n 004h 8 Name (zeropadded if less than 8 chars)\n 00Ch 4 ID \"DSEQ\" ;\\Size\n 010h .. Data ;/\n VAB Blocks:\n Apparently inspired on Sony's .VAB format (but the ID is spelled other way\n around, Lists have variable size, and entries have different format).\n 000h 4 ID \"VABp\" (this is: not pBAV, unlike normal .VAB files)\n 004h 4 Unknown (0)\n 008h 4 Unknown (0)\n 00Ch 4 Size of all SPU-ADPCM samples (SIZ)\n 010h 2 Number of List 1 entries (N1)\n 012h 2 Number of List 2 entries (N2)\n 014h 2 Number of Samples (N3)\n 016h 6 Unused? (CCh-filled)\n 01Ch N1*10h List 1\n ... N2*10h List 2\n ... N3*2 Sample Size List (size of each SPU-ADPCM sample)\n ... SIZ SPU-APDCM Sample(s)\n 000h 4 ID \"DSND\"\n 004h 4 Unknown (0 or 2)\n 008h .. VAB Block (same as in MIDB chunks, see there)\nDRAM and MIDB chunks can have odd size; there isn't any alignment padding, so all following chunks can start at unaligned locations.
"},{"location":"cdromfileformats/#cdrom-file-archive-blue-chunks-blues-clues","title":"CDROM File Archive Blue Chunks (Blue's Clues)","text":""},{"location":"cdromfileformats/#blues-clues-blues-big-musical-txd","title":"Blue's Clues: Blue's Big Musical (*.TXD)","text":" 000h 4 Size of AUDD+SEPD+VABB chunks ;\\for quick look-up only\n 004h 4 Size of all VRAM chunks ; (can be ignored by chunk crawlers)\n 008h 4 Size of STGE+ANIM+FRAM chunks ;/(note: sum is total filesize-0Ch)\n ... .. AUDD Chunk (contains .VH) ;\\\n ... .. SEPD Chunk(s) (contains .SEP) ; sound\n ... .. VABB Chunk (contains .VB) ;/\n ... (..) VRAM Chunk(s) (not in IN\\FE2.TXD) ;-textures/palettes\n ... (..) STGE Chunk (if any, not in IN\\FE*.TXD) ;-stage data?\n ... (..) ANIM Chunk (if any, not in IN\\FE*.TXD) ;\\animation\n ... (..) FRAM Chunk(s) (if any, not in IN\\FE*.TXD) ;/\n ... (..) Further groups with ANIM+FRAM Chunks (if any) ;-more animation(s)\n AUDD Chunks:\n 000h 4 Chunk ID (\"AUDD\")\n 004h 4 Chunk Size (of whole chunk from Chunk ID and up)\n 008h 4 Compression Flag (0=Uncompressed)\n 00Ch 4 Zero\n 010h .. VH File (Sony Voice Header, starting with ID \"pBAV\")\n SEPD Chunks:\n 000h 4 Chunk ID (\"SEPD\")\n 004h 4 Chunk Size (of whole chunk from Chunk ID and up)\n 008h 4 Compression Flag (0=Uncompressed)\n 00Ch 2 Zero\n 00Eh 2 Number of sequences (in the SEP sequence archive)\n 010h 4 Zero\n 014h .. SEP File (Sony Sequence archive, starting with ID \"pQES\")\n ... .. Zeropadding to 4-byte boundary\n VABB Chunks:\n 000h 4 Chunk ID (\"VABB\")\n 004h 4 Chunk Size (of whole chunk from Chunk ID and up)\n 008h 4 Compression Flag (0=Uncompressed)\n 00Ch .. VB File (Sony Voice Binary, with raw SPU-ADPCM samples)\n VRAM Chunks:\n 000h 4 Chunk ID (\"VRAM\")\n 004h 4 Chunk Size (of whole chunk from Chunk ID and up)\n 008h 4 Compression Flag (1=Compressed)\n 00Ch 2 VRAM.X\n 00Eh 2 VRAM.Y\n 010h 2 Width in halfwords\n 012h 2 Height\n 014h 4 Decompressed Size (Width*Height*2) ;\\Texture Bitmaps 8bpp\n 018h .. Compressed Data ; (or Palettes, in last VRAM\n ... .. Zeropadding to 4-byte boundary ;/chunk)\n STGE Chunks:\n 000h 4 Chunk ID (\"STGE\")\n 004h 4 Chunk Size (of whole chunk from Chunk ID and up)\n 008h 4 Compression Flag (0=Uncompressed)\n 00Ch .. Unknown (stage data?)\n ANIM Chunks:\n 000h 4 Chunk ID (\"ANIM\")\n 004h 4 Chunk Size (of whole chunk from Chunk ID and up)\n 008h 4 Compression Flag (0=Uncompressed)\n 00Ch .. Unknown (animation sequence info?)\n FRAM Chunks:\n 000h 4 Chunk ID (\"FRAM\")\n 004h 4 Chunk Size (of whole chunk from Chunk ID and up)\n 008h 4 Compression Flag (0=When Chunksize=14h, 1=When Chunksize>14h)\n 00Ch 1 Width in bytes\n 00Dh 1 Height\n 00Eh 6 Unknown, looks like three signed 16bit values (maybe X,Y,Z)?\n 014h (4) Decompressed Size (Width*Height*1) ;\\Animation Frame Bitmap 8bpp\n 018h (..) Compressed Data ; (only if Chunksize>14h)\n ... (..) Zeropadding to 4-byte boundary ;/\nCrazy Data Format (CDF) is used by Parasite Eve 2, on Disc 1 and 2: 1: PE_Disk.01 Stage0.hed Stage0.cdf Stage1.cdf Stage2.cdf Stage3.cdf Inter0.str 2: PE_Disk.02 Stage0.hed Stage0.cdf Stage3.cdf Stage4.cdf Stage5.cdf Inter1.str
"},{"location":"cdromfileformats/#stage0hed-and-stage0cdf","title":"STAGE0.HED and STAGE0.CDF","text":"This uses separate header/data files. The directory is stored in STAGE0.HED:
0000h 78h Streaming List (03h entries, 28h-bytes each, all entries used)\n 0078h 1B00h File List (360h entries, 8 bytes each, all entries used)\n 1B78b 8 File List End Code (FFFFFFFFh,FFFFFFFFh)\n 0000h 800h Root: Folder List (100h entries, 8-byte each, unused=zeropadded)\n 0800h .. 1st Folder (File/Streaming List and Data)\n ... .. 2nd Folder (File/Streaming List and Data)\n ... .. etc.\n 000h 4 Folder ID (usually N*100+1 decimal, increasing, eg. 101,201,301,etc.)\n 004h 4 Folder Size/800h (of whole folder, with File/Stream List and Data)\n The Folder List ends with unused/zeropadded entries with ID/Size=00000000h.\n 0000h 510h File List (A2h entries, 8-bytes each, unused=zeropadded)\n 0510h 4 Zero (padding to decimally-minded offset 1300 aka 514h)\n 0514h 2D0h Streaming List (12h entries, 28h-bytes each, unused=zeropadded)\n 07E4h 1Ch Zero (padding to end of sector)\n 0800h ... Data (for Files, Audio streams, and sometimes also Movie streams)\n 000h 4 File ID (increasing, eg. 0,1,2,3,4,etc.) (or 99) (or N*100+x)\n 004h 4 File Offset/800h in in .CDF (from begin of current Folder)\n The offset of next File in File List (same as CurrOffset for 0-byte files)\n The offset of next Audio stream in Streaming List\n The offset of next Movie stream in Streaming List (if it's in .CDF, not .STR)\n The size of the current Folder (for STAGE1-5)\n The size of the whole .CDF file (for STAGE0)\nMost CDF files in STAGE0 and STAGE1-5 do contain one or more chunks with 10h-byte chunk headers (this can be considered as an additional filesystem layer, with the chunk data being the actual files).
000h 1 Chunk Type (see below)\n 001h 1 End Flag (01h=More Chunks follow, FFh=Last Chunk)\n 002h 2 Unknown (usually 800h, sometimes 500h or 600h)\n (eg. 500h in stage0\\file30301\\chunkX)\n (eg. 600h in stage1\\folder1201\\file0\\chunkXYZ)\n 004h 4 Chunk Size/800h\n 008h 4 Unknown (usually zero) (or 80xxxx00h in Chunk Type 0 files?)\n 00Ch 4 Zero (0)\n 010h .. Data (Chunk Size-10h bytes)\n 00h=Room package .pe2pkg\n 01h=Image .pe2img\n 02h=CLUT .pe2clut\n 04h=CAP2 Text .pe2cap2\n 05h=Room backgrounds .bs\n 06h=SPK/MPK music program .spk ;stereo/mono, sound/music, single/multiple?\n 07h=ASCII text .txt (eg. stage0\\20101..20132)\n ;Reportedy also (but wrong):\n ;60h=Sounds .pe2snd (but nope, that's wrong, see below)\n ;60h is a MDEC movie from Streaming List (unrelated to File List chunks),\n ;60h is 20h-byte .STR header each 800h-bytes (occurs in \"stage1\\folder501\")\n stage0\\40105...40198 are raw hMPK files without chunks\n stage0\\11000, 20213, 20214, 20300, .., 660800 and 900000 are empty 0-byte\n 000h 2 Stream Type (0001h=Movie)\n 002h 2 Unknown (8000h or 0000h)\n 004h 4 Offset/800h in current Folder of .CDF file ;<-- used when [024h]=0\n 008h 4 Offset/800h in INTERx.STR file ;<-- used when [024h]>0\n 00Ch 2 Unknown (0000h)\n 00Eh 2 Stream ID (increasing, usually starting at 64h aka 100 decimal)\n 010h 2 Stream sub.ID (usually 0, increases +1 upon multiple same IDs)\n 012h 2 Picture Width (0140h = 320 decimal)\n 014h 2 Picture Height (00F0h = 224 decimal)\n 016h 2 Unknown (0000h)\n 018h 2 Unknown (0000h or 0018h) maybe 24bpp or 24fps\n 01Ah 2 Unknown (73Ah or 359h or 3DCh) (Size? but it's slighty too large?)\n 01Ch 6 Unknown (zero)\n 022h 2 Unknown (0 or 1) (often 1 when [024h]>0, but not always)\n 024h 2 Movie number in INTERx.STR, 1 and up? (or 0=Movie is in STAGEx.CDF)\n 026h 2 Unknown (0 or 1)\n 000h 2 Stream Type (0002h=Audio)\n 002h 2 Unknown (806Ah or increasing 0133h,0134h,0135h)\n 004h 4 Offset/800h in STAGEx.CDF file (increasing offsets)\n 008h 4 Unknown (0 or 13000h or E000h)\n 00Ch 2 Stage Number (0..5 = STAGE0-5)\n 00Eh 2 Stream ID (1, or increasing 3Ah,3Bh,3Ch)\n 010h 4 Stream sub.ID (usually 0Bh, increases +0Ah upon multiple same IDs)\n 014h 2 Unknown (0 or 2B0h or 3ADh or 398h) (Size/800h minus something?)\n 016h 2 Unknown (usually 20h, sometimes 0Fh)\n 018h 4 Unknown (2 or 1) ... maybe num channels ?\n 01Ch 2+2 Unknown (0,0 or 800h,800h)\n 020h 8 Unknown (0)\nThis contains a 800h-byte header a list of 32bit indices:
000h 800h Whatever increasing 32bit index/timing values? FFFFFFFFh=special?\n ;That header exists in stage0\\ and stage3\\folder101\\\n ;That header doesn't exist in all files (eg. not in stage1\\folder301\\)\n 000h 4 Chunk Index (increases each second chunk, from 0 and up)\n 004h 4 Number of Chunk Indices\n 008h 4 Fixed (02h,\"STM\") ;2-channel Stream?\n 00Ch 1 Chunk Subindex (toggles 00h or 01h per each chunk) ;ch left/right?\n 00Dh 1 Chunk Size/800h\n 00Eh 4 Unknown (can be 00h, 01h, 11h, 20h, 21h)\n 00Fh 4 Unknown (can be A0h or C0h)\n 010h .. Data (Chunk Size-10h bytes) (looks like SPU-ADPCM audio)\n 000h 0 Number of ADPCM blocks? (eg. 28h or 49h)\n 004h 4 Size of extra data block in bytes (eg. 13900h or 24200h)\n 008h 38h Zerofilled\n 040h 8 Zerofilled (maybe 1st sample of 1st SPU-ADPCM block)\n 048h .. Looks like more SPU-ADPCM block(s), terminated by ADPCM end flag(s)\n ... .. Zerofilled (padding to end of last 800h-byte sector)\nThe movies are usually stored in INTERx.STR (except, some have them stored in STAGEx.CDF, eg. stage1\\folder501, stage1\\folder801, stage2\\folder2101, stage2\\folder3001). The data consists of standard .STR files (with 20h-byte headers on each 800h-byte sector), with the MDEC data being in huffman .BS format (with .BS header... per frame?). And, supposedly interleaved with XA-ADPCM audio sectors...?
"},{"location":"cdromfileformats/#pe_disk01-and-pe_disk02","title":"PE_DISK.01 and PE_DISK.02","text":"The presence of these files is probably used to detect which disc is inserted. The file content is unknown (looks like 800h-byte random values).
"},{"location":"cdromfileformats/#note_2","title":"Note","text":"Reportedly \"Files inside archive may be compressed with custom LZSS compression\" (unknown if/when/where/really/which files).
"},{"location":"cdromfileformats/#cdrom-file-archive-indwad-mtv-music-generator","title":"CDROM File Archive IND/WAD (MTV Music Generator)","text":""},{"location":"cdromfileformats/#mtv-music-generator-indwad-magdemo30-jesterwadsectsind-and-wad","title":"MTV Music Generator (IND/WAD) (MagDemo30: JESTER\\WADS\\ECTS.IND and .WAD)","text":"ECTS.IND contains FOLDER info:
0000h 20h Name/ID (\"Music 2\", zeropadded)\n 0020h 4 Unknown (110000h)\n 0024h 4 Filesize-1000h (size excluding last 1000h-byte padding)\n 0028h 4 Unknown (17E0h)\n 002Ch 4 Unknown (5)\n 0030h N*10h Folder List, starting with Root in first 10h-byte\n 2CF0h 4 Small Padding (34h-filled)\n 2CF4h 1000h Final Padding (34h-filled)\n Folder List entries that refer to Child Folders in ECTS.IND:\n 000h 8 Folder Name (\"EXTRA*~*\", zeropadded if less than 8) (\"\" for root)\n 008h 2 Self-relative Index to first Child folder (positive)\n 00Ah 2 Number of Child Folders (0..7FFFh)\n 00Ch 4 Always 0007FFFFh (19bit Offset=7FFFFh, plus 13bit Size=0000h)\n Folder List entries that refer to File Folders in ECTS.WAD:\n 000h 8 Folder Name (\"EXTRA*~*\", zeropadded if less than 8)\n 008h 2 Self-relative Index to Parent folder (negative)\n 00Ah 2 Number of Child Folders (always 8000h=None)\n 00Ch 4 Offset and Size in ECTS.WAD\n The 32bit \"Offset and Size\" entry consists of:\n 0-18 19bit Offset/800h in ECTS.WAD\n 19-31 13bit Size/800h-1 in ECTS.WAD\n There are several File Folders (at the locations specified in ECTS.IND).\n The separate File Folders look as so:\n 000h 4 Number of files (N)\n 004h N*10h File List\n ... .. 34h-Padding to 800h-byte boundary\n ... .. File Data area\n File List entries:\n 000h 8 File Name (\"NAMELIST\", \"ACIDWO~1\", etc.) (00h-padded if shorter)\n 008h 4 Offset/800h (always from begin of WAD, not from begin of Folder)\n 00Ch 4 Filesize in bytes\n The first file in each folder is called \"NAMELIST\" and contains this:\n 000h 20h Long Name for Parent Folder (eg. \"Backgrounds\", zeropadded)\n 020h 20h Long Name for this Folder (eg. \"Extra 1\", zeropadded)\n 040h N*20h Long Names for all files in folder (except for NAMELIST itself)\n For example, Long name for \"ACIDWO~1\" would be \"Acidworld\". Short names are\n uppercase, max 8 chars, without spaces (with \"~N\" suffix if the long name\n contains spaces or more than 8 chars). Many folder names are truncated to\n one char (eg. \"D\" for Long name \"DTex\"), in such cases short names CAN be\n lowercase (eg. \"z\" for Long name \"zTrans\").\n The Long Names are scattered around in the NAMELIST files in ECTS.WAD file,\n so they aren't suitable for lookup (unless when loading all NAMELIST's).\n 0000h 4 Offset to Bonkers List (2794h)\n 0004h F*8 Folder List (80h bytes, 10h entries)\n 0084h N*14h File List(s) for each folder (2710h bytes, 1F4h entries)\n 2794h 4 Number of Bonkers (FE3h)\n 2798h B*8 Bonkers List (7F18h bytes, FE3h entries)\n A6B0h 8 Unknown (zerofilled)\n A6B8h .. File Data area\n 000h 4 Offset to File List for this folder ;\\both zero when empty\n 004h 4 Number of Files in this folder ;/\n 000h 10h Filename (\"FILENAME_EXT\", zeropadded)\n 010h 3 Index (in Bonkers list) (000h..Fxxh)\n 013h 1 Folder Number where the file is stored (00h..0Fh)\n 000h 4 File Offset (to Data, inreasing, 4-byte aligned, A6B8h and up)\n 004h 4 Folder Number where the file is stored (00h..0Fh)\n 000h 2 Number of Folders (175h in retail, 0Ah in demo)\n 002h 2 Zero\n 004h N*8 Folder List (8-byte per Folder)\n ... .. Zeropadding (to 800h-byte boundary)\n ... .. 1st Folder (with File List, and File Data for that folder)\n ... .. 2nd Folder (with File List, and File Data for that folder)\n ... .. 3rd Folder (with File List, and File Data for that folder)\n ... .. etc.\n 000h 2 Unknown (somehow randomly increases from -8000h to +7E8Fh)\n 002h 2 Number of Files in this Folder (eg. 97h)\n 004h 4 Offset to Folder (usually 800h-aligned)\n 000h 2 Number of Files (same value as FolderistEntry[002h]) ;\\encrypted\n 002h 2 Zero ; by 16bit\n 004h N*10h File List (10h-byte per Folder) ; XOR value\n ... .. Zeropadding (to 800h-byte boundary) ;/\n ... .. File Data for this folder ;-unencrypted\n 000h 4 Unknown (random? filename hash? encrypted name?)\n 004h 4 File Size in bytes\n 008h 4 File Offset (usually 800h-aligned)\n 00Ch 4 Unknown (random? filename hash? encrypted name?)\n key = FileListEntry[000h] XOR FolderListEntry[002h] ;encrypted num entries\n key = FileListEntry[002h] ;encrypted Zero\n key = FileListEntry[zeropadding, if any] ;encrypted Zeropadding\nFF8 is quite a mess without clear directory structure. Apart from SYSTEM.CNF and boot EXE, there is only one huge IMG file. There are at least two central directories: The Root directory (usually at the start of the IMG file), and the Fields directory (hidden in a compressed file that can be found in the Root directory). Moreover, there are files that exist in neither of the directories (most notably the Movies at the end of the IMG file).
"},{"location":"cdromfileformats/#img-file","title":"IMG File","text":"The IMG file doesn't have a unique file header, it can be best detected by checking the filename: FF8DISCn.IMG with n=1-4 for Disc 1-4 (or only FF8DISC1.IMG or FF8.EXE+FF8TRY.IMG for demo versions). The directories contain ISO sector numbers (originated from begin of the ISO area at sector 00:02:00). Accordingly, it's best to extract data from the whole disc image (in CUE/BIN format or the like). When having only the raw IMG file, one most know/guess the starting sector number (eg. assume that the first Root File is located on the sector after the Root Directory, and convert sector numbers ISO-to-IMG accordingly). Another oddity is that many files contain RAM addresses (80000000h-801FFFFFh), unknown how far that's relevant, and if there are cases where one would need to convert RAM addresses to IMG offsets.
"},{"location":"cdromfileformats/#root-directory","title":"Root Directory","text":"The Root Directory is found at:
Offset 0000h in FF8DISCn.IMG in NTSC retail versions\n Offset 2800h in FF8DISCn.IMG in PAL retail versions\n Offset 0000h in FF8DISC1.IMG in french demo version\n Offset ?????h in FF8.EXE in MagDemo23 (...maybe offset 3357Ch ?)\n Offset 33510h in FF8.EXE in japanese demo version ?\n Offset 33584h in FF8.EXE in other demo versions ?\n if FF8DISCn.IMG starts with 000003xxh --> assume Root at IMG offset 0\n if FF8DISCn.IMG starts with xxxxxxxxh --> assume Root at IMG offset 2800h\n if FF8TRY.IMG starts with \"SmCdReadCore\" --> assume Root somewhere in EXE\n 000h N*8 File List entries\n ... .. Zeropadding to end of 800h-byte sector\n 000h 4 ISO Sector Number (origin at 00:02:00) (unsorted, not increasing)\n 004h 4 Filesize in bytes\nThe Fields Directory is located in Root file 0002h. First of, decompress that file, then search the following byte sequences to find the start/end of the directory:
retail.start 040005241800bf8f1400b18f1000b08f2000bd270800e00300000000\n retail.end 0000010002000300\n demo.start 76DF326F34A8D0B863C8C0EC4BE817F8\n demo.end 0000000000000000000000000000000000100010\n 000h 4 ISO Sector Number (origin at 00:02:00)\n 004h 4 Filesize in bytes\nThere is no known central directory for the movies (unknown if such a thing exists, or if the movie sector numbers are scattered around, stored in separate files). However, a movie list can be generated by crawling the movie headers, starting at end of IMG file:
sector = NumSectors(IMG file)\n @@lop:\n seek(sector-1), read(buf,08h bytes)\n if first4byte[buf+0]=(\"SMJ\",01h), or (\"SMN\",01h) then\n num_sectors=(byte[buf+5]+1)*(halfword[buf+6]+1)\n sector=sector-num_sectors\n AddToMovieFileList(sector, num_sectors)\n goto @@lop\n endif\nPADBUG archives are used in Root files 001Eh..007Fh, most of them contain two AKAO files (except file 004Bh contains one AKAO and one TXT file).
000h 4 Number of Files (N) (usually 2)\n 004h N*8 File List\n ... .. File Data area\n 000h 4 Offset in bytes (increasing, 4-byte aligned, see Quirk)\n 004h 4 File Size in bytes (can be odd)\nCDROM File Compression LZ5 and LZ5-variants FF8 does reportedly also use GZIP (unknown in which files).
"},{"location":"cdromfileformats/#knownunknown-sectors-for-us-version-ff8disc1img","title":"Known/unknown sectors for US version FF8DISC1.IMG","text":" root sectors: 27CBh ;\\\n field sectors: D466h ; total known sectors: 36D13h\n movie sectors: 270E2h ;/\n unknown sectors: 14F49h\n total IMG sectors: 4BC5Ch\nhttps://github.com/myst6re/deling/blob/master/FF8DiscArchive.cpp
https://ff7-mods.github.io/ff7-flat-wiki/FF8/PlaystationMedia.html
"},{"location":"cdromfileformats/#cdrom-file-archive-ff9-img-final-fantasy-ix","title":"CDROM File Archive FF9 IMG (Final Fantasy IX)","text":""},{"location":"cdromfileformats/#final-fantasy-ix-ff9img-320mbyte-overall-format","title":"Final Fantasy IX (FF9.IMG, 320Mbyte) Overall format","text":" 000h Root Directory\n 800h 1st Child Folder\n ... 2nd Child Folder\n ... 3rd Child Folder\n ... ...\n 8000h ? Last folder, with Type3, contains 1FFh x increasing 16bit numbers\n ... Data for files in 1st Child Folder\n ... Data for files in 2nd Child Folder\n ... Data for files in 3rd Child Folder\n ...\n 000h 4 ID \"FF9 \"\n 004h 4 Unknown (06h on Disc 1 of 4) (maybe version, or disc id?)\n 008h 4 Number of Folder List entries (0Fh)\n 00Ch 4 Unknown (01h on Disc 1 of 4) (maybe version, or disc id?)\n (or Offset/800h to first file list?)\n 010h N*10h Folder List\n ... .. Padding to 800h-byte boundary (\"FF9 FF9 FF9 FF9 \")\n 000h 4 FolderType (2=Normal, 3=Special, 4=Last entry)\n 004h 4 Number of entries in File List (0..1FFh ?)\n 008h 4 Offset/800h to Child Folder with File List\n 00Ch 4 Offset/800h to File Data (same as 1st offs in File List) (0=Last)\n 000h N*8 File List entries (N=Number of files, from Root directory)\n N*8 8 File List END entry (ID=FFFFh, Attr=FFFFh, Offs=EndOfLastFile)\n ... .. Zeropadding to 800h-byte boundary\n 000h 2 File ID (increasing, often decimal 0,10,100, or FFFFh=Last)\n 002h 2 Attr (unknown purpose, eg. 0,2,3,4,8,21h,28h,2Fh,44h,114h,FFFFh)\n 004h 4 Offset/800h to File Data (increasing, implies end of prev entry)\n 000h N*2 File Offsets/800h, from File Data Offset in Root (or FFFFh=None)\n N*2 2 End Offset for last file\nMost of the files in FF9.IMG are DB archives, there are also some DOT1 archives. CDROM File Archive FF9 DB (Final Fantasy IX) There are various combinations of IMG, DB, DOT1 archives nested up to 4 levels deep:
IMG\\DOT1 (eg. dir01\\file003C)\n IMG\\DB (eg. dir01\\file2712)\n IMG\\DB\\DOT1 (eg. dir01\\file2712\\00-0411)\n IMG\\DB\\DOT1\\DOT1 (eg. dir01\\file2712\\00-0443\\*)\n IMG\\DB\\DB (eg. dir03\\file2328\\1B-000*)\n dir00 - Status/Menu/Battle/... -Text and random stuff.\n dir01 - Misc Images (Logos, Fonts, World 'mini' Map images, etc).\n dir02 - Dialog Text\n dir03 - Map models (Mini-zidane, airships, save point moogle, tent...)\n dir04 - Field models\n dir05 - Monster Data (Part I, stats, names, etc).\n dir06 - Location Data (Dungeon, Cities, etc).\n dir07 - Monster Data (Part II, 3d models)\n dir08 - Weapon Data (including models)\n dir09 - Samplebanks and Sequencer Data (ie music).\n dir0A - party members Data (including models)\n dir0B - Sound effects\n dir0C - World Map Data\n dir0D - Special effects (magic, summons...)\nhttps://ninjatoes.blogspot.com/2020/07/
https://wiki.ffrtt.ru/index.php?title=Main_Page
"},{"location":"cdromfileformats/#cdrom-file-archive-gtfs-gran-turismo-2","title":"CDROM File Archive GTFS (Gran Turismo 2)","text":""},{"location":"cdromfileformats/#gran-turismo-2-magdemo27-gt2gt2vol-gt2volarcadearc_carlogo-gtfs","title":"Gran Turismo 2 (MagDemo27: GT2\\GT2.VOL, GT2.VOL\\arcade\\arc_carlogo) - GTFS","text":" 000h 4 ID \"GTFS\" ;\\\n 004h 4 Zero ;\n 008h 2 Number of 4-byte File Offset List entries (N) ; File(0)\n 00Ah 2 Number of 20h-byte File/Folder Name List entries (F) ;\n 00Ch 4 Zero ;\n 010h N*4 File Offset List (see below) ;/\n ... .. Zeropadding to 800h-byte boundary\n ... F*20h File/Folder Name List (see below) ;-File(1)\n ... .. Zeropadding to 800h-byte boundary\n ... .. File Data ;-File(2)\n ... .. Zeropadding to 800h-byte boundary\n ... File Data ;-File(3)\n ... .. ...\n ... File Data ;-File(N-2)\n ... .. Zeropadding to 800h-byte boundary\n EOF 0 End of File ;-File(N-1)\n File(0) and File(1) = Directory information\n File(2)..File(N-2) = Regular data files\n File(N-1) = Offset List entry points to the end of .VOL file\n Bit0-10 = Number of padding bytes in last sector of this file (0..7FFh)\n Bit11-31 = Offset/800h to first sector of this file (increasing)\n To compute the filesize: Size=(Entry[N+1] AND FFFFF800h)-Entry[N]\n 000h 4 Unknown (379xxxxxh) (maybe timestamp?)\n 004h 2 When Flags.bit0=0: Index of File in File Offset List (2 and up)\n When Flags.bit0=1: Index of first child in Name List, or...\n When Flags.bit0=1: Index of 1st? parent in Name List (Name=\"..\")\n 006h 1 Flags (bit0:0=File, 1=Directory; bit7:1=Last Child entry)\n 007h 19h Name (ASCII, zeropadded)\n size=gz_filesize\n size=size-GzipHeader(including ExtraHeader, Filename, Comment, HeaderCrc)\n size=size-GzipFooter(8) ;initially assuming 8-byte footer (without padding)\n i=gz_filesize-4\n @@search_footer:\n if buf[i]<size then i=i-1, size=size-1 goto @@search_footer\n decompressed_size = buf[i]\nISO Files:
CD.IMG 550Mbyte Contains file 004h..FFFh\n CDRTBL.DAT 32Kbyte Alias for file 000h (File List for file 000h..FFFh)\n FDTBL.DAT 2Kbyte Alias for file 001h (Folder List and Disc ID)\n SLPS_010.4* 500Kbyte Alias for file 003h (Boot EXE)\n SYSTEM.CNF 72bytes Alias for file 002h (Boot Info)\n XXXXXXXX. 27Mbyte Padding (zerofilled)\n FDLTBL.DAT seems to be used to divide the file list in CDRTBL.DAT into\n separate folders. The Folder List entries are containing the first file number\n for each folder. Empty folders have same file number as next entry.\n The last folder contains the specified file number plus all remaining files.\n 000h 56h*2 Folder List (16bit File Numbers, increasing from 0004h to 0xxxh)\n 0ACh 748h Zerofilled\n 7F4h 0Ah Game ID (ASCII \"SLPS1045\",00h,00h; always so on Disc 1..3)\n 7FEh 2 Disc ID (1..3 = Disc 1..3)\n 000h 8000h File List (1000h x 8-byte entries)\n File List entries:\n 000h 4 Sector (MM:SS:FF:00 in BCD, increasing) ;\\all zero for\n 004h 2 Size1 (NumFramesCh1 or NumSectors) ; unused entries\n 006h 2 Size0 (NumFramesCh0 or Zero) ;/\n The meaning of the Size entries depends on the file type:\n Normal binaries: [004h]=NumSectors [006h]=0 (1 channel)\n XA-ADPCM streams: [004h]=NumSectors-50h [006h]=0 (16 channels)\n MDEC streams: [004h]=NumFrames [006h]=0 (audio+video)\n Special streams: [004h]=NumFramesCh1 [006h]=NumFramesCh0 (2 channels)\n To determine the actual filesize, one must compute the difference between\n sectors for current and next used file entry (or end of CD.IMG for last file;\n or alternately assume last file to be a Normal Binary with Size=NumSectors).\n Normal Binaries:\n Contains single files (file=0/channel=0). Filetypes include TIM, VB, VH,\n other/custom file formats, and DOT1 archives.\n The DOT1 archives have 4-byte aligned offsets, but, unconventionally, with\n some offsets set to ZERO (usually the last entry, and sometimes also other\n entries):\n SEQ files (Disc1:Dir08h\\File173h) ;with ZERO entries (=uncommon)\n SEQ files (Disc1:Dir09h\\File176h..3D7h) ;with ZERO entries (=uncommon)\n SEQ files (Disc1:Dir0Ah\\File3DAh..3E6h) ;with ZERO entries (=uncommon)\n TIM files (Disc1:Dir4Fh\\File962h..983h) ;with ZERO entries (=uncommon)\n TIM files (Disc1:Dir0Ch\\File414h..426h) ;without ZERO entries (=normal DOT1)\n XA-ADPCM Streams (Disc1:Dir0Bh\\File3E7h..413h):\n These contain 16 audio streams (file=1/channel=00h-0Fh). The Size entry is\n set to total size in sectors for all streams, minus 50h (ie. there appears\n to be 50h sectors appended as padding before next file).\n MDEC Streams (Disc1:Dir53h\\FileBD1h..BEBh):\n These are standard STR files with MDEC video (file=0/channel=1) and\n XA-ADPCM (file=1/channel=1). There are 10 sectors per frame (8-9 video\n sectors plus 1-2 audio sectors). The total filesize is NumFrames*10+Align(8)\n sectors; the Align(8) might be there to include one final audio sector.\n Special Streams (Disc1:Dir07h\\File0E9h-16Eh and Dir50h\\File985h..B58h):\n These are custom STR files (non-MDEC format), perhaps containing Polygon\n streams or whatever.\n There are two channels (file=1/channel=00h-01h), each channel contains\n data that consists of 5 sectors per frame (1xHeader plus 4xData).\n The sectors have STR ID=0160h, and STR Type as follows:\n 0000h=Whatever special, channel 0 header (sector 0)\n 0400h=Whatever special, channel 1 header (sector 1)\n 0001h=Whatever special, channel 0 data (sector 2,4,6,8)\n 0401h=Whatever special, channel 1 data (sector 3,5,7,9)\n The File List size entries contain Number of Frames for each channel (either\n of these entries may be zero, or bigger/smaller/same than the other entry).\n The smaller channel is padded to same size as bigger channel (ie. total\n filesize is \"max(NumFramesCh0,NumFramesCh1)*10 sectors\"; though that formula\n doesn't always hold true, for example, Disc1:Dir50h\\FileA2Dh and FileB1Bh\n are bigger or smaller than expected).\n FILE.IDX\n 000h 8 ID \"FAdj0500\"\n 008h 38h RAM addresses (80xxxxxxh, 0Ch words)\n 038h 4 Zero\n 03Ch 4 RAM address (80xxxxxxh)\n 040h N*10h File List (including Folder start/end markers)\n FILE.BIN\n 000h .. File Data area (split into filesizes from FILE.IDX)\n Type 0 (Folder End):\n 000h 4 Type (0=Folder End)\n 000h 4 Zero\n 008h 4 RAM address (always 801EAF8Ch)\n 00Ch 4 Zero\n Type 1.a (Folder Start):\n 000h 4 Type (1=Folder Start)\n 000h 4 Folder Offset/800h (offset of FIRST file in this Folder)\n 008h 4 RAM address (always 801EAF8Ch)\n 00Ch 4 Folder Size/800h (size of ALL files in this Folder)\n Type 1.b (Force Offset, can occur between Files within a Folder):\n 000h 4 Type (1=Same as Folder Start)\n 000h 4 Folder Offset/800h (offset of NEXT file in this Folder)\n 008h 4 RAM address (always 801EAF8Ch)\n 00Ch 4 Folder Size/800h (zero for Force Offset)\n Type 2 (File entries, within Folder Start/End):\n 000h 4 Type (2=File)\n 004h 4 Filesize in bytes (4-byte aligned?)\n 008h 4 RAM address 1 (80xxxxxxh, or zero)\n 00Ch 4 RAM address 2 (80xxxxxxh)\nXenogears, Chrono Cross, and Threads of Fate contain only two files in the ISO filesystem (SYSTEM.CNF and the boot executable). The CDROMs contain standard ISO data in Sector 10h-16h, followed by Hidden stuff in Sector 17h and up:
Sector 10h (00:02:16) Volume Descriptor (CD001) ;\\\n Sector 11h (00:02:17) Volume Terminator (CD001) ;\n Sector 12h (00:02:18) Path Table 1 ;\n Sector 13h (00:02:19) Path Table 2 ; standard ISO\n Sector 14h (00:02:20) Path Table 3 ;\n Sector 15h (00:02:21) Path Table 4 ;\n Sector 16h (00:02:22) Root Directory ;/\n Sector 17h (00:02:23) Hidden ID ;\\\n Sector 18h (00:02:24) Hidden Directory ; hidden directory\n Sector .. (00:02:xx) Hidden Unknown ;/\n Sector .. (00:02:xx) Hidden Files... (referenced via Hidden Directory)\n Sector 17h (Hidden.ID)\n 000h 0Eh ID (\"DS01_XENOGEARS\"=Disc 1, or \"DS02_XENOGEARS\"=Disc 2)\n 00Eh 7F2h Zerofilled\n Sector 18h..27h\n 000h N*7 File List entries\n Sector 28h (Hidden.Unknown)\n Seems to contain a list of 16bit indices 0000h..1037h,FFFFh in File List\n (that, as raw list indices, regardless of the directory structure)\n 000h Unknown 0016 0018 FFFF FFFF 01A8 FFFF FFFF FFFF ;\\\n 010h Unknown FFFF FFFF FFFF FFFF 0A35 0A3A 0D35 0AD3 ; as so on Disc 2\n 020h Unknown 0A22 0A2E 0A2F FFFF FFFF FFFF FFFF FFFF ; (values<>FFFFh\n 030h Unknown 0014 0001 0013 FFFF 0075 FFFF FFFF FFFF ; on Disc 1\n 040h Unknown 0C10 0C14 0C15 0C19 0F52 FFFF FFFF FFFF ; are 5 less, eg.\n 050h Unknown 0F4C 0B6E 0C4D 1037 0C09 0BAD FFFF FFFF ; 0011,0013,FFFF..)\n 060h Unknown 002E 0034 FFFF FFFF FFFF FFFF FFFF FFFF ;\n 070h Unknown FFFF FFFF FFFF FFFF ;/\n 078h 2 Disc Number (0001h=Disc 1, 0002h=Disc 2)\n 07Ah 786h Zerofilled\n Sector 29h 1st file\n 000h 3 24bit Offset (increasing sector number, or 0=special)\n 003h 4 32bit Size (filesize in bytes, or negative or 0=special)\n offset=curr, size=+N file at sector=curr, size N bytes\n offset=curr, size=-N begin of sub-directory, with N files\n offset=curr, size=0 empty file, size 0 bytes\n offset=0, size=0 unused file entry\n offset=FFFFFFh, size=0 end of root-directory\n Sector 17h (Hidden.ID)\n 000h 2 Disc Number (0001h=Disc 1, 0002h=Disc 2)\n 002h 2 Number of Discs? (0002h) (always 2, even if only 1 disc)\n 004h 2+2 Sector and Size for Hidden.ID (Sector=0017h, Size=002Ch)\n 008h 2+2 Sector and Size for Hidden.Directory (Sector=0018h, Size=60E0h)\n 00Ch 2+2 Sector and Size for Hidden.Unknown (Sector=0025h, Size=0022h)\n 010h 10h Zerofilled\n 020h 0Ch Title ID (\"CHRONOCROSS\",00h) ;Chrono Cross (retail)\n 09h Title ID (\"DEWPRISM\",00h) ;Threads of Fate (retail)\n 10h Title ID (\"DEWPRISM_TAIKEN\",00h) ;Threads of Fate (demo)\n 0xxh 7xxh Zerofilled (unused, since Hidden.ID has only Size=2Ch/29h/30h)\n Sector 18h..24h (Hidden.Directory)\n 000h N*4 File List entries\n ... .. Zeropadding (till Size=60E0h, aka 6200 entries)\n ... 720h Zeropadding (till end of 800h-byte sector)\n Sector 25h (Hidden.Unknown)\n Seems to contain a list of 16bit indices 0000h..1791h,FFFFh in File List\n (though many of the listed indices are unused file list entries)\n 000h 2 Disc Number (0001h=Disc 1, 0002h=Disc 2)\n 002h 10h Unknown 0000 1791 1777 1775 00ED 09DF FFFF 0002 ;\\same on\n 012h 10h Unknown 0025 0943 10E3 FFFF FFFF 0C77 0FD9 0FA3 ;/Disc 1+2\n 022h .. Zerofilled (unused, since Hidden.ID has only Size=0022h)\n Sector 26h 1st file (same as boot EXE in ISO)\n 0-22 Sector number\n 23 Flag (0=Normal, 1=Unused entry)\n 24-31 Number of unused bytes in last sector, div8 (0..FFh = 0..7F8h bytes)\n filesize = ([addr+4]-[addr] AND 7FFFFFh)*800h - ([addr+3] AND FFh)*8\nThe demo version is using the same directory format as retail version (but with Virtual Sector numbers in HED+EXE+IMG files instead of Hidden Sectors).
TOF\\DEWPRISM.HED (6000h bytes) VirtSector=1Ah, PhysSector=A0A5h\n TOF\\DEWPRISM.EXE (97800h bytes) VirtSector=26h, PhysSector=A0B1h\n TOF\\DEWPRISM.IMG (19EA800h bytes) VirtSector=155h, PhysSector=A1E0h\n 000h 52Ch List for .DAT file ;value 0000h..6FFFh = sector 0..6FFFh in DAT\n 52Ch D4h Zerofilled\n 600h C4h List for .BNS file ;value 7000h..71AFh = sector 0..1AFh in BNS\n 6C4h 3Ch Zerofilled\n 700h 50h List for .STR file(s) ;raw CDROM sector numbers from 00:02:00\n 750h B0h Zerofilled\n 0-19 File Offset/800h (20bit)\n 20-31 File Size/800h (12bit)\n .HED is 2048 bytes\n .DAT is 58720256 bytes = 3800000h bytes ;div800h would be 7000h\n .BNS is 884736 bytes = D8000h bytes ;div800h would be 1B0h\n .STR's: 7D3Bh+150 = 7DD1h = sector for STR\\LAB.STR\nBelow are two slightly different formats. WAD.WAD has unused entries 00h-filled. The PKG format has them FFh-filled, and does additionally support Folders, and does have a trailing ASCII string. There's also a difference on whether or not to apply alignment to empty 0-byte files. However, the formats can appear almost identical (unused entries, 0-byte files, and folders are optional, without them, the only difference would be the presence of the ASCII string; which does exist only in 800h-byte aligned PKG's though).
"},{"location":"cdromfileformats/#wadwad-crashcrash","title":"WAD.WAD (Crash/Crash)","text":"Used by Crash Bandicoot 3 (DRAGON\\WAD.WAD, plus nested WADs inside of WAD.WAD) Used by Crash Team Racing (SPYR02\\WAD.WAD, plus nested WADs inside of WAD.WAD) Used by Madden NFL'98 (MagDemo02: TIBURON.DAT except PORTRAIT,SPRITES,XA.DAT) Used by N2O (MagDemo09, N2O\\PSXMAP.TRM and N2O\\PSXSND.SND) Used by Speed Racer (MagDemo10: SPDRACER\\ALL1.BIN, with 0-byte, unpadded eof) Used by Gran Turismo 2 (MagDemo27: GT2\\GT2.OVL = 128Kbyte WAD.WAD with GZIP's) Used by Jonah Lomu Rugby (LOMUDEMO\\SFX\\.VBS, ENGLISH\\.VBS) Used by Judge Dredd (*.CAP and *.MAD) Used by Spyro 2 Ripto's Rage (SPYRO2\\WAD.WAD, and nested WAD's therein) Used by Spyro 3 Year of the Dragon (SPYRO3\\WAD.WAD, and nested WAD's therein) Used by Men: Mutant Academy (MagDemo33: PSXDATA\\WAD.WAD\\*, childs in PWF)
000h N*8 File List\n ... .. Zeropadding to 4-byte or 800h-byte boundary (or garbage padding)\n ... .. File Data...\n 000h 4 Offset in bytes (4- or 800h-byte aligned, increasing) ;\\both zero\n 004h 4 Size in bytes (always multiples of 800h bytes) ;/when Unused\nThis does resemble standard WAD.WAD, but with leading 800h-byte extra stuff.
000h 4 ID (\"PWF \") ;\\\n 004h 4 Total Filesize (707800h) ;\n 008h 4 Unknown (1) ; extra stuff\n 00Ch 4 Number of files (N) ;\n 010h 7F0h Zerofilled ;/\n 800h N*8 File List ;\\\n ... .. Zerofilled (padding to 800h-byte boundary) ; standard WAD.WAD\n ... .. File Data area ;/\n File List entries:\n 000h 4 File Offset in bytes (increasing, 800h-byte aligned)\n 004h 4 File Size in bytes\nUsed by Pandemonium II (JESTERS.PKG, with Files+Folders+Unused entries) Used by Herc's Adventure (BIG.BIN, with Files+Unused entries, without Folders) Used by Unholy War (MagDemo12:CERBSAMP.PKG, with 0-byte files and nested PKG's) Used by 102 Dalmatians (MagDemo40: PTTR\\PSXDEMO.PKG)
000h N*8 File List\n ... .. ASCII string (junk, but somewhat needed as nonzero end marker)\n ... .. Zeropadding to 800h-byte boundary; not in 4-byte aligned nested PKG\n ... .. File Data...\n 000h 4 Offset in bytes (increasing, or 0=First child) ;\\both FFFFFFFFh\n 004h 4 Size in bytes (always nonzero) ;/when Unused\n<B> Example</B>\n 00003800h,00000666h ;root00h (file 666h bytes, padded=800h)\n 00004000h,00000300h ;root01h\\.. (folder 300h bytes, padded=800h)\n 00000000h,000000FDh ;root01h\\child00h (file FDh bytes, padded=100h) ;\\300h\n FFFFFFFFh,FFFFFFFFh ;root01h\\child01h (unused) ; byte\n 00000100h,000001FDh ;root01h\\child02h (file 1FDh bytes, padded=200h) ;/\n 00004800h,00001234h ;root02h (file 1234h bytes, padded=1800h)\n 00006000h,00001234h ;root03h (file 1234h bytes, padded=1800h)\n FFFFFFFFh,FFFFFFFFh ;root04h (unused)\n 00007800h,00001234h ;root05h (file 1234h bytes, padded=1800h)\n etc.\n 000h 4 Number of Files (eg. F4h)\n 004h 0Ch Zero\n 010h N*10h File entries\n ... 4 Archive ID (eg. 00000000h, FF53EC8Bh, or 83FFFFFFh)\n ... .. Zeropadding to 800h byte boundary\n ... .. File Data\n 000h 4 Archive ID (same value as in above header)\n 004h 4 Filename checksum or so (randomly ordered, not increasing)\n 008h 4 Filesize in bytes\n 00Ch 4 Fileoffset (800h-byte aligned) (increasing)\n looks like a lot of raw data without meaningful file headers...\n file C3h,ECh are raw SPU-ADPCM\n file 08h,09h are nested BIG archives, but with FileEntry[00h]=FF53EC8Bh\n file D9h,DAh are nested BIG archives, but with FileEntry[00h]=83FFFFFFh\nUsed by Gex 2: Enter the Gecko (BIGFILE.DAT) Used by Gex 3: Deep Cover Gecko (MagDemo20: G3\\BIGFILE.DAT) -- UNSORTED Used by Akuji (MagDemo18: AKUJI\\BIGFILE.DAT) Used by Walt Disney World Racing Tour (MagDemo35: GK\\BIGFILE.DAT) -- UNSORTED
000h 4 Number of Files (C0h)\n 004h N*18h File entries\n ... .. Zeropadding to 800h byte boundary\n ... .. File Data\n 000h 4 Random\n 004h 4 Filesize in bytes (uncompressed size)\n 008h 4 Filesize in bytes (compressed size, or 0=uncompressed)\n 00Ch 4 Fileoffset (800h-byte aligned) (increasing, unless UNSORTED)\n 010h 4 Random\n 014h 4 Random (or ascii in 1st file)\n @@collect_more:\n flagbits=[src]+[src+1]*100h+10000h, src=src+2 ;16bit flags, unaligned\n @@decompress_lop:\n if dst>=dst.end then goto @@decompress_done\n flagbits=flagbits SHR 1\n if zero then goto @@collect_more\n if carry=0 then\n [dst]=[src], dst=dst+1, src=src+1\n else\n len=([src] AND 0Fh)+1), disp=([src] AND 0F0h)*10h+[src+1], src=src+2\n if len=1 or disp=0 then goto invalid ;weirdly, these are left unused\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n endif\n goto @@decompress_lop\n @@decompress_done:\n ret\n standard TIM (eg. file 01h,02h)\n malformed TIM (eg. file 0Fh,14h) (with [8]=2*cx*cy+4 instead 2*cx*cy+0Ch)\n crippled VAB (eg. file 0Eh,13h) (with hdr=filesize-4 plus raw ADPCM samples)\n several DNSa (eg. file 0Dh,12h,17h,BCh) SND sound? (also used by kain)\n PMSa (eg. Gex 3, World Racing) (SMP spu-adpcm samples)\n there seem to be no nested DAT files inside of the main DAT file\n 000h 1 ID (DBh)\n 001h 1 Number of Types\n 002h 2 Zero (0)\n 004h N*4 Type List\n ... .. File Lists & File Data for each Type\n 000h 3 Offset to File List (self-relative, from current entry in Type List)\n 003h 1 Data Type (00h..1Fh)\n 000h 1 Data type (00h..1Fh) (same as in Type List)\n 001h 1 Number of Files\n 002h 2 Zero (0)\n 004h N*2 File ID List (unique ID per type) (different types may have same ID)\n ... .. Zeropadding to 4-byte boundary\n ... N*4 Offset List (self-relative, from current entry in Offset List)\n ... 4 End Offset (first-relative, from first entry in Offset List)\n ... .. File Data (referenced from above Offset List)\n 00h Misc (DOT1 Archives, or other files)\n 01h Unused?\n 02h Reportedly 3D Model data (vertices,quads,triangles,texcoords)\n 03h Reportedly 3D Animation sequences\n 04h TIM Texture\n 05h Reportedly Scripts (hdr=\"EV\") (eg. dir04\\file32\\1B-0001)\n 06h ? (eg. dir02\\file*)\n 07h Sound \"Sequencer Data\" (hdr=\"AKAO\") (eg. dir09\\file*)\n 08h Sound? tiny files (hdr=\"AKAO\") (eg. dir04\\file32\\1B-0001)\n 09h Sound Samples (hdr=\"AKAO\") (eg. dir0B\\file*)\n 0Ah Reportedly Field Tiles and Field Camera parameters\n 0Bh Reportedly Field Walkmesh (eg. dir04\\file32\\1B-0001)\n 0Ch Reportedly Battle Scene geometry (eg. dir06\\file*)\n 0Dh ? (eg. dir01\\file01)\n 0Eh Unused?\n 0Fh Unused?\n 10h ? (eg. dir05\\file*)\n 11h ? (eg. dir05\\file*)\n 12h Reportedly CLUT and TPage info for models (eg. dir04\\file32\\1B-0001)\n 13h Unused?\n 14h ? (eg. dir05\\file*)\n 15h Unused?\n 16h ? (eg. dir04\\file32\\1B-0001)\n 17h ? (eg. dir04\\file32\\1B-0000)\n 18h Sound (hdr=\"AKAO\") (eg. dir04\\file32\\1B-0001)\n 19h ? (eg. dir04\\file32\\1B-0001)\n 1Ah ? (eg. dir06\\file*)\n 1Bh DB Archives (ie. further DB's nested inside of the parent DB archive)\n 1Ch ? (eg. dir04\\file32\\1B-0001)\n 1Dh ? (eg. dir03\\file2328\\1B-0001)\n 1Eh ? (eg. dir04\\file32\\1B-0001)\n 1Fh ? (eg. dir04\\file32\\1B-0001)\n 20h..FFh Unused?\nThere are two archives, stored in three files:
ACE2.DAT Directory for Data in ACE2.DAT itself ;normal binary data\n ACE2.STH Directory for Data in separate ACE2.STP file ;streaming data\n 000h 4 Unknown (1)\n 004h 4 Number of entries (N)\n 008h N*8 File List\n 0-27 28bit Size/N (DAT=Size/4, STP=Size/800h)\n 28-31 4bit Type or Channel Number (see below)\n 32-63 32bit Offset/800h in ACE2.STP or ACE2.DAT file\n File Bit28-31 Channel Sector types... Interleave Notes\n DAT 0 ch=0 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 1:1 data (normal)\n DAT 2 ch=0 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 1:1 data (exe)\n STH 0-6 ch=0-6 S.......S.......S.......S....... 1:8 stereo\n STH 8 ch=1 vvvvvvvSvvvvvvvSvvvvvvvSvvvvvvvS 1:1 video+stereo\n Whereas D=data, S=Stereo/Audio, v=video, .=other channels\nThere are two archives, stored in four files:
ACE.BPH Directory for Data in separate ACE.BPB file ;normal binary data\n ACE.SPH Directory for Data in separate ACE.SPB file ;streaming data\n 000h 4 ID \"AC3E\" (=Ace Combat 3 Electrosphere)\n 004h 4 Type (BPH=3=Data?, SPH=1=Streaming?)\n 008h 2 BCD Month/Day? (Japan=0427h, US=1130h)\n 00Ah 2 BCD Year (or zero) (SPH=1999h, BPH=0)\n 00Ch 4 Unknown (SPH=0, BPH/US=16CFh or BPH/JP=1484h)\n 010h 4 Number of entries (N)\n 014h N*8 File List\n 0-18 19bit Size/N (BPH=Size/4, SPB=Size/800h)\n 19-23 5bit Channel Number (BPH=0, SPH=0..1Fh)\n 24-26 3bit Channel Interval (BPH=0, SPH=1 SHL N, eg. 3=Interval 1:8)\n 27 1bit Video Flag (0=No, 1=Has Video sectors)\n 28 1bit Audio Flag (0=No, 1=Has Audio sectors)\n 29 1bit Always 1 (except special entries with Bit31=0, see below)\n 30 1bit Unknown (US: Always 1, Japan: 0 or 1)\n 31 1bit Always 1 (except special entries with Bit31=0, see below)\n 32-63 32bit Offset/800h in ACE.BPB or ACE.SPB file (or 0 when bit31=0 ?)\n For unknown purpose, the normal entries with Bit31=1 are occassionally followed by one or more entries with Bit31=0.\n Unknown if those entries do affect the actual storage (like switching to\n different channel numbers, or jumping to non-continous sector numbers).\n That unknown stuff exists in Japanese version only, not in US version.\n 0-18 19bit Unknown (maybe some snippet size value in whatever units?)\n 19-23 5bit Always 0 (instead of Channel)\n 24-27 4bit Same as in most recent entry with Bit31=1\n 28-31 4bit Always 5 (instead of Flags)\n 32-63 32bit Always 0 (instead of Offset)\n File Bit24-31 Sector types... Interval Content\n BPH.US E0h DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 1:1 data\n SPH.US F8h SvvvvvvvSvvvvvvvSvvvvvvvSvvvvvvv 1:1 stereo+video\n SPH.US FBh S.......v.......S.......v....... 1:8 stereo+video\n SPH.US F3h S.......S.......S.......S....... 1:8 stereo\n SPH.US F4h S...............S............... 1:16 stereo\n SPH.US F5h M............................... 1:32 mono\n BPH.JAP E0h DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 1:1 data\n SPH.JAP B8h,F8h SvvvvvvvSvvvvvvvSvvvvvvvSvvvvvvv 1:1 stereo+video\n SPH.JAP B9h Svvv....vvvv....Svvv....vvvv.... 1:2 (4:8) stereo+video\n SPH.JAP BAh,FAh Mv......vv......vv......vv...... 1:4 (2:8) mono+video\n SPH.JAP BBh,FBh S.......v.......S.......v....... 1:8 stereo+video\n SPH.JAP B3h,F3h S.......S.......S.......S....... 1:8 stereo\n SPH.JAP B5h,F5h M............................... 1:32 mono\n Whereas D=data, S=Stereo/Audio, M=Mono/Audio, v=Video, .=Other channels\n v0 Crash Bandicoot Prototype (oldest known prototype from 08 Apr 1996)\n v1 Crash Bandicoot 1 (retail: S*\\*.NSD and .NSF)\n v2 Crash Bandicoot 2 (MagDemo02: CRASH\\S0\\*.NSD and .NSF)\n v3 Crash Bandicoot 3 Warped (MagDemo26,50: (S0\\*.NSD and .NSF)\n 0000h 100h*4 Lookup Table, using index=((Filename/8000h) AND FFh) ;\\\n 0400h 4 Number of Chunks in .NSF file ; Lookup\n 0404h 4 Number of Files in Lookup File List (N) ;/\n 0408h 4 Level Data Filename (eg. 4F26E8DFh=\"DATh.L\") ;-LevelDat\n 040Ch 4 Bitmap Number of Colors (100h) (P) (0=None) ;\\\n 0410h 4 Bitmap Width (200h or 1B0h) (X) (0=None) ; Bitmap\n 0414h 4 Bitmap Height (0D8h or 090h) (Y) (0=None) ;/\n 0418h 4 Compression: Offset/800h of first uncompressed chunk ;\\\n 041Ch 4 Compression: Number of compressed chunks (0..40h) ; Compress\n 0420h 40h*4 Compression: Compressed Chunk List (0=unused entry) ;/\n ... N*8 Lookup File List ;-Lookup\n ... .. Level Data (size/format varies, see below) ;-LevelDat\n ... P*2 Bitmap Palette (16bit values, 8000h..FFFFh) ;\\Bitmap\n ... X*Y Bitmap Pixels (0D8h*200h) ;/\n v0 NSD Filesize=408h + N*8 ;-Lookup only\n v1 NSD Filesize=520h + N*8 + P*2+X*Y + 210h ;\\\n v2 NSD Filesize=520h + N*8 + P*2+X*Y + 1DCh+S*18h ; with extra stuff\n v3 NSD Filesize=520h + N*8 + P*2+X*Y + 2DCh+S*18h ;/\nThe lookup table allows to find files (by filenames) in the NSF files. It does merely contain the NSF chunk number, so one must load/decompress that chunk to find the file's exact size/location in that chunk. One can create a complete file list by scanning the whole NSF file without using the NDS lookup table.
Lookup File List entries (indexed via Lookup Table):\n 00h 4 Chunk Number in .NSF file\n 04h 4 Filename (five 6bit characters)\n 0 Type (always 1=Filename) (as opposed to 0=Memory Pointer)\n 1-6 5th character ;-Extension ;\\character set is:\n 7-12 4th character ;\\ ; 00h..09h=\"0..9\"\n 13-18 3rd character ; Name ; 0Ah..23h=\"a..z\"\n 19-24 2nd character ; ; 24h..3Dh=\"A..Z\"\n 25-30 1st character ;/ ;/3Eh..3Fh=\"_\" and \"!\"\n 31 Always zero?\nLevel Data exists in NSD v1-v3 (v0 does also have Level Data, but it's stored in NSF file \"DAT*.L\" instead of in the NSD file). There are two major versions:
Level Data in NSD v1 (or NSF v0 file DAT*.L):\n 000h 4 01h ;\\\n 004h 4 Level Number (xxh) (same as xx in S00000xx.NSD/NSF) ;\n 008h 4 3807C8FBh = \"s0_h.Z\" ? ; LevelDat\n 00Ch 4 Zero ; v1\n 010h 4 Zero ;\n 014h L*4 Namelist (40h*4) ;\n ... 4 5Ah ;\n ... F8h Zerofilled ;/\n Level Data in NSD v2-v3:\n 000h 4 Number of Spawn Points (S) ;\\\n 004h 4 Zero ;\n 008h 4 Level Number (xxh) (same as xx in S00000xx.NSD/NSF) ; LevelDat\n 00Ch 4 Number of Objects? (can be bigger than below list) ; v2/v3\n (eg. 1BDh or A5h or E4h) ;\n 010h L*4 Namelist for Objects? (v2=40h*4, or v3=80h*4) ;\n ... 4 Unknown, always 5Ah (maybe just list end marker?) ;\n ... C8h Zerofilled ;\n ... S*18h Spawn Points ;/\nThis bitmap is displayed while loading the level.
"},{"location":"cdromfileformats/#nsd-compression-info","title":"NSD Compression Info","text":"Compression is only used in v1 (v2-v3 do also have the compression entries at [418h..51Fh], but they are always zerofilled).
Compressed Chunk List entries at [420h..51Fh]:\n 0-5 Compressed Chunk Size/800h (1..1Fh=800h..F800h bytes, 20h..3Fh=Bad?)\n 6-31 Compressed Chunk Offset/800h\nNSF files consist of 64Kbyte chunks (compressed chunks are smaller, but will be 64Kbyte after decompression). Each chunk can contain one or more file(s). That implies that all files must be smaller than 64Kbyte (larger textures or ADPCM samples must be broken into multiple smaller files). All files (except Textures) are NSF Child Archives which contain one or more smaller files/items.
"},{"location":"cdromfileformats/#nsf-chunk-types","title":"NSF Chunk Types","text":" N*8Kbyte-Compressed-chunks:\n 000h 2 ID, always 1235h (instead of 1234h)\n 002h 2 Zero\n 004h 4 Decompressed Size (max 10000h) (usually 9xxxh..Fxxxh, often Fxxxh)\n 008h 4 Skip Size (max 40h or so, when last LZSS_len was 40h)\n 00Ch .. Compressed data\n ... SK Unused (Skip size)\n ... .. Final uncompressed bytes (10000h-compressed_size-skip_size)\n 64Kbyte-Texture-chunks:\n 000h 2 ID, always 1234h\n 002h 2 Chunk Family (1=Texture)\n 004h 4 Filename (five 6bit characters)\n 008h 4 File Type (5=Texture)\n 00Ch 4 Checksum (sum of bytes ar [0..FFFFh], with initial [0Ch]=00000000h)\n 010h ... Zerofilled\n 020h ... Texture data (raw VRAM data, FFE0h bytes?)\n 64Kbyte-NonTexture-chunks:\n 000h 2 ID, always 1234h\n 002h 2 Chunk Family (0=Misc or 2..5=Sound)\n 004h 4 Chunk Number*2+1\n 008h 4 Number of Files (N) (can be 0, eg. prototype S0000003 chunk21h)\n 00Ch 4 Checksum (sum of bytes ar [0..FFFFh], with initial [0Ch]=00000000h)\n 010h N*4 File List (Offsets from ID=1234h to entries) (4-byte aligned)\n ... .. Offset for end of last File\n ... .. File Data (NSF Child Archives) (includes Type/Filename)\n ... .. Padding to 10000h-byte boundary\n 000h 4 ID, always 0100FFFFh\n 004h 4 Filename (five 6bit characters)\n 008h 4 File Type (01h..04h, or 06h..15h)\n 00Ch 4 Item Count (I)\n 010h I*4 Item List (Offsets from ID=0100FFFFh to items) (...unaligned?)\n ... .. Offset for end last item\n ... .. Data (Items)\nThe compression is a mixup of LZSS and RLE. Compressed chunks are max F800h bytes tall (10000h bytes after decompression).
dst=chunk_buffer_64kbyte\n if chunksize is known (from NSD file)\n src=dest=dst+10000h-chunksize\n diskread(fpos,src,chunksize)\n else (when parsing raw NSF file without NSD file)\n src=temp_buffer_64kbyte\n diskread(fpos,src,10000h)\n dst_start=dst, src_start=src\n if halfword[src+00h]<>1234h then ;check ID (1234h=raw, or 1235h=compressed)\n dst_end=dst+word[src+04h]\n skip_size=word[src+08h]\n src=src+0Ch\n while dst<dst_end\n x=[src], src=src+1\n if x<80h then\n for i=0 to x-1, [dst]=[src], dst=dst+1, src=src+1, next i ;uncompressed\n else\n x=(x AND 7Fh)*100h+[src], src=src+1\n disp=x/8, len=(x AND 7)+3, if len=0Ah then len=40h\n for i=0 to len-1, [dst]=[dst-disp], dst=dst+1, next i ;compressed\n src=src+src_skip\n if src<>dst then\n while dst<dst_start+10000h, [dst]=[src], dst=dst+1, src=src+1 ;uncompressed\n chunksize=src-src_start ;<-- compute (when chunksize was unknown)\n fpos=fpos+chunksize ;<-- fileposition of next chunk\nBelow shows File Type, Chunk Family, Extension (5th character of filename), the version where the type is used, 4-letter type names (as found in the EXE files), and a more verbose description.
Typ Family Ext Ver Name Description\n 00h - ! - NONE Nothing\n 01h 0 V all SVTX Misc.Vertices\n 02h 0 G all TGEO Misc.Model ;\\changed format in v2-v3 ?\n 03h 0 W all WGEO Misc.WorldScenery ;/\n 04h 0 S all SLST Misc.UnknownSLST\n 05h 01h T all TPAG Texture.VRAM\n 06h 0 L v0 LDAT Misc.LevelData ;-stored in NSD in v1-v3\n 07h 0 Z all ZDAT Misc.Entity ;-changed format in v2-v3 ?\n 08h - - - CPAT Internal?\n 09h - - - BINF Internal?\n 0Ah - - - OPAT Internal?\n 0Bh 0 C all GOOL Misc.GoolBytecode\n 0Ch 02h A v0 ADIO OldSound.Adpcm ;\\type 0Ch\n 0Ch 03h A all ADIO Sound.Adpcm ;/\n 0Dh 0 M all MIDI Misc.MidiMusic ;-changed format in v1-v3 ?\n 0Eh 04h N all INST Sound.Instruments\n 0Fh 0 D v0-1 IMAG Misc.UnknownIMAG ;\\type 0Fh\n 0Fh 0 X v2-3 VCOL Misc.UnknownVCOL ;/\n 10h - - - LINK Internal?\n 11h 0 P v0-1 MDAT Misc.UnknownMDAT ;\\type 11h\n 11h 0 R v3 RAWD Misc.UnknownRAWD ;/\n 12h 0 U v0-1 IPAL Misc.Unknown ;-Crash 1 only? (eg. S0000019.NSF)\n 13h 0 B v1-3 PBAK Misc.DemoPlayback ;-eg. in MagDemo02\n 14h 0 V v0-1 CVTX Misc.UnknownCVTX ;\\type 14h\n 14h 05h O v2-3 SDIO Speech.Adpcm ;/\n 15h 0 D v2-3 VIDO Misc.UnknownVIDO\nhttps://gist.github.com/ughman/3170834
https://dl.dropbox.com/s/fu29g6xn97sa4pl/crash2fileformat.html
"},{"location":"cdromfileformats/#weird-note","title":"Weird Note","text":"\"Sound entries don't need to be aligned as strictly for most (all?) emulators.\" What does that mean??? Is there a yet unknown 16-byte DMA alignment requirement on real hardware?
"},{"location":"cdromfileformats/#cdrom-file-archive-stagedir-and-dat-metal-gear-solid","title":"CDROM File Archive STAGE.DIR and *.DAT (Metal Gear Solid)","text":"Metal Gear Solid (MagDemo13: MGS\\) Metal Gear Solid (MagDemo25: MGS\\) Metal Gear Solid (MagDemo44: MGS\\) (looks same as in MagDemo13) Metal Gear Solid (Retail: MGS\\)
"},{"location":"cdromfileformats/#summary-of-iso-files-in-mgs-folder-with-filesizes-for-different-releases","title":"Summary of ISO files in MGS folder (with filesizes for different releases)","text":" File MagDemo13/44 MagDemo25 Retail/PAL\n .EXE 9C000h 9C800h 9D800h ;-executable\n STAGE.DIR 590800h 11A7800h 42AE000h ;-main archive\n FACE.DAT 2CA000h 3Dh (txt) 358800h ;-face animation archive\n ZMOVIE.STR - - 2D4E800h ;-movie archive\n DEMO.DAT 149B000h 3Dh (txt) EC20000h ;\\DAT/SYM combos (the .SYM\n DEMO.SYM 88h - - ; files were leaked in\n VOX.DAT 14F2000h 9F800h B054800h ; MagDemo13/MagDemo44 only)\n VOX.SYM 988h - - ;/\n BRF.DAT - 66800h 575800h ;\\whatever, unknown format(s)\n RADIO.DAT 16CB8h 3Dh (txt) 1AA956h ;/\n 000h 4 Size of File List (N*0Ch)\n 004h N*0Ch Folder List\n ... .. Zeropadding to 800h-byte boundary\n ... .. Folder Data\n Folder List entries:\n 000h 8 Foldername (zeropadded if less than 8 chars) ;nickname=stg\n 008h 4 Offset/800h to File List\n Folder Data (per folder):\n 000h 2 Unknown (always 1) (maybe File List size/800h?)\n 002h 2 Folder Size/800h (of whole folder, with file list plus file data)\n 004h N*8 File List\n ... Zeropadding to 800h-byte\n 800h Data (for files in current folder)\n File List entries:\n 000h 2 File ID (checksum on name)\n 002h 1 File Family (one of following chars: \"cnrs\")\n 003h 1 File Type (one of following chars: \"abcdeghiklmoprswz\",FFh)\n 004h 4 File Size (or File Offset, when File Family=\"c\")\n .?a ???? if any ???? (does NOT exist on PAL disc 1) ;nickname=azm\n .sb MIPS binary code (leading) ;nickname=bin\n .cc Whatever (eg. vr10\\*, s01a\\*) ;nickname=con\n .nd Texture Archive (leading) (contains PCX files) ;nickname=dar\n .rd Misc Archive (leading) (eg. init\\*) ;nickname=dar\n .se Sound Effects? (trailing) ;nickname=efx\n .cg Whatever, reportedly bytecode functions ;nickname=gcx\n .ch Whatever ;nickname=hzm\n .ci Whatever (eg. ending\\*, s01a\\*) ;nickname=img\n .ck Whatever, model? aka \"pat_xxx\" files ;nickname=kmd\n .cl Lights, first word = size/10h ;nickname=lit\n .sm Sound Music? Nested DOT1+DOTLESS Archives ;nickname=mt3\n .co Whatever \"OARa\" (eg. d16e\\*, s00a\\*, s02c\\*) ;nickname=oar\n .cp PCX bitmap (eg. init\\*) ;nickname=pcc\n .cr Whatever \"sNRJ1F\" (eg. roll\\*) ;nickname=rar\n .cs Whatever (eg. d16e\\*, s01a\\*) ;nickname=sgt\n .sw Wave Archive (trailing) ;nickname=wvx\n .cz Whatever \"KMDa\" (eg. s11a, a11c, s14e, s15a) ;nickname=zmd\n .c,FFh End of Family=\"c\" area ;nickname=dar?\nThis contains several large blocks (supposedly one per stage, each block having its own file list). There is no directory to find the begin of the separate blocks, but one can slowly crawl through the file:
NextBlock = CurrBlock + 4 + Offset(lastfile)+Size(lastfile) + Align800h\n 000h 4 Number of Files in this block (eg. 19h or 1Ch)\n 004h N*0Ch File List for this block\n ... .. File Data for this block\n ... .. Zeropadding to 800h-byte boundary (followed by next block, if any)\n File List entries:\n 000h 2 File Type (0=Main/Eye/Mouth frames, 1=All frames are full size)\n 002h 2 File ID (name checksum?)\n 004h 4 Filesize in bytes\n 008h 4 Offset in bytes, minus 4\n This type use a single palette for all frames, and only the first frame is\n full 52x89pix, the other frames contain only the update sections (eg. eyes).\n 000h 4 Offset to 200h-byte palette (usually 20h) ;\\Main\n 004h 4 Offset to Main Bitmap (52x89pix) (usually 220h) ;/\n 008h 4 Offset to 4th Bitmap (usually xxxxh or 0=None) ;\\Eyes\n 00Ch 4 Offset to 5th Bitmap (usually xxxxh or 0=None) ;/\n 010h 4 Zero\n 014h 4 Offset to 2nd Bitmap (usually 143Ch or 0=None) ;\\Mouth\n 018h 4 Offset to 3rd Bitmap (usually xxxxh or 0=None) ;/\n 01Ch 4 Zero\n 020h 200h Palette (256 colors) ;\\Main\n 220h 1218h Main Bitmap ;/\n 1438h 4 Zero\n 143Ch .. 2nd Bitmap (if any) ;\\Mouth\n ... .. 3rd Bitmap (if any) ;/\n ... .. 4th Bitmap (if any) ;\\Eyes\n ... .. 5th Bitmap (if any) ;/\n This type use separate palettes for each frame, all frames are full 52x89pix.\n 000h 4 Number of frames\n 004h N*0Ch Frame List\n ... 200h 1st Frame Palette\n ... 1218h 1st Frame Bitmap (52x89pix)\n ... 4 ?\n ... 200h 2nd Frame Palette\n ... 1218h 2nd Frame Bitmap (52x89pix)\n ... 4 ?\n ... .. 3rd Frame ...\n Frame List entries:\n 000h 4 Offset to Palette\n 004h 4 Offset to Bitmap (usually at Palette+200h)\n 008h 4 Unknown (often 000x000xh)\n 000h 1 Offset X (always 00h in Main Bitmap)\n 001h 1 Offset Y (always 00h in Main Bitmap)\n 002h 1 Width (always 34h in Main Bitmap, or less in 2nd-5th bitmap)\n 003h 1 Height (always 59h in Main Bitmap, or less in 2nd-5th bitmap)\n 004h .. Bitmap Pixels at 8bpp (Width*Height bytes)\nThe .DAT files contain several huge blocks, found on 800h-boundaries starting with:
10 08 00 00 0x 00 00 00 ..\n \"0xNNNNNNNN name\",0Ah\nWhatever, contains chunks with text messages, chunks are about as so:
000h 4 Unknown (eg. 36h,BFh,5Eh,00h)\n 004h 4 Unknown (eg. 03h,13h,00h,00h)\n 008h 1 Unknown (eg. 80h)\n 009h 2 Chunk Size (eg. 0xh,xxh) ;big-endian\n .. .. Chunk Data (Chunk Size-2 bytes) (binary stuff, and text strings)\nContains several \"folders\" in this format:
000h 4 Number of files in this folder\n 004h .. File(s)\n ... .. 01h-padding to 800h-byte boundary\n Files have this format:\n 000h .. Filename (\"name.pll\",00h)\n ... .. Zeropadding to 4-byte boundary (aligned to begin of BRF.DAT)\n ... 4 File data size (usually a multiple of 4)\n ... .. File data\n ... 1 Zero (00h)\n 000h .. PCX file (starting with 0A,05,01,01 or 0A,05,01,08)\n ... .. 01h-padding to 800h-byte boundary\nCDROM File Video Streaming STR Variants
"},{"location":"cdromfileformats/#stagedirsb-stage-binaryheader","title":"STAGE.DIR\\\\.sb - stage binary/header","text":"This is the first file in most folders (except \"init*\" folders). The file contains MIPS binary program code. And, there are ascii strings near end of .sb files, which include filenames, alike:
\"name.c\",00h + garbage-padding to 4-byte boundary ;<-- maybe source code?\n \"pat_lamp\",00h + zero- padding to 4-byte boundary ;<-- name for File ID !\nMGS is using customized/corrupted PCX files as standard texture format (in STAGE.DIR\\\\.cp, STAGE.DIR\\\\.nd\\.p, and BRF.DAT\\). For details on PCX format (and MGS-specific customizations), see: CDROM File Video Texture/Bitmap (PCX) Apart from PCX, there's also custom texture format for animated bitmaps (in FACE.DAT), and a few TIM images (in STAGE.DIR\\init*\\.rd\\.r)
"},{"location":"cdromfileformats/#stagedirnd-texture-archive-with-pcx-files","title":"STAGE.DIR\\\\.nd - texture archive (with .PCX files)","text":""},{"location":"cdromfileformats/#stagedirinitrd-misc-archive-with-misc-files","title":"STAGE.DIR\\init*\\*.rd - misc archive (with misc files)","text":"These archives contain several chunks in following format:
000h 2 File ID (checksum on name?)\n 002h 1 File Type (one of following chars: \"p\" for .nd, or \"kors\" for .rd)\n 003h 1 Zero (00h)\n 004h 4 Chunk Size (rounded to 4-byte boundary)\n 008h .. Chunk Data\n .p PCX bitmap ;-in *\\*.nd archives\n .k Whatever ;\\\n .o Whatever \"OARa\" ; in init*\\*.rd archives\n .a Whatever ;\n .r Misc (TIM and other stuff) ;/\nThere can be one or more .sw files per stage folder (eg. two sw's in \"vr*\\*.sw\").
000h 4 Unknown (800h or C00h) ;big-endian\n 004h 4 Size of File List (N*10h) ;big-endian\n 008h 8 Zerofilled\n 010h N*10h File List (xx,xx,xx,00,00,00,00,7F,00,00,00,0F,00,19,0A,00)\n ... 4 Unknown (40000h or 60000h) ;big-endian\n ... 4 Size of SPU-ADPCM Data area ;big-endian\n ... 8 Zerofilled\n ... .. SPU-ADPCM Data area (indexed from File List)\n File List entries:\n 000h 4 Offset+Flags ;little-endian!\n bit0-16 Offset (from begin of SPU-ADPCM Data area)\n bit17 Unknown (0 or 1)\n bit18 Unknown (1)\n bit19-31 Unknown (0)\n 004h 12 Whatever (always 00,00,00,7F,00,00,00,0F,00,19,0A,00)\n 000h 80h*10h List (unused entries are 1x00000000h,3xFFFFFFFFh)\n 800h .. Data (whatever, usually 14h or more bytes per list entry)\n List entries:\n 000h 1 Unknown (eg. 01h,10h,20h,A0h,80h,FFh) ;\\\n 001h 1 Number of Voices? (1..3) ; all zero for\n 002h 1 Unknown (1 or 0) ; unused list entries\n 003h 1 Unknown (2 or 0 or 1) ;/\n 004h 4 Offset-800h for 1st Voice? ;-FFFFFFFFh=Unused\n 008h 4 Offset-800h for 2nd Voice? (if any) ;-FFFFFFFFh=Unused\n 00Ch 4 Offset-800h for 3rd Voice? (if any) ;-FFFFFFFFh=Unused\n Data:\n Seems to contain 4-byte entries (last entry being 00,00,FE,FF).\nThis does resemble a DOT1 Parent archive with 1-4 DOTLESS Child archives. Except, the offsets in Child archives are counted from begin of Parent archive.
Data:\n Seems to contain 4-byte entries (last entry being 00,00,FE,FF).\nFile IDs in STAGE.DIR (and maybe elsewhere, too) are computed as so:
sum=0,\n for i=0 to len(filename)-1\n sum=sum*20h+filename[i] ;\\or so, 16bit overflows might be\n sum=(sum+sum/10000h) AND FFFFh ;/cropped slightly differently\n 000h 4 Zero\n 004h 4 Number of Entries (503h)\n 008h 4 Zero\n 00Ch 4 Random\n 010h 10h Zero\n 020h N*10h File List\n ... .. Zeropadding to 800h-byte boundary\n ... .. Fild Data area\n 000h 4 Offset/800h\n 004h 4 Type (see below for info on different file types)\n 008h 4 Filesize in bytes\n 00Ch 4 Random (or 0 when Filesize=0)\n Type=00000001h Cubemap ;\\either one of these\n Type=00000040h Cubemap.empty ;/\n Type=00000020h Cubemap.overlay? ;\\these have size=0 when unused\n Type=00000400h Cubemap.sounds ;/\n Type=00000000h Archive with TIMs (Size=AB74h) (\" RSC3.1V\")\n Type=00000004h Unknown (Size=16164h) (00000064h)\n Type=00000008h Related to DRACULA1.STR (Size=1000h) (\" RTS1.1V\")\n Type=00001000h Unknown (Size=2000h) (\"BXFS1.1V\")\n Type=00008000h Unknown (Size=71Dh) (\" CM1.1V\")\n Type=00020000h Unknown (Size=3B9h) (\" GSM0.1V\")\n Type=02000000h Unknown (Size=0h) (empty)\n Type=00000100h Related to DRACULA1.XA (Size=1000h) (\"RAAX1.1V\")\n Type=00000010h Unknown (Size=450h) (\" HYP0.1V\")\n Type=00100000h Unknown (Size=4014h) (\" xFS1.1V\") (x=A1h)\n Type=00000080h Unknown (Size=258F4h) (00000010h)\n Type=00000200h TIM (gui charset) (Size=6E9Eh) (TIM)\n Type=00010000h TIM (gui buttons) (Size=10220h) (TIM)\n Type=00040000h Unknown (Size=2C4h) (\" TES0.1V\")\n Type=00002000h TIM (gui book pages) (Size=1040h) (TIM)\n Type=00000800h Cubemap ;\\as Type 01h, (Size=4092Ch) (\" RIV3.1V\")\n Type=00004000h Cubemap ;/but [10h,14h]=0 (Size=4092Ch) (\" RIV3.1V\", too)\n 000h 8 Name, ASCII, padded with leading spaces (eg. \" RIV3.1V\")\n 008h 4 Something (0, 1 or 2) (unknown, this isn't number of list entries)\n 00Ch 4 Zero\n 010h 4 Offset to Ext data (ACh) ;\\ext data\n 014h 4 Size of Ext data (eg. 0 or 84h) ;/\n 018h 6*4 Offsets to Side 0-5 ;\\cubemap sides\n 030h 6*4 Sizes of Side 0-5 (0, 10220h, or 10820h) ;/\n 048h 44h Zerofilled\n 08Ch 20h Name, ASCII (eg. \"DEBUT0.VR\", zeropadded)\n 0ACh .. Ext Data (if any)\n ... .. Cubemap TIM sides (if any)\n Note: The cubemap TIMs have 100h or 400h colors (in the latter case: 100h colors for each quarter of the 8bpp bitmap).\n Note: The TIMs can be arranged as 3D-cubemap with six sides, or as hires\n 2D-bitmap (composed of four TIMs, and 2 empty TIMs with size=0).\n Same as Type 01h, but size is always 0ACh (and all seven Size entries are 0)\n 000h 8 Name, ASCII, padded with leading spaces (eg. \" XFS0.1V\")\n 008h 4 Zero\n 00Ch 4 Number of Files (N) (max 10h)\n 010h N*10h File List (100h bytes, zeropadded when less than 10h files)\n 110h .. File Data (VAG files)\n File List entries:\n 000h 4 Unknown (55F0h, 255F0h or 20000h)\n 004h 4 File ID (01010000h, increasing, or other when above=2xxxxh)\n 008h 4 Offset in bytes ;\\.VAG files\n 00Ch 4 Filesize in bytes ;/\n 000h 8 Name, ASCII, padded with leading dot (eg. \".MNA4.1V\")\n 008h 4 Zero\n 00Ch 4 Random\n 010h 4 Unknown 01h\n 014h 4 Total Number of 40h-byte blocks (01h..[018h]) (H)\n 018h 4 Total Number of 120h-byte blocks (eg. 1Fh,31h) (N)\n 01Ch 4 Total Number of 1Ch-byte blocks (eg. 1Eh, 50h, F7h) (M)\n 020h 4 Unknown 0 or 1 (in file 4EAh)\n 024h 4 Unknown 01h\n 028h 6*4 Offsets to Side 0-5 (at end of file and up) (or 0) ;\\cubemap\n 040h 6*4 Sizes of Side 0-5 (10220h, or 10820h) (or 0) ;/sides\n 058h H*40h 40h-byte blocks\n ... N*120h 120h-byte blocks (related to offsets in 40h-byte blocks)\n ... M*1Ch 1Ch-byte blocks (related to offsets in 120h-byte blocks)\n ... .. Unknown data (related to offsets in 1Ch-byte blocks)\n ... .. Ext data (related to Ext offsets in 40h-byte blocks)\n FILE DOES END HERE!\n (below is allocated in above header, but not actually stored in the file)\n (maybe allocated as rendering buffer?)\n ... - Cubemap TIM sides\n The 40h-byte blocks are:\n 000h 20h Name (eg. \"FLAMMES\", zeropadded)\n 020h 4 Unknown 01h or 00h\n 024h 4 Offset to 120h-byte blocks (usually 98h, or higher)\n 028h 4 Unknown 00h\n 02Ch 4 Number of 120h-byte blocks (01h..[018h])\n 030h 4 Unknown 01h\n 034h 4 Ext Offset ;\\usually all zero\n 038h 4 Ext Size (3C000h) ; (except, nonzero in file 4EAh)\n 03Ch 4 Ext Random (checksum?) ;/\n The 120h-byte blocks are:\n 000h 18h*4 List with Offsets to 1Ch-byte blocks (usually 4 entries nonzero)\n 060h 18h*4 List with Zeroes\n 0C0h 18h*4 List with Numbers of 1Ch-byte blocks (usually max 4 entries)\n The 1Ch-byte blocks are:\n 000h 4 Unknown 04h\n 004h 4 Width 20h or 10h\n 008h 4 Height 20h or 10h or 30h\n 00Ch 4 Unknown 60h or 10h\n 010h 4 Unknown 00h or 30h\n 014h 4 Offset to Unknown Data\n 018h 4 Size of Unknown Data (Width*Height*1)\n 000h 8 Name (\" RSC3.1V\")\n 008h 8 Zerofilled\n 010h 4 Number of used entries (1Fh) (max 80h)\n 014h 80h*4 Offset List (offsets to files) (A14h and up)\n 214h 80h*4 Zero List (zerofilled)\n 414h 80h*4 Size List (filesizes)\n 614h 80h*4 Width List (0Ch,18h,34h,2Ch) (in pixels)\n 814h 80h*4 Height List (0Ch,24h,34h,2Ch)\n A14h .. Data (TIM files, with mouse pointers)\nCROCFILE.DIR and CROCFILE.1:
CROCFILE.DIR:\n 000h 4 Number of Entries (N)\n 004h N*18h File List\n ... 4 Checksum (sum of all of the above bytes)\n CROCFILE.1:\n 000h .. File Data (referenced from .DIR)\n File List entries:\n 000h 0Ch Filename (\"FILENAME.EXT\", zeropadded if shorter)\n 00Ch 4 File Size in bytes (can be odd) (including 8 byte for size/chksum)\n 010h 4 File Offset in .1 file (unaligned, can be odd, increasing)\n 014h 4 Zero (0)\n 000h 4 Size-8 of whole file (or Size-0 for those in MP*.WAD)\n 004h 4 Flags? (usually 0Ch or 14h)\n 008h 1 Filename length (including trailing 00h, if any)\n 009h .. Filename (\"P:\\CROC\\EDITOR\\MAPS\\..\\*.MAP\") (+00h in MAP05*.WAD)\n ... .. Unknown\n ... 1 Description length\n ... .. Description (eg. \"Default New Map\")\n ... .. Unknown\n ... (4) Checksum of whole file (sum of all bytes) (not in MP*.WAD)\n MAP*.WAD:\n 000h 4 Size-8 of whole file\n 004h .. MAP file(s) (each with size/checksum, same format as MP*.MAP)\n ... 4 Checksum of whole file (sum of all of the above bytes)\n CROC.WAD, CROCSLID.WAD, EXCLUDE.WAD, MP*.WAD, OPTIONS.WAD, SWIMCROC.WAD:\n 000h 4 Size-8 of whole file\n 004h 4 Offset-8 to SPU-ADPCM data area\n 008h .. Data File area (model.MOD anim.ANI, bytecode.BIN, header.CVG, etc.)\n ... .. SPU-ADPCM data area (if any, note in CROCSLID.WAD and OPTIONS.WAD)\n The Data File area contains several \"files\" but doesn't have any directory\n with filename/offset/size. The only way to find the separate files seems to\n be to detect the type/filesize of each file, and then advance to next file\n (bytecode.BIN files start with a size entry, but files like .MOD or .ANI\n require parsing their fileheader for computing filesize).\n Note: The PC version reportedly has .WAD files bundled with .IDX file (that\n makes it easier to find files and filenames).\n Note: The STRAT.DIR file contains a list of filenames used in .WAD files\n (but lacks info on offset/size, so it isn't really useful).\n Sound.BIN Files (CROCFILE.DIR\\AMBI*.BIN, MAP*.BIN, JRHYTHM.BIN, REVERB.BIN):\n 000h 4 Size of .SEQ file ;\\if any (not in REVERB.BIN)\n 004h .. SEQ file (starting with ID \"pQES\") ;/\n ... 4 Size of .VH file ;\\always present\n ... .. VH file (starting with ID \"pBAV\") ;/\n ... .. VB file (sample data, SPU-ADPCM data, up to end of file)\n Music.BIN files (MAGMUS.BIN, MUSIC.BIN):\n 000h 4 Size-8 of whole file (118h)\n 004h .. Increasing 32bit values ;sector numbers in PACK*.STR files or so?\n ... 4 Unknown (2EEh or 258h) (aka 750 or 600 decimal)\n ... .. Zeropadding\n 11Ch 4 Checksum (sum of all of the above bytes)\n Note: MUSIC.BIN has an extra copy (without chksum) in EXCLUDE.WAD\\MUSIC.BIN\n Ascii.BIN files (CREDITS*.BIN, MNAME.BIN):\n 000h 4 Size-8 of whole file\n 004h (2) Type or so? (02h,01h) (only in CREDITS*.BIN, not in MNAME.BIN)\n ... .. Ascii strings (each string is: len,\"text string\",unknown)\n ... 4 Checksum (sum of all of the above bytes)\n Texture.BIN files (type 4) (STILLGO.BIN, STILLST.BIN, STILLTL.BIN):\n 000h 2 Type (4=Texture/uncompressed, with 0Eh-byte list entries)\n 002h 1 Zero (maybe Extra6byte as in type 5,6 Texture.BIN files)\n 003h 2 Number of List entries (N) (always 4B0h in all three files)\n 005h 2 Number of Texture Pages (usually 2)\n 007h 2 Zero (maybe Unknown/Animation as in type 5,6 Texture.BIN files)\n 009h N*0Eh Polygon List (?,?,?,?,?,?, x1,y1, x2,y1, x1,y2, x2,y2)\n ... 40000h Texture Page uncompressed data (two pages, 20000h bytes each)\n ... 4 Checksum (sum of all of the above bytes)\n Texture.BIN files (type 5,6) (ENDTEXT*.BIN, FONT.BIN, FRONTEND.BIN,\n OUTRO.BIN, PUBLISH.BIN, STILL*.BIN, TB*.BIN, TK*.BIN, TPAGE213.BIN):\n 000h 4 Zero (0) (in TPAGE213.BIN: Size-8 of whole file)\n 004h 2 Type (6=Texture/RLE16) (in TPAGE213.BIN: 5=Texture/uncompressed)\n 006h 1 Extra6byte flag/size (0=None, 3=Extra6byte: TB*.BIN, TPAGE*.BIN)\n ... (6) Extra6byte data (unknown purpose, only present when [006h]=3)\n ... 2 Number of Polygon List entries (N)\n ... 2 Number of Texture Pages (usually 1) (in TK*_ENM.BIN: usually 2)\n ... 2 Number of Unknown Blocks (0=None, or 1,2,4,8)\n ... (..) Unknown Block(s), if any\n ... 2 Number of Animation Blocks (0=None)\n ... (..) Animation Block(s), if any\n ... N*0Ch Polygon List (?,?,?,?, x1,y1, x2,y1, x1,y2, x2,y2) ;x,y or y,x?\n ... (4) Texture Page compressed size (T1) ;\\only when [004h]=Type=6\n ... (T1) Texture Page compressed data ;/\n ... (4) Texture Page compressed size (T2) ;\\only when [004h]=Type=6\n ... (T2) Texture Page compressed data ;/ and NumPages=2\n ... 20000h Texture Page uncompressed data ;-only when [004h]=Type=5\n ... 4 Checksum (sum of all of the above bytes)\n Unknown Block(s):\n (Unknown purpose, each Unknown Block has the format shown below)\n 000h 2 Unknown (looks like some index value, different for each entry)\n 002h 2 Number of Unknown Items (eg. 1 or 2 or 4)\n 004h .. Unknown Items (NumItems*6 bytes) (three halfwords each?)\n Animation Block(s):\n (This is supposedly used to update portions of the Texture Page for\n animated textures, each Animation Block has the format shown below)\n 000h 2 Number of Bitmap Frames in this Animation (usually 8)\n 002h 2 Bitmap Width (in halfword units)\n 004h 2 Bitmap Height\n 006h 2 Unknown (1 or 3) ;\\\n 008h 2 Unknown (C10h, CC8h, 1E8h, or xxxh) ; maybe vram X,Y address?\n 00Ah 2 Unknown (0) ;/\n 00Ch .. Bitmap Frames (Width*2*Height*NumFrames bytes, uncompressed)\n Croc 1 RLE16 compression:\n This is using unsigned little-endian 16bit LEN/DATA pairs, LEN can be:\n 0000h..7FFFh --> Load one halfword, fill 1..8000h halfwords\n 8000h..FFFFh --> Copy 1..8000h uncompressed halfwords\n BUG: Texture pages should be 20000h bytes (256x256 halfwords), but for\n whatever reason, the size of decompressed data can be 1FFEAh, 1FFF0h,\n 1FFFAh, 20000h, or 20002h.\n Bytecode.BIN (inside of .WAD files):\n 000h 4 Size of whole file\n 004h .. Whatever bytecode (starting with initial 16bit program counter?)\n Unknown.BIN (last 1-2 file(s) in EXCLUDE.WAD file):\n 000h 4 Number of entries (N)\n 004h N*18h Whatever\n ... 4 Checksum (sum of above bytes)\n Unknown purpose, retail version has one such file (with 0Ah entries), demo\n version has two such files (with 0Ah and 4Eh entries. The files start with:\n 0A,00,00,00,00,00,00,00,00,00,64,00,00,00,EB,FF,... ;demo+retail\n 4E,00,00,00,00,00,64,00,00,00,50,00,00,00,64,00,... ;demo\n Demo version has one .MOD file in CROCFILE.DIR (retail has more such files):\n 000h 2 Number of Models (N) (1 or more) (up to ECh exists) ;\\header\n 002h 2 Flags (0 or 1) ;/\n 004h N*Var SubHeadersWithData ;see below ;-data\n ... 4 Checksum (sum of all of the above bytes) ;-checksum\n SubHeadersWithData(N*Var):\n 004h 4 Radius ;\\\n 008h 48h Bounding Box[9*8] (each 8byte are 4x16bit: X,Y,Z,0) ; for each\n 050h 4 Number of Vertices (V) ; model\n 054h V*8 Vectors (4x16bit: X,Y,Z,0) ;\n ... V*8 Normals (4x16bit: X,Y,Z,0) ;\n ... 4 Number of Faces (F) (aka Polygons?) ;\n ... F*14h Faces (8x16bit+4x8bit: X,Y,Z,0,V1,V2,V3,V4, Tex/RGB) ;\n ... 2 Number of collision info 1? (X) ;\\ ;\n ... 2 Number of collision info 2? (Y) ; only if ;\n ... X*2Ch Collision info 1? ; Flags.bit0=1 ;\n ... Y*2Ch Collision info 2? ;/ ;/\n There are further .MOD models inside of .WAD files, with slightly\n re-arranged entries (and additional reserved/garbage fields):\n 000h 2 Number of Models (N) (1 or more) (up to ECh exists) ;\\\n 002h 2 Flags (0 or 1) ; header\n 004h 4 Reserved/garbage (usually 224460h) (or 22C9F4h/22DF54h) ;/\n 008h (4) Number of Models WITH Data arrays (M) ;\\\n 00Ch (M*2) Model Numbers WITH Data arrays (increasing, 0..N-1) ; ext.hdr\n ... (..) Padding to 4-byte boundary (garbage, usually=M) ;/\n ... N*68h Subheader(s) ;see below ;-part 1\n ... N*Var DataArray(s) ;see below ;-part 2\n Subheaders(N*68h):\n 000h 4 Radius ;\\\n 004h 48h Bounding Box[9*8] (each 8byte are 4x16bit: X,Y,Z,0) ; for each\n 04Ch 4 Number of Vertices (V) ; model\n 050h 4 Reserved/garbage (usually 0022xxxxh) ;\n 054h 4 Reserved/garbage (usually 0022xxxxh) ;\n 058h 4 Number of Faces (F) (aka Polygons?) ;\n 05Ch 4 Reserved/garbage (usually 0022xxxxh) ;\n 060h 2 Number of collision info1? (X) ;\n 062h 2 Number of collision info2? (Y) ;\n 064h 4 Reserved/garbage (usually 0022xxxxh) or xxxxxxxxh) ;/\n DataArrays(N*Var) with sizes V,F,X,Y from corresponding Subheader:\n (if ext.hdr is present, then below exists only for models listed in ext.hdr)\n 000h V*8 Vectors (4x16bit: X,Y,Z,0) ;\\\n ... V*8 Normals (4x16bit: X,Y,Z,0) ; for each\n ... F*14h Faces (8x16bit+4x8bit: X,Y,Z,0,V1,V2,V3,V4, Tex/RGB) ; model\n ... X*2Ch Collision info 1? ;\n ... Y*2Ch Collision info 2? ;/\n The ext.hdr mentioned above exists only in some .MOD files (usually in one of\n the last chunks of MP*.WAD). Files with ext.hdr have N>1, Flags=1 (but files\n without ext.hdr can also have those settings). Files with ext.hdr do usually\n have uncommon garbage values at hdr[4], which isn't too helpful for detection.\n The only way to detect models with ext.hdr seems to be to check if the ext.hdr\n contains valid increasing entries in range 0..N-1.\n WAD's that do contain a model with ext.hdr do usually also contain an extra\n 100h-byte file, that file contains N bytes for model 0..N-1 (plus zeropadding\n to 100h-byte size), the bytes are supposedly redirecting models without Data\n Arrays to some other data source.\n The 100h-byte files don't have any header or checksum, they contain up to 9Ch\n entries (so there's always some zeropadding to 100h), the existing 100h-byte\n files contain following values in first 4 bytes (as 32bit value):\n 04141401h, 0C040017h, 01010101h, 09030503h, 0A0B0A0Bh, 03020102h, 0C060900h,\n 00060501h, 04040201h, 01010203h, 01030201h, 05000302h, 0C040317h, or Zero.\n To distinguish from other files: BIN/MAP files start with a 4-byte aligned\n Size value; if Size=0 or (Size AND 3)>0 or Size>RemainingSize then it's\n probably a 100h-byte file. Best also check if last some bytes are zeropadded.\n Exceptions:\n Retail MP090..MP100_*.WAD has model with ext.hdr, but no 100h-byte file\n Demo MP041_00.WAD has model with ext.hdr, with zerofilled 100h-byte file\n Note: Some models have ALL models listed in ext.hdr (which is about same as\n not having any ext.hdr at all; except, they ARE bundled with 100h-byte file).\n Some (not all) MP*.WAD files are bundled with MP*.DEM files, supposedly\n containing data for demonstration mode. There are two versions:\n demo version: size 2584h (9604 decimal) (some files with partial checksum)\n retail version: size 0E10h (3600 decimal) (without checksum)\n Animation data, there is only one such file in CROCFILE.DIR:\n 000h 2 Value (100h)\n 002h 2 Number of Triggers (T) (2)\n 004h (T*2) Trigger List (with 2x8bit entries: FrameNo, TriggerID)\n ... .. Probably, Padding to 4-byte boundary (when T=odd)\n ... 4 Number of entries 1 (X)\n ... X*18h Whatever Array 1\n ... 4 Number of entries 2 (Y) (usually/always 64h)\n ... X*Y*4 Whatever Array 2\n ... 4 Number of entries 3 (Z) (usually/always 0Ah)\n ... X*Z*18h Whatever Array 3\n There are further .ANI files inside of .WAD files:\n 000h 2 Value (100h or 200h) ;Animation Speed?\n 002h 2 Number of Triggers (T) (0, 1, 2, 3, 5, or 9)\n 004h 4 Garbage/Pointer (usually 224460h) (or zero)\n 008h 4 Number of entries 1 (X) (1 or more) ;Num Frames\n 00Ch 4 Garbage/Pointer (usually 22C9F4h) (or 224460h or 22DF54h)\n 010h 4 Number of entries 2 (Y) (usually 64h) (or 0) ;Num Vertices (?)\n 014h 4 Garbage/Pointer\n 018h 4 Number of entries 3 (Z) (usually 0Ah) (or 6 or 9)\n 01Ch 4 Garbage/Pointer\n 020h (T*2) Trigger List (with 2x8bit entries: FrameNo, TriggerID)\n ... .. Padding to 4-byte boundary (garbage, usually=X)\n ... X*18h Whatever Array 1\n ... X*4 Garbage/Pointers (0021EE74h,0021EE74h,xxx,...)\n ... X*Y*4 Whatever Array 2 ;Vertex 3x10bit? ;only if Y>0\n ... (X*4) Garbage/Pointers (0021EE74h,0021EE74h,xxx,...) ;only if Y>0\n ... X*Z*18h Whatever Array 3\n There is only one such file in CROCFILE.DIR:\n 000h 4 Size-8 of whole file\n 004h 4 Unknown (0)\n 008h 4 Unknown (1)\n 00Ch .. SPU-ADPCM data\n ... 4 Checksum (sum of all of the above bytes)\n There are further .CVG files inside of .WAD files, these consist of two\n parts; 0Ch-byte Headers (in the data file area), and raw SPU-ADPCM data\n (in the spu-adpcm data area at end of the .WAD file):\n Header(0Ch):\n 000h 4 Size+8 of data part\n 004h 4 Unknown (0)\n 008h 4 Unknown (0 or 1)\n Data(xxxx0h):\n 000h .. SPU-ADPCM data (starting with sixteen 00h bytes)\n This file contains a list of filenames for files inside of .WAD files, but\n it does NOT tell where those files are (in which WAD at which offset).\n 000h 4 Number of Entries (N)\n 004h N*xxh File List (retail=14h bytes, or demo=18h bytes per entry)\n ... 4 Checksum (sum of all of the above bytes)\n List entries are:\n demo: entrysize=18h ;Filename(0Ch)+Size(4)+Zeroes(8)\n retail: entrysize=14h ;Filename(0Ch)+ Zeroes(8)\n The list contains hundreds of filenames, with following extensions:\n *.BIN byte-code strategies\n *.MOD models\n *.ANI animations\n *.CVG spu-adpcm voice data\n These \"filenames\" seem to be actually solely used as \"memory handle names\":\n MemoryHandle(#1) = LoadFile(\"FILENAME.BIN\") ;<-- names NOT used like this\n MemoryHandle(\"FILENAME.BIN\") = LoadFile(#1) ;<-- names used like this\n Huge files with XA-ADPCM audio data\n Huge mis-mastered 24Mbyte file (contains several smaller XA-ADPCM blocks,\n accidentally stored in 800h-byte FORM1 data sectors, instead of 914h-byte\n FORM2 audio sectors).\n MDEC movies\n Raw bitmaps (25800h bytes, uncompressed, 320x240x16bpp)\nOverall .WAD format:
000h 4 Total Filesize+/-xx (-4 or +800h or +1800h)\n 004h 4+4+.. XSPT Chunk ;Textures\n ... 4+4+.. XSPS Chunk ;SPU-ADPCM Sound (if any, not in all .WAD's)\n ... 4+4+.. XSPD Chunk ;...whatever Data...?\n ... 4+4 DNE Chunk ;End marker (in Harry Potter: with data!)\n 000h 4 Chunk Name \"XSPT\" (aka TPSX backwards)\n 004h 4 Chunk Size (excluding 8-byte Name+Size)\n 008h 4 Chunk Flags (02h or 06h or 0Eh) ;02h in Croc 2\n 00Ch (20h) Name (eg. \"Default new map\", zeropadded) ;\\if Flags bit2=1\n ... (804h) Unknown ... SAME as in XSPD chunk !!! ;/\n ... 4 Number of List 1 entries (N1) (xxh..xxxh) ;\\\n ... 4 Number of Texture Pages (1..4) ; List 1 and NumPages\n ... N1*0Ch List 1 Whatever (6B 2F xx 00..) ;/\n ... 4 Number of List 2 entries (N2) (0..xxh) ;\\\n ... 4 Unknown (2 or 7) ; List 2\n ... N2*04h List 2 Whatever (halfwords?) (if N2>0) ;/\n ... (5*C00h) Whatever, 5*C00h, Palette+Stuff? ;-if Flags bit3=1\n ... .. RLE16 compressed Texture Pages ;-Texture bitmap\n RLE16 Texture notes:\n Compressed data consists of signed little-endian 16bit LEN+DATA pairs:\n LEN=0000h --> invalid/unused\n LEN=0001h..7FFFh --> copy LEN halfwords from src\n LEN=8000h..FFFFh --> load ONE halfword as fillvalue, fill -LEN halfwords\n Compressed size is everything up to end of XSPT chunk\n Decompressed size is 20000h*NumTexturePages (=20000h,40000h,60000h or 80000h)\n That is: Width=256 halfwords, height 256*NumTexturePages lines. There seems\n to be only one RLE16 compression block for all Texture Pages, rather than one\n RLE16 block for each Page.\n BUG #1: Decompressed data in Aladding/Emperor does often contain only\n 1FFFEh,3FFFEh,5FFFEh,7FFFEh bytes (the decompressed data has correct size\n when appending ONE halfword with random/zero value).\n BUG #2: Compressed data in Croc 2 ends with a RLE16 length value (-LEN), but\n lacks the corresponding RLE16 filldata (the decompressed data is 7FFFEh when\n filling those LEN halfwords with random/zero values).\n 000h 4 Chunk Name \"XSPS\" (aka SPSX backwards) ;\\\n 004h 4 Chunk Size (excluding 8-byte Name+Size) ; header\n 008h 4 Chunk Flags (0 or 3 or 7) ;/\n 00Ch 4 Number of Sounds (N1) (1..xxh) ;\\always present\n 010h N1*14h Sound List ;/\n ... (4) VAB/VH Size ;\\if Flags=3 or 7\n ... (..) VAB/VH Header ;/ (bit0 or bit1?)\n ... (4) Unknown (2 or 4) ;-if Flags=3 or 7\n ... (4) Whut (N2) ;\\if Flags.bit2=1\n ... (N2*10h) Whut List (4 words: xxh,10h,xxxx00h,xxxx0h);/\n ... 4 Size of all Part 1 Sound Data blocks ;\\always\n ... .. SPU-ADPCM Sound Data (referenced from Sound List) ;/\n ... (4) Size of all Part 2 Sound Data blocks (+8) ;\\if Flags=\n ... (..) SPU-ADPCM Sound Data (referenced from Sound List?) ; 3 or 7\n ... (8) Zero ;/\n Sound List entries (as in FESOUND.WAD):\n 000h 4 Sample Rate in Hertz (AC44h=44100Hz, 5622h=22050Hz, 3E80h=16000Hz)\n 004h 2 Sample Rate Pitch (1000h=44100Hz, 0800h=22050Hz, 05CEh=16000Hz)\n 006h 2 Unknown (7Fh)\n 008h 4 Unknown (1) (1) (8)\n 00Ch 4 Unknown (42008Fh) (1FC0001Fh) (40008Fh)\n 010h 4 Filesize (xxx0h) (xxx0h)\n 000h 4 Chunk Name \"XSPD\" (aka DPSX backwards)\n 004h 4 Chunk Size (excluding 8-byte Name+Size)\n 008h 4 Flags-and/or-other stuff ? (eg. 00000094h or 0A801094h)\n 00Ch 804h Unknown ... SAME as in XSPT chunk !!!\n 810h .. Unknown ...\n 000h 4 Chunk Name \" DNE\" (aka END backwards)\n 004h 4 Chunk Size (0) (except, in Harry Potter: nonzero)\n ... .. Data (usually none such) (except, in Harry Potter: with data!)\n 000h 4 Number of entries (N) (always 2EEh, aka 750 decimal)\n 004h N*8 Whatever entries... maybe data for demonstration mode?\nSome games use files that contain several files badged together. For example,
PSX Resident Evil 2, COMMON\\DATA\\*.DIE contains TIM+VAB badged together\n PSX Resident Evil 2, COMMON\\DATA\\*.ITP contains 1000h-byte aligned TIMs\n Blaster Master, DATA\\MENU\\*\\*.PRT contains three smaller TIMs badged together\n Blaster Master, DATA\\MENU\\*\\*.BG contains three bigger TIMs badged together\n Misadventures of Tron Bonne, KATWA\\*.BIN contains headerless archives (with TIMs and audio)\n Headerless BSS files contain several BS files with huge padding inbetween\n .BS used by several games (and also in most .STR videos)\n .GIF used by Lightspan Online Connection CD\n .JPG used by Lightspan Online Connection CD\n .BMP with RLE4 used by Lightspan Online Connection CD (MONOFONT, PROPFONT)\n .BMP with RLE8+Delta also used by Online Connection CD (PROPFONT\\ARIA6.BMP)\n .PCX with RLE used by Jampack Vol. 1 (MDK\\CD.HED\\*.pcx)\n .PCX with RLE used by Hot Wheels Extreme Racing (MagDemo52: US_01293\\MISC\\*)\n .PCX with RLE used by Metal Gear Solid (slightly corrupted PCX files)\n .XA uses XA-ADPCM (and also used in .STR videos)\n .VAG .VB .VAB uses SPU-ADPCM\nCDROM File Compression LZSS (Moto Racer 1 and 2) CDROM File Compression LZSS (Dino Crisis 1 and 2) CDROM File Compression LZSS (Serial Experiments Lain) CDROM File Compression ZOO/LZSS CDROM File Compression Ulz/ULZ (Namco) CDROM File Compression SLZ/01Z (chunk-based compressed archive) CDROM File Compression LZ5 and LZ5-variants CDROM File Compression PCK (Destruction Derby Raw) CDROM File Compression GT-ZIP (Gran Turismo 1 and 2) CDROM File Compression GT20 and PreGT20 CDROM File Compression HornedLZ CDROM File Compression LZS (Gundam Battle Assault 2) CDROM File Compression BZZ CDROM File Compression RESOURCE (Star Wars Rebel Assault 2) CDROM File Compression TIM-RLE4/RLE8 CDROM File Compression RLE_16 CDROM File Compression PIM/PRS (Legend of Mana) CDROM File Compression BPE (Byte Pair Encoding) CDROM File Compression RNC (Rob Northen Compression) CDROM File Compression Darkworks CDROM File Compression Blues CDROM File Compression Z (Running Wild) CDROM File Compression ZAL (Z-Axis) CDROM File Compression EA Methods CDROM File Compression ZIP/GZIP/ZLIB (Inflate/Deflate) CDROM File Compression LArc/LHarc/LHA (LZS/LZH) CDROM File Compression UPX CDROM File Compression LZMA CDROM File Compression FLAC audio Some other archvies that aren't used by any PSX games, but, anyways... CDROM File Compression ARJ CDROM File Compression ARC CDROM File Compression RAR CDROM File Compression ZOO CDROM File Compression nCompress.Z CDROM File Compression Octal Oddities (TAR, CPIO, RPM) CDROM File Compression MacBinary, BinHex, PackIt, StuffIt, Compact Pro
"},{"location":"cdromfileformats/#compressed-archives","title":"Compressed Archives","text":"Some Archives have \"built-in\" compression. CDROM File Archive WAD (Doom) CDROM File Archive BIGFILE.DAT (Gex - Enter the Gecko)
"},{"location":"cdromfileformats/#cdrom-file-compression-lzss-moto-racer-1-and-2","title":"CDROM File Compression LZSS (Moto Racer 1 and 2)","text":""},{"location":"cdromfileformats/#moto-racer-1-lzss-with-len2-magdemo03-mrdemoimgtim","title":"Moto Racer 1 (\"LZSS\" with len+2) (MagDemo03: MRDEMO\\IMG\\*.TIM)","text":""},{"location":"cdromfileformats/#moto-racer-2-lzss-with-len3-magdemo16-mr2demoimgtim-and-tpk","title":"Moto Racer 2 (\"LZSS\" with len+3) (MagDemo16: MR2DEMO\\IMG\\*.TIM and .TPK)","text":" 000h 4 ID \"LZSS\"\n 004h 4 Decompressed Size\n 008h .. Compressed Data\n @@collect_more:\n flagbits=[src]+100h, src=src+1 ;8bit flags\n @@decompress_lop:\n flagbits=flagbits SHR 1\n if zero then goto @@collect_more\n if carry=1 then\n [dst]=[src], dst=dst+1, src=src+1\n else\n disp=([src]+[src+1]*100h) AND 3FFh, len=([src+1]/4)+2_or_3, src=src+2\n if disp=0 then goto @@decompress_done\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n endif\n goto @@decompress_lop\n @@decompress_done:\n ret\nDino Crisis LZSS Decompression for files with type 7 and 8:
@@collect_more:\n flagbits=[src]+100h, src=src+1 ;8bit flags\n @@decompress_lop:\n flagbits=flagbits SHR 1\n if zero then goto @@collect_more\n if carry=1 then\n [dst]=[src], dst=dst+1, src=src+1\n else\n disp=[src]+[src+1]*100h AND FFFh, len=[src+1]/10h+2, src=src+2\n if disp=0 then error\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n endif\n if src<src_end then goto @@decompress_lop\n ret\nSerial Experiments Lain is using LZSS compression for TIMs (in SITEA.BIN, SITEN.BIN), and for Transparency Masks (in LAPKS.BIN).
"},{"location":"cdromfileformats/#serial-experiments-lain-7mb-siteabin-on-disc-1-5mb-sitebbin-on-disc-2","title":"Serial Experiments Lain (7MB SITEA.BIN on Disc 1, 5MB SITEB.BIN on Disc 2)","text":"These are huge 5-7 Mbyte files with hundreds of chunks. Each chunk contains one compressed TIM.
Each chunk is having this format:\n 000h 4 Chunk ID \"napk\"\n 004h 4 Decompressed size\n 008h .. LZSS compressed TIM data\n ... .. Zeropadding to 800h-byte boundary\nThis a huge 14Mbyte file with 59 chunks. Each chunk contains one or more 24bpp .BS images with black background (the images in each chunk are forming a short animation sequence; width/height may vary because all images are cropped to rectangles containing non-black pixels).
Each chunk is having this format:\n 000h 4 Chunk ID \"lapk\"\n 004h 4 Chunk size (excluding 8-byte chunk header, excluding zeropadding)\n 008h 4 Number of Files in this Chunk (N)\n 00Ch N*0Ch File List\n ... .. File Data (bitmaps in .BS v0 format with uncommon headers)\n ... .. Zeropadding to 800h-byte boundary\n File List entries:\n 000h 4 Offset in bytes (zerobased, from begin of File Data area)\n 004h 2 Bitmap Width/2 + some 3bit value in LSBs?\n 006h 2 Bitmap Height\n 00Ch 4 Zero\n File Data (bitmaps in .BS v0 format with uncommon headers):\n 000h 2 Bitmap Width\n 002h 2 Bitmap Height\n 004h 2 Quant for Y1,Y2,Y3,Y4\n 006h 2 Quant for Cr,Cb\n 008h 4 Size of compressed BS Bitstream plus 4 ;Transparency at [008h]+0Ch\n 00Ch 2 Size/2 of MDEC data (after huffman decompression, without padding)\n 00Eh 2 BS Version (0) (actually MSBs of above Size, but it's always 0)\n 010h .. BS Bitstream with DC and AC values (Huffman compressed MDEC data)\n ... 4 Transparency Mask Decompressed Size (Width*Height*2/8) (=2bpp)\n ... .. Transparency Mask LZSS-compressed data\nThis LZSS variant is unusually using 8bit len and 8bit disp.
dst_end=dst+[src], src=src+4 ;decompressed size\n @@collect_more:\n flagbits=([src] SHL 24)+800000h, src=src+1 ;8bit flags\n @@decompress_lop:\n if dst=dst_end then goto @@decompress_done\n flagbits=flagbits SHL 1 ;32bit shift with carry-out/zeroflag\n if zero then goto @@collect_more\n if carry=0 then\n [dst]=[src], dst=dst+1, src=src+1\n else\n disp=[src]+1, len=[src+1]+3, src=src+2\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n endif\n goto @@decompress_lop\n @@decompress_done:\n ret\n 0000h 4 Decompressed Size ;\\1st sector\n 0004h 7FCh Garbage ;/\n 0800h 4 Decompressed Size (same as above) ;\\2nd sector\n 0804h 7FCh LZSS compressed data, part 1 ;/\n 1000h 800h LZSS compressed data, part 2 ;-3rd sector\n 1800h 800h LZSS compressed data, part 3 ;-4th sector\n ... .. etc.\n decompress_file:\n if LittleEndian32bit[src+14h]=FDC4A7DCh then goto error ;refuse ZOO archives\n if LittleEndian32bit[src]<>LittleEndian32bit[src+800h] then goto error\n curr=src+800h\n src=curr+4\n @@sector_lop:\n call decompress_sector\n curr=curr+800h\n src=curr\n if src<src_end then goto @@sector_lop\n ret\n ;---\n decompress_sector:\n @@collect_more:\n flagbits=([src] SHL 24)+800000h, src=src+1 ;8bit flags\n @@decompress_lop:\n flagbits=flagbits SHL 1 ;32bit shift with carry-out/zeroflag\n if zero then goto @@collect_more\n if carry=0 then\n [dst]=[src], dst=dst+1, src=src+1\n else\n disp=[src]*100h+[src+1], src=src+2\n if disp=FFFFh then goto @@decompress_done\n len=(disp/800h)+3, disp=(disp AND 7FFh)+1\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n endif\n goto @@decompress_lop\n @@decompress_done:\n ret\nUlz/ULZ uses fairly normal LZSS compression, unusually with variable Len/Disp ratio, three separate data streams (flg/lz/dta), and rather weird end check in version=0.
"},{"location":"cdromfileformats/#ulz-format-ace-combat-3-electrosphere-namco","title":"Ulz Format (Ace Combat 3 Electrosphere, Namco)","text":""},{"location":"cdromfileformats/#ulz-format-klonoa-magdemo08-klonoafileidx","title":"Ulz Format (Klonoa, MagDemo08: KLONOA\\FILE.IDX\\*)","text":" 000h 4 ID (\"Ulz\",1Ah) (parts lowercase)\n 004h 3 Decompressed Size in bytes\n 007h 1 Version (0 or 2)\n 008h 3 Offset to Uncompressed data <-- reportedly can be 0 in version=0?\n 00Bh 1 Number of Disp bits (DispBits=N, LenBits=16-N) (usually 0Ah..0Dh)\n 00Ch 4 Offset to Compressed data\n 010h .. Compression Flags (32bit entries)\n ... .. Uncompressed data (8bit entries)\n ... .. Zeropadding to 4-byte boundary\n ... .. Compressed data (16bit entries)\n 000h 4 ID (\"ULZ\",1Ah) (all uppercase)\n 004h 2 Zero\n 006h 1 Version (0 or 2)\n 007h 1 Number of Disp bits (DispBits=N, LenBits=16-N) (usually 0Ah..0Dh)\n 008h 4 Offset to Uncompressed data\n 00Ch 4 Offset to Compressed data\n 010h 4 Decompressed Size in bytes\n 014h .. Compression Flags (32bit entries)\n ... .. Uncompressed data (8bit entries)\n ... .. Zeropadding to 4-byte boundary\n ... .. Compressed data (16bit entries)\n if [src+00h]=\"Ulz\",1Ah then\n version = Byte[src+07h]\n disp_bits = Byte[src+0Bh]\n dst_end = LittleEndian24bit[src+04h] + dst\n src_dta = LittleEndian24bit[src+08h] + src\n src_lz = LittleEndian32bit[src+0Ch] + src\n src_flg = src + 10h\n add_len = 3\n flg_1st = 31 ;process flag bit31 first\n if [src+00h]=\"ULZ\",1Ah then\n version = Byte[src+06h]\n disp_bits = Byte[src+07h]\n src_dta = LittleEndian32bit[src+08h] + src\n src_lz = LittleEndian32bit[src+0Ch] + src\n dst_end = LittleEndian32bit[src+10h] + dst\n src_flg = src + 14h\n add_len = 2\n flg_1st = 0 ;process flag bit0 first\n collected = 80000000h ;initially empty, plus stop bit\n @@decompress_lop:\n if version=2 AND dst=dst_end then goto @@decompress_done\n flag = collected AND 80000000h\n collected=collected*2\n if collected=0\n collected = LittleEndian32bit[src_flg], src_flg=src_flg+4\n if flg_1st=0 then ReverseBitOrder(collected) ;or make custom/faster code\n flag = collected AND 80000000h\n if version=0 AND collected=0 then goto @@decompress_done\n if version=0 then collected=collected*2 ;<-- has implied stop bit\n if version=2 then collected=collected*2 + 1 ;<-- shift-in stop bit\n if flag=0 ;compressed\n disp = LittleEndian16bit[src_lz], src_lz=src_lz+2\n len = (disp SHR disp_bits) + add_len\n disp = (disp AND ((1 shl disp_bits)-1)) + 1\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n else ;uncompressed\n [dst]=[src_dta], dst=dst+1, src_dta=src_dta+1\n goto @@decompress_lop\n @@decompress_done:\n ret\nSLZ/01Z files are Chunk-based archives with one or more compressed chunk(s). Used by Hot Shots Golf 2 (retail: DATA\\F0000.BIN\\, MagDemo31/42: HSG2\\MINGOL2.BIN\\)
"},{"location":"cdromfileformats/#slz01z-chunk-headers","title":"SLZ/01Z chunk headers","text":"The archive consists of Chunk(s) in following format:
000h 3 ID (either \"01Z\" or \"SLZ\", both are used)\n 003h 1 Method (00h=Uncompressed, 01h=LZSS, 02h=LZSS+FILL)\n 004h 4 Compressed size (SIZ) (same as decompressed when Method=0)\n 008h 4 Decompressed size\n 00Ch 4 Distance to next chunk, if any (SIZ+10h+Align4, or 0=None)\n 010h SIZ Compressed data\n method=byre[src+3]\n len=word[src+8]\n src=src+10h\n if method=0 then\n for i=1 to len, [dst]=[src], dst=dst+1, src=src+1, next i\n goto @@decompress_done\n dst_end = dst+len\n @@collect_more:\n flagbits=[src]+100h, src=src+1 ;8bit flags\n @@decompress_lop:\n if method=2 AND dst=dst_end then goto @@decompress_done\n flagbits=flagbits SHR 1\n if zero then goto @@collect_more\n if carry=1 then\n [dst]=[src], dst=dst+1, src=src+1\n else\n disp=([src]+[src+1]*100h) AND 0FFFh, len=([src+1]/10h)+3, src=src+2\n if method=1 AND disp=0 then goto @@decompress_done\n if method=2 AND len=12h then ;special fill mode...\n len=disp/100h+3, val=disp AND FFh ;len=3..12h\n if len=3 then len=val+13h, val=[src], src=src+1 ;len=13h..112h\n for i=1 to len, [dst]=val, dst=dst+1, next i ;len=4..112h\n else\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n endif\n goto @@decompress_lop\n @@decompress_done:\n ret\nLZ5 was used by LArc compression tool from 1988/1989, decompression is also supported by LHarc/LHA. LZ5 is basically LZSS compression, but with some oddities:
LZ5 is often implemented with a ringbuf (instead of actual sliding window)\n LZ5 uses absolute ringbuf indices (instead of relative sliding dest indices)\n LZ5 requires the ringbuf to be initially prefilled with constants\n LZ5 ringbuf is 1000h bytes tall and starts with write index FEEh\n INFO.DAT\n encrypted directory with filename, offset and compressed/uncompressed size\n GAME.DAT\n 000h 4 ID \"ALZ1\"\n 004h ... ALZ1 Compressed data (with size as defined in INFO.DAT)\n ... 4 ID \"ALZ1\"\n ... ... ALZ1 Compressed data (with size as defined in INFO.DAT)\n ...\nALZ1 compression is used in various folders (ENEMY*, STAGE*, STARTUP, MAGIC, FIELD, MINI, MOVIE, WORLD) with various filename extensions (.LZS .BSX .DAT .MIM .TIZ .PRE .BSZ .TXZ).
000h 4 Compressed Size ;=Filesize-4\n 004h .. ALZ1 Compressed data (Filesize-4 bytes)\nAbout same as FF7, but detection is less reliable because there are no filenames or extensions, and the file header is somewhat randomly set to [000h]=(Filesize-4)+0..7, unknown why, maybe it's allocating dummy bytes to last some compression flags.
000h 4 Compressed Size+0..7 ;=(Filesize-4)+0..7\n 004h .. ALZ1 Compressed data (Filesize-4 bytes)\n 000h 8 ID \"00zLATAD\" (aka DATALz00 backwards) ;\\PreHeader\n 008h 4 Total Filesize excluding PreHeader+Padding (SIZ+0Ch) ;/\n 00Ch 4 Unknown (always 1000h) ;\\\n 010h 4 Compressed data size (SIZ) ; Header\n 014h 4 Decompressed data size ;/\n 018h SIZ zLATAD Compressed data ;-Data\n ... .. Padding to 4-byte boundary ;-Padding\n 000h 8 ID \"VRAM-WAD\"\n 008h 4 Compressed size (Filesize-Padding-10h)\n 00Ch 4 Decompressed size (18000h, 28000h, 40000h bytes)\n 010h .. VRAMWAD Compressed data (192x256, 320x256, 512x256 halfwords)\n ... (..) Padding to 4-byte boundary (if any, in files in .VRW archives)\nBIZ compression is used in BIZ archives (which are nested in IDX/HUG archive). The compressed & decompressed size is stored in the BIZ archive. Note: Power Spike 20h-filled initial BIZ ringbuf is required for sky pixels in:
MagDemo43: POWER\\GAME.IDX\\PERSOS\\PSX\\CUSTOM\\\\TEXTURE\\NFIELD.BIZ\\LPORJ.PSI\nSCRATCH compression is used in PAK archives (which are nested in PCK archive). The compressed & decompressed size is stored in the PAK archive. Note: The decompressor uses half of the 1Kbyte Scratchpad RAM at 1F800000h as ringbuf (hence the name and unusual small 200h-byte ringbuf size).
"},{"location":"cdromfileformats/#alice-in-cyberland-alicepacfa2","title":"Alice in Cyberland (ALICE.PAC\\*.FA2)","text":" 000h .. FA2 Compressed .FA archive\n DEFAULT = ALZ1 or BIZ or LZ5\n if DEFAULT then wr=0FEEh, mask=FFFh ;\\\n if VRAMWAD then wr=0FEEh, mask=FFFh ; initial ringbuf write index\n if zLATAD then wr=0000h, mask=FFFh ; and ringbuf mask (size-1)\n if SCRATCH then wr=01BEh, mask=1FFh ;\n if FA2 then wr=00EFh, mask=0FFh ;/\n if FA2 then len2=0\n initialize_ringbuf_content (see below)\n numbits=0\n @@decompress_lop:\n if dst>=dst.end then goto @@decompress_done\n if numbits=0\n flagbits=[src], numbits=8, src=src+1 ;8bit flags\n numbits=numbits-1\n if VRAMWAD or FA2 then flagbits SHL 1, else flagbits=flagbits SHR 1\n if carry=1 then\n dta=[src], [dst]=dta, ringbuf[wr AND mask]=dta\n dst=dst+1, wr=wr+1, src=src+1\n else\n if DEFAULT then rd=[src]+([src+1]/10h)*100h), len=([src+1] AND 0Fh)+3\n if zLATAD then rd=[src]+([src+1] AND 0Fh)*100h), len=([src+1]/10h)+3\n if SCRATCH then rd=[src]+([src+1]/80h)*100h), len=([src+1] AND 7Fh)+3\n if VRAMWAD then rd=[src+1]+([src]/10h)*100h), len=([src] AND 0Fh)+3\n if FA2 then rd=[src], len=len2, len2=0, src=src+1\n if FA2 and len=0 then len=[src]/10h+2, len2=([src] AND 0Fh)+2, src=src+1\n if FA2=0 then src=src+2\n for i=1 to len ;read ringbuf[rd] (instead of relative [dst-rd])\n dta=ringbuf[rd AND mask], [dst]=dta, ringbuf[wr AND mask]=dta\n dst=dst+1, wr=wr+1, rd=rd+1\n next i\n endif\n goto @@decompress_lop\n @@decompress_done:\n ret\n if ALZ1 or zLATAD then\n ringbuf[000h..FFFh]=(00h) ;zeroes\n if VRAMWAD then\n ringbuf[000h..FEDh]=(00h) ;zeroes\n ringbuf[FEEh..FFFh]=(uninitialized) ;uninitialized, don't use\n if BIZ then\n ringbuf[000h..FEDh]=(20h) ;ascii space\n ringbuf[FEEh..FFFh]=(uninitialized) ;uninitialized, don't use\n if SCRATCH then\n ringbuf[000h..1BFh]=(00h) ;zeroes\n ringbuf[1C0h..1FFh]=(uninitialized) ;uninitialized, don't use\n if FA2 then\n ringbuf[000h..0FFh]=(00h) ;zeroes\n if LZ5 then\n ringbuf[000h..CFFh]=(000h..CFFh)/0Dh ;increasing, repeated 0Dh times each\n ringbuf[D00h..DFFh]=(00h..FFh) ;increasing\n ringbuf[E00h..EFFh]=(FFh..00h) ;decreasing\n ringbuf[F00h..F7Fh]=(00h) ;zeroes\n ringbuf[F80h..FEDh]=(20h) ;ascii space\n ringbuf[FEEh..FFFh]=(should be 00h) ;see note, better don't use\n 000h 3 Decompressed size (24bit, little-endian)\n 003h 1 Unused (0)\n 004h ... LZSS compressed data, starting with 30bit+2bit flags\n [03h]=00h, [04h]=00h, [08h]=\"PS-X EXE\" ;DDRAW\\*.EXE\n [03h]=00h, [04h] AND FCh=00h, [08h]=\"BC\",04h,40h,0,0 ;DDRAW\\LDPICS\\*.PCK\nThe PSX BIOS seems to use the same LZSS format for the self-decompressing GUI code (with GUI/decompression starting at 80030000h).
"},{"location":"cdromfileformats/#decompression-function_2","title":"Decompression function","text":" dst_end=dst+LittleEndian24bit[src], src=src+4\n @@collect_more:\n flagbits=BigEndian32bit([src]), src=src+4\n dispbits=14-(flagbits AND 03h), flagbits=(flagbits OR 3)-1\n dispmask=(1 SHL dispbits)-1\n @@decompress_lop:\n flagbits=flagbits SHL 1 ;32bit shift with carry-out/zeroflag\n if zero then goto @@collect_more\n if carry=0 then\n [dst]=[src], dst=dst+1, src=src+1\n else\n disp=BigEndian16bit[src], src=src+2\n len=(disp SHR dispbits)+3\n disp=(disp AND dispmask)+1\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n endif\n id dst<dst_end then goto @@decompress_lop\n @@decompress_done:\n ret\nIKI is a rather uncommon variant of the .STR video format (used by Gran Turismo 1 and 2, Legend of Legaia, Legend of Dragoon, Omega Boost, Um Jammer Lammy). IKI videos have a custom .BS header, including some GT-ZIP compressed data:
000h 2 MDEC Size/4 (after huffman decompression) (rounded to 80h/4 bytes)\n 002h 2 File ID (3800h)\n 004h 2 Bitmap Width in pixels ;instead quant\n 006h 2 Bitmap Height in pixels ;instead version\n 008h 2 Size of GT-ZIP compressed data (plus 2-byte alignment padding)\n 00Ah .. GT-ZIP compressed DC/Quant values (plus 2-byte alignment padding)\n ... .. Huffman compressed AC data blocks (Cr,Cb,Y1,Y2,Y3,Y4, Cr,Cb,Y1,Y2..)\n 000h .. Compressed Data (without header)\n 000h 0Ch ID \"@(#)GT-ZIP\",0,0\n 00Ch 4 Decompressed Size\n 010h .. Compressed Data (unknown compressed size due to below padding)\n ... .. Zeropadding to 4-byte boundary (when stored in DOT1 archives)\n if [src]=\"@(#)GT-ZIP\",0,0 then dst.end=dst+[src+0Ch], src=src+10h\n @@collect_more:\n flagbits=[src]+100h, src=src+1 ;8bit flags\n @@decompress_lop:\n if src>=src.end then goto @@decompress_done ;(when src.end is known)\n if dst>=dst.end then goto @@decompress_done ;(when dst.end is known)\n flagbits=flagbits SHR 1\n if zero then goto @@collect_more\n if carry=0 then\n [dst]=[src], dst=dst+1, src=src+1\n else\n len=[src], src=src+1, disp=[src], src=src+1 ;len, disp\n if disp>=80h then disp=(disp-80h)*100h+[src], src=src+1 ;longer disp\n for i=1 to (len+3), [dst]=[dst-(disp+1)], dst=dst+1, next i\n endif\n goto @@decompress_lop\n @@decompress_done:\n ret\nDepending on the source, only the compressed or decompressed size may be known:
Source Compressed Size Decompressed Size\n Compressed GAMEFONT.DAT In ISO Filesystem Unknown (n/a)\n Compressed GT-ARC In ISO Filesystem Unknown (n/a)\n Files in GT-ARC In GT-ARC In GT-ARC\n Files with GT-ZIP header Unknown (due to padding) In GT-ZIP\n DC values in IKI videos Unknown (due to padding) From Width*Height\nUsed by Rollcage (MagDemo19: ROLLCAGE\\SPEED.IMG\\*) Used by Rollcage Stage II (MagDemo31: ROLLCAGE\\SPEED.IDX\\*) Used by Sydney 2000 (MagDemo37: OLY2000\\DEMO.IDX\\* and OLY2000\\GTO\\*.GTO) Reportedly also Chill (PS1) (*.GTO) Reportedly also Ducati World: Racing Challenge Reportedly also Martian Gothic: Unification (PS1) (*.GT20)
000h 4 ID (\"GT20\"=Compressed) (or reportedly \"NOGT\"=Uncompressed)\n 004h 4 Size of decompressed data in bytes\n 008h 4 Overlap for in-situ decompression (usually 3, or sometimes 7)\n 00Ch 4 Size of Leading Zeropadding in bytes (0..7FFh)\n 010h .. Leading Zeropadding (0..7FFh bytes)\n ... .. Compressed Data\n DecompressGT20:\n src=src+word[src+0Ch]+10h ;skip header and any leading zeropadding\n collected=00000001h ;end-bit\n @@lop:\n if GetBit=0\n [dst]=[src], dst=dst+1, src=src+1 ;uncompressed byte\n else\n if GetBit=0\n disp=byte[src]-100h, src=src+1 ;disp=(-100h..-1)\n len=(GetBit*2)+(GetBit*1)+2 ;len=(2..5)\n else\n tmp=halfword[src], src=src+2\n disp=(tmp/8)-2000h ;disp=(-2000h..-1)\n len=(tmp AND 7)+2 ;len=(2..9)\n if len=2\n tmp=byte[src], src=src+1\n if (tmp AND 80h) then disp=disp-2000h ;disp=(-4000h..-1)\n len=(len AND 7Fh)+2 ;len=(2..81h)\n if len=3 then goto decompression_done\n if len=2 then len=halfword[src], src=src+2 ;len=(0..FFFFh)\n for i=1 to len, [dst]=[dst+disp], dst=dst+1, next i\n goto @@lop\n ;---\n GetBit:\n collected=collected SHR 1\n if zero then collected=(word[src] SHR 1)+80000000h, src=src+4\n return carry (from shift right)\nUsed by Bloody Roar 1 (MagDemo06: BL\\.DAT\\) Used by Bloody Roar 2 (MagDemo22: ASC,CMN,EFT,LON,SND,ST5,STU\\.DAT\\)
000h 4 Compression Method (0=None, 2=Compressed, Other=Invalid)\n 004h 4 Compressed Size (SIZ) (same as decompressed when method=0)\n 008h 4 Decompressed Size\n 00Ch SIZ Compressed Data\n ... .. Garbagepadding to 4-byte boundary (in 4-byte aligned DAT files)\n DecompressPreGT20:\n src=src+0Ch ;skip header\n collected=80h ;end-bit\n @@lop:\n if GetBit=1\n [dst]=[src], dst=dst+1, src=src+1 ;uncompressed byte\n else\n if GetBit=0\n len=(GetBit*2)+(GetBit*1)+2 ;len=(2..5)\n disp=byte[src]-100h, src=src+1 ;disp=(-100h..-1)\n else\n tmp=bigendian_halfword[src], src=src+2\n disp=(tmp/8)-2000h ;disp=(-2000h..-1)\n len=(tmp AND 7)+2 ;len=(2..9)\n if len=2\n len=byte[src]+1, src=src+1 ;len=(1..100h)\n if len=1 then goto decompression_done\n for i=1 to len, [dst]=[dst+disp], dst=dst+1, next i\n goto @@lop\n ;---\n GetBit:\n collected=collected SHL 1 ;8bit shift\n if zero then collected=(byte[src] SHL 1)+01h, src=src+1\n return carry (from 8bit shift left)\nUsed by Project Horned Owl (*.BIN\\*) (and within self-decompressing EXE)
"},{"location":"cdromfileformats/#hornedlz-detection","title":"HornedLZ Detection","text":"The easiest way to detect HornedLZ files is to check first 4 bytes:
B3 10 00 4F .. Compressed TIM with TIM Type=00h (4bpp without CLUT)\n DB 10 00 3F .. Compressed TIM with TIM Type=08h,09h,etc.\n Type=05h can be uncompressed .TXT or HornedLZ-compressed .TIM\n (check if 2nd data byte is ASCII or 10h)\n Type=0Fh is a DOT1 archive with HornedLZ-compressed .TIMs\n (parse the DOT1 archive and treat its contents as compressed .TIMs)\n Type=10h contains Deflated TIMs\n (a completely different compression method)\n collected=01h ;end-bit\n @@lop:\n if GetBit=1\n [dst]=[src], dst=dst+1, src=src+1 ;uncompressed byte\n else\n if GetBit=1\n tmp=[src], src=src+1\n len=tmp/40h+2, disp=tmp or (-40h) ;len=(2..05h), disp=(-40h..-1)\n else\n tmp=[src]*100h+[src+1], src=src+2\n len=tmp/1000h+2, disp=tmp or (-1000h) ;len=(2..11h), disp=(-1000h..-1)\n if len=2 then\n len=[src]+2, src=src+1 ;len=(2..101h)\n if len=2 then goto decompression_done\n for i=1 to len, [dst]=[dst+disp], dst=dst+1, next i\n goto @@lop\n ;---\n GetBit:\n collected=collected SHR 1\n if zero then collected=([src] SHR 1)+80h, src=src+1\n return carry (from shift right)\n 000h 4 ID (\"lzs\",00h)\n 004h 4 Zerofilled\n 008h 4 Fixed (must be 1) (method/version?)\n 00Ch 14h Zerofilled\n 020h 2 Fixed (must be 3) (method/version?)\n 022h 2 Offset to Compressed Data minus 20h (usually 38h-20h)\n 024h 4 Decompressed Size\n 028h 2 Flagsize (must be 08h, 10h, or 20h) (usually 20h=32bit)\n 02Ah 2 Lensize (must be 02h..07h) (usually 05h=5bit)\n 02Ch 4 Compressed Size (total filesize, including \"lzs\" header)\n 030h 8 Name? (always \"000000\",00h,00h)\n 038h .. Compressed data (usually at offset 38h)\n dst_end = dst+littleendian32bit[src+24h]\n flg_bits = littleendian16bit[src+28h] ;8,16,32\n len_bits = littleendian16bit[src+2Ah] ;2..7\n len_mask = (1 shl len_bits)-1 ;03h..7Fh\n src=src+littleendian16bit[src+22h]+20h\n collected_bits=0\n @@collect_more:\n for i=0 to flg_bits/8-1 ;read 8bit/16bit/32bit little-endian\n collected_bits=collected_bits+([src] SHL (i*8)), src=src+1\n num_collected=flg_bits\n @@decompress_lop:\n if dst=dst_end then goto @@decompress_done\n if num_collected=0 then goto @@collect_more\n num_collected=num_collected-1\n flagbits=flagbits SHR 1\n if carry=1 then\n [dst]=[src], dst=dst+1, src=src+1\n else\n temp=bigendian16bit[src], src=src+2\n len=(temp AND len_mask)+3\n disp=(temp SHR len_bits), if disp=0 then goto @@decompress_error\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n endif\n goto @@decompress_lop\n @@decompress_done:\n ret\nUsed in .BZZ archives. Note that there are three slightly different .BZZ archive formats (they are all using the same BZZ compression, only the BZZ archive headers are different).
Jersey Devil .BZZ (MagDemo10: JD\\*.BZZ)\n Bugs Bunny: Lost in Time (MagDemo25: BBLIT\\*.BZZ)\n The Grinch (MagDemo40: GRINCH\\*.BZZ)\nThe compression is fairly standard LZSS, except that it supports non-linear length values, and it does support uncommon Len/Disp pairs like 7bitLen/9bitDisp (though usually, it does use standard 4bitLen/12bitDisp).
decompress_bzz:\n method=byte[src], src=src+1 ;method (00h..1Fh) ;usually/always 0Bh)\n shifter = ((method/8) and 3) ;00h..03h ;usually 1\n len_bits = ((method and 7) xor 7) ;07h..00h ;usually 4\n len_mask = (1 shl len_bits)-1 ;7Fh..00h ;usually 0Fh\n threshold=len_mask/2, if threshold>07h then threshold=13h ;usually 07h\n for i=0 to len_mask\n if i>threshold then len_table[i] = ((i-threshold) shl shifter)+threshold+3\n else len_table[i] = i+3 ;method=18h max=(7Fh-13h)*8+13h+3=376h=886 decimal\n next i ;method=0Hh max=(0Fh-07h)*2+07h+3=1Ah=26 decimal\n num_flags=bigendian24bit[src]+1, src=src+3 ;NUM24+1\n @@collect_more:\n if src>=src_end then goto @@decompress_error\n flagbits=[src]+100h, src=src+1 ;8bit flags\n @@decompress_lop:\n flagbits=flagbits SHR 1\n if zero then goto @@collect_more\n if carry=1 then\n if src>=src_end then goto @@decompress_error\n [dst]=[src], dst=dst+1, src=src+1\n else\n if src+1>=src_end then goto @@decompress_error\n temp=bigendian16bit[src], src=src+2\n len=len_table[temp AND len_mask]\n disp=temp SHR len_bits, if disp=0 then goto @@decompress_error\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n endif\n num_flags=num_flags-1, if num_flags>0 then goto @@decompress_lop\n @@decompress_error:\n ret\n Case 1) source has NUM24+1 codes\n --> decode all NUM24+1 codes (otherwise output will be too small)\n Case 2) source has NUM24 codes (and enough padding for another code)\n --> decode all NUM24+1 codes (for compatibility with case 1)\n --> output will have some constant garbage byte(s) appended\n --> exception: omit last code if it contains invalid disp=0\n Case 3) source has NUM24 codes (and not enough padding for another code)\n --> decode only NUM24 codes (abort if NUM24+1 exceeds src_end)\n --> output should (probably) have correct size\n --> never exceed src_end which would be highly unstable\n decompression function:\n base=src, method=[src], dst_end=dst+BigEndian24bit[src+1], src=src+4\n @@decompress_lop:\n if dst>=dst_end then goto @@decompress_done\n if [src] AND 80h then\n if method=01h then\n len=([src]-80h)/8+3, disp=(BigEndian16bit[src] AND 7FFh)+1, src=src+2\n else ;method=02h\n len=([src]-80h)+4, disp=(BigEndian16bit[src+1])+1, src=src+3\n for i=1 to len, [dst]=[dst-disp], dst=dst+1\n else ;uncompressed\n len=[src]+1, src=src+1\n for i=1 to len, [dst]=[src], src=src+1, dst=dst+1\n goto @@decompress_lop\n @@decompress_done:\n src=(src+3) AND NOT 3\n if LittleEndian32bit[src]<>crc(base, src-base) then error\n ret\nNormally only Top-level archives contain compression, however, there are also some Nested archives with compression in BallBlazer Champions:
STD_BBX.DAT\\s*t\\tp_a\\* ;\\double compression, Top-level is ALSO compressed\n BBX_INTR.DAT\\data1\\pics\\* ;/\n BBX_INTR.DAT\\Stad\\pics\\* ;\\\n BBX_INTR.DAT\\Stad\\wire\\* ; Nested archives with compression\n BBX_INTR.DAT\\Subtitl\\* ;\n BBX_INTR.DAT\\Subtitl\\sub\\*;/\nApe Escape (Sony 1999) (MagDemo22: KIDZ\\) has several compressed and uncompressed TIMs in headerless archives, the archives can contain:
Compressed 4bpp RLE4-TIM with uncompressed CLUT ;\\only 4bpp can be compressed\n Compressed 4bpp RLE8-TIM with uncompressed CLUT ;/\n Uncompressed 4bpp TIM with uncompressed CLUT ;\\only this type/combinations\n Uncompressed 8bpp TIM with uncompressed CLUT ; are allowed if uncompressed\n Uncompressed 16pp TIM without CLUT ;/\n End code 00000000h (plus more zeropadding) ;-end of headerless archive\n hdr[02h]=Method (0000h=Uncompressed, 0001h=RLE4, 0002h=RLE8)\n @@decompress_lop:\n color=[src]/10h, len=([src] AND 0Fh)+1, src=src+1\n for i=1 to len, putpixel(color), next i ;len=1..10h\n if numpixels<Width*Height*4 then goto @@decompress_lop\n @@decompress_lop:\n color1=[src]/10h, color2=[src] AND 0Fh, src=src+1\n if color1=color2\n len=[src]+2, src=src+1\n for i=1 to len, putpixel(color1), next i ;len=2..101h\n else\n putpixel(color1), if numpixels<Width*Height*4 then putpixel(color2)\n for i=1 to len, putpixel(color) ;len=1..10h\n if numpixels<Width*Height*4 then goto @@decompress_lop\n 80078760h ape_escape_load_tim_archive\n 8007894Ch ape_escape_decompress_with_4bit_lengths\n 800789FCh ape_escape_decompress_with_8bit_lengths\n RLE8: Ape Escape, MagDemo22: KIDZ\\KKIIDDZZ.HED\\DAT\\file004h\\1stTIM\n RLE4: Ape Escape, MagDemo22: KIDZ\\KKIIDDZZ.HED\\DAT\\file135h\\1stTIM\n RLE8: Ape Escape, MagDemo22: KIDZ\\KKIIDDZZ.HED\\DAT\\file139h\\1stTIM\n 000h 8 ID \"_RLE_16_\"\n 008h 4 Decompressed Size (usually 3C008h) (33408h=Apocalypse warning.rle)\n 00Ch .. RLE Compressed Data (usually a .BMR bitmap)\n src=src+0Ch ;skip ID and size\n @@decompress_lop:\n len=halfword[src], src=src+2\n if len=0000h then goto @@decompress_done ;end-code\n if (len AND 8000h)=0 then\n for i=1 to len, halfword[dst]=halfword[src], dst=dst+2, src=src+2, next i\n else\n fillvalue=halfword[src], src=src+2\n for i=1 to len-8000h, halfword[dst]=fillvalue, dst=dst+2, next i\n goto @@decompress_lop\n @@decompress_done:\n ret\nA similar RLE16 variant is used in Croc 1, and another variant in Croc 2. CDROM File Archive Croc 1 (DIR, WAD, etc.) CDROM File Archive Croc 2 (DIR, WAD, etc.)
"},{"location":"cdromfileformats/#cdrom-file-compression-pimprs-legend-of-mana","title":"CDROM File Compression PIM/PRS (Legend of Mana)","text":""},{"location":"cdromfileformats/#legend-of-mana-pimprs","title":"Legend of Mana (.PIM/.PRS)","text":" 000h 1 Unknown (always 01h) (maybe File ID or Compression method)\n 001h .. Compressed data ;for TIM: usually 00,10, F0,00, 00,0x, F0,00, ...\n nn,data[nn+1] ;nn=00..EF len=nn+1 [dst]=data[1] ;-uncompressed\n F0,xn len=n+3 [dst]=0x ;1x4bit ;\\\n F1,nn,xx len=nn+4 [dst]=xx ;1x8bit ;\n F2,nn,yx len=nn+2 [dst]=0x,0y ;2x4bit ; RLE fill\n F3,nn,xx,yy len=nn+2 [dst]=xx,yy ;2x8bit ;\n F4,nn,xx,yy,zz len=nn+2 [dst]=xx,yy,zz ;3x8bit ;/\n F5,nn,xx,data[nn+4] len=nn+4 [dst]=xx,data[1] ;\\interleaved\n F6,nn,xx,yy,data[nn+3] len=nn+3 [dst]=xx,yy,data[1] ; fill combo\n F7,nn,xx,yy,zz,data[nn+2] len=nn+2 [dst]=xx,yy,zz,data[1] ;/\n F8,nn,xx len=nn+4 [dst]=xx ;xx=xx+1 ;\\\n F9,nn,xx len=nn+4 [dst]=xx ;xx=xx-1 ; fill with\n FA,nn,xx,ss len=nn+5 [dst]=xx ;xx=xx+ss ; signed step\n FB,nn,xx,yy,ss ;ss=signed len=nn+3 [dst]=xx,yy ;yyxx=yyxx+ss ;/\n FC,xx,ny len=n+4 [dst]=[dst-yxx-1] ;\\\n FD,xx,nn len=nn+14h [dst]=[dst-xx-1] ; LZ compress\n FE,xn len=n+3 [dst]=[dst-x*8-8] ;/\n FF len=0 end ;-end code\n BIN\\*.BIN ---> packed misc binary\n MAP\\*\\FDATA.PRS ---> packed resource, whatever\n MAP\\*\\MAP*.PRS ---> packed MPD resource, \"SKmapDat\"\n WM\\WMTIM\\*.PIM ---> packed TIM image, 384x384x4bpp, bad compression ratio\n WM\\WMAP\\*.PAT ---> packed loaddata\n WM\\WMAP\\*.PIM ---> packed TIM image, 320x256x16bit, with UNCOMPRESSED dupe\nByte Pair Encoding (BPE) does replace the most common byte-pairs with bytes that don't occur in the data. That does work best if there are unused bytes (eg. ASCII text, or 8bpp bitmaps with less than 256 colors).
"},{"location":"cdromfileformats/#bust-a-groove-magdemo18-bustgr_abpe","title":"Bust A Groove (MagDemo18: BUSTGR_A\\*.BPE)","text":""},{"location":"cdromfileformats/#bust-a-groove-2-magdemo37-bustagr2bust2bin","title":"Bust-A-Groove 2 (MagDemo37: BUSTAGR2\\BUST2.BIN\\*)","text":" 000h 4 ID \"BPE_\"\n 004h 4 Total Filesize of compressed file including header (big-endian)\n ... .. Compression block(s)\n Each compression block contains:\n 000h .. Dictionary info\n ... 2 Size of compressed data (big-endian)\n ... .. Compressed data\n 000h 4 Decompressed size (little-endian)\n 004h 4 ID \"BPE\",1Ah\n 008h .. Compression block(s)\n ... .. End code (00000000h) (aka last block with Blocksize=0)\n Each compression block contains:\n 000h 4 Size of decompressed block (little-endian) (or 0=End code)\n 004h .. Dictionary info\n ... .. Compressed data\n ... .. Padding to 4-byte boundary\n if [src+0]=\"BPE_\" then type=GROOVE ;\\\n if [src+4]=\"BPE\",1Ah then type=DRAGOON ;\n if type=GROOVE then src_end = src+BigEndian32bit[src+4] ; hdr\n if type=DRAGOON then dst_end = dst+LittleEndian32bit[src+0] ;\n src=src+8 ;/\n @@block_lop:\n if type=DRAGOON then ;\\blk\n dst_blk_end = dst+LittleEndian32bit[src]+4, src=src+4 ; len\n if dst=dst_blk_end then goto @@decompress_done ;/\n for i=00h to FFh, dict1[i]=i, next i ;\\\n i=00h ;\n @@dict_lop: ; dict\n num=[src], src=src+1 ;\n if num>7Fh then i=i+(num-7Fh), num=0, if i=100h then goto @@dict_done ;\n for j=0 to num ;\n a=[src], src=src+1 ;\n if a<>i then b=[src], src=src+1, dict1[i]=a, dict2[i]=a ;\n i=i+1 ;\n if i<100h then goto @@dict_lop ;\n @@dict_done: ;/\n if type=GROOVE then ;\\blk\n src_blk_end = src+BigEndian16bit[src]+2, src=src+2 ;/len\n i=0 ;\\\n @@data_lop: ;\n if i=0 then ;\\ ; data\n if type=GROOVE and src=src_blk_end then goto @@data_done ; get data ;\n if type=DRAGOON and dst=dst_blk_end then goto @@data_done; from src ;\n x=[src], src=src+1 ; or heap ;\n else ; ;\n i=i-1, x=heap[i] ;/ ;\n a=dict1[x] ;-xlat ;\n if a=x then ;\\ ;\n [dst]=x, dst=dst+1 ; output data to ;\n else ; dst or heap ;\n b=dict2[x], heap[i]=b, heap[i+1]=a, i=i+2 ;/ ;\n goto @@data_lop ;\n @@data_done: ;/\n if type=GROOVE and src<src_end then goto @@block_lop ;\\next\n if type=DRAGOON then src=(src+3) AND not 3, goto @@block_lop ;/blk\n @@decompress_done:\n if type=DRAGOON and dst<>dst_end then error\n ret\nElectronic Arts games support several compression methods, including a BPE variant. That BPE variant is a bit unusual: It does have only one compression block (with a single dictionary for the whole file), and uses escape codes for rarely used bytes. CDROM File Compression EA Methods
"},{"location":"cdromfileformats/#cdrom-file-compression-rnc-rob-northen-compression","title":"CDROM File Compression RNC (Rob Northen Compression)","text":""},{"location":"cdromfileformats/#rob-northen-compression","title":"Rob Northen compression","text":"Rob Northen compression (RNC) is a LZ/Huffman compression format used by various games for PC, Amiga, PSX, Mega Drive, Game Boy, SNES and Atari Lynx. Most RNC compressed files come in a standard 12h-byte header:
000h 3 Signature (\"RNC\") (short for Rob Northen Computing compression)\n 003h 1 Compression Method (01h or 02h)\n 004h 4 Size of Uncompressed Data ;big-endian\n 008h 4 Size of Compressed Data (SIZ) ;big-endian\n 00Ch 2 CRC16 on Uncompressed Data (with initial value 0000h) ;big-endian\n 00Eh 2 CRC16 on Compressed Data (with initial value 0000h) ;big-endian\n 010h 1 Leeway (difference between compressed and uncompressed data in\n largest pack chunk, if larger than decompressed data)\n 011h 1 Number of pack chunks\n 012h SIZ Compressed Data\n ... (..) Zeropadding to 800h-byte boundary-4 ;\\as so in PSX Heart of Darkness\n ... (4) Unknown ;/\nThe bit-stream is read in 16bit units (the 1st bit being in bit0 of 1st byte).
Each pack chunk contains the following:\n * 3 Huffman trees (one for literal data sizes, one for distance values,\n and one for length values) in the bit stream. These consist of:\n o A 5 bit value for the amount of leaf nodes in the tree\n o 4 bit values for each node representing their bit depth.\n * One 16 bit value in the bitstream for the amount of subchunks in the\n pack chunk.\n * The subchunk data, which contains for each subchunk:\n o A Huffman code value from the first tree in the bit stream for the\n amount of literals in the byte stream.\n o Literals from the byte stream.\n o A Huffman code from the bit stream that represents the distance - 1\n of a distance/length pair.\n o A Huffman code from the bit stream that represents the length - 2\n of a distance/length pair.\nThe bit-stream is read in 8bit units (the 1st bit being in bit7).
0 + Byte(DATA[1]) Copy 1 Byte from Source\n 1000 + Dist + Byte(X) Copy 4 Bytes from Dest-(Dist+X+1)\n 10010 + Dist + Byte(X) Copy 6 Bytes from Dest-(Dist+X+1)\n 10011 + Dist + Byte(X) Copy 7 Bytes from Dest-(Dist+X+1)\n 1010 + Dist + Byte(X) Copy 5 Bytes from Dest-(Dist+X+1)\n 10110 + Dist + Byte(X) Copy 8 Bytes from Dest-(Dist+X+1)\n 10111 + nnnn + Byte(DATA[12..72]) Copy nnnn*4+12 Bytes from Source\n 110 + Byte(X) Copy 2 Bytes from Dest-(X+1)\n 1110 + Dist + Byte(X) Copy 3 bytes from Dest-(Dist+X+1)\n 1111 + Byte(0) + 0 + zeropadding End of last pack chunk\n 1111 + Byte(0) + 1 End of non-last pack chunk\n 1111 + Byte(L) + Dist + Byte(X) Copy L+8 Bytes from Dest-(Dist+X+1) ;L>00h\n 0 = 0000h 1000 = 0200h\n 110 = 0100h 1001 = 0300h\n 111000 = 0C00h 101000 = 0800h\n 111001 = 0D00h 101001 = 0900h\n 11101 = 0600h 10101 = 0400h\n 111100 = 0E00h 101100 = 0A00h\n 111101 = 0F00h 101101 = 0B00h\n 11111 = 0700h 10111 = 0500h\nhttp://aminet.net/package/util/pack/RNC_ProPack - official tool & source code https://segaretro.org/Rob_Northen_compression - description (contains bugs)
RNC is used in a number of games by UK developers (notably Bullfrog and Traveller's Tales), including Sonic 3D: Flickies' Island, Blam! Machinehead, Dungeon Keeper 2, Magic Carpet, Syndicate and Syndicate Wars.
"},{"location":"cdromfileformats/#rnc-in-psx-games","title":"RNC in PSX Games","text":" Method 2: Demolition Racer (MagDemo27: DR\\DD.DAT\\*.RNC)\n Method 2: Heart of Darkness (IMAGES\\US.TIM)\n Method 2: Jonah Lomu Rugby (LOMUDEMO\\GFX\\*.PAK)\n Method 2: NBA Jam: Tournament Edition (*.RNC, headerless .BIN/.GFX archives)\n Method 2: Test Drive 5 (MagDemo13: TD5.DAT\\*.RNC)\n Method 2: Test Drive Off-Road 3 (MagDemo27: TDOR3\\TDOR3.DAT\\*.rnc)\n 3 Ninjas Kick Back\n Addams Family\n Addams Family Values\n The Adventures of Mighty Max\n Asterix and the Great Rescue\n Asterix and the Power of the Gods\n The Incredible Hulk\n The Itchy & Scratchy Game (unreleased)\n Marsupilami\n Mortal Kombat\n Mr. Nutz\n Outlander\n The Pagemaster\n RoboCop 3\n Spirou\n Spot Goes to Hollywood\n Stargate\n Street Racer\n Tinhead\n Tintin in Tibet\n World Championship Soccer II\nUsed by Alone in the Dark The New Nightmare (FAT.BIN\\LEVELS\\*\\chunks)
"},{"location":"cdromfileformats/#decompression_2","title":"Decompression","text":"The decompressor is designed to hook the sector loading function: It does decompress incoming sectors during loading, and forwards the decompressed data to the original sector loading function. The decompressed data is temporarily stored in two small Dict buffers (which do also serve as compression dictionary).
decompress:\n dictsize=1000h, dict0=alloc(dictsize), dict1=alloc(dictsize)\n src=load_next_800h_byte_sector ;load first sector\n dst=dict0 ;temp dest in current dict\n dst_base=dst ;memorize start of newly decompressed data\n @@decompress_lop:\n if [src]=00h then ;\\\n esc=[src+1], src=src+1 ;\n forward_to_actual_dest(source=dst_base, len=dst-dst_base) ; escape\n if esc=0 or esc>4 then esc=2 (or warn_invalid_escape_code) ;\n if esc=1 then goto @@decompress_done ;\n if esc=2 or esc=4 then src=load_next_800h_byte_sector ;\n if esc=3 or esc=4 then swap(dict0,dict1), dst=dict0 ;\n dst_base=dst ;/\n elseif ([src] AND 03h)=0 then ;\\\n len=[src]/4+2, dat=[src+1], src=src+2 ; fill 8bit\n for i=1 to len, [dst]=dat, dst=dst+1 ;/\n elseif ([src] AND 03h)=1 then ;\\\n len=[src]/4+([src+2] AND 40h)+4 ;\n ptr=[src+1]+([src+2] AND 3Fh)*100h ; LZ compressed\n if ptr+len>dictsize then error (exceeds allocated dictsize) ;\n if ([src+2] AND 80h) then ptr=ptr=dict1 else ptr=ptr=dict0 ;\n src=src+3 ;\n for i=1 to len, [dst]=[ptr], ptr=ptr+1, dst=dst+1 ;/\n elseif ([src] AND 03h)=2 then ;\\\n len=[src]/4+3, dat0=[src+1], dat1=[src+2], src=src+3 ; fill 16bit\n for i=1 to len, [dst]=dat0, [dst+1]=dat1, dst=dst+2 ;/\n elseif ([src] AND 03h)=3 then ;\\\n len=[src]/4+1, src=src+1 ; uncompressed\n for i=1 to len, [dst]=[src], src=src+1, dst=dst+1 ;/\n goto @@decompress_lop\n @@decompress_done:\n dealloc(dict0), dealloc(dict1)\n ret\nDecompression function:
if LittleEndian32bit[src+08h]<>1 then error ;compression flag\n dst_end=dst+LittleEndian32bit[src+14h], src=src+18h, num_collected=0\n @@decompress_lop:\n if GetBit=1 then\n [dst]=[src], src=src+1, dst=dst+1 ;code 1 uncompressed byte\n elseif GetBit=1 then\n len=[src], src=src+1 ;code 01 fill or end code\n if len=00h then goto @@decompress_done\n len=len+1, fillvalue=[dst-1]\n for i=1 to len, [dst]=fillvalue, dst=dst+1\n else\n len=GetBit*2+GetBit\n if len=0 then ;code 0000 long LZ range\n len=[src] AND 0Fh, disp=[src]/10h+[src+1]*10h-1000h, src=src+2\n else ;code 00xx short LZ range\n disp=[src]-100h, src=src+1\n len=len+1\n for i=1 to len, [dst]=[dst+disp], dst=dst+1\n goto @@decompress_lop\n @@decompress_done:\n if dst<>dst_end then error\n ret\n ;---\n GetBit:\n if num_collected=0 then collected=[src], src=src+1, num_collected=8\n collected=collected*2\n return (collected/100h) AND 1\n decompress_z:\n src=src+4 ;skip 32bit decompressed size entry\n @@reload_lop:\n load_table1 ;table for first 9bits\n load_table2 ;table for codes longer than 9bits\n @@decompress_lop:\n sym=get_symbol()\n if sym<100h then [dst]=sym, dst=dst+1, goto @@decompress_lop\n if sym=100h then goto @@escape\n len=sym-0FCh ;change 101h..140h to 05h..44h\n disp=((get_symbol()-101h)*40h) ;change 101h..140h to 00h..3Fh*40h\n disp=((get_symbol()-101h) or disp)+1 ;change 101h..140h to 00h..3Fh+above+1\n copy len bytes from dst-disp to dst\n goto @@decompress_lop\n @@escape:\n if GetBits(1)=0 then goto @@reload_lop\n ret\n ;-----\n load_table1:\n t=0\n @@load_lop:\n x=GetBits(10h)\n if x and 8000h then num=1 else num=(1 shl (9-(x/400h)))\n for i=1 to num, table1[t]=x, t=t+1, next i\n if t<200h then goto @@load_lop\n ret\n ;-----\n load_table2:\n num=GetBits(9)*2 ;can be 0=none, max=3FEh\n if num>0 then for i=0 to num-1, table2[i]=GetBits(9), next i\n ret\n ;-----\n get_symbol:\n ;returns a value in range 0..140h:\n ; 00h..FFh = data 00h..FFh (or unused for disp codes)\n ; 100h = escape (or unused for disp codes)\n ; 101h..140h = length 05h..44h (or 6bit fraction of 12bit disp)\n ; 141h..3FFh = would be possible for short codes, but shouldn't be used\n x=table1[PeekBits(9)]\n if (x and 8000h)=0 then SkipBits(x/400h), return (x and 3FFh) ;-short code\n SkipBits(9) ;skip first 9 bits, and process futher bit(s).. ;\\\n x=x-0C000h ;change C000h..C1FFh and up to 000h..1FFh ; long code\n @@lop: ; (with more\n x=table2[x*2+GetBits(1)] ;branch node0/node1 ; than 9bit)\n if x>=141h then x=x-141h, goto @@lop ;\n return x ;/\nZAL compression is used in ZAL archives. The archive header contains compressed and decompressed size for each file (and a compression flag indicating whether the archive is compressed at all).
"},{"location":"cdromfileformats/#zal-decompression","title":"ZAL Decompression","text":" if src_len=0 then goto @@decompress_done ;empty (without end code)\n lzlen=0, rawlen=0\n if [src]=10h..FFh then ;\\special handling\n rawlen=[src]-11h, src=src+1 ; for code=10h..FFh\n if rawlen<=0 then goto @@decompress_error ;/at begin of source\n @@decompress_lop:\n memcopy(dst-disp,dst,lzlen) ;copy compressed bytes\n memcopy(src,dst,rawlen) ;copy uncompressed bytes\n code=[src], src=src+1\n if code=00h..0Fh then\n if rawlen=0 ;when OLD rawlen=0...\n lzlen=0, rawlen=code+3 ;\\\n if rawlen=3 then ;\n while [src]=00h, rawlen=rawlen+FFh, src=src+1 ;\n rawlen=rawlen+[src]+0Fh, src=src+1 ;/\n else ;when OLD rawlen>0, and depending on OLD lzlen...\n rawlen=code AND 03h\n disp=code/4+[src]*4, src=src+1\n if lzlen=0 then disp=disp+801h, lzlen=3, else then disp=disp+1h, lzlen=2\n if code=10h..1Fh then\n lzlen=(code AND 07h)+2\n if lzlen=2 then\n while [src]=00h, lzlen=lzlen+FFh, src=src+1\n lzlen=lzlen+[src]+07h, src=src+1\n rawlen=[src] AND 03h, disp=[src]/4+[src+1]*40h+(code/8 AND 1)*4000h+4000h\n src=src+2\n if disp=4000h AND code=11h then goto @@decompress_done ;end code\n if disp=4000h AND code<>11h then goto @@decompress_error\n if code=20h..3Fh then\n lzlen=code-20h+2\n if lzlen=2 then\n while [src]=00h, lzlen=lzlen+FFh, src=src+1\n lzlen=lzlen+[src]+1Fh, src=src+1\n rawlen=[src] AND 03h, disp=[src]/4+[src+1]*40h+1, src=src+2\n if code=40h..FFh then\n rawlen=code AND 03h\n lzlen=(code/20h)+1\n disp=((code/4) AND 07h)+([src]*8)+1, src=src+1\n goto @@decompress_lop\n @@decompress_done:\n ret\nThe files start with a 16bit big-endian Method value, with following bits:
0-7 ID (usually FBh) (or 31h for Method 4A31h with 16bit sizes)\n 8 Extended Header (usually 0) (or 1 for headers with extra entries)\n 9-14 Used to distinguish different methods\n 15 Extended Size (usually 0 for 24bit sizes) (or 1 for 32bit sizes)\n 10FBh = LZSS Compression (RefPack)\n 90FBh = LZSS Compression (RefPack, with 32bit size) (not on PSX)\n 30FBh = Huffman Compression\n 32FBh = Huffman Compression with filter\n 34FBh = Huffman Compression with dual filter\n 46FBh = BPE Byte-Pair Encoding\n 4AFBh = RLE Run-Length Encoding\n 4A31h = RLE Run-Length Encoding, with 16bit size\n C0FBh = File Archive (not a compression method)\nCDROM File Compression EA Methods (LZSS RefPack) CDROM File Compression EA Methods (Huffman) CDROM File Compression EA Methods (BPE) CDROM File Compression EA Methods (RLE)
"},{"location":"cdromfileformats/#usage-in-psx-games","title":"Usage in PSX games","text":"The compression can be used to compress whole files:
PGA Tour 96, 97, 98 (*.* and *.VIV\\*) (with method 10FBh)\n Need for Speed 3 Hot Pursuit (*.Q* with method 10FBh, 30FBh, 32FBh)\n FIFA - Road to World Cup 98 (*.PSH chunk C0h/C1h with method 10FBh)\n Sled Storm (MagDemo24: ART3\\LOAD*.PSH chunk C0h/C1h with method 10FBh)\n WCW Mayhem (MagDemo28: WCWDEMO\\*.BIG\\*.PSH with chunk C0h/C1h with 10FBh)\nNote: Some compressed files are slightly larger than uncompressed files (eg. filesizes for PGA Tour 96, 97, 98 COURSES\\\\.VIV\\*.mis are compressed=58h, uncompressed=50h).
"},{"location":"cdromfileformats/#see-also_6","title":"See also","text":"http://wiki.niotso.org/RefPack - LZ method
"},{"location":"cdromfileformats/#cdrom-file-compression-ea-methods-lzss-refpack","title":"CDROM File Compression EA Methods (LZSS RefPack)","text":""},{"location":"cdromfileformats/#refpack","title":"RefPack","text":" 000h 2 Method (10FBh, or 11FBh,90FBh,91FBh) (big-endian)\n ... (3/4) Compressed size (24bit or 32bit) (optional)\n ... 3/4 Uncompressed size (24bit or 32bit) (big-endoan)\n ... .. Compressed data\n 0ddzzzrrdddddddd rawlen=r(2), lzlen=z(3)+3, disp=d(10)+1\n 10zzzzzzrrdddddddddddddd rawlen=r(2), lzlen=z(6)+4, disp=d(14+1\n 110dzzrrddddddddddddddddzzzzzzzz rawlen=r(2), lzlen=z(10)+5, disp=d(17)+1\n 111rrrrr rawlen=r(5)*4+4, lzlen=0\n 111111rr rawlen=r(2), lzlen=0, endflag=1\n method=BigEndian16bit[src], src=src+2\n if (method AND 100h)>0 then src=src+3+method/8000h ;compressed size, if any\n if (method AND 8000h]=0 then dst_size=BigEndian24bit[src], src=src+3\n if (method AND 8000h)>0 then dst_size=BigEndian32bit[src], src=src+4\n endflag=0\n @@decompress_lop:\n if ([src] AND 80h)=0 then\n rawlen=[src] AND 03h\n lzlen=([src] AND 1Fh)/4+3\n disp=([src] AND 60h)*8+[src+1]+1\n src=src+2\n elseif ([src] AND 40h)=0 then\n rawlen=[src+1]/40h\n lzlen=[src] AND 3Fh+4\n disp=([src+1] AND 3Fh)*100h+[src+2]+1\n src=src+3\n elseif ([src] AND 20h)=0 then\n rawlen=[src] AND 03h\n lzlen=([src] AND 0Ch)*40h+[src+3]+5\n disp=([src] AND 10h)*1000h+[src+1]*100h+[src+2]+1\n src=src+4\n elseif ([src] AND FCh)=FCh then\n rawlen=[src] AND 03h\n lzlen=0\n src=src+1, endflag=1\n else\n rawlen=([src] AND 1Fh)*4+4\n lzlen=0\n src=src+1\n for i=1 to rawlen, [dst]=[src], src=src+1, dst=dst+1, next i\n for i=1 to lzlen, [dst]=[dst-disp], dst=dst+1, next i\n if endflag=0 then goto @@decompress_lop\n if (dst-dst_base)<>dst_size then error\n ret\n 000h 2 Method (30FBh..35FBh) (big-endian)\n ... (3) Extra 3 bytes (only present if Method.bit8=1)\n ... 3 Decompressed Size (big-endian)\n ... 1 Escape code\n ... .. Number of codes per width\n ... .. Data placement for each code\n ... .. Compressed Data\n decompress_ea_huffman:\n method=GetBits(16) ;3xFBh ;-get method (30FBh..35FBh)\n if method AND 100h then dummy=GetBits(24) ;-skip extra (if any)\n dst_size=GetBits(24) ;-get uncompressed size\n ESC=GetBits(8) ;-get escape code\n huffwidth=0, huffcode=0, totalnumcodes=0 ;\\\n while (huffcode shl (10h-huffwidth))<10000h ;\n num=GetVarLenCode ; get num codes per width\n huffwidth=huffwidth+1 ;\n numcodes_per_width[width]=num ;\n totalnumcodes=totalnumcodes+num ;\n huffcode=(huffcode*2)+num ;/\n for i=0 to FFh, data_defined_flags[i]=00h ;\\\n dat=FFh, index=0 ;\n while index<totalnumcodes ;\n n=GetVarLenCode+1 ;- ; get/assign data values\n while n>0 ;search Nth notyet defined entry ;\n dat=(dat+1) AND FFh ;wrap in 8bit range! ;\n if data_defined_flags[dat]=0 then n=n-1 ;\n data_defined_flags[dat]=1 ;\n data_values[index]=dat, index=index+1 ;/\n huffcode=0000h, index=0 ;\\\n InitEmptyHuffTree(data_tree) ;\n for width=1 to huffwidth ;\n for i=1 to numcodes_per_width[width] ; create huffman tree\n dat=data_values[index], index=index+1 ;\n CreateHuffCode(data_tree,dat,huffcode,width) ;\n huffcode=huffcode+(1 shl (10h-width) ;/\n @@decompress_lop: ;\\\n dat=GetHuffCode(data_tree) ;\n if dat<>ESC ;\n [dst]=dat, dst=dst+1 ; decompress\n else ;\n num=GetVarLenCode ;\n if num=0 then ;\n if GetBits(1)=1 then goto @@decompress_done ;\n [dst]=GetBits(8), dst=dst+1 ;\n else ;\n dat=[dst-1] ;\n for i=0 to num-1, [dst]=dat, dst=dst+1 ;\n goto @@decompress_lop ;/\n @@decompress_done:\n if (dst-dst_base)<>dst_size then error ;-error check\n dst=dst_base, x=00h, y=00h ;\\\n if (method AND FEFFh)=32FBh ; optional final\n for i=0 to dst_size-1, x=x+[dst+i], [dst+i]=x ; unfiltering\n if (method AND FEFFh)=34FBh ;\n for i=0 to dst_size-1, x=x+[dst+i], y=y+x, [dst+i]=y ;/\n ret\n ;------------------\n GetVarLenCode:\n num=2\n while GetBits(1)=0, num=num+1\n return (GetBits(num)+(1 shl num)-4)\n GetBits(num):\n return \"num\" bits, fetched from big-endian bitstream\n GetHuffCode(data_tree):\n ...\n InitEmptyHuffTree(data_tree):\n ...\n CreateHuffCode(data_tree,dat,huffcode,width):\n ...\n numcodes_per_width[10h] ;9bit numcodes per width 0..15 (entry[0]=unused)\n data_values[100h] ;8bit data values for up to 100h huffman codes\n data_defined_flags[100h] ;1bit flags for data(00h..FFh)\n 000h 2 Method (46FBh or 47FBh) (big-endian)\n ... (5) Extra 5 bytes (only present if Method=47FBh)\n ... 3 Decompressed Size (big-endian)\n ... 1 Escape code\n ... 1 Number of Dict entries (N)\n ... N*3 Dict (each 3 bytes: Index,Dat1,Dat2)\n ... .. Compressed Data\n method=BigEndian16bit[src], src=src+2\n if method=47FBh then src=src+5\n dst_size=BigEndian24bit[src], src=src+3\n esc=[src], src=src+1\n num=[src], src=src+1\n for i=0 to FFh, dict1[i]=i ;initially default=self (uncompressed bytes)\n for i=1 to num, j=[src], dict1[j]=[src+1], dict2[j]=[src+2], src=src+3\n @@decompress_lop:\n x=[src], src=src+1\n if x=dict1[x] then\n if x=esc then x=[src], src=src+1, if x=00h then goto @@decompress_done\n [dst]=x, dst=dst+1\n else\n heap[0]=x, i=1\n while i>0\n i=i-1, x=heap[i], a=dict1[x]\n if a=x then [dst]=x, dst=dst+1 ;\\output data to\n else b=dict2[x], heap[i]=b, heap[i+1]=a, i=i+2 ;/dst or heap\n goto @@decompress_lop\n @@decompress_done:\n if (dst-dst_base)<>dst_size then error\n ret\n 000h 2 Method (4AFBh=24bit or 4A31h=16bit) (big-endian)\n ... 2/3 Decompressed Size (24bit or 16bit) (big-endian)\n ... .. Compressed Data\n 00h..3Fh Copy 0..3Fh uncompressed bytes\n 40h..7Fh Load new fillbyte and fill 0..3Fh bytes\n 80h..BFh Use old fillbyte and fill 0..3Fh bytes (initial fillbyte=00h)\n C0h..FFh Copy 0..3Fh bytes with constant value in upper 4bit\n method=BigEndian16bit[src], src=src+2\n if (method AND 00FFh)=31h then dst_size=BigEndian16bit[src], src=src+2\n if (method AND 00FFh)<>31h then dst_size=BigEndian24bit[src], src=src+3\n fillbyte=00h ;initially zero\n @@decompress_lop:\n type=[src]/40h, len=[src] AND 3Fh, src=src+1, dst_size=dst_size-len\n if type=0 then ;\\uncompressed bytes\n for i=1 to len, [dst]=[src], src=src+1, dst=dst+1 ;/\n elseif type=1 then ;\\\n fillbyte=[src], src=src+1 ; fill with new dat\n for i=1 to len, [dst]=fillbyte, dst=dst+1 ;/\n elseif type=2 then ;\\fill with old dat\n for i=1 to len, [dst]=fillbyte, dst=dst+1 ;/\n elseif type=3 then\n x=[src], [dst]=x, src=src+1, dst=dst+1, x=x AND F0h\n for i=2 to len ;<-- or so?\n if (i AND 1)=0 then [dst]=x+([src]/10h) dst=dst+1\n if (i AND 1)=1 then [dst]=x+([src] AND 0Fh), dst=dst+1, src=src+1\n if dst_size<>0 then goto @@decompress_lop\n ret\nInflate/Deflate is a common (de-)compression algorithm, used by ZIP, ZLIB, and GZIP.
Inflate - Core Functions Inflate - Initialization & Tree Creation Inflate - Headers and Checksums
"},{"location":"cdromfileformats/#psx-disk-images","title":"PSX Disk Images","text":"In PSX cdrom-images, ZLIB is used by the .CDZ cdrom-image format: CDROM Disk Image/Containers CDZ In PSX cdrom-images, Inflate is used by .PBP and .CHD cdrom-image formats: CDROM Disk Images PBP (Sony) CDROM Disk Images CHD (MAME)
"},{"location":"cdromfileformats/#psx-games","title":"PSX Games","text":"In PSX games, ZLIB is used by:
Twisted Metal 4 (MagDemo30: TM4DATA\\*.MR\\* and *.IMG\\*)\n Kula Quest / Kula World / Roll Away (*.PAK) (*.PAK\\*)\n (and probably more games... particulary files starting with \"x\")\n Final Fantasy VII (FF7) (BATTLE\\TITLE.BIN)\n Gran Turismo 2 (MagDemo27: GT2\\*) (with corrupted/zeropadded GZIP footers)\n Mat Hoffman's Pro BMX (old demo) (MagDemo39: BMX\\BMXCD.HED\\TITLE_H.ZLB)\n Mat Hoffman's Pro BMX (new demo) (MagDemo48: MHPB\\FE.WAD+STR)\n Project Horned Owl (COMDATA.BIN, DEMODATA.BIN, ROLL.BIN, ST*DATA.BIN)\n tinf_init() ;init constants (needed to be done only once)\n tinf_align_src_to_byte_boundary()\n repeat\n bfinal=tinf_getbit() ;read final block flag (1 bit)\n btype=tinf_read_bits(2) ;read block type (2 bits)\n if btype=0 then tinf_inflate_uncompressed_block()\n if btype=1 then tinf_build_fixed_trees(), tinf_inflate_compressed_block()\n if btype=2 then tinf_decode_dynamic_trees(), tinf_inflate_compressed_block()\n if btype=3 then ERROR ;reserved\n until bfinal=1\n tinf_align_src_to_byte_boundary()\n ret\n tinf_align_src_to_byte_boundary()\n len=LittleEndian16bit[src+0] ;get len\n if LittleEndian16bit[src+2]<>(len XOR FFFFh) then ERROR ;verify inverse len\n src=src+4 ;skip len values\n for i=0 to len-1, [dst]=[src], dst=dst+1, src=src+1, next i ;copy block\n ret\n repeat\n sym1=tinf_decode_symbol(tinf_len_tree)\n if sym1<256\n [dst]=sym1, dst=dst+1\n if sym1>256\n len = tinf_read_bits(length_bits[sym1-257])+length_base[sym1-257]\n sym2 = tinf_decode_symbol(tinf_dist_tree)\n dist = tinf_read_bits(dist_bits[sym2])+dist_base[sym2]\n for i=0 to len-1, [dst]=[dst-dist], dst=dst+1, next i\n until sym1=256\n ret\n sum=0, cur=0, len=0\n repeat ;get more bits while code value is above sum\n cur=cur*2 + tinf_getbit()\n len=len+1\n sum=sum+tree.table[len]\n cur=cur-tree.table[len]\n until cur<0\n return tree.trans[sum+cur]\n val=0\n for i=0 to num-1, val=val+(tinf_getbit() shl i), next i\n return val\n bit=tag AND 01h, tag=tag/2\n if tag=00h then tag=[src], src=src+1, bit=tag AND 01h, tag=tag/2+80h\n return bit\n tag=01h ;empty/end-bit (discard any bits, align src to byte-boundary)\n ret\n tinf_build_bits_base(length_bits, length_base, 4, 3)\n length_bits[28]=0, length_base[28]=258\n tinf_build_bits_base(dist_bits, dist_base, 2, 1)\n ret\n for i=0 to 29\n bits[i]=min(0,i-delta)/delta\n base[i]=base_val\n base_val=base_val+(1 shl bits[i])\n ret\n for i=0 to 6, tinf_len_tree.table[i]=0, next i ;[0..6]=0 ;len tree...\n tinf_len_tree.table[7,8,9]=24,152,112 ;[7..9]=24,152,112\n for i=0 to 23, tinf_len_tree.trans[i+0] =i+256, next i ;[0..23] =256..279\n for i=0 to 143, tinf_len_tree.trans[i+24] =i+0, next i ;[24..167] =0..143\n for i=0 to 7, tinf_len_tree.trans[i+168]=i+280, next i ;[168..175]=280..287\n for i=0 to 111, tinf_len_tree.trans[i+176]=i+144, next i ;[176..287]=144..255\n for i=0 to 4, tinf_dist_tree.table[i]=0, next i ;[0..4]=0,0,0,0,0 ;\\dist\n tinf_dist_tree.table[5]=32 ;[5]=32 ; tree\n for i=0 to 31, tinf_dist_tree.trans[i]=i, next i ;[0..31]=0..31 ;/\n ret\n hlit = tinf_read_bits(5)+257 ;get 5 bits HLIT (257-286)\n hdist = tinf_read_bits(5)+1 ;get 5 bits HDIST (1-32)\n hclen = tinf_read_bits(4)+4 ;get 4 bits HCLEN (4-19)\n for i=0 to 18, lengths[i]=0, next i\n for i=0 to hclen-1 ;read lengths for code length alphabet\n lengths[clcidx[i]]=tinf_read_bits(3) ;get 3 bits code length (0-7)\n tinf_build_tree(code_tree, lengths, 19) ;build code length tree\n for num=0 to hlit+hdist-1 ;decode code lengths for dynamic trees\n sym = tinf_decode_symbol(code_tree)\n len=1, val=sym ;default (for sym=0..15)\n if sym=16 then len=tinf_read_bits(2)+3, val=lengths[num-1] ;3..6 previous\n if sym=17 then len=tinf_read_bits(3)+3, val=0 ;3..10 zeroes\n if sym=18 then len=tinf_read_bits(7)+11, val=0 ;11..138 zeroes\n for i=1 to len, lengths[num]=val, num=num+1, next i\n tinf_build_tree(tinf_len_tree, 0, hlit) ;\\build trees\n tinf_build_tree(tinf_dist_tree, 0+hlit, hdist) ;/\n ret\n for i=0 to 15, tree.table[i]=0, next i ;clear code length count table\n ;scan symbol lengths, and sum code length counts...\n for i=0 to num-1, x=lengths[i+first], tree.table[x]=tree.table[x]+1, next i\n tree.table[0]=0\n sum=0 ;compute offset table for distribution sort\n for i=0 to 15, offs[i]=sum, sum=sum+tree.table[i], next i\n for i=0 to num-1 ;create code to symbol xlat table (symbols sorted by code)\n x=lengths[i+first], if x<>0 then tree.trans[offs[x]]=i, offs[x]=offs[x]+1\n next i\n ret\n clcidx[0..18] = 16,17,18,0,8,7,9,6,10,5,11,4,12,3,13,2,14,1,15 ;constants\n typedef struct TINF_TREE:\n unsigned short table[16] ;table of code length counts\n unsigned short trans[288] ;code to symbol translation table\n TINF_TREE tinf_len_tree ;length/symbol tree\n TINF_TREE tinf_dist_tree ;distance tree\n TINF_TREE code_tree ;temporary tree (for generating the dynamic trees)\n unsigned char lengths[288+32] ;temporary 288+32 x 8bit ;\\for dynamic tree\n unsigned short offs[16] ;temporary 16 x 16bit ;/creation\n unsigned char length_bits[30]\n unsigned short length_base[30]\n unsigned char dist_bits[30]\n unsigned short dist_base[30]\n src_start=src, dst_start=dst ;memorize start addresses\n if (src[0]<>1fh or src[1]<>8Bh) then ERROR ;check id bytes\n if (src[2]<>08h) then ERROR ;check method is deflate\n flg=src[3] ;get flag byte\n if (flg AND 0E0h) then ERROR ;verify reserved bits\n src=src+10 ;skip base header\n if (flg AND 04h) then src=src+2+LittleEndian16bit[src] ;skip extra data\n if (flg AND 08h) then repeat, src=src+1, until [src-1]=00h ;skip file name\n if (flg AND 10h) then repeat, src=src+1, until [src-1]=00h ;skip file comment\n hcrc=(tinf_crc32(src_start, src-src_start) & 0000ffffh)) ;calc header crc\n if (flg AND 02h) then x=LittleEndian16bit[src], src=src+2 ;get header crc\n if (flg AND 02h) then if x<>hcrc then ERROR ;verify header\n tinf_uncompress(dst, destLen, src, src_start+sourceLen-src-8) ;----> inflate\n crc32=LittleEndian32bit[src], src=src+4 ;get crc32 of decompressed data\n dlen=LittleEndian32bit[src], src=src+4 ;get decompressed length\n if (dlen<>destLen) then ERROR ;verify dest len\n if (crc32<>tinf_crc32(dst_start,dlen)) then ERROR ;verify crc32\n ret\n src_start=src, dst_start=dst ;memorize start addresses\n hdr=BigEndian16bit[src], src=src+2 ;get header\n if (hdr MOD 31)<>0 then ERROR ;check header checksum (modulo)\n if (hdr AND 20h)>0 then ERROR ;check there is no preset dictionary\n if (hdr AND 0F00h)<>0800h then ERROR ;check method is deflate\n if (had AND 0F000h)>7000h then ERROR ;check window size is valid\n tinf_uncompress(dst, destLen, src, sourceLen-6) ;------> inflate\n chk=BigEndian32bit[src], src=src+4 ;get data checksum\n if src-src_start<>sourceLen then ERROR ;verify src len\n if dst-dst_start<>destLen then ERROR ;verify dst len\n if a32<>tinf_adler32(dst_start,destLen)) then ERROR ;verify data checksum\n ret\n s1=1, s2=0\n while (length>0)\n k=max(length,5552) ;max length for avoiding 32bit overflow before mod\n for i=0 to k-1, s1=s1+[src], s2=s2+s1, src=src+1, next i\n s1=s1 mod 65521, s2=s2 mod 65521, length=length-k\n return (s2*10000h+s1)\nLHA (formerly LHarc) is an old DOS compression tool with backwards compatibility for LArc. LHA appears to have been particulary popular in Japan, and in the Amiga scene. LHA archives are used by at least one PSX game:
PSX Championship Surfer (MagDemo43: HWX\\*.DAT) ;method lh5\nDefault archive filename extension is .LZH for LHarc/LHA (lh*-methods), or .LZS for LArc (lz*-methods). Archives can contain multiple files, and are usually terminated by a 00h-byte:
LHA Header+Data for 1st file\n LHA Header+Data for 2nd file\n End Marker (00h)\n 00h 1 Header Size (Method up to including Extended Area) (=16h+F+E)\n 01h 1 Header Checksum, sum of bytes at [02h+(0..15h+F+E)]\n 02h 5 Compression Method (eg. \"-lh0-\"=Uncompressed)\n 07h 4 Compressed Size\n 0Bh 4 Uncompressed Size\n 0Fh 2 Last modified time (in MS-DOS format)\n 11h 2 Last modified date (in MS-DOS format)\n 13h 1 MS-DOS File attribute (usually 20h)\n 14h 1 Header level (must be 00h for v0)\n 15h 1 Path\\Filename Length\n 16h (F) Path\\Filename (eg. \"PATH\\FILENAME.EXT\")\n '\\' may apper in the 2nd byte of Shift_JIS, processing\n of Shift_JIS is indispensable when you need full\n implementation of reading Pathname.\n 16h+F 2 CRC16 (with initial value 0000h) on uncompressed file\n 18h+F (E) Extended area (used by UNIX in v0)\n 18h+F+E .. Compressed data\n 00h 1 Header Size (Method up to including 1st Ext Size) (=19h+F+E)\n 01h 1 Base Header Checksum, sum of bytes at [02h+(0..18h+F+E)]\n 02h 5 Compression Method (eg. \"-lh0-\"=Uncompressed)\n 07h 4 Skip size (size of all Extended Headers plus Uncompressed Size)\n 0Bh 4 Uncompressed Size\n 0Fh 2 Last modified time (in MS-DOS format)\n 11h 2 Last modified date (in MS-DOS format)\n 13h 1 Reserved (must be 20h) (but is 02h on Amiga)\n 14h 1 Header level (must be 01h for v1)\n 15h 1 Length of Filename (or 00h when name is in Extended Header)\n 16h (F) Filename (eg. \"FILENAME.EXT; path (if any) is in Extended Header)\n 16h+F 2 CRC16 (with initial value 0000h) on uncompressed file\n 18h+F 1 Compression Tool OS ID (eg. \"M\"=MSDOS)\n 19h+F (E) Extended area (unused in v1, use Ext Headers instead)\n 19h+F+E 2 Size of 1st Extended Header (0000h=None)\n 1Bh+F+E .. Extended Header(s) (optional stuff)\n ... .. Compressed data\n 00h 2 Header Size (whole Header including all Extended Headers)\n 02h 5 Compression Method (eg. \"-lh0-\"=Uncompressed)\n 07h 4 Compressed Size\n 0Bh 4 Uncompressed Size\n 0Fh 4 Last modified date and time (seconds since 1st Jan 1970 UTC)\n 13h 1 Reserved (must be 20h) (but is 02h on Amiga)\n 14h 1 Header level (must be 02h for v2)\n 15h 2 CRC16 (with initial value 0000h) on uncompressed file\n 17h 1 Compression Tool OS ID (eg. \"M\"=MSDOS)\n 18h 2 Size of first Extended Header (0000h=None)\n 1Ah .. Extended Header(s) (filename and optional stuff)\n ... 0/1 Nullbyte (End-Marker conflict: change Headersize xx00h to xx01h)\n ... .. Compressed data\nKinda non-standard (supported only in late japanese LHA beta versions): Allows Header and Ext.Headers to exceed 64Kbyte, which is rather useless.
00h 2 Word size for 32bit Header entries (always 4=32bit)\n 02h 5 Compression Method (eg. \"-lh0-\"=Uncompressed)\n 07h 4 Compressed Size\n 0Bh 4 Uncompressed Size\n 0Fh 4 Last modified date and time (seconds since 1st Jan 1970 UTC)\n 13h 1 Reserved (must be 20h)\n 14h 1 Header level (must be 03h for v3)\n 15h 2 CRC16 (with initial value 0000h) on uncompressed file\n 17h 1 Compression Tool OS ID (eg. \"M\"=MSDOS)\n 18h 4 Header Size (whole Header including all Extended Headers)\n 1Ch 4 Size of first Extended Header (00000000h=None)\n 20h .. Extended Header(s) (filename and optional stuff)\n ... .. Compressed data\n Method Len Window\n -lz4- - - - LArc Uncompressed File\n -lh0- - - - LHA Uncompressed File\n -lhd- - - - LHA Uncompressed Directory name entry\n -lzs- 2..17 2Kbyte LArc LZSS-Compressed (rare, very-very old) ;-15bit\n -lz5- 3..17 4Kbyte LArc LZSS-Compressed (LArc srandard) ;-16bit\n -lh1- 3..60 4Kbyte LHA LZHUF-Compressed (old LHA standard)\n -lh2- 3..256 8Kbyte LHA Obscure test (used in self-extractor)\n -lh3- 3..256 8Kbyte LHA Obscure test (experimental)\n -lh4- 3..256 4Kbyte LHA AR002-Compressed (rare, for small RAM) ;\\4bit\n -lh5- 3..256 8Kbyte LHA AR002-Compressed (new LHA standard) ;/\n -lh6- 3..256 32Kbyte LHA AR002-Compressed (rare) ;\\\n -lh7- 3..256 64Kbyte LHA AR002-Compressed (rare) ; 5bit\n -lh8- 3..256 64Kbyte LHA AR002-Compressed (accidently same as lh7) ;\n -lh9- 3..256 128Kbyte LHA AR002-Compressed (unimplemented proposal) ;\n -lha- 3..256 256Kbyte LHA AR002-Compressed (unimplemented proposal) ;\n -lhb- 3..256 512Kbyte LHA AR002-Compressed (unimplemented proposal) ;\n -lhc- 3..256 1Mbyte LHA AR002-Compressed (unimplemented proposal) ;\n -lhe- 3..256 2Mbyte LHA AR002-Compressed (unimplemented proposal) ;\n -lhx- 3..256 512Kbyte LHA AR002-Compressed (rare) ;/\n 00h 1 Extension Type (00h..FFh, eg. 01h=Filename)\n 01h .. Extension Data\n ... 2/4 Size of next Extended Header (0=None) (v1/v2=16bit, v3=32bit)\n 00h CRC16 on whole Header with InitialValue=0000h and InitialCrcEntry=0000h\n 01h Filename\n 02h Directory name (with FFh instead of \"\\\", and usually with trailing FFh)\n 3Fh Comment (unspecified format/purpose)\n 40h MS-DOS File attribute of MS-DOS format\n 41h Windows FILETIME for last access, creation, and modification\n 42h Filesize (uncompressed and compressed size, when exceeding 32bit)\n 50h Unix Permission\n 51h Unix User ID and Group ID\n 52h Unix Group name\n 53h Unix User name (owner)\n 54h Unix Last modified time in time_t format\n 7Dh Capsule offs/size (if the OS adds extra header/footer to the filebody)\n 7Eh OS/2 Extended attribute\n 7Fh Level 3 Attribute in Unix form and MS-DOS form\n FFh Level 3 Attribute in Unix form\nThe site below has useful links with info about headers (see LHA Notes), source code, and test archives: http://fileformats.archiveteam.org/wiki/LHA
"},{"location":"cdromfileformats/#cdrom-file-compression-upx","title":"CDROM File Compression UPX","text":""},{"location":"cdromfileformats/#upx-compression-used-in-amidogs-gte-test","title":"UPX Compression (used in AmiDog's GTE test)","text":"UPX is a tool for creating self-decompressing executables. It's most commonly used for DOS/Windows EXE files, but it does also support consoles like PSX. The PSX support was added in UPX version 1.90 beta (11 Nov 2002).
000h 88h Standard PS-X EXE header\n 088h 20h Unknown\n 0A8h 4 ASCII ID \"UPX!\"\n 0ACh 1Eh Unknown\n 0CAh 9Ah ASCII \"$info: This file is ...\"\n 164h 69Ch Zerofilled\n 800h .. Leading zeropadding (to make below end on 800h-byte boundary)\n ... .. Decompression stub\n ... .. Compressed data (ending on 800h-byte boundary)\nLZMA is combining LZ+Huffman+Probabilities. The LZ+Huffman bitstream is rather simple (using hardcoded huffman trees), the high compression ratio is reached by predicting probabilities for the bitstream values (that is, the final compressed data is smaller than the bitstream).
"},{"location":"cdromfileformats/#lzma-bitstreams","title":"LZMA Bitstreams","text":" 000h 1 Ignored byte (usually 00h, unknown purpose)\n 001h .. Bitstream with actual compression codes\n ... .. EOS end code (end of stream) (optional)\n ... .. Ignored byte (present in case of Normalization after last code)\n ... .. Padding to byte-boundary\n Three decompression parameters: lc, lp, pb\n Decompressed size (required if the bitstream has no EOS end code)\n Dictionary size (don't care when decompressing the whole file to memory)\n Presence/Absence of EOS end code\n 000h 1 Parameters (((pb*5)+lp)*9)+lc (usually 5Dh) ;\\\n 001h 4 Dictionary Size in bytes (usually 10000h) ; Header\n 005h 8 Decompressed Size in bytes (or -1=Unknown) ;/\n 00Dh 1 LZMA ignored 1st byte of bitstream (00h) ;\\LZMA\n 00Eh .. LZMA bitstream (with optional EOS end code) ;/\nLZIP files can contain one or more \"LZIP Members\" plus optional extra data:
000h .. LZIP Member(s)\n ... .. Optional extra data (if any) (eg. zeropadding or some SHA checksum)\n 000h 5 ID and version (\"LZIP\",01h) ;\\LZIP Header\n 005h 1 Dictionary size (5bit+3bit code, see below) ;/\n 006h .. LZMA bitstream (with lc=3, lp=0, pb=2) (with EOS end code)\n ... 4 CRC32 on uncompressed data ;\\\n ... 8 Size of uncompressed data ; LZIP Footer\n ... 8 Size of compressed data (including header+footer) ;/\n temp = 1 SHL (hdr[005h] AND 1Fh)\n dict_size = temp - (temp/10h)*(hdr[005h]/20h)\nThe CHD format has its own headers and supports several compression methods including LZMA. Leaving apart the CHD specific headers, the raw LZMA bitstreams are stored as so:
000h .. LZMA bitstream (with lc=3, lp=0, pb=2) (without EOS end code)\nThis is a slightly overcomplicated format with LZMA2 compression and optional filters. CDROM File Compression XZ
"},{"location":"cdromfileformats/#7z-files-7-zip-archives","title":".7z files (7-Zip archives)","text":" 000h 6 ID (\"7z\",BCh,AFh,27h,1Ch)\n ... .. ..\nLZMA2 is a container format with LZMA chunks. The LZMA function is slightly customized: It can optionally skip some LZMA initialization steps (and thereby re-use the dictionary/state from previous chunks). The chunks are:
ChunkID=00h - Last chunk:\n 000h 1 Chunk ID (00h=End)\n ChunkID=01h..02h - Uncompressed chunks:\n 000h 1 Chunk ID (01h=Uncompressed+ResetDictionary, 02h=Uncompressed)\n 001h 2 Uncompressed Data Size-1 (big-endian)\n 003h .. Uncompressed Data (to be copied to destination and dictionary)\n Note: The uncompressed data is stored in LZMA dictionary, and\n the last uncompressed byte is updating the LZMA prevbyte.\n ChunkID=03h..7Fh - Invalid chunks:\n 000h 1 Chunk ID (03h..7Fh=Invalid)\n ChunkID=80h..FFh - LZMA-compressed chunks:\n 000h 1 Chunk ID (80h/A0h/C0h/E0h + Upper5bit(UncompressedSize-1))\n 001h 2 LSBs(UncompressedSize-1) (big-endian)\n 003h 2 CompressedSize-1 (big-endian)\n 005h (1) Parameters (((pb*5)+lp)*9)+lc (only present if ChunkID=C0h..FFh)\n ... .. LZMA bitstream (without EOS end code)\n ChunkID dict/prev lc/lp/pb state dist[0-3] probabilities code/range\n 01h reset - - - - -\n 02h - - - - - -\n 80h+n - - - - - reset\n A0h+n - - reset reset reset reset\n C0h+n - reset reset reset reset reset\n E0h+nn reset reset reset reset reset reset\n (Note: Those resets occur before processing the chunk data)\n Dictionary Size byte (00h..28h = 4K,6K,8K,12K,16K,24K,..,2G,3G,4G)\n Which can be decoded as so:\n if (param AND 1)=0 then dict_size=1000h shl (param/2)\n if (param AND 1)=1 then dict_size=1800h shl (param/2)\n if param=28h then dict_size=FFFFFFFFh ;4GB-1\n if param>28h then error\n In .xz files, that byte is stored alongsides with the Filter ID.\nCompact LZMA decompression ASM code can be found here:
https://github.com/ilyakurdyukov/micro-lzmadec
Above code is for self-decompressing executables (for plain LZMA, ignore the stuff about EXE/ELF headers). The two \"static\" versions are size-optimized (they contain weird and poorly commented programming tricks, and do require additional initialization code from \"test_static.c\"). For normal purposes, it's probably better to port the 64bit fast version to 32bit (instead of dealing with the trickery in the 32bit static version).
"},{"location":"cdromfileformats/#cdrom-file-compression-xz","title":"CDROM File Compression XZ","text":""},{"location":"cdromfileformats/#overall-structure-of-xz-file","title":"Overall Structure of .xz File","text":" 000h .. Stream(s)\n 000h 6 Header ID (FDh,\"7zXZ\",00h) (FDh,37h,7Ah,58h,5Ah,00h) ;\\\n 006h 2 Checksum Type (0000h, 0100h, 0400h or 0A00h) ; Header\n 008h 4 Header CRC32 on above 2 bytes ;/\n 00Ch .. Compressed Block(s) ;-Block(s)\n ... .. Index List ;-Index\n ... 4 Footer CRC32 on below 6 bytes ;\\\n ... 4 Index List Size/4-1 ; Footer\n ... 2 Checksum Type (must be same as in Header) ;\n ... 2 Footer ID (\"YZ\") (59h,5Ah) ;/\n ... .. Optional Zeropadding (multiple of 4 bytes) ;-Padding\n Checksum Type (for Block checksums):\n 0000h=None\n 0100h=CRC32 (little-endian)\n 0400h=CRC64 (little-endian)\n 0A00h=SHA256 (big-endian)\n Other=Reserved\n 000h 1 Index Indicator (00h) (as opposed to 01h..FFh in Block Headers)\n 001h VL Number of Records (must be same as number of Blocks in Stream)\n ... .. Index Record(s)\n ... .. Zeropadding to 4-byte boundary\n ... 4 CRC32 on above bytes\n Index Record:\n 000h VL Unpadded Block Size (BlockHeader + CompressedData + 0 + Checksum)\n ... VL Uncompressed Block Size\n 000h 1 Block Header Size/4-1 (01h..FFh = 8..400h bytes) ;\\\n 001h 1 Block Flags ;\n 002h (VL) Compressed Size ;present if Flags.bit6 = 1 ; Header\n ... (VL) Uncompressed Size ;present if Flags.bit7 = 1 ;\n ... .. Filter Info 0 (LAST filter when DECOMPRESSING) ;\n ... (..) Filter Info 1 ;present if Flags.bit0-1 = 1,2,3 ;\n ... (..) Filter Info 2 ;present if Flags.bit0-1 = 2,3 ;\n ... (..) Filter Info 3 ;present if Flags.bit0-1 = 3 ;\n ... .. Zeropadding to 4-byte boundary ;\n ... (..) Optional Zeropadding (multiple of 4 bytes) ;\n ... 4 CRC32 on above bytes ;/\n ... .. Compressed Data ;-Data\n ... .. Zeropadding to 4-byte boundary ;-Pad\n ... (..) Checksum on uncompressed Data (None/CRC32/CRC64/SHA256) ;-Check\n Block Flags:\n 0-1 Number of filters-1 (0..3 = 1..4 filters)\n 2-5 Reserved (0)\n 6 Compressed Size field is present (0=No, 1=Present)\n 7 Uncompressed Size field is present (0=No, 1=Present)\n Filter Info:\n 000h VL Filter ID\n ... VL Size of Filter Properties\n ... .. Filter Properties\n Filter IDs:\n 03h Delta Filter (with 1 byte param)\n 04h..09h Executable Filters (with 0 or 4 byte param)\n 21h LZMA2 Compression (with 1 byte param)\n 300h..4FFh Reserved to ease .7z compatibility\n 20000h..7FFFFh Reserved to ease .7z compatibility\n 2000000h..7FFFFFFh Reserved to ease .7z compatibility\n xxxxxxxxxxxxxxxxh Custom Registered IDs (obtained from Lasse Collin)\n 3Frrrrrrrrrriiiih Custom Random IDs (40bit random+16bit filterno)\n 4000000000000000h and up Reserved for internal use (don't use in xz files)\nThis \"filter\" is the actual compression method (XZ supports only one method). It can be combined with BCJ/Delta filters (whereas, LZMA2 must be always used as LAST compression filter, aka FIRST decompression filter).
The filter parameter is 1 byte tall:\n Dictionary Size byte (00h..28h = 4K,6K,8K,12K,16K,24K,..,2G,3G,4G)\n The compressed data contains:\n LZMA2 chunks (with LZMA-compressed data and/or uncompressed data)\nThe filter parameter is 1 byte tall:
Distance-1 (00h..FFh = distance 1..100h)\n<B> unfilter_delta(buf,len,param_byte):</B>\n dist=byte(param)+1, i=dist ;init dist and skip first some unfiltered bytes\n while i<len, byte(buf[i]) = buf[i]+buf[i-dist], i=i+1\nThese filters can replace relative jump addresses by absolute values.
ID Parameters Alignment Description\n 04h 0 or 4 bytes 1 byte 80x86 filter (32bit or 64bit)\n 05h 0 or 4 bytes 4 bytes PowerPC filter (big endian)\n 06h 0 or 4 bytes 16 bytes IA64 filter\n 07h 0 or 4 bytes 4 bytes ARM filter (little endian)\n 08h 0 or 4 bytes 2 bytes ARM Thumb filter (little endian)\n 09h 0 or 4 bytes 4 bytes SPARC filter\n 0Ah,0Bh Inofficial hacks/proposals for ARM64?\n if param_size=0 then offset=00000000h\n if param_size=4 then offset=LittleEndian32bit(param)\n Nonzero offsets are intended for executables with multiple sections and\n cross-section jumps. The offset shall/must match the filter's alignment.\n<B> unfilter_bcj_x86(buf,len,offset):</B>\n i=0, len=len-4, offset=offset+4\n while i<len\n x=byte[buf+i], i=i+1\n if (x AND FEh)=E8h ;Opcode=E8h or E9h\n x=LittleEndian32bit[buf+i]\n if ((x+01000000h) AND FE000000h)=0 ;MSB=00h or FFh\n LittleEndian32bit[buf+i]=SignExpandLower25bit(x-i-offset)\n i=i+4\n<B> unfilter_bcj_arm(buf,len,offset):</B>\n i=0, len=len/4, offset=(offset+8)/4\n while i<len\n x=LittleEndian32bit[buf+i*4]\n if (x AND FF000000h)=EB000000h\n LittleEndian32bit[buf+i*4]=((x-i-offset) and 00FFFFFFh)+EB000000h\n i=i+1\n<B> unfilter_bcj_armthumb(buf,len,offset):</B>\n i=0, len=len/2-1, offset=(offset+4)/2\n while i<len\n x=LittleEndian32bit[buf+i*2]\n if (x AND F800F800h)=F800F000h\n msw=LittleEndian16bit[buf+i*2+0] AND 7FFh\n lsw=LittleEndian16bit[buf+i*2+2] AND 7FFh\n x=msw*800h+lsw-i-offset\n LittleEndian16bit[buf+i*2+0]=F000h+(7FFh and (x/800h))\n LittleEndian16bit[buf+i*2+2]=F800h+(7FFh and (x/1))\n i=i+1\n<B> unfilter_bcj_sparc(buf,len,offset):</B>\n i=0, len=len/4, offset=offset/4\n while i<len\n x=BigEndian32bit[buf+i*4]\n if (x AND FFC00000h)=40000000h or (x AND FFC00000h)=7FC00000h\n x=SignExpandLower23bit(x-i-offset)\n BigEndian32bit[buf+i*4]=(x AND 3FFFFFFFh)+40000000h\n i=i+1\n<B> unfilter_bcj_powerpc(buf,len,offset):</B>\n i=0, len=len/4, offset=offset/4\n while i<len\n x=BigEndian32bit[buf+i*4]\n if (x AND FC000003h)=48000001h\n BigEndian32bit[buf+i*4]=(((x/4-i-offset) AND 00FFFFFFh)*4)+48000001h\n i=i+1\n<B> unfilter_bcj_ia64(buf,len,offset):</B>\n i=0, len=len/10h, offset=offset/10h\n xlat[0..1Fh]=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,4,6,6,0,0,7,7,4,4,0,0,4,4,0,0\n while i<len\n flags=xlat[byte[buf] and 1Fh] ;shared 5bit for three 41bit opcodes\n for slot=0 to 2\n if flags and (1 shl slot) ;process three 41bit opcodes\n bitbase=slot*41+5\n hi=byte[buf+(bitbase+37)/8] shr ((bitbase+37) and 7) and 0Fh\n lo=LittleEndian16bit[buf+(bitbase+9)/8] shr ((bitbase+9) and 7) and 07h\n if hi=5 and lo=0\n mid=LittleEndian32bit[buf+(bitbase+13)/8]\n x=mid shr ((bitbase+13) and 7)\n x=x and 8FFFFFh, if (x and 800000h) then x=x-700000h\n x=x-i-offset\n x=x and 1FFFFFh, if (x and 100000h) then x=x+700000h\n mid=mid AND NOT (8FFFFFh shl ((bitbase+13) and 7)) ;strip old\n mid=mid OR x shl ((bitbase+13) and 7)) ;place new\n LittleEndian32bit[buf+(bitbase+13)/8]=mid ;apply\n i=i+1, buf=buf+10h\nCRC32 uses 32bit (with polynomial=EDB88320h). CRC64 does basically use the same function (with 64bit values and polynomial=C96C5795D7870F42h).
"},{"location":"cdromfileformats/#endianness-and-variable-length-vl-integers","title":"Endianness and Variable Length (VL) Integers","text":"Little-endian is used for 16bit/32bit/64bit values (Flags, Sizes, CRCs). Big-endian is used for 256bit SHA256 and for values within LZMA2 chunks. Variable length integers (marked VL in above tables) are used for Sizes and IDs, these values may contain max 63bit, stored in 1-9 bytes:
decode_variable_len_integer:\n i=0, num=0\n @@lop:\n x=[src], src=src+1, num=num+((x and 7Fh) shl i), i=i+7\n if x AND 80h then goto @@lop\n return num\nXZ Utils for Windows is claimed to work on Win98 (that is, it will throw an error about missing MSVCRT.DLL:___mb_cur_max_func). XZ Utils for DOS does work on Win98. Official XZ file format specs for can be found at:
https://tukaani.org/xz/format.html
The BCJ filters aren't documented in XZ specs, but are defined in XZ source code, see src\\liblzma\\simple\\*.c). There's also this mail thread about semi-official ARM64 filters:
https://www.mail-archive.com/xz-devel@tukaani.org/msg00537.html
"},{"location":"cdromfileformats/#cdrom-file-compression-flac-audio","title":"CDROM File Compression FLAC audio","text":"FLAC is a lossless audio compression format.
"},{"location":"cdromfileformats/#flac-file-format","title":"FLAC file format","text":" 000h 4 FLAC ID (\"fLaC\")\n 004h .. Metadata block with STREAMINFO\n ... .. Metadata block(s) with further info (optional)\n ... .. FLAC Frame(s)\n 1bit Last Metadata block flag (1=Last, 0=More blocks follow)\n 7bit Block Type (see below)\n 24bit Size of following metadata in bytes (N)\n N*8bit Metadata (depending on Type)\n 00h = STREAMINFO\n 01h = PADDING\n 02h = APPLICATION\n 03h = SEEKTABLE\n 04h = VORBIS_COMMENT\n 05h = CUESHEET\n 06h = PICTURE\n .. = Reserved\n 7Fh = Invalid (to avoid confusion with a frame sync code)\n 16bit Minimum Block size in samples (10h..FFFFh) ;\\min=max implies\n 16bit Maximum Block size in samples (10h..FFFFh) ;/fixed blocksize\n 24bit Minimum Frame size in bytes (or 0=Unknown)\n 24bit Maximum Frame size in bytes (or 0=Unknown)\n 20bit Sample rate in Hertz (01h..9FFF6h = 1..655350 Hz)\n 3bit Number of channels-1 (00h..07h = 1..8 channels)\n 5bit Bits per sample-1 (03h..1Fh = 4..32 bits) (max 24bit implemented)\n 36bit Total number of samples per channel (or 0=Unknown)\n 128bit MD5 on unencoded audio data (...in which format? endian/interleave?)\nThe FLAC file format is documented here:
https://xiph.org/flac/format.html
Source code for a compact FLAC decoder can be found here:
https://www.nayuki.io/page/simple-flac-implementation
"},{"location":"cdromfileformats/#cdrom-file-compression-arj","title":"CDROM File Compression ARJ","text":""},{"location":"cdromfileformats/#arj-archives-contain-several-chunks","title":"ARJ archives contain several chunks","text":" Main header chunk\n Local file chunk(s)\n Chapter chunk(s), backup related, exist only in newer archives\n End Marker\nThis is stored at the begin of the archive. The format is same as for local file header (but with file-related entries set to zero, or to global security settings).
000h 2 ARJ ID (EA60h, aka 60000 decimal)\n 002h 2 Header size (from 004h up to including Filename+Comment) (max 2600)\n 004h 1 Header size (from 004h up to including Extra Data) (1Eh+extra)\n 005h 1 Archiver version number (01h..0xh)\n 006h 1 Minimum archiver version to extract (usually 01h)\n 007h 1 Host OS\n 008h 1 ARJ Flags (bit0-7, see below)\n 009h 1 Security version (2 = current)\n 00Ah 1 File Type (must be 2=ARJ Comment in main header)\n 00Bh 1 Reserved/Garbage (LSB of Archive creation Date/Time, same as [00Ch])\n 00Ch 4 Date/Time when archive was created\n 010h 4 Date/Time when archive was last modified\n 014h 4 Zero (or Secured Archive size, excluding Security and Protection)\n 018h 4 Zero (or Security envelope file position) (after End Marker)\n 01Ch 2 Zero (or Filespec position in filename) (0) (what is that??)\n 01Eh 2 Zero (or Security envelope size in bytes) (78h, if any)\n 020h 1 Zero (or >2.50?: Encryption version, 0-1=Old, 2=New, 4=40bit GOST)\n 021h 1 Zero (or >2.50?: Last chapter (eg. 4 when having chapter 1..4)\n 022h (1) Extra data: ARJ Protection factor ;\\extra,\n 023h (1) Extra data: ARJ Flags (bit0=ALTVOLNAME, bit1=ReservedBit) ; if any\n 024h (2) Extra data: Spare bytes ;/\n ... .. Filename, max 500 bytes (\"FILENAME.ARJ\",00h)\n ... .. Comment, max 2048 bytes (\"ASCII Comment\",00h)\n ... 4 CRC32 on Header (from 004h up to including Comment)\n ... 2 Size of 1st extended header (usually 0=none)\n ... (0) Extended Header(s?) (usually none such)\nThis occurs at the begin of each file in the archive.
000h 2 ARJ ID (EA60h, aka 60000 decimal)\n 002h 2 Header size (from 004h up to including Filename+Comment) (max 2600)\n 004h 1 Header size (from 004h up to including Extra Data) (1Eh+extra)\n 005h 1 Archiver version number\n 006h 1 Minimum archiver version to extract (usually 01h)\n 007h 1 Host OS\n 008h 1 ARJ Flags (bit0,2-5)\n 009h 1 Method\n 00Ah 1 File Type (0=Binary, 1=Text, 3=Directory Name, 4=Volume Name)\n 00Bh 1 Reserved/Garbage (LSB of Archive update Date/Time?)\n 00Ch 4 Date/Time modified\n 010h 4 Filesize, compressed (max 7FFFFFFFh)\n 014h 4 Filesize, uncompressed\n 018h 4 CRC32 on uncompressed file data\n 01Ch 2 Zero (or Filespec position in filename) (what is that??)\n 01Eh 2 File access mode (aka MSDOS file attribute) (20h=Normal)\n 020h 1 Zero (or >2.50?: first chapter of file's lifespan)\n 021h 1 Zero (or >2.50?: last chapter of file's lifespan)\n 022h (4) Extra data: Extended file position (maybe for split?) ;\\extra,\n 026h (4) Extra data: Date/Time accessed ;\\ARJ ; 0,4 or 10h\n 03Ah (4) Extra data: Date/Time created ; 2.62 ; bytes\n 03Eh (4) Extra data: Original file size even for volumes ;/ ;/\n ... .. Filename, max 500 bytes (\"PATH/FILENAME.EXT\",00h)\n ... .. Comment, max 2048 bytes (\"ASCII Comment\",00h)\n ... 4 CRC32 on Header (from 004h up to including Comment)\n ... 2 Size of 1st extended header (usually 0=none)\n ... (0) Extended Header(s?) (usually none such)\n ... .. Compressed file data\nThis is rarely used and supported only in newer ARJ versions. The format is same as for local file header (but with file-related entries being nonsense in TECHNOTE; in practice, those nonsense values seem to be zero).
000h 2 ARJ ID (EA60h, aka 60000 decimal)\n 002h 2 Header size (from 004h up to including Filename+Comment) (max 2600)\n 004h 1 Header size (from 004h up to including Extra Data) (1Eh+extra)\n 005h 1 Archiver version number (eg. 0Ah=2.75a)\n 006h 1 Minimum archiver version to extract (usually 01h)\n 007h 1 Host OS\n 008h 1 ARJ Flags (usually 00h)\n 009h 1 Method (usually 01h, although chapters have no data) what file???\n 00Ah 1 File Type (must be 5=ARJ Chapter)\n 00Bh 1 Reserved/Garbage (LSB of Chapter Date/Time, same as [00Ch])\n 00Ch 4 Date/Time stamp created\n 010h 4 Zero (or reportedly, ?) what question?\n 014h 4 Zero (or reportedly, ?) what question?\n 018h 4 Zero (or reportedly, original file's CRC32) what file???\n 01Ch 2 Zero (or reportedly, entryname position in filename) what file???\n 01Eh 2 Zero (or reportedly, file access mode) what file???\n 020h 1 Chapter range start (01h=First chapter?) what range???\n 021h 1 Chapter range end (contains same value as above) what range???\n 022h (4) Extra data: Extended file position (usually none such)what extra???\n ... .. Filename (\"<<<001>>>\",00h for First chapter)\n ... .. Comment (\"\",00h)\n ... 4 CRC32 on Header (from 004h up to including Comment)\n ... 2 Size of 1st extended header (usually 0=none)\n ... (0) Extended Header(s?) (usually none such)\nThis is stored at the end of the archive.
000h 2 ARJ ID (EA60h, aka 60000 decimal)\n 002h 2 Header size (0=End)\n 0 = stored (uncompressed)\n 1 = compressed most (default) (Window=6800h=26Kbyte, Chars=255, Tree=31744)\n 2 = compressed medium (Window=5000h=20Kbyte, Chars=72, Tree=30720)\n 3 = compressed less (Window=2000h=8Kbyte, Chars=32, Tree=30720)\n 4 = compressed least/fastest (Window=6800h? or 8000h?)\n 8 = no data, no CRC ;\\unknown if/where that is used (maybe only used\n 9 = no data ;/internally, and never stored in actual files?)\n 0 = binary file (default)\n 1 = text file (with converted line breaks, via -t1 switch)\n 2 = ARJ comment header (aka ARJ main file header)\n 3 = directory name\n 4 = volume label (aka disc name)\n 5 = ARJ chapter label (aka begin of newer backup sections)\n 0 GARBLED\n 1 OLD_SECURED has old signature (with signature in Main Header?)\n 1 ANSIPAGE ANSI codepage used by ARJ32 (for what? for \"FILENAME.ARJ\"?)\n 2 VOLUME presence of succeeding volume\n 3 ARJPROT\n 4 PATHSYM archive name translated (\"\\\" changed to \"/\")\n 5 BACKUP obsolete\n 6 SECURED has new signature (in security envelope?)\n 7 ALTNAME dual-name archive\n 0 GARBLED passworded file\n 1 NOT USED\n 2 VOLUME continued file to next volume (file is split)\n 3 EXTFILE file starting position field (for split files)\n 4 PATHSYM filename translated (\"\\\" changed to \"/\")\n 5 BACKUP_FLAG obsolete\n 0 GARBLED ;\\\n 1 RESERVED ;\n 2 VOLUME ; what does that mean in Chapters???\n 3 EXTFILE ;\n 4 PATHSYM ;/\n 5 BACKUP obsolete < 2.50a ;-how can obsolete exist in Chapters???\n 6 RESERVED\n 0=MSDOS, 1=PRIMOS, 2=UNIX, 3=AMIGA, 4=MACDOS (aka MAC-OS)\n 5=OS/2, 6=APPLE GS, 7=ATARI ST, 8=NEXT\n 9=VAX VMS, 10=WIN95, 11=WIN32 (aka WinNT or so?)\nThese methods are same as LHA's \"-lh6-\" compression method (albeit the three ARJ methods are allocating slighly less memory for the sliding window).
"},{"location":"cdromfileformats/#arj-method-4-custom-fastest-compression","title":"ARJ Method 4 (custom fastest compression)","text":" @@decompress_lop:\n if dst>=dst_end then goto @@decompress_done\n width=count_ones(max=7), len = get_bits(width) + (1 shl width)+1\n if len=2 then\n [dst]=get_bits(8), dst=dst+1\n else ;len>=3\n width=count_ones(max=4)+9, disp = get_bits(width) + (1 shl width)-1FFh\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n goto @@decompress_lop\n @@decompress_done:\n ret\n ;---\n count_ones(max):\n num=0\n @@lop:\n if get_bits(1)=1 then\n num=num+1, if num<max then goto @@lop\n return num\nBACKUPs seem to keep old files (instead overwrting them by newer files) CHAPTERs seems to be a new backup type (instead of [008h].Bit5=Backup flag). COMMENTS can be text... with ANSI.SYS style ANSI escape codes? DATE/TIME stamps seem to be MSDOS format (16bit date plus 16bit time) EXTENDED headers seem to be unused, somewhat inspired on LHA format but with CRC32 instead CRC16 (unknown if the \"1st extended header\" can be followed by 2nd, 3rd, and further extended headers in LHA fashion) (bug: older ARJ versions are reportedly treating the extended CRC32 as 16bit value). GARBLED seems to refer to encrypted password protected archives. PROTECTED seems to mean Error Correction added in newer ARJ archives. SECURED seems to mean archive with signature from registered manufacturers. SPLIT aka VOLUMEs means large ARJ's stored in fragments on multiple disks. TEXT (aka [00Ah]=1 aka -t1 switch aka \"C Text\" aka \"7-bit text\") converts linebreaks from CR,LF to LF to save memory (the uncompressed size and uncompressed CRC32 entries refer to that converted LF format, not to the original CR,LF format; the official name \"7-bit text\" is nonsense: All characters are stored as 8bit values, not 7bit values). TIMEBOMB causes newer ARJ versions to refuse to work (and request the user to check for non-existing newer updates) (eg. ARJ 2.86 is no longer working, ARJ 2.75a does still work without timebomb).
"},{"location":"cdromfileformats/#see-also_8","title":"See also","text":"The various ARJ versions include .TXT or .DOC files (notably, ARJ.TXT is user manual, TECHNOTE.TXT contains hints on the ARJ file format). There's also an open source version.
"},{"location":"cdromfileformats/#cdrom-file-compression-arc","title":"CDROM File Compression ARC","text":""},{"location":"cdromfileformats/#arc-archives","title":"ARC Archives","text":"ARC is an old DOS and CP/M compression tool from 1985-1990. ARC files contain chunks in following format:
000h 1 Fixed ID (1Ah)\n 001h 1 Compression Method (00h..1Fh)\n 002h 13 Filename (\"FILENAME.EXT\",00h) (garbage-padded if shorter)\n 00Fh 4 Filesize, compressed\n 013h 4 File Timestamp in MSDOS format\n 017h 2 CRC16 with initial value 0000h on uncompressed/decrypted file\n 019h (4) Filesize, uncompressed ;<-- not present for Method=1\n ... .. Compressed file data (size as stored in [00Fh])\n Method 00h and 1Fh --> Chunksize=02h (archive/subdir end markers)\n Method 01h --> Chunksize=19h+[0Fh] (old uncompressed ARC archives)\n Others Methods --> Chunksize=1Dh+[0Fh] (normal case)\n 00h End-of-archive marker (1Ah,00h)\n 01h ARC v? Uncompressed (with short 19h-byte header)\n 02h ARC v? Uncompressed (with normal 1Dh-byte header)\n 03h ARC v? Packed (RLE90) Used for small files\n 04h ARC v? Squeezed (RLE90+Huffman) Based on CP/M Squeeze\n 05h ARC v4.00 Crunched (OldRandomizedLZW) Derived from LZWCOM\n 06h ARC v4.10 Crunched (RLE90+OldRandomizedLZW) Alike CP/M Crunch v1.x\n 07h ARC vBeta? Crunched (RLE90+NewRandomizedLZW) Leaked beta version?\n 08h ARC v5.00 Crunched (RLE90+ClearGap12bitLZW) Most common ARC method\n 09h Inofficial Squashed (ClearGap13bitLZW) Used by PKARC/PKPAK\n 0Ah ARC v7.xx Trimmed (RLE90+LZHUF) Based on LHArc lh1\n 0Ah Inofficial Crushed (RLE90+LZW/LZMW?) PAK\n 0Bh Inofficial Distilled (LZ77+Huffman) PAK v2.0\n 14h-1Dh ARC v6.0 Used/reserved for Information items:\n 14h Archive info\n 15h Extended File info (maybe a prefix(?) for actual file entries?)\n 16h OS-specific info\n 1Eh-27h ARC v6.0 Used/reserved for Control items:\n 1Eh ARC v6.00 Subdir (nested ARC-like format, created by the \"z\" option)\n 1Fh ARC v6.00 End-of-subdir marker (1Ah,1Fh)\n 48h Not used in ARC ;\\Hyper archives start with 1Ah,48h or 1Ah,53h\n 53h Not used in ARC ;/(an unrelated format that also starts with 1Ah)\n 80h-xxh Not used in ARC ;-Spark archives (ARC-like, with extended headers)\n 000h 2 Item size (LEN)\n 002h 1 Item Subtype\n 003h .. Item Data (LEN-3 bytes)\n Method=14h, Subtype=0 Archive description (eg. \"Comment blah\",00h)\n Method=14h, Subtype=1 Archive creator program name (eg. \"ARC 7.12 ...\",00h)\n Method=14h, Subtype=2 Archive modifier program name\n Method=15h, Subtype=0 File description (eg. \"Comment blah\",00h)\n Method=15h, Subtype=1 File long filename (if not MS-DOS \"8.3\" filename)\n Method=15h, Subtype=2 File extended date-time info (reserved)\n Method=15h, Subtype=3 File Icon (reserved)\n Method=15h, Subtype=4 File attributes (see below) (eg. \"RWHSN\",00h)\n Method=16h, Subtype=.. Operating system info (reserved)\n R=ReadAccess, W=WriteAccess, H=HiddenFile, 1=SystemFile, N=NetworkShareable\nSub-directories are implemented as nested ARC files - about same as when storing the sub-directory files in SUBDIR.ARC, and including that SUBDIR.ARC file in the main archive with Method 02h. Except that: It's using Method 1Eh (instead Method 02h), with filename SUBDIR (instead SUBDIR.ARC), and with [019h]=Nonsense (instead uncompressed size), and the nested file ends with Method 1Fh (instead Method 00h).
"},{"location":"cdromfileformats/#rle90-run-length-compression-with-value-90h-used-as-escape-code","title":"RLE90 (run-length compression with value 90h used as escape code)","text":"ARC does use raw RLE90 for small files (eg. 4-byte \"aaaa\"). ARC does also use RLE90 combined with other methods (perhaps because ARC wasn't very fast, compressing 100Kbytes could reportedly take several minutes; and without RLE90 pre-compression it might have been yet slower).
90h,00h Output 90h, but DON'T change prevbyte ;<-- ARC\n 90h,00h Output 90h, and DO set prevbyte=90h ;<-- BinHex\n 90h,00h Output 90h, and UNKNOWN what to do ;<-- StuffIt\n 90h,01h..03h Output prevbyte 00h..02h times (this is not useful)\n 90h,04h..FFh Output prevbyte 03h..FEh times (this does save memory)\n xxh Output xxh, and memorize prevbyte=xxh\n arc_decompress_rle90:\n src_end = src+src_size\n prevbyte = <initially undefined in ARC source code>\n @@decompress_lop:\n if src>=src_end then goto @@decompress_done\n x=[src], src=src+1\n if x<>90h then\n [dst]=x, dst=dst+1, prevbyte=x ;output x, and memorize prevbyte=x\n else ;x=90h\n x=[src], src=src+1\n if x=00h then\n [dst]=90h, dst=dst+1 ;output 90h, but DO NOT change prevbyte\n if BinHex then prevbyte=90h ;for BinHex, DO change prevbyte\n else\n for i=1 to x-1, [dst]=prevbyte, dst=dst+1, next i\n goto @@decompress_lop\n 000h 2 Number of Tree entries (0..100h) (when 0, assume tree=FEFFh,FEFFh)\n 002h N*4 Tree entries (16bit node0, 16bit node1)\n ... .. Huffman bitstream (starting in bit0 of first byte)\n ... .. Maybe supposedly padding to byte boundary?\n The 16bit nodes are:\n 0000h..00FFh Next Tree index\n 0100h..FEFEh Invalid\n FEFFh End of compressed data\n FF00h..FFFFh Data values FFh..00h (these are somewhat inverted/reversed)\n arc_decumpress_squeeze:\n if [src]=0000h then tree=empty_tree, else tree=src+2 ;-start tree\n InitBitstreamLsbFirst(src+2+[src]*4) ;-start bitstream\n @@decompress_lop:\n index=0000h ;\\\n while index<FEFFh ; huffman decode\n index=[tree+index*4+GetBits(1)*2] ;/\n if index>FEFFh then ;-check end code\n [dst]=(index XOR FFh) AND FFh), dst=dst+1 ;-store data\n goto @@decompress_lop\n return\n empty_tree dw FEFFh,FEFFh ;upen empty tree, ARC defines two 1bit END codes\n arc_decompress_randomized_lzw:\n num_free=1000h, stack=empty, oldcode=-1\n for i=0 to FFFh, lzw_parent[i]=EEEEh ;mark all codes as unused\n for i=0 to FFh, create_code(FFFFh,i) ;codes for 00h..FFh with parent=none\n @@decompress_lop:\n if src>=src_end then goto @@decompress_done\n code=GetBitsMsbFirst(12), i=code\n if lzw_parent[i]=EEEEh then i=oldcode, push(oldbyte) ;-for KwKwK strings\n while lzw_parent[i]<>FFFFh, push(lzw_data[i]), i=lzw_parent[i]\n oldbyte=lzw_data[i], [dst]=oldbyte, dst=dst+1\n if oldcode<>-1 then create_code(oldcode,oldbyte)\n oldcode=code\n while stack<>empty, [dst]=pop(), dst=dst+1\n goto @@decompress_lop\n @@decompress_done:\n ret\n ;---\n create_code(parent,data):\n if num_free=0 then goto @@no_further_codes, else num_free=num_free-1 ;-full\n i=(parent+data) AND 0000FFFFh ;\\\n if method=7 then i=(i*3AE1h) AND FFFh ;new \"fast\" randomizer ;\n else i=(sqr(i OR 800h)/40h) AND FFFh ;old \"slow\" randomizer ;\n if lzw_parent[i]=EEEEh then goto @@found_free ; alloc\n while lzw_sibling[i]>0000h, do i=lzw_sibling[i] ;find chain end ; code\n e=i, i=(i+65h) AND FFFh ;memorize chain end & do some random skip ;\n while lzw_parent[i]<>EEEEh, do i=(i+1) AND FFFh ;find a free code ;\n lzw_sibling[e]=i ;weirdly, i=0 will make it behave as sibling=none ;\n @@found_free: ;/\n lzw_data[i]=data, lzw_parent[i]=parent, lzw_sibling[i]=0000h ;-apply\n @@no_further_codes:\n ret\nThis is more straight non-randomized LZW with Clear codes (and weird gaps after Clear codes). The compression (and gaps) are same as for nCompress (apart from different headers): CDROM File Compression nCompress.Z
ARC Method 8 with 1-byte header (0Ch) --> nCompress 3-byte header 1Fh,9Dh,8Ch\n ARC Method 9 without header --> nCompress 3-byte header 1Fh,9Dh,8Dh\nThis is based on LHArc lh1. Like lh1, it does have 13Ah data/len codes, and 1000h distance codes. There are two differences:
Differences LHArc method lh1 ARC method 0Ah\n Data/len codes: 100h..139h=Len(3..3Ch) 100h=End, 101h..139h=Len(3..3Bh)\n Initial dictionary: 20h-filled Uninitialized\nARC file/directory names are alphabetically sorted, that does apply even when adding files to an existing archive (they are inserted at alphabetically sorted locations rather than being appended at end of archive). ARC files can be encrypted/garbled with password (via \"g\" option), the chunk header doesn't contain any flags for indicating encrypted files (except, the CRC16 will be wrong when not supplying the correct password). ARC end-marker (1Ah,00h) may be followed by additional padding bytes, or by additional information from third-party tools:
PKARC/PKPAK adds comments (starting with \"PK\",AAh,55h)\n PAK adds extended records (described in PAK.DOC file in the v2.51)\nhttp://fileformats.archiveteam.org/wiki/ARC_(compression_format)
https://www.fileformat.info/format/arc/corion.htm
http://cd.textfiles.com/pcmedic/utils/compress/arc520s.zip - source code
https://github.com/ani6al/arc - source code, upgraded with method 9 and 4
https://entropymine.wordpress.com/2021/05/11/arcs-trimmed-compression-scheme/
http://www.textfiles.com/programming/FORMATS/arc-lbr.pro - benchmarks
"},{"location":"cdromfileformats/#cdrom-file-compression-rar","title":"CDROM File Compression RAR","text":"RAR is a compression format for enthusiastic users (who love to download the latest RAR version before being able to decompress those RAR files).
"},{"location":"cdromfileformats/#rar-v13-march-1994-used-only-in-rar-1402","title":"RAR v1.3 (March 1994, used only in RAR 1.402)","text":"This format was only used by RAR 1.402, and discontinued after three months when RAR 1.5 got released.
File Header:\n 000h 4 ID \"RE~^\" (aka 52h,45h,7Eh,5Eh)\n 004h 2 Header Size (usually 0007h, or bigger when Comment/Ext1 exist)\n 006h 1 Archive Flags (80h or xxh)\n ... (2) Archive Comment Size ;\\Only present when ArchiveFlags.bit1=1\n ... (..) Archive Comment Data ;/\n ... (2) Ext1 Size ;\\Only present when ArchiveFlags.bit5=1\n ... (..) Ext1 Data ;/\n ... .. Unknown (TECHNOTE hints sth can be here, when bigger HeaderSize?)\n Archive Flags:\n 0 Volume (maybe related to split-volume on several floppies?)\n 1 Comment\n 2 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)\n 3 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)\n 4 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)\n 5 EXT1\n 6 Unspecified (maybe unused)\n 7 Unspecified (maybe unused, but... it's usually 1)\n File Data blocks:\n 000h 4 Filesize, compressed\n 004h 4 Filesize, uncompressed\n 008h 2 Checksum on uncompressed? file (sum=LeftRotate16bit(sum+byte[i])\n 00Ah 2 Header Size (usually 0015h+FilenameLength)\n 00Ch 4 File Modification Timestamp in MSDOS format\n 010h 1 File Attribute in MSDOS format (20h=Normal)\n 011h 1 Flags\n 012h 1 Version (0=0.99, 1=1.00, 2=1.30) (always 2 in public version)\n 013h 1 Filename Length\n 014h 1 Method (00h=m0a=Stored, 03h=m3a=Default) (1..5 = fastest..best)\n ... (2) File Comment Length ;\\Only present if FileFlags.bit3=1\n ... (..) File Comment Data ;/\n ... .. Filename (\"PATH\\FILENAME.EXT\", without any end marker)\n ... .. Unknown (TECHNOTE hints sth can be here, when bigger HeaderSize?)\n ... .. Compressed file data\n File Flags:\n 0 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)\n 1 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)\n 2 Unknown? (non-english description is in 1.402's TECHNOTE.DOC)\n 3 Comment (non-english description is in 1.402's TECHNOTE.DOC)\n 4-7 Unspecified (maybe unused)\nOverall Chunk Format:
000h 2 Chunk Header CRC; Lower 16bit of CRC32 on [002h..HdrSize-1 or less]\n 002h 1 Chunk Type (72h..7Ah)\n 003h 2 Chunk Flags\n 005h 2 Chunk Header Size\n 007h (4) Data block size ;<-- Only present if Flags.bit15=1\n ... .. Header values (depending on Chunk Type and Chunk Header Size)\n ... .. Data block ;<-- Only present if Flags.bit15=1\n Chunk Types:\n 72h=\"r\"=Marker block (with \"r\" being 3rd byte in ID \"Rar!\",1Ah)\n 73h=\"s\"=Archive header\n 74h=\"t\"=File header\n 75h=\"u\"=Old style Comment header (nested within Type 73h/74h)\n 76h=\"v\"=Old style Authenticity information\n 77h=\"w\"=Old style Subblock\n 78h=\"x\"=Old style Recovery record\n 79h=\"y\"=Old style Authenticity information\n 7AH=\"z\"=Subblock\n Chunk Flags:\n 0-13 Flags, meaning depends on Chunk Type\n 14 If set, older RAR versions (before 1.52 or so?) will ignore the\n block and remove it when the archive is updated. If clear, the\n block is copied to the new archive file when the archive is\n updated;\n or does \"older\" mean older than the \"archiver version\"?\n 15 Data Block present (0=No, 1=Yes, with size at [007h])\nType 72h, Marker Block (MARK_HEAD) This 7-byte ID occurs at the begin of RAR files (or after the executable in case of self-extracting files).
000h 7 ID (\"Rar!\",1Ah,07h,00h) (or \"Rar!\",1Ah,07h,01h for RAR 5.0)\n The above ID can be somewhat parsed as normal chunk header, as so:\n 000h 2 Faux CRC (6152h, no actual valid CRC)\n 002h 1 Chunk Type (72h)\n 003h 2 Faux Flags (1A21h, no actual meaning)\n 005h 2 Chunk Header size (0007h)\nType 73h, Archive Header (MAIN_HEAD)
000h 2 CRC32 AND FFFFh of fields HEAD_TYPE to RESERVED2\n 002h 1 Chunk Type: 73h\n 003h 2 Archive HeaderFlags\n 005h 2 Header size (usually 000Dh) (plus Comment Block, if any)\n 007h 2 RESERVED1 (0000h)\n 009h 4 RESERVED2 (0000011Dh)\n ... (..) Comment block ;<-- only present if Flags.bit1=1\n ... (..) Reserved for additional blocks\n Archive Header Chunk Flags:\n 0 Volume attribute (archive volume) (split-volume? volume-label? what?)\n 1 Archive comment present ;<-- used only before RAR 3.x\n RAR 3.x uses \"the separate comment block\" and does not set this flag.\n 2 Archive lock attribute\n 3 Solid attribute (solid archive)\n 4 New volume naming scheme (0=Old=\"name.???\", 1=New=\"name.partN.rar\")\n 5 Authenticity information present ;<-- used only before RAR 3.x\n 6 Recovery record present\n 7 Chunk headers are encrypted\n 8 First volume ;<-- set only by RAR 3.0 and later\n 9-13 Reserved for internal use\n 14-15 See overall Chunk Format\nType 74h, File Header (File in Archive)
000h 2 CRC32 AND FFFFh on HEAD_TYPE to FILEATTR and file name\n 002h 1 Header Type: 74h\n 003h 2 Bit Flags\n 005h 2 File header full size including file name and comments\n 007h 4 Compressed file size (can be bigger than uncompressed)\n 00Bh 4 Uncompressed file size\n 00Fh 1 Operating system used for archiving\n 010h 4 CRC32 on uncompressed file\n 014h 4 File Modification Timestamp in MSDOS format\n 018h 1 RAR version needed to extract file (Major*10+Minor) (min=0Fh=1.5)\n 019h 1 Compression Method (usually 35h in RAR 1.52)\n 01Ah 2 Filename size\n 01Ch 4 File Attribute in MSDOS format (20h=Normal, Upper24bit=whatever=0)\n ... (..) Comment block ;-Only present if Flags.bit3=1\n ... (4) MSBs of compressed file size ;\\Only present if Flags.Bit8=1\n ... (4) MSBs of uncompressed file size ;/\n ... .. Filename (\"PATH\\FILENAME.EXT\")\n ... (..) Filename extra fields (see Flags.bit9+bit11)\n ... (8) Encryption SALT ;-Only present if Flags.Bit10=1\n ... (..) Extended Time, variable size ;-Only present if Flags.Bit12=1\n ... (..) * other new fields may appear here.\n ... .. Compressed file data\n File Chunk Flags:\n 0 File continued from previous volume\n 1 File continued in next volume\n 2 File encrypted with password\n 3 File comment present ;<-- used only before RAR 3.x\n RAR 3.x uses the separate comment block and does not set this flag.\n 4 Information from previous files is used (solid flag) ;RAR 2.0 and later\n 5-7 Dictionary bits (for RAR 2.0 and later)\n 8 64bit Filesizes (for files \"larger than 2Gb\")\n 9 Unicode Filename, this can be in Dual or Single name form:\n Dual name: \"NormalName\",00h,\"UnicodeName\" ;<-- in UTF-8 or what?\n Single name: \"UnicodeName\" ;<-- in UTF-8\n 10 Header contains 8-byte Encryption SALT entry\n 11 Backup File (with version number \";n\" appended to filename)\n 12 Extended Time field present\n 13-14 -\n 15 Data Block present (always 1=With 32bit size at [007h], or 64bit size)\n Dictionary Bits (bit5-7)\n 00h=Dictionary Size 64 Kbyte\n 01h=Dictionary Size 128 Kbyte ;\\\n 02h=Dictionary Size 256 Kbyte ; RAR 2.0 and up\n 03h=Dictionary Size 512 Kbyte ;\n 04h=Dictionary Size 1024 Kbyte ;/\n 05h=Dictionary Size 2048 Kbyte ;\\RAR ?? and up\n 06h=Dictionary Size 4096 Kbyte ;/\n 07h=File is a directory ;-RAR 2.0 and up\n Operating System Indicators:\n 00h=MS DOS\n 01h=OS/2\n 02h=Windows\n 03h=Unix\n 04h=Mac OS\n 05h=BeOS\n ??h=Android?\n Compression Method:\n 35h=Default in RAR 1.52 (used even when file is too small to be compressed)\n xxh=Other methods (unknown values)\n 30h=Stored (RAR 2.00 supports uncompressed small files and -m0 switch)\n N/A=Stored (RAR 1.52 simply ignores \"-m0\" switch, and enforces \"-m1\" or so)\nType 75h, Comment block:
000h 2 Header CRC of fields from HEAD_TYPE to COMM_CRC\n 002h 1 Chunk Type: 75h\n 003h 2 Chunk Flags (unknown if/which flags are used)\n 005h 2 Chunk Header size (0Eh+Compressed comment size)\n 007h 2 Uncompressed comment size\n 009h 1 RAR version needed to extract comment\n 00Ah 1 Packing Method\n 00Ch 2 Comment CRC\n 00Eh .. Compressed comment data\nSub-formats The RAR format is comprised of many sub-formats that have changed over the years. The different formats and their descriptions are as follows:
* 1.3 (Does not have the RAR! signature)\n o There is difficulty finding information regarding this sub-format.\n * 1.5\n o Utilizes a proprietary compression method that is not public.\n o Considered the root model of subsequent formats.\n o A detailed list of information can be found here.\n * 2.0\n o Utilizes a proprietary compression method that is not public.\n o Based off of version 1.5 of the RAR file format.\n * 3.0\n o Utilizes the PPMII and Lempel-Ziv (LZSS)] algorithms.\n o Encryption now uses cipher block chaining (AES?-CBC) instead of AES\n o Based off of version 1.5 of the RAR file format.\nOlder RAR versions did include a TECHNOTE file describing the file format of those versions (TECHNOTE for 1.402 exist in unknown-language only, perhaps russian, and TECHNOTE was discontinued somewhere between 2.5 and 2.9). There is official decompression source code for newer RAR versions.
"},{"location":"cdromfileformats/#cdrom-file-compression-zoo","title":"CDROM File Compression ZOO","text":""},{"location":"cdromfileformats/#zoo-archives","title":"ZOO Archives","text":" File Header:\n 000h 20 Text Message (usually \"ZOO #.## Archive.\",1Ah,00h,00h)\n 014h 4 ID (FDC4A7DCh) (use this ID for detection, and ignore above text)\n 018h 4 Offset to first Chunk (22h or 2Ah+commentsize?)\n 01Ch 4 Offset to first Chunk, negated (-22h or -2Ah-commentsize?)\n 020h 1+1 Version needed to extract (Major,Minor) (usually 1,01 or 2,00)\n 022h (1) Archive Header Type (01h) ;\\\n 023h (4) Offset to Archive Comment (0=None) ; v2.00 and\n 027h (2) Length of Archive Comment (0=None) ; up only\n 029h (1) Version Data (01h or 03h) \"HVDATA\" ;/\n File Chunks:\n 000h 4 ID (FDC4A7DCh)\n 004h 1 Type of directory entry (1=Old, 2=New, with extra entries)\n 005h 1 Compression method (0=Stored, 1=LZW/default, 2=LZH)\n 006h 4 Offset to next Chunk\n 00Ah 4 Offset to File Data\n 00Eh 4 File Modification Date/time in MSDOS format\n 012h 2 CRC16 on uncompressed file (with initial value 0000h)\n 014h 4 Filesize, uncompressed\n 018h 4 Filesize, compressed\n 01Ch 1+1 Version needed to extract (Major,Minor) (usually 1,00 or 2,01)\n 01Eh 1 Deleted flag (0=Normal, 1=Deleted)\n 01Fh 1 File structure (unknown purpose)\n 020h 4 Offset of comment field (0=None)\n 024h 2 Length of comment field (0=None)\n 026h 13 Short Filename (\"FILENAME.EXT\",00h, garbage padded if shorter)\n 033h (1) Unknown (4Fh) (or 00h when with comment?) ;-Type=1\n 033h (2) Length of 038h and up (0Ah+longname+dirname) ;\\\n 035h (1) Timezone (signed) (7Fh=Unknown) ;\n 036h (2) CRC16 on Header (000h..037h+[033h], with [036h]=0000h) ;\n 038h (1) Length of Long Filename (0=None, use Short Filename) ;\n 039h (1) Length of Directory name (0=None) ; Type=2\n 03Ah (..) Long Filename (\"longfilename.ext\",00h) (if any) ;\n ... (..) Directory name (\"/path\",00h) (if any) ;\n ... (2) System ID (0=Unix, 1=DOS, 2=Portable) (but for DOS=0) ;\n ... (3) File Attributes (24bit) (but for DOS=0) ;\n ... (1) Backup Flags (bit7=On, bit6=Last, bit0-3=Generation) ;\n ... (2) Backup File Version Number (for backup copies) ;/\n ... 5 File Leader aka Fudge Factor (\"@)#(\",00h) ;\\\n ... .. File Data ; All types\n ... .. File Comment (if any) (ASCII, \"Text string\",0Ah) ;/\n Last Chunk:\n 000h 4 ID (FDC4A7DCh)\n 004h (30h) Zerofilled ;-Type 1\n 004h (1) Fixed (02h) ;\\\n 005h (31h) Zerofilled ; Tyoe 2\n 036h (2) CRC16 on Header (with [036h]=0000h) (always 83FCh) ;/\n ... (..) Comments may be stored here (if added after archive creation)\n ... (..) Padding, if any (1Ah-filled in some files)\nNotes: Method LZW is quite straight, the bitstream is fetched LSB first, codesize is initially 9bit, max 13bit, with two special codes (100h=Clear, 101h=Stop), there aren't any gaps after clear codes, the unusual part is that the bitstream does start with a clear code. Method LZH is slower, requires Zoo 2.10, and is used only when specifiying \"h\" option in commandline. LZH has 8Kbyte window, same as LHA's \"lh5\", with an extra end marker (blocksize=0000h=end). Comments may be stored anywhere in the middle or at the end of the archive (even after the zerofilled last chunk) (depending on whether the comment or further files where last added to the archive). Zoo is from 1986-1991, long filenames were supported only for OSes that did support them at that time (ie. not for DOS/Windows). When adding new files, Zoo defaults to maintain backups of old files in the archive (older files are marked as \"deleted\" via [01Eh]=1, but are kept in the archive; until the user issues command \"P\" for repacking/removing deleted files) (Zoo 2.xx can additionally use a \"generation\" limit of 0..15, which means to keep 0..15 older copies). All offsets are originated from begin of archive.
"},{"location":"cdromfileformats/#zoo-tiny-format-single-file-commandline-z-option","title":"Zoo Tiny format (single-file) (commandline \"z\" option)","text":"This format is called Tiny in Zoo source code, but isn't documented in the Zoo manual or Zoo help screen. Tiny can contain only a single file (alike gzip). The purpose appears to be using Tiny as temporary files when moving files from one archive to another (without needing to decompress & recompress the file), for example:
zoo xz source.too testfile.txt ;extract to tiny/temp file testfile.tzt\n zoo az dest.zoo testfile.txt ;import from tiny/temp file testfile.tzt\n 000h 2 Zoo Tiny ID (07FEh)\n 002h 1 Type (01h)\n 003h 1 Compression Method\n 004h 4 Date/time in MSDOS format\n 008h 2 CRC16 on uncompressed file, or what (?)\n 00Ah 4 Filesize, uncompressed\n 00Eh 4 Filesize, compressed\n 012h 1 Major_ver\n 013h 1 Minor_ver\n 014h 2 Comment size (0=None)\n 016h 13 Short Filename\n 023h .. File data ... plus comment, if any?\nThis command is documented in the Zoo manual, although it isn't actually supported in Zoo DOS version. The intended purpose is to use Zoo as a filter to speedup modem transfers. Going by some information snippets, the transfer format appears to be somewhat as so:
000h 2 Zoo Filter ID (32h,5Ah)\n ... .. Compressed data\n ... 2 CRC16 on uncompressed file, or what (?)\nnCompress is some kind of a Gzip predecessor. The program was originally called \"compress\" and later renamed to \"ncompress\" (and sometimes called \"(n)compress\"). Compressed files have uppercase \".Z\" attached to their original name.
"},{"location":"cdromfileformats/#ncompressz","title":"nCompress.Z","text":"The header is rather small and lacks info on decompressed size (ie. the one must process the whole bitstream to determine the size, and accordingly, the fileformat doesn't allow padding to be appended at end of file). To detect .Z files, examine the first three bytes, and best also check that the leading 9bit codes don't exceed num_codes (with num_codes increasing from 101h and up for each new code).
000h 2 ID (1Fh,9Dh)\n 002h 1 Mode (MaxBits(9..16) + bit7=WithClearCode) (usually 90h)\n 003h .. ClearGap LZW compressed data (or raw LZW when mode.bit7=0)\nBelow are file formats with unix/linux-style octal numbers (unknown if they are serious about using that formats, or if they do consider them as decently amusing, or whatever).
"},{"location":"cdromfileformats/#compression_2","title":"Compression","text":"TAR and CPIO are uncompressed archives, however, they are usually enclosed in a compressed Gzip file (or some other compression format like nCompress, Bzip2).
"},{"location":"cdromfileformats/#tar-format-1979","title":"TAR format (1979)","text":" 0000h .. TAR Chunk(s)\n ... 400h TAR End Marker (400h bytes zerofilled)\n ... .. Zerofilled (whatever further padding)\n 000h 100 text Filename (\"path/filename.ext\",00h)\n 064h 8 octal Mode Flags\n 06Ch 8 octal User ID\n 074h 8 octal Group ID\n 07Ch 12 octal Filesize\n 088h 12 octal File modification time (seconds since 01 Jan 1970)\n 094h 8 octal Header Checksum (sum of byte[0..1F3h], with [94h..9Bh]=20h)\n 09Ch 1 text Type (00h or \"0\" for normal files)\n 09Dh 100 text Whatever link name\n 101h 8 text Tar ID (6x00h or \"ustar\",00h,\"00\" or \"ustar \",00h)\n 109h 32 text User Name (owner)\n 129h 32 text Group Name\n 149h 8 octal Device major ;\\device number (when Type=\"4\")\n 151h 8 octal Device minor ;/\n 159h 155 ? Whatever prefix ;-when ID=\"ustar\",00h,\"00\" or 6x00h\n 159h 131 ? Whatever prefix ;\\\n 1DCh 12 octal File access time ; when ID=\"ustar \",00h\n 1E8h 12 octal File status-change time ;/\n 1F4h 12 - Zeropadding to 200h-byte boundary\n 200h .. - File data (Filesize bytes)\n ... .. - Zeropadding to 200h-byte boundary\n \"0000123.\" <-- normal weirdness, with leading zeroes and end-byte (\".\"=00h)\n \" 123 . \" <-- extra weird, leading/trailing spaces, mis-placed end-byte\n \" 123 \" <-- extra weird, leading/trailing spaces, without end-byte\n 0000h .. CPIO Chunk(s) (with actual files)\n ... 57h CPIO Chunk (with filename \"TRAILER!!!\",00h)\n ... .. Zeropadding to 200h-byte boundary (not always present)\n Align 2, Binary, little-endian (but partial \"big-endian\" for 2x16bit pairs)\n Align 2, Binary, big-endian\n Align 1, Ascii, octal strings\n Align 4, Ascii, hexadecimal lowercase strings, checksum=0)\n Align 4, Ascii, hexadecimal lowercase strings, checksum=sum of bytes in file)\n 000h 2 binary 16bit ID (71C7h) ;-little-or big endian\n 002h 2 binary 16bit dev ;\\\n 004h 2 binary 16bit ino ; same\n 006h 2 binary 16bit mode ; endianness\n 008h 2 binary 16bit uid ; as in ID\n 00Ah 2 binary 16bit gid ;\n 00Ch 2 binary 16bit nlink ; (but be aware\n 00Eh 2 binary 16bit rdev ; of the fixed\n 010h 2 binary 16bit File modification time, upper 16bit ;\\ ; upper/lower\n 012h 2 binary 16bit File modification time, lower 16bit ;/ ; 16bit order\n 014h 2 binary 16bit Filename size (including ending 00h) ; for time and\n 016h 2 binary 16bit Filesize, upper 16bit ;\\ ; filesize)\n 018h 2 binary 16bit Filesize, lower 16bit ;/ ;/\n 01Ah .. text Filename, terminated by 00h (\"path/filename\",00h)\n ... .. binary Zeropadding to 2-byte boundary\n ... .. binary File data (Filesize bytes)\n ... .. binary Zeropadding to 2-byte boundary\n 000h 6 octal 18bit ID \"070707\" (=71C7h)\n 006h 6 octal 18bit dev ;\\unique file id\n 00Ch 6 octal 18bit ino ;/within archive\n 012h 6 octal 18bit Mode (file attributes)\n 018h 6 octal 18bit User ID of owner\n 01Eh 6 octal 18bit Group ID\n 024h 6 octal 18bit nlink (related to duplicated dev/ino?)\n 02Ah 6 octal 18bit rdev (system-defined info on char/blk devices)\n 030h 11 octal 33bit File modification time\n 03Bh 6 octal 18bit Filename size (including ending 00h)\n 041h 11 octal 33bit Filesize\n 04Ch .. text Filename, terminated by 00h (\"path/filename\",00h)\n ... .. binary File data (Filesize bytes)\n 000h 6 hex 24bit ID \"070701\"=Without Checksum, or \"070702\"=With Checksum\n 006h 8 hex 32bit ino (does that 32bit value include 16bit \"dev\"?)\n 00Eh 8 hex 32bit mode\n 016h 8 hex 32bit uid\n 01Eh 8 hex 32bit gid\n 026h 8 hex 32bit nlink\n 02Eh 8 hex 32bit mtime\n 036h 8 hex 32bit Filesize\n 03Eh 8 hex 32bit devmajor\n 046h 8 hex 32bit devminor\n 04Eh 8 hex 32bit rdevmajor\n 056h 8 hex 32bit rdevminor\n 05Eh 8 hex 32bit Filename size (including ending 00h)\n 066h 8 hex 32bit Checksum, sum of all bytes in file, zero when ID=070701\n 06Eh .. text Filename, terminated by 00h (\"path/filename\",00h)\n ... .. binary Zeropadding to 4-byte boundary\n ... .. binary File data (Filesize bytes)\n ... .. binary Zeropadding to 4-byte boundary\nRPM files contain Linux installation packages. The RPM does basically contain a CPIO archive bundled with additional header/records with installation information.
000h 60h File Header (officially called \"Lead\" instead of \"Header\")\n 060h .. Signature Record (contains \"Header Record\" in \"Signature format\")\n ... .. Padding (to 8-byte boundary)\n ... .. Info Record (called \"Header\" and also uses \"Signature format\")\n ... .. Archive file (usually a GZIP compressed CPIO) (called \"Payload\")\n 000h 4 File ID (EDh,ABh,EEh,DBh) (aka octal string \"\\355\\253\\356\\333\")\n 004h 1 Major version (3)\n 005h 1 Minor version (0)\n 006h 2 Type (0=Binary Package, 1=Source Package)\n 008h 2 Architecture ID (defined in ISO/IEC 23360)\n 00Ah 66 Package name, terminated by 00h\n 04Ch 2 Operating System ID (1)\n 04Eh 2 Signature Type (5)\n 050h 16 Reserved space (officially undefined, usually zerofilled)\n 000h 4 Record ID (8Eh,ADh,E8h,01h) (aka octal string \"\\216\\255\\350\\001\")\n 004h 4 Reserved (zerofilled) (aka octal string \"\\000\\000\\000\\000\")\n 008h 4 Number of Item List entries (N)\n 00Ch 4 Size of Item Data (SIZ)\n 010h N*10h Item List (4x32bit each: Tag, Type, Offset, Size)\n ... SIZ Item Data (referenced via Offset/Size entries in above list)\n 00h=NULL Not Implemented\n 01h=CHAR Unknown, maybe unsigned 8bit (unaligned)\n 02h=INT8 Unknown, maybe signed 8bit (unaligned)\n 03h=INT16 Unknown, maybe signed 16bit (align2)\n 04h=INT32 Unknown, maybe signed 323bit (align4)\n 05h=INT64 Reserved, maybe signed 643bit (maybe align8)\n 06h=STRING Variable, NUL terminated string (unaligned)\n 07h=BIN Unknown, reportedly 1-byte size??? (unaligned)\n 08h=STRING_ARRAY Variable, Sequence of NUL terminated strings (unaligned)\n 09h=I18NSTRING Variable, Sequence of NUL terminated strings (unaligned)\n There are dozens of required & optional tag values defined.\n Basic extensions:\n .cpio (CPIO)\n .pax (CPIO for MAC)\n .rpm (RPM installation package for RPM package manager)\n .spec (RPM source file for creating RPM header/records)\n .tar (TAR, tape archive)\n Double extensions (and short forms like tgz):\n .tgz short for .tar.gz (gzip)\n .tbz short for .tar.bz2 (bzip2)\n .txz short for .tar.xz (XZ)\n .tlz short for .tar.lz (Lzip) or .tar.lzma (LZMA_Alone)\n .tzst short for .tar.zst (zstandard)\n .tsz short for .tar.sz (Sunzip)\n .taz short for .tar.Z (nCompress or possibly some other compressed format)\n .tz short for .tar.Z (nCompress or possibly some other compressed format)\n .spm short for .src.rpm (RPM source code package)\nBelow are related to MAC filesystems (where the file body consists of separate Data and Resource forks), and file type/creator values (resembling filename extensions).
"},{"location":"cdromfileformats/#macbinary-iiiiii-format-v1v2v3","title":"MacBinary I,II,III format (v1,v2,v3)","text":"MacBinary contains a single uncompressed file, used for transferring MAC files via network, or storing MAC files on non-MAC filesystems. PackIt/StuffIt archives do often have leading MacBinary headers. MacBinary doesn't have any unique filename extension (.bin may be used, more often it's using the same extension as the enclosed file, eg. .sit if it contains a StuffIt archive). Also, archives without explicit MAC support may use MacBinary format within compressed files (eg. LZH archives created with LHA MAC version).
000h 1 Old version number, must be kept at zero for compatibility\n 001h 1 Length of filename (1..63) (though v3 says 1..31)\n 002h 63 Filename (only \"length\" bytes are significant)\n 041h 4 File type (normally expressed as four characters)\n 045h 4 File creator (normally expressed as four characters)\n 049h 1 Finder flags, bit8-15 (see [065h] for bit0-7)\n 04Ah 1 Zero (must be 00h for compatibility)\n 04Bh 2 File Vertical position within its window\n 04Dh 2 File Horizontal position within its window\n 04Fh 2 File Window or folder ID\n 051h 1 Protected flag (bit0=Protected, whatever that is)\n 052h 1 Zero (must be 00h for compatibility)\n 053h 4 Filesize, Data Fork (0=None)\n 057h 4 Filesize, Resource Fork (0=None)\n 05Bh 4 File Timestamp, creation\n 05Fh 4 File Timestamp, last modification\n 063h 27 v1: Reserved (zerofilled)\n 063h 2 v2/v3: Length of Get Info comment (if any, usually 0000h)\n 065h 1 v2/v3: Finder Flags, bit0-7 (see [049h] for bit8-15)\n 066h 6 v2: Reserved (zerofilled)\n 066h 4 v3: ID (\"mBIN\"=MacBinary III)\n 06Ah 1 v3: Script of file name (from fdScript field of an fxInfo record)\n 06Bh 1 v3: Extended Finder flags (from fdXFlags field of fxInfo record)\n 06Ch 8 v2/v3: Reserved (zerofilled)\n 074h 4 v2/v3: Length of \"total files\" when \"packed files are unpacked\", uh?\n 078h 2 v2/v3: Extended Header size (reserved for future, always 0000h)\n 07Ah 1 v2/v3: MacBinary II uploader version (81h=v2, 82h=v3)\n 07Bh 1 v2/v3: MacBinary II downloader minimum version (81h=v2)\n 07Ch 2 v2/v3: CRC16-XMODEM on [000h..07Bh]\n 07Eh 2 Reserved for computer type and OS ID (0000h)\n ... .. Extended Header (if any, maybe stored here? when [078h]>0)\n ... .. Padding to 80h-byte boundary\n ... .. Data Fork (if any)\n ... .. Padding to 80h-byte boundary\n ... .. Resource Fork (if any)\n ... .. Padding to 80h-byte boundary\n ... .. Get Info comment (if any, usually none)\nDecoding binhex files is done via following steps (in that order):
1) ASCII to BINARY conversion (similar to BASE64)\n 2) RLE90 decompression of whole file (header+data+resource+crc's)\n 3) Processing the header+data+resource from the decompressed binary\n 4) For Multipart files, repeat above steps for each part\n The file may start with some text message, comments, description. Skip any\n such text lines until reaching a line that contains this 45-byte ID string:\n (This file must be converted with BinHex 4.0)\n That line should be followed by following characters (each char representing\n 6bit binary value, MSB first, first char is bit7-2 of first byte):\n !\"#$%&'()*+,- char(21h..2Dh) --> bin(00h..0Ch)\n 0123456 char(30h..36h) --> bin(0Dh..13h)\n 89 char(38h..39h) --> bin(14h..15h)\n @ABCDEFGHIJKLMN char(40h..4Eh) --> bin(16h..24h)\n PQRSTUV char(50h..56h) --> bin(25h..2Bh)\n XYZ[ char(58h..5Bh) --> bin(2Ch..2Fh)\n `abcdef char(60h..66h) --> bin(30h..36h)\n hijklm char(68h..6Dh) --> bin(37h..3Ch)\n pqr char(70h..72h) --> bin(3Dh..3Fh)\n : char(3Ah) --> start/end marker\n CR/LF char(0Dh/0Ah) --> linebreaks per 64 chars (CR and/or LF)\n SPC/TAB char(09h/20h) --> blanks (reportedly in some files)\n RLE90 decompression is same as in ARC files, except, code 90h,00h is handled\n differently: ARC keeps prevbyte=unchanged, BinHex sets prevbyte=90h.\n RLE90 compression is somewhat optional: 90h must be encoded as 90h,00h,\n but many encoders don't bother to compress repeating bytes (eg. many files\n contain \"!!!!!!!!\" chars aka uncompressed 00h-filled bytes).\n There is no way to know the decompressed size before decompression (either\n decompress the whole file and allocate more memory as needed, or decompress\n only the header (filename+16h bytes) and then compute decompressed size as\n filename+16h+data+2+resource+2 bytes).\n The decompressed binary contains following data (similar as MacBinary):\n 00h 1 Length of Filename (1..63)\n 01h .. Filename (\"FILENAME.EXT\")\n 01h+N 1 Version (00h)\n 02h+N 4 File Type\n 06h+N 4 File Creator\n 0Ah+N 2 Finder Flags\n 0Ch+N 4 Filesize, uncompressed, Data Fork\n 10h+N 4 Filesize, uncompressed, Resource Fork\n 14h+N 2 Header CRC16-XMODEM on uncompressed 14h+N bytes\n 16h+N .. Data Fork\n ... 2 Data Fork CRC16-XMODEM on uncompressed Data Fork\n ... .. Resource Fork\n ... 2 Resource Fork CRC16-XMODEM on uncompressed Resource Fork\n ... .. Padding (might reportedly occur in some files)\n Caution: There is a document that does claim that the CRC field should be be\n set to 0000h before CRC calculation, and that the CRC would be computed on\n Size+2 bytes (up to including he CRC field), that appears to be nonsense,\n the CRC is computed on Size+0 bytes, not Size+2.\n Emails or other text documents may contain multiple binhex files, if so,\n each part should be reportedly followed by a line containing:\n --- end of part NN ---\n Unknown if there are any .hqx files with such multipart stuff.\n Unknown if the next part starts with \"(This file must..\" or just with \":\".\nMAC File Type,Creator IDs = \"PIT \",\"PIT \" \\<-- normal (=uncompressed?) MAC File Type,Creator IDs = \"PIT \",\"UPIT\" \\<-- other (=compressed?)
Bitstream for Uncompressed File Entries:\n 32bits Uncompressed Header[000h..003h] (Method/Crypto=\"PMag\")\n ..bits Uncompressed Header[004h..061h] (uncompressed size = 5Eh)\n ..bits Uncompressed Data+Resource+CRC (uncompressed size = Data+Rsrc+2)\n Bitstream for Compressed File Entries:\n 32bits Uncompressed Header[000h..003h] (Method/Crypto=\"PMa4\")\n ..bits Compressed Huffman Tree (for decoding following bits)\n ..bits Compressed Header[004h..061h] (uncompressed size = 5Eh)\n ..bits Compressed Data+Resource+CRC (uncompressed size = Data+Rsrc+2)\n ..bits Padding to 8bit-boundary (byte align next File Entry)\n Bitstream for Archive End Marker (after last file):\n 32bits Uncompressed Header[000h..003h] (Method/Crypto=\"PEnd\")\n File Entry Format:\n 000h 4 Method/Crypto (usually \"PMag\"=Uncompressed, \"PMa4\"=Huffman)\n 004h 1 Filename length\n 005h 63 Filename (\"FILENAME\", garbage padded)\n 044h 4 File Type\n 048h 4 File Creator\n 04Ch 2 Finder flags\n 04Eh 2 Locked?\n 050h 4 Filesize, uncompressed, Data fork\n 054h 4 Filesize, uncompressed, Resource fork\n 058h 4 Timestamp, creation\n 05Ch 4 Timestamp, modification\n 060h 2 CRC16-XMODEM on [004h..05Fh]\n ... .. Data Fork\n ... .. Resource Fork\n ... 2 CRC16-XMODEM on uncompressed Data+Resource forks\n Method/Crypto:\n \"PEnd\" = Archive End marker (4-byte end marker, without filename etc.)\n \"PMag\" = Uncompressed\n \"PMa1\" = Uncompressed, Encrypted Simple\n \"PMa2\" = Uncompressed, Encrypted DES\n \"PMa3\" = Uncompressed, Encrypted reserved\n \"PMa4\" = Huffman\n \"PMa5\" = Huffman, Encrypted Simple\n \"PMa6\" = Huffman, Encrypted DES\n \"PMa7\" = Huffman, Encrypted reserved\n Decompression: ;for PackIt (and also for StuffIt method 03h)\n InitBitstreamMsbFirst(src) ;-src is after \"PMa4\" PackIt ID\n tree=GetMem(200h*4) ;-alloc tree (probably less needed)\n num_entries=0 ;\\init tree\n root=GetTreeEntry ;/\n while dst<dst_end ;-decompress, till end...\n index=root ;\\\n while index<FF00h ; huffman decode\n index=[tree+index*4+GetBits(1)*2] ;/\n [dst]=index AND FFh, dst=dst+1 ;-store data\n return\n ;---\n GetTreeEntry:\n if GetBits(1)=1 then\n return GetBits(8)+FF00h ;-final data entry\n else\n index=num_entries ;-current index\n num_entries=num_entries+1 ;-alloc next index\n [tree+index*4+0*2] = GetTreeEntry ;-recursive call for node0\n [tree+index*4+1*2] = GetTreeEntry ;-recursive call for node1\n return index\nMAC File Type,Creator IDs = \"SIT!\",\"SIT!\" (version=01h). MAC File Type,Creator IDs = \"SITD\",\"SIT!\" (version=02h). MAC File Type,Creator IDs = \"APPL\",\"STi0\" (whatever, with ID=\"ST65\")
StuffIt Archive Header:\n 000h 4 ID (\"SIT!\", short for StuffIt)\n Reportedly, there are several alternate IDs:\n \"SIT!\",\"ST46\",\"ST50\",\"ST60\",\"ST65\",\"STin\",\"STi2\",\"STi3\",\"STi4\"\n Unknown why, and if some do differ somehow (ST65 appears to be\n same as SIT!) (for STi, the \"i\" might be short for it? installer?)\n 004h 2 Number of entries in root directory\n 006h 4 Total size of archive\n 00Ah 4 ID (\"rLau\", short for Raymond Lau)\n 00Eh 1 Version number (01h=v1.x-v1.5.x, 02h=v1.6-v4.5)\n 00Fh 7 Reserved (zerofilled) ;-when version=01h\n 00Fh 1 Unknown (C6h or FFh) ;\\\n 010h 4 Offset to first root entry (16h or elsewhere!) ; when version=02h\n 014h 2 Unknown (0001h or FFFFh) ;/\n File Entries:\n 000h 1 Compression method, Resource fork\n 001h 1 Compression method, Data fork\n 002h 1 Filename length (1..63 for version=01h, 1..31 for version=02h)\n 003h 1Fh Filename (\"FILENAME.EXT\", garbage padding)\n 022h 20h Filename further chars ;-when version=01h\n 022h 2 Filename+size CRC ;\\\n 024h 2 Unknown (always 0000h or 0986h?) ; when version=02h\n 026h 4 Unknown Resource fork related ;maybe window ;\n 02Ah 4 Unknown Data fork related ;coords ? ;\n 02Eh 1 Unknown Data fork related ;\n 02Fh 1 Unknown Resource fork related ;\n 030h 2 Number of child entries (excluding End marker) ;\n 032h 4 Offset to previous entry ;\n 036h 4 Offset to next entry ;\n 03Ah 4 Offset to parent entry ;\n 03Eh 4 Offset to first child (or -1 for file entries) ;/\n 042h 4 File type (eg. \"APPL\")\n 046h 4 File creator (eg. \"ACTA\")\n 04Ah 2 Finder flags (2100h)\n 04Ch 4 Creation date\n 050h 4 Modification date\n 054h 4 Filesize, uncompressed, Resource fork (0=None)\n 058h 4 Filesize, uncompressed, Data fork (0=None)\n 05Ch 4 Filesize, compressed, Resource fork (0=None)\n 060h 4 Filesize, compressed, Data fork (0=None)\n 064h 2 CRC16 on uncompressed(?) Resource fork (0=None)\n 066h 2 CRC16 on uncompressed(?) Data fork (0=None)\n 068h 1 Pad bytes for encrypted Resource? (00h)\n 069h 1 Pad bytes for encrypted Data? (00h)\n 06Ah 2 Unknown Data fork related (0000h, or 0004h=Encrypted?)\n 06Ch 2 Unknown Resource fork related (0000h, or 0004h=Encrypted?)\n 06Eh 2 CRC16 on Header [000h..06Dh] with initial=0000h\n 070h .. Compressed Data, Resource fork (if any) (size=[05Ch])\n ... .. Compressed Data, Data fork (if any) (size=[060h])\n StuffIt Methods:\n 00h Uncompressed\n 01h RLE90 (same as... unknown if this is like BinHex, or like ARC)\n 02h ClearGap LZW (same as nCompress, 14bit, with Clear(+gap), no Stop code)\n 03h Huffman (same as PackIt \"PMa4\" method)\n 05h LZHUF (same as LHA \"lh1\" method)\n 06h Fixed Huffman Segmented. PackBits, then optional Huffman coding.\n The set of Huffman codes is predefined, but the meaning\n of a code can be different in each segment\n 08h MW (Miller-Wegman, presumably LZMW)\n 0Dh LZ+Huffman (?) ;-StuffIt and StuffIt5\n 0Eh Installer (uh?)\n 0Fh Arsenic (BWT and arithmetic coding) ;-StuffIt5 only?\n 1xh Encrypted methods (same as above, plus encryption)\n 20h Folder start ;\\StuffIt (not StuffIt5)\n 21h Folder end ;/\n Folder start\n Child entries\n Folder end\n Folder start\n Child entries\n Folder end\n StuffIt Archive Header:\n 000h 82 ID \"StuffIt (c)1997\",...,\"/StuffIt/\",0Dh,0Ah,1Ah,00h)\n 052h 1 Version (always 05h)\n 053h 1 Flags (can be 00h, 10h, 80h) (bit4=what?, bit7=Encrypted)\n 054h 4 Total size of archive\n 058h 4 Offset to first entry in root directory (64h, plus Extra Data)\n 05Ch 2 Number of entries in root directory\n 05Eh 4 Same as [058h] (maybe one is 1st entry, and other is Header size)?\n 062h 2 Header CRC16 on [000h..[05xh]-1] with [062h]=0000h and initial=0\n 064h .. Extra Data (see below)\n ... .. File/Folder entries\n Extra data can be:\n None (when [58h]=64h) ;with Flags=00h\n 05h,76h,35h,B9h,87h,11h ;maybe 05h=Length? ;with Flags=80h=crypto\n 0Dh,A5h,A5h,\"Reserved\",A5h,A5h,00h) ;maybe 0Dh=Length? ;with Flags=10h=what?\n File/Folder entries:\n 000h .. Base Header\n ... .. OS Header (depending on OS Type in Base Header)\n ... .. Resource fork (if any) (MAC only, not Windows)\n ... .. Data fork (if any)\n Base Header:\n 000h 4 ID (A5A5A5A5h) (or B4B4B4B4h=corrupted charset conversion maybe?)\n 004h 1 OS Type (1=Mac, 3=Windows)\n 005h 1 Unknown (0)\n 006h 2 Base Header size (41h) (30h+IV?+Filename+Comment)\n 008h 1 Unknown (0) (maybe Flags MSB?)\n 009h 1 Flags (bit3=Comment, bit6=Folder, bit5=Encrypted)\n 00Ah 4 Timestamp, Creation (Mac OS format, seconds since 1904)\n 00Eh 4 Timestamp, Modification (Mac OS format, seconds since 1904)\n 012h 4 Offset of previous entry (0=None)\n 016h 4 Offset of next entry (0=None)\n 01Ah 4 Offset of parent folder entry (0=None)\n 01Eh 2 Filename size (F)\n 020h 2 Base Header CRC-16 on [000h..[006h]-1]\n 022h (4) Offset of first child entry in folder (FFFFFFFFh=End) ;\\Folder\n 026h (4) Size of complete directory ; (if Flags\n 02Ah (4) Unknown ; bit6=1)\n 02Eh (2) Number of child entries (excluding folder End marker) ;/\n 022h (4) Data fork uncompressed size ;\\\n 026h (4) Data fork compressed size ;\n 02Ah (2) Data fork CRC-16 (0 for method 0Fh) ; File\n 02Ch (2) Data fork Unknown (0000h) ; (if Flags\n 02Eh (1) Data fork compression method (00h,0Dh,0Fh) ; bit6=0)\n 02Fh (1) Data fork Encryption IV? size ;\n ... (..) Data fork Encryption IV? data ;/\n ... .. File/Folder name (\"FILENAME.EXT\")\n ... (2) Comment size (K) ;\\Comment\n ... (2) Comment Unknown (0) ; (if Flags\n ... (..) Comment data ;/bit3=1)\n OS Header for Mac (OS=1):\n 000h 2 Flags2 (bit0=HasResource, bit4=same as archive header [053h] ?)\n 002h 2 CRC16 on OS Header (with [002h]=0000h, initial=0)\n 004h 4 Mac OS file type ;\\\n 008h 4 Mac OS file creator ; as so for Files\n 00Ch 2 Mac OS Finder flags ; (seems to contain\n 00Eh 2 Mac OS Unknown ; other stfuff/junk\n 010h 4 Mac OS Unknown ; for Folders)\n 014h 4 Mac OS Unknown ;\n 018h 4 Mac OS Unknown ;\n 01Ch 4 Mac OS Unknown ;\n 020h 4 Mac OS Unknown ;/\n 024h (4) Resource fork uncompressed size ;\\\n 028h (4) Resource fork compressed size ; only if\n 02Ch (2) Resource fork CRC-16 (0 for method 0Fh) ; Flags2\n 02Eh (2) Resource fork Unknown ; bit0=1\n 030h (1) Resource fork compression method ;\n 031h (1) Resource fork Encryption IV? size ;\n ... (..) Resource fork Encryption IV? data ;/\n OS Header for Windows (OS=3):\n 000h 2 Flags 2 (bit4=same as archive header [053h] ?)\n 002h 2 CRC16 on OS Header (with [002h]=0000h, initial=0)\n 004h 4 Windows File Attribute (20h=Normal, 10h=Folder)\n 008h 08h Windows Zerofilled\n 010h 4 Windows Timestamp last accessed?\n 014h 4 Windows Unknown (0005xxxxh)\n 018h 08h Windows Zerofilled\n StuffIt Archive Header:\n 000h 8 ID \"StuffIt!\" (reportedly \"StuffIt?\" also exists)\n 008h .. Unknown...\nMAC File Type,Creator IDs = \"PACT\",\"CPCT\". Compact Pro (originally called Compactor) was a MAC archiver competing with StuffIt. There's also a DOS tool (ExtractorPC) for extracting .cpt files on PCs (albeit released in .EXE.sit.hqx format, making it unlikely that PC users could have used it).
Archive header:\n 000h 1 File ID (always 01h)\n 001h 1 Volume number (01h for single-volume, Other=Unknown)\n 002h 2 Random Volume ID? (...must be same in all split volume files?)\n 004h 4 Offset to Footer (from begin of file)\n 008h .. Compressed files (resource+data fork pairs)\n ... .. Footer (directory information)\n Footer format:\n 000h 4 CRC32 XOR FFFFFFFFh on following bytes\n 004h 2 Number of entries in root folder (including all child entries)\n 006h 1 Comment length (usually 00h=None)\n 007h N Comment\n 007h+N .. File/Folder entries\n Folder entries, with [000h].bit=1:\n 000h 1 Foldername length (N), plus bit7=Type (1=Folder)\n 001h N Foldername (\"FOLDERNAME\")\n 001h+N 2 Number of entries in this folder (including all child entries)\n File entries, with [000h].bit=0:\n 000h 1 Filename length (N), plus bit7=Type (0=File)\n 001h N Filename (\"FILENAME.EXT\")\n 001h+N 1 Volume number (01h for single-volume, Other=Unknown)\n 002h+N 4 Offset to compressed Resource (followed by compressed Data)\n 006h+N 4 File type\n 00Ah+N 4 File creator\n 00Eh+N 4 Timestamp, creation (seconds since 1904)\n 012h+N 4 Timestamp, modification (seconds since 1904)\n 016h+N 2 Finder flags\n 018h+N 4 CRC32 XOR FFFFFFFFh on uncompressed Resource + Data forks\n 01Ch+N 2 Method/Flags (see below)\n 01Eh+N 4 Filesize, uncompressed, Resource fork\n 022h+N 4 Filesize, uncompressed, Data fork\n 026h+N 4 Filesize, compressed, Resource fork\n 02Ah+N 4 Filesize, compressed, Data fork\n Method/Flags:\n 0 Encryption (0=None, 1=Encrypted, unknown how)\n 1 Method for Resource fork (0=RLE8182, 1=RLE8182+LZSSHUF)\n 2 Method for Data fork (0=RLE8182, 1=RLE8182+LZSSHUF)\n 3-15 Unknown/unused (0)\n Note: RLE8182 and RLE8182+LZSSHUF are also used by Mac DiskDoubler.\n This is same as RLE90, with two-byte escape code (81h,82h instead of 90h):\n 81h,82h,00h Output 81h,82h\n 81h,82h,01h..03h Output prevbyte 00h..02h times (this is not useful)\n 81h,82h,04h Output prevbyte 03h times (useful if prev=81h, next=82h)\n 81h,82h,05h..FFh Output prevbyte 04h..FEh times (this does save memory)\n 81h,xxh Output 81h, and then process xxh\n 81h,padding Output 81h, at end of file (with padding<>82h)\n xxh Output xxh (unless it is 81h)\n Note: prevbyte is the previous output byte (ie. that stored at [dst-1]).\n If the uncompressed file ends with 81h, then the compressed file MUST contain\n a dummy padding byte (the RLE decoder in macutils sets a prefix flag upon 81h,\n but doesn't output it to dst until receiving the padding byte, which could be\n 81h, or any value other than 82h).\n This uses LZSS-style flag bits (to distinguish between data and len/disp),\n combined with three Huffman trees (for data, len, disp values). The sliding\n window is 2000h bytes (8Kbytes). The format appears to be a simplified variant\n or LHA compression (but gets complicated by inventing weird corner cases).\n if uncompressed_size=0 then goto @@all_done ;-empty (eg. for unused forks)\n [dst+0000h..1FFCh]=uninitialized ;\\\n [dst+1FFDh..1FFFh]=00h,00h,00h ; prefill sliding window\n dst+dst+2000h ;/\n @@block_lop:\n InitBitstreamMsbFirst(src)\n GetLzsshufTree(data_tree,100h) ;tree for data=00h..FFh\n GetLzsshufTree(len_tree,40h) ;tree for len=00h..3Fh (0,1 usually unused)\n GetLzsshufTree(disp_tree,80h) ;tree for dispUpper7bit=00h..7Fh\n block_org=src, blocksize=0 ;block origin (after above trees)\n @@decompress_lop:\n if src>=src_end then goto @@all_done ;<-- this may overshoot on padding bits\n if out>=out_end then goto @@all_done ;<-- more precise; if RleOnTheFly\n if blocksize>=1FFF0h AND type=CompactPro then goto @@block_done\n if blocksize>=0FFF0h AND type=Disc Double then goto @@block_done\n if GetBits(1)=1 then\n [dst]=GetHuffCode(data_tree), dst=dst+1, blocksize=blocksize+2\n else\n len=GetHuffCode(len_tree)+0, blocksize=blocksize+3\n disp=GetHuffCode(disp_tree)*40h+GetBits(6), if disp=0000h then disp=2000h\n for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i\n if RleOnTheFly then forward above byte(s) to RLE (which advances \"out\" ptr)\n goto @@decompress_lop\n @@block_done:\n ;the decoder does prefetch data in 16bit units, and it does always have\n ;16..31 bits prefetched, these bits are discarded at block end...\n src=src+2+((src-block_org) AND 1) ;discard 16..31 bits (till 16bit-boundary)\n goto @@block_lop ;start next block, with new trees\n @@all_done:\n ret\n num=GetBits(8)*2, if num>max then goto error ;number of symbols (00h and up)\n for i=0 to num-1, codesizes[i]=GetBits(4) ;sizes (1..15 bits, or 0=unused)\n lzh_explode_tree(tree,codesizes,num) ;alike LHA trees\n ret\n Disp=0 acts as Disp=2000h (don't care when using ringbuf[index AND 1FFFh])\n Len=0..1 could be definied in the len_tree (but are usually size=0bit=unused)\n Unknown if disp_tree & len_tree can be empty (when using data_tree only)?\n RLE ending with 81h,padding should only output 81h (see RLE8182 description)\n A few .cpt files (eg. ABC's-1.09.cpt.hqx\\..\\Colin's ABC's\\Message.h) have\n incomplete trees (like only one disp code, \"0\"=DispUpper7bit=00h, without\n defining any further huffman codes like \"1\" or \"1xxx\").\n This isn't much of a problem (except, one may need to remove incomplete tree\n error checking in the \"lzh_explode_tree\" function).\n End of Last Block is usually determined by forwarding the LZSSHUF output\n directly to the RLE8182 decompressor (which does then check if uncompressed\n size is reached) (marked \"RleOnTheFly\" in above sample code).\n Alternately, one could decompress in separate steps (LZSSHUF to tempbuf, and\n then tempbuf to RLE8182), but that requires to deal with padding bits.\n - padding seems to be 16..31 bits (?) alike at end of blocksize\n - padding bits are (always?) zeroes, which act as flag=0=compressed\n - compressed data occupies at least flg(1),len(1),disp(1),displsbs(6)=9bits\n That can lead to decoding a few extra codes (with lengths up to 3Fh each),\n so the tempbuf must have trailing space for writing that garbage padding.\n And, those padding bits tend to translate to disp=0000h (aka disp=2000h),\n which can cause reads from the whole sliding window, so tempbuf requires\n 2000h leading bytes to avoid page faults (not just the 3 initialized bytes).\nThe abbreviation SEA (and extension .sea) is used for several self-extracting MAC archives. The Resource fork contains an executable (as indicated by Type=\"APPL\") which contains the decompressor, and the Data fork contains the archive.
MAC File Type,Creator IDs = \"APPL\",\"aust\" (StuffIt).\n MAC File Type,Creator IDs = \"APPL\",\"EXTR\" (CompactPro).\n MAC File Type,Creator IDs = \"APPL\",\"DSEA\" (DiskDoubler).\n StuffIt .sea files: These are often raw StuffIt archives (apparently\n somebody had removed the MacBinary header and the resource fork with\n the decompressor).\n CompactPro .sea files: These are often stored as MacBinary without 80h-byte\n padding appended to the Data and Resource forks.\n That applies to \"Santa.sea\" but other such files have OTHER corruptions,\n which may include wrong Size and/or garbage in reserved MacBinary fields?\nThe Data fork contains the \"normal data\" part of the file (eg. anything like .TXT .DOC .GIF .JPG .WAV .ZIP .LZH .SIT .PIT .CPT etc).
"},{"location":"cdromfileformats/#mac-os-resource-forks","title":"Mac OS Resource forks","text":"The Resource fork can contain executable code resources (similar to .EXE files; with File Type=\"APPL\"), and various other resources (fonts, icons, text strings for dialog boxes, etc). Those resources are stored in a filesystem-style archive and can be accessed with IDs and/or name strings.
Resource fork Header:\n 000h 4 Offset to Resource Data section (from start of file) (100h)\n 004h 4 Offset to Resource Map section (from start of file) (100h+DataSiz)\n 008h 4 Size of Resource Data section (can be 0=None)\n 00Ch 4 Size of Resource Map section\n 010h F0h Unknown (can contain filename/type.. MAYBE just garbage padding?)\n 100h .. Resource Data section, contains Data Record(s)\n ... .. Resource Map section\n Data Record(s) in Resource Data section (usually at offset 100h and up):\n 000h 4 Size of Data for this record\n 004h .. Data for this record\n Resource Map section:\n 000h 4 Offset to Resource Data section (from start of file) ;\\\n 004h 4 Offset to Resource Map section (from start of file) ; same as in\n 008h 4 Size of Resource Data section ; header\n 00Ch 4 Size of Resource Map section ;/\n 010h 4 Zero (internally used by Resource Manager, nextResourceMap)\n 014h 2 Zero (internally used by Resource Manager, fileRef)\n 016h 2 Map Attributes\n 0-4 Zero (reserved)\n 5 Zero (internally used by Resource Manager, changed)\n 6 Zero (internally used by Resource Manager, need compression)\n 7 Resource map is read-only\n 8-15 Zero (reserved)\n 018h 2 Offset to Type List (from start of resource map) (usually 1Ch ?)\n 01Ah 2 Offset to Name List (from start of resource map)\n ... .. Type List\n ... .. Resource List (with one or more entry for each entry in Type List)\n ... .. Name List (each name consists of 8bit NameLength, plus name string)\n Type List follows the header and contains an array of resource type records.\n 000h 2 Number of Type Records, minus one (FFFFh=None, 0000h=One, etc.)\n 002h N*8 Type Records\n Type Record format:\n 000h 4 Resource Type (four-character constant)\n 004h 2 Number of Resource List entries, minus one (0000h=One, etc.)\n 006h 2 Offset to first Resource List entry (from start of Type List)\n Resource List entries:\n 000h 2 Resource ID (C000h..FFFFh=Special/Owned)\n 002h 2 Offset to Resource Name (from start of Name List) (FFFFh=None)\n 004h 1 Attributes\n 0 Resource data is compressed (0=No, 1=Compressed)\n 1 Zero (internally used by Resource Manager, changed)\n 2 Load Resource as soon as file is opened (0=No, 1=Preload)\n 3 Resource is read-only (0=No, 1=Protected)\n 4 Resource may not be moved in memory (0=No, 1=Locked)\n 5 Resource may be paged out of memory (0=No, 1=Purgeable)\n 6 Load Resource to (0=Application heap, 1=System Heap)\n 7 Zero (reserved)\n 005h 3 Offset to Resource Data (from start of Resource Data section)\n 008h 4 Zero (internally used by Resource Manager, resourcePtr)\n Note: Some (or all?) 16bit offsets are reportedly signed (max 32Kbyte), the\n 24bit offsets are reportedly unsigned (max 16Mbyte).\n Compressed resource have a standarized header, the decompression function(s)\n are supposed to be stored in separate \"dmcp\" resource (unknown if the OS is\n also providing standard decompression functions).\n 000h 4 ID (always A89F6572h for compressed resource)\n 004h 2 Always 0012h (maybe compression header size)\n 006h 1 Type (08h=Type8, 09h=Type9)\n 007h 1 Always 01h\n 008h 4 Uncompressed resource size\n 00Ch 1 For Type8: workingBufferFractionalSize ;\\\n 00Dh 1 For Type8: expansionBufferSize ; Type8\n 00Eh 2 For Type8: dcmpID (ID in \"dmcp\" decompress resource) ;\n 010h 2 For Type8: Zero (reserved?) ;/\n 00Ch 2 For Type9: dcmpID (ID in \"dmcp\" decompress resource) ;\\Type9\n 00Eh 4 For Type9: decompressor_specific_parameters_with_io ;/\n 012h .. Compressed Resource Data\nOwned Resources (with Resource ID=C000h..FFFFh):
https://github.com/kreativekorp/ksfl/wiki/Macintosh-Resource-File-Format
The upper 5bit (mask F800h) indicate the resource type of the owner, the middle 6bit (mask 07E0h) indicate the resource id of the owner, and the lower 5bit (mask 001Fh) indicate the \"sub-id\" of the owned resource.
ID MSBs Owner Type Notes\n C000h DRVR driver or desk accessory\n C800h WDEF window definition: code to draw windows\n D000h MDEF menu definition: code to draw menus\n D800h CDEF control definition: code to draw UI widgets\n E000h PDEF printer driver\n E800h PACK utility code package/library used by the Mac OS\n F000h cdev control panel; owner id is set to 1\n F800h reserved reserved for future use\nMost PSX discs have huge zerofilled dummy files with about 32Mbytes, using filenames like DUMMY, NUL, NULL, or ZNULL, this is probably done to tweak the disc to have valid sector numbers at the end of disc (to help the drive head to know which sector it is on). Of course, Sony could as well pad the discs with longer Lead-Out areas, but the dummy files may have been needed during development with CDRs (though burning such large files doesn't exactly speed up development). There are different ways to make sure that the file is at end of the disc: - Some CDROM burning tools may allow to specify which file is where - Some games have the file alphabetically sorted as last file in last folder - Some games have the file declared as audio track - Some games (additionally) have large zeropadding at end of their archive file
"},{"location":"cdromfileformats/#xyz-files","title":"XYZ Files","text":"To reduce seek times, it can make sense to have the boot files & small files at the begin of the disc. Some games seem to use alphabetically sorted file/folder names to tweak Movies and XA-audio to be located at the end of disc (eg. using ZMOVIE as folder name).
"},{"location":"cdromfileformats/#cdrom-disk-images-ccdimgsub-clonecd","title":"CDROM Disk Images CCD/IMG/SUB (CloneCD)","text":""},{"location":"cdromfileformats/#fileimg-2352-930h-bytes-per-sector","title":"File.IMG - 2352 (930h) bytes per sector","text":"Contains the sector data, recorded at 930h bytes per sector. Unknown if other sizes are also used/supported (like 800h bytes/sector, or even images with mixed sizes of 800h and 930h for different tracks).
"},{"location":"cdromfileformats/#filesub-96-60h-bytes-per-sector-subchannel-pw-with-96-bits-each","title":"File.SUB - 96 (60h) bytes per sector (subchannel P..W with 96 bits each)","text":"Contains subchannel data, recorded at 60h bytes per sector.
00h..0Bh 12 Subchannel P (Pause-bits, usually all set, or all cleared)\n 0Ch..17h 12 Subchannel Q (ADR/Control, custom info, CRC-16-CCITT)\n 18h..5Fh .. Subchannel R..W (usually zero) (can be used for CD-TEXT)\nContains Lead-in info in ASCII text format. Lines should be terminated by 0Dh,0Ah. The overall CCD filestructure is:
[CloneCD] ;File ID and version\n [Disc] ;Overall Disc info\n [CDText] ;CD-TEXT (included only if present)\n [Session N] ;Session(s) (numbered 1 and up)\n [Entry N] ;Lead-in entries (numbered 0...\"TocEntries-1\")\n [TRACK N] ;Track info (numbered 1 and up)\n Version=3 ;-version (usually 3) (rarely 2)\n TocEntries=4 ;-number of [Entry N] fields (lead-in info blocks)\n Sessions=1 ;-number of sessions (usually 1)\n DataTracksScrambled=0 ;-unknown purpose (usually 0)\n CDTextLength=0 ;-total size of 18-byte CD-TEXT chunks (usually 0)\n CATALOG=NNNNNNNNNNNNN ;-13-digit EAN-13 barcode (included only if present)\n Entries=N ;number of following entries (CDTextLength/18) (not /16)\n Entry 0=80 00 NN NN NN NN NN NN NN NN NN NN NN NN NN NN ;entry 0\n Entry 1=80 NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN ;entry 1\n ...\n Entry XX=8f NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN ;entry N-1\n Note: Each entry contains 16 bytes (ie. \"18-byte CD-TEXT\" with CRC excluded)\n \"NN NN NN..\" consists of 2-digit lowercase HEX numbers (without leading \"0x\")\n PreGapMode=2 ;-unknown purpose (usually 1 or 2) (or 0)\n PreGapSubC=1 ;-unknown purpose (usually 0 or 1)\n[Entry 0..2] are usually containing Point A0h..A2h info. [Entry 3..N] are usually TOC info for Track 1 and up.
Session=1 ;-session number that this entry belongs to (usually 1)\n Point=0xa0 ;-point (0..63h=Track, non-BCD!) (A0h..XXh=specials) Q2\n ADR=0x01 ;-lower 4bit of ADR/Control (usually 1) Q0.lo\n Control=0x04 ;-upper 4bit of ADR/Control (eg. 0=audio, 4=data) Q0.hi\n TrackNo=0 ;-usually/always 0 (as [Entry N]'s are in Lead-in) Q1\n AMin=0 ;\\current MSF address Q3\n ASec=0 ; (dummy zero values) (actual content Q4\n AFrame=0 ; would be current lead-in position) Q5\n ALBA=-150 ;/ALBA=((AMin*60+ASec)*75+AFrame)-PreGapSize\n Zero=0 ;-probably reserved byte from Q channel Q6\n PMin=1 ;\\referenced MSF address (non-BCD!), for certain Q7\n PSec=32 ; Point's, PMin may contain a Track number, and PSec Q8\n PFrame=0 ; the disc type value (that without non-BCD-glitch) Q9\n PLBA=6750 ;/PLBA=((PMin*60+PSec)*75+PFrame)-PreGapSize\n MODE=2 ;-mode (0=Audio, 1=Mode1, 2=Mode2)\n ISRC=XXXXXNNNNNNN ;-12-letter/digit ISRC code (included only if present)\n INDEX 0=N ;-1st sector with index 0, missing EVEN if any?\n INDEX 1=N ;-1st sector with index 1, usually same as track's PLBA\n INDEX 2=N ;-1st sector with index 2, if any\n etc.\nThe .CCD file doesn't define the \"PreGapSize\" (the number of missing sectors at begin of first track). It seems to be simply constant \"PreGapSize=150\". Unless one is supposed to calculate it as \"PreGapSize=((PMin*60+PSec)*75+PFrame)-PLBA\". The SectorSize seems to be also constant, \"SectorSize=930h\".
"},{"location":"cdromfileformats/#non-bcd-caution","title":"Non-BCD Caution","text":"All Min/Sec/Frame/Track/Index values are expressed in non-BCD, ie. they must be converted to BCD to get the correct values (as how they are stored on real CDs). Exceptions are cases where those bytes have other meanings: For example, \"PSec=32\" does normally mean BcdSecond=32h, but for Point A0h it would mean DiscType=20h=CD-ROM-XA). The Point value is also special, it is expressed in hex (0xNN), but nonetheless it is non-BCD, ie. Point 1..99 are specified as 0x01..0x63, whilst, Point A0h..FFh are specified as such (ie. as 0xA0..0xFF).
"},{"location":"cdromfileformats/#versions","title":"Versions","text":"Version=1 doesn't seem to exist (or it is very rare). Version=2 is quite rare, and it seems to lack the [TRACK N] entries (meaning that there is no MODE and INDEX information, except that the INDEX 1 location can be assumed to be same as PLBA). Version=3 is most common, this version includes [TRACK N] entries, but often only with INDEX=1 (and up, if more indices), but without INDEX 0 (on Track 1 it's probably missing due to pregap, on further Tracks it's missing without reason) (so, only ways to reproduce INDEX=0 would be to guess it being located 2 seconds before INDEX=1, or, to use the information from the separate .SUB file, if that file is present; note: presence of index 0 is absolutely required for some games like PSX Tomb Raider 2).
"},{"location":"cdromfileformats/#entry-points-sessions","title":"Entry & Points & Sessions","text":"The [Entry N] fields are usually containing Point A0h,A1h,A2h, followed by Point 1..N (for N tracks). For multiple sessions: The session is terminated by Point B0h,C0h. The next session does then contain Point A0h,A1h,A2h, and Point N+1..X (for further tracks). The INDEX values in the [TRACK N] entries are originated at the begin of the corresponding session, whilst PLBA values in [Entry N] entries are always originated at the begin of the disk.
"},{"location":"cdromfileformats/#cdrom-disk-images-cdi-discjuggler","title":"CDROM Disk Images CDI (DiscJuggler)","text":""},{"location":"cdromfileformats/#overall-format","title":"Overall Format","text":" Sector Data (sector 00:00:00 and up) ;-body\n Number of Sessions (1 byte) <--- located at \"Filesize-Footersize\"\n Session Block for 1st session (15 bytes) ;\\\n nnn-byte info for 1st track ; 1st session\n nnn-byte info for 2nd track (if any) ;\n etc. ;/\n Session Block for 2nd session (15 bytes) ;\\\n nnn-byte info for 1st track ; 2nd session (if any)\n nnn-byte info for 2nd track (if any) ;\n etc. ;/\n etc. ;-further sessions (if any)\n Session Block for no-more-sessions (15 bytes) ;-end marker\n nnn-byte Disc Info Block ;-general disc info\n Entrypoint (4 bytes) <--- located at \"Filesize-4\"\nContains Sector Data for sector 00:00:00 and up (ie. all sectors are stored in the file, there are no missing \"pregap\" sectors). Sector Size can be 800h..990h bytes/sector (sector size may vary per track).
"},{"location":"cdromfileformats/#number-of-sessions-1-byte","title":"Number of Sessions (1 byte)","text":" 00h 1 Number of Sessions (usually 1)\n 00h 1 Unknown (00h)\n 01h 1 Number of Tracks in session (01h..63h) (or 00h=No More Sessions)\n 02h 7 Unknown (00h-filled)\n 09h 1 Unknown (01h)\n 0Ah 3 Unknown (00h-filled)\n 0Dh 2 Unknown (FFh,FFh)\n 00h 12 Unknown (FFh,FFh,00h,00h,01h,00h,00h,00h,FFh,FFh,FFh,FFh)\n 0Ch 3 Unknown (DAh,0Ah,D5h or 64h,05h,2Ah) (random/id/chksum?)\n 0Fh 1 Total Number of Tracks on Disc (00h..63h) (non-BCD)\n 10h 1 Length of below Path/Filename (F)\n 11h (F) Full Path/Filename (eg. \"C:\\folder\\file.cdi\")\n 11h+F 11 Unknown (00h-filled)\n 1Ch+F 1 Unknown (02h)\n 1Dh+F 10 Unknown (00h-filled)\n 27h+F 1 Unknown (80h)\n 28h+F 4 Unknown (00057E40h) (=360000 decimal) (disc capacity 80 minutes?)\n 2Ch+F 2 Unknown (00h,00h)\n 2Eh+F 2 Medium Type (0098h=CD-ROM, 0038h=DVD-ROM)\n 00h 30h+F Track/Disc Header (see above)\n 30h+F 02h Number of Indices (usually 0002h) (I=Num*4)\n 32h+F (I) 32bit Lengths (per index) (eg. 00000096h,00007044h)\n 32h+FI 04h Number of CD-Text blocks (usually 0) (T=Num*18+VariableLen's)\n 36h+FI (T) CD-Text (if any) (see \"mirage_parser_cdi_parse_cdtext\")\n 36h+FIT 02h Unknown (00h,00h)\n 38h+FIT 01h Track Mode (0=Audio, 1=Mode1, 2=Mode2/Mixed)\n 39h+FIT 07h Unknown (00h,00h,00h,00h,00h,00h,00h)\n 40h+FIT 04h Session Number (starting at 0) (usually 00h)\n 44h+FIT 04h Track Number (non-BCD, starting at 0) (00h..62h)\n 48h+FIT 04h Track Start Address (eg. 00000000h)\n 4Ch+FIT 04h Track Length (eg. 000070DAh)\n 50h+FIT 0Ch Unknown (00h-filled)\n 5Ch+FIT 04h Unknown (00000000h or 00000001h)\n 60h+FIT 04h read_mode (0..4)\n 0: Mode1, 800h, 2048\n 1: Mode2, 920h, 2336\n 2: Audio, 930h, 2352\n 3: Raw+PQ, 940h, 2352+16 non-interleaved (P=only 1bit)\n 4: Raw+PQRSTUVW, 990h, 2352+96 interleaved\n 64h+FIT 4 Control (Upper 4bit of ADR/Control, eg. 00000004h=Data)\n 68h+FIT 1 Unknown (00h)\n 69h+FIT 4 Track Length (eg. 000070DAh) (same as above)\n 6Dh+FIT 4 Unknown (00h,00h,00h,00h)\n 71h+FIT 12 ISRC Code 12-letter/digit (ASCII?) string (00h-filled if none)\n 7Dh+FIT 4 ISRC Valid Flag (0=None, Other?=Yes?)\n 81h+FIT 1 Unknown (00h)\n 82h+FIT 8 Unknown (FFh,FFh,FFh,FFh,FFh,FFh,FFh,FFh)\n 8Ah+FIT 4 Unknown (00000001h)\n 8Eh+FIT 4 Unknown (00000080h)\n 92h+FIT 4 Unknown (00000002h) (guess: maybe audio num channels??)\n 96h+FIT 4 Unknown (00000010h) (guess: maybe audio bits/sample??)\n 9Ah+FIT 4 Unknown (0000AC44h) (44100 decimal, ie. audio sample rate?)\n 9Eh+FIT 2Ah Unknown (00h-filled)\n C8h+FIT 4 Unknown (FFh,FFh,FFh,FFh)\n CCh+FIT 12 Unknown (00h-filled)\n D8h+FIT 1 session_type ONLY if last track of a session (else 0)\n (0=Audio/CD-DA, 1=Mode1/CD-ROM, 2=Mode2/CD-XA)\n D9h+FIT 5 Unknown (00h-filled)\n DEh+FIT 1 Not Last Track of Session Flag (0=Last Track, 1=Not Last)\n DFh+FIT 1 Unknown (00h)\n E0h+FIT 4 address for last track of a session? (otherwise 00,00,FF,FF)\n 00h 30h+F Track/Disc Header (see above)\n 30h+F 4 Disc Size (total number of sectors)\n 34h+F 1 Volume ID Length (V) ;\\from Primary Volume Descriptor[28h..47h]\n 35h+F (V) Volume ID String ;/(ISO Data discs) (unknown for Audio)\n 35h+FV 1 Unknown (00h)\n 36h+FV 4 Unknown (01h,00h,00h,00h)\n 3Ah+FV 4 Unknown (01h,00h,00h,00h)\n 3Eh+FV 13 EAN-13 Code 13-digit (ASCII?) string (00h-filled if none)\n 4Bh+FV 4 EAN-13 Valid Flag (0=None, Other?=Yes?)\n 4Fh+FV 4 CD-Text Length in bytes (T=Num*1)\n 53h+FV (T) CD-Text (for Lead-in) (probably 18-byte units?)\n 53h+FVT 8 Unknown (00h-filled)\n 5Bh+FVT 4 Unknown (06h,00h,00h,80h)\n 00h 4 Footer Size in bytes\nCDRWIN stores disk images in two separate files. The .BIN file contains the raw disk image, starting at sector 00:02:00, with 930h bytes per sector, but without any TOC or subchannel information. The .CUE file contains additional information about the separate track(s) on the disk, in ASCII format, for example:
FILE \"PATH\\FILENAME.BIN\" BINARY\n TRACK 01 MODE2/2352\n INDEX 01 00:00:00 ;real address = 00:02:00 (+2 seconds)\n TRACK 02 AUDIO\n PREGAP 00:02:00 ;two missing seconds (NOT stored in .BIN)\n INDEX 01 08:09:29 ;real address = 08:13:29 (+2 seconds +pregap)\n TRACK 03 AUDIO\n INDEX 00 14:00:29 ;real address = 14:04:29 (+2 seconds +pregap)\n INDEX 01 14:02:29 ;real address = 14:06:29 (+2 seconds +pregap)\n TRACK 04 AUDIO\n INDEX 00 18:30:20 ;real address = 18:34:20 (+2 seconds +pregap)\n INDEX 01 18:32:20 ;real address = 18:36:20 (+2 seconds +pregap)\n (must appear before any other commands, except CATALOG)\n (uh, may also appear before further tracks)\n AUDIO ;930h ;bytes 000h..92Fh\n CDG ;? ;?\n MODE1/2048 ;800h ;bytes 010h..80Fh\n MODE1/2352 ;930h ;bytes 000h..92Fh\n MODE2/2336 ;920h ;bytes 010h..92Fh\n MODE2/2352 ;930h ;bytes 000h..92Fh\n CDI/2336 ;920h ;?\n CDI/2352 ;930h ;bytes 000h..92Fh\nDuration of silence at the begin (PREGAP) or end (POSTGAP) of a track. Even if it isn't specified, the first track will always have a 2-second pregap. The gaps are NOT stored in the BIN file.
"},{"location":"cdromfileformats/#rem-comment","title":"REM comment","text":"Allows to insert comments/remarks (which are usually ignored). Some third-party tools are mis-using REM to define additional information.
"},{"location":"cdromfileformats/#catalog-1234567890123","title":"CATALOG 1234567890123","text":""},{"location":"cdromfileformats/#isrc-abcde1234567","title":"ISRC ABCDE1234567","text":" (ISRC must be after TRACK, and before INDEX)\nThese entries allow to define basic CD-Text info directly in the .CUE file. Some third-party utilites allow to define additional CD-Text info via REM lines, eg. \"REM GENRE Rock\". Alternately, more complex CD-Text data can be stored in a separate .CDT file.
"},{"location":"cdromfileformats/#cdtextfile-clong-filenamecdt","title":"CDTEXTFILE \"C:\\LONG FILENAME.CDT\"","text":"Specifies an optional file which may contain CD-TEXT. The .CDT file consists of raw 18-byte CD-TEXT fragments (which may include any type of information, including exotic one's like a \"Message\" from the producer). For whatever reason, there's a 00h-byte appended at the end of the file. Alternately to the .CDT file, the less exotic types of CD-TEXT can be defined by PERFORMER, TITLE, and SONGWRITER commands in the .CUE file.
"},{"location":"cdromfileformats/#missing","title":"Missing","text":"Unknown if newer CUE/BIN versions do also support subchannel data.
"},{"location":"cdromfileformats/#malformed-cue-files","title":"Malformed .CUE files","text":"Some .CCD files are bundled with uncommon/corrupted .CUE files, with entries as so:
TRACK 1 MODE2/2352 ;three spaces indent, and 1-digit track\n INDEX 1 00:00:00 ;three spaces indent, and 1-digit index\n TRACK 01 MODE2/2352 ;two spaces indent, and 2-digit track\n INDEX 01 00:00:00 ;four spaces indent, and 2-digit index\nContains the sector data, recorded at 800h..930h bytes per sector, optionally followed by 60h bytes subchannel data (appended at the end of each sector). The stuff seems to be start on 00:02:00 (ie. the first 150 sectors are missing; at least it is like so when \"Session Start Sector\" is -150). The subchannel data (if present) consists of 8 subchannels, stored in 96 bytes (each byte containing one bit per subchannel).
Bit7..0 = Subchannel P..W (in that order, eg. Bit6=Subchannel Q)\n 1st..8th bit = Bit7..Bit0 of 1st byte (in that order, ie. MSB/Bit7 first)\n 9st..16th bit = Bit7..Bit0 of 2nd byte (\"\")\n 17th.. = etc.\nAn MDS file's structure consists of the following stuff ...
Header (58h bytes)\n Session block(s) (usually one 18h byte entry)\n Data blocks (N*50h bytes)\n Index blocks (usually N*8 bytes)\n Filename blocks(s) (usually one 10h byte entry)\n Filename string(s) (usually one 6 byte string)\n Read error(s) (usually none such)\n 00h 16 File ID (\"MEDIA DESCRIPTOR\")\n 10h 2 Unknown (01h,03h or 01h,04h or 01h,05h) (Fileformat version?)\n 12h 2 Media Type (0=CD-ROM, 1=CD-R, 2=CD-RW, 10h=DVD-ROM, 12h=DCD-R)\n 14h 2 Number of sessions (usually 1)\n 16h 4 Unknown (02h,00h,00h,00h)\n 1Ah 2 Zero (for DVD: Length of BCA data)\n 1Ch 8 Zero\n 24h 4 Zero (for DVD: Offset to BCA data)\n 28h 18h Zero\n 40h 4 Zero (for DVD: Offset to Disc Structures) (from begin of .MDS file)\n 44h 0Ch Zero\n 50h 4 Offset to First Session-Block (usually 58h) (from begin of .MDS file)\n 54h 4 Offset to Read errors (usually 0=None) (from begin of .MDS file)\n 00h 4 Session Start Sector (starting at FFFFFF6Ah=-150 in first session)\n 04h 4 Session End Sector (XXX plus 150 ?)\n 08h 2 Session number (starting at 1) (non-BCD)\n 0Ah 1 Number of Data Blocks with any Point value (Total Data Blocks)\n 0Bh 1 Number of Data Blocks with Point>=A0h (Special Lead-In info)\n 0Ch 2 First Track Number in Session (01h..63h, non-BCD!)\n 0Eh 2 Last Track Number in Session (01h..63h, non-BCD!)\n 10h 4 Zero\n 14h 4 Offset to First Data-Block (usually 70h) (from begin of .MDS file)\nBlock 0..2 are usually containing Point A0h..A2h info. Block 3..N are usually TOC info for Track 1 and up.
00h 1 Track mode (see below for details)\n 01h 1 Number of subchannels in .MDF file (0=None, 8=Sector has +60h bytes)\n 02h 1 ADR/Control (but with upper/lower 4bit swapped, ie. MSBs=ADR!) Q0\n 03h 1 TrackNo (usually/always 00h; as this info is in Lead-in area) Q1\n 04h 1 Point (Non-BCD!) (Track 01h..63h) (or A0h and up=Lead-in info) Q2\n 05h 4 Zero (probably dummy MSF and reserved byte from Q channel) Q3..Q6?\n 09h 1 Minute (Non-BCD!) ;\\MM:SS:FF of Point'ed track Q7\n 0Ah 1 Second (Non-BCD!) ; (or disc/lead-out info when Point>=A0h) Q8\n 0Bh 1 Frame (Non-BCD!) ;/ Q9\n 0Ch 4 Offset to Index-block for this track (from begin of .MDS file)\n 10h 2 Sector size (800h..930h) (or 860h..990h if with subchannels)\n 12h 1 Unknown (02h) (maybe number of indices?)\n 13h 11h Zero\n 24h 4 Track start sector, PLBA (00000000h=00:02:00)(or 00000096h=00:02:00?)\n 28h 8 Track start offset (from begin of .MDF file)\n 30h 4 Number of Filenames for this track (usually 1)\n 34h 4 Offset to Filename Block for this track (from begin of .MDS file)\n 38h 18h Zero\n (upper 4bit seem to be meaningless?)\n 00h=None (used for entries with Point=A0h..FF)\n A9h=AUDIO ;sector size = 2352 930h ;bytes 000h..92Fh\n AAh=MODE1 ;sector size = 2048 800h ;bytes 010h..80Fh\n ABh=MODE2 ;sector size = 2336 920h ;bytes 010h..92Fh\n ACh=MODE2_FORM1 ;sector size = 2048 800h ;bytes 018h..817h (incomplete!)\n ADh=MODE2_FORM2 ;sector size = 2324+0? 914h ;bytes 018h..91Bh (incomplete!)\n ADh=MODE2_FORM2 ;sector size = 2324+4? 918h ;bytes ??..?? (contains what?)\n ECh=MODE2 ;sector size = 2448 990h ;(930h+60h) (with subchannels)\n 00h 4 Number of sectors with Index 0 (usually 96h or zero)\n 04h 4 Number of sectors with Index 1 (usually size of main-track area)\n 00h 4 Offset to Filename (from begin of .MDS file)\n 04h 1 Filename format (0=8bit, 1=16bit characters)\n 05h 11 Zero\n 00h 6 Filename, terminated by zero (usually \"*.mdf\",00h)\n 00h 4 Unknown (1)\n 04h 4 Offset to following stuff\n 08h 4 Unknown (2)\n 0Ch 4 Unknown (7)\n 10h 4 Unknown (1)\n 14h 4 Number of read errors (E)\n 18h E*4 LBA's for sectors with read errors (0 and up)\nUnknown if/how this format supports EAN-13, ISRC, CD-TEXT.
"},{"location":"cdromfileformats/#cdrom-disk-images-nrg-nero","title":"CDROM Disk Images NRG (Nero)","text":""},{"location":"cdromfileformats/#nrg-nero","title":".NRG (NERO)","text":"Nero is probably the most bloated and most popular CD recording software. The first part of the file contains the disk image, starting at sector 00:00:00, with 800h..930h bytes per sector. Additional chunk-based information is appended at the end of the file, usually consisting of only four chunks: CUES,DAOI,END!,NERO (in that order).
"},{"location":"cdromfileformats/#chunk-entrypoint-in-last-812-bytes-of-file","title":"Chunk Entrypoint (in last 8/12 bytes of file)","text":" 4 File ID \"NERO\"/\"NER5\"\n 4/8 Fileoffset of first chunk\n 4 Chunk ID \"CUES\"/\"CUEX\"\n 4 Chunk size (bytes)\n 1 ADR/Control from TOC (usually LSBs=ADR=1=fixed, MSBs=Control=Variable)\n 1 Track (BCD) (00h=Lead-in, 01h..99h=Track N, AAh=Lead-out)\n 1 Index (BCD) (usually 00h=pregap, 01h=actual track)\n 1 Zero\n 1 Zero\n 1 Minute (BCD) ;starting at 00:00:00 = 2 seconds before ISO vol. descr.\n 1 Second (BCD)\n 1 Sector (BCD)\n 4 Logical Sector Number (HEX) ;starting at FFFFFF6Ah (=00:00:00)\n 4 Chunk ID \"DAOI\"/\"DAOX\"\n 4 Chunk size (bytes)\n 4 Garbage (usually same as above Chunk size)\n 13 EAN-13 Catalog Number (13-digit ASCII) (or 00h-filled if none/unknown)\n 1 Zero\n 1 Disk type (00h=Mode1 or Audio, 20h=XA/Mode2) (and probably 10h=CD-I?)\n 1 Unknown (01h)\n 1 First track (Non-BCD) (01h..63h)\n 1 Last track (Non-BCD) (01h..63h)\n 12 ISRC in ASCII (eg. \"USXYZ9912345\") (or 00h-filled if none/unknown)\n 2 Sector size (usually 800h, 920h, or 930h) (see Mode entry for more info)\n 1 Mode:\n 0=Mode1/800h ;raw mode1 data (excluding sync+header+edc+errorinfo)\n 3=Mode2/920h ;almost full sector (exluding first 16 bytes; sync+header)\n 6=Mode2/930h ;full sector (including first 16 bytes; sync+header)\n 7=Audio/930h ;full sector (plain audio data)\n Mode values from wikipedia:\n 00h for data Mode1/800h\n 02h\n 03h for Mode 2 Form 1 data eh? FORM1??? Mode2/920h\n 05h for raw data Mode1?/930h\n 06h for raw Mode 2/form 1 data Mode2/930h\n 07h for audio Audio/930h\n 0Fh for raw data with sub-channel Mode1?/930h+WHAT?\n 10h for audio with sub-channel Audio/930h+WHAT?\n 11h for raw Mode 2/form 1 data with sub-channel Mode2/WHAT?+WHAT?\n Note: Some newer files do actually use different sector sizes for each\n track (eg. 920h for the data track, and 930h for any following audio\n tracks), older files were using the same sector size for all tracks\n (eg. if the disk contained 930-byte Audio tracks, then Data tracks\n were stored at the same size, rather than at 800h or 920h bytes).\n 3 Unknown (always 00h,00h,01h)\n 4/8 Fileoffset 1 (Start of Track's Pregap) (with Index=00h)\n 4/8 Fileoffset 2 (Start of actual Track) (with Index=01h and up)\n 4/8 Fileoffset 3 (End of Track) (aka begin of next track's pregap)\n 4 Chunk ID \"END!\"\n 4 Chunk size (always zero)\n 4 Chunk ID \"TINF\"/\"ETNF\"/\"ETN2\"\n 4 Chunk size (bytes)\n 4/4/8 Track fileoffset ;\\32bit in TINF/ETNF chunks,\n 4/4/8 Track length (bytes) ;/64bit in ETN2 chunks\n 4 Mode (should be same as in DAO chunks, see there) (implies sector size)\n 0/4/4 Start lba on disc ;\\only in ETNF/ETN2 chunks,\n 0/4/4 Unknown? ;/not in TINF chunks\n 4 Chunk ID \"RELO\"\n 4 Chunk size (bytes)\n 4 Zero\n 4 Chunk ID \"TOCT\"\n 4 Chunk size (bytes)\n 1 Disk type (00h=Mode1 or Audio, 20h=XA/Mode2) (and probably 10h=CD-I?)\n 1 Zero (00h)\n 4 Chunk ID \"SINF\"\n 4 Chunk size (bytes)\n 4 Number of tracks in session\n 4 Chunk ID None/\"CDTX\"\n 4 Chunk size (bytes) (must be a multiple of 18 bytes)\n 18 Raw 18-byte CD-text data fragments\n 4 Chunk ID \"MTYP\"\n 4 Chunk size (bytes)\n 4 Unknown? (00000001h for CDROM) (maybe other value for DVD)\n 4 Chunk ID \"AFNM\"\n 4 Chunk size (bytes)\n .. Track Filenames (eg. \"Track1.wav\",0,\"Track2.wav\",0)\n 4 Chunk ID \"VOLM\"\n 4 Chunk size (bytes)\n .. Name (eg. \"Audio CD\",00h)\nNewer/older .NRG files may contain 32bit/64bit values (and use \"OLD\"/\"NEW\" chunk names) (as indicated by the \"/\" slashes). CAUTION: All 16bit/32bit/64bit values are in big endian byte-order.
"},{"location":"cdromfileformats/#missing_2","title":"Missing","text":"Unknown if newer NRG versions do also support subchannel data.
"},{"location":"cdromfileformats/#cdrom-disk-imagecontainers-cdz","title":"CDROM Disk Image/Containers CDZ","text":".CDZ is a compressed disk image container format (developed by pSX Author, and used only by the pSX emulator). The disk is split into 64kbyte blocks, which allows fast random access (without needing to decompress all preceeding sectors). However, the compression ratio is surprisingly bad (despite of being specifically designed for cdrom compression, the format doesn't remove redundant sector headers, error correction information, and EDC checksums).
"},{"location":"cdromfileformats/#cdz-file-structure","title":".CDZ File Structure","text":" FileID (\"CDZ\",00h for cdztool v0/v1, or \"CDZ\",01h for cdztool v2 and up)\n One or two Chunk(s)\nChunk Header in v0 (unreleased prototype):
4 32bit Decompressed Size (of all blocks) (must be other than \"ZLIB\")\n 4 ZLIB ID (\"ZLIB\")\n 8 64bit Decompressed Size (of all blocks)\n 4 Chunk ID (eg. \"CUE\",00h)\n 8 Chunk Size in bytes (starting at \"ZLIB\" up to including Footer, if any)\n 4 ZLIB ID (\"ZLIB\")\n 8 64bit Decompressed Size (of all blocks)\n 4 Number of Blocks (N)\n 4 Block 1 Compressed Size (CS.1)\n 4 Block 1 Decompressed Size (always 00010000h, except last block)\n CS.1 Block 1 Compressed ZLIB Data (starting with 78h,9Ch)\n ... ... ;\\\n 4 Block N Compressed Size (CS.N) ; further block(s)\n 4 Block N Decompressed Size ; (if any)\n CS.N Block N Compressed ZLIB Data ;/\n 4*N Directory Entries for N blocks ;-this ONLY for BIN chunk\n BPD*(N-1) Directory Entries for N-1 blocks ;\\this ONLY for BIN chunk\n 1 Bytes per Directory Entry (BPD) ;/(not for CUE/CCD/MDS)\nThe chunk(s) have following content:
noname+noname --> .CUE+.BIN (cdztool v1 and below)\n \"BIN\",0 --> .ISO (cdztool v2? and up)\n \"CUE\",0+\"BIN\",0 --> .CUE+.BIN (cdztool v2 and up)\n \"CCD\",0+\"BIN\",0 --> .CCD+.IMG (cdztool v2 and up)\n \"CCD\",0+\"BIN\",01h --> .CCD+.IMG+.SUB (930h sectors, plus 60h subchannels)\n \"MDS\",0+\"BIN\",0 --> .MDS+.MDF (cdztool v5 only)\n cdztool.exe v0, unrelased prototype\n cdztool.exe v1, 22 May 2005, CRC32=620dbb08, 102400 bytes, pSX v1.0-5\n cdztool.exe v2, 02 Jul 2006, CRC32=bcb29c1e, 110592 bytes, pSX v1.6\n cdztool.exe v3, 22 Jul 2006, CRC32=4062ba82, 110592 bytes, pSX v1.7\n cdztool.exe v4, 13 Aug 2006, CRC32=7388dd3d, 118784 bytes, pSX v1.8-11\n cdztool.exe v5, 22 Jul 2007, CRC32=f25c1659, 155648 bytes, pSX v1.12-13\nECM (Error Code Modeler by Neill Corlett) is a utility that removes unneccessary ECC error correction and EDC error detection values from CDROM-images. This is making the images a bit smaller, but the real size reduction isn't gained until subsequently compressing the images via tools like ZIP. Accordingly, these files are extremly uncomfortable to use: One most first UNZIP them, and then UNECM them.
"},{"location":"cdromfileformats/#extecm-double-extension","title":".EXT.ECM - Double extension","text":"ECM can be applied to various CDROM-image formats (like .BIN, .CDI, .IMG, .ISO, .MDF, .NRG), as indicated by the double-extension. Most commonly it's applied to .BIN files (hence using extension .BIN.ECM).
"},{"location":"cdromfileformats/#example-file-structure","title":"Example / File Structure","text":" 45 43 4D 00 ;FileID \"ECM\",00h\n 3C ;Type 0, Len=10h (aka 0Fh+1)\n 00 FF FF FF FF FF FF FF FF FF FF 00 00 02 00 02 ;16 data bytes\n 02 ;Type 2, Len=1 (aka 00h+1)\n 00 00 08 00 00 00 00 00 00 00 00 ..... 00 00 00 ;804h data bytes\n 3C ;Type 0, Len=10h (aka 0Fh+1)\n 00 FF FF FF FF FF FF FF FF FF FF 00 00 02 01 02 ;16 data bytes\n 02 ;Type 2, Len=1 (aka 00h+1)\n 00 00 08 00 00 00 00 00 00 00 00 ..... 00 00 00 ;804h data bytes\n ...\n FC FF FF FF 3F ;End Code (Len=FFFFFFFFh+1)\n NN NN NN NN ;EDC (on decompressed data)\nType/Length is encoded in 1..5 byte(s), with \"More=1\" indicating that further length byte(s) follow:
1st Byte: Bit7=More, Bit6-2=LengthBit4-0, Bit1-0=Type(0..3)\n 2nd Byte: Bit7=More, Bit6-0=LengthBit5-11\n 3rd Byte: Bit7=More, Bit6-0=LengthBit12-18\n 4th Byte: Bit7=More, Bit6-0=LengthBit19-25\n 5th Byte: Bit7-6=Reserved/Zero, Bit5-0=LengthBit26-31\nBelow is repeated LEN times (with LEN being the Length value plus 1):
Type 0: load 1 byte, save 1 byte\n Type 1: load 803h bytes [0Ch..0Eh,10h..80Fh], save 930h bytes [0..92Fh]\n Type 2: load 804h bytes [14h..817h], save 920h bytes [10h..92Fh]\n Type 3: load 918h bytes [14h..91Bh], save 920h bytes [10h..92Fh]\nThere's a lot of wrong with the ECM format. The two central problems are that it doesn't support data-compression (and needs external compression tools like zip/rar), and, that it doesn't contain a sector look-up table (meaning that random access isn't possible unless when scanning the whole file until reaching the desired sector).
"},{"location":"cdromfileformats/#worst-case-scenario","title":"Worst-case Scenario","text":"As if ECM as such wouldn't be uncomfortable enough, you may expect typical ECM users to get more things messed up. For example:
A RAR file containing a 7Z file containing a ECM file containing a BIN file.\n The BIN containing only Track 1, other tracks stored in APE files.\n And, of course, the whole mess without including the required CUE file.\nSBI Files start with a 4-byte FileID:
4 bytes FileID (\"SBI\",00h)\n 3 bytes real absolute MM:SS:FF address where the sub q data was bad\n 1 byte Format: the format can be 1, 2 or 3:\n Format 1: complete 10 bytes sub q data (Q0..Q9)\n Format 2: 3 bytes wrong relative MM:SS:FF address (Q3..Q5)\n Format 3: 3 bytes wrong absolute MM:SS:FF address (Q7..Q9)\nM3S files are containing Subchannel Q data for all sectors on Minute=03 (the region where PSX libcrypt data is located) (there is no support for storing the (unused) libcrypt backup copy on Minute=09). The .M3S filesize is 72000 bytes (60 seconds * 75 sectors * 16 bytes). The 16 bytes per sector are:
Q0..Q9 Subchannel Q data (normally position data)\n Q10..Q11 Subchannel Q checksum\n Q12..Q15 Dummy/garbage/padding (usually 00000000h or FFFFFFFFh)\n 1. With CRC (Q0..Q11 intact) (and Q12..Q15 randomly 00000000h or FFFFFFFFh)\n 2. Without CRC (only Q0..Q9 intact, but Q10..Q15 zerofilled)\n 3. Without anything (only Q0 intact, but Q1..Q15 zerofilled)\nMost CDROM-Image formats can (optionally) contain subchannel recordings. The downsides are: Storing all 8 subchannels for a full CDROM takes up about 20MBytes. And, some entries may contain 'wrong' data (read errors caused by scratches cannot be automatically repaired since subchannels do not contain error correction info). If present, the subchannel data is usually appended at the end of each sector in the main binary file (one exception is CloneCD, which stores it in a separate .SUB file instead of in the .IMG file).
CCD/IMG/SUB (CloneCD) P-W 60h-bytes Non-interleaved (in separate .SUB file)\n CDI (DiscJuggler) P-Q 10h-bytes Non-interleaved (in .CDI file)\n \"\" P-W 60h-bytes Interleaved (in .CDI file)\n CUE/BIN/CDT (Cdrwin) N/A\n ISO (single-track) N/A\n MDS/MDF (Alcohol 120%) P-W 60h-bytes Interleaved (in .MDF file)\n NRG (Nero) P-W 60h-bytes Interleaved (in .NRG file)\n 00h-07h 80 C0 80 80 80 80 80 C0 ;P=FFh, Q=41h=ADR/Control, R..W=00h\n 08h-0Fh 80 80 80 80 80 80 80 C0 ;P=FFh, Q=01h=Track, R..W=00h\n 10h-17h 80 80 80 80 80 80 80 C0 ;P=FFh, Q=01h=Index, R..W=00h\n 18h-1Fh 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=RelMinute, R..W=00h\n 20h-27h 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=RelSecond, R..W=00h\n 28h-2Fh 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=RelSector, R..W=00h\n 30h-37h 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=Reserved, R..W=00h\n 38h-3Fh 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=AbsMinute, R..W=00h\n 40h-47h 80 80 80 80 80 80 C0 80 ;P=FFh, Q=02h=AbsSecond, R..W=00h\n 48h-4Fh 80 80 80 80 80 80 80 80 ;P=FFh, Q=00h=AbsSector, R..W=00h\n 50h-57h 80 80 C0 80 C0 80 80 80 ;P=FFh, Q=28h=ChecksumMsb, R..W=00h\n 58h-5Fh 80 80 C0 C0 80 80 C0 80 ;P=FFh, Q=32h=ChecksumLsb, R..W=00h\n 00h-0Bh FF FF FF FF FF FF FF FF FF FF FF FF ;Subchannel P (Pause)\n 0Ch-17h 41 01 01 00 00 00 00 00 02 00 28 32 ;Subchannel Q (Position)\n 18h-23h 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel R\n 24h-2Fh 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel S\n 30h-3Bh 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel T\n 3Ch-47h 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel U\n 48h-53h 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel V\n 54h-5Fh 00 00 00 00 00 00 00 00 00 00 00 00 ;Subchannel W\n This is probably based on MMC protocol, which would be as crude as this:\n The 96 pause bits are summarized in 1 bit. Pause/Checksum are optional.\n 00h-09h 41 01 01 00 00 00 00 00 02 00 ;Subchannel Q (Position)\n 0Ah-0Bh 28 32 ;<-- OPTIONAL, can be zero! ;Subchannel Q (Checksum)\n 0Ch-0Eh 00 00 00 ;Unused padding (zero)\n 0F 80 ;<-- OPTIONAL, can be zero! ;Subchannel P (Bit7=Pause)\nSony's disc image format used on PSP. Can store multi-disc images in a single file. Supports deflate data compression and some yet unknown audio compression. A homebrew compressor can compress whole discs with deflate (which works, but it isn't very good to compress audio sectors that way).
"},{"location":"cdromfileformats/#pbp-format-rev-engineered-from-homebrew-dballpbp","title":"PBP Format (rev-engineered from homebrew DBALL.PBP)","text":" 000000h 4 ID (00h,\"PBP\")\n 000004h 4 Version? (10000h) (but, reportedly \"always 100h or 1000100h\")\n 000008h 4 Offset of the file PARAM.SFO (28h)\n 00000Ch 4 Offset of the file ICON0.PNG (3D8h)\n 000010h 4 Offset of the file ICON1.PMF (3D8h) or ICON1.PNG\n 000014h 4 Offset of the file PIC0.PNG (3D8h) or UNKNOWN.PNG\n 000018h 4 Offset of the file PIC1.PNG (3D8h) or PICT1.PNG\n 00001Ch 4 Offset of the file SND0.AT3 (3D8h)\n 000020h 4 Offset of the file DATA.PSP (3D8h)\n 000024h 4 Offset of the file DATA.PSAR (10000h)\n 000028h .. PARAM.SFO file (zerofilled in homebrew PBP)\n 0003D8h .. PNG files etc (zerofilled in homebrew PBP)\n 010000h 0Ch ID \"PSISOIMG0000\"\n 01000Ch 4 PBP Size-10000h (144740h)\n 010010h 4 PBP Size-6420h (???) (14E320h)\n 010014h .. Zerofilled\n 010400h 0Bh Game ID (\"_SCUS_94476\" for Hot Shots Golf 2)\n 01040Bh .. Zerofilled\n 010800h A00h TOC List (0Ah-byte per entry) (unused entries are zerofilled)\n 011200h 20h Zerofilled\n 011220h 4 PBP Size-D2CFh (???) (147471h)\n 011224h 4 Zero\n 011228h 4 Unknown (7FFh)\n 01122Ch 11h Game Name (\"Hot Shots Golf\",C2h,AEh,\"2\")\n 01123Dh .. Zerofilled\n 014000h .. Sector List (20h-byte per entry) (unused entries are zerofilled)\n ... .. Zerofilled\n 110000h .. Deflated sectors (9300h bytes after decompression)\n 15467Dh B8h One extra compression block that is NOT in Sector List ???\n 154735h 0Bh Weird padding with ASCII \"00000000000\"\n 154740h - End of file\n TOC List (Subchannel Q with ADR=1 during Lead-In):\n 000h 1 ADR/Control (eg. 41h=Data Track)\n 001h 1 Track (always 00h=Lead-in for all TOC List entries)\n 002h 1 Point (A0h, A1h, A2h, or Track 01h and up) (BCD?)\n 003h 3 Dummy MSF (usually 00:00:00 or weirdly 00:02:01) (BCD?)\n 006h 1 Reserved (00h)\n 007h 3 Actual MSF (or TOC info for Point=A0h,A1h) (BCD?)\n Example TOC (DBALL.PBP):\n 41 00 A0 00 00 00 00 01 20 00 ;First Track (1) and Type (20h=CDROM-XA)\n 41 00 A1 00 00 00 00 01 00 00 ;Last Track Number (1)\n 41 00 A2 00 00 00 00 27 19 22 ;Lead-Out, uh at 27:19:22 in DBALL.PBP ???\n 41 00 01 00 02 01 00 00 02 00 ;Track 1 at 00:02:00\n (remaining entries are zerofilled)\n Example TOC (PSALM69.PBP):\n 01 00 01 00 02 00 00 00 00 00 ;Track 1 as audio <-- why that ???\n 01 00 02 02 37 44 00 00 00 00 ;Track 2 as audio\n 01 00 03 03 25 45 00 00 00 00 ;Track 3 as audio\n 41 00 01 00 02 01 00 00 02 00 ;Track 1 as data <-- listed last?\n (remaining entries are zerofilled)\n (weirdly, most MM:SS:FF values are stored in byte[3..5] instead [7..9])\n (there are no point=A0h,A1h,A2h entries)\n Example TOC (GOOGLE_AI_TTS.PBP):\n 01 00 01 00 02 00 00 00 00 00 ;Track 1 as audio\n 01 00 02 00 02 30 00 00 00 00 ;Track 2 as audio, but without pregap?\n 01 00 03 00 02 60 00 00 00 00 ;Track 3 as audio, but without pregap?\n 01 00 04 00 03 15 00 00 00 00 ;Track 4 as audio, but without pregap?\n (remaining entries are zerofilled)\n Sector List:\n 000h 4 Offset-110000h to Sector(N*10h)\n 004h 2 Compressed size of Sector(N*10h+(0..0Fh)) ;9300h=uncompressed?\n 006h 2 Zero (but, reportedly \"usually 1... and 0 for the last entry\")\n 008h 10h Zero (but, reportedly \"first 10h bytes of SHA1 sum of 10h sectors\")\n 018h 8 Zero (padding)\n ?\n ?\n ?\nAll numbers are stored in Motorola (big-endian) byte ordering.
"},{"location":"cdromfileformats/#v1v2-header-hdcomp","title":"V1/V2 header (hdcomp):","text":"V1/V2 contains harddisk related header entries (and apparently does't support cdroms).
000h 08h ID \"MComprHD\" (MAME Compressed Hunks of Data)\n 008h 4 Header size (4Ch=V1, 50h=V2)\n 00Ch 4 Header version (probably 01h=V1, 02h=V2)\n 010h 4 Flags (bit0=DriveHasParent, bit1=AllowWrites)\n 014h 4 Compression type (0=None, 1=ZLIB)\n 018h 4 Number of sectors per hunk\n 01Ch 4 Total number of hunks represented\n 020h 4 Number of cylinders on hard disk\n 024h 4 Number of heads on hard disk\n 028h 4 Number of sectors on hard disk\n 02Ch 10h MD5 checksum on raw data\n 03Ch 10h MD5 checksum on parent file\n N/A - V1: Uses fixed 200h-byte Sector size\n 04Ch (4) V2: Number of bytes per sector\n ... ? Supposedly followed by map and/or data at whatever locations\nV3/V4 are inventing new \"metadata\" for info about harddisks or cdroms.
000h 08h ID \"MComprHD\" (MAME Compressed Hunks of Data)\n 008h 4 Header size (78h=V3, 6Ch=V4)\n 00Ch 4 Header version (03h=V3, 04h=V4)\n 010h 4 Flags (bit0=DriveHasParent, bit1=AllowWrites)\n 014h 4 Compression type (0=None, 1=ZLIB, 2=ZLIB_PLUS) (V4: 3=AV)\n 018h 4 Total number of hunks represented (N) (92h)\n 01Ch 08h Total size of all uncompressed hunks (N*2640h) (15D080h)\n 024h 08h Offset to the first blob of metadata\n 02Ch 10h V3: MD5 checksum on raw data ;\\\n 03Ch 10h V3: MD5 checksum on parent file ;\n 04Ch 4 V3: Number of bytes per hunk (2640h=990h*4) ; V3\n 050h 14h V3: SHA1 checksum on raw data ;\n 064h 14h V3: SHA1 checksum on parent file ;/\n 02Ch 4 V4: Number of bytes per hunk (2640h=990h*4) ;\\\n 030h 14h V4: SHA1 checksum on raw+meta ; V4\n 044h 14h V4: SHA1 checksum on raw+meta of parent ;\n 058h 14h V4: SHA1 checksum on raw data ;/\n ... N*10h Map entries (for each hunk)\n ... 10h Map end marker (\"EndOfListCookie\",00h)\n ... .. Metadata Chunk(s)\n ... .. Compressed Sectors (aka hunks)\n 000h 8 ID \"MComprHD\" (MAME Compressed Hunks of Data)\n 008h 4 Header size (7Ch=V5)\n 00Ch 4 Header version (05h=V5)\n 010h 4 Compressor 0 (usually \"cdlz\"=cdrom/lzma)\n 014h 4 Compressor 1 (usually \"cdzl\"=cdrom/zlib)\n 018h 4 Compressor 2 (usually \"cdfl\"=cdrom/flac)\n 01Ch 4 Compressor 3 (usually 0=none)\n 020h 8 Total size of all uncompressed hunks (N*4C80h-HunkPadding)\n 028h 8 Offset to Map (3D797h)\n 030h 8 Offset to first Metadata chunk (7Ch)\n 038h 4 Number of bytes per hunk (512k maximum) (990h*8) (4C80h)\n 03Ch 4 Number of bytes per sector (990h) (30h+60h)\n 040h 14h SHA1 on raw data\n 054h 14h SHA1 on raw+meta\n 068h 14h SHA1 on raw+meta of parent (0=No parent)\n ... .. Metadata Chunk(s)\n ... .. Padding to BytesPerHunk-boundary ;\\when uncompressed\n ... .. Uncompressed Sectors (aka hunks) ;/\n ... .. Compressed Sectors (aka hunks) ;-when compressed\n ... .. Map\nOverall Metadata chunk format:
000h 4 Chunk ID (aka Blob Tag) (eg. \"CHT2\" for each CDROM track)\n 004h 1 Flags (00h=V3, 01h=V4/V5) ;maybe some kind of flag/type/version?\n 005h 3 Chunk Data Size (24bit)\n 008h 8 Offset to next Chunk (or 0=Last chunk)\n 010h .. Chunk Data (eg. \"TRACK:1 TYPE:MODE2_RAW ... POSTGAP:0\",00h for CHT2)\n Summary of Chunk IDs and corresponding Data entries:\n ID_______Data_______________________________________________________\n \"GDDD\" \"CYLS,HEADS,SECS,BPS\" ;-hard disk standard info ;\\\n \"IDNT\" ? ;-hard disk identify info ; HDD\n \"KEY \" ? ;-hard disk key info ;/\n \"CIS \" ? ;-pcmcia CIS info ;-PCMCIA\n \"CHCD\" 94Ch-byte binary (4+99*24 bytes) ;\\\n \"CHTR\" \"TRACK TYPE SUBTYPE FRAMES\" ; CD-ROM\n \"CHT2\" \"TRACK TYPE SUBTYPE FRAMES PREGAP PGTYPE PGSUB POSTGAP\" ;/\n \"CHGT\" ? ;\\Sega\n \"CHGD\" \"TRACK TYPE SUBTYPE FRAMES PAD PREGAP PGTYPE PGSUB POSTGAP\" ;/GD-ROM\n \"AVAV\" \"FPS WIDTH HEIGHT INTERLACED CHANNELS SAMPLERATE\" ;\\AV\n \"AVLD\" ? (A/V Laserdisc frame) ;/\nThe ASCII items are separated by spaces as shown above (or commas for GDDD). The last item in each chunk is terminated by 00h (at least so for CHTR/CHT2). Most items are followed by a colon and decimal string (eg. TRACK:1), except, TYPE,PGTYPE,SUBTYPE,PGSUB are followed by text strings (eg. TYPE:MODE2_RAW).
CYLS:# Hard disc number of cylinders\n HEADS:# Hard disc number of heads\n SECS:# Hard disc number of sectors\n BPS:# Hard disc bytes per sector\n TRACK:# CDROM current track number (1..99)\n TYPE:string CDROM sector type/size\n SUBTYPE:string CDROM subchannel info (usually \"NONE\")\n FRAMES:# CDROM number of sectors per track (with/without pregap?)\n PAD:# Sega GDROM only: whatever pad value?\n PREGAP:# CDROM ... maybe number of pregap sectors? (can be HUGE !!??)\n PGTYPE:string CDROM ... whatever type? (usually \"MODE1\"??)\n PGSUB:string CDROM ... whatever subchannel (usually \"RW\"??)\n POSTGAP:# CDROM ... maybe number of pstgap sectors? (usually 0)\n FPS:#.###### AV Video(?)-frames per second? with 6-digit fraction? (.avi?)\n WIDTH:# AV Width (maybe in pixels?)\n HEIGHT:# AV Height (maybe in pixels?) (with/without interlace?)\n INTERLACED:# AV Interlace (maybe a flag that might be maybe 0 or 1?)\n CHANNELS:# AV Channels (maybe audio mono/stereo or so?)\n SAMPLERATE:# AV Samplerate (maybe audio samplerate, maybe in Hertz?)\n For SUBTYPE and PGSUB:\n \"RW\" 60h-byte interleaved ;normal \"cooked\" 96 bytes per sector\n \"RW_RAW\" 60h-byte uninterleaved ;raw uninterleaved 96 bytes per sector\n \"NONE\" 0-byte ;no subcode data stored (default)\n (unknown how RAW and RW_RAW differ, one format does probably store 8 bits\n for 8 subchannels per byte... but unknown which format is doing so?)\n For TYPE and PGTYPE (and CHCD numeric type 0..7):\n \"MODE1/2048\" or \"MODE1\" CHCD=0 800h-byte ;\\Data Mode1\n \"MODE1/2352\" or \"MODE1_RAW\" CHCD=1 930h-byte ;/\n \"MODE2/2336\" or \"MODE2\" ;\\dupe? CHCD=2 920h-byte ;\\\n \"MODE2/2336\" or \"MODE2_FORM_MIX\" ;/ CHCD=5 920h-byte ;\n \"MODE2/2048\" or \"MODE2_FORM1\" CHCD=3 800h-byte ; Data Mode2\n \"MODE2/2324\" or \"MODE2_FORM2\" CHCD=4 914h-byte ;\n \"MODE2/2352\" or \"MODE2_RAW\" or \"CDI/2352\" CHCD=6 930h-byte ;/\n \"AUDIO\" (stored as big-endian samples!!!) CHCD=7 930h-byte ;-Audio CD-DA\n 000h 4 Number of tracks (N) (1..99)\n 004h N*18h Track entries\n ... .. Zeropadding to 94Ch-byte size (when less than 99 tracks)\n Track entries:\n 000h 4 Track Type (0..7, CHCD=# in above table) (eg. 6=MODE2_RAW)\n 004h 4 Subchannel Type (0=RW, 1=RW_RAW, 2=None)\n 008h 4 Sector Size (800h, 914h, 920h or 930h)\n 00Ch 4 Subchannel Size (0 or 60h)\n 010h 4 Number of Frames (aka number of sectors)\n 014h 4 Padding Frames (0..3) (to make Total Frames a multiple of 4)\nThe Maps contain info (offset, size, compression method, etc.) for the separate compression blocks.
"},{"location":"cdromfileformats/#v1v2-map-format-64bit-entries-with-44bit20bit","title":"V1/V2 map format (64bit entries with 44bit+20bit):","text":" 44bit Offset to compressed data\n 20bit Size of compressed data (or uncompressed data when size=hunksize)\n 000h 8 Offset to compressed data (64bit big-endian)\n 008h 4 CRC32 on uncompressed data (32bit big-endian)\n 00Ch 3 Size of compressed data (24bit mixed-endian: Mid, Low, High)\n 00Fh 1 Flags, indicating compression info (=whut? maybe below V34 stuff?)\n V34_MAP_ENTRY_TYPE_INVALID = 0 invalid type\n V34_MAP_ENTRY_TYPE_COMPRESSED = 1 standard compression\n V34_MAP_ENTRY_TYPE_UNCOMPRESSED = 2 uncompressed data\n V34_MAP_ENTRY_TYPE_MINI = 3 mini: use offset as raw data\n V34_MAP_ENTRY_TYPE_SELF_HUNK = 4 same as another hunk in this file\n V34_MAP_ENTRY_TYPE_PARENT_HUNK = 5 same as a hunk in the parent file\n V34_MAP_ENTRY_TYPE_2ND_COMPRESSED = 6 compressed with secondary algorithm\n V5 uncompressed map format (when [filehdr+10h]=00000000h):\n 000h N*4 Hunk List (32bit offsets: Offset/BytesPerHunk) (usually 1,2,3..)\n V5 compressed map format (when [filehdr+10h]<>00000000h):\n 000h 4 Length of compressed map\n 004h 6 Offset of first block (48bit) (E4h, after meta)\n 00Ah 2 CRC16 on decompressed map entries\n 00Ch 1 bits used to encode complength\n 00Dh 1 bits used to encode self-refs\n 00Eh 1 bits used to encode parent unit refs\n 00Fh 1 Reserved for future use (probably zero)\n 010h .. Compressed Map entries (bitstream with Huffman/RLE encoding)\n The decompressed map entries should look as shown below (one could store them\n differently, eg. as 32bit little endian values; however, they must be stored\n exactly as shown below when computing the CRC16 on decompressed map entries):\n 000h 1 Compression type (0..3=Codec0..3, 4=Uncompressed, 5=Self, 6=Parent)\n 001h 3 Compressed length (24bit big-endian)\n 004h 6 Offset to compressed data (48bit big-endian)\n 00Ah 2 CRC16 on decompressed data (big-endian)\n V5 compression codecs:\n 0,0,0,0 = CHD_CODEC_NONE ;-unused (when using less than 4 codecs)\n \"zlib\" = CHD_CODEC_ZLIB ;\\\n \"lzma\" = CHD_CODEC_LZMA ; general codecs\n \"huff\" = CHD_CODEC_HUFFMAN ;\n \"flac\" = CHD_CODEC_FLAC ;/\n \"cdzl\" = CHD_CODEC_CD_ZLIB ;\\\n \"cdlz\" = CHD_CODEC_CD_LZMA ; general codecs with CD frontend\n \"cdfl\" = CHD_CODEC_CD_FLAC ;/\n \"avhu\" = CHD_CODEC_AVHUFF ;-A/V codecs\n readfile(src,NumberOfHunks*4) ;\\\n i=0 ; load uncomoressed\n while i<NumberOfHunks ; map (needed only\n ofs=bigendian32bit[src+i*4]*BytesPerHunk ; for uncompressed\n byte[map+i*0Ch+00h]=04h ;typ=Uncompressed ; files, which can\n bigendian24bit[map+i*0Ch+01h]=BytesPerHunk ; be created via\n bigendian48bit[map+i*0Ch+04h]=ofs ; chdman commandline\n bigendian16bit[map+i*0Ch+0Ah]=none ;no crc ; options)\n ofs=ofs+len, i=i+1 ;/\n readfile(hdr,10h) ;\\read map hdr and\n readfile(src,bigendian32bit[hdr+0]) ; compressed map\n InitBitstream(src,BigEndianMsbFirst) ;/\n i=0 ;\\\n while i<10h ;\n val=GetBits(4), num=1 ;\n if val=01h then ; read huffman tree\n val=GetBits(4) ;\n if val<>01h then num=GetBits(4)+3 ;\n for j=1 to num, codesizes[i]=val, i=i+1 ;\n nonlzh_explode_tree(codetree,codesizes,10h) ;/\n i=0, typ=0, num=0 ;\\\n while i<NumberOfHunks ;\n if num=0 ; load huffman coded\n x=GetHuffCode(codetree) ; map type values\n if x=07h then ;COMPRESSION_RLE_SMALL ;\n num=GetHuffCode(codetree)+03h ;\n elseif x=08h then ;COMPRESSION_RLE_LARGE ;\n num=GetHuffCode(codetree)*10h ;\n num=GetHuffCode(codetree)+num+13h ;\n else typ=x, num=1 ;\n byte[map+i*0Ch+0]=typ, i=i+1, num=num-1 ;/\n i=0, s=0, p=0 ;index,self,parent ;\\\n o=bigendian48bit[hdr+4] ;offset ; load other\n while i<NumberOfHunks ; map items\n typ=byte[map+i*0Ch+00h], ofs=o, len=0, crc=0 ;\n if typ<04h then len=GetBits([hdr+0Ch]), crc=GetBits(16); ;Method 0..3\n elseif typ=04h then len=BytesPerHunk, crc=GetBits(16) ; ;Uncompressed\n elseif typ=05h then s=GetBits([hdr+0Dh]), ofs=s ; ;New Self\n elseif typ=06h then p=GetBits([hdr+0Eh]), ofs=p ; ;New Parent\n elseif typ=09h then typ=05h, ofs=s ; ;Old Self\n elseif typ=0Ah then typ=05h, s=s+1, ofs=s ; ;Old Self+1\n elseif typ=0Bh then typ=06h, p=i*SectorsPerHunk, ofs=p ; ;Direct Parent\n elseif typ=0Ch then typ=06h, ofs=p ; ;Old Parent\n elseif typ=0Dh then typ=06h, p=p+SectorsPerHunk, ofs=p ; ;Old Parent+1\n else goto error ;\n byte[map+i*0Ch+00h]=typ ;\n bigendian24bit[map+i*0Ch+01h]=len ;\n bigendian48bit[map+i*0Ch+04h]=ofs ;\n bigendian16bit[map+i*0Ch+0Ah]=crc ;\n o=o+len, i=i+1 ;/\n if bigendian16bit[hdr+0Ah]<>noncrc16(map,i*0Ch) then error ;-final crc check\n 000h .. Uncompressed data\n 000h .. Deflate-compressed data\n 000h .. LZMA-compressed data (with lc=3, lp=0, pb=2) (without EOS end code)\n 000h 1 Output format for 16bit samples (\"L\"=Little-endian, \"B\"=Big-endian)\n 001h .. FLAC-compressed data frame(s)\n 000h .. Huffman-compressed data (small tree, large tree, plus data)\n 000h .. ECC Flags, (SectorsPerHunk+7)/8 bytes ;little-endian, bit0=1st flag\n ... 2/3 Size of compressed Data part (SIZ) ;big-endian, 16bit or 24bit\n ... SIZ Deflate compressed Data part ;uncompressed=930h*N bytes\n ... .. Deflate compressed Subchannel part ;uncompressed=60h*N bytes\n 000h .. ECC Flags, (SectorsPerHunk+7)/8 bytes ;little-endian, bit0=1st flag\n ... 2/3 Size of compressed Data part (SIZ) ;big-endian, 16bit or 24bit\n ... SIZ LZMA compressed Data part ;uncompressed=930h*N bytes\n ... .. Deflate compressed Subchannel part ;uncompressed=60h*N bytes\n 000h .. FLAC-compressed Data Frame(s) ;uncompressed=930h*N bytes\n ... .. Deflate compressed Subchannel part ;uncompressed=60h*N bytes\nThis isn't used on CDROMs and details are unknown/untested. It does reportedly exist in different versions, and does combine different compression methods for audio and video data.
"},{"location":"cdromfileformats/#compression-v4-format-3-av","title":"Compression V4 format 3 (AV)","text":"Unknown, maybe same/similar as \"avhu\".
"},{"location":"cdromfileformats/#compression-v3-v4-secondary-compression-method-flac-cdda","title":"Compression V3-V4 secondary compression method (FLAC CDDA)","text":"CHD source code claims that V3-V4 maps support \"FLAC CDDA\", but it doesn't actually seem to support that (audio discs compressed with chdman v0.145 are merely using Deflate).
"},{"location":"cdromfileformats/#chd-compression-for-cdroms","title":"CHD Compression for CDROMs","text":""},{"location":"cdromfileformats/#cdrom-cdzl-and-cdlz","title":"CDROM \"cdzl\" and \"cdlz\"","text":"If the sector's ECC flag is set:
Fix the 0Ch-byte Sync mark at [000h..00Bh]\n Fix the 114h-byte ECC data at [81Ch..92Fh] in relation to Mode at [00Fh]\n Fixing just means to overwrite those values (there's no XOR-filter or so).\n CHD doesn't filter EDC values, MM:SS:FF:Mode Sector headers, nor Subheaders.\n decompressing the subchannel part without decompressing the whole data part,\n and for using libraries that don't return the end of the compressed data part\nThere are no ECC flags (since Audio sectors don't have ECC). There is no size entry (one must decompress the whole FLAC part to find the begin of the Subchannel part). The FLAC output is always stored in BIG-ENDIAN format (because CHD likes to use big-endian for audio sectors, unlike formats like CUE/BIN).
"},{"location":"cdromfileformats/#cdrom-subchannel-data","title":"CDROM Subchannel data","text":"The Data part and Subchannel part must be interleaved after decompression (to form 990h-byte sectors with 930h+60h bytes). The CHD map's CRC is then computed on that interleaved data. Most CHD files use metadata SUBTYPE:NONE which means that the 60h-byte subchannel data is simply zerofilled and one must replace it by default Index/Position values (AFTER the above CRC check). The CHD metadata lacks accurate info about Index values; the PREGAP part is supposedly meant to have Index=0 and the remaining sectors Index=1). Although CHD files can contain subchannel data, CHDMAN has very limited support for creating such files (the most practical way seems to be to convert CCD/IMG/SUB to TOC/BIN and then convert that to CHD format).
"},{"location":"cdromfileformats/#chd-cdrom-sector-sizes","title":"CHD CDROM Sector Sizes","text":"Decompressed CHD CDROM Sectors are always 990h bytes tall (930h+60h). However, the Metadata TYPE/SUBTYPE entries may specify smaller sizes (corresponding to the format of the original TOC/BIN or CUE/BIN image). CHD does arrange that data as so:
000h Sector Data (800h, 914h, 920h or 930h bytes)\n ... Subchannel Data (0 or 60h bytes)\n ... Zeropadding to 990h-byte size (0..190h bytes)\n - The ECC-Filter works only for 930h-byte sectors (920h does also contain\n ECC, but CHD can't filter that, resulting in very bad compression ratio)\n - The last 60h-byte are supposed to be Deflate-compressed Subchannel Data\n (but 800h..920h+60h sectors actually contain Zeropadding in that location)\nThis is raw Deflate (despite of being called \"zlib\" in chd headers and source code; there aren't any ZLIB headers nor Adler checksums). V1-V4 does distinguish between \"zlib\" and \"zlib+\" (both are using normal Deflate) (V3/V4 are always using \"zlib+\") (the \"+\" does probably just mean that file was compressed with improved compression ratio). CDROM File Compression ZIP/GZIP/ZLIB (Inflate/Deflate)
"},{"location":"cdromfileformats/#lzma","title":"LZMA","text":"This contains a raw LZMA bitstream (without .lzma or .lz headers). The LZMA bitstream starts with 8 ignored bits, if Normalization occurs after last compression code, then it will also end with 8 ignored bits (those ignored bits aren't CHD-specific, they do also occur in other LZMA-based formats). CDROM File Compression LZMA
"},{"location":"cdromfileformats/#flac","title":"FLAC","text":"The data consists of raw FLAC Frames (without FLAC file header or FLAC metadata blocks), the format is always signed 16bit/stereo (NumChannels=2 SampleDepth=16), the sample rate is don't care for compression purposes (the FLAC Frame headers have it set to 09h=44100Hz). Each FLAC Frame starts with a 14bit Sync mark (3FFEh), and ends with 16bit CRC. There are usually several FLAC frames per CHD hunk (one must decompress all FLAC frames, until reaching the decompressed hunk size). Each FLAC Frame contains Left samples, followed by Right samples. After decompression, CHD does store them in interleaved form (L,R,L,R,etc.) CDROM File Compression FLAC audio
"},{"location":"cdromfileformats/#huffman_2","title":"Huffman","text":"This is using some custom CHD-specific Huffman compression.
decompress_chd_huffman_hunk:\n InitBitstream(src,BigEndianMsbFirst) ;-init\n codesizes[0..17h]=00h ;initially all unused ;\\\n codesizes[0]=GetBits(3) ;get first entry ;\n i=GetBits(3)+1 ;leading unused entries ; small\n @@small_tree_lop: ; tree\n val=GetBits(3) ;\n if val=07h then goto @@small_tree_done ;trailing unused entries ;\n codesizes[i]=val, i=i+1 ;apply entry ;\n if i<18h then goto @@small_tree_lop ;\n @@small_tree_done: ;\n nonlzh_explode_tree(codetree,codesizes,18h) ;/\n data=00h ;\\\n @@large_tree_lop: ;\n val=GetHuffCode(codetree)-1 ;using small tree codes ; large\n if val>=00h then ; tree\n data=val, codesizes[i]=data, i=i+1 ;\n else ;\n len=GetBits(3)+2 ;\n if len=7+2 then len=GetBits(8)+7+2 ;\n for n=1 to len, codesizes[i]=datal, i=i+1 ;\n if i<100h then goto @@large_tree_lop ;\n nonlzh_explode_tree(codetree,codesizes,100h) ;/\n for n=1 to decompressed_size ;\\data\n [dst]=GetHuffCode(codetree), dst=dst+1 ;using large tree codes ;/\nA normal CDROM contains a series of sectors. The CHD format is violating that in several ways: It's removing Index0/Pregap sectors, and it's instead inserting dummy/padding sectors between tracks.
Track <---- Track1---------> <---- Track2---------> <--End-->\n Section Index0 IndexN TrackPad Index0 IndexN TrackPad HunkPad\n Real Disc Yes Yes - Yes Yes - -\n CHD Header - Yes Yes - Yes Yes -\n CHD Data - Yes Yes - Yes Yes Yes\n Index0/pregap: Metadata PREGAP:sectors isn't stored in compressed data\n Track padding: Metadata FRAMES:sectors is rounded up to N*4 sectors\n Hunk padding: The last hunk is additionally rounded up to hunksize\nParent files are only used for writeable media like harddisks. The idea is to store the original installation and operating system in a readonly Parent file, and to store changes that file in a writeable Child file. Unknown what determines which parent belongs to which child, and if parents can be nested with other grandparents. Anyways, Parents aren't needed for CDROMs (except, one could theoretically store CDROM patches in child files).
"},{"location":"cdromfileformats/#self-references","title":"Self references","text":"This can be used to reference to another identical hunk in the same file (eg. zerofilled sectors or other duplicated data). There are some restrictions for CDROMs: Data sector headers contain increasing sector numbers, so there won't be any identical sectors. However, Audio sectors can be identical (unless they are stored with subchannel info, which does also contain increasing sector numbers).
"},{"location":"cdromfileformats/#mini","title":"Mini","text":"Mini is only used in V3/V4 maps. It does apparently store the \"data\" directly in the 8-byte Map offset field.
XXX Unknown what kind of \"data\" that is\n (probably \"normal compressed data\", that happens to be 8 bytes or smaller).\nCHD files can (cannot) be generated with the CHDMAN.EXE tool:
chdman hdr meta features/requirements/bugs/quirks/failures...\n v0.58 - - - ;-CHD didn't exist in older MAME versions\n v0.59 V1 - - ;\\\n v0.71 V2 - - ; supports harddisk CHD files only, not cdrom\n v0.78 V3 xxxx - ;/\n v0.81 V3 CHCD bad ;-crashes after creating the CHD file header\n v0.90 V3 CHCD ok ;\\\n v0.110 V3 CHCD ok ; requires cdrdao TOC/BIN as input (CUE/BIN does crash)\n v0.111 V3 CHTR ok ; (warning: BIN filenames may not contain space chars!)\n v0.112 V3 CHTR bug ; ;\\works, but compression is somewhat bugged (files\n v0.118 V3 CHTR bug ; ;/are BIGGER instead of SMALLER after compression)\n v0.120 V3 CHTR ok ;\n v0.130 V3 CHTR ok ;\n v0.131 V4 CHTR ok ;/\n v0.140 V4 CHT2 ok ;\\requires \"unicows.dll\" (=Quintessential Media Player)\n v0.145 V4 CHT2 ok ;/\n v0.146 V5 CHT2 bad ;\\says output file already exists (crashes on -f force)\n v0.154 V5 CHT2 bad ;/\n v0.155 V5 CHT2 bad ;\\crashes instantly (shortly before CreateEventW)\n v0.160 V5 CHT2 bad ;/\n v0.161 V5 CHT2 bad ;\\says output file already exists (crashes on -f force)\n v0.169 V5 CHT2 bad ;/\n v0.170 V5 CHT2 bad ;\\missing KERNEL32.DLL:AddVectoredExceptionHandler\n v0.217 V5 CHT2 bad ;/\n v0.218 V5 CHT2 bad ;\\requires \"newer version of windows\" (64bit)\n v0.247 V5 CHT2 bad ;/\nCHD source code (see files cdrom.*, chd*.*, etc):
https://github.com/mamedev/mame/tree/master/src/lib/util
CHDMAN commandline tool for generating chd files:
https://github.com/mamedev/mame/blob/master/src/tools/chdman.cpp
CHD decompression clone with useful comments:
https://github.com/SnowflakePowered/chd-rs/tree/master/chd-rs/src
CHD format reverse-engineering thread:
http://www.psxdev.net/forum/viewtopic.php?f=70&t=3980
"},{"location":"cdromfileformats/#cdrom-disk-images-other-formats","title":"CDROM Disk Images Other Formats","text":""},{"location":"cdromfileformats/#iso-a-raw-iso9660-image-can-contain-a-single-data-track-only","title":".ISO - A raw ISO9660 image (can contain a single data track only)","text":"Contains raw sectors without any sub-channel information (and thus it's restricted to the ISO filesystem region only, and cannot contain extras like additional audio tracks or additional sessions). The image should start at 00:02:00 (although I wouldn't be surprised if some \\<might> start at 00:00:00 or so). Obviously, all sectors must have the same size, either 800h or 930h bytes (if the image contains only Mode1 or Mode2/Form1 sectors then 800h bytes would usually enough; if it contains one or more Mode2/Form2 sectors then all sectors should be 930h bytes). Handling .ISO files does thus require to detect the image's sector size, and to search the sector that contains the first ISO Volume Descriptor. In case of 800h byte sectors it may be additionally required to detect if it is a Mode1 or Mode2/Form1 image; for PSX images (and any CD-XA images) it'd be Mode2.
"},{"location":"cdromfileformats/#c2d","title":".C2D","text":"Something. Can contain compressed or uncompressed CDROM-images. Fileformat and compression ratio are unknown. Also unknown if it allows random-access. Some info on (uncompressed) .C2D files can be found in libmirage source code.
"},{"location":"cdromfileformats/#isz-compressed-iso-file-with-800h-byte-sectors-ultraiso","title":".ISZ - compressed ISO file with 800h-byte sectors (UltraISO)","text":"This contains a compressed ISO filesystem, without supporting any CD-specific features like Tracks, FORM2 sectors, or CD-DA Audio.
http://www.ezbsystems.com/isz/iszspec.txt
The format might be suitable for PC CDROMs, but it's useless for PSX CDROMs.
"},{"location":"cdromfileformats/#mdx","title":".MDX","text":"Reportedly a \"compressed\" MDS/MDF file, supported by Daemon Tools. Other info says that MDX is just MDS/MDF merged into a single file, without mentioning any kind of \"compression\" support. Basically... Daemon Tools is Adware that can merge MDS+MDF into one MDX file... with additional Advertising? However, the MDS+MDF format is completely different than MDX format:
000h 10h ID (\"MEDIA DESCRIPTOR\") (weirdly, same as in Alcohol .MDS)\n 010h 2 Unknown (02h,01h) (maybe version or so)\n 012h 1Ah Copyright string (A9h,\" 2000-2015 Disc Soft Ltd.\")\n 02Ch 4 Unknown (FFFFFFFFh)\n 030h 4 Offset to Unknown Footer (322040h) (N*800h+40h)\n 034h 4 Unknown (0)\n 038h 4 Unknown (B0h)\n 03Ch 4 Unknown (0)\n 040h N*800h Sector Data\n 322040h 270h Unknown (Advertising IDs? CRCs? Encrypted CUE sheet? Garbage?)\nCustom format used by PSIO (an SD-card based CDROM-drive emulator connected to PSX expansion port). The .CU2 file is somewhat intended to be smaller and easier to parse than normal .CUE files, the drawback is that it's kinda non-standard, and doesn't support INDEX and ADSR information. A sample .CUE file looks as so:
ntracks 3\n size 39:33:17\n data1 00:02:00\n track02 31:36:46\n track03 36:03:17\n ;(insert 2 blanks lines here, and insert 1 leading space in next line)\n trk end 39:37:17\nThis is a rather crude file format, used only by the Xe Emulator. The files are meant to be generated by a utility called CDR (CD Image Ripper), which, in practice merely displays an \"Unable to read TOC.\" error message. The overall file structure is, according to \"Xe User's Manual\":
header: 200h bytes header (see below)\n data: 990h bytes per sector (2352 Main, 96 Sub), 00:00:00->Lead Out\n 000h 00\n 001h 00\n 002h First Track\n 003h Last Track\n 004h Track 1 (ADR << 4) | CTRL ;\\\n 005h Track 1 Start Minutes ; Track 1\n 006h Track 1 Start Seconds ;\n 007h Track 1 Start Frames ;/\n ... ... ;-Probably Further Tracks (?)\n n+0 Last Track Start Minutes ;\\\n n+1 Last Track Start Seconds ; Last Track\n n+2 Last Track Start Frames ;\n n+3 Last Track (ADR << 4) | CTRL ;/\n n+4 Lead-Out Track Start Minutes ;\\\n n+5 Lead-Out Track Start Seconds ; Lead-Out\n n+6 Lead-Out Track Start Frames ;\n n+7 Lead-Out Track (ADR << 4) | CTRL ;/\n ... 00\n 1FFh 00\nPSX software can access the CDROM via Port 1F801800h..1F801803h (as described in the previous chapters). The following chapters describe the inner workings of the PSX CDROM controller - this information is here for curiosity only - normally PSX software cannot gain control of those lower-level stuff (although some low level registers can be manipulated via Test commands, but that will usually conflict with normal operation).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#motorola-mc68hc05-8bit-single-chip-cpu","title":"Motorola MC68HC05 (8bit single-chip CPU)","text":"The Playstation CDROM drive is controlled by a MC68HC05 8bit CPU with on-chip I/O ports and on-chip BIOS ROM. There is no way to reprogram that BIOS, nor to tweak it to execute custom code in RAM. CDROM Internal HC05 Instruction Set CDROM Internal HC05 On-Chip I/O Ports CDROM Internal HC05 I/O Port Usage in PSX CDROM Internal HC05 Motorola Selftest Mode The PSX can read HC05 I/O Ports and RAM via Test Commands: CDROM - Test Commands - Read HC05 SUB-CPU RAM and I/O Ports
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#decoderfifo-cxd1199bq-or-cxd1815q","title":"Decoder/FIFO (CXD1199BQ or CXD1815Q)","text":"This chip handles error correction and ADPCM decoding, and acts as some sort of FIFO interface between main/sub CPUs and incoming cdrom sector data. On the MIPS Main CPU it is controlled via Port 1F801800h..1F801803h. CDROM Controller I/O Ports On the HC05 Sub CPU it is controlled via Port A (data in/out), Port E (address/index), and Port D (read/write/select signals); the HC05 doesn't have external address/data bus, so one must manually access the CXD1815Q via those ports. CDROM Internal CXD1815Q Sub-CPU Configuration Registers CDROM Internal CXD1815Q Sub-CPU Sector Status Registers CDROM Internal CXD1815Q Sub-CPU Address Registers CDROM Internal CXD1815Q Sub-CPU Misc Registers The PSX can read/write the Decoder I/O Ports and SRAM via Test commands: CDROM - Test Commands - Read/Write Decoder RAM and I/O Ports The sector buffer used in the PSX is 32Kx8 SRAM. Old PU-7 boards are using CXD1199BQ chips, later boards are using CXD1815Q, and even later boards have the stuff intergrated in the SPU. Note: The CXD1199BQ/CXD1815Q are about 99% same as described in CXD1199AQ datasheet.
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#signal-processor-and-servo-amplifier","title":"Signal Processor and Servo Amplifier","text":"Older PSX mainboards are using two separate chips: CDROM Internal Commands CX(0x..3x) - CXA1782BR Servo Amplifier CDROM Internal Commands CX(4x..Ex) - CXD2510Q Signal Processor Later PSX mainboards have the above intergrated in a single chip, with some extended features: CDROM Internal Commands CX(0x..Ex) - CXD2545Q Servo/Signal Combo Later version is CXD1817R (Servo/Signal/Decoder Combo). Even later PSX mainboards have it integrated in the Sound Chip: CXD2938Q (SPU+CDROM) with some changed bits and New SCEx transfer: CDROM Internal Commands CX(0x..Ex) - CXD2938Q Servo/Signal/SPU Combo Finally, PM-41(2) boards are using a CXD2941R chip (SPU+CDROM+SPU_RAM), unknown if/how far the CDROM part of that chip differs from CXD2938Q. Some general notes: CDROM Internal Commands CX(xx) - Notes CDROM Internal Commands CX(xx) - Summary of Used CX(xx) Commands The PSX can manipulate the CX(..) registers via some test commands: CDROM - Test Commands - Test Drive Mechanics Note: Datasheets for CXD2510Q/CXA1782BR/CXD2545Q do exist.
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cdrom-pinouts","title":"CDROM Pinouts","text":"Pinouts - DRV Pinouts Pinouts - HC05 Pinouts
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cdrom-internal-hc05-instruction-set","title":"CDROM Internal HC05 Instruction Set","text":""},{"location":"cdrominternalinfoonpsxcdromcontroller/#alu-loadstore-jumpcall","title":"ALU, Load/Store, Jump/Call","text":" Opcode Clk HINZC Name Syntax\n x6 ... 2-5 --NZ- LDA MOV A,<op> ;A=op\n xE ... 2-5 --NZ- LDX MOV X,<op> ;X=op\n x7 ... 4-6 --NZ- STA MOV <op>,A ;op=A\n xF ... 4-6 --NZ- STX MOV <op>,X ;op=X\n xC ... 2-4 ----- JMP JMP <op> ;PC=op\n xD ... 5-7 ----- JSR CALL <op> ;[SP]=PC, PC=op\n xB ... 2-5 H-NZC ADD ADD A,<op> ;A=A+op\n x9 ... 2-5 H-NZC ADC ADC A,<op> ;A=A+op+C\n x0 ... 2-5 --NZC SUB SUB A,<op> ;A=A-op\n x2 ... 2-5 --NZC SBC SBC A,<op> ;A=A-op-C\n x4 ... 2-5 --NZ- AND AND A,<op> ;A=A AND op\n xA ... 2-5 --NZ- ORA OR A,<op> ;A=A OR op\n x8 ... 2-5 --NZ- EOR XOR A,<op> ;A=A XOR op\n x1 ... 2-5 --NZC CMP CMP A,<op> ;A-op\n x3 ... 2-5 --NZC CPX CMP X,<op> ;X-op\n x5 ... 2-5 --NZ- BIT TEST A,<op> ;A AND op\n A7,AF,AC = Reserved (no STA/STX/JMP with immediate operand)\n Opcode Clk ALU/LDA/LDX Clk STA/STX Clk JMP/CALL\n Ax nn 2 cmd r,nn - N/A -/6 call relative (BSR)\n Bx nn 3 cmd r,[nn] 4 mov [nn],r 2/5 cmd nn\n Cx nn mm 4 cmd r,[nnmm] 5 mov [nnmm],r 3/6 cmd nnmm\n Dx nn mm 5 cmd r,[X+nnmm] 6 mov [X+nnmm],r 4/7 cmd X+nnmm\n Ex nn 4 cmd r,[X+nn] 5 mov [X+nn],r 3/6 cmd X+nn\n Fx 3 cmd r,[X] 4 mov [X],r 2/5 cmd X\n Opcode Clk HINZC Name Syntax\n xC ... 3-6 --NZ- INC INC op ;increment ;op=op+1\n xA ... 3-6 --NZ- DEC DEC op ;decrement ;op=op-1\n xF ... 3-6 --01- CLR ?? op,00h ;clear ;op=op AND 00h\n x3 ... 3-6 --NZ1 COM NOT op ;complement ;op=op XOR FFh\n x0 ... 3-6 --NZC NEG NEG op ;negate ;op=00h-op\n x9 ... 3-6 --NZC ROL RCL op ;rotate left through carry\n x6 ... 3-6 --NZC ROR RCR op ;rotate right through carry\n x8 ... 3-6 --NZC LSL SHL op ;shift left logical\n x4 ... 3-6 --0ZC LSR SHR op ;shift right logical\n x7 ... 3-6 --NZC ASR SAR op ;shift right arithmetic\n xD ... 3-5 --NZ- TST TEST op,FFh ;test for negative or zero (AND FFh?)\n x1,x2,x5,xB,xE = Reserved (except for: 42 = MUL)\n Opcode Clk RMW Clk CLR Clk TST\n 3x nn 5 cmd [nn] 5 MOV [nn],00h 4 TEST [nn],0FFh\n 4x 3 cmd A 3 MOV A,00h,slow 3 TEST A,0FFh,slow\n 5x 3 cmd X 3 MOV X,00h,slow 3 TEST X,0FFh\n 6x nn 6 cmd [X+nn] 6 MOV [X+nn],00h 5 TEST [X+nn],0FFh\n 7x 5 cmd [X] 5 MOV [X],00h 4 TEST [X],0FFh\n Opcode Clk HINZC Name Syntax\n 00h+i*2 nn dd 5 ----C BRSET JNZ [nn].i,dest ;C=[nn].i, branch if set\n 01h+i*2 nn dd 5 ----C BRCLR JZ [nn].i,dest ;C=[nn].i, branch if clear\n 10h+i*2 nn 5 ----- BSET SET [nn].i ;set [nn].i\n 11h+i*2 nn 5 ----- BCLR RES [nn].i ;clear [nn].i\n Opcode Clk HINZC Name Syntax\n 20 nn 3 ----- BRA JR nn ;branch always\n 21 nn 3 ----- BRN NUL nn ;branch never\n 22 nn 3 ----- BHI JA nn ;if C=0 and Z=0, higher ?\n 23 nn 3 ----- BLS JBE nn ;if C=1 or Z=1, lower or same ?\n 24 nn 3 ----- BCC/BHS JNC/JAE nn ;if C=0, carry clear, higher.same\n 25 nn 3 ----- BCS/BLO JC/JB nn ;if C=1, carry set, lower\n 26 nn 3 ----- BNE JNZ/JNE nn ;if Z=0, not equal / not zero\n 27 nn 3 ----- BEQ JZ/JE nn ;if Z=1, equal / zero\n 28 nn 3 ----- BHCC JNH nn ;if H=0, half-carry clear\n 29 nn 3 ----- BHCS JH nn ;if H=1, half-carry set\n 2A nn 3 ----- BPL JNS nn ;if S=0, plus / not signed\n 2B nn 3 ----- BMI JS nn ;if S=1, minus / signed\n 2C nn 3 ----- BMC JEI nn ;if I=0, interrupt mask clear\n 2D nn 3 ----- BMS JDI nn ;if I=1, interrupt mask set\n 2E nn 3 ----- BIL JIL nn ;if XX=LO, interrupt line low\n 2F nn 3 ----- BIH JIH nn ;if XX=HI, interrupt line high\n AD nn 6 ----- BSR CALL relative nn ;branch to subroutine always\n Opcode Clk HINZC Name Syntax\n 9D 2 ----- NOP NOP ;no operation\n 97 2 ----- TAX MOV X,A ;transfer A to X\n 9F 2 ----- TXA MOV A,X ;transfer X to A\n 9C 2 ----- RSP MOV SP,00FFh ;reset stack pointer (SP=00FFh)\n 42 11 0---0 MUL MUL X,A ;X:A=X*A (unsigned multiply)\n 81 6 ----- RTS RET ;return from subroutine\n 80 9 xxxxx RTI RETI ;return from interrupt\n 99 2 ----1 SEC STC ;set carry flag\n 98 2 ----0 CLC CLC ;clear carry flag\n 9B 2 -1--- SEI DI ;set interrupt mask (disable ints)\n 9A 2 -0--- CLI EI ;clear interrupt mask (enable ints)\n 8E ..2 -0--- STOP STOP ;?\n 8F ..2 -0--- WAIT WAIT ;?\n 83 10 -1--- SWI SWI ;software interrupt ...? PC=[FFFCh]\n <IRQ> ? ????? Interrupt ;? PC=[FFFxh]\n <RESET> ? ????? Reset ;? PC=[FFFEh]\n 82,84..8D,90..96,9E = Reserved\n A 8bit accumulator\n X 8bit index register\n SP 6bit stack pointer (range 00C0h..00FFh)\n PC 16bit program pointer (range 0000h..FFFFh)\n CCR 5bit condition code register (flags) (111HINZC)\n SP.highest PC.lo\n PC.hi\n X\n A\n SP.lowest Flags (CCR, 5bit condition code register) (111HINZC)\n nn immediate ;00h..FFh\n [nn] direct address ;[0000h..00FFh]\n [nnmm] extended address ;[0000h..FFFFh]\n [X] indexed, no offset ;[0000h..00FFh]\n [X+nn] indexed, 8bit offset ;[0000h..01FEh]\n [X+nnmm] indexed, 16bit offset ;[0000h..FFFFh]\n [nn].i bit ;[0000h..00FFh].bit0..7\n dd relative ;$+2..3+(-80h..+7Fh)\n operand \"X+nn\" performs an unsigned addition, and can address 0000h..01FEh.\n 16bit operands (nnmm) are encoded in BIG-ENDIAN format (same for pushed PC).\nException vectors are 16bit BIG-ENDIAN values at FFF0h-FFFFh (or at FFE0h-FFEFh when running in Motorola Bootstrap mode).
Vector Prio Usage\n FFF0h 7=lo TBI Vector (Timebase)\n FFF2h 6 SSPI Vector (SPI bus) (SPI1 and SPI2)\n FFF4h 5 Timer 2 Interrupt Vector (Timer 2 Input/Compare)\n FFF6h 4 Timer 1 Interrupt Vector (Timer 1 Input/Compare/Overflow)\n FFF8h 3 KWI Vector (Key Wakeup) (KWI0..7 pins)\n FFFAh 2 External Interrupt Vector (/IRQ1 and /IRQ2 pins)\n FFFCh none Software Interrupt Vector (SWI opcode) ;\\regardless of\n FFFEh 1=hi Reset Vector (/RESET signal and COP) ;/CPU's \"I\"\n .hc05 select HC05 instruction set (default would be .mips)\n .nocash select nocash syntax (default would be .native opcode names)\n db ... define 8bit byte(s), or quoted ascii strings\n dw ... define 16bit word(s) in BIG ENDIAN (for HC05 exception vectors)\n org nnnn change origin for following opcodes\n end end of file\n mov c,[nn].i alias for \"jnz [nn].i,$+3\" (dummy jump & set carry=[nn].i)\n 0 OPTM Option Map Select (bank-switching for Port 00h..0Fh)\n 1 FOSCE Fast (Main) Oscillator Enable (0=Disable OSC, 1=Normal)\n 2-3 SYS System Clock Select (0=OSC/2, 1=OSC/4, 2=OSC/64, 3=XOSC/2)\n 4-5 - Not used (0)\n 6 STUP XOSC Time Up Flag (R)\n 7 FTUP OSC Time Up Flag (R) (0=Busy, 1=Ready/Good/Stable)\nThese are general purpose I/O ports (controlling external pins). Some ports are Input-only, and some can be optionally used for special things (like IRQs, SPI-bus, or as Timer input/output).
PA.0-7 PAn Port A Bit0..7 Input/Output (0=Low, 1=High) (R/W)\n PB.0-7 PBn Port B Bit0..7 Input /KWI0..7 (0=Low, 1=High) (R)\n PC.0 PC0 Port C Bit0 Input/Output /SDI1 (SPI)(0=Low, 1=High) (R/W)\n PC.1 PC1 Port C Bit1 Input/Output /SDO1 (SPI)(0=Low, 1=High) (R/W)\n PC.2 PC2 Port C Bit2 Input/Output /SCK1 (SPI)(0=Low, 1=High) (R/W)\n PC.3 PC3 Port C Bit3 Input/Output /TCAP (T1) (0=Low, 1=High) (R/W)\n PC.4 PC4 Port C Bit4 Input/Output /EVI (T2) (0=Low, 1=High) (R/W)\n PC.5 PC5 Port C Bit5 Input/Output /EVO (T2) (0=Low, 1=High) (R/W)\n PC.6 PC6 Port C Bit6 Input/Output /IRQ2 (0=Low, 1=High) (R/W)\n PC.7 PC7 Port C Bit7 Input/Output /IRQ1 (0=Low, 1=High) (R/W)\n PD.0-7 PDn Port D Bit0..7 Input/Output (0=Low, 1=High) (R/W)\n PE.0-7 PEn Port E Bit0..7 Input/Output (0=Low, 1=High) (R/W)\n PF.0-7 PFn Port F Bit0..7 Input/Undoc A/D-input (0=Low, 1=High) (R)(R/W)\n DDRX.0-7 DDRXn Port X Data Direction Bit0..7 (0=Input, 1=Output) (R/W)\n RCR1.0 RAL Port A.Bit0-3 Pullup Resistors (0=Off, 1=On)\n RCR1.1 RAH Port A.Bit4-7 Pullup Resistors (0=Off, 1=On)\n RCR1.2 RBL Port B.Bit0-3 Pullup Resistors (0=Off, 1=On)\n RCR1.3 RBH Port B.Bit4-7 Pullup Resistors (0=Off, 1=On)\n RCR1.4 RGL Port G.Bit0-3 Pullup Resistors (0=Off, 1=On) ;\\\n RCR1.5 RGH Port G.Bit4-7 Pullup Resistors (0=Off, 1=On) ; on chips\n RCR1.6 RHL Port H.Bit0-3 Pullup Resistors (0=Off, 1=On) ; with Port G,H\n RCR1.7 RHH Port H.Bit4-7 Pullup Resistors (0=Off, 1=On) ;/\n RCR2.0-7 RCn Port C.Bit0-7 Pullup Resistors (0=Off, 1=On)\n WOM1.0 AWOML Port A.Bit0-3 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)\n WOM1.1 AWOMH Port A.Bit4-5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)\n WOM1.2 GWOML Port G.Bit0-3 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)\n WOM1.3 GWOMH Port G.Bit4-5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)\n WOM1.4 HWOML Port H.Bit0-3 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)\n WOM1.5 HWOMH Port H.Bit4-5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)\n WOM1.6-7 - Not used (0)\n WOM2.0-5 CWOMn Port C.Bit0..5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)\n WOM2.6-7 - Not used (always both bits set)\n==== Interrupts =====
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-optm008h-intcr-interrupt-control-register-rw","title":"HC05 Port OPTM=0:08h - INTCR - Interrupt Control Register (R/W)","text":" 0-1 - Not used (0)\n 2 IRQ2S IRQ2 Select Edge-Sensitive Only (0=LowLevelAndNegEdge, 1=NegEdge)\n 3 IRQ1S IRQ1 Select Edge-Sensitive Only (0=LowLevelAndNegEdge, 1=NegEdge)\n 4 KWIE Key Wakeup Interrupt Enable (0=Disable, 1=Enable)\n 5 - Not used (0)\n 6 IRQ2E IRQ2 Interrupt Enable (0=Disable, 1=Enable)\n 7 IRQ1E IRQ1 Interrupt Enable (0=Disable, 1=Enable)\n 0 RKWIF Reset Key Wakeup Interrupt Flag (0=No Change, 1=Reset) (W)\n 1 - Not used (0)\n 2 RIRQ2 Reset IRQ2 Interrupt Flag (0=No Change, 1=Reset) (W)\n 3 RIRQ1 Reset IRQ1 Interrupt Flag (0=No Change, 1=Reset) (W)\n 4 KWIF Key Wakeup Interrupt Flag (PB/KWI) (0=No, 1=IRQ) (R)\n 5 - Not used (0)\n 6 IRQ2F IRQ2 Interrupt Flag (PC6) (0=No, 1=IRQ) (R)\n 7 IRQ1F IRQ1 Interrupt Flag (PC7) (0=No, 1=IRQ) (R)\n 0-7 KWIEn Port B.Bit0..7 Key Wakeup Interrupt Enable (0=Disable, 1=Enable)\n==== SPI Bus ====
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-optm00ah-spcr1-serial-peripheral-control-register-1-rw","title":"HC05 Port OPTM=0:0Ah - SPCR1 - Serial Peripheral Control Register 1 (R/W)","text":" 0 SPRn SPI Clock Rate (0=ProcessorClock/2, 1=ProcessorClock/16)\n 1-3 - Not used (0)\n 4 MSTRn SPI Master Mode Select (0=Slave/SCK.In, 1=Master/SCK.Out)\n 5 DORDn SPI Data Transmission Order (0=MSB First, 1=LSB First)\n 6 SPEn SPI Enable (SPI1:PortC, SPI2:PortG) (0=Disable, 1=Enable)\n 7 SPIEn SPI Interrupt Enable (... ack HOW?) (0=Disable, 1=Enable)\n 0-5 - Not used (0)\n 6 DCOLn SPI Data Collision Occurred (0=No, 1=Collision)\n 7 SPIFn SPI Transfer Complete Flag (0=Busy, 1=Complete) (R)\n 0-7 BITn Data to be sent / being received\n==== Time Base / Config ====
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-10h-tbcr1-time-base-control-register-1-rw","title":"HC05 Port 10h - TBCR1 - Time Base Control Register 1 (R/W)","text":" 0-1 T2R Timer2 Prescaler (0=SysClk, 1=SysClk/4, 2=SysClk/32, 3=SysClk/256)\n 2-3 T3R PWM Prescaler (0=CLK3, 1=CLK3/2, 2=CLK3/8, 3=Timer2compare)\n 4-6 - Not used (0)\n 7 TBCLK Time Base Clock (0=XOSC, 1=OSC/128) ;<-- write-able only ONCE\n 0 COPC COP Clear 2bit COP timeout divider (0=No Change, 1=Clear) (W)\n 1 COPE COP Enable ;<-- write-able only ONCE\n 2 - Not used (0)\n 3 RTBIF Reset Time Base Interrupt Flag (0=No Change, 1=Clear TBIF) (W)\n 4-5 TBR Time Base Interrupt Rate (0=TBCLK/128, 1=/4096, 2=/8192, 3=/16384)\n 6 TBIE Time Base Interrupt Enable (0=Disable, 1=Enable)\n 7 TBIF Time Base Interrupt Flag (0=No, 1=IRQ) (R)\n 0-4 - Not used (0)\n 5 XOSCR XOSC Feedback Resistor (0=None, 1=Implemented)\n 6 OSCR OSC Feedback Resistor (0=None, 1=Implemented)\n 7 RSTR /RESET Pullup Resistor (0=None, 1=Implemented)\n==== Timer 1 ====
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-12h-tcr-timer-1-control-register-rw","title":"HC05 Port 12h - TCR - Timer 1 Control Register (R/W)","text":" 0 OLVL Output Level on TCMP pin on Compare Match? (0=Low, 1=High)\n 1 IEDG Input Edge on TCAP pin (0=NegativeEdge, 1=PositiveEdge)\n 2-4 - Not used (0)\n 5 TOIE Timer Overflow Interrupt Enable (0=Disable, 1=Enable)\n 6 OC1IE Output Compare Interrupt Enable (0=Disable, 1=Enable)\n 7 ICIE Input Capture Interrupt Enable (0=Disable, 1=Enable)\n 0-4 - Not used (0)\n 5 TOF Timer Overflow Flag (0=No, 1=Yes) (R) ;clear by Port 19h access\n 6 OC1F Output Compare Flag (0=No, 1=Yes) (R) ;clear by Port 17h access\n 7 ICF Input Capture Flag (0=No, 1=Yes) (R) ;clear by Port 15h access\n 0-15 Capture Value\n 0-15 Compare Value\n 0-15 Counter\n 0-15 Alternate Counter (uh, what?)\n==== Timer 2 ====
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-1ch-tcr2-timer-2-control-register-rw","title":"HC05 Port 1Ch - TCR2 - Timer 2 Control Register (R/W)","text":" 0 OL2 Timer Output 2 Edge (0=Falling, 1=Rising)\n 1 OE2 Timer Output 2 Enable (EVO) (0=Disable, 1=Enable)\n 2 IL2 Timer Input 2 Edge/Level (0=Low/Falling, 1=High/Rising)\n 3 IM2 Timer Input 2 Mode Select for EVI (0=EventMode, 1=GatedByCLK2)\n 4 T2CLK Timer 2 Clock Select (0=CLK2 from Prescaler, 1=EXCLK from EVI)\n 5 - Not used (0)\n 6 OC2IE Output Compare 2 Interrupt Enable (0=Disable, 1=Enable)\n 7 TI2IE Timer Input 2 Interrupt Enable (EVI) (0=Disable, 1=Enable)\n 0-1 - Not used (0)\n 2 ROC2F Reset Output Compare 2 Interrupt Flag (0=No Change, 1=Clear) (W)\n 3 RTI2F Reset Timer Input 2 Interrupt Flag (0=No Change, 1=Clear) (W)\n 4-5 - Not used (0)\n 6 OC2F Output Compare 2 Interrupt Flag (0=No, 1=Yes) (R)\n 7 TI2F Timer Input 2 Interrupt Flag (EVI) (0=No, 1=Yes) (R)\n 0-7 Compare Value (\"Transferred to buffer on certain events?\")\n 0-7 Counter Value, incremented at T2R (set to 01h on Compare Matches)\n==== Reserved ====
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-3fh-unknownunused","title":"HC05 Port 3Fh - Unknown/Unused","text":"Reading this port via Sony's test command returns 20h (same as openbus), but reading it via Motorola's selftest function returns 00h (unlike openbus), so it seems to have some unknown/undocumented function; bit5 might indicate selftest mode, or it might reflect initialization of whatever other ports.
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-optm006h07h0dh0fh-reserved","title":"HC05 Port OPTM=0:06h..07h,0Dh..0Fh - Reserved","text":""},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-optm101h06h07h0ch0dh-reserved","title":"HC05 Port OPTM=1:01h,06h..07h,0Ch..0Dh - Reserved","text":""},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-20h3dh-reserved","title":"HC05 Port 20h..3Dh - Reserved","text":"These ports are unused/reserved. Trying to read them on a PSone does return 20h (possibly the prefetched next opcode value from the RAM test command). Other HC05 variants contain some extra features in these ports: CDROM Internal HC05 On-Chip I/O Ports - Extras The PSX CDROM BIOS doesn't use any of these ports - execpt, it is writing [20h]=2Eh (possibly to disable unused LCD hardware; which might be actually present in the huge 80pin HC05 chips on old PU-7 mainboards).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-openbus","title":"HC05 Openbus","text":"Openbus values can be read from invalid memory locations, on PSX with 52pin chips:
I/O bank 0: 0:06h..07h, 0:0Dh..0Fh\n I/O bank 1: 1:01h, 1:06h..07h, 1:0Ch..0Dh, and upper 4bit of 1:05h\n Unbanked I/O: 20h..3Dh\n Unused Memory: 0240h..0FFFh, 5000h..FDFFh\n [nn],[mmnn],[nn+x],[mmnn+x] --> returns LAST byte of current opcode (=nn)\n [x] --> returns FIRST byte of following opcode\nThis is a second SPI channel, works same as first SPI channel, but using the lower 3bits of Port G (instead of Port C) for the SPI signals.
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-optm006h-portg-port-g-data-register-rw","title":"HC05 Port OPTM=0:06h - PORTG - Port G Data Register (R/W)","text":""},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-optm007h-porth-port-h-data-register-rw","title":"HC05 Port OPTM=0:07h - PORTH - Port H Data Register (R/W)","text":""},{"location":"cdrominternalinfoonpsxcdromcontroller/#hc05-port-3ch-portj-port-j-data-register-rw","title":"HC05 Port 3Ch - PORTJ - Port J Data Register (R/W)","text":" PG.0 PG0 Port G Bit0 Input/Output /SDI2 (0=Low, 1=High) (R/W)\n PG.1 PG1 Port G Bit1 Input/Output /SDO2 (0=Low, 1=High) (R/W)\n PG.2 PG2 Port G Bit2 Input/Output /SCK2 (0=Low, 1=High) (R/W)\n PG.3 PG3 Port G Bit3 Input/Output /TCMP (0=Low, 1=High) (R/W)\n PG.4 PG4 Port G Bit4 Input/Output /PWM0 (0=Low, 1=High) (R/W)\n PG.5 PG5 Port G Bit5 Input/Output /PWM1 (0=Low, 1=High) (R/W)\n PG.6 PG6 Port G Bit6 Input/Output /PWM2 (0=Low, 1=High) (R/W)\n PG.7 PG7 Port G Bit7 Input/Output /PWM3 (0=Low, 1=High) (R/W)\n PH.0-7 PHn Port H Bit0..7 Input/Output (0=Low, 1=High) (R/W)\n PJ.0-3 PJn Port J Bit0..3 Output (0=Low, 1=High) (R/W)\n PJ.4-7 - Not used (0)\n 0-7 DDRXn Port X Data Direction Bit0..7 (0=Input, 1=Output) (R/W)\n 0 - Not used (0)\n 1 PDH Select Port D (H) (0=FP35-FP38 pins, 1=PD7-PD4 pins)\n 2 PEL Select Port E (L) (0=FP31-FP34 pins, 1=PE3-PE0 pins)\n 3 PEH Select Port E (H) (0=FP27-FP30 pins, 1=PE7-PE4 pins)\n 4 - Not used (0)\n 5-6 DUTY LCD Duty Select (...)\n 7 LCDE LCD Output Enable BP and FP pins (0=Disable, 1=Enable)\n 0-3 First Data Unit ;\\Fourty 4bit LCD values (in the twenty registers)\n 4-7 Second Data Unit ;/(some duties use only the LSBs of that 4bit values)\n 0-3 CH0-3 PWM Channel 0..3 on Port G.Bit4-7 Enable (0=Disable, 1=Enable)\n 4-7 - Not used (0)\n 0-7 PWM Counter, incremented at PHI2 (range 01h..FFh)\n 0-7 Duty (N cycles High, 255-N cycles Low)\n 0-3 A/D Conversion result (probably unsigned, 00h=Lowest, FFh=Max voltage?)\n 0-3 CH0-3 A/D Channel (0..7=PortF.Bit0-7, 8..0Fh=Reserved/Vref/FactorTest)\n 4 - Not used (0)\n 5 ADON A/D Charge Pump enable (0=Disable, 1=Enable)\n 6 ADRC A/D RC Oscillator On (0=Normal/Use CPU Clock, 1=Use RC Clock)\n 7 COCO A/D Conversion Complete (0=Busy, 1=Complete) (R)\n 0 PGM EPROM Program Command (0=Normal, 1=Apply Programming Power)\n 1 ELAT EPROM Latch Control (0=Normal/Read, 1=Latch/Write)\n 2-7 RES Reserved for Factory Testing (always 0 in user mode)\n porta.0-7 i/o CXD1815Q.Data (indexed via Port E)\n porta.0 in debug.dta.serial.in ;\\normally unused (exists in early bios)\n porta.1 out debug.dta.serial.out ; (prototype/debug_status stuff)\n porta.2 out debug.clk.serial.out ;/(with portc.5 = debug.select)\n portb.0 in F-BIAS ;unused\n portb.1 in SCEx input (serial 250 baud, received via 1000Hz timer2 irq)\n portb.2 in LMTSW aka /POS0 ;\\pos0 and door switches\n portb.3 in DOOR aka SHELL_OPEN ;/\n portb.4 in TEST2\n portb.5 in TEST1 (CL316) enter test mode (instead of mainloop)\n portb.6 in COUT ;<-- unused, extra pin, not \"SENSE=COUT\"\n portb.7 in CXD2510Q.SENSE ;-from CXD2510Q (and forwarded from CXA1782BR)\n portc.0 in CXD2510Q.SUBQ ;\\\n portc.1 in? NC (SPI.OUT) ; used via SPDR1 to receive SPI bus SUBQ data\n portc.2 out CXD2510Q.SQCK ;/\n portc.3 out SPEED\n portc.4 out =\"SPEED XOR 1\" ... AL/TE ... or CG ... or MIRR ?\n portc.5 out ROMSEL: debug.select (or \"SCLK\" on later boards???)\n portc.6 in CXD1815Q.XINT/IRQ2 ;unused (instead INTSTS bits are polled)\n portc.7 in CXD2510Q.SCOR/IRQ1 ;used via polling INTSR.7 (not as irq)\n portd.0 out NC ;-unused (always 1)\n portd.1 out CXD2510Q.DATA ;\\serial bus for CXD2510Q\n portd.2 out CXD2510Q.XLAT ; (and also forwarded to CXA1782BR)\n portd.3 out CXD2510Q.CLOK ;/\n portd.4 out CXD1815Q.DECCS ;\\\n portd.5 out CXD1815Q.DECWR ; control for data/index on Port A/E\n portd.6 out CXD1815Q.DECRD ;/\n portd.7 out LDON ... IC723.Pin11 ... maybe \"laser on\" ?\n porte.0-4 out CXD1815Q.Index (for data on Port A)\n porte.5 out NC, not used\n porte.6 out NC, see \"idx_4xh\" maybe test signal ???\n porte.7 out? NC, TEST? configured as OUTPUT... but used as INPUT?\n portf.0 out NC, TX ;\\\n portf.1 in NC, RX ; not used by sony's cdrom bios\n portf.2 out NC, RTS ; (but used by motorola's bootstrap rom)\n portf.3 out NC, DTR ;/\n portf.0 in Serial Data In (from daughterboard) ;\\\n portf.1 out Serial Data Out (to daughterboard) ; usage in SCPH-5903\n portf.2 out Serial Clock Out (to daughterboard) ; (PSX with Video CD)\n portf.3 out Audio/Video Select (0=Normal, 1=VCD) ;/\n portf.4-7 - NC, not used (probably pins don't even exist)\n SPI 1 - used for receiving SUBQ (via Port C)\n IRQ 1 - used for latching/polling SUBQ's \"SCOR\" (not used as interrupt)\n IRQ 2 - connects to CXD1815Q.XINT, but isn't actually used at all\n Timer 1 - unused\n Timer 2 - generates 1000Hz interrupts (for 250 baud \"SCEx\" string transfers)\n DDRx - data directions for Port A-F (as listed above)\n52-pin chips are used on LATE-PU-8 boards, and on later boards ranging from PU-18 up to PM-41(2). CDROM Internal HC05 Motorola Selftest Mode (52pin chips)
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#80-pin-hc05-chips-older-psx-cdrom-controllers","title":"80-pin HC05 chips (older psx cdrom controllers)","text":"80-pin chips are used PU-7, EARLY-PU-8, and PU-9 boards. CDROM Internal HC05 Motorola Selftest Mode (80pin chips)
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#32-pin-hc05-chips-joypadmouse","title":"32-pin HC05 chips (joypad/mouse)","text":"Sony's Digital Joypad and Mouse are using 32pin chips (with TQFP-32 package), which are probably containing Motorola HC05 CPUs, too. Unknown if/how those chips can be switched into bootstrap/dumping modes.
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#pinouts","title":"Pinouts","text":"Pinouts - HC05 Pinouts
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cdrom-internal-hc05-motorola-selftest-mode-52pin-chips","title":"CDROM Internal HC05 Motorola Selftest Mode (52pin chips)","text":""},{"location":"cdrominternalinfoonpsxcdromcontroller/#motorola-bootstrap-rom","title":"Motorola Bootstrap ROM","text":"The Motorola MC68HC05 chips are including a small bootstrap ROM which gets activated upon /RESET when having two pins strapped to following levels:
Pin30 PortC.6 (/IRQ2) (/XINT) ----> wire to 3.5V (VCC)\n Pin31 PortC.7 (/IRQ1) (SCOR) ----> wire to 7V (2xVCC)\n Pin16 PortB.0 ----> ModeSelectBit0 (0=GND, 1=3.5V)\n Pin17 PortB.1 ----> ModeSelectBit1 (0=GND, 1=3.5V)\n Mode0: Jump to RAM Address 0040h (useless when RAM is empty)\n Mode1: Semifunctional Selftest (useless)\n Mode2: Upload 200h bytes to RAM & jump to 0040h (allows fast/custom dumping)\n Mode3: Download ROM as ASCII hexdump (nice, but very slow)\n Pin50 PortF.0 ----> TX output (11bytes: 0Dh,0Ah,\" AAAA DD \")\n Pin51 PortF.1 <---- RX input (1byte: \"!\" to request next 11 bytes)\n Pin52 PortF.2 ----> RTS output or so (not needed)\n Pin1 PortF.3 ----> DTR output or so (not needed)\n Ground ------------ GND for RX/TX\nThis mode is very simple and powerful: After /RESET, you send 200h bytes to the RX input (without any response on TX output), the bytes are stored at 0040h..023Fh in RAM, and the chip jumps to 0040h after transferring the last byte. The uploaded program can contain a custum highspeed dumping function, or perform hardware tests, etc. A custom dumping function for PSX/PSone can be found at:
http://www.psxdev.net/forum/viewtopic.php?f=70&t=557\n .------------ pin31, PC7, SCOR, cut the connection\n 39 | 27 to Signal Processor,\n .-----------------. then wire Pin31 to 7.5V\n 40 | | 26\n | C nnnn |\n | SC4309nnPB |\n | G63C 185 |\n pin50, TX <--- | | ---- pin17, PB1, SCEX, wire to 3.5V,\n pin51, RX ---> | | for Mode2 Selection\n 52 | O | 14\n '-----------------'\n 1 13\n CN602.Pin1 = 7.5V ;\\on PSX boards (with either 5pin or\n CN602.Pin3 = 3.5V ;/ 7pin CN602 connectors)\n IC601.Pin1 = 7.5V ;-on PSone boards (3pin 78M05 voltage regulator)\n IC102.Pin32 = 3.5V ;-on PSone boards (32pin Main BIOS ROM chip)\n CXD2510Q.Pin63 (eg. on PU-8 boards) ;\\\n CXD2545Q.Pin74 (eg. on PU-18 boards) ; either one of these, depending\n CXD1817R.Pin49 (eg. on PU-20 boards) ; on which chipset you have\n CXD2938Q.Pin77 (eg. on PM-41 boards) ;\n CXD2941R.Pin85 (eg. PM-41(2) boards) ;/\nThis mode is very slow and not too powerful. But it may useful if you can't get Mode2 working for whatever reason. Wiring for Mode3 is same as above, plus PortB.0=3.5V. In this mode, the chip will send one 0Dh,0Ah,\" AAAA DD \" string immediately after /RESET (with 16bit address \"AAAA\" (initially 1000h), and 8bit data \"DD\"). Thereafter the chip will wait for incoming commands:
4-digit ASCII HEX address --> change address, and return 0Dh,0Ah,\" AAAA DD \"\n chr(00h) --> increment address, and return 0Dh,0Ah,\" AAAA DD \"\n chr(07h) --> jump to current address (not so useful)\n other characters --> same as chr(00h)\n All digits/characters sent to RX input will produce an echo on TX output.\nAnd for anyone else planning to try this, these are the connections:
Pin PortC\n 46 PC7/IRQ1 (SCOR) disconnect from PCB, then wire the pin to Vtst (7.6V)\n 45 PC6/IRQ2 (/XINT) wire to Vdd (3.5V) (you have to solder to the pin)\n Pin PortA DDRA Usage\n 23 PA0 in RXD\n 24 PA1 out TXD\n 25 PA2 in -\n 26 PA3 in Testmode.bit0 (GND=0, 3.5V=1)\n 27 PA4 in Testmode.bit1 (GND=0, 3.5V=1)\n 28 PA5 in Testmode.bit2 (GND=0, 3.5V=1)\n 29 PA6 out RTS (don't care)\n 30 PA7 out -\n PA5 PA4 PA3 Effect\n 0 x x Jump to 0040h ;\\\n 1 0 0 Test (complex) ; not so useful\n 1 0 1 Test (simple loop) ;/\n 1 1 0 ROM Dump 4200h bytes (plain binary, non-ASCII)\n 1 1 1 RAM Upload 100h bytes to 0040h..013Fh, then jump to 0040h\n .------------ pin46, PC7/IRQ1, SCOR, cut & wire to 7.5V\n |.----------- pin45, PC6/IRQ2, wire to 3.5V\n 60 || 41\n .-----------------.\n 61 | o | 40\n | Sony Computer | ,----- pin28, PA5, wire to 3.5V\n | Entertainment | _________/ ,--- pin27, PA4, wire to 3.5V\n | Inc. (C) E35D | ==========='---- pin26, PA3, mode select\n | 4246xx 185 | ----> pin24, PA1, TXD (for ROM dump)\n | | <---- pin23, PA0, RXD (for RAM upload)\n 80 | O | 21\n '-----------------'\n 1 20\n CN602.Pin1 = 7.5V ;\\on PSX boards (with 7pin CN602 connectors)\n CN602.Pin3 = 3.5V ;/\nDTL-H100x uses 80pin chip with onchip PROM (chip text \"(M) MC68HC705L15\", instead of \"Sony [...] 4246xx\"), wiring for serial dumping on that is unknown (the bootstrap ROM may be a little different because it should contain PROM burning functions). PU-9 boards boards seem to use a similar PROM (with some sticker on it). DTL-H2000 uses 80pin CXP82300 chip with socketed piggyback 32pin EPROM - that chip is a Sony SPC700 CPU, not a Motorola HC05 CPU. Accordingly there's no Motorola Bootstrap mode in it, but of course one can simply dump the EPROM with standard eprom utilities, as done by TriMesh).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cdrom-internal-cxd1815q-sub-cpu-configuration-registers","title":"CDROM Internal CXD1815Q Sub-CPU Configuration Registers","text":""},{"location":"cdrominternalinfoonpsxcdromcontroller/#00h-drvif-drive-interface-w","title":"00h - DRVIF - Drive Interface (W)","text":" 0-1 \"L\" Reserved (should be 0)\n 2 LSB 1st CD DSP DATA order (0=MSB first, 1=LSB first)\n 3-4 BCK MD CD DSP Number of BCLKs per WCLK (0=16, 1=24, 2=32, 3=Reserved)\n 5 BCK RED Strobe DATA on BLCK Edge (0=Falling Edge, 1=Rising Edge)\n 6 LCH LOW Channel on LRCK=Low (0=Right, 1=Left)\n 7 C2PL1st ... C2PO lower byte 1st\n 0 HCLKDIS HCLK Pin Output (0=8.4672MHz, 1=Disable; Fixed Low)\n 1 CLKDIS CLK Pin Output (0=16.9344MHz, 1=Disable; Fixed Low)\n 2 9BITRAM SRAM Databus width (0=8bit/normal, 1=9bit)\n 3-4 RAM SZ SRMA Address bus (0=32K, 1=64K, 2=128K, 3=Reserved)\n 5 PRTYCTL ... Priority Control\n 6 XSLOW Number of clock cycles per DMA cycle (0=12, 1=4) (for SRAM)\n 7 \"L\" Reserved (should be 0)\n 0 \"L\" Reserved (should be 0)\n 1 DACODIS .... DAC Out Disable\n 2 DAMIXEN Digital Audio Mixer Enable (0=Attentuator/Mixer for CD-DA, 1=No)\n 3 SMBF2 Number of Sound Map Buffer Surfaces (0=Three, 1=Two)\n 4 SPMCTL Sound Parameter Majority Control (0=?) ;\\for ADPCM params\n 5 SPECTL Sound Parameter Error Control (0=?) ;/\n 6-7 \"L\" Reserved (should be 0)\n 0-2 DECMD Decoder Mode (0-7)\n 0 or 1 Decoder Disable ;-disable sector reading\n 2 or 3 Monitor-only Mode ;\\no error correction\n 4 Write-only Mode ;/\n 5 Real-time Correction Mode ;\\with error correction\n 6 Repeat Correction Mode ;/\n 7 CD-DA Mode ;-audio\n 3 AUTODIST Auto Distinction (0=Use MODESEL/FORMSEL bits, 1=Use Sector Hdr)\n (Error Correction is done according to above MODE/FORM values)\n 4 FORMSEL Form Select (0=FORM1, 1=FORM2) (must be 0 for MODE1)\n 5 MODESEL Mode Select (0=MODE1, 1=MODE2)\n 6 ECCSTR ECC Strategy (0=Normal, 1=Use Error Flags; requires 9bit SRAM)\n 7 ENDLADR Enable Drive Last Address ...\n 0 \"L\" Reserved (should be 0)\n 1 DBLSPD Double Speed Mode (0=Normal, 1=Double) (init CD DSP first)\n 2 RPSTART Repeat Correction Start (0=No, 1=Start) (automatically cleared)\n 3 SWOPEN Sync Window Open (0=SyncControlledByIC, 1=OpenDetectionWindow)\n 4 CD-DA CD-DA Play (0=No, 1=Playback CD-DA as audio)\n 5 CDDAMUTE CD-DA Mute (0=Normal, 1=Mute CD-DA Audio)\n 6 RTMUTE Real-time Mute (0=Normal, 1=Mute CDROM ADPCM)\n 7 SMMUTE Sound Map Mute (0=Normal, 1=Mute Sound Map ADPCM)\n 0 CFORM FORM assumed by Error Correction (0=FORM1, 1=FORM2)\n 1 CMODE MODE assumed by Error Correction (0=MODE1, 1=MODE2)\n 2 ECCOK ECC Okay (0=Bad, 1=Okay)\n 3 EDCOK EDC Okay (0=Bad, 1=Okay)\n 4 CORDONE Correction Done (0=None, 1=Error occurred and was corrected)\n 5 CORINH Correction Inhibit (0=Okay,1=AUTODIST couldn't determine MODE/FORM)\n 6 ERINBLK Erasure in Block (0=Okay, 1=At least 1 byte is wrong & uncorrected)\n 7 EDCALL0 EDC all-zero (0=No/EDC Exists, 1=Yes/All four EDC bytes are 00h)\n 0 NOSYNC No Sync (0=Okay, 1=Sector Sync Mark Missing)\n 1 SHRTSCT Short Sector (0=Okay, 1=Sector Sync Mark within Sector Data)\n 2-4 - Reserved (undefined)\n 5 RTADPBSY Real-time ADPCM Busy (0=No, 1=Busy/playback)\n 6-7 - Reserved (undefined)\n 0 CI Error in 4th Subheader byte (Coding Info) (0=Okay, 1=Error)\n 1 SUBMODE Error in 3rd Subheader byte (Submode) (0=Okay, 1=Error)\n 2 CHANNEL Error in 2nd Subheader byte (Channel) (0=Okay, 1=Error)\n 3 FILE Error in 1st Subheader byte (File) (0=Okay, 1=Error)\n 4 MODE Error in 4th Header byte (MODE) (0=Okay, 1=Error)\n 5 BLOCK Error in 3rd Header byte (FF) (0=Okay, 1=Error)\n 6 SEC Error in 2nd Header byte (SS) (0=Okay, 1=Error)\n 7 MIN Error in 1st Header byte (MM) (0=Okay, 1=Error)\n 1st read: 1st Header byte (MM)\n 2nd read: 2nd Header byte (SS)\n 3rd read: 3rd Header byte (FF)\n 4th read: 4th Header byte (MODE)\n 1st read: 1st Subheader byte (File)\n 2nd read: 2nd Subheader byte (Channel)\n 3rd read: 3rd Subheader byte (Submode) (SM)\n 4th read: 4th Subheader byte (Coding Info) (CI)\n (1) The corrected value in the real-time correction or\n repeat correction mode\n (2) Value of the raw data from the drive in the monitor-only\n or write-only mode\n The CMOME? and CMODE bits (bits 1, 0) of ECCSTS indicate the FORM and MODE\n of the sector the decoder has discriminated by the raw data from the drive.\n Due to erroneous correction, the values of these bits may be at variance\n with those of the HDR register MODE byte and SHDR register submode byte\n bit5.\nUnknown when 1st..4th read indices are reset for HDR and SHDR (maybe on access to certain I/O ports, or maybe anytime when receiving a new sector), also unknown what happens on 5th read and up.
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cdrom-internal-cxd1815q-sub-cpu-address-registers","title":"CDROM Internal CXD1815Q Sub-CPU Address Registers","text":"Drive Address -- used for storing incoming CDROM sectors in Buffer RAM Host Address -- used for transferring Buffer RAM to (or from) Main CPU ADPCM Address -- used for Real-time ADPCM audio output from Buffer RAM
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#05h-cmadr-drive-current-minute-address-r","title":"05h - CMADR - Drive Current Minute Address (R)","text":" 0-6 CMADR Address bit10-16 (in 1Kbyte steps)\n 7 - Reserved (undefined)\n HADR = (CMADR AND 7Fh)*400h+offset\n HXFR = length OR 4000h\n ADPMNT = (CMADR AND 7Fh) OR 80h\n 0-6 ADPxxx ADPCM source Address bit10-16 (in 1Kbyte-steps)\n 7 RTADPEN Real-time ADPCM Enable (0=Disable, 1=Enable Real-time ADPCM)\n 0-16 DLADR Addr. bit0-16 ...\n 17-23 \"L\" Reserved (should be 0)\n 0-16 DADRC Incrementing Drive-to-Buffer Write Address, bit0-16\n 17-23 \"L\" Reserved (should be 0)\n 0-15 DADRC Address bit0-15 ;bit16 is in Port 0Bh ...\n 0-11 HXFR number of data bytes, bit0-11 (0..FFFh) ...\n 12 HADR.16 HADR bit16\n 13 \"L\" Reserved (should be 0)\n 14 \"L\" ?? Reserved (should be 0) ;<-- XXX but on PSX: Always 1 !?!\n ; seems to Disable INT8 ?!!!\n 15 DISHXFRC Disable HXFRC (0=Use HXFRC, 1=Disable, Infinite-or-Zero Len?)\n 0-15 HADR Addr. bit0-15 ;bit16 in Port 0Dh ...\n 0-11 HXFRC Host Transfer Counter bit0-11 (number of remaining bytes)\n 12 HADRC bit16 ;MSB of Port 0Ch/0Dh\n 13 DADRC bit16 ;MSB of Port 0Eh/0Fh\n 14-15 - Reserved (undefined) (usually both bits set)\n 0-15 HADRC Address bit0-15 ;bit16 is in Port 0Bh\nWhen reading from SRAM, data seems to go through a 8-byte data fifo, the HXFRC (remain) and HADRC (addr) values aren't aware of that FIFO (ie. if there's data in the fifo, then addr will be 8 bigger and remain 8 smaller than what has arrived at the host).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#unclear-notes","title":"Unclear Notes","text":"\"If sound map data is to be transferred before the data is transferred (immediately after the host has set the BFRD and BFWR bits (bits 7 and 6) of the HCHPCTL register high)\":
900h is loaded into HXFRC\n and 600Ch, 6A0Ch, or 740Ch is loaded into HADRC\n (at least, supposedly, above addresses , for cases when using 32K SRAM)\n HADR and HXFR are loaded into HADRC and HXFRC\n 0000h 1st Sector (at 0000h..0923h) (unused gap at 0924h..0BFFh)\n 0C00h 2nd Sector (at 0C00h..1523h) (unused gap at 1524h..17FFh)\n 1800h 3rd Sector (at 1800h..2123h) (unused gap at 2124h..23FFh)\n 2400h 4th Sector (at 2400h..2D23h) (unused gap at 2D24h..2FFFh)\n 3000h 5th Sector (at 3000h..3923h) (unused gap at 3924h..3BFFh)\n 3C00h 6th Sector (at 3C00h..4523h) (unused gap at 4524h..47FFh)\n 4800h 7th Sector (at 4800h..5123h) (unused gap at 5124h..53FFh)\n 5400h 8th Sector (at 5400h..5D23h) (unused gap at 5D24h..5FFFh)\n 6000h Soundmap ADPCM Buffer (at 600Ch..690Bh) (gaps at 6000h and 690Ch)\n 6A00h Soundmap ADPCM Buffer (at 6A0Ch..730Bh) (gaps at 6A00h and 730Ch)\n 7400h Soundmap ADPCM Buffer (at 740Ch..7D0Bh) (gaps at 7400h and 7D0Ch)\n 7E00h Unknown/Unused\n 0-2 HINT Request Host Interrupt (INT1..INT7, or 0=None/No change)\n 3-7 \"L\" Reserved (should be 0)\n 0-2 HINTSTS Pending Host Interrupt (INT1..INT7, or 0=None/All acknowledged)\n 3 DMABUSY DMA Busy (0=Data FIFO Empty and HXFRC=0, 1=Data Transfer Busy)\n 4 PRMRRDY Parameter Read Ready (0=Parameter FIFO Empty, 1=Ready/Not Empty)\n 5 RSLEMPT Result Empty (0=Response FIFO Not Empty, 1=Empty)\n 6 RSLWRDY Result Write Ready (0=Response FIFO Full, 1=Ready/Not Full)\n 7 BUSYSTS Command Busy Status (0=Command Not Empty, 1=Ack'ed by CLRBUSY)\n 0 RESYNC Sync with CD DSP (0=No change, 1=Resync, eg. after speed change)\n 1-3 \"L\" Reserved (should be 0)\n 4 RTADPCLR Abort Real-time ADPCM (0=No Change, 1=Abort; when ADPMNT.7=0)\n 5 CLRRSLT Clear Reply FIFO (0=No change, 1=Acknowledge; clear FIFO)\n 6 CLRBUSY Acknowledge Command (0=No change, 1=Acknowledge; clear BUSYSTS)\n 7 CHPRST Chip Reset (0=No change, 1=Do Chip Initialization)\n 0 HCRISD Host Chip Reset Issued\n 1 HSTCMND Host Command ...\n 2 DECINT Decoder Interrupt ..\n 3 HDMACMP Host DMA Complete . <-- PSX: used for retry ?!?!!!\n 4 RTADPEND Real-time ADPCM end\n 5 RSLTEMPT Result Empty\n 6 DECTOUT Decoder Time Out\n 7 DRVOVRN Drive Overrun\n 0-7 Param FIFO (check HIFSTS.4 to see if the FIFO is empty)\n 0-7 Command (check INTSTS.1 or HIFSTS.7 to see if a command was sent)\n 0-7 Data (has 8-byte FIFO)\n 0 S/M ADPCM Stereo/Mono (0=Mono, 1=Stereo)\n 1 - Reserved (undefined)\n 2 FS ADPCM Sampling Frequency (0=37.8kHz, 1=18.9kHz)\n 3 - Reserved (undefined)\n 4 BITLNGTH ADPCM Sample Bit Length (0=Normal/4bit, 1=8bit)\n 5 ADPBUSY ADPCM Decoding (0=No, 1=Yes/Busy)\n 6 EMPHASIS ADPCM Emphasis (0=Normal/Off, 1=On)\n 7 MUTE DA Data is Muted (uh?) (0=No, 1=Yes/Muted)\n 0 S/M ADPCM Stereo/Mono (0=Mono, 1=Stereo)\n 1 \"L\" Reserved (should be 0)\n 2 FS ADPCM Sampling Frequency (0=37.8kHz, 1=18.9kHz)\n 3 \"L\" Reserved (should be 0)\n 4 BITLNGTH ADPCM Sample Bit Length (0=Normal/4bit, 1=8bit)\n 5 \"L\" Reserved (should be 0)\n 6 EMPHASIS ADPCM Emphasis (0=Normal/Off, 1=On)\n 7 \"L\" Reserved (should be 0)\n 0-7 Reserved (undefined)\n 0-7 Reserved (should be 00h) (or don't write at all)\n 23-20 4bit Command (00h)\n 19 1bit FS4 Focus Servo (0=Off, 1=On)\n 18 1bit FS3 DEFECT\n 17 1bit FS2 Enable Focus Search Voltage (0=Off, 1=On)\n 16 1bit FS1 Select Focus Search Voltage (0=Falling, 1=Rising)\n 15-0 16bit Unused (don't care)\n 23-20 4bit Command (01h)\n 19 1bit TG1,TG2 ON/OFF Tracking Servo Gain Up/Normal (hmmm?)\n 18 1bit Brake Circuit ON/OFF\n 17-16 2bit PS Sled Kick Height (0=+/-1, 1=+/-2, 2=Undoc, 3=\"Don't use\"?)\n 15-0 16bit Unused (don't care)\n 23-20 4bit Command (02h)\n 19-18 2bit Tracking Control (0=Off, 1=Servo On, 2=F-Jump, 3=R-Jump) ;TM1,3,4\n 17-16 2bit Sled Control (0=Off, 1=Servo On, 2=F-Fast, 3=R-Fast) ;TM2,5,6\n 15-0 16bit Unused (don't care)\n 23-20 4bit Command (03h)\n 19 1bit Value to be adjusted (0=Balance, 1=Gain)\n 18-16 3bit New Balance or Gain value (depending on above bit)\n 15-0 16bit Unused (don't care)\n N-N 4bit Command (04h..07h)\n N-N 4bit Command (08h..0Fh)\nThe Servo Amplifier isn't directly connected to the CPU. Instead, it's connected as a slave device to the Signal Processor. There are two ways to access the Servo Amplifier: 1) The CPU can send CX(0X..3X) commands to the Signal Processor (which will then forward them to the Servo Amplifier). 2) The Signal Processor can send CX(0X..3X) commands to the Servo Amplifier (this happens during CX(4xxx) Auto Sequence command).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cdrom-internal-commands-cx4xex-cxd2510q-signal-processor","title":"CDROM Internal Commands CX(4x..Ex) - CXD2510Q Signal Processor","text":""},{"location":"cdrominternalinfoonpsxcdromcontroller/#cxd2510q-cx4xxx-auto-sequence","title":"CXD2510Q - CX(4xxx) - Auto Sequence","text":" 23-20 4bit Command (4)\n 19-16 4bit AS3-0 Auto Sequence Command (see below)\n 15-12 4bit MT3-0 Max Timer Value (N timer units, or 0=Invalidate Timer)\n 11 1bit LSSL Timer Units (0=2.9ms, 1=186ms) (for above MT value)\n 10-8 3bit Unused (zero)\n 7-0 8bit Unused (don't care)\n 00h Cancel\n 04h/05h Forward/Reverse Fine Search ;<--sends CX(25h) ;\\these do internally\n 07h Focus-On ;<--sends CX(02h) ; send commands to\n 08h/09h Forward/Reverse 1 Track Jump ;\\ ; CXA1782BR\n 0Ah/0Bh Forward/Reverse 10 Track Jump ; sends CX(25h) ; and, auto sequence\n 0Ch/0Dh Forward/Reverse 2N Track Jump ;/ ;/is interrupted?\n 0Eh/0Fh Forward/Reverse 1N Track Move ;<--CXD2545Q only(Reserved on CXD2510Q)\n 01h..03h,06h = Reserved\n 23-20 4bit Command (5)\n 19-16 4bit TR3-0 Timer (N*0.022ms for Blind/Overflow, N*0.045ms for Brake)\n 15-8 8bit Unused (don't care on CXD2510Q, zero on CXD2545Q)\n 7-0 8bit Unused (don't care)\n 23-20 4bit Command (6)\n 19-16 4bit SD3-0 Timer KICK.D (N*2.9ms for Fine Search? else N*1.45ms?)\n 15-12 4bit KF3-0 Timer KICK.F (N*0.09ms)\n 11-8 4bit Unused (don't care on CXD2510Q, zero on CXD2545Q)\n 7-0 8bit Unused (don't care)\n 23-20 4bit Command (7)\n 19-4 16bit Track Jump Count Setting (0..65535) for Command 4x\n 3-0 4bit Unused (don't care)\n 23-20 4bit Command (8)\n 19 1bit CDROM (0=Audio, 1=CDROM; no average and pre-value stuff)\n 18 1bit DOUT Mute (0=Not muted, 1=Mute DOUT)\n 17 1bit D.out Mute-F (0=Not muted, 1=Mute DA)\n 16 1bit WSEL (0=Enhanced Sync Window, 1=Enhanced Anti-Rolling)\n 15 1bit VCO SEL (0=Double Correction, 1=Quadruple Correction)\n 14 1bit ASHS (0=Double Correction, 1=Quadruple Correction)\n 13 1bit SOCT (0=Output SubQ to SQSO, 1=Output Each? to SQSO)\n 12 1bit Unused (zero)\n 11-8 4bit Unused (don't care on CXD2510Q, zero on CXD2545Q)\n 7-0 8bit Unused (don't care)\n 23-20 4bit Command (9)\n 19 1bit DCLV ON-OFF (complex stuff, related to gain and frequencies)\n 18 1bit DSPB ON-OFF (0=Normal Speed, 1=Double Speed; fixed pitch)\n 17 1bit ASEQ ON-OFF (select output on SENS pin)\n 16 1bit DPLL ON-OFF (0=Analog RFPLL, 1=Digital RFPLL)\n 15-14 1bit Bilingual Audio (0=Stereo, 1=RightOnly, 2=LeftOnly, 3=Mute)\n 13 1bit FLFC (normally 0)\n 12 1bit Unused (zero)\n 11-8 4bit Unused (don't care on CXD2510Q, zero on CXD2545Q)\n 7-0 8bit Unused (don't care)\n 23-20 4bit Command (0Ah)\n 19 1bit Vari Up (write 1-then-0 to increase pitch by +0.1%)\n 18 1bit Vari Down (write 1-then-0 to decrease pitch by -0.1%)\n 17 1bit Mute (0=Not muted; unless muted elsewhere, 1=Mute & Peak=0)\n 16 1bit ATT (0=Attentuation off, 1=Minus 12 dB)\n 15-14 2bit PCT (0=Normal, 1=LevelMeter, 2=PeakMeter, 3=Normal) (0-1=QuadC2)\n 13-12 2bit Unused (zero)\n 11-8 4bit Unused (don't care on CXD2510Q, zero on CXD2545Q)\n 7-0 8bit Unused (don't care)\n 23-20 4bit Command (0Bh)\n 19-4 16bit Traverse Monitor Count (used when monitored by COMP and COUT) (?)\n 3-0 4bit Unused (don't care)\n 23-20 4bit Command (0Ch)\n 19-18 2bit Gain MDP for CLVP mode (0=-6db, 1=0dB, 1=+6dB, 3=Reserved)\n 17-16 2bit Gain MDS for CLVS/CLVP (0=-12dB, 1=-6dB, 2=0dB, 3=Reserved)\n 15 1bit Zero (zero)\n 14 1bit Gain DCLV0 overall gain (0=0dB, 1=+6dB\n 13-12 2bit Unused (zero)\n 11-8 4bit Unused (don't care on CXD2510Q, zero on CXD2545Q)\n 7-0 8bit Unused (don't care)\n 23-20 4bit Command (0Dh)\n 19 1bit DCLV PWM MD Digital CLV PWM mode (0=Use MDS+MDP, 1=Ternary MDP)\n 18 1bit TB Bottom Hold in CLVS/CLVH modes (0=At cycle RFCK/32, 1=RFCK/16)\n 17 1bit TP Peak Hold in CLVS mode (0=At cycle RFCK/4, 1=RFCK/2)\n 16 1bit Gain CLVS for CLVS mode (0=0dB, 1=+6dB)(always +6dB in CLVP mode)\n 15-8 8bit Unused (don't care on CXD2510Q, zero on CXD2545Q)\n 7-0 8bit Unused (don't care)\n 23-20 4bit Command (0Eh)\n 19-16 4bit CM3-0\n 15-8 8bit Unused (don't care on CXD2510Q, zero on CXD2545Q)\n 7-0 8bit Unused (don't care)\n 00h Stop Spindle Motor Stop mode\n 06h CLVA Automatic CLVS/CLVP switching mode, normally used for playback\n 08h Kick Spindle Motor Forward rotation mode\n 0Ah Brake Spindle Motor Reverse rotation mode\n 0Ch CLVH Peak hold at 34kHz\n 0Eh CLVS Rough Servo Mode, RF-PLL related\n 0Fh CLVP PLL Servo mode\n 23-0 N/A Don't use\n 80bit subq\n 15bit peak level (lsb first) (absolute/unsigned value)\n 1bit peak l/r flag (aka appears as \"MSB\" of peak level)\n Index ASEQ=0 ASEQ=1 ;<-- ASEQ can be set via CX(9xx)\n 0X HighZ SEIN (FZC) ;\\aka SENS output\n 1X HighZ SEIN (A.S) ... aka DEFECT ; from CXA1782BR\n 2X HighZ SEIN (T.Z.C) ... aka TZC ; forwarded through\n 3X HighZ SEIN (SSTOP) ... aka Gain/Bal ;/CXD2510Q\n 4X HighZ XBUSY\n 5X HighZ FOK\n 6X HighZ SEIN (HighZ)\n AX GFS GFS\n BX COMP COMP\n CX COUT COUT\n EX /OV64 /OV64\n 7X-9X,DX,FX HighZ 0\n FZC Focus Zero Cross\n DEFECT Defect?\n TZC Tracking Zero Cross\n SSTOP Gain or Balance adjust reached wanted level\n XBUSY Low while the auto sequencer operation is busy\n FOK High for \"focus OK\" (same as FOK pin)\n GFS High when the played back frame sync is obtained with correct timing\n COMP Measures the number of tracks set with Reg B. High when Reg B is\n latched, low when the initial Reg B number is input by CNIN\n COUT Measures the number of tracks set with Reg B. High when Reg B is\n latched, toggles each time the Reg B number is input by CNIN. While\n $44 and $45 are being executed, toggles with each CNIN 8-count\n instead of the Reg B number\n OV64 Low when filtered EFM signal is lengthened by 64 channel clock\n pulses or more\nCDROM Internal Commands CX(0x..3x) - CXA1782BR Servo Amplifier
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cxd2545q-cx4xex-same-as-cxd2510q-signal-processor","title":"CXD2545Q - CX(4x..Ex) - same as CXD2510Q Signal Processor","text":"CDROM Internal Commands CX(4x..Ex) - CXD2510Q Signal Processor One small difference is that the CXD2545Q supports a new \"M Track Move\" function as part of the CX(4xxx) command. And, some \"don't care\" bits are now reserved (ie. some commands need to be padded with additional leading \"0\" bits).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cxd2545q-cx1x-anti-shockbraketracking-gainfilter","title":"CXD2545Q - CX(1x) - Anti Shock/Brake/Tracking Gain/Filter","text":" 23-20 4bit Command (01h)\n 19 1bit Anti Shock (0=Off, 1=On)\n 18 1bit Brake (0=Off, 1=On)\n 17 1bit Tracking Gain (0=Normal, 1=Up)\n 16 1bit Tracking Gain Filter (0=Select 1, 1=Select 2)\n 15-0 16bit Unused (don't care)\n 23-20 4bit Command (03h)\n 19-18 2bit Subcommand (0)\n 17-16 2bit Sled Kick Level (0=+/-1, 1=+/-2, 2=+/-3, 3=+/-4)\n 15-0 16bit Unused (don't care)\n 23-16 8bit Command (34h)\n 15 1bit Zero (0)\n 14-8 7bit Address (00h..4Fh = Select Coefficient K00..K4F)\n 7-0 8bit Data (00h..FFh = New value)\n PLUS 8bit Eight more bits on PSone (!)\n 23-12 12bit Command (34Fh)\n 11-10 2bit Index (0=TRVSC, 1=FBIAS, 2=?, 3=?)\n 9-0 10bit Data (for FBIAS: bit0=don't care)\n 23-16 8bit Command (35h)\n 15-14 2bit FT Focus Search-up speed 1\n 13-8 6bit FS Focus Search limit voltage (default 011000b) (+/-1.875V)\n 7 1bit FTZ Focus Search-up speed 2\n 6-0 7bit FG AGF Convergence Gain Setting (default 0101101b)\n 23-16 8bit Command (36h)\n 15 1bit Zero (0)\n 14 1bit DTZC DTZC Delay (0=4.25us/Default, 1=8.5us)\n 13-8 6bit TJ Track Jump voltage (default 001110b) (+/-1.09V)\n 7 1bit Zero (0)\n 6-0 7bit TG AGT Convergence Gain Setting (default 0101110b)\n 23-16 8bit Command (37h)\n 15-14 2bit FZS XXX pg. 84\n 13-8 6bit SM Sled Move Voltage\n 7 1bit AGS\n 6 1bit AGJ\n 5 1bit AGGF\n 4 1bit AGGT\n 3 1bit AGV1\n 2 1bit AGV2\n 1 1bit AGHS\n 0 1bit AGHT\n 23-16 8bit Command (38h)\n 15 1bit VCLM VC level measurement on/off\n 14 1bit VCLC VC level compensation for FCS_In Register on/off\n 13 1bit FLM Focus zero level measurement on/off\n 12 1bit FLC0 Focus zero level compensation for FZC Register on/off\n 11 1bit RFLM RF zero level measurement on/off\n 10 1bit RFLC RF zero level compensation on/off\n 9 1bit AGF Focus automatic gain adjustment on/off\n 8 1bit AGT Tracking automatic gain adjustment on/off\n 7 1bit DFSW Defect switch disable (1=disable defect measurement)\n 6 1bit LKSW Lock switch (1=disable sled free-running prevention)\n 5 1bit TBLM Traverse center measurement on/off\n 4 1bit TCLM Tracking zero level measurement on/off\n 3 1bit FLC1 Focus zero level compensation for FCS_In Register on/off\n 2 1bit TLC2 Traverse center compensation on/off\n 1 1bit TLC1 Tracking zero level compensation on/off\n 0 1bit TLC0 VC level compensation for TRK/SLD_In register on/off\n 23-16 8bit Command (39h)\n 15 1bit DAC Serial data readout DAC mode on/off\n 14-8 7bit SD Serial readout data select (see below)\n 7-0 8bit Unused (don't care)\n Addr Data Content\n 00h 8bit VC input signal\n 01h 8bit SE input signal\n 02h 8bit TE input signal\n 03h 8bit FE input signal\n 04h-07h 9bit TE AVRG register (mirrored to 04h-07h)\n 08h-0Bh 9bit FE AVRG register (mirrored to 08h-0Bh)\n 0Ch-0Fh 9bit VC AVRG register (mirrored to 0Ch-0Fh)\n 12h 8bit RFDC envelope (peak)\n 13h 8bit RFDC envelope (bottom)\n 1Ch 9bit TRVSC register\n 1Dh 9bit FBIAS register\n 1Eh 8bit RFDC input signal\n 1Fh 8bit RF AVRG register\n 20h-3Fh 16bit Data RAM (M00-M1F)\n 40h-7Fh 8bit Coefficient RAM (K00-K3F) (note: K40-K4F cannot be read out)\n 23-16 8bit Command (3Ah)\n 15 1bit Zero (0)\n 14 1bit FBON: FBIAS register addition (0=off, 1=Add FBIAS to FCS)\n 13-0 14bit Zero (0)\n 23-16 8bit Command (3Bh)\n 15-14 2bit SFO FOK Slice Level (...depends on SFOX)\n 13-12 2bit SDF DFCT Slice Level (0=89mV, 1=134mV, 2=179mV, 3=224mV)\n 11-10 2bit MAX DFCT Maximum Time (0=No Limit, 1=2ms, 2=2.36ms, 3=2.72ms)\n 9 1bit SFOX FOK Slice Level (...depends on SFO)\n 8 1bit BTF Bottom Hold Double-Speed Count-Up mode for MIRR (0=off)\n 7-6 2bit D2V Peak Hold 2 for DFCT (0=22.05kHz, 1=44.1, 2=88.2, 3=176.4)\n 5-4 2bit D1V Peak Hold 1 for DFCT (0=176.4kHz, 1=352.8, 2=705.6, 3=1411)\n 3-0 4bit Zero (0)\n 23-16 8bit Command (3Ch)\n 15-0 16bit Unused (don't care)\n 23-16 8bit Command (3Dh)\n 15-0 16bit Unused (don't care)\n 23-16 8bit Command (3Eh)\n 15-14 2bit F1NDM FCS servo filter 1st stage (1=normal, 2=down)\n 13-12 2bit F3NUM FCS servo filter 3rd stage (1=normal, 2=up)\n 11-10 2bit T1NDM TRK servo filter 1st stage (1=normal, 2=down)\n 9-8 2bit T3NUM TRK servo filter 3rd stage (1=normal, 2=up)\n 7 1bit DFIS FCS hold filter input extraction node (0=M05, 1=M04)\n 6 1bit TLCD Mask TLC2 set by D2 of CX(38) only when FOK low\n 5 1bit RFLP Pass signal from RFDC pin through low-pass-filter\n 4-0 5bit Zero (0)\n 23-16 8bit Command (3Fh) ... XXX pg. 89\n 15-14 2bit Unused (0)\n 13-12 2bit XTD\n 11 1bit Unused (0)\n 10-8 3bit DRR\n 7 1bit Unused (0)\n 6 1bit ASFG\n 5 1bit Unused (0)\n 4 1bit LPAS\n 3-2 2bit SRO\n 1-0 2bit Unused (0)\nXXX
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cxd2545q-sens-output","title":"CXD2545Q - SENS output","text":" Index ASEQ=0 ASEQ=1 Length\n $0X Z FZC -\n $1X Z AS -\n $2X Z TZC -\n $38 Z AGOK*1 -\n $38 Z XAVEBSY*1 -\n $30-37,$3A-3F Z SSTP -\n $3904 Z TE Avrg Reg. 9 bit\n $3908 Z FE Avrg Reg. 9 bit\n $390C Z VC Avrg Reg. 9 bit\n $391C Z TRVSC Reg. 9 bit\n $391D Z FB Reg. 9 bit\n $391F Z RFDC Avrg Reg. 8 bit\n $4X Z XBUSY -\n $5X Z FOK -\n $6X Z 0 -\n $AX GFS GFS -\n $BX COMP COMP -\n $CX COUT COUT -\n $EX OV64 OV64 -\n $7X-9X,DX,FX Z 0 -\nMost commands are same as on CXD2545Q. New/changed commands are:
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cxd2938q-cx349xxxxx-new-scex","title":"CXD2938Q - CX(349xxxxx) - New SCEx","text":"Older PSX consoles have received the \"SCEx\" string at 250 baud via HC05 PortB.bit1, which allowed modchips to injected faked \"SCEx\" signals to that pin. To prevent that, the CXD2938Q contains some new 32bit commands that allow to receive somewhat encrypted \"SCEx\" strings via SPI bus. The used commands are:
CX(34910000) NewScexStopReading\n CX(3491xy80) NewScexRandomKey(xy)\n CX(34920000) NewScexFlushResyncOrSo\n CX(34944A00) NewScexInitValue1\n CX(3498C000) NewScexInitValue2\n CX(349C1000) NewScexThis ;\\inverse ;\\use CX(3C2080) for COUT selection\n CX(349D1000) NewScexThat ;/of COUT ;/\n 1st byte: Unknown/unused (normally ADR/Control) ;\\these should be probably\n 2nd byte: Unknown/unused (normally Track) ; set to some invalid values\n 3rd byte: Unknown/unused (normally Index/Point) ;/to avoid SUB-Q confusion\n 4th..10th byte: SCEx data or Dummy bytes (depending on xy.bit7..1)\n 11th..12th byte: Unknown/unused (normally Audio Peak level)\nSame as in older version, but initialized slightly differently: CXD2545Q used CX(3B2250) whilst CXD2938Q is using CX(3B7250).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cxd2938q-cx3cxxxx-tzccoutselect-with-newchanged-extra-bits","title":"CXD2938Q - CX(3Cxxxx) - TzcCoutSelect with New/Changed Extra Bits","text":"The CXD2545Q used two 8bit commands, CX(3C) and CX(3D), for TzcOut selection, which are now replaced by a single 24bit command, CX(3Cxxxx), and which do include a new mode related to New SCEx.
CXD2545Q CXD2938Q\n CX(3C) CX(3C0080) TzcCoutSelectHPTZC;\\ <--formerly CX(3C)\n - CX(3C2080) TzcCoutSelectSCEX ; <--special NewScex mode\n CX(3D) CX(3C4080) TzcCoutSelectDTZC ;/ <--formerly CX(3D)\nCommand CX(8xx) has been 12bit wide on CXD2545Q, and is now expanded 24bit width (with some changed/unknown bits).
CXD2545Q CXD2938Q\n CX(8180) CX(810408) MODE = Audio (CD-DA)\n CX(8120) CX(812400) MODE = Audio (CD-DA) (manual SPI bus access)\n CX(8980) CX(890408) MODE = CDROM (Data)\n - CX(898000) MODE = CDROM (Data) (used on RESET)\nCommand CX(9xx) has been 12bit wide on CXD2545Q (with bit12=reserved/zero), and is now expanded 24bit width (with bit12=unknown/one and bit11-0=unknown/zero).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cxd2938q-cxdx0000-and-cxex0000-new-zero-padding","title":"CXD2938Q - CX(Dx0000) and CX(Ex0000) - New Zero Padding","text":"Commands CX(Dx) and CX(Ex) have been 8bit wide on CXD2545Q, and are now zeropadded to 24bit width, ie. CX(Dx0000) and CX(Ex0000). Unknown if the extra bits are hiding any extra features. In practice, the CDROM BIOS is always setting them zero (except in some test commands which are accidently still using the old 8bit form, resulting in garbage in lower 16bits).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cdrom-internal-commands-cxxx-notes","title":"CDROM Internal Commands CX(xx) - Notes","text":""},{"location":"cdrominternalinfoonpsxcdromcontroller/#serial-command-transmission-for-signal-processor-and-servo-amplifier","title":"Serial Command Transmission (for Signal Processor and Servo Amplifier)","text":"Commands are sent serially LSB first via DATA,CLOK,XLAT pins: DATA+CLOK are used to send commands to the chip, command execution is then applied by dragging XLAT low for a moment. Commands can be up to 24bits in length, but unused LSBs (the \"don't care\" bits) can be omitted; the PSX BIOS clips the length to 8bit/16bit where possible (due to the LSB-first transfer order, the chip does treat the most recently transferred bit as MSB=bit23, and there's no need to transfer the LSBs if they aren't used). Aside from being used as command number, the four most recently transferred bits are also used to select SENS status feedback (for the SENS selection it doesn't matter if the four bits were terminated by XLAT or not).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#sled-motor-track-jumps-tracking","title":"Sled Motor / Track Jumps / Tracking","text":"The Sled motor moves the drive head to the current read position. On a Compact Disc, the term \"Track\" does normally refer to Audio tracks (songs). But the drive hardware uses the terms \"Track\" and \"Tracking\" for different purposes: Tracking appears to refer to moving the Optics via magnets (ie. moving only the laser/lens, without actually moving the whole sled) (this is done for fine adjustments, and it seems to happen more or less automatically; emulators can just return increasing sectors without needing to handle special tracking commands). Track jumps refer to moving the entire Sled, one \"track\" is equal to one spiral winding (1.6 micrometers). One winding contains between 9 sectors on innermost windings, and 22.5 sectors on outermost windings (the PSX cdrom bios is translating the sector-distance to non-linear track-distance, and emulators must undo that translation; otherwise the sled doesn't arrive at the intended location; the cdrom bios will retry seeking a couple of times and eventually settle down at the desired location - but it will timeout if the sled emulation is too inaccurate). The PSX hardware uses two mechanisms for moving the Sled: Command CX(4xxx) Forward/Reverse Track Jump: allows to move the sled by 1..131070 tracks (ie. max 210 millimeters), and the hardware does stop automatically after reaching the desired distance. Command CX(2x) Forward/Reverse Fast Sled: moves the sled continously until it gets stopped by another command (in this mode, software can watch the COUT signal, which gets toggled each \"N\" tracks; whereas \"N\" can be selected via Command CX(Bxxxx), which is configured to N=100h in PSX). The PSX cdrom bios is issuing another Fast Sled command (in opposite direction) after Fast Sled commands, emulators must somehow interprete this as \"sled slowdown\" (rather than as actually moving the sled in opposite direction, which could move the sled miles away from the target). For some reason vC1 BIOS is using a relative short slowdown period, whilst vC2/vC3 are using much longer slowdown periods (probably related to different SledKickHeight aka SledKickLevel settings and/or to different Sled Move Voltage settings).
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#focus-gain-balance","title":"Focus / Gain / Balance","text":"The hardware includes commands for adjusting & measuring focus/gain/balance. Emulators can just omit that stuff, and can always signalize good operation (except that one should emulate failures for Disc Missing; and eventually also for cases like Laser=Off, or Spindle=Stopped). Focus does obviously refer to moving the lens up/down. Gain does probably refer to reflection level/laser intensity. Balance might refer to tracking adjustments or so.
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cdrom-internal-commands-cxxx-summary-of-used-cxxx-commands","title":"CDROM Internal Commands CX(xx) - Summary of Used CX(xx) Commands","text":"The PSX CDROM BIOS versions vC1, vC2, and vC3 are using following CX() commands:
<B> <--vC1--> <--vC2--> <--vC3--></B>\n<B> CXD2510Q CXD2545Q CXD2938Q</B>\n CX(00) CX(00) CX(00) AllFocusSwitchesOff\n CX(02) CX(02) CX(02) FocusSearchVoltageFalling\n CX(03) CX(03) CX(03) FocusSearchVoltageRising ;ForTestOnly\n CX(08) CX(08) CX(08) FocusServoOn\n CX(0C) CX(0C) CX(0C) FocusServoOnAndDefectOn ;diff.usage vC# ?\n -----\n CX(11) - - SledKickHeight2\n CX(12) - - SledKickHeightInvalid\n CX(19) - - TrackingGainAndSledKickHeight2\n CX(1D) - - TrackingGainBrakeAndSledKickHeight2\n CX(1E) - - TrackingGainBrakeAndSledKickHeightInvalid\n -----\n - CX(11) CX(11) AntiShockOff ;\\\n - CX(13) CX(13) AntiShockOffGainUp ;\n - CX(17) CX(17) AntiShockOffGainUpBrake ;/\n -----\n CX(20) CX(20) CX(20) SledAndTrackingOff\n CX(21) CX(21) CX(21) SledServoOn ;ForTestOnly\n CX(22) CX(22) CX(22) SledFastForward\n CX(23) CX(23) CX(23) SledFastReverse\n CX(24) - - TrackingServoOn\n CX(25) CX(25) CX(25) SledAndTrackingServoOn\n - CX(26) CX(26) SledFastForwardAndTrackingServoOn\n CX(28) CX(28) CX(28) TrackingForwardJump ;ForTestOnly\n CX(2C) CX(2C) CX(2C) TrackingReverseJump ;ForTestOnly\n -----\n CX(30+n) - - BalanceAdjust(0..7)\n CX(38+n) - - GainAdjust(0..7)\n -----\n - CX(30) CX(30) SetSledKickLevel1 ;\\\n - CX(31) CX(31) SetSledKickLevel2 ;\n - CX(32) CX(32) SetSledKickLevel3 ;/\n -----\n - CX(3400E6) CX(3400E6) SetK00toE6hSledInputGain ;def=E0h\n - CX(340730) CX(340730) SetK07to30hSledAutoGain ;blah ;def=30h\n - CX(34114A) CX(34114A) SetK11to4AhFocusOutputGain ;def=32h\n - CX(341330) CX(341330) SetK13to30hFocusAutoGain ;blah ;def=30h\n - CX(341D6F) CX(341D6F) SetK1Dto6FhTrackingLowBoostFilterAL ;def=44h\n - CX(341F64) CX(341F64) SetK1Fto64hTrackingLowBoostFilterBL ;def=5Eh\n - CX(342220) CX(342220) SetK22to20hTrackingOutputGain ;def=18h\n - CX(342330) CX(342330) SetK23to30hTrackingAutoGain ;blah ;def=30h\n - CX(342D28) CX(342D28) SetK2Dto28hFocusGainDownOutputGain ;def=1Bh\n - CX(343E70) CX(343E70) SetK3Eto70hTrackingGainUpOutputGain ;def=57h\n - - CX(34910000) NewScexStopReading ;\\\n - - CX(3491x180) NewScexRandomKey(x) ;\n - - CX(34920000) NewScexFlushResyncOrSo ; SCEX SPECIAL\n - - CX(34944A00) NewScexInitValue1 ; see also:\n - - CX(3498C000) NewScexInitValue2 ; CX(3C2080)\n - - CX(349C1000) NewScexThis ;\\inverse ;\n - - CX(349D1000) NewScexThat ;/of COUT ;/\n - CX(34F000) CX(34F000) SetTRVSCto000h\n - CX(34Fxxx) CX(34Fxxx) SetFBIAStoNNNh\n -----\n - CX(3740AA) CX(3740AA) SetSMto00h ;\\set SM to 0,6,7,9\n - CX(3746AA) CX(3746AA) SetSMto06h ; (sled move voltage)\n - CX(3747AA) CX(3747AA) SetSMto07h ; (and init several\n - CX(3749AA) CX(3749AA) SetSMto09h ;/fixed settings)\n -----\n - CX(380010) CX(380010) ModeMeasureTrackingZeroLevel ;\\Measure modes\n - CX(380800) CX(380800) ModeMeasureRfZeroLevel ; (accepted\n - CX(382000) CX(382000) ModeMeasureFocusZeroLevel ; every 2.9ms)\n - CX(388000) CX(388000) ModeMeasureVcLevel ;/\n - CX(38140A) CX(38140A) ModeCompensate\n - CX(38140E) CX(38140E) ModeCompensateAndTraverseCenter\n - CX(38148A) CX(38148A) ModeCompensateAndDefectOff\n - CX(38148E) CX(38148E) ModeCompensateAndDefectOffTraverseCenter\n - CX(3814AA) CX(3814AA) ModeCompensateAndStuffAndMeasureTraverse ;!\n - CX(38150A) CX(38150A) ModeCompensateAndTrackingAutoGain\n - CX(38150E) CX(38150E) ModeCompensateAndTrackingAutoGain\n - CX(38160A) CX(38160A) ModeCompensateAndFocusAutoGain\n -----\n - CX(391E) - SenseRFDCinputSignalWithoutDAC ;\\rather\n - CX(3983) - SenseFEinputSignalWithDAC ;/unused\n - CX(399C) - SenseTRVSCregisterWithDAC ;\\only if\n - CX(399D) - SenseFBIASregisterWithDAC ;/TEST1=LOW\n -----\n - CX(3A0000) CX(3A0000) FocusBiasAdditionOff ;\\\n - CX(3A4000) CX(3A4000) FocusBiasAdditionOn ;/\n - CX(3B2250)!CX(3B7250)!InitOperationForMirrDfctFok <-- vC2/vC3 DIFF\n - CX(3C) !!!CX(3C0080) TzcCoutSelectHPTZC;\\ <--formerly CX(3C)\n - - !!!CX(3C2080) TzcCoutSelectSCEX ; <--special NewScex mode\n - CX(3D) !!!CX(3C4080) TzcCoutSelectDTZC ;/ <--formerly CX(3D)\n - CX(3E0000) CX(3E0000) InitFilterBits ;\\\n - CX(3E0008) CX(3E0008) InitFilterBitsInvalid ;/\n - CX(3F0008) CX(3F0008) InitOtherStuff ;-\n -----\n CX(4000) CX(4000) CX(4000) AutoSeqCancel\n CX(4700) CX(4700) CX(4700) AutoSeqFocusOn\n CX(4800) CX(4800) CX(4800) Forward1track\n CX(4900) CX(4900) CX(4900) Reverse1track\n CX(4C00) CX(4C00) CX(4C00) Forward2Ntrack\n CX(4D00) CX(4D00) CX(4D00) Reverse2Ntrack\n -----\n CX(54) CX(54) CX(54) BlindBrakeOverflowTimer=4\n CX(5A) CX(5A) CX(5A) BlindBrakeOverflowTimer=A\n CX(6100) CX(6100) CX(6100) SledKickBrakeKickTimer\n CX(70xxx0) CX(70xxx0) CX(70xxx0) TrackJumpCountSetting\n CX(8180) CX(8180)!!!CX(810408) MODE = Audio (CD-DA)\n - CX(8120)!!!CX(812400) MODE = Audio (CD-DA) (manual SPI bus access)\n - - CX(810000/UNUSED)\n - - CX(812000/UNUSED)\n CX(8980) CX(8980) CX(890408) MODE = CDROM (Data)\n - - CX(898000) MODE = CDROM (Data) (used on RESET)\n CX(9B00) CX(9B00)!!!CX(9B1000) NormalSpeed\n CX(9F00) CX(9F00)!!!CX(9F1000) DoubleSpeed\n CX(A040) CX(A040) CX(A040) Attentuation Off\n CX(A140) CX(A140) CX(A140) Attentuation -12 dB\n CX(B01000) CX(B01000) CX(B01000) TraverseMonitorCounterSetting\n CX(C600) CX(C600) CX(C600) SpindleServoCoefficientSetting\n CX(D7) CX(D7) CX(D70000) ClvControl (fixed)\n CX(E0) CX(E0) CX(E00000) SpindleMotorStop\n - - CX(E02000) <-- aka bugged CX(E0) with CRAP=2000h\n CX(E6) CX(E6) CX(E60000) AutomaticNormal\n CX(E8) CX(E8) CX(E80000) SpindleMotorForward\n - - CX(E8crap) <-- aka bugged CX(E8) with CRAP=xxxxh\n CX(EA) CX(EA) CX(EA0000) SpindleMotorReverse\n - - CX(EAcrap) <-- aka bugged CX(EA) with CRAP=xxxxh\n CX(EE) CX(EE) CX(EE0000) RoughServo\n -----\n CX(F) CX(F) CX(F) Unused (N/A)\n -----\n CX(Xx) CX(Xx) CX(Xx) ;\\\n CX(Xxxx) CX(Xxxx) CX(Xxxx) ; TestCommand (cmd_19h_50h)\n CX(Xxxxxx) CX(Xxxxxx) CX(Xxxxxx) ;\n - - CX(Xxxxxxxx) ;/\n - CX(Xxxxxx) CX(Xxxxxx) SerialSense, CX(Xxxx) with extra 8bit junk\n sense(30) SEIN.BAL ;vC2: SSTP\n sense(38) SEIN.GAIN ;vC2: AGOK(AGT/AGF) or XAVEBSY(AVRG) or SSTP(else?)\n sense(40) XBUSY (low=AutoSeqBusy)\n sense(50) FOK (high=FokusOkay)\n sense(A0) GFS (high=GoodFrameSync, ie. CorrectPlaybackSpeed)\n sense(C5) COUT (toggles each 100h 'tracks') (100h=selected via CX(B01000))\n sense(EA) /OV64 (low=EFM too long?)\nThe CXD2545Q contains Preset Coefficients in internal ROM, which are copied to internal Coefficient RAM shortly after Reset. CX(34xxxx) allows to change those RAM settings, and CX(39xxxx) allows to readout some of those values serially.
"},{"location":"cdrominternalinfoonpsxcdromcontroller/#cxd2545q-coefficient-preset-values","title":"CXD2545Q - Coefficient Preset Values","text":" Addr Val Expl.\n K00 E0 Sled input gain\n K01 81 Sled low boost filter A-H\n K02 23 Sled low boost filter A-L\n K03 7F Sled low boost filter B-H\n K04 6A Sled low boost filter B-L\n K05 10 Sled output gain\n K06 14 Focus input gain\n K07 30 Sled auto gain\n K08 7F Focus high cut filter A\n K09 46 Focus high cut filter B\n K0A 81 Focus low boost filter A-H\n K0B 1C Focus low boost filter A-L\n K0C 7F Focus low boost filter B-H\n K0D 58 Focus low boost filter B-L\n K0E 82 Focus phase compensate filter A\n K0F 7F Focus defect hold gain\n K10 4E Focus phase compensate filter B\n K11 32 Focus output gain\n K12 20 Anti shock input gain\n K13 30 Focus auto gain\n K14 80 HPTZC / Auto Gain High pass filter A\n K15 77 HPTZC / Auto Gain High pass filter B\n K16 80 Anti shock high pass filter A\n K17 77 HPTZC / Auto Gain low pass filter B\n K18 00 Fix (should not change this preset value)\n K19 F1 Tracking input gain\n K1A 7F Tracking high cut filter A\n K1B 3B Tracking high cut filter B\n K1C 81 Tracking low boost filter A-H\n K1D 44 Tracking low boost filter A-L\n K1E 7F Tracking low boost filter B-H\n K1F 5E Tracking low boost filter B-L\n K20 82 Tracking phase compensate filter A\n K21 44 Tracking phase compensate filter B\n K22 18 Tracking output gain\n K23 30 Tracking auto gain\n K24 7F Focus gain down high cut filter A\n K25 46 Focus gain down high cut filter B\n K26 81 Focus gain down low boost filter A-H\n K27 3A Focus gain down low boost filter A-L\n K28 7F Focus gain down low boost filter B-H\n K29 66 Focus gain down low boost filter B-L\n K2A 82 Focus gain down phase compensate filter A\n K2B 44 Focus gain down defect hold gain\n K2C 4E Focus gain down phase compensate filter B\n K2D 1B Focus gain down output gain\n K2E 00 Not used\n K2F 00 Not used\n K30 80 Fix (should not change this preset value)\n K31 66 Anti shock low pass filter B\n K32 00 Not used\n K33 7F Anti shock high pass filter B-H\n K34 6E Anti shock high pass filter B-L\n K35 20 Anti shock filter comparate gain\n K36 7F Tracking gain up2 high cut filter A\n K37 3B Tracking gain up2 high cut filter B\n K38 80 Tracking gain up2 low boost filter A-H\n K39 44 Tracking gain up2 low boost filter A-L\n K3A 7F Tracking gain up2 low boost filter B-H\n K3B 77 Tracking gain up2 low boost filter B-L\n K3C 86 Tracking gain up phase compensate filter A\n K3D 0D Tracking gain up phase compensate filter B\n K3E 57 Tracking gain up output gain\n K3F 00 Not used\n K40 04 Tracking hold filter input gain\n K41 7F Tracking hold filter A-H\n K42 7F Tracking hold filter A-L\n K43 79 Tracking hold filter B-H\n K44 17 Tracking hold filter B-L\n K45 6D Tracking hold filter output gain\n K46 00 Not used\n K47 00 Not used\n K48 02 Focus hold filter input gain\n K49 7F Focus hold filter A-H\n K4A 7F Focus hold filter A-L\n K4B 79 Focus hold filter B-H\n K4C 17 Focus hold filter B-L\n K4D 54 Focus hold filter output gain\n K4E 00 Not used\n K4F 00 Not used\nVCDs are Video CDs with MPEG compression, yielding a playtime of 72 minutes per disc (whole movies usually being stored on two CDs). VCDs are popular in asia (as opposed to VHS tapes used in western world).
"},{"location":"cdromvideocdsvcd/#vcds-on-playstation","title":"VCDs on Playstation","text":"For the Playstation, the asian SCPH-5903 model includes a special daughterboard with MPEG decoding hardware for playing VCDs. CDROM - Video CD Commands Pinouts - VCD Pinouts Without that hardware it has been widely believed to be impossible to play VCDs on Playstations, although, as of 2017, it turned out that the Playstation's CPU and MDEC decoder are fast enough for that purpose (when skipping B-frames, rendering the movie in monochrome without colors, and reducing audio output to 11kHz/mono).
"},{"location":"cdromvideocdsvcd/#iso-filesystem-track-1","title":"ISO Filesystem (Track 1)","text":"VCD ISO Basic Files (INFO, ENTRIES, AVSEQnn, ISO Filesystem) VCD ISO Playback Control PBC Files (PSD, LOT, ITEMnnnn) VCD ISO Search Files (SCANDATA, SEARCH, TRACKS, SPICONTX) VCD ISO Misc files (CAPTnn, AUDIOnn, KARINFO, PICTURES, CDI)
"},{"location":"cdromvideocdsvcd/#mpeg-streams-track-2-and-up","title":"MPEG Streams (Track 2 and up)","text":"VCD MPEG-1 Multiplex Stream VCD MPEG-1 Video Stream XXX MPEG-1 Macroblocks VCD MP2 Audio Stream
"},{"location":"cdromvideocdsvcd/#vcd-versions-variants","title":"VCD Versions & Variants","text":"XXX
"},{"location":"cdromvideocdsvcd/#vcd-iso-basic-files-info-entries-avseqnn-iso-filesystem","title":"VCD ISO Basic Files (INFO, ENTRIES, AVSEQnn, ISO Filesystem)","text":""},{"location":"cdromvideocdsvcd/#primary-volume-descriptor-000216","title":"Primary Volume Descriptor (00:02:16)","text":"VCDs are having a standard ISO Primary Volume Descriptor, with some VCD specific entries:
008h 32 System Identifier (always \"CD-RTOS CD-BRIDGE\" for VCDs)\n 028h 32 Volume Identifier (often nonsense, eg. \"\" or \"__\" or \"VolumeLabel\")\n 23Eh 128 Application Identifier (\"CDI/CDI_APPL.VCD;1\" or \"CDI/CDI_VCD.APP;1\")\n 400h 8 CD-XA Identifying Signature (\"CD-XA001\" for PSX and VCD)\n VCDs are using MODE2 (with 800h-byte and 914h-byte sectors)\n MPEG videos are on extra data tracks (outside of the ISO area on Track 1)\n Files in VCD or SVCD folders use fixed sectors numbers (00:04:00 and up)\n All 16bit/32bit values in files in VCD,SVCD,EXT,etc are BIG-ENDIAN\n 000h 8 ID \"VIDEO_CD\" for VCD (or \"SUPERVCD\"/\"HQ-VCD \" for SVCD)\n 008h 1 Version ;Version Major (01h) (or 02h for VCD 2.0)\n 009h 1 System Profile Tag ;Version Minor (00h) (or 01h for VCD 1.1 or HQ)\n 00Ah 16 Album ID/Desc (name in ASCII, padded with SPC) (usually empty)\n 01Ah 2 Total Number of CDs in Album (1..N) ;\\usually always 1,1 (even\n 01Ch 2 Number of this CD in Album (1..N) ;/for movies with 2 discs)\n 01Eh 13 PAL Flags, 98x1bit, for each Track? (0=NTSC, 1=PAL)\n 02Bh 1 InfoStatusFlags (see below)\n Below is usually zero-filled when not using PBC\n 02Ch 4 Size of PSD.VCD file (or PSD.SVD?) (0=None)\n 030h 3 First segment addr MM:SS:00 in BCD (00:02:00 ???)\n 033h 1 Offset Multiplier for \"PsdOffset\" values in PSD.VCD (must be 8)\n 034h 2 Number of ListIDs in LOT.VCD file (1..7FFFh, plus 1 in some discs)\n 036h 2 Number of ITEMnnnn.DAT files (plus nonsense in some discs?)\n Below is usually zero-filled (maybe exists on SVCD only?)\n 038h 1980 SegmentContent[1..1980] (b0-1=Audio, b2-4=Video, b5=Cont, b6-7=OGT)\n 7F4h 5*2 volume start time[0]: 5x16bit ;aka playing_time[5] in seconds (?)\n 7FEh 2 Reserved (0)\n bit0 Reserved, must be zero\n bit1-2 Restriction (0=No, 1..3=Restricted category 1..3) (eg. \"not for kids\")\n bit3 Special Information is encoded in the pictures, uh?\n bit4 MPEG User Data is used for Closed Caption (user_data_cc) (0=No, 1=Yes)\n bit5 Next Disc with PBC (0=Start at ListID#1, 1=Start at ListID#2)\n bit6 Next Disc without PBC (0=Start at Track #2, 1=Start at Track #3)\n bit7 Extended PBC available (0=No, 1=Yes... aka EXT\\PSD_X exists?)\n 000h 8 ID \"ENTRYVCD\" for VCD and SVCD (or \"ENTRYSVD\" for VCD30)\n 008h 1 Version ;\\same as in INFO.VCD/SVD\n 009h 1 System Profile Tag ;/\n 00Ah 2 Number of Entries/Chapters (1..500)\n 00Ch 4*500 Entry[N] (Track 02h..99h, and MM:SS:FF) (all 4 bytes in BCD)\n 7DCh 36 Reserved (0)\n 0x02 --- VCD2.0\n 0x01 --- SVCD, should be same as version in INFO.SVD\n 0x01 if VCD1.1\n 0x00 else\nThese filesystem entries contain pointers to the video tracks (that is, outside of the ISO area on Track 1). Commercially made SVCDs can reportedly contain 7 folders: Autorun, Data, Ext, Mpegav, Segment, Svcd and Vmp (ie. there's no MPEG2 folder on all SVCDs? though that MPEGAV folder is said to contain a .MPG file instead of .DAT file).
"},{"location":"cdromvideocdsvcd/#vcd-iso-playback-control-pbc-files-psd-lot-itemnnnn","title":"VCD ISO Playback Control PBC Files (PSD, LOT, ITEMnnnn)","text":"Playback Control (PBC) is an optional feature that allows to define menues, pictures or text pages (whereas all those is internally just consisting of MPEG compressed bitmaps; rather than of text characters). Presence of the PBC feature is indicated by PSD.VCD filesize entry (in INFO.VCD) being nonzero. PBC seems to be supported by most VCDs (except older discs from around 1997), however, many VCDs are merely including a single PlayList entry for the movie track, without any further menues/extras.
"},{"location":"cdromvideocdsvcd/#vcdpsdvcd-or-svcdpsdsvd-000434-and-up-max-256-sectors","title":"VCD\\PSD.VCD or SVCD\\PSD.SVD (00:04:34 and up) (max 256 sectors)","text":"The Descriptors in this file can be considered as being \"program code\". The program is usually stuck on \"executing\" the current descriptor (eg. playing a movie, or showing a selection menu) without automatically increasing the program counter. Actual program flow occurs only if the user presses a button (or upon selection timeouts), causing the program to \"goto\" to a new PsdOffset. And, something does probably happen upon end-of-track/item... maybe that does automatically trigger the Next button handler?
<B> PsdPlayListDescriptor (14+2*N bytes):</B>\n 00h 1 Type (10h=PlayList)\n 01h 1 Number of Items (noi) ;for Start-of-Movie and Numeric-Input?\n 02h 2 ListID for this Descriptor (1..7FFFh)\n 04h 2 PsdOffset for Prev button (FFFFh=Disable)\n 06h 2 PsdOffset for Next button (FFFFh=Disable)\n 08h 2 PsdOffset for Return/back button (FFFFh=Disable)\n 0Ah 2 Play time in 1/15s (=max 72.8 minutes) (or 0000h=full item)\n 0Ch 1 Delay time in \"1s/10s\" units after ;<-- uh, after? after what?\n 0Dh 1 Auto pause time in \"1s/10s\" units (used for each item in list if\n the auto pause flag in a sector is true) [WHAT is that? Trigger bit?]\n 0Eh 2*N ItemID[N] ;item number (0..599 or 1000..2979)\n Entry 0 is for \"start of movie\" (usually 0002h=Track 2)\n Entry 1..N-1 is for numeric input ?\n<B> PsdSelectionListDescriptor (20+2*N bytes, or 36+6*N bytes):</B>\n 00h 1 Type (18h=SELECTION_LIST, or 1Ah=EXT_SELECTION_LIST)\n 01h 1 Flags (bit0=SelectionArea, bit1=CommandList, bit2-7=Reserved)\n 02h 1 nos <-- aka Number of Numeric-input selections ?\n 03h 1 bsn <-- ?\n 04h 2 ListID for this Descriptor (1..7FFFh)\n 06h 2 PsdOffset for Prev button\n 08h 2 PsdOffset for Next button\n 0Ah 2 PsdOffset for Return/back button\n 0Ch 2 PsdOffset for Default button (uh, what is that?)\n 0Eh 2 PsdOffset for Timeout\n 10h 1 totime <-- aka Timeout Time maybe? in WHAT units?\n 11h 1 loop <-- aka ?\n 12h 2 itemid <-- aka Item to be displayed during the selection?\n 14h 2*N PsdOffset[N] for Numeric-input ?\n Below only for SVCDs (with Type=18h), or for Extended VCDs (with Type=1Ah):\n (14h+2*N) 4 Area for Prev (x1,y1,x2,y2) ;\\these extra entries exist for\n (18h+2*N) 4 Area for Next (x1,y1,x2,y2) ; SVCDs with Type=18h, and\n (1Ch+2*N) 4 Area for Return (x1,y1,x2,y2) ; Extended VCDs with Type=1Ah\n (20h+2*N) 4 Area for Default (x1,y1,x2,y2) ; (but do NOT exist for\n (24h+2*N) 4*N Area[N] (x1,y1,x2,y2) ;/older VCDs with Type=18h)\n<B> PsdEndListDescriptor (8 bytes)</B>\n 00h 1 Type (1Fh=EndList)\n 01h 1 Next_disc ;00h to stop PBC or NNh to switch to disc no NN (BCD!?)\n 02h 2 Item (0 or 1000..2979, should be still image, eg. Change Disc pic)\n 04h 4 Reserved (0)\n N/A - This descriptor doesn't have a ListID (unlike as other descriptors)\n<B> PsdCommandListDescriptor (5+2*N bytes)</B>\n 00h 1 Type (20h=CommandList)\n 01h 2 Command_count\n 03h 2 ListID for this Descriptor (1..7FFFh)\n 05h 2*N command[EMPTY_ARRAY_SIZE] ;uh, WHAT is a command?\n<B> PsdAlignmentPadding (after each list entry)</B>\n 00h 0..7 Padding to next 8-byte PsdOffset boundary (00h-filled)\n 1..60 --> wait \"N\" seconds\n 61..254 --> wait \"(N-60)*10+60\" seconds\n 255 --> wait infinite\n 0..1 - Play nothing\n 2..99 - Play Track 2..99 (TOC tracks, for AVSEQnn.DAT and AUDIOnn.DAT?)\n 100..599 - Play Entry 1..500 from table in ENTRIES file up to end of track\n 600..999 - Reserved\n 1000..2979 - Play SPI Segment Play Item 1..1980 (ITEMnnnn.DAT file)\n 2980..65535 - Reserved\n 0..N Offset within PSD.VCD file, in 8-byte units\n FFFDh PSD_OFS_MULTI_DEF_NO_NUM ;\\uh, what is that?\n FFFEh PSD_OFS_MULTI_DEF ;/\n FFFFh PSD_OFS_DISABLED ;-no function assigned to the button\nThe ListID Offset Table (LOT) allows to translate ListIDs to PsdOffsets. The file is always 64Kbyte in size (unused entries should be set to FFFFh). The PSD.VCD file does also assign ListIDs to each descriptor (ie. instead of using the LOT.VCD file, one could also scan all descriptors in PSD.VCD when searching a specific ListID).
0000h 2 Reserved (0)\n 0002h 2*7FFFh PsdOffset[1..7FFFh] ;for ListID 1..7FFFh\nThese files contain Pictures/Menu screens referenced from PSD.VCD. The files seem to be stored in FORM2 sectors (not FORM1). Unknown if the files are located on Track 1. The content of the files seems to resemble short MPEG video clips (with only one picture frame, or eventually with a few frames for short animations, including audio in some cases). Still images are said to be allowed to use twice the resolution of MPEG videos.
"},{"location":"cdromvideocdsvcd/#extpsd_xvcd-or-extpsd_xsvd-extended-version-of-psdvcd","title":"EXT\\PSD_X.VCD or EXT\\PSD_X.SVD (extended version of PSD.VCD)","text":""},{"location":"cdromvideocdsvcd/#extlot_xvcd-or-extlot_xsvd-extended-version-of-lotvcd","title":"EXT\\LOT_X.VCD or EXT\\LOT_X.SVD (extended version of LOT.VCD)","text":"The \"extended\" files are often identical to the normal PSD/LOT files. The difference is that, if disc uses SelectionLists, then PSD should use the normal descriptor (18h), and PSD_X should use the extended descriptor (1Ah), the latter one seems to be intended to allow to highlight the current menu selection (particulary useful when using +/- buttons instead of Numeric Keypad input). Note: Nethertheless, Muppets from Space uses descriptor 18h in PSD_X. Unknown if SVCDs do really have \"extended\" files, too (theoretically the VCD extension should be a default feature for SVCDs).
"},{"location":"cdromvideocdsvcd/#playback-control-issues","title":"Playback Control Issues","text":"Although PBC was intended as \"nice extra feature\", many VCDs are containing faulty PSD files. In general, VCD players should either leave PBC unsupported (or at the very least, provide an option for disabling it). Red Dragon from 2003 uses extended selection lists, but crops PSD_X.VCD to the same filesize as PSD.VCD. Muppets from Space from 1999 assigns weird functions to Prev/Next buttons (Next wraps from Last Track to First Track, but Prev doesn't wrap from First to Last; default Non-PBC Prev/Next functions are more user friendly). Sony's SCPH-5903 console refuses to display the HH:MM:SS playback time when using PBC (instead it does only display a \"PBC\" logo).
"},{"location":"cdromvideocdsvcd/#vcd-iso-search-files-scandata-search-tracks-spicontx","title":"VCD ISO Search Files (SCANDATA, SEARCH, TRACKS, SPICONTX)","text":"Below files can help searching I-frames, and provide some info about the content of Tracks and Segments. Essentially, searching I-frames is possible without these files - however, if present, then the files may be useful in two cases: For discs with variable bitrates (which isn't allowed on VCDs though), and, for CDROM firmwares that don't support \"inaccurate\" seeking (like telling it to start reading anywhere NEAR some MM:SS:FF value, so one could skip sectors till reaching an I-frame) (ie. if the firmware insists on a \"accurate\" seek position, then it's best to give it a known I-frame address).
"},{"location":"cdromvideocdsvcd/#caution-overlapping-sectors","title":"Caution: Overlapping Sectors (!?!)","text":"Reportedly the new SVCD files TRACKS.SVD and SEARCH.DAT are on these sectors:
TRACKS_SVD_SECTOR = (PSD_VCD_SECTOR+1) ;aka 2nd sector in PSD.SVD?\n SEARCH_DAT_SECTOR = (TRACKS_SVD_SECTOR+1) ;aka 3rd..Nth sector in PSD.SVD?\nThis file fulfills much the same purpose of the SEARCH.DAT file except that this file is mandatory only if the System Profile Tag of the INFO.SVD file is 0x01 (HQ-VCD) and also that it contains sector addresses also for each video Segment Play Items in addition to the regular MPEG tracks.
SCANDATA.DAT Format for VCD 2.0 (12+3*N bytes):\n 000h 8 ID \"SCAN_VCD\"\n 008h 1 Version (02h for VCD 2.0)\n 009h 1 Reserved (0)\n 00Ah 2 Number of scan points (in 0.5s units) (max FFFFh = ca. 9.1 hours)\n 00Ch 3*N Scan Point[0..N-1] ;MM:SS:FF of closest I-frame\n SCANDATA.DAT Format for SVCD (16+3*N+2*X+3*Y+3*Z bytes):\n 000h 8 ID \"SCAN_VCD\"\n 008h 1 Version (01h for SVCD)\n 009h 1 Reserved (0)\n 00Ah 2 scandata_count ;number of 3-byte entries in the table\n 00Ch 2 track_count ;number of MPEG tracks on disc\n 00Eh 2 spi_count ;number of consecutively recorded play item segments\n ; (as opposed to the number of segment play items).\n 010h 3*N msf_t cum_playtimes[N] ;cumulative playing time up to track N.\n ; (track time just wraps at 99:59:74)\n xxxh 2*X spi_indexes[X] ;Indexes into the following scandata table\n xxxh 2 mpegtrack_start_index ;Index into the following scandata table\n ; (where the MPEG track scan points start)\n xxxh 3*Y The scandata table... [Y] ;8bit Track Number and 16bit Index\n uint8_t track_num; /* Track number as in TOC\n uint16_t table_offset; /* Index into scandata table\n xxxh 3*Z msf_t scandata_table[Z] ;MM:SS:FF\nThis file defines where the scan points are. It covers all mpeg tracks together. A scan point at time T is the nearest I-picture in the MPEG stream to the given time T. Scan points are given at every half-second for the entire duration of the disc.
000h 8 ID \"SEARCHSV\"\n 008h 1 Version (01h)\n 009h 1 Reserved (0)\n 00Ah 2 Number of scan points\n 00Ch 1 Time_interval (in units of 0.5 seconds) (must be 01h)\n 00Dh 3*N Scan Point[0..N-1] ;MM:SS:FF of closest I-frame\nThe TRACKS.SVD file contains a series of structures, one for each track, which indicates the track's playing time (in sectors, not actually real time) and contents. SVCD\\TRACKS.SVD is a mandatory file which describes the numbers and types of MPEG tracks on the disc.
SVCD\\TRACKS.SVD Format for SVCD (11+4*N bytes):\n 000h 8 ID \"TRACKSVD\"\n 008h 1 Version (01h)\n 009h 1 Reserved (0)\n 00Ah 1 Number of MPEG tracks (N)\n 00Bh 3*N Track playing_time[N] (MM:SS:FF, in BCD)(in sectors, not real time)\n 0xxh 1*N TrackContent[N] ;bit0-1=Audio,bit2-4=Video,bit5=Reserved,bit6-7=OGT\n SVCD\\TRACKS.SVD Format for VCD30 (11+5*N bytes) (some sort of SVCD-prototype):\n 000h 8 ID \"TRACKSVD\"\n 008h 1 Version (01h)\n 009h 1 Reserved (0)\n 00Ah 1 Number of MPEG tracks (N)\n 00Bh 5*N Cum_Playing_time and Content (MM:SS:FF in BCD, and OGT, Audio)\nUnknown if/when/where/why this file exists, possibly only on VCD30? Note: The same info can be stored in INFO.SVD at offsets [038h..7F3h].
0000h 8 ID \"SPICONSV\"\n 0008h 1 Version (01h)\n 0009h 1 Reserved (0)\n 000Ah 2*1980 Segment Content[1..1980] (1st byte=OGT, 2nd byte=Audio)\n 0F82h 126 Reserved (0)\nFor SVCD\\INFO.SVD and SVCD\\TRACKS.SVD (on SVCD) these are encoded in 1 byte:
bit0-1 Audio characteristics:\n 0 = No MPEG audio stream\n 1 = One MPEG1 or MPEG2 audio stream without extension\n 2 = Two MPEG1 or MPEG2 audio streams without extension\n 3 = One MPEG2 multi-channel audio stream with extension\n bit2-4 Video characteristics:\n In TRACKS.SVD this must be 0,3,7 (no still pictures)\n 0 = No MPEG video data\n 1 = NTSC still picture\n 2 = NTSC Reserved (NTSC still pic hires?)\n 3 = NTSC motion picture\n 4 = Reserved\n 5 = PAL still picture\n 6 = PAL Reserved (PAL still pic hires?)\n 7 = PAL motion picture\n bit5 Indicates segment is continuation of an item\n In TRACKS.SVD this must be 0 (reserved)\n 0 = First or only segment of item\n 1 = Second or later segment of item\n bit6-7 Overlay Graphics/Text (OGT):\n 0 = No OGT substream\n 1 = Sub-stream 0 available\n 2 = Sub-stream 0 & 1 available\n 3 = All OGT sub-substreams available\n 1st byte = Audio characteristics ;\\probably same values as\n 2nd byte = Overlay Graphics/Text (OGT) ;/in above bitfields?\nVCDs with subtitles are usually/always having the subtitles encoded directly in the picture frames (ie. in the MPEG macroblocks, rather than using the Closed Caption feature). These CAPTnn.DAT files are intended for Closed Captions (eg. subtitles in different languages and/or for deaf people). Alternately, the \"user_data_cc\" flag in INFO.VCD?/INFO.SVD can indicate to store Closed Captions in MPEG User Data (with START_CODE=000001B2h=User Data) instead of in EXT\\CAPTnn.DAT. Either way, the format of those Closed Captions is unknown. Moreover, Content can be flagged to have Overlay Graphics/Text (OGT), whatever that is: it might be related to Closed Captions. Note: Reportedly CAPTnn.DAT can exist on VCDs and SVCDs (although the same person reported that VCDs do not support subtitles, so that info sounds wrong).
"},{"location":"cdromvideocdsvcd/#cddaaudionndat-pointers-to-uncompressed-cd-audio-tracks","title":"CDDA\\AUDIOnn.DAT (pointers to uncompressed CD Audio Tracks)","text":"These filesystem entries contain pointers to uncompressed audio tracks tracks (that is, outside of the ISO area on Track 1). Most VCDs don't have audio tracks (though some VCDs do contain empty CDDA folders). Maybe the feature is occassionally used the other way around: Music discs containing VCD clips as bonus feature?
"},{"location":"cdromvideocdsvcd/#karaokekarinfoxxx-whatever","title":"KARAOKE\\KARINFO.xxx (whatever)","text":"The KARAOKE folder exists on many VCDs (about 50%), but it's usually/always empty on all discs. Reportedly the folder can contain \"KARINFO.xxx\" files, but the purpose/format of that files is unknown. Reportedly there are Midi VCDs (MVCDs) for karaoke, maybe those discs have \"KARINFO.xxx\" files(?)
"},{"location":"cdromvideocdsvcd/#pictures-whatever","title":"PICTURES\\*.* (whatever)","text":"Unknown purpose. The PICTURES folder has been spotted on one VCD (Wallace and Gromit), but the folder was just empty.
"},{"location":"cdromvideocdsvcd/#cdi-some-kind-of-guidriver-for-philips-cdi-players","title":"CDI\\*.* (some kind of GUI/driver for Philips CDI Players)","text":"The CDI folder is some relict for Philips CDI Players, it isn't used by normal VCD players, however, the CDI folder & files are included on most or all VCDs. The path/name for the CDI executable is stored at offset 23Eh in the ISO Primary Volume Descriptor (usually \"CDI/CDI_APPL.VCD;1\" or \"CDI/CDI_VCD.APP;1\") (or accidentally \"CDI_CDI_VCD.APP;1\" on homebrew Nero discs). The files in the CDI folder are usually just some standard files (without any customizations), however, there are some different revisions of these files:
<B> Revision A (spotted on two discs from 1997 and 1999):</B>\n CDI_APPL.VCD 80702 bytes, 04-Mar-1996, CRC32=AE8FC5D0h ;executable\n VCD_BACK.DYV 92572 bytes, 18-Jul-1995, CRC32=00693E5Eh ;whatever?\n VCD_BTN.C8 93719 bytes, 18-Jul-1995, CRC32=FF0A636Ah ;whatever?\n<B> Revision B (spotted on a disc from 2003):</B>\n CDI_VCD.APP 20648 bytes, 00-Nul-0000 CRC32=DC885F70h ;executable\n CDI_FONT.FNT 145388 bytes, 00-Nul-0000 CRC32=FB4D63F4h ;font?\n CDI_ALL.RTF ? bytes, CRC32=? ;realtimefile?\n CDI_BUM.RTF ? bytes, CRC32=? ;realtimefile?\n<B> Revision C (spotted on a disc from 2006, and homebrews from 2001 and 2017):</B>\n CDI_VCD.APP 102400 bytes, 00-Nul-0000 CRC32=E91E128Dh ;executable\n CDI_VCD.CFG 193 bytes, 00-Nul-0000 CRC32=D1C6F7ADh ;config/ascii\n CDI_TEXT.FNT 13616 bytes, 00-Nul-0000 CRC32=BDC55E86h ;font?\n CDI_IMAG.RTF 1510028 bytes, 00-Nul-0000 CRC32=(RIFF) ;realtimefile?\nThe Multiplex stream is some higher level stream, intended to help to distinguish between Audio- and Video-streams (which are enclosed in the Multiplex stream). MPEG's are somewhat organized in \"sectors\", with sector size varying for normal .mpg files and VCDs:
VCD discs --> Sector Size = 914h bytes (the discs MODE2/FORM2 sector size)\n .mpg files --> Sector Size = 800h bytes (regardless of physical sector size)\nThe Pack Header is found at the begin of the stream (on VCDs, it's also found at the begin of each sector). The SCR values might help on identifying the current playback position, and, with the bitrate value, this could be also used to compute the distance to another position (though there are other ways to determine the position/bitrate, so the Pack is kinda useless).
32bit PACK_START_CODE (000001BAh) ;-4byte\n 2bit Fixed (00b for MPEG-1) (would be 01b for MPEG-2) ;\\\n 2bit Fixed (10b) ;\n 3bit System Clock Reference, bit32-30 ;\\ ;\n 1bit Marker (1) ; System Clock Reference (SCR) ;\n 15bit System Clock Reference, bit29-15 ; (intended Time, ; 5byte\n 1bit Marker (1) ; in 90kHz clock cycles) ;\n 15bit System Clock Reference, bit14-0 ;/ ;\n 1bit Marker (1) ;/\n 1bit Marker (1) ;\\\n 22bit Multiplex Rate (total bitrate of the stream, in 400bit/s units) ; 3byte\n 1bit Marker (1) ;/\nThe System Header is usally found after the first Pack at the begin of the stream.
32bit SYSTEM_HEADER_START_CODE (000001BBh) ;\\6byte\n 16bit Header Length minus 6 (in bytes) (0006h+N*3) ;/\n 1bit Marker (1) ;\\\n 22bit Rate bound (max multiplex rate of all packs in the stream, ; 3byte\n 1bit Marker (1) in 400bit/s units) ;/\n 6bit Audio Bound (max number of audio streams in this ISO stream) ;\\\n 1bit Fixed Flag (1=Fixed bitrate) ; 1byte\n 1bit CSPS Flag (1=Constrained) ;/\n 1bit System Audio Lock Flag XXX ;\\\n 1bit System Video Lock Flag XXX ; 1byte\n 1bit Marker (1) ;\n 5bit Video Bound (max number of video streams in this ISO stream) ;/\n 8bit Reserved (FFh) ;-1byte\n 8bit Stream ID (C0h..DFh=Audio, E0h..EFh=Video) ;\\\n 2bit Fixed (11b) ; 3byte\n 1bit STD buffer scale (0=Mul128/audio, 1=Mul1024/video) ;\n 13bit STD buffer size (largest required buffer over all packets) ;/\nThese packets are encapsulating the lower-level Video/Audio streams.
32bit START (000001xxh BDh-BFh=Special, C0h-DFh=Audio, E0h-EFh=Video);\\6byte\n 16bit Packet Length minus 6 (in bytes) (1..18, plus data) ;/\n (2bit) Fixed (11b, indicates presence of stuffing) ;\\optional 0..16byte\n (6bit) Fixed (111111b) ;/\n (2bit) Fixed (01b, indicates presence of buffer size) ;\\\n (1bit) STD Buffer Scale (0=Mul128/audio, 1=Mul1024/video) ; optional 2byte\n (13bit) STD Buffer Size (for decoding, in above scale units) ;/\n 2bit Fixed (00b, indicates no further stuffing/buffer info);\\\n 1bit PTS Flag (Presentation Time Stamp) ; 0.5 bytes\n 1bit DTS Flag (Decoding Time Stamp) ;/\n (3bit) Presentation Time Stamp, bit32-30 ;\\\n (1bit) Marker (1) ; optional 4.5 bytes\n (15bit) Presentation Time Stamp, bit29-15 ; (time when to output the\n (1bit) Marker (1) ; the packet to audio/video\n (15bit) Presentation Time Stamp, bit14-0 ; hardware, in 90kHz cycles)\n (1bit) Marker (1) ;/\n (4bit) Fixed (0001b) ;\\\n (3bit) Decoding Time Stamp, bit32-30 ; optional 5 bytes\n (1bit) Marker (1) ; (recommended time when\n (15bit) Decoding Time Stamp, bit29-15 ; to decode the block,\n (1bit) Marker (1) ; in 90kHz cycles)\n (15bit) Decoding Time Stamp, bit14-0 ;\n (1bit) Marker (1) ;/\n (4bit) Fixed (1111b) ;-optional 0.5 bytes\n ... packet data bytes ;-data...(not crossing sector)\n 32bit END_CODE (000001B9h) ;-4byte\nThe Video stream is part of the Multiplex stream, meaning that the Video packets preceeded (and interrupted) by Multiplex headers. Ie. before processing the Video packets, one must first extract the video snippets from the Multiplex stream (see previous chapter).
"},{"location":"cdromvideocdsvcd/#mpeg-1-video-sequence-header-12-76-or-140-bytes-ie-12n64","title":"MPEG-1 Video Sequence Header (12, 76, or 140 bytes, ie. 12+N*64)","text":" 32bit SEQUENCE_HEADER_CODE (000001B3h) ;-4byte\n 12bit Width in pixels (1..4095) ;\\3byte\n 12bit Height in pixels (1..2800, for max AFh slices) ;/\n 4bit Aspect Ratio (01h..0Eh, see below) ;\\1byte\n 4bit Framerate (01h..08h, see below) ;/\n 18bit Bitrate (in 400bit/s units, 3FFFFh=variable rate) ;\\\n 1bit Marker (1) ; 3byte\n 10bit VBV (required decoding memory size, in \"16 kB\" units) ; +6bit\n 1bit Constrained Parameter Flag ;/\n 1bit Load Intra Q Matrix (0=No, use Standard Matrix, 1=Yes, Custom)\n (64byte) Intra Quantizer Matrix (64 x 8bit, unsigned) (in zigzag order)\n 1bit Load Non-Intra Q Matrix (0=No, use Standard Matrix, 1=Yes, Custom)\n (64byte) Non-Intra Quantizer Matrix (64 x 8bit, unsigned) (in zigzag order)\n 0 - ;forbidden\n 1 1.0 ;square pixels\n 2 0.6735 ;0.6735\n 3 0.7031 ;16:9, 625 line, PAL\n 4 0.7615 ;0.7615\n 5 0.8055 ;0.8055\n 6 0.8437 ;16:9, 525 line, NTSC\n 7 0.8935 ;0.8935\n 8 0.9157 ;4:3, 625 line, PAL, CCIR601\n 9 0.9815 ;0.9815\n 10 1.0255 ;1.0255\n 11 1.0695 ;1.0695\n 12 1.0950 ;4:3, 525 line, NTSC, CCIR601\n 13 1.1575 ;1.1575\n 14 1.2015 ;1.2015\n 15 - ;reserved\n 0 - ;forbidden\n 1 23.976 (24000/1001) ;NTSC encapsulated film rate\n 2 24.0 ;Standard international cinema film rate\n 3 25.0 ;PAL video frame rate (625/50)\n 4 29.97 (30000/1001) ;NTSC video frame rate\n 5 30.0 ;NTSC video frame rate drop-frame (525/60)\n 6 50.0 ;PAL double frame rate/progressive\n 7 59.94 (60000/1001) ;NTSC double frame rate\n 8 60.0 ;NTSC double frame rate drop-frame\n 9-15 - ;reserved\n 32bit GROUP_START_CODE (000001B8h)\n 1bit Drop Frame (1=drop this frame; for reducing 30 fps to 29.97 fps)\n 5bit Time Code Hours (0..23)\n 6bit Time Code Minutes (0..59)\n 1bit Marker (1)\n 6bit Time Code Seconds (0..59)\n 6bit Time Code Picture (0..59)\n 1bit Closed GOP\n 1bit Broken Link\n 32bit PICTURE_START_CODE (00000100h) ;\\\n 10bit Temporal Reference (display order, 0..3FFh) ; 61bit\n 3bit Coding Type (0=Invalid, 1=I, 2=P, 3=B, 4=D, 5-7=Reserved);\n 16bit VBV Delay (in 90kHz cycles, FFFFh=variable bitrate) ;/\n (1bit) full fel forward vector (0=half pix, 1=full pix) ;\\optional 4bit\n (3bit) forward f code (0=invalid, 1..7=0..6bits) ;/\n (1bit) full backward vector ;\\optional 4bit\n (3bit) backward f code ;/\n (1bit) Fixed (1, indicates presence of Extra Info) ;\\opt. N*9bit\n (8bit) Extra Information ;/\n 1bit Fixed (0, indicates no further Extra Info) ;-1bit\n 0-7bit Padding to byte boundary (0) ;-0..7bit\n 0 Forbidden\n 1 I - Intra Coded (full image)\n 2 P - Predictive Coded (based on prev I or P frame)\n 3 B - Bidirectionally Predictive Coded (based on prev+next I or P frame)\n 4 D - DC Intra Coded (don't care, lowres thumbnail)\n 5 Reserved\n 6 Reserved\n 7 Reserved\n DISPLAY ORDER:\n I B B B P B B B P B B B P B B B I B B B P B B B P B B B P B B B ...\n | |_______|_______| | |_______|_______|\n | | | |\n I-Frame P-frames I-Frame P-frames\n STORAGE ORDER:\n I P B B B P B B B P B B B I B B B P B B B P B B B P B B B ...\n | |_______|_______| | |_______|_______|\n | | | |\n I-Frame P-frames I-Frame P-frames\nSlices are containing the actual 16x16 pixel Macro Blocks. Usually a Slice contains one horizontal line - although, theoretically, it could be longer or shorter, ie. a slice could wrap to next line, or a line could be split into several slices (with the leading \"MBA Increment\" value greater than 1 to define the horizontal start offset).
32bit PACK_START_CODE (000001xxh; xx=01h..AFh; vertical index) ;-4byte\n 5bit Quantizer Scale (1..31) (may be later changed by blocks) ;-5bit\n (1bit) Fixed (1, indicates presence of Extra Info) ;\\opt. N*9bit\n (8bit) Extra Information ;/\n 1bit Fixed (0, indicates no further Extra Info) ;-1bit\n ... Macroblock (within horizontal line) ;...\n 0-7bit Padding to byte boundary (0) ;-0..7bit\n 32bit START_CODE (000001B2h=User Data, 000001B5h=Extension Data) ;-4byte\n ... data (end is signaled by presence of next 000001xxh code) ;-data\n 32bit SEQUENCE_END_CODE (000001B7h) ;-4byte\n N*11bit Macroblock_address_increase escape/stuffing codes (if any)\n 1..11bit Macroblock_address_increase\n 1-6bit Macroblock_type\n 5bit Quantizer_scale\n ... Motion_vector\n 3-9bit Coded_block_pattern\n ... Block(i)\n Addr Incr\n Type\n Motion Vector\n QScale\n CBP\n Block b0 (Y1)\n Block b1 (Y2)\n Block b2 (Y3)\n Block b3 (Y4)\n Block b4 (Cb)\n Block b5 (Cr)\nVCD video discs and .mpg movie files are having the MP2 Audio Stream enclosed in the Multiplex stream (whilst .mp2 audio files may contain raw MP2 data without Multiplex stream).
Each MP2 frame is starting with a FFFh syncword (which is always located on a byte boundary). Unfortunately, the value FFFh can also occur anywhere in the audio data (eg. a 16bit sample with value 3FFCh). So, when starting mid-stream, one will need some guessing when searching a valid syncword. The best method is to compute the frame size (based on the supposed frame header), and then to check if supposed frame begins AND ends with a sync word. Moreover, one could check for invalid sample rate values in the frame header, or invalid \"groupings\" in the frame's data part. VCDs are conventionally having three audio frames encoded in one CDROM sector, so the first syncword can be simply found right after the multiplex packet header (though that might differ in some cases: VCD2.0 allows different audio bitrates, and a CDROM sector could be theoretically shared for Audio and Video data).
"},{"location":"cdromvideocdsvcd/#overall-mp2-frame-format","title":"Overall MP2 Frame Format","text":" Header (32bit)\n Optional CRC (16bit) (or 0bit if none)\n Allocation Information\n Scale Factor Selector Information\n Scale Factors\n Data\n 12bit Syncword (FFFh) ;\\\n 1bit Revision (0=MPEG-2, 1=MPEG-1) ; 2 bytes\n 2bit Layer (2=Audio LayerII) ;for VCDs ;\n (3=LayerI, 1=LayerIII, 0=reserved) ;not on VCDs ;\n 1bit Protection_bit (1=no crc) ;/\n 4bit Bitrate_index (1..14) ;\\\n (0=free format, 15=reserved) ;\n 2bit Sampling_frequency ; 1 byte\n 1bit Padding_bit ;\n 1bit Private_bit ;/\n 2bit Mode ;\\\n 2bit Mode_extension (aka bound) ;\n 1bit Copyright ; 1 byte\n 1bit Original/home ;\n 2bit Emphasis ;/\n 16bit CRC\n XXX...\nThe Datel devices exist in various official/cloned hardware revisions, the DB25 connector requires a special Comms Link ISA card (or a \"FiveWire\" mod for making it compatible with normal PC parallel ports). Later \"PAR3\" models are said to not require Comms Link, and do thus probably work directly with normal parallel ports). Cheat Devices - Datel I/O Cheat Devices - Datel DB25 Comms Link Protocol Cheat Devices - Datel Chipset Pinouts Cheat Devices - Datel Cheat Code Format
"},{"location":"cheatdevices/#xplorerxploderx-terminator-fcdblaze","title":"Xplorer/Xploder/X-Terminator (FCD/Blaze)","text":"The FCD/Blaze devices are all same hardware-wise (with some cosmetic PCB revisions, and with extra SRAM and bigger FLASH installed in some carts). The DB25 connector can be directly connected to a PC parallel port. Cheat Devices - Xplorer Memory and I/O Map Cheat Devices - Xplorer DB25 Parallel Port Function Summary Cheat Devices - Xplorer DB25 Parallel Port Command Handler Cheat Devices - Xplorer DB25 Parallel Port Low Level Transfer Protocol Cheat Devices - Xplorer Versions Cheat Devices - Xplorer Chipset Pinouts Cheat Devices - Xplorer Cheat Code Format Cheat Devices - Xplorer Cheat Code and ROM-Image Decryption
"},{"location":"cheatdevices/#flash-chips-for-both-xplorer-and-datel","title":"FLASH Chips (for both Xplorer and Datel)","text":"Cheat Devices - FLASH/EEPROMs
http://gamehacking.org/faqs/hackv500c.html - cheat code formats http://doc.kodewerx.org/hacking_psx.html - cheat code formats http://xianaix.net/museum.htm - around 64 bios versions http://www.murraymoffatt.com/playstation-xplorer.html - xplorer bioses
"},{"location":"cheatdevices/#separating-between-gameshark-and-xplorer-codes","title":"Separating between Gameshark and Xplorer Codes","text":" First Digit Usage\n 3,8 Same for Gameshark & Xplorer (for Xplorer: can be encrypted)\n 1,2,C,D,E Gameshark\n 4,6,7,9,B,F Xplorer\n 0,5 Meaning differs for Gameshark & Xplorer\n A Unused\nCodebreaker Megacom Power Replay III Game Enhancer
"},{"location":"cheatdevices/#cheat-devices-datel-io","title":"Cheat Devices - Datel I/O","text":""},{"location":"cheatdevices/#datel-memory-and-io-map-for-par2-or-so","title":"Datel Memory and I/O Map (for PAR2 or so)","text":" 1F000000h-1F01FFFFh R/W Flash (first 128K)\n 1F020010h R Comms Link STB pin state (bit0)\n 1F020018h R Switch Setting (bit0: 0=Off, 1=On)\n 1F040000h-1F05FFFFh R/W Flash (second 128K) + feedback area (see below)\n 1F060000h R Comms Link data in (byte)\n 1F060008h W Comms Link data out (byte, pulses ACK to Comms Link)\nOriginal PAR1 might have supported only 128K FLASH (?) if so, the I/O ports are probably same as above, but without the \"second 128K\" FLASH area.
"},{"location":"cheatdevices/#datel-par3","title":"Datel PAR3","text":"The PAR3 version is said to work with parallel ports (not needing the Comms Link IDA card), and said to support more FLASH with bankswitching, so the I/O ports must work somehow entirely different as described above. Some notes from a (poorly translated) japanese document: PAR3 Memory:
1f000000-1f01ffff ROM. Change in bank switching.\n 1f020000-1f03ffff ROM. Change in bank switching.\n 1f040000-1f05ffff whopping RAM. It is able to use.\n 1f060000-1f06003f I/O. Intently mirror to the subsequent 1f07ffff.\n 1f060000 for reception. (1f060000 use only.) All bytes same treatment like.\n It is 01h in the state that does not connected anything.\n 1f060008 for transmission. (1f060008 use only.) This is ffh in the state\n that does not connected anything.\n 1f060010 during data reception it will stand the least significant bit.\n Usually is fe.\n 1f060018 state of the push button. In not pressed and fefefefefefefefe,\n it will Ost ffffffffffffffff.\n 1f060020 I think 1f060020 unused. It is ffffffffffffffff.\n 1f060028 I think 1f060028 unused. It is ffffffffffffffff.\n 1f060030 bank switching. 1 put and run-time of the ROM, and changes to the\n 3's and the start-up of the ROM.\n 1f060038 would be what? It is lbu. Like there is a meaning bits 0 and 1.\n It was fcfcfcfcfcfcfcfc. I think that it is bank cult.\nThe Boot Command Handler is executed once at Pre-Boot, and also (at least in some firmware versions) once before displaying the GUI. Following command(s) can be sent from PC side:
Repeatedly send 8bit \"W\", until receiving \"R\"\n Repeatedly send 8bit \"B\", until receiving \"W\"\n Send 8bit command \"X\" (upload/exec) or \"U\" (upload/flash), and receive ECHO\n Send 32bit ADDRESS, and receive ECHO or \"BX\" (bad command)\n Send 32bit LENGTH, and receive ECHO\n Send DATA[LENGTH], and receive ECHO\n Send 16bit CHECKSUM, and receive ECHO\n (for upload/flash and if checksum was good, PSX will now BURN ADDR,LENGTH)\n Send 16bit DUMMY, and receive \"OK\"/\"BC\"/\"BF\" (okay, bad chksum, bad flash)\n (for upload/exec and if checksum was good, PSX will now CALL ADDR)\n (thereafter, PAR2.0 and up will reboot via jmp BFC00000h)\nThere must be some further command handler(s) after the Boot Command Handler, with support for additional cheat related commands, and (at least in Caetla) with support for uploading EXE files with Kernel functions installed (the Boot Command Handler at Pre-Boot time can also upload EXE code, but doesn't have Kernel installed). Original Datel commands for Menu/Game mode are unknown. The Caetla commands are documented in japanese, and there are also two english translations: http://www.psxdev.net/forum/viewtopic.php?f=49&t=370 - good (though incomplete) http://www.psxdev.net/forum/viewtopic.php?f=53&t=462#p6849 - very bad (beware)
"},{"location":"cheatdevices/#cheat-devices-datel-chipset-pinouts","title":"Cheat Devices - Datel Chipset Pinouts","text":"There appear to be numerous Datel hardware revisions (and possibly numerous Datel clones). So this chapter is unlikely to cover all hardware revisions.
PSX Expansion cards:\n PCB Controller FLASH DB25 spotted by\n DATEL REF 1215 GAL + 74HC245 128K+128K yes Type79\n DATEL REF 1288 DATEL ASIC1 256K yes nocash\n DATEL xxx? GAL + PIC + HC245 128K yes CharlesMacD\n noname? GAL + 74HC245 256K+0K yes Type79\n DATEL REF 1324 lots of chips? lots? no CyrusDevX\n DATEL REF 1326 lots of chips? lots? yes Type79\n PS-121 ZISAN GAL + PIC? + HC245 128K yes Kryptonick\n Comms Link ISA cards:\n PCB Chipset spotted by\n DATEL COMMS LINK, XXX? blurry SMD chipset? lowres photo\n DATEL REF 1113, IBM SATURN LINK 1x74HC74, 2x74HC373, 1xXXX? Type79\n EMS, PCCOM 1x74HC74, 2x74HC373, 1xXXX? jokergameth\n DIY Alternatives to Comms Link\n FiveWire ;simple hardware mod for use with parallel ports, for SPP/EPP\n FreeWing ;parallel port adaptor, lots of 74xxx TTL chips, for SPP/EPP\n ExStand ;parallel port adaptor, lots of 74xxx TTL chips, for EPP\n CommLinkUSB ;USB adaptor, Buy-and-Diy technology (adafruit/teensy based)\nThe ASIC1 chip is found in this hardware:
Label: \"EQUALIZER, EVEN THE ODDS\" (sticker on outside of case)\n Case: \"DATEL ENGLAND\" (printed inside of case)\n PCB: \"DATEL REF1288 SONY SONYPSX2meg\"\n U: 44pin \"DATEL, ASIC1, A8B1944A, 9832\" ;custom logic chip\n U: 32pin \"SST, 29EE020, 150-4C-NH, 981918-D\" ;256Kx8 EEPROM\n U: 8pin \"83BA, LM78L, 05ACM\" ;5V voltage regulator\n CN: 25pin DB25 connector (for Comms Link ISA card)\n CN: 68pin PSX expansion port connector\n SW: 3pin Switch\n 7 D0 18 DB25.2.DATA0 29 D0 (same as pin7) 40 A3\n 8 D1 19 DB25.3.DATA1 30 EERPROM./WE 41 A4\n 9 D2 20 DB25.4.DATA2 31 /WR 42 /EXP\n 10 GND 21 GND 32 GND 43 GND\n 11 D3 22 DB25.5.DATA3 33 /RD 44 A17\n 12 D4 23 DB25.6.DATA4 34 /MODE (\"jumper\") 1 A18\n 13 D5 24 DB25.7.DATA5 35 VCC 2 GND\n 14 VCC 25 VCC 36 DB25.11.ACK 3 VCC\n 15 D6 26 DB25.8.DATA6 37 ? 4 EEPROM./OE\n 16 VCC 27 DB25.9.DATA7 38 VCC 5 DB25.10.STB\n 17 D7 28 EEPROM./CS 39 ? 6 SWITCH\n 1-NC 8-NC 15-NC 22-NC\n 2-FBIN 9-CPU.A4 16-GNDed 23-FLASH./WE\n 3-CPU.A17 10-CPU./EXP 17-DB25.pin10 (PAR.STB) 24-FBOUT\n 4-CPU./WR 11-CPU.A3 18-FLASH./CS 25-FLASH./OE (and BUF.DIR)\n 5-CPU./RD 12-CPU.A5 19-DB25.pin11 (PAR.ACK) 26-BUF./EN\n 6-CPU.A18 13-SWITCH 20-CPU.D0 27-unused\n 7-CPU.A20 14-GND 21-FLASH.A17 28-VCC\n 1-FBIN 7-CPU.A4.NC? 13-GNDed 19-FLASH./WE\n 2-PIC.RC1 8-CPU./EXP.NC? 14-PAR.STB 20-FBOUT\n 3-CPU./WR 9-CPU.A3 15-PIC.RA0 21-BUF.DIR\n 4-CPU./RD 10-CPU.A2 16-PAR.ACK 22-BUF./OE\n 5-CPU.A18 11-SWITCH 17-CPU.D0 23-PIC.RC0\n 6-CPU.A17 12-GND 18-FLASH./OE 24-VCC\n 1-FBIN 6-CPU.A17 11-CPU.A2 16-FBOUT\n 2-SWITCH 7-CPU.A4.NC? 12-PAR.ACK 17-CPU.A20\n 3-CPU./WR 8-CPU./EXP.NC? 13-CPU.D0 18-PAR.STB\n 4-CPU./RD 9-CPU.A3 14-FLASH./OE 19-BUF./OE\n 5-CPU.A18 10-GND 15-FLASH./WE 20-VCC\nPAL
1-/STATUS 7-ISA.A6 13-JP2 19-NC\n 2-ISA.A1 8-ISA.A7 14-ISA.A9 20-PCWR\n 3-ISA.A2 9-ISA.A8 15-NC 21-/PCRD\n 4-ISA.A3 10-ISA.AEN 16-ISA./IOW 22-NC\n 5-ISA.A4 11-JP1 17-/IRQ 23-ISA./IOR\n 6-ISA.A5 12-GND 18-ISA.D0 24-VCC\n Pin Parallel Port CommsLink (PC) cable PAR (PSX)\n 1 /STB ----> \"strobe\" ----.---o-------------o-- -- NC\n 2-9 DATA <-/----> DATA <-- | --o-------------o-------> DATA\n 10 /ACK <---- \"strobe\" ----'---o-------------o-------> \"strobe\"\n 11 BUSY <---- \"ack\" <-------o-------------o-------- \"ack\"\n 12 PE <---- NC -- --o-------------o-- -- NC\n 13 SLCT <---- NC -- --o-------------o-- -- NC\n 14 /AUTOLF ----> NC -- --o-------------o--. .-- GNDed\n 15 /ERROR <---- NC -- --o-------------o--. .-- GNDed\n 16 /INIT ----> NC -- --o-------------o--. .-- GNDed\n 17 /SELECT ----> GNDed --. .--o-------------o--. .-- GNDed\n 18-25 GND ----- GND --'--'--o-------------o--'--'-- GND\n disconnect DB25.pin14,15,16,17 from GND (may require to desolder the DB25)\n repair any GND connections that were \"routed through\" above pins\n wire DB25.pin1./STB to DB25.pin10./ACK\n wire DB25.pin16./INIT to PSX.EXPANSION.pin2./RESET\n wire DB25.pin15./ERROR to PSX.EXPANSION.pin28.A20\n wire DB25.pin13.SLCT to PSX.EXPANSION.pin62.A21\n wire DB25.pin12.PE to PSX.EXPANSION.pin29.A22\n 30aaaaaa 00dd ;-8bit Write [aaaaaa]=dd\n 80aaaaaa dddd ;-16bit Write [aaaaaa]=dddd\n D0aaaaaa dddd ;-16bit/Equal If dddd=[aaaaaa] then (exec next code)\n D1aaaaaa dddd ;-16bit/NotEqual If dddd<>[aaaaaa] then (exec next code)\n D2aaaaaa dddd ;-16bit/Less If dddd<[aaaaaa] then (exec next code)\n D3aaaaaa dddd ;-16bit/Greater If dddd>[aaaaaa] then (exec next code)\n E0aaaaaa 00dd ;-8bit/Equal If dd=[aaaaaa] then (exec next code)\n E1aaaaaa 00dd ;-8bit/NotEqual If dd<>[aaaaaa] then (exec next code)\n E2aaaaaa 00dd ;-8bit/Less If dd<[aaaaaa] then (exec next code)\n E3aaaaaa 00dd ;-8bit/Greater If dd>[aaaaaa] then (exec next code)\n 10aaaaaa dddd ;-16bit Increment [aaaaaa]=[aaaaaa]+dddd\n 11aaaaaa dddd ;-16bit Decrement [aaaaaa]=[aaaaaa]-dddd\n 20aaaaaa 00dd ;-8bit Increment [aaaaaa]=[aaaaaa]+dd\n 21aaaaaa 00dd ;-8bit Decrement [aaaaaa]=[aaaaaa]-dd\n D4000000 dddd ;-Buttons/If If dddd=JoypadButtons then (exec next code)\n D5000000 dddd ;-Buttons/On If dddd=JoypadButtons then (turn on all codes)\n D6000000 dddd ;-Buttons/Off If dddd=JoypadButtons then (turn off all codes)\n C0aaaaaa dddd ;-If/On If dddd=[aaaaaa] (turn on all codes)\n 5000nnbb dddd ;\\Slide Code aka Patch Code aka Serial Repeater\n aaaaaaaa ??ee ;/for i=0 to nn-1, [aaaaaaaa+(i*bb)]=dddd+(i*??ee), next i\n 00000000 0000 ;-Dummy (do nothing?) needed between slides (CD version only)\n C1000000 nnnn ;-Delays activation of codes by nnnn (4000-5000 = 20-30 sec)\n C2ssssss nnnn ;\\Copy ssss bytes from 80ssssss to 80tttttt\n 80tttttt 0000 ;/\nThese are probably caetla-specific, not official Datel-codes. In fact, Caetla .341 itself might be an inofficial hacked version of Caetla .34 (?) so below might be totally inofficial stuff:
C3aaaaaa 0000 ;\\Indirect 8bit Write [[aaaaaa]+bbbb]=dd\n 9100bbbb 000000dd ;/\n C3aaaaaa 0001 ;\\Indirect 16bit Write [[aaaaaa]+bbbb]=dddd (Tomb Raider 2)\n 9100bbbb 0000dddd ;/\n C3aaaaaa 0002 ;\\Indirect 32bit Write [[aaaaaa]+bbbb]=dddddddd\n 9100bbbb dddddddd ;/\n FFFFFFFF 0001 ;-Optional prefix for GameShark 2.2 codes(force non-caetla)\n 12aaaaaa dddddddd ;-32bit Increment [aaaaaa]=[aaaaaa]+dddddddd\n 22aaaaaa dddddddd ;-32bit Decrement [aaaaaa]=[aaaaaa]-dddddddd\nA maximum of 30 increment/decrement codes can be used at a time. A maximum of 60 conditionals can be used at a time (this includes Cx codes). Increment/decrement codes should (must?) be used with conditionals. Unknown if greater/less conditionals are signed or unsigned. Unclear if greater/less compare dddd by [aaaaaa], or vice-versa. Unknown if 16bit codes do require memory alignment.
"},{"location":"cheatdevices/#cheat-devices-xplorer-memory-and-io-map","title":"Cheat Devices - Xplorer Memory and I/O Map","text":""},{"location":"cheatdevices/#xplorer-memory-map","title":"Xplorer Memory Map","text":" 1F000000h-1F03FFFFh.RW First 256K of FLASH (fixed mapping)\n 1F040000h-1F05FFFFh.RW Map-able: 2x128K FLASH or 4x128K SRAM (if any)\n 1F060000h-1F060007h.xx I/O Ports\n 1F060008h-1F06FFFFh Mirrors of I/O at 1F060000h..1F060007h\n 1F070000h-1F07FFFFh Unused (open bus)\n 1F005555h.W FLASH Cmd 1st/3rd byte ;\\for first FLASH chip\n 1F002AAAh.W FLASH Cmd 2nd byte ;/\n 1F045555h.W FLASH Cmd 1st/3rd byte ;\\for 2nd FLASH chip (if any)\n 1F042AAAh.W FLASH Cmd 2nd byte ;/\n 1F060000h.R I/O - Switch Setting (bit0: 0=Off, 1=On)\n 1F060001h.R I/O - 8bit Data from PC (bit0-7)\n 1F060001h.W I/O - 8bit Latch (Data to PC, and Memory Mapping)\n 0 DB25.pin13.SLCT ;\\\n 1 DB25.pin12.PE ; used for data to PC\n 2 DB25.pin11.BUSY ;/\n 3 DB25.pin10./ACK ;-used for handshake to PC\n 4 Memory Mapping (0=EEPROM, 1=SRAM)\n 5 Memory Mapping (EEPROM A17 when A18=1)\n 6 Memory Mapping (SRAM A17 or SRAM CE2)\n 7 Memory Mapping (SRAM A18 or NC)\n 1F060002h.R I/O - Handshake from PC (bit0) (DB25.pin17./SEL)\n 1F060005h.W I/O - Unknown (used by Xplorer v4.52, set to 03h)\n 1F060006h.R I/O - Unknown (used by Xplorer v4.52, bit0 used)\n 1F060007h.R I/O - Unknown (used by Xplorer v4.52, bit0 used)\n GetByteByAddr32 Tx(5702h,Addr32), Rx(Data8)\n OldMenuBuReadFile Tx(5703h), TxFilename, RxDataFFEEh\n OldMenuBuDeleteFile Tx(5704h), TxFilename\n OldMenuBuWriteFile Tx(5705h), TxFilename, TxFiledata\n OldMenuBuGetFileHdr Tx(5706h), TxFilename, Rx(00h,00h), RxTurbo, Rx(02h)\n OldMenuBuOpenEvents Tx(5707h)\n SetCop0Breakpoint Tx(5708h,Addr32,Mask32,Ctrl32) ;Menu: Dummy?\n OldMenuBuCopyFile Tx(5709h), TxFilename ;to other memcard\n OldMenuBuFormat Tx(570Ah,Port8)\n OldMenuBuGetStatus2x Tx(570Bh), Rx(Stat8,Stat8) ;\\different in old/new\n NewMenuBuGetStatus1x Tx(570Bh,Port8), Rx(Stat8) ;/\n MenuGetSetFlag Tx(570Ch), Rx(Flag8) ;get old flg, then set flg=01h\n NewMenuBuReadSector Tx(570Dh,Port8,Sector16), Rx(Data[80h])\n NewMenuBuWriteSector Tx(570Eh,Port8,Sector16,Data[80h])\n NewRawExecute Tx(570Fh,Addr32) ;call Addr\n MidMenuBuggedExecJump Tx(5710h,ORra32,ORgp32,ORsp32,pc32) ;aka r31,r28,r29,pc\n MidMenuSendComment Tx(5711h,Len8,AsciiMessage[Len])\n NewMenuFillVram Tx(5712h,Xloc32,Yloc32,Xsiz32,Ysiz32,FillValue32)\n NewGetVram Tx(5713h,Xloc32,Yloc32), Rx(Data[800h]) ;32x32pix\n NewGetSetIrqMask Tx(5714h), Rx(OldMask16), Tx(NewMask16) ;Menu: Dummy\n NewSetVram Tx(5715h,Xloc8,Yloc8,Data[800h]) ;X/Y=div32 ;32x32pix\n NewMenuGetFlgAndOrVal Tx(5716h), Rx(00h, or 01h,Val32) ;\\\n NewMenuGetTwoValues Tx(5717h), Rx(Val32,Val32) ;\n NewMenu... Tx(5718h), ... ;\n NewMenuGet2kGarbage Tx(5719h,Dummy32), Rx(Garbage[800h]) ; whatever\n NewMenuGetSomeValue Tx(571Ah), Rx(Val32) ;\n NewMenu... Tx(571Bh,Data[4]) ;similar to 5763h ;\n NewMenuNoLongerSupp. Tx(571Ch) ;probably WAS supported someday ;/\n GameAddCheatCode Tx(5741h,Addr32,Data16), Rx(Index8)\n MenuReBootKernel Tx(5742h) ;jumps to BFC00000h\n GameDelCheatCode Tx(5744h,Index8)\n GetMem Tx(5747h,Addr32,Len32), Rx(Data[Len]), TxRxChksum\n Lock/Freeze Tx(574Ch)\n OldMenuBuGetDirectory Tx(574Dh), RxTurbo\n MenuTestDB25Handshake Tx(574Eh), ...\n MenuOptimalGetMem Tx(574Fh,Addr32,Len32), RxFaster(Data[Len]), TxRxChksum\n OldMenuGetWhatever Tx(5750h), RxDataFFEEh ;-whatever\n Release/Unfreeze Tx(5752h)\n SetMem Tx(5753h,Addr32,Len32,Data[Len]), TxRxChksum\n TurboGetMem Tx(5754h,Addr32,Len32), RxFast(Data[Len]), TxRxChksum\n MenuSetMemAndBurnFirm Tx(5755h,Addr32,Len32,Data[Len]), TxRxChksum ;burnFlash\n GetStateGameOrMenu Tx(5757h), Rx(47h=Game, or 58h=Menu)\n SetMemAndExecute Tx(5758h,Addr32,Len32,Data[Len]), TxRxChksum ;call Addr\n NewMenu... Tx(5763h,Val32) ;similar to 571Bh ;-whatever\n GetByteByAddr24 Tx(5767h,Addr24), Rx(Data8)\n NewMenuBuggedExecJump Tx(577Ah,ORra32,ORgp32,ORsp32,pc32) ;formerly 5710h\n NewMenuFlashAndReboot Tx(57C7h,Dest32,Len32,DataXorD3h[Len])\nThe only useful command is SetMemAndExecute, which works in ALL versions, and which can be used to do whatever one wants to do (unfortunately, most of the official & inoffical tools are relying on other weird commands, which are working only with specific xplorer firmware versions).
"},{"location":"cheatdevices/#cheat-devices-xplorer-db25-parallel-port-command-handler","title":"Cheat Devices - Xplorer DB25 Parallel Port Command Handler","text":"The command handler is called once and then during booting, during xplorer GUI, and during Game execution. Each call to the command handler does allow to execute ONLY ONE command, however, the \"Freeze\" command can be used to force the xplorer to stay in the command handler, so one can send MORE commands, until leaving the command handler by sending the \"Unfreeze\" command. The command handling can vary depending on current boot phase (see below cautions on Pre-Boot, Mid-Boot, and In-Game phases).
"},{"location":"cheatdevices/#pre-boot-handler","title":"Pre-Boot Handler","text":"This is called shortly after the kernel has done some basic initialization, and after the xplorer has relocated its EEPROM content to RAM (which means it may called about a second after reset when using official PSX kernel and Xplorer Firmware).
OLD Explorer Firmware: Call command handler ONCE (in MENU mode)\n NEW Explorer Firmware: Call command handler TWICE (in MENU mode)\n if SWITCH=ON or [80000030h]=\"WHB.\" then\n NEW Explorer Firmware: Call command handler ONCE AGAIN (in MENU mode)\n Install Mid-Boot hook\n endif\nThe Xplorer GUI is called only if the Pre-Boot handler has installed it (eg. if the SWITCH was ON). The handler is called alongsides with joypad reading (which does NOT take place during the Xplorer intro, so there will be a long dead spot between Pre-Boot and Mid-Boot command handling).
Call command handler ONCE (in MENU mode) alongsides with each joypad read\nThis is called when starting CDROM booting.
Install GAME mode hook for the B(17h) ReturnFromException() handler\n OLD Explorer Firmware: Call command handler ONCE (still in MENU mode)\n NEW Explorer Firmware: Call command handler ONCE (already in GAME mode)\nThis is called via the hooked B(17h) ReturnFromException() handler.
if SWITCH=ON\n Call command handler ONCE (in GAME mode) upon each B(17h)\n And, process game cheat codes (if any) upon each B(17h)\n endif\nAll 16bit/24bit/32bit parameters are transferred MSB first.
"},{"location":"cheatdevices/#txdata-transmit-data-bytes","title":"Tx(Data) - transmit data byte(s)","text":" Output 8bit data to DATA0-7 (DB25.pin2-9) ;-Send Data (D0-D7)\n Output /SEL=HIGH (DB25.pin17) ;\\Handshake High\n Wait until /ACK=HIGH (DB25.pin10) ;/\n Output /SEL=LOW (DB25.pin17) ;\\Handshake Low\n Wait until /ACK=LOW (DB25.pin10) ;/\n Wait until /ACK=HIGH (DB25.pin10) ;\\\n Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 1st Part (D6,D7,HIGH)\n Output /SEL=HIGH (DB25.pin17) ;/\n Wait until /ACK=LOW (DB25.pin10) ;\\\n Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 2nd Part (D3,D4,D5)\n Output /SEL=LOW (DB25.pin17) ;/\n Wait until /ACK=HIGH (DB25.pin10) ;\\\n Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 3rd Part (D0,D1,D2)\n Output /SEL=HIGH (DB25.pin17) ;/\n Wait until /ACK=LOW (DB25.pin10) ;\\4th Part (ver,LOW,LOW)\n Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; (ver=LOW for v1.091)\n Output /SEL=LOW (DB25.pin17) ;/ (ver=HIGH for v4.52)\n Wait until all 4bits LOW (DB25.pin13,12,11,10);-xlink95 fails if not\nFirst, for invoking the Turbo transfer:
Wait for BUSY=LOW (DB25.pin11)\n Output DATA = 00h (DB25.pin2-9)\n Wait for BUSY=HIGH (DB25.pin11)\n Output DATA = ECh (DB25.pin2-9)\n Wait for /ACK transition (DB25.pin10) ;\\\n Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 1st Part (D6,D7,LOW)\n Output DATA = 02h (DB25.pin2-9) ;/\n Wait for /ACK transition (DB25.pin10) ;\\\n Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 2nd Part (D3,D4,D5)\n Output DATA = 04h (DB25.pin2-9) ;/\n Wait for /ACK transition (DB25.pin10) ;\\\n Get 3bit from SLCT,PE,BUSY (DB25.pin13,12,11) ; 3rd Part (D0,D1,D2)\n Output DATA = 01h (DB25.pin2-9) ;/\nFirst, for invoking the Turbo transfer:
Output DATA = 00h ;<-- crap (DB25.pin2-9) ;-BUGGY, but REQUIRED\n Get 4bit from SLCT,PE,BUSY,/ACK (DB25.pin13,12,11,10);\\1st Part (D4,D5,D6,D7)\n Output DATA = 00h (DB25.pin2-9) ;/\n Get 4bit from SLCT,PE,BUSY,/ACK (DB25.pin13,12,11,10);\\2nd Part (D0,D1,D2,D3)\n Output DATA = 01h (DB25.pin2-9) ;/\n Tx(chkMsb), Rx(chkMsb), Tx(chkLsb), Rx(chkLsb), Rx(\"OK\" or \"CF\" or \"BG\")\n Rx(Addr32), Tx(Addr32,Len32,Data[Len]), TxRxChksum\n Rx(Filename[26h]) ;-name from TxFilename, echo'ed back\n Rx(Addr32) ;-buffer address for fragments\n Tx(NumFragments8) ;-number of fragments\n Tx(Addr32,Len32,Data[Len]), TxRxChksum ;<-- repeat this for each fragment\n Rx(FileHandle8) ;-ending dummy byte (filehandle)\n Rx(FFEEh,\"W\",Len32,Data[Len] ;<-- can be repeated for several fragments\n Rx(FFEEh,\"CA\") ;<-- End Code (after last fragment)\n Rx(Addr32), Tx(Addr32,Len32), RxFast(Data[Len]), TxRxChksum\n Xploder (Germany/USA)\n Xplorer (England/Spain/Netherlands)\n X-Terminator (Japan)\n V1/V2/V3 normal boards (256K EEPROM, no SRAM, no DB25 resistor)\n FX/DX extended boards (512K EEPROM, 128K SRAM, with DB25 resistor)\n PRO meaningless suffix\n 1) PXT6 ;original board\n 2) Nameless ;with alternate solder pads for smaller SRAM/GAL\n 3) PXT6-3 ;with alternate solder pads for smaller SRAM/GAL and 2nd EEPROM\nThe three PCB versions are functionally identical, and do differ only by cosmetic changes for alternate/smaller chip packages. However, some things that can make difference in functionality are the installed components and installed firmware version:
- FX carts have some extra components & more memory installed.\n (needed for \"bigger\" firmwares, mainly needed for the X-Assist add-on)\n - FLASH chips from different manufacturers can occassionally cause problems\n (eg. older software not knowing how to program newer FLASH chips).\n - DB25 transfer protocol has some changed commands in each firmware version\n (and most transfer tools tend to rely on such commands, so most tools will\n fail unless the cart is flashed with a certain firmware version).\nThe X-Assist is a quity huge clumsy controller with DPAD, plus 4 buttons, plus small LCD screen. The thing connects to the Xplorer's DB25 connector, allowing to enter/search cheat codes without using a PC. The device works only with \"FX\" Xplorer boards (which contain an extra resistor for outputting supply power on the DB25 connector, plus more memory which is somewhat intended for use by the X-Assist thing).
"},{"location":"cheatdevices/#cheat-devices-xplorer-chipset-pinouts","title":"Cheat Devices - Xplorer Chipset Pinouts","text":""},{"location":"cheatdevices/#xplorer-pinout-gal20v8-generic-array-logic","title":"Xplorer Pinout GAL20V8 (generic array logic)","text":" 1 IN0 (DB25.pin17./SEL)\n 2 IN1 (PSX.pin14.A0)\n 3 IN2 (PSX.pin48.A1)\n 4 IN3 (PSX.pin15.A2)\n 5 IN4 (74373.pin15.Q5)\n 6 IN5 (PSX.pin4./EXP)\n 7 IN6 (74373.pin12.Q4)\n 8 IN7 (PSX.pin26.A16) (EEPROM.pin2.A16) (SRAM.pin2.A16) (10000h)\n 9 IN8 (PSX.pin60.A17) (20000h)\n 10 IN9 (PSX.pin27.A18) (EEPROM.pin1.A18 or NC) (40000h)\n 11 IN10 (PSX.pin30./RD)\n 12 GND\n ---\n 13 IN11 (GND)\n 14 IN12 (/SWITCH_ON)\n 15 IO (74373.pin11.LE)\n 16 IO (PSX.pin6.D0)\n 17 IO (SRAM./CE.pin22)\n 18 IO (EEPROM2./CE.pin22) (for 2nd EEPROM chip, if any)\n 19 IO (EEPROM1./CE.pin22) (for 1st EEPROM chip)\n 20 IO (NC) (reportedly has wire?)\n 21 IO (EEPROM.pin30.A17) (reportedly A14 ?)\n 22 IO (74245.pin19./E)\n 23 IN13 (PSX.pin64./WR) (SRAM.29, EEPROM.31)\n 24 VCC\n 1 /OE (GND)\n 2 Q0 (DB25.pin13.SLCT)\n 3 D0 (PSX)\n 4 D1 (PSX)\n 5 Q1 (DB25.pin12.PE)\n 6 Q2 (DB25.pin11.BUSY)\n 7 D2 (PSX)\n 8 D3 (PSX)\n 9 Q3 (DB25.pin10./ACK)\n 10 GND\n 11 LE (GAL.pin15.LatchEnable)\n 12 Q4 (GAL.pin7) (0=EEPROM, 1=SRAM)\n 13 D4 (PSX)\n 14 D5 (PSX)\n 15 Q5 (GAL.pin5) (EEPROM bank 2/3)\n 16 Q6 (SRAM.pin30.A17 or CE2)\n 17 D6 (PSX)\n 18 D7 (PSX)\n 19 Q7 (SRAM.pin1.A18 or NC)\n 20 VCC\n 1 DIR (GNDed)\n 2 D7 (PSX)\n 3 D6 (PSX)\n 4 D5 (PSX)\n 5 D4 (PSX)\n 6 D3 (PSX)\n 7 D2 (PSX)\n 8 D1 (PSX)\n 9 D0 (PSX)\n 10 GND\n 11 D0 (DB25.pin2)\n 12 D1 (DB25.pin3)\n 13 D2 (DB25.pin4)\n 14 D3 (DB25.pin5)\n 15 D4 (DB25.pin6)\n 16 D5 (DB25.pin7)\n 17 D6 (DB25.pin8)\n 18 D7 (DB25.pin9)\n 19 /E (GAL.pin22)\n 20 VCC\n 1 5V (VCC)\n 2 GND (GND)\n 3 7.5V (PSX.pin18,52)\n OFF NC\n COM PAL.pin14 (with 10K pull-up to VCC)\n ON GND\n 1 In /STB (NC)\n 2 In DATA0 (74245.pin11)\n 3 In DATA1 (74245.pin12)\n 4 In DATA2 (74245.pin13)\n 5 In DATA3 (74245.pin14)\n 6 In DATA4 (74245.pin15)\n 7 In DATA5 (74245.pin16)\n 8 In DATA6 (74245.pin17)\n 9 In DATA7 (74245.pin18)\n 10 Out /ACK (74373.Q3)\n 11 Out BUSY (74373.Q2)\n 12 Out PE (74373.Q1)\n 13 Out SLCT (74373.Q0)\n ---\n 14 In /LF (NC)\n 15 Out /ERR (VCC via 0.47ohm) (installed only on carts with SRAM)\n 16 In /INIT (NC)\n 17 In /SEL (GAL.IN0.pin1)\n 18..25 GND (Ground)\nEEPROM.pin1 is NC on 256Kx8 chip (however it is wired to A18 for use with 512Kx8 chips). EEPROM.pin30 is A17 from GAL.pin21 (not from PSX.A17), accordingly GAL.pin21 is EEPROM.A17 (not A14). Boards with solder pads for TWO EEPROMs are leaving A18 not connected on the 2nd EEPROM (but do connect A18 to the first EEPROM, so one could either use one 512K chip or two 256K chips). DB25.pin15./ERR is VCC via 0.47ohm (installed only on carts with SRAM, intended as supply for the X-ASSIST thing). SRAM (if any) is wired to GAL.pin17 (/CE), 74373.Q6 (A17 or CE2), 74373.Q7 (A18 or NC), other SRAM pins are wired straight to D0-D7, A0-A16, /RD, /WR. VCC is 5V, derived from a 7805 voltage converter (with 7.5V used as input). Existing boards seem to have 128K SRAM (if any), so SRAM A17/A18 aren't actually used (unless a board would have 512K SRAM), however, for 128K SRAMs one should switch SRAM CE2 (aka A17) high.
"},{"location":"cheatdevices/#cheat-devices-xplorer-cheat-code-format","title":"Cheat Devices - Xplorer Cheat Code Format","text":""},{"location":"cheatdevices/#psx-xplorerxploder-code-format","title":"PSX Xplorer/Xploder Code Format","text":" 3taaaaaa 00dd ;-8bit write [aaaaaa]=dd\n 8taaaaaa dddd ;-16bit write [aaaaaa]=dddd\n 00aaaaaa dddd ;-32bit write [aaaaaa]=0000dddd <-- not \"0taaaaaa dddd\" ?\n 4t000000 000x ;-Slow Motion (delay \"x\" whatever/ns,us,ms,frames?)\n 7taaaaaa dddd ;-IF [aaaaaa]=dddd then <execute following code>\n 9taaaaaa dddd ;-IF [aaaaaa]<>dddd then <execute following code>\n Ftaaaaaa dddd ;-IF [aaaaaa]=dddd then activate \"other selected\" codes (uh?)\n 5taaaaaa ?nnn ;\\\n d0d1d2d3 d4d5 ; write \"?nnn\" bytes to [aaaaaa] ;ordered d0,d1,d2... ?\n d6d7d8.. .... ;/\n 6t000000 nnnn ;\\COP0 hardware breakpoint\n aaaaaaaa cccc ; aaaaaaaa=break_address, mmmmmmmm=break_mask\n mmmmmmmm d0d1 ; nnnn=num_bytes (d0,d1,d2,etc.), cccc=break_type (see below)\n d2d3d4.. .... ;/\n B?nnbbbb eeee ;\\Slide/Patch Code, with unclear end: \"end=?nn+/-1\" ?\n 10aaaaaa dddd ;/for i=0 to end, [aaaaaa+(i*bbbb)]=dddd+(i*eeee), next i\n C0aaaaaa dddd ;-garbage/mirror of 70aaaaaa dddd ? ;\\or maybe meant to be\n D0aaaaaa dddd ;-garbage/mirror of 70aaaaaa dddd ? ;/same as on GameShark?\n E180 (instruction gotton by CPU but not yet implemented) (uh, gotton what?)\n EE80 (data to be read or written) ;<--looks okay\n E680 (data to be read) ;<--looks okay\n EA80 (data to be wrtten) ;<--looks okay\n EF80 (instruction) ;<-- looks crap, should be probably E180\nThe \"Slide\" code shall be used only with even addresses, unknown if other 16bit/32bit codes do also require aligned addresses.
"},{"location":"cheatdevices/#cheat-devices-xplorer-cheat-code-and-rom-image-decryption","title":"Cheat Devices - Xplorer Cheat Code and ROM-Image Decryption","text":""},{"location":"cheatdevices/#decrypt_xplorer_cheat_code","title":"decrypt_xplorer_cheat_code:","text":" key = x[0] and 07h ;'''''''' AABBCCDD EEFF '''''''';\n x[0] = x[0] xor key ; / / / \\ \\ \\ ;\n if key=0 ; x[0] --' / / \\ \\ '-- x[5] ;\n ;unencrypted (keep as is) ; x[1] ---' / \\ '--- x[4] ;\n elseif key=4 ; x[2] ----' '----- x[3] ;\n x[1] = x[1] xor (025h) ;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,;\n x[2] = x[2] xor (0FAh + (x[1] and 11h))\n x[3] = x[3] xor (0C0h + (x[2] and 11h) + (x[1] xor 12h))\n x[4] = x[4] xor (07Eh + (x[3] and 11h) + (x[2] xor 12h) + x[1])\n x[5] = x[5] xor (026h + (x[4] and 11h) + (x[3] xor 12h) + x[2] + x[1])\n elseif key=5\n x[1] = (x[1] + 057h) ;\"W\"ayne\n x[2] = (x[2] + 042h) ;\"B\"eckett\n x[3] = (x[3] + 031h) ;\"1\"\n x[4] = (x[4] + 032h) ;\"2\"\n x[5] = (x[5] + 033h) ;\"3\"\n elseif key=6\n x[1] = (x[1] + 0ABh) xor 01h\n x[2] = (x[2] + 0ABh) xor 02h\n x[3] = (x[3] + 0ABh) xor 03h\n x[4] = (x[4] + 0ABh) xor 04h\n x[5] = (x[5] + 0ABh) xor 05h\n elseif key=7\n x[5] = x[5] + 0CBh\n x[4] = x[4] + 0CBh + (x[5] and 73h)\n x[3] = x[3] + 05Ah + (x[4] and 73h) - (x[5] xor 90h)\n x[2] = x[2] + 016h + (x[3] and 73h) - (x[4] xor 90h) + x[5]\n x[1] = x[1] + 0F5h + (x[2] and 73h) - (x[3] xor 90h) + x[4] + x[5]\n else\n error ;(key=1,2,3)\n endif\n for i=0 to romsize-1\n x=45h\n y=(i and 37h) xor 2Ch\n if (i and 001h)=001h then x=x xor 01h\n if (i and 002h)=002h then x=x xor 01h\n if (i and 004h)=004h then x=x xor 06h\n if (i and 008h)=008h then x=x xor 04h\n if (i and 010h)=010h then x=x xor 18h\n if (i and 020h)=020h then x=x xor 30h\n if (i and 040h)=040h then x=x xor 60h\n if (i and 080h)=080h then x=x xor 40h\n if (i and 100h)=100h then x=x xor 80h\n if (i and 006h)=006h then x=x xor 0ch\n if (i and 00Eh)=00Eh then x=x xor 08h\n if (i and 01Fh)>=016h then x=x-10h\n rom[i]=(rom[i] XOR x)+y\n next i\nBelow commands should work on all chips (for write: page size may vary, eg. 1 byte, 128 bytes, or 256 bytes). Some chips do have some extra commands (eg. an alternate older get id command, or sector erase commands, or config commands), but those extras aren't needed for basic erase/write operations.
[5555h]=AAh, [2AAAh]=55h, [5555h]=A0h, [addr..]=byte(s) ;write page\n [5555h]=AAh, [2AAAh]=55h, [5555h]=90h, id=[0000h..0001h] ;enter id mode\n [5555h]=AAh, [2AAAh]=55h, [5555h]=F0h ;exit id mode\n [5555h]=AAh, [2AAAh]=55h, [5555h]=80h ;erase chip, step 1\n [5555h]=AAh, [2AAAh]=55h, [5555h]=10h ;erase chip, step 2\nWaiting is required after chip erase and page write (after writing the last byte at page end), and on some chips it's also required after enter/exit id mode. Some chips indicate busy state via a toggle bit (bit6 getting inverted on each 2nd read), and/or by outputting a value different than the written data, and/or do require hardcoded delays (eg. AM29F040). Using the following 3-step wait mechanism should work with all chips:
Wait 10us (around 340 cpu cycles on PSX) ;-step 1, hardcoded delay\n Wait until [addr]=[addr] ;-step 2, check toggle bit\n Wait until [addr]=data ;-step 3, check data\nFirst of, one should detect the expansion board type, this can be done as so:
Enter Chip ID mode (at 1F000000h)\n Compare 400h bytes at 1F000000h vs 1F020000h\n If different --> assume Datel PAR1/PAR2 hardware\n If same --> assume Xplorer hardware (or Datel PAR3, whatever that is)\n Exit Chip ID mode (at 1F000000h)\n Enter Chip ID mode (at 1F000000h)\n Read the two ID bytes (at 1F00000xh)\n Exit Chip ID mode (at 1F000000h)\n If cart=xplorer AND 1st_chip=256K --> might have a 2nd 256K chip\n If cart=datel AND 1st_chip=128K --> might have a 2nd 128K chip\n Enter Chip ID (at 1F000000h) and Enter Chip ID (at 1F400000h) ;id1+id2\n Exit Chip ID (at 1F000000h) and Enter Chip ID (at 1F400000h) ;id2\n Exit Chip ID (at 1F400000h) and Enter Chip ID (at 1F000000h) ;id1\n Exit Chip ID (at 1F400000h) and Exit Chip ID (at 1F000000h) ;none\n If they are all same --> there is only one chip (mirrored to both areas)\n If different --> 1F400000h is either garbage, or a 2nd chip\n ChipID Kbyte Page Maker/Name ;notes\n 1Fh,D5h 128K 128 ATMEL AT29C010A ;xplorer/prototypes?\n 1Fh,35h 128K 128 ATMEL AT29LV010A ;-\n 1Fh,DAh 256K 256 ATMEL AT29C020 ;xplorer\n 1Fh,BAh 256K 256 ATMEL AT29BV020 ;xplorer\n 1Fh,A4h 512K 256 ATMEL AT29C040A ;xplorer\n 1Fh,C4h 512K 256 ATMEL AT29xV040A ;-\n BFh,07h 128K 128 SST SST29EE010 ;-\n BFh,08h 128K 128 SST SST29xE010 ;-\n BFh,22h 128K 128 SST SST29EE010A ;-\n BFh,23h 128K 128 SST SST29xE010A ;-\n BFh,10h 256K 128 SST SST29EE020 ;xplorer\n BFh,12h 256K 128 SST SST29xE020 ;xplorer\n BFh,24h 256K 128 SST SST29EE020A ;-\n BFh,25h 256K 128 SST SST2xEE020A ;-\n BFh,04h 512K 256 SST SST28SF040 ;said to be used in \"AR/GS Pro\"\n DAh,C1h 128K 128 WINBOND W29EE01x ;-\n DAh,45h 256K 128 WINBOND W29C020 ;-\n DAh,46h 512K 256 WINBOND W29C040 ;xplorer\n 01h,A4h 512K 1 AMD AM29F040 ;nocash psone bios (intact console)\n 20h,20h 128K 1 ST M29F010B ;nocash psone bios (broken console)\n 31h,B4h 128K ?? CATALYST CAT28F010 ;NEEDS VPP=12V !!! (\"PS-121 ZISAN\")\nController and Memory Card Overview Controller and Memory Card Signals Controller and Memory Card Multitap Adaptor
"},{"location":"controllersandmemorycards/#controllers","title":"Controllers","text":"Controllers - Communication Sequence Controllers - Standard Digital/Analog Controllers Controllers - Mouse Controllers - Racing Controllers Controllers - Lightguns Controllers - Configuration Commands Controllers - Vibration/Rumble Control Controllers - Analog Buttons (Dualshock2) Controllers - Dance Mats Controllers - Pop'n Controllers Controllers - Densha de Go! / Jet de Go! Controllers Controllers - Fishing Controllers Controllers - PS2 DVD Remote Controllers - I-Mode Adaptor (Mobile Internet) Controllers - Additional Inputs Controllers - Misc
"},{"location":"controllersandmemorycards/#memory-cards","title":"Memory Cards","text":"Memory Card Read/Write Commands Memory Card Data Format Memory Card Images Memory Card Notes
"},{"location":"controllersandmemorycards/#pocketstation-memory-card-with-built-in-lcd-screen-and-buttons","title":"Pocketstation (Memory Card with built-in LCD screen and buttons)","text":"Pocketstation
"},{"location":"controllersandmemorycards/#pinouts","title":"Pinouts","text":"Pinouts - Controller Ports and Memory-Card Ports
"},{"location":"controllersandmemorycards/#controller-and-memory-card-overview","title":"Controller and Memory Card Overview","text":"Controllers and memory cards connect to the console using a serial protocol and are accessed through SIO0 registers: Serial Interfaces (SIO) The protocol used is similar to standard SPI, with no start/stop bytes and no parity (even though SIO0 has support for it). Unlike typical SPI, only one byte is transferred at a time and a separate wire (/ACK) is used by the device to signal the PS1 that it is ready to exchange the next byte. For more details see: Controller and Memory Card Signals
"},{"location":"controllersandmemorycards/#device-addressing","title":"Device addressing","text":"Each controller port and its respective memory card slot are wired in parallel, and the /CSn signals select both the controller and the memory card when asserted. This selection is narrowed down through a simple addressing scheme, where the first byte sent by the console after asserting /CSn is the address of the device that shall reply. All devices must keep the DAT line idle before receiving this byte. Once the address is sent, the device that was addressed shall pull /ACK low to signal its presence and start exchanging bytes. The following addresses are known to be used:
Device Address Standard controller01h Yaroze Access Card 21h PS2 multitap (incompatible with PS1) 21h PS2 DVD remote receiver 61h Memory card 81h"},{"location":"controllersandmemorycards/#dsr-ack-controller-and-memory-card-byte-received-interrupt","title":"DSR (/ACK) Controller and Memory Card - Byte Received Interrupt","text":"Gets set after receiving a data byte - that only if an /ACK has been received from the peripheral (ie. there will be no IRQ if the peripheral fails to send an /ACK, or if there's no peripheral connected at all).
Actually, DSR means \"more-data-request\",\n accordingly, it does NOT get triggered after receiving the LAST byte.\nPin 8 on Controller Port. Routed directly to the Interrupt Controller (at 1F80107xh). There are no status/enable bits in the SIO0_registers (at 1F80104xh).
"},{"location":"controllersandmemorycards/#plugging-and-unplugging-cautions","title":"Plugging and Unplugging Cautions","text":"During plugging and unplugging, the Serial Data line may be dragged LOW for a moment; this may also affect other connected devices because the same Data line is shared for all controllers and memory cards (for example, connecting a joypad in slot 1 may corrupt memory card accesses in slot 2). Moreover, the Sony Mouse does power-up with /ACK=LOW, and stays stuck in that state until it is accessed at least once (by at least sending one 01h byte to its controller port); this will also affect other devices (as a workaround one should always access BOTH controller ports; even if a game uses only one controller, and, code that waits for /ACK=HIGH should use timeouts).
"},{"location":"controllersandmemorycards/#emulation-note","title":"Emulation Note","text":"After sending a byte, the Kernel waits 100 cycles or so, and does THEN acknowledge any old IRQ7, and does then wait for the new IRQ7. Due to that bizarre coding, emulators can't trigger IRQ7 immediately within 0 cycles after sending the byte.
"},{"location":"controllersandmemorycards/#bios-functions","title":"BIOS Functions","text":"Controllers can be probably accessed via InitPad and StartPad functions, BIOS Joypad Functions Memory cards can be accessed by the filesystem (with device names \"bu00:\" (slot1) and \"bu10:\" (slot2) or so). Before using that device names, it seems to be required to call InitCard, StartCard, and _bu_init (?).
"},{"location":"controllersandmemorycards/#synchronous-io","title":"Synchronous I/O","text":"The data is transferred in units of bytes, via separate input and output lines. So, when sending byte, the hardware does simultaneously receive a response byte. One exception is the address byte (which selects either the controller, or the memory card) until that byte has been sent, neither the controller nor memory card are selected (and so the first \"response\" byte should be ignored; probably containing more or less stable high-z levels). The other exception is, when you have send all command bytes, and still want to receive further data, then you'll need to send dummy command bytes (should be usually 00h) to receive the response bytes.
"},{"location":"controllersandmemorycards/#controller-and-memory-card-signals","title":"Controller and Memory Card Signals","text":""},{"location":"controllersandmemorycards/#overview","title":"Overview","text":" ____ _____\n /CS \\____________________________________________________________/\n ______ ____ ____ ____ ____ _________\n SCK |||||||| |||||||| |||||||| |||||||| ||||||||\n ____ _____\n MOSI '=[ Addr ]====[ Cmd ]====[ Tap ]====[Param ]====[Param ]==='\n\n MISO ---------------===[ IDlo ]====[ IDhi ]====[ Data ]====[ Data ]===------\n _______________ _________ _________ _________ _________________\n /ACK |_| |_| |_| |_|\n\n--- High impedance\n=== Any state (don't care)\n ____\n /CS \\__________________________________________________________________\n ______ _ _ _ _ _ _ _ __________________ _ _ _ _\n SCK |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|\n __________ ___\n MOSI 1 |_0___0___0___0___0___0___0____________________0_| 1 |_0___0_\n ____\n MISO -----------------------------------------------=======' 1 |_0___0___0_\n ______________________________________________ ____________________\n /ACK |___|\n\n--- High impedance\n=== Any state (don't care)\nNotes:
The Multitap is an external adaptor that allows to connect 4 controllers, and 4 memory cards to one controller port. When using two adaptors (one on each slot), up to 8 controllers and 8 memory cards can be used.
"},{"location":"controllersandmemorycards/#multitap-controller-access","title":"Multitap Controller Access","text":"Normally joypad reading is done by sending this bytes to the pad:
01 42 00 00 .. ;normal read\n 01 42 01 00 .. ;method 1: receive special ID and data from ALL four pads\n 0n 42 00 00 .. ;method 2: receive data from pad number \"n\" (1..4)\nBelow LONG response is activated by sending \"01h\" as third command byte; observe that sending that byte does NOT affect the current response. Instead, it does request that the NEXT command shall return special data, as so:
Halfword 0 --> Controller ID for MultiTap (5A80h=Multitap)\n Halfword 1..4 --> Player A (Controller ID, Buttons, Analog Inputs, if any)\n Halfword 5..8 --> Player B (Controller ID, Buttons, Analog Inputs, if any)\n Halfword 9..12 --> Player C (Controller ID, Buttons, Analog Inputs, if any)\n Halfword 13..16 --> Player D (Controller ID, Buttons, Analog Inputs, if any)\n Previous access had REQ=0 and returned Slot A data ---> returns Slot A data\n Previous access had REQ=0 and returned Slot A-D data -> returns Slot A data\n Previous access had REQ=1 and returned Slot A data ---> returns Slot A-D data\n Previous access had REQ=1 and returned Slot A-D data -> returns garbage\n Previous access had REQ=1 and returned garbage -------> returns Slot A-D data\nNormally memory card access is done by sending this bytes to the card:
80 xx .. .. ;normal access\n 8n xx .. .. ;access memory card in slot \"n\" (1..4)\n Bomberman / Bomberman Party Edition (requires Multitap on Port 2 instead of 1)\n Bomberman World\n Breakout: Off the Wall Fun\n Circuit Breakers\n Crash Team Racing\n FIFA series soccer games\n Frogger\n Gauntlet: Dark Legacy\n Hot Shots Golf 2 & 3\n Jigsaw Island: Japan Graffiti / Jigsaw Madness (requires Multitap on Port 2 instead of 1)\n NBA Live (any year) (up to 8 players with two multitaps)\n Need For Speed 3\n Need For Speed 5\n Poy Poy (4 players hitting each other with rocks and trees)\n Running Wild\n S.C.A.R.S. (requires Multitap on Port 2 instead of 1)\n Zen Nippon Pro Wrestling: Ouja no Tamashii (requires Multitap on Port 2 instead of 1)\n .------.\n SCPH-1070 | | SCPH-111\n (gray case) | | (white case)\n (for PSX) | D | (for PSone)\n | | .----------------.\n cable | | cable .' D C '.\n ''--.. | C | '''--..__| |\n \\| | | |\n .----------------' | '. A B .'\n | | '----------------'\n | |\n | A B /\n '---------------------'\nHalfword 0 is parsed (by the BIOS) as usually, ie. the LSB is moved to MSB, and LSB is replaced by status byte (so ID 5A80h becomes 8000h=Multitap/okay, or xxFFh=bad). Halfwords 1,5,9,13 are NOT parsed (neither by the BIOS nor by the Multitap hardware), however, some info in the internet is hinting that Sony's libraries might be parsing these IDs too (so for example 5A41h would become 4100h=DigitalPad/okay, or xxFFh=bad).
"},{"location":"controllersandmemorycards/#power-supply","title":"Power Supply","text":"The Multitap is powered by the PSX controller port. Unknown if there are any power supply restrictions (up to eight controllers and eight cards may scratch some limits, especially when doing things like activating rumble on all joypads). However, the Multitap hardware itself doesn't do much on supply restrictions (+3.5V is passed through something; maybe some fuse, loop, or 1 ohm resistor or so) (and +7.5V is passed without any restrictions).
"},{"location":"controllersandmemorycards/#ps2-multitap","title":"PS2 multitap","text":"Sony made a multitap adapter for the PS2, however it is not compatible with the PS1 as it plugs into both the controller and memory card ports (which are not wired in parallel on the PS2). The protocol is also different: rather than modifying packets it seems to act as a mostly-passive port multiplexer, accepting switching commands with address 61h. Unknown if the PS2 multitap is backwards compatible with the SCPH-1070 protocol.
"},{"location":"controllersandmemorycards/#see-also","title":"See also","text":"Pinouts - Component List and Chipset Pin-Outs for Multitap, SCPH-1070
"},{"location":"controllersandmemorycards/#controllers-communication-sequence","title":"Controllers - Communication Sequence","text":""},{"location":"controllersandmemorycards/#controller-communication-sequence","title":"Controller Communication Sequence","text":" Send Reply Comment\n 01h Hi-Z Controller address\n 42h idlo Receive ID bit0..7 (variable) and Send Read Command (ASCII \"B\")\n TAP idhi Receive ID bit8..15 (usually/always 5Ah)\n MOT swlo Receive Digital Switches bit0..7\n MOT swhi Receive Digital Switches bit8..15\n --- transfer stops here for digital pad (or analog pad in digital mode) ---\n 00h adc0 Receive Analog Input 0 (if any) (eg. analog joypad or mouse)\n 00h adc1 Receive Analog Input 1 (if any) (eg. analog joypad or mouse)\n --- transfer stops here for analog mouse ----------------------------------\n 00h adc2 Receive Analog Input 2 (if any) (eg. analog joypad)\n 00h adc3 Receive Analog Input 3 (if any) (eg. analog joypad)\n --- transfer stops here for analog pad (in analog mode) -------------------\n --- transfer stops here for nonstandard devices (steering/twist/paddle) ---\n 0-3 Number of following halfwords (01h..0Fh=1..15, or 00h=16 halfwords)\n 4-7 Controller Type (or currently selected Controller Mode)\n 8-15 Fixed (5Ah)\n xx00h=N/A (initial buffer value from InitPad BIOS function)\n 5A12h=Mouse (two button mouse)\n 5A23h=NegCon (steering twist/wheel/paddle)\n 5A31h=Konami Lightgun (IRQ10-type)\n 5A41h=Digital Pad (or analog pad/stick in digital mode; LED=Off)\n 5A53h=Analog Stick (or analog pad in \"flight mode\"; LED=Green)\n 5A63h=Namco Lightgun (Cinch-type)\n 5A73h=Analog Pad (in normal analog mode; LED=Red)\n 5A7xh=Dualshock2 (with variable number of inputs enabled)\n 5A79h=Dualshock2 (with all analog/digital inputs enabled)\n 5A80h=Multitap (multiplayer adaptor) (when activated)\n 5A96h=Keyboard (rare lightspan keyboard)\n 5AE3h=Jogcon (steering dial)\n 5AE8h=Keyboard/Sticks (rare homebrew keyboard/segasticks adaptor)\n 5AF3h=Config Mode (when in config mode; see rumble command 43h)\n FFFFh=High-Z (no controller connected, pins floating High-Z)\n ___ ___ ___ ___\n __/_L_\\__ Analog Pad __/_R_\\__ __/_L_\\__ Digital Pad __/_R_\\__\n / _ \\--------------/ \\ / _ \\--------------/ \\\n | _| |_ | | /\\ | | _| |_ | | /\\ |\n | |_ X _| |SEL STA| [] () | | |_ X _| | | [] () |\n | |_| ___ ANALOG ___ >< | | |_| | SEL STA | >< |\n |\\______ / L \\ LED / R \\ ______/| |\\_________/--------------\\_________/|\n | | Joy |--------| Joy | | | | | |\n | / \\___/ \\___/ \\ | | / \\ |\n \\____/ \\____/ \\____/ \\____/\n __Halfword 0 (Controller Info)_______________________________________________\n 0-15 Controller Info (5A41h=digital, 5A73h=analog/pad, 5A53h=analog/stick)\n __Halfword 1 (Digital Switches)______________________________________________\n 0 Select Button (0=Pressed, 1=Released)\n 1 L3/Joy-button (0=Pressed, 1=Released/None/Disabled) ;analog mode only\n 2 R3/Joy-button (0=Pressed, 1=Released/None/Disabled) ;analog mode only\n 3 Start Button (0=Pressed, 1=Released)\n 4 Joypad Up (0=Pressed, 1=Released)\n 5 Joypad Right (0=Pressed, 1=Released)\n 6 Joypad Down (0=Pressed, 1=Released)\n 7 Joypad Left (0=Pressed, 1=Released)\n 8 L2 Button (0=Pressed, 1=Released) (Lower-left shoulder)\n 9 R2 Button (0=Pressed, 1=Released) (Lower-right shoulder)\n 10 L1 Button (0=Pressed, 1=Released) (Upper-left shoulder)\n 11 R1 Button (0=Pressed, 1=Released) (Upper-right shoulder)\n 12 /\\ Button (0=Pressed, 1=Released) (Triangle, upper button)\n 13 () Button (0=Pressed, 1=Released) (Circle, right button)\n 14 >< Button (0=Pressed, 1=Released) (Cross, lower button)\n 15 [] Button (0=Pressed, 1=Released) (Square, left button)\n __Halfword 2 (Right joystick) (analog pad/stick in analog mode only)_________\n 0-7 adc0 RightJoyX (00h=Left, 80h=Center, FFh=Right)\n 8-15 adc1 RightJoyY (00h=Up, 80h=Center, FFh=Down)\n __Halfword 3 (Left joystick) (analog pad/stick in analog mode only)__________\n 0-7 adc2 LeftJoyX (00h=Left, 80h=Center, FFh=Right)\n 8-15 adc3 LeftJoyY (00h=Up, 80h=Center, FFh=Down)\n __Further Halfword(s) (Dualshock2 only, and only if enabled)_________________\n 0-7 .. Analog Button (if enabled) (00h=Released, FFh=Max Pressure)\n 8-15 .. Analog Button (if enabled) (00h=Released, FFh=Max Pressure)\n .. .. ..\nOn power-up, the controllers are in digital mode (with analog inputs disabled). Analog mode can be (de-)activated manually by pushing the Analog button. Alternately, analog mode can be (de-)activated by software via rumble configuration commands (though that's supported only on newer pads; those with two rumble motors). It is essential that emulators and any third-party hardware have a way of manually toggling analog mode, similar to original analog controllers, as certain games like Gran Turismo 1 will not attempt to enter analog mode on their own, even if they support analog controls and detect an analog controller. Since analog pads boot in digital mode and will return the same ID byte as digital controllers, the most common way of distinguishing between the 2 is to send a Dualshock-only command (Typically command 43h - enter/exit config mode) and seeing how the controller responds to it. The analog sticks are mechanically restricted to a \"circular field of motion\" (most joypads can reach \"min/max\" values only in \"straight\" horizontal or vertical directions, but not in \"diagonal\" directions).
"},{"location":"controllersandmemorycards/#analog-joypad-range","title":"Analog Joypad Range","text":" ...''''''''''...\n ____ .''________________''._____ ___ 00h\n | .'' ''. |\n |.' '.| ___ 10h\n .' '.\n :| |:\n : | | : ___ 60h\n .' | .''''''. | '.\n : | .' '. | :\n : | : : | : ___ 80h\n : | : : | :\n : | '. .' | :\n '. | '......' | .' ___ A0h\n : | | :\n :| |:\n '. .' ___ F0h\n |'. .'|\n |__'..______________________..'__| ___ FFh\n . '.. ..' .\n 00h '''..........''' FFh\n Big Circle --> Mechanically possible field of motion\n Square Area --> Digitally visible 8bit field of motion\n Small Circle --> Resting position when releasing the joystick\n SCPH-1150 Min=(00,00), Mid: (72..90,79..AC), Max=(FF,FF) at 25'C\n SCPH-1200 Min=(0E,0E), Mid: (6C..8A,75..79), Max=(ED,ED) at 16'C\n SCPH-110 Min=(11,11), Mid: (8A..9F,70..96), Max=(FD,FD) at 16'C\nBasically same as normal analog LED=Red mode, with following differences:
ID is 5A53h (identifying itself as analog stick) (rather than analog pad)\n Left/right joy-buttons disabled (as for real analog stick, bits are always 1)\n Some buttons are re-arranged: bit9=L1 bit10=[] bit11=/\\ bit12=R1 bit15=R2\nPinouts - Component List and Chipset Pin-Outs for Digital Joypad, SCPH-1080 Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-1150 Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-1200 Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-110
"},{"location":"controllersandmemorycards/#controllers-mouse","title":"Controllers - Mouse","text":""},{"location":"controllersandmemorycards/#sony-mouse-controller","title":"Sony Mouse Controller","text":" __Halfword 0 (Controller Info)________________\n 0-15 Controller Info (5A12h=Mouse)\n __Halfword 1 (Mouse Buttons)__________________\n 0-7 Not used (All bits always 1)\n 8-9 Unknown (Seems to be always 0) (maybe SNES-style sensitivity?)\n 10 Right Button (0=Pressed, 1=Released)\n 11 Left Button (0=Pressed, 1=Released)\n 12-15 Not used (All bits always 1)\n __Halfword 2 (Mouse Motion Sensors)___________\n 0-7 Horizontal Motion (-80h..+7Fh = Left..Right) (00h=No motion)\n 8-15 Vertical Motion (-80h..+7Fh = Up..Down) (00h=No motion)\nOn Power-on (or when newly connecting it), the Sony mouse does draw /ACK to LOW on power-on, and does then hold /ACK stuck in the LOW position. For reference: Normal controllers and memory cards set /ACK=LOW only for around 100 clk cycles, and only after having received a byte from the console. The /ACK pin is shared for both controllers and both memory cards, so the stuck /ACK is also \"blocking\" all other connected controllers/cards. To release the stuck /ACK signal: Send a command (at least one 01h byte) to both controller slots.
"},{"location":"controllersandmemorycards/#sony-mouse-compatible-games","title":"Sony Mouse Compatible Games","text":" 3D Lemmings\n Alien Resurrection\n Area 51\n Ark of Time\n Atari Anniversary Edition\n Atlantis: The Lost Tales\n Breakout: Off the Wall Fun\n Broken Sword: The Shadow of the Templars\n Broken Sword II: The Smoking Mirror\n Clock Tower: The First Fear\n Clock Tower II: The Struggle Within\n Command & Conquer: Red Alert\n Command & Conquer: Red Alert - Retaliation\n Constructor (Europe)\n Die Hard Trilogy\n Die Hard Trilogy 2: Viva Las Vegas\n Discworld\n Discworld II: Missing Presumed...!?\n Discworld Noir\n Dune 2000\n Final Doom\n Galaxian 3\n Ghoul Panic\n Klaymen Klaymen: Neverhood no Nazon (Japan)\n Lemmings and Oh No! More Lemmings\n Monopoly\n Music 2000\n Myst\n Neorude (Japan)\n Perfect Assassin\n Policenauts (Japan)\n Puchi Carat\n Quake II\n Railroad Tycoon II\n Rescue Shot\n Risk\n Riven: The Sequel to Myst\n RPG Maker\n Sentinel Returns\n SimCity 2000\n Syndicate Wars\n Tempest 2000 (Tempest X3)\n Theme Aquarium (Japan)\n Transport Tycoon\n Warhammer: Dark Omen\n Warzone 2100\n X-COM: Enemy Unknown\n X-COM: Terror from the Deep\n Z\nPCB \"TD-T41V/\\, MITSUMI\" Component Side:
1x 3pin 4.00MHz \"[M]4000A, 85 2\"\n 2x 2pin button (left/right)\n 1x 8pin connector (to cable with shield and 7 wires)\n 1x 3pin \"811, T994I\"\n 2x 3pin photo transistor (black) ;\\or so, no idea which one is\n 2x 2pin photo diode (transparent) ;/sender and which is sensor\n 1x 2pin electrolyt capacitor 16V, 10uF\n 1x 32pin \"(M), SC442116, FB G22K, JSAA815B\"\n 1x 14pin \"BA10339F, 817 L67\" (Quad Comparator)\n 2x 3pin \"LC\" (amplifier for photo diodes)\n 1x 3pin \"24-\" (looks like a dual-diode or so)\n plus many SMD resistors/capacitors\n PSX.Controller.Pin1 DAT ---- brown -- Mouse.Pin4\n PSX.Controller.Pin2 CMD ---- red -- Mouse.Pin3\n PSX.Controller.Pin3 +7.5V ---- N/A\n PSX.Controller.Pin4 GND ---- orange -- Mouse.Pin7 GND (G)\n PSX.Controller.Pin5 +3.5V ---- yellow -- Mouse.Pin1\n PSX.Controller.Pin6 /CSn ---- green -- Mouse.Pin5\n PSX.Controller.Pin7 SCK ---- blue -- Mouse.Pin2\n PSX.Controller.Pin8 /IRQ ---- N/A\n PSX.Controller.Pin9 /ACK ---- purple -- Mouse.Pin6\n PSX.Controller.Shield -------- shield -- Mouse.Pin8 GND (SHIELD)\nSome keyboard adaptors are also including a mouse adaptor feature (either by simulating normal Sony Mouse controller data, or via more uncommon ways like using the PSX expansion port). Controllers - Keyboards
"},{"location":"controllersandmemorycards/#rs232-mice","title":"RS232 Mice","text":"Below is some info on RS232 serial mice. That info isn't directly PSX related as the PSX normally doesn't support those mice. With some efforts, one can upgrade the PSX SIO port to support RS232 voltages, and with such a modded console one could use RS232 mice (in case one wants to do that). The nocash PSX bios can map a RS232 mouse to a spare controller slot (thereby simulating a Sony mouse), that trick may work with various PSX games.
"},{"location":"controllersandmemorycards/#standard-serial-mouse","title":"Standard Serial Mouse","text":"A serial mouse should be read at 1200 bauds, 7 data bits, no parity, 1 stop bit (7N1) with DTR and RTS on. For best compatibility, the mouse should output 2 stop bits (so it could be alternately also read as 7N2 or 8N1). When the mouse gets moved, or when a button gets pressed/released, the mouse sends 3 or 4 characters:
__First Character____________________\n 6 First Character Flag (1)\n 5 Left Button (1=Pressed)\n 4 Right Button (1=Pressed)\n 2-3 Upper 2bit of Vertical Motion\n 0-1 Upper 2bit of Horizontal Motion\n __Second Character___________________\n 6 Non-first Character Flag (0)\n 5-0 Lower 6bit of Horizontal Motion\n __Third Character____________________\n 6 Non-first Character Flag (0)\n 5-0 Lower 6bit of Vertical Motion\n __Fourth Character (if any)__________\n 6 Non-first Character Flag (0)\n 5 Middle Button (1=Pressed)\n 4 Unused ???\n 3-0 Wheel ???\n \"M\" = Two-Button Mouse (aka \"Microsoft\" mouse)\n \"3\" = Three-Button Mouse (aka \"Logitech\" mouse)\n \"Z\" = Mouse-Wheel\nAccessed at 1200 bauds, just like standard serial mouse, but with 8N1 instead 7N1, and with different data bytes.
__First Byte_________________________\n 7-3 First Byte Code (10000b)\n 2 Left? Button (0=Pressed)\n 1 Middle? Button (0=Pressed)\n 0 Right? Button (0=Pressed)\n __Second Byte________________________\n 7-0 Horizontal Motion (X1)\n __Third Byte_________________________\n 7-0 Vertical Motion (Y1)\n __Fourth Byte________________________\n 7-0 Horizontal Motion (X2)\n __Fifth Byte_________________________\n 7-0 Vertical Motion (Y2)\nThe Sony Mouse connects directly to the PSX controller port. Alternately serial RS232 mice can be connected to the SIO port (with voltage conversion adaptor) (most or all commercial games don't support SIO mice, nor does the original BIOS do so, however, the nocash BIOS maps SIO mice to unused controller slots, so they can be used even with commercial games; if the game uses BIOS functions to read controller data). Serial Mice (and maybe also the Sony mouse) do return raw mickeys, so effects like double speed threshold must (should) be implemented by software. Mice are rather rarely used by PSX games. The game \"Perfect Assassin\" includes ultra-crude mouse support, apparently without threshold, and without properly matching the cursor range to the screen resolution.
"},{"location":"controllersandmemorycards/#controllers-racing-controllers","title":"Controllers - Racing Controllers","text":""},{"location":"controllersandmemorycards/#negcon-racing-controller-twist-npc-101slph-00001sleh-0003","title":"neGcon Racing Controller (Twist) (NPC-101/SLPH-00001/SLEH-0003)","text":" __Halfword 0 (Controller Info)_______________________________________________\n 0-15 Controller Info (5A23h=neGcon)\n __Halfword 1 (Digital Switches)______________________________________________\n 0-2 Not used (always 1) (would be Select, L3, R3 on other pads)\n 3 Start Button (0=Pressed, 1=Released)\n 4 Joypad Up (0=Pressed, 1=Released)\n 5 Joypad Right (0=Pressed, 1=Released)\n 6 Joypad Down (0=Pressed, 1=Released)\n 7 Joypad Left (0=Pressed, 1=Released)\n 8-10 Not used (always 1) (would be L2, R2, L1 on other pads)\n 11 R Button (0=Pressed, 1=Released) (would be R1 on other pads)\n 12 B Button (0=Pressed, 1=Released) (would be /\\ on other pads)\n 13 A Button (0=Pressed, 1=Released) (would be () on other pads)\n 14-15 Not used (always 1) (would be ><, [] on other pads)\n __Halfword 2 (Right joystick) (analog pad/stick in analog mode only)_________\n 0-7 Steering Axis (00h=Left, 80h=Center, FFh=Right) (or vice-versa?)\n 8-15 Analog I button (00h=Out ... FFh=In) (Out=released, in=pressed?)\n __Halfword 3 (Left joystick) (analog pad/stick in analog mode only)__________\n 0-7 Analog II button (00h=Out ... FFh=In) (Out=released, in=pressed?)\n 8-15 Analog L button (00h=Out ... FFh=In) (Out=released, in=pressed?)\n _____ _ _ _____ ____\n |__L__\\_______/ || \\_______/__R__| / \\\n / _ namco || neGcon \\ / \\\n | _| |_ || B | | |\n | |_ X _| ....||.... II A | .... Rotation Axis ... | ... \\|/\n | |_| || I | |\n | START || | \\\n | ________ || ________ | \\__\\\n | / \\_||_/ \\ | /\n \\____/ \\____/\nThis is a cut-down variant of the neGcon, just a featureless small box. It does have the same ID value as neGcon (ID=5A23h), but, it excludes most digital, and all analog buttons.
_______\n | namco | Halfword 1 (digital buttons):\n | | Bit3 Button A (0=Pressed) (aka neGcon Start button)\n | A B | Bit13 Button B (0=Pressed) (aka neGcon A button aka () button)\n | | Other bits (not used, always 1)\n | _ | Halfword 2 and 3 (analog inputs):\n | (_) | Steering Axis (00h..FFh) (as for neGcon)\n |_______| Analog I,II,L button values (not used, always 00h)\nAnother cut-down variant of the neGcon (with ID=5A23h, too). But, this one seems to have only one button. Unlike Namco's volume controller it doesn't look featureless. It looks pretty much as shown in the ascii-arts image below. Seems to be supported by several irem titles. No idea what exactly it is used for, it's probably not a sewing machine controller, nor an electronic amboss.
____ ____ Halfword 1 (digital buttons):\n | / _ \\ Bit12 Button (0=Pressed) (aka neGcon B button aka /\\ button)\n |_ / (_) ) Other bits (not used, always 1)\n |_|___ /\\ Halfword 2 and 3 (analog inputs):\n ____| |_ Steering Axis (00h..FFh) (as for neGcon)\n |__________| Analog I,II,L button values (not used, always 00h)\nA neGcon compatible controller. The Twist-feature has been replaced by a steering wheel (can be turned by 270 degrees), and the analog I and II buttons by foot pedals. The analog L button has been replaced by a digital button (ie. in neGcon mode, the last byte of the controller data can be only either 00h or FFh). When not using the pedals, the I/II buttons on the wheel can be used (like L button, they aren't analog though).
__________________________\n / ____________________ \\ Stick\n / / \\ \\ ___ Brakes Gas\n / ( ) \\ ( ) II I\n / I \\ / A \\ \\ / ___ ___\n / /\\ II \\____________MODE__/ B /\\ \\ | | | | |\n | | \\ L _ R / | | | |!!!|_|!!!|___\n | | ) _| |_ MadCatz ( | |_|_ /|!!!| |!!!| /\n | | | |_ X _| | | | | | / |___| |___| /\n | | | |_| | | | / / =========== /\n | | \\ SEL STA / | | / / =========== /\n \\ \\__/ ______________________ \\__/ / / /_____________/\n \\____/ \\____/_/\n |___________________________|\nUnlike the neGon, the controller has Select, >\\< and [] buttons, and a second set of L/R buttons (at the rear-side of the wheel) (no idea if L1/R1 or L2/R2 are at front?). Aside from the neGcon mode, the controller can be also switched to Digital mode (see below for button chart).
"},{"location":"controllersandmemorycards/#madcatz-dual-force-racing-wheel","title":"MadCatz Dual Force Racing Wheel","text":"Same as above, but with a new Analog mode (additionally to Digital and neGcon modes). The new mode is for racing games that support only Analog Joypads (instead of neGcon). Additionally it supports vibration feedback.
"},{"location":"controllersandmemorycards/#madcatz-mc2-vibration-compatible-racing-wheel-and-pedals","title":"MadCatz MC2 Vibration compatible Racing Wheel and Pedals","text":"Same as above, but with a redesigned wheel with rearranged buttons, the digital pad moved to the center of the wheel, the L/R buttons at the rear-side of the wheel have been replaced by 2-way butterfly buttons (\"pull towards user\" acts as normal, the new \"push away from user\" function acts as L3/R3).
____________________\n / ________________ \\ ___ Stick Brakes Gas\n / / MC2 \\ \\ ( ) ___ ___\n / /__________________\\ \\ \\ / | | | |\n | A () _|_ I >< | | |!!!|_|!!!|___\n | B /\\ _ | _ II [] | | /|!!!| |!!!| /\n ___| L2 / \\ STA / \\ R2 |_|_ / |___| |___| /\n / \\ / | SEL | \\ / \\ / =========== /\n / ____\\ |___| |___| /____ \\ / =========== /\n /__/ \\____________________/ \\__\\ /_____________/\n Mode Buttons...................... Gas Brake Stick Wheel\n Digital >< [] () /\\ L1 R1 L2 R2 L1 R1 >< () L1/R1 lt/rt\n Analog >< [] () /\\ L1 R1 L2 R2 L3 R3 UP DN L1/R1 LT/RT\n Negcon I II A B L R L R L R I II up/dn Twist\n __Halfword 0 (Controller Info)___________________\n 0-15 Controller Info (5AE3h=Jogcon in Jogcon mode) (ie. not Digital mode)\n halfword1: buttons: same as digital pad\n halfword2:\n 0 unknown (uh, this isn't LSB of rotation?)\n 1-15 dial rotation (signed offset since last read?) (or absolute position?)\n halfword3:\n 0 flag: dial was turned left (0=no, 1=yes)\n 1 flag: dial was turned right (0=no, 1=yes)\n 2-15 unknown\n ___ ________ ___\n __/_L_\\__ / \\ __/_R_\\__\n / _ \\ / LED MODE \\-/ \\\n | _| |_ | SEL STA | /\\ |\n | |_ X _| | ________ | [] () |\n | |_| | / \\ | >< |\n |\\_________/\\/ \\/\\__ ______/|\n | | | JOGCON | | |\n | | | DIAL | | |\n | | \\ / | |\n | | \\________/ | |\n | | | |\n | | | |\n \\_____/ \\_____/\nThere are two different types of PSX lightguns (which are incompatible with each other).
"},{"location":"controllersandmemorycards/#namco-lightgun-guncon","title":"Namco Lightgun (GunCon)","text":"Namco's Cinch-based lightguns are extracting Vsync/Hsync timings from the video signal (via a cinch adaptor) (so they are working completely independed of software timings). Controllers - Lightguns - Namco (GunCon)
"},{"location":"controllersandmemorycards/#konami-lightgun-irq10","title":"Konami Lightgun (IRQ10)","text":"Konami's IRQ10-based lightguns are using the lightgun input on the controller slot (which requires IRQ10/timings being properly handled at software side). Controllers - Lightguns - Konami Justifier/Hyperblaster (IRQ10) The IRQ10-method is reportedly less accurate (although that may be just due to bugs at software side).
"},{"location":"controllersandmemorycards/#third-party-lightguns","title":"Third-Party Lightguns","text":"There are also a lot of unlicensed lightguns which are either IRQ10-based, or Cinch-based, or do support both. For example, the Blaze Scorpion supports both IRQ10 and Cinch, and it does additionally have a rumble/vibration function; though unknown how that rumble feature is accessed, and which games are supporting it).
"},{"location":"controllersandmemorycards/#lightgun-games","title":"Lightgun Games","text":"Controllers - Lightguns - PSX Lightgun Games
"},{"location":"controllersandmemorycards/#compatibilty-notes-irq10-vs-cinch-pal-vs-ntsc-calibration","title":"Compatibilty Notes (IRQ10 vs Cinch, PAL vs NTSC, Calibration)","text":"Some lightguns are reportedly working only with PAL or only with NTSC games (unknown which guns, and unknown what is causing problems; the IRQ10 method should be quite hardware independed, the GunCon variant, too, although theoretically, some GunCon guns might have problems to extract Vsync/Hsync from either PAL or NTSC composite signals). Lightguns from different manufacturers are reportedly returning slightly different values, so it would be recommended to include a calibration function in the game, using at least one calibration point (that would also resolve different X/Y offsets caused by modifying GP1 display control registers). Lightguns are needing to sense light from the cathode ray beam; as such they won't work on regions of the screen that contain too dark/black graphics.
"},{"location":"controllersandmemorycards/#controllers-lightguns-namco-guncon","title":"Controllers - Lightguns - Namco (GunCon)","text":""},{"location":"controllersandmemorycards/#guncon-cinch-based-lightguns-namco","title":"GunCon Cinch-based Lightguns (Namco)","text":" __Halfword 0 (Controller Info)___________________\n 0-15 Controller Info (5A63h=Namco Lightgun; GunCon/Cinch Type)\n __Halfword 1 (Buttons)___________________________\n 0-2 Not used (All bits always 1)\n 3 Button A (Left Side) (0=Pressed, 1=Released) ;aka Joypad Start\n 4-12 Not used (All bits always 1)\n 13 Trigger Button (0=Pressed, 1=Released) ;aka Joypad O-Button\n 14 Button B (Right Side) (0=Pressed, 1=Released) ;aka Joypad X-Button\n 15 Not used (All bits always 1)\n __Halfword 2 (X)_________________________________\n 0-15 8MHz clks since HSYNC (01h=Error, or 04Dh..1CDh)\n __Halfword 3 (Y)_________________________________\n 0-15 Scanlines since VSYNC (05h/0Ah=Error, PAL=20h..127h, NTSC=19h..F8h)\nCoordinates X=0001h, Y=0005h indicates \"unexpected light\":
ERROR: Sensed light during VSYNC (eg. from a Bulb or Sunlight).\n ERROR: no light sensed at all (not aimed at screen, or screen too dark).\n BUSY: no light sensed yet (when trying to read gun during rendering).\nBelow are some average minimum brightness values, the gun may be unable to return position data near/below that limits (especially coordinates close to left screen border are most fragile). The exact limits may vary from gun to gun, and will also depend on the TV Set's brightness setting.
666666h Minimum Gray\n 770000h Minimum Blue\n 007700h Minimum Green\n 000099h Minimum Red\nThe coordinates are updated in all frames (as opposed to some lightguns which do update them only when pulling the trigger). The absolute min/max coordinates may vary from TV set to TV set (some may show a few more pixels than others). The relation of the gun's Screen Coodinates to VRAM Coordinates does (obviously) depend on where the VRAM is located on the screen; ie. on the game's GP1(06h) and GP1(07h) settings. Vertical coordinates are counted in scanlines (ie. equal to pixels). Horizontal coordinates are counted in 8MHz units (which would equal a resolution of 385 pixels; which can be, for example, converted to 320 pixel resolution as X=X*320/385).
"},{"location":"controllersandmemorycards/#misinformation-from-bugged-homebrew-source-code","title":"Misinformation (from bugged homebrew source code)","text":" __Halfword 2 (X)_________________________________\n 0-7 X-Coordinate (actual: see X-Offset) ;\\with unspecified\n 8-15 X-Offset (00h: X=X-80, Nonzero: X=X-80+220) ;/dotclock?\n __Halfword 3 (Y)_________________________________\n 0-7 Y-Coordinate (actual: Y=Y-25) (but then, max is only 230, not 263 ?)\n 8-15 Pad ID (uh, what id?) (reportedly too dark/bright error flag?)\n _-_______________________--_\n -----> | namco \\\\\\\\ \\ Namco G-Con 45 (light gray) (cinch)\n sensor |............ .. .....\\\\\\\\...|_\n |_ : :.. _____ _\\\n | O :__../ )))| (\n \\__________/ |_\\____/| \\\n : : | |\n : : | | NPC-103\n A-Button (Left) Trigger | | SLPH-00034/SLEH-0007/SLUH-00035\n B-Button (Right) |______|\nPinouts - Component List and Chipset Pin-Outs for Namco Lightgun, NPC-103
"},{"location":"controllersandmemorycards/#controllers-lightguns-konami-justifierhyperblaster-irq10","title":"Controllers - Lightguns - Konami Justifier/Hyperblaster (IRQ10)","text":""},{"location":"controllersandmemorycards/#overall-irq10-based-lightgun-access","title":"Overall IRQ10-Based Lightgun Access","text":" Send 01h 42h 00h x0h 00h\n Reply HiZ 31h 5Ah buttons\nThe Controller Data simply consists of the ID and buttons states:
__Halfword 0 (Controller Info)___________________\n 0-15 Controller Info (5A31h=Konami Lightgun; Timer/IRQ10 type)\n __Halfword 1 (Buttons)\n 0-2 Not used (All bits always 1)\n 3 Start Button (Left Side) (0=Pressed, 1=Released) ;aka Joypad Start\n 4-13 Not used (All bits always 1)\n 14 Back Button (Rear End) (0=Pressed, 1=Released) ;aka Joypad X-Button\n 15 Trigger Button (0=Pressed, 1=Released) ;aka Joypad []-Button\n __ ______ _\n _|__\\_______________/ ___ \\ \\ Konami Justifier/Hyperblaster (light green)\n | _______________ __ / \\ \\ \\\n |__| _ _ _ _ |==| O| \\O\\ .... Back Button (Rear End)\n |__:_:_:_:_:__ |___\\__ / ( (\n |_| ) \\ : \\ \\\n Trigger ...... \\___/| :...|.|.... Start Button (Left Side)\n | | |\n | | | SLPH-00013/SLPH-00014/SLEH-0005/SLUH-00017\n / _|_|\n \\___--\nThe PSX does have a lightgun input (Pin 8 of the controller), but, Sony did apparently \"forget\" to latch the current cathode ray beam coordinates by hardware when sensing the lightgun signal (quite strange, since that'd be a simple, inexpensive, and very obvious feature for a gaming console). Instead, the lightgun signal triggers IRQ10, and the interrupt handler is intended to \"latch\" the coordinates by software (by reading Timer 0 and 1 values, which must configured to be synchronized with the GPU). That method requires IRQ handling to be properly implemented in software (basically, IRQs should not be disabled for longer periods, and DMA transfers should not block the bus for longer periods). In practice, most programmers probably don't realize how to do that, to the worst, Sony seems to have delivered a slightly bugged library (libgun) to developers. For details on Timers, see: Timers In some consoles, IRQ10 seems to be routed through a Secondary IRQ Controller, see: EXP2 DTL-H2000 I/O Ports
"},{"location":"controllersandmemorycards/#irq10-priority","title":"IRQ10 Priority","text":"For processing IRQ10 as soon as possible, it should be assigned higher priority than all other IRQs (ie. when using the SysEnqIntRP BIOS function, it should be the first/newest element in priority chain 0). The libgun stuff assigns an even higher priority by patching the BIOS exception handler, causing IRQ10 to be processed shortly before processing the priority chains (the resulting IRQ priority isn't actually higher as when using 1st element of chain 0; the main difference is that it skips some time consuming code which pushes registers R4..R30). For details on that patch, see: BIOS Patches Even if IRQ10 has highest priority, execution of (older) other IRQs may cause a new IRQ10 to be executed delayed (because IRQs are disabled during IRQ handling), to avoid that problem: Best don't enable any other IRQs except IRQ0 and IRQ10, or, if you need other IRQs, best have them enabled only during Vblank (there are no scanlines drawn during vblank, so IRQ10 should never trigger during that period). DMAs might also slow down IRQ execution, so best use them only during Vblank, too.
"},{"location":"controllersandmemorycards/#irq10-timer-reading","title":"IRQ10 Timer Reading","text":"To read the current timer values the IRQ10 handler would be required to be called \\<immediately> after receiving the IRQ10 signal, which is more or less impossible; if the main program is trying to read a mul/div/gte result while the mul/div/gte operation is still busy may stop the CPU for some dozens of clock cycles, and active DMA transfers or cache hits and misses in the IRQ handler may cause different timings, moreover, timings may become completely different if IRQs are disabled (eg. while another IRQ is processed). However, IRQ10 does also get triggered in the next some scanlines, so the first IRQ10 is used only as a notification that the CPU should watch out for further IRQ10's. Ie. the IRQ10 handler should disable all DMAs, acknowledge IRQ10, and then enter a waitloop that waits for the IRQ10 bit in I_STAT to become set again (or abort if a timeout occurs) and then read the timers, reportedly like so:
IF NTSC then X=(Timer0-140)*0.198166, Y=Timer1\n IF PAL then X=(Timer0-140)*0.196358, Y=Timer1\nBUG: The \"libgun\" library doesn't acknowledge the old IRQ10 \\<immediately> before waiting for a new IRQ10, so the timer values after sensing the new IRQ10 are somewhat random (especially for the first processed scanline) (the library allows to read further IRQ10's in further scanlines, which return more stable results). No idea how many times IRQ10 gets typically repeated? Sporting Clays allocates a buffer for up to 20 scanlines (which would cause pretty much of a slowdown since the CPU is just waiting during that period) (nethertheless, the game uses only the first timer values, ie. the bugged libgun-random values).
Unknown if/how two-player games (with 2 lightguns) are working with the IRQ10 method... if IRQ10 is generated ONLY after pressing the trigger button, then it may work, unless both players have Trigger pressed at the same time... and, maybe one can enable/disable the lightguns by whatever commmand being sent to the controller (presumably that \"x0h\" byte, see above), so that gun 1 generates IRQ10 only in each second frame, and gun 2 only in each other frame...?
"},{"location":"controllersandmemorycards/#controllers-lightguns-psx-lightgun-games","title":"Controllers - Lightguns - PSX Lightgun Games","text":""},{"location":"controllersandmemorycards/#psx-lightgun-games","title":"PSX Lightgun Games","text":"Some games are working only with IRQ10 or only with Cinch, some games support both methods:
Area 51 (Mesa Logic/Midway) (IRQ10)\n Crypt Killer (Konami) (IRQ10)\n Die Hard Trilogy 1: (Probe Entertainment) (IRQ10)\n Die Hard Trilogy 2: Viva Las Vegas (n-Space) (IRQ10/Cinch)\n Elemental Gearbolt (Working Designs) (IRQ10/Cinch)\n Extreme Ghostbusters: Ultimate Invasion (LSP) (Cinch)\n Galaxian 3 (Cinch)\n Ghoul Panic (Namco) (Cinch)\n Gunfighter: The Legend of Jesse James (Rebellion) (Cinch)\n Judge Dredd (Gremlin) (Cinch)\n Lethal Enforcers 1-2 (Konami) (IRQ10)\n Maximum Force (Midway) (IRQ10/Cinch)\n Mighty Hits Special (Altron) (EU/JPN) (Cinch)\n Moorhuhn series (Phenomedia) (Cinch)\n Point Blank 1-3 (Namco) (Cinch)\n Project Horned Owl (Sony) (IRQ10)\n Rescue Shot (Namco) (Cinch)\n Resident Evil: Gun Survivor (Capcom) (JPN/PAL versions) (Cinch)\n Silent Hill (IRQ10) (\"used for an easter egg\")\n Simple 1500 Series Vol.024 - The Gun Shooting (unknown type)\n Simple 1500 Series Vol.063 - The Gun Shooting 2 (unknown type)\n Snatcher (IRQ10)\n Sporting Clays (Charles Doty) (homebrew with buggy source code) (IRQ10/Cinch)\n Star Wars Rebel Assault II (IRQ10)\n Time Crisis, and Time Crisis 2: Project Titan (Namco) (Cinch)\nSome controllers can be switched from Normal Mode to Config Mode. The Config Mode was invented for activating the 2nd rumble motor in SCPH-1200 analog joypads. Additionally, the Config commands can switch between analog/digital inputs (without needing to manually press the Analog button), activate more analog inputs (on Dualshock2), and read some type/status bytes.
"},{"location":"controllersandmemorycards/#normal-mode","title":"Normal Mode","text":" 42h \"B\" Read Buttons (and analog inputs when in analog mode)\n 43h \"C\" Enter/Exit Configuration Mode (stay normal, or enter)\n 40h \"@\" Unused, or Dualshock2: Get/Set ButtonAttr?\n 41h \"A\" Unused, or Dualshock2: Get Reply Capabilities\n 42h \"B\" Read Buttons AND analog inputs (even when in digital mode)\n 43h \"C\" Enter/Exit Configuration Mode (stay config, or exit)\n 44h \"D\" Set LED State (analog mode on/off)\n 45h \"E\" Get LED State (and Type/constants)\n 46h \"F\" Get Variable Response A (depending on incoming bit)\n 47h \"G\" Get whatever values (response HiZ F3h 5Ah 00h 00h 02h 00h 01h 00h)\n 48h \"H\" Unknown (response HiZ F3h 5Ah 00h 00h 00h 00h 01h 00h)\n 49h \"I\" Unused\n 4Ah \"J\" Unused\n 4Bh \"K\" Unused\n 4Ch \"L\" Get Variable Response B (depending on incoming bit)\n 4Dh \"M\" Get/Set RumbleProtocol\n 4Eh \"N\" Unused\n 4Fh \"O\" Unused, or Dualshock2: Set ReplyProtocol\n Send 01h 42h 00h xx yy (00h 00h 00h 00h) (...)\n Reply HiZ id 5Ah buttons ( analog-inputs ) (dualshock2 buttons...)\n yy.bit0-7 ---> Left/Large Motor M1 (analog slow/fast) (00h=stop, FFh=fastest)\n xx.bit0 ---> Right/small Motor M2 (digital on/off) (0=off, 1=on)\n Send 01h 43h 00h xx 00h (zero padded...) (...)\n Reply HiZ id 5Ah buttons (analog inputs...) (dualshock2 buttons...)\n xx=00h Stay in Normal mode\n xx=01h Enter Configuration mode\n Send 01h 42h 00h M2 M1 00h 00h 00h 00h\n Reply HiZ F3h 5Ah buttons analog-inputs\n Send 01h 43h 00h xx 00h 00h 00h 00h 00h\n Reply HiZ F3h 5Ah 00h 00h 00h 00h 00h 00h\n xx=00h Enter Normal mode (Exit Configuration mode)\n xx=01h Stay in Configuration mode\n Send 01h 44h 00h Led Key 00h 00h 00h 00h\n Reply HiZ F3h 5Ah 00h 00h Err 00h 00h 00h\n When Led=00h --> Digital mode, with LED=Off\n When Led=01h --> Analog mode, with LED=On/red\n When Led=02h..FFh --> Ignored (and, in case of dualshock2: set Err=FFh)\n When Key=00h..02h --> Unlock (allow user to push Analog button)\n When Key=03h --> Lock (stay in current mode, ignore Analog button)\n When Key=04h..FFh --> Acts same as (Key AND 03h)\n Send 01h 45h 00h 00h 00h 00h 00h 00h 00h\n Reply HiZ F3h 5Ah Typ 02h Led 02h 01h 00h\n Led: Current LED State (00h=Off, 01h=On/red)\n Typ: Controller Type (01h=PSX/Analog Pad, 03h=PS2/Dualshock2)\n Send 01h 46h 00h ii 00h 00h 00h 00h 00h\n Reply Hiz F3h 5Ah 00h 00h cc dd ee ff\n Send 01h 47h 00h 00h 00h 00h 00h 00h 00h\n Reply HiZ F3h 5Ah 00h 00h 02h 00h 01h 00h\n Send 01h 4Ch 00h ii 00h 00h 00h 00h 00h\n Reply Hiz F3h 5Ah 00h 00h 00h dd 00h 00h\n Send 01h 48h 00h ii 00h 00h 00h 00h 00h\n Reply HiZ F3h 5Ah 00h 00h 00h 00h ee 00h\nControllers - Vibration/Rumble Control
"},{"location":"controllersandmemorycards/#config-mode-command-40h-dualshock2-getset-buttonattr","title":"Config Mode - Command 40h \"@\" Dualshock2: Get/Set ButtonAttr?","text":""},{"location":"controllersandmemorycards/#config-mode-command-41h-a-dualshock2-get-reply-capabilities","title":"Config Mode - Command 41h \"A\" Dualshock2: Get Reply Capabilities","text":""},{"location":"controllersandmemorycards/#config-mode-command-4fh-o-dualshock2-set-replyprotocol","title":"Config Mode - Command 4Fh \"O\" Dualshock2: Set ReplyProtocol","text":"Controllers - Analog Buttons (Dualshock2)
"},{"location":"controllersandmemorycards/#config-mode-command-49h-i-unused","title":"Config Mode - Command 49h \"I\" - Unused","text":""},{"location":"controllersandmemorycards/#config-mode-command-4ah-j-unused","title":"Config Mode - Command 4Ah \"J\" - Unused","text":""},{"location":"controllersandmemorycards/#config-mode-command-4bh-k-unused","title":"Config Mode - Command 4Bh \"K\" - Unused","text":""},{"location":"controllersandmemorycards/#config-mode-command-4eh-n-unused","title":"Config Mode - Command 4Eh \"N\" - Unused","text":""},{"location":"controllersandmemorycards/#config-mode-command-40h-unused-except-used-by-dualshock2","title":"Config Mode - Command 40h \"@\" - Unused (except, used by Dualshock2)","text":""},{"location":"controllersandmemorycards/#config-mode-command-41h-a-unused-except-used-by-dualshock2","title":"Config Mode - Command 41h \"A\" - Unused (except, used by Dualshock2)","text":""},{"location":"controllersandmemorycards/#config-mode-command-4fh-o-unused-except-used-by-dualshock2","title":"Config Mode - Command 4Fh \"O\" - Unused (except, used by Dualshock2)","text":" Send 01h 4xh 00h 00h 00h 00h 00h 00h 00h\n Reply HiZ F3h 5Ah 00h 00h 00h 00h 00h 00h\nSomething called \"Guitar Hero controller\" does reportedly also support Config commands. Unknown if that thing does have the same inputs & rumble motors as normal analog PSX joypads, and if it does return special type values.
"},{"location":"controllersandmemorycards/#controllers-vibrationrumble-control","title":"Controllers - Vibration/Rumble Control","text":"Rumble (aka \"Vibration Function\") is basically controlled by two previously unused bytes of the standard controller Read command. There are two methods to control the rumble motors, the old method is very simple (but supports only one motor), the new method envolves a bunch of new configuration commands (and supports two motors).
SCPH-1150 DualAnalog Pad with 1 motor ;-old rumble method\n SCPH-1200 DualAnalog Pad with 2 motors, PSX-design ;\\new rumble method\n SCPH-110 DualAnalog Pad with 2 motors, PSone-design ;/\n SCPH-10010 DualAnalog Pad with 2 motors, PS2/Dualshock2 ;-plus analog buttons\n Blaze Scorpion Lightgun with rumble ;\\unknow how to control rumble\n Fishing controllers with rumble ;/\n SCPH-1180 Analog Pad without rumble ;\\unknow if there're config commands\n SCPH-1110 Analog Stick without rumble ;/for analog mode (probably not)\nThe SCPH-1150 doesn't support any special config commands, instead, rumble is solely done via the normal joypad read command:
Send 01h 42h 00h xx yy (00h 00h 00h 00h)\n Reply HiZ id 5Ah buttons ( analog-inputs )\n xx --> must be 40h..7Fh (ie. bit7=0, bit6=1) ;\\switches motor on\n yy --> must be 01h,03h,...,FDh,FFh (ie. bit0=1) ;/\nFor using the new rumble method, one must unlock the new rumble mode, for that purpose Sony has invented a \"slightly\" overcomplicated protocol with not less than 16 new commands (the rumble relevant commands are 43h and 4Dh, also, command 44h may be useful for activating analog inputs by software, and, once when rumble is unlocked, command 42h is used to control the rumble motors). Anyways, here's the full command set... Controllers - Configuration Commands And, the rumble-specific config command is described below...
"},{"location":"controllersandmemorycards/#config-mode-command-4dh-m-getset-rumbleprotocol_1","title":"Config Mode - Command 4Dh \"M\" - Get/Set RumbleProtocol","text":" Send 01h 4Dh 00h aa bb cc dd ee ff ;<-- set NEW aa..ff values\n Reply Hiz F3h 5Ah aa bb cc dd ee ff ;<-- returns OLD aa..ff values\n 00h = Map Right/small Motor (Motor M2) to bit0 of this byte\n 01h = Map Left/Large Motor (Motor M1) to bit0-7 of this byte\n 02h..FEh = Unknown (can be mapped, maybe for extra motors/outputs)\n FFh = Map nothing to this byte\n Send 01h 4Dh 00h 00h 01h FFh FFh FFh FFh ;enable new method (two motors)\n Send 01h 4Dh 00h FFh FFh FFh FFh FFh FFh ;disable motor control\nDualshock2 does reportedly have \"two more levels of vibration\", unknown what that means and if it's used by any PSX or PS2 games... it might refer to the small motor which usually has only 2 levels (on/off) and might have 4 levels (fast/med/slow/off) on dualshock2... but, if so, it's unknown how to control/unlock that feature. Also, the PSone controller (SCPH-110) appear to have been released shortly after Dualshock2, unknown if that means that it might have that feature, too.
"},{"location":"controllersandmemorycards/#note_1","title":"Note","text":"Rumble is a potentially annoying feature, so games that do support rumble should also include an option to disable it.
"},{"location":"controllersandmemorycards/#controllers-analog-buttons-dualshock2","title":"Controllers - Analog Buttons (Dualshock2)","text":"Dualshock2 has three new commands (40h,41h,4Fh) for configuring analog buttons. Additionally, Command 45h does return a different type byte for Dualshock2. Dualshock2 is a PS2 controller. However, it can be also used with PSX games (either by connecting the controller to a PSX console, or by playing a PSX game on a PS2 console). The analog button feature is reportedly rarely used by PS2 games (and there aren't any PSX games known to use it).
"},{"location":"controllersandmemorycards/#config-mode-command-40h-dualshock2-getset-buttonattr_1","title":"Config Mode - Command 40h \"@\" Dualshock2: Get/Set ButtonAttr?","text":" Send 01h 40h 00h Idx Val 00h 00h 00h 00h ;<-- Set NEW Val, array[Idx]=Val\n Reply HiZ F3h 5Ah 00h 00h Val 00h 00h 00h ;<-- Old Val (or FFh when Idx>0Bh)\n Digital button sensitivity, or Analog button sensitivity, or\n Analog button bit-depth/conversion speed, or something else?\n Send 01h 41h 00h 00h 00h 00h 00h 00h 00h\n Reply HiZ F3h 5Ah FFh FFh 03h 00h 00h 00h\n Send 01h 41h 00h aa bb cc dd ee ff\n Reply HiZ F3h 5Ah 00h 00h 00h 00h 00h 00h\n - HighZ (always transferred) 1st byte\n - ID/Mode/Len (always transferred) 2nd byte\n - 5Ah (always transferred) 3rd byte\n 0 LSB of digital buttons (0=No, 1=Yes) 4th byte\n 1 MSB of digital buttons (0=No, 1=Yes) 5th byte\n 2 RightJoyX (0=No, 1=Yes) 6th byte\n 3 RightJoyY (0=No, 1=Yes) 7th byte\n 4 LeftJoyX (0=No, 1=Yes) 8th byte\n 5 LeftJoyY (0=No, 1=Yes) 9th byte\n 6 DPAD Right (0=No, 1=Yes) button 00h 10th byte\n 7 DPAD Left (0=No, 1=Yes) button 01h 11th byte\n 8 DPAD Uup (0=No, 1=Yes) button 02h 12th byte\n 9 DPAD Down (0=No, 1=Yes) button 03h 13th byte\n 10 Button /\\ (0=No, 1=Yes) button 04h 14th byte\n 11 Button () (0=No, 1=Yes) button 05h 15th byte\n 12 Button >< (0=No, 1=Yes) button 06h 16th byte\n 13 Button [] (0=No, 1=Yes) button 07h 17th byte\n 14 Button L1 (0=No, 1=Yes) button 08h 18th byte\n 15 Button R1 (0=No, 1=Yes) button 09h 19th byte\n 16 Button L2 (0=No, 1=Yes) button 0Ah 20th byte\n 17 Button R2 (0=No, 1=Yes) button 0Bh 21st byte\n 18-39 Must be 0 (otherwise command is ignored)\n 40-47 Unknown (no effect?)\n Send 01h 41h 00h 03h 00h 00h 00h 00h 00h Digital buttons\n Send 01h 41h 00h 3Fh 00h 00h 00h 00h 00h Digital buttons + analog sticks\n Send 01h 41h 00h FFh FFh 03h 00h 00h 00h Enable all 18 input bytes\nNote: Some Dualshock2 Config Mode commands do occassionally send 00h, 5Ah, or FFh as last (9th) reply byte (unknown if that is some error/status thing, or garbage).
"},{"location":"controllersandmemorycards/#analog-button-sensitivity","title":"Analog Button Sensitivity","text":"The pressure sensors are rather imprecise and results may vary on various factors, including the pressure angle.
00h Button released\n 01h..2Fh Normal (soft) pressure\n 30h..FEh Medium pressure\n FFh Hard pressure\nDigital inputs are converting the analog inputs as so:
Analog=00h --> not pressed\n Analog=01h..FFh --> pressed (no matter if soft, medium, or hard pressure)\n[https://gist.github.com/scanlime/5042071] - tech (=mentions unknown details) [https://store.curiousinventor.com/guides/PS2/] - guide (=omits unknown stuff)
"},{"location":"controllersandmemorycards/#controllers-dance-mats","title":"Controllers - Dance Mats","text":"PSX Dance Mats are essentially normal joypads with uncommonly arranged buttons, the huge mats are meant to be put on the floor, so the user could step on them.
"},{"location":"controllersandmemorycards/#dance-mat-vs-joypad-compatibility","title":"Dance Mat vs Joypad Compatibility","text":"There are some differences to normal joypads: First of, the L1/L2/R1/R2 shoulder buttons are missing in most variants. And, the mats are allowing to push Left+Right and Up+Down at once, combinations that aren't mechanically possible on normal joypads (some dancing games do actually require those combinations, whilst some joypad games may get confused on them).
"},{"location":"controllersandmemorycards/#dance-mat-unknown-things","title":"Dance Mat Unknown Things","text":"Unknown if the mat was sold in japan, and if so, with which SLPH/SCPH number. Unknown if the mat's middle field is also having a button assigned. Unknown if the mat is having a special controller ID, or if there are other ways to detect mats (the mats are said to be compatible with skateboard games, so the mats are probably identifying themselves as normal digital joypad; assuming that those skateboard games haven't been specifically designed for mats).
"},{"location":"controllersandmemorycards/#dance-mat-games","title":"Dance Mat Games","text":" D.D.R. Dance Dance Revolution 2nd Remix\n (and maybe whatever further games)\nThere is the US version (DDR Dance Pad, SLUH-00071), and a slightly different European version (Official Dance Mat, SLEH-00023: shiny latex style with perverted colors, and Start/Select arranged differently). The japanese version (RU017) resembles the US version, but without Triangle/Square symbols drawn in lower left/right edges. And there is a handheld version (with additional L1/L2/R2/R1 buttons; maybe unlicensed; produced as MINI DDR, and also as Venom Mini Dance Pad).
US Version (white/black/red/blue) Handheld Version (blue/gray)\n __________.---------.___________ _____/ MINI \\_____\n | \\ / | | D.D.R. |\n | SELECT '-------' START | |L1 L2 SEL STA R2 R1|\n |------------.------.------------| | ___ ___ ___ |\n | .''''. / \\ .''''. | || X | | ^ | | O ||\n | | \\/ | | /\\ | | .''. | | ||___| |___| |___||\n | | /\\ | | /..\\ | | '..' | | | ___ .---. ___ |\n | '....' '. || .' '....' | || < | |Stay | | > ||\n | .-------. .''''''''. .-------. | ||___| |Cool!| |___||\n |/ /| .' '. |\\ \\| | ___ '___' ___ |\n | / |-- | | --| \\ | || []| | v | | /\\||\n | \\ |-- | Stay Cool! | --| / | ||___| |___| |___||\n |\\ \\| '. .' |/ /| |___________________|\n | '-------' '........' '-------' |\n | .''''. .' || '. .''''. | Gothic Dance Mat (black/silver)\n | | /\\ | | \\''/ | | |''| | | _.----------._\n | | /__\\ | | \\/ | | |..| | | | \\ SEL STA / | This one\n | '....' \\ / '....' | | '--------' | wasn't ever\n '------------'------'------------' | .----------. | produced,\n | | .''''. | | as cool as\n European Version (pink/blue/yellow) | | | /\\ | | | it could have\n __________.---------.___________ | | | /..\\ | | | been, the lame\n | \\ SEL STA / | | | '.||.' | | marketing\n | '-------' | | +----------+ | people didn't\n |----------.----------.----------| | | .''''. | | even think\n | .''''. | .''''. | .''''. | | | | /\\ | | | about it.\n | | \\/ | | | /\\ | | | .''. | | | | | /..\\ | | |\n | | /\\ | | | /..\\ | | | '..' | | | | '.||.' | |\n | '....' | '.||.' | '....' | | +----------+ |\n |----------+-.. ..-+----------| | | .'||'. | |\n | .'/|'. / '''' \\ .'|\\'. | | | | \\''/ | | |\n | | / |--|/ \\|--| \\ | | | | | \\/ | | |\n | | \\ |--|\\ /|--| / | | | | '....' | |\n | '.\\|.' \\ .... / '.|/.' | | +----------+ |\n |----------+-'' ''-+----------| | | .'||'. | |\n | .''''. | .'||'. | .''''. | | | | \\''/ | | |\n | | /\\ | | | \\''/ | | | |''| | | | | | \\/ | | |\n | | /__\\ | | | \\/ | | | |..| | | | | '....' | |\n | '....' | '....' | '....' | | '----------' '\n '----------|----------|----------' '--------------'\nDespite of the \"Stay Cool!\" slogan, the mat wasn't very cool - not at all! It offered only two steps back-and-forth, and also allowed to do extremly uncool side-steps. Not to mention that it would melt when dropping a burning cigarette on it. Stay Away!
"},{"location":"controllersandmemorycards/#controllers-popn-controllers","title":"Controllers - Pop'n Controllers","text":"Controllers used for Konami's Pop'n Music series. At least a few different versions of the controller (Pop'n Controller, Pop'n Controller 2, larger arcade-size version, possibly others and in different color variations) have been released for the PS1 and PS2. Unknown if the controllers released in the PS2 era have any additional commands not present in the original Pop'n Controller, but they are supposedly fully compatible with PS1 Pop'n Music games.
Pop'n Controllers report as digital controllers (ID byte 41h), but the left, right, and down d-pad controls are not connected to any physical buttons and are always reported as pressed (in the first transferred button byte, bits 5-7 are always 0). Pop'n Music games check these bits to determine if a Pop'n Controller is connected and will change the in-game controls accordingly if so.
"},{"location":"controllersandmemorycards/#controllers-densha-de-go-jet-de-go-controllers","title":"Controllers - Densha de Go! / Jet de Go! Controllers","text":"Controllers used for Taito's Densha de Go! and Jet de Go! series. Unknown what method is being used by Densha de Go! and Jet de Go! games for detecting these controllers.
The fishing rods are (next to lightguns) some of the more openly martial playstation controllers - using the credo that \"as long as you aren't using dynamite: it's okay to kill them cause they don't have any feelings.\"
"},{"location":"controllersandmemorycards/#psx-fishing-controller-games","title":"PSX Fishing Controller Games","text":" Action Bass (Syscom Entertainment) (1999) (SLPH-00100)\n Bass Landing (ASCII/agetec) (1999) (SLPH-00100, SLUH-00063)\n Bass Rise, Fishing Freaks (Bandai) (1999) (BANC-0001)\n Bass Rise Plus, Fishing Freaks (Bandai) (2000) (BANC-0001, SLPH-00100)\n Breath of Fire IV (Capcom) (SLUH-00063)\n Championship Bass (EA Sports) (2000) (SLUH-00063)\n Fish On! Bass (Pony Canyon) (1999) (BANC-0001, SLPH-00100)\n Fisherman's Bait 2/Exiting Bass2 - Big Ol'Bass(Konami)(SLPH-00100,SLUH-00063)\n Fishing Club: (series with 3 titles) (have \"headset-logo\" on back?)\n Lake Masters II (1999) (Dazz/Nexus) (SLPH-00100)\n Lake Masters Pro (1999) (Dazz/Nexus) (BANC-0001, SLPH-00100)\n Let's Go Bassfishing!: Bass Tsuri ni Ikou! (Banpresto) (1999) (SLPH-00100)\n Matsukata Hiroki no World Fishing (BPS The Choice) (1999) (SLPH-00100)\n Murakoshi Seikai-Bakuchou Nihon Rettou (Victor) (SLPH-00100)\n Murakoshi Masami-Bakuchou Nippon Rettou:TsuriConEdition (1999) (SLPH-00100)\n Pakuchikou Seabass Fishing (JP, 03/25/99) (Victor) (SLPH-00100)\n Perfect Fishing: Bass Fishing (2000) (Seta) (yellow/green logo)\n Perfect Fishing: Rock Fishing (2000) (Seta) (yellow/green logo)\n Oyaji no Jikan: Nechan, Tsuri Iku De! (2000) (Visit) (BANC-0001, SLPH-00100)\n Reel Fishing II / Fish Eyes II (2000)(Natsume/Victor)(SLPH-00100, SLUH-00063)\n Simple 1500 Series Vol. 29: The Tsuri (2000) (yellow/green logo)\n Suizokukan Project: Fish Hunter e no Michi (1999)(Teichiku)(SLPH-00100)\n Super Bass Fishing (1999) (King) (BANC-0001, SLPH-00100, yellow/green logo)\n Super Black Bass X2 (2000) (Starfish) (SLPH-00100)\n Tsuwadou Keiryuu Mizuumihen (Best Edition)(2000) (ASCII PS1+PS2 controllers?)\n Tsuwadou Seabass Fishing (PlayStation the Best) (1999) (Oz Club) (SLPH-00100)\n Uki Uki Tsuri Tengoku Nagami/Uokami Densetsu Oe (2000) (Teichiku)(SLPH-00100)\n Umi no Nushi Tsuri-Takarajima ni Mukatte (1999)(Victor)(BANC-0001,SLPH-00100)\n Winning Lure (Hori) (2000) (for Hori HPS-97 controller) AKA HPS-98 ?\nUS Fishing games should have a \"SLUH-00063\" logo. European Fishing games don't have any fishing logos; apparently fishing controllers haven't been officially released/supported in Europe. Japanese Fishing games can have a bunch of logos: Usually BANC-0001 or SLPH-00100 (or both). Moreover, some japanese games have a yellow/green fishing logo with japanese text (found on Perfect Fishing: Bass Fishing, Perfect Fishing: Rock Fishing, Simple 1500 Series Vol. 29: The Tsuri, Super Bass Fishing) (unknown if that logo refer to other special hardware, or if it means the \"normal\" BANC-0001 or SLPH-00100 controllers. And Moreover, some japanese games have some sort of \"headset\" logos with japanese text, these seem to have same meaning as SLPH-00100; as indicated by photos on CD cover of Tsuwadou Keiryuu Mizuumihen (Best Edition) (2000); that CD cover also has a \"headset 2\" logo, which seems to mean a newer PS2 variant of the SLPH-00100.
"},{"location":"controllersandmemorycards/#psx-fishing-controllers","title":"PSX Fishing Controllers","text":" ASCII Tsuricon SLPH-00100 (also marked with a second serial, ASC-0514TR, on the packaging box)\n ASCII Tsuricon 2 ASC-0521TR2 (has a mode switch with 3 settings. \"1\" is original Tsuricon mode, \"2\" is Tsuricon 2 mode. Unknown what the unnumbered mode does)\n Sammy Tsuricon 2 SMY-0506FS (looks to be identical to the ASCII Tsuricon 2)\n Sammy Tsuricon 2+ SMY-0511FS (unknown what the differences between this and the Tsuricon 2 are)\n Agetec Bass Landing Fishing Controller SLUH-00063 (US version of ASCII's SLPH-00100 controller)\n Bandai Fishing Controller BANC-0001 (dark gray/blue) (has less buttons than ASCII/agetec)\n Interact Fission (light gray/blue)(similar to ASCII/agetec, 2 extra buttons?)\n Naki (transparent blue) (looks like a clone of the ASCII/agetec controllers)\n Hori HPS-97/HPS-98 (black/gray) (a fishing rod attached to a plastic fish)\nUnknown how to detect fishing controllers. Unknown how to read buttons, joystick, crank, motion sensors. Unknown how to control rumble/vibration. Unknown if/how Bandai differs from ASCII/agetec (aside from less buttons). Unknown how the Hori thing works.
"},{"location":"controllersandmemorycards/#ascii-slph-00100-agetec-sluh-00063-silver","title":"ASCII SLPH-00100 / agetec SLUH-00063 (silver)","text":" ___\n __|___|__\n _| |_ _ __\n | | | | | |=|__| <--- crank handle\n | | SEL STA | | | |\n | | | |---| \\ ASCII SLPH-00100\n | \\ / |---| / agetec SLUH-00063\n / L1 R1 \\ | | __\n | L2 .---. R2 | |_|=|__|\n | | joy | |\n | |stick| | <------- analog thumb controlled joystick\n | /\\ '---' >< |\n | [] () |\n \\ ASCII /\n '.___________.' \\___ 10 buttons (SEL,STA,L1,L2,R1,R2,/\\,[],(),><)\n \\ _____ /\n | | Note: many (not all) agetec controllers\n | | have the >< and () buttons exchanged\n | |\n | | Aside from the crank/buttons/joystick,\n | | the controller reportedly contains:\n | | some sort of motion sensors?\n | | some kind of rumble/vibration?\n | |\n '.___.'\n '--...___ cable\n ___\n __|___|__\n _| | _ __\n | .---. |\\ | |=|__| <--- crank handle\n || joy | | | | |\n ||stick| | |-#-| \\\n | '---' | |-#-| /\n / \\ | \\ | | __\n | | ... | | |_|=|__|\n | | : : | ()|\n | |O :___: O| | <--- two buttons: () and ><\n | |- |___| -| ><| and some slide switch with I and 0 positions?\n | | | |\n \\ | BANDAI | / unknown if the joystick is digital or analog\n '._\\_______/_.'\n | | unknown if there are motion sensors and/or rumble\n '. .'\n | |\n | |\n | |\n | |\n | |\n | |\n | |\n '.___.'\n '--...___ cable\n ....----------------O\n .'' \\ HPS-97 (controller bundled with game)\n _:_ \\ \\ HPS-98 (controller only, for HPS-96 game)\n __|___|__ \\ short \\\n _| |_ elastic \\\n | | pole \\\n | | \\ <--- string (from pole to\n | SW? | _ __ \\ reel inside of fish)\n / \\ | |=|__| \\\n | .---. | | | \\\n | ( ) | joy | |--| \\ \\ ___\n | |stick| |--| / \\ / /\n | ( ) '---' | | | __ \\ ...---''''''--. /|\n | | |_|=|__| <--- crank \\ ' '/ |\n \\ ( ) ( ) / handle '..| |.\n '.___________.' |__________________| :\n \\ / \\ plastic fish :\n | | joystick, (presumable some heavy :\n | | four buttons, stationary thing that :\n | | and a switch? rests on floor) :\n | | (presumably with :\n | | motor-driven reel?) :\n | | :\n | | the two cables do probably connect :\n | | to both of the PSX controller slots :\n '.___.' cable 2 ---'\n '--...___ cable 1\nAn accessory released by Sony for the PS2, consisting of an infrared remote control and a receiver dongle that plugs into a controller port. The remote features all standard controller buttons (including L3/R3) as well as additional controls for the PS2's DVD player. The receiver behaves very differently from any other known device: it does not respond to any command until a button on the remote is pressed. When a valid IR code is received it will start accepting commands for about 2000-2500 ms, then become unresponsive again. It will initially behave as two different devices, one with address 01h acting like a standard digital controller and the other with address 61h exposing IR codes as received from the remote.
"},{"location":"controllersandmemorycards/#command-04h-ir-poll-and-disable-controller-mode","title":"Command 04h - IR poll (and disable controller mode)","text":" Send Reply Comment\n 61h N/A IR receiver address\n 04h 12h Receive ID bits 0-7, send command byte\n 00h 5Ah Receive ID bits 8-15\n 00h len Receive code length (20 for DVD remote, 0 if no button is pressed)\n 00h code Receive code bits 16-23\n 00h code Receive code bits 8-15\n 00h code Receive code bits 0-7\n Code sent by remote (first bit after preamble to last bit):\n 0000 0000 1011 1001 0010\n Code sent by remote (MSB to LSB):\n 0100 1001 1101 0000 0000\n Data returned by receiver:\n code[16:23] = 01001001\n code[8:15] = 11010000\n code[0:7] = 0000xxxx ; xxxx = (24 - len) bits of padding (all zeroes)\n Reassembled MSB-aligned code (MSB to LSB):\n 0100 1001 1101 0000 0000 xxxx\n Send Reply Comment\n 61h N/A IR receiver address\n 06h 12h Receive ID bits 0-7, send command byte 1\n 03h 5Ah Receive ID bits 8-15, send command byte 2\n 00h ? Receive unknown data, send padding\n 00h ?\n 00h ?\n 00h ?\nThis command exists (the receiver will keep pulling /ACK low) but its purpose is currently unknown. It could possibly be an alternate poll command that does not disable controller mode.
"},{"location":"controllersandmemorycards/#ir-code-format","title":"IR code format","text":"The DVD remote always emits 20-bit IR codes. The receiver does return the length of the code, but it's unclear if it can receive codes with lengths other than 20 bits. All non-controller buttons on the remote are arranged in an 8x16 button matrix, shown below (transposed for readability):
Col Row 0 Row 1 Row 2 Row 3 Row 4 Row 5 Row 6 Row 7 0 1 Previous Slow << 1 2 Next Slow >> 2 3 Play 3 4 Scan << Subtitle 4 5 Scan >> Display Audio 5 6 Shuffle Angle 6 7 7 8 8 9 Time Stop 9 0 Pause Up 10 Title A<->B Down 11 Enter DVD Menu Left 12 Repeat Right 13 14 Return 15 Clear ProgramEach button in the matrix is assigned a code as follows:
code = 49D00h OR (row << 4) OR (column) ; sent LSB first\n\n ; where row = 0..7, column = 0..15\n code = DAD50h OR (id) ; sent LSB first\n\n ; where id = 0..15, index of the bit that would normally represent the button\n ; in the bitfield returned by a controller poll command\n ; (i.e. 0=Select, 1=L3, 2=R3, 3=Start, 4=Up, 5=Right, etc.)\nThe remote emits IR pulses modulated with a 38 kHz carrier, as most remotes do. Codes are sent as a 2460 \u00b5s \"preamble\" pulse followed by 24 data pulses, each of which can be either 1250 \u00b5s (if the respective bit is 1) or 650 \u00b5s (if the respective bit is 0) long. After each pulse including the preamble, the remote waits 530 \u00b5s before sending the next pulse. Every code is always sent at least 3 times in a row (more if the button is held down but not necessarily a multiple of 3), approximately every 45 ms. For arrow buttons the matrix code is sent 3 times first, then the respective controller button code is sent 3 times, then the sequence repeats until the button is released (with the total number of codes sent always being a multiple of 6 in this case).
"},{"location":"controllersandmemorycards/#built-in-ir-receivers","title":"Built-in IR receivers","text":"In later PS2 models, Sony integrated the IR receiver into the console. Assuming the built-in receivers used the same circuitry as the external dongle, this may explain its weird behavior: the receiver was likely designed to be wired in parallel with one of the controller ports, and to be unresponsive until the remote is actually in use to avoid interfering with another controller plugged into the same port. Whether or not the integrated receivers are connected this way has not been confirmed. There is a second revision of the DVD remote with power and eject buttons, meant to be used with the PS2 models that have a built-in receiver. Weirdly enough, however, it seems to be incompatible with the older receiver dongle.
"},{"location":"controllersandmemorycards/#controllers-i-mode-adaptor-mobile-internet","title":"Controllers - I-Mode Adaptor (Mobile Internet)","text":"The I-Mode Adaptor cable (SCPH-10180) allows to connect an I-mode compatible mobile phone to the playstation's controller port; granting a mobile internet connection to japanese games.
"},{"location":"controllersandmemorycards/#psx-games-for-i-mode-adaptor-japan-only","title":"PSX Games for I-Mode Adaptor (Japan only)","text":" Doko Demo Issyo (PlayStation the Best release only) (Sony) 2000\n Doko Demo Issyo Deluxe Pack (Bomber eXpress/Sony) 2001\n Hamster Club-I (SLPS-03266) (Jorudan) 2002\n iMode mo Issyo: Dokodemo Issho Tsuika Disc (Bomber/Sony) 2001\n Keitai Eddy (iPC) 2000 (but, phone connects to SIO port on REAR side of PSX?)\n Komocchi (Victor) 2001\n Mobile Tomodachi (Hamster) 2002\n Motto Trump Shiyouyo! i-Mode de Grand Prix (Pure Sound) 2002\n One Piece Mansion (Capcom) 2001 (japanese version only)\nUnknown how to detect the thing, and how to do the actual data transfers. The cable does contain a 64pin chip, an oscillator, and some smaller components (inside of the PSX controller port connector).
"},{"location":"controllersandmemorycards/#hardware-variant","title":"Hardware Variant","text":"Keitai Eddy seems to have the phone connect to the SIO port (on rear side of the PSX, at least it's depicted like so on the CD cover). This is apparently something different than the SCPH-10180 controller-port cable. Unknown what it is exactly - probably some mobile internet connection too, maybe also using I-mode, or maybe some other protocol.
"},{"location":"controllersandmemorycards/#controllers-keyboards","title":"Controllers - Keyboards","text":"There isn't any official retail keyboard for PSX, however, there is a shitload of obscure ways to connect keyboards...
"},{"location":"controllersandmemorycards/#sony-scph-2000-ps2-keyboardmouse-adaptor-prototypewith-cable-undated","title":"Sony SCPH-2000 PS/2 Keyboard/Mouse Adaptor (prototype/with cable) (undated)","text":""},{"location":"controllersandmemorycards/#sony-scph-2000-ps2-keyboardmouse-adaptor-without-cable-undated","title":"Sony SCPH-2000 PS/2 Keyboard/Mouse Adaptor (without cable) (undated)","text":"A PS/2 to PSX controller port adaptor. Maybe for educational Lightspan titles? There are two hardware variants of the adaptor:
Adaptor with short cable to PSX-controller port (and prototype marking)\n Adaptor without cable, directly plugged into controller port (final version?)\nThe Online Connection CD is a web browser from the educational Lightspan series, the CD is extremly rare (there's only one known copy of the disc). The thing requires a dial-up modem connected to the serial port (maybe simply using the same RS232 adaptor as used by Yaroze). User input can be done via joypad, or optionally, via some external keyboard (or keyboard adaptor) hardware:
Send 01h 42h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 00h 06h\n Reply HiZ 96h 5Ah num dat dat dat dat dat dat dat dat dat dat dat\n Send .. .. .. 01h xxh FFh FFh FFh FFh FFh 00h .. .. .. ..\n Send .. .. .. 00h .. .. .. .. .. .. 00h .. .. .. ..\nMade by Anthony Ball. [http://www.sinistersoft.com/psxkeyboard]
[1F801058h]=00CEh ;SIO_MODE 8bit, no parity, 2 stop bits (8N2)\n [1F80105Ah]=771Ch ;SIO_CTRL rx enable (plus whatever nonsense bits)\n [1F80105Eh]=006Ch ;SIO_BAUD 19200 bps\n RX Keyboard Scancode (same ASCII-style as in later versions?)\n CTS Caps-Lock state\n DSR Num-Lock state\nMade by Anthony Ball. [http://www.sinistersoft.com/psxkeyboard]
This adaptor can send pad/stick data,
Send 01h 42h 00h 0h 0h\n Reply HiZ 41h 5Ah PadA\n Send 01h 42h 00h 0h 0h 0h 0h 0h 0h 0h 0h 00h 00h 0h 0h 0h 0h 0h 0h\n Reply HiZ E8h 5Ah PadA PadB PadC PadD Ver Lock Buffer(0..5)\n Version=1 ; version number\n 0 SCROLL ; scroll lock on\n 1 NUM ; num lock on\n 2 CAPS ; caps lock on\n 3 DONETEST ; keyboard has just done a selftest\n 4 EMUA ; emulation mode a\n 5 EMUB ; emulation mode b\n 01 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 69 1F\n 60 21 22 68 24 25 5E 26 2A 28 29 5F 3D 2D 0B 0E 0F 67 2F 1E 2D\n 27 51 57 45 52 54 59 55 49 4F 50 5B 5D 0D 10 61 62 37 38 39\n 3B 41 53 44 46 47 48 4A 4B 4C 3A 40 23 34 35 36 2B\n 02 5C 5A 58 43 56 42 4E 4D 3C 3E 3F 03 63 31 32 33\n 04 05 06 20 07 08 09 0A 65 64 66 30 2E 6A\n Send 01h 42h 00h 00h 00h 00h 00h\n Reply HiZ 12h 5Ah key flg dx dy\n bit0-1 = Always 11b (unlike Sony mouse)\n bit2 = Left Mouse Button (0=Pressed, 1=Released)\n bit3 = Right Mouse Button (0=Pressed, 1=Released)\n bit4-5 = Always 11b (like Sony mouse)\n bit6 = Key Release (aka F0h prefix) (0=Yes)\n bit7 = Key Extended (aka E0h prefix) (0=Yes)\nRunix is a homebrew linux kernel for PSX, it can be considered being the holy grail of the open source scene because nobody has successfully compiled it in the past 16 years. - USB host controller SL811H driver with keyboard and mouse support; - RTC support. file: drivers/usb/sl811h.c
"},{"location":"controllersandmemorycards/#tty-console","title":"TTY Console","text":"The PSX kernel allows to output \"printf\" debug messages via stdout. In the opposite direction, it's supporting to receive ASCII user input via \"std_in_gets\" (there isn't any software actually using that feature though, except maybe debug consoles like DTL-H2000).
"},{"location":"controllersandmemorycards/#controllers-additional-inputs","title":"Controllers - Additional Inputs","text":""},{"location":"controllersandmemorycards/#reset-button","title":"Reset Button","text":"PSX only (not PSone). Reboots the PSX via /RESET signal. Probably including for forcefully getting through the WHOLE BIOS Intro, making it rather useless/annoying? No idea if it clears ALL memory during reboot?
"},{"location":"controllersandmemorycards/#cdrom-shell-open","title":"CDROM Shell Open","text":"Status bit of the CDROM controller. Can be used to sense if the shell is opened (and also memorizes if the shell was opened since last check; allowing to sense possible disk changes).
"},{"location":"controllersandmemorycards/#pocketstation","title":"PocketStation","text":"Memory Card with built-in LCD screen and Buttons (which can be used as miniature handheld console). However, when it is connected to the PSX, the buttons are vanishing in the cartridge slot, so the buttons cannot be used as additional inputs for PSX games.
"},{"location":"controllersandmemorycards/#serial-port-psx-only-not-psone","title":"Serial Port PSX only (not PSone)","text":"With an external adaptor (voltage conversion), the serial port can be used (among others) to connect a RS232 Serial Mouse. Although, most or all commercial games with mouse input are probably (?) supporting only Sony's Mouse (on the controller port) (rather than standard RS232 devices on the serial port).
"},{"location":"controllersandmemorycards/#tty-debug-terminal","title":"TTY Debug Terminal","text":"If present, the external DUART can be used for external keyboard input, at the BIOS side, this is supported as \"std_in\".
"},{"location":"controllersandmemorycards/#controllers-misc","title":"Controllers - Misc","text":""},{"location":"controllersandmemorycards/#standard-controllers_1","title":"Standard Controllers","text":" SCPH-1010 digital joypad (with short cable)\n SCPH-1080 digital joypad (with longer cable)\n SCPH-1030 mouse (with short cable)\n SCPH-1090 mouse (with longer cable)\n SCPH-1092 mouse (european?)\n SCPH-1110 analog joystick\n SCPH-1150 analog joypad (with one vibration motor, with red/green led)\n SCPH-1180 analog joypad (without vibration motors, with red/green led)\n SCPH-1200 analog joypad (with two vibration motors) (dualshock)\n SCPH-110 analog joypad (with two vibration motors) (dualshock for psone)\n SCPH-10010 dualshock2 (analog buttons, except L3/R3/Start/Select) (for ps2)\n SCPH-1070 multitap\n SCPH-4010 VPick (guitar-pick controller) (for Quest for Fame, Stolen Song)\n __________ __________\n | | | ^ | ^\n | L1 R1 | | X <+> O | <+> = Digital Stick\n \\ ___| <--- L2 [] ---> |___ v / v\n | | <--- R2 /\\ ---> | |\n ___| |___________________________| |___ Not sure if all buttons\n | | | SEL STA =?= | | | are shown at their\n | | | | | | correct locations?\n | | |_ [] /\\ _| | | (drawing is based on\n | _| / L1 R1 \\ |_ | below riddle/lyrics)\n | \\_____/ X O \\_____/ |\n | /___\\ L2 R2 /___\\ |\n | |\n | |\n \\___________________________________________/\n The thumb buttons on the left act as L1 and R1,\n the trigger is L2, the pinky button is R2\n The thumb buttons on the right act as X and O,\n the trigger is Square and the pinky button is Triangle.\n I find this odd as the triggers should've been L1 and R1,\n the pinkies L2 and R2.\n The buttons are redundantly placed on the base as large buttons like what\n you'd see on a fight/arcade stick. Also with Start and Select.\n There is also a physical analog mode switch,\n not a button like on dual shock.\nThe MX4SIO is a homebrew microSD card adapter for the PS2 that plugs into a memory card slot, taking advantage of the fact that SD cards support an SPI mode which is more or less compatible with SIO0. The adapter is completely passive and has the card wired up as follows:
uSD pin Name Wired to MC pin 1D2/NC - 2 D3//CS /CS 3 CMD/MOSI CMD/MOSI 4 VCC +3.5V 5 SCK SCK 6 GND GND, /ACK 7 D0/MISO DAT/MISO 8 D1/NC - Unfortunately, this design has a fatal flaw that makes it unusable as-is on the PS1: /ACK is permanently shorted to ground, taking down the entire controller bus. However, it should be possible to use the MX4SIO on a PS1 with custom driver code once the MX4SIO's /ACK pin is masked out with some tape, or if no other controllers or memory cards are plugged in. Note that, as SD cards do not employ the addressing scheme used by standard controllers and memory cards, the MX4SIO should get its own dedicated /CSn pin and not share the port with a controller (i.e. if the MX4SIO is plugged in slot 2, then controller port 2 shall be left unused).
"},{"location":"controllersandmemorycards/#memory-card-readwrite-commands","title":"Memory Card Read/Write Commands","text":""},{"location":"controllersandmemorycards/#reading-data-from-memory-card","title":"Reading Data from Memory Card","text":" Send Reply Comment\n 81h N/A Memory card address\n 52h FLAG Send Read Command (ASCII \"R\"), Receive FLAG Byte\n 00h 5Ah Receive Memory Card ID1\n 00h 5Dh Receive Memory Card ID2\n MSB (00h) Send Address MSB ;\\sector number (0..3FFh)\n LSB (pre) Send Address LSB ;/\n 00h 5Ch Receive Command Acknowledge 1 ;<-- late /ACK after this byte-pair\n 00h 5Dh Receive Command Acknowledge 2\n 00h MSB Receive Confirmed Address MSB\n 00h LSB Receive Confirmed Address LSB\n 00h ... Receive Data Sector (128 bytes)\n 00h CHK Receive Checksum (MSB xor LSB xor Data bytes)\n 00h 47h Receive Memory End Byte (should be always 47h=\"G\"=Good for Read)\n Send Reply Comment\n 81h N/A Memory card address\n 57h FLAG Send Write Command (ASCII \"W\"), Receive FLAG Byte\n 00h 5Ah Receive Memory Card ID1\n 00h 5Dh Receive Memory Card ID2\n MSB (00h) Send Address MSB ;\\sector number (0..3FFh)\n LSB (pre) Send Address LSB ;/\n ... (pre) Send Data Sector (128 bytes)\n CHK (pre) Send Checksum (MSB xor LSB xor Data bytes)\n 00h 5Ch Receive Command Acknowledge 1\n 00h 5Dh Receive Command Acknowledge 2\n 00h 4xh Receive Memory End Byte (47h=Good, 4Eh=BadChecksum, FFh=BadSector)\n Send Reply Comment\n 81h N/A Memory card address\n 53h FLAG Send Get ID Command (ASCII \"S\"), Receive FLAG Byte\n 00h 5Ah Receive Memory Card ID1\n 00h 5Dh Receive Memory Card ID2\n 00h 5Ch Receive Command Acknowledge 1\n 00h 5Dh Receive Command Acknowledge 2\n 00h 04h Receive 04h\n 00h 00h Receive 00h\n 00h 00h Receive 00h\n 00h 80h Receive 80h\n Send Reply Comment\n 81h N/A Memory card address\n xxh FLAG Send Invalid Command (anything else than \"R\", \"W\", or \"S\")\nThe initial value of the FLAG byte on power-up (and when re-inserting the memory card) is 08h. Bit3=1 is indicating that the directory wasn't read yet (allowing to sense memory card changes). For some strange reason, bit3 is NOT reset when reading from the card, but rather when writing to it. To reset the flag, games are usually issuing a dummy write to sector number 003Fh, more or less unneccessarily stressing the lifetime of that sector. Bit2=1 seems to be intended to indicate write errors, however, the write command seems to be always finishing without setting that bit, instead, the error flag may get set on the NEXT command. Note: Some (not all) non-sony cards also have Bit5 of the FLAG byte set.
"},{"location":"controllersandmemorycards/#timings","title":"Timings","text":"IRQ7 is usually triggered circa 1500 cycles after sending a byte (counted from the begin of the first bit), except, the last byte doesn't trigger IRQ7, and, after the 7th byte of the Read command, an additional delay of circa 31000 cycles occurs before IRQ7 gets triggered (that strange extra delay occurs only on original Sony cards, not on cards from other manufacturers). There seems to be no extra delays in the Write command, as it seems, the data is written on the fly, and one doesn't need to do any write-busy handling... although, theoretically, the write shouldn't start until verifying the checksum... so it can't be done on the fly at all...?
"},{"location":"controllersandmemorycards/#notes_1","title":"Notes","text":"Responses in brackets are don't care, (00h) means usually zero, (pre) means usually equal to the previous command byte (eg. the response to LSB is MSB).
Memory cards are reportedly \"Flash RAM\" which sounds like bullshit, might be battery backed SRAM, or FRAM, or slower EEPROM or FLASH ROM, or vary from card to card...?
"},{"location":"controllersandmemorycards/#memory-card-data-format","title":"Memory Card Data Format","text":""},{"location":"controllersandmemorycards/#data-size","title":"Data Size","text":" Total Memory 128KB = 131072 bytes = 20000h bytes\n 1 Block 8KB = 8192 bytes = 2000h bytes\n 1 Frame 128 bytes = 80h bytes\n 00h-01h Memory Card ID (ASCII \"MC\")\n 02h-7Eh Unused (zero)\n 7Fh Checksum (all above bytes XORed with each other) (usually 0Eh)\n 00h-03h Block Allocation State\n 00000051h - In use ;first-or-only block of a file\n 00000052h - In use ;middle block of a file (if 3 or more blocks)\n 00000053h - In use ;last block of a file (if 2 or more blocks)\n 000000A0h - Free ;freshly formatted\n 000000A1h - Free ;deleted (first-or-only block of file)\n 000000A2h - Free ;deleted (middle block of file)\n 000000A3h - Free ;deleted (last block of file)\n 04h-07h Filesize in bytes (2000h..1E000h; in multiples of 8Kbytes)\n 08h-09h Pointer to the NEXT block number (minus 1) used by the file\n (ie. 0..14 for Block Number 1..15) (or FFFFh if last-or-only block)\n 0Ah-1Eh Filename in ASCII, terminated by 00h (max 20 chars, plus ending 00h)\n 1Fh Zero (unused)\n 20h-7Eh Garbage (usually 00h-filled)\n 7Fh Checksum (all above bytes XORed with each other)\nThe first some letters of the filename should indicate the game to which the file belongs, in case of commercial games this is conventionally done like so: Two character region code:
\"BI\"=Japan, \"BE\"=Europe, \"BA\"=America\n in \"AAAA-NNNNN\" form ;for Pocketstation executables replace \"-\" by \"P\"\n \"abcdefgh\"\n 00h-03h Broken Sector Number (Block*64+Frame) (FFFFFFFFh=None)\n 04h-7Eh Garbage (usually 00h-filled) (some cards have [08h..09h]=FFFFh)\n 7Fh Checksum (all above bytes XORed with each other)\n 00h-7Fh Data (usually FFh-filled, if there's no broken sector)\n 00h-7Fh Unused (usually FFh-filled)\nReportedly \"write test\". Usually same as Block 0 (\"MC\", 253 zero-bytes, plus checksum 0Eh).
"},{"location":"controllersandmemorycards/#title-frame-block-115-frame-0-in-first-block-of-file-only","title":"Title Frame (Block 1..15, Frame 0) (in first block of file only)","text":" 00h-01h ID (ASCII \"SC\")\n 02h Icon Display Flag\n 11h...Icon has 1 frame (static) (same image shown forever)\n 12h...Icon has 2 frames (animated) (changes every 16 PAL frames)\n 13h...Icon has 3 frames (animated) (changes every 11 PAL frames)\n Values other than 11h..13h seem to be treated as corrupted file\n (causing the file not to be listed in the bootmenu)\n 03h Block Number (1-15) \"icon block count\" Uh?\n (usually 01h or 02h... might be block number within\n files that occupy 2 or more blocks)\n (actually, that kind of files seem to HAVE title frames\n in ALL of their blocks; not only in their FIRST block)\n (at least SOME seem to have such duplicated title frame,\n but not all?)\n 04h-43h Title in Shift-JIS format (64 bytes = max 32 characters)\n 44h-4Fh Reserved (00h)\n 50h-5Fh Reserved (00h) ;<-- this region is used for the Pocketstation\n 60h-7Fh Icon 16 Color Palette Data (each entry is 16bit CLUT)\n 00h-7Fh Icon Bitmap (16x16 pixels, 4bit color depth)\n 00h-7Fh Data\nCan contain japanese or english text, english characters are encoded like so:
81h,40h --> SPC\n 81h,43h..97h --> punctuation marks\n 82h,4Fh..58h --> \"0..9\"\n 82h,60h..79h --> \"A..Z\"\n 82h,81h..9Ah --> \"a..z\"\nThere are a lot of different ways to get a save from a memory card onto your PC's hard disk, and these ways sometimes involve sticking some additional information into a header at the beginning of the file.
"},{"location":"controllersandmemorycards/#raw-memory-card-images-without-header-ie-usually-128k-in-size","title":"Raw Memory Card Images (without header) (ie. usually 128K in size)","text":" SmartLink .PSM,\n WinPSM .PS,\n DataDeck .DDF,\n FPSX .MCR,\n ePSXe .MCD...\nAll of these headers contain a signature at the top of the file. The three most common formats and their signatures are:
Connectix Virtual Game Station format (.MEM): \"VgsM\", 64 bytes\n PlayStation Magazine format (.PSX): \"PSV\", 256 bytes\nsome programs will OMIT any blank or unallocated blocks from the end of the memory card -- if only three save blocks on the card are in use, for example, saving the other twelve is pointless.
"},{"location":"controllersandmemorycards/#xploder-and-action-replay-files-54-byte-header","title":"Xploder and Action Replay Files (54 byte header)","text":" 00h..14h Filename in ASCII, terminated by 00h (max 20 chars, plus ending 00h)\n 15h..35h Title in ASCII, terminated by 00h (max 32 chars, plus ending 00h)\n 36h.. File Block(s) (starting with the Title sector)\nMCS files consist of the 128 byte directory frame for the savefile's first block followed by all of that savefile's blocks in linked list order. When importing this format, the directory frame should be parsed for the save filename and the filesize while other fields should be ignored. The rest of the directory frame fields and any extra directory frames, in the case of multi-block saves, should be reconstructed based on the destination memory card.
"},{"location":"controllersandmemorycards/#gme-files-usually-20f40h-bytes","title":".GME Files (usually 20F40h bytes)","text":"InterAct GME format, produced by the DexDrive.
000h 12 ASCII String \"123-456-STD\",00h\n 00Ch 4 Usually zerofilled (or meaningless garbage in some files)\n 010h 5 Always 00h,00h,01h,00h,01h\n 015h 16 Copy of Sector 0..15 byte[00h] ;\"M\", followed by allocation states\n 025h 16 Copy of Sector 0..15 byte[08h] ;00h, followed by next block values\n 035h 11 Usually zerofilled (or meaningless garbage in some files)\n 040h F00h Fifteen Description Strings (each one 100h bytes, padded with 00h)\n F40h 128K Memory Card Image (128K) (unused sectors 00h or FFh filled)\nSony has manufactured only 128KByte memory cards for PSX, no bigger/smaller ones.
"},{"location":"controllersandmemorycards/#sony-ps2-memory-cards","title":"Sony PS2 Memory Cards","text":"A special case would be PS2 cards, these are bigger, but PS2 cards won't fit into PSX cards slots (unless when cutting an extra notch in the card edge connector), a PSX game played on a PS2 console could theoretically access PS2 cards (if it supports the different directory structure on that cards).
"},{"location":"controllersandmemorycards/#third-party-cards-with-bigger-capacity","title":"Third Party Cards with bigger capacity","text":"Some third party cards contain larger memory chips, however, the PSX games/kernel are supporting only regular 128Kbyte cards, so the extra memory can be used only by dividing it into several 128Kbyte memory card images. Selecting a different memory card image can be done by a switch or button on the card, or via joypad key combinations (joypad/card are sharing the same signals, so the card could watch the traffic on joypad bus, provided that the MIPS CPU is actually reading the joypad).
"},{"location":"controllersandmemorycards/#third-party-cards-with-bigger-capacity-and-data-compression","title":"Third Party Cards with bigger capacity and Data Compression","text":"Some cards are additionally using data compression to increase the card capacity, but that techinque is having rather bad reputation and could result in data loss. For example, if a game has allocated four blocks on the memory card, then it'll expect to be able to overwrite that four blocks at any time (without needing to handle \"memory card full\" errors), however, if the card is full, and if the newly written data has worse compression ratio, then the card will be unable to store the new game position (and may have already overwritten parts of the old game position). As a workaround, such cards may use a LED to warn users when running low on memory (ideally, there should be always at least 128Kbytes of free memory).
"},{"location":"controllersandmemorycards/#joytech-smart-card-adaptor","title":"Joytech Smart Card Adaptor","text":"The smart card adaptor plugs into memory card slot, and allows to use special credit card-shaped memory cards. There don't seem to be any special features, ie. the hardware setup does just behave like normal PSX memory cards.
"},{"location":"controllersandmemorycards/#datel-vmem-virtual-memory-card-storage-on-expansion-port","title":"Datel VMEM (virtual memory card storage on expansion port)","text":"The Datel/Interact VMEM exists as standalone VMEM cartridge, and some Datel Cheat Devices do also include the VMEM feature. Either way, the VMEM connects to expansion port, and contain some large FLASH memory, for storing multiple memory cards on it. Unknown, how that memory is accessed (maybe it must be copied to a regular memory card, or maybe they've somehow hooked the Kernel (or even the hardware signals?) so that games could directly access the VMEM?
"},{"location":"controllersandmemorycards/#passwords-instead-of-memory-cards","title":"Passwords (instead of Memory Cards)","text":"Some older games are using passwords instead of memory cards to allow the user to continue at certain game positions. That's nice for people without memory card, but unfortunately many of that games are restricted to it - it'd be more user friendly to support both passwords, and, optionally, memory cards.
"},{"location":"controllersandmemorycards/#yaroze-access-cards-dtl-h3020","title":"Yaroze Access Cards (DTL-H3020)","text":"The Yaroze Access Card connects to memory card slot, the card resembles regular memory cards, but it doesn't contain any storage memory. Instead, it does merely support a very basic Access Card detection command:
Send Reply Comment\n 21h N/A? Probably replies HighZ (ie. probably reads FFh)?\n 53h 0xh? Replies unknown 8bit value (upper 4bit are known to be zero)?\nPocketstation
"},{"location":"cpuspecifications/","title":"CPU Specifications","text":""},{"location":"cpuspecifications/#cpu","title":"CPU","text":"CPU Registers CPU Opcode Encoding CPU Load/Store Opcodes CPU ALU Opcodes CPU Jump Opcodes CPU Coprocessor Opcodes CPU Pseudo Opcodes
"},{"location":"cpuspecifications/#system-control-coprocessor-cop0","title":"System Control Coprocessor (COP0)","text":"COP0 - Register Summary COP0 - Exception Handling COP0 - Misc COP0 - Debug Registers
"},{"location":"cpuspecifications/#cpu-registers","title":"CPU Registers","text":"All registers are 32bit wide.
Name Alias Common Usage\n R0 zero Constant (always 0)\n R1 at Assembler temporary (destroyed by some assembler pseudoinstructions!)\n R2-R3 v0-v1 Subroutine return values, may be changed by subroutines\n R4-R7 a0-a3 Subroutine arguments, may be changed by subroutines\n R8-R15 t0-t7 Temporaries, may be changed by subroutines\n R16-R23 s0-s7 Static variables, must be saved by subs\n R24-R25 t8-t9 Temporaries, may be changed by subroutines\n R26-R27 k0-k1 Reserved for kernel (destroyed by some IRQ handlers!)\n R28 gp Global pointer (rarely used)\n R29 sp Stack pointer\n R30 fp(s8) Frame Pointer, or 9th Static variable, must be saved\n R31 ra Return address (used so by JAL,BLTZAL,BGEZAL opcodes)\n - pc Program counter\n - hi,lo Multiply/divide results, may be changed by subroutines\nThe CPU doesn't explicitly have stack-related registers or opcodes, however, conventionally, R29 is used as stack pointer (SP). The stack can be accessed with normal load/store opcodes, which do not automatically increase/decrease SP, so the SP register must be manually modified to (de-)allocate data. The PSX BIOS is using \"Full Decrementing Wasted Stack\". Decrementing means that SP gets decremented when allocating data (that's common for most CPUs) - Full means that SP points to the first ALLOCATED word on the stack, so the allocated memory is at SP+0 and above, free memory at SP-1 and below, Wasted means that when calling a sub-function with N parameters, then the caller must pre-allocate N works on stack, and the sub-function may freely use and destroy these words; at [SP+0..N*4-1].
For example, \"push ra,r16,r17\" would be implemented as:
sub sp,20h\n mov [sp+14h],ra\n mov [sp+18h],r16\n mov [sp+1Ch],r17\n [sp+00h..0Fh] wasted stack (may, or may not, be used by sub-functions)\n [sp+10h..13h] 8-byte alignment padding (not used)\n [sp+14h..1Fh] pushed registers\n 00h=SPECIAL 08h=ADDI 10h=COP0 18h=N/A 20h=LB 28h=SB 30h=LWC0 38h=SWC0\n 01h=BcondZ 09h=ADDIU 11h=COP1 19h=N/A 21h=LH 29h=SH 31h=LWC1 39h=SWC1\n 02h=J 0Ah=SLTI 12h=COP2 1Ah=N/A 22h=LWL 2Ah=SWL 32h=LWC2 3Ah=SWC2\n 03h=JAL 0Bh=SLTIU 13h=COP3 1Bh=N/A 23h=LW 2Bh=SW 33h=LWC3 3Bh=SWC3\n 04h=BEQ 0Ch=ANDI 14h=N/A 1Ch=N/A 24h=LBU 2Ch=N/A 34h=N/A 3Ch=N/A\n 05h=BNE 0Dh=ORI 15h=N/A 1Dh=N/A 25h=LHU 2Dh=N/A 35h=N/A 3Dh=N/A\n 06h=BLEZ 0Eh=XORI 16h=N/A 1Eh=N/A 26h=LWR 2Eh=SWR 36h=N/A 3Eh=N/A\n 07h=BGTZ 0Fh=LUI 17h=N/A 1Fh=N/A 27h=N/A 2Fh=N/A 37h=N/A 3Fh=N/A\n 00h=SLL 08h=JR 10h=MFHI 18h=MULT 20h=ADD 28h=N/A 30h=N/A 38h=N/A\n 01h=N/A 09h=JALR 11h=MTHI 19h=MULTU 21h=ADDU 29h=N/A 31h=N/A 39h=N/A\n 02h=SRL 0Ah=N/A 12h=MFLO 1Ah=DIV 22h=SUB 2Ah=SLT 32h=N/A 3Ah=N/A\n 03h=SRA 0Bh=N/A 13h=MTLO 1Bh=DIVU 23h=SUBU 2Bh=SLTU 33h=N/A 3Bh=N/A\n 04h=SLLV 0Ch=SYSCALL 14h=N/A 1Ch=N/A 24h=AND 2Ch=N/A 34h=N/A 3Ch=N/A\n 05h=N/A 0Dh=BREAK 15h=N/A 1Dh=N/A 25h=OR 2Dh=N/A 35h=N/A 3Dh=N/A\n 06h=SRLV 0Eh=N/A 16h=N/A 1Eh=N/A 26h=XOR 2Eh=N/A 36h=N/A 3Eh=N/A\n 07h=SRAV 0Fh=N/A 17h=N/A 1Fh=N/A 27h=NOR 2Fh=N/A 37h=N/A 3Fh=N/A\n 31..26 |25..21|20..16|15..11|10..6 | 5..0 |\n 6bit | 5bit | 5bit | 5bit | 5bit | 6bit |\n -------+------+------+------+------+--------+------------\n 000000 | N/A | rt | rd | imm5 | 0000xx | shift-imm\n 000000 | rs | rt | rd | N/A | 0001xx | shift-reg\n 000000 | rs | N/A | N/A | N/A | 001000 | jr\n 000000 | rs | N/A | rd | N/A | 001001 | jalr\n 000000 | <-----comment20bit------> | 00110x | sys/brk\n 000000 | N/A | N/A | rd | N/A | 0100x0 | mfhi/mflo\n 000000 | rs | N/A | N/A | N/A | 0100x1 | mthi/mtlo\n 000000 | rs | rt | N/A | N/A | 0110xx | mul/div\n 000000 | rs | rt | rd | N/A | 10xxxx | alu-reg\n 000001 | rs | 00000| <--immediate16bit--> | bltz\n 000001 | rs | 00001| <--immediate16bit--> | bgez\n 000001 | rs | 10000| <--immediate16bit--> | bltzal\n 000001 | rs | 10001| <--immediate16bit--> | bgezal\n 00001x | <---------immediate26bit---------> | j/jal\n 00010x | rs | rt | <--immediate16bit--> | beq/bne\n 00011x | rs | N/A | <--immediate16bit--> | blez/bgtz\n 001xxx | rs | rt | <--immediate16bit--> | alu-imm\n 001111 | N/A | rt | <--immediate16bit--> | lui-imm\n 100xxx | rs | rt | <--immediate16bit--> | load rt,[rs+imm]\n 101xxx | rs | rt | <--immediate16bit--> | store rt,[rs+imm]\n x1xxxx | <------coprocessor specific------> | coprocessor (see below)\n 31..26 |25..21|20..16|15..11|10..6 | 5..0 |\n 6bit | 5bit | 5bit | 5bit | 5bit | 6bit |\n -------+------+------+------+------+--------+------------\n 0100nn |0|0000| rt | rd | N/A | 000000 | MFCn rt,rd_dat ;rt = dat\n 0100nn |0|0010| rt | rd | N/A | 000000 | CFCn rt,rd_cnt ;rt = cnt\n 0100nn |0|0100| rt | rd | N/A | 000000 | MTCn rt,rd_dat ;dat = rt\n 0100nn |0|0110| rt | rd | N/A | 000000 | CTCn rt,rd_cnt ;cnt = rt\n 0100nn |0|1000|00000 | <--immediate16bit--> | BCnF target ;jump if false\n 0100nn |0|1000|00001 | <--immediate16bit--> | BCnT target ;jump if true\n 0100nn |1| <--------immediate25bit--------> | COPn imm25\n 010000 |1|0000| N/A | N/A | N/A | 000001 | COP0 01h ;=TLBR, unused on PS1\n 010000 |1|0000| N/A | N/A | N/A | 000010 | COP0 02h ;=TLBWI, unused on PS1\n 010000 |1|0000| N/A | N/A | N/A | 000110 | COP0 06h ;=TLBWR, unused on PS1\n 010000 |1|0000| N/A | N/A | N/A | 001000 | COP0 08h ;=TLBP, unused on PS1\n 010000 |1|0000| N/A | N/A | N/A | 010000 | COP0 10h ;=RFE\n 1100nn | rs | rt | <--immediate16bit--> | LWCn rt_dat,[rs+imm]\n 1110nn | rs | rt | <--immediate16bit--> | SWCn rt_dat,[rs+imm]\nAll opcodes that are marked as \"N/A\" in the Primary and Secondary opcode tables are causing a Reserved Instruction Exception (excode=0Ah). The unused operand bits (eg. Bit21-25 for LUI opcode) should be usually zero, but do not necessarily trigger exceptions if set to nonzero values.
"},{"location":"cpuspecifications/#cpu-loadstore-opcodes","title":"CPU Load/Store Opcodes","text":""},{"location":"cpuspecifications/#load-instructions","title":"Load instructions","text":" lb rt,imm(rs) rt=[imm+rs] ;byte sign-extended\n lbu rt,imm(rs) rt=[imm+rs] ;byte zero-extended\n lh rt,imm(rs) rt=[imm+rs] ;halfword sign-extended\n lhu rt,imm(rs) rt=[imm+rs] ;halfword zero-extended\n lw rt,imm(rs) rt=[imm+rs] ;word\nThe loaded data is NOT available to the next opcode, ie. the target register isn't updated until the next opcode has completed. So, if the next opcode tries to read from the load destination register, then it would (usually) receive the OLD value of that register (unless an IRQ occurs between the load and next opcode, in that case the load would complete during IRQ handling, and so, the next opcode would receive the NEW value). MFC2/CFC2 also have a 1-instruction delay until the target register is loaded with its new value (more info in the GTE section).
"},{"location":"cpuspecifications/#store-instructions","title":"Store instructions","text":" sb rt,imm(rs) [imm+rs]=(rt AND FFh) ;store 8bit\n sh rt,imm(rs) [imm+rs]=(rt AND FFFFh) ;store 16bit\n sw rt,imm(rs) [imm+rs]=rt ;store 32bit\nDuring an 8-bit or 16-bit store, all 32 bits of the GPR are placed on the bus. As such, when writing to certain 32-bit IO registers with an 8 or 16-bit store, it will behave like a 32-bit store, using the register's full value. The soundscope on some shells is known to rely on this, as it uses sh to write to certain DMA registers. If this is not properly emulated, the soundscope will hang, waiting for an interrupt that will never be fired.
Halfword addresses must be aligned by 2, word addresses must be aligned by 4, trying to access mis-aligned addresses will cause an exception. There's no alignment restriction for bytes.
"},{"location":"cpuspecifications/#unaligned-loadstore","title":"Unaligned Load/Store","text":" lwr rt,imm(rs) load right bits of rt from memory (usually imm+0)\n lwl rt,imm(rs) load left bits of rt from memory (usually imm+3)\n swr rt,imm(rs) store right bits of rt to memory (usually imm+0)\n swl rt,imm(rs) store left bits of rt to memory (usually imm+3)\n lwl r2,$0003(t0) ;\\no delay required between these\n lwr r2,$0000(t0) ;/(although both access r2)\n nop ;-requires load delay HERE (before reading from r2)\n and r2,r2,0ffffh ;-access r2 (eg. reducing it to unaligned 16bit data)\nLWR/SWR transfers the right (=lower) bits of Rt, up-to 32bit memory boundary:
lwr/swr [N*4+0] transfer whole 32bit of Rt to/from [N*4+0..3]\n lwr/swr [N*4+1] transfer lower 24bit of Rt to/from [N*4+1..3]\n lwr/swr [N*4+2] transfer lower 16bit of Rt to/from [N*4+2..3]\n lwr/swr [N*4+3] transfer lower 8bit of Rt to/from [N*4+3]\n lwl/swl [N*4+0] transfer upper 8bit of Rt to/from [N*4+0]\n lwl/swl [N*4+1] transfer upper 16bit of Rt to/from [N*4+0..1]\n lwl/swl [N*4+2] transfer upper 24bit of Rt to/from [N*4+0..2]\n lwl/swl [N*4+3] transfer whole 32bit of Rt to/from [N*4+0..3]\nNote: The aligned variant can also misused for blocking memory access on aligned addresses (in that case, if the address is known to be aligned, only one of the opcodes are needed, either LWL or LWR).... Uhhhhhhhm, OR is that NOT allowed... more PROBABLY that doesn't work?
"},{"location":"cpuspecifications/#cpu-alu-opcodes","title":"CPU ALU Opcodes","text":""},{"location":"cpuspecifications/#arithmetic-instructions","title":"arithmetic instructions","text":" add rd,rs,rt rd=rs+rt (with overflow trap)\n addu rd,rs,rt rd=rs+rt\n sub rd,rs,rt rd=rs-rt (with overflow trap)\n subu rd,rs,rt rd=rs-rt\n addi rt,rs,imm rt=rs+(-8000h..+7FFFh) (with ov.trap)\n addiu rt,rs,imm rt=rs+(-8000h..+7FFFh)\n slt rd,rs,rt if rs<rt (signed comparison) then rd=1 else rd=0\n sltu rd,rs,rt if rs<rt (unsigned comparison) then rd=1 else rd=0\n slti rt,rs,imm if rs<(sign-extended immediate in range [-8000h..+7FFFh], signed comparison) then rt=1 else rt=0\n sltiu rt,rs,imm if rs<(sign-extended immediate in range [0..7FFFh] U [FFFF8000h..FFFFFFFFh], unsigned comparison) then rt=1 else rt=0\n and rd,rs,rt rd = rs AND rt\n or rd,rs,rt rd = rs OR rt\n xor rd,rs,rt rd = rs XOR rt\n nor rd,rs,rt rd = FFFFFFFFh XOR (rs OR rt)\n andi rt,rs,imm rt = rs AND (0000h..FFFFh)\n ori rt,rs,imm rt = rs OR (0000h..FFFFh)\n xori rt,rs,imm rt = rs XOR (0000h..FFFFh)\n sllv rd,rt,rs rd = rt SHL (rs AND 1Fh)\n srlv rd,rt,rs rd = rt SHR (rs AND 1Fh)\n srav rd,rt,rs rd = rt SAR (rs AND 1Fh)\n sll rd,rt,imm rd = rt SHL (00h..1Fh)\n srl rd,rt,imm rd = rt SHR (00h..1Fh)\n sra rd,rt,imm rd = rt SAR (00h..1Fh)\n lui rt,imm rt = (0000h..FFFFh) SHL 16\n mult rs,rt hi:lo = rs*rt (signed)\n multu rs,rt hi:lo = rs*rt (unsigned)\n div rs,rt lo = rs/rt, hi=rs mod rt (signed)\n divu rs,rt lo = rs/rt, hi=rs mod rt (unsigned)\n mfhi rd rd=hi ;move from hi\n mflo rd rd=lo ;move from lo\n mthi rs hi=rs ;move to hi\n mtlo rs lo=rs ;move to lo\n __multu_execution_time_____________________________________________________\n Fast (6 cycles) rs = 00000000h..000007FFh\n Med (9 cycles) rs = 00000800h..000FFFFFh\n Slow (13 cycles) rs = 00100000h..FFFFFFFFh\n __mult_execution_time_____________________________________________________\n Fast (6 cycles) rs = 00000000h..000007FFh, or rs = FFFFF800h..FFFFFFFFh\n Med (9 cycles) rs = 00000800h..000FFFFFh, or rs = FFF00000h..FFFFF801h\n Slow (13 cycles) rs = 00100000h..7FFFFFFFh, or rs = 80000000h..FFF00001h\n __divu/div_execution_time________________________________________________\n Fixed (36 cycles) no matter of rs and rt values\n Opcode Rs Rt Hi/Remainder Lo/Result\n divu 0..FFFFFFFFh 0 --> Rs FFFFFFFFh\n div 0..+7FFFFFFFh 0 --> Rs -1\n div -80000000h..-1 0 --> Rs +1\n div -80000000h -1 --> 0 -80000000h\nNote that the instruction following the branch will always be executed.
j dest pc=(pc and F0000000h)+(imm26bit*4)\n jal dest pc=(pc and F0000000h)+(imm26bit*4),ra=$+8\n jr rs pc=rs\n jalr (rd,)rs(,rd) pc=rs, rd=$+8 ;see caution\n beq rs,rt,dest if rs=rt then pc=$+4+(-8000h..+7FFFh)*4\n bne rs,rt,dest if rs<>rt then pc=$+4+(-8000h..+7FFFh)*4\n bltz rs,dest if rs<0 then pc=$+4+(-8000h..+7FFFh)*4\n bgez rs,dest if rs>=0 then pc=$+4+(-8000h..+7FFFh)*4\n bgtz rs,dest if rs>0 then pc=$+4+(-8000h..+7FFFh)*4\n blez rs,dest if rs<=0 then pc=$+4+(-8000h..+7FFFh)*4\n bltzal rs,dest if rs<0 then pc=$+4+(..)*4; ra=$+8; \n bgezal rs,dest if rs>=0 then pc=$+4+(..)*4; ra=$+8;\njr/jalr can be used to jump to an unaligned address, in which case an address error (AdEL) exception will be raised on the next instruction fetch. Additionally, bltzal/bgezal will always place the return address in $ra, whether or not the branch is taken. Additionally, if rs is $ra, then the value used for the comparison is $ra's value before linking.
Caution: The JALR source code syntax varies (IDT79R3041 specs say \"jalr rs,rd\", but MIPS32 specs say \"jalr rd,rs\"). Moreover, JALR may not use the same register for both operands (eg. \"jalr r31,r31\") (doing so would destroy the target address; which is normally no problem, but it can be a problem if an IRQ occurs between the JALR opcode and the following branch delay opcode; in that case BD gets set, and EPC points \"back\" to the JALR opcode, so JALR is executed twice, with destroyed target address in second execution).
"},{"location":"cpuspecifications/#exception-opcodes","title":"exception opcodes","text":"Unlike for jump/branch opcodes, exception opcodes are immediately executed (ie. without executing the following opcode).
syscall imm20 generates a system call exception\n break imm20 generates a breakpoint exception\n mfc# rt,rd ;rt = cop#datRd ;data regs\n cfc# rt,rd ;rt = cop#cntRd ;control regs\n mtc# rt,rd ;cop#datRd = rt ;data regs\n ctc# rt,rd ;cop#cntRd = rt ;control regs\n cop# imm25 ;exec cop# command 0..1FFFFFFh\n lwc# rt,imm(rs) ;cop#dat_rt = [rs+imm] ;word\n swc# rt,imm(rs) ;[rs+imm] = cop#dat_rt ;word\n bc#f dest ;if cop#flg=false then pc=$+disp\n bc#t dest ;if cop#flg=true then pc=$+disp\n rfe ;return from exception (COP0)\n tlb<xx> ;virtual memory related (COP0), unused in the PS1\nWhen reading from a coprocessor register, the next opcode cannot use the destination register as operand (much the same as the Load Delays that occur when reading from memory; see there for details). Reportedly, the Load Delay applies for the next TWO opcodes after coprocessor reads, but, that seems to be nonsense (the PSX does finish both COP0 and COP2 reads after ONE opcode).
"},{"location":"cpuspecifications/#caution-store-delay","title":"Caution - Store Delay","text":"In some cases, a similar delay occurs when writing to a coprocessor register. COP0 is more or less free of store delays (eg. one can read from a cop0 register immediately after writing to it), the only known exception is the cop2 enable bit in cop0r12.bit30 (setting that cop0 bit acts delayed, and cop2 isn't actually enabled until after 2 clock cycles or so). Writing to cop2 registers has a delay of 2..3 clock cycles. In most cases, that is probably (?) only 2 cycles, but special cases like writing to IRGB (which does additionally affect IR1,IR2,IR3) take 3 cycles until the result arrives in all registers). Note that Store Delays are counted in numbers of clock cycles (not in numbers of opcodes). For 3 cycle delay, one must usually insert 3 cached opcodes (or one uncached opcode).
"},{"location":"cpuspecifications/#cpu-pseudo-opcodes","title":"CPU Pseudo Opcodes","text":""},{"location":"cpuspecifications/#pseudo-instructions-nativespasm","title":"Pseudo instructions (native/spasm)","text":" nop ;alias for sll r0,r0,0\n move rd,rs ;alias for addu rd,rs,r0\n la rx,imm32 ;load address (alias for lui rx / addiu rx)\n li rx,imm32 ;load immediate (alias for lui rx / ori rx)\n li rx,imm16 ;load immediate (alias for ori, range 0..FFFFh)\n li rx,-imm15 ;load immediate (alias for addiu, range -1..-8000h)\n li rx,imm16*10000h ;load immediate (alias for lui)\n lw rx,imm32 ;load from address (lui rx / lw rx,rx)\n sw rx,imm32 ;store to address (lui r1 / sw rx,r1) (destroys r1!)\n lb,lh,lwl,lwr,lbu,lhu;as above pseudo lw\n sb,sh,swl,swr ;as above pseudo sw (ie. also destroys r1!)\n alu rx,op ;alias for alu rx,rx,op\n alu(u) rx,rx,imm ;alias for alui(u) rx,rx,imm\n jalr rx ;alias for jalr (RA,)rx(,RA)\n subi(u) rt,rs,imm ;alias for addi(u) rt,rs,-imm\n beqz rx,dest ;alias for beq rx,r0,dest\n bnez rx,dest ;alias for bne rx,r0,dest\n b dest ;alias for beq r0,r0,dest (jump relative/spasm)\n bra dest ;alias for bgez r0, r0, dest\n bal dest ;alias for bgezal r0, r0, dest\n mov rx,NNNN0000h ;alias for lui rx,NNNNh\n mov rx,0000NNNNh ;alias for or rx,r0,NNNNh ;max +FFFFh\n mov rx,-imm15 ;alias for add rx,r0,-NNNNh ;min -8000h\n mov rx,ry ;alias for or rx,ry,0 (or \"addiu\")\n jrel dest ;alias for blez R0,dest ;relative jump\n crel dest ;alias for callns R0,dest ;relative call\n jz rx,dest ;alias for je rx,R0,dest\n jnz rx,dest ;alias for jne rx,R0,dest\n call rx ;alias for call rx,ret=RA\n ret ;alias for jmp ra\n subt rt,rs,imm ;alias for addt rt,rs,-imm\n sub rt,rs,imm ;alias for add rt,rs,-imm\n alu rx,op ;alias for alu rx,rx,op\n neg(t) rx,ry ;alias for sub(t) rx,R0,ry\n not rx,ry ;alias for nor rx,R0,ry\n neg(t)/not rx ;alias for neg(t)/not rx,rx\n setz rx,ry ;alias for setb rx,ry,1 (set if zero)\n setnz rx,ry ;alias for setb rx,R0,ry (set if nonzero)\n syscall/break ;alias for syscall/break 000000h\n movp rx,imm32 ;alias for lui rx,imm16 -plus- or rx,rx,imm16)\n mov(bhs)p rx,[imm32] ;load from address (lui rx,imm16 / mov rx,[rx+imm16])\n movu [rs+imm] ;alias for lwr/swr [rs+imm] plus lwl/swl [rs+imm+3]\n reti ;alias for jmp k0 plus rfe\n push rlist ;alias for sub sp,n*4 -- mov [sp+(1..n)*4],r1..rn\n pop rlist ;alias for mov r1..rn,[sp+(1..n)*4] -- add sp,n*4\n pop pc,rlist ;alias for pop ra,rlist -- jmp ra\n .mips ;select MIPS instruction set (alternately .hc05 for MC68HC05)\n .bios ;create a .ROM file (instead of .EXE)\n .auto_nop ;append NOPs to jumps ;unless next opcode starts with a +\n org imm ;assume following code to be originated at address \"imm\"\n db n(,n(..))) ;define 8bit data values(s) or quoted ASCII strings\n dw n(,n(..))) ;define 16bit data values(s) (not 32bit data!)\n dd n(,n(..))) ;define 32bit data values(s)\n .align imm\n 0 ;alias for immediate 0 and register R0 (whichever fits)\n org imm ;self-explaining (but, default=$80010000 for spasm!)\n align imm ;self-explaining (probably zeropadded?)\n db n(,n(..))) ;define 8bit data values(s) or quoted ASCII strings\n dh n(,n(..))) ;define 16bit data values(s)\n dw n(,n(..))) ;define 32bit data values(s) (not 16bit data!)\n dcb len,value ;fill <len> bytes by <value> (different as DCB on ARM CPUs)\n xyz ;define label \"xyz\" at current address (without colon)\n xyz equ n ;assign value n to xyz\n xyz = n ;probably same/sililar as \"equ\"\n ;xyz ;comments invoked with semicolon (spasm)\n incbin file.bin ;import binary file\n include file.asm ;import asm file\n zero ;alias for r0\n >imm32 ;alias for (i-(i AND 8000h))/10000h, and/or i/10000h ?\n <imm32 ;alias for (i AND 0FFFFh), used for SW(+/-) and ORI(+)?\n end ;N/A ;no \"end\" or \".end\" directive needed/used by spasm\n r1 aka at ;N/A ;some assemblers may (optionally) reject to use r1/at\nIt uses \"0x\" for HEX values (but doesn't use \"$\" for registers). It uses \"#\" instead of \";\" for comments. It uses \":\" for labels (fortunately). The assembler has at least one directive: \".byte\" (equivalent to \"db\" on other assemblers). I've no clue which assembler is used for that syntax... could that be the Psy-Q assembler?
"},{"location":"cpuspecifications/#cop0-register-summary","title":"COP0 - Register Summary","text":""},{"location":"cpuspecifications/#cop0-register-summary_1","title":"COP0 Register Summary","text":" cop0r0-r2 - N/A\n cop0r3 - BPC - Breakpoint on execute (R/W)\n cop0r4 - N/A\n cop0r5 - BDA - Breakpoint on data access (R/W)\n cop0r6 - JUMPDEST - Randomly memorized jump address (R)\n cop0r7 - DCIC - Breakpoint control (R/W)\n cop0r8 - BadVaddr - Bad Virtual Address (R)\n cop0r9 - BDAM - Data Access breakpoint mask (R/W)\n cop0r10 - N/A\n cop0r11 - BPCM - Execute breakpoint mask (R/W)\n cop0r12 - SR - System status register (R/W)\n cop0r13 - CAUSE - Describes the most recently recognised exception (R)\n cop0r14 - EPC - Return Address from Trap (R)\n cop0r15 - PRID - Processor ID (R)\n cop0r16-r31 - Garbage\n cop0r32-r63 - N/A - None such (Control regs)\nDescribes the most recently recognised exception
0-1 - Not used (zero)\n 2-6 Excode Describes what kind of exception occured:\n 00h INT Interrupt\n 01h MOD Tlb modification (none such in PSX)\n 02h TLBL Tlb load (none such in PSX)\n 03h TLBS Tlb store (none such in PSX)\n 04h AdEL Address error, Data load or Instruction fetch\n 05h AdES Address error, Data store\n The address errors occur when attempting to read\n outside of KUseg in user mode and when the address\n is misaligned. (See also: BadVaddr register)\n 06h IBE Bus error on Instruction fetch\n 07h DBE Bus error on Data load/store\n 08h Syscall Generated unconditionally by syscall instruction\n 09h BP Breakpoint - break instruction\n 0Ah RI Reserved instruction\n 0Bh CpU Coprocessor unusable\n 0Ch Ov Arithmetic overflow\n 0Dh-1Fh Not used\n 7 - Not used (zero)\n 8-15 Ip Interrupt pending field. Bit 8 and 9 are R/W, and\n contain the last value written to them. As long\n as any of the bits are set they will cause an\n interrupt if the corresponding bit is set in IM.\n 16-27 - Not used (zero)\n 28-29 CE Contains the coprocessor number if the exception\n occurred because of a coprocessor instuction for\n a coprocessor which wasn't enabled in SR.\n 30 - Not used (zero)\n 31 BD Is set when last exception points to the\n branch instuction instead of the instruction\n in the branch delay slot, where the exception\n occurred.\n 0 IEc Current Interrupt Enable (0=Disable, 1=Enable) ;rfe pops IUp here\n 1 KUc Current Kernel/User Mode (0=Kernel, 1=User) ;rfe pops KUp here\n 2 IEp Previous Interrupt Enable ;rfe pops IUo here\n 3 KUp Previous Kernel/User Mode ;rfe pops KUo here\n 4 IEo Old Interrupt Enable ;left unchanged by rfe\n 5 KUo Old Kernel/User Mode ;left unchanged by rfe\n 6-7 - Not used (zero)\n 8-15 Im 8 bit interrupt mask fields. When set the corresponding\n interrupts are allowed to cause an exception.\n 16 Isc Isolate Cache (0=No, 1=Isolate)\n When isolated, all load and store operations are targetted\n to the Data cache, and never the main memory.\n (Used by PSX Kernel, in combination with Port FFFE0130h)\n 17 Swc Swapped cache mode (0=Normal, 1=Swapped)\n Instruction cache will act as Data cache and vice versa.\n Use only with Isc to access & invalidate Instr. cache entries.\n (Not used by PSX Kernel)\n 18 PZ When set cache parity bits are written as 0.\n 19 CM Shows the result of the last load operation with the D-cache\n isolated. It gets set if the cache really contained data\n for the addressed memory location.\n 20 PE Cache parity error (Does not cause exception)\n 21 TS TLB shutdown. Gets set if a programm address simultaneously\n matches 2 TLB entries.\n (initial value on reset allows to detect extended CPU version?)\n 22 BEV Boot exception vectors in RAM/ROM (0=RAM/KSEG0, 1=ROM/KSEG1)\n 23-24 - Not used (zero)\n 25 RE Reverse endianness (0=Normal endianness, 1=Reverse endianness)\n Reverses the byte order in which data is stored in\n memory. (lo-hi -> hi-lo)\n (Affects only user mode, not kernel mode) (?)\n (The bit doesn't exist in PSX ?)\n 26-27 - Not used (zero)\n 28 CU0 COP0 Enable (0=Enable only in Kernel Mode, 1=Kernel and User Mode)\n 29 CU1 COP1 Enable (0=Disable, 1=Enable) (none in PSX)\n 30 CU2 COP2 Enable (0=Disable, 1=Enable) (GTE in PSX)\n 31 CU3 COP3 Enable (0=Disable, 1=Enable) (none in PSX)\n 0-31 Return Address from Exception\nIf an interrupt occurs \"on\" a GTE command (cop2cmd), then the GTE command is executed, but nethertheless, the return address in EPC points to the GTE command. So, if the exeception handler would return to EPC as usually, then the GTE command would be executed twice. In best case, this would be a waste of clock cycles, in worst case it may lead to faulty result (if the results from the 1st execution are re-used as incoming parameters in the 2nd execution). To fix the problem, the exception handler must do:
if (cause AND 7Ch)=00h ;if excode=interrupt\n if ([epc] AND FE000000h)=4A000000h ;and opcode=cop2cmd\n epc=epc+4 ;then skip that opcode\nThe RFE opcode moves some bits in cop0r12 (SR): bit2-3 are copied to bit0-1, and bit4-5 are copied to bit2-3, all other bits (including bit4-5) are left unchanged. The RFE opcode does NOT automatically jump to EPC. Instead, the exception handler must copy EPC into a register (usually R26 aka K0), and then jump to that address. Because of branch delays, that would look like so:
mov k0,epc ;get return address\n push k0 ;save epc in memory (if you expect nested exceptions)\n ... ;whatever (ie. process CAUSE)\n pop k0 ;restore from memory (if you expect nested exceptions)\n jmp k0 ;jump to K0 (after executing the next opcode)\n +rfe ;move SR bit4/5 --> bit2/3 --> bit0/1\nContains the address whose reference caused an exception. Set on any MMU type of exceptions, on references outside of kuseg (in User mode) and on any misaligned reference. BadVaddr is updated ONLY by Address errors (Excode 04h and 05h), all other exceptions (including bus errors) leave BadVaddr unchanged.
"},{"location":"cpuspecifications/#exception-vectors-depending-on-bev-bit-in-sr-register","title":"Exception Vectors (depending on BEV bit in SR register)","text":" Exception BEV=0 BEV=1\n Reset BFC00000h BFC00000h (Reset)\n UTLB Miss 80000000h BFC00100h (Virtual memory, none such in PSX)\n COP0 Break 80000040h BFC00140h (Debug Break)\n General 80000080h BFC00180h (General Interrupts & Exceptions)\n Reset At any time (highest) ;-reset\n AdEL Memory (Load instruction) ;\\\n AdES Memory (Store instruction) ; memory (data load/store)\n DBE Memory (Load or store) ;/\n MOD ALU (Data TLB) ;\\\n TLBL ALU (DTLB Miss) ; none such\n TLBS ALU (DTLB Miss) ;/\n Ovf ALU ;-overflow\n Int ALU ;-interrupt\n Sys RD (Instruction Decode) ;\\\n Bp RD (Instruction Decode) ;\n RI RD (Instruction Decode) ;\n CpU RD (Instruction Decode) ;/\n TLBL I-Fetch (ITLB Miss) ;-none such\n AdEL IVA (Instruction Virtual Address) ;\\memory (opcode fetch)\n IBE RD (end of I-Fetch, lowest) ;/\n 0-7 Revision\n 8-15 Implementation\n 16-31 Not used\nThe is a rather strange totally useless register. After certain exceptions, the CPU does memorize a jump destination address in the register. Once when it has memorized an address, the register becomes locked, and the memorized value won't change until it becomes unlocked by a new exception. Exceptions that do unlock the register are Reset and Interrupts (cause.bit10). Exceptions that do NOT unlock the register are syscall/break opcodes, and software generated interrupts (eg. cause.bit8). In the unlocked state, the CPU does more or less randomly memorize one of the next some jump destinations - eg. the destination from the second jump after reset, or from a jump that occured immediately before executing the IRQ handler, or from a jump inside of the IRQ handler, or even from a later jump that occurs shortly after returning from the IRQ handler. The register seems to be read-only (although the Kernel initialization code writes 0 to it for whatever reason).
"},{"location":"cpuspecifications/#cop0r0r2-cop0r4-cop0r10-cop0r32r63-na","title":"cop0r0..r2, cop0r4, cop0r10, cop0r32..r63 - N/A","text":"Registers 0,1,2,4,10 control virtual memory on some MIPS processors (but there's none such in the PSX), and Registers 32..63 (aka \"control registers\") aren't used in any MIPS processors. Trying to read any of these registers causes a Reserved Instruction Exception (excode=0Ah).
"},{"location":"cpuspecifications/#cop0cmd01h02h06h08h-tlbrtlbwitlbwrtlbp","title":"cop0cmd=01h,02h,06h,08h - TLBR,TLBWI,TLBWR,TLBP","text":"The PSX supports only one cop0cmd (cop0cmd=10h aka RFE). Trying to execute the TLBxx opcodes causes a Reserved Instruction Exception (excode=0Ah).
"},{"location":"cpuspecifications/#jfjt-cop0flgdest-conditional-cop0-jumps","title":"jf/jt cop0flg,dest - conditional cop0 jumps","text":""},{"location":"cpuspecifications/#mov-memcop0reg-mov-cop0regmem-coprocessor-cop0-loadstore","title":"mov [mem],cop0reg / mov cop0reg,[mem] - coprocessor cop0 load/store","text":"Not supported by the CPU. Trying to execute these opcodes causes a Coprocessor Unusable Exception (excode=0Bh, ie. unlike above, not 0Ah).
"},{"location":"cpuspecifications/#cop0r16-r31-garbage","title":"cop0r16-r31 - Garbage","text":"Trying to read these registers returns garbage (but does not trigger an exception). When reading one of the garbage registers shortly after reading a valid cop0 register, the garbage value is usually the same as that of the valid register. When doing the read later on, the return value is usually 00000020h, or when reading much later it returns 00000040h, or even 00000100h. No idea what is causing that effect...? Note: The garbage registers can be accessed (without causing an exception) even in \"User mode with cop0 disabled\" (SR.Bit1=1 and SR.Bit28=0); accessing any other existing cop0 registers (or executing the rfe opcode) in that state is causing Coprocessor Unusable Exceptions (excode=0Bh).
"},{"location":"cpuspecifications/#cop0-debug-registers","title":"COP0 - Debug Registers","text":"The COP0 debug registers seem to be PSX specific, normal R30xx CPUs like IDT's R3041 and R3051 don't have anything similar.
"},{"location":"cpuspecifications/#cop0r7-dcic-breakpoint-control-rw","title":"cop0r7 - DCIC - Breakpoint control (R/W)","text":" 0 Automatically set by hardware upon Any break (R/W)\n 1 Automatically set by hardware upon BPC Code break (R/W)\n 2 Automatically set by hardware upon BDA Data break (R/W)\n 3 Automatically set by hardware upon BDA Data-Read break (R/W)\n 4 Automatically set by hardware upon BDA Data-Write break (R/W)\n 5 Automatically set by hardware upon any-jump break (R/W)\n 6-11 Not used (always zero)\n 12-13 Jump Redirection (0=Disable, 1..3=Enable) (see note) (R/W)\n 14-15 Unknown? (R/W)\n 16-22 Not used (always zero)\n 23 Super-Master Enable 1 for bit24-29\n 24 Execution breakpoint (0=Disabled, 1=Enabled) (see BPC, BPCM)\n 25 Data access breakpoint (0=Disabled, 1=Enabled) (see BDA, BDAM)\n 26 Break on Data-Read (0=No, 1=Break/when Bit25=1)\n 27 Break on Data-Write (0=No, 1=Break/when Bit25=1)\n 28 Break on any-jump (0=No, 1=Break on branch/jump/call/etc.)\n 29 Master Enable for bit28 (..and/or exec-break at address>=80000000h?)\n 30 Master Enable for bit24-27\n 31 Super-Master Enable 2 for bit24-29\nIf one or both of these bits are nonzero, then the PSX seems to check for the following opcode sequence,
mov rx,[mem] ;load rx from memory\n ... ;one or more opcodes that do not change rx\n jmp/call rx ;jump or call to rx\nBreak condition is \"((addr XOR BDA) AND BDAM)=0\".
"},{"location":"cpuspecifications/#cop0r3-bpc-breakpoint-on-execute-address-rw","title":"cop0r3 - BPC - Breakpoint on Execute Address (R/W)","text":""},{"location":"cpuspecifications/#cop0r11-bpcm-breakpoint-on-execute-mask-rw","title":"cop0r11 - BPCM - Breakpoint on Execute Mask (R/W)","text":"Break condition is \"((PC XOR BPC) AND BPCM)=0\".
"},{"location":"cpuspecifications/#note-break-opcode","title":"Note (BREAK Opcode)","text":"Additionally, the BREAK opcode can be used to create further breakpoints by patching the executable code. The BREAK opcode uses the same Excode value (09h) in CAUSE register. However, the BREAK opcode jumps to the normal exception handler at 80000080h (not 80000040h).
"},{"location":"cpuspecifications/#note-libcrypt","title":"Note (LibCrypt)","text":"The debug registers are mis-used by \"Legacy of Kain: Soul Reaver\" (and maybe also other games) for storing libcrypt copy-protection related values (ie. just as a \"hidden\" location for storing data, not for actual debugging purposes). CDROM Protection - LibCrypt
"},{"location":"cpuspecifications/#note-cheat-devicesexpansion-roms","title":"Note (Cheat Devices/Expansion ROMs)","text":"The Expansion ROM header supports only Pre-Boot and Post-Boot vectors, but no Mid-Boot vector. Cheat Devices are often using COP0 breaks for Mid-Boot Hooks, either with BPC=BFC06xxxh (break address in ROM, used in older cheat firmwares), or with BPC=80030000h (break address in RAM aka relocated GUI entrypoint, used in later cheat firmwares). Moreover, aside from the Mid-Boot Hook, the Xplorer cheat device is also supporting a special cheat code that uses the COP0 break feature.
"},{"location":"cpuspecifications/#note-datasheet","title":"Note (Datasheet)","text":"Note: COP0 debug registers are described in LSI's \"L64360\" datasheet, chapter 14. And in their LR33300/LR33310 datasheet, chapter 4.
"},{"location":"dmachannels/","title":"DMA Channels","text":""},{"location":"dmachannels/#dma-register-summary","title":"DMA Register Summary","text":" 1F80108xh DMA0 channel 0 MDECin (RAM to MDEC)\n 1F80109xh DMA1 channel 1 MDECout (MDEC to RAM)\n 1F8010Axh DMA2 channel 2 GPU (lists + image data)\n 1F8010Bxh DMA3 channel 3 CDROM (CDROM to RAM)\n 1F8010Cxh DMA4 channel 4 SPU\n 1F8010Dxh DMA5 channel 5 PIO (Expansion Port)\n 1F8010Exh DMA6 channel 6 OTC (reverse clear OT) (GPU related)\n 1F8010F0h DPCR - DMA Control register\n 1F8010F4h DICR - DMA Interrupt register\n 0-23 Memory Address where the DMA will start reading from/writing to\n 24-31 Not used (always zero)\nFor SyncMode=0 (ie. for OTC and CDROM):
0-15 BC Number of words (0001h..FFFFh) (or 0=10000h words)\n 16-31 0 Not used (usually 0 for OTC, or 1 (\"one block\") for CDROM)\n 0-15 BS Blocksize (words) ;for GPU/SPU max 10h, for MDEC max 20h\n 16-31 BA Amount of blocks ;ie. total length = BS*BA words\n 0-31 0 Not used (should be zero) (transfer ends at END-CODE in list)\n 0 Transfer direction (0=device to RAM, 1=RAM to device)\n 1 MADR increment per step (0=+4, 1=-4)\n 2-7 Unused\n 8 When 1:\n -Burst mode: enable \"chopping\" (cycle stealing by CPU)\n -Slice mode: Causes DMA to hang\n -Linked-list mode: Transfer header before data?\n 9-10 Transfer mode (SyncMode)\n 0=Burst (transfer data all at once after DREQ is first asserted)\n 1=Slice (split data into blocks, transfer next block whenever DREQ is asserted)\n 2=Linked-list mode\n 3=Reserved\n 11-15 Unused\n 16-18 Chopping DMA window size (1 << N words)\n 19 Unused\n 20-22 Chopping CPU window size (1 << N cycles)\n 23 Unused\n 24 Start transfer (0=stopped/completed, 1=start/busy)\n 25-27 Unused\n 28 Force transfer start without waiting for DREQ\n 29 In forced-burst mode, pauses transfer while set.\n In other modes, stops bit 28 from being cleared after a slice is transferred.\n No effect when transfer was caused by a DREQ.\n 30 Perform bus snooping (allows DMA to read from -nonexistent- cache?)\n 31 Unused\n 0-2 DMA0, MDECin Priority (0..7; 0=Highest, 7=Lowest)\n 3 DMA0, MDECin Master Enable (0=Disable, 1=Enable)\n 4-6 DMA1, MDECout Priority (0..7; 0=Highest, 7=Lowest)\n 7 DMA1, MDECout Master Enable (0=Disable, 1=Enable)\n 8-10 DMA2, GPU Priority (0..7; 0=Highest, 7=Lowest)\n 11 DMA2, GPU Master Enable (0=Disable, 1=Enable)\n 12-14 DMA3, CDROM Priority (0..7; 0=Highest, 7=Lowest)\n 15 DMA3, CDROM Master Enable (0=Disable, 1=Enable)\n 16-18 DMA4, SPU Priority (0..7; 0=Highest, 7=Lowest)\n 19 DMA4, SPU Master Enable (0=Disable, 1=Enable)\n 20-22 DMA5, PIO Priority (0..7; 0=Highest, 7=Lowest)\n 23 DMA5, PIO Master Enable (0=Disable, 1=Enable)\n 24-26 DMA6, OTC Priority (0..7; 0=Highest, 7=Lowest)\n 27 DMA6, OTC Master Enable (0=Disable, 1=Enable)\n 28-30 CPU memory access priority (0..7; 0=Highest, 7=Lowest)\n 31 No effect, should be CPU memory access enable (R/W)\n 0-6 Controls channel 0-6 completion interrupts in bits 24-30.\n When 0, an interrupt only occurs when the entire transfer completes.\n When 1, interrupts can occur for every slice and linked-list transfer.\n No effect if the interrupt is masked by bits 16-22.\n 7-14 Unused\n 15 Bus error flag. Raised when transferring to/from an address outside of RAM. Forces bit 31. (R/W)\n 16-22 Channel 0-6 interrupt mask. If enabled, channels cause interrupts as per bits 0-6.\n 23 Master channel interrupt enable.\n 24-30 Channel 0-6 interrupt flags. (R, write 1 to reset)\n 31 Master interrupt flag (R)\n IF b15=1 OR (b23=1 AND (b16-22 AND b24-30)>0) THEN b31=1 ELSE b31=0\n (changes to 7FE358D1h after DMA transfer)\n (stays so even after DMA transfer)\n DMA0 MDEC.IN 01000201h (always)\n DMA1 MDEC.OUT 01000200h (always)\n DMA2 GPU 01000200h (VramRead), 01000201h (VramWrite), 01000401h (List)\n DMA3 CDROM 11000000h (normal), 11400100h (chopped, rarely used)\n DMA4 SPU 01000201h (write), 01000200h (read, rarely used)\n DMA5 PIO 11150100h (System 573 ATAPI read), ? (System 573 ATAPI write)\n DMA6 OTC 11000002h (always)\nGPU commands are usually sent from RAM to GP0 using DMA2 in linked list mode. In this mode, the DMA controller transfers words in \"nodes\", with the first node starting in the address indicated by D2_MADR. Each node is composed of a header word (the very first word in the node) and some extra words to be DMA'd before moving on to the next node. The node header is formatted like this:
0-23 Address of the next node (or end marker)\n 24-31 Number of extra words to transfer for this node\nThe transfer is stopped once an end marker is reached. On some (earlier?) CPU revisions any address with bit 23 set will be interpreted as an end marker, while on other revisions all bits must be set (i.e. the address must be FFFFFF). This change was probably necessary as later CPU versions added support for up to 16 MB RAM addressing, which made addresses in the 800000-FFFFFC range valid.
"},{"location":"dmachannels/#dma-transfer-rates","title":"DMA Transfer Rates","text":" DMA0 MDEC.IN 1 clk/word ;0110h clks per 100h words ;\\plus whatever\n DMA1 MDEC.OUT 1 clk/word ;0110h clks per 100h words ;/decompression time\n DMA2 GPU 1 clk/word ;0110h clks per 100h words ;-plus ...\n DMA3 CDROM/BIOS 24 clks/word ;1800h clks per 100h words ;\\plus single/double\n DMA3 CDROM/GAMES 40 clks/word ;2800h clks per 100h words ;/speed sector rate\n DMA4 SPU 4 clks/word ;0420h clks per 100h words ;-plus ...\n DMA5 PIO 20 clks/word ;1400h clks per 100h words ;-not actually used\n DMA6 OTC 1 clk/word ;0110h clks per 100h words ;-plus nothing\nDMA is using DRAM Hyper Page mode, allowing it to access DRAM rows at 1 clock cycle per word (effectively around 17 clks per 16 words, due to required row address loading, probably plus some further minimal overload due to refresh cycles). This is making DMA much faster than CPU memory accesses (CPU DRAM access takes 1 opcode cycle plus 6 waitstates, ie. 7 cycles in total)
"},{"location":"dmachannels/#cpu-operation-during-dma","title":"CPU Operation during DMA","text":"CPU is running during DMA within very strict rules. It can be kept running when accessing only cache, scratchpad, COP0 and GTE. It can also make use of the 4 entry Write queue for both RAM and I/O registers, see: Write queue Any read access from RAM or I/O registers or filling more than 4 entries into the write queue will stall the CPU until the DMA is finished. Additionally, the CPU operation resumes during periods when DMA gets interrupted (ie. after SyncMode 1 blocks, after SyncMode 2 list entries) (or in SyncMode 0 with Chopping enabled).
"},{"location":"dmachannels/#ps2-iop-dma","title":"PS2 IOP DMA","text":"The PS2's IOP has an extended DMA unit with more channels, new control registers and an additional chain mode (SyncMode=3). For more details, see: ps2tek - IOP DMA
"},{"location":"expansionportpio/","title":"Expansion Port (PIO)","text":"Expansion Port can contain ROM, RAM, I/O Ports, etc. For ROM, the first 256 bytes would contain the expansion ROM header.
For region 1, the CPU outputs a chip select signal (CPU Pin 98, /EXP). For region 2, the CPU doesn't produce a chip select signal (the region is intended to contain multiple I/O ports, which require an address decoder anyways, that address decoder could treat any /RD or /WR with A13=Hi and A23=Hi and A22=Lo as access to expansion region 2 (for /WR, A22 may be ignored; assuming that the BIOS is read-only).
"},{"location":"expansionportpio/#sizebus-width","title":"Size/Bus-Width","text":"The BIOS initalizes Expansion Region 1 to 512Kbyte with 8bit bus, and Region 2 to 128 bytes with 8bit bus. However, the size and data bus-width of these regions can be changed, see: Memory Control For Region 1, 32bit reads are supported even in 8bit mode (eg. 32bit opcode fetches are automatically processed as four 8bit reads). For Region 2, only 8bit access seems to be supported (except that probably 16bit mode allows 16bit access), anyways, larger accesses seem to cause exceptions... not sure if that can be disabled...?
"},{"location":"expansionportpio/#expansion-1-exp1-intended-to-contain-rom","title":"Expansion 1 - EXP1 - Intended to contain ROM","text":"EXP1 Expansion ROM Header
"},{"location":"expansionportpio/#expansion-2-exp2-intended-to-contain-io-ports","title":"Expansion 2 - EXP2 - Intended to contain I/O Ports","text":"EXP2 Dual Serial Port (for TTY Debug Terminal) EXP2 DTL-H2000 I/O Ports EXP2 Post Registers EXP2 Nocash Emulation Expansion
"},{"location":"expansionportpio/#expansion-3-exp3-intended-to-contain-ram","title":"Expansion 3 - EXP3 - Intended to contain RAM","text":"Not used by BIOS nor by any games. Seems to contain 1Mbyte RAM with 16bit databus (ie. 512Kx16) in DTL-H2000.
"},{"location":"expansionportpio/#other-expansions","title":"Other Expansions","text":"Aside from the above, the Expansion regions can be used for whatever purpose, however, mind that the BIOS is reading from the ROM header region, and is writing to the POST register (so 1F000000h-1F0000FFh and 1F802041h should be used only if the hardware isn't disturbed by those accesses). Most arcade boards have their custom I/O registers (and sometimes game ROMs) mapped into the EXP1 and/or EXP2 regions.
"},{"location":"expansionportpio/#missing-expansion-port","title":"Missing Expansion Port","text":"The expansion port is installed only on older PSX boards, newer PSX boards and all PSone boards don't have that port. However, the CPU should still output all expansion signals, and there should be big soldering points on the board, so it'd be easy to upgrade the console.
"},{"location":"expansionportpio/#latched-address-bus","title":"Latched Address Bus","text":"Note that A0..A23 are latched outputs, so they can be used as general purpuse 24bit outputs, provided that the system bus isn't used for other purposes (such like /BIOS, /SPU, /CD accesses) (A0..A23 are not affected by Main RAM and GPU addressing, nor by internal I/O ports like Timer and IRQ registers).
"},{"location":"expansionportpio/#exp1-expansion-rom-header","title":"EXP1 Expansion ROM Header","text":""},{"location":"expansionportpio/#expansion-1-rom-header-accessed-with-8bit-databus-setting","title":"Expansion 1 - ROM Header (accessed with 8bit databus setting)","text":" Address Size Content\n 1F000000h 4 Post-Boot Entrypoint (eg. 1F000100h and up)\n 1F000004h 2Ch Post-Boot ID (\"Licensed by Sony Computer Entertainment Inc.\")\n 1F000030h 50h Post-Boot TTY Message (must contain at least one 00h byte)\n 1F000080h 4 Pre-Boot Entrypoint (eg. 1F000100h and up)\n 1F000084h 2Ch Pre-Boot ID (\"Licensed by Sony Computer Entertainment Inc.\")\n 1F0000B0h 50h Not used (should be zero, but may contain code/data/io)\n 1F000100h .. Code, Data, I/O Ports, etc.\nThe Pre-Boot function is called almost immediately after Reset, with only some Memory Control registers initialized, the BIOS function vectors at A0h, B0h, and C0h are NOT yet initialized, so the Pre-Boot function can't use them.
"},{"location":"expansionportpio/#post-boot-function","title":"Post-Boot Function","text":"The Post-Boot function gets called while showing the \"PS\" logo, but before loading the .EXE file. The BIOS function vectors at A0h, B0h, and C0h are already installed and can be used by the Post-Boot Function. Note that the Post-Boot Function is called ONLY when the \"PS\" logo is shown (ie. not if the CDROM drive is empty, or if it contains an Audio CD).
"},{"location":"expansionportpio/#mid-boot-hook","title":"Mid-Boot Hook","text":"One common trick to hook the Kernel after BIOS initialization, but before CDROM loading is to use the Pre-Boot handler to set a COP0 opcode fetch hardware breakpoint at 80030000h (after returning from the Pre-Boot handler, the Kernel will initialize important things like A0h/B0h/C0h tables, and will then break again when starting the GUI code at 80030000h) (this trick is used by Action Replay v2.0 and up).
"},{"location":"expansionportpio/#note","title":"Note","text":"Expansion ROMs are most commonly used in cheat devices, Cheat Devices
"},{"location":"expansionportpio/#exp2-dual-serial-port-for-tty-debug-terminal","title":"EXP2 Dual Serial Port (for TTY Debug Terminal)","text":""},{"location":"expansionportpio/#scn2681-dual-asynchronous-receivertransmitter-duart","title":"SCN2681 Dual Asynchronous Receiver/Transmitter (DUART)","text":"The PSX/PSone retail BIOS contains some TTY Debug Terminal code; using an external SCN2681 chip which can be connected to the expansion port. Whilst supported by all PSX/PSone retail BIOSes on software side, there aren't any known PSX consoles/devboards/expansions actually containing DUARTs on hardware side.
"},{"location":"expansionportpio/#1f802023hread-rhra-duart-rx-holding-register-a-fifo-r","title":"1F802023h/Read - RHRA - DUART Rx Holding Register A (FIFO) (R)","text":""},{"location":"expansionportpio/#1f80202bhread-rhrb-duart-rx-holding-register-b-fifo-r","title":"1F80202Bh/Read - RHRB - DUART Rx Holding Register B (FIFO) (R)","text":""},{"location":"expansionportpio/#1f802023hwrite-thra-duart-tx-holding-register-a-w","title":"1F802023h/Write - THRA - DUART Tx Holding Register A (W)","text":""},{"location":"expansionportpio/#1f80202bhwrite-thrb-duart-tx-holding-register-b-w","title":"1F80202Bh/Write - THRB - DUART Tx Holding Register B (W)","text":" 7-0 Data (aka Character)\n 7 RxRTS Control (0=No, 1=Yes)\n 6 RxINT Select (0=RxRDY, 1=FFULL)\n 5 Error Mode (0=Char, 1=Block)\n 4-3 Parity Mode (0=With Parity, 1=Force Parity, 2=No Parity, 3=Multidrop)\n 2 Parity Type (0=Even, 1=Odd)\n 1-0 Bits per Character (0=5bit, 1=6bit, 2=7bit, 3=8bit)\n 7-6 Channel Mode (0=Normal, 1=Auto-Echo, 2=Local loop, 3=Remote loop)\n 5 TxRTS Control (0=No, 1=Yes) (when 1 --> OP0=RTSA / OP1=RTSB)\n 4 CTS Enable (0=No, 1=Yes) (when 1 --> IP0=CTSA / IP1=CTSB)\n 3-0 Tx Stop Bit Length (00h..0Fh = see below)\n 0=0.563 1=0.625 2=0.688 3=0.750 4=0.813 5=0.875 6=0.938 7=1.000\n 8=1.563 9=1.625 A=1.688 B=1.750 C=1.813 D=1.875 E=1.938 F=2.000\n 7-4 Rx Clock Select (0..0Ch=See Table, 0Dh=Timer, 0Eh=16xIP, 0Fh=1xIP)\n 3-0 Tx Clock Select (0..0Ch=See Table, 0Dh=Timer, 0Eh=16xIP, 0Fh=1xIP)\n Rate 00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch\n Set1 50 110 134.5 200 300 600 1200 1050 2400 4800 7200 9600 38400\n Set2 75 110 134.5 150 300 600 1200 2000 2400 4800 1800 9600 19200\n Set3 4800 880 1076 19200 28800 57600 115200 1050 57600 4800 57600 9600 38400\n Set4 7200 880 1076 14400 28800 57600 115200 2000 57600 4800 14400 9600 19200\n 7 Not used (should be 0)\n 6-4 Miscellaneous Commands (0..7 = see below)\n 3 Disable Tx (0=No change, 1=Disable)\n 2 Enable Tx (0=No change, 1=Enable) ;Don't use with Command 3 (Reset Rx)\n 1 Disable Rx (0=No change, 1=Disable)\n 0 Enable Rx (0=No change, 1=Enable) ;Don't use with Command 2 (Reset Tx)\n 0 No command ;no effect\n 1 Reset MR pointer ;force \"FirstAccess\" state for MR1A (or MR1B) access\n 2 Reset receiver ;reset RxA (or RxB) registers, disable Rx, flush Fifo\n 3 Reset transmitter ;reset TxA (or TxB) registers\n 4 Reset Error Flags ;reset SRA.7-4 (or SRB.7-4) to zero\n 5 Reset Break-Change IRQ Flag ;reset ISR.2 (or ISR.6) to zero\n 6 Start break ;after current char, pause Tx with TxDA=Low (or TxDB=Low)\n 7 Stop break ;output one High bit, then continue Tx (ie. undo pause)\n 7 Input Port Change (0=No, 1=Yes) (Ack via reading IPCR) ;see ACR.3-0\n 6 Break Change B (0=No, 1=Yes) (Ack via CRB/Command5)\n 5 RxRDYB/FFULLB (0=No, 1=Yes) (Ack via reading data) ;see MR1B.6\n 4 THRB Empty (TxRDYB) (0=No, 1=Yes) (Ack via writing data) ;same as SRB.2\n 3 Counter Ready (0=No, 1=Yes) (Ack via CT_STOP)\n 2 Break Change A (0=No, 1=Yes) (Ack via CRA/Command5)\n 1 RxRDYA/FFULLA (0=No, 1=Yes) (Ack via reading data) ;see MR1A.6\n 0 THRA Empty (TxRDYA) (0=No, 1=Yes) (Ack via writing data) ;same as SRA.2\n 7 Rx Received Break* (0=No, 1=Yes) ;received 00h without stop bit\n 6 Rx Framing Error* (0=No, 1=Yes) ;received data without stop bit\n 5 Rx Parity Error* (0=No, 1=Yes) ;received data with bad parity\n 4 Rx Overrun Error (0=No, 1=Yes) ;Rx FIFO full + RxShiftReg full\n 3 Tx Underrun (TxEMT) (0=No, 1=Yes) ;both TxShiftReg and THR empty\n 2 Tx THR Empty (TxRDY) (0=No, 1=Yes) ;same as ISR.0 / ISR.4\n 1 Rx FIFO Full (FFULL) (0=No, 1=Yes) ;set upon 3 or more characters\n 0 Rx FIFO Not Empty (RxRDY) (0=No, 1=Yes) ;set upon 1 or more characters\n 7 Select Baud Rate Generator (BRG) Set (0=Set1/Set3, 1=Set2/Set4)\n 6-4 Counter/Timer Mode and Source (see below)\n 3-0 IP3..IP0 Change Interrupt Enable Flags (0=Off, 1=On)\n Num Mode Clock Source\n 0h Counter External (IP2)\n 1h Counter TxCA - 1x clock of Channel A transmitter\n 2h Counter TxCB - 1x clock of Channel B transmitter\n 3h Counter Crystal or external clock (x1/CLK) divided by 16\n 4h Timer External (IP2)\n 5h Timer External (IP2) divided by 16\n 6h Timer Crystal or external clock (x1/CLK)\n 7h Timer Crystal or external clock (x1/CLK) divided by 16\n 7-4 IP3..IP0 Change Occured Flags (0=No, 1=Yes) ;auto reset after read\n 3-0 Current IP3-IP0 Input states (0=Low, 1=High) ;Same as IP.3-0\n 7 Not used (always 1)\n 6-0 Current IP6-IP0 Input states (0=Low, 1=High) ;LSBs = Same as IPCR.3-0\n IP6 External RxB Clock ;see CSRB.7-4\n IP5 External TxB Clock ;see CSRB.3-0\n IP4 External RxA Clock ;see CSRA.7-4\n IP3 External TxA Clock ;see CSRA.3-0\n IP2 External Timer Input ;see AUX.6-4\n IP1 Clear to Send B (CTSB) ;see MR2B.5\n IP0 Clear to Send A (CTSA) ;see MR2A.5\n 7-0 Change \"OPR\" OP7-OP0 Output states (0=No change, 1=Set/Reset)\n 7 OP7 (0=OPR.7, 1=TxRDYB)\n 6 OP6 (0=OPR.6, 1=TxRDYA)\n 5 OP5 (0=OPR.5, 1=RxRDY/FFULLB)\n 4 OP4 (0=OPR.4, 1=RxRDY/FFULLA)\n 3-2 OP3 (0=OPR.3, 1=Clock/Timer Output, 2=TxCB(1x), 3=RxCB(1x))\n 1-0 OP2 (0=OPR.2, 1=TxCA(16x), 2=TxCA(1x), 3=RxCA(1x))\n 7-0 Not used (just issue a dummy-read to toggle the test mode on/off)\n 7-0 Not used (just issue a dummy-read to strobe start/stop command)\nThe CTLR/CTUR reload value is copied to CTL/CTU upon Start Counter Command. In Timer mode (not in Counter mode), it is additionally copied automatically when the timer undeflows.
"},{"location":"expansionportpio/#1f80202ch-na-duart-reserved-register-neither-r-nor-w","title":"1F80202Ch - N/A - DUART Reserved Register (neither R nor W)","text":"Reserved.
"},{"location":"expansionportpio/#chip-versions","title":"Chip versions","text":"The SCN2681 is manufactured with 24..44 pins, the differences are:
24pin basic cut-down version ;without IP0-1/OP0-1 = without CTS/RTS\n 28pin additional IP2,OP0,OP1,X2 ;without IP0-1 = without CTS\n 40pin additional IP0-IP6,OP0-OP7,X2 ;full version\n 44pin same as 40pin with four NC pins ;full version (SMD)\nUnknown if the Interrupt signal is connected to the PSX... there seems to be no spare IRQ for it, though it \\<might> share an IRQ with whatever other hardware...? The BIOS seems to use only one of the two channels; for the std_io functions: BIOS TTY Console (std_io) Aside from the external DUART, the PSX additionally contains an internal UART, Serial Interfaces (SIO) The DTL-H2000 devboard uses a non-serial \"ATCONS\" channel for TTY stuff, EXP2 DTL-H2000 I/O Ports
"},{"location":"expansionportpio/#exp2-dtl-h2000-io-ports","title":"EXP2 DTL-H2000 I/O Ports","text":"The DTL-H2000 contains extended 8Mbyte Main RAM (instead of normal 2Mbyte), plus additional 1MByte RAM in Expansion Area at 1FA00000h, plus some I/O ports at 1F8020xxh:
"},{"location":"expansionportpio/#1f802000h-dtl-h2000-exp2-atcons-stat-r","title":"1F802000h - DTL-H2000: EXP2: - ATCONS STAT (R)","text":" 0 Unknown, used for something\n 1 Unknown/unused\n 2 Unknown, used for something\n 3 TTY/Atcons TX Ready (0=Busy, 1=Ready)\n 4 TTY/Atcons RX Available (0=None, 1=Yes)\n 5-7 Unknown/unused\n 0-7 TTY/Atcons RX/TX Data\n 0-15 Data...?\nThis register does expand IRQ10 (Lightgun) to more than one IRQ source. The register contains only Secondary IRQ Flags (there seem to be no Secondary IRQ Enable bits; at least not for Lightguns).
0 ... used for something\n 1 Lightgun IRQ (write: 0=No change, 1=Acknowledge) (read: 0=None, 1=IRQ)\n 2-3 Unknown/unused (write: 0=Normal)\n 4 ... acknowledged at 1FA00B04h, otherwise unused\n 5 ... TTY RX ?\n 6-7 Unknown/unused (write: 0=Normal)\n 8-31 Not used by DTL-H2000 BIOS (but Lightgun games write 0 to these bits)\n IF [BFC00104h]=00002000h then Port 1F802030h does exist (DTL-H2000)\n IF [BFC00104h]=00002500h then Port 1F802030h does NOT exist\n IF [BFC00104h]=00000003h then Port 1F802030h does NOT exist (default)\n IF [BFC00104h]= <other> then Port 1F802030h does NOT exist\n 0 Used for something (CLEARED on some occassions)\n 1-3 Unknown/unused\n 4 Used for something (SET on some occassions)\n 5-7 Unknown/unused\n 0-7 DIP Value (00h..FFh, but should be usually 00h..02h)\n DIP=0 --> .. long delay before TTY? with \"PSX>\" prompt, throws CDROM cmds\n DIP=1 --> .. long delay before TTY? no \"PSX>\" prompt PSY-Q?\n DIP=2 --> .. instant TTY? with \"PSX>\" prompt\n DIP=3 --> Lockup\n DIP=04h..FFh --> Lockup with POST=04h..FFh\nEXP2 Post Registers
"},{"location":"expansionportpio/#exp2-post-registers","title":"EXP2 Post Registers","text":""},{"location":"expansionportpio/#1f802041h-post-external-7-segment-display-w","title":"1F802041h - POST - External 7-segment Display (W)","text":" 0-3 Current Boot Status (00h..0Fh)\n 4-7 Not used by BIOS (always set to 0)\n 0-7 Post/LED value\nMight be a configuration port, or it's another POST register (which is used prior to writing the normal POST bytes to 1FA00000h). The first write to 1F802070h is 32bit, all further writes seem to be 8bit.
"},{"location":"expansionportpio/#1fa00000h-post3-external-7-segment-display-w-ps2","title":"1FA00000h - POST3 - External 7-segment Display (W) - PS2","text":"Similar to POST, but PS2 BIOS uses this address.
"},{"location":"expansionportpio/#exp2-nocash-emulation-expansion","title":"EXP2 Nocash Emulation Expansion","text":""},{"location":"expansionportpio/#1f802060h-emu-expansion-id1-e-r","title":"1F802060h Emu-Expansion ID1 \"E\" (R)","text":""},{"location":"expansionportpio/#1f802061h-emu-expansion-id2-x-r","title":"1F802061h Emu-Expansion ID2 \"X\" (R)","text":""},{"location":"expansionportpio/#1f802062h-emu-expansion-id3-p-r","title":"1F802062h Emu-Expansion ID3 \"P\" (R)","text":""},{"location":"expansionportpio/#1f802063h-emu-expansion-version-01h-r","title":"1F802063h Emu-Expansion Version (01h) (R)","text":"Contains ID and Version.
"},{"location":"expansionportpio/#1f802064h-emu-expansion-enable1-o-rw","title":"1F802064h Emu-Expansion Enable1 \"O\" (R/W)","text":""},{"location":"expansionportpio/#1f802065h-emu-expansion-enable2-n-rw","title":"1F802065h Emu-Expansion Enable2 \"N\" (R/W)","text":"Activates the Halt and Turbo Registers (when set to \"ON\").
"},{"location":"expansionportpio/#1f802066h-emu-expansion-halt-r","title":"1F802066h Emu-Expansion Halt (R)","text":"When enabled (see above), doing an 8bit read from this address stops the CPU emulation unless/until an Interrupt occurs (when \"CAUSE AND SR AND FF00h\" becomes nonzero). Can be used to reduce power consumption, and to make the emulation faster.
"},{"location":"expansionportpio/#1f802067h-emu-expansion-turbo-mode-flags-rw","title":"1F802067h Emu-Expansion Turbo Mode Flags (R/W)","text":"When enabled (see above), writing to this register activates/deactivates \"turbo\" mode, which is causing new data to arrive immediately after acknowledging the previous interrupt.
0 CDROM Turbo (0=Normal, 1=Turbo)\n 1 Memory Card Turbo (0=Normal, 1=Turbo)\n 2 Controller Turbo (0=Normal, 1=Turbo)\n 3-7 Reserved (must be zero)\nPCSX-Redux contains some specific hardware registers for the purpose of testing and debugging. They are located past the 1F802080h address, which means that accessing them on the real hardware will cause an exception, unless the 1F80101Ch register has been set to be at least twice its normal size.
"},{"location":"expansionportpio/#1f802080h-4-redux-expansion-id-pcsx-r","title":"1F802080h 4 Redux-Expansion ID \"PCSX\" (R)","text":"Identification string. Use this to query that your binary is running under PCSX-Redux.
"},{"location":"expansionportpio/#1f802080h-1-redux-expansion-console-putchar-w","title":"1F802080h 1 Redux-Expansion Console putchar (W)","text":"Adds this character to the console output. This is an easier way to write to the console than using the BIOS.
"},{"location":"expansionportpio/#1f802081h-1-redux-expansion-debug-break-w","title":"1F802081h 1 Redux-Expansion Debug break (W)","text":"Causes a debug breakpoint to be triggered. PCSX-Redux will pause and the user will be alerted of a software breakpoint.
"},{"location":"expansionportpio/#1f802082h-1-redux-expansion-exit-code-w","title":"1F802082h 1 Redux-Expansion Exit code (W)","text":"Sets the exit code for the program. When in test mode, PCSX-Redux will exit with this code.
"},{"location":"expansionportpio/#1f802084h-4-redux-expansion-notification-message-pointer-w","title":"1F802084h 4 Redux-Expansion Notification message pointer (W)","text":"Displays a pop-up message to the user with the specified string.
See PCSX-Redux's documentation for more details and examples.
"},{"location":"geometrytransformationenginegte/","title":"Geometry Transformation Engine (GTE)","text":"GTE Overview GTE Registers GTE Saturation GTE Opcode Summary GTE Coordinate Calculation Commands GTE General Purpose Calculation Commands GTE Color Calculation Commands GTE Division Inaccuracy
"},{"location":"geometrytransformationenginegte/#gte-overview","title":"GTE Overview","text":""},{"location":"geometrytransformationenginegte/#gte-operation","title":"GTE Operation","text":"The GTE doesn't have any memory or I/O ports mapped to the CPU memory bus, instead, it's solely accessed via coprocessor opcodes:
mov cop0r12,rt ;-enable/disable COP2 (GTE) via COP0 status register\n mov cop2r0-63,rt ;\\write parameters to GTE registers\n mov cop2r0-31,[rs+imm] ;/\n mov cop2cmd,imm25 ;-issue GTE command\n mov rt,cop2r0-63 ;\\read results from GTE registers\n mov [rs+imm],cop2r0-31 ;/\n jt cop2flg,dest ;-jump never ;\\implemented (no exception), but,\n jf cop2flg,dest ;-jump always ;/flag seems to be always \"false\"\nUsing CFC2/MFC2 has a delay of 1 instruction until the GPR is loaded with its new value. Certain games are sensitive to this, with the notable example of Tekken 2 which will be filled with broken geometry on emulators which don't emulate this properly. GTE (memory-?) load and store instructions have a delay of 2 instructions, for any GTE commands or operations accessing that register. Any? That's wrong! GTE instructions and functions should not be used in
- Delay slots of jumps and branches\n - Event handlers or interrupts (sounds like nonsense?) (need push/pop though)\n 31-25 Must be 0100101b for \"COP2 imm25\" instructions\n 20-24 Fake GTE Command Number (00h..1Fh) (ignored by hardware)\n 19 sf - Shift Fraction in IR registers (0=No fraction, 1=12bit fraction)\n 17-18 MVMVA Multiply Matrix (0=Rotation. 1=Light, 2=Color, 3=Reserved)\n 15-16 MVMVA Multiply Vector (0=V0, 1=V1, 2=V2, 3=IR/long)\n 13-14 MVMVA Translation Vector (0=TR, 1=BK, 2=FC/Bugged, 3=None)\n 11-12 Always zero (ignored by hardware)\n 10 lm - Saturate IR1,IR2,IR3 result (0=To -8000h..+7FFFh, 1=To 0..+7FFFh)\n 6-9 Always zero (ignored by hardware)\n 0-5 Real GTE Command Number (00h..3Fh) (used by hardware)\n cop2r0-1 3xS16 VXY0,VZ0 Vector 0 (X,Y,Z)\n cop2r2-3 3xS16 VXY1,VZ1 Vector 1 (X,Y,Z)\n cop2r4-5 3xS16 VXY2,VZ2 Vector 2 (X,Y,Z)\n cop2r6 4xU8 RGBC Color/code value\n cop2r7 1xU16 OTZ Average Z value (for Ordering Table)\n cop2r8 1xS16 IR0 16bit Accumulator (Interpolate)\n cop2r9-11 3xS16 IR1,IR2,IR3 16bit Accumulator (Vector)\n cop2r12-15 6xS16 SXY0,SXY1,SXY2,SXYP Screen XY-coordinate FIFO (3 stages)\n cop2r16-19 4xU16 SZ0,SZ1,SZ2,SZ3 Screen Z-coordinate FIFO (4 stages)\n cop2r20-22 12xU8 RGB0,RGB1,RGB2 Color CRGB-code/color FIFO (3 stages)\n cop2r23 4xU8 (RES1) Prohibited\n cop2r24 1xS32 MAC0 32bit Maths Accumulators (Value)\n cop2r25-27 3xS32 MAC1,MAC2,MAC3 32bit Maths Accumulators (Vector)\n cop2r28-29 1xU15 IRGB,ORGB Convert RGB Color (48bit vs 15bit)\n cop2r30-31 2xS32 LZCS,LZCR Count Leading-Zeroes/Ones (sign bits)\n cop2r32-36 9xS16 RT11RT12,..,RT33 Rotation matrix (3x3) ;cnt0-4\n cop2r37-39 3x 32 TRX,TRY,TRZ Translation vector (X,Y,Z) ;cnt5-7\n cop2r40-44 9xS16 L11L12,..,L33 Light source matrix (3x3) ;cnt8-12\n cop2r45-47 3x 32 RBK,GBK,BBK Background color (R,G,B) ;cnt13-15\n cop2r48-52 9xS16 LR1LR2,..,LB3 Light color matrix source (3x3) ;cnt16-20\n cop2r53-55 3x 32 RFC,GFC,BFC Far color (R,G,B) ;cnt21-23\n cop2r56-57 2x 32 OFX,OFY Screen offset (X,Y) ;cnt24-25\n cop2r58 BuggyU16 H Projection plane distance. ;cnt26\n cop2r59 S16 DQA Depth queing parameter A (coeff) ;cnt27\n cop2r60 32 DQB Depth queing parameter B (offset);cnt28\n cop2r61-62 2xS16 ZSF3,ZSF4 Average Z scale factors ;cnt29-30\n cop2r63 U20 FLAG Returns any calculation errors ;cnt31\nNote in some functions format is different from the one that's given here.
"},{"location":"geometrytransformationenginegte/#matrix-registers","title":"Matrix Registers","text":" Rotation matrix (RT) Light matrix (LLM) Light Color matrix (LCM)\n cop2r32.lsbs=RT11 cop2r40.lsbs=L11 cop2r48.lsbs=LR1\n cop2r32.msbs=RT12 cop2r40.msbs=L12 cop2r48.msbs=LR2\n cop2r33.lsbs=RT13 cop2r41.lsbs=L13 cop2r49.lsbs=LR3\n cop2r33.msbs=RT21 cop2r41.msbs=L21 cop2r49.msbs=LG1\n cop2r34.lsbs=RT22 cop2r42.lsbs=L22 cop2r50.lsbs=LG2\n cop2r34.msbs=RT23 cop2r42.msbs=L23 cop2r50.msbs=LG3\n cop2r35.lsbs=RT31 cop2r43.lsbs=L31 cop2r51.lsbs=LB1\n cop2r35.msbs=RT32 cop2r43.msbs=L32 cop2r51.msbs=LB2\n cop2r36 =RT33 cop2r44 =L33 cop2r52 =LB3\n cop2r37 (cnt5) - TRX - Translation vector X (R/W?)\n cop2r38 (cnt6) - TRY - Translation vector Y (R/W?)\n cop2r39 (cnt7) - TRZ - Translation vector Z (R/W?)\n cop2r45 (cnt13) - RBK - Background color red component\n cop2r46 (cnt14) - GBK - Background color green component\n cop2r47 (cnt15) - BBK - Background color blue component\n cop2r53 (cnt21) - RFC - Far color red component\n cop2r54 (cnt22) - GFC - Far color green component\n cop2r55 (cnt23) - BFC - Far color blue component\n cop2r56 (cnt24) - OFX - Screen offset X\n cop2r57 (cnt25) - OFY - Screen offset Y\n cop2r58 (cnt26) - H - Projection plane distance\n cop2r59 (cnt27) - DQA - Depth queing parameter A.(coeff.)\n cop2r60 (cnt28) - DQB - Depth queing parameter B.(offset.)\n cop2r61 (cnt29) ZSF3 | 0|ZSF3 1,3,12| Z3 average scale factor (normally 1/3)\n cop2r62 (cnt30) ZSF4 | 0|ZSF4 1,3,12| Z4 average scale factor (normally 1/4)\n cop2r7 OTZ (R) | |OTZ 0,15, 0| Average Z value (for Ordering Table)\n cop2r12 - SXY0 rw|SY0 1,15, 0|SX0 1,15, 0| Screen XY fifo (older)\n cop2r13 - SXY1 rw|SY1 1,15, 0|SX1 1,15, 0| Screen XY fifo (old)\n cop2r14 - SXY2 rw|SY2 1,15, 0|SX2 1,15, 0| Screen XY fifo (new)\n cop2r15 - SXYP rw|SYP 1,15, 0|SXP 1,15, 0| SXY2-mirror with move-on-write\n cop2r16 - SZ0 rw| 0|SZ0 0,16, 0| Screen Z fifo (oldest)\n cop2r17 - SZ1 rw| 0|SZ1 0,16, 0| Screen Z fifo (older)\n cop2r18 - SZ2 rw| 0|SZ2 0,16, 0| Screen Z fifo (old)\n cop2r19 - SZ3 rw| 0|SZ3 0,16, 0| Screen Z fifo (new)\n Vector 0 (V0) Vector 1 (V1) Vector 2 (V2) Vector 3 (IR)\n cop2r0.lsbs - VX0 cop2r2.lsbs - VX1 cop2r4.lsbs - VX2 cop2r9 - IR1\n cop2r0.msbs - VY0 cop2r2.msbs - VY1 cop2r4.msbs - VY2 cop2r10 - IR2\n cop2r1 - VZ0 cop2r3 - VZ1 cop2r5 - VZ2 cop2r11 - IR3\n cop2r6 - RGBC rw|CODE |B |G |R | Color/code\n cop2r20 - RGB0 rw|CD0 |B0 |G0 |R0 | Characteristic color fifo.\n cop2r21 - RGB1 rw|CD1 |B1 |G1 |R1 |\n cop2r22 - RGB2 rw|CD2 |B2 |G2 |R2 |\n cop2r23 - (RES1) | | Prohibited\n cop2r8 IR0 rw|Sign |IR0 1, 3,12| Intermediate value 0.\n cop2r24 MAC0 rw|MAC0 1,31,0 | Sum of products value 0\n cop2r25 MAC1 rw|MAC1 1,31,0 | Sum of products value 1\n cop2r26 MAC2 rw|MAC2 1,31,0 | Sum of products value 2\n cop2r27 MAC3 rw|MAC3 1,31,0 | Sum of products value 3\nExpands 5:5:5 bit RGB (range 0..1Fh) to 16:16:16 bit RGB (range 0000h..0F80h).
0-4 Red (0..1Fh) (R/W) ;multiplied by 80h, and written to IR1\n 5-9 Green (0..1Fh) (R/W) ;multiplied by 80h, and written to IR2\n 10-14 Blue (0..1Fh) (R/W) ;multiplied by 80h, and written to IR3\n 15-31 Not used (always zero) (Read only)\nCollapses 16:16:16 bit RGB (range 0000h..0F80h) to 5:5:5 bit RGB (range 0..1Fh). Negative values (8000h..FFFFh/80h) are saturated to 00h, large positive values (1000h..7FFFh/80h) are saturated to 1Fh, there are no overflow or saturation flags set in cop2r63 though.
0-4 Red (0..1Fh) (R) ;IR1 divided by 80h, saturated to +00h..+1Fh\n 5-9 Green (0..1Fh) (R) ;IR2 divided by 80h, saturated to +00h..+1Fh\n 10-14 Blue (0..1Fh) (R) ;IR3 divided by 80h, saturated to +00h..+1Fh\n 15-31 Not used (always zero) (Read only)\nReading LZCR returns the leading 0 count of LZCS if LZCS is positive and the leading 1 count of LZCS if LZCS is negative. The results are in range 1..32.
"},{"location":"geometrytransformationenginegte/#cop2r63-cnt31-flag-returns-any-calculation-errors","title":"cop2r63 (cnt31) - FLAG - Returns any calculation errors.","text":"See GTE Saturation chapter.
"},{"location":"geometrytransformationenginegte/#gte-saturation","title":"GTE Saturation","text":"Maths overflows are indicated in FLAG register. In most cases, the result is saturated to MIN/MAX values (except MAC0,MAC1,MAC2,MAC3 which aren't saturated). For IR1,IR2,IR3 many commands allow to select the MIN value via \"lm\" bit of the GTE opcode (though not all commands, RTPS/RTPT always act as if lm=0).
"},{"location":"geometrytransformationenginegte/#cop2r63-cnt31-flag-returns-any-calculation-errors_1","title":"cop2r63 (cnt31) - FLAG - Returns any calculation errors.","text":" 31 Error Flag (Bit30..23, and 18..13 ORed together) (Read only)\n 30 MAC1 Result larger than 43 bits and positive\n 29 MAC2 Result larger than 43 bits and positive\n 28 MAC3 Result larger than 43 bits and positive\n 27 MAC1 Result larger than 43 bits and negative\n 26 MAC2 Result larger than 43 bits and negative\n 25 MAC3 Result larger than 43 bits and negative\n 24 IR1 saturated to +0000h..+7FFFh (lm=1) or to -8000h..+7FFFh (lm=0)\n 23 IR2 saturated to +0000h..+7FFFh (lm=1) or to -8000h..+7FFFh (lm=0)\n 22 IR3 saturated to +0000h..+7FFFh (lm=1) or to -8000h..+7FFFh (lm=0)\n 21 Color-FIFO-R saturated to +00h..+FFh\n 20 Color-FIFO-G saturated to +00h..+FFh\n 19 Color-FIFO-B saturated to +00h..+FFh\n 18 SZ3 or OTZ saturated to +0000h..+FFFFh\n 17 Divide overflow. RTPS/RTPT division result saturated to max=1FFFFh\n 16 MAC0 Result larger than 31 bits and positive\n 15 MAC0 Result larger than 31 bits and negative\n 14 SX2 saturated to -0400h..+03FFh\n 13 SY2 saturated to -0400h..+03FFh\n 12 IR0 saturated to +0000h..+1000h\n 0-11 Not used (always zero) (Read only)\n Opc Name Clk Expl.\n 00h - N/A (modifies similar registers than RTPS...)\n 01h RTPS 15 Perspective Transformation single\n 0xh - N/A\n 06h NCLIP 8 Normal clipping\n 0xh - N/A\n 0Ch OP(sf) 6 Cross product of 2 vectors\n 0xh - N/A\n 10h DPCS 8 Depth Cueing single\n 11h INTPL 8 Interpolation of a vector and far color vector\n 12h MVMVA 8 Multiply vector by matrix and add vector (see below)\n 13h NCDS 19 Normal color depth cue single vector\n 14h CDP 13 Color Depth Que\n 15h - N/A\n 16h NCDT 44 Normal color depth cue triple vectors\n 1xh - N/A\n 1Bh NCCS 17 Normal Color Color single vector\n 1Ch CC 11 Color Color\n 1Dh - N/A\n 1Eh NCS 14 Normal color single\n 1Fh - N/A\n 20h NCT 30 Normal color triple\n 2xh - N/A\n 28h SQR(sf)5 Square of vector IR\n 29h DCPL 8 Depth Cue Color light\n 2Ah DPCT 17 Depth Cueing triple (should be fake=08h, but isn't)\n 2xh - N/A\n 2Dh AVSZ3 5 Average of three Z values\n 2Eh AVSZ4 6 Average of four Z values\n 2Fh - N/A\n 30h RTPT 23 Perspective Transformation triple\n 3xh - N/A\n 3Dh GPF(sf)5 General purpose interpolation\n 3Eh GPL(sf)5 General purpose interpolation with base\n 3Fh NCCT 39 Normal Color Color triple vector\nThe fake opcode number in bit20-24 has absolutely no effect on the hardware, it seems to be solely used to (or not to) confuse developers. Having the opcodes sorted by their fake numbers gives a more or less well arranged list:
Fake Name Clk Expl.\n 00h - N/A\n 01h RTPS 15 Perspective Transformation single\n 02h RTPT 23 Perspective Transformation triple\n 03h - N/A\n 04h MVMVA 8 Multiply vector by matrix and add vector (see below)\n 05h - N/A\n 06h DCPL 8 Depth Cue Color light\n 07h DPCS 8 Depth Cueing single\n 08h DPCT 17 Depth Cueing triple (should be fake=08h, but isn't)\n 09h INTPL 8 Interpolation of a vector and far color vector\n 0Ah SQR(sf)5 Square of vector IR\n 0Bh - N/A\n 0Ch NCS 14 Normal color single\n 0Dh NCT 30 Normal color triple\n 0Eh NCDS 19 Normal color depth cue single vector\n 0Fh NCDT 44 Normal color depth cue triple vectors\n 10h NCCS 17 Normal Color Color single vector\n 11h NCCT 39 Normal Color Color triple vector\n 12h CDP 13 Color Depth Que\n 13h CC 11 Color Color\n 14h NCLIP 8 Normal clipping\n 15h AVSZ3 5 Average of three Z values\n 16h AVSZ4 6 Average of four Z values\n 17h OP(sf) 6 Cross product of 2 vectors\n 18h - N/A\n 19h GPF(sf)5 General purpose interpolation\n 1Ah GPL(sf)5 General purpose interpolation with base\n 1Bh - N/A\n 1Ch - N/A\n 1Dh - N/A\n 1Eh - N/A\n 1Fh - N/A\nThe LZCS/LZCR registers offer a Count-Leading-Zeroes/Leading-Ones function. The IRGB/ORGB registers allow to convert between 48bit and 15bit RGB colors. These registers work without needing to send any COP2 commands. However, unlike for commands (which do automatically halt the CPU when needed), one must insert dummy opcodes between writing and reading the registers.
"},{"location":"geometrytransformationenginegte/#gte-coordinate-calculation-commands","title":"GTE Coordinate Calculation Commands","text":""},{"location":"geometrytransformationenginegte/#cop2-0180001h-15-cycles-rtps-perspective-transformation-single","title":"COP2 0180001h - 15 Cycles - RTPS - Perspective Transformation (single)","text":""},{"location":"geometrytransformationenginegte/#cop2-0280030h-23-cycles-rtpt-perspective-transformation-triple","title":"COP2 0280030h - 23 Cycles - RTPT - Perspective Transformation (triple)","text":"RTPS performs final Rotate, translate and perspective transformation on vertex V0. Before writing to the FIFOs, the older entries are moved one stage down. RTPT is same as RTPS, but repeats for V1 and V2. The \"sf\" bit should be usually set.
IR1 = MAC1 = (TRX*1000h + RT11*VX0 + RT12*VY0 + RT13*VZ0) SAR (sf*12)\n IR2 = MAC2 = (TRY*1000h + RT21*VX0 + RT22*VY0 + RT23*VZ0) SAR (sf*12)\n IR3 = MAC3 = (TRZ*1000h + RT31*VX0 + RT32*VY0 + RT33*VZ0) SAR (sf*12)\n SZ3 = MAC3 SAR ((1-sf)*12) ;ScreenZ FIFO 0..+FFFFh\n MAC0=(((H*20000h/SZ3)+1)/2)*IR1+OFX, SX2=MAC0/10000h ;ScrX FIFO -400h..+3FFh\n MAC0=(((H*20000h/SZ3)+1)/2)*IR2+OFY, SY2=MAC0/10000h ;ScrY FIFO -400h..+3FFh\n MAC0=(((H*20000h/SZ3)+1)/2)*DQA+DQB, IR0=MAC0/1000h ;Depth cueing 0..+1000h\n MAC0 = SX0*SY1 + SX1*SY2 + SX2*SY0 - SX0*SY2 - SX1*SY0 - SX2*SY1\n MAC0 = ZSF3*(SZ1+SZ2+SZ3) ;for AVSZ3\n MAC0 = ZSF4*(SZ0+SZ1+SZ2+SZ3) ;for AVSZ4\n OTZ = MAC0/1000h ;for both (saturated to 0..FFFFh)\nMultiply vector by matrix and vector addition.
Mx = matrix specified by mx ;RT/LLM/LCM - Rotation, light or color matrix\n Vx = vector specified by v ;V0, V1, V2, or [IR1,IR2,IR3]\n Tx = translation vector specified by cv ;TR or BK or Bugged/FC, or None\n MAC1 = (Tx1*1000h + Mx11*Vx1 + Mx12*Vx2 + Mx13*Vx3) SAR (sf*12)\n MAC2 = (Tx2*1000h + Mx21*Vx1 + Mx22*Vx2 + Mx23*Vx3) SAR (sf*12)\n MAC3 = (Tx3*1000h + Mx31*Vx1 + Mx32*Vx2 + Mx33*Vx3) SAR (sf*12)\n [IR1,IR2,IR3] = [MAC1,MAC2,MAC3]\n [MAC1,MAC2,MAC3] = [IR1*IR1,IR2*IR2,IR3*IR3] SHR (sf*12)\n [IR1,IR2,IR3] = [MAC1,MAC2,MAC3] ;IR1,IR2,IR3 saturated to max 7FFFh\n [MAC1,MAC2,MAC3] = [IR3*D2-IR2*D3, IR1*D3-IR3*D1, IR2*D1-IR1*D2] SAR (sf*12)\n [IR1,IR2,IR3] = [MAC1,MAC2,MAC3] ;copy result\nThe LZCS/LZCR registers offer a Count-Leading-Zeroes/Leading-Ones function.
"},{"location":"geometrytransformationenginegte/#gte-color-calculation-commands","title":"GTE Color Calculation Commands","text":""},{"location":"geometrytransformationenginegte/#cop2-0c8041eh-14-cycles-ncs-normal-color-single","title":"COP2 0C8041Eh - 14 Cycles - NCS - Normal color (single)","text":""},{"location":"geometrytransformationenginegte/#cop2-0d80420h-30-cycles-nct-normal-color-triple","title":"COP2 0D80420h - 30 Cycles - NCT - Normal color (triple)","text":""},{"location":"geometrytransformationenginegte/#cop2-108041bh-17-cycles-nccs-normal-color-color-single-vector","title":"COP2 108041Bh - 17 Cycles - NCCS - Normal Color Color (single vector)","text":""},{"location":"geometrytransformationenginegte/#cop2-118043fh-39-cycles-ncct-normal-color-color-triple-vector","title":"COP2 118043Fh - 39 Cycles - NCCT - Normal Color Color (triple vector)","text":""},{"location":"geometrytransformationenginegte/#cop2-0e80413h-19-cycles-ncds-normal-color-depth-cue-single-vector","title":"COP2 0E80413h - 19 Cycles - NCDS - Normal color depth cue (single vector)","text":""},{"location":"geometrytransformationenginegte/#cop2-0f80416h-44-cycles-ncdt-normal-color-depth-cue-triple-vectors","title":"COP2 0F80416h - 44 Cycles - NCDT - Normal color depth cue (triple vectors)","text":"In: V0=Normal vector (for triple variants repeated with V1 and V2), BK=Background color, RGBC=Primary color/code, LLM=Light matrix, LCM=Color matrix, IR0=Interpolation value.
[IR1,IR2,IR3] = [MAC1,MAC2,MAC3] = (LLM*V0) SAR (sf*12)\n [IR1,IR2,IR3] = [MAC1,MAC2,MAC3] = (BK*1000h + LCM*IR) SAR (sf*12)\n [MAC1,MAC2,MAC3] = [R*IR1,G*IR2,B*IR3] SHL 4 ;<--- for NCDx/NCCx\n [MAC1,MAC2,MAC3] = MAC+(FC-MAC)*IR0 ;<--- for NCDx only\n [MAC1,MAC2,MAC3] = [MAC1,MAC2,MAC3] SAR (sf*12) ;<--- for NCDx/NCCx\n Color FIFO = [MAC1/16,MAC2/16,MAC3/16,CODE], [IR1,IR2,IR3] = [MAC1,MAC2,MAC3]\nIn: [IR1,IR2,IR3]=Vector, RGBC=Primary color/code, LCM=Color matrix, BK=Background color, and, for CDP, IR0=Interpolation value, FC=Far color.
[IR1,IR2,IR3] = [MAC1,MAC2,MAC3] = (BK*1000h + LCM*IR) SAR (sf*12)\n [MAC1,MAC2,MAC3] = [R*IR1,G*IR2,B*IR3] SHL 4\n [MAC1,MAC2,MAC3] = MAC+(FC-MAC)*IR0 ;<--- for CDP only\n [MAC1,MAC2,MAC3] = [MAC1,MAC2,MAC3] SAR (sf*12)\n Color FIFO = [MAC1/16,MAC2/16,MAC3/16,CODE], [IR1,IR2,IR3] = [MAC1,MAC2,MAC3]\nIn: [IR1,IR2,IR3]=Vector, FC=Far Color, IR0=Interpolation value, CODE=MSB of RGBC, and, for DCPL, R,G,B=LSBs of RGBC.
[MAC1,MAC2,MAC3] = [R*IR1,G*IR2,B*IR3] SHL 4 ;<--- for DCPL only\n [MAC1,MAC2,MAC3] = [IR1,IR2,IR3] SHL 12 ;<--- for INTPL only\n [MAC1,MAC2,MAC3] = [R,G,B] SHL 16 ;<--- for DPCS/DPCT\n [MAC1,MAC2,MAC3] = MAC+(FC-MAC)*IR0\n [MAC1,MAC2,MAC3] = [MAC1,MAC2,MAC3] SAR (sf*12)\n Color FIFO = [MAC1/16,MAC2/16,MAC3/16,CODE], [IR1,IR2,IR3] = [MAC1,MAC2,MAC3]\n [MAC1,MAC2,MAC3] = [0,0,0] ;<--- for GPF only\n [MAC1,MAC2,MAC3] = [MAC1,MAC2,MAC3] SHL (sf*12) ;<--- for GPL only\n [MAC1,MAC2,MAC3] = (([IR1,IR2,IR3] * IR0) + [MAC1,MAC2,MAC3]) SAR (sf*12)\n Color FIFO = [MAC1/16,MAC2/16,MAC3/16,CODE], [IR1,IR2,IR3] = [MAC1,MAC2,MAC3]\n [IR1,IR2,IR3] = (([RFC,GFC,BFC] SHL 12) - [MAC1,MAC2,MAC3]) SAR (sf*12)\n [MAC1,MAC2,MAC3] = (([IR1,IR2,IR3] * IR0) + [MAC1,MAC2,MAC3])\nWorks like MVMVA command (see there), but with fixed Tx/Vx/Mx parameters, the sf/lm bits can be changed and do affect the results (although normally both bits should be set for use with color matrices).
"},{"location":"geometrytransformationenginegte/#notes","title":"Notes","text":"The 8bit RGB values written to the top of Color Fifo are the 32bit MACn values divided by 16, and saturated to +00h..+FFh, and of course, the older Fifo entries are moved downwards. Note that, at the GPU side, the meaning of the RGB values depends on whether or not texture blending is used (for untextured polygons FFh is max brightness) (for texture blending FFh is double brightness and 80h is normal brightness). The 8bit CODE value is intended to contain a GP0(20h..7Fh) Rendering command, allowing to automatically merge the 8bit command number, with the 24bit color value. The IRGB/ORGB registers allow to convert between 48bit and 15bit RGB colors. Although the result of the commands in this chapter is written to the Color FIFO, some commands like GPF/GPL may be also used for other purposes (eg. to scale or scale/translate single vertices).
"},{"location":"geometrytransformationenginegte/#gte-division-inaccuracy","title":"GTE Division Inaccuracy","text":""},{"location":"geometrytransformationenginegte/#gte-division-inaccuracy-for-rtpsrtpt-commands","title":"GTE Division Inaccuracy (for RTPS/RTPT commands)","text":"Basically, the GTE division does (attempt to) work as so (using 33bit maths):
n = (((H*20000h/SZ3)+1)/2)\n n = ((H*10000h+SZ3/2)/SZ3)\n if n>1FFFFh or division_by_zero then n=1FFFFh, FLAG.Bit17=1, FLAG.Bit31=1\n if (H < SZ3*2) then ;check if overflow\n z = count_leading_zeroes(SZ3) ;z=0..0Fh (for 16bit SZ3)\n n = (H SHL z) ;n=0..7FFF8000h\n d = (SZ3 SHL z) ;d=8000h..FFFFh\n u = unr_table[(d-7FC0h) SHR 7] + 101h ;u=200h..101h\n d = ((2000080h - (d * u)) SHR 8) ;d=10000h..0FF01h\n d = ((0000080h + (d * u)) SHR 8) ;d=20000h..10000h\n n = min(1FFFFh, (((n*d) + 8000h) SHR 16)) ;n=0..1FFFFh\n else n = 1FFFFh, FLAG.Bit17=1, FLAG.Bit31=1 ;n=1FFFFh plus overflow flag\n FFh,FDh,FBh,F9h,F7h,F5h,F3h,F1h,EFh,EEh,ECh,EAh,E8h,E6h,E4h,E3h ;\\\n E1h,DFh,DDh,DCh,DAh,D8h,D6h,D5h,D3h,D1h,D0h,CEh,CDh,CBh,C9h,C8h ; 00h..3Fh\n C6h,C5h,C3h,C1h,C0h,BEh,BDh,BBh,BAh,B8h,B7h,B5h,B4h,B2h,B1h,B0h ;\n AEh,ADh,ABh,AAh,A9h,A7h,A6h,A4h,A3h,A2h,A0h,9Fh,9Eh,9Ch,9Bh,9Ah ;/\n 99h,97h,96h,95h,94h,92h,91h,90h,8Fh,8Dh,8Ch,8Bh,8Ah,89h,87h,86h ;\\\n 85h,84h,83h,82h,81h,7Fh,7Eh,7Dh,7Ch,7Bh,7Ah,79h,78h,77h,75h,74h ; 40h..7Fh\n 73h,72h,71h,70h,6Fh,6Eh,6Dh,6Ch,6Bh,6Ah,69h,68h,67h,66h,65h,64h ;\n 63h,62h,61h,60h,5Fh,5Eh,5Dh,5Dh,5Ch,5Bh,5Ah,59h,58h,57h,56h,55h ;/\n 54h,53h,53h,52h,51h,50h,4Fh,4Eh,4Dh,4Dh,4Ch,4Bh,4Ah,49h,48h,48h ;\\\n 47h,46h,45h,44h,43h,43h,42h,41h,40h,3Fh,3Fh,3Eh,3Dh,3Ch,3Ch,3Bh ; 80h..BFh\n 3Ah,39h,39h,38h,37h,36h,36h,35h,34h,33h,33h,32h,31h,31h,30h,2Fh ;\n 2Eh,2Eh,2Dh,2Ch,2Ch,2Bh,2Ah,2Ah,29h,28h,28h,27h,26h,26h,25h,24h ;/\n 24h,23h,22h,22h,21h,20h,20h,1Fh,1Eh,1Eh,1Dh,1Dh,1Ch,1Bh,1Bh,1Ah ;\\\n 19h,19h,18h,18h,17h,16h,16h,15h,15h,14h,14h,13h,12h,12h,11h,11h ; C0h..FFh\n 10h,0Fh,0Fh,0Eh,0Eh,0Dh,0Dh,0Ch,0Ch,0Bh,0Ah,0Ah,09h,09h,08h,08h ;\n 07h,07h,06h,06h,05h,05h,04h,04h,03h,03h,02h,02h,01h,01h,00h,00h ;/\n 00h ;<-- one extra table entry (for \"(d-7FC0h)/80h\"=100h) ;-100h\nThe GPU can render Polygons, Lines, or Rectangles to the Drawing Buffer, and sends the Display Buffer to the Television Set. Polygons are useful for 3D graphics (or rotated/scaled 2D graphics), Rectangles are useful for 2D graphics and Text output.
GPU I/O Ports, DMA Channels, Commands, VRAM GPU Render Polygon Commands GPU Render Line Commands GPU Render Rectangle Commands GPU Rendering Attributes GPU Memory Transfer Commands GPU Other Commands GPU Display Control Commands (GP1) GPU Status Register GPU Versions GPU Depth Ordering GPU Video Memory (VRAM) GPU Texture Caching GPU Timings GPU (MISC)
"},{"location":"graphicsprocessingunitgpu/#gpu-io-ports-dma-channels-commands-vram","title":"GPU I/O Ports, DMA Channels, Commands, VRAM","text":""},{"location":"graphicsprocessingunitgpu/#gpu-io-ports-1f801810h-and-1f801814h-in-readwrite-directions","title":"GPU I/O Ports (1F801810h and 1F801814h in Read/Write Directions)","text":" Port Name Expl.\n 1F801810h-Write GP0 Send GP0 Commands/Packets (Rendering and VRAM Access)\n 1F801814h-Write GP1 Send GP1 Commands (Display Control) (and DMA Control)\n 1F801810h-Read GPUREAD Receive responses to GP0(C0h) and GP1(10h) commands\n 1F801814h-Read GPUSTAT Receive GPU Status Register\nMost of the Timers are bound to GPU timings, see Timers Interrupts
"},{"location":"graphicsprocessingunitgpu/#gpu-related-dma-channels-dma2-and-dma6","title":"GPU-related DMA Channels (DMA2 and DMA6)","text":" Channel Recommended for\n DMA2 in Linked Mode - Sending rendering commands ;GP0(20h..7Fh,E1h..E6h)\n DMA2 in Continuous Mode - VRAM transfers to/from GPU ;GP0(A0h,C0h)\n DMA6 - Initializing the Link List ;Main RAM\nWhile it is probably more simple for the MIPS software to see GPU commands as a collection of bytes, the GPU will only see 32 bits words being sent to it. Therefore, while the Sony libraries will fill up structures to send to the GPU using byte-level granularity, it is much more simple to see these as bitmasks from the GPU's point of view. So when processing commands on GP0, the GPU will first inspect the top 3 bits of the 32 bits command being sent. Depending on the value of these 3 bits, further decoding of the other bits can be done. Commands sent to GP1 are more simple in nature to decode. Top 3 bits of a GP0 command:
0 (000) Misc commands\n 1 (001) Polygon primitive\n 2 (010) Line primitive\n 3 (011) Rectangle primitive\n 4 (100) VRAM-to-VRAM blit\n 5 (101) CPU-to-VRAM blit\n 6 (110) VRAM-to-CPU blit\n 7 (111) Environment commands\nThe astute reader will realize that there are shared bits between primitives, such as the gouraud shading flag.
Unlike all the others, the environment commands are more clear to be seen as a single 8 bits command, therefore the rest of the document will refer to them by their full 8 bits value.
"},{"location":"graphicsprocessingunitgpu/#clear-cache","title":"Clear Cache","text":" 1st Command (01000000h)\n 1st Color+Command (02BbGgRrh) ;24bit RGB value (see note)\n 2nd Top Left Corner (YyyyXxxxh) ;Xpos counted in halfwords, steps of 10h\n 3rd Width+Height (YsizXsizh) ;Xsiz counted in halfwords, steps of 10h\nVRAM can be 1 MB or 2 MB (not mapped to the CPU bus) (it can be read/written only via I/O or DMA). The memory is used for:
Framebuffer(s) ;Usually 2 buffers (Drawing Area, and Display Area)\n Texture Page(s) ;Required when using Textures\n Texture Palette(s) ;Required when using 4bit/8bit Textures\n Unit = 4bit 8bit 16bit 24bit Halfwords | Unit = Lines\n Width = 4096 2048 1024 682.66 1024 | Height = 512/1024\nWhen the upper 3 bits of the first GP0 command are set to 1 (001), then the command can be decoded using the following bitfield:
bit number value meaning\n 31-29 001 polygon render\n 28 1/0 gouraud / flat shading\n 27 1/0 4 / 3 vertices\n 26 1/0 textured / untextured\n 25 1/0 semi-transparent / opaque\n 24 1/0 raw texture / modulation\n 23-0 rgb first color value.\nSubsequent data sent to GP0 to complete this command will be the vertex data for the command. The meaning and count of these words will be altered by the initial flags sent in the first command.
If doing flat rendering, no further color will be sent. If doing gouraud shading, there will be one more color per vertex sent, and the initial color will be the one for vertex 0.
If doing textured rendering, each vertex sent will also have a U/V texture coordinate attached to it, as well as a CLUT index.
So each vertex data can be seen as the following set of words:
Color xxBBGGRR - optional, only present for gouraud shading\nVertex YYYYXXXX - required, two signed 16 bits values\nUV ClutVVUU or PageVVUU - optional, only present for textured polygons\nThe upper 16 bits of the first two UV words contain extra information. The first word holds the Clut index. The second word contains texture page information. Any further clut/page bits should be set to 0.
So for example, a solid flat blue triangle of coordinate (10, 20), (30, 40), (50, 60) will be drawn using the following draw call data:
200000FF\n00100020\n00300040\n00500060\nAnd a quad with gouraud shading texture-blend will have the following structure:
2CR1G1B1\nYyy1Xxx1\nClutV1U1\n00R2G2B2\nYyy2Xxx2\nPageV2U2\n00R3G3B3\nYyy3Xxx3\n0000V3U3\n00R4G4B4\nYyy4Xxx4\n0000V4U4\nSome combination of these flags can be seen as nonsense however, but it's important to realize that the GPU will still process them properly. For instance, specifying gouraud shading without modulation will force the user to send the colors for each vertex to satisfy the GPU's state machine, without them being actually used for the rendering.
"},{"location":"graphicsprocessingunitgpu/#notes","title":"Notes","text":"Polygons are displayed up to \\<excluding> their lower-right coordinates. Quads are internally processed as two triangles, the first consisting of vertices 1,2,3, and the second of vertices 2,3,4. This is an important detail, as splitting the quad into triangles affects the way colours are interpolated. Within the triangle, the ordering of the vertices doesn't matter on the GPU side (a front-back check, based on clockwise or anti-clockwise ordering, can be implemented at the GTE side). Dither enable (in Texpage command) affects ONLY polygons that do use gouraud shading or modulation.
"},{"location":"graphicsprocessingunitgpu/#gpu-render-line-commands","title":"GPU Render Line Commands","text":"When the upper 3 bits of the first GP0 command are set to 2 (010), then the command can be decoded using the following bitfield:
bit number value meaning\n 31-29 010 line render\n 28 1/0 gouraud / flat shading\n 27 1/0 polyline / single line\n 25 1/0 semi-transparent / opaque\n 23-0 rgb first color value.\nSo each vertex can be seen as the following list of words:
Color xxBBGGRR - optional, only present for gouraud shading\nVertex YYYYXXXX - required, two signed 16 bits values\nWhen polyline mode is active, at least two vertices must be sent to the GPU. The vertex list is terminated by the bits 12-15 and 28-31 equaling 0x5, or (word & 0xF000F000) == 0x50005000. The terminator value occurs on the first word of the vertex (i.e. the color word if it's a gouraud shaded).
If the 2 vertices in a line overlap, then the GPU will draw a 1x1 rectangle in the location of the 2 vertices using the colour of the first vertex.
"},{"location":"graphicsprocessingunitgpu/#note","title":"Note","text":"Lines are displayed up to \\<including> their lower-right coordinates (ie. unlike as for polygons, the lower-right coordinate is not excluded). If dithering is enabled (via Texpage command), then both monochrome and shaded lines are drawn with dithering (this differs from monochrome polygons and monochrome rectangles).
"},{"location":"graphicsprocessingunitgpu/#wire-frame","title":"Wire-Frame","text":"Poly-Lines can be used (among others) to create Wire-Frame polygons (by setting the last Vertex equal to Vertex 1).
"},{"location":"graphicsprocessingunitgpu/#gpu-render-rectangle-commands","title":"GPU Render Rectangle Commands","text":"Rectangles are drawn much faster than polygons. Unlike polygons, gouraud shading is not possible, dithering isn't applied, the rectangle must forcefully have horizontal and vertical edges, textures cannot be rotated or scaled, and, of course, the GPU does render Rectangles as a single entity, without splitting them into two triangles.
The Rectangle command can be decoded using the following bitfield:
bit number value meaning\n 31-29 011 rectangle render\n 28-27 sss rectangle size\n 26 1/0 textured / untextured\n 25 1/0 semi-transparent / opaque\n 24 1/0 raw texture / modulation\n 23-0 rgb first color value.\nThe size parameter can be seen as the following enum:
0 (00) variable size\n 1 (01) single pixel (1x1)\n 2 (10) 8x8 sprite\n 3 (11) 16x16 sprite\nTherefore, the whole draw call can be seen as the following sequence of words:
Color ccBBGGRR - command + color; color is ignored when textured\nVertex1 YYYYXXXX - required, indicates the upper left corner to render\nUV ClutVVUU - optional, only present for textured rectangles\nWidth+Height YsizXsiz - optional, dimensions for variable sized rectangles (max 1023x511)\nUnlike for Textured-Polygons, the \"Texpage\" must be set up separately for Rectangles, via GP0(E1h). Width and Height can be up to 1023x511, however, the maximum size of the texture window is 256x256 (so the source data will be repeated when trying to use sizes larger than 256x256).
"},{"location":"graphicsprocessingunitgpu/#texture-origin-and-xy-flip","title":"Texture Origin and X/Y-Flip","text":"Vertex & Texcoord specify the upper-left edge of the rectangle. And, normally, screen coords and texture coords are both incremented during rendering the rectangle pixels. Optionally, X/Y-Flip bits can be set in Texpage.Bit12/13, these bits cause the texture coordinates to be decremented (instead of incremented). The X/Y-Flip bits do affect only Rectangles (not Polygons, nor VRAM Transfers). Caution: Reportedly, the X/Y-Flip feature isn't supported on old PSX consoles (unknown which ones exactly, maybe such with PU-7 mainboards, and unknown how to detect flipping support; except of course by reading VRAM).
"},{"location":"graphicsprocessingunitgpu/#note_1","title":"Note","text":"There are also two VRAM Transfer commands which work similar to GP0(60h) and GP0(65h). Eventually, that commands might be even faster... although not sure if they do use the Texture Cache? The difference is that VRAM Transfers do not clip to the Drawig Area boundary, do not support fully-transparent nor semi-transparent texture pixels, and do not convert color depths (eg. without 4bit texture to 16bit framebuffer conversion).
"},{"location":"graphicsprocessingunitgpu/#gpu-rendering-attributes","title":"GPU Rendering Attributes","text":""},{"location":"graphicsprocessingunitgpu/#vertex-parameter-for-polygon-line-rectangle-commands","title":"Vertex (Parameter for Polygon, Line, Rectangle commands)","text":" 0-10 X-coordinate (signed, -1024..+1023)\n 11-15 Not used (usually sign-extension, but ignored by hardware)\n 16-26 Y-coordinate (signed, -1024..+1023)\n 26-31 Not used (usually sign-extension, but ignored by hardware)\n 0-7 Red (0..FFh)\n 8-15 Green (0..FFh)\n 16-23 Blue (0..FFh)\n 24-31 Command (in first paramter) (don't care in further parameters)\n 0-8 Same as GP0(E1h).Bit0-8 (see there)\n 9-10 Unused (does NOT change GP0(E1h).Bit9-10)\n 11 Same as GP0(E1h).Bit11 (see there)\n 12-13 Unused (does NOT change GP0(E1h).Bit12-13)\n 14-15 Unused (should be 0)\nThis attribute is used in all Textured Polygon/Rectangle commands. Of course, it's relevant only for 4bit/8bit textures (don't care for 15bit textures).
0-5 X coordinate X/16 (ie. in 16-halfword steps)\n 6-14 Y coordinate 0-511 (ie. in 1-line steps) ;\\on v0 GPU (max 1 MB VRAM)\n 15 Unused (should be 0) ;/\n 6-15 Y coordinate 0-1023 (ie. in 1-line steps) ;on v2 GPU (max 2 MB VRAM)\n 0-3 Texture page X Base (N*64) (ie. in 64-halfword steps) ;GPUSTAT.0-3\n 4 Texture page Y Base 1 (N*256) (ie. 0, 256, 512 or 768) ;GPUSTAT.4\n 5-6 Semi-transparency (0=B/2+F/2, 1=B+F, 2=B-F, 3=B+F/4) ;GPUSTAT.5-6\n 7-8 Texture page colors (0=4bit, 1=8bit, 2=15bit, 3=Reserved);GPUSTAT.7-8\n 9 Dither 24bit to 15bit (0=Off/strip LSBs, 1=Dither Enabled) ;GPUSTAT.9\n 10 Drawing to display area (0=Prohibited, 1=Allowed) ;GPUSTAT.10\n 11 Texture page Y Base 2 (N*512) (only for 2 MB VRAM) ;GPUSTAT.15\n 12 Textured Rectangle X-Flip (BIOS does set this bit on power-up...?)\n 13 Textured Rectangle Y-Flip (BIOS does set it equal to GPUSTAT.13...?)\n 14-23 Not used (should be 0)\n 24-31 Command (E1h)\n 0-4 Texture window Mask X (in 8 pixel steps)\n 5-9 Texture window Mask Y (in 8 pixel steps)\n 10-14 Texture window Offset X (in 8 pixel steps)\n 15-19 Texture window Offset Y (in 8 pixel steps)\n 20-23 Not used (zero)\n 24-31 Command (E2h)\n Texcoord = (Texcoord AND (NOT (Mask*8))) OR ((Offset AND Mask)*8)\n 0-9 X-coordinate (0..1023)\n 10-18 Y-coordinate (0..511) ;\\on v0 GPU (max 1 MB VRAM)\n 19-23 Not used (zero) ;/\n 10-19 Y-coordinate (0..1023) ;\\on v2 GPU (max 2 MB VRAM)\n 20-23 Not used (zero) ;/\n 24-31 Command (Exh)\n 0-10 X-offset (-1024..+1023) (usually within X1,X2 of Drawing Area)\n 11-21 Y-offset (-1024..+1023) (usually within Y1,Y2 of Drawing Area)\n 22-23 Not used (zero)\n 24-31 Command (E5h)\n 0 Set mask while drawing (0=TextureBit15, 1=ForceBit15=1) ;GPUSTAT.11\n 1 Check mask before draw (0=Draw Always, 1=Draw if Bit15=0) ;GPUSTAT.12\n 2-23 Not used (zero)\n 24-31 Command (E6h)\nGP0(E3h..E5h) do not take up space in the FIFO, so they are probably executed immediately (even if there're still other commands in the FIFO). Best use them only if you are sure that the FIFO is empty (otherwise the new Drawing Area settings might accidentally affect older Rendering Commands in the FIFO).
"},{"location":"graphicsprocessingunitgpu/#gpu-memory-transfer-commands","title":"GPU Memory Transfer Commands","text":"The next three commands being described are when the high 3 bits are set to the values 4 (100), 5 (101), and 6 (110). For them, the remaining 29 bits are ignored, and can be set to any arbitrary value.
"},{"location":"graphicsprocessingunitgpu/#vram-to-vram-blitting-command-4-100","title":"VRAM to VRAM blitting - command 4 (100)","text":" 1st Command\n 2nd Source Coord (YyyyXxxxh) ;Xpos counted in halfwords\n 3rd Destination Coord (YyyyXxxxh) ;Xpos counted in halfwords\n 4th Width+Height (YsizXsizh) ;Xsiz counted in halfwords\n 1st Command\n 2nd Destination Coord (YyyyXxxxh) ;Xpos counted in halfwords\n 3rd Width+Height (YsizXsizh) ;Xsiz counted in halfwords\n ... Data (...) <--- usually transferred via DMA\n 1st Command ;\\\n 2nd Source Coord (YyyyXxxxh) ; write to GP0 port (as usually)\n 3rd Width+Height (YsizXsizh) ;/\n ... Data (...) ;<--- read from GPUREAD port (or via DMA)\n Xpos=(Xpos AND 3F0h) ;range 0..3F0h, in steps of 10h\n Ypos=(Ypos AND 1FFh) ;range 0..1FFh\n Xsiz=((Xsiz AND 3FFh)+0Fh) AND (NOT 0Fh) ;range 0..400h, in steps of 10h\n Ysiz=((Ysiz AND 1FFh)) ;range 0..1FFh\nNote that because of the height (Ysiz) masking, a maximum of 511 rows can be filled in a single command. Calling a fill with a full VRAM height of 512 rows will be ineffective as the height will be masked to 0.
"},{"location":"graphicsprocessingunitgpu/#masking-for-copy-commands-parameters","title":"Masking for COPY Commands parameters","text":" Xpos=(Xpos AND 3FFh) ;range 0..3FFh\n Ypos=(Ypos AND 1FFh) ;range 0..1FFh\n Xsiz=((Xsiz-1) AND 3FFh)+1 ;range 1..400h\n Ysiz=((Ysiz-1) AND 1FFh)+1 ;range 1..200h\nThe coordinates for the above VRAM transfer commands are absolute framebuffer addresses (not relative to Draw Offset, and not clipped to Draw Area). Non-DMA transfers seem to be working at any time, but GPU-DMA Transfers seem to be working ONLY during V-Blank (outside of V-Blank, portions of the data appear to be skipped, and the following words arrive at wrong addresses), unknown if it's possible to change that by whatever configuration settings...? That problem appears ONLY for continous DMA aka VRAM transfers (linked-list DMA aka Ordering Table works even outside V-Blank).
"},{"location":"graphicsprocessingunitgpu/#wrapping","title":"Wrapping","text":"If the Source/Dest starting points plus the width/height value exceed the 1024x512 pixel VRAM size, then the Copy/Fill operations wrap to the opposite memory edge (without any carry-out from X to Y, nor from Y to X).
"},{"location":"graphicsprocessingunitgpu/#gpu-other-commands","title":"GPU Other Commands","text":""},{"location":"graphicsprocessingunitgpu/#gp01fh-interrupt-request-irq1","title":"GP0(1Fh) - Interrupt Request (IRQ1)","text":" 1st Command (Cc000000h) ;GPUSTAT.24\nUnknown. Doesn't seem to be used by any games. Unlike the \"NOP\" commands, GP0(03h) does take up space in FIFO, so it is apparently not a NOP.
"},{"location":"graphicsprocessingunitgpu/#gp000h-nop","title":"GP0(00h) - NOP (?)","text":"This command doesn't take up space in the FIFO (eg. even if a VRAM-to-VRAM transfer is still busy, one can send dozens of GP0(00h) commands, without the command FIFO becoming full. So, either the command is ignored (or, if it has a function, it is executed immediately, even while the transfer is busy). ... GP0(00h) unknown, used with parameter = 08A16Ch... or rather 08FDBCh ... the written value seems to be a bios/ram memory address, anded with 00FFFFFFh... maybe a bios bug? GP0(00h) seems to be often inserted between Texpage and Rectangle commands, maybe it acts as a NOP, which may be required between that commands, for timing reasons...?
"},{"location":"graphicsprocessingunitgpu/#gp004h1ehe0he7hefh-mirrors-of-gp000h-nop","title":"GP0(04h..1Eh,E0h,E7h..EFh) - Mirrors of GP0(00h) - NOP (?)","text":"Like GP0(00h), these commands don't take up space in the FIFO. So, maybe, they are same as GP0(00h), however, the Drawing Area/Offset commands GP0(E3h..E5h) don't take up FIFO space either, so not taking up FIFO space doesn't neccessarily mean that the command has no function.
"},{"location":"graphicsprocessingunitgpu/#gpu-display-control-commands-gp1","title":"GPU Display Control Commands (GP1)","text":"GP1 Display Control Commands are sent by writing the 8bit Command number (MSBs), and 24bit parameter (LSBs) to Port 1F801814h. Unlike GP0 commands, GP1 commands are passed directly to the GPU (ie. they can be sent even when the FIFO is full).
"},{"location":"graphicsprocessingunitgpu/#gp100h-reset-gpu","title":"GP1(00h) - Reset GPU","text":" 0-23 Not used (zero)\n GP1(01h) ;clear fifo\n GP1(02h) ;ack irq (0)\n GP1(03h) ;display off (1)\n GP1(04h) ;dma off (0)\n GP1(05h) ;display address (0)\n GP1(06h) ;display x1,x2 (x1=200h, x2=200h+256*10)\n GP1(07h) ;display y1,y2 (y1=010h, y2=010h+240)\n GP1(08h) ;display mode 320x200 NTSC (0)\n GP0(E1h..E6h) ;rendering attributes (0)\n 0-23 Not used (zero)\n 0-23 Not used (zero) ;GPUSTAT.24\n 0 Display On/Off (0=On, 1=Off) ;GPUSTAT.23\n 1-23 Not used (zero)\n 0-1 DMA Direction (0=Off, 1=FIFO, 2=CPUtoGP0, 3=GPUREADtoCPU) ;GPUSTAT.29-30\n 2-23 Not used (zero)\nSpecifies where the display area is positioned on the screen, and how much data gets sent to the screen. The screen sizes of the display area are valid only if the horizontal/vertical start/end values are default. By changing these you can get bigger/smaller display screens. On most TV's there is some black around the edge, which can be utilised by setting the start of the screen earlier and the end later. The size of the pixels is NOT changed with these settings, the GPU simply sends more data to the screen. Some monitors/TVs have a smaller display area and the extended size might not be visible on those sets. \"(Mine is capable of about 330 pixels horizontal, and 272 vertical in 320*240 mode)\"
"},{"location":"graphicsprocessingunitgpu/#gp105h-start-of-display-area-in-vram","title":"GP1(05h) - Start of Display area (in VRAM)","text":" 0-9 X (0-1023) (halfword address in VRAM) (relative to begin of VRAM)\n 10-18 Y (0-511) (scanline number in VRAM) (relative to begin of VRAM)\n 19-23 Not used (zero)\n 0-11 X1 (260h+0) ;12bit ;\\counted in video clock units,\n 12-23 X2 (260h+320*8) ;12bit ;/relative to HSYNC\n 0-9 Y1 (NTSC=88h-(240/2), (PAL=A3h-(288/2)) ;\\scanline numbers on screen,\n 10-19 Y2 (NTSC=88h+(240/2), (PAL=A3h+(288/2)) ;/relative to VSYNC\n 20-23 Not used (zero)\n 0-1 Horizontal Resolution 1 (0=256, 1=320, 2=512, 3=640) ;GPUSTAT.17-18\n 2 Vertical Resolution (0=240, 1=480, when Bit5=1) ;GPUSTAT.19\n 3 Video Mode (0=NTSC/60Hz, 1=PAL/50Hz) ;GPUSTAT.20\n 4 Display Area Color Depth (0=15bit, 1=24bit) ;GPUSTAT.21\n 5 Vertical Interlace (0=Off, 1=On) ;GPUSTAT.22\n 6 Horizontal Resolution 2 (0=256/320/512/640, 1=368) ;GPUSTAT.16\n 7 Flip screen horizontally (0=Off, 1=On, v1 only) ;GPUSTAT.14\n 8-23 Not used (zero)\nAfter sending the command, the result can be read (immediately) from GPUREAD register (there's no NOP or other delay required) (namely GPUSTAT.Bit27 is used only for VRAM reads, but NOT for register reads, so do not try to wait for that flag).
0-23 Register index (via following GPUREAD)\n 00h-01h = Returns Nothing (old value in GPUREAD remains unchanged)\n 02h = Read Texture Window setting ;GP0(E2h) ;20bit/MSBs=Nothing\n 03h = Read Draw area top left ;GP0(E3h) ;19bit/MSBs=Nothing\n 04h = Read Draw area bottom right ;GP0(E4h) ;19bit/MSBs=Nothing\n 05h = Read Draw offset ;GP0(E5h) ;22bit\n 06h-07h = Returns Nothing (old value in GPUREAD remains unchanged)\n 08h-FFFFFFh = Mirrors of 00h..07h\n 00h-01h = Returns Nothing (old value in GPUREAD remains unchanged)\n 02h = Read Texture Window setting ;GP0(E2h) ;20bit/MSBs=Nothing\n 03h = Read Draw area top left ;GP0(E3h) ;20bit/MSBs=Nothing\n 04h = Read Draw area bottom right ;GP0(E4h) ;20bit/MSBs=Nothing\n 05h = Read Draw offset ;GP0(E5h) ;22bit\n 06h = Returns Nothing (old value in GPUREAD remains unchanged)\n 07h = Read GPU version (1 or 2)\n 08h = Unknown (Returns 00000000h) (lightgun? VRAM size set via GP1(09h)?)\n 09h-0Fh = Returns Nothing (old value in GPUREAD remains unchanged)\n 10h-FFFFFFh = Mirrors of 00h..0Fh\n 0 Allow Y coordinates in 512-1023 range (0=No/wrap to 0-511, 1=Yes)\n 1-23 Unknown (seems to have no effect)\n 0-23 Unknown (501h=1 MB, 504h=2 MB, or so?)\n 0-10 Unknown (GPU crashes after a while when set to 274h..7FFh)\n 11-23 Unknown (seems to have no effect)\nNot used?
"},{"location":"graphicsprocessingunitgpu/#gp140hffh-na-mirrors","title":"GP1(40h..FFh) - N/A (Mirrors)","text":"Mirrors of GP1(00h..3Fh).
"},{"location":"graphicsprocessingunitgpu/#mis-centered-pal-games-wrong-gp106hgp107h-settings","title":"Mis-Centered PAL Games (wrong GP1(06h)/GP1(07h) settings)","text":"NTSC games are typically well centered (using X1=260h, and Y1/Y2=88h+/-N). PAL games should be centered as X1=260h, and Y1/Y2=A3h+/-N) - these values would be looking well on a Philips Philetta TV Set, and do also match up with other common picture positions (eg. as used by Nintendo's SNES console). However, most PAL games are using completely different \"random\" centering values (maybe caused by different developers trying to match the centering to the different TV Sets) (although it looks more as if the PAL developers just went amok: Many PAL games are even using different centerings for their Intro, Movie, and actual Game sequences). In result, most PAL games are looking like crap when playing them on a real PSX. For PSX emulators it may be recommended to ignore the GP1(06h)/GP1(07h) centering, and instead, apply auto-centering to PAL games. For PAL game developers, it may be recommended to add a screen centering option (as found in Tomb Raider 3, for example). Unknown if this is really required... or if X1=260h, and Y1/Y2=A3h+/-N would work fine on most or all PAL TV Sets?
"},{"location":"graphicsprocessingunitgpu/#gpu-status-register","title":"GPU Status Register","text":""},{"location":"graphicsprocessingunitgpu/#1f801814h-gpustat-gpu-status-register-r","title":"1F801814h - GPUSTAT - GPU Status Register (R)","text":" 0-3 Texture page X Base (N*64) ;GP0(E1h).0-3\n 4 Texture page Y Base 1 (N*256) (ie. 0, 256, 512 or 768) ;GP0(E1h).4\n 5-6 Semi-transparency (0=B/2+F/2, 1=B+F, 2=B-F, 3=B+F/4) ;GP0(E1h).5-6\n 7-8 Texture page colors (0=4bit, 1=8bit, 2=15bit, 3=Reserved)GP0(E1h).7-8\n 9 Dither 24bit to 15bit (0=Off/strip LSBs, 1=Dither Enabled);GP0(E1h).9\n 10 Drawing to display area (0=Prohibited, 1=Allowed) ;GP0(E1h).10\n 11 Set Mask-bit when drawing pixels (0=No, 1=Yes/Mask) ;GP0(E6h).0\n 12 Draw Pixels (0=Always, 1=Not to Masked areas) ;GP0(E6h).1\n 13 Interlace Field (or, always 1 when GP1(08h).5=0)\n 14 Flip screen horizontally (0=Off, 1=On, v1 only) ;GP1(08h).7\n 15 Texture page Y Base 2 (N*512) (only for 2 MB VRAM) ;GP0(E1h).11\n 16 Horizontal Resolution 2 (0=256/320/512/640, 1=368) ;GP1(08h).6\n 17-18 Horizontal Resolution 1 (0=256, 1=320, 2=512, 3=640) ;GP1(08h).0-1\n 19 Vertical Resolution (0=240, 1=480, when Bit22=1) ;GP1(08h).2\n 20 Video Mode (0=NTSC/60Hz, 1=PAL/50Hz) ;GP1(08h).3\n 21 Display Area Color Depth (0=15bit, 1=24bit) ;GP1(08h).4\n 22 Vertical Interlace (0=Off, 1=On) ;GP1(08h).5\n 23 Display Enable (0=Enabled, 1=Disabled) ;GP1(03h).0\n 24 Interrupt Request (IRQ1) (0=Off, 1=IRQ) ;GP0(1Fh)/GP1(02h)\n 25 DMA / Data Request, meaning depends on GP1(04h) DMA Direction:\n When GP1(04h)=0 ---> Always zero (0)\n When GP1(04h)=1 ---> FIFO State (0=Full, 1=Not Full)\n When GP1(04h)=2 ---> Same as GPUSTAT.28\n When GP1(04h)=3 ---> Same as GPUSTAT.27\n 26 Ready to receive Cmd Word (0=No, 1=Ready) ;GP0(...) ;via GP0\n 27 Ready to send VRAM to CPU (0=No, 1=Ready) ;GP0(C0h) ;via GPUREAD\n 28 Ready to receive DMA Block (0=No, 1=Ready) ;GP0(...) ;via GP0\n 29-30 DMA Direction (0=Off, 1=?, 2=CPUtoGP0, 3=GPUREADtoCPU) ;GP1(04h).0-1\n 31 Drawing even/odd lines in interlace mode (0=Even or Vblank, 1=Odd)\nFurther GPU status information can be retrieved via GP1(10h) and GP0(C0h).
"},{"location":"graphicsprocessingunitgpu/#ready-bits","title":"Ready Bits","text":"Bit28: Normally, this bit gets cleared when the command execution is busy (ie. once when the command and all of its parameters are received), however, for Polygon and Line Rendering commands, the bit gets cleared immediately after receiving the command word (ie. before receiving the vertex parameters). The bit is used as DMA request in DMA Mode 2, accordingly, the DMA would probably hang if the Polygon/Line parameters are transferred in a separate DMA block (ie. the DMA probably starts ONLY on command words). Bit27: Gets set after sending GP0(C0h) and its parameters, and stays set until all data words are received; used as DMA request in DMA Mode 3. Bit26: Gets set when the GPU wants to receive a command. If the bit is cleared, then the GPU does either want to receive data, or it is busy with a command execution (and doesn't want to receive anything). Bit25: This is the DMA Request bit, however, the bit is also useful for non-DMA transfers, especially in the FIFO State mode.
"},{"location":"graphicsprocessingunitgpu/#gpu-versions","title":"GPU Versions","text":""},{"location":"graphicsprocessingunitgpu/#summary-of-gpu-differences","title":"Summary of GPU Differences","text":" Differences... v0 (160-pin) v1 (208-pin prototype) v2 (208-pin)\n GPU Chip CXD8514Q CXD8538Q CXD8561Q/BQ/CQ/CXD9500Q\n Mainboard EARLY-PU-8 and below Arcade boards only LATE-PU-8 and up\n Memory Type Dual-ported VRAM Dual-ported VRAM? Normal DRAM\n GPUSTAT.13 when interlace=off always 0 unknown always 1\n GPUSTAT.14 always 0 screen flip nonfunctional screen flip\n GPUSTAT.15 always 0 always 0? bit1 of texpage Y base\n GP1(10h:index3..4) 19-bit (1 MB VRAM) 22-bit (2 MB VRAM) 20-bit (2 MB VRAM)\n GP1(10h:index7) N/A 00000001h version 00000002h version\n GP1(10h:index8) mirror of index0 00000000h zero 00000000h zero\n GP1(10h:index9..F) mirror of index1..7 unknown N/A\n GP1(09h) N/A N/A VRAM size\n GP1(20h) N/A VRAM size/settings N/A\n GP0(E1h).bit11 N/A N/A bit1 of texpage Y base\n GP0(E1h).bit12/13 without x/y-flip without x/y-flip with x/y-flip\n GP0(03h) N/A (no stored in fifo) unknown unknown/unused command\n Shaded Textures ((color/8)*texel)/2 unknown (color*texel)/16\n GP0(02h) FillVram xpos.bit0-3=0Fh=bugged unknown xpos.bit0-3=ignored\n\n dma-to-vram: doesn't work with blksiz>10h (v2 gpu works with blksiz=8C0h!)\n dma-to-vram: MAYBE also needs extra software-handshake to confirm DMA done?\n 320*224 pix = 11800h pix = 8C00h words\nThe v0 GPU crops 8:8:8 bit gouraud shading color to 5:5:5 bit before multiplying it with the texture color, resulting in rather poor graphics. For example, the snow scence in the first level of Tomb Raider I looks a lot smoother on v2 GPUs. This bug was presumably already fixed on the v1 prototype GPU (unconfirmed). The cropped colors are looking a bit as if dithering would be disabled (although, technically dithering works fine, but due to the crippled color input, it's always using the same dither pattern per 8 intensities, instead of using 8 different dither patterns).
"},{"location":"graphicsprocessingunitgpu/#memoryrendering-timings","title":"Memory/Rendering Timings","text":"The v0 GPU uses two Dual-ported VRAM chips (each with two 16bit databusses, one for CPU/DMA/rendering access, and one for output to the video DAC). The New GPU uses s normal DRAM chip (with single 32bit databus). The exact timing differences are unknown, but the different memory types should result in quite different timings: The v0 GPU might perform better on non-32bit aligned accesses, and on memory accesses performed simultaneously with DAC output. On the other hand, the v2 GPU's DRAM seems to be faster in some cases (for example, during Vblank, it's fast enough to perform DMA's with blksiz>10h, which exceeds the GPU's FIFO size, and causes lost data on v0 GPUs).
"},{"location":"graphicsprocessingunitgpu/#xy-flip-and-psone-2-mb-vram","title":"X/Y-Flip and PSone 2 MB VRAM","text":"The X/Y-flipping feature may be used by arcade games (provided that the arcade board is fitted with v2 GPUs). The flipping feature does also work on retail consoles with v2 GPUs, but PSX games should never use that feature (for maintaining compatiblity with older PSX consoles). Some PSone consoles seem to be fitted with 2 MB VRAM chips (maybe because smaller chips had not been in production anymore), but only the first 1 MB region is accessible. However, as all PSone models use a v2 GPU which supports 2 MB VRAM, it should be possible to rewire the chip selects to make the upper half accessible.
"},{"location":"graphicsprocessingunitgpu/#gpu-detection-and-optional-vram-size-switching","title":"GPU Detection (and optional VRAM size switching)","text":"Below is slightly customized GPU Detection function taken from Perfect Assassin (the index7 latching works ONLY on v1/v2 GPUs, whilst v0 GPUs would leave the latched value unchanged; as a workaround, the index4 latching is used to ensure that the latch won't contain 000002h on v0 GPUs, assuming that index4 is never set to 000002h).
[1F801814h]=10000004h ;GP1(10h).index4 (latch draw area bottom right)\n [1F801814h]=10000007h ;GP1(10h).index7 (latch GPU version, if any)\n if ([1F801810h] AND 00FFFFFFh)=00000002h then goto @@gpu_v2\n [1F801810h]=([1F801814h] AND 3FFFh) OR E1001000h ;change GPUSTAT via GP0(E1h)\n dummy=[1F801810h] ;dummy read (unknown purpose)\n if ([1F801814h] AND 00001000h) then goto @@gpu_v1 else goto @@gpu_v0\n ;---\n @@gpu_v0:\n return 0\n ;---\n @@gpu_v1:\n if want_2mb_vram then [1F801814h]=20000504h ;GP1(20h)\n return 1\n ;---\n @@gpu_v2:\n if want_2mb_vram then [1F801814h]=09000001h ;GP1(09h)\n return 2\nThe FillVram command does normally ignore the lower 4bit of the x-coordinate (and software should always set those bits to zero). However, if the 4bits are all set, then the old v0 GPU does write each 2nd pixel to wrong memory address. For example, a 32x4 pixel fill produces following results for x=0..1Fh:
0h 10h 20h 30h 40h\n | | | | |\n ################################ ;\\x=00h..0Eh\n ################################ ; and, x=0Fh\n ################################ ; on v2 GPU\n ################################ ;/\n # # # # # # # ################## # # # # # # # ;\\\n # # # # # # # ################## # # # # # # # ; x=0Fh\n # # # # # # # ################## # # # # # # # ; on v0 GPU\n # # # # # # # ################## # # # # # # # ;/\n ################################ ;\\x=10h..1Eh\n ################################ ; and, x=1Fh\n ################################ ; on v2 GPU\n ################################ ;/\n # # # # # # # ################## # # # # # # # ;\\\n # # # # # # # ################## # # # # # # # ; x=1Fh\n # # # # # # # ################## # # # # # # # ; on v0 GPU\n # # # # # # # ################## # # # # # # # ;/\nThe PlayStation's GPU stores only RGB colors in the framebuffer (ie. unlike modern 3D processors, it's NOT buffering Depth values; leaving apart the Mask bit, which could be considered as a tiny 1bit \"Depth\" or \"Priority\" value). In fact, the GPU supports only X,Y coordinates, and it's totally unaware of Z coordinates. So, when rendering a polygon, the hardware CANNOT determine which of the new pixels are in front/behind of the old pixels in the buffer.
"},{"location":"graphicsprocessingunitgpu/#simple-ordering","title":"Simple Ordering","text":"The rendering simply takes place in the ordering as the data is sent to the GPU (ie. the most distant objects should be sent first). For 2D graphics, it's fairly easy follow that order (eg. even multi-layer 2D graphics can be using DMA2-continous mode).
"},{"location":"graphicsprocessingunitgpu/#depth-ordering-table-ot","title":"Depth Ordering Table (OT)","text":"For 3D graphics, the ordering of the polygons may change more or less randomly (eg. when rotating/moving the camera). To solve that problem, the whole rendering data is usually first stored in a Depth Ordering Table (OT) in Main RAM, and, once when all polygons have been stored in the OT, the OT is sent to the GPU via \"DMA2-linked-list\" mode.
"},{"location":"graphicsprocessingunitgpu/#initializing-an-empty-ot-via-dma6","title":"Initializing an empty OT (via DMA6)","text":"DMA channel 6 can be used to set up an empty linked list, in which each entry points to the previous:
DPCR - enable bits ;Example=x8xxxxxxh\n D6_MADR - pointer to the LAST table entry ;Example=8012300Ch\n D6_BCR - number of list entries ;Example=00000004h\n D6_CHCR - control bits (should be 11000002h) ;Example=11000002h\n [80123000h]=00FFFFFFh ;1st entry, points to end code (xxFFFFFFh)\n [80123004h]=00123000h ;2nd entry, points to 1st entry\n [80123008h]=00123004h ;3rd entry, points to 2nd entry\n [8012300Ch]=00123008h ;last entry, points to 3rd entry (table entrypoint)\nThe GTE commands AVSZ3 and AVSZ4 can be used to calculate the Average Z coordinates of a polygon (based on its three or four Z coordinates). The result is returned as a 16bit Z value in GTE register OTZ, the commands do also allow to divide the result, to make it less than 16bit (the full 16bit would require an OT of 256KBytes - for the EMPTY table, which would be a waste of memory, and which would slowdown the DMA2/DMA6 operations) (on the other hand, a smaller table means less depth resolution).
[PacketAddr+0] = [80123000h+OTZ*4] + (N SHL 24) <--internal link chain\n [PacketAddr+4..N*4] = GP0 Command(s) and Parameters <--data (send to GP0)\n [80123000h+OTZ*4] = PacketAddr AND FFFFFFh <--internal link chain\n 1 - Wait until GPU is ready to receive commands ;GPUSTAT.28\n 2 - Enable DMA channel 2 ;DPCR\n 3 - Set GPU to DMA cpu->gpu mode ;[GP1]=04000002h aka GP1(04h)\n 3 - Set D2_MADR to the start of the list ;(LAST Entry) ;Example=80123010h\n 4 - Set D2_BCR to zero ;(length unused, end at END-CODE)\n 5 - Set D2_CHCR to link mode, mem->GPU and dma enable ;=01000401h\nThe framebuffer contains the image that is to be output to the Television Set. The GPU supports 10 resolutions, with 16bit or 24bit per pixel.
Resolution 16bit 24bit | Resolution 16bit 24bit\n 256x240 120Kbytes 180Kbytes | 256x480 240Kbytes 360Kbytes\n 320x240 150Kbytes 225Kbytes | 320x480 300Kbytes 450Kbytes\n 368x240 xx0Kbytes xx0Kbytes | 368x480 xx0Kbytes xx0Kbytes\n 512x240 240Kbytes 360Kbytes | 512x480 480Kbytes 720Kbytes\n 640x240 300Kbytes 450Kbytes | 640x480 600Kbytes 900Kbytes\n<B> 15bit Direct Display (default) (works with polygons, lines, rectangles)</B>\n 0-4 Red (0..31)\n 5-9 Green (0..31)\n 10-14 Blue (0..31)\n 15 Mask flag (0=Normal, 1=Do not allow to overwrite this pixel)\n<B> 24bit Direct Display (works ONLY with direct vram transfers)</B>\n 0-7 Red (0..255)\n 8-15 Green (0..255)\n 16-23 Blue (0..255)\nA texture is an image put on a polygon or sprite. The data of a texture can be stored in 3 different modes:
<B> 16bit Texture (Direct Color) ;(One 256x256 page = 128Kbytes)</B>\n 0-4 Red (0..31) ;\\Color 0000h = Fully-transparent\n 5-9 Green (0..31) ; Color 0001h..7FFFh = Non-transparent\n 10-14 Blue (0..31) ; Color 8000h..FFFFh = Semi-transparent (*)\n 15 Semi-transparency Flag ;/(*) or Non-transparent for opaque commands\n<B> 8bit Texture (256 Color Palette) ;(One 256x256 page = 64Kbytes)</B>\n 0-7 Palette index for 1st pixel (left)\n 8-15 Palette index for 2nd pixel (right)\n<B> 4bit Texture (16 Color Palette) ;(One 256x256 page = 32Kbytes)</B>\n 0-3 Palette index for 1st pixel (left)\n 4-7 Palette index for 2nd pixel (middle/left)\n 8-11 Palette index for 3rd pixel (middle/right)\n 12-15 Palette index for 4th pixel (right)\nThe clut is a the table where the colors are stored for the image data in the CLUT modes. The pixels of those images are used as indexes to this table. The clut is arranged in the frame buffer as a 256x1 image for the 8bit clut mode, and a 16x1 image for the 4bit clut mode.
0-4 Red (0..31) ;\\Color 0000h = Fully-transparent\n 5-9 Green (0..31) ; Color 0001h..7FFFh = Non-transparent\n 10-14 Blue (0..31) ; Color 8000h..FFFFh = Semi-transparent (*)\n 15 Semi-transparency Flag ;/(*) or Non-transparent for opaque commands\nOn the PSX, texture color 0000h is fully-transparent, that means textures cannot contain Black pixels. However, in some cases, Color 8000h (Black with semi-transparent flag) can be used, depending on the rendering command:
opaque command, eg. GP0(24h) --> 8000h = Non-Transparent Black\n semi-transp command, eg. GP0(26h) --> 8000h = Semi-Transparent Black\nThe GPU has 2 Kbyte Texture Cache There is also a CLUT cache that is preserved between GPU drawing commands. The CLUT cache is invalidated when different CLUT index values are used or when GP0(01h) is issued. If polygons with texture are displayed, the GPU needs to read these from the frame buffer. This slows down the drawing process, and as a result the number of polygons that can be drawn in a given timespan. To speed up this process the GPU is equipped with a texture cache, so a given piece of texture needs not to be read multiple times in succession. The texture cache size depends on the color mode used for the textures. In 4 bit CLUT mode it has a size of 64x64, in 8 bit CLUT it's 32x64 and in 15bitDirect is 32x32. A general speed up can be achieved by setting up textures according to these sizes. For further speed gain a more precise knowledge of how the cache works is necessary.
"},{"location":"graphicsprocessingunitgpu/#cache-blocks","title":"Cache blocks","text":"The texture page is divided into non-overlapping cache blocks, each of a unit size according to color mode. These cache blocks are tiled within the texture page.
+-----+-----+-----+--\n |cache| | |\n |block| |\n | 0| 1 | 2 ..\n +-----+-----+--\n |.. | |\nEach cache block is divided into 256 cache entries, which are numbered sequentially, and are 8 bytes wide. So a cache entry holds 16 4bit clut pixels 8 8bit clut pixels, or 4 15bitdirect pixels.
4bit and 8bit clut: 15bitdirect:\n +----+----+----+----+ +----+----+----+----+----+----+----+----+\n | 0| 1| 2| 3| | 0| 1| 2| 3| 4| 5| 6| 7|\n +----+----+----+----+ +----+----+----+----+----+----+----+----+\n | 4| 5| 6| 7| | 8| 9| a| b| c| d| e| f|\n +----+----+----+----+ +----+----+----+----+----+----+----+----+\n | 8| 9| .. | 10| 11| ..\n +----+----+-- +----+----+--\n | c| ..| | 18| ..|\n +----+-- +----+--\n | .. | ..\n NTSC video clock = 53.693175 MHz\n PAL video clock = 53.203425 MHz\n 263 scanlines per field for NTSC non-interlaced\n 262.5 scanlines per field for NTSC interlaced\n\n 314 scanlines per field for PAL non-interlaced\n 312.5 scanlines per field for PAL interlaced\n NTSC mode on NTSC video clock\n Interlaced: 59.940 Hz\n Non-interlaced: 59.826 Hz\n\n PAL mode on PAL video clock\n Interlaced: 50.000 Hz\n Non-interlaced: 49.761 Hz\n\n NTSC mode on PAL video clock\n Interlaced: 59.393 Hz\n Non-interlaced: 59.280 Hz\n\n PAL mode on NTSC video clock\n Interlaced: 50.460 Hz\n Non-interlaced: 50.219 Hz\nTODO: Derivations for vertical refresh rates; horizontal timing notes
Nocash's original GPU Timings notes:
"},{"location":"graphicsprocessingunitgpu/#video-clock","title":"Video Clock","text":"The PSone/PAL video clock is the cpu clock multiplied by 11/7.
CPU Clock = 33.868800MHz (44100Hz*300h)\n Video Clock = 53.222400MHz (44100Hz*300h*11/7)\n PAL: 314 scanlines per frame (13Ah)\n NTSC: 263 scanlines per frame (107h)\n PAL: 3406 video cycles per scanline (or 3406.1 or so?)\n NTSC: 3413 video cycles per scanline (or 3413.6 or so?)\n PSX.256-pix Dotclock = 5.322240MHz (44100Hz*300h*11/7/10)\n PSX.320-pix Dotclock = 6.652800MHz (44100Hz*300h*11/7/8)\n PSX.368-pix Dotclock = 7.603200MHz (44100Hz*300h*11/7/7)\n PSX.512-pix Dotclock = 10.644480MHz (44100Hz*300h*11/7/5)\n PSX.640-pix Dotclock = 13.305600MHz (44100Hz*300h*11/7/4)\n Namco GunCon 385-pix = 8.000000MHz (from 8.00MHz on lightgun PCB)\n 320pix/PAL: 3406/8 = 425.75 dots 320pix/NTSC: 3413/8 = 426.625 dots\n 640pix/PAL: 3406/4 = 851.5 dots 640pix/NTSC: 3413/4 = 853.25 dots\n 256pix/PAL: 3406/10 = 340.6 dots 256pix/NTSC: 3413/10 = 341.3 dots\n 512pix/PAL: 3406/5 = 681.2 dots 512pix/NTSC: 3413/5 = 682.6 dots\n 368pix/PAL: 3406/7 = 486.5714 dots 368pix/NTSC: 3413/7 = 487.5714 dots\n PAL: 53.222400MHz/314/3406 = ca. 49.76 Hz (ie. almost 50Hz)\n NTSC: 53.222400MHz/263/3413 = ca. 59.29 Hz (ie. almost 60Hz)\nAbove values include \"hidden\" dots and scanlines (during horizontal and vertical blanking/retrace).
"},{"location":"graphicsprocessingunitgpu/#gpu-misc","title":"GPU (MISC)","text":""},{"location":"graphicsprocessingunitgpu/#gp020h7fh-render-command-bits","title":"GP0(20h..7Fh) - Render Command Bits","text":" 0-23 Color for (first) Vertex (Not for Raw-Texture)\n 24 Texture Mode (0=Blended, 1=Raw) (Textured-Polygon/Rect only)\n 25 Semi-transparency (0=Off, 1=On) (All Render Types)\n 26 Texture Mapping (0=Off, 1=On) (Polygon/Rectangle only)\n 27-28 Rect Size (0=Var, 1=1x1, 2=8x8, 3=16x16) (Rectangle only)\n 27 Num Vertices (0=Triple, 1=Quad) (Polygon only)\n 27 Num Lines (0=Single, 1=Poly) (Line only)\n 28 Shading (0=Flat, 1=Gouroud) (Polygon/Line only)\n 29-31 Primitive Type (1=Polygon, 2=Line, 3=Rectangle)\nThe PSX doesn't support perspective correct rendering: Assume a polygon to be rotated so that it's right half becomes more distant to the camera, and it's left half becomes closer. Due to the GTE's perspective division, the right half should appear smaller than the left half. The GPU supports only linear interpolations for rendering - that is correct concerning the X and Y screen coordinates (which are still linear to each other, even after perspective division, since both are divided by the same value). However, texture coordinates (and Gouraud shaded colors) are NOT linear to the screen coordinates, and so, the linear interpolated PSX graphics are often looking rather distorted, that especially for textures that contain straight lines. For color shading the problem is less obvious (since shading is kinda blurry anyways).
"},{"location":"graphicsprocessingunitgpu/#perspective-correct-rendering","title":"Perspective correct Rendering","text":"For perspective correct rendering, the polygon's Z-coordinates would be needed to be passed from the GTE to the GPU, and, the GPU would then need to use that Z-coordinates to \"undo\" the perspective division for each pixel (that'd require some additional memory, and especially a powerful division unit, which isn't implemented in the hardware). As a workaround, you can try to reduce the size of your polygons (the interpolation errors increase in the center region of larger polygons). Reducing the size would be only required for polygons that occupy a larger screen region (which may vary depending on the distance to the camera). Ie. you may check the size AFTER perspective division, if it's too large, then break it into smaller parts (using the original coordinates, NOT the screen coordinates), and then pass the fragments to the GTE another time. Again, perspective correction would be relevant only for certain textures (not for randomly dithered textures like sand, water, fire, grass, and not for untextured polygons, and of course not for 2D graphics, so you may exclude those from size reduction).
"},{"location":"graphicsprocessingunitgpu/#24bit-rgb-to-15bit-rgb-dithering-enabled-in-texpage-attribute","title":"24bit RGB to 15bit RGB Dithering (enabled in Texpage attribute)","text":"For dithering, VRAM is broken to 4x4 pixel blocks, depending on the location in that 4x4 pixel region, the corresponding dither offset is added to the 8bit R/G/B values, the result is saturated to +00h..+FFh, and then divided by 8, resulting in the final 5bit R/G/B values.
-4 +0 -3 +1 ;\\dither offsets for first two scanlines\n +2 -2 +3 -1 ;/\n -3 +1 -4 +0 ;\\dither offsets for next two scanlines\n +3 -1 +2 -2 ;/(same as above, but shifted two pixels horizontally)\nThe GPU has a shading function, which will scale the color of a primitive to a specified brightness. There are 2 shading modes: Flat shading, and gouraud shading. Flat shading is the mode in which one brightness value is specified for the entire primitive. In Gouraud shading mode, a different brightness value can be given for each vertex of a primitive, and the brightness between these points is automatically interpolated.
"},{"location":"graphicsprocessingunitgpu/#semi-transparency","title":"Semi-transparency","text":"When semi-transparency is set for a pixel, the GPU first reads the pixel it wants to write to, and then calculates the color it will write from the 2 pixels according to the semi-transparency mode selected. Processing speed is lower in this mode because additional reading and calculating are necessary. There are 4 semi-transparency modes in the GPU.
B=Back (the old pixel read from the frame buffer)\n F=Front (the new semi-transparent pixel)\n * 0.5 x B + 0.5 x F ;aka B/2+F/2\n * 1.0 x B + 1.0 x F ;aka B+F\n * 1.0 x B - 1.0 x F ;aka B-F\n * 1.0 x B +0.25 x F ;aka B+F/4\nModulation is a colour effect that can be applied to textured primitives. For each pixel of the primitive it combines every colour channel of the fetched texel with the corresponding channel of the interpolated vertex colour according to this formula (Assuming all channels are 8-bit).
finalChannel.rgb = (texel.rgb * vertexColour.rgb) / vec3(128.0)\nThis will enable/disable any drawing to the area that is currently displayed. Not sure yet WHY one should want to disable that? Also not sure HOW and IF it works... the SIZE of the display area is implied by the screen size - which is horizontally counted in CLOCK CYCLES, so, to obtain the size in PIXELS, the hardware would require to divide that value by the number of cycles per pixel, depending on the current resolution...?
"},{"location":"hardwarenumbers/","title":"Hardware Numbers","text":""},{"location":"hardwarenumbers/#sonys-own-hardware-for-psx-can-be-also-used-with-psone","title":"Sony's own hardware (for PSX) (can be also used with PSone)","text":" SCPH-1000 PlayStation (1994) (NTSC-J) (with S-Video)\n SCPH-1001 PlayStation (1995) (NTSC-U/C) (without S-Video)\n SCPH-1002 PlayStation (199x) (PAL) (without S-Video)\n SCPH-1010 Digital joypad (with short cable) (1994)\n SCPH-1020 Memory Card 1Mbits (1994)\n SCPH-1030 2-button Mouse (with short cable) (1994)\n SCPH-1040 Serial Link Cable\n SCPH-1050 RGB Cable (21-pin RGB Connector)\n SCPH-1060 RFU Cable/Adaptor (antennae connector) (NTSC-JP?) (1995)\n SCPH-1061 RFU Cable/Adaptor (antennae connector) (NTSC-US?)\n SCPH-1062 RFU Cable/Adaptor (antennae connector) (PAL)\n SCPH-1070 Multitap adaptor (four controllers/memory cards on one slot) (1995)\n SCPH-1080 Digital joypad (with longer cable) (1996)\n SCPH-1090 2-button Mouse (with longer cable) (1998)\n SCPH-1100 S Video Cable (1995)\n SCPH-1110 Analog Joystick (1996)\n SCPH-1120 RFU Adaptor (antennae connector) (NTSC-JP?) (1996)\n SCPH-1121 RFU Adaptor (antennae connector) (NTSC-US?)\n SCPH-1122 RFU Adaptor (antennae connector) (PAL)\n SCPH-1130 AC Power Cord (1996)\n SCPH-1140 AV Cable (1997)\n SCPH-1150 Analog Joypad (with one vibration motor, with red/green led) (1997)\n SCPH-1160 AV Adaptor (1997)\n SCPH-1170 Memory Card Triple Pack (three Memory Cards) (1996)\n SCPH-1180 Analog Joypad (without vibration motors, with red/green led)\n SCPH-119X Memory Card (X=different colors) (1997)\n SCPH-1200 Analog Joypad (with two vibration motors) (dualshock) (1997)\n SCPH-1210 Memory Card Case (1998)\n SCPH-2000 Keyboard/Mouse adapter (PS/2 to PSX controller port; for Lightspan)\n SCPH-3000 PlayStation (1995) (NTSC-J) (with the S-video output removed)\n SCPH-3500 PlayStation Fighting Box (console bundled with 2 controllers)(1996)\n SCPH-4000 PocketStation (Memory Card with LCD-screen) (1999)\n SCPH-4010 VPick (guitar-pick controller) (for Quest for Fame, Stolen Song)\n SCPH-4020 Long Strap for PocketStation (1999)\n SCPH-4030 Wrist Strap for PocketStation (1999)\n SCPH-5000 PlayStation (cost reduced) (Japan) (1996) ;\\exists in these three\n SCPH-5001 PlayStation (cost reduced) (North America) ; regions only (not\n SCPH-5003 PlayStation (Asia) ;/in Europe)\n SCPH-5500 PlayStation without Cinch sockets (ie. AV Multi Out only) (1996)(J)\n SCPH-5501 \"\" North American version of the 5500\n SCPH-5502 \"\" European version of the 5500 (shipped with 1 digital joypad)\n SCPH-5552 Same as SCPH-5502 (but shipped with memcard and 2 digital joypads)\n SCPH-5903 PlayStation with built-in MPEG Video-CD decoder (Asia-only)\n SCPH-7000 PlayStation with Dualshock (1997) (Japan)\n SCPH-7001 PlayStation with Dualshock (199x) (North America)\n SCPH-7002 PlayStation with Dualshock (199x) (Europe)\n SCPH-7003 PlayStation with Dualshock (199x) (Asia)\n SCPH-7000W PlayStation (10 million model, not for sale, blue, region free)\n SCPH-7500 PlayStation with Dualshock, cost reduced (1999) (Japan)\n SCPH-7501 PlayStation with Dualshock, cost reduced (199x) (North America)\n SCPH-7502 PlayStation with Dualshock, cost reduced (199x) (Europe)\n SCPH-7503 PlayStation with Dualshock, cost reduced (199x) (Asia)\n SCPH-9000 PlayStation without Parallel I/O port (1999) (Japan)\n SCPH-9001 PlayStation without Parallel I/O port (199x) (North America)\n SCPH-9002 PlayStation without Parallel I/O port (199x) (Europe)\n SCPH-9003 PlayStation without Parallel I/O port (199x) (Asia)\n SCPH-9903 Rare SCEx-free PSX (Property of Sony Computer Entertainment, U/C)\n SFX-100 PlayStation Super Disc Prototype (with SNES chipset, no PSX chips)\n SCPH-100 PSone (miniaturized PlayStation) (2000) (Japan)\n SCPH-101 PSone (miniaturized PlayStation) (200x) (North America)\n SCPH-102 PSone (miniaturized PlayStation) (200x) (Europe)\n SCPH-103 PSone (miniaturized PlayStation) (200x) (Asia)\n SCPH-102A PSone Europe (UK/AU, with A/V cable) ;\\revision of \"SCPH-102\"\n SCPH-102B PSone Europe (UK, with RFU adaptor) ; with PM-41(2) board ?\n SCPH-102C PSone Europe (Continent, with A/V cable) ;/\n SCPH-110 Dual Analog Pad (for PSone) (Dualshock) (2000)\n SCPH-111 Multitap for PSone (seems to be quite rare, except in brazil)\n SCPH-112 AC adapter for PSone (In: 110-220VAC, Out: 7.5VDC, 2.0A, Japan)\n SCPH-113 AC adapter for PSone (In: 120VAC/60Hz, Out: 7.5VDC, 2.0A, USA)\n SCPH-114 AC adapter for PSone (In: 220-240VAC, Out: 7.5VDC, 2.0A, Europe)\n SCPH-115 AC adapter for PSone (In: 220-240VAC, Out: 7.5VDC, 2.0A, UK)\n SCPH-116 AC adapter for PSone (In: 220-240VAC, Out: 7.5VDC, 2.0A, Australia)\n SCPH-117 AC adapter for PSone (In: 110VAC, Out: 7.5VDC, 2.0A, Asia?)\n SCPH-120 AC adapter for PSone with LCD Screen (In: 100VAC, Out: 7.5VDC, 3.0A)\n SCPH-130 LCD Screen for PSone (to be attached to the console) (2001)\n SCPH-140 PSone and LCD screen combo (2001)\n SCPH-152 LCD screen for PSone (PAL SCPH-152C)\n SCPH-162 PSone and LCD screen (PAL SCPH-162C)\n SCPH-170 Car Adapter for PSone from car cigarette lighter (2001)\n SCPH-180 AV Connection Cable for LCD-screen's AV IN\n SCPH-10180K DoCoMo I-Mode Adaptor Cable (for internet via mobile phones)\n SCPH-10150 PS2 DVD remote\n SCPH-10160 IR receiver dongle for PS2 DVD remote\n DTL-H201A Graphic Artist Board (ISA bus) (with NTSC video out)\n DTL-H240 PS-X RGB Cable\n DTL-H500C Digital joypad prototype (SNES-style design, with DB9 connector)\n DTL-H505 PS-X (Code Name) Target Box ? (PSX prototype, SCSI instead CDROM?)\n DTL-H700 Sound Artist Board (NuBus for Mac)\n DTL-H800 Sound Artist Board (PCI Bus for IBM) (with optical fibre sound out)\n DTL-H1000 Debugging Station (CD-R compatible PSX console) (Japan)\n DTL-H1001 Debugging Station (CD-R compatible PSX console) (North America)\n DTL-H1002 Debugging Station (CD-R compatible PSX console) (Europe)\n DTL-H1030 Mouse ?\n DTL-H1040 Link Cable ?\n DTL-H1050 RGB Cable ?\n DTL-H110x Debugging Station revision? (DC-powered)\n DTL-H120x Debugging Station revision? (AC-powered)\n DTL-H1500 Stand-Alone Box ? With ethernet, for SGI Workstation ?\n DTL-H2000 Dev board v1 (PSX on two ISA carts) (old pre-retail)\n DTL-H2010 Black External CDROM Drive for DTL-H2000 (CD-R compatible)\n DTL-H2040 Memory Box ?\n DTL-H2050 Adaptor for Controller port ?\n DTL-H2060 Serial Link cable\n DTL-H2070 RGB Cable ?\n DTL-H2080 Controller Box (joypad/memcard adaptor for DTL-H2000/DTL-xxxx?)\n DTL-H2500 Dev board (PCI bus)\n DTL-H2510 Gray Internal CDROM Drive for DTL-H2500/DTL-H2700 (CD-R compatible)\n DTL-H2700 Dev board (ISA bus) (CPU, ANALYZER ...?)\n DTL-H3000 Net Yaroze (hobby programmer dev kit) (Japan)\n DTL-H3001 Net Yaroze (hobby programmer dev kit) (North America)\n DTL-H3002 Net Yaroze (hobby programmer dev kit) (Europe)\n DTL-H3020 Access Card (for yaroze)\n DTL-H3050 Communication Cable (link port to rs232, for yaroze)\n DTL-D2020 Documentation: BUILD CD (Manual of Programmer's Tool)\n DTL-D2120 Documentation: (Manual of Programmer's Tool)\n DTL-D2130 Documentation: PsyQ (Manual of Programmer's Tool)\n DTL-D2130 Documentation: SdevTC (Manual of Programmer's Tool)\n DTL-D2140A Documentation: Ver.1.0 (Manual of Programmer's Tool)\n DTL-D2150A Documentation: Ver.2.0 (Manual of Programmer's Tool)\n DTL-S510B Unknown (another CDROM emulator version?)\n DTL-S2020 CD-ROM EMULATOR for DTL-H2000/DTL-H2500/DTL-H2700\n SLPH-00001 Namco neGcon (white) (NPC-101), Twist controller (SLEH-0003)\n SLPH-00002 Hori Fighting stick, digital stick with autofire/slowmotion/rumble\n SLPH-00003 ASCII Fighter stick V, psx-shaped digital stick (SLEH-0002)\n SLPH-00004 Sunsoft Sunstation pad, digital pad with autofire/slowmotion\n SLPH-00005 ASCII ASCIIPAD V, digital pad with autofire/slowmotion\n SLPH-00006 Imagineer Sandapaddo ThunderPad\n SLPH-00007 SANKYO N.ASUKA aka Nasca Pachinco Handle, bizarre paddle\n SLPH-00008 Spital SANGYO Programmable joystick\n SLPH-00009 Hori Fighting commander 2way controller\n SLPH-00010 Optec Super Pro Commander\n SLPH-00011 Super Pro Commander Accessory / Extended memo repack memory\n SLPH-00012 Hori Fighting Commander 10B Pad (gray), digital pad with extras\n SLPH-00013 Konami Hyper Blaster (green) ;\\IRQ10-based Lightgun\n SLPH-00014 Konami Hyper Blaster (black) ;/(SLEH-0005/SLUH-00017)\n SLPH-00015 Namco Volume controller, paddle with 2 buttons\n SLPH-00016 Waka Up Scan Converter \"[chiyo] clean! peripheral equipment?\"\n SLPH-00017 Hori Fighting Commander 10B Pad (black), digital pad with extras\n SLPH-00018 Hori Real Arcade Stick, digital stick, small L1/L2 (HPS-10)\n SLPH-00019 Konami Hyperstick\n SLPH-00020 Imagineer Thunder Pad Transparent\n SLPH-00021 Imagineer Imagegun\n SLPH-00022 Optec AI Commander Pro, digital pad with extras / lcd display\n SLPH-00023 Namco Joystick (SLEH-00004)\n SLPH-00024 Optec Cockpit Wheel, analog joystick/analog pedals or so\n SLPH-00025 Optec AI Commander Accessory (extended memo repack ZERO2 version)\n SLPH-00026 Hori Command Stick PS (SLPH-00026 aka HPS11)\n SLPH-00027 ASCII Grip, single-handed digital pad (SLEH-00008)\n SLPH-00028 Hori Grip (gray) (see also: SLPH-00040, and 00086..00088)\n SLPH-00029 Hori Horipad (clear), digital pad\n SLPH-00030 Hori Horipad (black), digital pad\n SLPH-00031 Hori Horipad (gray), digital pad\n SLPH-00032 Hori Horipad (white), digital pad\n SLPH-00033 Hori Horipad (blue), digital pad\n SLPH-00034 Namco G-CON 45, Cinch-based Lightgun (SLEH-0007/SLUH-00035)\n SLPH-00035 ASCII Fighter stick V Jr. (SLEH-00009)\n SLPH-00036 Optec Wireless Dual Shot, digital pad with turbo button\n SLPH-00037 ?\n SLPH-00038 ASCII Pad V Jr., digital pad without any extras\n SLPH-00039 ASCII Pad V2 (gray), digital pad with turbo switches (SLEH-00010)\n SLPH-00040 Hori Grip (black)\n SLPH-00041 ASCII Grip V\n SLPH-00042 ASCII Grip V plus (Derby Stallion'99 supplement set), single-hand\n SLPH-00043 ASCII Pad V2 (clear pink)\n SLPH-00044 ASCII Pad V2 (clear white)\n SLPH-00045 ASCII Pad V2 (clear blue)\n SLPH-00046 ASCII Pad V2 (clear green)\n SLPH-00047 ASCII Pad V2 (clear black)\n SLPH-00048 ASCII Pad V2 (clear red/lead?)\n SLPH-00049 ASCII Pad V2 (clear yellow)\n SLPH-00050 ASCII Pad V2 (clear orange)\n SLPH-00051 Taito Streetcar GO! Controller 2 steering \"wheel?\" tie toe strange\n SLPH-00052 Koei Video Capture, Ergosoft EGWord, and Lexmark Printer bundle\n SLPH-00053 Koei Word Processor Ergosoft September EGWORD Ver.2.00\n SLPH-00054 Hori Zerotech Steering Controller (black)\n SLPH-00055 Hori Grip (clear blue)\n SLPH-00056 Hori Grip (clear pink)\n SLPH-00057 Hori Grip (clear yellow)\n SLPH-00058 ASCII Pad V2 (gold)\n SLPH-00059 ASCII Pad V2 (silver)\n SLPH-00060 ASCII Biohazard, digital pad with re-arranged buttons (SLEH-0011)\n SLPH-00061 ASCII Pad V2 (pearl white)\n SLPH-00062 ASCII Pad V2 (pearl blue)\n SLPH-00063 ASCII Pad V2 (pearl pink)\n SLPH-00064 ASCII Pad V2 (pearl green)\n SLPH-00065 ASCII Pad V Pro, with lcd for button-combinations (ASC-0508GX)\n SLPH-00066 ASCII Arcade Stick 3 \"Ultimate\"\n SLPH-00067 ASCII Pad V2 (purple metallic)\n SLPH-00068 ASCII Pad V2 (lead metallic)\n SLPH-00069 Namco neGcon (black) (NPC-104), Twist controller (SLEH-0003)\n SLPH-00070 Sankyo Pachinko FF Controller (alternate to SLPH-00007)\n SLPH-00071 Hori Command Stick PS Custom\n SLPH-00072 ASCII Command Pack (memory card add-on or so)\n SLPH-00073 Optec Wireless digital set (gray) ;\\\n SLPH-00074 Optec Wireless digital set (black) ; pad with receiver\n SLPH-00075 Optec Wireless digital set (clear) ;\n SLPH-00076 Optec Wireless digital set (clear blue) ;\n SLPH-00077 Optec Wireless digital set (clear black) ;/\n SLPH-00078 Optec Wireless digital shot (gray) ;\\\n SLPH-00079 Optec Wireless digital shot (black) ; extra pad for\n SLPH-00080 Optec Wireless digital shot (clear) ; second player\n SLPH-00081 Optec Wireless digital shot (clear blue) ; (without receiver)\n SLPH-00082 Optec Wireless digital shot (clear black) ;/\n SLPH-00083 ASCII Stick Justice controller\n SLPH-00084 Hori ZeroTech Steering Controller (clear)\n SLPH-00085 Hori Compact joystick (black)\n SLPH-00086 Hori Compact joystick (clear)\n SLPH-00087 Hori Compact joystick (clear blue)\n SLPH-00088 Hori Multi Analog Pad (clear) or Hori Grip (pink?)\n SLPH-00089 Hori AV Cable with selector\n SLPH-00090 Hori Multi Analogue Pad (clear black)\n SLPH-00091 Hori AV Multi-Out Converter\n SLPH-00092 ASCII Pad V2 (margin green)\n SLPH-00093 ASCII Pad V2 (margin blue)\n SLPH-00094 ASCII Pad V2 (margin pink)\n SLPH-00095 ASCII Pad V2 (margin orange)\n SLPH-00096 ASCII Hyper Steering V (\"high pass tear ring V controller?\")\n SLPH-00097 Hori S Cable with selector (uh, maybe S-video or so?) (HPS-36)\n SLPH-00098 NSYSCOM Pachinko slot controller (NSC-1)\n SLPH-00099 ASCII Pad V2 (rainbow)\n SLPH-00100 ASCII 'Hanging' Fishing Controller, controller for fishing games\n SLPH-00101 Optec Cockpit big shock\n SLPH-00102 ASCII Grip V (set for mars story)\n SLPH-00103 Hori Pad V2 (clear)\n SLPH-00104 Hori Pad V2 (clear blue)\n SLPH-00105 Hori Pad V2 (clear pink)\n SLPH-00106 Hori Pad V2 (black)\n SLPH-00107 Hori Compact Joystick (camouflage)\n SLPH-00108 Hori Rumble Digital Pad (clear blue)\n SLPH-00109 Hori Monoaural AV Cable\n SLPH-00110 ASCII Pad V2 (marble)\n SLPH-00111 ASCII Pad V2 (camouflage)\n SLPH-00112 ASCII Pad V3\n SLPH-00113 ASCII Pad V3 with cable reel\n SLPH-00114 ASCII Pad V3 with V2 (pearl white) bundle\n SLPH-00115 ASCII Pad V3 with V2 (pearl pink) bundle\n SLPH-00116 ASCII Pad V3 with V2 (pearl blue) bundle\n SLPH-00117 ASCII Pad V3 (blue) with V2 (pearl green) bundle\n SLPH-00118 Hori Pad V3\n SLPH-00119 Hori Pad V3 (white)\n SLPH-00120 Hori Analog Rumble Pad (clear pink)\n SLPH-00121 Hori Analog Rumble Pad (clear)\n SLPH-00122 Hori Analog Rumble Pad (clear blue)\n SLPH-00123 Hori Analog Rumble Pad (clear red)\n SLPH-00124 Hori Analog Rumble Pad (clear black)\n SLPH-00125 Hori Analog Rumble Pad (clear yellow)\n SLPH-00126 Namco Jogcon, digital pad, steering dial (SLEH-0020/SLUH-00059)\n SLPH-00127 ?\n SLPH-00128 ASCII stick ZERO3\n SLPH-00129 ASCII Pad V2 (wood grain pitch)\n SLPH-00130 Hori Real Arcade (camouflage)\n SLPH-00131 Hori Ehrgeiz Stick\n SLPH-00132 ASCII Pad V3 (blue)\n SLPH-00133 ASCII Fighter Stick V Jr. (limited edition)\n SLPH-00134 ASCII Pad V3 (blue) with cable reel\n SLPH-00135 ASCII Pad V3 (blue) with V2 (silver)\n SLPH-00136 ASCII Pad V3 with V2 (purple metallic)\n SLPH-00137 ASCII Pad V3 with V2 (gold)\n SLPH-00138 ASCII Pad V3 with \"VPRO. aka Ascii Fighter Stick V\"\n SLPH-00139 Hori Analog Rumble Pad (gray)\n SLPH-00140 Hori Analog Rumble Pad (black)\n SLPH-00141 Hori Analog Rumble Pad (blue)\n ASC-05158B ASCII Beatmania Junk (similar to SLEH-0021)\n ASC-0528T Sammy Shakkato Tambourine\n BANC-0001 Bandai Fishing Controller\n BANC-0002 Bandai Kids Station\n RU017 Konami Dance Dance Revolution Controller (Dance Mat)\n GAE001 G.A.E. Baton stick with 2 buttons (for The Maestromusic)\n RU029 Konami Beatmania IIDX\n RU014 Konami Pop'n Music (buttons A,B,C,D,E,F,G,H,I, and Select/Start)\n RU014-J2 Konami Pop'n Controller 2\n RU036 Konami Pop'n Controller (Arcade Style)\n ? Produce! Paca Paca Passion\n ? Sega/Ascii Minimoni Shakatto Tambourine\n SLEH-00001 Ascii Specialized Pad (similar to SLPH-00005: ASCII ASCIIPAD V)\n SLEH-00002 Ascii Arcade Stick, psx-shaped digital stick (SLPH-00003)\n SLEH-00003 Namco Negcon, Twist controller (SLPH-00001)\n SLEH-00004 Namco Arcade Stick (SLPH-00023)\n SLEH-00005 Konami Hyper Blaster, IRQ10-based Lightgun (SLPH-00014/SLUH-00017)\n SLEH-00006 Mad Catz Steering Wheel (SLPH-?)\n SLEH-00007 Namco G-Con 45, Cinch-based Lightgun (SLPH-00034/SLUH-00035)\n SLEH-00008 Ascii Grip, single-handed digital pad (SLPH-00027/SLUH-00038)\n SLEH-00009 Ascii Arcade Stick v2 (SLPH-00035)\n SLEH-00010 Ascii Enhanced Control Pad (similar as SLEH-00001) (SLPH-00039)\n SLEH-00011 Resident Evil Pad (aka SLPH-00060 ASCII Biohazard)\n SLEH-00012 Reality-Quest The Glove (right-handed only) (SLUH-00045/SLPH-?)\n SLEH-00013 CD Case (small nylon bag for fourteen CDs) (SLPH-?)\n SLEH-00014 ?\n SLEH-00015 PlayStation Case (bigger bag for the console) (SLPH-?)\n SLEH-00016 PlayStation Case + Digital Joypad + Memory Card\n SLEH-00017 ?\n SLEH-00018 Ascii Sphere 360 (SLUH-00028/SLPH-?)\n SLEH-00019 Interact V3 Racing Wheel (SLPH-?)\n SLEH-00020 Namco JogCon, digital pad, steering dial (SLPH-00126/SLUH-00059)\n SLEH-00021 Konami Beatmania Controller (SLPH-?)\n SLEH-00022 ?\n SLEH-00023 Official Dance Mat (RU017/SLUH-00071) (for PSone and PS2)\n SLEH-00024 Fanatec Speedster 2 (wheel with pedals) (for PSone and PS2)\n SLEH-00025 Mad Catz 8MB Memory Card (for PS2)\n SLEH-00026 Olympus Eye-Trek FMD-20P Game/DVD glasses (for PS2)\n SLEH-00027 Logitech Cordless Controller... or Eye-Trek FMD-20P, too? (PSx?)\n SLEH-00028 ?\n SLEH-00029 Fanatec Speedster 3 (for PS2)\n SLEH-00030 Logitech Eye Toy (camera?) (for PS2)\n Mad Catz Wrist Rumbler (rumble add-on for pre-dualshock controllers)\n SLUH-00001 Specialized Joystick (single-axis, digital?)\n SLUH-00002 Control Pad (redesigned joypad)\n SLUH-00003 InterAct Piranha Pad, digital pad, autofire/slowmotion\n SLUH-00017 Konami Justifier, IRQ10-based Lightgun (Hyperblaster/SLPH-00014)\n SLUH-00018 Enhanced Pad (joypad with whatever extra functions)\n SLUH-00022 Analog and Digital Steering Wheel with pedals (for testdrive 4?)\n SLUH-00026 Optec Mach 1 (gray steering/flight controller with pedals)\n SLUH-00028 Ascii Sphere 360 (SLEH-00018)\n SLUH-00029 Namco NPC-102 Joystick (single-axis, digital?)\n SLUH-00031 Interact Program Pad\n SLUH-00033 Piranha Pad (redesigned joypad)\n SLUH-00034 NUBY Manufacturing The Heater, white lightgun (irq10 or cinch?)\n SLUH-00035 Namco G-CON 45, Cinch-based Lightgun (SLEH-0007/SLPH-00034)\n SLUH-00037 Arcade Stick (single-axis, digital?)\n SLUH-00038 ASCII Grip V, single-handed digital pad (SLPH-00027/SLEH-00008)\n SLUH-00040 System Organizer (huh? looks like... a black storage box?)\n SLUH-00041 V3 Racing Wheel with pedals\n SLUH-00043 GunCon (bundled with Time Crisis 1)\n SLUH-00044 Remote Wizard (looks like wireless joypad or so)\n SLUH-00045 Reality-Quest The Glove (right-handed only) (SLEH-00012/SLPH-?)\n SLUH-00046 GunCon (bundled with Point Blank)\n SLUH-00055 Aftershock Wheel with pedals\n SLUH-00056 UltraRacer Steering Controller (grip-style)\n SLUH-00057 EA Sports Game Pad (redesigned joypad)\n SLUH-00058 something for point blank 2 (?) (maybe a lightgun)\n SLUH-00059 Namco Jogcon, digital pad, steering dial (SLEH-0020/SLPH-00126)\n SLUH-00061 MadCatz MC2 Racing Wheel (black/gray)\n SLUH-00063 Bass Landing Fishing Reel controller\n SLUH-00066 Sportster racing wheel\n SLUH-00068 Jungle Book Rhythm N Groove Dance Pack\n SLUH-00071 Konami Dance Pad (DDR Dance Pad) (RU017)\n SLUH-00072 GunCon (bundled with Point Blank 3)\n SLUH-00073 GunCon (bundled with Time Crisis 2 - Project Titan)\n SLUH-00077 Logitech Cordless Controller, analog pad (ps1/ps2)\n SLUH-00081 Logitech NetPlay Controller, pad with keyboard (usb/ps2)\n SLUH-00083 Konami Dance Dance Revolution Controller (for PS1 and PS2)\n SLUH-00084 NYKO iType2, pad with keyboard (usb/ps2)\n SLUH-00085 Logitech Cordless Action Controller (for PS2)\n SLUH-00086 Namco/Taiko Drum Master (Taiko Controller Pack) (for PS2)\n SLUH-00088 RedOctane In the Groove Dance Pad Controller ?\n SLUH-00090 Dance Pad (bundled with Pump It Up) (for PS2)\n Unknown (if any)\n SCEH-0001 SingStar (USB to Microfon) (for PS2)\nEarly SLEH/SLUH devices used 4-digit numbers (eg. the \"official\" name for SLEH-00003 is SLEH-0003; unlike as shown in the above list).
"},{"location":"hardwarenumbers/#software-cdrom-game-codes","title":"Software (CDROM Game Codes)","text":" CPCS-00701 Dino Crisis 5th Anniversary Box Serial\n DTL-NNNNN Development Tool Licensed (Net Yaroze)\n ESPM-NNNNN Sony Music Entertainment Japan (Music Video Discs)\n LSP-NNNNNN Lightspan series (non-retail educational games)\n PAPX-NNNNN Japanese Demos/Rental Editions/Taikenban\n PBPX-NNNNN Official Playstation Sampler Discs (USA/UK)\n PCPX-NNNNN Japanese Otameshi Discs (Samplers)\n PEPX-NNNNN Analog Controller Service Disc\n PUPX-NNNNN Analog controller Service Disc\n PSRM-017100 Syphon Filter 2 Disc 2 Preview Version\n PSXCDCLEAN Laser Clean\n PTPX-NNNNN Aging Disk\n SCAJ-NNNNN Sony Computer Entertainment America ... ?\n SCED-NNNNN Sony Computer Europe Demo\n SCES-NNNNN Sony Computer Europe Software\n SCPM-NNNNN Sony Computer Japan ...?\n SCPS-NNNNN Sony Computer Japan Software\n SCUS-NNNNN Sony Computer USA Software\n SCZS-NNNNN Sony Computer ... Software? (Fan Books)\n SIPS-NNNNN Sony Imports ...? (All Imports to Japan)\n SLED-NNNNN Sony Licensed Europe Demo\n SLES-NNNNN Sony Licensed Europe Software\n SLKA-NNNNN Sony Licensed Korea ...? (3 Korean Releases)\n SLPM-NNNNN Sony Licensed Japan ... ?\n SLPS-NNNNN Sony Licensed Japan Software\n SLUS-NNNNN Sony Licensed USA Software\n SPUS-NNNNN Sony Playstation US ...? (Playstation Picks Disc)\nStatus: Read I_STAT (0=No IRQ, 1=IRQ) Acknowledge: Write I_STAT (0=Clear Bit, 1=No change) Mask: Read/Write I_MASK (0=Disabled, 1=Enabled)
0 IRQ0 VBLANK (PAL=50Hz, NTSC=60Hz)\n 1 IRQ1 GPU Can be requested via GP0(1Fh) command (rarely used)\n 2 IRQ2 CDROM\n 3 IRQ3 DMA\n 4 IRQ4 TMR0 Timer 0 aka Root Counter 0 (Sysclk or Dotclk)\n 5 IRQ5 TMR1 Timer 1 aka Root Counter 1 (Sysclk or H-blank)\n 6 IRQ6 TMR2 Timer 2 aka Root Counter 2 (Sysclk or Sysclk/8)\n 7 IRQ7 Controller and Memory Card - Byte Received Interrupt\n 8 IRQ8 SIO\n 9 IRQ9 SPU\n 10 IRQ10 Controller - Lightpen Interrupt. Also shared by PIO and DTL cards.\n 11-15 Not used (always zero)\n 16-31 Garbage\nEXP2 DTL-H2000 I/O Ports
"},{"location":"interrupts/#interrupt-request-execution","title":"Interrupt Request / Execution","text":"The interrupt request bits in I_STAT are edge-triggered, ie. the get set ONLY if the corresponding interrupt source changes from \"false to true\". If one or more interrupts are requested and enabled, ie. if \"(I_STAT AND I_MASK)=nonzero\", then cop0r13.bit10 gets set, and when cop0r12.bit10 and cop0r12.bit0 are set, too, then the interrupt gets executed.
"},{"location":"interrupts/#interrupt-acknowledge","title":"Interrupt Acknowledge","text":"To acknowledge an interrupt, write a \"0\" to the corresponding bit in I_STAT. Most interrupts (except IRQ0,4,5,6) must be additionally acknowledged at the I/O port that has caused them (eg. JOY_CTRL.bit4). Observe that the I_STAT bits are edge-triggered (they get set only on High-to-Low, or False-to-True edges). The correct acknowledge order is:
First, acknowledge I_STAT (eg. I_STAT.bit7=0)\n Then, acknowledge corresponding I/O port (eg. JOY_CTRL.bit4=1)\nRelevant COP0 registers are cop0r13 (CAUSE, reason flags), and cop0r12 (SR, control flags), and cop0r14 (EPC, return address), and, cop0cmd=10h (aka RFE opcode) is used to prepare the return from interrupts. For more info, see COP0 - Exception Handling
"},{"location":"interrupts/#psx-specific-cop0-notes","title":"PSX specific COP0 Notes","text":"COP0 has six hardware interrupt bits, of which, the PSX uses only cop0r13.bit10 (the other ones, cop0r13.bit11-15 are always zero). cop0r13.bit10 is NOT a latch, ie. it gets automatically cleared as soon as \"(I_STAT AND I_MASK)=zero\", so there's no need to do an acknowledge at the cop0 side. COP0 additionally has two software interrupt bits, cop0r13.bit8-9, which do exist in the PSX, too, these bits are read/write-able latches which can be set/cleared manually to request/acknowledge exceptions by software.
"},{"location":"interrupts/#ps2-iop-interrupts","title":"PS2 IOP interrupts","text":"The PS2's IOP has the same interrupt controller as the PS1 but with more channels. For more details, see: ps2tek - IOP Interrupts
"},{"location":"iomap/","title":"I/O Map","text":""},{"location":"iomap/#expansion-region-1","title":"Expansion Region 1","text":" 1F000000h 80000h Expansion Region (default 512 Kbytes, max 8 MBytes)\n 1F000000h 100h Expansion ROM Header (IDs and Entrypoints)\n 1F800000h 400h Scratchpad (1K Fast RAM) (Data Cache mapped to fixed address)\n 1F801000h 4 Expansion 1 Base Address (usually 1F000000h)\n 1F801004h 4 Expansion 2 Base Address (usually 1F802000h)\n 1F801008h 4 Expansion 1 Delay/Size (usually 0013243Fh; 512Kbytes 8bit-bus)\n 1F80100Ch 4 Expansion 3 Delay/Size (usually 00003022h; 1 byte)\n 1F801010h 4 BIOS ROM Delay/Size (usually 0013243Fh; 512Kbytes 8bit-bus)\n 1F801014h 4 SPU_DELAY Delay/Size (usually 200931E1h)\n 1F801018h 4 CDROM_DELAY Delay/Size (usually 00020843h or 00020943h)\n 1F80101Ch 4 Expansion 2 Delay/Size (usually 00070777h; 128-bytes 8bit-bus)\n 1F801020h 4 COM_DELAY / COMMON_DELAY (00031125h or 0000132Ch or 00001325h)\n 1F801040h 1/4 JOY_DATA Joypad/Memory Card Data (R/W)\n 1F801044h 4 JOY_STAT Joypad/Memory Card Status (R)\n 1F801048h 2 JOY_MODE Joypad/Memory Card Mode (R/W)\n 1F80104Ah 2 JOY_CTRL Joypad/Memory Card Control (R/W)\n 1F80104Eh 2 JOY_BAUD Joypad/Memory Card Baudrate (R/W)\n 1F801050h 1/4 SIO_DATA Serial Port Data (R/W)\n 1F801054h 4 SIO_STAT Serial Port Status (R)\n 1F801058h 2 SIO_MODE Serial Port Mode (R/W)\n 1F80105Ah 2 SIO_CTRL Serial Port Control (R/W)\n 1F80105Ch 2 SIO_MISC Serial Port Internal Register (R/W)\n 1F80105Eh 2 SIO_BAUD Serial Port Baudrate (R/W)\n 1F801060h 4/2 RAM_SIZE (usually 00000B88h; 2MB RAM mirrored in first 8MB)\n 1F801070h 2 I_STAT - Interrupt status register\n 1F801074h 2 I_MASK - Interrupt mask register\n 1F80108xh DMA0 channel 0 - MDECin\n 1F80109xh DMA1 channel 1 - MDECout\n 1F8010Axh DMA2 channel 2 - GPU (lists + image data)\n 1F8010Bxh DMA3 channel 3 - CDROM\n 1F8010Cxh DMA4 channel 4 - SPU\n 1F8010Dxh DMA5 channel 5 - PIO (Expansion Port)\n 1F8010Exh DMA6 channel 6 - OTC (reverse clear OT) (GPU related)\n 1F8010F0h DPCR - DMA Control register\n 1F8010F4h DICR - DMA Interrupt register\n 1F8010F8h unknown\n 1F8010FCh unknown\n 1F80110xh Timer 0 Dotclock\n 1F80111xh Timer 1 Horizontal Retrace\n 1F80112xh Timer 2 1/8 system clock\n 1F801800h.x.x 1 CD Index/Status Register (Bit0-1 R/W, Bit2-7 Read Only)\n 1F801801h.R.x 1 CD Response Fifo (R) (usually with Index1)\n 1F801802h.R.x 1/2 CD Data Fifo - 8bit/16bit (R) (usually with Index0..1)\n 1F801803h.R.0 1 CD Interrupt Enable Register (R)\n 1F801803h.R.1 1 CD Interrupt Flag Register (R/W)\n 1F801803h.R.2 1 CD Interrupt Enable Register (R) (Mirror)\n 1F801803h.R.3 1 CD Interrupt Flag Register (R/W) (Mirror)\n 1F801801h.W.0 1 CD Command Register (W)\n 1F801802h.W.0 1 CD Parameter Fifo (W)\n 1F801803h.W.0 1 CD Request Register (W)\n 1F801801h.W.1 1 Unknown/unused\n 1F801802h.W.1 1 CD Interrupt Enable Register (W)\n 1F801803h.W.1 1 CD Interrupt Flag Register (R/W)\n 1F801801h.W.2 1 Unknown/unused\n 1F801802h.W.2 1 CD Audio Volume for Left-CD-Out to Left-SPU-Input (W)\n 1F801803h.W.2 1 CD Audio Volume for Left-CD-Out to Right-SPU-Input (W)\n 1F801801h.W.3 1 CD Audio Volume for Right-CD-Out to Right-SPU-Input (W)\n 1F801802h.W.3 1 CD Audio Volume for Right-CD-Out to Left-SPU-Input (W)\n 1F801803h.W.3 1 CD Audio Volume Apply Changes (by writing bit5=1)\n 1F801810h.Write 4 GP0 Send GP0 Commands/Packets (Rendering and VRAM Access)\n 1F801814h.Write 4 GP1 Send GP1 Commands (Display Control)\n 1F801810h.Read 4 GPUREAD Read responses to GP0(C0h) and GP1(10h) commands\n 1F801814h.Read 4 GPUSTAT Read GPU Status Register\n 1F801820h.Write 4 MDEC Command/Parameter Register (W)\n 1F801820h.Read 4 MDEC Data/Response Register (R)\n 1F801824h.Write 4 MDEC Control/Reset Register (W)\n 1F801824h.Read 4 MDEC Status Register (R)\n 1F801C00h+N*10h 4 Voice 0..23 Volume Left/Right\n 1F801C04h+N*10h 2 Voice 0..23 ADPCM Sample Rate\n 1F801C06h+N*10h 2 Voice 0..23 ADPCM Start Address\n 1F801C08h+N*10h 4 Voice 0..23 ADSR Attack/Decay/Sustain/Release\n 1F801C0Ch+N*10h 2 Voice 0..23 ADSR Current Volume\n 1F801C0Eh+N*10h 2 Voice 0..23 ADPCM Repeat Address\n 1F801D80h 4 Main Volume Left/Right\n 1F801D84h 4 Reverb Output Volume Left/Right\n 1F801D88h 4 Voice 0..23 Key ON (Start Attack/Decay/Sustain) (W)\n 1F801D8Ch 4 Voice 0..23 Key OFF (Start Release) (W)\n 1F801D90h 4 Voice 0..23 Channel FM (pitch lfo) mode (R/W)\n 1F801D94h 4 Voice 0..23 Channel Noise mode (R/W)\n 1F801D98h 4 Voice 0..23 Channel Reverb mode (R/W)\n 1F801D9Ch 4 Voice 0..23 Channel ON/OFF (status) (R)\n 1F801DA0h 2 Unknown? (R) or (W)\n 1F801DA2h 2 Sound RAM Reverb Work Area Start Address\n 1F801DA4h 2 Sound RAM IRQ Address\n 1F801DA6h 2 Sound RAM Data Transfer Address\n 1F801DA8h 2 Sound RAM Data Transfer Fifo\n 1F801DAAh 2 SPU Control Register (SPUCNT)\n 1F801DACh 2 Sound RAM Data Transfer Control\n 1F801DAEh 2 SPU Status Register (SPUSTAT) (R)\n 1F801DB0h 4 CD Volume Left/Right\n 1F801DB4h 4 Extern Volume Left/Right\n 1F801DB8h 4 Current Main Volume Left/Right\n 1F801DBCh 4 Unknown? (R/W)\n 1F801DC0h 2 dAPF1 Reverb APF Offset 1\n 1F801DC2h 2 dAPF2 Reverb APF Offset 2\n 1F801DC4h 2 vIIR Reverb Reflection Volume 1\n 1F801DC6h 2 vCOMB1 Reverb Comb Volume 1\n 1F801DC8h 2 vCOMB2 Reverb Comb Volume 2\n 1F801DCAh 2 vCOMB3 Reverb Comb Volume 3\n 1F801DCCh 2 vCOMB4 Reverb Comb Volume 4\n 1F801DCEh 2 vWALL Reverb Reflection Volume 2\n 1F801DD0h 2 vAPF1 Reverb APF Volume 1\n 1F801DD2h 2 vAPF2 Reverb APF Volume 2\n 1F801DD4h 4 mSAME Reverb Same Side Reflection Address 1 Left/Right\n 1F801DD8h 4 mCOMB1 Reverb Comb Address 1 Left/Right\n 1F801DDCh 4 mCOMB2 Reverb Comb Address 2 Left/Right\n 1F801DE0h 4 dSAME Reverb Same Side Reflection Address 2 Left/Right\n 1F801DE4h 4 mDIFF Reverb Different Side Reflection Address 1 Left/Right\n 1F801DE8h 4 mCOMB3 Reverb Comb Address 3 Left/Right\n 1F801DECh 4 mCOMB4 Reverb Comb Address 4 Left/Right\n 1F801DF0h 4 dDIFF Reverb Different Side Reflection Address 2 Left/Right\n 1F801DF4h 4 mAPF1 Reverb APF Address 1 Left/Right\n 1F801DF8h 4 mAPF2 Reverb APF Address 2 Left/Right\n 1F801DFCh 4 vIN Reverb Input Volume Left/Right\n 1F801E00h+N*04h 4 Voice 0..23 Current Volume Left/Right\n 1F801E60h 20h Unknown? (R/W)\n 1F801E80h 180h Unknown? (Read: FFh-filled) (Unused or Write only?)\n 1F802000h 80h Expansion Region (8bit data bus, crashes on 16bit access?)\n 1F802020h/1st DUART Mode Register 1.A (R/W)\n 1F802020h/2nd DUART Mode Register 2.A (R/W)\n 1F802021h/Read DUART Status Register A (R)\n 1F802021h/Write DUART Clock Select Register A (W)\n 1F802022h/Read DUART Toggle Baud Rate Generator Test Mode (Read=Strobe)\n 1F802022h/Write DUART Command Register A (W)\n 1F802023h/Read DUART Rx Holding Register A (FIFO) (R)\n 1F802023h/Write DUART Tx Holding Register A (W)\n 1F802024h/Read DUART Input Port Change Register (R)\n 1F802024h/Write DUART Aux. Control Register (W)\n 1F802025h/Read DUART Interrupt Status Register (R)\n 1F802025h/Write DUART Interrupt Mask Register (W)\n 1F802026h/Read DUART Counter/Timer Current Value, Upper/Bit15-8 (R)\n 1F802026h/Write DUART Counter/Timer Reload Value, Upper/Bit15-8 (W)\n 1F802027h/Read DUART Counter/Timer Current Value, Lower/Bit7-0 (R)\n 1F802027h/Write DUART Counter/Timer Reload Value, Lower/Bit7-0 (W)\n 1F802028h/1st DUART Mode Register 1.B (R/W)\n 1F802028h/2nd DUART Mode Register 2.B (R/W)\n 1F802029h/Read DUART Status Register B (R)\n 1F802029h/Write DUART Clock Select Register B (W)\n 1F80202Ah/Read DUART Toggle 1X/16X Test Mode (Read=Strobe)\n 1F80202Ah/Write DUART Command Register B (W)\n 1F80202Bh/Read DUART Rx Holding Register B (FIFO) (R)\n 1F80202Bh/Write DUART Tx Holding Register B (W)\n 1F80202Ch/None DUART Reserved Register (neither R nor W)\n 1F80202Dh/Read DUART Input Port (R)\n 1F80202Dh/Write DUART Output Port Configuration Register (W)\n 1F80202Eh/Read DUART Start Counter Command (Read=Strobe)\n 1F80202Eh/Write DUART Set Output Port Bits Command (Set means Out=LOW)\n 1F80202Fh/Read DUART Stop Counter Command (Read=Strobe)\n 1F80202Fh/Write DUART Reset Output Port Bits Command (Reset means Out=HIGH)\n 1F802000h 1 DTL-H2000: ATCONS STAT (R)\n 1F802002h 1 DTL-H2000: ATCONS DATA (R and W)\n 1F802004h 2 DTL-H2000: Whatever 16bit data ?\n 1F802030h 1/4 DTL-H2000: Secondary IRQ10 Flags\n 1F802032h 1 DTL-H2000: Whatever IRQ Control ?\n 1F802040h 1 DTL-H2000: Bootmode \"Dip switches\" (R)\n 1F802041h 1 PSX: POST (external 7 segment display, indicate BIOS boot status)\n 1F802042h 1 DTL-H2000: POST/LED (similar to POST) (other addr, 2-digit wide)\n 1F802070h 1 PS2: POST2 (similar to POST, but PS2 BIOS uses this address)\n 1F802060h Emu-Expansion ID1 \"E\" (R)\n 1F802061h Emu-Expansion ID2 \"X\" (R)\n 1F802062h Emu-Expansion ID3 \"P\" (R)\n 1F802063h Emu-Expansion Version (01h) (R)\n 1F802064h Emu-Expansion Enable1 \"O\" (R/W)\n 1F802065h Emu-Expansion Enable2 \"N\" (R/W)\n 1F802066h Emu-Expansion Halt (R)\n 1F802067h Emu-Expansion Turbo Mode Flags (R/W)\n 1F802080h 4 Redux-Expansion ID \"PCSX\" (R)\n 1F802080h 1 Redux-Expansion Console putchar (W)\n 1F802081h 1 Redux-Expansion Debug break (W)\n 1F802082h 1 Redux-Expansion Exit code (W)\n 1F802084h 4 Redux-Expansion Notification message pointer (W)\n 1FA00000h - Not used by BIOS or any PSX games\n 1FA00000h - POST3 (similar to POST, but PS2 BIOS uses this address)\n 1FC00000h 80000h BIOS ROM (512Kbytes) (Reset Entrypoint at BFC00000h)\n FFFE0130h 4 Cache Control\n COP0 System Control Coprocessor - 32 registers (not all used)\n COP1 N/A\n COP2 Geometry Transformation Engine (GTE) - 64 registers (most are used)\n COP3 N/A\nBIOS Overview BIOS Memory Map BIOS Function Summary BIOS File Functions BIOS File Execute and Flush Cache BIOS CDROM Functions BIOS Memory Card Functions BIOS Interrupt/Exception Handling BIOS Event Functions BIOS Event Summary BIOS Thread Functions BIOS Timer Functions BIOS Joypad Functions BIOS GPU Functions BIOS Memory Allocation BIOS Memory Fill/Copy/Compare (SLOW) BIOS String Functions BIOS Number/String/Character Conversion BIOS Misc Functions BIOS Internal Boot Functions BIOS More Internal Functions BIOS PC File Server BIOS TTY Console (std_io) BIOS Character Sets BIOS Control Blocks BIOS Versions BIOS Patches
"},{"location":"kernelbios/#bios-overview","title":"BIOS Overview","text":""},{"location":"kernelbios/#bios-cdrom-boot","title":"BIOS CDROM Boot","text":"The main purpose of the BIOS is to boot games from CDROM, unfortunately, before doing that, it displays the Sony intro. It's also doing some copy protection and region checks, and refuses to boot unlicensed games, or illegal copies, or games for other regions.
"},{"location":"kernelbios/#bios-bootmenu","title":"BIOS Bootmenu","text":"The bootmenu shows up when starting the Playstation without CDROM inserted. The menu allows to play Audio CDs, and to erase or copy game positions on Memory Cards.
"},{"location":"kernelbios/#bios-functions","title":"BIOS Functions","text":"The BIOS contains a number of more or less useful, and probably more or less inefficient functions that can be used by software. No idea if it's easy to take full control of the CPU, ie. to do all hardware access and interrupt handling by software, without using the BIOS at all? Eventually the BIOS functions for accessing the CDROM drive are important, not sure how complicated/compatible it'd be to access the CDROM drive directly via I/O ports... among others, there might be different drives used in different versions of the Playstation, which aren't fully compatible with each other?
"},{"location":"kernelbios/#bios-memory","title":"BIOS Memory","text":"The BIOS occupies 512Kbyte ROM with 8bit address bus (so the BIOS ROM is rather slow, for faster execution, portions of it are relocated to the first 64K of RAM). For some very strange reason, the original PSX BIOS executes all ROM functions in uncached ROM, which is incredible slow (nocash BIOS uses cached ROM, which does work without problems). The first 64Kbyte of the 2Mbyte Main RAM are reserved for the BIOS (containing exception handlers, jump tables, other data, and relocated code). That reserved region does unfortunately include the \"valuable\" first 32Kbytes (valuable because that memory could be accessed directly via [R0+immediate], without needing to use R1..R31 as base register).
"},{"location":"kernelbios/#bios-memory-map","title":"BIOS Memory Map","text":""},{"location":"kernelbios/#bios-rom-map-512kbytes","title":"BIOS ROM Map (512Kbytes)","text":" BFC00000h Kernel Part 1 (code/data executed in uncached ROM)\n BFC10000h Kernel Part 2 (code/data relocated to cached RAM)\n BFC18000h Intro/Bootmenu (code/data decompressed and relocated to RAM)\n BFC64000h Character Sets\n BFC00100h Kernel BCD date (YYYYMMDDh)\n BFC00104h Console Type (see Port 1F802030h, Secondary IRQ10 Controller)\n BFC00108h Kernel Maker/Version Strings (separated by one or more 00h bytes)\n BFC7FF32h GUI Version/Copyright Strings (if any) (separated by one 00h byte)\n 00000000h 10h Garbage Area (see notes below)\n 00000010h 30h Unused/reserved\n 00000040h 20h COP0 debug-break vector (not used by Kernel) (in KSEG0)\n 00000060h 4 RAM Size (in megabytes) (2 or 8)\n 00000064h 4 Unknown (set to 00000000h)\n 00000068h 4 Unknown (set to 000000FFh)\n 0000006Ch 14h Unused/reserved\n 00000080h 10h Exception vector (actually in KSEG0, ie. at 80000080h)\n 00000090h 10h Unused/reserved\n 000000A0h 10h A(nnh) Function Vector\n 000000B0h 10h B(nnh) Function Vector\n 000000C0h 10h C(nnh) Function Vector\n 000000D0h 30h Unused/reserved\n 00000100h 58h Table of Tables (BIOS Control Blocks) (see below)\n 00000158h 28h Unused/reserved\n 00000180h 80h Command line argument from SYSTEM.CNF; BOOT = fname argument\n 00000200h 300h A(nnh) Jump Table\n 00000500h ... Kernel Code/Data (relocated from ROM)\n 0000Cxxxh ... Unused/reserved\n 0000DF80h 80h Used for BIOS Patches (ie. used by games, not used by BIOS)\n 0000DFFCh 4 Response value from Intro/Bootmenu\n 0000E000h 2000h Kernel Memory; ExCBs, EvCBs, and TCBs allocated via B(00h)\n 00010000h ... Begin of User RAM (Exefile, Data, Heap, Stack, etc.)\n 001FFF00h ... Default Stacktop (usually in KSEG0)\n 1F800000h 400h Scratchpad (Data-Cache mis-used as Fast RAM)\nEach table entry consists of two 32bit values; containing the base address, and total size (in bytes) of the corresponding control blocks.
00000100h ExCB Exception Chain Entrypoints (addr=var, size=4*08h)\n 00000108h PCB Process Control Block (addr=var, size=1*04h)\n 00000110h TCB Thread Control Blocks (addr=var, size=N*C0h)\n 00000118h - Unused/reserved\n 00000120h EvCB Event Control Blocks (addr=var, size=N*1Ch)\n 00000128h - Unused/reserved\n 00000130h - Unused/reserved\n 00000138h - Unused/reserved\n 00000140h FCB File Control Blocks (addr=fixed, size=10h*2Ch)\n 00000148h - Unused/reserved\n 00000150h DCB Device Control Blocks (addr=fixed, size=0Ah*50h)\nThe first some bytes of memory address 00000000h aren't actually used by the Kernel, except for storing some garbage at that locations. However, this garbage is actually important for bugged games like R-Types and Fade to Black (ie. games that do read from address 00000000h due to using uninitialized pointers). Initially, the garbage area is containing a copy of the 16-byte exception handler at address 80h, but the first 4-bytes are typically smashed (set to 00000003h from some useless dummy writes in some useless CDROM delays). Ie. the 16-bytes should have these values:
[00000000h]=3C1A0000h ;<-- but overwritten by 00000003h after soon\n [00000004h]=275A0C80h ;<-- or 275A0C50h (in older BIOS)\n [00000008h]=03400008h\n [0000000Ch]=00000000h\nArgument(s) are passed in R4,R5,R6,R7,[SP+10h],[SP+14h],etc. Caution: When calling a sub-function with N parameters, the caller MUST always allocate N words on the stack, and, although the first four parameters are passed in registers rather than on stack, the sub-function is allowed to use/destroy these words at [SP+0..N*4-1]. BIOS Functions (and custom callback functions) are allowed to destroy registers R1-R15, R24-R25, R31 (RA), and HI/LO. Registers R16-R23, R29 (SP), and R30 (FP) must be left unchanged (if the function uses that registers, then it must push/pop them). R26 (K0) is reserved for exception handler and should be usually not used by other functions. R27 (K1) and R28 (GP) are left more or less unused by the BIOS, so one can more or less freely use them for whatever purpose. The return value (if any) is stored in R2 register.
"},{"location":"kernelbios/#a-functions-call-00a0h-with-function-number-in-r9-register","title":"A-Functions (Call 00A0h with function number in R9 Register)","text":" A(00h) or B(32h) open(filename,accessmode)\n A(01h) or B(33h) lseek(fd,offset,seektype)\n A(02h) or B(34h) read(fd,dst,length)\n A(03h) or B(35h) write(fd,src,length)\n A(04h) or B(36h) close(fd)\n A(05h) or B(37h) ioctl(fd,cmd,arg)\n A(06h) or B(38h) exit(exitcode)\n A(07h) or B(39h) isatty(fd)\n A(08h) or B(3Ah) getc(fd)\n A(09h) or B(3Bh) putc(char,fd)\n A(0Ah) todigit(char)\n A(0Bh) atof(src) ;Does NOT work - uses (ABSENT) cop1 !!!\n A(0Ch) strtoul(src,src_end,base)\n A(0Dh) strtol(src,src_end,base)\n A(0Eh) abs(val)\n A(0Fh) labs(val)\n A(10h) atoi(src)\n A(11h) atol(src)\n A(12h) atob(src,num_dst)\n A(13h) setjmp(buf)\n A(14h) longjmp(buf,param)\n A(15h) strcat(dst,src)\n A(16h) strncat(dst,src,maxlen)\n A(17h) strcmp(str1,str2)\n A(18h) strncmp(str1,str2,maxlen)\n A(19h) strcpy(dst,src)\n A(1Ah) strncpy(dst,src,maxlen)\n A(1Bh) strlen(src)\n A(1Ch) index(src,char)\n A(1Dh) rindex(src,char)\n A(1Eh) strchr(src,char) ;exactly the same as \"index\"\n A(1Fh) strrchr(src,char) ;exactly the same as \"rindex\"\n A(20h) strpbrk(src,list)\n A(21h) strspn(src,list)\n A(22h) strcspn(src,list)\n A(23h) strtok(src,list) ;use strtok(0,list) in further calls\n A(24h) strstr(str,substr) ;Bugged\n A(25h) toupper(char)\n A(26h) tolower(char)\n A(27h) bcopy(src,dst,len)\n A(28h) bzero(dst,len)\n A(29h) bcmp(ptr1,ptr2,len) ;Bugged\n A(2Ah) memcpy(dst,src,len)\n A(2Bh) memset(dst,fillbyte,len)\n A(2Ch) memmove(dst,src,len) ;Bugged\n A(2Dh) memcmp(src1,src2,len) ;Bugged\n A(2Eh) memchr(src,scanbyte,len)\n A(2Fh) rand()\n A(30h) srand(seed)\n A(31h) qsort(base,nel,width,callback)\n A(32h) strtod(src,src_end) ;Does NOT work - uses (ABSENT) cop1 !!!\n A(33h) malloc(size)\n A(34h) free(buf)\n A(35h) lsearch(key,base,nel,width,callback)\n A(36h) bsearch(key,base,nel,width,callback)\n A(37h) calloc(sizx,sizy) ;SLOW!\n A(38h) realloc(old_buf,new_siz) ;SLOW!\n A(39h) InitHeap(addr,size)\n A(3Ah) _exit(exitcode)\n A(3Bh) or B(3Ch) getchar()\n A(3Ch) or B(3Dh) putchar(char)\n A(3Dh) or B(3Eh) gets(dst)\n A(3Eh) or B(3Fh) puts(src)\n A(3Fh) printf(txt,param1,param2,etc.)\n A(40h) SystemErrorUnresolvedException()\n A(41h) LoadTest(filename,headerbuf)\n A(42h) Load(filename,headerbuf)\n A(43h) Exec(headerbuf,param1,param2)\n A(44h) FlushCache()\n A(45h) init_a0_b0_c0_vectors\n A(46h) GPU_dw(Xdst,Ydst,Xsiz,Ysiz,src)\n A(47h) gpu_send_dma(Xdst,Ydst,Xsiz,Ysiz,src)\n A(48h) SendGP1Command(gp1cmd)\n A(49h) GPU_cw(gp0cmd) ;send GP0 command word\n A(4Ah) GPU_cwp(src,num) ;send GP0 command word and parameter words\n A(4Bh) send_gpu_linked_list(src)\n A(4Ch) gpu_abort_dma()\n A(4Dh) GetGPUStatus()\n A(4Eh) gpu_sync()\n A(4Fh) SystemError\n A(50h) SystemError\n A(51h) LoadExec(filename,stackbase,stackoffset)\n A(52h) GetSysSp\n A(53h) SystemError ;PS2: set_ioabort_handler(src)\n A(54h) or A(71h) _96_init()\n A(55h) or A(70h) _bu_init()\n A(56h) or A(72h) _96_remove() ;does NOT work due to SysDeqIntRP bug\n A(57h) return 0\n A(58h) return 0\n A(59h) return 0\n A(5Ah) return 0\n A(5Bh) dev_tty_init() ;PS2: SystemError\n A(5Ch) dev_tty_open(fcb,and unused:\"path\\name\",accessmode) ;PS2: SystemError\n A(5Dh) dev_tty_in_out(fcb,cmd) ;PS2: SystemError\n A(5Eh) dev_tty_ioctl(fcb,cmd,arg) ;PS2: SystemError\n A(5Fh) dev_cd_open(fcb,\"path\\name\",accessmode)\n A(60h) dev_cd_read(fcb,dst,len)\n A(61h) dev_cd_close(fcb)\n A(62h) dev_cd_firstfile(fcb,\"path\\name\",direntry)\n A(63h) dev_cd_nextfile(fcb,direntry)\n A(64h) dev_cd_chdir(fcb,\"path\")\n A(65h) dev_card_open(fcb,\"path\\name\",accessmode)\n A(66h) dev_card_read(fcb,dst,len)\n A(67h) dev_card_write(fcb,src,len)\n A(68h) dev_card_close(fcb)\n A(69h) dev_card_firstfile(fcb,\"path\\name\",direntry)\n A(6Ah) dev_card_nextfile(fcb,direntry)\n A(6Bh) dev_card_erase(fcb,\"path\\name\")\n A(6Ch) dev_card_undelete(fcb,\"path\\name\")\n A(6Dh) dev_card_format(fcb)\n A(6Eh) dev_card_rename(fcb1,\"path\\name1\",fcb2,\"path\\name2\")\n A(6Fh) ? ;card ;[r4+18h]=00000000h ;card_clear_error(fcb) or so\n A(70h) or A(55h) _bu_init()\n A(71h) or A(54h) _96_init()\n A(72h) or A(56h) _96_remove() ;does NOT work due to SysDeqIntRP bug\n A(73h) return 0\n A(74h) return 0\n A(75h) return 0\n A(76h) return 0\n A(77h) return 0\n A(78h) CdAsyncSeekL(src)\n A(79h) return 0 ;DTL-H: Unknown?\n A(7Ah) return 0 ;DTL-H: Unknown?\n A(7Bh) return 0 ;DTL-H: Unknown?\n A(7Ch) CdAsyncGetStatus(dst)\n A(7Dh) return 0 ;DTL-H: Unknown?\n A(7Eh) CdAsyncReadSector(count,dst,mode)\n A(7Fh) return 0 ;DTL-H: Unknown?\n A(80h) return 0 ;DTL-H: Unknown?\n A(81h) CdAsyncSetMode(mode)\n A(82h) return 0 ;DTL-H: Unknown?\n A(83h) return 0 ;DTL-H: Unknown?\n A(84h) return 0 ;DTL-H: Unknown?\n A(85h) return 0 ;DTL-H: Unknown?, or reportedly, CdStop (?)\n A(86h) return 0 ;DTL-H: Unknown?\n A(87h) return 0 ;DTL-H: Unknown?\n A(88h) return 0 ;DTL-H: Unknown?\n A(89h) return 0 ;DTL-H: Unknown?\n A(8Ah) return 0 ;DTL-H: Unknown?\n A(8Bh) return 0 ;DTL-H: Unknown?\n A(8Ch) return 0 ;DTL-H: Unknown?\n A(8Dh) return 0 ;DTL-H: Unknown?\n A(8Eh) return 0 ;DTL-H: Unknown?\n A(8Fh) return 0 ;DTL-H: Unknown?\n A(90h) CdromIoIrqFunc1()\n A(91h) CdromDmaIrqFunc1()\n A(92h) CdromIoIrqFunc2()\n A(93h) CdromDmaIrqFunc2()\n A(94h) CdromGetInt5errCode(dst1,dst2)\n A(95h) CdInitSubFunc()\n A(96h) AddCDROMDevice()\n A(97h) AddMemCardDevice() ;DTL-H: SystemError\n A(98h) AddDuartTtyDevice() ;DTL-H: AddAdconsTtyDevice ;PS2: SystemError\n A(99h) add_nullcon_driver()\n A(9Ah) SystemError ;DTL-H: AddMessageWindowDevice\n A(9Bh) SystemError ;DTL-H: AddCdromSimDevice\n A(9Ch) SetConf(num_EvCB,num_TCB,stacktop)\n A(9Dh) GetConf(num_EvCB_dst,num_TCB_dst,stacktop_dst)\n A(9Eh) SetCdromIrqAutoAbort(type,flag)\n A(9Fh) SetMem(megabytes)\n A(A0h) _boot()\n A(A1h) SystemError(type,errorcode)\n A(A2h) EnqueueCdIntr() ;with prio=0 (fixed)\n A(A3h) DequeueCdIntr() ;does NOT work due to SysDeqIntRP bug\n A(A4h) CdGetLbn(filename) ;get 1st sector number (or garbage when not found)\n A(A5h) CdReadSector(count,sector,buffer)\n A(A6h) CdGetStatus()\n A(A7h) bufs_cb_0()\n A(A8h) bufs_cb_1()\n A(A9h) bufs_cb_2()\n A(AAh) bufs_cb_3()\n A(ABh) _card_info(port)\n A(ACh) _card_load(port)\n A(ADh) _card_auto(flag)\n A(AEh) bufs_cb_4()\n A(AFh) card_write_test(port) ;CEX-1000: jump_to_00000000h\n A(B0h) return 0 ;CEX-1000: jump_to_00000000h\n A(B1h) return 0 ;CEX-1000: jump_to_00000000h\n A(B2h) ioabort_raw(param) ;CEX-1000: jump_to_00000000h\n A(B3h) return 0 ;CEX-1000: jump_to_00000000h\n A(B4h) GetSystemInfo(index) ;CEX-1000: jump_to_00000000h\n A(B5h..BFh) N/A ;jump_to_00000000h\n B(00h) alloc_kernel_memory(size)\n B(01h) free_kernel_memory(buf)\n B(02h) init_timer(t,reload,flags)\n B(03h) get_timer(t)\n B(04h) enable_timer_irq(t)\n B(05h) disable_timer_irq(t)\n B(06h) restart_timer(t)\n B(07h) DeliverEvent(class, spec)\n B(08h) OpenEvent(class,spec,mode,func)\n B(09h) CloseEvent(event)\n B(0Ah) WaitEvent(event)\n B(0Bh) TestEvent(event)\n B(0Ch) EnableEvent(event)\n B(0Dh) DisableEvent(event)\n B(0Eh) OpenTh(reg_PC,reg_SP_FP,reg_GP)\n B(0Fh) CloseTh(handle)\n B(10h) ChangeTh(handle)\n B(11h) jump_to_00000000h\n B(12h) InitPAD2(buf1,siz1,buf2,siz2)\n B(13h) StartPAD2()\n B(14h) StopPAD2()\n B(15h) PAD_init2(type,button_dest,unused,unused)\n B(16h) PAD_dr()\n B(17h) ReturnFromException()\n B(18h) ResetEntryInt()\n B(19h) HookEntryInt(addr)\n B(1Ah) SystemError ;PS2: return 0\n B(1Bh) SystemError ;PS2: return 0\n B(1Ch) SystemError ;PS2: return 0\n B(1Dh) SystemError ;PS2: return 0\n B(1Eh) SystemError ;PS2: return 0\n B(1Fh) SystemError ;PS2: return 0\n B(20h) UnDeliverEvent(class,spec)\n B(21h) SystemError ;PS2: return 0\n B(22h) SystemError ;PS2: return 0\n B(23h) SystemError ;PS2: return 0\n B(24h) jump_to_00000000h\n B(25h) jump_to_00000000h\n B(26h) jump_to_00000000h\n B(27h) jump_to_00000000h\n B(28h) jump_to_00000000h\n B(29h) jump_to_00000000h\n B(2Ah) SystemError ;PS2: return 0\n B(2Bh) SystemError ;PS2: return 0\n B(2Ch) jump_to_00000000h\n B(2Dh) jump_to_00000000h\n B(2Eh) jump_to_00000000h\n B(2Fh) jump_to_00000000h\n B(30h) jump_to_00000000h\n B(31h) jump_to_00000000h\n B(32h) or A(00h) open(filename,accessmode)\n B(33h) or A(01h) lseek(fd,offset,seektype)\n B(34h) or A(02h) read(fd,dst,length)\n B(35h) or A(03h) write(fd,src,length)\n B(36h) or A(04h) close(fd)\n B(37h) or A(05h) ioctl(fd,cmd,arg)\n B(38h) or A(06h) exit(exitcode)\n B(39h) or A(07h) isatty(fd)\n B(3Ah) or A(08h) getc(fd)\n B(3Bh) or A(09h) putc(char,fd)\n B(3Ch) or A(3Bh) getchar()\n B(3Dh) or A(3Ch) putchar(char)\n B(3Eh) or A(3Dh) gets(dst)\n B(3Fh) or A(3Eh) puts(src)\n B(40h) cd(name)\n B(41h) format(devicename)\n B(42h) firstfile2(filename,direntry)\n B(43h) nextfile(direntry)\n B(44h) rename(old_filename,new_filename)\n B(45h) erase(filename)\n B(46h) undelete(filename)\n B(47h) AddDrv(device_info) ;subfunction for AddXxxDevice functions\n B(48h) DelDrv(device_name_lowercase)\n B(49h) PrintInstalledDevices()\n B(4Ah) InitCARD2(pad_enable) ;uses/destroys k0/k1 !!!\n B(4Bh) StartCARD2()\n B(4Ch) StopCARD2()\n B(4Dh) _card_info_subfunc(port) ;subfunction for \"_card_info\"\n B(4Eh) _card_write(port,sector,src)\n B(4Fh) _card_read(port,sector,dst)\n B(50h) _new_card()\n B(51h) Krom2RawAdd(shiftjis_code)\n B(52h) SystemError ;PS2: return 0\n B(53h) Krom2Offset(shiftjis_code)\n B(54h) _get_errno()\n B(55h) _get_error(fd)\n B(56h) GetC0Table\n B(57h) GetB0Table\n B(58h) _card_chan()\n B(59h) testdevice(devicename)\n B(5Ah) SystemError ;PS2: return 0\n B(5Bh) ChangeClearPAD(int)\n B(5Ch) _card_status(slot)\n B(5Dh) _card_wait(slot)\n B(5Eh..FFh) N/A ;jump_to_00000000h ;CEX-1000: B(5Eh..F6h) only\n B(100h....) N/A ;garbage ;CEX-1000: B(F7h.....) and up\n C(00h) EnqueueTimerAndVblankIrqs(priority) ;used with prio=1\n C(01h) EnqueueSyscallHandler(priority) ;used with prio=0\n C(02h) SysEnqIntRP(priority,struc) ;bugged, use with care\n C(03h) SysDeqIntRP(priority,struc) ;bugged, use with care\n C(04h) get_free_EvCB_slot()\n C(05h) get_free_TCB_slot()\n C(06h) ExceptionHandler()\n C(07h) InstallExceptionHandlers() ;destroys/uses k0/k1\n C(08h) SysInitMemory(addr,size)\n C(09h) SysInitKernelVariables()\n C(0Ah) ChangeClearRCnt(t,flag)\n C(0Bh) SystemError ;PS2: return 0\n C(0Ch) InitDefInt(priority) ;used with prio=3\n C(0Dh) SetIrqAutoAck(irq,flag)\n C(0Eh) return 0 ;DTL-H2000: dev_sio_init\n C(0Fh) return 0 ;DTL-H2000: dev_sio_open\n C(10h) return 0 ;DTL-H2000: dev_sio_in_out\n C(11h) return 0 ;DTL-H2000: dev_sio_ioctl\n C(12h) InstallDevices(ttyflag)\n C(13h) FlushStdInOutPut()\n C(14h) return 0 ;DTL-H2000: SystemError\n C(15h) _cdevinput(circ,char)\n C(16h) _cdevscan()\n C(17h) _circgetc(circ) ;uses r5 as garbage txt for _ioabort\n C(18h) _circputc(char,circ)\n C(19h) _ioabort(txt1,txt2)\n C(1Ah) set_card_find_mode(mode) ;0=normal, 1=find deleted files\n C(1Bh) KernelRedirect(ttyflag) ;PS2: ttyflag=1 causes SystemError\n C(1Ch) AdjustA0Table()\n C(1Dh) get_card_find_mode()\n C(1Eh..7Fh) N/A ;jump_to_00000000h\n C(80h.....) N/A ;mirrors to B(00h.....)\n SYS(00h) NoFunction()\n SYS(01h) EnterCriticalSection()\n SYS(02h) ExitCriticalSection()\n SYS(03h) ChangeThreadSubFunction(addr) ;syscall with r4=03h, r5=addr\n SYS(04h..FFFFFFFFh) calls DeliverEvent(F0000010h,4000h)\nBRK opcodes may be used within devkits, however, the standard BIOS simply calls DeliverEvent(F0000010h,1000h) and SystemError_A_40h upon any BRK opcodes (as well as on any other unresolved exceptions).
BRK(1C00h) Division by zero (commonly checked/invoked by software)\n BRK(1800h) Division overflow (-80000000h/-1, sometimes checked by software)\n BRK(1h) Whatever lockup or so?\n BRK(101h) PCInit() Inits the fileserver.\n BRK(102h) PCCreat(filename, fileattributes)\n BRK(103h) PCOpen(filename, accessmode)\n BRK(104h) PCClose(filehandle)\n BRK(105h) PCRead(filehandle, length, memory_destination_address)\n BRK(106h) PCWrite(filehandle, length, memory_source_address)\n BRK(107h) PClSeek(filehandle, file_offset, seekmode)\n BRK(3C400h) User has typed \"break\" command in debug console\n out: V0 File handle (00h..0Fh), or -1 if error.\n bit0 1=Read ;\\These bits aren't actually used by the BIOS, however, at\n bit1 1=Write ;/least 1 should be set; won't work when all 32bits are zero\n bit2 1=Exit without waiting for incoming data (when TTY buffer empty)\n bit9 0=Open Existing File, 1=Create New file (memory card only)\n bit15 1=Asynchronous mode (memory card only; don't wait for completion)\n bit16-31 Number of memory card blocks for a new file on the memory card\n seektype 0 = from start of file (with positive offset)\n 1 = from current file pointer (with positive/negative offset)\n 2 = Bugs. Should be from end of file.\n out: V0 Number of bytes actually read, -1 if failed.\n out: V0 Number of bytes written.\nReturns r2=fd (or r2=-1 if failed).
"},{"location":"kernelbios/#a08h-or-b3ah-getcfd-read-one-byte-from-file","title":"A(08h) or B(3Ah) - getc(fd) - read one byte from file","text":" out: R2=character (sign-expanded) or FFFFFFFFh=error\nObserve that \"fd\" is the 2nd paramter (not the 1st paramter as usually).
out: R2=Number of bytes actually written, -1 if failed\nChanges the current directory on the specified device, which should be \"cdrom:\" (memory cards don't support directories). The PSX supports only a current directory, but NOT a current device (ie. after cd, the directory name may be ommited from filenames, but the device name must be still included in all filenames).
in: A0 Pointer to new directory path (eg. \"cdrom:\\path\")\nReturns r2=direntry (or r2=0 if no matching files). Searches for the first file to match the specified filename; the filename may contain \"?\" and \"*\" wildcards. \"*\" means to ignore ALL following characters; accordingly one cannot specify any further characters after the \"*\" (eg. \"DATA*\" would work, but \"*.DAT\" won't work). \"?\" is meant to ignore a single character cell. Note: The \"?\" wildcards (but not \"*\") can be used also in all other file functions; causing the function to use the first matching name (eg. erase \"????\" would erase the first matching file, not all matching files). Start the name with the device you want to address. (ie. pcdrv:) Different drives can be accessed as normally by their drive names (a:, c:, huh?) if path is omitted after the device, the current directory will be used. A direntry structure looks like this:
00h 14h Filename, terminated with 00h\n 14h 4 File attribute (always 0 for cdrom) (50h=norm or A0h=del for card)\n 18h 4 File size\n 1Ch 4 Pointer to next direntry? (not used?)\n 20h 4 First Sector Number\n 24h 4 Reserved (not used)\nReturns r2=direntry (or r2=0 if no more matching files). Uses the settings of a previous firstfile2/nextfile command.
"},{"location":"kernelbios/#b44h-renameold_filename-new_filename","title":"B(44h) - rename(old_filename, new_filename)","text":"Returns 1=okay, or 0=failed.
"},{"location":"kernelbios/#b45h-erasefilename-delete-a-file-on-target-device","title":"B(45h) - erase(filename) - Delete a file on target device","text":"Returns 1=okay, or 0=failed.
"},{"location":"kernelbios/#b46h-undeletefilename","title":"B(46h) - undelete(filename)","text":"Returns 1=okay, or 0=failed.
"},{"location":"kernelbios/#b41h-formatdevicename","title":"B(41h) - format(devicename)","text":"Erases all files on the device (ie. for formatting memory cards). Returns 1=okay, or 0=failed.
"},{"location":"kernelbios/#b54h-_get_errno","title":"B(54h) - _get_errno()","text":"Indicates the reason of the most recent file function error (open, lseek, read, write, close, _get_error, ioctl, cd, testdevice, erase, undelete, format, rename). Use _get_errno() ONLY if an error has occured (the error code isn't reset to zero by functions that are passing okay). firstfile2/nextfile do NOT affect _get_errno(). See below list of File Error Numbers for more info.
"},{"location":"kernelbios/#b55h-_get_errorfd","title":"B(55h) - _get_error(fd)","text":"Basically same as B(54h), but allowing to specify a file handle for which error information is to be received; accordingly it doesn't work for functions that do use 'hidden' internal file handles (eg. erase, or unsuccessful open). Returns FCB[18h], or FFFFFFFFh if the handle is invalid/unused.
"},{"location":"kernelbios/#a05h-or-b37h-ioctlfdcmdarg","title":"A(05h) or B(37h) - ioctl(fd,cmd,arg)","text":"Used only for TTY.
"},{"location":"kernelbios/#a07h-or-b39h-isattyfd","title":"A(07h) or B(39h) - isatty(fd)","text":"Returns bit1 of the file's DCB flags. That bit is set only for Duart/TTY, and is cleared for Dummy/TTY, Memory Card, and CDROM.
"},{"location":"kernelbios/#b59h-testdevicedevicename","title":"B(59h) - testdevice(devicename)","text":"Whatever. Checks the devicename, and if it's accepted, calls a device specific function. For the existing devices (cdrom,bu,tty) that specific function simply returns without doing anything. Maybe other devices (like printers or modems) would do something more interesting.
"},{"location":"kernelbios/#file-error-numbers-for-b54h-and-b55h","title":"File Error Numbers for B(54h) and B(55h)","text":" 00h okay (though many successful functions leave old error code unchanged)\n 02h file not found\n 06h bad device port number (tty2 and up)\n 09h invalid or unused file handle\n 10h general error (physical I/O error, unformatted, disk changed for old fcb)\n 11h file already exists error (create/undelete/rename)\n 12h tried to rename a file from one device to another device\n 13h unknown device name\n 16h sector alignment error, or fpos>=filesize, unknown seektype or ioctl cmd\n 18h not enough free file handles\n 1Ch not enough free memory card blocks\n FFFFFFFFh invalid or unused file handle passed to B(55h) function\nLoads the 800h-byte exe file header to an internal sector buffer, and does then copy bytes [10h..4Bh] of that header to headerbuf[00h..3Bh].
"},{"location":"kernelbios/#a42h-loadfilename-headerbuf","title":"A(42h) - Load(filename, headerbuf)","text":"Same as LoadTest (see there for details), but additionally loads the body of the executable (using the size and destination address in the file header), and does call FlushCache. The exe can be then started via Exec (this isn't done automatically by LoadTest). Unlike \"LoadExec\", the \"LoadTest/Exec\" combination allows to return the new exe file to return to the old exe file (instead of restarting the boot executable). BUG: Uses the unstable FlushCache function (see there for details).
"},{"location":"kernelbios/#a43h-execheaderbuf-param1-param2","title":"A(43h) - Exec(headerbuf, param1, param2)","text":"Can be used to start a previously loaded executable. The function saves R16,R28,R30,SP,RA in the reserved region of headerbuf (rather than on stack), more or less slowly zerofills the memfill region specified in headerbuf, reads the stack base and offset values and sets SP and FP to base+offset (or leaves them unchanged if base=0), reads the GP value from headerbuf and sets GP to that value. Then calls the excecutables entrypoint, with param1 and param2 passed in r4,r5. If the executable (should) return, then R16,R28,R30,SP,RA are restored from headerbuf, and the function returns with r2=1.
"},{"location":"kernelbios/#a51h-loadexecfilename-stackbase-stackoffset","title":"A(51h) - LoadExec(filename, stackbase, stackoffset)","text":"This is a rather bizarre function. In short, it does load and execute the specified file, and thereafter, it (tries to) reload and restart to boot executable. Part1: Takes a copy of the filename, with some adjustments: Everything up to the first \":\" or 00h byte is copied as is (ie. the device name, if it does exist, or otherwise the whole path\\filename.ext;ver), the remaining characters are copied and converted to uppercase (ie. the path\\filename.ext;ver part, or none if the device name didn't exist), finally, checks if a \";\" exists (ie. the version suffix), if there's none, then it appends \";1\" as default version. CAUTION: The BIOS allocates ONLY 28 bytes on stack for the copy of the filename, that region is followed by 4 unused bytes, so the maximum length would be 32 bytes (31 characters plus EOL) (eg. \"device:\\pathname\\filename.ext;1\",00h). Part2: Enables IRQs via ExitCriticalSection, memorizes the stack base/offset values from the previously loaded executable (which should have been the boot executable, unless LoadExec should have been used in nested fashion), does then use LoadTest to load the desired file, replaces the stack base/offset values in its headerbuf by the LoadExec parameter values, and does then execute it via Exec(headerbuf,1,0). Part3: If the exefile returns, or if it couldn't be loaded, then the boot file is (unsuccessfully) attempted to be reloaded: Enables IRQs via ExitCriticalSection, loads the boot file via LoadTest, replaces the stack base/offset values in its headerbuf by the values memorized in Part2 (which \\<should> be the boot executable's values from SYSTEM.CNF, unless the nesting stuff occurred), and does then execute the boot file via Exec(headerbuf,1,0). Part4: If the boot file returns, or if it couldn't be loaded, then the function looks up in a \"JMP $\" endless loop (normally, returning from the boot exe causes SystemError(\"B\",38Ch), however, after using LoadExec, this functionality is replaced by the \"JMP $\" lockup. BUG: Uses the unstable FlushCache function (see there for details). BUG: Part3 accidently treats the first 4 characters of the exename as memory address (causing an invalid memory address exception on address 6F726463h, for \"cdrom:filename.exe\").
"},{"location":"kernelbios/#a9ch-setconfnum_evcb-num_tcb-stacktop","title":"A(9Ch) - SetConf(num_EvCB, num_TCB, stacktop)","text":"Changes the number of EvCBs and TCBs, and the stacktop. These values are usually initialized from the settings in the SYSTEM.CNF file, so using this function usually shouldn't ever be required. The function deallocates all old ExCBs, EvCBs, TCBs (so all Exception handlers, Events, and Threads (except the current one) are lost, and all other memory that may have been allocated via alloc_kernel_memory(size) is deallocated, too. It does then allocate the new control blocks, and enqueue the default handlers. Despite of the changed stacktop, the current stack pointer is kept intact, and the function returns to the caller.
"},{"location":"kernelbios/#a9dh-getconfnum_evcb_dst-num_tcb_dst-stacktop_dst","title":"A(9Dh) - GetConf(num_EvCB_dst, num_TCB_dst, stacktop_dst)","text":"Returns the number of EvCBs, TCBs, and the initial stacktop. There's no return value in the R2 register, instead, the three 32bit return values are stored at the specified \"dst\" addresses.
"},{"location":"kernelbios/#a44h-flushcache","title":"A(44h) - FlushCache()","text":"Flushes the Code Cache, so opcodes are ensured to be loaded from RAM. This is required when loading program code via DMA (ie. from CDROM) (the cache controller apparently doesn't realize changes to RAM that are caused by DMA). The LoadTest and LoadExec functions are automatically calling FlushCache (so FlushCache is required only when loading program code via \"read\" or via \"CdReadSector\"). FlushCache may be also required when relocating or modifying program code by software (the cache controller doesn't seem to realize modifications to memory mirrors, eg. patching the exception handler at 80000080h seems to be work without FlushCache, but patching the same bytes at 00000080h doesn't). Note: The PSX doesn't have a Data Cache (or actually, it has, but it's misused as Fast RAM, mapped to a fixed memory region, and which isn't accessable by DMA), so FlushCache isn't required for regions that contain data. BUG: The FlushCache function contains a handful of opcodes that do use the k0 register without having IRQs disabled at that time, if an IRQ occurs during those opcodes, then the k0 value gets destroyed by the exception handler, causing FlushCache to get trapped in an endless loop. One workaround would be to disable all IRQs before calling FlushCache, however, the BIOS does internally call the function without IRQs disabled, that applies to:
load_file A(42h)\n load_exec A(51h)\n add_device B(47h) (and all \"add_xxx_device\" functions)\n init_card B(4Ah)\n and by intro/boot code\nLoadTest and LoadExec are simply loading the file to the address specified in the exe file header. There's absolutely no verification whether that memory is (or isn't) allocated via malloc, or if it is used by the boot executable, or by the kernel, or if it does contain RAM at all. When using the \"malloc\" function combined with loading exe files, it may be recommended not to pass all memory to InitHeap (ie. to keep a memory region being reserved for loading executables).
"},{"location":"kernelbios/#note","title":"Note","text":"For more info about EXE files and their headers, see CDROM File Formats
"},{"location":"kernelbios/#bios-cdrom-functions","title":"BIOS CDROM Functions","text":""},{"location":"kernelbios/#general-file-functions","title":"General File Functions","text":"CDROMs are basically accessed via normal file functions, with device name \"cdrom:\" (which is an abbreviation for \"cdrom0:\", anyways, the port number is ignored). BIOS File Functions BIOS File Execute and Flush Cache Before starting the boot executable, the BIOS automatically calls _96_init(), so the game doesn't need to do any initializations before using CDROM file functions.
"},{"location":"kernelbios/#absent-cd-audio-support","title":"Absent CD-Audio Support","text":"The Kernel doesn't include any functions for playing Audio tracks. Also, there's no BIOS function for setting the XA-ADPCM file/channel filter values. So CD Audio can be used only by directly programming the CDROM I/O ports.
"},{"location":"kernelbios/#asynchronous-cdrom-access","title":"Asynchronous CDROM Access","text":"The normal File functions are always using synchroneous access for CDROM (ie. the functions do wait until all data is transferred) (unlike as for memory cards, accessmode.bit15 cannot be used to activate asynchronous cdrom access). However, one can read files in asynchrouneous fashion via CdGetLbn, CdAsyncSeekL, and CdAsyncReadSector. CDROM files are non-fragmented, so they can be read simply from incrementing sector numbers.
"},{"location":"kernelbios/#aa4h-cdgetlbnfilename","title":"A(A4h) - CdGetLbn(filename)","text":"Returns the first sector number used by the file, or -1 in case of error. BUG: The function accidently returns -1 for the first file in the directory (the first file should be a dummy entry for the current or parent directory or so, so that bug isn't much of a problem), if the file is not found, then the function accidently returns garbage (rather than -1).
"},{"location":"kernelbios/#aa5h-cdreadsectorcountsectorbuffer","title":"A(A5h) - CdReadSector(count,sector,buffer)","text":"Reads \\<count> sectors, starting at \\<sector>, and writes data to \\<buffer>. The read is done in mode=80h (double speed, 800h-bytes per sector). The function waits until all sectors are transferred, and does then return the number of sectors (ie. count), or -1 in case of error.
"},{"location":"kernelbios/#aa6h-cdgetstatus","title":"A(A6h) - CdGetStatus()","text":"Retrieves the cdrom status via CdAsyncGetStatus(dst) (see there for details; especially for cautions on door-open flag). The function waits until the event indicates completion, and does then return the status byte (or -1 in case of error).
"},{"location":"kernelbios/#a78h-cdasyncseeklsrc","title":"A(78h) - CdAsyncSeekL(src)","text":"Issues Setloc and SeekL commands. The parameter (src) is a pointer to a 3-byte sector number (MM,SS,FF) (in BCD format). The function returns 0=failed, or 1=okay. Completion is indicated by events (class=F0000003h, and spec=20h, or 8000h).
"},{"location":"kernelbios/#a7ch-cdasyncgetstatusdst","title":"A(7Ch) - CdAsyncGetStatus(dst)","text":"Issues a GetStat command. The parameter (dst) is a pointer to a 1-byte location that receives the status response byte. The function returns 0=failed, or 1=okay. Completion is indicated by events (class=F0000003h, and spec=20h, or 8000h). Caution: The command acknowledges the door-open flag, but doesn't automatically reload the path table (which is required if a new disk is inserted); if the door-open flag was set, one should call a function that does forcefully load the path table (like cd).
"},{"location":"kernelbios/#a7eh-cdasyncreadsectorcountdstmode","title":"A(7Eh) - CdAsyncReadSector(count,dst,mode)","text":"Issues SetMode and ReadN (when mode.bit8=0), or ReadS (when mode.bit8=1) commands. count is the number of sectors to be read, dst is the destination address in RAM, mode.bit0-7 are passed as parameter to the SetMode command, mode.bit8 is the ReadN/ReadS flag (as described above). The sector size (for DMA) depends on the mode value: 918h-bytes (bit4=1, bit5=X), 924h-bytes (bit4=0, bit5=1), or 800h-bytes (bit4,5=0). Before CdAsyncReadSector, the sector number should be set via CdAsyncSeekL(src). The function returns 0=failed, or 1=okay. Completion is indicated by events (class=F0000003h, and spec=20h, 80h, or 8000h).
"},{"location":"kernelbios/#a81h-cdasyncsetmodemode","title":"A(81h) - CdAsyncSetMode(mode)","text":"Similar to CdAsyncReadSector (see there for details), but issues only the SetMode command, without any following ReadN/ReadS command.
"},{"location":"kernelbios/#a94h-cdromgetint5errcodedst1dst2","title":"A(94h) - CdromGetInt5errCode(dst1,dst2)","text":"Returns the first two response bytes from the most recent INT5 error: [dst1]=status, [dst2]=errorcode. The BIOS doesn't reset these values in case of successful completion, so the values are quite useless.
"},{"location":"kernelbios/#a54h-or-a71h-_96_init","title":"A(54h) or A(71h) - _96_init()","text":""},{"location":"kernelbios/#a56h-or-a72h-_96_remove-does-not-work-due-to-sysdeqintrp-bug","title":"A(56h) or A(72h) - _96_remove() ;does NOT work due to SysDeqIntRP bug","text":""},{"location":"kernelbios/#a90h-cdromioirqfunc1","title":"A(90h) - CdromIoIrqFunc1()","text":""},{"location":"kernelbios/#a91h-cdromdmairqfunc1","title":"A(91h) - CdromDmaIrqFunc1()","text":""},{"location":"kernelbios/#a92h-cdromioirqfunc2","title":"A(92h) - CdromIoIrqFunc2()","text":""},{"location":"kernelbios/#a93h-cdromdmairqfunc2","title":"A(93h) - CdromDmaIrqFunc2()","text":""},{"location":"kernelbios/#a95h-cdinitsubfunc-subfunction-for-_96_init","title":"A(95h) - CdInitSubFunc() ;subfunction for _96_init()","text":""},{"location":"kernelbios/#a9eh-setcdromirqautoaborttypeflag","title":"A(9Eh) - SetCdromIrqAutoAbort(type,flag)","text":""},{"location":"kernelbios/#aa2h-enqueuecdintr-with-prio0-fixed","title":"A(A2h) - EnqueueCdIntr() ;with prio=0 (fixed)","text":""},{"location":"kernelbios/#aa3h-dequeuecdintr-does-not-work-due-to-sysdeqintrp-bug","title":"A(A3h) - DequeueCdIntr() ;does NOT work due to SysDeqIntRP bug","text":"Internally used CDROM functions for initialization and IRQ handling.
"},{"location":"kernelbios/#bios-memory-card-functions","title":"BIOS Memory Card Functions","text":""},{"location":"kernelbios/#general-file-functions_1","title":"General File Functions","text":"Memory Cards aka Backup Units (bu) are basically accessed via normal file functions, with device names \"bu00:\" (Slot 1) and \"bu10:\" (Slot 2), BIOS File Functions Before using the file functions for memory cards, first call InitCARD2(pad_enable), then StartCARD2(), and then _bu_init().
"},{"location":"kernelbios/#file-header-filesize-and-sector-alignment","title":"File Header, Filesize, and Sector Alignment","text":"The first 100h..200h bytes (2..4 sectors) of the file must contain the title and icon bitmap(s). For details, see: Memory Card Data Format The filesize must be a multiple of 2000h bytes (one block), the maximum size would be 1E000h bytes (when using all 15 blocks on the memory card). The filesize must be specified when creating the file (ie. accessmode bit9=1, and bit16-31=number of blocks). Once when the file is created, the BIOS does NOT allow to change the filesize (unless by deleting and re-creating the file). When reading/writing files, the amount of data must be a multiple of 80h bytes (one sector), and the file position must be aligned to a 80h-byte boundary, too. There's no restriction on fragmented files (ie. one may cross 2000h-byte block boundaries within the file).
"},{"location":"kernelbios/#poor-memcard-performance","title":"Poor Memcard Performance","text":"PSX memory card accesses are typically super-slow. That, not so much because the hardware would be slow, but rather because of improper inefficent code at the BIOS side. The original BIOS tries to synchronize memory card accesses with joypad accesses simply by accessing only one sector per frame (although it could access circa two sectors). To the worst, the BIOS accesses Slot 1 only on each second frame, and Slot 2 only each other frame (although in 99% of all cases only one slot is accessed at once, so the access time drops to 0.5 sectors per frame). Moreover, the memory card id, directory, and broken sector list do occupy 26 sectors (although the whole information would fit into 4 or 5 sectors) (a workaround would be to read only the first some bytes, and to skip the additional unused bytes - though that'd also mean to skip the checksums which are unfortunately stored at the end of the sector). And, anytime when opening a file (in synchronous mode), the BIOS does additionally read sector 0 (which is totally useless, and gets especially slow when opening a bunch of files; eg. when extracting the title/icon from all available files on the card).
"},{"location":"kernelbios/#asynchronous-access","title":"Asynchronous Access","text":"The BIOS supports synchronous and asynchronous memory card access. Synchronous means that the BIOS function doesn't return until the access has completed (which means, due to the poor performance, that the function spends about 75% of the time on inactivity) (except in nocash PSX bios, which has better performance), whilst asynchronous access means that the BIOS function returns immediately after invoking the access (which does then continue on interrupt level, and does return an event when finished). The file \"read\" and \"write\" functions act asynchronous when accessmode bit15 is set when opening the file. Additionally, the A(ACh) _card_load(port) function can be used to tell the BIOS to load the directory entries and broken sector list to its internal RAM buffers (eg. during the games title screen, so the BIOS doesn't need to load that data once when the game enters its memory card menu). All other functions like erase or format always act synchronous. The open/findfirst/findnext functions do normally complete immediately without accessing the card at all (unless the directory wasn't yet read; in that case the directory is loading in synchronous fashion). Unfortunately, the asynchronous response doesn't rely on a single callback event, but rather on a bunch of different events which must be all allocated and tested by the game (and of which, one event is delivered on completion) (which one depends on whether function completed okay, or if an error occurred).
"},{"location":"kernelbios/#multitap-support-and-multitap-problems","title":"Multitap Support (and Multitap Problems)","text":"The BIOS does have some partial support for accessing more than two memory cards (via Multitap adaptors). Device/port names \"bu01:\", \"bu02:\", \"bu03:\" allow to access extra memory carts in slot1 (and \"bu11:\", \"bu12:\", \"bu13:\" in slot2). Namely, those names will send values 82h, 83h, 84h to the memory card slot (instead of the normal 81h value). However, the BIOS directory_buffer and broken_sector_list do support only two memory cards (one in slot1 and one in slot2). So, trying to access more memory cards may cause great data corruption (though there might be a way to get the BIOS to reload those buffers before accessing a different memory card). Aside from that problem, the BIOS functions are very-very-very slow even when accessing only two memory cards. Trying to use the BIOS to access up to eight memory cards would be very-extremly-very slow, which would be more annoying than useful.
"},{"location":"kernelbios/#b4ah-initcard2pad_enable-usesdestroys-k0k1","title":"B(4Ah) - InitCARD2(pad_enable) ;uses/destroys k0/k1 !!!","text":""},{"location":"kernelbios/#b4bh-startcard2","title":"B(4Bh) - StartCARD2()","text":""},{"location":"kernelbios/#b4ch-stopcard2","title":"B(4Ch) - StopCARD2()","text":""},{"location":"kernelbios/#a55h-or-a70h-_bu_init","title":"A(55h) or A(70h) - _bu_init()","text":" --- Below are some lower level memory card functions ---\nCan be used to check if the most recent call to _card_write has completed okay. Issues an incomplete dummy read command (similar to B(4Fh) - _card_read). The read command is aborted once when receiving the status byte from the memory card (the actual data transfer is skipped).
"},{"location":"kernelbios/#aafh-card_write_testport-not-supported-by-old-cex-1000-version","title":"A(AFh) - card_write_test(port) ;not supported by old CEX-1000 version","text":"Resets the card changed flag. For some strange reason, this flag isn't automatically reset after reading the flag, instead, the flag is reset upon sector writes. To do that, this function issues a dummy write to sector 3Fh.
"},{"location":"kernelbios/#b50h-_new_card","title":"B(50h) - _new_card()","text":"Normally any memory card read/write functions fail if the BIOS senses the card change flag to be set. Calling this function tells the BIOS to ignore the card change flag on the next read/write operation (the function is internally used when loading the \"MC\" ID from sector 0, and when calling the card_write_test function to acknowledge the card change flag).
"},{"location":"kernelbios/#b4eh-_card_writeportsectorsrc","title":"B(4Eh) - _card_write(port,sector,src)","text":""},{"location":"kernelbios/#b4fh-_card_readportsectordst","title":"B(4Fh) - _card_read(port,sector,dst)","text":"Invokes asynchronous reading/writing of a single sector. The function returns 1=okay, or 0=failed (on invalid sector numbers). The actual I/O is done on IRQ level, completion of the I/O command transmission can be checked, among others, via get/wait_card_status(slot) functions (with slot=port/10h). In case of the write function, completion of the \\<transmission> does NOT mean that the actual \\<writing> has completed, instead, write errors are indicated upon completion of the \\<next sector> read/write transmission (or, if there are no further sectors to be accessed; one can use _card_info to verify completion of the last written sector). The sector number should be in range of 0..3FFh, for some strange reason, probably a BUG, the function also accepts sector 400h. The specified sector number is directly accessed (it is NOT parsed through the broken sector replacement list).
"},{"location":"kernelbios/#b5ch-_card_statusslot","title":"B(5Ch) - _card_status(slot)","text":""},{"location":"kernelbios/#b5dh-_card_waitslot","title":"B(5Dh) - _card_wait(slot)","text":"Returns the status of the most recent I/O command, possible values are:
01h=ready\n 02h=busy/read\n 04h=busy/write\n 08h=busy/info\n 11h=failed/timeout (eg. when no cartridge inserted)\n 21h=failed/general error\nThese five callback functions are internally used by the BIOS, notifying other BIOS functions about (un-)successful completion of memory card I/O commands.
"},{"location":"kernelbios/#b58h-_card_chan","title":"B(58h) - _card_chan()","text":"This is a subfunction for the five bufs_cb__xxx functions (indicating whether the callback occured for a slot1 or slot2 access).
"},{"location":"kernelbios/#aach-_card_loadport","title":"A(ACh) - _card_load(port)","text":"Invokes asynchronous reading of the memory card directory. The function isn't too useful because the BIOS tends to read the directory automatically in various places in synchronous mode, so there isn't too much chance to replace the automatic synchronous reading by asynchronous reading.
"},{"location":"kernelbios/#aadh-_card_autoflag","title":"A(ADh) - _card_auto(flag)","text":"Can be used to enable/disable auto format (0=off, 1=on). The _bu_init function initializes auto format as disabled. If auto format is enabled, then the BIOS does automatically format memory cards if it has failed to read the \"MC\" ID bytes on sector 0. Although potentially useful, activating this feature is rather destructive (for example, read errors on sector 0 might occur accidently due to improperly inserted cards with dirty contacts, so it'd be better to prompt the user whether or not to format the card, rather than doing that automatically).
"},{"location":"kernelbios/#c1ah-set_card_find_modemode","title":"C(1Ah) - set_card_find_mode(mode)","text":""},{"location":"kernelbios/#c1dh-get_card_find_mode","title":"C(1Dh) - get_card_find_mode()","text":"Allows to get/set the card find mode (0=normal, 1=find deleted files), the mode setting affects only the firstfile2/nextfile functions. All other file functions are used fixed mode settings (always mode=0 for open, rename, erase, and mode=1 for undelete).
"},{"location":"kernelbios/#bios-interruptexception-handling","title":"BIOS Interrupt/Exception Handling","text":"The Playstation's Kernel uses an uncredible inefficient and unstable exception handler; which may have been believed to be very powerful and flexible.
"},{"location":"kernelbios/#inefficiency","title":"Inefficiency","text":"For a maximum of slowness, it does always save and restore all CPU registers (including such that aren't used in the exception handler). It does then go through a list of installed interrupt handlers - and executes ALL of them. For example, a Timer0 IRQ is first passed to the Cdrom and Vblank handlers (which must reject it, no thanks), before it does eventually reach the Timer0 handler.
"},{"location":"kernelbios/#unstable-irq-handling","title":"Unstable IRQ Handling","text":"A fundamental mistake in the exception handler is that it doesn't memorize the incoming IRQ flags. So the various interrupt handlers must check Port 1F801070h one after each other. That means, if a high priority handler has rejected IRQ processing (because the desired IRQ flag wasn't set at that time), then a lower priority handler may process it (assuming that the IRQ flag got set in the meantime), and, in worst case it may even acknowledge it (so the high priority handler does never receive it). To avoid such problems, there should be only ONE handler installed for each IRQ source. However, that isn't always possible because the Kernel automatically installs some predefined handlers. Most noteworthy, the totally bugged DefaultInterruptHandlers is always installed (and cannot be removed), so it does randomly trigger Events. Fortunately, it does not acknowledge the IRQs (unless SetIrqAutoAck was used to enable that fatal behaviour).
"},{"location":"kernelbios/#b18h-resetentryint","title":"B(18h) - ResetEntryInt()","text":"Applies the default \"Exit\" structure (which consists of a pointer to ReturnFromException, and the Kernel's exception stacktop (minus 4, for whatever reason), and zeroes for the R16..R23,R28,R30 registers. Returns the address of that structure. See HookEntryInt for details.
"},{"location":"kernelbios/#b19h-hookentryintaddr","title":"B(19h) - HookEntryInt(addr)","text":"addr points to a structure (with same format as for the setjmp function):
00h 4 r31/ra,pc ;usually ptr to ReturnFromException function\n 04h 4 r28/sp ;usually exception stacktop, minus 4, for whatever reason\n 08h 4 r30/fp ;usually 0\n 0Ch 4x8 r16..r23 ;usually 0\n 2Ch 4 r28/gp ;usually 0\nThe Kernel's exception handler has four priority chains, each may contain one or more Interrupt or Exception handlers. The default handlers are:
Prio Chain Content\n 0 CdromDmaIrq, CdromIoIrq, SyscallException\n 1 CardSpecificIrq, VblankIrq, Timer2Irq, Timer1Irq, Timer0Irq\n 2 PadCardIrq\n 3 DefInt\nInserts a new element in the specified priority chain. The new element is inserted at the begin of the chain, so (within that priority chain) the new element has highest priority.
00h 4 pointer to next element (0=none) ;this pointer is inserted by BIOS\n 04h 4 pointer to SECOND function (0=none) ;executed if func1 returns r2<>0\n 08h 4 pointer to FIRST function (0=none) ;executed first\n 0Ch 4 Not used (usually zero)\nRemoves the specified element from the specified priority chain. BUG: The function tries to search the whole chain (and to remove the element if it finds it). However, it does only check the first element properly, and, thereafter it reads a garbage value from an uninitialized stack location, and acts more or less unpredictable. So, it can remove only the first element in the chain, ie. it should be called only if you are SURE that there's no newer element in the chain, and only if you are SURE that the element IS in the chain.
"},{"location":"kernelbios/#sys01h-entercriticalsection-syscall-with-r401h","title":"SYS(01h) - EnterCriticalSection() ;syscall with r4=01h","text":"Disables interrupts by clearing SR (cop0r12) Bit 2 and 10 (of which, Bit2 gets copied to Bit0 once when returning from the syscall exception). Returns 1 if both bits were set, returns 0 if one or both of the bits were already zero.
"},{"location":"kernelbios/#sys02h-exitcriticalsection-syscall-with-r402h","title":"SYS(02h) - ExitCriticalSection() ;syscall with r4=02h","text":"Enables interrupts by set SR (cop0r12) Bit 2 and 10 (of which, Bit2 gets copied to Bit0 once when returning from the syscall exception). There's no return value (all registers except SR and K0 are unchanged).
"},{"location":"kernelbios/#c0dh-setirqautoackirqflag","title":"C(0Dh) - SetIrqAutoAck(irq,flag)","text":"Specifies if the DefaultInterruptHandler shall automatically acknowledge IRQs. The \"irq\" paramter is the number of the interrupt, ie. 00h..0Ah = IRQ0..IRQ10. The \"flag\" value should be 0 to disable AutoAck, or non-zero to enable AutoAck. By default, AutoAck is disabled for all IRQs. Mind that the DefaultInterruptHandler is totally bugged. Especially the AutoAck feature doesn't work very well: It may cause higher priority handlers to miss their IRQ, and it may even cause the DefaultInterruptHandler to miss its own IRQs.
"},{"location":"kernelbios/#c06h-exceptionhandler","title":"C(06h) - ExceptionHandler()","text":"The C(06h) vector points to the exception handler, ie. to the function that is invoked from the 4 opcodes at address 80000080h, that opcodes jump directly to the exception handler, so patching the C(06h) vector has no effect. Reading the C(06h) entry can be used to let a custom 80000080h handler pass control back to the default handler (that, by a \"direct\" jump, not by the usual \"MOV R9,06h / CALL 0C0h\" method, which would destroy main programs R9 register). Also, reading C(06h) may be useful for patching the exception handler (which contains a bunch of NOP opcodes, which seem to be intended to insert additional opcodes, such like debugger exception handling) (Note: some of that NOPs are reserved for Memory Card IRQ handling). BUG: Early BIOS versions did try to examine a copy of cop0r13 in r2 register, but did forgot cop0r13 to r2 (so they examined garbage), this was fixed in newer BIOS versions, additionally, most commercial games still include patches for compatibility with the old BIOS.
"},{"location":"kernelbios/#b17h-returnfromexception","title":"B(17h) - ReturnFromException()","text":"Restores the CPU registers (R1-R31,HI,LO,SR,PC) (except R26/K0) from the current TCB. This function is usually executed automatically at the end of the ExceptionHandler, however, functions in the exception chain may call ReturnFromException to return immediately, without processing chain elements of lower priority.
"},{"location":"kernelbios/#c00h-enqueuetimerandvblankirqspriority-used-with-prio1","title":"C(00h) - EnqueueTimerAndVblankIrqs(priority) ;used with prio=1","text":""},{"location":"kernelbios/#c01h-enqueuesyscallhandlerpriority-used-with-prio0","title":"C(01h) - EnqueueSyscallHandler(priority) ;used with prio=0","text":""},{"location":"kernelbios/#c0ch-initdefintpriority-used-with-prio3","title":"C(0Ch) - InitDefInt(priority) ;used with prio=3","text":"Internally used to add some default IRQ and Exception handlers.
"},{"location":"kernelbios/#no-nested-exceptions","title":"No Nested Exceptions","text":"The Kernel doesn't support nested exceptions, that would require a decreasing exception stack, however, the kernel saves the incoming CPU registers in the current TCB, and an exception stack with fixed start address for internal push/pop during exception handling. So, nesting would overwrite these values. Do not enable IRQs, and don't trap other exceptions (like break or syscall opcodes, or memory or overlow errors) during exception handling. Note: The execption stack has a fixed size of 1000h bytes (and is located somewhere in the first 64Kbytes of memory).
"},{"location":"kernelbios/#bios-event-functions","title":"BIOS Event Functions","text":""},{"location":"kernelbios/#b08h-openeventclass-spec-mode-func","title":"B(08h) - OpenEvent(class, spec, mode, func)","text":"Adds an event structure to the event table.
class,spec - triggers if BOTH values match\n mode - (1000h=execute function/stay busy, 2000h=no func/mark ready)\n func - Address of callback function (0=None) (used only when mode=1000h)\n out: R2 = Event descriptor (F1000000h and up), or FFFFFFFFh if failed\nAlways returns 1 (even if the event handle is unused or invalid).
"},{"location":"kernelbios/#b0ch-enableeventevent-turns-on-event-handling-for-specified-event","title":"B(0Ch) - EnableEvent(event) - Turns on event handling for specified event","text":"Always returns 1 (even if the event handle is unused or invalid).
"},{"location":"kernelbios/#b0dh-disableeventevent-turns-off-event-handling-for-specified-event","title":"B(0Dh) - DisableEvent(event) - Turns off event handling for specified event","text":"Always returns 1 (even if the event handle is unused or invalid).
"},{"location":"kernelbios/#b0ah-waiteventevent","title":"B(0Ah) - WaitEvent(event)","text":"Returns 0 if the event is disabled. Otherwise hangs in a loop until the event becomes ready, and returns 1 once when it is ready (and automatically switches the event back to busy status). Callback events (mode=1000h) do never set the ready flag (and thus WaitEvent would hang forever). The main program simply hangs during the wait, so when using multiple threads, it may be more recommended to create an own waitloop that checks TestEvent, and to call ChangeTh when the event is busy. BUG: The return value is unstable (sometimes accidently returns 0=disabled if the event status changes from not-ready to ready shortly after the function call).
"},{"location":"kernelbios/#b0bh-testeventevent","title":"B(0Bh) - TestEvent(event)","text":"Returns 0 if the event is busy or disabled. Otherwise, when it is ready, returns 1 (and automatically switches the event back to busy status). Callback events (mode=1000h) do never set the ready flag.
"},{"location":"kernelbios/#b07h-delivereventclass-spec","title":"B(07h) - DeliverEvent(class, spec)","text":"This function is usually called by the kernel, it triggers all events that are enabled/busy, and that have the specified class and spec values. Depending on the mode, either the callback function is called (mode=1000h), or the event is marked as enabled/ready (mode=2000h).
"},{"location":"kernelbios/#b20h-undelivereventclass-spec","title":"B(20h) - UnDeliverEvent(class, spec)","text":"This function is usually called by the kernel, undelivers all events that are enabled/ready, and that have mode=2000h, and that have the specified class and spec values. Undeliver means that the events are marked as enabled/busy.
"},{"location":"kernelbios/#c04h-get_free_evcb_slot","title":"C(04h) - get_free_EvCB_slot()","text":"A subfunction for OpenEvent.
"},{"location":"kernelbios/#event-classes","title":"Event Classes","text":"File Events:
0000000xh memory card (for file handle fd=x)\n F0000001h IRQ0 VBLANK\n F0000002h IRQ1 GPU\n F0000003h IRQ2 CDROM Decoder\n F0000004h IRQ3 DMA controller\n F0000005h IRQ4 RTC0 (timer0)\n F0000006h IRQ5/IRQ6 RTC1 (timer1 or timer2)\n F0000007h N/A Not used (this should be timer2)\n F0000008h IRQ7 Controller (joypad/memcard)\n F0000009h IRQ9 SPU\n F000000Ah IRQ10 PIO ;uh, does the PIO have an IRQ signal? (IRQ10 is joypad)\n F000000Bh IRQ8 SIO\n F0000010h Exception ;CPU crashed (BRK,BadSyscall,Overflow,MemoryError, etc.)\n F0000011h memory card (lower level BIOS functions)\n F0000012h memory card (not used by BIOS; maybe used by Sony's devkit?)\n F0000013h memory card (not used by BIOS; maybe used by Sony's devkit?)\n F1xxxxxxh event (not used by BIOS; maybe used by Sony's devkit?)\n F2000000h Root counter 0 (Dotclock) (hardware timer)\n F2000001h Root counter 1 (horizontal retrace?) (hardware timer)\n F2000002h Root counter 2 (one-eighth of system clock) (hardware timer)\n F2000003h Root counter 3 (vertical retrace?) (this is a software timer)\n F3xxxxxxh user (not used by BIOS; maybe used by games and/or Sony's devkit?)\n F4000001h memory card (higher level BIOS functions)\n F4000002h libmath (not used by BIOS; maybe used by Sony's devkit?)\n FFxxxxxxh thread (not used by BIOS; maybe used by Sony's devkit?)\n 0001h counter becomes zero\n 0002h interrupted\n 0004h end of i/o\n 0008h file was closed\n 0010h command acknowledged\n 0020h command completed\n 0040h data ready\n 0080h data end\n 0100h time out\n 0200h unknown command\n 0400h end of read buffer\n 0800h end of write buffer\n 1000h general interrupt\n 2000h new device\n 4000h system call instruction ;SYS(04h..FFFFFFFFh)\n 8000h error happened\n 8001h previous write error happened\n 0301h domain error in libmath\n 0302h range error in libmath\n 1000h Execute callback function, and stay busy (do NOT mark event as ready)\n 2000h Do NOT execute callback function, and mark event as ready\nBelow is a list of all events (class,spec values) that are delivered and/or undelivered by the BIOS in one way or another. The BIOS does internally open five events for cdrom (class=F0000003h with spec=10h,20h,40h,80h,8000h). The various other class/spec's are only delivered by the BIOS (but not received by the BIOS) (ie. a game may open/enable memory card events to receive notifications from the BIOS).
"},{"location":"kernelbios/#cdrom-events","title":"CDROM Events","text":" F0000003h,10h cdrom DMA finished (all sectors finished)\n F0000003h,20h cdrom ?\n F0000003h,40h cdrom dead feature (delivered only by unused functions)\n F0000003h,80h cdrom INT4 (reached end of disk)\n F0000003h,100h n/a ? ;undelivered, but not opened, nor delivered\n F0000003h,200h ;undelivered, but not opened\n F0000003h,8000h\n 0000000xh,4 card file handle (x=fd) done okay\n F4000001h,4 card done okay (len=0)\n F4000001h,100h card err busy ;A(A9h)\n F4000001h,2000h card err eject ;A(AAh) or unformatted (bad \"MC\" id)\n F4000001h,8000h card err write ;A(A8h) or A(AEh) or general error\n F0000011h,4 finished okay\n F0000011h,100h err busy\n F0000011h,200h n/a ?\n F0000011h,2000h err\n F0000011h,8000h err\n F0000011h,8001h err (this one is NOT undelivered!)\n F2000000h,2 Timer0 (IRQ4)\n F2000001h,2 Timer1 (IRQ5)\n F2000002h,2 Timer2 (IRQ6)\n F2000003h,2 Vblank (IRQ0) (unstable since IRQ0 is also used for joypad)\n F0000001h,1000h ;IRQ0 (VBLANK)\n F0000002h,1000h ;IRQ1 (GPU)\n F0000003h,1000h ;IRQ2 (CDROM)\n F0000004h,1000h ;IRQ3 (DMA)\n F0000005h,1000h ;IRQ4 (TMR0)\n F0000006h,1000h ;IRQ5 (TMR1)\n F0000006h,1000h ;IRQ6 (TMR2) (accidently uses same event as TMR1)\n F0000008h,1000h ;IRQ7 (joypad/memcard)\n F0000009h,1000h ;IRQ9 (SPU)\n F000000Ah,1000h ;IRQ10 (Joypad and PIO)\n F000000Bh,1000h ;IRQ8 (SIO)\n F0000010h,1000h unknown exception ;neither IRQ nor SYSCALL\n F0000010h,4000h unknown syscall ;syscall(04h..FFFFFFFFh)\nSearches a free TCB, marks it as used, and stores the inital program counter (PC), global pointer (GP aka R28), stack pointer (SP aka R29), and frame pointer (FP aka R30) (using the same value for SP and FP). All other registers are left uninitialized (eg. may contain values from an older closed thread, that includes the SR register, see note). The return value is the new thread handle (in range FF000000h..FF000003h, assuming that 4 TCBs are allocated) or FFFFFFFFh if there's no free TCB. The function returns to the old current thread, use \"ChangeTh\" to switch to the new thread. Note: The desired max number of TCBs can be specified in the SYSTEM.CNF boot file (the default is \"TCB = 4\", one initially used for the boot executable, plus 3 free threads).
"},{"location":"kernelbios/#bug-unitialized-sr-register","title":"BUG - Unitialized SR Register","text":"OpenTh does NOT initialize the SR register (cop0r12) of the new thread. Upon powerup, the bootcode zerofills the TCB memory (so, the SR of new threads will be initially zero; ie. Kernel Mode, IRQ's disabled, and COP2 disabled). However, when closing/reopening threads, the SR register will have the value of the old closed thread (so it may get started with IRQs enabled, and, in worst case, if the old thread should have switched to User Mode, even without access to KSEG0, KSEG1 memory). Or, ACTUALLY, the memory is NOT zerofilled on powerup... so SR is total random?
"},{"location":"kernelbios/#b0fh-closethhandle","title":"B(0Fh) - CloseTh(handle)","text":"Marks the TCB for the specified thread as unused. The function can be used for any threads, including for the current thread. Closing the current thread doesn't terminate the current thread, so it may cause problems once when opening a new thread, however, it should be stable to execute the sequence \"DisableInterrupts, CloseCurrentThread, ChangeOtherThread\". The return value is always 1 (even if the handle was already closed).
"},{"location":"kernelbios/#b10h-changethhandle","title":"B(10h) - ChangeTh(handle)","text":"Pauses the current thread, and activates the selected new thread (or crashes if the specified handle was unused or invalid). The return value is always 1 (stored in the R2 entry of the TCB of the old thread, so the return value will be received once when changing back to the old thread). Note: The BIOS doesn't automatically switch from one thread to another. So, all other threads remain paused until the current thread uses ChangeTh to pass control to another thread. Each thread is having it's own CPU registers (R1..R31,HI,LO,SR,PC), the registers are stored in the TCB of the old thread, and restored when switching back to that thread. Mind that other registers (I/O Ports or GTE registers aren't stored automatically, so, when needed, they need to be pushed/popped by software before/after ChangeTh).
"},{"location":"kernelbios/#c05h-get_free_tcb_slot","title":"C(05h) - get_free_TCB_slot()","text":"Subfunction for OpenTh, returns the number of the first free TCB (usually in range 0..3) or FFFFFFFFh if there's no free TCB.
"},{"location":"kernelbios/#sys03h-changethreadsubfunctionaddr-syscall-with-r403h-r5addr","title":"SYS(03h) ChangeThreadSubFunction(addr) ;syscall with r4=03h, r5=addr","text":"Subfunction for ChangeTh, R5 contains the address of the new TCB, just like all exceptions, the syscall exception is saving the CPU registers in the current TCB, but does then apply the new TCB as current TCB, and so, it does then enter the new thread when returning from the exception.
"},{"location":"kernelbios/#bios-timer-functions","title":"BIOS Timer Functions","text":""},{"location":"kernelbios/#timers-aka-root-counters","title":"Timers (aka Root Counters)","text":"The three hardware timers aren't internally used by any BIOS functions, so they can be freely used by the game, either via below functions, or via direct I/O access.
"},{"location":"kernelbios/#vblank","title":"Vblank","text":"Some of the below functions are allowing to use Vblank IRQs as a fourth \"timer\". However, Vblank IRQs are internally used by the BIOS for handling joypad and memory card accesses. One could theoretically use two separate Vblank IRQ handlers, one for joypad, and one as \"timer\", but the BIOS is much too unstable for such \"shared\" IRQ handling (it may occassionally miss one of the two handlers). So, although Vblank IRQs are most important for games, the PSX BIOS doesn't actually allow to use them for purposes other than joypad access. A possible workaround is to examine the status byte in one of the joypad buffers (ie. the InitPAD2(buf1,22h,buf2,22h) buffers). Eg. a wait_for_vblank function could look like so: set buf1[0]=55h, then wait until buf1[0]=00h or buf1[0]=FFh.
"},{"location":"kernelbios/#b02h-init_timertreloadflags","title":"B(02h) - init_timer(t,reload,flags)","text":"When t=0..2, resets the old timer mode by setting [1F801104h+t*16]=0000h, applies the reload value by [1F801108h+t*16]=reload, computes the new mode:
if flags.bit4=0 then mode=0048h else mode=0049h\n if flags.bit0=0 then mode=mode OR 100h\n if flags.bit12=1 then mode=mode OR 10h\nReads the current timer value: Returns halfword[1F801100h+t*16] for t=0..2. Does nothing and returns zero for t>2.
"},{"location":"kernelbios/#b04h-enable_timer_irqt","title":"B(04h) - enable_timer_irq(t)","text":""},{"location":"kernelbios/#b05h-disable_timer_irqt","title":"B(05h) - disable_timer_irq(t)","text":"Enables/disables timer or vblank interrupt enable bits in [1F801074h], bit4,5,6 for t=0,1,2, or bit0 for t=3, or random/garbage bits for t>3. The enable function returns 1 for t=0..2, and 0 for t=3. The disable function returns always 1.
"},{"location":"kernelbios/#b06h-restart_timert","title":"B(06h) - restart_timer(t)","text":"Sets the current timer value to zero: Sets [1F801100h+t*16]=0000h and returns 1 for t=0..2. Does nothing and returns zero for t>2.
"},{"location":"kernelbios/#c0ah-changeclearrcnttflag-root-counter-aka-timer","title":"C(0Ah) - ChangeClearRCnt(t,flag) ;root counter (aka timer)","text":"Selects what the kernel's timer/vblank IRQ handlers shall do after they have processed an IRQ (t=0..2: timer 0..2, or t=3: vblank) (flag=0: do nothing; or flag=1: automatically acknowledge the IRQ and immediately return from exception). The function returns the old (previous) flag value.
"},{"location":"kernelbios/#bios-joypad-functions","title":"BIOS Joypad Functions","text":""},{"location":"kernelbios/#pad-input","title":"Pad Input","text":"Joypads should be initialized via InitPAD2(buf1,22h,buf2,22h), and StartPAD2(). The main program can read the pad data from the buf1/buf2 addresses (including Status, ID1, button states, and any kind of analogue inputs). For more info on ID1, Buttons and analogue inputs, see Controllers and Memory Cards Note: The BIOS doesn't include any functions for sending custom data to the pads (such like for controlling rumble motors).
"},{"location":"kernelbios/#b12h-initpad2buf1-siz1-buf2-siz2","title":"B(12h) - InitPAD2(buf1, siz1, buf2, siz2)","text":"Memorizes the desired buf1/buf2 addresses, zerofills the buffers by using the siz1/siz2 buffer size values (which should be 22h bytes each). And does some initialization on the PadCardIrq element (but doesn't enqueue it, that must be done by a following call to StartPAD2), and does set the \"pad_enable_flag\", that flag can be also set/cleared via InitCARD2(pad_enable), where it selects if the Pads are kept handled together with Memory Cards. buf1/buf2 are having the following format:
00h Status (00h=okay, FFh=timeout/wrong ID2)\n 01h ID1 (eg. 41h=digital_pad, 73h=analogue_pad, 12h=mouse, etc.)\n 02h..21h Data (max 16 halfwords, depending on lower 4bit of ID1)\nShould be used after InitPAD2. Enqueues the PadCardIrq handler, and does additionally initialize some flags.
"},{"location":"kernelbios/#b14h-stoppad2","title":"B(14h) - StopPAD2()","text":"Dequeues the PadCardIrq handler. Note that this handler is also used for memory cards, so it'll \"stop\" cards, too.
"},{"location":"kernelbios/#b15h-pad_init2type-button_dest-unused-unused","title":"B(15h) - PAD_init2(type, button_dest, unused, unused)","text":"This is an extremely bizarre and restrictive function - don't use! The function fails unless type is 20000000h or 20000001h (the type value has no other function). The function uses \"buf1/buf2\" addresses that are located somewhere \"hidden\" within the BIOS variables region, the only way to read from that internal buffers is to use the ugly \"PAD_dr()\" function. For some strange reason it FFh-fills buf1/buf2, and does then call InitPAD2(buf1,22h,buf2,22) (which does immediately 00h-fill the previously FFh-filled buffers), and does then call StartPAD2(). Finally, it does memorize the \"button_dest\" address (see PAD_dr() for details on that value). The two unused parameters have no function, however, they are internally written back to the stack locations reserved for parameter 2 and 3, ie. at [SP+08h] and [SP+0Ch] on the caller's stack, so the function MUST be called with all four parameters allocated on stack. Return value is 2 (or 0 if type was disliked).
"},{"location":"kernelbios/#b16h-pad_dr","title":"B(16h) - PAD_dr()","text":"This is a very ugly function, using the internal \"buf1/buf2\" values from \"PAD_init2\" and the \"button_dest\" value that was passed to that function. If \"button_dest\" is non-zero, then this function is automatically called by the PadCardIrq handler, and stores it's return value at [button_dest] (where it may be read by the main program). If \"button_dest\" is zero, then it isn't called automatically, and it \\<can> be called manually (with return value in R2), however, it does additionally write the return value to [button_dest], ie. to [00000000h] in this case, destroying that memory location. The return value itself is useless garbage: The lower 16bit contain the pad1 buttons, the upper 16bit the pad2 buttons, of which, both values have reversed byte-order (ie. the first button byte in upper 8bit). The function works only with controller IDs 41h (digital joypad) and 23h (nonstandard device). For ID=23h, the halfword is ORed with 07C7h, and bit6,7 are then cleared if the analogue inputs are greater than 10h. For ID=41h the data is left intact. Any other ID values, or disconnected joypads, cause the halfword to be set to FFFFh (same as when no buttons are pressed), that includes newer analogue pads (unless they are switched to \"digital\" mode).
"},{"location":"kernelbios/#bios-gpu-functions","title":"BIOS GPU Functions","text":""},{"location":"kernelbios/#a48h-sendgp1commandgp1cmd","title":"A(48h) - SendGP1Command(gp1cmd)","text":"Writes [1F801814h]=gp1cmd. There's no return value (r2 is left unchanged).
"},{"location":"kernelbios/#a49h-gpu_cwgp0cmd-send-gp0-command-word","title":"A(49h) - GPU_cw(gp0cmd) ;send GP0 command word","text":"Calls gpu_sync(), and does then write [1F801810h]=gp0cmd. Returns the return value from the gpu_sync() call.
"},{"location":"kernelbios/#a4ah-gpu_cwpsrcnum-send-gp0-command-word-and-parameter-words","title":"A(4Ah) - GPU_cwp(src,num) ;send GP0 command word and parameter words","text":"Calls gpu_sync(), and does then copy \"num\" words from [src and up] to [1F801810h], src should usually point to a command word, followed by num-1 parameter words. Transfer is done by software (without DMA). Always returns 0.
"},{"location":"kernelbios/#a4bh-send_gpu_linked_listsrc","title":"A(4Bh) - send_gpu_linked_list(src)","text":"Transfer an OT via DMA. Calls gpu_sync(), and does then write [1F801814h]=4000002h, [1F8010F4h]=0, [1F8010F0h]=[1F8010F0h] OR 800h, [1F8010A0h]=src, [1F8010A4h]=0, [1F8010A8h]=1000401h. The function does additionally output a bunch of TTY status messages via printf. The function doesn't wait until the DMA is completed. There's no return value.
"},{"location":"kernelbios/#a4ch-gpu_abort_dma","title":"A(4Ch) - gpu_abort_dma()","text":"Writes [1F8010A8h]=401h, [1F801814h]=4000000h, [1F801814h]=2000000h, [1F801814h]=1000000h. Ie. stops GPU DMA, and issues GP1(4), GP1(2), GP1(1). Returns 1F801814h, ie. the I/O address.
"},{"location":"kernelbios/#a4dh-getgpustatus","title":"A(4Dh) - GetGPUStatus()","text":"Reads [1F801814h] and returns that value.
"},{"location":"kernelbios/#a46h-gpu_dwxdstydstxsizysizsrc","title":"A(46h) - GPU_dw(Xdst,Ydst,Xsiz,Ysiz,src)","text":"Waits until GPUSTAT.Bit26 is set (unlike gpu_sync, which waits for Bit28), and does then [1F801810h]=A0000000h, [1F801810h]=YdstXdst, [1F801810h]=YsizXsiz, and finally transfers \"N\" words from [src and up] to [1F801810h], where \"N\" is \"Xsiz*Ysiz/2\". The data is transferred by software (without DMA) (by code executed in the uncached BIOS region with high waitstates, so the data transfer is very SLOW). Caution: If \"Xsiz*Ysiz\" is odd, then the last halfword is NOT transferred, so the GPU stays waiting for the last data value. Returns [SP+04h]=Ydst, [SP+08h]=Xsiz, [SP+0Ch]=Ysiz, [SP+10h]=src+N*4, and R2=src=N*4.
"},{"location":"kernelbios/#a47h-gpu_send_dmaxdstydstxsizysizsrc","title":"A(47h) - gpu_send_dma(Xdst,Ydst,Xsiz,Ysiz,src)","text":"Calls gpu_sync(), writes [1F801810h]=A0000000h, [1F801814h]=4000002h, [1F8010F0h]=[1F8010F0h] OR 800h, [1F8010A0h]=src, [1F8010A4h]=N*10000h+10h (where N=\"Xsiz*Ysiz/32\"), [1F8010A8h]=1000201h. Caution: If \"Xsiz*Ysiz\" is not a multiple of 32, then the last halfword(s) are NOT transferred, so the GPU stays waiting for that values. Returns R2=1F801810h, and [SP+04h]=Ydst, [SP+08h]=Xsiz, [SP+0Ch]=Ysiz.
"},{"location":"kernelbios/#a4eh-gpu_sync","title":"A(4Eh) - gpu_sync()","text":"If DMA is off (when GPUSTAT.Bit29-30 are zero): Waits until GPUSTAT.Bit28=1 (or until timeout). If DMA is on: Waits until D2_CHCR.Bit24=0 (or until timeout), and does then wait until GPUSTAT.Bit28=1 (without timeout, ie. may hang forever), and does then turn off DMA via GP1(04h). Returns 0 (or -1 in case of timeout, however, the timeout values are very big, so it may take a LOT of seconds before it returns).
"},{"location":"kernelbios/#bios-memory-allocation","title":"BIOS Memory Allocation","text":""},{"location":"kernelbios/#a33h-mallocsize","title":"A(33h) - malloc(size)","text":"Allocates size bytes on the heap, and returns the memory handle (aka the address of the allocated memory block). The address of the block is guaranteed to by aligned to 4-byte memory boundaries. Size is rounded up to a multiple of 4 bytes. The address may be in KUSEG, KSEG0, or KSEG1, depending on the address passed to InitHeap. Caution: The BIOS (tries to) initialize the heap size to 0 bytes (actually it accidently overwrites that initial setting by garbage during relocation), so any call to malloc will fail, unless InitHeap has been used to initialize the address/size of the heap.
"},{"location":"kernelbios/#a34h-freebuf","title":"A(34h) - free(buf)","text":"Deallocates the memory block. There's no return value, and no error checking. The function simply sets [buf-4]=[buf-4] OR 00000001h, so if buf is an invalid handle it may destroy memory at [buf-4], or trigger a memory exception (for example, when buf=0).
"},{"location":"kernelbios/#a37h-callocsizx-sizy-slow","title":"A(37h) - calloc(sizx, sizy) ;SLOW!","text":"Allocates xsiz*ysiz bytes by calling malloc(xsiz*ysiz), and, unlike malloc, it does additionally zerofill the memory via SLOW \"bzero\" function. Returns the address of the memory block (or zero if failed).
"},{"location":"kernelbios/#a38h-reallocold_buf-new_size-slow","title":"A(38h) - realloc(old_buf, new_size) ;SLOW!","text":"If \"old_buf\" is zero, executes malloc(new_size), and returns r2=new_buf (or 0=failed). Else, if \"new_size\" is zero, executes free(old_buf), and returns r2=garbage. Else, executes malloc(new_size), bcopy(old_buf,new_buf,new_size), and free(old_buf), and returns r2=new_buf (or 0=failed). Caution: The bcopy function is SLOW, and realloc does accidently copy \"new_size\" bytes from old_buf, so, if the old_size was smaller than new_size then it'll copy whatever garbage data - in worst case, if it exceeds the top of the 2MB RAM region, it may crash with a locked memory exception, although that'd happen only if SetMem(2) was used to restrict RAM to 2MBs.
"},{"location":"kernelbios/#a39h-initheapaddr-size","title":"A(39h) - InitHeap(addr, size)","text":"Initializes the address and size of the heap - the BIOS does not automatically do this, so, before using the heap, InitHeap must be called by software. Usually, the heap would be memory region between the end of the boot executable, and the bottom of the executable's stack. InitHeap can be also used to deallocate all memory handles (eg. when a new exe file has been loaded, it may use it to deallocate all old memory). The heap is used only by malloc/realloc/calloc/free, and by the \"qsort\" function.
"},{"location":"kernelbios/#b00h-alloc_kernel_memorysize","title":"B(00h) - alloc_kernel_memory(size)","text":""},{"location":"kernelbios/#b01h-free_kernel_memorybuf","title":"B(01h) - free_kernel_memory(buf)","text":"Same as malloc/free, but, instead of the heap, manages the 8kbyte control block memory at A000E000h..A000FFFFh. This region is used by the kernel to allocate ExCBs (4x08h bytes), EvCBs (N*1Ch bytes), TCBs (N*0C0h bytes), and the process control block (1x04h bytes). Unlike the heap, the BIOS does automatically initialize this memory region via SysInitMemory(addr,size), and does autimatically allocate the above data (where the number of EvCBs and TCBs is as specified in the SYSTEM.CNF file). Note: FCBs and DCBs are located elsewhere, at fixed locations in the kernel variables area.
"},{"location":"kernelbios/#scratchpad-note","title":"Scratchpad Note","text":"The kernel doesn't include any allocation functions for the scratchpad (nor do any kernel functions use that memory area), so the executable can freely use the \"fast\" memory at 1F800000h..1F8003FFh.
"},{"location":"kernelbios/#a9fh-setmemmegabytes","title":"A(9Fh) - SetMem(megabytes)","text":"Changes the effective RAM size (2 or 8 megabytes) by manipulating port 1F801060h, and additionally stores the size in megabytes in RAM at [00000060h]. Note: The BIOS bootcode accidently sets the RAM value to 2MB (which is the correct physical memory size), but initializes the I/O port to 8MB (which mirrors the physical 2MB within that 8MB region), so the initial values don't match up with each other. Caution: Applying the correct size of 2MB may cause the \"realloc\" function to crash (that function may accidently access memory above 2MB).
"},{"location":"kernelbios/#bios-memory-fillcopycompare-slow","title":"BIOS Memory Fill/Copy/Compare (SLOW)","text":"Like most A(NNh) functions, below functions are executed in uncached BIOS ROM, the ROM has very high waitstates, and the 32bit opcodes are squeezed through an 8bit bus. Moreover, below functions are restricted to process the data byte-by-byte. So, they are very-very-very slow, don't even think about using them. Of course, that applies also for most other BIOS functions. But it's becoming most obvious for these small functions; memcpy takes circa 160 cycles per byte (reasonable would be less than 4 cycles), and bzero takes circa 105 cycles per byte (reasonable would be less than 1 cycles).
"},{"location":"kernelbios/#a2ah-memcpydst-src-len","title":"A(2Ah) - memcpy(dst, src, len)","text":"Copies len bytes from [src..src+len-1] to [dst..dst+len-1]. Refuses to copy any data when dst=00000000h or when len>7FFFFFFFh. The return value is always the incoming \"dst\" value.
"},{"location":"kernelbios/#a2bh-memsetdst-fillbyte-len","title":"A(2Bh) - memset(dst, fillbyte, len)","text":"Fills len bytes at [dst..dst+len-1] with the fillbyte value. Refuses to fill memory when dst=00000000h or when len>7FFFFFFFh. The return value is the incoming \"dst\" value (or zero, when len=0 or len>7FFFFFFFh).
"},{"location":"kernelbios/#a2ch-memmovedst-src-len-bugged","title":"A(2Ch) - memmove(dst, src, len) - bugged","text":"Same as memcpy, but (attempts) to support overlapping src/dst regions, by using a backwards transfer when src\\<dst (and, for some reason, only when dst>=src+len). BUG: The backwards variant accidently transfers len+1 bytes from [src+len..src] down to [dst+len..dst].
"},{"location":"kernelbios/#a2dh-memcmpsrc1-src2-len-bugged","title":"A(2Dh) - memcmp(src1, src2, len) - bugged","text":"Compares len bytes at [src1..src1+len-1] with [src2..src2+len-1], and (attempts) to return the difference between the first mismatching bytes, ie. [src1+N]-[src2+N], or 0 if there are no mismatches. Refuses to compare data when src1 or src2 is 00000000h, and returns 0 in that case. BUG: Accidently returns the difference between the bytes AFTER the first mismatching bytes, ie. [src1+N+1]-[src2+N+1]. That means that a return value of 0 can mean absolutely anything: That the memory blocks are identical, or that a mismatch has been found (but that the NEXT byte after the mismatch does match), or that the function has failed (due to src1 or src2 being 00000000h).
"},{"location":"kernelbios/#a2eh-memchrsrc-scanbyte-len","title":"A(2Eh) - memchr(src, scanbyte, len)","text":"Scans [src..src+len-1] for the first occurence of scanbyte. Refuses to scan any data when src=00000000h or when len>7FFFFFFFh. Returns the address of that first occurence, or 0 if the scanbyte wasn't found.
"},{"location":"kernelbios/#a27h-bcopysrc-dst-len","title":"A(27h) - bcopy(src, dst, len)","text":"Same as \"memcpy\", but with \"src\" and \"dst\" exchanged. That is, the first parameter is \"src\", the refuse occurs when \"src\" is 00000000h, and, returns the incoming \"src\" value (whilst \"memcpy\" uses \"dst\" in that places).
"},{"location":"kernelbios/#a28h-bzerodst-len","title":"A(28h) - bzero(dst, len)","text":"Same as memset, but uses 00h as fixed fillbyte value.
"},{"location":"kernelbios/#a29h-bcmpptr1-ptr2-len-bugged","title":"A(29h) - bcmp(ptr1, ptr2, len) - bugged","text":"Same as \"memcmp\", with exactly the same bugs.
"},{"location":"kernelbios/#bios-string-functions","title":"BIOS String Functions","text":""},{"location":"kernelbios/#a15h-strcatdst-src","title":"A(15h) - strcat(dst, src)","text":"Appends src to the end of dst. Searches the ending 00h byte in dst, and copies src to that address, up to including the ending 00h byte in src. Returns the incoming dst value. Refuses to do anything if src or dst is 00000000h (and returns 0 in that case).
"},{"location":"kernelbios/#a16h-strncatdst-src-maxlen","title":"A(16h) - strncat(dst, src, maxlen)","text":"Same as \"strcat\", but clipped to \"MaxSrc=(min(0,maxlen)+1)\" characters, ie. the total length is max \"length(dst)+min(0,maxlen)+1\". If src is longer or equal to \"MaxSrc\", then only the first \"MaxSrc\" chars are copied (with the last byte being replaced by 00h). If src is shorter, then everything up to the ending 00h byte gets copied, but without additional padding (unlike as in \"strncpy\").
"},{"location":"kernelbios/#a17h-strcmpstr1-str2","title":"A(17h) - strcmp(str1, str2)","text":"Compares the strings up to including ending 00h byte. Returns 0 if they are identical, or otherwise [str1+N]-[str2+N], where N is the location of the first mismatch, the two bytes are sign-expanded to 32bits before doing the subtraction. The function rejects str1/str2 values of 00000000h (and returns 0=both are zero, -1=only str1 is zero, and +1=only str2 is zero).
"},{"location":"kernelbios/#a18h-strncmpstr1-str2-maxlen","title":"A(18h) - strncmp(str1, str2, maxlen)","text":"Same as \"strcmp\" but stops after comparing \"maxlen\" characters (and returns 0 if they did match). If the strings are shorter, then comparision stops at the ending 00h byte (exactly as for strcmp).
"},{"location":"kernelbios/#a19h-strcpydst-src","title":"A(19h) - strcpy(dst, src)","text":"Copies data from src to dst, up to including the ending 00h byte. Refuses to copy anything if src or dst is 00000000h. Returns the incoming dst address (or 0 if copy was refused).
"},{"location":"kernelbios/#a1ah-strncpydst-src-maxlen","title":"A(1Ah) - strncpy(dst, src, maxlen)","text":"Same as \"strcpy\", but clipped to \"maxlen\" characters. If src is longer or equal to maxlen, then only the first \"maxlen\" chars are copied (but without appending an ending 00h byte to dst). If src is shorter, then the remaining bytes in dst are padded with 00h bytes.
"},{"location":"kernelbios/#a1bh-strlensrc","title":"A(1Bh) - strlen(src)","text":"Returns the length of the string up to excluding the ending 00h byte (or 0 when src is 00000000h).
"},{"location":"kernelbios/#a1ch-indexsrc-char","title":"A(1Ch) - index(src, char)","text":""},{"location":"kernelbios/#a1dh-rindexsrc-char","title":"A(1Dh) - rindex(src, char)","text":""},{"location":"kernelbios/#a1eh-strchrsrc-char-exactly-the-same-as-index","title":"A(1Eh) - strchr(src, char) ;exactly the same as \"index\"","text":""},{"location":"kernelbios/#a1fh-strrchrsrc-char-exactly-the-same-as-rindex","title":"A(1Fh) - strrchr(src, char) ;exactly the same as \"rindex\"","text":"Scans for the first (index) or last (rindex) occurence of char in the string. Returns the memory address of that occurence (or 0 if there's no occurence, or if src is 00000000h). Char may be 00h (returns the end address of the string). Note that, despite of the function names, the return value is always a memory address, NOT an index value relative to src.
"},{"location":"kernelbios/#a20h-strpbrksrc-list","title":"A(20h) - strpbrk(src, list)","text":"Scans for the first occurence of a character that is contained in the list. The list contains whatever desired characters, terminated by 00h. Returns the address of that occurence, or 0 if there was none. BUG: If there was no occurence, it returns 0 only if src[0]=00h, and otherwise returns the incoming \"src\" value (which is the SAME return value as when a occurence did occur on 1st character).
"},{"location":"kernelbios/#a21h-strspnsrc-list","title":"A(21h) - strspn(src, list)","text":""},{"location":"kernelbios/#a22h-strcspnsrc-list","title":"A(22h) - strcspn(src, list)","text":"Scans for the first occurence of a character that is (strspn), or that isn't (strcspn) contained in the list. The list contains whatever desired characters, terminated by 00h. Returns the index (relative to src) of that occurence. If there was no occurence, then it returns the length of src. That silly return values do not actually indicate if an occurence has been found or not (unless one checks for [src+index]=00h or so). *** \"The strcspn() function shall compute the length (in bytes) of the maximum initial segment of the string pointed to by s1 which consists entirely of bytes not from the string pointed to by s2.\" \"The strspn() function shall compute the length (in bytes) of the maximum initial segment of the string pointed to by s1 which consists entirely of bytes from the string pointed to by s2.\" *** Hmmmm, that'd be vice-versa?
"},{"location":"kernelbios/#a23h-strtoksrc-list-first-call","title":"A(23h) - strtok(src, list) ;first call","text":""},{"location":"kernelbios/#a23h-strtok0-list-further-calls","title":"A(23h) - strtok(0, list) ;further call(s)","text":"Used to split a string into fragments, list contains a list of characters that are to be treated as separators, terminated by 00h. The first call copies the incoming string to a buffer in the BIOS variables area (the buffer size is 100h bytes, so the string should be max 255 bytes long, plus the ending 00h byte, otherwise the function destroys other BIOS variables), it does then search the first fragment, starting at the begin of the buffer. Further calls (with src=00000000h) are searching further fragments, starting at the buffer address from the previous call. The internal buffer is used only for strtok, so its contents (and the returned string fragments) remain intact until a new first call to strtok takes place. The separate fragments are processed by searching the first separator, starting at the current buffer address, the separator is then replaced by a 00h byte, and the old buffer address is returned to the caller. Moreover, the function tries to skip all continously following separators, until reaching a non-separator, and does memorize that address for the next call (due to that skipping further calls won't return empty fragments, the first call may do so though). That skipping seems to be bugged, if list contains two or more different characters, then additional separators aren't skipped.
\",,TEXT,,,END\" with list=\",\" returns \"\", \"TEXT\", \"END\"\n \",,TEXT,,,END\" with list=\",.\" returns \"\", \"\", \"TEXT\", \"\", \"\", \"END\"\nScans for the first occurence of substr in the string. Returns the memory address of that occurence (or 0 if it was unable to find an occurence). BUG: After rejecting incomplete matches, the function doesn't fallback to the old str address plus 1, but does rather continue at the current str address. Eg. it doesn't find substr=\"aab\" in str=\"aaab\" (in that example, it does merely realize that \"aab\"\\<>\"aaa\" and then that \"aab\"\\<>\"b\").
"},{"location":"kernelbios/#bios-numberstringcharacter-conversion","title":"BIOS Number/String/Character Conversion","text":""},{"location":"kernelbios/#a0eh-absval","title":"A(0Eh) - abs(val)","text":""},{"location":"kernelbios/#a0fh-labsval-exactly-same-as-abs","title":"A(0Fh) - labs(val) ;exactly same as \"abs\"","text":"Returns the absolute value (if val\\<0 then R2=-val, else R2=val).
"},{"location":"kernelbios/#a0ah-todigitchar","title":"A(0Ah) - todigit(char)","text":"Takes the incoming character, ANDed with FFh, and returns 0..9 for characters \"0..9\" and 10..35 for \"A..Z\" or \"a..z\", or 0098967Fh (9,999,999 decimal) for any other 7bit characters, or garbage for characters 80h..FFh.
"},{"location":"kernelbios/#a25h-toupperchar","title":"A(25h) - toupper(char)","text":""},{"location":"kernelbios/#a26h-tolowerchar","title":"A(26h) - tolower(char)","text":"Returns the incoming character, ANDed with FFh, with letters \"A..Z\" converted to uppercase/lowercase format accordingly. Works only for char 00h..7Fh (some characters in range 80h..FFh are left unchanged, others are randomly \"adjusted\" by adding/subtracting 20h, and by sign-expanding the result to 32bits).
"},{"location":"kernelbios/#a0dh-strtolsrc-src_end-base","title":"A(0Dh) - strtol(src, src_end, base)","text":"Converts a string to a number. The function skips any leading \"blank\" characters (that are, 09h..0Dh, and 20h) (ie. TAB, CR, LF, SPC, and some others) (some characters in range 80h..FFh are accidently treated as \"blank\", too). The incoming base value should be in range 2..11, although the function does also accept the buggy values in range of 12..36 (for values other than 2..36 it defaults to decimal/base10). The used numeric digits are \"0..9\" and \"A..Z\" (or less when base is smaller than 36). The string may have a negative sign prefix \"-\" (negates the result) (a \"+\" is NOT recognized; and will be treated as the end of the string). Additionally, the string may contain prefixes \"0b\" (binary/base2), \"0x\" (hex/base16), or \"o\" (octal/base8) (only \"o\", not \"0o\"), allowing to override the incoming \"base\" value. BUG: Incoming base values greater than 11 don't work due to the prefix feature (eg. base=16 with string \"0b11\" will be treated as 11 binary, and base=36 with string \"o55\" will be treated as 55 octal) (the only workaround would be to add/remove leading \"0\" characters, ie. \"b11\" or \"00b11\" or \"0o55\" would work okay). Finally, the function initializes result=0, and does then process the digits as \"result=result*base+digit\" (without any overflow checks) unless/until it reaches an unknown digit (or when digit>=base) (ie. the string may end with 00h, or with any other unexpected characters). The function accepts both uppercase and lowercase characters (both as prefixes, and as numeric digits). The function returns R2=result, and [src_end]=end_address (ie. usually the address of the ending 00h byte; or of any other unexpected end-byte). If src points to 00000000h, then the function returns r2=0, and leaves [src_end] unchanged.
"},{"location":"kernelbios/#a0ch-strtoulsrc-src_end-base","title":"A(0Ch) - strtoul(src, src_end, base)","text":"Same as \"strtol\" except that it doesn't recognize the \"-\" sign prefix (ie. works only for unsigned numbers).
"},{"location":"kernelbios/#a10h-atoisrc","title":"A(10h) - atoi(src)","text":""},{"location":"kernelbios/#a11h-atolsrc-exactly-same-as-atoi-but-slightly-slower","title":"A(11h) - atol(src) ;exactly same as \"atoi\" (but slightly slower)","text":"Same as \"strtol\", except that it doesn't return the string end address in [src_end], and except that it defaults to base=10, but still supports prefixes, allowing to use base2,8,16. CAUTION: For some super bizarre reason, this function treats \"0\" (a leading ZERO digit) as OCTAL prefix (unlike strtol, which uses the \"o\" letter as octal prefix) (the \"0x\" and \"0b\" prefixes are working as usually).
"},{"location":"kernelbios/#a12h-atobsrc-num_dst","title":"A(12h) - atob(src, num_dst)","text":"Calls \"strtol(str,src_end,10)\", and does then exchange the two return values (ie. sets R2=[src_end], and [num_dst]=value_32bit).
"},{"location":"kernelbios/#a0bh-atofsrc-uses-absent-cop1-fpu","title":"A(0Bh) - atof(src) ;USES (ABSENT) COP1 FPU !!!","text":""},{"location":"kernelbios/#a32h-strtodsrc-src_end-uses-absent-cop1-fpu","title":"A(32h) - strtod(src, src_end) ;USES (ABSENT) COP1 FPU !!!","text":"These functions are intended to convert strings to floating point numbers, however, the functions are accidently compiled for MIPS processors with COP1 floating point unit (which is not installed in the PSX, nor does the BIOS support a COP1 software emulation), so calling these functions will produce a coprocessor exception, causing the PSX to lockup via A(40h) SystemErrorUnresolvedException.
"},{"location":"kernelbios/#note_1","title":"Note","text":"On other systems (eg. 8bit computers), \"abs/atoi\" (integer) and \"labs/atol\" (long) may act differently. However, on the Playstation, both use signed 32bit values.
"},{"location":"kernelbios/#bios-misc-functions","title":"BIOS Misc Functions","text":""},{"location":"kernelbios/#a2fh-rand","title":"A(2Fh) - rand()","text":"Advances the random generator as \"x=x*41C64E6Dh+3039h\" (aka plus 12345 decimal), and returns a 15bit random value \"R2=(x/10000h) AND 7FFFh\".
"},{"location":"kernelbios/#a30h-srandseed","title":"A(30h) - srand(seed)","text":"Changes the current 32bit value of the random generator.
"},{"location":"kernelbios/#ab4h-getsysteminfoindex-not-supported-by-old-cex-1000-version","title":"A(B4h) - GetSystemInfo(index) ;not supported by old CEX-1000 version","text":"Returns a word, halfword, or string, depending on the selected index value:
00h Get Kernel BCD Date (eg. 19951204h) (YYYYMMDDh)\n 01h Get Kernel Flags or so (usually/always 000000003h)\n 02h Get Kernel Version String (eg. \"CEX-3000/1001/1002 by K.S.\",0)\n 03h Get whatever halfword (usually 0) ;PS2: returns cop0r15\n 04h Get whatever halfword (usually 0)\n 05h Get RAM Size in kilobytes (usually 2048) ;=[00000060h] SHL 10\n 06h..0Eh Get whatever halfwords (usually 0,400h,0,200h,0,0,1,1,1)\n 0Fh N/A (returns zero) ;PS2: returns 0000h (effectively = same as zero)\n 10h..FFFFFFFFh Not used (returns zero)\nRetrieves the address of the jump lists for B(NNh) and C(NNh) functions, allowing to patch entries in that lists (however, the BIOS does often jump directly to the function addresses, rather than indirectly via the list, so patching may have little effect in such cases). Note: There's no function to retrieve the address of the A(NNh) jump list, however, that list is usually/always at 00000200h.
"},{"location":"kernelbios/#a31h-qsortbase-nel-width-callback","title":"A(31h) - qsort(base, nel, width, callback)","text":"Sorts an array, using a super-slow implementation of the \"quick sort\" algorithm. base is the address of the array, nel is the number of elements in the array, width is the size in bytes of each element, callback is a function that receives pointers to two elements which need to be compared; callback should return return zero if the elements are identical, or a positive/negative number to indicate which element is bigger. The qsort function rearranges the contents of the array, ie. depending on the callback result, it may swap the contents of the two elements, for some bizarre reason it doesn't swap them directly, but rather stores one of the elements temporarily on the heap (that means, qsort works only if the heap was initialized with InitHeap, and only if \"width\" bytes are free). There's no return value.
"},{"location":"kernelbios/#a35h-lsearchkey-base-nel-width-callback","title":"A(35h) - lsearch(key, base, nel, width, callback)","text":""},{"location":"kernelbios/#a36h-bsearchkey-base-nel-width-callback","title":"A(36h) - bsearch(key, base, nel, width, callback)","text":"Searches an element in an array (key is the pointer to the searched element, the other parameters are same as for \"qsort\"). \"lsearch\" performs a slow linear search in an unsorted array, by simply comparing one array element after each other. \"bsearch\" assumes that the array contains sorted elements (eg. via qsort), which is allowing to skip some elements, and to jump back and forth in the array, until it has found the desired element (or the location where it'd be, if it'd be in the array). Both functions return the address of the element (or 0 if it wasn't found).
"},{"location":"kernelbios/#c19h-_ioaborttxt1txt2","title":"C(19h) - _ioabort(txt1,txt2)","text":"Displays the two strings on the TTY (in some cases the BIOS does accidently pass garbage instead of the 2nd string though). And does then execute _ioabort_raw(1), see there for more details.
"},{"location":"kernelbios/#ab2h-_ioabort_rawparam-not-supported-by-old-cex-1000-version","title":"A(B2h) - _ioabort_raw(param) ;not supported by old CEX-1000 version","text":"Executes \"longjmp(ioabortbuffer,param)\". Internally used to recover from failed I/O operations, param should be nonzero to notify the setjmp caller that the abort has occurred.
"},{"location":"kernelbios/#a13h-setjmpbuf","title":"A(13h) - setjmp(buf)","text":"This is a somewhat incomplete implementation of posix's setjmp, by storing the ABI-saved CPU registers in the specified buffer (30h bytes):
00h 4 r31 (ra) (aka caller's pc)\n 04h 4 r29 (sp)\n 08h 4 r30 (fp)\n 0Ch 4x8 r16..r23\n 2Ch 4 r28 (gp)\nRestores the R16-R23,GP,SP,FP,RA registers from a previously recorded jmp_buf buffer, and \"returns\" to that new RA address (rather than to the caller of the longjmp function). The \"param\" value is passed as \"return value\" to the code at RA, ie. usually to the caller of the original setjmp call. Noteworthy difference from a conformant longjmp implementation is that the \"param\" value won't be clamped to 1 if you pass 0 to it. So since setjmp returns 0 on the first call, the caller of longjmp must take care that \"param\" is non-zero, so the callsite of setjmp can make the difference between the first call and a rollback. See setjmp for further details.
"},{"location":"kernelbios/#a53h-set_ioabort_handlersrc-ps2-only-psx-systemerror","title":"A(53h) - set_ioabort_handler(src) ;PS2 only ;PSX: SystemError","text":"Normally the _ioabort handler is changed only internally during booting, with this new function, games can install their own _ioabort handler. src is pointer to a 30h-byte \"savestate\" structure, which will be copied to the actual _ioabort structure.
"},{"location":"kernelbios/#a06h-or-b38h-exitexitcode","title":"A(06h) or B(38h) - exit(exitcode)","text":"Terminates the program and returns control to the BIOS; which does then lockup itself via A(3Ah) _exit.
"},{"location":"kernelbios/#aa0h-_boot","title":"A(A0h) - _boot()","text":"Performs a warmboot (resets the kernel and reboots from CDROM). Unlike the normal coldboot procedure, it doesn't display the \"\\<S>\" and \"PS\" intro screens (and doesn't verify the \"PS\" logo in the ISO System Area), and, doesn't enter the bootmenu (even if the disk drive is empty, or if it contains an Audio disk). And, it doesn't reload the SYSTEM.CNF file, so the function works only if the same disk is still inserted (or another disk with identical SYSTEM.CNF, such like Disk 2 of the same game).
"},{"location":"kernelbios/#ab5hbfh-b11h24h29h2ch31h5ehffh-c1eh7fh-na-jump-0","title":"A(B5h..BFh) B(11h,24h..29h,2Ch..31h,5Eh..FFh) C(1Eh..7Fh) - N/A - Jump 0","text":"These functions jump to address 00000000h. For whatever reason, that address does usually contain a copy of the exception handler (ie. same as at address 80000080h). However, since there's no return address stored in EPC register, the functions will likely crash when returning from the exception handler.
"},{"location":"kernelbios/#a57h5ah73h77h79h7bh7dh7fh80h82h8fhb0hb1hb3h-and","title":"A(57h..5Ah,73h..77h,79h..7Bh,7Dh,7Fh..80h,82h..8Fh,B0h..B1h,B3h), and","text":""},{"location":"kernelbios/#c0eh11h14h-na-returns-0","title":"C(0Eh..11h,14h) - N/A - Returns 0","text":"No function. Simply returns with r2=00000000h. Reportedly, A(85h) is CdStop, but that seems to be nonsense?
"},{"location":"kernelbios/#sys00h-nofunction","title":"SYS(00h) - NoFunction()","text":"No function. Simply returns without changing any registers or memory locations (except that, of course, the exception handler destroys k0).
"},{"location":"kernelbios/#sys04hffffffffh-calls-delivereventf0000010h4000h","title":"SYS(04h..FFFFFFFFh) - calls DeliverEvent(F0000010h,4000h)","text":"These are syscalls with invalid function number in R4. For whatever reason that is handled by issuing DeliverEvent(F0000010h,4000h). Thereafter, the syscall returns to the main program (ie. it doesn't cause a SystemError).
"},{"location":"kernelbios/#a3ah-_exitexitcode","title":"A(3Ah) - _exit(exitcode)","text":""},{"location":"kernelbios/#a40h-systemerrorunresolvedexception","title":"A(40h) - SystemErrorUnresolvedException()","text":""},{"location":"kernelbios/#aa1h-systemerrortypeerrorcode-type-bbootddisk","title":"A(A1h) - SystemError(type,errorcode) ;type \"B\"=Boot,\"D\"=Disk","text":"These are used \"SystemError\" functions. The functions are repeatedly jumping to themselves, causing the system to hang. Possibly useful for debugging software which may hook that functions.
"},{"location":"kernelbios/#a4fh50h52h53h9ah9bh-b1ah1fh21h23h2ah2bh52h5ah-c0bh-na","title":"A(4Fh,50h,52h,53h,9Ah,9Bh) B(1Ah..1Fh,21h..23h,2Ah,2Bh,52h,5Ah) C(0Bh) - N/A","text":"These are additional \"SystemError\" functions, but they are never used. The functions are repeatedly jumping to themselves, causing the system to hang.
"},{"location":"kernelbios/#brk1c00h-division-by-zero-commonly-checkedinvoked-by-software","title":"BRK(1C00h) - Division by zero (commonly checked/invoked by software)","text":""},{"location":"kernelbios/#brk1800h-division-overflow-80000000h-1-sometimes-checked-by-software","title":"BRK(1800h) - Division overflow (-80000000h/-1, sometimes checked by software)","text":"The CPU does not generate any exceptions upon divide overflows, because of that, the Kernel code and many games are commonly checking if the divider is zero (by software), and, if so, execute a BRK 1C00h opcode. The default BIOS exception handler doesn't handle BRK exceptions, and does simply redirect them to SystemErrorUnresolvedException().
"},{"location":"kernelbios/#bios-internal-boot-functions","title":"BIOS Internal Boot Functions","text":""},{"location":"kernelbios/#a45h-init_a0_b0_c0_vectors","title":"A(45h) - init_a0_b0_c0_vectors","text":"Copies the three default four-opcode handlers for the A(NNh),B(NNh),C(NNh) functions to A00000A0h..A00000CFh.
"},{"location":"kernelbios/#c07h-installexceptionhandlers-destroysuses-k0k1","title":"C(07h) - InstallExceptionHandlers() ;destroys/uses k0/k1","text":"Copies the default four-opcode exception handler to the exception vector at 80000080h..8000008Fh, and, for whatever reason, also copies the same opcodes to 80000000h..8000000Fh.
"},{"location":"kernelbios/#c08h-sysinitmemoryaddrsize","title":"C(08h) - SysInitMemory(addr,size)","text":"Initializes the address (A000E000h) and size (2000h) of the allocate-able Kernel Memory region, and, seems to deallocate any memory handles which may have been allocated via B(00h).
"},{"location":"kernelbios/#c09h-sysinitkernelvariables","title":"C(09h) - SysInitKernelVariables()","text":"Zerofills all Kernel variables; which are usually at [00007460h..0000891Fh]. Note: During the boot process, the BIOS accidently overwrites the first opcode of this function (by the last word of the A0h table), so, thereafter, this function won't work anymore (nor would it be of any use).
"},{"location":"kernelbios/#c12h-installdevicesttyflag","title":"C(12h) - InstallDevices(ttyflag)","text":"Initializes the size and address of the File and Device Control Blocks (FCBs and DCBs). Adds the TTY device by calling \"KernelRedirect(ttyflag)\", and the CDROM and Memory Card devices by calling \"AddCDROMDevice()\" and \"AddMemCardDevice()\".
"},{"location":"kernelbios/#c1ch-adjusta0table","title":"C(1Ch) - AdjustA0Table()","text":"Copies the B(32h..3Bh) and B(3Ch..3Fh) function addresses to A(00h..09h) and A(3Bh..3Eh). Apparently Sony's compiler/linker can't insert the addresses in the A0h table directly at compilation time, so this function is used to insert them during execution of the boot code.
"},{"location":"kernelbios/#bios-more-internal-functions","title":"BIOS More Internal Functions","text":"Below are mainly internally used device related subfunctions.
"},{"location":"kernelbios/#internal-device-stuff","title":"Internal Device Stuff","text":" A(5Bh) dev_tty_init() ;PS2: SystemError\n A(5Ch) dev_tty_open(fcb,and unused:\"path\\name\",accessmode) ;PS2: SystemError\n A(5Dh) dev_tty_in_out(fcb,cmd) ;PS2: SystemError\n A(5Eh) dev_tty_ioctl(fcb,cmd,arg) ;PS2: SystemError\n A(5Fh) dev_cd_open(fcb,\"path\\name\",accessmode)\n A(60h) dev_cd_read(fcb,dst,len)\n A(61h) dev_cd_close(fcb)\n A(62h) dev_cd_firstfile(fcb,\"path\\name\",direntry)\n A(63h) dev_cd_nextfile(fcb,direntry)\n A(64h) dev_cd_chdir(fcb,\"path\")\n A(65h) dev_card_open(fcb,\"path\\name\",accessmode)\n A(66h) dev_card_read(fcb,dst,len)\n A(67h) dev_card_write(fcb,src,len)\n A(68h) dev_card_close(fcb)\n A(69h) dev_card_firstfile(fcb,\"path\\name\",direntry)\n A(6Ah) dev_card_nextfile(fcb,direntry)\n A(6Bh) dev_card_erase(fcb,\"path\\name\")\n A(6Ch) dev_card_undelete(fcb,\"path\\name\")\n A(6Dh) dev_card_format(fcb)\n A(6Eh) dev_card_rename(fcb1,\"path\\name1\",fcb2,\"path\\name2\")\n A(6Fh) ? ;card ;[r4+18h]=00000000h ;card_clear_error(fcb) or so\n A(96h) AddCDROMDevice()\n A(97h) AddMemCardDevice()\n A(98h) AddDuartTtyDevice() ;PS2: SystemError\n A(99h) add_nullcon_driver()\n B(47h) AddDrv(device_info) ;subfunction for AddXxxDevice functions\n B(48h) DelDrv(device_name_lowercase)\n B(5Bh) ChangeClearPAD(int) ;pad AND card (ie. used also for Card)\n C(15h) _cdevinput(circ,char)\n C(16h) _cdevscan()\n C(17h) _circgetc(circ) ;uses r5 as garbage txt for _ioabort\n C(18h) _circputc(char,circ)\nDevice Names are case-sensitive (usually lowercase, eg. \"bu\" for memory cards). In filenames, the device name may be followed by a hexadecimal 32bit non-case-sensitive port number (eg. \"bu00:\" for selecting the first memory card slot). Accordingly, the device name should not end with a hexdigit (eg. \"usb:\" would be treated as device \"us\" with port number 0Bh). Standard device names are \"cdrom:\", \"bu00:\", \"bu10:\", \"tty00:\". Other, nonstandard devices are:
Castlevania is trying to access an unknown device named \"sim:\".\n Caetla (a firmware replacement for Cheat Devices) supports \"pcdrv:\" device.\nBelow BRK's are internally used in DTL-H2000 BIOS for two devices: \"mwin:\" (Message Window) and \"sim:\" (CDROM Sim).
"},{"location":"kernelbios/#caetla-blurb","title":"Caetla Blurb","text":"Caetla (a firmware replacement for Cheat Devices) supports \"pcdrv:\" device, the SN systems (=what?) device extension to access files on the drive of the pc. This fileserver can be accessed by using the kernel functions, with the \"pcdrv:\" device name prefix to the filenames or using the SN system calls. The following SN system calls for the fileserver are provided. Accessed by setting the registers and using the break command with the specified field. The break functions have argument(s) in A1,A2,A3 (ie. unlike normal BIOS functions not in A0,A1,A2), and TWO return values (in V0, and V1).
"},{"location":"kernelbios/#brk101h-pcinit-inits-the-fileserver","title":"BRK(101h) - PCInit() - Inits the fileserver","text":"No parameters.
"},{"location":"kernelbios/#brk102h-pccreatfilename-fileattributes-creates-a-new-file-on-pc","title":"BRK(102h) - PCCreat(filename, fileattributes) - Creates a new file on PC","text":" out: V0 0 = success, -1 = failure\n V1 file handle or error code if V0 is negative\n bit0 Read only file (R)\n bit1 Hidden file (H)\n bit2 System file (S)\n bit3 Not used (zero)\n bit4 Directory (D)\n bit5 Archive file (A)\n bit6-31 Not used (zero)\n out: V0 0 = success, -1 = failure\n V1 file handle or error code if V0 is negative\n out: V0 0 = success, -1 = failure\n V1 0 = success, error code if V0 is negative\n out: V0 0 = success, -1 = failure\n V1 number of read bytes or error code if V0 is negative.\n out: V0 0 = success, -1 = failure\n V1 number of written bytes or error code if V0 is negative.\nseekmode may be from 0=Begin of file, 1=Current fpos, or 2=End of file.
out: V0 0 = success, -1 = failure\n V1 file pointer\n in: A0 Pointer to 0 terminated string\n A1,A2,A3,[SP+10h..] Argument(s)\n c display ASCII character\n s display ASCII string\n i,d,D display signed Decimal number (d/i=default32bit, D=force32bit)\n u,U display unsigned Decimal number (u=default32bit, U=force32bit)\n o,O display unsigned Octal number (o=default32bit, O=force32bit)\n p,x,X display unsigned Hex number (p=lower/force32bit, x=lower, X=upper)\n n write 32bit/16bit string length to [parameter] (default32bit)\n + or SPC show leading plus or space character in positive signed numbers\n NNN fixed width (for padding or so) (first digit must be 1..9) (not 0)\n .NNN fixed width (for clipping or so)\n * variable width (using one of the parameters) (negative=ending_spc)\n .* variable width\n - force ending space padding (in case of width being specified)\n # show leading \"0x\" or \"0X\" (hex), or ensure 1 leading zero (octal)\n 0 show leading zero's\n L unknown/no effect?\n h,l force 16bit (h=halfword), or 32bit (l=long/word)\n in: R4=address of string (terminated by 00h)\n in: r4=dst (pointer to a 128-byte buffer) - out: r2=dst (same is incoming r4)\nReads one character from the TTY console, by internally redirecting to \"read(0,tempbuf,1)\". The returned character is ANDed by 7Fh (so, to read a fully intact 8bit character, \"read(0,tempbuf,1)\" must be used instead of this function).
"},{"location":"kernelbios/#a3ch-or-b3dh-putcharchar-write-character-to-tty","title":"A(3Ch) or B(3Dh) - putchar(char) - Write character to TTY","text":"Writes the character to the TTY console, by internally redirecting to \"write(1,tempbuf,1)\". Char 09h (TAB) is expanded to one or more SPC characters, until reaching the next tabulation boundary (every 8 characters). Char 0Ah (LF) is expanded to 0Dh,0Ah (CR,LF). Other special characters (which should be handled at the remote terminal side) are 08h (BS, backspace, move cursor one position to the left), and 07h (BELL, produce a short beep sound).
"},{"location":"kernelbios/#c13h-flushstdinoutput","title":"C(13h) - FlushStdInOutPut()","text":"Closes and re-opens the std_in (fd=0) and std_out (fd=1) file handles.
"},{"location":"kernelbios/#c1bh-kernelredirectttyflag-ps2-ttyflag1-causes-systemerror","title":"C(1Bh) - KernelRedirect(ttyflag) ;PS2: ttyflag=1 causes SystemError","text":"Removes, re-mounts, and flushes the TTY device, the parameter selects whether to mount the real DUART-TTY device (r4=1), or a Dummy-TTY device (r4=0), the latter one sends any std_out to nowhere. Values other than r4=0 or r4=1 do remove the device, but do not re-mount it (which might result in problems). Caution: Trying to use r4=1 on a PSX that does not has the DUART hardware installed causes the BIOS to hang (so one should first detect the DUART hardware, eg. by writing two different bytes to Port 1F802020h.1st/2nd access, and the read and verify that two bytes).
"},{"location":"kernelbios/#activating-std_io","title":"Activating std_io","text":"The std_io functions can be enabled via C(1Bh) KernelRedirect(ttyflag), the BIOS is unable to detect the presence of the TTY hardware, by default the BIOS bootcode disables std_io by setting the initial KernelRedirect value at [A000B9B0h] to zero, this is hardcoded shortly after the POST(E) output:
call output_post_r4 ;\\output POST(E)\n +mov r4,0Eh ;/\n mov r1,0A0010000h ;\\set [0A000B9B0h]=0 ;TTY=dummy/off\n call reset_cont_d_3 ; and call reset_cont_d_3\n +mov [r1-4650h],0 ;/\n mov r1,1h ;\\set [0A000B9B0h]=1 ;TTY=duart/on\n call reset_cont_d_3 ; and call reset_cont_d_3\n +mov [r28-4650h-0ff0h],r1 ;/\nUses printf to display the long and short names from the DCB of the currently installed devices. Doesn't do anything else. There's no return value.
"},{"location":"kernelbios/#note_2","title":"Note","text":"Several BIOS functions are internally using printf to output status information, timeout, and error messages, etc. So, trying to close the TTY file handles (fd=0 and fd=1) would cause such functions to work unstable.
"},{"location":"kernelbios/#bios-character-sets","title":"BIOS Character Sets","text":""},{"location":"kernelbios/#b51h-krom2rawaddshiftjis_code","title":"B(51h) - Krom2RawAdd(shiftjis_code)","text":" In: r4 = 16bit Shift-JIS character code\n Out: r2 = address in BIOS ROM of the desired character (or -1 = error)\n In: r4 = 16bit Shift-JIS character code\n Out: r2 = offset within charset (without charset base address)\nThe character sets are located at BFC64000h and up, intermixed with some other stuff:
BFC64000h Charset 1 (16x15 pix, letters with accent marks) (NOT in JAPAN)\n BFC65CB6h Garbage (four-and-a-half reverb tables, ioports, printf strings)\n BFC66000h Charset 2 (16x15 pix, various alphabets, english, greek, etc.)\n BFC69D68h Charset 3 (16x15 pix, japanese or chinese symbols or so)\n BFC7F8DEh Charset 4 (8x15 pix, mainly ASCII letters)\n BFC7FE6Fh Charset 5 (8x15 pix, additional punctuation marks) (NOT in PS2)\n BFC7FF32h Version (Version and Copyright strings) (NOT in SCPH1000)\n BFC7FF8Ch Charset 6 (8x15 pix, seven-and-a-half japanese chars) (NOT in PS2)\n BFC80000h End (End of 512kBYTE BIOS ROM)\n 00h 4 ptr to first element of exception chain\n 04h 4 not used (zero)\n 00h 4 class (events are triggered when class and spec match)\n 04h 4 status (0=free,1000h=disabled,2000h=enabled/busy,4000h=enabled/ready)\n 08h 4 spec (events are triggered when class and spec match)\n 0Ch 4 mode (1000h=execute function/stay busy, 2000h=no func/mark ready)\n 10h 4 ptr to function to be executed when ready (or 0=none)\n 14h 8 not used (uninitialized)\n 00h 4 status (1000h=Free TCB, 4000h=Used TCB)\n 04h 4 not used (set to 1000h by OpenTh) (not for boot executable?)\n 08h 80h r0..r31 (entries for r0/zero and r26/k0 are unused)\n 88h 4 cop0r14/epc (aka r26/k0 and pc when returning from exception)\n 8Ch 8 hi,lo (the mul/div registers)\n 94h 4 cop0r12/sr (stored/restored by exception, NOT init by OpenTh)\n 98h 4 cop0r13/cause (stored when entering exception, NOT restored on exit)\n 9Ch 24h not used (uninitialized)\n 00h 4 ptr to TCB of current thread\n 00h 4 status (0=Free FCB) (nonzero=accessmode)\n 04h 4 cdrom: disk_id (checksum across path table of the corresponding disk),\n memory card: port number (00h=slot1, 10h=slot2)\n 08h 4 transfer address (for dev_in_out function)\n 0Ch 4 transfer length (for dev_in_out function)\n 10h 4 current file position\n 14h 4 device flags (copy of DCB[04h])\n 18h 4 error ;used by B(55h) - _get_error(fd)\n 1Ch 4 Pointer to DCB for the file\n 20h 4 filesize\n 24h 4 logical block number (start of file) (for cdrom: at least)\n 28h 4 file control block number (simply 0..15 for FCB number 0..15)\n 00h 4 ptr to lower-case short name (\"cdrom\", \"bu\", \"tty\") (or 0=Free DCB)\n 04h 4 device flags (cdrom=14h, bu=14h, tty/dummy=1, tty/duart=3)\n 08h 4 sector size (cdrom=800h, bu=80h, tty=1)\n 0Ch 4 ptr to upper-case long name (\"CD-ROM\", \"MEMORY CARD\", \"CONSOLE\")\n 10h 4 ptr to init() (TTY only)\n 14h 4 ptr to open(fcb,\"path\\name\",accessmode)\n 18h 4 ptr to in_out(fcb,cmd) (TTY only)\n 1Ch 4 ptr to close(fcb)\n 20h 4 ptr to ioctl(fcb,cmd,arg) (TTY only)\n 24h 4 ptr to read(fcb,dst,len)\n 28h 4 ptr to write(fcb,src,len)\n 2Ch 4 ptr to erase(fcb,\"path\\name\")\n 30h 4 ptr to undelete(fcb,\"path\\name\")\n 34h 4 ptr to firstfile2(fcb,\"path\\name\",direntry)\n 38h 4 ptr to nextfile(fcb,direntry)\n 3Ch 4 ptr to format(fcb)\n 40h 4 ptr to cd(fcb,\"path\") (CDROM only)\n 44h 4 ptr to rename(fcb1,\"path\\name1\",fcb2,\"path\\name2\")\n 48h 4 ptr to remove()\n 4Ch 4 ptr to testdevice(fcb,\"path\\name\")\nFor the actual kernel, there seem to be only a few different versions. Most PSX/PSone's are containing the version from 1995 (which is kept 1:1 the same in all consoles; without any PAL/NTSC related customizations).
28-Jul-1994 \"DTL-H2000\" ;v0.x (pre-retail devboard)\n 22-Sep-1994 \"CEX-1000 KT-3 by S.O.\" ;v1.0 through v2.0\n no-new-date \"CEX-3000 KT-3 by K.S.\" ;v2.1 only (old Port 1F801060h)\n 27-Jul-1995 \"Konami OS by T.H.\" ;Twinkle System\n 01-Sep-1995 \"Konami OS by T.H.\" ;Konami GV, GQ, System 573\n 04-Dec-1995 \"CEX-3000/1001/1002 by K.S.\" ;v2.2 through v4.5 (except v4.0)\n 29-May-1997 \"CEX-7000/-7001 by K.S. \" ;v4.0 only (new Port 1F801010h)\n 17-Jan-2000 \"PS compatible mode by M.T.\" ;v5.0 (Playstation 2)\nThis portion was updated more often. It's customized for PAL/NTSC displays, japanese/english language, and (maybe?) region/licence string checks. The SCPH1000 uses uncompressed Bootmenu/Intro code with \"\\<S>\" intro, but without \"PS\" intro (or, \"PS\" is shown only on region matches?), newer versions are using selfdecompressing code, with both intro screens. The GUI in older PSX models looks like a drawing program for children, the GUI in newer PSX models and in PSone's looks more like a modernized bathroom furniture, unknown how the PS2 GUI looks like? Games are communicating only with the Kernel, so the differences in the Bootmenu/Intro part should have little or effect on compatibility (although some I/O ports might be initialized differently, and although some games might (accidently) read different (garbage) values from the ROM).
Ver CRC32 Used in System ROM Version Kernel\n 0.xj 18D0F7D8 DTL-H2000 (no version string) dtlh2000\n 1.0j 3B601FC8 SCPH-1000 and DTL-H1000 (no version string) cex1000\n 1.1j 3539DEF6 SCPH-3000 and DTL-H1000H \"1.1 01/22/95\" \"\"\n 2.0a 55847D8C DTL-H1001 \"2.0 05/07/95 A\" \"\"\n 2.0e 9BB87C4B SCPH-1002 and DTL-H1002 \"2.0 05/10/95 E\" \"\"\n 2.1j BC190209 SCPH-3500 \"2.1 07/17/95 J\" cex3000\n 2.1a AFF00F2F SCPH-1001 and DTL-H1101 \"2.1 07/17/95 A\" \"\"\n 2.1e 86C30531 SCPH-1002 and DTL-H1102 \"2.1 07/17/95 E\" \"\"\n 2.2j 24FC7E17 SCPH-5000 and DTL-H1200 \"2.2 12/04/95 J\" cex3000/100x\n 2.2a 37157331 SCPH-1001 and DTL-H1201/3001 \"2.2 12/04/95 A\" \"\"\n 2.2e 1E26792F SCPH-1002 and DTL-H1202/3002 \"2.2 12/04/95 E\" \"\"\n 2.2v 446EC5B2 SCPH-5903 (VCD, 1Mbyte) \"2.2 12/04/95 J\" \"\"\n 2.2d DECB22F5 DTL-H1100 \"2.2 03/06/96 D\" \"\"\n 3.0j FF3EEB8C SCPH-5500 \"3.0 09/09/96 J\" \"\"\n 3.0a 8D8CB7E4 SCPH-5501/7003 \"3.0 11/18/96 A\" \"\"\n 3.0e D786F0B9 SCPH-5502/5552 \"3.0 01/06/97 E\" \"\"\n 4.0j EC541CD0 SCPH-7000/9000 \"4.0 08/18/97 J\" cex7000\n 4.1w B7C43DAD SCPH-7000W ...XXX...\n 4.1a 502224B6 SCPH-7001/7501/7503/9001 \"4.1 12/16/97 A\" cex3000/100x\n 4.1e 318178BF SCPH-7002/7502/9002 \"4.1 12/16/97 E\" \"\"\n 4.3j F2AF798B SCPH-100 (PSone) \"4.3 03/11/00 J\" \"\"\n 4.4a 6A0E22A0 SCPH-101 (PSone) \"4.4 03/24/00 ..XXX..\n 4.4e 0BAD7EA9 SCPH-102 (PSone) \"4.4 03/24/00 E\" \"\"\n 4.5a 171BDCEC SCPH-101 (PSone) \"4.5 05/25/00 A\" \"\"\n 4.5e 76B880E5 SCPH-102 (PSone) \"4.5 05/25/00 E\" \"\"\n 5.0t B7EF81A9 SCPH10000 (Playstation 2) \"5.0 01/17/00 T\" PS compatible\nv2.2j/a/e use exactly the same GUI as v2.1 (only the kernel was changed). v2.2d is almost same as v2.2j (but with some GUI patches or so). v4.1 and v4.5 use exactly the same GUI code for \"A\" and \"E\" regions (the only difference is the last byte of the version string; which does specify whether the GUI shall use PAL or NTSC). v5.0 is playstation 2 bios (4MB) with more or less backwards compatible kernel.
"},{"location":"kernelbios/#character-set-versions","title":"Character Set Versions","text":"The 16x15 pixel charsets at BFC66000h and BFC69D68h are included in all BIOSes, however, the 16x15 portion for letters with accent marks at BFC64000h is included only in non-japanese BIOSes, and in some newer japanese BIOSes (not included in v4.0j, but they are included in v4.3j). The 8x15 pixel charset with characters 21h..7Fh is included in all BIOSes. In the SCPH1000, this region is followed by additional 8x15 punctuation marks at char 80h and up, however, this region is missing in PS2 BIOS. Moreover, some BIOSes include an incomplete 8x15 japanese character set (which ends abruptly at BF7FFFFFh), in newer BIOSes, some of theses chars are replaced by the version string at BFC7FF32h, and, the remaining 8x15 japanese chars were removed in the PS2 BIOS version.
"},{"location":"kernelbios/#bios-patches","title":"BIOS Patches","text":"The original PSX Kernel mainly consists of messy and unstable compiler generated code, and, to the worst, the \\<same> author seems to have attempted to use assembler code in some places. In result, most commercial games are causing a greater mess by inserting patches in the kernel code... Which has been a nasty surprise when making the nocash PSX bios; which obviously wasn't compatible with these patches. The only solutions would have been to insert hundreds of NOPs to make my bios \\<exactly> as bloated as the original bios (which I really didn't want to do), or to create anti-patch-patches.
"},{"location":"kernelbios/#patches-and-anti-patch-patches","title":"Patches and Anti-Patch-Patches","text":"As shown below, all known patches are invoked by a B(56h) or B(57h) function call. In the nocash PSX bios, these two functions are examining the following opcodes, if the opcodes are a known patch, then the BIOS reproduces the desired behaviour, and does then continue normal execution after those opcodes. If the opcodes are unknown, then the BIOS simply locks up; and shows an error message with the address of that opcodes in the TTY window; info about any such unknown opcodes would be welcome!
"},{"location":"kernelbios/#compatibility","title":"Compatibility","text":"If you want to (or need to) use patches, please use byte-identical opcodes as commercial games do (as shown below; only the \"xxxx\" address digits are don't care), so the nocash PSX bios (or other homebrewn BIOSes) can detect and reproduce them. Or alternately, don't use the BIOS, and access I/O ports directly, which is much better and faster anyways.
"},{"location":"kernelbios/#patch_missing_cop0r13_in_exception_handler","title":"patch_missing_cop0r13_in_exception_handler:","text":"In newer Kernel version, the exception handler reads cop0r13/cause to r2, examines the Excode value in r2, and if the exception was caused by an interrupt, and if the next opcode (at EPC) is a GTE/COP2 command, then it does increment EPC by 4. The GTE commands are executed even if an interrupt occurs simultaneously, so, without adjusting EPC, the command would be executed twice. With some commands that'd just waste some clock cycles, with other commands it may cause data to be written twice to the GTE FIFOs, or may re-use the result from the 1st command execution as input to the 2nd execution. The old \"CEX-1000 KT-3\" Kernel version did examine r2, but it \"forgot\" to previously load cop0r13 to r2, so it did randomly examine a garbage value. The patch inserts the missing opcode, used in elo2 at 80033740h, and in Pandemonium II at 8007F3FCh:
240A00B0 mov r10,0B0h ;\\ 00000000 nop\n 0140F809 call r10 ; 00000000 nop\n 24090056 +mov r9,56h ;/ 241A0100 mov k0,100h\n 3C0Axxxx mov r10,xxxx0000h ;\\ 8F5A0008 mov k0,[k0+8h]\n 3C09xxxx mov r9,xxxx0000h ; 00000000 nop\n 8C420018 mov r2,[r2+06h*4] ;=C(06h) ; 8F5A0000 mov k0,[k0]\n 254Axxxx add r10,xxxxh ;=@@new_data ; 00000000 nop\n 2529xxxx add r9,xxxxh ;=@@new_data_end ;/ 235A0008 addt k0,8h\n @@copy_lop: ;\\ AF410004 mov [k0+4h],r1\n 8D430000 mov r3,[r10] ; AF420008 mov [k0+8h],r2\n 254A0004 add r10,4h ; AF43000C mov [k0+0Ch],r3\n 24420004 add r2,4h ; AF5F007C mov [k0+7Ch],ra\n 1549FFFC jne r10,r9,@@copy_lop ; 40026800 mov r2,cop0r13\n AC43FFFC +mov [r2-4h],r3 ;/ 00000000 nop\n 240A00B0 mov r10,0B0h ;\\ 00000000 nop\n 0140F809 call r10 ; 00000000 nop\n 24090056 +mov r9,56h ;/ 241A0100 mov k0,100h\n 3C1Axxxx mov k0,xxxx0000h ;\\ 8F5A0008 mov k0,[k0+8h]\n 3C1Bxxxx mov k1,xxxx0000h ; 00000000 nop\n 8C420018 mov r2,[r2+06h*4] ;=C(06h) ; 8F5A0000 mov k0,[k0]\n 275Axxxx add k0,xxxxh ;=@@new_data ; 00000000 nop\n 277Bxxxx add k1,xxxxh ;=@@new_data_end ;/ 235A0008 addt k0,8h\n @@copy_lop: ;\\ AF410004 mov [k0+4h],r1\n 8F430000 mov r3,[k0] ; AF420008 mov [k0+8h],r2\n 275A0004 add k0,4h ; AF43000C mov [k0+0Ch],r3\n 24420004 add r2,4h ; AF5F007C mov [k0+7Ch],ra\n 175BFFFC jne k0,k1,@@copy_lop ; 40026800 mov r2,cop0r13\n AC43FFFC +mov [r2-4h],r3 ;/ 00000000 nop\n 24090056 mov r9,56h ;\\\n 240A00B0 mov r10,0B0h ; B(56h) GetC0Table\n 0140F809 call r10 ;\n 00000000 +nop ;/\n 8C420018 mov r2,[r2+06h*4] ;=00000C80h = exception_handler = C(06h)\n 00000000 nop\n 24420028 add r2,28h\n 00407821 mov r15,r2\n 3C0Axxxx lui r10,xxxxh ;\\@@ori_data ;\\\n 254Axxxx add r10,xxxxh ;/ ;\n 3C09xxxx lui r9,xxxxh ;\\@@ori_data_end ; @@ori_data:\n 2529xxxx add r9,xxxxh ;/ ; AF410004 mov [k0+4h],r1\n @@verify_lop: ; AF420008 mov [k0+8h],r2\n 8D430000 mov r3,[r10] ; AF43000C mov [k0+0Ch],r3\n 8C4B0000 mov r11,[r2] ; AF5F007C mov [k0+7Ch],ra\n 254A0004 add r10,4h ; 40037000 mov r3,cop0r14\n 146B000E jne r3,r11,@@verify_mismatch ; 00000000 nop\n 24420004 +add r2,4h ;\n 1549FFFA jne r10,r9,@@verify_lop ;\n 00000000 +nop ;/\n 01E01021 mov r2,r15\n 3C0Axxxx lui r10,xxxxh ;\\@@new_data ;\\\n 254Axxxx add r10,xxxxh ;/ ;\n 3C09xxxx lui r9,xxxxh ;\\@@new_data_end ; @@new_data:\n 2529xxxx add r9,xxxxh ;/ ; AF410004 mov [k0+4h],r1\n @@copy_lop: ; AF420008 mov [k0+8h],r2\n 8D430000 mov r3,[r10] ; 40026800 mov r2,cop0r13\n 00000000 nop ; AF43000C mov [k0+0Ch],r3\n AC430000 mov [r2],r3 ; 40037000 mov r3,cop0r14\n 254A0004 add r10,4h ; AF5F007C mov [k0+7Ch],ra\n 1549FFFB jne r10,r9,@@copy_lop ;\n 24420004 +add r2,4h ;/\n @@verify_mismatch:\n ;BUG1: 8bit \"movb r6\" should be 32bit \"mov r6\"\n ;BUG2: @@copy_lop should transfer 6 words (not 7 words)\n ;BUG3: and, asides, the minimum demo works only with PAL BIOS (not NTSC)\n 0xxxxxxx call xxxxxxxxh ;\\B(56h) GetC0Table\n 00000000 +nop ;/(mov r8,0B0h, jmp r8, +mov r9,56h)\n 3C04xxxx mov r4,xxxx0000h ;\\@@ori_data\n 2484xxxx add r4,xxxxh ;/\n 90460018 movb r6,[r2+06h*4] ;BUG1 ;exception_handler = C(06h)\n 24870018 add r7,r4,18h ;@@ori_end ;\\\n 24C50028 add r5,r6,28h ;C(06h)+28h ;\n 00A03021 mov r6,r5 ; @@ori_data:\n @@verify_lop: ; 80086520 AF410004 mov [k0+4h],r1\n 8CA30000 mov r3,[r5] ; 80086524 AF420008 mov [k0+8h],r2\n 8C820000 mov r2,[r4] ; 80086528 AF43000C mov [k0+0Ch],r3\n 00000000 nop ; 8008652C AF5F007C mov [k0+7Ch],ra\n 1462000C jne r3,r2,@@verify_mismatch ; 80086530 40037000 mov r3,cop0r14\n 24840004 +add r4,4h ; 80086534 00000000 nop\n 1487FFFA jne r4,r7,@@verify_lop ; @@ori_end:\n 24A50004 +add r5,4h ;/\n 00C02821 mov r5,r6 ;\\ @@new_data:\n 3C04xxxx mov r4,xxxx0000h ;\\@@new_data; 80086538 AF410004 mov [k0+4h],r1\n 2484xxxx add r4,xxxxh ;/ ; 8008653C AF420008 mov [k0+8h],r2\n 2483001C add r3,r4,1Ch ;@@bugged_end ; 80086540 40026800 mov r2,cop0r13\n @@copy_lop: ; 80086544 AF43000C mov [k0+0Ch],r3\n 8C820000 mov r2,[r4] ; 80086548 40037000 mov r3,cop0r14\n 24840004 add r4,4h ; 8008654C AF5F007C mov [k0+7Ch],ra\n ACA20000 mov [r5],r2 ; @@new_end:\n 1483FFFC jne r4,r3,@@copy_lop ; 80086550 00000000 nop ;BUG2\n 24A50004 +add r5,4h ;/ @@bugged_end:\n @@verify_mismatch:\nBecause of a hardware glitch the card IRQ cannot be acknowledged while the external IRQ signal is still LOW, making it neccessary to insert a delay that waits until the signal gets HIGH before acknowledging the IRQ. The original BIOS is so inefficient that it takes hundreds of clock cycles between the interrupt request and the IRQ acknowledge, so, normally, it doesn't require an additional delay. However, the central mistake in the IRQ handler is that it doesn't memorize which IRQ has originally triggered the interrupt. For example, it may get triggered by a timer IRQ, but a newer card IRQ may occur during IRQ handling, in that case, the card IRQ may get processed and acknowledged without the required delay. Used in Metal Gear Solid at 8009AA5Ch, and in alone1 at 800AE2F8h:
24090056 mov r9,56h ;\\ ; @@new_data:\n 240A00B0 mov r10,0B0h ; B(56h) GetC0Table ;3C02A001 lui r2,0A001h\n 0140F809 call r10 ; ;2442DFAC sub r2,2054h\n 00000000 +nop ;/ ;00400008 jmp r2 ;=@@new_cont_d\n 8C420018 mov r2,[r2+06h*4] ;\\get C(06h) ;00000000 +nop ;=A000DFACh\n 00000000 nop ;/ ;00000000 nop\n 8C430070 mov r3,[r2+70h] ;\\ ; @@new_data_end:\n 00000000 nop ; get ; @@new_cont_d:\n 3069FFFF and r9,r3,0FFFFh ; early_card ;8C621074 mov r2,[r3+1074h]\n 00094C00 shl r9,10h ; irq_handler ;00000000 nop\n 8C430074 mov r3,[r2+74h] ; ;30420080 and r2,80h ;I_STAT.7\n 00000000 nop ; ;1040000B jz r2,@@ret\n 306AFFFF and r10,r3,0FFFFh ;/ ;00000000 +nop\n 012A1821 add r3,r9,r10 ; @@wait_lop:\n 24620028 add r2,r3,28h ;=early+28h ;8C621044 mov r2,[r3+1044h]\n 3C0Axxxx lui r10,xxxxh ;\\@@new_data ;00000000 nop\n 254Axxxx sub r10,xxxxh ;/ ;30420080 and r2,80h ;JOY_STAT.7\n 3C09xxxx lui r9,xxxxh ;\\@@new_data_end ;1440FFFC jnz r2,@@wait_lop\n 2529xxxx sub r9,xxxxh ;/ ;00000000 +nop\n @@copy_lop: ;3C020001 lui r2,0001h\n 8D430000 mov r3,[r10] ;8C42DFFC mov r2,[r2-2004h]\n 00000000 nop ;00000000 nop\n AC430000 mov [r2],r3 ;00400008 jmp r2 ;=[0000DFFCh]\n 254A0004 add r10,4h ;00000000 +nop\n 1549FFFB jne r10,r9,@@copy_lop ; @@ret:\n 24420004 +add r2,4h ;03E00008 ret\n 3C010001 lui r1,0001h ;\\[DFFCh]=r2 ;00000000 +nop\n 0xxxxxxx call xxxxxxxxh ; and call ... ;\n AC22DFFC +mov [r1-2004h],r2 ;/ ;\n 240A00B0 mov r10,0B0h ;\\ ; @@new_data:\n 0140F809 call r10 ; B(56h) GetC0Table ;3C02xxxx lui r2,8xxxh\n 24090056 +mov r9,56h ;/ ;2442xxxx sub r2,xxxxh\n 8C420018 mov r2,[r2+06h*4] ;\\get C(06h) ;00400008 jmp r2 ;=@@new_cont_d\n 00000000 nop ;/ ;00000000 +nop ;=8xxxxxxxh\n 8C430070 mov r3,[r2+70h] ;\\ ;00000000 nop\n 00000000 nop ; get ; @@new_data_end:\n 3069FFFF and r9,r3,0FFFFh ; early_card ; @@new_cont_d:\n 8C430074 mov r3,[r2+74h] ; irq_handler ;8C621074 mov r2,[r3+1074h]\n 00094C00 shl r9,10h ; ;00000000 nop\n 306AFFFF and r10,r3,0FFFFh ; ;30420080 and r2,80h ;I_STAT.7\n 012A1821 add r3,r9,r10 ;/ ;1040000B jz r2,@@ret\n 3C0Axxxx mov r10,xxxx0000h ;00000000 +nop\n 3C09xxxx mov r9,xxxx0000h ; @@wait_lop:\n 24620028 add r2,r3,28h ;=early+28h ;8C621044 mov r2,[r3+1044h]\n 254Axxxx sub r10,xxxxh ;=@@new_data ;00000000 nop\n 2529xxxx sub r9,xxxxh ;=@@new_data_end ;30420080 and r2,80h ;JOY_STAT.7\n @@copy_lop: ;1440FFFC jnz r2,@@wait_lop\n 8D430000 mov r3,[r10] ;00000000 +nop\n 254A0004 add r10,4h ;3C02xxxx lui r2,8xxxh\n 24420004 add r2,4h ;8C42xxxx mov r2,[r2-xxxxh]\n 1549FFFC jne r10,r9,@@copy_lop ;00000000 nop\n AC43FFFC +mov [r2-4h],r3 ;00400008 jmp r2 ;=[8xxxxxxxh]\n 3C018xxx mov r1,8xxx0000h ;\\[...]=r2, ;00000000 +nop\n 0xxxxxxx call xxxxxxxxh ; and call ... ; @@ret:\n AC22xxxx +mov [r1+xxxxh],r2 ;/ ;03E00008 ret\n ... ;00000000 +nop\nUsed to uninstall the \"early_card_irq_vector\" (the BIOS installs that vector from inside of B(4Ah) InitCARD2(pad_enable), and, without patches, the BIOS doesn't allow to uninstall it thereafter). Used in Breath of Fire III (SLES-01304) at 8017E790, and also in Ace Combat 2 (SLUS-00404) at 801D23F4:
240A00B0 mov r10,0B0h ;\\\n 0140F809 call r10 ; B(56h) GetC0Table\n 24090056 +mov r9,56h ;/\n 3C0Axxxx mov r10,xxxx0000h\n 3C09xxxx mov r9,xxxx0000h\n 8C420018 mov r2,[r2+06h*4] ;=00000C80h = exception_handler = C(06h)\n 254Axxxx add r10,xxxxh ;@@new_data\n 2529xxxx add r9,xxxxh ;@@new_data_end\n @@copy_lop: ;\\ @@new_data:\n 8D430000 mov r3,[r10] ; 00000000 nop\n 254A0004 add r10,4h ; 00000000 nop\n 24420004 add r2,4h ; 00000000 nop\n 1549FFFC jne r10,r9,@@copy_lop ; @@new_data_end:\n AC43006C +mov [r2+70h-4],r3 ;/\n 24090056 mov r9,56h ;\\\n 240A00B0 mov r10,0B0h ; B(56h) GetC0Table\n 0140F809 call r10 ;\n 00000000 +nop ;/\n 8C420018 mov r2,[r2+06h*4] ;=00000C80h = exception_handler = C(06h)\n 3C0Axxxx mov r10,xxxx0000h ;\\@@new_data\n 254Axxxx add r10,xxxxh ;/\n 3C09xxxx mov r9,xxxx0000h ;\\@@new_data_end\n 2529xxxx add r9,xxxxh ;/\n @@copy_lop: ;\\\n 8D430000 mov r3,[r10] ; @@new_data:\n 00000000 nop ; 00000000 nop\n AC430070 mov [r2+70h],r3 ; 00000000 nop\n 254A0004 add r10,4h ;src ; 00000000 nop\n 1549FFFB jne r10,r9,@@copy_lop ; @@new_data_end:\n 24420004 +add r2,4h ;dst ;/\nSame purpose as the \"early_card_irq_patch\" (but for the command/status bytes rather than for the data bytes). The patch looks buggy since it inserts the delay AFTER the acknowledge, but it DOES work (the BIOS accidently acknowledges the IRQ twice; and the delay occurs PRIOR to 2nd acknowledge). Used in Metal Gear Solid at 8009AAF0h, and in Legacy of Kain at 801A56D8h, and in alone1 at 800AE38Ch:
24090057 mov r9,57h ;\\ ; @@new_data:\n 240A00B0 mov r10,0B0h ; B(57h) GetB0Table ; 3C08A001 lui r8,0A001h\n 0140F809 call r10 ;/ ; 2508DF80 sub r8,2080h\n 00000000 +nop ; 0100F809 call r8 ;=A000DF80h\n 8C42016C mov r2,[r2+5Bh*4] ;B(5Bh) ; 00000000 +nop\n 00000000 nop ; 00000000 nop\n 8C4309C8 mov r3,[r2+9C8h] ;blah ; @@new_data_end:\n 3C0Axxxx lui r10,xxxxh ;\\@@new_data ; 946F000A movh r15,[r3+0Ah]\n 254Axxxx sub r10,xxxxh ;/ ; 3C080000 mov r8,0h\n 3C09xxxx lui r9,xxxxh ;\\@@new_data_end ; 01E2C025 or r24,r15,r2\n 2529xxxx sub r9,xxxxh ;/ ; 37190012 or r25,r24,12h\n @@copy_lop: ; A479000A movh [r3+0Ah],r25\n 8D480000 mov r8,[r10] ; 24080028 mov r8,28h\n 00000000 nop ; @@wait_lop:\n AC4809C8 mov [r2+9C8h],r8 ;B(5Bh)+9C8h.. ; 2508FFFF sub r8,1h\n 254A0004 add r10,4h ; 1500FFFE jnz r8,@@wait_lop\n 1549FFFB jne r10,r9,@@copy_lop ; 00000000 +nop\n 24420004 +add r2,4h ; 03E00008 ret ;above delay is\n ... ; 00000000 +nop ;in UNCACHED RAM\n 240A00B0 mov r10,0B0h ;\\ ; @@swap_begin:\n 0140F809 call r10 ; B(57h) GetB0Table ; 3C088xxx lui r8,8xxxh\n 24090057 +mov r9,57h ;/ ; 2508xxxx sub r8,xxxxh\n 8C42016C mov r2,[r2+5Bh*4] ;B(5Bh) ; 0100F809 call r8 ;=8xxxxxxxh\n 3C0Axxxx mov r10,xxxx0000h ; 00000000 +nop\n 3C09xxxx mov r9,xxxx0000h ; 00000000 nop\n 8C4309C8 mov r3,[r2+9C8h] ;blah ; @@swap_end:\n 254Axxxx sub r10,xxxxh ;=@@swap_begin ; ;- - -\n 2529xxxx sub r9,xxxxh ;=@@swap_end ; 00000000 nop\n @@swap_lop: ; 240800C8 mov r8,0C8h\n 8C4309C8 mov r3,[r2+9C8h] ;B(5Bh)+9C8h.. ; @@wait_lop:\n 8D480000 mov r8,[r10] ; 2508FFFF sub r8,1h\n 254A0004 add r10,4h ; 1500FFFE jnz r8,@@wait_lop\n AD43FFFC mov [r10-4h],r3 ; 00000000 +nop\n 24420004 add r2,4h ; 03E00008 ret ;above delay is\n 1549FFFA jne r10,r9,@@swap_lop ; 00000000 +nop ;in CACHED RAM\n AC4809C4 +mov [r2+9C4h],r8 ;\nThe \"card_info\" function sends an incomplete read command to the card; in order to receive status information. After receiving the last byte, the function does accidently send a further byte to the card, so the card responds by another byte (and another IRQ7), which is not processed nor acknowledged by the BIOS. This patch kills the opcode that sends the extra byte. Used in alone1 at 800AE214h:
24090057 mov r9,57h ;\\\n 240A00B0 mov r10,0B0h ; B(57h) GetB0Table\n 0140F809 call r10 ;\n 00000000 +nop ;/\n 240A0009 mov r10,9h ;=blah\n 8C42016C mov r2,[r2+5Bh*4] ;=B(5Bh)\n 00000000 nop\n 20431988 addt r3,r2,1988h ;=B(5Bh)+1988h ;\\store a NOP,\n 0xxxxxxx call xxxxxxxxh ; and call ...\n AC600000 +mov [r3],0 ;=nop ;/\nIf a transmission error occurs (or if there's no controller connected), then the Pad handler handler does usually issue a strange chip select signal to the OTHER controller slot, and does then execute the bizarre_pad_delay function. The patch below overwrites that behaviour by NOPs. Purpose of the original (and patched) behaviour is unknown. Used by Perfect Assassin at 800519D4h:
240A00B0 mov r10,0B0h ;\\\n 0140F809 call r10 ; B(57h) GetB0Table\n 24090057 +mov r9,57h ;/\n 8C42016C mov r2,[r2+5Bh*4] ;=B(5Bh)\n 3C01xxxx mov r1,xxxx0000h\n 20430884 addt r3,r2,884h ;B(5Bh)+884h\n AC23xxxx mov [r1+xxxxh],r3 ;<--- SetPadEnableFlag()\n 3C01xxxx mov r1,xxxx0000h\n 20430894 addt r3,r2,894h ;B(5Bh)+894h\n 2409000B mov r9,0Bh ;len\n AC23xxxx mov [r1+xxxxh],r3 ;<--- ClearPadEnableFlag()\n @@fill_lop: ;\\\n 2529FFFF sub r9,1h ;\n AC400594 mov [r2+594h],0 ;B(5Bh)+594h.. ; erase error handling\n 1520FFFD jnz r9,@@fill_lop ;\n 24420004 +add r2,4h ;/\n 24090057 mov r9,57h ;\\\n 240A00B0 mov r10,0B0h ; B(57h) GetB0Table\n 0140F809 call r10 ;\n 00000000 +nop ;/\n 8C42016C mov r2,[r2+5Bh*4]\n 2409000B mov r9,0Bh ;len\n 20430884 addt r3,r2,884h\n 3C01xxxx mov r1,xxxx0000h\n AC23xxxx mov [r1+xxxxh],r3 ;<--- SetPadEnableFlag()\n 20430894 addt r3,r2,894h\n 3C01xxxx mov r1,xxxx0000h\n AC23xxxx mov [r1+xxxxh],r3 ;<--- ClearPadEnableFlag()\n @@fill_lop: ;\\\n AC400594 mov [r2+594h],0 ;\n 24420004 add r2,4h ; erase error handling\n 2529FFFF sub r9,1h ;\n 1520FFFC jnz r9,@@fill_lop ;\n 00000000 +nop ;/\n 240A00B0 mov r10,0B0h ;\\\n 0140F809 call r10 ; B(57h) GetB0Table\n 24090057 +mov r9,57h ;/\n 8C42016C mov r2,[r2+5Bh*4] ;=B(5Bh)\n 2409000B mov r9,0Bh ;len ;\\\n @@fill_lop: ;\n 2529FFFF sub r9,1h ; erase error handling\n AC400594 mov [r2+594h],0 ;B(5Bh)+594h.. ;\n 1520FFFD jnz r9,@@fill_lop ;\n 24420004 +add r2,4h ;/\nThe normal BIOS functions are only allowing to READ from the controllers, but not to SEND data to them (which would be required to control Rumble motors, and to auto-activate Analog mode without needing the user to press the Analog button). Internally, the BIOS does include some code for sending data to the controller, but it doesn't offer a function vector for setting up the data source address, and, even if that would be supported, it clips the data bytes to 00h or 01h. The patch below retrieves the required SetPadOutput function address (in which only the src1/src2 addresses are relevant, the blah1/blah2 values aren't used), and suppresses clipping (ie. allows to send any bytes in range 00h..FFh). Used in Resident Evil 2 at 80091914h:
240A00B0 mov r10,0B0h ;\\\n 0140F809 call r10 ; B(57h) GetB0Table\n 24090057 +mov r9,57h ;/\n 8C42016C mov r2,[r2+5Bh*4] ;B(5Bh)\n 3C0Axxxx mov r10,xxxx0000h\n 3C09xxxx mov r9,xxxx0000h\n 3C01xxxx mov r1,xxxx0000h\n 204307A0 addt r3,r2,7A0h ;B(5Bh)+7A0h\n 254Axxxx add r10,xxxxh ;=@@new_data\n 2529xxxx add r9,xxxxh ;=@@new_data_end\n AC23xxxx mov [r1-xxxxh],r3 ;<--- SetPadOutput(src1,blah1,src2,blah2)\n @@double_copy_lop: ;\\\n 8D430000 mov r3,[r10] ; @@new_data:\n 254A0004 add r10,4h ; 00551024 and r2,r21\n AC4303D8 mov [r2+3D8h],r3 ;<--- here ; 00000000 nop\n 24420004 add r2,4h ; 00000000 nop\n 1549FFFB jne r10,r9,@@double_copy_lop ; 00000000 nop\n AC4304DC +mov [r2+4DCh],r3 ;<--- here ;/ @@new_data_end:\n 24090057 mov r9,57h ;\\\n 240A00B0 mov r10,0B0h ; B(57h) GetB0Table\n 0140F809 call r10 ;\n 00000000 +nop ;/\n 3C0Axxxx mov r10,xxxx0000h\n 254Axxxx add r10,xxxxh ;=@@new_data\n 3C09xxxx movp r9,xxxx0000h\n 2529xxxx add r9,xxxxh ;=@@new_data_end\n 8C42016C mov r2,[r2+5Bh*4] ;B(5Bh)\n 00000000 nop\n 204307A0 addt r3,r2,7A0h ;B(5Bh)+7A0h\n 3C01xxxx mov r1,xxxx0000h\n AC23xxxx mov [r1+xxxxh],r3 ;<--- SetPadOutput(src1,blah1,src2,blah2)\n @@double_copy_lop: ;\\\n 8D430000 mov r3,[r10] ; @@new_data:\n 00000000 nop ; 00551024 and r2,r21\n AC4303D8 mov [r2+3D8h],r3 ; 00000000 nop\n AC4304E0 mov [r2+4E0h],r3 ; 00000000 nop\n 24420004 add r2,4h ; 00000000 nop\n 254A0004 add r10,4h ; @@new_data_end:\n 1549FFF9 jne r10,r9,@@double_copy_lop ;\n 00000000 +nop ;/\nThis patch suppresses automatic IRQ0 (vblank) acknowleding in the Pad/Card IRQ handler, that, even if auto-ack is enabled. Obviously, one could as well disable auto-ack via B(5Bh) ChangeClearPAD(int), so this patch is total nonsense. Used in Resident Evil 2 at 800919ACh:
240A00B0 mov r10,0B0h ;\\\n 0140F809 call r10 ; B(57h) GetB0Table\n 24090057 +mov r9,57h ;/\n 8C42016C mov r2,[r2+5Bh*4] ;=B(5Bh)\n 240A0009 mov r10,9h ;len ;\\\n 2043062C addt r3,r2,62Ch ;=B(5Bh)+62Ch ;\n @@fill_lop: ;\n 254AFFFF sub r10,1h ;\n AC600000 mov [r3],0 ;\n 1540FFFD jnz r10,@@fill_lop ;\n 24630004 +add r3,4h ;/\n 24090057 mov r9,57h ;\\\n 240A00B0 mov r10,0B0h ; B(57h) GetB0Table\n 0140F809 call r10 ;\n 00000000 +nop ;/\n 240A0009 mov r10,9h ;len\n 8C42016C mov r2,[r2+5Bh*4]\n 00000000 nop\n 2043062C addt r3,r2,62Ch\n @@fill_lop: ;\\\n AC600000 mov [r3],0 ;\n 24630004 add r3,4h ;\n 254AFFFF sub r10,1h ;\n 1540FFFC jnz r10,@@fill_lop ;\n 00000000 +nop ;/\nUsed in Sporting Clays at 80027D68h (when Konami Lightgun connected):
240A00B0 mov r10,0B0h ;\\\n 0140F809 call r10 ; B(56h) GetC0Table\n 24090056 +mov r9,56h ;/\n 3C0Axxxx mov r10,xxxx0000h ;src\n 3C09xxxx mov r9,xxxx0000h ;src.end\n 8C420018 mov r2,[r2+06h*4] ;C(06h)\n 254Axxxx add r10,xxxxh ;src\n 2529xxxx add r9,xxxxh ;src.end (=src+10h)\n @@copy_lop: ;\\ ; @@src:\n 8D430000 mov r3,[r10] ; ;3C02xxxx mov r2,xxxx0000h\n 254A0004 add r10,4h ; ;2442xxxx add r2,xxxxh\n 24420004 add r2,4h ; ;0040F809 call r2 ;lightgun_proc\n 1549FFFC jne r10,r9,@@copy_lop ; ;00000000 +nop\n AC43007C +mov [r2+80h-4],r3 ;/ @@src_end:\n 24090056 mov r9,56h ;\\\n 240A00B0 mov r10,0B0h ; B(56h) GetC0Table\n 0140F809 call r10 ;\n 00000000 +nop ;/\n 8C420018 mov r2,[r2+06h*4] ;=00000C80h = exception_handler = C(06h)\n 3C0Axxxx mov r10,xxxx0000h ;\\@@new_data (3xNOP)\n 254Axxxx add r10,-xxxxh ;/\n 3C09xxxx mov r9,xxxx0000h ;\\@@new_data_end\n 2529xxxx add r9,-xxxxh ;/\n @@copy_lop: ;\\\n 8D430000 mov r3,[r10] ; @@new_data: ;for (un-)install...\n 00000000 nop ; 00000000 nop / 3C02xxxx mov r2,xxxx0000h\n AC430080 mov [r2+80h],r3 ; 00000000 nop / 2442xxxx add r2,-xxxxh\n 254A0004 add r10,4h ; 00000000 nop / 0040F809 call r2 ;proc\n 1549FFFB jne r10,r9,@@copy_lop ; @@new_data_end:\n 24420004 +add r2,4h ;/\nUsed in Spec Ops Airborne Commando at 80070AE8h, and also in the homebrew game Roll Boss Rush at 80010B68h and 8001B85Ch. Purpose is unknown (maybe to override improperly defined .EXE headers).
8C030474 mov r3,[200h+(9Dh*4)] ;\\get ptr to A(9Dh) GetConf (done so,\n 00000000 nop ;/as there's no \"GetA0Table\" funtion)\n 94620000 movh r2,[r3+0h] ;lui msw ;\\\n 84630004 movhs r3,[r3+4h] ;lw lsw+8 ; extract ptr to \"boot_cnf_values\"\n 00021400 shl r2,10h ;msw*10000h ; (from first 2 opcodes of GetConf)\n 2442FFF8 sub r2,8h ;undo +8 ;\n 00431021 add r2,r3 ;lsw ;/\n AC450000 mov [r2+0h],r5 ;num_TCB ;\\set num_EvCB,num_TCB,stacktop\n AC440004 mov [r2+4h],r4 ;num_EvCB ; (unlike A(9Ch) SetConf, without\n 03E00008 ret ; actually reallocting anything)\n AC460008 +mov [r2+8h],r6 ;stacktop ;/\nCAETLA detects the PSX BIOS version by checksumming BFC06000h..BFC07FFFh and does then use some hardcoded BIOS addresses based on that checksum. The reason for doing that is probably that the Pre-Boot Expansion ROM vector is called with the normal A0h/B0h/C0h vectors being still uninitialized. Problems are that the hardcoded addresses won't work with all BIOSes (eg. not with the no$psx bios clone, probably also not with the newer PS2 BIOS), moreover, the checksumming can fail with patched original BIOSes (eg. no$psx allows to enable TTY debug messages and to skip the BIOS intro). The Cheat Firmwares are probably also hooking the Vblank handler, and maybe also some other functions. ACTION REPLAY (at least later versions like 2.81) uses the Pre-Boot handler to set a COP0 hardware breakpoint at 80030000h and does then resume normal BIOS booting (which will then initialize important things like A0h/B0h/C0h tables, and will then break when starting the GUI code at 80030000h). XPLORER searches opcode 24040385h at BFC06000h and up, and does then place a COP0 opcode fetch breakpoint at the opcode address+10h (note: this is within a branch delay slot, which makes COP0 emulation twice as complicated). XPLORER does also require space in unused BIOS RAM addresses (eg. Xplorer v3.20: addr 7880h at 1F002280h, addr 017Fh at 1F006A58h).
"},{"location":"kernelbios/#note_3","title":"Note","text":"Most games include two or three patches. The only game that I've seen so far that does NOT use any patches is Wipeout 2097.
"},{"location":"konamisystem573/","title":"Konami System 573","text":"The System 573 is a PlayStation-based system used in a number of Konami arcade games from the late 90s and early 2000s, most notably Dance Dance Revolution and other titles from the Bemani series of rhythm games.
This document is currently work-in-progress. Here is an incomplete list of things that need more research:
/CE1 and /CE2 are tied together, even though the CPU actually exposes them as separate signals!), have no DMA and don't expose the PCMCIA I/O and configuration space (/IORD and /IOWR are not connected at all). This makes them incompatible with CF cards and most PCMCIA devices.All standard PS1 registers, with the exception of the CD-ROM drive's, are present and accessible. System 573-specific hardware is mapped into the EXP1 region at 0x1f000000. IRQ10 and DMA5, normally reserved for the expansion bus (and lightguns) on a regular PS1, are used to access the ATAPI drive, while IRQ2 and DMA3 go unused.
NOTE: EXP1 must be configured prior to accessing any of these registers. The configuration value written by Konami's code to the EXP1 delay/size register at 0x1f801008 is 0x24173f47. Afterwards, all bus writes shall be 16 or 32 bits wide. The behavior of 8-bit writes is undefined, but 8-bit reads work as intended.
0x1f000000-0x1f3fffff Bank switched, can be mapped to flash or PCMCIA slots 0x1f400000-0x1f40000f Konami ASIC registers 0x1f480000-0x1f48000f IDE register bank 0 0x1f4c0000-0x1f4c000f IDE register bank 1 0x1f620000-0x1f623fff RTC registers and battery-backed RAM 0x1f640000-0x1f6400ff I/O board registers 0x1f500000-0x1f6a0001 Other registers"},{"location":"konamisystem573/#konami-asic-registers","title":"Konami ASIC registers","text":"Registers in the 0x1f400000-0x1f40000f region are handled by the Konami 056879 I/O ASIC, consisting of a single 8-bit output port and at least six 16-bit input ports. The same chip was used in other Konami arcade boards of the time.
0x1f400000 (ASIC register 0): ADC / Coin counters / Audio control","text":"Bits RW Description 0 W Data input to ADC (DI) 1 W Chip select to ADC (/CS) 2 W Data clock to ADC (CLK) 3 W Coin counter 1 (1 = energize counter coil) 4 W Coin counter 2 (1 = energize counter coil) 5 W Built-in audio amplifier enable (0 = muted) 6 W External audio input enable (0 = muted) 7 W SPU DAC output enable (0 = muted) 8 W JVS MCU reset output (0 = pull reset low) 9-15 Unused The ADC chip is an ADC0834 from TI, which uses a proprietary SPI-like protocol. Its four inputs are wired to the ANALOG connector on the 573 motherboard. Refer to the ADC083x datasheet for details on how to bitbang the protocol.
Mechanical coin counters are incremented by games whenever a coin is inserted by setting bit 3 or 4 for a fraction of a second and then clearing them. Bit 5 controls whether the onboard audio amp is enabled but does not affect the RCA line level outputs, which are always enabled. Setting bit 5 has no effect immediately as the amplifier takes about a second to turn on.
Bit 6 is used by games to mute audio from the CD-ROM drive or digital I/O board. However, testing on real hardware seems to suggest it is actually some sort of attenuation control, as the audio is still audible (albeit at a very low volume) when the bit is cleared. Note that some games, such as GuitarFreaks, break the CD/MP3 output to separate jacks on the front I/O panel rather than routing it through the motherboard, making bit 6 meaningless.
Bit 8 resets the JVS MCU. Since the reset pin is active-low, resetting is done by writing 0, waiting at least 10 H8 clock cycles (the BIOS waits 2 hblanks) and writing 1 again. Resetting the MCU will clear JVSDRDY but not JVSIRDY. As the 056879 ASIC's output register is only 8 bits wide, bit 8 is actually handled by a discrete flip-flop on the motherboard.
Unknown what reading from this port does.
"},{"location":"konamisystem573/#0x1f400004-asic-register-2-dip-switches-jvs-status-security-cartridge","title":"0x1f400004 (ASIC register 2): DIP switches / JVS status / Security cartridge","text":"Bits RW Description 0-3 R DIP switch 1-4 status (0 = on, 1 = off) 4-5 R Current JVS MCU status code 6-7 R Current JVS MCU error code 8-15 R I0-I7 from security cartridge The MCU status code can be one of the following values:
Code Description 0 Waiting for the 573 to read or write the first word of a packet 1 Busy (sending a packet or waiting for a response) 2 Waiting for the 573 to finish reading or writing a packet 3 UnusedThe MCU error code can be one of the following values:
Code Description 0 Unused 1 Packet written by the 573 has an invalid checksum 2 Packet written by the 573 does not start with a0xe0 sync byte 3 No error Once an error is reported, the MCU will enter an endless loop and become unresponsive. In order to clear the error the MCU must be reset using bit 8 in register 0x1f400000.
The highest 8 bits read from this register are the current state of the security cartridge's I0-I7 pins. See the security cartridge section for an explanation of what each bit is wired to. Unknown whether reading from this register will clear the IRDY flag, if previously set by the cartridge.
Bit 3 (DIP switch 4) is used by the BIOS to determine whether to boot from flash. If set, the BIOS will attempt to search for a valid executable on the internal flash and both PCMCIA cards prior to falling back to the CD-ROM.
"},{"location":"konamisystem573/#0x1f400006-asic-register-3-misc-inputs","title":"0x1f400006 (ASIC register 3): Misc. inputs","text":"Bits RW Description 0 R Data output from ADC (DO) 1 R SAR status from ADC (SARS) 2 R From SDA on security cartridge 3 R Sense input from JVS port 4 R JVSIRDY status from JVS MCU 5 R JVSDRDY status from JVS MCU 6 R IRDY status from security cartridge 7 R DRDY status from security cartridge 8 R Coin switch input 1 (0 = coin being inserted) 9 R Coin switch input 2 (0 = coin being inserted) 10 R PCMCIA card 1 insertion (0 = card present) 11 R PCMCIA card 2 insertion (0 = card present) 12 R Service button (JAMMA pin R, 0 = pressed) 13-15 Unused? See the security cartridge section for more details about IRDY and DRDY. In order for bit 2 to be valid, SDA should be set as an input by clearing the respective bit in register 0x1f500000.
0x1f400008 (ASIC register 4): JAMMA controls","text":"Bits RW Description 0 R Player 2 joystick left (JAMMA pin X) 1 R Player 2 joystick right (JAMMA pin Y) 2 R Player 2 joystick up (JAMMA pin V) 3 R Player 2 joystick down (JAMMA pin W) 4 R Player 2 button 1 (JAMMA pin Z) 5 R Player 2 button 2 (JAMMA pin a) 6 R Player 2 button 3 (JAMMA pin b) 7 R Player 2 start button (JAMMA pin U) 8 R Player 1 joystick left (JAMMA pin 20) 9 R Player 1 joystick right (JAMMA pin 21) 10 R Player 1 joystick up (JAMMA pin 18) 11 R Player 1 joystick down (JAMMA pin 19) 12 R Player 1 button 1 (JAMMA pin 22) 13 R Player 1 button 2 (JAMMA pin 23) 14 R Player 1 button 3 (JAMMA pin 24) 15 R Player 1 start button (JAMMA pin 17) As buttons are active-low (wired between JAMMA pins and ground), all bits are 0 when a button is pressed and 1 otherwise. The BIOS and games often read from this register and discard the result as a way of (inefficiently) flush the CPU's write queue.
"},{"location":"konamisystem573/#0x1f40000a-asic-register-5-data-from-jvs-mcu","title":"0x1f40000a (ASIC register 5): Data from JVS MCU","text":"Bits RW Description 0-15 R Current data word from MCU This register is only valid when the JVSIRDY flag is set. After reading, a dummy write to 0x1f520000 shall be issued to clear JVSIRDY. If the MCU has more data available, it will update the register and set the flag again.
0x1f40000c (ASIC register 6): JAMMA controls / External inputs","text":"Bits RW Description 0-7 Unused? 8 R Player 1 button 4 (JAMMA pin 25) 9 R Player 1 button 5 (JAMMA pin 26) 10 R Test button (built-in and JAMMA pin 15) 11 R Player 1 button 6 12-15 Unused? As buttons are active-low (wired between JAMMA pins and ground), all bits are 0 when a button is pressed and 1 otherwise.
The signals for buttons 4 and 5 are wired in parallel to both JAMMA and the EXT-IN connector, while button 6 can only be connected through EXT-IN and is usually unused.
0x1f40000e (ASIC register 7): JAMMA controls / External inputs","text":"Bits RW Description 0-7 Unused? 8 R Player 2 button 4 (JAMMA pin c) 9 R Player 2 button 5 (JAMMA pin d) 10 Unused? 11 R Player 2 button 6 12-15 Unused? As buttons are active-low (wired between JAMMA pins and ground), all bits are 0 when a button is pressed and 1 otherwise.
The signals for buttons 4 and 5 are wired in parallel to both JAMMA and the EXT-IN connector, while button 6 can only be connected through EXT-IN and is usually unused.
The IDE interface consists of a 16-bit parallel data bus with a 3-bit address bus and two bank select pins (/CS0 and /CS1), giving a total of sixteen 16-bit registers of which only nine are typically used. On the 573 the two IDE banks are mapped to two separate memory regions at 0x1f480000 and 0x1f4c0000 respectively. The IDE interrupt pin is routed into IRQ10 through the CPLD, while all other signals on the 40-pin connector (DMA handshaking lines, status pins, etc.) go unused.
Most 573 games, with the exception of those that run entirely from the internal flash or PCMCIA cards, expect an ATAPI CD-ROM drive to be always connected and configured as the primary (master) drive. Connecting an additional ATA hard drive, CF card, IDE-to-SATA bridge or other device configured as secondary will not interfere with the BIOS or games, thus homebrew games and apps can leverage such a drive to store data separately from the currently installed game.
Note that IDE and ATAPI give slightly different meanings to each register. Refer to the ATA and ATAPI specifications for more details.
"},{"location":"konamisystem573/#0x1f480000-ide-bank-0-address-0-data","title":"0x1f480000 (IDE bank 0, address 0): Data","text":"Bits RW Description 0-15 RW Current packet or data word Data transfers can also be performed through DMA. See below for details.
"},{"location":"konamisystem573/#0x1f480002-ide-bank-0-address-1-error-features","title":"0x1f480002 (IDE bank 0, address 1): Error / Features","text":"When read:
Bits RW Description (ATA) Description (ATAPI) 0 R Unused Illegal length flag (ILI) 1 R No media flag (NM) End of media flag (EOM) 2 R Command aborted flag (ABRT) Command aborted flag (ABRT) 3 R Media change request flag (MCR) Unused 4 R Address not found flag (IDNF) SCSI sense key bit 0 5 R Media changed flag (MC) SCSI sense key bit 1 6 R Uncorrectable error flag (UNC) SCSI sense key bit 2 7 R DMA CRC error flag (ICRC) SCSI sense key bit 3 8-15 Unused Unused When written:
Bits RW Description 0-7 W Command-specific feature index or flags 8-15 Unused"},{"location":"konamisystem573/#0x1f480004-ide-bank-0-address-2-sector-count","title":"0x1f480004 (IDE bank 0, address 2): Sector count","text":"Bits RW Description (ATA) Description (ATAPI) 0-7 W Transfer sector count Unused 8-15 Unused Unused In ATA 48-bit LBA mode, bits 8-15 of the number of sectors to transfer must be written to this register first, followed by bits 0-7.
In ATA CHS or 28-bit LBA mode, setting this register to 0 will cause 256 sectors to be transferred.
"},{"location":"konamisystem573/#0x1f480006-ide-bank-0-address-3-sector-number","title":"0x1f480006 (IDE bank 0, address 3): Sector number","text":"Bits RW Description (ATA) Description (ATAPI) 0-7 W CHS sector index or LBA bits 0-7 Unused 8-15 Unused Unused In ATA 48-bit LBA mode, bits 24-31 of the target LBA must be written to this register first, followed by bits 0-7.
"},{"location":"konamisystem573/#0x1f480008-ide-bank-0-address-4-cylinder-number-low","title":"0x1f480008 (IDE bank 0, address 4): Cylinder number low","text":"Bits RW Description (ATA) Description (ATAPI) 0-7 RW CHS cylinder index bits 0-7 or LBA bits 8-15 Transfer chunk size bits 0-7 8-15 Unused Unused In ATA 48-bit LBA mode, bits 32-39 of the target LBA must be written to this register first, followed by bits 8-15.
"},{"location":"konamisystem573/#0x1f48000a-ide-bank-0-address-5-cylinder-number-high","title":"0x1f48000a (IDE bank 0, address 5): Cylinder number high","text":"Bits RW Description (ATA) Description (ATAPI) 0-7 RW CHS cylinder index bits 8-15 or LBA bits 16-23 Transfer chunk size bits 8-15 8-15 Unused Unused In ATA 48-bit LBA mode, bits 40-47 of the target LBA must be written to this register first, followed by bits 16-23.
"},{"location":"konamisystem573/#0x1f48000c-ide-bank-0-address-6-head-number-drive-select","title":"0x1f48000c (IDE bank 0, address 6): Head number / Drive select","text":"Bits RW Description (ATA) Description (ATAPI) 0-3 W CHS head index or 28-bit LBA bits 24-27 Reserved (should be 0) 4 RW Drive select (0 = primary, 1 = secondary) Drive select (0 = primary, 1 = secondary) 5 Reserved (should be 1?) Reserved (should be 1?) 6 W Sector addressing mode (0 = CHS, 1 = LBA) Reserved (should be 0) 7 Reserved (should be 1?) Reserved (should be 1?) 8-15 Unused Unused Bits 0-3 are not used in ATA 48-bit LBA mode.
"},{"location":"konamisystem573/#0x1f48000e-ide-bank-0-address-7-status-command","title":"0x1f48000e (IDE bank 0, address 7): Status / Command","text":"When read:
Bits RW Description (ATA) Description (ATAPI) 0 R Error flag (ERR) Error flag (CHK) 1 R Unused Unused 2 R Unused Unused 3 R Data request flag (DRQ) Data request flag (DRQ) 4 R Drive write error flag (DWE) Overlapped service flag (SERV) 5 R Drive fault flag (DF) Drive fault flag (DF) 6 R Drive ready flag (DRDY) Drive ready flag (DRDY) 7 R Drive busy flag (BSY) Drive busy flag (BSY) 8-15 Unused Unused When written:
Bits RW Description 0-7 W Command index 8-15 UnusedIn order to issue a command, the features, sector, cylinder and head registers must be set up appropriately before writing the command ID to this register. Refer to the ATA specification for a list of available commands and their parameters.
DRDY is set by the drive when it is ready to execute an ATA command. Note that ATAPI drives will not set DRDY initially, while still accepting ATAPI commands, in order to prevent misdetection as a hard drive. Before sending any command, a polling loop shall be used to wait until BSY is cleared.
DRQ is set when the drive is waiting for data to be read or written. Depending on the drive and command, an interrupt may also be fired when DRQ goes high after a command is issued. ERR/CHK is set if the last command executed resulted in an error; in that case the error register will contain more information about the cause of the error.
Reading from this register will acknowledge any pending drive interrupt and deassert IRQ10. Note that, as with all PS1 interrupts, IRQ10 must additionally be acknowledged at the interrupt controller side in order for it to fire again.
"},{"location":"konamisystem573/#0x1f4c000c-ide-bank-1-address-6-alternate-status","title":"0x1f4c000c (IDE bank 1, address 6): Alternate status","text":"Bits RW Description (ATA) Description (ATAPI) 0 R Error flag (ERR) Error flag (CHK) 1 R Unused Unused 2 R Unused Unused 3 R Data request flag (DRQ) Data request flag (DRQ) 4 R Drive write error flag (DWE) Overlapped service flag (SERV) 5 R Drive fault flag (DF) Drive fault flag (DF) 6 R Drive ready flag (DRDY) Drive ready flag (DRDY) 7 R Drive busy flag (BSY) Drive busy flag (BSY) 8-15 Unused Unused Read-only mirror of the status register at 0x1f48000e that returns the same flags, but does not acknowledge any pending IRQ when read.
DMA channel 5, normally reserved for the expansion port on a PS1, can be used to transfer data to/from the IDE bus... with some caveats. The \"correct\" way to connect an IDE drive to the PS1's DMA controller would to be to wire up DMARQ and /DMACK from the drive directly to the respective pins on the CPU, allowing the DMA controller to synchronize transfers to the drive's internal buffer in chunked mode.
However, Konami being Konami, they did not do this on the 573. IDE drives will instead interpret DMA reads or writes as a burst of regular (\"PIO\", as defined in the ATA specification) CPU-issued reads or writes. As such, the drive shall be configured for PIO data transfers rather than DMA using the \"set features\" ATA command, and bits 9-10 in the DMA5_CHCR register shall be cleared to put the channel in manual synchronization mode. The DRQ bit in the status register must also be polled manually prior to starting a transfer, to ensure the drive is ready for it.
The RTC is an ST M48T58. This chip behaves like an 8 KB 8-bit static RAM, wired to the lower 8 bits of the 16-bit data bus. It must thus be accessed by performing 16-bit bus accesses and ignoring/masking out the upper 8 bits (as with IDE control registers).
The first 8184 bytes are mapped to the 0x1f620000-0x1f623fef region and are simply battery-backed SRAM, which will retain its contents across power cycles as long as the RTC's battery is not dead. The last 8 bytes are used as clock and control registers.
The values of the clock registers are buffered: they are stored in intermediate registers rather than being read from or written to the clock counters directly. Bits 6 and 7 in the control register at 0x1f623ff0 are used to control transfers between the registers and clock counters. All clock values are returned in BCD format.
0x1f623ff0 (M48T58 register 0x1ff8): Calibration / Control","text":"Bits RW Buffered Description 0-4 RW Unknown Calibration offset (0-31), adjusts oscillator frequency 5 RW Unknown Sign bit for calibration offset (1 = positive) 6 W No Read mutex (1 = prevent buffered register updates) 7 W No Write mutex and trigger 8-15 Unused The values of all buffered clock registers are updated automatically. Setting bit 6 will disable this behavior while keeping the counters running, allowing for the registers to be read reliably without the RTC updating them at the same time. The bit shall be cleared after reading the registers.
Setting bit 7 will also halt buffered register updates, so that they can be overwritten manually with new values. Clearing it afterwards will result in the registers' values being copied back to the clock counters.
"},{"location":"konamisystem573/#0x1f623ff2-m48t58-register-0x1ff9-seconds-stop","title":"0x1f623ff2 (M48T58 register 0x1ff9): Seconds / Stop","text":"Bits RW Buffered Description 0-3 RW Yes Second units (0-9) 4-6 RW Yes Second tens (0-5) 7 RW Unknown Stop flag (0 = clock paused, 1 = clock running) 8-15 Unused"},{"location":"konamisystem573/#0x1f623ff4-m48t58-register-0x1ffa-minute","title":"0x1f623ff4 (M48T58 register 0x1ffa): Minute","text":"Bits RW Buffered Description 0-3 RW Yes Minute units (0-9) 4-6 RW Yes Minute tens (0-5) 7 Reserved (must be 0) 8-15 Unused"},{"location":"konamisystem573/#0x1f623ff6-m48t58-register-0x1ffb-hour","title":"0x1f623ff6 (M48T58 register 0x1ffb): Hour","text":"Bits RW Buffered Description 0-3 RW Yes Hour units (0-9, or 0-3 if tens = 2) 4-5 RW Yes Hour tens (0-2) 6-7 Reserved (must be 0) 8-15 Unused Hours are always returned in 24-hour format, as there is no way to switch to 12-hour format.
"},{"location":"konamisystem573/#0x1f623ff8-m48t58-register-0x1ffc-day-of-week-century","title":"0x1f623ff8 (M48T58 register 0x1ffc): Day of week / Century","text":"Bits RW Buffered Description 0-2 RW Yes Day of week (1-7) 3 Reserved (must be 0) 4 RW Yes Century flag 5 RW Unknown Century flag toggling enable (1 = enabled) 6 RW Unknown Enable 512 Hz clock signal output on pin 1 7 Reserved (must be 0) 8-15 Unused The day of week register is a free-running counter incremented alongside the day counter. There is no logic for calculating the day of the week, so it must be updated manually when setting the time. Konami games use 1 as Sunday, 2 as Monday and so on.
Bit 4 is a single-bit \"counter\" that gets toggled each time the year counter overflows. It can be frozen by clearing bit 5. Konami games do not use the century flag, as they interpret any year counter value in 70-99 range as 1970-1999 and all other values as a year after 2000.
"},{"location":"konamisystem573/#0x1f623ffa-m48t58-register-0x1ffd-day-of-month-battery-state","title":"0x1f623ffa (M48T58 register 0x1ffd): Day of month / Battery state","text":"Bits RW Buffered Description 0-3 RW Yes Day of month units (range depends on tens and month) 4-5 RW Yes Day of month tens (range depends on month) 6 R No Low battery flag (1 = battery voltage is below 2.5V) 7 RW Unknown Battery monitoring enable (1 = enabled) 8-15 Unused Bit 6 is updated when the system is power cycled, if bit 7 has previously been set.
"},{"location":"konamisystem573/#0x1f623ffc-m48t58-register-0x1ffe-month","title":"0x1f623ffc (M48T58 register 0x1ffe): Month","text":"Bits RW Buffered Description 0-3 RW Yes Month units (1-9, or 0-2 if tens = 1) 4 RW Yes Month tens (0-1) 5-7 Reserved (must be 0) 8-15 Unused"},{"location":"konamisystem573/#0x1f623ffe-m48t58-register-0x1fff-year","title":"0x1f623ffe (M48T58 register 0x1fff): Year","text":"Bits RW Buffered Description 0-3 RW Yes Year units (0-9) 4-7 RW Yes Year tens (0-9) 8-15 Unused The year counter covers a full century, going from 00 to 99. On each overflow the century flag in the day of week register is toggled.
"},{"location":"konamisystem573/#other-registers","title":"Other registers","text":"These registers are implemented almost entirely using 74-series logic and the XC9536 CPLD on the main board.
"},{"location":"konamisystem573/#0x1f500000-bank-switch-security-cartridge","title":"0x1f500000: Bank switch / Security cartridge","text":"Bits RW Description 0-5 W Bank number (0-47, see below) 6 W SDA direction on security cartridge (0 = input/high-z) 7 Unknown (goes into CPLD) 8-15 Unused Bit 6 controls whether SDA on the security cartridge is an input or an output. If set, SDA will output the same logic level as D0, otherwise the pin will be floating. Bits 0-5 are used to switch the device mapped to the 4 MB 0x1f000000-0x1f3fffff region:
31M, 27M) 1 Internal flash 2 (chips 31L, 27L) 2 Internal flash 3 (chips 31J, 27J) 3 Internal flash 4 (chips 31H, 27H) 4-15 Unused 16-31 PCMCIA card slot 1 32-47 PCMCIA card slot 2 48-63 Unused"},{"location":"konamisystem573/#0x1f520000-jvsirdy-clear","title":"0x1f520000: JVSIRDY clear","text":"Bits RW Description 0-15 Unused This register is a dummy write-only port that clears the JVSIRDY flag when any value is written to it. The flag is set by the JVS MCU whenever a new data word is available for reading from 0x1f40000a.
0x1f560000: IDE reset control","text":"Bits RW Description 0 W Reset pin output (0 = pull reset low) 1-15 Unused Since the IDE reset pin is active-low, a reset is performed by writing 0 to this register, then waiting a few milliseconds and writing 1 again. Note that the IDE specification also defines a way to \"soft-reset\" devices (e.g. to abort execution of a command) using the SRST bit in the device control register.
0x1f5c0000: Watchdog clear","text":"Bits RW Description 0-15 Unused This register is a dummy write-only port that clears the watchdog timer embedded in the Konami 058232 power-on reset and coin counter driver chip when any value is written to it. The BIOS and games write to this port roughly once per frame.
If the watchdog is not cleared at least every 350-400 ms, it will pull the system's reset line low for about 50 ms in order to force a reboot. The watchdog can be disabled without affecting power-on reset by placing a jumper on S86 (see the pinouts section).
0x1f600000: External outputs","text":"Bits RW Description 0-7 W To OUT0-OUT7 on EXT-OUT connector 8-15 Unused The lower 8 bits written to this register are latched on pins OUT0-OUT7 of the external output connector (see the pinouts section). This connector is used by some games to control cabinet lights without using an I/O board.
0x1f680000: Data to JVS MCU","text":"Bits RW Description 0-15 W Data word to MCU In order to prevent overruns, this register shall only be accessed when JVSDRDY is cleared. Writing to it will set JVSDRDY.
0x1f6a0000: Security cartridge outputs","text":"Bits RW Description 0-7 W To D0-D7 on security cartridge 8-15 Unused The lower 8 bits written to this register are latched on pins D0-D7 of the cartridge slot. See the security cartridge section for an explanation of what each pin is wired to. Bit 0 additionally controls the SDA pin when configured as an output through the bank switch register. Writing to this register will set the DRDY flag, which can then be cleared by the cartridge.
Some games may rely on reads from this register returning the last value written to it. This behavior is unconfirmed.
"},{"location":"konamisystem573/#jvs-interface","title":"JVS interface","text":"The System 573 is equipped with a JVS host interface, allowing for connection of I/O modules, controllers and other devices that implement the JVS protocol commonly used in arcade cabinets.
JVS uses a single RS-485 bus running at 115200 bits per second, shared by all devices. The standard JVS connector is a single USB-A port, with the data lines used as the RS-485 differential pair and the VBUS pin as a sensing line (see the JVS specification for details). JVS devices typically have a full size USB-B port for connection to the host, plus optionally another USB-A port for daisy chaining additional devices. The RS-485 bus needs to be terminated; some boards will automatically insert a termination resistor when connected as the last node in a daisy chain.
A JVS packet can be up to 258 bytes long and is made up of the following fields:
Byte Description 0 Synchronization byte, must be0xe0 1 Destination address 2 Length (number of payload bytes including checksum) 3- Payload Checksum (sum of address, length and payload bytes modulo 256) NOTE: when a JVS packet is sent over the RS-485 bus, any 0xd0 or 0xe0 byte other than the synchronization byte must be escaped as 0xd0 0xcf or 0xd0 0xdf respectively, in order to allow downstream devices to reliably determine the end of a packet. On the 573, the JVS MCU handles escaping outbound packets and unescaping inbound packets automatically. The escaping process does not update the length field to reflect the escaped length of the packet.
Refer to the JVS specification for details on the contents of standard and vendor-specific payloads.
"},{"location":"konamisystem573/#mcu-communication-protocol","title":"MCU communication protocol","text":"The system's JVS interface is managed by a dedicated H8/3644 microcontroller, interfaced through two 16-bit latches and handshaking lines (in a similar way to the 8-bit ports on the security cartridge slot). The MCU's firmware is stored in OTP ROM and consists of a simple loop that buffers the data written by the 573, sends it, waits for a response to be received and lets the 573 read it.
In order to perform a JVS transaction the 573 must:
0x1f400000, clear JVSIRDY by writing to 0x1f520000 then wait for the status and error codes in register 0x1f400004 to be set to 0 and 3 respectively.0x1f680000, waiting for JVSDRDY to go low before each write. Words are little endian, so for instance the first word of a packet with destination address 0x01 would be 0x01e0. If the total length of the packet is odd, the last byte shall still be written as a word (with the upper byte zeroed out).0x1f40000a, waiting for JVSIRDY to go high before each read and clearing it by writing to 0x1f520000 after each read. The status code will be set to 2 after the first word is read and back to 0 once no more data is available to read.The MCU does not allow for non-JVS packets to be sent as it validates the sync byte, checksum and uses the length field to determine packet length. Responses cannot be received without sending a packet first either. The MCU will also insert a 200 us minimum delay between the last byte of a received packet and the first byte of the next packet.
"},{"location":"konamisystem573/#io-boards","title":"I/O boards","text":"The System 573 was designed to be expanded with game-specific hardware using I/O expansion boards mounted on top of the main board, and/or custom security cartridges. I/O boards have access to the 16-bit system bus and are accessible through the 0x1f640000-0x1f6400ff region.
GX700-PWB(F))GX894-PWB(B)A)GX700-PWB(K))GE765-PWB(B)A)GX921-PWB(B))PWB0000073070)GX700-PWB(F))","text":"Used in early Bemani games such as DDR 1stMIX and 2ndMIX, as well as some non-Bemani games. The name is misleading as the board does not deal with any analog signals whatsoever; the name was given retroactively to distinguish it from the digital I/O board. It provides up to 28 optoisolated open-drain outputs typically used to control cabinet lights, split across 4 banks:
CN33): 8 outputs (A0-A7)CN34): 8 outputs (B0-B7)CN35): 8 outputs (C0-C7)CN36): 4 outputs (D0-D3)Some games shipped with partially populated analog I/O boards, thus not all banks may be available. See the game-specific information section for details on how lights are wired up on each cabinet type.
"},{"location":"konamisystem573/#0x1f640080-bank-a","title":"0x1f640080: Bank A","text":"Bits RW Description 0 W Output A1 (0 = grounded) 1 W Output A3 (0 = grounded) 2 W Output A5 (0 = grounded) 3 W Output A7 (0 = grounded) 4 W Output A6 (0 = grounded) 5 W Output A4 (0 = grounded) 6 W Output A2 (0 = grounded) 7 W Output A0 (0 = grounded) 8-15 Unused"},{"location":"konamisystem573/#0x1f640088-bank-b","title":"0x1f640088: Bank B","text":"Bits RW Description 0 W Output B1 (0 = grounded) 1 W Output B3 (0 = grounded) 2 W Output B5 (0 = grounded) 3 W Output B7 (0 = grounded) 4 W Output B6 (0 = grounded) 5 W Output B4 (0 = grounded) 6 W Output B2 (0 = grounded) 7 W Output B0 (0 = grounded) 8-15 Unused"},{"location":"konamisystem573/#0x1f640090-bank-c","title":"0x1f640090: Bank C","text":"Bits RW Description 0 W Output C1 (0 = grounded) 1 W Output C3 (0 = grounded) 2 W Output C5 (0 = grounded) 3 W Output C7 (0 = grounded) 4 W Output C6 (0 = grounded) 5 W Output C4 (0 = grounded) 6 W Output C2 (0 = grounded) 7 W Output C0 (0 = grounded) 8-15 Unused"},{"location":"konamisystem573/#0x1f640098-bank-d","title":"0x1f640098: Bank D","text":"Bits RW Description 0 W Output D3 (0 = grounded) 1 W Output D2 (0 = grounded) 2 W Output D1 (0 = grounded) 3 W Output D0 (0 = grounded) 4-15 Unused"},{"location":"konamisystem573/#digital-io-board-gx894-pwbba","title":"Digital I/O board (GX894-PWB(B)A)","text":"Used by later Bemani games, such as DDR from Solo onwards. This board features the same 28 isolated open-drain outputs as the analog I/O board, plus a Xilinx XCS40XL Spartan-XL FPGA and a Micronas MAS3507D audio decoder ASIC used to play encrypted MP3 files. The FPGA has 24 MB of dedicated DRAM into which the files are preloaded on startup, then decrypted on the fly and fed to the decoder. The board also features 128 KB of SRAM used as a cache, RS-232 and ARCnet transceivers for communication with other hardware and a DS2401 serial number chip, used to prevent usage of the same security cartridge on more than one 573.
The vast majority of the registers provided by this board (including some but not all light outputs) are handled by its FPGA, which requires a configuration bitstream to be uploaded to it in order to work. Registers in the 0x1f6400f0-0x1f6400ff region are handled by a CPLD and are functional even if no bitstream is loaded. There are several known versions of Konami's bitstream:
32d455a25eb26fe4e4b577cb0f0e3bebd0f82959 Dance Dance Revolution Solo Bass Mix a53b8906de95c34b6e3f053bd7488c888bc904b6 Dance Dance Revolution 3rdMIX 450b12627b7eacd3ea3f8b0b7a16589a13010c41 Mambo a Go-Go 53d0c1e3f6ae042d7d45ce889b79a12f1be5eabd Martial Beat e-Amusement d1d0f123bbb9d5abfefbd556c366f9ded0779e41 Martial Beat (leftover file 1, unused) f354619fe1a80cabe0b774784181b3bfeff0a3e9 Martial Beat (leftover file 2, unused) The DDR and Mambo bitstreams all implement the same registers (listed below) and seem to only differ in the MP3 decryption algorithm, while the unused Martial Beat bitstreams seem to behave in a completely different way. Homebrew tools may also load custom bitstreams, which can be developed using the Xilinx ISE toolchain. See the pinouts section for a list of all devices connected to the FPGA.
"},{"location":"konamisystem573/#0x1f640080-fpga-ddrmambo-bitstream-magic-number","title":"0x1f640080 (FPGA, DDR/Mambo bitstream): Magic number","text":"Bits RW Description 0-15 R Magic number (0x1234) This register is checked by Konami's digital I/O board driver to make sure the bitstream was properly loaded into the FPGA.
"},{"location":"konamisystem573/#0x1f640090-fpga-ddrmambo-bitstream-network-board-address","title":"0x1f640090 (FPGA, DDR/Mambo bitstream): Network board address","text":""},{"location":"konamisystem573/#0x1f640092-fpga-ddrmambo-bitstream-unknown-network-related","title":"0x1f640092 (FPGA, DDR/Mambo bitstream): Unknown (network related)","text":""},{"location":"konamisystem573/#0x1f6400a0-fpga-ddrmambo-bitstream-mp3-data-start-address-high","title":"0x1f6400a0 (FPGA, DDR/Mambo bitstream): MP3 data start address high","text":""},{"location":"konamisystem573/#0x1f6400a2-fpga-ddrmambo-bitstream-mp3-data-start-address-low","title":"0x1f6400a2 (FPGA, DDR/Mambo bitstream): MP3 data start address low","text":""},{"location":"konamisystem573/#0x1f6400a4-fpga-ddrmambo-bitstream-mp3-data-end-address-high","title":"0x1f6400a4 (FPGA, DDR/Mambo bitstream): MP3 data end address high","text":""},{"location":"konamisystem573/#0x1f6400a6-fpga-ddrmambo-bitstream-mp3-data-end-address-low","title":"0x1f6400a6 (FPGA, DDR/Mambo bitstream): MP3 data end address low","text":""},{"location":"konamisystem573/#0x1f6400a8-fpga-ddrmambo-bitstream-mp3-frame-counter-decryption-key-1","title":"0x1f6400a8 (FPGA, DDR/Mambo bitstream): MP3 frame counter / Decryption key 1","text":""},{"location":"konamisystem573/#0x1f6400aa-fpga-ddrmambo-bitstream-mp3-playback-status","title":"0x1f6400aa (FPGA, DDR/Mambo bitstream): MP3 playback status","text":""},{"location":"konamisystem573/#0x1f6400ac-fpga-ddrmambo-bitstream-mas3507d-i2c","title":"0x1f6400ac (FPGA, DDR/Mambo bitstream): MAS3507D I2C","text":""},{"location":"konamisystem573/#0x1f6400ae-fpga-ddrmambo-bitstream-mp3-data-feeder-control","title":"0x1f6400ae (FPGA, DDR/Mambo bitstream): MP3 data feeder control","text":""},{"location":"konamisystem573/#0x1f6400b0-fpga-ddrmambo-bitstream-ram-write-address-high","title":"0x1f6400b0 (FPGA, DDR/Mambo bitstream): RAM write address high","text":""},{"location":"konamisystem573/#0x1f6400b2-fpga-ddrmambo-bitstream-ram-write-address-low","title":"0x1f6400b2 (FPGA, DDR/Mambo bitstream): RAM write address low","text":""},{"location":"konamisystem573/#0x1f6400b4-fpga-ddrmambo-bitstream-ram-data","title":"0x1f6400b4 (FPGA, DDR/Mambo bitstream): RAM data","text":""},{"location":"konamisystem573/#0x1f6400b6-fpga-ddrmambo-bitstream-ram-read-address-high","title":"0x1f6400b6 (FPGA, DDR/Mambo bitstream): RAM read address high","text":""},{"location":"konamisystem573/#0x1f6400b8-fpga-ddrmambo-bitstream-ram-read-address-low","title":"0x1f6400b8 (FPGA, DDR/Mambo bitstream): RAM read address low","text":""},{"location":"konamisystem573/#0x1f6400c0-fpga-ddrmambo-bitstream-network-data","title":"0x1f6400c0 (FPGA, DDR/Mambo bitstream): Network data","text":""},{"location":"konamisystem573/#0x1f6400c2-fpga-ddrmambo-bitstream-network-output-buffer-size","title":"0x1f6400c2 (FPGA, DDR/Mambo bitstream): Network output buffer size","text":""},{"location":"konamisystem573/#0x1f6400c4-fpga-ddrmambo-bitstream-network-input-buffer-size","title":"0x1f6400c4 (FPGA, DDR/Mambo bitstream): Network input buffer size","text":""},{"location":"konamisystem573/#0x1f6400c8-fpga-ddrmambo-bitstream-unknown-network-related","title":"0x1f6400c8 (FPGA, DDR/Mambo bitstream): Unknown (network related)","text":""},{"location":"konamisystem573/#0x1f6400ca-fpga-ddrmambo-bitstream-dac-sample-counter-high","title":"0x1f6400ca (FPGA, DDR/Mambo bitstream): DAC sample counter high","text":""},{"location":"konamisystem573/#0x1f6400cc-fpga-ddrmambo-bitstream-dac-sample-counter-low","title":"0x1f6400cc (FPGA, DDR/Mambo bitstream): DAC sample counter low","text":""},{"location":"konamisystem573/#0x1f6400ce-fpga-ddrmambo-bitstream-dac-sample-counter-delta","title":"0x1f6400ce (FPGA, DDR/Mambo bitstream): DAC sample counter delta","text":""},{"location":"konamisystem573/#0x1f6400e0-fpga-ddrmambo-bitstream-bank-a","title":"0x1f6400e0 (FPGA, DDR/Mambo bitstream): Bank A","text":"Bits RW Description 0-11 Unused 12 W Output A4 (0 = grounded) 13 W Output A5 (0 = grounded) 14 W Output A6 (0 = grounded) 15 W Output A7 (0 = grounded)"},{"location":"konamisystem573/#0x1f6400e2-fpga-ddrmambo-bitstream-bank-a","title":"0x1f6400e2 (FPGA, DDR/Mambo bitstream): Bank A","text":"Bits RW Description 0-11 Unused 12 W Output A0 (0 = grounded) 13 W Output A1 (0 = grounded) 14 W Output A2 (0 = grounded) 15 W Output A3 (0 = grounded)"},{"location":"konamisystem573/#0x1f6400e4-fpga-ddrmambo-bitstream-bank-b","title":"0x1f6400e4 (FPGA, DDR/Mambo bitstream): Bank B","text":"Bits RW Description 0-11 Unused 12 W Output B4 (0 = grounded) 13 W Output B5 (0 = grounded) 14 W Output B6 (0 = grounded) 15 W Output B7 (0 = grounded)"},{"location":"konamisystem573/#0x1f6400e6-fpga-ddrmambo-bitstream-bank-d","title":"0x1f6400e6 (FPGA, DDR/Mambo bitstream): Bank D","text":"Bits RW Description 0-11 Unused 12 W Output D0 (0 = grounded) 13 W Output D1 (0 = grounded) 14 W Output D2 (0 = grounded) 15 W Output D3 (0 = grounded)"},{"location":"konamisystem573/#0x1f6400e8-fpga-ddrmambo-bitstream-initializationreset-related","title":"0x1f6400e8 (FPGA, DDR/Mambo bitstream): Initialization/reset related","text":"Bits RW Description 0-11 Unused 12 W Unknown (0 = reset?) 13 W Unknown (0 = reset?) 14 W Unknown (0 = reset?) 15 W Unknown (0 = reset?) Konami's code writes 0xf000, followed by 0x0000, a delay and 0xf000 again, to this register after uploading the bitstream.
0x1f6400ea (FPGA, DDR/Mambo bitstream): Decryption key 2","text":""},{"location":"konamisystem573/#0x1f6400ec-fpga-ddrmambo-bitstream-decryption-key-3","title":"0x1f6400ec (FPGA, DDR/Mambo bitstream): Decryption key 3","text":""},{"location":"konamisystem573/#0x1f6400ee-fpga-ddrmambo-bitstream-1-wire-bus","title":"0x1f6400ee (FPGA, DDR/Mambo bitstream): 1-wire bus","text":"When read:
Bits RW Description 0-11 Unused 12 R DS2401 1-wire bus readout 13-15 Unused? (see note)When written:
Bits RW Description 0-11 Unused 12 W Drive DS2401 1-wire bus low (1 = pull low, 0 = release) 13-15 Unused? (see note)In addition to the DS2401 the board has an unpopulated footprint for a DS2433 1-wire EEPROM, connected to a separate FPGA pin. Bit 13, 14 or 15 may actually be mapped to the unused DS2433 bus.
"},{"location":"konamisystem573/#0x1f6400f0-cpld-unknown-unused","title":"0x1f6400f0 (CPLD): Unknown (unused?)","text":"Konami's code does not write to this CPLD register.
"},{"location":"konamisystem573/#0x1f6400f2-cpld-unknown-unused","title":"0x1f6400f2 (CPLD): Unknown (unused?)","text":"Konami's code does not write to this CPLD register.
"},{"location":"konamisystem573/#0x1f6400f4-cpld-unknown-reset","title":"0x1f6400f4 (CPLD): Unknown (reset?)","text":"Bits RW Description 0-14 Unused 15 W Unknown (0 = reset?) Probably controls the MAS3507D or DAC's reset pin. Bit 15 is cleared before uploading the bitstream and set again once the FPGA is initialized.
"},{"location":"konamisystem573/#0x1f6400f6-cpld-fpga-status-and-control","title":"0x1f6400f6 (CPLD): FPGA status and control","text":"When read:
Bits RW Description 0-11 Unused 12 R Possibly/INIT from FPGA 13 R Possibly DONE from FPGA 14 R Board identification? (always 1) 15 R Board identification? (always 0) NOTE: all registers in the 0x1f6400f0-0x1f6400ff region seem to return the same value as this register when read, possibly due to incomplete address decoding in the CPLD. Konami's driver only ever reads from this register and treats all other CPLD registers as write-only.
When written:
Bits RW Description 0-11 Unused 12 W Possibly/INIT to FPGA 13 W Possibly DONE to FPGA 14 W Possibly /PROGRAM to FPGA 15 W Unused? (always 1) This register is only written to 3 times when resetting the FPGA prior to loading the bitstream. The values written are 0x8000 first, then 0xc000 and finally 0xf000.
0x1f6400f8 (CPLD): FPGA bitstream upload","text":"Bits RW Description 0-14 Unused 15 W Bit to send to the FPGA Bits written to this register are sent to the FPGA's configuration interface (DIN and CCLK pins, see the XCS40XL datasheet). There is no separate bit to control the CCLK pin as clocking is handled automatically. The FPGA is wired to boot in \"slave serial\" mode and wait for a bitstream to be loaded by the 573 through this port.
All known games load the bitstream from an array embedded in the executable or a file on the internal flash (usually named data/fpga/fpga_mp3.bin), then write its contents to this port LSB first and monitor the FPGA status register. The bitstream is always 330696 bits (41337 bytes) long as per the XCS40XL datasheet.
0x1f6400fa (CPLD): Bank C","text":"Bits RW Description 0-11 Unused 12 W Output C0 (0 = grounded) 13 W Output C1 (0 = grounded) 14 W Output C2 (0 = grounded) 15 W Output C3 (0 = grounded)"},{"location":"konamisystem573/#0x1f6400fc-cpld-bank-c","title":"0x1f6400fc (CPLD): Bank C","text":"Bits RW Description 0-11 Unused 12 W Output C4 (0 = grounded) 13 W Output C5 (0 = grounded) 14 W Output C6 (0 = grounded) 15 W Output C7 (0 = grounded)"},{"location":"konamisystem573/#0x1f6400fe-cpld-bank-b","title":"0x1f6400fe (CPLD): Bank B","text":"Bits RW Description 0-11 Unused 12 W Output B0 (0 = grounded) 13 W Output B1 (0 = grounded) 14 W Output B2 (0 = grounded) 15 W Output B3 (0 = grounded)"},{"location":"konamisystem573/#alternate-analog-io-board-gx700-pwbk","title":"Alternate analog I/O board (GX700-PWB(K))","text":"Used by Kick & Kick. Has several optocouplers, plus a DS2401 serial number chip and several unpopulated footprints.
This board is currently undocumented.
"},{"location":"konamisystem573/#fishing-controller-io-board-ge765-pwbba","title":"Fishing controller I/O board (GE765-PWB(B)A)","text":"Used by the Fisherman's Bait series. Uses an NEC uPD4701 mouse/trackball chip to track motion of the fishing reel's rotary encoders and contains PWM drivers for the feedback motors. Along with the analog I/O board, it is the only known board that does not have a DS2401.
This board is currently undocumented.
"},{"location":"konamisystem573/#ddr-karaoke-mix-io-board-gx921-pwbb","title":"DDR Karaoke Mix I/O board (GX921-PWB(B))","text":"Used by DDR Karaoke Mix 1 and 2. Similarly to the digital I/O board, this board features several optoisolated light outputs, an ARCnet PHY and a DS2401 serial number chip. It also has composite video inputs and outputs, a video encoder to convert the 573's native RGB output to composite and additional circuitry to superimpose it onto the video feed from an external karaoke machine. An onboard PC16552 UART is provided to communicate with the machine (the security cartridge also exposes SIO1).
This board is currently undocumented.
"},{"location":"konamisystem573/#gunmania-io-board-pwb0000073070","title":"GunMania I/O board (PWB0000073070)","text":"Used by GunMania and GunMania Zone Plus. Contains an RGB to S-video converter which drives the cabinet's projector, several motor drivers, optoisolators, a PC16552 UART and a DS2401 serial number chip. A DB25 connector on the side of the board is used to interface to the resistive matrix used to detect bullet shots.
This board is currently undocumented.
"},{"location":"konamisystem573/#hypothetical-debugging-board","title":"Hypothetical debugging board","text":"There is no proof whatsoever of this board having ever existed, but the BIOS and some games attempt to access the hardware on it. It seems to contain at least a Fujitsu MB89371 UART and a 7-segment display, although these may have actually been on two separate boards (or built into a prototype board used by Konami during development).
The MB89371 does not have a publicly available datasheet.
"},{"location":"konamisystem573/#0x1f640000-uart-data","title":"0x1f640000: UART data","text":""},{"location":"konamisystem573/#0x1f640002-uart-control","title":"0x1f640002: UART control","text":""},{"location":"konamisystem573/#0x1f640004-uart-baud-rate-select","title":"0x1f640004: UART baud rate select","text":""},{"location":"konamisystem573/#0x1f640006-uart-mode","title":"0x1f640006: UART mode","text":""},{"location":"konamisystem573/#0x1f640010-7-segment-display","title":"0x1f640010: 7-segment display","text":"Bits RW Description 0 W Right digit segment G (0 = on) 1 W Right digit segment F (0 = on) 2 W Right digit segment E (0 = on) 3 W Right digit segment D (0 = on) 4 W Right digit segment C (0 = on) 5 W Right digit segment B (0 = on) 6 W Right digit segment A (0 = on) 7 Unused 8 W Left digit segment G (0 = on) 9 W Left digit segment F (0 = on) 10 W Left digit segment E (0 = on) 11 W Left digit segment D (0 = on) 12 W Left digit segment C (0 = on) 13 W Left digit segment B (0 = on) 14 W Left digit segment A (0 = on) 15 Unused The BIOS shell shows \"00\" on this display (but contains a function to show any hexadecimal value). Kick & Kick shows an animated spinner, some other games show error or status codes on it. This may have been meant to be a POST display integrated into the 573 main board at some point.
"},{"location":"konamisystem573/#security-cartridges","title":"Security cartridges","text":"Most System 573 games use cartridges that plug into the slot on the right side of the main board as an anti-piracy measure and/or to add game specific I/O functionality (particularly for games that do not otherwise require any I/O board). Cartridges typically contain a password protected EEPROM, used to store game and installation information, and in some cases a DS2401 unique serial number chip.
All communication with the cartridge is performed through the following means:
I0-I7), readable via register 0x1f400004;D0-D7), controlled by register 0x1f6a0000;SDA), which can be either configured as a floating input or set to output the same logic level as D0 through register 0x1f500000;TX, RX, /RTS, /CTS, /DTR, /DSR);IRDY, DRDY, /IREQ, /DACK).As all EEPROMs used in cartridges have an I2C interface rather than a parallel one, SDA is used in combination with individual bits of the parallel I/O ports to bitbang I2C. The SIO1 interface either goes unused or is translated to RS-232 voltage levels and broken out to a connector on the cartridge.
See the pinouts section for more information on the security cartridge slot.
"},{"location":"konamisystem573/#handshaking-lines","title":"Handshaking lines","text":"The cartridge slot carries two status lines unofficially known as IRDY and DRDY plus two inputs named /IREQ and /DACK, probably meant for synchronization with cartridges that would actually use D0-D7 and I0-I7 as a parallel data bus rather than to bitbang serial protocols. No currently known cartridge uses these pins.
DRDY is set whenever the 573 writes to the output port, even if no bits have actually changed. The cartridge can monitor this signal to know when to read a byte from the port and then pull /DACK low to reset it. To send a byte to the 573 the cartridge can pulse /IREQ, which will cause IRDY to go high until the 573 accesses the input port. The 573 can read the status of IRDY (as well as DRDY) through the Konami ASIC and wait for it to be set before reading the next byte.
The cartridge I/O ports can basically be thought of as a single-byte FIFO, with DRDY being the \"TX buffer full\" flag and IRDY the \"RX buffer not empty\" flag. The handshaking lines are implemented using a handful of 74LS74 flip flops.
NOTE: the JVS MCU also has its own handshaking lines, JVSIRDY and JVSDRDY, which are actually used and work in pretty much the same way. See the JVS interface section for more information on communicating with the MCU.
The PS1 CPU's SIO1 UART has hardware flow control and will not transmit data until CTS is asserted. In order to get around this most cartridges tie CTS to RTS, allowing it to be controlled in software. Cartridges that use the serial port (i.e. ones with a network port) have the pins tied together on the PCB, while other cartridge types usually break them out to a shorted 2-pin jumper.
Some earlier games that do not use SIO1 for networking purposes redirect their debug logging output to it (by calling the AddSIO() function provided by the Sony SDK) if CTS and RTS are shorted on startup. On later 573 motherboard revisions, the SIO1 pins are additionally broken out to a separate connector (CN24) and made accessible even when a cartridge without a network port is inserted.
Konami's security cartridge driver supports the following EEPROMs:
Manufacturer Chip \"Response to reset\" ID Capacity Xicor X76F04119 55 aa 55 (LSB first) 512 bytes Xicor X76F100 19 00 aa 55 (LSB first) 112 bytes Konami/Microchip ZS01 (PIC16CE625) 5a 53 00 01 (MSB first) 112 bytes NOTE: Konami seems to have never manufactured X76F100 cartridges, however most games that expect an X76F041 can also use the X76F100 interchangeably. ZS01 support was only added in later versions of the driver.
"},{"location":"konamisystem573/#zs01-protocol","title":"ZS01 protocol","text":"The \"ZS01\" EEPROM is actually a PIC16 microcontroller that mostly replicates the X76F100's functionality, allowing the 573 to store up to 112 bytes of data protected by a 64-bit password. Unlike the X76F041 and X76F100, which use plaintext commands, all communication with the ZS01 is obfuscated using a rudimentary scrambling algorithm. A CRC16 is attached to each packet and used to detect attempts to tamper with the obfuscation. Attempting to send too many requests with an invalid CRC16 will cause the ZS01 to self-erase and reset the password.
A ZS01 transaction can be broken down into the following steps:
The 573 prepares a 12-byte packet to be sent to the ZS01, containing a command, address and payload:
Bytes Description 0 Command flags 1 Address bits 0-7 2-9 Payload (data for writes, response key for reads) 10-11 CRC16 of bytes 0-9, big endianThe first byte is a 3-bit bitfield encoding the command and access type:
Bits Description 0 Command (0 = write/erase, 1 = read) 1 Address bit 8 (unused, should be 0) 2 Access type (0 = unprivileged, 1 = privileged) 3-7 Unused? (should be 0)The access type bit specifies whether the command is privileged. Privileged commands require the ZS01's current password, while unprivileged commands do not.
The address must be one of the following values:
Address Length Privileged Description0x00-0x03 32 bytes No Unprivileged data area 0x04-0x0e 80 bytes Yes Privileged data area 0xfc 8 bytes No Internal ZS01 serial number 0xfd 8 bytes No External DS2401 serial number 0xfd 8 bytes Yes Erases data area when written (write-only) 0xfe 8 bytes Yes Configuration registers 0xff 8 bytes Yes New password (write-only) Data is always read or written in aligned 8 byte blocks. Unprivileged areas can be read using either a privileged or unprivileged read command, but writing to them still requires a privileged write command.
If the command is a read command, a random 8-byte \"response key\" is generated (typically as an MD5 hash of the current time from the RTC) and written to the payload field; the ZS01 will later use it to encrypt the returned data as a replay attack prevention measure. For write commands, the payload field is populated with the 8 bytes to be written.
A CRC16 is calculated over the first 10 bytes of the packet and stored in the last 2 bytes in big endian format. The CRC is computed as follows:
#define ZS01_CRC16_POLYNOMIAL 0x1021\n\nuint16_t zs01_crc16(const uint8_t *data, size_t length) {\nuint16_t crc = 0xffff;\n\nfor (; length; length--) {\ncrc ^= *(data++) << 8;\n\nfor (int bit = 8; bit; bit--) {\nuint16_t temp = crc;\n\ncrc <<= 1;\nif (temp & (1 << 15))\ncrc ^= ZS01_CRC16_POLYNOMIAL;\n}\n}\n\nreturn (~crc) & 0xffff;\n}\nIf the command is privileged, the 573 scrambles the payload field with the chip's currently set password, using the following algorithm:
// Note that this state is preserved across calls to zs01_scramble_payload()\n// and must be updated when a response is received (see step 8).\nuint8_t zs01_scrambler_state = 0;\n\nvoid zs01_scramble_payload(\nuint8_t *output, const uint8_t *input, size_t length,\nconst uint8_t *password\n) {\nfor (; length; length--) {\nint value = *(input++) ^ zs01_scrambler_state;\nvalue = (value + password[0]) & 0xff;\n\nfor (int i = 1; i < 8; i++) {\nint add = password[i] & 0x1f;\nint shift = password[i] >> 5;\n\nint shifted = value << shift;\nshifted |= value >> (8 - shift);\nshifted &= 0xff;\n\nvalue = (shifted + add) & 0xff;\n}\n\nzs01_scrambler_state = value;\n*(output++) = value;\n}\n}\nThe CRC16 is not updated to reflect the new data. This step is skipped for unprivileged read commands.
All 12 bytes of the packet are scrambled with a fixed \"command key\", using the following algorithm:
static const uint8_t ZS01_COMMAND_ADD[] = { 237, 8, 16, 11, 6, 4, 8, 30 };\nstatic const uint8_t ZS01_COMMAND_SHIFT[] = { 0, 3, 2, 2, 6, 2, 2, 1 };\n\nvoid zs01_scramble_packet(\nuint8_t *output, const uint8_t *input, size_t length\n) {\n// Unlike zs01_scramble_payload(), this state is *not* preserved across\n// calls.\nuint8_t state = 0xff;\n\noutput += length;\ninput += length;\n\nfor (; length; length--) {\nint value = *(--input) ^ state;\nvalue = (value + ZS01_COMMAND_ADD[0]) & 0xff;\n\nfor (int i = 1; i < 8; i++) {\nint shifted = value << ZS01_COMMAND_SHIFT[i];\nshifted |= value >> (8 - ZS01_COMMAND_SHIFT[i]);\nshifted &= 0xff;\n\nvalue = (shifted + ZS01_COMMAND_ADD[i]) & 0xff;\n}\n\nstate = value;\n*(--output) = value;\n}\n}\nThe scrambled packet is sent to the ZS01, which will respond to the first 11 bytes immediately with an I2C ACK and to the last byte with an ACK after a short delay. The 573 then proceeds to read 12 bytes from the ZS01, issuing an I2C ACK for each byte received up until the last one.
The 573 uses the response key generated in step 2 to unscramble the packet returned by the ZS01. The unscrambling algorithm is the same one used in step 5, applied in reverse:
void zs01_unscramble_packet(\nuint8_t *output, const uint8_t *input, size_t length,\nconst uint8_t *response_key\n) {\nuint8_t state = 0xff;\n\noutput += length;\ninput += length;\n\nfor (; length; length--) {\nint value = *(--input);\nint last_state = state;\nstate = value;\n\nfor (int i = 1; i < 8; i++) {\nint add = response_key[i] & 0x1f;\nint shift = response_key[i] >> 5;\n\nint subtracted = (value - add) & 0xff;\n\nvalue = subtracted >> shift;\nvalue |= subtracted << (8 - shift);\nvalue &= 0xff;\n}\n\nvalue = (value - response_key[0]) & 0xff;\n*(--output) = value ^ last_state;\n}\n}\nFor write commands, the response key required to unscramble the packet is the one sent as part of the last read command issued. For read commands, the ZS01 may either use the key provided in the payload field or the one from the last read command issued; Konami's code tries unscrambling responses with both.
The unscrambled packet will contain the following fields:
Bytes Description 0 Status code (0 = success, 1-5 = error) 1 New payload scrambler state 2-9 Payload (empty for writes, data for reads) 10-11 CRC16 of bytes 0-9, big endianThe 573 proceeds to compute the CRC16 of the first 10 bytes. If it does not match the one in the packet, it will try unscrambling the packet with a different response key (see step 7) before giving up. Otherwise, the global zs01_scrambler_state variable from step 4 is set to the value of byte 1, regardless of whether the status code is zero or not.
The exact meaning of non-zero status codes is currently unknown.
GX700-PWB(E))","text":"This is the only known cartridge type that has no EEPROM (although the PCB does have an unpopulated X76F041 footprint). It has no plastic case, as it's meant to be enclosed in the same case as the 573 itself. It has open-drain outputs for driving up to 12 lights, arranged as 3 banks of 4 outputs each (one bank for each player's buttons), plus an RS-232 transceiver for SIO1. The following pins are used:
Name Dir UsageTX O TX to network port (via RS-232 transceiver) RX I RX from network port (via RS-232 transceiver) /RTS O Shorted to /CTS to enable SIO1 /CTS I Shorted to /RTS to enable SIO1 /DSR I Cartridge insertion detection (grounded) D0 O Updates/latches bank 3 when pulsed D1 O Updates/latches bank 2 when pulsed D3 O Updates/latches bank 1 when pulsed D4 O Data for light output 0 (green button) D5 O Data for light output 1 (blue button) D6 O Data for light output 2 (red button) D7 O Data for light output 3 (start button) ? O DTR to network port (via RS-232 transceiver) ? I DSR from network port (via RS-232 transceiver) This cartridge has three connectors:
CN2 (5-pin): RS-232 port. Note that this port is not electrically isolated and shares its ground with the 573, unlike all other cartridges with an RS-232 connector.CN3 (16-pin): breaks out the light outputs and the incoming 12V supply from CN4.CN4 (4-pin): 12V power input, connected through a short cable to CN17 on the 573 main board.All X76F041 cartridges use the following pins:
Name Dir Usage/DSR I Cartridge insertion detection (grounded) D0 O Drives X76F041 I2C SDA when SDA is set as output D1 O X76F041 I2C SCL D2 O X76F041 chip select (/CS) D3 O X76F041 reset (RST) SDA IO X76F041 I2C SDA readout X76F041 cartridges equipped with a DS2401 additionally use the following pins:
Name Dir UsageD4 O Drives 1-wire bus low when pulled high I6 I DS2401 1-wire bus readout"},{"location":"konamisystem573/#generic-cartridge-gx700-pwbd","title":"Generic cartridge (GX700-PWB(D))","text":"Rectangular cartridge used by the earliest 573 games and as a separate installation key for some later games. Contains only the X76F041 EEPROM and no DS2401, but the PCB has an unpopulated footprint for an unknown 64-pin TQFP part.
"},{"location":"konamisystem573/#generic-cartridge-with-ds2401-gx894-pwbd","title":"Generic cartridge with DS2401 (GX894-PWB(D))","text":"Rectangular cartridge similar to GX700-PWB(D) but equipped with a DS2401. The PCB has two unpopulated SOIC footprints, one of which may possibly be for an X76F100 or another I2C EEPROM.
GX896-PWB(A)A)","text":"Seems to be an older variant of the more common GX883-PWB(D) cartridge, with the same ports but no DS2401. As with the 3-player Bishi Bashi cartridge, it has no case and is instead meant to sit inside the 573's own case.
TX O TX to network port (via RS-232 transceiver) RX I RX from network port (via RS-232 transceiver) /RTS O Shorted to /CTS to enable SIO1 /CTS I Shorted to /RTS to enable SIO1 ? O CTRL0 to control port ? O CTRL1 to control port ? O CTRL2 to control port ? O DTR to network port (via RS-232 transceiver) ? I DSR from network port (via RS-232 transceiver) This cartridge has two connectors:
CN2 (5-pin): electrically isolated RS-232 port. The transceiver is powered by an isolated DC-DC module and all signals going from/to the 573 are optoisolated.CN3 (6-pin): three 5V logic level signals, used in some cabinets to control lights or the speaker amplifier.GX883-PWB(D))","text":"T-shaped cartridge with a DS2401, a \"network\" (RS-232) port and a \"control\" or \"amp box\" port, commonly used by pre-ZS01 Bemani games. Uses the following pins:
Name Dir UsageTX O TX to network port (via RS-232 transceiver) RX I RX from network port (via RS-232 transceiver) /RTS O Shorted to /CTS to enable SIO1 /CTS I Shorted to /RTS to enable SIO1 ? O CTRL0 to control port ? O CTRL1 to control port ? O CTRL2 to control port ? O DTR to network port (via RS-232 transceiver) ? I DSR from network port (via RS-232 transceiver) This cartridge has two connectors:
GX700-PWB(J))","text":"T-shaped cartridge used only by PunchMania/Fighting Mania series. Contains an X76F041, a DS2401 and an ADC0838 used to measure up to 8 analog inputs. The ADC uses the following pins:
Name Dir UsageD0 O Chip select to ADC (/CS), shared with X76F041 SDA D1 O Data clock to ADC (CLK), shared with X76F041 SCL D5 O Data input to ADC (DI) I0 I Data output from ADC (DO) I1 I SAR status from ADC (SARS) This cartridge has two connectors:
CN4 (10-pin): unknown purpose. Seems to be always unpopulated.PWB0000068819)","text":"T-shaped cartridge with open-drain outputs for driving up to 8 lights, arranged as 2 banks of 4 outputs each. Unlike the GX700-PWB(E) 3-player variant, it has an X76F041 (but no DS2401), lacks the RS-232 port and does not seem to be designed to be mounted inside the 573. The latches driving the light outputs use the following pins:
? O Updates/latches bank 1 when pulsed ? O Updates/latches bank 2 when pulsed ? O Data for light output 0 (green button) ? O Data for light output 1 (blue button) ? O Data for light output 2 (red button) ? O Data for light output 3 (start button) This cartridge has two connectors:
CN2 (16-pin): breaks out the light outputs and the incoming 12V supply from CN3.CN3 (4-pin): 12V power input, presumably connected to the power supply externally (i.e. not through the main board).PWB0000088954)","text":"T-shaped cartridge with open-drain outputs for driving up to 8 lights (although only 6 outputs seem to be populated). Contains an X76F041, a DS2401 and two 4094 shift registers, presumably chained. The shift registers use the following pins:
Name Dir UsageD5 O Shift register clock D6 O Shift register reset D7 O Shift register data This cartridge has two connectors:
All ZS01 cartridges use the following pins:
Name Dir Usage/DSR I Cartridge insertion detection (grounded) D0 O Drives ZS01 I2C SDA when SDA is set as output D1 O ZS01 I2C SCL D3 O ZS01 reset SDA IO ZS01 I2C SDA readout All cartridges are fitted with a DS2401, however it is connected to a GPIO pin on the ZS01 rather than being directly exposed to the 573. The ZS01 additionally provides its own unique serial number, which seems to be unused by games.
"},{"location":"konamisystem573/#serial-port-cartridge-ge949-pwbda","title":"Serial port cartridge (GE949-PWB(D)A)","text":"ZS01 variant of the GX883-PWB(D) cartridge. Uses the following pins:
TX O TX to network port (via RS-232 transceiver) RX I RX from network port (via RS-232 transceiver) /RTS O Shorted to /CTS to enable SIO1 /CTS I Shorted to /RTS to enable SIO1 ? O CTRL0 to control port ? O CTRL1 to control port ? O CTRL2 to control port ? O DTR to network port (via RS-232 transceiver) ? I DSR from network port (via RS-232 transceiver) This cartridge has two connectors:
GE949-PWB(D)B)","text":"T-shaped cartridge that uses the same PCB as GE949-PWB(D)A but only has the ZS01, DS2401 and supporting parts are populated. Used by games that do not need the RS-232 interface.
Most games use the security cartride's EEPROM to store, among other data such as the game code and region, a set of up to four 8-byte identifiers.
"},{"location":"konamisystem573/#sid-siliconserial-id","title":"SID (silicon/serial ID?)","text":"The serial number of the cartridge's DS2401, always present in cartridges that have one. As per the 1-wire specification it has the following format:
Bytes Description 0 1-wire family code (0x01 for DS2401) 1-6 48-bit progressive serial number, little endian 7 CRC8 of bytes 0-6 The CRC is computed as follows:
#define DS2401_CRC8_POLYNOMIAL 0x8c\n\nuint8_t ds2401_crc8(const uint8_t *data, size_t length) {\nuint8_t crc = 0;\n\nfor (; length; length--) {\nuint8_t value = *(data++);\n\nfor (int bit = 8; bit; bit--) {\nuint8_t temp = crc ^ value;\n\nvalue >>= 1;\ncrc >>= 1;\nif (temp & 1)\ncrc ^= DS2401_CRC8_POLYNOMIAL;\n}\n}\n\nreturn crc & 0xff;\n}\nRefer to the DS2401 datasheet and Maxim 1-wire documentation for more details.
"},{"location":"konamisystem573/#tid-trace-id","title":"TID (trace ID)","text":"Seems to be a cartridge-type-agnostic serial number. On cartridges without a DS2401 the trace ID is assigned by Konami at manufacture time (see the master calendar section) and has the following format:
Bytes Description 0 Trace ID type (0x81) 1-2 16-bit \"main\" serial number, big endian 3-6 32-bit \"sub\" serial number, big endian 7 Checksum (sum of bytes 0-6 xor'd with 0xff) On cartridges with a DS2401 the trace ID is instead derived from the SID:
Bytes Description 0 Trace ID type (0x82) 1-2 DS2401 serial number hash, big or little endian depending on game 3-6 Reserved (must be 0) 7 Checksum (sum of bytes 0-6 xor'd with 0xff) The hash is calculated over bytes 1-6 of the SID (excluding the family code and CRC8) using the following algorithm:
// Note that some games set this to 14 instead of 16.\n#define TRACE_ID_HASH_BIT_WIDTH 16\n\nuint16_t trace_id_hash(const uint8_t *data, size_t length) {\nuint16_t hash = 0;\n\nfor (size_t i = 0; i < (length * 8); i += 8) {\nuint8_t value = *(data++);\n\nfor (size_t j = i; j < (i + 8); j++, value >>= 1) {\nif (value & 1)\nhash ^= 1 << (j % TRACE_ID_HASH_BIT_WIDTH);\n}\n}\n\nreturn hash;\n}\nSeems to be some kind of cartridge type flag, possibly indicating whether the cartridge shall be used during or after game installation, or if it was used when performing a game upgrade and shall no longer be usable to run the game it initially shipped with.
Bytes Description 0 Cartridge type? (always0x00, 0x01 or 0x02) 1-6 Reserved (must be 0) 7 Checksum (sum of bytes 0-6 xor'd with 0xff) NOTE: 00 00 00 00 00 00 00 00 seems to be a valid MID value, despite having an otherwise invalid checksum, and to have a different meaning from 00 00 00 00 00 00 00 ff.
The serial number of the digital I/O board's DS2401, written to the cartridge during installation by most games that use it in order to prevent reinstallation on a different system. Has the same format as the SID. On a cartridge that has not yet been paired to a 573 the XID is set to 00 00 00 00 00 00 00 00.
When finishing installation or attempting to use a cartridge with a mismatching XID the game will display the digital I/O board's serial number as an 8-digit value (XXXX-YYYY), generated as follows:
// Some games seem to only use the lower 32 bits of the DS2401's serial number,\n// while others use all 48 bits.\nsize_t xid_to_string_32(char *output, const uint8_t *xid) {\nuint32_t value = 0\n| (xid[1] << 0)\n| (xid[2] << 8)\n| (xid[3] << 16)\n| (xid[4] << 24);\n\nint high = (value / 10000) % 10000;\nint low = value % 10000;\n\nreturn sprintf(output, \"%04d-%04d\", high, low);\n}\n\nsize_t xid_to_string_48(char *output, const uint8_t *xid) {\nuint64_t value = 0\n| (xid[1] << 0)\n| (xid[2] << 8)\n| (xid[3] << 16)\n| (xid[4] << 24)\n| (xid[5] << 32)\n| (xid[6] << 40);\n\nint high = (int) ((value / 10000) % 10000);\nint low = (int) (value % 10000);\n\nreturn sprintf(output, \"%04d-%04d\", high, low);\n}\nCartridges for games that use the digital I/O board typically come with a blank label onto which the 8-digit ID can be written by the operator, to help keep track of which cartridge goes into which system after installation.
Note that games that use other I/O boards with a DS2401, such as Kick & Kick and DDR Karaoke Mix, do not seem to write those boards' serial numbers to the cartridge; they are stored in the internal flash memory instead.
"},{"location":"konamisystem573/#external-modules","title":"External modules","text":"Over the 573's lifetime Konami introduced several add-ons that extended its functionality. Unlike the I/O boards, these were external to the 573 unit and not always mandatory. Not much is currently known about any of these.
"},{"location":"konamisystem573/#relay-board-gn845-pwba","title":"Relay board (GN845-PWB(A))","text":"A relatively simple lamp driver board, controlled by the optoisolated outputs from the analog or digital I/O board. Commonly mounted in a metal box alongside audio amplifier boards in most cabinets.
"},{"location":"konamisystem573/#ddr-stage-io-board-gn845-pwbb","title":"DDR stage I/O board (GN845-PWB(B))","text":"Sits between the 573 and the sensors in each stage's arrow panels in Dance Dance Revolution cabinets. It is based on a Xilinx XC9536 CPLD and allows the 573 to check the status of a specific pressure sensor (each panel has 4 sensors, one along each edge), in addition to ensuring DDR games can only be played with an actual stage rather than just a joystick or buttons wired up to the 573's JAMMA connector. Konami kept using the same board long after the 573 was discontinued, with the last game to use it being DDR X/X2 (PC based).
Each stage's board communicates with the 573 over 6 wires, of which 4 are the up/down/left/right signals going to the JAMMA connector and 2 are light outputs from the I/O board being misused as data and clock lines (see above). The board initially asserts the right and up signals and waits for the 573 to issue an initialization command by bitbanging it over the light outputs. Received bits are acknowledged by the board by echoing them on the right signal and toggling the up signal.
Once initialization is done the board goes into passthrough mode, asserting the up/down/left/right signals whenever any of the respective arrow panels' sensors are pressed. The 573 can issue another command to retrieve the status of each sensor separately, which is then sent by the board in serialized form over the right and up signals. DDR games only use this command to display sensor status in the operator menu, no commands are sent to the board during actual gameplay.
The initialization protocol is currently unknown. The protocol used after initialization is partially known (see links) but needs to be verified and documented properly.
"},{"location":"konamisystem573/#ps1-controller-and-memory-card-adapter-ge885-pwba","title":"PS1 controller and memory card adapter (GE885-PWB(A))","text":"A ridiculously overengineered JVS board providing support for accessing PS1 controllers and memory cards plugged into ports on the front of the cabinet. Contains a Toshiba TMPR3904 CPU, a Xilinx XCS10XL Spartan-XL FPGA, 512 KB of RAM and a 512 KB boot ROM; the ROM is only a small bootloader and the actual firmware is downloaded from the 573 into RAM. There are also two connectors for security dongles. Returns the following JVS identifier string:
KONAMI CO.,LTD.;White I/O;Ver1.0;White I/O PCB\nMemory card support became common in later Bemani games, allowing players to save their scores and play custom charts. GuitarFreaks is the only game known to support external controllers through this board.
"},{"location":"konamisystem573/#punchmania-2-pcmcia-splitter-pwb0000085445","title":"PunchMania 2 PCMCIA splitter (PWB0000085445)","text":"Combines two 32 MB PCMCIA flash cards into the same address space, allowing them to be accessed as if they were a single 64 MB card. Connects to the 573 through a cable that plugs into a passive PCMCIA slot adapter. Only used by PunchMania 2.
"},{"location":"konamisystem573/#e-amusement-network-unit-pwb0000100991","title":"e-Amusement network unit (PWB0000100991)","text":"Used by some Bemani games, in particular later GuitarFreaks and DrumMania releases. Provides networking functionality (DHCP and TCP/UDP sockets) as well as a 10 or 20 GB IDE hard drive for storage of downloaded content. The module contains a Toshiba TMPR3927 CPU, a Xilinx XC2S100 Spartan-2 FPGA, 16 MB of RAM, a 512 KB boot ROM and a DP83815 PCI Ethernet MAC. As with the controller and memory card adapter, the bulk of the firmware seems to be loaded from the 573. Connects through PCMCIA slot 2, using the same cable and adapter as the PunchMania PCMCIA splitter.
"},{"location":"konamisystem573/#multisession-unit-gxa25-pwba","title":"Multisession unit (GXA25-PWB(A))","text":"A fairly large box containing a Toshiba TMPR3927 CPU, a Xilinx XC2S200 Spartan-2 FPGA and four (!) hardware MP3 decoders. It comes with up to four daughterboards installed, each of which hosts a stereo DAC and has RCA jacks for audio input and output plus a mini-DIN connector for RS-232 communication with a cabinet. The box also has its own ATAPI CD-ROM drive and power supply.
Its purpose is to enable \"session mode\" in later Bemani games, which allows for the same song to be played on multiple games at the same time with the box playing the backing tracks and routing audio between the machines. It connects to each cabinet's 573 using RS-232, through the \"network\" port on the security cartridge.
"},{"location":"konamisystem573/#master-calendar","title":"Master calendar","text":"A JVS device used internally by Konami to initialize motherboards and security cartridges during manufacturing. The exact hardware Konami used is unknown, but the protocol can be inferred from game code. All games search the JVS bus on startup and enter a \"factory test\" mode if any device with the following identifier string is present:
KONAMI CO.,LTD.;Master Calendar;<any value>;<any value>\nThe game will then proceed to request the current date, time, game and region information from the master calendar, initialize the RTC and program the security cartridge. The master calendar also returns a unique trace ID (see the cartridge data formats section) for each 573, used for identification purposes on cartridges that lack a DS2401.
"},{"location":"konamisystem573/#0x70-get-date-and-time","title":"0x70: Get date and time","text":""},{"location":"konamisystem573/#0x71-get-game-region-or-initialization-data","title":"0x71: Get game region or initialization data","text":""},{"location":"konamisystem573/#0x7c-0x7f-0x00-get-trace-id-main-serial-number","title":"0x7c, 0x7f, 0x00: Get trace ID \"main\" serial number","text":""},{"location":"konamisystem573/#0x7c-0x80-0x00-get-trace-id-sub-serial-number","title":"0x7c, 0x80, 0x00: Get trace ID \"sub\" serial number","text":""},{"location":"konamisystem573/#0x7d-0x80-0x10-get-next-id","title":"0x7d, 0x80, 0x10: Get next ID","text":""},{"location":"konamisystem573/#0x7e-set-ds2401-identifiers","title":"0x7e: Set DS2401 identifiers","text":""},{"location":"konamisystem573/#0x7f-unknown","title":"0x7f: Unknown","text":""},{"location":"konamisystem573/#0xf0-reset-master-calendar","title":"0xf0: Reset master calendar","text":""},{"location":"konamisystem573/#bios","title":"BIOS","text":"The System 573's BIOS is based on a slightly modified version of Sony's standard PS1 kernel, plus a custom shell executable. The kernel identifies itself as Konami OS by T.H. and seems to have been used across all Konami PS1-based arcade boards. The kernels used by other manufacturers' arcade boards also contain the same T.H. initials, possibly hinting at the fact there was a single Sony employee in charge of providing customized kernels to all arcade system manufacturers.
The only meaningful difference from the PS1 kernel is that most CD-ROM APIs, the ISO9660 driver and the cdrom: device are missing, as the 573 lacks the PS1's CD-ROM hardware. All other functionality, such as controller and memory card drivers, is still present and no new functionality was added (drivers for 573-specific hardware are simply statically linked into the shell and game executables instead).
There seem to be either three or four different versions of the BIOS, all of which share the same kernel but feature different shells:
ROM marking MAME ROM name SHA-1 Used by700A01 700a01.22g e1284add4aaddd5337bd7f4e27614460d52b5b48 Most games 700A01 700a01,gchgchmp.22g 9aab8c637dd2be84d79007e52f108abe92bf29dd Gachagachamp 700A01 Unknown (undumped, see below) 700B01 700b01.22g a2421d0a494892c0e71003c96995ce8f945064dd Dancing Stage EuroMIX 2 700A01 is the earliest and most common version. The only difference between the two known variants of it is that they were linked to slightly different Sony SDK releases; Konami's own code is identical across the two. There reportedly is a third variant that shipped on systems that came with the JVS MCU unpopulated (presumably it would skip the check for it), however no evidence of its existence has ever been found. The shell is stored in ROM in both variants at 0xbfc40000, in the form of a standard PS1 executable (including the header) that gets loaded at 0x803c0000 by the kernel.
700B01 has a more complicated structure: it is split up into two separate executables, one (at 0xbfc28000, loaded at 0x80010000) in charge of running the self-test sequence and the other (at 0xbfc60000, loaded at 0x80380000) handling CD-ROM or flash booting. The overall coding style suggests that it was developed alongside the installers/launchers used by later Bemani games, but dropped as the main feature it would have introduced over the 700A01 shell - CF card support - was broken due to a PCB wiring mistake.
All variants of the shell are far simpler than their PS1 counterparts, as they lack any kind of UI (aside from a non-interactive status screen) and have no copy protection or anti-piracy checks of any kind. Once loaded by the kernel, they start by initializing the system bus and proceed to run a hardware self-test. The outcome of all checks is displayed on screen, with the following ones being performed:
22G: BIOS ROM integrity check. A checksum is calculated and compared to the one stored at the end of the ROM;16H, 16G, 14H, 14G: main RAM read/write test (first row of chips on the board, closest to the CPU);12H, 12G, 9H, 9G: main RAM read/write test (second row of chips on the board, closest to the JAMMA connector);4L, 4P: VRAM read/write test. This causes the 573 to briefly display random pixels as framebuffers are overwritten during the check;10Q: SPU RAM read/write test;18E: JVS MCU reset and status check;CDR: ATAPI CD-ROM drive initialization and executable loading.NOTE: 700A01 shells do not actually test 4P! The GPU starts up in 1 MB VRAM mode by default and the shell does not enable the chip select for the second bank, so the first VRAM chip is tested twice instead. This bug was fixed in the 700B01 shell, which initializes the GPU correctly.
If any check fails the shell locks up, shows a blinking \"HARDWARE ERROR... RESET\" prompt and stops clearing the watchdog after a few seconds, causing the 573 to reboot. Otherwise, the state of DIP switch 4 is checked and the shell attempts to load an executable from four different sources in the following order:
PSX.EXE in the root directory of the disc inserted in the CD-ROM drive. The drive is only initialized after booting from flash or PCMCIA fails or if DIP switch 4 is off, thus the shell will not error out if a drive is not connected but a boot executable is present on the flash. Note that the drive must be set up as an IDE primary/master device using the appropriate jumpers.As with Sony's PS1 shell, the 573 shell's ISO9660 filesystem driver only implements a minimal subset of the specification and may not properly support non-8.3 file names. It also only allocates 2 KB for the disc's path table, so the total number of directories on the disc must be kept to a minimum in order to prevent the shell from crashing. Unlike the PS1, however, the 573 ignores SYSTEM.CNF completely regardless of whether or not it is present on the disc; the shell is hardcoded to always load PSX.EXE. Homebrew discs can take advantage of this behavior to provide separate PS1 and 573 executables instead of detecting the system type at runtime.
If DIP switch 4 is on, the shell expects to find a standard PS1 executable (including the full 2048-byte header) at offset 0x24 on either the built-in flash memory or one of the two PCMCIA flash cards, preceded by a CRC32 checksum of it at offset 0x20. The CRC is stored in little endian format and is not calculated on the whole executable, but rather only on bytes whose offsets are a power of two (i.e. on bytes at 0x24 + 0, 0x24 + 1, 0x24 + 2, 0x24 + 4 and so on). The check is implemented as follows:
#define EXE_CRC32_POLYNOMIAL 0xedb88320 // 0x04c11db7 bit-reversed\n\nuint32_t exe_crc32(const uint8_t *data, size_t length) {\nsize_t offset = 0;\nuint32_t crc = 0xffffffff;\n\nwhile (offset < length) {\ncrc ^= data[offset];\n\nfor (int bit = 8; bit; bit--) {\nuint16_t temp = crc;\n\ncrc >>= 1;\nif (temp & 1)\ncrc ^= EXE_CRC32_POLYNOMIAL;\n\nif (offset)\noffset <<= 1;\nelse\noffset = 1;\n}\n}\n\nreturn ~crc;\n}\n\n#define DIP_SWITCH_PTR ((const uint32_t *) 0x1f400004)\n#define EXE_CRC32_PTR ((const uint32_t *) 0x1f000020)\n#define EXE_HEADER_PTR ((const uint8_t *) 0x1f000024)\n// Offset of the \"text section size\" field within the executable header\n#define EXE_TEXT_SIZE_PTR ((const uint32_t *) 0x1f000040)\n\nbool is_exe_valid(void) {\nif (*DIP_SWITCH_PTR & (1 << 3)) // 1 = DIP switch off\nreturn false;\nif (memcmp(EXE_HEADER_PTR, \"PS-X EXE\", 8))\nreturn false;\n\nsize_t length = 2048 + *EXE_TEXT_SIZE_PTR;\nuint32_t crc = exe_crc32(EXE_HEADER_PTR, length);\n\nreturn (crc == *EXE_DATA_PTR);\n}\nInstalling a new game usually involves inserting the installation disc and turning off DIP switch 4 in order to prevent the shell from booting the game currently installed on the internal flash.
"},{"location":"konamisystem573/#command-line-arguments","title":"Command-line arguments","text":"PS1 executables are generally launched with CPU registers $a0 and $a1 set to zero, in order to make sure programs that interpret them as argc and argv respectively will not crash by trying to parse invalid data. The 700A01 shell follows this convention.
The 700B01 shell, however, does pass two arguments to the executable it loads. $a0 is thus set to 2, while $a1 is set to point to an array containing pointers to the following strings:
boot.rom=700B01boot.from=<device>, where <device> is one of the following:flash.0 (internal flash memory)flash.1 (PCMCIA flash card in slot 1)flash.2 (PCMCIA flash card in slot 2)ata.2 (CF card in slot 2)cdromThe launchers used by later Bemani games use these arguments if present to determine where to load the main game executable from, and fall back to autodetecting the game's installation location otherwise.
"},{"location":"konamisystem573/#jvs-mcu-test-sequence","title":"JVS MCU test sequence","text":"The JVS MCU check is implemented in a different way between the two shell revisions. While the 700A01 shell simply resets the MCU and validates the status and error codes, the 700B01 self-test sequence performs 35 (!) different checks, each validating the codes returned under different conditions. The following tests are done:
JVSIRDY, ensure that:JVSIRDY = 0JVSDRDY = 00x00000x00e0), ensure that:0x001f), ensure that:0x1fe0, 0x0004, 1 << i, checksum), for each packet ensure that:It is currently unclear if any data is actually sent to the JVS bus during step 4, as the shell may reset the MCU it before it starts sending the packet.
"},{"location":"konamisystem573/#dvd-rom-support","title":"DVD-ROM support","text":"Even though neither of the shell versions was explicitly designed with DVD-ROM support in mind, it is possible to run games from a DVD-ROM thanks to the fact that the ATAPI commands used by the shell and games to read sectors from the disc are medium-agnostic. Games that rely on CD-DA playback obviously cannot be put on a DVD, however all other games (including ones that rely on the digital I/O board for MP3 playback) will work as long as the disc is formatted as if it were a typical 573 CD-ROM (ISO9660 with no extensions, no UDF, 8.3 file names and a path table smaller than 2 KB).
NOTE: due to ATAPI incompatibility issues only a very limited number of DVD-ROM drives will actually be recognized and work properly with the shells and games. This is unrelated to the DVD format itself and is purely due to the fact that, unlike CD-ROM drives, most DVD drives were manufactured after the ATAPI specification got updated in a way that broke the 573's compatibility.
This accidental capability was greatly abused by bootleg Bemani \"superdiscs\" that bundled multiple games on a single DVD-ROM and shipped with a modified installation menu, allowing the user to pick which game to install. Each game on a superdisc is patched to load its files from a subdirectory rather than from the DVD's root.
Homebrew 573 software can be distributed as an ISO9660 image larger than 650 MB meant to be burned to a DVD-R, if sacrificing PS1 compatibility and CD-DA support is an option. In such case the image shall be distributed as an .iso file with 2048-byte sectors, rather than the typical .bin and .cue file pair used for PS1 games with 2352-byte Mode 2 sectors.
In addition to booting from \"linear\" memory mapped PCMCIA flash cards, the 700B01 shell features a driver for CF cards and a FAT filesystem parser that allows it to mount a CF card inserted in PCMCIA slot 2 (via a passive CF-to-PCMCIA adapter), search for a flash card image file and interpret its contents as if it were an actual flash card, loading the executable directly from it. Or at least, that would allow it to do so, had Konami not screwed up the wiring of the PCMCIA slots.
CF cards can operate in three different interfacing modes: memory mapped, I/O mapped and IDE compatibility mode. On the 573 only memory mapped mode is accessible as the other modes require usage of I/O chip select pins that are not connected. This mode, however, requires the host to issue 8-bit writes to the card's 16-bit bus through the use of individual chip select lines for each byte (/CE1 and /CE2). While the PS1's CPU does have separate lower (/WR0) and upper (/WR1) byte write strobes that could have been easily adapted to the appropriate signals, Konami decided to cut this specific corner and shorted /CE1 and /CE2 on each PCMCIA slot together, making it impossible to issue a single-byte write.
NOTE: later revisions of the 573 main board seem to have unpopulated jumpers next to the PCMCIA slots that can be used to rewire the chip select signals. It is currently unclear if these jumpers are actually sufficient to enable CF card booting without any additional hardware or BIOS modifications.
"},{"location":"konamisystem573/#bios-mod-boards","title":"BIOS mod boards","text":"It is not uncommon to find 573s fitted with a bootleg BIOS \"mod board\" in place of the stock 700A01 or 700B01 mask ROM. These boards used to be bundled alongside bootleg game CD-ROMs and were apparently required in order to bypass the \"anti-piracy checks\" in Konami's BIOS.
Of course, since neither version of the shell has any such checks, the claims were completely misleading. The actual purpose of these boards was not to tamper with the BIOS, but rather to piggyback on the system bus and provide a crude authentication mechanism to the bootleg game, allowing it to verify that it was indeed running on a 573 equipped with an appropriate mod board. In other words, mod boards were actually the bootleggers' implementation of Konami's security cartridge system, meant to prevent people from simply burning copies of a bootleg CD-ROM and forcing them to buy bootleg kits from whoever produced them instead. Oh the irony.
The added authentication circuitry will not create any issues with official nor homebrew software, however most of these boards feature an additional party trick: the shell executable is altered to load a differently named executable, making bootleg discs unable to boot on a stock 573 and vice versa. The following names have been found so far in modified BIOS ROMs:
QSY.DXDSSW.BXFTSV.AXGGSE.NXXNSE.GXXThe following names have been found on unofficial game discs, but are not confirmed to have ever been used in modified BIOS ROMs:
OSE.FXXQSU.DXHQSX.DXEQSZ.DXCRSU.CXHRSV.CXGRSW.CXFRSZ.CXCSSX.BXESSY.BXDTSW.AXFTSX.AXETSY.AXDTSZ.AXCHomebrew software should thus place multiple copies of the boot executable on the CD-ROM to ensure any BIOS, modded or not, can successfully load it. An interesting side note is that, for any of these names, summing the ASCII codes of each character will always yield the same result. Presumably bootleggers were unable to find the code in charge of BIOS ROM checksum validation and found it easier to just turn the string into random nonsense whose checksum collided with the original one.
"},{"location":"konamisystem573/#game-specific-information","title":"Game-specific information","text":""},{"location":"konamisystem573/#black-case-io-connectors","title":"Black case I/O connectors","text":"Fisherman's Bait and a few other non-Bemani games use a 573 housed in a black case with blue front and back panels. Unlike the gray metal cases used by other games, this case model has no cutouts for removable front and back panels that hold game-specific connectors and instead has a fixed set of ports exposed:
CN17.CN3 on the main board.CN5 on the motherboard.GE765-PWB(B)A fishing controller I/O board. Probably missing on systems that that did not come with Fisherman's Bait.Dance Dance Revolution uses a 573 enclosed in a gray metal case, with either an analog or digital I/O board installed. The front panel has a cutout covered by a metal plate, which in turn holds the following connectors:
The back panel has a similar cutout, covered by a plate with holes for the digital I/O board's RCA networking jacks.
"},{"location":"konamisystem573/#ddr-light-mapping","title":"DDR light mapping","text":"Dance Dance Revolution cabinets (standard 2-player ones, not Solo) have lights wired up to the analog or digital I/O board as follows:
Output Connected to A0 Player 1 up arrow A1 Player 1 down arrow A2 Player 1 left arrow A3 Player 1 right arrow A4 Data to player 1 stage I/O A5 Clock to player 1 stage I/O A6-A7 Unused B0 Player 2 up arrow B1 Player 2 down arrow B2 Player 2 left arrow B3 Player 2 right arrow B4 Data to player 2 stage I/O B5 Clock to player 2 stage I/O B6-B7 Unused C0-C1 Unused C2 Player 1 buttons C3 Player 2 buttons C4 Bottom right marquee light C5 Top right marquee light C6 Bottom left marquee light C7 Top left marquee light D0 Speaker neon D1-D3 UnusedLight outputs A4, A5, B4 and B5 do not actually control any lamps, but are used to communicate with each stage's I/O board. See the external modules section for more details.
"},{"location":"konamisystem573/#ddr-solo-input-and-light-mapping","title":"DDR Solo input and light mapping","text":"Dance Dance Revolution Solo cabinets, unlike 2-player cabinets, do not use a stage I/O board to multiplex the sensors as each arrow panel only has 2 sensors (rather than 4). Each sensor is instead wired directly to the JAMMA connector, making use of most of the available inputs.
JAMMA input Connected to Player 1 left Left sensor A Player 1 right Right sensor A Player 1 up Up sensor A Player 1 down Down sensor A Player 1 button 1 Up-left sensor B Player 1 button 2 Left sensor B Player 1 button 3 Down sensor B Player 1 button 4 Unused Player 1 button 5 Left button Player 1 start Start button Player 2 left Up-left sensor A Player 2 right Up-right sensor A Player 2 up Unused Player 2 down Unused Player 2 button 1 Up sensor B Player 2 button 2 Right sensor B Player 2 button 3 Up-right sensor B Player 2 button 4 Unused Player 2 button 5 Right button Player 2 start Unused (shorted?)The light mapping is currently unknown. Solo cabinets have less lights compared to their 2-player counterparts (e.g. arrow panel lamps are missing).
"},{"location":"konamisystem573/#drummania-light-mapping","title":"DrumMania light mapping","text":"First-generation DrumMania cabinets have lights wired up to the I/O board as follows:
Output Connected to A0-A7 Unused B0-B7 Unused C0 Hi-hat C1 Snare C2 High tom C3 Low tom C4 Cymbal C5 Unused C6 Start button C7 Select button D0 Spotlight D1 Top neon D2 Unused D3 Bottom neonThe wiring was changed in later cabinets, which use the following mapping instead:
Output Connected to A0 Hi-hat A1 Snare A2 High tom A3 Low tom A4-A7 Unused B0 Spotlight B1 Bottom neon B2 Top neon B3 Unused B4 Cymbal B5 Unused B6 Start button B7 Select button C0-C7 Unused D0-D3 Unused"},{"location":"konamisystem573/#notes","title":"Notes","text":""},{"location":"konamisystem573/#homebrew-guidelines","title":"Homebrew guidelines","text":"It is relatively easy to develop homebrew games that can run on both a System 573 and a regular PlayStation 1, or to port existing PS1 homebrew to the 573. Nevertheless, there are some significant differences between the two systems and a game meant to run on both shall avoid using any feature that is only available on one. \"Hybrid\" PS1/573 games shall adhere to the following guidelines:
SYSTEM.CNF while the 573 BIOS ignores it, a disc can have two different executables, one named PSX.EXE (which will be launched on a 573) and the other (which will run on a PS1) referenced by SYSTEM.CNF. This makes it easier to have two separate builds of the game rather than having to detect system type at runtime. Additional copies of PSX.EXE with the file names commonly used by BIOS mod boards (QSY.DXD, TSV.AXG and so on) shall also be present.The 573 only supports 60 Hz mode (i.e. \"NTSC\", even though the video DAC has no composite or S-video output so no color modulation is involved). Attempting to switch the GPU into 50 Hz PAL mode using the GP1(0x08) command will result in a crash, as only the NTSC clock input pin is wired up.
Support for 50 Hz can be added back by shorting pins 192 and 196 on the GPU (which will give \"PAL-on-NTSC\" timings) or by connecting pin 192 to an external oscillator tuned to generate a PAL clock. See the timings section of the GPU page for more details.
"},{"location":"konamisystem573/#flash-chips-and-pcmcia-cards","title":"Flash chips and PCMCIA cards","text":"The PCMCIA flash cards required by most 573 games are \"linear\" (memory mapped) cards consisting of one or more parallel flash memory chips wired directly to the bus, rather than CF or ATA-compatible cards. As neither linear cards nor parallel flash command sets are fully standardized, working with these cards may be difficult without some prior knowledge.
There are two main variants of such cards:
0x9090 to issue the 0x90 JEDEC ID command). Issuing 8-bit writes to a single chip is not supported on the 573 due to the way chip select lines are wired up; see the BIOS CF card support section for more details.Konami's flash driver only supports 8-bit cards that use one of the following chips:
Manufacturer Chip Capacity Manuf. ID Device ID Fujitsu MBM29F016A 2 MB0x04 0xad Fujitsu MBM29F017A 2 MB 0x04 0x3d Fujitsu MBM29F040A 512 KB 0x04 0xa4 Intel 28F016S5 2 MB 0x89 0xaa Sharp LH28F016S 2 MB 0x89 0xaa Most games, including the launchers used by later Bemani games, will check the JEDEC IDs of the cards' chips on startup and reject any unsupported chip, even if valid game data is otherwise present on the card. This makes it impossible to manually install a game onto an unsupported card (e.g. through homebrew tools) without also patching the launcher in order to skip the check.
The 573 main board seems to always be fitted with either MBM29F016A or LH28F016S chips. The internal flash memory is accessed using the same driver as the flash cards and has the same caveats (having to issue commands to two chips at once and so on).
"},{"location":"konamisystem573/#known-working-replacement-pcmcia-cards","title":"Known working replacement PCMCIA cards","text":"This is an incomplete list of PCMCIA flash cards that are known to work, or not to work, with Konami's flash driver. Due to the JEDEC ID checks, only cards that contain flash chips listed in the previous section will work.
Manufacturer Model Flash chips Capacity Bus type Manuf. ID Device ID Working Notes Centennial PM24265, FL32M-20-*-67 16x 28F016S5 32 MB 8-bit0x8989 0xaaaa Yes Centennial PM24276, FL32M-20-*-J5-03 4x 28F640J5 32 MB 16-bit 0x0089 0x0015 No Centennial PM24282, FL32M-20-*-S5-03 16x AM29F016 32 MB 8-bit 0x0101 0xadad No Same command set as Fujitsu cards, may work with minimal game patching Fujitsu \"32MB Flash Card\" (no model number) 16x MBM29F016A 32 MB 8-bit 0x0404 0xadad Yes Stock card (Konami \"FLASH CARD\" sticker covers Fujitsu logo) Fujitsu \"32MB Flash Card\" (no model number) 16x MBM29F017A 32 MB 8-bit 0x0404 0x3d3d Yes Stock card (Konami \"FLASH CARD\" sticker covers Fujitsu logo) Sharp ID245P01 16x LH28F016S 32 MB 8-bit 0x8989 0xaaaa Yes Stock card (Konami \"FLASH CARD\" sticker covers Sharp logo) Note that all Centennial cards have identical labels and can only be told apart from the model number printed on the bottom side.
"},{"location":"konamisystem573/#known-working-replacement-drives","title":"Known working replacement drives","text":"This is an incomplete list of drives that are known to work, or to be incompatible, with the ATAPI driver Konami used in the BIOS shell and games. The driver was likely written using an old version of the ATAPI specification as a reference; CD-ROM drives manufactured in the late 1990s and very early 2000s have a higher chance of being compatible than drives manufactured later, possibly due to changes introduced in later revisions of the ATAPI specification that broke the assumptions Konami's driver makes.
CD-DA playback is particularly problematic as Konami's code seems to be unable to handle the subtle implementation differences across different drives. To add insult to injury, some of the few drives that do work have bugs in their subchannel handling that result in incorrect playback status data being reported to the 573, completely breaking pre-digital-I/O Bemani titles that rely heavily on audio timing.
Manufacturer Model Type BIOS CD-DA Notes ASUSTeK DVD-E616P3 DVD Yes Unknown Compaq CRN-8241B CD Yes Yes Laptop drive, has CD-DA sync issues Creative CD4832E CD Yes No Hitachi CDR-7930 CD Yes No LG GCE-8160B CD Yes No LG GCR-8523B CD Yes Unknown LG GDR-8163B DVD Yes Yes LG GDR-8164B DVD Yes Yes LG GH22LP20 DVD Yes Unknown LG GH22NP20 DVD Yes Unknown LG GSA-4165B DVD No Lite-On LH-18A1H DVD Yes Yes Lite-On LTD-163 DVD Yes Unknown Lite-On LTD-165H DVD Yes Unknown Lite-On LTR-40125S CD Yes Unknown Lite-On SHW-160P6S DVD Yes Unknown Lite-On XJ-HD166S DVD Yes Unknown Matsushita CR-583 CD Yes Yes Stock drive Matsushita CR-587 CD Yes Yes Stock drive, can't read CD-R Matsushita CR-589B CD Yes Yes Stock drive Matsushita SR8589B DVD Yes Unknown Mitsumi CRMC-FX4830T CD Yes Unknown NEC CDR-1900A CD Yes Unknown NEC ND-2510A DVD No Panasonic CR-594C CD Yes Unknown Panasonic UJDA770 CD? Yes Unknown Laptop drive Sony CRX217E CD Yes Unknown Sony DRU-510A DVD Yes Unknown Sony DRU-810A DVD Yes Unknown TDK AI-CDRW241040B CD Yes Unknown TDK AI-481648B CD Yes Unknown TEAC CD-W552E CD Yes Unknown Toshiba TS-H292C CD Yes Unknown Toshiba XM-5702B CD Yes Unknown Toshiba XM-6102B CD Yes No Has issues with homebrew Toshiba XM-7002B CD Yes Unknown Stock drive, laptop driveNOTE: Konami shipped some units with a Toshiba XM-7002B laptop drive and a passive adapter board (GX874-PWB(B)) to break out the drive's signals to a regular 40-pin IDE connector. Laptop drives seem to have been first used by Konami in the GXA25-PWB(A) multisession unit.
The installers and launchers used by Bemani titles that require the digital I/O board have an extensive error and status reporting system. Launcher messages are easily recognizable as they are always displayed in a blue window and have a 3-digit status code, however Japanese versions of the games will show them in Japanese with no way to switch language (short of patching the launcher; all launcher variants contain both English and Japanese strings).
Below is a list of all messages in both English and Japanese, along with the respective status codes and indices in the launcher's internal message array.
Index Type Status codes Description (English) Description (Japanese) 0 Error 100Boot is not available from this device.DEVICE=%s1
\u3053\u306e\u30c7\u30d0\u30a4\u30b9\u304b\u3089\u306e\u30d6\u30fc\u30c8\u306f\u3067\u304d\u307e\u305b\u3093.DEVICE=%s11 Error 101
Digital Sound PCB intialization failed.
\u30c7\u30b8\u30bf\u30eb\u30b5\u30a6\u30f3\u30c9\u57fa\u677f\u306e\u521d\u671f\u5316\u306b\u5931\u6557\u3057\u307e\u3057\u305f.2 Error 102
Digital Sound PCB ROM error.
\u30c7\u30b8\u30bf\u30eb\u30b5\u30a6\u30f3\u30c9\u57fa\u677fROM\u30a8\u30e9\u30fc.4 Error 104
CD-ROM initialization failed.
CD-ROM\u30c9\u30e9\u30a4\u30d6\u306e\u521d\u671f\u5316\u306b\u5931\u6557\u3057\u307e\u3057\u305f.7 Error 107
File system mounting failed.Please check that correct CD-ROM is in use.
\u30d5\u30a1\u30a4\u30eb\u30b7\u30b9\u30c6\u30e0\u306e\u30de\u30a6\u30f3\u30c8\u306b\u5931\u6557\u3057\u307e\u3057\u305f.CD-ROM\u304c\u9593\u9055\u3063\u3066\u3044\u306a\u3044\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.9 Error 109
File system mounting failed.Please check that correct CD-ROM is in use.
\u30d5\u30a1\u30a4\u30eb\u30b7\u30b9\u30c6\u30e0\u306e\u30de\u30a6\u30f3\u30c8\u306b\u5931\u6557\u3057\u307e\u3057\u305f.CD-ROM\u304c\u9593\u9055\u3063\u3066\u3044\u306a\u3044\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.10 Error 110
File system mounting failed.Please check that correct CD-ROM is in use.
\u30d5\u30a1\u30a4\u30eb\u30b7\u30b9\u30c6\u30e0\u306e\u30de\u30a6\u30f3\u30c8\u306b\u5931\u6557\u3057\u307e\u3057\u305f.CD-ROM\u304c\u9593\u9055\u3063\u3066\u3044\u306a\u3044\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.11 Error 111
File system mounting failed.Please check that correct CD-ROM is in use.
\u30d5\u30a1\u30a4\u30eb\u30b7\u30b9\u30c6\u30e0\u306e\u30de\u30a6\u30f3\u30c8\u306b\u5931\u6557\u3057\u307e\u3057\u305f.CD-ROM\u304c\u9593\u9055\u3063\u3066\u3044\u306a\u3044\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.12 Error 112
File system mounting failed.Please check that correct CD-ROM is in use.
\u30d5\u30a1\u30a4\u30eb\u30b7\u30b9\u30c6\u30e0\u306e\u30de\u30a6\u30f3\u30c8\u306b\u5931\u6557\u3057\u307e\u3057\u305f.CD-ROM\u304c\u9593\u9055\u3063\u3066\u3044\u306a\u3044\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.13 Error 113
Disc device initialization failed.
\u30c7\u30a3\u30b9\u30af\u30c7\u30d0\u30a4\u30b9\u306e\u521d\u671f\u5316\u306b\u5931\u6557\u3057\u307e\u3057\u305f.14 Error 114
You are using an incorrect CD-ROM.Replace CD-ROM to %s1 andturn on the main power.
CD-ROM\u304c\u9055\u3044\u307e\u3059.CD-ROM\u3092%s1\u306b\u4ea4\u63db\u3057,\u96fb\u6e90\u3092\u5165\u308c\u76f4\u3057\u3066\u304f\u3060\u3055\u3044.15 Error 115
Disc device initialization failed.
\u30c7\u30a3\u30b9\u30af\u30c7\u30d0\u30a4\u30b9\u306e\u521d\u671f\u5316\u306b\u5931\u6557\u3057\u307e\u3057\u305f.16 Error 116
Disc device initialization failed.
\u30c7\u30a3\u30b9\u30af\u30c7\u30d0\u30a4\u30b9\u306e\u521d\u671f\u5316\u306b\u5931\u6557\u3057\u307e\u3057\u305f.17 Error 117
Config file error.FILE=%s1ERROR=%d2, LINE=%d3, COLUMN=%d4
\u30b3\u30f3\u30d5\u30a3\u30b0\u30d5\u30a1\u30a4\u30eb\u30a8\u30e9\u30fc.FILE=%s1ERROR=%d2, LINE=%d3, COLUMN=%d419 Error 119
You are using an incorrect CD-ROM.Replace CD-ROM to %s1 andturn on the main power.
CD-ROM\u304c\u9055\u3044\u307e\u3059.CD-ROM\u3092%s1\u306b\u4ea4\u63db\u3057,\u96fb\u6e90\u3092\u5165\u308c\u76f4\u3057\u3066\u304f\u3060\u3055\u3044.20 Error 120
Cassette is not installed.Turn off the main power and install thecorrect cassette then turn the power on.
\u30ab\u30bb\u30c3\u30c8\u304c\u30bb\u30c3\u30c8\u3055\u308c\u3066\u3044\u307e\u305b\u3093.\u96fb\u6e90\u3092\u5207\u308a,\u6b63\u3057\u3044\u30ab\u30bb\u30c3\u30c8\u3092\u30bb\u30c3\u30c8\u3057\u3066\u518d\u5ea6\u96fb\u6e90\u3092\u5165\u308c\u3066\u304f\u3060\u3055\u3044.21 Error 121
Cassette error. (%d1)Cassette does not match this game.Check if the cassette is for thisgame (%s2)Refer to manual for more information.
\u30ab\u30bb\u30c3\u30c8\u30a8\u30e9\u30fc (%d1)\u30b2\u30fc\u30e0\u3068\u30ab\u30bb\u30c3\u30c8\u304c\u5bfe\u5fdc\u3057\u3066\u3044\u307e\u305b\u3093.\u30ab\u30bb\u30c3\u30c8\u304c\u3053\u306e\u30b2\u30fc\u30e0(%s2)\u7528\u306e\u3082\u306e\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.\u8a73\u3057\u304f\u306f\u53d6\u308a\u6271\u3044\u8aac\u660e\u66f8\u3092\u53c2\u7167\u3057\u3066\u304f\u3060\u3055\u3044.25 Error 125
Boot is not available from this device.DEVICE=%s1
\u3053\u306e\u30c7\u30d0\u30a4\u30b9\u304b\u3089\u30b2\u30fc\u30e0\u306e\u30d6\u30fc\u30c8\u306f\u3067\u304d\u307e\u305b\u3093.DEVICE=%s126 Error 126
Cassette error (%d1)
\u30ab\u30bb\u30c3\u30c8\u30a8\u30e9\u30fc (%d1)27 Error 127
Master Calendar network error.
\u30de\u30b9\u30bf\u30fc\u30ab\u30ec\u30f3\u30c0\u30fc\u901a\u4fe1\u30a8\u30e9\u30fc.28 Error 128
Master Calendar network error.
\u30de\u30b9\u30bf\u30fc\u30ab\u30ec\u30f3\u30c0\u30fc\u901a\u4fe1\u30a8\u30e9\u30fc.29 Error 129
Master Calendar network error.
\u30de\u30b9\u30bf\u30fc\u30ab\u30ec\u30f3\u30c0\u30fc\u901a\u4fe1\u30a8\u30e9\u30fc.30 Error 130
Installation boot device error.Installation cassette is inserted.Turn off the power. Before turning thepower on: 1. Change the cassette to theOperating Cassette to enter the game or2. Set DIP-SW4 to \"OFF\" to install.
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30d6\u30fc\u30c8\u30c7\u30d0\u30a4\u30b9\u30a8\u30e9\u30fc.\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8\u304c\u30bb\u30c3\u30c8\u3055\u308c\u3066\u3044\u307e\u3059.\u96fb\u6e90\u3092\u5207\u308a,\u30b2\u30fc\u30e0\u3092\u884c\u3046\u306b\u306f\u904b\u7528\u30ab\u30bb\u30c3\u30c8\u306b\u4ea4\u63db, \u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3059\u308b\u306b\u306fDIP-SW4\u3092OFF\u306b\u3057,\u518d\u5ea6\u96fb\u6e90\u3092\u5165\u308c\u3066\u304f\u3060\u3055\u3044.31 Error 131
Installation Cassette does not correspondto the machine.Please use Installation Cassette marked%s1 for installation.
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8\u3068\u672c\u4f53\u3068\u306e\u5bfe\u5fdc\u304c\u3068\u308c\u3066\u3044\u307e\u305b\u3093. \u8a8d\u8a3c\u756a\u53f7%s1\u304c\u8a18\u5165\u3055\u308c\u305f\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8\u3092\u7528\u3044\u3066\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3057\u3066\u304f\u3060\u3055\u3044.32 Error 132
Cassette error (%d1)
\u30ab\u30bb\u30c3\u30c8\u30a8\u30e9\u30fc (%d1)35 Error 135
This cassette is used to convert anothergame. This can not be used as an operatingcassette.
\u3053\u306e\u30ab\u30bb\u30c3\u30c8\u306f\u3044\u3061\u3069\u6b21\u6a5f\u7a2e\u3078\u306e\u30b3\u30f3\u30d0\u30fc\u30b8\u30e7\u30f3\u306b\u4f7f\u7528\u3055\u308c\u305f\u3082\u306e\u3067\u3059.\u904b\u7528\u30ab\u30bb\u30c3\u30c8\u3068\u3057\u3066\u4f7f\u7528\u3059\u308b\u3053\u3068\u306f\u3067\u304d\u307e\u305b\u3093.36 Error 136
Cassette error (%d1)
\u30ab\u30bb\u30c3\u30c8\u30a8\u30e9\u30fc (%d1)38 Error 138
File not found.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093.FILE=%s139 Error 139
File reading error.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u30ea\u30fc\u30c9\u30a8\u30e9\u30fc.FILE=%s140 Error 140
File not found.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093.FILE=%s141 Error 141
File reading error.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u30ea\u30fc\u30c9\u30a8\u30e9\u30fc.FILE=%s142 Error 142
File reading error.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u30ea\u30fc\u30c9\u30a8\u30e9\u30fc.FILE=%s143 Error 143
File reading error.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u30ea\u30fc\u30c9\u30a8\u30e9\u30fc.FILE=%s144 Error 144
File data error.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u30c7\u30fc\u30bf\u30a8\u30e9\u30fc.FILE=%s145 Error 145
File data error.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u30c7\u30fc\u30bf\u30a8\u30e9\u30fc.FILE=%s146 Error 146
Turn off the power and check if the FlashCard is inserted properly.Please turn the power on after checking.DEVICE=%s1
\u96fb\u6e90\u3092\u5207\u308a, \u30d5\u30e9\u30c3\u30b7\u30e5\u30ab\u30fc\u30c9\u304c\u6b63\u3057\u304f\u30bb\u30c3\u30c8\u3055\u308c\u3066\u3044\u308b\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044. \u6e96\u5099\u304c\u6574\u3063\u3066\u304b\u3089\u518d\u3073\u96fb\u6e90\u3092\u5165\u308c\u3066\u304f\u3060\u3055\u3044.DEVICE=%s147 Error 147
Checksum error. If you have the latestCD-ROM, please replace. Turn off thepower and insert installation cassette.Set DIP-SW4 to \"OFF\", then turn on thepower and reinstall CD-ROM.
\u30c1\u30a7\u30c3\u30af\u30b5\u30e0\u30a8\u30e9\u30fc. \u6700\u65b0\u306eCD-ROM\u304c\u3042\u308c\u3070,\u305d\u308c\u306b\u4ea4\u63db\u3057\u3066\u304f\u3060\u3055\u3044. \u96fb\u6e90\u3092\u5207\u308a,\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8\u306b\u4ea4\u63db,DIP-SW4\u3092OFF\u306b\u3057\u3066\u96fb\u6e90\u3092\u5165\u308c,\u518d\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3057\u3066\u304f\u3060\u3055\u3044.48 Error 148
Area specification error.Only area specification below is available. %s1Check the DIP-SW of Master Calendar.
\u4ed5\u5411\u5730\u6307\u5b9a\u30a8\u30e9\u30fc.\u672c\u30bf\u30a4\u30c8\u30eb\u306f\u6b21\u306e\u4ed5\u5411\u5730\u306e\u307f\u6307\u5b9a\u3067\u304d\u307e\u3059. %s1\u30de\u30b9\u30bf\u30fc\u30ab\u30ec\u30f3\u30c0\u30fc\u306eDIP-SW\u3092\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.49 Error 149
Cassette initialization error.The cassette is already initialized asOperating Cassette (%s1)Reinitialization can not be completed.
\u30ab\u30bb\u30c3\u30c8\u521d\u671f\u5316\u30a8\u30e9\u30fc.\u30ab\u30bb\u30c3\u30c8\u306f\u3059\u3067\u306b\u904b\u7528\u30ab\u30bb\u30c3\u30c8(%s1)\u3068\u3057\u3066\u521d\u671f\u5316\u3055\u308c\u3066\u3044\u307e\u3059.\u518d\u521d\u671f\u5316\u306f\u3067\u304d\u307e\u305b\u3093.50 Error 150
Cassette initialization error.The cassette is already initialized asInstallation Cassette (%s1)Reinitialization can not be completed.
\u30ab\u30bb\u30c3\u30c8\u521d\u671f\u5316\u30a8\u30e9\u30fc.\u30ab\u30bb\u30c3\u30c8\u306f\u3059\u3067\u306b\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8(%s1)\u3068\u3057\u3066\u521d\u671f\u5316\u3055\u308c\u3066\u3044\u307e\u3059.\u518d\u521d\u671f\u5316\u306f\u3067\u304d\u307e\u305b\u3093.51 Error 151
File not found.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093.FILE=%s152 Error 152
Turn off the power and check if the FlashCard is inserted properly.Please turn the power on after checking.DEVICE=%s1
\u96fb\u6e90\u3092\u5207\u308a, \u30d5\u30e9\u30c3\u30b7\u30e5\u30ab\u30fc\u30c9\u304c\u6b63\u3057\u304f\u30bb\u30c3\u30c8\u3055\u308c\u3066\u3044\u308b\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044. \u6e96\u5099\u304c\u6574\u3063\u3066\u304b\u3089\u518d\u3073\u96fb\u6e90\u3092\u5165\u308c\u3066\u304f\u3060\u3055\u3044.DEVICE=%s153 Error 153
Installation failed. (%d1)
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u306b\u5931\u6557\u3057\u307e\u3057\u305f (%d1)54 Error 154
Assertion failed.FILE=%s1LINE=%d2
\u30a2\u30b5\u30fc\u30b7\u30e7\u30f3\u30d5\u30a7\u30a4\u30eb.FILE=%s1LINE=%d255 Error 155
Argument buffer overflow.
\u5f15\u6570\u30d0\u30c3\u30d5\u30a1\u30aa\u30fc\u30d0\u30fc\u30d5\u30ed\u30fc.56 Error 156
File not found.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093.FILE=%s157 Error 157
File data error.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u30c7\u30fc\u30bf\u30a8\u30e9\u30fc.FILE=%s158 Error 158
File reading error.FILE=%s1
\u30d5\u30a1\u30a4\u30eb\u30ea\u30fc\u30c9\u30a8\u30e9\u30fc.FILE=%s159 Error 159
Security Chip error. (%d1)This Security Chip was initialized foranother title.
\u30bb\u30ad\u30e5\u30ea\u30c6\u30a3\u30c1\u30c3\u30d7\u30a8\u30e9\u30fc.(%d1)\u3053\u306e\u30bb\u30ad\u30e5\u30ea\u30c6\u30a3\u30c1\u30c3\u30d7\u306f\u4ed6\u306e\u30bf\u30a4\u30c8\u30eb\u7528\u306b\u521d\u671f\u5316\u3055\u308c\u3066\u3044\u307e\u3059.60 Error 160
CD-ROM drive error
CD-ROM\u30c9\u30e9\u30a4\u30d6\u30a8\u30e9\u30fc.61 Error 161
RTC error
RTC\u30a8\u30e9\u30fc.62 Error 162
Specification selection errorOnly specification below can beselected for this title. %s1Check the DIP-SW of machine.
\u5546\u54c1\u4ed5\u69d8\u6307\u5b9a\u30a8\u30e9\u30fc.\u672c\u30bf\u30a4\u30c8\u30eb\u306f\u6b21\u306e\u5546\u54c1\u4ed5\u69d8\u306e\u307f\u6307\u5b9a\u3067\u304d\u307e\u3059. %s1\u672c\u4f53\u306eDIP-SW\u3092\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.64 Error 164
Operating Cassette is not correspondingwith the machine. Turn off the power andreplace it with Operating CassetteNo.%s1 then reboot.
\u904b\u7528\u30ab\u30bb\u30c3\u30c8\u3068\u672c\u4f53\u3068\u306e\u5bfe\u5fdc\u304c\u3068\u308c\u3066\u3044\u307e\u305b\u3093.\u96fb\u6e90\u3092\u5207\u308a,\u8a8d\u8a3c\u756a\u53f7%s1\u304c\u8a18\u5165\u3055\u308c\u305f\u904b\u7528\u30ab\u30bb\u30c3\u30c8\u306b\u4ea4\u63db\u3057\u3066\u518d\u8d77\u52d5\u3057\u3066\u304f\u3060\u3055\u3044.66 Error 166
Incorrect cassette installed.
\u4e0d\u5f53\u306a\u30ab\u30bb\u30c3\u30c8\u3067\u3059.67 Error 167
Security Chip initialization failed. (%d1)
\u30bb\u30ad\u30e5\u30ea\u30c6\u30a3\u30c1\u30c3\u30d7\u521d\u671f\u5316\u30a8\u30e9\u30fc. (%d1)69 Error 169
Cannot use this security cassetteas Installation Cassette.
\u3053\u306e\u30bb\u30ad\u30e5\u30ea\u30c6\u30a3\u30ab\u30bb\u30c3\u30c8\u306f\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8\u3068\u3057\u3066\u4f7f\u7528\u3059\u308b\u3053\u3068\u306f\u3067\u304d\u307e\u305b\u3093.70 Error 170
Cannot use this security cassetteas Installation Cassette.
\u3053\u306e\u30bb\u30ad\u30e5\u30ea\u30c6\u30a3\u30ab\u30bb\u30c3\u30c8\u306f\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8\u3068\u3057\u3066\u4f7f\u7528\u3059\u308b\u3053\u3068\u306f\u3067\u304d\u307e\u305b\u3093.71 Error 171
This version cannot initialize a cassette.Please replace CD-ROM to %s1for initialize, and turn off the power.Set DIP-SW4 to \"OFF\", then turn onthe power.
\u3053\u306e\u30d0\u30fc\u30b8\u30e7\u30f3\u306f\u30ab\u30bb\u30c3\u30c8\u3092\u521d\u671f\u5316\u3067\u304d\u307e\u305b\u3093.\u521d\u671f\u5316\u3059\u308b\u306b\u306fCD-ROM\u3092%s1\u306b\u4ea4\u63db\u3057\u3066\u96fb\u6e90\u3092\u5207\u308a,DIP-SW4\u3092OFF\u306b\u3057\u3066\u518d\u8d77\u52d5\u3057\u3066\u304f\u3060\u3055\u3044.72 Error 172
You are using an incorrect CD-ROM.Replace CD-ROM to %s1 andturn on the main power.
CD-ROM\u304c\u9055\u3044\u307e\u3059.CD-ROM\u3092%s1\u306b\u4ea4\u63db\u3057,\u96fb\u6e90\u3092\u5165\u308c\u76f4\u3057\u3066\u304f\u3060\u3055\u3044.73 Error 173
Cannot use this security cassette.
\u3053\u306e\u30bb\u30ad\u30e5\u30ea\u30c6\u30a3\u30ab\u30bb\u30c3\u30c8\u306f\u4f7f\u7528\u3067\u304d\u307e\u305b\u3093.74 Error 174
Cannot use this security cassette.
\u3053\u306e\u30bb\u30ad\u30e5\u30ea\u30c6\u30a3\u30ab\u30bb\u30c3\u30c8\u306f\u4f7f\u7528\u3067\u304d\u307e\u305b\u3093.75 Error 175
Cassette is not corresponding with themachine. Turn off the power andreplace it with Cassette No.%s1then reboot.
\u30ab\u30bb\u30c3\u30c8\u3068\u672c\u4f53\u3068\u306e\u5bfe\u5fdc\u304c\u3068\u308c\u3066\u3044\u307e\u305b\u3093.\u96fb\u6e90\u3092\u5207\u308a,\u8a8d\u8a3c\u756a\u53f7%s1\u304c\u8a18\u5165\u3055\u308c\u305f\u30ab\u30bb\u30c3\u30c8\u306b\u4ea4\u63db\u3057\u3066\u518d\u8d77\u52d5\u3057\u3066\u304f\u3060\u3055\u3044.76 Error 176
Cassette is not corresponding with themachine. Turn off the power andreplace it with Cassette No.%s1then reboot.
\u30ab\u30bb\u30c3\u30c8\u3068\u672c\u4f53\u3068\u306e\u5bfe\u5fdc\u304c\u3068\u308c\u3066\u3044\u307e\u305b\u3093.\u96fb\u6e90\u3092\u5207\u308a,\u8a8d\u8a3c\u756a\u53f7%s1\u304c\u8a18\u5165\u3055\u308c\u305f\u30ab\u30bb\u30c3\u30c8\u306b\u4ea4\u63db\u3057\u3066\u518d\u8d77\u52d5\u3057\u3066\u304f\u3060\u3055\u3044.77 Error 177
Checksum error.If you have the latest CD-ROM, pleasereplace. Turn off the power and setDIP-SW4 to \"OFF\", then turn onthe power and reinstall CD-ROM.
\u30c1\u30a7\u30c3\u30af\u30b5\u30e0\u30a8\u30e9\u30fc.\u6700\u65b0\u306eCD-ROM\u304c\u3042\u308c\u3070\u305d\u308c\u306b\u4ea4\u63db\u3057\u3066\u304f\u3060\u3055\u3044.\u96fb\u6e90\u3092\u5207\u3063\u3066DIP-SW4\u3092OFF\u306b\u3057\u305f\u3042\u3068,\u96fb\u6e90\u3092\u5165\u308c\u3066\u518d\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3057\u3066\u304f\u3060\u3055\u3044.78 Error 178
This cassette is used to convert anothergame. This can not be used to this game.
\u3053\u306e\u30ab\u30bb\u30c3\u30c8\u306f\u6b21\u6a5f\u7a2e\u3078\u306e\u30b3\u30f3\u30d0\u30fc\u30b8\u30e7\u30f3\u306b\u4f7f\u7528\u3055\u308c\u305f\u3082\u306e\u3067\u3059.\u3053\u306e\u6a5f\u7a2e\u3067\u518d\u3073\u4f7f\u7528\u3059\u308b\u3053\u3068\u306f\u3067\u304d\u307e\u305b\u3093.79 Error 179
Boot is not available from this device.DEVICE=%s1
\u3053\u306e\u30c7\u30d0\u30a4\u30b9\u304b\u3089\u30b2\u30fc\u30e0\u306e\u30d6\u30fc\u30c8\u306f\u3067\u304d\u307e\u305b\u3093.DEVICE=%s180 Error 180
You are using an incorrect CD-ROM.Replace CD-ROM to %s1 andturn on the main power.
CD-ROM\u304c\u9055\u3044\u307e\u3059.CD-ROM\u3092%s1\u306b\u4ea4\u63db\u3057,\u96fb\u6e90\u3092\u5165\u308c\u76f4\u3057\u3066\u304f\u3060\u3055\u3044.81 Error 181
File system mounting failed.Please check that correct CD-ROM is in use.
\u30d5\u30a1\u30a4\u30eb\u30b7\u30b9\u30c6\u30e0\u306e\u30de\u30a6\u30f3\u30c8\u306b\u5931\u6557\u3057\u307e\u3057\u305f.CD-ROM\u304c\u9593\u9055\u3063\u3066\u3044\u306a\u3044\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.82 Error 182
File system mounting failed.Please check that correct CD-ROM is in use.
\u30d5\u30a1\u30a4\u30eb\u30b7\u30b9\u30c6\u30e0\u306e\u30de\u30a6\u30f3\u30c8\u306b\u5931\u6557\u3057\u307e\u3057\u305f.CD-ROM\u304c\u9593\u9055\u3063\u3066\u3044\u306a\u3044\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.83 Error 183
Installation boot device error.Please turn off the power for installation,and set DIP-SW4 to \"OFF\", then turn onthe power.
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30d6\u30fc\u30c8\u30c7\u30d0\u30a4\u30b9\u30a8\u30e9\u30fc.\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3059\u308b\u306b\u306f\u96fb\u6e90\u3092\u5207\u308a,DIP-SW4\u3092OFF\u306b\u3057\u3066\u518d\u8d77\u52d5\u3057\u3066\u304f\u3060\u3055\u3044.84 Error 184
CD-ROM drive error
CD-ROM\u30c9\u30e9\u30a4\u30d6\u30a8\u30e9\u30fc.85 Error 185
CD-ROM drive version update failed. (%d1)Please call a dealer near you.
CD-ROM\u30c9\u30e9\u30a4\u30d6\u306e\u30d0\u30fc\u30b8\u30e7\u30f3\u30a2\u30c3\u30d7\u306b\u5931\u6557\u3057\u307e\u3057\u305f. (%d1)\u6700\u5bc4\u308a\u306e\u30b5\u30fc\u30d3\u30b9\u30bb\u30f3\u30bf\u30fc\u306b\u304a\u554f\u3044\u5408\u308f\u305b\u4e0b\u3055\u3044.86 Error 186
Cassette error (%d1)
\u30ab\u30bb\u30c3\u30c8\u30a8\u30e9\u30fc (%d1)87 Error 187
You are using the cassette of anothercabinet. Please use the correct cassette.Please see details in operator's manual.
\u7570\u306a\u308b\u672c\u4f53\u5411\u3051\u306e\u30ab\u30bb\u30c3\u30c8\u3092\u4f7f\u7528\u3057\u3066\u3044\u307e\u3059.\u6b63\u3057\u3044\u672c\u4f53\u3068\u306e\u7d44\u307f\u5408\u308f\u305b\u3067\u4f7f\u7528\u3057\u3066\u304f\u3060\u3055\u3044.\u8a73\u3057\u304f\u306f\u53d6\u308a\u6271\u3044\u8aac\u660e\u66f8\u3092\u53c2\u7167\u3057\u3066\u304f\u3060\u3055\u3044.88 Error 188
You are using the cassette of anothercabinet. Please use the correct cassette.Please see details in operator's manual.
\u7570\u306a\u308b\u672c\u4f53\u5411\u3051\u306e\u30ab\u30bb\u30c3\u30c8\u3092\u4f7f\u7528\u3057\u3066\u3044\u307e\u3059.\u6b63\u3057\u3044\u672c\u4f53\u3068\u306e\u7d44\u307f\u5408\u308f\u305b\u3067\u4f7f\u7528\u3057\u3066\u304f\u3060\u3055\u3044.\u8a73\u3057\u304f\u306f\u53d6\u308a\u6271\u3044\u8aac\u660e\u66f8\u3092\u53c2\u7167\u3057\u3066\u304f\u3060\u3055\u3044.89 Error 189
You are using unknown cabinet.Check all connectors.Please see details in operator's manual.
\u4e0d\u660e\u306a\u672c\u4f53\u3092\u4f7f\u7528\u3057\u3066\u3044\u307e\u3059.\u5404\u30b3\u30cd\u30af\u30bf\u304c\u5916\u308c\u3066\u3044\u306a\u3044\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.\u8a73\u3057\u304f\u306f\u53d6\u308a\u6271\u3044\u8aac\u660e\u66f8\u3092\u53c2\u7167\u3057\u3066\u304f\u3060\u3055\u3044.90 Error 190
You are using unknown cabinet.Check all connectors.Please see details in operator's manual.
\u4e0d\u660e\u306a\u672c\u4f53\u3092\u4f7f\u7528\u3057\u3066\u3044\u307e\u3059.\u5404\u30b3\u30cd\u30af\u30bf\u304c\u5916\u308c\u3066\u3044\u306a\u3044\u304b\u78ba\u8a8d\u3057\u3066\u304f\u3060\u3055\u3044.\u8a73\u3057\u304f\u306f\u53d6\u308a\u6271\u3044\u8aac\u660e\u66f8\u3092\u53c2\u7167\u3057\u3066\u304f\u3060\u3055\u3044.91 Error 191
Non-applicable game installed.To install this game, %s1shall be installed first.
\u7570\u306a\u308b\u30b2\u30fc\u30e0\u304c\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3055\u308c\u3066\u3044\u307e\u3059.\u3053\u306e\u30b2\u30fc\u30e0\u3092\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3059\u308b\u306b\u306f\u3042\u3089\u304b\u3058\u3081 %s1\u304c\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3055\u308c\u3066\u3044\u308b\u5fc5\u8981\u304c\u3042\u308a\u307e\u3059.92 Error 192
This software is for the e-Amusementsystem.The game will only work on the e-Amusementcabinet.
\u3053\u306e\u30b2\u30fc\u30e0\u30bd\u30d5\u30c8\u306fe-Amusement(\u30ec\u30f3\u30bf\u30eb)\u7528\u30bd\u30d5\u30c8\u3067\u3059.e-Amusement\u7528\u7b50\u4f53\u3067\u306e\u307f\u52d5\u4f5c\u3057\u307e\u3059.93 Error 193
This software is not for the e-Amusementsystem.The game doesn't work on the e-Amusementcabinet.
\u3053\u306e\u30b2\u30fc\u30e0\u30bd\u30d5\u30c8\u306fe-Amusement(\u30ec\u30f3\u30bf\u30eb)\u7528\u30bd\u30d5\u30c8\u3067\u306f\u3042\u308a\u307e\u305b\u3093.e-Amusement\u7528\u7b50\u4f53\u3067\u306f\u52d5\u4f5c\u3057\u307e\u305b\u3093.94 Error 194
Non-applicable game installed.To install this game, %s1shall be installed first.
\u7570\u306a\u308b\u30b2\u30fc\u30e0\u304c\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3055\u308c\u3066\u3044\u307e\u3059.\u3053\u306e\u30b2\u30fc\u30e0\u3092\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3059\u308b\u306b\u306f\u3042\u3089\u304b\u3058\u3081 %s1\u304c\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3055\u308c\u3066\u3044\u308b\u5fc5\u8981\u304c\u3042\u308a\u307e\u3059.95 Error 195
Cassette initialization error.The cassette is already initialized as%s1Reinitialization can not be completed.
\u30ab\u30bb\u30c3\u30c8\u521d\u671f\u5316\u30a8\u30e9\u30fc.\u30ab\u30bb\u30c3\u30c8\u306f\u3059\u3067\u306b%s1\u3068\u3057\u3066\u521d\u671f\u5316\u3055\u308c\u3066\u3044\u307e\u3059. \u518d\u521d\u671f\u5316\u306f\u3067\u304d\u307e\u305b\u3093.96 Error 196
Cassette initialization error.The cassette is already initialized as%s1Reinitialization can not be completed.
\u30ab\u30bb\u30c3\u30c8\u521d\u671f\u5316\u30a8\u30e9\u30fc.\u30ab\u30bb\u30c3\u30c8\u306f\u3059\u3067\u306b%s1\u3068\u3057\u3066\u521d\u671f\u5316\u3055\u308c\u3066\u3044\u307e\u3059. \u518d\u521d\u671f\u5316\u306f\u3067\u304d\u307e\u305b\u3093.97 Error 197
Cassette initialization error.The cassette is already initialized as%s1Reinitialization can not be completed.
\u30ab\u30bb\u30c3\u30c8\u521d\u671f\u5316\u30a8\u30e9\u30fc.\u30ab\u30bb\u30c3\u30c8\u306f\u3059\u3067\u306b%s1\u3068\u3057\u3066\u521d\u671f\u5316\u3055\u308c\u3066\u3044\u307e\u3059. \u518d\u521d\u671f\u5316\u306f\u3067\u304d\u307e\u305b\u3093.98 Info 198, 500
Installation completed.Please write down the No.%s2on cassette and machine. Turn off thepower and replace cassette to%s1 then turn on the power.
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u5b8c\u4e86.\u30ab\u30bb\u30c3\u30c8\u3068\u672c\u4f53\u306b\u8a8d\u8a3c\u756a\u53f7%s2\u3092\u8a18\u5165\u3057\u3066\u304f\u3060\u3055\u3044.\u96fb\u6e90\u3092\u5207\u3063\u3066\u30ab\u30bb\u30c3\u30c8\u3092%s1\u306b\u4ea4\u63db\u3057,\u518d\u5ea6\u96fb\u6e90\u3092\u5165\u308c\u3066\u304f\u3060\u3055\u3044.99 Info 199, 501
Installation complete. Please write downthe No.%s3 on cassette and machine.Replace CD-ROM to %s1 and turn offthe power then replace cassette to%s2. Set DIP-SW4 to \"ON\",then turn on the power.
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u5b8c\u4e86. \u30ab\u30bb\u30c3\u30c8\u3068\u672c\u4f53\u306b\u8a8d\u8a3c\u756a\u53f7%s3\u3092\u8a18\u5165\u3057\u3066\u304f\u3060\u3055\u3044.CD-ROM\u3092%s1\u306b\u4ea4\u63db\u3057\u3066\u96fb\u6e90\u3092\u5207\u308a,\u30ab\u30bb\u30c3\u30c8\u3092%s2\u306b\u4ea4\u63db\u3057,DIP-SW4\u3092ON\u306b\u3057\u3066\u518d\u5ea6\u96fb\u6e90\u3092\u5165\u308c\u3066\u304f\u3060\u3055\u3044.100 Info 200, 502
Operating cassette initialized.The cassette was initialized as OperatingCassette (%s1)
\u904b\u7528\u30ab\u30bb\u30c3\u30c8\u521d\u671f\u5316\u5b8c\u4e86.\u30ab\u30bb\u30c3\u30c8\u3092\u904b\u7528\u30ab\u30bb\u30c3\u30c8(%s1)\u3068\u3057\u3066\u521d\u671f\u5316\u3057\u307e\u3057\u305f.101 Info 201, 503
Installation cassette initialized.The cassette was initialized asInstallation Cassette (%s1)
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8\u521d\u671f\u5316\u5b8c\u4e86.\u30ab\u30bb\u30c3\u30c8\u3092\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8(%s1)\u3068\u3057\u3066\u521d\u671f\u5316\u3057\u307e\u3057\u305f.102 Info 202, 504
Initialized Operating CassetteThe cassette is already initialized asOperating Cassette (%s1)Reinitialization is not necessary.
\u521d\u671f\u5316\u6e08\u307f\u904b\u7528\u30ab\u30bb\u30c3\u30c8.\u30ab\u30bb\u30c3\u30c8\u306f\u3059\u3067\u306b\u904b\u7528\u30ab\u30bb\u30c3\u30c8(%s1)\u3068\u3057\u3066\u521d\u671f\u5316\u3055\u308c\u3066\u3044\u307e\u3059. \u518d\u521d\u671f\u5316\u306e\u5fc5\u8981\u306f\u3042\u308a\u307e\u305b\u3093.103 Info 203, 505
Initialized Installation CassetteThe cassette is already initialized asInstallation Cassette (%s1)Reinitialization is not necessary.
\u521d\u671f\u5316\u6e08\u307f\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8.\u30ab\u30bb\u30c3\u30c8\u306f\u3059\u3067\u306b\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8(%s1)\u3068\u3057\u3066\u521d\u671f\u5316\u3055\u308c\u3066\u3044\u307e\u3059.\u518d\u521d\u671f\u5316\u306e\u5fc5\u8981\u306f\u3042\u308a\u307e\u305b\u3093.104 Info 204, 506
Installation completed.Please write down the No.%s2on cassette and machine. Turn off thepower and replace cassette to%s1 then turn on the power.
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u5b8c\u4e86.\u30ab\u30bb\u30c3\u30c8\u3068\u672c\u4f53\u306b\u8a8d\u8a3c\u756a\u53f7%s2\u3092\u8a18\u5165\u3057\u3066\u304f\u3060\u3055\u3044.\u96fb\u6e90\u3092\u5207\u3063\u3066\u30ab\u30bb\u30c3\u30c8\u3092%s1\u306b\u4ea4\u63db\u3057,\u518d\u5ea6\u96fb\u6e90\u3092\u5165\u308c\u3066\u304f\u3060\u3055\u3044.105 Info 205, 507
Installation complete. Please write downthe No.%s3 on cassette and machine.Replace CD-ROM to %s1 and turn offthe power then replace cassette to%s2. Set DIP-SW4 to \"ON\",then turn on the power.
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u5b8c\u4e86. \u30ab\u30bb\u30c3\u30c8\u3068\u672c\u4f53\u306b\u8a8d\u8a3c\u756a\u53f7%s3\u3092\u8a18\u5165\u3057\u3066\u304f\u3060\u3055\u3044.CD-ROM\u3092%s1\u306b\u4ea4\u63db\u3057\u3066\u96fb\u6e90\u3092\u5207\u308a,\u30ab\u30bb\u30c3\u30c8\u3092%s2\u306b\u4ea4\u63db\u3057,DIP-SW4\u3092ON\u306b\u3057\u3066\u518d\u5ea6\u96fb\u6e90\u3092\u5165\u308c\u3066\u304f\u3060\u3055\u3044.106 Info 206, 508
Installation completed.Please write down the No.%s1on cassette and machine.Turn off the power, then reboot.
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u5b8c\u4e86.\u30ab\u30bb\u30c3\u30c8\u3068\u672c\u4f53\u306b\u8a8d\u8a3c\u756a\u53f7%s1\u3092\u8a18\u5165\u3057\u3066\u304f\u3060\u3055\u3044.\u96fb\u6e90\u3092\u5207\u3063\u3066\u518d\u8d77\u52d5\u3057\u3066\u304f\u3060\u3055\u3044.107 Info 207, 509
Installation complete.Please write down the No.%s2on cassette and machine.Replace CD-ROM to %s1 and turn offthe power.Set DIP-SW4 to \"ON\", then reboot.
\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u5b8c\u4e86.\u30ab\u30bb\u30c3\u30c8\u3068\u672c\u4f53\u306b\u8a8d\u8a3c\u756a\u53f7%s2\u3092\u8a18\u5165\u3057\u3066\u304f\u3060\u3055\u3044.CD-ROM\u3092%s1\u306b\u4ea4\u63db\u3057\u3066\u96fb\u6e90\u3092\u5207\u308a,DIP-SW4\u3092ON\u306b\u3057\u3066\u518d\u8d77\u52d5\u3057\u3066\u304f\u3060\u3055\u3044.108 Info 208, 510
Security cassette initialized.The cassette was initialized for%s1.
\u30bb\u30ad\u30e5\u30ea\u30c6\u30a3\u30ab\u30bb\u30c3\u30c8\u521d\u671f\u5316\u5b8c\u4e86.\u30ab\u30bb\u30c3\u30c8\u3092%s1\u306b\u521d\u671f\u5316\u3057\u307e\u3057\u305f.109 Info 209, 511
Initialized Security CassetteThe cassette is already initialized for%s1.Reinitialization is not necessary.
\u521d\u671f\u5316\u6e08\u307f\u30bb\u30ad\u30e5\u30ea\u30c6\u30a3\u30ab\u30bb\u30c3\u30c8.\u30ab\u30bb\u30c3\u30c8\u306f\u3059\u3067\u306b%s1\u306b\u521d\u671f\u5316\u3055\u308c\u3066\u3044\u307e\u3059. \u518d\u521d\u671f\u5316\u306e\u5fc5\u8981\u306f\u3042\u308a\u307e\u305b\u3093.110 Info 210, 512
SERVICE button is pressed.To force installation, turn off the power,change the cassette to the InstallationCassette, and turn on the power withpressing SERVICE switch.
\u30b5\u30fc\u30d3\u30b9\u30dc\u30bf\u30f3\u304c\u62bc\u3055\u308c\u3066\u3044\u307e\u3059.\u5f37\u5236\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u3092\u884c\u3046\u306b\u306f\u96fb\u6e90\u3092\u5207\u308a,\u30a4\u30f3\u30b9\u30c8\u30fc\u30eb\u30ab\u30bb\u30c3\u30c8\u306b\u4ea4\u63db\u3057\u3066, \u30b5\u30fc\u30d3\u30b9\u30dc\u30bf\u30f3\u3092\u62bc\u3057\u306a\u304c\u3089\u96fb\u6e90\u3092\u5165\u308c\u3066\u304f\u3060\u3055\u3044.111 Note 211, 513, 602
CD-ROM drive version update in progress.Please do not shut off power.This will take a few moments.
\u73fe\u5728CD-ROM\u30c9\u30e9\u30a4\u30d6\u306e\u30d0\u30fc\u30b8\u30e7\u30f3\u30a2\u30c3\u30d7\u3092\u5b9f\u884c\u3057\u3066\u3044\u307e\u3059.\u96fb\u6e90\u3092\u5207\u3089\u305a\u306b\u305d\u306e\u307e\u307e\u304a\u5f85\u3061\u4e0b\u3055\u3044.112 Note 212, 514, 603
CD-ROM drive version update completed.
CD-ROM\u30c9\u30e9\u30a4\u30d6\u306e\u30d0\u30fc\u30b8\u30e7\u30f3\u30a2\u30c3\u30d7\u304c\u5b8c\u4e86\u3057\u307e\u3057\u305f.113 Note 213, 515, 604
Starting CD-ROM drive version update.Please do not turn off the power whileupdating.Press TEST button to begin updating.
CD-ROM\u30c9\u30e9\u30a4\u30d6\u306e\u30d0\u30fc\u30b8\u30e7\u30f3\u30a2\u30c3\u30d7\u3092\u884c\u3044\u307e\u3059.\u30d0\u30fc\u30b8\u30e7\u30f3\u30a2\u30c3\u30d7\u4e2d\u306f\u7d76\u5bfe\u306b\u96fb\u6e90\u3092\u5207\u3089\u306a\u3044\u3067\u4e0b\u3055\u3044.\u30c6\u30b9\u30c8\u30dc\u30bf\u30f3\u3092\u62bc\u3059\u3068\u30d0\u30fc\u30b8\u30e7\u30f3\u30a2\u30c3\u30d7\u3092\u958b\u59cb\u3057\u307e\u3059.114 Note 214, 516, 605
Cleared RTC-RAM.At Game Demo screen, press the test buttonfor the Test Mode and re-do the settings.Press the Test Button for the next screen.
RTC-RAM\u3092\u30af\u30ea\u30a2\u3057\u307e\u3057\u305f.\u30b2\u30fc\u30e0\u30c7\u30e2\u304c\u59cb\u307e\u3063\u305f\u3089\u30c6\u30b9\u30c8\u30dc\u30bf\u30f3\u3092\u62bc\u3057\u3066\u30c6\u30b9\u30c8\u30e2\u30fc\u30c9\u306b\u5165\u308a\u8a2d\u5b9a\u3092\u3084\u308a\u76f4\u3057\u3066\u304f\u3060\u3055\u3044.\u30c6\u30b9\u30c8\u30dc\u30bf\u30f3\u3092\u62bc\u3059\u3068\u6b21\u306b\u9032\u307f\u307e\u3059."},{"location":"konamisystem573/#pinouts","title":"Pinouts","text":"
GX700-PWB(A))GX700-PWB(F))GX894-PWB(B)A)GX700-PWB(A))","text":""},{"location":"konamisystem573/#analog-input-port-analog-cn3","title":"Analog input port (ANALOG, CN3)","text":"The inputs are wired directly to the 573's built-in ADC with no protection, so they can only accept voltages in 0-5V range. This connector is usually used for potentiometers and similar resistive analog controls.
Pin Name Dir 15V 2 5V 3 5V 4 5V 5 CH0 I 6 GND 7 CH1 I 8 CH2 I 9 CH3 I 10 GND"},{"location":"konamisystem573/#digital-output-port-ext-out-cn4","title":"Digital output port (EXT-OUT, CN4)","text":"Unlike the light output ports on most I/O boards, these are unisolated 5V logic level outputs.
Pin Name Dir 15V 2 5V 3 OUT7 O 4 OUT6 O 5 OUT5 O 6 OUT4 O 7 OUT3 O 8 OUT2 O 9 OUT1 O 10 OUT0 O 11 GND 12 GND"},{"location":"konamisystem573/#digital-input-port-ext-in-cn5","title":"Digital input port (EXT-IN, CN5)","text":"Unlike EXT-OUT, this port is not a separate input port. It piggybacks on the JAMMA button inputs instead, exposing the button 4 and 5 pins for both players as well as a sixth button input which is not available on the JAMMA connector. All inputs have a pullup resistor to 5V.
5V 2 5V 3 P1_B4 I 25 4 P1_B5 I 26 5 P1_B6 I 6 GND 7 P2_B4 I c 8 P2_B5 I d 9 P2_B6 I 10 GND"},{"location":"konamisystem573/#amplified-speaker-output-sound-out-cn9","title":"Amplified speaker output (SOUND-OUT, CN9)","text":"The pinout of this connector is currently unknown.
"},{"location":"konamisystem573/#main-io-board-connector-cn10","title":"Main I/O board connector (CN10)","text":"Used by I/O boards to connect to the motherboard. Note that the address and data bus are 3.3V, while all other signals are 5V as they go through the CPLD.
Pin Name Dir Pin Name Dir A15V B1 5V A2 5V B2 5V A3 5V B3 5V A4 5V B4 5V A5 5V B5 5V A6 /RD O B6 /WR0 O A7 /WR1 O B7 GND A8 GND B8 SYSCLK O A9 GND B9 GND A10 /RESET O B10 /RESET O A11 GND B11 GND A12 /CS1 O B12 DMARQ5 I A13 GND B13 GND A14 DMARQ5 I B14 /CS1 O A15 /CS2 O B15 NC A16 /IRQ10 I B16 /IRQ10 I A17 A22 O B17 A23 O A18 A20 O B18 A21 O A19 A14 O B19 A15 O A20 A12 O B20 A13 O A21 A6 O B21 A7 O A22 A4 O B22 A5 O A23 A2 O B23 A3 O A24 A0 O B24 A1 O A25 D14 IO B25 D15 IO A26 D12 IO B26 D13 IO A27 D10 IO B27 D11 IO A28 D8 IO B28 D9 IO A29 D6 IO B29 D7 IO A30 D4 IO B30 D5 IO A31 D2 IO B31 D3 IO A32 D0 IO B32 D1 IO A33 GND B33 GND A34 GND B34 GND A35 GND B35 GND A36 3.3V B36 3.3V A37 3.3V B37 3.3V A38 3.3V B38 3.3V A39 3.3V B39 3.3V A40 3.3V B40 3.3V"},{"location":"konamisystem573/#analog-cd-damp3-audio-input-cd-da-in-cn12","title":"Analog CD-DA/MP3 audio input (CD-DA IN, CN12)","text":"Connected to either the CD-ROM drive's audio output or to CN16 on the digital I/O board on systems equipped with a drive.
LIN I 2 AGND 3 AGND 4 RIN I"},{"location":"konamisystem573/#security-cartridge-slot-cn14","title":"Security cartridge slot (CN14)","text":"All signals are 5V as they go through level shifters.
Pin Name Dir Notes Pin Name Dir Notes 1GND 23 GND 2 GND 24 GND 3 /DSR I Usually shorted to ground 25 MCUCLK O 7.3728 MHz JVS MCU clock 4 NC May actually be /DTR? 26 GND 5 TX O 27 DRDY O Goes high when 573 updates D0-D7 6 RX I 28 SDA IO 7 /RESET IO System reset (from watchdog) 29 /IREQ I Sets IRDY when pulsed low 8 GND 30 /DACK I Clears DRDY when pulsed low 9 GND 31 IRDY O Goes low when 573 reads I0-I7 10 Key (missing pin) 32 Key (missing pin) 11 ? Not connected? 33 I7 I 12 ? Not connected? 34 I6 I 13 D7 O 35 I5 I 14 D6 O 36 I4 I 15 D5 O 37 I3 I 16 D4 O 38 I2 I 17 D3 O 39 I1 I 18 D2 O 40 I0 I 19 D1 O 41 5V 20 D0 O 42 5V 21 5V 43 /RTS O Usually shorted to /CTS 22 5V 44 /CTS I Usually shorted to /RTS"},{"location":"konamisystem573/#power-input-or-output-cn17","title":"Power input or output (CN17)","text":"Commonly used to distribute the 12V rail to security cartridges with built-in light drivers or external modules, but it can also used instead of the JAMMA connector to supply power to the 573. The pinout is silkscreened on the board.
Pin Name 112V 2 12V 3 GND 4 GND 5 5V 6 5V"},{"location":"konamisystem573/#i2s-digital-spu-audio-output-digital-audio-cn19","title":"I2S digital SPU audio output (DIGITAL-AUDIO, CN19)","text":"Always unpopulated. Pin 4 outputs a 16.9344 MHz master clock (system clock divided by 2, or 44100 Hz sampling rate multiplied by 384). This port does not output audio from the CD-DA/MP3 input, which is not routed through the SPU.
Pin Name Dir 1BCLK O 2 SDOUT O 3 GND 4 MCLK O 5 LRCK O"},{"location":"konamisystem573/#secondary-io-board-connector-cn21","title":"Secondary I/O board connector (CN21)","text":"The address lines not wired to CN10, as well as the otherwise unused SIO0 controller and memory card bus, are broken out to this connector. No currently known I/O board uses it. All signals are 3.3V.
A8 O B1 A9 O A2 A10 O B2 A11 O A3 A16 O B3 A17 O A4 A18 O B4 A19 O A5 GND B5 ? A6 GND B6 ? A7 GND B7 GND A8 GND B8 DOTCLK O A9 GND B9 GND A10 GND B10 /DSR I A11 GND B11 /DTR2 O A12 GND B12 /DTR1 O A13 GND B13 RX I A14 GND B14 TX O A15 GND B15 SCK O"},{"location":"konamisystem573/#watchdog-test-header-wd-check-cn22","title":"Watchdog test header (WD-CHECK, CN22)","text":"Always unpopulated. Exposes the watchdog's clear input (pulsed whenever the CPU writes to the watchdog clear register) as well as the reset output. Injecting pulses to forcefully clear the watchdog should work, although it's much easier to simply disable it by placing a jumper on S86.
WDCLR IO 2 /RESET O 3 5V 4 GND"},{"location":"konamisystem573/#gpu-clock-and-compositing-output-cn23","title":"GPU clock and compositing output (CN23)","text":"Only present on later revisions of the main board and only populated on DDR Karaoke Mix, which uses the semitransparency plane of the currently displayed framebuffer as an alpha mask in order to composite the 573's output on top of the incoming karaoke video feed.
Pin Name Dir GPU pin 1FSC O 153 2 DMASK O 202 3 GND"},{"location":"konamisystem573/#security-cartridge-serial-port-cn24","title":"Security cartridge serial port (CN24)","text":"Only present on later revisions of the main board and always unpopulated. Exposes the same 5V SIO1 signals as the security cartridge slot.
Pin Name Dir Cart pin 1TX O 5 2 RX I 6 3 GND 4 GND 5 /RTS O 43 6 /CTS I 44"},{"location":"konamisystem573/#rgb-video-output-cn25","title":"RGB video output (CN25)","text":"Only present on later revisions of the main board and only populated on GunMania and DDR Karaoke Mix, whose I/O boards feature RGB to S-video and composite converters respectively. Exposes the same RGB signals as the JAMMA and DB15 connectors.
Pin Name Dir JAMMA pin 1GND O 2 CSYNC O P 3 BOUT O 13 4 GOUT O N 5 ROUT O 12"},{"location":"konamisystem573/#watchdog-configuration-jumper-s86","title":"Watchdog configuration jumper (S86)","text":"Always unpopulated. Shorting pin 1 and 2 will disable the watchdog while keeping power-on reset functional. Pin 3 is an active-high reset output, unused by the 573.
Pin Name Dir 1WDEN I 2 GND 3 RESET O"},{"location":"konamisystem573/#jvs-mcu-pin-mapping","title":"JVS MCU pin mapping","text":"Pin H8 GPIO Dir Connected to Usage 11 P9_0 I Unused 12 P9_1-2 O Konami ASIC Status code (readable from 0x1f400004) 12 P9_3-4 O Konami ASIC Error code (readable from 0x1f400004) 16 IRQ0 I Unused 17-24 P6_0-7 O Konami ASIC Low byte of value readable from 0x1f40000a 25-32 P5_0-7 O Konami ASIC High byte of value readable from 0x1f40000a 34 P7_3 I Handshaking logic Current JVSDRDY status 35 P7_4 I Handshaking logic Current JVSIRDY status 36 P7_5 I Unused 37 P7_6 I Unused 38 P7_7 I Unused 39-46 P8_0-7 I Bus (via latch) High byte of value written to 0x1f680000 47 P2_0 O RS-485 transceiver JVS driver output enable 48 P2_1 I RS-485 transceiver JVS serial port RX 49 P2_2 O RS-485 transceiver JVS serial port TX 50 P3_2 I Unused 51 P3_1 I Unused 52 P3_0 I Unused 53 P1_0 O Handshaking logic /JVSDACK (clears JVSDRDY when pulsed low) 54 P1_4 O Handshaking logic JVSIREQ (sets JVSIRDY when pulsed high) 55 P1_5 I Unused 56 P1_6 I Unused 57 P1_7 I Unused 59-2 PB_7-0 I Bus (via latch) Low byte of value written to 0x1f680000"},{"location":"konamisystem573/#analog-io-board-pinouts-gx700-pwbf","title":"Analog I/O board pinouts (GX700-PWB(F))","text":""},{"location":"konamisystem573/#output-banks-a-b-cn33-cn34-respectively","title":"Output banks A, B (CN33, CN34 respectively)","text":"All outputs are open-drain. Pins 1 and 10 are tied together and connected to the optocouplers' emitters.
Pin Name Dir 1ACOM/BCOM 2 A0/B0 O 3 A1/B1 O 4 A2/B2 O 5 A3/B3 O 6 A4/B4 O 7 A5/B5 O 8 A6/B6 O 9 A7/B7 O 10 ACOM/BCOM"},{"location":"konamisystem573/#output-bank-c-cn35","title":"Output bank C (CN35)","text":"All outputs are open-drain. Unlike banks A and B, pin 10 is not tied to pin 1 but is instead connected to the EMI filters' ground (FGND), isolated from the system ground but shared across all output banks.
CCOM 2 C0 O 3 C1 O 4 C2 O 5 C3 O 6 C4 O 7 C5 O 8 C6 O 9 C7 O 10 FGND"},{"location":"konamisystem573/#output-bank-d-cn36","title":"Output bank D (CN36)","text":"All outputs are open-drain.
Pin Name Dir 1DCOM 2 D0 O 3 D1 O 4 D2 O 5 D3 O 6 FGND"},{"location":"konamisystem573/#digital-io-board-pinouts-gx894-pwbba","title":"Digital I/O board pinouts (GX894-PWB(B)A)","text":""},{"location":"konamisystem573/#output-bank-c-cn10","title":"Output bank C (CN10)","text":"All outputs are open-drain. The optocouplers driving C0-C3 have their emitters wired to CCOM0, while those driving C4-C7 have their emitters wired to CCOM1.
CCOM0 2 C0 O 3 C1 O 4 C2 O 5 C3 O 6 CCOM1 7 C4 O 8 C5 O 9 C6 O 10 C7 O"},{"location":"konamisystem573/#output-bank-b-cn11","title":"Output bank B (CN11)","text":"All outputs are open-drain. The optocouplers driving B0-B3 have their emitters wired to BCOM0, while those driving B4-B7 have their emitters wired to BCOM1.
BCOM0 2 B0 O 3 B1 O 4 B2 O 5 B3 O 6 BCOM1 7 B4 O 8 B5 O 9 B6 O 10 B7 O 11 NC 12 NC"},{"location":"konamisystem573/#output-bank-a-cn12","title":"Output bank A (CN12)","text":"All outputs are open-drain. The optocouplers driving A0-A3 have their emitters wired to ACOM0, while those driving A4-A7 have their emitters wired to ACOM1.
ACOM0 2 A0 O 3 A1 O 4 A2 O 5 A3 O 6 ACOM1 7 A4 O 8 A5 O 9 A6 O 10 A7 O 11 NC 12 NC 13 NC"},{"location":"konamisystem573/#output-bank-d-cn13","title":"Output bank D (CN13)","text":"All outputs are open-drain.
Pin Name Dir 1DCOM 2 D0 O 3 D1 O 4 D2 O 5 D3 O"},{"location":"konamisystem573/#input-bank-cn14","title":"Input bank (CN14)","text":"The pinout of this connector is currently unknown.
"},{"location":"konamisystem573/#rs-232-serial-port-cn15","title":"RS-232 serial port (CN15)","text":"Pin Name Dir 1 TX O 2 RX O 3 GND 4 GND 5 RTS O 6 CTS O 7 DTR O 8 DSR O"},{"location":"konamisystem573/#analog-mp3-audio-output-cn16","title":"Analog MP3 audio output (CN16)","text":"Usually connected to CN12 on the main board. GuitarFreaks routes this output to a separate set of RCA jacks on the front I/O panel instead.
LOUT O 2 AGND 3 AGND 4 ROUT O"},{"location":"konamisystem573/#unknown-cn17","title":"Unknown (CN17)","text":"The pinout of this connector is currently unknown.
"},{"location":"konamisystem573/#i2s-digital-mp3-audio-output-cn18","title":"I2S digital MP3 audio output (CN18)","text":"Pin Name Dir FPGA pin 1 MCLK O 97 2 BCLK O 94 3 SDOUT O 96 4 LRCK O 95 5 ? 6 ?"},{"location":"konamisystem573/#xcs40xl-fpga-pin-mapping","title":"XCS40XL FPGA pin mapping","text":"Pin JTAG FPGA alt. Dir Connected to Usage 2 170 GCK1 IO DRAM Data bus bit 4 3 173 IO DRAM Data bus bit 8 4 176 IO DRAM Data bus bit 9 5 179 IO DRAM Data bus bit 10 6 182 TDI Unused 7 185 TCK Unused 8 194 IO DRAM Data bus bit 3 9 197 IO DRAM Data bus bit 11 10 200 IO DRAM Data bus bit 2 11 203 IO DRAM Data bus bit 12 12 206 Unused 14 212 IO DRAM Data bus bit 1 15 215 IO DRAM Data bus bit 0 16 218 TMS Unused 17 221 IO DRAM Data bus bit 13 19 236 IO DRAM Data bus bit 14 20 239 IO DRAM Data bus bit 15 21 242 IO SRAM Data bus bit 3 22 245 IO SRAM Data bus bit 2 23 248 IO SRAM Data bus bit 4 24 251 IO SRAM Data bus bit 1 27 254 IO SRAM Data bus bit 5 28 257 IO SRAM Data bus bit 0 29 260 IO SRAM Data bus bit 6 30 263 O SRAM Address bus bit 0 31 266 IO SRAM Data bus bit 7 32 269 O SRAM Address bus bit 1 34 284 O SRAM Chip select 35 287 O SRAM Address bus bit 2 36 290 O SRAM Address bus bit 10 37 293 O SRAM Address bus bit 3 39 299 Unused 40 302 O SRAM Output enable 41 305 O SRAM Address bus bit 4 42 308 O SRAM Address bus bit 11 43 311 O SRAM Address bus bit 5 44 320 O SRAM Address bus bit 9 45 323 O SRAM Address bus bit 6 46 326 O SRAM Address bus bit 8 47 329 O SRAM Address bus bit 7 48 332 O SRAM Address bus bit 13 49 335 GCK2 O SRAM Address bus bit 12 55 342 GCK3 O SRAM Write enable 56 345 /HDC O SRAM Address bus bit 14 57 348 O SRAM Address bus bit 16 58 351 O SRAM Address bus bit 15 59 354 O Light bank D Output D3 60 357 LDC O Light bank D Output D2 61 366 I Input bank Unknown input 62 369 I Input bank Unknown input 63 372 I Input bank Unknown input 64 375 I Input bank Unknown input 65 378 67 384 O Light bank D Output D1 68 387 O Light bank D Output D0 69 390 O Light bank ? Unknown output 70 393 O Light bank ? Unknown output 72 396 O Light bank ? Unknown output 73 399 O Light bank ? Unknown output 74 414 O Light bank ? Unknown output 75 417 O Light bank ? Unknown output 76 420 O Light bank ? Unknown output 77 423 /INIT IO CPLD FPGA reset/status 80 426 O Light bank ? Unknown output 81 429 O Light bank ? Unknown output 82 432 O Light bank ? Unknown output 83 435 O Light bank ? Unknown output 84 438 O Light bank ? Unknown output 85 441 I RS-232 transceiver Unknown pin 87 456 O RS-232 transceiver Unknown pin 88 459 I RS-232 transceiver Unknown pin 89 462 O RS-232 transceiver Unknown pin 90 465 I RS-232 transceiver Unknown pin 92 471 93 474 O RS-232 transceiver Unknown pin 94 477 O Audio DAC I2S bit clock (BCLK) 95 480 O Audio DAC I2S frame clock (LRCK) 96 483 O Audio DAC I2S data input (SDIN) 97 492 O Audio DAC I2S master clock (MCLK) 98 495 O ARCnet transceiver Network TX enable? 99 498 O ARCnet transceiver Network TX? 100 501 I ARCnet transceiver Network RX 101 504 102 507 GCK4 104 DONE IO CPLD FPGA configuration status 106 /PROGRAM I CPLD FPGA configuration reset 107 510 D7 IO DS2433 (unpopulated) Unused 1-wire bus (open drain) 108 513 GCK5 Unused 109 516 IO DS2401 1-wire bus (open drain) 110 519 I 573 bus Address bus bit 7 111 525 Unused 112 534 D6 I 573 bus Address bus bit 6 113 537 I 573 bus Address bus bit 5 114 540 I 573 bus Address bus bit 4 115 543 I 573 bus Address bus bit 3 116 546 I 573 bus Address bus bit 2 117 549 I 573 bus Address bus bit 1 119 558 O Unused? 120 561 IO 573 bus Data bus bit 15 122 564 D5 IO 573 bus Data bus bit 14 123 567 IO 573 bus Data bus bit 13 124 576 IO 573 bus Data bus bit 12 125 579 IO 573 bus Data bus bit 11 126 582 IO 573 bus Data bus bit 10 127 585 IO 573 bus Data bus bit 9 128 588 D4 IO 573 bus Data bus bit 8 129 591 IO 573 bus Data bus bit 7 132 594 D3 IO 573 bus Data bus bit 6 133 597 IO 573 bus Data bus bit 5 134 600 IO 573 bus Data bus bit 4 135 603 IO 573 bus Data bus bit 3 136 606 IO 573 bus Data bus bit 2 137 609 IO 573 bus Data bus bit 1 138 618 D2 IO 573 bus Data bus bit 0 139 621 141 624 142 627 I 573 bus I/O board chip select 144 639 145 642 I 573 bus Write strobe (/WR0) 146 645 I 573 bus Read strobe (/RD) 147 648 148 651 I MAS3507D MP3 data request flag (PI19) 149 654 D1 O MAS3507D PIO chip select (/PCS) 150 657 IO MAS3507D I2C SDA 151 666 IO MAS3507D I2C SCL 152 669 O MAS3507D Chip reset (/POR) 153 672 D0/DIN I CPLD FPGA configuration data 154 675 GCK6/DOUT Unused 155 CCLK I CPLD FPGA configuration clock 157 0 TDO Unused 159 2 I MAS3507D Master clock ready flag (WRDY) 160 5 GCK7 I Crystal oscillator 29.45 MHz clock 161 8 I MAS3507D MP3 frame sync flag (PI4) 162 11 I MAS3507D I2S master clock (CLKO/MCLK) 163 14 CS1 O MAS3507D Main clock input (CLKI) 164 17 O MAS3507D MP3 stream bit clock (SIC) 165 26 166 32 O MAS3507D MP3 stream frame clock (SII) 167 35 O MAS3507D MP3 stream data input (SID) 168 38 I MAS3507D MP3 error flag (PI8) 169 41 I MAS3507D I2S bit clock (SOC/BCLK) 171 44 I MAS3507D I2S frame clock (SOI/LRCK) 172 47 I MAS3507D I2S data output (SOD/SDOUT) 174 62 O DRAM Address bus bit 5 175 65 O DRAM Address bus bit 6 176 68 O DRAM Address bus bit 4 177 71 O DRAM Address bus bit 7 178 74 O DRAM Address bus bit 3 179 77 O DRAM Address bus bit 8 180 80 O DRAM Address bus bit 2 181 83 O DRAM Address bus bit 9 184 86 O DRAM Address bus bit 1 185 89 O DRAM Address bus bit 10 186 92 O DRAM Address bus bit 0 187 95 O DRAM Address bus bit 11 188 98 O DRAM Unknown (22J?) pin 189 101 O DRAM Unknown (22J?) pin 190 104 O DRAM Unknown (22H?) pin 191 107 O DRAM Unknown (22H?) pin 193 122 O DRAM Unknown (22G?) pin 194 125 O DRAM 22G CAS 196 128 O DRAM Write strobe 197 131 O DRAM 22G output enable 198 134 O DRAM 22H CAS 199 137 O DRAM 22H output enable 200 140 O DRAM 22J CAS 201 143 O DRAM 22J output enable 202 152 Unused 203 155 Unused 204 158 IO DRAM Data bus bit 7 205 161 IO DRAM Data bus bit 6 206 164 IO DRAM Data bus bit 5 207 167 GCK8 I Crystal oscillator 19.6608 MHz clock The 1-wire pins have external pullup resistors, so enabling the FPGA's built-in pullups is not necessary. The FPGA's M0, M1 and /PWRDWN pins are hardwired to 3.3V.
Present on GX700-PWB(E), GX896-PWB(A)A, GX883-PWB(D) and GE949-PWB(D)A cartridges. All signals use RS-232 voltage levels. Note that DTR and DSR are not wired to the respective SIO1 pins but to the security cartridge I/O pins.
On the GX700-PWB(E) cartridge the signals are referenced to the 573's ground and not isolated. On all other cartridge types, the RS-232 transceiver is powered through an isolated DC-DC module and fully eletrically isolated from the 573; the GND pin is the transceiver's isolated ground.
TX O 2 RX I 3 DTR O 4 DSR I 5 GND"},{"location":"konamisystem573/#control-or-amp-box-connector","title":"\"Control\" or \"amp box\" connector","text":"Present on GX896-PWB(A)A, GX883-PWB(D) and GE949-PWB(D)A cartridges. Unlike the RS-232 connector these are unisolated 5V logic level signals driven through open-drain buffers, with pullup resistors to 5V.
GND 2 CTRL0 O 3 GND 4 CTRL1 O 5 CTRL2 O 6 5V"},{"location":"konamisystem573/#credits-sources-and-links","title":"Credits, sources and links","text":"This document is the result of a joint effort consisting of years' worth of research, brought to you by:
Traced schematics, images, datasheets and additional resources are available in Naoki's 573 repo. Shiz also maintains a general documentation repo for several arcade systems including the 573.
Some information has been aggregated from the following sources:
Huge thanks to the Rhythm Game Cabs Discord server and everyone who provided valuable information about the 573!
"},{"location":"macroblockdecodermdec/","title":"Macroblock Decoder (MDEC)","text":"The MDEC is a JPEG-style Macroblock Decoder, that can decompress pictures (or a series of pictures, for being displayed as a movie).
MDEC I/O Ports MDEC Commands MDEC Decompression MDEC Data Format
"},{"location":"macroblockdecodermdec/#mdec-io-ports","title":"MDEC I/O Ports","text":""},{"location":"macroblockdecodermdec/#1f801820h-mdec0-mdec-commandparameter-register-w","title":"1F801820h - MDEC0 - MDEC Command/Parameter Register (W)","text":" 31-0 Command or Parameters\n 31-0 Macroblock Data (or Garbage if there's no data available)\n 31 Data-Out Fifo Empty (0=No, 1=Empty)\n 30 Data-In Fifo Full (0=No, 1=Full, or Last word received)\n 29 Command Busy (0=Ready, 1=Busy receiving or processing parameters)\n 28 Data-In Request (set when DMA0 enabled and ready to receive data)\n 27 Data-Out Request (set when DMA1 enabled and ready to send data)\n 26-25 Data Output Depth (0=4bit, 1=8bit, 2=24bit, 3=15bit) ;CMD.28-27\n 24 Data Output Signed (0=Unsigned, 1=Signed) ;CMD.26\n 23 Data Output Bit15 (0=Clear, 1=Set) (for 15bit depth only) ;CMD.25\n 22-19 Not used (seems to be always zero)\n 18-16 Current Block (0..3=Y1..Y4, 4=Cr, 5=Cb) (or for mono: always 4=Y)\n 15-0 Number of Parameter Words remaining minus 1 (FFFFh=None) ;CMD.Bit0-15\n 31 Reset MDEC (0=No change, 1=Abort any command, and set status=80040000h)\n 30 Enable Data-In Request (0=Disable, 1=Enable DMA0 and Status.bit28)\n 29 Enable Data-Out Request (0=Disable, 1=Enable DMA1 and Status.bit27)\n 28-0 Unknown/Not used - usually zero\nMDEC decompression uses a lot of DMA channels,
1) DMA3 (CDROM) to send compressed data from CDROM to RAM\n 2) DMA0 (MDEC.In) to send compressed data from RAM to MDEC\n 3) DMA1 (MDEC.Out) to send uncompressed macroblocks from MDEC to RAM\n 4) DMA2 (GPU) to send uncompressed macroblocks from RAM to GPU\n 31-29 Command (1=decode_macroblock)\n 28-27 Data Output Depth (0=4bit, 1=8bit, 2=24bit, 3=15bit) ;STAT.26-25\n 26 Data Output Signed (0=Unsigned, 1=Signed) ;STAT.24\n 25 Data Output Bit15 (0=Clear, 1=Set) (for 15bit depth only) ;STAT.23\n 24-16 Not used (should be zero)\n 15-0 Number of Parameter Words (size of compressed data)\n 31-29 Command (2=set_iqtab)\n 28-1 Not used (should be zero) ;Bit25-28 are copied to STAT.23-26 though\n 0 Color (0=Luminance only, 1=Luminance and Color)\n 31-29 Command (3=set_scale)\n 28-0 Not used (should be zero) ;Bit25-28 are copied to STAT.23-26 though\nThis command has no function. Command bits 25-28 are reflected to Status bits 23-26 as usually. Command bits 0-15 are reflected to Status bits 0-15 (similar as the \"number of parameter words\" for MDEC(1), but without the \"minus 1\" effect, and without actually expecting any parameters).
"},{"location":"macroblockdecodermdec/#mdec47-invalid","title":"MDEC(4..7) - Invalid","text":"These commands act identical as MDEC(0).
"},{"location":"macroblockdecodermdec/#mdec-decompression","title":"MDEC Decompression","text":""},{"location":"macroblockdecodermdec/#decode_colored_macroblock-mdec1-command-at-15bpp-or-24bpp-depth","title":"decode_colored_macroblock ;MDEC(1) command (at 15bpp or 24bpp depth)","text":" rl_decode_block(Crblk,src,iq_uv) ;Cr (low resolution)\n rl_decode_block(Cbblk,src,iq_uv) ;Cb (low resolution)\n rl_decode_block(Yblk,src,iq_y), yuv_to_rgb(0,0) ;Y1 (and upper-left Cr,Cb)\n rl_decode_block(Yblk,src,iq_y), yuv_to_rgb(0,8) ;Y2 (and upper-right Cr,Cb)\n rl_decode_block(Yblk,src,iq_y), yuv_to_rgb(8,0) ;Y3 (and lower-left Cr,Cb)\n rl_decode_block(Yblk,src,iq_y), yuv_to_rgb(8,8) ;Y4 (and lower-right Cr,Cb)\n rl_decode_block(Yblk,src,iq_y), y_to_mono ;Y\n for i=0 to 63, blk[i]=0, next i ;initially zerofill all entries (for skip)\n @@skip:\n n=[src], src=src+2, k=0 ;get first entry, init dest addr k=0\n if n=FE00h then @@skip ;ignore padding (FE00h as first halfword)\n q_scale=(n SHR 10) AND 3Fh ;contains scale value (not \"skip\" value)\n val=signed10bit(n AND 3FFh)*qt[k] ;calc first value (without q_scale/8) (?)\n @@lop:\n if q_scale=0 then val=signed10bit(n AND 3FFh)*2 ;special mode without qt[k]\n val=minmax(val,-400h,+3FFh) ;saturate to signed 11bit range\n val=val*scalezag[i] ;<-- for \"fast_idct_core\" only\n if q_scale>0 then blk[zagzig[k]]=val ;store entry (normal case)\n if q_scale=0 then blk[k]=val ;store entry (special, no zigzag)\n n=[src], src=src+2 ;get next entry (or FE00h end code)\n k=k+((n SHR 10) AND 3Fh)+1 ;skip zerofilled entries\n val=(signed10bit(n AND 3FFh)*qt[k]*q_scale+4)/8 ;calc value for next entry\n if k<=63 then jump @@lop ;should end with n=FE00h (that sets k>63)\n idct_core(blk)\n return (with \"src\" address advanced)\nFast code with only 80 multiplications, works only if the scaletable from MDEC(3) command contains standard values (which is the case for all known PSX games).
src=blk, dst=temp_buffer\n for pass=0 to 1\n for i=0 to 7\n if src[(1..7)*8+i]=0 then ;when src[(1..7)*8+i] are all zero:\n dst[i*8+(0..7)]=src[0*8+i] ;quick fill by src[0*8+i]\n else\n z10=src[0*8+i]+src[4*8+i], z11=src[0*8+i]-src[4*8+i]\n z13=src[2*8+i]+src[6*8+i], z12=src[2*8+i]-src[6*8+i]\n z12=(1.414213562*z12)-z13 ;=sqrt(2)\n tmp0=z10+z13, tmp3=z10-z13, tmp1=z11+z12, tmp2=z11-z12\n z13=src[3*8+i]+src[5*8+i], z10=src[3*8+i]-src[5*8+i]\n z11=src[1*8+i]+src[7*8+i], z12=src[1*8+i]-src[7*8+i]\n z5 =(1.847759065*(z12-z10)) ;=sqrt(2)*scalefactor[2]\n tmp7=z11+z13\n tmp6=(2.613125930*(z10))+z5-tmp7 ;=scalefactor[2]*2\n tmp5=(1.414213562*(z11-z13))-tmp6 ;=sqrt(2)\n tmp4=(1.082392200*(z12))-z5+tmp5 ;=sqrt(2)/scalefactor[2]\n dst[i*8+0]=tmp0+tmp7, dst[i*8+7]=tmp0-tmp7\n dst[i*8+1]=tmp1+tmp6, dst[i*8+6]=tmp1-tmp6\n dst[i*8+2]=tmp2+tmp5, dst[i*8+5]=tmp2-tmp5\n dst[i*8+4]=tmp3+tmp4, dst[i*8+3]=tmp3-tmp4\n endif\n next i\n swap(src,dst)\n next pass\nLow level code with 1024 multiplications, using the scaletable from the MDEC(3) command. Computes dst=src*scaletable (using normal matrix maths, but with \"src\" being diagonally mirrored, ie. the matrices are processed column by column, instead of row by column), repeated with src/dst exchanged.
src=blk, dst=temp_buffer\n for pass=0 to 1\n for x=0 to 7\n for y=0 to 7\n sum=0\n for z=0 to 7\n sum=sum+src[y+z*8]*(scaletable[x+z*8]/8)\n next z\n dst[x+y*8]=(sum+0fffh)/2000h ;<-- or so?\n next y\n next x\n swap(src,dst)\n next pass\n for y=0 to 7\n for x=0 to 7\n R=[Crblk+((x+xx)/2)+((y+yy)/2)*8], B=[Cbblk+((x+xx)/2)+((y+yy)/2)*8]\n G=(-0.3437*B)+(-0.7143*R), R=(1.402*R), B=(1.772*B)\n Y=[Yblk+(x)+(y)*8]\n R=MinMax(-128,127,(Y+R))\n G=MinMax(-128,127,(Y+G))\n B=MinMax(-128,127,(Y+B))\n if unsigned then BGR=BGR xor 808080h ;aka add 128 to the R,G,B values\n dst[(x+xx)+(y+yy)*16]=BGR\n next x\n next y\n for i=0 to 63\n Y=[Yblk+i]\n Y=Y AND 1FFh ;clip to signed 9bit range\n Y=MinMax(-128,127,Y) ;saturate from 9bit to signed 8bit range\n if unsigned then Y=Y xor 80h ;aka add 128 to the Y value\n dst[i]=Y\n next i\n iqtab_core(iq_y,src), src=src+64 ;luminance quant table\n if command_word.bit0=1\n iqtab_core(iq_uv,src), src=src+64 ;color quant table (optional)\n endif\n for i=0 to 63, iq[i]=src[i], next i\n 1.000000000, 1.387039845, 1.306562965, 1.175875602,\n 1.000000000, 0.785694958, 0.541196100, 0.275899379\n 0 ,1 ,5 ,6 ,14,15,27,28,\n 2 ,4 ,7 ,13,16,26,29,42,\n 3 ,8 ,12,17,25,30,41,43,\n 9 ,11,18,24,31,40,44,53,\n 10,19,23,32,39,45,52,54,\n 20,22,33,38,46,51,55,60,\n 21,34,37,47,50,56,59,61,\n 35,36,48,49,57,58,62,63\n for y=0 to 7\n for x=0 to 7\n scalezag[zigzag[x+y*8]] = scalefactor[x] * scalefactor[y] / 8\n next x\n next y\n for i=0 to 63, zagzig[zigzag[i]]=i, next i\nThis command defines the IDCT scale matrix, which should be usually/always:
5A82 5A82 5A82 5A82 5A82 5A82 5A82 5A82\n 7D8A 6A6D 471C 18F8 E707 B8E3 9592 8275\n 7641 30FB CF04 89BE 89BE CF04 30FB 7641\n 6A6D E707 8275 B8E3 471C 7D8A 18F8 9592\n 5A82 A57D A57D 5A82 5A82 A57D A57D 5A82\n 471C 8275 18F8 6A6D 9592 E707 7D8A B8E3\n 30FB 89BE 7641 CF04 CF04 7641 89BE 30FB\n 18F8 B8E3 6A6D 8275 7D8A 9592 471C E707\n +s0 +s0 +s0 +s0 +s0 +s0 +s0 +s0\n +s1 +s3 +s5 +s7 -s7 -s5 -s3 -s1\n +s2 +s6 -s6 -s2 -s2 -s6 +s6 +s2\n +s3 -s7 -s1 -s5 +s5 +s1 +s7 -s3\n +s4 -s4 -s4 +s4 +s4 -s4 -s4 +s4\n +s5 -s1 +s7 +s3 -s3 -s7 +s1 -s5\n +s6 -s2 +s2 -s6 -s6 +s2 -s2 +s6\n +s7 -s5 +s3 -s1 +s1 -s3 +s5 -s7\nEach macroblock consists of six blocks: Two low-resolution blocks with color information (Cr,Cb) and four full-resolution blocks with luminance (grayscale) information (Y1,Y2,Y3,Y4). The color blocks are zoomed from 8x8 to 16x16 pixel size, merged with the luminance blocks, and then converted from YUV to RGB format.
.-----. .-----. .-----. .-----.\n | | | | |Y1|Y2| | |\n | Cr | + | Cb | + |--+--| ----> | RGB |\n | | | | |Y3|Y4| | |\n '-----' '-----' '-----' '-----'\nEach macroblock consist of only one block: with luminance (grayscale) information (Y), the data comes out as such (it isn't converted to RGB).
.--. .--.\n |Y | ----> |Y |\n '--' '--'\nAn (uncompressed) block consists of 64 values, representing 8x8 pixels. The first (upper-left) value is an absolute value (called \"DC\" value), the remaining 63 values are relative to the DC value (called \"AC\" values). After decompression and zig-zag reordering, the data in unfiltered horizontally and vertically (IDCT conversion, ie. the relative \"AC\" values are converted to absolute \"DC\" values).
"},{"location":"macroblockdecodermdec/#str-files","title":".STR Files","text":"PSX Video files are usually having file extension .STR (for \"Streaming\").
"},{"location":"macroblockdecodermdec/#mdec-vs-jpeg","title":"MDEC vs JPEG","text":"The MDEC data format is very similar to the JPEG file format, the main difference is that JPEG uses Huffman compressed blocks, whilst MDEC uses Run-Length (RL) compressed blocks. The (uncompressed) blocks are same as in JPEGs, using the same zigzag ordering, AC to DC conversion, and YUV to RGB conversion (ie. the MDEC hardware can be also used to decompress JPEGs, when handling the file header and huffman decompression by software). Some other differences are that MDEC has only 2 fixed-purpose quant tables, whilst JPEGs \\<can> use up to 4 general-purpose quant tables. Also, JPEGs \\<can> use other color resolutions than the 8x8 color info for 16x16 pixels. Whereas, JPEGs \\<can> do that stuff, but most standard JPEG files aren't actually using 4 quant tables, nor higher color resolution.
"},{"location":"macroblockdecodermdec/#run-length-compressed-blocks","title":"Run-Length compressed Blocks","text":"Within each block the DCT information and RLE compressed data is stored:
DCT ;1 halfword\n RLE,RLE,RLE,etc. ;0..63 halfwords\n EOB ;1 halfword\nDCT data has the quantization factor and the Direct Current (DC) reference.
15-10 Q Quantization factor (6 bits, unsigned)\n 9-0 DC Direct Current reference (10 bits, signed)\n 15-10 LEN Number of zero AC values to be inserted (6 bits, unsigned)\n 9-0 AC Relative AC value (10 bits, signed)\nIndicates the end of a 8x8 pixel block, causing the rest of the block to be padded with zero AC values.
15-0 End-code (Fixed, FE00h)\nData is sent in units of words (or, when using DMA, even in units of 32-words), which is making it neccessary to send some dummy halfwords (unless the compressed data size should match up the transfer unit). The value FE00h can be used as dummy value: When FE00h appears at the begin of a new block, or after the end of block, then it is simply ignored by the hardware (if it occurs elsewhere, then it acts as EOB end code, as described above).
"},{"location":"memorycontrol/","title":"Memory Control","text":"The Memory Control registers are initialized by the BIOS, and, normally software doesn't need to change that settings. Some registers are useful for expansion hardware (allowing to increase the memory size and bus width).
"},{"location":"memorycontrol/#1f801000h-expansion-1-base-address-usually-1f000000h","title":"1F801000h - Expansion 1 Base Address (usually 1F000000h)","text":""},{"location":"memorycontrol/#1f801004h-expansion-2-base-address-usually-1f802000h","title":"1F801004h - Expansion 2 Base Address (usually 1F802000h)","text":" 0-23 Base Address (Read/Write)\n 24-31 Fixed (Read only, always 1Fh)\n 0-3 Write Delay (00h..0Fh=01h..10h Cycles)\n 4-7 Read Delay (00h..0Fh=01h..10h Cycles)\n 8 Recovery Period (0=No, 1=Yes, uses COM0 timings)\n 9 Hold Period (0=No, 1=Yes, uses COM1 timings)\n 10 Floating Period (0=No, 1=Yes, uses COM2 timings)\n 11 Pre-strobe Period (0=No, 1=Yes, uses COM3 timings)\n 12 Data Bus-width (0=8bits, 1=16bits)\n 13 Auto Increment (0=No, 1=Yes)\n 14-15 Unknown (R/W)\n 16-20 Memory Window Size (1 SHL N bytes) (0..1Fh = 1 byte ... 2 gigabytes)\n 21-23 Unknown (always zero)\n 24-27 DMA timing override\n 28 Address error flag. Write 1 to it to clear it.\n 29 DMA timing select (0=use normal timings, 1=use bits 24-27)\n 30 Wide DMA (0=use bit 12, 1=override to full 32 bits)\n 31 Wait (1=wait on external device before being ready)\nbfc00000 lui $t0, 0x0013\nbfc00004 ori $t0, 0x243f\nbfc00008 lui $at, 0x1f80\nbfc0000c sw $t0, 0x1010($at)\nbfc00010 nop\nbfc00014 li $t0, 0x0b88\nbfc00018 lui $at, 0x1f80\nbfc0001c sw $t0, 0x1060($at)\nbfc00020 nop\nWhen using a logic analyzer to monitor the boot sequence, the instruction at bfc00014 is still read using the old timings since reset, and then the instruction at bfc00018 is finally read using the sped up timings.
Reads and writes access times aren't symmetrical, and are each controlled with their own values. By default, EXP1 will be set to 16 cycles when writing, which is the slowest possible. If the programmer wants to write to a flash chip on EXP1, or communicate with a computer, speeding up write access is recommended.
The fastest a port could go would be by setting the lowest 16 bits to zero, which will result in 3 CPU cycles for a single byte access.
!CS always goes active at least one cycle before !WR or !RD go active. The various timing changes are between all the events inside the data read/write waveform. The whole formula for computing the total access time is fairly complex overall, and difficult to properly describe.
The data bus width will influence if the CPU does full 16 bits reads, or only 8 bits. When doing 32 bits operations, the CPU will issue 2 16-bits operations, or 4 8-bits operations, keeping !CS active the whole time, and strobing !WR or !RD accordingly. When doing these sequences, the address bus will also increment automatically between each operation, if the auto-increment bit is active.
This means it is possible to slightly shorten the read time of 4 bytes off the same address by disabling auto-increment, and reading a full word. The CPU will then read 4 bytes off the same address, and place them all into each byte of the loaded register.
The DMA timing override portion will replace the access timing when doing DMA, only if the DMA override flag is set.
The Wide DMA flag will enable full 32 bits DMA operations on the bus, by reusing the low 16-bits address signals as the high 16-bits data. This means that if the CPU is doing Wide DMA reads, the low 16-bits of the address bus will become inputs.
Trying to access addresses that exceed the selected size causes a bus exception. Maximum size would be Expansion 1 = 17h (8MB), BIOS = 16h (4MB), Expansion 2 = 0Dh (8KB), Expansion 3 = 15h (2MB). Trying to select larger sizes would overlap the internal I/O ports, and crash the PSX. The Size bits seem to be ignored for SPU/CDROM. The SPU timings seem to be applied for both the 200h-byte SPU region at 1F801C00h and for the 200h-byte unknown region at 1F801E00h.
"},{"location":"memorycontrol/#1f801020h-com_delay-common_delay-00031125h-or-0000132ch-or-00001325h","title":"1F801020h - COM_DELAY / COMMON_DELAY (00031125h or 0000132Ch or 00001325h)","text":" 0-3 COM0 - Recovery period cycles\n 4-7 COM1 - Hold period cycles\n 8-11 COM2 - Floating release cycles\n 12-15 COM3 - Strobe active-going edge delay\n 16-31 Unknown/unused (read: always 0000h)\n 1ST=0, SEQ=0, MIN=0\n IF Use_COM0 THEN 1ST=1ST+COM0-1, SEQ=SEQ+COM0-1\n IF Use_COM2 THEN 1ST=1ST+COM2, SEQ=SEQ+COM2\n IF Use_COM3 THEN MIN=COM3\n IF 1ST<6 THEN 1ST=1ST+1 ;(somewhat like so)\n 1ST=1ST+AccessTime+2, SEQ=SEQ+AccessTime+2\n IF 1ST<(MIN+6) THEN 1ST=(MIN+6)\n IF SEQ<(MIN+2) THEN SEQ=(MIN+2)\n 0-2 Unknown (no effect)\n 3 Crashes when zero (except PU-7 and EARLY-PU-8, which <do> set bit3=0)\n 4-6 Unknown (no effect)\n 7 Delay on simultaneous CODE+DATA fetch from RAM (0=None, 1=One Cycle)\n 8 Unknown (no effect) (should be set for 8MB, cleared for 2MB)\n 9-11 Define 8MB Memory Window (first 8MB of KUSEG,KSEG0,KSEG1)\n 12-15 Unknown (no effect)\n 16-31 Unknown (Garbage)\n 0 = 1MB Memory + 7MB Locked\n 1 = 4MB Memory + 4MB Locked\n 2 = 1MB Memory + 1MB HighZ + 6MB Locked\n 3 = 4MB Memory + 4MB HighZ\n 4 = 2MB Memory + 6MB Locked ;<--- would be correct for PSX\n 5 = 8MB Memory ;<--- default by BIOS init\n 6 = 2MB Memory + 2MB HighZ + 4MB Locked ;<-- HighZ = Second /RAS\n 7 = 8MB Memory\n 0-2 Unknown (Read/Write) (R/W)\n 3 Scratchpad Enable 1 (0=Disable, 1=Enable when Bit7 is set, too) (R/W)\n 4-5 Unknown (Read/Write) (R/W)\n 6 Unknown (read=always zero) (R) or (W) or unused..?\n 7 Scratchpad Enable 2 (0=Disable, 1=Enable when Bit3 is set, too) (R/W)\n 8 Unknown (R/W)\n 9 Crash (0=Normal, 1=Crash if code-cache enabled) (R/W)\n 10 Unknown (read=always zero) (R) or (W) or unused..?\n 11 Code-Cache Enable (0=Disable, 1=Enable) (R/W)\n 12-31 Unknown (R/W)\n Init Cache Step 1:\n [FFFE0130h]=00000804h, then set cop0_sr=00010000h, then\n zerofill each FOURTH word at [0000..0FFFh], then set cop0_sr=zero.\n Init Cache Step 2:\n [FFFE0130h]=00000800h, then set cop0_sr=00010000h, then\n zerofill ALL words at [0000h..0FFFh], then set cop0_sr=zero.\n Finish Initialization:\n read 8 times 32bit from [A0000000h], then set [FFFE0130h]=0001E988h\nBIU = (BIU & ~0x0483) | 0x0804. With the normal BIU value of 0x001e988, this results in writing the value 0x001e90c - Then, it writes 0x00010000 to cop0's Status register. This order is important, as it would otherwise not take the BIU change, and still write to main ram instead of the i-cache region. - At this point, it proceeds with the step 1 of the flushcache procedure of clearing every fourth word. - Finally, it restores both the original value of the BIU and Status registers it had previously saved. A usable version of this code is available.
Note: FFFE0130h is described in LSI's \"L64360\" datasheet, chapter 14 (and probably also in their LR33300/LR33310 datasheet, if it were available in internet).
"},{"location":"memorymap/","title":"Memory Map","text":""},{"location":"memorymap/#memory-map_1","title":"Memory Map","text":" KUSEG KSEG0 KSEG1\n 00000000h 80000000h A0000000h 2048K Main RAM (first 64K reserved for BIOS)\n 1F000000h 9F000000h BF000000h 8192K Expansion Region 1 (ROM/RAM)\n 1F800000h 9F800000h -- 1K Scratchpad (D-Cache used as Fast RAM)\n 1F801000h 9F801000h BF801000h 4K I/O Ports\n 1F802000h 9F802000h BF802000h 8K Expansion Region 2 (I/O Ports)\n 1FA00000h 9FA00000h BFA00000h 2048K Expansion Region 3 (SRAM BIOS region for DTL cards)\n 1FC00000h 9FC00000h BFC00000h 512K BIOS ROM (Kernel) (4096K max)\n FFFE0000h (in KSEG2) 0.5K Internal CPU control registers (Cache Control)\n 1024K VRAM (Framebuffers, Textures, Palettes) (with 2KB Texture Cache)\n 512K Sound RAM (Capture Buffers, ADPCM Data, Reverb Workspace)\n 0.5K CDROM controller RAM (see CDROM Test commands)\n 16.5K CDROM controller ROM (Firmware and Bootstrap for MC68HC05 cpu)\n 32K CDROM Buffer (IC303) (32Kx8) (BUG: only two sectors accessible?)\n 128K External Memory Card(s) (EEPROMs)\n Address Name i-Cache Write-Queue\n 00000000h KUSEG Yes Yes\n 80000000h KSEG0 Yes Yes\n A0000000h KSEG1 No No\n C0000000h KSEG2 (No code) No\nThe i-Cache can hold 4096 bytes, or 1024 instructions. It is only active in the cached regions (KUSEG and KSEG0). There are reportedly some restrictions... not sure there... eventually it is using the LSBs of the address as cache-line number... so, for example, it couldn't simultaneously memorize opcodes at BOTH address 80001234h, AND at address 800F1234h (?)
"},{"location":"memorymap/#scratchpad","title":"Scratchpad","text":"MIPS CPUs usually have a d-Cache, but, in the PSX, Sony has assigned it as what's referenced as the \"Scratchpad\", mapped to a fixed memory location at 1F800000h..1F8003FFh, ie. it's used as Fast RAM, rather than as cache. There \\<might> be a way to disable that behavior (via Port FFFE0130h or so), but, the Kernel is accessing I/O ports via KUSEG, so activating Data Cache would cause the Kernel to access cached I/O ports. The purpose of the scratchpad is to have a more flexible cache system available to the programmer. Neither the kernel nor the Sony libraries will try to make use of it, so it is therefore completely up for grabs to the programmer. A good example would be if you were to write a piece of code that's doing a lot of CRC computation, to use the 1KB scratchpad to initially load the CRC lookup tables, which incidentally, is exactly 1KB large. Doing this will relieve SDRAM page changes overhead while reading the data to checksum linearly, while also keeping the whole CRC code in the i-Cache, hence being more optimal than what you'd get with an automatic d-Cache system.
"},{"location":"memorymap/#memory-mirrors","title":"Memory Mirrors","text":"As described above, the 512Mbyte KUSEG, KSEG0, and KSEG1 regions are mirrors of each other. Additional mirrors within these 512MB regions are:
2MB RAM can be mirrored to the first 8MB (strangely, enabled by default)\n 512K BIOS ROM can be mirrored to the last 4MB (disabled by default)\n Expansion hardware (if any) may be mirrored within expansion region\n The seven DMA Control Registers at 1F8010x8h are mirrored to 1F8010xCh\n Memory Error ------> Misalignments\n (and probably also KSEG access in User mode)\n Bus Error ------> Unused Memory Regions (including Gaps in I/O Region)\n (unless RAM/BIOS/Expansion mirrors are mapped to \"unused\" area)\nThe MIPS CPU has a 4-words deep pass-through write queue, in order to relieve some bus contention when writing to memory. If reading the same memory location that just got written into the write queue, it will first be flushed before being read back from memory. It is important to realize that the write queue's mechanism is only viable for normal memory attached to the main CPU, and that any hardware register state machine will get messed up by it. The typical example is the typical JEDEC standard to access flash, which usually does the following sequence to read the ID of a flash chip:
base[0xAAA] = 0xAA;\nbase[0x555] = 0x55;\nbase[0xAAA] = 0x90;\nuint8_t mnfctrID = base[0x000];\nuint8_t deviceId = base[0x002];\nIn this example above, if base is located in a memory segment that has the write queue enabled, even if the low level assembly code will do the first 3 stores before doing 2 loads, the physical signals sent to that device through the CPU bus will be seen in the sequence:
store(0xaaa, 0xaa)\nload(0x000)\nstore(0x555, 0x55)\nload(0x002)\nstore(0xaaa, 0x90)\nTherefore, using KSEG1 that disables the write queue is the only way to ensure that the operations are done in the proper way.
The above is valid for most of the hardware connected to the main CPU, such as the CDROM controller, exp1, exp2, the SPU, or the GPU. Therefore, using BF80180xh to access the CDROM registers is more correct than using 1F80180xh.
It is noteworthy that the Sony code will still incorrectly use KUSEG as the memory map for all hardware registers, and they then spend a lot of time writing 4 dummy values somewhere, in order to ensure the write queue has been flushed.
The SN debugger in contrast is properly using the KSEG1 memory map for all the hardware registers, nullifying the need to flush the write queue when accessing it.
It's also noteworthy that doing ANY KSEG1 access (read OR write) will automatically stall the CPU in order to flush the whole write queue before proceeding with the operation. Therefore, all BIOS ROM operations will naturally and effectively have the write queue disabled, as this code requires the CPU to read from KSEG1 constantly.
This also means that if using KUSEG for the hardware registers, another method to flush the write queue, albeit potentially slightly less efficient, would be to simply read the first byte located at BFC00000h. The latter is what is effectively described as the official method to flush the write queue in the MIPS handbook. This could be potentially useful to flush the write queue all at once, instead of flushing it word by word.
"},{"location":"memorymap/#more-memory-info","title":"More Memory Info","text":"For Info on Exception vectors, Unused/Garbage memory locations, I/O Ports, Expansion ROM Headers, and Memory Waitstate Control, etc. see: I/O Map Memory Control EXP1 Expansion ROM Header BIOS Memory Map BIOS Memory Allocation COP0 - Exception Handling Unpredictable Things
"},{"location":"pinouts/","title":"Pinouts","text":""},{"location":"pinouts/#external-connectors","title":"External Connectors","text":"Pinouts - Controller Ports and Memory-Card Ports Pinouts - Audio, Video, Power, Expansion Ports Pinouts - SIO Pinouts
"},{"location":"pinouts/#internal-pinouts","title":"Internal Pinouts","text":"Pinouts - Chipset Summary Pinouts - CPU Pinouts Pinouts - GPU Pinouts (for old 160-pin GPU) Pinouts - GPU Pinouts (for new 208-pin GPU) Pinouts - SPU Pinouts Pinouts - DRV Pinouts Pinouts - VCD Pinouts Pinouts - HC05 Pinouts Pinouts - MEM Pinouts Pinouts - CLK Pinouts Pinouts - PWR Pinouts Pinouts - Component List and Chipset Pin-Outs for Digital Joypad, SCPH-1080 Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-1150 Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-1200 Pinouts - Component List and Chipset Pin-Outs for Analog Joypad, SCPH-110 Pinouts - Component List and Chipset Pin-Outs for Namco Lightgun, NPC-103 Pinouts - Component List and Chipset Pin-Outs for Multitap, SCPH-1070 Pinouts - Memory Cards
"},{"location":"pinouts/#modsupgrades","title":"Mods/Upgrades","text":"Mods - Nocash PSX-XBOO Upload Mods - PAL/NTSC Color Mods
"},{"location":"pinouts/#pinouts-controller-ports-and-memory-card-ports","title":"Pinouts - Controller Ports and Memory-Card Ports","text":""},{"location":"pinouts/#controller-ports-and-memory-card-ports","title":"Controller Ports and Memory-Card Ports","text":" _______________________\nMemory card slot: | 9 7 6 | 5 4 3 | 2 1 |\n |_=_=_=_|_=_=_=_|__=_=__|\n _______________________\n | 9 8 7 | 6 5 4 | 3 2 1 |\nController port: | * * * | * * * | * * * |\n '\\______|_______|______/'\nDAT/MISO RX Serial data from device 2 Out CMD/MOSI TX Serial data to device 3 +7.5V Supply for rumble motors 4 GND Ground 5 +3.5V Supply for main logic 6 Out /CSn DTRn Port select 7 Out SCK SCK Serial data clock 8 In /IRQ /IRQ10 Lightgun IRQ (controller only) 9 In /ACK DSR Data acknowledge IRQ /CSn are two separate signals (/CS1 for controller/memory card port 1, /CS2 for port 2). All other signals are exactly the same on all four connectors (with the memory card slots lacking the /IRQ pin and shield).
"},{"location":"pinouts/#irq-pin","title":"/IRQ pin","text":"Most or all controllers leave pin 8 unused, the pin can be used as lightpen input (not sure if the CPU is automatically latching a timer somewhere?), if there's no auto-latched timer, then the interrupt would be required to be handled as soon as possible; ie. don't disable interrupts, and don't \"halt\" the CPU for longer periods (as far as I understood, the GTE can halt the CPU when trying to read results of incomplete operations; to avoid that, one could wait by software, eg. inserting NOPs, before reading GTE results...?) (Some (or maybe all?) existing psx lightguns are reportedly connected to the Video output on the Multiout port for determining the current cathode ray position though).
"},{"location":"pinouts/#pinouts-audio-video-power-expansion-ports","title":"Pinouts - Audio, Video, Power, Expansion Ports","text":""},{"location":"pinouts/#av-multi-out-audiovideo-port","title":"AV Multi Out (Audio/Video Port)","text":" 1 RGB-Video Green\n 2 RGB-Video Red\n 3 Supply +5.0V (eg. supply for external RF adaptor)\n 4 RGB-Video Blue\n 5 Supply Ground\n 6 S-Video C (chrominance)\n 7 Composite Video (yellow cinch)\n 8 S-Video Y (luminance) ____________________________\n 9 Audio Left (white cinch) | |\n 10 Audio Left Ground | 12 11 10 9 8 7 6 5 4 3 2 1 |\n 11 Audio Right (red cinch) |____________________________|\n 12 Audio Right Ground\n Shield Video Ground\nThis port exists only on older PSX boards (not on newer PSX boards, and not on PSone boards). The parallel port is used by various third-party unlicensed cheat cartridges and VCD player addons, as well as by the PSIO optical drive emulator (see below).
________\n | | Console Rear View\n GND ==| 1 35 |== GND .-------------------------.\n /RESET =| 2 36 |= DACK5 |1 2 3 ... ... 32 33 34|\n DREQ5 =| 3 37 |= /IRQ10 |35 36 37 ... ... 66 67 68|\n /CS0 =| 4 38 |= /WR1 |__.-------------------.__|\n(SBEN)GND =| 5 39 |= GND(CS2)\n D0 =| 6 40 |= D1\n D2 =| 7 41 |= D3\n D4 =| 8 42 |= D5\n D6 =| 9 43 |= D7\n D8 =|10 44 |= D9\n D10 =|11 45 |= D11\n D12 =|12 46 |= D13\n D14 =|13 47 |= D15\n A0 =|14 48 |= A1\n A2 =|15 49 |= A3\n GND =|16 50 |= GND\n +3.5V ==|17 51 |== +3.5V\n +7.5V ==|18 52 |== +7.5V\n GND =|19 53 |= GND\n A4 =|20 54 |= A5\n A6 =|21 55 |= A7\n A8 =|22 56 |= A9\n A10 =|23 57 |= A11\n A12 =|24 58 |= A13\n A14 =|25 59 |= A15\n A16 =|26 60 |= A17\n A18 =|27 61 |= A19\n A20 =|28 62 |= A21\n A22 =|29 63 |= A23\n /RD =|30 64 |= /WR0\n(/IRQ2)NC =|31 65 |= NC(/CS5)\n SYSCK =|32 66 |= LRCK\n BCLK =|33 67 |= SDIN\n GND ==|34 68 |== GND\n |________|\nThe PSX contains an internal power supply, however, like the PSone, it's only having a \"Standby\" button, which merely disconnects 3.5V and 7.9V from the mainboard. The actual power supply remains powered, and wastes energy day and night, thanks Sony!
"},{"location":"pinouts/#external-power-supply-psone","title":"External Power Supply (PSone)","text":" Inner +7.5V DC 2.0A (inside diameter 0.8mm)\n Outer GND (outside diameter 5.0mm)\nThat port exists only on original Playstation (not on the PSone). The shape of the Serial Port is identical to the 12pin Multiout (audio/video) port, but with only 8pins.
1 SIO1 In RXD receive data (from remote TXD)\n 2 SIO2 - VCC +3.5VDC (supply, eg. for voltage conversion)\n 3 SIO3 In DSR (from remote DTR) _________________\n 4 SIO4 Out TXD transmit data (to remote RXD) | |\n 5 SIO5 In CTS clear to send (from remote RTS) | 8 7 6 5 4 3 2 1 |\n 6 SIO6 Out DTR (to remote DSR) |_________________|\n 7 SIO7 - GND Ground (supply, eg. for voltage conversion)\n 8 SIO8 Out RTS request to send (to remote CTS)\n Shield GND Ground (to/from remote GND)\nThe PSone doesn't have an external serial connector, however, easy to use soldering points for serial port signals are found as cluster of 5 soldering points (below CPU pin52), and a single soldering point (below CPU pin100), arranged like so (on PM-41 boards) (might be different on PM-41(2) boards):
CPU70.RTS\n CPU71.CTS CPU74.TxD\n CPU72.DTR CPU75.RxD CPU73.DSR\nThe PSX serial circuit basically consists of a few transistors, diodes, and resistors. The relevant part is that most of the signals are inverted - compared with RS232 signals, the CPU uses normal high/low levels (of course with 0V and 3.5V levels, not -12V and +12V), and the signals at the serial port socket are inverted. Ie. if you want to built a RS232 adaptor, you must either externally undo the inversion, or, disconnect the transistors, and wire your circuit directly to the CPU signals.
SIO8 SIO6 SIO4 SIO1 SIO3 SIO5 SIO2 SIO7---GND\n | | | | | | |\n FB112 FB114 FB116 FB115 FBnnn FBnnn o--L102-------3.5V\n | | | | | |\n | | o-------|-------|-------|--------diode-------GND\n | | | o-------|-------|--------diode-------GND\n | | | | o-------|--------diode-------GND\n | | | | | o--------diode-------GND\n | | | | | |\n | | | o-------|-------|--------[1K]--------3.5V\n | | | | o-------|--------[1K]--------3.5V\n [22] [22] [22] [22] | o--------[1K]--------3.5V\n | | | | | |\n Q105-----|-------|-------|-------|-------|--------------------GND\n | Q105-----|-------|-------|-------|--------------------GND\n | | | | Q106-----|--------------------GND\n | | | | | Q106------------------GND\n | | | | | |\n | | | | o-------|--------[470]-------3.5V\n | | | | | o--------[470]-------3.5V\n | | | | | |\n RTS DTR TxD RxD DSR CTS\n CPU70 CPU72 CPU74 CPU75 CPU73 CPU71 <-- CPU Pin Numbers\n out out out in in in\nThe PSX serial port uses 0V/3.5V logic, whilst RS232 uses -5V/+5V...-15V/+15V logic. An example circuit for converting the logic levels would be:
PSX.VCC--+||--PSX.GND PSX.GND----DSUB.5.GND----DSUB.SHIELD DSUB.1,9----NC\n ______ ______\n ,-----------||+-|1 16|-------PSX.VCC ,-----------||+-|1 16|-------PSX.VCC\n | PSX.GND---||+-|2 15|-------PSX.GND | PSX.GND---||+-|2 15|-------PSX.GND\n '---------------|3 14|----DSUB.3.TXD '---------------|3 14|--- N/A\n ,---+||--|4 13|----DSUB.2.RXD ,---+||--|4 13|--- N/A\n '--------|5 12|-------PSX.RXD '--------|5 12|--- N/A\n PSX.GND--+||--|6 11|-------PSX.TXD PSX.GND--+||--|6 11|--- N/A\n DSUB.7.RTS----|7 10|--o<|--PSX.RTS DSUB.4.DTR----|7 10|--o<|--PSX.DTR\n DSUB.8.CTS----|8 9|--|>o--PSX.CTS DSUB.6.DSR----|8 9|--|>o--PSX.DSR\n |______| |______|\n Board Expl.\n PU-7 PSX, with AV multiout+cinch+svideo, GPU in two chips (160+64pins)\n PU-8 PSX, with AV multiout+cinch, four 8bit Main RAM chips\n EARLY-PU-8: \"PU-8 1-658-467-11, N4\" --> old chipset, resembles PU-7\n LATE-PU-8: \"PU-8 1-658-467-22, N6\" --> new chipset, other as PU-7\n PU-9 PSX, without SCPH-number (just sticker saying \"NOT FOR SALE, SONY)\n PU-16 PSX, with extra Video CD daughterboard (for SCPH-5903)\n PU-18 PSX, with AV multiout only, single 32bit Main RAM (instead 4x8bit)\n PU-20 PSX, unknown if/how it differs from PU-18\n PU-22 PSX, unknown if/how it differs from PU-18\n PU-23 PSX, with serial port, but without expansion port\n PM-41 PSone, older PSone, for GPU/SPU with RAM on-board (see revisions)\n PM-41(2) PSone, newer PSone, for GPU/SPU with RAM on-chip\n PM-41, 1-679-335-21 PSone with incomplete RGB signals on multiout port\n PM-41, 1-679-335-51 PSone with complete RGB signals on multiout port\n IC103 - 208pin - \"SONY CXD8530BQ\" ;seen on PU-7 board\n IC103 - 208pin - \"SONY CXD8530CQ\" ;seen on PU-7 and PU-8 boards\n IC103 - 208pin - \"SONY CXD8606Q\" ;seen in PU-18 schematic\n IC103 - 208pin - \"SONY CXD8606AQ\" ;seen on PU-xx? board\n IC103 - 208pin - \"SONY CXD8606BQ\" ;seen on PM-41, PU-23, PU-20 boards\n IC103 - 208pin - \"SONY CXD8606CQ\" ;seen on PM-41 board, too\n IC203 - 160pin - \"SONY CXD8514Q\" ;seen on PU-7 and EARLY-PU-8 boards\n IC203 - 208pin - \"SONY CXD8561Q\" ;seen on LATE-PU-8 board\n IC203 - 208pin - \"SONY CXD8561BQ\" ;seen on PU-18, PU-20 boards\n IC203 - 208pin - \"SONY CXD8561CQ\" ;seen on PM-41 board\n IC203 - 208pin - \"SONY CXD9500Q\" ;with on-chip RAM ;for PM-41(2) board\n IC21 - 208pin - \"SONY CXD8538Q\" ;seen on GP-11 (namco System 11) boards\n IC103 - 208pin - \"SONY CXD8654Q\" ;seen on GP-15 (namco System 12) boards\n IC308 - 100pin - \"SONY CXD2922Q\" (SPU) ;PU-7 and EARLY-PU-8\n IC308 - 100pin - \"SONY CXD2922BQ\"(SPU) ;EARLY-PU-8\n IC308 - 100pin - \"SONY CXD2925Q\" (SPU) ;LATE-PU-8, PU-18, PU-20\n IC732 - 208pin - \"SONY CXD2938Q\" (SPU+CDROM) ;PSone/PM-41 Board\n IC732 - 176pin - \"SONY CXD2941R\" (SPU+CDROM+SPU_RAM) ;PSone/PM-41(2) Board\n IC402 - 24pin - \"AKM AK4309VM\" (Serial 2x16bit DAC);older boards only\n IC405 - 8pin - \"NJM2100E (TE2)\" Audio Amplifier ;PU-8 and PU-22 boards\n IC405 - 14pin - \"NJM2174\" Audio Amplifier with Mute ;later boards\n IC106/IC107/IC108/IC109 - NEC 424805AL-A60 (28pin, 512Kx8) (PU-8 board)\n IC106 - \"Samsung K4Q153212M-JC60\" (70pin, 512Kx32) (newer boards)\n IC106 - \"Toshiba T7X16 (70pin, 512Kx32) (newer boards, too)\n IC201 - 64pin NEC uPD482445LGW-A70-S ;VRAM ;\\on PU-7 and EARLY-PU-8 board\n IC202 - 64pin NEC uPD482445LGW-A70-S ;VRAM ;/split into 2 chips !\n IC201 - 64pin SEC KM4216Y256G-60 ;VRAM ;\\on other PU-7 board\n IC202 - 64pin SEC KM4216Y256G-60 ;VRAM ;/split into 2 chips !\n IC201 - 100pin - Samsung KM4132G271BQ-10 (128Kx32x2) ;-on later boards\n IC201 - 100pin - Samsung K4G163222A-PC70 (256Kx32x2) ;-on PM-41\n IC310 - 40pin - \"TOSHIBA TC51V4260DJ-70\" ;seen on PU-8 board\n IC310 - 40pin - EliteMT M11B416256A-35J (256K x 16bit)\n IC102 - 40pin - \"SONY ...\" ;seen on PU-7 & early-PU-8 board (40pin!)\n IC102 - 44pin - \"SONY M538032E-02\" ;seen on PU-16 (video CD, 1Mbyte BIOS)\n IC102 - 32pin - \"SONY M534031C-25\" ;seen on later-PU-8 board\n IC102 - 32pin - \"SONY 2022\" ;seen on PU-8 (1-658-467-23)\n IC102 - 32pin - \"SONY 2030\" ;seen on PU-18 board\n IC102 - 32pin - \"SONY M534031E-47\" ;seen on PM-41 board and PM-41(2)\n IC102 - 32pin - \"SONY M27V401D-41\" ;seen on PM-41 board, too\n X101 - 4pin - \"67.737\" (NTSC, presumably) ;PU-7 .. PU-20\n X201 - 2pin - \"17.734\" (PAL) or \"14.318\" (NTSC) ;PU-22 .. PM-41(2)\n IC204 - 8pin - \"2294A\" (PAL) or <unknown?> (NTSC) ;PU-22 .. PM-41(2)\n IC601 - 3pin - \"78M05\" or \"78005\" ;used in PSone\n IC606 16pin/10mm \"TL594CD\" (alternately to IC607) ;seen on PM-41 board\n IC607 16pin/5mm \"T594\" (alternately to IC606) ;seen on PM-41 board, too\n IC002 - 8pin - <not installed> (would be alternately to IC003) ;\\on PSone\n IC003 - 5pin - <usually installed> ;/\n IC101 - 5pin - M51957B (Reset Generator) (on PSX-power supply boards)\n U42 80pin SUB-CPU (CXP82300) with piggyback EPROM ;DTL-H2000\n IC304 80pin SUB-CPU (MC68HC05L16) 80pin package ;PU-7 and EARLY-PU-8\n IC304 52pin SUB-CPU (MC68HC05G6) 52pin package ;LATE-PU-8 and up\n IC305 - 100pin SONY CXD1199BQ (Decoder/FIFO) ;PU-7\n IC305 - 100pin SONY CXD1815Q (Decoder/FIFO) ;PU-8, PU-18\n IC309 - 100pin SONY CXD2516Q (Signal Processor) ;PU-7 (100pin!)\n IC309 - 80pin SONY CXD2510Q (Signal Processor) ;PU-8 and DTL-H2510\n IC702 - 48pin SONY CXA1782BR (Servo Amplifier) ;PU-7, PU-8\n IC101 - 100pin SONY CXD2515Q (=CXD2510Q+CXA1782BR) ;DTL-H2010\n IC701 - 100pin SONY CXD2545Q (=CXD2510Q+CXA1782BR) ;PU-18\n IC720 - 144pin SONY CXD1817R (=CXD2545Q+CXD1815Q) ;PU-20\n IC102 - 28pin - \"BA6297AFP\" ;seen on DTL-H2010 drives\n IC704 - 28pin - \"BA6398FP\" ;seen on PU-7\n IC722 - 28pin - \"BA6397FP\" ;seen on late PU-8\n IC722 - 28pin - \"BA5947FP\" ;seen on PM-41 and various boards\n IC722 - 28pin - \"Panasonic AN8732SB\" ;seen on PM-41 board\n ICxxx - 20pin SONY CXA1571N (RF Amplifier) (on DTL-H2010 drives)\n IC703 - 20pin SONY CXA1791N (RF Amplifier) (on PU-18 boards)\n IC723 - 20pin SONY CXA2575N-T4 (RF Matrix Amplifier) (on PU-22 .. PM-41(2))\n IC207 64pin \"SONY CXD2923AR\" VRAM Data to Analog RGB ;\\oldest\n IC501 24pin \"SONY CXA1645M\" Analog RGB to Composite ;/\n IC202 44pin \"Philips TDA8771H\" Digital RGB to Analog RGB ;\\old boards\n IC202 44pin \"Motorola MC141685FT\" Digital RGB to Analog RGB ;/\n IC? 48pin \"H7240AKV\" 24bit RGB to Analog+Composite ;-SCPH-7001?\n IC502 48pin \"SONY CXA2106R-T4\" 24bit RGB to Analog+Composite ;-newer boards\n CDROM Drive: \"KSM-440BAM\" ;seen used with PM-41 board\n IC602 5pin \"L/\\1B\" or \"<symbol> 3DR\"\n U? 24pin \"9625H, CFS8121\" ;SCPH-1080, digital pad (alternate?)\n U? ?pin \"SC438001\" ;SCPH-1080, digital pad (alternate?)\n U? 32pin \"(M), SC401800\" ;SCPH-1080, digital pad\n U? 32pin \"(M), SC442116\" ;SCPH-xxxx, mouse\n IC? 64pin \"SONY CXD103, -166Q\" ;SCPH-1070, multitap\n U1 42pin \"SD657, 9702K3006\" ;SCPH-1150, analog pad, single motor\n U1 42pin \"SD657, 9726K3002\" ;SCPH-1180, analog pad, without motor\n U1 44pin \"SONY CXD8771Q\" ;SCPH-1200, analog pad, two motors (PSX)\n U1 44pin \"SD707, 039 107\" ;SCPH-110, analog pad, two motors (PSone)\n U1 44pin \"SD787A\" ;SCPH-xxx, analog pad, two motors (PS2?)\n U? 64pin \"SONY CXD8732AQ\" ;SCPH-1020, memory card, on-chip FLASH\n U? XXpin other chips ;SCPH-xxxx, memory card, external FLASH\n U1 44pin \"NAMCO103P\" ;NPC-103, namco lightgun\nVDD 53 VDD 105 VDD 157 VDD 2 VDD 54 VDD 106 VDD 158 VDD 3 CRYSTALN 55 RAM.A11 107 SBUS.D0 159 TIMER1.CLK 4 CRYSTALP 56 RAM.A10 108 SBUS.D1 160 TIMER0.CLK 5 RAM.D31 57 RAM.A9 109 SBUS.D2 161 GPU.D0 6 RAM.D30 58 RAM.A8 110 SBUS.D3 162 GPU.D1 7 RAM.D29 59 RAM.A7 111 SBUS.D4 163 GPU.D2 8 RAM.D28 60 RAM.A6 112 SBUS.D5 164 GPU.D3 9 RAM.D27 61 RAM.A5 113 SBUS.D6 165 GPU.D4 10 RAM.D26 62 RAM.A4 114 SBUS.D7 166 GPU.D5 11 RAM.D25 63 RAM.A3 115 SBUS.D8 167 GPU.D6 12 RAM.D24 64 RAM.A2 116 SBUS.D9 168 GPU.D7 13 RAM.D23 65 GND 117 GND 169 GPU.D8 14 VDD 66 VDD 118 VDD 170 GND 15 GND 67 RAM.A1 119 SBUS.D10 171 VDD 16 RAM.D22 68 RAM.A0 120 SBUS.D11 172 GPU.D9 17 RAM.D21 69 /RC_NET 121 SBUS.D12 173 GPU.D10 18 RAM.D20 70 SIO1./RTS 122 SBUS.D13 174 GPU.D11 19 RAM.D19 71 SIO1./CTS 123 SBUS.D14 175 GPU.D12 20 RAM.D18 72 SIO1./DTR 124 SBUS.D15 176 GPU.D13 21 RAM.D17 73 SIO1./DSR 125 SBUS.A0 177 GPU.D14 22 RAM.D16 74 SIO1.TX 126 SBUS.A1 178 GPU.D15 23 RAM.D15 75 SIO1.RX 127 SBUS.A2 179 GPU.D16 24 RAM.D14 76 /EXT_RESET 128 SBUS.A3 180 GPU.D17 25 RAM.D13 77 SIO0./DTR2 129 SBUS.A4 181 GPU.D18 26 VDD 78 GND 130 GND 182 GND 27 GND 79 VDD 131 VDD 183 VDD 28 RAM.D12 80 SIO0./DTR1 132 SBUS.A5 184 GPU.D19 29 RAM.D11 81 SIO0./SCK 133 SBUS.A6 185 GPU.D20 30 RAM.D10 82 SIO0./DSR 134 SBUS.A7 186 GPU.D21 31 RAM.D9 83 SIO0.TX 135 SBUS.A8 187 GPU.D22 32 RAM.D8 84 SIO0.RX 136 SBUS.A9 188 GPU.D23 33 RAM.D7 85 SBUS.DACK5_PIO 137 SBUS.A10 189 GPU.D24 34 RAM.D6 86 SBUS.DREQ5_PIO 138 SBUS.A11 190 GPU.D25 35 RAM.D5 87 SBUS.DACK4_SPU 139 SBUS.A12 191 GPU.D26 36 RAM.D4 88 SBUS.DREQ4_SPU 140 SBUS.A13 192 GPU.D27 37 RAM.D3 89 /IRQ10_PIO 141 SBUS.A14 193 GPU.D28 38 VDD 90 /IRQ9_SPU 142 SBUS.A15 194 GPU.D29 39 GND 91 GND 143 GND 195 GND 40 RAM.D2 92 VDD 144 VDD 196 VDD 41 RAM.D1 93 /CSHTST 145 SBUS.A16 197 GPU.D30 42 RAM.D0 94 /IRQ2_CDROM 146 SBUS.A17 198 GPU.D31 43 RAM./WE 95 SBUS./CS5_CDROM 147 SBUS.A18 199 /IRQ0 44 RAM./RAS1 96 SBUS./CS4_SPU 148 SBUS.A19 200 GPU.DREQ2 45 RAM./RAS0 97 SBUS./CS2_BIOS 149 SBUS.A20 201 SYSCK0 46 RAM./CAS3 98 SBUS./CS0_EXP1 150 SBUS.A21 202 GPU.DACK2 47 RAM./CAS2 99 SBUS./WR1 151 SBUS.A22 203 GPU./WR 48 RAM./CAS1 100 SBUS./WR0 152 SBUS.A23 204 GPU./RD 49 RAM./CAS0 101 SBUS./RD 153 GPU.A0 205 GPU./CS7 50 VDD 102 /IRQ1_GPU 154 SYSCK1 206 DSYSCK0 51 GND 103 GND 155 GND 207 GND 52 GND 104 GND 156 GND 208 GND Pin5-68 = Main RAM bus. Pin 95-152 = System bus. Pin 102,153,159-206 = Video bus.
"},{"location":"pinouts/#cpu-pinout-notes","title":"CPU Pinout Notes","text":"RAM.A11 is wired to the RAM chips' A8 line, while RAM.A8 and RAM.A10 are left unconnected.RAM./RAS1 is only used on systems with 4 or 8 MB RAM./RC_NET is tied to 3.5V, while /CSHTST (test pin?) is wired to ground.SYSCK0 (33 MHz), DSYSCK0 (67 MHz) and SYSCK1 (33 MHz) are clock outputs from the CPU to the rest of the system.TIMER0.CLK is fed from the GPU's DOTCK output, while TIMER1.CLK is fed from its HBLANK output.CRYSTALP and CRYSTALN are meant to be connected to a crystal, however all known console models feed CRYSTALP with the clock generated by an external oscillator and leave CRYSTALN open.SBUS./WR1 (upper byte write strobe) is routed to the expansion port but otherwise left unused, as all system bus devices are either 8-bit (CD-ROM, BIOS ROM) or only support 16-bit writes (SPU).SBUS.A0-SBUS.A23 are latched outputs and are not affected by RAM and GPU addressing.Old 160-pin GPU is used on PU-7 boards and EARLY-PU-8 boards.
"},{"location":"pinouts/#ic203-sony-cxd8514q-old-160pin-gpu-for-use-with-dual-ported-vram","title":"IC203 - Sony CXD8514Q - Old 160pin GPU for use with Dual-ported VRAM","text":"Unlike the later 208pin GPU's, the old 160pin GPU has less supply pins, and, it doesn't have a 24bit RGB output (nor any other video output at all), instead, it's used with a RGB D/A converter that reads the video data directly from the Dual-ported VRAM chips (ie. from special RAM chips with two data busses, one bus for GPU read/write access, and one for the RGB video output).
1-VCC 21-GND 41-D16 61-D2 81-D12'a 101-GND 121-D7'b 141-GND\n 2-GND 22-D31 42-D15 62-D1 82-D11'a 102-DT/OE'b 122-D6'b 142-53MHz\n 3-/GPUCS 23-D30 43-VCC 63-D0 83-D10'a 103-DT/OE'a 123-D5'b 143-VCC\n 4-GPU.A2 24-D29 44-GND 64-GND 84-D9'a 104-/RAS 124-D4'b 144-GND\n 5-/GPURD 25-D28 45-D14 65-VCC 85-D8'a 105-/WE'a 125-D3'b 145-FSC\n 6-/GPUWR 26-D27 46-D13 66-A8'a 86-VCC 106-/WE'b 126-D2'b 146-VCC\n 7-DACK2 27-D26 47-D12 67-A7'a 87-GND 107-/SE 127-D1'b 147-GND\n 8-/RESET 28-VCC 48-D11 68-A6'a 88-D7'a 108-SC 128-D0'b 148-DOTCLK\n 9-VCC 29-GND 49-D10 69-A5'a 89-D6'a 109-VCC 129-VCC 149-VCC\n 10-GND 30-D25 50-GND 70-GND 90-D5'a 110-GND 130-GND 150-GND\n 11-SYSCK0 31-D24 51-VCC 71-A4'a 91-D4'a 111-D15'b 131-A8'b 151-MEMCK1\n 12-VCC 32-D23 52-D9 72-A3'a 92-D3'a 112-D14'b 132-A7'b 152-MEMCK2\n 13-GND 33-D22 53-D8 73-A2'a 93-D2'a 113-D13'b 133-A6'b 153-BLANK\n 14-DREQ2 34-D21 54-D7 74-A1'a 94-D1'a 114-D12'b 134-A5'b 154-/24BPP\n 15-/IRQ1 35-D20 55-D6 75-A0'a 95-D0'a 115-D11'b 135-A4'b 155-/CSYNC\n 16-HBLANK 36-VCC 56-D5 76-GND 96-VCC 116-D10'b 136-A3'b 156-/HSYNC\n 17-VBLANK 37-GND 57-D4 77-VCC 97-DSF 117-D9'b 137-A2'b 157-/VSYNC\n 18-high? 38-D19 58-D3 78-D15'a 98-/CAS'b 118-D8'b 138-A1'b 158-VCC\n 19-high? 39-D18 59-GND 79-D14'a 99-/CAS'a 119-VCC 139-A0'b 159-GND\n 20-VCC 40-D17 60-VCC 80-D13'a 100-VCC 120-GND 140-VCC 160-DSYSCK0\n 151-? --- (mem clock?)\n 152-? (mem clock?)\n 153-BLANK (high in HBLANK & VBLANK)\n 154-/24BPP (high=15bpp, low=24bpp)\n 156-/HSYNC rate:65us=15KHz, low:3.5us\n 157-/VSYNC rate:20ms=50Hz, low:130us=TwoLines\nThis chip is used with the old 160pin GPU and two Dual-ported VRAM chips. The 2x16bit databus is capable of reading up to 32bits of VRAM data, and the chip does then extract the 15bit or 24bit RGB values from that data (depending on the GPU's current color depth). The RGB outputs (pin 5,7,9) seem to be passed through transistors and capacitors... not sure how the capacitors could output constant voltage levels... unless the RGB signals are actually some kind of edge-triggering PWM pulses rather than real analog levels(?)
1-test? 9-BLUE 17-GND 25-D0'a 33-D8'a 41-D15'a 49-D7'b 57-D13'b\n 2-test? 10-Vxx 18-MEMCK1 26-D1'a 34-D9'a 42-D0'b 50-D8'b 58-D14'b\n 3-Vxx 11-test? 19-/24BPP 27-D2'a 35-D10'a 43-D1'b 51-D9'b 59-D15'b\n 4-Vxx 12-test? 20-MEMCK2 28-D3'a 36-D11'a 44-D2'b 52-D10'b 60-GND\n 5-RED 13-test? 21-BLANK 29-D4'a 37-D12'a 45-D3'b 53-D11'b 61-GND\n 6-Vxx 14-aGND? 22-DOTCLK 30-D5'a 38-D13'a 46-D4'b 54-D12'b 62-GND\n 7-GREEN 15-aGND? 23-GND 31-D6'a 39-D14'a 47-D5'b 55-GND 63-test?\n 8-GND 16-aGND? 24-Vxx 32-D7'a 40-GND 48-D6'b 56-Vxx 64-GND\nThese are special Dual-ported VRAM chips (with two data busses), the D0-D15 pins are wired to the GPU (for read/write access), the Q0-Q15 pins are wired to the RGB D/A converter (for sequential video output).
1-VCC 9-Q2 17-D5 25-/UWE 33-GND 41-DSF 49-Q10 57-VCC\n 2-/DT/OE 10-D2 18-VCC 26-/RAS 34-A3 42-GND 50-D11 58-D14\n 3-GND 11-Q3 19-Q6 27-A8 35-A2 43-D8 51-Q11 59-Q14\n 4-Q0 12-D3 20-D6 28-A7 36-A1 44-Q8 52-GND 60-D15\n 5-D0 13-GND 21-Q7 29-A6 37-A0 45-D9 53-D12 61-Q15\n 6-Q1 14-Q4 22-D7 30-A5 38-QSF 46-Q9 54-Q12 62-GND\n 7-D1 15-D4 23-GND 31-A4 39-/CAS 47-VCC 55-D13 63-/SE\n 8-VCC 16-Q5 24-/LWE 32-VCC 40-NC 48-D10 56-Q13 64-SC\n 1-GND1 4-BIN 7-NPIN 10-SYNCIN 13-IREF 16-YOUT 19-VCC2 22-GOUT\n 2-RIN 5-NC 8-BFOUT 11-BC 14-VREF 17-YTRAP 20-CVOUT 23-ROUT\n 3-GIN 6-SCIN 9-YCLPC 12-VCC1 15-COUT 18-FO 21-BOUT 24-GND2\n GPU pin 145 (old 160-pin GPU)\n GPU pin 154 (new 208-pin GPU)\n IC204 (on later boards, eg. PSone)\nNew 206-pin GPU is used LATE-PU-8 boards and up.
"},{"location":"pinouts/#gpu-pinouts-ic203","title":"GPU Pinouts (IC203)","text":"Pin Name Pin Name Pin Name Pin Name 1HOST./CS 53 HOST.D10 105 GND 157 NTSC/PAL 2 HOST.A0 54 HOST.D9 106 VDD 158 /VSYNC 3 HOST./RD 55 HOST.D8 107 SGRAM.D9 159 /HSYNC 4 HOST./WR 56 HOST.D7 108 SGRAM.D8 160 DAC.B0 5 HOST.DACK 57 HOST.D6 109 SGRAM.D7 161 DAC.B1 6 /RESET 58 HOST.D5 110 SGRAM.D6 162 DAC.B2 7 VDD 59 HOST.D4 111 SGRAM.D5 163 DAC.B3 8 GND 60 GND 112 SGRAM.D4 164 GND 9 /SYSCLK 61 VDD 113 GND 165 VDD 10 VDD 62 HOST.D3 114 VDD 166 DAC.B4 11 GND 63 HOST.D2 115 SGRAM.D3 167 DAC.B5 12 HOST.DREQ 64 HOST.D1 116 SGRAM.D2 168 DAC.B6 13 HOST./IRQ 65 HOST.D0 117 SGRAM.D1 169 DAC.B7 14 HBLANK 66 GND 118 SGRAM.D0 170 DAC.G0 15 GND 67 VDD 119 GND 171 DAC.G1 16 VDD 68 PCKSL2 120 VDD 172 DAC.G2 17 VBLANK 69 PCKSL1 121 SGRAM./CS1 173 DAC.G3 18 HVHLD 70 PCKSL0 122 SGRAM./CS0 174 GND 19 GND 71 TEST3 123 SGRAM.DSF 175 VDD 20 GND 72 TEST2 124 SGRAM./RAS 176 DAC.G4 21 NC 73 TEST1 125 SGRAM./CAS 177 DAC.G5 22 VDD 74 TEST0 126 SGRAM./WE 178 DAC.G6 23 VDD 75 VDD 127 SGRAM.DQMH 179 DAC.G7 24 HOST.D31 76 GND 128 SGRAM.DQML 180 DAC.R0 25 HOST.D30 77 SGRAM.D31 129 GND 181 DAC.R1 26 HOST.D29 78 SGRAM.D30 130 VDD 182 DAC.R2 27 HOST.D28 79 SGRAM.D29 131 MCLKOUT 183 DAC.R3 28 HOST.D27 80 VDD 132 GND 184 GND 29 VDD 81 GND 133 VDD 185 VDD 30 GND 82 SGRAM.D28 134 MCLKIN 186 DAC.R4 31 HOST.D26 83 SGRAM.D27 135 GND 187 DAC.R5 32 HOST.D25 84 SGRAM.D26 136 VDD 188 DAC.R6 33 HOST.D24 85 SGRAM.D25 137 SGRAM.A9 189 DAC.R7 34 HOST.D23 86 SGRAM.D24 138 SGRAM.A8 190 GND 35 HOST.D22 87 VDD 139 SGRAM.A7 191 VDD 36 HOST.D21 88 GND 140 SGRAM.A6 192 VCLK_NTSC 37 VDD 89 SGRAM.D23 141 VDD 193 VDD 38 GND 90 SGRAM.D22 142 GND 194 GND 39 HOST.D20 91 SGRAM.D21 143 SGRAM.A5 195 VDD 40 HOST.D19 92 SGRAM.D20 144 SGRAM.A4 196 VCLK_PAL 41 HOST.D18 93 SGRAM.D19 145 SGRAM.A3 197 VDD 42 HOST.D17 94 SGRAM.D18 146 GND 198 GND 43 VDD 95 SGRAM.D17 147 VDD 199 PCK 44 GND 96 GND 148 SGRAM.A2 200 GND 45 HOST.D16 97 VDD 149 SGRAM.A1 201 VDD 46 HOST.D15 98 SGRAM.D16 150 SGRAM.A0 202 DMASK 47 HOST.D14 99 SGRAM.D15 151 VDD 203 ODE2 48 HOST.D13 100 SGRAM.D14 152 GND 204 GND 49 HOST.D12 101 SGRAM.D13 153 FSC 205 VDD 50 HOST.D11 102 SGRAM.D12 154 VDD 206 /DSYSCK 51 VDD 103 SGRAM.D11 155 GND 207 GND 52 GND 104 SGRAM.D10 156 CSYNC 208 VDD Pin 77..150 = Video RAM Bus. Pin 156..189 = Video Out Bus. Other = CPU Bus. Pin 153: Sub Carrier (NC on newer boards whick pick color clock from IC204).
"},{"location":"pinouts/#gpu-pinout-notes","title":"GPU Pinout Notes","text":"SGRAM./CS1 is only used on arcade boards with 2 MB VRAM (two 1 MB chips).HVHLD has a 4.7k pullup to 3.5V.TEST0-TEST3 are tied to 3.5V. PCKSL0-PCKSL2 (outputs possibly related to the current resolution/pixel clock?) are left unconnected.MCLKIN and MCLKOUT are tied together and wired to the DAC's clock input. MCLKIN could possibly be an external clock input for genlocking purposes.VCLK_PAL or VCLK_NTSC is wired up, depending on the console's region. On later boards both are tied together and connected to a programmable clock generator, which is preprogrammed to generate the appropriate frequency./VSYNC and /HSYNC are only connected to test points./CSYNC = (/VSYNC AND /HSYNC). BLANK = (VBLANK OR HBLANK).SGRAM.DQML is wired to both DQM0 and DQM2 on the SGRAM, while SGRAM.DQMH is wired to both DQM1 and DQM3.DMASK outputs the mask/\"alpha\" bit of the current pixel and is used by some arcade boards to composite the GPU's output on top of an external video source. ODE2 indicates which field is currently being output in interlaced mode.Region Japan+Europe: TDA8771AN Region America+Asia: MC151854FLTEG or so?
1-IREF 6-GNDd1 11-R1 16-G4 21-B7 26-B2 31-CLK 36-OUTB 41-NC\n 2-GNDa1 7-VDDd1 12-R0 17-G3 22-B6 27-VDDd2 32-VDDa1 37-NC 42-GNDa2\n 3-R7 8-R4 13-G7 18-G2 23-B5 28-GNDd2 33-VREF 38-NC 43-VDDa4\n 4-R6 9-R3 14-G6 19-G1 24-B4 29-B1 34-NC 39-VDDa3 44-OUTR\n 5-R5 10-R2 15-G5 20-G0 25-B3 30-B0 35-VDDa2 40-OUTG\nBCLAMP 13 NTSC/PAL 25 G7 37 B3 2 AGND2 14 SYNCIN 26 G6 38 B2 3 ROUT 15 SCIN 27 G5 39 B1 4 GOUT 16 R7 28 G4 40 B0 5 BOUT 17 R6 29 G3 41 VCLK 6 YOUT 18 R5 30 G2 42 DGND 7 COUT 19 R4 31 G1 43 VREFIN 8 VOUT 20 DVDD 32 G0 44 VREFOUT 9 AVCC2 21 R3 33 B7 45 AGND1 10 YTRAP 22 R2 34 B6 46 RCRAMP 11 NC 23 R1 35 B5 47 AVCC1 12 POWER_SAVE 24 R0 36 B4 48 GCLAMP Pin 3..8 (analogue outputs) are passed via external 75 ohm resistors. Pin 6,7 additionally via 220uF. Pin 8 additionally via smaller capacitor. Pin 10 (YTRAP) wired via 2K7 to 5.0V. Pin 1,44,46,48 (can) connect via capacitors to ground (only installed for 44). The 4.4MHz clock is obtained via 2K2 from IC204.Pin6. The /PAL pin can be reportedly GROUNDED to force PAL colors in NTSC mode, when doing that, you may first want to disconnect the pin from the GPU. Note: Rohm BH7240AKV has same pinout (XXX but with pin7/pin8 swapped?)
"},{"location":"pinouts/#beware","title":"Beware","text":"Measuring in the region near GPU Pin10 is the nocash number one source for blowing up components on the mainboard. If you want to measure that signals while power is on, better measure them at the CPU side.
"},{"location":"pinouts/#pinouts-spu-pinouts","title":"Pinouts - SPU Pinouts","text":""},{"location":"pinouts/#ic308-sony-cxd2922q-spu-on-pu-7-early-pu-8-boards","title":"IC308 - SONY CXD2922Q (SPU) (on PU-7, EARLY-PU-8 boards)","text":""},{"location":"pinouts/#ic308-sony-cxd2925q-spu-on-late-pu-8-pu-16-pu-18-pu-20-boards","title":"IC308 - SONY CXD2925Q (SPU) (on LATE-PU-8, PU-16, PU-18, PU-20 boards)","text":" 1-D0 14-D11 27-A8 40-GND 53-3.5V 66-A15 79-5V 92-LRIA\n 2-D1 15-GND 28-3.5V 41-SYSCK 54-GND 67-A14 80-A3 93-DTIA\n 3-3.5V 16-D12 29-GND 42-GND 55-D7 68-A13 81-A2 94-BCIB\n 4-GND 17-D13 30-A9 43-TEST 56-D6 69-A12 82-A1 95-LRIB\n 5-D2 18-D14 31-/SPU 44-TES2 57-D5 70-A11 83-A0 96-DTIB\n 6-D3 19-D15 32-/RD 45-D15 58-D4 71-A10 84-/WE0 97-BCKO\n 7-D4 20-A1 33-/WR 46-D14 59-D3 72-A9 85-/OE0 98-LRCO\n 8-D5 21-A2 34-DACK 47-D13 60-D2 73-A8 86-/WE1 99-DATO\n 9-D6 22-A3 35-/IRQ 48-D12 61-D1 74-A7 87-/OE1 100-WCKO\n 10-D7 23-A4 36-DREQ 49-D11 62-D0 75-A6 88-GND\n 11-D8 24-A5 37-MUTE 50-D10 63-/RAS 76-A5 89-XCK\n 12-D9 25-A6 38-/RST 51-D9 64-/CAS 77-A4 90-GND\n 13-D10 26-A7 39-NC 52-D8 65-GND 78-GND 91-BCIA\n 1-DA16 23-FILO 45-LOCK 67-FSTO 89-SCSY 111-XCS 133-HD9 155-VSS5\n 2-DA15 24-FILI 46-SSTP 68-COUT 90-SCLK 112-XRD 134-HD8 156-HA1\n 3-DA14 25-PCO 47-SFDR 69-XDRST 91-SQSO 113-XWR 135-HD7 157-HA0\n 4-VDDM0 26-CLTV 48-SRDR 70-DA11 92-SENS 114-HINT 136-HD6 158-VDDM3\n 5-DA13 27-AVSSO 49-TFDR 71-DA10 93-DATA 115-XIRQ 137-VDD4 159-XCK\n 6-DA12 28-RFAC 50-TRDR 72-DA09 94-XLAT 116-VDDM2 138-HD5 160-DTIB\n 7-LRCK 29-BIAS 51-VSSM1 73-DA08 95-CLOK 117-XSCS 139-HD4 161-BCKO\n 8-WDCK 30-ASYI 52-FFDA 74-AVSMO 96-XINT 118-XHCS 140-HD3 162-LRCO\n 9-VDD0 31-AVDDO 53-FRDA 75-AVDMO 97-A4 119-XHRD 141-HD2 163-DAVDD0\n 10-VSS0 32-ASYO 54-MDP 76-DA07 98-A3 120-XHWR 142-VSS4 164-DAREFL\n 11-PSSL 33-VC 55-MDS 77-DA06 99-A2 121-DACK 143-HD1 165-AOUTL\n 12-ASYE 34-CE 56-VDD2 78-VDDM1 100-A1 122-DREQ 144-HD0 166-DAVSS0\n 13-GND 35-CEO 57-VSS2 79-DA05 101-A0 123-XRST 145-VSSM3 167-DAVSS1\n 14-C4M 36-CEI 58-MIRR 80-DA04 102-D7 124-VDD3 146-HA9 168-AOUTR\n 15-C16M 37-RFDC 59-DFCT 81-DA03 103-D6 125-SYSCK 147-HA8 169-DAREFR\n 16-FSOF 38-ADIO 60-AVSM1 82-DA02 104-D5 126-VSS3 148-HA7 170-DAVDD1\n 17-XTSL 39-AVDD1 61-AVDM1 83-DA01 105-D4 127-HD15 149-HA6 171-MUTO\n 18-VDD1 40-IGEN 62-FOK 84-WFCK 106-VSSM2 128-HD14 150-HA5 172-DATO\n 19-GND 41-AVSS1 63-PWMI 85-SCOR 107-D3 129-HD13 151-HA4 173-MTS3\n 20-VPCO1 42-TE 64-FSW 86-SBSO 108-D2 130-HD12 152-VDD5 174-MTS2\n 21-VPCO2 43-SE 65-MON 87-EXCK 109-D1 131-HD11 153-HA3 175-MTS1\n 22-VCTL 44-FE 66-ATSK 88-SQCK 110-D0 132-HD10 154-HA2 176-MTS0\n 1-SCLK 27-RFAC 53-TrckR 79-/XINT 105-A0 131-3.5V 157-(tst) 183-A8\n 2-GNDed 28-GNDed 54-TrckF 80-SQCK 106-3.5V 132-D9 158-(tst) 184-A7\n 3-GNDed 29-CLTV 55-FocuR 81-SQSO 107-A1 133-D8 159-GND 185-A6\n 4-SBSO 30-PCO 56-3.5V 82-SENSE 108-A2 134-D7 160-D15 186-A5\n 5-WFCK 31-FILI 57-FocuF 83-GND 109-A3 135-D6 161-D0 187-GND\n 6-GNDed 32-FILO 58-SledR 84-GND 110-A4 136-D5 162-D14 188-A4\n 7-C16M 33-VCTL 59-SledF 85-CD.D7 111-A5 137-3.5V 163-D1 189-A3\n 8-3.5V 34-VPC02 60-NC 86-CD.D6 112-3.5V 138-D4 164-D13 190-A2\n 9-C4M 35-VPC01 61-GND 87-CD.D5 113-A6 139-D3 165-3.5V 191-A1\n 10-GNDed 36-VC 62-NC 88-CD.D4 114-A7 140-D2 166-D2 192-A0\n 11-4.3MHz 37-FE 63-GND 89-CD.D3 115-A8 141-D1 167-D12 193-3.5V\n 12-12MHz 38-SE 64-(tst) 90-CD.D2 116-A9 142-D0 168-D3 194-NC\n 13-V16M 39-TE 65-(tst) 91-CD.D1 117-/IRQ2 143-GND 169-D11 195-(tst)\n 14-DOUT 40-CE 66-note 92-CD.D0 118-/IRQ9 144-33MHzS 170-D10 196-GND\n 15-LACK 41-CEO 67-note 93-3.5V 119-/RD 145- 171-D4 197-(tst)\n 16-WDCK 42-CEI 68-(tst) 94-CD/CS 120-/WR 146-3.48V 172-D9 198-NC\n 17-3.5Ved 43-RFDC 69-3.5V 95-CD/WR 121-DMA4 147-ZZ11 173-GND 199-NC\n 18-LOCK 44-ADIO 70-(tst) 96-CD/RD 122-GND 148-GND 174-D5 200-NC\n 19-GND 45-GND 71-(tst) 97-CD.A0 123-GND 149-GND 175-D8 201-3.5V\n 20-MDS 46-IGEN 72-(tst) 98-CD.A1 124-/SPUW 150-ZZ7 176-D6 202-NC\n 21-MDP 47-AVD1 73-(tst) 99-CD.A2 125-D15 151-3.48V 177-D7 203-NC\n 22-3.5Ved 48-GNDed 74-DATA 100-GND 126-D14 152-/RES 178-/CAS 204-NC\n 23-AVDO 49-GNDed 75-XLAT 101-CDA3 127-D13 153-3.5V 179-/WE 205-GND\n 24-ASYO 50-GND 76-CLOK 102-CDA4 128-D12 154-ZZ5 180-3.5V 206-(tst)\n 25-ASYI 51-GNDed 77-SCOR 103-/CD 129-D11 155-(tst) 181-/OE 207-(tst)\n 26-BIAS 52-GNDed 78-GND 104-/SPU 130-D10 156-(tst) 182-/RAS 208-GND\nPin 74,75,76,119,120 are connected via 22 ohm. Pin 103,104 are connected via 100 ohm. ZZnn = IC405 Pin nn (analog audio related, L/R/MUTE). Pin 103..142 = System Bus (BIOS,CPU). Pin 160..192 = Sound RAM Bus. Pin 178 used for both /CASL and /CASH (which are shortcut with each other). Pin 146 and 151 are 3.48V (another supply, not 3.5V). Pin 147 and 150 are connected via capacitors. Pin 195 and 197 testpoints are found below of the pin 206/207 testpoints.
SPU155 (tst) always low ;=maybe external audio (serial) this?\n SPU156 (tst) 45kHz (22us) ;=probably 44.1kHz (ext audio sample-rate)\n SPU157 (tst) 2777kHz (0.36us) ;=probably 64*44.1kHz (ext audio bit-rate)\n SPU158 (tst) always high ;=maybe external audio (serial) or this?\n SPU197 (*) 7.35kHz (44.1kHz/6) (stable clock, maybe DESIRED drive speed)\n SPU5 (*) 7.35kHz (44.1kHz/6) (unstable clock, maybe ACTUAL drive speed)\n SPU15 (*) 44.1kHz (44.1kHz*1)\n SPU16 (*) 88.2kHz (44.1kHz*2)\n SPU206 (*) circa 2.27MHz\n SPU70 (*) whatever clock (with SHORT low pulses)\n SPU207 fastsignal?\n SPU195 slowsignal?\n SPU18 usually high, low during seek or spinup or so\n SPU44 superslow hi/lo with superfast noise on it\n SPU73 mainly LOW with occasional HIGH levels...\n SPU71 LOW=SPIN_OK, PULSE=SPIN_UP/DOWN_OR_STOPPED\n SPU72 similar as SPU71\n SPU64 LOW=STOP, HI=SPIN\n SPU68 always low...?\n SPU65 whatever?\n SPU75 mainly HIGH, short LOW pulses when changing speed up/down/break\n | | SPU73\n | CXD2938Q (SPU) | SPU72\n | (on PM-41 board) | SPU70 SPU71\n | | SPU64 SPU65 SPU68\n SPU206 SPU207 |_______________________________________|\n SPU197\n SPU195 SPU16 SPU44\n SPU18 SPU5 SPU15\n SPU12\n 1-TST? 4-/PD 7-CKS 10-LRCK 13-NC? 16-AOUTL 19-GNDa 22-VREFH\n 2-VCCd 5-/RST 8-BICK 11-NC? 14-NC? 17-VCOM 20-NC? 23-VREFL\n 3-GNDd 6-MCLK 9-SDATA 12-NC? 15-AOUTR 18-VCCa 21-NC? 24-DZF?\nCalled \"NJM2174\" in service manual. Audio Amplifier with Mute.
1 GND\n 2 NC ? via 100ohm to multiout pin 9 ;Audio Left (white cinch)\n 3 OUT-R ?\n 4 MUTE1 ;specified as LOW = Mute\n 5 MUTE2 ;specified as HIGH = Mute\n 6 MUTEC ;unspecified, maybe capacitor, or output based on MUTE1+MUTE2?\n 7 IN-R via capacitor to SPU.150\n 8 BIAS\n 9 NC\n 10 NC\n 11 IN-L via capacitor to SPU.147\n 12 OUT-L ?\n 13 NC ? via 100ohm to multiout pin 11 ;Audio Right (red cinch)\n 14 VCC +5.0V (via L401)\n 1-ROUT\n 2-RIN- IC732.SPU.150\n 3-RIN+\n 4-GND\n 5-LIN+\n 6-LIN- IC732.SPU.147\n 7-LOUT\n 8-VCC 4.9V (+5.0V via L401)\nPinouts - HC05 Pinouts
"},{"location":"pinouts/#ic305-sony-cxd1815q-cdrom-decoderfifo-used-on-pu-8-pu-16-pu-18","title":"IC305 - SONY CXD1815Q - CDROM Decoder/FIFO (used on PU-8, PU-16, PU-18)","text":" 1-D0 14-/XINT 27-/HRD 40-GND 53-VDD 66-/MWR 79-GND 92-LRCO\n 2-D1 15-GND 28-VDD 41-HDRQ 54-GND 67-MDB0 80-CLK 93-WCKO\n 3-VDD 16-A0 29-GND 42-/HAC 55-MA8 68-MDB1 81-HCLK 94-BCKO\n 4-GND 17-A1 30-/HWR 43-MA0 56-MA9 69-MDB2 82-CKSL 95-MUTE\n 5-D2 18-A2 31-HD0 44-MA1 57-MA10 70-MDB3 83-RMCK 96-TD7\n 6-D3 19-A3 32-HD1 45-MA2 58-MA11 71-MDB4 84-LRCK 97-TD6\n 7-D4 20-A4 33-HD2 46-T01 59-MA12 72-MDB5 85-DATA 98-TD5\n 8-D5 21-TD0 34-HD3 47-T02 60-MA13 73-MDB6 86-BCLK 99-TD4\n 9-D6 22-/HRS 35-HD4 48-MA3 61-MA14 74-MDB7 87-C2PO 100-TD3\n 10-D7 23-/HCS 36-HD5 49-MA4 62-MA15 75-MDBP 88-EMP\n 11-/CS 24-HA0 37-HD6 50-MA5 63-MA16 76-XTL2 89-/RST\n 12-/RD 25-HA1 38-HD7 51-MA6 64-/MOE 77-XTL1 90-GND\n 13-/WR 26-HINT 39-HDP 52-MA7 65-GND 78-VDD 91-DATO\n 1-FEO 7-FE_M 13-RA_O 19-CLK 25-FOK 31-RF_O 37-FE_BIAS 43-LPFI\n 2-FEI 8-SRCH 14-SL_P 20-XLT 26-CC2 32-RF_M 38-F 44-TEI\n 3-FDFCT 9-TGU 15-SL_M 21-DATA 27-CC1 33-LD 39-E 45-ATSC\n 4-FGD 10-TG2 16-SL_O 22-XRST 28-CB 34-PD 40-EI 46-TZC\n 5-FLB 11-FSET 17-ISET 23-C.OUT 29-CP 35-PD1 41-GND 47-TDFCT\n 6-FE_O 12-TA_M 18-VCC 24-SENS 30-RF_I 36-PD2 42-TEO 48-VC\n 1-FOK 11-PDO 21-GNDa 31-WDCK 41-DA09-XPLCK 51-APTL 61-EMPH 71-DATA\n 2-FSW 12-GND 22-VLTV 32-LRCK 42-DA08-GFS 52-GND 62-WFCK 72-XLAT\n 3-MON 13-TEST0 23-VDDa 33-VDD 5V 43-DA07-RFCK 53-XTAI 63-SCOR 73-VDD\n 4-MDP 14-NC 24-RF 34-DA16-SDTA48 44-DA06-C2PO 54-XTAO 64-SBSO 74-CLOK\n 5-MDS 15-NC 25-BIAS 35-DA15-SCLK48 45-DA05-XRAOF 55-XTSL 65-EXCK 75-SEIN\n 6-LOCK 16-VPCO 26-ASYI 36-DA14-SDTA64 46-DA04-MNT3 56-FSTT 66-SQSO 76-CNIN\n 7-NC 17-VCKI 27-ASYO 37-DA13-SCLK64 47-DA03-MNT2 57-FSOF 67-SQCK 77-DATO\n 8-VCOO 18-FILO 28-ASYE 38-DA12-LRCK64 48-DA02-MNT1 58-C16M 68-MUTE 78-XLTO\n 9-VCOI 19-FILI 29-NC 39-DA11-GTOP 49-DA01-MNT0 59-MD2 69-SENS 79-CLKO\n 10-TEST 20-PCO 30-PSSL 40-DA10-XUGF 50-APTR 60-DOUT 70-XRST 80-MIRR\n 1-SRON 14-TEST 27-TE 40-VDDa 53-DA09-XPLCK 66-FSTI 79-MUTE 92-DFCT\n 2-SRDR 15-GND 28-SE 41-VDD 54-DA08-GFS 67-FSTO 80-SENS 93-FOK\n 3-SFON 16-TES2 29-FE 42-ASYE 55-DA07-RFCK 68-FSOF 81-XRST 94-FSW\n 4-TFDR 17-TES3 30-VC 43-PSSL 56-DA06-C2PO 69-C16M 82-DIRC 95-MON\n 5-TRON 18-PDO 31-FILO 44-WDCK 57-DA05-XRAOF 70-MD2 83-SCLK 96-MDP\n 6-TRDR 19-VPCO 32-FILI 45-LRCK 58-DA04-MNT3 71-DOUT 84-DFSW 97-MDS\n 7-TFON 20-VCKI 33-PCO 46-DA16-SDTA48 59-DA03-MNT2 72-EMPH 85-ATSK 98-LOCK\n 8-FFDR 21-VDDa 34-CLTV 47-DA15-SCLK48 60-DA02-MNT1 73-WFCK 86-DATA 99-SSTP\n 9-FRON 22-IGEN 35-GNDa 48-DA14-SDTA64 61-DA01-MNT0 74-SCOR 87-XLAT 100-SFDR\n 10-FRDR 23-GNDa 36-RFAC 49-DA13-SCLK64 62-XTAI 75-SBSO 88-CLOK\n 11-FFON 24-ADIO 37-BIAS 50-DA12-LRCK64 63-XTAO 76-EXCK 89-COUT\n 12-VCOO 25-RFC 38-ASYI 51-DA11-GTOP 64-XTSL/GNDed 77-SQSO 90-VDD\n 13-VCOI 26-RFDC 39-ASYO 52-DA10-XUGF 65-GND 78-SQCK 91-MIRR\nPinouts are same as CXD2545Q, except, three pins are different: Pin24=ADII (instead of ADIO), Pin25=ADIO (instead of RFC), Pin68=C4M (instead of FSOF).
"},{"location":"pinouts/#ic720-144pin-sony-cxd1817r-cxd2545qcxd1815q-pu-20","title":"IC720 - 144pin SONY CXD1817R (=CXD2545Q+CXD1815Q) ;PU-20","text":" 1..48 - unknown\n 49 - SCOR\n 50..144 - unknown\n 1-8 Unknown (maybe CDROM related, at least it's near other CDROM chips)\nDrive Motor related.
1 to pin24,27\n 2 SPINDLE - via 15K to SPU21\n 3 SW (ON/OFF) - IC304.27\n 4 TRACKING FORWARD\n 5 TRACKING REVERSE\n 6 FOCUS FORWARD\n 7 FOCUS REVERSE\n 8 GND - CN702 pin 11\n 9 NC (INTERNAL) - via C731 (10uF) to GND\n 10 +7.5V (Pow VCC ch1,2)\n 11 FOCUS COIL (1) - CN702 pin 15\n 12 FOCUS COIL (2) - CN702 pin 14\n 13 TRACKING COIL (1) - CN702 pin 16\n 14 TRACKING COIL (2) - CN702 pin 13\n 15 SPINDLE MOTOR (1) - CN701 pin 4\n 16 SPINDLE MOTOR (2) - CN701 pin 3\n 17 SLED MOTOR (1) - CN701 pin 1\n 18 SLED MOTOR (2) - CN701 pin 2\n 19 +7.5V (Pow VCC ch3,4)\n 20 MUTE - /RES (via 5K6)\n 21 GND\n 22 SLED REVERSE\n 23 SLED FORWARD\n 24 to pin1\n 25 via capacitors to pin1\n 26 BIAS 1.75V\n 27 to pin1\n 28 +7.5V (Pre VCC)\n 1 LD O APC amplifier output\n 2 PD I APC amplifier input\n 3 PD1 I Input 1 for RF I-V amplifiers\n 4 PD2 I Input 2 for RF I-V amplifiers\n 5 GND/VEE - Supply Ground\n 6 F I Input F for I-V amplifier\n 7 E I Input E for I-V amplifier\n 8 VR O DC Voltage Output (VCC+VEE)/2\n 9 VC I Center Voltage Input\n 10 NC - NC\n 11 NC - NC\n 12 EO O Monitoring Output for I-V amplifier E\n 13 EI - Gain Adjust for I-V amplifier E\n 14 TE O Tracking Error Amplifier Output\n 15 FE_BIAS I BIAS Adjustment for Focus Error\n 16 FE O Focus Error Amplifier Output\n 17 RFO O RF Amplifier Output\n 18 RFI I RF Amplifier Input\n 19 /LD_ON I APC amplifier ON=GND, OFF=VCC\n 20 VCC - Supply\n 1-TEIM\n 2-TEIG\n 3-VEE GND\n 4-E via 33K to CN702 pin 4\n 5-F via 33K to CN702 pin 8\n 6-PD2 via 36K to CN702 pin 6\n 7-PD1 via 36K to CN702 pin 7\n 8-PD to CN702 pin 9\n 9-LD\n 10-VC CL710, and CN702.Pin3, and via resistor?/diode? to SPU42\n 11-LD_ON IC304.Pin49 \"LDON\" ..... XXX or is that Pin 20 \"LD_ON\" ?\n 12-G_CONT ;or AL/TE?\n 13-RF0 CL704, and...\n 14-RFM\n 15-FE CL708, and... (maybe focus error?)\n 16-TE CL709, and via 15K to SPU.39 (maybe tracking error?)\n 17-TE0\n 18-COMP+\n 19-MIRR via 4K7 to SPU66\n 20-VCC 3.48V (not 3.5V)\n 1-LD to Q701\n 2-VCC to Q701\n 3-VC to IC723.Pin10 (and CL710)\n 4-F- to IC723.Pin4 (via 33K ohm)\n 5-NC to CL776\n 6-PD2 to IC723.Pin6 (via 33K ohm)\n 7-PD1 to IC723.Pin7 (via 33K ohm)\n 8-E- to IC723.Pin5 (via 33K ohm)\n 9-M1 to IC723.Pin8\n 10-VR via 91 ohm to GND\n 11-GND GND\n 12-LS /POS0 (switch, GNDed when at head is at inner-most position)\n 13-FCS+ TRACKING COIL (2) ;\\\n 14-TRK+ FOCUS COIL (2) ; or swapped?\n 15-TRK FOCUS COIL (1) ;\n 16-FCS TRACKING COIL (1) ;/\n 1-SL- SLED MOTOR (1)\n 2-SL+ SLED MOTOR (2)\n 3-SP+ SPINDLE MOTOR (2)\n 4-SP- SPINDLE MOTOR (1)\n CL616 +7.5V (PM-41 only, not PM-23) (before power switch)\n CL617 GND (PM-41 only, not PM-23)\n CL316 to IC304 pin 21\n CL704 to IC723.Pin13\n CL706 GND\n CL708 to IC723.Pin15\n CL709 to IC723.Pin16\n CL710 to IC723.Pin10, and CN702.Pin3\n CL711 via 1K to IC723.Pin15\n CL776 to CN702.Pin5\nSCPH-5903 Video CD PlayStation
"},{"location":"pinouts/#vcd-mainboard-pu-16-1-655-191-11-component-list","title":"VCD Mainboard \"PU-16, 1-655-191-11\" Component List","text":"The overall design is very close to LATE-PU-8 boards (1-658-467-2x). Changed components are IC102/IC304 (different kernel and cdrom firmware), C318/C325/C327 (height reduced capacitors for mounting the daughterboard above of them). Plus some extra components: Three triple multiplexors (for switching between PSX and VCD audio/video), and the daughterboard connector.
IC102 44pin SONY, M538032E-02, JAPAN 6465401 (uncommonly big BIOS, 1Mx8)\n IC304 52pin C 4021 SC430924PB (HC05 sub-cpu, with extra Video CD command 1Fh)\n C318 2pin S5 ;\\tantalum capacitors with lower height (instead\n C325 2pin CA7 ; of the electrolytic capacitors on PU-8 boards)\n C327 2pin CA7 ;/\n ICnnn 16pin 4053C (Triple multiplexor, for Audio LRCK,BCLK,DATA) (PCB top)\n ICnnn 16pin 4053C (Triple multiplexor, for Video FSC,CSYNC) (PCB bottom)\n ICnnn 16pin 2283 (Triple multiplexor, for Video R,G,B) (PCB bottom)\n CNnnn 30pin Connector to daughterboard (PCB top)\n IC102 3pin TA78M05F voltage regulator (7.5V to 5V) (Toshiba)\n IC104 120pin CXD1852AQ Video CD decoder (Sony)\n IC106 40pin MB814260-70 (256Kx16 DRAM) (Fujitsu) ;see also: IC114\n IC107 20pin 6230FV 649 115 (OSD, similar to BU6257AFV-E2) (PCB back)\n IC109 14pin Y2932 (TLC2932 PLL) (TI) (for RGB.DAC.CLK)\n IC110 44pin TDA8771AH Triple Video DAC for RGB (Philips) (PCB back)\n IC111 64pin CXP10224-603R 732A02E (MCU) (Sony)\n IC112 14pin HCT32A (74HCT32 Quad OR gate) (TI) (PCB back) (for RGB.DAC.CLK)\n IC113 8pin H74 7H (single D-type flip-flop; OSD clock divider) (PCB back)\n IC114 40pin MB814260-70 (256Kx16 DRAM) (Fujitsu) ;see also: IC106\n CN101 30pin Male Connector (to female 30pin socket on PU-16 mainboard)\n X103 2pin 45.00MHz (for VCD decoder chip)\n X104 4pin 12.000MHz (for MCU chip)\n X105 2pin 28.636MHz (for VCD decoder chip) (8*3.579545 NTSC clock)\n .--.---.\n GND / 1 2 | GND\n (CXD1815Q.86) CD.BCLK | 3 4 | CD.LRCK (CXD1815Q.84)\n (CXD1815Q.87) CD.C2PO | 5 6 | CD.DATA (CXD1815Q.85)\n GND | 7 8 | CD.SQCK (CXD2510Q.67) CXP.31\n (TDA.44) VIDEO.OUTR | 9 10 | CD.SQSO (CXD2510Q.66) CXP.29\n GND | 11 12 | SIO.OUT (HC05.51.PORTF1 to CXP.47)\n (TDA.40) VIDEO.OUTG | 13 14 | SIO.IN (HC05.50.PORTF0 from CXP.48)\n GND | 15 16 | SIO.CLK (HC05.52.PORTF2 to CXP.49)\n (TDA.36) VIDEO.OUTB | 17 18 | VIDEO.FSC (CXD1852AQ.95)\n GND | 19 20 | VIDEO.CSYNC(CXD1852AQ.96)\n (PSU.3) 3.5V | 21 22 | 3.5V (PSU.3)\n (PSU.1) 7.5V | 23 24 | AUDIO.FSXI (CXD1852AQ.103 to VCD)\n (PSU.7) /RES | 25 26 | AUDIO.DATA (CXD1852AQ.100)\n (CXD1852AQ.102) AUDIO.BCLK | 27 28 | AUDIO.LRCK (CXD1852AQ.101)\n GND | 29 30 | GND\n '--------'\n 1-GND 16-HD7 31-GND 46-MD4 61-GND 76-G/Y3 91-GND 106-XTL2O\n 2-XTL0O 17-MA3 32-MA7 47-MD11 62-/VOE 77-G/Y4 92-HSYNC 107-XTL2I\n 3-XTL0I 18-MA4 33-MA8 48-MD3 63-R/Cr0 78-G/Y5 93-VSYNC 108-VDD\n 4-VDD 19-MA2 34-/RAS 49-MD12 64-R/Cr1 79-G/Y6 94-FID/FHREF 109-C2PO\n 5-HA2 20-MA5 35-/MWE 50-MD2 65-R/Cr2 80-G/Y7 95-CBLNK/FSC 110-LRCI\n 6-HA3 21-MA1 36-/CAS2 51-MD13 66-R/Cr3 81-B/Cb0 96-CSYNC 111-DATI\n 7-HD0 22-GND 37-/CAS0 52-MD1 67-R/Cr4 82-B/Cb1 97-/SGRST 112-BCKI\n 8-HD1 23-MA6 38-MD7 53-MD14 68-R/Cr5 83-B/Cb2 98-CLK0O 113-DOIN\n 9-HD2 24-MA0 39-MD8 54-MD0 69-R/Cr6 84-B/Cb3 99-DOUT 114-/HCS\n 10-HD3 25-BC 40-MD6 55-MD15 70-R/Cr7 85-B/Cb4 100-DATO 115-/HDT\n 11-HD4 26-TCKI 41-MD9 56-OSDEN 71-G/Y0 86-B/Cb5 101-LRCO 116-HRW\n 12-HD5 27-TDI 42-MD5 57-OSDB 72-G/Y1 87-B/Cb6 102-BCKO 117-/HIRQ\n 13-HD6 28-TENA1 43-MD10 58-OSDG 73-G/Y2 88-B/Cb7 103-FSXI 118-/RST\n 14-VDD 29-TDO 44-VDD 59-OSDR 74-VDD 89-DCLK 104-VDD 119-HA0\n 15-GND 30-VST 45-GND 60-VDD 75-GND 90-VDD 105-GND 120-HA1\n 1-SIO.CLK 5-VDD 9-TEST 13-BLK2 17-OSDG\n 2-SIO./CS 6-/CKOUT 10-GND 14-VC2 18-OSDB\n 3-SIO.DTA 7-OSCOUT 11-BLK1 15-OSDEN 19-/VSYNC\n 4-/RESET 8-OSCIN 12-VC1 16-OSDR 20-/HSYNC\n 1-PB5=TP 17-PD5=/HCS 33-AVREF=VDD 49-PG5/SCK1=HC05.PF2\n 2-PB4=TP 18-PD4=TP 34-AVDD=VDD 50-PG4=/RST.OUT\n 3-PB3=HA3 19-PD3=TP 35-PF7/AN7=TP 51-PG3/TO=TP\n 4-PB2=HA2 20-PD2=TP 36-PF6/AN6=OSD.DTA 52-PA7=TP\n 5-PB1=HA1 21-PD1=TP 37-PF5/AN5=OSD./CS 53-PA6=TP\n 6-PB0=HA0 22-PD0=TP 38-PF4/AN4=OSD.CLK 54-PA5=TP\n 7-PC7=HD7 23-MP/TEST=GND 39-PF3/AN3=GND 55-PA4=TP\n 8-PC6=HD6 24-XTAL=12MHZ 40-PF2/AN2=GND 56-VPP=VDD\n 9-PC5=HD5 25-EXTAL=12MHZ 41-PF1/AN1=GND 57-VDD=VDD\n 10-PC4=HD4 26-VSS=GND 42-PF0/AN0=10KtoGND 58-VSS=GND\n 11-PC3=HD3 27-/RST=/RES 43-PE3/PWM1=TP 59-PA3=TP\n 12-PC2=HD2 28-/CS0=VDD 44-PE2/PWM0=TP 60-PA2=TP\n 13-PC1=HD1 29-SI0=CD.SQSO 45-PE1/INT2/EC=/VSYNC 61-PA1=TP\n 14-PC0=HD0 30-SO0=TP 46-PE0/INT0=/HIRQ 62-PA0=TP\n 15-PD7=HRW 31-/SCK0=CD.SQCK 47-PG7/SI1/INT1=HC05.PF1 63-PB7=TP\n 16-PD6=/HDT 32-AVSS=GND 48-PG6/SO1=HC05.PF0 64-PB6=TP\n 1-LOGIC_VDD=5V 5-FIN-B=HSYNC.PLL 9-PFD_INHIBIT=GND 13-BIAS\n 2-SELECT=5V 6-PFD_OUT 10-VCO_INHIBIT=GND 14-VCO_VDD=5V\n 3-VCO_OUT=RGB.DAC.CLK.PLL 7-LOGIC_GND=GND 11-VCO_GND=GND\n 4-FIN-A=FID/FHREF.PLL 8-NC 12-VCO_IN\n 1-FID/FHREF.MPEG 4-HSYNC.MPEG 8-(low) 11-RGB.DAC.CLK.TDA 7-GND\n 2-FID/FHREF.MPEG 5-HSYNC.MPEG 9-GNDed 12-RGB.DAC.CLK.PLL 14-VCC/5V\n 3-FID/FHREF.PLL 6-HSYNC.PLL 10-GNDed 13-RGB.DAC.CLK.PLL\n 1-CLK 2-D 3-/Q 4-GND 5-Q 6-/RES 7-/SET 8-VCC\n 1-IN2B=DATA.VCD 5-IN3A=LRCK.SPU 9-SEL3=LRCK.SEL 13-IN1B=BCLK.VCD\n 2-IN2A=DATA.SPU 6-/OE=GNDed 10-SEL2=DATA.SEL 14-OUT1=BCLK.OUT\n 3-IN3B=LRCK.VCD 7-VEE=GNDed 11-SEL1=BCLK.SEL 15-OUT2=DATA.OUT\n 4-OUT3=LRCK.OUT 8-GND=GND 12-IN1A=BCLK.SPU 16-VDD=VDD/3.5V\n 1-IN2B=FSC.VCD 5-IN3A=CSYNC.PSX 9-SEL3=CSYNC.SEL 13-IN1B=GNDed\n 2-IN2A=FSC.PSX 6-/OE=GNDed 10-SEL2=FSC.SEL 14-OUT1=NCed\n 3-IN3B=CSYNC.VCD 7-VEE=GNDed 11-SEL1=DUMMY.SEL 15-OUT2=FSC.OUT\n 4-OUT3=CSYNC.OUT 8-GND=GND 12-IN1A=GNDed 16-VDD=VCC/5V\n 1-IN1B=R.VCD 5-OUT2=G.OUT 9-IN3B=B.VCD 13-V=VCC/5V\n 2-SEL1=R.SEL 6-OUT3=B.OUT 10-GND3=81ohm/GND 14-IN2B=G.VCD\n 3-OUT1=R.OUT 7-SEL3=B.SEL 11-IN2A=G.PSX 15-GND1=GND\n 4-GND2=GND 8-IN3A=B.PSX 12-SEL2=G.SEL 16-IN1A=R.PSX\n 80pin \"4246xx\" - MC68HC05L16, on-chip ROM (DTL-H120x & old retail consoles)\n 80pin \"MC68HC705L16CFU\" - MC68HC705L16, on-chip ROM (DTL-H100x, and PU-9)\n 52pin \"SC4309xx\" - MC68HC05G6, on-chip ROM (newer retail consoles)\nCalled \"MC68HC05G6PB\" in service manual (=8bit CPU).
1 NC NC (TEST:DTR/out) (VCD:AVSEL/out) ;-Port F ;PortF.Bit3\n 2 VDD 3.5V\n 3 NC NC ;\\ ;maybe PortE.Bit7?\n 4 NC NC ; maybe MSBs of Port E ;maybe PortE.Bit6?\n 5 NC NC ;/ ;maybe PortE.Bit5?\n 6 DECA4 SPU102 ;\\ ;PortE.Bit4\n 7 DECA3 SPU101 ; Port E [04h], aka Address/Index ;PortE.Bit3\n 8 DECA2 SPU99 ; ;PortE.Bit2\n 9 DECA1 SPU98 ; ;PortE.Bit1\n 10 DECA0 SPU97 ;/ ;PortE.Bit0\n 11 VSS GND\n 12 NDLY GND reserved for factory test, should be wired to VDD, not GND?\n 13 /RES /RES (via 5K6)\n 14 OSC1 4.3MHz (SPU11)(used as external clock for some modchips)(low volts)\n 15 OSC2 NC\n 16 F-BIAS aka FOK=NC (in SCPH-5500) ;PortB.Bit0\n 17 CG NC aka CG=CG (in SCPH-5500) ;this IS portb.1! ;PortB.Bit1\n 18 LMTSW /POS0 (switch, GNDed when head at inner-most position) ;PortB.Bit2\n 19 DOOR SHELL_OPEN ;PortB.Bit3\n 20 TEST2 NC ;PortB.Bit4\n 21 TEST1 to CL316 ;PortB.Bit5\n 22 COUT NC ;PortB.Bit6\n 23 SENSE SPU82 ;CXD2510Q.69 ;PortB.Bit7\n 24 SUBQ SPU81 ;CXD2510Q.66 ;PortC.Bit0\n 25 NC NC ;NC ;PortC.Bit1\n 26 SQCK SPU80 ;CXD2510Q.67 ;PortC.Bit2\n 27 SPEED IC722.Pin3 (SW) ;PortC.Bit3\n 28 AL/TE ;transisor aka MIRROR=.. (in SCPH-5500);ISN'T PortB.Bit1 !\n 29 ROMSEL ;NC aka ROMSEL=SCLK (in SCPH-5500) ;PortC.Bit5\n 30 /XINT SPU79 ;CXD1815Q.14 ;PortC.Bit6\n 31 SCOR SPU77 ;CXD2510Q.63 ;PortC.Bit7\n 32 VDD 3.5V\n 33 DECD0 CD.D0 ;\\ ;PortA.Bit0\n 34 DECD1 CD.D1 ; ;PortA.Bit1\n 35 DECD2 CD.D2 ; ;PortA.Bit2\n 36 DECD3 CD.D3 ; Port A [00h], aka Data ;PortA.Bit3\n 37 DECD4 CD.D4 ; ;PortA.Bit4\n 38 DECD5 CD.D5 ; ;PortA.Bit5\n 39 VSS GND ;\n 40 DECD6 CD.D6 ; ;PortA.Bit6\n 41 DECD7 CD.D7 ;/ ;PortA.Bit7\n 42 NC NC ;maybe PortD.Bit0?\n 43 DATA SPU74 (via 22 ohm) ;PortD.Bit1\n 44 XLAT SPU75 (via 22 ohm) ;PortD.Bit2\n 45 CLOK SPU76 (via 22 ohm) ;PortD.Bit3\n 46 DECCS SPU94 ;PortD.Bit4\n 47 DECWR SPU95 ;PortD.Bit5\n 48 DECRD SPU96 ;PortD.Bit6\n 49 LDON IC723.Pin11 ;PortD.Bit7\n 50 NC NC (TEST:TX/out) (VCD:SIO.IN/in) ;\\PortF (used by ;PortF.Bit0\n 51 NC NC (TEST:RX/in) (VCD:SIO.OUT/out) ; Motorola Testmode;PortF.Bit1\n 52 NC NC (TEST:RTS/out) (VCD:SIO.CLK/out) ;/and VCD version) ;PortF.Bit2\n PU-8 4.0000MHz from separate 4.000MHz oscillator (X302)\n PU-16 4.0000MHz from separate 4.000MHz oscillator (X302)\n DTL-H2000 4.1900MHz from separate 4.1900MHz oscillator (SPC700, not HC05)\n PU-18 4.2336MHz from CXD2545Q.pin68 (Servo+Signal) (FSOF=16.9344MHz/4)\n PU-20 4.2xxxMHz from CXD1817R.pin? (Servo+Signal+Decoder)\n PM-41 4.2xxxMHz from CXD2938Q.pin11 (Servo+Signal+Decoder+SPU)\n 1 VDD\n 2 FP28/PE6 ;\\\n 3 FP29/PE5 ;\n 4 FP30/PE4 ;\n 5 FP31/PE3 ; Port E LSBs\n 6 FP32/PE2 ;\n 7 FP33/PE1 ;\n 8 FP34/PE0 ;/\n 9 FP35/PD7 ;\\\n 10 FP36/PD6 ; Port D MSBs\n 11 FP37/PD5 ;\n 12 FP38/PD4 ;/\n 13 VLCD3\n 14 VLCD2\n 15 VLCD1\n 16 VSS\n 17 NDLY\n 18 XOSC1\n 19 XOSC2\n 20 /RESET\n ---\n 21 OSC1\n 22 OSC2\n 23 PA0 ;\\\n 24 PA1 ;\n 25 PA2 ;\n 26 PA3 ; Port A\n 27 PA4 ;\n 28 PA5 ;\n 29 PA6 ;\n 30 PA7 ;/\n 31 PB0/KWI0 ;\\\n 32 PB1/KWI1 ;\n 33 PB2/KWI2 ;\n 34 PB3/KWI3 ; Port B\n 35 PB4/KWI4 ;\n 36 PB5/KWI5 ;\n 37 PB6/KWI6 ;\n 38 PB7/KWI7 ;/\n 39 PC0/SDI ;\\\n 40 PC1/SDO ;\n --- ;\n 41 PC2/SCK ; Port C\n 42 PC3/TCAP ;\n 43 PC4/EVI ;\n 44 PC5/EVO ;\n 45 PC6/IRQ2 ;\n 46 PC7/IRQ1 ;/\n 47 VDD\n 48 BP3/PD3 ;\\\n 49 BP2/PD2 ; Port D LSBs\n 50 BP1/PD1 ;\n 51 BP0 (no \"PD0\") ;/\n 52 FP0\n 53 FP1\n 54 FP2\n 55 FP3\n 56 FP4\n 57 FP5\n 58 FP6\n 59 FP7\n 60 VSS\n ---\n 61 FP8\n 62 FP9\n 63 FP10\n 64 FP11\n 65 FP12\n 66 FP13\n 67 FP14\n 68 FP15\n 69 FP16\n 70 FP17\n 71 FP18\n 72 FP19\n 73 FP20\n 74 FP21\n 75 FP22\n 76 FP23\n 77 FP24\n 78 FP25\n 79 FP26\n 80 FP27/PE7 ;- Port E MSB\nSony's Digital Joypad and Mouse contain 32pin CPUs, which are probably also HC05's: Pinouts - Component List and Chipset Pin-Outs for Digital Joypad, SCPH-1080 Moreover, some old memory cards contain a 64pin Motorola SC419510FU (probably also a HC05) with separate Atmel AT29LV010A (128Kx8 FLASH).
"},{"location":"pinouts/#pinouts-mem-pinouts","title":"Pinouts - MEM Pinouts","text":""},{"location":"pinouts/#ic102-bios-rom-32pin-512kx8-used-on-late-pu-8-boards-and-newer-boards","title":"IC102 - BIOS ROM (32pin, 512Kx8, used on LATE-PU-8 boards, and newer boards)","text":" 1-A19 5-A7 9-A3 13-D0 17-D3 21-D7 25-A11 29-A14\n 2-A16 6-A6 10-A2 14-D1 18-D4 22-/CE 26-A9 30-A17 ;/CE=/BIOS\n 3-A15 7-A5 11-A1 15-D2 19-D5 23-A10 27-A8 31-A18\n 4-A12 8-A4 12-A0 16-GND 20-D6 24-/OE 28-A13 32-3.5V ;/OE=/RD\n 1-A18 6-A4 11-GND 16-D9 21-VCC 26-D6 31-GND(/BYTE) 36-A13\n 2-A8 7-A3 12-/OE 17-D2 22-D4 27-D14 32-A17 37-A12\n 3-A7 8-A2 13-D0 18-D10 23-D12 28-D7 33-A16 38-A11\n 4-A6 9-A1 14-D8 19-D3 24-D5 29-A0(D15) 34-A15 39-A10\n 5-A5 10-/CS 15-D1 20-D11 25-D13 30-GND 35-A14 40-A9\n 1-NC 5-A7 9-A3 13-GND 17-D1 21-D3 25-D12 29-D14 33-/BYT 37-A14 41-A10\n 2-A19 6-A6 10-A2 14-/OE 18-D9 22-D11 26-D5 30-D7 34-A17 38-A13 42-A9\n 3-A18 7-A5 11-A1 15-D0 19-D2 23-VCC 27-D13 31-D15/A0 35-A16 39-A12 43-NC\n 4-A8 8-A4 12-/CE 16-D8 20-D10 24-D4 28-D6 32-GND 36-A15 40-A11 44-NC\nUnknown. Note: The newer 70pin RAM comes up without external /REFRESH signal, but maybe the 28pin RAMs required refresh (the CPU has some odd delays once and when).
"},{"location":"pinouts/#ic106-cpu-ram-single-70pin-chip-on-newer-boards","title":"IC106 - CPU-RAM (single 70pin chip, on newer boards)","text":"\"Samsung K4Q153212M-JC60\" (70pin, 512Kx32) (newer boards) \"Toshiba T7X16\" (70pin, 512Kx32) (newer boards, too)
1-VCC 11-N.C 21-DQ15 31-A3 41-N.C 51-DQ17 61-DQ24\n 2-DQ0 12-VCC 22-N.C 32-A4 42-N.C 52-DQ18 62-DQ25\n 3-DQ1 13-DQ8 23-N.C! 33-A5 43-/OE 53-DQ19 63-DQ26\n 4-DQ2 14-DQ9 24-N.C 34-A6 44-/W 54-VSS 64-DQ27\n 5-DQ3 15-DQ10 25-N.C 35-VCC 45-/CAS3 55-DQ20 65-VSS\n 6-VCC 16-DQ11 26-N.C 36-VSS 46-/CAS2 56-DQ21 66-DQ28\n 7-DQ4 17-VCC 27-/RAS 37-A7 47-/CAS1 57-DQ22 67-DQ29\n 8-DQ5 18-DQ12 28-A0 38-A8 48-/CAS0 58-DQ23 68-DQ30\n 9-DQ6 19-DQ13 29-A1 39-A9 49-N.C 59-VSS 69-DQ31\n 10-DQ7 20-DQ14 30-A2 40-N.C 50-DQ16 60-N.C 70-VSS\nSEC KM48V514BJ-6 (DRAM 512Kx8) (four pieces = 512Kx32 = 2Mbyte)
1-VCC 5-DQ3 9-A9 13-A3 17-A5 21-NC 25-DQ5\n 2-DQ0 6-NC 10-A0 14-VCC 18-A6 22-/OE 26-DQ6\n 3-DQ1 7-/W 11-A1 15-GND 19-A7 23-/CAS 27-DQ7\n 4-DQ2 8-/RAS 12-A2 16-A4 20-A8 24-DQ4 28-GND\nEliteMT M11B416256A-35J (256K x 16bit) (40pin SOJ, PM-41 boards) Nippon Steel NN514256ALTT-50 (256K x 16bit) (40pin TSOP-II, PU-23 boards) Toshiba TC51V4260DJ-70 (40pin, PU-8 board) (PseudoSRAM)
1-5.0V 6-5.0V 11-NC 16-A0 21-VSS 26-A8 31-I/O8 36-I/O12\n 2-I/O0 7-I/O4 12-NC 17-A1 22-A4 27-/OE 32-I/O9 37-I/O13\n 3-I/O1 8-I/O5 13-/WE 18-A2 23-A5 28-/CASH 33-I/O10 38-I/O14\n 4-I/O2 9-I/O6 14-/RAS 19-A3 24-A6 29-/CASL 34-I/O11 39-I/O15\n 5-I/O3 10-I/O7 15-NC 20-5.0V 25-A7 30-NC 35-VSS 40-VSS\n\"HM62W256LFP-7T\" (SRAM 32Kx8) (PCB bottom side) (PU-8) \"SONY CXK5V8257BTM\" 32Kx8 SRAM (PU-18)
1-A14 4-A6 7-A3 10-A0 13-D2 16-D4 19-D7 22-/OE 25-A8 28-VCC\n 2-A12 5-A5 8-A2 11-D0 14-GND 17-D5 20-/CS 23-A11 26-A13\n 3-A7 6-A4 9-A1 12-D1 15-D3 18-D6 21-A10 24-A9 27-/WE\nSamsung KM4132G271BQ-10 (128K x 32bit x 2 Banks, Synchronous Graphic RAM) 1MB Samsung K4G163222A-PC70 (256K x 32bit x 2 Banks, Synchronous Graphic RAM) 2MB
1-DQ3 13-DQ19 25-/WE 37-N.C 49-A6 61-DQ9 73-VDDQ 85-VSS 97-DQ0\n 2-VDDQ 14-VDDQ 26-/CAS 38-N.C 50-A7 62-VSSQ 74-DQ24 86-N.C 98-DQ1\n 3-DQ4 15-VDD 27-/RAS 39-N.C 51-A8 63-DQ10 75-DQ25 87-N.C 99-VSSQ\n 4-DQ5 16-VSS 28-/CS 40-N.C 52-N.C 64-DQ11 76-VSSQ 88-N.C 100-DQ2\n 5-VSSQ 17-DQ20 29-A9(BA) 41-N.C 53-DSF 65-VDD 77-DQ26 89-N.C\n 6-DQ6 18-DQ21 30-NC(GND) 42-N.C 54-CKE 66-VSS 78-DQ27 90-N.C\n 7-DQ7 19-VSSQ 31-A0 43-N.C 55-CLK 67-VDDQ 79-VDDQ 91-N.C\n 8-VDDQ 20-DQ22 32-A1 44-N.C 56-DQM1 68-DQ12 80-DQ28 92-N.C\n 9-DQ16 21-DQ23 33-A2 45-N.C 57-DQM3 69-DQ13 81-DQ29 93-N.C\n 10-DQ17 22-VDDQ 34-A3 46-VSS 58-NC 70-VSSQ 82-VSSQ 94-N.C\n 11-VSSQ 23-DQM0 35-VDD 47-A4 59-VDDQ 71-DQ14 83-DQ30 95-N.C\n 12-DQ18 24-DQM2 36-N.C 48-A5 60-DQ8 72-DQ15 84-DQ31 96-VDD\nThe \"should-be\" CPU clock is 33.868800 Hz (ie. the 44100Hz CDROM/Audio clock, multiplied by 300h). However, the different PSX/PSone boards are using different oscillators, multipliers and dividers, which aren't exactly reaching that \"should-be\" value. The PSone are using a single oscillator for producing CPU/GPU clocks, and for producing the TV/color signal:
For PAL, Fsc=4.43361875MHz (5^6*283.75Hz+25Hz) --> 4*Fsc=17.734MHz\n For NTSC, Fsc=3.579545MHz (4.5*455/572 MHz) --> 4*Fsc=14.318MHz\nClock Multiplier/Divider
1 53MHz ;17.734MHz*3 = 53.202 MHz (?)\n 2 GND\n 3 X1 17.734MHz\n 4 X2 17.734MHz\n 5 67MHz ;17.734MHz*3*2*7/11 = 67.711636 MHz (?)\n 6 4.4Mhz ;17.734MHz/4 = 4.4335MHz (?) ;via 2K2 to IC502.pin15\n 7 3.5V\n 8 3.5V\nUnknown. Uses a 14.318MHz oscillator, so multiply/divide factors must be somehow different.
3*3*7*5/2/11 = 14.3181818\n 3*3*7*7*100 = 44100\n 14.3181818 * 3*7*11*64 / (5*5*5*5*5) = 67.737600\n 14.3181818 * 2*2*13/11 ... or so?\nPU-7 and PU-8 boards are using three separate oscillators:
X101: 67.737MHz (div2 = CPU Clock = 33.8685MHz) (div600h = 44.1kHz audio)\n X201: 53.20MHz (GPU Clock) (div12 = PAL color clock)\n X302: 4.000MHz (for CDROM SUB CPU)\nPU-7 and PU-8 boards are using three separate oscillators:
X101: 67.737MHz (div2 = CPU Clock = 33.8685MHz) (div600h = 44.1kHz audio)\n X201: 53.69MHz (GPU Clock) (div15 = NTSC color clock)\n X302: 4.000MHz (for CDROM SUB CPU)\n +7.5V Used to generate other voltages and CDROM/Joypad/MemoryCard/Expansion\n +5.0V Used for Multiout, IC405, and IC502, and IC602\n +3.5V Used for most ICs, and for Joypad/MemoryCard/Expansion\n +3.48V Used for SPU and CDROM\n GND Ground, shared for all voltages\nThere are a lot of SMD elements marked FBnnn, these are NOT fuses (at least they don't seem to blow-up whatever you do). The actual fuses are marked PSnnn, found near the power switch and near the power socket.
"},{"location":"pinouts/#ic601-3pin-50v-78m05-rz125-on","title":"IC601 3pin +5.0V \"78M05, RZ125, (ON)\"","text":" 1 +7.5V\n 2 GND\n 3 +5.0V (used for Multiout, IC405, and IC502)\nCalled \"LP29851MX-3.5\" in service manual.
1 VIN 5.0V (in)\n 2 GND GND\n 3 ON/OFF 5.0V (in)\n 4 NOISE ?\n 5 VOUT 3.48V (out)\n IC002 IC003 Expl.\n 2 2 connected to Q002 (reset input?)\n 5 5 connected via capacitor to GND\n 6 1 reset-output (IC002=wired to /RES, IC003: via Q004 to /RES)\n 7 - 7.5V\n 4 3 GND\n 1,3,8 4 NC\n 1 1IN+\n 2 1IN-\n 3 FEEDBACK\n 4 DTC\n 5 CT\n 6 RT\n 7 GND\n 8 C1\n 9 E1\n 10 E2\n 11 C2\n 12 VCC\n 13 OUTPUT CTRL\n 14 REF\n 15 2IN-\n 16 2IN+\n x +7.5V\n y +3.5V\n z REG\n 1 Brown 7.5V (actually 7.69V)\n 2 Red GND Ground\n 3 Orange 3.5V (actually 3.48V)\n 4 Yellow GND Ground\n 5 White STAND-BY (3.54V, always ON, even if power switch is off)\n 6 Blue GND Ground\n 7 Magenta /RES Reset input (from power-on logic and reset button)\n 1 Brown 7.5V (actually 7.92V or so) (ie. higher than in PSone)\n 2 Red GND Ground\n 3 Orange 3.5V (actually 3.53V or so) (ie. quite same as PSone)\n 4 Yellow GND Ground\n 5 White /RES Reset input (from power-on logic and reset button)\n 1 /IRQ10 (/IRQ10)\n 2 /ACK (/IRQ7)\n 3 /JOY2\n 4 7.5V (or actually 7.92V)\n 5 /JOY1\n 6 DAT\n 7 GND\n 8 CMD\n 9 3.5V\n 10 CLK\n Case: \"SONY, CONTROLLER, Sony Computer Entertainment Inc. H\"\n Case: \"SCPH-1080 Made in China\"\n PCB: \"CMK-PIHB /\\, CFS8121-200010-01\"\n U?: 32pin \"(M), SC401800, FB C37B, JSJD520C\" (Motorola) (TQFP-32 package)\n U?: 14pin \"BA10339F, 528 293\" (Quad Comparator) (/ACK,JOYDAT,and reset or so)\n X?: 3pin \"4.00G1f\" (on PCB bottom side)\n Z1: 2pin z-diode or so (on PCB bottom side) (+1.7V VREF for BA10339F)\n CN?: 7pin cable to controller port (plus shield; but not connected to PCB)\n C1 2pin to GND and R5\n C2 2pin capacitor for power supply input (between +3.5V and GND)\n C3 2pin between BA.pin8 and (via R6) BA.pin15\n R1 2pin 1M ohm (for X1)\n R2 2pin 2.7K\n R3 2pin 8xK ohm?\n R4 2pin 100K\n R5 2pin 22K ohm\n R6 2pin 56K ohm\n RN1 8pin 4x200 ohm (/JOYn,JOYCMD,JOYCLK)\n RN2 8pin 4x22K ohm (pull-ups for button bit0..3)\n RN3 8pin 4x22K ohm (pull-ups for button bit12..15)\n RN4 8pin 4x22K ohm (pull-ups for button bit8..11)\n RN5 8pin 4x22K ohm (pull-ups for button bit4..7)\n PSX.1 -------brown---- PAD.2 JOYDAT\n PSX.2 -------orange--- PAD.6 JOYCMD\n PSX.3 --- NC +7.5V\n PSX.4 -------black---- PAD.3 GND\n PSX.5 -------red------ PAD.4 +3.5V\n PSX.6 -------yellow--- PAD.5 /JOYn\n PSX.7 -------blue----- PAD.7 JOYCLK\n PSX.8 --- NC /IRQ10\n PSX.9 -------green---- PAD.1 /ACK\n PSX.Shield --shield--- NC (cable is shielded but isn't connected in joypad)\n 1 Bit14 SW-X\n 2 Bit13 SW-O\n 3 Bit12 SW-/\\\n 4 Bit11 SW-R1 (via cable pin1, white wire)\n 5 Bit10 SW-L1 (via cable pin1, white wire)\n 6 Bit9 SW-R2 (via cable pin3, black wire)\n 7 Bit8 SW-L2 (via cable pin3, black wire)\n 8 via BA10339F.pin7 to cn.2 JOYDAT (PSX.1)\n ---\n 9 via RN1 (200 ohm) to cn.5 /JOYn (PSX.6)\n 10 via RN1 (200 ohm) to cn.6 JOYCMD (PSX.2)\n 11 via RN1 (200 ohm) to cn.7 JOYCLK (PSX.7)\n 12 GND to cn.3 (PSX.4)\n 13 Bit7 SW-LEFT\n 14 Bit6 SW-DOWN\n 15 Bit5 SW-RIGHT\n 16 via BA10339F.pin5 to cn.1 /ACK (PSX.9)\n ---\n 17 Bit4 SW-UP\n 18 Bit3 SW-START\n 19 Bit2 (HI) (would be R3 on Analog Pads) ;\\unused, but working button inputs\n 20 Bit1 (HI) (would be L3 on Analog Pads) ;/(each fitted with a RN2 pullup)\n 21 Bit0 SW-SELECT\n 22\n 23\n 24 wired to SC401800.pin25\n ---\n 25 wired to SC401800.pin24\n 26 4.00MHz'a\n 27 4.00MHz'b\n 28 +3.5V to cn.4 (PSX.5)\n 29 wired to SC401800.pin32, and via 22K ohm to +3.5V, and to BA.14\n 30\n 31 Bit15 SW-[]\n 32 wired to SC401800.pin29\n 1 OUT2 CN.2 JOYDAT (PSX.1)\n 2 OUT1 CN.1 /ACK (PSX.9)\n 3 VCC +3.5V\n 4 -IN1 +1.7V VREF via Z1 to GND\n 5 +IN1 CXD.16 /ACK\n 6 -IN2 +1.7V VREF via Z1 to GND\n 7 +IN2 CXD.8 JOYDAT\n ---\n 8 -IN3 +1.7V VREF via Z1 to GND\n 9 +IN3 C3,R3,R4\n 10 -IN4 C1 to +3.5V\n 11 +IN4 GND\n 12 GND GND\n 13 OUT4 NC ??\n 14 OUT3 CXD.29/32\nThis applies for two controller versions:
SCPH-1150 Analog Pad with Single Rumble Motor (japan only)\n SCPH-1180 Analog Pad without Rumble Motor\n Case \"SONY, ANALOG, CONTROLLER, SonyCompEntInc. A, SCPH-1150 MADE IN CHINA\"\n PCB1 \"DD1P09A\" (mainboard with digital buttons)\n PCB2 \"DD1Q14A\" (daughterboard with analog joysticks)\n PCB3 \"DD1Q15A-R\" (daughterboard with R-1, R-2 buttons) (J3)\n PCB4 \"DD1Q15A-L\" (daughterboard with L-1, L-2 buttons) (J2)\n U1 42pin \"SD657, 9702K3006\" (2x21pins, L=17.8mm, W=7mm, W+Pins=11mm)\n U2 3pin \"DR, 4.Z\"\n Q1 3pin \"BQ03\" or so (motor post-amp)\n Q2 3pin \"S6\",\"SG\",\"9S\" or so (motor pre-amp)\n Y1 3pin \"400CMA\"\n CN1 8pin cable to PSX controller port\n CN2 8pin ribbon cable to analog-joystick daughterboard (not so robust cable)\n J1 2pin wires to rumble motor (in left handle) (digital, on/off)\n J2 3pin ribbon cable to L-1, L-2 button daughterboard\n J3 3pin ribbon cable to R-1, R-2 button daughterboard\n LED1 4pin red/green LED (optics without mirror)\n D1,D2 diodes\n plus resistors/capacitors\nCN1 (cable to PSX controller port) (same for SCPH-1150 and SCPH-1200)
PSX.1 -------brown---- PAD.2 JOYDAT\n PSX.2 -------orange--- PAD.6 JOYCMD\n PSX.3 -------magenta-- PAD.8 +7.5V\n PSX.4 -------black---- PAD.3 GND\n PSX.5 -------red------ PAD.4 +3.5V\n PSX.6 -------yellow--- PAD.5 /JOYn\n PSX.7 -------blue----- PAD.7 JOYCLK\n PSX.8 --- NC /IRQ10\n PSX.9 -------green---- PAD.1 /ACK\n PSX.Shield --shield--- NC (cable is shielded but isn't connected in joypad)\n 8 +3.5V to POT pins\n 7 Button L3 pins A,C\n 6 GND to POT pins and Button L3/R3 pins B,D\n 5 Button R3 pins A,C\n 4 Axis R_Y middle POT pin (SD657.18)\n 3 Axis R_X middle POT pin (SD657.17)\n 2 Axis L_Y middle POT pin (SD657.16)\n 1 Axis L_X middle POT pin (SD657.15)\n 1 (red) R1\n 2 (gray) GND\n 3 (gray) R2\n 1 (red) L1\n 2 (gray) GND\n 3 (gray) L2\n 1 (red) +7.5V\n 2 (black) Q1\nU1 42pin \"SD657, 9702K3006\"
1 NC?\n 2 NC?\n 3 /RESET? (U2.3)\n 4 OSC\n 5 OSC\n 6 BUTTON Bit3 START SW1\n 7 BUTTON Bit2 R3 (via CN2.5)\n 8 BUTTON Bit1 L3 (via CN2.7)\n 9 BUTTON Bit0 SELECT SW3\n 10 GND\n 11 BUTTON Bit7 LEFT SW4\n 12 BUTTON Bit6 DOWN SW5\n 13 BUTTON Bit5 RIGHT SW6\n 14 BUTTON Bit4 UP SW7\n 15 Analog Axis L_X (via CN2.1)\n 16 Analog Axis L_Y (via CN2.2)\n 17 Analog Axis R_X (via CN2.3)\n 18 Analog Axis R_Y (via CN2.4)\n 19 NC?\n 20 3.5V\n 21 3.5V\n ---\n 22 BUTTON Bit15 [] SW11\n 23 BUTTON Bit14 >< SW10\n 24 BUTTON Bit13 () SW9\n 25 BUTTON Bit11 R1 (via J3.1)\n 26 BUTTON Bit12 /\\ SW8\n 27 BUTTON Bit10 L1 (via J3.1)\n 28 BUTTON Bit9 R2 (via J3.3)\n 29 BUTTON Bit8 L2 (via J3.3)\n 30 PSX.2/CN1.6 JOYCMD orange (via 220 ohm R14)\n 31 PSX.1/CN1.2.JOYDAT brown (via 22 ohm R13 and diode D2)\n 32 PSX.7/CN1.7 JOYCLK blue (via 220 ohm R12)\n 33 PSX.6/CN1.5./JOYn yellow (via 220 ohm R11)\n 34 LED.GREEN (LED.4)\n 35 LED.RED (LED.3)\n 36 MOTOR (via 4.7Kohm R8 to Q2, then via Q1 to motor)\n 37 NC?\n 38 NC?\n 39 PSX.9/CN1.1./ACK green (via 22 ohm R10)\n 40 NC?\n 41 MODE SW2 (analog button)\n 42 GND\n 1 from 3.5V (via R1,D1,R2)\n 2 to U1.3 (/RESET?) (U2.rear contact = same as U2.pin2)\n 3 GND\n 1 Q2.2 (via 1Kohm R7)\n 2 to Motor (-)\n 3 GND\n 1 SD657.36 (via 4.7Kohm R8)\n 2 Q1.1 (via 1Kohm R7) (and via 100Kohm R13 to GND)\n 3 3.5V\nLeft/Single Motor (SCPH-1150)
27.5mm Total Length (18.5mm Motor, 2mm Axis, 7mm Weight/block)\n 12.0mm Width/Diameter (of Weight, and of Motor at flat side)\n Case \"SONY, ANALOG, CONTROLLER, SonyCompEntInc. H, SCPH-1200 MADE IN CHINA\"\n PCB1 \"01, /\\YG-H2, (r)RU\" (mainboard with digital buttons)\n PCB2 \"M-29-01, YG-H3, (r)RU\" (daughterboard with analog joysticks)\n PCB3 \"E, /\\YG-H2, (r)RU, 01\" (daughterboard with R-1, R-2 buttons) (J1)\n PCB4 \"01, W, /\\YG-H2, (r)RU\" (daughterboard with L-1, L-2 buttons) (J2)\n U1 44pin \"SONY, CXD8771Q 4A03, JAPAN 9840 HAL, 148896\"\n U2 4pin \",\\\\ 29\" (PST9329) (System Reset with 2.9V detection voltage)\n U3 8pin \"2904, 8346G, JRC\" (NJM2904) (Dual Operational Amplifier)\n Q1 3pin \".Y S'\" (big transistor for big M1 rumble motor)\n Q2 3pin \"Z\" (small transistor for small M2 rumble motor)\n Y1 3pin \"800CMLX\" or so (hides underneath of the CN2 ribbon cable)\n CN1 8pin cable to PSX controller port\n CN2 8pin ribbon cable to analog-joystick daughterboard\n J1 3pin ribbon cable to R-1, R-2 button daughterboard\n J2 3pin ribbon cable to L-1, L-2 button daughterboard\n M1 2pin wires to left/big rumble motor (analog, slow/fast)\n M2 2pin wires to right/small rumble motor (digital, on/off)\n ZD1,ZD2 some Z-diodes\n D1,D2 diodes near M1,M2 motors (these diodes aren't installed)\n LED1 red analog mode LED (with transparent optics/light direction mirror)\n plus resistors/capacitors\nNote: There's also a different SCPH-1200 revision, which having a smaller mainboard with analog joysticksonboard, plus a single sided PCB for the digital buttons (that is, similar to SCPH-110, but with the single sided PCB instead of membrane foil).
"},{"location":"pinouts/#analog-joypad-connection-cables-scph-1200","title":"Analog Joypad Connection Cables (SCPH-1200)","text":"CN1 (cable to PSX controller port) (same for SCPH-1150 and SCPH-1200)
PSX.1 -------brown---- PAD.2 JOYDAT\n PSX.2 -------orange--- PAD.6 JOYCMD\n PSX.3 -------magenta-- PAD.8 +7.5V\n PSX.4 -------black---- PAD.3 GND\n PSX.5 -------red------ PAD.4 +3.5V\n PSX.6 -------yellow--- PAD.5 /JOYn\n PSX.7 -------blue----- PAD.7 JOYCLK\n PSX.8 --- NC /IRQ10\n PSX.9 -------green---- PAD.1 /ACK\n PSX.Shield --shield--- NC (cable is shielded but isn't connected in joypad)\n 1 +3.5V to POT pins\n 2 Button L3 pins C,D\n 3 GND to POT pins and Button L3/R3 pins A,B\n 4 Button R3 pins C,D\n 5 Axis R_Y middle POT pin (CXD.20)\n 6 Axis R_X middle POT pin (CXD.19)\n 7 Axis L_X middle POT pin (CXD.21)\n 8 Axis L_Y middle POT pin (CXD.22)\n 1 (red) R1\n 2 (gray) GND\n 3 (gray) R2\n 1 (red) L1\n 2 (gray) GND\n 3 (gray) L2\n + (red) Q1.E\n - (black) GND\n + (red) +7.5V\n - (black) Q2.C\nU1 SONY CXD8771Q
1 PSX.7/CN1.7 JOYCLK (via 220 ohm R2)\n 2 via R10 to U3.3 (for big M1 motor)\n 3 via R15 to Q2.B (for small M2 motor)\n 4 GND\n 5 BUTTON Bit15 []\n 6 BUTTON Bit14 ><\n 7 BUTTON Bit13 ()\n 8 BUTTON Bit12 /\\\n 9 BUTTON Bit11 R1 (via J1.1)\n 10 BUTTON Bit10 L1 (via J2.1)\n 11 BUTTON Bit9 R2 (via J1.3)\n ---\n 12 BUTTON Bit8 L2 (via J2.3)\n 13 GND\n 14 U2.Pin3 (reset)\n 15 Y1'a\n 16 Y1'b\n 17 GND\n 18 +3.5V\n 19 Analog Axis R_X via CN2.6\n 20 Analog Axis R_Y via CN2.5\n 21 Analog Axis L_X via CN2.7\n 22 Analog Axis L_Y via CN2.8\n ---\n 23 GND\n 24 GND\n 25 GND\n 26 GND\n 27 GND\n 28 +3.5V\n 29 BUTTON Bit0 SELECT\n 30 BUTTON Bit1 L3 (via CN2.2)\n 31 BUTTON Bit2 R3 (via CN2.4)\n 32 BUTTON Bit3 START\n 33 BUTTON Bit4 UP\n ---\n 34 BUTTON Bit5 RIGHT (aka spelled RIHGT on the PCB)\n 35 BUTTON Bit6 DOWN\n 36 BUTTON Bit7 LEFT\n 37 PSX.6/CN1.5./JOYn (via 220 ohm R1)\n 38 ANALOG BUTTON\n 39 GND\n 40 +3.5V\n 41 /LED (to LED1, and from there via 300 ohm R6 to +3.5V)\n 42 PSX.9/CN1.1./ACK (via 22 ohm R5)\n 43 PSX.1/CN1.2.JOYDAT (via 22 ohm R3)\n 44 PSX.2/CN1.6 JOYCMD (via 220 ohm R4)\n 1 NC GND\n 2 GND GND\n 3 Vout U1.14\n 4 VCC +3.5V\n 1 A.OUTPUT Q1.B (big motor M1 transistor)\n 2 A.INPUT- to R11/R12\n 3 A.INPUT+ to R10/R17\n 4 GND PSX.4/CN1.3 GND\n 5 B.INPUT+ GND\n 6 B.INPUT- NC?\n 7 B.OUTPUT NC?\n 8 VCC PSX.3/CN1.8 +7.5V\n E M1+\n B U3.1 (NJM2904)\n C +7.5V\n E GND\n B via 1K ohm R15 to U1.3 (CXD), and via 100K ohm R16 to GND\n C M2-\n Left/Large Motor (SCPH-1200)\n 24.0mm Total Length (12.0mm Motor, 2.5mm Axis, 9.5mm Weight/plates)\n 24.0mm Diameter (Motor), 20.0mm Diameter (Weight/plates)\n Right/Small Motor (SCPH-1200)\n 25.4mm Total Length (18.7mm Motor, 2mm Axis, 4.7mm Weight/plates)\n 12.0mm Width/Diameter (of Weight, and of Motor at flat side)\n Case \"SONY, ANALOG CONTROLLER, SonyCompEntInc. A, SCPH-110 MADE IN CHINA\"\n PCB1 \"SA1Q22A, <PF-LP>, KPC, 7694V-0\" (mainboard with joysticks onboard)\n PCB2 \"...\" (membrane/foil with digital buttons)\n U1 44pin \"SD707, 039 107\"\" (4x11pin)\n Q1 3pin \"KA\" (big transistor for left/big M1 rumble motor)\n Q2 3pin \"LG\" (small transistor for right/small M2 rumble motor)\n D1 2pin diode (for large motor, reference Z-diode with pull-up?)\n D2 3pin dual-diode (R5/IRQ7 to GND and R3/DAT to GND)\n CN1 9pin cable to PSX controller port\n J1 16pin ribbon cable from membrane/foil\n M1 2pin wires to left/big rumble motor (analog, slow/fast)\n M2 2pin wires to right/small rumble motor (digital, on/off)\n LED1 2pin red analog mode LED (with long legs, without mirror/optics)\n plus resistors/capacitors\nCN1 (cable to PSX controller port)
1 +3.5V (logic supply)\n 2 GND3 (logic supply)\n 3 /IRQ7\n 4 /SEL\n 5 CMD\n 6 DAT\n 7 CLK\n 8 GND7 (motor supply)\n 9 +7.5V (motor supply)\n 1 BUTTON Bit8 L2\n 2 BUTTON Bit10 L1\n 3 BUTTON Bit4 UP\n 4 BUTTON Bit5 RIGHT\n 5 BUTTON Bit6 DOWN\n 6 BUTTON Bit7 LEFT\n 7 GND3\n 8 ANALOG BUTTON\n 9 BUTTON Bit0 SELECT\n 10 BUTTON Bit3 START\n 11 BUTTON Bit15 SQUARE []\n 12 BUTTON Bit14 CROSS ><\n 13 BUTTON Bit13 CIRCLE ()\n 14 BUTTON Bit12 TRIANGLE /\\\n 15 BUTTON Bit11 R1\n 16 BUTTON Bit9 R2\n 1 (red) Q1\n 2 (black) GND (via some ohm)\n 1 (red) +7.5V\n 2 (black) Q2\n 1 via R9/Q2 to M2 (right/small) (digital 0V=off, 3V=on)\n 2 via \"JP1\" to LED (330 ohm)\n 3 +3.5V\n 4 BUTTON Bit2 R3\n 5 vr2 RX (lt/rt)\n 6 vr1 RY (up/dn)\n 7 vr4 LX (lt/rt)\n 8 vr3 LY (up/dn)\n 9 BUTTON Bit1 L3\n 10 GND3\n 11 GND7\n ---\n 12 via Q1 to M1 (left/large) (1V=off, 6V=fast)\n 13 via D1/R7 to M1 (left/large) (6.7V)\n 14 +7.5V\n 15 +7.5V\n 16 BUTTON Bit8 L2\n 17 BUTTON Bit10 L1\n 18 BUTTON Bit4 UP\n 19 BUTTON Bit5 RIGHT\n 20 BUTTON Bit6 DOWN\n 21 BUTTON Bit7 LEFT\n 22 GND3\n ---\n 23 BUTTON Bit9 R2\n 24 BUTTON Bit11 R1\n 25 BUTTON Bit12 TRIANGLE /\\\n 26 BUTTON Bit13 CIRCLE ()\n 27 BUTTON Bit14 CROSS ><\n 28 BUTTON Bit15 SQUARE []\n 29 BUTTON Bit3 START\n 30 BUTTON Bit0 SELECT\n 31 ANALOG BUTTON\n 32 NC\n 33 +3.5V\n ---\n 34 GND3\n 35 NC\n 36 via R5 to /IRQ7\n 37 via R1 to /SEL\n 38 via R4 to CMD\n 39 via R3 to DAT\n 40 via R2 to CLK\n 41 +7.5V\n 42 +7.5V\n 43 GND7\n 44 GND7\nVR1..VR4 -- analog inputs R1..R5 -- signals to/from psx R6 ? R7 M1 R8 R9 R10 JP1 C1 3.5V to GND3 (22uF) C2 3.5V to GND3 (U1) C3 VR1 to GND3 C4 VR2 to GND3 C5 VR3 to GND3 C6 VR4 to GND3 C7 M2+ to M2- C8 M1+ to M1- C9 M1 related S5 S6
"},{"location":"pinouts/#motors_1","title":"Motors","text":" Left/Large Motor (SCPH-110)\n 23.0mm Total Length (12.0mm Motor, 3mm Axis, 8.0mm Weight/plates)\n 24.0mm Diameter (Motor), 20.0mm Diameter (Weight/plates)\n Right/Small Motor (SCPH-110)\n 25.4mm Total Length (18.7mm Motor, 2mm Axis, 4.7mm Weight/plates)\n 12.0mm Width/Diameter (of Weight, and of Motor at flat side)\n M1+ --o---Q1---o--------- U1.12\n | | | analog\n Left | | C9\n Large | | |\n | o----o--------- 7.5V\n | |\n C8 R7\n | D1 | 6.7V\n o---|>|--o--------- U1.13\n |\n M1- --o------------------ GND7\nD1 is probably a Z-diode with R7 as pull-up, creating a reference/source voltage at U1.13 for the analog output at U1.12.
M2+ --o------------------ 7.5V\n |\n Right | o-------o--R9-- U1.1\n Small | | | on/off\n C7 | R10\n | | |\n M2- --o---Q2------o------ GND7\n ___ ___ ____\n axis | | / \\ \\\n __/___ ______| m | __.____________|__. | |\n /__/__/ | | w | | | | | | axis | | |\n | |/ weight |___| |___| \\___/_/ \\___/____/\n \\____/ weight motor\nhttp://www.nicolaselectronics.be/reverse-engineering-the-playstation-g-con45/
"},{"location":"pinouts/#namco-lightgun-npc-103-c-1996-namco-ltd-component-list","title":"Namco Lightgun \"NPC-103, (C) 1996 NAMCO LTD.\" Component List","text":"PCB \"DNP-0500A, NPC10300, namco, CMK-P3X\"
U1 44pin \"NAMCO103P, 1611U1263, JAPAN 9847EAI, D0489AAF\"\n U2 8pin \"7071, 8C19\" (=BA7071F, Sync Separator IC with AFC)\n XTAL 2pin \"CSA 8.00WT\"\n PS1 3pin Light sensor with metal shielding\n J1 9pin Connector for 9pin cable to PSX controller and GunCon plugs\n plus resistors and capacitors, and A1,A2,B1,B2,T1,T2 wires to buttons\n DIP Button (with black T1,T2 wires) (trigger)\n Button A (with red A1,A2 wires) (left side)\n Button B (with white B1,B2 wires) (right side)\n Lens (20mm)\n J1.Pin1 green PSX.Controller.Pin5 +3.5V\n J1.Pin2 brown PSX.Controller.Pin4 GND\n J1.Pin3 black PSX.Controller.Pin9 /ACK/IRQ7\n J1.Pin4 red PSX.Controller.Pin6 /JOYn\n J1.Pin5 yellow PSX.Controller.Pin1 JOYDAT\n J1.Pin6 orange PSX.Controller.Pin2 JOYCMD\n J1.Pin7 blue PSX.Controller.Pin7 JOYCLK\n J1.Pin8 gray GunCon shield (GND)\n J1.Pin9 white GunCon composite video\n N/A PSX.Controller.Pin3 +7.5V\n N/A PSX.Controller.Pin8 /IRQ10\n N/A PSX.Controller Shield\n 1 GND 12 SYNC (from U2) 23 3.5V 34 SW1 (A)\n 2 GND 13 3.5V 24 3.5V 35 3.5V\n 3 GND 14 3.5V 25 3.5V 36 3.5V\n 4 GND 15 SW3 (TRIGGER) 26 GND 37 SW2 (B)\n 5 GND 16 JOYCLK (J1.Pin7 via 220 ohm R7) 27 GND 38 3.5V\n 6 GND 17 3.5V 28 GND 39 3.5V\n 7 GND 18 JOYCMD (J1.Pin6 via 220 ohm R8) 29 GND 40 LIGHT (from PS1)\n 8 GND 19 JOYDAT (J1.Pin5 via 0 ohm R10) 30 - 41 GND\n 9 - 20 /JOYn (J1.Pin4 via 220 ohm R9) 31 GND 42 GND\n 10 GND 21 /ACK/IRQ7 (J1.Pin3 via 0 ohm R11) 32 GND 43 OSC 8MHz\n 11 GND 22 GND 33 GND 44 OSC 8MHz\n 1 VIN = SYNC.IN from J1.Pin9 Composite Video (via C5/C6/C7/R6)\n 2 HD_OUT = NC\n 3 GND = GND\n 4 PD_OUT = NC\n 5 HOSC_R = via 100K to GND\n 6 VCC = 3.5V\n 7 VD_OUT = NC\n 8 SYNC_OUT = SYNC.OUT to U1.pin12 (with R4 pull-up)\n Case \"SONY, MULTITAP, SonyComputerEntertainmentInc, SCPH-1070 MADE IN CHINA\"\n PCB1 \"SONY 1-659-343-11\" (mainboard with Slot A,B, ICs, X1, PSX-cable)\n PCB2 \"SONY 1-711-414-11\" (daughterboard with Slot C,D)\n IC? 64pin \"SONY JAPAN, CXD103, -166Q, 550D66E\" (smd/back side)\n IC02 8pin \"7W14, 5K\" some tiny SMD chip (for JOYCLK) (smd/back side)\n X1 2pin \"4.00G CMj\" oscillator (front side)\n J34 2pin fuse or 1 ohm resistor or so (for +3.5V input) (front side)\n Jxx 2pin normal wire bridges (except: J34 is NOT a wire) (front side)\n 1pin black wire Shield/GND (lower edge)\n 1pin black wire Shield/GND (upper edge)\n 2x8pin red/gray ribbon cable (side edge)\n 2x2pin red/gray ribbon cable (lower edge)\n 2pin red/gray ribbon cable (upper middle) (gray=+3.3V, red=+7.5V)\n PSX.1 -------brown------ TAP.1 JOYDAT ;via 47 ohm (R57) to CXD.35\n PSX.2 -------orange----- TAP.2 JOYCMD ;via 220 ohm (R58) to CXD.37\n PSX.3 -------magenta---- TAP.3 +7.5V ;directly to +7.5V on JOY/CARD's\n PSX.4 -------black------ TAP.4 GND ;directly to GND\n PSX.5 -------red-------- TAP.5 +3.5V ;via 1 ohm or so (J34) to +3.3V\n PSX.6 -------yellow----- TAP.6 /JOYn ;via 220 ohm (R59) to CXD.46\n PSX.7 -------blue------- TAP.7 JOYCLK ;via 220 ohm (R60) to IC02.pin6\n PSX.8 -------gray------- TAP.8 /IRQ10 ;via 47 ohm (R02/R16/R30/R44) to JOY's\n PSX.9 -------green------ TAP.9 /ACK ;via 47 ohm (R61) to CXD.51\n PSX.Shield --shield----- TAP.shielding.plate (GND)\n 1 JOYDAT Via 47 ohm (R11/R25/R38/R5x) to CXD.18/29/60/5 (and to JOY slot)\n 2 JOYCMD Via 220 ohm (R10/R24/R39/R52) to CXD.19/30/62/6\n 3 +7.5V Directly to PSX.3\n 4 GND Directly to PSX.4\n 5 +3.3V Via J34 to PSX.5 (+3.5V)\n 6 /JOYn Via 220 ohm (R09/R2x/Rxx/R51) to CXD.11/22/52/61\n 7 JOYCLK Via 220 ohm (R08/R2x/Rxx/R50) to CXD.33/33/47/47\n 9 /ACK Via 47 ohm (R07/R2x/Rxx/R49) to CXD.12/21/45/64\n 1 JOYDAT Via 47 ohm (R06/Rxx/R34/R5x) to CXD.18/29/60/5 (and to CARD slot)\n 2 JOYCMD Via 220 ohm (R05/R19/R35/R5x) to CXD.17/28/59/4\n 3 +7.5V Directly to PSX.3\n 4 GND Directly to PSX.4\n 5 +3.3V Via 1 ohm or so (J34) to PSX.5 (+3.5V)\n 6 /JOYn Via 220 ohm (R04/R18/R32/R4x) to CXD.16/20/55/63\n 7 JOYCLK Via 220 ohm (R03/R17/R31/R45) to CXD.15/23/56/2\n 8 /IRQ10 Via 47 ohm (R02/R16/R30/R44) to PSX.8\n 9 /ACK Via 47 ohm (R01/R15/R29/R43) to CXD.13/27/54/7\n Shield Directly to Shield/GND\n 1\n 2\n 3\n 4 GND\n 5\n 6 via 220 ohm (R60) to PSX.7 (JOYCLK)\n 7 to CXD.Pin48\n 8 +3.3V, aka via 1 ohm (J34) to PSX.5 (+3.5V)\n 1 via to 10K (R63) to +3.3V, and via C13 to GND (probably power-on reset)\n 2 JOY.D.7.JOYCLK\n 3\n 4 JOY.D.2.JOYCMD\n 5 JOY/CARD.D.1.JOYDAT\n 6 CARD.D.2.JOYCMD\n 7 JOY.D.9./ACK\n 8 4MHz X1/C12\n 9 4MHz X1/C11\n 10 GND\n 11 CARD.A.6./JOYn\n 12 CARD.A.9./ACK\n 13 JOY.A.9./ACK\n 14\n 15 JOY.A.7.JOYCLK\n 16 JOY.A.6./JOYn\n 17 JOY.A.2.JOYCMD\n 18 JOY/CARD.A.1.JOYDAT\n 19 CARD.A.2.JOYCMD\n ---\n 20 JOY.B.6./JOYn\n 21 CARD.B.9./ACK\n 22 CARD.B.6./JOYn\n 23 JOY.B.7.JOYCLK\n 24\n 25 GND\n 26 +3.3V\n 27 JOY.B.9./ACK\n 28 JOY.B.2.JOYCMD\n 29 JOY/CARD.B.1.JOYDAT\n 30 CARD.B.2.JOYCMD\n 31 GND\n 32\n ---\n 33 CARD.A/B.7.JOYCLK\n 34\n 35 PSX.1.JOYDAT\n 36\n 37 PSX.2.JOYCMD\n 38\n 39\n 40\n 41\n 42 GND\n 43\n 44 GND\n 45 CARD.C.9./ACK\n 46 PSX.6./JOYn\n 47 CARD.C/D.7.JOYCLK\n 48 IC02.Pin7.PSX.JOYCLK\n 49\n 50\n 51 PSX.9./ACK\n ---\n 52 CARD.C.6./JOYn\n 53\n 54 JOY.C.9./ACK\n 55 JOY.C.6./JOYn\n 56 JOY.C.7.JOYCLK\n 57 GND\n 58 +3.3V\n 59 JOY.C.2.JOYCMD\n 60 JOY/CARD.C.1.JOYDAT\n 61 CARD.D.6./JOYn\n 62 CARD.C.2.JOYCMD\n 63 JOY.D.6./JOYn\n 64 CARD.D.9./ACK\nThe \"SONY CXD8732AQ\" chip is installed on memory cards with \"SPC02K1020B\" boards, however, the text layer on the board says that it's an \"LC86F8604A\" chip. So, the CXD8732AQ is most probably a standard LC86F8604A chip (more on that below) with a Sony Memory Card BIOS ROM on it. The \"SONY CXD8732AQ\" comes in a huge 64pin package, but it connects only to:
5 = /IRQ7 (via 22 ohm) 2 = /RESET (from U2)\n 6 = JOYCLK (via 220 ohm) 30,31 = CF1,CF2 (12 clock pulses per 2us)\n 7 = /JOYn (via 220 ohm) 14,16,25,32,38,39,61 = 3.5V (via 3.3 ohm)\n 12 = JOYCMD (via 220 ohm) 8,15,28,29 = GND\n 13 = JOYDAT (via 22 ohm) All other pins = Not connected\n8bit CPU with 132Kbyte EEPROM, 4Kbyte ROM, 256 bytes RAM, 2 timers, serial port, and general purpose parallel ports. The 132K EEPROM is broken into 128K plus 4K, the 4K might be internally used by the CPU, presumably containing the BIOS (not too sure if it's really containing 4K EEPROM plus 4K ROM, or if it's meant to be only either one).
1=P40/A0 9=P13 17=TP0 25=VDD 33=A11 41=NC 49=A7 57=NC\n 2=/RES 10=P14 18=TP1 26=NC 34=A9 42=NC 50=A6 58=NC\n 3=TEST2 11=P15 19=TP2 27=NC 35=A8 43=NC 51=A5 59=NC\n 4=TEST1 12=P16 20=TP3 28=NC 36=A13 44=NC 52=A4 60=NC\n 5=P10 13=P17 21=TP4 29=VSS 37=A14 45=A17 53=NC 61=NC61\n 6=P11 14=/CE 22=TP5 30=CF1 38=/WE 46=A16 54=NC 62=P43/A3\n 7=P12 15=A10 23=TP6 31=CF2 39=VDD 47=A15 55=NC 63=P42/A2\n 8=VSS 16=/OE 24=TP7 32=VDD 40=EP 48=A12 56=NC 64=P41/A1\n P10/DQ0/SEPMOD P12/DQ2/FSI0 P14/DQ4 P16/DQ6/SI0/FSTART\n P11/DQ1/SCLK0/FSCLK P13/DQ3 P15/DQ5 P17/DQ7/SO0/FRW\nFor the actual pin-outs of the cart-edge connector, see Pinouts - Controller Ports and Memory-Card Ports
"},{"location":"pinouts/#mods-nocash-psx-xboo-upload","title":"Mods - Nocash PSX-XBOO Upload","text":""},{"location":"pinouts/#nocash-psx-xboo-connection-required","title":"Nocash PSX-XBOO Connection (required)","text":" GND (BOARD) --------- GND (SUBD.18-25, CNTR.19-30)\n A16 (ROM.2) --------- SLCT (SUBD.13, CNTR.13) ;\\\n A17 (ROM.30) --------- PE (SUBD.12, CNTR.12) ; 4bit.dta.out\n A18 (ROM.31) --------- /ACK (SUBD.10, CNTR.10) ;\n A19 (ROM.1) --------- BUSY (SUBD.11, CNTR.11) ;/\n /RESET ---|>|--- /INIT (SUBD.16, CNTR.31) ;-reset.in\n D0..D7 (74HC541) --------- DATA (SUBD.2-9, CNTR.2-9) ;\\\n Y0..Y7 (74HC541) --------- D0..D7 (ROM.13-15,17-21) ; 7bit.dta.in, and\n /OE1 (74HC541.1) --------- /EXP (CPU.98) ; 1bit.dta.clk.in\n /OE2 (74HC541.19) --------- /OE (ROM.24) ;\n GND (74HC541.10) --------- GND (BOARD) ;\n VCC (74HC541.20) --------- +5V (BOARD) ;/\n A0..A19 (ROM) --------- A0..A19 (EPROM)\n D0..D7 (ROM) --------- D0..D7 (EPROM)\n /BIOS (CPU.97)--------- /CS (EPROM.22)\n /OE (ROM.24) --------- /OE (EPROM.24)\n +5V (BOARD) --------- VCC (EPROM.32)\n GND (BOARD) --------- GND (EPROM.16)\n /CS (ROM.22) --/cut/-- /BIOS (CPU.97)\n /CS (ROM.22) --------- +5V (BOARD) (direct, or via 100k ohm)\n SPU.Pin42 \"data\" -------|>|------ CPU.Pin149 (A20)\n SPU.Pin5 \"sync\" ---------------- IC723.Pin17\nMods - PAL/NTSC Color Mods
"},{"location":"pinouts/#component-list","title":"Component List","text":" 32pin socket for EPROM\n EPROM (or FLASH)\n 74HC541 (8-bit 3-state noninverting buffer/line driver)\n 1N4148 diode (for reset signal)\n 1N4148 diode (for optional \"modchip\" feature)\n 36pin Centronics socket for printer cable (or 25pin dsub)\nThe required BIOS is contained in no$psx (built-in in the no$psx.exe file), the Utility menu contains a function for creating a standalone ROM-image (file PSX-XBOO.ROM in no$psx folder; which can be then burned to FLASH or EPROM).
"},{"location":"pinouts/#pinouts_1","title":"Pinouts","text":" ______ ______ ____ ____\n | \\/ | | \\/ |\n A19,VPP12 | 1 32 | VCC6 /OE1 |1 20| VCC\n A16 | 2 31 | A18,/PGM D0 |2 19| /OE2\n A15 | 3 30 | A17 D1 |3 18| Y0\n A12 | 4 29 | A14 D2 |4 17| Y1\n A7 | 5 28 | A13 D3 |5 74541 16| Y2\n A6 | 6 27 | A8 D4 |6 15| Y3\n A5 | 7 26 | A9,IDENT12 D5 |7 14| Y4\n A4 | 8 25 | A11 D6 |8 13| Y5\n A3 | 9 24 | /OE,VPP12 D7 |9 12| Y6\n A2 | 10 23 | A10 GND |10 11| Y7\n A1 | 11 22 | /CE,(/PGM) |__________|\n A0 | 12 21 | D7\n D0 | 13 20 | D6\n D1 | 14 19 | D5\n D2 | 15 18 | D4\n GND | 16 17 | D3\n |______________|\nInstead of the above internal mod, the nocash kernel clone can be also installed on cheat devices, which do also include DB25 connectors for parallel port uploads, too. For DB25 parallel port uploads, do the following mods to the cheat device:
- Datel: use the FiveWire mod to get it parallel port compatible\n - Xplorer: simply wire DB25./INIT to EXP./RESET (with diode, if needed)\nThe PSX hardware is more or less capable of generating both PAL and NTSC signals. However, it's having the bad habbit to do this automatically depending on the game's frame rate. And worse, it's doing it regardless of whether the board is having matching oscillators installed (eg. a PAL board in 60Hz mode will produce NTSC encoding with faulty NTSC color clock).
color encoding PAL NTSC\n color clock 4.43361875MHz 3.579545MHz\n frame rate 50Hz 60Hz\nRGB cables don't rely on composite PAL/NTSC color encoding, and thus don't need any color mods (except, see the caution on GNDed pins for missing 53.20MHz/53.69MHz oscillators below).
"},{"location":"pinouts/#newer-consoles-pu-22-pu-23-pm-41-pm-412","title":"Newer Consoles (PU-22, PU-23, PM-41, PM-41(2))","text":"These consoles have 17.734MHz (PAL) or 14.318MHz (NTSC) oscillators with constant dividers, so the color clock will be always constant, and one does only need to change the color encoding:
/PAL (IC502.pin13) ---/cut/--- /PAL (GPU.pin157)\n /PAL (IC502.pin13) ----------- GND (PAL) or VCC (NTSC)\nThese consoles have 53.20MHz (PAL) or 53.69MHz (NTSC) oscillators and the GPU does try to change the clock divider depending on the frame rate (thereby producing a nonsense clock signal that's neither PAL nor NTSC). Best workaround is to install an extra 4.43361875MHz (PAL) or 3.579545MHz (NTSC) oscillator (with internal amplifier, ie. in 4pin package, which resembles DIP14, hence the pin 1,7,8,14 numbering):
GPU ------------------/cut/--- CXA1645M.pin6 SCIN\n GPU ------------------/cut/--- CXA1645M.pin7 /PAL\n Osc.pin14 VCC ---------------- CXA1645M.pin12 VCC (5V)\n Osc.pin7 GND ---------------- CXA1645M.pin1 GND\n Osc.pin8 OUT ---------------- CXA1645M.pin6 SCIN\n Osc.pin1 NC --\n GND (PAL) or VCC (NTSC) ------ CXA1645M.pin7 /PAL\nExternal 4.433MHz/3.579MHz osciallors won't be synchronized with the GPU frame rate (normally you don't want them to be synchronized, but there's some small risk that they might get close to running in sync, which could result in static or crawling color artifacts). For the CXA1645 chip modded to a different console region, one should also change one of the resistors (see datasheet), there's no noticable difference on the TV picture though.
"},{"location":"pinouts/#region-checks","title":"Region Checks","text":"Some kernel versions contain regions checks (additionally to the SCEx check), particulary for preventing NTSC games to run on PAL consoles, or non-japanese games on japanese consoles. Some PAL modchips can bypass that check (by patching the region byte in BIOS). Expansions ROMs or nocash kernel clone could be also used to avoid such checks.
"},{"location":"pocketstation/","title":"Pocketstation","text":"Pocketstation Overview Pocketstation I/O Map Pocketstation Memory Map Pocketstation IO Video and Audio Pocketstation IO Interrupts and Buttons Pocketstation IO Timers and Real-Time Clock Pocketstation IO Infrared Pocketstation IO Memory-Control Pocketstation IO Communication Ports Pocketstation IO Power Control Pocketstation SWI Function Summary Pocketstation SWI Misc Functions Pocketstation SWI Communication Functions Pocketstation SWI Execute Functions Pocketstation SWI Date/Time/Alarm Functions Pocketstation SWI Flash Functions Pocketstation SWI Useless Functions Pocketstation BU Command Summary Pocketstation BU Standard Memory Card Commands Pocketstation BU Basic Pocketstation Commands Pocketstation BU Custom Pocketstation Commands Pocketstation File Header/Icons Pocketstation File Images Pocketstation XBOO Cable
"},{"location":"pocketstation/#pocketstation-overview","title":"Pocketstation Overview","text":""},{"location":"pocketstation/#sonys-pocketstation-scph-4000-1998","title":"Sony's Pocketstation (SCPH-4000) (1998)","text":"The Pocketstation is a memory card with built-in LCD screen and buttons; aside from using it as memory storage device, it can be also used as miniature handheld console.
CPU ARM7TDMI (32bit RISC Processor) (variable clock, max 7.995MHz)\n Memory 2Kbytes SRAM (battery backed), 16Kbytes BIOS ROM, 128Kbytes FLASH\n Display 32x32 pixel LCD (black and white) (without any grayscales)\n Sound Mini Speaker \"(12bit PCM) x 1 unit\" / \"8bit PCM with 12bit range\"\n Controls 5 input buttons, plus 1 reset button\n Infrared Bi-directional (IrDA based)\n Connector Playstation memory card interface\n RTC Battery backed Real-Time Clock with time/date function\n Supply CR2032 Battery (3VDC) (used in handheld mode, and for SRAM/RTC)\n _________\n / _______ \\\n | | | |\n | | LCD | | __\n | |_______| | Side Views | _|\n |\\_________/| || <-------- Button Cover\n | O | (Closed) (Open) ||\n | O O O | ____________ _____|| .------- Reset Button\n | O | | LCD \\____ | | LCD \\|__|_\n |___________| |___________|| |___________| <--- Memory card plug\nThe main problem of the Pocketstation seems to be that it tends to reset the RTC to 1st January 1999 with time 00:00:00 whenever possible. The BIOS contains so many RTC-reset functions, RTC-reset buttons, RTC-reset flags, RTC-reset communication commands, RTC-reset parameters, RTC-reset exceptions, RTC-reset sounds, and RTC-reset animations that it seems as if Sony actually WANTED the Time/Date to be destroyed as often as possible. The only possible reason for doing this is that the clock hardware is so inaccurate that Sony must have decided to \"solve\" the problem at software engineering side, by erasing the RTC values before the user could even notice time inaccuracies.
"},{"location":"pocketstation/#cpu-specs","title":"CPU Specs","text":"For details on the ARM7TDMI CPUs opcodes and exceptions, check GBATEK at, http://problemkaputt.de/gbatek.htm (or .txt) The GBA uses an ARM7TDMI CPU, too.
Thanks to Exophase, Orion, Fezzik, Dr.Hell for Pocketstation info.
"},{"location":"pocketstation/#pocketstation-io-map","title":"Pocketstation I/O Map","text":""},{"location":"pocketstation/#memory-and-memory-control-registers","title":"Memory and Memory-Control Registers","text":" 00000000h RAM (2KB RAM) (first 512 bytes bytes reserved for kernel)\n 02000000h FLASH1 Flash ROM (virtual file-mapped addresses in this region)\n 04000000h BIOS_ROM Kernel and GUI (16KB)\n 06000000h F_CTRL Control of Flash ROM\n 06000004h F_STAT Unknown?\n 06000008h F_BANK_FLG FLASH virtual bank mapping enable flags(16 bits)(R/W)\n 0600000Ch F_WAIT1 waitstates...?\n 06000010h F_WAIT2 waitstates, and FLASH-Write-Control-and-Status...?\n 06000100h F_BANK_VAL FLASH virtual bank mapping addresses (16 words) (R/W)\n 06000300h F_EXTRA Extra FLASH (256 bytes, including below F_SN, F_CAL)\n 06000300h F_SN_LO Extra FLASH Serial Number LSBs (nocash: 6BE7h)\n 06000302h F_SN_HI Extra FLASH Serial Number MSBs (nocash: 426Ch)\n 06000304h F_? Extra FLASH Unknown ? (nocash: 05CAh)\n 06000306h F_UNUSED1 Extra FLASH Unused halfword (nocash: FFFFh)\n 06000308h F_CAL Extra FLASH LCD Calibration (nocash: 001Ah)\n 0600030Ah F_UNUSED2 Extra FLASH Unused halfword (nocash: FFFFh)\n 0600030Ch F_? Extra FLASH Unknown ? (nocash: 0010h)\n 0600030Eh F_UNUSED3 Extra FLASH Unused halfword (nocash: FFFFh)\n 06000310h F_UNUSED4 Extra FLASH Unused (310..3FFh) (nocash: FFFFh-filled)\n 08000000h FLASH2 Flash ROM (128KB) (physical addresses in this region)\n 08002A54h F_KEY1 Flash Unlock Address 1 (W)\n 080055AAh F_KEY2 Flash Unlock Address 2 (W)\n 0A000000h INT_LATCH Interrupt hold (R)\n 0A000004h INT_INPUT Interrupt Status (R)\n 0A000008h INT_MASK_READ Read Interrupt Mask (R)\n 0A000008h INT_MASK_SET Set Interrupt Mask (W)\n 0A00000Ch INT_MASK_CLR Clear Interrupt Mask (W)\n 0A000010h INT_ACK Clear Interrupt hold (W)\n 0A800000h T0_RELOAD Timer 0 Maximum value\n 0A800004h T0_COUNT Timer 0 Current value\n 0A800008h T0_MODE Timer 0 Mode\n 0A800010h T1_RELOAD Timer 1 Maximum value\n 0A800014h T1_COUNT Timer 1 Current value\n 0A800018h T1_MODE Timer 1 Mode\n 0A800020h T2_RELOAD Timer 2 Maximum value\n 0A800024h T2_COUNT Timer 2 Current value\n 0A800028h T2_MODE Timer 2 Mode\n 0B000000h CLK_MODE Clock control (CPU and Timer Speed) (R/W)\n 0B000004h CLK_STOP Clock stop (Sleep Mode)\n 0B800000h RTC_MODE RTC Mode\n 0B800004h RTC_ADJUST RTC Adjust\n 0B800008h RTC_TIME RTC Time (R)\n 0B80000Ch RTC_DATE RTC Date (R)\n 0C000000h COM_MODE Com Mode\n 0C000004h COM_STAT1 Com Status Register 1 (Bit1=Error)\n 0C000008h COM_DATA Com RX Data (R) and TX Data (W)\n 0C000010h COM_CTRL1 Com Control Register 1\n 0C000014h COM_STAT2 Com Status Register 2 (Bit0=Ready)\n 0C000018h COM_CTRL2 Com Control Register 2\n 0C800000h IRDA_MODE Infrared Control (R/W)\n 0C800004h IRDA_DATA Infrared TX Data\n 0C80000Ch IRDA_MISC Infrared Unknown/Reserved\n 0D000000h LCD_MODE Video Control (R/W)\n 0D000004h LCD_CAL Video Calibration (?)\n 0D000100h LCD_VRAM Video RAM (80h bytes; 32x32bit) (R/W)\n 0D800000h IOP_CTRL IOP control\n 0D800004h IOP_STAT Read Current Start/Stop bits? (R)\n 0D800004h IOP_STOP Stop bits? (W)\n 0D800008h IOP_START Start bits? (W)\n 0D80000Ch IOP_DATA IOP data? (not used by bios)\n 0D800010h DAC_CTRL DAC Control (R/W)\n 0D800014h DAC_DATA DAC data\n 0D800020h BATT_CTRL Battery Monitor Control\nMemory Access Time for Opcode Fetch:
WRAM 1 cycle (for ARM and THUMB)\n FLASH 2 cycles (for ARM), or 1 cycle (for THUMB)\n BIOS ?\n WRAM (and some F_xxx ports) 1 cycle\n VIRT/PHYS/XTRA_FLASH, BIOS, VRAM, I/O 2 cycles\n 00000800h-00FFFFFFh Mirrors of 00000000h-000007FFh (2K RAM)\n 01000000h-01FFFFFFh Invalid (read causes data abort) (unused 16MB area)\n 020xxxxxh-0201FFFFh Invalid (read causes data abort) (disabled FLASH banks)\n 02020000h-02FFFFFFh Invalid (read causes data abort) (no Virt FLASH mirrors)\n 03000000h-03FFFFFFh Invalid (read causes data abort) (unused 16MB area)\n 04004000h-04FFFFFFh Mirrors of 04000000h-04003FFFh (16K BIOS)\n 05000000h-05FFFFFFh Invalid (read causes data abort)\n 06000014h-060000FFh Zerofilled (or maybe mirror of a ZERO port?) (F_xxx)\n 06000140h-060002FFh Zerofilled (or maybe mirror of a ZERO port?) (F_xxx)\n 06000400h-06FFFFFFh Zerofilled (or maybe mirror of a ZERO port?) (F_xxx)\n 07000000h-07FFFFFFh Invalid (read causes data abort) (unused 16MB area)\n 08020000h-08FFFFFFh Mirrors of 08000000h-0801FFFFh (128K Physical FLASH)\n 09000000h-09FFFFFFh Invalid (read causes data abort) (unused 16MB area)\n 0A000014h-0A7FFFFFh Mirrors of 0A000008h-0A00000Bh (INT_MASK_READ) (I_xxx)\n 0A80000Ch Mirror of 0A800000h-0A800003h (T0_RELOAD) (T0_xxx)\n 0A80001Ch Mirror of 0A800000h-0A800003h (T0_RELOAD) (T1_xxx)\n 0A80002Ch Mirror of 0A800000h-0A800003h (T0_RELOAD) (T2_xxx)\n 0A800030h-0AFFFFFFh Mirrors of 0A800000h-0A800003h (T0_RELOAD) (T_xxx)\n 0B000008h-0B7FFFFFh Mirrors of .... ? (CLK_xxx)\n 0B800010h-0BFFFFFFh Mirrors of 0B800008h-0B80000Bh (RTC_TIME)\n 0C00000Ch-0C00000Fh Zero (COM_xxx)\n 0C00001Ch-0C7FFFFFh Zerofilled (or maybe mirror of a ZERO port?) (COM_xxx)\n 0C800008h-0CFFFFFFh ? (IRDA_xxx)\n 0D000008h-0D0000FFh Zerofilled (or maybe mirror of a ZERO port?) (LCD_xxx)\n 0D000180h-0D7FFFFFh Zerofilled (or maybe mirror of a ZERO port?) (LCD_xxx)\n 0D800018h ? (DAC_xxx)\n 0D80001Ch ? (DAC_xxx)\n 0D800024h-0DFFFFFFh Zerofilled (or maybe mirror of a ZERO port?) (BATT_xxx)\n 0E000000h-FFFFFFFFh Invalid (read causes data abort) (unused 3872MB area)\n 02000000h-0201FFFFh VIRT_FLASH ;\\\n 04000000h-04FFFFFFh BIOS_ROM ; \"garbage_byte\" (see below)\n 06000300h-060003FFh EXTRA_FLASH ;\n 08000000h-08FFFFFFh PHYS_FLASH ;/\n 0A800001h-0AFFFFFFh Timer area, odd addresses (with A0=1) mirror to 0A800001h\n 0B800001h-0BFFFFFFh RTC area, odd addresses (with A0=1) mirror to ...?\n 0B800002h-0BFFFFFEh RTC area, odd addresses (with A1=1) mirror to 0B80000Ah\nThe \"garbage_byte\" depends on the LSBs of the read address, prefetched opcodes, and recent data fetches:
garbage_word = (prefetch OR (ramdata AND FFFFFFD0h))\n garbage_byte = (garbage_word shr (8*(addr and 3))) AND FFh\n prefetch.bit0-31 = [curr_arm_opcode_addr+8] ;-eg. from arm LDRB\n prefetch.bit0-15 = [recent_arm_opcode_addr+8] ;-eg. from arm BX to thumb\n prefetch.bit16-31 = [curr_thumb_opcode_addr+4] ;-eg. from thumb LDRB\n ramdata.bit0-31 = [recent_ram_read_addr] ;-eg. from LDR/POP from RAM\n 00000000h RAM RAM (2K) (or mirror of BIOS ROM upon reset)\n 02000000h FLASH1 Flash ROM (virtual file-mapped addresses in this region)\n 04000000h BIOS_ROM BIOS (16K) (Kernel and GUI)\n 06000300h F_SN... Seems to contain a bunch of additional FLASH bytes?\n 08000000h FLASH2 Flash ROM (128K) (physical addresses in this region)\n 0D000100h LCD_VRAM Video RAM (128 bytes) (32x32 pixels, 1bit per pixel)\nThe first 200h bytes of RAM are reserved for the kernel.
0000000h 20h Exception handler opcodes (filled with LDR R15,[$+20h] opcodes)\n 0000020h 20h Exception handler addresses (in ARM state, no THUMB bit here)\n 0000040h 80h Sector buffer (and BU command parameter work space)\n 00000C0h 8 ComFlags (see GetPtrToComFlags(), SWI 06h for details)\n 00000C8h 2 BU Command FUNC3 Address (see GetPtrToFunc3addr() aka SWI 17h)\n 00000CAh 1 Value from BU Command_50h, reset by SWI 05h (sense_auto_com)\n 00000CBh 2 Not used\n 00000CDh 1 Old Year (BCD, 00h..99h) (for sensing wrapping to new century)\n 00000CEh 1 Alternate dir_index (when [0D0h]=0) (see SWI 15h and SWI 16h)\n 00000CFh 1 Current Century (BCD, 00h..99h) (see GetBcdDate() aka SWI 0Dh)\n 00000D0h 2 Current dir_index (for currently executed file, or 0=GUI)\n 00000D2h 2 New dir_index (PrepareExecute(flag,dir_index,param), SWI 08h)\n 00000D4h 4 New param (PrepareExecute(flag,dir_index,param), SWI 08h)\n 00000D8h 8 Alarm Setting (see GetPtrToAlarmSetting() aka SWI 13h)\n 00000E0h 4 Pointer to SWI table (see GetPtrToPtrToSwiTable() aka SWI 14h)\n 00000E4h 3x4 Memory Card BU Command variables\n 00000F0h 1 Memory Card FLAG byte (bit3=new_card, bit2=write_error)\n 00000F1h 1 Memory Card Error offhold (0=none, 1=once)\n 00000F2h 6 Not used\n 00000F8h 4x4 Callback Addresses (set via SetCallbacks(index,proc), SWI 01h)\n 0000108h 4 Snapshot ID (0xh,00h,\"SE\")\n 000010Ch 74h IRQ and SWI stack (stacktop at 180h)\n 0000180h 80h FIQ stack (stacktop at 200h)\nThis region can be freely used by the game. The memory is zerofilled when the game starts.
"},{"location":"pocketstation/#02000000h-flash1-flash-rom-virtual-file-mapped-addresses-in-this-region","title":"02000000h - FLASH1 - Flash ROM (virtual file-mapped addresses in this region)","text":"This region usually contains the currently selected file (including its title and icon sectors), used to execute the file in this region, mapped to continous addresses at 2000000h and up.
"},{"location":"pocketstation/#08000000h-flash2-flash-rom-128k-physical-addresses-in-this-region","title":"08000000h - FLASH2 - Flash ROM (128K) (physical addresses in this region)","text":"This region is used by the BIOS when reading the memory card directory (and when writing data to the FLASH memory). The banking granularity is 2000h bytes (one memory card block), that means that the hardware cannot map Replacement Sectors which may be specified in the for Broken Sector List.
"},{"location":"pocketstation/#04000000h-bios-rom-16k-kernel-and-gui","title":"04000000h - BIOS ROM (16K) - Kernel and GUI","text":" 4000000h 1E00h Begin of Kernel (usually 1E00h bytes)\n 4000014h 4 BCD Date in YYYYMMDDh format (19981023h for ALL versions)\n 4001DFCh 4 Core Kernel Version (usually \"C061\" or \"C110\")\n 4001E00h 2200h Begin of GUI (usually 2200h bytes)\n 4003FFCh 4 Japanese GUI Version (usually \"J061\" or \"J110\")\nFLASH and BIOS ROM seem to be allowed to be read only in 16bit and 32bit units, not in 8bit units? Similar restrictions might apply for some I/O ports...? RAM can be freely read/written in 8bit, 16bit, and 32bit units.
"},{"location":"pocketstation/#waitstates","title":"Waitstates","text":"Unknown if and how many waitstates are applied to the different memory regions. The F_WAIT1 and F_WAIT2 registers seem to be somehow waitstate related. FLASH memory does probably have a 16bit bus, so 32bit data/opcode fetches might be slower then 16bit reads...? Similar delays might happen for other memory and I/O regions...?
"},{"location":"pocketstation/#pocketstation-io-video-and-audio","title":"Pocketstation IO Video and Audio","text":""},{"location":"pocketstation/#0d000000h-lcd_mode-lcd-control-word-rw","title":"0D000000h - LCD_MODE - LCD control word (R/W)","text":" 0-2 Draw mode; seems to turn off bits of the screen;\n 0: All 32 rows on ;\\\n 1: First 8 rows on ;\n 2: Second 8 rows on ;\n 3: Third 8 rows on ; (these are not necessarily all correct?)\n 4: Fourth 8 rows on ;\n 5: First 16 rows on ;\n 6: Middle 16 rows on ;\n 7: Bottom 16 rows on ;/\n 3 CPEN (0=Does some weird fade out of the screen, 1=Normal)\n 4-5 Refresh rate\n 0: Makes a single blue (yes, blue, yes, on a black/white display)\n line appear at the top or middle of the screen - don't use!\n 1: 64Hz? (might be 32Hz too, like 2)\n 2: 32Hz\n 3: 16Hz (results in less intensity on black pixels)\n 6 Display active (0=Off, 1=On)\n 7 Rotate display by 180 degrees (0=For Handheld Mode, 1=For Docked Mode)\n 8-31 Unknown (should be zero)\nUpon the reset, the kernel sets LCD_CAL = F_CAL AND 0000003Fh. Aside from that, it doesn't use LCD_CAL.
"},{"location":"pocketstation/#0d000100hd00017fh-lcd_vram-32x32-pixels-1bit-color-depth-rw","title":"0D000100h..D00017Fh - LCD_VRAM - 32x32 pixels, 1bit color depth (R/W)","text":"This region consists of 32 words (32bit values),
[D000100h]=Top, through [D00017Ch]=Bottom-most scanline\n Bit0=Left, through Bit31=Right-most Pixel (0=White, 1=Black)\n 0 Audio Enable enable (0=Off, 1=On)\n 1-31 Unknown, usually zero\nUnknown how many bits are passed to the D/A converter, probably bit8-15, ie. 8 bits...?
0-7 Probably unused, usually zero (or fractional part when lowered volume)\n 8-15 Signed Audio Outut Level (usually -7Fh..+7Fh) (probably -80h works too)\n 16-31 Probably unused, usually sign-expanded from bit15\n Bit Type Meaning\n 0 IRQ Button Fire (0=Released, 1=Pressed)\n 1 IRQ Button Right (0=Released, 1=Pressed)\n 2 IRQ Button Left (0=Released, 1=Pressed)\n 3 IRQ Button Down (0=Released, 1=Pressed)\n 4 IRQ Button Up (0=Released, 1=Pressed)\n 5 ? Unknown? (?)\n 6 FIQ (!) COM ;for the COM_registers? (via /SEL Pin?)\n 7 IRQ Timer 0\n 8 IRQ Timer 1\n 9 IRQ RTC (square wave) (usually 1Hz) (when RTC paused: 4096Hz)\n 10 IRQ Battery Low (0=Normal, 1=Battery Low)\n 11 IRQ Docked (\"IOP\") (0=Undocked, 1=Docked to PSX) (via VCC Pin?)\n 12 IRQ Infrared Rx\n 13 FIQ (!) Timer 2\n 14-15 N/A Not used\n INT_MASK_SET Enable Interrupt Flags (0=No change, 1=Enable) (W)\n INT_MASK_CLR Disable Interrupt Flags (0=No change, 1=Disable) (W)\n INT_MASK_READ Current Interrupt Enable Flags (0=Disabled, 1=Enabled) (R)\n INT_LATCH Latched Interrupt Requests (0=None, 1=Interrupt Request) (R)\n INT_ACK Clear Interrupt Requests (0=No change, 1=Acknowledge) (W)\nATTENTION: The GUI doesn't acknowledge Fire Button interrupts on wakeup... so, it seems as if button interrupts are NOT latched... ie. the button \"INT_LATCH\" bits seem to be just an unlatched mirror of the \"INT_INPUT\" bits... that might also apply for some other interrupt...? However, after wakeup, the gui does DISABLE the Fire Button interrupt, MAYBE that does automatically acknowledge it... in that case it might be latched...?
Reading outside the readable region (that is where exactly?) seems to mirror to 0A000008h. Enabling IRQs for the buttons seems to make it impossible to poll them... is that really true?
"},{"location":"pocketstation/#pocketstation-io-timers-and-real-time-clock","title":"Pocketstation IO Timers and Real-Time Clock","text":""},{"location":"pocketstation/#timer-and-rtc-interrupts","title":"Timer and RTC interrupts","text":" INT_INPUT.7 Timer 0 IRQ ;used as 30Hz frame rate IRQ by GUI\n INT_INPUT.8 Timer 1 IRQ ;used as Audio square wave IRQ by GUI\n INT_INPUT.13 Timer 2 FIQ (this one via FIQ vector, not IRQ vector)\n INT_INPUT.9 RTC IRQ (usually 1Hz) (or 4096Hz when RTC paused)\n 0-15 Reload Value (when timer becomes less than zero)\n 0-15 Current value (decrementing)\n 0-1 Timer Divider (0=Div2, 1=Div32, 2=Div512, 3=Div2 too)\n 2 Timer Enable (0=Stop, 1=Decrement)\n 3-15 Unknown (should be zero)\n 0 Pause RTC (0=Run/1Hz, 1=Pause/4096Hz)\n 1-3 Select value to be modified via RTC_ADJUST\n 4-31 Not used?\n 00h = Second ;\\\n 01h = Minute ;\n 02h = Hour ; used in combination with RTC_ADJUST\n 03h = Day of Week ; while RTC is paused\n 04h = Day ;\n 05h = Month ;\n 06h = Year ;/\n 07h = Unknown ;-usually used when RTC isn't paused\nWriting a value here seems to increment the current selected parameter (by the RTC control). What is perhaps (?) clear is that you have to wait for the RTC interrupt signal to go low before writing to this.
"},{"location":"pocketstation/#0b800008h-rtc_time-real-time-clock-time-read-only-r","title":"0B800008h - RTC_TIME - Real-Time Clock Time (read only) (R)","text":" 0-7 Seconds (00h..59h, BCD)\n 8-15 Minutes (00h..59h, BCD)\n 16-23 Hours (00h..23h, BCD)\n 24-31 Day of week (1=Sunday, ..., 7=Saturday)\n 0-7 Day (01h..31h, BCD)\n 8-11 Month (01h..12h, BCD)\n 16-23 Year (00h..99h, BCD)\n 24-31 Unknown? (this is NOT used as century)\nThe BIOS doesn't contain any IR functions (aside from doing some basic initialization and power-down stuff). IR is used in Final Fantasy 8's Chocobo World (press Left/Right in the Map screen to go to the IR menu), and in Metal Gear Solid Integral (Press Up in the main screen), and in PDA Remote 1 & 2 (one-directional TV remote control).
"},{"location":"pocketstation/#0c800000h-irda_mode-controlling-the-protocol-sendrecv-etc-rw","title":"0C800000h - IRDA_MODE - Controlling the protocol - send/recv, etc. (R/W)","text":" 0 Transfer Direction (0=Receive, 1=Transmit)\n 1 Disable IRDA (0=Enable, 1=Disable)\n 2 Unknown (reportedly IR_SEND_READY, uh?)\n 3 Unknown (reportedly IR_RECV_READY, uh?)\n 4-31 Unknown (should be zero)\n 0 Transmit Data in Send Direction (0=LED Off, 1=LED On)\n 1-31 Unknown (should be zero)\nUnknown? Reportedly reserved.
"},{"location":"pocketstation/#int_input12-irq-infrared-rx-interrupt","title":"INT_INPUT.12 - IRQ - Infrared RX Interrupt","text":"Seems to get triggered on raising or falling (?) edges of incoming data. The interrupt handler seems to read the current counter value from one of the timers (usually Timer 2, with reload=FFFFh) to determine the length of the incoming IR pulse.
"},{"location":"pocketstation/#ir-notes","title":"IR Notes","text":"Mind that IR hardware usually adopts itself to the normal light conditions, so if it receives an IR signal for a longer period, then it may treat that as the normal light conditions (ie. as \"OFF\" state). To avoid that, one would usually send a group of ON-OFF-ON-OFF pulses, instead of sending a single long ON pulse:
___------------------___ One HIGH bit send as SINGLE-LONG-ON pulse (BAD)\n ___-_-_-_-_-_-_-_-_-____ One HIGH bit send as MULTIPLE-ON-OFF pulses (OK)\nReportedly, Bit4 of Port 0D80000Ch (IOP_DATA) is also somewhat IR related...?
"},{"location":"pocketstation/#pocketstation-io-memory-control","title":"Pocketstation IO Memory-Control","text":""},{"location":"pocketstation/#06000000h-f_ctrl","title":"06000000h - F_CTRL","text":" 0-31 Unknown\n 00000000h Used when disabling all virtual flash banks\n 00000001h Used before setting new virtual bank values\n 00000002h Used after setting virtual bank enable bits\n 03h Replace ROM at 00000000h by RAM (used after reset)\n 0-31 Unknown\n 0-15 Enable physical banks 0..15 in virtual region (0=Disable, 1=Enable)\n 16-31 Unknown (should be zero)\nThis region contains 16 words, the first word at 06000100h for physical bank 0, the last word at 0600013Ch for physical bank 15. Each word is:
0-3 Virtual bank number\n 4-31 Should be 0\n 0..3 Unknown/not tested\n 4 hangs hardware? but that bit is used in some cases!\n 5..31 Unknown/not tested\n F_WAIT1=00000000h when CPU Speed = 00h..07h\n F_WAIT1=00000010h when CPU Speed = 08h..0Fh\n 0 no effect? but that bit is used in some cases! maybe write-enable?\n 1 hangs hardware?\n 2 no effect? READ: indicates 0=write-busy, 1=ready? (R)\n 3 hangs hardware?\n 4 makes FLASH slower?\n 5 makes WRAM and F_xxx as slow as other memory (0=1 cycle, 1=2 cycles)\n 6 hangs hardware? but that bit is used in some cases!\n 7 no effect?\n 8..31 Unknown/not tested\n F_WAIT2=00000000h when CPU Speed = 00h..07h ;\\same as F_WAIT1\n F_WAIT2=00000010h when CPU Speed = 08h..0Fh ;/\n F_WAIT2=00000021h ;SWI 10h, FlashWritePhysical(sector,src)\n F_WAIT2=00000041h ;SWI 0Fh, FlashWriteSerial(serial_number)\n wait until reading returns F_WAIT2.Bit2 = 1\n and then set F_WAIT2=00000000h\nUnlocks FLASH memory for writing. The complete flowchart for writing sector data (or header values) is:
if write_sector ;\\\n F_WAIT2=00000021h ; write enable or so\n if write_header ;\n F_WAIT2=00000041h ;/\n [80055AAh]=FFAAh ;\\\n [8002A54h]=FF55h ; unlock flash\n [80055AAh]=FFA0h ;/\n if write_sector ;\\\n for i=0 to 3Fh ;\n [8000000h+sector*80h+i*2]=src[i*2] ; write data\n if write_header ;\n [8000000h]=new F_SN_LO value ;\n [8000002h]=new F_SN_HI value ;\n [8000008h]=new F_CAL value ;/\n first, wait 4000 clock cycles ;\\wait\n then, wait until F_WAIT2.Bit2=1 ;/\n F_WAIT2=00000000h ;-write disable or so\n 0-15 Data\nObserve that the physical_bank number (p) is used as array index, and that the virtual bank number (v) is stored in that location, ie. table[p]=v, which is unlike as one may have expected it (eg. on a 80386 CPU it'd be vice-versa: table[v]=p). Due to the table[p]=v assignment, a physical block cannot be mirrored to multiple virtual blocks, instead, multiple physical blocks can be mapped to the same virtual block (unknown what happens in that case, maybe the data becomes ANDed together).
"},{"location":"pocketstation/#pocketstation-io-communication-ports","title":"Pocketstation IO Communication Ports","text":""},{"location":"pocketstation/#0c000000h-com_mode-com-mode","title":"0C000000h - COM_MODE - Com Mode","text":" 0 Data Output Enable (0=None/HighZ, 1=Output Data Bits)\n 1 /ACK Output Level (0=None/HighZ, 1=Output LOW)\n 2 Unknown (should be set when expecting a NEW command...?)\n 3-31 Unknown (should be zero)\n 0-7 Data (Write: to be transmitted to PSX, Read: been received from PSX)\n 8-31 Unknown\n 0 Unknown\n 1 Error flag or so (0=Okay, 1=Error)\n 2-31 Unknown\n 0 Ready flag (0=Busy, 1=Ready) (when 8bits have been transferred)\n 1-31 Unknown\n 0 Unknown (should be set AT BEGIN OF A NEW command...?)\n 1 Unknown (0=Disable something, 1=Enable something)\n 2-31 Unknown (should be zero)\n 00000000h = unknown? disable\n 00000002h = unknown? enable\n 00000003h = unknown? at BEGIN of a new command\n 0 Unknown (should be set, probably starts or acknowledges something)\n 1 Unknown (should be set when expecting a NEW command...?)\n 2-31 Unknown (should be zero)\n 00000001h = unknown? used before AND after each byte-transfer\n 00000003h = unknown? used after LAST byte of command (and when init/reset)\n (via FIQ vector, not IRQ vector)\nProbably senses the voltage on the cartridge slots VCC Pin. Becomes zero when Undocked (and probably also when the PSX is switched off). The Kernel uses IRQ-11 for BOTH sensing docking and undocking, ie. as if the IRQ would be triggered on both 0-to-1 and 1-to-0 transistions... though maybe that feature just relies on switch-bounce. For the same reason (switch bounce), the IRQ-11 handler performs a delay before it checks the new INT_INPUT.11 setting (ie. the delay skips the unstable switch bound period, and allows the signal to stabilize).
"},{"location":"pocketstation/#iop_startiop_stopbit1","title":"IOP_START/IOP_STOP.Bit1","text":"The BIOS adjusts this bit somehow in relation to communication. Unknown when/why/how it must be used. For details on IOP_START/IOP_STOP see Power Control chapter.
"},{"location":"pocketstation/#opcode-e6000010h-the-undefined-instruction-write-chrr0-to-tty","title":"Opcode E6000010h (The Undefined Instruction) - Write chr(r0) to TTY","text":"This opcode is used by the SN Systems emulator to write chr(r0) to a TTY style text window. r0 can be ASCII characters 20h and up, or 0Ah for CRLF. Using that opcode is a not too good idea because the default BIOS undef instruction handler simply runs into an endless loop, so games that are using it (eg. Break-Thru by Jason) won't work on real hardware. That, unless the game would change the undef instruction vector at [04h] in Kernel RAM, either replacing it by a MOVS R15,R14 opcode (ignore exception and return to next opcode), or by adding exception handling that outputs the character via IR or via whatever cable connection. Observe that an uninitialized FUNC3 accidently destroys [04h], so first init FUNC3 handler via SWI 17h, before trying to change [04h], moreover, mind that SWI 05h may reset FUNC3, causing the problem to reappear. Altogether, it'd be MUCH more stable to write TTY characters to an unused I/O port... only problem is that it's still unknown which I/O ports are unused... ie. which do neither trap data aborts, nor do mirror to existing ports...?
"},{"location":"pocketstation/#pocketstation-io-power-control","title":"Pocketstation IO Power Control","text":""},{"location":"pocketstation/#0b000000h-clk_mode-clock-control-cpu-and-timer-speed-rw","title":"0B000000h - CLK_MODE - Clock control (CPU and Timer Speed) (R/W)","text":" 0-3 Clock Ratio (01h..08h, see below) (usually 7 = 3.99MHz) (R/W)\n 4 Clock Change State (0=Busy, 1=Ready) (Read-only)\n 5-15 ?\n 00h = hangs hardware ;-don't use\n 01h = 0.063488 MHz ;\\\n 02h = 0.126976 MHz ;\n 03h = 0.253952 MHz ; 31*8000h / 1,2,4,8,16\n 04h = 0.507904 MHz ;\n 05h = 1.015808 MHz ;/\n 06h = 1.998848 MHz ;\\\n 07h = 3.997696 MHz ; 61*8000h * 1,2,4\n 08h = 7.995392 MHz ;/\n 09h..0Fh = same as 08h ;-aliases\nStops the CPU until an interrupt occurs. The pocketstation doesn't have a power-switch nor standby button, the closest thing to switch \"power off\" is to enter sleep mode. Software should do that when the user hasn't pressed buttons for 1-2 seconds (that, only in handheld mode, not when docked to the PSX; where it's using the PSX power supply instead of the battery).
0 Stop Clock (1=Stop)\n 1-15 ?\n DAC_CTRL=0 ;\\disable sound\n IOP_STOP=20h ;/\n LCD_MODE=0 ;-disable video\n IRDA=whatever ;-disable infrared (if it was used)\n BATT_CTRL=BATT_CTRL AND FFFFFFFCh ;-do whatever\n INT_MASK_SET=801h ;-enable Docking/Fire wakeup interrupts\n 0-3 Probably Direction for IOP_DATA bit0..3 (0=Input, 1=Output)\n 4-31 Unknown/Unused (seems to be always zero)\nThese two ports are probably accessing a single register, writing \"1\" bits to IOP_STOP sets bits in that register, and writing \"1\" bits to IOP_START clears bits... or vice-versa...? Writing \"0\" bits to either port seems to leave that bits unchanged. The meaning of most bits is still unknown:
0 Unknown, STARTED by Kernel upon reset\n 1 Red LED, Communication related (START=Whatever, STOP=Whatelse) (?)\n 2 Unknown, STARTED by Kernel upon reset\n 3 Unknown, STARTED by Kernel upon reset\n 4 Never STARTED nor STOPPED by BIOS (maybe an INPUT, read via IOP_DATA)\n 5 Sound Enable (START=On, STOP=Off)\n 6 Unknown, STOPPED by Kernel upon reset\n 7-31 Unknown, never STARTED nor STOPPED by BIOS\n 0 ?\n 1 Red LED (0=On, 1=Off)\n 2 ?\n 3 ?\n 4 Seems to be always 1 (maybe Infrared input?)\n 5-31 Unknown/Unused (seems to be always zero)\nUnknown. Somehow battery saving related. Upon reset, and upon leaving sleep mode, the BIOS does set BATT_CTRL=00000000h. Before entering sleep mode, it does set BATT_CTRL=BATT_CTRL AND FFFFFFFCh, whereas, assuming that BATT_CTRL was 00000000h, ANDing it with FFFFFFFCh would simply leave it unchanged... unless the hardware (or maybe a game) sets some bits in BATT_CTRL to nonzero values...?
"},{"location":"pocketstation/#battery-low-interrupt","title":"Battery Low Interrupt","text":" INT_INPUT.10 IRQ Battery Low (0=Normal, 1=Battery Low)\nBIOS functions can be called via SWI opcodes (from both ARM and THUMB mode) (in ARM mode, the SWI function number is in the lower 8bit of the 24bit field; unlike as for example on the GBA, where it'd be in the upper 8bit). Parameters (if any) are passed in r0,r1,r2. Return value is stored in r0 (all other registers are left unchanged).
SWI 00h - Reset() ;don't use out: everything destroyed\n SWI 01h - SetCallbacks(index,proc) out: old proc\n SWI 02h - CustomSwi2(r0..r6,r8..r10) out: r0\n SWI 03h - FlashWriteVirtual(sector,src) out: 0=okay, 1=failed\n SWI 04h - SetCpuSpeed(speed) out: old_speed\n SWI 05h - SenseAutoCom() out: garbage\n SWI 06h - GetPtrToComFlags() out: ptr (usually 0C0h)\n SWI 07h - ChangeAutoDocking(flags.16-18) out: incoming flags AND 70000h\n SWI 08h - PrepareExecute(flag,dir_index,param) out: dir_index (new or old)\n SWI 09h - DoExecute(snapshot_saving_flag) out: r0=r0 (failed) or r0=param\n SWI 0Ah - FlashReadSerial() out: F_SN\n SWI 0Bh - ClearComFlagsBit10() out: new [ComFlags] (with bit10=0)\n SWI 0Ch - SetBcdDateTime(date,time) out: garbage (RTC_DATE/10000h)\n SWI 0Dh - GetBcdDate() out: date (with century in MSBs)\n SWI 0Eh - GetBcdTime() out: time and day-of-week\n SWI 0Fh - FlashWriteSerial(serial_number) out: garbage (r0=0) ;old BIOS only!\n SWI 10h - FlashWritePhysical(sector,src) out: 0=okay, 1=failed\n SWI 11h - SetComOnOff(flag) out: garbage retadr to swi handler\n SWI 12h - TestSnapshot(dir_index) out: 0=normal, 1=MCX1 with 1,0,\"SE\"\n SWI 13h - GetPtrToAlarmSetting() out: ptr to alarm_setting\n SWI 14h - GetPtrToPtrToSwiTable() out: ptr-to-ptr to swi_table\n SWI 15h - MakeAlternateDirIndex(flag,dir_index) out: alt_dir_index (new/old)\n SWI 16h - GetDirIndex() out: dir_index (or alternate)\n SWI 17h - GetPtrToFunc3addr() out: ptr to func3 address\n SWI 18h - FlashReadWhateverByte(sector) out: [8000000h+sector*80h+7Eh]\n SWI 19h..FFh - garbage\n SWI 100h..FFFFFFh - mirrors of SWI 00h..FFh\n r0=0 Set SWI 02h callback (r1=proc, or r1=0=reset/default)\n r0=1 Set IRQ callback (r1=proc, or r1=0=none/default)\n r0=2 Set FIQ callback (r1=proc, or r1=0=none/default)\n r0=3 Set Download Notification callback (r1=proc, or r1=0=bugged/default)\nRegisters r0,r1,r12 are pushed by the kernels FIQ/IRQ handlers (so the callbacks can use that registers without needing to push them). The FIQ handler can additionally use r8..r11 without pushing them (the CPU uses a separate set of r8..r12 registers in FIQ mode, nethertheless, the kernel DOES push r12 in FIQ mode, without reason). Available stack is 70h bytes for the FIQ callback, and 64h bytes for the IRQ callback. The callbacks don't receive any incoming parameters, and don't need to respond with a return value. The callback should return to the FIQ/IRQ handler (via normal BX r14) (ie. it should not try to return to User mode). The kernel IRQ handler does (after the IRQ callback) process IRQ-11 (IOP) (which does mainly handle docking/undocking), and IRQ-9 (RTC) (which increments the century if the year wrapped from 99h to 00h). And the kernel FIQ handler does (before the FIQ callback) process IRQ-6 (COM) (which does, if ComFlags.Bit9 is set, handle bu_cmd's) (both IRQs and FIQs are disabled, and the main program is stopped until the bu_cmd finishes, or until a joypad command is identified irrelevant, among others that means that sound/timer IRQs aren't processed during that time, so audio output may become distorted when docked). When docked, the FIQ callback should consist of only a handful of opcodes, eg. it may contain a simple noise, square wave generator, or software based sound \"DMA\" function, but it should not contain more time-consuming code like sound envelope processing; otherwise IRQ-6 (COM) cannot be executed fast enough to handle incoming commands.
"},{"location":"pocketstation/#swi-02h-customswi2r0r6r8r10-out-r0","title":"SWI 02h - CustomSwi2(r0..r6,r8..r10) out: r0","text":"Calls the SWI2 callback function (which can be set via SWI 01h). The default callback address is 00000000h (so, by default, it behaves identically as SWI 00h). Any parameters can be passed in r0..r6 and r8..r10 (the other registers aren't passed to the callback function). Return value can be stored in r0 (all other registers are pushed/popped by the swi handler, as usually). Available space on the swi stack is 38h bytes. SWI2 can be useful to execute code in privileged mode (eg. to initialize FIQ registers r8..r12 for a FIQ based sound engine) (which usually isn't possible because the main program runs in non-privileged user mode).
"},{"location":"pocketstation/#swi-04h-setcpuspeedspeed-out-old_speed","title":"SWI 04h - SetCpuSpeed(speed) out: old_speed","text":"Changes the CPU speed. The BIOS uses it with values in range 01h..07h. Unknown if value 00h can be also used? The function also handles values bigger than 07h, of which, some pieces of BIOS code look as if 08h would be the maximum value...? Before setting the new speed, the function sets F_WAIT1 and F_WAIT2 to 00000000h (or to 00000010h if speed.bit3=1). After changing the speed (by writing the parameter to CLK_MODE) it does wait until the new speed is applied (by waiting for CLK_MODE.bit4 to become zero). The function returns the old value of CLK_MODE, anded with 0Fh.
"},{"location":"pocketstation/#pocketstation-swi-communication-functions","title":"Pocketstation SWI Communication Functions","text":"Communication (aka BU Commands, received from the PSX via the memory card slot) can be handled by the pocketstations kernel even while a game is running. However, communications are initially disabled when starting a game, so the game should enable them via SWI 11h, and/or via calling SWI 05h once per frame.
"},{"location":"pocketstation/#swi-11h-setcomonoffflag","title":"SWI 11h - SetComOnOff(flag)","text":"Can be used to enable/disable communication. When starting an executable, communication is initially disabled, so it'd be a good idea to enable them (otherwise the PSX cannot communicate with the Pocketstation while the game is running). When flag=0, disables communication: Intializes the COM_registers, disables IRQ-6 (COM), and clears ComFlags.9. When flag=1, enables communication: Intializes the COM_registers, enables IRQ-6 (COM), sets ComFlags.9 (when docked), or clears Sys.Flags.9 (when undocked), and sets FAST cpu_speed=7 (only when docked). The function returns garbage (r0=retadr to swi_handler).
"},{"location":"pocketstation/#swi-06h-getptrtocomflags","title":"SWI 06h - GetPtrToComFlags()","text":"Returns a pointer to the ComFlags word in RAM, which contains several communication related flags (which are either modified upon docking/undocking, or upon receiving certain bu_cmd's). The ComFlags word consists of the following bits:
0-3 Whatever (set/cleared when docked/undocked, and modified by bu_cmd's)\n 4-7 Not used (should be zero)\n 8 IRQ-11 (IOP) occurred (set by irq handler, checked/cleared by SWI 05h)\n 9 Communication Enabled And Docked (0=No, 1=Yes; prevents DoExecute)\n 10 Reject writes to Broken Sector Region (sector 16..55) (0=No, 1=Yes)\n 11 Start file request (set by bu_cmd_59h, processed by GUI, not by Kernel)\n 12-15 Not used (should be zero)\n 16 Automatically power-down DAC audio on insert/removal (0=No, 1=Yes)\n 17 Automatically power-down IRDA infrared on insert/removal (0=No, 1=Yes)\n 18 Automatically adjust LCD screen rotate on insert/removal (0=No, 1=Yes)\n 19-27 Not used (should be zero)\n 28 Indicates if a standard bu_cmd (52h/53h/57h) was received (0=No, 1=Yes)\n 29 Set date/time request (set by bu_cmd FUNC0, processed by BIOS)\n 30 Destroy RTC and Start GUI request (set by bu_cmd_59h, dir_index=FFFEh)\n 31 Not used (should be zero)\n 0-15 Not used (should be zero)\n 16 Automatically power-down DAC audio on insert/removal (0=No, 1=Yes)\n 17 Automatically power-down IRDA infrared on insert/removal (0=No, 1=Yes)\n 18 Automatically adjust LCD screen rotate on insert/removal (0=No, 1=Yes)\n 19-31 Not used (should be zero)\nResets ComFlags.Bit10, ie. enables bu_cmd_57h (write_sector) to write to the Broken Sector region in FLASH memory (sector 16..55). SWI 0Bh returns the current ComFlags value (the new value, with bit10=0). Aside from calling SWI 0Bh, ComFlags.10 is also automatically cleared upon IRQ-10 (IOP) (docking/undocking). ComFlags.10 can get set/cleared by the Download Notification callback.
"},{"location":"pocketstation/#swi-05h-senseautocom","title":"SWI 05h - SenseAutoCom()","text":"Checks if docking/undocking has occurred (by examining ComFlags.8, which gets set by the kernel IRQ-11 (IOP) handler). If that flag was set, then the function does reset it, and does then reset FUNC3=0000h and [0CAh]=00h (both only if docked, not when undocked), and, no matter if docked or undocked, it enables communication; equivalent to SetComOnOff(1); which sets/clears ComFlags.9. The function returns garbage (r0=whatever). The GUI is calling SWI 05h once per frame. The overall purpose is unknown. It's a good idea to reset FUNC3 and to Enable Communication (although that'd be required only when docked, not when undocked), but SWI 05h is doing that only on (un-)docking transitions (not when it was already docked). In general, it'd make more sense to do proper initializations via SWI 11h and SWI 17h as than trusting SWI 05h to do the job. The only possibly useful effect is that SWI 05h does set/clear ComFlags.9 when docked/undocked.
"},{"location":"pocketstation/#swi-17h-getptrtofunc3addr","title":"SWI 17h - GetPtrToFunc3addr()","text":"Returns a pointer to a halfword in RAM which contains the FUNC3 address (for bu_cmd_5bh and bu_cmd_5ch). The address is only 16bit, originated at 02000000h in FLASH (ie. it can be only in the first 64K of the file), bit0 can be set for THUMB code. The default address is zero, which behaves bugged: It accidently sets [00000004h]=00000000h, ie. replaces the Undefined Instruction exception vector by a \"andeq r0,r0,r0\" opcode, due to that NOP-like opcode, any Undefined Instruction exceptions will run into the SWI vector at [00000008h], and randomly execute an SWI function; with some bad luck that may execute one of the FlashWrite functions and destroy the saved files. Although setting 0000h acts bugged, one should restore that setting before returning control to GUI or other executables; otherwise the address would still point to the FUNC3 address of the old unloaded executable, which is worse than the bugged effect. The FUNC3 address is automatically reset to 0000h when (if) SWI 05h (SenseAutoCom) senses new docking.
"},{"location":"pocketstation/#download-notification-callback","title":"Download Notification callback","text":"Can be used to mute sound during communication, see SWI 01h, SetCallbacks(index,proc), and BU Command 5Dh for details.
"},{"location":"pocketstation/#pocketstation-swi-execute-functions","title":"Pocketstation SWI Execute Functions","text":""},{"location":"pocketstation/#swi-08h-prepareexecuteflagdir_indexparam","title":"SWI 08h - PrepareExecute(flag,dir_index,param)","text":"dir_index should be 0=GUI, or 1..15=First block of game. When calling DoExecute, param is passed to the entrypoint of the game or GUI in r0 register (see notes on GUI \\<param> values belows). For games, param may be interpreted in whatever way. When flag=0, the function simply returns the old dir_index value. When flag=1, the new dir_index and param values are stored in Kernel RAM (for being used by DoExecute); the values are stored only if dir_index=0 (GUI), or if dir_index belongs to a file with \"SC\" and \"MCX0\" or \"MCX1\" IDs in it's title sector. If dir_index was accepted, then the new dir_index value is returned, otherwise the old dir_index is returned.
"},{"location":"pocketstation/#gui-param-values-for-prepareexecute10param","title":"GUI \\<param> values - for PrepareExecute(1,0,param)","text":"PrepareExecute(1,0,param) prepares to execute the GUI (rather than a file). When executing the GUI, \\<param> consists of the following destructive bits:
0-7 Command number (see below, MSBs=Primary command, LSBs=another dir_index)\n 8 Do not store Alarm setting in Kernel RAM (0=Normal, 1=Don't store)\n 9-31 Not used (should be zero)\n Command 0xh --> Erase RTC time/date\n Command 1xh --> Enter GUI Time Screen with speaker symbol\n Command 20h --> Enter GUI Time Screen with alarm symbol\n Command 2xh --> Prompt for new Date/Time, then start dir_index (x)\n Command 3xh --> Enter GUI File Selection Screen, with dir_index (x) selected\n Command xxh --> Erase RTC time/date (same as Command 0xh)\nAllows to return control to the GUI (when dir_index=0), or to start an executable (when dir_index=1..15). Prior to calling DoExecute, parameters should be set via PrepareExecute(1,dir_index,param), when not doing that, DoExecute would simply restart the current executable (which may be a desired effect in some cases). The \"snapshot_saving_flag\" can be ommited for normal (MCX0) files, that parameter is used only for special (MCX1) files (see Snapshot Notes for details). Caution: DoExecute fails (and returns r0=unchanged) when ComFlags.9=1 (which indicates that communications are enabled, and that the Pocketstation is believed to be docked to the PSX). ComFlags.9 can be forcefully cleared by calling SetComOnOff(0), or it can be updated according to the current docking-state by calling SetComOnOff(1) or SenseAutoCom().
"},{"location":"pocketstation/#swi-16h-getdirindex","title":"SWI 16h - GetDirIndex()","text":"Returns the dir_index for the currently executed file. If that value is zero, ie. if there is no file executed, ie. if the function is called by the GUI, then it does instead return the \"alternate\" dir_index (as set via SWI 15h).
"},{"location":"pocketstation/#swi-15h-makealternatedirindexflagdir_index-out-alt_dir_index-newold","title":"SWI 15h - MakeAlternateDirIndex(flag,dir_index) out: alt_dir_index (new/old)","text":"Applies the specified dir_index as \"alternate\" dir_index (for being retrieved via SWI 16h for whatever purpose). The dir_index is applied only when flag=1, and only if dir_index is 0=none, or if it is equal to the dir_index of the currently executed file (ie. attempts to make other files being the \"alternate\" one are rejected). If successful, the new dir_index is returned, otherwise the old dir_index is returned (eg. if flag=0, or if the index was rejected).
"},{"location":"pocketstation/#swi-12h-testsnapshotdir_index","title":"SWI 12h - TestSnapshot(dir_index)","text":"Tests if the specified file contains a load-able snapshot, ie. if it does have the \"SC\" and \"MCX1\" IDs in the title sector, and the 01h,00h,\"SE\" ID in the snapshot header. If so, it returns r0=1, and otherwise returns r0=0.
"},{"location":"pocketstation/#snapshot-notes-mcx1-files","title":"Snapshot Notes (MCX1 Files)","text":"Snapshots are somewhat automatically loaded/saved when calling DoExecute: If the old file (the currently executed file) contains \"SC\" AND \"MCX1\" IDs in the title sector, then the User Mode CPU registers and User RAM at 200h..7FFh are automatically saved in the files snapshot region in FLASH memory, with the snapshot_saving_flag being applied as bit0 of the 0xh,00h,\"SE\" ID of the snapshot header). If the new file (specified in dir_index) contains load-able snapshot data (ie. if it has \"SC\" and \"MCX1\" IDs in title sector, and 01h,00h,\"SE\" ID in the snapshot region), then the BIOS starts the saved snapshot data (instead of restarting the executable at its entrypoint). Not too sure if that feature is really working... the snapshot loader seems to load User RAM from the wrong sectors... and it seems to jump directly to User Mode return address... without removing registers that are still stored on SWI stack... causing the SWI stack to underflow after loading one or two snapshots...?
"},{"location":"pocketstation/#pocketstation-swi-datetimealarm-functions","title":"Pocketstation SWI Date/Time/Alarm Functions","text":""},{"location":"pocketstation/#swi-0ch-setbcddatetimedatetime","title":"SWI 0Ch - SetBcdDateTime(date,time)","text":"Sets the time and date, the parameters are having the same format as SWI 0Dh and SWI 0Eh return values (see there). The SWI 0Ch return value contains only garbage (r0=RTC_DATE/10000h).
"},{"location":"pocketstation/#swi-0dh-getbcddate","title":"SWI 0Dh - GetBcdDate()","text":" 0-7 Day (01h..31h, BCD)\n 8-11 Month (01h..12h, BCD)\n 16-31 Year (0000h..9999h, BCD)\n 0-7 Seconds (00h..59h, BCD)\n 8-15 Minutes (00h..59h, BCD)\n 16-23 Hours (00h..23h, BCD)\n 24-31 Day of week (1=Sunday, ..., 7=Saturday)\nReturns a pointer to a 64bit value in Kernel RAM, the upper word (Bit32-63) isn't actually used by the BIOS, except that, the bu_cmd FUNC3 does transfer the whole 64bits. The meaning of the separate bits is:
0-7 Alarm Minute (00h..59h, BCD)\n 8-15 Alarm Hour (00h..23h, BCD)\n 16 Alarm Enable (0=Off, 1=On)\n 17 Button Lock (0=Normal, 1=Lock) (pressing all 5 buttons in GUI)\n 18-19 Volume Shift (0=Normal/Loud, 1=Medium/Div4, 2=Mute/Off)\n 20-22 Not used (should be zero)\n 23 RTC Initialized (0=Not yet, 1=Yes, was initialized from within GUI)\n 24-31 Not used (should be zero)\n 32-63 Pointer to 8x8 BIOS Charset (characters \"0\"...\"9\" plus strange symbols)\n CHR(00h..09h) = Digits \"0..9\"\n CHR(0Ah) = Space \" \"\n CHR(0Bh) = Colon \":\"\n CHR(0Ch) = Button Lock (used by Final Fantasy 8's Chocobo World)\n CHR(0Dh) = Speaker Medium; or loud if followed by chr(0Eh)\n CHR(0Eh) = Speaker Loud; to be appended to chr(0Dh)\n CHR(0Fh) = Speaker Off\n CHR(10h) = Battery Low (used by PocketMuuMuu's Cars)\n CHR(11h) = Alarm Off\n CHR(12h) = Alarm On\n CHR(13h) = Memory Card symbol\nWrites 80h-bytes at src to the physical sector number (0..3FFh, originated at 08000000h), and does then compare the written data with the source data. Returns 0=okay, or 1=failed.
"},{"location":"pocketstation/#swi-03h-flashwritevirtualsectorsrc","title":"SWI 03h - FlashWriteVirtual(sector,src)","text":"The sector number (0..3FFh) is a virtual sector number (originated at 02000000h), the function uses the F_BANK_VAL settings to translate it to a physical sector number, and does then write the 80h-bytes at src to that location (via the FlashWritePhysical function). Returns 0=okay, or 1=failed (if the write failed, or if the sector number exceeded the filesize aka the virtually mapped memory region).
"},{"location":"pocketstation/#swi-0ah-flashreadserial","title":"SWI 0Ah - FlashReadSerial()","text":"Returns the 32bit value from the two 16bit F_SN registers (see F_SN for details).
"},{"location":"pocketstation/#swi-0fh-flashwriteserialserial_number-old-bios-only","title":"SWI 0Fh - FlashWriteSerial(serial_number) ;old BIOS only!","text":"Changes the 32bit F_SN value in the \"header\" region of the FLASH memory. The function also rewrites the F_CAL value (but it simply rewrites the old value, so it's left unchanged). The function isn't used by the BIOS, no idea if it is used by any games. No return value (always returns r0=0). This function is supported by the old \"061\" version BIOS only (the function is padded with jump opcodes which hang the CPU in endless loops on newer \"110\" version).
"},{"location":"pocketstation/#swi-18h-flashreadwhateverbytesector","title":"SWI 18h - FlashReadWhateverByte(sector)","text":"Returns [8000000h+sector*80h+7Eh] AND 00FFh. Purpose is totally unknown... the actual FLASH memory doesn't contain any relevant information at that locations (eg. the in the directory sectors, that byte is unused, usually zero)... and, reading some kind of status or manufacturer information would first require to command the hardware to output that info...?
"},{"location":"pocketstation/#pocketstation-swi-useless-functions","title":"Pocketstation SWI Useless Functions","text":""},{"location":"pocketstation/#swi-00h-reset-dont-use-destroys-rtc-settings","title":"SWI 00h - Reset() ;don't use, destroys RTC settings","text":"Reboots the pocketstation, similar as when pressing the Reset button. Don't use! The BIOS bootcode does (without any good reason) reset the RTC registers and alarm/century settings in RAM to Time 00:00:00, Date 01 Jan 1999, and Alarm 00:00 disabled, so, after reset, the user would need to re-enter these values. Aside from the annoying destroyed RTC settings, the function is rather unstable: it does jump to address 00000000h in RAM, which should usually redirect to 04000000h in ROM, however, most pocketstation games are programmed in C language, where \"pointer\" is usually pronounced \"pointer?\" without much understanding of whether/why/how to initialize that \"strange things\", so there's a good probability that one of the recently executed games has accidently destroyed the reset vector at [00000000h] in battery-backed RAM.
"},{"location":"pocketstation/#swi-14h-getptrtoptrtoswitable","title":"SWI 14h - GetPtrToPtrToSwiTable()","text":"Returns a pointer to a word in RAM, which contains another pointer which usually points to SWI table in ROM. Changing that word could be (not very) useful for setting up a custom SWI table in FLASH or in RAM. When doing that, one must restore the original setting before returning control to the GUI or to another executable (the setting isn't automatically restored).
"},{"location":"pocketstation/#swi-service-routine","title":"SWI service routine","text":"The default SWI service routine is slightly finicky
push {r1-r12, lr} @ Backup SVC-mode registers\nmrs r12, spsr @ Old CPSR in r12\nnop\n\n@ Check if we were previously in Thumb mode\n@ And adjust LR accordingly to fetch the SWI comment field\ntst r12, #0x20\nsubeq lr, #2\nsub lr, #2\n\n@ Fetch the comment field\nldrh r12, [lr]\nand r12, #0xFF\n\n@ Load function pointer for SWI handler and call it\nmov lr, #0xE0 ; Pointer to SWI table in LR\nldr r11, [lr]\nadd r11, r11, r12, lsl #2 @ r11 = &swi_table[comment]\nldr r11, [r11] @ Get function pointer\nmov lr, pc @ Set LR to return address\nbx r11 @ Call SWI handler\n\n@ Restore SVC regs, return from SWI service routine and restore SPSR into CPSR\npop {r1-r12, pc}^\nldrb. Any custom handler needs to do the same, otherwise it won't work on real hardware. Also, for emulator developers, be wary of the last pop as it abuses an ldm edge case (S bit set with r15 in rlist - restores registers properly and then does CPSR = SPSR)"},{"location":"pocketstation/#pocketstation-bu-command-summary","title":"Pocketstation BU Command Summary","text":"The Pocketstation supports the standard Memory Card commands (Read Sector, Write Sector, Get Info), plus a couple of special commands.
"},{"location":"pocketstation/#bu-command-summary","title":"BU Command Summary","text":" 50h Change a FUNC 03h related value or so\n 51h N/A\n 52h Standard Read Sector command\n 53h Standard Get ID command\n 54h N/A\n 55h N/A\n 56h N/A\n 57h Standard Write Sector command\n 58h Get an ID or Version value or so\n 59h Prepare File Execution with Dir_index, and Parameter\n 5Ah Get Dir_index, ComFlags, F_SN, Date, and Time\n 5Bh Execute Function and transfer data from Pocketstation to PSX\n 5Ch Execute Function and transfer data from PSX to Pocketstation\n 5Dh Execute Custom Download Notification Function ;via SWI 01h with r0=3\n 5Eh Get-and-Send ComFlags.bit1,3,2\n 5Fh Get-and-Send ComFlags.bit0\n FUNC 00h - Get or Set Date/Time\n FUNC 01h - Get or Set Memory Block\n FUNC 02h - Get or Set Alarm/Flags\n FUNC 03h - Custom Function 3 ;via SWI 17h, GetPtrToFunc3addr()\n FUNC 80h..FFh - Custom Functions 80h..FFh ;via Function Table in File Header\nFor general info on the three standard memory card commands (52h, 53h, 57h), and for info on the FLAG response value, see: Memory Card Read/Write Commands
"},{"location":"pocketstation/#bu-command-52h-read-sector","title":"BU Command 52h (Read Sector)","text":"Works much as on normal memory cards, except that, on the Pocketstation, the Read Sector command return 00h as dummy values; instead of the \"(pre)\" dummies that occur on normal memory cards. The Read Sector command does reproduce the strange delay (that occurs between 5Ch and 5Dh bytes), similar as on normal original Sony memory cards, maybe original cards did (maybe) actually DO something during that delay period, the pocketstation BIOS simply blows up time in a wait loop (maybe for compatibility with original cards).
"},{"location":"pocketstation/#bu-command-53h-get-id","title":"BU Command 53h (Get ID)","text":"The Get ID command (53h) returns exactly the same values as normal original Sony memory cards.
"},{"location":"pocketstation/#bu-command-57h-write-sector","title":"BU Command 57h (Write Sector)","text":"The Write Sector command has two new error codes (additonally to the normal 47h=\"G\"=Good, 4Eh=\"N\"=BadChecksum, FFh=BadSector responses). The new error codes are (see below for details):
FDh Reject write to Directory Entries of currently executed file\n FEh Reject write to write-protected Broken Sector region (sector 16..55)\nThe FDh error code is intended to prevent the PSX bootmenu (or other PSX games) to delete the currently executed file (which would crash the pocketstation - once when the deleted region gets overwritten by a new file), because the PSX bootmenu and normal PSX games do not recognize the new FDh error code the pocketstation does additionally set FLAG.3 (new card), which should be understood by all PSX programs. The FDh error code occurs only on directory sectors of the file (not on its data blocks). However, other PSX games should never modify files that belong to other games (so there should be no compatibility problem with other PSX programs that aren't aware of the file being containing currently executed code). However, the game that has created the executable pocketstation file must be aware of that situation. If the file is broken into a Pocketstation Executable region and a PSX Gameposition region, then it may modify the Gameposition stuff even while the Executable is running. If the PSX want to overwrite the executable then it must first ensure that it isn't executed (eg. by retrieving the dir_index of the currently executed file via BU Command 5Ah, and comparing it against the first block number in the files FCB at the PSX side; for file handle \"fd\", the first block is found at \"[104h]+fd*2Ch+24h\" in PSX memory).
"},{"location":"pocketstation/#write-error-code-feh-write-protected-broken-sector-region-sector-1655","title":"Write Error Code FEh (write-protected Broken Sector region, sector 16..55)","text":"The write-protection is enabled by ComFlags.bit10 (which can be set/cleared via BU Command 5Dh). That bit should be set before writing Pocketstation excecutables (the Virtual Memory banking granularity is 2000h bytes, which allows to map whole blocks only, but cannot map single sectors, which would be required for files with broken sector replacements). Unlike Error FDh, this error code doesn't set FLAG.3 for notifying normal PSX programs about the error (which is no problem since normally Error FEh should never occur since ComFlags.10 is usually zero). For more info on ComFlags.10, see SWI 0Bh aka ClearComFlagsBit10(), and BU Command 5Dh.
"},{"location":"pocketstation/#pocketstation-bu-basic-pocketstation-commands","title":"Pocketstation BU Basic Pocketstation Commands","text":""},{"location":"pocketstation/#bu-command-50h-change-a-func-03h-related-value-or-so","title":"BU Command 50h (Change a FUNC 03h related value or so)","text":" Send Reply Comment\n 81h N/A Memory Card Access\n 50h FLAG Send Command 50h\n VAL 00h Send new [0CAh], receive length of following data (00h)\n Send Reply Comment\n 81h N/A Memory Card Access\n 58h FLAG Send Command 58h\n (0) 02h Send dummy/zero, receive length of following data (02h)\n (0) 01h Send dummy/zero, receive whatever value (01h)\n (0) 01h Send dummy/zero, receive another value (01h)\n Send Reply Comment\n 81h N/A Memory Card Access\n 59h FLAG Send Command 59h\n (0) 06h Send dummy/zero, receive length of following data (06h)\n NEW OLD Send new dir_index.8-15, receive old dir_index.8-15\n NEW OLD Send new dir_index.0-7, receive old dir_index.0-7\n PAR (0) Send exec_parameter.0-7, receive dummy/zero\n PAR (0) Send exec_parameter.8-15, receive dummy/zero\n PAR (0) Send exec_parameter.16-23, receive dummy/zero\n PAR (0) Send exec_parameter.24-31, receive dummy/zero\n 0000h..000Fh --> Request to Start GUI or File (with above parameter bits)\n 0010h..FFFDh --> Not used, acts same as FFFFh (see below)\n FFFEh --> Request to Destroy RTC and Start GUI (with parameter 00000000h)\n FFFFh --> Do nothing (transfer all bytes, but don't store the new values)\n Send Reply Comment\n 81h N/A Memory Card Access\n 5Ah FLAG Send Command 5Ah\n (0) 12h Send dummy/zero, receive length of following data (12h)\n (0) INDX Send dummy/zero, receive curr_dir_index.bit8-15 (00h)\n (0) INDX Send dummy/zero, receive curr_dir_index.bit0-7 (00h..0Fh)\n (0) FLG Send dummy/zero, receive ComFlags.bit0 (00h or 01h)\n (0) FLG Send dummy/zero, receive ComFlags.bit1 (00h or 01h)\n (0) FLG Send dummy/zero, receive ComFlags.bit3 (00h or 01h)\n (0) FLG Send dummy/zero, receive ComFlags.bit2 (00h or 01h)\n (0) SN Send dummy/zero, receive F_SN.bit0-7 (whatever)\n (0) SN Send dummy/zero, receive F_SN.bit8-15 (whatever)\n (0) SN Send dummy/zero, receive F_SN.bit16-23 (whatever)\n (0) SN Send dummy/zero, receive F_SN.bit24-31 (whatever)\n (0) DATE Send dummy/zero, receive BCD Day (01h..31h)\n (0) DATE Send dummy/zero, receive BCD Month (01h..12h)\n (0) DATE Send dummy/zero, receive BCD Year (00h..99h)\n (0) DATE Send dummy/zero, receive BCD Century (00h..99h)\n (0) TIME Send dummy/zero, receive BCD Second (00h..59h)\n (0) TIME Send dummy/zero, receive BCD Minute (00h..59h)\n (0) TIME Send dummy/zero, receive BCD Hour (00h..23h)\n (0) TIME Send dummy/zero, receive BCD Day of Week (01h..07h)\n Send Reply Comment\n 81h N/A Memory Card Access\n 5Eh FLAG Send Command 5Eh\n (0) 03h Send dummy/zero, receive length of following data (03h)\n NEW OLD Send new ComFlags.bit1, receive old ComFlags.bit1 (00h or 01h)\n NEW OLD Send new ComFlags.bit3, receive old ComFlags.bit3 (00h or 01h)\n NEW OLD Send new ComFlags.bit2, receive old ComFlags.bit2 (00h or 01h)\n Send Reply Comment\n 81h N/A Memory Card Access\n 5Fh FLAG Send Command 5Fh\n (0) 01h Send dummy/zero, receive length of following data (01h)\n NEW OLD Send new ComFlags.bit0, receive old ComFlags.bit0 (00h or 01h)\n Send Reply Comment\n 81h N/A Memory Card Access\n 5Bh FLAG Send Command 5Bh\n FUNC FFh Send Function Number, receive FFh (indicating variable length)\n (0) LEN1 Send dummy/zero, receive length of parameters (depending on FUNC)\n ... (0) Send parameters (LEN1 bytes), and receive dummy/zero\n <-------- at this point, the function is executed for the first time\n (0) LEN2 Send dummy/zero, receive length of data (depending on FUNC)\n (0) ... Send dummy/zero, receive data (LEN2 bytes) from pocketstation\n (0) FFh Send dummy/zero, receive FFh\n <-------- at this point, the function is executed for the second time\n Send Reply Comment\n 81h N/A Memory Card Access\n 5Ch FLAG Send Command 5Ch\n FUNC FFh Send Function Number, receive FFh (indicating variable length)\n (0) LEN1 Send dummy/zero, receive length of parameters (depending on FUNC)\n ... (0) Send parameters (LEN1 bytes), and receive dummy/zero\n <-------- at this point, the function is executed for the first time\n (0) LEN2 Send dummy/zero, receive length of data (depending on FUNC)\n ... (0) Send data (LEN2 bytes) to pocketstation, receive dummy/zero\n (0) FFh Send dummy/zero, receive FFh\n <-------- at this point, the function is executed for the second time\nCan be used to notify the GUI (or games that do support this function) about following \"download\" operations (or uploads or other BU commands). BU commands are handled inside of the kernels FIQ handler, that means both IRQs and FIQs are disabled during a BU command transmission, so any IRQ or FIQ based audio frequency generators will freeze during BU commands. To avoid distorted noise, it's best to disable sound for the duration specified in bit0-7. If the PSX finishes before the originally specified duration has expired, then it can resend this command with bit8=1 to notify the pocketstation that the \"download\" has completed.
Send Reply Comment\n 81h N/A Memory Card Access\n 5Dh FLAG Send Command 5Dh\n (0) 03h Send dummy/zero, receive length of following data (03h)\n VAL (0) Send receive value.16-23 (whatever), receive dummy/zero\n VAL (0) Send receive value.8-15 (download flags), receive dummy/zero\n VAL (0) Send receive value.0-7 (download duration), receive dummy/zero\n If value.8-15 = 00h, then ComFlags.bit10=1, else ComFlags.bit10=0.\n If download_callback<>0 then call download_callback with r0=value.0-23.\n bit0-7 download duration (in whatever units... 30Hz, RTC, seconds...?)\n bit8 download finished (0=no, 1=yes, cancel any old/busy duration)\n bit9-23 not used by gui\nLEN1 is 00h (no parameters), and LEN2 is 08h (eight data bytes):
DATE Get or Send BCD Day (01h..31h)\n DATE Get or Send BCD Month (01h..12h)\n DATE Get or Send BCD Year (00h..99h)\n DATE Get or Send BCD Century (00h..99h)\n TIME Get or Send BCD Second (00h..59h)\n TIME Get or Send BCD Minute (00h..59h)\n TIME Get or Send BCD Hour (00h..23h)\n TIME Get or Send BCD Day of Week (01h..07h)\nLEN1 is 05h (five parameters bytes):
ADDR Send Pocketstation Memory Address.bit0-7\n ADDR Send Pocketstation Memory Address.bit8-15\n ADDR Send Pocketstation Memory Address.bit16-23\n ADDR Send Pocketstation Memory Address.bit24-31\n LEN2 Send Desired Data Length (00h..80h, automatically clipped to max=80h)\n ... Get or Send LEN2 Data byte(s), max 80h bytes\nLEN1 is 00h (no parameters), and LEN2 is 08h (eight data bytes):
DATA Get or Send Alarm.bit0-7, Alarm Minute (00h..59h, BCD)\n DATA Get or Send Alarm.bit8-15, Alarm Hour (00h..23h, BCD)\n DATA Get or Send Alarm.bit16-23, Flags, see SWI 13h, GetPtrToAlarmSetting()\n DATA Get or Send Alarm.bit24-31, Not used (usually 00h)\n DATA Get or Send Alarm.bit32-39, BIOS Charset Address.0-7\n DATA Get or Send Alarm.bit40-47, BIOS Charset Address.8-15\n DATA Get or Send Alarm.bit48-55, BIOS Charset Address.16-23\n DATA Get or Send Alarm.bit56-63, BIOS Charset Address.24-31\nLEN1 is 04h (fixed) (four parameters bytes):
VAL Send Parameter Value.bit0-7\n VAL Send Parameter Value.bit8-15\n VAL Send Parameter Value.bit16-23\n VAL Send Parameter Value.bit24-31\n ... Get or Send LEN2 Data byte(s)\nLEN1 is variable (depends on the LEN1 value in Function Table in File Header):
... Send LEN1 Parameter Value(s), max 80h bytes (destroys Kernel when >80h)\n ... Get or Send LEN2 Data byte(s), max 80h bytes (clipped to max=80h)\n ;above LEN1 should be 00h..80h (the parameters are stored\n ;in a 80h-byte buffer in kernel RAM, so len LEN1=81h..FFh would\n ;destroy the kernel RAM that is located after that buffer)\nIncoming parameters on 1st Function Call:
r0=flags (09h=Pre-Data to PSX, or 0Ah=Pre-Data from PSX)\n r1=pointer to parameter buffer (which contains LEN1 bytes) (in Kernel RAM)\n r0 = Pointer to 64bit memory location (or r0=00000000h=Failed)\n 0-31 BUF2 address of data buffer (src/dst)\n 32-63 LEN2 (00000000h..00000080h) (clipped to max 00000080h if bigger)\nIncoming parameters on 2nd Function Call:
r0=flags (11h=Post-Data to PSX, 12h=Post-Data from PSX; plus 04h if Bad-Data)\n r1=pointer to data buffer (which contains LEN2 bytes) (BUF2 address)\n There's no return value required on 2nd call (although the kernel\n functions seem to return the same stuff as on 1st call).\nFor each function, there is only one single function vector which is called for both To- and From-PSX, and both Pre- and Post-Data, and also on errors. The function must decipher the flags in r0 to figure out which of that operations it should handle:
0 To-PSX (when used by Command 5Bh)\n 1 From-PSX (when used by Command 5Ch)\n 2 Error occurred during Data transfer\n 3 Pre-Data\n 4 Post-Data\n 5-31 Not used (zero)\n 09h Pre-Data to PSX\n 0Ah Pre-Data from PSX\n 11h Post-Data to PSX\n 12h Post-Data from PSX\n 15h Post-Bad-Data to PSX\n 16h Post-Bad-Data from PSX\nPocketstation files consists of the following elements (in that order):
PSX Title Sector ;80h bytes\n PSX Colored Icon(s) ;(hdr[02h] AND 0Fh)*80h bytes\n Pocketstation Saved Snapshot ;800h bytes if hdr[52h]=\"MCX1\", else 0 bytes\n Pocketstation Function Table ;(hdr[57h]*8+7Fh) AND NOT 7Fh bytes\n Pocketstation File Viewer Mono Icon ;hdr[50h]*80h bytes\n Pocketstation Executable Mono Icon List ;hdr[56h]*8 bytes\n Body (Pocketstation Executable Code/Data, PSX Game Position, Exec-Icons)\nFor pocketstation executables, the 7th byte of the filename must be a \"P\" (for other files that location does usually contain a \"-\", assuming the file uses a standard filename, eg. \"BESLES-12345abcdefgh\" for a Sony licensed european title).
"},{"location":"pocketstation/#special-pocketstation-entries-in-the-title-sector-at-50h5fh","title":"Special Pocketstation Entries in the Title Sector at [50h..5Fh]","text":" 50h 2 Number of File Viewer Mono Icon Frames (or 0000h=Use Exec-Icons)\n 52h 4 Pocketstation Identifier (\"MCX0\"=Normal, \"MCX1\"=With Snapshot)\n 56h 1 Number of entries in Executable Mono Icon List (01h..FFh)\n 57h 1 Number of BU Command 5Bh/5Ch Get/Set Functions (00h..7Fh, usually 00h)\n 58h 4 Reserved (zero)\n 5Ch 4 Entrypoint in FLASH1 (ie. Fileoffset plus 02000000h) (bit0=THUMB)\nFor a load-able snapshot the Snapshot ID must be 01h,00h,\"SE\", the Kernel uses snapshots only once (after loading a snapshot, it forcefully changes the ID to 00h,00h,\"SE\" in FLASH memory).
000h r1..r12 (ie. without r0)\n 030h r13_usr (sp_usr)\n 034h r14_usr (lr_usr)\n 038h r15 (pc)\n 03Ch psr_fc\n 040h Snapshot ID (0xh,00h,\"SE\")\n 044h unused (3Ch bytes)\n 200h Copy of user RAM at 200h..7FFh\nThe table can contain 00h..7Fh entries, for FUNC 80h..FFh. Each entry occupies 8 bytes:
00h 4 LEN1 (00000000h..00000080h) (destroys Kernel RAM if bigger)\n 04h 4 Function Address (bit0 can be set for THUMB code)\nAnimation Length (0001h..any number) (icon frames) is stored in hdr[50h], for the File Viewer Icon, the Animation Delay is fixed (six 30Hz units per frame). The File Viewer Icon is shown in the Directory Viewer (which is activated when holding the Down-button pressed for some seconds in the GUI screen with the speaker and memory card symbols, and which shows icons for all files, including regular PSX game positions, whose colored icons are converted without any contrast optimizations to unidentify-able dithered monochrome icons). If the animation length of the File Viewer Icon is 0000h, then the Directory Viewer does instead display the first Executable Mono Icon. Each icon frame is 32x32 pixels with 1bit color depth (32 words, =128 bytes),
1st word = top-most scanline, 31st word = bottom-most scanline\n bit0 = left-most pixel, bit31 = right-most pixel (0=white, 1=black)\nThe number of entries in the Executable Mono Icon List is specified in hdr[56h] (usually 01h). Each entry in the Icon List occupies 8 bytes:
00h 2 Animation Length (0001h..any number) (icon frames)\n 02h 2 Animation Delay (N 30Hz units per icon frame)\n 04h 4 Address of icon frame(s) in Virtual FLASH (at 02000000h and up)\nThe whole file (including the header and icons) gets mapped to 02000000h and up. The entrypoint can be anywhere in the file Body, and it gets called with a parameter value in r0 (when started by the GUI, that parameter is always zero, but it may be nonzero when the executable was started by a game, ie. the \\<param> from SWI 08h, PrepareExecute, or the \\<param> from BU Command 59h). Caution: Games (and GUI) are started with the ARM CPU running in Non-privileged User Mode (however, there are several ways to hook IRQ/FIQ handlers, and from there one can switch to Privileged System Mode).
"},{"location":"pocketstation/#returning-to-the-gui","title":"Returning to the GUI","text":"Games should always include a way to return to the GUI (eg. an option in the game over screen, a key combination, a watchdog timer, and/or the docking signal) (conventionally, games should prompt Exit/Continue when holding Fire pressed for 5 seconds), otherwise it wouldn't be possible to start other games - except by pushing the Reset button (which is no good idea since the bizarre BIOS reset handler does reset the RTC time for whatever reason). The kernel doesn't pass any return address to the entrypoint (neither in R14, nor on stack). To return control to the GUI, use SWI functions PrepareExecute(1,0,GetDirIndex()+30h), and then DoExecute(0).
"},{"location":"pocketstation/#pocketstation-file-images","title":"Pocketstation File Images","text":"Pocketstation files are normally stored in standard Memory Card images, Memory Card Images
"},{"location":"pocketstation/#pocketstation-specific-files","title":"Pocketstation specific files","text":"Aside from that standard formats, there are two Pocketstation specific formats, the \"SC\" and \"SN\" variants. Both contain only the raw file, without any Directory sectors, and thus not including a \"BESLESP12345\"-style filename string. The absence of the filename means that a PSX game couldn't (re-)open these files via filenames, so they are suitable only for \"standalone\" pocketstation games.
"},{"location":"pocketstation/#pocketstation-bin-files-sc-variant","title":"Pocketstation .BIN Files (\"SC\" variant)","text":"Contains the raw Pocketstation Executable (ie. starting with the \"SC\" bytes in the title sector, followed by icons, etc.), the filesize should be padded to a 2000h-byte block boundary.
"},{"location":"pocketstation/#pocketstation-bin-files-sn-variant","title":"Pocketstation .BIN Files (\"SN\" variant)","text":"This is a strange incomplete .BIN file variant which starts with a 4-byte ID (\"SN\",00h,00h), which is directly followed by executable code, without any title sector, and without any icons.
It seems as if the file (including the 4-byte ID) is intended to be\n mapped to address 02000000h, and that the entrypoint is fixed at\n 02000004h (in ARM state).\n Since the File doesn't have a valid file header with \"SC\" and \"MCXn\" IDs,\n it won't be recognized by real hardware, the PSX BIOS would treat it as\n a corrupted/deleted file, the Pocketstation BIOS would treat it as a\n non-executable file.\n So, that fileformat is apparently working only on whatever emulators,\n apparently on the one developed by SN Systems.\n If one should want to use that files on real hardware, one could add\n a 2000h byte stub at the begin of the file; with valid headers, and\n with a small executable that remaps the \"SN\" stuff to 02000000h via\n the F_BANK_VAL registers.\n Ah, and the \"SN\" files seem to access RAM at 01000000h and up, unknown\n if RAM is mirrored to that location on real hardware, reportedly that\n region is unused... and doesn't contain RAM...?\n Some games use The Undefined Instruction for TTY Output.\n Most games do strange 8bit writes to LCD_MODE+0 and LCD_MODE+1\n The games usually don't allow to return to the GUI (except by Reset).\nThis circuit allows to connect a pocketstation to PC parallel port, allowing to upload executables to real hardware, and also allowing to download TTY debug messages (particulary useful as the 32x32 pixel LCD screen is way too small to display any detailed status info).
"},{"location":"pocketstation/#poc-xboo-circuit","title":"POC-XBOO Circuit","text":"Use a standard parallel port cable (with 36pin centronics connector or 25pin DB connector) and then build a small adaptor like this:
Pin CNTR DB25 Pocketstation _______________________\n ACK 10 10 --------- 1 JOYDTA | | | |\n D0 2 2 --------- 2 JOYCMD | 9 7 6 | 5 4 3 | 2 1 | CARD\n GND 19-30 18-25 ------- 4 GND |_______|_______|_______|\n D1 3 3 --------- 6 /JOYSEL _______________________\n D2 4 4 --------- 7 JOYCLK | | | |\n PE 12 12 --------- 9 /JOYACK (/IRQ7) | 9 8 7 | 6 5 4 | 3 2 1 | PAD\n NC -------------------- 8 /JOYGUN (/IRQ10) \\______|_______|______/\n NC -------------------- 3 7.5V (rumble.supply)\n SUPPLY.5V --|>|---|>|-- 5 3.5V (VCC) (eg. PC's +5V via two 1N4001 diodes)\n SUPPLY.0V ------------- 4 GND (not needed when same as GND on CNTR/DB25)\nThe upload function is found in no$gba \"Utility\" menu. It does upload the executable and autostart it via standard memory card/pocketstation commands (ie. it doesn't require any special transmission software installed on the pocketstation side). Notes: Upload is overwriting ALL files on the memory card, and does then autostart the first file. Upload is done as \"read and write only if different\", this provides faster transfers and higher lifetime.
"},{"location":"pocketstation/#poc-xboo-tty-debug-messages","title":"POC-XBOO TTY Debug Messages","text":"TTY output is conventionally done by executing the ARM CPU's Undefined Opcode with an ASCII character in R0 register (for that purpose, the undef opcode handler should simply point to a MOVS PC,LR opcode). That kind of TTY output works in no$gba's pocketstation emulation. It can be also used via no$gba's POC-XBOO cable, but requires some small customization in the executable: First of, the executable needs \"TTY+\" ID in some reserved bytes of the title sector (telling the xboo uploader to stay in transmission mode and to keep checking for TTY messages after the actual upload):
TitleSector[58h] = \"TTY+\"\n ;------------------\n .data?\n org 200h\n ...\n tty_bufsiz equ 128 ;max=128=fastest (can be smaller if you are short of RAM)\n func3_info: ;\\ ;\\\n func3_buf_base dd 0 ;fixed=\"func3_buf\" ; ; func3_info+00h\n func3_buf_len dd 0 ;range=0..128 ;/ ; func3_info+04h\n func3_stack dd 0 ; func3_info+08h\n func3_buffer: defs tty_bufsiz ;/ func3_info+0Ch\n ptr_to_comflags dd 0\n ...\n .code\n ...\n ;------------------\n tty_wrchr: ;in: r0=char\n dd 0e6000010h ;=undef opcode ;-Write chr(r0) to TTY\n bx lr\n ;------------------\n init_tty: ;in: r0=param (from entrypoint)\n ldr r1,=2B595454h ;\"TTY+\" ;\\check if xboo-cable present\n cmp r1,r0 ; (r0=incoming param from\n beq @@tty_by_xboo_cable ;/executable's entrypoint)\n ;- - -\n mov r1,0 ;\\dummy und_handler\n ldr r2,=0e1b0f00eh ;=movs r15,r14 ; (just return from exception,\n str r2,[r1,04h] ;und_handler ;/for normal cable-less mode)\n b @@finish\n ;---\n @@tty_by_xboo_cable:\n swi 17h ;GetPtrToFunc3addr() ;\\\n ldr r1,=(tty_func3_handler AND 0ffffh) ; init FUNC3 aka TTY handler\n strh r1,[r0] ;/\n ldr r1,=func3_info ;\\\n mov r0,0 ;\\ ; mark TTY as len=empty\n str r0,[r1,4] ;func3_buf_len ;/ ; and\n add r0,r1,0ch ;=func3_buffer ;\\ ; init func3 base\n str r0,[r1,0] ;func3_buf_base ;/ ;/\n mov r1,0 ;\\\n ldr r2,=0e59ff018h ;=ldr r15,[pc,NN] ;\n str r2,[r1,04h] ;und_handler ; special xboo und_handler\n add r2,=tty_xboo_und_handler ;\n str r2,[r1,24h] ;und_vector ;/\n @@finish:\n swi 06h ;GetPtrToComFlags() ;\\\n ldr r1,=ptr_to_comflags ; get ptr to ComFlags\n str r0,[r1] ;/\n bx lr\n ;------------------\n tty_xboo_und_handler: ;in: r0=char\n ldr r13,=func3_info ;aka sp_und ;-base address (in sp_und)\n str r12,[r13,8] ;func3_stack ;-push r12\n @@wait_if_buffer_full: ;\\\n ldr r12,=ptr_to_comflags ; ;\\exit if execute file request\n ldr r12,[r12] ;ptr to ComFlags ; ; ComFlg.Bit11 (\"bu_cmd_59h\"),\n ldr r12,[r12] ;read ComFlags ; ; ie. allow that flag to be\n tst r12,1 shl 11 ;test bit11 ; ; processed by main program,\n bne @@exit ; ;/without hanging here\n ldrb r12,[r13,4] ;func3_buf_len ; wait if buffer full\n cmp r12,tty_bufsiz ; (until drained by FIQ)\n beq @@wait_if_buffer_full ;/\n mov r12,1bh+0c0h ;mode=und, FIQ/IRQ=off ;\\disable FIQ (no COMMUNICATION\n mov cpsr_ctl,r12 ;/interrupt during buffer write)\n ldrb r12,[r13,4] ;func3_buf_len ;\\\n add r12,1 ;raise len ; write char to buffer\n strb r12,[r13,4] ;func3_buf_len ; and raise buffer length\n add r12,0ch-1 ;=func3_buffer+INDEX ;\n strb r0,[r13,r12] ;append char to buf ;/\n @@exit:\n ldr r12,[r13,8] ;func3_stack ;-pop r12\n movs r15,r14 ;return from exception (and restore old IRQ/FIQ state)\n ;------------------\n tty_func3_handler: ;in: r0=flags, r1=ptr\n tst r0,10h ;test if PRE/POST data (pre: Z, post: NZ)\n ;ldreq r1,[r1] ;read 32bit param (aka the four LEN1 bytes of FUNC3)\n ldr r0,=func3_info ;ptr to two 32bit values (FUNC3 return value)\n movne r1,0 ;\\for POST data: mark buffer empty\n strne r1,[r0,4] ;func3_buf_len=0 ;/\n bx lr ;-for PRE data: return r0=func3_info\n CL825 20pin pin test points (2x10 pins)\n CL827 20pin pin test points (2x10 pins)\n U83 64pin SEC KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM\n U84 64pin SEC KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM\n CL828 20pin pin test points (2x10 pins)\n CL826 20pin pin test points (2x10 pins)\n X10 4pin JC53.20 (PAL, 53.203425MHz)\n X2 4pin 53.69317MHz (NTSC, 53.693175MHz)\n U62 20pin LVT244 (dual 4-bit 3-state noninverting buffer/line driver)\n U27 64pin Sony CXD2923AR ;GPU'b\n CL813 20pin pin test points (2x10 pins)\n CL814 20pin pin test points (2x10 pins) (with one resistor or so installed)\n U16 160pin Sony CXD8514Q ;GPU'a\n X7 4pin 67.73760 MHz\n CL807 20pin pin test points (2x10 pins)\n CL809 20pin pin test points (2x10 pins)\n CL811 20pin pin test points (2x10 pins)\n U801 208pin Sony CXD8530BQ ;CPU\n U11 28pin SEC KM48V2104AJ-6 (DRAM 2Mx8) ;Main RAM\n U10 28pin SEC KM48V2104AJ-6 (DRAM 2Mx8) ;Main RAM\n U9 28pin SEC KM48V2104AJ-6 (DRAM 2Mx8) ;Main RAM\n U8 28pin SEC KM48V2104AJ-6 (DRAM 2Mx8) ;Main RAM\n CN801 100pin Blue connector (to other ISA board)\n U66 48pin LVT16244? (quad 4-bit 3-state noninverting buffer/line driver)\n U65 48pin LVT16244? (quad 4-bit 3-state noninverting buffer/line driver)\n U64 48pin LVT16245? (dual 8-bit 3-state noninverting bus transceiver)\n U34 100pin Sony CXD2922Q ;SPU\n U63 14pin 74F74N (dual flipflop)\n U32 44pin SEC KM416V256B1-8 (DRAM 256Kx16) ;SoundRAM\n CL801 20pin pin test points (2x10 pins)\n CL802 20pin pin test points (2x10 pins)\n Q881 3pin voltage stuff?\n U31 20pin 74ACT244P (dual 4-bit 3-state noninverting buffer/line driver)\n U35 18pin Sony CXD2554P or OKI M6538-01 (aka MSM6538-01?) (audio related?)\n U36 20pin Sanyo LC78815 ;16bit D/A Converter\n U37 8pin NEC ...? C4558C? D426N0B or 9426HOB or so?\n J806 8pin solder pads...\n J805 9pin solder pads...\n J804 10pin solder pads... (11pins, with only 10 contacts?)\n - 48pin solder pads (12x4pin config jumpers or so)\n U26 20pin SN74ALSxxx logic?\n U71 24pin Sony CXA1xxxx? ;RGB?\n JPxx 9pin PAL/NTSC Jumpers (three 3pin jumpers)\n J801 24pin solder pads...\n J803 9pin rear connector: Serial Port (3.3V) (aka \"J308\") (DB9) (5+4pin)\n J802 15pin rear connector: AV Multi-out (5+5+5pin)\n CN881 98pin ISA Bus Cart-edge (2x31 basic pins, plus 2x18 extended pins)\n JP72x 68pin Black connector (maybe equivalent to 68pin PSX expansion port?)\n SWI 5pin solder pads...\n U371 40pin HN27C4000G-12 (512Kx8 / 256Kx16 EPROM) (sticker: \"94/7/27\")\n U370 84pin Altera EPM7160ELC84-12 (sticker: \"U730, cntl 1\")\n U3 14pin SN74ALS1004N (hex inverters)\n U43 44pin Altera EPM7032LC44-10 (sticker: \"U43, add 1\")\n U716 28pin Sharp LH5498D-35 (FIFO 2Kx9)\n U717 28pin Sharp LH5498D-35 (FIFO 2Kx9)\n U719 28pin Sharp LH5498D-35 (FIFO 2Kx9)\n U720 28pin Sharp LH5498D-35 (FIFO 2Kx9)\n U724 20pin SN74ALS688N (8bit inverting identity comparator with enable)\n U722 20pin SN74ALS245AN (8bit tristate noninverting bus transceiver)\n U47 20pin 74FCT244ATP (dual 4-bit 3-state noninverting buffer/line driver)\n U732 48pin LVT16245? (dual 8-bit 3-state noninverting bus transceiver)\n U711 20pin SN74ALS244BN (dual 4-bit 3-state noninverting buffer/line driver)\n U712 20pin SN74ALS244BN (dual 4-bit 3-state noninverting buffer/line driver)\n U713 20pin 74HC244AP (dual 4-bit 3-state noninverting buffer/line driver)\n U714 20pin 74HC244AP (dual 4-bit 3-state noninverting buffer/line driver)\n U721 20pin SN74ALS244BN (dual 4-bit 3-state noninverting buffer/line driver)\n U55 14pin SN74ALS08N (quad 2-input AND gates)\n U726 20pin SN74ALS245AN (8bit tristate noninverting bus transceiver)\n U715 20pin 74HC244AP (dual 4-bit 3-state noninverting buffer/line driver)\n JPxx 100pin Blue connector (to other ISA board)\n U738 20pin LVT244 (SMD) (dual 4-bit 3-state noninverting buffer/line driver)\n U734 32pin KM684000G-7 (SRAM 512Kx8) ;\\maybe 1Mbyte EXP3 RAM ?\n U733 32pin KM684000G-7 (SRAM 512Kx8) ;/\n U725 20pin SN74ALS688N (8bit inverting identity comparator with enable)\n S700 24pin 12bit DIP switch (select I/O Address bits A15..A4)\n JP700 8pin Jumper (4x2 pins) (select IRQ15/IRQ12/IRQ11/IRQ10)\n JP7xx 12pin Jumper (3x4 pins) (select DMA7/DMA6/DMA5)\n U64 48pin LVT16245? (dual 8-bit 3-state noninverting bus transceiver)\n U65 48pin LVT16244? (quad 4-bit 3-state noninverting buffer/line driver)\n U66 48pin LVT16244? (quad 4-bit 3-state noninverting buffer/line driver)\n U737 48pin LVT16244? (quad 4-bit 3-state noninverting buffer/line driver)\n U710 20pin SN74ALS244BN (dual 4-bit 3-state noninverting buffer/line driver)\n U709 20pin HD74HC245P (8bit tristate noninverting bus transceiver)\n U723 14pin SN74ALS38AN (quad open-collector NAND gates with buffered output)\n U2 14pin SN74LS19AN (hex inverters with schmitt-trigger)\n U1 8pin Dallas DS1232 (MicroMonitor Chip) ;power-good-detect ?\n U708 20pin HD74HC245P (8bit tristate noninverting bus transceiver)\n X3 2pin 4.1900 (4.19MHz for SPC700 CPU)\n U42 80pin P823, U01Q (Sony CXP82300 SPC700 CPU with piggyback EPROM socket)\n U42' 32pin 27C256A-15 (EPROM 32Kx8) (sticker: \"94/11/28\")\n U706 10pin some slim chip with 1x10 pins\n BT700 2pin battery (or super-cap?) for DS1302S (?) (not installed)\n U729? 5pin voltage stuff?\n U40 8pin Dallas DS1302S (real time clock)\n X4 2pin small crystal (32.768kHz for DS1302S)\n JP702 34pin Black connector (maybe for internal CDROM Emulator ISA cart?)\n U736 28pin Sony CXK58257ASP-70L (SRAM 32Kx8) ;CDROM Sector Buffer?\n U735 100pin Sony CXD1199BQ ;CDROM Decoder/FIFO\n JP715 40pin Blue connector... to external DTL-H2010 CDROM drive?\n JP721 9pin rear connector: Joypad/Memcard 2 (DB9)\n JP719 9pin rear connector: Joypad/Memcard 1 (DB9)\n ? - rear hole for cdrom-cable to Blue 40pin connector?\n J70x 98pin ISA Bus Cart-edge (2x31 basic pins, plus 2x18 extended pins)\nNewer revision of the DTL-H2000 board. Consists of a single PCI card (plus tiny daughterboard with Controller ports).
Mainboard \"PI-27 1-589-867-11, DTL-H2500, MAIN BOARD 1575E01A0, SONY\"\n Daughterboard \"SONY,CN-102 1-589-865-11,CONNECTOR BOARD,DTL-H2500,1575E02A0\"\n CJ1 9pin rear connector: DB9\n CJ2? 15pin rear connector: AV Multi-out (5+5+5pin)\n CJ3 10pin gray connector (to controller daughterboard with two DB9's)\n CJ4 34pin black connector (maybe for internal CDROM Emulator ISA cart?)\n CJ5 50pin black connector (to DTL-H2510, Gray Internal CDROM Drive?)\n CJ6 68pin black connector (maybe equivalent to 68pin PSX expansion port?)\n - 124pin PCI bus cart edge connector\n CJ1' 9pin rear connector: DB9 (CTR1, joypad 1) ;\\\n CJ2' 9pin rear connector: DB9 (CTR2, joypad 2) ; on daughterboard\n CJ3' 10pin gray ribbon cable (to CJ3 on main board) ;/\n IC103 208pin Sony CXD8530CQ (CPU)\n IC106 28pin SEC KM48V2104AT-6 (DRAM 2Mx8)\n IC107 28pin SEC KM48V2104AT-6 (DRAM 2Mx8)\n IC108 28pin SEC KM48V2104AT-6 (DRAM 2Mx8)\n IC109 28pin SEC KM48V2104AT-6 (DRAM 2Mx8)\n IC201 64pin SEC KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM\n IC202 64pin SEC KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM\n IC203 160pin Sony CXD8514Q ;GPU'a\n IC207 64pin Sony CXD2923AR ;GPU'b\n IC303 28pin HM62W256LFP-7T (CDROM SRAM 32Kx8) ;on back side\n IC304 52pin \"D 2021, SC430920PB, G64C 185, JSAA9618A\" (Sub-CPU) ;on back\n IC305 100pin Sony CXD1199BQ (CDROM Decoder/FIFO) ;on back side\n IC308 100pin Sony CXD2922BQ (SPU) ;on back side\n IC310 44pin SEC KM416V256BLT-7 (DRAM 256Kx16) ;SoundRAM ;on back side\n IC402 24pin something bigger\n IC404 8pin something small\n IC405 8pin something small\n IC501 24pin Sony CXA1645M (Analog RGB to Composite) ;on back side\n IC701 4pin \"RD, 5B\" or so ;on back side\n IC801 +++pin \"ALTERA, FLEX, EPF8820ARC208-3, A9607\"\n IC802 20pin LVT245A <-- ;on back side\n IC803 52pin \"IDT71321, LA35J, S9704P\" (2Kx8 dual port SRAM)\n IC804 20pin LVT244A\n IC805 8pin something with socket (sticker: \"PD3\")\n IC807-2 32pin MX 27C1000MC-90 (PROM) ;\\on back side\n IC808 32pin F 29F040A-90 (FLASH) ;/BIOS on these chip(s) or so?\n IC901 4pin 37, 69 ;\\on back side\n IC902 4pin 37, 69 ;/\n ICxxx? 28pin \"DALLAS, DS1230Y-100, NONVOLATILE SRAM\"\n U28 20pin LVT244A\n Z1 20pin LVT244A ;\\on back side\n Z2 20pin LVT245A <-- ;/\n Z3 20pin LVT244A\n Z4 20pin LVT244A ;\\\n Z5 20pin LVT245A <-- ; on back side\n Z6 20pin LVT244A ;/\n Z7 20pin LVT244A\n Z8 20pin LVT244A\n Z9 20pin LVT244A\n X101 4pin RC67.73, JVC 5L (67.7376MHz oscillator for main cpu)\n X201 4pin JC53.20, JVC 6A (for GPU, PAL)\n X202 4pin JC53.69, JVC 6A (for GPU, NTSC)\n X302 3pin 4.000MHz (for sub-cpu)\nAnother revision of the DTL-H2000/DTL-H2500 boards. Consists of a single ISA card stacked together with two huge daughterboards, and probably additionally having a small connector daughterboard. Exact chipset is unknown (there might be components on both sides of the PCBs, most of them not visible due to the PCB stacking, so taking photos/scans of the PCBs would require advanced techniques with screwdrivers). Currently the only known chip name is an EPROM (MX 27C1000DC-90, with sticker \"Title=DTL-H2700, Ver=1.00, Date=96.12.4, Sum=046B No.\"). The ISA card is having markings: \"SONY HCD MWB-7? MADE IN JAPAN, PA47 1-589-003-01 1642E03A0\". One uncommon feature is an extra connector for a \"trigger switch\" (foot pedal), which is reportedly used for activating performance analyzer logging.
"},{"location":"psxdevboardchipsets/#sony-dtl-h201a-dt-hv-graphic-artist-board-ibm-pcats-to-ntsc-video","title":"Sony DTL-H201A / DT-HV - Graphic Artist Board (IBM PC/ATs to NTSC video)","text":" X2 xpin TXC-2 OSC 66.000MHz\n X1 xpin TXC-2AOSC 53.693MHz\n U16 14pin 74F74 (dual flipflop)\n U29 14pin 74AS04 (hex inverters)\n U14 20pin LVT244 (dual 4-bit 3-state noninverting buffer/line driver)\n U18 20pin LVT244 (dual 4-bit 3-state noninverting buffer/line driver)\n U15 20pin ACT244 (dual 4-bit 3-state noninverting buffer/line driver)\n U11 84pin Altera EPM7096LC84-12 (sticker: \"artpc13\" or \"ARTPC13\")\n U13 160pin Sony CXD8514Q ;GPU'a\n U5 14pin ALS38A ? (quad open-collector NAND gates with buffered output)\n U27 20pin ALS244AJ ? (dual 4bit tristate noninverting buffer/line driver)\n Q1 3pin T B596\n U23 64pin KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM\n U22 64pin KM4216V256G-60 (DRAM 256Kx16) ;dual-ported VRAM\n U28 64pin Sony CXD2923AR ;GPU'b\n S1 16pin 8bit DIP switch (select I/O address A15..A8)\n S2 8pin 4bit DIP switch (select I/O address A7..A4)\n U1 20pin SN74ALS688N (8bit inverting identity comparator with enable)\n U2 20pin SN74ALS688N (8bit inverting identity comparator with enable)\n U3 20pin ALS245A (8bit tristate noninverting bus transceiver)\n JP9 12pin Jumper (6x2 pins) (select IRQ15/IRQ11/IRQ10/IRQ9/IRQ5/IRQ3)\n U26 24pin Sony CXA1145M ? ;RGB?\n JP10 3pin Jumper ;\\\n JP12 3pin Jumper ; select \"S\" or \"O\" (?)\n JP11 3pin Jumper ;/\n J3 2pin? Yellow connector (composite video out?)\n J2? pin? Mini DIN? connector (maybe S-video out?)\n J1 15pin High Density SubD (maybe video multi out?)\n CJx 98pin ISA Bus Cart-edge (2x31 basic pins, plus 2x18 extended pins)\n Yellow PCB \"CD Emulator System, (C) Cirtech & SN Systems Ldt, 1994 v1.2\"\n IC 24pin GAL20V8B\n IC 68pin Analog Devices ADSP-2101 (16bit DSP Microprocessor)\n IC 20pin HD74HC244P\n IC15 20pin HD74HC244P\n IC14 20pin CD74HCT245E\n IC7 28pin 27C512-10 (EPROM 64Kx8) (yellow sticker, without text)\n IC 28pin HY62256ALP-70 (SRAM 32Kx8)\n IC12 28pin HY62256ALP-70 (SRAM 32Kx8)\n IC 28pin HY62256ALP-70 (SRAM 32Kx8)\n IC13 84pin Emulex/QLogic FAS216 (Fast Architecture SCSI Processor)\n IC5 84pin Emulex/QLogic FAS216 (Fast Architecture SCSI Processor)\n IC4 24pin GAL20V8B (near IO Addr jumpers)\n IC 20pin 74LS244B1 (near lower 8bit of ISA databus)\n IC 20pin SN74LS245N? (near lower 8bit of ISA databus)\n IC 20pin SN74LS245N (near upper 8bit of ISA databus)\n DMA 12pin Jumpers (select DMA7/6/5)\n IRQ 12pin Jumpers (select IRQ15/12/11/10/7/5)\n IO 16pin Jumpers (select IO Addr 300/308/310/318/380/388/390/398)\n SCSI 6pin Jumpers (select SCSI ID 4/2/1) (aka 3bit 0..7 ?)\n PL3 34pin Connector to DTL-H2000 ?\n PL1 50pin Connector to INTERNAL SCSI hardware ?\n PL2 50pin? Connector to EXTERNAL SCSI hardware ? (25pin plug/50pin cable?)\n Jx 98pin ISA Bus Cart-edge (2x31 basic pins, plus 2x18 extended pins)\n 32pin GM76C8128ALLFW85 (SRAM 128Kx8)\n 44pin ALTERA EPM7032LC44-15T\n 34pin EMULEX FAS101 (SCSI Interface Processor)\n 28pin 27C64 (EPROM 8Kx8) (green sticker, without text)\n 20pin LCX245 (=74245?)\n 8pin 2112, CPA, H9527 (?)\n 3pin transistor? voltage regulator?\n 20pin DIP socket (containing two 10pin resistor networks)\n 20pin DIP socket (containing two 10pin resistor networks)\n 2pin CR2032 Battery 3V\n 68pin Connector to PSX \"Parallel I/O\" expansion port\n 25pin Connector to SCSI hardware (to DTL-S510B or DTL-S2020 ISA cart or so?)\n U15 24pin ?\n U5 28pin 27C256 (EPROM 32Kx8) (not installed)\n U7 4pin 67.7376MHz oscillator\n U8 14pin ?\n U11 44pin SEC KM416V256B1-8 (DRAM 256Kx16) ;SoundRAM\n (44pin package with middle 4pin missing, 40pins used)\n U10 100pin Sony CXD2925Q ;SPU\n U4 160pin Lattice IspLSI 3256 (sticker: \"VER3\")\n U6 128pin Lattice IspLSI xxxx ?\n U12 48pin ?\n U13 48pin ?\n U3 20pin 74ACT244\n U14 5pin \"LM25755, -3.3 P+\" ?\n U2 54pin ?\n U1 54pin ?\n U9 ?pin GP1F31T (light transmitting unit for optical fibre cable)\n ? 124pin PCI bus cart edge connector\n ? 8pin internal jumper/connector? (7pin installed, 1pin empty)\n U1 14pin SN74ALS388N ?\n U2 20pin SN74ALS688N (8bit inverting identity comparator with enable)\n U3 20pin SN74ALS688N (8bit inverting identity comparator with enable)\n U4 24pin PALxxx ?\n U5 20pin SN74ALS245AN\n U6 20pin SN74ALS245AN\n U7 20pin SN74ALS244N\n U8 20pin SN74ALS244N\n U9 20pin SN74ALS245AN\n U10 20pin SN74ALS245AN\n U11 20pin SN74ALS244N\n S2 16pin 8bit DIP switch (ISA 15/14/13/12/11/10/9/8) ;I/O address bit15-8\n S1 8pin 4bit DIP switch (ISA 7/6/5/4) ;I/O address bit7-4\n S3 8pin 4bit DIP switch (BISO? 3/2/1/0) ;BISO? or BISD? or 8150?\n JPxx .... several jumpers (unknown purpose)\n Jx 98pin ISA Bus Cart-edge (2x31 basic pins, plus 2x18 extended pins)\n J5 68pin Connector on rear side (unknown purpose)\nExternal front loading CDROM drive with Eject button. Connects to the blue 40pin connector on DTL-H2000 boards.
IC101 100pin SONY CXD2515Q (Signal Processor + Servo Amp) ;\\\n IC102 28pin BA6297AFP ; on mainboard\n ICxx 20pin SONY CXA1571N (RF Amp) (on tiny daughtboard) ; (HCMK-81X)\n CN101 21pin connector to DEX2010.SCH board ;\n CN10x 12pin connector to KSS-240A (laser pickup) ;\n S101 2pin pos0 switch or so? ;\n M101 2pin spindle motor ;/\n U1 20pin 74ALS244BN ;\\\n U2 20pin 74ALS244BN ;\n U3 20pin 74ALS244BN ; on DEX2010.SCH board\n J1 2pin connector to EJECT BUTTON ;\n J2 5pin connector to LOADING MOTOR ;\n J3 21pin connector to mainboard ;\n JP1 40pin external connector to DTL-H2000 ;/\n CN151 5pin connector to DEX2010.SCH board ;\\\n M151 2pin loading motor (eject motor) ; on CDM 14, CMK PSX board\n S151 2pin OUT SW ;\\switches, probably to ;\n S152 2pin IN SW ;/sense load/eject status ;/\n CN1 2pin connector to DEX2010.SCH board ;\\on DTL-H2010(1) board\n SW1 2pin eject button ;/\nThis is some sort of a mimmicked front loading PC CDROM drive (consisting of a tray that contains a normal (top-loading) PSX cdrom drive unit).
IC309 80pin Sony CXD2510Q (CDROM Signal Processor)\n ICxx ?pin Unknown if there are further ICs (eg. CXA1782BR should exist?)\n CN1 10pin Connector to daughterboard (with drive unit)\n CN2 4pin Connector to PC power supply (12V/5V and 2xGND)\n CN3 50pin Connector to DTL-H2500 or so? (need \"PCS-E50FC\" plug?)\nA rare SCEx-free Playstation that can boot from CDR's without SCEx strings; maybe intended for beta-testers. Marked \"Property of Sony Computer Entertainment\", \"U/C\".
"},{"location":"serialinterfacessio/","title":"Serial Interfaces (SIO)","text":"The console has two serial interfaces, SIO0 (connected to the controller and memory card ports) and SIO1 (connected to the serial port). SIO0 is hardwired to run in synchronous mode, while SIO1 can only operate in asynchronous mode. Both units are fairly similar, although not identical, and seem to be vaguely based on the Intel 8251A USART chip.
"},{"location":"serialinterfacessio/#1f801040hn10h-sio_tx_data-w","title":"1F801040h+N*10h - SIO#_TX_DATA (W)","text":" 0-7 Data to be sent\n 8-31 Not used\n 0-7 Received Data (1st RX FIFO entry) (oldest entry)\n 8-15 Preview (2nd RX FIFO entry)\n 16-23 Preview (3rd RX FIFO entry)\n 24-31 Preview (4th RX FIFO entry) (5th..8th cannot be previewed)\n 0 TX FIFO Not Full (1=Ready for new byte) (depends on CTS) (TX requires CTS)\n 1 RX FIFO Not Empty (0=Empty, 1=Data available)\n 2 TX Idle (1=Idle/Finished) (depends on TXEN and on CTS)\n 3 RX Parity Error (0=No, 1=Error; Wrong Parity, when enabled) (sticky)\n 4 SIO1 RX FIFO Overrun (0=No, 1=Error; received more than 8 bytes) (sticky)\n 5 SIO1 RX Bad Stop Bit (0=No, 1=Error; Bad Stop Bit) (when RXEN) (sticky)\n 6 SIO1 RX Input Level (0=Normal, 1=Inverted) ;only AFTER receiving Stop Bit\n 7 DSR Input Level (0=Off, 1=On) (remote DTR) ;DSR not required to be on\n 8 SIO1 CTS Input Level (0=Off, 1=On) (remote RTS) ;CTS required for TX\n 9 Interrupt Request (0=None, 1=IRQ) (See SIO_CTRL.Bit4,10-12) (sticky)\n 10 Unknown (always zero)\n 11-31 Baudrate Timer (15-21 bit timer, decrementing at 33MHz)\n 0-1 Baudrate Reload Factor (1=MUL1, 2=MUL16, 3=MUL64) (or 0=MUL1 on SIO0, STOP on SIO1)\n 2-3 Character Length (0=5 bits, 1=6 bits, 2=7 bits, 3=8 bits)\n 4 Parity Enable (0=No, 1=Enable)\n 5 Parity Type (0=Even, 1=Odd) (seems to be vice-versa...?)\n 6-7 SIO1 stop bit length (0=Reserved/1bit, 1=1bit, 2=1.5bits, 3=2bits)\n 8 SIO0 clock polarity (CPOL) (0=High when idle, 1=Low when idle)\n 9-15 Not used (always zero)\n 0 TX Enable (TXEN) (0=Disable, 1=Enable)\n 1 DTR Output Level (0=Off, 1=On)\n 2 RX Enable (RXEN) (SIO1: 0=Disable, 1=Enable) ;Disable also clears RXFIFO\n (SIO0: 0=only receive when /CS low, 1=force receiving single byte)\n 3 SIO1 TX Output Level (0=Normal, 1=Inverted, during Inactivity & Stop bits)\n 4 Acknowledge (0=No change, 1=Reset SIO_STAT.Bits 3,4,5,9) (W)\n 5 SIO1 RTS Output Level (0=Off, 1=On)\n 6 Reset (0=No change, 1=Reset most registers to zero) (W)\n 7 SIO1 unknown? (read/write-able when FACTOR non-zero) (otherwise always zero)\n 8-9 RX Interrupt Mode (0..3 = IRQ when RX FIFO contains 1,2,4,8 bytes)\n 10 TX Interrupt Enable (0=Disable, 1=Enable) ;when SIO_STAT.0-or-2 ;Ready\n 11 RX Interrupt Enable (0=Disable, 1=Enable) ;when N bytes in RX FIFO\n 12 DSR Interrupt Enable (0=Disable, 1=Enable) ;when SIO_STAT.7 ;DSR high or /ACK low\n 13 SIO0 port select (0=port 1, 1=port 2) (/CS pulled low when bit 1 set)\n 14-15 Not used (always zero)\nThis is an internal register, which usually shouldn't be accessed by software. Messing with it has rather strange effects: After writing a value \"X\" to this register, reading returns \"X ROR 8\" eventually \"ANDed with 1F1Fh and ORed with C0C0h or 8080h\" (depending on the character length in SIO_MODE). SIO0 does not have this register.
"},{"location":"serialinterfacessio/#1f80104ehn10h-sio_baud-rw-eg-00dch-9600-bps-when-factormul16","title":"1F80104Eh+N*10h - SIO#_BAUD (R/W) (eg. 00DCh --> 9600 bps; when Factor=MUL16)","text":" 0-15 Baudrate Reload value for decrementing Baudrate Timer\n SIO0: BitsPerSecond = 33868800 / MIN(((Reload*Factor) AND NOT 1),1)\n SIO1: BitsPerSecond = 33868800 / MIN(((Reload*Factor) AND NOT 1),Factor)\n SIO0_BAUD is multiplied by Factor, and does then elapse \"2\" times per bit.\n SIO1_BAUD is NOT multiplied, and, instead, elapses \"2*Factor\" times per bit.\nThe hardware can hold (almost) 2 bytes in the TX direction (one being currently transferred, and, once when the start bit was sent, another byte can be stored in SIO_TX_DATA). When writing to SIO_TX_DATA, both SIO_STAT.0 and SIO_STAT.2 become zero. As soon as the transfer starts, SIO_STAT.0 becomes set (indicating that one can write a new byte to SIO_TX_DATA; although the transmission is still busy). As soon as the transfer of the most recently written byte ends, SIO_STAT.2 becomes set.
"},{"location":"serialinterfacessio/#sio_rx_data-notes","title":"SIO_RX_DATA Notes","text":"The hardware can hold 8 bytes in the RX direction (when receiving further byte(s) while the RX FIFO is full, then the last FIFO entry will by overwritten by the new byte, and SIO_STAT.4 gets set; the hardware does NOT automatically disable RTS when the FIFO becomes full). The RX FIFO overrun flag is not accessible on SIO0. Data can be read from SIO_RX_DATA when SIO_STAT.1 is set, that flag gets automatically cleared after reading from SIO_RX_DATA (unless there are still further bytes in the RX FIFO). Note: The hardware does always store incoming data in RX FIFO (even when Parity or Stop bits are invalid). Note: A 16bit read allows to read two FIFO entries at once; nethertheless, it removes only ONE entry from the FIFO. On the contrary, a 32bit read DOES remove FOUR entries (although, there's nothing that'd indicate if the FIFO did actually contain four entries). Reading from Empty RX FIFO returns either the most recently received byte or zero (the hardware stores incoming data in ALL unused FIFO entries; eg. if five entries are used, then the data gets stored thrice, after reading 6 bytes, the FIFO empty flag gets set, but nethertheless, the last byte can be read two more times, but doing further reads returns 00h).
"},{"location":"serialinterfacessio/#interrupt-acknowledge-notes","title":"Interrupt Acknowledge Notes","text":"First reset I_STAT.8, then set SIO.CTRL.4 (when doing it vice-versa, the hardware may miss a new IRQ which may occur immediately after setting SIO.CTRL.4) (and I_STAT.8 is edge triggered, so that bit can be reset even while SIO_STAT.9 is still set). When acknowledging via SIO_CTRL.4 with the enabled condition(s) in SIO_CTRL.10-12 still being true (eg. the RX FIFO is still not empty): the IRQ does trigger again (almost) immediately (it goes off only for a very short moment; barely enough to allow I_STAT.8 to sense a edge).
"},{"location":"serialinterfacessio/#note","title":"Note","text":"For more details on how SIO0 is used to communicate with controllers and memory cards, see: Controller and Memory Card Overview For serial port pinouts, PSone SIO1 upgrading, and for building RS232 adaptors, see: Pinouts - SIO Pinouts Aside from the internal SIO port, the PSX BIOS supports two additional external serial ports, connected to the expansion port. EXP2 Dual Serial Port (for TTY Debug Terminal)
"},{"location":"serialinterfacessio/#sio1-link-cable-games","title":"SIO1 link cable games","text":"The serial ports on two consoles can be connected with an SCPH-1040 Link Cable (known as Taisen Cable, or \"Fight Cable\" in Japan) for multiplayer functionality on games that support this method. This was used by a small number of games in the console's lifecycle, but inconveniently required a second console and copy of the game.
Two-Console Link Cable Games (Incomplete List):
Andretti Racing\nArmored Core (and Armored Core \"Link Versus Demo\" disc)\nArmored Core Project Phantasma\nArmored Core Master of Arena\nAssault Rigs\nAyrton Senna Kart Duel\nBlast Radius\nBogey Dead 6\nBurning Road\nBushido Blade\nBushido Blade 2\nC1 -Circuit-\nCART World Series\nCommand & Conquer Red Alert\nCommand & Conquer Red Alert Retaliation\nCool Boarders 2\nDead in the Water\nDescent\nDescent Maximum\nDestruction Derby\nDuke Nukem Total Meltdown\nDodgem Arena\nDoom\nDune 2000\nExplosive Racing (X Racing in NTSC-J)\nFinal Doom\nFormula 1\nFormula 1 98\nGrand Tour Racing '98 (Gekisou!! Grand Racing -Total Driving'- in NTSC-J, Total Drivin in PAL)\nIndependence Day\nKrazy Ivan\nLeading Jockey Highbred\nMetal Jacket\nMobile Suit Z-Gundam\nMonaco Grand Prix Racing Simulation 2 (Monaco Grand Prix in NTSC-U/C)\nMotor Toon Grand Prix (reportedly NTSC-U/C version only)\nMotor Toon Grand Prix 2\nMotor Toon Grand Prix USA Edition\nThe Need for Speed (Over Drivin' DX in NTSC-J)\nPrePre Vol. 2\nPro Pinball Big Race USA\nRacinGroovy\nReal Robots Final Attack\nRed Asphalt (Rock & Roll Racing 2 Red Asphalt in PAL)\nRidge Racer Revolution\nR4 Ridge Racer Type 4\nRobo Pit\nRogue Trip Vacation 2012\nSan Francisco Rush Extreme Racing (reportedly PAL version only)\nShutokou Battle R\nSidewinder\nSidewinder USA\nSoukou Kihei Votoms Gaiden: Ao no Kishi Berserga Monogatari\nStreak Hoverboard Racing\nTest Drive 4\nTest Drive Off-Road (reportedly NTSC-U/C only)\nTOCA 2 Touring Car Challenge (TOCA 2 Touring Cars in PAL)\nTrick'N Snowboarder (Tricky Sliders Freestyle Snowboard in NTSC-J)\nTwisted Metal III\nWing Over\nWipeout\nWipeout 3 Special Edition\nWipeout XL (Wipeout 2097 in PAL)\nZero Pilot Ginyoku no Senshi\nThe serial port is used (for 2-player link) by Wipeout 2097 (that game accidently assumes BAUDs based on 64*1024*1025 Hz rather than on 600h*44100 Hz). Ridge Racer Revolution is also said to support 2P link. Keitai Eddy seems to allow to connect a mobile phone to the SIO port (the games CD cover suggests so; this seems to be something different than the \"normal\" I-Mode adaptor, which would connect to controller port, not to SIO port).
"},{"location":"soundprocessingunitspu/","title":"Sound Processing Unit (SPU)","text":"SPU Overview SPU ADPCM Samples SPU ADPCM Pitch SPU Volume and ADSR Generator SPU Voice Flags SPU Noise Generator SPU Control and Status Register SPU Memory Access SPU Interrupt SPU Reverb Registers SPU Reverb Formula SPU Reverb Examples SPU Unknown Registers SPU Internal State Machine from SPU RAM Timing
"},{"location":"soundprocessingunitspu/#spu-overview","title":"SPU Overview","text":""},{"location":"soundprocessingunitspu/#spu-io-port-summary","title":"SPU I/O Port Summary","text":" 1F801C00h..1F801D7Fh - Voice 0..23 Registers (eight 16bit regs per voice)\n 1F801D80h..1F801D87h - SPU Control (volume)\n 1F801D88h..1F801D9Fh - Voice 0..23 Flags (six 1bit flags per voice)\n 1F801DA2h..1F801DBFh - SPU Control (memory, control, etc.)\n 1F801DC0h..1F801DFFh - Reverb configuration area\n 1F801E00h..1F801E5Fh - Voice 0..23 Internal Registers\n 1F801E60h..1F801E7Fh - Unknown?\n 1F801E80h..1F801FFFh - Unused?\n 00000h-003FFh CD Audio left (1Kbyte) ;\\CD Audio before Volume processing\n 00400h-007FFh CD Audio right (1Kbyte) ;/signed 16bit samples at 44.1kHz\n 00800h-00BFFh Voice 1 mono (1Kbyte) ;\\Voice 1 and 3 after ADSR processing\n 00C00h-00FFFh Voice 3 mono (1Kbyte) ;/signed 16bit samples at 44.1kHz\n 01000h-xxxxxh ADPCM Samples (first 16bytes usually contain a Sine wave)\n xxxxxh-7FFFFh Reverb work area\nThe SPU has 24 hardware voices. These voices can be used to reproduce sample data, noise or can be used as frequency modulator on the next voice. Each voice has it's own programmable ADSR envelope filter. The main volume can be programmed independently for left and right output.
"},{"location":"soundprocessingunitspu/#voice-capabilities","title":"Voice Capabilities","text":"All 24 voices are having exactly the same capabilities(?), with the exception that Voice 1 and 3 are having a special Capture feature (see SPU Memory map). There seems to be no way to produce square waves (without storing a square wavefrom in memory... although, since SPU RAM isn't connected to the CPU bus, the \"useless\" DMA for square wave data wouldn't slowdown the CPU bus)?
"},{"location":"soundprocessingunitspu/#additional-sound-inputs","title":"Additional Sound Inputs","text":"External Audio can be input (from the Expansion Port?), and the CDROM drive can be commanded to playback normal Audio CDs (via Play command), or XA-ADPCM sectors (via Read command), and to pass that data to the SPU.
"},{"location":"soundprocessingunitspu/#monostereo-audio-output","title":"Mono/Stereo Audio Output","text":"The standard PSX Audio cables have separate Left/Right signals, that is good for stereo TVs, but, when using a normal mono TV, only one of the two audio signals (Left or Right) can be connected. PSX programs should thus offer an option to disable stereo effects, and to output an equal volume to both cables.
"},{"location":"soundprocessingunitspu/#unstable-and-delayed-io","title":"Unstable and Delayed I/O","text":"The SPU occasionally seems to \"miss\" 32bit I/O writes (not sure if that can be fixed by any Memory Control settings?), a stable workaround is to split each 32bit write into two 16bit writes. The SPU seems to process written values at 44100Hz rate (so it may take 1/44100 seconds (300h clock cycles) until it has actually realized the new value).
"},{"location":"soundprocessingunitspu/#spu-bus-width","title":"SPU Bus-Width","text":"The SPU is connected to a 16bit databus. 8bit/16bit/32bit reads and 16bit writes are implemented; 32bit writes are also supported but seem to be particularly unstable (see above). However, 8bit writes are NOT implemented: 8bit writes to ODD addresses are simply ignored (without causing any exceptions), 8bit writes to EVEN addresses are executed as 16bit writes (e.g. li v0, 12345678h; sb v0, spu\\_port will write 5678h instead of 78h).
The SPU supports only ADPCM compressed samples (uncompressed samples seem to be totally unsupported; leaving apart that one can write uncompressed 16bit PCM samples to the Reverb Buffer, which can be then output at 22050Hz, as long as they aren't overwritten by the hardware).
"},{"location":"soundprocessingunitspu/#1f801c06hn10h-voice-023-adpcm-start-address-rw","title":"1F801C06h+N*10h - Voice 0..23 ADPCM Start Address (R/W)","text":"This register holds the sample start address (not the current address, ie. the register doesn't increment during playback).
15-0 Startaddress of sound in Sound buffer (in 8-byte units)\nIf the hardware finds an ADPCM header with Loop-Start-Bit, then it copies the current address to the repeat addresss register. If the hardware finds an ADPCM header with Loop-Stop-Bit, then it copies the repeat addresss register setting to the current address; that, \\<after> playing the current ADPCM block.
15-0 Address sample loops to at end (in 8-byte units)\nSamples consist of one or more 16-byte blocks:
00h Shift/Filter (reportedly same as for CD-XA) (see there)\n 01h Flag Bits (see below)\n 02h Compressed Data (LSBs=1st Sample, MSBs=2nd Sample)\n 03h Compressed Data (LSBs=3rd Sample, MSBs=4th Sample)\n 04h Compressed Data (LSBs=5th Sample, MSBs=6th Sample)\n ... ...\n 0Fh Compressed Data (LSBs=27th Sample, MSBs=28th Sample)\n 0 Loop End (0=No change, 1=Set ENDX flag and Jump to [1F801C0Eh+N*10h])\n 1 Loop Repeat (0=Force Release and set ADSR Level to Zero; only if Bit0=1)\n 2 Loop Start (0=No change, 1=Copy current address to [1F801C0Eh+N*10h])\n 3-7 Unknown (usually 0)\n Code 0 = Normal (continue at next 16-byte block)\n Code 1 = End+Mute (jump to Loop-address, set ENDX flag, Release, Env=0000h)\n Code 2 = Ignored (same as Code 0)\n Code 3 = End+Repeat (jump to Loop-address, set ENDX flag)\nThe Loop Start/End flags in the ADPCM Header allow to play one or more sample block(s) in a loop, that can be either all block(s) endless repeated, or only the last some block(s) of the sample. There's no way to stop the output, so a one-shot sample must be followed by dummy block (with Loop Start/End flags both set, and all data nibbles set to zero; so that the block gets endless repeated, but doesn't produce any sound).
"},{"location":"soundprocessingunitspu/#spu-adpcm-vs-xa-adpcm","title":"SPU-ADPCM vs XA-ADPCM","text":"The PSX supports two ADPCM formats: SPU-ADPCM (as described above), and XA-ADPCM. XA-ADPCM is decompressed by the CDROM Controller, and sent directly to the sound mixer, without needing to store the data in SPU RAM, nor needing to use a Voice channel. The actual decompression algorithm is the same for both formats. However, the XA nibbles are arranged in different order, and XA uses 2x28 nibbles per block (instead of 2x14), XA blocks can contain mono or stereo data, XA supports only two sample rates, and, XA doesn't support looping.
"},{"location":"soundprocessingunitspu/#spu-adpcm-pitch","title":"SPU ADPCM Pitch","text":""},{"location":"soundprocessingunitspu/#1f801c04hn10h-voice-023-adpcm-sample-rate-rw-vxpitch","title":"1F801C04h+N*10h - Voice 0..23 ADPCM Sample Rate (R/W) (VxPitch)","text":" 0-15 Sample rate (0=stop, 4000h=fastest, 4001h..FFFFh=usually same as 4000h)\nPitch modulation allows to generate \"Frequency Sweep\" effects by mis-using the amplitude from channel (x-1) as pitch factor for channel (x).
0 Unknown... Unused?\n 1-23 Flags for Voice 1..23 (0=Normal, 1=Modulate by Voice 0..22)\n 24-31 Not used\nThe pitch counter is adjusted at 44100Hz rate as follows:
Step = VxPitch ;range +0000h..+FFFFh (0...705.6 kHz)\n IF PMON.Bit(x)=1 AND (x>0) ;pitch modulation enable\n Factor = VxOUTX(x-1) ;range -8000h..+7FFFh (prev voice amplitude)\n Factor = Factor+8000h ;range +0000h..+FFFFh (factor = 0.00 .. 1.99)\n Step=SignExpand16to32(Step) ;hardware glitch on VxPitch>7FFFh, make sign\n Step = (Step * Factor) SAR 15 ;range 0..1FFFFh (glitchy if VxPitch>7FFFh)\n Step=Step AND 0000FFFFh ;hardware glitch on VxPitch>7FFFh, kill sign\n IF Step>3FFFh then Step=4000h ;range +0000h..+3FFFh (0.. 176.4kHz)\n Counter = Counter + Step\nThe Mixer and DAC supports a 44.1kHz output rate (allowing to produce max 22.1kHz tones). The Reverb unit supports only half the frequency. The pitch counter supports sample rates up to 176.4kHz. However, exceeding the 44.1kHz limit causes the hardware to skip samples (or actually: to apply incomplete interpolation on the 'skipped' samples). VxPitch can be theoretically 0..FFFFh (max 705.6kHz), normally 4000h..FFFFh are simply clipped to max=4000h (176.4kHz). Except, 4000h..FFFFh could be used with pitch modulation (as they are multiplied by 0.00..1.99 before clipping; in practice this works only for 4000h..7FFFh; as values 8000h..FFFFh are mistaken as signed values).
"},{"location":"soundprocessingunitspu/#4-point-gaussian-interpolation","title":"4-Point Gaussian Interpolation","text":"Interpolation is applied on the 4 most recent 16bit ADPCM samples (new,old,older,oldest), using bit4-11 of the pitch counter as 8bit interpolation index (i=00h..FFh):
out = ((gauss[0FFh-i] * oldest) SAR 15)\n out = out + ((gauss[1FFh-i] * older) SAR 15)\n out = out + ((gauss[100h+i] * old) SAR 15)\n out = out + ((gauss[000h+i] * new) SAR 15)\n -001h,-001h,-001h,-001h,-001h,-001h,-001h,-001h ;\\\n -001h,-001h,-001h,-001h,-001h,-001h,-001h,-001h ;\n 0000h,0000h,0000h,0000h,0000h,0000h,0000h,0001h ;\n 0001h,0001h,0001h,0002h,0002h,0002h,0003h,0003h ;\n 0003h,0004h,0004h,0005h,0005h,0006h,0007h,0007h ;\n 0008h,0009h,0009h,000Ah,000Bh,000Ch,000Dh,000Eh ;\n 000Fh,0010h,0011h,0012h,0013h,0015h,0016h,0018h ; entry\n 0019h,001Bh,001Ch,001Eh,0020h,0021h,0023h,0025h ; 000h..07Fh\n 0027h,0029h,002Ch,002Eh,0030h,0033h,0035h,0038h ;\n 003Ah,003Dh,0040h,0043h,0046h,0049h,004Dh,0050h ;\n 0054h,0057h,005Bh,005Fh,0063h,0067h,006Bh,006Fh ;\n 0074h,0078h,007Dh,0082h,0087h,008Ch,0091h,0096h ;\n 009Ch,00A1h,00A7h,00ADh,00B3h,00BAh,00C0h,00C7h ;\n 00CDh,00D4h,00DBh,00E3h,00EAh,00F2h,00FAh,0101h ;\n 010Ah,0112h,011Bh,0123h,012Ch,0135h,013Fh,0148h ;\n 0152h,015Ch,0166h,0171h,017Bh,0186h,0191h,019Ch ;/\n 01A8h,01B4h,01C0h,01CCh,01D9h,01E5h,01F2h,0200h ;\\\n 020Dh,021Bh,0229h,0237h,0246h,0255h,0264h,0273h ;\n 0283h,0293h,02A3h,02B4h,02C4h,02D6h,02E7h,02F9h ;\n 030Bh,031Dh,0330h,0343h,0356h,036Ah,037Eh,0392h ;\n 03A7h,03BCh,03D1h,03E7h,03FCh,0413h,042Ah,0441h ;\n 0458h,0470h,0488h,04A0h,04B9h,04D2h,04ECh,0506h ;\n 0520h,053Bh,0556h,0572h,058Eh,05AAh,05C7h,05E4h ; entry\n 0601h,061Fh,063Eh,065Ch,067Ch,069Bh,06BBh,06DCh ; 080h..0FFh\n 06FDh,071Eh,0740h,0762h,0784h,07A7h,07CBh,07EFh ;\n 0813h,0838h,085Dh,0883h,08A9h,08D0h,08F7h,091Eh ;\n 0946h,096Fh,0998h,09C1h,09EBh,0A16h,0A40h,0A6Ch ;\n 0A98h,0AC4h,0AF1h,0B1Eh,0B4Ch,0B7Ah,0BA9h,0BD8h ;\n 0C07h,0C38h,0C68h,0C99h,0CCBh,0CFDh,0D30h,0D63h ;\n 0D97h,0DCBh,0E00h,0E35h,0E6Bh,0EA1h,0ED7h,0F0Fh ;\n 0F46h,0F7Fh,0FB7h,0FF1h,102Ah,1065h,109Fh,10DBh ;\n 1116h,1153h,118Fh,11CDh,120Bh,1249h,1288h,12C7h ;/\n 1307h,1347h,1388h,13C9h,140Bh,144Dh,1490h,14D4h ;\\\n 1517h,155Ch,15A0h,15E6h,162Ch,1672h,16B9h,1700h ;\n 1747h,1790h,17D8h,1821h,186Bh,18B5h,1900h,194Bh ;\n 1996h,19E2h,1A2Eh,1A7Bh,1AC8h,1B16h,1B64h,1BB3h ;\n 1C02h,1C51h,1CA1h,1CF1h,1D42h,1D93h,1DE5h,1E37h ;\n 1E89h,1EDCh,1F2Fh,1F82h,1FD6h,202Ah,207Fh,20D4h ;\n 2129h,217Fh,21D5h,222Ch,2282h,22DAh,2331h,2389h ; entry\n 23E1h,2439h,2492h,24EBh,2545h,259Eh,25F8h,2653h ; 100h..17Fh\n 26ADh,2708h,2763h,27BEh,281Ah,2876h,28D2h,292Eh ;\n 298Bh,29E7h,2A44h,2AA1h,2AFFh,2B5Ch,2BBAh,2C18h ;\n 2C76h,2CD4h,2D33h,2D91h,2DF0h,2E4Fh,2EAEh,2F0Dh ;\n 2F6Ch,2FCCh,302Bh,308Bh,30EAh,314Ah,31AAh,3209h ;\n 3269h,32C9h,3329h,3389h,33E9h,3449h,34A9h,3509h ;\n 3569h,35C9h,3629h,3689h,36E8h,3748h,37A8h,3807h ;\n 3867h,38C6h,3926h,3985h,39E4h,3A43h,3AA2h,3B00h ;\n 3B5Fh,3BBDh,3C1Bh,3C79h,3CD7h,3D35h,3D92h,3DEFh ;/\n 3E4Ch,3EA9h,3F05h,3F62h,3FBDh,4019h,4074h,40D0h ;\\\n 412Ah,4185h,41DFh,4239h,4292h,42EBh,4344h,439Ch ;\n 43F4h,444Ch,44A3h,44FAh,4550h,45A6h,45FCh,4651h ;\n 46A6h,46FAh,474Eh,47A1h,47F4h,4846h,4898h,48E9h ;\n 493Ah,498Ah,49D9h,4A29h,4A77h,4AC5h,4B13h,4B5Fh ;\n 4BACh,4BF7h,4C42h,4C8Dh,4CD7h,4D20h,4D68h,4DB0h ;\n 4DF7h,4E3Eh,4E84h,4EC9h,4F0Eh,4F52h,4F95h,4FD7h ; entry\n 5019h,505Ah,509Ah,50DAh,5118h,5156h,5194h,51D0h ; 180h..1FFh\n 520Ch,5247h,5281h,52BAh,52F3h,532Ah,5361h,5397h ;\n 53CCh,5401h,5434h,5467h,5499h,54CAh,54FAh,5529h ;\n 5558h,5585h,55B2h,55DEh,5609h,5632h,565Bh,5684h ;\n 56ABh,56D1h,56F6h,571Bh,573Eh,5761h,5782h,57A3h ;\n 57C3h,57E2h,57FFh,581Ch,5838h,5853h,586Dh,5886h ;\n 589Eh,58B5h,58CBh,58E0h,58F4h,5907h,5919h,592Ah ;\n 593Ah,5949h,5958h,5965h,5971h,597Ch,5986h,598Fh ;\n 5997h,599Eh,59A4h,59A9h,59ADh,59B0h,59B2h,59B3h ;/\n Incoming ADPCM Data ---> Interpolated Data\n _ _ _ _\n | | | | | | | | . . . . Nibbles=79797979, Filter=0\n | | | | | | | | ---> / \\ / \\ / \\ / \\ HALF-volume ZIGZAG-wave\n | |_| |_| |_| |_ ' ' ' '\n ___ ___\n | | | | .'. .'. Nibbles=77997799, Filter=0\n | | | | ---> / \\ / \\ FULL-volume SINE-wave\n | |___| |___ ' '.' '.\n _______ ___\n | | .' '. Nibbles=77779999, Filter=0\n | | ---> / \\ SQUARE wave (with rounded edges)\n | |_______ ' '.____\n _____ _ __\n | |_ _| .' ''. .' Nibbles=7777CC44, Filter=0\n | |___| ---> / '..' CUSTOM wave-form\n | '\n ___ __\n | |___| | _ \\ ! / . \\ ! / Nibbles=77DE9HZK, Filter=V\n |_ ____| _| ---> - + - + - + - SOLAR STORM wave-form\n __| |______|___ / ! \\ ' / ! \\\n ____lower 16bit (at 1F801C08h+N*10h)___________________________________\n 15 Attack Mode (0=Linear, 1=Exponential)\n - Attack Direction (Fixed, always Increase) (until Level 7FFFh)\n 14-10 Attack Shift (0..1Fh = Fast..Slow)\n 9-8 Attack Step (0..3 = \"+7,+6,+5,+4\")\n - Decay Mode (Fixed, always Exponential)\n - Decay Direction (Fixed, always Decrease) (until Sustain Level)\n 7-4 Decay Shift (0..0Fh = Fast..Slow)\n - Decay Step (Fixed, always \"-8\")\n 3-0 Sustain Level (0..0Fh) ;Level=(N+1)*800h\n ____upper 16bit (at 1F801C0Ah+N*10h)___________________________________\n 31 Sustain Mode (0=Linear, 1=Exponential)\n 30 Sustain Direction (0=Increase, 1=Decrease) (until Key OFF flag)\n 29 Not used? (should be zero)\n 28-24 Sustain Shift (0..1Fh = Fast..Slow)\n 23-22 Sustain Step (0..3 = \"+7,+6,+5,+4\" or \"-8,-7,-6,-5\") (inc/dec)\n 21 Release Mode (0=Linear, 1=Exponential)\n - Release Direction (Fixed, always Decrease) (until Level 0000h)\n 20-16 Release Shift (0..1Fh = Fast..Slow)\n - Release Step (Fixed, always \"-8\")\nFixed Volume Mode (when Bit15=0):
15 Must be zero (0=Volume Mode)\n 0-14 Voice volume/2 (-4000h..+3FFFh = Volume -8000h..+7FFEh)\n 15 Must be set (1=Sweep Mode)\n 14 Sweep Mode (0=Linear, 1=Exponential)\n 13 Sweep Direction (0=Increase, 1=Decrease)\n 12 Sweep Phase (0=Positive, 1=Negative)\n 7-11 Not used? (should be zero)\n 6-2 Sweep Shift (0..1Fh = Fast..Slow)\n 1-0 Sweep Step (0..3 = \"+7,+6,+5,+4\" or \"-8,-7,-6,-5\") (inc/dec)\n 0-15 Volume Left (-8000h..+7FFFh)\n 16-31 Volume Right (-8000h..+7FFFh)\n AdsrCycles = 1 SHL Max(0,ShiftValue-11)\n AdsrStep = StepValue SHL Max(0,11-ShiftValue)\n IF exponential AND increase AND AdsrLevel>6000h THEN AdsrCycles=AdsrCycles*4\n IF exponential AND decrease THEN AdsrStep=AdsrStep*AdsrLevel/8000h\n Wait(AdsrCycles) ;cycles counted at 44.1kHz clock\n AdsrLevel=AdsrLevel+AdsrStep ;saturated to 0..+7FFFh\n 15-0 Current ADSR Volume (0..+7FFFh) (or -8000h..+7FFFh on manual write)\n 0-15 Current Volume Left (-8000h..+7FFFh)\n 16-31 Current Volume Right (-8000h..+7FFFh)\nNegative volumes are phase inverted, otherwise same as positive.
"},{"location":"soundprocessingunitspu/#spu-voice-flags","title":"SPU Voice Flags","text":""},{"location":"soundprocessingunitspu/#1f801d88h-voice-023-key-on-start-attackdecaysustain-kon-w","title":"1F801D88h - Voice 0..23 Key ON (Start Attack/Decay/Sustain) (KON) (W)","text":" 0-23 Voice 0..23 On (0=No change, 1=Start Attack/Decay/Sustain)\n 24-31 Not used\n 0-23 Voice 0..23 Off (0=No change, 1=Start Release)\n 24-31 Not used\n 0-23 Voice 0..23 Status (0=Newly Keyed On, 1=Reached LOOP-END)\n 24-31 Not used\nKey On and Key Off should be treated as write-only (although, reading returns the most recently 32bit value, this doesn't doesn't provide any status information about whether sound is on or off). The on/off (status) (ENDX) register should be treated read-only (writing is possible in so far that the written value can be read-back for a short moment, however, thereafter the hardware is overwriting that value).
"},{"location":"soundprocessingunitspu/#spu-noise-generator","title":"SPU Noise Generator","text":""},{"location":"soundprocessingunitspu/#1f801d94h-voice-023-noise-mode-enable-non","title":"1F801D94h - Voice 0..23 Noise mode enable (NON)","text":" 0-23 Voice 0..23 Noise (0=ADPCM, 1=Noise)\n 24-31 Not used\nThe signed 16bit output Level is calculated as so (repeated at 44.1kHz clock):
Wait(1 cycle) ;at 44.1kHz clock\n Timer=Timer-NoiseStep ;subtract Step (4..7)\n ParityBit = NoiseLevel.Bit15 xor Bit12 xor Bit11 xor Bit10 xor 1\n IF Timer<0 then NoiseLevel = NoiseLevel*2 + ParityBit\n IF Timer<0 then Timer=Timer+(20000h SHR NoiseShift) ;reload timer once\n IF Timer<0 then Timer=Timer+(20000h SHR NoiseShift) ;reload again if needed\n 15 SPU Enable (0=Off, 1=On) (Don't care for CD Audio)\n 14 Mute SPU (0=Mute, 1=Unmute) (Don't care for CD Audio)\n 13-10 Noise Frequency Shift (0..0Fh = Low .. High Frequency)\n 9-8 Noise Frequency Step (0..03h = Step \"4,5,6,7\")\n 7 Reverb Master Enable (0=Disabled, 1=Enabled)\n 6 IRQ9 Enable (0=Disabled/Acknowledge, 1=Enabled; only when Bit15=1)\n 5-4 Sound RAM Transfer Mode (0=Stop, 1=ManualWrite, 2=DMAwrite, 3=DMAread)\n 3 External Audio Reverb (0=Off, 1=On)\n 2 CD Audio Reverb (0=Off, 1=On) (for CD-DA and XA-ADPCM)\n 1 External Audio Enable (0=Off, 1=On)\n 0 CD Audio Enable (0=Off, 1=On) (for CD-DA and XA-ADPCM)\n 15-12 Unknown/Unused (seems to be usually zero)\n 11 Writing to First/Second half of Capture Buffers (0=First, 1=Second)\n 10 Data Transfer Busy Flag (0=Ready, 1=Busy)\n 9 Data Transfer DMA Read Request (0=No, 1=Yes)\n 8 Data Transfer DMA Write Request (0=No, 1=Yes)\n 7 Data Transfer DMA Read/Write Request ;seems to be same as SPUCNT.Bit5\n 6 IRQ9 Flag (0=No, 1=Interrupt Request)\n 5-0 Current SPU Mode (same as SPUCNT.Bit5-0, but, applied a bit delayed)\n 15-0 Address in sound buffer divided by eight\n 15-0 Data (max 32 halfwords)\n 15-4 Unknown/no effect? (should be zero)\n 3-1 Sound RAM Data Transfer Type (see below) (should be 2)\n 0 Unknown/no effect? (should be zero)\n __Transfer Type___Halfwords in Fifo________Halfwords written to SPU RAM__\n 0,1,6,7 Fill A,B,C,D,E,F,G,H,...,X X,X,X,X,X,X,X,X,...\n 2 Normal A,B,C,D,E,F,G,H,...,X A,B,C,D,E,F,G,H,...\n 3 Rep2 A,B,C,D,E,F,G,H,...,X A,A,C,C,E,E,G,G,...\n 4 Rep4 A,B,C,D,E,F,G,H,...,X A,A,A,A,E,E,E,E,...\n 5 Rep8 A,B,C,D,E,F,G,H,...,X H,H,H,H,H,H,H,H,...\nAs by now, there's no known method for reading SPU RAM without using DMA.
"},{"location":"soundprocessingunitspu/#spu-ram-dma-read-stable-reading-with-1f801014hbit24-27-nonzero","title":"SPU RAM DMA-Read (stable reading, with [1F801014h].bit24-27 = nonzero)","text":"Below describes some dirt effects and some trickery to get around those dirt effects.
Below problems (and workarounds) apply ONLY if [1F801014h].bit24-27 = zero.\n Ie. below info describes what happens when [1F801014h] is mis-initialized.\n Normally one should set [1F801014h]=220931E1h (and can ignore below info).\n 1st block: FFFFh, halfwords[00h..1Eh]\n 2nd block: FFFFh, halfwords[20h..3Eh]\n etc.\n 1st block: FFFFh, halfwords[00h..1Eh], twice halfword[1Fh]\n 2nd block: FFFFh, halfwords[20h..3Eh], twice halfword[3Fh]\n etc.\n 1st block: FFFFh, halfwords[00h,00h,..0Eh,0Eh], triple halfword[0Fh]\n 2nd block: FFFFh, halfwords[10h,10h,..1Eh,1Eh], triple halfword[1Fh]\n etc.\n 15-0 Address in sound buffer divided by eight\nTriggers an IRQ when a voice reads ADPCM data from the IRQ address. Mind that ADPCM cannot be stopped (uh, except, probably they CAN be stopped, by setting the sample rate to zero?), all voices are permanently reading data from SPU RAM - even in Noise mode, even if the Voice Volume is zero, and even if the ADSR pattern has finished the Release period - so even inaudible voices can trigger IRQs. To prevent unwanted IRQs, best set all unused voices to an endless looped dummy ADPCM block. For stable IRQs, the IRQ address should be aligned to the 16-byte ADPCM blocks. If if the IRQ address is in the middle of a 16-byte ADPCM block, then the IRQ doesn't seem to trigger always (unknown why, but it seems to occassionally miss IRQs, even if the block gets repeated several times).
"},{"location":"soundprocessingunitspu/#capture-interrupt","title":"Capture Interrupt","text":"Setting the IRQ address to 0000h..01FFh (aka byte address 00000h..00FFFh) will trigger IRQs on writes to the four capture buffers. Each of the four buffers contains 400h bytes (=200h samples), so the IRQ rate will be around 86.13Hz (44100Hz/200h). CD-Audio capture is always active (even CD-Audio output is disabld in SPUCNT, and even if the drive door is open). Voice capture is (probably) also always active (even if the corresponding voice is off). Capture IRQs do NOT occur if 1F801DACh.bit3-2 are both zero.
"},{"location":"soundprocessingunitspu/#reverb-interrupt","title":"Reverb Interrupt","text":"Reverb is also triggering interrupts if the IRQ address is located in the reverb buffer area. Unknown \\<which> of the various reverb read(s) and/or reverb write(s) are triggering interrupts.
"},{"location":"soundprocessingunitspu/#data-transfers","title":"Data Transfers","text":"Data Transfers (usually via DMA4) to/from SPU-RAM do also trap SPU interrupts.
"},{"location":"soundprocessingunitspu/#note_1","title":"Note","text":"The IRQ Address is used in the following games (not exhaustive): Metal Gear Solid: Dialogue and Konami intro. Legend of Mana Hercules: the memory card loading screen's lip sync. Tokimeki Memorial 2 Crash Team Racing: Lip sync, requires capture buffers. The Misadventures of Tron Bonne: Dialogues. Need For Speed 3: (somewhat?).
"},{"location":"soundprocessingunitspu/#spu-reverb-registers","title":"SPU Reverb Registers","text":""},{"location":"soundprocessingunitspu/#reverb-volume-and-address-registers-rw","title":"Reverb Volume and Address Registers (R/W)","text":" Port Reg Name Type Expl.\n 1F801D84h spu vLOUT volume Reverb Output Volume Left\n 1F801D86h spu vROUT volume Reverb Output Volume Right\n 1F801DA2h spu mBASE base Reverb Work Area Start Address in Sound RAM\n 1F801DC0h rev00 dAPF1 disp Reverb APF Offset 1\n 1F801DC2h rev01 dAPF2 disp Reverb APF Offset 2\n 1F801DC4h rev02 vIIR volume Reverb Reflection Volume 1\n 1F801DC6h rev03 vCOMB1 volume Reverb Comb Volume 1\n 1F801DC8h rev04 vCOMB2 volume Reverb Comb Volume 2\n 1F801DCAh rev05 vCOMB3 volume Reverb Comb Volume 3\n 1F801DCCh rev06 vCOMB4 volume Reverb Comb Volume 4\n 1F801DCEh rev07 vWALL volume Reverb Reflection Volume 2\n 1F801DD0h rev08 vAPF1 volume Reverb APF Volume 1\n 1F801DD2h rev09 vAPF2 volume Reverb APF Volume 2\n 1F801DD4h rev0A mLSAME src/dst Reverb Same Side Reflection Address 1 Left\n 1F801DD6h rev0B mRSAME src/dst Reverb Same Side Reflection Address 1 Right\n 1F801DD8h rev0C mLCOMB1 src Reverb Comb Address 1 Left\n 1F801DDAh rev0D mRCOMB1 src Reverb Comb Address 1 Right\n 1F801DDCh rev0E mLCOMB2 src Reverb Comb Address 2 Left\n 1F801DDEh rev0F mRCOMB2 src Reverb Comb Address 2 Right\n 1F801DE0h rev10 dLSAME src Reverb Same Side Reflection Address 2 Left\n 1F801DE2h rev11 dRSAME src Reverb Same Side Reflection Address 2 Right\n 1F801DE4h rev12 mLDIFF src/dst Reverb Different Side Reflect Address 1 Left\n 1F801DE6h rev13 mRDIFF src/dst Reverb Different Side Reflect Address 1 Right\n 1F801DE8h rev14 mLCOMB3 src Reverb Comb Address 3 Left\n 1F801DEAh rev15 mRCOMB3 src Reverb Comb Address 3 Right\n 1F801DECh rev16 mLCOMB4 src Reverb Comb Address 4 Left\n 1F801DEEh rev17 mRCOMB4 src Reverb Comb Address 4 Right\n 1F801DF0h rev18 dLDIFF src Reverb Different Side Reflect Address 2 Left\n 1F801DF2h rev19 dRDIFF src Reverb Different Side Reflect Address 2 Right\n 1F801DF4h rev1A mLAPF1 src/dst Reverb APF Address 1 Left\n 1F801DF6h rev1B mRAPF1 src/dst Reverb APF Address 1 Right\n 1F801DF8h rev1C mLAPF2 src/dst Reverb APF Address 2 Left\n 1F801DFAh rev1D mRAPF2 src/dst Reverb APF Address 2 Right\n 1F801DFCh rev1E vLIN volume Reverb Input Volume Left\n 1F801DFEh rev1F vRIN volume Reverb Input Volume Right\n 0-23 Voice 0..23 Destination (0=To Mixer, 1=To Mixer and to Reverb)\n 24-31 Not used\nThe SPUCNT register contains a Reverb Master Enable flag, and Reverb Enable flags for External Audio input and CD Audio input. When the Reverb Master Enable flag is cleared, the SPU stops to write any data to the Reverb buffer (that is useful when zero-filling the reverb buffer; ensuring that already-zero values aren't overwritten by still-nonzero values). However, the Reverb Master Enable flag does not disable output from Reverb buffer to the speakers (that might be useful to output uncompressed 22050Hz samples) (otherwise, to disable the buffer output, set the Reverb Output volume to zero and/or zerofill the reverb buffer).
"},{"location":"soundprocessingunitspu/#spu-reverb-formula","title":"SPU Reverb Formula","text":""},{"location":"soundprocessingunitspu/#reverb-formula","title":"Reverb Formula","text":" ___Input from Mixer (Input volume multiplied with incoming data)_____________\n Lin = vLIN * LeftInput ;from any channels that have Reverb enabled\n Rin = vRIN * RightInput ;from any channels that have Reverb enabled\n ____Same Side Reflection (left-to-left and right-to-right)___________________\n [mLSAME] = (Lin + [dLSAME]*vWALL - [mLSAME-2])*vIIR + [mLSAME-2] ;L-to-L\n [mRSAME] = (Rin + [dRSAME]*vWALL - [mRSAME-2])*vIIR + [mRSAME-2] ;R-to-R\n ___Different Side Reflection (left-to-right and right-to-left)_______________\n [mLDIFF] = (Lin + [dRDIFF]*vWALL - [mLDIFF-2])*vIIR + [mLDIFF-2] ;R-to-L\n [mRDIFF] = (Rin + [dLDIFF]*vWALL - [mRDIFF-2])*vIIR + [mRDIFF-2] ;L-to-R\n ___Early Echo (Comb Filter, with input from buffer)__________________________\n Lout=vCOMB1*[mLCOMB1]+vCOMB2*[mLCOMB2]+vCOMB3*[mLCOMB3]+vCOMB4*[mLCOMB4]\n Rout=vCOMB1*[mRCOMB1]+vCOMB2*[mRCOMB2]+vCOMB3*[mRCOMB3]+vCOMB4*[mRCOMB4]\n ___Late Reverb APF1 (All Pass Filter 1, with input from COMB)________________\n Lout=Lout-vAPF1*[mLAPF1-dAPF1], [mLAPF1]=Lout, Lout=Lout*vAPF1+[mLAPF1-dAPF1]\n Rout=Rout-vAPF1*[mRAPF1-dAPF1], [mRAPF1]=Rout, Rout=Rout*vAPF1+[mRAPF1-dAPF1]\n ___Late Reverb APF2 (All Pass Filter 2, with input from APF1)________________\n Lout=Lout-vAPF2*[mLAPF2-dAPF2], [mLAPF2]=Lout, Lout=Lout*vAPF2+[mLAPF2-dAPF2]\n Rout=Rout-vAPF2*[mRAPF2-dAPF2], [mRAPF2]=Rout, Rout=Rout*vAPF2+[mRAPF2-dAPF2]\n ___Output to Mixer (Output volume multiplied with input from APF2)___________\n LeftOutput = Lout*vLOUT\n RightOutput = Rout*vROUT\n ___Finally, before repeating the above steps_________________________________\n BufferAddress = MAX(mBASE, (BufferAddress+2) AND 7FFFEh)\n Wait one 22050Hz cycle, then repeat the above stuff\nThe values written to memory are saturated to -8000h..+7FFFh. The multiplication results are divided by +8000h, to fit them to 16bit range. All memory addresses are relative to the current BufferAddress, and wrapped within mBASE..7FFFEh when exceeding that region. All data in the Reverb buffer consists of signed 16bit samples. The Left and Right Reverb Buffer addresses should be choosen so that one half of the buffer contains Left samples, and the other half Right samples (ie. the data is L,L,L,L,... R,R,R,R,...; it is NOT interlaced like L,R,L,R,...), during operation, when the buffer address increases, the Left half will overwrite the older samples of the Right half, and vice-versa. The reverb hardware spends one 44100h cycle on left calculations, and the next 44100h cycle on right calculations (unlike as shown in the above formula, where left/right are shown simultaneously at 22050Hz).
"},{"location":"soundprocessingunitspu/#reverb-disable","title":"Reverb Disable","text":"SPUCNT.bit7 disables writes to reverb buffer, but reads from reverb buffer do still occur. If vAPF2 is zero then it does simply read \"Lout=[mLAPF2-dAPF2]\" and \"Rout=[mRAPF2-dAPF2]\". If vAPF2 is nonzero then it does additionally use data from APF1, if vAPF1 and vAPF2 are both nonzero then it's also using data from COMB. However, the SAME/DIFF stages aren't used when reverb is disabled.
"},{"location":"soundprocessingunitspu/#bug","title":"Bug","text":"vIIR works only in range -7FFFh..+7FFFh. When set to -8000h, the multiplication by -8000h is still done correctly, but, the final result (the value written to memory) gets negated (this is a pretty strange feature, it is NOT a simple overflow bug, it does affect the \"+[mLSAME-2]\" addition; although that part normally shouldn't be affected by the \"*vIIR\" multiplication). Similar effects might (?) occur on some other volume registers when they are set to -8000h.
"},{"location":"soundprocessingunitspu/#speed-of-sound","title":"Speed of Sound","text":"The speed of sound is circa 340 meters per second (in dry air, at room temperature). For example, a voice that travels to a wall at 17 meters distance, and back to its origin, should have a delay of 0.1 seconds.
"},{"location":"soundprocessingunitspu/#reverb-buffer-resampling","title":"Reverb Buffer Resampling","text":"Input and output to/from the reverb unit is resampled using a 39-tap FIR filter with the following coefficients.
-0001h, 0000h, 0002h, 0000h, -000Ah, 0000h, 0023h, 0000h,\n -0067h, 0000h, 010Ah, 0000h, -0268h, 0000h, 0534h, 0000h,\n -0B90h, 0000h, 2806h, 4000h, 2806h, 0000h, -0B90h, 0000h,\n 0534h, 0000h, -0268h, 0000h, 010Ah, 0000h, -0067h, 0000h,\n 0023h, 0000h, -000Ah, 0000h, 0002h, 0000h, -0001h,\nBelow are some Reverb examples, showing the required memory size (ie. set Port 1F801DA2h to \"(80000h-size)/8\"), and the Reverb register settings for Port 1F801DC0h..1F801DFFh, ie. arranged like so:
dAPF1 dAPF2 vIIR vCOMB1 vCOMB2 vCOMB3 vCOMB4 vWALL ;1F801DC0h..CEh\n vAPF1 vAPF2 mLSAME mRSAME mLCOMB1 mRCOMB1 mLCOMB2 mRCOMB2 ;1F801DD0h..DEh\n dLSAME dRSAME mLDIFF mRDIFF mLCOMB3 mRCOMB3 mLCOMB4 mRCOMB4 ;1F801DE0h..EEh\n dLDIFF dRDIFF mLAPF1 mRAPF1 mLAPF2 mRAPF2 vLIN vRIN ;1F801DF0h..FEh\n 007Dh,005Bh,6D80h,54B8h,BED0h,0000h,0000h,BA80h\n 5800h,5300h,04D6h,0333h,03F0h,0227h,0374h,01EFh\n 0334h,01B5h,0000h,0000h,0000h,0000h,0000h,0000h\n 0000h,0000h,01B4h,0136h,00B8h,005Ch,8000h,8000h\n 0033h,0025h,70F0h,4FA8h,BCE0h,4410h,C0F0h,9C00h\n 5280h,4EC0h,03E4h,031Bh,03A4h,02AFh,0372h,0266h\n 031Ch,025Dh,025Ch,018Eh,022Fh,0135h,01D2h,00B7h\n 018Fh,00B5h,00B4h,0080h,004Ch,0026h,8000h,8000h\n 00B1h,007Fh,70F0h,4FA8h,BCE0h,4510h,BEF0h,B4C0h\n 5280h,4EC0h,0904h,076Bh,0824h,065Fh,07A2h,0616h\n 076Ch,05EDh,05ECh,042Eh,050Fh,0305h,0462h,02B7h\n 042Fh,0265h,0264h,01B2h,0100h,0080h,8000h,8000h\n 00E3h,00A9h,6F60h,4FA8h,BCE0h,4510h,BEF0h,A680h\n 5680h,52C0h,0DFBh,0B58h,0D09h,0A3Ch,0BD9h,0973h\n 0B59h,08DAh,08D9h,05E9h,07ECh,04B0h,06EFh,03D2h\n 05EAh,031Dh,031Ch,0238h,0154h,00AAh,8000h,8000h\n 01A5h,0139h,6000h,5000h,4C00h,B800h,BC00h,C000h\n 6000h,5C00h,15BAh,11BBh,14C2h,10BDh,11BCh,0DC1h\n 11C0h,0DC3h,0DC0h,09C1h,0BC4h,07C1h,0A00h,06CDh\n 09C2h,05C1h,05C0h,041Ah,0274h,013Ah,8000h,8000h\n 0017h,0013h,70F0h,4FA8h,BCE0h,4510h,BEF0h,8500h\n 5F80h,54C0h,0371h,02AFh,02E5h,01DFh,02B0h,01D7h\n 0358h,026Ah,01D6h,011Eh,012Dh,00B1h,011Fh,0059h\n 01A0h,00E3h,0058h,0040h,0028h,0014h,8000h,8000h\n 033Dh,0231h,7E00h,5000h,B400h,B000h,4C00h,B000h\n 6000h,5400h,1ED6h,1A31h,1D14h,183Bh,1BC2h,16B2h\n 1A32h,15EFh,15EEh,1055h,1334h,0F2Dh,11F6h,0C5Dh\n 1056h,0AE1h,0AE0h,07A2h,0464h,0232h,8000h,8000h\n 0001h,0001h,7FFFh,7FFFh,0000h,0000h,0000h,8100h\n 0000h,0000h,1FFFh,0FFFh,1005h,0005h,0000h,0000h\n 1005h,0005h,0000h,0000h,0000h,0000h,0000h,0000h\n 0000h,0000h,1004h,1002h,0004h,0002h,8000h,8000h\n 0001h,0001h,7FFFh,7FFFh,0000h,0000h,0000h,0000h\n 0000h,0000h,1FFFh,0FFFh,1005h,0005h,0000h,0000h\n 1005h,0005h,0000h,0000h,0000h,0000h,0000h,0000h\n 0000h,0000h,1004h,1002h,0004h,0002h,8000h,8000h\n 0000h,0000h,0000h,0000h,0000h,0000h,0000h,0000h\n 0000h,0000h,0001h,0001h,0001h,0001h,0001h,0001h\n 0000h,0000h,0001h,0001h,0001h,0001h,0001h,0001h\n 0000h,0000h,0001h,0001h,0001h,0001h,0000h,0000h\n 0-15 Unknown?\n 80 21 4B DF\n .. 31 .. ..\n 7E 61 A9 96 47 39 F9 1E E1 E1 80 DD E8 17 7F FB\n FB BF 1D 6C 8F EC F3 04 06 23 89 45 C1 6D 31 82\n .. .. .. .. .. .. .. .. .. .. .. .. .. .. 7B ..\n .. .. .. .. .. .. .. .. 04 .. .. .. .. .. .. 86\nThe bytes at 1F801DBCh and 1F801E60h usually have the above values on cold-boot. The registers are read/write-able, although writing any values to them doesn't seem to have any effect on sound output. Also, the SPU doesn't seem to modify the registers at any time during sound output, nor reverb calculations, nor activated external audio input... the registers seem to be just some kind of general-purpose RAM.
"},{"location":"soundprocessingunitspu/#spu-internal-state-machine-from-spu-ram-timing","title":"SPU Internal State Machine from SPU RAM Timing","text":""},{"location":"soundprocessingunitspu/#introduction","title":"Introduction","text":"The 33.8 Mhz clock of the PSX is a well chosen value. It is exactly 768 x 44.1 Khz = For each audio sample in CD quality, there are 768 cycles of system clock. So, the state machine has to repeat its complete cycle every 768 system clock cycles.
Now the full job to do within those 768 cycles: - 24 channels to process. - Reverb to compute and write back. - Write back to voice 1 / 3, audio CD L/R. - Do transfer from/to CPU bus of SPU RAM data if asked.
"},{"location":"soundprocessingunitspu/#first-look-at-the-data-from-logic-analyzer","title":"First look at the data from logic analyzer.","text":"By looking at the signal of the SPU RAM chip, it is possible to figure out what it is reading and writing. - A read or a write to the SPU Ram is happening in 8 clock cycles. (Did not check in detail, but probably allow refresh and everything) - Each channel is using 24 cycles. (3 operations of 8 cycles) - Has TWO read for the current ADPCM block : one to the header of the currently played ADPCM block, one to the current 16 bit of the ADPCM. - A unrelated READ (see later) - 8 Cycle for each operation : WRITE CD Left, WRITE CD Right, Voice 1 WRITE, Voice 3 WRITE. - Reverb operations : 14 memory operations of 8 cycles.
"},{"location":"soundprocessingunitspu/#sequence-of-work","title":"Sequence of work","text":"When doing the analysis from data, it is possible to figure out what are the operations, in what order they are done. But it is not possible to figure out what is the FIRST operation in the loop. So we arbitrarely decide to start the loop at 'Voice 1' (voice being from 1 to 24).
As written earlier, each Voice is 3x RAM access (one unrelated), reverb is 14x RAM access, then 4x RAM access for the all write.
"},{"location":"soundprocessingunitspu/#what-we-can-guess-from-those-information","title":"What we can guess from those information.","text":" [Left Side] [Right Side]\nREAD REVERB dLSame dRSame\nREAD REVERB mLSame-1 mRSame-1\nREAD REVERB dRDiff dLDiff\nXXXX REVERB mLSame mRSame <-- WRITE becomes READ if REVERB DISABLED.\nREAD REVERB mLDiff-1 mRDiff-1\nREAD REVERB mLComb1 mRComb1\nXXXX REVERB mLDiff mRDiff <-- WRITE becomes READ if REVERB DISABLED.\nREAD REVERB mLComb2 mRComb2\nREAD REVERB mLComb3 mRComb3\nREAD REVERB mLComb4 mRComb4\nREAD REVERB mLAPF1 - dAPF1 mRAPF1 - dAPF1\nREAD REVERB mLAPF2 - dAPF2 mRAPF2 - dAPF2\nXXXX REVERB mLAPF1 mRAPF1 <-- WRITE becomes READ if REVERB DISABLED.\nXXXX REVERB mLAPF2 mRAPF2 <-- WRITE becomes READ if REVERB DISABLED.\nRead Header word in current ADPCM block.\nRead Current Sample 16 bit word in current ADPCM block.\nRead [UNRELATED ADR ? Not related to current block...]\nEverything is not fully clear yet, testing of SPU with proper tests to validate/invalidate various assumption. Our finding are based on a logic analyzer log using the PSX boot sounds, knowing the values of the registers thanks to emulators.
"},{"location":"timers/","title":"Timers","text":""},{"location":"timers/#1f801100hn10h-timer-02-current-counter-value-rw","title":"1F801100h+N*10h - Timer 0..2 Current Counter Value (R/W)","text":" 0-15 Current Counter value (incrementing)\n 16-31 Garbage\n 0 Synchronization Enable (0=Free Run, 1=Synchronize via Bit1-2)\n 1-2 Synchronization Mode (0-3, see lists below)\n Synchronization Modes for Counter 0:\n 0 = Pause counter during Hblank(s)\n 1 = Reset counter to 0000h at Hblank(s)\n 2 = Reset counter to 0000h at Hblank(s) and pause outside of Hblank\n 3 = Pause until Hblank occurs once, then switch to Free Run\n Synchronization Modes for Counter 1:\n Same as above, but using Vblank instead of Hblank\n Synchronization Modes for Counter 2:\n 0 or 3 = Stop counter at current value (forever, no h/v-blank start)\n 1 or 2 = Free Run (same as when Synchronization Disabled)\n 3 Reset counter to 0000h (0=After Counter=FFFFh, 1=After Counter=Target)\n 4 IRQ when Counter=Target (0=Disable, 1=Enable)\n 5 IRQ when Counter=FFFFh (0=Disable, 1=Enable)\n 6 IRQ Once/Repeat Mode (0=One-shot, 1=Repeatedly)\n 7 IRQ Pulse/Toggle Mode (0=Short Bit10=0 Pulse, 1=Toggle Bit10 on/off)\n 8-9 Clock Source (0-3, see list below)\n Counter 0: 0 or 2 = System Clock, 1 or 3 = Dotclock\n Counter 1: 0 or 2 = System Clock, 1 or 3 = Hblank\n Counter 2: 0 or 1 = System Clock, 2 or 3 = System Clock/8\n 10 Interrupt Request (0=Yes, 1=No) (Set after Writing) (W=1) (R)\n 11 Reached Target Value (0=No, 1=Yes) (Reset after Reading) (R)\n 12 Reached FFFFh Value (0=No, 1=Yes) (Reset after Reading) (R)\n 13-15 Unknown (seems to be always zero)\n 16-31 Garbage (next opcode)\n 0-15 Counter Target value\n 16-31 Garbage\nFor more info on dotclock and hblank timings, see: GPU Timings Caution: Reading the Current Counter Value can be a little unstable (when using dotclk or hblank as clock source); the GPU clock isn't in sync with the CPU clock, so the timer may get changed during the CPU read cycle. As a workaround: repeat reading the timer until the received value is the same (or slightly bigger) than the previous value.
"},{"location":"timers/#reset-and-wrap","title":"Reset and Wrap","text":"When resetting the Counter by writing the Mode register, it will stay at 0000h for 2 clock cycles before counting up. When writing the Current value, it will stay at the written value for 2 clock cycles before counting up or checking against Target overflows. When wrapping around at FFFFh(Mode Bit3 not set), it will stay at 0000h for only 1 clock cycle. When being reset to 0000h by reaching the Target value(Mode Bit3 set), it will stay at 0000h for 2 clock cycles. Example behavior with Target Value of 0001h and Mode Bit3 set:
clock cycle 0 - Counter Value = 0000h\nclock cycle 1 - Counter Value = 0000h\nclock cycle 2 - Counter Value = 0001h\nclock cycle 3 - Counter Value = 0000h\nclock cycle 4 - Counter Value = 0000h\nclock cycle 5 - Counter Value = 0001h\nNormally, I/O ports should be accessed only at their corresponding size (ie. 16bit read/write for 16bit ports), and of course, only existing memory and I/O addresses should be used. When not recursing that rules, some more or less (un-)predictable things may happen...
"},{"location":"unpredictablethings/#io-write-datasize","title":"I/O Write Datasize","text":" Address Content W.8bit W.16bit W.32bit\n 00000000h-00xFFFFFh Main RAM OK OK OK\n 1F800000h-1F8003FFh Scratchpad OK OK OK\n 1F801000h-1F801023h MEMCTRL (w32) (w32) OK\n 1F80104xh JOY_xxx (w16) OK CROP\n 1F80105xh SIO_xxx (w16) OK CROP\n 1F801060h-1F801063h RAM_SIZE (w32) (w32) OK (with crash)\n 1F801070h-1F801077h IRQCTRL (w32) (w32) OK\n 1F8010x0h-1F8010x3h DMAx.ADDR (w32) (w32) OK\n 1F8010x4h-1F8010x7h DMAx.LEN OK OK OK\n 1F8010x8h-1F8010xFh DMAx.CTRL/MIRR (w32) (w32) OK\n 1F8010F0h-1F8010F7h DMA.DPCR/DICR (w32) (w32) OK\n 1F8010F8h-1F8010FFh DMA.unknown IGNORE IGNORE IGNORE\n 1F801100h-1F80110Bh Timer 0 (w32) (w32) OK\n 1F801110h-1F80111Bh Timer 1 (w32) (w32) OK\n 1F801120h-1F80112Bh Timer 2 (w32) (w32) OK\n 1F801800h-1F801803h CDROM OK ? ?\n 1F801810h-1F801813h GPU.GP0 ? ? OK\n 1F801814h-1F801817h GPU.GP1 ? ? OK\n 1F801820h-1F801823h MDEC.CMD/DTA ? ? OK\n 1F801824h-1F801827h MDEC.CTRL ? ? OK\n 1F801C00h-1F801E7Fh SPU (i16) OK OK\n 1F801E80h-1F801FFFh SPU.UNUSED IGNORE IGNORE IGNORE\n 1F802020h-1F80202Fh DUART OK ? ?\n 1F802041h POST OK ? ?\n FFFE0130h-FFFE0133h CACHE.CTRL (i32) (i32) OK\n OK works\n (w32) write full 32bits (left-shifted if address isn't word-aligned)\n (w16) write full 16bits (left-shifted if address isn't halfword-aligned)\n (i32) write full 32bits (ignored if address isn't word-aligned)\n (i16) write full 16bits (ignored if address isn't halfword-aligned)\n CROP write only lower 16bit (and leave upper 16bit unchanged)\nIn most cases, I/O ports can be read in 8bit, 16bit, or 32bit units, regardless of their size, among others allowing to read two 16bit ports at once with a single 32bit read. If there's only one 16bit port within a 32bit region, then 32bit reads often return garbage in the unused 16bits. Also, 8bit or 16bit VRAM data reads via GPUREAD probably won't work? Expansion 2 Region can be accessed only via 8bit reads, and 16bit/32bit reads seem to cause exceptions (or rather: no such exception!) (except, probably 16bit reads are allowed when the region is configured to 16bit databus width). There are at least some special cases:
FFFE0130h-FFFE0133h 8bit (+16bit?) read works ONLY from word-aligned address\nPerforming a 8-bit or 16-bit write (sb/sh) will place the entirety of the GPR on the bus, regardless of the write size. Therefore, the data is not masked. This has an effect when performing a narrower write to a wider address, for example the DMA controller, but not others such as the CD-ROM controller.
Emulators should therefore treat all access widths as having 32 bits of data, but depending on the device perform masking/splitting (see Memory Control).
The CD audio visualizer (aka Soundscope) in the SCPH-7xxx series of consoles is an example of where this behavior is required, as it issues halfword writes to the DMA controller addresses.
"},{"location":"unpredictablethings/#cache-problems","title":"Cache Problems","text":"The functionality of the Cache is still widely unknown. Not sure if DMA transfers are updating or invalidating cache. Cached Data within KSEG0 should be automatically also cached at the corresponding mirrored address in KUSEG and vice versa. Mirrors within KSEG1 (or within KUSEG) may be a different thing, eg. when using addresses spead across the first 8MB region to access the 2MB RAM. Same problems may occor for Expansion and BIOS mirrors, although, not sure if that regions are cached.
"},{"location":"unpredictablethings/#writebuffer-problems","title":"Writebuffer Problems","text":"The writebuffer seems to be disabled for the normal I/O area at 1F801000h, however, it appears to be enabled for the Expansion I/O region at 1F802000h (after writing to 1F802041h, the BIOS issues 4 dummy writes to RAM, apparently (?) in order to flush the writebuffer). The same might apply for Expansion Memory region at 1F000000h, although usually that region would contain ROM, so it'd be don't care whether it is write-buffered or not.
"},{"location":"unpredictablethings/#cpu-loadstore-problems","title":"CPU Load/Store Problems","text":"XXcpuREG ---> applies ONLY to LOAD (not to store) Memory read/write opcodes take a 1-cycle delay until the data arrives at the destination, ie. the next opcode should not use the destination register (or more unlikely, the destination memory location) as source operand. Usually, when trying to do so, the second opcode would receive the OLD value - however, if an exception occurs between the two opcodes, then the read/write operation may finish, and the second opcode would probably receive the NEW value.
"},{"location":"unpredictablethings/#cpu-register-problems-r1-at-r26-k0-r29-sp","title":"CPU Register Problems - R1 (AT), R26 (K0), R29 (SP)","text":"Exception handlers cannot preserve all registers, before returning, they must load the return address into a general purpose register (conventionally R26 aka K0), so be careful not to use that register, unless you are 100% sure that no interrupts and no other exceptions can occur. Some exception handlers might also destroy R27 aka K1 (though execption handler in the PSX Kernel leaves that register unchanged). Some assemblers (not a22i in nocash syntax mode) are internally using R1 aka AT as scratch register for some pseudo opcodes, including for a \"sw rx,imm32\" pseudo opcode (which is nearly impossible to separate from the normal \"sw rx,imm16\" opcode), be careful not to use R1, unless you can trust your assembler not to destroy that register behind your back. The PSX Kernel uses \"Full-Decrementing-Wasted-Stack\", where \"Wasted\" means that when calling a sub-function with N parameters, then the caller must pre-allocate N works on stack, and the sub-function may freely use and destroy these words; at [SP+0..N*4-1].
"},{"location":"unpredictablethings/#locked-locations-in-memory-and-io-area","title":"Locked Locations in Memory and I/O Area","text":" 00800000h ;-when Main RAM configured to end at 7FFFFFh\n 1F080000h 780000h ;-when Expansion 1 configured to end at 7FFFFh\n 1F800400h C00h ;-region after Scratchpad\n 1F801024h 1Ch ;\\\n 1F801064h 0Ch ;\n 1F801078h 08h ;\n 1F801140h 6C0h ; gaps in I/O region\n 1F801804h 0Ch ;\n 1F801818h 08h ;\n 1F801828h 3D8h ;/\n 1F802080h 3FDF80h ;-when Expansion 2 configured to end at 7Fh\n 1FC80000h 60380000h ;-when BIOS ROM configured to end at 7FFFFh\n C0000000h 1FFE0000h ;\\\n FFFE0020h E0h ; gaps in KSEG2 (cache control region)\n FFFE0140h 1FEC0h ;/\n 1F80108Ch+N*10h - D#_CHCR Mirrors - (N=0..6, for DMA channel 0..6)\n 1F801062h (2 bytes) ;\\\n 1F801072h (2 bytes) ; unused addresses in Memory and Interrupt Control area\n 1F801076h (2 bytes) ;/\n 1F801102h (2 bytes) ;\\\n 1F801106h (2 bytes) ; unused addresses in Timer 0 area\n 1F80110Ah (6 bytes) ;/\n 1F801112h (2 bytes) ;\\\n 1F801116h (2 bytes) ; unused addresses in Timer 1 area\n 1F80111Ah (6 bytes) ;/\n 1F801122h (2 bytes) ;\\\n 1F801126h (2 bytes) ; unused addresses in Timer 2 area and next some bytes\n 1F80112Ah (22 bytes) ;/\n 1F801820h (4 bytes) ;-read MDEC Data-Out port (if there is no data)\n FFFE0000h (32 bytes) ;\\\n FFFE0100h (48 bytes) ; unused addresses in Cache control area\n FFFE0132h (2 bytes) ; (including write-only upper 16bit of Port FFFE0130h)\n FFFE0134h (12 bytes) ;/\nIn gaming and programming scene, \"PSX\" is most commonly used as abbreviation for the original Playstation series (occasionally including PSone). Sony has never officially used that abbreviation, however, the Playstation BIOS contains the ASCII strings \"PSX\" and \"PS-X\" here and there. The letters \"PS\" are widely believed to stand for PlayStation, and the meaning of the \"X\" is totally unknown (although, actually it may stand for POSIX.1, see below).
"},{"location":"unpredictablethings/#psx-as-abbreviation-for-posix1","title":"PSX as Abbreviation for POSIX.1","text":"According to JMI Software Systems, \"PSX\" is a trademark of themselves, and stands for \"single-user, single-group, subset of POSIX.1\" (POSIX stands for something commonly used by HLL programmers under UNIX or so). That \"PSX\" kernel from JMI is available for various processors, including MIPS processors, and like the playstation, it does include functions like \"atoi\", and does support TTY access via Signetics 2681 DUART chips. The DTL-H2000 does also have POSIX-style \"PSX>\" prompt. So, altogether, it's quite possible that Sony has licensed the kernel from JMI.
"},{"location":"unpredictablethings/#psx-as-abbreviation-for-an-extended-playstation-2","title":"PSX as Abbreviation for an Extended Playstation 2","text":"As everybody agrees, PSX should be used only as abbreviation for Playstation 1, and nobody should never ever use it for the Playstation 2. Well, nobody, except Sony... despite of the common use as abbreviation for Playstation 1 (and despite of the JMI trademark)... in 2003, Sony has have released a \"Playstation 2 with built-in HDD/DVD Videorecorder\" and called that thing \"PSX\" for the best of confusion.
"}]} \ No newline at end of file diff --git a/serialinterfacessio/index.html b/serialinterfacessio/index.html new file mode 100644 index 0000000..9b34f5a --- /dev/null +++ b/serialinterfacessio/index.html @@ -0,0 +1,1196 @@ + + + + + + + + + + + + + + + + + + + + + + + +The console has two serial interfaces, SIO0 (connected to the controller and
+memory card ports) and SIO1 (connected to the serial port). SIO0 is hardwired to
+run in synchronous mode, while SIO1 can only operate in asynchronous mode. Both
+units are fairly similar, although not identical, and seem to be vaguely based
+on the Intel 8251A USART chip.
0-7 Data to be sent
+ 8-31 Not used
+ 0-7 Received Data (1st RX FIFO entry) (oldest entry)
+ 8-15 Preview (2nd RX FIFO entry)
+ 16-23 Preview (3rd RX FIFO entry)
+ 24-31 Preview (4th RX FIFO entry) (5th..8th cannot be previewed)
+ 0 TX FIFO Not Full (1=Ready for new byte) (depends on CTS) (TX requires CTS)
+ 1 RX FIFO Not Empty (0=Empty, 1=Data available)
+ 2 TX Idle (1=Idle/Finished) (depends on TXEN and on CTS)
+ 3 RX Parity Error (0=No, 1=Error; Wrong Parity, when enabled) (sticky)
+ 4 SIO1 RX FIFO Overrun (0=No, 1=Error; received more than 8 bytes) (sticky)
+ 5 SIO1 RX Bad Stop Bit (0=No, 1=Error; Bad Stop Bit) (when RXEN) (sticky)
+ 6 SIO1 RX Input Level (0=Normal, 1=Inverted) ;only AFTER receiving Stop Bit
+ 7 DSR Input Level (0=Off, 1=On) (remote DTR) ;DSR not required to be on
+ 8 SIO1 CTS Input Level (0=Off, 1=On) (remote RTS) ;CTS required for TX
+ 9 Interrupt Request (0=None, 1=IRQ) (See SIO_CTRL.Bit4,10-12) (sticky)
+ 10 Unknown (always zero)
+ 11-31 Baudrate Timer (15-21 bit timer, decrementing at 33MHz)
+ 0-1 Baudrate Reload Factor (1=MUL1, 2=MUL16, 3=MUL64) (or 0=MUL1 on SIO0, STOP on SIO1)
+ 2-3 Character Length (0=5 bits, 1=6 bits, 2=7 bits, 3=8 bits)
+ 4 Parity Enable (0=No, 1=Enable)
+ 5 Parity Type (0=Even, 1=Odd) (seems to be vice-versa...?)
+ 6-7 SIO1 stop bit length (0=Reserved/1bit, 1=1bit, 2=1.5bits, 3=2bits)
+ 8 SIO0 clock polarity (CPOL) (0=High when idle, 1=Low when idle)
+ 9-15 Not used (always zero)
+ 0 TX Enable (TXEN) (0=Disable, 1=Enable)
+ 1 DTR Output Level (0=Off, 1=On)
+ 2 RX Enable (RXEN) (SIO1: 0=Disable, 1=Enable) ;Disable also clears RXFIFO
+ (SIO0: 0=only receive when /CS low, 1=force receiving single byte)
+ 3 SIO1 TX Output Level (0=Normal, 1=Inverted, during Inactivity & Stop bits)
+ 4 Acknowledge (0=No change, 1=Reset SIO_STAT.Bits 3,4,5,9) (W)
+ 5 SIO1 RTS Output Level (0=Off, 1=On)
+ 6 Reset (0=No change, 1=Reset most registers to zero) (W)
+ 7 SIO1 unknown? (read/write-able when FACTOR non-zero) (otherwise always zero)
+ 8-9 RX Interrupt Mode (0..3 = IRQ when RX FIFO contains 1,2,4,8 bytes)
+ 10 TX Interrupt Enable (0=Disable, 1=Enable) ;when SIO_STAT.0-or-2 ;Ready
+ 11 RX Interrupt Enable (0=Disable, 1=Enable) ;when N bytes in RX FIFO
+ 12 DSR Interrupt Enable (0=Disable, 1=Enable) ;when SIO_STAT.7 ;DSR high or /ACK low
+ 13 SIO0 port select (0=port 1, 1=port 2) (/CS pulled low when bit 1 set)
+ 14-15 Not used (always zero)
+This is an internal register, which usually shouldn't be accessed by software.
+Messing with it has rather strange effects: After writing a value "X" to this
+register, reading returns "X ROR 8" eventually "ANDed with 1F1Fh and ORed with
+C0C0h or 8080h" (depending on the character length in SIO_MODE). SIO0 does not
+have this register.
0-15 Baudrate Reload value for decrementing Baudrate Timer
+ SIO0: BitsPerSecond = 33868800 / MIN(((Reload*Factor) AND NOT 1),1)
+ SIO1: BitsPerSecond = 33868800 / MIN(((Reload*Factor) AND NOT 1),Factor)
+ SIO0_BAUD is multiplied by Factor, and does then elapse "2" times per bit.
+ SIO1_BAUD is NOT multiplied, and, instead, elapses "2*Factor" times per bit.
+The hardware can hold (almost) 2 bytes in the TX direction (one being currently
+transferred, and, once when the start bit was sent, another byte can be stored
+in SIO_TX_DATA). When writing to SIO_TX_DATA, both SIO_STAT.0 and SIO_STAT.2
+become zero. As soon as the transfer starts, SIO_STAT.0 becomes set (indicating
+that one can write a new byte to SIO_TX_DATA; although the transmission is
+still busy). As soon as the transfer of the most recently written byte ends,
+SIO_STAT.2 becomes set.
The hardware can hold 8 bytes in the RX direction (when receiving further
+byte(s) while the RX FIFO is full, then the last FIFO entry will by overwritten
+by the new byte, and SIO_STAT.4 gets set; the hardware does NOT automatically
+disable RTS when the FIFO becomes full). The RX FIFO overrun flag is not
+accessible on SIO0.
+Data can be read from SIO_RX_DATA when SIO_STAT.1 is set, that flag gets
+automatically cleared after reading from SIO_RX_DATA (unless there are still
+further bytes in the RX FIFO). Note: The hardware does always store incoming
+data in RX FIFO (even when Parity or Stop bits are invalid).
+Note: A 16bit read allows to read two FIFO entries at once; nethertheless, it
+removes only ONE entry from the FIFO. On the contrary, a 32bit read DOES remove
+FOUR entries (although, there's nothing that'd indicate if the FIFO did
+actually contain four entries).
+Reading from Empty RX FIFO returns either the most recently received byte or
+zero (the hardware stores incoming data in ALL unused FIFO entries; eg. if five
+entries are used, then the data gets stored thrice, after reading 6 bytes, the
+FIFO empty flag gets set, but nethertheless, the last byte can be read two more
+times, but doing further reads returns 00h).
First reset I_STAT.8, then set SIO.CTRL.4 (when doing it vice-versa, the
+hardware may miss a new IRQ which may occur immediately after setting
+SIO.CTRL.4) (and I_STAT.8 is edge triggered, so that bit can be reset even
+while SIO_STAT.9 is still set).
+When acknowledging via SIO_CTRL.4 with the enabled condition(s) in
+SIO_CTRL.10-12 still being true (eg. the RX FIFO is still not empty): the IRQ
+does trigger again (almost) immediately (it goes off only for a very short
+moment; barely enough to allow I_STAT.8 to sense a edge).
For more details on how SIO0 is used to communicate with controllers and memory
+cards, see:
+Controller and Memory Card Overview
+For serial port pinouts, PSone SIO1 upgrading, and for building RS232 adaptors,
+see:
+Pinouts - SIO Pinouts
+Aside from the internal SIO port, the PSX BIOS supports two additional external
+serial ports, connected to the expansion port.
+EXP2 Dual Serial Port (for TTY Debug Terminal)
The serial ports on two consoles can be connected with an SCPH-1040 Link Cable +(known as Taisen Cable, or "Fight Cable" in Japan) for multiplayer functionality +on games that support this method. This was used by a small number of games in +the console's lifecycle, but inconveniently required a second console and copy +of the game.
+Two-Console Link Cable Games (Incomplete List): +
Andretti Racing
+Armored Core (and Armored Core "Link Versus Demo" disc)
+Armored Core Project Phantasma
+Armored Core Master of Arena
+Assault Rigs
+Ayrton Senna Kart Duel
+Blast Radius
+Bogey Dead 6
+Burning Road
+Bushido Blade
+Bushido Blade 2
+C1 -Circuit-
+CART World Series
+Command & Conquer Red Alert
+Command & Conquer Red Alert Retaliation
+Cool Boarders 2
+Dead in the Water
+Descent
+Descent Maximum
+Destruction Derby
+Duke Nukem Total Meltdown
+Dodgem Arena
+Doom
+Dune 2000
+Explosive Racing (X Racing in NTSC-J)
+Final Doom
+Formula 1
+Formula 1 98
+Grand Tour Racing '98 (Gekisou!! Grand Racing -Total Driving'- in NTSC-J, Total Drivin in PAL)
+Independence Day
+Krazy Ivan
+Leading Jockey Highbred
+Metal Jacket
+Mobile Suit Z-Gundam
+Monaco Grand Prix Racing Simulation 2 (Monaco Grand Prix in NTSC-U/C)
+Motor Toon Grand Prix (reportedly NTSC-U/C version only)
+Motor Toon Grand Prix 2
+Motor Toon Grand Prix USA Edition
+The Need for Speed (Over Drivin' DX in NTSC-J)
+PrePre Vol. 2
+Pro Pinball Big Race USA
+RacinGroovy
+Real Robots Final Attack
+Red Asphalt (Rock & Roll Racing 2 Red Asphalt in PAL)
+Ridge Racer Revolution
+R4 Ridge Racer Type 4
+Robo Pit
+Rogue Trip Vacation 2012
+San Francisco Rush Extreme Racing (reportedly PAL version only)
+Shutokou Battle R
+Sidewinder
+Sidewinder USA
+Soukou Kihei Votoms Gaiden: Ao no Kishi Berserga Monogatari
+Streak Hoverboard Racing
+Test Drive 4
+Test Drive Off-Road (reportedly NTSC-U/C only)
+TOCA 2 Touring Car Challenge (TOCA 2 Touring Cars in PAL)
+Trick'N Snowboarder (Tricky Sliders Freestyle Snowboard in NTSC-J)
+Twisted Metal III
+Wing Over
+Wipeout
+Wipeout 3 Special Edition
+Wipeout XL (Wipeout 2097 in PAL)
+Zero Pilot Ginyoku no Senshi
+The serial port is used (for 2-player link) by Wipeout 2097 (that game
+accidently assumes BAUDs based on 64*1024*1025 Hz rather than on 600h*44100
+Hz).
+Ridge Racer Revolution is also said to support 2P link.
+Keitai Eddy seems to allow to connect a mobile phone to the SIO port (the games
+CD cover suggests so; this seems to be something different than the "normal"
+I-Mode adaptor, which would connect to controller port, not to SIO port).
SPU Overview
+SPU ADPCM Samples
+SPU ADPCM Pitch
+SPU Volume and ADSR Generator
+SPU Voice Flags
+SPU Noise Generator
+SPU Control and Status Register
+SPU Memory Access
+SPU Interrupt
+SPU Reverb Registers
+SPU Reverb Formula
+SPU Reverb Examples
+SPU Unknown Registers
+SPU Internal State Machine from SPU RAM Timing
1F801C00h..1F801D7Fh - Voice 0..23 Registers (eight 16bit regs per voice)
+ 1F801D80h..1F801D87h - SPU Control (volume)
+ 1F801D88h..1F801D9Fh - Voice 0..23 Flags (six 1bit flags per voice)
+ 1F801DA2h..1F801DBFh - SPU Control (memory, control, etc.)
+ 1F801DC0h..1F801DFFh - Reverb configuration area
+ 1F801E00h..1F801E5Fh - Voice 0..23 Internal Registers
+ 1F801E60h..1F801E7Fh - Unknown?
+ 1F801E80h..1F801FFFh - Unused?
+ 00000h-003FFh CD Audio left (1Kbyte) ;\CD Audio before Volume processing
+ 00400h-007FFh CD Audio right (1Kbyte) ;/signed 16bit samples at 44.1kHz
+ 00800h-00BFFh Voice 1 mono (1Kbyte) ;\Voice 1 and 3 after ADSR processing
+ 00C00h-00FFFh Voice 3 mono (1Kbyte) ;/signed 16bit samples at 44.1kHz
+ 01000h-xxxxxh ADPCM Samples (first 16bytes usually contain a Sine wave)
+ xxxxxh-7FFFFh Reverb work area
+The SPU has 24 hardware voices. These voices can be used to reproduce sample
+data, noise or can be used as frequency modulator on the next voice. Each voice
+has it's own programmable ADSR envelope filter. The main volume can be
+programmed independently for left and right output.
All 24 voices are having exactly the same capabilities(?), with the exception
+that Voice 1 and 3 are having a special Capture feature (see SPU Memory map).
+There seems to be no way to produce square waves (without storing a square
+wavefrom in memory... although, since SPU RAM isn't connected to the CPU bus,
+the "useless" DMA for square wave data wouldn't slowdown the CPU bus)?
External Audio can be input (from the Expansion Port?), and the CDROM drive can
+be commanded to playback normal Audio CDs (via Play command), or XA-ADPCM
+sectors (via Read command), and to pass that data to the SPU.
The standard PSX Audio cables have separate Left/Right signals, that is good
+for stereo TVs, but, when using a normal mono TV, only one of the two audio
+signals (Left or Right) can be connected. PSX programs should thus offer an
+option to disable stereo effects, and to output an equal volume to both cables.
The SPU occasionally seems to "miss" 32bit I/O writes (not sure if that can be
+fixed by any Memory Control settings?), a stable workaround is to split each
+32bit write into two 16bit writes. The SPU seems to process written values at
+44100Hz rate (so it may take 1/44100 seconds (300h clock cycles) until it has
+actually realized the new value).
The SPU is connected to a 16bit databus. 8bit/16bit/32bit reads and 16bit
+writes are implemented; 32bit writes are also supported but seem to be
+particularly unstable (see above). However, 8bit writes are NOT implemented:
+8bit writes to ODD addresses are simply ignored (without causing any
+exceptions), 8bit writes to EVEN addresses are executed as 16bit writes (e.g.
+li v0, 12345678h; sb v0, spu\_port will write 5678h instead of 78h).
The SPU supports only ADPCM compressed samples (uncompressed samples seem to be
+totally unsupported; leaving apart that one can write uncompressed 16bit PCM
+samples to the Reverb Buffer, which can be then output at 22050Hz, as long as
+they aren't overwritten by the hardware).
This register holds the sample start address (not the current address, ie. the
+register doesn't increment during playback).
+
15-0 Startaddress of sound in Sound buffer (in 8-byte units)
+If the hardware finds an ADPCM header with Loop-Start-Bit, then it copies the
+current address to the repeat addresss register.
+If the hardware finds an ADPCM header with Loop-Stop-Bit, then it copies the
+repeat addresss register setting to the current address; that, \<after>
+playing the current ADPCM block.
+
15-0 Address sample loops to at end (in 8-byte units)
+Samples consist of one or more 16-byte blocks:
+
00h Shift/Filter (reportedly same as for CD-XA) (see there)
+ 01h Flag Bits (see below)
+ 02h Compressed Data (LSBs=1st Sample, MSBs=2nd Sample)
+ 03h Compressed Data (LSBs=3rd Sample, MSBs=4th Sample)
+ 04h Compressed Data (LSBs=5th Sample, MSBs=6th Sample)
+ ... ...
+ 0Fh Compressed Data (LSBs=27th Sample, MSBs=28th Sample)
+ 0 Loop End (0=No change, 1=Set ENDX flag and Jump to [1F801C0Eh+N*10h])
+ 1 Loop Repeat (0=Force Release and set ADSR Level to Zero; only if Bit0=1)
+ 2 Loop Start (0=No change, 1=Copy current address to [1F801C0Eh+N*10h])
+ 3-7 Unknown (usually 0)
+ Code 0 = Normal (continue at next 16-byte block)
+ Code 1 = End+Mute (jump to Loop-address, set ENDX flag, Release, Env=0000h)
+ Code 2 = Ignored (same as Code 0)
+ Code 3 = End+Repeat (jump to Loop-address, set ENDX flag)
+The Loop Start/End flags in the ADPCM Header allow to play one or more sample
+block(s) in a loop, that can be either all block(s) endless repeated, or only
+the last some block(s) of the sample.
+There's no way to stop the output, so a one-shot sample must be followed by
+dummy block (with Loop Start/End flags both set, and all data nibbles set to
+zero; so that the block gets endless repeated, but doesn't produce any sound).
The PSX supports two ADPCM formats: SPU-ADPCM (as described above), and
+XA-ADPCM. XA-ADPCM is decompressed by the CDROM Controller, and sent directly
+to the sound mixer, without needing to store the data in SPU RAM, nor needing
+to use a Voice channel.
+The actual decompression algorithm is the same for both formats. However, the
+XA nibbles are arranged in different order, and XA uses 2x28 nibbles per block
+(instead of 2x14), XA blocks can contain mono or stereo data, XA supports only
+two sample rates, and, XA doesn't support looping.
0-15 Sample rate (0=stop, 4000h=fastest, 4001h..FFFFh=usually same as 4000h)
+Pitch modulation allows to generate "Frequency Sweep" effects by mis-using the
+amplitude from channel (x-1) as pitch factor for channel (x).
+
0 Unknown... Unused?
+ 1-23 Flags for Voice 1..23 (0=Normal, 1=Modulate by Voice 0..22)
+ 24-31 Not used
+The pitch counter is adjusted at 44100Hz rate as follows:
+
Step = VxPitch ;range +0000h..+FFFFh (0...705.6 kHz)
+ IF PMON.Bit(x)=1 AND (x>0) ;pitch modulation enable
+ Factor = VxOUTX(x-1) ;range -8000h..+7FFFh (prev voice amplitude)
+ Factor = Factor+8000h ;range +0000h..+FFFFh (factor = 0.00 .. 1.99)
+ Step=SignExpand16to32(Step) ;hardware glitch on VxPitch>7FFFh, make sign
+ Step = (Step * Factor) SAR 15 ;range 0..1FFFFh (glitchy if VxPitch>7FFFh)
+ Step=Step AND 0000FFFFh ;hardware glitch on VxPitch>7FFFh, kill sign
+ IF Step>3FFFh then Step=4000h ;range +0000h..+3FFFh (0.. 176.4kHz)
+ Counter = Counter + Step
+The Mixer and DAC supports a 44.1kHz output rate (allowing to produce max
+22.1kHz tones). The Reverb unit supports only half the frequency.
+The pitch counter supports sample rates up to 176.4kHz. However, exceeding the
+44.1kHz limit causes the hardware to skip samples (or actually: to apply
+incomplete interpolation on the 'skipped' samples).
+VxPitch can be theoretically 0..FFFFh (max 705.6kHz), normally 4000h..FFFFh are
+simply clipped to max=4000h (176.4kHz). Except, 4000h..FFFFh could be used with
+pitch modulation (as they are multiplied by 0.00..1.99 before clipping; in
+practice this works only for 4000h..7FFFh; as values 8000h..FFFFh are mistaken
+as signed values).
Interpolation is applied on the 4 most recent 16bit ADPCM samples
+(new,old,older,oldest), using bit4-11 of the pitch counter as 8bit
+interpolation index (i=00h..FFh):
+
out = ((gauss[0FFh-i] * oldest) SAR 15)
+ out = out + ((gauss[1FFh-i] * older) SAR 15)
+ out = out + ((gauss[100h+i] * old) SAR 15)
+ out = out + ((gauss[000h+i] * new) SAR 15)
+ -001h,-001h,-001h,-001h,-001h,-001h,-001h,-001h ;\
+ -001h,-001h,-001h,-001h,-001h,-001h,-001h,-001h ;
+ 0000h,0000h,0000h,0000h,0000h,0000h,0000h,0001h ;
+ 0001h,0001h,0001h,0002h,0002h,0002h,0003h,0003h ;
+ 0003h,0004h,0004h,0005h,0005h,0006h,0007h,0007h ;
+ 0008h,0009h,0009h,000Ah,000Bh,000Ch,000Dh,000Eh ;
+ 000Fh,0010h,0011h,0012h,0013h,0015h,0016h,0018h ; entry
+ 0019h,001Bh,001Ch,001Eh,0020h,0021h,0023h,0025h ; 000h..07Fh
+ 0027h,0029h,002Ch,002Eh,0030h,0033h,0035h,0038h ;
+ 003Ah,003Dh,0040h,0043h,0046h,0049h,004Dh,0050h ;
+ 0054h,0057h,005Bh,005Fh,0063h,0067h,006Bh,006Fh ;
+ 0074h,0078h,007Dh,0082h,0087h,008Ch,0091h,0096h ;
+ 009Ch,00A1h,00A7h,00ADh,00B3h,00BAh,00C0h,00C7h ;
+ 00CDh,00D4h,00DBh,00E3h,00EAh,00F2h,00FAh,0101h ;
+ 010Ah,0112h,011Bh,0123h,012Ch,0135h,013Fh,0148h ;
+ 0152h,015Ch,0166h,0171h,017Bh,0186h,0191h,019Ch ;/
+ 01A8h,01B4h,01C0h,01CCh,01D9h,01E5h,01F2h,0200h ;\
+ 020Dh,021Bh,0229h,0237h,0246h,0255h,0264h,0273h ;
+ 0283h,0293h,02A3h,02B4h,02C4h,02D6h,02E7h,02F9h ;
+ 030Bh,031Dh,0330h,0343h,0356h,036Ah,037Eh,0392h ;
+ 03A7h,03BCh,03D1h,03E7h,03FCh,0413h,042Ah,0441h ;
+ 0458h,0470h,0488h,04A0h,04B9h,04D2h,04ECh,0506h ;
+ 0520h,053Bh,0556h,0572h,058Eh,05AAh,05C7h,05E4h ; entry
+ 0601h,061Fh,063Eh,065Ch,067Ch,069Bh,06BBh,06DCh ; 080h..0FFh
+ 06FDh,071Eh,0740h,0762h,0784h,07A7h,07CBh,07EFh ;
+ 0813h,0838h,085Dh,0883h,08A9h,08D0h,08F7h,091Eh ;
+ 0946h,096Fh,0998h,09C1h,09EBh,0A16h,0A40h,0A6Ch ;
+ 0A98h,0AC4h,0AF1h,0B1Eh,0B4Ch,0B7Ah,0BA9h,0BD8h ;
+ 0C07h,0C38h,0C68h,0C99h,0CCBh,0CFDh,0D30h,0D63h ;
+ 0D97h,0DCBh,0E00h,0E35h,0E6Bh,0EA1h,0ED7h,0F0Fh ;
+ 0F46h,0F7Fh,0FB7h,0FF1h,102Ah,1065h,109Fh,10DBh ;
+ 1116h,1153h,118Fh,11CDh,120Bh,1249h,1288h,12C7h ;/
+ 1307h,1347h,1388h,13C9h,140Bh,144Dh,1490h,14D4h ;\
+ 1517h,155Ch,15A0h,15E6h,162Ch,1672h,16B9h,1700h ;
+ 1747h,1790h,17D8h,1821h,186Bh,18B5h,1900h,194Bh ;
+ 1996h,19E2h,1A2Eh,1A7Bh,1AC8h,1B16h,1B64h,1BB3h ;
+ 1C02h,1C51h,1CA1h,1CF1h,1D42h,1D93h,1DE5h,1E37h ;
+ 1E89h,1EDCh,1F2Fh,1F82h,1FD6h,202Ah,207Fh,20D4h ;
+ 2129h,217Fh,21D5h,222Ch,2282h,22DAh,2331h,2389h ; entry
+ 23E1h,2439h,2492h,24EBh,2545h,259Eh,25F8h,2653h ; 100h..17Fh
+ 26ADh,2708h,2763h,27BEh,281Ah,2876h,28D2h,292Eh ;
+ 298Bh,29E7h,2A44h,2AA1h,2AFFh,2B5Ch,2BBAh,2C18h ;
+ 2C76h,2CD4h,2D33h,2D91h,2DF0h,2E4Fh,2EAEh,2F0Dh ;
+ 2F6Ch,2FCCh,302Bh,308Bh,30EAh,314Ah,31AAh,3209h ;
+ 3269h,32C9h,3329h,3389h,33E9h,3449h,34A9h,3509h ;
+ 3569h,35C9h,3629h,3689h,36E8h,3748h,37A8h,3807h ;
+ 3867h,38C6h,3926h,3985h,39E4h,3A43h,3AA2h,3B00h ;
+ 3B5Fh,3BBDh,3C1Bh,3C79h,3CD7h,3D35h,3D92h,3DEFh ;/
+ 3E4Ch,3EA9h,3F05h,3F62h,3FBDh,4019h,4074h,40D0h ;\
+ 412Ah,4185h,41DFh,4239h,4292h,42EBh,4344h,439Ch ;
+ 43F4h,444Ch,44A3h,44FAh,4550h,45A6h,45FCh,4651h ;
+ 46A6h,46FAh,474Eh,47A1h,47F4h,4846h,4898h,48E9h ;
+ 493Ah,498Ah,49D9h,4A29h,4A77h,4AC5h,4B13h,4B5Fh ;
+ 4BACh,4BF7h,4C42h,4C8Dh,4CD7h,4D20h,4D68h,4DB0h ;
+ 4DF7h,4E3Eh,4E84h,4EC9h,4F0Eh,4F52h,4F95h,4FD7h ; entry
+ 5019h,505Ah,509Ah,50DAh,5118h,5156h,5194h,51D0h ; 180h..1FFh
+ 520Ch,5247h,5281h,52BAh,52F3h,532Ah,5361h,5397h ;
+ 53CCh,5401h,5434h,5467h,5499h,54CAh,54FAh,5529h ;
+ 5558h,5585h,55B2h,55DEh,5609h,5632h,565Bh,5684h ;
+ 56ABh,56D1h,56F6h,571Bh,573Eh,5761h,5782h,57A3h ;
+ 57C3h,57E2h,57FFh,581Ch,5838h,5853h,586Dh,5886h ;
+ 589Eh,58B5h,58CBh,58E0h,58F4h,5907h,5919h,592Ah ;
+ 593Ah,5949h,5958h,5965h,5971h,597Ch,5986h,598Fh ;
+ 5997h,599Eh,59A4h,59A9h,59ADh,59B0h,59B2h,59B3h ;/
+ Incoming ADPCM Data ---> Interpolated Data
+ _ _ _ _
+ | | | | | | | | . . . . Nibbles=79797979, Filter=0
+ | | | | | | | | ---> / \ / \ / \ / \ HALF-volume ZIGZAG-wave
+ | |_| |_| |_| |_ ' ' ' '
+ ___ ___
+ | | | | .'. .'. Nibbles=77997799, Filter=0
+ | | | | ---> / \ / \ FULL-volume SINE-wave
+ | |___| |___ ' '.' '.
+ _______ ___
+ | | .' '. Nibbles=77779999, Filter=0
+ | | ---> / \ SQUARE wave (with rounded edges)
+ | |_______ ' '.____
+ _____ _ __
+ | |_ _| .' ''. .' Nibbles=7777CC44, Filter=0
+ | |___| ---> / '..' CUSTOM wave-form
+ | '
+ ___ __
+ | |___| | _ \ ! / . \ ! / Nibbles=77DE9HZK, Filter=V
+ |_ ____| _| ---> - + - + - + - SOLAR STORM wave-form
+ __| |______|___ / ! \ ' / ! \
+ ____lower 16bit (at 1F801C08h+N*10h)___________________________________
+ 15 Attack Mode (0=Linear, 1=Exponential)
+ - Attack Direction (Fixed, always Increase) (until Level 7FFFh)
+ 14-10 Attack Shift (0..1Fh = Fast..Slow)
+ 9-8 Attack Step (0..3 = "+7,+6,+5,+4")
+ - Decay Mode (Fixed, always Exponential)
+ - Decay Direction (Fixed, always Decrease) (until Sustain Level)
+ 7-4 Decay Shift (0..0Fh = Fast..Slow)
+ - Decay Step (Fixed, always "-8")
+ 3-0 Sustain Level (0..0Fh) ;Level=(N+1)*800h
+ ____upper 16bit (at 1F801C0Ah+N*10h)___________________________________
+ 31 Sustain Mode (0=Linear, 1=Exponential)
+ 30 Sustain Direction (0=Increase, 1=Decrease) (until Key OFF flag)
+ 29 Not used? (should be zero)
+ 28-24 Sustain Shift (0..1Fh = Fast..Slow)
+ 23-22 Sustain Step (0..3 = "+7,+6,+5,+4" or "-8,-7,-6,-5") (inc/dec)
+ 21 Release Mode (0=Linear, 1=Exponential)
+ - Release Direction (Fixed, always Decrease) (until Level 0000h)
+ 20-16 Release Shift (0..1Fh = Fast..Slow)
+ - Release Step (Fixed, always "-8")
+Fixed Volume Mode (when Bit15=0):
+
15 Must be zero (0=Volume Mode)
+ 0-14 Voice volume/2 (-4000h..+3FFFh = Volume -8000h..+7FFEh)
+ 15 Must be set (1=Sweep Mode)
+ 14 Sweep Mode (0=Linear, 1=Exponential)
+ 13 Sweep Direction (0=Increase, 1=Decrease)
+ 12 Sweep Phase (0=Positive, 1=Negative)
+ 7-11 Not used? (should be zero)
+ 6-2 Sweep Shift (0..1Fh = Fast..Slow)
+ 1-0 Sweep Step (0..3 = "+7,+6,+5,+4" or "-8,-7,-6,-5") (inc/dec)
+ 0-15 Volume Left (-8000h..+7FFFh)
+ 16-31 Volume Right (-8000h..+7FFFh)
+ AdsrCycles = 1 SHL Max(0,ShiftValue-11)
+ AdsrStep = StepValue SHL Max(0,11-ShiftValue)
+ IF exponential AND increase AND AdsrLevel>6000h THEN AdsrCycles=AdsrCycles*4
+ IF exponential AND decrease THEN AdsrStep=AdsrStep*AdsrLevel/8000h
+ Wait(AdsrCycles) ;cycles counted at 44.1kHz clock
+ AdsrLevel=AdsrLevel+AdsrStep ;saturated to 0..+7FFFh
+ 15-0 Current ADSR Volume (0..+7FFFh) (or -8000h..+7FFFh on manual write)
+ 0-15 Current Volume Left (-8000h..+7FFFh)
+ 16-31 Current Volume Right (-8000h..+7FFFh)
+Negative volumes are phase inverted, otherwise same as positive.
0-23 Voice 0..23 On (0=No change, 1=Start Attack/Decay/Sustain)
+ 24-31 Not used
+ 0-23 Voice 0..23 Off (0=No change, 1=Start Release)
+ 24-31 Not used
+ 0-23 Voice 0..23 Status (0=Newly Keyed On, 1=Reached LOOP-END)
+ 24-31 Not used
+Key On and Key Off should be treated as write-only (although, reading returns
+the most recently 32bit value, this doesn't doesn't provide any status
+information about whether sound is on or off).
+The on/off (status) (ENDX) register should be treated read-only (writing is
+possible in so far that the written value can be read-back for a short moment,
+however, thereafter the hardware is overwriting that value).
0-23 Voice 0..23 Noise (0=ADPCM, 1=Noise)
+ 24-31 Not used
+The signed 16bit output Level is calculated as so (repeated at 44.1kHz clock):
+
Wait(1 cycle) ;at 44.1kHz clock
+ Timer=Timer-NoiseStep ;subtract Step (4..7)
+ ParityBit = NoiseLevel.Bit15 xor Bit12 xor Bit11 xor Bit10 xor 1
+ IF Timer<0 then NoiseLevel = NoiseLevel*2 + ParityBit
+ IF Timer<0 then Timer=Timer+(20000h SHR NoiseShift) ;reload timer once
+ IF Timer<0 then Timer=Timer+(20000h SHR NoiseShift) ;reload again if needed
+ 15 SPU Enable (0=Off, 1=On) (Don't care for CD Audio)
+ 14 Mute SPU (0=Mute, 1=Unmute) (Don't care for CD Audio)
+ 13-10 Noise Frequency Shift (0..0Fh = Low .. High Frequency)
+ 9-8 Noise Frequency Step (0..03h = Step "4,5,6,7")
+ 7 Reverb Master Enable (0=Disabled, 1=Enabled)
+ 6 IRQ9 Enable (0=Disabled/Acknowledge, 1=Enabled; only when Bit15=1)
+ 5-4 Sound RAM Transfer Mode (0=Stop, 1=ManualWrite, 2=DMAwrite, 3=DMAread)
+ 3 External Audio Reverb (0=Off, 1=On)
+ 2 CD Audio Reverb (0=Off, 1=On) (for CD-DA and XA-ADPCM)
+ 1 External Audio Enable (0=Off, 1=On)
+ 0 CD Audio Enable (0=Off, 1=On) (for CD-DA and XA-ADPCM)
+ 15-12 Unknown/Unused (seems to be usually zero)
+ 11 Writing to First/Second half of Capture Buffers (0=First, 1=Second)
+ 10 Data Transfer Busy Flag (0=Ready, 1=Busy)
+ 9 Data Transfer DMA Read Request (0=No, 1=Yes)
+ 8 Data Transfer DMA Write Request (0=No, 1=Yes)
+ 7 Data Transfer DMA Read/Write Request ;seems to be same as SPUCNT.Bit5
+ 6 IRQ9 Flag (0=No, 1=Interrupt Request)
+ 5-0 Current SPU Mode (same as SPUCNT.Bit5-0, but, applied a bit delayed)
+ 15-0 Address in sound buffer divided by eight
+ 15-0 Data (max 32 halfwords)
+ 15-4 Unknown/no effect? (should be zero)
+ 3-1 Sound RAM Data Transfer Type (see below) (should be 2)
+ 0 Unknown/no effect? (should be zero)
+ __Transfer Type___Halfwords in Fifo________Halfwords written to SPU RAM__
+ 0,1,6,7 Fill A,B,C,D,E,F,G,H,...,X X,X,X,X,X,X,X,X,...
+ 2 Normal A,B,C,D,E,F,G,H,...,X A,B,C,D,E,F,G,H,...
+ 3 Rep2 A,B,C,D,E,F,G,H,...,X A,A,C,C,E,E,G,G,...
+ 4 Rep4 A,B,C,D,E,F,G,H,...,X A,A,A,A,E,E,E,E,...
+ 5 Rep8 A,B,C,D,E,F,G,H,...,X H,H,H,H,H,H,H,H,...
+As by now, there's no known method for reading SPU RAM without using DMA.
Below describes some dirt effects and some trickery to get around those dirt
+effects.
+
Below problems (and workarounds) apply ONLY if [1F801014h].bit24-27 = zero.
+ Ie. below info describes what happens when [1F801014h] is mis-initialized.
+ Normally one should set [1F801014h]=220931E1h (and can ignore below info).
+ 1st block: FFFFh, halfwords[00h..1Eh]
+ 2nd block: FFFFh, halfwords[20h..3Eh]
+ etc.
+ 1st block: FFFFh, halfwords[00h..1Eh], twice halfword[1Fh]
+ 2nd block: FFFFh, halfwords[20h..3Eh], twice halfword[3Fh]
+ etc.
+ 1st block: FFFFh, halfwords[00h,00h,..0Eh,0Eh], triple halfword[0Fh]
+ 2nd block: FFFFh, halfwords[10h,10h,..1Eh,1Eh], triple halfword[1Fh]
+ etc.
+ 15-0 Address in sound buffer divided by eight
+Triggers an IRQ when a voice reads ADPCM data from the IRQ address.
+Mind that ADPCM cannot be stopped (uh, except, probably they CAN be stopped, by
+setting the sample rate to zero?), all voices are permanently reading data from
+SPU RAM - even in Noise mode, even if the Voice Volume is zero, and even if the
+ADSR pattern has finished the Release period - so even inaudible voices can
+trigger IRQs. To prevent unwanted IRQs, best set all unused voices to an
+endless looped dummy ADPCM block.
+For stable IRQs, the IRQ address should be aligned to the 16-byte ADPCM blocks.
+If if the IRQ address is in the middle of a 16-byte ADPCM block, then the IRQ
+doesn't seem to trigger always (unknown why, but it seems to occassionally miss
+IRQs, even if the block gets repeated several times).
Setting the IRQ address to 0000h..01FFh (aka byte address 00000h..00FFFh) will
+trigger IRQs on writes to the four capture buffers. Each of the four buffers
+contains 400h bytes (=200h samples), so the IRQ rate will be around 86.13Hz
+(44100Hz/200h).
+CD-Audio capture is always active (even CD-Audio output is disabld in SPUCNT,
+and even if the drive door is open). Voice capture is (probably) also always
+active (even if the corresponding voice is off).
+Capture IRQs do NOT occur if 1F801DACh.bit3-2 are both zero.
Reverb is also triggering interrupts if the IRQ address is located in the
+reverb buffer area. Unknown \<which> of the various reverb read(s) and/or
+reverb write(s) are triggering interrupts.
Data Transfers (usually via DMA4) to/from SPU-RAM do also trap SPU interrupts.
The IRQ Address is used in the following games (not exhaustive):
+Metal Gear Solid: Dialogue and Konami intro.
+Legend of Mana
+Hercules: the memory card loading screen's lip sync.
+Tokimeki Memorial 2
+Crash Team Racing: Lip sync, requires capture buffers.
+The Misadventures of Tron Bonne: Dialogues.
+Need For Speed 3: (somewhat?).
Port Reg Name Type Expl.
+ 1F801D84h spu vLOUT volume Reverb Output Volume Left
+ 1F801D86h spu vROUT volume Reverb Output Volume Right
+ 1F801DA2h spu mBASE base Reverb Work Area Start Address in Sound RAM
+ 1F801DC0h rev00 dAPF1 disp Reverb APF Offset 1
+ 1F801DC2h rev01 dAPF2 disp Reverb APF Offset 2
+ 1F801DC4h rev02 vIIR volume Reverb Reflection Volume 1
+ 1F801DC6h rev03 vCOMB1 volume Reverb Comb Volume 1
+ 1F801DC8h rev04 vCOMB2 volume Reverb Comb Volume 2
+ 1F801DCAh rev05 vCOMB3 volume Reverb Comb Volume 3
+ 1F801DCCh rev06 vCOMB4 volume Reverb Comb Volume 4
+ 1F801DCEh rev07 vWALL volume Reverb Reflection Volume 2
+ 1F801DD0h rev08 vAPF1 volume Reverb APF Volume 1
+ 1F801DD2h rev09 vAPF2 volume Reverb APF Volume 2
+ 1F801DD4h rev0A mLSAME src/dst Reverb Same Side Reflection Address 1 Left
+ 1F801DD6h rev0B mRSAME src/dst Reverb Same Side Reflection Address 1 Right
+ 1F801DD8h rev0C mLCOMB1 src Reverb Comb Address 1 Left
+ 1F801DDAh rev0D mRCOMB1 src Reverb Comb Address 1 Right
+ 1F801DDCh rev0E mLCOMB2 src Reverb Comb Address 2 Left
+ 1F801DDEh rev0F mRCOMB2 src Reverb Comb Address 2 Right
+ 1F801DE0h rev10 dLSAME src Reverb Same Side Reflection Address 2 Left
+ 1F801DE2h rev11 dRSAME src Reverb Same Side Reflection Address 2 Right
+ 1F801DE4h rev12 mLDIFF src/dst Reverb Different Side Reflect Address 1 Left
+ 1F801DE6h rev13 mRDIFF src/dst Reverb Different Side Reflect Address 1 Right
+ 1F801DE8h rev14 mLCOMB3 src Reverb Comb Address 3 Left
+ 1F801DEAh rev15 mRCOMB3 src Reverb Comb Address 3 Right
+ 1F801DECh rev16 mLCOMB4 src Reverb Comb Address 4 Left
+ 1F801DEEh rev17 mRCOMB4 src Reverb Comb Address 4 Right
+ 1F801DF0h rev18 dLDIFF src Reverb Different Side Reflect Address 2 Left
+ 1F801DF2h rev19 dRDIFF src Reverb Different Side Reflect Address 2 Right
+ 1F801DF4h rev1A mLAPF1 src/dst Reverb APF Address 1 Left
+ 1F801DF6h rev1B mRAPF1 src/dst Reverb APF Address 1 Right
+ 1F801DF8h rev1C mLAPF2 src/dst Reverb APF Address 2 Left
+ 1F801DFAh rev1D mRAPF2 src/dst Reverb APF Address 2 Right
+ 1F801DFCh rev1E vLIN volume Reverb Input Volume Left
+ 1F801DFEh rev1F vRIN volume Reverb Input Volume Right
+ 0-23 Voice 0..23 Destination (0=To Mixer, 1=To Mixer and to Reverb)
+ 24-31 Not used
+The SPUCNT register contains a Reverb Master Enable flag, and Reverb Enable
+flags for External Audio input and CD Audio input.
+When the Reverb Master Enable flag is cleared, the SPU stops to write any data
+to the Reverb buffer (that is useful when zero-filling the reverb buffer;
+ensuring that already-zero values aren't overwritten by still-nonzero values).
+However, the Reverb Master Enable flag does not disable output from Reverb
+buffer to the speakers (that might be useful to output uncompressed 22050Hz
+samples) (otherwise, to disable the buffer output, set the Reverb Output volume
+to zero and/or zerofill the reverb buffer).
___Input from Mixer (Input volume multiplied with incoming data)_____________
+ Lin = vLIN * LeftInput ;from any channels that have Reverb enabled
+ Rin = vRIN * RightInput ;from any channels that have Reverb enabled
+ ____Same Side Reflection (left-to-left and right-to-right)___________________
+ [mLSAME] = (Lin + [dLSAME]*vWALL - [mLSAME-2])*vIIR + [mLSAME-2] ;L-to-L
+ [mRSAME] = (Rin + [dRSAME]*vWALL - [mRSAME-2])*vIIR + [mRSAME-2] ;R-to-R
+ ___Different Side Reflection (left-to-right and right-to-left)_______________
+ [mLDIFF] = (Lin + [dRDIFF]*vWALL - [mLDIFF-2])*vIIR + [mLDIFF-2] ;R-to-L
+ [mRDIFF] = (Rin + [dLDIFF]*vWALL - [mRDIFF-2])*vIIR + [mRDIFF-2] ;L-to-R
+ ___Early Echo (Comb Filter, with input from buffer)__________________________
+ Lout=vCOMB1*[mLCOMB1]+vCOMB2*[mLCOMB2]+vCOMB3*[mLCOMB3]+vCOMB4*[mLCOMB4]
+ Rout=vCOMB1*[mRCOMB1]+vCOMB2*[mRCOMB2]+vCOMB3*[mRCOMB3]+vCOMB4*[mRCOMB4]
+ ___Late Reverb APF1 (All Pass Filter 1, with input from COMB)________________
+ Lout=Lout-vAPF1*[mLAPF1-dAPF1], [mLAPF1]=Lout, Lout=Lout*vAPF1+[mLAPF1-dAPF1]
+ Rout=Rout-vAPF1*[mRAPF1-dAPF1], [mRAPF1]=Rout, Rout=Rout*vAPF1+[mRAPF1-dAPF1]
+ ___Late Reverb APF2 (All Pass Filter 2, with input from APF1)________________
+ Lout=Lout-vAPF2*[mLAPF2-dAPF2], [mLAPF2]=Lout, Lout=Lout*vAPF2+[mLAPF2-dAPF2]
+ Rout=Rout-vAPF2*[mRAPF2-dAPF2], [mRAPF2]=Rout, Rout=Rout*vAPF2+[mRAPF2-dAPF2]
+ ___Output to Mixer (Output volume multiplied with input from APF2)___________
+ LeftOutput = Lout*vLOUT
+ RightOutput = Rout*vROUT
+ ___Finally, before repeating the above steps_________________________________
+ BufferAddress = MAX(mBASE, (BufferAddress+2) AND 7FFFEh)
+ Wait one 22050Hz cycle, then repeat the above stuff
+The values written to memory are saturated to -8000h..+7FFFh.
+The multiplication results are divided by +8000h, to fit them to 16bit range.
+All memory addresses are relative to the current BufferAddress, and wrapped
+within mBASE..7FFFEh when exceeding that region.
+All data in the Reverb buffer consists of signed 16bit samples. The Left and
+Right Reverb Buffer addresses should be choosen so that one half of the buffer
+contains Left samples, and the other half Right samples (ie. the data is
+L,L,L,L,... R,R,R,R,...; it is NOT interlaced like L,R,L,R,...), during
+operation, when the buffer address increases, the Left half will overwrite the
+older samples of the Right half, and vice-versa.
+The reverb hardware spends one 44100h cycle on left calculations, and the next
+44100h cycle on right calculations (unlike as shown in the above formula, where
+left/right are shown simultaneously at 22050Hz).
SPUCNT.bit7 disables writes to reverb buffer, but reads from reverb buffer do
+still occur. If vAPF2 is zero then it does simply read "Lout=[mLAPF2-dAPF2]"
+and "Rout=[mRAPF2-dAPF2]". If vAPF2 is nonzero then it does additionally use
+data from APF1, if vAPF1 and vAPF2 are both nonzero then it's also using data
+from COMB. However, the SAME/DIFF stages aren't used when reverb is disabled.
vIIR works only in range -7FFFh..+7FFFh. When set to -8000h, the multiplication
+by -8000h is still done correctly, but, the final result (the value written to
+memory) gets negated (this is a pretty strange feature, it is NOT a simple
+overflow bug, it does affect the "+[mLSAME-2]" addition; although that part
+normally shouldn't be affected by the "*vIIR" multiplication). Similar effects
+might (?) occur on some other volume registers when they are set to -8000h.
The speed of sound is circa 340 meters per second (in dry air, at room
+temperature). For example, a voice that travels to a wall at 17 meters
+distance, and back to its origin, should have a delay of 0.1 seconds.
Input and output to/from the reverb unit is resampled using a 39-tap FIR filter
+with the following coefficients.
-0001h, 0000h, 0002h, 0000h, -000Ah, 0000h, 0023h, 0000h,
+ -0067h, 0000h, 010Ah, 0000h, -0268h, 0000h, 0534h, 0000h,
+ -0B90h, 0000h, 2806h, 4000h, 2806h, 0000h, -0B90h, 0000h,
+ 0534h, 0000h, -0268h, 0000h, 010Ah, 0000h, -0067h, 0000h,
+ 0023h, 0000h, -000Ah, 0000h, 0002h, 0000h, -0001h,
+Below are some Reverb examples, showing the required memory size (ie. set Port
+1F801DA2h to "(80000h-size)/8"), and the Reverb register settings for Port
+1F801DC0h..1F801DFFh, ie. arranged like so:
+
dAPF1 dAPF2 vIIR vCOMB1 vCOMB2 vCOMB3 vCOMB4 vWALL ;1F801DC0h..CEh
+ vAPF1 vAPF2 mLSAME mRSAME mLCOMB1 mRCOMB1 mLCOMB2 mRCOMB2 ;1F801DD0h..DEh
+ dLSAME dRSAME mLDIFF mRDIFF mLCOMB3 mRCOMB3 mLCOMB4 mRCOMB4 ;1F801DE0h..EEh
+ dLDIFF dRDIFF mLAPF1 mRAPF1 mLAPF2 mRAPF2 vLIN vRIN ;1F801DF0h..FEh
+ 007Dh,005Bh,6D80h,54B8h,BED0h,0000h,0000h,BA80h
+ 5800h,5300h,04D6h,0333h,03F0h,0227h,0374h,01EFh
+ 0334h,01B5h,0000h,0000h,0000h,0000h,0000h,0000h
+ 0000h,0000h,01B4h,0136h,00B8h,005Ch,8000h,8000h
+ 0033h,0025h,70F0h,4FA8h,BCE0h,4410h,C0F0h,9C00h
+ 5280h,4EC0h,03E4h,031Bh,03A4h,02AFh,0372h,0266h
+ 031Ch,025Dh,025Ch,018Eh,022Fh,0135h,01D2h,00B7h
+ 018Fh,00B5h,00B4h,0080h,004Ch,0026h,8000h,8000h
+ 00B1h,007Fh,70F0h,4FA8h,BCE0h,4510h,BEF0h,B4C0h
+ 5280h,4EC0h,0904h,076Bh,0824h,065Fh,07A2h,0616h
+ 076Ch,05EDh,05ECh,042Eh,050Fh,0305h,0462h,02B7h
+ 042Fh,0265h,0264h,01B2h,0100h,0080h,8000h,8000h
+ 00E3h,00A9h,6F60h,4FA8h,BCE0h,4510h,BEF0h,A680h
+ 5680h,52C0h,0DFBh,0B58h,0D09h,0A3Ch,0BD9h,0973h
+ 0B59h,08DAh,08D9h,05E9h,07ECh,04B0h,06EFh,03D2h
+ 05EAh,031Dh,031Ch,0238h,0154h,00AAh,8000h,8000h
+ 01A5h,0139h,6000h,5000h,4C00h,B800h,BC00h,C000h
+ 6000h,5C00h,15BAh,11BBh,14C2h,10BDh,11BCh,0DC1h
+ 11C0h,0DC3h,0DC0h,09C1h,0BC4h,07C1h,0A00h,06CDh
+ 09C2h,05C1h,05C0h,041Ah,0274h,013Ah,8000h,8000h
+ 0017h,0013h,70F0h,4FA8h,BCE0h,4510h,BEF0h,8500h
+ 5F80h,54C0h,0371h,02AFh,02E5h,01DFh,02B0h,01D7h
+ 0358h,026Ah,01D6h,011Eh,012Dh,00B1h,011Fh,0059h
+ 01A0h,00E3h,0058h,0040h,0028h,0014h,8000h,8000h
+ 033Dh,0231h,7E00h,5000h,B400h,B000h,4C00h,B000h
+ 6000h,5400h,1ED6h,1A31h,1D14h,183Bh,1BC2h,16B2h
+ 1A32h,15EFh,15EEh,1055h,1334h,0F2Dh,11F6h,0C5Dh
+ 1056h,0AE1h,0AE0h,07A2h,0464h,0232h,8000h,8000h
+ 0001h,0001h,7FFFh,7FFFh,0000h,0000h,0000h,8100h
+ 0000h,0000h,1FFFh,0FFFh,1005h,0005h,0000h,0000h
+ 1005h,0005h,0000h,0000h,0000h,0000h,0000h,0000h
+ 0000h,0000h,1004h,1002h,0004h,0002h,8000h,8000h
+ 0001h,0001h,7FFFh,7FFFh,0000h,0000h,0000h,0000h
+ 0000h,0000h,1FFFh,0FFFh,1005h,0005h,0000h,0000h
+ 1005h,0005h,0000h,0000h,0000h,0000h,0000h,0000h
+ 0000h,0000h,1004h,1002h,0004h,0002h,8000h,8000h
+ 0000h,0000h,0000h,0000h,0000h,0000h,0000h,0000h
+ 0000h,0000h,0001h,0001h,0001h,0001h,0001h,0001h
+ 0000h,0000h,0001h,0001h,0001h,0001h,0001h,0001h
+ 0000h,0000h,0001h,0001h,0001h,0001h,0000h,0000h
+ 0-15 Unknown?
+ 80 21 4B DF
+ .. 31 .. ..
+ 7E 61 A9 96 47 39 F9 1E E1 E1 80 DD E8 17 7F FB
+ FB BF 1D 6C 8F EC F3 04 06 23 89 45 C1 6D 31 82
+ .. .. .. .. .. .. .. .. .. .. .. .. .. .. 7B ..
+ .. .. .. .. .. .. .. .. 04 .. .. .. .. .. .. 86
+The bytes at 1F801DBCh and 1F801E60h usually have the above values on
+cold-boot. The registers are read/write-able, although writing any values to
+them doesn't seem to have any effect on sound output. Also, the SPU doesn't
+seem to modify the registers at any time during sound output, nor reverb
+calculations, nor activated external audio input... the registers seem to be
+just some kind of general-purpose RAM.
The 33.8 Mhz clock of the PSX is a well chosen value. +It is exactly 768 x 44.1 Khz = For each audio sample in CD quality, there are 768 cycles of system clock. +So, the state machine has to repeat its complete cycle every 768 system clock cycles.
+Now the full job to do within those 768 cycles: +- 24 channels to process. +- Reverb to compute and write back. +- Write back to voice 1 / 3, audio CD L/R. +- Do transfer from/to CPU bus of SPU RAM data if asked.
+By looking at the signal of the SPU RAM chip, it is possible to figure out what it is reading and writing. +- A read or a write to the SPU Ram is happening in 8 clock cycles. (Did not check in detail, but probably allow refresh and everything) +- Each channel is using 24 cycles. (3 operations of 8 cycles) + - Has TWO read for the current ADPCM block : one to the header of the currently played ADPCM block, one to the current 16 bit of the ADPCM. + - A unrelated READ (see later) +- 8 Cycle for each operation : WRITE CD Left, WRITE CD Right, Voice 1 WRITE, Voice 3 WRITE. +- Reverb operations : 14 memory operations of 8 cycles.
+When doing the analysis from data, it is possible to figure out what are the operations, in what order they are done. +But it is not possible to figure out what is the FIRST operation in the loop. +So we arbitrarely decide to start the loop at 'Voice 1' (voice being from 1 to 24).
+As written earlier, each Voice is 3x RAM access (one unrelated), reverb is 14x RAM access, then 4x RAM access for the all write.
+ [Left Side] [Right Side]
+READ REVERB dLSame dRSame
+READ REVERB mLSame-1 mRSame-1
+READ REVERB dRDiff dLDiff
+XXXX REVERB mLSame mRSame <-- WRITE becomes READ if REVERB DISABLED.
+READ REVERB mLDiff-1 mRDiff-1
+READ REVERB mLComb1 mRComb1
+XXXX REVERB mLDiff mRDiff <-- WRITE becomes READ if REVERB DISABLED.
+READ REVERB mLComb2 mRComb2
+READ REVERB mLComb3 mRComb3
+READ REVERB mLComb4 mRComb4
+READ REVERB mLAPF1 - dAPF1 mRAPF1 - dAPF1
+READ REVERB mLAPF2 - dAPF2 mRAPF2 - dAPF2
+XXXX REVERB mLAPF1 mRAPF1 <-- WRITE becomes READ if REVERB DISABLED.
+XXXX REVERB mLAPF2 mRAPF2 <-- WRITE becomes READ if REVERB DISABLED.
+Read Header word in current ADPCM block.
+Read Current Sample 16 bit word in current ADPCM block.
+Read [UNRELATED ADR ? Not related to current block...]
+Everything is not fully clear yet, testing of SPU with proper tests to validate/invalidate various assumption. +Our finding are based on a logic analyzer log using the PSX boot sounds, knowing the values of the registers thanks to emulators.
+ + + + + + + 0-15 Current Counter value (incrementing)
+ 16-31 Garbage
+ 0 Synchronization Enable (0=Free Run, 1=Synchronize via Bit1-2)
+ 1-2 Synchronization Mode (0-3, see lists below)
+ Synchronization Modes for Counter 0:
+ 0 = Pause counter during Hblank(s)
+ 1 = Reset counter to 0000h at Hblank(s)
+ 2 = Reset counter to 0000h at Hblank(s) and pause outside of Hblank
+ 3 = Pause until Hblank occurs once, then switch to Free Run
+ Synchronization Modes for Counter 1:
+ Same as above, but using Vblank instead of Hblank
+ Synchronization Modes for Counter 2:
+ 0 or 3 = Stop counter at current value (forever, no h/v-blank start)
+ 1 or 2 = Free Run (same as when Synchronization Disabled)
+ 3 Reset counter to 0000h (0=After Counter=FFFFh, 1=After Counter=Target)
+ 4 IRQ when Counter=Target (0=Disable, 1=Enable)
+ 5 IRQ when Counter=FFFFh (0=Disable, 1=Enable)
+ 6 IRQ Once/Repeat Mode (0=One-shot, 1=Repeatedly)
+ 7 IRQ Pulse/Toggle Mode (0=Short Bit10=0 Pulse, 1=Toggle Bit10 on/off)
+ 8-9 Clock Source (0-3, see list below)
+ Counter 0: 0 or 2 = System Clock, 1 or 3 = Dotclock
+ Counter 1: 0 or 2 = System Clock, 1 or 3 = Hblank
+ Counter 2: 0 or 1 = System Clock, 2 or 3 = System Clock/8
+ 10 Interrupt Request (0=Yes, 1=No) (Set after Writing) (W=1) (R)
+ 11 Reached Target Value (0=No, 1=Yes) (Reset after Reading) (R)
+ 12 Reached FFFFh Value (0=No, 1=Yes) (Reset after Reading) (R)
+ 13-15 Unknown (seems to be always zero)
+ 16-31 Garbage (next opcode)
+ 0-15 Counter Target value
+ 16-31 Garbage
+For more info on dotclock and hblank timings, see:
+GPU Timings
+Caution: Reading the Current Counter Value can be a little unstable (when using
+dotclk or hblank as clock source); the GPU clock isn't in sync with the CPU
+clock, so the timer may get changed during the CPU read cycle. As a workaround:
+repeat reading the timer until the received value is the same (or slightly
+bigger) than the previous value.
When resetting the Counter by writing the Mode register, it will stay at 0000h for 2 clock cycles before counting up.
+When writing the Current value, it will stay at the written value for 2 clock cycles before counting up or checking against Target overflows.
+When wrapping around at FFFFh(Mode Bit3 not set), it will stay at 0000h for only 1 clock cycle.
+When being reset to 0000h by reaching the Target value(Mode Bit3 set), it will stay at 0000h for 2 clock cycles.
+Example behavior with Target Value of 0001h and Mode Bit3 set:
+
clock cycle 0 - Counter Value = 0000h
+clock cycle 1 - Counter Value = 0000h
+clock cycle 2 - Counter Value = 0001h
+clock cycle 3 - Counter Value = 0000h
+clock cycle 4 - Counter Value = 0000h
+clock cycle 5 - Counter Value = 0001h
+Normally, I/O ports should be accessed only at their corresponding size (ie.
+16bit read/write for 16bit ports), and of course, only existing memory and I/O
+addresses should be used. When not recursing that rules, some more or less
+(un-)predictable things may happen...
Address Content W.8bit W.16bit W.32bit
+ 00000000h-00xFFFFFh Main RAM OK OK OK
+ 1F800000h-1F8003FFh Scratchpad OK OK OK
+ 1F801000h-1F801023h MEMCTRL (w32) (w32) OK
+ 1F80104xh JOY_xxx (w16) OK CROP
+ 1F80105xh SIO_xxx (w16) OK CROP
+ 1F801060h-1F801063h RAM_SIZE (w32) (w32) OK (with crash)
+ 1F801070h-1F801077h IRQCTRL (w32) (w32) OK
+ 1F8010x0h-1F8010x3h DMAx.ADDR (w32) (w32) OK
+ 1F8010x4h-1F8010x7h DMAx.LEN OK OK OK
+ 1F8010x8h-1F8010xFh DMAx.CTRL/MIRR (w32) (w32) OK
+ 1F8010F0h-1F8010F7h DMA.DPCR/DICR (w32) (w32) OK
+ 1F8010F8h-1F8010FFh DMA.unknown IGNORE IGNORE IGNORE
+ 1F801100h-1F80110Bh Timer 0 (w32) (w32) OK
+ 1F801110h-1F80111Bh Timer 1 (w32) (w32) OK
+ 1F801120h-1F80112Bh Timer 2 (w32) (w32) OK
+ 1F801800h-1F801803h CDROM OK ? ?
+ 1F801810h-1F801813h GPU.GP0 ? ? OK
+ 1F801814h-1F801817h GPU.GP1 ? ? OK
+ 1F801820h-1F801823h MDEC.CMD/DTA ? ? OK
+ 1F801824h-1F801827h MDEC.CTRL ? ? OK
+ 1F801C00h-1F801E7Fh SPU (i16) OK OK
+ 1F801E80h-1F801FFFh SPU.UNUSED IGNORE IGNORE IGNORE
+ 1F802020h-1F80202Fh DUART OK ? ?
+ 1F802041h POST OK ? ?
+ FFFE0130h-FFFE0133h CACHE.CTRL (i32) (i32) OK
+ OK works
+ (w32) write full 32bits (left-shifted if address isn't word-aligned)
+ (w16) write full 16bits (left-shifted if address isn't halfword-aligned)
+ (i32) write full 32bits (ignored if address isn't word-aligned)
+ (i16) write full 16bits (ignored if address isn't halfword-aligned)
+ CROP write only lower 16bit (and leave upper 16bit unchanged)
+In most cases, I/O ports can be read in 8bit, 16bit, or 32bit units, regardless
+of their size, among others allowing to read two 16bit ports at once with a
+single 32bit read. If there's only one 16bit port within a 32bit region, then
+32bit reads often return garbage in the unused 16bits. Also, 8bit or 16bit VRAM
+data reads via GPUREAD probably won't work? Expansion 2 Region can be accessed
+only via 8bit reads, and 16bit/32bit reads seem to cause exceptions (or rather:
+no such exception!) (except, probably 16bit reads are allowed when the region
+is configured to 16bit databus width).
+There are at least some special cases:
+
FFFE0130h-FFFE0133h 8bit (+16bit?) read works ONLY from word-aligned address
+Performing a 8-bit or 16-bit write (sb/sh) will place the entirety of the GPR
+on the bus, regardless of the write size. Therefore, the data is not masked.
+This has an effect when performing a narrower write to a wider address, for example
+the DMA controller, but not others such as the CD-ROM controller.
Emulators should therefore treat all access widths as having 32 bits of data, but +depending on the device perform masking/splitting (see Memory Control).
+The CD audio visualizer (aka Soundscope) in the SCPH-7xxx series of consoles is an +example of where this behavior is required, as it issues halfword writes to the DMA +controller addresses.
+The functionality of the Cache is still widely unknown. Not sure if DMA
+transfers are updating or invalidating cache. Cached Data within KSEG0 should
+be automatically also cached at the corresponding mirrored address in KUSEG and
+vice versa. Mirrors within KSEG1 (or within KUSEG) may be a different thing,
+eg. when using addresses spead across the first 8MB region to access the 2MB
+RAM. Same problems may occor for Expansion and BIOS mirrors, although, not sure
+if that regions are cached.
The writebuffer seems to be disabled for the normal I/O area at 1F801000h,
+however, it appears to be enabled for the Expansion I/O region at 1F802000h
+(after writing to 1F802041h, the BIOS issues 4 dummy writes to RAM, apparently
+(?) in order to flush the writebuffer). The same might apply for Expansion
+Memory region at 1F000000h, although usually that region would contain ROM, so
+it'd be don't care whether it is write-buffered or not.
XXcpuREG ---> applies ONLY to LOAD (not to store)
+Memory read/write opcodes take a 1-cycle delay until the data arrives at the
+destination, ie. the next opcode should not use the destination register (or
+more unlikely, the destination memory location) as source operand. Usually,
+when trying to do so, the second opcode would receive the OLD value - however,
+if an exception occurs between the two opcodes, then the read/write operation
+may finish, and the second opcode would probably receive the NEW value.
Exception handlers cannot preserve all registers, before returning, they must
+load the return address into a general purpose register (conventionally R26 aka
+K0), so be careful not to use that register, unless you are 100% sure that no
+interrupts and no other exceptions can occur. Some exception handlers might
+also destroy R27 aka K1 (though execption handler in the PSX Kernel leaves that
+register unchanged).
+Some assemblers (not a22i in nocash syntax mode) are internally using R1 aka AT
+as scratch register for some pseudo opcodes, including for a "sw rx,imm32"
+pseudo opcode (which is nearly impossible to separate from the normal "sw
+rx,imm16" opcode), be careful not to use R1, unless you can trust your
+assembler not to destroy that register behind your back.
+The PSX Kernel uses "Full-Decrementing-Wasted-Stack", where "Wasted" means that
+when calling a sub-function with N parameters, then the caller must
+pre-allocate N works on stack, and the sub-function may freely use and destroy
+these words; at [SP+0..N*4-1].
00800000h ;-when Main RAM configured to end at 7FFFFFh
+ 1F080000h 780000h ;-when Expansion 1 configured to end at 7FFFFh
+ 1F800400h C00h ;-region after Scratchpad
+ 1F801024h 1Ch ;\
+ 1F801064h 0Ch ;
+ 1F801078h 08h ;
+ 1F801140h 6C0h ; gaps in I/O region
+ 1F801804h 0Ch ;
+ 1F801818h 08h ;
+ 1F801828h 3D8h ;/
+ 1F802080h 3FDF80h ;-when Expansion 2 configured to end at 7Fh
+ 1FC80000h 60380000h ;-when BIOS ROM configured to end at 7FFFFh
+ C0000000h 1FFE0000h ;\
+ FFFE0020h E0h ; gaps in KSEG2 (cache control region)
+ FFFE0140h 1FEC0h ;/
+ 1F80108Ch+N*10h - D#_CHCR Mirrors - (N=0..6, for DMA channel 0..6)
+ 1F801062h (2 bytes) ;\
+ 1F801072h (2 bytes) ; unused addresses in Memory and Interrupt Control area
+ 1F801076h (2 bytes) ;/
+ 1F801102h (2 bytes) ;\
+ 1F801106h (2 bytes) ; unused addresses in Timer 0 area
+ 1F80110Ah (6 bytes) ;/
+ 1F801112h (2 bytes) ;\
+ 1F801116h (2 bytes) ; unused addresses in Timer 1 area
+ 1F80111Ah (6 bytes) ;/
+ 1F801122h (2 bytes) ;\
+ 1F801126h (2 bytes) ; unused addresses in Timer 2 area and next some bytes
+ 1F80112Ah (22 bytes) ;/
+ 1F801820h (4 bytes) ;-read MDEC Data-Out port (if there is no data)
+ FFFE0000h (32 bytes) ;\
+ FFFE0100h (48 bytes) ; unused addresses in Cache control area
+ FFFE0132h (2 bytes) ; (including write-only upper 16bit of Port FFFE0130h)
+ FFFE0134h (12 bytes) ;/
+In gaming and programming scene, "PSX" is most commonly used as abbreviation
+for the original Playstation series (occasionally including PSone). Sony has
+never officially used that abbreviation, however, the Playstation BIOS contains
+the ASCII strings "PSX" and "PS-X" here and there. The letters "PS" are widely
+believed to stand for PlayStation, and the meaning of the "X" is totally
+unknown (although, actually it may stand for POSIX.1, see below).
According to JMI Software Systems, "PSX" is a trademark of themselves, and
+stands for "single-user, single-group, subset of POSIX.1" (POSIX stands for
+something commonly used by HLL programmers under UNIX or so). That "PSX" kernel
+from JMI is available for various processors, including MIPS processors, and
+like the playstation, it does include functions like "atoi", and does support
+TTY access via Signetics 2681 DUART chips. The DTL-H2000 does also have
+POSIX-style "PSX>" prompt. So, altogether, it's quite possible that Sony has
+licensed the kernel from JMI.
As everybody agrees, PSX should be used only as abbreviation for Playstation 1,
+and nobody should never ever use it for the Playstation 2. Well, nobody, except
+Sony... despite of the common use as abbreviation for Playstation 1 (and
+despite of the JMI trademark)... in 2003, Sony has have released a "Playstation
+2 with built-in HDD/DVD Videorecorder" and called that thing "PSX" for the best
+of confusion.