This release lays a new foundation for WUDSN IDE in many respects. The inner structure of the IDE has been reworked so that it can be extended to other languages beyond 6502 assembly languages. The main reason is that I want to make it the primary development environment for Mad Pascal. I consider Mad Pascal the most crucial step forward in development for my beloved Atari 8-bit platform. Its perfect integration with Mad Assembler allows one to use the best high-level and low-level languages in one project. The level of reuse possible via Mad Pascal Units is unmatched in the 8-bit world.

Java and Eclipse

  • The minimum requirements are the same as for WUDSN 1.7.2, i.e., Java 11 and Eclipse 4.19 or newer.


  • Perform a new fresh installation using the new WUDSN IDE installer scripts.
    They are available for 64-bit Windows, 64-bit macOS, and 64-bit Linux. The installer will automatically download and install all required components like Java, Eclipse, compilers, tools, and example projects. All information is available on the updated Installation page. The installer replaces the previous Windows-specific "zero-installation" downloads. Unlike the "zero-installation" downloads, the new installer scripts allow installing WUDSN IDE into freely chosen folders on your hard drive. This way, you can also have multiple installations in parallel.
  • This a major version change, so a new empty workspace folder for the new version.
    The installer creates such a folder for you. If you update or install manually, use a new empty workspace folder or delete the ".metadata" folder in the existing workspace folder. Otherwise, you will see errors caused by incompatible settings and entries from the "WUDSN IDE 1.x.x" versions.


  • Stable and daily versions are now available via separate update site URLs.
    The recommended version to use is the stable version. The daily version is available, so bug fixes and new features can be tested by reporters before pushing them to the public.
  • The new default updates site URL is   
    The old update site is no longer available.
    If you need to install old plugin versions, use the version-specific update site on the Releases page.

Source Code

Bug Reports and Feature Requests

  • You can now report bugs and file feature requests directly via GitHub.
    Just click on the Issues section of the respective project. This also lets you vote for fixes and features, comment on them, and receive notifications when something is created. Feature Requests should be tagged as "enhancement".

Source Compatibility

  • All source code from previous versions of WUDSN IDE will continue to work in the new version.
  • Use the new annotation prefix "@com.wudsn.ide.lng" instead of "@com.wudsn.ide.asm".
    The old prefix is deprecated because the IDE now supports multiple languages. If you used the old prefix, it results in warnings during compiling for now.

Behind the Scenes

In the past 14 years, WUDSN IDE has grown immensely, and creating a new WUDSN IDE release became increasingly complex: more assemblers, more support target platforms, and more requests for operating systems like macOS or Linux. Because building a release consisted primarily of manual steps, and testing was tedious to impossible (for example, I didn't own a macOS machine). So something like a preview for testing was unthinkable without investing a whole day of work. Ultimately, I didn't want to code something in the IDE anymore because 5 minutes of coding resulted in hours of painful post-processing.

But since I want the IDE to continue and evolve, I've invested several months to break the vicious circle and prepare my development cycle for prime time. This included:

  • Splitting up the sources
  • Getting familiar with git, after all
  • Moving all sources to GitHub
  • Establishing issue management Github
  • Buying an Intel-based MacBook Pro
  • Buying an M1-based Mac Mini
  • Setting up Linux VMs for development on macOS
  • Setting up Linux VMs for testing on Windows
  • Creating and testing installation scripts for Windows
  • Transcribing the installation scripts to Unix shell scripts
  • Testing the installation scripts on macOS
  • Generalizing the installation scripts for Linux
  • Creating test scripts for automated tests on the development machines (aka. "Does it work here?")
  • Creating test scripts for automated clean-installation tests on the test machines (aka "Will it work there?")
  • Reworking all source code to use the language as an additional dimension

The process took several months, a now it finally pays off. I guess that's where all progress comes from: Underestimating the actual time and effort something will take :-). This is what my new workplace looks like, and below that picture, you can find a short video (German language) where I demonstrate the new workflow when using GitHub.