prussia_bios: Wrapping BIOS calls

[Ravenslofty]

Some open questions:

• Wrap all syscalls? (Even the undocumented ones)
• Wrap useful syscalls? (Nobody cares about _ExceptionEpilogue, right?)
• Implement it all in Rust? (as much as I'd like to, this might bloat executables a bit).

[Ravenslofty]

Syscalls by number (as documented in PS2tek):

• 0x01: ResetEE
• 0x02: SetGsCrt - f5ea1b1
• 0x04: Exit - f77ed8f
• 0x05: _ExceptionEpilogue (useless?)
• 0x06: LoadExecPS2
• 0x07: ExecPS2
• 0x10: AddIntcHandler
• 0x11: RemoveIntcHandler
• 0x12: AddDmacHandler
• 0x13: RemoveDmacHandler
• 0x14: _EnableIntc
• 0x15: _DisableIntc
• 0x16: _EnableDmac
• 0x17: _DisableDmac
• 0x20: CreateThread
• 0x21: DeleteThread
• 0x22: StartThread
• 0x23: ExitThread
• 0x24: ExitDeleteThread
• 0x25: TerminateThread
• 0x26: iTerminateThread
• 0x29: ChangeThreadPriority
• 0x2A: iChangeThreadPriority
• 0x2B: RotateThreadReadyQueue
• 0x2C: _iRotateThreadReadyQueue
• 0x2D: ReleaseWaitThread
• 0x2E: iReleaseWaitThread
• 0x2F: GetThreadId
• 0x30/0x31: ReferThreadStatus/iReferThreadStatus
• 0x32: SleepThread
• 0x33: WakeupThread
• 0x34: iWakeupThread
• 0x35/0x36: CancelWakeupThread/iCancelWakeupThread
• 0x37/0x38: SuspendThread/iSuspendThread
• 0x39: ResumeThread
• 0x3A: iResumeThread
• 0x3B: JoinThread
• 0x3C: InitMainThread
• 0x3D: InitHeap
• 0x3E: EndOfHeap
• 0x40: CreateSema
• 0x41: DeleteSema
• 0x42: SignalSema
• 0x43: iSignalSema
• 0x44: WaitSema
• 0x45: PollSema
• 0x64: FlushCache
• 0x70: GsGetIMR
• 0x71: GsPutIMR
• 0x74: SetSyscall
• 0x78: SifSetDChain
• 0x7B: ExecOSD
• 0x7D: PSMode
• 0x7E: MachineType
• 0x7F: GetMemorySize

[zachary-cauchi]

Hello @Ravenslofty. I'm very new to the PS2 dev scene so my opinion may not carry much weight.

I don't imagine all the syscalls are needed, and some are higher-priority than others. Eventually, most would be desired, but some would be desired sooner than others, so how about a roadmap to plot which syscalls are needed for which desired features (for instance, strings I imagine would require the heap-related syscalls)?

Regarding Rust vs assembly, I don't know how much of a bloat the rust implementation would take. For the time being, I'd say leave it in Rust where the environment is familiar, and then if need be, upgrade it to assembly. For the time being, if file size really is an issue, feature flags may help with stripping away unused functions.

What do you think?

[Ravenslofty]

Hello @Ravenslofty. I'm very new to the PS2 dev scene so my opinion may not carry much weight.

I don't imagine all the syscalls are needed, and some are higher-priority than others. Eventually, most would be desired, but some would be desired sooner than others, so how about a roadmap to plot which syscalls are needed for which desired features (for instance, strings I imagine would require the heap-related syscalls)?

Well, yes and no. See, the PS2 was built around a...modest threading library, and so the heap syscalls interface with that (they set up per-thread heaps). But I think in modern times we would use async/await which maps a bit nicer to the PS2.

Regarding Rust vs assembly, I don't know how much of a bloat the rust implementation would take. For the time being, I'd say leave it in Rust where the environment is familiar, and then if need be, upgrade it to assembly. For the time being, if file size really is an issue, feature flags may help with stripping away unused functions.

What do you think?

There's certainly some mitigation to the bloat of implementing things in Rust: by not depending on any of the PS2 BIOS calls we can treat the space used by the BIOS as free memory and reclaim a megabyte or so of memory.

[zachary-cauchi]

True that about the threading, if memory serves its only a single core cpu (not counting VUs and other bits)?

In that case, I suppose there isn't need for any of the bios calls is there? What would you suggest as a next step?

[Ravenslofty]

I would say there is exactly one useful BIOS call from Prussia's point of view: SetGsCrt, which configures the GS for the relevant video mode.

This can be RIIR'd, but I think it would be easier to do if we had the GS video registers abstracted over, which brings us back to #9...