I've just tried running rustzx on ARM, using soft mesa opengl, but it failed to start:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: CompilationError("0:1(10): error: GLSL 1.40 is not supported. Supported versions are: 1.10, and 1.20\n")', src/libcore/result.rs:785

Probably means the default OpenGL 3.3 is required again? I wonder if you could switch to polydraw once it's ready, as it's going to support many different GL/ES backends.

On ARM Linux, I'm unable to run any downloaded roms:

$ RUST_BACKTRACE=1 ./rustzx --rom ../../Some_Rom.tzx

thread 'main' panicked at 'index 42629 out of range for slice of length 16384', src/libcore/slice.rs:549
stack backtrace:
   1: 0xb6f7cc23 - std::sys::backtrace::tracing::imp::write::hf504bc08f2a3011f
   2: 0xb6f80b7b - std::panicking::default_hook::_{{closure}}::h49b28af2d05b6140
   3: 0xb6f7f30b - std::panicking::default_hook::hf5d79ad4f1ead81e
   4: 0xb6f7fa67 - std::panicking::rust_panic_with_hook::h9a3925e37821d434
   5: 0xb6f7f8e3 - std::panicking::begin_panic::h240b4915cec4a07c
   6: 0xb6f7f85f - std::panicking::begin_panic_fmt::hcfb5c8e1936587e5
   7: 0xb6f7f7ef - rust_begin_unwind
   8: 0xb6f8de7b - core::panicking::panic_fmt::h92d7d79877c10aae
   9: 0xb6f8df53 - core::slice::slice_index_len_fail::h0ead1e2e3326bfc4
  10: 0xb6e4ad5f - core::slice::_<impl core..ops..IndexMut<core..ops..Range<usize>> for [T]>::index_mut::h31ebe17e01f75d06
                at /rust/rust-master/src/libcore/slice.rs:683
  11: 0xb6e4a1d7 - core::slice::_<impl core..ops..IndexMut<core..ops..RangeTo<usize>> for [T]>::index_mut::h771fe2e82fcced80
                at /rust/rust-master/src/libcore/slice.rs:705
  12: 0xb6e7171f - rustzx::zx::memory::ZXMemory::load_rom::h9d6c49208f6daf5e
                at /home/odroid/rustzx/src/zx/memory.rs:142
  13: 0xb6e72497 - rustzx::zx::controller::ZXController::load_rom::h46185b805a5fc1f0
                at /home/odroid/rustzx/src/zx/controller.rs:120
  14: 0xb6e7fc2f - rustzx::emulator::Emulator::new::h4ae3c17883f6b238
                at /home/odroid/rustzx/src/emulator/mod.rs:28
  15: 0xb6e7b35f - rustzx::app::rustzx::RustzxApp::from_config::h298f9aba9b39d55e
                at /home/odroid/rustzx/src/app/rustzx.rs:60
  16: 0xb6e826df - rustzx::main::h6b31a6d2189678aa
                at /home/odroid/rustzx/src/main.rs:54
  17: 0xb6f7f717 - std::panicking::try::call::h8e1d2d9d7dca0745
  18: 0xb6f8875f - __rust_try
19: 0xb6f8860f - __rust_maybe_catch_panic
  20: 0xb6f7e8af - std::rt::lang_start::h30b674bef4ff14e2
  21: 0xb6e851a3 - main
  22: 0xb6c0b66f - __libc_start_main

Compiled with rustc 1.12.0-dev (34f35ed29 2016-07-17)

• [x] Drag n drop
• [ ] Palette configuration
• [ ] Config files
• [ ] Tape autoloading
• [ ] Fast save/load
• [ ] App icon with sdl
• [ ] Keys bindings
• [ ] Controller support
• [ ] More snapshot formats

Work on 128K implementation was started in develop branch

• [x] Memory
• [x] Screen validation on bank switch
• [x] Check contentions
• [x] Loading custom 128K ROM
• [x] Window size option
• [x] AY flag
• [x] Mixing Beeper and AY
• [x] Joysticks

During the final link on an ARM Linux system, I'm getting this error even though I've got libjack installed:

note: ../rustzx/target/release/deps/libportaudio-cf78f0b5104b5853.rlib(pa_jack.o): In function `BuildDeviceList':
pa_jack.c:(.text+0x844): undefined reference to `jack_client_name_size'
pa_jack.c:(.text+0x868): undefined reference to `jack_client_name_size'
pa_jack.c:(.text+0x89c): undefined reference to `jack_get_ports'
pa_jack.c:(.text+0x9f4): undefined reference to `jack_client_name_size'
pa_jack.c:(.text+0xc0c): undefined reference to `jack_get_sample_rate'
pa_jack.c:(.text+0xe00): undefined reference to `jack_get_ports'
pa_jack.c:(.text+0xe58): undefined reference to `jack_port_by_name'
pa_jack.c:(.text+0xe64): undefined reference to `jack_port_get_latency'
pa_jack.c:(.text+0xef8): undefined reference to `jack_get_ports'
pa_jack.c:(.text+0xf50): undefined reference to `jack_port_by_name'
pa_jack.c:(.text+0xf5c): undefined reference to `jack_port_get_latency'

and so on. What are the required dependencies again? (static versions?)

Added drag-n-drop functionality for files (from #29). Currently only tap and sna are supported:

• Dropping .tap file inserts it as current tape (without starting or autoloading, the same as --tap command line argument)
• Dropping .sna file loads snapshot immediately

Currently, there's no visual indication if drop is successful or failed (for tap it's invisible, as it just inserts tape).

File format is currently detected only by extension (case-insensitive).

Paths with malformed unicode are not supported: SDL returns filename as String.

Added directory with files for tests, currently it's accessed via CARGO_MANIFEST_DIR, there are other approaches, like env::current_exe, but there's no standard idiomatic approach. Currently there's only one tap file.

This branch is based on update-sdl branch (#33), as older SDL does not work on my machine.

I couldn't built sdl2's dependency rustc-serialize on my machine, it fails with following error

error[E0642]: patterns aren't allowed in methods without bodies
   --> /Users/kolen/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-serialize-0.3.19/src/serialize.rs:147:45
    |
147 |                                             &f_name: &str,
    |                                             ^^^^^^^
...
error: aborting due to previous error

For more information about this error, try `rustc --explain E0642`.
error: Could not compile `rustc-serialize`.

So I updated sdl2 to latest version.

It had breaking changes, especially after 0.30, when Renderer was split into Canvas and TextureCreator. Also, now Texture has lifetime parameter, but it's not possible to store both TextureCreator and Textures into the same struct, because they're self-referencing. Because of this, sdl2 now has unsafe_textures feature, which is, AFAIK, similar to behavior before 0.30, and it's probably safe to use it as long as textures are not deallocated manually, and looks like rustzx does not deallocate textures prematurely.

However, I'm not sure about regressions, as there are lots of changes in sdl2. For me, it runs very slowly in debug version (in release it's ok). Probably I should first build with first working version of sdl2 and compare.

Make CI workflow for releasing new rustzx versions, so new versions could be released more easily. Workflow requirements:

• Create github releases page with change log and artifacts (use CHANGELOG.md and artifacts produced on the previous steps)
• Publish all rustzx crates to crates.io (last step)
• If possible, make draft release for dev branch and promote same release to non-draft when tag is pushed
• Perform dry run of cargo publish in dev branch
• If easy to implement, detect changes in crates and fail if forgot to raise version (check in dev branch)

Checklist

• [x] Check that pending version is bigger than already released
• [x] Check all publish = true crates version consistency
• [x] Check that git available
• [x] Check that user specified all required data (GitHub token, crates.io token, artifacts folder)
• [x] Check that artifacts folder is not empty
• [x] check that current commit (git call) exist in remote (via octocrab)
• [x] check that changelog was updated
• [ ] Add version bump functionality
• [x] crates are pushed
• [x] crates pushed in right order (via guppy)
• [x] create tag from commit (via octocrab GitHub API)
• [x] create github release
• [x] Implement --dry-run

Behavior: Load Wonderful Dizzy .tap, rutzx fails with error after displaying load-screen:

thread 'main' panicked at 'attempt to add with overflow', C:\projects\rustzx\rustzx-core\src\emulator\fastload\tap.rs:68:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\rustzx.exe -m128 --tape .\dizzy.tap` (exit code: 101)

Tap: https://yolkfolk.com/wonderful-dizzy/

Command:

cargo run --bin rustzx -- -m128 --tape .\dizzy.tap

Environment: Windows 10 21H1, rustc 1.56.0-nightly (ae90dcf02 2021-08-09)

Removed time crate, which is deprecated, replaced time::precise_time_ns with standard library's std::time::Instant.

I'm not sure if it worsened "smoothness" of emulation. It feels the same after this change. I'm not sure that std::time::Instant is as precise as time::precise_time_ns on most systems. However, it all boils down to thread::sleep, which can't be very precise, I think, due to nature of schedulers in standard non-realtime OSes, so nanosecond-grade precision for time measurements is probably not as important.

To get feeling how std::time::Instant works, I ran the following script:

use std::time::Instant;

fn main() {
    let mut t = Instant::now();
    loop {
        println!("{:?}", t.elapsed());
        t = Instant::now();
    }
}

It outputs something like this:

73ns
41ns
41ns
75ns
42ns
42ns
76ns
43ns
41ns
74ns
44ns
44ns
75ns
41ns
42ns
77ns
41ns
41ns

So probably quite precise on my system (Mac OS). Not tested on Linux and Windows.

• version from master branch (dd40dc4)
• Mac OS 10.13.6

It crashes after starting and typing few characters (probably even after first keypress)

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:345:21
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:70
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:58
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at src/libstd/panicking.rs:478
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:385
   6: std::panicking::try::do_call
             at src/libstd/panicking.rs:312
   7: core::char::methods::<impl char>::escape_debug
             at src/libcore/panicking.rs:85
   8: core::char::methods::<impl char>::escape_debug
             at src/libcore/panicking.rs:49
   9: sdl2::keyboard::Mod::from_bits
             at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libcore/macros.rs:10
  10: sdl2::event::WindowEventId::from_ll
             at /Users/kolen/.cargo/registry/src/github.com-1ecc6299db9ec823/sdl2-0.21.0/src/sdl2/event.rs:811
  11: sdl2::event::poll_event
             at /Users/kolen/.cargo/registry/src/github.com-1ecc6299db9ec823/sdl2-0.21.0/src/sdl2/event.rs:1173
  12: <alloc::borrow::Cow<'a, str> as alloc::string::ToString>::to_string
             at /Users/kolen/.cargo/registry/src/github.com-1ecc6299db9ec823/sdl2-0.21.0/src/sdl2/event.rs:1219
  13: <rustzx::app::events::events_sdl::EventsSdl as rustzx::app::events::EventDevice>::pop_event
             at src/app/events/events_sdl.rs:113
  14: rustzx::app::rustzx::RustzxApp::start
             at src/app/rustzx.rs:109
  15: rustzx::main
             at src/main.rs:54
  16: std::rt::lang_start::{{closure}}
             at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libstd/rt.rs:64
  17: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:297
  18: panic_unwind::dwarf::eh::read_encoded_pointer
             at src/libpanic_unwind/lib.rs:92
  19: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at src/libstd/panicking.rs:276
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  20: std::rt::lang_start
             at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libstd/rt.rs:64
  21: rustzx::main

Unwrap occurs in sdl2/event.rs in sdl2 crate.

                    keymod: keyboard::Mod::from_bits(event.keysym._mod as SDL_Keymod).unwrap(),

It does not occur in branch with latest version of sdl2. Probably fixed by this PR in sdl2: https://github.com/Rust-SDL2/rust-sdl2/pull/780

Hello,

I'd like to use your AYM emulation for my own Apple2 emulator. I've read your code but there's that function "decimate" which, I think, is there to help the downsampling, which has lots of hardcoded floats. Would you be care to explain what the function exactly do and how the floats were computed ? Thanks!

The initial implementation of RustZX core has been implemented with minimal optimizations, and as esp32 rustzx port demonstrated there is a lot to improve in the emulator core (by the way, big shout-out to @georgik and @ivmarkov for their work on esp32 port of this project 🎉 ! Running this thing on something like esp32 was the actual purpose of rustzx-core no-std capable crate separation).

This is an epic for tracking all optimizations which should be done to achieve emulation speeds competitive with C implementations of ZX Spectrum emulators

TODO:

• [ ] Optimize screen processing - it easily eats up to half of emulation time

rustzx v1.0.0 development branch scope:

Main epics

• [ ] #93

Features

• [ ] #110
• [ ] #111

Bugfixes

• [ ] #112
• [ ] #119

Dependencies

• [x] pacmancoder/rustzx#121

Produce static binaries for:

• [ ] Windows (Link with static runtime libraries)
  • Implementation tip: set target-feature=+crt-static rustc flag during compilation
• [ ] Linux
  • Implementation tips:
    • Use x86_64-unknown-linux-musl target
    • Check that binary is statically linked via ldd