33 replies to this topic

[retroclouds]

Well today I finally managed to package the first official release of spectra².

http://www.retroclou...a2/spectra2.zip.

It's everything you'll ever need for writing your own TI-99/4A arcade game

Seriously, I don't expect too see any new games soon. However if you do plan on writing a game in TMS-9900 assembly language then you might want to check out the library.
There are some examples included. With the permission of Owen I also included the source code for the cartridge version of Honeycomb Rapture.

Check out the reference manual here.

[matthew180]

Very cool! These kinds of tools are definitely needed in our small community. I just wish more people would seriously consider assembly language instead of thinking it too hard, strange, or esoteric. In reality assembly is fun, very rewarding, and very straight forward.

Anyway, excellent job!

[Opry99er]

Can't wait to DL and play!!! Congratulations Filip--- I'm very glad to see this released. I wish everyone knew how much time, work, effort, and love went into the development of SPECTRA2. Let's hope some folks give it a whirl!

Edited by Opry99er, Tue Mar 8, 2011 2:08 PM.

[ti99userclub]

GREAT !!!

You would not have chosen a better day for release this wonderful work!

You made me a present unintentionally ... Today is my birthday! ... ThankYou!

[rocky007]

ti99userclub, on Tue Mar 8, 2011 3:26 PM, said:

GREAT !!!

You would not have chosen a better day for release this wonderful work!

You made me a present unintentionally ... Today is my birthday! ... ThankYou!

Happy Birthdayyyyyyyyyyyyyy



thanks retroclouds for this great job i already checked the user manual, i definetively will try something soon... your 'step by step" exemple is great for people like me

Edited by rocky007, Tue Mar 8, 2011 5:02 PM.

[ti99userclub]

rocky007, on Tue Mar 8, 2011 4:58 PM, said:

Happy Birthdayyyyyyyyyyyyyy

Thankyou

rocky007, on Tue Mar 8, 2011 4:58 PM, said:

thanks retroclouds for this great job i already checked the user manual, i definetively will try something soon... your 'step by step" exemple is great for people like me

yes i agree... it's a real good job and manual... i hoping i can be able to understand something of the assembler using "step by step"

[unhuman]

matthew180, on Tue Mar 8, 2011 1:42 PM, said:

Very cool! These kinds of tools are definitely needed in our small community. I just wish more people would seriously consider assembly language instead of thinking it too hard, strange, or esoteric. In reality assembly is fun, very rewarding, and very straight forward.

Anyway, excellent job!

Yeah, I'm gonna give in... I just need to find a decent entry point and probably a giant block of time. But I'm past the denial stage.

[retroclouds]

ti99userclub, on Tue Mar 8, 2011 3:26 PM, said:

GREAT !!!

You would not have chosen a better day for release this wonderful work!

You made me a present unintentionally ... Today is my birthday! ... ThankYou!

cool! Happy birthday man!

[retroclouds]

Thank you all for the kind words. A rather large amount of time was spent on the manual and I hope you with get some use of it.
I still have a few things in mind for a future 1.1 release, but more on that at a later time.

Also might try doing a step-by-step video tutorial on the assembly process, etc.
But I'm an absolute beginner on video tutorials, so that'll be fun

[retroclouds]

matthew180, on Tue Mar 8, 2011 1:42 PM, said:

Very cool! These kinds of tools are definitely needed in our small community. I just wish more people would seriously consider assembly language instead of thinking it too hard, strange, or esoteric. In reality assembly is fun, very rewarding, and very straight forward.

Anyway, excellent job!

Thanks, yes assembly language *really* is fun. And not that hard if you use the classic99 or MESS debugger. You can set breakpoints, single-step through your running program and actually see what is happening. A great learning tool

[sometimes99er]

Will take time to try out your library. I glanced the contents and see room for math and bitmap libraries. Not that I'm any good at that, but if I dig up gold anywhere, I'll let you have it for further twisting.

[marc.hull]

retroclouds, on Wed Mar 9, 2011 12:02 AM, said:

A rather large amount of time was spent on the manual.....

That may be the understatement of the year ! Excellent job, I perused it a bit last night and am impressed. Did no go in depth too much so have one question. Is it possible to pluck certain routines from your library to use or is it all or nothing ?
At any rate, impressive job Retro....

[retroclouds]

marc.hull, on Wed Mar 9, 2011 8:57 AM, said:

retroclouds, on Wed Mar 9, 2011 12:02 AM, said:

A rather large amount of time was spent on the manual.....

That may be the understatement of the year ! Excellent job, I perused it a bit last night and am impressed. Did no go in depth too much so have one question. Is it possible to pluck certain routines from your library to use or is it all or nothing ?
At any rate, impressive job Retro....

Thanks

Absolutely, it's possible to just pick the routines you need. The subroutines with a dependency have that listed in the subroutine description.
Example: the PUTBOX subroutine on page 97 has 2 dependencies listed: YX2PNT and XFILV.
You do not need to check if YX2PNT or XFILV again have dependencies on their own. In that case I would have listed it on page 97.
You will need the RUNLIB subroutine, because it does initialisation stuff, prepares the CONFIG register and loads some machine code into scratchpad memory.

The idea is that when starting work, you just include the RUNLIB.a99
Once you start optimizing for space you just remove any unused parts.

[trev2005]

I've been starting off a machine language game project over the last few days and a day or two into it spectra2 was released so I thought I'd take a look. Thanks retroclouds for providing such a useful, well thought-out and professional product! After checking it out I've realised just how much of a leg-up the library is in an arcade game project. It really frees the author up to be creative rather than have to deal with the necessary foundations. I'm definitely going to use spectra2 from now on and should I find that I need to/can add anything I'll feed it back to you to decide whether it's something worth including.

I'm working on a multi-bank cartridge so I'm assuming that the best idea is to include all of spectra2 in Bank 0 as the default bank, initialise the library from there and then to copy portions of spectra2 library code into other banks as required for their own routines?


Hopefully I'll have something to show soon - I'm sure it would be a lot sooner than it would be without spectra2, thanks and thanks again!

[retroclouds]

trev2005, on Thu Mar 10, 2011 10:06 AM, said:

I've been starting off a machine language game project over the last few days and a day or two into it spectra2 was released so I thought I'd take a look. Thanks retroclouds for providing such a useful, well thought-out and professional product! After checking it out I've realised just how much of a leg-up the library is in an arcade game project. It really frees the author up to be creative rather than have to deal with the necessary foundations. I'm definitely going to use spectra2 from now on and should I find that I need to/can add anything I'll feed it back to you to decide whether it's something worth including.

I'm working on a multi-bank cartridge so I'm assuming that the best idea is to include all of spectra2 in Bank 0 as the default bank, initialise the library from there and then to copy portions of spectra2 library code into other banks as required for their own routines?

Hopefully I'll have something to show soon - I'm sure it would be a lot sooner than it would be without spectra2, thanks and thanks again!

A multi-bank cartridge project, now that sounds cool. And that's an interesting question really.

There are many options (leaving 32K or mini-memory out of the picture):

1) Custom-make a spectra² library for each bank, only containing the subroutines you actually use in that bank.
Doing so will squeeze the most out of the 8K per bank for you. That's basically what I did with Pitfall! (using spectra¹, but the idea stays the same)
There are some drawbacks and I'm not sure if I would go down that road again. Keeping track of the subroutine locations can be *quite annoying* and that's an understatement
Suppose you use the subroutine PUTBOX. Due to the nature of the game you need to call it in BANK 0 and BANK 1. The thing is that in BANK 0 the routine will most likely be at another location as in BANK 1.
There are no TMS9900 assemblers supporting multi-bank images. So you have to manually keep track of the memory addresses for each subroutine.
I made a small utility to deal with that while working on Pitfall.
Anyway, for further details you might want to check my document "Building a multi-bank ROM image".
I suppose there are different solutions to the issue. Wonder how Mark handles this in TurboForth (16K ROM image if I'm not mistaking).


2) Build a custom spectra² and keep it the same for all banks.
The advantage here is that you won't have to go through the "where's my subroutine" crap. They will be at the exact same location in every bank.
Jon's cartridge board now easily support up-to 64K EPROMS. I'd rather pay a few extra $$ for the EPROM and cut-down on *many* hours of development/search/debug time.


3) Build a custom spectra² and keep it the same for all banks, except for your data banks. That's a combination of option 1 & 2.
That's the solution I'll be using for Tutankham. I'll have a custom bank for loading pattern data and maze data. It will only contain a small part of spectra² code.
The banks where the game code resides will share the same custom spectra² code.


Hope this helps


EDIT: Just today I learned that the classic99 debugger now has better support for developing multi-bank cartridges. You really need to check that out.

[trev2005]

I went with the mini-customised Spectra2 in the data bank with the untouched library in my main bank 0. I'm trying to keep all of the bulk data separate which is why, although my code doesn't need a multi-bank setup, I decided to start with two banks and see how it goes.

For managing the routines in different banks, I'm trying out a branch table just after the cartridge header in each bank that stores branch instructions to the routines in that bank. Then I branch to the routines indirectly through the table branch instructions. I copy the branch table labels into an include file for other banks when a new routine is added. If I need to change anything I don't need to recompile the other banks unless there's an addition to the branch table for a new routine as the table labels are frozen. I'm thinking that I can then remove the branch table by moving the labels to the actual routines when it's all stable at some later time.

Spectra2 has really saved me so much effort and it's letting me concentrate on getting used to the TMS9900 coming from a 6502 mainly. I've only found one issue to now - in the YX2PX / YX2PXX routine I was getting X pixels a little offset to the character positions and found that I needed to clear TMP1 for it work correctly. I added the line in the Spectra2 library:-

YX2PX   MOV   @WYX,TMP0
YX2PXX  MOV   R11,TMP2              ; Save return address
        SWPB  TMP0                  ; Y<->X<
        CLR   TMP1  ; Clear ready for shift
        MOVB  TMP0,TMP1 			; Copy X to TMP1
...
...

Really I find at the moment that every time I try to add something I break something so progress is slow but without the runtime library I'd be nowhere. Thanks again retroclouds!

[retroclouds]

Thanks for the update trev, I appreciate it a lot.
Yes, you squashed a bug there, I'll add the fix to the 1.1 release

Looking forward seeing what you come up with

[retroclouds]

I want to shutdown my old spectra¹ download page on sourceforge.
That's why I put up this new download page.

Hey, a little publicity now and then doesn't harm

[retroclouds]

I'm currently working on the v1.1 spectra² release, mainly because I figured there was still some stuff missing I wanted for Tutankham

So here are the changes I did:

* Better support for virtual screens. All high level subroutines will now support screen areas up to 255 rows and 255 columns.

* Some changes to scratchpad memory again. I reintroduced the "columns per row" memory location.
This was required for better support of the virtual screens.

* Introduced 3 memory locations called WAUX1, WAUX2, WAUX3. Basically it's auxilary storage for many of the spectra subroutines.
By using these I'm able to make some of the subroutines more compact.

* Completely reworked the PUTBOX subroutine. You can now vertically/horizontally repeat a box.
A box itself is basically a rectangular area containing a set of tiles.
I see the PUTBOX subroutine as a good way to draw screens in a very compact way.
In Tutankham PUTBOX will draw a complete level in VRAM memory. Scrolling will be done by just copying the relevant parts to the screen area.

* In addition to the virtual keyboard, there is now a full keyboard scan routine. I'm not certain if it will be included in the runlib.a99 file or if it will be an extra file. Kinda like a plugin.



I want the code size of the spectra² 1.1 release to be smaller or equal to the existing version.

[matthew180]

That is a cool library! Makes me want to write a game. :-)

[Willsy]

retroclouds, on Thu Mar 10, 2011 1:48 PM, said:

I made a small utility to deal with that while working on Pitfall.
Anyway, for further details you might want to check my document "Building a multi-bank ROM image".
I suppose there are different solutions to the issue. Wonder how Mark handles this in TurboForth (16K ROM image if I'm not mistaking).

I wrote two little utility routines in scratch pad. One routine, called BANK1 jumps to a routine in bank 1 from bank 0. The other routine, called RETB0 returns to where it was in Bank 0. TurboForth only ever calls from bank 0 to bank 1. Never from bank 1 to bank 0.

;BANK1
; routine to perform a bank switch and branch
; this routine is copied to PAD at startup
bank1	mov *r11+,r12	        ; get branch address
	clr @>6000		; select bank 1
	b *r12			; branch to the desired address

;RETB0
; returns to the caller in bank 0
retb0   clr @>6002              ; select bank 0
        b *r11                  ; return to caller

Note: The above code must be in scratchpad. You can then "branch and link" to subroutines in bank1 from bank0:

    BL @BANK1
    DATA DOSYS  ; call DOSYS in bank1

The code in bank1 just branches to RETB0 to neatly return to the caller in bank0:

DOSYS ...
      ...
      ...
      B @RETB0 ; return to caller in bank 0

Et voila. This approach avoids the requirement of having to duplicate routines at identical memory addresses in both banks. You can treat the bank0/bank1 as though it's one big 16K address space. It's handled by the little helper routines.

Works for me

Mark

[retroclouds]

So I'm thinking on how to enhance spectra² while keeping code size as small as possible.

Features I'm gonna include:

* Viewport handling
This is basically the key to scrolling and I now have a clear picture on how this is gonna work.
You draw the full map in a virtual screen once and then use a "viewport" for displaying part of the virtual screen on the real screen.
Combined with the TMGR thread functionality will make it easy to scroll through big maps.
I need this functionality for Tutankham. It'll replace the clumsy custom code I now use for that game.

* Complete the speech synthesizer functionality (speak words available in the speech rom). I've also been thinking about moving the speech
player from runlib.a99 to a separate plugin.

* For keeping a moderate code size, I've been thinking about replacing many of the constants used in spectra² by equates that point
to values stored in the TI-99/4A console ROM. Doing so will save me at least 50 to 60 bytes. And the console ROM is on the 16-bit bus, so will be a
bit faster. The disadvantage is that it's not gonna work if there are multiple ROM revisions out there. As far as I know that's not the case.

* I'm gonna need to bug-fix my sound player to make it fully compatible with the sound player inside the console ISR. I currently don't support branches
in my player. Only learned that just today.


EDIT: My target platform is the unexpanded TI-99/4A console. That is why the virtual screens reside in VRAM.
However it should be quite easy to draw the virtual screens in RAM as well. This is an option I'm gonna keep for later, in case cartridges with RAM start popping up

Edited by retroclouds, Wed May 18, 2011 12:21 PM.

[retroclouds]

On a sidenote: I've also been thinking about a PC "compression" utility that converts Magellan maps to pattern data, strings & PUTBOX data statements.
Basically the tool should identify optimal (repeating) rectangular areas. I don't have a clue what algorithms are available to accomplish that task.

That will be fun

[marc.hull]

retroclouds, on Wed May 18, 2011 12:07 PM, said:

So I'm thinking on how to enhance spectra² while keeping code size as small as possible.

Features I'm gonna include:

* Viewport handling
This is basically the key to scrolling and I now have a clear picture on how this is gonna work.
You draw the full map in a virtual screen once and then use a "viewport" for displaying part of the virtual screen on the real screen.
Combined with the TMGR thread functionality will make it easy to scroll through big maps.
I need this functionality for Tutankham. It'll replace the clumsy custom code I now use for that game.

* Complete the speech synthesizer functionality (speak words available in the speech rom). I've also been thinking about moving the speech
player from runlib.a99 to a separate plugin.

* For keeping a moderate code size, I've been thinking about replacing many of the constants used in spectra² by equates that point
to values stored in the TI-99/4A console ROM. Doing so will save me at least 50 to 60 bytes. And the console ROM is on the 16-bit bus, so will be a
bit faster. The disadvantage is that it's not gonna work if there are multiple ROM revisions out there. As far as I know that's not the case.

* I'm gonna need to bug-fix my sound player to make it fully compatible with the sound player inside the console ISR. I currently don't support branches
in my player. Only learned that just today.


EDIT: My target platform is the unexpanded TI-99/4A console. That is why the virtual screens reside in VRAM.
However it should be quite easy to draw the virtual screens in RAM as well. This is an option I'm gonna keep for later, in case cartridges with RAM start popping up

Is your sound layer going to allow a program to interrupt a song, play another sequence and then continue to original song to prevent the annoying Burger Time music situation ?

I too have been goofing around with Magellan lately and trying to come up with some simple compression. I came up with a scheme that is pretty simple and pretty effective. For every repeating byte of three or more I replace the string of like bytes with.....


0---> signals a repeating pattern.
#---> how many bytes to write.
C---> character to write.

Not very sophisticated and definitely not mind blowing but pretty effective.

I would suspect most screens are composed of repeating patterns. My new projects has about 28 screens of 768 bytes. the smallest compressed one is 44 bytes while the largest is 444. Works for my needs but with some bit twiddeling you could probably go smaller.

[retroclouds]

marc.hull, on Wed May 18, 2011 12:44 PM, said:

Is your sound layer going to allow a program to interrupt a song, play another sequence and then continue to original song to prevent the annoying Burger Time music situation ?

That's currently not possible. It's actually a good idea and it wouldn't take much effort.
I just have to copy a few pointers in scratchpad RAM and then when the new tune is done, restore the pointers and the sound player will resume the previous melody.
The tricky part is, that if I implement it, it may not use any scratchpad RAM if not in use.
Perhaps I should start thinking about reserving a small VRAM area for storing variables using in slow operations.

However, I'm trying to do my very best to keep the whole thing as easy as possible, so have to consider.
Not that there are much assembler programmers out there, but you never know someone might actually try the library

marc.hull, on Wed May 18, 2011 12:44 PM, said:

I too have been goofing around with Magellan lately and trying to come up with some simple compression. I came up with a scheme that is pretty simple and pretty effective. For every repeating byte of three or more I replace the string of like bytes with.....

0---> signals a repeating pattern.
#---> how many bytes to write.
C---> character to write.

Not very sophisticated and definitely not mind blowing but pretty effective.

I would suspect most screens are composed of repeating patterns. My new projects has about 28 screens of 768 bytes. the smallest compressed one is 44 bytes while the largest is 444. Works for my needs but with some bit twiddeling you could probably go smaller.

Well it doesn't have to be sophisticated and mind blowing to be effective
I thought about a similar approach for the Tutankham levels, but the combination of tiles used did not make it look very promising.
That's why I came up with the "PUTBOX" approach.
So the type of compression basically depends on how the screen looks like.

In tutankham they for example have a lot of repeating tiles as seen in the screenshot below:

 tutankham level 1 pattern lookup.PNG   115.06K   13 downloads

The idea for doing the compression utility was after I implemented the PUTBOX subroutine.
It just seems to fit so well that I will have to give it a spin.

The difficult part here is on the PC side: letting a program identify repeating vertical/horizontal blocks.
I haven't done much with algorithms yet, so that might be interesting.
Is it gonna work, I dunno. We'll see.


EDIT: The PC utility mentioned here will probably not be used for Tutankham. If all works well we will have completely new
upgraded graphics for Tutankham. I'm in touch with a very talented 9918 pixel artist who is willing to do some
TI-99/4A work