Any GUI-Based jzintv Frontends for Linux?

[Zendocon]

I have the scripts I wrote to select a few options from a menu, but it's all command-line.  I've never developed for X11 before, so I thought I'd ask if any such thing exists already before I go reinventing the wheel.

[ColecoJoe]

Not sure about a linux version but here is a mac version that was abandoned long ago.

 

 

[mr_me]

I use Linux Files Manager / Nautilus and it's right-click send to script function.

[Zendocon]

That sounds like what I had in mind to build.  Unfortunately, neither of those packages are readily available in my distro.  The closest thing I could find is xorg-util-macro, but there is no man page, and I gave up trying to find any documentation online.  From the sound of it, I assume it's a graphical macro generator.

[mr_me]

You just put your jzintv script at  ~/.local/share/nautilus/scripts/ and it adds it to the right click menu.  That's ubuntu, which linux are you using?

Edited September 16, 2019 by mr_me

[Zendocon]

It's called Termux, which runs in chroot on an Android device and doesn't require rooting.

 

What I was thinking was a bunch of drag-and-drop GUI controls, with a Launch button that would generate the appropriate string, and would then pass that string into a shell.  Not unlike jzintv Launcher, which I use in Windows.

[+intvsteve]

Not yet.  I've been occasionally giving some oxygen to a GTK-based version of the LTO Flash! UI software (LUI) the past couple years. At present, it's got much of the core functionality needed to communicate with LTO Flash! implemented, with plenty of gaps in some of the more advanced UI features.

 

LUI on Mac / Windows does have integration to support launching jzintv for ROMs tracked in the UI.  The parts that are missing in the experimental GTK version are the settings and the UI to point LUI to your jzintv and "system" ROMs.  The most recent updates to that branch of the code removed using gconf for settings storage.

[Zendocon]

On 9/17/2019 at 1:59 PM, intvsteve said:

Not yet.  I've been occasionally giving some oxygen to a GTK-based version of the LTO Flash! UI software (LUI) the past couple years. At present, it's got much of the core functionality needed to communicate with LTO Flash! implemented, with plenty of gaps in some of the more advanced UI features.

I did start to take up GTK recently, but then gave up on it and wrote a GUI using Python's Tkinter.  @jenergy helped to get it ported to Windows and took some screenshots for the preview.  I cleaned it up a bit and posted it to my website.  This is what I had in mind; something with not too many controls in the front-end beyond the common stuff.

[zzip]

On 9/16/2019 at 3:31 PM, Zendocon said:

I have the scripts I wrote to select a few options from a menu, but it's all command-line.  I've never developed for X11 before, so I thought I'd ask if any such thing exists already before I go reinventing the wheel.

I've written a graphical front-end that runs full screen using SDL.   It supports JZintv among many other emulators.    If interested, I could send a copy

[Zendocon]

6 hours ago, zzip said:

I've written a graphical front-end that runs full screen using SDL.   It supports JZintv among many other emulators.    If interested, I could send a copy

Sure.  I'd be interested to see it.

[jenergy]

9 hours ago, zzip said:

I've written a graphical front-end that runs full screen using SDL.   It supports JZintv among many other emulators.    If interested, I could send a copy

 

I'm interested too!

Edited August 14, 2020 by jenergy

[zzip]

10 hours ago, Zendocon said:

Sure.  I'd be interested to see it.

 

6 hours ago, jenergy said:

I'm interested too!

Ok, I will put together an executable and sample config later today

[Zendocon]

I just made a slight change and reuploaded both the Linux and Windows ports for my front-end.  The GameList included the original 125 games, plus the two variations of Pac-Man and Lock & Chase.  Of the six released ECS games, two of them supported saving to tape: The Jetsons' Ways With Words and World Series Major League Baseball.  Melody Blaster only supported loading new songs from tape, and I don't think any tapes were made.  Mr. BASIC Meets Bits & Bytes lets you use CSAV and CLOD with 4-character filenames, just like ECS BASIC, and saves to the appropriate file on its own.  The other two games, Mind Strike and Scooby Doo's Maze Chase, didn't support saving or loading at all.

 

As a side note, I'd love to create virtual tapes to add new songs to Melody Blaster.  I'll have to reverse-engineer the ROM and uncover the data format for the existing songs.  Then I'll have to see how it loads data from tape.  Maybe I can start with a ROM hack.

 

As another side note, maybe I ought to put more ROM variants into the GameList.  One such variant is the released 8K version of Thin Ice from INTV as opposed to the unreleased 16K version from Mattel Electronics that had the Vučko easter egg.  I found this thread, but is there a comprehensive list of ROM variants out there somewhere?

[zzip]

20 hours ago, Zendocon said:

Sure.  I'd be interested to see it.

 

17 hours ago, jenergy said:

I'm interested too!

 

I've attached the front-end,  after you extract it you can run the runme.sh script in the top level to get it started.   A few things to be aware of:

- it requires SDL2, SDL2-image, freetype, libraries to be installed,  these are fairly common libraries, and they are usually in your distribution's repo to be easily installed if you don't have them.  If it crashes on start, let me know.    This is also a 64-bit build.   I think I still have 32-bit builds if needed.

- The included theme is designed for 1080p or higher.  Not sure what will happen if you try to run it at a lower res.  The theme is highly configurable if this one isn't to your taste.  I have older themes that run at lower resolutions

- I've included a live jzintv  and a few samples games,  however the roms are fake and the emulator won't run them.  The front end won't generate the command-line properly if it doesn't see the romfile, so that's why I put fake ones,  if you replace them with actual roms + actual exec and grom files, it should work

- I also included a sample Atari 2600 config to give an idea how multiple systems can be configured and organized.  If you don't want it, remove the Atari directory, and remove the line for Atari from the index.menu file in the top-level directory.

- This front-end is extremely configurable, and can handle most emulators, multiple media types for each emulator.  System and emulator specific options can be added, you can even configure it on a per-game basis if needed (like if gameX needs OSversion1 rom and PAL settings, gameY needs OSversion2 and NTSC).  but all that configuration is done in config files that might not be obvious how to setup.    I can provide configuration samples for many other emulators, including Mame, atari800, stella, Mess, Retroarch, mednafen, hatari, Steem, fs-uae, Vice, coolcv, dosbox, z26, vitualjaguar and others I'm forgetting

- The game menus are static, not dynamic, but I have scripts that can help generate menus and other content.

- use the escape key to leave the front-end, you can navigate with keys, joystick (if enabled), mouse (although I think I need to fix this)

- if things don't work as expect--  crashes, or games don't run, it's usually a file missing.

 

Good luck, let me know if you run into trouble!

emufrontend.tgz

[+Lathe26]

11 hours ago, Zendocon said:

As a side note, I'd love to create virtual tapes to add new songs to Melody Blaster.  I'll have to reverse-engineer the ROM and uncover the data format for the existing songs.  Then I'll have to see how it loads data from tape.  Maybe I can start with a ROM hack.

 

Please do!  This sounds like a cool project.

[Zendocon]

9 hours ago, Lathe26 said:

Please do!  This sounds like a cool project.

I'll probably start another thread for this and stay on topic.

 

So far, I discovered the tunes and the pointers in the ROM to their location.  It looks like the general format is for each of 4 channels to have its own line, which consists of byte pairs: one for the note (or $80 for silence) and the next for its duration in ticks.  All the data fits into 8 bits, and I assume it's because it gets loaded into ECS memory and parsed from there.  There are a lot of calls to addresses in $40xx and $41xx, probably ECS "exec" ROM.  The first 18 bytes are the tune name.  Within the tune data are some arbitrary spaces between notes, suggesting somebody played a MIDI keyboard into an intermediate device which encoded the data into a file.

[Zendocon]

14 hours ago, zzip said:

I've attached the front-end,  after you extract it you can run the runme.sh script in the top level to get it started.

I tried running the runme script on my phone, whose architecture is aarch64.  The script is looking for an emufe.aarch64 file in the /bin folder.  Also, none of my mobile devices have an Escape key on their keyboards; it's replaced with a Home key.  I'm lucky the latest keyboard I have for my tablet has function keys.

[zzip]

24 minutes ago, Zendocon said:

I tried running the runme script on my phone, whose architecture is aarch64.  The script is looking for an emufe.aarch64 file in the /bin folder.  Also, none of my mobile devices have an Escape key on their keyboards; it's replaced with a Home key.  I'm lucky the latest keyboard I have for my tablet has function keys.

ah..  it's compiled for the 64-bit intel architecture.   It is designed to be cross-compiled and I did make a build on my Raspberry Pi,  but I don't that uses aarch64.

 

if you're feeling lucky, I can send the source.   If it builds successfully, just copy the resulting emufe binary to emufe.aarch64 under the bin folder, it should work

[Zendocon]

Yes, I usually just compile the source myself.  I'm almost certain I have the required packages you listed.

[+Lathe26]

5 hours ago, Zendocon said:

I'll probably start another thread for this and stay on topic.

 

So far, I discovered the tunes and the pointers in the ROM to their location.  It looks like the general format is for each of 4 channels to have its own line, which consists of byte pairs: one for the note (or $80 for silence) and the next for its duration in ticks.  All the data fits into 8 bits, and I assume it's because it gets loaded into ECS memory and parsed from there.  There are a lot of calls to addresses in $40xx and $41xx, probably ECS "exec" ROM.  The first 18 bytes are the tune name.  Within the tune data are some arbitrary spaces between notes, suggesting somebody played a MIDI keyboard into an intermediate device which encoded the data into a file.

Thanks.

 

The $4000-$47FF is ECS 8-bit RAM.  The ECS ROM is located in $2xxx, $7xxx, and $Exxx and only in specific banks in those memory regions.  Hope that helps with the decoding.

[Zendocon]

48 minutes ago, Lathe26 said:

Thanks.

 

The $4000-$47FF is ECS 8-bit RAM.  The ECS ROM is located in $2xxx, $7xxx, and $Exxx and only in specific banks in those memory regions.  Hope that helps with the decoding.

It does.  I started another thread for Melody Blaster.  I'll make a list of the exact addresses referenced in the game ROM.

[zzip]

On 8/15/2020 at 11:28 AM, Zendocon said:

Yes, I usually just compile the source myself.  I'm almost certain I have the required packages you listed.

I went and did a build on Pi to make sure it still compiles on non-Intel.   I found there's a few hardware-specific lines I need to change, and then I can post the source code.

 

[zzip]

On 8/15/2020 at 11:28 AM, Zendocon said:

Yes, I usually just compile the source myself.  I'm almost certain I have the required packages you listed.

Here's a 3-year old version that compiles and runs on my raspberry pi.   The newest version has a start-up error I need to get to the bottom of.

 

build should be a matter of running:

./configure

make

cp src/emufe /data/emulator/bin/emufe.aarch64

(change "/data/emulator" to the location you extracted the front-end I sent last week)

 

Some notes: 

1. if configure complains about freetype even though you have the freetype dev package installed, let me know and I'll provide a workaround.  Apparently newer versions of freetype did away with "freetype-config" and now use "pkg-config" instead

2. it assumes your display is 32-bit depth.  I think most modern displays are 32, but if your isn't, I can tell you what to change.

3. It runs slower than I'd like on my PI, I don't think it's using the PI hardware acceleration, and it's also a slow PI-2.   If it runs too slow for you, let me know and I'll see what I can do about hw acceleration on your device

4. I've written and enhanced this over a period of 20-years.  When I started, I knew just enough C to be dangerous.   I'm much better at  C now, but there's still a lot of legacy code that throws out tons of compilation warnings that I haven't fixed yet.    But at least  it runs pretty stable.   If it crashes, it's usually due to a file missing

 

emufe-3.2.0.tar.gz

[Zendocon]

I ran the configure script, and these are the last few lines:

UNAME_MACHINE = aarch64
UNAME_RELEASE = 4.14.117-18725784
UNAME_SYSTEM  = Linux
UNAME_VERSION = #2 SMP PREEMPT Wed Jul 1 10:55:25 KST 2020
configure: error: cannot guess build type; you must specify one

As for what's ahead, I'm pretty sure I'm using pkg-config, and $TERM=xterm-24bits.

 

I do want to give this a try, but we may have to "take this outside" to DM to handle any additional errors.  Once I get it going, I'd be happy to add installation of this to my environment documentation, to provide an alternative to users.