Getting old, getting stupid. Can't even make "Hello World" to run correctly anymore

Page 2/2
1 |

By Thom

Hero (593)

Thom's picture

09-09-2019, 18:09

Thanks guys, I appreciate your patience and the extensive explanations. It helped me a lot. Although it wasn't really important because usually ROM-programmes don't exit, but (knowing myself) it would have bothered me forever. I did not expect to learn so many things from a 'hello world', which is nice.

I'm now able to move on. The first goal was to set up a development environment, which I will tell about later.

By saccopharynx

Master (135)

saccopharynx's picture

10-09-2019, 00:56

Sorry for stepping in with a comment that relates to the debugger rather than the actual topic concerning this post, but the code (displayed in the GUI controls) is not actually updated when a breakpoint is hit. In addition to that, it is also necessary to scroll down or up several lines and come back to the breakpoint address to see an update.

Currently, I am not on the computer where I have the debugger installed to check which version I am using, but in any case, this issue has been around for quite a lot time.

I wonder if this is actually a bug or if I am missing some settings that control code refreshment.

Cheers!

By Grauw

Ascended (8515)

Grauw's picture

10-09-2019, 09:12

@saccopharynx See https://www.msx.org/forum/msx-talk/openmsx/openmsx-debuggers...

p.s. The openMSX debugger is open source so anyone can step in to fix it, which is probably the fastest way to see this fixed since the debugger is only getting sporadic updates.

It seems to me it would only have to clear the disassembly cache when connecting, but idk the code.

By Manuel

Ascended (15829)

Manuel's picture

10-09-2019, 22:44

NYYRIKKI wrote:
Thom wrote:

The slotmap command in the openMSX console doesn't give me different results when I add the -romtype Page1 option.

Indeed... I think this is for Manuel to explain: If I use debugger to view hex dump of "slotted memory" I can see for sure that the "-romtype Page1" is effective, how ever in "slotmap" I also get false result... When I look in to my "scripts"-folder, in my case this comes down to problem that ie. "machine_info slot 1 0 0" seems to return false information... at least from user perspective (In my head I could imagine it might be related to problem that you can't insert more than one physical cartridge to one physical slot at a time, so the cartridge reserves all of the slot address space, but it still seems a bit weird and misleading.)

You guessed kind of right. When inserting a ROM game in a slot, openMSX always assumes it's occupying the full 64kB of the slot. (The mem tag in the config XML files, it would say base=0x0000 size=0x10000.) How the ROM is mapped into Z80 memory space is from openMSX point of view not related to that. A smaller mem tag would work for this case, but it would depend on the mapping method (aka 'the mapper') whether that would be correct or not. The mem tag decides which part of memory the emulated device can 'see', independent of the emulated device itself. (In theory, one could make a table for each romtype to know which memory area it uses and the generated internal XML file could use that to properly fill the mem tag.... but is it worth the trouble?)
And the slotmap stuff shows what the mem tag indicates.

OK, all boring, internal stories and perhaps confusing, but if you really wanted to know, that's why Smile

Short version: sorry, due to how openMSX works at the moment. Can't easily fix it. Apologies for the confusion.

By Manuel

Ascended (15829)

Manuel's picture

10-09-2019, 22:31

saccopharynx: I think Edwin looked into that problem a couple of months ago, but he couldn't reproduce it. More people who have a refreshing problem with the code view?

EDIT: oh, I should have checked that bug report. Looks like everyone is running into it...?

By NYYRIKKI

Enlighted (5399)

NYYRIKKI's picture

10-09-2019, 23:46

Manuel wrote:

saccopharynx: I think Edwin looked into that problem a couple of months ago, but he couldn't reproduce it. More people who have a refreshing problem with the code view?

EDIT: oh, I should have checked that bug report. Looks like everyone is running into it...?

Yes... Very annoying problem even when you know to expect it. -> Always remember to scroll once up & down if you use break points and you expect memory to change.

Another kind of nasty one is that you can lock the different debug windows only on certain specific order, other ways they start jumping up & down and get corrupted.

By gdx

Prophet (3087)

gdx's picture

11-09-2019, 01:09

Another problem annoying in laster versions: When I copy files to a DSK, sometime one or two can not be read by OpenMSX. When this happens I have to copy again these files over it. I suspect that OpenMSX has trouble reading fragmented files in DSK.

Another thing: I happened to myself once OpenMSX (Mac version) destroyed the contents of a folder used as a floppy disk. That's why I only use DSKs now.

Even now, I still prefer the BlueMSX debugger despite its restrictions.

By Manuel

Ascended (15829)

Manuel's picture

11-09-2019, 07:21

Gdx, these are not debugger related, but if you can provide steps to reproduce, we will fix the issues.

Page 2/2
1 |