6502.org Forum Projects Code Documents Tools Forum
It is currently Fri Nov 22, 2024 8:39 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Emulation and Simulation

All times are UTC




Post new topic Reply to topic  Page 12 of 28
  [ 413 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14, 15 ... 28  Next
  Previous topic | Next topic 
Author Message
BigDumbDinosaur
PostPosted: Thu Mar 18, 2021 12:52 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8506
Location: Midwestern USA
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:
  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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Thu Mar 18, 2021 1:20 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Mar 18, 2021 1:32 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8506
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Thu Mar 18, 2021 3:57 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Mar 18, 2021 4:36 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8506
Location: Midwestern USA
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.

Attachment:
File comment: Source File w/Conditional Assembly
assemble.asm [296 Bytes]
Downloaded 59 times
Attachment:
File comment: INCLUDE File w/Conditional Assembly
part2.asm [199 Bytes]
Downloaded 61 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.

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


Last edited by BigDumbDinosaur on Fri Mar 19, 2021 7:08 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
8BIT
PostPosted: Fri Mar 19, 2021 1:55 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Fri Mar 19, 2021 2:24 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Fri Mar 19, 2021 6:37 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8506
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Fri Mar 19, 2021 6:38 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8506
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Fri Mar 19, 2021 4:19 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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.

Attachment:
assemble.asm
Attachment:
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

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Fri Mar 19, 2021 6:29 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8506
Location: Midwestern USA
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:
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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Fri Mar 19, 2021 6:37 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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?

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Fri Mar 19, 2021 7:03 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8506
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Fri Mar 19, 2021 10:57 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Fri Mar 19, 2021 11:45 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 12 of 28
  [ 413 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14, 15 ... 28  Next

Board index » 6502.org Users Forum » Emulation and Simulation

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.