v10 rough timetable

[ppgrainbow]

It works pretty well in PCem-X, though OBattler has drastically modified it.

PCem-X was only used with r188 (last updated on 2015-01-10) and I don't think that it has been updated ever since.

[Battler]

- ppgrainbow: That's absolutely false. PCem-X keeps being updated. Look at our GitHub ( https://github.com/OBattler/PCem-X ) for the latest source.

[ppgrainbow]

- ppgrainbow: That's absolutely false. PCem-X keeps being updated. Look at our GitHub ( https://github.com/OBattler/PCem-X ) for the latest source.

I didn't look correctly, but thanks for telling me.

[neozeed]

Looks like some kind of race condition in the CD thread?

Code: Select all

D:\pcem>gdb PCem.exe
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from D:\pcem\pcem.exe...done.
(gdb) r
Starting program: D:\pcem/pcem.exe
[New Thread 9376.0x2bf4]
[New Thread 9376.0x12c8]
[New Thread 9376.0x1c3c]
[New Thread 9376.0x2edc]
[New Thread 9376.0x2fcc]
[New Thread 9376.0x2294]
[New Thread 9376.0x1950]
[New Thread 9376.0x1654]
[New Thread 9376.0x2320]
[New Thread 9376.0x1a6c]
[New Thread 9376.0x195c]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 9376.0x195c]
0x0052c2a6 in sound_cd_thread (param=0x0) at sound.c:104
104     {
(gdb) l
99              cd_vol_l = vol_l;
100             cd_vol_r = vol_r;
101     }
102
103     static void sound_cd_thread(void *param)
104     {
105             while (1)
106             {
107                     int c;
108
(gdb) bt
#0  0x0052c2a6 in sound_cd_thread (param=0x0) at sound.c:104
#1  0x778d6fde in msvcrt!_beginthread () from C:\WINDOWS\SysWOW64\msvcrt.dll
#2  0x778d70b1 in msvcrt!_endthread () from C:\WINDOWS\SysWOW64\msvcrt.dll
#3  0x77bc3744 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SysWOW64\kernel32.dll
Backtrace stopped: frame did not save the PC
(gdb) quit
A debugging session is active.

        Inferior 1 [process 9376] will be killed.

I don't always get this crash, but when I do it shows the call stack as endthread/beginthread and the head of sound_cd_thread. I don't see why it's happening. I've tried making sound_reset contain a kill thread

Code: Select all

thread_kill(sound_cd_thread_h);

but it didn't matter. I've tried re-compiling sound.c with -O0 and tried altering the stack size. Sometimes it works, other times it doesn't.

I don't see any mutex's, maybe I'm looking for the wrong things? Maybe other threads are trying to access some of the same things?

[startmenu]

Sound Blaster AWE32&64 could address up to 28M memory (according to wikipedia), but PCem only has 4M Audio Memory as I saw on soundfront manager( SBAWE driver for win3.1). So, do you have the intention to add a configurable Audio Memory to PCem v10?

[SarahWalker]

AWE32 RAM size is now configurable as of rev 328.

[startmenu]

Is there any other V10 performance targets you want to hit?

[SarahWalker]

No, there won't be any more optimisations before v10.

[SarahWalker]

v10 is now feature frozen, only bug fixes from now until release.

[SarahWalker]

Quick timetable update, v10 will be pushed out probably to mid-October, as I will be moving house shortly and won't have proper internet access for a bit.

[FredPJ]

A counterintuitive UI nuisance not worth a new thread:
When saving IMG (hard disk image) or CFG (configuration) files, only typing the name of the file without the extension will save the file without any extension.
So for example in this case:

It will save a file named "hddname." and not the expected "hddname.img", unless you manually type the ".img" extension.