[GGJ 2017] DeathBall

[Xavi92]

Me and a few mates participated on this year's Global Game Jam, and we decided to create a PS1 in less than 48 hours! The result was a 2-player versus arcade game featuring two beach balls fighting for their lifes!

Source code link: https://github.com/Galbar/GGJ-2017
BIN/CUE image: https://github.com/Galbar/GGJ-2017/tree/master/Bin

Short video showing gameplay under real hardware:
https://invidious.snopyta.org/watch?v=tPisBxHv-cI

Screenshots:

[Administrator]

Pretty cool and nice work! I'll add it to the homepage when I have some time.

[Xavi92]

Added link to BIN/CUE image! Tested under real hardware (PSOne), PCSX-R and ePSXe.

Enjoy!

[Xavi92]

Any thoughts?

[likeabaus]

I'll have to give it a shot, when I get a chance and get back to you . 48 hours huh?

[gwald]

I downloaded the 150mg bin/cue zip, why is it so big?
Anyway, it didn't work for me on PCSX nor no$psx.

Nocash PSX Kernel (c) 2008-2014 Martin Korth.
KERNEL SETUP!
Configuration : EvCB=10h TCB=04h
Read Path Table

BOOTSTRAP LOADER Type C Ver 2.1 03-JUL-1994
Read Directory 1
setup file : cdrom:SYSTEM.CNF;1
TCB 00000004h
EVENT 00000006h
STACK 801FF800h
BOOT = cdrom:\DBALL.EXE;1
argument =
KERNEL SETUP!
Configuration : EvCB=06h TCB=04h
boot file : cdrom:\DBALL.EXE;1
EXEC:PC0(80010000h) T_ADDR(80010000h) T_SIZE(00030800h)
boot address : 80010000h 801FF800h
Execute !

S_ADDR(801FF800h) S_SIZE(00000000h)
Initializing PSXSDK...
Read Path Table
SetCDROMHandler
Starting CDROMlib...
PSXSDK testing version !!!
Initializing SPU (Sound Synthesizer)...
SPU/SS Initialized.
Read Directory 5


And stops there, doesn't crash just a black screen


PCSXR (linux 64bit git version) works until it runs the game, "Segmentation fault"



PCSX:
* Running PCSX Version 1.9 (Jun 20 2012).
* Loading memory card /home/xp/.pcsx/memcards/card1.mcd
* Loading memory card /home/xp/.pcsx/memcards/card2.mcd
* Plugins loaded.
* Loaded CD Image: /home/xp/Downloads/Bin/DBALL.bin[+cue].
* Track 01 (DATA) - Start 00:02:00, Length 12:08:71
RGB mode found. id: 18424752, depth: 24
pcsx: ../libpcsxcore/ix86_64/ix86-64.c:158: MEMADDR_OP: Assertion `!isreg || reg != 0' failed.
Aborted


probably just my crappy linux builds

[Xavi92]

The image was made this big on purpose with garbage data (what is usually called like "padding"). I was told that it was easier for the PSX CD-ROM reader to read CDs with more data, and that even some commercial games used this tecnique, as well.
On the other hand, Deathball was tested on PCSX-R, pSX, FPSE (Android emu) and on SCPH-102 (PAL PSOne) and SCPH-5502 (PAL). I recall no$psx was problematic with games made with PSXSDK as long as you used its integrated BIOS. . Sometimes (specially under real hw), the game hangs when loading files - much likely the GPU and/or Vblank ISR are working when BIOS' fopen() is called and that may be causing the freezes. Other than that, the game should work with no problems

[nocash]

The dropbox link doesn't work with Windows 98, it does only show a blank white browser window. Does it require Windows 7?

Hmmm, I always thought that Garbage (and Windows 7) is usually called "bloated", or is that just padding? I don't know what you have padded why/where/how, but, in general, it sounds like a really stupid idea. The only thing that might make sense is appending dummy sectors at the end of image... in case the PSX should have problems when somehow moving past lead-out-area? But if it's a CUE/BIN image, then you should rather use the POSTGAP entry in the CUE sheet, instead of storing those 150 milligrams (?) of zeroes (or even random values and/or error correction info) in the BIN file.

If there's a compatibility issue with PSXSDK and no$psx-kernel... I could probably fix that, if somebody could point me on any non-working PSXSDK programs (well, unless they are too padded for downloading, or on post-internet sites like dropbox or mega).

Doing something in 48 hours sounds neat. More recently I've wasted 1-2 months on some really dumb projects (just porting some open-source code from HLL to ASM, which, I really don't know why it takes me so much time).

[Administrator]

Yeah developers added padding (usually only like 30 MB) to avoid over-shooting on the lead-out area (which is silly), because if you actually wanted to make sure not to over-shoot, the lead-out is usually 300 frames with a post-gap of 150 frames, so it's quite pointless. If anything, I reckon it was a bug in the old libs or perhaps a missing function as part of Sony's old "CDGEN" program.

[Xavi92]

I have added a new, much lighter BIN/CUE image directly on Github (the other >100 MB image was not allowed by Github size limit constraints). Also, I have made some small bugfixes which should fix the hangs caused by loading files. Since y'all have stated that padding is not an useful technique, I will remove Dropbox link as well.

Download the BIN/CUE image here!
https://github.com/Galbar/GGJ-2017/tree/master/Bin

[nocash]

I've got it working in no$psx to reach the screen with Play / Credits buttons, but then it seems to hang there. Or, wait, does it require two joypads, and is supposed to 'hang' with only one joypad?

Thanks to your code, I've found two bugs in my kernel clone, both related to cases where I've tried to reduce loading times...

The first bug (the one where I forgot to push RA before calling a subfunction), occurs in chdir & findfirst functions (where I've changed them not to reload the path table unless the drive door was open). The interesting part is that the bug didn't cause any problems yet, almost looks as if you are the first person having used chdir or findfirst for cdrom.

The second bug occurs because I am tweaking the emulator to spin at 12x speed for kernel loading functions. That's normally working fine, unless a cdrom IRQ occurs right between sending a cdrom command & setting the cdrom "current_task" variable (in that case the kernel thinks that the IRQ belongs to an older command, since the "current_task" wasn't updated yet) (doing it the other way around should fix that issue, ie. first setting "current_task", and then sending the cdrom command... I'll need to fix that in the cdrom seek function... and as it looks... also in several other functions).

The same bug does also exist in original kernel, but it's less likely to cause problems on real hardware because the cdrom IRQs normally won't occur "too soon" after sending cdrom commands (ie. without my 12x speed trick, there's normally enough time for the kernel to set the "current_task" value before the cdrom response IRQ occurs).

But the problem could also occur on real hardware & original kernel, especially if you've any IRQ handlers that take a lot of time before returning from the interrupt. For example, the normal flow would be:
-- kernel sends the cdrom command
-- kernel sets the "current_task" value (usually done just a handful of clock cycles after sending the command)
-- cdrom IRQ occurs (some hundreds or thousands cycles after the above stuff)
But if you are unlucky, some situation like this might happen:
-- kernel sends the cdrom command
-- vblank IRQ occurs and takes a lot of clock cycles before returning
-- cdrom IRQ occurs during vblank IRQ handling (and gets executed right after returning from vblank IRQ)
-- kernel tries to set the "current_task" value, but, no, it's too late since the cdrom IRQ was already executed

[Xavi92]

I've got it working in no$psx to reach the screen with Play / Credits buttons, but then it seems to hang there. Or, wait, does it require two joypads, and is supposed to 'hang' with only one joypad?

It should work both with one or two joypads. In fact, also had the same problem with other PSXSDK-based games. AFAIK, PSXSDK uses SIO for pad management instead of BIOS routines since many versions ago. Could it be somehow related to this?

[nocash]

New no$psx version should work with the DeathBall - but only with one joypad (which makes the game rather unplayable; no$psx has some support for up to 12 joypads when emulating 12 consoles at once, but it still lacks support for more than joypad per console).

Btw. looks as if the loading problem wasn't caused by the "current_task" variable that I had mentioned (though that might also cause problems in rare circumstances), but rather by more serious bug where the kernel clone was acknowleding the cdrom IRQ flags in ports 1F801070h and 1F801803h.Index1 in wrong-order, causing edge-triggered IRQs not to receive new edges if a new IRQ had arrived in the meantime (same problem does also exist in official kernel, but my tweaking for reduced loading times increased the chance that IRQ timings could go wrong).

And the other issue, with defunct joypad input in the games title screen... that was because DeathBall didn't reset the joypad via port 1F80104Ah.bit6, leaving my joypad emu in unitialized state (most other games are doing that reset, whilst the kernel doesn't do that reset (unless when entering the bootmenu), but the power-up /RESET does probably do something equivalent, so your joypad code should be perfectly stable on hardware as-is).

Many thanks for the game! It really helped to find 3-4 serious bugs in the emulation and kernel. I've also had some fun playing it (but I guess it would be even more fun with two players & two joypads).

[Xavi92]

Thanks for your kind words! I'm glad you enjoyed the game.