NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/ti/1016

Internet Message Format | 1993-01-22 | 7.3 KB

Path: sparky!uunet!math.fu-berlin.de!mailgzrz.TU-Berlin.DE!zrzsp5.chem.tu-berlin.de!willi
From: [e-mail] (Winfried Winkler)
Newsgroups: comp.sys.ti
Subject: Re: NCTIS report
Date: 22 Jan 1993 17:11:42 GMT
Organization: Inst.Organ.Chemistry, Techn.Univ.Berlin
Lines: 110
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: zrzsp5.chem.tu-berlin.de

>In article <[e-mail]>, [e-mail] (Winfried Winkler) writes:
>> In article <[e-mail]> [e-mail] writes:
>
>>>Hardware standards decided-
>>>     LEVEL A             TI 99/4A CONSOLE, TV OR MONITOR, CASSETTE DECK AND
>>>                         CABLE
>>>     LEVEL B             LEVEL A PLUS: 32K MEMORY EXPANSION, EA/5 LOADER
>>>                         (XB, EA, SUPERCART, TI WRITER, MULTIPLAN, ETC...)
>>>     LEVEL C             LEVEL B PLUS: RS232, DOUBLE SIDED SINGLE DENSITY DISK
>>>                         DRIVE AND CONTROLLER (ALL CONTROLLERS DO DSSD)
>>>     LEVEL D             LEVEL C PLUS: 128K OR GREATER CPU RAM BANKABLE IN AT
>>>                         LEAST 8K SEGMENTS.
>>>     LEVEL E             LEVEL D PLUS: 9938/58 VDP WITH 128K VDP RAM
>>>                         (ANY 8 COLUMN CARD) OR A GENEVE
>>
>> Where does a DS/DD DiskController fit in ?
>
>The hardware standards were based on the software programmer and end-user
>perspective.  At any of the 5 levels, there will be more users with single
>density disk capabilities than with double density capabilities.  You can have
>a Level A system even if you have DS/SD capabilities if you don't have 32K.
>At Level A, you are pretty much limited to cartridge or BASIC software.  When
>moving to Level B, much of the newer assembly language software can be used if
>saved to cassette, but the main software base there is XB software loaded from
>cassette.
> [....]     Most software authors will continue to develop
>for the Level C system.  To stay "Level C-compliant," the use of hardware not
>required at Level C would best be left as optional.  I.e., if you write a
>disk manager program [...] it makes sense to give the option to support double
>density disks if at all possible.  This may seem like a ridiculous example,
>since there are already several disk managers available and most support both
>single and double density.  However, it illustrates the point.  If every piece
>of new hardware requires a new level, and various combinations of hardware are
>different levels, there would be way more than 5 levels.  Level 5 was added
>to appease the Geneve population.  If you are writing for the Geneve, it is
>best to make your software compatible with V9938/58-equipped 99/4A's.

I mentioned DD-diskcontrollers, because for some programs it is really "a pain
in the ass" :-> to use'em with SD-drives only -- or very annoying for the one
who's writing software to assume only SD-disks available...
In the first category  FunlWeb, TI-ArtistPlus, etc come to my mind.
About the second category:  Remember that Graphics-Adventure "Legends" ?
 It had to open a "dummy"file for read and check error-conditions very often
 if it was loading one of *several* sub-files with additional data...
 Just to find out, wether the right (single density) disk was in the drive.
 (It could've read disknames or similar things  to stay "fool-proof"...)
As Text/Data on adventure-type games or graphics (at least for VDP9938!) fill
up a 720 sector-disk very soon sometimes - do you agree? - I think it would at
least be easier to assume DD-disks for "D2" or "E" Level, too !
That "check for which disk" could be eliminated or completely different, faster
(sector-based, for example) options only available with DD could be used.
Comments ?

>> shouldn't be a GRAM-device on that list, too ?
>> ... as it could be used for "storage only" memory expansion, too.
>There has been some contention during the NCTIS meetings on the absence of
>GRAM devices from the levels.  Again, the levels were decided based upon what
>the larger markets in the TI community would be for software developers.  Also
>recall that most of the committee are from the U.S.  Information for using and
>programming GPL was kept very secret in TI's home country.  Europe and Canada
>got the information needed to use the power of GPL not long after TI pulled
>out of the home computer market.  This information has gradually come back to
>the U.S.  One might think that TI was free with the information outside the
>U.S. because development could be done abroad where salaries are lower and the
>products would not have quick competitors to market because development tools
>were controlled so tightly.
Don't you think a little bit *too bad* about TI's information's policy :-> ??
Anything *I* learned about GPL I got from one book stating:
"Anything in this book comes from hand-analysing the ROM-Code and, after being
able to program a disassembler for GPL, hand-analysing some GROMs ..."
or something similar... (cited from memory)
Because the support in europe was sometimes even worse - pricing was always! -
some people decided to get any information necessary for themselves -- the hard
way, if no other source of information could be used ...
By the way:  as this book seems to be long out of print -
   what about making the (uncommented, as I will not translate and
   type all these german comments in !!) complete GROM #0,1,2 and
   console ROM sourcecodes, similar to the ones in this book available ?
   (I could post it as TIED-Archiver file, ready-to-assemble)

But back to our topic :->
You've "level E" for Geneve ... well there's a GRAM device already so wide-spread
and compatible to another TI99-GRAM (MG's GRAM-Cracker?) !
Even if I'll have to agree with J.Cohen, that (estimated) 700-800 Geneve users are
no argument for a true TI99'er -- considering numbers only, of cause :-> :->
There are already several GPL Free/Fairware programs available, from austrian and
german, as well as some american users, their number is growing and may grow even
faster if that new GPL-assembler will come out "real soon now" :->
GPL is easier to use and must not be learned "as a completely different language"
compared to assembler. It allows use of more memory (without banking!) for the
program itself and the complete CPU-address-range of RAM for data-storage.
Easy:  build-in stack  (Don't worry about saving return-addresses over&over...)
       "conditional jump" within 8K-segment unlimited (No "out of range"...)
       easy-to-use build-ins for screen writings
       and many more...
Isn't there a copy of TI's own "GPL Manual" floating around at some user groups ?


>When 4a Memex becomes available, it will be compatible with 16-bit 32K consoles.
Do you know, what mechanism they're using to make this sure ?
If they only support RAM>6000 or >4000 banking *additionally* me thinks most
programmers will use banked >A000 to >FFFF range for ease of programming or just
because they're used to use that -- thus giving away 16-bit compatibility ...
Could you give any more detailed information about the Memex :
Estimated date of release & price, address range & banking mechanism
 (CRU- or Memory-Address- usage for banking, for example ?)



Winfried --  [e-mail]