HDTenEightyP/NetNews huggingface dataset:
From: mcarrico@terapin.com (Michael Carrico)
Newsgroups: comp.sys.atari.st.tech
Subject: Comparing Strings in 68000 Assembly
Date: 9 Oct 92 16:03:30 PST
Organization: BBS

I'm a programmer in various different languages on the ST, but one langauge I
am learning at this point is 68000 Assembly. I think I have the hang of reading
single characters and printing them to the modem or to the screen.
 
I am working on a project that started out as a "Chat Mode" program for a
friend of mine, for his BBS, and after he found a program, I decided to make it
into something different. I have a small VT52 Terminal Emulator program written
in Assembly langauge. I talked with my friend and we are discussing taking that
program and re-arranging it so the single key routine reads a string instead.
The over-all goal is to make the chat mode one procedure in an online adventure
game..I.E. The Local sysop can interrupt the player with say the F1 key.. and
chat with him..then hit it again and the player resumes playing..anyway I'm
finished with the Chat mode part, but now we need a routine that can read a
string and compare it with some common commands, such as "North" or "Look" or
"Open Door" These type..
 
Anyway, I found some routines to read a string using GEM, but it does'nt trap
control C, so I decided to attempt to write my own variable length readstring
routine. It takes one character at a time and adds it to a buffer, then when
the user hits return, it ends adding to the buffer, and compares the buffer to
the string I want.
 
Well I pretty much have the readstring part, but as soon as I compare the
string..(exit from inputting) I get 2 bombs and it exits.. Addressing Error.
 
Well.. Here's the string compare assuming A1 holds the starting address of
string 1 and A2 holds the starting address of string 2..
 
This is my compare routine..can someone please give me a hint as to want I am
doing wrong? 
 
=========================================================================
 
 ST D6      ;Set $FF to D6 we are using this as a True/False Register
 CLR.W D7   ;Set $00 to D7 we need a clean slate for a character counter
LOOP CMPM.B (A1)+,(A2)+  Compare the bytes of each and increment pointer
     BNE MISMAT          If they are different, then string does'nt match
 TST.B   -1(A1)          Did we reach a Null Byte ? (End of string)
 BEQ ENDOK               If we did then both are null, so end..
 ADDQ.W #1,D7            We tested one byte so far, so add 1 to the count!
 BRA LOOP                Branch back up and loop
MISMAT CLR.B D6          Strings don't match so make D6 False ($00)
ENDOK  ...               We continue here
 
Ok soo using that I should be able to compare byte by byte right?
 
What am I doing wrong?
 
ST MASTER
Newsgroups: comp.sys.atari.st.tech
Subject: Can IRQ exceptions malloc memory ? (&using IPL7)
From: 8918927y@levels.unisa.edu.au
Date: 15 Oct 92 09:40:18 +0930
Organization: University of South Australia

Gday
	On the subject of TSR's malloc'ing memory - can hardware interrupt
exceptions in supervisor mode also malloc memory ?.. I'm trying to get a
exception routine working that calls a Lattice 5.06.01 malloc call (in
the library, but gets bus errors half way through...).. Should I be
calling gemdos directly via a trap ?

	And - also is it safe to use IPL7 for hardware interrupts ?? -
or should I use IPL5 (I'm using an Atari MEGA ST)

Thanks
Kym
------------------------------------------------------------------------------
   "`Get back' I screamed, `I'm an Australian!'.I new this was a pretty
   lame excuse and prepared myself for the truth. `Australia is merely an
   Island of Antarctica' came the voice,`and of no further significance.'
               Suddenly I understood the secret of Atlantis."
--`What's Rangoon to you is Grafton to me' by Russell Guy. JJJ-FM circa 1978--
 Kym B Newbery : 8918927y@lux.levels.UniSA.edu.au : 4th Year electronic eng.
Newsgroups: comp.sys.atari.st.tech
From: tevans@unislc.uucp (Terry Evans)
Subject: HELP: Termcap problem when starting emacs
X-Newsreader: TIN [version 1.1 PL6]
Organization: Unisys Corporation SLC
Date: Wed, 14 Oct 1992 01:00:22 GMT

   When I attempt to run emacs after setting it up as instructed
I always receive an error that says that my TERM is not powerful
enough to run emacs.  I get the same error when I tried to run
the emacs binaries, complied source from gnu, and when I tried
to use the emacs version for MiNT.  Does somebody know what
it wrong off the top of their head?  If you need more detail
as to the errors please let me know.

tevans@cs.utah.edu

Newsgroups: comp.sys.atari.st.tech
From: thomasc@ms.uky.edu (Thomas Campbell)
Subject: Re: What makes the Screen Scroll *UP* ???
Date: Sat, 10 Oct 1992 23:00:32 GMT
Organization: University Of Kentucky, Dept. of Math Sciences

Ok, between Kevin and Michel I've gotten a good start towards wehre
I need to go but, I still haven't quite gotten it.  Michel suggested
that I ues the Line-A function but, he suggested it in Pascal.  I
should have said before that I'm using C.  I looked thru my libraries
on Line-A functions and I didn't find *anything* on how to shorten
the screen which is what I'm trying to do.   Let me try and explain
waht I'm trying to do a little better.  Whenever there is input on
line 20 I want it to be on line 20, when input comes in for the next
line (line 21) I want the screen to scroll up and have the input displayed
on line 20 again and so on and so on.  I'm using Laser C and as I've
said I've looked thru all my functions twice over.  Michel I think 
suggested that I Peek and Poke a location but, I don't think I can do
that in C... any suggestiosn will be greatly appreciated.

Alex
From: eker@loria.fr (Steven Eker)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Address of Atari timer
Date: 12 Oct 92 18:21:12 GMT
Organization: CRIN (CNRS) Nancy - INRIA Lorraine

In article <1992Oct6.151422.25180@crc.ac.uk>, pgardner@crc.ac.uk (Phil Gardner) writes:
|> Does anyone know the address of the internal timer of the 520STFM?
|>

$4BA-$4BD
 
|> Does anyone have an access routine for the timer from Atari Basic?

PEEK at it! (Assuming Atari Basic has a peek function)

Steven
Newsgroups: comp.sys.atari.st.tech
From: ridderbusch.pad@sni-usa.com (Frank Ridderbusch, STO SI211)
Subject: Re: Can't get gcc2.2.2 to work! (cpp-problem)
X-Md4-Signature: 827973696a43fee44f4e467375c3152b
Organization: Siemens Nixdorf Informationssysteme AG, Paderborn, Germany
	<RIDDERBUSCH.PAD.92Oct9085941@nozzle.sni.de>
Date: Sat, 10 Oct 1992 15:34:29 GMT

In article <RIDDERBUSCH.PAD.92Oct9085941@nozzle.sni.de> ridderbusch.pad@sni-usa.com (Frank Ridderbusch, STO SI211) writes:

   Even better, don't use GCC_EXEC_PREFIX at all on the ST. Since I've
   been using GCC, which is since version 1.36 (over 2 years now), I've
   set the variable GNUEXEC (similar to GNUINC and GNULIB). Please don't
                    ^^^^^^^
   create another version of GCC 2.2.2. There are already three, I know
   of (Bammi's original, Howard Chu's version with baserel and a version
   here in Paderborn,Germany compiled with MiNT libs).

Never trust your memory. GNUEXEC is still not right. It should be
GCCEXEC as Howard Chu already pointed out in another article. Every
time I want to name this env variable, I have to look it up in my
shell profile.
--
MfG/Regards

     /====                          Siemens Nixdorf Informationssysteme AG
    /    Ridderbusch        / ,    Abt.: STO SI211
   /                       /./    Riemeke Str.
  /=== /,== ,===/  /,==,  //     W-4790 Paderborn, Germany
 /    //   /   /  //   / / \    Tel.: (49) 05251-8-0
/    /     `==/\ /    / /   \  NERV:ridderbusch.pad

Email: ridderbusch.pad@sni-usa.com (America (North & South))
       ridderbusch.pad@sni.de      (Rest of world)
       
Newsgroups: comp.sys.atari.st.tech
From: hjv@phil.ruu.nl (Hendrik Jan Veenstra)
Subject: Re: Detecting the closing of an ACC from within an APP
Organization: Department of Philosophy, University of Utrecht, The Netherlands
Date: Mon, 12 Oct 1992 09:59:34 GMT

tony@microware.co.uk (Tony Mountifield) writes:

>In article <hjv.718670793@groucho.phil.ruu.nl> hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:
>> genius@sys6626.bison.mb.ca (Trevor Cordes) writes:
>> 
>> My (not completely blind) guess would be that this is not possible, but I
>> could be mistaken (if so, please let someone correct me). According to
>> the 'Atari Profibuch' WM_NEWTOP is the same as WM_TOPPED.

>No, they are different, but I am given to understand that WM_NEWTOP is
>only implemented on newer versions of TOS (1.2? 1.4? ...).

>As I understand it, WM_TOPPED is sent to an application to indicate that
>one of its windows (ID given) has become the top window, and WM_NEWTOP
>is sent to an application when one of its windows stops being the top
>window because another window has been topped. In other words, a window
>is only on top after getting a WM_TOPPED until it gets a WM_NEWTOP.

>Hope this is right - someone correct me it not. I think the information
>came from Tim Oren's 17-part Gem class articles, in a Q-and-A section.

Citing the Profibuch (thereby translating a Dutch translation of a German
book in English... :)

WM_TOPPED (21): This window becomes the active window.
	mbuf[3]: window handle
WM_NEWTOP (29): The window was activated. Seems to be identical with
                WM_TOPPED (21) !
	mbuf[3]: window handle
WM_UNTOPPED (30): The window will be inactivated (sp?) in a while. This
                message can be used to buffer the contents of the window
                somewhere in advance.
                Only with GEM >= 2.0!
	mbuf[3] window handle.


--
Hendrik Jan Veenstra  |  hjv@phil.ruu.nl  |   You look for your dreams in
Dept. of Philosophy   |                   |   heaven, but what the hell are
University of Utrecht |                   |   you supposed to do when they
The Netherlands       |                   |   come true...?
Newsgroups: comp.sys.atari.st.tech
From: mattera@rtsg.mot.com (Michael Mattera)
Subject: Any articles on Falcon?
Organization: Motorola Inc., Cellular Infrastructure Group
Distribution: net
Date: Thu, 8 Oct 1992 15:55:44 GMT

Are there any articles that give the Falcon's Spec's?
What magazines are they in? Do the Atari dealers have
any docs yet?

					mike

Newsgroups: comp.sys.atari.st.tech
From: 7103_2622@uwovax.uwo.ca (Eric Smith)
Subject: Re: VT52 variables? (was: What makes the Screen Scroll *UP* ?)
Organization: University of Western Ont, London
Date: Mon, 12 Oct 1992 15:13:59 GMT

In article <1992Oct12.001444.160007@rrz.uni-koeln.de>, aeg03@rrz.uni-koeln.de (Jan T. Kim) writes:
> In <2XJesB1w165w@ersys.edmonton.ab.ca> mforget@ersys.edmonton.ab.ca (Michel Forget) writes:

>>To further complicate matters, I found that I could not access the Line-A
>>variables through Personal Pascal so I had to play with the memory locations
>>themselves, which is not a good thing to do.
>>Anyway, the WORD located at $2AB2
>>holds the number of lines that the screen is. 

> Where did you get this information  (about  the  location)  from?
> And,  is there also a location where the number of characters per
> line for the vt52 is stored?

Before everyone starts swapping "peeks" and "pokes":
Michel gave the location *for one particular version of TOS*. I would
be very surprised indeed if it is the same for all versions of TOS;
in fact, it may even be different for different language versions of
the same version of TOS. The line A variables have never been guaranteed
to be fixed in one location.

The number of characters per line is stored at offset -44 from the
base of the line A variables, and the number of rows on the screen
is at offset -42. Actually, both of these are 1 less than the number,
i.e. for an 80x25 screen linea0()-44 will hold 79 and linea0()-42
will hold 24. How you get the line A base address depends on your
language/compiler; in C, with the MiNT libraries, you do:
    #include <linea.h>
    base = linea0();

Using these variables to change the number of lines (e.g. to provide
a status line for a terminal program) is quite dodgy. It will almost
certainly break under MultiTOS, for example, or under MiNT+TOSWIN
(where your program is no longer running on the whole screen, but
rather is in a GEM window).

Someone suggested using the top line as a status line -- that's
probably the easiest "clean" way (you just let the top line scroll
off and then redraw it). Even better is to put your program into
a GEM window and manage the VT52 emulation yourself, but obviously
that's a lot more work. (It does have the advantage that once the
basic code is written, changing it to do VT100 or some other emulation
would be quite easey.)
--
Eric R. Smith                     email:
Dept. of Mathematics            eric.smith@uwo.ca
University of Western Ontario

Newsgroups: comp.sys.atari.st.tech
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Subject: Event dispatching
Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Wed, 14 Oct 92 20:09:43 GMT

Hi everyone,

in the program I'm currently hacking there will be  windows  with
different  contents.  This  necessitates two dispatching steps in
event handling, one to  branch  to  the  procedure  handling  the
occurring  event,  and  the  second  to  branch  to the procedure
handling the event for the contents of the affected  window.  The
following chunk of GFA code illustrates the situation:

PROCEDURE check_event
  SELECT MENU(1)
  CASE 10
    @menu
  CASE 20
    @redraw(MENU(4),MENU(5),MENU(6),MENU(7),MENU(8))
  CASE 21
    .
    . (other window events)
    .
  ENDSELECT
RETURN
'
PROCEDURE redraw(w_handle&,x&,y&,w&,h&)
  SELECT @contents(w_handle&)    !function contents(w_handle&) returns
    '                             some int describing the contents
    '                             of the window with that handle.
  CASE 1
    @redraw_contents1(handle&,x&,y&,w&,h&)
  CASE 2
    @redraw_contents2(handle&,x&,y&,w&,h&)
  CASE 3
    .
    . (other window types)
    .
  ENDSELECT
RETURN

For those unfamiliar with GFA basic, MENU(1) ... MENU(8) contains
the AES message buffer after an AES message event.
The annoyingly unelegant part of this is that the dispatching for
window  types  must  occur  for  a  bunch  of  other  events  too
(arrowing, sizing, sliding etc.). Thus, the  procedures  handling
those  other  events are all of the same dispatcher type like the
sample  redraw()  procedure  above,   in   other   words,   there
necessarily is a considerable amount of redundancy in my code. My
question is, do I overlook a way to avoid this?
Another silly  complication  is  that  a  bunch  of  window  type
specific  reactions to events (e.g. to slider events) necessitate
a complete redrawing of the affected window. To do  this,  I  can
either hack in a procedure redraw_all() like this:

PROCEDURE redraw_all(w_handle&)
  LOCAL x&,y&,w&,h&
  ~WIND_GET(w_handle&,11,x&,y&,w&,h&)
  WHILE w&>0 or h&>0
    @redraw(w_handle&,x&,y&,w&,h&)
    ~WIND_GET(w_handle&,12,x&,y&,w&,h&)
  WEND
RETURN

Then, the type of the window will be determined during each  call
to  the  redraw()  procedure, which is superfluous as the type is
already known. The only way to avoid this is to write a bunch  of
procedures  of  the  type redraw_all_contentsx(), which then call
the corresponding redraw_contentsx() procedures. But  that  would
mean a bunch of almost identical procedures again.

Thanx for reading through all this stuff,

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  >=-----*
From: whitcomb@aurs01.uucp (Jonathan Whitcomb)
Newsgroups: comp.sys.atari.st.tech
Subject: AdSpeed AdVice?
Date: 15 Oct 92 13:45:50 GMT
Distribution: na
Organization: Alcatel Network Systems, Raleigh NC

I've just ordered AdSpeed to crank my Mega ST2/4 up to 16 MHz.  Does
anyone who's performed this operation have any advice on installation,
i.e. is there something you know that they left out of the installation
instructions?  

-Jonathan

**********************************************************************
Jonathan Whitcomb                    UUCP: <whitcomb%aurgate@mcnc.org>
Alcatel Network Systems              Delphi: JBWHIT
Raleigh, NC                          GEnie: J.WHITCOMB3        
Newsgroups: comp.sys.atari.st.tech
From: grier@bnr.ca (Brian Grier)
Subject: Re: Are 100ns DRAMs too slow for an 1040ST ?
Keywords: DRAM Memory
Organization: BNR
Date: Wed, 07 Oct 1992 13:43:27 GMT

I've heard of this problem before. If memory serves me the problem
is with your MMU chip and/or the 5vdc power supply. Some early MMUs
can not drive 32 chips. Also if your 5vdc is below 4.7 volts some
memories seem to balk.

My 520ST is upgraded to 2.5meg with a Z-ram board using 100ns chips.
The only time I had a problem was when I also tried to use a Spectre
GCR. The system sometimes wouldn't even come up. I replaced the
power supply and everything works great now.

I would call BEST Electronics and ask them. They sell MMUs and better
power supplies. I do not have their phone number here. I'll check at
home.

Brian
From: bpat@cs.mcgill.ca (Patrick BETREMIEUX)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: What makes the Screen Scroll *UP* ???
Date: 10 Oct 92 22:08:48 GMT
Organization: McGill University, Montreal, Canada

In article <1992Oct8.202714.13324@ms.uky.edu> thomasc@ms.uky.edu (Thomas Campbell) writes:
>What makes the screen scroll up?  I"ve been working on this program
>and I want to have an input line on line 22-23 while still accepting 
>input on line 20 and above.  (It's a modem program)  Do I have to do
>this thru screen flipping or what? I"m a pretty experienced programmer
>but, this has completely stumped me.  (An easy way to do it)  I remember
>with the *old* Atari 800.. :) that there was a special graphics window
>that I could have used but, how do I do this now?
>
>alex

1) your program will have to check which line the cursor is on before echoing
   it. You must then keep track of ALL characters coming in (And take care to
   work with various ESC sequences that may move the cursor around)

2) If you are at line 20 and you want to add a line, then do:
   ESC-Y-(32+24)-(32+79)      {That's to place the cursor at the last
                               possible place}
   (13)                       {To scroll up one line}
   ESC-Y-(32+20)-(32+0)       {place at first char of input line}
   ESC-L                      {insert a line}
   ESC-A                      {go up}
   echo whatever you want ...

This will cuase the whole screen to go up one line, and then the input line
will scroll down one line. You can then echo whatever you want.

If you need a list of the vt52 escape sequences, just ask me. (like reverse
video for some information line)

Hope this helps.

					Patrick.
Newsgroups: comp.sys.atari.st.tech
From: nino@vmars.tuwien.ac.at (Marinos Yannikos)
Subject: Re: VT52 variables? (was: What makes the Screen Scroll *UP* ?)
Organization: TU Wien, Vienna, Austria
Date: Tue, 13 Oct 1992 12:05:17 GMT

bpat@cs.mcgill.ca (Patrick BETREMIEUX) writes:
: In article <7akisB1w165w@ersys.edmonton.ab.ca> mforget@ersys.edmonton.ab.ca (Michel Forget) writes:
: >
: >I received the information from a user on the Forem Net in the Programmer's
: >Conference.  I cannot remember the name of the user, but I do remember how he
: >did it.  He disassembled the Bconout() function and traced it to see what it
: >was doing.  I know nothing about assembly, though, so I really cannot tell you
: >more.  There should be a variable for the number of columns, though, if there
: >isone for the number of rows.
: >
: ><<  ------------------------------------------  >>
: ><<        mforget@ersys.edmonton.ab.ca          >>
: ><<  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  >>
: ><<               Michel Forget                  >>
: ><<   The Key:  Spirit over mind over matter.    >>
: ><<  ------------------------------------------  >>
: >
: 
: On TOS 1.2, I have:
: 
: $2910 = maximum cursor line
: $291E = current cursor column
: $2920 = current cursor line
: 
: and some others like color and cursor visibility ...
:
ARGHHH!!!! Don't use such absolute addresses! If you really want to use
Line-A variables (which is still very bad practice) at least use an offset
from the address you get in A0 when you execute a "dc.w $a000" ...
IMHO, the best way to implement such a status line is by using WINDOWS
and the info line provided. After all, we have MultiTOS coming up,
and noone will want to use another single-task program, especially
if it's a terminal program (what I suppose you want to write).

: 					Patrick BETREMIEUX
: 					bpat@binkley.cs.mcgill.ca
: 
: PS. I still think the best way is what I posted first. Use vt52 ESC codes
: to scroll around !!!
:
Marinos Yannikos

Newsgroups: comp.sys.atari.st.tech
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Subject: Re: Event dispatching
Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Fri, 16 Oct 92 13:24:33 GMT

In <hjv.719146981@groucho.phil.ruu.nl> hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:

>aeg03@rrz.uni-koeln.de (Jan T. Kim) writes:

>>Hi everyone,

>>in the program I'm currently hacking there will be  windows  with
>>different  contents.  This  necessitates two dispatching steps in
>>event handling, one to  branch  to  the  procedure  handling  the
>>occurring  event,  and  the  second  to  branch  to the procedure
>>handling the event for the contents of the affected  window.  The
>>following chunk of GFA code illustrates the situation:
>[... long article deleted ...]

>Use C - make a structure that contains pointers to all the functions 
>necessary for window-handling and swap pointers depending on the 
>current window. Then write *one* generic window-handling function.
>Piece of cake... in C :-)
>Sorry, just couldn't resist...

Actually, the procedure check_event()  which  I  outlined  in  my
original  posting  is  almost exactly the generic window-handling
function you  suggest.  I  don't  see  why  it  should  make  any
difference  whether  one  branches to the appropriate function by
swapping pointers or by a SELECT-CASE construct.  The  number  of
structures  containing  pointers can't be smaller than the number
of SELECT @contents(w_handle&) constructs.
The difference I see between your suggestion and  my  program  is
that  you're  dispatching for the window type first, then for the
AES window event. So, would you say it's better to do things this
way  round?  I  always  have  thought the sequence of dispatching
steps I chose is better because  one  has  to  dispatch  for  all
window  events  in  any  case,  but  some  window events (such as
WM_FULLED) don't necessitate full dispatching for window types.

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  >=-----*
Xref: sparky comp.sys.atari.st.tech:5192 comp.sys.atari.st:15209