New snap format that convenient for view/modify

[ZXDunny]

I would like to ask why you're not using an emulator that has a decent debugger/memory viewer built in which lets you examine RAM and make changes and then you can save your stuff out as whatever snapshot format you want.

[Weiv]

If you want to have yet another new snapshot format that no-one supports the usual route is to write another emulator.

Already)

Or you could write a converter from szx but in that case you may as well put your coding effort into an szx viewer/editor that might be useful

This is not our method) But my emulator can be such a converter, of course.

Yay, arbitrarily assigned machine configuration bitfields too! Speed-running all the mistakes of the last 30 years of emulator snapshots like we've never learned anything.

So what you have to offer instead?

[Weiv]

I would like to ask why you're not using an emulator that has a decent debugger/memory viewer built in which lets you examine RAM and make changes and then you can save your stuff out as whatever snapshot format you want.

Of course this is prefer way. But sometimes you just need to view/explore/modify snapshots outside of an emulator - for example with more powerful or functional outside tool. Or you need to view/modify a snapshot quickly in hex viewer/editor. Or you need to compare several snapshots.

[Guesser]

So what you have to offer instead?

Use szx because it's not perfect but most of the bugs caused by confusing design issues have been squashed out of everyone's implementation by now.

Or create something new where every piece of configuration and memory block is its own block with extensible tags so no-one has to guess what something is based on its position ever again.

If I ever write an emulator I think make it store its snapshots in a big ol' json file full of base64 encoded memory banks to annoy everyone equally

[Weiv]

Use szx because it's not perfect but most of the bugs caused by confusing design issues have been squashed out of everyone's implementation by now.

But szx is not viewable/explorable/modifiable almost at all.

Or create something new where every piece of configuration and memory block is its own block with extensible tags so no-one has to guess what something is based on its position ever again.

Why guess if there is a specification. Also that bitfield is mostly not for viewing/modifying.

If I ever write an emulator I think make it store its snapshots in a big ol' json file full of base64 encoded memory banks to annoy everyone equally

It was not my goal basically)

[Guesser]

Why guess if there is a specification.

Luckily emulator authors are always very well behaved when implementing snapshot export code, so finding snapshots with data stuffed into unused/reserved bits from an original specification to support extra hardware for their particular emulator basically never happens!

(I didn't really mean guess, someone spoke to me while I was writing the reply and I lost my train of thought. I just meant having a load of jumbled hardware settings stuffed into bit fields are annoying. Especially when they end up split up in different places because the format gets extended but is all based on fixed width fields so the second lot of settings gets added way later in the file somewhere else entirely)

Also that bitfield is mostly not for viewing/modifying.

I thought the whole point of this format was that you could easily read and modify the content in a hex editor...

[Weiv]

Luckily emulator authors are always very well behaved when implementing snapshot export code, so finding snapshots with data stuffed into unused/reserved bits from an original specification to support extra hardware for their particular emulator basically never happens!

Maybe sometimes. I don't know. I use simple rule - if it is not in specification I don't guess about it.

I just meant having a load of jumbled hardware settings stuffed into bit fields are annoying. Especially when they end up split up in different places because the format gets extended but is all based on fixed width fields so the second lot of settings gets added way later in the file somewhere else entirely

I doubt that it will be in this case. I'm sure that 32 bits is enough for my purposes. But if it wil be needed - yes, I can add another bit field in other place. I don't see this as a big problem. Anyway this format will not be as good as some text format, right?

I thought the whole point of this format was that you could easily read and modify the content in a hex editor...

Yes, but not for system configuration, as it not much important data to view/modify commonly. Also I'm pretty able to find needed bit in hex-viewed bitfield.

[Weiv]

I have implemented the first edition of SNV format in my emulator, and - I like how it looks in hex viewer:
https://zx-pk.ru/attachment.php?attachm ... 1692037715

Specified configuration flags for now:
snv8kbPages = $80000000;
snvLongPageNumbers = $40000000;
snvLateTimings = $00000001;
snvCMOSZ80 = $00000002;
snvIssue2 = $00000004;
snvMainAYpresent = $00000008; // Didaktik Melodik for 48kб, can be off for 128kb

[Lethargeek]

I would like to ask why you're not using an emulator that has a decent debugger/memory viewer built in which lets you examine RAM and make changes and then you can save your stuff out as whatever snapshot format you want.

are there any? it is either:
- not enough features
- window is too small/big/wrong shape
- odd behaviour/plain buggy
etc etc

[equinox]

I would like to ask why you're not using an emulator that has a decent debugger/memory viewer built in which lets you examine RAM and make changes and then you can save your stuff out as whatever snapshot format you want.

Become a part of our talent community. Explore Careers at SpecBasCo