Important..... nah.

First of all, everything for users

Second: I mean about the priority. It's quite possible that my priorities with Xep128 development is quite different as users would think It's often the case with software development ... Since developers are too much "in", viewing from inside, while users are really interested about the usage not the internal structure too much being bad or good if it works, it's good

With my "if it's important for you" i meant that it's always interesting see what users find useful with more priority to develop against other features.

Now I try to make OSX version just because it seems there is at least one user who would be interested For me, that's not so important as I don't use OSX. Same for Windows, I don't use Windows, but I guess it would be a huge limiting factor if I refuse Windows support ... So you see ...

Only that I would like to use more your emulator. There are "easy things" that we do with Ep128emu that we can't still do with XEP128. I only want your emulator be BIG.

it's big enough already with code complexity Ok, just joking here.

I understand the incompatibilities, it is wonderful to try to converge the two emulators, but Ep128emu is stalled and yours not. Sooner or later your emulator will be more actual. I think you must look for your own snapshot while maintaining some short of  legacy snapshot mode for backwards compatibility.

IstvanV's snapshot format is quite good one actually. it builds up from blocks (with type fields etc), so it's easy to extend with additional things, ep128emu can't emulate, ie state of SD card etc. If you have ep128emu snapshot loading in Xep128 _now_ it also means of course that you can't use SD card emulation neither :XEP stuffs as those are "private" to Xep128. However often it's not a problem and someone just wants to try something, then it's OK. Another thing is saving snapshot, is the opposite direction: if Xep128 is able to save snapshots it won't work too much with ep128emu, at least ep128emu would not care about XEP ROM code, SD card emulation, mouse, etc ... So, the inter-ermulator snapshot compatibility is limited by logical reasons, as you can see. However, surely, it can be still useful not to re-invent the wheel with my very own snapshot which is not compatible with ep128emu at all. OK, so in nutshell, I will support ep128emu snapshot format, though with the limitations caused by the nature of the problem of different emulators ...

For me is also important if you make an OSX implementation of XEP128. No mater if actually there is only one user of it. I think that  the best form of expandability of a program is its universality of use.

Don't get me wrong, it's important for me too, if for no other reason then for the challenge.  What I meant here however is that as "user" of my own work, I wouldn't use it, as I have no OSX, that's all

Now Xep128 can load ep128emu snapshots. Note, that it's still buggy as not everything is restored, ie internal dave/nick exact state, etc, only the I/O ports, memory and Z80.

Most of the time it would probably be enough to restore a few internal registers, such as the interrupt state in DAVE, and the current LPB, and line and slot count in NICK. By ignoring unsupported block types, it would also be possible to load demo files as snapshots.

For sure, there are serve issues if a snapshot from ep128emu uses EXDOS/WD as Xep128 can't emulate that currently ...

The WD state is not stored in snapshots, ep128emu just resets the floppy controller on snapshot load. Of course, this does not work if a snapshot is saved during a disk operation, but the lack of the original image file would cause problems then even if saving/restoring WD state was implemented.

And by the way, now Xep128 uses a bit different timing code.

First of all, the time difference measurement can use the "Xep128 classic" getimeofday() call (which we know is problematic on Windows, because of the bad precision of the emulation of this unix-style call) and an SDL method (that second one is used now by default). That uses  SDL_GetPerformanceCounter() call difference divided by the result of SDL_GetPerformanceFrequency(). This method seems to be architecture independent, at least the difference is at SDL level, that is not so my task to deal with the problem but SDL's.

Second, the actual sleeping. There is usleep() call, SDL's SDL_Delay() usage, and use of nanosleep() call. Currently on Linux and OSX nanosleep() is used, for Windows it's usleep (but probably that's only a call "emulated" by MingW for sure).

https://github.com/lgblgblgb/xep128/blob/master/main.c

functions  get_elapsed_time() and emu_sleep()

The next interesting development will be the audio buffer handling, ie taking account the audio buffer fill state to slightly modify the timing for real-time sync'ed audio which is not done yet. SDL 2.0.4 supports both of callback for audio buffer filling and "manual buffer queuing push" the later will be prefered I think, since you can even ask then about the real "amount of sent bytes to the hardware" (well or to the software if it's some kind of software audio layer eg with PulseAudio on Linux) information. I guess, this will result in better audio support than the callback version which is quite tricky to deal with the buffer status measurement values.

I am glad to see that LGB's useful web page is again active, or almost...

Yeah, I managed to found an older copy of the site. A more up-to-date one would need some kind of hdd-hospital it seem :-O

May be you can mix what you have with what is stored on the WayBackMachine.
Edit: But surely you already have thought on that...

Amazing!
I couldn't believe it was!
You saved my life

szipucsu, http://eprimo.lgb.hu/

Also just to mention I'm not so active unfortunately in Ep topics nowadays, since i'm busy with this: