HDTenEightyP/NetNews huggingface dataset:
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Newsgroups: comp.sys.atari.st.tech
Subject: GFA: Compiled program bombs at SWAP *x%,x$()
Date: 22 Nov 1992 15:55:50 +0100
Organization: Regional Computing Center, University of Cologne
Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
NNTP-Posting-Host: rs1.rrz.uni-koeln.de

Hi tech folks,

I have run into an annoying problem  with  the  GFA  basic  3.6TT
system.  The command mentioned in the subject causes the compiled
program to exit with two bombs,  or  sometimes  to  exit  wit  an
"Error  64"  alert  box.  However, in the interpreter the program
runs without such a problem.
This takes place on a TT, in TT med resolution, no matter whether
the TT ram bits are set or not.
I have tried to write a short program  that  reliably  reproduces
the  error,  without  success. Therefore, I include an outline of
what I do in the program that causes the trouble:
The program is GEM-based and menu driven.  It  loads  stuff  from
files into string arrays, and this stuff can then be displayed in
windows. There can be several windows, which can all  be  redrawn
by  the same routine. Therefore, I chose to store the the pointer
to the array which is shown in a window in some  window-specific,
MALLOC()'ed  chunk  of  memory.  When  it comes to redrawing, the
redraw routine retrieves the  pointer,  called  p_st%,  from  the
memory.  It  creates a dummy array, swaps the pointers, draws the
window acessing the dummy array which is the real  array  because
of  the  swapping. When redrawing is done, the arrays are swapped
again and the dummy array is erased. In GFA code, that is:

PROCEDURE redraw(w_handle&,x&,y&,w&,h&)
  LOCAL p_st%, ...
  DIM d$(0)
  a%=@w_adr(w_handle) !determine pointer to window-specific stuff
  p_st%={a%+176}
  ~FORM_ALERT(1,"[1]["+STR$(p_st%)+"|"+str$(*stb$())+"][ Ok ]")
  SWAP *p_st%,d$()
  .
  .  (redraw the stuff)
  .
  SWAP *p_st%,d$()
  ERASE d$()
RETURN

The alert box reveals that p_st% and *stb$()  are  identical,  so
the  problem  is not that GFA basic has shuffled the array around
and the pointer once stored is no longer pointing to the  current
location of the array descriptor.
Unfortunately, it doesn't seem to be possible to write a function
for  swapping  arrays manually. The problem is, swapping seems to
swap the internal pointers to the array descriptors  rather  than
the descriptors themselves. But maybe, I'll have to work on this.
I'll post to the net if I can find the reasons for the problem or
ways to work around it anyway.

BTW, a while ago someone mentioned he had a  list  of  known  GFA
bugs. I'd appreciate if this could be mailed to me.

Thanx in advance

Greetinx, Jan

 +- Jan Kim -- X.400:    S=kim;OU=vax;O=mpiz-koeln;P=mpg;A=dbp;C=de -+
 |             Internet: kim@vax.mpiz-koeln.mpg.dbp.de               |
 |                                                                   |
 *----=<  hierarchical systems are for files, not for humans  >=-----*
Newsgroups: comp.sys.atari.st.tech
From: rep@informatik.tu-chemnitz.de (Ralph Eppert)
Subject: MiNT & GEM programs
Organization: tu-chemnitz
Date: Fri, 20 Nov 1992 17:40:28 GMT

I have some little questions concerning MiNT and GEM programs. I want to know whether it is possible to 
determine in a normal GEM program if MiNT is active. If MiNT installs a cookie, it should be a very easy task.
What's the id of MiNT then?     
Is there a working version of a fileselector, which can handle the minix filesystem properly (especially the 
longer filenames) ?  
 
By the way, does anybody know Eric's new address?

Thanks in advance! 

Any help will be appreciated.


Ralph Eppert    rep@informatik.tu-chemnitz.de
From: okes@essex.ac.uk (Simon Oke)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: 16-bit RAM Access on Falcon ?
Date: 17 Nov 92 18:37:19 GMT
	<1992Nov16.152504.24848@Informatik.TU-Muenchen.DE>
	<1992Nov16.192239.9654@rmece49.upr.clu.edu>
Organization: Department of Computer Science, University of Essex, UK.
In-reply-to: raist@rmece02.upr.clu.edu's message of 16 Nov 92 19:22:39 GMT

In article <1992Nov16.192239.9654@rmece49.upr.clu.edu> raist@rmece02.upr.clu.edu (Ricardo Hernandez) writes:
|   While I wouldn't claim that the A1200 runs every available piece of
|software (particularly games), it surely runs almost any Amiga application.
|Include here all paint packages, desktop publishing, illustration programs,
|multimedia programs, etc.  Yes, it's got a significant advantage over
|the FALCON.  And BTW, I know of more than 30 games that run on the A600.
|
And I have a friend who can name a few dozen that don't even work on
his A500 plus (supposedly *completely* compatible with the 500 - har har.
So I don't think that there is much chance of those games running on a
600 or 1200, do you?

|    Psygnosis and Ocean have pledged support for the AGA.  There is another
| company that also pledged support for the AGA.  AT LEAST Psygnosis and
| OCEAN are MAJOR entertainment software companies....  Psygnosis ALONE
| is an EXCELLENT MAJOR GAME COMPANY... a company that have dropped ST
| support in some of their games...
|
I suggest you read comp.sys.amiga.games. Psygnosis are continually flamed
for producing games that refuse to run on anything more than a bog-standard
A500. They can't even support *current* machines, so what makes you think
that they can support new ones?

|    I suggest that you read signatures before replying.... the guy above
| seems to work for an entertainment software company and I think that
| he knows better.
|
The guy who wrote that article is a notorious bigot and flamer. Yes, he does
work for a programming team - a team that refuses to support anything other
than Amigas, I believe. Obviously they are totally reliant on hardware to do
the hard work for them.

--
This signature is copyright 12/6/1992 Simon Oke. All rights reserved. If you
like it and keep a copy for your own use, you owe me $20. Please pass it on
to your friends with all documentation.              Email okes@essex.ac.uk.
----------------------------------------------------------------------------
Analysis of television viewing figures has shown that 80% of people in this
	country are crap.
Newsgroups: comp.sys.atari.st.tech
From: morrison@ee.ualberta.ca (Robert Morrison)
Subject: Installing TOS 2.06 ROMs...HELP!
Organization: University Of Alberta, Edmonton Canada
Date: Fri, 20 Nov 1992 00:13:48 GMT

Greetings,

	I made a similar post on comp.sys.atari.st recently, but it occurred
to me that this group is more appropriate.

	Basically, in my 1040 STE I have installed the new TOS 2.06 ROMs but
my system won't operate with them in place.  The installation documentation
says that "jumpers W102, W103, and W104 be se to 1-2, 2-3, and 1-2 respect-
ively.  I can't do that easily, as my system board has resistors soldered
into those locations--in the configuration 2-3, 2-3, 2-3.  

	What can/should I do to make my new TOS work?


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|  Robert Morrison              morrison@bode.ee.ualberta.ca            | 
|                               Edmonton, Alberta, Canada               |
|  IBM Canada Ltd.              Ph:  (403) 439-9372                     |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|  [The universe cannot be read until we have learnt the language and   |
|  become familiar with the characters in which it is written.  It is   |
|  written in mathematical language...    Galileo Galilei (1564-1642)   |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: mhughes@comtch.spk.wa.us (Mark Hughes)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: GFA Basic Manual Wanted
Date: 22 Nov 92 06:14:51 GMT
Organization: Waffle BBS at CompuTech Spokane, Washington

hutch@bellman.lanl.gov (John Hutchinson) writes:
> Mark, there has been a LOT of confusion lately as to the status of GFA BASIC
> for the Atari platform.  I too, thought that Richter had purchased the entire
> rights to the Atari version but evidently, this is NOT so.  Here is an
> excerpt from a letter by John Barger, Tech Director at GFA Software Tech in
> Salem, Mass that was in the Nov issue of Current Notes:
> 
> "It is important for people to know that GFA-BASIC and GFA Software
> Technologies, Inc., are here to stay and fully support the Atari market.
> Said support can be shown in the imminent release of GFA BASIC 3.7 with more
> new features than you can "shake a joystick at" (including a new GEM-Based
> editor, a faster compiler, and Falcon/Multi-TOS compatability).
> 
> If Richter ever comes out with a 4.0 GFA BASIC with all the features that
> were rumored/promised in an earlier post here, then that's fine with me.
> But in the meantime, GFA Software Technologies in the US is still with us.
> 
> For more info, contact:
> 
> GFA Software Technologies, Inc.
> 27 Congress Street
> Salem, MA  01970
> (508)744-0201

  Ah...  I was not aware of this (I don't get any ST mags right now...  
and since I'm not on DELPHI right now, c.s.a.s is my main source of ST 
news right now)...  Is there a review of GFA 3.7?  I'd like to keep 
straight compatibility with the DOS/Windows/Amiga (and someday Mac and 
OS/2) versions...  The C-translator is a great concept, if it works right 
(I'd rather code some stuff in C, and the current compiler is a pain to 
do that with).
 
  A feature comparison would be cool when they both come out...  Any 
volunteers in net-land?

 - Mark Hughes (Caves of Steel 509-624-2078)  mhughes@comtch.spk.wa.us
"And just where are the rights to GFA split between Richter and GFA?"
Newsgroups: comp.sys.atari.st.tech
From: beaumont@sics.se (Anthony Beaumont)
Subject: Opus spreadsheet Author?
Organization: Swedish Institute of Computer Science, Kista
Date: Tue, 17 Nov 1992 10:55:09 GMT


Could someone please tell me how to get in touch with the author of the Opus
spreadsheet.  If he is reading this, could he please email me at:

        beaumont@cs.bris.ac.uk

-Tony Beaumont
University of Bristol

Newsgroups: comp.sys.atari.st.tech
From: pyr579@oz.plymouth.edu (Technoid)
Subject: Sozobon Help Needed
Reply-To: pyr579@oz.plymouth.edu (Technoid)
Organization: Plymouth State College - Plymouth, N.H.
Date: Sat, 21 Nov 92 22:44:01 GMT

Hello,

	I'm having immense trouble linking accs with sozobon. I have one
file that I wrote that I CAN link into a successfully working acc, but
when I tried to modify that code and change the function of the program,
but still using the original base I cannot link. I get a double
definition of __main error from the linker. This is very frustrating,
especially in light of the fact that the original compiles and links
every time. I am using sozoinit.o ( changed to dstart.o ), because I
cannot seem to make an acc with the original dstart.o at all. Can
somebody shed some light on the problem? Anyone write accs with sozobon?
If so I'd really like to see some code. Basically I took this code
from a very old st-log magazine that featured an accessory. That is how
I found out how to do the original acc stuff.

Stephan

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  pyr579@oz.plymouth.edu      Stephan R. Cleaves      Salamanders Are Slick...
  	       Newts Are Neato-van...    Chameleons Are Cool...
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Newsgroups: comp.sys.atari.st.tech
From: danieldr@ecr.mu.oz.au (Daniel_Romulus CUCINELLI)
Subject: Hard disk with ADSCSI.....Help!
Organization: Computer Science, University of Melbourne, Australia
Date: Sun, 22 Nov 1992 03:53:24 GMT


G'day peoples,

	Can someone please help me on the following problem I have with
a hard disk which I am connecting to my 1040STFM with the AdSCSI host adapter.

My hard disk assembly consists of the following.....
	
	1. NEC D3861 SCSI HARD DISK.....130 Mb
	2. 200 W P.C power supply.

	
	I have connected all the components together in a PC Case. 
And I am confident that all the connections are correct.  
	Now, when I power up the hard disk and then boot the ICD disk
utilities.  I find myself (after about 20 secs.)  on a gem desktop with
no disk icons.  From here I obviously cannot run the ICD Format program.
	I have noticed that the same thing happens when I completely remove
the SCSI cable which links the adapter to the hard disk.  (ie just having a
'powered' AdSCSI board connected to the Hard Disk port of the ST.  Can
someone check for me if this is normal behaviour ?
	So what can be wrong? 
	One of my prime suspicions is the SCSI cable which I made myself.  I
accidently (well didn't read the manual before doing it) connected the red
edge on the cable to pin 50, instead of pin 1.  But surely this shouldn't 
matter? As the red edge connects to pin 50 on the other end. So all coressponding pins are connected together.....I think....can someone clarify this? 
	Another possiblilty is that my hard disk isn't compatible with 
the host adapter (unusual I hope) .  Or that the hard disk isn't functioning
properly.  There are no led's on it.....but apparently it has a self diagnostic
test.
	Or maybe it is the AdSCSI host adapter that isn't working ??

Any help would be gratefully appreciated.
Thanks.

Daniel.
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon Bus
Date: 16 Nov 92 01:17:15 GMT
Reply-To: warwick@cs.uq.oz.au

In <1992Nov10.180014.2405@imada.ou.dk> micro@imada.ou.dk (Klaus Pedersen) writes:

>But I don't think that any 16 bitplane h-line or sprite routine is faster than 
>good 1 word/pixel implementations.

For h-lines, yes, but for sprites, I have my doubts - so much can be done by exploiting
the separation of the bit-planes - as you can see by what the Demo programmers do.  When
you have 8 bitplanes, it actually becomes useful in general (and 16-bitplanes would be
even better).  But yes, 1 word/pixel is the Right Choice for the True Colour mode.


--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /   C references are NULL && void*
      v      Brisbane, Australia.        /  
Newsgroups: comp.sys.atari.st.tech
From: nrossi@jarthur.claremont.edu (Nick Rossi)
Subject: GNU CC compiler - configured for 68000
Organization: Harvey Mudd College, Claremont, CA 91711
Date: Mon, 23 Nov 1992 01:21:09 GMT


I was referred to this newsgroup in search of a C compiler for the IBM
which can produce machine code for the 68000.  I need such a beast for
a microcontroller board I'm working on which is based on the 68000.
I was told that some folks over here have configured the Gnu-CC compiler
to produce 68000 code.  Is there an FTP site where I could get my hands
on this 68000-configured C compiler?

Thanks,

Nick
From: healy@nosc.mil (Mike Healy)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon '030 BUS: 16 or 32 bit?
Date: 19 Nov 92 07:16:14 GMT
Organization: Naval Ocean Systems Center, San Diego

In article <H.QHklPxgdMm2@fredrik.atari.no> jornmoe@fredrik.atari.no writes:
>Ok, sorry about this guys, but here's the final facts:
>

stuff deleted

>  This is what John Townsend (Atari Corp) said on GEnie:
>  --------------------------------
>  Atari-ST RoundTable
>  Category 14,  Topic 20
>  Message 73        Mon Nov 16, 1992
>  TOWNS [John@Atari]           at 15:01 EDT
> 
>  Once and for all..
>

stuff deleted

>  The Falcon030 can have a minimum of 1 meg of RAM and a maximum of
>  14 megs of RAM. Possible RAM configurations are 1meg, 4meg, or 16
>  megs of RAM.
>
>
>  -- John Townsend, Atari Corp.
>  ------------------------------

That last RAM configuration looks rather interesting if there is a
maximum of 14 megs :-) 

Mike Healy

healy@nosc.mil
Newsgroups: comp.sys.atari.st.tech
From: mpnolan@unix1.tcd.ie (Mark Patrick Nolan)
Subject: 16 bit data dus?!
Organization: Trinity College, Dublin
Date: Wed, 18 Nov 1992 12:46:58 GMT

Ok. That's it!!!
If you are telling me that Atari put a GREAT processor,
the 68030, and then put it onto a 16 bit data bus..well! 

look..

	1. Atari 8-bit [atari 800]
	2. Atari 16-bit [st]
	3. Atari 32(16) bit (?) [falcon]

If they're next computer is 16 bit it doesn't make sense!!!

Why not use a souped up 16Mhz 68000 instead of an expensive 68030
and still only have 16 bit data bus

RUBBISH!!!

Atari aren't THAT stupid!!!! The FALCON has a 32 bit bus, till 
I see it with my own eyes..

ps: has anybody seen the 16-bit bus with THEIR eyes?
		(no crap please)

Newsgroups: comp.sys.atari.st.tech
From: pyr579@oz.plymouth.edu (Technoid)
Subject: Thanks for Sozobon Help!
Reply-To: pyr579@oz.plymouth.edu (Technoid)
Organization: Plymouth State College - Plymouth, N.H.
Date: Mon, 23 Nov 92 23:00:05 GMT

Hello,

	Thanks to everyone who replied about compiling ACCs with
Sozobon.
I had in fact been using sozo 2.0, but am now using 1.33, it is
much better. I have not compiled an ACC yet, but I can tell from
the better workings of the GEM stuff I've been doing that I
should have no trouble with 1.33.

Stephan

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  pyr579@oz.plymouth.edu      Stephan R. Cleaves      Salamanders Are Slick...
  	       Newts Are Neato-van...    Chameleons Are Cool...
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Newsgroups: comp.sys.atari.st.tech
From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: 16-bit RAM Access on Falcon ?
Organization: SAR Systems Development & Processing, JPL
Date: Thu, 19 Nov 1992 04:22:51 GMT

In article <1992Nov16.192239.9654@rmece49.upr.clu.edu> raist@rmece02.upr.clu.edu (Ricardo Hernandez) writes:
>In article <1992Nov16.152504.24848@Informatik.TU-Muenchen.DE>, seibert@Informatik.TU-Muenchen.DE (Ewald Seibert) writes:
>   So, I don't know about what the Falcon can claim, but at least on the
>Amiga part of the statement, yes, major entertainment software producers
>have pledged support.

Most apps run fine on the Falcon, some games seem to trip up on 68030
incompatibilities.
>
>|> |>  I've got a 68040 in my A4000. Does a 68040 Atari even exist? Didn't think
>|> so.
>|> 
>|> there is a ATARI040 ready ...  
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    | WHERE?  Ready as a prototype or shipping?  Or is it a CARD?
>      or is it the Jaguar? (he he)

Well, there was no Falcon040 on display at Comdex. But several independent
sources have already confirmed its existence, so I'm sure we'll be hearing
more about it next quarter. I guess this is just one of many topics that
you won't find more substantial discussion about, folks who have heard stuff
aren't at liberty to repeat it.
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

All true wisdom is conveyed in one-line witticisms.
Newsgroups: comp.sys.atari.st.tech
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon '030 BUS: 16 or 32 bit?
From: J.J. Lehett <JJL101@psuvm.psu.edu>
Date: Mon, 16 Nov 1992 13:21:02 EST
Organization: Penn State University

In article <1992Nov13.230009.6192@prime.mdata.fi>, paetau@mits.mdata.fi (Rasmus
Paetau) says:
>
>In article <1992Nov11.204525.11194@rmece49.upr.clu.edu>
>raist@rmece02.upr.clu.edu (Ricardo Hernandez) writes:
>>   Reading from the above converstion, it looks like the Falcon
>>68030 bus to memory is:
>>
>>   * 16 bit wide
>>   * can't do the 68030's burst mode
>>
>>   Can someone with real Atari specs clarify this?
>>
>>- Raist
>>
>
>All "real" Atari specs say that the bus is 32-bit wide, and Quick
>Index gives results of about 50% of a TT, which sounds reasonable as
>the TT has 2x Falcon's clock frequency. I don't think this would be
>possible with a 16-bit bus. I still believe the Falcon has a 32-bit
>wide data bus.
>
>--
>-----------------------------------------------------------------------
>| Rasmus Paetau (paetau@mits.mdata.fi) | Waiting for the Atari Falcon |
>-----------------------------------------------------------------------


      Well, not to add fuel to the fire, but...

      In the latest issue of Current Notes, Dave Small says, and I quote:

      'It's a 16 MHz 68030 on a 16-bit bus (NOT 32 bit, contrary to Atari's
       spec's....'
------------------
J.J. Lehett     : Atari's, puzzles, games, chaos, fractals, math....

  - Work: JJL101@psuvm.psu.edu           Penn State CAC
  - Genie: J.LEHETT2
  - Delphi: JLEHETT@delphi.com
From: paul@jupiter.ame.arizona.edu (Paul Harris)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: TOS 2.05 vs 2.06 ?
Date: 20 Nov 92 19:26:29 GMT
Reply-To: paul@jupiter.ame.arizona.edu
Distribution: world,local
Organization: University of Arizona

In article 27791@csi.uottawa.ca, cbbrowne@csi.uottawa.ca (Christopher Browne) writes:
> In article <1992Nov19.194812.10824@newshost.lanl.gov> hutch@bellman.lanl.gov writes:
> >OK, here's an easy one.  Someone asked me the other day what the differences
> >between TOS 2.05 and 2.06 were.  I understood there were just a couple of
> >minor bug fixes but is there more?  Does 2.05 support the 1.44Mb format?
> >Just curious so I'll have the right answers the next time.
> 
> a) Yes, it'll support READING 1.4MB format.
> b) No, it won't support FORMATTING 1.4MB disks.
> 

I must disagree.  I have 3.05 in my TT (~2.05 in an ST) and after flipping a dip
switch (which can be done via a CPX) the "FORMAT FLOPPY" command displays a high-
density option along with single sided/double sided.  (But unfortunately for me,
all this does is make griding noises in my floppy since I don't have a high-
density drive :(


-Paul Harris                       @ @ 
paul@jupiter.ame.arizona.edu      \___/
From: jornmoe@fredrik.atari.no (Joern Moe)
Newsgroups: comp.sys.atari.st.tech
Organization: Atari Corp. Scand. AB (Norway)
Subject: Re: Falcon '030 BUS: 16 or 32 bit?
	<92321.132102JJL101@psuvm.psu.edu>
	<1992Nov17.050651.18469@rmece49.upr.clu.edu>
Reply-To: jornmoe@fredrik.atari.no
X-Software: HERMES GUS 1.03 Rev. Apr 14 1992
Date: Tue, 17 Nov 1992 22:56:48 MET

Ok, sorry about this guys, but here's the final facts:


  Date: 17 Nov 92 07:02:23 EST
  From: Wilfred Kilwinger <72347.2124@CompuServe.COM>
  Subject: Want to get something cleared up....
  To: >INTERNET:jornmoe@fredrik.atari.no

  >There's a lot of confusion going on at comp.sys.atari.st.tech about the
  >Falcon bus: Does it have 16 or 32 bit databus (CPU <-> memory)?

  This is what John Townsend (Atari Corp) said on GEnie:
  --------------------------------
  Atari-ST RoundTable
  Category 14,  Topic 20
  Message 73        Mon Nov 16, 1992
  TOWNS [John@Atari]           at 15:01 EDT
 
  Once and for all..


  The Falcon030 has a 24bit Address Bus and a 16bit Data Bus. The
  expansion port on the machine represents that bus.


  The Falcon030 can have a minimum of 1 meg of RAM and a maximum of
  14 megs of RAM. Possible RAM configurations are 1meg, 4meg, or 16
  megs of RAM.


  -- John Townsend, Atari Corp.
  ------------------------------
  Note that the Apple LC and the Classic II use the same trick and some
  chips do have full 32bit access like the video logic.
 
*****************

Now, that should settle the discussion on wheter it has 16 or 32 bit bus, but 
it will certainly not settle the frustration among some of you Atarians now:-/ 
But remember: with its low price, the Falcon 030 is quite uniq anyway!!

And while we are at it with facts from reliable sources:

  >There just appeared a roumor about the reason for the delay of Falcon. The 
  >roumor states that an Atari official (in europe som place) said that the 
  >reason for delay was that new video-modes were added (redesigning of video-
  >hardware) to see to that the Falcon had better spesifications than Amiga 
  >1200!
  >Do you have anny coments on this roumor (that I may quote to internet)?

  Yes, 100% nonsens.

  Regards,

  Wilfred

-- 
  _______________________________________________________
 / Joern F. Moe /  All above is my own personal opinion! \
/ Oslo, Norway /  Any lack of opinion above is also mine! \
-----------------------------------------------------------