Meta

The board tried to boot but just had a line of yellow text saying ‘XVVSIDXXVVVVV’. That usually means there’s an issue with the text layer. Using the ‘wet finger on the pins’ of the 4 SRM20256 SRAM chips at F14 to F18 showed some changes to the text when I touched the data pins on F14. Desoldering it and testing on my Wellon VP280 showed it as bad. (no continuity on the data lines). Replaced it with a Sony CXK58256P aka 62256 and got a working screen.

Now it showed ROM OK, RAM OK and SOUND CPU BAD. This most likely meant that the 6116 at F1 was bad, (although it can mean otherwise). Desoldering and testing the chip showed the A0 pin to be faulty. Replaced it with a Hitachi 6116, fired up the board and was presented with the same error message.

After looking at the Rally Bike schematics which is basically the same board, showed that the 68000 can access the sound z80’s work ram. This is done by using the BUSREQ pin to tell the z80 to get off the bus. There is quite a bit of circuitry to handle this.

Since the 6116 showed a fault with the A0 line, the z80’s A0 line could be bad too. I desoldered the z80, put in a socket and tried another z80. This new z80 was a pull and was in fact bad. The board didn’t even boot, and without the z80 in the socket it won’t boot either. I tried another working z80 and the game booted with the same fault.

Now it was time to look at the support chips that handle the interaction between the z80 and 68000.

The 68000 uses 3 74LS245’s to access the address and data bus, and a 74LS244 to set the control lines when the z80 gives up the bus.

Looking at the chips, I noticed the 74LS244 is a Fujitsu chip and if you read many other repair logs you’ll see a pattern of Fujitsu chips rapidly and randomly dying. A good candidate.

Desoldering and testing the 74LS244 showed, you guessed it, as faulty. Replacing it with a known brand pull (rather than Goldstar chips from bootlegs!) and the board fired up 100%.

Another classic saved.

PS You have to be careful desoldering chips on these board as they used a ground and power plane. This sucks out all the heat making it extremely hard even with a desoldering station to extract the chips without damaging the pcb.

I have a Super Sprint (more on that later) and 720 boardset in my collection. These are untested as they are beasts of pcbs. Two layer, but instead of being sandwiched they are plugged in end to end and bolted to the back door. Yikes.

I came across this video and it prompted me to think about doing something with my pcb sets.

Both these games run on the same hardware, so it’s just a case of burning a new set of roms and playing it right? Unfortunately this is not the case. Atari spent a lot of money developing these games and you (as the operator back in the day) need to pay for this. To stop ingenious operators looking for a quick buck Atari employed a custom chip called a Slapstic.

Fast forward many years and MAME has dissected and simulated every Slapstic version and reproductions have even been produced by UKVAC’er Colin D.

Other slapstic protected games have been hacked out or replaced, Gauntlet I and II and ESB for example. Why not the T-11 based games.

Paperboy is a more desirable game so lets convert Super Sprint into Paperboy without replacing the Slapstic, it can’t be that hard right?

The slapstic generally sits between the CPU’s address bus and one of the program ROMs

In the case of the T-11 games it actually handles VRAM banking. The slapstic sits on the address bus and activates a state machine when it’s accessed with certain address combinations which are different for each slapstic, which provides the security mechanism. An address of $0000 and /CS resets the state. In the simplest mode of the slapstic, (there are 3), the next address read sets the bank number output on the BS0 and BS1 pins.

Looking at the the memory map in MAME, reads and writes to the program rom (roms in this case as it’s a 16bit bus) also trigger the slapstics /CS pin. The program rom(s) are mapped into memory location $8000 to $FFFF.

So in theory, there must be code that reads $8000 to clear the Slaptic ready to accept a bank switch which is another read of a memory location between $8000-$FFFF which is mapped to a bank. It is also possible to do bitwise manipulation of the bank pins by accessing certain memory locations in the same range.

Next thing to do is find all accesses to the slapstic region in Paperboy using MAME’s built in debugger.

mame paperboy -debug

wpset 8000,7fff,rw

running the game with the ‘g’ command produces and immediate breakpoint as the cpu is reading the program rom as well. This is not going to help as its not possible to distinguish between slapstic reads and cpu writes.

Looking at the mame code for the slapstic (handily named slapstic.cpp) there is a define for logging slapstic accesses

#defineLOG_SLAPSTIC (0)

Changing this to 1 and re-compiling produces a large slapstic.log file when the game is run. This file gets filled with reads in the Slapstic region. Even the initialisation code is logged, hence the mystery multiple reads from the same PC.

$20 is put into location $D20 which is work ram, then a TST $8000 which reads the Slapstic and resets its state, another read from $8020 which must set the Bank to an unknown value. Since $20 is the same offset as $8020, location $D20 must being used for holding what the current bank is set to.

The subroutine at 0o100242 sets the bank to the value in R0 after doing some maths on it. This must be the magic code that sets the bank. The reason the address looks weird is that addresses are specified in OCTAL, not HEX although MAME tends to use both at the same time. The rom address is in OCTAL but the disassembly is in HEX, (ie the jump/call address).

Now we have the code that sets the bank we can use breakpoint commands to see what values R0 is set to on the bank calls. Fortunately MAME uses the convention 0oXXXX to specify OCTAL numbers.

mame paperboy -debug
bp 0o100242
g

The breakpoint is hit immediately and R0 has a value of $4000. We can single step through the code using F10.

After the ASR (shift right) R0 has the values of $00,$08,$10,$18 whereas Super Sprint needs these to be $00,$04,$08,$10. R0 needs to be shifted right one more time to get these values. Changing the BIS #$0020 to BIS #$0050 gives the page addresses starting at $8050.

We can’t magically insert another instruction so a call to a routine that has an extra shift is necessary. Fortunately there are enough bytes to replace the ASR’s with a call to the routine with the extra shift.

Change the slapstic number Paperboy uses (105) in the mame/drivers/atarisy2.cpp file to the Super Sprint slapstic (108).

Recompile MAME to incorporate these changes.

Try running Paperboy now with this change. This is what a real board would do if you just burnt a set of roms without changing the code.

If you don’t already have the two ROM binaries in the mame/roms/paperboy directory, put them there with the correct name.

Start MAME and lets see if it works.

We have a winner. A great looking title shot.

Better check the demo/game works. After showing the highscore page, the demo starts as usual, but then the game messes up with this screen.

This looks like something is screwing with the VRAM banking. We have only changed the slapstic code a little bit and the game initially worked. Lets check the slapstic.log file to see if something strange is happening.

Looking through the log shows the state changing to BITWISE1 and BITWISE2, but this never happened in the normal Paperboy run.

Normally Paperboy uses the Slapstic in simplified mode,but there are other modes which allow the game code to change banks with certain address triggers.

From the Slapstic FAQ

Finally, each slapstic has a mechanism for modifying the value of the
current bank. Earlier chips (101-110) allowed you to twiddle the
specific bits of the bank number, clearing or setting bits 0 and 1
independently.

In mame/machine/slapstic.cpp there is the definition of the Paperboy slapstic

The BITWISE state address’s are at $0060-$0063. Times two and in OCTAL is address 0o100300 to 0o100306. The slapstic.log file shows it changing to BITWISE state at these locations. Something is triggering the BITWISE state.

Either intentionally or by happy accident the Paperboy code is triggering the BITWISE state as well as setting the bank using the simple mode of the slapstic.

We know that to set the bank in simple mode we need the two TST instructions but we need them at another address so the BITWISE state doesn’t get triggered. A JMP to the necessary code elsewhere in the ROM would work, just like adding the extra ASR, but haven’t we seen this code before?

I noticed a strange 1541 clone for sale on TradeMe over Xmas which according to the seller started smoking when he powered it up to test. I put a bid on it and it went for a song.

Untouched main pcb

It duely arrived and I opened it up. There are no identifying markings on this drive other than PC-606. Googling that just shows the Trademe auction. The floppy drive itself is a Gold King GYE55A also give no results when googled.

First thing I noticed was a discoloured tantalum cap on the main pcb. No surprise there as they tend to short and since the PSU is a linear type it feeds more amps into the circuit until something fries.

Toasty C7 presumably a 10uf 25v – Note the floating TTL chip and “we don’t have any 4 way resistor packs so a 8 will do” bodge.

Googling typical original 1541 faults showed that a 10uf in the 12v line usually shorts. I checked with a digital meter on continuity test and it indeed was shorted. After replacing it with a electrolytic and powering up the drive with the floppy cable disconnected got the board booting, with the drive light coming on red for a few seconds as expected.

Floppy drive and main pcb

I connected the floppy drive to the main pcb and powered it up, expecting the repair to be done. Low and behold more magic smoke appeared. This time it was a tantalum cap on the floppy drive itself.

Smokey 4.7uf 25v tantalum this time

I removed the melting cap and checked the 12 volt rail which still showed as shorted. Checked the rest of the tantalum caps on the pcb with the meter and found another 4.7uf cap was shorted. Removing that cap resulted in no more shorts. There were no shorts on the 5v rail fortunately. Replaced both caps with electrolytics I had to hand, and after re-assembling, the drive power up without loosing any magic smoke.

Full view of floppy drive pcb

Strangely the power LED stopped working. After checking that the LED was getting power I noticed the green wire wasn’t even soldered properly as it wasn’t stripped properly. Must have only just been connected since it was made in 1985. Resoldered the wire and the power LED worked fine.

Put it all back together and connected it to my C64. Tried a couple of disks and its all working fine now.

It even comes up with the normal 1541 version on boot. I’ll dump the eprom to see if its different from a real CBM drive.

[Edit] I dumped the eprom. Its 1541-325301-01 joined with 1541-901229-05.

Seems there are still some questions regarding the extra pins (Konami-1 is 42 pins rather than 40 like a 6809e) and interrupts. Maybe some examining of boards with builtin Konami-1 replacements like Junofirst and Gyrus is necessary.

As far as I know Circus Chalie and Ropeman use this daughter board too.

Swapped the switching FET to an open collector 7406 (I didn’t have an LS handy) and I was able to reduce the delay in the read considerably.

Reading the directory from the SD card works which is cool.

As the SD/FAT code needs to run in the System24 bios, it all needs converting to 68k assembler. After a few evenings work, the code to interface to the sd card is written but still needs debugging on real hardware. FAT16/FAT32 (or maybe just FAT32) code to be converted next.

The beauty of having the code working in C is that I can just replace each function with it’s assembler version and test each one. (after realising I needed to create some trampoline functions to convert the stack passing method to a more typical assembly call method.. unless there’s a compiler function to use register passing.. I wonder..)

After spending a ton of time researching sdcard interfacing, perils of voltage shifting and with the help of Charles MacDonald getting the Genesis C compiler working on System 24, I have successfully read a file from a SD Card. whoo hoo.

This is only proof of concept as the hardware is very slow receiving data and all the C sdcard and fat16/32 code will need rewriting in assembler. Hopefully a change from a FET to a 74ls05 will improve the speed.

After googling on and off for a week or so (every time she complains about it), today I finally came across mention of Apples two-step verification causing issues (Original post) . Bing the light came on.

Basically, the email on Android phone doesn’t handle two-step verification so you have to create an App specific password to use instead of the normal iCloud password as discussed here Using app-specific passwords.

So, go through all the steps as usual to add the email as shown in the mail settings link, except use the super long and annoying to type App specific Generated Password instead of the iCloud one.

I brought an Outrun pcb which looked original from the auction picture. It even had the Sega licensed holo sticker.

But but when it arrived, it looks like a bootleg.

Back in the 80’s it was expensive to import electronic equipment (tv,etc) to New Zealand so many companies just imported the parts and manufactured them locally. In other words Taito NZ most likely brought the custom chips (including the ck5205 chips), from Sega and built them. Hence the ‘Manufactured under license sticker”. Oh, and thanks guys for soldering in all the eproms.

Very low volume was the first issue. Checked the volume pot as it had been changed. Was the correct value. Replaced the 1000uf capacitor that was visibly bulging and the sound came back very loud!

When it is first powered up all the ROMs and RAM 7 show as bad, but powering the game off and on again reports RAM OK ROM OK.

Left for a few minutes it doesn’t again.

Having already replaced the capacitor which was bulging, the rest of the capacitors were suspect.
M72 games have a reset chip at ic7, with two timing capacitors. Shorting out both when the board was powered off produced the same error message every time. Replaced both capacitors at C8 and C10 got the board reliably booting.