>From: "Dave Dunfield" <dave04a(a)dunfield.com>
---snip---
>
>I find having the disassembler inject comments is very useful, as it
>allows me to re-run the disassembler at any time without losing the
>comments (very useful in the "oh crap - this block should really be
>WORD data - not BYTE data) situation.
>
Hi Dave
I agree, I think that being able to feed comments back into the
disassembler is one of the most important parts, like you.
I find that I needed a way to strip the comments from
the listing file and not simply type them into a separate
file. The method I've been using is maybe to simplified
because it doesn't allow inline comments but I've not
found this to be all that bad. One can still put one line
of comment with each line of code. I expect that the next
one I write, I may try to include some method of capturing
the comments that are inline with the code as well, though.
I originally had a separate file that I'd edit comments into
but found that I couldn't make myself do this every time.
I wanted to edit the comments into the listing file as
I figured things out. Going back and finding the comments
to feed back was always a pain. That is why the computer
generates the comment file from the listing file,
automatically for me. I guess I'm just to lazy. The
price was that I needed to make it easy for the computer
to find my new comments.
Dwight
Hello, all:
Does anyone have any idea how to connect a non-TI printer to the port on
the TI-74 BasicCalc? The actual printer unit is scarcer than hen's teeth.
Googling didn't produce any useful links other than general information
sites.
Thanks.
Rich
Rich Cini
Collector of classic computers
Build Master for the Altair32 Emulation Project
Web site: http://highgate.comm.sfu.ca/~rcini/classiccmp/
/************************************************************/
>>> COMMENTS!? I'd like to see a disassembler comment code! Humans
>>> even are areally bad at this...
> I add comments after the decompiling with a merge. The
>control file just has code start addresses and data block
>types/addresses. I even deal with labels in a separate file that
>is later merged to form the complete output file.
>I even put data in a separate file from the code.
>I like the idea of just merging it all when done.
>The disadvantage of this is that only computer generated
>comments exist on the same line as the code or labels
My disassemblers (see my web page) use two control files:
One controls how the disassembler views memory blocks, including
symbols, block type (code, byte data, word data, reversed word
data, strings etc.)
The other controls comments blocks. For each block, you provide
a memory address (or none=continuation of previous address), and
either block or line comments. Block comments are inserted as
separate lines. Line comments are appended to the end of the code
lines generated by the disassembler.
The disassembler can generate the initial memory control file with
generated symbol names for addresses which are referenced within
the code block. (Sorry - it can't generate initial comments :-) Then
in a highly manual and iterative process, you re-run the disassemler
over and over again, providing more information in these two files
as you "figure it out". The end result (if you stick with it long
enough) is an assembly source file indistinguishable from an original
source file (often better because many people use more meaningful
names and comment better during disassembly then they would when
writing original code!)
I find having the disassembler inject comments is very useful, as it
allows me to re-run the disassembler at any time without losing the
comments (very useful in the "oh crap - this block should really be
WORD data - not BYTE data) situation.
Regards,
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Vintage computing equipment collector.
Hi All,
Well it was a good day for classic stuff at the U of A auction today.
For a whopping $2.50 i got:
A HP 9000 200 (double stack), have not looked inside yet. powers on but I need
to make a cable for a serial console.
A HP 7673 Controller! Whatever that is (same kind of case as the 9000 200)
A HP external storage case w/HDD a floppy with HP1B connector
A HP 9000 Apollo series 400, boots fine but has no HDD.
AND a box of around hundred and fifty 5 1/4 floppies that included:
1 complete set of AT&T Unix PC V.3.0 (32 disks) and probably 3-4 more "broken"
sets that are missing a few disks.
I wanna kick myself for passing on the AT&T 7300 in pristine condition about
two months ago for about $5.00 concluding I'd never find the Unix to go with it.
Go figure.
Cheers,
Tom
In my quest to read every tu58 tape on the planet (one needs a goal :-),
I managed to read 3 tu58 tapes today.
Naturally in the middle of the 4th tape the controller died. (looks like
the rs422 received failed for some reason... humm... digikey to the
rescue :-)
Anyway, I think I have valid vax 11/730 console and diag tape images.
The 730 console tape looks almost pristine except for 2 files added to
the end (I wonder if the original "defboo.cmd" has been replaced, but it
should be possible to reconstruct it with a little hackery)
http://www.heeltoe.com/download/vax/contentshttp://www.heeltoe.com/download/vax/BE-T173I-MEhttp://www.heeltoe.com/download/vax/BE-T175I-DEhttp://www.heeltoe.com/download/vax/BE-T176I-DE
BE-T173I-ME "BE-T173I-ME","TU58#34 11725/730 CONSOLE","1982,1984"
BE-T175I-DE "BE-T175I-DE","TU58#35 11725/730 DIAG SUPER","PROPERTY OF DEC","1982,1984"
BE-T176I-DE "BE-T176I-DE","TU58#36 11725/730 MICRODIAG","PROPERTY OF DEC","1982,1983"
I also hacked an ancient CP/M program which reads RT11 disk images to
run on linux. It allows one to read the dir, copy a file out, copy a
file in, type a file, etc... (it's like 'putr' but only knows rt11)
It can be used (on linux anyway) to read the tape images and get files
off them. I haven't used it to create a tape image yet, but plan to.
http://www.heeltoe.com/download/vax/rt11.tar.gz
I should have the drive running again once the UPS man arrives :-) I think
I have some 750 console tapes also, which I'll put up as soon as I read
them.
-brad
>From: "Ethan Dicks" <dickset(a)amanda.spole.gov>
>
>On Thu, Apr 08, 2004 at 01:46:55PM -0700, Tom Jennings wrote:
>> On Wed, 7 Apr 2004, Dwight K. Elvey wrote:
>>
>> > It is interesting that my definition of a disassembler is
>> > quite a bit different than yours. I would call this a code
>> > lister. A disassembler includes comments, selecting data types,
>>
>> COMMENTS!? I'd like to see a disassembler comment code! Humans
>> even are areally bad at this...
>
>I'm working with a tool that decompiles Z-Machine binaries (think
"Zork")
>into Inform source code. It injects comments into the output code when
you
>describe enum data types. Since decompiling is an iterative process,
one
>of the features I want to add to this tool is comments in the control
file
>that are copied verbatim to the output source file. It puts the burden
on
>the person running the decompiler to understand the output, but it would
>then be _possible_ to have commented output.
>
>-ethan
>
Hi Ethan
I add comments after the decompiling with a merge. The
control file just has code start addresses and data block
types/addresses. I even deal with labels in a separate file that
is later merged to form the complete output file.
I even put data in a separate file from the code.
I like the idea of just merging it all when done.
The disadvantage of this is that only computer generated
comments exist on the same line as the code or labels
( like the counts of how many times a label was used ).
Human comments are always on separate lines. This is
all controlled by the sorted address fields. Comments and
labels are attached to specific addresses that are used
during the merge of the various files.
This way, the comments are not part of the control file
( no specific advantage here ) but by sorting before merging,
disassembled code, comments and labels don't need to be
placed in the output files in any specific order. Comments
only need to have an address to show order. Order of these
sub pieces that may have the same address is controlled by
the merge order.
Comments can be easily extracted from an edited list file
by looking for text that doesn't have address. One simply
uses the next address after this text for the next iteration.
Comments are most easily added this way to the previous
output list file and feed back for the next iteration
and future iterations by placing them in the comment file.
The comment file also has the advantage that it can later
be edited to enhance comments or rearrange lines within
comments( remember a comment can be multiple lines with
the same address ).
I used the DOS sort ( 64K limit fixed by splitting
files ) and my own merge that takes any size files.
It is all handled in a batch file so I just take a break
while it runs.
Dwight
Rumor has it that Patrick may have mentioned these words:
> > sendmail is a piece of Swiss cheese when it comes to security and
> > it's only
> > of *when*, not *if* there is another security hole found.
>
>What server software does this not apply to? --Patrick ;-)
qmail.
There has *never* been a "user-permissions" exploit (as in any user being
able to gain any permissions to any other user, including root) and the few
bugs that have been found generally just make it die.
There was a new bug that was just found in it - if a user sends a mail with
a header line longer than 2Gbytes, it'll crash that particular process, and
I think the mail is lost to the ether.[1]
All other mails will still be delivered fine, tho.
Why is the most secure MTA not included with every Linux distro? DJB's
license is (at best) wonky, to preserve his codebase & help alleviate
techsupport nightmares, and as it's not "Open Source" with fully
redistributable binaries, none of the linux vendors (except Gentoo, which
compiles stuff on the fly) will touch it.
http://www.qmail.org/ && http://cr.yp.to/qmail.html for more info.
Laterz,
Roger "Merch" Merchberger
[1] If you have people sending you 2G Header lines, you have a lot bigger
problems than one crashed qmail-smtpd process...
--
Roger "Merch" Merchberger -- sysadmin, Iceberg Computers
zmerch(a)30below.com
What do you do when Life gives you lemons,
and you don't *like* lemonade?????????????
>Webmail prolly won't run well on your target hardware, but if go with
>something newer, there are several choices for qmail; and with an older
>version of ColdFusion (4.5) you could set up webmail no matter what MTA...
>This combo will run fine on a Pentium 133 (almost on topic...) -- and
>there's always www.mail2web.com as backup...
I can also run a 2nd machine to handle the actual web mail processing if
need be. And web mail isn't a deal breaker anyway. I just happen to have
two or three users that keep asking me about it, so I figured as long as
I'm upgrading, now would be a good time to try to add it.
>If you want "It's gotta support the latest, kewlest schtuff" qmail isn't
>for you
I don't care about the latest bells and whistles per se... however, since
my goal is to reject known spam and viri, that ebs into the relm. But, it
sounds like you are having no problems on that end of things anyway.
In fact, like you point out, since I want to run on old hardware, I may
be better off going with something that isn't going to expect me to
constantly add to it... that way once it is running, I can just leave it
running and not have to worry about regular updates (probably the single
biggest reason why I won't run Windows based internet servers... they
expect you to do updates too often, I don't have the time/desire to jerk
around with that).
>I was supporting 2500 mailboxen on a Cyrix 6x86 w/single 4.5M Micropolis
>SCSI HD - if it weren't for spam & viruses, we might still be running that
>ol' box... :-O
I'm not looking at anywhere NEAR that number of boxes. I'm looking at
around 50 spread among a dozen domains (most of the domains are Unified
accounts anyway, so one box covers all possible addresses for the
domain). The server only gets in the range of 2000 messages a day (most
being to me anyway). So it is a fairly light duty server.
>I haven't run Sendmail in aeons;
I've heard enough horror stories about Sendmail to know that I probably
don't want to use it. From what I gather, its great, IF you know how to
use it... but if you are new to it, be prepared to move the sacrificial
lambs off the SCSI god alter and onto the Sendmail god alter.
(Ironically, Sendmail is the only *nix mailer I have used already... I'm
running it on both my web servers for handling emails created by web
forms... but I didn't really have to do much to get it up and running,
just a little tweaking to lock it down from the outside)
>Anyway, that's my story, and if you want any (kinda ;-) unbiased info about
>qmail, feel free to ask away. I'd be more than happy to help!
Thanks
-chris
<http://www.mythtech.net>
