I used to have an Action Replay 6, and you could hit the freezer button, 
and dump all memory and registers, and hardware to a snapshot file.

How is this possible? Surely if you unpack 64KB of data, there's no memory 
left to store the hardware registers (which must be at least 2KB).

Then when it's done unpacking, you have to restore the stack and jump to 
the address, again without extra RAM.

Any responses would be helpful, and can go in the Wikipedia entry for 
freezers so others can learn.

Jeremy.

"Jeremy Smith" <nospamjeremy@decompiler.org> wrote in message 
news:Xns9D02BC9FACE74jeremyalansmithsofth@216.196.109.145...
> How is this possible? Surely if you unpack 64KB of data, there's no memory
> left to store the hardware registers (which must be at least 2KB).

I believe most freezer cartridges had, e.g., 8K of RAM in the cartridge itself 
to directly address this problem, although even without extra RAM in the 
cartridge I wouldn't be surprised if some little algorithm could peek around 
memory a bit and try to find, e.g., 128 bytes or so -- enough for a tiny 
memory unpacker/mover -- that appeared to be unused and just use that as the 
"last outpost" of the image restoration.

In general freezers weren't 100% perfect anyway, as I recall -- some registers 
of VIC or SID couldn't be read directly, although there were clever methods 
that would infer their values indirectly.  (I.e., you could increment a timer 
a count at a time and have the overflow trigger an interrupt, so even if you 
didn't know the actual value, by counting how many increments it took to 
overflow it, you could infer the original value.)

---Joel

In article <Xns9D02BC9FACE74jeremyalansmithsofth@216.196.109.145>, 
nospamjeremy@decompiler.org says...
>I used to have an Action Replay 6, and you could hit the freezer button, 
>and dump all memory and registers, and hardware to a snapshot file.
>How is this possible?

Once upon a time I reverse engineered the old ISEpic cartridge, (one of the 
first freezer/dump carts available for the 64), in order to program it to 
save screen dumps of whatever was displaying on the 64 to to disk. It was a 
more primitive freezer than the later Action Replay, Super Snapshot etc. 
carts, but I believe it used a somewhat similar technique.

I recall the ISEpic cartidge had a 2K? RAM inside and a bit of glue logic. 
You downloaded the freezer program into the ISEpic to prepare for a 
snapshot as it didn't have any built-in ROM.

It had a switch on it that when set would cause a NMI (Non-Maskable 
Interrupt) on the CPU, temporarily map a page of cartridge RAM into the 
kernal space at $FFxx so that the NMI vector would be directed to the 
cartridge RAM located in the $C000(?) area of memory, and then bank a page 
of the cartridge RAM into that area by asserting a signal on the expansion 
port.

Although the cartridge had 2K? of RAM, I think only 1 or a few pages of 256 
bytes were accessible at a time, which made for some interesting 
programming.  It used a memory location to change the page that was mapped 
in at any time. Jumping to code between banks was done by having common 
code in all banks at the same memory locations that could be used to set 
the bank selection and continue executing at a specified address.

When the NMI was triggered, the code would get the state of the CPU & 
hardware registers, stack, etc. and save them in internal RAM. It also 
saved any display memory it was likely to need to show the the freezer 
program. Memory on this cartridge was tight!

I think the original ISEpic software ended up using the stack space beyond 
the saved stack pointer to run the final stages of the decompressor before 
returning control to the original program via RTI, so there were always a 
few bytes that it could not restore.

Later cartidges like the Action Replay used a similar banking technique to 
toggle their program ROM and RAM in and out of the C64 address space, but 
they had a lot more RAM.

Restoring the C64 to it's original state was a bit tricky, not only due to 
read-only registers, but also because the 1541 could be used as a 
programmable copyprotection watchdog.  I believe EA used a technique to 
prevent some of the early freezers/rippers from working correctly with 
custom loaders. It was hard to restore the custom code to the 1541 since it 
wasn't under your control.

 -Mark

On Jan 19, 1:58=A0am, Mark <m...@marks-labREMOVE.com> wrote:
> I recall the ISEpic cartidge had a 2K? RAM inside and a bit of glue logic=
..
> You downloaded the freezer program into the ISEpic to prepare for a
> snapshot as it didn't have any built-in ROM.

Which explains why I (still) need to make 5.25s from .d64s for the two
ISEPIC knock off carts I have... I never thought they'd use RAM
instead of ROM when I got them. I suppose they can be updated more
easily but it sure makes it a pain in the butt to upload every time...

Great but of work BTW.

In article 
<f782ee02-3f2e-4e0d-af66-0e733d3bd8e7@j19g2000yqk.googlegroups.com>, 
daniel.otoole@ucd.ie says...
>On Jan 19, 1:58�am, Mark <m...@marks-labREMOVE.com> wrote:
>> I recall the ISEpic cartidge had a 2K? RAM inside and a bit of glue logic.
>> You downloaded the freezer program into the ISEpic to prepare for a
>> snapshot as it didn't have any built-in ROM.
>
>Which explains why I (still) need to make 5.25s from .d64s for the two
>ISEPIC knock off carts I have... I never thought they'd use RAM
>instead of ROM when I got them. I suppose they can be updated more
>easily but it sure makes it a pain in the butt to upload every time...

It's possible to add a diode or two and 2.5-3V battery to the cartridge to 
have it save the contents of the RAM for as long as the battery holds out.  
The CMOS static RAM would only draw a few microamps when not being used. I'd 
expect the battery to last for weeks at least. Found a schematic using NiCd 
here: http://schematics.dapj.com/2006/10/battery-backup-for-sram-or.html
You'd have to cut the +5V power between the RAM and the rest of the circuit 
to insert the battery backup.   (Probably not worth it....)

Cheers,

  -Mark

On Jan 21, 12:55=A0am, Mark <m...@marks-labREMOVE.com> wrote:
> It's possible to add a diode or two and 2.5-3V battery to the cartridge t=
o
> have it save the contents of the RAM for as long as the battery holds out=
.. =A0
> The CMOS static RAM would only draw a few microamps when not being used. =
I'd
> expect the battery to last for weeks at least. Found a schematic using Ni=
Cd
> here:http://schematics.dapj.com/2006/10/battery-backup-for-sram-or.html
> You'd have to cut the +5V power between the RAM and the rest of the circu=
it
> to insert the battery backup. =A0 (Probably not worth it....)


Or maybe just make a ROM chip with the software and replace the
RAM? :-)

There are non-volatile Static RAM chips out there.. (I've recently used
a Dallas DS1230Y as a EPROM replacement in a system here..)

-- 
Chris