assembly games for xb, no 32k?

[notwhoyouthink]

Is there a list of assembly games (if there are any) that will run from Extended basic, without the 32k, and can be loaded from tape?

[+arcadeshopper]

There aren't any that I know of.. There are a few that run in TI basic though check out this thread: http://atariage.com/forums/topic/218904-playground/?view=findpost&p=3635423&hl=%2Bplayground

 

Greg

[notwhoyouthink]

you can load assembly from basic, but not extended basic?

 

Assuming the code is short enough to fit the unexpanded limit of the ti, why could you not use extended basics call load() to start a assembly game?

[+arcadeshopper]

you can load assembly from basic, but not extended basic?

 

Assuming the code is short enough to fit the unexpanded limit of the ti, why could you not use extended basics call load() to start a assembly game?

 

Since playground is basically a exploit I wouldn't expect it to work in extended basic.. I believe call init requires 32k..

 

Name:

INIT subprogram

Format:

CALL INIT

Description:

The INIT subprogram is used along with LINK, LOAD, and PEEK, to access assembly language subprograms. The INIT subprogram checks to see that the Memory Expansion is connected, prepares the computer to run assembly language programs, and loads a set of supporting routines into the Memory Expansion.

 

The INIT subprogram must be called before LOAD and LINK are called. INIT removes any previously loaded subprograms from the Memory Expansion. The effects of INIT last until the Memory Expansion is turned off and does not need to be called from each program that is using the subprogram involved.

 

If the Memory Expansion is not attached, a syntax error is given.

 

Here's the command reference I referenced: http://mainbyte.com/ti99/basic/basic2.asp

 

Call load gives you a syntax error if you do not call init first.. chicken and egg

Edited July 11, 2017 by arcadeshopper

[Asmusr]

you can load assembly from basic, but not extended basic?

 

Assuming the code is short enough to fit the unexpanded limit of the ti, why could you not use extended basics call load() to start a assembly game?

 

The unexpanded console only has 256 bytes RAM that could, in theory, be used for running assembly code, but XB doesn't support that. The 16K is video memory that cannot be used for running assembly code. The fact that you can run a bit of assembly from TI BASIC is due to a recently discovered exploit, but no games from 'back then' were written for that.

[Tursi]

 

 

The fact that you can run a bit of assembly from TI BASIC is due to a recently discovered exploit, but no games from 'back then' were written for that.

 

I do believe it would have been a game changer (hah!) if we'd had the trick back then. So many people I knew who had a console were discouraged by the limits of the console itself.

[+RXB]

 

Since playground is basically a exploit I wouldn't expect it to work in extended basic.. I believe call init requires 32k..

 

Name:

INIT subprogram

Format:

CALL INIT

Description:

The INIT subprogram is used along with LINK, LOAD, and PEEK, to access assembly language subprograms. The INIT subprogram checks to see that the Memory Expansion is connected, prepares the computer to run assembly language programs, and loads a set of supporting routines into the Memory Expansion.

 

The INIT subprogram must be called before LOAD and LINK are called. INIT removes any previously loaded subprograms from the Memory Expansion. The effects of INIT last until the Memory Expansion is turned off and does not need to be called from each program that is using the subprogram involved.

 

If the Memory Expansion is not attached, a syntax error is given.

 

Here's the command reference I referenced: http://mainbyte.com/ti99/basic/basic2.asp

 

Call load gives you a syntax error if you do not call init first.. chicken and egg

RXB allows CALL LOAD without the need for CALL INIT to be used.

 

I fixed this is RXB 2001 so 2015 has continued this repair of XB.

[Tursi]

Right, but I believe even the RXB CALL LOAD needs to load to CPU memory, doesn't it? With only 256 bytes available, the unexpanded console is restricted. (It's still useful.. I so wanted the ability to CALL LOAD without 32k back in the day ).

[+RXB]

Yea you can write a small XB Program to CALL LOAD some bytes into FAST RAM and then move more in from VDP with only a console.

 

RXB even has a routine for this using no LINK NAMES.

 

CALL EXECUTE(ADDRESS) will do a BLWP into any address, thus no LINK or tricks needed to run Assembly in just a Console.

[+Vorticon]

Yea you can write a small XB Program to CALL LOAD some bytes into FAST RAM and then move more in from VDP with only a console.

 

RXB even has a routine for this using no LINK NAMES.

 

CALL EXECUTE(ADDRESS) will do a BLWP into any address, thus no LINK or tricks needed to run Assembly in just a Console.

 

So theoretically, one could load an XB program from cassette containing an assembly program stored as a hexadecimal list in data statements, and execute it from fast RAM with CALL LOAD in RXB. Am I understanding this correctly?

[Omega-TI]

 

I do believe it would have been a game changer (hah!) if we'd had the trick back then. So many people I knew who had a console were discouraged by the limits of the console itself.

 

Now days with Matt's 32K sidecar it's not necessary, but I imagine someone, JUST TO SEE WHAT CAN BE DONE or FOR THE HECK OF IT may try to combine that playground method with the expanded capabilities of the FG99. One thing I've learned from TI'ers like you over the past few years... if it's never been done before, just wait, someone will make it happen!

[+RXB]

 

So theoretically, one could load an XB program from cassette containing an assembly program stored as a hexadecimal list in data statements, and execute it from fast RAM with CALL LOAD in RXB. Am I understanding this correctly?Ye

Yep! That was the idea.

[Tursi]

 

Now days with Matt's 32K sidecar it's not necessary, but I imagine someone, JUST TO SEE WHAT CAN BE DONE or FOR THE HECK OF IT may try to combine that playground method with the expanded capabilities of the FG99. One thing I've learned from TI'ers like you over the past few years... if it's never been done before, just wait, someone will make it happen!

 

If you have the FG plugged in, you can already run assembly code, so the Playground trick offers no advantage that I can see?

[Omega-TI]

 

If you have the FG plugged in, you can already run assembly code, so the Playground trick offers no advantage that I can see?

 

I suppose... I was thinking more in terms of user written RXB programs using the architecture of the FG99 to swap things in and out to get around the memory limitations. For anything other than experimentation and proof of concept I really don't see a practical application.

[+RXB]

EXECUTE subprogram PAGE E4

-------------------------------------------------------------

Format CALL EXECUTE(cpu-address[,...])

CALL EXECUTE(numeric-variable[,...])

Description

The EXECUTE subprogram directly goes to the cpu-address and

expects to find 4 bytes to be present. The bytes are 1 and 2

define the workspace register address. Bytes 3 and 4 define

the address to start execution at in cpu memory. Programmers

can see this is a BLWP at a cpu-address. The programmer is

responsible for keeping track of the workspace and program

space he is using. Also for any registers while doing a BL or

another context switch. A RTWP will end either a BL or a BLWP

as long as registers set are not changed. By using CALL LOAD

or CALL MOVES the programmer can set up a BLWP routine in the

lower 8K by filling the registers with values first, then

using CALL EXECUTE to directly complete these commands. This

is faster then CALL LINK as no interpretation of the access

or values are checked.

EXECUTE runs a XML link from GPL by moving 12 bytes from the

Fast RAM at HEX 8300 to VDP at HEX 03C0 then moving the value

in FAC passed from XB to HEX 8304 and does a GPL XML >F0

After a RTWP by the Assembly program, it returns VDP HEX 03C0

to Fast RAM HEX 8300 so the 12 bytes are restored. Thus this

allows programmers use of FAC and ARG areas in Fast RAM.

Here is the program loaded into Fast RAM by EXECUTE:

AORG >8300

CPUPGM DATA >8302 First address.

BLWP @>834A Switch context

with FAC as dummy.

CLR @>837C Clear for GPL return.

RT Return to GPL.

END

If a programmer absolutely must use Fast RAM for his program

I suggest he set up a buffer for saving HEX 8300 to HEX 83FF

if only so it will not mess up any GPL pointers and don't go

and mess up the 12 bytes at VDP HEX >03C0. Then the only

thing to worry about is messing up something else.

EXECUTE PAGE E5

-------------------------------------------------------------

Programs

Line 100 initializes lower 8k | >100 CALL INIT

Line 110 loads the assembly | >110 CALL LOAD(9838,47,0,38,1

program shown below. VMBR | 14,4,32,32,44,3,128)

Line 120 loads registers with | >120 CALL LOAD(12032,0,0,48,0

VDP address, Buffer, Length. | ,2,255)

Line 130 runs line 110 program| >130 CALL EXECUTE(9838)

Line 140 loads the assembly | >140 CALL LOAD(9838,47,0,38,1

program shown below. VMBW | 14,4,32,32,36,3,128)

Line 150 loads registers with | >150 CALL LOAD(12032,0,0,48,0

VDP address, Buffer, Length. | ,2,255)

Line 160 runs line 140 program| >160 CALL EXECUTE(9838)

Line 170 put a command in here| >170 CALL VCHAR(1,1,32,768)

Line 180 loops to line 160 | >180 GOTO 160

HEX ADDRESS|HEX VALUE|ASSEMBLY COMMAND EQUIVALENT

>266E >2F00 DATA >2F00 (workspace area address)

>2670 >2672 DATA >2672 (start execution address)

>2672 >0420 BLWP (first executed command)

>2674 >202C @VMBR (or >2024 VMBW)

>2676 >0380 RTWP

-------------------------------------------------------------

>2F00 >0000 REGISTER 0 (VDP address)

>2F02 >3000 REGISTER 1 (RAM buffer address)

>2F04 >02FF REGISTER 2 (length of text)

Normal XB using LINK.

Initialize for Assembly. | >100 CALL INIT

Load support routine. | >110 CALL LOAD("DSK1.TEST")

LINK to program. | >120 CALL LINK("GO")

RXB EXECUTE EXAMPLE. |

Initialize for Assembly. | >100 CALL INIT

Load support routine. | >110 CALL LOAD("DSK1.TEST")

EXECUTE program address. | >120 CALL EXECUTE(13842)

EXECUTE does no checking so the address must be correct.

The LINK method finds the name and uses the 2 byte address

after the name to run the Assembly. EXECUTE just runs the

address without looking for a name thus faster.

Options.

Dependent on Programmers use and skill.

[+adamantyr]

Here's a question... just how hard would it be to make the 32K (and maybe even SAMS) a mod for a TI console? Is it too tied into the side-port circuitry to be viable?

[+mizapf]

There are 32K mods for the console. I had one.

[+arcadeshopper]

Here's a question... just how hard would it be to make the 32K (and maybe even SAMS) a mod for a TI console? Is it too tied into the side-port circuitry to be viable?

 

uhm..did you miss the hardware project for the quarter thread? 32k in the console the 32k sicecar came out just a few months after this was popular

 

I sell the chips needed on my site.. also theres a pcb for making it easier on osh park

 

Greg