Videopac / Odyssey2 forum
December 11, 2019, 11:36:46 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Join Rafael's Haunted Woods contest and win a copy of the game!
 
   Home   arcade Help Login Register links videopac.nl  
Pages: [1]   Go Down
  Print  
Author Topic: VP.org: Advanced game graphics , part 2  (Read 2333 times)
Rene_G7400
Moderator
I take the Videopac and leave the Canoli!
*****
Posts: 2519



WWW
« on: September 17, 2007, 06:16:58 PM »


fernandotcl

Joined: 09 Nov 2006
Posts: 29

   Rene_G7400 wrote:
   
   Kurt_Woloch wrote:
   
As for Turtles, which has been mentioned - I don't think that one does any mid-screen changes.

Correct.

Hmmm, no, Turtles does have mid-screen changes. When you first start the game (and I think it happens also every time you beat a level) the grid is drawn 1 line per N frames. That's accomplished by turning the grid off during VBLANK, and turning it back on when the timer goes off, and gradually increasing the timer.

Wed Dec 27, 2006 10:36 pm    


Rene_G7400

Joined: 06 Mar 2006
Posts: 651
Location: Netherlands

   fernandotcl wrote:
   
Hmmm, no, Turtles does have mid-screen changes. When you first start the game (and I think it happens also every time you beat a level) the grid is drawn 1 line per N frames. That's accomplished by turning the grid off during VBLANK, and turning it back on when the timer goes off, and gradually increasing the timer.


That is true, but I didn't really count that as mid-screen changes. There is no re-use of characters or sprites. Then you would also have to take every game which has more than 1 background color into account (like Smithereens).

Wed Dec 27, 2006 11:35 pm       


fernandotcl

Joined: 09 Nov 2006
Posts: 29
 
   Rene_G7400 wrote:
   
   fernandotcl wrote:
   
Hmmm, no, Turtles does have mid-screen changes. When you first start the game (and I think it happens also every time you beat a level) the grid is drawn 1 line per N frames. That's accomplished by turning the grid off during VBLANK, and turning it back on when the timer goes off, and gradually increasing the timer.

That is true, but I didn't really count that as mid-screen changes. There is no re-use of characters or sprites. Then you would also have to take every game which has more than 1 background color into account (like Smithereens).

Well, yeah. But those are mid-screen changes, they change a VDC register after VBLANK... Bah, whatever.

Wed Jan 03, 2007 9:12 pm    


al

Joined: 01 Oct 2006
Posts: 17
Location: Munich, Germany

I get the following title screen of Killer Bees in NTSC mode. It's a bit different from o2em's although it seems to be cleaner.
Does this match the real NTSC Odyssey2?
- vertical adjustment of the white bar wrt to the characters
- no white rectangle around the lower tip of the triangle
- small flashing bars not aligned with top of triangle

Thu Jan 11, 2007 11:58 pm    


Rene_G7400

Joined: 06 Mar 2006
Posts: 651
Location: Netherlands

Your picture looks better than on O2em, on a real NTSC console it looks like this:



Fri Jan 12, 2007 7:34 pm       


al

Joined: 01 Oct 2006
Posts: 17
Location: Munich, Germany

Ah thanks, no bars. Looks like another debug session Confused

Fri Jan 12, 2007 10:56 pm    


Marcelo Ribeiro

Joined: 30 Mar 2006
Posts: 56
Location: Rio de Janeiro - Brazil

I would love to see this intro screen from Killer Bees perfectly emulated by O2EM...

_________________
Marcelo Ribeiro
http://odysseymania.classicgaming.com.br/

Mon Jan 15, 2007 3:21 am         


Rene_G7400

Joined: 06 Mar 2006
Posts: 651
Location: Netherlands

   Marcelo Ribeiro wrote:
   I would love to see this intro screen from Killer Bees perfectly emulated by O2EM...


Philips didn't even take the effort to correct it for PAL consoles.....

Mon Jan 15, 2007 8:13 am       


al

Joined: 01 Oct 2006
Posts: 17
Location: Munich, Germany

   Marcelo Ribeiro wrote:
   I would love to see this intro screen from Killer Bees perfectly emulated by O2EM...


In my opinion, Killer Bees (and other games) suffer from slight timing inaccuracies of o2em. Can't tell exactly what they are, but they seem to manifest in different ways.
E.g. o2em's changing the background color in frogger from black asphalt to yellow happens too late. Score and time counters shouldn't reach onto the highway for PAL, I guess. Whereas the NTSC Frogger shows a slightly too high yellow bottom.
Backgammon also seems to be sensitive to exact video timing. Here I suspect a problem with VBLANK duration. At least fixing this parameter on my FPGA design made the display stable. Yet I have no idea how to start a session.

BTW the KB title screen on NTSC is now clean. This one pointed me to a bug in the grid generator.

Mon Jan 15, 2007 7:41 pm    


Rene_G7400

Joined: 06 Mar 2006
Posts: 651
Location: Netherlands

   al wrote:
   
In my opinion, Killer Bees (and other games) suffer from slight timing inaccuracies of o2em. Can't tell exactly what they are, but they seem to manifest in different ways.
E.g. o2em's changing the background color in frogger from black asphalt to yellow happens too late. Score and time counters shouldn't reach onto the highway for PAL, I guess. Whereas the NTSC Frogger shows a slightly too high yellow bottom.
Backgammon also seems to be sensitive to exact video timing. Here I suspect a problem with VBLANK duration.


(I think I've said this before somewhere.) I think in Euro mode the difference in CPU speed as compared to NTSC consoles hasn't been taken into account in O2em.

Mon Jan 15, 2007 11:37 pm       


al

Joined: 01 Oct 2006
Posts: 17
Location: Munich, Germany

   Rene_G7400 wrote:
   
I think in Euro mode the difference in CPU speed as compared to NTSC consoles hasn't been taken into account in O2em.


Fully agreed. The "instructions per line" seems to be somewhat fixed to 22 (or 21) which is close to but not exactly at the real value of 22.8 for NTSC. Had a look at the code last night and fooled around with the timing in there, but only to find that this ratio is scattered over several files so the instances to update are not easily identified Crying or Very sad
Guess I will at least contact manopac and tell him about my findings.

Tue Jan 16, 2007 10:03 pm    


fernandotcl

Joined: 09 Nov 2006
Posts: 29

That sounds awesome, al. I'm curious about some details, if you don't mind answering:

- How is the final product planned to be, will you guys sell hardware or simply distribute the FPGA code (or both)?
- How accurate will this emulation be when the project is complete? I mean, I assume you're not emulating e.g. VDC at the same layer as computer emulators do, i.e., it doesn't use a framebuffer, but instead writes video signals directly, no?
- What exactly are you emulating, just a few parts of the console (that then are glued to some more circuitry that loads the games (from flash maybe), processes input, etc.) or the whole thing (meaning you can hook up real controllers, real cartridge connectors, etc.)?

Sorry if those questions are a bit newbish, but I really never knew anything like that (except maybe NES On A Chip) existed before I saw this thread. It's definately exciting.

Fri Feb 02, 2007 8:17 pm


al

Joined: 01 Oct 2006
Posts: 17
Location: Munich, Germany

   fernandotcl wrote:
   How is the final product planned to be, will you guys sell hardware or simply distribute the FPGA code (or both)?

Initially, there will be nothing like a product, just the plain FPGA source code targeted for one or two boards I usally work with. That'll be full open source so everybody can port it to other boards / FPGAs.

   fernandotcl wrote:
   How accurate will this emulation be when the project is complete? I mean, I assume you're not emulating e.g. VDC at the same layer as computer emulators do, i.e., it doesn't use a framebuffer, but instead writes video signals directly, no?


Target is to have an implementation of the Magnavox Odyssey 2/VP hardware that is 100% functionally and timingwise equivalent to the original hardware. For some parts like the VDC that's probably not always possible since the documentation of this chip is quite brief and undocumented design features are not always apparant from a spec.
So the basic flow is to read and understand (truly) the documentation and build a circuit design with VHDL on Register Transfer Level (RTL) that behaves exactly like the original VDC; same pins, same timing. Theoretically, one could take this design (without the rest of Magnavox Odyssey 2) and build a VDC replacement chip using an FPGA. Although certain electrical issues like voltage levels and output buffering must be resolved in this case. Nevertheless, the VDC design outpus RGB and sync signals with the same timing as the original 8244 does.

Concerning accuracy, the documented functionality is easy to build. It's more tricky to mimic all the odds and ends of undocumented features and characteristics of such a chip. E.g. the fact that the display has to be blanked before changing VDC registers during the active display area must be derived from some restrictions of the i8244 electrical design. At the moment I have no idea which those are and my design doesn't exhibit the same restriction.
Such restrictions and undoc'ed features often exist because the original designs were optimized in terms of transistor count and chip area, based on the design techniques used back then. That's hard to figure out why the chip ended up with a certain quirk just because the designers saved a couple of transistors for the related logic.

   fernandotcl wrote:
   What exactly are you emulating, just a few parts of the console (that then are glued to some more circuitry that loads the games (from flash maybe), processes input, etc.) or the whole thing (meaning you can hook up real controllers, real cartridge connectors, etc.)?


The device under emulation is the logical view of the Videopac console. I.e. CPU, VDC, RAM, keyboard/joystick interface logic and address decoders are built in the way described above. External interfaces are cartridge port, RGB video, audio output and keyb/joy connections. The way how these are hooked up to the external devices is part of porting the design to a dedicated FPGA board.
The cartridge interface for instance could be directly connected to a real connector (considering electrical levels etc.). Or it's wired to an on-board flash or RAM.
Likewise the video interface might be connected to an RGB monitor or with additional conversion to a VGA display. One could also derive PAL/NTSC signals using an external chip. Audio is similar, either through a simple DAC to active speakers or more sophisticated ways. It all depends on the FPGA board.

Just have a look at http://www.fpgaarcade.com/ to get an idea about all this. There are a couple of arcade and console games already converted to FPGA. The Magnavox Odyssey 2/VP release will be very similar.

Sat Feb 03, 2007 11:35 am    


al

Joined: 01 Oct 2006
Posts: 17
Location: Munich, Germany

It's finally online at www.fpgaarcade.com.
CPU, VDC and sound are fully implemented. Plus a special goodie: on-chip multicart interface with menu software.

Have fun!

Tue Jun 12, 2007 9:59 pm    


grgh

Joined: 31 May 2006
Posts: 729
Location: High Wycombe, UK

Has anybody checked this out yet?
http://home.freeuk.net/fpgaarcade/videopac.htm

Thu Jul 12, 2007 5:32 pm
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!