Output vectors to a DAC device on the serial port. #483
Conversation
The v.st vector display board will draw the line segments from the emulated games on oscilloscopes, vectorscopes and slower XY monitors like the Vectrex. More info: https://trmm.net/MAME This also adds a SUBTARGET=vector to build just the vector games and CPUs, which shortens the build time from hours to a few minutes.
|
Thank you for your hard work. But please note few things. Change in vector.cpp is system dependent so will not compile on Windows, I have also commented other changes so please review them. Would like also to suggest usage of clang 3.6 that you can get from On Fri, Nov 27, 2015 at 11:57 PM, Trammell Hudson notifications@github.com
|
This comment has been minimized.
This comment has been minimized.
|
This is an unacceptably hacky way to achieve the intended result. Vector objects are already identified as such when passed up to the OSD layer. That's where this should be implemented. Hacking up vector.cpp is the wrong way to do it. |
|
@cuavas: Can you point me at the file/function where the vectors are received by OSD? It's not clear to me what happens to the lines after they are added to the container. |
|
This should be implemented as a renderer module that's a peer with the existing OpenGL, D3D, Soft etc. renderers. You'd then do -video=serialvector or something similar. Look at int sdl_info_ogl::draw(const int update) in drawogl.cpp to see how OSD parses the primitive list. (Similar functions exist in other renderers). |
|
Is there an guide to how to add a new renderer? The I don't want to abandon SDL for joystick and other support, plus it is helpful during debugging to have the mirrored display on the (raster) screen. Looking through |
|
@u-man74 these patches are for a more modern open-source hardware vector board that I've designed with a USB interface and that works with the current release. The ZVG used the parallel port and required booting to DOS to run MAME 0.96 (circa 2005). |
|
I don't see any open documentation, schematics, firmware or drivers available for your v.st device. It would be better to actually open your device before attempting to get other projects to provide support for it. You can distribute modified MAME source (provided you comply with copyright and trademark license restrictions) before you get the project into a state where MAME will accept a patch. Also your current patch falls into the same trap as the old VectorMAME of only supporting a minority platform: it doesn't compile, let alone work, on our most popular target Windows. |
|
If you follow the "More info" link on the v.st page to https://trmm.net/V.st you'll find all of the documentation, schematics, and firmware. There are no drivers necessary since it enumerates as a USB ACM device. It would still be nice if there were an easy way to hook into the vector logic that doesn't require such a detailed understanding of the MAME tree. Figuring out how to add a new target in |
|
@osresearch I believe USB ACM devices require an .inf on Windows 8.1 and earlier — see https://msdn.microsoft.com/en-us/library/windows/hardware/ff538820. This is annoying, as an .inf-only driver needs to be signed on Windows 8.1. I'm not sure if there's any reasonable workaround here (other than avoiding that version of Windows). However, that's a fairly minor issue in the grand scheme of things. Just worth pointing out. |
This patch adds output of the vector line segments to the serial port in a format that the v.st vector display board will parse. This allows display of the emulated games on real vector hardware like oscilloscopes, vectorscopes and slower XY monitors like the Vectrex. It adds runtime options to set the serial port, the scaling and the rotation of the display. More info: https://trmm.net/MAME
This patch also adds a
SUBTARGET=vectorto build just the vector games and CPUs, which shortens the build time from hours to a few minutes.