Skip to content
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

Output vectors to a DAC device on the serial port. #483

Closed
wants to merge 5 commits into from

Conversation

osresearch
Copy link
Contributor

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=vector to build just the vector games and CPUs, which shortens the build time from hours to a few minutes.

Starwars on a vectorscope and a Vectrex

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.
@mmicko
Copy link
Member

mmicko commented Nov 28, 2015

Thank you for your hard work. But please note few things.

Change in vector.cpp is system dependent so will not compile on Windows,
there are osd calls used to open file, socket or ptty that you can use.

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
macports for better compatibility, also would need that probably for next
release already.

On Fri, Nov 27, 2015 at 11:57 PM, Trammell Hudson notifications@github.com
wrote:

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=vector to build just the vector games
and CPUs, which shortens the build time from hours to a few minutes.

[image: Starwars on a vectorscope and a Vectrex]

https://camo.githubusercontent.com/b0824c5a1ae4dd4aaaf9e4a8230b0ed521ce3286/68747470733a2f2f34392e6d656469612e74756d626c722e636f6d2f65346632353836646439346364333662656565323731666439306538613963632f74756d626c725f6e786773336771634d63317336773671376f315f3530302e676966

You can view, comment on, or merge this pull request online at:

#483
Commit Summary

File Changes

Patch Links:


Reply to this email directly or view it on GitHub
#483.

@u-man74

This comment has been minimized.

@cuavas
Copy link
Member

cuavas commented Nov 28, 2015

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 cuavas closed this Nov 28, 2015
@osresearch
Copy link
Contributor Author

@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.

@rb6502
Copy link
Contributor

rb6502 commented Nov 28, 2015

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).

@osresearch
Copy link
Contributor Author

Is there an guide to how to add a new renderer? The drawnone.cpp doesn't seem to be built on OSX and adding src/osd/modules/render/drawvector.cpp doesn't seem to update the list of available renderers. The -renderdriver option also silently ignores unknown values.

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 osdmini and some of the other parallel OSD interfaces it seems like this is quite a rabbithole of stuff that has to be reimplemented. Surely there is a better place to insert this sort of hook that doesn't require so much new code.

@osresearch
Copy link
Contributor Author

@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).

@cuavas
Copy link
Member

cuavas commented Nov 28, 2015

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.

@osresearch
Copy link
Contributor Author

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 src/osd/modules/render/ is really non-trivial and I've given up on it for now.

@balr0g
Copy link
Contributor

balr0g commented Nov 28, 2015

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants