I can confirm this. However, as there is a work-around, I will not have a look into it ATM, and I lowered the priority. I suspect it is due to the newer handling of the parameters, where you can also skip the spaces, but I would have to have a deeper look into it.
Regards,
Spiro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the problem was that parsing for the "radix" argument conflicted with parsing for a number, so "b" and "d" would always be rated as a radix arg, and not a number :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Confirmed also
> 0400 b
> 0400 d
hex values a/c/e/f works fine. Must use 0b and 0d to poke $0b/$0d
Confirmed also
> 0400 b
> 0400 d
hex values a/c/e/f works fine. Must use 0b and 0d to poke $0b/$0d
Hello,
thank you for your report.
I can confirm this. However, as there is a work-around, I will not have a look into it ATM, and I lowered the priority. I suspect it is due to the newer handling of the parameters, where you can also skip the spaces, but I would have to have a deeper look into it.
Regards,
Spiro
fixed in r23004
the problem was that parsing for the "radix" argument conflicted with parsing for a number, so "b" and "d" would always be rated as a radix arg, and not a number :)
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).