Kowalski Simulator Updates

[8BIT]

I made the updates to CCrystalTextEditBuffer.cpp & .h, but I get 1 error:

Line 156 of .h: 'nullptr' : undeclared identifier

This variable also appears on line 99 of the .cpp file:
m_pszText = nullptr; // Being pedantic about clearing our pointer.


My guess is that VS2022 defines this but my old VS2008 does not. What are your thoughts to correct this?

thanks!
Daryl

[AndrewP]

I don't have a specific solution but I do have a couple of thoughts.

nullptr was only introduced in C++11. I don't know if VS2008 has been updated for C++11 but my gut feel is that it won't have been.

You could probably define something like:

Code: Select all

#define nullptr ((void*)0)

or

Code: Select all

#define nullptr NULL

to make it work.

If someone uses VS2022 I guess this will break their compilation so it might need to be guarded with:

Code: Select all

#if __cplusplus < 201103L
#define nullptr ((void*)0)
#endif

...but the above is all completely untested and your mileage may vary.

[8BIT]

thanks for the tip!

I tried the ((void*)0) but the compiler complained about converting void * to TCHAR * so I changed it to ((TCHAR *)0) and that worked.

I also wrapped it like this:

Code: Select all

#ifndef nullptr
#define nullptr ((TCHAR*)0)
#endif

I'm open to further suggestions if this is not correct.

I'll play around with the editor and the undo queue with these changes applied.

thanks!
Daryl

[BigDumbDinosaur]

(Feeling a bit bad for causing all this gnashing of teeth over some strange Microsoft drivel)

[John West]

8BIT wrote:

Code: Select all

#ifndef nullptr
#define nullptr ((TCHAR*)0)
#endif

That's not right.

In C++11 and later nullptr is a keyword (not a macro, so the preprocessor won't know about it). And #defining keywords is not permitted. So that code, while it might compile and work, is technically illegal under C++11.

Before C++11 we had NULL, which is defined to be the literal 0 (or "an integral constant expression rvalue of integer type that evaluates to zero"). It's only C that wants it to be cast to a pointer type.

I can't find an accurate way to test whether a compiler supports nullptr or not. __cplusplus is the closest, but that can still cause problems: some versions of VC++ supported some but not all of C++11, so they had nullptr but __cplusplus still reported an earlier standard. And gcc had it defined as 1 for a while. So the best I can suggest is

Code: Select all

#if __cplusplus < 201100
#define nullptr NULL
#endif

If that causes problems with one particular compiler, find a way of identifying it and include that in the condition.

(and this is not "some strange Microsoft drivel". It's C++ adding features with no reliable way of testing for their presence, people still using very old compilers, and what looks like a third party library of unknown quality)

[BigDumbDinosaur]

John West wrote:

(and this is not "some strange Microsoft drivel". It's C++ adding features with no reliable way of testing for their presence, people still using very old compilers, and what looks like a third party library of unknown quality)

We need a “facetious” tag!  I would have used it in my earlier lament. 

As for C++... “hideous mess” comes to mind when I see that in print.

[Yuri]

8BIT wrote:

I made the updates to CCrystalTextEditBuffer.cpp & .h, but I get 1 error:

Line 156 of .h: 'nullptr' : undeclared identifier

This variable also appears on line 99 of the .cpp file:
m_pszText = nullptr; // Being pedantic about clearing our pointer.


My guess is that VS2022 defines this but my old VS2008 does not. What are your thoughts to correct this?

thanks!
Daryl

D'OH! Completely forgot about that. nullptr is a keyword in a later C++ revision. Just replace with NULL, should be fine.
Sorry about that.

[Yuri]

John West wrote:

8BIT wrote:

Code: Select all

#ifndef nullptr
#define nullptr ((TCHAR*)0)
#endif

That's not right.

In C++11 and later nullptr is a keyword (not a macro, so the preprocessor won't know about it). And #defining keywords is not permitted. So that code, while it might compile and work, is technically illegal under C++11.

Before C++11 we had NULL, which is defined to be the literal 0 (or "an integral constant expression rvalue of integer type that evaluates to zero"). It's only C that wants it to be cast to a pointer type.

I can't find an accurate way to test whether a compiler supports nullptr or not. __cplusplus is the closest, but that can still cause problems: some versions of VC++ supported some but not all of C++11, so they had nullptr but __cplusplus still reported an earlier standard. And gcc had it defined as 1 for a while. So the best I can suggest is

Code: Select all

#if __cplusplus < 201100
#define nullptr NULL
#endif

If that causes problems with one particular compiler, find a way of identifying it and include that in the condition.

(and this is not "some strange Microsoft drivel". It's C++ adding features with no reliable way of testing for their presence, people still using very old compilers, and what looks like a third party library of unknown quality)

Yea, there's no need to go through all of that, just replace my use of nullptr with NULL in that one header and all will be well.

And yes, C++ has been adding all sorts of crap lately. Some of it is good, most of it..... no so much....

EDIT: I just checked VC 2022 won't go any lower than C++14 now. >_<
Oh well.... I'll be more mindful next time when I make an edit.

[8BIT]

Got it. I replaced the 2 'nullptr' references to 'NULL' and compiled without error. Did a quick test at deleting some text - single deletes, backspaces, and block deletes and then did undo for all of it and it worked just fine. It will be interesting to see if BDD encounters the lockup any more.

Version 1.4.0.4 is now on my website. https://sbc.rictor.org/kowalski.html

Let me know if there are any issues.

thanks!
Daryl

[BigDumbDinosaur]

8BIT wrote:

It will be interesting to see if BDD encounters the lockup any more.

We shall soon know. 

[BigDumbDinosaur]

BigDumbDinosaur wrote:

8BIT wrote:

It will be interesting to see if BDD encounters the lockup any more.

We shall soon know. 

Regarding version 1.4.0.4, so far, so good with find-and-replace.  I haven’t done too much with it to date, but have something on which I will soon be working that will give the editor plenty of exercise and thus opportunities to crash following a find-and-replace.

In the assembler, I did discover that the PEA instruction is now broken; PEA #$1234 will fail to assemble and the error ERROR E006: Value doesn't fit in single byte. will be emitted.  PEA #$12 will assemble, however.

On a different note, I was fiddling around with 65C816 simulation while testing some code, which follows:

Code: Select all

         sei                   ;(2)
         sec                   ;(2)
         xce                   ;(2) select emulation mode
;
;
;	short delay to illuminate the MCE indicator, if present...
;
         ldx #0                ;(2)
         txy                   ;(2)
;
init     inx                   ;(2)
         bne init              ;(3,2)
;
         iny                   ;(2)
         bne init              ;(3,2)
;
         clc                   ;(2) return to...
         xce                   ;(2) native mode
         rep #%11011011        ;(3)
         sep #%00100100        ;(3)
         brk                   ;(8) <—— stopped here

Numbers in parentheses are the cycles per instruction.

After running the above, the simulator’s MPU status window (below) was showing some confusing-to-me information:

• 

  65C816 Simulation Status

The P=$24 status register (SR) value is correct, but as can be seen, an erroneous ‘B’ flag is present and set, which SR doesn’t have when the 816 is running in native mode (B is replaced by x).  The e, m and x flags are as expected.

I'm trying to figure out what the ‘B=$00’ field is supposed to mean.  Also, the 816-specific register names are somewhat confusing; for example, ‘PBR’ if spoken aloud as words, would be “‘program bank register’ register,” kind of like saying “PIN number.”    Also, it took me a moment to figure out that ‘DIR’ is referring to the direct page pointer; that should probably be ‘DP’.

The value shown for .Y is erroneous as well.  At the point where the program stopped, .Y would be $0000.  Also, it appears the clock cycle count is off.  Unless I'm missing something, the above code should have consumed about 1,638,400 cycles.  Live testing of this code in a ROM on POC V1.4 with Ø2 running at 1 MHz bears out my cycle count estimate.  The MCE LED (controlled by the MPU’s E output) stays illuminated for a little less than two seconds.

Other than the above, things seem to be working okay.

[8BIT]

Thanks for the feedback BDD!

PEA will work for now as PEA !#1234. I have a fix for allowing PEA #1234 while causing the "value won't fit in a byte" error for LDA #300 and others.

The B bit is reflecting the Emulation mode status of Break. I left it to the user to know that when in native mode, that bit is not used, I could clear the check mark if you think it would be more clear?

B= $00 is the internal value of the B register ( upper 8 bits of the Acc ) XBA swaps this with A in 8 bit mode.

Yes, the DIR is the "D" Direct register. I didn't want to call it D as that would get confused with the D bit of the status register. I chose DIR. I will add something to the help system to describe the register definitions.

Something is amiss with the Y register. If you single step it past the loop, Y will be $0000. Only when changing the X bit in run mode does it return $0100. I should be able to find this and get it corrected.

It's possible the cycle counting is off... I made sure I had the right counts for each opcode, but may have missed some of the notes and exceptions regarding emulation mode timing. I'll dig into it when I get some time.

I'm glad to hear the rest of the program is working ok. Thanks again for the feedback!

Daryl

[8BIT]

I just ran a spreadsheet with the cycle counts.

Using the cycle counts you provided above in (), I came up with 328723 cycles, not counting the BRK. Can you post your calculations that brought you to 1,638,400 cycles?

Here's mine:

Code: Select all

pre loop    10 cycles

X loop   (255 * 5) + 4 = 1279    -> loops 255 times with 5 cycles per loop plus last loop does not branch and uses 4 cycles.

Y loop   (255 * 5) + (255 * 1279) + 4 = 327424   -> loops 255 times with 5 cycles per loop plus the full X loop done 255 times plus 4 cycles on the last loop.

post loop   10 cycles

10 + 1279 + 327424 + 10 = 328723.

Assuming this is your RESET code, is it possible the E LED illuminates during RESET and that the RESET line is being held low for 1.3 seconds?

Daryl

[BigDumbDinosaur]

8BIT wrote:

I just ran a spreadsheet with the cycle counts.

Using the cycle counts you provided above in (), I came up with 328723 cycles, not counting the BRK. Can you post your calculations that brought you to 1,638,400 cycles?

Here's mine:

Code: Select all

pre loop    10 cycles

X loop   (255 * 5) + 4 = 1279    -> loops 255 times with 5 cycles per loop plus last loop does not branch and uses 4 cycles.

Y loop   (255 * 5) + (255 * 1279) + 4 = 327424   -> loops 255 times with 5 cycles per loop plus the full X loop done 255 times plus 4 cycles on the last loop.

post loop   10 cycles

10 + 1279 + 327424 + 10 = 328723.

Here again is an annotation of the delay loop:

Code: Select all

init     inx                   ;(2)   —— 2 × 256 = 512
         bne init              ;(3,2) —— 3 × 255 + 2 = 767 (Xloop = 1279)
;
         iny                   ;(2)   —— 2 × 256 = 512
         bne init              ;(3,2) —— 3 × 255 + 2 = 767 (Yloop = 1279)

TOTAL CYCLES = Xloop × 256 + Yloop

The correct value of TOTAL CYCLES as annotated above would be 328,703.  When I was doing the previous cycle count, I apparently somehow did 1279 × 1279, instead of 1279 × 256. 

Quote:

Assuming this is your RESET code, is it possible the E LED illuminates during RESET and that the RESET line is being held low for 1.3 seconds?

The LED does illuminate during a power-on reset, but, interestingly, does not light up when the reset button is pressed, or even when held down for a while.  Below is the entirety of the code:

Code: Select all

	.opt proc65816,caseinsensitive,swapbin
;===============================================================================
;
;HARDWARE QUALIFICATION TEST ROM
;
;	—————————————————————————————————————————————————————————————————————
;	This code programs a ROM to “touch” RAM in the range $000000-$00BFFF
;	for the purposes of proving that RAM decoding is functional.  Testing
;	consists of writing $EA (NOP) into each address, followed by a short
;	delay, after which the content is checked.  If the checkfails, the
;	MPU is switched back to emulation mode & halted.  With POC V1.4 &
;	later, returning to emulation mode will cause the MCE indicator to
;	illuminate.  A short test at the beginning of this code momentarily
;	illuminates MCE to prove that it is functional.
;
;	NOTE: No interrupts are trapped.  IRQs are masked, but an NMI will
;	      likely derail the MPU.
;	—————————————————————————————————————————————————————————————————————
;
mc_nop   =$ea                  ;NOP opcode
ramstart =$000000              ;start of base RAM
ramend   =$00c000              ;start of I/O block
romstart =$00d000              ;start of ROM
ve_reset =$00fffc              ;reset hardware vector
hwstack  =romstart-1           ;top of MPU stack
;
	*=romstart
;
         sei
         cld                   ;just in case
;
start    sec                   ;select...
         xce                   ;emulation mode...
;
;			—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-
;			On POC V1.4 & later, putting the MPU into emulation
;			mode will cause the MCE (machine check exception)
;			indicator to illuminate.  The following loop will
;			keep the MPU in emulation mode long enough to light
;			the LED & prove it’s operating.
;
;			As the test code runs, it will periodically return
;			to START, thus causing MCE to flicker & indicate
;			that processing is continuing.
;			—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-
;
         ldx #0
         txy
;
init     inx
         bne init
;
         iny
         bne init
;
         clc                   ;select...
         xce                   ;native mode...
;
;			—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—
;			At this point, MCE should extinguish.
;			—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—
;
         lda #%00100100
         pha                   ;do MPU...
         plp                   ;test setup...
;
;			—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-
;			Above clears n,v,x,d,z,c & sets m,i.
;			—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-
;
         pea #0                ;DP must be...
         pld                   ;at $0000
         ldx !#hwstack         ;set top of...
         txs                   ;MPU stack
;
;——————————————
;MAIN TEST LOOP
;——————————————
;
         lda #mc_nop           ;test value
         ldx !#0               ;index
         ldy !#ramend-ramstart ;counter
;
main     sta ramstart,x        ;write test value & wait
         .dcb 100,mc_nop       ;100 NOPs to waste time
         cmp ramstart,x        ;check test value
         bne error             ;oops!
;
         inx                   ;next location
         dey                   ;--COUNT
         bne main              ;continue
;
         brl start             ;endlessly loop
;
;
;	error handler...
;
error    sec                   ;return to...
         xce                   ;emulation mode
         .dcb 10,mc_nop
         stp                   ;halt system
;
;—-—-—-—-—-
;
textend  =*
;
         .dcb ve_reset-textend,$ff
;
	*=ve_reset
;
         .word romstart
         .word $ffff
;
	.end

Note that the above endlessly repeats the test loop, which causes the MCE LED to light up after each pass.  Despite the (re)calculated cycle count, MCE is staying lit for longer than 0.3 seconds during each pass.  Something is hinky... 

[8BIT]

Do your system have RAM at $CFFF? That area is listed as IO Block in your source.

Code: Select all

         ldx !#hwstack         ;set top of...
         txs                   ;MPU stack

If there is no RAM there, then its possible some of your code is might be causing a longer loop. For instance, this code might be affecting I, M or X flags.

Code: Select all

         lda #%00100100
         pha                   ;do MPU...
         plp                   ;test setup...

PLP might be pulling other bits if the stack points to non-RAM.

I'm working on the corrections and found another issue. The syntax checker in the editor flags the REP and SEP commands with error 6 if you press enter on either line. This is because the syntax checker assembles just the one line without knowledge of the assembler options - SwapBin included. I need to work out how to fix that, maybe adding another registry option on the assembler options to set SwapBin.

Daryl