Welcome, Guest. Please login or register.


Author Topic: Xep128 (Read 114849 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • 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: 3615
  • Country: es
    • Támogató Támogató
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: 3563
  • Country: hu
  • æðsta yfirmaður
    • 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: 3563
  • Country: hu
  • æðsta yfirmaður
    • 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: 4822
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: 3563
  • Country: hu
  • æðsta yfirmaður
    • 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: 3563
  • Country: hu
  • æðsta yfirmaður
    • 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.


Offline gflorez

  • EP addict
  • *
  • Posts: 3615
  • Country: es
    • Támogató Támogató
Re: Xep128
« Reply #202 on: 2020.June.23. 17:20:23 »
I am glad to see that LGB's useful web page is again active, or almost...

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #203 on: 2020.July.01. 11:11:19 »
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

Offline gflorez

  • EP addict
  • *
  • Posts: 3615
  • Country: es
    • Támogató Támogató
Re: Xep128
« Reply #204 on: 2020.July.01. 11:46:03 »
May be you can mix what you have with what is stored on the WayBackMachine.

Edit: But surely you already have thought on that...
« Last Edit: 2020.July.01. 11:54:35 by gflorez »

Offline Tutus

  • EP lover
  • *
  • Posts: 692
  • Country: hu
    • Enterprise 128
Re: Xep128
« Reply #205 on: 2020.July.01. 11:56:12 »
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 :mrgreen:

Offline szipucsu

  • Global Moderator
  • EP addict
  • *
  • Posts: 10095
  • Country: hu
    • Támogató Támogató
    • Webnyelv.hu - Tanuljunk nyelveket!
Re: Xep128
« Reply #206 on: 2020.July.01. 13:43:42 »
LGB's useful web page
Is there also a Primo Emulator for the Enterprise? I didn't remember.
100 SOUND SOURCE 2,STYLE 128,PITCH 25.2,SYNC 1
110 SOUND PITCH 25,SYNC 1
120 ! Videos

Offline SlashNet

  • EP addict
  • *
  • Posts: 1348
  • Country: ua
  • Enterprise 128K | Cubietruck
    • My old site about Enterprise
Re: Xep128
« Reply #207 on: 2020.July.01. 16:32:37 »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #208 on: 2020.July.02. 01:21:42 »
May be you can mix what you have with what is stored on the WayBackMachine.

Edit: But surely you already have thought on that...

The hard part is the active content, which ran on the server side, that's cannot be archived too much by external stuff like archive.org. For example the "smart" disassembler is kinda an old version now, since it has a server side (python) component which does the stuff ...

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: Xep128
« Reply #209 on: 2020.July.02. 01:26:10 »
Also just to mention I'm not so active unfortunately in Ep topics nowadays, since i'm busy with this: