I have been working on fixing bugs and adding features to the simulator. I am pleased to release v1.2.13 for everyone to use. Please let me know if you have any issues with this release.

Here is a summary of the issues I have collected and their current status:


It has passed both of Klaus' test suites - the 6502 and the 65C02. I has also passed the timing test that BigEd created (details here -> viewtopic.php?f=8&t=3340&p=38584&hilit=kowalski#p38581 )

enjoy!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Thank you very much Daryl. Works like a charm!

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I've downloaded it and will give it a try in the next few days. Thanks for your efforts in updating this software.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

For those interested, unused opcodes in 65C02 mode will be executed as NOP's using the appropriate operand modes. You can use them by using the .DB or .BYTE pseudo opcodes. Here's an example of using the undefined opcode $DB, which has an "absolute" addressing mode.


You can see in the disassembly window that the LDA #$36 at $1003 gets absorbed into $DB's operand. This trick allows you to call either top or val to load different values into address $56, in this example.

As a side note, the yellow pointer will not display on lines that do not contain valid opcodes in the source windows, but you can follow the pointer in the disassembly window. This is on my list to try to fix in the next revision.

The disassembly window will also jump when you move to address $1003 so that you will see the LDA #$36.

The command log will show the correct opcodes, similar to the disassembly window.

I hope everyone finds this useful, or at least understandable.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Well, as some of you know, "the next few days" came and went for me and up until now, I had not been able to give 1.2.13 a test run. I did today and discovered local labels are no longer working properly. Attached is a small source code file that will demonstrate the problem. The code assembles without error in V1.2.12, but not in V1.2.13.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks BDD,

I'll dig out the code and see if I can figure this out.

thanks!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I downloaded a fresh copy of the 1.2.12 sources and compiled using the latest updates for Visual Studio 2017, and this test file also errors. Something has changed in the source since they were compiled by Michael. This will not be as easy to find as I had hoped.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I found the place where the local labels get defined and checked for duplication. I tried your source on the old 1.2.6 source and it works correctly. So, I compared the source for both versions and it appears Michal added a process level local variable.

I could not find any documentation on this but it appears from the source that a label using .. as a prefix might apply to this process level. Where any global label delimits the local label, it appears that a global label named 'proc' is used the delimit this new level. However, without testing it, I would assume that using 'proc' more than once would result in a duplicate label error.

I have added a condition test to the source where the error was occurring and it appears that local labels are working now.

Attached is the binary for new version 1.2.14.

I will post the source files shortly.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Kowalski source code containing 1.2.13 and 1.2.14 fixes for anyone interested.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

V1.2.14 appears to work correctly. It assembled the local labels test program without error. I also used it to assemble POC V1.1's firmware, which is full of local labels in both the main source and in macros. It all assembles without error.

Something that would be worth doing when time permits would be to reduce the amount of whitespace emitted in each line in the listing file. For example, four blanks separate the line number from the assembly address—that could be reduced to two blanks with no loss of readability. Similarly, three blanks could be removed from the whitespace that follows the bytes that have been generated for an instruction.

For example, here's how a line in the listing file looks right now:

Code:

04013    E303  BD 50 D9     .0000010 lda postmemc,x        ;current memory count

It could be changed to:

Code:

04013  E303  BD 50 D9  .0000010 lda postmemc,x        ;current memory count

The result is a longish comment wouldn't be wrapped to the next line, improving the readability of the listing. Dunno how much of a deal it would be to fix this.

Anyhow, thanks for tracking down and fixing the local labels error.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Glad to hear you POC sources compile now BDD. I will look into the list output. I use Windows notepad to view my listings and it does not wrap the lines, so the spacing doesn't affect me. If I can find where to adjust it, I'll post it here.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

It almost looks like he was leaving space for a 24-bit address and a fourth instruction byte, huh?

Does anyone else prefer a different ordering, like so:

It would allow a .lst file to be pasted directly into a Woz-style monitor.

Mike B.

I found the report section. There is 1 case where it allows 4 bytes in the byte list, but I'm not sure where it would get used. Data declarations do no output the byte list and there are no 4 byte opcodes. I will edit the 1,2 & 3 byte fields to shorten the white space, and the 4 byte one will be untouched, meaning that line on a listing will be spaced differently, but this should be rare or never.

As for rearranging the order, I can do that too, but do not want to create any forks for future releases, so we'll need a consensus from the group. I can create a one-time executable with that format if you would like.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Hi Mike,

I just realized that this will only work for instructions... any data declarations will fail as the assembler does not output a list of bytes for data sections. it would take a lot of time to dig deeper in the code to change that. It would be easier to build a stand alone executable that could take a binary image and convert that to a Woz friendly listing.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Give this version a try... the white spaces should be shortened.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/