Airshack

My head has been in the books too long. Where do I go to order FinalGROM99?

The 99/4 Equation Calculator menu option is evidence that this calculator company lacked vision and invited too many calculator engineers to the party. I'd be interested to hear about the decision to remove that (along with the calculator style overlay ready keyboard) from the 99/4A. Seems the calculator guys lost a battle but not before TI had already embarrassed themselves.

Wondering if any original TI Programmers are lurking about on AtariAge, or anywhere else? Just finished listening to a four part interview with Chuck Peddle the inventor of the 6502 CPU and Commodore PET. http://retrobits.libsyn.com/show-123-an-interview-with-chuck-peddle-part-i Wondering if any of our guys are still around and talking?

Hey Lee, Did I get it all? B @>0070 To GPL interpreter** GPL SCAN (Scan keyboard with return to GPL interpreter):* LI 11,>0070 Trick with return** Keybord scanning*KEYSCN MOV 11,@>83D8 Save R11 BL @PUSHGA Save GROM address to substack CLR 12 CRU 0 SBO >0015 Alpha lock MOVB @>8374,5 Keyboard mode SRL 5,8 MOV 5,6 JEQ >02EC 0 LI 0,>0FFF DEC 6 1 R0=>0FFF JEQ >02F4 LI 0,>F0FF DEC 6 2 R0=>F0FF JEQ >02F4 DEC 6 3 C 6,@>0072 JH >0382 >5? MOVB 6,@>8374 Keyboard mode 0 SWPB 6 MOVB 6,@>83C6 Keybord debounce (3=0, 4=1, 5=2) CLR 5 CLR 0 CLR 6 JMP >032E Mode 0,3,4,5 DATA >2925 LI 12,>0024 Mode 1,2 scan Joystick LDCR @>0405(5),3 CRU 06 and 07 LI 12,>0006 CLR 3 SETO 4 STCR 4,5 Fetch CRU SRL 4,9 JOC >0310 No fire key? MOVB @>02F1(5),@>83E7 Lbyte R3 SLA 4,1 AI 4,>16E0 GROM address Joystick table MOVB 4,@>0402(13) Write address MOVB @>83E9,@>0402(13) JMP >0322 MOVB *13,@>8376 Fetch values Y**~~Page 19: TI99/4A INTERN (Heiner Martin)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* MOVB *13,@>8377 and X MOV 3,3 Fire key ? JNE >03AA LI 1,>0005 Scan keys CLR 2 CLR 7 LI 12,>0024 SWPB 1 LDCR 1,3 Load CRU SWPB 1 LI 12,>0006 SETO 4 STCR 4,8 Fetch CRU INV 4 Invert bits MOV 1,1 0? JNE >0354 MOVB 4,7 ANDI 4,>0F00 SZC 0,4 JEQ >037A No key? MOV 1,1 Last loop? JNE >0360 MOV 5,5 Mode 1 or 2? JNE >037A MOV 2,2 Already a key? JNE >037A SETO 2 MOV 1,3 SLA 3,3 DEC 3 INC 3 SLA 4,1 Built key value in R3 JNC >036C MOV 1,1 JEQ >037A LI 1,>0001 Shorten loop DEC 1 JOC >0336 Smaller than 0? MOV 2,2 Key pressed? JNE >03AA CLR 6 Set pointer for no key MOVB 6,@>83C7 SETO 0 CB 0,@>83C8(5) JEQ >0394 BL @>0498 Time delay MOVB 0,@>83C8 MOVB 0,@>83C8(5) MOV 5,5 Mode 1 or 2? JNE >0478 End MOVB 0,@>83C9 MOVB 0,@>83CA JMP >0478 End**~~Page 20: TI99/4A INTERN (Heiner Martin)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* CB @>83E7,@>83C8(5) Same key as last time? JEQ >03E6 LI 6,>2000 Set GPL status BL @>0498 Time delay MOVB @>83E7,@>83C8 Set pointer (Lbyte R3) MOVB @>83E7,@>83C8(5) MOV 5,5 Mode 1 or 2 JNE >03E2 MOV 3,12 AI 12,>FFF8 JLT >03E2 LI 1,>0002 SRL 12,3 JOC >03DC DEC 1 MOVB @>83E7,@>83C8(1) MOVB 7,@>83C7 Last loop scanning on >83C7 MOVB @>83C7,7 LI 1,>17C0 GROM table mode 1 and 2 MOV 5,5 JNE >040E LI 1,>1790 GROM table CNTRL SLA 7,2 JOC >040E LI 1,>1760 GROM table FCTN SRL 7,15 JOC >040E LI 1,>1730 GROM table SHIFT DEC 7 JEQ >040E LI 1,>1700 GROM address table small letters A 3,1 +Key value MOVB 1,@>0402(13) Write address MOVB @>83E3,@>0402(13) JMP >041C MOVB *13,0 Values from GROM MOV 5,5 Mode 1 or 2? JNE >0478 MOVB @>83C6,@>83E7 Keyboard mode in R3 Lbyte BL @>04A2 Compare DATA >617A**~~Page 21: TI99/4A INTERN (Heiner Martin)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* JNE >0444 Small letter? CLR 12 MOV 3,3 Mode <4 JEQ >043E SBZ >0015 Activate ALPHA LOCK SRC 12,14 TB >0007 Scan ALPHA LOCK JEQ >0442 SB @>03B4,0 ->20 (Capital letter) SBO >0015 MOV 3,3 Mode 4 or 5 JNE >0456 BL @>04A2 Compare DATA >101F JEQ >0382 R0 between >10 and >1F CB 0,@>0587 5F? JH >0382 DEC 3 Mode 5 JNE >0478 CB 0,@>0025 0D (CR)? JEQ >0478 CB 0,@>02CA 0F? JH >046C SOCB @>0470,0 Set 1st bit JMP >0478 BL @>04A2 Compare DATA >809F JNE >0478 R0 smaller than >80 or bigger than >9F SZCB @>0470,0 Reset 1st bit MOVB 0,@>8375 ASCII value key on >8375 BL @POPGRA Restore GROM address MOVB 6,@>837C Set GPL status JEQ >0492 MOVB @>83D4,*15 Load VDP register 01 CLR @>83D6 Clear screen timeout counter MOVB @>0B61,*15 MOV @>83D8,11 Fetch return B *11** Time delay* LI 12,>04E2 Loop counter DEC 12 JNE >049C B *11** Compare RO with status EQU if R0 is in area of Hbyte and Lbyte* of the data value* MOV *11+,12 CB 0,12 JL >04B0**~~Page 22: TI99/4A INTERN (Heiner Martin)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* CB 0,@>83F9 JH >04B0 CB 0,0 B *11** CLEAR keyboard scanning(status EQU, if pressed):*CLRSCN LI 12,>0024 Load CRU keyboard select LDCR @>0012,3 >00 SRC 12,7 LI 12,>0006 STCR 12,8 Fetch CRU CZC @>0036,12 Right key? JNE >04DC LI 12,>0024 CRU 2nd key LDCR @>0074,3 >03 SRC 12,7 LI 12,>0006 STCR 12,8 Fetch CRU CZC @>0036,12 Right key B *11 BackI'm guessing the time delay segment will raise issues with at least one member of this group?

lava.zip <==== Early Beryl Magellan File Magellan Graphics Editor Tool for TI-99/4A (runs on Windows): http://atariage.com/forums/topic/267322-programming-resources-for-ti-xb-graphicssprites/?p=3798140 Some graphics inspiration: http://bifi.msxnet.org/msxnet/konami/ Useful links while looking at the Viewport code from 2 June 2010

It is now clear what is meant by "a placeholder," and the self-modifying code example is understood. The key for me understanding this example was realizing the placeholder is only there to satisfy the assembler. Coming from an interpreted BASIC paradigm, I was assuming the code "FUN1RT B @0" was always going to Branch to >0000. I forgot that this looks crash-worthy post-assembly, on a listing of the assembled code, yet it's modified at run-time to Branch to the intended return address. Clever!

GameLp4D.a99 <==== Corrected GameLoop for Dummies commented code Playing around with that viewport code of Owen's (and the Matthew Methodology version) has me really excited right now. At first I thought Owen's Viewport code represented some skipping ahead, or at very least some confusing thread creep. My expectations were for Matthew to transition towards the next logical conversation --KSCAN.. Loading and running the Viewport code has opened up some very interesting possibilities. It appears Owen is using the traditional KSCAN routine with his viewport code while Matthew is taking the "Roll Yer Own" approach. What better way to learn than to pour through both code segments and test the differences? InsaneMultitasker (Tim) correctly noted that there's nothing wrong with using the console routines. Here lies an opportunity to get familiar with the pre-written routines as well as some efficient custom routines. Win-Win!

Thanks Lee! Earlier posts here outline the problems with using BLWP: speed, scratchpad RAM overwriting, etc. Looks to me like TI's KSCAN requires this... along with the REF... thus limitations to be avoided. I'll investigate your link. Thanks!

After Matthew's GameLoop breakdown the thread seems to have moved along (page4), to Owen's viewport code (Beryl) with KSCAN used. I'm going to download that code and try to figure everything out next. Matthew mentioned his disappointment with TI's KSCAN code due to wasted speed via two delay loops. This is probably a good time to look into how KSCAN works. Hopefully Owen's code will be helpful in unravelling yet another TI coding mystery. Willsy posted (6 Jun 2010) KSCAN replacement code? Probably something I need to understand before moving on. I'll start with p.250 of the E/A manual, 16.2.1 KSCAN.

This sparked my interest! I'm guessing here: SUB1 MOV R11, @SUB1RT+2 * this stores the PC/return address of the calling code into a hard memory location immediately following this routine ??? <code> SUB1RT B @0 *I don't get what the '@0' does or how it somehow gets ignored and replaced with the stored return address at SUB1RT+2 ???

Looking forward to playing a new TI game! Sweet!

Thanks for the feedback guys! I just finished page three of this wonderfully informative 19 page thread. Again, I'm humbled by all the help I've received. Matt's approach to learning Assembly Language is something that has grabbed my attention but more importantly, it's really helping me learn while staying engaged. The Gameloop code from page three of this thread took me a while to wrap my mind around. In the process I read multiple user's comments and did some research into the TMS9900 Guide and TI's E/A manual. I've attached a version of Matthew's GameLoop code with "For Dummies" style comments and additional information in an attempt to encapsulate everything I have learned while pouring through the code. A beginner with some of the same questions as myself, and very few of the expert-like assumptions of a proficient Assembly programmer, may find the additional comments useful. Hopefully I'm not stepping on any toes doing so. This week I was able to demo the BASIC gameloop v Assembly Gameloop programs to Sparkdrummer at the July VAST meeting in PHX. We had a lot of fun looking at this code and comparing its performance to BASIC. Thanks again! - James GameLoop.a99

Recognize the controllers yet not the system? https://www.shopgoodwill.com/viewItem.asp?ItemID=41150926 This is a Sears rebranded Atari 2800 (not 2600) with the worst joysticks ever made for any system. http://www.jwnyc.com/games/videoarcade2.html May be a cool pickup for Atari fans though. Guessing the REAL 2800/Sears Video Arcade II joysticks are tough to find.

So far it appears Canada has the most TI people.

This is the best Arizona based TI newsletter out there. Thanks Ralph! Ps - When are the guys from VAST meeting again?

I always forget to count that damn zero.

Thanks For the rapid feedback Lee! I read that about the source operand having to be larger than the first word of the destination operand, for "normal division to occur." Otherwise the resulting quotient won't fit inside a 16-bit word. What I meant by "ignored" (R4) is this specific code does nothing with the number (integer quotient) in R4 after the DIV executes. It's only concerned with the remainder. Seem right you? Otherwise, I will move on with the assumption that it's all understood. The big takeaway here was learning the peculiarity of the DIV OpCode, which is only peculiar to me because there's nothing similar going on with BASIC regarding which end of the equation needs to be smaller.

Hey Matthew, I was able to easily understand most of this post up to the point where your code started plotting random characters on the screen. The DIV OpCode is where I started to stumble as I've never really used it before. I went to p.88 of the E/A manual as a reference. To help in my understanding of the logic I added comments as notes. A way to further clarify what exactly is going on between registers during the Divide, etc. Here's what I came up with in order for it all to be clear in my mind: *********************************************************************** Plot a random character*PLOT* Only draw on the VSYNC C @VSYNC,@NUM01 * If VSYNC is not active, return JEQ PLOT01 B *R11PLOT01 MOV R11,*R10+ * Push return address onto the stack* Get a random screen location BL @RANDNO * Get a random number (in R5)... between 0 and 65,535 (2^16 -1) LI R3,768 * by cleverly using 768 as a divisor we assure any DIV remainder is ALWAYS 0-767 CLR R4 * Dividend will be 32-bit R4&R5 (two words used by DIV) which is really just* a 16-bit dividend (R5) with leading zeros in R4 to satisfy the TI DIV OpCode DIV R3,R4 * divides destination operand (a consecutive 2-word workspace, R4&R5) by 768* Makes a number between 0 and 767 (see E/A manual p.88) in R5* - the resulting integer quotient (R4) is ignored here, does not matter* - the resulting integer remainder (R5) is ALWAYS between 0 and 767* MOV R5,R0 * Move to R0 for the VDP routine AI R0,NAMETB * Adjust to the name table base* Get a random character 40, 48, 56, 64 BL @RANDNO * Get a random number (in R5), again 0-65,535 SRL R5,14 * Make a number between 0 and 3 using Shift Right Logical* Shifts bits in R5 right 14 times and fills left with zeros, leaving 2 LS-bits SLA R5,3 * Multiply by 8 (number is now 0, 8, 16, 24) using Shift Left Arithmetic* Shifts bits 1&0 left to positions 4&3, and fills in the right bits (2,1,0) with zeros A @CHR040,R5 * Add to the base character MOV R5,R1 SWPB R1 * Remember, the MSB goes to the VDP! BL @VSBW DECT R10 * Pop return address off the stack MOV *R10,R11 B *R11*// PLOTDoes this all seem correct to you? I want to make sure my understanding of the situation is correct. I'm finding this thread incredibly helpful. Forgive my snails pace as I pick my way through the lessons. To me it seems to be moving along quite well yet based on the dates of your original posts I'm moving along a bit slower than Owen and the guys from 2010. Thanks again! -James

Where may one find Panzer Strike?

Have you tried Tidbit? Allows programming BASIC with labels in place of line numbers which really improves the BASIC experience. Editing on a modern PC + Tidbit = a delight!

Yes! I'd like to see some sort of TI version of this: http://64bites.com/ "If so please say so here and give an idea of the topics you'd like to see covered and I'll see what I can do." An introduction to include workflow and supporting software: editor, emulator, etc. it doesn't have to be ultra professional, just informative. The following example was made with an iPhone in just 30 minutes and one take: Example: https://youtu.be/YwQL1-CZGO8 ^^^Includes the all-important "how-to" on getting code written and imported into the emulator, and then exported to the TI itself. Ideal for beginners new to the TI Cult. "If anyone else wants to make some videos, of TurboForth, fbForth, or Camel 99 Forth please go right ahead. I'd love to get more TIers at least having a dabble with Forth!" It'd be nice to have a pinned thread to go to or an agreed upon YouTube central channel.

I wasn't aware of the video game console part of the story. Wondering if any details exist?

Yep! I must have had R<zero>LB in there. Good to know RoLB = ROLB so no case sensitivity. I was using the "END" as I had with BASIC I suppose. So it's an Assembler Directive, not an OpCode. Is it safe to assume I'll be writing strictly relocatable code vs absolute code? The way you phrased this makes it easy for me to understand. I didn't get that earlier in my reading. Same comment as above. I didn't realize this was happening with DEF making it external/global. This is quite powerful and a big potential time saver. Wondering if this how SPECTRA by Retroclouds works? A collection of arcade game enabling routines imported by REF's at the beginning of my code? My Assembler workflow includes using Classic99 with the E/A Cart, Option 3 Load and Run. With multiple source code files I'd have to load.... say... the VDP Routine file before the Main Program file. I'd need DEFs in the VDP Routine file and associated REFs in the Main Program file. I'd have to remember to load the VDP Routine file first. How do most people automate this? I anticipate issues with several or more support (DEF) packages. This really clears up a lot regarding REF v DEF. Also seems it'd become tedious if you had more than a few libraries to load. Always appreciate a little History with my daily computer lessons! THANK YOU! Great reply!