Jump to content
Sign in to follow this  
xxx

why does the ti99 need extended basic or assembler to run some games?

Recommended Posts

if they are written in code, i dont see the difference. is there a way around this? i know code can be executed from basic

Edited by xxx

Share this post


Link to post
Share on other sites

By code, do you mean assembly language? Still, you have to be able to start the game. There is no official way to link to an assembly program from BASIC, unless you have the Editor/Assembler or Mini Memory module in the machine. Or you can link from Extended BASIC.

Later, some bugs in BASIC were exploited to jump to assembly code, but that wasn't common knowledge back when I got my TI, for example.

 

Today, we also have a lot of other methods, including loaders in various peripherals.

Share this post


Link to post
Share on other sites
10 minutes ago, apersson850 said:

By code, do you mean assembly language? Still, you have to be able to start the game. There is no official way to link to an assembly program from BASIC, unless you have the Editor/Assembler or Mini Memory module in the machine. Or you can link from Extended BASIC.

Later, some bugs in BASIC were exploited to jump to assembly code, but that wasn't common knowledge back when I got my TI, for example.

 

Today, we also have a lot of other methods, including loaders in various peripherals.

yes and yes, i know u can use data statements and the open#1 command

Share this post


Link to post
Share on other sites
if they are written in code, i dont see the difference. is there a way around this? i know code can be executed from basic
The big requirement is RAM, assembly language programs need the extra 32k to load into since they are programmed for that memory space.

The basic playground loader uses the teeny amount of cpu RAM in the console to leverage loading assembly in Ti basic but that's limited to very small programs. Ti basic has no built in ability to access expansion RAM.

Most games from TI on cartridge for instance are written in GPL and run from GROM carts. They can be copied to RAM and run from there but it has to be the 32k expansion RAM. This is how we run GROM games from a ROM cartridge board such as the flashROM99.

Editor assembler gives you the loader to load assembly programs while extended basic gives you the ability to load SOME assembly natively. Editor assembler sets up a environment with routines that can be called by programs. It also has add on routines for Ti basic while the cart is installed. Both require 32k expansion RAM to do this.

People have written loaders for extended basic that create the editor assembler environment that many programs require to load correctly.

These days with sidecar 32k availability for a reasonable price and SAMS cards for less than $100us and the FinalGrom99 sd card cart you can have a full assembly capable TI for not much investment.

Greg


Sent from my LM-V600 using Tapatalk

  • Like 3

Share this post


Link to post
Share on other sites
44 minutes ago, arcadeshopper said:

 Ti basic has no built in ability to access expansion RAM.

ok, sorry to be a pain but could this not be programmed from basic in code to access the ram?

Share this post


Link to post
Share on other sites
26 minutes ago, xxx said:

ok, sorry to be a pain but could this not be programmed from basic in code to access the ram?

 

This should be possible, but, as noted earlier, you will need to use Playground to do it. You should consult the Playground thread—especially posts #33 – #50 to see how you might do it.

 

...lee

Share this post


Link to post
Share on other sites
Just now, Lee Stewart said:

 

This should be possible, but, as noted earlier, you will need to use Playground to do it. You should consult the Playground thread—especially posts #33 – #50 to see how you might do it.

 

...lee

yeah, ive taken a look at that thank you

Share this post


Link to post
Share on other sites
44 minutes ago, xxx said:

ok, sorry to be a pain but could this not be programmed from basic in code to access the ram?

Basic can only be run from VDP memory or GROM never from RAM.

(Unless you have a emulator to move from RAM to VDP to run Basic.)

To run TI Basic from RAM convert to  Extended Basic program that originally was TI Basic programs.

TI Basic Editor Assembly Cartridge has access to RAM.

Extended Basic Cartridge has access to RAM.

TI Basic Mini Memory has access to RAM.

  • Like 1

Share this post


Link to post
Share on other sites

As long as you don't have some memory expansion, like 32 K RAM card, running assembly programs isn't interesting anyway. If you have such memory, then adding some cartridge to load assembly programs isn't any big deal.

For most practical purposes, writing a complete application in assembly language isn't efficient. You augment your programs, in BASIC, Forth, Pascal or whatever with assembly to either access functionality not available or speed up critical parts of the program.

 

It's mainly games that are written as complete applications in assembly, when speed and/or graphic requirements makes everything else short of the target.

  • Like 1

Share this post


Link to post
Share on other sites

I feel like your original question's never really been answered.

 

TI BASIC is much more limited than BASIC on most other microcomputers is. There is a lot you simply can't do with it(Playground exploit aside), like utilizing expansion memory, running assembly programs, or accessing sprite hardware. Hence, there's a lot of software that can't be run with just TI BASIC.

 

TI Extended BASIC is the BASIC the console should have shipped with in a more reasonable world, and makes it possible to access most of the system's capabilities as well as load assembly programs.

It is, more or less, what someone would expect BASIC to be if they came to the 99/4a after experience with a diffrent microcomputer and was not familiar with the 4a's "quirks".

 

 

  • Like 2
  • Thanks 2

Share this post


Link to post
Share on other sites

Which in turn most probably is because at TI, at that time, they didn't envision the majority of the buyers to do programming. They expected them to buy software modules, and run TI Invaders or Personal Record Keeping that way.

The unusual architecture of the machine, combined with the hardware they used to implement things like the Extended BASIC, which feature-wise is more advanced than what many competitors had (albeit slow), prevents Extended BASIC from being present at the same time as a TI Invaders module, for example.

Share this post


Link to post
Share on other sites

It's sad to see that even when they should have understood that things turned out to go in the wrong direction - in particular, realizing that systems like C-64 benefitted from their openness for programming - that they still steered towards the same cliff and developed the even more restricted QI.

  • Like 1

Share this post


Link to post
Share on other sites

Very true.

 

I sorta feel like that is on-brand for the home computer division's entire all-too-brief life, though. A good line of products designed by talented people that were repeatedly kneecapped by bad luck and sabotaged by poor management.

...

Which, to be fair, still places them far ahead of MOST companies with an established minicomputer business in this era. 

Share this post


Link to post
Share on other sites

TI, but not the home computer division, also launched the TI Professional computer. A computer that was supposed to play the same role as the "IBM PC", but wasn't compatible with it. Better in some ways, but not compatible.

Didn't live too long either.

Share this post


Link to post
Share on other sites
On 11/17/2020 at 2:08 PM, xxx said:

if they are written in code, i dont see the difference. is there a way around this? i know code can be executed from basic

 

Your statement assumes the game is stored in TMS9900 machine code, not TMS9900 assember object code, nor written in a high level programming language like Basic.

But then you face the following...

 

Situation:

- no single CPU (also not todays CPUs) can run machine code from a mass storage device directly.

- you can only run machine code from CPU memory.

- to execute some machine code, this machine code needs to first be copied from its current location (disk, tape) into CPU memory, such a thing is typically called loader.

 

So either you need to have such a loader in CPU memory or create one in CPU memory to be able to start the loader to be able to start your game.

 

Finding such a loader:

- such a loader was not part of the ti-99 console system software nor part of TI Basic that came with the console.

- the console system software was on ROM chips and did only include the absolute essential stuff for an unexpanded console, it was NOT including software for potential expansions

- the unexpanded console is only coming with 256 bytes of CPU ram

- having a loader for running machine code within the 256 bytes of CPU ram would have hardly added value to the target audience. so not existing.

- having a loader for a potential memory expansion would not fit the strategy of a tight console system software. so not existing.

 

Creating your own loader:

- TI Basic, that sits in the console, is your only way to interact with the computer, unless you plugin a cartridge.

- TI Basic is limited, but can be expanded by inserting certain cartridges and selecting TI Basic from the Menu to have its additional commands available.

           (Mini Memory, Editor/Assembler, Statistics, Personal Record Keeping, Personal Report Generator, Terminal Emulator II, TI Extended Basic)

- TI Basic with no cartridge plugged in is not(!) providing you with the necessary commands to create your own loader. This would at least require commands in TI Basic to write to the 256 bytes of CPU Ram or towards the CPU Memory Expansion.

- TI Basic is not aware of a memory expansion. You can not access or use the memory epxansion from TI Basic.

- TI Basic has an OLD (load) functionality but that is limited to load basic programs and it loads the basic program only into Video Ram since all of 256 bytes of CPU RAM are used by the system and the GPL and Basic Interpreter.

 

Adding a cartridge

- the expansion strategy of TI was to expand the functionality of the computer via cartridges:

     - TI Extended BASIC cartridge added new important features to the console, making full use of an installed Memory Expansion. It also adds commands to read and write to all installed CPU memory. With those extensions you can either create your own loader or run one created by another person. Those command extensions require the 32K memory expansion.

     - Mini Memory cartridge added 4K of CPU ram via the cartridge part and adding assembler functionality and also a loader for a game like you mentioned. Also it expands TI Basic by several commands to read and write to CPU memory allowing you to create your own loader.

     - The Editor/Assembler cartridge added tms9900 assembler functionality and came with several loaders for a game like you mentioned. Also this cartridge expands TI Basic by several commands to read and write to CPU memory. This cartridge requires the 32K memory expansion to start.

     - TI Writer cartridge came with a loader for a game like you mentioned. This cartridge requires the 32K memory expansion to start.

 

Why does it even work via cartridge?

- when you insert a cartridge, its ROM is part of the CPU memory and therefore any machine code in its ROM can be run directly by the CPU.

 

So to sum it up, the Extended Basic or Editor/Assembler cartridge is not required but they provide you with a loader for Tms9900 machine code which is not part of the console system software. Instead of running those cartridges one could release a cartridge with nothing but such a loader.

 

And yes, recently somebody managed to find a way out of the TI Basic sandbox and therefore allows to start a loader even on an unexpanded console without any cartridge installed. But this was never intended by the engineers of the console.

  • Like 4

Share this post


Link to post
Share on other sites
14 hours ago, kl99 said:

Why does it even work via cartridge?

- when you insert a cartridge, its ROM is part of the CPU memory and therefore any machine code in its ROM can be run directly by the CPU.

There doesn't even have to be ROM in the cartride. On the contrary, there are many of TI's modules that has no ROM. Instead they have GROM, which is an auto-incrementing port-accessible ROM. It's mainly used to store GPL code. Graphics Programming Language is interpreted by the GPL interpreter in the console.

In GPL, you have the ability to program file handling (loading your program), moving it around in memory (place the program where it should run, including expansion memory) and then execute the machine language (XML instruction).

If TI had wanted to, they could have added this functionality to TI BASIC. The only thing perhaps preventing that would be space in the console's GROM chips.

Instead, they selected to use the facility they had provided to expand TI BASIC with more commands in a cartridge.

 

To briefly return to the concept of "code", the TI can handle programs in several formats.

Memory image assembly programs are exactly that, a copy of a region of memory when the program is loaded in that memory. It's the most efficient way to load a program, but also the least flexible. It will load a chunk of memory in one operation, but the code must go in the same place as it was when the image file was created.

Absolute object code is tagged object code, where each word of memory is represented in printable hexadecimal ASCII codes. The object code is reasonable to read by humans too. The tags are used to describe if each word is an instruction, an address, an external reference or similar. This kind of code can only run in one single location in memory.

Relocatable object code is very similar to the absolute code. The difference is that addresses here are not fixed in the code. Addresses are relative to the code's loading position in memory, so the loader (which has to be more advanced) can select any free space in memory and load the code there. Several segments of code can be loaded after each other. One segment can define one or more locations inside itself, locations which then can be referenced by segments loaded later. These references will be resolved by the loader at load time. This feature allows for creating library routines, which can be loaded first, and then used by several other programs, loaded later.

Compressed object code has the same features as the object code formats above, but each word requires half the space in the code file.

 

Named definitions inside the object code can then also be called from TI BASIC/TI Extended BASIC, by name, with the CALL LINK command. For TI BASIC this requires some kind of expansion with this capability. Like the E/A module, or similar.

 

Not even touching the ability to load BASIC programs, or running other operating systems (like the UCSD p-system, which has even more advanced linking features between high level Pascal and low level assembly programs), you quickly find that albeit the TI 99/4A has pretty limited capabilities with just the console, adding some equipment (memory expansion, program cartridges) suddenly makes it bypass the capabilities of several contemporary products.

Edited by apersson850
  • Like 3

Share this post


Link to post
Share on other sites

I think what is difficult to imagine for many people less acquainted to the TI-99/4A is that this machine came with only minimal RAM (256 byte), and instead, used the video RAM to store the BASIC program.

 

Hence, many ideas for the unexpanded console that would be applicable to most other platforms turn out to be just unfeasible or - in the case of Playground - as a clever, yet limited hack.

 

Our community had to learn quickly, right from the start, that the plain console is rather uninteresting.

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
3 hours ago, mizapf said:

I think what is difficult to imagine for many people less acquainted to the TI-99/4A is that this machine came with only minimal RAM (256 byte), and instead, used the video RAM to store the BASIC program.

 

Hence, many ideas for the unexpanded console that would be applicable to most other platforms turn out to be just unfeasible or - in the case of Playground - as a clever, yet limited hack.

 

Our community had to learn quickly, right from the start, that the plain console is rather uninteresting.

So true I went from 1983 TI99/4A console with Mini Memory or XB to owning a P-Box very quickly.

Within a year after that I had RS232 Corcomp, Horizon RAMDISK, CORCOMP RAMDISK, 32K and GRAMKRACKER.

As soon as anything came out I got it for my TI.

 

Only computer I ever owned that I expended as fast as financially possible.

  • Like 1

Share this post


Link to post
Share on other sites

Spot on. Had there been 32 K RAM inside the console, like some of us have installed, then it would have been a very different game. But at that time it would have taken up too much space and cost too much. TI tried to reduce the cost, not increase the performance.

 

What I wanted was to be able to run Pascal on my home computer. So I got the p-code card as soon as I could.

Edited by apersson850
  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...