-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vmp3700 Raf Electronics Videokê #7839
base: master
Are you sure you want to change the base?
Conversation
* Sketched an initial Vmp3700 driver * Determined the mapping of the chip-select signals * Declared the ROMs (including 2 undumped maskroms which are soldered to the PCB) * Started working on an Intel 386EX processor driver. * Hooked up the internal I/O maps for the embedded i386EX interrupt controllers (master and slave PIC8259). * Mapped the bank-switching high-address bits for the maskroms (a few Port 3 bits)
* Parallel Port I/O handlers (boilerplate code) * helper method to print bit patterns in log messages * PINCFG (Pin Configuration) * implementing a few more boilerplate code of configuration registers * parse chip-select-unit register values + mem map tweaks + frontpanel mcu + misc changes * set clock prescaler
…ME codebase as lots of things changed since 2017
Could you move the device to i386ex.cpp and i386ex.h or is there a conflict with macros? |
Is the FETCH() replacement really necessary? |
This definitely needs cleanup, and the 386ex should be moved out to a separate file. Pulling in all the peripheral chip headers for everything using the 386 is undesirable. |
OK, I can do the refactoring you suggested, for sure. But can someone tell me why this does not build properly (regardless of code-style cleanup considerations)? I recall I gave up late last year after trying for a few days to update the code to the newest code-base. |
It compiled and linked fine here, what error are you getting? |
Interesting! Maybe it was a runtime error then. I will get back to it later (probably on the weekend) so that I can better describe what's wrong. Last time I touched this code was circa September 2020 if I recall correctly |
33cf6e3
to
3564ba8
Compare
3564ba8
to
23d19d3
Compare
what's the purpose of the |
I think the problem is, the memory accessors need overrides for 16-bit bus. Or you could just derive the class from i386sx_device instead. |
I will try the overrides later and I'll let you know if it worked well. Thanks a lot! |
yes, it worked! Thanks, @villedevs |
b726c0e
to
5f42b85
Compare
Please consider merging this preliminary work, as-is, since I do not plan to continue working on it on the short-term. I may revisit it on the future for further improvements, though. |
I'll be happy to make minor tweaks in order to get this merged, of course! Please, let me know. |
@@ -0,0 +1,316 @@ | |||
#include "i386ex.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is missing the standard header comment, and the PCH.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is PCH?
{ | ||
zero_state(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it necessary to avoid calling i386_device::device_reset
? It’s usually better to call the base device_reset
and patch up things that need to be different.
All .cpp files should start with
#include "emu.h"
When building with gcc/clang emu.h is precompiled and injected into
every .cpp, so it will compile regardless without it (unless you disable
precompiled headers with a command line parameter) but it will fail to
compile with visual studio.
…On 25/05/2021 18:37, Felipe Corrêa da Silva Sanches wrote:
***@***.**** commented on this pull request.
------------------------------------------------------------------------
In src/devices/cpu/i386/i386ex.cpp
<#7839 (comment)>:
> @@ -0,0 +1,316 @@
+#include "i386ex.h"
what is PCH?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#7839 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACGVYYQFVM65TDMRWJRQ5GLTPPN5XANCNFSM4YTHO2PQ>.
|
Oh, I see! I was not aware of that. Thanks for the clarification ;-) |
Back in 2017 I started drafting a driver for the Raf Electronics VMP3700 videoke. I've then shelved this pet-project for many years and by September 2020 I gave it a second chance by rebasing the old commits against git master and then attempting to update the code-style to re-sync with MAME's current codebase.
Yesterday a friend asked me about this project and I decided to make it public "as is" so that it is not lost forever in a branch of my local copy on my laptop.
Unfortunately, there is one portion of that code that I was not able to update properly, which involves the implementation of the 386EX device, which is basically a 386 CPU with some other typical PC chipset all included in a single chip (this is a simplistic description, but gives you a general idea of what this is about). I'd like to ask for some help here to at least fix build. I know that there may be many code-style tweaks that may be needed to make this PR acceptable for merge, and I will address them, but this is not yet a PR intended for merging. I want to just fix the build so that I can get back to studying the device. The ability to run its boot code and inspect it on MAME's debugger is very important in helping me to figure out other aspects of the emulation that still need to be implemented or fixed.
I plan to get back to it on my free time during this weekend. Any feedback on this preliminary set of commits will be much appreciated.
cheers!