NO$PSX V2.1 Released (20th Aug 2022)

[nocash]

Anybody tried the above test version? I'd really like to get that problem sorted out!

[Administrator]

All I get is

Code: Select all

debug
tv
fonts
b
bb

and then it closes the debugger, but I still need to kill it via task manager because it's secretly still running.

[null]

Anybody tried the above test version?

I tried the no$gba/no$psx test versions, but there's no crashing and task manager bugs in my Win10.

There's a stuttering audio bug in no$gba with NDS game.

Thanks for supporting CHD format!! It's working fine.

[Squaresoft74]

Anybody tried the above test version? I'd really like to get that problem sorted out!

Windows 10 22H2 x64:

Code: Select all

debug
tv
fonts
a
aa
b
bb
c
aspi
done

No crashing nor task manager bugs here.

[nocash]

All I get is

Code: Select all

debug
tv
fonts
b
bb

Thank you! That problem has been lurking around for several years, but now I know what hangs... it's this part:

Code: Select all

        MFG 'b'
 push offset patched_font_fname ;\remove font
 call RemoveFontResourceA       ;/
        MFG 'bb'
 push 0                         ; push 0                         ;
 push WM_FONTCHANGE             ; broadcast fontchange message
 push HWND_BROADCAST            ;
 call SendMessageA              ;/
        ;(hangs in above call)

That's coded exactly as recommended in the "Win32 Programmer's Reference", and I wouldn't have expected that the SendMessage call could hang... but actually it can happen, as described here: https://stackoverflow.com/questions/195 ... cast-hangs
Apparently you have another program that has locked up or refuses the handle it's message queue (you should theoretically see that in task manager, like tasks marked "not responding" or the like). And that's causing a ripple effect where the senders will also hang when sending broadcast messages to the hanging task.

I'll use SendNotifyMessage instead of SendMessage for broadcasts, that should work the same, but won't hang if any of the receivers fail to process the message (it might flood the message queue of the hanging task, but that's not my problem).

Bigger problem: The Win32 ref says that SendNotifyMessage isn't supported on win32s... so that function may kill support for windows 3.1 damnit : /
I haven't tested for a while, but the older no$xxx should work (or almost work) with win3.1 (when having the 32bit win32s upgrade installed). If neccessary, I could fallback to use SendMessage instead of SendNotifyMessage when detecting that old OS, but I don't currently have a PC set up for testing that stuff.

Windows 10 22H2 x64:

Code: Select all

debug
tv
fonts
a
aa
b
bb
c
aspi
done

No crashing nor task manager bugs here.

Good to know. Then it appears to be normally working, and only hangs if another task is hanging.

whenever I close NO$PSX, the program never closes properly. It closes the game window and disassembler, but the TTY output window hangs

The TTY window (and Help window and others) are normally automatically closed when reaching ExitProcess. Anyways, I've added code for closing them before ExitProcess yesterday (the main advantage is that it will now restore the keyboard focus to the correct window).

[Administrator]

Detecting the OS and applying the correct code to support it would be ideal, that way NO$PSX still works under Win16 systems. No point ditching Win16 support just because the exit code is broken on modern systems.

[nocash]

I am sure that win32s does at least require a 80386SX processor (hence the name: it's 32bit, and won't work on 16bit computers).
Btw. win32s was really rare ultra-odd exotic stuff, I doubt that more than 5-10 people (myself included) have ever used or supported it.
But yes, win32s support would be a neat nonsense feature, but detecting the OS without testing if that function (and other functions) are actually still working would be kinda pointless.

[Administrator]

By the way, version 2.2 is missing from here https://problemkaputt.de/psx.htm

[gwald]

I just tried 2.2 from the .de site, in winXP it crashes when launching via cmdline with a psx.exe as first param.
dragging and dropping seems to crash the same way.

[Administrator]

I just tried 2.2 from the .de site, in winXP it crashes when launching via cmdline with a psx.exe as first param.
dragging and dropping seems to crash the same way.

That's the same issue I'm having
I'll have to stick with V2.1 until NO$CASH can try it himself under Windows.

[Administrator]

Just an update regarding the broken volume levels. It seems I overlooked the volume slider ('Sound Volume' seen in my screenshot below) within the NO$PSX options. Sliding it back to full volume restored the issue. It operates independently from the Windows volume slider which is why I was so confused why I couldn't hear any audio output from NO$PSX anymore.

NO$PSX V2.2 however is still completely broken for me and fails to run any game (instantly crashes) which is why I've stuck with V2.1 for the time being.

[nocash]

This the wrong thread, for no$psx v2.1. I guess that's because the v2.1 thread is sticky and appears above v2.2.

I just tried 2.2 from the .de site, in winXP it crashes when launching via cmdline with a psx.exe as first param.
dragging and dropping seems to crash the same way.

Thanks! I'll fix that. No$psx v2.2 is allocating larger cue sheets, but the commandline loading did occur before doing that allocation.

Just an update regarding the broken volume levels. It seems I overlooked the volume slider... It operates independently from the Windows volume slider

No surprise then. Though I had thought that the newer windows versions would have that slider synced with one of the windows hardware mixer volume sliders.

[mkultimate]

They could add the FPS counter

[alexfree]

Not sure if this is the best place to suggest this, but I found some interesting info while researching CD-R stuff in relation to the PSX at the SCEA BBS archive.

The NO$PSXSPX should be updated since it is now concrete that the seek table is optimized for 71 minute discs, not 72 minutes like it says at https://problemkaputt.de/psx-spx.htm#cd ... nsetimings

3/29/95 2:34 PM
*Why 71 minute? Why 900e?
BillÊ"Angus" Guschwan
CD
>I had 2 CD questions: >1) Can we use the CDW950E with the CDGEN software? Why or why
not?
CD-ROM Generator doesn't support CDW-950E. CDW-950E doesn't have compatibility in SCSI
protocol and doesn't have capability to create master disc.
>2) Why do we need to use 71 minute media? Some people like to use the cheaper >74 minute
media. Can you tell me why we need the 71 minute CDRs?
The 71min disc is different from 74min at the dencity. PlayStaion is tuned up for 71min and
make reliability for data read. A 74min disc makes error rate more higher.

[nocash]

Interesting. I don't remember where the 72 minute number came from, it's probably one of the many theories about the exact capacity of the original CDs.

As for CDRs, the existing sizes listed on german wikipedia are 21, 23, 63, 71, 74, 80, 90, 99, and 100 minutes,
http://web.archive.org/web/2/http://de. ... /wiki/CD-R (english wikipedia does list only three sizes, 74, 80, and 99 minutes).

The playstation CDROM firmware does - sorts of - also rely on 71 minutes. The early firmware versions did have four seek functions - with four corresponding seek tables - with 71, 77, 85, or 95 minutes.
But all four functions are using only the first 71 table entries, and only one of the functions is used (confusingly, that's the one using the 77 minute table (maybe that's intended for 71 minutes plus 6 minute post-gap, or maybe they've accidently appended 6 garbage entries when computing the table for the PSX stepping motors)).

When using discs with more than 71 minutes, the PSX is using small steps for the outmost minutes (ie. it can read more than 71 minutes, but seeking won't be fast).

Oh, and to verify the 71 minute number in practice.. having a quick look at a few PSX games... the largest one I've found is Judge Dredd (with 70:53 minutes). I've checked only a few dozen games though.
If somebody has a larger collection or database, please check:
What is the largest PSX disc you can find?

[alexfree]

Interesting. I don't remember where the 72 minute number came from, it's probably one of the many theories about the exact capacity of the original CDs.

As for CDRs, the existing sizes listed on german wikipedia are 21, 23, 63, 71, 74, 80, 90, 99, and 100 minutes,
http://web.archive.org/web/2/http://de. ... /wiki/CD-R (english wikipedia does list only three sizes, 74, 80, and 99 minutes).

The playstation CDROM firmware does - sorts of - also rely on 71 minutes. The early firmware versions did have four seek functions - with four corresponding seek tables - with 71, 77, 85, or 95 minutes.
But all four functions are using only the first 71 table entries, and only one of the functions is used (confusingly, that's the one using the 77 minute table (maybe that's intended for 71 minutes plus 6 minute post-gap, or maybe they've accidently appended 6 garbage entries when computing the table for the PSX stepping motors)).

When using discs with more than 71 minutes, the PSX is using small steps for the outmost minutes (ie. it can read more than 71 minutes, but seeking won't be fast).

Oh, and to verify the 71 minute number in practice.. having a quick look at a few PSX games... the largest one I've found is Judge Dredd (with 70:53 minutes). I've checked only a few dozen games though.
If somebody has a larger collection or database, please check:
What is the largest PSX disc you can find?

The PoPorogue game is 702.8 MB (702,787,008 bytes). Google search psx redump archive.org and you will find the actual game.

Also, Tekken 3

Track01: 632.5 MB (632,532,768 bytes)
Track 02: 27.7 MB (27,701,856 bytes)
Track 03: 28.0 MB (28,042,896 bytes)

At least with Tekken 3 (but probably with PoPoRogue as well but I didn't look) the last of the disc image is a dummy track for the don't seek in the last 3 minutes thing AFAICT.


I'm not sure if your aware but the PS2 actually does have issues reading the last part of a burned 80 minute CD-R if the last files are not a dummy file, see: https://github.com/socram8888/tonyhax/issues/24 and my fix: https://alex-free.github.io/psx80mp . The PSX seems to not have the same issues in my experience,

[nocash]

Those aren't anywhere near 71 minutes, the PoPorogue http://redump.org/disc/1552/ page does even tell you that the track is only 66:24:04 tall.
Counting the size in bytes isn't too reliable as the actual length depends on the amount of bytes per sector. Anyways, the Judge Dredd binary is 750,048,096 bytes tall (that, using 930h-byte sectors).

[alexfree]

Those aren't anywhere near 71 minutes, the PoPorogue http://redump.org/disc/1552/ page does even tell you that the track is only 66:24:04 tall.
Counting the size in bytes isn't too reliable as the actual length depends on the amount of bytes per sector. Anyways, the Judge Dredd binary is 750,048,096 bytes tall (that, using 930h-byte sectors).

Right, makes sense. I think that every game is sub 71 minutes in that case.

Also, have you seen these?

s-l1600.jpg

s-l1600-6.jpg

s-l1600-7.jpg

s-l1600-8.jpg

[alexfree]

Interesting. I don't remember where the 72 minute number came from, it's probably one of the many theories about the exact capacity of the original CDs.

As for CDRs, the existing sizes listed on german wikipedia are 21, 23, 63, 71, 74, 80, 90, 99, and 100 minutes,
http://web.archive.org/web/2/http://de. ... /wiki/CD-R (english wikipedia does list only three sizes, 74, 80, and 99 minutes).

The playstation CDROM firmware does - sorts of - also rely on 71 minutes. The early firmware versions did have four seek functions - with four corresponding seek tables - with 71, 77, 85, or 95 minutes.
But all four functions are using only the first 71 table entries, and only one of the functions is used (confusingly, that's the one using the 77 minute table (maybe that's intended for 71 minutes plus 6 minute post-gap, or maybe they've accidently appended 6 garbage entries when computing the table for the PSX stepping motors)).

When using discs with more than 71 minutes, the PSX is using small steps for the outmost minutes (ie. it can read more than 71 minutes, but seeking won't be fast).

Oh, and to verify the 71 minute number in practice.. having a quick look at a few PSX games... the largest one I've found is Judge Dredd (with 70:53 minutes). I've checked only a few dozen games though.
If somebody has a larger collection or database, please check:
What is the largest PSX disc you can find?

I bought a 'PlayStation Master Disc 71PS', the ones used for testing on the debugging station/sending out to Sony to make the CD-ROMs, and I can confirm that they are 71 minutes long.

ATIP info from disk:
Indicated writing power: 4
Is not unrestricted
Is not erasable
ATIP start of lead in: -11849 (97:24/01)
ATIP start of lead out: 319725 (71:05/00)
Disk type: Long strategy type (Cyanine, AZO or similar)
Manuf. index: 25
Manufacturer: Taiyo Yuden Company Limited

Screenshot from 2023-09-22 16-08-45.png

https://gbatemp.net/threads/do-modern-b ... t-10252624