Re: new disassembler vs IDA (was Re: 8085 Dissasembly?)
> On Apr 19, 2018, at 9:19 AM, Eric Smith via cctalk > wrote: > > For the 1802, I've used a really crude disassembler written in C. The 1802 > instruction set isn't very complicated, so a disassembler for it isn't > either. It's been so many years since I actually disassembled 1802 code > that I'm not sure I still have the disassembler around. Well, you're welcome to use dismantler on CDP1802 code! :) -- Mark J. Blair, NF6X http://www.nf6x.net/
new disassembler vs IDA (was Re: 8085 Dissasembly?)
On Wed, Apr 18, 2018 at 8:17 PM, Mark J. Blair via cctech < cct...@classiccmp.org> wrote: > Some of the future reverse engineering projects I have on my to-do list > involve the CDP1802 processor, which IDA presently doesn't support. When I > get to them I'll have to decide whether to use dismantler vs. learning how > to add CDP1802 support to IDA. I'm leaning towards the latter, because IDA > is so much fancier than dismantler is. I'd vote for adding it to dismantler. I had an IDA Pro license at one point, but I seem to have misplaced it, and it is too old to get me any discount on a new release. I imagine that IDA has probably improved a lot since back then, but at the time it had a pretty awful user interface. If I had an actual business need to reverse-engineer something using a processor that IDA supported, I'd certainly buy a new IDA license, but I wouldn't personally invest any time in building add-ons for expensive commercial software, when there are open source alternatives that may not be as good, but are generally good enough. For the 1802, I've used a really crude disassembler written in C. The 1802 instruction set isn't very complicated, so a disassembler for it isn't either. It's been so many years since I actually disassembled 1802 code that I'm not sure I still have the disassembler around.
Re: 8085 Dissasembly?
On 19 April 2018 at 17:37, Liam Proven wrote: > > I don't know when a word stops being new, but that one is a good 35 years old: > > https://en.wikipedia.org/wiki/Heisenbug (But saying that, I like it, too. Even as a rookie programmer around the time it was defined, in my trivial programs, I'd seen them.) -- Liam Proven • Profile: https://about.me/liamproven Email: lpro...@cix.co.uk • Google Mail/Hangouts/Plus: lpro...@gmail.com Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: 8085 Dissasembly?
On 19 April 2018 at 13:27, Noel Chiappa via cctalk wrote: > > From: Charles Anthony > > > discovered that changing the executable would change the behavior -- a > > heisenbug. > > Ooh, love that neologism. I don't know when a word stops being new, but that one is a good 35 years old: https://en.wikipedia.org/wiki/Heisenbug -- Liam Proven • Profile: https://about.me/liamproven Email: lpro...@cix.co.uk • Google Mail/Hangouts/Plus: lpro...@gmail.com Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: Int 13h buffer 64k boundaries (was: 8085 Dissasembly?
On Wed, Apr 18, 2018 at 9:20 PM, Fred Cisin via cctalk < cctalk@classiccmp.org> wrote: > >>> > You certainly did the right thing, narrowing it down to load address. The > final conclusion would have been to systematically try many/all load > addresses, and see whether it was consistent for given ones, and what the > failing ones had in common. > > I was coming from a DEC environment (VMS, RT-11/ RSTS) -- produce a repeatable demonstration of a error and send it off; a few weeks later a fix appears. MS's failure to respond confirmed my suspicions; they were a commodity software company. (That is a perfectly valid business model, but staking your own business success on them their behavior is a real risk.0 > > > I was not invited to be in the 3.11, nor WIN95, Betas. > They wanted cheerleaders, not testers, anyway. > We received the SDK for the very first Windows. We looked at it and laughed and laughed. You can still see the design flaw in today's Windows. Much later, having fled the MS ecosystem, I was working on a SGI application. Attended a MS seminar for the first NT release -- it featured OpenGL support and they wanted all of the SGI developers to migrate. I spend an entire day listening to them telling my how wonderful NT was. What I learned could have been covered in three minutes: * OpenGL support was a port of the reference driver, slow and buggy. Hardware manufacturers would provide "real" OpenGL drivers. Of course, they would focus on the gaming market, not data visualization, so the chances of a usable implementation was low, plus the cost of losing customers who made a poor hardware selection based on the manufacturer's claim that they are OpenGL compliant. It is possible to write an OpenGL compliant driver for a light bulb; it is no guarantee that you will be able to do data visualization. * Despite the fact that (as I have heard quoted, but cannot give a citation) 80% of an application is UI, there was no support for X11 semantics, so we would have to rewrite all of that code for the [patently broken] Windows semantics. We did not migrate, and I still waiting for MS to apologize for wasting a day of my time with their delusions of grandeur. -- Charles
Re: 8085 Dissasembly?
> From: Charles Anthony > discovered that changing the executable would change the behavior -- a > heisenbug. Ooh, love that neologism. Noel
Re: 8085 Dissasembly?
> On Apr 18, 2018, at 2:50 AM, Torfinn Ingolfsen via cctech > wrote: > > Since it has not been mentioned yet: NF6X's dismantler supports the > 8085 (and a couple of other CPUs): https://github.com/NF6X/dismantler > It is written in Python, so it should run on any platform where Python > is available. From the description "semiautomatic code recognition" > and "allows binary files to be disassembled from the command line". My main motivation for writing dismantler was that I was intrigued by recursive-descent disassemblers such as IDA (which I had seen in use in videos, blog posts and presentations), but didn't want to pay for IDA at the time. I've recently purchased IDA Starter, so I may not use my own disassembler any more for future reverse engineering projects. Dismantler is a pale shadow of IDA, but it's still a big improvement over the simple disassemblers I've used in previous reverse engineering projects. Some of the future reverse engineering projects I have on my to-do list involve the CDP1802 processor, which IDA presently doesn't support. When I get to them I'll have to decide whether to use dismantler vs. learning how to add CDP1802 support to IDA. I'm leaning towards the latter, because IDA is so much fancier than dismantler is. -- Mark J. Blair, NF6X http://www.nf6x.net/
Int 13h buffer 64k boundaries (was: 8085 Dissasembly?
I always found it amusing that many programs (even FORMAT!) would fail with the wrong error message if their internal DMA buffers happened to straddle a 64K block boundary. THAT was a direct result of failure to adequately integrate, or at least ERROR-CHECK!, the segment-offset kludge bag. Different device drivers and TSRs could affect at 16 byte intervals where the segment of a program ended up loading. It was NOT hard to normalize the Segment:Offset address and MOVE the buffer to another location if it happened to be straddling. On Wed, 18 Apr 2018, Charles Anthony wrote: Huh. I would guess that this is the source of a DOS bug that I found back in the day, reported to MS, and never heard back. . . . A buffer boundary straddling error certainly sounds like the issue I was seeing; it feels very odd to see a plausible explanation 35 years later. I'm learning a lot these days that would have been handy back then! Segment:Offset hides it until you normalize the resulting address. IIRC, INT13h should return a code of 09h if the DMA straddles a 64K boundary. But, not all code checks for that, or knows what to do when it happens. Looking at the value of ES:BX? can work, or, if it happens, swap your DMA buffer with one that is not used for DMA (and doesn't happen to be 64K away :-) In my code, I happened to have buffers for several purposes, so that was easy to do. If operating above Int 13H (DOS calls), then you are dependent on DOS error checking. "Can you trust THAT?" If operating below Int 13h, then be careful where your DMA ends up, work without DMA, or simply watch for occurrence. And, of course, a lot of C code can't tell the difference between end of file and a disk error. #define EOF (-1)/* depending on implementation */ while ((ptr2++ = fgetc(fp2)) != EOF); /* does not differentiate between error and end of file */ fgets() returns a null pointer for EITHER end-of-file OR error! and therefore assumes total reliability and any failure to read is assumed to be EOF. IFF available, feof(fp2) is much better. You certainly did the right thing, narrowing it down to load address. The final conclusion would have been to systematically try many/all load addresses, and see whether it was consistent for given ones, and what the failing ones had in common. Yes, the "solution" for the extraneous FORMAT failure was "add or remove TSRs and device drivers"! When I first hit it, I used a P.O.S.T. card, and put in minimal code to output values until I realized that DS was the key, and that I had mishandled error #9. Eventually I realized that even for code not my own, I needed to write a TSR intercepting Int 13H calls. (For exampole, the critical error handler in certain early versions of PC-Tools was more concerned with protecting their pretty display than success of writes!) Microsoft's response to error reporting was amusing. I was in the Windows 3.10 Beta, and encountered the SMARTDRV write caching problem. There was apparently a flaw on one of my drives, that neither SPINRITE nor SSTOR could find. But, during Windoze installation, a write would fail, and with write caching ON (Windoze installation did NOT give you a choice), there was no way to recover from a write error! (SMARTDRV had already told SETUP that it had been successful, so now, when the error occured, there was no way to (I)gnore the error (figure out which file copy had failed, rename the failed copy "BADSECS", and go back later to copy that one manually). All you could do was (R)etry which didn't work, or (A)bort, which cancelled the entire setup before it ever wrote the directory entries for the files that had worked. By loading a bunch of space filler files on the disk, I was able to get the installation to be in a working area. Once I finally determined WHERE the bad track was, I put in a filler file to keep it from being used. (SPINRITE tried to return it to use when I just marked it as BAD!) Microsoft's response was, "YOU have a HARDWARE problem. NOT OUR PROBLEM." I was unable to either convince them that CORRECT response to a hardware problem was a responsibility of the OS, NOR that SMARTDRV with write-caching was going to cause a lot of data losses that they would get blamed for, inspite of it not be narrowed down to SMARTDRV, and that it would end up costing them a lot. Sho'nuff, COMPRESSION got blamed for the data losses. DOS 6.2x had to be put out for FREE to fix "the problems with compression". The "problems with compression" were fixed by having SMARTDRV NOT default to write caching ON, have SMARTDRV NOT rearrange writes for efficiency (it wasn't writing DIRectory sectors until later), and having SMARTDRV NOT returning a DOS prompt until its buffers were emptied. (One of the common losses was people would save a file, and turn off the computer as soon as the word processor came back to the DOS prompt. SMARTDRV had not finished writing their file! When my g
Re: 8085 Dissasembly?
On Tue, Apr 17, 2018 at 1:49 PM, Fred Cisin via cctalk < cctalk@classiccmp.org> wrote: > >>> > I always found it amusing that many programs (even FORMAT!) would fail > with the wrong error message if their internal DMA buffers happened to > straddle a 64K block boundary. THAT was a direct result of failure to > adequately integrate, or at least ERROR-CHECK!, the segment-offset kludge > bag. Different device drivers and TSRs could affect at 16 byte intervals > where the segment of a program ended up loading. > It was NOT hard to normalize the Segment:Offset address and MOVE the > buffer to another location if it happened to be straddling. > > Huh. I would guess that this is the source of a DOS bug that I found back in the day, reported to MS, and never heard back. Working on a large application, ground out a new release, got a call from the production (the guy that ran the floppy duplicator) that his quality control tests were failing -- the application on the floppies wouldn't start. I grabbed one, it ran on my machine ok, wouldn't run on production's test machine. Confiscated that machine and started swapping out hardware, nothing helped. Tried adding tracing code to the application to see if I could narrow down the failure point, but discovered that changing the executable would change the behavior -- a heisenbug. Eventually worked that the crash was related to the address that the executable was loaded at, which was dependent on the various TSRs that were loaded -- with the production test machine driver configuration, the load address would reliably crash the application. If I adjusted the load address to match on my machine, I would get the same crash. To figure out what the crash was about, I ended up writing a small TSR that set the "break on every instruction bit", and would push the PC and opcode out the serial port, and collected the data streams for the crashing and non-crashing configurations. Diffed the data streams to find where they were diverging. The application was large enough to have overlays -- as the program was starting up, an overlay with run-once initialization code would be read from disk and jumped into; in the crash configuration, the overlay code seemed not to be being read, or read incorrectly -- the first opcode in the overlay was wrong. Wrote a simple program that read a data file of the same size as the overlay into different locations in memory and verified that the data was read, demonstrating that DOS was failing for one buffer address but not another, documented it, and send it off to MS and told management that the bug was MS and there really wasn't anything we could do. Never heard back from them, and have actively avoided MS software ever since. A buffer boundary straddling error certainly sounds like the issue I was seeing; it feels very odd to see a plausible explanation 35 years later. -- Charles
Re: 8085 Dissasembly?
For the simulator part, perhaps GNUSim8085 can be used: https://gnusim8085.github.io/ Again, I have no personal experience with it (yet). HTH -- Regards, Torfinn Ingolfsen
Re: 8085 Dissasembly?
On Mon, Apr 16, 2018 at 9:01 PM, W2HX via cctech wrote: > Hi friends. I have a 1990's vintage commercial radio system that uses an > 80C85A CPU. I am looking to hopefully modify the firmware to make some small > changes in its behavior. The firmware is contained in two EPROMS. > > > Can anyone recommend a decent disassembler to use with this? Preferably > something that ran in windows 10 or windows 7? A dos box would be fine too. > > Since it has not been mentioned yet: NF6X's dismantler supports the 8085 (and a couple of other CPUs): https://github.com/NF6X/dismantler It is written in Python, so it should run on any platform where Python is available. From the description "semiautomatic code recognition" and "allows binary files to be disassembled from the command line". Note: I haven't used it yet, so I have no personal experience of whether it is good or not. HTH -- Regards, Torfinn Ingolfsen
Re: 8085 Dissasembly?
On 17/04/2018 14:25, Warner Losh via cctalk wrote: On Tue, Apr 17, 2018 at 7:12 PM, Johnny Eriksson via cctalk < cctalk@classiccmp.org> wrote: Bill Gunshannon wrote: Many of us think that the advent of the x86 architecture is what led to masochism. ... or masochism led to the x86 architecture. I think you are confused maybe. Wasn't it sadism? Never attribute to malice that which is adequately explained by stupidity. -- Pete Pete Turnbull
Re: 8085 Dissasembly?
OTOH, Micropro had 8080 originated Wordstar running on the 5150 in weeks. It took them longer to edit the manuals than to port the code. Likewise Supercalc, etc. On Tue, 17 Apr 2018, Warner Losh wrote: Part of that too was because MS-DOS provided CP/M programming interfaces, so in many ways it was CP/M with a bag on the side... Certainly. But, Q-DOS didn't have much of a bag. It was mostly a rewritten copy of CP/M with a different data structure for disk directory. LATER, starting with MS-DOS 2.00, there was a major bag of sub-directories and "unix style" file handling (file handles V File-Control-Block) And much later, for "long filenames" (Win95), MICROS~1 used a kludge bag, keeping the old 8.3 Directory structure and using "excess" directory entries for storage of the long nicknames. HINT: do NOT use "long filenames" for anything in the root directory. WINDOWS itself started as a bag hanging off of the side. Originally, MS-DOS clearly documented what was needed for a replacement command processor. (Was it 2.11? or 3.00? when IBM removed the appendix from the PC-DOS manual, and started marketing it as "PC-DOS Technical Reference Manual" (still with "appendix" page numbering)) I always found it amusing that many programs (even FORMAT!) would fail with the wrong error message if their internal DMA buffers happened to straddle a 64K block boundary. THAT was a direct result of failure to adequately integrate, or at least ERROR-CHECK!, the segment-offset kludge bag. Different device drivers and TSRs could affect at 16 byte intervals where the segment of a program ended up loading. It was NOT hard to normalize the Segment:Offset address and MOVE the buffer to another location if it happened to be straddling. -- Grumpy Ol' Fred ci...@xenosoft.com
Re: 8085 Dissasembly?
On Tue, Apr 17, 2018 at 2:14 PM, Fred Cisin via cctalk < cctalk@classiccmp.org> wrote: > On Tue, 17 Apr 2018, allison via cctalk wrote: > >> Looked at 8086 and decided it was a 8080 with a bag on the side. >> It was and still is irrational. >> > > OTOH, Micropro had 8080 originated Wordstar running on the 5150 in weeks. > It took them longer to edit the manuals than to port the code. > Likewise Supercalc, etc. > Part of that too was because MS-DOS provided CP/M programming interfaces, so in many ways it was CP/M with a bag on the side... Warner
Re: 8085 Dissasembly?
On Tue, 17 Apr 2018, allison via cctalk wrote: Looked at 8086 and decided it was a 8080 with a bag on the side. It was and still is irrational. In the days of assembly language and hand edited machine code, An 8080 with a bag on the side made it extremely quick and easy to port legacy (8080) code. An 80286 can run almost all 8086 code without further modifications. Each generation of the intel processors was easy to adopt with legacy code. LATER, the code can be rewritten to take advantage of new "features". The alternative, to start from scratch and design it correctly, means that instead of porting legacy code, everything needs to be written from scratch. For example, in the 68000, you have a processor that is NOT hampered by being a 6800/6809 with a bag on the side. And it took a while before commercial applications were ready. Consider spreadsheets on the Mac. Good ones became available, but it took a while. OTOH, Micropro had 8080 originated Wordstar running on the 5150 in weeks. It took them longer to edit the manuals than to port the code. Likewise Supercalc, etc. There are trade-offs between redesign with integrated features to do it right, VS add-on kludge bags to have maximum compatability. These days, with most stuff written in compiled high-level languages, it becomes "merely" developing the new compiler. 'course the result of compiled high-level language is not comparable to assembly/machine coding. It requires "Moore's Law" to compensate for the slower final result. -- Grumpy Ol' Fred ci...@xenosoft.com
Re: 8085 Dissasembly?
On Tue, Apr 17, 2018 at 12:46 PM, Eric Smith via cctalk < cctalk@classiccmp.org> wrote: > On Tue, Apr 17, 2018 at 9:12 AM, allison via cctalk > > wrote: > > > Looked at 8086 and decided it was a 8080 with a bag on the side. > > It was and still is irrational. > > > > With the 386 architecture (32-bit), they actually cleaned it up quite a > bit. I won't go nearly so far as to say that 386 is elegant, but when > running in 32-bit mode with flat addressing it's nowhere near as awful as > 16-bit 8086 and 286. AMD did a pretty good job of further extending that > to 64-bit. However, it does keep accumulating ever more bags on the side. > Disassembly still isn't 'simple' or 'easy' on x86 as it is on other RISC since the instruction stream can start/stop anywhere. MIPS and Sparc, for example, are both are word based. > I hope RISC-V eventually drives a stake through it. > I have hopes that my 11-year-old son will never have to deal with the horrors that are x86 when he's my age... Maybe it will be gone by then :) Warner
Re: 8085 Dissasembly?
On 04/17/2018 02:21 PM, Chuck Guzis via cctalk wrote: > How many started coding for a machine writing machine code? > > I recall that the IBM 1620 SPS coding forms had two sides--one for > coding assembly (SPS); the other labeled "IBM 1620 Absolute Coding > System". Basically a form with the first 5 positions reserved for the > address, 2 positions for the opcode and 5 positions each for the P and Q > addresses. > > You could enter the code from the form right into the console typewriter > or punch it on a keypunch. If you were a real hard-case, you didn't > bother with coding forms, you sat down at the typewriter and did > everything from memory, mentally keeping track of storage addresses and > what referenced them. > > Do this for a while and disassembly is easy. After all, you'll have all > of the instructions and their opcodes committed to memory. > > I believe that I can still do this for 8080 code, in spite of my > deteriorating wetware. > Well, the first programming I learned was Autocoder on the IBM 1401. Our instructor gave us a simple project (80/80 Print). Had us write it in Autocoder and verify that it worked. Then we had to optimize it to reduce it to fit on a single punched card. That was done by tweaking the machine code output by the Autocoder "compiler". I still have mine around here somewhere. bill
Re: 8085 Dissasembly?
On Tue, Apr 17, 2018 at 9:12 AM, allison via cctalk wrote: > Looked at 8086 and decided it was a 8080 with a bag on the side. > It was and still is irrational. > With the 386 architecture (32-bit), they actually cleaned it up quite a bit. I won't go nearly so far as to say that 386 is elegant, but when running in 32-bit mode with flat addressing it's nowhere near as awful as 16-bit 8086 and 286. AMD did a pretty good job of further extending that to 64-bit. However, it does keep accumulating ever more bags on the side. I hope RISC-V eventually drives a stake through it.
Re: 8085 Dissasembly?
On Tue, Apr 17, 2018 at 11:06 AM, Richard Sheppard via cctalk wrote: >> Lastly, I wonder if there might be some kind of checksum check to prevent >> tampering. Is there a common way this is handled in 8085 world? Or is it >> entirely programmer dependent? > > One approach that be doable for you is if you have a good ROM with a > known checksum, make your changes then calculate the difference between the > new and the original checksum and make another change somewhere innocuous to > bring the checksum back to the original value. "Innocuous" may be the trick - > perhaps some text string you don't care about, copyright notice etc. or maybe > there is an empty area in the EPROM you could stick a byte. > > Richard Sheppard A while ago someone asked about dumping contents of the firmware EPROMs from a DECserver 200 where the pair of EPROMs were soldered in place. I used a method of doing that which didn't require desoldering the EPROMs to read them on a device programmer. I wanted to verify the correctness of what I managed to dump and by disassembling and inspecting sections of the firmware I found that the firmware was running a standard CRC32 checksum on itself during its initialization. I was able to run the CRC32 algorithm on what I dumped and verified that it match the checksum that was stored in the EPROM data, and that was sufficient to convince myself that the dump was correct. But the interesting part of all of that is when I looked further at the disassembled firmware it appeared that after it calculated the CRC32 checksum and compared it against the expected result, it completely ignored whether or not the checksum actually matched the expected result. Seemed odd. Later I acquired another DECserver 200 with the same firmware version in socketed EPROMs. Just for curiosity sometime I should try altering the checksum and verify that it really doesn't matter.
Re: 8085 Dissasembly?
How many started coding for a machine writing machine code? I recall that the IBM 1620 SPS coding forms had two sides--one for coding assembly (SPS); the other labeled "IBM 1620 Absolute Coding System". Basically a form with the first 5 positions reserved for the address, 2 positions for the opcode and 5 positions each for the P and Q addresses. You could enter the code from the form right into the console typewriter or punch it on a keypunch. If you were a real hard-case, you didn't bother with coding forms, you sat down at the typewriter and did everything from memory, mentally keeping track of storage addresses and what referenced them. Do this for a while and disassembly is easy. After all, you'll have all of the instructions and their opcodes committed to memory. I believe that I can still do this for 8080 code, in spite of my deteriorating wetware. --Chuck
Re: 8085 Dissasembly?
> Lastly, I wonder if there might be some kind of checksum check to prevent > tampering. Is there a common way this is handled in 8085 world? Or is it > entirely programmer dependent? One approach that be doable for you is if you have a good ROM with a known checksum, make your changes then calculate the difference between the new and the original checksum and make another change somewhere innocuous to bring the checksum back to the original value. "Innocuous" may be the trick - perhaps some text string you don't care about, copyright notice etc. or maybe there is an empty area in the EPROM you could stick a byte. Richard Sheppard
Re: 8085 Dissasembly?
On Tue, Apr 17, 2018 at 8:31 AM, Tapley, Mark via cctalk < cctalk@classiccmp.org> wrote: > On Apr 17, 2018, at 8:25 AM, Warner Losh via cctalk > wrote: > > > On Tue, Apr 17, 2018 at 7:12 PM, Johnny Eriksson via cctalk < > > cctalk@classiccmp.org> wrote: > > > >> Bill Gunshannon wrote: > >> > >>> Many of us think that the advent of the x86 architecture is what led to > >>> masochism. > >> > >> ... or masochism led to the x86 architecture. > >> > > > > I think you are confused maybe. Wasn't it sadism? > > > > Warner > > …? weren’t we talking about disasm? Maybe you got spell-checked, Warner? > I think I have a name for the disassembler I coincidentally am working on for the Venix stuff :) Warner
Re: 8085 Dissasembly?
On 04/17/2018 11:07 AM, Brian L. Stuart via cctalk wrote: > On Tue, 4/17/18, Eric Smith via cctalk wrote: >> On Mon, Apr 16, 2018 at 7:29 PM, Chuck Guzis via cctalk >> wrote: >>> Disassembly is never lots of fun, >> Some of us might disagree. >> But then, some of us might be masochists. > I was just thinking the same thing. This whole discussion > has taken me back to fond memories of writing a 68000 > disassembler in AWK (long story). > > While I never had to write a disassembler I have written quite a bit of assembler code and have done a number of disassemblies. (Still do once in a while but most of what I do today is for fun.) My first was PDP-11 followed by Z-80\8080, M68K and M6809. I have even done some VAX. I have worked with x86, not from scratch but maintenance. Of all of them the last was the worst and I would never do it for fun. Oh, I forgot one. Sparc. bill
Re: 8085 Dissasembly?
On 04/17/2018 10:59 AM, Bill Gunshannon via cctalk wrote: > > On 04/17/2018 09:25 AM, Warner Losh via cctalk wrote: >> On Tue, Apr 17, 2018 at 7:12 PM, Johnny Eriksson via cctalk < >> cctalk@classiccmp.org> wrote: >> >>> Bill Gunshannon wrote: >>> Many of us think that the advent of the x86 architecture is what led to masochism. >>> ... or masochism led to the x86 architecture. >>> >> I think you are confused maybe. Wasn't it sadism? >> >> > Sadism on Intel's part but masochism on the part of those who willingly > accepted it. > Not sure where that leaves the rest of us. Linux on ARM or NETBSD on VAX... in recovery, or maybe PDP-8 or PDP 11? The old RCA CDP1802 keeps dragging me back. I seriously stopped messing with intel with 8080/8085 jumping to Z80 and 8048/8051 for the single chips and then going off to PIC and Atmega. Looked at 8086 and decided it was a 8080 with a bag on the side. It was and still is irrational. Disassembly for 8085 is dirt simple as the opcodes are easily classified and decoded. Its easy enough to do in a word processor, find and replace. Allison > bill >
Re: 8085 Dissasembly?
On Tue, 4/17/18, Eric Smith via cctalk wrote: > On Mon, Apr 16, 2018 at 7:29 PM, Chuck Guzis via cctalk > wrote: >> Disassembly is never lots of fun, > > Some of us might disagree. > But then, some of us might be masochists. I was just thinking the same thing. This whole discussion has taken me back to fond memories of writing a 68000 disassembler in AWK (long story). BLS
Re: 8085 Dissasembly?
On 04/17/2018 09:25 AM, Warner Losh via cctalk wrote: > On Tue, Apr 17, 2018 at 7:12 PM, Johnny Eriksson via cctalk < > cctalk@classiccmp.org> wrote: > >> Bill Gunshannon wrote: >> >>> Many of us think that the advent of the x86 architecture is what led to >>> masochism. >> ... or masochism led to the x86 architecture. >> > I think you are confused maybe. Wasn't it sadism? > > Sadism on Intel's part but masochism on the part of those who willingly accepted it. Not sure where that leaves the rest of us. bill
Re: 8085 Dissasembly?
Doing disassembly is about a process of refining. Some expect the disassembler to figure out where the gobs of data bytes are. Most such disassembler do a poor job on one or another program. The ones that actually work best are those that allow you ( a human ) to look at the result and allow you to see list of suspected pointers. Also, those that high light sections of code that don't make much sense. These features allow one to feedback to the assembler meaning full labels for what the code does. Although, one might think this type of disassembler is more complicated, it is often the simpler ones that are the easiest to use. I recommend that you write your own disassembler. The 8085 has a simple code. Make it so you can post process notes made into the early listings and have them copied to the new listing. It need to be able to start and stop disassembling and putting in fields of data bytes. It is always useful to be able to define these data bytes in some regular format, such as ASCII strings, address tables or possible offsets. The ability to carry forward such information makes the process of dissecting a program so much easier. If it is a disassembler that you wrote, you can add features that may be specific to the code you are disassembling. An example of this is one I recently wrote to understand Forth code. I'm looking at a Forth written for the 6502 but turnkeyed for a specific purpose that is no longer useful. It had its complete dictionary intact that I'm making a new boot section to allow me to access the interpreter and compiler. One can optimize C code as well. It tends to have regular groups of instructions as well. You as a human with a brain can do better at understanding things than any program. Dwight From: cctalk on behalf of Bill Gunshannon via cctalk Sent: Tuesday, April 17, 2018 6:07:21 AM To: cctalk@classiccmp.org Subject: Re: 8085 Dissasembly? On 04/17/2018 08:04 AM, Noel Chiappa via cctalk wrote: > > From: Eric Smith > > > But then, some of us might be masochists. > > I think pretty much by definition if you're into vintage computers, you have > to be a masochist... :-) > > Many of us think that the advent of the x86 architecture is what led to masochism. bill
Re: 8085 Dissasembly?
On Apr 17, 2018, at 8:25 AM, Warner Losh via cctalk wrote: > On Tue, Apr 17, 2018 at 7:12 PM, Johnny Eriksson via cctalk < > cctalk@classiccmp.org> wrote: > >> Bill Gunshannon wrote: >> >>> Many of us think that the advent of the x86 architecture is what led to >>> masochism. >> >> ... or masochism led to the x86 architecture. >> > > I think you are confused maybe. Wasn't it sadism? > > Warner …? weren’t we talking about disasm? Maybe you got spell-checked, Warner? :-)
Re: 8085 Dissasembly?
On Tue, Apr 17, 2018 at 7:12 PM, Johnny Eriksson via cctalk < cctalk@classiccmp.org> wrote: > Bill Gunshannon wrote: > > > Many of us think that the advent of the x86 architecture is what led to > > masochism. > > ... or masochism led to the x86 architecture. > I think you are confused maybe. Wasn't it sadism? Warner
Re: 8085 Dissasembly?
Bill Gunshannon wrote: > Many of us think that the advent of the x86 architecture is what led to > masochism. ... or masochism led to the x86 architecture. > bill --Johnny
Re: 8085 Dissasembly?
On 04/17/2018 08:04 AM, Noel Chiappa via cctalk wrote: > > From: Eric Smith > > > But then, some of us might be masochists. > > I think pretty much by definition if you're into vintage computers, you have > to be a masochist... :-) > > Many of us think that the advent of the x86 architecture is what led to masochism. bill
Re: 8085 Dissasembly?
> From: Eric Smith > But then, some of us might be masochists. I think pretty much by definition if you're into vintage computers, you have to be a masochist... :-) Noel
Re: 8085 Dissasembly?
On Mon, Apr 16, 2018 at 07:01:51PM +, W2HX via cctech wrote: >Hi friends. I have a 1990's vintage commercial radio system that uses an >80C85A CPU. I am looking to hopefully modify the firmware to make some >small changes in its behavior. The firmware is contained in two EPROMS. > >Can anyone recommend a decent disassembler to use with this? Preferably >something that ran in windows 10 or windows 7? A dos box would be fine >too. I wrote one for DOS eons ago that does simple execution tracing and supports the 8085: http://www.dbit.com/pub/ibmpc/dasm/ It's not perfect but the price is right and it comes with source. John Wilson (KC1P) D Bit
Re: 8085 Dissasembly?
On 04/16/2018 03:01 PM, W2HX via cctech wrote: > Hi friends. I have a 1990's vintage commercial radio system that uses an > 80C85A CPU. I am looking to hopefully modify the firmware to make some small > changes in its behavior. The firmware is contained in two EPROMS. > > > Can anyone recommend a decent disassembler to use with this? Preferably > something that ran in windows 10 or windows 7? A dos box would be fine too. I've used DASMx freeware. My primary for that work is resource/Zsource but that runs on my CP/M box where my EPROM reader/writer is. Google 8085 disassembler. Try several to see what works for you. Generally those that interact with the user are best as you can sorta guide them around text sections and allow you to assign descriptive labels to sections (subroutines). You may even need a 8085 simulator to test sections of code. > Also, I looked through the dumped contents of the EPROM. In the past I have > seen EPROM ascii dumps where most is unintelligible to the naked eye but > typically text messages give to the users during interaction with the program > are human readable. In this case, the ASCII dump shows only other HEX data. > I believe I read that there is a HEX format and that I might need to convert > from HEX to BIN before disassembling. Of course, an ideal tool would do both > if anyone knows such a thing. > You may depending on what the tool expects. Usually hex dumps obscure the text. Its not common for 8085 programmers to compress text. That assumes the text is not a bitmap for a LCD or LED then all bets are off as to what you may see. > I am not familiar with 8085 stuff but any insight would be appreciated. > I am. You will need to understand the 8085, its environment (the stuff it controls) and what the memory layout(both rom and ram) and IO layout. Learn the 8085 instruction set. FYI the 8080/8085 user manual is on line so find it and get it will be a big help. As they say, you will be working very close to the raw metal. One worry is that the code could have been written in C or PL/M (or PLI) and that may obscure the code further. > Lastly, I wonder if there might be some kind of checksum check to prevent > tampering. Is there a common way this is handled in 8085 world? Or is it > entirely programmer dependent? The 8085 does not have hardware checksum. Its a programmer thing as in who wrote the code and if there were requirements by management or client to have checks (may include other self tests and manufacturing diagnostics as well). However, its possible to do that in the code as part of the startup self check (or BITE if mil). That only means you have to either negate that code (after finding it) or you can find where the checksum is and write a new one. In cases where I've seen it it was early in the startup and was there to verify the Eproms were not broken than a worry about tampering. Doing this is not trivial and you are in full forensic sleuth mode. Hope that helps. Allison/KB1GMX
Re: 8085 Dissasembly?
On Mon, Apr 16, 2018 at 7:29 PM, Chuck Guzis via cctalk < cctalk@classiccmp.org> wrote: > Disassembly is never lots of fun, > Some of us might disagree. But then, some of us might be masochists.
RE: 8085 Dissasembly?
Hi Glen, Allison, Jonathan, Chuck, et. al. Thanks everyone for the suggestions. I investigated the IDA Pro and unfortunately, the freeware version does not support 8085 and their lowest tier version costs $700 (ouch), but I will look into others like DASMx. In case anyone is interested in the project, this is a transmitter system. There is one button called PWR when pressed it cycles through different output power levels - 125W, 500W, 1KW and then back to 125W and so on. Problem is, I have a 500W amp, not a 1KW amp. The manufacturer was kind enough to explain that they never got around to updating the firmware in the remote control for the 500W system and therefore it assumes 1KW is available. In my case when 1KW comes around the system goes into "funk mode". All I am looking to do is to remove the 1KW option and have it cycle from 125W, 500W and back to 125W. I am hoping this could be done with a JMP in the right place or some NOOPs or something. Appreciate the responses. Eugene W2HX -Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Glen Slick via cctalk Sent: Monday, April 16, 2018 8:35 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: 8085 Dissasembly? You could post the EPROM files you have online somewhere for other people to take a quick look. Maybe create a thread on the vcfed forum and add them as an attachment to a message there. If you zip them up they should be small enough for an attachment. I have only tried using IDA Pro a couple of times. I haven't learned how to use it well enough to be what I have used for similar 8-bit CPU disassembly tasks in the past. I have just written my own basic functionality 8085 / Z80 / 8051 disassemblers when I have had the need. Not too hard to make it smart enough to be able to specify known entry points (for example reset and interrupt vectors) and have it do reachable code traversal from there. Some things require manual intervention and iterative refinement, for example any indirect jumps through call tables, or calculated jumps. Using a professional tool might be quicker, but you might learn a lot more along the way doing things yourself.
Re: 8085 Dissasembly?
On 04/16/2018 05:35 PM, Glen Slick via cctalk wrote: > I have only tried using IDA Pro a couple of times. I haven't learned > how to use it well enough to be what I have used for similar 8-bit CPU > disassembly tasks in the past. I have just written my own basic > functionality 8085 / Z80 / 8051 disassemblers when I have had the > need. Not too hard to make it smart enough to be able to specify known > entry points (for example reset and interrupt vectors) and have it do > reachable code traversal from there. Some things require manual > intervention and iterative refinement, for example any indirect jumps > through call tables, or calculated jumps. Using a professional tool > might be quicker, but you might learn a lot more along the way doing > things yourself. I've used IDA Pro quite a bit and like it a lot. One of things that it does is analyze program flow. You can assign your own labels and symbol names; it can detect subroutine boundaries and you can change the assembly syntax of constants. Disassembly is never lots of fun, but IDA makes it easier. I think that it's still possible to get the old "free" version on the web. The "pay to play" version covers a lot of processors (8- 16- 32- and 64-bit). IDA does require a bit of learning the lay of the land, but once you et started, things get easier faster. --Chuck
Re: 8085 Dissasembly?
You could post the EPROM files you have online somewhere for other people to take a quick look. Maybe create a thread on the vcfed forum and add them as an attachment to a message there. If you zip them up they should be small enough for an attachment. I have only tried using IDA Pro a couple of times. I haven't learned how to use it well enough to be what I have used for similar 8-bit CPU disassembly tasks in the past. I have just written my own basic functionality 8085 / Z80 / 8051 disassemblers when I have had the need. Not too hard to make it smart enough to be able to specify known entry points (for example reset and interrupt vectors) and have it do reachable code traversal from there. Some things require manual intervention and iterative refinement, for example any indirect jumps through call tables, or calculated jumps. Using a professional tool might be quicker, but you might learn a lot more along the way doing things yourself.
Re: 8085 Dissasembly?
IDA Pro will do 8080/8085 and is very nice -- especially if you have no source and are having to reverse-engineer the whole thing yourself. The commercial version is expensive, but there's a free version. I don't remember if the free version includes 8080/8085 mode. The strings may be packed ASCII, to save space. There were a few methods of doing this. If there's a checksum it's not inherent to the CPU. There would need to be custom hardware on the board to enforce a hardware ROM checksum; otherwise, it's left to software and you can easily update that :) Thanks, Jonathan On Mon, Apr 16, 2018 at 3:01 PM, W2HX via cctalk wrote: > Hi friends. I have a 1990's vintage commercial radio system that uses an > 80C85A CPU. I am looking to hopefully modify the firmware to make some > small changes in its behavior. The firmware is contained in two EPROMS. > > > Can anyone recommend a decent disassembler to use with this? Preferably > something that ran in windows 10 or windows 7? A dos box would be fine too. > > > Also, I looked through the dumped contents of the EPROM. In the past I > have seen EPROM ascii dumps where most is unintelligible to the naked eye > but typically text messages give to the users during interaction with the > program are human readable. In this case, the ASCII dump shows only other > HEX data. I believe I read that there is a HEX format and that I might > need to convert from HEX to BIN before disassembling. Of course, an ideal > tool would do both if anyone knows such a thing. > > > I am not familiar with 8085 stuff but any insight would be appreciated. > > > Lastly, I wonder if there might be some kind of checksum check to prevent > tampering. Is there a common way this is handled in 8085 world? Or is it > entirely programmer dependent? > > > Thanks for your time > > Eugene W2HX? > > >
8085 Dissasembly?
Hi friends. I have a 1990's vintage commercial radio system that uses an 80C85A CPU. I am looking to hopefully modify the firmware to make some small changes in its behavior. The firmware is contained in two EPROMS. Can anyone recommend a decent disassembler to use with this? Preferably something that ran in windows 10 or windows 7? A dos box would be fine too. Also, I looked through the dumped contents of the EPROM. In the past I have seen EPROM ascii dumps where most is unintelligible to the naked eye but typically text messages give to the users during interaction with the program are human readable. In this case, the ASCII dump shows only other HEX data. I believe I read that there is a HEX format and that I might need to convert from HEX to BIN before disassembling. Of course, an ideal tool would do both if anyone knows such a thing. I am not familiar with 8085 stuff but any insight would be appreciated. Lastly, I wonder if there might be some kind of checksum check to prevent tampering. Is there a common way this is handled in 8085 world? Or is it entirely programmer dependent? Thanks for your time Eugene W2HX?
