FPGA Based Videogame System

[Newsdee]

The MiST supports USB controllers (inc. Keyboard and mouse), MIDI in/out ports, VGA out, and gets data from an SD card.

 

It cannot connect to cartridges natively with the current design, and needs an external upscaler/converter for HDMI.

 

It looks like the z3k will do both of the latter out of the box. Not sure about loading ROMs from an SD card but perhaps that isn't the point of it (you could use an Everdrive for that). USB can probably be added as an external microcontroller if it doesn't come with it.

[Keatah]

IIRC Z3K is going to load from SD card, too.

[aloram]

 

#1: The goal is a 100% "authentic" experience, and I think I achieve a pretty decent score here. Things like video frame timing are exactly the same as a real system, down to the number of scanlines and cycles per scanline even.

 

#2: Not sure what you mean. It's a piece of hardware like anything else, and since I design conservatively, the hardware should live a fairly long time. Since the systems are written in verilog, it means that they are pretty much immortal, and new hardware with new models of FPGA, etc. can be used. The resulting hardware should work and act exactly the same as any previous models.

 

#3: The only one I can think of is cost.

 

Thanks a lot for answering my questions.

 

In my second question, I was asking if you expected the Zimba 3000's hardware to outlive the hardware of the original systems (such as the NES, Master System, etc.). I don't know how to describe it in technical terms, but basically, those systems will stop working at some point, and I was wondering you expect the Zimba's hardware to still be going strong when that happens.

 

I have a few other questions, but I'm not trying to monopolize your time here, so of course it's no problem at all if you don't answer them.

 

1. Any chance the FDS will be one of the systems in the Zimba? You mentioned Famicom, but I'm assuming you meant just the regular system, not the Disk System.

 

2. If the Zimba supports SD cards, will there be a barebones menu from which to run ROMs, or will there be more options, such as what the Everdrives feature? I guess my question is about both the menu and whether or not certain features like save states will be "built in" to the Zimba. I have most of the Everdrives, and I'm just curious if the Zimba would render some or all of them unnecessary.

 

3. What do you expect the Zimba to have as far as controller ports? I mean, will it be possible to use the original controllers without buying third-party adapters, or will you offer certain upgrades so, say, I could plug my NES controller straight into the Zimba?

 

Thanks again. Looking forward to seeing how things evolve with the Zimba 3000.

[Newsdee]

For 1) if it runs carts natively (without dumping the ROM I mean) then you can just plug a FDS into it. If you don't want to bother with the floppies or the bulky unit, just get s loose RAM adapter and one of those "FDS sticks". I have the latter and it works great.

 

For 2) you could just plug an Everdrive into it as well. It can implement the same features although they did get creative and e.g. supported save states on some NES mappers, which might take a bit to replicate on the Z3K. But the hardware can do it in principle.

[iwasaperson]

Will you be open sourcing the verilog cores either on release or after a period of time as to preserve these consoles? If you're worried about clones coming out, you could always go the id Software route and open source them after 5 years or so.

[brentonius]

This thread brought up an interesting point... The lifespan of old systems in comparison to these new FPGA built systems. Will old systems really die if we care for them well, change capacitors, etc?

Edited June 7, 2016 by brentonius

[Keatah]

The geometry of the old systems is set to live for 200 years or more. Many of us vintage enthusiasts have semiconductor products that are approaching 50 years old now. Not too shabby. And the program data is hardwired for most cartridges. Not stored in some sort of flash device or magnetic media. Though I have magnetic media that's 40 years old already!

 

Will your iPhone still work in 50 years? What would be its point of failure?

 

To keep an old system working, all you need to do is use contact cleaner, be gentle with the power - no frying, and be sure the capacitors remain in specification. Don't wait till they pop or short out.

 

As for this "new generation of FPGA-systems". They're not going to be long-lived. I can't see them making past 30 years at best, maybe if you don't play them too much. Anything with "charge storage" technology isn't built for the long haul.

[Keatah]

Will you be open sourcing the verilog cores either on release or after a period of time as to preserve these consoles? If you're worried about clones coming out, you could always go the id Software route and open source them after 5 years or so.

 

I would suggest that the source remain closed for x amount of time, and when the original author gets tired of maintaining it or moves on - then it gets released into PD. This seemed to work ok for a couple of projects I watched over the years.

[Keatah]

In order to maximize sales, I think this Z3K will need emphasis on 16 bit systems now more than ever. The 8-bit stuff like the VCS and Intellivision and Colecovision is falling off the radar as the window of interest moves along the timeline. It's currently framing the NES.

 

Having said that, and being of the old-school guard, I want to see some good Astrocade emulation. The shit we have now is just that, shit. Rendered stinky by a bad user interface. So bad I had to roll my own.

[kevtris]

I find it particularly impressive that your FPGA NES will output identical waveforms with a real NES. If I read that correctly, it should put out the same video signal, warts and all, hopefully minus jailbars. In this case I am talking about the three-line stairstep effect that was intended to reduce the effect of composite color artifacting. The effect tends to make screenshots and video capture of the native NES signal look much more ugly compared to other systems of the 1980s that do not use this effect.

well that's a different thing. jailbars are caused by some kind of issue in the PPU or power such that the access pattern on the video bus is visible. The missing pixel trick to make still images on the NES look better by changing the dot crawl pattern is still there. I implement that just like a real NES does. I can't really eliminate it either, because then timing is slightly upset and that would be detectable by software. I guess if you hate it that much you can use RGB or HDMI.

[kevtris]

The MiST supports USB controllers (inc. Keyboard and mouse), MIDI in/out ports, VGA out, and gets data from an SD card.

 

It cannot connect to cartridges natively with the current design, and needs an external upscaler/converter for HDMI.

 

It looks like the z3k will do both of the latter out of the box. Not sure about loading ROMs from an SD card but perhaps that isn't the point of it (you could use an Everdrive for that). USB can probably be added as an external microcontroller if it doesn't come with it.

 

Yes, loading ROMs off SD card is one of the big things I want to do since I don't really like having to keep around a bunch of obsolete storage media for games :-) I have full mapper emulation on all systems and this is indeed how I have been playing the games. So it's basically like having an FPGA NES and a powerpak/everdrive built in. Though, at least on NES/fami, I support waaay more stuff than either of those cartridges do. All mappers and all audio is fully supported. The only thing not supported right now is FDS, but I was going to add this. It isn't that hard to add- I just sorta never got around to it and I was waiting for "Raw" FDS formats to emerge... which finally did. Right now, I have been sending ROMs from the PC to the system through a USB interface to play them.

 

Recently I made a Gameboy ROM adapter for my ROM/cart emulator project (it appears earlier in this thread) and ported my GB mappers directly from the FPGA GB to it, and it worked great- using my Verilog mappers on a real gameboy.

 

 

 

 

Thanks a lot for answering my questions.

 

In my second question, I was asking if you expected the Zimba 3000's hardware to outlive the hardware of the original systems (such as the NES, Master System, etc.). I don't know how to describe it in technical terms, but basically, those systems will stop working at some point, and I was wondering you expect the Zimba's hardware to still be going strong when that happens.

 

I have a few other questions, but I'm not trying to monopolize your time here, so of course it's no problem at all if you don't answer them.

 

1. Any chance the FDS will be one of the systems in the Zimba? You mentioned Famicom, but I'm assuming you meant just the regular system, not the Disk System.

 

2. If the Zimba supports SD cards, will there be a barebones menu from which to run ROMs, or will there be more options, such as what the Everdrives feature? I guess my question is about both the menu and whether or not certain features like save states will be "built in" to the Zimba. I have most of the Everdrives, and I'm just curious if the Zimba would render some or all of them unnecessary.

 

3. What do you expect the Zimba to have as far as controller ports? I mean, will it be possible to use the original controllers without buying third-party adapters, or will you offer certain upgrades so, say, I could plug my NES controller straight into the Zimba?

 

Thanks again. Looking forward to seeing how things evolve with the Zimba 3000.

 

Ah I see. Well, I don't know why it wouldn't live a long time. The good news is there's nothing custom in it, so if the Cyclone V FPGA goes obsolete in 5 years, I can just design in a Cyclone 10 or whatever they have then, or even change to another vendor totally if need be. Once the system is rendered into Verilog, it's pretty much immortal and can be ported forever in the future as new technology emerges. I fully expect to have a very nice menu interface for selecting games and stuff off SD card. Basically, when you fire it up, a menu will appear that lets you select the system you wish to play, and then present a list of games for said system that live on the SD card. Kind of like a Powerpak/Everdrive but a lot nicer and more polished.

 

For controllers I was expecting to have 2 or 4 USB ports to accept controllers, keyboards, and mice. There was going to be a 'legacy' port that would allow one to make or buy adapters to plug in native controllers like zappers and d-pads and what not. Right now I have been mostly using a fake keyboard interface on the PC (that lets me "type" to the FPGA) and SNES controllers. i..e. for 2600, start and select on the SNES controller do reset and select on the console, and the L and R triggers toggle the two difficulty switches. X toggles the B&W/colour switch too.

 

For cartridge adapters, they will run everything a 'real' system runs, including power paks, everdrives, etc. It won't just dump the game and run the ROM, it will play the cart itself.

 

 

 

Will you be open sourcing the verilog cores either on release or after a period of time as to preserve these consoles? If you're worried about clones coming out, you could always go the id Software route and open source them after 5 years or so.

 

No, I will not be open sourcing anything unless someone pays me a lot of money, then I might :-) Or if the project took off and got popular I might as well.

 

 

This thread brought up an interesting point... The lifespan of old systems in comparison to these new FPGA built systems. Will old systems really die if we care for them well, change capacitors, etc?

 

Well you can keep just about anything going with enough work, but it will probably require donor systems to keep i.e. the NES going. I can keep making new revs of my hardware forever though since the Verilog code will directly port and run on new hardware.

 

 

In order to maximize sales, I think this Z3K will need emphasis on 16 bit systems now more than ever. The 8-bit stuff like the VCS and Intellivision and Colecovision is falling off the radar as the window of interest moves along the timeline. It's currently framing the NES.

 

Having said that, and being of the old-school guard, I want to see some good Astrocade emulation. The shit we have now is just that, shit. Rendered stinky by a bad user interface. So bad I had to roll my own.

 

Yes I am going to be working on lots of 16 bit systems for it. I really want to get SNES and genesis on there for sure. SNES is going to be extremely tough, and I am going to have to make a pretty insane test rig to do it. I will detail more of that as it progresses, but the basic idea is having a large FPGA, and then connecting each SNES chip up to it separately and then passing the signals from each chip THROUGH the FPGA to the other chips. This will allow me to probe the exact operation of each chip in extreme detail, and then replace and replicate each chip one at a time, running the 'Real" chip and my fake one in parallel to spot any differences. This should theoretically let me make an "exact" black box copy of the system. That's the theory anyways.

 

As for astrocade, I can probably add that in a few days. My friend Jason lent me an Astrocade, so I will put it under the knife and do some probing on it. Z80 is done, and the system is just an overgrown framebuffer so making it work can't be too difficult. The audio will be the trickiest part, and is the place where I will be putting most of the work since I think audio is still a touchy area on emulation. It has some really weird sound capabilities and I want to get a good replication of this going.

[Newsdee]

Re: open source, I don't suppose there will be anything preventing the port of a 3rd party open core to it by other people?

 

Although maybe the "controller" part of the machine will need to be documented well for that to be possible.

[Schizophretard]

If I understand correctly your "clone turing test" would be putting it inside the original console box and check whether the electrical signals are exactly the same as the original on each port (video, controllers, etc).

You are understanding me correctly. In my opinion, that would be perfect emulation and anything less would just be attempted or approximate emulation.

 

FPGAs are much better suited for that than emulators and would consume much less power for an accurate rendition. Emulators can achieve accuracy too but with a much stronger CPU (see higan/bsnes) and higher power consumption. At least from what I've tested with my hardware (MiST FPGA, RPi, PC and a few consoles).

 

 

Also I do not think an emulator exists that supports all accessories natively. The Retro Freak (for example) doesn't output composite so can't support it.

Hmm... I'm still confused about some things but I'm not sure how to express it. I'm trying to figure out which one, if either, would inherently have the potential to be superior at emulation. Maybe these examples would help show what I'm struggling to see:

 

When I think of my understanding of what Kevtris is doing with cores it seems like a process of reverse engineering, making the cores, and then it is pretty much a done deal. There may be a few tweaks here and there and adding extra features that the original hardware didn't have for updates but for the most part the cores would be finished. But with software emulators I read people talking about how they are constantly being updated, getting more accurate, the process is still going on, and they aren't finished yet. Why is that? Is it because writing a core for an FPGA is inherently superior at finishing the process? Or is it the opposite more like the beginning of the process and limited to that kind of like an FPGA could be 99% accurate but software emulators are already 99% accurate but can go beyond an FPGA with updates making them 99.1%, 99.2%, 99.3.%, etc. accurate? In other words, why is it that Kevtris makes it seem like he can finish a core within months or a year but software emulators have been worked on for decades with updates and are still not done yet? And what is inherently different between the two to cause this? And I'm not referring to updates that add extra features, or ports for different operating systems, or things like that but updates that make the emulation more accurate and complete.

 

Why is it as you say that emulators don't exist that support all accessories natively but Kevtris can already get a Zapper to work? I would think that working with the accessories would be basic necessary functions that would be added before CRT effects, save states, and other extras. Why if emulators have been worked on for decades do they not have all the basics down yet? What is different with the development processes to cause this?

 

Why is it that there are more than one emulator for consoles? Are they just making educated guesses and competing because they disagree about the best methods or something like that? Or do they just want to say,"I made an emulator too!"? Or something else? I would think that they would just be working together to combine efforts to make one emulator for each console because each one only needs one good emulator. As a side note to that, I don't understand why people would say that they prefer one emulator over another, while others would disagree and prefer another, and while both could claim that emulation is reaching a point of 99% accuracy. Is each emulator 99% accurate on their own or is it that what is really meant is if you download every emulator for a console that the pros of all of them would cancel out the cons and therefore all of them together make them 99% accurate? Also, what are usually included in the left over 1%, why are they included, and where does the math that those making claims about 99% accuracy come from?

 

If you goal is replicating accurately real hardware without embellishments or extra features then IMHO FPGAs are the way to go (to just play the games an emulator will do fine, or even better considering 3D upscaling).

I would think that the goal of any software or hardware emulator would have replicating accurately real hardware as its primary goal because by definition that is what an emulator is. To emulate is to replicate.

[Andromeda Stardust]

 

Unless your emulator and the hardware it runs on supports output to a 15KHz CRT screen, there would be no point to Zapper emulation, the Zapper just wouldn't work.

 

A Raspberry Pi has a composite video jack, so you could theoretically design a NES emulator that would output its video image to the right kind of TV. However, it is a software NES emulator and depending on the processing power of the CPU, there may be substantial input latency. That may throw off your Zapper aim. Please note that the Zapper is not the most precise device ever made.

Suppose one rigged a seven pin NES socket up to the GPIO pins with 3.3-5v logic shifters. The Raspberry Pi CPU would need to know the exact timing of the composite signal as the beam moves across the screen, continuously checking for inputs from the Zapper.

 

Software emulators don't work that way. In real hardware, the state of the PPU can be altered by CPU at any time during the frame. In a software emulator, the inputs are read, then the entire contents of the video frame are computed. This frame data is then sent to the GPU buffer and output on Vsync. The video buffer creates at least 16ms of lag. For the Zapper to work, the light input from the zapper needs to be processed immediately before the next frame. But the fact the screen data is stored in a frame buffer before being pushed to the display device, means the data from the zapper detection will be delayed into the next frame.

 

This would complicate detection immensely. Upon trigger pull, the emulator would need to hold the screen flash long enough to determine whether or not the zapper detected light. This may cause the game to stutter every time the zapper trigger is pulled. After the frame has been output from the GPU, and if a light detect event has occured, further analysis may be needed in the event of multiple targets to determine the exact timing of the light detect event, and compare it to the timing of the composite output scan. I'm not even sure it's possible to precicely measure the timings of GPIO inputs and composite GPU output. If so, no emu authors would take the time to incorporate a feature that few users would ever use.

 

It would be far easier to set up a mouse, or pair a USB Bluetooth dongle to Wiimote using a sensor bar to aim the gun. Great part about that setup, is somebody else besides the emu author can write the driver file necessary to use the Wiimote as a mouse.

[Newsdee]

I'm trying to figure out which one, if either, would inherently have the potential to be superior at emulation.

Here the problem is defining what we mean by emulation. If the goal is to:

* Run a game at 60fps with original sound regardless of hardware, then both FPGA and software can do it.

* Replicate the hardware itself at electrical level (without enhancement), then FPGA are better.

* Improve on the original game (better graphics or other feature not originally available), then software approach is better (currently; and you sacrifice connectivity to real hardware and need more power to run it)

 

Why is that? Is it because writing a core for an FPGA is inherently superior at finishing the process?

It's the approach, which has nothing to do with whether you later implement it in software or FPGA. Kevtris is analyzing each component at the electrical signal level. Once you have that well documented, it becomes possible to both write an accurate emulator or reimplement the logic in FPGA.

The FPGA approach is closer to the original electronic implementation than the software approach, but both can deliver playing the game in the same way. In my experience the FPGA approach is more power-efficient though, which to me flags it as objectively superior for the same task (of replication only, no enhancement).

It's even more power-efficient than real hardware (from what I've measured myself)... so FPGA are an improvement over the original too.

 

Why is it as you say that emulators don't exist that support all accessories natively but Kevtris can already get a Zapper to work?

Mainly because they aren't needed to play the games. The goal of most emulators is to run the game on PC and computer monitor, not to use the zapper on a CRT. There are other alternatives to provide the same experience (like using a Wiimote).

 

Why is it that there are more than one emulator for consoles?

(...)I would think that they would just be working together to combine efforts

Why is there more than one Linux? Why is there more than one text editor? Why is there more than one browser?

As for the latter it already exists and is called MAME...

 

where does the math that those making claims about 99% accuracy come from?

I think you'll find this article interesting (bsnes/Higan): http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/

 

It hits a key point: to be completely accurate you need a 3Ghz processor to make sure everything runs in sync. Instead FPGA natively runs things in parallel... which means it can achieve the same synchronization effortlessly (assuming you have all the original hardware analyzed).

Edited June 8, 2016 by Newsdee

[narshe]

@kevtris, since we're talking about support for the Zimba, will you be doing Neo Geo (I think you said yes to this already), Sega CD, Sega 32X, TurboGrafx-16, TurboGrafx-CD, System Card 3.0 and Arcade Cards for PC Engine?

 

I'm getting way too excited for this man.

[Great Hierophant]

Suppose one rigged a seven pin NES socket up to the GPIO pins with 3.3-5v logic shifters. The Raspberry Pi CPU would need to know the exact timing of the composite signal as the beam moves across the screen, continuously checking for inputs from the Zapper.

 

Software emulators don't work that way. In real hardware, the state of the PPU can be altered by CPU at any time during the frame. In a software emulator, the inputs are read, then the entire contents of the video frame are computed. This frame data is then sent to the GPU buffer and output on Vsync. The video buffer creates at least 16ms of lag. For the Zapper to work, the light input from the zapper needs to be processed immediately before the next frame. But the fact the screen data is stored in a frame buffer before being pushed to the display device, means the data from the zapper detection will be delayed into the next frame.

 

This would complicate detection immensely. Upon trigger pull, the emulator would need to hold the screen flash long enough to determine whether or not the zapper detected light. This may cause the game to stutter every time the zapper trigger is pulled. After the frame has been output from the GPU, and if a light detect event has occured, further analysis may be needed in the event of multiple targets to determine the exact timing of the light detect event, and compare it to the timing of the composite output scan. I'm not even sure it's possible to precicely measure the timings of GPIO inputs and composite GPU output. If so, no emu authors would take the time to incorporate a feature that few users would ever use.

 

It would be far easier to set up a mouse, or pair a USB Bluetooth dongle to Wiimote using a sensor bar to aim the gun. Great part about that setup, is somebody else besides the emu author can write the driver file necessary to use the Wiimote as a mouse.

 

I think someone wrote that you need an Ardiuno to interface between the Pi's general I/O and the NES controllers simple switches and shift registers.

 

Even so, the NES typically does not alter the state of the PPU during its drawing of its current frame absent special features like scanline IRQs and MMC5 split screen.

 

The requirement for minimal lag when dealing with true Zapper input is because the black screen and the white box last for one frame each, and the Zapper is looking for black followed by white. If you have a little more than 16ms of lag, you theoretically could never hit what you were aiming at. A good Zapper game uses large targets and starts them off moving at a reasonable speed. Bad Zapper games start out with small, fast moving targets (I'm looking at To the Eath here).

 

However, emulators somehow get around this when they use a mouse as a Zapper. They may not care about the black screen, only the white box, but that does give them a screen's worth of latency to figure out if your mouse is over the target. Moreover, they can retain the image in its buffer, so it can know precisely where your mouse cursor was when you clicked the pointer and process it as a hit or miss accordingly.

 

Kevtris' Zimba 3K gets around this by providing an analog output appropriate for a CRT TV without perceptible lag.

Edited June 8, 2016 by Great Hierophant

[Keatah]

1- But with software emulators I read people talking about how they are constantly being updated, getting more accurate, the process is still going on, and they aren't finished yet. Why is that? .. In other words, why is it that Kevtris makes it seem like he can finish a core within months or a year but software emulators have been worked on for decades with updates and are still not done yet?

 

2- And what is inherently different between the two to cause this? And I'm not referring to updates that add extra features, or ports for different operating systems, or things like that but updates that make the emulation more accurate and complete.

 

3- Why if emulators have been worked on for decades do they not have all the basics down yet? What is different with the development processes to cause this?

 

4- Why is it that there are more than one emulator for consoles?

 

5- Are they just making educated guesses and competing because they disagree about the best methods or something like that?

 

6- Or do they just want to say,"I made an emulator too!"? Or something else?

 

7- I would think that they would just be working together to combine efforts to make one emulator for each console because each one only needs one good emulator.

 

8- As a side note to that, I don't understand why people would say that they prefer one emulator over another, while others would disagree and prefer another, and while both could claim that emulation is reaching a point of 99% accuracy.

 

9- Is each emulator 99% accurate on their own or is it that what is really meant is if you download every emulator for a console that the pros of all of them would cancel out the cons and therefore all of them together make them 99% accurate?

 

10- Also, what are usually included in the left over 1%, why are they included, and where does the math that those making claims about 99% accuracy come from?

 

11- I would think that the goal of any software or hardware emulator would have replicating accurately real hardware as its primary goal because by definition that is what an emulator is. To emulate is to replicate.

 

1- This is pretty much self evident. It comes down to the amount of time spent researching and reverse engineering. The more time spent, the more accurate you get. IIRC Kev has been building the set of cores for years now. This isn't a one weekend fling and BAM, a new system appears.

 

2- Working with physical things in the physical world imposes some restrictions. You can't get carried away by theory and then gloss over it with approximations. The process is more mechanized and regimented.

 

3- Same.

 

4- Because there are many more people working in software than hardware.

 

5- Some are, yes. Some may disagree with other's approaches.

 

6- No. There are easy ways to get a "I can do this too!" Fix. A lot emulators were born out of Computer Science classroom projects and a desire to have their childhood systems recreated.

 

7- The real world does not operate this way. Something as simple as a language barrier or time schedule can get in the way.

 

8- I prefer Altirra for Atari 400/800 emulation over MESS & MAME. And that's because of the user interface, accuracy, and ongoing development for new amenities and side features like new expansion options and memory configurations.

 

9- Some emulators are 90% accurate, some 99.5%. And it is generally accepted and understood to be on an individual basis. Not collectively. And which aspect of the machine are we talking about? The main 6502? Or a supporting video chip? Or bus logic? Or overall?

 

10- There is no hard/fast list of implemented vs. unimplemented features. 99.9% is an approximation. You cannot easily compute something like this. So we go on feel and pull it out of our ass holes.

 

11- I'm sure every software and hardware emulator is architected with the best intent to be as accurate as they humanly can.

[Keatah]

This would complicate detection immensely. Upon trigger pull, the emulator would need to hold the screen flash long enough to determine whether or not the zapper detected light. This may cause the game to stutter every time the zapper trigger is pulled. After the frame has been output from the GPU, and if a light detect event has occured, further analysis may be needed in the event of multiple targets to determine the exact timing of the light detect event, and compare it to the timing of the composite output scan. I'm not even sure it's possible to precicely measure the timings of GPIO inputs and composite GPU output. If so, no emu authors would take the time to incorporate a feature that few users would ever use.

 

That way *I* understand light gun operation is this.

 

1- There is a simple photosensor/transistor in the gun. And it is behind a lens, so it sees one tiny square inch of the CRT.

 

2- When you pull the trigger, the Game Program stops running so to speak. It goes into a special loop

 

3- This loop blanks the screen, usually black. Then it turns on the photo sensor in the light gun.

 

4- It starts a counter. 1-2-3-4-5-6-and so on.

 

5- As this counter is counting the electron beam is drawing one pixel at a time. Or one scanline at a time. Left to right. Top to bottom. The raster, you know..

 

5- Now when the Light Gun sees the transition from dark to light it essentially "pushes the fire-button".

 

6- If the gun is aimed at the center of a 256x256 pixel image. It will "alert" the console 32,768 pixels into the count that started in step #4. The console will draw 32,768 pixels before the gun registers the dark-to-light transition. And if you do the math 32,768 is the center of a 256x256 array. So therefore you aimed at the center. If the detected a dark-to-light transistion right away, early in the count, like 10, then it'd be pointing to the upper lefthand corner. Likewise 65536, means the lower righthand corner. That's why you see a white flash, a single frame of white. Slow it down with a high speed camera to see the screen being made white one pixel at a time. In interest of speed and memory requirements, they may break the screen up into much lower resolution, perhaps a 32x32 array of large square pixels or sprites. After all you don't need that much precision in a game.

 

That is why the screen flashes.

 

I believe this is how the early light guns worked on like the Coleco Telstar and dedicated Target Shooting games. The TV Scoreboard with the Pistol from RadioShack comes to mind. As does the SkeetShoot version with the rifle. Incidentally this is also how light-pens work.

 

--

 

Other designs blank the screen and draw the targets sequentially, but fast. Target one at time index A, target 2 at time index B, target 3 at time index C.. When you pull the trigger the sequence starts and if you are correctly aimed at target B, the console will notice the trigger is pulled while it rendered target B. But if you were off-target, to the left or something, there would be no match. No transistor detection, no light detection, dead. Thus you missed!

 

This method can be used to eliminate screen flashes. Just the potential soon-to-be-shot-at targets would flash. And they could do it 2x to confirm you're not pointing at a light source, this hitting target #1 all the time by default!

 

--

 

Newer methods use IR tracking which is a topic for another thread if anyone wants to start it.

 

--

 

There is nothing stopping emulator authors from simulating the drawing of a black screen and painting it white, pixel by pixel, and counting the time. Then reporting that to the Game Program being emulated. Absolutely nothing.

 

There would have to be lag calibration. Whether it be 3 ms or 16 ms. But you have a lightgun hooked up and pointing at the screen would close the loop for calibration. Point the gun at the screen center, pull trigger, emulator counts up, calculates center position and time to register. And done!

[Andromeda Stardust]

Keatah, one thing you are forgetting is that in real hardware, the machine code needs the input from the lightgun now, and this signal may impact what is drawn on the very next frame. So waiting a couple extra frames to get signal back from the lightgun would necessitate emulating every possible outcome in realtime, then going forward with the correct response. Mouse pointer or Wiimote for Zapper emulation works because while there is screen lag and input lag, it is incorporated into the software. Take Duck Hunt for example. You click or point at the duck and press the corresponding input for trigger pull. The screen you see may be delayed, but the actual X,Y coordinates are tracked in software in realtime. A single frame is a very short span of time, and is it high likely that your target has not shifted much onscreen since you aimed and fired. Hence it is still possible to get fairly accurate results in the emulator, despite those results being inferior to playing on real hardware with a CRT.

 

A better example besides Duck Hunt or Hogan's Alley would be Wild Gunman, as it not only tells you if you hit or miss, but also displays your reaction time. This allows you to get a fairly rough estimate of lag by subtracting your average reaction time playing on CRT to your average reaction time playing in emulator. On my NES, I tend to average 0.32-0.35 reaction time on Wild Gunman, single gunman mode. I do get outliers like with any mean distribution, but in general there isn't a lot that I can do to shorten my reaction time on a consistent basis. None of the gunmen have a draw speed less than 0.40, so I almost never miss the shot. In fact I rolled the score back to zero at one million, and rolled round 99 back to round zero as well, before turning off the system. I would take a gander that if I were to play Wild Gunman on a PC emulator with a mouse, or the official Wii-U VC port, my reaction time would be less than with CRT and lightgun (even my 23" ASUS 1080p gaming monitor has ~8ms response time, slightly better than the ~16ms afforded by the Wii-U Gamepad, and this is in addition to any internal frame buffers), and I would be more likely to score a miss when the 0.40 dude draws his weapon.

[matter]

Would it make sense to release a first iteration of zimba with limited scope? Maybe just those 8-bit cores that are ready. This could help establish demand and identify issues with design or implementation. Not to doubt Kevtris' skills, but the 16-bit system cores will be a huge challenge to get right.

 

Is there a "buy Kevtris a beer"page anywhere? Kevtris'projects are all impressive and I wish the best of luck, no matter what the result.

[Pixelboy]

Would it make sense to release a first iteration of zimba with limited scope? Maybe just those 8-bit cores that are ready. This could help establish demand and identify issues with design or implementation. Not to doubt Kevtris' skills, but the 16-bit system cores will be a huge challenge to get right.

It's a FPGA-based console, which means it's designed to receive any core, whether it's 8-bit or 16-bit. So technically, Kevtris could release the Zimba now with the cores he's got implemented, and deliver the 16-bit cores later. Loading any core simply involves having that core on an SD card and following a procedure to have it loaded for the game you want to play.

 

My guess is Kev will want to have the Super-NES and Genesis cores done before he tackles proper mass-production of the Zimba, because being a FPGA console implies that it's a mostly open architecture, and he will not want someone else writing a 16-bit core for the Zimba that doesn't meet his (very high) standards. I would probably do the same if I were in his shoes, to be honest.

[brentonius]

Is there a "buy Kevtris a beer"page anywhere? Kevtris'projects are all impressive and I wish the best of luck, no matter what the result.

There should be! The guy is doing fantastic work... and just generally seems likeable. Anyways, I think the big thing Kevtris is doing goes beyond simply making cool stuff for gamers and collectors like us. It's a step in the right direction for preserving gaming history. The SNES, NES, Genesis... these systems will all fail someday. It's nice to think that a newly built system made today will extend that lifetime of these systems... and (dare I use this word) emulate (ugh!) very accurately, in fact, super perfectly accurately, these old consoles. The thing I like about Kevtris's work is how accurate it is. That's important to me. Nothing pisses me off more than the Retron 5 or playing emulated games on a PC and having that horrible lag and terrible audio. It almost made me depressed. But Kevtris brings hope to us all.

[aloram]

It's a FPGA-based console, which means it's designed to receive any core, whether it's 8-bit or 16-bit. So technically, Kevtris could release the Zimba now with the cores he's got implemented, and deliver the 16-bit cores later. Loading any core simply involves having that core on an SD card and following a procedure to have it loaded for the game you want to play.

 

My guess is Kev will want to have the Super-NES and Genesis cores done before he tackles proper mass-production of the Zimba, because being a FPGA console implies that it's a mostly open architecture, and he will not want someone else writing a 16-bit core for the Zimba that doesn't meet his (very high) standards. I would probably do the same if I were in his shoes, to be honest.

Thanks for your clear explanation.

 

The guy is doing fantastic work... and just generally seems likeable.

 

Definitely. I subscribe to his YouTube channel (highly recommended), and the guy just exudes integrity. Really looking forward to seeing more of his work.

[Andromeda Stardust]

 

 

Is there a "buy Kevtris a beer"page anywhere? Kevtris'projects are all impressive and I wish the best of luck, no matter what the result.

I recommend the 8-bit ale!

http://tallgrassbeer.com/8-bit-pale-ale/

 

Never tried it as it isn't available in my state, but I would love to get a six-pack er four pack. Five three to drink, one to display sealed forever!