=========================================================================
(C) 1994 by Atari Corporation, GEnie, and the Atari Roundtables. May
be reprinted only with this notice intact.  The Atari Roundtables on
GEnie are *official* information services of Atari Corporation. To sign
up for GEnie service, call (with modem) 800-638-8369.  Upon connection
type HHH (RETURN after that). Wait for the U#= prompt.Type XTX99437,GENIE
and press [RETURN]. The system will prompt you for your information.
==========================================================================



                      Wednesday Night Real Time Conference

                              February 3, 1994

                          Host - Larry Duke



<[Temp Host] LARRY.D> I'm gonna be eating pizza while typing.  If you see
some cheese on my text, you'll understand....

<[John too] J.G.H.> hehe....and drinking Jolt and smoking cigarettes?

<[The MadMan] W.JONES43> Keith!  Long time no chat!

<[Temp Host] LARRY.D> As the room slowly fills.....

<[John too] J.G.H.> isn't that the programmer's diet?

<[Temp Host] LARRY.D> It is for me.  Went to the dentist today, and I'm
dying to try out this new cap.  I may also type a bit hard to understand,
considering the Novacaine....

<[Bill] W.JONES43> Forgot I was being the programmer type tonight! <grin>

<E.MONACO> \nam Erin

<E.MONACO> ack!

<[John too] J.G.H.> ack...ack

<[Temp Host] LARRY.D> We knew who you were anyway, Erin...

<E.MONACO> ok... never mind then! :)

<[Bill] W.JONES43> I finally got a Thursday off work - haven't been to
this particular RTC before.  What type of programming are we discussing?

<[Temp Host] LARRY.D> All types, Bill.  C, Assembly, GFA BASIC, whatever
you want to....

<[John too] J.G.H.> Larry is tonight's "Special" host, Mike is busy
tonight

<CBARRON> gee, thats a wide area<grin>

<[Bill] W.JONES43> Ah - PureC's my favorite environment.  Hisoft BASIC
for quick and dirty hacks.

<[Temp Host] LARRY.D> You don't want to join us, Rob? (Rob's hiding in
the other room)

<[John too] J.G.H.> I am currently playing with M.A.G.E. and GFA

<[Bill] W.JONES43> John, is M.A.G.E. a toolbox for GFA or library
routines?  Could it be interfaced to C?  The results I've seen look
pretty impressive.

<E.MONACO> I can't stay long but Mike wanted us to define our objectives
for the next homework assignment a little better.

<[John too] J.G.H.> It is a Graphics Engine and I think it currently only
works with GFA of course you can use C in GFA so it probably is possible

<[Bill] W.JONES43> Did my time with STOS - very nice results if you have
LOTS of patience.

<[Temp Host] LARRY.D> True enough, Bill.  Interesting language, isn't it?

<[Bill] W.JONES43> Yeah, but I don't own GFA and can't get a lead on 4.0.
The 2.0 version crashes BADLY on my TT.  OTOH, PureC's editor is a dream
in TT-Med res.

<[Temp Host] LARRY.D> I'm using GFA 3.6TT Bill.  Works great in all
resolutions (including 1280*960)  Of course, the guys at GFA will swear
up and down there is no 3.6, but that's what mine says....

<[John too] J.G.H.> Also MAGE comes with the latest version of GFA Basic
Interpreter, compiler and assembler on disk

<[Bill] W.JONES43> Larry - yeah I heard that from them too.  Actually
they told me _NO_ version of GFA was TT compatible.

<E.MONACO> It'd be nice if they offered a version of M.A.G.E without GFA
for those who already own it.

<[Temp Host] LARRY.D> Naw - they are the ones that sold it to me.  I
think anything after 3.6E is TT compatible...

<[Temp Host] LARRY.D> Back from lurking, Rob?

<[/dev/null] R.ANISKO> unlurked... how is everyone tonight?

<[Bill] W.JONES43> Larry, programs _written_ in 3.5E MAY be TT
compatible.  All depends on how you set the fastload and TT-RAM bits. 
I've gotten a few to work well.

<[Temp Host] LARRY.D> I see that Carl uploaded homework for this one. 
What was the actual assignment?

<[carl] CBARRON>  Re: Homework, good idea, how complicated a editor are
we 'eventually' writing?

<[Bill] W.JONES43> As long as the author stayed away from the RESERVE
command.

<[John too] J.G.H.> I know programs using MAGE don't like screen
accelerators

<[Bill] W.JONES43> John, actually Dark Pearl plays fine here with NVDI on
the TT.  Too damn fast to get past the first few inches of the board, but
it _DOES_ run!

<[Temp Host] LARRY.D> Bill - The earlier versions of GFA have a little
problem with their MENU S$ command - it always defaulted to an 8 pixel
height character.  TT resolutions made the menus terribly compressed and
overwritten.

<[carl] CBARRON> I did?  I have an incomplete one on my HD. Perhaps that
was the first assignment Mike's looks a little more structured, this
time.<grin>

<[Bill] W.JONES43> Larry - THAT'S what caused that.  Always wondered
about it.

<[John too] J.G.H.> I just turn off my warp 9

<[Temp Host] LARRY.D> Even earlier versions of GFA will still run if you
use 24BIT.PRG in the auto folder.  They stored additional info in the
upper 8 bits of the addresses.

<[John too] J.G.H.> MajicSoft also have BUTTONZBASIC a GUI shell for GFA
which makes things easier ;>

<[Temp Host] LARRY.D> I use GFA for things quick and dirty.  For real
programming, I use DEV PAC TT.  I gotta upgrade to 3.0 soon....

<[Bill] W.JONES43> Larry - actually I use PMMU.  Nicer, fixes a couple of
mapping problems for games that ask for the ROM version directly and
doesn't require a keypress if you have it in the auto folder.

<E.MONACO> Our assignment was to write a simple windowed editor that
would edit one windows worth of information.  Just do simple stuff like
cursor movement, insert, delete.  If you wanted you could add a resource
contianing a menu with info & Quit.

<[John too] J.G.H.> I am trying to get the folks from MajicSoft on GEnie
for an RTC

<[/dev/null] R.ANISKO> I have a quick "C" question if anyone could answer
it?

<[Bill] W.JONES43> Shoot, Rob...

<E.MONACO> I don't think anybody got into the editing part of it yet. I
didn't.

<[carl] CBARRON> where are we going with this editor?  I have some gap
buffer code, I might use if this is really an editor.  I do use Lattice C
and misc. unix tools ported to ST/TT.  If this is going to go no place a
simple arrangement is possible without

<[/dev/null] R.ANISKO> real simple (but i haven't figured it out) - how
could I simply write a  ?

<[/dev/null] R.ANISKO> oops. hang on...

<[Temp Host] LARRY.D> That sounds like a very adventurous homework
assignment....

<[carl] CBARRON> without any real editor code.

<[/dev/null] R.ANISKO> how can I ask for a keypress and treat it as a
hotkey - that is, take the keypresss and act *without* needing to hit
RETURN? in "C" that is

<[Bill] W.JONES43> Which C are you using?

<[/dev/null] R.ANISKO> GCC

<E.MONACO> How far I am not sure, we had talked about adding maybe load
and save, search and replace, things like that in later assignments.

<[Bill] W.JONES43> Oh - in your TOS binding you'll find int Bconin(int
port).  Use port 2 for the keyboard.  Inputs 1 character from device.

<E.MONACO> "How far" is something we can address now.

<[/dev/null] R.ANISKO> ok - will have to "grep" my header files and see
what asscoaiets (associates) to it (typos tonight)...

<[Bill] W.JONES43> Rob - or to be more "general", get(stdin) also works.

<[Temp Host] LARRY.D> Is anybody having problems with the homework
assignment so far?

<[/dev/null] R.ANISKO> hmm, Bill, get(stdin) and not stdin(  (oops)
getch(stdin) or getchar(stdin)?

<[Bill] W.JONES43> Rob - getch(stdin) in GCC.  PureC has a couple of
shortcuts.

<[/dev/null] R.ANISKO> which Programming RTC had the latest and greatest
description of the homweork? maybe i'll write myself an online
spell-checker :-)

<E.MONACO> Was it 6th of Jan?

<[carl] CBARRON> Ok if we are going to do something with it sometime, I
will play with a gap buffer.  Got the generic code for one.

<[/dev/null] R.ANISKO> which file transcript though?

<[Keith] K.GERDES> I think the description was uploaded to the Topic.

<[/dev/null] R.ANISKO> ok - will see if i can capture the info later...

<[John too] J.G.H.> I will go look for ya ;>

<[Temp Host] LARRY.D> You know, writing an editor is something I've
wanted to do for a long time.  I am by no means a professional
programmer, and my little mind doesn't come up with any creative thoughts
on buffering ideas.

<E.MONACO> I believe Keith is right, it should be in the Topic.

<[Bill] W.JONES43> Rob - if you're programming TOS style and don't intend
to port your code, use TOS for all it's got.  Your code will be faster. 
You need to list out your BIOS.H, GEMDOS.H and other headers and just
prowl around.

<[/dev/null] R.ANISKO> i wrote a simple editor under microsoft-c some
time ago - might have to steal some of my old code (unfortunately it's
not Atari code :-(

<[Temp Host] LARRY.D> What is the best way to do this?  A gap buffer, I
realize is what is needd, but how should each line be stored in memory? 
After an edit, should the entire document be reformatted in memory and
the inserted in the proper place? (that should read "the LINE inserted in
the proper place.")

<[/dev/null] R.ANISKO> ph well, will try to hack around sometimes this
week - i need to go now though - maybe see yunz at the brodie rtc...

<[John too] J.G.H.> here it is ;>
hmmmmm....

<[Bill] W.JONES43> Larry, shouldn't an editor insert 1 character at a
time and reformat as quickly as possible?  Otherwise you can't see what
you're doing until you finish the line!

<[John too] J.G.H.> well if anyone else needs the info on the homework
here it is

Number: 31565  Name: PRGRTC04.ARC
Address: MIKE-ALLEN                Date: 940108
Approximate # of bytes: 10496
Number of Accesses: 54  Library: 13

Description: Transcript of the 4th Programming RTC held on 6 January,
1994.  Comments and reviews of the 1st homework assignment.  Second
homework assignment defined.

<[carl] CBARRON>  A gap buffer keeps the free space of the buffer at the
insert point. Pointers to the start of lines, with lengths is one
approach to lines.

<E.MONACO> I'd planned on doing its something like that.  Not worrying
about wrapping or stuff like that.

<[Bill] W.JONES43> Carl - I like that concept.  Easy to implement too.  I
guess since I wasn't in the original "assignment" RTC I should hush now,
though... <smile>

<[carl] CBARRON>  Easy but not that easy, when all the possibilities are
considered. Have DDJ's C source on that someplace.

<[Temp Host] LARRY.D> So, you basically just have an array of addresses
for the start of each line?

<[Bill] W.JONES43> Carl, is your line size defined?  If so, then you
don't need pointers to the start of each line unless your trying to
conserve memory.

<[Temp Host] LARRY.D> It would be relatively easy if all lines were a
given length, but how do you work with variable line lengths, and edits
that extend over 1 line?

<[Bill] W.JONES43> Any of you ever been on a BBS using FidoDoor?

<[carl] CBARRON> That is the only real approach. It also complicates the
gap buffer approach some as the start of a line in the buffer is
variable.  A gap buffer is going to move lots of text variable lines get
the most out of a fixed amount of memory and reduce the 'mallocs'
involved for long lines.  The one thing I hate about some editors is a
line max. Some as small as 100 characters.  terrible for editing ascii
text files....

<[Bill] W.JONES43> Larry, why would an edit extend past one line?  You'd
have to make changes character by character or the user wouldn't see the
results as they typed.

<[carl] CBARRON>  Search and replace will edit in more than one character
at a time...

<[Temp Host] LARRY.D> Here's my thought, Bill (it's probably really
screwed up, and I'm hoping somebody can set me straight)....

<[Bill] W.JONES43> Carl, I see your point.  Yes, then you'll have to have
pointers to the start of each line and your search routine will have to
ignore whatever you're using as an EOL marker.

<[Temp Host] LARRY.D> Each character is displayed when it's entered, and
the text is stored in a temporary buffer.  Once ENTER, an arrow key, or
something like that is pressed, the contents of the buffer is dumped into
the TEXT buffer and stored.  That way, you could have an UNDO function
really easily.

<[Bill] W.JONES43> But the gap concept isn't totally off.  Insert or
modify the necessary text, then increment/decrement the line pointers
after the modified line by the changed length if any, then redraw. 
Larry!  I'm gonna have to do something like that in MY editor (for real
editor, not this project).  So obvious it never dawned upon me.  I have
an undelete line function, but not an undo right now.

<E.MONACO> I'd planned on going pretty much the same route.

<[Bill] W.JONES43> Actually, it'd be easier just to have a "twin" of your
real text buffer - when they hit your "hot" keys, copy it back to the
"real" buffer.  Always display the "twin" on screen.

<[Temp Host] LARRY.D> If you insert text, the TEXT buffer would then be
reformatted with the new text inserted in the right place.  It would take
LOTS of memory moves to create the text buffer in a sequential order.

<[carl] CBARRON>  Larry that is one approach useful in reducing memory
moves of a gap buffer as well.  Bill, all lines after the edit as well
will move with a gap buffer.

<[Bill] W.JONES43> Carl, yes - I meant to modify ALL the line pointers
after the affected line.  Inserting text requires 1 memmove() call. 
Carl, maybe I don't follow you.  You have a SECOND area of memory for
your gap buffer?  Why not just create the gap in your REAL text buffer?

<[carl] CBARRON> memmove is ok, but with a project like this and a 680x0
a better approach is to move longs if possible, providing the size of the
move is bigger than 16 bytes.

<[Bill] W.JONES43> That's the way Bryan Hall and I did it with FidoDoor.

<E.MONACO> Would using the blitter speed it up?

<[Temp Host] LARRY.D> My experiences with the Blitter are that it's not
quite as fast as straight assembly moves....

<[Bill] W.JONES43> Carl - true.  And YES, blitted moves will make it FLY,
but only if you're moving 16 bytes or better.  But sheesh, how fast are
you expecting someone to type? Larry, but this isn't being coded in
assembly, is it? Or does the language matter?

<E.MONACO> Using longs you have to insure that your working on even
addresses, and on the newer 680X0's using a longword boundry will speed
it up even further

<[carl] CBARRON>  A gap buffer moves the 'free area' to  the insertion
point any time the text is changed.  If you use a simple edit approach in
a second buffer then insert it onta return or cursor movement.  Moving
64k or 128K at a time to insert one chara cter is slow....

<[Bill] W.JONES43> Carl, okay - but for display purposes you need have a
pointer that say which line is currently held in the gap buffer and its
location.  Also that makes you have a size limit on edits, correct?

<[carl] CBARRON> No, you write the text SKIPPING THE AREA OF THE GAP
buffer. It is constantly changing in location BTW.

<[Bill] W.JONES43> Carl, now I'm confused.  Don't you want to display the
changes they're making AS THEY MAKE THEM?  Otherwise you won't know if
you made a typo until you move the cursor.

<[carl] CBARRON> Well it is confusing to talk in three lines. A gap
buffer is a block of unused memory that is moved to where it will be
used. If you set the pointer of the current line to an input buffer, no
problem, it will display the input buffer.  It is possible in design,
details are not infront of me. As we are seeing this is not as simple as
first appears....

<[Bill] W.JONES43> Carl, okay.  That's what I meant.  Display all
unchanged lines PLUS the gap buffer they're currently typing.  Something
I've been meaning to add to FidoDoor, in fact to speed up its redraw
speed.

<[Temp Host] LARRY.D> I honestly thought this was an ambitious project
for this early in the Programmer's RTC life - it may well be over the
heads of most people (me included)

<[carl] CBARRON>  over heads, only if thinking past the 'design specs' of
the assignment. I do think, it should be in pieces myself.  After years
of reading, I am often lost myself....

<[Temp Host] LARRY.D> Can we redefine the assignment?  Has anybody got it
handy?

<[carl] CBARRON>  for the assignment an array of say 500 byte lines is
more than sufficient, as it stands.  512 makes more sense <grin>

<E.MONACO> Carl, for some people even working with GEM is totally new. 
Why don't we just concentrate on opening a window with a title and close
box if thats not enough we could do a displayed cursor that can be moved
with the arrow keys.

<[Temp Host] LARRY.D> That's not a bad idea.  I personally would be
intimidated by an assignment to write an editor like this.  I could,
however, write something that opened windows, reacted to all of the
window commands, etc.  I could then take THAT knowledge and use it later
for a project like this.

<[carl] CBARRON>  Gem text is something I hardly ever do. Fine we can
open a window, clear its contents and redraw it. That is essentially what
my shell is doing.

<[Temp Host] LARRY.D> Still, I'm a little unclear as to the actual
assignment.  I realize it's a text editor in a window, but with INSERT,
DELETE, and stuff like that? Just writing the cursor control portion
would be a relatively long project...

<[carl] CBARRON>   Supposedly, eventually...  Cursor control with mouse
or just gadgets and cursor keys???

<E.MONACO> It shouldn't be that hard.  You need routines that will turn
the cursor on and off and adjust its onscreen position.  I'd like to see
mouse control.  That'd be a nice feature and not to hard to implement
once the regular routines are in place and working correctly.

<[carl] CBARRON>  a small box drawn in xor mode over the text is the
normal way to draw a cursor. removal is the same as drawing...  thought
lag....

<E.MONACO> Keith, what do you think?

<[Keith] K.GERDES> I sent Mike email a couple weeks ago about starting
out small and working the way up through the AES ladder.

<E.MONACO> I believe thats the best way to procede.

<[Keith] K.GERDES> The project as it stands is way too ambitious IMO...

<[tony] T.SMOLAR> hello everyone

<[Temp Host] LARRY.D> I think that's a good idea, Keith.  The first
assignment was to check the computer status and display it on screen. 
Now, why not do the same thing in a window? Hiya, Tony.  We take what we
already know, then build up slowly.  Next time, we add resources.  The
time after that, we add something else, etc...

<[tony] T.SMOLAR> I was wondering if anyone could help me, I'm having
problems getting GNU C working

<[Temp Host] LARRY.D> Pretty soon, we've done every call in standard TOS,
and we can then start with the extended calls of MiNT, etc....  Shoot,
Tony - I can't answer, but there are people here that probably can.

<[carl] CBARRON>   Not a bad idea, KISS there are a lot of people with
not a lifetime to devote to a project.<grin>  Structured design helps a
lot....

<G.SIMUNOVICH> I've got GNU C up, what's the matter.

<[tony] T.SMOLAR> I'm trying to get GNU C working with either Gulam, or
GNU BASH, preferably BASH But when we try to use the compiler, it seems
like it can't find something\

<E.MONACO> I have to go... so are we just going to worry about getting a
window up and handling that?

<[Temp Host] LARRY.D> Eric - that's my preference.  Of course, I'm just a
small player in a big band...  Oops - EriN

<[carl] CBARRON>   Erin, looks like you are right.  I don't think mike is
ready for a full editor at this time either....

<E.MONACO> I like the stats in a window idea, but have already done that,
I suppose I could add to it though.

<[Temp Host] LARRY.D> George, any ideas on how to help Tony?

<G.SIMUNOVICH> How about a text viewer in a window???

<E.MONACO> I agree, I've done alot on my project but at the expense of
getting other work done, I'd like to see it toned down a bit. :)

<[Temp Host] LARRY.D> That's not a bad idea, George.  No editing, just
viewing, etc...

<G.SIMUNOVICH> Depends on what it cann't find as to the problem,
environment variable probably.

<[carl] CBARRON>   About GNU C sounds like some environment strings are
wrong. I don't use gnu C  so the specifics I don't have...

<[tony] T.SMOLAR> I have GCC set up (in gulam) as per the "Quick Start"
instructions.

<E.MONACO> Okay.  Take care everyone.

<[Temp Host] LARRY.D> After this, we could add SEARCH capabilities, then
menu's to load, etc...

<G.SIMUNOVICH> 3 variables are needed GCCEXEC "setenv GCCEXEC
d:/<path>/gcc-" GNUINC "setenv GNUINC d:/<path to includes>" GNULIB
"setenv GNULIB d:/<path to libs>"

<[Temp Host] LARRY.D> Tony - does that sound like it will work?

<[tony] T.SMOLAR> Could the problem be that I am using "\" pathname
separators instead of the UNIX-like "/" ones?

<G.SIMUNOVICH> with GCCEXEC the "gcc-" is needed as it prefixs the
executable needed "ld", "as", etc with the variable.  This assumes the
executables are named "gcc-ld", "gcc-as".  Tony, it should not "/" & "\"
are the same for most GNU and public domain thing.

<[tony] T.SMOLAR> Can someone tell me more about "UNIXMODE" under Bash?
How do I set Bash up to work with it?

<G.SIMUNOVICH> Also, instead of "d:/<>" you could try "/dev/d/<>", these
programs treat both as the same.  Tony, you can send me mail if this
doesn't work, include what errors are produced, etc and I'll reply.

<[tony] T.SMOLAR> Thanks.

<[Splat!] DMJ> Hello...

<G.SIMUNOVICH> UNIXMODE is to complex to explain here, but I'll send you
some docs I have.

<[carl] CBARRON> Da fun of 'cheap' software.... <grin>  Written for unix
masters... <grin>

<[tony] T.SMOLAR> Ok, I'll give that a shot, thanks for the help.  and
I'll look forward to that doc file.

<G.SIMUNOVICH> Written to get UNIX things working ok on the Atari.

<[Splat!] DMJ> So what's all the discussion about tonight?

<[carl] CBARRON> True, you don't happen to have berkeley yacc 1.9
compiled?

<[Splat!] DMJ> (And _don't_ ask me if I did my homework...)

<[Temp Host] LARRY.D> Damien, did you do your homework?

<[carl] CBARRON> What is the discussion? a) splitting the homework, b)
how to edit text, c)other.

<[Temp Host] LARRY.D> (I had to do that)

<[Splat!] DMJ> I said not to ask me that! No, I didn't do my homework.

<G.SIMUNOVICH> No yacc here, just starting to get GNU stuff, damn they're
big.

<[Splat!] DMJ> I've _never_ done my homework, if I could get away with
it... ever since I started school.  Might explain why I nearly flunked
out.

<[carl] CBARRON> Just downloaded f2c (f77 to c) translator only 594K
compressed tar file.<grin>

<[Splat!] DMJ> Geez, tiny download...

<G.SIMUNOVICH> Just got CS-TeX, 4meg.  Ghostscript 1meg, thank god for
fast modems.

<[Splat!] DMJ> I could never get into UNIX-type tools.  For some reason,
they just don't appeal to me.  Carl, however, loves them...  So it's
probably just me.

<G.SIMUNOVICH> I got really hooked on Unix at school, I REALLY like suns.

<[carl] CBARRON> True but it might contain the code I need to write a
fortran file reader for my  c code..... They do work esp. sed/gawk....

<[Splat!] DMJ> I always knew I was warped.

<G.SIMUNOVICH> For my entire Atari setup I might be able to buy a CPU.<g>

<[Splat!] DMJ> Maybe if I'd had the chance to work on a Sun or other UNIX
workstation I might like it more.  But then again, my fondness for neat,
compact, _usable_ programs might get in the way... <g> Anybody see Keith
Gerdes' post about Missouri?

<G.SIMUNOVICH> "compact" would be really nice.

<[Temp Host] LARRY.D> Nope - he just left, though (actually, he was
disconnected)

<[Splat!] DMJ> Hmmm.  Maybe he knew I was coming.  I have a feeling we
might not be on speaking terms, soon.  (Sigh)

<[carl] CBARRON>   Small useable tools are the backbone of unix style
operations. this stuff is source and often underdocumented [for
'dummies'] documentation.

<[Splat!] DMJ> That depends what you call a usable tool.

<[Temp Host] LARRY.D> "If it was hard to write, it should be hard to use"
"Real programmers don't document" or comment their code....

<[Splat!] DMJ> For example, a program to display memory usage in a
windowed dialog, updated every five seconds or so...  How big, in C? I
must not be a real programmer, then.

<[Temp Host] LARRY.D> Big - in assembly?  Small...

<[carl] CBARRON>  Larry, that is the problem and they resent profesional
writers doing it for them!

<[Splat!] DMJ> No, how big would such a program be in C? i.e. how many K
is the executable.  Did I mention resolution-independent? Works as a
program or accessory? Is MTOS & Geneva aware? Includes an option to shut
off the five-second update thing?

<[Temp Host] LARRY.D> I'd say as a minimum it would be 18K (if you have a
good optimizing compiler)

<G.SIMUNOVICH> GNU C produces about a 15k file to do nothing (stripped). 
Damn those huge libs.

<[Splat!] DMJ> Uses 100% legal GEMDOS and AES calls? Right now, mine is
sitting at 5K.  And it wasn't something I slaved at for weeks, either.

<[carl] CBARRON> Depends on the compiler and slim down startups. maybe
8-12K in LC5.

<[Splat!] DMJ> I didn't go to any great pains to make it small.  If I
had, I wouldn't have embedded a complete .RSC file in the program.  I
think I'm making an ass of myself here.  I should stop.

<[Temp Host] LARRY.D> Written in assembly, Damien?

<[Splat!] DMJ> Of course.  It will probably be ready by Saturday.  If I
didn't have to work tomorrow, it'd be tomorrow.

<[carl] CBARRON>   Size of the 'lib stuff' is signifigant only on small
student sized projects. a project like ldw power not so....

<G.SIMUNOVICH> Anyone know a a good RSC editor (recent) availiable???

<[Splat!] DMJ> That's true, Carl.

<[Temp Host] LARRY.D> You know, those are my feelings, too.  I write in
assembly, never learned C because of the terrible overhead.  I started on
a 16K computer, and have been very memory conscious ever since.

<[Splat!] DMJ> In a 100K program, who cares about a 10K library?

<[carl] CBARRON>  commericial - I use wercs.  Free ORCS works, but is not
3d aware, I do not believe.

<[Temp Host] LARRY.D> George - I have INTERFACE from GRIBNIF software. 
It's really nice.  The new one from ATARI is supposed to be really nice,
too.

<SAM-RAPP> Hello.  Is this informal?

<[Splat!] DMJ> ORCS is not 3D aware, no.  It's what I use.  Yep,
informal.

<G.SIMUNOVICH> Not many people write 100K programs.

<[Splat!] DMJ> Really? Huh.  I'll keep that in mind when I try to keep
Sound Lab under 200K.

<SAM-RAPP> Can I ask a non-programming related question?

<[Splat!] DMJ> Won't bother _me_. <g>

<[Temp Host] LARRY.D> INTERFACE is really nice.  GRIBNIF hasn't finished
the English docs yet, and I hope to get those in the mail when it then
completed.  Nice RCS, though.  Next time you're in town, I'll be glad to
show you, George...

<[carl] CBARRON>  I got one 141K demo exec, will get bigger since I found
the problem. over 400K of source, I did not write...

<[Splat!] DMJ> Yeah, those demos are usually huge.  A lot of it is
because they use straight-line code, tho'.

<[carl] CBARRON> esp. when it is msdos code!

<[Splat!] DMJ> They get great speed by eliminating the looping overhead.

<SAM-RAPP> How can one use a WOrd Perfect file on an Atari?

<[Splat!] DMJ> Oh, MS-DOS code.  That's different.  That's always huge,
no matter what you do.  Use WordPerfect ST?

<SAM-RAPP> All I have is WORKS.

<[carl] CBARRON>  unsigned char foo[]={....}; stuff over 400K....

<[Splat!] DMJ> Even a 386 takes twice as many instructions to do the same
task as a 68000.  It's ridiculous.  I don't know AW, Sam... can't help
you.  Perhaps one of these other enlightened individuals?

<[Temp Host] LARRY.D> There is a program to convert Word Perfect to ASCII
somewhere in the library...

<SAM-RAPP> Where?  ;-)

<[Splat!] DMJ> Which would strip out all the formatting, but would be
useful if all you needed was the text.

<[Temp Host] LARRY.D> Are we talking WP 4.1 or a later version?

<SAM-RAPP> I dunno.  I FTPed some files off internet, and I THINK they
are wordperfect.

<[carl] CBARRON>   Its about 75% of the msdos side. On WP there is
program to translate wp5.2 files to something in the libs I downloaded,
but did no use....  internet, tex, or postscript is more likely....

<SAM-RAPP> The first two characters are "WP" and one line further down
says "NEC SILENTWRITER..." There is a lot of crappy formatting stuff
throughout.

<[Temp Host] LARRY.D> Yep - that's a WP file, alright.  Search the
library (item 3) for CONVERT and see if something shows up.

<[carl] CBARRON>  ok is probably a word perfect file. I'll let some
search the libs. It is less than a month old if I recall.  I can find it
if it's there!  Thanks.  I'm gonna go look!  Thanks! Bye!