Topic: Pac-Man Hardware (multiple games)

The Pac-Man hardware is reimplemented for FPGA's.

Main project page:
http://arcade.gadgetfactory.net/index.p … PacManHelp
Sourcecode:
https://github.com/GadgetFactory/Papili … 3e_papilio

Crush roller:
http://arcade.gadgetfactory.net/index.p … RollerHelp
Source:
https://github.com/GadgetFactory/Papili … 3e_papilio

Gorkan's Help / Mr TNT(?)
http://arcade.gadgetfactory.net/index.p … orkansHelp
Source:
https://github.com/GadgetFactory/Papili … 3e_papilio

Lizard Wizard:
http://arcade.gadgetfactory.net/index.p … WizardHelp
Source:
https://github.com/GadgetFactory/Papili … 3e_papilio

Re: Pac-Man Hardware (multiple games)

I found another one for the Pac-Man HW, Pengo!
https://code.google.com/p/pengo-papilioplus-fpga/

Re: Pac-Man Hardware (multiple games)

Ha ha, those are all based on my code.
I'm porting it now to the super cool and froody framework.

The Really nice thing is you can upload different ROMs just by changing the INI file wink

Re: Pac-Man Hardware (multiple games)

I've got the project up and running. Basic video working now.

As I'm using this as a test of the libraries, I'm having to do a few tweaks on the way, so it's taking a little longer that it would
normally.

Should be done tomorrow.
/MikeJ

Re: Pac-Man Hardware (multiple games)

Woohoo!  Nice job, Mike!

Re: Pac-Man Hardware (multiple games)

Really happy with the way the whole system is hanging together.
All 8 ROMs in the game are instantiated from the lib, daisy chained together and then in the ini file a line this this :
ROM = pacrom_6e.bin, 0, 0x80000000

They are all read back to verify the load as well during boot:

DBG:  FCh:update status Ch:1 F0
DBG:  FCh:SetDriver Ch:1 Type:00
DBG:  Looking for \replay.ini (post-init)
DBG:  \pacrom_6e.bin @0x80000000 (0x0),S:4096
DBG:  Upload done in 3 ms.
DBG:  Verify done in 5 ms.
DBG:  \pacrom_6f.bin @0x80001000 (0x0),S:4096
DBG:  Upload done in 4 ms.
DBG:  Verify done in 6 ms.
DBG:  \pacrom_6h.bin @0x80002000 (0x0),S:4096
DBG:  Upload done in 4 ms.
DBG:  Verify done in 6 ms.
DBG:  \pacrom_6j.bin @0x80003000 (0x0),S:4096
DBG:  Upload done in 4 ms.
DBG:  Verify done in 6 ms.
DBG:  \pacrom_5e.bin @0x80004000 (0x0),S:4096
DBG:  Upload done in 4 ms.
DBG:  Verify done in 6 ms.
DBG:  \pacrom_5f.bin @0x80005000 (0x0),S:4096
DBG:  Upload done in 4 ms.
DBG:  Verify done in 6 ms.
DBG:  \pacrom_4a.bin @0x80006000 (0x0),S:256
DBG:  Upload done in 0 ms.
DBG:  Verify done in 1 ms.
DBG:  \pacrom_7f.bin @0x80007000 (0x0),S:32
DBG:  Upload done in 1 ms.
DBG:  Verify done in 0 ms.
DBG:  Final free MEM:   40303 bytes
DBG:  Menu requires 1568 bytes
DBG:  POST-INI processing done, core started
DBG:  --------------------------
DBG:  POSTINIT (39919 bytes free)

This has of course been done in other cores before, but this is all using "off the shelf" blocks.
/MikeJ

Re: Pac-Man Hardware (multiple games)

And it runs!
Interesting issue. Some of the ROM images are longer than the actual memory. If I don't restrict the address map, it aliases during write and the blank last half of the ROM splats the data.
If I do restrict the address range of the memory, it doesn't respond to the latter part of the image and times out.
This is a probably the right answer, so I modified the ini file to force a max size on the problematic files.

I can now create different INI files for other games which run on the same hardware, Pacplus, Crush Roller, Eyes etc and use the same FPGA binary.

I've checked in the SD card files.

No audio, input and the screen in double scan mode is not quite right - not bad for a first effort though.
/MikeJ

Re: Pac-Man Hardware (multiple games)

Added audio and started work on inputs.
Audio isn't quite right, some odd stuff happening... I need to simulate it.
/MikeJ

update:
Fixed one part of the problem, forgot the audio was 2s comp into the DAC.
You can convert from unsigned to 2s comp in this case by flipping the top bit.
0xFF becomes 0x7F (+127)
0x80 becomes 0x00 (0)
0x7F becomes 0xFF (-1)
0x00 becomes 0x80 (-128)

I missing some voices - and I have some voices appearing on left or right channel which is odd as I'm outputting the 8 bit audio to both left and right. The state machine is aliasing against the shifter which outputs the data to the DAC.

9 (edited by WoS 2015-02-09 22:37:33)

Re: Pac-Man Hardware (multiple games)

You can check out all my Arcade games for the audio stuff, I usually use some simple IIR lowpass filters between the clock/sample domains. Straight forward and really simple to set up. Real audio on these boards was usually also not DC free, so using unsigned and half the DAC range is just fine (I limit even to 1/4, this is already quite loud). The DAC will nevertheless remove the DC offset... Compared the outputs with a DSO, looked just fine.

Here for example in Core_Top.vhd of Galaga:

  ----------------------------------------------------------
  -- AUDIO
  ----------------------------------------------------------
  -- we need to filter first to avoid aliasing when resampling,
  -- for that purpose we use a simple 1.O. IIR structure
  lp_proc : process (i_ClK_Sys, i_Ena_Sys, sample_s, sound_s, resn_s, aud_z1_s) is
  variable auda_v : unsigned (11 downto 0);
  variable auds_v : unsigned (11 downto 0);
  begin
    auda_v := "0000" & unsigned(sound_s);
    auda_v := auda_v + aud_z1_s;
    auds_v := "0000" & aud_z1_s(11 downto 4);
    auda_v := auda_v - auds_v;

    if resn_s='0' then
      aud_z1_s <= (others => '0');
    elsif rising_edge(i_ClK_Sys) and i_Ena_Sys='1' and sample_s='1' then -- based on DAC sampling
      aud_z1_s <= auda_v;
    end if;
  end process lp_proc;
  -- we have some simple gain setup as well before passing to replay
  sample_s <= "0" & word(aud_z1_s) & "00000000000" when i_Audio_lvl="11" else
            "00" & word(aud_z1_s) & "0000000000" when i_Audio_lvl="10" else
            "000" & word(aud_z1_s) & "000000000" when i_Audio_lvl="01" else
            "0000" & word(aud_z1_s) & "00000000";
  o_Audio_l <= sample_s;
  o_Audio_R <= sample_s;
/WoS

Re: Pac-Man Hardware (multiple games)

Thanks Wolfgang, I should wrap something like that into the library wrapper.
In this case I'm a bit perplexed though - the clock domains are locked, so the DAC is running on clk_sys.

I suspect they are relying on the channel mixing happening simply on the output filter capacitance.

It worked before as I had a PWM DAC.
Running a sim...
/Mike

11 (edited by WoS 2015-02-09 22:56:07)

Re: Pac-Man Hardware (multiple games)

Yes, that is definitely true. All this games have some low pass filter, either directly or included in the output amp somehow.

Eg. Phoenix is heavily using this together with some logic to generate sound, so I made a synthesize-able RC-lowpass model. It is parameterized directly with R/C values (so very convinient, just take the values from the game schematics) and can be build without multiplier used (with reduced accuracy, of course - thus the generic to select this is called "accuracy" big_smile ). It even has a "restart" function (this is used to emulate the capacitor charging to some voltage used in NE555 and similar circuits).

...\cores\phoenix\source\game\analog\rc_bypass.vhd


There I also have a generic IIR module as well there:

...\cores\phoenix\source\game\iir_1o.vhd

Maybe it helps...

/WoS

Re: Pac-Man Hardware (multiple games)

Yup, simulation shows this is what's happening. These designs are a masterpiece in minimal use of components to be sure.

I'll plug it in and see what happens, thanks.
/Mike

Re: Pac-Man Hardware (multiple games)

Oh, I just noticed you created a loadable ROM module much like I just did!
That rc_bypass module, is, well, quite scary wink

14 (edited by WoS 2015-02-09 23:17:26)

Re: Pac-Man Hardware (multiple games)

Ha, ha - yes, setting up the rc_bypass model was really, really fun, to show that something with "real" numbers can be synthesized using VHDL - especially when showing this to students. It is a classic RC filter with butterworth characteristics. But I have to say it took me a while to dig out the basics of this bilinear (s- to z-domain) transformations from the university again, today I usually have some tools doing this work for me, I enter the filter spec and just take the calculated coefficients... big_smile

I put the ROM modules in the lib quite some time ago - I use (or used) it for all cores at the beginning before I started using the DRAM with the C64 core (which already has a "native" upload/download channel). But these modules I set up can't do a verification readback. I thought if it comes that far that this verification would fail, I'd say there are some severe issues with the board which will be seen even without this step (I'd expect it will not even boot up the loader correctly)...

/WoS

Re: Pac-Man Hardware (multiple games)

The cap I can figure out, but would you like to guess a suitable resistor value for the filter?
Bits 5-8 of the 273 go through a four bit DAC, and then into analogue switches controlled by bits 1-4 into a second volume DAC.

One way would be to calculate the max/min case and pick a value in the middle.
Typ ron for the 4066 is around 470R at 5V supply.

All on is ~270R for the first DAC, ron ~110 and ~5.7K for the second DAC.
Total about 6K from the driver, 22K to gnd gives perhaps ~4.7K source R into the cap.
Highest would be 22KR.

So, something like 10KR would be reasonable with 0.01uF cap ??

/Mike

Post's attachments

pacsound.gif
pacsound.gif 16.16 kb, 1 downloads since 2015-02-09 

You don't have the permssions to download the attachments of this post.

Re: Pac-Man Hardware (multiple games)

Oh, you put them in lib/generic. Didn't spot them there.
I've added

RAM_D2048_W8
RAM_D4096_W8
ROM_D16_W8

etc into replay_lib as they go directly onto the FileIO bus.
If you look at the pacman code you see an example. They are cascadable and readable.
/Mike

17 (edited by WoS 2015-02-09 23:44:08)

Re: Pac-Man Hardware (multiple games)

The DAC looks quite similar to Galaga...?

I think Galaga just had additional sound channels from a 54xx custom IC.

1/(2*pi*10k*0,01u) gives ~1.5kHz corner frequency, sounds good I'd say...

You can use tools like this: http://www-users.cs.york.ac.uk/~fisher/ … /trad.html
enter the DAC sample rate and the corner frequency to calculate a 1.O. IIC butterworth filter and see some simulations.

Should give similar values as my rc_bypass model.

/WoS

Re: Pac-Man Hardware (multiple games)

Yes - I've just been reading through your code. Looks pretty similar to my Pacman audio. I've decoded the control ROM differently, and there are some difference in the adder.

I need to compare the schematics and then we can cross check the code.

Either way, I'll steal your strobe (sample) output and LPF as you have already solved this problem wink
Cheers,
Mike

Re: Pac-Man Hardware (multiple games)

Hardware looks identical. I think my code is ok, I did :

  p_adder : process(vol_ram_dout, frq_ram_dout, accum_reg)
  begin
    -- 1K 4 bit adder
    sum <= ('0' & vol_ram_dout & '1') + ('0' & frq_ram_dout & accum_reg(5));
  end process;

Looks like I was saving an adder. The '1' on the left side when added to accum_reg(5) works as if accum_reg(5) was on the carry in.
Your code does the same.

Re: Pac-Man Hardware (multiple games)

Wolfgang, would you have a quick look at Pacman_Audio.vhd I checked in.
I'm using your rc_bypass module, seems to work fine, sounds nicely muffled now.
The output is signed, so I can connect to top bit of the DAC I guess?
Cheers,
Mike

Re: Pac-Man Hardware (multiple games)

I've checked a binary in if you want to play the WIP.
Joystick not wired up yet, but you can use a keyboard in either port.
Keypad enter = credit
Keypad 1/2    = start 1/2
cursor keys to move.

Audio seems ok. Scan double can be switched on/off in ini file or OSD.
Next step is to add the video converter module to get DVI out, so use analog for now.
/Mike

Re: Pac-Man Hardware (multiple games)

Checked in with dip switches/config and joysticks wired up.
Slight tidy up to do still with the source, but it's complete functionally now.

I can't find the remote control to align the picture...

Post's attachments

20150214_003834_resized_1.jpg
20150214_003834_resized_1.jpg 37.32 kb, 2 downloads since 2015-02-13 

You don't have the permssions to download the attachments of this post.

23

Re: Pac-Man Hardware (multiple games)

MikeJ wrote:

Wolfgang, would you have a quick look at Pacman_Audio.vhd I checked in.
I'm using your rc_bypass module, seems to work fine, sounds nicely muffled now.
The output is signed, so I can connect to top bit of the DAC I guess?

Sorry, still AFK in Italy, will have a look to it tomorrow...

I had a look at the original schematics and got out the RC lowpass  may have for R about half the resistance ~5kOhms, which is about 3 kHz corner freq...


But with the analogue crap used these days (very cheap stuff with massive tolerances) as I found on my original Pacman PCB it might not make this big difference...

/WoS

Re: Pac-Man Hardware (multiple games)

I now see your attitude... "with the analog crap used these / those days".

Selvgjort er velgjort! wink

25

Re: Pac-Man Hardware (multiple games)

I am a realist, if you would actually know how such a board look like and compare just two of the "same" ones you would see it the same way. They mostly do not even use a separate supply and all digital switching "dirt" from the vdd of the TTL output is passed to the audio output, as they are radiometric to the supply, just look at the schematic. They had to reduce costs and not make audiophile sound for such games. By the way - some of this games are more or less using digital multibit delta(-sigma) converter structures (or other forms of noise shaping together with sound synthesis) followed by a DAC and a simple 1./2. O. butterworth interpolation on the output. This concepts are also pretty old and one could think it is just a simple r2r/binary flash DAC and could ignore "what happens before"... These setups can be quite perfectly replicated, except their tolerances from PCB to PCB...

/WoS