Disclaimer: I'm pretty new to this whole calculator programming thing, and have no idea what I'm doing when it comes to how the memory of these calculators are structured. However, I made this program on a whim and I think it turned out kind of cool, though I have no idea what the results mean.


Code:
[i]MEMORY
Begin
0->PAGE
Repeat X=320 or getKey(15)
   SetColor(*{PAGE*76800+(240*X+Y)})
   SetPixel(X,Y)
   Y+1->Y
   If Y>239
      0->Y
      X+1->X
   End
End
Pause
det(1)


The result is the first 76800 bytes of the memory written to the screen according to the default palette. Since a byte has 256 possible values just as the palette does, this works pretty well. You can change the PAGE variable to display different 76800-byte pages of the calculator's memory starting from the first byte. Here are the first 3 pages together:



Like I said, I'm not sure what I'm looking at here, but I thought it was pretty cool, and was kind of surprised when it wasn't just random.
Did you know that you can do this quickly and easily using the CEmu tool "Debug > Add Memory Visualizer"?
MateoConLechuga wrote:
Did you know that you can do this quickly and easily using the CEmu tool "Debug > Add Memory Visualizer"?

Yep, I just realized that. Razz
It would be interesting to connect the patterns you see with what the actual memory stores (I guess that's why there is an option in CEmu to see it). For instance, why is it white for that one section (approximately byte 85,000 to byte 110,000)?
dankcalculatorbro wrote:
It would be interesting to connect the patterns you see with what the actual memory stores (I guess that's why there is an option in CEmu to see it). For instance, why is it white for that one section (approximately byte 85,000 to byte 110,000)?

That's exactly what I was wondering. Those bytes have values of 255 (the maximum value), or 11111111 in binary, but I have no idea why.
It's 255 because that's the value flash erases to. They have two bootcodes; one which handles the interrupt vectoring and then the other is the jump table vectors. They just hardcoded the difference between the two because it's easier.

dankcalculatorbro wrote:
I guess that's why there is an option in CEmu to see it

It's also because let's say you are using double buffering for instance and want to see what the back buffer is rendering.
Alright seems cool. But why does it seem to line up in vertical stripes? Are the routines really all ~320 in length or is it just a coincidence?
_iPhoenix_ wrote:
Alright seems cool. But why does it seem to line up in vertical stripes? Are the routines really all ~320 in length or is it just a coincidence?

No it's because the person who wrote the program inverted x and y.
MateoConLechuga wrote:
_iPhoenix_ wrote:
Alright seems cool. But why does it seem to line up in vertical stripes? Are the routines really all ~320 in length or is it just a coincidence?

No it's because the person who wrote the program inverted x and y.

Yeah, that's kind of just how I wrote it. The values are displayed top to bottom and left to right.

MateoConLechuga wrote:
It's 255 because that's the value flash erases to. They have two bootcodes; one which handles the interrupt vectoring and then the other is the jump table vectors. They just hardcoded the difference between the two because it's easier.

Cool!
Pi_Runner The image of your memory dump reminded me of an image I used on my iPad. The image size was 1000x1000 pixels. It wasn’t a dump of memory or anything like that, but a dictionary file. Each pixel of the image contained 3 characters, giving a total size of 3 million characters. Those 3 million characters resulted in 300,249 words. At the time, it was easier for the program to use the image then to use a 3 million character text file. The program would read each pixel and extract the 3 characters. It would combine those characters until it reached a separator and then put that word into a table. The full table (300,249 entries) could be read in less than a second. It was interesting to do different processing on all those words. For instance, the count by letter, the count by word size, how many words were palendrones, etc. Plus it could be used in a hangman type game.

dave1707 wrote:
Pi_Runner The image of your memory dump reminded me of an image I used on my iPad. The image size was 1000x1000 pixels. It wasn’t a dump of memory or anything like that, but a dictionary file. Each pixel of the image contained 3 characters, giving a total size of 3 million characters. Those 3 million characters resulted in 300,249 words. At the time, it was easier for the program to use the image then to use a 3 million character text file. The program would read each pixel and extract the 3 characters. It would combine those characters until it reached a separator and then put that word into a table. The full table (300,249 entries) could be read in less than a second. It was interesting to do different processing on all those words. For instance, the count by letter, the count by word size, how many words were palendrones, etc. Plus it could be used in a hangman type game.

That's really cool! It's interesting that that would be more efficient than a text file. That would be a really sneaky way to hide secret messages as well. Wink
Pi_Runner I guess you could hide a message in a picture. You could put a character every 50 pixels or whatever so that the image wouldn’t be changed that much. You could just post the picture and make a comment about it but someone could read the image for the secret message. It’s not that the image was more efficient than the text file. At the time the app I was using couldn’t read text files. That came a few releases later and now I do use a text file.
You can also replace, say, the least significant bit of each color per pixel, which means that there would be no discolored spots. The process of hiding data in plain sight in images (among other things) is called steganography, which I would link to the Wikipedia page for if I wasn't on mobile.
commandblockguy wrote:
You can also replace, say, the least significant bit of each color per pixel, which means that there would be no discolored spots. The process of hiding data in plain sight in images (among other things) is called steganography, which I would link to the Wikipedia page for if I wasn't on mobile.

https://en.wikipedia.org/wiki/Steganography
I guess that would be a better way of doing it. You’re correct that the image wouldn’t change that much either. I’ll have to look up steganography.
I went to the link above and it’s interesting that they show how they hid a second image inside of another image.
Steganography has been used in some internet challenges like Cicada. There is more information abouit it here.

When I saw this post this it reminded me of one of the ways core dumps were displayed.

Quote:
If that sounds painful, consider the Whirlwind computer developed at MIT around 1951 (pictured below). When this 2kB, 0.04mHz behemoth crashed, it would simply display the entire contents of memory as a string of octal numbers on a dedicated CRT screen. Then, an automated camera would take a picture of this CRT on microfilm1. You, the programmer, would get the developed microfilm the next morning and display it on a projector, which would be your crash debugger. Operand highlighting was done with a brightly colored marker on the film transparency, and the disassembler was a guy you called on the phone to ask what instruction 0125715 meant. At least the dump files themselves were small — about 35 millimeters, more or less.
I like that this is one of the rare problems where writing it in asm actually makes it simpler Laughing

Code:
 ld hl,0
 ld de,vRam
 ld bc,153600
 ldir
 ret
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
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 vote in polls in this forum

 

Advertisement