Open Ravenslofty opened 4 months ago
This looks like a good base to start work, thanks! This will be a sizeable project but looks doable. I'd say this is ordered in descending priority (with debugging being highest priority) which makes a lot of sense. I was going to create a ticket for this and begin with some light research into what debugging facilities would be available to us (such as ps2sdk for emulation, ps2link for remote real-hardware, etc). What do you think?
I'd say this is ordered in descending priority (with debugging being highest priority) which makes a lot of sense.
chronological ordering was what I had in mind; it makes little sense to start with the triangle without any of the infrastructure in place for it :p
I was going to create a ticket for this and begin with some light research into what debugging facilities would be available to us (such as ps2sdk for emulation, ps2link for remote real-hardware, etc). What do you think?
right, uh. here's where we get into awkwardness.
println!
debugging is painful because there is so much stuff to do to get that far. I have an idea of the path of least agony, but... how good are you with a soldering iron?right, uh. here's where we get into awkwardness.
* ps2sdk is an excellent resource, but directly using or linking to ps2sdk code won't work because ps2sdk has its own toolchain which is not ABI compatible with Rust, and that's a rabbit hole I have spent long enough in already. * ps2link is nice, but we run into a bit of an issue: AFAICT ps2link registers itself as a BIOS thread, and we want to claim all the memory available, so realistically it would be little more than a remote bootloader. (...it would be nice to have a shorter load chain than FreeMCBoot into wLaunchELF into PS2Link into Prussia...). the biggest thing is that even `println!` debugging is painful because there is _so much stuff_ to do to get that far. I have an idea, but... how good are you with a soldering iron?
Oh no, I didn't mean using ps2sdk code/linking to it. I can only imagine the nightmarish can of worms that we'd open if we tried that, and that's assuming it were compatible in the first place. I meant more in terms of looking at what their approach to debugging support/developer QoL was and seeing if their ideas would be compatible or not with a Rust environment. Regarding ps2link, I hadn't considered that detail about it, my bad.
Would pcsx2 still be a good option for debugging you think? I think I remember it offering views into the disassembled code loaded in memory and to the registers themselves (it's not real hardware, but for high-level coding I suppose it would be acceptable).
Regarding the soldering iron, I'm guessing you're referring to soldering an interface to the serial pads on the ps2 motherboard? Came across that thread a year ago myself. Looks cool, but I don't yet have the right skills for such soldering.
Would pcsx2 still be a good option for debugging you think?
I've found the pcsx2 debugger to be clumsy, but beggars cannot be choosers.
Regarding the soldering iron, I'm guessing you're referring to soldering an interface to the serial pads on the ps2 motherboard? Came across that thread a year ago myself. Looks cool, but I don't yet have the right skills for such soldering.
if you're planning to be in this for the long haul, then it might be a useful skill to learn. a seven-segment display clock kit is usually pretty cheap, if you want something semi-disposable to practice on.
other than that, the methods of reaching the outside world are limited: trying to use the GS for printing information seems like a bit of a chicken-and-egg situation; something like TCP/IP is a pretty major undertaking which would also require us to talk to the IOP; USB doesn't work because the PS2 is a host and not a client.
I'll definitely be practicing on my soldering, both for this and for other projects. I'd like to contribute to this as much as possible since ps2 software has been something I wanted to develop for a long while now so I want to be serious about this.
Regardless of what comes first, a place to start writing and/or documenting should be the start. Speaking of which, regarding the wiki-located references we discussed a few days ago, I think it would require you to create it and then add me as a contributor. If it's still the preferred option, would you create it please? I'll continue work on the debugger task with a new issue tomorrow maybe.
Created #18 as a start to the exception-handling/debugging effort.
prussia_gs
, reimplementSetGsCrt
for setting screen resolution. (note to self: or do I just have one hugeprussia
crate?)prussia_dma
to improve its safety; while it's apparently possible to directly poke the GS registers to draw things, it's more efficient to transfer things through DMA, since once a DMA transfer is started the EE can do other things. This probably means we need to come up with a DMAtag builder.prussia_gif
orprussia_gs
, provide a GIFtag builder, and then we can provide a GS builder that wraps that. (yes, it's abstractions all the way down)DISPFB1
/DISPFB2
(whichever we choose) to point to that field.