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.
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.
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.
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.
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
photorec
-- This email has not been checked by half-arsed antivirus software
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
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
Probably!
Creating a 32 bit executable that runs fine on XP/2k should be possible...
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.
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!! :>
I guess the one thing you can
Disregard...
Don't waste your time on all that amateur nonsense. Go with what the real pros use for their most intimate secrets: BleachBit.
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
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
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.
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
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
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
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.
-- Regards, Martin Brown
Do not know how to do that.
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.