C++ 86.68%C 12.39%Assembly 0.91%Shell 0.01%Batchfile 0.01%HLSL 0.01%Makefile 0.01%Smalltalk 0.01%
winuae's Introduction
WinUAE
Requirements: Windows 7 32-bit/64-bit or newer.
Visual Studio 2017 Community with the following feature:
"Desktop Development with C++" with follow option:
-"Support Windows XP for C++"
-"Windows 8.1 SDK UCRT SDK"
-"Windows 10 SDK 10.0.17763.0"
Download and Install the Windows Driver Kit (WDK). 16299 (1709) or newer.
Download the zip packages include and lib "winuaeinclibs.zip" and create the directory "c:\dev" and extract all. When finished you have "c:\dev\include" and "c:\dev\lib"
In Visual Studio click on "File"->"Open"->"Project/Solution" select the folder \od-win32\winuae_msvc15\winuae_msvc.sln (Ignore error message "Unsupported" and click ok)
In The solution 'winuae_msvc' you can unload or delete the following projects (and all others not needed in step 12):
-uaeunp
-consolewrapper
-decompess
-fdrawcmd
-ipctester
-resourcedll
-singlefilehelper
-wix
Change to 32-bit Release mode.
Build following projects in following order:
build68k
genlinetoscr
genblitter
gencpu
gencomp
prowizard
unpackers
Switch to Test (debug build) or FullRelease (full optimized) and select either 32-bit or 64-bit. Compile.
Finished. In "D:\Amiga" you find winuae.exe and winuae64.exe
I think the line
blit_firstline_cycles = blit_first_cycle + (blit_diag[0] * blt_info.hblitsize + cpu_cycles) * CYCLE_UNIT;
should be replaced by
blit_firstline_cycles = blit_first_cycle + (blit_diag[0] * blt_info.hblitsize) * CYCLE_UNIT + cpu_cycles;
because cpu_cycles are already scaled by CYCLE_UNIT.
it is: [C:1; Z:0] -7a = 1f; XnzvC
should be: [C:1; Z:0] -7a = 1f; XnzVC
it is: [C:1; Z:1] -7a = 1f; XnzvC
should be: [C:1; Z:1] -7a = 1f; XnzVC
it is: [C:0; Z:0] -7b = 1f; XnzvC
should be: [C:0; Z:0] -7b = 1f; XnzVC
it is: [C:0; Z:1] -7b = 1f; XnzvC
should be: [C:0; Z:1] -7b = 1f; XnzVC
it is: [C:1; Z:0] -7b = 1e; XnzvC
should be: [C:1; Z:0] -7b = 1e; XnzVC
it is: [C:1; Z:1] -7b = 1e; XnzvC
should be: [C:1; Z:1] -7b = 1e; XnzVC
it is: [C:0; Z:0] -7c = 1e; XnzvC
should be: [C:0; Z:0] -7c = 1e; XnzVC
it is: [C:0; Z:1] -7c = 1e; XnzvC
should be: [C:0; Z:1] -7c = 1e; XnzVC
it is: [C:1; Z:0] -7c = 1d; XnzvC
should be: [C:1; Z:0] -7c = 1d; XnzVC
it is: [C:1; Z:1] -7c = 1d; XnzvC
should be: [C:1; Z:1] -7c = 1d; XnzVC
it is: [C:0; Z:0] -7d = 1d; XnzvC
should be: [C:0; Z:0] -7d = 1d; XnzVC
it is: [C:0; Z:1] -7d = 1d; XnzvC
should be: [C:0; Z:1] -7d = 1d; XnzVC
it is: [C:1; Z:0] -7d = 1c; XnzvC
should be: [C:1; Z:0] -7d = 1c; XnzVC
it is: [C:1; Z:1] -7d = 1c; XnzvC
should be: [C:1; Z:1] -7d = 1c; XnzVC
it is: [C:0; Z:0] -7e = 1c; XnzvC
should be: [C:0; Z:0] -7e = 1c; XnzVC
it is: [C:0; Z:1] -7e = 1c; XnzvC
should be: [C:0; Z:1] -7e = 1c; XnzVC
it is: [C:1; Z:0] -7e = 1b; XnzvC
should be: [C:1; Z:0] -7e = 1b; XnzVC
it is: [C:1; Z:1] -7e = 1b; XnzvC
should be: [C:1; Z:1] -7e = 1b; XnzVC
it is: [C:0; Z:0] -7f = 1b; XnzvC
should be: [C:0; Z:0] -7f = 1b; XnzVC
it is: [C:0; Z:1] -7f = 1b; XnzvC
should be: [C:0; Z:1] -7f = 1b; XnzVC
it is: [C:1; Z:0] -7f = 1a; XnzvC
should be: [C:1; Z:0] -7f = 1a; XnzVC
it is: [C:1; Z:1] -7f = 1a; XnzvC
should be: [C:1; Z:1] -7f = 1a; XnzVC
v = cleared, V = set, C = input carry flag, Z = input zero flag
I.e. in those situations is the V flag incorrectly cleared. Please note that this applies only to the 68000, as mentioned in #127 the V flag must be ignored on 030+.
happens in latest PUAE when changing chipmem size to 2048 kb from first call to gui_display
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7d659cc in free (p=0x7ffff5e9d020) at src/malloc/malloc.c:486
486 if (IS_MMAPPED(self)) {
(gdb) bt
#0 0x00007ffff7d659cc in free (p=0x7ffff5e9d020) at src/malloc/malloc.c:486
#1 0x00000000005659b6 in mapped_free (
p=0x7ffff5e9d020 <Address 0x7ffff5e9d020 out of bounds>)
at src/memory.c:1573
#2 0x0000000000565dbb in allocate_memory () at src/memory.c:1871
#3 0x0000000000566c63 in memory_reset () at src/memory.c:2176
#4 0x00000000005611a0 in reset_all_systems () at src/main.c:916
#5 0x0000000000483c2f in custom_reset (hardreset=true, keyboardreset=false)
at src/custom.c:7798
#6 0x000000000057cb92 in m68k_go (may_quit=1) at src/newcpu.c:4218
1869 if (bogomem_bank.allocated != currprefs.bogomem_size) {
1870 if (!(bogomem_bank.allocated == 0x200000 && currprefs.bogomem_size == 0x180000)) {
1871 mapped_free (bogomem_bank.baseaddr);
1872 bogomem_bank.baseaddr = NULL;
1873 bogomem_bank.allocated = 0;
so bogomem gets an offset into the mem allocated for chipmem.
however other parts of the code malloc the memory for bogomem directly:
1881 if (bogomem_bank.allocated) {
1882 bogomem_bank.baseaddr = mapped_malloc (bogomem_bank.allocated, _T("bogo"));
1883 if (bogomem_bank.baseaddr == 0) {
so it seems that the code free'ing the bogomem cant be sure whether it deals with a chunk pointing into the middle of chipmem or a separate chunk. in the first case, calling free on the bogomem address is UB.
In part
if (!strcasecmp (p, _T("keyboard_type"))) {
cfgfile_strval (option, value, NULL, &pr->input_analog_joystick_offset, kbtypes, 0);
keyboard_default = keyboard_default_table[pr->input_keyboard_type];
inputdevice_default_kb_all (pr);
}
should "&pr->input_analog_joystick_offset" be replaced by "&pr->input_keyboard_type".
i'm running winuae 2.4.1 in virtual box inside a winxpsp2 vm, and as soon as i resize the vbox window, the winuae screen gets black and stays that way.
winuae is run in windowed mode with 800x600.
JanusUAE (just for morphOS) has seamless mode. It would be great if this was available on other platforms so amiga apps such as deluxe paint could be ran as normal apps.
Sorry, I might be wrong about this but the block array in function "archive_directory_tar" does not necessarily contain a null byte after reading contents from a file. Therefore the call of "strcat (name, (char*)block);" might call a segmentation fault. At least it did for me :) I have tried to resolve the problem using "memcpy(name, (char*)block, 512);" and it seems to work.
Hi.
I dont understand what i must do to get the CDRom LED working.
I tried to mount an ISO, also select Auto detect etc.
I tried to create a CD32 with an inserted CD but the LED doesn't work.
Also i try to boot an ccd Image. Winuae dont boot from ccd, only from the Image of the ccd file.
would you mind applying these 2 fixes to qemuuaeglue.h to fix compilation with older gcc's ? the forward declaration of 2 structs currently makes trouble with those. thanks!
Hi,
Are there any plans to merge WinUAE and fs-uae into single repository? Or at least unify emulation core? For example, make some "libuae", which can be reused by both projects? I've raised similar question on fs-uae repo: FrodeSolheim/fs-uae#180
LNK2019 unresolved external symbol "bool __fastcall check_prefs_changed_comp(bool)" (?check_prefs_changed_comp@@YI_N_N@Z) referenced in function "void __fastcall prefs_changed_cpu(void)" (?prefs_changed_cpu@@YIXXZ) winuae in newcpu.obj
I found a bug in Amiberry, which seems to exist in WinUAE as well.
Steps to recreate:
Change Quickstart to CD32
Insert a CD32 game and start the emulator
After the game is loaded and starts, enter the GUI and change the CD to another one (e.g. another game)
Click Reset from the GUI
Instead of rebooting and loading the other game, it reboots and shows the CD32 boot screen instead
If you enter the GUI again, and click Reset one more time, the new game is loaded.
This seems to happen regardless of game chosen.
All settings were left at their defaults, just using Quickstart CD32 as mentioned above, to keep things simple.
"z" or "t" command after landing at some breakpoint, doesn't work. It throws many exceptions in debugger console, looses current state, and program continues executes without a debugger, then finishes its execution.
It is strange, that on the same commands, stepping doesn't execute "uae_u32 REGPARAM2 CPUFUNC(op_007c_11)(uae_u32 opcode)" function. It looks like the execution context of other threads breaks with execution context of my program.
I've bought a speedlink Rocketeer Joystick recently and tried using it with WinUAE.
Unfortunately, no matter how i tried reconfiguring it, it only allowed me to move left and up - right and down movement was impossible.
At first I thought, that the joystick was damaged during the delivery, but then I tested it both with Windows USB Game Controllers Setup and also a few PC games native to Windows - it worked normally.
I took a peek at the code (inputdevice.cpp) and realized, that it assumes the following:
The joystick axis input (variable name: state) will either be a negative or a positive number. Negative numbers go left or up, positive numbers go down or right.
This assumption may not be true for all devices. As I tested the joystick in USB Game Controllers, it would show a value around 0 when the joystick was tilted left , 75 when it was centered and 150 when it was tilted fully right.
Proposed fix:
Adding an axis bias (or two, for X and Y separately) to input configuration added to the state variable would enable the user to calibrate such devices, greatly increasing the spectrum of supported joysticks.
Comment says:
/* Always put the right word before the left word. */
and code in put_sound_word_right() just stores the sample (if mixedon) and the code in put_sound_word_left() handles the samples.
But in all sample handlers (i.e. sample16s_handler()), put_sound_word_left() is called before put_sound_word_right().
I think, correct calls are
put_sound_word_right (data2);
put_sound_word_left (data3);
instead of
put_sound_word_left (data2);
put_sound_word_right (data3);
(switch of data2 and data3 required, otherwise channels are switched).
It's not possible to click OK on the crash/minidump screen when a crash has occured.
Win10 64bit
WinUAE 3.4.0 Beta 10 32bit (also happens in 3.3 release)
I think, the line
if (cop_state.ip >= currprefs.chipmem_size && cop_state.ip < currprefs.z3chipmem_start && cop_state.ip >= currprefs.z3chipmem_start + currprefs.z3chipmem_size)
break;
should be replaced by
if ((cop_state.ip >= currprefs.chipmem_size && cop_state.ip < currprefs.z3chipmem_start) || cop_state.ip >= currprefs.z3chipmem_start + currprefs.z3chipmem_size)
break;
Otherwise, the result is always false and the intended check (ip inside of chipmem) wasn't done.
in case of branches, or returns skipaddr_start will point at the next (in listing) instruction, but not at actual next address.
This case should be rewritten to skip branches, jumps, and returns and execute them as the regular step.
Subj.
After entering command like "fp "program.exe"", debugger window should be closed, but it isn't.
And every following commands cannot be entered without debugger closing.
Then, debugger cannot be stopped at program.exe entry.
I think the lines
if (value & 0xff00)
thisline_decision.xor_seen = true;
should be placed inside of
if (regno == 0x1000 + 0x10c) {
...
}
Otherwise the flag xor_seen is set for each register with bits set in 0xff00 and not only for BPLCON4.
Hi!
I would love to have a fast Workbench with the ability to switch the option JIT and cycle-exact chipset (DMA/Memopry-Accesses) AND/OR cycle-exact chipset (FULL) on and off with my Joypad while CPU Emulation speed stays at "fastest possible".
I do this manually all the time without any crashes and use it to have a fast Workbench with full WHD-LOAD compatibility. Having this option on a hotkey would be great!
I suggest creating a little README.md text file about compiling the source code: what libs are needed, how to prepare compiling environment etc., because currently provided .sln files for VS aren't working OOTB and it's not intuitive to set up everything correctly (like ./configure && make in Linux).
I'm fighting with this repo around 5h and I get some basic errors like syntax error : missing ';' before '*' in sysdeps.h. I installed DirectX SDK, WDK, VS2010, all dependencies I could find for WinUAE, set includes... and I still can't manage basic errors. I don't mind modifying the source code.
Compiling this should be easy, but is a pain in the... rear.
Just look at FS-UAE repo, everything is described with a set of instructions.
It would be great if you could add this upstream (unless you have a better solution of course) so we don't have to keep fixing it with future merges :)
I have a crash I can recreate always, along with some "strange" behavior regarding the JIT settings.
WinUAE version 3.5.0 x64, from the official installer package. Running on Windows 10 x64 with the latest updates.
I have a config to emulate a CStormPPC (though I only use the 060 part), boot in a default Workbench 3.1 installation with no extras. I use it to run Lightwave.
Here's a screenshot of my CPU and FPU settings:
Booting into Workbench works fine, but opening up the WinUAE window again shows that "Direct" mode has been changed to "Indirect". Changing it back to Direct, does not stick (it switches back).
However, disabling JIT completely and then re-enabling it, allows Direct to stay on.
That's one part of the strange behavior.
Part two, is that if right after disabling/enabling JIT and enabling Direct, you try to reboot the Amiga with the keyboard (Ctrl-A-A), then WinUAE crashes. Every time.
Let me know if you'd like more info to help troubleshoot this (e.g. config file, other system details, etc)
Basically, ultra-high-page-flip-rate raster-synchronized VSYNC OFF with no tearing artifacts, to achieve a lagless VSYNC ON. Achievable using standard Direct 3D calls.
Ideally rendering to front buffer is preferred, but modern graphics cards can now do thousands of buffer swaps per second of redundant frame buffers (to simulate front buffer rendering) -- so this is achievable within the sphere of standard graphics APIs utilizing VSYNC OFF and access to the graphics card's current raster.
You'd map the real raster (e.g. #540 of 1080p) to the emulated raster (e.g. #120 of 240p) for beam chasing of scaled resolutions.
Basically, works with raster-accurate emulators (line-accurate or cycle-accurate) to simulate a rolling-window frame slice buffer, for synchronizing emulator raster to real world raster (tight beam racing).
EDIT: After I posted this, I have learned at least one other have simultaneously invented a (formerly-before-unreleased) jitter-forgiving beam-chasing algorithm, I'm happy to share due credit. I'm open sourcing a raster demo soon, keep tuned. (see subsequent posts)
When compiling with Visual Studio, I'm getting an error C2308 here (line 2568):
{ // 16 - 18
_T("Memory\0""1M\0""2M\0""4M\0""8M\0""16M\0""32M\0"),
_T("memory\0""1M\0""2M\0""4M\0""8M\0""16M\0""32M\0"),
true, false, 0
},
Maybe it will be better to refactor these lines with getting every part of string in _T() macros like this?
_T("Memory\0") _T("1M\0") _T("2M\0") _T("4M\0") _T("8M\0") _T("16M\0") _T("32M\0"),
_T("memory\0") _T("1M\0") _T("2M\0") _T("4M\0") _T("8M\0") _T("16M\0") _T("32M\0"),
Shouldn't this line be int old = lores_shift; instead?
Like this, the pfield_set_linetoscr(); will never be hit since the values are always equal to each other...
I posted this FrodeSolheim/fs-uae#63 over at fs-uae but after looking around a bit I noticed that you @tonioni has been doing some changes in debug.cpp so I thought you might have some ideas on how I should go about implementing this.
if (((uintptr_t)&b[start]) & 1)
should be
if (((uintptr_t)&b[start]) & 3)
and
if (((uintptr_t)&b[stop]) & 1) {
should be
if (((uintptr_t)&b[stop]) & 3) {
Otherwise you write one pixel too much if start is even and stop is odd.
If you are at the end of the buffer, you write in not allocated mem.