Time Machine

[JetSetIlly]

Has anyone had any thoughts about how Time Machine will work with this?

 

Personally, I'm not sure it can work except with 2k/4k cartridges. In all other instances the cartridge has a state which can't be captured by the emulator. I suppose in some instances, the state can be recreated (eg. the correct bank selected) after the TimeMachine event but that would require the emulator being in full knowledge of what the bank switching method was. It's possible in those instances but tricky to get right I suspect.

 

Any other thoughts on this?

[Thomas Jentzsch]

We could try to identify the correct bankswitching on-the-fly. Then we should be able to recreate the cart state. But detection and state recreation will become complex. And probably not work in all cases.

[JetSetIlly]

Just now, Thomas Jentzsch said:

We could try to identify the correct bankswitching on-the-fly. Then we should be able to recreate the cart state. But detection and state recreation will become complex. And probably not work in all cases.

Yes. I think in some cases it'll be impossible - I can't see anyway of recreating an ARM program state, for example. But it would be an interesting exercise to figure out the limitations.

[+MarcoJ]

18 hours ago, JetSetIlly said:

Any other thoughts on this?

I think for 2k/4K Time machine should work currently. For bank switching and RAM carts, I think not, at least with the management model Stella uses. If I remember correctly, Stella manages its own backend model of the state of current bank and the RAM in the cart, rather than using the peek and poke commands to control a virtual cartridge model. The CartridgePort driver uses a 4K model where Stella is blind to what is happening inside the cart, but is permissive of all reads and writes to various memory spaces following the regular rules of data routed to TIA, 6532 and cartridge space. This is basically the Atari 2600 to be honest. For time machine to work, Stella would need to know the bank switching type, have its own backend model of the cart state for storing the time machine data, plus actually writing back to the cart to control the bank switching state and memory contents when a desired time in history is arrived upon. The reading and writing back to the cart would need to follow the same speed rules as regular execution (might be somewhat slow to move back and forth in time). Some bank switching schemes that need JSRs to work might be difficult for Stella to change on call, but bank switching types that change by accessing a memory location should be ok.

[+Al_Nafuur]

On 10/19/2023 at 6:31 PM, JetSetIlly said:

Has anyone had any thoughts about how Time Machine will work with this?

 

Any other thoughts on this?

Detecting which banking is used inside the cartridge is really difficult to tell for the 2600. AFAIK the Time Machine is mostly used by developers for debugging, so maybe giving them an interface to peek/poke addresses individually (or via a batch-script?) can help the developer to bring the cartridge (RAM, banking, etc.) into the state he wants it or debug its current state.

 

 

[JetSetIlly]

Just now, Al_Nafuur said:

Detecting which banking is used inside the cartridge is really difficult to tell for the 2600.

I would say that it's impossible for a real 2600 to differentiate between bank switching schemes. But for RTStella I would argue it's possible. One way would be to dump the cartridge (just 4k will do I think), examine it to decide on the scheme and then discard the dump*. That way the emulation knows the scheme in use but accesses the cartridge in the realtime manner.

 

* The cartridge would need to be reset in case the state was changed during the dumping process

 

Building up the information required to differentiate bank switching schemes as the program is actually run would be possible, but awkward to code I would imagine.

 

5 minutes ago, Al_Nafuur said:

AFAIK the Time Machine is mostly used by developers for debugging, so maybe giving them an interface to peek/poke addresses individually (or via a batch-script?) can help the developer to bring the cartridge (RAM, banking, etc.) into the state he wants it or debug its current state.

Yes. I think a development interface is an idea worth exploring

 

[Thomas Jentzsch]

21 hours ago, JetSetIlly said:

Building up the information required to differentiate bank switching schemes as the program is actually run would be possible, but awkward to code I would imagine.

The CartPort class would have either to scan the data read from the ROM for known pattern or "somehow" find out that a bank got switched.

 

The former doesn't seem too complicated, but will of course not work for all ROMs. Also the same approach could be used for detecting controllers used by the ROM. And Stella's pattern based detection is quite good for both. If you look at the Stella.pro file, there are not that many games which require bankswitching (mostly Xin1 ROMs) or controller type properties.

 

The latter seems much more complicated. How can the code identify a bank switch? It could store and compare the read data. If data changes, then it could be RAM or bank switched ROM (or RAM too). Then the code would have to look back and find out which instruction might have caused the bank switching. I am not sure if this approach is even feasible. Or are there any better ideas?

 

BTW: Using Stella's properties wouldn't work, since they are based on the checksum of the whole ROM. Maybe one could generate a checksum based on code executed when the ROM gets started. But that has also quite some problems.

Edited November 1, 2023 by Thomas Jentzsch

[JetSetIlly]

1 minute ago, Thomas Jentzsch said:

The latter seems much more complicated. How can the code identify a bank switch? It could store and compare the read data. If data changes, then it could be RAM or bank switched ROM (or RAM too). Then the code would have to look back and find out which instruction might have caused the bank switching. I am not sure if this approach is even feasible. Or are there any better ideas?

I meant building up the fingerprint profile as the program is being run. Once enough data has been accumulated a decision on the bank switching scheme can be made. The problem with this is that the key fingerprint information may never be seen as a result of execution; and there will be small delay before the scheme is known.

 

Partial dumping of the cartridge is far easier.

 

4 minutes ago, Thomas Jentzsch said:

How can the code identify a bank switch?

The only way you could do that I think, is to emulate the cartridge in parallel with the real cartridge. In this arrangement, the real cartridge is the source for all read data but the effects of all memory accesses are also run through the cartridge emulation and a record of the current state is kept. Then, if the game play is rewound, the state can be restored in the real cartridge before resuming execution.

 

In most cases I believe the state can be restored - the only state most vintage cartridges have, at most, is the current bank and cartridge RAM. But for those which have state which is not directly accessible via the cartridge interface (eg. Pitfall2/DPC) it should be possible to resume execution from the rewind point using the cartridge emulation only. Once the state in the cartridge emulation matches the state in the real cartridge (ie. the last state seen before the rewound took place), "full" execution using the real cartridge can resume. However, I'm absolutely sure there are corner cases where this wouldn't work as expected.

 

In a general sense I don't believe ARM programs can be rewindable. However, for development purposes it might be feasible to arrange a side-channel to allow communication between the debugger and the ARM program. This would allow the ARM programmer to put the ARM program into a known state. This would have to be established by the programmer on a game-by-game basis but a development library for the ARM could be developed to standardise the basic protocol.

[Thomas Jentzsch]

Good ideas, but quite complex. Overall it seems like a lot of work. 

Edited November 1, 2023 by Thomas Jentzsch