🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.atari.st
Article #27386

VMSmail Gateway nondelivery notification

#27386
From: SDRRTRSDRRTRMRGATEMRGATE
Date: Sat, 27 Jun 1987 04:05
449 lines
19202 bytes
Delivery of this message through the Gateway had the following results:

	M_SIFVX1::BURROWS - invalid address

The original message follows:

 
From:	IN%"Info-Atari16@score.stanford.edu"@SDR@MRGATE
To:	BB_ATARI@M_DSAVX1@MRGATE@SDRRTR,
	BURROWS@M_SIFVX1@MRGATE@SDRRTR
Subject: Info-Atari16 Digest V87 #253
Received: from relay.cs.net by sdr.slb.com; Fri, 26 Jun 87 22:43 EDT
Received: from relay.cs.net by RELAY.CS.NET id ac29520; 26 Jun 87 22:10 EDT
Received: from score.stanford.edu by RELAY.CS.NET id aa09163;          26 Jun
 87 22:10 EDT
Date: Fri 26 Jun 87 15:20:11 PDT
From: Info-Atari16 Digest <Info-Atari16@score.stanford.edu>
Subject: Info-Atari16 Digest V87 #253
To: Info-Atari16 Distribution List: ;
Reply-to: Info-Atari16@score.stanford.edu
Errors-to:  Info-Atari16-request@Score.Stanford.EDU
Maint-Path: Info-Atari16-request@Score.Stanford.EDU

Info-Atari16 Digest   Friday, June 26, 1987   Volume 87 : Issue 253

This weeks Editor: Bill Westfield

Today's Topics:

                             68020/68881
                           Re: DCFORMAT UUE
           Re: True Multitasking, and some history lessons
                   Re: multiple applications in RAM
                      MWC error message ? - (nf)
                   Problems with PD UUCICO!? - (nf)
                       Re: I'm not dead yet....
                   This that and the next thing ...
                   Re: Intelligent database wanted
                    Re: MWC error message ? - (nf)
                 Re: This that and the next thing ...
                      Re: Megamax Utilities Disk
         Re: Comparison of C Compilers on Different Machines

----------------------------------------------------------------------

Date: Sat, 13 Jun 87 15:30:13 CET
To: info-atari16@score.stanford.edu
From: HAHN_K%DMRHRZ11.BITNET@wiscvm.wisc.edu
Subject: 68020/68881

To those who are listening: I understand that out there exists a number of
people who are able / willing to really hack around. Listen: the famous
german computer magazin c't (the 'german BYTE') will publish in it's next
issue (to appear around the 15th of july) a project that's intended to
help you replacing an 68.000 by an 68.020/68.881 - combination. They're
known to be decent people.
So long, Klaus.


-- Klaus Hahn.
University of MARBURG
D-3550 Marburg, West-Germany           <HAHN_K@DMRHRZ11.bitnet>

------------------------------

Date: 12 Jun 87 18:37:23 GMT
From: amdahl!drivax!holloway@AMES.ARPA  (Bruce Holloway)
Subject: Re: DCFORMAT UUE
To: info-atari16@score.stanford.edu

I used STRINGS to look through the DCFORMAT.UUE program that came down
the net - as I couldn't figure out what it did. Maybe a couple of words
of explanation would be in order when you post things????

(Also, it unARCed with errors, even after I removed the dollar signs ($)
from the end of each line. It looks interesting - but I can't get it to
unARC without errors.)

Anyway. DCFORMAT == Double Click Software Formatter, version 2.0 for mono
systems.

It has two Format options: Normal and Fast

Also, it seems to be able to put on a standard boot track, or one that makes
disks directly execute a file??? (called MAGIC Executable Boot).

It appears to be able to copy disks as well.

Hmmm... more discoveries. It seems that MAGIC refers the Magic Sac. Perhaps
it formats those disks - which would make it really useful. Maybe it even
copies files from one format to another.

Seems to be an enhancement of something called "The Formatter".

(The following is gleaned from the .RSC file - which unARCed so badly I
could barely make some of the words and phrases out).

Copies double or single sided MAGIC SAC disks. If allowed, lets you make
another copy of the same disk, instantly. Intelligently copies disks of any
format. (unprotected disks)

Writes a boot sector that can set BIOS time, cause cold reset, turn off
verify, set med rez, bypass hard disk bootup, or run COMMAND.PRG on
floppy bootup. Writes IBM DOS boot sector.

MAGIC Formats Fast MAGIC SAC. Fast or Normal. 80 or 82 tracks. 9 or 10 sectors.
single or double. A or B drive. MAGIC SAC disks in fast format!
Double sided or single sided!

In all cases, if you are not formatting the destination disk, DC Formatter
checks to see if both disks are similar. If you are going to format the
destination disk, DC Formatter will automatically format the destination or the
copy the same as the source disk.

Look ZENTH Term and ZENTH BBS, sS Bn.

For information, write:

Double Click Software
2502 Lemonwood
Houston,Tx 77038
-- 
Bruce Holloway - Terminal Netnews Addict    {seismo,sun}!amdahl!drivax!holloway
ALBATROSS, ATARI*TROS @ Plink                                ALBATROSS @ Delphi
                                >>> HI, KARL! <<<

------------------------------

Date: 13 Jun 87 15:40:43 GMT
From: ihnp4!cuae2!ltuxa!ll1a!ll1!nesac2!jec@ucbvax.Berkeley.EDU  (John Carter ATLN SADM)
Subject: Re: True Multitasking, and some history lessons
To: info-atari16@score.stanford.edu

Since this has turned into a discussion of Suns, windows, and
operating system design, perhaps it should be moved to comp.os.????
instead of being in comp.sys.m6809.
-- 

John Carter
AT&T Communications - Atlanta RWC
USnail:	3001 Cobb Parkway, Atlanta GA 30339
E-mail:	...ihnp4!cuea2!ltuxa!ll1!nesac2!jec
Voice:	404+951-4642
(The above views are my very own. How dare you question them? :-)

------------------------------

Date: 10 Jun 87 07:29:10 GMT
From: mcvax!jack@seismo.css.gov  (Jack Jansen)
Subject: Re: multiple applications in RAM
To: info-atari16@score.stanford.edu

In article <1288@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu.UUCP (braner) writes:
>[]
>
>Looking forward to the 2-meg machines of next year:  1 meg is just right
>for me now, but I could use 2 megs as follows:  Say 640K for the usual
>workspace, another 640K for a "shadow" machine, and the rest (768K) for
>a reset-proof RAMdisk in High RAM.  The idea is: you press a "hot key",
>and the complete TOS environment (the first 640K) gets copied into the next
>640K.  Next time(s) you press that hot key, the two 640K pieces get
>_swapped_.  That way you can run two separate applications in RAM, instantly
>switching back and forth.  The two can communicate via the RAMdisk (which
>should also work as a disk-cache...).

This touches on a problem that I encountered (and haven't solved yet):

How can you make sure that the current program is 'idle', i.e. not doing any
disk I/O, or something similar? It seems that this is necessary for a
swapping scheme to work.

My problem is more-or-less similar: I have an interrupt driven MIDI driver,
and packets come in, requesting disk blocks. So, I want to read the block, and
send it to the machine on the other side. However, how can I make sure that
the current 'real' program isn't doing any disk I/O?
-- 
	Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp)
	The shell is my oyster.

------------------------------

Date: 9 Jun 87 22:43:00 GMT
From: mcvax!unido!qtecmuc!ralph@seismo.css.gov
Subject: MWC error message ? - (nf)
To: info-atari16@score.stanford.edu

Hi ....
does anybody know the following error message of the MWC Version 1.0.4
(loader)
Ld: file name.o: bad relocation adress 0x......
Ld: file name.o: bad relocation adress 0x......
Ld: file name.o: bad relocation adress 0x......
Ld: file name.o: bad relocation adress 0x......
	...............
thanks
ralph  (...!seismo!unido!qtecmuc!ralph)

------------------------------

Date: 8 Jun 87 14:47:00 GMT
From: mcvax!unido!rmi!hikaru@seismo.css.gov
Subject: Problems with PD UUCICO!? - (nf)
To: info-atari16@score.stanford.edu

I have used the PD uucico program for about two days, and have encountered
the following problems.
(Not necessarily bugs in the program but rather 'operator stupidity'. If
so, please let me know.)

SLAVE Mode:
The modem initialisation string and the login sequence is sent to the 
screen and not to the RS-232 port.

MASTER Mode:
1. When the program is started with "uucico -r1", it prints a line for
   every system in l.sys and 'says' NO WORK, even though I have created
   work files with names according to the docs. 
   (ex.: crmi678 for the remote system rmi, or caltg954 for the remote
    system altger. Are these names correct, or what filenames have to be
    used?)

2. When the program is started with "uucico -r1 -ssysname", it calls the
   remote system specified, gets past login and Shere=sysname, sends some
   characters, and then hangs up.
   The uucico debugfile (PROTO) shows the following:
       startup (master): 1st msg = 'Shere=altger'
       startup (master): 2nd msg = RLOGIN
       MAIN:          state = O__
   ...

   uulog on the remote UNIX system (Sys V) says: 
   "FAILED (BAD LOGIN/MACHINE NAME)"

Ideas anyone?

------------------------------

Date: 8 Jun 87 18:06:51 GMT
From: mcvax!ukc!warwick!cvaxa!leilabd@seismo.css.gov  (Leila Burrell-Davis)
Subject: Re: I'm not dead yet....
To: info-atari16@score.stanford.edu

>
> I'd like to thank all of the kind people who have offered to take
> over the moderating task from me, HOWEVER, I have high hopes of
  ...
> C'est la vie, C'est la guerre, C'est la pomme de terre

I'm very pleased to hear that Turner is still of this world.  However, like
many other readers of comp.sys.atari.st, I've never been able to reap the
benefit of his efforts, because the sources and binaries groups never arrive
here.  All I can do is foam at the mouth when I hear about the goodies other
people can get.  Consequently, I am delighted at the reappearance of programs
in comp.sys.atari.st - long may it continue.
-- 
Leila Burrell-Davis, Arts E, University of Sussex, Brighton BN1 9QN, UK

Tel:    +44 273 606755  Ext. 2387
JANET:  leilabd@uk.ac.sussex.cvaxa
ARPA:   leilabd%uk.ac.sussex.cvaxa@cs.ucl.ac.uk
BITNET: leilabd%uk.ac.sussex.cvaxa@uk.ac
UUCP:   leilabd@cvaxa.uucp OR ...!mcvax!ukc!cvaxa!leilabd

------------------------------

Date: 9 Jun 87 14:31:16 GMT
From: mcvax!ukc!its63b!hwcs!neil@seismo.css.gov  (Neil Forsyth)
Subject: This that and the next thing ...
To: info-atari16@score.stanford.edu

Here some of my queries and discoveries about the ST ...

Neochrome
---------
The only version of Neochrome that I have is 0.5 which I got free with the
machine. While poking about in it (is this against the law? Yours or mine) I
found that it tries to load a file called "NEO.MCP". Since I didn't have this
file I assumed it was an authors hook "Master Control Program" ala TRON. I gave
it a 1K NEO.MCP file and exepected it to crash. Nope! MCP I reckon stands for
Multi Coloured Palette. I think the original palette is well organised but you
can change it using this feature by giving it a 512 word file of colour values.
Please excuse me if this has been documented in a later release as I have yet
to see a release version. Do any later releases support medium and high res
modes and what new features do they provide. I was interested in the animation
hook someone found one version.

Thrusteroids
------------
I have recently been investigating direct keyboard reading and found Megaroids
method rather interesting. The current keyboard chip only sends key data on the
control,alternate,left shift,right shift and any two other keys. If you play
Megaroids and hold Z and X down you can't thrust. Also since the keyboard vector
is switched at the start of the game you can play Thrusteroids:-
1. Select 1 game from the start menu
2. Hold down the thrust key '?'
3. Abort the game with F1
4. Restart the game and as long as you don't press '?' again its release code
   will never be sent the thrust will stay on.
The same effect can be achieved with other controls but are not as exciting.
Also notice that if you hold down and repeat a key before you start a game
the key click continues during the game even after being released. This is due
to the OS not getting the release code.

C & Assembler
--------
I am torn between two development systems. I have only recently (seems like I do
everything recently :-)) started learning C using the Megamax Compiler. I like
the Developers Kit AS68 assembler, which I have been using for over a year now,
but find the C impossible after using Megamax. I think the Megamax assembler
is trivial and not really intended for big assembly language programs. Having
said that, someone recently (!) sent a program to the net that was completely
written using the Megamax assembler. I take my hat off to him.
When I started using Alycon C after Megamax I was stunned by its policy on
carriage returns. I found that to terminate a scanf I had to use CTRL J! I
couldn't find any #defines governing that anywhere. Have I missed something
there? Ideally I would like to get my hands on a different/friendlier compiler
which will accept my AS68 object files during linking. Does MWC do this?
Will they ever produce an assembler?

New ROMS and BLITTERS
---------------------
Is anybody still talking about these? Since I like to write code that will work
on all ST's I wouldn't make use of the blitter and take the Sublogic approach
of rolling your own graphic routines. I therefore would like new && compatible
bug free ROMS.

Vectors
-------
Is there any way of OS independantly restoring the default vectors other than
resetting or switching off the machine? On my old BBC Micro the address of the
default vector table was freely availiable in all versions of the OS and
software protections made good use of it. I was reliably informed by Atari that
changing the keyboard vector can't be done safely without introducing some OS
dependance. I concluded that Megaroids does this and will only work on future
ST's if Atari are content with their current keyboard handling.
I for one am not but will suffer if they do change it.

GULAM
-----
Every time I try to use * for a wildcard I get the emacs [Mark set]
message. If I use the * on the keypad I get a weird X. I presume that Gulam
changes the keyboard mapping and that the new map makes * produce a character
zero thus mark set. Is this due to UK and US keyboard differences?

-------------------------------------------------------------------------------
"I think all right thinking people in this country are sick and tired of being
told that ordinary decent people are fed up in this country with being sick and
tired. I'm certainly not and I'm sick and tired of being told that I am!"
- Monty Python                            (Vote for the Silly Party on June 11)

 Neil Forsyth                           JANET:  neil@uk.ac.hw.cs
 Dept. of Computer Science              ARPA:   neil@cs.hw.ac.uk
 Heriot-Watt University                 UUCP:   ..!ukc!cs.hw.ac.uk!neil
 Edinburgh
 Scotland

------------------------------

Date: 10 Jun 87 10:40:37 GMT
From: mcvax!ukc!dcl-cs!bath63!pes@seismo.css.gov  (Paul Smee)
Subject: Re: Intelligent database wanted
To: info-atari16@score.stanford.edu

Sorry, should have mentioned, we're looking for something for personal home
use, and at 'personal home use software' prices.  The *really powerful*
packages that cost half as much as the machine did are not of practical
interest to us.  Things at 'serious home software' prices could be.

------------------------------

Date: 10 Jun 87 11:07:01 GMT
From: mcvax!unido!laura!@@seismo.css.gov  (Andreas Toenne)
Subject: Re: MWC error message ? - (nf)
To: info-atari16@score.stanford.edu

In article <19400003@qtecmuc.UUCP> ralph@qtecmuc.UUCP writes:
>Hi ....
>does anybody know the following error message of the MWC Version 1.0.4
>(loader)
>Ld: file name.o: bad relocation adress 0x......
>	...............
>thanks
>ralph  (...!seismo!unido!qtecmuc!ralph)

Hi Ralph,

I had this funny error myself lately. The reason was a weired c-statement:

while (... && func && ...) <- it should read func(), a typo!
The compiler didn't complain (of course), but the relocator died.
Could you send me your c-file name.c ?? Perhaps I'll find a similiar error.

	Greetings

	Andreas Toenne
	at@unido.uucp
D

------------------------------

Date: 10 Jun 87 13:27:11 GMT
From: mcvax!ukc!dcl-cs!bath63!pes@seismo.css.gov  (Paul Smee)
Subject: Re: This that and the next thing ...
To: info-atari16@score.stanford.edu

Yes, Gulam appears to remap the keyboard into a US keyboard.  (I presume this
is an attempt to 're-standardize' it in case something run previously has
munged it, but it's annoying.  I seem to recall that uemacs 3.7i did/does this
as well -- certainly one of the many uemacs'es around does.)

Please, folks, when you write keyboard-driven thingies, leave the flipping
keyboard alone -- if it's funny, it's probably funny because I like it that
way -- or at least provide an easy hook to allow me to set it up the way I like
it.  While I did have some 30 years of US keyboard use, I've been using UK ones
since I came here, and I **like** for all the keyboards I use to have the
special chars in the same place.

------------------------------

Date: 10 Jun 87 19:31:45 GMT
From: mcvax!ukc!dcl-cs!bath63!pes@seismo.css.gov  (Paul Smee)
Subject: Re: Megamax Utilities Disk
To: info-atari16@score.stanford.edu

I'd suggest you contact Megamax (whoever they are) directly.  I did that
with MetaComCo when I bought my MCC Assembler used, and they (for a very
tiny fee) transferred the original registratiion including rights to
support; and upgraded my copy.  If MegaMax don't have some similar policy
I'd be amazed.

------------------------------

Date: 10 Jun 87 19:40:09 GMT
From: mcvax!ukc!dcl-cs!bath63!pes@seismo.css.gov  (Paul Smee)
Subject: Re: Comparison of C Compilers on Different Machines
To: info-atari16@score.stanford.edu

I'd suggest (since you seem to use Lattice C already) that you quick go
get the latest upgrade to version 3.04 -- should be out now, I got mine
3 weeks ago.  I haven't formally measured it, but some quick and dirty tests
indicate that the math stuff has apparently been speeded up by an order
of magnitude, roughly (well, somewhere between and octal and a decimal
OoM, anyway).  Might well make you happier.

------------------------------

End of Info-Atari16 Digest
**************************
-------
Technical Details
Message-ID: <8706270503.AA27621@ucbvax.Berkeley.EDU>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ames!ucbcad!ucbvax!sdr.slb.COM"!"SDRRTR::SDRRTR::MRGATE::\"MRGATE\"

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ames!ucbcad!ucbvax!sdr.slb.COM"!"SDRRTR::SDRRTR::MRGATE::\"MRGATE\"
From: "SDRRTR::SDRRTR::MRGATE::\"MRGATE\"@sdr.slb.COM"
Newsgroups: comp.sys.atari.st
Subject: VMSmail Gateway nondelivery notification
Message-ID: <8706270503.AA27621@ucbvax.Berkeley.EDU>
Date: Sat, 27-Jun-87 00:05:00 EDT
Article-I.D.: ucbvax.8706270503.AA27621
Posted: Sat Jun 27 00:05:00 1987
Date-Received: Sat, 27-Jun-87 19:38:58 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 449