Welcome, Guest!

Here are some links you may find helpful

Running PS1 game on DTL-T10000 TOOL

the7thchild

Active member
Original poster
Registered
Jun 13, 2019
25
38
13
AGName
the7thchild
AG Join Date
2011-2-7
I – The mystery of MINIRA

It is strange that nobody has posted this before. I have found that the PS1 mode in TOOL is already completed by a company or someone called M.T. under a project code GmainX(MINIRA):

MINIRA.jpg

I believe originally this MINIRA mode consists of the following components:
1. DTL-H1500 bios and IOP boot code called TBIN (completed)
2. SBIN containing PSX function call (completed)
3. KROM - purpose unknown (completed)
4. DECI1 related boot rom modules for psnet communication (completed)
5. psnet driver mrp.o (completed and somehow appeared in official SDK)
6. psnet related components for TOOL CP (or SBC) (unfinished, or finished but never leaked). I think this part should contain something like a psnetm, psreset, dexicons etc....

Somehow like the WorkStaton mode, Sony decided to scrap this function entirely because they thought developers won't need to develop a new PSX title on a PS2 development hardware. These components should have been used internally for the development of PS1DRV (and related per title boot parameters, TITLE.DB) in retail consoles.

II – DSW602

According to the boot message of IOP on TTY:
IOP-reset-dsw602.png
(credit to @unclejun for this tips)

The planned PS Mode is already mentioned in the TOOL boot message. However, the default setting of DSW602 has b3 set to 1 (ignore cd-rom always), we have to turn that back on by a painful disassembly of the tool. This DSW602 hides deep down under the PCMCIA card.

5767_1582519563311.png
Credit to Parris and unclejun for taking this photo. For the method to reach DSW602, please refer to PS2 TOOL guide http://lorezan.free.fr/ps2/PS2 Tool guide.pdf

b0 is hardwired to switch 5 at the back of the TOOL. This make switch 5 serves 2 purposes:
  • Set GS mode to NTSC or PAL in PS2 mode
  • Set PS Mode to H1500 or disable
III- Launching the PS Mode
  • Set up the DSW 602 so that b3 is 0^ check cdrom.
  • Set back switch 5 to disable H1500 (we do not have psnet clients, so it will be useless for now).
  • Extract PS1DRV from SCPH-70XXX bios. Use romfs tool for this.
  • Compile the following source code as boot loader
C:
#include <eekernel.h>
#include <eestruct.h>
#include <eeregs.h>
#include <libcdvd.h>
#include <libpad.h>
#include <libgraph.h>
#include <sifrpc.h>
#include <sifdev.h>
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <malloc.h>
#include <stdarg.h>
#include <stdlib.h>
#include <sifcmd.h>

/* MAIN PROGRAM */
int main(int argc, char *argv[])
{
                printf("Trial 34\n");
    
                while(!sceSifRebootIop("host0:IOPRP300.IMG")) {};
                while(!sceSifSyncIop()) {};

                sceCdInit(SCECdINIT);

                sceSifInitRpc(0);
                sceSifLoadFileReset();
                sceFsReset();
                LoadExecPS2("host0:PS1DRV", 0, NULL);
                return 0;
}

  • I know this code calls too much unnecessary .h, I will clean it up later.
  • Launch bootloader with IOPRP300.IMG and PS1DRV in the same directory, with boot parameters = 0x000f0000 for EE and 0x100 for IOP
IV PS1DRV

You will be facing a lot of problem when dealing with PS1DRV as it is not fully compatible with newer boot rom of the TOOL.

  • In WS mode (ancient boot rom), it will boot flawlessly but you will lose component cable signal...
  • In TOOL mode, your program will hang in the midway after cdvd driver is loaded.
  • To get pass this error, you will have to use a debugger like dsidb to step through the problem code. A step, step, cont will usually do.
  • Or alternatively you can search cdrom0:\SYSTEM.CNF;1 and replace NF;1 by "host0:". It will look like cdrom0:\SYSTEM.Chost0:
  • It is strange because the cd driver is not loading text strings correctly, it is always delayed by 16 bytes.
  • In TOOL mode, the product ID of the disc will not be loaded correctly and the initial boot parameters of the GPU EMU will be fixed to default value. Luckily this value works for most of the games.
Edit: Change the C0 to B0 for the following 2 addresses (using PS1DRV 1.3.0 from SCPH-70XXX) can eliminate the need for debugger:

1.jpg

2.jpg


V PS Mode launched

Your TOOL will perform in the following order:




  • Put a ps1 pressed retail disc or cd-r master disc into the CDVD-ROM drive (if the tray still opens and reads disc)
  • Load bootloader
  • IOP reset
  • Wait for CDINIT to initiate the CDVD-ROM drive (note: it is important, PS1DRV will not function without sceCdInit(SCECdINIT); )
  • Your TOOL is as old as a grand grand daddy in 2020, so wait a bit more...
  • PS1DRV launches
  • Rainbow screen displays (if back switch 5 is set to 0)
rainbow.jpg
  • TBIN will parse system.cnf or load psx.exe in the disc root
  • Game launches
  • When somebody say PS2 TOOL cannot run PS1 games, correct them!!
VI Interesting points

  • TBIN contains tons of debug printf(); but they are not visible in all EE tty and IOP tty channels. PCSX2 PS1 mode somehow display those printfs correctly. You can see something like PSX Kernel 1.X.X etc.
  • PS1DRV debug info is sent to com2 (/dev/ttyS1) of the TOOL SBC. You can install ncurse and minicom to get those information (38400bps, 8N1, ANSI)
  • If you kill dsnetm and restart dsnet driver by "/usr/local/sce/bin/mrp deci1 start", you can install psnet driver successfully.
  • There is no corresponding manager like dsnetm for deci1 communication. dsnetm does have a –psnet option, but it cannot connect to psnet driver at all.
  • There is a H1500 utility install disc which contains command binaries for the real DTL-H1500 hardware, but the code will launch only in Linux with qemu-irix installed.
  • By capturing the output of those commands. I can push reset command to /dev/mrp0 in deci1 mode. However, it is the best I can do at this moment.
4C A1 24 00 0A 00 00 00 0A 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 01 54 61 A1 25 54 01 00 00 00

Binary of deci1 reset protocol, create a binary file called reboot

cat reboot >/dev/mrp0 will reset the tool

  • Without proper psnet tools, reset command is the only thing we can do. A complete tool set should contains RUN15, PLOAD15, BLOAD15 and RESET15 commands.
irix.jpg

Everyone who have obtained their TOOL from 1st party sources should check the internal HDD. There may be some codes different from 3rd party TOOLs.

VII Binary release

https://www.sendspace.com/file/oheygv

This release is called PSEUDORETAIL for T10K:
  • Includes HDDOSD for T10K with PS2LOGO and PS1DRV bootloader integration for retail and master discs
  • Includes standalone PS1LOADER for TOOL MODE and WS MODE
  • if you encounter a title in which a special parameter is needed for TBIN, please use WS MODE as it loads the product ID correctly.
 

Attachments

  • MINIRA.jpg
    MINIRA.jpg
    6.3 KB · Views: 0
Last edited:

HI_RICKY

Donator
Donator
Registered
Mar 21, 2019
379
247
43
AGName
HI_Ricky
AG Join Date
Jun 7, 2007
nice job , finish every one 20year dream project :)
 

wisi

Member
Registered
Jun 7, 2019
11
24
13
AGName
wisi
AG Join Date
Apr 16, 2016
Great work!
Different people tried this before, but it was never given too much attention, as the necessary modifications to PS1DRV seemed to be too many. I don't think anybody considered that simply skipping the errors while it boots will result in correct operation...


There was some info recently about the person who wrote PS1DRV:
https://www.psx-place.com/threads/m...ibility-from-the-engineer-who-built-it.28431/
https://storys.jp/story/3458


"Gmain" is the name of the main board of the PS2 TOOL or something like that.
Code:
TOOL models

The model number is stored as a byte in 0x1F803204. It is suspected that the model number can be changed in some cases - like switching one of the DIP switches at the back of the DTL-T10000.

info source: IGREETING

id            model

0x00        UMA board  UMA = Unified Memory Architecture (assumed)
0x01        UMA board

value & 0xF8:

0x10        "Gmain-1.0 board DSW602\r\n"
0x20        "Gmain-2.0 board DSW602\r\n"
0x30        "Gmain-3.0 board DSW602\r\n"
0x40        "B3system-1.0 front dipsw\r\n"
0x50        "Gmain-4.0 board DSW602\r\n"
0x51        ? Gmain-4 ? - reportedly the DTL-T10000 can switch to that by a DIP switch.
0x58        "Gmain-5.0 board DSW602\r\n"

0x5C        Gmain-6.0  GUESS

0x60        "MPU-4.0 board DSW602\r\n"
0x61        GSM-1   GSM = GS Module (main board). 4x GSM-1 is used in the GSB 0.3 GSBox
The GSCube uses 16x GSM-4, so there were at least 4 versions.
0x62        GSM-2 GUESS
0x63        GSM-3 GUESS
0x64        GSM-4 GUESS

0x68        GSM-4 GUESS; more likely

0x64        Gmain-7.0  GUESS  These three were guessed before it was known that GSM-1 has ID = 0x61. Now it seems more likely that ID 0x68 was the only release model among these, and thus it may be the release model of the GSCube GSM-4 board.
0x68        Gmain-8.0  GUESS
0x6C        Gmain-9.0  GUESS
Just like ID 0x70 is used on both Gmain-10.0 and 11.0 it is possible that Gmain 7.0, 8.0 and 9.0 had the same ID.

0x70        "Gmain-10.0/11.0 board DSW602\r\n"
0x78        "Gmain-12.0 board DSW602\r\n"
0x7C        "Gmain-13.0 board DSW602\r\n"  (this compare can't equalize, because the mask used is 0xF8).


"MINIRA" - "MiniRa" I suspect is actually shortened "Mini Rack", referring to the mini-rack the PS2 TOOL originally was. This also suggests there was a big rack the PS2 TOOL was before that. There are one or two pictures of the mini-rack on the net.
You can see "MiniRa" on the (perhaps) BOOT ROM on the Gmain2.0 board, which was perhaps part of the Mini Rack.
Gmain4.0 and there are also pictures of the rack. There were other pictures of another - green rack, but I can't find them.
This was found by Shuji, on Assemblergames.

There are several different strings like ("$CEI...") "GmainX (MINIRA) by M. T." from the start of SBIN/RESET:
Code:
PS1:
DTL-H1001                       CEX-1000 KT-3 by S.O.
DTL-H3000, SCPH-5500            CEX-3000/1001/1002 by K.S.
DTL-H2000                       DTL-H2000+DECI by M.T.

PS2:
PS2 TOOL                        GmainX(MINIRA) by M.T
CEX PS2                         PS compatible mode by M.T.

KROM is Kanji characters ROM - from the info by SP193 - https://sites.google.com/view/ysai187/home/projects/fontm-font-project
I have no idea if it is used or related to PS1 mode.

SBIN is the controller pads (and other things?) driver for PS1 mode.

AFAIK the PS1 'BIOS' from the PS2 TOOL has at least two-three different modes (though they may be even more - I don't remember), with various levels of debugging, and using different software and devices.
I have no idea how DTL-H1500 was meant to be used with the PS2 TOOL. It is very much possible that this option is a remainder of one of the earliest PS2 TOOL models.

I once looked at psnet MRP/PIF driver, and compared it with the one for dsnet, but I forgot what the differences were - I don't think there were too many. The actual hardware interface is a packet interface(for dsnet) and a bi-directional "serial port", which is not used much in PS2 mode.
The PS1 debugging tools use a yet different serial port for debug messages - https://problemkaputt.de/psx-spx.htm#exp2dtlh2000ioports
Maybe one of those two is the serial port used.

Note that there is also a simple, single-word communication interface through the PGIF. But maybe that was only for debugging the PGIF itself.
 
Last edited:

supersega

Donator
Donator
Registered
Nov 25, 2019
54
18
8
AGName
supersega
AG Join Date
Jul 25, 2014
I find it sort of amazing that they had the option for it in there to do this, even though they sort-of knew it was over for the PS1.. great guide!
 

water111

Member
Jun 2, 2019
8
5
3
This is really awesome, great work!

I guess it is not too surprising that this is possible, as they probably needed a way to debug the PS1 compatibility mode.

I found that the psnet version of the mrp driver was not on my tool, but there is one in the SDK, perhaps by an accident. I do have a "sam.o" driver though.

Also the pictures from wisi's post of the older "gmain" boards is very cool.

I am curious if anybody knows more about the serial port on /dev/ttyS1 on the SBC. What is it connected to? I've seen this cable before in my TOOL.
 

wisi

Member
Registered
Jun 7, 2019
11
24
13
AGName
wisi
AG Join Date
Apr 16, 2016
Or maybe even it was considered switching PS1 development to using a PS2 TOOL, for developers who already had it.

The sam.o driver I think is for some sort of monitoring (hardware status/debugging maybe), but I never managed to figure-it-out. It is for some PCI device implemented in the backplane (BP-?) board, but I only vaguely remember that it seemed to refer to a PLX PCI bridge of a different model than the one on the BP-2 board.

The serial cable going from the MPU-4 board to the SBC board is certainly the EE serial port - "EE-SIO", but I don't think that is what the PS1 debug console uses, unless the mentioned above channel over the PGIF is used (usually the IOP in PS2 mode sees the EE only as the PS1 GPU and doesn't have a generic path for non-GPU data to it). I am not sure which one is /dev/ttyS1 though. It is possible it is a virtual device, implemented through a data channel in the mrp.o driver - this would explain how it can get data from the IOP in PS1 mode.

BTW, an interesting note about how EE booting happens - actually the EE *always* boots (from the BOOT ROM) *after* the IOP. This is because the IOP does not allow EE to access the SSBUS (through the SBUS) until the SIF IOP driver is loaded.
This explains how the IOP can basically affect what the EE RESET code will do - as the EE RESET code is executed after the IOP enables EE access to its memory (basically its entire memory). Which however is however not available as an option (the IOP PGIF interface over the SBUS design prevents it), in PS1 mode.
This is also used in a neat debugging feature of the PS2 TOOL (and any PS2, if it had a similar RESET code). The TOOL has a RESET that can in some mode (set by some of the DIP switches), run the EE from code in IOP RAM. What happens is that the IOP boots, then some code is loaded to its RAM (I don't know how that was meant to happen exactly) and then the EE is enabled access to its memory (as usual) and then the EE (in RESET) jumps to that pre-set (hard-coded) location in IOP RAM. Perhaps that was some sort of test-feature in case EE RAM is suspected to be bad.


EDIT:
Actually, there seems to be a 74CBTS3384 bus switch before the MAX233 on the EE SIO, which would suggest that there are two UARTs that connect to the same port. This would explain how PS1 mode IOP console can be routed to it. There must be some register that switches it, or perhaps this is done by the line that resets devices into PS1 mode.
DTL-T10000_EE-SIO_combinedWithIOP_PS1ModeSIO.JPG
This would explain how the PS1 mode IOP console can be output from that port.
Having some of the messages received from it can help determine exactly where (which registers) is this UART implemented on IOP side.
 
Last edited:

the7thchild

Active member
Original poster
Registered
Jun 13, 2019
25
38
13
AGName
the7thchild
AG Join Date
2011-2-7
This is really awesome, great work!

I guess it is not too surprising that this is possible, as they probably needed a way to debug the PS1 compatibility mode.

I found that the psnet version of the mrp driver was not on my tool, but there is one in the SDK, perhaps by an accident. I do have a "sam.o" driver though.

Also the pictures from wisi's post of the older "gmain" boards is very cool.

I am curious if anybody knows more about the serial port on /dev/ttyS1 on the SBC. What is it connected to? I've seen this cable before in my TOOL.

There is a connector from the main board under the DVD drive:

ttyS1.jpg

It will send some debug information to /dev/ttyS1 which can be viewed by using minicom,
You can install minicom rpm and set : 38400bps, 8N1, ANSI mode to view those information,
 

the7thchild

Active member
Original poster
Registered
Jun 13, 2019
25
38
13
AGName
the7thchild
AG Join Date
2011-2-7
2020-03-19 - added method to eliminate the need for debugger
2020-03-23 - added PSEUDORETAIL mode for T10K binary release
 
Last edited:

slycooper124

Well-known member
Registered
Jul 30, 2019
495
117
43
AGName
slycooper124
AG Join Date
June 2019
hello, i have opl running on my ps2 tool through dsnet and it dosent recognize .bin, .cue files which are cd iso files, so if I flip the switch to enable check for cd, will opl be able to run cd iso's?
 

uyjulian

Well-known member
Registered
May 30, 2019
122
57
28
Just for reference, the filename of the sendspace link above is PS1DRV.zip
 

locarno

Member
Jul 3, 2022
6
0
1
I don't know. I don't have much knowledge about it. Why PS1DRV will not work with TOOL bootroom?
 

Make a donation