What's new
Joined
Oct 2, 2021
Messages
41
Reaction score
42
Location
Germany
Hi.

Err, this is a big Work In Progress. Nowhere near finished. I'm gonna abuse this post as a blog or something, so expect updates.

OK before you TL;DR, can you please point me in the direction of a program that can convert an audio file with FM encoded data into a binary? Otherwise I will have to write my own and that's gonna take all day (I'm a bit rusty).
Also - how do you dump the Dongles? Does anyone know? Ideally without depotting? (Note it's an early game and from what I read there are two types of dongles, simple and sophisticated. This is 99.9% sure a simple one) (and it's probably easier to bruteforce it...)

Why am I doing this?
2 reasons: First, I can't find any of the documentation or software on how the DECO tapes were originally dumped (it appears, they did it in 1996 already) and need to reinvent all the wheels. Second, the Flipper und Arcade Museum Seligenstadt has a copy of The Tower which isn't dumped yet. We don't have the Marquee, but we have the tape, the dongle, the inlays (which slides under the control panel to tell you how the game is played) and even the manual. And maybe the marquee is stored somewhere else and we just haven't found it.
(before you get too excited, there's two things: First, we have a long journey ahead of us to get something that's playable in MAME. Second, it looks to be an almost identical clone of Nichibutsu's Crazy Climber - like lawsuit style identical)

I just managed to dump a DECO tape (Lock'n'Chase, since we have two of it and it's well known). To do that, I had to fix the drive.
Here's how to fix the drive
So the tape drive is a modified mini cassette. The closest I have seen is what HP used in the 70s and 80s. On the surface it's a standard Philips Mini Cassette, but instead of having 2 openings for the tape head, it has only one in the center. It also has a ridge to tell the drive if side A or B has been inserted. And that's pretty much it. It's a rim drive as well, so don't put a wow&flutter meter on these as it will likely explode.
Inside the drive, there are two idler tires which rest against the center spindle which is driven by the motor via a belt. Replacing the belt won't fix the drive, since the idler tires are pushed against the center spindle via a spring and haven't moved in (usually) 3 decades, so they got a nice dent which will make the tape transport screw up.
So first I took apart and cleaned the mechanism. The form and size of the idler tires made me think "tape pinchroller" and sure enough, they are very similar in size but twice as thick - so I cut one in two. Note there are different versions with different inner diameters. I happened to get lucky - the inner diameter fit perfectly and the outer diameter was just a tiny bit too large - it would make both reels turn always.
IMG00002.JPG

So I stuck the sliced-in-half pinch roller onto another cassette deck's motor and held it against a fine grit sand paper for a while and repeated the process until it was the right size.
Next task was to get the data off the tape.
For this, I desoldered the tape's motor and read head, connected the motor to a lab power supply and soldered the read head to a cheap shoebox recorder that was also designed for use as a data recorder as well. The output was then connected to a computer sound card.
IMG00001.JPG


(note left the shoebox recorder and right the DECO Cassette Deck - the two idler tires can be seen below the flywheel of each reel. The left one is a sliced in half pinch roller and the right one is original. That saved on sanding time, but the machine won't be reading data in reverse any time soon. (or ever - I'm pretty sure it doesn't read anything in rewind, just look for markers. In the top middle, right next to the green alligator clip there's a motor with another idler tire against it - this is to demonstrate how I sanded it down)

Here's me trying to make sense of the audio
Next - getting the audio off the tape is... hard. Even with the mechanism wonking (not a typo - I mashed working and wonky into one word) I had speed problems as well as azimuth problems, it appears the tape head doesn't make good contact with the tape.

Anyway, I made two audio dumps of the program. Zooming into the waveform, it becomes apparent that DECO uses FM encoding. Maybe MFM, I can't see more than 8 consecutive 1's (or 0's depending if a long pulse is a 0 or a 1) except at the start and end of a block. I can see more than 8 consecutive 0's though.
(the start and end of block has exactly 16 long pulses)
What I can also see is there are blocks where the tape stopped for a fraction of a second (about 6 bytes). Good that I have two dumps. Also this is just preparation to be able to dump The Tower.
So here's a screenshot of what I make of the audio.
screenshot_fm_decode.png


This is from the very first packet on the tape and it contains vast areas of repeating identical bytes (here you can see about four repetitions). Comparing to the hex dump of Lock'n'Chase I can see the start of the file contains a vast amount of 0xBA, followed by some data, followed by a vast amount of 0x1B. Looking at the audio waveform I can see both areas of repeating bytes with a bunch of data in between, but the pattern for 0x1B looks exactly the same as 0xBA. So either the dongle does this or the files don't match or I'm looking at something completely different - since this is the first packet which is a header packet that basically mates with the dongle and tells the machine what number to display on the counter, maybe it isn't even included in the dump. But the second packet has no repeating data (although that could be because of the dongle). Or maybe it's MFM.

So please - does anyone know more about the DECO, how to read the tapes or ideally has a bunch of .EXE files for DOS or Win9x to convert a .WAV to a .BIN and ideally know how to decrypt these, please tell me.
Otherwise that'll be more wheels to reinvent.

Btw. https://scarybeastsecurity.blogspot.com/2021/05/recovering-lost-treasure-filled-floppy.html also has a nice writeup on how to decode FM by hand, but I haven't found a link to a program that does it for you.

And something for the far future - let's assume I managed to dump The Tower and it's playable in MAME - how do I get the file back onto Darksoft's Multikit? I have a rather late version that uses a compressed 16 bit EPROM (27C0160) and I don't even have a burner that can take these! (it can do 27C210 though so I could build a breakout to toggle the extra address lines and burn it one block at a time)
 

Attachments

  • screenshot_fm_decode.png
    screenshot_fm_decode.png
    246.7 KB · Views: 103
i would tap the digital processed signal from the arcade board or hack the bios to load the tape and then dump it through some port/pins to a pc.
 
If you provide the hacked ROM image and tell me what pins to connect to...

The flaw in your plan is: The DECO will re-read sectors with read errors, so the processed signal will every now and then have the same block backwards and then again forwards so I'd need to watch the drive, rig up another button to read as a signal so I can push it and mark a block as duplicate.
And... if the machine aborts, unable to load the game at all, this plan won't work at all. (although judging from the signal, there's a decent chance it actually manages to load the game).
 
The bad new: The DECO won't read anything from tape. It stutters wildly and aborts at the first block with ERROR 01.

The good news: I looked at the entire waveform of the first of the four dumps of The Tower I did and it's gapless (in one piece, the tape didn't even stop for a split second - both my Lock'n'Chase dumps have gaps, albeit in different blocks each so you could construct a valid dump from the two files). There is one tape dropout which still has plenty of amplitude left to decode.

So once I've finished programming (haven't started yet) I should be able to get a good dump.

So I got a few questions remaining:
-Is a half-cycle wave a 0 and a full-cycle wave a 1 or is it the other way round? (It's a 50:50 chance and if I screw up it's the easiest of operations to fix it - just a NOT)
-The packet header counts as how many 0s (or 1s)?
-The packet trailer counts as how many 0s (or 1s)?
-Are the packet headers/trailers discarded?
-Which part of the packet is the checksum? Is the checksum encrypted?
 
i would think someone involved with the mame driver would know. But I’m not sure they’re here. They have a discord and there’s the mame world forums - have you been there?
 
No, I haven't used discord before.

So the dongles are 32 bytes. That's 2^256 possibilities. Even from looking at the mame driver I don't know what the dongle does with the data. Maybe I missed it in between the vast amounts of game specific configuration. And then it's probably something simple and reversible like XOR.
What I can glance is that the blocks I'm hearing/seeing are 4800bps, have 256 bytes (I will be able to very easily verify that) plus a checksum which just finds two bytes that roll the checksum to 00, so I even have a chance of determining if my decoding is correct. Question: Checksum before or after dongle? The decocass_tape.h/cpp don't make any mention of a dongle anywhere.
Also the packets start with 0x00 0xAA and end with 0xAA 0x00. I can verify that for the first block (although mine all start with 0x00 0x00 0xAA and end with 0xAA 0x00 0x00 -> Now I know that a half cycle wave is a 0 and a full cycle wave is a 1. Cool, the second block also starts with 0x00 0x00 0xAA. Woo progress, thanks!

Also btw. I'm pretty sure the countdown counter displays the number of blocks left and if a block has a bad CRC, it is rewound and retried (as seen in Jacklick's video).
 
OK... this is really preliminary, I really have to fine-tune the tolerances, I need to put in some more debug statements so the actual periods go to a separate text file that also includes asterisks if a value is out of range, then I can fine-tune the tolerances. Or find a read of the same block that's in better shape.

Also the code quality is pretty bad, even for my standards.

The file size of the Lock'n'Chase binary is 26039 bytes
The file size of the The Tower binary is 27587 bytes.
(the odd number might be due to trailing ringing noise being interpreted as extra bytes - it even tries reading the record start/end blub noise...)

Also I just notice that not every block begins with 00 aa... some are missing a bit or two! Like the header of The Tower needs to be shifted two bits to the right, and the third block needs to be one bit to the left. Every block HAS to begin with 00 aa.
Uhh... all you need to do is shift each block until the first bytes are 00 aa, then you should be good, I don't see any bits outside the tolerance in my tower.txt - my program kinda panics at the end of each block, but that's ok, it won't save it. The Lock'n'Chase tape is in way worse condition with tons of bits outside their tolerances mid-block.

Lots and lots of fine tuning... but if you shift the blocks that don't start with 00 aa, you'll end up with a good dump.

Last question remaining: Where do I upload my .bin file once I'm done? And who will decode it?
(I mean - when I finished fine-tuning, I will run this program over the three other dumps and see if there's consensus)

TL;DR
ignore the Period=0 in the Lock'n'Chase debug output - for some reason, printf isn't working right - the period equals the average determined above each block. Also this is a bad dump, but it was just for testing.
And note to self: in the calibration program, read until the first 1 is encountered, then jump into decoding - although this will make the code even more unwieldy.
And now I'm back in my day job, so don't expect the 100% fixed version tomorrow.
Also looking at the dump and the decoded Lock'n'Chase binary, it looks like the data is XORed with a value from the dongle which then is randomly switched, otherwise you can't explain the fact that the encrypted headers contain the same byte over and over again. The decrypted headers contain lots of the same byte, some noise and then lots of a different byte. That's probably the dongle rotation. I'm not a code cracker, so please someone else do this.
 

Attachments

  • tower.txt
    116.7 KB · Views: 110
  • lockchas.txt
    118.5 KB · Views: 97
  • DECOREAD.C.TXT
    10.4 KB · Views: 113
You know what? I let myself go. I cheated. Coding by Trial&Error. But still, three out of the four dumps I did got the exact same binary file (with the same checksum, but I also flicked through all the bits so it's pretty much certain they are identical). Dump number 2 had a few blocks that were totally different (shifted), but blocks 0-3 were error free and even though I had two different errors in blocks 0 and 2 in all the other dumps, these blocks were still the same!
So even though I cheated, I ended up with the same exact data as if I didn't.

Which also means I created a program that can only read The Tower and probably other DECO Cassette System games.

But like I said - I did FOUR dumps of the tape, each with different strategies (putting finger on pinch roller, putting finger on tape to push against tape head, put finger against mechanism, just letting it run without touching it at all...) - and THREE ARE BIT-BY-BIT IDENTICAL and the fourth one (Dump #2) has a few errors, is mostly identical.

Err... I think we got a good dump, then.

So... unless I find out how to read the dongle, this is probably gonna be the last entry. I wouldn't bet on me not being able to work out the dongle... the only thing that sucks is that almost all the dumps on MAME have the same exact dongle data - someone has written a program to re-encode DECO CAS files from one dongle to another so most games now play with the same dongle - which means it's improbable that we have one unique dongle I can check against... would be so nice if I knew I did the right thing.

I wonder if I should upload the EXE - but you'll have the same problem as I when I get one of your EXEs - I will get the error "This program requires a newer version of Windows" and you will get "This program uses an obsolete format and is incompatible with this machine". But it runs just fine on a 40 MHz 386. Takes about 2 seconds per block on this machine.

EDIT: Please note that the TOWER1.BIN also includes the block headers, checksum and block trailers - each block is 263 bytes long, there are 105 blocks.
 

Attachments

  • decotower.zip
    100.8 KB · Views: 103
Last edited:
Senil, Juergen Buchmueller, who hails an is maybe from Bonn, probably wrote most of the mame deco driver stuff. Not sure the best way to reach out to him but seems like he would have the best info.
 
Last edited:
So I had two pretty bad (and stupid) errors:
- I copied the bit first and shifted then. That way the last shift operation will shift the first bit out of the byte. That's why my previous dumps have the 2^0 bit stuck 0.
- I had the bit order the wrong way round. So if it's 0101 1100, that's not 5C, it's 3A.

Bad news: I can't get three of the dumps to agree anymore (even though I didn't change the sub-bit level code in any way, so theoretically I should get the same exact pattern - oh wait it's often the first byte of the block, so you could easily manually decode it, also that means it's -probably- certainly a programming error)
(dump 2 is the only one that has bytes disagreeing that aren't the first byte in the block)

OK let's make a table of the errors (line/column are from DOS editor)
0x200: 50:50 - 97 or 9E (block 2 - this time starting at zero) hand decode says 97 is correct (which is unfortunately Dump 1 and 2)
Line 17 Column 1: Majority vote C7 (dump 2 is bad)
0x700: 50:50 - F5 or F6 (block 7) (manual decode says F5) (again, dump 3 and 4 are wrong)
Line 77 Column 1: Majority vote DD (dump 2 is bad)
Line 117 Column 1: Majority vote 39 (dump 2 is bad)
Line 165: Bad block in dump 2
Line 173 Column 1: 50:50 - C7 or CE (block 43) (manual decode says C7, again 3 and 4 bad)
Line 261 Column 1: Majority vote 8E (dump 1 is bad)
Line 268 Column 43: Dump 2 is bad
Line 276 Column 56: Dump 2 is bad
Line 277 Column 1: Dump 2 is bad
Line 285 Column 58: Dump 2 is bad
Line 291 Column 14: Dump 2 is bad
Line 293: Bad block in dump 2
Line 317 Column 1: Majority vote 47 (dump 1 is bad)
Line 330 Column 1: Majority vote C7 (dump 2 is bad)
Line 342 Column 61+62: Dump 2 is bad
Line 384 Column 38+39: Dump 2 is bad
0x6000: 50:50 F6 or F7 (block 96) (manual decode says F5 (!) ) (checked I'm not in the wrong block, so F5 is gotta be right)
Line 409 Column 1: 50:50 DD or DE (block 102) (manual decode says DD)
Line 413 Column 1: Majority vote 77 (dump 1 is bad)

And... dump 3 and 4 are absolutely identical. Unfortunately hand decoding the first ambiguity shows the error is in dump 3 and 4...

OK I'm gonna upload TOWERFIX.BIN (which is taken from TOWER3.BIN) which has the 50:50 ambiguities resolved with the manual decoding. If it still doesn't run in MAME (if it can be made to run without the dongle), I have the choice of either manually decoding every first byte in the block or... fixing whatever bug causes this behavior.
 

Attachments

  • tower.zip
    114.6 KB · Views: 97
Hi, I just tried this new file and it doesnt even load on MAME, it fails the CRC in the first read. I just remembered that most .cas files in MAME are 32Kb. This one seems to be smaller.
 
I noticed that the .CAS files I looked at are padded to reach 32k. Lock'n'Chase for example stops at 0x6400 so it's actually smaller than The Tower.
Also the first block, I manually converted the first couple bytes to check if my code works, so it's pretty certain the first block is good (so I guess it's gonna need the dongle)

Concerning the dongle... I dumped the Lock'n'Chase dongle completely (but destructively) and it looks like it contains the same data as the MAME file, but not in the same order, not even if you switch bits around, because the address 00000 and 11111 should be the same or reversed, instead they're found somewhere in between (like at position 6 or something). I need to do more research. Or copulating drill holes in the case to access the chip legs.
 
As I said, if you try to read the Tape in MAME it fails immediately, the tape counter doesn't even move. This has nothing to do with the dongle. The dongle is checked during the gameplay.
 
Maybe I do the first packet by hand then. And/or upload one of the wave dumps.

But onto the dongle... here's what I gathered last weekend:
Pinout as seen on the solder side of the dongle (the contacts are exposed no matter how epoxied your dongle is)
NC D3 DE DF D0 D1 D4 IG IH II IJ NC +5
NC NC 0V DL D2 A0 A1 AM AN A2 A3 AO A4

A0..A4 address (as connected on Lock'n'Chase) - The Tower has A1 not going to the PROM, but instead has AO strapped as A3
D0..D4 data (EDIT: Since the D's all go to an LS374 on the RMS-3 board, I could match them with their REAL data lines, but that thought occurred literal seconds ago)
NC = not connected
DE = Data pin unused on Lock'n'chase
DF = Another pin strapped for data usage.
IG = Input G (goes to pin 2 of the LS139)
IH = Input H (goes to Enable of the LS139)
II = Input I (goes to pin 14 of the LS139)
IJ = Input J (goes to pin 13 of the LS139)
+5 = 5 Volts in
0V = Ground
DL = Designation L (another data pin)
AM = Designation M (this is an address pin unused on Lock'n'Chase)
AN = Designation N
AO = Designation O (A3 on the The Tower dongle)

So the address pinout of The Tower has A3 hooked up on A0 (row 2 pin 2 from the right), otherwise it's the same.

And now for the data:
2⁷ = D4
2⁶ = D1
2⁵ = D2
2⁴ = D0
2³ = DL (the one right next to the ground)
(LEDs 2⁰, 2¹ and 2² don't toggle unless you do some weird stuff I won't explain unless I understand it)

(D4 D1 D2 D0 D3 is probably the order of these bits... since I can't trace them, there could be more swapped orders)
0 11111
1 00101
2 10001
3 00110
4 11000
5 00100
6 10010
7 11101
8 01011
9 01001
A 11110
B 01010
C 10000
D 10111
E 01111
F 10101
10 00011
11 11100
12 10110
13 01000
14 01101
15 11011
16 00001
17 11001
18 01110
19 10100
1A 00010
1B 00000
1C 00111
1D 10011
1E 01100
1F 11010

This is repeatable. However if I pull all the Ix (inputs to the 139) low, the dongle will start to oscillate and even drive the address lines, so there's data coming out of the address lines.
 
Very good retroanalysis, bravo!

In the original DECO the only hack they do is that the code being run, swaps bit 5 and 6 on each byte. That's it.

Send me that dump whenever you can please.
 
So I just have to swap bit 5 and 6 for each byte in the binary? (excuse me if I have to ask, but it looks like I'm missing the bigger picture, I still think that a byte is read from tape, goes through the dongle, gets XORed, some "magic" decides whether to load the next byte from the PROM or not, at least that's what I'm seeing with the official known working Lock'n'Chase dump)
 
NOTE: This binary doesn't have any bits swapped yet.

OK I fixed my bug. So I took a read from the start of each packet to determine the period. Sometimes, whatever noise is at the beginning would get in there, causing the entire block to be shifted. The fix for that was to check if I get anything other than 00 for the first byte, if yes, rewind, if no check if I get anything but AA for the second byte, if yes, fast forward. And the amount of bytes I rewound/fast forwarded was constand [period]. So I could have read a 1 but rewound a 0, stopping at an illegal position, corrupting the first byte.

I vastly updated my calibratebot routine, it will read some bytes to calibrate the period, then continue reading until the first 1 is encountered. Then, we rewind to the last 0 (because that period is known), then we rewind two periods and do one dummy read so we line up exactly at the start of each block.

The result:
No more "shifting to get AA/00" in the debug output. Every block now starts with aa. Reliably.
The first byte in the block matches the ones I decoded manually (also, some first bytes per block were wrong for all four dumps, proving that TOWERFIX.BIN is indeed faulty) - and yes it gets F5 for 0x6000 which is correct.
TOWER1.BIN, TOWER3.BIN and TOWER4.BIN are bit-by-bit identical again. Yay!
 

Attachments

  • tower.zip
    44.3 KB · Views: 105
Great news! As you suspected, the BIOS is doing some logical operations with the data being read from the tape and the dongle, so until we dont get the dongle dumped, we wont be able to run the game, I'm afraid.
 
Well I got a shocker for you... it appears the ROM contents is 100% identical to Lock'n'Chase, only the address/data lines have been wired differently.
So there's 8 address and 8 data lines and only 5 of each are used, but which 5 is different for each dongle.
So this is what I think:
In the factory, all dongles are made exactly the same, with the same data on each PROM, and then they go to the workers who customize these by connecting solder pads in different ways (you can see there's a lot of vias for jumpers and then there's a jumper wire in each block).

And here's the connections:
Lock'n'Chase:
Data Lines:
8765xyx1 (which would be 5432xyx1 or rather 4120xyx3 on the PROM)
Address Lines
8x65xy21

The Tower:
Data Lines:
87654xyx (which would be 54321xyx or rather 41203 on the PROM)
Address Lines
87x5yx21

So when it comes to data, just use the Lock'n'Chase Dongle and rotate the least significant Nybble 1 to the right.
And when it comes to addresses, bit 6 and 7 are swapped, bits 4 and 3 are swapped. So I don't know how the internal connections in the dongle are coded in MAME, but these three bit swaps in the Dongle should be all that's needed to get The Tower running in MAME. And then there's a chance the two lines I marked X are switched. But we went from 2^32 combinations to 4 combinations.
Ah and I haven't said what the x and y lines do... if anything on the dongle is output enabled (by pulling three of the LS139s inputs low), toggling the y address line will make the LED marked y toggle. So this is a pass-through that doesn't seem to affect anything else on the dongle at all.
Toggling the X lines makes the X LEDs toggle AFTER clocking the LS139s inputs. The X outputs appears to only react to the X inputs, it's repeatable and it's 4 different outputs for 4 different inputs. The lookup table for The Tower is (input->output)
xx=00->10 01->00 10->11 11->01


TL;DD (too long, don't decode)
"unfortunately" the order is my own arbitrary one, the way the wires came out the connector, but here's a translation with the Lock'n'Chase dongle I had open:
So this is the contents of the Lock'n'Chase PROM.
There are 5 columns, from left to right:
Byte number (reflects the address bits, duh),
the 5 bits per byte that are exposed to the world,
the remaining 3 bits read with a scope probe directly from the PROM
the entire byte rearranged to have the bit order the right way round
the entire byte's HEX code.

So the second columns bit order is 4 1 2 0 3 as reflected on the PROM itself. And even though the address lines are wired differently on The Tower, I got the same exact data, only one LED was different, but the bit order was the same.
41203 567 76543210 (sorting the bits by hand, could contain errors)
00 11111 001 10011111 9F
01 00101 011 11001100 CC
02 10001 001 10011000 98
03 00110 111 11100101 E5
04 11000 100 00110010 32
05 00100 011 11000100 C4
06 10010 010 01010001 51
07 11101 101 10111110 BE
08 01011 000 00001011 0B
09 01001 001 10001010 8A
0A 11110 100 00110111 37
0B 01010 110 01100011 63
0C 10000 000 00010000 10
0D 10111 110 01111101 7D
0E 01111 000 00001111 0F
0F 10101 101 10111100 BC
10 00011 010 01001001 49
11 11100 111 11110110 F6
12 10110 111 11110101 F5
13 01000 110 01100010 62
14 01101 111 11101110 EE
15 11011 101 10111011 BB
16 00001 010 01001000 48
17 11001 101 10111010 BA
18 01110 001 00100111 27
19 10100 110 01110100 74
1A 00010 011 11000001 C1
1B 00000 011 11000000 C0
1C 00111 010 01001101 4D
1D 10011 100 00111001 39
1E 01100 000 00000110 06
1F 11010 110 01110011 73

So this is the dongle data of Lock'n'Chase. And I dumped The Tower with the same dumping station and for the first two columns I get the same exact data (except the rightmost bit lit the 4th LED from the right instead of the rightmost). Bit by bit. I just can't get the 3 extra bits per byte out.
And yes I know, the order the bytes go in the official MAME file is totally different.

There's still a faint chance these three bits are different, because when I look at what the Multikit dongle does, it never uses the address lines EVER, but it uses 4 pins that aren't connected on the dongles I know and it looks like there's some bitstream serializing going on, so the one chip I completely broke might have been a '94 or a '194.

So if it doesn't work with the 4 combination of x lines, try using the data in this post and then the 4 combinations. That's... 8 combinations you can try.
Let's see if one of them works.
 
Back
Top