Posts by dddaaannn

    My guess is you previously saw mouse activity on port 1 causing accidental key presses, which no longer occur with the new keyboard scanner. The previous keyboard scanner used CIA1, which has well known conflicts with activity on joystick port 1. GETKEY is not intended to unpause on mouse button. A reliable "wait for key or mouse" routine would be something like:


    Code
    1. 20 get a$:mouse xp,yp,bt:if a$="" and bt=0 then 20

    Since the keyword RUNFILE is neither documented nor can it be seen in any other way, I don't understand why it was discussed at all. The keyword could also be called XYZ, for example, and the "up arrow" shortcut would work in exactly the same way. But R+Shift U would work as RUN again. :)

    I just changed it to XXXRUNFILE for the next ROM beta. This will restore the rU abbreviation.


    It is technically possible for any new keyword to break existing programs. A variable in BASIC can be a long string of characters, even though only the first two letters are recognized, and it is a syntax error for any substring of a long variable name to be a keyword. (Yes, I would advise against long variable names for this reason, but it is allowed.) Adding a keyword has the remote possibility that it will break an existing program, or be an obnoxious hurdle for a future one. The keyword "XXXRUNFILE" is long and obnoxious enough to be unlikely to cause an issue, but I wanted to consider the options carefully. For example, some were suggesting we use a nice name for it like EXEC, but that just increases the likelihood that it'll conflict with a program. I have a tool that searches all BASIC programs on Filehost so we can make these decisions more practically, but it's still important to stop and think about it.


    I don't want to make a blanket promise that we will protect all abbreviations. When we need a new keyword, I don't want protecting an abbreviation to be a reason we avoid an intuitive and clear name. The most defensive way to avoid breaking existing programs is for the new keyword to use an existing keyword as a substring—but if the new keyword uses an existing keyword as a prefix, it obliterates the existing keyword's abbreviation. I'm OK with protecting lO and rU as special cases, but I don't want to protect the full list.

    @rosettif With apologies, can you try downloading the latest Xemu stable? It has just been updated. I was able to reproduce the blank screen, and it is fixed in the latest stable Xemu. Sorry for the inconvenience. (I had thought Xemu stable was updated in December, I'm not sure how I got confused.)


    Snoopy I'll do this soon. This has been discussed at length multiple times in the Discord. It seems to only exist as a keyword to support the up-arrow shortcut without special-casing the shortcut mechanism. (shortcut != abbreviation, they are separate ideas)

    After updating the Kernal, I'm just getting an empty, black screen with it (when starting the emulator).

    Can you describe how you acquired the ROM? Did you construct it with a patch, and if so, which base ROM did you use, which patch file, and which patching tool?


    The v0.96 ROM (920395) is expected to work with the current Xemu stable and Xemu "next" releases.

    Apologies for the confusion. We're chasing down several unrelated Amiga mouse issues. We have fixes for some but not all of the issues staged for a later core release (not v0.96 but the next one), and our ability to reproduce some issues has been inconsistent, possibly due to the quality of the vintage hardware we've been able to access.


    I've gotten ahold of an Escom mouse and a Commodore Amiga mouse, and I'm getting different broken symptoms. The Amiga mouse doesn't register either button on either port, but in my case this is *not* fixed by downgrading the ROM. I'm not ready to call this definitive, as I don't have an actual Amiga to test the mouse, but I was able to verify that the buttons work electronically, making a circuit with 5 ohms of resistance across the appropriate pins. The Escom mouse worked on a friend's Amiga but didn't work at all on the MEGA.


    I can at least partly explain the theory of the ROM making a difference: the legacy keyboard scanner had a side effect of resetting the CIA directional pins with every IRQ. With the new keyboard scanner in 920387, it no longer does this, revealing some bugs in how the CIA port is handled elsewhere. I'll try reintroducing some CIA resets in the IRQ and see if I can improve things, but because I can't yet reproduce an Amiga mouse working better with an older ROM than a newer one, it'll be tricky for me to confirm. The work continues.

    I have a guess but it's a long shot. Can you try 920393, the very latest ROM version?


    920393 differs from 920392 in just one way, but it might be relevant. I don't know why this behavior would be specific to DevKits. (So far I haven't had any DevKit owner volunteers to reproduce this, and I don't have a DevKit.)

    If it works with v0.95, we should continue to suspect the core. I agree that it might be worth suspecting a DevKit-specific issue. We should try to find someone else with a DevKit to repro. Technically the R3 and R3A boards shouldn't be different enough to matter, but it's something I can't test myself.


    I use a mouSTer with a typical Logitech wireless mouse in Amiga mode. I see the known issue with the right mouse button flickering in the v0.96 release candidate, but it otherwise works. I also have a vintage 1351 that works flawlessly.


    Sorry for the inconvenience, and thanks for the reports!

    I cannot reproduce mouse buttons not working for an Amiga mouse in port 1 with the latest development core, and I don't know why that might be the case on your machine. (I don't have a DevKit to test with, but I can't think of a reason why that would be a factor.)


    There is a case on the old v0.95 core that would produce this symptom. I'll describe it just in case it's useful, but it contradicts a couple of facts in your report so it might not apply. The v0.95 core was mis-wired such that attempts to read mouse and paddle movements from port 2 actually reported mouse and paddle movements from port 1. Attempts to read mouse buttons from port 2 correctly reported buttons from port 2. So with v0.95, if the mouse (either kind) was connected to port 2 and the program was trying to read from port 1, it would see port 2 mouse movements but not port 2 buttons.


    One additional point of interest: The BASIC "MOUSE ON" command takes a port parameter. This parameter is optional, but I think it's easy to miss the note in the documentation that the default port is actually port 2. (For whatever reason this is how it was on the C65.) With the CIA bug in v0.95, a BASIC program using "MOUSE ON" without specifying the port would read mouse movements from port 1 but mouse buttons from port 2. With the bug fix in v0.96, "MOUSE ON" would read both movements and buttons from port 2.


    Maybe none of that applies to what you're seeing but I thought I'd mention it just in case.

    (Apologies for English. :) )


    November 2020: 100 DevKits delivered (board R3)

    May 2022: Batch #1: 400 MEGA65s delivered (board R3A)

    January 2023: Batch #2: 400 MEGA65s delivered (board R3A)

    June 2024: All remaining pre-orders placed up to January 2024 to be delivered, estimated counts not made public (board R6)


    Hardware improvements made between R3A and R6:
    https://c65gs.blogspot.com/2023/06/mega65r4-bring-up.html
    https://c65gs.blogspot.com/202…-changes-to-r4-board.html

    https://c65gs.blogspot.com/2023/12/r5-board-bring-up.html


    The only difference between R5 and R6 is a non-electrical change relocating the DIP switches.


    There are no significant differences to the MEGA65 platform (core, ROM, system software) with the mainboard revision. No new RAM is exposed to MEGA65 programs. The bidirectional cartridge and joystick pins enables some possibilities with peripherals, but this is more for completeness than broadening the horizons of the platform. The new RAM does expand the possibilities of future core porting projects, though time will tell if anyone actually uses it. For all practical purposes, any MEGA65 program that runs on an R6 board will run on an R3/R3A board.


    Trenz Electronic's announcement is that preorders will ship on June 1st, and the MEGA65 will be in stock for others to purchase on June 12th. I would assume that the MEGA65 will only be in stock if they don't sell out the remaining stock through more pre-orders placed between now and then. If you don't have one and want one, I recommend preordering. ;)

    Thanks! Can you confirm which version of Xemu you're using (About dialog)?


    I'm not able to reproduce in Xemu 20231206012335-next and ROM 920390, playing a few rounds with the mouse. This looks like a character attribute issue related to the animation of battle impact on stats, but I can't tell if that animation is sprite based or character based or both.

    I'll make sure that the ROM beta file descriptions in Filehost refer testers to the CHANGELOG for testing instructions. Anyone testing beta releases should keep up with the instructions in the CHANGELOG , and should probably be following along in the Discord as well. Testers are most welcome, but they need to follow testing instructions.


    The latest stable release is v0.95. This release includes ROM 920377 and the core from that release (October 2022). ROM 920377 also works with the "stable" release of Xemu. ROM 920391 is a "beta" release and depends on the latest development core, or the "next" release of Xemu. Release v0.96 is coming very soon (probably in a few weeks!), and will promote the most recent beta ROM and core to "stable" status.


    Moscription seems to be working fine for me on the latest beta, but I'm not sure how to reproduce the problem described above. Can someone write up reproduction steps?