jhs@MITRE-BEDFORD.ARPA.UUCP (05/06/87)
Did I miss the posting of Ace C to the net? I didn't see it go by, but am
seeing messages of appreciation. Why, oh why, does my host have to pick the
worst possible times to be down? (I know, Murphy's Law, of course.)
Could somebody re-post it or mail it to me directly? Thanks!
Also, can anybody comment on the following: It appears to me that ACTION! is
MANY TIMES faster at compilation than any C compiler around. E.g., my wife,
who has used C compilers on WANG's IBM-PC clones, about fell off her chair
when she saw how fast ACTION! compiled a 2-page program -- around 0.75 second,
as I recall, by the way. Now, it appears to me that ACTION! is a lot like C,
and probably a C implemented with the same kind of approach would compile just
about as fast. I understand that ACTION! also produces mind bogglingly
efficient code. We will all have a chance to see how true this is if I ever
finish my C version of uuencode and uudecode and we can compare with the
Deep Blue C and BASIC/ML versions that now exist. My question is this: Would
it be possible to implement C with ACTION! technology, and would it indeed
run as fast and compile as fast as ACTION! does? If so, why doesn't somebody
up and do this? (Clint Parker, where are you?!)
While I have the floor, let me also ask why in all these years nobody has
come up with a standard for "relocatable object code" for the Atari?
Usually when I ask people this, they say "it's hard to write relocatable code
for a 6502". In my mind, that is the very reason that we NEED a relocatable
object code format. This is not an executable format, but one which can
easily be relocated to the desired memory segment and the absolute references
filled in. What is needed is an assembler which preserves the relocatable
versus absolute semantics of its input and marks those values in the output
which need to be relocated so that the linker can identify them at link time.
So the relocatable intermediate object code format plus the availability of an
automatic linker and (hopefully) "librarian" utility, would COMPENSATE FOR the
limitations of the 6502 instruction set and let us develop really decent
language environments -- all ending up in the same relocatable format.
If we could readily develop reusable software libraries, with the performance
that languages like ACTION! and MAC65 give, we could greatly reduce the effort
involved in developing high-performance application programs on the 8-bitters.
By the way, I understand that there is a recently-announced assembler that
DOES produce relocatable object code, but unfortunately does not (yet) have
macro capabilities. I can't locate the name and address I was given but will
post it if I find it. Maybe their format will become the standard!
-John Sangster
P.S. Thanks to Sascha Segan for his reply about Turbo BASIC for the 800.
Also, thanks to Fred Sullivan for his help with the ACTION! Block Read
question, and to the several others who also responded privately.
I wanted to share some of my thoughts on where the 8 vs 16 bit atari
machines is going.
I have owned an atari 8 bit machine since 1980 and have loved every minute
of it. I am now at a crossroads, however, in upgrading. As background, I
have an 130XE, 810 drive, monitor, and an MX80 printer. Consider the
following data (near best price from magazines):
Upgrading the XE: ATARI ST (new):
SpartaDOS 3.2 $40 1040ST/mono $820
RTIME8 (clock) $50 Clock/cal $50
MIO (1meg) +20Meg HD $970 (ATARI) 20 Meg HD $650
MIDI (Hybrid Arts) $200 (midi built in)
----- -----
$1360 $1520
(Mono ST vs. Color XE is not totally fair, but read on)
I simply cannot bring myself to spending like that on a dead end machine.
However, after giving it some thought, I concluded that the 8 bit machines
ARE NOT DEAD. Why? They still do many things very well. Also I have
noticed that a lot of 8 bit software is VERY CHEAP!
So here is where I think things are going based on my needs as a model (ha)
Keep the 8 bit machine. Let my child use it sometimes (he is currently 3).
I went out and bought a second disk drive for it (a $130 1050) to eliminate
the disk swapping head aches. I will continue to buy software for it since
that is usually priced below the new machines. For example, recently I got
ARCHON II <$10
Miner 2049 <$5
Millipede $2.50
Can't beat that.
Get an ST. I intend on using it for synthesizer control and a genealogy
data base project. If ATARI gets its TT act together, who knows? A sun
(near) equivalent machine at home!
I leave you with this summary. The 8 bit machines are NOT dead, but the
future holds limited interest and growth. The machine prices are getting so
low that you cannot significantly expand an 8 bit for much less than an ST.
Comments are indeed welcome. I am not spending any money on these things
yet until I have a chance to think about this for a while.
8 bits forever,
16 bits for the future too.
Daryl Monge UUCP: ...!ihnp4!iheds!dlm
AT&T CIS: 72717,65
Bell Labs, Naperville, Ill AT&T 312-979-3603
------------------------------
Date: Tue, 5 May 87 10:03:56 PDT
From: cel@CitHex.Caltech.Edu (Chuck Lane)
Subject: ARCX problems
To: linus!philabs!tg!dasys1!ssegan@husc6.harvard.edu,
I've been trying to get the ARCX program that was posted going on my
800, with only a certain amount of luck. The program as posted
uudecodes to a binary load file that looks like:
$FFFF binary file flag
$2416 - $4D38 part1
$0400 - $0510 part2
$02E0 - $02E1 starting address = $3000
$FF1A - $FFFF ?? all $FF's ??
the last segment won't load properly on my system, and it looks like a
control-Z followed by $FF's. I truncated the last piece, and the program
at least loads and starts running, asking for an archive file, and
doing a disk directory properly. When I uudecode JUMBO and have ARCX
work on it, it starts to extract ARC.COM,
(paraphrasing)
<Enter filename or + for directory>
>JUMBO.ARC
DRIVE #1
SCREEN OFF?: N
<Extracting ARC.COM> ... 196 bytes <squeezed>
and just hangs there. Checksums match for uudecoded JUMBO and ARCX when
uudecoded on my 800 and VAX/VMS, so I think they uudecoded okay. Are there
some system dependencies? I have a 48K `plain vanilla' 800, running
OSS's DOSXL. I've also tried Atari DOS 2.0, with the exact same results.
-- Chuck Lane
cel@cithex.caltech.edu
@cithex.bitnet
@cithex.span/.hepnet
------------------------------
Date: Tue, 5 May 87 18:35 EDT
From: John R. Dunning <jrd@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Disk drive questions
To: info-atari8@score.stanford.edu
A couple of questions:
I've got a fairly old Astra 1620 disk drive, which has this annoying
habit of writing bad sectors periodically. It seems to happen only when
the machine's been reading from drive 2, and then goes to write on drive
1 immediately. Sometimes (not always) when that's been happening, a bad
sector or two shows up right in the middle of the file on drive two that
it was reading. Not nice. It seems to work fine if there's a delay
between reading and writing. Has anyone ever seen this sort of lossage,
and if so, what can I do about it?
Second question, which shouldn't come as a surprise in light of the
first, is what recommendations does anyone have about disk drives these
days? I'm looking for single/double density, dual disk models
preferred.
Any information appreciated.
------------------------------
End of Info-Atari8 Digest
**************************
-------jhs@MITRE-BEDFORD.ARPA.UUCP (05/06/87)
****** A T T E N T I O N A-8 D I G E S T E D I T O R *********** ***** OOPS! Bill Westfield Please use this version instead of the one I accidentally sent with half of the Digest hanging on!!! ******* ****************************************************************************** Did I miss the posting of Ace C to the net? I didn't see it go by, but am seeing messages of appreciation. Why, oh why, does my host have to pick the worst possible times to be down? (I know, Murphy's Law, of course.) Could somebody re-post it or mail it to me directly? Thanks! Also, can anybody comment on the following: It appears to me that ACTION! is MANY TIMES faster at compilation than any C compiler around. E.g., my wife, who has used C compilers on WANG's IBM-PC clones, about fell off her chair when she saw how fast ACTION! compiled a 2-page program -- around 0.75 second, as I recall, by the way. Now, it appears to me that ACTION! is a lot like C, and probably a C implemented with the same kind of approach would compile just about as fast. I understand that ACTION! also produces mind bogglingly efficient code. We will all have a chance to see how true this is if I ever finish my C version of uuencode and uudecode and we can compare with the Deep Blue C and BASIC/ML versions that now exist. My question is this: Would it be possible to implement C with ACTION! technology, and would it indeed run as fast and compile as fast as ACTION! does? If so, why doesn't somebody up and do this? (Clint Parker, where are you?!) While I have the floor, let me also ask why in all these years nobody has come up with a standard for "relocatable object code" for the Atari? Usually when I ask people this, they say "it's hard to write relocatable code for a 6502". In my mind, that is the very reason that we NEED a relocatable object code format. This is not an executable format, but one which can easily be relocated to the desired memory segment and the absolute references filled in. What is needed is an assembler which preserves the relocatable versus absolute semantics of its input and marks those values in the output which need to be relocated so that the linker can identify them at link time. So the relocatable intermediate object code format plus the availability of an automatic linker and (hopefully) "librarian" utility, would COMPENSATE FOR the limitations of the 6502 instruction set and let us develop really decent language environments -- all ending up in the same relocatable format. If we could readily develop reusable software libraries, with the performance that languages like ACTION! and MAC65 give, we could greatly reduce the effort involved in developing high-performance application programs on the 8-bitters. By the way, I understand that there is a recently-announced assembler that DOES produce relocatable object code, but unfortunately does not (yet) have macro capabilities. I can't locate the name and address I was given but will post it if I find it. Maybe their format will become the standard! -John Sangster P.S. Thanks to Sascha Segan for his reply about Turbo BASIC for the 800. Also, thanks to Fred Sullivan for his help with the ACTION! Block Read question, and to the several others who also responded privately.