Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user ZiKE! ! (Registered 2022-01-27) You are not logged in 
CSDb User Forums

Forums > CSDb Entries > Release id #212693 : JC64dis 1.7
2022-01-02 18:53

Registered: Aug 2003
Posts: 63
Release id #212693 : JC64dis 1.7

Out of curiosity, I gave this disassembler a go on my own compiled code. As I know what each area in memory contains, it was easy to concentrate on just learning the usage of the disassembler itself.

A few things I noticed along the way:

1) When removing automatically generated labels, they do disappear when re-disassembling, but on the next disassembly they always come back, unless there are no references to the label left. However, I have an unrolled STA table for filling segments of a colram buffer. When loading the program, this buffer area is filled with the default colour, i.e. the area contains only dummy data. This data area is filled with labels, to which the STA statements refer to, and I can't remove the references and the labels. Is there a way to do it somehow? So instead of

STA W1234,x
.byte $07

force the disassembler to use the address directly, i.e.
STA $1234,x

2) As an exception to the above, removing some labels DOES seem to take effect. This is what the beginning of my buffer looks like now:
      .byte $07, $07, $07, $07, $07, $07, $07, $07 
      .byte $07, $07, $07, $07, $07, $07, $07, $07 
      .byte $07, $07, $07, $07, $07, $07, $07, $07 
      .byte $07, $07, $07, $07, $07, $07, $07, $07 
      .byte $07, $07, $07, $07, $07, $07, $07 
      .byte $07
      .byte $00
      .byte $00

So as removing some labels which are used exactly the same works and some doesn't, is this a bug?

3) When removing automatic comments, instead of actually removing them, the disassembler adds a blank user comment which seems to override the automatic one. I suppose this works, but isn't very clean IMHO. Is there a way to simply remove the automatic comment instead?

4) Adding user comments to word data lines doesn't work.

5) Setting a mem area as specific type of data doesn't work from the toolbar. Same goes for marking a cell as constant. They both do work fine from the "Memory" menu though.

Despite a few niggles, I was able to successfully disassemble the program back to Kickass source, and it compiles and runs fine too. :) Thanks for the great tool!
... 1 post hidden. Click here to view all posts....
2022-01-03 03:37

Registered: Aug 2003
Posts: 63
Don't know if this answer even for 2, usaully if you have a buffer a way is to define location as + reference of the initial block, example

LDA #$33
STA W1234
LDA #$22
STA W1235
LDA #$11
STA W1236

.byte $00
.byte $00
.byte $00

will become:

LDA #$33
STA Buffer
LDA #$22
STA Buffer+1
LDA #$11
STA Buffer+2

.byte $00, $00, $00

Instead, if what you get in point 2 is not the above example I need to see the memory state for look if it is a bug.

I guess this could work, I need to give it a go. Thanks for the tip!

This is strange. Did you see the sub-menu in toolbar that opens and can select the kind, or not?
Actually what I see that not works is the shorcut keys (need to redefine them too)

Submenu pops up when I hover over the toolbar button, but I can't select anything from it. I do get this NPE in terminal when I move on to hover over the submenu:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at java.desktop/com.apple.laf.AquaMenuPainter.paintSelectedMenuItemBackground(AquaM enuPainter.java:157)
	at java.desktop/com.apple.laf.AquaMenuItemUI.paintBackground(AquaMenuItemUI.java:13 0)
	at java.desktop/com.apple.laf.AquaMenuPainter.paintMenuItem(AquaMenuPainter.java:18 6)
	at java.desktop/com.apple.laf.AquaMenuItemUI.paintMenuItem(AquaMenuItemUI.java:103) 
	at java.desktop/javax.swing.plaf.basic.BasicMenuItemUI.paint(BasicMenuItemUI.java:6 24)
	at java.desktop/com.apple.laf.AquaMenuItemUI.update(AquaMenuItemUI.java:119)
	at java.desktop/javax.swing.JComponent.paintComponent(JComponent.java:797)
	at java.desktop/javax.swing.JComponent.paint(JComponent.java:1074)
	at java.desktop/javax.swing.JComponent.paintToOffscreen(JComponent.java:5255)
	at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBufferedImpl(Rep aintManager.java:1643)
	at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Repaint Manager.java:1618)
	at java.desktop/javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1 556)
	at java.desktop/javax.swing.RepaintManager.paint(RepaintManager.java:1323)
	at java.desktop/javax.swing.JComponent._paintImmediately(JComponent.java:5203)
	at java.desktop/javax.swing.JComponent.paintImmediately(JComponent.java:5013)
	at java.desktop/javax.swing.RepaintManager$4.run(RepaintManager.java:865)
	at java.desktop/javax.swing.RepaintManager$4.run(RepaintManager.java:848)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) 
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPr ivilege(ProtectionDomain.java:85)
	at java.desktop/javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:84 8)
	at java.desktop/javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:82 3)
	at java.desktop/javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java :772)
	at java.desktop/javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.ja va:1884)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) 
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPr ivilege(ProtectionDomain.java:85)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchTh read.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThrea d.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchTh read.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:10 9)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:10 1)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Java version or flavour incompatibility / mismatch, perhaps? Which version are you using? I'm on

java 13.0.2 2020-01-14
Java(TM) SE Runtime Environment (build 13.0.2+8)
Java HotSpot(TM) 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing)
2022-01-03 08:20

Registered: Apr 2002
Posts: 50
The binary needs at least java 8.
Tested with java 8, 11 and 17

Please, try to change the Look & Feel in Option and see if this happen with the other mode or not.

It seems related to MacOs Acqua look and feel even if the default theme set by the program is Metal
2022-01-03 14:00

Registered: Aug 2003
Posts: 63
I tried all other looks too (java, Metal with different themes, Nimbus, a few Synth based looks) but the exception remains. It's not a biggie though, I can always select the specific data type from the Memory menu.

I've also noticed a couple other issues:

1) There's some kind of a memory leak. After a few hours of use the heap is pretty much full (I believe it went up to 4 gigs) and then the program gets very slow, for example double clicking on a mem address to jump to that area in preview takes several seconds, disassembly and assembly are much slower etc. They do slow down gradually before the heap completely filling up as well.

2) The load, save and close buttons in Options are, excluding the lowest few pixel rows, behind the content pane until I hover over where they should be. Even when they become visible in front of the pane, I can only click on the narrow strip that is located under the pane. I suspect this has to do with the window size: My screen's resolution is only 1440x900 and thus not all options fit on the screen at once and thus the pane has a scroll bar. Maybe the buttons are not correctly attached to the pane?
2022-01-03 14:33

Registered: Aug 2003
Posts: 63
Another small issue: Instruction and data separators can be changed to tabs, but for comment separators 25 spaces is the minimum, can't change those to zero to use only tabs like with the instruction and data separators. Again not a big issue, I just prefer tabs for indentation.
2022-01-03 14:46

Registered: Apr 2002
Posts: 50
The unique point that I did not manage directly is the syntax highlight library, so it should be it that did not release object in time.
However I will profile a session to see what takes so much memory.
The delay is when Java starts the garbage collection and release memory. I wil lactivate that by clicking into the heap graph it force a garbace collectiona action.

I will decrease the min height size in next version, now you can move the windows using meta+click or alt+click on the border and move it up
2022-01-03 14:51

Registered: Apr 2002
Posts: 50
Quote: Another small issue: Instruction and data separators can be changed to tabs, but for comment separators 25 spaces is the minimum, can't change those to zero to use only tabs like with the instruction and data separators. Again not a big issue, I just prefer tabs for indentation.

Yes, comment has 25 min spaces. I probably can modify to go to 0 if there are some tabs. Need to test
2022-01-04 11:15

Registered: Apr 2002
Posts: 50
You can test some modification from here:

This Jar has all the libraries inside, so no more need of lib directory.

I have replaced all libraries,so test it for the memory problem and the theme problem (maybe if that issue is due to a library bug, it could be resolved).

You can test the option dialog size too.

By click onto the heap view should request a garbace collection (it is not mandatory that JVM accept it).

Else, comments on word, long, ecc is done.
Add clear automatic comments (for data area now an erase is true erase)
2022-01-06 20:11

Registered: Aug 2003
Posts: 63
Sorry for the delay, real life is distracting me from things that really matter. :)

Heap seems to creep up just by keeping clicking on disassembly, and only some of the heap is eventually freed up again. When I'm at 4 gigs, GC does get more aggressive and pushes the usage down to around 3 gigs, but not sure if the heap would be filled completely in some cases. I guess this'd become apparent only after several hours of normal use.

Clicking on the heap view doesn't do anything, although AFAIK it's not possible to force a GC in java anyway, one can just give a gentle suggestion to the JVM to maybe prioritise memory related tasks if it feels like it (which it often doesn't).

Submenus from the toolbar still don't work and throw the same NPE.

Option dialog is now working fine: Load, Save and Close buttons are accessible under the content pane in the options.

Clearing automatic comments now happens on data (a true erase rather than an empty user comment like you mentioned), but on code, can't clear the auto-comments at all now. I can only manually add a user comment to override the automatic one.
2022-01-08 14:14

Registered: Apr 2002
Posts: 50
Try the new build on previous link.

The click on the heap was not invocated correctly.
Now it calls garbace collector (it is a way that even if it is only suggested, it is actually invoked).

From my profiling I only view that memory is free after a garbage collector without leaks.
However I modify some heavy part of the core to reuse the objects instead of creating a new one.

This should help.

By compiling there memory increase as there are the undo function to store previous state and then all inside the preview and source are recreated from scratch.

However if you still reach 4GB, try the GC click and see if it goes down. If memory after goes down only of 1GB this is still strange.

ps. the spaces for comment can be reduced to only 1
2022-01-11 17:34

Registered: Aug 2003
Posts: 63
Gave this another quick test: Kept clicking on the "Disassemble" button until mem usage was up to 4 gigs, and then clicked on the heap view. Triggering the GC now works, and it takes memory usage down to around 2.3gigs. In more real life usage (e.g. a several hours long disassembly session) the behaviour may be different though.
Previous - 1 | 2 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
Ze Smasher/F4CG
Guests online: 33
Top Demos
1 Edge of Disgrace  (9.6)
2 Comaland 100%  (9.6)
3 Coma Light 13  (9.6)
4 Bromance  (9.6)
5 Uncensored  (9.6)
6 Memento Mori  (9.5)
7 Lunatico  (9.5)
8 Unboxed  (9.5)
9 Wonderland XII  (9.5)
10 Christmas Megademo  (9.5)
Top onefile Demos
1 Copper Booze  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Dawnfall V1.1  (9.5)
4 Cityscape 2730  (9.5)
5 Lovecats  (9.5)
6 Square Booze  (9.5)
7 To Norah  (9.5)
8 Elite Code Mechanics  (9.4)
9 Barry Boomer - Trapp..  (9.4)
10 For Your Sprites Only  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Oxyron  (9.3)
3 Crest  (9.3)
4 Fossil  (9.3)
5 Performers  (9.3)
Top Webmasters
1 Slaygon  (9.6)
2 Perff  (9.6)
3 Morpheus  (9.6)
4 Sabbi  (9.4)
5 CreaMD  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2022
Page generated in: 0.055 sec.