Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Tricorder simulator

78 views
Skip to first unread message

Steven D Ourada

unread,
Dec 31, 1992, 5:09:33 AM12/31/92
to

In this message:
Tricordr documentation
uuencoded tricordr executable
Tricordr assembly source
Tricordr user RPL source


---------------- Cut here. Tricordr documentation follows. ----------------


Copyright 1992 Steven Ourada Freeware

TRICORDR
========

What it is
----------

This is a silly little program to simulate the 'Tricorder' devices used on
Star Trek.


How to use it
-------------

To use TRICORDR, download it into a convenient directory, take off the
plastic cover over the infra-red pair on your 48, and execute TRICORDR.
When you bring the front of the 48 close to some object, the speaker will
repeatedly beep. Wow, lot's of fun, eh?

When the excitement dulls, press a key to get out of the program.


How it works
------------

Nothing too complicated: a small assembly language code segment pulses the
IR emitter, and checks the detector to see if there is a reflection. It reports
this back to the user-RPL code that beeps if there was a reflection.

Don't be worried that this will drain your batteries; the IR LED is only on for
about 20 microseconds for each 10 milliseconds.


I disclaim it
-------------

This is Freeware, copy it freely as long as you give credit where it's due.
There is NO WARRANTY with this software as it is provided to you with no charge.


That's it
---------

Keep in mind that this is my first attempt at using Saturn assembly and my
first HP48 program to be posted to Usenet. :-) If you have any comments,
please mail me.

----------------- Cut here. uuencoded executable follows. --------------


--------------- Cut here. Assembly source follows. ------------------
; Copyright 1992 Steven Ourada Freeware

; Embedded assembly code to do "proximity check"
; Turn the IR on, check to see if it reflected, turn it off

include class.mac

rpl $02dcc ; DOCODE

pgmbeg
rpl pgmend-pgmbeg ; length of code

jsr save_regs

move.a #$11a,d1
move.1 (d1),a
bclr #0,a
move.1 a,(d1) ; clear IR detector bit

move.a #$11c,d0
move.1 (d0),a
bset #3,a
move.b a,c
bclr #3,c
move.1 a,(d0) ; turn IR emitter on

move.1 (d1),a ; read IR detector
move.1 c,(d0) ; turn IR emitter off (it's only on for ~20us)

bbs #0,a,reflec

noreflec
move.a #"0",d1 ; return a "0" in the string
exg.a d1,c
bra.3 stostat

reflec
move.a #"1",d1 ; return a "1" in the string
exg.a d1,c

stostat
push
jsr restore_regs
pop

move.a (d1),a ; assuming a string on the top of the stack
move.a a,d1
add.a #$a,d1
move.b c,(d1)

exit
jsr restore_regs
move.a (d0),a
add.a #5,d0
jmp (a)

pgmend
rpl $0312b ; SEMI

include class.sym


-------------------- Cut here. User RPL source follows. ---------------
@ Copyright 1992 Steven Ourada Freeware

@ 'Tricorder' simulator
@ Note that the assembly code must be inserted where shown for this program
@ to work properly.

\<<
"0"
DO
@ Assembly code inserted here
IF DUP "1" SAME THEN
200 .03 BEEP
END
UNTIL KEY
END
DROP DROP
\>>
--
-------
Steven Ourada -- sou...@iastate.edu

tricordr

Lutz Vieweg

unread,
Jan 2, 1993, 11:50:17 AM1/2/93
to
In article <sourada....@vincent1.iastate.edu>, Steven D Ourada writes:

> Copyright 1992 Steven Ourada Freeware
>
> TRICORDR
> ========

[...]


8) - Wow! - finally I see at least one guy is using my CLASS assembler -
hope you like it!

Yours very happy

Lutz Vieweg

PS: What version of CLASS are you using on which computer?

Steve VanDevender

unread,
Jan 4, 1993, 1:42:03 PM1/4/93
to
In article <prpes*T...@mania.RoBIN.de> l...@mania.RoBIN.de (Lutz Vieweg) writes:

In article <sourada....@vincent1.iastate.edu>, Steven D Ourada writes:

> Copyright 1992 Steven Ourada Freeware
>
> TRICORDR
> ========
[...]


8) - Wow! - finally I see at least one guy is using my CLASS assembler -
hope you like it!

Yours very happy

Lutz Vieweg

Oh. That's why the assembler source for TRICORDR is so weird.

Why didn't you use real AG mnemonics? It's really kind of
annoying that most, but not all, of the mnemonics and assembler
notation are the same. You can't assemble the file with STAR,
but it looks tantalizingly close. But instead of SETB, CLRB, and
CALL, you use BSET, BCLR, and JSR. Instead of "move.a @d1, a",
it's "move.a (d1), a". Instead of "#12345", it's "#$12345".

This is one of those cases where Yet Another Standard is a big
pain in the neck.
--
Steve VanDevender ste...@greylady.uoregon.edu
"Bipedalism--an unrecognized disease affecting over 99% of the population.
Symptoms include lack of traffic sense, slow rate of travel, and the
classic, easily recognized behavior known as walking."

ochealth

unread,
Jan 4, 1993, 7:14:27 PM1/4/93
to
In article <STEVEV.93...@miser.uoregon.edu> ste...@miser.uoregon.edu (Steve VanDevender) writes:

:In article <prpes*T...@mania.RoBIN.de> l...@mania.RoBIN.de (Lutz Vieweg) writes:
:
: In article <sourada....@vincent1.iastate.edu>, Steven D Ourada writes:
:
: > Copyright 1992 Steven Ourada Freeware
: >
: > TRICORDR
: > ========
: [...]
:
:
: 8) - Wow! - finally I see at least one guy is using my CLASS assembler -
: hope you like it!
:
: Yours very happy
:
: Lutz Vieweg
:
:Oh. That's why the assembler source for TRICORDR is so weird.
:
:Why didn't you use real AG mnemonics? It's really kind of
:annoying that most, but not all, of the mnemonics and assembler
:notation are the same. You can't assemble the file with STAR,
:but it looks tantalizingly close. But instead of SETB, CLRB, and
:CALL, you use BSET, BCLR, and JSR. Instead of "move.a @d1, a",
:it's "move.a (d1), a". Instead of "#12345", it's "#$12345".

One can speculate on Alonzo's mnemonics, but BSET, BCLR, JSR
etc. are all familiar Motorola mnemonics, same with $ for
hex.and same with the move.a (d1),a

So it look s like CLASS is much closer to a standard than
the AG mnemonics (which is disappointing to learn)


:
:This is one of those cases where Yet Another Standard is a big


:pain in the neck.
:--
:Steve VanDevender ste...@greylady.uoregon.edu
:"Bipedalism--an unrecognized disease affecting over 99% of the population.
:Symptoms include lack of traffic sense, slow rate of travel, and the
:classic, easily recognized behavior known as walking."


--
______________________________________________________________________________
oche...@unixg.ubc.ca


Steve VanDevender

unread,
Jan 4, 1993, 10:27:08 PM1/4/93
to
In article <1iajt3...@iskut.ucs.ubc.ca> oche...@unixg.ubc.ca
(ochealth) writes:

One can speculate on Alonzo's mnemonics, but BSET, BCLR, JSR
etc. are all familiar Motorola mnemonics, same with $ for
hex.and same with the move.a (d1),a

So it look s like CLASS is much closer to a standard than
the AG mnemonics (which is disappointing to learn)

So perhaps we should just program the Saturn in 68000 assembler?
The Saturn is not a 68000. I don't think you get the point,
which is indeed disappointing to learn.

What I object to is changing a few parts of a well-established
assembly language format while leaving others alone, introducing
unnecessary confusion and incompatibility. The changed mnemonics
are no better in terms of comprehensibility or notational
convenience than the originals. One should think very carefully
before introducing those kinds of changes, and be able to justify
them. Alonzo Gariepy did a lot better in inventing a new,
consistent set of Saturn mnemonics to use in place of HP's than
Lutz Vieweg did in gratuitously changing a few of Alonzo's
around for his assembler.

ochealth

unread,
Jan 5, 1993, 2:17:50 AM1/5/93
to
In article <STEVEV.93...@miser.uoregon.edu> ste...@miser.uoregon.edu (Steve VanDevender) writes:
>In article <1iajt3...@iskut.ucs.ubc.ca> oche...@unixg.ubc.ca
>(ochealth) writes:
>
> One can speculate on Alonzo's mnemonics, but BSET, BCLR, JSR
> etc. are all familiar Motorola mnemonics, same with $ for
> hex.and same with the move.a (d1),a
>
> So it look s like CLASS is much closer to a standard than
> the AG mnemonics (which is disappointing to learn)
>
>So perhaps we should just program the Saturn in 68000 assembler?
>The Saturn is not a 68000. I don't think you get the point,
>which is indeed disappointing to learn.

Who said 68000? Every goddam 68xx series microcontroller, 65xx series
uses the opcodes the way Lutz does them, while Alonzo is the one that adds
the quirk. The Saturn is a Saturn, so following your conservatism, maybe
we should use HP's mnemonics. Sounds like hypocrisy to me: if you want
to bitch about Lutz's mnemonics being different than Alonzo's, maybe
you should be bitching about Alonzo's being different than HP's.

I'm not the one who started second guessing the design motives of
of each instruction set (Alonzo's vs. Lutz's), you were.


>
>What I object to is changing a few parts of a well-established
>assembly language format while leaving others alone, introducing
>unnecessary confusion and incompatibility. The changed mnemonics
>are no better in terms of comprehensibility or notational
>convenience than the originals. One should think very carefully
>before introducing those kinds of changes, and be able to justify
>them. Alonzo Gariepy did a lot better in inventing a new,
>consistent set of Saturn mnemonics to use in place of HP's than
>Lutz Vieweg did in gratuitously changing a few of Alonzo's
>around for his assembler.

Following your reasoning, we could say that Alonzo was wrong to
have changed HP's mnemonics, after all, Alonzo's 'changed mnemonics


are no better in terms of comprehensibility or notational

convenience than the originals [HP's]', at least using any measurable,
objective set of criteria.

I happen to like Alonzo's mnemonic set, but that is a subjective opinion.
I don't think I'll switch to Lutz's, but it sort of mildly annoys me to
find out that Alonzo's mnemonics are the bastardized Motorola style,
and then you are griping about Lutz's being real Motorola style.

You accuse Lutz of 'gratuitously changing a few of Alonzo's around'.
For all we know, Lutz has been confined to the Fidonet wasteland
with a 300 bps modem, living in a shack in the Black Forest
for the past 5 years, and has never seen Alonzo's. Just because
they look similar, doesn't mean Alonzo is the one who invented
that style, and Lutz is the one who 'gratuitously' changed Alonzo's.
We all know Motorola, Rockwell had been using that style for years,
with all kinds of CPUs, controllers etc. Sheesh! Give the guy a break.

--
______________________________________________________________________________
oche...@unixg.ubc.ca


Lutz Vieweg

unread,
Jan 5, 1993, 4:10:48 PM1/5/93
to
In article <STEVEV.93...@miser.uoregon.edu>, Steve VanDevender writes:

> >
> > TRICORDR
> > ========
> [...]
>
>
> 8) - Wow! - finally I see at least one guy is using my CLASS assembler -
> hope you like it!
>

> Oh. That's why the assembler source for TRICORDR is so weird.

It looks very familiar to anyone who has programmed MOTOROLAs
great 68xxx processors before.... :)

> Why didn't you use real AG mnemonics?

I wrote CLASS before I knew anything about Alonzo's work.

I simply tried to make the assembler syntax as similar as possible to
MOTOROLAs syntax.

> This is one of those cases where Yet Another Standard is a big
> pain in the neck.

Well, you are right here, but I don't want to change all of my
code just because someone's assembler has become much more
popular than mine. And - of course - you can emulate the
AG syntax by using CLASS's macro-facilities if you like to.

cu, Lutz Vieweg

Steve VanDevender

unread,
Jan 5, 1993, 5:25:29 AM1/5/93
to
In article <1ibcmu...@iskut.ucs.ubc.ca> oche...@unixg.ubc.ca
(ochealth) writes:

Following your reasoning, we could say that Alonzo was wrong to
have changed HP's mnemonics, after all, Alonzo's 'changed mnemonics
are no better in terms of comprehensibility or notational
convenience than the originals [HP's]', at least using any measurable,
objective set of criteria.

Actually, Jan Brittenson recently mentioned one reasonably
objective criterion by which the Alonzo mnemonics are
significantly better than HP mnemonics: the HP mnemonic set is
highly context-dependent, in that the mnemonics must be
interpreted differently than symbolic expressions that often use
nearly identical syntax. On the other hand, more conventional
assembly languages clearly differentiate opcodes from operands,
which makes them easier to read. AG mnemonics are much more
conventional than HP's, and many people prefer using assemblers
with AG mnemonics because they consider them more notationally
convenient.

You accuse Lutz of 'gratuitously changing a few of Alonzo's around'.
For all we know, Lutz has been confined to the Fidonet wasteland
with a 300 bps modem, living in a shack in the Black Forest
for the past 5 years, and has never seen Alonzo's. Just because
they look similar, doesn't mean Alonzo is the one who invented
that style, and Lutz is the one who 'gratuitously' changed Alonzo's.
We all know Motorola, Rockwell had been using that style for years,
with all kinds of CPUs, controllers etc. Sheesh! Give the guy a break.

This is a very interesting defense, although one that is probably
wrong. I seriously doubt that Lutz can document that he came up
with this mnemonic all by himself without reference to the AG
mnemonics. There are too many similarities between his mnemonic
set and Alonzo Gariepy's.

Here's a restatement of what I feel the problem is. If you want
to share source code with others, you should be aware of what
languages are commonly available. Right now, for the Saturn
processor, HP's SASM or Jan Brittenson's STAR are the most
widely-available assemblers for the Saturn. It's bad enough
having two standards, although for me there is a clear choice
(obviously, I prefer STAR). I do not want to have to also obtain
Lutz Vieweg's CLASS or convert code from CLASS to STAR,
particularly when so little code is available for it. Especially
where programming tools are concerned, there is no benefit to
having a lot of different quirky variants, and programmers should
think about what standards they want to use and promote. I
reluctantly begrudge the existence of SASM, since HP did all
their Saturn development with it and were kind enough to release
it to the public. I feel that STAR is much better, both for
using the more sane AG mnemonic set and because it is available
in source code form and has been ported to a wide variety of
systems, unlike SASM which is currently only available for
MS-DOS. But I find it very frustrating that someone would invent
yet another assembler with a mutated version of AG mnemonics and
syntax without any regard for the compatibility problems it could
cause. Jan Brittenson was kind enough to poll people about
whether STAR and MLDL should use HP or AG mnemonics; that his
respondents recommended AG mnemonics indicates that the AG set is
not just some quirky individual format, but has a reasonable
level of support in the user community.

Lutz Vieweg

unread,
Jan 6, 1993, 3:05:32 PM1/6/93
to
In article <STEVEV.93...@miser.uoregon.edu>, Steve VanDevender writes:

> This is a very interesting defense, although one that is probably
> wrong. I seriously doubt that Lutz can document that he came up
> with this mnemonic all by himself without reference to the AG
> mnemonics. There are too many similarities between his mnemonic
> set and Alonzo Gariepy's.

This is really a ridiculous discussion - are you just searching
reasons to flame around or what the hell is your motivation?

I don't see any reason to justify myself against such obviously
wrong reproaches, so I tell you once and never again:

- When I programmed CLASS and CLDIS, I'd never heard of Alonzo
Gariepi or his work - I had no access to the net, and the
48sx was my first HP handheld.

Additionally, I don't have a version of STAR for my
amiga until now.

- The mnemonics I use(d) where inspired only by the Motorola ones -
I've been programming ML on their processors for several years.

- The similarities between Alonzo's mnemonics (which I would have
probably used if I'd known them before I startet CLASS) are
obviously resulting from their common predecessor...

> I do not want to have to also obtain
> Lutz Vieweg's CLASS or convert code from CLASS to STAR,
> particularly when so little code is available for it.

You don't have to do so, and so anything should be fine, shouldn't it?

To me it is not "so little code", and I don't want to convert
around 10000 source-lines into other mnemonics, even because
I've got no running assembler for them.

> But I find it very frustrating that someone would invent
> yet another assembler with a mutated version of AG mnemonics

This is, as I said before, absolutely untrue.


Please stop this unnecessary and unproductive discussion - and
get away with your reproaches.

cu, Lutz Vieweg

Steve VanDevender

unread,
Jan 6, 1993, 7:05:28 PM1/6/93
to
In article <Exsfs*1...@mania.RoBIN.de> l...@mania.RoBIN.de (Lutz Vieweg) writes:

> This is one of those cases where Yet Another Standard is a big
> pain in the neck.

Well, you are right here, but I don't want to change all of my
code just because someone's assembler has become much more
popular than mine. And - of course - you can emulate the
AG syntax by using CLASS's macro-facilities if you like to.

Or emulate CLASS's syntax by using STAR's macro facilities. Or,
in this case, just do a manual translation of the TRICORDR code.

Has anyone ever tried faking a call to a system RPL word by
stuffing an address into A.A and then entering the RPL main loop?
It seems like you could just push system RPL TRUE or FALSE on the
stack or user RPL's %1 or %0 rather than doing what the TRICORDR
code does now, which is modifying a string on the the stack.

**

unread,
Jan 10, 1993, 8:16:07 PM1/10/93
to

Lutz, do you have a list of Amiga programs for HP-48 development work? I
use a PC at work and loath having to touch the damn thing... Little Amy,
at home, is much more pleasent to work with and a lot more fun! If you
have any HP-48 development tools or support programs I'd like to take a
look at them!

Jim

-----------------------------------------------------------------------------
James Cook, P.E. - E. & C.S. Engineer - Internet: James...@nesbbx.rain.COM

// -| |--|/|--| |---------( )- = IF 1 AND NOT 2 AND 3 THEN 4
\X/ Amiga! 1 2 3 4
-----------------------------------------------------------------------------

0 new messages