bode plot readyBut it lacks hardware support, right? This needs signal generator, which the DHO800 don't have, if I understand correctly.
how about trying to understand how to build a java (or any machine code such as exe) decompiler inside out?
Now we are getting into real "hacking" territory.
How about trying to understand how to build a scope inside out?
Now we are getting into real "hacking" territory.
How about trying to understand how to build a scope inside out?
how about trying to understand how to build a java (or any machine code such as exe) compiler and decompiler inside out? along the way you know the format and how OS make entry to the executables allocate RAM etc etc... i think if you guru enough in this, you should be able to insert additional machine codes with correct offset, and correction too on all existing call offsets? this is what i really loved to do on exe but never got the chance and time, i'm just enjoying developing my own app.. and i feel i'm getting older, not enough timetoo many responsibilities and hobbies. ymmv.
ADC is capable to make 2 Gsa/s. Dont know how is with FPGA, but we should try to do at least 1.5.
I found how to remove an LA I don’t need from the bottom panel and, after digging deeper into the code, I figured out how to enable the date and time display
But this method is very slow and inconvenient
madman
But this method is very slow and inconvenientthe problem is when new FW update is released, are you patient enough to redo all the hardwork again? maybe building an automating app can help significantly? just an idea ymmv. cheers.
achievement like this is already great, if its only involves flipping a constant bit/byte without changing code size/structure/logic. but even greater if it involved adding more codes into the compiled apk.. it might not be easy, you probably need access to android/java documentation on how to assemble into a machine/OS readable format, by paying professional fee... i dont know this android SDK/assembler stuffs.. maybe you need to investigate rat/grey/black/illegit route, just an ideaso ymmv.
# virtual methods
.method public draw(Landroid/graphics/Canvas;)V
.locals 16
move-object/from16 v0, p0
.line 85
iget-object v1, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
iget v1, v1, Landroid/graphics/Rect;->right:I
iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
iget v2, v2, Landroid/graphics/Rect;->right:I
iget v3, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mTopWidth:I
# changed
# const/16 v3, 120
# sub-int/2addr v2, v3
# sub-int/2addr v1, v2
.line 87
iget v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->currentState:I
if-eqz v2, :cond_1
const/4 v3, 0x1
if-eq v2, v3, :cond_0
goto/16 :goto_0
.line 92
:cond_0
iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
iget v2, v2, Landroid/graphics/Rect;->left:I
int-to-float v5, v2
const/4 v6, 0x0
int-to-float v7, v1
iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
iget v2, v2, Landroid/graphics/Rect;->bottom:I
int-to-float v8, v2
iget v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mRadius:I
add-int/lit8 v4, v2, 0x1
int-to-float v9, v4
# const/high16 v9, 0x3f000000 # 0.5f
add-int/2addr v2, v3
int-to-float v10, v2
# const/high16 v10, 0x3f000000 # 0.5f
iget-object v11, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->selectedPaint:Landroid/graphics/Paint;
move-object/from16 v4, p1
invoke-virtual/range {v4 .. v11}, Landroid/graphics/Canvas;->drawRoundRect(FFFFFFLandroid/graphics/Paint;)V
.line 96
iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
iget v2, v2, Landroid/graphics/Rect;->left:I
You can change it as you like, when you reassemble it, it will be compiled into the correct “executable” Java file with all the changes made.the problem is when new FW update is released, are you patient enough to redo all the hardwork again? maybe building an automating app can help significantly? just an idea ymmv. cheers.
Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.
Any chance you can get the info boxes for CH1..4 to display the probe divider setting? Only possible if the information is available to the display routine, I guess.
The decompiled source codes of DALVIK allow you to add/remove/change anything you like. These are not machine codes in an executable file, where you need to take care not to break the structure of the file, where it is impossible to insert something, or replace it with something larger. No, here are the source codes in a programming language, just a very low-level one
Here is an example of a piece of such source code:
Here is an example of a piece of such source code:Code: [Select]...
You can change it as you like, when you reassemble it, it will be compiled into the correct “executable” Java file with all the changes made.
Although I read a lot of reviews on the Internet that it was almost impossible to build a working application from decompiled Java source codes, there was still a little hope. However, no, life is cruel and there was no surprise. You will have to dig into the Java assembler as before to make any changes to the application logic
Something like that, right?)
Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.I assure you that changing the binary firmware of such an FPGA is several orders of magnitude more difficult than any port of the Linux kernelPerhaps this can be compared to completely rewriting the entire kernel from scratch. Moreover, initially without having any source codes for this kernel, only a compiled kernel and a disassembler
Is there no decompiler for Android which generates Java source code instead of bytecode assembly?
For plain .class and .jar files, there seem to exist a couple of decompilers.
Is there no decompiler for Android which generates Java source code instead of bytecode assembly?
For plain .class and .jar files, there seem to exist a couple of decompilers.
those codes look somehow readable and editable.. so then why your statement above is contradicting with your statement below?
great job! rigol should hire you
I did already an email to Rigol for source codes just for kernel and U-boot used on this scope - currently they didnt reply. Maybe they do tomorrow?
Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.I assure you that changing the binary firmware of such an FPGA is several orders of magnitude more difficult than any port of the Linux kernelPerhaps this can be compared to completely rewriting the entire kernel from scratch. Moreover, initially without having any source codes for this kernel, only a compiled kernel and a disassembler
I did already an email to Rigol for source codes just for kernel and U-boot used on this scope - currently they didnt reply. Maybe they do tomorrow?
BufferedImage createWheelBuffer(int radius) {
final int diameter = radius * 2;
final double radius2 = radius * radius;
float hue, sat;
final double PI2 = 2 * Math.PI;
double dist2;
int rgb;
BufferedImage buffer = new BufferedImage(diameter, diameter, BufferedImage.TYPE_INT_ARGB);
for (int x = 0; x < diameter; x++) {
for (int y = 0; y < diameter; y++) {
dist2 = distance2(x, y, radius, radius);
// if the point is not inside the circle we go to the next point
if (dist2 > radius2) continue;
hue = (float) (Math.atan2(y - radius, x - radius) / PI2);
sat = (float) Math.sqrt((float) dist2) / (float) radius;
rgb = Color.HSBtoRGB(hue, sat, 1);
buffer.setRGB(x, y, rgb);
}
}
return buffer;
}
int distance2(int x1, int y1, int x2, int y2) {
int a = x2 - x1;
int b = y2 - y1;
return a * a + b * b;
}
And in the paintComponent event:
protected void paintComponent(Graphics gr) {
super.paintComponent(gr);
Graphics2D g = (Graphics2D) gr;
BufferedImage buffer = createWheelBuffer(radius);
g.drawImage(buffer, x, y, this);
}
ADC is capable to make 2 Gsa/s. Dont know how is with FPGA, but we should try to do at least 1.5.
Yes, there is, but the decompilation process is imperfect; there are many errors and strange designs that need to be corrected in order to be able to compile a working application from these sources. When the application is small, with a couple of dozen source code files, this is not so scary. But when the application is huge, consisting of several thousand source code files, then fixing all the decompiler errors becomes unrealistic.
Decompiled Java sources can be used for information in order to better understand what is happening in the corresponding files with DALVIK. That's all.
As a side note, I am working on adding a color box to the Channel widget, in the color box you can enter RGB value to change the color of the channel. I thought about color picker wheel too. My work has been slow comared to others here, I just too busy with other priorities.
As a side note, I am working on adding a color box to the Channel widget, in the color box you can enter RGB value to change the color of the channel. I thought about color picker wheel too. My work has been slow comared to others here, I just too busy with other priorities.
Have you already found in the source code how to set the color of the channel trace?
Yes, there is, but the decompilation process is imperfect; there are many errors and strange designs that need to be corrected in order to be able to compile a working application from these sources. When the application is small, with a couple of dozen source code files, this is not so scary. But when the application is huge, consisting of several thousand source code files, then fixing all the decompiler errors becomes unrealistic.
Decompiled Java sources can be used for information in order to better understand what is happening in the corresponding files with DALVIK. That's all.
Is is possible to just decompile individual classes? Surely that would make it much more manageable.
The majority of the code in these is C++ though. From the poking around I did it seemed like Java is only used for UI, everything else is in a huge .so file (12Mb IIRC).