JAMMArcade.net – Page 144

Time Pilot repair log

Jul 242015

Got Muddymusic’s Time Pilot on the bench this time.
This game gave me the run around for a lot longer than I anticipated due to reasons I don’t really understand. Maybe someone can help me understand why.

So the game was meant to have two faults. The first was the RIGHT control didnt work. The second was the sound did not work.
Straight away I ran into problems. I could not get this board to sync with any of the 3 screens I have on my test rig, it also wouldnt sync properly in my Astro City cab.
I have recently bought a couple of those mini cabs and one was stripped out at the time so I used the monitor from that and the board seemed to sync up just fine.

There was that big red border around but I recall having the same thing on a Circus Charlie board I fixed so thought nothing of it.
Playing the game led me to think the background colours were missing.

I spent about 3 days going right through the schematics and running tests with the Fluke 9010 to figure out what was wrong. I couldn’t understand it. Muddy claimed that the background colours were present before he sent it off.

As I started doing more and more testing I started to get new faults with the sprites. I needed to figure out which chips were the sprite RAM’s so I reversed the ‘custom’ chip known as K526. In reality this chip is an 82s153. I dumped the chip and reversed it into equations

Pin 1 = MREQ
Pin 2 = RFSH
Pin 3 = A15
Pin 4 = A14
Pin 5 = A13
Pin 6 = A12
Pin 7 = A10
Pin 8 = F4

0xb400 (spriteram2)
/o12 = /MREQ & RFSH & A15 & /A14 & A13 & A12 & A10 & /F4

0xb000 (spriteram1)
/o13 = /MREQ & RFSH & A15 & /A14 & A13 & A12 & /A10 & /F4

0xa000 (main ram. covers color ram and video ram too)
/o14 = /MREQ & RFSH & A15 & /A14 & A13 & /A12 & /F4

0x8000 (Goes to pin 12 of 501 custom and also F3.)
/o15 = /MREQ & RFSH & A15

0x6000 (enable for unpopulated ROM socket, H5)
/o16 = /MREQ & RFSH & /A15 & A14 & A13

0x4000 (ROM H4)
/o17 = /MREQ & RFSH & /A15 & A14 & /A13

0x2000 (ROM H3)
/o18 = /MREQ & RFSH & /A15 & /A14 & A13

0x0 (ROM H2)
/o19 = /MREQ & RFSH & /A15 & /A14 & /A13

I figured out that the 4 x 2114 chips at D7 – D9 were the sprite RAM. 3 out of 4 had failed one by one so I ordered some up and replaced them when I got them.
All the sprites were back but still no background colours.
In a desperate attempt I wired the RGB-S straight into a scart connector to try a different TV. This is what I got.

The backgrounds were there all along but for some reason my other monitor wouldnt display them. I know the monitor works fine with my other games but why I did this I have no idea. If anyone knows or has any theories I would love to hear why.

On with the repair.
As you may already know this board gave me the opportunity to test Shoestring’s diagnostic ROM. After a few teething problems we got it working and I was able to test the player inputs. To my surprise they all worked fine and testing in game confirmed this. No idea why it didnt work for Muddy but it works now.
After getting the game up and running with background I noticed the main ship sprite was no longer a ship (see picture above).
Lightly flexing the boards fixed the problem but then the board stopped working. The Fluke was already plugged in and running test gave me a DCD error.

This error means there was a problem with the RAM addressing/decoding. This issue is normally missed by POST routines as they simply write a value to an address and read it back comparing it. The Fluke doesnt do this. It writes specific values to specific addresses so if there are any addressing issues it can tell. My issue ended up being caused by me. There was a tiny flake of loose solder bridging two address lines on the main RAM. Removing this made the game boot again but now I had another issue.

The graphics were now doubled up.
This was easy to find and ended up being a dodgy socket on the 082 custom chip at location F5. I replaced the socket and now everything was good again.

With that all done it was on to the sound.
I was getting a little tired of looking at this board so after a few preliminary checks I just desoldered the Z80 and fitted the Fluke.
BUS CHECK showed bit 0 and bit 1 were stuck LOW. I wrote 0x55 to a point in RAM and read it back, I got 0x50.
I then wrote 0xAA to the same point and read it back, I got 0xA0.
Looking at the schematics I pinpointed the offending RAM chip to the 2114 at B7.
Replacing this game me back the sound.

On the final test the sprites died again!!
I replaced the last 2114 RAM chip on the main board and this is now 100%

Using the HxC Floppy Emulator with a Fluke 9100

Guides Comments Off

Jul 192015

Recently the floppy drive on my Fluke 9100 became unusable and I feared the worst. I’ve tried once before to get the HxC floppy drive emulator to work with this but I never managed and to be honest I’ve never delved into floppy drives at all so I was a bit clueless.

I found THIS site while looking for information and at first I skimmed over the details and didn’t really take any of it in. That was a big mistake as it provided all the information I needed to get this up and running.

The only thing I needed to do on the hardware side of things was to cut pin 14 of the floppy cable and connect the Fluke 9100 side to GND.
Everything else is all software.
In the HxC Floppy Emulator software you need to apply these settings

Save the config file to the SD card.

Then “Load” the .TD0 files that are available from HERE or HERE.

The HxC software can deal with these files without any issue so once you have loaded one go ahead and “Export” it to your SD card using the indexing naming scheme
Disk 1 = DSKA0000.HFE
Disk 2 = DSKA0001.HFE
etc

I have the first dip set to ON on the HxC device.
Once that’s all done you can fire up the Fluke and use your SD card to load.
My Fluke doesn’t have an SCSI controller hence it has no hard drive fitted so it is vital I have a working floppy drive.

Once you have the OS loaded up from the floppy drive you may need to change the way the system loads the user disks.
If your system is configured to be a 9100 then user disks are defaulted to load from the hard disk.
If your system is configured to be a 9105 the user disks are attempted to be loaded from the second floppy disk drive.

The HxC floppy replacement can apparently be configured to emulate two drives but I cannot for the life of me get it to work so this is necessary for me.

When loaded you will be met with this message
20160309_195246

Press the ‘SETUP’ button
20160309_195256

Move RIGHT to highlight ‘POD’
20160309_195304

Press F2 (‘USERDISK’) then select ‘DR1’. This is the first floppy drive.
20160309_195319

Go back to the initial ‘SETUP’ menu and select ‘POD’ again
20160309_195344

Then press the ‘SOFT KEYS’ button and some more options will appear
20160309_195349

Select ‘PODNAME’ and you will get this (Z80 pod is used here)
20160309_195354

Make sure you have the correct disk image selected on the HxC then press the ‘ENTER/YES’ key.
If all goes well the floppy will read and you will be presented with a new message (its different depending on POD type fitted)
20160309_195459

Now the POD is available to use.
NOTE: If you press the ‘RESET’ button on the keypad at anytime then it will revert back to DR2.

Time Pilot Test & Diagnostic ROM

General 3 Responses »

Jul 182015

18/07/2015

Added support for Atari licensed version
SFX counter broke after exiting character menu and re-entering SFX menu
Wrong ram associations with pcb locations now fixed.
Holding down player 2 start during power-up enters diagnostic mode

Important: Porchy discovered that 0x1 needs to be written to 0xc308 or nothing shows up on the screen at all on a PCB. This was undocumented but now we believe the value 0x1 must be written during initialization of the screen. The latest release addresses this issue. Thanks to Porchy!

To fix: Some sounds still play after exiting SFX test to main menu.

Note: Diagnostic mode relies on good RAM and ROM for configuration data to facilitate the support of multiple Time Pilot versions in the one ROM. Do not rely on results from the diagnostic mode without sorting out issues associated with RAM and ROM first.

21/6/2015

The EPROM ( a 27c64 ) once burned with this software installs on the CPU board @ 5H and can stay in there permanently if so desired.

Performs tests of the RAM & game EPROMs on the CPU board. This supports Konami and Centuri versions of the software, bootlegs are not supported yet.

Also has a built in diagnostic mode for testing inputs, sound output and displays character & sprite tables. The diagnostic mode is accessible via DSW2. All dips must be on except for dip 3 to access the diagnostic mode of the program.

Would like to thank cmonkey for providing me with technical info which assisted me in being able to display the sprite & character tables properly. Also like to thank the MAME team for their hard work on the emulator which I used as a tool for debugging/testing purposes throughout the development of this program.

See downloads in ROM Files for the binary.

0001 0006 0005

‘Massive’ Konami PAL dumps update

PAL Updates Comments Off

Jul 172015

Today we have a huge PAL dumps update and all of them came from Konami boards (original and bootleg, too).Let’s start with order.

Porchy dumped the PLDs (actually one is a redump and replaces an existing one) from an original Time Pilot PCB.Devices were two 82S153 so he converted the dumps to a more usable GAL16V8 format and succesfully tested them on hardware.

Dragos sent us the PAL20L10 chip from his Mystic Warriors PCB, I dumped it and Porchy took care of reversing it in a GAL22V10.Dragos successfully tested it.

Andreas sent us dump of the PLS173 from an original Devil World PCB ( board ID GX687, chip marked ‘007789’ @10H also present on Gradius II).We mark this dump as untested until we found a way of reversing the chip in a GAL or test the dump in an original device.

Thank you all for your precious contributions.

As for me I dumped the three PALs (two PAL16L8 and one PALCE16V8) from a Run and Gun PCB and the two ones (PAL16L8) from a Block Hole.Lastly I dumped the two 82S153 devices from a Gyruss bootleg PCB (located on the Konami-1 replacement piggyback board) and reversed them into GAL format.All my dumps come in GAL16V8 format (except for one from Gyruss that needs a GAL18V10) and have been tested as working on PCB.

Time Pilot diagnostic ROM update

General, Technical Info 5 Responses »

Jul 172015

Im currently working on a Time Pilot PCB and tested out Shoestrings diagnostic ROM.
This board is the Atari version which wasnt supported at the time but has now been updated.
I also ran into a problem where nothing appeared on the screen. Working together we eventually found the issue.
The original game code makes a write of 01 to address $c308. Using the Fluke 9010 I found that this write actually initialises the screen output.
MAME doesnt have any support for this so when testing the ROM in MAME it works fine. The test ROM has been updated with this now too and should work fine.

This highlights the need to test things on REAL hardware.
Thanks to Shoestring for making the diagnostic ROM and for putting up with all my questions.

Older Entries Newer Entries