letzter Beitrag von dddaaannn am
Ich würde mir gern die Neuerungen im Beta ROM 920385 durchlesen.
Leider bekomme ich nach Anmeldung im github.com unter der angegebenen Adresse https://github.com/MEGA65/mega…/blob/master/CHANGELOG.md keine Seite geöffnet.
Gibt es dazu noch eine andere Adresse?
Guter Hinweis, habe es im public repo gespiegelt: https://github.com/MEGA65/mega…ic/blob/main/CHANGELOG.md
SUPER. Danke.
Die letzten beiden Kernal ROMs 380387 und 380388 haben laufen mit meinem Devkit nicht. Sie lassen sich zwar starten aber die Eingabe ist nicht o.k. So lässt sich beispielsweise kein Ausführungszeichen eingeben. Nach Rückspielen auf ROM 380386 ist alles wieder normal. Im Emulator ist es genau so.
Kann das jemand verifizieren?
Ja, ist auch hier so. 
Man braucht ab ROM 920387 zwingend auch ein Update vom Core, sonst "spinnt" die Tastatur. Der Keyboard scanner wurde ab 387 verändert.
( https://github.com/MEGA65/mega…ic/blob/main/CHANGELOG.md )
Ich finde das eher unglücklich, aber mich fragt ja keiner. 
Ist nämlich blöd, dass man beim Emulator keine "Cores updaten" kann. Das geht halt dann nicht mehr ab 920387. 
Also alles wieder auf Anfang.
Ja, leider. Vielleicht ist dem Team das Setup mittlerweile zu stabil geworden? 
Beim Emulator ist vom Entwickler zumindest schon dokumentiert, dass er Anpassungen für die neuen ROMs vornehmen will:
https://github.com/lgblgblgb/xemu/issues/388
Meine Meinung dazu: Anstatt den Fokus auf "bald alles stabil" hinzubekommen, macht man stattdessen so eine "unnötige" Baustelle auf. Cores müssen zwingend geupdatet und der Emulator extra angepasst werden. Und ob dann alles Bisherige weiterhin gut läuft, muss sich erst zeigen ... 
(Apologies for English:) The latest stable release of the platform is v0.95. The v0.95 release has a core and ROM that work well together, and a corresponding version of Xemu that emulates that version of the core and runs well with that version of the ROM. We are converging on a v0.96 stable release, and the goal is to once again have the core, ROM, and Xemu emulator all working together.
It is inevitable that development versions will have temporary restrictions with regards to dependencies between the platform components. Almost every change to the core needs a corresponding change in Xemu, and they are very different code bases developed by different people. (There is no way for the core and Xemu to share code.) it is rare for a change in the ROM to depend on a change in the core, but they're part of the same platform, so this will happen occasionally. The latest ROM beta release that works with the latest version of Xemu is 920386, and LGB is actively working on updating Xemu with the changes required to support later beta versions and eventually the upcoming release v0.96.
I'm grateful that people want to help test the newest software! Just be aware that testers always need to work within temporary limitations. We'll do our best to document those limitations to support testing.
PS I wasn't aware of issues with Amiga mice in the latest core. I'm unable to reproduce this with the latest development core and ROM. Please submit bug reports to Github when you notice issues with development versions. Reporting bugs helps everyone!
It is rare for a change in the ROM to depend on a change in the core, but they're part of the same platform, so this will happen occasionally.
I know that this has already been discussed several times, so I'll just say briefly: From a developer's point of view, I don't think it's good that even such "serious" changes are still being made to the MEGA65 at this point. But well, that's just the way it is.
But I would definitely welcome it if you can continue to use the previous ROMs with new cores. For me, backwards compatibility with the old ROMs is a definite "must have" if you don't want to expect the developer to make every adaptation to new cores.
Thanks for the tips dddaaannn.
I once again reloaded the core from 20230922 and did the configuration. Now the AMIGA mouse actually works again.
The typing feeling is now completely different. If you write fast you have a lot of double characters. But maybe this is just my observation.
Switching off the Run/Stop button via memory address 808 logically does not work anymore. With Poke 808,112 the key Run/Stop but also the mouse button is locked. (Poke 808,25 switches to normal mode).
Thanks for the notes! Please upgrade to core 20230924 (build 61), which contains a fix for the repeated characters. I'm maintaining testing instructions for this feature here: https://mega65.atlassian.net/w…r+v0.96+feature+candidate
Re: location 808, remember that most MEGA65 KERNAL APIs are not yet documented, and not guaranteed to work like they did on the C64. Many Commodore 64 tricks, especially magic POKEs, depend on internal details of the C64 implementation that are not true for the C65, would never have been considered part of the API design in the first place, and only survive as lore because the C64 ROM stopped evolving after a few iterations and people started forming (and documenting!) dependencies on internals.
Location 808 is the low byte in the "istop" vector, an API that Commodore intended to allow replacing the routine that handles checking for Run/Stop. Its value is an address to a subroutine, and its default value is the location of an internal KERNAL routine. With this API, the official way to disable Run/Stop is to write a short subroutine that does nothing (an RTS instruction), then change the vector to point to that subroutine. At some point in C64 history, someone decided that it was sufficient to pick an existing RTS instruction already in the KERNAL and use that as the istop vector value to "disable Run/Stop." They wrote it down as a magic POKE and started passing it around as if it were the right way to do it. But magic values like these are not part of the API definition, and are in no way guaranteed to be preserved across versions. There is no practical way to promise that an arbitrary RTS instruction in an internal routine will still be in the same memory location between two versions of the ROM.
Commodore never finished the C65 KERNAL. Some of the intended APIs are poorly designed, some are implemented but don't work as designed, and others may have to change as other bugs are fixed. We're working to formalize, test, and document the KERNAL API surface as we figure out how to close these gaps. While many KERNAL APIs resemble those of the C64, until they are added to the MEGA65 manual, they need to be considered unsupported. Otherwise there is no hope of fixing Commodore's bugs and design flaws.
(This is not true of the C64 ROM used in GO64 mode. Any bugs in the C64 ROM need to be preserved, precisely because C64 software formed dependencies on internal details. That's why the recently discovered issue with the tape buffer variable space is considered a regression that needs to be fixed.)
From a developer's point of view, I don't think it's good that even such "serious" changes are still being made to the MEGA65 at this point. But well, that's just the way it is.
But I would definitely welcome it if you can continue to use the previous ROMs with new cores. For me, backwards compatibility with the old ROMs is a definite "must have" if you don't want to expect the developer to make every adaptation to new cores.
Changing the ROM in a way that depends on a change in the core is not the same as changing the core in a way that breaks older ROMs. The latest core still supports all older software, including older ROMs. And the latest ROM still supports older software, as well. (If it doesn't, file a bug!)
More generally, the core and ROM make up the platform that runs MEGA65 software. This platform has documented and supported APIs (hardware registers, the KERNAL jump table, etc.), and it is a goal of the project to support those APIs across future versions. Any software that adheres to the API contract should continue to function as the platform evolves. The process will be messy and incomplete, and for now there are large areas that are considered unsupported while we formalize API surfaces, especially in the KERNAL. But that's the goal.
We all want a stable, well-documented development surface to build on. This is the ultimate goal of everything I have been working toward all year, including bug fixes, automated testing, and documentation. I know that some have expressed a pessimistic view of our ability to formalize the API surface of the hardware and the KERNAL, and believe the only path toward stability is to halt development and let the API surface be discovered organically as many have done with the C64. That's a fair position, considering this is all run by volunteers! If we can't document the API contract properly, we shouldn't change the internals! I think I can speak for the MEGA65 team when I say, we believe that continuing to improve the platform is what's best for the MEGA65 community in the long run. The alternative would require freezing substantial flaws into the platform, and those flaws would be more discouraging to growing a thriving community of recreational programmers than some short-term discomfort as we try to fix the flaws. But if we are changing the internals, we need to document the API contract, so developers know what they can rely on.
We are working toward a v1.0 release of the platform with major known issues repaired, and hardware and KERNAL interfaces formalized and documented, ideally protected through automated testing. That doesn't mean there won't be further development after v1.0, but we do expect to have a satisfyingly substantial, stable, well-documented platform with that release. Personally, I suspect platform evolution will slow down at that point, though as a MEGA65 user I would welcome continued work on fixing bugs. I'm sure we won't find all of them.
— Dan
