Today I came around to update my core to the latest version (and the rom) and thought I give this a try again ... still no joy, I still get that destroyed graphic with every ROM up to 920395 ... I also tried to write this back to a real floppy and load it, still the same garbled screen (and the right LED on the MEGA65 is blinking red ![]()
A little graphic adventure game for the MEGA65
-
- Sonstiges!
-
TOS22 -
21. Januar 2024 um 00:40 -
Erledigt
Es gibt 32 Antworten in diesem Thema, welches 6.529 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Today I came around to update my core to the latest version (and the rom) and thought I give this a try again ... still no joy, I still get that destroyed graphic with every ROM up to 920395 ... I also tried to write this back to a real floppy and load it, still the same garbled screen (and the right LED on the MEGA65 is blinking red

Hi! I'm sorry that it - for whatever reason - still doesn't work. This is really weird. In the last weeks I focused on TCC and I still need the next weeks to do some important preparations on the compiler, but when TCC 2.0 is finished I'll start the next adventure game project (this will be far improved over this demo project) and there I'll focus on solving this graphics problem. I'm sure that we'll then find out what's wrong!
Matthias
-
This is a weird one and I can say that this took me to a solution (for Xemu) -> Bitte melde dich an, um diesen Link zu sehen.
ZitatIt fails this way, if I use:
- LOAD "TEMPUS.PRG", it will fail this way
- ^ "TEMPUS.PRG"
...but if I load it either of these ways, it loads normally:
- SHIFT + RUN-STOP (to load it as the first thing off the disk)
- RUN "TEMPUS.PRG"
... still have to test this on my real Mega65 but I really want to know why the way you load a game lead to corrupted graphics

-
still have to test this on my real Mega65 but I really want to know why the way you load a game lead to corrupted graphics
So strange
... but now we have something to start with. Tempus executes at $5000 while the bitmap data is at $2000 (which was necessary because I was technically unable to combine HiRes bitmaps with 16-color sprites with the bitmap at another location as $2000), perhaps this collides somehow with the way the program itself is loaded, just a first guess, but still it is strange anyhow ... -
So strange
... but now we have something to start with. Tempus executes at $5000 while the bitmap data is at $2000 (which was necessary because I was technically unable to combine HiRes bitmaps with 16-color sprites with the bitmap at another location as $2000), perhaps this collides somehow with the way the program itself is loaded, just a first guess, but still it is strange anyhow ...Just tested again on my real Mega65 and it is as Gurce described in the other thread ...
run"*" works
run"tempus" works
shift + run/stop works
every other loading method leads to corrupted graphics ...
-
Da gibt's eh nur zwei Möglichkeiten:
1) Timing
2) Du verlässt dich irgendwo auf Default-Werte in den (VIC IV-)Registern. Ich habe aus leidvoller Erfahrung feststellen müssen, dass man lieber alles explizit setzt. Beim C64 kommt man in der Regel damit durch.
Englisherized:
IMHO there's only two options:
1) Timing
2) Relying on default values in (VIC IV) registers. I already learned that you better set all the values explicitely you want to be set. Relying on defaults can work on th C64, on the Mega65 not so much.
-
Dddaaannn from discord mentioned that POKE 1,135 was another way to get the load working. It seems to relate to a change in rom 920384 relating to io register $01 and c64 memory mapping.
I don't know the backstory on how it came about, think it might relate to some overlap between the behaviour of the c64 mapping scheme versus the c65 mapping scheme?
He mentioned that this poke was added to the intro disks to get malfunctioning titles working. Seems like xanadu/bas was impacted in this same way too, but deathy added the fix in there and re-uploaded.
After my holiday, I can try add in the same poke fix into a re-released dr tempus, along with my more polished attempts to add mouse support
-
2) Du verlässt dich irgendwo auf Default-Werte in den (VIC IV-)Registern. Ich habe aus leidvoller Erfahrung feststellen müssen, dass man lieber alles explizit setzt.
You're right, absolutely. I tried to address this and set all necessary VIC registers explicitely, but of course I can always forget something
But in this case, I don't think VIC settings are the problem, because I did some tests together with Skulleater and we could narrow the problem definitively down to the loading routine, which for some reasons failed on Skulleaters system.Just tested again on my real Mega65 and it is as Gurce described in the other thread ...
Dddaaannn from discord mentioned that POKE 1,135 was another way to get the load working. It seems to relate to a change in rom 920384 relating to io register $01 and c64 memory mapping.
Ok, thanks for the informations, I am on vacation now, but when I am back home, I will test the POKE 1,135 solution with another testing routine for Skulleater. Let's see ...

-
We changed the boot state of $0001 because it was just wrong in the C65 ROM in several ways. Hopefully we have correctly calculated the correct future-proof value (e.g. useful default memory map, datasette control registers for the upcoming expansion board), and we don't expect to change it again. In general, we want a stable boot state (ideally documented) including hardware registers and KERNAL, so at least "power on, DLOAD, RUN" is empirically dependable. I'm hoping we can formally declare this to be the case by platform version 1.0. (There's no accounting for a user running other programs before yours, but I think most users can understand the consequences of that for Commodore 8-bits.)
-
Ok, back from holidays and trying to get my mega65 dev mojo back, but very sluggish

At the very least, I tried adding the poke and recompiled. And yes, this has resolved the issue of loading with dload or ^ arrow.
Bitte melde dich an, um diesen Anhang zu sehen.
Will try look into the mouse behaviour in the coming days

So far, while playing with my prior attempt, I noticed that the hotspot, didn't quite match up to the centre of the sprite.
I noticed in latest rom, I can specify a hotspot with: MOUSE ON, 2, 2, 12, 10 (for hotspot at (12,10)).
This seems to help, but one gotchya is that I can walk to the left screen (to the kitchen) via the mouse, but I can't walk back to the living room by clicking on the far-right, as the rom's mouse-routine seems to limit the travel to the far-right by a few pixels (so I can't click the extreme right).
Will try take a look at that in the coming days...
-
Aah ok, my mouse pointer hotspot issues were my own fault it seems.
I had assumed the mouse sprite was a standard 24x21 c64 sprite with a hotspot in the middle, at about (12,10)
...but it's actually an fcm sprite (16x21), with a hotspot located at about (8, 12)
So I'm settling for this now inside the "AUTOBOOT.C65" file:
MOUSE ON, 1, 2, 7, 11
I used 7 (instead of 8), and 11 (instead of 12) as I think the maths inside the mouse-region checking logic of the rom is off by one pixel

I'm also switching to mouse in port 1, since that seems the most popular port choice for mouse. Not sure if I'll have the appetite to support joystick alongside mouse, so maybe my release will just be mouse version alone (my mega65 dev mojo is still very sluggish right now :D)
PS. I also noticed that the hotspot/mouse positioning seemed to in the wrong place if I used the 920395 rom. (The mouse's left offset was pushed too right of the left-edge). After upgrading to 920406, this problem went away, so I recommend running this version with a newer rom.
-
ROM 920396 fixed a significant bug in the way MOUSE handled its hotspot arguments, and also our docs on the argument order were wrong. That could result in a program written per the old docs to pick up new behavior after this change. Apologies for that! The decision was made to conform to Fred Bowen's intended API and just fix both the implementation and the docs.
-
No probs dddaaannn, that's fine
Oh, it reminds me, I should make a note in the filehost entry to mention which minimum version of rom is needed 
-
Beitrag von Stanley Knowles (
9. Dezember 2024 um 10:24 )Dieser Beitrag wurde von controlport2 aus folgendem Grund gelöscht: Spammer (9. Dezember 2024 um 13:02 ). -