Posts by dddaaannn

  • Liste von Peeks und Pokes

    The KERNAL jump table is documented, and we're formalizing and documenting more of the KERNAL API as we go, including adding accessor routines for useful internal state. For example, we recently added a KERNAL routine to access properties of the most recent disk operation. Vectors, such as the IRQ vector, are accessible via the VECTOR accessor—which was actually in Commodore's original jump table but nobody used it. Memory usage by the KERNAL and BASIC is also documented. And of course all of the hardware registers are documented.


    Otherwise no. Old fashioned "magic peeks and pokes" rely on the fact that Commodore is dead and nobody is releasing new versions of the C64 KERNAL. The MEGA65 KERNAL is under active development, and programs must rely on official documented APIs for KERNAL integrations to work with future versions of the platform.


    If you have any specific things you need from the KERNAL that are not yet documented, please let me know, so we can consider adding accessors.

  • Der MEGA65-Laber-Stammtisch

    When we get close to doing a stable release, I try to pause feature development to keep the ROM from changing too much while we test it. Adding features just before a release increases the likelihood that something broken ends up in the release.


    Similarly, after a release I like to do a bunch of feature requests, prioritizing higher risk changes. Some people like to use the latest beta as their default ROM, and the more time they have to encounter bugs, the more likely the bugs will get found.

  • Der MEGA65-Laber-Stammtisch

    I recently tried to format a 128 GB card with the SD card utility, and the utility got stuck reformatting the first 32 GB repeatedly in a loop. I don't know if that was due to the capacity or another issue with the type of the SD card. Only SDHC up to 32 GB is documented as supported.

  • Intro Disk #4 (2025) / MegaZine #1

    I think anything that resembles a vintage type-in in 2025 is going to require some commitment to the idea that typing in a program listing has some value beyond just making the program available on your computer. That might mean roleplaying as someone in the 1980's that didn't have any other option, for a nostalgic feeling. That might mean focusing on the experience of reading the code for understanding, or typing it in for to develop a rapport with the keyboard and editing environment. In 2025, there will always be much faster ways to get to the binary, so you have to approach it intentionally. If that doesn't seem valuable, then don't do it. :)


    Author Hunter S. Thompson (Fear and Loathing in Las Vegas) made a practice of re-typing parts of his favorite novels by other authors before working on his own writing, to get the feel of the words running through his fingers.


    I also agree that it's entertaining to have something tangible to go with the computer, even if you don't actually type anything in. I own a boxed copy of Showdown on floppy disk despite its availability as a download.

  • Was machen mit Deinem MEGA65?

    Eratosthenes One of the difficulties of addressing broad concerns is that it's difficult to tell what you're seeing.


    You suggest that there ought to be a user-friendly collection of software for the MEGA65. The MEGA65 comes bundled with almost everything that's ever been uploaded to Filehost, with a user-friendly menu with descriptions, that boots automatically for all new owners. So far, this bundle has been updated with each release, and the upcoming v0.97 release will expand the Intro Disks further. Are you criticizing this experience, or have you not seen it? It's fine to criticize it as long as we're polite to the volunteer developers that work on it, but you haven't mentioned the Intro Disks at all in your posts.


    You describe the new user experience as unfriendly, but you don't say anything about the printed manual that comes bundled with the computer. The User Guide describes all the major activities, including how to use disk images and update cores and ROMs. It is well written and well typeset. Is the User Guide lacking, or have you not seen it?


    The M65Connect app makes many tasks easier, including file transfer, and the ROM patching process. Are you including that in your assessment?


    Most of the MEGA65 community activity is on Discord. Do you follow the Discord, or are you only accounting for what is posted to Forum64.de?


    None of these things are perfect, and I can imagine many ways they can be improved if we had many more developer resources. Personally, I don't need to compare the MEGA65 to other projects to imagine these things. I can also imagine many ways SpecNext and other projects can be improved.

  • S-BASIC 65 (MEGA65)

    Changes between ROM 920173 and 920183 changed how internal float rounding works. The difference is slight but noticeable in cases of compounding error.


    In general, PRINT rounds at fewer digits of precision than are stored to retain as much precision as possible during calculations, and present the result intuitively when an intuitive result is expected. This would result in counterintuitive edge cases of two numbers that PRINT the same but test as unequal. A reasonable system would prevent these edge cases in common, low-precision calculations. I'm still figuring out how our post-920183 ROM differs from Commodore BASIC in this regard, and whether there's a common (or perhaps IEEE standard) definition that we should be using instead.

  • S-BASIC 65 (MEGA65)

    Quote from MauriceMEGA65
    Quote from dddaaannn

    this specific example of 1-0.8 <> 0.2 is consistent across BASIC 2, 7, and 10.

    O wow, but this is very strange, not?

    I would agree that it's unpleasant. :) It's important for programmers to understand why floating point representations of reals are inaccurate. That said, in a language where all numbers are reals by default, I would prefer a system where low-precision floats behave precisely, such as for cases like this.


    One thing I don't yet understand about Commodore BASIC is why different rounding rules apply to displaying a value vs. storing a value. If 1-0.8 really <> 0.2, then I might prefer PRINT 1-0.8 to not display as 0.2, so I can at least see that floating point inaccuracy was introduced by the subtraction. An explicit rounding function might also help, so I can tell BASIC that I want it to treat 1-0.8 as 0.2.


    I'm sure there's formal theory around all of this that I should study, instead of just trying to guess what the improved system would look like. That article covers a lot of formalism. I don't know how much of that Commodore BASIC implements.

  • Der MEGA65-Laber-Stammtisch

    There is a cartridge protocol for MEGA65 cartridges, similar to the C128 protocol with a different ID string: https://mega65.atlassian.net/w…artridge+Work+in+Progress


    Auto-booting a MEGA65 cartridge is implemented in the core and ROM. We have tested it with an EasyFlash 1CR cartridge. So far nobody has distributed a MEGA65 cartridge. Feedback welcome!

  • S-BASIC 65 (MEGA65)

    For what it's worth, this specific example of 1-0.8 <> 0.2 is consistent across BASIC 2, 7, and 10. You're welcome to do what you like with S-BASIC, of course. I just had to double-check that we didn't introduce this as an inconsistency in BASIC 65. :)

  • Mal wieder eine IRQ-Frage

    Digest article on MEGA65 interrupts, including how to un-MAP the KERNAL to replace the CPU hardware interrupt addresses: https://dansanderson.com/mega65/racing-the-beam/


    Digest article on MEGA65 KERNAL integration, including how to robustly install KERNAL vectors and extend the KERNAL IRQ handler: https://dansanderson.com/mega65/kernal-of-truth/


    If you're just writing a machine code program that doesn't need the KERNAL, you can build your program as a PRG file with a BASIC bootstrap routine that invokes the machine code with SYS, in the traditional way. This automatically clears away most of the KERNAL and BASIC so you have most of bank 0 for your program.



    If you want the KERNAL IRQ handler to call your machine code routine to run concurrently with BASIC, your routine must live in $1600-$1eff. The routine can manipulate the memory map to access more code space, as long as it restores everything correctly before returning to the system (MAPL=(E)000 MAPH=(8)300).


    Memory mapping is an important topic on the MEGA65, especially when doing KERNAL integrations. See the Memory chapter of the Compendium.

  • Was machen mit Deinem MEGA65?

    Quote from Eratosthenes

    Nebenbei: Gibt es irgendwo ein Repository, das aktiv ist - (gitlab, oder github) - wo man ein paar Punkte loswerden kann? Bei allen Repos, die ich bei github gesehen habe, sind >> 90% der gemeldeten Bugs/Issues teilweise seit Monaten, oder einem Jahr unbeantwortet. (Bei so etwas habe ich keine Lust mitzuarbeiten... :( )

    Multiple core contributors read this forum, as well as the Discord. Feel free to reach out to me privately with feedback, if that's more comfortable. (I'm sorry that I only speak English. :) )


    The Github ticket queues are best for specific bug reports and actionable feature requests. Please keep in mind that this is an all-volunteer project. We keep tickets open if they are within the scope of the project, but we're not a company that can assign development resources to implement every request. We do read and consider everything, and we welcome contributors. (I personally try to keep the ROM and documentation queues tidy, and hope to clear some feature requests after v0.97 launches.)


    it sounds like you have some feedback about the on-boarding experience. We continue to put a lot of effort into the User's Guide and Intro Disks, and try to connect everyone with our online resources such as the Welcome Guide, Filehost, and Discord server. If you believe there are improvements that could be made to the bundled software, I'd be interested in your thoughts.

  • Was machen mit Deinem MEGA65?

    Quote from clarkkent

    Ich glaube, für den Anfang wärs schon mal was, wenn es ein paar Spieleports von anderen Systemen gäbe, die „etwas mehr“ bieten als die jeweiligen Originale. Vielleicht etwas verbesserte Grafik oder einfach ein paar Eigenheiten des Mega65 hinzuzufügen.


    Vielleicht sogar für den Anfang aufgemotzte C64 Ports.

    We have a bunch of C64 ports and remakes already, and I think they're pretty good. Showdown, Luma, Mega Sisters, Wave Hero 65, Mega Wizards, Old Mine Hoist, seven other games on the Four Fun disk. As I understand it, these all originated as C64 titles.


    I suppose you could put Maniac Mansion in this category. Admittedly this has less of a community feel because it's primarily a vintage commercial game. Personally I think it's exciting and inspiring to have this on the platform, in a similar way to having more polished exclusive titles.


    I'm quite thrilled to have the Ozmoo Z-machine interpreter for the MEGA65, which can play dozens of Infocom text adventrues and hundreds of modern ones. The MEGA65 version does a great job of taking advantage of MEGA65 features, including 80-column text and extra memory. I understand text adventures aren't everyone's thing, but this is a polished piece of software that runs many polished games.


    You will be quite pleased with First Shot when it comes out, a MEGA65 exclusive side scrolling shooter. It's made by a professional game developer, takes advantage of the whole machine, and will be a fully published title. It has taken years to produce, and is a sobering example of how expensive it is to produce polished titles.


    I agree that it would make the MEGA65 more appealing to have more polished game titles. We have to figure out how to turn that observation into actionable feedback for the platform. There's not much the core team can do to make polished video games appear. We can only continue to invest in bootstrapping the community, such that members of the community are motivated to spend months of their lives producing games. The developer of First Shot *loves* the experience of developing for the MEGA65, which I think is a strong signal for what we need to do to entice more game development: promotion and documentation of what we already have.

  • Was machen mit Deinem MEGA65?

    Some scattered reactions to things others have said:

    Re: what's new with SpecNext, I enjoyed this SpecNext year-in-review video by BAPSTARCADE, which was promoted in the most recent official SpecNext project update.


    Re: continued platform development: The MEGA65 is a stable managed platform. Improvements are made in a way that minimizes impact to existing programs. If the rate of change is discouraging you from writing programs, please take a closer look, and provide specific feedback, so we can improve. The rink is built, get off the bench. Just mind the Zamboni. :)


    Re: new owner communication, web findability, and emulator set-up: These are known weak points of the project. We're not allowed to know about or contact Trenz Electronic customers, so everyone has to find our web resources on their own, and our web findability is sub-par. The ROM patching prerequisite for the emulator is a limitation of the intellectual property landscape around Commodore stuff. These are tricky problems to solve with volunteer hobbyist resources and no money.


    Re: "quality games" (clark), I agree that more games that meet a certain perception of quality would enliven the ecosystem and the community, and make the MEGA65 more enjoyable for owners to use casually (i.e. for something other than hardcore programming). We should ask ourselves what bar of quality would meet the need. SpecNext-style games are well within the MEGA65's technical capabilities, and there's no shortage of tooling, documentation, or support to that end. If that's the bar, then we just need people willing to make those games.


    Re: "cozy spaces" (zeha), I agree that exploiting the MEGA65's maximum technical capabilities requires more skill than is within the range of a typical hobbyist, and this fact can be discouraging to hobbyists that would otherwise be willing to make smaller games. It's worth noting that SpecNext has comparable specs to the MEGA65, though the contours are very different and it may not feel that way for various reasons. I mostly know SpecNext games from YouTube videos, and I don't know how hard they're driving the hardware but it doesn't look that aggressive to me.


    It's interesting to contrast the "quality games" and "cozy spaces" points. IMO, the bar for "quality games" is much lower than "maximum technical capabilities," and what we're really looking for are complete ideas. The challenge is to establish the frame, then fill it. There are millions of quality games you can make with 50 KB of code and data, VIC-III character graphics in 320x200x4 or x5, one or two SIDs. Some of those games could be written in BASIC 65 at 40 MHz. There are a dozen or more games on the intro Disks alone that meet the bar for me (and I'm a tough audience for retro-style games).

  • Was machen mit Deinem MEGA65?

    Spectrum Next had a stronger launch and has been public longer than the MEGA65. They are further along in bootstrapping an ecosystem of developers and enthusiasts.


    SpecNext has had spectacular success in delivery. The first two Kickstarters shipped over 8,000 units: ~3,000 before 2020, and ~5000 before 2024, with some impact from the supply chain crisis. The MEGA65 has shipped over 2,000 units so far, and most of those were shipped very recently. We shipped 100 DevKits in 2020, shipped the first round of 400 units in 2022, then got completely stuck behind supply chain issues for two years. The majority went out in late 2024, and we're now caught up on pre-orders and doing direct sales. If you count "unit years"—the number of units times the amount of time they've been in the wild—SpecNext has had roughly 6.5x the exposure of the MEGA65. That seems like enough to explain the relative levels of visible activity.


    Game publishing activity is especially likely to correlate with unit sales. Games are costly to make. As fun as it is to explore a specific platform's hardware capabilities through making a game, that's not enough to justify the investment in game assets, polish, and up-front monetary costs in publishing a game. Most game devs want people to play their games to justify the investment, and unit sales play a dominant role in bootstrapping an ecosystem that attracts game devs.


    Full credit goes to the SpecNext team and community for this accomplishment! They did an amazing job running the Kickstarter campaigns, developing and maintaining a strong vision, keeping costs down, maintaining post-campaign customer communication, and producing a product that appeals to Spectrum fans and retro enthusiasts at multiple skill levels. It's a great computer, and an attractive gamedev platform.


    I don't believe there are major factors holding the MEGA65 back from developing its ecosystem to a similar level of maturity as our sibling projects. As long as we continue to promote the MEGA65 and can keep the hardware supply chain flowing, we'll get there. MEGA65 is just earlier in the process.

  • CURSOR so korrekt?

    The intended behavior of the screen terminal is to scroll the screen up when PRINTing a carriage return in the bottommost row (scrolling), or push some lines down when PRINTing a character in the rightmost column (line pushing). These mechanisms allow for line entry at the bottom of the screen, and typing long logical lines in the middle of the screen. By design, PRINTing is similar to typing, and behaves by the same rules. Without the semicolon, PRINT prints a carriage return, as you would press Return at the end of a typed line.


    If you want to paint characters onto the screen using PRINT, you usually want to disable scrolling and line pushing so PRINT can reach the borders without changing the rest of the display. To disable scrolling, print CHR$(27)+"M". (To re-enable: CHR$(27)+"L") To disable line pushing, print CHR$(27)+"R". (To re-enable: CHR$(27)+"N"). CHR$(27) is Escape, so you can test these behaviors by pressing Escape then the corresponding key. The ability to disable line pushing was introduced in ROM beta 920386, and will be in the next stable release v0.97.


    It is possible that there is either a bug or unintuitive behavior when using CURSOR with PRINT. If you can give me precise steps to reproduce the behavior you're seeing, that'd help me track it down. I haven't been able to reproduce an issue with a few attempts.

  • 2025 Compo: "Screenful of BASIC"

    The submission procedure appears to be as follows:


    1. Create an itch.io project for your submission in "draft" status.

    2. Re-visit your project edit page, then update its status to "public."

    3. Visit the jam page, click the button to join the jam, then select the project from the dropdown menu.


    It feels a bit silly to create a full project for a jam entry, but that's apparently how it works. You get a full detail page for your entry, with an optional comment section. You can even charge money for it. :)