Airshack

Translation: get an adapter.

27" LCD TV/Monitor combo I picked up at Goodwill with VGD/HDMI/Composite/Cable inputs. Cost $19.

Sinphaltimus! Please write a For Dummies level guide to TI99/RetroPie once you've completed the process. I need it.

It's just a heavily commented version of Matthew's viewport code with changes to the map and Sprites to show a scrolling football field with one player moving about. I changed the theme to learn some more about Magellan exporting. If you load DSK9.F2O and run MAIN it should run.

XOP Question While reading the E/A Manual today unnoticed this curious entry: "The extended operation instruction (XOP) is available in some TI-99/4A computers. The only way to determine if your computer supports this instruction is to try it." E/A Manual, p 43 Have the 99er historians determined which units have XOP availability? Tell me TI didn't have some Lubbock Leprechaun randomly include this capability into units, in a Wonka-like golden ticket manner, just to mess with us. Also, is it safe to assume that context switching with XOP instructions will trash scratchpad RAM as seen with BLWP?

Robotron 2084 too!

This seems to be the currently accepted best practice. Thanks!

Berzerk comes to mind.

Tursi, Do you continue to hold this position? Apparently there's a situation where VPD status bit in question VSYNC is masked. Wondering if a few misses here and there of the status bit is a significant enough issue? Later in this thread Matthew has a change of heart regarding this VDP status bit methodology. -j

The RAM mode w/ FG99 seems worthy of its own topic thread. Has anyone utilized this capability?

Hey Matthew and AtariAger TI Gurus, I was wondering about how things may have changed over the past year with respect to programming in Assembly for Cartridge vs. EA. Specifically, how has the advent of the FlashROM/FlashGROM99/NanoPEB/SAMS impacted things, if at all, since this thread began back in 2010 - pre-Flash/Nano Anything? Why wouldn't one want to write for Cart v EA? I suspect the balance is tipped towards Cart development with all the new hardware, though modern disk replacements (GoTech, Lotharek, etc) tip the scale back towards disk use code. It's confusing at this point as I'm not fully appreciative of one route over the other. With the development of JediMatt's external 32k, NanoPEB w/32k expansion, and the proliferation of emulation, I can't really imagine wanting to write code without the 32k expansion in mind. Seems to me most current day TI users will most likely be using systems some form of the 32k expansion RAM. Any good arguments with this conclusion out there? Big Picture Question: How/why does EA3 code need to be modified to run from a Cart? Apparently EA3 cod tramples all over the lower 8K? What's the advantage to EA3 code over Cart based coding? -j

I've invested the time to understand matthew's viewport code from page-4 of this thread. Here's my twist on the whole thing along with comments clarifying what may seem obvious to experienced TI Assembly programmers. The attached Viewport code is over-commented to suit my needs and to encapsulate answers to questions, thread comments, etc: ViewportFD.zip This version of the viewport code is American Football themed. Added feature: I was able to allow for the addition of diagonal joystick moves by removing two JMP PLY10s and adding a JMP PLY03.. Whenever a Left or Right move is detected the code now ALSO checks for Up and DOWN which equals a diagonal move. * Test the joystick via the Communications Register Unit (CRU) * Com Register Unit on TI-99/4A reads: Keyboard keys, Joysticks, Cassette i/o * - Interfaces with TMS9900 via TMS9901 Programmable Systems Interface (PSI) * - uses 12 lines of the address bus (3-14), does not use the data bus * - addresses 4,096 Input lines and 4,096 output lines * - CRUIN line, CRUOUT line, CRUCLK line * Note: Joystick lines are tied high(1), and when a contact is made, they are pulled low. * - Making a contact with the joystick connects that contact to 0V & sets CRU bit. * LI R12,>0006 * Base CRU address for joystick 1 is placed into R12 for following Test Bit Operation * - 0000 0000 0000 0110 * - ^^^ ^^^^ ^^^^ ^ <== bits 3-14 yield >0000 ???? TB 1 * \\\\\\\\\\ LEFT MOVE CHECK \\\\\\\\\\ Jump if LEFT-Joy1 position not selected * TB 1 = Test Bit 1; Reads CRU bit/line 1 relative to the CRU base address in R12 * The Equal Status Bit is set to the value of CRU line level, which gets * set '1' when the joystick line goes to 0V. * E/A Manual, 9.5, p.156 * Reads the digital input bit on the CRU at the address specified * by the sum of the signed displacement (1) + contents of R12, bits 3-14, * and set the equal status bit (third MSbit) of Status Reg to the value read JEQ PLY02 * Jump when Left not selected, test Right next MOVB @SLTNAM,R4 * R4 loaded with the Sprite address for the Left moving player Sprite's Top/Left Tile * - Player Sprites are four tiles in size DEC R3 * R3 contains P1LOC (top/left)value; updates R3 held tile counter one position less/left DEC R5 * R5 contains P1LOC+88(bottom/left); DEC R5 to update player1 Sprite's bottom-LEFT tile MOV R3,R6 * R6 updates to hold a copy of P1LOC tile counter for the top/LEFT tile * - Since this is a LEFT move it's important to use LEFT side Sprite tiles * for when we later check move legality. DEC R1 * R1 contains @P1MX value; this updates R1 held P1MX value JLT PLY99 * Left side horizonal bound check; IF P1MX < 0 THEN No_Updating RETURN * - Player1 cannot move left beyond column 0 * - Nothing has been updated above except temp. values held in registers * JMP PLY10 * PLY10 is where we test the moves before making them permanent/executing them in memory * - R1= top/LefT P1MX; R3= P1LOC offset; R4 = char; R5 = bottom/LEFT; R6= P1LOC top/LT JMP PLY03 PLY02 TB 2 * ////////// RIGHT MOVE CHECK CRU Bit 2 ////////// JEQ PLY03 MOVB @SRTNAM,R4 * Sprite name INC R3 * R3 contains P1LOC value; updates R3 held tile counter to one position right INCT R5 * R5 contains P1LOC+88; adds TWO so R5 now holds counter for Player1 Sprite bottow/RIGHT * - had to add TWO here since R5 = Sprite bottom/RIGHT for validity checking INC R6 * R6 contains Sprite top/right tile offset; this updates it one tile to the right INCT R1 * R1 contains P1MX value; adds TWO so R1 now holds counter for Player1 Sprite top/RIGHT * - right moves dictate right side Sprite tile values here for move validity checks C R1,@MAPW * Upper horizontal bound check; see if right side of sprite exceeds right edge of map JGT PLY99 * There is no arithmetic >= so make two checks JEQ PLY99 * PLY99 RETURNs without moving DEC R1 * R1 Readjusted to real (left/top) tile counter location, X + 1 * JMP PLY10 * R1= P1MX; R3= P1LOC offset; R4= char; R5= bottom/RIGHT; R6= top/RIGHT * edited to go to PLY03 PLY03 TB 3 * DOWN MOVE CHECK --- moving down DECREASES P1MY --- Row 0 of the Map is at the bottom JEQ PLY04 MOVB @SDNNAM,R4 * Sprite name for down A @MAPW,R3 * Adjust the location of P1LOC counter to a row lower A @MAPW,R5 * R5 holds bottom/left tile offset; update to a row lower MOV R5,R6 INC R6 * R6 now holds bottom/right sprite tile offset INCT R2 * Move down, Y + 2 for bound check C R2,@MAPH * Upper vertical bound check; compare P1MY to Map Height JGT PLY99 * There is no arithmetic >= so make two checks JEQ PLY99 * RETURN w/o moving DEC R2 * Re-adjust to real location, Y + 1 JMP PLY10 * R2= P1MY updated; R3= P1LOC offset; R4 = char; R5 = BOTTOM/Left; R6= BOTTOM/right PLY04 TB 4 * UP MOVE CHECK --- moving up INCREASES P1MY --- Row 39 of the Map is on top JEQ PLY10 MOVB @SUPNAM,R4 * Sprite name for up S @MAPW,R3 * Adjust the location MOV R3,R5 S @MAPW,R6 * R6 was top/right tile which has been update to a row above DEC R2 * Move up, Y - 1 JLT PLY99 * Lower vertical bound check 0, If fails RETURN w/o moving * * R2= P1MY updated; R3 = P1LOC offset; R4 = char; R5 = TOP/left; R6 = TOP/right PLY10 * * PLY10 Checks to make sure the requested Player1 move is to a 'Legal' tile such as a path or bridge * DSK9.zip <===== File "F2O" runs w/ E/A - J

I was just looking for a Map data arrangement similar to the ViewPort code. Turns out that's Magellan's default IF No Compression is selected in the Export Settings menu.

Well... I believe I can work with what Magellan produces after all. It does seem strange how Export menu items work though. Ex. The BASIC and XB Export functions don't seem to export anything? I remember Sinphaltimus finding a resolution for this issue last year? I forgot the fix. Probably needing to check a Magellan thread.

I'm trying to get Magellan to export data to the same format as Matthew's Viewport example: * -- Map Row 0 (of 40) -- [ 'MAP6' is 88 * 40 ] MAP6 DATA >696E,>6E69,>6960,>6060 ; * Each table row = 8 tile identifiers: >69, >6E, >6E, >69, >69, etc... DATA >6060,>6060,>6060,>6060 ; * - each tile in the table is described by one 16-bit word DATA >6060,>6068,>6868,>6868 ; * - the table has 11 DATA rows per Map Row DATA >6868,>6860,>6060,>6060 ; * - therefor each Map Row has 8 * 11 = 88 Tiles (per MAP row) DATA >6060,>6060,>6868,>6868 ; * DATA >686F,>6F6F,>6F68,>6868 ; * In this example code the MAP is 88 Tiles wide * 40 Map rows DATA >6868,>6868,>6860,>6060 ; DATA >6868,>6868,>6868,>6060 ; * The Origin (0,0) of the Map is top-left corner of the MAP DATA >6060,>6060,>6060,>6060 ; DATA >6060,>6060,>6060,>6060 ; DATA >6060,>6060,>6060,>6060 ; * -- Map Row 1 (of 40)-- DATA >6B69,>6B70,>7060,>6060 ; * <==== 8 tiles for row 1/40 DATA >6060,>6068,>6868,>6868 ; DATA >6868,>6868,>6868,>6868 ; DATA >6868,>6860,>6060,>6060 ; DATA >6060,>6060,>6868,>6868 ; DATA >686A,>6A6A,>6A68,>6868 ; DATA >6868,>6868,>6860,>6060 ; DATA >6868,>6868,>6868,>6868 ; DATA >6868,>6868,>6868,>6868 ; DATA >6860,>6060,>6068,>6868 ; DATA >6868,>6860,>6060,>6060 ; * 88 tiles TOTAL for row 1/40 etc.... I'm having difficulty using the Export feature of Magellan. Any good documentation out there?

I'm familiar with using zeros when counting, just wondered if you had a unique scheme for the viewport origin being bottom/left vs top/left. Give me another look before you look back at your code. I'll figure it out. Wanting to get through it all before asking further questions.

Question about matthew's ViewPort code: To me the map looks to be 88 columns wide by 40 rows high; with columns numbered 0-87 (left to right), and rows numbered 0-39 (bottom to top.) Is this correct? With the origin 0/0 being the bottom left corner, not top/left? The PLY40 code segment has me needing to take a break. Don't understand why you set the origin to the bottom-left corner when it's top-left in memory? Off to run and think... - james

Great TI coverage in a recent episode of FloppyDays. Interview with Jon Guidry from VCFSE 5. This guy Randy Kindig does a really great job with the FloppyDays program. http://floppydays.libsyn.com/

That video starts out slowly but the reviewer/player gets better. Give him a little time. This game looks quite fun yet what I like best is it's something completely new. Old style graphics with simple controls yet kickass gameplay! Really creative and clever! Haven't seen anything like but I really want to play it. Looks like a winner and quite do-able on the TI. Betting MadMarvin could be tweaked to play in a similar manner.

Just what I needed!

I'm using TapATalk a lot so maybe that's it? I know what you mean, it's ugly. Noted. Never more on the single line look.

Where does one look for more technical data on manually polling joysticks and the keyboard? E/A manual is all about KSTAT which seems cumbersome compared to Matt's viewport example.

Interesting. There seems to be an endless amount of learning available via this ancient little system. I get caught up with it all until something mysterious pops-up in my way, a barrier I cannot see beyond. You all have been very helpful in circumventing these barricades to progress. Matthew, I've almost completed dissecting your viewport code. This time I noted minimal comments and less discussion as to how it all works. This has lead to a better opportunity for me to learn. Along with Assembly coding, I'm learning some very valuable graphics presentation techniques, discovering many clever details... I may have even discovered a small unnecessary code segment?! Probably, I'm wrong...but maybe not. More on that in the debrief/lessons learned post to follow. This challenge is more enjoyable than I ever anticipated. -james

I clearly didn't consider this arrangement! Well hell! That's just what I needed with my morning coffee. Thanks guys!

As I go through Matthew's viewport code example I'm having a problem understanding his polling of joystick-1 technique: * Test the Joystick** First Test if moved Left LI R12,>0006 * base CRU address for joystick 1 TB 1 * Left JEQ PLY02 * Jump to test for Joystick 1 moved right < process a move left then return>PLY02 * Test if Moved rightFrom what I see in the E/A manual that 'JEQ PLY02' line should read 'JNE PLY02' since moving Joystick1 to the left would set the CRU line, and the following 'TB 1' should set the Statue Register EQ bit. So, the status (EQ) bit should be set after moving the joystick left. Then the following 'JEQ PLY02' should jump past the code where you process moving left ??? I've run and played with the viewport code which works flawlessly. I guess I'm missing something obvious here?