+retroclouds Posted March 8, 2011 Share Posted March 8, 2011 Well today I finally managed to package the first official release of spectra2. http://www.retroclouds.de/spectra2/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. 2 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 8, 2011 Share Posted March 8, 2011 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! Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 8, 2011 Share Posted March 8, 2011 (edited) 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 March 8, 2011 by Opry99er Quote Link to comment Share on other sites More sharing options...
ti99iuc Posted March 8, 2011 Share Posted March 8, 2011 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! Quote Link to comment Share on other sites More sharing options...
rocky007 Posted March 8, 2011 Share Posted March 8, 2011 (edited) 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 March 8, 2011 by rocky007 Quote Link to comment Share on other sites More sharing options...
ti99iuc Posted March 8, 2011 Share Posted March 8, 2011 Happy Birthdayyyyyyyyyyyyyy Thankyou 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" Quote Link to comment Share on other sites More sharing options...
unhuman Posted March 9, 2011 Share Posted March 9, 2011 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. Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 9, 2011 Author Share Posted March 9, 2011 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! 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 9, 2011 Author Share Posted March 9, 2011 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 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 9, 2011 Author Share Posted March 9, 2011 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 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted March 9, 2011 Share Posted March 9, 2011 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. Quote Link to comment Share on other sites More sharing options...
marc.hull Posted March 9, 2011 Share Posted March 9, 2011 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.... Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 10, 2011 Author Share Posted March 10, 2011 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. Quote Link to comment Share on other sites More sharing options...
RetroElectroDad Posted March 10, 2011 Share Posted March 10, 2011 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! Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 10, 2011 Author Share Posted March 10, 2011 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 spectra2 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 spectra1, 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 spectra2 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 spectra2 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 spectra2 code. The banks where the game code resides will share the same custom spectra2 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. Quote Link to comment Share on other sites More sharing options...
RetroElectroDad Posted March 21, 2011 Share Posted March 21, 2011 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! 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 21, 2011 Author Share Posted March 21, 2011 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 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 23, 2011 Author Share Posted March 23, 2011 I want to shutdown my old spectra1 download page on sourceforge. That's why I put up this new download page. Hey, a little publicity now and then doesn't harm Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted May 17, 2011 Author Share Posted May 17, 2011 I'm currently working on the v1.1 spectra2 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 spectra2 1.1 release to be smaller or equal to the existing version. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted May 18, 2011 Share Posted May 18, 2011 That is a cool library! Makes me want to write a game. :-) Quote Link to comment Share on other sites More sharing options...
Willsy Posted May 18, 2011 Share Posted May 18, 2011 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 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted May 18, 2011 Author Share Posted May 18, 2011 (edited) So I'm thinking on how to enhance spectra2 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 spectra2 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 May 18, 2011 by retroclouds Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted May 18, 2011 Author Share Posted May 18, 2011 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 Quote Link to comment Share on other sites More sharing options...
marc.hull Posted May 18, 2011 Share Posted May 18, 2011 So I'm thinking on how to enhance spectra2 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 spectra2 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. 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted May 19, 2011 Author Share Posted May 19, 2011 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 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: 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 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.