Creating custom ROMs for the PS2

[Epaminondas]

I'm sharing here a project that was experimental in nature, but I noticed a lot of interest in it from the community, so here we go!

I created this for personal use, so it's very rudmentary, made with a simple command prompt script and some free tools.

The package doesn't contain any PS2 ROMs, you'll have to get your own to customize it.

So far, they have only been tested on hardware from the 79000 and 90000 series (they use the same ROM, except for the latest versions of the 90xxx series).

There is support for the 75 and 77, 70, 50 and 39 series, but other versions can also be flashed without any problems.

Main changes made:

Uses PS2BBL as the main boot manager, so we have OPL, ULE and a small part of FMCB inside the ROM (just to have a shortcut to "go back" when using OSDSYS).

If you don't have OPL on your MC or USB drive, PS2BBL will start it from the ROM, so you won't be stuck with the version installed inside the ROM forever, because you can update it inside your pendrive whenever you want!

Some things were removed from the original ROM to make free space, since we only have 4MB, the FONTS file that supports Japanese, Chinese, Russian, etc... and other things that I removed and don't seem to be needed ;-)

OSDSYS is modified, I removed some textures and audio FX, it was very small and preserved all its functionalities, I particularly liked its new look and sound!

GitHub - pp5di/custom-rom-ps2-first-version

Contribute to pp5di/custom-rom-ps2-first-version development by creating an account on GitHub.

github.com

Use it in the root of the disk. For example 'C:/CUSTOM'

put your original ROM inside the 'CUSTOM' folder and rename it to 'rom.bin'

Run 'MAKEROM.bat' and follow the instructions.

If your custom ROM is generated without error, test it on your PS2 emulator

So far I have only tested it with models from the 79xxx and 90xxx series. The package contains scripts for other cards, but they need to be improved and tested on PS2 hardware. Not everything that runs on emulators can run on real hardware.

 

[El_isra]

Very nice. I'm dying to do something like this to my 75k. The potential for development is amazing.

 

[Epaminondas]

75k and 77k use the same ROM, and it is very similar to 79k and 90k, it won't be difficult to do.

 

[Epaminondas]

I remember seeing some projects to burn flash, with stm32f407, but I think they can be easily adapted to the rp2040, if you choose a flash with SOP44 encapsulation, you can solder without the need for PCBs, I have one like this as shown in the photo above.

 

[El_isra]

I remember seeing some projects to burn flash, with stm32f407, but I think they can be easily adapted to the rp2040, if you choose a flash with SOP44 encapsulation, you can solder without the need for PCBs, I have one like this as shown in the photo above.

Latest ROMIMG is capable of highlighting files Wich are marked as "expected at fixed location".

It somehow crashes on windows build. But Linux build running on WSL worked like a charm

 

[Epaminondas]

Very nice. I'm dying to do something like this to my 75k. The potential for development is amazing.

By making good welds, the work can be undone later and returning your 75k to its original state.

 

[El_isra]

By making good welds, the work can be undone later and returning your 75k to its original state.

I doubt that if I make it I'll ever use stock ROM again. At very least, I'll add the PPCTYY driver and hook it to IOPBTCONF to have all logs redirected to the PowerPC UART.

Would be cool to make the flash chip programable from the console.

 

[Epaminondas]

Latest ROMIMG is capable of highlighting files Wich are marked as "expected at fixed location".

It somehow crashes on windows build. But Linux build running on WSL worked like a charm

I found some small problems with ROMING. We can't have very long directories, because this directory is written inside the ROM, and ends up corrupting it. Another problem is with files named "_", there are usually about 4 or 5 of them, and ROMING doesn't recreate them when recompiling the new ROM. In the script, I recreate them with the name DUMMY1, DUMMY2... the name doesn't matter.

I was able to eliminate some of them, others not. They should remain in the same place. They are small files with nothing in them. I still don't understand their purpose. I don't know if it's to reserve some space in RAM.

 

[El_isra]

I found some small problems with ROMING. We can't have very long directories, because this directory is written inside the ROM, and ends up corrupting it. Another problem is with files named "_", there are usually about 4 or 5 of them, and ROMING doesn't recreate them when recompiling the new ROM. In the script, I recreate them with the name DUMMY1, DUMMY2... the name doesn't matter.

I was able to eliminate some of them, others not. They should remain in the same place. They are small files with nothing in them. I still don't understand their purpose. I don't know if it's to reserve some space in RAM.

It's because some files are expected to be at specific offsets, because those files are inmediatel needed by the bios bootstrap program (the raw executable at the beginning of the file, Wich is represented by the RESET entry)

Latest ROMIMG will highlight those files in YELLOW when listing ROM content

 

[Epaminondas]

I haven't seen the last ROMIMG yet, the last time I worked on it was in November / 2023

 

[El_isra]

I haven't seen the last ROMIMG yet, the last time I worked on it was in November / 2023

I made the update I'm talking about this week XD

 

[Epaminondas]

Look at the possibilities of having a customizable ROM, running without mechacom, dsp and lan, if we can remove things, we can also add others, like a bus for high-speed reading, endless possibilities, I understand very little about programming, so I think that in the right hands the project can fly!!!

 

[Mister M]

Look at the possibilities of having a customizable ROM, running without mechacom, dsp and lan, if we can remove things, we can also add others, like a bus for high-speed reading, endless possibilities, I understand very little about programming, so I think that in the right hands the project can fly!!!

I took the liberty of uploading your video @Epaminondas , to illustrate what you say. An unprecedented advance for PS2 portability. I also remember what you told me, with the removal of the Mechacon the memory card becomes unusable, having to use the virtual memory card. Can you explain all this work better?

 

[El_isra]

an example of romimg marking the fixed offset files (the third new colum indicates offset (bytes occupied so far by previous files)

This should allow spotting them easily

my next target: adding a "scripted rom creation" feature.

Where you give ROMIMG the list of files, specifying the ones you want at specific offsets. so that the program deals with the dummy gap fillers automatically...

 

[Tschicki]

I did some more tests with the boot rom flex and can confirm that your custom bios works on my 70004 console too! Incredible work!

 

[Shank]

This thread is wild. So much potential. I could see some crazy PS2 developments come out of this.

Do you think USB 2.0 capability could be added through this method? Be it through the ps2's USB data lines, or through custom means elsewhere?

 

[Epaminondas]

an example of romimg marking the fixed offset files (the third new column indicates the offset (bytes occupied so far by the previous files))


This should make it easy to identify them


View attachment 34729


My next goal: to add a "scripted ROM creation" feature.


Where you provide ROMIMG with the list of files, specifying the ones you want at specific offsets, so that the program handles the fictitious gap-fillers automatically...

Good morning, I downloaded the latest version of ROMIMG, I just used it instead of the previous one and it still works, but I haven't explored it much, I'll take a look today, but your idea of putting the option of a list of components to be used in the reconstruction of the ROM is very interesting, In the original project some files are modified, in text and HEX mode, I don't know if it would be possible to have this in ROMIMG, so it would be unbeatable!

If you look in the 'files' folder, there are the scripts for each model, they would be the starting point for the ROMIMG task list, but the heavy lifting is done by MAKEROM.bat.

---

um exemplo de romimg marcando os arquivos de deslocamento fixo (a terceira nova coluna indica o deslocamento (bytes ocupados até agora pelos arquivos anteriores)

Isso deve permitir identificá-los facilmente

View attachment 34729

meu próximo objetivo: adicionar um recurso de "criação de ROM com script".

Onde você fornece ao ROMIMG a lista de arquivos, especificando aqueles que você deseja em deslocamentos específicos, para que o programa lide com os preenchimentos de lacunas fictícios automaticamente...
[/CITAR]
Bom dia, baixei a última versão do ROMIMG, acabei de usar no lugar da anterior e continua funcionando, mas não explorei muito, vou dar uma olhada hoje, mas sua ideia de colocar a opção de uma lista de componentes para serem usados na reconstrução da ROM é bem interessante, No projeto original alguns arquivos são modificados, em modo texto e HEX, não sei se seria possível ter isso no ROMIMG, então seria imbatível!

Se você olhar a pasta 'files', lá estão os scripts para cada modelo, eles seriam o ponto de partida para a lista de tarefas do ROMIMG, mas o trabalho mais pesado é feito pelo MAKEROM.bat


Moderator note - merged post & provided translation using DeepL.

 

[Epaminondas]

sorry, I forgot to disable my translator

 

[CrashBash]

No worries, I ran the posts through DeepL and updated them.

I also merged your posts. If you realize you made a mistake you can always edit your post. Helps keep "clutter" in threads down.

Really cool to see a custom BIOS becoming a reality on the PS2. This came out of nowhere and is really impressive!

 

[El_isra]

If you look in the 'files' folder, there are the scripts for each model, they would be the starting point for the ROMIMG task list, but the heavy lifting is done by MAKEROM.bat.

IMO the ideal approach is the following

The script will be parsed. The files expected at fixed locations will be listed apart.

And the writing loop logic will be:

next_offset = written_bytes + next_file_size;

if (next_offset > next_fixed_pos_files->offset)  {
    gap = next_fixed_pos_files->offset - written_bytes;
    if (gap > 256) {
        look_for_smaller_file();
    } else {
        fill_the_gap();
    }
    write_next_fixed_pos_file();
    next_fixed_pos_files++;
} else {
    write_next_file();
}

This ensures a few things:

• No need to manually handle all models
• No need to manually deal with the gaps