Galaxian and new Arcade Blaster 1.2 app


xbelanch

Recommended Posts

Not sure if it's my fault or a bug. I downloaded today the new version of Arcade Blaster to see Galaxian running on papilio arcade. I have two problems:

  1. When I'm trying to install the rom, Arcade Blaster recognizes Mr. Do's Nightmare (they share the same romset files as it shows at Games.xml).
  2. Changing the order of game romsets at Games.xml (Galaxian before Mr. Do's Nightmare) I've installed Galaxian but it doesn't work well as you can see on the next pictures. Some parts of the sprites (ships, flags,...) has disappeared

P1010570.JPG

P1010571.JPG

Thanks!

Link to comment
Share on other sites

here you go. i committed the fix to these to my branch of Arcade Blaster on GitHub this morning.

just replace yours with these two


<game name="Galaxian" id="galaxian">
<hardware>galaxian</hardware>
<category>shooter</category>
<publisher>Nameco</publisher>
<year>1979</year>
<description>Galaxian (Namco Set 1)</description>

<fileset primary="true">
<group name="maincpu" size="2000">
<rom file="galmidw.u" offset="0" size="800" crc="745e2d61" sha1="e65f74e35b1bfaccd407e168ea55678ae9b68edf" />
<rom file="galmidw.v" offset="800" size="200" crc="9c999a40" sha1="02fdcd95d8511e64c0d2b007b874112d53e41045" />
<rom file="galmidw.w" offset="1000" size="800" crc="b5894925" sha1="0046b9ed697a34d088de1aead8bd7cbe526a2396" />
<rom file="galmidw.y" offset="1800" size="200" crc="6b3ca10b" sha1="18d8714e5ef52f63ba8888ecc5a25b17b3bf17d1" />
<rom file="7l" offset="2000" size="200" crc="1b933207" sha1="8b44b0f74420871454e27894d0f004859f9e59a9" />
</group>
<group name="1h" size="1000">
<rom file="1h.bin" offset="0" size="1000" crc="39fb43a4" sha1="4755609bd974976f04855d51e08ec0d62ab4bc07" />
</group>
<group name="1k" size="1000">
<rom file="1k.bin" offset="0" size="1000" crc="7e3f56a2" sha1="a9795d8b7388f404f3b0e2c6ce15d713a4c5bafa" />
</group>
<group name="proms" size="1000">
<rom file="6l.bpr" offset="0" size="1000" crc="c3ac9467" sha1="f382ad5a34d282056c78a5ec00c30ec43772bae2" />
</group>
</fileset>
<!-- Uses groups as input and creates intermediate mem files by name specified in file atribute-->
<generate src="maincpu" file="ROM_PGM_0" parameters="entity=rom_code;addrbits=14" />
<generate src="1h" file="GALAXIAN_1H" parameters="entity=rom_1h;addrbits=11" />
<generate src="1k" file="GALAXIAN_1K" parameters="entity=rom_1k;addrbits=11" />
<generate src="proms" file="GALAXIAN_6L" parameters="entity=galaxian_6l;addrbits=5" />
<!-- Uses output of (file attribute) from generate tag. Sequence is important! -->
<assembly name="galaxian_merged">
<piece file="ROM_PGM_0" tag="rom_code" />
<piece file="GALAXIAN_1H" tag="rom_1h" />
<piece file="GALAXIAN_1K" tag="rom_1k" />
<piece file="GALAXIAN_6L" tag="galaxian_6l" />
</assembly>
</game>



<game name="Mr. Do's Nightmare" id="mrdonightmare">
<hardware>mrdonightmare</hardware>
<category>shooter</category>
<publisher>Nameco</publisher>
<year>1979</year>
<description>Mr Do's Nightmare</description>
<fileset primary="true">
<group name="maincpu" size="2000">
<rom file="galmidw.u" offset="0" size="800" crc="197493a6" sha1="f939fd712985db24dced4f7a66f4a804ca34ce60" />
<rom file="galmidw.v" offset="800" size="200" crc="b8ee84cf" sha1="c5018f21da2f65fa573a2d5e9c8f96db1f0136e9" />
<rom file="galmidw.w" offset="1000" size="800" crc="76879d31" sha1="7aae5ee1eeaa5dacf4a232b3336f9e3df74018ca" />
<rom file="galmidw.y" offset="1800" size="200" crc="d6d5e47e" sha1="e5f41f90ca357f3e7ef1a6b055ca0cccc91ed391" />
<rom file="7l" offset="2000" size="200" crc="34913886" sha1="c1936ef6dc6080d080715d1c064513d581180fea" />
</group>
<group name="1h" size="1000">
<rom file="1h.bin" offset="0" size="1000" crc="f880af4b" sha1="67d24ac48a6bd68de5b914675dc4cd5982d8ffc4" />
</group>
<group name="1k" size="1000">
<rom file="1k.bin" offset="0" size="1000" crc="40fd608a" sha1="3a58d5ac17e98bea3d58d238d81bd6a5dd24bb81" />
</group>
<group name="proms" size="1000">
<rom file="6l.bpr" offset="0" size="1000" crc="77f95861" sha1="2acb3021e31b3c91bbf48763d2504dfad0d87f38" />
</group>
</fileset>

<!-- Uses groups as input and creates intermediate mem files by name specified in file atribute-->
<generate src="proms" file="GALAXIAN_6L" parameters="entity=galaxian_6l;addrbits=5" />


<!-- Uses output of (file attribute) from generate tag. Sequence is important! -->
<assembly name="mrdo_merged">
<piece file="GALAXIAN_6L" tag="galaxian_6l" />
</assembly>
</game>

Link to comment
Share on other sites

Actually it seems that the whole right audio channel is missing,

the your ship going boom sound

and the background "humming" that is supposed to be there

I doubt it is something that can be fixed in the Arcade Blaster XML.

I think it may be something in the actual simulated hardware, but

can't be sure since I still know next to nothing about HDL

Edit: Mr Do's Nightmare also has Right side audio missing

Link to comment
Share on other sites

  • 7 months later...

Anyone tried to play Galaxian recently? When I gave it a try I was getting double vision, sort of. I had two skinny copies of the video side by side. This didn't happen with the original verilog code, only the vhdl. I dug into it and noticed an error in the mc_video.vhd and I'm not sure if this was introduced when I translated the game from verilog to vhdl as I don't have that original source code any more, this is the code from gadgetfactoy github so this section

--   Parts  4,5NW_45N_Q <= (W_VF_CNT + W_H_POSI) & '0';

should really be 

--   Parts  4,5NW_45N_Q <= W_VF_CNT + W_H_POSI;

Otherwise the VF counter is essentially multiplied by two (shifted left one bit).

 
 

 

Link to comment
Share on other sites

not sure where that came from.

 

on my github branch it shows mc_video.vhd lines 291/292 to be

-- Parts 4,5N
W_45N_Q <= (W_VF_CNT + W_H_POSI) ;
 
 
[Edit:
github shows that as part of a commit that i never did to my tree.
adding support to it for the PPRO (Shows Jack did it but not sure if it was his code or not.)
]
Link to comment
Share on other sites

Since I started digging though the Galaxian code yesterday, I couldn't just stop there so I ended up doing the following:

 

The video on my monitor seemed to ride a little too high (in portrait mode) so I'd have to fiddle with the adjustments to center the picture. I got sick of doing that and replaced the scan doubler originally written by MikeJ or fpgaarcade with my own that I developed for my BombJack implementation. My scan doubler does a few things differently and more closely implements the VGA timing for the sync signals therefore the picture just ends up centered on the monitor without having to fiddle with buttons, in fact just reseting the monitor settings to factory defaults still ends up with a centered picture due to the scan doubler observing the correct front/back porch and sync signal polarity and duration. It also requires and generates composite blanking signals, see why below.

 

In the process I also simplified the clock section and had it generate one additional 24Mhz clock which I required for my scan doubler, but more importantly that clock is required if you want to bolt on an HDMI output on the end of the scan doubler. The reason 24Mhz is required is because it is very close to the VGA standard 25.175MHz but also is an integer multiple of the 6Mhz that the game video runs at. To run an HDMI output you simply feed the scan doubler output into the DVID module that Mike Fields created. That module requires composite blanking signals as well as 24Mhz and 24*5 Mhz clocks to generate an as close as possible to VGA signal. This was tested successfully and it works.

 

I didn't like how the top module of the project that was geared towards a Papilio board just contained all the game sub-modules. I think it is more proper to separate the game logic from the board implementation. As such the game module itself should be self contained, it should take as inputs some clocks and player controls and it should have as outputs the original video (not scan doubled) and sound. This game module can then be imported into a top level board specific module that then connects other stuff to the game module to make it work in a particular environment. Such add ons can be the scan doubler, a PS2 keyboard controller that is then converted to button presses and fed to the game module, the DACs, etc. So I went ahead and separated the game logic itself from the board specific bits and pieces.

 

While trying to eliminate some warnings, I also ended up switching some negative logic signals to positive logic simplifying some code across several modules.

 

Finally, some good stuff, the sound! I saw some complaints that the Galaxian was missing the right channel, sound effects. These include the ship explosion sound, the shooting sound and the background sound. Initially I looked at how the original author tried to implement this. He basically had three sampled sounds, one for each of the above sounds listed above and would just play the relevant sample as appropriate. These samples had been missing in the source and I couldn't find them on teh nets. I fired up MAME and recorded the background sound and the ship shooting sound but could not get a clean ship explosion as there are always other sound effects going on when the ship explodes. So I cheated and added a generic explosion sound effect. I down-sampled all of them to 11025Hz and added them to the game. Upon playing a test game I noticed that while the shooting and explosion sounds were OK, the background droning sound was just the static sample repeated over and over. The original Galaxian game actually plays that sound faster and faster as the game progresses adding a sense of urgency to the game play. I realized that just having this static sample would not do.

 

I pulled out the schematic of Galaxian and had a look. The original hardware implements this sound with old fashioned 555 timer chips (no fancy sound generators here). Basically the CPU writes a 4 bit value to a 4 bit DAC implemented by latch 9M in the schematic. This is converted to an analog voltage by an 2-2R ladder and then feeds into a current mirror (transistors Q1 and Q2). This current mirror controls the first 555 timer labeled 9R. It causes it to generate a sweeping analog voltage, the sweep rate (how fast it sweeps) is controlled by the 4 bit A/D value from about once per second to ... um, really fast.

 

This sweep voltage is fed to three other 555 chips, 8R, 8S, and 8T. Each of these is configured as an astable multivibrator and each is tuned to a different base frequency but the sweep voltage causes each of them to detune making each of them sweep across a range of frequencies. Essentially they are voltage controlled oscillators (VCOs). The outputs of these three VCOs are a set of square waves that combine together via resistors R24, R27 and R30 and are further filtered by C20, therefore this is a low pass RC filter causing the sharp sound of the square waves to be smoothed into the familiar droning Galaxian background sound. Each of the three VCOs is further controlled by lines FS1, FS2 and FS3 so each of them can be selectively enabled or disabled from producing sound. These lines were not connected in the original game source as they didn't have anything to control since the original author just played a static sample for the background.

 

So what I did was implement a VCO module, that currently just generates a sine wave of a certain frequency based on an input value. I didn't want to bother with generating square waves and then passing them through digital filters, while that would have been a more faithful representation it adds complexity. So the VCO module it replicated three times and they are all controlled by a modulator that uses lookup tables to feed the VCOs their frequency based on the 4 bit A/D value generated by the game CPU.

 

In practice, the game is much more realistic now with the background sound that changes cadence as the game progresses and becomes faster and faster just as the original Galaxian. The other sounds, the shooting and explosion are still just samples even though the original game implements them with discrete hardware. The explosion sound is a one bit digital noise that is passed through a low pass filter to create a the explosion noise. The fading volume of the explosion (starts loud and fades to quiet) is implemented via an analogue switch and a capacitor that discharges as the sound it played controlling the volume. The shooting sound is also a combination of a 555 timer chip 7S producing a base frequency which is modulated by the one bit digital noise after passing through an RC filter. The fading volume is also implemented by another analogue switch and capacitor. Implementing these two types of sounds in hardware is a bit challenging due to all the analogue electronics involved so for now we'll just have to put up with the two sampled sounds each consuming exactly 8KiB.

 

I haven't uploaded the source anywhere yet as I'm still fiddling with it, if there is any interest I will share the last stable snapshot.

 

Oh forgot to say, this of course means that other games using the Galaxian hardware will have these sounds, tested with Balck Hole so far.

 

  • Like 1
Link to comment
Share on other sites

Something else I came across, there seems to be an annoying flicker at random intervals in the Galaxian game, it looks a bit like a checkered pattern. I run the game through the simulator with the Black Hole ROMs and managed to capture the event on frame 12 after power on. In the picture below frame 11 is normal, frame 12 has the pattern then the next frame is back to normal. Since this only occurs for exactly one frame, it looks like a flicker, and is quite annoying after a while. Now that I can see it in the simulator, I'm hoping I can get to the bottom of it.

 

post-29560-0-72164800-1365426908.png

Link to comment
Share on other sites

Interesting... the video circuitry is producing correct video which is combined with the output from the stars generator module via a video mixer.  It seems the stars module is producing this checkered pattern which is then mixed with the game video.

 

At first glance, in the stars module, chips A1 and B2 form a 14bit shift register which in conjunction with xor gate 3B and flops 2D forms a PRNG used to generate digital noise. Every time the low 8 bits of this PRNG are all set, this checkered noise pattern is sent out and mixed with the video which explains why it's occurring so... randomly. Not sure why yet, I'll have to check it against the schematic, but it's after 2am so I'm of to ZZzzz...

Link to comment
Share on other sites

OK all sorted now, code is here if someone wants to take it for a spin. It turned out to be some weirdness with the StarsOFF and VSync signals having become inverted at some point. As far as I can tell, the starfield is scrolling as it should, all sounds are there and the gameplay seems faithful to the original as expected, I haven't seen any other glitches that would be of concern.

Link to comment
Share on other sites

  • 6 years later...

Pleased to find this thread...

A few weeks ago, having read another thread in this forum about Atari Centipede, I got the code running on a Papilio Pro with Arcade MageWing. It worked but there were a number of problems which had been pointed out by the person who ported the code, the biggest of which was heavily distorted sound.

Since the hardware was by my side, for some reason I was looking in the Papilio One folder on my hard drive and saw a number of arcade downloads, and I decided to have a go at getting Galaxians to work.

I setup a new project and made a UCF (all unnecessary as the project file and UCF already existed - doh!) and having found the romgen script, was able to get the code to compile and load. It worked, but the screen was drawn twice. The solution was in this thread, which I implemented and then had good video. I noted that the explosion sound when the ship is hit was missing, and again reading this thread I saw that @alex had not only posted an explaination, but also modified code. So I then tried out his code. It took a little searching to figure out how to create the missing ROM files (which required the updated romgetn script), and I had to remove the PS2 code and replace it with code for the Arcade MegaWing, but this was pretty straightforward. It finally compiled and all appears to be working properly.

Many thanks to all involved.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.