james1095

Ms. Pac?

26 posts in this topic

Has anyone looked into the possibility of running Ms. Pacman? My recollection is that the hardware is identical, except Ms. Pac adds a few more ROMs. Memory could be an issue since I think Pacman already uses all but one available BRAM in the P1 500K, but perhaps the program ROMs could be stored in the config flash or an external EEPROM?

Share this post


Link to post
Share on other sites

http://forum.gadgetfactory.net/index.php?/topic/1273-galaxian-alieninv-lizwiz/#entry7603

its actually a bit more complicated than that as it uses pacman and aux daughterboard that replaces cpu (well cpu moved to daughterboard and has mspacman roms on it. board overlays mapac code on pac code)

but using the mspacmab mame set makes it possible with the current pac hw. see thread i pasted above.

:)

Share this post


Link to post
Share on other sites

Cool, I'll give it a go. Perhaps it can be added to the Arcade Blaster app, it seems like a natural addition. That said, I've pretty much moved on to just loading the bitfiles I've synthesized rather than using a separate app.

Share this post


Link to post
Share on other sites

it can probably be added to the ppro (arcade blaster profiles) but not the 500.

same with lizwiz.

 

jack explained it in that thread i posted.

Share this post


Link to post
Share on other sites

I could take a stab at getting the original Ms Pacman running if you guys are keen on that game.

As was said before, the Ms Pacman ROMs include the Pacman ROMs and the hardware will run the Pacman game (albeit with Ms Pacman graphics overlays due to different gfx ROMs) and will only in fact run Ms Pacman if certain conditions are met.

The additional Ms Pacman ROMs are actually scrambled and will overlay portions of the top of the Pacman ROM memory space as well as also overlay certain discontinuous low memory ROM addresses essentially forming a patch table into the original Pacman ROM causing the program execution to jump into Ms Pacman portions of the ROMs. I hope that makes sense, it's a little hard to explain.

Despite the complexity, it should be doable though.

I also just got Mr TNT running. I guess you could say Mr TNT was already running if you bothered to descramble the ROMs before inserting them in the Pacman hardware but I implemented the descrambling inside the hardware so the game runs with the original scrambled ROMs.

Share this post


Link to post
Share on other sites

cool :)

 

the thing with ms pacman is, as you said it uses the original pacman roms with the ms pacman roms overlaid.

the mame mspacmab set already has this done, and it will load, but will not fit into the papilio 500k (bram issue)

so you need to tweak here and there, then generate the bitfile for mspacmab and upload that to the fpga.

 

supposedly it doesnt play 100% like the original, but then again papilio pacman probably doesnt either.

 

i would guess that pacman+mspacman roms just wouldnt fit into the 500 and be mergeable, since the mspacmab

which is way smaller isnt mergable.

 

as for Mr TNT, I am not sure how I missed that one as it seems to be a gorkans clone (or maybe parent). 

 

do you by any chance remember the specifics on how it is scrambled? if not i will look in the mame sources whenever i am home.

 

I have a (windows only) version of romgen that is capable of descrambling the roms on the fly (based on an .ini file) so as to add more games to the base hardware.

https://github.com/FelixV/ROMGen_v3.01 if you want to take a look.

 

i used it in my GameBase setup as i am really not a big java fan..

https://github.com/FelixV/Papilio-GameBase

Share this post


Link to post
Share on other sites

Mr TNT has two data lined swapped for the program ROMs and two data and two address lines swapped for the graphics ROMs

Using the MAME convention for naming games, mspacman is a set of ROMs overlaid on puckmana ROMs, the Pacman machine hardware is implemented completely as per the schematic so with the correct ROMs the game should run 100% as the original

Share this post


Link to post
Share on other sites

@mr tnt - so its pretty much the same as pacman plus and a few others.  will look up the specific address/data lines later. thanks.

 

@ms pacman yes i get that :)

 

i was referring to the mspacmab (ms pacman bootleg) set

Share this post


Link to post
Share on other sites

It darn well *should* play 100% like the original, at least that's the goal, anything less constitutes a bug that we should aim to fix. That's the point of using an FPGA to synthesize the actual original hardware rather than just running software emulation.

 

Lack of sufficient BRAM seems to be the limiting factor on a great deal of games. IIRC Pacman on the P1 500K uses only 20% of the FPGA logic but 100% of the BRAM cells. Using BRAM to hold ROM images that are by nature static and read-only is a really inefficient use of BRAM. It would be really nice to have an external EEPROM or flash chip for storing the ROM images, but the Papilio platform suffers from a shortage of available I/O for such things. Perhaps we could come up with an arcade megawing that uses shift registers to provide ample IO for controller and dip switch inputs and gain enough IO to talk to a parallel flash ROM, saving the BRAM cells to be used as RAM. It may be possible to use a serial EEPROM or flash, but I don't know if that would be fast enough to emulate the parallel ROM used in the classic games.

Share this post


Link to post
Share on other sites
Mr TNT program ROMs have data lines D3 and D5 swapped and video ROMs have data lines D4 and D6 and address lines A0 and A2 swapped

 

I should have said earlier that I'm only focusing on Papilio Pro from now on, I consider the P1 too limited to try and spend too much time cramming resources in it, sorry.

Share this post


Link to post
Share on other sites

Yeah, the Papilio Pro should open up a lot more games. Even without using the external SDRAM, there are 64KB of BRAM compared to the 40KB BRAM of the Papilio One 500K.

 

Jack.

Share this post


Link to post
Share on other sites

 

Mr TNT program ROMs have data lines D3 and D5 swapped and video ROMs have data lines D4 and D6 and address lines A0 and A2 swapped
 
I should have said earlier that I'm only focusing on Papilio Pro from now on, I consider the P1 too limited to try and spend too much time cramming resources in it, sorry.

 

 

thanks for the infos.

 

if you want to try to fix the pac hardware, i know a few things that are wrong which i don't know how to fix... (rather i know the symptoms but not enough vhdl to fix)

 

the not plays like original comment was related to the unused rom in 3m, i think, but i forget the specifics. its been awhile since i looked into it.

there are references to the 3m rom in the vhdl, but the rom itself is never loaded by arcade blaster etc.  if the rom data is included in the vhdl already, thats a big no-no ;)

Share this post


Link to post
Share on other sites

My point was that even the P1 250K has vastly more resources than a lot of classic arcade games need. The only limiting factor is available BRAM. While it's possible to use BRAM to store ROM data, that certainly isn't the most efficient or intended use of it.

Share this post


Link to post
Share on other sites

My point was that even the P1 250K has vastly more resources than a lot of classic arcade games need. The only limiting factor is available BRAM. While it's possible to use BRAM to store ROM data, that certainly isn't the most efficient or intended use of it.

 

agreed.

 

ideally i would love to have a serial eeprom with the pins broken out to an icsp style header in addition to

being routed to the papilio, but i doubt that ever happens as it would be a very very niche product.

not to mention, would it even work properly...

Share this post


Link to post
Share on other sites

I don't think it's that far fetched. It would be simple enough to breadboard the thing and not too terribly hard to design a whole wing from scratch, that's a nice thing about open hardware. I bet you could connect a serial EEPROM to one of the joystick ports on the Arcade megawing, or tack wires onto other IO pins.

Share this post


Link to post
Share on other sites

actually i wanted to get rid of the LED's and the 4D buttons and add in a dip switch and a neo-geo style controller port (more buttons)

never designed a pcb before tho.

Share this post


Link to post
Share on other sites

ideally i would love to have a serial eeprom with the pins broken out

 

You already have a serial eeprom connected to the FPGA that is readily programmable and is plenty big, the problem with serial eeproms is very slow access times for random reads.

 

Additionally most games will require simultaneous access to the program ROM for the CPU and at the very least one graphics ROM. This means the serial eeprom needs to be accessed twice as often. For some games you need to access two graphics ROMS, one audio ROM and one CPU program ROM. The eeprom then needs to be access four times per game clock cycle. This just isn't possible.

 

With an SD card the problem becomes that you need to read a whole sector at a time (512 bytes) which means you must implements some form of caching and of course on a cache miss you must load a whole 'nother 512 bytes thereby having to stall the game then somehow make up the speed loss due to the stall and catch up to real time. This becomes too complicated again, not to mention the game no longer runs as the original having this (possibly noticeable) jerky behaviour.

 

With an external parallel flash, your chances are much better, fastest flash is I think about 35ns though most flash is rated at 70ns. Again you need to access it at least twice to 4 or maybe even 5 times per game cycle. Games typically run at 4Mhz with graphics at 6Mhz so the math isn't straight forward but say worst case four accesses in a 6Mhz cycle that is ~42ns you'd need the faster more expensive flash to even have a chance.

 

With external DRAM your problems don't go away either as although you have abundant capacity, you still need to retrieve multiple bytes from random addresses per game cycle, added complexity of a DRAM controller and you'd still have to implement some caching mechanism complicating things.

 

You best chance by far is SRAM, rated at 10ns is plenty fast and super simple to access. Your problem here is that SRAM comes in limited capacities, I think from memory your best bet with current tech maxes out at 2Mx16 so 4M bytes 1Mx16 (IS61WV102416BLL) and it won't come cheap either at $28 a pop compared with $3 for flash

 

if you want to try to fix the pac hardware, i know a few things that are wrong

 

Well if you tell us specifics then we might see what we can do  :)

 

there are references to the 3m rom in the vhdl, but the rom itself is never loaded

 

The 3M ROM is indeed implemented in VHDL in the audio module rather than loaded from external 3M ROM dump. I don't know why the original author chose to do that but as far as I've seen all the games use exactly the same 3M ROM, you can check the hashes in MAME if you want. One thing that got me was when looking at the VHDL code implementation of the 3M ROM and comparing it to the 3M ROM dump the data seemed different until I realized the author also inverted all the bits of the 3M ROMs. In any case the 3M ROM is used entirely for timing signals in the audio section so the VHDL implementation is still faithful to the schematic AFAIK.

 

@james1095 yeah I don't disagree the S3E500 is plenty grunty for 80' arcades, the problem with the P1 is not the FPGA so much as its lack of external RAM. Also due to the package used (for easy assembly) it lacks the pins required to bolt on additional RAM onto it as that will eat into the available pins for VGA and buttons. Possibly your best bet with the P1 is to have a wing with PS2 keyboard as controller (2 pins), HDMI video output (8 pins), audio (2 pins stereo) leaving you 36 pins for a RAM which might just be enough (16 data, 4 control, 16 address maybe) but still borderline unless you go for 8 bit data bus RAM...

Share this post


Link to post
Share on other sites

i will take your word on it :)

good explanation, btw.

 

as for pac hw issues, here is the main one. affects just about everything that runs on the HW

 

http://forum.gadgetfactory.net/index.php?/topic/1379-super-glob-sprglbpg

 

i chose to post super glob pics because that is what i was working on at the time, but the same

issue is present in other games, including base pacman ( i think if you go to the top right of the

screen, or maybe when you start in 2 player mode and p1 dies you can see it well )
 

Share this post


Link to post
Share on other sites

I'll have to take a closer look at the game you mentioned as I'm not too familiar with it. When you say "affects just about everything that runs on the HW" does that include puckmana ? Because I don't recall seeing anything weird with that. I wonder if it's the scan doubler causing it, as I have removed the scan doubler that MikeJ included in all the fpgaarcade games and replaced it with my own design.

Share this post


Link to post
Share on other sites

i am not aware of a `puckmana` set. then again, i have been awake for longer than i care to remember...

 

i have tried a `puckman` set tho.  will try `puckman` when i get home in about 7 hours or so again but i

am pretty sure it was there.

 

(caterpillar) `ctrpllrp` also shows the effects well.

Share this post


Link to post
Share on other sites

An easy way to test that would be to bypass the scan doubler. Mike's original code enables one of the switches to turn the scan doubler off and on. I've mostly kept it turned off since I have an old monitor that can do 15kHz and find that it looks a lot more authentic that way. I did test Pacman both with the scan doubler enabled and disabled using MikeJ's code and it made no difference but I didn't think to try disabling the scan doubler on the Papilio since I hadn't realized it was different.

Share this post


Link to post
Share on other sites

hmmm will try that.

however, if it was the scan doubler, wouldn't it affect the other games hw platforms too?

it was only pacman hw that had the bug.

Share this post


Link to post
Share on other sites

OK done, I trundled through MAME source code and added the Ms Pacman address mapping overlay and descrambling to the base Pacman hardware. This means you can supply it with the original ROMs and the overlaying and descrambling will be done in real time just like on the original hardware. I encourage you to read through this module comments at the top of the file, to get an idea of what a pain it was to implement this, with all the trap addresses, address remapping and address and data scrambling that Ms Pacman does.

 

This release is hot off the press and not a lot of testing has been done, I just quickly tested I can play Pengo, Puckman and Ms Pacman, to level 2 only. I noticed that the colors on Pengo demo screen are wrong (when he runs across the ice with the sun behind) but the colors in game are correct. I kind of know where to look to fix that so no biggie, it has to be the high address bit of the color prom, which is larger capacity for the Pengo game than for Pacman. I'll work some more on this in the near future.

 

The code is here, essentially what I ended up doing is inserting a decoding layer between the program ROMs and the rest of the hardware. This decoding layer is controlled with some generics, so it will perform descrambling and proper ROM mapping into the address space for Ms Pacman, if the MSPACMAN flag is set, descrambling for Pengo is the PENGO flag is set, descrambling for Mr TNT if the MRTNT flag is set, etc

 

All the generics are in the top level wrapper, only set one of PACMAN or PENGO as they are mutually exclusive. If PACMAN is set then, you may also set one or more of the MRTNT, LIZWIZ, MSPACMAN flags is you intend to play that particular ROM or leave them unset for all other Pacman hardware based games.

 

Because of the use of generics to control the hardware behaviour of different games, this is not friendly to the method if inserting the ROMs into the FPGA image with romgen, so you'll have to compile different FPGA images with the ROMs built in for each game you want to play.

Share this post


Link to post
Share on other sites

good job :)

 

sadly, i havent even had time to do the other stuff we talked about ... =/

 

but i will make sure to add this to my to try list asap.

Share this post


Link to post
Share on other sites

On the romgen topic, I was trying to elliminate some of the many compile warnings in Xilinx XST and one of the more annoying was the "<ram> remains a black box" which was being generated for every instance of each RAMB that was generated by romgen.

 

I went and changed romgen to no longer generate the seemingly complicated VHDL where the RAMB inits were generated as strings then parsed via a function into bit vectors. Now romgen simply generates the init data for the RAMB as generics passed directly to the component. This has elliminated the warnings and also generates more compact VHDL code which is easier on the eye, on average each source file is now half the size.

 

I have tested that it synthesizes for S3 and S6 targets as well as keeping the simulator happy. The code is here. This only affects the block ram capability of romgen, the other stuff remains unchanged. If you guys want to take it for a test run, please do.

 

This version also includes the changes to generate Xilinx mem files too as added by... can't remember who did it, sorry... searched the forum and couldn't find it.

 

To compile, just run "g++ -static -o romgen romgen.cpp; strip romgen.exe" or use the precompiled Windows exe at the link above.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now