-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mvp: the path to the triangle #17
Comments
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? |
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
right, uh. here's where we get into awkwardness.
|
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. |
I've found the pcsx2 debugger to be clumsy, but beggars cannot be choosers.
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.The text was updated successfully, but these errors were encountered: