Describe the bug
As it turns out, using pyinstaller or Nuitka to generate executables results in terrible experience both on Windows and macOS. On Windows application is detected either as Trojan or Virus. On macOS performance and ease of use is hindered because of system protective measures.

To Reproduce
Steps to reproduce the behavior:

1. Run sc64.exe on Windows OS
2. Executable is detected as malicious software

Expected behavior
sc64 executable shouldn't be detected as malicious software

Possible solution
Rewrite application in compiled language like C, Rust or Go.

Is your feature request related to a problem? Please describe.
The current readme flashcart features does not take into account the N64FlashcartMenu.

Describe the solution you'd like
Add a link to the repo.

Additional context
It should be obvious, but most people will not connect the dots. Most "users" will not read between the lines about how great both parts are when combined.

Firmware Version: V2.18.0

Menu Revision: V0.0.1.2023-12-23T00:55:08Z.ALPHA

Describe the bug
Ive been playing Paper Mario (PAL) for a bit and randomly the game just freezes after being left idle.
It doesnt crash and trigger the crash handler, it just stops moving intierly, with just the BGM continuing.

The Roms SHA-1: 2111D39265A317414D359E35A7D971C4DFA5F9E1
The Roms MD5 : A9BE6A493A680642D840F859A65816CA
The Roms CRC32: 85B3AB37

To Reproduce
Steps to reproduce the behavior:

1. Load the PAL Rom and load a Save
2. Do not touch the controller afterwards
3. Wait untill it freezes (Doesnt always happen)

Screenshots
If applicable, add screenshots to help explain your problem.

Expected behavior
No Freezes when left idle

Possible solution
Not obligatory, but suggest a fix/reason for the bug.

Can I use LCMXO2-7000HC-4TG144 instead of LCMXO2-7000HC-6TG144？

Is your feature request related to a problem? Please describe.
May or may not be a problem, but there is no hardware-specific license on the project.

Describe the solution you'd like
Consider adding something like the CERN OHL-S-2.0 license. This would add a license similar to GPL-3.0 but specifically for the hardware in the project

Describe alternatives you've considered
There are not really any other licenses geared towards hardware that are similar to GPL-3.0 other than CERN OHL-S-2.0

Additional context
https://opensource.org/license/cern-ohl-s/

Example repo with 2 licenses (and how GitHub can easily show multiple licenses)
https://github.com/MasonStooksbury/Hex-Clock

Quick overview of each

GPL-3.0 (Software License)

• Type: Designed specifically for software.
• Copyleft: Strong. Requires that derivative works of the licensed software are also distributed under the GPL.
• Distribution: Any distribution of the software, modified or not, must include the source code.
• Patent License: Provides an express grant of patent rights from contributors to users.
• Tivoization: Prevents "Tivoization," where hardware restricts software modifications.
• Compatibility: Can be complex when integrating with non-GPL software.
• Termination: Automatic license termination upon non-compliance, but allows for remedy.

CERN-OHL-S-2.0 (Hardware License)

• Type: Specifically for hardware designs.
• Copyleft: Strongly reciprocal. Requires that modifications/derivatives of the design are distributed under the same license.
• Distribution: Requires the distribution of all original and modified design files.
• Patent License: Includes clauses on patent licensing.
• Tivoization: Not applicable, as it focuses on hardware.
• Compatibility: More straightforward for hardware components but limits flexibility in combining with non-reciprocal designs.
• Termination: License persists as long as the conditions are met.

Key Differences:

• Purpose and Domain: GPL-3.0 is tailored for software, while CERN-OHL-S-2.0 is for hardware designs.
• Application: GPL-3.0 addresses software distribution and modification concerns. CERN-OHL-S-2.0 focuses on hardware design, production, and distribution.
• Specific Terms: Each license contains terms and conditions specific to its domain (software vs. hardware), reflecting the different concerns and practices in these areas.

Conclusion:

Both GPL-3.0 and CERN-OHL-S-2.0 are strong copyleft licenses but in different domains. GPL-3.0 is ideal for developers who want their software and its derivatives to remain open source. CERN-OHL-S-2.0 suits hardware designers seeking to ensure that their designs and any derivatives stay open source. The choice between these licenses depends on whether the project is software or hardware-focused and the desired level of control over derivatives.

My main issue is I absolutely cannot get FT_PROG to see the cart through the usb connector no matter what I do. Even after erasing and rebuilding the EEPROM with libftdi and installing the drivers from the ftdi website there's still nothing there. But I CAN get libftdi's utilities to work with it. I have written a config file myself based on the XML template, but there are options in one that I don't see in the other and it makes me quite nervous. Been having trouble finding documentation on the libftdi conf options as well.

If there's any way you would either know what the options should be, or have a way of dumping them and shipping them alongside the xml, it would be greatly appreciated.

This is the config file I wrote based on what I saw in the XML. Does this look ok?

vendor_id=0x403
product_id=0x6014

# The rest of the fields are settings which can be written to the
# FT2xx with the --flash-eeprom option.

# Max. power consumption: value * 2 mA. Use 0 if self_powered = true.
max_power=500

###########
# Strings #
###########
manufacturer="Polprzewodnikowy"
product="SC64"
serial="SC64xxxxx"

###########
# Options #
###########
self_powered=false  # Turn this off for bus powered
remote_wakeup=false # Turn this on for remote wakeup feature
use_serial=true     # Use the serial number string

# Normally out don't have to change one of these flags
in_is_isochronous=false     # In Endpoint is Isochronous
out_is_isochronous=false    # Out Endpoint is Isochronous
suspend_pull_downs=false    # Enable suspend pull downs for lower power
change_usb_version=false    # Change USB Version
usb_version=0x0200          # Only used when change_usb_version is enabled

cha_vcp=true
cha_type=FT1284
#chb_type=UART

########
# Misc #
########

# This is the relative filename that EEPROM contents will either be 
# read from or written to, depending on whether ftdi_eeprom is run
# with the --read-eeprom or --flash-eeprom option.
filename="eeprom.bin"

FT_PROG does see the cart if I use the UART header but not the usb connector. :(

EDIT: After a... lot of googling I finally found some documentation listing all the possible values.

Expected Behavior

Ease of use for average user.

Current Behavior

Requires python and dependencies to be installed.

Possible Solution

Installing python should not really be required for the average user, so let's generate a standalone application as part of the release process... at least for the loader.

Steps to Reproduce

Context (Environment)

Mainly a windows environment.

Detailed Description

Possible Implementation

Use something like pyinstaller.

Describe the bug
CIC emulation doesn't adhere to timings generated by real CIC chip in two locations: before sending encoded checksum and before sending x105 algorithm result. This makes games boot faster than on real cartridge.

To Reproduce
Steps to reproduce the behavior:

1. Run game on SC64 with direct mode enabled
2. Measure timings
3. Run game on retail cartridge
4. Measure timings

Screenshots
No screenshots.

Expected behavior
Timings should be close to the real CIC chip.

Possible solution
Add delay between detecting falling edge of CIC clock and falling edge of CIC data in locations mentioned above.

Is your feature request related to a problem? Please describe.
Some SD cards behave different from each other. There's no way to detect what went wrong when card misbehaves. Some kind of diagnostics would help with issues similar to one described in #30.

Describe the solution you'd like
Implement a set of error codes corresponding to error location (specific SD command or data timeout).

Describe alternatives you've considered
No alternatives were considered.

Additional context
Issue #30.

When developing the N64FlashcartMenu, it is advantagous to be able to "save" or "overwrite" certain ROM's to the SD card without having to remove the SD card.

examples:

• replace the current sc64menu.n64 at certain save points.
• Add a new ROM for testing.
• overwrite the config.ini

Currently it requires that I remove the SD card to manage its content.

I propose that theUSB loader functionality is able to support it.

Describe the bug
Using this SD card results in A hard error occured in the low level disk I/O layer.

To Reproduce
Steps to reproduce the behaviour:
1.
2.
3.
4.

Screenshots

Expected behavior
A clear and concise description of what you expected to happen.

Possible solution
Not obligatory, but suggest a fix/reason for the bug.

Originally posted by @xgsh159 in #58