#Tx-Ed
23 messages in this thread
I have three questions about Tx-Ed:
1) How many bytes of memory does it use?
2) Are all Tx-Ed's commands memory resident?
3) Where is Jimmy Hoffa?
Thanks, George Glines
1) As much as it needs! (the file itself is 25848 bytes — that's not the
current version tho — I'm using an older version).
2) All the commnads are intrinsic.
3) Same place D.B. Cooper is hiding out.
Actually the version I'm using now is about 21K 'cause I've
recompiled it with Lattice V3.10 using relative addressing. Hold
the phones though! This is *not* a "Silent Update" yet. Hope
to have an official V2.0 some time this summer, available for
$20 or less to registered owners.
…cheath
Thanks Steve!
George
Currnt version of TxED is 25492 on disk, and it grabs some buffer space when it
loads. It seems to come in at about 70K memory usage, but bear in mind that
text up to 35000 bytes will not add to theat total. If you load a larger file,
it will grab more memory as needed, and release it when done with it. It is a
very friendly program as far as multitasking goes.
All "normal" commands are resident, and the only thing that requires another
program is the "print from clipboard" function, that is a separate program. It
runs regardless of what else is happening, even if you leave TxED.
Jimmy Hoffa? He's hiding in a small town near Chicoutimi.
Or was that Billy Hoffa?
Regards, Larry.
I'm hoping to make it even more multi-tasking friendly, by having it become
re-entrant. That unfortunately depends on my finding an assembler that will
generate relative addressed code assuming register A6 as base register,
compatable with Lattice V3.10. That'd save about 25K for each window opened!
But alas, it does not appear that such an assembler exists, so my options are
to spend a week converting to manx, or spend a week explicitly converting every
data reference to an offset reference, or… just give up.
Sounds like quite a job you've set yourself there Cheath. Personally, I think a
switch to Manx might be the way to go. Best of all, you can look at exactly
what is generated (in assembly) with the C source as comments, a feature worth
a lot to someone like me.
Regards, Larry.
I've tried switching to Manx a couple times, but had some nasty bugs I
couldn't trace – I've got a lot of asm code that makes assumptions about
register allocations, plus all the C code was written assuming 32-bit int size
so it's not too happy being compiled by Manx. Likely that's what I'll end up
doing, though, since it doesn't seem likley that a Lattice-compatible assembler
such as I need for relative addressing will mysteriously show up on my
doorstep. But just in case – I'm willing to pay good bucks to somebody if they
develop one!
Charlie, from what I hear of the new release of Manx, it is pretty good, and
though Lattice has been improved a lot, Manx has not been resting on their
laurels. You can always use the 32 bit model at the expense of larger slower
code unntil you get everything converted properly.
Regards, Larry.
I just wish Manx would ship my upgrade so I could find out for myself!
(I called them today to find out were it was — "oh, it must be down in
shipping getting packaged" — uh huh — that's what I heard 4 weeks ago!
I love their compiler, can't wait for the update, but I'm not too sure their
shipping people are on the ball.
Well, they can't be shipping alphabetically, as jeff Lydiatt called them up and
they told him it would be shipping this coming Monday.
Regards, Larry.
They told me they're shipping by 2 different priority lists — by serial number
(mine is 191) and by those who yell the loudest.
AARRGGHH! <Looking sadly at 3.20A disk, which has a serial number of 397> I
guess I'll never get mine, then. Don't suppose the fact that I had one of the
early 1.99E betas also, matters to them? <Sigh>
Rick <Chugging along in 3.2/1.2 mixed mode> Rae
Hey Larry; Lattice allows the same thing; It's just an extra pass
with a tool called OMD like so: "omd file.o file.c", assuming you
gave the compiler the -d switch when you ran the compile of the
module in question. Plus everythings compatibobule, and includes
are CMB supported (not that THAT means much — look what a balls-
up they made of the 2000) –Ben–
So how do you assemble the output of the OMD, ie, what assembler is it
compatible with?
Regards, Larry.
Larry, wanted to thank you for pointing me toward TxED! Got it today and it
solved the problem I was having with garbage at the top of files I was
transferring from my old CoCo to the Amiga. Thanks again…Dave
Dave,
Glad you like it. I think it is one of the best editors I've ever used.
My quarrel with most editors is that they tend to do too much, losing speed or
ease of use in the process.
Just last night I was looking for some library routine offsets to check
against a disassembly, and decided it was time to stop counting and multiplying
multiplying routines positions in the FD files.
Turns out it couldn't have been much easier to do. Fist, I used TxED to
strip out all the "extra" lines that were only comments, then placed the first
routine of each file on line 30 of the file, did a search/replace to put all
lines 6 apart, and saved the file back out. from that point, a search on each
file for the occurrence of a "(", redirecting the output to another file,
yielded all the correct offsets. The entire process took me about 35 minutes.
Regards, Larry.
Larry, well you're talking over my head (not hard to do) but is sounds good.
I'm finding TxED to be excellent…Dave
Assemble it; Why would you want to do such a thing? You mean to
(shudder) optimize it? In my mind, the ONLY reason you would EVER
want to look at the output of a compiler is to decide whether you
want to REPLACE it with assembler, not optimize… Normally, I think
that instinct will tell you without OMD or whatever the Manx tool
provides. Optimizing compiler output is VERY counterproductive.
Here's why; Compiler makes "stuff". You look. You say, echh! and
modify (shudder) same. Ok. Next week, oops! left out calculation
in recursive sort & hiccup loop. Gee, the very one you (shudder)
optimized. Too bad. Compiler puts in what you forgot, your changes
are history, and… you're mad. On the other hand, you look, see,
say echh! and rewrite in assembler, find bug, fix bug, all done,
happy. Using compiler to write first pass of assembly is also
yechh. practice, in my (humble and self-abasing) opinion. This due
to the fact (yes, fact) that no compiler can hold a candle to a
real, twinkee/coke certified assembly language programmer.
< G R I N >. –Ben–
My sentiments exactly Ben, though I do occasionally do a little optimization, I
it is only when messing around with routines, and not in something I am likely
to keep.
Regards, Larry.
TxEd's about 25K of code, and will allocate about 40K more
of data to run. However, it uses SIMPLE_REFRESH windows which
save about 32K per window compared with similar applications
that use "SMART_REFRESH" – which is about 95% of amiga applications.
The only non-resident TxEd command is the print spooler,
which is loaded as a separate command.
Regarding Jimmy, I don't know but I don't think he's
trapped in a TxEd package.
…cheath
Cheath, I'm not sure how this whole TxEd-Hoffa thing got started but I'm sure
Geraldo Rivera will be looking into it soon 8). BTW, I have gotten hooked on
Funkeys (plus FastFont and screenblanker) and the "runback" utility really
makes Funkeys shine!
Thanks, George
Just what I need, Geraldo Rivera snooping around in my Amiga!
( thanks )