...There may be another issue involving DP (direct page pointer) when it is set to something other than the default $0000, but I haven’t yet determined if it is a bug in my code or a bug in the simulator’s code. It has to do with temporarily pointing DP to SP+1 in functions (subroutines).
Further to the above, when DP is not pointed to anywhere in the physical zero page, one might expect that during simulation, displaying the zero page range ([Alt-3] from the View selection on the menu bar) would display the MPU’s notion of what is zero page, which would actually be the address range pointed to by DP. Instead, the simulator continues to display what is in the physical zero page, which could mislead one into thinking there’s a bug in one’s code when no apparent zero-page changes seem to occur.
BDD, I know you use macros extensively so please let me know if you find any issues with this fix. Also, I have not forgotten the memory display bugs...they are just more extensive, and I'll have to re-write several whole routines to fix it. I will get to them eventually.
I have fixed a bug with macro names and the case-insensitive configuration. Thanks to gregorio for pointing it out...BDD, I know you use macros extensively so please let me know if you find any issues with this fix.
I’ve downloaded the package and will check it out ASAP.
Quote:
Also, I have not forgotten the memory display bugs...they are just more extensive, and I'll have to re-write several whole routines to fix it. I will get to them eventually.
This is a good fix. I have also fixed the download file so 6502.htm is included. I went through the Windows 11 migration and my dev files are not quite put back yet... I got the html folder but missed 6502.htm. Fixed now.
Sounds like a politician discussing a rigged election.
Quote:
I have also fixed the download file so 6502.htm is included.
Just so you know, I have every simulator ZIP on one of my servers, going back to version 1.2.14.
Quote:
I went through the Windows 11 migration and my dev files are not quite put back yet... I got the html folder but missed 6502.htm. Fixed now.
A large insurance agency client of mine is going through the Windows 11 “upgrade” right now. Their agency management software is so tightly integrated with Windows, when someone sneezes in Redmond, everybody has to reboot. I feel sorry for them—the entire insurance industry marches in lockstep to Microsoft.
I suggest ignoring at least the first tab character in labels. In my opinion, this would improve the readability of user-generated source code and reduce the number of frustrating errors.
I suggest ignoring at least the first tab character in labels. In my opinion, this would improve the readability of user-generated source code and reduce the number of frustrating errors.
I’m not sure I understand what you mean by “first tab character.” Please explain.
In my opinion, this example source code is more readable...
To my eyes, which have been staring at 6502 assembly language programs for nearly 50 years, it looks like a disorganized mess. The labels’ offset from the left actually worsens the readability of the instruction statements. I would find having to read that while debugging a program to be sufficiently annoying to warrant reformatting the listing to get the labels out of the way.
Something that threw me when I first read that was the lack of a blank line between the end of subroutine BLABL and the start of subroutine BLAB2. It appeared that they were one sub...so much for readability. After realizing that BLAB2 was not part of BLABL, I noticed that the former has a little bug in it waiting to bite you.
BTW, just about every assembler I have used required that symbols and labels be started in the first column—and these weren’t just 65xx assemblers. In theory, it should be possible to efface leading whitespace by scanning each source line to find the first non-whitespace character. However, doing so will add processing overhead, especially when assembling many INCLUDE files, without contributing anything to the overall task of generating code.
If you are looking to indent sections to help visualize program flow in loops, you should only indent the mnemonics, operands and comments. Garth has some good illustrations of that on his website. I don’t indent things such as loop bodies in my source, but if I did, I would be using a model such as his.
It's not just a question of removing leading spaces; with the requirement that labels start in column one, if it starts in column one, it's a label. Otherwise either you have to first check that it's not a mnemonic or a pseudo-op and only then assume it's a label, or you have to insist on, and test for, a terminating colon.
Which doesn't work if e.g. you use a colon for labels and nothing for 'equ' and similar...
It's not just a question of removing leading spaces; with the requirement that labels start in column one, if it starts in column one, it's a label. Otherwise either you have to first check that it's not a mnemonic or a pseudo-op and only then assume it's a label, or you have to insist on, and test for, a terminating colon.
Which doesn't work if e.g. you use a colon for labels and nothing for 'equ' and similar...
Yep! I didn’t mention the extra load of discerning between a label or symbol assignment and a valid mnemonic. Complicating things would be if the assembler allowed labels or symbols to have the same name as a mnemonic without setting some requirement on where in the line of code the label/symbol can start. The old Commodore HCD65 assembler for the C-128 allowed labels, symbols and macros to be given mnemonic names, which was handy for making the assembler understand 65C02 instructions with enhanced addressing modes—a macro named LDA was processed instead if the actual mnemonic. However, the assembler required that all such definitions be in column 1, and mnemonics start in column 2 or later.
I feel sorry for them—the entire insurance industry marches in lockstep to Microsoft. 
