What's new
By:
Filters

JVS 2 jamma / over-engineered arcade thingy

Scaling to 25k is probably a no - as I don't have a medium res monitor, and not sure how to do the scaling cleanly + it is a line based scaler, not frame based.

As for cost, I haven't started optimizing the BOM yet, but likely a few hundred USD. It may turn out to be too much money(risk) to have it assembled at a factory, and with over 100 components pr board, a hand-assembled run will for sure be limited in numbers :)

Anyho - this is a passion project, and focus is to get the thing working first :)
 
Am I right when I think this is a JVS I/O combined with an OSSC like device? Just making sure I'm getting excited by the right thing here.
 
defor said:
I actually meant scaling FROM 25k to 31k
:)
Click to expand...
Yeah.. that would be the holy grail for me so I can finally buy a way too expensive gradius IV and play it in my Naomi cab :) . I would like to stick an SRAM chip or two to the board to have a little more room to play with video, but not enough pins left on the FPGA. I haven't done the proper calculations yet, but it MAY be possible to do 25-31k scaling:

31k= 524 lines total, 60hz = horz scan frequency of 31444 hz
25k=416 lines total, 60hz = horz scan frequency of 24960 hz.

If we we sample 4 lines at 25k, and output 5 during the same time period - it should result in something like:
520 lines total, 60 hz = horiz scan frequency of 31200 hz which should be in range. This will be require the FPGA to do fancy clock and buffer stuff, but in theory I think it should be doable.

It is very much like an OSSC device, being a line based scaler.

It's primary task is not to be a JVS I/O (master), but a JVS game (slave) - and enable playing jamma PCB's in a JVS cab. Being raspberry PI and with an extra USB port, it opens for some fun stuff - like using USB controllers to play games.
 
Speaking of, is medium res, 24k or 25k? I see it referred to as both...
 
Soon done with the schematics and moving on to routing. Happy to report that the kick connector and pin-out will be exactly the same as the RGB's excellent HAS supergun.

If space permits, should I add some buttons on the PCB for game input, like coin/start/test/..? Not sure which buttons or how many. As a bench setup, you can always plug in a USB controller/joypad - but could be useful in some troubleshooting scenarios.
 
invzim said:
If space permits, should I add some buttons on the PCB for game input, like coin/start/test/..? Not sure which buttons or how many. As a bench setup, you can always plug in a USB controller/joypad - but could be useful in some troubleshooting scenarios.
Click to expand...
service/test from the JAMMA standard ... reset button ^^
 
Any opinions on power input? Any point in adding something other than the JST-VL connectors? For bench use, I'm toying with the idea of either 20/24pin ATX or plain HDD connector(s).
 
invzim said:
Any opinions on power input? Any point in adding something other than the JST-VL connectors? For bench use, I'm toying with the idea of either 20/24pin ATX or plain HDD connector(s).
Click to expand...
I would say JVS style JST-VL 6/8 pin connectors, as in most use cases it will be installed in a JVS ready cab anyway ;)
 
Shut-up-and-take-my-money.jpg
 
I've said this before in #arcadeotaku last year when I was bugging you about it, but I would really really love a simple no-frills analogue->analogue scan doubler for VGA monitors, so basically this minus all the JVS/JAMMA specific features. If you say it's never going to happen, I'll see how much can be done with the OSSC coupled with a HDMI to VGA dongle, but all the HDTV-specific features (plus the fact that it has a display and everything) make it way too complicated for my use.
 
Muf said:
I've said this before in #arcadeotaku last year when I was bugging you about it, but I would really really love a simple no-frills analogue->analogue scan doubler for VGA monitors, so basically this minus all the JVS/JAMMA specific features. If you say it's never going to happen, I'll see how much can be done with the OSSC coupled with a HDMI to VGA dongle, but all the HDTV-specific features (plus the fact that it has a display and everything) make it way too complicated for my use.
Click to expand...
It's the line doubler that makes this a little complicated + a lot of (attention to) details. You have sync issues to begin with, and probably the most challenging part is sampling the line correctly - two games can have identical horizontal frequency, but very different resolution - meaning the clock the line doubler operates is different. This is what I'm aiming for at least, matching the pixelclock of the game with the converter so you get 'pixel perfect' upscaling. This is new stuff for me, so will be interesting to see what can be accomplished once I have a working proto.

I'm actually leaning towards adding either HDD, or even 24pin ATX power. For 2(3) reasons:
  • Bench setup
  • Separate ATX PSU in cab for jamma, so you can switch games without powering off the cab
    • easy with ON/OFF using a jumper on the PCB that leaves it always on, but can be broken out to a switch - using the ATX on/off functionality
  • because I think it would be neat
This is of course feature creep etc etc, but I've been toying with this idea for years, so I don't care :)

Would look something like this:2016-07-12-capture.png

Or maybe not.. - I've ordered small test PCB to test jamma controls, audio, raspberry controls etc - should have it by the weekend with a bit of luck, and will continue on the hard-parts once the basics are confirmed.
 
Last edited:
invzim said:
You have sync issues to begin with, and probably the most challenging part is sampling the line correctly - two games can have identical horizontal frequency, but very different resolution - meaning the clock the line doubler operates is different. This is what I'm aiming for at least, matching the pixelclock of the game with the converter so you get 'pixel perfect' upscaling. This is new stuff for me, so will be interesting to see what can be accomplished once I have a working proto.
Click to expand...
That is a problem for something like OSSC which is A->D, when you need pixel perfect pixels. But since you're outputting VGA, it's A->D->A, in which case I actually think you will be fine with just oversampling the horizontal clock by as much as your hardware will allow, so that your analogue waveform coming out of the doubler is (practically) identical to the waveform coming in, just output twice. I say this because I have a composite to RGB converter from Ambery which uses a digital stage, and which (according to the datasheet for the video IC) samples 720 horizontal pixels, and using my Datapath capture card I have been able to reconstruct a pixel-perfect (as far as composite video allows) 256x240 capture image from an NES by adjusting the clock/phase on the capture card. This would be in line with Nyquist's sampling theorem.

NQoF61f.png
 
Muf said:
That is a problem for something like OSSC which is A->D, when you need pixel perfect pixels. But since you're outputting VGA, it's A->D->A, in which case I actually think you will be fine with just oversampling the horizontal clock by as much as your hardware will allow, so that your analogue waveform coming out of the doubler is (practically) identical to the waveform coming in, just output twice. I say this because I have a composite to RGB converter from Ambery which uses a digital stage, and which (according to the datasheet for the video IC) samples 720 horizontal pixels, and using my Datapath capture card I have been able to reconstruct a pixel-perfect (as far as composite video allows) 256x240 capture image from an NES by adjusting the clock/phase on the capture card. This would be in line with Nyquist's sampling theorem.
Click to expand...
Lets see how the tests turns out, if all else fails - oversampling for sure is the way to go. I'm only worried things will look a little blurry if you just miss things. The AD I'm using have a lot of knobs on it with phase shifting/adjusting, and I do intend for the raspberry to be able to do 'offline' analysis so I can code that stuff in plain C instead of getting fancy with the FPGA. It is an interesting problem though, and I have read up on detecting aliasing for a sampled signal with unknown properties, and from what I can gather it's theoretically impossible - but I plan to take advantage of the fact that there are SOME known properties of the video - there is e.g. a finite number of horizontal resolutions that can be expected.

A personal goal is to be able to adjust (shorten) the blanking periods without touching the pixels using a method of adjusting the output total pixels, while adjusting the output clock so that the horizontal frequency is identical. So say you have a htotal of 512 pixels with line frequency 15.72mhz, adjust that to 496 pixels while keeping the frequency at 15.72mhz, but keeping all the display pixels intact. This could also be used to make 'nice' horizontal resolutions that are compatible with LCD screens.

All this is a little preliminary though, as I don't have the hardware to do the development on yet :)
 
It's always good times when you get a PCB in the mail. Reason that the jamma connector is not all hooked up is pcbway had a promotion, 10usd for 10x10cm PCB - so I made a quick & dirty 2 layer board to test some basics.

This board is to test a couple of different chips to sink the jamma signals (button presses) and the analog input stages for audio and video. I also hooked up the raspberry to the RS485 system, so I can speak with the IO board.

I admit I had to think a couple of times if the setup in the picture would work, but it's actually a nice test setup. A free bonus from using the PI, is that I can SSH into the thing from the office :)

Quiz: what the hell am I doing in the picture with JVS cable looped like that? :)
 

Attachments

  • 2016-07-21 basics POC bringup.JPG
    2016-07-21 basics POC bringup.JPG
    284.6 KB · Views: 295
invzim said:
Lets see how the tests turns out, if all else fails - oversampling for sure is the way to go. I'm only worried things will look a little blurry if you just miss things. The AD I'm using have a lot of knobs on it with phase shifting/adjusting, and I do intend for the raspberry to be able to do 'offline' analysis so I can code that stuff in plain C instead of getting fancy with the FPGA. It is an interesting problem though, and I have read up on detecting aliasing for a sampled signal with unknown properties, and from what I can gather it's theoretically impossible - but I plan to take advantage of the fact that there are SOME known properties of the video - there is e.g. a finite number of horizontal resolutions that can be expected.
Click to expand...
If you can grab video frames into Pi memory then you've hit the jackpot - A raspi3 is really powerful and that opens up some interesting analysis options - if you've ever hit the "auto" button on an LCD monitor with VGA input, what it does is simply cycle through all the possible clock/phase parameters (within reason), and then run a fourier analysis on that to see which one outputs the highest frequency peaks. If the signal is clean enough and there are some extremes on screen (like in test mode) you should be able to derive the AD parameters almost perfectly. JAMMA boards have test screens and things like the geometry test screen are great to figure out active picture timing, RGB bars are good for gain, convergence test is great for horizontal clock/phase, etc.
 
  • Like
Reactions: rtw
As the wife is not entirely sure what I'm up to, I'm sharing with you guys instead - Initial bringup is successful - I/O board is responding and communications stable :)


Code: 
Initialization of raspberryPi specific JVS functions....done
JVS daemon test
Initialization of JVS bus.
JVS bus reset #1
JVS bus reset #2
sense line is high
Setting node address for board 1..successful
IO-board 1:
SEGA ENTERPRISES,LTD.;I/O 838-13683B ;Ver1.07;99/06
sense is low, no more IO-boards on bus
Initializing JVS bus complete, 1 IO-board(s)
----- IO BOARD DETAILS -----
SEGA ENTERPRISES,LTD.;I/O 838-13683B ;Ver1.07;99/06
JVS version 2.0
JVS command format revison 1.1
JVS communucation system version 1.0
Number of players 2
Number of inputs per player 15 - 9 buttons
Number of coinslots 2
Number of analog input channels 8
                bits pr channel 0
----- JVS STATE -----
JVS requests  6
JVS acks      6
JVS errors    0

300done - i=299 count=300  reqs 306  acks 306 errors 0
300done - i=599 count=300  reqs 606  acks 606 errors 0
300done - i=899 count=300  reqs 906  acks 906 errors 0
300done - i=1199 count=300  reqs 1206  acks 1206 errors 0
300done - i=1499 count=300  reqs 1506  acks 1506 errors 0
300done - i=1799 count=300  reqs 1806  acks 1806 errors 0
300done - i=2099 count=300  reqs 2106  acks 2106 errors 0
300done - i=2399 count=300  reqs 2406  acks 2406 errors 0
300done - i=2699 count=300  reqs 2706  acks 2706 errors 0
300done - i=2999 count=300  reqs 3006  acks 3006 errors 0
300done - i=3299 count=300  reqs 3306  acks 3306 errors 0
300done - i=3599 count=300  reqs 3606  acks 3606 errors 0
300done - i=3899 count=300  reqs 3906  acks 3906 errors 0
300done - i=4199 count=300  reqs 4206  acks 4206 errors 0
300done - i=4499 count=300  reqs 4506  acks 4506 errors 0
300done - i=4799 count=300  reqs 4806  acks 4806 errors 0
300done - i=5099 count=300  reqs 5106  acks 5106 errors 0
300done - i=5399 count=300  reqs 5406  acks 5406 errors 0
300done - i=5699 count=300  reqs 5706  acks 5706 errors 0
300done - i=5999 count=300  reqs 6006  acks 6006 errors 0
I can also toggle a couple of LED's that is on the same i2c bus as the jamma controls, and voltmeter reads -5V :)
 
You must log in or register to reply here.
Back
Top