Threaded Mode | Linear Mode

3298 · 05-08-2018, 11:19 AM

(05-07-2018 11:09 PM)Claudio L. Wrote: Done. I followed your exact instructions on a clean directory. Created the commits for your patches and did a pull request from the new "official" repo.

You squashed the patches into a single commit... that wasn't quite what I had in mind, but oh well. To be fair, my instructions weren't precise on that topic.

(05-07-2018 11:09 PM)Claudio L. Wrote: I would call Egan's fork the quasi-official, since he maintained the project for many years, and pulled quite a few of my patches in the past. Eddie's repository should become the one-and-only-true-official repository (no quasi-official, he's the original author).
I wish there was a way to move the new offical repository to the top of the tree, I bet very few people would realize that one of those repositories lost in the middle is the original author.

The "quasi-official" term was not meant to describe Egan's repository, but the one you subsequently turned yours into. I agree that drowning the official repository is less than ideal, but we don't have the power to tweak GitHub's user interface, so we can only hope that soon it floats to the top again by merging yours and putting some additional commit in.

(05-08-2018 02:57 AM)Claudio L. Wrote: A couple of things I noticed after applying all the patches:
* Trying to mount the SD card on newRPL showed "Unsupported CMD8 and CMD55". These are SD commands for SDHC cards. I need to double check on other computers. I could swear I implemented those on x49gp at some point.

I haven't actually tried running NewRPL yet. Your simulator more or less fills the role of providing a platform for fresh NewRPL users to try it out, so getting x49gp to run it is not urgent. On the other hand, I think x49gp could still be a decent development platform in the future (I'm hoping there will be some way to run native applications in NewRPL, roughly similar to HPGCC3?) thanks being an actual emulator, so improved compatibility would be awesome.

(05-08-2018 02:57 AM)Claudio L. Wrote: * The menu sometimes shows up with green text (green as in the same background of the calculator screen). I think the text is being drawn as transparent?

I did notice that the menu text sometimes changes color, but I didn't notice that it's the screen's color. I don't think I missed a note in the API docs about having to set the color for the menu, but even if there's a framework bug, it should get at least a workaround. I'll look into it. I'm pretty sure it's not transparent, because that would mean it would've been partially black when opening it such that it covers the display frame of the 50g. Perhaps it's wrongly picking up something from the color switching for the grayscale stuff.

(05-08-2018 02:57 AM)Claudio L. Wrote: * There were 3 errors (actually warnings) at block-vvfat.c (or vvfat-block.c, whatever) which I just silenced in the makefile (it was an Unused result value from a few functions), not sure if it's the most elegant solution.

That's weird. It simply worked for me with no warnings. Are they new or did they occur in older versions too (i.e. before the -Werror from the official fork turned them into errors)? If they are new, I'd guess they start to appear with the patch suppressing the debug log. And since I don't see them, which functions are they from? I will happily make fixes, but it's kind of hard to fix something one can't reproduce.
I'm running GCC 7.3.1, by the way. Maybe it's a difference between our compilers; a difference in #ifdef branches taken based on our systems could also be there, but I just searched through the file and only found #ifdefs for DEBUG, DBG (don't ask me about the difference between these), DEBUG_SECTORS (I commented out that #define DEBUG line, and there already was #undef DEBUG_SECTORS below it), QEMU_OLD (which shouldn't be set because it persuades the Makefile to try using QEMU 0.9.0 instead of 0.12.50; according to my experience that will fail horribly), __MINGW32__ and _WIN32 (shouldn't be set on supported systems because they clearly aren't Windows), S_IWGRP and S_IWOTH (only defines them as 0 if missing), and a single constant #if 0 (which cannot be different between our systems), so I think that's unlikely.

(05-08-2018 02:57 AM)Claudio L. Wrote: Perhaps you would like to investigate also the ones I couldn't solve myself. In all of them, I'm using Qt Creator as IDE/debugger (but the issues happen with all debuggers in general), works great except:
* When debugging, somehow breakpoints are not set/removed properly. If the code is running, it won't pause when you insert a breakpoint (it should pause, let the debugger set the breakpoint, then continue), so you need to manually pause the code before setting any breakpoints.
* An easy one: when the debugger stops at a breakpoint, doing single step should run the instruction regardless of the presence of the breakpoint (perhaps remove it temporarily, execute, then re-apply the breakpoint). Right now it won't single-step, you need to manually disable the breakpoint or it will be triggered every time.
* When single-stepping through the code, there has to be a way to avoid stepping through IRQs. Right now as soon as an IRQ is triggered, you start single-stepping through its code, making it impossible to debug the main application.

This is also not happening for me. Mind you, I use bare-bones GDB in a terminal instead of an IDE.
With GDB in a terminal, I've only been able to type commands when the debugged process is halted. That may be why I haven't had the chance to trigger the first issue, but I'm not even 100% sure it's an actual issue with x49gp. The IDE likely uses GDB inside, so it might simply be unable to send the commands (that would mean it's an IDE limitation outside x49gp's control). I think it would be interesting to see what happens when combining the IDE and a remote GDB connection to an instance of the regular gdbserver program; if that setup exhibits the same behavior, then we can't do much about it.
I thought I fixed the step / continue from breakpoint issue. That added "continue;" line in timer.c in the "misc fixes" patch makes it skip the code responsible for raising timer interrupts between the call to the GDB stub and the call to QEMU; these timer interrupts were what prevented me from continuing from breakpoints (by stepping / continuing into a timer interrupt, going through that until it returns to user code at the location of the breakpoint, and then immediately raising a trap exception). If the timers are skipped, the single step / continue can move away from the breakpoint position before the check for trap exceptions kicks in.
With that fix in place, I was able to single-step and continue from active breakpoints in my HPGCC3 program just fine, so I'm curious why it's still broken for you.