6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 22, 2024 9:38 am

All times are UTC




Post new topic Reply to topic  [ 413 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 28  Next
Author Message
PostPosted: Tue Dec 01, 2020 4:54 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8505
Location: Midwestern USA
jdimeglio wrote:
Sorry still got bugs.

So when i run up my polished monitor :-) :-) it assembles (f7), it debugs (f6) and Run is highlighted (f5). Hitting Run does nothing other then grey out all the options.
I've tried to step in rather than run, even place a breakpoint on RESET.

Is this worth fixing? Are there any more 65C02 die-hards out there? or am i just better off using an older version..

PS:@BigDumbDinosaur i added .OPT proc65C02,swapbin (and removed it and all the @<->% in troubleshooting this issue)

I loaded up an old 65C02 program, assembled it and ran the simulation. It appeared to function okay.

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 01, 2020 5:30 am 
Offline
User avatar

Joined: Wed Nov 11, 2020 3:33 am
Posts: 22
Location: Sydney
I'll look into it further - i dont want to be that dumb new noob on the forum :-)

_________________
_________________________________________________________________________
Checkout my 2pass assembler/monitor https://github.com/jdimeglio/6502-Monitor


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 01, 2020 5:31 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
jdimeglio wrote:
Sorry still got bugs.

So when i run up my polished monitor :-) :-) it assembles (f7), it debugs (f6) and Run is highlighted (f5). Hitting Run does nothing other then grey out all the options.
I've tried to step in rather than run, even place a breakpoint on RESET.

Is this worth fixing? Are there any more 65C02 die-hards out there? or am i just better off using an older version..


Yes, I want this to function correctly for all versions of processors. Some of my fixes also affect 65C02 and 6502 operation, and I am not planning to update version 1.2 separately.

I will grab your source from github and see if I can re-produce the trouble. That way I can troubleshoot the issue.

Daryl

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 01, 2020 5:48 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
OK, so here's the scoop.

The simulator will start execution at the first *= or .ORG it encounters.

The first *= that the assembler encounters in your source is the one in constants.65s. That is *= $0018 on line 67.

At address, $0018, is $00. The simulator starts execution be running a BRK opcode and going to the IRQ vector.

However, if you press debug, then RST, then Run, you will get your splash screen in the IO Window.

All appears to be good.

Daryl

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 01, 2020 5:53 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
BigDumbDinosaur wrote:
Everything appears to be copacetic with it. It successfully assembled the POC V1.2 firmware.
Good job!

That is good news. Thanks for the update. I started digging into expanding the memory to 16MB. Lots to research and lots of Polish-English translations - thanks Google translate!!

Daryl

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 03, 2020 6:05 am 
Offline
User avatar

Joined: Thu Mar 11, 2004 7:42 am
Posts: 362
jdimeglio wrote:
https://github.com/jdimeglio/6502-Monitor

Looks like you've got a bug in the T command; there should be a CLD at NBRNCH (after JSR SAVE) and BRANCH, otherwise the PCADJ calculations can be wrong if you step through code that runs in decimal mode. The S command from the Apple II old monitor ROM has this same bug for the BRANCH case (the SAVE registers routine contained a CLD so NBRNCH was ok).

See also this post on the same subject:

viewtopic.php?p=68234#p68234


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 04, 2020 12:16 am 
Offline
User avatar

Joined: Wed Sep 03, 2003 6:53 pm
Posts: 153
Location: Long Island, NY
8BIT wrote:
*** EDIT *** I have updated the zip file with the corrected program. The Missing ORG error is fixed.

Here is the latest version - 1.3.2

It includes the \x overrides I mentioned previously, a few fixes, some added features, and updated help.

Features added:

Code:
     .XWORD  $123456     ; 24 bit constant declaration
     .DX     $123456

     .DWORD  $12345678   ; 32 bit constant declaration
     .DDW    $12345678

     .DATE               ;  inserts ASCII date in the format YYYY-MM-DD into the output file.  It is not null-terminated.

     .TIME               ; inserts ASCII time in the format (24 hour time)  HH:MM:SS.  It is not null-terminated.

     COP       #$00      ; you can insert an immediate value after COP   -  $02 $00
     COP                 ; or you can have just the opcode - $02


I also added all of the 65816 opcodes to the help file along with the new 65816 mode chart. There is a new page on overriding the operand sizes as well, which covers immediate '!#' and '\1', '\2', and '\3'.

The assembler makes an assumption that any undeclared variable will be 16 bits by default. If it later is found to fix in 8 bits or 24 bits, it will adjust the output accordingly. However, if an address label value changes between the first and second pass, a "Phase Error" will be generated. This is not new, but may be encountered more often with the increased possibility of operand size changes. This can be hard to troubleshoot as the error will tell you where the label is, but not where the variable size change happened. It would require a major rewrite to allow better error reporting. I am investigating other options.

Please give this a try - try to use the new features, and let me know if you find any issues.

thanks!

Daryl


Hey, Daryl. Great thing I found this! I'm getting back into some 6502 projects after a loooong side trip into the Z80/S100 world. Anyway, I'm working with a 65816 board from the Retrobrew series (all ECB-format boards) and helping one of my friends there with software to support some peripheral boards. I downloaded it and will give it a whirl. I've tried to use the WDC tools but I find them clunky, and other tools like Nu256 or whatever are too specific.

So, looking forward to this. It's amazing how much I've forgotten about 6502 code.I had to pull out my old VIC-20 Programmer's Reference Guide to take a refresher.

Later.
Rich

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 04, 2020 3:19 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
Hello Rich,

Welcome back to 6502 turf! I hope you are well, its been a long time! Do you still have any SBC 2.7 boards? I had someone I was helping with drivers ask about an SBC2 board.

Let me know if you have any questions or find any issues with the program.

Be well!

Daryl

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 04, 2020 1:46 pm 
Offline
User avatar

Joined: Wed Sep 03, 2003 6:53 pm
Posts: 153
Location: Long Island, NY
Thanks Daryl, good to be back.

I do have boards still available, 2.7R1. Someone contacted me the other day and his board is shipping today...not sure if the same person.

Will let you know how it goes with using the simulator; will likely have some time this weekend to play with it.

Rich

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 05, 2020 2:02 am 
Offline
User avatar

Joined: Wed Sep 03, 2003 6:53 pm
Posts: 153
Location: Long Island, NY
Daryl --

I really like the simulator. So, the short story on the project is that there is a graphics/sound board comprising of a TMS9918 video chip and AY3-8912 audio chip that was used with a Z80 SBC and now we want to use it with a 65816-based SBC. So, I ported the Z80 test code over to the '816 using '816 instructions for certain 16-bit operations (mostly music note values which are 12-bit). Except for that, it would work fully in 8-bit mode.

This is my first exposure to the '816 and the WDC tools which I find kind of clunky. Yours is a pleasure to use. I have a handful of suggestions, if that's ok.

* CPU mode 8/16 management. I guess this could be handled by macros, but I liked the WDC LONGA/LONGI thing, EXCEPT that you also had to put the REP/SEP instructions too. If there was a way to use a single obvious directive for this, that would be great.

* Line numbers. Other IDEs I've used allow for showing line numbers on the left side of the editor. I know the line number is in the status bar, but my eye doesn't naturally gravitate there when editing and scrolling.

* Assembly. In moving the code over, there was a lot of tinkering I needed to do finding syntactical errors ("$" versus "h" for example). When you hit Assemble, it stops at the first error, but then you have to hit Assemble again to get to the next one. I find it easier to edit a file if I can see all of the errors at once so I can roll through the whole file and make corrections.

* Love the context.sensitive help.

* Indication that the file hasn't been saved. Some IDEs I've used gray-out the SAVE icon when the file is "clean" (no changes) and then enable it when it's "dirty" and often put some other indicator somewhere (like a "*" after the file name in the title bar).

* Listing files. One of the options dialog tabs has a checkbox to allow generating listing files during the assembly. Rather than having to type in the file name of the listing file, I might suggest just a check box and then assume the list file base name is the same as the source file.

* Object output. To save the compiled output requires a separate "save code" operation. Similar to the listing file, I kind of feel that this should be automatic. Putting an option in the Assembler settings tab for a default assembler output would save a step.

* 65816 debugger. This is probably on the TODO list. Maybe there's a way you can suggest for me to eliminate the 16-bit LDA/STA so I can use the 6502 mode and debugger for the note values. Code grabs a 16-bit value and sends MSB,LSB separately BUT the value is changed/incremented in the code as a 16-bit unit. That would involve an INC/CMP/INC/XOR maybe.

Thanks again for such a great tool. It's some awesome work and a well-executed IDE.

Rich

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 05, 2020 5:08 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
RichCini wrote:
This is my first exposure to the '816 and the WDC tools which I find kind of clunky. Yours is a pleasure to use. I have a handful of suggestions, if that's ok.

Hi Rich, suggestions are always welcome. While I have been adding 65816 features to the program, I'd like to just say that this is Michal Kowalski's program. He did a great job in putting the IDE together. I initially found some errors in the opcode timing and needed to do some very accurate cycle counting, so I decided to attempt the fixes needed. That has morphed into fixing other bugs and adding a few simple features. I have left the basic look and feel of the program as original as I could. Given that, here are my thought on your suggestions

Quote:
* CPU mode 8/16 management. I guess this could be handled by macros, but I liked the WDC LONGA/LONGI thing, EXCEPT that you also had to put the REP/SEP instructions too. If there was a way to use a single obvious directive for this, that would be great.
I will look at adding some assembler directives that can accomplish this. Until then, you can use macros to accomplish this task.

Quote:
* Line numbers. Other IDEs I've used allow for showing line numbers on the left side of the editor. I know the line number is in the status bar, but my eye doesn't naturally gravitate there when editing and scrolling.
I would have to totally rewrite the editor to allow for line numbers, which is beyond the scope of what I set out to do.

Quote:
* Assembly. In moving the code over, there was a lot of tinkering I needed to do finding syntactical errors ("$" versus "h" for example). When you hit Assemble, it stops at the first error, but then you have to hit Assemble again to get to the next one. I find it easier to edit a file if I can see all of the errors at once so I can roll through the whole file and make corrections.
The way the assembler is written, it would be a major rewrite to incorporate this feature. While it is not hard to add logging, the code is written so that when an error is encountered, subroutines are exited with the error code, which then filters up through all subroutine before the error is processed. The program will highlight syntax errors as you type lines, which is great for new work. What I find when porting existing code is if I encounter a particular error that involves changing symbols, I do an global replace to eliminate repeated errors. I know that is not always possible.

Quote:
* Love the context.sensitive help.
I do too! Thank Michal for that - he did a great job with the editor, other than not allowing the DOS box-drawing characters to be displayed. I'm still trying to figure that out (Windows C++ coding really sucks)

Quote:
* Indication that the file hasn't been saved. Some IDEs I've used gray-out the SAVE icon when the file is "clean" (no changes) and then enable it when it's "dirty" and often put some other indicator somewhere (like a "*" after the file name in the title bar).
I like this idea and will try to add it for my next release.

Quote:
* Listing files. One of the options dialog tabs has a checkbox to allow generating listing files during the assembly. Rather than having to type in the file name of the listing file, I might suggest just a check box and then assume the list file base name is the same as the source file.
Some like the option, other do not. I have just entered "listing.lst" and I do not edit it for each project, and it seems to work that way.

Quote:
* Object output. To save the compiled output requires a separate "save code" operation. Similar to the listing file, I kind of feel that this should be automatic. Putting an option in the Assembler settings tab for a default assembler output would save a step.
If this was just an assembler, I would agree. But it was written as integrated editor, assembler, simulator/debugger and does not need an object file to operate. Also, there are many options for generating object files, including setting the target memory range. I think it's best to leave this as it is.

Quote:
* 65816 debugger. This is probably on the TODO list. Maybe there's a way you can suggest for me to eliminate the 16-bit LDA/STA so I can use the 6502 mode and debugger for the note values. Code grabs a 16-bit value and sends MSB,LSB separately BUT the value is changed/incremented in the code as a 16-bit unit. That would involve an INC/CMP/INC/XOR maybe.
Yes, once I get the assembler working on the 16MB address space, my next goal is to tackle the disassembler and debugger. That will be a major undertaking to get right and it will require a lot of testing. If you want to use the 65C02 simulator, then it would be possible to rewire the 16-bit operations as 8-bit. Post some code snippets and I or others can help with the translation.

Quote:
Thanks again for such a great tool. It's some awesome work and a well-executed IDE.
It is and you are welcome for my parts. I have to give most of the credit to Michal.

Daryl

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 05, 2020 5:46 pm 
Offline
User avatar

Joined: Wed Sep 03, 2003 6:53 pm
Posts: 153
Location: Long Island, NY
8BIT wrote:
RichCini wrote:
This is my first exposure to the '816 and the WDC tools which I find kind of clunky. Yours is a pleasure to use. I have a handful of suggestions, if that's ok.

Hi Rich, suggestions are always welcome. While I have been adding 65816 features to the program, I'd like to just say that this is Michal Kowalski's program. He did a great job in putting the IDE together. I initially found some errors in the opcode timing and needed to do some very accurate cycle counting, so I decided to attempt the fixes needed. That has morphed into fixing other bugs and adding a few simple features. I have left the basic look and feel of the program as original as I could. Given that, here are my thought on your suggestions

I guess I didn't realize the entire project chain, so thanks for clarifying that.

8BIT wrote:
RichCini wrote:
* Line numbers. Other IDEs I've used allow for showing line numbers on the left side of the editor. I know the line number is in the status bar, but my eye doesn't naturally gravitate there when editing and scrolling.
I would have to totally rewrite the editor to allow for line numbers, which is beyond the scope of what I set out to do.

Understood, thanks. I have some experience in Windows programming through my Altair32 Emulator so I can appreciate the effort it takes to grafting code into someone else's work, particularly UI. I did find some code to do it, but grafting it in would depend on how the MDI window code is written.

8BIT wrote:
RichCini wrote:
* Assembly. In moving the code over, there was a lot of tinkering I needed to do finding syntactical errors ("$" versus "h" for example). When you hit Assemble, it stops at the first error, but then you have to hit Assemble again to get to the next one. I find it easier to edit a file if I can see all of the errors at once so I can roll through the whole file and make corrections.
The way the assembler is written, it would be a major rewrite to incorporate this feature. While it is not hard to add logging, the code is written so that when an error is encountered, subroutines are exited with the error code, which then filters up through all subroutine before the error is processed. The program will highlight syntax errors as you type lines, which is great for new work. What I find when porting existing code is if I encounter a particular error that involves changing symbols, I do an global replace to eliminate repeated errors. I know that is not always possible.


Again, the perspective is helpful.

8BIT wrote:
RichCini wrote:
* Listing files. One of the options dialog tabs has a checkbox to allow generating listing files during the assembly. Rather than having to type in the file name of the listing file, I might suggest just a check box and then assume the list file base name is the same as the source file.
Some like the option, other do not. I have just entered "listing.lst" and I do not edit it for each project, and it seems to work that way.


Good idea. Thanks. I know there's basically dynamic error correction (from the above), but does the lister emit error lines? If it does, then using the listing to help with bulk corrections could be the solution for modifying existing code (rather than new code creation).

8BIT wrote:
RichCini wrote:
* Object output. To save the compiled output requires a separate "save code" operation. Similar to the listing file, I kind of feel that this should be automatic. Putting an option in the Assembler settings tab for a default assembler output would save a step.
If this was just an assembler, I would agree. But it was written as integrated editor, assembler, simulator/debugger and does not need an object file to operate. Also, there are many options for generating object files, including setting the target memory range. I think it's best to leave this as it is.


Again, the perspective is helpful, thanks. If the code ever becomes publicly available, I would be happy to try to tinker with it. I'm assuming it's written in C/C++ rather than C# or something else.

Rich

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 05, 2020 7:48 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
8BIT wrote:
RichCini wrote:
* CPU mode 8/16 management. I guess this could be handled by macros, but I liked the WDC LONGA/LONGI thing, EXCEPT that you also had to put the REP/SEP instructions too. If there was a way to use a single obvious directive for this, that would be great.

I will look at adding some assembler directives that can accomplish this. Until then, you can use macros to accomplish this task.

I like the way the C32 assembler which I use does it. I do have macros with descriptive names (ACCUM_16, etc.) to hide the cryptic REP and SEP instructions, but the way the assembler itself knows to put the right length of operand in is what you put on the individual instruction line. For example, LDA #FOOBAR uses 16-bit, and LDA #<FOOBAR uses 8-bit. You could have a series of subroutines where ones is expected to be called in 16-bit mode and the next in 8-bit mode and the next again in 16-bit and so on, and you don't have to keep taking extra lines for LONGA, SHORTA, LONGA, etc.. It makes the source code more concise.

_________________
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  
PostPosted: Sat Dec 05, 2020 10:38 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
RichCini wrote:
If the code ever becomes publicly available, I would be happy to try to tinker with it. I'm assuming it's written in C/C++ rather than C# or something else.Rich


The code is available for version 1.2.15. (65C02 and 6502). It is posted here -> viewtopic.php?f=8&t=5011&start=45#p79528

I have not posted the version 1.3.x code yet, but I will once I get the 16MB memory range done (hint - I'm almost there)

Yes, this code is compiled using MS Visual Studio 2008 C++. I'll let you know when I post it.

Daryl

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


Last edited by 8BIT on Sat Dec 05, 2020 10:41 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 05, 2020 10:41 pm 
Offline
User avatar

Joined: Wed Sep 03, 2003 6:53 pm
Posts: 153
Location: Long Island, NY
8BIT wrote:
RichCini wrote:
If the code ever becomes publicly available, I would be happy to try to tinker with it. I'm assuming it's written in C/C++ rather than C# or something else.Rich


The code is available for version 1.2.15. (65C02 and 6502). It is posted a few pages up from here.

I have not posted the version 1.3.x code yet, but I will once I get the 16MB memory range done (hint - I'm almost there)

Yes, this code is compiled using MS Visual Studio 2008 C++. I'll let you know when I post it.

Daryl


Thanks Daryl. No rush of course. I have several versions of VS to work with. I'm working on getting my test code working...

Rich

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 413 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 28  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 13 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: