6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Mon Sep 16, 2024 8:01 pm

All times are UTC




Post new topic Reply to topic  [ 413 posts ]  Go to page Previous  1 ... 24, 25, 26, 27, 28
Author Message
PostPosted: Sun Aug 25, 2024 5:26 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8382
Location: Midwestern USA
8BIT wrote:
Do your system have RAM at $CFFF? That area is listed as IO Block in your source.

Code:
         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.

The memory map for the $00Cxxx block is I/O from $00C000 to $00C37F, undecoded from $00C380 to $00C3FF, and RAM from $00C400 to $00CFFF.

Quote:
For instance, this code might be affecting I, M or X flags.

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

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

After coming out of reset and thus with the MPU in emulation mode, it is implied that SP will be $01xx. Hence the above push-and-pull should work on the first pass.  Shortly afterward, when the MPU has been switched to native mode and SP is set to $CFFF, it will still be pointing to RAM.  So the above will work no matter what.

I did verify with my GAL test rig that the GAL in POC V1.4 is correctly decoding the memory map.

Quote:
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.

I actually have not used the syntax checker, so I was unaware there was a problem with SwapBin.  I just let the assembler report syntax issues and fix them all at the same time.  :shock:

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 02, 2024 11:09 pm 
Online
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1738
Location: Sacramento, CA
I have update the simulator to fix the PEA #$1234 error, the issue with the Y register not updating correctly, cleared the B bit when in 65816 native mode, and fix issues with "Casesensitive" assembler options and added "SwapBin" support to the Assembler Options tab with Registry storage.

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

thanks!
Daryl

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 03, 2024 12:46 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8382
Location: Midwestern USA
8BIT wrote:
I have update the simulator to fix the PEA #$1234 error, the issue with the Y register not updating correctly, cleared the B bit when in 65816 native mode, and fix issues with "Casesensitive" assembler options and added "SwapBin" support to the Assembler Options tab with Registry storage.

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

Downloaded.  I will give it a test later on this evening...if I can stay awake.  :shock:

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Sep 03, 2024 4:25 pm 
Offline
User avatar

Joined: Tue Feb 28, 2023 11:39 pm
Posts: 214
Location: Texas
Updated the GitHub repo:
https://github.com/Kelmar/kowalski/rele ... on_1.4.0.5


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 12, 2024 10:48 am 
Offline

Joined: Tue Feb 07, 2023 12:27 pm
Posts: 25
Hi. I started using Kowalski Simulator, it's a very good tool, but I ran into a problem. I have set the input/output to address 0x7F00, where sending data involves writing it to port 0x7f00 and receiving it by reading it from port 0x7f00. It turns out that the terminal built into Kowalski Simulator doesn't work when I enter data into 0x7f00, but works when I enter it into 0x7f01. This forces me to compile two versions of the program, one to check its operation in KS, and the other for my system. Is there an easy way to bypass this problem?
Not working code:
Code:
*=$0300
 LDA #$41
 STA $7f00
 BRK
 

Working code:
Code:
*=$0300
 LDA #$41
 STA $7f01
 BRK
 


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 12, 2024 11:59 am 
Online
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1738
Location: Sacramento, CA
Hello Gregoria,
The answer is yes and no.

For output, you can set the IO area in the Simulator options to $7EFF. This will allow writing characters to $7F00. There may be some side affects if you are using RAM in page $7Exx.

But, input will not be from $7F00. Input is from IO_AREA+4, so in this case it will be $7F03. You will not be able to do both from the same address.

You can set your IO addresses as variables at the top of your code and then you can just change those to assemble for System or Simulator.

Code:
; IO_Page = $7F00
cout = $7F01
cin = $7F04

...

     lda #'A'
     JSR cout

input jsr cin
        beq input
        rts


Daryl

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 16, 2024 3:56 pm 
Offline

Joined: Tue Feb 07, 2023 12:27 pm
Posts: 25
Thank you for the explanation. I have another problem with Kowalski Simulator. How do I save a binary image file larger than 64kB?


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 16, 2024 5:42 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8382
Location: Midwestern USA
gregorio wrote:
How do I save a binary image file larger than 64kB?

Use Ctrl-K to open the save program dialog, select binary image, select Options to set the desired memory range in hex (0x0000 - 0x1FFFF would save 128K) and then save the file.  You can subsequently load the saved binary by using Ctrl-L, selecting binary image, etc.

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 413 posts ]  Go to page Previous  1 ... 24, 25, 26, 27, 28

All times are UTC


Who is online

Users browsing this forum: 8BIT and 6 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: