Did openMSX crash or the debugger? Which versions were these?
The debugger, openMSX keeps working without any issue.
openMSX 0.14.0
openMSX Debugger 0.10.0-unknown
Oh, sounds like ancient versions... Can someone reproduce this?
Can you tell me exactly what you were doing, MsxKun? Which machine and extensions were you running? Which exact ROM file did you insert and in which slot?
Trying to put watchpoints into the Track & Field 2 ROM. We have RuMSX event tomorrow, and it's for the contest.
When you open the debugger, when you usually scroll down the code... it scrolls only a bit and then got stuck...
If you start at 0x0000, if you scroll down, it gest only to 0x0060, no more down, but you can go up again.
Machine: Philips 8250, Panasonic FS-A1WSX, Panasonic FS-A1GT, HB20P... no matter, same result.
Extensions: none, I have the debugdevice as default, only that.
All you need is to take the Track2.rom (If you get the ROM at Planetemu, this one does the same as the one I had), open debugger, and scroll down the code.
Works fine with the Raspberry OS version, newer openMSX and newer debugger. Not with mine on Ubuntu 18. Track & Field 1 (Track.rom or Track1.rom) does the same. This is the first time I see this behaviour.
And... after I changed some stuff I needed on the ROM using the MSXVR with Raspberry OS, this modified ROM doesn't have this problem when you debug it with the Ubuntu openMSX debugger. Very strange.
ROM in Slot1. Also in Slot2, same. Tho I noticed that if you put a ROM in Slot 2 in Catapult, if you go to the debugger and if ROM is for example at $4000 (the most usual), the Debugger shows in Slot Memory Layout that Page 1 ($4000 ) is set to slot 1 :/ (I tried with one of my ROMs now, set on slot 2, shows a 1 on slot).
Well, I guess it has been fixed then later... perhaps some specific byte pattern made the debugger trip?
Anyways, it also works fine here with the latest openMSX and debugger, so I guess there's nothing I can do to fix it... Agreed?
Well, I guess it has been fixed then later... perhaps some specific byte pattern made the debugger trip?
Anyways, it also works fine here with the latest openMSX and debugger, so I guess there's nothing I can do to fix it... Agreed?
Yeh, I wouldn't bother. Happened once in a hundred cases, and newer versions works fine, so can't see any problem, tho it's pretty strange.
When Ubuntu 22.04 is out I should think about to update to 20.04 and maybe then to 22.04, but so far, i'm pretty happy with 18.04, so no hurries. In case of emergency, I have a 20.04 on laptop and also on another partition on this computer, plus some virtualized one, and it can pass like another decade until I find the need to hack something (btw, people was playing with it at the MSXRU ) and the very rare issue happens again, so zero problem.
Just out of curiosity: why don't you just upgrade to the latest version right away?
Just out of curiosity: why don't you just upgrade to the latest version right away?
If you mean Ubuntu, cause if it works, don't touch it.
If you mean openMSX, lazyness.
In this case it did not work and a newer Ubuntu would come with a newer openMSX. And this would also happen for other software packages.
Ok, since a day or two the debugger went nuts again. Breakpoints that are set by clicking in left border area no longer fire. Only breakpoints that are set using CTRL+B will fire (even if these breakpoints are already removed by clicking in left border). Also the step out fails to work..... its driving me nuts... what is going on here?