Welcome, Guest. Please login or register.


Author Topic: Xep128 (Read 25361 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 47.0 Firefox 47.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #195 on: 2016.July.26. 18:29:11 »
Important..... nah.

First of all, everything for users :D

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 :D 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 ...

Quote
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 :D Ok, just joking here.

Quote
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 ...

Offline gflorez

  • EP addict
  • *
  • Posts: 2663
  • Country: es
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 47.0 Firefox 47.0
    • View Profile
Re: Xep128
« Reply #196 on: 2016.July.26. 20:37:25 »
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.

And, on your hard way you are learning a lot, what maintains your enjoyment.........

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 47.0 Firefox 47.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #197 on: 2016.July.27. 08:36:08 »
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 :)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 47.0 Firefox 47.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #198 on: 2016.July.30. 13:10:17 »
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.

http://download.lgb.hu/travis/?repo=xep128

Download xep128.exe from "Build #17" (not the xep128 without extension, it's a Linux binary). You need 2.0.4 SDL2 DLL file, if you still have the 2.0.2, you need to download newer:

http://xep128.lgb.hu/files/SDL-2.0.4.dll

Rename it as "SDL2.dll". Loading a snapshot can be done with command line, ie:

xep128.exe -audio 1 -snapshot ...directory....\game.ep128s

Of course "-audio 1" is not compulsory (it just enables the lame audio support), also can be done in the config file, for sure (well, even the snaptshot option can be put into a config file but usually you don't want that for obvious reasons).

For sure, there are serve issues if a snapshot from ep128emu uses EXDOS/WD as Xep128 can't emulate that currently ...
« Last Edit: 2016.July.30. 13:41:44 by lgb »

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Xep128
« Reply #199 on: 2016.July.30. 14:11:17 »
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.

Quote
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.

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 47.0 Firefox 47.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #200 on: 2016.July.30. 14:19:49 »
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.

Yes, just currently I was "lazy" :) even with current LPB etc stuff. So I just restore the I/O registers and LPT address but not even the current LPB. Also with dave, state of latches etc are not restored. Currently only blocks  0x45508001, 0x45508002, and 0x45508003 are used, the rest are checked (for existence in the snapshot) but not used otherwise. As far as I can say, with testing some snapshots, it's already enough to deal with most of them, but surely it's very far from a perfect solution. It's just the initial work, not the final :)

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

Quote
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.

Yes, that's understandable after all ...
« Last Edit: 2016.July.30. 14:25:56 by lgb »

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 47.0 Firefox 47.0
    • View Profile
    • http://lgb.hu/
Re: Xep128
« Reply #201 on: 2016.July.30. 14:38:55 »
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.