Anybody know where the software for the Cromemco Dazzler Games Package
(Kalideoscope, Life, etc.) might be hiding?

-J

You can get paper tape images here:

http://bitsavers.trailing-edge.com/bits/Cromemco/paperTapes/

Tom Lake

=====================
Posted through Grouply, the better way
to access your Yahoo Groups like this one.
http://www.grouply.com/?code=post

--- In altaircomputerclub@yahoogroups.com, "Andrew Kessel"
<akessel56@...> wrote:
>
> Are those .ptp files standard binary files, that one can upload
through a
> serial connection?

I have copies of the manuals for some of the Dazzler programs: Life,
Dazzlemation, Kaleidoscope, Dazzlewriter, Dazzle-Writer 512, and Tic
Tac Toe.  If you can't find them elsewhere online, I could probably
scan at least some of them.  They include program listings and a
simple tape loader program.

Looking at the tape loader, the tapes appear to be simple 8 bit binary
memory dumps starting at address 0.

Geoff Harrison.

--- In altaircomputerclub@yahoogroups.com, "Andrew Kessel"
<akessel56@...> wrote:

Are those .ptp files standard binary files, that one can upload

through a

serial connection?

I have copies of the manuals for some of the Dazzler programs: Life,
Dazzlemation, Kaleidoscope, Dazzlewriter, Dazzle-Writer 512, and Tic
Tac Toe. If you can't find them elsewhere online, I could probably
scan at least some of them. They include program listings and a
simple tape loader program.
Looking at the tape loader, the tapes appear to be simple 8 bit binary
memory dumps starting at address 0.

-- [ Happy New Year --- http://www2.applegate.org/~ragooman/ ]

--- In altaircomputerclub@yahoogroups.com, John Crane
<john_crane_59@...> wrote:
>
> So, it looks like they are binary images, not papertapes. 
> I can zap them straight in and not have to worry about special loaders.


The Dazzler paper tapes I have are just binary images.  There's no
leadin/leadout bytes, no encoding, no checksum, nothing.  I don't know
why the .ptp files have nulls, but my pape tapes don't have them.  The
Cromemco loader just sets HL to 0 (or 0x5000 for dazzlewriter), reads
a byte from the input port, writes it to memory, increments HL and
loops.  It looks like you can do the same thing with the .ptp files
after you strip the leading nulls.

Geoff Harrison.

MITS appeared to have releases two different styles of documentation binders,
seen here at
Dave Dunfield's site:

http://www.classiccmp.org/dunfield/altair/h/mits1.jpg

http://www.classiccmp.org/dunfield/altair/h/mits2.jpg

Does anyone recall which one came first?

-Mardy

Mardy-

The blue on white "Altair Age" binder  
( http://www.classiccmp.org/dunfield/altair/h/mits1.jpg ) was used for all early Altair manuals, until about the time that the 8800b was introduced, when MITS switched to classier looking blue binders with white and black lettering.

[ Happy New Year --- http://www2.applegate.org/~ragooman/ ]

Well, that picture would seem to prove me wrong.  Even if the photo
misrepresents what was really delivered to customers, it certainly
shows that those "Altair Systems" binders existed at the very
beginning.  I can only go by my experience as a MITS employee, and I
did see 8800 and 8800a models delivered with the other kind of
binder, so maybe they existed in parallel (I wasn't at MITS until
after the 8800a was introduced).  There's no doubt, though, that
the "systems" binder is much more scarce than the other, and it was
used for the WACC handouts.

Steve
===============================

--- In altaircomputerclub@yahoogroups.com, "Marden P. Marshall"
<mardy@...> wrote:
>
> Steve,
>
> Thank you for the detailed accounting.  I suspected that
the "Altair
> Age" binder was the original one, since that is what you see the
most
> of, although usually not in very good shape these days.  What made
me
> start to question this though is that you see the "Altair Systems"
> style manual used in one of the 8800 kit add photos
> (Altair_Kits.jpg).  I personally like the looks of the "Altair
Age"
> binder the best.
>
> -Mardy
>
> On Jan 6, 2009, at 12:52 AM, Steve wrote:
>
> > Mardy-
> >
> > The blue on white "Altair Age" binder
> > ( http://www.classiccmp.org/dunfield/altair/h/mits1.jpg ) was
used
> > for all early Altair manuals, until about the time that the
8800b
> > was introduced, when MITS switched to classier looking blue
binders
> > with white and black lettering. You can see an example at Tom
> > Sanderson's Virtual Altair site at
> >
http://www.virtualaltair.com/virtualaltair.com/vac_library.asp .
> > ICOM Microperipherals eventually came under MITS'/Pertec's roof,
and
> > Tom's site has an image of a typical iCOM binder too.
> >
> > The other blue on white binder that you referenced,
labeled "Altair
> > System",
> > (  http://www.classiccmp.org/dunfield/altair/h/mits2.jpg ) was
used,
> > as far as I know, only for special packages of information given
out
> > at some of the seminars at the World Altair Computer Convention
> > (WACC). They contained general information, talking points,
theory
> > of operation, and bits of architecture of the original 8800 and
RAM
> > board. These may also have been mailed out to potential customers
at
> > one time.  They're relatively rare.
> >
> > After Pertec acquired MITS, they began to distribute some
> > information in "PCC" blue on white binders. The hard disk
systems
> > and a few other items were also distributed in black on blue PCC
> > binders. Sorry, I can't find any handy examples.
> >
> > Besides the above, the ASDC/Peachtree business software manuals
were
> > different, usually saying "Altair Software" or "ASDC Software"
in
> > white on blue vinyl. There were a couple of variations. Here's
one
> > example:
> > http://www.digibarn.com/collections/articles/altairs-notes/
> > index.html .  Note that this example at Digibarn was found
> > containing reprints of MITS "Computer Notes" articles. Those are
not
> > the contents that were originally contained in this kind of
binder.
> >
> > Steve
> >
> > =====================================
> >
> >
> > --- In altaircomputerclub@yahoogroups.com, "mardy_marshall"
> > <mardy@> wrote:
> > >
> > > MITS appeared to have releases two different styles of
> > documentation binders, seen here at
> > > Dave Dunfield's site:
> > >
> > > http://www.classiccmp.org/dunfield/altair/h/mits1.jpg
> > >
> > > http://www.classiccmp.org/dunfield/altair/h/mits2.jpg
> > >
> > > Does anyone recall which one came first?
> > >
> > > -Mardy
> > >
> >
> >
>

--- In altaircomputerclub@yahoogroups.com, John Crane
<john_crane_59@...> wrote:
>
> Looking at Kaleidoscope and ignoring initial nulls, I see:
>  
> 31 00 01 3E 81 ....
>  


Well, the Dazzler is up and running!

Kalideoscope is pretty amazing for 70's tech.

I haven't managed to get Life to work though - just get one blue
cell.  I have the manual, but still no joy.  It's communicating with
the console on the standard port 01, no problem there.  I trimmed
the NULLS from the papertape images, but left a string terminating
NULL, then tried leaving the BELLs (07h) chars at the end (an
annunciator telling the TTY user the tape has loaded?)

I did find something unusual.  Although I did not disassemble it, I
noticed the first three bytes was a jump command the very next
instruction.  Maybe there's a reason for this somewhere in the code.

-John

31 00 01 loads the stack pointer with what needs to be an area of ram
to use for calls, returns, pushes and pops.  It works from the loaded
area downward.  It is not a jump.

Rich

LXI  SP,word  LD  SP,word  31word  SP <- word

--- In altaircomputerclub@yahoogroups.com, "john_crane_59"
<john_crane_59@...> wrote:
>
> --- In altaircomputerclub@yahoogroups.com, John Crane
> <john_crane_59@> wrote:
> >
> > Looking at Kaleidoscope and ignoring initial nulls, I see:
> >
> > 31 00 01 3E 81 ....
> >
>
>
> Well, the Dazzler is up and running!
>
> Kalideoscope is pretty amazing for 70's tech.
>
> I haven't managed to get Life to work though - just get one blue
> cell.  I have the manual, but still no joy.  It's communicating with
> the console on the standard port 01, no problem there.  I trimmed
> the NULLS from the papertape images, but left a string terminating
> NULL, then tried leaving the BELLs (07h) chars at the end (an
> annunciator telling the TTY user the tape has loaded?)
>
> I did find something unusual.  Although I did not disassemble it, I
> noticed the first three bytes was a jump command the very next
> instruction.  Maybe there's a reason for this somewhere in the code.
>
> -John
>

Rich,

You are correct for Kalideoscope, that was my initial post.  I guess I
wasn't too clear in my second post.  I was talking about the
game "Life".  The fist five bytes are:

C3  03  00  31  00

And, assuming the programs runs from 0000, it should immediatly jump
to the very next instruction, the 31 (LXI).

Maybe there's a reason for it, but it sure looks like a waste of three
bytes.

-John

--- In altaircomputerclub@yahoogroups.com, "Rich Whiteman"
<richwmn@...> wrote:
>
> 31 00 01 loads the stack pointer with what needs to be an area of ram
> to use for calls, returns, pushes and pops.  It works from the loaded
> area downward.  It is not a jump.
>
> Rich
>
> LXI  SP,word  LD  SP,word  31word  SP <- word
>

Rich,

You are correct for Kalideoscope, that was my initial post. I guess I
wasn't too clear in my second post. I was talking about the
game "Life". The fist five bytes are:

C3 03 00 31 00

And, assuming the programs runs from 0000, it should immediatly jump
to the very next instruction, the 31 (LXI).

Maybe there's a reason for it, but it sure looks like a waste of three
bytes.

-John

--- In altaircomputerclub@yahoogroups.com, "Rich Whiteman"
<richwmn@...> wrote:
>
> 31 00 01 loads the stack pointer with what needs to be an area of ram
> to use for calls, returns, pushes and pops. It works from the loaded
> area downward. It is not a jump.
>
> Rich
>
> LXI SP,word LD SP,word 31word SP <- word
>

Good point, it could be a remnant from an assembly language
template.  The programmer just forgot to remove it, as this
application does not have any data in that area.  All the data seems
to be grouped at the end.

I also found that the code only contains ascii compares for F, S,
and Y.  However, my manual says the program takes many more one
letter commands.  In fact, when I looked for the command C (to move
the cursor) the ascii code for C (43 upper 63 lower) doesn't appear
anywhere in the code, so that also eliminates a jump table holding
command chars.

Of course, there could be some really funny business going on in the
code (derived command codes, etc).  But the game of Life is so
simple, I don't see the need for it, especially in something like
the command processor.

Has anyone had any luck with the life program from bitsavers?

http://bitsavers.trailing-edge.com/bits/Cromemco/paperTapes/


-John






--- In altaircomputerclub@yahoogroups.com, "Derek J. Lassen"
<xl198CV56@...> wrote:
>
> IIRC, the hex file format had no transfer address, and assumed
> x'0000'. Many programmers put constants and jump tables at the
> beginning. So, we usually coded :
>           ORG   0
>           JMP    Entry
> Entry  EQU   *
>
> as the first three lines.
>
> (s) Derek
> Altair #000000067
>
> At 02:18 AM 1/12/2009 +0000, you wrote:
>
> >Rich,
> >
> >You are correct for Kalideoscope, that was my initial post. I
guess I
> >wasn't too clear in my second post. I was talking about the
> >game "Life". The fist five bytes are:
> >
> >C3 03 00 31 00
> >
> >And, assuming the programs runs from 0000, it should immediatly
jump
> >to the very next instruction, the 31 (LXI).
> >
> >Maybe there's a reason for it, but it sure looks like a waste of
three
> >bytes.
> >
> >-John
> >
> >--- In
> ><mailto:altaircomputerclub%
40yahoogroups.com>altaircomputerclub@yahoogroups.com,
> >"Rich Whiteman"
> ><richwmn@> wrote:
> > >
> > > 31 00 01 loads the stack pointer with what needs to be an area
of ram
> > > to use for calls, returns, pushes and pops. It works from the
loaded
> > > area downward. It is not a jump.
> > >
> > > Rich
> > >
> > > LXI SP,word LD SP,word 31word SP <- word
> > >
> >
> >
>

> I also found that the code only contains ascii compares for F, S,
> and Y.  However, my manual says the program takes many more one
> letter commands.  In fact, when I looked for the command C (to move
> the cursor) the ascii code for C (43 upper 63 lower) doesn't appear
> anywhere in the code, so that also eliminates a jump table holding
> command chars.
>
> Of course, there could be some really funny business going on in the
> code

Assuming you have 52 bytes available for a jump table, it is easy to
support every character of the alphabet as commands. Subtract "A" from
the character entered, shift left one bit (multiply * 2), the add the
result to a register pair (like HL) that contains the start of the
26 addresses of the command handlers, load the jump address from the
table into HL and JP (HL).  Don't support some letter commands? Just
point those to a "bad command" routine or ignore them. For a complex
program with lots of commands, you are unlikely to find a direct
letter for letter comparison, although once you make the jump, there
could be direct comparisons for commands that have arguments or
two-letter commands.

Just a thought.

--
Craig Landrum
Chief Technical Officer
mindwrap, inc.
Phone: (540) 675-3015 x 229
Fax:   (540) 675-3130
email: craigl@...

--- In altaircomputerclub@yahoogroups.com, Craig Landrum
<craigl@...> wrote:
>
> > I also found that the code only contains ascii compares for F,
S,
> > and Y.  However, my manual says the program takes many more one
> > letter commands.  In fact, when I looked for the command C (to
move
> > the cursor) the ascii code for C (43 upper 63 lower) doesn't
appear
> > anywhere in the code, so that also eliminates a jump table
holding
> > command chars.
> >
> > Of course, there could be some really funny business going on in
the
> > code
>
> Assuming you have 52 bytes available for a jump table, it is easy
to
> support every character of the alphabet as commands. Subtract "A"
from
> the character entered, shift left one bit (multiply * 2), the add
the
> result to a register pair (like HL) that contains the start of the
> 26 addresses of the command handlers, load the jump address from
the
> table into HL and JP (HL).  Don't support some letter commands?
Just
> point those to a "bad command" routine or ignore them. For a
complex
> program with lots of commands, you are unlikely to find a direct
> letter for letter comparison, although once you make the jump,
there
> could be direct comparisons for commands that have arguments or
> two-letter commands.
>
> Just a thought.
>
> --
> Craig Landrum
> Chief Technical Officer
> mindwrap, inc.
> Phone: (540) 675-3015 x 229
> Fax:   (540) 675-3130
> email: craigl@...
>


That's the funny businesss I was considering - derived command chars
and address tables.  You explained it very well, thank you! But I
checked for that, no ascii codes for "a" or "A" (except in a data
string at the end instructing the user to "ENTER DATA").  And no
subtracts, subtracts with borrows, or subtracts immediate with or
without borrow anywhere in the code.

I also found a DB FF, which reads the sense switches.  That worries
me because there is absolutely no reference to using the switches in
the manual.

I'm beginning to think I've got the wrong program.

-John

There's a loaded 8800 on ebay at
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=220340089061
(item #220340089061).  It closes tonight and there are no bids yet,
but I blame that on the high starting price ($3,000).  I think it
will sell though, considering all that's included.

I suppose most of you have already seen it, and I only mention this
auction because it includes a 35 character-per-second Altair Q70
daisywheel printer (actually, it's a relabeled Qume Sprint 3),
complete with forms tractor attachment.  This is the first one I've
seen on ebay, at least with the Altair label, so I thought I would
point it out to those who have never seen one.  Qume supplied this
model with choice of at least 3 different interfaces- RS232 serial,
Centronics parallel, and OEM parallel.  Unfortunately, MITS went with
the OEM interface and then manufactured a special controller card for
the Altair to talk to it.  That worked OK, but made the printer
unusable with any other computer that couldn't accept the Q70
controller card.  Later, NEC came out with their SpinWriter model,
and as far as I know, it was the only other printer that was
available with the same interface (in fact, NEC may have made it at
MITS' request), so it too worked with Altairs.  MITS also marketed
these printers, which ran at 55cps.

I had a Q70 years ago, when my working computer was an 8800b,
and I wonder if anyone else here has any experience with this
Qume/MITS model?  Like all daisywheels, it was fun to see in
operation.

Steve

| From: Derek J. Lassen <xl198CV56@...>

| IIRC, the hex file format had no transfer address, and assumed x'0000'. Many
| programmers put constants and jump tables at the beginning. So, we usually
coded :
|          ORG   0
|          JMP    Entry
| Entry  EQU   *
|
| as the first three lines.

Interesting.  Those low addresses are used for the interrupt jump
vector but I guess most programs never used interrupts.

I used the interrupt instructions for very short subroutine calls (1 byte
instead of 3).  This also made it possible to "revector" to a different
implementation: the low memory was in RAM but my code was in a
ByteSaver EPROM.

--- In altaircomputerclub@yahoogroups.com, "Steve" <alltare@...> wrote:
>
> There's a loaded 8800 on ebay at
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=220340089061
> (item #220340089061).  It closes tonight and there are no bids yet,
> but I blame that on the high starting price ($3,000).  I think it
> will sell though, considering all that's included.

He's been trying to sell it at that price for a while now, this is
about the fourth time I've seen it.  So far no one's been
crazy^H^H^H^H^H interested enough to pay that much.  There's not much
information there about it, he'd probably do better if he gave more
details about the cards.  It looks like the backplane is made up of 4
of the original 4 slot units wired together, I wonder how reliable it is.

Geoff.