Kowalski Simulator Updates

[BigDumbDinosaur]

Drass wrote:

In running through the opcodes, I did note that PHB and PLB are incorrectly documented as pushing and pulling the B accumulator. In fact the opcodes push and pull the Data Bank Register (DBR). Similarly, PHD and PLD are documented as operating on DBR when in fact they operate on the D register.

Good catch! I've actually not looked at the instruction help screens, so I never noticed that before. Now you've got me perusing the help screens.

While on the subject, the DEA and INA mnemonics (decrement and increment the accumulator, respectively) cannot be used when assembling for the 65C816. Instead, DEC and INC must be used without an operand. The help screens for DEA and INA incorrectly say they are usable when assembling for the 816.

Also noted, the help screens for PEI and PER contain the same text as the help screen for PEA.

BTW, it's better to refer to the direct page register as DP than D. Similarly, the data bank register is best referred to as DB and the program bank as PB (not K). The program counter would be PC, the status register SR and the stack pointer as SP. The problem with using single-letter names for registers other than the accumulator and index registers is it's too easy to mistake single-letter names for other things. For instance, D could refer to the decimal mode bit in SR. Similarly, is P referring to the stack pointer or the status register ("P" isn't even in the latter's name)?

Using DBR and PBR to refer to the data bank and program bank (respectively) could look too much like mnemonics to someone not familiar with the 65C816's instruction set.

In Supermon 816, a register dump would displayed as follows (using made-up values):

Code: Select all

  PB  PC   NVmxDIZC  .C   .X   .Y   SP   DP  DB
; 00 204C  00110000 000A 0000 0050 BFFF 0000 00

Two-character register names in commentary tend to eliminate ambiguity and make it possible to refer to the bits in SR without causing confusion to the reader.

[8BIT]

I'm getting ready to release an update. I'll try to fix these issues before it goes out. it shows how much I was rushing to get the documentation up to date. I hate doing documentation, even though I appreciate it when its done.

thanks!

Daryl

[BigDumbDinosaur]

8BIT wrote:

I'm getting ready to release an update. I'll try to fix these issues before it goes out. it shows how much I was rushing to get the documentation up to date. I hate doing documentation, even though I appreciate it when its done.

thanks!

Daryl

Again, I'd like to offer my help in fixing up the documentation, both for grammar and for technical accuracy. The latter is especially important with the 65C816, which apparently continues to evoke a deer-in-the-headlights reaction in some 6502 enthusiasts. After June 1st I will have more free time available, as I am officially retiring at that time.

[8BIT]

The updates have been completed.

Several documentation errors were corrected in context selective help and help file.
Corrected COP opcode to require an Immediate operand. It was treated like BRK, with an optional operand.
Corrected assembly listing with values greater than $FFFF being truncated.
Added optional parameters to .DATE and .TIME directives. These allow changing or omitting the separator characters.

Added .LSTR & .LSTRING directives. These work just like .STR & .STRING but have a 16 bit length variable vs. an 8 bit length. Maximum editor line length of 1024 limits the strings to about 1016 characters, but that's better than 255 for longer strings. There are work arounds for even longer strings.

The new version is 1.3.4 and the Executable and source code are on my website.
Here's the link -> https://sbc.rictor.org/kowalski.html

Enjoy!

Daryl

[BigDumbDinosaur]

It seems a little problem may have crept into the assembler. Attached are two source files for testing. Copy both of them into a subdirectory and assemble the one named assemble.asm. Examine the listing file. If the error occurs, the conditional assembly statements in both source files will not have been correctly processed.

assemble.asm

Source File w/Conditional Assembly

(296 Bytes) Downloaded 124 times

part2.asm

INCLUDE File w/Conditional Assembly

(199 Bytes) Downloaded 121 times

Edit: This problem likely has existed well before Daryl added his enhancements. Unfortunately, the oldest version I have of the simulator is 1.2.12 and it too fails to correctly handle the conditional assembly statements in the example code.

[8BIT]

OK, I'll look into this. I'm swamped with other stuff for a while, but will work on this as time permits.

Thanks!

Daryl

[GARTHWILSON]

BigDumbDinosaur wrote:

BTW, it's better to refer to the direct page register as DP than D. Similarly, the data bank register is best referred to as DB and the program bank as PB (not K). The program counter would be PC, the status register SR and the stack pointer as SP. The problem with using single-letter names for registers other than the accumulator and index registers is it's too easy to mistake single-letter names for other things. For instance, D could refer to the decimal mode bit in SR. Similarly, is P referring to the stack pointer or the status register ("P" isn't even in the latter's name)?

The P comes from "Processor status." When I see SR, my mind goes to "Shift Register," because of the VIA. I never had any trouble with S, because the 6502 had TXS and TSX right from the beginning, eight years before the '816 was out. The one that does trip me up though is K, and I keep having to look it up because I can't remember if it's "data banK" or "program banK." I do like the fact that all the assembly-language mnemonics are three letters though.

[BigDumbDinosaur]

GARTHWILSON wrote:

The P comes from "Processor status." When I see SR, my mind goes to "Shift Register," because of the VIA. I never had any trouble with S, because the 6502 had TXS and TSX right from the beginning, eight years before the '816 was out. The one that does trip me up though is K, and I keep having to look it up because I can't remember if it's "data banK" or "program banK." I do like the fact that all the assembly-language mnemonics are three letters though.

All the machine language monitors I've used over the last 40+ years, starting with Jim Butterfield's Supermon, through Supermon 64, Commodore's resident monitor in the C-128 (basically Supermon 64 with some enhancements to take advantage of the 128) and Fiscal Information's LKMON (which shipped with the Lt. Kernal hard drive subsystem) use two-character names for registers. Jim Butterfield used AR, XR and YR for the accumulator and index registers, and the same register designations I mentioned for the program counter, status register and stack pointer. When I wrote Supermon 816, I copied the register naming pattern established long ago by Jim Butterfield because I knew that pattern would be familiar to a lot of potential users.

As for the TSX and TXS instructions (and the 816's TCS and TSC instructions), those names are the way they are because MOS Technology followed the IEEE-694 standardized assembly language mnemonic structure (now inactive)—register naming had little to do with it. That standard specified three character mnemonics, with the first character indicating the nature of the operation (e.g., L for load, T for transfer, S for store, etc.). With only three characters allowed in the mnemonic, it took some creativity to somehow represent the operation, the source and the destination. That is why register-to-register mnemonics use a single letter for each register.

[BigDumbDinosaur]

8BIT wrote:

OK, I'll look into this. I'm swamped with other stuff for a while, but will work on this as time permits.

Thanks!

Daryl

Roger that.

Thanks for your hard work.

[8BIT]

BigDumbDinosaur wrote:

It seems a little problem may have crept into the assembler. Attached are two source files for testing. Copy both of them into a subdirectory and assemble the one named assemble.asm. Examine the listing file. If the error occurs, the conditional assembly statements in both source files will not have been correctly processed.

assemble.asm

part2.asm

So, I tested this on all 4 versions I have on my website. All 4 assemble with LDA #0 vs. LDA #123. This includes the last version Michal posted.

Do you have a version where this works? it would be easier to troubleshoot if I had a working version to reference.

Daryl

[BigDumbDinosaur]

8BIT wrote:

So, I tested this on all 4 versions I have on my website. All 4 assemble with LDA #0 vs. LDA #123. This includes the last version Michal posted.

Do you have a version where this works? it would be easier to troubleshoot if I had a working version to reference.

Just to clarify, are you saying conditional assembly for you worked when FLAG is defined?

For your reference, here is the listing output I got after assembling with FLAG defined.

Code: Select all

00001  ;===============================================================================
00002  ;
00003  ;Conditional Assembly Not Working, Part 1
00004  ;
00005    007B              FLAG     =123
00006  ;
00007  00A000                	*=$00a000
00008  ;
00009  	.if .ref(FLAG)
00010  00A000  A9 00         	    lda #0
00011  	.endif
00012  	.include "part2.asm"
00013  ;===============================================================================
00014  ;
00015  ;Conditional Assembly Not Working, Part 2
00016  ;
00017  	.if .ref(FLAG)
00018  00A002  A9 00         	    lda #0
00019  	.endif
00020  	.end
00021  	.end

[8BIT]

I got the same listing as you on all 4 versions.

if I read it correctly, we should see LDA #123 vs LDA #0. So there is a problem, even though there are no ERROR messages generated.

So I was wanting to know what version this worked on previously?

[BigDumbDinosaur]

8BIT wrote:

So I was wanting to know what version this worked on previously?

I thought I still had the older (pre-1.2.12) versions archived on my server, but I must've done some housekeeping in the past. None of the versions that I have correctly honor the conditional assembly function in the test code. I'm surmising the problem existed for a long time and no one evidently noticed it.

[8BIT]

I scraped up a copy of 1.2.6 and the conditional assembly worked on that. As I recall, Michal had done some work with a third level of variables that was present in the 1.2.12 version he posted to github. I have the source for 1.2.6 so I'll compare that to see if I can find the issue.

DAryl

[8BIT]

So its even more odd now. I got home and ran the code and experienced the problem. Now, without changing anything, its working correctly on 3 versions.

This is going to be a hard one to track down.

Daryl