#434 xscpu64+reu gives segfault

[Zed Yago]

I tried "franz craps" ( http://csdb.dk/release/?id=117421 ) with REU enabled, and it crashed scpu64 with a segfault.
Used linux (debian), and nightly build (from today, 4.6.2013)

tried also x64+REU, and it works.

(the REU is only used to clear/color the screen. at init, the demo fills one page with 00..FF, and later it uses this to erase a screen, keeping REU-address constant)

[Soci/Singular]

Known limitation of the emulation as I don't have a REU to test the timing. I think this combination needs to be disabled for now.

[Zed Yago]

the timing is pretty easy, 1 cycle per transferred byte.
for this particular demo, timing isnt important.

anyway, isnt it possible to use the same sources for the reu for scpu, as for x64?

[gpz]

"isnt it possible to use the same sources for the reu for scpu, as for x64?"
for the reu emulation itself, ofcourse (anything else would be stupid really) - however, as soci said, the timing isnt easy (nor documented anywhere). for example when/how REU transfers are interrupted by refresh cycles and/or VIC fetches when scpu is used. (that said, even the timing of ordinary cpu instructions is broken at the moment, as certain RAM access penalties are not emulated at all)

[Zed Yago]

the main point of xscpu64 for me, is to have a faster running cpu with a c64, i doubt much software (for scpu) requires exact timing..

my personal feature request would be to have a better "warp-mode", where only cpu runs as fast as possible, while all other chips keep going normal, but i disgress.

thanks for putting work into xscpu64, looks like i have to get rid of reu in my next demos :-D

[Soci/Singular]

RAM access penalties for mirroring are ok and tested, but SIMM timing implementation is only based off documentation with page switching delays implemented but with missing periodic refresh cycles.

I think REU should be disabled until there's no information available. I can try to get a REU lended but I don't have access to real hw for testing most of the year ;(

[gpz]

i only noticed there is something wrong (i assumed its ram timing penalties...) when i ran some timing tests on xscpu64 and noticed it gives me wildly different numbers than the real thing ("synthmark", see http://wiki.icomp.de/wiki/C64_Benchmarks)

[Soci/Singular]

Wow, I'll keep that benchmark in my mind for some real hw testing ;) (unrelated to SCPU)

However the numbers presented there are for SCPU V1 which is much slower in some situations. If you enable zeropage/stack mirroring then it's more close in some columns. But some things like the V2 color ram optimization can't be switched off so it's always faster than on V1. I'll cross check it with real hw in a month or so just to be sure ;)

[francesco piccardo]

Reu and Super Cpu emulation still doesn't work. This is very bad because new Sonic 64 would really benefit, I guess

[DarkVision]

Any progress on this? I did some more testing:

xscpu64 \
-default \
-reu -reusize 512 \
-scpu64 "supercpu_dos_204.bin" -simmsize 16

Demo-Programm:

.C:c000  A0 90       LDY #$90
.C:c002  2C A0 91    BIT $91A0
.C:c005  A9 00       LDA #$00
.C:c007  8D 02 DF    STA $DF02
.C:c00a  A2 10       LDX #$10
.C:c00c  8E 03 DF    STX $DF03
.C:c00f  8D 04 DF    STA $DF04
.C:c012  8D 05 DF    STA $DF05
.C:c015  A2 01       LDX #$01
.C:c017  8E 06 DF    STX $DF06
.C:c01a  8D 07 DF    STA $DF07
.C:c01d  A2 80       LDX #$80
.C:c01f  8E 08 DF    STX $DF08
.C:c022  8D 09 DF    STA $DF09
.C:c025  8D 0A DF    STA $DF0A
.C:c028  8C 01 DF    STY $DF01
.C:c02b  AD 00 DF    LDA $DF00
.C:c02e  29 60       AND #$60
.C:c030  F0 F9       BEQ $C02B
.C:c032  60          RTS

The program stores 32Kb in the REU Bank#1 (sys49152) or copies it from the REU back into the C64 memory (sys49155).

Enter in BASIC:

sys49152:sys49155

This seem to work... RAM is copied to REU and back to C64.

If you do this in a loop like:

10 for i=0 to 99
20 print i
30 sys49152:sys49155
40 next

it will sooner or later crash with a "segmentation fault" and vice will get closed.

I also tested that "franz craps" demo from the original post and it crashes here too.

Since this does not work for nearly 10 years and is still not 100% working (tested with r42846) wouldn't it be better to disable the REU feature for xscpu64 ?

And yes... people try that combination and have to be told that it hasn't worked for years.

GeoRAM is working, it is just the REU emulation.

[Marco van den Heuvel]

Should be fixed in rev 42850, please svn up, compile and re-test.

[DarkVision]

Tested with 42851 and the above franz-demo and sample testcase and it is looking good.

I also tried to boot into GEOS and can now make use of CREU, GeoRAM and RAMCard-RAM at the same time.

Thanks a lot for this fix!

[Marco van den Heuvel]

thank you for bringing this back up, it looks like this bug report got made during my 'too busy to do stuff for vice' period and therefor didn't know about it, and since I recently fixed dma for x128 this particular fix was fairly easy.

Thank you for testing, I'm gonna close this bug report now.

[DarkVision]

Looks like the bug is not completely fixed. I did some more testing an when using the xscpu64 in 1MHz the franzcraps demo still crashes.

You can reproduce the issue using this command:

xscpu64 \
-default \
+speedswitch \
-scpu64 "supercpu_dos_204.bin" \
-simmsize 16 \
-reu -reusize 16384 \
-autostart-delay 20 franzcraps.prg 

SuperCPU will start in 1MHz mode and will autoload the franzcraps demo. The screen will be filled with black color, wait until the color has reached the lower right corner.

xscpu64 will still segfault in 1MHz mode.

If you replace +speedswitch with -speedswitch SuperCPU will start in 20MHz mode and the demo will work as expected.

The crash happens in the following code as soon as the program writes to register $df01.

...
.C:2309  A2 09       LDX #$09
.C:230b  BD 15 23    LDA $2315,X
.C:230e  9D 01 DF    STA $DF01,X
.C:2311  CA          DEX
.C:2312  10 F7       BPL $230B
.C:2314  60          RTS
...
>C:2315  90 00 2f 00  00 00 00 01  00 00

Tested with r42856, Linux 64Bit

[Marco van den Heuvel]

Thank you for bringing that part to my attention.

Should be fixed in rev 42857, please svn up, compile and re-test.

[DarkVision]

Looks good...

There was another issue with this D64 from here:
https://www.lyonlabs.org/commodore/onrequest/geos/index.html#os

geos-supercpu.d64

This is a GEOS boot disk prepared for the SuperCPU.

When using this command:

xscpu64 \
-default \
-scpu64 "supercpu_dos_204.bin" \
-simmsize 16 \
-reu -reusize 16384 \
-autostart-delay 20 \
-8 geos-supercpu.d64 geos-supercpu.d64:*

The system will crash after GEOS was loaded... with 42857 this D64 seem to work fine... in 1MHz and 20MHz mode.

Thanks again for that fix...

[Marco van den Heuvel]

YAY, 2 bugs with 1 hammer ;)

Closing this now.