Datel's VMEM Addon (other questions too)

General information to do with the PlayStation 1 Hardware. Including modchips, pinouts, rare or obscure development equipment, etc.
User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Datel's VMEM Addon (other questions too)

Post by CyrusDevX » August 8th, 2015, 4:59 am

UPDATE: 9/27/15
School has slowed down a bit, so i actually have time to spend here on psxdev.net ^^. I've already have been studying how to manipulate hardware in C and a few ways to properly write c. Its been very fun for me and now that i have time im starting back up on SIOFlash. I've already cleaned my old source of all the silly stuff i tried. And with working pointers XD.

Ill be back here later today with a follow up. Cheers
I'll start with my setup and then explain further were im at as of now and what my goal is:

My hardware:
7501 PU-22 PS1, with a Mayumi V4 PIC chip i flashed and installed. I also have a working USB SIOCON capable cable(uses all hw handshaking) with a PSXSERIAL v1.3 disc.

Goal:
So i have been messing around with the ps1, and doing some C and minor ASM programming, etc. And i have this old vmem hardware and i know its similar to the GS type PIO cards. My Goal is to find a way to load XFLASH over serial while using the pc as the storage media to load the firmware from, so i can flash unirom on the vmem. The reason for not just burning a cdr is due to the fact im really low on $ and not going to buy more cdr's. So i kinda made this difficult for myself. But i have loaded XFLASH over SIO and discovered it has 128kb flash rom thats detectable within xflash. Im assuming its possible to load unirom onto the device. Idc about the LPT port access because i have a SIO cable etc.

So basically im trying to flash my PIO card completely over SIO. Is this possible, or could be possible with changes to certain software?

Also i should mention i attempted to dump the 12c508 MCU on the vmem directly with my k150 programmer, i detects the chip but im sure it has code protection on so the chip displays 0's. Also if there is some documentation on the software side of the PIO port, i would love to get my greedy hands on it lawl ^^.
Some Pics: These are linked so u can see them better on the img host
Image
Image
Last edited by CyrusDevX on September 28th, 2015, 4:15 am, edited 2 times in total.

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 9th, 2015, 1:38 am

The Parallel prt is is a sort of a faux name. It's really an expantion port. Any device connected to this port
will have access to everything on the local bus. The address that the PIO port resides on is from 0x1f00_0000-
0x1f00_ffff The following is a pin diagram of the PIO.

0x1f80_10d0 DMA channel 5 PIO


Expansion 1 Base Address (usually 1F000000h)

1F000000h-1F01FFFFh R/W Flash (first 128K)
1F020010h R Comms Link STB pin state (bit0)
1F020018h R Switch Setting (bit0: 0=Off, 1=On)
1F040000h-1F05FFFFh R/W Flash (second 128K) + feedback area (see below)
1F060000h R Comms Link data in (byte)
1F060008h W Comms Link data out (byte, pulses ACK to Comms Link)
This is some info i pulled from http://problemkaputt.de/psx-spx.htm

Now that i got the address for the full 128K flash on the vmem, im going to attempt to program a small application with my rom of choice encoded into the exe. Should writing directly to those addresses via memcpy or something be sufficient? i want to minimize the use of ASM because its not my forte.

EDIT: obv memcpy doesnt work XD, now that i think about it im sure theres a lot that goes into flashing a PIO Card native on the ps1....
Last edited by CyrusDevX on August 9th, 2015, 3:16 am, edited 1 time in total.

User avatar
CosmoGuy
Serious PSXDEV User
Serious PSXDEV User
Posts: 91
Joined: May 30, 2012
I am a: Hell knows who I am
PlayStation Model: SCPH-7502
Location: Polska, Wroclaw
Contact:

Post by CosmoGuy » August 9th, 2015, 2:30 am

Whoa cool stuff dude :D

Keep doing that, i've also had on my mind making such reprogrammable "diskette" with EPROM just to test my demos.
However i cannot help you yet :/, sorry.

Regards.
Image

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 9th, 2015, 3:19 am

CosmoGuy wrote:Whoa cool stuff dude :D

Keep doing that, i've also had on my mind making such reprogrammable "diskette" with EPROM just to test my demos.
However i cannot help you yet :/, sorry.

Regards.
lol its okey if u cant help as of now. im kinda stuck were im at for now, until i can figure out what methods and function i need to properly erase and burn a new img to the vmem ^^
You do not have the required permissions to view the files attached to this post.

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 9th, 2015, 11:35 am

I think i figured out another way to add external storage to the psx.

Code: Select all

#include <stdio.h>
#include <sys/file.h>
#include <sys/types.h>
#include <kernel.h>
#include <libgte.h>
#include <libgpu.h>
#include <libetc.h>
#include <libapi.h>
#include <libmcx.h>

/*
    from BlackBag/Nagra PSX

    0x1f801040 - unsigned char data;
    0x1f801044 - unsigned short status;
    0x1f80104a - unsigned short cntl;
    0x1f80104e - unsigned short baud; not used???
*/

#define SIO_DATA(x)     *((unsigned char*)(0x1f801040 + (x<<4)))
#define SIO_STATUS(x)   *((unsigned short*)(0x1f801044 + (x<<4)))
#define SIO_CTRL(x)     *((unsigned short*)(0x1f80104a + (x<<4)))
#define SIO_BAUD(x)     *((unsigned short*)(0x1f80104e + (x<<4)))

//TODO: Figure out SPI protocol and implement.
//Build hardware interface for psx from gamepad
//port to store the spi flash ic for data storage.

int main() {
	
	PadInit();
	McxStartCom();
	
	
	return 0;
}
thats what i have so far. i have several spi flash ic laying around. i have 128kb ic from microchip that i might try this on ^^. it'll be challenge for me. But i also could be wrong.

User avatar
sickle
Verified
C Programming Expert
C Programming Expert
Posts: 257
Joined: Jul 17, 2013
I am a: Chocolate-fueled pug fetish robot.
Location: Scotland

Post by sickle » August 9th, 2015, 5:16 pm

Tricky one, but I've wondered this also - would be nice if there was a "R1 - COPY MAIN MEM TO EEPROM" or similar.
The XFlash .exe decompiles quite cleanly in IDA, so maybe you could find a way to upload the ROM elsewhere into RAM first then patch XFlash to use that RAM instead of its own buffer right before flashing?

I'd probs do that over rewriting XFlash 'cause of the sheer amount of work involved :p

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 9th, 2015, 11:35 pm

sicklebrick wrote:Tricky one, but I've wondered this also - would be nice if there was a "R1 - COPY MAIN MEM TO EEPROM" or similar.
The XFlash .exe decompiles quite cleanly in IDA, so maybe you could find a way to upload the ROM elsewhere into RAM first then patch XFlash to use that RAM instead of its own buffer right before flashing?

I'd probs do that over rewriting XFlash 'cause of the sheer amount of work involved :p
wow thanks ^^. i have IDA so ill see what i can do.

Found these in 2 subroutines in IDA: Idk but it looks like exp1 control of some sort.

Code: Select all

sub_8001242C:

var_10= -0x10
var_C= -0xC
var_8= -8

addiu   $sp, -0x20
sw      $s1, 0x20+var_C($sp)
li      $s1, 0xAA
sw      $s0, 0x20+var_10($sp)
li      $s0, 0x55
lw      $a0, 0x48($gp)
li      $v0, 0x90
sw      $ra, 0x20+var_8($sp)
sb      $s1, 0x1F005555
sb      $s0, 0x1F002AAA
sb      $v0, 0x1F005555
jal     sub_800124C4
nop
lw      $a0, 0x48($gp)
lbu     $v1, 0x1F000000
lbu     $a1, 0x1F000001
li      $v0, 0xF0
sb      $s1, 0x1F005555
sb      $s0, 0x1F002AAA
sb      $v0, 0x1F005555
sb      $v1, 0x40($gp)
sb      $a1, 0x41($gp)
jal     sub_800124C4
nop
lw      $ra, 0x20+var_8($sp)
lw      $s1, 0x20+var_C($sp)
lw      $s0, 0x20+var_10($sp)
addiu   $sp, 0x20
jr      $ra
nop

##################

sub_80012800:
lui     $v1, 0x1F00
lbu     $v0, 0x1F001823
lbu     $v0, 0x1F001820
lbu     $v0, 0x1F001822
lbu     $v0, 0x1F000418
lbu     $v0, 0x1F00041B
lbu     $v0, 0x1F000419
lbu     $v0, 0x1F00041A
jr      $ra
nop

EDIT: XFLASH allocates RAM from 0x8001F000 to 0x801FFFFF.

EDIT2: Ok so looking into the xflash program i figured out theres a check for the rom size per eeprom chip it detect, this is obvious. But some PIO cards have a larger ic then 128KB, and the amount of allocated ram from xflash is about 247KB. The actual xflash program ends in memory at 0x8001EAEC then jumps to 0x8001F000 for what i think is the location in memory for the rom buffer. ^^ let me know the deal here someone haha.

EDIT3: I might just end up flashing one of my other 29LE010 ic's and swap it for the one on the vmem.

User avatar
sickle
Verified
C Programming Expert
C Programming Expert
Posts: 257
Joined: Jul 17, 2013
I am a: Chocolate-fueled pug fetish robot.
Location: Scotland

Post by sickle » August 10th, 2015, 4:47 pm

By graphing the XRefs from the first sub_ you mentioned, I found the "Press O to retry" menu, (ANDs against 0x20 from a pad read)... just to double check.
That returns to 0x8001327B

That itsself is called from 0x80012D74, which I would assume is the start func
(It's called various times after checking the CD, comms from the main menu, press X to continue, etc)

So I guess if it helps any, here's
0x80012D74 and 0x80013278 to follow for more clues?

I'm not entirely sure what those subrs you listed do, 'cause really I have no idea how those chips are flashed :\ Do you send them a sequence of commands and they suddenly become readwrite? Or do you point the chip at a memory location and say "copy this"?

That second sub is definitely writing to $1f00xxxx though, which under most circumstances is readonly, so yeah maybe 1f00555F and 1f002AAA are registers to enable writing?

I would have thought it'd be like:
$1F060000 = The on/off switch
$1F060001 = Read/Write on the Parallel port
$1F060002 = handshake

That second one is called much later than the "retry" menu, so this might be a final kinda "we're done writing" command?

Ooh, while I remember, IIRC when XFlash is dumping ROM to memory it generally goes from exactly 1MB into the main RAM. I'd wager that that's where it stores it before flashing.

Love to know if you get this working either way :D

Edit:
Some info here which might help on the various ports, might make things a bit easier to read?
http://problemkaputt.de/psx-spx.htm
You could also use no$PSX to test changes I guess?

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 10th, 2015, 11:45 pm

sicklebrick wrote: So I guess if it helps any, here's
0x80012D74 and 0x80013278 to follow for more clues?
You my friend have provided me with a far better understanding of where im at ^^ cheers! Oh and yes eeproms or flash ic's have a cmd to enable write and so forth. its specific to a series of the ic's. So all i need to do is figure out a way to load the rom into ram prior to the xflash application, then patch the cd function to instead goto my roms location in memory and then probably hook back into the xflash app and return to the functions used to physically flash the ic. i think... lol

EDIT: Well i've been at this all morning so far lol(starting with your clues ^^) I went ahead and got no$psx (thanks nocash ^^), and havent used it much as of now. I will use it when testing the patches. But so far i've stumbled cross these subroutines.
  • LoadTPage = 80013504
  • LoadImage = 8001484C
  • StoreImage = 800148AC w/ Subroutine @ 80014608
  • MoveImage = 8001490C w/ Subroutine @ 80014608
These subs are interesting to me, though im still not 100% sure if im heading in the right direction? But "image" could be the rom img or some graphics on xflash... which it seems to have a minute amount of. Also Store and Move Image subs share the same nested 80014608 sub.

Heres the 80014608 Subroutine:

Code: Select all

TEXT:80014608
TEXT:80014608  # =============== S U B R O U T I N E =======================================
TEXT:80014608
TEXT:80014608  # Attributes: library function
TEXT:80014608
TEXT:80014608 sub_80014608:                            # CODE XREF: TEXT:80014754p
TEXT:80014608                                          # TEXT:800147E4p ...
TEXT:80014608
TEXT:80014608 var_10          = -0x10
TEXT:80014608 var_8           = -8
TEXT:80014608 var_4           = -4
TEXT:80014608
TEXT:80014608                 addiu   $sp, -0x20
TEXT:8001460C                 move    $t0, $a0
TEXT:80014610                 sw      $s0, 0x20+var_8($sp)
TEXT:80014614                 la      $a0, byte_8001D366
TEXT:8001461C                 sw      $ra, 0x20+var_4($sp)
TEXT:80014620                 lbu     $v1, (byte_8001D366 - 0x8001D366)($a0)
TEXT:80014624                 li      $v0, 1
TEXT:80014628                 beq     $v1, $v0, loc_80014644
TEXT:8001462C                 move    $s0, $a1
TEXT:80014630                 li      $v0, 2
TEXT:80014634                 beq     $v1, $v0, loc_800146D0
TEXT:80014638                 nop
TEXT:8001463C                 j       loc_80014714
TEXT:80014640                 nop
TEXT:80014644  # ---------------------------------------------------------------------------
TEXT:80014644
TEXT:80014644 loc_80014644:                            # CODE XREF: sub_80014608+20j
TEXT:80014644                 lh      $a1, 4($s0)
TEXT:80014648                 lh      $v1, (word_8001D368 - 0x8001D366)($a0)
TEXT:8001464C                 nop
TEXT:80014650                 slt     $v0, $v1, $a1
TEXT:80014654                 bnez    $v0, loc_800146C4
TEXT:80014658                 nop
TEXT:8001465C                 lh      $a3, 0($s0)
TEXT:80014660                 nop
TEXT:80014664                 addu    $v0, $a1, $a3
TEXT:80014668                 slt     $v0, $v1, $v0
TEXT:8001466C                 bnez    $v0, loc_800146C4
TEXT:80014670                 nop
TEXT:80014674                 lh      $v1, 2($s0)
TEXT:80014678                 lh      $a0, (word_8001D36A - 0x8001D366)($a0)
TEXT:8001467C                 nop
TEXT:80014680                 slt     $v0, $a0, $v1
TEXT:80014684                 bnez    $v0, loc_800146C4
TEXT:80014688                 nop
TEXT:8001468C                 lh      $a2, 6($s0)
TEXT:80014690                 nop
TEXT:80014694                 addu    $v0, $v1, $a2
TEXT:80014698                 slt     $v0, $a0, $v0
TEXT:8001469C                 bnez    $v0, loc_800146C4
TEXT:800146A0                 nop
TEXT:800146A4                 blez    $a1, loc_800146C4
TEXT:800146A8                 nop
TEXT:800146AC                 bltz    $a3, loc_800146C4
TEXT:800146B0                 nop
TEXT:800146B4                 bltz    $v1, loc_800146C4
TEXT:800146B8                 nop
TEXT:800146BC                 bgtz    $a2, loc_80014714
TEXT:800146C0                 nop
TEXT:800146C4
TEXT:800146C4 loc_800146C4:                            # CODE XREF: sub_80014608+4Cj
TEXT:800146C4                                          # sub_80014608+64j ...
TEXT:800146C4                 lui     $a0, 0x8001
TEXT:800146C8                 j       loc_800146D8
TEXT:800146CC                 la      $a0, aSBadRect   # "%s:bad RECT"
TEXT:800146D0  # ---------------------------------------------------------------------------
TEXT:800146D0
TEXT:800146D0 loc_800146D0:                            # CODE XREF: sub_80014608+2Cj
TEXT:800146D0                 la      $a0, aS          # "%s:"
TEXT:800146D8
TEXT:800146D8 loc_800146D8:                            # CODE XREF: sub_80014608+C0j
TEXT:800146D8                 lw      $v0, off_8001D360
TEXT:800146E0                 nop
TEXT:800146E4                 jalr    $v0
TEXT:800146E8                 move    $a1, $t0
TEXT:800146EC                 lh      $a1, 0($s0)
TEXT:800146F0                 lh      $a2, 2($s0)
TEXT:800146F4                 lh      $a3, 4($s0)
TEXT:800146F8                 lh      $v1, 6($s0)
TEXT:800146FC                 lw      $v0, off_8001D360
TEXT:80014704                 la      $a0, aDDDD       # "(%d,%d)-(%d,%d)\n"  //Reminds me of *nix DD cmd//
TEXT:8001470C                 jalr    $v0
TEXT:80014710                 sw      $v1, 0x20+var_10($sp)
TEXT:80014714
TEXT:80014714 loc_80014714:                            # CODE XREF: sub_80014608+34j
TEXT:80014714                                          # sub_80014608+B4j
TEXT:80014714                 lw      $ra, 0x20+var_4($sp)
TEXT:80014718                 lw      $s0, 0x20+var_8($sp)
TEXT:8001471C                 jr      $ra
TEXT:80014720                 addiu   $sp, 0x20
TEXT:80014720  # End of function sub_80014608
It would be extremely helpful if i could just take one of the asm lines with offsets and do something to calculate what the variable locations are for "lw $s0, 0x20+var_8($sp)" etc. That would better help me understand whats actually going on in these blocks of instructions. No$PSX seems to do this auto, but im looking for "manual or paper" method to get the locations referenced in these instructions.

The fact is ASM and im still a newb with this hardware and what not lol. I've been making some serious effort on learning from nocash's extremely adv documentation on the psx. I have never seen something as detailed and complex as that documentation XD. gj nocash ^^

EDIT2: http://problemkaputt.de/psx-spx.htm#mod ... xbooupload
Thats epic nocash. I will be ordering "samples" from Microchip for SST39SF020A-70-4C-PHE && SST39SF040-70-4C-PHE. I plan on making a daughter board for my unit with 1x SST39SF020 && 1x SST39SF040 with a selector switch for /CE. Ill also be making the 74HC541 + DB25 board to add to the first daughter board when i can get some 74HC541's(or just find a PDIP of a Parallel to USB transceiver). Also i will be acquiring SCN2681 ic's for EXP2, and i plan on having the EXP2 internal & might even add a USB Transceiver.

From my experience with hardware development (in which 90% of my work experience has been with embedded systems), nothing is "impossible" but its simple as knowing your requirements for interfacing and with proper implementation from that perspective; Its "possible" to create an extensive "collection" of additional hardware for anything really. But the neat thing here is the psx has several (at least 3) methods of adding additional hardware; To expand upon the the original "legacy" hardware it already contains.

EDIT3: https://docs.google.com/document/d/1Fal ... sp=sharing

Link to a Possible PIO Card project i conceived ^^.

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

Post by nocash » August 11th, 2015, 6:09 am

CyrusDevX wrote:Found these in 2 subroutines in IDA: Idk but it looks like exp1 control of some sort.

Code: Select all

sw      $s1, 0x20+var_C($sp)
li      $s1, 0xAA
sw      $s0, 0x20+var_10($sp)
li      $s0, 0x55
lw      $a0, 0x48($gp)
li      $v0, 0x90
sw      $ra, 0x20+var_8($sp)
sb      $s1, 0x1F005555
sb      $s0, 0x1F002AAA
sb      $v0, 0x1F005555
That 5555 and 2AAA stuff is common for writing to flash memory, check the datasheet for the flash chip (in case you haven't already done so).

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 11th, 2015, 7:14 am

nocash wrote:
CyrusDevX wrote:Found these in 2 subroutines in IDA: Idk but it looks like exp1 control of some sort.

Code: Select all

sw      $s1, 0x20+var_C($sp)
li      $s1, 0xAA
sw      $s0, 0x20+var_10($sp)
li      $s0, 0x55
lw      $a0, 0x48($gp)
li      $v0, 0x90
sw      $ra, 0x20+var_8($sp)
sb      $s1, 0x1F005555
sb      $s0, 0x1F002AAA
sb      $v0, 0x1F005555
That 5555 and 2AAA stuff is common for writing to flash memory, check the datasheet for the flash chip (in case you haven't already done so).
Sweet! ^^ Thanks nocash!

//trying to shorten my posts
And if its possible could you provide any example on the "method" i should hook into the segment:offsets? Like it doesnt need to be a full function / prototype, just more specifically what kernel and or bios calls (in C) i should be working with.

^^^^^ disregard this for now lol. Im doing a lot more research on the "in's and out's" of working directly with memory locations in C. I'm also reading the datasheet for values of the ic's cmd's etc for control.
OK SO! I kinda (ithinklol) figured out what should be going on in C.
So i need the page size and page count defined. Then need to reference the segment:offsets with a loop of some sort in correspondence with the page size and count. Then read from the location in memory to verify there is a eeprom attached. Continue with "unlocking the chip" for data write, then through a C function like memcpy or similar write the data to "memory" but that memory is actually the eeprom ^^ ! im getting close woot! :dance

EDIT: Wow i should have looked at the datasheet XD! Im silly... thanks for the subconscious reminder nocash lol
Image

I'm rapidly beginning to understand the aspects of the psx. Even before i made my account here, my "understanding" of the game console scene's hardware versus my normal embedded work seemed to be at a large disconnect. But unlike like PIC32's, ARM linux boards and random side projects or products i would develop; The psx for example just seemed to be a different "breed" of what i would work on. I now realize at the root of what they actually are and how they work, is all the same. Just a different way of operating different things. Im so motivated lol ^^

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 11th, 2015, 10:59 am

SIOFlash pre-alpha: Updated : 9:17 EST 8/10/15

Test With extreme caution, there is an erase function in the menu now. works for 29LE010 EEPROM's atm.

Code: Select all

#include <stdio.h>
#include <sys/file.h>
#include <sys/types.h>
#include <kernel.h>
#include <libgte.h>
#include <libgpu.h>
#include <libetc.h>
#include <libapi.h>
#include <strings.h>
#include <memory.h>

#define PAGESIZE 128
#define PAGES 1024  

u_long	pad;

char *cmd1 = (char *)0x1F005555;
char *cmd2 = (char *)0x1F002AAA;
char *checkBase = (char *)0x1F000004;
int checkBSize = 44;
int check = 1;
char data;

void eraseFlash();
void readFlash();
void Menu();
void checkPIO();
void clearScreen();
void init();

char *FlashRom[PAGES][PAGESIZE];

int main() {
	
	init();
	
	PadInit(0);
	
	FntPrint("\nLoading SIOFlash...\n");
	FntPrint("\nPress X To Continue.\n");
	FntFlush(0);
	
	while(1) {
		
		pad = PadRead(0);
		VSync(0);
		
		if (pad & PADRdown) {
			break;
		}
	}
	
	while(1) {
		
		pad = PadRead(0);
		VSync(0);
		
		if (!(pad & PADRdown)) {
			
			Menu();
			//break;
		}
		
	}
	
	
	return 0;
}

void eraseFlash() {
	
	clearScreen();

	FntPrint("\nROM Erase Menu\n");
	FntPrint("\nONLY PRESS X TO ERASE ROM!!!\n");
	FntPrint("\nPress O To Return to Main Menu\n\n");
	
	while(1) {
		
		pad = PadRead(0);
		VSync(0);
		
		if (pad & PADRright) {
			Menu();
		}
		
		if (pad & PADRdown) {
			break;
		}
	}
	
	FntPrint("\nErasing ROM!\n");

	data = 0xAA;
	memset(cmd1, data, sizeof(data));
	data = 0x55;
	memset(cmd2, data, sizeof(data));
	data = 0x80;
	memset(cmd1, data, sizeof(data));
	data = 0xAA;
	memset(cmd1, data, sizeof(data));
	data = 0x55;
	memset(cmd2, data, sizeof(data));
	data = 0x10;
	memset(cmd1, data, sizeof(data));
	
	FntPrint("\nErase Complete!\n");
	FntFlush(0);
	
}

/*
void readFlash() {
	
	int i;
	int y;
	
	for (i = 0; i < PAGESIZE; i++) {
		
		
		for (y = 0; y < PAGES; y++) {
			
			
			
		}
		
		
	}
	
}
*/

void Menu() {
	
	//loop:
	
	clearScreen();
	
	checkPIO();
	
	while(1) {
		
		if (check == 0) {
			
			FntPrint("\nROM Detected\n");
			FntPrint("\nPress Square to EXIT\n");
			FntPrint("\nPress Up on DPAD for Erase Menu\n");
			FntFlush(0);
			
		} else {
			
			FntPrint("\nNO EEPROM / FLASH DETECTED\n");
			FntPrint("\nPress Square to EXIT\n");
			FntFlush(0);	
		
		}
		
		break;
		
	}
	
	while(1) {
		
		pad = PadRead(0);
		VSync(0);
		
		if (pad & PADLup) {
			
			clearScreen();
			eraseFlash();
			
		}
		
		if (pad & PADRleft) {
			
			clearScreen();
			__asm__("j 0x801ecd94");
			
		}
		
	}
		
}


void checkPIO() {
	
	check = strncmp(checkBase, checkBase, checkBSize);

}

void clearScreen() {
	
	RECT	clearRect = { 0, 0, 320, 240 };
	
	VSync(0);
	ClearImage(&clearRect, 170, 100, 255);
	
}

void init() {
	
	DISPENV	disp;
	DRAWENV draw;
	
	ResetGraph(0);
	
	SetDefDispEnv(&disp, 0, 0, 320, 240);
	disp.isinter = 0;	disp.isrgb24=0;
	SetDefDrawEnv(&draw, 0, 0, 320, 240);
	
	VSync(0);
	PutDispEnv(&disp);
	PutDrawEnv(&draw);
	clearScreen();
	SetDispMask(1);
	
	FntLoad(960, 0);
	FntOpen(0, 0, 320, 240, 0, 512);
	
}
You do not have the required permissions to view the files attached to this post.
Last edited by CyrusDevX on August 11th, 2015, 12:19 pm, edited 1 time in total.

User avatar
sickle
Verified
C Programming Expert
C Programming Expert
Posts: 257
Joined: Jul 17, 2013
I am a: Chocolate-fueled pug fetish robot.
Location: Scotland

Post by sickle » August 11th, 2015, 12:13 pm

nocash wrote:
CyrusDevX wrote:Found these in 2 subroutines in IDA: Idk but it looks like exp1 control of some sort.

Code: Select all

sw      $s1, 0x20+var_C($sp)
li      $s1, 0xAA
sw      $s0, 0x20+var_10($sp)
li      $s0, 0x55
lw      $a0, 0x48($gp)
li      $v0, 0x90
sw      $ra, 0x20+var_8($sp)
sb      $s1, 0x1F005555
sb      $s0, 0x1F002AAA
sb      $v0, 0x1F005555
That 5555 and 2AAA stuff is common for writing to flash memory, check the datasheet for the flash chip (in case you haven't already done so).
Lol, yeah... uhm.. we definitely should have done this. Cheers nocash!

Seems you found the right function first time afterall Cyrus =)


So I did a few flashes and things to check my initial hunch - XFlash seems to use the address $80100000 ( ram_start + 1mb ) as the read and write buffer, which simplifies things a little. You can see $8010 passed the fail/retry function as the first argument, and passed to the CD sub also, or when copying into main mem from the "L1" button press in the "main" function at 0x80011040, which jumps to 80011D64.

While I remember btw:
Loadimage is literally that - from what I can see it's used to load an image into the VRAM, rather than some kinda OS-level support for executable "images" - do you have the Library Ref to hand btw, helps a lot given that IDA can recognize these functions.
(see C:/psyq/DOCS/LIBREF46.PDF if you've installed the PSYQ SDK http://www.psxdev.net/downloads.html )


Aaanyhoo.
@loc_ 80011660 - calls PadRead, checks against 0x40 (X to upgrade)
@loc_ 8001167C - some error handling, there's your ROM size.
@loc_ 80011650 - calls that first sub you found


With this in mind, and no$psx (such love for this) in hand, it should be relatively easy to patch xFlash. Maybe:
-Hijack the "L1" button to call whichever function explicitly (hardcoded args)
-Reassemble bits and bobs in no$psx (easier than compiling little binary chunks for everything)
-CopyPasta using your hex editor.

When editing the binary, the entry point is at 0x10 in the .EXE's header (e.g. 80 01 86 04 )
In this case, subtract 0x80010000 offset to give 0x8604 offset into the .EXE file.
And finally add 0x800 to account for the header to give 8E04 into the .EXE file.
so 0x80018604 in PSX mem corresponds to 8E04 in the .EXE.

CyrusDevX wrote:...The psx for example just seemed to be a different "breed" of what i would work on. I now realize at the root of what they actually are and how they work, is all the same. Just a different way of operating different things. Im so motivated lol ^^
Yeah, it's great everything's bundled into a neat little easily accessible package, that makes it really fun and accessible to see what's going on at a hardware level - without OS abstraction and threading and stuff getting in the way. When I'm bored I love just reeling over nocash's docus and learning how things are done - wouldn't mind a bit of time to actually do things but oh well ^^


LMAO, you posted that while I was typing that long winded reply - nice :D
Decided just to roll your own?

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 11th, 2015, 12:21 pm

Yep im making my own hahaha. I just updated it, and i should have it to were i need here soon.

User avatar
sickle
Verified
C Programming Expert
C Programming Expert
Posts: 257
Joined: Jul 17, 2013
I am a: Chocolate-fueled pug fetish robot.
Location: Scotland

Post by sickle » August 11th, 2015, 12:25 pm

you I like... you get shit done ^^

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 11th, 2015, 12:50 pm

sicklebrick wrote:you I like... you get shit done ^^
:dance :dance

Im going to add std_io on the psx side, so later on ill make the pc side application in C# (my native lang ^^)

EDIT: ok im a little stuck on the writing function.

danhans42
BANNED
BANNED
Posts: 329
Joined: Nov 28, 2012

Post by danhans42 » August 11th, 2015, 9:33 pm

CyrusDevX wrote:I think i figured out another way to add external storage to the psx.

Code: Select all

#include <stdio.h>
#include <sys/file.h>
#include <sys/types.h>
#include <kernel.h>
#include <libgte.h>
#include <libgpu.h>
#include <libetc.h>
#include <libapi.h>
#include <libmcx.h>

/*
    from BlackBag/Nagra PSX

    0x1f801040 - unsigned char data;
    0x1f801044 - unsigned short status;
    0x1f80104a - unsigned short cntl;
    0x1f80104e - unsigned short baud; not used???
*/

#define SIO_DATA(x)     *((unsigned char*)(0x1f801040 + (x<<4)))
#define SIO_STATUS(x)   *((unsigned short*)(0x1f801044 + (x<<4)))
#define SIO_CTRL(x)     *((unsigned short*)(0x1f80104a + (x<<4)))
#define SIO_BAUD(x)     *((unsigned short*)(0x1f80104e + (x<<4)))

//TODO: Figure out SPI protocol and implement.
//Build hardware interface for psx from gamepad
//port to store the spi flash ic for data storage.

int main() {
	
	PadInit();
	McxStartCom();
	
	
	return 0;
}
thats what i have so far. i have several spi flash ic laying around. i have 128kb ic from microchip that i might try this on ^^. it'll be challenge for me. But i also could be wrong.
I have often thought about getting SPI stuff working through a joypad port. It would be great way to expand the playstation using low speed peripherals and would easily open up the playstation so we could use a keyboard, low speed serial, SD card or SPI ethernet or even GPIO..

Other than that great work so far on the flashing code :D

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 11th, 2015, 10:23 pm

danhans42 wrote:
I have often thought about getting SPI stuff working through a joypad port. It would be great way to expand the playstation using low speed peripherals and would easily open up the playstation so we could use a keyboard, low speed serial, SD card or SPI ethernet or even GPIO..

Other than that great work so far on the flashing code :D
Thanks bud ^^. Im very serious about adding more options to have larger data storage, and i would love to get direct spi out of either pad or mc ports. Im looking at the PDA lib within Psy-q, Seems to be a pad port library with these functions.

Code: Select all

Offset Contents
0 Executing PDA application number (LSB)
1 Executing PDA application number (MSB)
2 Speaker disabled
3 IR communication disabled
4 PDA serial number (LSB)
5 PDA serial number (1)
6 PDA serial number (2)
7 PDA serial number (MSB)
8 Real-time clock (100 years)
9 Real-time clock (year)
10 Real-time clock (month)
11 Real-time clock (day)
12 Real-time clock (day of the week)
13 Real-time clock (hours)
14 Real-time clock (minutes)
15 Real-time clock (seconds)
16 PDA application's flash write priority
disabled
17 LED disabled

danhans42
BANNED
BANNED
Posts: 329
Joined: Nov 28, 2012

Post by danhans42 » August 11th, 2015, 10:28 pm

I have a Pocketstation, as well as the I-Mode cable which uses a pad port for serial communication to some Japanese mobile phones.

Is there anything in there for the imode cable?

User avatar
CyrusDevX
Active PSXDEV User
Active PSXDEV User
Posts: 47
Joined: Aug 07, 2015

Post by CyrusDevX » August 11th, 2015, 10:40 pm

OOhhhh i was digging around the forums and i came across a post about the imode cable. i saw 2 pics but the one i wanted to look a better was the side with the chip on it. But it looks like (to me) a cpld? or just a random chip to do a hardware protocol conversion. But it seems to use more i/o on the phone side then the psx port side. making me think its a hw protocol converter.

I havent came across anything about that cable. Seems to me like it was a custom lib that was used to work with that hw.

EDIT: That chip on ur cable looks the same as my ps2 dual shock controllers chip??? :shrug
Also im assuming the pda lib might have been used on this cable.

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests