FPGA based dumb frame buffer - Why has this not been created?

[olin]

anyone has a link for the Bgg or Bbb chip

BBG stands for BeagleboneGreen and it is a mini computer. You can buy one at seeedstudio.com and elsewhere in electronics shops.
I recommend using BBG, but if somebody already has BBB then try that one first.

So, is Arvid the right thing for me?

It's hard to say, depends on your expectations. For example ArvidMAME currently doesn't support accelerated 3d rendering, so new 3D games will work way slower than you might expect. If you are into emulation of that kind of machines you'll need more powerful computer. It's not impossible to fix that, but I didn't have time / motivation to implement it. If you happy to use 2D machines, especially those with non standard resolutions and/or refresh rates (for example irem games, cave games, toaplan games etc.), then it might be the right thing. But if I understand well GroovyMAME supports these things too, am I right? Arvid can be also useful if you plan to use notebook or mini pc for the emulation.

Can I create custom horizontal resolutions with it or does it restrict me to those listed in the specifications?

Yes you can, the firmware and rest of the software is open source with non restricting license. Mind you, if you'll be modifying the resolutions it's better to test on some multi-sync monitor (and oscilloscope as well) first, just in case a mistake in resolution parameters would damage your regular monitor. Realistically a maximum resolution you will get on BBG using ARVID is around 720x480i or 360x480p (will need a better monitor than 15kHz though for the latter). 

Does it work in Windows with any software (version of MAME)

Currently there is only ArvidMAME that supports the hardware (AFAIK), but anybody is free to add support for other emulators as well. As I wrote above, the source code is open an non limiting (MIT license). ArvidMAME is ported to Win32, Win64, Linux32, Linux64, OSX64, ARM Linux32. The Linux ports are also supported in headless mode so they don't need Xorg (graphical/windowing interface).

is it required to reprogram/patch the programs for it?

If you want particular software to output video signal on Arvid, then yes you/somebody has to reprogram it.

does Arvid output a DC coupled or AC coupled video signal

The video signal is generated by BBG which operates on DC. GPIOs of BBG produce 3.3V DC digital signals that are converted via resistor network into analog signal. The output voltage of white colour measured when the TV is disconnected is ~1V. The TV (when connected) reduces the incoming signal voltage by its internal voltage divider (usually resistor of 75 ohms).

I'm working on an adapter to make consoles work on my cabinet...

The following page describing video pin-out of various game consoles might be useful: http://members.optusnet.com.au/eviltim/gamescart/gamescart.htm


Sorry to moderators, I guess we are getting slightly off-topic in this thread, feel free to move it somewhere more appropriate.

[donluca]

The video signal is generated by BBG which operates on DC. GPIOs of BBG produce 3.3V DC digital signals that are converted via resistor network into analog signal. The output voltage of white colour measured when the TV is disconnected is ~1V. The TV (when connected) reduces the incoming signal voltage by its internal voltage divider (usually resistor of 75 ohms).

That's great as it will prevent lots of headaches for those wanting to connect it to an arcade monitor!

The following page describing video pin-out of various game consoles might be useful: http://members.optusnet.com.au/eviltim/gamescart/gamescart.htm

That has been my resource to go until now!

[maiki]

How many video modes can you store in the firmware? I am not interested in 3D stuff at all. Arvid seems the be the right device to deliver 1:1 low pclock lowres modes. I have never been a fan of multiplicated resolutions. I see that as a waste of resources. But it is important for me to have multiple video modes available. Also, switching resolutions on the fly (switchres?) would be welcome for systems like Sega Genesis (320 vs 256 modes).

[olin]

How many video modes can you store in the firmware?

Firmware is stored on micro SD card (plugged in to BBG), so you can have plenty. A single resolution is stored in separate file containing binary code for the MCU (PRU) which is currently ~1 kbyte. To have 720 resolutions (1 for each horizontal pixel) you need ~720kbytes free space on the SD card.

Switching resolutions on the fly (switchres?) would be welcome for systems like Sega Genesis (320 vs 256 modes).

Arvid currently does not support that gracefully. You can switch video modes on the fly, but there will be a brief period of time (few hundreds of ms) during which the video signal will not be produced - that means artefacts on the screen like pumping effect will occur. It's because when a new video mode is applied its MCU code has to be loaded and after the load the MCU is reset. But fluid resolution switching can be implemented. It should not be hard to do for the specific example you gave - 2 video modes 256 and 320. The specific MCU code would contain both video modes and switch them internally during V-sync period without producing artefacts.

[maiki]

Yes it would be great if resolution switching would be implemented. I don't think it requires critical time - I may be wrong. But when eg. Sega Genesis switches the modes it also takes a lot of time plus it is only done outside of gameplay - like switching between game menu / title screen etc. So IMO not critical at all. But those with expericence with switchres should know better.

[lugaidster]

Hey Olin, do you think something like double-strike could be implemented? This allows seamless switching between interlaced and progressive modes like what older consoles do in certain games.

With regards to the horizontal resolution scaling, I believe that some cases could be aliviated with wider modes. SNES games use either 256 or 512 and allows seamless switching between both modes midframe (via scanline triggered interrupts or H-IRQ and DMAs triggered by a scanline), which means that the signal has to be 512 pixel wide always and the SNES either outputs two pixels in 256 mode or one in 512 mode. I think that in the case of the Genesis, a mode with 1280 pixels horizontally (and FB stretching) could provide seamless switching between 256 and 320 while providing close to zero, if not zero, artifacts.

I'm very interested in testing this with something like Retroarch (or libretro cores for that matter, I have no idea, but I think a simple wrapper for libretro cores that outputs to arvid could be possibility for my C programming knowledge) as well as in my own Arcade cab. GroovyMame works just fine with the arcade games I play, but would love to not rely on such a finnicky system. I have a selfbuilt cab with a TV inside that has been modded to support RGB with a sync-combiner and signals directly to the OSD RGB pins on the Jungle Chip and also modded to turn on when the PC is on. I'm going to try and get a BBG from around here and build me an arvid or two for testing both systems.

With regards to 3d acceleration, I think some workarounds can be made by rendering to a texture and copying to ram. It might not be fast, but if the render is simple enough, latency might not be that big of a problem. A small texture of 640x480 or less shouldn't take that long to transfer. So many possibilities! Haha, sorry, I got carried away.

PS: Just found this in ebay: http://www.ebay.com/itm/Arvid-arcade-video-card-for-Arcade-monitor-/272619944682?hash=item3f796a3aea:g:vmsAAOSwuLZY5WEc, is it yours? If it is, do you ship internationally? (outside of Europe).

[olin]

Hi lugaidster,

related to double-strike: yes, I think that can be implemented. Interlaced and non-interlaced modes differ only by the vsync sequence. So the code of the video mode (runing on MCU) would periodically read a flag which Vsync sequence to use: either progressive or interlaced - and then output appropriate Vsync sequence at the Vsync time. Whether it would be seamless (no flickering on the screen) I don't know. I prefer having scan lines (as is common on arcades) that's why Arvid uses progressive mode, but a software switch (interlaced/progressive) can be added to the API as well. I tried interlaced on Arvid a long time ago (out of curiosity) and it worked fine.

Switching modes in midframe - that seems more complicated (not impossible though). I'd suggest in this case (256 and 512 switching) to use 512 mode all the time and let the emulator double the pixels on certain lines as it pleases (according to the emulated IRQ  etc.). Of course if you need to switch for example 256 and 320 in midframe then such solution will not work well (FB stretching in lowres) - does megadrive support switching modes in midframe?

libretro: not a bad idea, but I'm not familiar with the code, so it would probably take me few months to make it work with Arvid. Frankly, consoles are not my motivation as they output standard(ish) resolutions and standard video frequencies (50/60Hz) - one can use simple HDMI to CVBS video converter (sold on Amazon) or use RPi TV-out to play these console games on their CRT TV. But that doesn't mean it can not be done on Arvid - if you are passionate about consoles, feel free to port it

3d acceleration: exactly, that would be the solution.

ebay: yes that's mine. It's for people who are not comfortable wielding a soldering iron or just can not be bothered to source parts and tinker. Yes, Europe only.

[lugaidster]

Hi lugaidster,

related to double-strike: yes, I think that can be implemented. Interlaced and non-interlaced modes differ only by the vsync sequence. So the code of the video mode (runing on MCU) would periodically read a flag which Vsync sequence to use: either progressive or interlaced - and then output appropriate Vsync sequence at the Vsync time. Whether it would be seamless (no flickering on the screen) I don't know. I prefer having scan lines (as is common on arcades) that's why Arvid uses progressive mode, but a software switch (interlaced/progressive) can be added to the API as well. I tried interlaced on Arvid a long time ago (out of curiosity) and it worked fine.

Switching modes in midframe - that seems more complicated (not impossible though). I'd suggest in this case (256 and 512 switching) to use 512 mode all the time and let the emulator double the pixels on certain lines as it pleases (according to the emulated IRQ  etc.). Of course if you need to switch for example 256 and 320 in midframe then such solution will not work well (FB stretching in lowres) - does megadrive support switching modes in midframe?

libretro: not a bad idea, but I'm not familiar with the code, so it would probably take me few months to make it work with Arvid. Frankly, consoles are not my motivation as they output standard(ish) resolutions and standard video frequencies (50/60Hz) - one can use simple HDMI to CVBS video converter (sold on Amazon) or use RPi TV-out to play these console games on their CRT TV. But that doesn't mean it can not be done on Arvid - if you are passionate about consoles, feel free to port it

3d acceleration: exactly, that would be the solution.

ebay: yes that's mine. It's for people who are not comfortable wielding a soldering iron or just can not be bothered to source parts and tinker. Yes, Europe only.

Hey, awesome. Bummer about the Europe only, but I guess I can manage without. The circuit doesn't look that complicated to do on a universal pcb.

With regards to the consoles, the biggest issue with regular video cards is that doublestrike is simply not possible to implement. This mode doesn't switch between frame, but changing modes in a regular video card simply takes too long. An HDMI adapter simply will not cut it because the context needs to be recrated whenever a switch between interlaced and progressive needs to be displayed.

Doublestrike is a hack even in consoles because it is actually an interlaced mode where fields aren't alternated. This allows consoles to seamlessly switch between progressive lowres modes and interlaced high-res modes. Achieving this with an emulator would be like a holy Grail to people like me. Anyway, I'm rambling.

With regards to the horizontal mode thing, as I said, I think using a wide mode that's an integer multiple of the alternatives is all that is needed to be honest. This would allow midframe mode switching like in the SNES. I wouldn't​ worry about it.

I'll take a stab at modifying RetroArch to see if I can get it to output to arvid, but first I need to build me one. Would you sell me an unpopulated pcb? I think I can get an address in Spain that would forward it to my country. The one you sell on ebay would be too expensive for me due to taxes through this method. I think I can procure everything else on my end and build it.

One question, though, since I'm not that familiar with analog signals, what would I need to do in order to achieve something similar to what a video card would output? My current design expects 0.7vpp like what comes out of a VGA port.

Enviado desde mi SM-G930F mediante Tapatalk

[olin]

What would I need to do in order to achieve something similar to what a video card would output? My current design expects 0.7vpp like what comes out of a VGA port.

If you want to reduce the voltage going out of the DACs you have several options, but the simplest seems to be to change the voltage divider resistors on each Red, Green, Blue, Sync from 200, 220, 470 and 470 (RGBS) to 75,75,100, 270 (RGBS).  I would not be surprised if the screen would be too dark after the modification, but you can always go back to original values.

[donluca]

You can also use 4 trimmers so you can manually adjust each line until you have good results on screen!