jzintv Christmas update

[intvnut]

I've gotten a couple reports of issues with the new release. 

 

In particular, it appears I accidentally busted stdout output on SDL2 on Win32, and I forgot to include the doc directory on the Win32 downloads.  (The latter part is fixed—the Win32 downloads include the doc directory).

 

If you download and try any of these versions—Win, OS/X, x86-64 Linux, R-Pi—using either SDL1 or SDL2 and see an issue, please contact me.  I'll do my best to address, and will release a followup version that hopefully addresses the issues soon.

[jenergy]

5 hours ago, intvnut said:

jzIntv has support for defining up to 64 COMBO events involving 2 key presses, along with a configurable delay.  See "Combo Events" in doc/jzintv/kbdhackfile.txt.

 

I should REALLY begin to read documentation files when I see them. ? 

Thanks

[intvnut]

An update:  

 

I've added the missing doc folder to both Windows downloads.  However, the Windows SDL2 release is broken:  it deadlocks when you enable voice.  Also, both SDL2 and SDL1 don't display stdout when launched from CMD.  This is unfortunate, as both do display stdout when you launch from an MinGW window.  

 

For the deadlock, I've figured out that the problem is SDL2 gives me very tiny audio buffers compared to SDL1 on Windows, and that causes my peripheral scheduler to deadlock when voice is enabled.  

 

I don't know the solution yet, but it has highlighted to me yet again that both my peripheral scheduling scheme and my audio buffering scheme have issues.  I've actually known that for a while but have been able to mostly ignore it, since it worked well enough.  In the short run, I'll probably tweak it so it "works" again, but I need to replace both longer term.

 

I don't have an ETA just yet, but hope to get to it soon.

[jenergy]

15 hours ago, intvnut said:

An update:  

 

I've added the missing doc folder to both Windows downloads.  However, the Windows SDL2 release is broken:  it deadlocks when you enable voice.  Also, both SDL2 and SDL1 don't display stdout when launched from CMD.  This is unfortunate, as both do display stdout when you launch from an MinGW window.  

 

For the deadlock, I've figured out that the problem is SDL2 gives me very tiny audio buffers compared to SDL1 on Windows, and that causes my peripheral scheduler to deadlock when voice is enabled.  

 

I don't know the solution yet, but it has highlighted to me yet again that both my peripheral scheduling scheme and my audio buffering scheme have issues.  I've actually known that for a while but have been able to mostly ignore it, since it worked well enough.  In the short run, I'll probably tweak it so it "works" again, but I need to replace both longer term.

 

I don't have an ETA just yet, but hope to get to it soon.

Sorry for the extra work you'll have to do, this migration has been a big change.  But you can think that all this stuff keeps you young and in good health ?

Edited June 10, 2020 by jenergy
Typos

[intvnut]

I've put a new test build up for Windows only.  This just has the updated Windows executables, and is not a full release. 

 

It should restore console output, and should resolve the Intellivoice deadlock.  It will hopefully resolve any problems with sound "popping" (reported against the SDL2 version) by increasing the buffer depth.  Please let me know if it complains about missing DLLs or any other problems.  If these builds for SDL1 and SDL2 are clean, I'll create full releases with all the updates.

• SDL1:  http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200610-win32-sdl1-test.zip
• SDL2:  http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200610-win32-sdl2-test.zip 

Thanks!

 

 

[IMBerzerk]

I hate to ask... But coming from someone that has absolutely no clue what all this means....

 

What are the advantages of changing jzintv to this new format?   Will I see a difference in any aspect as a simple user?  Or is this more or less to get it to modern standards?

 

Thanks 

[intvnut]

2 minutes ago, IMBerzerk said:

I hate to ask... But coming from someone that has absolutely no clue what all this means....

 

What are the advantages of changing jzintv to this new format?   Will I see a difference in any aspect as a simple user?  Or is this more or less to get it to modern standards?

 

Thanks 

 

SDL2 makes better use of modern video cards. 

 

On the Mac, for example, I was getting some dreadful frame rates with SDL1.  I'm talking 10-15FPS when running in a window.  jzIntv seemed to get slower with each new OS release, even though under the hood it was as fast as ever.  It was doing 60Hz around 20 years ago on much slower hardware.  I also saw some performance issues on Windows, although to a lesser degree.  I haven't tried with anything newer than Windows 7, though.

 

SDL2 uses modern APIs, and pulls 60Hz effortlessly on modern machines.  It's buttery smooth and responsive on my laptop now.

 

SDL2 also supports some other nice features, such as multiple monitors and multiple windows.  I may make use of those at some point.  But for now, I'll take the nice 60Hz display.

[jenergy]

16 hours ago, intvnut said:

I've put a new test build up for Windows only.  This just has the updated Windows executables, and is not a full release. 

 

It should restore console output, and should resolve the Intellivoice deadlock.  It will hopefully resolve any problems with sound "popping" (reported against the SDL2 version) by increasing the buffer depth.  Please let me know if it complains about missing DLLs or any other problems.  If these builds for SDL1 and SDL2 are clean, I'll create full releases with all the updates.

• SDL1:  http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200610-win32-sdl1-test.zip
• SDL2:  http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200610-win32-sdl2-test.zip 

Thanks!

 

 

I tried space spartans on both tests (but a very quick test, for the moment) and it seems ok, while the 'official' jzintv version get stuck in a purple screen

[Zendocon]

15 hours ago, IMBerzerk said:

I hate to ask... But coming from someone that has absolutely no clue what all this means....

 

What are the advantages of changing jzintv to this new format?   Will I see a difference in any aspect as a simple user?  Or is this more or less to get it to modern standards?

 

Thanks 

From my own perspective, I've run into performance issues running jzintv in my Portable Development Environment using SDL1.  It was good enough for playtesting my indie games, but hardly good enough for playing the original games unless I hacked something and wanted to playtest it.  On my old phone, I even had to lower the audio sampling rate just to get it running full speed at all.  Even my new phone, which runs a Sega Dreamcast libretro core at full speed with sound, sporadically drops frames running jzintv on my X Server.  I knew there was an SDL2 package available, and when I heard that the conversion to SDL2 handled the performance issues, I was all too quick to volunteer to try it out.

[Zendocon]

15 hours ago, intvnut said:

SDL2 also supports some other nice features, such as multiple monitors and multiple windows.  I may make use of those at some point.  But for now, I'll take the nice 60Hz display.

Xinerama?  Might be good for displaying box and overlay images, and perhaps scans of each pair of pages of an opened instruction manual.

 

Currently, my scripts fetch the overlay image and calls feh to display it, and kills feh when jzintv is finished running.

[+fdr4prez]

I fear that the SDL2 build will not accept the GPIO script inputs that I've created for the Pi used in the "ultimate" flashback rebuilds.

 

I've seen this bandied about in my google searches when I first started development of my GPIO python script:

 

SDL2 applications depend on evdev for input events. Specifically this means applications like the latest version of RetroPie and EmulationStation won't be able to see key events generated by a python script.

 

Which I forewarn people that using my GPIO script in RetroPie that jzintv, standalone Stella and CoolCV will work with my script, but none of the "lr-" emulators that have been updated to SDL2 will detect the GPIO events generated by my script.

 

I am going to need to do more research on how to get my little script to work correctly for SDL2.  It seems that I basically need it be recognized as a virtual keyboard instead of just pushing uinput data out into the system.

[intvnut]

2 hours ago, fdr4prez said:

I fear that the SDL2 build will not accept the GPIO script inputs that I've created for the Pi used in the "ultimate" flashback rebuilds.

Perhaps I could build a direct interface to GPIO so we can retire your Python scripts, at least for jzIntv?  Do your GPIO scripts perform any translation / mapping, or do they mostly just detect GPIO changes and reinsert them as events picked up by SDL1?  That is, what degree of matching and translation do you do?

 

Do you know offhand how Python accesses the GPIO?  Is it through pigpio, WiringPi, or something else?

 

When I looked before, it looked like most documentation focused on using some high level libraries or Python.  I have no problem directly mangling the GPIO myself, or consuming GPIO from a commonly-loaded daemon (as pigpio does), or opening a pipe to a Python script (so it can just print the events to me), or whatever.

 

Biggest challenge:  I'm not really set up to test this.  Would you be willing to test what I build?  I can easily add a bunch of general purpose GPIO events to the event table, and provide platform-specific modules where it makes sense.  I also have corresponding "raw" actions now, so in theory you really could directly wire Intellivision controller bits to GPIOs.  If the wiring is more complicated, that could get challenging.

 

5 hours ago, Zendocon said:

Xinerama?  Might be good for displaying box and overlay images, and perhaps scans of each pair of pages of an opened instruction manual.

I don't think I used Xinerama when I was using multiple monitors on Linux.  I believe I used RandR.   Right now, I'm sadly in a zero-monitor state on Linux, but I hope to change that within the next month.

 

At the moment, I'm only considering features that would directly connect to the core of jzIntv, such as debugger windows.  I want to clean up the separation of core and GUI so that it's easier to write a front end and embed jzIntv within it, or move jzIntv to other graphics/sound/event backends.  Organizing a library of manuals, overlays, box images, and so on seems like a task that belongs outside the core emulator.  It would be both interesting and useful to the folks playing the games, and I want to enable that. 

 

I'm not the right person to write that, for the same reasons I wasn't the right person to write the LTO Flash GUI. ?

 

Edited June 11, 2020 by intvnut

[+fdr4prez]

18 minutes ago, intvnut said:

Perhaps I could build a direct interface to GPIO so we can retire your Python scripts?  Do your GPIO scripts perform any translation / mapping, or do they mostly just detect GPIO changes and reinsert them as events picked up by SDL1?  That is, what degree of matching and translation do you do?

 

Do you know offhand how Python accesses the GPIO?  Is it through pigpio, WiringPi, or something else?

 

When I looked before, it looked like most documentation focused on using some high level libraries or Python.  I have no problem directly mangling the GPIO myself, or consuming GPIO from a commonly-loaded daemon (as pigpio does), or opening a pipe to a Python script (so it can just print the events to me), or whatever.

 

Biggest challenge:  I'm not really set up to test this.  Would you be willing to test what I build?  I can easily add a bunch of general purpose GPIO events to the event table, and provide platform-specific modules where it makes sense.  

 

My script(s) is for monitoring the button(s) on the various Flashback shells.

 

For Intv and CoolCV I am using a python script using the gpiozero library.

 

For the Intv and Coleco Flashback console shells, there is only a single Reset button on it.  So my script will do a "F12" keypress for a quick press of that Reset button, and the script will do a "F1" on a long hold-down of the Reset button.  So a quick press will reset the game and a long press will do a quit game.  Since the Inty FB shell only has one button, I make the most out of that single button for the user.

reset - jzintv.txt

 

My CoolCV script is exactly the same, but uses those particular default keypresses for that emulator's reset and quit.

 

If someone wants to use jzintv and coolcv at the same time, then I would either change my script accordingly to work with both.  Or remap the emulator settings so both emulators work with the same for the reset and quit events in the script.

 

My Atari 2600 script doesn't use gpiozero and is completely different, but conceptually the same.  The Atari FB shell has many switches and buttons, and some are latching and some are momentary, so all that is taken into consideration in my Atari script.

 

And if someone wants to use jzintv, stella and coolcv all in the same FB shell, then I'd recommend to use an Atari FB shell due to the needed Atari console buttons/switches and I will map jzintv and coolcv accordingly so all three emulators work off of the same script.

 

for me, since I am working with a variety of scripts to help out the many AA member's with their flavor of "ultimate" build, i think it would be better for me to get my script "SDL2 compliant" because then my script could be used with the other "lr-" emulators used in RetroPie

 

[+fdr4prez]

56 minutes ago, intvnut said:

I also have corresponding "raw" actions now, so in theory you really could directly wire Intellivision controller bits to GPIOs.  If the wiring is more complicated, that could get challenging.

I am interested in testing this.

 

There are only 9 wires in the controller, so it should be easy enough to connect them to the GPIO header.

 

If I recall, the current RetroPie release is using your jzintv-20181225 release, so is this gpio support added in that version?

 

Is there a document for how to implement this?  What controller wire goes to what GPIO pin?  How do you configure that set of GPIO to be left or right controller?

 

I can definitely test this with a Pi and if it works, then I can rebuild my Ultimate Intellivision Controller to use the GPIO for its main input, and then I can use its existing Raphnet adapter to have a DB9 pigtail and it will now be 2-player compatible.  Or wire the player DB9 directly to the GPIO, too, and the Raphnet won't be needed at all... oh boy, this is exciting 

 

My Pi2 and Pi3 are inside Flashback units right now, but I have a handful of Pi0 that i can easily test this on.

[intvnut]

3 hours ago, fdr4prez said:

It seems that I basically need it be recognized as a virtual keyboard instead of just pushing uinput data out into the system.

 

1 hour ago, fdr4prez said:

for me, since I am working with a variety of scripts to help out the many AA member's with their flavor of "ultimate" build, i think it would be better for me to get my script "SDL2 compliant" because then my script could be used with the other "lr-" emulators used in RetroPie

 

I did some digging around, and it appears there's a Python evdev library that provides a UInput interface similar to what you're already unit for injecting events:

https://python-evdev.readthedocs.io/en/latest/tutorial.html#injecting-input

 

1 hour ago, fdr4prez said:

 

For Intv and CoolCV I am using a python script using the gpiozero library.

 

It looks like gpiozero can uses a variety of back-ends.  I guess for now I won't worry about implementing raw support.  A perhaps more interesting approach anyway would be to open a pipe to an external "event provider," although I don't think that works on Windows.

 

41 minutes ago, fdr4prez said:

I am interested in testing this.

 

There are only 9 wires in the controller, so it should be easy enough to connect them to the GPIO header.

That's what I was hoping to enable, even if it doesn't make sense for the "UFB" type builds.  For example, a dedicated Intellivision-only build. 

 

Also, if Hafner can update his adaptor to provide raw controller bits (if it doesn't already), I can provide higher-fidelity input options that would allow, for example, triggering easter eggs with arbitrary controller patterns.

 

41 minutes ago, fdr4prez said:

If I recall, the current RetroPie release is using your jzintv-20181225 release, so is this gpio support added in that version?

 

Is there a document for how to implement this?  What controller wire goes to what GPIO pin?  How do you configure that set of GPIO to be left or right controller?

I don't have support for GPIO input events, per se.  But, if you can map GPIO events to keys, then you can bind those keys directly to controller pad bits.  There are 8 input bits for each controller:  PD0L_BIT_[0-7], PD0R_BIT_[0-7], PD1L_BIT_[0-7], and PD1R_BIT_[0-7].  That's enough to get you raw controller pad support.

 

I have an example kbdhackfile that maps the upper buttons of a suitably-updated Retronic USB adaptor directly to the raw controller pad bits here (also under doc/jzintv/ in the downloads):  http://spatula-city.org/~im14u2c/intv/jzintv/doc/jzintv/retronic-usb-raw.kbd

 

It looks like, for example, the current Python uinput module supports F13 - F22 input keys, and I'm pretty sure nothing uses them.  So, you could have your GPIO script output F13 - F20 events based on whether those bits read 1 or 0.  "Press" the button for 1, and "Release" the button for 0.  You might want a periodic refresh (e.g. send a redundant "press" or "release") if there's any chance an event could get dropped between your script and jzIntv.  jzIntv's own internal tracking won't care if it gets redundant presses or releases.

 

For raw GPIO connections, you'll need a pull-up on the 8 data pins, and to tie the 9th pin to ground.  It looks like gpiozero supports configuring pins as pull-up.

 

If I need a more flexible scheme for controlling the controller input raw bits, I can add it. (e.g. "BIT_x_SET" and "BIT_x_CLR" that ignore press/release might be useful in some scenarios.)

 

Note: This doesn't get you raw ECS alphanumeric keyboard and music synth input.  jzIntv needs to be able to drive values out to do that, and to switch ports between input and output.

Edited June 11, 2020 by intvnut
add note about ECS keyboard/synth.

[jenergy]

2 hours ago, intvnut said:

At the moment, I'm only considering features that would directly connect to the core of jzIntv, such as debugger windows.  I want to clean up the separation of core and GUI so that it's easier to write a front end and embed jzIntv within it, or move jzIntv to other graphics/sound/event backends.  Organizing a library of manuals, overlays, box images, and so on seems like a task that belongs outside the core emulator.  It would be both interesting and useful to the folks playing the games, and I want to enable that. 

 

 

You should really REALLY spend a couple of minutes for checking "Dear ImGui" (https://github.com/ocornut/imgui, look also at screenshots at half and bottom of page), it's the perfect tool to 'cooperate', debug and manage with a core like jzintv, and integration is very easy, you can construct your windows in a couple of c++ lines, and embed inside it every kind of common widget to monitor all you need.  Even if it is designed explicitly as debug tool, I'm working to create a BASIC interface with it, for configuring and launching jzintv (on rom selection you can see image, screenshot, description and specific launch settings based on the crc32 of single roms)

[+fdr4prez]

22 minutes ago, intvnut said:

I did some digging around, and it appears there's a Python evdev library that provides a UInput interface similar to what you're already unit for injecting events:

https://python-evdev.readthedocs.io/en/latest/tutorial.html#injecting-input

 

Thanks, I will look into this.

 

There is Retrogame that is a GPIO > Keyboard event module available, and makes note on how to make it compatible with SDL2, but it doesn't support the short-press event and the long-press event that i do in my scripts.  So I have at least something else that i can look into to try and mimic what they do.

 

luckily for now, there isn't a big rush for me to get this completed  

 

22 minutes ago, intvnut said:

That's what I was hoping to enable, even if it doesn't make sense for the "UFB" type builds.  For example, a dedicated Intellivision-only build. 

I know of an AA member that is doing an Intellivision only build and he is using an old 2609 console for his build.  I will reach out to him to see where he is at in this build.  If he hasn't purchased adapters, yet, then he may also be willing to try this with the GPIO

 

22 minutes ago, intvnut said:

I don't have support for GPIO input events, per se.  But, if you can map GPIO events to keys, then you can bind those keys directly to controller pad bits.  There are 8 input bits for each controller:  PD0L_BIT_[0-7], PD0R_BIT_[0-7], PD1L_BIT_[0-7], and PD1R_BIT_[0-7].  That's enough to get you raw controller pad support.

 

I have an example kbdhackfile that maps the upper buttons of a suitably-updated Retronic USB adaptor directly to the raw controller pad bits here (also under doc/jzintv/ in the downloads):  http://spatula-city.org/~im14u2c/intv/jzintv/doc/jzintv/retronic-usb-raw.kbd

 

It looks like, for example, the current Python uinput module supports F13 - F22 input keys, and I'm pretty sure nothing uses them.  So, you could have your GPIO script output F13 - F20 events based on whether those bits read 1 or 0.  "Press" the button for 1, and "Release" the button for 0.  You might want a periodic refresh (e.g. send a redundant "press" or "release") if there's any chance an event could get dropped between your script and jzIntv.  jzIntv's own internal tracking won't care if it gets redundant presses or releases.

thanks, that all sounds easy enough

 

22 minutes ago, intvnut said:

For raw GPIO connections, you'll need a pull-up on the 8 data pins, and to tie the 9th pin to ground.  It looks like gpiozero supports configuring pins as pull-up.

Yes, I do configure pull_up=True in my scripts

 

22 minutes ago, intvnut said:

Note: This doesn't get you raw ECS alphanumeric keyboard and music synth input.  jzIntv needs to be able to drive values out to do that, and to switch ports between input and output.

No worries for this from me, thanks.

[jenergy]

On 6/10/2020 at 7:27 PM, intvnut said:

I've put a new test build up for Windows only.  This just has the updated Windows executables, and is not a full release. 

 

It should restore console output, and should resolve the Intellivoice deadlock.  It will hopefully resolve any problems with sound "popping" (reported against the SDL2 version) by increasing the buffer depth.  Please let me know if it complains about missing DLLs or any other problems.  If these builds for SDL1 and SDL2 are clean, I'll create full releases with all the updates.

• SDL1:  http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200610-win32-sdl1-test.zip
• SDL2:  http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200610-win32-sdl2-test.zip 

Thanks!

 

 

Hi, do sources on jzIntv site contain finally these fixes?

[intvnut]

3 minutes ago, jenergy said:

Hi, do sources on jzIntv site contain finally these fixes?

I haven't uploaded the sources for that version yet.  I'd hoped to get to this sooner than I have, since there were some other changes I wanted to make.  I have a new release brewing w/ other fixes and enhancements that hopefully I'll get out later today.

 

A preview:

• Bugfixes:
  • Scale number of audio buffers based on buffer size if smaller than expected.
  • Fixed: PREVMAP accidentally did NEXTMAP, not PREVMAP.
  • Fixed: Intellivoice min tick too high; deadlocks with small audio buffers.
  • Fixed: Restore console output on Windows.
  • Fixed: Restore window decorations when toggling fullscreen back to windowed on Windows.
  • Fixed: Use C99-friendly forward decl for palette_t in avi.h.
  • Fixed: Missing top-level const on prototypes causes warnings w/ MSVC.
  • Fixed: Crash when using --rand-mem and .ROM files.
• Improvements:
  • Flush and close CSAV, CLOD when returning to prompt, rather than after next command.
  • Lazier controller pad / ECS keyboard updates (performance).
  • No longer require -D_GNU_SOURCE on SDL2 builds.
  • Retire -Dlinux from Makefiles; use PLAT_LINUX, set by config.h
  • Improved "momentary pause" behavior when toggling full-screen / windowed, especially automatic toggles from debugger.
  • Document the (already present) 'v' command to show source code in vicinity of an address.
  • Move OS/X specific SDLmain.* files to plat/SDL1_osx_main.*.
• Features:
  • New debugger commands:
    • rs now resets the Intellivision.
    • va now toggles AVI generation.
    • vm now toggles movie (MVI) generation.
    • vs now takes a screen shot.
    • Ctrl-C at console halts the game and drops to debugger (if debugger's enabled) rather than killing jzIntv.
  • Batch mode:
    • Defaults to rate-control off.
    • AVI defaults to 1⨉ scaling in batch mode when rate-control off.
  • Better reset emulation:
    • --rand-mem now randomizes CPU registers at reset.
    • CPU registers and flags no longer zeroed when resetting mid-game.

 

I haven't tried building on Windows in a few days, and I still have changes pending to merge for Termux.

 

But, if you want to see the work-in-progress above, I've snapshot the source here:  http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200621-src-pre.zip

 

[+Tarzilla]

On 6/10/2020 at 3:29 PM, intvnut said:

 

SDL2 also supports some other nice features, such as multiple monitors and multiple windows.  I may make use of those at some point.  But for now, I'll take the nice 60Hz display.

So live GRAM and/or memory viewer windows that we've discussed before is now a eventual possibility with SDL2? I seem to recall you said SDL1 was the limiting factor.

[intvnut]

Just now, Tarzilla said:

So live GRAM and/or memory viewer windows that we've discussed before is now a eventual possibility with SDL2? I seem to recall you said SDL1 was the limiting factor.

Yes indeed.  SDL1 only supports a single window.  SDL2 supports multiple windows, and that's definitely something I am interested in myself.

[jenergy]

16 hours ago, intvnut said:

I haven't uploaded the sources for that version yet.  I'd hoped to get to this sooner than I have, since there were some other changes I wanted to make.  I have a new release brewing w/ other fixes and enhancements that hopefully I'll get out later today.

 

A preview:

• Bugfixes:
  • Scale number of audio buffers based on buffer size if smaller than expected.
  • Fixed: PREVMAP accidentally did NEXTMAP, not PREVMAP.
  • Fixed: Intellivoice min tick too high; deadlocks with small audio buffers.
  • Fixed: Restore console output on Windows.
  • Fixed: Restore window decorations when toggling fullscreen back to windowed on Windows.
  • Fixed: Use C99-friendly forward decl for palette_t in avi.h.
  • Fixed: Missing top-level const on prototypes causes warnings w/ MSVC.
  • Fixed: Crash when using --rand-mem and .ROM files.
• Improvements:
  • Flush and close CSAV, CLOD when returning to prompt, rather than after next command.
  • Lazier controller pad / ECS keyboard updates (performance).
  • No longer require -D_GNU_SOURCE on SDL2 builds.
  • Retire -Dlinux from Makefiles; use PLAT_LINUX, set by config.h
  • Improved "momentary pause" behavior when toggling full-screen / windowed, especially automatic toggles from debugger.
  • Document the (already present) 'v' command to show source code in vicinity of an address.
  • Move OS/X specific SDLmain.* files to plat/SDL1_osx_main.*.
• Features:
  • New debugger commands:
    • rs now resets the Intellivision.
    • va now toggles AVI generation.
    • vm now toggles movie (MVI) generation.
    • vs now takes a screen shot.
    • Ctrl-C at console halts the game and drops to debugger (if debugger's enabled) rather than killing jzIntv.
  • Batch mode:
    • Defaults to rate-control off.
    • AVI defaults to 1⨉ scaling in batch mode when rate-control off.
  • Better reset emulation:
    • --rand-mem now randomizes CPU registers at reset.
    • CPU registers and flags no longer zeroed when resetting mid-game.

 

I haven't tried building on Windows in a few days, and I still have changes pending to merge for Termux.

 

But, if you want to see the work-in-progress above, I've snapshot the source here:  http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200621-src-pre.zip

 

Thank you

[+Lathe26]

That is an impressive list of improvements, thanks!

[intvnut]

8 minutes ago, Lathe26 said:

That is an impressive list of improvements, thanks!

You might recognize a few of them as suggested by you. 

 

I have a couple more goodies are bubbling.  And I need to make a minor fix to make to 'rs'.  It currently doesn't do a good job of resetting after "CPU off in the weeds," and that's actually a rather important use case for the feature!  In fact, jzIntv's debugger generally doesn't handle that state well.

[intvnut]

I've finally uploaded an updated version here.  Release notes:

Release notes for 2020-07-12.  (SVN r2110)
Updates since 2020-06-07.  See ReleaseNotes_20200607.txt for earlier updates.

---------------
 New features:
---------------

*   jzIntv
    *   Debugger improvements:
        *   GNU Readline support!
            *   Available on Windows, Linux, Mac by default.
            *   Readline-enabled builds pump event-loop in background,
                improving window behavior / interaction w/ the OS.
        *   New commands:
            *   rs now resets the Intellivision.
            *   va now toggles AVI generation.
            *   vm now toggles movie (MVI) generation.
            *   vs now takes a screen shot.
        *   Ctrl-C at console halts the game and drops to debugger when the
            debugger is enabled, rather than killing jzIntv.
        *   Treat "off-in-the-weeds" and HLT cleanly.
        *   Improved history logging around reset, in-the-weeds, and HLT.
        *   Emulator now starts before the first command, not after.
        *   Debugger requests clean exit from main loop, rather than just
            exiting the emulator entirely.
    * Added documentation on the Cheat facility.
        *   You may provide up to 8 cheats (CHEAT0 through CHEAT7).
        *   See doc/jzintv/cheat.txt for more details.

----------
 Changes:
----------

*   jzIntv
    *   Batch mode:
        *   Defaults to rate-control off.
        *   AVI recording defaults to 1x time scale when in batch mode with
            rate control disabled.
    *   Improved reset emulation:
        *   --rand-mem now randomizes CPU registers at reset.
        *   CPU registers and flags no longer reset when resetting mid-game.

*   Documentation:
    *   Documented how to manipulate CPU flags with the 'g' debugger command.
    *   Documented the (already present) 'v' debugger command.

-------------------------
 Cleanups and bug fixes:
-------------------------

*   Improvements:
    *   Removed various unused/defunct files from source tree.
    *   Lazier controller pad / ECS keyboard updates.
    *   Allow quoted strings in CFG file macros that take string arguments.
    *   Optimized transposed-keyboard code in ECS keyboard scanner.
    *   Scale audio buffer depth based on SDL's reported buffer size.
    *   Flush and close CSAV, CLOD when returning to ECS BASIC prompt, rather
        than the next ECS BASIC command.
    *   Cleaner handling of momentary pause when toggling full-screen,
        as well as the initial pause at emulator startup.
    *   Retire -Dlinux, -DPLAT_MACOS from Makefiles. Set PLAT_LINUX, PLAT_MACOS
        in config.h.
    *   Add new buildcfg/ directory to clean up how Makefiles are configured:
        *   MacOS X and Linux Makefiles now have sane out-of-the-box defaults
            that don't tie to a specific compiler version.  More to come.
        *   SVN version detection fails cleanly when not in an SVN working
            directory.  Also fully avoids network access.
        *   R-Pi builds now use the main Linux Makefile.
    *   Move OS/X SDLmain.* to plat/SDL_osx_main.*.
    *   Add new POP_UP action that pops the keyboard map stack on key release.
    *   Use POP_UP when releasing WIN/CMD/META to leave Map 3.  Avoids 
        edge conditions where we sometimes get stuck in Map 3.
    *   Add Clang pragmas to not complain about unreachable code in generated
        Bison and Flex output.  Allows enabling -Werror for Clang builds.
    *   Slightly more conservative CPU instruction cache invalidation.
    *   Add additional error checking to cart.mac ROMSETUP.
    *   Begin refactoring GFX module so less code is in SDL backends.  This
        is just the tip of the iceberg.
    *   Use -flto=auto w/ GCC to scale to the actual number of cores.
    *   Print messages from JLP savegame emulation for read, write, and erase
        commands, rather than just read.
    *   Spelling and typo fixes in intro_to_cp1600.txt.
    *   Remove -Dtermux, relying on __TERMUX__ instead.
    *   Prep work to decommission Makefile.termux_* in favor of just using the
        main Makefile.linux_*; however, it's not removed yet.
    *   Updated the FSF's address in files under src/., and in the various
        license files.
    *   Convert some source files to DOS text format rather than UNIX.

*   Fixed bugs:
    *   Intellivoice min tick too high; deadlocks with small audio buffers.
    *   PREVMAP accidentally did NEXTMAP, not PREVMAP.
    *   Restore console output on Windows.
    *   Restore window decorations when toggling fullscreen back to windowed
        on Windows.
    *   Use C99-friendly forward declarations for palette_t in avi.h.
    *   Missing top-level const on prototypes causes warnings in MSVC.
    *   Crash when using --rand-mem and .ROM files.
    *   Explicitly mute audio when there's no sound (e.g. when stopped at a
        breakpoint).  Fixes looping noise in SDL2 builds.
    *   Pause when auto-toggling to full screen when resuming in debugger.
    *   Explicitly set sRGB colorspace on Mac w/ SDL2 to get correctly
        managed color on multi-monitor systems.
    *   Add missing periph_reset() call in one of the reset paths.
    *   Update comment in mapping.c to correctly describe what the four
        default maps are.
    *   Fix examples/kbd_test so it assembles properly.