Worklog Some PS2 Project

[mixa232323]

Update time!

Sorry, I completely forgot to post updates! (again…)

Ever since the last update I’ve been working on FPGA stuff to get the video output of my mainboard up and running and I guess I’m slowly getting there.

After the little experiments with my DPI LCD I know more or less what to expect when it comes to resolutions and video timings. The big blocker was the lack of memory to buffer at least one field of each frame. It made the bridge between the 2 clocking regions very tricky and at some point it stopped me from progressing with my design.

The next logical step was to look into the available RAM options. First, I wanted to try the DDR3 on my Artix 7 Development board, as it would provide plenty of memory at a sufficient speed.

Getting DDR3 working is not trivial, though. I figured that out the hard way after 2 evenings of fighting with vivado’s memory interface generator IP. That “experience” forced me to take a step back and to reconsider things.
At that point I knew already that I would like to use a cheaper FPGA for the final board and it made no sense to waste time with proprietary Xilinx IP, so instead I was looking into the RAM options with my FPGA of choice, the Trion T20. It didn’t take a lot of reading in the datasheet until I realized that the only package I can economically design a PCB for (0.8mm pitch) does not have a hard DDR3 controller & as I’m by far not experienced enough to write a soft DDR3 controller, that option was out of the game.
Instead, I chose a SDR SDRAM for the framebuffer, the IS42S32400F-6BL to be precise. Compared to DDR3 it mostly has drawbacks: it’s slower, it’s more expensive, SDR RAM is kinda outdated and on top of that it requires more pins. BUT it’s considerably easier to drive and it makes PCB layouting much simpler with less strict timing & impedance requirements.

You can imagine the next step…. Custom development board time!

View attachment 31269View attachment 31270
This one was like a 2-weekend project and it should include everything I need to continue with video processing. I tried to check all the boxes regarding compatibility with my existing PS2 mainboard while making it flexible enough to be reusable for future projects. The main features are:

• Trion T20F256
• IS42S32400F-6BL SDRAM + QSPI flash for the FPGA config
• All power regulators included, only requires 5V to operate
• 2 80 pin mezzanine connectors with as many IOs as I could fit -> great for custom shields
• 1 bank is selectable between 1.8V and 3.3V (mainly for the GS video interface)
• Status LEDs, 1 user button
• Programmable via JTAG (QSPI flash too)
• The BOM of the whole board (including PCB) is less than my old Artix 7 A35 FPGA (just the chip!!)

SDRAM length matching is a bit sloppy, KiCAD kinds sucks in that regard and I just could not be bothered to waste a lot of time there (especially with 56 signals…). So, all lengths are within ~7mm (ignoring the propagation speed of inner vs outer layers). Should be alright for the speeds I need, but for the next revision I should improve it.

Of course, I also designed a shield for interfacing with my PS2 and the LCD later & a little JTAG programming adapter PCB for the FTDI module:

View attachment 31271View attachment 31272

Assembly went smooth, during testing I had to solder three little bodges, though. The main issue was the RST. Short version: Efinix recommends to use a voltage supervisor with manual reset input to drive the reset pin of the FPGA at powerup. The RST signal is also required for JTAG and the application note says to connect all reset inputs to the manual reset input of the voltage supervisor. Doing that will delay all reset pulses from the debugger by ~200ms, which made JTAG programming impossible. I had to connect the JTAG RST to the FPGA directly and solder the voltage supervisor in parallel to handle startup, that fixed it.

With the hardware part done, I can focus on the video interface again. First step is to design a proper framebuffer as the heart of the scaler. That was done in the last 2 weeks over Christmas.

The Efinix SDRAM controller IP did not convince me and making things from scratch is fun, so I decided to design one myself as a learning exercise and to get some experience. I would not call the Efinity IDE and documentation beginner friendly, so it was a good opportunity to experiment with the tools too. There’s not a lot of features compared to vivado; no wizards, no templates, no simulator, no schematic view, no block designs; BUT it’s a million times faster, the entire flow from synthesis to bitstream takes just as long as the synthesis in vivado…I'm still using vivado for functional simulation, though.

Back to the SDRAM: The state machine was straight forward, but it was my first-time debugging timings. In the end I got it working at 150MHz, but at the max of 166MHz the controller just reads garbage still. 166MHz should be achievable according to the timing analysis, but maybe I just have to recalculate my timing constraints to find the culprit.

Anyway 150MHz should be plenty already, in the simulation the controller hits ~400Mbyte/s write and ~300Mbyte/s read MAX when there are no rows to open/close. The video stream should require about 160MByte/s in the worst case.

The controller is optimized for R/W speed over latency and I tried to make it as simple as possible without sacrificing too much of the bandwidth. There are no fancy functions like command scheduling (overlapping, canceling,...) or delaying refresh cycles, only one command at at a time. It does do 8-word read/write bursts, though - to maximize the bandwitdh (that's 32 bytes per command). On top of that it avoids auto-precharges and insteads keeps track of the open rows to minimize overhead. So far the controller is passing all my test cases in simulation (with some generic SDRAM memory model).

My goal is to make the SDRAM controller as stable as possible, as it is one of the core blocks of the scaler & maybe I can still shave off some clock cycles here and there to make it faster.
I will work on that the next week and then I will continue with the other blocks. Missing would be the video input and output blocks (kinda defined already from my experiments), the read/write scheduler for the framebuffer (probably the most complex block), the scaler and the block to write OSD info into the framebuffer. Still a LOT of work ahead!

GSModeSelector can switch from 480i to 480p. Maybe experiment with it?

 

[Tschicki]

GSModeSelector can switch from 480i to 480p. Maybe experiment with it?

I appreciate the suggestion, but I decided not to rely on GSM for the same reason I decided to make miniature memory cards instead of using on virtual memory cards - it's not a plug and play solution and needs settings adjustments per game to get things working (and PAL games in general are pretty hit or miss). I'm lazy, so ideally I would just like to plug in an sd card and start playing - like you would do on a normal PS2.

While I'm typing already, I also have an update to share!

I spent the last 6 weeks on implementing a first proof of concept for the scaler. After doing the final tests of my SDRAM controller I was thinking about an architecture that is simple, expandable & hopefully functional. I split the design into functional blocks and started implementing & simulating them individually, starting from the video input block. To give it a start, only the weave deinterlacer was implemented to find problems before I dive into scaling.

The result of the first implementation can be seen here:


The current proof of concept still has its flaws, I don't know how well they translate into the video. The most obvious issues I observed are:

• Every now and then the video shows heavy combing artifacts and feels a bit choppy, to then return back to a normal state for a while. While I understand that those artifacts are somewhat normal for a weave deinterlacer, sometimes they are so bad that I think there is a bug somewhere. I have my suspicions on where the issue might be and I will need to do some debugging of the whole frame lock logic - it might be that the deinterlacer loses synchronization and a field of one frame ends up in the next frame (which would explain the choppiness and the nasty combing)
• Depending on the scene, the image has quite some noise. It is especially noticable in areas where there are big color/contrast changes (like the text in the OPL menu) or in GTA when there are soft color gradients (very obvious in the second half of the video when I fly the jet). In still images, some pixels also like to flicker, most noticably red and green. Still not quite sure where I should start troubleshooting that, it could be caused by a lot of things, my ideas so far are:
  • dithering on the GS output
  • bad connection of one or more lines on either the input or output (actually found 2 already)
  • timing issues either while sampling the video input or inside the deinterlacer
  • driving the LCD incorrectly - I'm operating the LCD in OE-mode instead of HV-mode, which is very much undocumented in the LCD's datasheet (apart from 2 diagrams, one for cascade, one for dual gate - no idea what the difference might be)
  • This was fixed already. The LCD datasheet doesn't list the setup and hold times and at 25MHz I thought looking into the timings wouldn't be necessary at this point.Turns out playing with the pixel clock phase shift of the output signal fixed the issue. I discovered it when injecting custom video data into the input stream and comparing the input & output - they were identical (and the issue was still present with the injected video signal). For the video signal I chose columns of dark and light gray with fast transitions - the output was displaying the first 2 Pixels of every transition incorrectly. That meant the issue could only be due to driving the LCD incorrectly and most likely with clocking.

​

Other than that I'm quite happy with the first try! This is now the first time the system is truly "portable" and playable, with no wires going to it!

• The image itself is generally very sharp and the frame lock logic I implemented should also make switching between NTSC and PAL easier
• There is visible combing, but on such a small display it's not as bad as on a TV
• Video delay is exactly one frame, this is because of the framebuffer implementation I ended up using -> while the current input frame is captured, the output block transmits the last frame, this leaves me a lot of freedom in the way I structure the state machines. In the framebuffer this is done utilizing the bank select of the SDRAM, it allows me to always have 2 rows open at the same time and eliminates the constant precharge commands to increase bandwidth.
• Each output frame is always transmitted twice per input frame (input frame consists of the odd and even field), this leads to a 25Hz effective framerate (PAL) and 50 Hz in total
• Without the scaler, PAL video doesn't fit the LCD yet, but I made it easy to adjust the image position
• I measured the power consumption today and it's about 1.2W in total for the FPGA development board and the LCD at full brightness

Those 2 big issues I mentioned will need some debugging and that's the next step. I started already and the debugger IP core in the Efinity software helps a lot, but I might still need to hook up the proper logic analyzer to see what is going on. Maybe someone with video processing experience has some clues to reduce the troubleshooting time? I would certainly appreciate it!

Anyway, I'm still very much motivated to continue with the FPGA implementation and let's see where I end up! FPGAs are actually kinda fun and I can highly recommend to give one a try!

 

[wisi]

This is an amazing project! I am glad people like the PS2 even after so many years and the projects around it get more and more interesting!
I have been doing small software and hardware projects on the PS2 as a hobby, but completing them is commonly difficult.

PS2 models after SCPH-75000 (included) have the IOP replaced with a PowerPC CPU with a MIPS Auxiliary Processing Unit. It runs the DECKARD emulator from the BOOT ROM, which partially emulates the IOP, while the MIPS APU emulates some of the instructions execution. The emulator code is in the DECKARD folder (big endian) in the BOOT ROM, at the very top (highest address) of the BOOT ROM. Those BOOT ROMs have 3 /CS signals - MIPS BOOT ROM /CS2, DVD ROM /CS1 and a /CSPPC for the PowerPC. I don't know if /CS2 and /CSPPC access the same memory area or two separate areas, but the data in both is exactly the same. For some unknown reason /CSPPC exists at the connector on the page of the Dev9 controller and SPU in the SCPH-70000 SM (even though that is not a deckard model).

To generate the BOOT ROM /CS to the new replacement flash ROM, the /CS2 has to be and-ed with /CSPPC, that went to the original ROM chip. Though it seems apparent that because there are few external devices, and internal devices don't exit to the SSBUS, even having the BOOT ROM selected when /CS1 and /CS5 (CDVD DSP) are not selected works fine.

The SSBUS (IOP sub-system bus to the peripherals), has configuration registers which set the access timings, widths and some other properties of the peripheral channels. It is possible for example to make the DVD ROM use 8 bit bus width or slower/faster timings. Also, AFAIK the DVD ROM uses by default faster timings than the BOOT ROM and also the BOOT ROM initially uses even slower timings and after a certain point in the boot process they switch to faster ones, but I could be wrong about this.

Also there is an unused EXTR SSBUSC channel. It is used on the PS2 TOOL for PIF (interface to the PC side for debugging) communication. its lines (chip select, DMA, interrupt) are present at pads on some SCPH-790xx models, so they might be present at least on some revisions (if not on all) of the PS2-on-chip ASIC (but for the GS and CDVD subsystem). That channel can also be used to connect an external device if that is necessary (avoiding the need for using the DVD ROM, though it would have to be remapped somewhere with enough space.

It is really inspiring to read this thread! Thank you for working on this project!

 

[Tschicki]

This is an amazing project! I am glad people like the PS2 even after so many years and the projects around it get more and more interesting!
I have been doing small software and hardware projects on the PS2 as a hobby, but completing them is commonly difficult.

Thanks! The PS2 was my first console, so I will also always have a soft spot for it! I've been modding mine already as a kid 20 years ago, so it's really fun to do something more serious with it now
Also thanks for the infos regarding the CS, it's quite hard to find information like that online! I haven't seen /CSPPC yet, could it be that it's one of the pins 12, 13 or 14 on the bios chip? Anyway, handling the CS on the bios flash is quite flexible, we found a couple of ways already that seem to work. Only for getting the DVD ROM to function it's a bit more complicated so far, as it requires 16 bit data by default. In a portbale it's not needed anyway as there is no disk drive, but I could imagine physical games wouldn't work without it(?)

While I'm typing already, I forgot to write an update again....

Video Output

Soooo... on the FPGA side I have found and fixed the issues from the last update.

The noise in the image was actually just a timing issue when driving the screen, as seen in my last edit.
The artifacts and lag every now and then were caused by frame drops in GTA. This is something I didn't think about initially, but now it makes sense. For PAL, the video output is fixed at 50Hz - independent of the ingame framerate. For a 25fps game this means that a frame consisting of 2 fields is output at 25Hz.
Now to the issue: When the game framerate drops below 25fps and the video output is fixed at 25Hz, some fields/frames will need to be sent twice to keep the output stable (most likely applicable to FMV scenes too).
In my first deinterlacer implementation, my assumption was that a frame always starts when HSYNC is low directly after a rising edge of VSYNC. My algorithm would then stitch the following 2 fields together and display them. I think usually this assumption would be correct, but in the case of lag spikes, this cannot be guaranteed. In the worst case, the deinterlacer would then combine fields from 2 completely different frames, which causes the combing artifacts and the additional lag.

My first fix for this was to always stich 2 subsequent fields together, which also doubles the output framerate from 25Hz to 50Hz. It works OK for games that run at 50fps, but for <25fps games it always generates combing artifacts, because in 50% of the time 2 different frames are combined.

The next implementation was just a simple line double and that was the point where I discovered all this. The line double had no issues at all, because it was displaying 1:1 the input, just line doubled. It looks horrible, though....

A couple of iterations of various algorithms later I started feeling the need for a motion adaptive deinterlacer, as it would fix most of my issues with the weave deinterlacer and the quality issues of the line doubler. This is exactly what I did and here is a demonstration of my motion adaptive deinterlacer algorithm:


It's a hybrid between a 2-field and 3-field motion adaptive deinterlacer. Ideally it would have been a 5-field algorithm, but I don't have the memory bandwith to pull that off.
The performance is still pretty good, the 3-field part handles most of the motion detection and in the cases where it misses some motion (fast moving objects, mainly in 50fps games), the 2-field part kicks in and detects motion. When motion is detected, I'm doing a simple interpolation between the pixels above and below. When no motion is detected, weave deinterlacing is performed.
Another thing to mention is that the algorithm calculates every missing pixel of a field individually, compared to some implementations that group a bunch of pixels together.
The "calibration" is based on two thresholds, one that sets the allowed motion value and one that inhibits the noisy nature of the 2-field motion detector. I adjusted both to make the result look good in most situations, but it still needs some tweaking.

In some parts of the video I modified the calculations to display movement detected by the 3-field part in pink and the output of the 2-field detector yellow. It performs exceptionally well with 50fps games, apart from some minor combing present on very fast moving objects & some noise caused by false detections. In GTA SA (~25fps) it looks great too, but there (last quarter of the video) you can start to see the main weakness of the algorithm: during lag spikes, when a field is displayed multiple times, the motion detector cannot detect any motion, which leads to the flickering you see in some scenes. It's really only noticable when the interpolated pixels are colored pink, but it still bugs me a little bit. Proper motion adaptive deinterlacers have some sort of "decay" function that stores the motion values for each frame and gradually adjusts them according to the current motion value.
Mine doesn't do that right now, but I was thinking about how to best implement it & it might be possible to do it by rewriting parts of the framebuffer scheduler...

I also got two new displays from here and tested them; the display in the video is actually a new one. Overall they look OK - viewing angles are perfect, colors are ok, brightness is good - and they have somewhat decent datasheets. What really bothers me though, is the dithering they do. When first turning them on, the flickering caused by it is very distracting, but it seems to disappear when the displays are on for a while. Still not comparable to the outstanding image quality I got with the old waveshare display, but much better than some other displays I've used in the past.

There still a shitload of work ahead for the video processor:

• look into implementing a "decay" for the motion values
• write a (bilinear?) scaler (especially needed for PAL)
• implement support for 480p and 480i
  • Everything I wrote so far should be natively compatible with NTSC, but I have no way right now to measure all the parameters I need to know in order to make the input state machine lock onto the video stream. For 480p I will need to change the fsm of the deinterlacer to just pass the data through for progressive video
• the input state machine will need some refactoring, as the new screens are a bit picky when it comes to video dropout during boot or while launching a game. I will need to reset the video processor and the display when the fsm loses synchronisation to the input signal
• I will still need a module that enables me to draw sprites onto the screen via the syscon (e.g. battery level)

I think with the motion adaptive deinterlacer it's looking pretty good already - that one caused a lot of sleepless nights...The next headache will for sure be the scaler...

Next topic:

To not lose momentum regarding the electrical/mechanical design, I started to work on the new mainboard revision with slightly reduced priority. I already copied the circuits from all my extension boards into the schematics (which was a big pain in the ass - libraries) and started working on a first housing concept to define the board outline and component placement. I would say the schematics are about 80% done and I'm sitting at exactly 30 pages right now. Cross checking this one will definitely take some time and I'm fully expecting this to not work first time, so I will be adding a lot of debugging/troubleshooting features to be sure. The mainboard will be about the size of a 5 inch LCD, most likely a bit bigger for mounting purposes.
Usually I don't share very preliminary stuff, but here is a very early concept for the mainboard, nothing is routed, the connectors are placeholders, and it will most likely still change a lot:

I have a rough drawing of the housing front view, but sadly I cannot share it as solidworks refuses to launch since the last (forced) update on monday.

In short, this is the idea:

• 3 or 4 piece construction; the mainboard, display, gamepad and batteries will be mounted in their own subassembly, call it "skeleton", which is sandwiched between the top and bottom housing. This allows for easy debugging, assembly and shell swaps.
• The holes around the edges of the first mainboard concept are meant to have 2 purposes:
  • mount the mainboard to the display subassembly
  • securely attach and ground the heatspreader/shield I was experimenting with in one of my previous posts
• The SD card slots will probably be on their own rigid/flex PCB, which attaches to the expansion connector in the top left
• 2 18650 or 21700 cells; replaceable. The housing will probably have a cell on each side in the grips, which would make the grips ~30mm thick; the center would then be about ~16mm thick
  • 18560 vs. 21700: I did a quick runtime test to see which battery would satisfy my 3h runtime requirement. The test was done with 2 2500mAh 18650 cells from my junk pile (they are from ~2013, left fully discharged for a while) and I managed to reach about 2.5h in GTA SA at full display brighness. This makes me believe that 2 3500mAh 18650s would be sufficient, in case I cannot fit 21700 cells
• For the buttons I'm planning to use PSVita buttons. I actually ordered and received some for testing. I'm considering these tact switches for the dpad and action buttons, after trying all variants I concluded that I prefer the 100gf variant. Start, select and power will most likely use something like this. The shoulder buttons and triggers are not decided yet
• The analog sticks will for sure be hall effect switch sticks, probably in the XBOX arrangement. I got myself these and I quite like the look and feel compared to the Gulikit sticks
• For cooling I'm planning to use a switch lite fan, controlled via PWM

Overall the progress slowed down a little due to the video processor implementation, but I'm having a lot of fun doing it It's good though to do some electrical/mechanical design again, I already started writing "if() then" accidentally in my C code recently....too much VHDL

 

[wisi]

/CSPPC which is also /CS13 in some way, seems to go to pin 12 of the BOOT ROM (SCPH-790xx).
Pins 13,14 seem to both be connected to A22, according to some measurements of mine from many years back (I could be wrong about this - I wasn't too sure about it back then too).

The DVD ROM contains contains the rom filesystems rom1, rom2, erom, and only the DVD Player(for playing DVD-Video discs) and the Chinese fonts (SCPH-50009) are on it, from what I could find out. You may want to ask about such questions on PS2 Scene discord or psx-place.com. The DVD Player is used in some disc exploits, but given that you don't have a CDVD drive, it should be mostly ok to remove (it shouldn't be needed by any games but best test at least a few or ask somebody who knows for sure).

 

[thedrew]

Insane man, really impressive and inspiring work as usual! That digital video is looking CRISPY.

I have those tact switches (100gf) ones installed in a couple of my portables and they are the perfect feel in my opinion, good choice.

Sounds like you're satisfied with the viewing angles of your screen but not the colors. That's the problem I've had with these small IPS panels UNTIL I found a couple small QLED panels, one 4.3" and one 5" with both having the same resolution of 800x480. Maybe I can suggest looking into the 5" QLED panel? Just know, once you go QLED, you can't go back... everything else just looks like trash lol.

https://www.elecrow.com/5-inch-qled-quantum-dot-display-800-x-480-resistive-touch-screen.html

I have that 5" QLED screen installed in my latest portable and it is gorgeous. There's a little bit of work involved since the the screen ships with a TN screen but an IPS LCD can be transferred in since all we care about is retaining the QLED filters. I go over it here as well as some example shots compared to a standard Waveshare IPS 4.3" screen if your interested in scrolling through this thread:

https://bitbuilt.net/forums/index.php?threads/priimiium-v1.5964/

The FPGA video + the QLED screen would be the end all be all for best display solution for the PS2, and who else would be the best candidate for this!?

 

[Tschicki]

/CSPPC which is also /CS13 in some way, seems to go to pin 12 of the BOOT ROM (SCPH-790xx).
Pins 13,14 seem to both be connected to A22, according to some measurements of mine from many years back (I could be wrong about this - I wasn't too sure about it back then too).

That would finally solve the mystery around pins 12, 13 and 14! One day someone should really test that bios mod with a disk drive, it's completely unknown to me what would happen in that case. With OPL it works great so far (for more than a year now) - and I've played a lot of games on it for far longer than I dare to admit
So for the next revision I will probably not change it, but I do have quite some questions - it's just a shame that such information is not easily available and will probably be lost with time.

Insane man, really impressive and inspiring work as usual! That digital video is looking CRISPY.

I have those tact switches (100gf) ones installed in a couple of my portables and they are the perfect feel in my opinion, good choice.

Sounds like you're satisfied with the viewing angles of your screen but not the colors. That's the problem I've had with these small IPS panels UNTIL I found a couple small QLED panels, one 4.3" and one 5" with both having the same resolution of 800x480. Maybe I can suggest looking into the 5" QLED panel? Just know, once you go QLED, you can't go back... everything else just looks like trash lol.

https://www.elecrow.com/5-inch-qled-quantum-dot-display-800-x-480-resistive-touch-screen.html

I have that 5" QLED screen installed in my latest portable and it is gorgeous. There's a little bit of work involved since the the screen ships with a TN screen but an IPS LCD can be transferred in since all we care about is retaining the QLED filters. I go over it here as well as some example shots compared to a standard Waveshare IPS 4.3" screen if your interested in scrolling through this thread:

https://bitbuilt.net/forums/index.php?threads/priimiium-v1.5964/

The FPGA video + the QLED screen would be the end all be all for best display solution for the PS2, and who else would be the best candidate for this!?

Thanks for the suggestion!
I would be surprised if the QLED backlight & filters can fix the horrible dithering of these LCDs and the mod doesn't sound like a very economical solution at this point - but I'm willing to give it a shot!
If you can confirm that this is the same model, I will order one. Anyway I orderd 2 LCDs, so I can sacrifice one for science
I may also order another one of those waveshare 5" DPI LCDs, as the image quality of the one I have is much better than the new screens. However, it's a couple years old and I don't know whether they use different panels now. Sadly mine has a broken row of pixels after a little accident...

 

[thedrew]

Yes you're right, the AliExpress link you posted is the same seller of the link I posted, just on AliExpress. Also won't solve the dithering issue you mentioned but the colors would be popping as well as a slight increase in contrast!

 

[Lightning]

Lord have mercy!! To think we used to consider the PS2 such a black box, and then you come along and just blow all it's secrets wide open! One wonders how one man can posses such keen insight.

Do these BIOS mods you've been working on have the ability to give a 70000 HD boot capability? Someone put a 50000 BIOS on a 70000, and despite a few bugs, it apparently gained the ability to use FHDB. Just wondering, since you would seem to be exactly the right person to ask!

Anyway, I am VERY impressed with your direct LCD interface. I always wondered if that was possible. Which is to say nothing of all the other amazing things you've already done! This is easily the most interesting thread I've ever seen. Awaiting eagerly your every word.