Prev: The Commodore 64 - 1980's Number 1 computer
Next: Commodore file cabinets in North Florida $20 each
From: Jeremy Smith on 16 Jan 2010 13:32
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.
From: Joel Koltner on 16 Jan 2010 19:53
"Jeremy Smith" <nospamjeremy(a)decompiler.org> wrote in message
news:Xns9D02BC9FACE74jeremyalansmithsofth(a)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

From: Mark on 18 Jan 2010 20:58
In article <Xns9D02BC9FACE74jeremyalansmithsofth(a)216.196.109.145>,
nospamjeremy(a)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

From: DanSolo on 20 Jan 2010 12:47
On Jan 19, 1:58 am, Mark <m...(a)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...
From: DanSolo on 20 Jan 2010 12:48
Great but of work BTW.
 |  Next  |  Last
Pages: 1 2
Prev: The Commodore 64 - 1980's Number 1 computer
Next: Commodore file cabinets in North Florida $20 each