This is a very simple question ! It has to do with a programming challenge where you had to write a virtual machine that is based on a segmented memory model with 16-byte segment size (notation seg:offset). We have also 2 segment registers (cs, ds)! The machine is initialized with cs=0x0 and ds =0x10
http://www.canyoucrackit.co.uk//15b436de1f9107f3778aad525e5d0b20.js
Questions:
1) Why ds = 0x10 (=16) ? Is this arbitrary for the specific virtual machine?
2) If cs=0 and ds = 16, then the data and code segments overlap to each other! How can code segment and data segment overlap?
3) Codes segment and data segment are fixed size (in this case 16-byte)! i thought that their size is dynamic! More generic: when we say "code segment" we mean that we have a dynamic size segment which can be further divided into fixed size small segments?
What am i missing here ??
Related
Assume I want to reserve 8 bytes on the stack and I also want to make sure current stack pointer is 8 byte aligned. I have seen some codes that assure current sp is 8 bye aligned using this logic:
sp = sp & -8;
They AND it with the amount they are going to reserve on the stack (which of course is negative).
How does this logic work?
It works because negative numbers are represented in two's complement, so -8 is equivalent to ~7, of which the 3 least significant bits are 0s and the rest are 1s. ANDing this with a value clears the 3 least significant bits, which obviously results in it being 8-byte aligned. By the way, this trick only works to align things to powers of 2. If you had some strange reason to align things to a 12-byte boundary, for example, sp = sp & -12 would not work as intended.
According to JPEG2000 specs, Number of tiles in X and Y directions is calculated by following formula:
numXtiles = (Xsiz − XTOsiz)/ XTsiz
&
numYtiles = (Ysiz − YTOsiz)/ YTsiz
But it is not mentioned about the range of numXtiles or numYtiles.
Can we have numXtiles=0 while numYtiles=250 (or any other value) ?
In short, no. You will always need at least one row and one column of tiles to place your image in the canvas.
In particular, the SIZ marker of the JPEG 2000 stream syntax does not directly define the number of tiles, but rather the size of each tile. Since the tile width and height are defined to be larger than 0 (see page 453 of "JPEG 2000 Image compression fundamentals, standards and practice", by David Taubman and Michael Marcellin), you will always have at least one tile.
That said, depending on the particular implementation that you are using, there may be a parameter numXtiles that you can set to 0 without crashing your program. In that case, the parameter is most likely being ignored or interpreted differently.
I am trying to accomplish something a bit backwards from everyone else. Given an array of sensor data, I wish to print a graph plot of it. My test bench uses a stepper motor to move the input shaft of a sensor, stop, get ADC value of sensor's voltage, repeat.
My current version 0.9 bench does not have a graphical output. The proper end solution will. Currently, I have 35 data points, and I'm looking to get 90 to 100. The results are simply stored in an int array. The index is linear, so it's not a complicated plot, but I'm having problems conceptualizing the plot from bottom-left to top-right to display to the operator. I figure on the TFT screen, I can literally translate an origin and then draw lines from point to point...
Worse, I want to also print out this to a thermal printer, so I'll need to translate this into a sub-384 pixel wide graph. I'm not too worried about the semantics of communicating the image to the printer, but how to convert the array to an image.
It gets better: I'm doing this on an Arduino Mega, so the libraries aren't very robust. At least it has a lot of RAM for the code. :/
Here's an example of when I take my data from the Arduino test and feed it into Excel. I'm not looking for color, but I'd like the graph to appear and this setup not be connected to a computer. Or the network. This is the ESC/POS printer, btw.
The algorithm for this took three main stages:
1) Translate the Y from top left to bottom left.
2) Break up the X into word:bit values.
3) Use Bresenham's algorithm to draw lines between the points. And then figure out how to make the line thicker.
For my exact case, the target bitmap is 384x384, so requires 19k of SRAM to store in memory. I had to ditch the "lame" Arduino Mega and upgrade to the ChipKIT uC32 to pull this off, 32k of RAM, 80 MHz cpu, & twice the I/O!
The way I figured out this was to base my logic on Adafruit's Thermal library for Arduino. In their examples, they include how to convert a 1-bit bitmap into a static array for printing. I used their GFX library to implement the setXY function as well as their GFX Bresenham's algorithm to draw lines between (X,Y)s using my setXY().
It all boiled down to the code in this function I wrote:
// *bitmap is global or class member pointer to byte array of size 384/8*384
// bytesPerRow is 384/8
void setXY(int x, int y) {
// integer divide by 8 (/8) because array size is byte or char
int xByte = x/8;
// modulus 8 (%8) to get the bit to set
uint8_t shifty = x%8;
// right shift because we start from the LEFT
int xVal = 0x80 >> shifty;
// inverts Y from bottom to start of array
int yRow = yMax - y;
// Get the actual byte in the array to manipulate
int offset = yRow*bytesPerRow + xByte;
// Use logical OR in case there is other data in the bitmap,
// such as a frame or a grid
*(bitmap+offset)|=xVal;
}
The big point is to remember with an array, we are starting at the top left of the bitmap, going right across the row, then down one Y row and repeating. The gotchya's are in translating the X into the word:bit combo. You've got to shift from the left (sort-of like translating the Y backwards). Another gotchya is one-off error in bookkeeping for the Y.
I put all of this in a class, which helped prevent me from making one big function to do it all and through better design made the implementation easier than I thought it would be.
Pic of the printout:
Write-up of the project is here.
I am having some issues with the TRichEdit.
The first issue is if I try to paste a lot of text from the clipboard into a empty TRichEdit, it truncates the bottom of the text.
The second issue, which I guess ties into the first issue, is that I seem to be limited to how many characters the TRichEdit can display, hence pasting from the clipboard is losing some of the data.
If I paste into a TJvRichEdit (Jedi), that works fine, obviously because that is a completely different component.
At this moment in time I would like a solution for the TRichEdit because I am using a lot of procedures/functions etc, if I change to a different Rich Edit class then I will have to edit a lot of my code to work.
So basically what I am asking is:
Is there a limit in the TRichEdit? which I am sure there is.
How can I increase the limit of the TRichEdit to accept more characters and lines etc.
Please provide advice/solution for TRichEdit only.
EDIT
never mind found the answer using:
RichEdit11.MaxLength := $7FFFFFF0;
Quoting an answer given by David Pate from the newsgroups:
The following remarks apply to the versions of Delphi that use the Windows Richedit version 1 control. I understand that this includes all Delphi versions prior to version 7. (I do not know what the situation is when you run programs compiled in these versions on the various NT/2000 versions of Windows although Windows XP behaves as described.)
Q. What is the limit to the amount of text that a Richedit can hold? A. The help files (Delphi help and Win32 SDK) are confusing, contradictory and incorrect on this point. There are 5 limits to be considered
The Maximum Capacity: the "hard-wired" limit, i.e the maximum size of the RichEdit's text buffer. It is 2 bytes less than 2 Gb. Note that this is the theoretical limit; in practice the limit will be determined by your computer's memory.
The Capacity: the actual size of the current buffer. By default, it is 64Kb but can be resized by several means.
The "Keyboard limit": the limit beyond which characters cannot be added by typing from the keyboard. It is often different from the Capacity but, like the Capacity, it is by default, 64Kb and can be resized by several means.
The MaxLength property of the tRichEdit object. The default of 0 sets both the Capacity and "Keyboard limit" to 64Kb.
The line-number limit: theoretically this is around 134 million, but in practice, you can expect to get much less than this. The maximum number of lines seems to depend on several factors including the amount of memory available and the average length of the lines. I find that I can get around 150 thousand to 200 thousand lines. Note also that it has been reported that some releases of the Windows 95 Richedit control sometimes throw an exception when more than a few hundred lines are added. This appears to be due to a bug in the control and to have been corrected in later releases..
Q. How can I increase the amount of text that a tRichEdit can hold?
A. When you add text programmatically, both the Capacity and the "Keyboard limit" are resized to accommodate the text being added. By adding text programmatically, I mean using any of the Add, Append, AddStrings or Assign methods of the tRichEdit.Lines property or the LoadFromFile, LoadFromStream or SetTextBuf methods of tRichEdit. Note that adding text in this way does not update the MaxLength property.
B. By using the MaxLength property. This sets the "Keyboard limit" to the value passed to MaxLength. It also increases the Capacity to match the "Keyboard limit" if the existing Capacity is less than MaxLength. Note that you cannot use MaxLength to reduce the Capacity and that changing MaxLength has no effect if the value passed is less than the length of the text currently in the control. To increase the Capacity and the "Keyboard limit" to the same value, set the tRichEdit.MaxLength to the desired value. To set the maximum size in the Object Inspector, use the value 2147483645 ($7FFFFFFD). To set it programmatically it is simpler to use .MaxLength := System.MaxInt-2;. The EM_LIMITTEXT and EM_EXLIMITTEXT messages may also be used to change the "Keyboard limit" and Capacity but I'd not normally recommend using them since, if you do, you will not be updating the MaxLength property.
Here's the steps to convert from section alignment to file alignment:
Find the RVA for the data
From the RVA, derive the section to which the data referenced belongs. This is trivial, since sections don’t overlap. The starting addresses of the various sections are available in the file header
Find the difference between the RVA and the starting address of the section to find the data offset, ie, offset of that data within a section.
From the file header, for the same section, find the location of the same section in the file.
Add the data offset to the location of section in the file, to find the address of the data in the file.
But I just don't understand that, can someone elaborate with more details?
Alignment is a rounded up value. Section data size is rounded up for effeciency because the OS moves stuff around in chunks anyway.
The File Alignment is usually 512 bytes which fit the blocksize of most filesystems.
The Section Alignment is usually 4096 bytes which fit the size of a memory page.
So if you have a PE-file with a section (like ".text") that contains 513 bytes of data:
Section .text will be rounded up to 1024 bytes on file.
Section .text will be rounded up to 4096 bytes in memory.
Note the amount of slack space possible both on file and in memory.
I'm unsure about why you want to "convert from one alignment to the other". The recipe you got there leaves the goal of the exercise as a mystery. If your goal is to manipulate PE-files then all you have to consider is the File Alignment. The Windows loader will handle the Section Alignment stuff when it throws it into memory, so you usually don't need to think about that at all.
You can read more about PE here.