Re: intelligent disassembly

pete@xxxxxxxxxxxxxxxxxx writes:

In article <y93sl30e70f.fsf@xxxxxxxxxxxxxxxxxxxx>
ara@xxxxxxxxxxxxxxxxxxxx "Allan Adler" writes:
Thanks for the suggestions. Someone suggested to me that reading screen
memory is inherently flaky because video ram is more complex than ordinary
ram.

Really? It might be "slower", but I can't see how that makes it
"inherently flaky". I too would like enlightenment...

I'm still trying to inform myself about this. There have been different
kinds of chips used to implement video ram. Some, for example, are dual
ported, making it possible to read the chip at the same time one writes
to it. That doesn't sound like a convincing reason to me for it being
unreliable to simply read screen memory, but possibly another argument
is the fact that there is another int 13h function that will look at
a video ram location (maybe AH=7, I forget) and put the character in AH
and its attribute in AL. If one could simply and reliably read the video
ram, one could do essentially the same with a mov instruction and no
interrupt would be needed.

Once I'm able to read the upper memory, I can hopefully read the code
for interrupt 13h, AH=7 (?) and find out exactly how one can read
the video memory without using interrupts. But one thing at a time.

Anyway, the fact that this interrupt exists also shows that I should be
able to write a simple loop that will capture the screen and write it
to the floppy. Since you say you have been able to copy upper memory
using my program and yours, more or less, maybe you can tell whether the
screen, as depicted in the bytes starting with 0xb8000, really is
the way the screen looks.

Not that it proves a lot, but I wrote the C program I mentioned
and after some debugging/fixing got it to create a file of the
mem from a0000 to fffff OK (in the sense that it was the correct
size and the bits I checked against a DEBUG inspection tallied).
So in principle there is not a problem reading upper memory.

I'll make another effort to implement either djgpp on FREEDOS or to
implement the djgpp cross-compiler to DOS under Linux. I realize I
could just use your executable, but it would be better if I can also
make modifications in the program and compile them.

I also tried to use dsk_do_rw to capture the entire first megabyte of
memory by writing to sectors 1-16 of each of tracks 1-64 on side 0
and then again on side 1. That seemed to result in the destruction of
the floppy, but that doesn't necessarily mean that the program caused it.

Will the floppy not reformat? I can't believe that the media is
physically destroyed, so you might be able to find a util that
will rewrite the boot sector so that DOS FORMAT will recognise
it and allow a format. I don't know whether DISKCOPY would work
using another "good" floppy -- haven't tried it.

I haven't tried to reformat it and I haven't looked at the floppy under
FREEDOS yet. This isn't a problem with boot sectors. I wrote a C program
from Linux that wrote 2 x 18 x 80 x 512 consecutive 0's to /dev/fd0,
completely obliterating any structure that any operating system might
recognize. That was to clean the floppy so that whatever got copied by
my boot sector program would stand out clearly. My technique for reading
the floppy afterwards has been to use, from Linux,
dd if=/dev/fd0 of=flop bs=512
and this has worked consistently, until now. What happens now is that I
get an error message complaining that some sector is unreadable and aborting.
It is possible that this is just a bad sector and that dd doesn't know how
to deal with that. I'll ask about that on a Linux group. In any case, I
prefer to work with a perfect floppy, since there are already enough
variables to worry about in figuring out why my programs aren't working.

Anyway, I'm now fresh out of floppies and need to buy another box.

:-( It would be worth your while getting hold of a decent disk
sector editor, so that you can revitalize "dead" disks with a
shiny new boot sector copied from a good diskette.

I use a variant of the C program write.c from Krishnakumar's article,
"Writing your own Toy OS", to write the boot sector programs to the floppy.
But I could just as easily use dd to capture the boot sector of a good
diskette and they modify the C program to write that to the bad diskette.
But I think there probably is something wrong with the diskette.
dec bp ;does not affect the carry
jz dsk_io_exit
xor ax,ax ;reset disk controllers
int 0x13
popa
dec bp
jmp dsk_do_int13a

Let me ask you this: why is it necessary to reset the disk controller between
calls to dsk_do_rw?

Would you consider running
my program on your machine and tell me if you have similar problems?
You could either assemble it directly or include it in a C program.

I sort of did that, inasmuch as I too have a shortage of spare
floppies, so replaced dsk_do_rw with a routine that writes the
data to a previously opened file on a ramdisk. As you would
expect, this file was different from the one produced by the C
version but identical in the ROM areas. It proves at least that
reading memory is OK, so would conclude that the numbers in your
program are correct and that your problem must be in your int 13
writes or in dd's interpretation of what was written (or both!).
I suspect the latter, though.

I think dd is probably reading the diskette correctly. I don't know why
my program produced only FF's for upper memory, but it is conceivable that
it is wrong in a way that has side effects that affect the other reads
and writes.

Anyway, now that I have figured out other ways to do the screen capture
and to capture memory from 0xC0000 to 0xFFFFF and to write from the floppy
to the screen, I'll try again as soon as I have some more floppies to
destroy, which I expect will be today.

Incidentally, about 13 years ago, I was using a Sparc workstation that had
a floppy drive that could read floppies formatted for DOS. I used to use
it to copy files from my PC running Linux to and from the Sparc. When it
copied large files, say 800 kb or so, it used to destroy the diskette.
I thought there was something wrong with the floppy drive, but the sysadmin
looked into it and said it was a software problem. He declined to give details.
He just upgraded some software and the problem went away. But that suggests
that there might be some ways of writing diskette routines in assembly
language that can damage a floppy. That would be good to know about.

This is a text-only group so I can't post binaries here, and the
source listings are rather too long for something that is likely
of little interest to others, so if you'd like me to email them
to you just let me know.

Thanks, I'll keep it in mind. As long as I have some hope of getting
the bootsector programs to work, I prefer to do it that way. Also, it
will be better to install djgpp, both directly on FREEDOS and as a
cross compiler on Linux. Once I've gotten further with the bootsector
program, I'll probably start asking here about problems installing
djgpp.

PS. did you check the _entire_ contents of your original written
sectors on the floppy? The first 64K or so in my dump files were
entirely FF bytes (graphics video ram).

Yes. What I did, under Linux, was to execute
od -bc
on the file flop produced by dd, as described above. As long as the
lines produced by the octal dump are different, od will list them, but
when lines repeat, it doesn't list the repeats. For example, when I filled
the floppy with 0's and examined it with dd and od, it just showed one line
of 0's. One can figure out how many repetitions are involved from examining
line numbers. I also write a C program to examine the file flop and print
a message if it found a byte that was not 0.

In the case of dd and od with the original written sectors, it was visibly
all FF's for the written sectors and 0's for the others. But the experience
where the memory wrapped due to an error in incrementing the BX register
led to some reads that were not all FF's from lower memory.

Anyway, today I hope to get some more floppies and to write the new
versions of the programs that will hopefully sidestep and isolate the
problems I've been having up until now.
--
Ignorantly,
Allan Adler <ara@xxxxxxxxxxxxxxxxxxxx>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.
.

Relevant Pages

  • Re: intelligent disassembly
    ... memory is inherently flaky because video ram is more complex than ordinary ... So in principle there is not a problem reading upper memory. ... will rewrite the boot sector so that DOS FORMAT will recognise ...
    (comp.os.msdos.programmer)
  • Re: Cant fix random freeze/lockup problems
    ... Since you have the case open, remove the memory and then reseat the memory. ... load Windows and perform a Scandisk. ... for Scandisk opens up, Select both check boxes. ... Running scandisk will identify this sector ...
    (microsoft.public.windowsxp.general)
  • Re: Stumped
    ... worked fine except floppy would not transfer data. ... CPU used supported by board and BIOS? ... memory can present in a lot of different ways. ... removing battery and jumping pins. ...
    (alt.comp.periphs.mainboard.asus)
  • Re: Windows Assembly
    ... calling the kernel, and making one context switch, you call the kernel and it sends it to the other process, which is two context switches. ... All the kernel has to do is copy the memory from one processes address space to the other's, which isn't really any different then what has to be done when you send data to the kernel. ... video card backbuffer instead of using an intermediary system memory buffer. ... You can either write in just one format to a buffer and then have some function do the conversion at the end when writing to video ram, or you can make your line drawing or texture mapping functions have to deal with all of that. ...
    (alt.lang.asm)
  • Re: read data from a disk
    ... Interestingly, if I change the buffer size to 1000, nBytesRead is 0. ... Probably has to do with sector alignment and device-specific restrictions. ... synchronous operations of the memory manager. ... File access must be for numbers of bytes that are integer multiples of the ...
    (microsoft.public.vc.language)