Zymosis and ZXEmuT

Struggling with Fuse or trying to find an emulator with a specific feature. Ask your questions here.
User avatar
utz
Dizzy
Posts: 87
Joined: Wed Nov 15, 2017 9:04 am
Contact:

Re: Zymosis and ZXEmuT

Post 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.
0 x

User avatar
ketmar
Manic Miner
Posts: 207
Joined: Tue Jun 16, 2020 5:25 pm

Re: Zymosis and ZXEmuT

Post 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... ;-)
0 x

User avatar
utz
Dizzy
Posts: 87
Joined: Wed Nov 15, 2017 9:04 am
Contact:

Re: Zymosis and ZXEmuT

Post 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.
0 x

User avatar
ketmar
Manic Miner
Posts: 207
Joined: Tue Jun 16, 2020 5:25 pm

Re: Zymosis and ZXEmuT

Post 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.
1 x

User avatar
utz
Dizzy
Posts: 87
Joined: Wed Nov 15, 2017 9:04 am
Contact:

Re: Zymosis and ZXEmuT

Post 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.
0 x

User avatar
ketmar
Manic Miner
Posts: 207
Joined: Tue Jun 16, 2020 5:25 pm

Re: Zymosis and ZXEmuT

Post 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. ;-)
0 x

User avatar
ketmar
Manic Miner
Posts: 207
Joined: Tue Jun 16, 2020 5:25 pm

Re: Zymosis and ZXEmuT

Post 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. ;-)
1 x

User avatar
ketmar
Manic Miner
Posts: 207
Joined: Tue Jun 16, 2020 5:25 pm

Re: Zymosis and ZXEmuT

Post 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.
0 x

User avatar
ketmar
Manic Miner
Posts: 207
Joined: Tue Jun 16, 2020 5:25 pm

Re: Zymosis and ZXEmuT

Post 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.
0 x

User avatar
ketmar
Manic Miner
Posts: 207
Joined: Tue Jun 16, 2020 5:25 pm

Re: Zymosis and ZXEmuT

Post by ketmar »

just for fun, two screenshots of ZXEmuT in action:
debugger
SpoilerShow
Image
control console. you can see alot of loaded Tcl scripts there... ;-)
SpoilerShow
Image
0 x

Post Reply