Image Map Image Map
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: DOS memory inspector?

  1. #11
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,489
    Blog Entries
    18

    Default

    Quote Originally Posted by Agent Orange View Post
    Could be Chuck, but not everyone has your talents.
    Call them mental deficiencies. I might have otherwise been a media personality like the Kardashians.

  2. #12

    Default

    Quote Originally Posted by Agent Orange View Post
    Could be Chuck, but not everyone has your talents.
    Tom, that is a major understatement.
    PM me if you're looking for 3" or 5" floppy disks. EMail For everything else, Take Another Step

  3. #13
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,082
    Blog Entries
    1

    Default

    Quote Originally Posted by Twospruces View Post
    I didn't know about debug. Thanks, I 'll try that first, as I want to be able to look at a range of memory. Basically I am debugging XUB on a machine that may use memory differently than XUB assumes. cheers
    DEBUG is a good thing to learn anyway because every single system with 64K or more RAM can run it, and most DOS systems come with it. It's cumbersome, but perfectly functional for inspection tasks -- just have a hex calculator handy (or be good at hex math in your head).

    Here's a quick'n'dirty tutorial by the author of DEBUGX: ftp://ftp.oldskool.org/pub/ANORMAL%2...ojta/DEBUG.TXT
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  4. #14
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,489
    Blog Entries
    18

    Default

    "just have a hex calculator handy (or be good at hex math in your head)."

    For much stuff, the "h" command will do:

    Code:
    >debug
    -h 1234 5678
    68AC BBBC

  5. #15
    Join Date
    Jan 2005
    Location
    Principality of Xeon (NJ)
    Posts
    1,346

    Default

    If you're only inspecting memory, it doesn't mean you know assembler. You could be looking to up yout stats in some old dos game for instance. Works to a point. It worked for one level of 2400ad which I played for a short while. But tried it on a different level, and I was immediately incinerated despite my efforts and talents. And yes I did know basic assembler at that point, but that's besides the point.

    Imho, and I'll proclaim to this to my grave, the best text for assembler/masm is Peter Abel's IBM Assembler Language and Programming 1st ed., or same title but uses "Assembly", which is the 2nd. ed. Just stick with it, take notes (I used a tape recorder, transcribed them on paper later on), and you'll be enlightened. I tried other books, the Tandy 2000 MASM manual, which someone gave me, bless their black little hearts, really just confused me. There may be other good texts, but I cannot see any doing a better job. I started reading this:

    https://www.ebay.com/itm/IBM-PC-and-...-/142093719493

    and all I can say is the initial section on binary and hex seemed to answer any question a newcomer might have.

  6. #16

    Default

    Developed a lot of machine code for model 100, but I am not up to speed yet on 8088 and DOS and the tools. I am working my way through how XUB is supposed to work. The code is well documented. It is so close to being functional in Zenith Z-171 The drives dont detect in the expected way, and there is some instability when XUB is installed. DEBUG worked right away for me. I can clearly see XUB at C800h and I can just as easily look at interrupts. CMOS ram is a different story though.. will need a tool for that I believe. I have the tools installed in my desktop now and can compile XUB but I have not yet attempted to install in z-171 a binary that I compiled. Maybe tomorrow.

  7. #17

    Default

    I would recommend using the enhanced DEBUG that I worked on in its later versions instead of the stock DEBUG which comes with DOS. It supports CPUs up to the Pentium Pro, has more commands (e.g. DW to display words, DD to display doublewords, DM to display the DOS memory chain) and uses less memory than most versions of DOS DEBUG. For example to display the INT 13h vector in a more readable format you can type: DD 0:4C L4

    https://sites.google.com/site/pcdosretro/enhdebug
    Last edited by pcdosretro; October 17th, 2019 at 09:03 PM.

  8. #18
    Join Date
    Jan 2005
    Location
    Principality of Xeon (NJ)
    Posts
    1,346

    Default

    Didn't Norton have a utility for memory viewing.

  9. Default

    Thanks pcdosretro ; downloaded the enhanced debug ; will try later.

    One problem with the standard debug is it won't run on 64-bit systems. I've used the dos 6.20 version for various things: patching 16-bit programs, and examining memory and program flow. Lately it's more likely to be used to adjust a few bytes in a file now and then.

  10. #20

    Default

    Quote Originally Posted by Robbbert View Post
    Thanks pcdosretro ; downloaded the enhanced debug ; will try later.

    One problem with the standard debug is it won't run on 64-bit systems. I've used the dos 6.20 version for various things: patching 16-bit programs, and examining memory and program flow. Lately it's more likely to be used to adjust a few bytes in a file now and then.
    No 16-bit DOS program will run in 64-bit long mode since v86 mode isn't available in long mode. You need a PC emulator or an old PC. Heck many newer PCs don't even support UEFI BIOS compatibility mode (CSM) and ones that do often aren't compatible enough to boot DOS so dual booting is generally no longer an option.

    To modify files use a Windows hex editor like HxD - https://mh-nexus.de/en/hxd/

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •