Page 1 of 1

Re: Zymosis and ZXEmuT

Posted: Sat Jul 04, 2020 11:38 am
by utz
A Tcl interpreter, you say? Excellent! That should be quite workable.
I'm controlling MAME through a stdio pipe. I could in theory do sockets, but it needs to work on Windows as well, so pipe is easier to do for me, I believe.

One feature that would be great to have is to be able to execute code on debugger breakpoints, so I can call back to the main app when certain breakpoints are hit. I guess that's what the trap code is for, but that's not feasible for me since I'd need handle this in Bintracker's compiler, which is supposed to be agnostic of the emulation back-end. I assume it'd be a lot of work to add a more general solution to ZXEmuT, though. Probably not worth it, at least not at this point. For the basic stuff I can get by without it.

Anyway, this will take some time since there are many other things in Bintracker that need to be finished first, but now that you said the magic T-word :mrgreen: I'm definitely interested in doing this at some point.

Re: Zymosis and ZXEmuT

Posted: Sat Jul 04, 2020 12:11 pm
by ketmar
utz wrote: Sat Jul 04, 2020 11:38 am but it needs to work on Windows as well
oops. ZXEmuT is GNU/Linux only. i may make it work on windows, but it will be mostly useless, as there will be no sound. ;-) when ZXEmuT is compled with sound support, timing is done by sound card queries. while i can rewrite it to use winmm timer, it will take some time.
utz wrote: Sat Jul 04, 2020 11:38 am One feature that would be great to have is to be able to execute code on debugger breakpoints, so I can call back to the main app when certain breakpoints are hit. I guess that's what the trap code is for, but that's not feasible for me since I'd need handle this in Bintracker's compiler, which is supposed to be agnostic of the emulation back-end. I assume it'd be a lot of work to add a more general solution to ZXEmuT, though. Probably not worth it, at least not at this point. For the basic stuff I can get by without it.
it is not hard to call Tcl command instead of opening the debugger when breakpoint is hit. actually, that feature was planned, i just didn't implemented it yet. the whole idea of embedding Tcl is that people could use it to automate any tasks they want. that's why all console commands are actually Tcl functions, and most of them returns some meaningful values. the API is not documented yet, but basically Tcl has full control over the emulator.
utz wrote: Sat Jul 04, 2020 11:38 am Anyway, this will take some time since there are many other things in Bintracker that need to be finished first, but now that you said the magic T-word :mrgreen: I'm definitely interested in doing this at some point.
no problems. ;-) i will happily add the features you need. windows may be the problem, tho, 'cause i don't have windows, and my windows programming skills are very... rusty. but there is some hope still... ;-)

Re: Zymosis and ZXEmuT

Posted: Sat Jul 04, 2020 1:02 pm
by utz
On second thought, it actually doesn't need to work on Windows. MAME will stay the default for Spectrum emulation, with ZXEmuT being an additional option. Windows users will miss out on it then, but well, tough luck :D

If you could implement calling Tcl code on hitting breakpoints, that would be awesome. But as I said, take your time, I'm still a few months away from adding additional emulation backends.

Re: Zymosis and ZXEmuT

Posted: Sat Jul 04, 2020 1:20 pm
by ketmar
utz wrote: Sat Jul 04, 2020 1:02 pm If you could implement calling Tcl code on hitting breakpoints, that would be awesome. But as I said, take your time, I'm still a few months away from adding additional emulation backends.
i already did it. ;-) you can now either process a breakpoint with Tcl code, or leave it to ZXEmuT to process. i also added Tcl API to manupulate Z80 registers (including PC and MEMPTR). now i only have to document it (and add some more API; but remember that all console commands are Tcl procs! ;-).

actually, there is no "direct console command execution" at all there: to execute console command, ZXEmuT calls "conexec" Tcl proc (which you can override). so the console is extensible from Tcl code too. and of course, you can directly execute Tcl code from console by prefixing it with a dot.

Re: Zymosis and ZXEmuT

Posted: Sat Jul 04, 2020 3:57 pm
by utz
Ha, you're a machine. Thanks a lot. I think with this setup, only minimal changes will be required on the Bintracker side, as I can send pretty much the same messages that I'm sending to MAME. Just need to write a Tcl script to decode them on ZXEmuT. That'll be fun.

Re: Zymosis and ZXEmuT

Posted: Sat Jul 04, 2020 4:31 pm
by ketmar
it was easy. the feature was planned from the beginning, so it was only a matter of writing several lines of code. ;-)

also, i added `proc usock_received {args}`, so you can process received commands without rewiring the console command handler.

also, "--usock -" can be used to read commands from stdin.

i will prolly document it all later. as you said that you're not in hurry right now, i will prolly play with this little more before finalising it. yet you can clone Zymosis repo at any time to test it out.

feel free to make additional feature requests when the time will come. ;-)

p.s.: ZXEmuT is still "one-user project" anyway -- while it has very rudimentary "jam install" option, it won't really work right. it will install the files, but ZXEmuT will not know where to find them. ;-) i pretty much dropped Speccy coding for years, and ZXEmuT was on hold too. i only resumed its development after i found this forum, so alot of things are not finished yet.

also, you can use any capitalisation you like. "zxemut" is fine too, or "ZXEmut", or even "zXeMuT". it is "EmuT" because it was "ZX Emulator Test", developed to test Zymosis. but the name stuck. ;-)

Re: Zymosis and ZXEmuT

Posted: Wed Jul 29, 2020 4:08 pm
by ketmar
i added +3DOS support to ZXEmuT. only +2A model for now (started doing +3 model, but it doesn't work yet for some reason ;-). still, it is now possible to load DSK files. yay. now i can start adding +3DOS support to dsForth. ;-)

Re: Zymosis and ZXEmuT

Posted: Fri Jul 31, 2020 8:46 am
by ketmar
also, i removed half-finished Widgets Tcl API, and created much simplier "UI Overlay" API. internally, ZXEmuT has no widgets, it uses a simple canvas ("virtual overlay" in terms of its videosystem), on which you can draw pixels and text, and then it blits that canvas to the emulated Spectrum screen. yeah, it means that UI is restricted to 320x240 pixels, but i'm ok with it right now. it can be changed later if necessary.

anyway, overlay API is much simplier, and can be used to create various tools with Tcl. it is already used to integrate simple sprite viewer/exporter tool, but the possibilities are endless, because Tcl has access to most of the emulated machine internals. i will also export asm/disasm to Tcl, to ease writing various code analysis tools.

of course, one can use overlay API to create traditional widget-based UI too -- it can be easily written in Tcl.

Re: Zymosis and ZXEmuT

Posted: Sat Aug 01, 2020 8:59 am
by ketmar
added alot of sanity checks to libfdc API, documented API a little, and almost done with +3DOS disk file i/o (not .dsk images, but files inside the images, on +3DOS file system).

ah, what is libfdc? (standalone ;-) part of ZXEmuT: WD1793/uPD765 emulator. it can also read and write alot of disk image formats, and have some simple API to access TR-DOS and +3DOS file systems.

libfdc is heavily based on the code written by SAM style for Xpeccy (thnx alot!), but i cleaned it up, created slightly better API, added at least several lines of comments to API calls and so on. emulated FDCs are working in nanosecond precision (at least this is what library is using to advance emulation ;-).

one emulated disk interface contains 4 floppy drives, and you can create alot of disk interface objects if you want too. you can also create standalone "floppy disk" object if all you want is read/write/modify disk images. if you need to add TR-DOS/+3DOS support to your emulator, libfdc may be what you are looking for. only $0.00!

p.s.: it depends only on libc, as usual.

p.p.s.: 'i consider both projects as "mostly finished"'. haha. ketmar's funny quotes.

Re: Zymosis and ZXEmuT

Posted: Fri Aug 14, 2020 4:52 am
by ketmar
just for fun, two screenshots of ZXEmuT in action:
debugger
Spoiler
Image
control console. you can see alot of loaded Tcl scripts there... ;-)
Spoiler
Image

Re: Zymosis and ZXEmuT

Posted: Sun Jun 12, 2022 3:40 pm
by ketmar
short news: replaced old libfdc with brand new libfusefdc. the code was exctracted from FUSE, and turned into standalone library; after that it was augmented with my modules to read/write TR-DOS and +3DOS file systems. libfusefdc has better emulation (all programs which refused to work with old libfdc are perfectly working now), and it also can be compiled without FDC emulation support, and used as a library to convert between different image formats, and work with TR-DOS/+3DOS disk images (list, extract, add, delete* files). also, no installed libspectrum needed, nor zlib (the code contains optional miniz deflate implementation).

there is experimental "turbo FDC" mode too, which reduces most delays. majority of programs (included protected +3DOS software) seems to work with this mode enabled. but of course, "turbo mode" can be toggled in runtime.

* deletion is only partially supported yet.