Jump to content
phoenixdownita

Multicart(s) suggestions?

Recommended Posts

Attempted to put Vpp to Vcc, No GO.

 

Attempted to invert /CE singla control (which I tied together to /OE at the EPROM), No GO

 

Separated /CE and /OE at the EPROM, (with and without Vpp=Vcc) so that the onboard PAL controls only /OE (/CE is at GND), No GO.

Tried again the same but inverting the /OE signal from the PAL, No GO

 

I'm stumped.

 

FOr the interested on the pinout of the APL is here http://www.uib.es/depart/dfs/GTE/education/industrial/sis_ele_digitals/Problemes/PAL16R4.pdf

A quick pic is here http://circuits.datasheetdir.com/117/PAL16L8AM-pinout.jpg

 

I kind reconstructed the PAL input from the cart and they are:

pin 1 = atari CLK (phi2)

pin 2 = GND

pin 3 = atari A0

pin 4 = atari A1

pin 5 = atari A2

pin 6 = atari A13

pin 7 = atari A14

pin 8 = atari A15

pin 9 = atari R/W

pin 10 = GND

pin 11 = GND (this is /OE on the PAL)

pin 12 = pin 20 at the ROM (ROM /CE ?)

pin 13 = pin 22 at the ROM (ROM A16 ?)

pin 14,15,16,17 = not connected

pin 18 = pin 1 at the ROM (ROM A15 ?)

pin 19 = pin 27 at the ROM (ROM A14 ?)

pin 20 = Vcc

 

Also PAL pin 6 (atari A13) and pins 3,4,5 (atari A0,A1,A2) are connected in parallel to both PAL and ROM, instead atari A14 and A15 go only to the PAL, the ROM gets them from the other side of the PAL.

 

With the exception of A16/A15/A14/CE (controller by the PAL only) every other pin on the ROM is connected to the corresponding pin on the cart port.

 

Just by looking at the pinout connection, this looks like a pretty straightforward logic design. I bet I can replicate that, I'll hack up one of my boards and write new PLD code for another chip, this weekend.

Share this post


Link to post
Share on other sites

 

Just by looking at the pinout connection, this looks like a pretty straightforward logic design. I bet I can replicate that, I'll hack up one of my boards and write new PLD code for another chip, this weekend.

 

I hope you succeed.

 

I really wished once more that a simple reroute of A16 and Vcc plus tie /CE and /OE together (like per all the other 128K I've done so far) would work.

I wonder if the ROM image we have is scrambled somehow, and the problem is not in my wiring of the EPROM but in the BIN content.

 

Anyhow let's see how your efforts pan out.

Share this post


Link to post
Share on other sites

Activision multicart is GO!!!!!!

 

What I did:

 

1) as I have Rampage I attempted to dump it as a 27C301 (just need to reroute power on a socket) via an old EPROM burner.

2) what I noticed is that it seems the up and low 64Kb are copy of each other [27C301 is pin compat version for maskROM 531000/831000 with the exception of the EPROM signals that are in the extra 4 pins) ... so maybe Rampage is really only 64K

3) found the first 16bytes of my dump over the offical bin .... and they are at 0x2000, then search for my dump 0x2000 16 bytes and found at 0x0000, then again 16bytes of my dump at 0x4000 and found at 0x6000 and 16 bytes of my dump at 0x6000 and found at 0x4000 ... so on

 

Aside from issue 2, it seems like the "official" dump has the 16K pages content swapped at the 8K boundary.

 

So I used HxD to simply split the offical 128K BIN andat 8KB, ended up with 16 files, then joined them as file1,file0,file3,file2,file5,file4,file7,file6,file9,file8,file11,file10,file13,file12,file15,file14 ..... basically swapping hi and low 8K on each page.

 

 

I did the exact same on Double Dragon (not sure if this is 64K or 128K as I don't have the original).

 

Anyway the 8K swapped BIN now works like a charm on an EPROM..... yippi!!!!!

 

 

I don't really know if rampage is 64K or 128K, but my dump is 64K x2 for sure while the official dump looks different in the high and low 64K.

Given my purpose was to make a multi, I am good by 8K swapping the "official" dump and be done.

 

I only played a little on the first level of both Rampage and Double Dragon and I don't see any issue so I call it good.

 

I guess bankswitching for Activision game could have been kind of wrong all along in the emulators, not sure how the official dump got the 8K pages swapped unless the actual maskROM is tricky and one of the address line (A13 I believe) is active low ... you know as a sort of "copy protection" ... in which case it is my dump being swapped ... but then again to make EPROM replacements to be used on the same Activision PCB I either validate the /A13 (and add an inverter there) or simply swap the content as I did.

 

Anyway here you have it .... a way to build the last of the multi!!!!!

Edited by phoenixdownita

Share this post


Link to post
Share on other sites

Chatting with RevEng a couple of days ago, I came to the same conclusion, the dump and emulators are wrong. I simply reverse engineered the logic in the PLD, according to the pinout you posted, it's really quite simple. Glad you got it working and I don't have to spend any more time on it. :thumbsup:

 

Do you have the means to dump the PLD? I don't have either of those carts available. I do not believe the 16R4 has a security fuse, so you should be able to read it.

Share this post


Link to post
Share on other sites

Chatting with RevEng a couple of days ago, I came to the same conclusion, the dump and emulators are wrong.

Dumps, emulators, and documentation on the format. :(

Share this post


Link to post
Share on other sites

...

 

Do you have the means to dump the PLD? I don't have either of those carts available. I do not believe the 16R4 has a security fuse, so you should be able to read it.

 

Not sure, both by EPROM burners seem to balk at the PLD section, so I'd say likely no.

Also I did not desolder the PAL, only the ROM so it's not that I can just give it a shot.

 

But if I have to venture a guess when W is low and A15/A14/A13 match whatever hotspot Activision uses, then they capture A2/A1/A0 as the bank number and store it in the flip flops at the PAL.

From there on out at least one of the 16K must be coming from the stored bank number, not sure which part is instead fixed and the PAL simply leaves A15/A14 untouched (not sure what A16 would be for that case, but if I have to guess I'd say 0 [if rampage ends up being really only 64K it makes sense]).

 

I still think it could be worthy to attempt to reverse eng the PAL, that way you'll probably be the only one capable of repro Activision carts.

(F18 as I said is very weird, it has no flip-flop or latches and yet according to doc it can do paging ?!?)

Edited by phoenixdownita

Share this post


Link to post
Share on other sites

 

Not sure, both by EPROM burners seem to balk at the PLD section, so I'd say likely no.

Also I did not desolder the PAL, only the ROM so it's not that I can just give it a shot.

 

But if I have to venture a guess when W is low and A15/A14/A13 match whatever hotspot Activision uses, then they capture A2/A1/A0 as the bank number and store it in the flip flops at the PAL.

From there on out at least one of the 16K must be coming from the stored bank number, not sure which part is instead fixed and the PAL simply leaves A15/A14 untouched (not sure what A16 would be for that case, but if I have to guess I'd say 0 [if rampage ends up being really only 64K it makes sense]).

 

I still think it could be worthy to attempt to reverse eng the PAL, that way you'll probably be the only one capable of repro Activision carts.

(F18 as I said is very weird, it has no flip-flop or latches and yet according to doc it can do paging ?!?)

 

I was just wondering, I can figure it out without a dump. I am not really interested in being able to make repros, just interested in the logic.

 

And yes, the A0, A1 and A2 bits are latched onto the upper address bits.

 

Some ROM's have logic in them (see Atari 2600), they don't need extra TTL chips.

Share this post


Link to post
Share on other sites

 

Is the above the original dumps?

 

attachicon.gifDoubledragon.zip

 

attachicon.gifDoubledragonPAL.zip

 

Yep, that NTSC BIN was my starting point. (I validated your ZIP with the file I used and they matched exactly).

 

I do not know the policy about posting ROM dumps, so you may want to take them down.

 

If I get permission I can post my 8K swapped BIN though the instructions are pretty clear and using HxD is trivial.

 

Keep in mind that you still need the Activision PAL for this to work, that's why I used as a base the PCB of Rampage.

Maybe you can quickly reverse engineer the PAL and make it out discreet component, I believe a 565 would do (or even a 339) with the appropriate rerouting (A0/A1/A2 instead of D0/D1/D2 to the 373/374) .... just a thought here.

Share this post


Link to post
Share on other sites

I have a loose Double Dragon board. Maybe I should unsolder the PAL chip and see what I get.

 

Mitch

Share this post


Link to post
Share on other sites

I believe a 565 would do (or even a 339) with the appropriate rerouting (A0/A1/A2 instead of D0/D1/D2 to the 373/374) .... just a thought here.

 

Not unless you modify the code, it isn't just about those 3 lines, it's also about the address decoding. Which Atari is doing like this: A15 & !A14 (plus the WE and CLK decoding).

 

You need something like A15 & A14 & A13 for this scheme. The documented hotspot definition is only partially correct, you can tell by the schematic. ;)

Share this post


Link to post
Share on other sites

I have a loose Double Dragon board. Maybe I should unsolder the PAL chip and see what I get.

 

Mitch

As you are at it you should also unsolder the ROM and dump it to see what you get, mainly to check if Double Dragon is 64K or 128K.

If it turns out it is 64K it means Activision bankswitching, although it supports 128K, never really used it.

You will dump 128K no matter what (as a 27C301) but if the first 64K and the second 64K are identical ....

 

On a side note even the 2 banks are identical it may still mean there are actually 2 copies back to back in the ROM, I have no way to identify if the ROM is a 64K or a 128K.

 

The rig I built to dump Rampage is trivially simple, just one 32pin socket and one piece of core wire (in my case the cut part of a resistor ending after soldering).

As reported dump it as a 27C301, my EPROM burner SW complained 2 pins were not connected [2 and 31] and I let them be safely ignored [they are /OE and /PGM on the EPROM, none is needed for reading the actual ROM].

The wire you see in the picture goes from socket hole 32 to hole 30 (I tucked it in enough just to have continuity, it is not soldered) as pin 32 is Vcc on the EPROM while 30 is nc for a 27C301, but for the actual ROM pin 28 is Vcc (and it sits in socket hole 30).

 

[disclaimer: this method of rigging only works for 27C301 as the nc pin matches the Vcc of the ROM and the rest is an exact match of the actual maskROM, and it's easy to write up the actual Vcc of the 27C301 to the Vcc of the maskROM, don't try it with a 27C010/020/040/080 ....]

post-36731-0-00096600-1402807871_thumb.jpg

Edited by phoenixdownita

Share this post


Link to post
Share on other sites

I believe cause a logic analyzer, will reveal all the truth about logic's of the little pal pld.

Share this post


Link to post
Share on other sites

As you are at it you should also unsolder the ROM and dump it to see what you get, mainly to check if Double Dragon is 64K or 128K.

If it turns out it is 64K it means Activision bankswitching, although it supports 128K, never really used it.

You will dump 128K no matter what (as a 27C301) but if the first 64K and the second 64K are identical ....

 

On a side note even the 2 banks are identical it may still mean there are actually 2 copies back to back in the ROM, I have no way to identify if the ROM is a 64K or a 128K.

 

The rig I built to dump Rampage is trivially simple, just one 32pin socket and one piece of core wire (in my case the cut part of a resistor ending after soldering).

As reported dump it as a 27C301, my EPROM burner SW complained 2 pins were not connected [2 and 31] and I let them be safely ignored [they are /OE and /PGM on the EPROM, none is needed for reading the actual ROM].

The wire you see in the picture goes from socket hole 32 to hole 30 (I tucked it in enough just to have continuity, it is not soldered) as pin 32 is Vcc on the EPROM while 30 is nc for a 27C301, but for the actual ROM pin 28 is Vcc (and it sits in socket hole 30).

 

[disclaimer: this method of rigging only works for 27C301 as the nc pin matches the Vcc of the ROM and the rest is an exact match of the actual maskROM, and it's easy to write up the actual Vcc of the 27C301 to the Vcc of the maskROM, don't try it with a 27C010/020/040/080 ....]

 

Yes, I've dumped these chips before but thanks for the detailed write up.

As it happens, CPUWIZ wants to test the board so I'm loaning it to him to check out.

 

Mitch

Share this post


Link to post
Share on other sites

 

Yes, I've dumped these chips before but thanks for the detailed write up.

As it happens, CPUWIZ wants to test the board so I'm loaning it to him to check out.

 

Mitch

 

Awesome, we will get to that PAL once and for all ;-)

 

Sorry for the write up, given that the "official" dump is wrong I just wanted to make sure we're all doing the same process, didn't intend to be schooling anyone.

Share this post


Link to post
Share on other sites

The last of the multi, the Activision multi.

 

I hope CPUWIZ manages to dump the PAL as this one is tricky due to the scarcity/price of donor carts ... and yeah Double Dragon is hard as hell.

post-36731-0-88447200-1403372377_thumb.jpg

Edited by phoenixdownita
  • Like 1

Share this post


Link to post
Share on other sites

Totally uncorrelated post (not Atari related) and really just patting myself in the back with both hands and boasting here ....

but couple of weeks ago I got an Amstrad GX4000 and Burnin'Rubber and "obviously" made a universal multi out of it.

 

GX-4000 games (all 25 of them ;-) ) are 128K [or that is what I found around].

The original cart (Burnin'Rubber) contained a 27C1001 which is a 27C010 pre standardization of the naming.

 

So (like for the Atari 7800 multi 128K) I planned to swap it with a 27C801 (or 27C080) to get myself an 8-in-1.

 

Because it is hard for me to come by with cheap donor carts, instead of replacing the EPROM inside I fabricated "an extension" protruding from the top of the cart and put a ZIF socket there.

So now I can change the EPROM when I want and of course already burnt 3 27C801 with 23 games + 1 "patched" OS (just to see the start screen as GX-4000 has no keyboard so not much use of the CPC+ OS). There are also 2 gun games around but given I am in NTSC land and the games are PAL there's no way for me to play them, and I don't even know how to find a gun or adapt an XG-1 or Sega Phaser. [At present I am using a very cheap Composite to HDMI converter that happens to convert PAL to 1080p-50Hz and my current LCD TV is fine with that, that's how I can even use a GX4000 in NTSC land].

 

I got the info I needed from:

http://www.cpcmania.com/Docs/GX4000/GX4000.htm

http://www.cpcmania.com/GX4000-Games/Games.htm

http://www.cpcwiki.eu/index.php/GX4000_cartridge

 

Anyway, because this post is about egotism and being self-conceited I attach a picture to satisfy my own arrogance.

post-36731-0-06775600-1403408710_thumb.jpg

Edited by phoenixdownita
  • Like 1

Share this post


Link to post
Share on other sites

To the OP: I'm very impressed with how far you took all the multicart stuff so quickly. You took on a task, learned the game and starting hitting them out of the park in no time flat. :thumbsup:

Share this post


Link to post
Share on other sites

The PLD is read protected.

 

Damn it.

 

Next step is to dump the ROM to see if it is really 64K or 128K.

 

In any case I have faith that RevEng an figure out the hotspot from the code, and the logic of bank-switching cannot be too complex after that, emulators got it wrong but likley only at 8K swapped pages so it should be possible to mock a compatible scheme that works with both games.

[who cares if it is the exact same or only good enough for those 2, there's no extra Activision game anyway]

Edited by phoenixdownita

Share this post


Link to post
Share on other sites

When I have more time, I will just stick the PLD in a breadboard and tickle the input lines with all combinations.

Share this post


Link to post
Share on other sites

Next step is to dump the ROM to see if it is really 64K or 128K.

 

In any case I have faith that RevEng an figure out the hotspot from the code, and the logic of bank-switching cannot be too complex after that, emulators got it wrong but likley only at 8K swapped pages so it should be possible to mock a compatible scheme that works with both games.

[who cares if it is the exact same or only good enough for those 2, there's no extra Activision game anyway]

Since I'm the one who wrote the cartridge reader software and therefore am responsible for the layout of those two ROMs, maybe I should explain why I chose the bank order to be the way it is.

 

At the time I didn't have either game, so I had a friend who did, dump the entire ROM space from $4000 to $ffff for me. I then had a look at the code and found that they both do sta $ff80,x in the initialization routine, which I assumed would trigger the bankswitching. So I had the friend dump the entire ROM space from $4000-$ffff again while writing to $ff8x first. I had a look at the 16 resulting ROM images and found that only 8 of them were different, and that the difference was always at $a000-$dfff. Therefore I wrote the cartridge reader routine for 78AC bankswitching to read 8 banks from $a000-$dfff, simply because it was easier to read 16K in one go than to read 2 times 8K. Yes, I'm that lazy. ;)

 

Of couse it's entirely possible that the ROM in the cartridge has the 8K parts of each bank reversed from what DevOS returns. And from your research it's very likely that the bankswitching logic would react to any address above $8000. The games only use $ff8x though. And from my experience they both are 128K.

 

If you can come up with a bankswitching logic that uses the inputs and outputs you found on the PLD that maps bank 6 at $4000-$7fff, the lower half of bank 7 at $8000-$9fff, the higher half of bank 7 at $e000-$ffff, the higher half of each bank at $a000-$bfff, and the lower half of each bank at $c000-$dfff, then that would probably be pretty close to what the PLD really does.

 

But if you really want to be sure, you could try to find Kevin Cooper and ask him. From the Rampage ROM:

 

"RAMPAGE - Trade Mark and Copyright Bally Midway --- Ported to Atari 7800 by Spectral Dimensions, Inc. EngineeringDesign Services - Atlanta, GA (404)442-8025 --- Programming by Bill Hawkins and Clay Turner of Spectral Dimensions, With many thanks to all the great people at Mediagenic/Activision - Tom Sloper and Perry Rodgers for their guidance and ideas - Glyn Anderson for his fine technical reference - Kevin Cooper for his novel bank switching design, as well as prototype RAM and EPROM cartridges - Steve Snyder for his artwork - Steve Imes for his in-depth testing which revealed more bugs than I care to admit. - and Luis Rivas, whose bulletin board service saved us untold dollars in Federal Express fees. -- Also Dave Staugas of Atari for the many software tools used in this development - and Jose Valdes of Atari for the design of the supercart development board. --- "

Share this post


Link to post
Share on other sites

Since I'm the one who wrote the cartridge reader software and therefore am responsible for the layout of those two ROMs, maybe I should explain why I chose the bank order to be the way it is.

 

At the time I didn't have either game, so I had a friend who did, dump the entire ROM space from $4000 to $ffff for me. I then had a look at the code and found that they both do sta $ff80,x in the initialization routine, which I assumed would trigger the bankswitching. So I had the friend dump the entire ROM space from $4000-$ffff again while writing to $ff8x first. I had a look at the 16 resulting ROM images and found that only 8 of them were different, and that the difference was always at $a000-$dfff. Therefore I wrote the cartridge reader routine for 78AC bankswitching to read 8 banks from $a000-$dfff, simply because it was easier to read 16K in one go than to read 2 times 8K. Yes, I'm that lazy. ;)

 

Of couse it's entirely possible that the ROM in the cartridge has the 8K parts of each bank reversed from what DevOS returns. And from your research it's very likely that the bankswitching logic would react to any address above $8000. The games only use $ff8x though. And from my experience they both are 128K.

 

If you can come up with a bankswitching logic that uses the inputs and outputs you found on the PLD that maps bank 6 at $4000-$7fff, the lower half of bank 7 at $8000-$9fff, the higher half of bank 7 at $e000-$ffff, the higher half of each bank at $a000-$bfff, and the lower half of each bank at $c000-$dfff, then that would probably be pretty close to what the PLD really does.

 

But if you really want to be sure, you could try to find Kevin Cooper and ask him. From the Rampage ROM:

 

"RAMPAGE - Trade Mark and Copyright Bally Midway --- Ported to Atari 7800 by Spectral Dimensions, Inc. EngineeringDesign Services - Atlanta, GA (404)442-8025 --- Programming by Bill Hawkins and Clay Turner of Spectral Dimensions, With many thanks to all the great people at Mediagenic/Activision - Tom Sloper and Perry Rodgers for their guidance and ideas - Glyn Anderson for his fine technical reference - Kevin Cooper for his novel bank switching design, as well as prototype RAM and EPROM cartridges - Steve Snyder for his artwork - Steve Imes for his in-depth testing which revealed more bugs than I care to admit. - and Luis Rivas, whose bulletin board service saved us untold dollars in Federal Express fees. -- Also Dave Staugas of Atari for the many software tools used in this development - and Jose Valdes of Atari for the design of the supercart development board. --- "

Hi, nice meeting you.

 

Regarding Rampage size the only thing I can say is that I dumped the physical ROM as a 27C301 and noticed that the 2 64KB halves are identical.

I chickened out once it came to actually program the EPROM, instead of my dump I simply did the 8KB swap of your dump and used that, if it worked on emulator it was worth a try on real EPROM.

Given that it worked I didn't look back.

If I have a little time I may just try to use my dump to see if it works. Given A16 is connected to the PAL I need to have 128KB (as I am using a 27C020), the original ROM may have been 64KB and at that point A16 is unconnected hence the 2 identical 64KB banks.

It is a little speculative, but I doubt I messed up so badly the rig to dump the ROM (it's literally 1 wire http://atariage.com/forums/topic/224038-multicarts-suggestions/page-3?do=findComment&comment=3010980)

 

Thanks for chiming in, it must have been like going back in time ;-)

Edited by phoenixdownita

Share this post


Link to post
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.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...