Current Behavior

At present, the Floppy Emulator invariably initiates as a Virtual A unit, undergoing the subsequent stages:

• [NEW in v0.0.11] The emulator verifies if a floppy is connected. Absent that, it establishes a virtual A drive placeholder.
• The Physical drive A is reconfigured and recognized as Physical drive B.
• The system attempts booting from the virtual drive A.

Due to this setup, users who wish to operate the physical drive A have to access it as unit B. This limitation impedes users from booting using the physical drive and could render specific software inoperative.

Proposed Enhancement

We propose granting users the flexibility to decide between the default operational sequence detailed above and an alternative where they can allocate the virtual drive to unit B, enabling them to boot from the physical A drive.

Bonus: An optional feature could be a flag, allowing users to opt whether or not to boot from the virtual floppy, even when designated as the A drive.

Documentation describes the CSV with five fields but provides an example of six fields, which is correct and working. But what is missing and has what meaning?

WIP in https://docs.sidecart.xyz

Description

Due to the limited size of the shared memory between the RP2040 and the Atari ST, the total number of elements in the list can't be more than 4KBytes.

This is not a problem for the number of ROMs available for the Atari ST, but it is an issue for the number of available collections of software from crews.

Workaround

Until a better solution is found, you can have only approx 150 files in the /floppies folder.

Another alternative can be to have multiple folders on the microSD card and place a maximum of files there. Then, modify the Configuration parameter FLOPPIES_FOLDER and point to the required folder containing the images.

Description:

To enrich the available software for Atari ST, integrating a pre-existing program database, such as the Atari ST Disk Image Database from TOSEC, is recommended.

Expected Behavior:

Reference: Atari ST Disk Image Database

• The system should facilitate users to download the database file into the /floppies directory and juxtapose the contents of this folder with the database file, optimal for a localized, non-networked user experience.

For Networked Experience:

Users with network access can potentially have an enriched experience by executing the process externally or by acquiring content on-demand, ensuring continuous access to the latest software available.

Proposed Workflow:

1. Local-only Experience:

   • Download the database file to the /floppies directory.
   • System parses and compares the folder content against this file.
   • Access to a localized Atari ST software database is achieved.

2. Networked Experience:

   • Enables external execution or on-demand content download.
   • Offers more flexibility and up-to-date access to the Atari ST software database.

Leveraging a well-established database, this feature aims to amplify software accessibility and enhance user experience, addressing both local and networked use cases.

Feature Description:

A significant addition would be the emulation of Atari ST floppy drives. This feature will provide an even more genuine and authentic retro computing experience for users by allowing them to load, save, and run software just as they would with a physical floppy disk.

Proposed Implementation:

1. Floppy Disk Image Loading:

   • Allow users to load .ST or .MSA floppy disk images from the microSD card or via a Wi-Fi connection.

2. Drive Selection & Management:

   • Provide options for users to select which virtual drive (A or B) they wish to insert the disk image into.
   • Offer disk eject and disk swap functionalities.

3. User Interface Enhancements:

   • Add relevant options and functionalities in the SIDECART.TOS application to manage the emulated floppy drives.

Benefits:

• Enhanced Retro Experience: By adding floppy drive emulation, SidecarT can provide an even deeper dive into the world of Atari ST, enhancing the retro experience.

• Broader Software Accessibility: Users can access a wider range of Atari ST software that was originally distributed on floppy disks.

• Preservation: Aids in the preservation of floppy-based software and games, ensuring they remain accessible.

Conclusion:

The addition of floppy drive emulation will augment the capabilities of SidecarT, making it an even more comprehensive solution for Atari ST enthusiasts. This feature is in line with SidecarT's mission to bridge the gap between genuine tactile retro computing experiences and modern emulation features.

A floppy image has an average of 700-800Kb, making it hard to copy the whole tracks of the image as raw in the available flash memory of 2Mbytes. As an alternative, implement a solution that browse a remote http server and allows the download of an images to the microSD card.

The download should have two options:

1. Download the image as a temporary file.
2. Download the image and keep it in the /floppies folder

Description

Previously, when a user resets the Atari ST when in floppy emulation mode, the firmware tried to open another descriptor for the floppy file image without closing the previous one. This could create a problem of performance and/or memory leaks.

Solution

Now when the firmware receives a new LOAD_IMAGE after a reset it will try to recycle the existing file descriptors to avoid any memory leaks or performance issues.

Description

The SidecarT can be a very helpful device to troubleshoot damaged computers. A good use case is bypass the configurator and let the SidecarT to run a "default ROM" when plugged.

The possible use case is as follows:

1. The user places a ROM image in the root folder of the microSD card with the name "AUTOBOOT.IMG"
2. The Configurator at boot time detects the file and loads and launches it immediately.
3. The user must delete or rename the file in the microSD card to exit the 'Rescue mode'

The initial implementation of the Configurator utilized an asynchronous command pattern which was suitable for the early firmware versions. However, the evolution of command support now enables synchronous execution, which can significantly enhance the responsiveness of the Configurator UI.

Currently, the Configurator employs a fixed delay of two to four seconds for command processing on the RP2040, which is excessive considering most commands execute within milliseconds. Transitioning to a synchronous pattern will facilitate an active wait mechanism, substantially improving the perceived speed of interactions for the users.

The SIDECART.TOS should be loaded at boot time. If the user does not want to boot, simply wait for the menu to timeout. If not, press a key to load it immediately.

If the user does not press the key and enters GEM, it still can open it in the Cartridge drive.

If the computer does not have any physical floppy unit connected, the floppy emulator can't create the virtual drive A.

Hey, just my 2 centes. It would be nice to have a display to know which rom image is currently included. i think a simple i2c oled display should do the trick. They cost nothing, are supported by the raspi and the are available.

The proposal aims to augment the SidecarT board functionality on Atari ST by introducing a hard disk emulation mode reminiscent of GemDrive features found in STEEM and Hatari emulators.

GemDrive, a high-level filesystem driver, eases the reading of SD cards on Atari ST, steering clear of the archaic TOS/BIOS filesystem. By replicating the behavior of GEMDOS on TOS versions, GemDrive enables direct interaction with modern SD card libraries via the RP2040, modernizing data handling on the Atari ST. This implementation is set to support all standard PC-formatted SD cards with no size limit, significantly diminish the ST's RAM usage, offer an efficient medium swap feature, and provide a near-accurate imitation of GEMDOS, thereby rectifying common TOS filesystem bugs.

The new emulation mode will install the driver in the cartridge ROM address range. The GemDrive mode will streamline the GEMDOS call process by forwarding synchronous commands to the RP2040 and waiting for the response from RP2040, simplifying the whole algorithm. This proposed emulation mode is poised to enhance the SidecarT's utility by incorporating a modern data management solution within an Atari ST environment.

Implement a ROM emulation that mimics the behaviour of the Real Time Clocks using the Dallas RTC 1216 in the cartridge.

Support .MSA floppy images. At least for reading them and converting to .ST, the native format of the SidecarT.

Hatari is GPL, we are GPL...

https://github.com/hatari/hatari/blob/69ce09390824a29c9708ae41290d6df28a5f766e/tools/hmsa/hmsa.c#L235C1-L244C4

Description

Our current setup relies on downloading and emulating floppy disk images directly from a microSD card. This enhancement proposes an exploration into using the device's FLASH memory as an alternative storage medium for these images. The core of this proposal is to investigate the feasibility of downloading (or copying) floppy images directly into the FLASH address space and then emulating from there.

Implementation Challenges

The primary concern is not the emulation process from FLASH memory, but rather the memory capacity. A typical floppy disk image is nearly 900Kbytes, and our device's FLASH storage is limited to 2MB. Considering that our existing application already utilizes approximately 900Kbytes of this space, a careful evaluation is necessary.

The initial step in this enhancement is to assess whether a full floppy image can be accommodated within the available FLASH memory and to determine the exact amount of free memory that can be utilized.

Description

The remote ROMs and Floppy catalogs have information in the form of taxonomies and collection creator. This information should be displayed to help the users to know what they are running.

Solution

• The ROMs now displays the size and the taxonomies
• The floppies now displays the disk collection creator, if any

Problem Overview:

Currently, pressing the SELECT button causes the SidecarT to immediately switch to CONFIGURATOR mode, potentially leading to unexpected errors.

Proposed Solution:

Introduce a SAFE_CONFIG_REBOOT flag with possible values of true or false.

• If false, the existing behavior remains unchanged.
• If true, pressing the SELECT button will not cause an immediate reboot. Instead, the RP2040 will change the board's status for the subsequent Atari ST power cycle, ensuring a smooth transition without disrupting ongoing processes.

By default, the SAFE_CONFIG_REBOOT flag should be set to true to prevent unforeseen data loss.

Description

The domain "sidecart.xyz" was mistakenly flagged as malicious by a major corporation's threat detection system. This false positive adversely affected our project's search engine optimization (SEO) and compatibility with certain deep inspection tools, particularly impacting our download engine.

Solution

Identifying the ".xyz" domain as the root of the issue, I have transitioned all system URLs to the new domain "sidecartridge.com," which is expected to have a significantly better reputation. In addition, the firmware has been updated to automatically replace any references to "sidecart.xyz" with "sidecartridge.com" to ensure seamless integration.

STE hanging after boot to desktop with Beta v0.0.12

I have an Atari STE running TOS 1.62, 4Mb Ram

I have updated to v0.0.12 but I now get lockups of system hanging when I get to the desktop, I may be able to move the mouse for a few seconds and then the machine locks up.

I have reverted to 0.0.11 and everything seems ok again.

Like in the Network status bar, show information on the screen about:

• microSD is mounted or not
• size in MB of the card and space consumed
• If the ROMS folder exists or not. If it exists, show the number of files.
• If the Floppies folder exists or not. If it exists, show the number files.

Some texts can be confusing and hard to understand. Please rewrite and reposition in the right place on screen.

This feature seeks to further extend the capabilities of the GEMDRIVE Hard Disk Emulation Mode on the SidecarT Board for Atari ST by enabling the mounting of Common Internet File System (CIFS) and Network File System (NFS) drives on top of it.

The implementation is dependent on the successful operation of the GEMDRIVE Emulation Mode, serving as a prerequisite. Once GEMDRIVE Emulation is fully functional, the new feature will allow users to seamlessly access, manage, and share files located on CIFS or NFS drives directly from their Atari ST systems. By bridging modern network file sharing protocols in the Atari ST environment through the GEMDRIVE emulation layer, this feature intends to provide a robust and contemporary file management solution, enhancing the overall user experience and the utility of the SidecarT Board.

Description

The floppy emulation process involves two key modifications:

• Hooking the hdv_* vectors, a high-level approach ideal for GEM applications and many cracked games.
• Intercepting XBIOS calls for sector read/write operations, a low-level method used by applications that directly access the disk through XBIOS.

However, hooking XBIOS calls leads to issues with:

• Early TOS versions (1.00 and 1.02), resulting in the inability to display the contents of the emulated disk.
• Certain games and applications that interpret the XBIOS hook as a crack or virus.

Solution

The updated firmware for floppy emulation now includes an option to disable XBIOS hooks at boot. This feature is particularly beneficial for users of TOS 1.00 and 1.02, allowing the floppy disk to be browsable.

Activation Method

To activate this feature, simply press the LEFT SHIFT key during boot when the loading screen appears.

Current Functionality

At present, the floppy emulator is designed to support a single virtual floppy drive, automatically designated as Drive A. In cases where a physical floppy drive exists as Drive A, the emulator assigns it as Drive B, thereby relegating the physical drive to a secondary position. This setup does not support the simultaneous emulation of two floppy drives, which limits the functionality in certain use cases.

Limitations of Current Setup

• Inability to emulate two drives simultaneously for systems that require or benefit from dual-drive operations.
• Restriction in scenarios where software demands the presence of both an A and a B drive, rendering such software incompatible with the current emulator setup.
• Users with a physical drive A are forced to work with a single emulated drive, missing out on the full capabilities of dual-drive software.

Proposed Enhancement

We propose an expansion of the emulator's functionality to include the support of two simultaneous virtual floppy drives, designated as Drive A and Drive B. This will allow for a complete virtual replacement of physical floppy drives, where necessary.

Details of the Enhancement:

• Users will be able to select two separate floppy images, one for each of the virtual drives, through the emulator's interface before booting.
• Upon booting, the emulator will present two accessible virtual drives (A and B) to the system, each with its respective loaded image.
• This feature will facilitate the running of legacy software or systems that were originally designed to operate with two floppy drives, enhancing the emulator's versatility.

Anticipated Benefits

• Eliminates the need for a physical floppy drive, offering a fully virtualized dual-drive environment.
• Expands the range of compatible legacy software that can be used with the emulator.
• Provides greater flexibility in managing floppy disk data, particularly for tasks that require frequent swapping between two disks.

Conclusion

By introducing the ability to emulate both Drive A and Drive B simultaneously, we not only enhance the emulator's compatibility with dual-drive dependent software but also provide a more comprehensive and flexible tool for users who require or desire a dual-drive setup for their computing environment.

More collections available, counting 3300 applications.

The crews cataloged are:

• ADRENALIN
• AUTOMATION
• CYNX
• DBUG
• FOF
• MEDWAY
• POMPEY PIRATES
• SUPERIOR
• THE DELIVERANCE

When initiating Wi-Fi configuration, the displayed list of available Wi-Fi networks seems incomplete, as it only shows a limited number of networks despite there being more accessible ones in my vicinity. Consequently, I am unable to locate and connect to my preferred network as it does not appear in the provided list. Is there a method to connect to a Wi-Fi network that isn’t displayed?

Provided Workarounds:

1. Quick Solution:

   • Repeatedly access '3. Wi-fi Configuration' until your Wi-Fi network becomes visible. It should eventually appear on the list.

2. Alternative Solution:

   • Navigate to '4. Sidecart Configuration' and adjust the configuration parameters as mentioned below:
     • WIFI_SSID: Input the name of your network.
     • WIFI_PASSWORD: Enter the password for your network.
     • WIFI_AUTH: Assign values corresponding to the network's security protocol. Utilize 5 for WPA2 (most prevalent), 1 for WPA, and 0 for open networks.
   • Ensure to save the newly entered parameters. After saving, perform a computer reset. The device should now connect to the Wi-Fi network without any issues.

Reminder:

Do not overlook to save the modifications after adjusting the new parameters to ensure a smooth connection upon resetting the computer.

Description

The Atari MegaSTE, featuring a 16MHz CPU with cache, has encountered issues, particularly when the cache is active. These include:

1. Misalignment of signals between the cartridge port and the computer's address and data bus.
2. Erroneous data during emulation modes.

Previous Workaround

Initially, the workaround involved operating the Sidecart at 8MHz without cache.

Solution

The latest firmware update introduces several improvements:

• Enhanced synchronization between the RP2040 and the computer's address and data bus, supporting both 8MHz and 16MHz operations.
• Automatic switch to 8MHz, cache-disabled mode during "hybrid mode" operations involving volatile data in ROM4 and ROM3 ranges. The firmware now detects a MegaSTE system and adjusts read/write operations to ROM3 and ROM4 accordingly, ensuring reliability.

The underlying issue stemmed from the CPU's cache algorithm. The CPU was unaware of external changes to ROM content by devices like the RP2040, leading to outdated, cached data being returned. The resolution involves either invalidating the cache or, more effectively, designating exclusion zones where the cache is disabled.

When attempting to delete characters within open fields, such as Wi-fi passwords or configuration parameters, the application is incorrectly interpreting the delete key stroke. Instead of removing the character, it's storing and displaying the VT-52 codes for the delete key (black and white). This issue makes it impossible for users to correct a mistake within these fields.

Suggested Resolution:

• Adjust the input handling mechanism to correctly interpret the delete keystroke and remove the intended character from the input field.

The GEMDOS calls of the Configurator are hard to control multiple repeats and keystrokes. BIOS keyboard calls should manage the keyboard better.

Description

A number of users have experienced issues with the system displaying "bombs" when resetting their computer, as prompted by the Configurator app. This problem appears to stem from a timing conflict caused by two simultaneous factors:

• Immediate key presses by users in response to the Configurator's prompt.
• Inadequate response speed in the reset code execution.

Proposed Solution

Addressing this issue effectively requires a two-pronged approach:

1. Optimization of ROM/Floppy Emulator Activation Speed: The primary cause of delay has been identified as the time taken by the blinking LEDs, surprisingly enough. Enhancing this process is crucial.

2. Incorporation of Additional Delay in the Code: To compensate for any remaining lag in response time and prevent premature key presses from causing errors, introducing an additional delay within the code is advisable. This would ensure more reliable and user-friendly operation post-reset.

It would be great if the SidecarT could be configured to emulate a Cubase dongle. I would be happy to work on this, but would need some guidance on where to start - I'd have thought it ought to be relatively trivial, but maybe it isn't as simple as I think :)

Issue:
Opening the directory window of emulated drive A: does not work. The window seems to "fly out of the screen" at the upper left corner. Re-trying several times leads to a "too many open windows" error.

This behaviour is independent from the "Disable XBIOS trap" feature. It occurs with or with out the trap enabled.

Impact:
Prevents usage of floppy images which do not auto-run a program, e.g. application floppies, data floppies. Makes copying files into a writeable floppy image more inconvenient.

Steps to reproduce with TOS 1.00/1.02:

• create an empty ST image from the SidecarT Configurator (Option 3. or 4.)
• choose the new/empty image for emulation (Option 3. or 4.)
• restart the ST
• try to open floppy A:

Test envionment:

• 520ST TOS 1.00 German 4MB
• 1040STFM TOS 1.02 German 4MB
• issue not present on Mega ST TOS 1.04 German 4MB

The floppy emulator fails if a program tries to read or write to odd memory addresses. It should allow to read or write on any memory address given.

Overview

With the growing user base of SidecarT, the need for extensive and stability-focused testing is becoming increasingly important. To address this, we propose introducing two distinct release workflows: BETA and FINAL releases. This approach aims to balance the needs of our diverse user community, ranging from makers to those seeking more stable and reliable software.

Proposed Release Workflows

1. BETA Release Workflow: This will cater to users who are interested in testing the latest features and providing valuable feedback. It will allow us to incorporate user experiences into development, ensuring that the software meets a wide range of needs and use cases.

2. FINAL (or Latest) Release Workflow: Aimed at users who prioritize stability and reliability. This workflow will focus on delivering a polished and thoroughly tested version of the software, thereby reducing support queries and enhancing user satisfaction.

Implementation Details

• Users will have the option to download either a BETA or FINAL firmware version.
• A notification mechanism will inform users of new releases based on their preferred version. This will be controlled through the LATEST_RELEASE_URL parameter in their configuration.
  • If LATEST_RELEASE_URL points to http://atarist.sidecart.xyz/version.txt, users will be notified about the availability of the FINAL (or latest) release.
  • If LATEST_RELEASE_URL points to http://atarist.sidecart.xyz/version-beta.txt, users will be alerted when a new BETA release is available.
• The goal is to have one FINAL release per version, accompanied by multiple BETA releases as needed for thorough testing and feedback.

Expected Benefits

This dual-release strategy is expected to enhance the overall quality of SidecarT software, aligning with the varied expectations of our user community. It allows for early detection and resolution of issues, fostering a more robust and user-friendly product.

Summary

Leverage the Bluetooth capabilities of the Raspberry Pi Pico W in the SidecarT board to create a driver that emulates remote keyboard and mouse devices, enhancing the interaction with the Atari ST system.

Description

The Raspberry Pi Pico W on the SidecarT board comes with Bluetooth functionality alongside WiFi. While the WiFi capabilities have been utilized, the Bluetooth functionality remains untapped. This feature aims to develop a driver that can emulate a keyboard and mouse over Bluetooth, allowing users to interact with their Atari ST system wirelessly.

Key Points

• Driver Development: Create a Bluetooth driver to emulate keyboard and mouse actions.
• Ease of Connectivity: Simplify the pairing process for a hassle-free connection between Bluetooth devices and the SidecarT board.
• Low Latency Interaction: Ensure low latency for a smooth user experience.
• Cross-Device Compatibility: Make the driver compatible with a wide range of Bluetooth-enabled keyboard and mouse devices.

This feature proposal seeks to enhance user accessibility and interaction with the Atari ST system by introducing Bluetooth keyboard and mouse emulation, providing a modern and wireless mode of interaction.

Computers with 1MB or less of memory fail to start the SIDECART.TOS. The new version works around this issue with better memory management.

Some WiFi networks are protected by MAC-address filter. In order to be able to connect to the WiFi network the MAC address of the SidecarT Pi Pico must be added to the allow list. Consequently the WiFi SidecarT configuration should show the MAC address od the Pi Pico.

Description

Develop a driver bootable as a ROM that seamlessly sets time and date. The date and time should be taken from an internet NTP server when the Wifi is available.

Would it be possible to have a text file somewhere to predefine configuration parameters?
My "issue" is that my WiFi password is very long, strong and therefore very difficult to enter.

After resetting the sidecart, upon launch I find that often wifi won't connect and just displays error - it won't reconnect until I go into wifi configuration and re-enter details, even though the details already exist and are correct in the SidecarT configuration screen.

Perhaps there's some sensible heuristic to retry connecting if it fails sometimes, or failing that, maybe manual disconnect/connect shortcuts would be helpful.

To avoid conflicts in the status when changing to a new network, now the Wifi configuration menu ask the user to leave the current network before joining a new one.

Experiencing a system crash characterized by four bombs occurs when skipping the CONFIGURATOR during boot into GEM on TOS 2.06 without any disk drives attached.

A practical workaround involves booting the system with at least one disk drive (floppy or hard disk) connected to prevent the crash.

There are various compressed file formats that are practically impossible to use with the ST 8MHz 68k but the RP2040 could decode them and present to the ST in a more usable format (e.g. RAW)

e.g. MP3 Audio

How best to implement? Perhaps start by emulating a stereo sound digitiser cartridge that existed?

https://temlib.org/AtariForumWiki/index.php/Sound_Samplers

Some file selector to choose the remote file to start streaming?

Description

Currently, users looking to copy content to a floppy disk image are required to work with pre-existing images in the /floppies folder. This approach is not only inconvenient but also prone to errors, especially when managing multiple images or ensuring data integrity.

To streamline this process and enhance user experience, we propose the introduction of a feature that allows the creation of new, empty floppy disk images directly within the system. This feature will be integrated into the existing workflow, offering an efficient and user-friendly way to generate new .ST image files without the need to rely on external tools or pre-existing images.

User Workflow

Upon selecting the option to create a new empty floppy disk image, the system will guide the user through a simple, interactive process:

1. Prompt for New Floppy Image Name: The user will be asked to provide a unique name for the new floppy disk image. This name will be used to identify the image file within the /floppies directory.

2. Select Number of Sides: The user can specify the number of sides for the floppy disk. This choice determines the disk's storage capacity and is critical for ensuring compatibility with the intended use case.

3. Choose Number of Sectors: The user will choose the number of sectors per track. This decision impacts the total storage capacity of the floppy disk and should be made based on the specific requirements of the content to be copied.

Post-Creation Actions

Once the user completes the above steps, the system will execute the following:

• Create the New .ST Image: The system will generate a new, empty .ST floppy disk image based on the provided specifications. This image will be automatically saved in the /floppies folder with the designated name.

• Automatically Mount the New Image: The newly created floppy disk image will be automatically mounted. This ensures that it is immediately available for use, streamlining the user's workflow.

• Reboot in Read/Write Mode: To facilitate immediate use, the SidecarT system will reboot into Read/Write mode with the new floppy disk image mounted and ready for content copying.

Conclusion

This new feature will significantly improve the flexibility and efficiency of the floppy emulation process. By enabling users to create bespoke, empty floppy disk images on demand, it eliminates the dependency on pre-existing images and reduces the potential for errors. This enhancement will be particularly beneficial for users regularly dealing with a variety of content and requiring custom storage solutions.

Description

Previously, the read and write routines in our floppy emulation adhered strictly to official documentation when saving and restoring registers. However, this approach led to compatibility issues with some applications that deviated from the documented standards. For instance, while routines were expected to clear only the lower word (D0.W) of a register upon exit, certain applications anticipated the entire long word (D0.L) being cleared, aligning with actual TOS behavior.

Solution

The functions have been updated to better reflect the real-world behavior of the TOS code, rather than strictly adhering to the documentation. This change aims to improve compatibility with a broader range of applications by aligning more closely with their operational expectations.

Background:

The 'Ultimate Ripper' software exhibits a specific behavior when handling the programs to rip:

• The 'Ultimate Ripper' cartridge is plugged in, but with its power switched off, thus the ROMs aren't loaded.
• Users then load the application meant for ripping.
• Next, they press and hold the computer's RESET button while activating the cartridge.
• Upon releasing the RESET button, the ROM-based ripper takes charge of the computer.

Proposal for SidecarT:

To emulate the above behavior in SidecarT, I suggest the following approach:

1. Introduce DELAY_ROM_EMULATION Flag:

   • This configuration flag determines the boot behavior of the ROMs.

2. Behavior with DELAY_ROM_EMULATION set to TRUE:

   • In EMULATOR mode, SidecarT initiates, but the ROM's memory range in the RP2040 remains unallocated. Like an unglugged cartridge.

3. Switching to Classic EMULATOR Mode:

   • Holding the SELECT button for over a second makes SidecarT revert to the classic EMULATOR mode.

4. Transition to CONFIGURATOR Mode:

   • If the SELECT button is pressed again after the above step, the device switches to CONFIGURATOR mode, consistent with its usual behavior.

End-User Experience:

By loading a program, pressing SELECT for more than a second should activate the ROM. To load it, the user should press the RESET button of the ATARI ST. Then the computer should boot the ripper program. SidecarT should replicate the experience provided by the vintage "Ultimate Ripper".

Summary:

Since the Sidecart has the capability to be continuously connected to the internet, it has the potential to poll the GitHub repository to verify if the firmware running on the microcontroller is the latest available release version.

Details:

It is proposed that the SIDECART.TOS firmware should be enhanced to display a warning whenever a newer version of the firmware is available. To implement this, the RP2040 firmware could poll the GitHub repository periodically and compare its own version against the latest released version available in the repository.

If a mismatch is detected between the current running version and the latest available version, the firmware could respond to the SIDECART.TOS, indicating this discrepancy. This way, users can receive immediate notification and can act accordingly to update their firmware.

Visual Indicator:

A simple "!" close to the version displayed on the screen could serve as an effective visual indicator, alerting the users to the fact that their firmware is outdated and needs updating.

Benefits:

Implementing this enhancement will ensure that the users are running the most updated, secure, and stable version of the firmware, thus enhancing the overall user experience and the system’s reliability and security.

Acceptance Criteria:

• The Sidecart should poll the GitHub repository to compare the firmware versions.
• If a new version is available, a visual indicator, e.g., "!" should be displayed next to the firmware version on the screen.
• The users should have the ability to act on this notification and update their firmware to the latest version.

The listings now display faster due to enhancements how the information is displayed.