byte-to-pixel data display program?

Been that way in all x86 type machines,even the Tandy 1000 which had a strange video architecture. Not relevant. if need, program X reads from HD to RAM, program Y makes the picture.

Reply to
Robert Baer
Loading thread data ...

MAT I REPEAT: i said nothing about JPEG,in fact, i talked about BMP format which is byte-oriented, exactly what one gets from a HD; it is plain i do not give a G.D. about compression (which plainly does not exist in this case). Next you will be talking about tri-state logic stored in holograms.

Reply to
Robert Baer

  • Well,is or is not Parted Magic Linux/Linx-based? I used their erase facility (nice memorable icon) that gives a number of choices, first one is dd diskwipe and theysay it does the whole drive,and it takes about two hours for my 500Gb HD. BTW, the whole drive was one partition if one cares... What do you think is "independent"? A different OS like Win7, or truly independent by busting the HD and optically look at the bit pattern?
  • Start with a brand new HD. Put a Partition Sector on it, label it and "format" it. Note right here that formatting is NOT done, just one byte is written in the Partition Sector. Since there are no tools to format the 500Mb drive partition,try option one: DOS FDISK, FORMAT /S/U and find you have only 2GB and the rest is not accessible. So go to option 2, clone a 500MB RAM stick that has data to the HD. Result in Windows (any OS including Win7) is not acceptable,so do a dd diskwipe and find that plainly does nothing to the data. Still there. But Computer Management flips it to all zero.
  • Gee, a 500MB cache of exactly the same data, hiding under the hood; not believable for a second.
Reply to
Robert Baer

Interesting...Looks like it may be yet another way to NOT diskwipe. Remember Norton's Ghost from daze long ago? Same failure, same lie. Then tried Parted Magic erase option internal diskwipe. Get a wonderful nasty message that drive security state was set as frozen. Maybe that is the lie maker. Even so, how the heck does the data switch between empty unallocated to Paladin have data will travel? Oh yes, i can change that data at will; just a few files to a bunch. Only Everything shows all of the original hundreds of GB originally cloned.

Reply to
Robert Baer

char b[0x200000]; int h=open('/dev/hda'); while(read(h,b,0x200000)>0){

// bytes-to-pixels code here

}

that stuff is piss-easy on linux.

--
This email has not been checked by half-arsed antivirus software
Reply to
Jasen Betts

photorec

--
This email has not been checked by half-arsed antivirus software
Reply to
Jasen Betts

if you're going to ignore error checking, it takes 3 lines in C too.

--
This email has not been checked by half-arsed antivirus software
Reply to
Jasen Betts

runs on anything reasonably modern, but the above code is for some unix variant. some windows advocate told me that the same sort of thing can be done on windows.if you know the right filename for the raw disk device.

--
This email has not been checked by half-arsed antivirus software
Reply to
Jasen Betts

Probably!

Creating a 32 bit executable that runs fine on XP/2k should be possible...

Reply to
bitrex

Then you have nothing to prove that dd did NOT do exactly as it was told!

E.g., this command: dd if=/dev/rawdiskdevice of=/dev/rawdiskdevice will spend "an hour and a half" *refreshing* the data that is already present on the disk. The disk's contents will NOT change!

And, this command: dd if=/dev/zero of=/dev/wrongdiskdevice will spend "some amount of time" (depends on the capacity and access speed of the "wrongdiskdevice") to also leave the rawdiskdevice intact.

Have you considered: dd of=/dev/zero if=/dev/rawdiskdevice

Finally: dd if=/dev/zero of=/dev/null will spend "forever" doing nothing (because the destination is an infinite sink!)

Are you sure that you are able to write to the "correct" device?

I.e., you claim to see files, there. Can you *delete* a file from the operating system prompt? Can you *create* a file from the prompt?

If not, then the operating system is preventing writes to the medium. Expecting dd to work if the OS isn't following through is not the fault of dd!

Are you sure you haven't installed one of the SCSI ID straps on the write protect jumper for the drive?

Have you invoked the HBA's diagnostics on the selected medium? Some include the ability to test the medium for defects, etc.

Reply to
Don Y

Exactly. He doesn't trust the program to recognize "non-zeroes".

Or, use a program that will display the contents of ANY FILE in ANY FORM (e.g., as hex/octal/ASCII characters) and pipe that through a $PAGER (so you don't see 50GB of data zoom by in an instant!)

Gee, sure would be nice if such programs existed!! :>

Reply to
Don Y

I guess the one thing you can

Reply to
bitrex

Disregard...

Reply to
bitrex

Don't waste your time on all that amateur nonsense. Go with what the real pros use for their most intimate secrets: BleachBit.

Reply to
krw

Robert, lI used to do this kind of thing, like with the CoCo and CP/M using the 6845 CRT controller in the Z80 system...

Nowadays, us mere mortals cannot obtain the data sheets (if they exist) for the new-ish graphics controllers. I would imagine you might be able to still do what you are wanting to do if we had that documentation. I have a feeling there is even still a 6845 compatible mode but I have no idea how to invoke that or address its memory.

I think that Linux is probably our best bet these days because they have reverse engineered these new graphics controllers and cards I believe.

I would love to have more information !

boB

Reply to
boB K7IQ

Ye Olde IBM PC-compatible modes never went away, on any BIOS-based hardware that still claims to support said standard. They're all accessible in the usual way: BIOS interrupt calls. SVGA's pretty standard too (VESA 3.0 compatible), though accessing large frame buffers in real mode is a pain (like EMS, you get a selectable window into the frame buffer).

Doesn't mean you can do that in a modern OS, or should want to do it that way, of course... :-)

(FYI, most programming languages provide an indexed graphics mode of arbitrary size, shape, colors, etc. It's easy to write up something like this in Java, for example. Though not the low level HD access... you'd need that provided as an open file, or hooked on a native blob.)

Tim

--
Seven Transistor Labs, LLC 
Electrical Engineering Consultation and Contract Design 
 Click to see the full signature
Reply to
Tim Williams

The environment for that would be DOS. Nice flat security model. The frame buffer is highly likely to be mapped for you. The resolution is low and fixed. You will need to find a website with DOS-era information. Maybe MinGW would be good enough to compile. And you have Extended Int 0x13 calls for hard disk reads (no driver needed).

*******

An example of the "perfect application", is memtest86+. It is a standalone application you can boot the computer with. No OS at all. Source is available. Even the floppy diskette it sat on, did not have a file system, so you could not "list" the floppy to prove it was present. I actually changed three lines of code on it at one time, and wrote some additional information to the screen. So I was able to compile and build it, but I don't remember the details at all. That was back in the era of my Nforce2 motherboard and AthlonXP processor.

formatting link

formatting link

So that's not even MSDOS. It's "nothing", just a single program right on the iron. It's just you and the CPU, and a straight stretch of road.

*******

These suggestions are for the "classic car" buffs, who like to be close to the metal and hate actual GUIs.

Paul

Reply to
Paul

Thanks. Good stuff to know !

Back in the late 1980s I was writing some DOS software to display FFTs etc (in 86 assembly using MASM and DOS calls) and not long ago I ran across the backups and wondered if they would still work. I found a DOS emulator

formatting link
that works OK but not perfect. At least I saw some dots on the screen again and my little low-tech ascii menu.

Computers seemed so much more exciting way back then and in the 1970s when it wasn't so common place.

I'd still like to know the low level registes and mappings of the newer graphics cards. Not exactly sure what I'd do with it though ?

boB

Reply to
boB K7IQ

That is because most graphics accelerators sit in their own local high bandwidth memory address space. You have to send stuff across or send how to draw it instructions to the graphics accelerator. Things have moved on a long way since the grotty IBM CGA and Hercules cards.

That is probably your simplest solution. Make a 256 indexed BMP header with dimensions that match your physical screen and then tack onto the end of it the right number of bytes from your hard disk. Paint the BMP to the screen or write it to a .BMP file and open in a viewer and bingo!

There is an example program in the free MSVC examples Vista? that could be subverted to do this or you could use .Net from scratch.

formatting link

--
Regards, 
Martin Brown
Reply to
Martin Brown

Do not know how to do that.

Reply to
Robert Baer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.