MAMEWorld >> Programming
View all threads Index   Threaded Mode Threaded  

Pages: 1

rubinstu
MAME Fan
Reged: 02/05/10
Posts: 20
Send PM


Exception thrown in m6502 for Asteroids
#394882 - 10/01/22 05:35 AM Attachment: screenshot_exception.png 376 KB (0 downloads)


Hello! I have built MAME 0.247 from source in Visual Studio 2022. Things seem to be working fine, except as soon as I launch Asteroids, I get an exception in the m6502 code. Has anyone else seen this? I have tweaked a little code in areas that I think have nothing to do with this just to make things compile, so there's a chance I broke it, but I would really like some confirmation.

Thanks!

Here is the code with the exception message and callstack:

[ATTACHED IMAGE - CLICK FOR FULL SIZE]

Attachment



MooglyGuy
Renegade MAME Dev
Reged: 09/01/05
Posts: 2261
Send PM


Re: Exception thrown in m6502 for Asteroids new [Re: rubinstu]
#394883 - 10/01/22 11:56 AM


> Hello! I have built MAME 0.247 from source in Visual Studio 2022. Things seem to be
> working fine, except as soon as I launch Asteroids, I get an exception in the m6502
> code. Has anyone else seen this? I have tweaked a little code in areas that I think
> have nothing to do with this just to make things compile, so there's a chance I broke
> it, but I would really like some confirmation.
>
> Thanks!
>
> Here is the code with the exception message and callstack:

Show us the tweaks anyway.



rubinstu
MAME Fan
Reged: 02/05/10
Posts: 20
Send PM


Re: Exception thrown in m6502 for Asteroids new [Re: MooglyGuy]
#394885 - 10/01/22 05:45 PM


Sure thing. Please keep in mind that these were very much "blunt force" changes just to make things compile in MSVC 2022.

Thanks!


Code:


diff --git a/src/devices/machine/ldv4200hle.cpp b/src/devices/machine/ldv4200hle.cpp
index db8f86a2a03..cebdd5739c2 100644
--- a/src/devices/machine/ldv4200hle.cpp
+++ b/src/devices/machine/ldv4200hle.cpp
@@ -801,7 +801,7 @@ TIMER_CALLBACK_MEMBER(pioneer_ldv4200hle_device::process_vbi_data)
int32_t old_delta = (int32_t)m_mark_frame - (int32_t)old_frame;
int32_t curr_delta = (int32_t)m_mark_frame - (int32_t)m_curr_frame;
LOGMASKED(LOG_STOPS, "%s: Stop Mark is currently %d, old frame is %d, current frame is %d, old delta %d, curr delta %d\n", machine().describe_context(), m_mark_frame, old_frame, m_curr_frame, old_delta, curr_delta);
- if (curr_delta == 0 || std::signbit(old_delta) != std::signbit(curr_delta))
+ if (curr_delta == 0 || std::signbit((double)old_delta) != std::signbit((double)curr_delta))
{
m_mark_frame = ~uint32_t(0);
if (is_cav_disc())
@@ -919,7 +919,7 @@ int32_t pioneer_ldv4200hle_device::player_update(const vbi_metadata &vbi, int fi
int32_t jump_frame = (int32_t)m_curr_frame + elapsed_tracks;
int32_t curr_delta = (int32_t)m_mark_frame - (int32_t)m_curr_frame;
int32_t next_delta = (int32_t)m_mark_frame - (int32_t)jump_frame;
- if (std::signbit(curr_delta) != std::signbit(next_delta))
+ if (std::signbit((double)curr_delta) != std::signbit((double)next_delta))
{
elapsed_tracks = curr_delta;
}
diff --git a/src/mame/nintendo/vsnes.cpp b/src/mame/nintendo/vsnes.cpp
index 7044c909e7c..90dc1fc3000 100644
--- a/src/mame/nintendo/vsnes.cpp
+++ b/src/mame/nintendo/vsnes.cpp
@@ -949,9 +949,12 @@ void vs_dual_state::vsdual_vrom_banking(u8 data)
// switch vrom
m_chr_banks[Side]->set_entry(BIT(data, 2));

+#if 0
+ // SFR Removed
// bit 1 ( data & 2 ) triggers irq on the other cpu
auto cpu = (Side == SUB) ? m_maincpu : m_subcpu;
cpu->set_input_line(0, (data & 2) ? CLEAR_LINE : ASSERT_LINE);
+#endif

// move along
vsnes_in0_w(data);
diff --git a/src/mame/sinclair/atm.cpp b/src/mame/sinclair/atm.cpp
index 3be353b43ee..c87b4ab8179 100644
--- a/src/mame/sinclair/atm.cpp
+++ b/src/mame/sinclair/atm.cpp
@@ -352,11 +352,14 @@ void atm_state::atm_update_screen_tx(screen_device &screen, bitmap_ind16 &bitmap
u8 fg = ((attr & 0x40) >> 3) | (attr & 0x07);
u8 bg = (((attr & 0x80) >> 1) | (attr & 0x38)) >> 3;

+#if 0
+// SFR Removed
u8 chunk = *(m_char_rom + (*symb_location << 3) + (y & 0x07));
for (u8 i = 0x80; i; i >>= 1)
{
bitmap.pix(vpos, hpos++) = (chunk & i) ? fg : bg;
}
+#endif
}
}
}
diff --git a/src/mame/sony/news_r4k.cpp b/src/mame/sony/news_r4k.cpp
index a83e7c3f468..caece8d1b6a 100644
--- a/src/mame/sony/news_r4k.cpp
+++ b/src/mame/sony/news_r4k.cpp
@@ -442,11 +442,14 @@ void news_r4k_state::machine_common(machine_config &config)
escc1_int_status = status ? 0x8 : 0x0; // guess
});

+#if 0
+ // SFR Removed
CXD8452AQ(config, m_sonic3, 0);
m_sonic3->set_addrmap(0, &news_r4k_state::sonic3_map);
m_sonic3->irq_out().set(FUNC(news_r4k_state::irq_w));
m_sonic3->set_bus(m_cpu, 0);
m_sonic3->set_apbus_address_translator(FUNC(news_r4k_state::apbus_virt_to_phys));
+#endif

// TODO: actual clock frequency - there is a 20MHz crystal nearby on the board, but traces need to be confirmed
DP83932C(config, m_sonic, 20'000'000);
@@ -476,10 +479,13 @@ void news_r4k_state::machine_common(machine_config &config)
[this] ()
{ return uint32_t(m_fdc->dma_r()); });

+#if 0
+ // SFR Removed
DMAC3(config, m_dmac, 0);
m_dmac->set_apbus_address_translator(FUNC(news_r4k_state::apbus_virt_to_phys));
m_dmac->set_bus(m_cpu, 0);
m_dmac->irq_out().set(FUNC(news_r4k_state::irq_w));
+#endif

NSCSI_BUS(config, m_scsibus0);
NSCSI_BUS(config, m_scsibus1);




MooglyGuy
Renegade MAME Dev
Reged: 09/01/05
Posts: 2261
Send PM


Re: Exception thrown in m6502 for Asteroids new [Re: rubinstu]
#394887 - 10/01/22 08:56 PM


I can at least confirm that the issues you mention are present in Visual Studio 2022 17.3, although for whatever reason they did not affect me in the 17.2 cycle. Have you considered downgrading?

The issue with the M6502 core is also not present when using the primary build tools, which once again, involve GCC. There's a bundle of everything you need here - https://www.mamedev.org/tools/ - and it takes all of about 5 minutes to get everything set up.

With how much trouble you're having, why are you so hell-bent on compiling MAME using Visual Studio? You've been making threads for over 2 months now about these issues that you specifically are having. Why are you insisting on working against the workflow that pretty much every other developer and contributor seems to have no problems with? In the 2 months you've been spinning your wheels with VS2022, you could have just installed the MinGW bundle from the aforementioned link, and been up and running.



rubinstu
MAME Fan
Reged: 02/05/10
Posts: 20
Send PM


Re: Exception thrown in m6502 for Asteroids new [Re: MooglyGuy]
#394889 - 10/02/22 04:17 AM



Quote:


Have you considered downgrading?



I will try that.


Quote:


why are you so hell-bent on compiling MAME using Visual Studio?



This is a fair question. There are several reasons for MSVS over the normal workflow.

The main reason is for the debugger. Visual Studio just has such a superior debug interface. GCC is great, but unless I'm missing something, using GDB with some other IDE (Code, Eclipse, or whatever) just isn't so great. I would love to be corrected here!

I have some long-term ideas for adding features, mostly for my own use, but would happy to put them into the Open Source eventually. Specifically, I want to add some remote interrogation and controls via MQTT so another program, even another computer, can control a game with AI or other automation. (I know there have been others doing things leveraging the Lua interface, and maybe HTTP...)

There will be a lot of new code, including patches to MAME (hooks into an MQTT client, etc.), and standalone "controller" MQTT application which will likely be coded in C#. Again, I can be corrected here, but it seems to me to be a whole lot easier to use Visual Studio than GCC in the Mingw environment.

I really like Visual Studio Code and I have used it for all sorts of embedded (cross-compiler), Windows, and Linux with many flavors of GCC. My one major complaint is the debugger. For example, there is no memory viewer. So, you need to manually command-line GDB commands like it's 1990, rather than a modern feature-rich debugger that you should have. Eclipse may have a better debugger interface but it definitely own obnoxious hang-ups.

What IDE / debugger front-end are people using? The official documentation seems to stop at just getting the existing code compiled (not that I would expect more).

Thanks



Vas Crabb
BOFH
Reged: 12/13/05
Posts: 4462
Loc: Melbourne, Australia
Send PM


Re: Exception thrown in m6502 for Asteroids new [Re: rubinstu]
#394902 - 10/04/22 01:28 AM


IDEs just don’t scale well to large projects. I use vim to edit source, and when I occasionally need to use a debugger, I use gdb. I don’t actually use a debugger very often, and most of the time it’s just to get a stack trace. I probably use valgrind more frequently than gdb.



rubinstu
MAME Fan
Reged: 02/05/10
Posts: 20
Send PM


Re: Exception thrown in m6502 for Asteroids new [Re: Vas Crabb]
#394904 - 10/04/22 02:18 AM



Quote:


IDEs just don’t scale well to large projects.
Maybe, but I actually have been having some good luck with Visual Studio Code on some huge projects like the full Linux sources.





Quote:


I probably use valgrind more frequently than gdb.



Interesting. I'll have to check out Valgrind again. I went though a tutorial years ago for some memory analysis, but would not have thought to use it in this context.

So, if I still am running into problems, I'll probably go back to GCC + GDB.

Thanks

Edited by rubinstu (10/04/22 05:36 AM)



jonwil
Lurker
Reged: 10/06/03
Posts: 536
Send PM


Re: Exception thrown in m6502 for Asteroids new [Re: rubinstu]
#395560 - 01/16/23 12:18 PM


There are plugins that let you use Visual Studio (or VS code) as a front end to GDB.


Pages: 1

MAMEWorld >> Programming
View all threads Index   Threaded Mode Threaded  

Extra information Permissions
Moderator:  Pi 
0 registered and 63 anonymous users are browsing this forum.
You cannot start new topics
You cannot reply to topics
HTML is enabled
UBBCode is enabled
Thread views: 340