Subject: Subroutine library

From: Owen Brand <[email-masked]>
Date: Thu, 28 Jan 2010 21:02:32 -0500

Hey guys--- I remember someone talking about a library of assembly  
subroutines aimed at game programming... At the time, I was not able  
to get into that, as I was on the road... I am in need now.  I believe  
it was Karsten or Filip... Maybe Ben... Anyway, I would love the  
opportunity to view those.... What was the name of that library?

Owen Brand
**Oprysoft**
Opry99er.com

---

From: mark wills <[email-masked]>
Date: Thu, 28 Jan 2010 22:03:50 -0800 (PST)

If you want to hi-res in BASIC and be compatible with others, you could do a lot worse than the AWESOME "The Missing Link"

Frankly quite brilliant! I remember it was BIG news in the UK when that landed!

M

>
>From: Owen Brand <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Sent: Fri, 29 January, 2010 3:02:32
>Subject: [TI994A] Subroutine library
>
> >
>
>
>
>
>  >
>>      
> 
>>subroutines aimed at game programming. .. At the time, I was not able

---

From: Owen Brand <[email-masked]>
Date: Fri, 29 Jan 2010 04:32:51 -0500

I saw that on whtech yesterday but didn't have a clue what it was....  
Sure wish I had a good directory of that site. Anyway, I was able to  
DL some cool Info....  Found a complete list of XB "ERRORS" that I  
DLed.... I got a digital copy of the XBII+ manual that I can search  
(Text under).... But I really went looking for entirely different  
pieces of info--- shut down!!!!  :). But sometimes you gotta "swim  
through a river of $&@* to come out clean on the other side..." (name  
the movie).

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 29, 2010, at 1:03 AM, mark wills <[email-masked]>  
wrote:

> If you want to hi-res in BASIC and be compatible with others, you  
> could do a lot worse than the AWESOME "The Missing Link"
>

---

From: "killroy732000" <[email-masked]>
Date: Fri, 29 Jan 2010 18:16:18 -0000

Hi Owen,

that might have been me. I made a library of assembly routines
for writing arcade games in assembly language. It's called SPECTRA.

Here is the URL, check out the PDF for details:
http://spectra99.sourceforge.net/

Currently working on the next beta version that I hope to release
in March. Note that this library doesn't focus on
interacting with Extended Basic. It's target are pure assembly games,
besides providing graphics and sound routines it also contains a
scheduler for running multiple threads.

As my library uses a software stack approach it might
be suited for inclusion in code written in C (or perhaps Forth?).
I want to look in programming C for the TI (using a cross compiler) 
and see how well SPECTRA integrates.

Filip

---

From: Owen Brand <[email-masked]>
Date: Fri, 29 Jan 2010 13:40:54 -0500

SPECTRA!!!  That's what it was.  Well, as I am not yet up to the task  
of writing an entire game in assembly, these routines may or may not  
be much use to me...  I am looking for one specific routine, and I  
very well may need to do it "by hand" as Tursi put it...  I mentioned  
this in the group yesterday, but I'll pop it up again...

100 FOR I=1 TO 28 :: CALL COINC(#1,I,10):: NEXT I

Again, I probably won't use 28 SPRITEs at any one time, so it would  
need to be adjusted to only check for active SPRITEs.... Essentially,  
I want a
CALL COINC(#1,ALL) routine.... I am looking into it now, doing some  
reading, learning.  Thanks for your help, guys.  :) I think this is do- 
able.  Tursi frigging rocks

Owen Brand
**Oprysoft**
Opry99er.com

---

From: mark wills <[email-masked]>
Date: Fri, 29 Jan 2010 19:54:54 -0800 (PST)

>100 FOR I=1 TO 28 :: CALL COINC(#1,I,10) :: NEXT I

Yeah, I can see where you coming from... BUT... Coding that in assembly won't gain you anything I'm afraid. This is because the CALL LINK statement in XB is itself slooooow.... Passing parameters into and back out of your program (for example) is slow, and also, it has to search the REF/DEF table every time to find the routine.

A better way would be to write the routine to hook into the user interrupt. Then, you don't CALL LINK it all - it would always be running. And have it pass information back to you by poking it into memory. You would then read it with a CALL PEEK or whatever it's called.

But, there you go again, the CALL PEEK is itself slow. Because the address is converted to Radix 100, and so is the return value!

We might just have to code something up and suck it and see...

Writing the code is easy enough. I have limited knowledge of the XB VDP memory layout though. (Classic99 debugger to the rescue, and TI994W too!) It's the *interface* between XB and Assembly that is the pain...

M

>Sent: Fri, 29 January, 2010 19:40:54
>Subject: Re: [TI994A] Re: Subroutine library
>
> >
>
>
>
>
>  >
>>      
> 
>SPECTRA!!!  That's what it was.  Well, as I am not yet up to the task of writing an entire game in assembly, these routines may or may not be much use to me...  I am looking for one specific routine, and I very well may need to do it "by hand" as Tursi put it...  I mentioned this in the group yesterday, but I'll pop it up again...
>
>
>100 FOR I=1 TO 28 :: CALL COINC(#1,I,10) :: NEXT I
>
>
>Again, I probably won't use 28 SPRITEs at any one time, so it would need to be adjusted to only check for active SPRITEs.... Essentially, I want a 
>CALL COINC(#1,ALL) routine.... I am looking into it now, doing some reading, learning.  Thanks for your help, guys.  :) I think this is do-able.  Tursi frigging rocks
>
>Owen Brand
>**Oprysoft**
>Opry99er.com
>
>On Jan 29, 2010, at 1:16 PM, "killroy732000" <filip.van-vooren@ gmx.net> wrote:
>
>
>>>
>>
>>
>>  >>
>>
>> 
>>>>      
>> 
>>Hi Owen,
>>
>>http://spectra99. sourceforge. net/
>>
>>>>--- In TI994A@yahoogroups. com, Owen Brand <owenbrand@. ..> wrote:
>>>>>

---

From: Owen Brand <[email-masked]>
Date: Sat, 30 Jan 2010 00:35:12 -0500

Well Mark, I appreciate your help and support.  :) Lets get that GROM  
emulator thing I linked to.... It's only at 500 buckaroos.  :)

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 29, 2010, at 10:54 PM, mark wills <[email-masked]>  
wrote:

> Yeah, I can see where you coming from... BUT... Coding that in  
> assembly won't gain you anything I'm afraid. This is because the  
> CALL LINK statement in XB is itself slooooow.... Passing parameters  
> into and back out of your program (for example) is slow, and also,  
> it has to search the REF/DEF table every time to find the routine.
>
> A better way would be to write the routine to hook into the user  
> interrupt. Then, you don't CALL LINK it all - it would always be  
> running. And have it pass information back to you by poking it into  
> memory. You would then read it with a CALL PEEK or whatever it's  
> called.
>
> But, there you go again, the CALL PEEK is itself slow. Because the  
> address is converted to Radix 100, and so is the return value!
>
> Writing the code is easy enough. I have limited knowledge of the XB  
> VDP memory layout though. (Classic99 debugger to the rescue, and  
> TI994W too!) It's the *interface* between XB and Assembly that is  
> the pain...
>
> M
>
> SPECTRA!!!  That's what it was.  Well, as I am not yet up to the  
> task of writing an entire game in assembly, these routines may or  
> may not be much use to me...  I am looking for one specific routine,  
> and I very well may need to do it "by hand" as Tursi put it...  I  
> mentioned this in the group yesterday, but I'll pop it up again...
>
> need to be adjusted to only check for active SPRITEs....  
> Essentially, I want a
> reading, learning.  Thanks for your help, guys.  :) I think this is  
> do-able.  Tursi frigging rocks
>
> Owen Brand
> **Oprysoft**
> Opry99er.com
>
> On Jan 29, 2010, at 1:16 PM, "killroy732000" <filip.van-vooren@ gmx.net 
> > wrote:
>
>>
>> Hi Owen,
>>

---

From: "Ksarul" <[email-masked]>
Date: Sat, 30 Jan 2010 02:00:59 -0500

BTW, if you don't get that one, I have already done the layout for the EGROM
box. . .which uses similar discrete components to simulate the GROM.

Jim

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Owen Brand
Sent: Saturday, January 30, 2010 12:35 AM
To: [email-masked]
Subject: Re: [TI994A] Owens AL requirement

Owen Brand

**Oprysoft**

Opry99er.com

>100 FOR I=1 TO 28 :: CALL COINC(#1,I,10) :: NEXT I

Yeah, I can see where you coming from... BUT... Coding that in assembly
won't gain you anything I'm afraid. This is because the CALL LINK statement
in XB is itself slooooow.... Passing parameters into and back out of your
program (for example) is slow, and also, it has to search the REF/DEF table
every time to find the routine.

A better way would be to write the routine to hook into the user interrupt.
Then, you don't CALL LINK it all - it would always be running. And have it
pass information back to you by poking it into memory. You would then read
it with a CALL PEEK or whatever it's called.

But, there you go again, the CALL PEEK is itself slow. Because the address
is converted to Radix 100, and so is the return value!

Writing the code is easy enough. I have limited knowledge of the XB VDP
memory layout though. (Classic99 debugger to the rescue, and TI994W too!)
It's the *interface* between XB and Assembly that is the pain...

M

SPECTRA!!!  That's what it was.  Well, as I am not yet up to the task of
writing an entire game in assembly, these routines may or may not be much
use to me...  I am looking for one specific routine, and I very well may
need to do it "by hand" as Tursi put it...  I mentioned this in the group
yesterday, but I'll pop it up again...

Again, I probably won't use 28 SPRITEs at any one time, so it would need to
be adjusted to only check for active SPRITEs.... Essentially, I want a 

CALL COINC(#1,ALL) routine.... I am looking into it now, doing some reading,
learning.  Thanks for your help, guys.  :) I think this is do-able.  Tursi
frigging rocks

Owen Brand

**Oprysoft**

 <http://Opry99er.com> Opry99er.com

On Jan 29, 2010, at 1:16 PM, "killroy732000" <filip.van-vooren@
<mailto:[email-masked]> gmx.net> wrote:

Hi Owen,

Here is the URL, check out the PDF for details:
 <http://spectra99.sourceforge.net/>  <http://spectra99> http://spectra99.
sourceforge. net/

Filip

--- In TI994A@yahoogroups. com <mailto:TI994A%40yahoogroups.com> , Owen
Brand <owenbrand@. ..> wrote:
>  <http://Opry99er.com>  <http://Opry99er.com> Opry99er.com
>

---

From: mark wills <[email-masked]>
Date: Fri, 29 Jan 2010 22:41:09 -0800 (PST)

Do you have a circuit/logic diagram for the GROM address stuff?

>
>From: Ksarul <[email-masked]>
>Sent: Sat, 30 January, 2010 8:00:59
>Subject: RE: [TI994A] Owens AL requirement
>
> >
>
>
>
>
>  >
>>      
> 
>>
>
>
>
>
>>
>BTW, if you don’t get that one, I have
>already done the layout for the EGROM box. . .which uses similar discrete
>components to simulate the GROM.
> 
>Jim
> 
>>
>>
________________________________
 >
>From:TI994A@yahoogroups. com [mailto: TI994A@yahoogroups. com ] On Behalf Of Owen Brand
>To: TI994A@yahoogroups. com
>Well Mark, I appreciate your help and support.  :) Lets get that
>GROM emulator thing I linked to.... It's only at 500 buckaroos.  :)
>
>>Owen Brand
>>
>**Oprysoft**
>>
>Opry99er.com
>>
>
>>On Jan 29, 2010, at 10:54 PM, mark wills <markrobertwills@ yahoo.co. uk>
>wrote:
>>>
>>>>
>>  
>>>>
>>>>
>>>>
>>>>Yeah, I can see where you coming from... BUT... Coding that in assembly won't
>>gain you anything I'm afraid. This is because the CALL LINK statement in XB is
>>itself slooooow.... Passing parameters into and back out of your program (for
>>example) is slow, and also, it has to search the REF/DEF table every time to
>>find the routine.
>>
>>Then, you don't CALL LINK it all - it would always be running. And have it pass
>>information back to you by poking it into memory. You would then read it with a
>>CALL PEEK or whatever it's called.
>>
>>>>But, there you go again, the CALL PEEK is itself slow. Because the address is
>>converted to Radix 100, and so is the return value!
>>
>>>>Writing the code is easy enough. I have limited knowledge of the XB VDP memory
>>layout though. (Classic99 debugger to the rescue, and TI994W too!) It's the
>>*interface* between XB and Assembly that is the pain...
>>
>>>>M
>>>>>
>>>>>>
>>> 
>>>>>>
>>>From:Owen Brand
>>><owenbrand@opry99er. com>
>>>To: " TI994A@yahoogroups .com "
>>>< TI994A@yahoogroups. com >
>>>SPECTRA!!!  That's what it was.  Well, as I am not yet up to
>>>the task of writing an entire game in assembly, these routines may or may not
>>>be much use to me...  I am looking for one specific routine, and I very
>>>well may need to do it "by hand" as Tursi put it...  I mentioned
>>>need to be adjusted to only check for active SPRITEs.... Essentially, I want
>>>a 
>>>>>>

---

From: "Ksarul" <[email-masked]>
Date: Sat, 30 Jan 2010 12:39:07 -0500

I haven't pulled it out to a true circuit diagram-I took my EGROM box and
analyzed the original layout to build a new one in Express PCB.  I should be
able to convert that to a circuit diagram, and I will once I get some time
for it. . .

Jim

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
mark wills
Sent: Saturday, January 30, 2010 1:41 AM
To: [email-masked]
Subject: Re: [TI994A] Owens AL requirement

Jim

  _____  

From: TI994A@yahoogroups. com [mailto: TI994A@yahoogroups. com ] On Behalf
Of Owen Brand
Sent: Saturday, January 30, 2010 12:35 AM
To: TI994A@yahoogroups. com
Subject: Re: [TI994A] Owens AL requirement

Owen Brand

**Oprysoft**

Opry99er.com

M

From: Owen Brand <owenbrand@opry99er. com>
To: " TI994A@yahoogroups .com " < TI994A@yahoogroups. com >
Sent: Fri, 29 January, 2010 19:40:54
Subject: Re: [TI994A] Re: Subroutine library

Owen Brand

**Oprysoft**

Hi Owen,

Filip

---

From: Owen Brand <[email-masked]>
Date: Sun, 31 Jan 2010 15:35:20 -0500

Mark... How would I do this?  Write it into the user interrupt?  It is  
intriguing to me.  What address should I start with?  Also---how many  
subroutines can be written to the user interrupt?

***Sorry--- TMS9900 Virgin here.

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 30, 2010, at 1:41 AM, mark wills <[email-masked]>  
wrote:

> BTW, if you don’t get that one, I have already done the layout for t 
> he EGROM box. . .which uses similar discrete components to simulate  
> the GROM.
>
>
>
> Jim
>
>
>
> From: TI994A@yahoogroups. com [mailto: TI994A@yahoogroups. com ] On  
> Behalf Of Owen Brand
> On Jan 29, 2010, at 10:54 PM, mark wills <markrobertwills@ yahoo.co.  
> uk> wrote:
>
>>
>>
>> may not be much use to me...  I am looking for one specific  
>> routine, and I very well may need to do it "by hand" as Tursi put  
>> it...  I mentioned this in the group yesterday, but I'll pop it up  
>> again...
>>
>>
>>

---

From: "Tursi" <[email-masked]>
Date: Sun, 31 Jan 2010 12:39:49 -0800

I would disagree with that advice... go back and take another look at the 
code I wrote for you that automatically locks sprites to a boundary on the 
screen. It does a comparable amount of work to the COINC, and has a pretty 
negative impact on XB's performance. Unless you only tested one sprite per 
frame or something I think it would slow you down too much. Calling it on 
demand would be better IMO.

---

From: Owen Brand <[email-masked]>
Date: Sun, 31 Jan 2010 15:51:32 -0500

I remember that code--- it did create a drag on the smoothness of the  
game.  I was not aware that this particular method that Mark was  
describing was what you had in the test you wrote.  Thanks... I will  
continue to search for the optimization that best suits my need.   
Trying to assemble this compiled code right now.... If I can get a  
solid conversion, I will proceed to make up a library of compiled  
subroutines that interact with XB and make them available.  Thanks !!

Owen Brand
**Oprysoft**
Opry99er.com

---

From: ti99_forever <[email-masked]>
Date: Sun, 31 Jan 2010 14:20:07 -0800 (PST)

I will point out - put a varying # of sprites in motion, then run a loop printing numbers on the screen (so they scroll).
Check out what happens to the sprites. Some XB routines take a while to execute. I bet XB is very similar to TI Basic, in that the interrupts are only enabled at a certain point and longer instructions can hold an interrupt from occurring 60 times a second (50 in European consoles).

And then you have to code your user interrupt routine to finish in 1/60th of a second, unless you break the code across interrupts (this is a possibility that I've never tried). Otherwise, you will then slow Basic down.

Fun stuff, interrupts. Make it look like you have multiple processors, but you have to remember they are all running on a shared processor.

--- On Sun, 1/31/10, Tursi <[email-masked]> wrote:

> From: Tursi <[email-masked]>
> Date: Sunday, January 31, 2010, 3:39 PM
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>     [email-masked]
> 
> 
>

---

From: ti99_forever <[email-masked]>
Date: Sun, 31 Jan 2010 14:48:14 -0800 (PST)

I also need to point out that I've tried the "stop all sprites" when a COINC returned true to check them and restart them. Turned out rather jerky.

It is at this point you have to look at tradeoffs and optimizations.
Just focus on the "critical code" in your game loop.

Gee, Tursi, a profiler would be a nice addition to Classic99, wouldn't it? ;)

--- On Sun, 1/31/10, ti99_forever <[email-masked]> wrote:

> From: ti99_forever <[email-masked]>
> Date: Sunday, January 31, 2010, 5:20 PM
> I will point out - put a varying # of
> sprites in motion, then run a loop printing numbers on the
> screen (so they scroll).
> Check out what happens to the sprites. Some XB routines
> take a while to execute. I bet XB is very similar to TI
> Basic, in that the interrupts are only enabled at a certain
> point and longer instructions can hold an interrupt from
> occurring 60 times a second (50 in European consoles).
> 
> And then you have to code your user interrupt routine to
> finish in 1/60th of a second, unless you break the code
> across interrupts (this is a possibility that I've never
> tried). Otherwise, you will then slow Basic down.
> 
> Fun stuff, interrupts. Make it look like you have multiple
> processors, but you have to remember they are all running on
> a shared processor.
> 
> 
> > code I wrote for you that automatically locks sprites
> to a
> > boundary on the 
> > screen. It does a comparable amount of work to the
> COINC,
> > and has a pretty 
> > negative impact on XB's performance. Unless you only
> tested
> > one sprite per 
> > frame or something I think it would slow you down too
> much.
> > Calling it on 
> > >> A better way would be to write the routine to
> hook
> > into the user
> > >> interrupt. Then, you don't CALL LINK it all -
> it
> > would always be
> > >> running. And have it pass information back to
> you
> > by poking it into
> > >> memory. You would then read it with a CALL
> PEEK or
> > whatever it's
> > >> called.
> > 
> >  
> > 
> > 
> >

---

From: Owen Brand <[email-masked]>
Date: Sun, 31 Jan 2010 19:59:34 -0500

Yea... It occurs to me that I should focus on the game loop now....  
The graphics are good.... I just need to optimize where I can and  
tighten up what's there.... But I won't give up on this compiler  
yet... If I can write several small necessary subs that are "memory/ 
speed expensive" and put them into AL, I think I can get a little more  
speed out of the game.  But other than that, I am just going to start  
optimizing and re-thinking what is NECESSARY to keep the nature of the  
game in tact... The rest will be shed in the spirit of  
"speeeeeeeed".  :). I am happy with what I've been able to accomplish  
so far.  I have been able to push XB to the edge, pull back and  
rethink, push it again and rethink again.  I have learned so much in  
the development of this game.... No matter what happens concerning the  
game competition-- I am a far richer programmer for this experience.  :)

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 31, 2010, at 5:48 PM, ti99_forever <[email-masked]>  
wrote:

> I also need to point out that I've tried the "stop all sprites" when  
> a COINC returned true to check them and restart them. Turned out  
> rather jerky.
>

---

From: "Tursi" <[email-masked]>
Date: Sun, 31 Jan 2010 17:02:20 -0800

> Gee, Tursi, a profiler would be a nice addition to Classic99, wouldn't it? 

There is a profiler in Classic99. ;)

---

From: Gregory McGill <[email-masked]>
Date: Sun, 31 Jan 2010 17:09:45 -0800

Tursi is so good, he works retroactively.

G

On Sun, Jan 31, 2010 at 5:02 PM, Tursi <[email-masked]> wrote:

>
>
> > Gee, Tursi, a profiler would be a nice addition to Classic99, wouldn't
> it?
> > ;)
>

---

From: Owen Brand <[email-masked]>
Date: Sun, 31 Jan 2010 20:12:25 -0500

Wonder if he's good enough to work retroactively enough to convince TI  
not to stop production of the /4a.

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 31, 2010, at 8:09 PM, Gregory McGill <[email-masked]>  
wrote:

> > Gee, Tursi, a profiler would be a nice addition to Classic99,  
> wouldn't it?
> > ;)
>

---

From: Owen Brand <[email-masked]>
Date: Sun, 31 Jan 2010 20:26:47 -0500

Out of curiosity... What specifically does the profiler in Classic99 do?

Owen Brand
**Oprysoft**
Opry99er.com

---

From: "Tursi" <[email-masked]>
Date: Sun, 31 Jan 2010 17:32:49 -0800

> Out of curiosity... What specifically does the profiler in Classic99 do?

I was a little glib in my reply, it's a very basic thing. It's just a cycle 
counter. Specify the two addresses you are interested in, and it will count 
cycles between them and dump to the debug log, as well as maintaining hit 
count, minimum, maximum, and average statistics. ;)