Oricutron 1.0 (EDIT: Now 1.2)
Re: Oricutron 1.0 (EDIT: Now 1.2)
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.
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.
Re: Oricutron 1.0 (EDIT: Now 1.2)
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:
The last place where I have source code is there:
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:
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?
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]
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
Code: Select all
[External Code]
oricutron-sdl2.exe!WinMainCRTStartup() Line 197 C++
[External Code]
Re: Oricutron 1.0 (EDIT: Now 1.2)
Ahem... maybe you can also have a look at IJK emulation? You know it does not behave like a real Oric..
Re: Oricutron 1.0 (EDIT: Now 1.2)
Oricutron for developers updated: 2021-02-13 - with BD500 improved support.
- ibisum
- Wing Commander
- Posts: 1652
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Re: Oricutron 1.0 (EDIT: Now 1.2)
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..
Re: Oricutron 1.0 (EDIT: Now 1.2)
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':
... 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:
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?
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
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:
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?
Re: Oricutron 1.0 (EDIT: Now 1.2)
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.
Re: Oricutron 1.0 (EDIT: Now 1.2)
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.
Re: Oricutron 1.0 (EDIT: Now 1.2)
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.
Changes in sources are related to BD500 support.
The compiled binaries use newest stable SDL2-2.0.14.
Re: Oricutron 1.0 (EDIT: Now 1.2)
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.
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.
Re: Oricutron 1.0 (EDIT: Now 1.2)
@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).ThomH wrote: ↑Thu Feb 18, 2021 11:11 pm 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.
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
Re: Oricutron 1.0 (EDIT: Now 1.2)
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.iss wrote: ↑Fri Feb 19, 2021 1:08 amActually 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
Re: Oricutron 1.0 (EDIT: Now 1.2)
I'm trying to update the OSDK to use the latest Oricutron, and I have a few questions:
- The readme has a line which disappeared, is it on purpose: "wm <addr> <len> <file>- Write mem to disk"
- Quid of oricutron.exe / oricutron-sdl2.exe, do I need both, or can I just bring one (like the sdl2 version, but renamed oricutron.exe)?
- Is SDL.dll gone now?
- The readme has a line which disappeared, is it on purpose: "wm <addr> <len> <file>- Write mem to disk"
- Quid of oricutron.exe / oricutron-sdl2.exe, do I need both, or can I just bring one (like the sdl2 version, but renamed oricutron.exe)?
- Is SDL.dll gone now?
Re: Oricutron 1.0 (EDIT: Now 1.2)
I've changed this monitor command to be more consistent with other commands of that type. Actual are:
Code: Select all
fd <addr> <end> <file>- Disassemble to file
fw <addr> <len> <file>- Write mem to BIN file
fr <addr> <file> - Read BIN file to mem
Both are independent standalone executables, so indeed, you can rename the sdl2 version and use it as oricutron.exe- Quid of oricutron.exe / oricutron-sdl2.exe, do I need both, or can I just bring one (like the sdl2 version, but renamed oricutron.exe)?
In my builds I'm linking the static SDL/SDL2 libraries. This is to avoid any questions about what DLL version should be used. Last build uses SDL-1.2.15 and SDL2-2.0.14. I just saw that there is more recent stable SDL2-2.0.16 and I'll try to use it on next release.- Is SDL.dll gone now?
Re: Oricutron 1.0 (EDIT: Now 1.2)
Hi,
I'm facing a difficulty with the oricutron 1.2.4 that comes with OSDK_1.19 : I can't find a way to type the symbol "_" (underscore) which is terribly frustrating when it comes to debug with symbols in monitor.
I use a french (azerty) keyboard which seems to be properly recognized by Oricutron because when I press a "A" it's a "A" that is typed (and not a "Q")
But when I press the key "8", i get the "8" typed instead of "_" as it used to do in the oricutron 1.2 of OSDK 1.16.
Did I miss something ?
I'm facing a difficulty with the oricutron 1.2.4 that comes with OSDK_1.19 : I can't find a way to type the symbol "_" (underscore) which is terribly frustrating when it comes to debug with symbols in monitor.
I use a french (azerty) keyboard which seems to be properly recognized by Oricutron because when I press a "A" it's a "A" that is typed (and not a "Q")
But when I press the key "8", i get the "8" typed instead of "_" as it used to do in the oricutron 1.2 of OSDK 1.16.
Did I miss something ?