+mizapf Posted March 8, 2019 Share Posted March 8, 2019 I added a CRU bit test and a message saying "RELEASE ALPHA LOCK TO BEGIN PLAY". Argh ... I always hated direct CRU queries, because this meant the program would not run on my Geneve. (Things got certainly better since I have emulation.) 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted March 8, 2019 Share Posted March 8, 2019 Argh ... I always hated direct CRU queries, because this meant the program would not run on my Geneve. (Things got certainly better since I have emulation.) I thought of that, too.. I took that feature out of the Geneve GPL version (unpublished, whereabouts of floppy disk unknown) 1 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 8, 2019 Author Share Posted March 8, 2019 I understand you're talking about the menus, not gameplay. But for gameplay, I don't like joysticks. I have more dexterity in my fingertips on the keyboard. I resent that the Atarisoft games generally don't have keyboard controls. Late games like Barrage and SpotShot let you push Fire instead of Redo. You only needed the keyboard for Back. Please use WASD instead of the "arrow keys" (which require two hands in a very uncomfortable configuration). And REDO / BACK are awful IMO, avoid them whenever possible. TI created a model for software on the 99/4A based on bad design (or a lack of any design) that perpetuated the use of things like single-color sprites, multi-key inputs (REDO, BACK, etc.), explicit instructions for single key inputs "Press 'P' to play", bad fonts, and on and on. When you compare 99/4A software with titles with systems like the ColecoVision, MSX1, and what people are producing today on the stock hardware, it is plainly obvious most developers did not even try very hard on the 99/4A. Yes, please do follow the examples of systems like the MSX1 and NES for how to navigate and control games. I guarantee you that none of the kids back then went running to the manual to figure out how to navigate the game menus and options, all without any keyboard at all. 4 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted March 8, 2019 Share Posted March 8, 2019 (edited) Please use WASD instead of the "arrow keys" (which require two hands in a very uncomfortable configuration). And REDO / BACK are awful IMO, avoid them whenever possible. TI created a model for software on the 99/4A based on bad design (or a lack of any design) that perpetuated the use of things like single-color sprites, multi-key inputs (REDO, BACK, etc.), explicit instructions for single key inputs "Press 'P' to play", bad fonts, and on and on. When you compare 99/4A software with titles with systems like the ColecoVision, MSX1, and what people are producing today on the stock hardware, it is plainly obvious most developers did not even try very hard on the 99/4A. Yes, please do follow the examples of systems like the MSX1 and NES for how to navigate and control games. I guarantee you that none of the kids back then went running to the manual to figure out how to navigate the game menus and options, all without any keyboard at all. Please allow the user to choose a keyboard layout? I suppose by two hands you mean left hand on E+S, right hand on X+D. I have seen people adopt this. It strikes me as odd when three fingertips is enough for me. I have always used my right hand thumb on X, middle finger on E, index finger on S+D. My index finger can move most quickly of all to switch between S and D. I am not a big fan of WASD. If I use the middle finger for both W and S, that muscle is slower to finish the movement (tendon causes three joints to contract) than the other movement in ESDX .WASD feels uncomfortable because my middle finger is above average length. That said, we all have idiosyncratic wiring between brains and fingertips. Also, hjkl. Edited March 8, 2019 by FarmerPotato 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted March 9, 2019 Share Posted March 9, 2019 I resent that the Atarisoft games generally don't have keyboard controls. This subject probably deserves its own thread. Sent from my iPhone using Tapatalk Pro 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 9, 2019 Share Posted March 9, 2019 Please use WASD instead of the "arrow keys" (which require two hands in a very uncomfortable configuration). And REDO / BACK are awful IMO, avoid them whenever possible. TI created a model for software on the 99/4A based on bad design (or a lack of any design) that perpetuated the use of things like single-color sprites, multi-key inputs (REDO, BACK, etc.), explicit instructions for single key inputs "Press 'P' to play", bad fonts, and on and on. When you compare 99/4A software with titles with systems like the ColecoVision, MSX1, and what people are producing today on the stock hardware, it is plainly obvious most developers did not even try very hard on the 99/4A. Yes, please do follow the examples of systems like the MSX1 and NES for how to navigate and control games. I guarantee you that none of the kids back then went running to the manual to figure out how to navigate the game menus and options, all without any keyboard at all. I absolutely hate WASD instead of arrows. They are never lined up evenly on almost any keyboard. The E is always off center to right of S & D keys, the X is directly below like it should be, I like the ARROWS as they are exactly lined up like you would expect. Also I hate the Number Keys and instead use Number Pad keys for numbers as you do not have to look to hit the right key. Additionally you can hit Num Lock and get another set of keys. I have small hands with short fingers so most keyboards is hard for me to type on. Quote Link to comment Share on other sites More sharing options...
whicker Posted March 9, 2019 Share Posted March 9, 2019 I absolutely hate WASD instead of arrows. They are never lined up evenly on almost any keyboard. The E is always off center to right of S & D keys, the X is directly below like it should be, Put your pinky of your left hand on the "A" key and place each of your following fingers to the right on the home row keys with your pointer finger ending up on the "F" key. The side of your thumb rests on the spacebar. To hit the "W" key (up), extend your ring finger naturally up from the "S" key, and your joints will naturally guide it to the upper-left direction there. Other natural movements are moving your pointer finger from the "F" key up to the "R" key or down to the "V" key. Using the spacebar for something precise like jumping feels really natural with this hand positioning. Part of the comfort of using WASD has to come from instant onscreen feedback (high framerate). Otherwise I agree it is more confusing than a cardinal direction layout. Quote Link to comment Share on other sites More sharing options...
Airshack Posted March 9, 2019 Share Posted March 9, 2019 (edited) “Put your pinky of your left hand on the "A" key and place each of your following fingers to the right on the home row keys with your pointer finger ending up on the "F" key. The side of your thumb rests on the spacebar. To hit the "W" key (up), extend your ring finger naturally up from the "S" key, and your joints will naturally guide it to the upper-left direction there. Other natural movements are moving your pointer finger from the "F" key up to the "R" key or down to the "V" key. Using the spacebar for something precise like jumping feels really natural with this hand positioning.” ^^^^ I can think of no better illustration as to why Atarisoft games generally do not have keyboard controls. Sent from my iPhone using Tapatalk Pro Edited March 9, 2019 by Airshack Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted March 9, 2019 Share Posted March 9, 2019 Hi all, Please take general discussion of using keys to TI-99/4A Computers : Game controls: keyboard ESDX, WASD, joysticks Talk about assembly programming and KSCAN here. 3 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 10, 2019 Share Posted March 10, 2019 (edited) Put your pinky of your left hand on the "A" key and place each of your following fingers to the right on the home row keys with your pointer finger ending up on the "F" key. The side of your thumb rests on the spacebar. To hit the "W" key (up), extend your ring finger naturally up from the "S" key, and your joints will naturally guide it to the upper-left direction there. Other natural movements are moving your pointer finger from the "F" key up to the "R" key or down to the "V" key. Using the spacebar for something precise like jumping feels really natural with this hand positioning. Part of the comfort of using WASD has to come from instant onscreen feedback (high framerate). Otherwise I agree it is more confusing than a cardinal direction layout. Again my PINKY will not reach the A key at same time as other fingers are on S & D keys. And there is a half inch gap between my index finger and F key, In order to type I have to constantly crank my hand left and right. I can type 60 words a minute, but it looks odd for a reason. The lay out of keys was not for typing it was for using a MANUAL TYPE WRITER as it took infinite more power back then, but that pattern stuck. Because the TI99/4A keyboard is shrunk I can type faster on it then normal computer keyboards. Edited March 10, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted March 12, 2019 Share Posted March 12, 2019 (edited) Back on topic: This code works on my 4A, but it assumes a GROM address for the char defs. Is there a better way to look up the char defs? Are there different GROMs out there? * copy 7 byte grom char defs to vdp. * assume 06b4 is the char table (seen in classic99 4A grom) * they are 7 bytes per char so add a 0 after each 7 bytes * R0 VDP address * ---- * R1 scratch * R2 scratch chara: ori r0,>4000 swpb r0 movb r0,@VDPWA swpb r0 movb r0,@VDPWA li r1,>06b4 movb r1,@GRMWA swpb r1 movb r1,@GRMWA li r1,>5f ; number of char defs chara1: movb r1,@VDPWD ; insert a zero byte li r2,7 ; bytes per char def chara2: movb @GRMRD,@VDPWD dec r2 jne chara2 dec r1 jne chara1 rt Edited March 12, 2019 by FarmerPotato Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted March 12, 2019 Share Posted March 12, 2019 Back on topic: This code works on my 4A, but it assumes a GROM address for the char defs. Is there a better way to look up the char defs? Are there different GROMs out there? * copy 7 byte grom char defs to vdp. * assume 06b4 is the char table (seen in classic99 4A grom) * they are 7 bytes per char so add a 0 after each 7 bytes * R0 VDP address * ---- * R1 scratch * R2 scratch chara: ori r0,>4000 swpb r0 movb r0,@VDPWA swpb r0 movb r0,@VDPWA li r1,>06b4 movb r1,@GRMWA swpb r1 movb r1,@GRMWA li r1,>5f ; number of char defs chara1: movb r1,@VDPWD ; insert a zero byte li r2,7 ; bytes per char def chara2: movb @GRMRD,@VDPWD dec r2 jne chara2 dec r1 jne chara1 rt http://atariage.com/forums/topic/267879-large-capital-letters-in-basic/page-2?do=findComment&comment=3825145 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted April 6, 2019 Share Posted April 6, 2019 Im working on blasting bitmap mode again. I decided on a 16x16 area with two frames. So that chars 0-127 are for one frame in each bank. One char has to double as the blank char. I found that I can push the whole color table portion in under 2 ticks, thats 2k of sequential writes, operating completely out of PAD. doing something more interesting than a scrolling checkerboard will be slower. Id post code but we just got hit with a lightning strike. Im typing on my phone plugged into a car jumper battery. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted April 6, 2019 Share Posted April 6, 2019 I measure how fast I can blast 4k of bitmap data, for 1 frame of a 16x16 tile area of the screen. I store the pattern and color in chars 00-7F (each bank) for one frame. checkr is a routine that blasts a 4x4 checkerboard pattern into the color table with a scrolled offset of 0-7. Registers are in PAD. * Timing Full blast 4k. Pat tbl all >F0 with vmsw 2k, color table with checkr 2k. All in CPU RAM. Music playing. ; 512 frames in 51 seconds with 2 vsync waits in a row. 10 fps or 6 ticks/frame ; 512 frames in 40 seconds with 1 vsync wait. 12 fps or 5 ticks/frame. ; 512 frames in 38 seconds with 0 vsync wait. Still around 5 ticks. half blast 2k. color table only with checkr. ; 512 frames in 24 seconds. 21 fps or 3 ticks/frame. half blast 2k. Inner loop of checkr in PAD. ; 512 frames in 21 seconds. 25 fps or 2-3 ticks/frame. no music ; 512 frames in 17 seconds. 30 fps. 2 ticks/frame. Cycle Analysis of checkr: T(a73e-a794) N Cy N*Cy 1024 26 26624 movb r4,*r15 (8 movb per unrolled loop) 128 10 1280 dec r2 128 10 1280 jne Total 29184 cycles average cycles measured in checkr: 30352 Times two, or 60700 cycles. Trying movb r4,@VDPWD takes 30 cycles. Slower than movb r4,*r15. Adds 4096 cycles. Time to move code into pad: 60 + 20*(38+14+14) = 1380 So do this once. ; full bandwidth, supposedly optimized vdp blitter. ; fill all the bytes that would be written if the whole field had been calculated. ; move this routine to >8380 padck1 equ >8380 ck1 movb r3,*vd movb r3,*vd movb r3,*vd movb r3,*vd movb r4,*vd movb r4,*vd movb r4,*vd movb r4,*vd dec r2 jne ck1 b @ck2 ck1$ ckinit ; move code into pad. call this once. li r0,padck1 li r1,ck1 li r2,(ck1$-ck1) ck0 mov *r1+,*r0+ dec r2 jne ck0 checkr li r2,>80 ; loops mov r9,r0 neg r0 andi r0,7 sla r0,1 ai r0,padck1 b *r0 ; jump into partial move ck2 mov r9,r0 neg r0 andi r0,7 jeq ck3 ; partial last char causes all the trouble. we could wrap but clobbering 0 would look awful. movb r3,*vd dec r0 jeq ck3 movb r3,*vd dec r0 jeq ck3 movb r3,*vd dec r0 jeq ck3 movb r3,*vd dec r0 jeq ck3 movb r4,*vd dec r0 jeq ck3 movb r4,*vd dec r0 jeq ck3 movb r4,*vd ck3 rt Next steps: Moving data from a buffer in CPU RAM will be a large hit. Since at best 2k takes 2 ticks, even 6 ticks for 4k, page flipping will be essential. I will have to break up the blitting into sections, as Rasmus suggested. Perhaps doing other processing in between (though there is only a finite amount of processing to do per frame. sprites move at most 1 pixel per frame.) While I would like to have full bitmap scrolling, other ideas are: 1. My current scheme is 2 tiles, with 2*2 permutations (space above space, space above block, block above space, block above block). There are two frames. On each tick, I update 4 patterns in the next frame, then update the SIT. Total 32+256 bytes. 2. Idea. Making the background out of only 5 tiles, with all permutations of 5*5*8 stored in the pattern/color table. Then to update the frame, write 256 bytes of SIT (in 16 rows of 16.) This is still awfully limiting. Total 256 bytes. 3. Idea. Have 11 tiles, and update all 11*11 permutations for a frame. Write SIT. Total 2.5k. 4. Reduce the scrolling area width or height. Links Source repo https://github.com/olsone/games/tree/master/9d9damashi Blog https://github.com/olsone/games/wiki/9d9damashi-RetroChallenge-2019-Blog Video https://www.youtube.com/watch?v=writJ0I5fHg Thread http://atariage.com/forums/topic/289763-namcos-unpublished-sequel-to-munchman 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 7, 2019 Share Posted April 7, 2019 Are you going to generate the scrolling background map on the fly or will it be pre-defined/edited by hand? In case of the latter you can use Magellan to only generate the permutations you actually need. There is also some sample code included. If you go for the idea of updating both patterns/colors and SIT, I think you can update something like 64 patterns + 1/8 SIT in a single tick. This is assuming the use of SIT double buffers. I posted some notes here: http://atariage.com/forums/topic/210888-smooth-scrolling/page-1?do=findComment&comment=2754421 3 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted May 26, 2019 Share Posted May 26, 2019 (edited) This is not a video I made. Just sharing. Edited May 27, 2019 by sometimes99er 8 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 26, 2019 Share Posted May 26, 2019 You going to do GPL as it is 1/3rd as complicated as the program shown and TI Basic is the worst. I know the majority on site do Assembly, but it is way more complicated then TI Basic or XB and GPL is a happy middle with much in common with Assembly and TI Basic. Many commands on GPL look like XB and some like Assembly. Quote Link to comment Share on other sites More sharing options...
hhos Posted May 26, 2019 Share Posted May 26, 2019 You going to do GPL as it is 1/3rd as complicated as the program shown and TI Basic is the worst. Maybe you could write the program and send it to him? Then he could make another video with that in it. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted May 26, 2019 Share Posted May 26, 2019 <video link snipped> Nicely done video. It probably needs a series of introduction videos that work up to this kind of final program to truly move a person from BASIC to Assembly Language. There is so much detail once you look "behind the curtain" as they Wizard of Oz said. But just creating this video is a lot of work. You have maintained very high production values here. So catch your breath before starting the Introduction series. :-) 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 26, 2019 Share Posted May 26, 2019 Maybe you could write the program and send it to him? Then he could make another video with that in it. Yea would not be hard with the TI Basic listing he never let it finish listing. Quote Link to comment Share on other sites More sharing options...
hhos Posted May 27, 2019 Share Posted May 27, 2019 Yea would not be hard with the TI Basic listing he never let it finish listing. The data that he uses for the displayed characters is complete. It is at time index 7:19. Once you have that you would just have to choose positions to put them onto the screen, poll the joysticks and display characters as desired, according to which bits are set. Quote Link to comment Share on other sites More sharing options...
RXB Posted May 28, 2019 Share Posted May 28, 2019 RXB 2020 has a new Joystick & Motion command that also polls the fire keys. Added a Joystick & Locate version too. https://www.youtube.com/watch?v=2kwEBr1nwOI&list=PL6258E1BCE0466CC4&index=68 https://www.youtube.com/watch?v=1xUnqgYLckM&list=PL6258E1BCE0466CC4&index=64 Response is crazy fast compared to normal XB. 3 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted May 28, 2019 Author Share Posted May 28, 2019 Nice video! Is the author an A.A. user I wonder? Nicely done video. It probably needs a series of introduction videos that work up to this kind of final program to truly move a person from BASIC to Assembly Language. There is so much detail once you look "behind the curtain" as they Wizard of Oz said. Agreed, the amount of background details can be staggering, which makes it very hard to do and introduction that actually leaves you with a sense that you can accomplish anything. There is no easy way to get into assembly, so sometimes you need to give a working program and explain the nuances later. I think the video does a nice job or introducing a few simple programs in BASIC, then demonstrates the advantage of all the effort needed to make the same program in assembly; primarily the speed advantage (which on a retro-computer is night and day when comparing to BASIC). Also, IMO a person learning assembly needs to do a lot of reading and finding details on their own, so anything they don't understand becomes a good catalyst for some research. I think the video gives a lot of points where a person really into learning assembly could discover quite a bit, and use a resource like this forum to get help and clarification when needed. I hope there are more videos to come! 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted July 10, 2019 Share Posted July 10, 2019 Ive got several pieces of data in addresses >6000 thru >6009. I know how to read the first batch, >6000 and swpb and grab the next. But how do I move my read address to the >6002 address? And so on... I'm using Gadr equ >6000 I've tried A 1,>6000 But RT now I'm guessing Quote Link to comment Share on other sites More sharing options...
intvnut Posted July 10, 2019 Share Posted July 10, 2019 6 minutes ago, GDMike said: Ive got several pieces of data in addresses >6000 thru >6009. I know how to read the first batch, >6000 and swpb and grab the next. But how do I move my read address to the >6002 address? And so on... I'm using Gadr equ >6000 I've tried A 1,>6000 But RT now I'm guessing You should use indirect addressing with auto increment, as in this example: GADR EQU >6000 ; Address of data to read ;... LI R1, GADR ; put the address into a register MOV *R1+, R2 ; reads >6000 into R2, updates R1 to the value >6002 MOV *R1+, R3 ; reads >6002 into R3, updates R1 to the value >6004 MOV *R1+, R4 ; reads >6004 into R4, updates R1 to the value >6006 1 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.