stunt
New Member
Posts: 2
|
Post by stunt on Jun 5, 2007 18:50:47 GMT -5
there is a poketsation emulator out there I could give you a link to it if you want I THINK it is open sorces I want a pocketsation emulator for pocket digimon world I have a PocketStation, unopened though. I also have PDW but I can't play it because no Japanese PSone. Loading it up in the emulator works, but I need to plug-in my PocketStation, which I can't.
|
|
|
Post by grendel on Jun 11, 2007 11:31:31 GMT -5
I'm having a hard time understanding why this would need to be something implemented into the pSX code. Since a PocketStation is basically a memory card, any emulator would technically have the capability to read its data. So what you're looking for is an indepedent emulator for PocketStation, right? (because it runs games independently) I'll do some research and see if I can find any such thing. EDIT: Let's give this a try.
|
|
|
Post by patrickp on Jun 11, 2007 12:36:13 GMT -5
No, I think what people are asking for _is_ a PocketStation built-in to pSX, grendel. There is a serious lack of information about the workings of the PocketStation (see comments earlier in this thread and, particularly, the other threads linked by Ultima). There is only one known emulator, PKEmu, the one you linked to and which was linked to earlier in this thread and in other threads referenced. Unfortunately, it's regarded as being less than complete and is, apparently, not reliable or easy to get working - I've never tried it myself. It's been around for a while and is not in development.
Hence, the requests are not simply for pSX to support an external PocketStation emulator - they're for pSX to include a PocketStation emulator, since there isn't a good one. Nice idea, but not likely to happen. See the Known Requests thread (i.e. these things have already been more than adequately requested) linked at the top of the page:
|
|
|
Post by f1reb4ll on Jun 14, 2007 7:27:42 GMT -5
I'm having a hard time understanding why this would need to be something implemented into the pSX code. Since a PocketStation is basically a memory card It's not just a memory card, it's more likely to be an another input device for some games (ex. Love Hina 1, Love Hina 2 - they won't run without PocketStation attached).
|
|
|
Post by viperzerofsx on Jun 21, 2007 15:42:48 GMT -5
say I bought a pocketstation what could I do to help if I don't know alot about this sort of things
|
|
|
Post by Ultima on Jun 22, 2007 7:37:18 GMT -5
Dunno, but I'd say... you wouldn't be able to do much unless you send it to someone who knows what to do with the device to analyze it and obtain the needed details. It'd likely require some specialized equipment, I'd imagine.
|
|
|
Post by viperzerofsx on Jun 25, 2007 18:46:36 GMT -5
|
|
|
Post by Ultima on Jun 28, 2007 8:19:54 GMT -5
Not exactly easy to determine without being able to read Japanese...
|
|
|
Post by viperzerofsx on Jul 1, 2007 17:45:02 GMT -5
I could get a google translation
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jul 2, 2007 13:00:56 GMT -5
Because machine translations are notoriously good.
|
|
|
Post by patrickp on Jul 2, 2007 13:45:45 GMT -5
Reminds me of the story about machine translation way back when - I heard it in the 60s I think - some researchers built a computer to translate between English and Russian. The first phrase they fed in came out as 'invisible idiot.' Apparently the phrase went in as 'out of sight, out of mind...' Don't know if it's true.
|
|
|
Post by viperzerofsx on Jul 2, 2007 18:43:23 GMT -5
i know it sucks but you get the idea what it means
|
|
|
Post by Ultima on Jul 3, 2007 16:02:14 GMT -5
The "translation" itself needs translation. At any rate, there doesn't appear to anything useful on the page, if the translation is any indication.
|
|
dlsmd
New Member
Posts: 5
|
Post by dlsmd on Dec 15, 2007 12:49:06 GMT -5
heres some info on th pocket station All information in this document has been personally verified on a real Pocketstation by me, Exophase (exophase@gmail.com) unless otherwise noted. Two other documents were used to help me find this information; these can be found at the following locations:
http://web.archive.org/web/20010719040543/ www.cs.jhu.edu/~fezzik/virtualboy/pocketstation.html
(remove linebreak)
http://onorisoft.info/ (see Pocketstation section)
PocketStation memory map:
The region is defined by the bits at 23 through 27 of an address.
Regions:
0x00 - 0x08 RAM 0x10 - 0x18 open 0x20 Current ROM bank 0x28 - 0x38 open 0x40 - 0x48 BIOS 0x50 - 0x58 open 0x60 - 0x68 ???? 0x70 - 0x78 open 0x80 - 0x88 Full ROM 0x90 - 0x98 open 0xA0 IRQ 0xA8 Timers 0xB0 CPU clock 0xB8 RTC 0xC0 ??? 0xC8 IRDA 0xD0 video 0xD8 audio/misc hardware 0xE0 - 0xF8 open
Reading to an open region will cause the machine to freeze; it possibly signals a data abort exception which goes into an infinite loop in the BIOS code.
Unknown regions:
There are some unknown regions that are used, however these functions probably exist but there's no lead on them, yet.
- How to change the ROM bank. Might involve writing to the ROM space. - How to light up the LED. - How flash is written to.
0x0: RAM:
0x000 through 0x800 is available. Higher addresses are mirrored every 2KB. 0x200 and below is used for the BIOS.
The BIOS will set up two stacks, initially at: 0x180 IRQ sp 0x200 FIQ sp
The following global locations are used by the BIOS code:
0x000 - 0x020 Exception vector table (copied from BIOS at 0x040001d0) 0x0C0 - 0x0CF Some important system structure is here. 0x0D0 Exec setting 0x0D8 Some other structure starts here. 0x0E0 Pointer to SWI function table 0x0F8 SWI hook pointer (for SWI 2) 0x0FC IRQ hook pointer 0x100 FIQ hook pointer 0x104 unknown hook pointer
0x2: Current ROM bank:
This is where the currently selected game resides. It's unknown if this is actually bank switched in from ROM (and if so, how), but this is much more likely than the alternative (that it's copied).
The current ROM bank occupies the space from 0x2000000 to 0x2001FFF. Reading outside of this area seems to cause the machine to freeze as it would if reading open regions.
Only 16 and 32bit quantities may be read properly. It's likely that ROM is ported on a 16bit bus.
Although this is flash ROM, it's not directly writeable. (There's probably a way to write to it indirectly)
0x4: BIOS
The BIOS occupies the space from 0x4000000 to 0x4007FFF. It is mirrored afterwards for every 32KB.
0x6: ????
It's currently unknown what this region's purpose is. Although the BIOS setup code freely writes to values in this region, it appears to be read only from within the game code (might depend on CPU mode for access?). Flash writing code seems to have some connection.
0x8: Full ROM
Contains direct access to the full ROM from 0x8000000 to 0x801FFFF. Mirrors every 128KB afterwards. Most likely has the same restrictions as the 0x2 region.
0xA0: IRQ
IRQ/control:
Each IRQ register has a bit mask corresponding to the available IRQs.
0xA000000: IRQs currently triggered 0xA000004: Raw status 0xA000008: Which IRQs are enabled 0xA00000C: Disable IRQs (write only) 0xA000010: IRQ service signal (write only)
Reading outside the readable region seems to return whatever 0xA000008 returns.
The raw status word contains the current status of the buttons and the heartbeat. They're in the same positions as their corresponding interrupts.
Interrupts: The following bits correspond to an interrupt line. So, when that interrupt is triggered, that bit will be high in the IRQ trigger register. Also, you must explicitely enable these bits in the enable register, and can disable them afterwards in the disable register.
Note: Enabling IRQs for the buttons seems to make it impossible to poll them.
Mask purpose 0x001 Action button 0x002 Right button 0x004 Left button 0x008 Down button 0x010 Up button 0x080 Timer 0 interrupt 0x100 Timer 1 interrupt 0x200 RTC "Heartbeat" interrupt 0x400 Timer 2 interrupt 0x800 Communication interrupt
The button interrupts are triggered by the 5 buttons, naturally.
The RTC interrupt I've named "heartbeat" because I correlate it with the heart beating in the GUI interface (although it's likely it has nothing to do with it). It's a square wave with varying duty cycles that can be changed in register 0xB800000.
The timer interrupts are triggered by the timers, if enabled.
The communication interrupt is triggered by the PS1/PS2 BIOS, or so it would seem; plugging it in causes this interrupt to fire.
0xA8: Timers
0xA800000: Timer 0 period 0xA800004: Timer 0 current value 0xA800008: Timer 0 control 0xA800010: Timer 1 period 0xA800014: Timer 1 current value 0xA800018: Timer 1 control 0xA800020: Timer 2 period 0xA800024: Timer 2 current value 0xA800028: Timer 2 control
The period value is a 16bit integer that determines when the timer wraps around. The timer will start at the max value and be decremented, until it hits 0. At this point it will trigger an interrupt and reset to the period value.
The current value contains where in the timing cycle the timer is at.
Repeated tests using the RTC strongly suggest this information to be at least roughly accurate, but it might not be.
All of the timers seem to run based off of a global clock that's roughly 2MHz. The clocks can then be set with a given divider N that makes it count down once every N cycles.
The control word is arranged as follows:
bits 0-1: Timer divider 00: 1 (2MHz) 01: 16 (128KHz) 02: 256 (8KHz) 03: Same as timer 1.
bit 2: Timer enable/disable This will start/stop the timer. This bit must be off for writes to the period to take effect, otherwise they'll be ignored.
Timer interrupts: The timers will automatically raise interrupts if they're enabled, there's no need to set a bit anywhere for IRQs (but you need to enable the respect interrupts in the IRQ control).
0xB0: CPU Clock
This region contains hardware registers for controlling the internal CPU clock as well as interfacing with the builtin real-time clock.
0xB000000: Writing to the bits 0-2 of this register appears to change the base clock speed. The higher the value, the faster: 0x7 is what the BIOS defaults to. 0x0 is very slow. The change in rate appears to be exponential, so 0x7 should be 128 times faster than 0x0.
Note that this changes the internal clock that appears to drive both the timer and the CPU. Since the timer was measured to be 2MHz with this value at 0x7, it's very likely that the CPU is also 2MHz, or a multiple of it (but based on tests ran 2MHz is likely, possibly 4MHz, depending on wait states in memory).
If a 0 is written to bit 3 then it will be made high again. Behavior in the BIOS seems to indicate that this does not happen immediately, but after a time interval. It might indicate that the change in clock speed has taken effect.
0xB8: RTC
The time of day/date values are stored in packed BCD, where a single decimal digit is stored in a 4bit nibble. Thus, a byte stores a value from 0 to 99, and you can read off the values from a hex printout of them.
0xB8000000: RTC control word
The RTC control word controls the operation of the RTC. It is 4bits long. Bit 0: 0 means RTC is running, 1 means RTC is paused Bits 1 - 3: Seems to vary the duty cycle of the "heartbeat" counter. And is likely also connected to which value you can modify. 0x7 here likely means that you can't modify.
0xB8000004: Modify value (write only) Writing a value here seems to increment the current selected parameter (by the RTC control) by 1. Maybe by N, whatever N is. This is unclear. What is perhaps clear is that you have to wait for the heartbeat to go low before writing to this.
0xB8000008: Time of day + day of week (read only) Byte 0: Seconds Byte 1: Minutes Byte 2: Hours Byte 3: Day of week (1 = Monday, 7 = Sunday)
0xB800000C: Date (read only) Byte 0: Day of month (1 through 31) Byte 1: Month (1 through 12) Bytes 2 - 3: Year (BIOS seems to only store bottom two digits)
Reading other locations seem to mirror 0xB8000008.
0xC0: ???
0xC8: IRDA
(see pocketstation.html for now)
0xD0: LCD
0xD0000000: LCD control word
The LCD control word controls the operation of the LCD screen. It is 8 bits long.
Bits 0 - 2: Draw mode; seems to turn off bits of the screen; these are not necessarily all correct. 0x0: All on 0x1: First 8 rows on 0x2: Second 8 rows on 0x3: Third 8 rows on 0x4: Fourth 8 rows on 0x5: First 16 rows on 0x6: Middle 16 rows on (rows 8 through 23) 0x7: Bottom 16 rows on
Bit 3: "CPEN", this bit should be on. Turning it off seems to do some weird fade out of the screen.
Bits 4 - 5: Refresh rate. Higher modes have lower refresh, as can be seen by the screen appearing lighter. Mode 0x00 shouldn't be used. The timings have not been measured (need to see if there's a vsync flag somewhere); these are taken from another source or assumed.
0x0: Makes a single blue (yes, blue, yes, on a black/white display) line appear at the top or middle of the screen. 0x1: 64Hz? (might be 32Hz like 0x2) 0x2: 32Hz 0x3: 16Hz
Bit 6: Display active (1 for on, 0 for off) Bit 7: Rotate display 180 degrees
0xD000100 - 0xD00017F: LCD buffer. One word (32 bits) corresponds to a scanline, for 32 scanlines. This area seems to be repeated in the lower part of this region in some way, possibly only partially.
0xD8: Peripheral hardware control/sound
(see Orion's doc for now)
SWI:
The BIOS has a standard SWI interface. Some are implemented in ARM code, but most are implemented in Thumb (I haven't reversed many of the Thumb ones yet). The following information is somewhat known, a bit incomplete and speculative right now:
SWI 0: sys_reset This goes straight to the reset vector of the CPU.
SWI 1: sys_handler Specify a handler to use for SWI, IRQ, and FIQ (and something else?). r0 specifies the handler (in the above order), and r1 has a pointer to the function. SWI doesn't involve an actual SWI handler hook - see SWI 2.
SWI 2: sys_custom Call the custom function set by SWI 1.
SWI 3: sys_save Save RAM to flash. Uses the 0x6000000 range.
SWI 4: sys_clock Set internal clock speed, given in r0. Returns the previous clock speed in r0.
SWI 5: May have to do with PS1/PS2 communication, since it checks 0x800 of the poll register.
SWI 6: sys_c0 Returns 0xc0, which appears to be a pointer to a system structure.
SWI 7: sys_set_c0 Bits 17 - 19 of [0xc0] are set to r0.
SWI 10: sys_rd6 Returns the word at [0x6000300]
SWI 11: sys_clr11_c0 Clears bit 11 in [0xc0].
SWI 13: sys_date Returns the date in the standard format (see RTC section).
SWI 14: sys_time Like SWI 12, but returns the time instead.
SWI 19: sys_d8 Returns 0xd8, which is perhaps another system structure pointer.
SWI 20: sys_swi_ptr Returns 0xe0 - this is a pointer to the SWI function table. If you change this you can write an entire set of your own SWIs (but would you really want to do such a thing??)
SWI 22: sys_appnum Returns [0xd0], or if [0xd0] == 0 returns [0xce].
SWI 23: sys_c8 Returns 0xc8, which is perhaps another system structure pointer.
SWI 24: sys_rdrom Returns something in ROM, the halfword at [(r0 << 7) + 0x0800007e] to be exact. i am not Exophase tho i have sent him an email about this quoted code placed in code brackets to prevent symbols being shown as smilies - patrickp
|
|
dlsmd
New Member
Posts: 5
|
Post by dlsmd on Dec 16, 2007 13:27:00 GMT -5
thanks patrickp for doing that for me i didnt know that symboles were shown as smiles
|
|