Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: FPGA based dumb frame buffer - Why has this not been created?  (Read 13141 times)

0 Members and 1 Guest are viewing this topic.

emubastard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 57
  • Last login:October 18, 2018, 07:10:57 pm
  • I met your mom once, she looked like Ms. PacMan!
    • Emubastard
FPGA based dumb frame buffer - Why has this not been created?
« on: September 13, 2016, 01:30:19 pm »
With all the old consoles receiving open source scan converters, and RGB conversion boards.... I thought...

Instead of hacking the ---steaming pile of meadow muffin--- out of mame and ATI drivers.

Wouldn't it be easy for someone to create a dumb framebuffer USB 2.0/3.0 device to connect to an RGB device?  Would the latency be low enough?

Just bypass the whole windows display chain completely and have a real/fake FPGA framebuffer to do whatever you want with.  Then it works with any video cards since it's actually not using the primary display device at all.

God knows i wish I could do this, I'm just surprised with the amount of FPGA flash carts, AD Converters and other FPGA projects that no one has created something like this for mame.

Just a thought... Maybe if such a device existed, developing groovymame would be easier.

Windows & Linux via USB, seems like a lot of good could come from a device like this.  People seem to pay a lot for all the other neat FPGA devices out there that do various kinds of frame-buffer output.

Imagine, a plug and play mame frame-buffer RGB output device...

Just kinda seems like endleslly hacking windows 7, 10, what ever is next.... why not just make a framebuffer device.

-James
-Bastard

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #1 on: September 13, 2016, 04:52:22 pm »
Admittedly I have envisioned such device since long, although creating it is completely beyond my knowledge and skills.

The USB port would probably be a limitation. I had imagined something more like a pci-express board.

One possible design would simply mirror the gpu framebuffer ram and implement the logic to perform DAC based on user defined timings, totally bypassing the OS. The hardware implementation would implement a CRTC. Switching video modes would be as simple as sending the new CRTC values (modeline) to the device, taking effect instantly, without the insane overhead that mode switching involves on modern operating systems.

Another more ambitious design would involve the emulation of the whole CRTC itself, and just implement one DAC for each line (R, G, B, H, V). This would work without any video card on the system. The hardware implementation would be more simple, but the RGB-HV signal would need to be created by software on real time. I think the CPU requirements would make this approach impossible. This design would virtually allow to recreate any video signal that ever existed. An emulator supporting this wouldn't even require to do any v-sync.

The paradox is the hardware to do this is already invented inside any cheap video card available, it's just a software issue.
« Last Edit: September 13, 2016, 04:55:16 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

emubastard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 57
  • Last login:October 18, 2018, 07:10:57 pm
  • I met your mom once, she looked like Ms. PacMan!
    • Emubastard
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #2 on: September 13, 2016, 05:08:05 pm »
Well then.... is USB 3.0 latency too much of an issue?

I thought.... why not see if existing hardware can be hacked, USB is an open protocol, maybe one of these devices could be... re purposed to a dumb frame buffer and not a video card at all.

Such USB 3.0 hardware exists, and it's cheap... if only it could be repurposed.... maybe some of these use FPGA's.  I'm sure someone with the skills could crack one of these devices for exactly your needs.   No hardware creation needed.  Just some clever software engineer.

https://www.google.com/search?q=USB+3.0+to+vga&espvd=2&source=univ&tbm=shop&tbo=u&sa=X&ved=0ahUKEwiBtuD9no3PAhVHzmMKHTETB7sQsxgIHg&biw=1431&bih=864



-Bastard

emubastard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 57
  • Last login:October 18, 2018, 07:10:57 pm
  • I met your mom once, she looked like Ms. PacMan!
    • Emubastard
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #3 on: September 13, 2016, 05:13:44 pm »
And then there's another thought.  These USB 3.0 to VGA adapters must not use increadibly complex software, say compared to AMD drivers.

Maybe one of these devices drivers would be easier to hack for custom resolutions.  We all keep our high powered video accelerated main card and just plug one of these little guys in with some hacked driver software to do what your doing now in CrtEmu Drivers.

Assuming USB 3.0 latency doesn't limit anything I've suggested so far....

-Bastard

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #4 on: September 13, 2016, 06:23:30 pm »
Leaving USB speed apart, those USB cards are recognized just like normal video cards by the OS, so there's probably no much advantage over what we're doing now.
« Last Edit: September 13, 2016, 06:26:24 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

elvis

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1154
  • Last login:April 13, 2023, 05:31:03 pm
  • penguin poker
    • StickFreaks
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #5 on: September 18, 2016, 08:58:09 am »
I've often wondered why simple "line-halvers" don't exist.

There seems to be an abundance of cheap VGA to CGA converters on eBay (~$50 price range), but every single one of them produce an interlaced 480i output.  It's a shame nobody's made one that produces a 240p output instead.  These would be fantastic for indie games and emulators already upscaling lower resolution content anyway, and a simple physical switch could be used to decided whether even or odd lines are discarded.

AstroFan

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • Last login:February 29, 2024, 06:45:40 pm
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #6 on: September 20, 2016, 04:32:49 pm »
It's not FPGA based but ARVID does some of the things you want.
http://mujweb.cz/molej/arvid/

 

ufoufo512

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 49
  • Last login:September 22, 2016, 02:09:41 pm
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #7 on: September 22, 2016, 10:15:27 am »
Arvid seems awesome and clever project! Probably need to make one. I hope the project will go on (not that I quickly see anything missing in its current form), just hope it reaches people who think it is cool. I hadn't heard anything about it previously.

ufoufo512

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 49
  • Last login:September 22, 2016, 02:09:41 pm
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #8 on: September 22, 2016, 10:27:15 am »
There are also ready made pcb boards (without component available) at http://dirtypcbs.com/view.php?share=12822&accesskey=5a73f683ece0249a8034b7781067ea21 . If I understand correctly 10 pieces cost 25 dollars including shipping which is very cheap imo. Only problem is: what do I do with 10 boards :) On top of that you need Beaglebone mini computer and some basic components. Looks ideal hobby project.

emubastard

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 57
  • Last login:October 18, 2018, 07:10:57 pm
  • I met your mom once, she looked like Ms. PacMan!
    • Emubastard
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #9 on: September 22, 2016, 12:15:19 pm »
"100 MBit ethernet interface for communication with the host PC"

Sounds like LAG to me.

Whatever it is, it seems reasonable that it would have to connect to PCI-E to match the performance level of Calamities existing solution.

USB 2 and 3 look like they would add at least one frame of lag (if not more).

Someone feel free to correct me.  These are some assumptions based on a little googling of the specs.
-Bastard

ufoufo512

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 49
  • Last login:September 22, 2016, 02:09:41 pm
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #10 on: September 22, 2016, 01:41:33 pm »
I thought about lag too first. In the Youtube video author says he is using crossover cable and with that latency is around half of a millisecond, so it is non-existent. I have no first hand experience but I am tempted to try it out.

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:June 12, 2023, 09:19:49 am
  • Z80 ERROR
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #11 on: September 23, 2016, 03:59:56 am »
I can confirm that USB or Ethernet based solutions would not introduce more than 1ms of delay for the communication layer.

The picture construction and video synchronisation could add 1 buffer delay to the picture (20ms). Direct rendering is subject to clock synchronisation between the transmitter and renderer.

Nevertheless, ARVID is a very promising solution. I am wondering if an USB CPLD development stick could provide the necessary IO to drive a CRT. (i.e. http://www.icstation.com/epm1270t144-50mhz-cpld-development-board-core-board-module-jtagusbswitchkeyprotection-p-9122.html or http://www.icstation.com/50mhz-max3000-cpld-development-board-core-board-module-jtagusbledldo-p-9121.html)

pakoman

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 162
  • Last login:March 04, 2024, 08:54:30 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #12 on: September 23, 2016, 07:58:51 am »
Looks really promising as an universal solution. I assume it needs the emulator to be modified to be compatible with arvid.

AstroFan

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • Last login:February 29, 2024, 06:45:40 pm
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #13 on: September 23, 2016, 02:19:11 pm »
It's a shame nobody's made one that produces a 240p output instead.

There are a few devices that do that, for example MIMO's Genius box II. http://retrogaming.hazard-city.de/mimo.html

Besides Arvid, I remember reading about some FPGA/CPLD based framebuffer solutions that may be interesting or useful as a codebase:
ELM's General purpose display controller  http://elm-chan.org/works/crtc/report.html
And Project VGA's open source VGA video card http://wacco.mveas.com/

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #14 on: October 08, 2016, 02:43:34 pm »
Looks really promising as an universal solution. I assume it needs the emulator to be modified to be compatible with arvid.

I've just released arvidmame0163r3 for ARVID. Works well enough for me.


... Only problem is: what do I do with 10 boards :) On top of that you need Beaglebone mini computer and some basic components. Looks ideal hobby project.

I have 2 spare boards (soldered and working) sitting on my desk. If you live in Europe then PM me and I'll send you one. It applies for the second one as well - if anybody wants to try it let me know.
Edit: I also have extra 3 unpopulated boards I'm happy to give away. Somebody with an arcade monitor that is not afraid to experiment/try-it-out would be handy as well. 


Related to FPGA and USB.
That was the original idea behind ARVID. Unfortunately when I started (2 years ago) I could not find cheap dev board that has FPGA, SRAM and USB 2.0 interface on a single board.
My very first attempts used STFM Disco board (ARM-M4) I bought for 16£ and overclocked to 220 Mhz. The problem was it advertised USB 2.0, but only so called Full Speed (12MBit) not the High Speed (480MBit) which I didn't realised at that time. I even made USB driver for sending screens to it. It was working wery slow (1 FPS) but at least I learned how the video signal is constructed how to make 'hardware' scanlines  etc. Even today a FPGA board with all the required stuff is about 2x as pricey as Beaglebone Green. I'm not saying BBG is better than FPGA (on the contrary, there is a slight GPIO jitter that more sensitive LCD TV's don't accept), but for me (CRT TV) it works well enough.

« Last Edit: October 08, 2016, 03:17:35 pm by olin »

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #15 on: October 08, 2016, 06:30:32 pm »
The cheapest  FPGA with RAM, USB 2.0 (High Speed) I could find is this one ($59):
https://www.aliexpress.com/item/Free-Shipping-CY7C68013A-USB2-0-High-speed-fpga-development-board-altera-data-acquisition-board-EP2C5Q208/1885804485.html
But bear in mind this is undocumented board with maybe some bits of doc written in Chinese. The FPGA chip on this board is quite old one and is probably not supported any more by using current Altera SDK, so it might be a challenge to make it work.
If anybody can find anything cheaper than that let me know.

Another more expensive board (with all the required stuff) is for example this one:
http://www.aessent.com/products/aes220-minimodule.html#!/~/product/id=52901862
It seems to have good documentation and even USB SDK with samples, but the cost is around $100.

MCU based cheap board that 'might' be suitable as well is the latest Nucleo board NUCLEO-F767ZI using Cortex M7 chip. There is both Ethernet and USB and the board is very affordable (around $23).

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #16 on: February 10, 2017, 08:10:31 pm »
"100 MBit ethernet interface for communication with the host PC"

Sounds like LAG to me.


I did some screen lag testing of Arvid output. At first the results didn't look good. There was ~42 milliseconds lag behind SDL screen output when I used my 'development' LCD TV and Arvid was connected to my laptop via ethernet switch. Then I did the same test with my CRT TV and the result were quite different, this time the SDL screen was lagging behind Arvid by ~25 milliseconds (Yes, Arvid displayed image quicker than SDL screen on my Linux laptop). I was wondering why is the lag difference so big (4 frames at 60Hz) then realised I didn't use ethernet switch with my CRT TV test. Then tested again LCD TV with direct network connection and the result shows the ethernet switch adds roughly extra 16.6 milliseconds to the screen lag.   

For the tests I used modified arvidmame with SDL output where I copied the emulated frame onto the SDL screen (normally it displays just the arvidmame splash screen). Then I used my camera to take shots. Note I've also added 2-line frame counter to the screen image to help me identify the screen lag. The frame counter consists of 2 lines , the top one showing frame_number / 10, and bottom one showing frame_number % 10. The bottom line digit is displayed shifted by 8 pixels for every digit to prevent smudging of the digit (if displayed on the same spot). So if line 2 of the frame counter reads 87, that means the shot was taken in between frame 8 and 7.    Results are in the picture  bellow.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #17 on: February 11, 2017, 07:10:38 am »
Hi olin,

Thanks for posting about your tests. I'm assuming when you mention SDL it's because you're doing your tests on Linux. Does Arvid MAME support Windows 7+? If so, it'd be very interesting to do your measurements there too. The Linux/SDL combo is known to be plagued with latency already (hopefully this will be solved in the future). Ideally, your testing setup should include a LED wired to a switch button for input, so you can measure absolute latency of the whole chain.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #18 on: February 11, 2017, 07:35:37 pm »
Hi Calamity,

yes there's several builds of arvidmame available for different OS'es. I made measurements on my spare laptop (Core i3) running Win7 and also on my mini PC (NUC-like, Celeron J1900) running Win8.1, both are 64 bit versions - see the image bellow. Win7 didn't show much of difference compared to Linux as SDL was lagging behind Arvid regularly ~1.3 frame. Win8.1 on the other hand improved considerably lagging behind Arvid most of the time around 0.7 frame with occasional drops to ~1 frame. Both Win computers used the same PC monitor. Just for the record I run the tests with the same binary and the same SDL dll on both computers, also Arvid was connected directly (no ethernet switch) in both cases.
As for the latency of the whole chain, you are absolutely right, that's very important as well. I didn't modify the way mame checks for input in arvidmame, so I expect the input lag will be similar to stock mame.

The goal of this exercise was to find out whether 100 mbit ethernet is causing Arvid a significant screen lag or not. My conclusion so far is: yes there is a lag, but on par with SDL output, usually slightly better than that.

maiki

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 64
  • Last login:April 22, 2019, 05:51:29 pm
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #19 on: February 19, 2017, 11:41:39 am »
As for USB, I have a USB 2.0 analogue TV capture device and it is capable of capturing the standard NTSC / PAL, even from not such standard Atari 2600 games, and yes, at full framerate (240p if you wish). So USB should really not be any limitation regarding standard video traffic.

As for the 15 kHz device, yes, that is definitely needed. How about Uzebox and its implementation of the AD723 / AD725?

no more messing with irrelevant PC VGA cards

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #20 on: February 19, 2017, 05:54:59 pm »
I didn't know about Uzebox, it looks like a cool project. But 4 kbytes or RAM is insanely small IMO. Anyway it doesn't have USB(2) port so you can't transfer images (generated by mame) to it in real time (at 60Hz). If I understand correctly Uzebox does output 15kHz video signal via 3-3-2 RGB DAC (which should be compatible with some newer arcade monitors). The AD725 is a video signal converter producing S-video or composite video out based upon the RGBS input. It's purpose is to be able to hook Uzbox to standard TV (without RGB inputs). So AD725 itself doesn't generate the signal, just transforms it (video quality is degraded in the process). Atmel MCU chip does generate the video signal via GPIOs and the DAC made of resistors - similar way how Arvid does it. Unfortunately low cost Atmel chips don't have high speed interface so you can't pump them with video stream. Anyway, it's an interesting tip.

I also had a look at a cheap USB2 cypress board:
http://www.ebay.co.uk/itm/EZ-USB-FX2LP-Cypress-CY7C68013A-USB2-0-Developement-Board-/232072867953?hash=item36089ef071:g:CIYAAOxy-WxTD-te
People use it as a high speed aquisition board for receiving digital signals and sending them to the host PC. Something like a logical analyser. The good thing is: it has documentation, it is programmable (linux code exists) and there's plenty of GPIO's to generate 15 bit RGB signal. It is possible to reverse the direction of data flow - so rather that reading GPIo's you can output signal and generate RGBS.  It seems to run on 48MHz which is not bad (Arvid's PRUs runs on 200Mhz though), but that might be slightly limiting (in terms of which video modes would be possible). Still an option worth investigating. I have one sitting on my desk, but didn't find time to do something useful with it yet. 

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Yesterday at 06:46:41 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #21 on: February 20, 2017, 04:14:39 am »
This is really, really interesting, as this enables us to generate EVERY SINGLE VIDEO MODE ever existed without limitations (other than bandwidth due to high resolution, but I think we're talking mostly 15khz here).

While the super modes in GM with the ultrawide horizontal resolution is ok most of the time as it gives us enough granularity, I'd still go for a 1:1 with the original resolution where possible to achieve perfect accuracy.

And, if I understood correctly, it only gives us a handful of ms of lag more than a ATI videocard, which is absolutely tolerable.

Please keep us updated on the matter.
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #22 on: February 20, 2017, 04:45:59 am »
And, if I understood correctly, it only gives us a handful of ms of lag more than a ATI videocard, which is absolutely tolerable.

Well... that's assuming a lot. However, latency could theoretically be reduced to zero (or close enough).

And yes, I definitely see this route (Arvid) as the future of analog video for emulation.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Yesterday at 06:46:41 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #23 on: February 22, 2017, 07:13:04 am »
Yeah, sorry, should have phrased that differently as that's my own opinion, referred to *my* tolerance :P
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #24 on: March 04, 2017, 06:56:34 pm »
I hope I’m not too boring wit this stuff, but I managed to shave off some more milliseconds from the screen lag on Arvid. The 'trick' is simple: normally the game is emulated and rendered to a frame buffer (not on the screen yet) in fraction of time of a frame  - let's say 4 milliseconds. The rest of the time (12.6 milliseconds) the renderer waits for vsync event from the video card and then the frame buffer is displayed (at leas that's what happens in arvidmame). So I thought why not make the gap between the time the emulation of single frame ends and the time vsync happens smaller? Why wait 12 milliseconds if I can wait only 2? So I programmed something I call 'virtual vsync' - that is a vsync that happens when line 128 is rendered rather than the last line is rendered which is the normal vsync event. As I can trace hsync events in Arvid, it was simple to do. And It looks it works quite well - see the screen shots from my Win 8.1 mini PC. Previously the screen lag was approx. -0.7 frame on my Win 8.1 set-up (ahead of SDL by ~11.6 milliseconds) now the gap is even bigger by (as expected) another 0.5 frame. On the latest screen shot the gap is between approx. -1.2 to -1.5 frames  - that is Arvid is quicker than SDL on my Win 8.1 by ~ 20 milliseconds. Was it noticeable during play ? To my surprise yes it was! With some simple games (raiden) I could even go to line 192 for virtual vsync to make the screen lag even smaller, but more demanding games had artefacts on the screen (tearing effect) as the emulator could not finish all it had to do within such small time gap (at least on my 2GHz ARM Cortex A-15) - so I went back to line 128 where the games are fine.

If you are interested to see more of the screen shots I did, you can find them all zipped in the original format from my camera here:
https://app.box.com/s/mtfjkjwwc12bede5kkn99j0n40v2fevb

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #25 on: March 05, 2017, 01:51:54 pm »
Hi olin,

So I thought why not make the gap between the time the emulation of single frame ends and the time vsync happens smaller?

That's exactly the same feature as "frame delay" in GroovyMAME. It certainly works :)
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Yesterday at 06:46:41 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #26 on: March 07, 2017, 04:17:42 pm »
Hi olin,

So I thought why not make the gap between the time the emulation of single frame ends and the time vsync happens smaller?

That's exactly the same feature as "frame delay" in GroovyMAME. It certainly works :)

That's exactly what I was thinking while I was reading olin's post, lol.

Keep those updates up olin, I'm really interested in this project.
Also, can you do a comparison between this latest iteration and d3d9ex video backend on your windows machine?
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #27 on: March 07, 2017, 07:18:05 pm »
Thanks for the info. I'm not familiar with GroovyMAME, is there more techniques in GroovyMAME that reduce latencies (screen and input) compared to stock mame? If you don't mind I'll use the 'frame delay' term in arvidmame as well.

 
Quote
latest iteration and d3d9ex
That's a slight problem - those rendering engines are not easy to combine (you can have one or another, but not both at the same time AFAIK). SDL was easy to (ab)use as I create SDL window in arvidmame for reading the input events.  Maybe I could sneak arvid rendering in the d3d3ex code somehow, but I didn't look how easy/hard it would be. Another problem is the compiler environment. Currently the windows code of arvidmame is cross-compiled on my linux machine (it's convenient and virus free) and I'm not sure I have compatible d3d9ex headers and libraries (if at all mame can be build on linux with d3d9ex ). I would have to investigate.

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Yesterday at 06:46:41 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #28 on: March 08, 2017, 07:04:39 am »
I see.

I think someone calculated the difference in lag between SDL and d3d9ex somewhere, that could be a good starting point to know how much lag arvid has against a dedicated Windows d3d9ex machine with GroovyMAME.

Anyway, I'm seriously considering going the arvid way so I can use my iMac to play MAME on my cabinet with 1:1 resolution and (hopefully) low lag.
The only thing I need to do is to modify the resistor values on the output so I have 5v on the RGB lines, this way I can feed the output to my Nanao MS8-29 in my Astro City cab.
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #29 on: March 08, 2017, 06:35:46 pm »
Arvid depends on BeagleBoneGreen GPIO voltage to produce video signal levels (GPIO output is 3.3V). So modifying the resistors will give you no more than 3.3V IMO. This might be enough to drive your monitor, on the other hand the colors won't probably look right.
For something more serious you may need a video amplifier made out for example of high-speed op-amp IC (max4386). I was thinking about raising Arvid's video signals to 5V recently and already designed the following little add-on board (see the snapshot). It doesn't look pretty, but allows me to experiment at least on my supergun (I don't have arcade monitor available) with current Arvid board. I've soldered it literally just yesterday and tests on the scope look promising (everything looks as expected, levels amplified between 0-5Volts).
If you decide to build Arvid let me know I can send you unpopulated PCBs (arvid and the amp addon pcb).

Edit: removed el5462 op-amp, as it is current feedback amp, not voltage feedback amp...
« Last Edit: March 08, 2017, 07:09:51 pm by olin »

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Yesterday at 06:46:41 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #30 on: March 09, 2017, 02:38:39 pm »
This is something I really want to do sooner or later, but right now I'm kind of broke (just got my cab and spent lots of money on components to get it working right) and my spare time is running really thin.

I was looking at BBB yesterday and it doesn't come too cheap either, it's 60€ + shipment here in Italy.

I'll definitely follow Arvid's development and I'll dive in as soon as I have some cash back and some free time to dedicate to this project.
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #31 on: March 09, 2017, 07:07:45 pm »
Quote
I was looking at BBB yesterday and it doesn't come too cheap either, it's 60€ + shipment here in Italy.
Do not use BBB they are overpriced, use BBG instead. They are  cheaper and do the job equally well, actually all my latest development and testing is on BBG, so I definitely recommend BBG. You should be able to get it for 40€ including shipment directly from seeedstudio ($39 + $3 shipment, after currency conversion ~40€). I bought few from them, the shipping cost was about 3$ to the UK. Anyway, there is no rush.

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Yesterday at 06:46:41 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #32 on: March 10, 2017, 11:33:22 am »
Thanks for the link! I'll definitely buy it from there.

Meanwhile, I was wondering if Arvid could be implemented into groovymame. It shouldn't change much theoretically, if I'm not wrong it's about adding support for a new hardware.
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors

maiki

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 64
  • Last login:April 22, 2019, 05:51:29 pm
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #33 on: April 13, 2017, 10:59:58 am »
I really wish you guys with the knowledge manage to build this device. I am literally sick with all that PC VGA cards nonsence for years and years and no definite standard nothing. One things works, another one does not. Perhaps something like that RGB output module for Raspbrry Pie (Pi2scart)?

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #34 on: April 13, 2017, 07:46:04 pm »
Quote
I really wish you guys with the knowledge manage to build this device.
Thanks for the kind words. A very similar device (not based on FPGA but MCU) has been already built. If you scroll few posts above you'll see the board and if you scroll even more you can see some images it produces on the SCART TV (RGB). If you are brave and live in Europe you can buy one at ebay these days :)

antoniomauro

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 22
  • Last login:September 02, 2022, 10:39:41 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #35 on: April 27, 2017, 11:26:25 am »
Where can i find a board to assemble/test this very promising solution?

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #36 on: April 27, 2017, 07:33:42 pm »
Where can i find a board to assemble/test this very promising solution?

If you want to try super cheap and have a Euro SCART TV you use just a bread board, resistors, BBG, SD card, SCART socket (or SCART cable if you are OK to solder the wires directly to it).  The IC chip only helps with booting - BBG uses some of the GPIO to determine the booting sequence. But if you connect the resistors (wires going to the resistors) AFTER the boot, you should be fine and no IC is required. To make the assembly even more quicker/simpler don't use all 5 bits (resistors) per color, but use only 2 or 3 bits per colour (wire up the smaller values , 510, 1k and 2k2). Even though you will get less colours you can still observe the latencies and all other stuff you are interested in (old games from early 80's didn't probably use more colours anyway). The schematic is on the ARVID's main page: http://mujweb.cz/molej/arvid/index.htm
If you'd prefer a photograph how it should be wired on the breadboard I can probably do it in few days for you.

If you don't have Euro SCART TV (that accepts RGB signals) but only 15kHz Arcade monitor, things might be more complicated, depending on your monitor (whether it accepts 1V signals, or signals up to 3.3V). If your 15kHz Arcade monitor only accepts 5V signals you'll probably need a video signal amplifier.

For anything more permanent you can buy a PCB (gerber files are on the same site) from an online PCB service and then solder parts on it (resistors and an IC, pins that connect to BBG). If obtaining a PCB seems too complicated then just PM me and I can send you one unpopulated PCB (I still have few left).

funkycochise

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 101
  • Last login:October 22, 2019, 07:35:18 am
  • 8 bits generation
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #37 on: April 29, 2017, 01:51:06 am »
Very interesting topic. Very original approach.
anyone has a link for the Bgg or Bbb chip ?
Seems very promising. I am very motivated to build one and see what I can give to the project,
in a matter of GUI on cab.

maiki

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 64
  • Last login:April 22, 2019, 05:51:29 pm
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #38 on: April 29, 2017, 08:47:45 am »
So, is Arvid the right thing for me?

Can I create custom horizontal resolutions with it or does it restrict me to those listed in the specifications?
Does it work in Windows with any software (version of MAME) or is it required to reprogram/patch the programs for it?

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Yesterday at 06:46:41 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #39 on: April 29, 2017, 12:14:55 pm »
I think I can reply to some of those questions:

You need a customized version of the software you want running.
There is a MAME version called ArvidMAME iirc which is tailored to use this project, so you have to use it.

It will not work out of the box with any software.

Also, talking about arcade monitors, does Arvid output a DC coupled or AC coupled video signal? Does it output standard 0.7V?

I'm asking because I'm working on an adapter to make consoles work on my cabinet and I'm having a hard time finding something "universal" which works with all consoles and delivers a good picture. A video amp alone is not enough, as console outputs are AC coupled and arcade monitors expect DC coupled video signals, so at least a clamp is needed.
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #40 on: April 29, 2017, 08:49:11 pm »
Quote
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.

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

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

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

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

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

Quote
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.
« Last Edit: April 29, 2017, 08:53:01 pm by olin »

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Yesterday at 06:46:41 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #41 on: April 30, 2017, 06:56:23 am »
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!


Quote
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! ;)
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors

maiki

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 64
  • Last login:April 22, 2019, 05:51:29 pm
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #42 on: April 30, 2017, 08:15:08 am »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #43 on: April 30, 2017, 10:13:19 am »
Quote
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.
Quote
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 64
  • Last login:April 22, 2019, 05:51:29 pm
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #44 on: April 30, 2017, 10:45:12 am »
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

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 6
  • Last login:August 22, 2019, 02:19:15 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #45 on: May 05, 2017, 08:22:30 am »
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).
« Last Edit: May 05, 2017, 10:08:15 am by lugaidster »

olin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #46 on: May 05, 2017, 08:32:20 pm »
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

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 6
  • Last login:August 22, 2019, 02:19:15 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #47 on: May 05, 2017, 09:39:44 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:June 30, 2018, 01:54:44 pm
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #48 on: May 06, 2017, 08:44:26 am »
Quote
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.

« Last Edit: May 06, 2017, 09:57:04 am by olin »

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Yesterday at 06:46:41 am
  • I want to build my own arcade controls!
Re: FPGA based dumb frame buffer - Why has this not been created?
« Reply #49 on: May 06, 2017, 09:41:38 am »
You can also use 4 trimmers so you can manually adjust each line until you have good results on screen!
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors