WRITE NOW! cartridge image problem

[mathom]

I'm having a problem trying to get a good cartridge image for WRITE NOW!. The one that is available at zimmers differs from the actual cartridge image and exhibits several bugs. The image I have dumped from the cartridge will not run when loaded into RAM nor will it run on the FE3 even when protecting block 5 memory after loading. I'm guessing it is some sort of copy protection scheme but whatever they are doing beats me. When trying to run from the image I created the splash screen flashes on screen for a fraction of a second and then returns to the "ready" prompt. So far my attempts at tracing execution and reverse engineering have come up empty. I'm afraid it is a bit over my head.

Any help arriving at a solution would be greatly appreciated.

The image in the zip file is a .prg that begins with the loading address. The cartridge is run by typing "sys 41000".

The one weird (to me) thing that I did turn up with a binary diff is that the only differences between the zimmers image and the one I dumped is that 57 occurrences of the byte $9B in my dump have been replaced by the byte $BB in the zimmers image.


(mod: thread moved from General section to Collecting and History section)

[Mike]

[...] 57 occurrences of the byte $9B in my dump have been replaced by the byte $BB in the zimmers image.

$9B is a somewhat complicated 'illegal' memory store opcode (TAS ABS,Y according to 6502.org), which copies the Accu ANDed with the X register into the stack pointer S, then ANDs that intermediate value with the high byte + 1 of the (un-indexed!) operand and then stores the final result at address ABS,Y. This last action, when done on the cartridge ROM will inevitably thrash a soft-loaded copy.

$BB instead is an 'illegal' memory load opcode (LAS ABS,Y) with somewhat similar action on the registers: it ANDs the contents of the memory location with the stack pointer S and stores the result in the Accu, X register and stack pointer S. This gives not exactly the same side effects on the registers (the AND with high byte + 1 is missing), but at least it does not overwrite a soft-loaded version.

Depending on where the $9B opcodes point to, they might also access the I/Ox area, interfering with FE3 registers there, and causing crashes.

Will take a more thorough look at your dump the next days. The TAS opcodes likely use their side effects on A and X to prepare them with values but any code also likely needs to restore the stack pointer S afterwards. There's an opportunity to tame them, let's see ...

[Mike]

Update: not illegal opcodes are the issue here, but the code seems to access the address range $9800..$9FFF in several places.

Either the dump is incomplete, or - more likely - the cartridge uses some logic to mirror the ROM data in $B800..$BFFF down to $9800..$9FFF. The patches in the zimmers dump do not cover all necessary changes to make the program self-contained in $A000..$BFFF, which leads to the bugs you noticed.

Mathom, could you please provide a dump of the address range $9800..$9FFF to confirm the mirroring hypothesis (or, in case, complete the dump):

Code: Select all

SYS57809"WN DUMP 2.PRG",8:POKE193,0:POKE194,152
POKE780,193:POKE781,0:POKE782,160:SYS65496

[mathom]

That's the trick! There is indeed stuff stored in IO memory ($9800 - $9BFF). If I load a dump of that into Vice along with the image from $A000 - $BFFF it works as it should. Thank you, Mike!

Attached is the dump from $9800 - $9FFF ("wn dump 2.prg.zip") and "wn-full.prg.zip" contains a dump from $9800 - $BFFF. If you enable I/O ram in vice you can load everything at once and get a working program with SYS41000.

wn dump 2.prg.zip

(1.39 KiB) Downloaded 29 times

wn-full.prg.zip

(6.47 KiB) Downloaded 29 times

Out of curiosity I opened the cartridge. Here is what I found:

[groepaz]

Cool, will add a cartridge type for this one to vice

Mike: is it a common setup for carts to mirror the last part of the rom to i/o? if so, what would be a better name for this than naming it after the cartridge (which is what we usually do)... "cardco"?

[Mike]

[...] is it a common setup for carts to mirror the last part of the rom to i/o?

Well, it's the first time I saw this, and it's clearly used as copy protection measure, not by any 'accident'. Blame the little 74LS02 bugger.

if so, what would be a better name for this than naming it after the cartridge (which is what we usually do)... "cardco"?

I'd suggest *.crt should simply be able to handle separate ROM chunks in either I/O2 or I/O3. Actually, with Write Now!, I/O3 is open, and it's just I/O2 that mirrors $B800..$BBFF to $9800..$9BFF. By adding a ROM chunk in I/O2 that contains the mirrored data, you get this cartridge covered (at a minor expense of duplicated data in the file).

[groepaz]

Well, it's the first time I saw this

ok, we can just use "write now" then

I'd suggest *.crt should simply be able to handle separate ROM chunks in either I/O2 or I/O3.

It can do that, using the "generic" type. What it can't do is mapping part of a ROM to I/O, you'll have to make a copy of the data.

By adding a ROM chunk in I/O2 that contains the mirrored data, you get this cartridge covered (at a minor expense of duplicated data in the file).

yes, you can (already) do this - i'd consider it a bit hacky though.

Ie in VICE we want to support the cartridge types more cleanly - in particular a raw ROM dump should also work, and a proper .crt file should not contain more than a plain rom dump either - hence dedicated crt id for it

[Mike]

[...] in VICE we want to support the cartridge types more cleanly [...]

Fair enough.

[groepaz]

I have added support for this now - please try r45649

I have also fixed (improved hopefully) the logic for mounting multiple raw binaries to the generic cartridge - would be nice if someone could test this a bit as well

[Mike]

In https://sourceforge.net/p/vice-emu/code ... writenow.c, you write:

- additionally the last 2KiB of the ROM are mapped to IO at 9800-9BFF

that should actually be: "- additionally the next-to-last 1 KiB of the ROM is mapped to I/O2 ($9800..$9BFF)"

From the mentioning of 2 KiB I first was about to ask whether the ROM also was mirrored to I/O3, which would have been a mistake and contrary to my post from Mar. 24, but the implementation itself looks fine.

[groepaz]

Ooops, correct. will fix