1050 Posted December 12, 2017 Share Posted December 12, 2017 Microsoft Visual C++ Visual Studio 2017 X64 https://go.microsoft.com/fwlink/?LinkId=746572 x86 https://go.microsoft.com/fwlink/?LinkId=746571 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted December 12, 2017 Share Posted December 12, 2017 Hi Marco, I haven't received any positive or negative feedback so far. I think there still is a mismatch in the type encoding of the workspaces (ex. 1 = BYTE, 2, = WORD, ...), but I didn't have time to look yet. Regards, Peter. 1 Quote Link to comment Share on other sites More sharing options...
marcokitt2000 Posted December 13, 2017 Share Posted December 13, 2017 Hi Marco, I haven't received any positive or negative feedback so far. I think there still is a mismatch in the type encoding of the workspaces (ex. 1 = BYTE, 2, = WORD, ...), but I didn't have time to look yet. Regards, Peter. Hello Peter, Thanks for the info. Gr. Marco Quote Link to comment Share on other sites More sharing options...
+JAC! Posted January 3, 2018 Share Posted January 3, 2018 I think there still is a mismatch in the type encoding of the workspaces (ex. 1 = BYTE, 2, = WORD, ...), but I didn't have time to look yet. Implemented a unit test today and can say everything was fine in the version that I had posted. VOID DumpTest::TestDumpType() { assert(version_22::DUMP_TYPE_UNKNOWN == DUMP_TYPE_UNKNOWN); assert(version_22::DUMP_TYPE_LOBYTE == DUMP_TYPE_LOBYTE); assert(version_22::DUMP_TYPE_HIBYTE == DUMP_TYPE_HIBYTE); assert(version_22::DUMP_TYPE_BYTE == DUMP_TYPE_BYTE); assert(version_22::DUMP_TYPE_WORD == DUMP_TYPE_WORD); assert(version_22::DUMP_TYPE_LABEL == DUMP_TYPE_LABEL); assert(version_22::DUMP_TYPE_STRING == DUMP_TYPE_STRING); assert(version_22::DUMP_TYPE_SBYTE == DUMP_TYPE_SBYTE); assert(version_22::DUMP_TYPE_DLIST == DUMP_TYPE_DLIST); assert(version_22::DUMP_TYPE_STORE == DUMP_TYPE_STORE); assert(version_22::DUMP_TYPE_CODE == DUMP_TYPE_CODE); } Quote Link to comment Share on other sites More sharing options...
kenames99 Posted January 4, 2018 Share Posted January 4, 2018 (edited) hi JAC!, well, did not get too far. opened a file and selected a number of bytes that were supposed to be a string, right click and select cchange type of bytes selected to>string, then it goes to disassemble again - gets to pass 4 then crashes bringing up a "6502 Disassembler has stopped working" system dialog. working on windows 10 here. Ken PS: oh yea, 64bit Edited January 4, 2018 by kenames99 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted January 4, 2018 Share Posted January 4, 2018 hi JAC!, well, did not get too far. opened a file and selected a number of bytes that were supposed to be a string, right click and select cchange type of bytes selected to>string, then it goes to disassemble again - gets to pass 4 then crashes bringing up a "6502 Disassembler has stopped working" system dialog. working on windows 10 here. Ken PS: oh yea, 64bit Thanks Ken. Fixed with https://sourceforge.net/p/dis6502/git/ci/2c029b9c0eb2090a4e7fd733e909a945cd9e3b9e/ Download archive updated. Quote Link to comment Share on other sites More sharing options...
kenames99 Posted January 4, 2018 Share Posted January 4, 2018 hi JAC!, this one wont run, it seems to be a debug build without the needed debug dlls. first one it looks for is ucrtbased.dll Ken Quote Link to comment Share on other sites More sharing options...
+JAC! Posted January 4, 2018 Share Posted January 4, 2018 hi JAC!, this one wont run, it seems to be a debug build without the needed debug dlls. first one it looks for is ucrtbased.dll Ken I definitivly need to automate the build process to prevent such errors. Release build uploaded. This one already contains some additional refatorcing to get rid of the macros which contained the bug and are impossible to debug. Quote Link to comment Share on other sites More sharing options...
marcokitt2000 Posted January 4, 2018 Share Posted January 4, 2018 Hello Peter, I download it with this link http://www.wudsn.com/productions/windows/dis6502/dis6502.zipi saw it was updated get all so the error i have downloaded ucrtbased.dll and put in the map x86 and x64 but i get other error. I hope that you can fix it i love the program. Gr. Marco I had a productive time during my summer vacation and some at the Fujiama meeting two weeks ago. The new version is very beta but I need to get the build chain and packaging with the 32 / 64 -bit DLLs working and tested. This is important, because I am using a 64 bit machine for development, but the result should also run on Windows XP in 32 bit. http://www.wudsn.com/productions/windows/dis6502/dis6502.zip This beta is only for testing and should not be used productively. Only use it on copies of your existing workspaces, otherwise they may become corrupted!Beta.png The archive contains a x86 (32 bit) and x64 (64 bit) version. The dis6502.exe and related own DDLs are all 32 bit, only the runtime DLLs are different. The known issues are in the "dis6502.txt" file, please check there if your issue is already listed, before reporting it. I'm looking forward to your feedback. Quote Link to comment Share on other sites More sharing options...
kenames99 Posted January 4, 2018 Share Posted January 4, 2018 hi Jac! downloaded again but still get that same error trying to run it. sorry, not trying to be difficult but that is just the way things seem to go for me. Ken Quote Link to comment Share on other sites More sharing options...
+JAC! Posted January 4, 2018 Share Posted January 4, 2018 >ucrtbased.dll The d indicates the debug Build, but I definitively did the release build...aaargh. >still get that same error trying to run it. sorry, not trying to be difficult but that is just the way things seem to go for me No worries. I'm really happy for any kind of test. The difficulty with Windows programs is the DLL hell. In fact it is impossible to test a program on the machine where Visual Studio itself is installed. Unfortunately I do not have any additional clean machine. But I feel I do need one.... On my machine it works. So maybe you can provide the exact file and steps/offset where it fails. EDIT: Installed a dependency analyzer. It only shows the non-debug dependency. Quote Link to comment Share on other sites More sharing options...
kenames99 Posted January 4, 2018 Share Posted January 4, 2018 (edited) hi JAC!, I just try to open by doule click on DIS6502.exe in a file explorer window and it gives the system error dialog shown. the smaller clip is the actual list inside the exe that is looking for the debug dll, the "d" is wrapped to next line but definitely there. send me the exe you are running! hold on! checking it again. Edited January 4, 2018 by kenames99 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted January 4, 2018 Share Posted January 4, 2018 Grr, caching issue on my web server. Re-uploaded the actual release build. Quote Link to comment Share on other sites More sharing options...
kenames99 Posted January 4, 2018 Share Posted January 4, 2018 hey JAC!, I obviously tried to hop on to the new download to early cuz now it comes up ok, sorry for the confusion. "Patience, I must learn patience!" Ken Quote Link to comment Share on other sites More sharing options...
kenames99 Posted January 5, 2018 Share Posted January 5, 2018 not a deal breaker, but the mouse scrolling in dump window on the left is not working. otherwise, so far so good! Ken Quote Link to comment Share on other sites More sharing options...
SignGuy81 Posted January 5, 2018 Share Posted January 5, 2018 I'm pretty good myself(maybe not the best), but at times when I go to reassemble I wind up looking for screws that I've misplaced because it is usually days, if not weeks that go by from the time that I disassemble the Atari to the time I reassemble the Atari. Quote Link to comment Share on other sites More sharing options...
+JAC! Posted January 5, 2018 Share Posted January 5, 2018 not a deal breaker, but the mouse scrolling in dump window on the left Fix uploaded. The dump window contains a special control which handles mouse events directly instead of handling them on child window level. Quote Link to comment Share on other sites More sharing options...
dmsc Posted January 5, 2018 Share Posted January 5, 2018 Hi! >ucrtbased.dll The d indicates the debug Build, but I definitively did the release build...aaargh. >still get that same error trying to run it. sorry, not trying to be difficult but that is just the way things seem to go for me No worries. I'm really happy for any kind of test. The difficulty with Windows programs is the DLL hell. In fact it is impossible to test a program on the machine where Visual Studio itself is installed. Unfortunately I do not have any additional clean machine. But I feel I do need one.... You can use a testing VM (virtual machine), so you can easily test in a "clean" windows installation. The Windows VMs (from 7 to 10) are free to download from MS: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ As I use Linux here, I have one of these images to test my cross-compiled binaries. 1 Quote Link to comment Share on other sites More sharing options...
kenames99 Posted January 5, 2018 Share Posted January 5, 2018 hey JAC!, ok, found a deal breaker! the filename.asm and filename.inc both contain the same thing only differing amounts. a hex dump of filename.inc is 695 bytes of F8F7190D0A repeatedly. filename.asm contains 31,294 bytes of the same hex values as the .inc file but starts with a $38 then the F8F7190D0A over and over up to the file length. also, if I load a saved workspace I get nothing until I load the binary file again , tho I am not sure how a workspace is actually supposed to work. hope you understand this. feel free to email me direct at kenames@gmx.com if you need more or faster info. thanks. Ken Quote Link to comment Share on other sites More sharing options...
+JAC! Posted January 6, 2018 Share Posted January 6, 2018 bytes of F8F7190D0A repeatedly. filename.asm contains 31,294 bytes of the same hex values as the .inc file but starts with a $38 then the F8F7190D0A So now I can explain the difference between "fprintf" and "vfprintf" :-). Fixed. Also rearranged the Profile settings dialog. Added disabling of dependend fields in the dialog to make the dependencies clear. Example: if you do not select "Hex Notation", the input field for the Hex Prefix is now disbaled. Also fixed some bugs when loading/saving the fields new in 3.0 in the profile. Number of lines in the include files can now be set to "0" which means "Unlimited". 2 Quote Link to comment Share on other sites More sharing options...
kenames99 Posted January 6, 2018 Share Posted January 6, 2018 thanks JAC!, will test tomorrow/saturday. Ken Quote Link to comment Share on other sites More sharing options...
kenames99 Posted January 6, 2018 Share Posted January 6, 2018 hi JAC!. looks like it is saving proper now. on to loading and saving workspaces now. cuz if I load a saved workspace I get nothing until I load the binary file again. then I have 2 segments and 3 different disassembly listings in the right window pane. also when saving the disassembly listing I get those 3 listings also, but I think that will be okay once the workspace loading gets fixed. thanks. Ken Quote Link to comment Share on other sites More sharing options...
kenames99 Posted January 6, 2018 Share Posted January 6, 2018 (edited) ok, another thing, I am seeing the byte I click on in right pane is off by 2 in the left pane. same from left to right pane. alright, silly me, I did not read the dis6502.txt and this is already listed there. sorry. Edited January 14, 2018 by kenames99 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted January 20, 2018 Share Posted January 20, 2018 Segments and workspace refresh after loading fixed. Data structure for SegmentList completely changed. Requires less memory and now files with more than 2 segments finally benefit from all your GHz :-) Selection handling is still off though, but now I have a chance to find it at least. 7 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 20, 2018 Share Posted January 20, 2018 wow! 20 years changed in the blink of an eye! Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.