Pocketstation
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
Pocketstation Overview
Sony's Pocketstation (SCPH-4000) (1998)
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 RTC Problem
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.
CPU Specs
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.
Pocketstation I/O Map
Memory and Memory-Control Registers
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)
Interrupts and Timers
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)
Communication Ports, Audio/Video
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
Upon reset, BIOS ROM is mirrored to address 00000000h (instead of RAM).
For most I/O ports, it is unknown if they are (R), (W), or (R/W)...?
I/O ports are usually accessed at 32bit width, occassionally some ports are (alternately) accessed at 16bit width. A special case are the F_SN registers which seem to be required to be accessed at 16bit (not 32bit).
Memory Access Time
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
Additional memory waitstates can be added via F_WAIT2 (and F_WAIT1 maybe).
Invalid/Unused Memory Locations
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)
Unsupported 8bit Reads
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 ...?
Unsupported 16bit Reads
0B800002h-0BFFFFFEh RTC area, odd addresses (with A1=1) mirror to 0B80000Ah
garbage_byte (for unsupported 8bit reads)
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
Note: The garbage_byte is "used" by the pocketstation "Rockman" series games.
Pocketstation Memory Map
Overall Memory Map
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)
00000000h..000001FFh - Kernel RAM
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)
00000200h..000007FFh - User RAM and User stack (stacktop at 800h)
This region can be freely used by the game. The memory is zerofilled when the
game starts.
02000000h - FLASH1 - Flash ROM (virtual file-mapped addresses in this region)
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.
08000000h - FLASH2 - Flash ROM (128K) (physical addresses in this region)
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.
04000000h - BIOS ROM (16K) - Kernel and GUI
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")
Bus-Width Restrictions
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.
Waitstates
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...?
Pocketstation IO Video and Audio
0D000000h - LCD_MODE - LCD control word (R/W)
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)
0D000004h - LCD_CAL - LCD Calibration (maybe contrast or so?)
Upon the reset, the kernel sets LCD_CAL = F_CAL AND 0000003Fh. Aside from that,
it doesn't use LCD_CAL.
0D000100h..D00017Fh - LCD_VRAM - 32x32 pixels, 1bit color depth (R/W)
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)
The LCD_VRAM area is reportedly mirrored to whatever locations?
0D800010h - DAC_CTRL - Audio Control (R/W)
0 Audio Enable enable (0=Off, 1=On)
1-31 Unknown, usually zero
0D800014h - DAC_DATA - Audio D/A Converter
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
For example, to produce a 1kHz square wave, the register must be toggled high/low at 2kHz rate. If desired, multiple channels can be mixed by software. High frequencies and multiple voices may require high CPU speed settings, and thus increase battery consumption (aside from that, battery consumption is probably increased anyways when the speaker is enabled).
Pocketstation IO Interrupts and Buttons
0A000004h - INT_INPUT - Raw Interrupt Signal Levels (R)
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
The direction keys seem to be separate buttons, ie. unlike as on a joystick or DPAD, Left/Right (and Up/Down) can be simultaneously pressed...?
0A000008h - INT_MASK_SET - Set Interrupt Mask (W)
0A00000Ch - INT_MASK_CLR - Clear Interrupt Mask (W)
0A000008h - INT_MASK_READ - Read Interrupt Mask (R)
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)
0A000000h - INT_LATCH - Interrupt Request Flags (R)
0A000010h - INT_ACK - Acknowledge Interrupts (W)
INT_LATCH Latched Interrupt Requests (0=None, 1=Interrupt Request) (R)
INT_ACK Clear Interrupt Requests (0=No change, 1=Acknowledge) (W)
The interrupts seem to be edge-triggered (?), ie. when the corresponding bits in INT_INPUT change from 0-to-1. Unknown if the request bits get set when the corresponding interrupt is disabled in INT_MASK...?
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?
Pocketstation IO Timers and Real-Time Clock
Timer and RTC interrupts
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)
0A800000h - T0_RELOAD - Timer 0 Reload Value
0A800010h - T1_RELOAD - Timer 1 Reload Value
0A800020h - T2_RELOAD - Timer 2 Reload Value
0-15 Reload Value (when timer becomes less than zero)
0A800004h - T0_COUNT - Timer 0 Current value
0A800014h - T1_COUNT - Timer 1 Current value
0A800024h - T2_COUNT - Timer 2 Current value
0-15 Current value (decrementing)
0A800008h - T0_MODE - Timer 0 Control
0A800018h - T1_MODE - Timer 1 Control
0A800028h - T2_MODE - Timer 2 Control
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)
0B800000h - RTC_MODE - RTC control word
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
0B800004h - RTC_ADJUST - Modify value (write only)
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.
0B800008h - RTC_TIME - Real-Time Clock Time (read only) (R)
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)
0B80000Ch - RTC_DATE - Real-Time Clock Date (read only) (R)
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)
Pocketstation IO Infrared
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).
0C800000h - IRDA_MODE - Controlling the protocol - send/recv, etc. (R/W)
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)
0C800004h - IRDA_DATA - Infrared TX Data
0 Transmit Data in Send Direction (0=LED Off, 1=LED On)
1-31 Unknown (should be zero)
0C80000Ch - IRDA_MISC
Unknown? Reportedly reserved.
INT_INPUT.12 - IRQ - Infrared RX Interrupt
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.
IR Notes
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...?
Pocketstation IO Memory-Control
06000000h - F_CTRL
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)
06000004h F_STAT
0-31 Unknown
06000008h F_BANK_FLG ;FLASH virtual bank mapping enable flags (16 bits)(R/W)
0-15 Enable physical banks 0..15 in virtual region (0=Disable, 1=Enable)
16-31 Unknown (should be zero)
06000100h F_BANK_VAL ;FLASH virtual bank mapping addresses (16 words)(R/W)
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
0600000Ch F_WAIT1 ;waitstates...?
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
06000010h F_WAIT2 ;waitstates, and FLASH-Write-Control-and-Status...?
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
08002A54h - F_KEY1 - Flash Unlock Address 1 (W)
080055AAh - F_KEY2 - Flash Unlock Address 2 (W)
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
06000300h - F_SN_LO - Serial Number LSBs
06000302h - F_SN_HI - Serial Number MSBs
06000308h - F_CAL - Calibration value for LCD
0-15 Data
Although only the above 3 halfwords are used by the BIOS, the "header" is unlike to be 6 bytes in size, probably there are whatever number of additional "header" locations at 06000300h and up...?
Note: Metal Gear Solid Integral uses F_SN as some kind of copy protection (the game refuses to run and displays "No copy" if F_SN is different as when the pocketstation file was initially created).
F_BANK_VAL and F_BANK_FLG Notes
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).
Pocketstation IO Communication Ports
0C000000h - COM_MODE - Com Mode
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)
0C000008h - COM_DATA - Com RX/TX Data
0-7 Data (Write: to be transmitted to PSX, Read: been received from PSX)
8-31 Unknown
0C000004h - COM_STAT1 - Com Status Register 1 (Bit1=Error)
0 Unknown
1 Error flag or so (0=Okay, 1=Error)
2-31 Unknown
Aside from the above error flag, one should check if INT_INPUT.11 becomes zero during transfer (which indicates undocking).
0C000014h - COM_STAT2 - Com Status Register 2 (Bit0=Ready)
0 Ready flag (0=Busy, 1=Ready) (when 8bits have been transferred)
1-31 Unknown
0C000010h - COM_CTRL1 - Com Control Register 1
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
0C000018h - COM_CTRL2 - Com Control Register 2
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)
INT_INPUT.6 FIQ (!) COM for the COM_registers? (via /SEL Pin?)
(via FIQ vector, not IRQ vector)
INT_INPUT.11 IRQ Docked ("IOP") (0=Undocked, 1=Docked to PSX)
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).
IOP_START/IOP_STOP.Bit1
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.
Opcode E6000010h (The Undefined Instruction) - Write chr(r0) to TTY
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...?
Pocketstation IO Power Control
0B000000h - CLK_MODE - Clock control (CPU and Timer Speed) (R/W)
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
For emulator authors: Note that some Pocketstation software will expect bit 4 of CLK_MODE to go from 0 to 1 rather than just polling it until it's 1. For this reason, emulating bit 4 as always being 1 can very likely break.
0B000004h - CLK_STOP - Clock stop (Sleep Mode)
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 ?
Before writing to CLK_STOP, one should do:
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
0D800000h - IOP_CTRL - Configures whatever...? (R/W)
0-3 Probably Direction for IOP_DATA bit0..3 (0=Input, 1=Output)
4-31 Unknown/Unused (seems to be always zero)
0D800004h - IOP_STAT (R) - Read Current bits? -- No, seems to be always 0
0D800004h - IOP_STOP (W) - Set IOP_DATA Bits
0D800008h - IOP_START (W) - Clear IOP_DATA Bits
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
Sound is usually disabled by setting IOP_STOP=00000020h. IOP_STAT is rarely used. Although, one piece of code in the BIOS disables sound by setting IOP_STOP=IOP_STAT OR 00000020h, that is probably nonsense, probably intended to keep bits stopped if they are already stopped (which would happen anyways), however, the strange code implies that reading from 0D800004h returns the current status of the register, and that the bits in that register seem to be 0=Started, and 1=Stopped...?
0D80000Ch - IOP_DATA (R)
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)
0D800020h - BATT_CTRL - Battery Monitor Control?
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...?
Battery Low Interrupt
INT_INPUT.10 IRQ Battery Low (0=Normal, 1=Battery Low)
The pocketstation can be also powered through the VCC pin (ie. when docked to the PSX, then it's working even if the battery is empty; or even without battery).
Pocketstation SWI Function Summary
SWI Function Summary
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
Pocketstation SWI Misc Functions
SWI 01h - SetCallbacks(index,proc)
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)
IRQ and FIQ Callbacks
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.
SWI 02h - CustomSwi2(r0..r6,r8..r10) out: r0
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).
SWI 04h - SetCpuSpeed(speed) out: old_speed
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.
Pocketstation SWI Communication Functions
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.
SWI 11h - SetComOnOff(flag)
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).
SWI 06h - GetPtrToComFlags()
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)
SWI 07h - ChangeAutoDocking(flags.16-18)
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)
SWI 0Bh - ClearComFlagsBit10()
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.
SWI 05h - SenseAutoCom()
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.
SWI 17h - GetPtrToFunc3addr()
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.
Download Notification callback
Can be used to mute sound during communication, see SWI 01h,
SetCallbacks(index,proc), and BU Command 5Dh for details.
Pocketstation SWI Execute Functions
SWI 08h - PrepareExecute(flag,dir_index,param)
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.
GUI \<param> values - for PrepareExecute(1,0,param)
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)
SWI 09h - DoExecute(), or DoExecute(snapshot_saving_flag) for MCX1
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().
SWI 16h - GetDirIndex()
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).
SWI 15h - MakeAlternateDirIndex(flag,dir_index) out: alt_dir_index (new/old)
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).
SWI 12h - TestSnapshot(dir_index)
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.
Snapshot Notes (MCX1 Files)
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...?
Pocketstation SWI Date/Time/Alarm Functions
SWI 0Ch - SetBcdDateTime(date,time)
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).
SWI 0Dh - GetBcdDate()
0-7 Day (01h..31h, BCD)
8-11 Month (01h..12h, BCD)
16-31 Year (0000h..9999h, BCD)
SWI 0Eh - GetBcdTime()
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)
SWI 13h - GetPtrToAlarmSetting()
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)
Games are usually using only the lower 16bit of the charset address, ORed with 04000000h (although the full 32bit is stored in RAM).
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
Pocketstation SWI Flash Functions
SWI 10h - FlashWritePhysical(sector,src)
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.
SWI 03h - FlashWriteVirtual(sector,src)
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).
SWI 0Ah - FlashReadSerial()
Returns the 32bit value from the two 16bit F_SN registers (see F_SN for
details).
SWI 0Fh - FlashWriteSerial(serial_number) ;old BIOS only!
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).
SWI 18h - FlashReadWhateverByte(sector)
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...?
Pocketstation SWI Useless Functions
SWI 00h - Reset() ;don't use, destroys RTC settings
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.
SWI 14h - GetPtrToPtrToSwiTable()
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).
SWI service routine
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)Pocketstation BU Command Summary
The Pocketstation supports the standard Memory Card commands (Read Sector,
Write Sector, Get Info), plus a couple of special commands.
BU Command Summary
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
Pocketstation BU Standard Memory Card Commands
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
BU Command 52h (Read Sector)
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).
BU Command 53h (Get ID)
The Get ID command (53h) returns exactly the same values as normal original
Sony memory cards.
BU Command 57h (Write Sector)
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)
Write Error Code FDh (Directory Entries of currently executed file)
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).
Write Error Code FEh (write-protected Broken Sector region, sector 16..55)
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.
Pocketstation BU Basic Pocketstation Commands
BU Command 50h (Change a FUNC 03h related value or so)
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)
BU Command 58h (Get an ID or Version value or so)
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)
BU Command 59h (Prepare File Execution with Dir_index, and Parameter)
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)
Caution: When dir_index=0000h, then \<param> should be a value that does NOT erase the RTC time/date (eg. 10h or 20h) (most other values do erase the RTC, see SWI 08h for details).
Upon dir_index=FFFEh, a similar request flag is set in ComFlags.30, and, the Kernel (not the GUI) does handle that request in its FIQ handler (however, the request is: To reset the RTC time/date and to start the GUI with uninitialized irq/svc stack pointers, so this unpleasant and bugged feature shouldn't ever be used). Finally, dir_index=FFFFh allows to read the current dir_index value (which could be also read via BU Command 5Ah).
BU Command 5Ah (Get Dir_index, ComFlags, F_SN, Date, and Time)
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)
BU Command 5Eh (Get-and-Send ComFlags.bit1,3,2)
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)
BU Command 5Fh (Get-and-Send ComFlags.bit0)
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)
Pocketstation BU Custom Pocketstation Commands
BU Command 5Bh (Execute Function and transfer data from Pocketstation to PSX)
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
BU Command 5Ch (Execute Function and transfer data from PSX to Pocketstation)
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
BU Command 5Dh (Execute Custom Download Notification Function)
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
FUNC 00h - Get or Set Date/Time (FUNC0)
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)
FUNC 01h - Get or Set Memory Block (FUNC1)
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
BUG: When sending more than 2 data bytes in the PSX-to-Pocketstation direction, then ADDR must be word-aligned (the BIOS tries to handle odd destination addresses, but when doing that, it messes up the alignment of another internal pointer).
FUNC 02h - Get or Set Alarm/Flags (FUNC2)
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
Test if the GUI is running, if so, restart it via Command 59h (with dir_index=0, and param=0120h or similar, ie. with param.bit8 set), then execute FUNC2, then restart the GUI again (this time with param.bit8 zero).
FUNC 03h - Custom Function 3 (aka FUNC3)
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)
Before using FUNC 03h one must somehow ensure that the desired file is loaded (and that it does have initialized the function address via SWI 17h, otherwise the pocketstation would crash).
The FUNC3 address is automatically reset to 0000h when (if) SWI 05h (SenseAutoCom) senses new docking.
Note: The POC-XBOO circuit uses FUNC3 to transfer TTY debug messages.
FUNC 80h..FFh - Custom Function 80h..FFh
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)
First Function Call (Pre-Data)
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)
src is read in 16bit units (and then split to 8bit units)
Second Function Call (Post-Data)
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).
Function flags (r0)
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 File Header/Icons
Pocketstation File Content
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)
Special "P" Filename in Directory Sector
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).
Special Pocketstation Entries in the Title Sector at [50h..5Fh]
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)
Memory Card Data Format
Snapshot Region (in "MCX1" Files only)
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
Function Table (FUNC 80h..FFh)
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)
For details see BU Commands 5Bh and 5Ch.
File Viewer Mono Icon
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)
Executable Mono Icon List
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 Executable Icons are shown in the Executable File Selection Menu (which occurs when pressing Left/Right buttons in the GUI). Pressing Fire button in that menu starts the selected executable. If the Icon List has more than 1 entry, then pressing Up/Down buttons moves to the previous/next entry (this just allows to view the corresponding icons, but doesn't have any other purpose, namely, the current list index is NOT passed to the game when starting it).
The Executable Mono Icon List is usually zero-padded to 80h-bytes size (although that isn't actually required, the following file Body could start at any location).
Entrypoint
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).
Returning to the GUI
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 File Images
Pocketstation files are normally stored in standard Memory Card images,
Memory Card Images
Pocketstation specific files
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.
Pocketstation .BIN Files ("SC" variant)
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.
Pocketstation .BIN Files ("SN" variant)
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).
Pocketstation XBOO Cable
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).
POC-XBOO Circuit
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)
POC-XBOO Upload
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.
POC-XBOO TTY Debug Messages
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
Note: The TTY messages are supported only in no$gba debug version (not no$gba gaming version).