First of all, where was I in January? Well, I left for the meeting a little early knowing the roads were bad, but as it turned out the roads were REALLY bad. At the rate I was going, I would have arrived by, oh, 8:30 perhaps. I turned around before I even got to Burnsville. I did make it back safely and all so that's a plus. I'm hoping for better luck on February 12.
I also have to follow up on something I mentioned in last month's newsletter. Remember where I mentioned that the L.K. Avalon game Change I bought from ZTM Software Manufacturers didn't work on North American Ataris? Well, I let them know of this by e-mail, and they responded very quickly with the generous offer to either refund my money, or send me 5 of their PD disks instead. I agreed to the PD disks idea, and just a few days later their PD catalog, on disk, arrived in the mail. I have yet to make my selections. But I thought it only fair to remark on this fine customer service.
From reading Greg's article in the January newsletter, and keeping in mind some of my own little ideas, it seems as though the Club has a number of issues to discuss. So, I hope we have a good turnout at the February meeting. Hope to see you there!
And keep using that Atari!
Well, Mother Nature did it again. The weather kept our meeting very low key for January. The traffic was so bad I don't blame anyone who did not want to venture out on that Friday night.
But those who did attend got a chance to bid on some great 8-bit and 16-bit software, hardware and manuals. Some great bargains were had and that was just a small sample of what I still have left for the upcoming auctions.
The Club took in $234.00 on this auction and along with a membership renewal and DOM sales, the Club's receipts totaled $274.00 for the January meeting.
Our only expense was $10.00 for the monthly BBS. We still owe Mike for the last three newsletters and the fourth quarter room rental billing should be on its way to me for payment.
You won't believe this and I hardly can either but our treasury now stands at $1,310.03 ending January 1999. Of course this will go down when we catch up on our expenses. Or will it'? I will be bringing lots more goodies to the next meeting to auction off and if the February auction goes anything like the January one did, then we will probably more than cover any expenses the Club incurs.
Just an example of some of next months auction items for you to consider and whet your appetite. I have another 130XE, another 800XL, a beautiful 1200XL with cover, many 8-bit and ST manuals and books, tons of software and magazines and more surprises.
You don't want to miss next month, Mother Nature notwithstanding. Mike Current has some interesting matters for the membership to consider and it would be great if most of the current membership was in attendance to discuss and possibly vote on these matters. See you all next month for what should be a very enjoyable meeting.
Subj: Hasbro Interactive Advances to #3 PC Games Publisher
Date: 99-02-01 18:22:44 EST
Thursday January 28, 9:11 am Eastern Time
Company Press Release
Hasbro Interactive Advances to #3 PC Games Publisher
BEVERLY, Mass.--(BUSINESS WIRE)--Jan. 28, 1999--In three short years, entertainment software publisher Hasbro Interactive has quickly climbed the ranks to #3 PC games publisher status, based on dollar sales, according to PC Data's 1998 year-end report. The company surpassed its year-ago ranking of #4 PC Games publisher and has increased its market share.
Hasbro Interactive strengthened its position as the #1 family games publisher in the industry by possessing six of the top seven best-selling family games in 1998 based on dollars, according to PC Data. The esteemed list of family titles included MonopolyR, ScrabbleR, Game of LifeR, Wheel of FortuneR, Monopoly Star WarsR and JeopardyR. The company also captured top-5 publisher positions in nearly all major PC games categories including children's, action and strategy, and held the #6 position in simulation games, based on dollars.
``1998 was another exciting year for Hasbro Interactive,'' said Hasbro Interactive President Tom Dusenberry. ``We met our goal of building the business beyond children's and family games and have made huge strides in creating new opportunities in the action, strategy and simulation game areas,'' Dusenberry added. ``With last year's acquisitions of MicroProse, Avalon Hill and Atari, we believe '99 will be an even brighter year.''
Hasbro Interactive also delivered impressive results during the 1998 holiday season. According to PC Data dollar numbers, Hasbro Interactive landed five titles in the Top-25, and a total of 10 titles in the Top-50 in the month of December.
For the year, Hasbro Interactive's top five sellers included FroggerR, MonopolyR, ScrabbleR, TonkaR Workshop CD-ROM Playset and Game of LIFER.
Hasbro Interactive, Inc. is a leading all-family interactive games publisher, formed in 1995 to bring to life on the computer the deep library of toy and board games of parent company, Hasbro, Inc. (AMEX:HAS - news). Hasbro Interactive has expanded its charter to include original and licensed games for the PC, the PlayStationR and NintendoR 64 game consoles and for multi-player gaming over the Internet. Headquartered in Beverly, Massachusetts, Hasbro Interactive has offices in the U.K., France, Germany, Japan and Canada. For additional information, visit Hasbro Interactive's web site at: www.hasbro-interactive.com
Based in Reston, VA, PC Data has been providing point-of-sale data since 1991 and has become the only comprehensive source of software and hardware sales information. The company provides software and hardware vendors with the point-of-sale data and analysis which forms the underpinning of their strategic decision-making process. PC Data supplies sales information to more than 800 software and hardware firms, which account for nearly 95 percent of total computer industry sales. The company's latest initiative includes launching @PCData, an Internet monitoring service. In addition to tracking software sales through retailers, PC Data also tracks hardware and software sales through educational resellers, corporate resellers and distributors.
Frogger is a registered trademark of Konami Co., Ltd. (c)1981 KONAMI. All rights reserved. Monopoly is a registered trademark of Hasbro, Inc.
Scrabble is a trademark of Hasbro in the United States and Canada. Scrabble rights elsewhere in the world are held by J.W. Spear & Sons, PLC.
Star Wars is a registered trademark of Lucasfilm Ltd., used under authorization.
Jeopardy! is a registered trademark of Jeopardy Productions, Inc. (c) 1998 Jeopardy Productions, Inc. All Rights Reserved.
Wheel of Fortune is a registered trademark of Califon Productions, Inc. (c) 1998 Califon Productions, Inc. All Rights Reserved.
(c) 1999 Hasbro Interactive, Inc. (c)1999 Hasbro, Inc.
----------------
Contact:
Hasbro Interactive
Dana Henry, 978-921-3759
dhenry@hasbro.com
or
Agnew, Carter, McCarthy
Cale Barrett, 617-437-7722
cbb@acm-pr.com
Subj: Atari800Win 2.5 released
Date: 99-01-09 18:00:43 EST
Here is what's new in this version:
12-05-98 Ver 2.5 (a "beta" release)
* Consider this a beta release. It has not been tested extensively.
I will be releasing again soon to sync up with the general
Atari800 code base and address some other issues of my own.
* Any "sticky key" problems should be fixed on slow machines
* Warmstart reappears on F5 as if by magic :-)
* Arrgh! ATR images formatted while loaded into the emulator were
getting corrupted headers (they were reformatted as XFD). Modified
SIO code so that any valid ATR image (even megadisks) can be
reformatted by Atari800win.
* Added option to load Atari executable files individually instead
of requiring a disk image. This will NOT work for files that
require Atari DOS. I more or less lifted Ken Sider's routines
right out of MakeATR (actually I initially wrote a multi-segment
loader myself, but it sucked, so people can thank Ken for this
feature). When you do this the EXE will replace the disk mounted
in drive 1.
* John Frias contributed some icons (mine are retired to no artistic
talent land now).
* Fixed a problem with the R-TIME cartridge returning the incorrect
month. BTW This should come as a surprise to no one, but the
R-TIME is not year 2000 compliant.
* Fixed a small timing problem on keyboard input.
* Blank scan line option added for some video modes. Read the
readme.txt for why I still think this is a *really* stupid idea.
* Built a new ZLIB DLL which appears much less touchy about
alignment. I highly recommend you use the one included with
Atari800win as your DLL in general (slightly larger but works much
better).
* Drive status can be set directly from the disk drive dialog. This
is mainly so images can be switched to read-only on the fly for
some demos. You cannot use the dialog to override actual file
permissions - if the file is read-only to the OS, then it will
always be read-only to Atari800win (and that's by design, not
omission).
* Corrected small joystick bug that prevented the keypad from
working as joystick on port 1 while a real joystick was used on
port 2.
* Inserted a completely bogus wait after DDraw SetDisplayMode that
corrects garbage sometimes left on the screen. This very much
looks like a DDraw bug. The delay may not be long enough for all
systems. Email me if you still see window garbage on your display.
* 640x480 is now a "no visible menu" mode. Use F10 to get a menu (or
the keyboard accelerators - e.g. Alt-A + L is Atari/Load Exe). Let
me know if you find this a problem - I could make it configurable.
800x600 and up still have menus.
Subj: Atari800win 2.5a & source released
Date: 99-01-09 18:30:38 EST
Atari800Win has been updated to version 2.5a, and the source code archive has been updated as well. The Atari800win page is located at
http://www.cris.com/~Twist/atari800win
and the emulator itself is contained in this zip: http://www.cris.com/~Twist/atari800win/atari800win_2.5a.zip
source code is in this archive:
http://www.cris.com/~Twist/atari800win/atari800win_2.5a_source.zip
Please do not download the source unless you intend to really look at it; my bandwidth is very limited.
Here is what's new in this release:
12-18-98 Ver 2.5a
* Note: Older saved states will need to be re-saved for this
version.
* Re-synced with the general Atari800 code base. Fixed a couple of
Antic problems.
* Fixed screen getting offset when switching hardware types.
* Fixed the damn keyboard joystick not being detected (was only
happening on machines that have no hardware joystick devices, and
guess what - all of mine do. Grrr).
* Joystick selections are saved permanently. If you change your
stick config around (hardware wise), it won't crash, but you will
probably have to reconfigure via the joystick selection dialog.
* The scanline modes are now driven by highly tweaked assembly,
mostly because I changed the way they worked: they now show
half-lumen lines interleaved instead of black ones. In a couple of
the available graphics modes (GDI) even though a lot more work is
being done it's slightly faster than the older scanline mode.
* Added keyboard accelerators for the following functions:
Alt-C Cartridge dialog
Alt-D Disk dialog (floppies)
Alt-G Graphics dialog (screen modes)
Alt-H Hardware dialog
Alt-J Joystick dialog
Alt-K Keyboard dialog
Alt-L Load Atari executable
Alt-S Sound dialog
Alt-R Rotate through artifacting modes (including off)
* Last path used to load Atari executables is remembered
* Some small code re-orgs (same functionality, but less code)
* Fixed screen corruption in stretched-window modes when paused
* Smarter about registry updates - doesn't have to reset ROM paths
when these occur now. Also, for first time users tries to find the
ROMS in either the working directory or "ROMS" subdirectory
* Added different machine types in hardware selector for 320XE Compy
and 320XE Rambo
Subj: Dir2Atr and Xdir, new versions
Date: 99-02-06 19:04:37 EST
Hi Atarian(s),
I«ve just finished my update of the new DIR2ATR and XDIR programs, and have updated my homepage accordingly.
DIR2ATR
========
Version 5.05.00 lets you turn a pc directory
(or more pc directories in the case of Spartados)
into one or more .ATR or .XFD disk images.
It supports Single, Medium, Enhanced, Double, Quad, 720KB,
1.44 MB and 16 MB disk images.
The following OS-es are supported: Dos 2.5, MyDos 4.53,
BeWeDos 1.30 and SpartaDos 3.3a.
Although the program is designed to accept SpartaDos/X as well,
the bootcode for it is not included in the archive.
The program accepts your own favourite DOS too, just use
the "MY OWN DOS" feature of the program.
Please note that the directories you are converting should
contain Atari XL/XE files and/or text files. Just a reminder.
The update solves a bug with the configuration file,
a command line interface has been added, and the program
has a fast drive switching option now.
XDIR
====
Version 10.05 now supports a command line interface as well,
has the fast drive switching option.
A bug concerning a multiple extraction of the same disk image
(which stopped the program), has been solved as well.
So download these new versions, and let me know what you think.
Regards,
Bo Schreurs
Email: stack@xs4all.nl
Homepage: http://www.xs4all.nl/~stack/atarixle.html
Download DIR2ATR directly: http://www.xs4all.nl/~stack/dir2atr.zip
Download XDIR directly: http://www.xs4all.nl/~stack/xdirv10.zip
Subj: Project: PHOENIX notes
Date: 99-02-06 19:18:21 EST
Project: PHOENIX
Development by: Timothy B. Kline
Logical development: S.T.I.P. (ST.andard I.nterface P.rotocol) modules
Product Design: Cartidge (256K ROM/128K RAM/dual chipset) (estimation)
Programming Language: 6502 Assembly
Supports: TCP, PPP, HTML (text-based)
Machine Requirements: Atari 800/XL/XE, modem
Optional Components: Disk Drive(floppy/hard),printer,mouse/joystick
Introduction: This is a very generalized overlay of the PHOENIX project that
I am presenting to the Atari public from the outset to get feedback. This is
also a rough draft of the project and will likely become more refined as
PHOENIX is developed. Feedback and questions are welcome, as I am new at
some of this and will likely have many mistakes, including in my logic. Let
PHOENIX be an Atari Users PUBLIC-INPUT project since you are the ones that
will be using it.
Modules:
Modules marked with (*) are required to remain in MAIN memory and cannot be
banked!
Modules marked with (+) are cleared from memory after they operate.
1. TCPIP*
A. Provides the tcp/ip stack for user.
2. DIALUP (+)
A. Handles connecting to ISP for user, including login procedures. Used only
to connect to ISP. All other matters are handled by TCPIP module.
B. Memory freed up by KERNEL after successful connection. Reconnection
requires that module be reloaded to run.
3. KERNEL*
A. Browser kernel (OS).
B. Handles com port activity, calls appropriate modules for action after
INIT.
C. Maintains HTML buffer for HTML-IN modules.
D. Frees up memory used by INIT module, DIALUP (after connection returns
"success"), DISPSETUP.
E. Monitors user's inputs via joystick/keyboard/mouse.
4. HMTL-IN
1.. HTML interpreter (similar to BASIC interpreter which dismisses w/error
any HTML code not supported (HTML 3 so far?)
B. Read in HTML from kernel HTML buffer
C. Convert to PHOENIX' display S.T.I.P. format
D. Send converted code to HTML-OUT S.T.I.P. module for displaying
5. HTML-OUT
A. Receive converted code from HTML-IN module
B. Display page, setup any pop-up boxes containing links on page
1) Determines if display is hi or lo res and formats accordingly
6. DISPSET (+)
A. Initializes custom display according to user's selection (hi/lo res)
7. INIT (+)
A. Runs setup routines, reads in from disk any user preferences/settings
B. Sets variables, checks machine's capabilities (RAM, XL/XE?, etc.)
C. Initializes KERNEL and passes control to KERNEL
8. BUFFER*
A. Stores HTML code for processing
9. POPUP
1.. Provides a pop-up menuing system for user to access certain features
such
as page links of a web page.
B. Provides a simple help system to user as an "online" guide.
2.. Provides a means to input manually a URL address, in conjunction with
the input box of the web browser.
3.. Provides user with a list of available "favorites" from disk file and
ability to select one.
10. HTMLED
A. A simple text-based HTML editor for editing HTML files
Notes:
1. S.T.I.P.
1.. S.T.I.P. is designed for modular use to allow for maximum
expandability of PHOENIX and to allow for optimal trapping of errors.
2.. Each module interfaces with the KERNEL by using the KERNEL's unique
program STACK. The KERNEL module simply initializes appropriate modules.
Each module MUST PERFORM A SINGLE FUNCTION, and may access the following
permanent modules: STACK, BUFFER, TCPIP.
1.. C. Additional modules can be interfaced into PHOENIX simply by
injecting itself into the STACK's command table or by the designer providing
a new COMMAND module for PHOENIX which includes his/her module's
call-command.
This gives PHOENIX unlimited potential for all its users and a standardized
means of expandability. Modules can be set up to run from any available disk
drive (floppy, hard, or RAM).
2. BUFFER
1.. Simply put, this is where all html that is received from the web goes.
Now, because there is only so much memory available on the Atari 8bit, this
is done in the following fashion:
1) html code is received
2) after each "complete" html segment, it is buffered and HTMLIN module is
summoned by KERNEL, which processes the code and passes the processed code
onto HTMLOUT for display.
example: KERNEL receives an html segment from web page and buffers it thus:
Received:
text
KERNEL's action:
Upon receiving the closure html code "", KERNEL considers this a
complete instruction and sends it on to HTMLIN for processing. If there had
been no "" signifying closure, KERNEL would have come to another html
code and dismissed the beginning "" command altogether.
Fortunately, most html editors on the market will check for errors in html
code, so this is unlikely to happen.
This is similar to how BASIC interprets your typing in a command (such as
SETCOLOR) and then reacts. Simple, right? Thus the COMMAND module's
importance comes to light. Want a new feature? Add a command to the COMMAND
table and KERNEL will call it up when it's needed. HTML definitions are
located in the COMMAND module in such a way as to cause HTMLIN to react in
an Atari-friendly fashion, and HTMLOUT, too.
Now you may ask, what about web pages that contain straight text, such as a
textfile, or text that may be found without html tags? Does that, then, just
become ignored? No. The KERNEL is designed to recognize that sometimes this
is the case and will respond thus:
If information continues to be received from a website, but without any html
tags, then it is fed into BUFFER until it becomes full, and then HTMLIN is
flagged to dispose of the BUFFER, treating it as raw text, and it will
certainly display it as raw text, too! The BUFFER is then cleared and ready
to go again. This process continues until an html tag is found or until the
web page finishes loading. Again, though, most people will add a
tag to their html, so this will work in an html setting. In
the case of a raw textfile, the end will be reached and that is, as they
say, that. Flagging HTMLIN to act on the buffer as raw text is the ultimate
failsafe that you won't miss any information of a web page that is
text-based. However, there is no java support, midi support, etc. in PHOENIX
unless someone figures out how to write the S.T.I.P. module for it. Sorry!
3) process returns to step 1.
3. STACK
1.. This is a unique system that will provide a means to access various
features of PHOENIX.
2.. It provides numerous factors such as FLAGS, online condition
(connected/offline), and more.
C. It is designed thus:
1) STATUS TABLE:
STATUS1 [64] [32] [16] [08] [04] [02] [01]
F E D C B A
A- CONNECT ONLINE=255 OFFLINE=0
B- DISPLAY HIGH=255 LOW=0
C- MACHINE XE=255 XL=0
D- CART YES=255 NO=0
E- MODIFIED YES=255 NO=0
F- PATCHING YES=255 NO=0
RAM [64] [32] [16] [08] [04] [02] [01]
1024 512 320 256 128 64
BANK [64] [32] [16] [08] [04] [02] [01]
7 6 5 4 3 2 1
[Bank 0 = 0, Bank 8=255]
STATUS2 [64] [32] [16] [08] [04] [02] [01]
G F E D C B A
A- BUFFER FULL=255 EMPTY=0
B- CONVERT HTMLIN=255 HTMLOUT=0
C- BUFCOMMAND TAG=255 RAW=0
2) COMMAND STACK:
CMDSTACK1 [64] [32] [16] [08] [04] [02] [01]
CMDSTACK2 [64] [32] [16] [08] [04] [02] [01]
4. COMMAND
1.. This works in conjunction with the KERNEL module in that it will
verify that what is in the BUFFER is html code. It examines the buffer's
start for an html tag, compares it against its command table and if it
doesn't find a match, sets the COMMAND flag to RAW and returns control to
KERNEL.
If it matches the html tag with a command, it sends it to HTMLIN for
processing, along with setting the CMDSTACK byte to its necessary flags for
HTMLIN.
2.. Can be modified by enduser or developer to incorporate additional
support, such as music support, or to add additional modules such as
ftp/email. Table for COMMAND is loaded during INIT from either the cartridge
or a diskfile. If PHOENIX is the cartridge version, the user must have set
the flag in his SETTINGS panel to have PHOENIX recognize that the COMMAND
table needs to be patched with add-on commands. The appropriate format for
patching is as follows (text-only!):
Format for a new COMMAND to be added into table:
128,command-name,command-module-name,0,255
The "128" tells INIT that this is an incoming COMMAND patch.
The "0" designates the end of the patch.
The "255" signifies end of patching sequence, EOF. If there are more
COMMANDS to be patched, then there would be another "128," after the "0,"
until done, and then the "255."
3.. There is no check to assure that the original COMMANDS are not
overwritten! However, the flag for MODIFIED is set to high when the COMMAND
table is patched, so if PHOENIX starts behaving erratically, check the
MODIFIED bit to see if the COMMAND table was modified. If it was, and you
want to determine if the patch is at fault, simply set the flag in your
SETUP to disallow patching of the COMMAND table and restart PHOENIX.
If the problem stops, then you've discovered the culprit!
4.. Again, this is a wonderful provision of expandability provided to the
enduser. By adding a command for KERNEL to access, you can add power to your
web browser! Your add-in patch can direct HTMLIN to act in certain ways in
response to the code it may have otherwise discarded or shown as raw text,
as an example. You could re-direct it to a file on your floppy drive (if you
have enough room!) or to a hard disk, even. The possibilities are there, if
you have the imagination and motivation to do it. I've made the S.T.I.P.
simple enough that you should have little trouble customizing your own copy
of PHOENIX or making your add-in patches available on the internet for
others to use. The only draw back is that you must use 6502 ML to write the
module. If you don't know ML, there may still be a pseudo-compiler available
at one of the Atari archives that takes BASIC and converts it into ML (I
used to use one from Analog Magazine years ago!) if you want to write it in
BASIC instead.
-------------------------------------------------------
Again, this is nothing more than my initial notes. Some things will change
as the design becomes more firm.
Essentially, PHOENIX will serve as a means for the Atari 8bit user to
connect to the WWW, using what I am calling a "in progress" interpreter.
Simply put: it will act like BASIC's intepreter does, only you aren't typing
in the html it is acting upon (like someone typing in the BASIC program for
you).
The S.T.I.P. concept should allow for a centralized KERNEL and companion
modules and yet allow for either customization or additional components. The
trick will be how to add in new commands in a cartridge setting.
Having established REGISTERS for PHOENIX and aspiring programmers should
ease things, too, since various values and settings will be accessible via a
table of bytes (with flagged bits as the means of discernment, rather than
wasting entire bytes for a particular value).
Conserving memory is vital in the Atari. PHOENIX is being built specifically
to utilize not only VBLANK processing, but memory bank switching, too! Add
to that that my current scenario is to have the browser burned into a 256K
rom cartridge (banked memory), and looking into how 128K of RAM can
accompany that for high-speed writes for caching. and this should be a
decent little web browser for the Atari 8bit!
The credit list will be intact as well, for all those who have been such a
tremendous help with this thus far!
Published by the Saint Paul Atari Computer Enthusiasts (SPACE), an independent organization with no business affiliation with ATARI Corporation. Permission is granted to any similar organization with which SPACE exchanges newsletters to reprint material from this newsletter. We do however ask that credit be given to the authors and to SPACE. Opinions expressed are those of the authors and do not necessarily reflect the views of SPACE, the club officers, club members or ATARI Corporation.