unknownbrackets / ps2autotests

A set of test programs run on a PS2, with accompanying results.
ISC License
25 stars 7 forks source link

Added GS SIGNAL register test #33

Closed jpd002 closed 8 years ago

jpd002 commented 8 years ago

As discussed in #31, this is a first shot of what GIF packet construction could look like.

Not quite sure about the register value generation in gsregs.h that uses defines. The alternative was to use functions, but I was thinking that might be a bit heavy.

Anyways, I'm open to all your suggestions, so, just tell me what you think!

unknownbrackets commented 8 years ago

Hmm. I definitely feel like it'd be nicer to specify the regs in a different way on the tag - ideally more typesafe. But it's tricky, since you're building a structure which will have nloop rows.

It might make sense for it to have methods which "build" the active tag, and have a method to init a new tag. I'm not sure though, been busy lately so haven't thought about this properly yet.

An idea, some of which I'm not liking:

// GIFtag(u16 nloop, DataFormat fmt, bool last, RegDesc r0 = REG_INVALID, RegDesc r1 = REG_INVALID, ... RegDesc r15 = REG_INVALID);
packet.GIFtag(1, GIF::FMT_PACKED, true, GIF::REG_AD);
packet.SetPrim(GS::PRIM_LINE);

It needs a way to add raw data too, so we can test other bits of the tag. But yeah, I think AD makes sense just taking a 64 bit value. Though, I think ideally they can be quick funcs under GS:: rather than defines, like u64 SIGNAL(u32 id, u32 msk) { return (u64)id | ((u64)idmsk << 32); }.

packet.PackedAD(GS::REG_SIGNAL, GS::SIGNAL(1234, 5768));

Hmm. It'd be awesome if it were somehow typesafe, but there are a ton of registers, so that seems like a pain. Could be something like GS::RegData SIGNAL(u32 id, u32 msk) { return RegData(GS::REG_SIGNAL, (u64)id | ((u64)idmsk << 32)); } and then packet.PackedAD(GS::SIGNAL(1234, 5678));. That seems cleanest but likely not worth the hassle, and would still want the alternative of a reg and data to add raw.

-[Unknown]

jpd002 commented 8 years ago

Thanks for your comments. Following your input, I've made some changes to the branch:

Well, tell me what you think! There's surely a way to make this even better.

unknownbrackets commented 8 years ago

Cool. I think this is a pretty good starting point, we may find ways to make it better as we work with it more but the important thing is that I think tests written this way will be clear enough for someone to read and have an idea what's being tested.

To be fair, some of the CPU tests are maybe not beautiful (RRI_, etc.) but it's at least pretty clear what's being tested.

Thanks.

-[Unknown]