Oricutron 1.0 (EDIT: Now 1.2)

[iss]

Sorry for the delay but I have to fix the build system after some recent commits.

I'll PM you download links with 32 & 64 bit / SDL1.x & SDL2.x, with debug-info for @Dbug to debug.
The build version is 1.2.1-20201222. By me all works in Win10:

Probably the problem in your tests is with the visual keyboard which I fixed just after my last dev-builds (1.2.1-20200515).
It's fixed 100% for SDL2, with SDL1 it works but if you switch the visual keyboard run-time on/off the SDL surface is lost and the result is black image. Need some free time to investigate the issue.

[Dbug]

Still crashing with the Oricutron_win*-20201222 versions, the SDL1 runs fine, the SDL2 crashes, and for some reason I do not have all the symbols.

The crash happens in the thread "SDLAudioP1" on a memory allocation from the SDL_RunAudio callback:

Code: Select all

 	ntdll.dll!RtlpCreateSplitBlock()	Unknown
 	ntdll.dll!RtlpReAllocateHeap()	Unknown
 	ntdll.dll!RtlpReAllocateHeapInternal()	Unknown
 	ntdll.dll!RtlReAllocateHeap()	Unknown
 	ntdll.dll!RtlpAllocateUserBlockFromHeap()	Unknown
 	ntdll.dll!RtlpAllocateUserBlock()	Unknown
 	ntdll.dll!RtlpLowFragHeapAllocFromContext()	Unknown
 	ntdll.dll!RtlpAllocateHeapInternal()	Unknown
 	msvcrt.dll!malloc()	Unknown
 	oricutron-sdl2.exe!SDL_malloc_REAL(unsigned __int64 size) Line 5328	C++
 	[External Code]	
	oricutron-sdl2.exe!SDL_RunAudio(void * devicep) Line 697	C++
 	[External Code]	
 	oricutron-sdl2.exe!RunThreadViaBeginThreadEx(void * data) Line 105	C++
 	[External Code]	

The last place where I have source code is there:

Code: Select all

void *SDL_malloc(size_t size)
{
0000000000485170  push        r12  
0000000000485172  sub         rsp,20h  
    void *mem;

    if (!size) {
        size = 1;
    }

    mem = s_mem.malloc_func(size);
0000000000485176  mov         eax,1  
000000000048517B  test        rcx,rcx  
000000000048517E  cmove       rcx,rax  
0000000000485182  call        qword ptr [5407A0h]           <------ call to the actual ntdll allocation code
0000000000485188  mov         r12,rax  
    if (mem) {
000000000048518B  test        rax,rax  
000000000048518E  je          00000000004851A1  
        SDL_AtomicIncRef(&s_mem.num_allocations);
0000000000485190  mov         edx,1  
0000000000485195  lea         rcx,[5407C0h]  
000000000048519C  call        00000000004CE6D0  
    }
    return mem;
}
00000000004851A1  mov         rax,r12  
00000000004851A4  add         rsp,20h  
00000000004851A8  pop         r12  
00000000004851AA  ret  

From what I see, the code crashes pretty much before we even enter "main", but I don't have much debugging information on the Main Thread:

Code: Select all

 	[External Code]	
	oricutron-sdl2.exe!WinMainCRTStartup() Line 197	C++
 	[External Code]	

I was wondering, recently Ibisum setup automated builds for... was it for the 8bit unity? or something, anyway, would it make sense to have the same thing setup on Oricutron, so each commit immediately triggers the generation of all the common versions (windows, linux, mac, in 32 and x64 version, with and without symbols, ...) so any broken code can immediately be detected, and any new feature immediately tested?

[Chema]

Ahem... maybe you can also have a look at IJK emulation? You know it does not behave like a real Oric..

[iss]

Oricutron for developers updated: 2021-02-13 - with BD500 improved support.

[ibisum]

Nice work - one nag though: Would it be possible for us to have oricutron on the one repo and just use developer- forks? Kind of difficult to keep track of the versions that are out there..

[iss]

Oricutron for developers updated again today: 2021-02-13.

Changes:
- last corrections for BD500 (see BD500 posts for more info);
- possible to disable the change of the menu's background color (as commented with @Chema earlier) - set in 'oricutron.cfg':

Code: Select all

; Disable menu color scheme
disable_menuscheme = yes

... and you will have the nice 'blue' background.

For easy tracking I set the tag: V1_2_3 in Oricutron for current release and this is noted in the window title as 1.2.3-20210213:

Would it be possible for us to have oricutron on the one repo and just use developer- forks?

For my builds I'm using always the sources from the main repo without any changes!
Customized are only some minor settings in the cfg file by my taste - for instance: to use by default 'opengl' instead of 'soft' rendering, to make menu 'blue' ...
Of course in my ZIP files are all ROMs which can be an issue if stored on github

EDIT: @Dbug: It makes no sense, but related to customization in oricutron.cfg can you try to set the render to 'soft' instead of 'opengl' to see if the crashes continue?

[Dbug]

EDIT: @Dbug: It makes no sense, but related to customization in oricutron.cfg can you try to set the render to 'soft' instead of 'opengl' to see if the crashes continue?

Changing render option did not do anything, but the crash happens in 'SDLAudioP1' so could it be audio related?
I do have multiple sound cards, multiple video capture cards, etc...

The SDL1 versions runs fine, as usual.

The only way to fix that really is to make an executable with symbols, then with the source code I can see where it crash.

[iss]

Changing render option did not do anything, but the crash happens in 'SDLAudioP1' so could it be audio related?

Indeed, it's very plausible that the problem is related to audio. I'll try to trace the initialization process and see what can be wrong.
Now for SDL2 I'm using ver. 2.0.8 but there is more recent version available - this sounds like a plan.

[iss]

New version available 1.2.4-20210214.
Changes in sources are related to BD500 support.
The compiled binaries use newest stable SDL2-2.0.14.

[ThomH]

I don't know whether you're building things automatically or manually, but I notice that the macOS build doesn't yet have native M1 (i.e. ARM) support. I have an M1 Mac, is there any assistance I can provide? SDL is now available for the M1, indeed I've already got the framework version installed and have built things against it.

I acknowledge that it's far from urgent. I've yet to find anything that runs well on an x86 that does not run well under Rosetta.

[iss]

I don't know whether you're building things automatically or manually, but I notice that the macOS build doesn't yet have native M1 (i.e. ARM) support. I have an M1 Mac, is there any assistance I can provide? SDL is now available for the M1, indeed I've already got the framework version installed and have built things against it.
I acknowledge that it's far from urgent. I've yet to find anything that runs well on an x86 that does not run well under Rosetta.

@ThomH: For all my builds I'm using cross toolchains under Linux. For macOS it's probably already obsolete but currently no free-time to setup something more recent but definitely I should make it and add M1 support. I test every new build on real hardware - it's an oldie too - Mac Mini (late 2012)

and although an i7 CPU with 16GB is still not so bad for me there will be no official Big Sur support (luckily with some hacks it's possible).

Actually I need some help - I noticed in recent releases that Oricutron SDL-1x doesn't start when clicking on Oricutron.app icon but if I "Show Package Content" and click on the executable - it runs fine. With Oricucutron SDL-2x is exactly the opposite - it runs OK from Oricutron.app icon but not from the executable. Both packages contain exactly the same files, different are only the executables

[ThomH]

Actually I need some help - I noticed in recent releases that Oricutron SDL-1x doesn't start when clicking on Oricutron.app icon but if I "Show Package Content" and click on the executable - it runs fine. With Oricucutron SDL-2x is exactly the opposite - it runs OK from Oricutron.app icon but not from the executable. Both packages contain exactly the same files, different are only the executables

Confirmed same behaviour under macOS 11; checking out the console suggests that the application is launching all four ways, followed by an ordinary safe exit. I'll try to learn some more.