Kowalski Simulator Updates

[8BIT]

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

[Klaus2m5]

Thank you very much Daryl. Works like a charm!

[BigDumbDinosaur]

8BIT wrote:

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:

todo.jpg

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

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

[8BIT]

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

[BigDumbDinosaur]

BigDumbDinosaur wrote:

8BIT wrote:

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.

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

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.

localtest.asm

LOCAL LABELS FAILURE DEMONSTRATION

(1.13 KiB) Downloaded 568 times

[8BIT]

Thanks BDD,

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

thanks!

Daryl

[8BIT]

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

[8BIT]

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

[8BIT]

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

Daryl

[BigDumbDinosaur]

8BIT wrote:

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

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: Select all

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

It could be changed to:

Code: Select all

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.

[8BIT]

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

[barrym95838]

BigDumbDinosaur wrote:

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

Code: Select all

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

It could be changed to:

Code: Select all

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

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:

Code: Select all

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

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

Mike B.

[8BIT]

8BIT wrote:

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

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

[8BIT]

barrym95838 wrote:

Does anyone else prefer a different ordering, like so:

Code: Select all

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

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

Mike B.

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

[8BIT]

BigDumbDinosaur wrote:

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: Select all

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

It could be changed to:

Code: Select all

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.

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

Daryl