Jump to content

FarmerPotato

+AtariAge Subscriber
  • Content Count

    1,465
  • Joined

  • Last visited

Posts posted by FarmerPotato


  1. Trying to get the lay of the user community, so this concerns physical modifications and or alterations to the TI console itself, not plug in or add devices like cartridges, P-Boxes, TIPI's etc.

     

    Like F18 with a hole melted for the VGA port?

     

    Also the alpha-lock joystick mod.

    • Like 1

  2.  

    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.

     

     

    This subject probably deserves its own thread.

     

     

    Sent from my iPhone using Tapatalk Pro

     

     

    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.

     

     

     

    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.


  3. On a related yet much less technical note...

     

    I’ve always felt the early computer games overused the keyboard. Lots of really poor UI out there...

     

    Examples:

     

    “Press J for joystick or K for keyboard”

    or

    “Press Enter/Return to start game.”

    or

    “Press 1 to play, 2 to exit.”

    or

    “Press Spacebar to begin”

    or

    “Make sure alpha-lock is....”

    or

     

    As a gamer I much prefer joystick based menus with button presses or Joystick movement to select options.

     

    Ex: Building in a joystick-up menu movement requirement prior to starting your game assures Alpha-Lock is released on the TI console, well before gameplay begins, every time.

     

    It’s understood the TI console did not come with a joystick. Is it not safe to assume each potential player has one by now? Why punish all players with zero value added keyboard driven UIs?

     

    Text adventures may be the exception here. They may also be the reason bad UIs became the standard prior to action games: sports, shooters, etc.

     

    Nothing worse than having to get up off the couch to restart a game. Seriously, I didn’t buy a joystick cable extender so I can now get up and press the 1 key to restart each and every game.

     

    Friends don’t let friends KSCAN.

     

     

    Sent from my iPhone using Tapatalk Pro

     

     

     

    But you have to consider the times the 99/4A was released in. Most people didn't have computer exposure prior to getting one, and if you just said "Use Joystick to make selection" and you couldn't move up because the Alpha Lock key was engaged, and didn't provide a reminder message, the novice user would likely be pretty frustrated with your program very quickly. I know there was an addendum thing in the pile of docs that came with the 99/4A that mentioned the joystick/alpha lock issue, but the average person probably didn't read all that real thoroughly.

     

     

    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.

     

     

    I’ve always felt the early computer games overused the keyboard. Lots of really poor UI out there...

     

    Examples:

     

    “Press J for joystick or K for keyboard”

    or

    “Press Enter/Return to start game.”

    or

    “Press 1 to play, 2 to exit.”

    or

    “Press Spacebar to begin”

    or

    “Make sure alpha-lock is....”

    or

     

    As a gamer I much prefer joystick based menus with button presses or Joystick movement to select options.

     

    Ex: Building in a joystick-up menu movement requirement prior to starting your game assures Alpha-Lock is released on the TI console, well before gameplay begins, every time.

     

    It’s understood the TI console did not come with a joystick. Is it not safe to assume each potential player has one by now? Why punish all players with zero value added keyboard driven UIs?

     

    Text adventures may be the exception here. They may also be the reason bad UIs became the standard prior to action games: sports, shooters, etc.

     

    Nothing worse than having to get up off the couch to restart a game. Seriously, I didn’t buy a joystick cable extender so I can now get up and press the 1 key to restart each and every game.

     

    Friends don’t let friends KSCAN.

     

     

    Sent from my iPhone using Tapatalk Pro

     

     

    But you have to consider the times the 99/4A was released in. Most people didn't have computer exposure prior to getting one, and if you just said "Use Joystick to make selection" and you couldn't move up because the Alpha Lock key was engaged, and didn't provide a reminder message, the novice user would likely be pretty frustrated with your program very quickly. I know there was an addendum thing in the pile of docs that came with the 99/4A that mentioned the joystick/alpha lock issue, but the average person probably didn't read all that real thoroughly.

     

     

    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.

     

     

     

    In Bubble Plane (1988) I added a CRU bit test and a message saying "RELEASE ALPHA LOCK TO BEGIN PLAY". Despite what I just said, keyboard and joystick gameplay and menus (including joystick high score initials entry) were both supported.


  4.  

    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.

    • Like 1

  5.  

    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)

    • Like 1

  6. But you have to consider the times the 99/4A was released in. Most people didn't have computer exposure prior to getting one, and if you just said "Use Joystick to make selection" and you couldn't move up because the Alpha Lock key was engaged, and didn't provide a reminder message, the novice user would likely be pretty frustrated with your program very quickly. I know there was an addendum thing in the pile of docs that came with the 99/4A that mentioned the joystick/alpha lock issue, but the average person probably didn't read all that real thoroughly.

     

    In Bubble Plane (1988) I added a CRU bit test and a message saying "RELEASE ALPHA LOCK TO BEGIN PLAY". Despite what I just said, keyboard and joystick gameplay and menus (including joystick high score initials entry) were both supported.

    • Like 1

  7. 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.

    • Like 2

  8. Like pausing for 8mS, twice, to debounce in code.

     

    @FarmerPotato, there has been a lot of keyboard and KSCAN discussion around pg. 10 in this thread. My post that dissects the delay in KSCAN is here:

     

    http://atariage.com/forums/topic/162941-assembly-on-the-994a/page-10?do=findComment&comment=2840302

     

    OK, KSCAN will be toast. I will check for movement keys/fire, maybe Redo/Back. The column setup can be combined.

    Thanks Rasmus!
    KEY_FN EQU  >000E
    
    KEY_FS EQU  >0106
    KEY_9  EQU  >010C
    KEY_S  EQU  >0110
    KEY_X  EQU  >0114
    
    KEY_D  EQU  >0210
    KEY_8  EQU  >020C
    KEY_E  EQU  >0212
    
    KEY_Q  EQU  >0512
    
    JOY_FI EQU  >0606
    JOY_LT EQU  >0608
    JOY_RT EQU  >060A
    JOY_DN EQU  >060C
    JOY_UP EQU  >060E
    
    • Like 1

  9. A. I’d like to see how your music player(s) work.

     

    B. KSCAN? Won’t that mess with the Scratchpad too?

     

     

     

    Right.. KSCAN. I'm not using PAD aggressively, just my WS in >8300. I must re-read this discussion if I want to take over more of PAD (like, storing my VDP write loop code).

     

    The music player is based on FORTI in pure assembly (not FORTH this time). I'll be posting all the source here shortly.


  10. A game like TI Scramble runs the entire main loop between two vsyncs, so you have more time than you may think.

     

    You have 50000 clock cycles in NTSC between two vsyncs, and you can use Classic99 to measure how much time you have used: Add a breakpoint with the start and end addresses of you main loop, e.g. T(A024-A038).

     

    Updates to the display you should try to finish as soon as possible after vsync. If you use two name tables as a double buffer you can update alternating tables each frame and just do a page flip right after vsync. I have even double buffered the sprite attribute table this way.

     

    Timing of sound playing is less important, I often do it after all the other work has been done.

     

    If you run over the frame, perhaps deliberately, remember to read the VDP status register once to clear the interrupt before you wait for the next one. Otherwise your polling loop will terminate immediately in the middle of a frame. You must also read the VDP status after detecting the interrupt, like this:

    vsync:
           movb @vdpsta,r12
           clr  r12
    vsync_1:
           tb   2                          ; Test CRU bit for VDP interrupt
           jeq  vsync_1
           movb @vdpsta,r12
           rt
    

    In Flying Shark the main loop takes up to 4 frames depending of the complexity of the graphics. In that game I had to count the frames and add delays in order to obtain an even pace, which was a real pain. If possible try to do approximately the same amount of work each frame. That doesn't mean you have to do the same things each frame. One frame can move the sprites while another scrolls the screen, for instance.

     

    I am using your vsync loop with success. My game loop is:

     

    LOOP

    LIMI 0

    wait for vsync

    draw 500 bytes to VDP for scrolling bitmap playing field and sprites

     

    increment counters

    test counters to see if sprites should go to next animation

    update playing field in CPU RAM

    tell music players to go 1 tick

    KSCAN

     

    The music is playing at regular speed and my tick counter is advancing at 60 Hz so all's well. I'm not giving the ISR any time.

    • Like 2

  11. I'll be honest. I have very little idea of exactly that any of this stuff is. Can anybody shed any light on it?

    The purple ceramic chips with windows are common EPROMs. The 2532s are the largest there, and still have practical replacement use in TI-99/4A peripherals.

     

    The board with the white chip: probably some kind of industrial controller.

    The white chip with gold pins looks like a TMS9900 cpu: http://www.wikiwand.com/en/Texas_Instruments_TMS9900

     

    I don't think the board is from a computer series (like TM990) because it has no card edge, but I could be wrong.

     

    Most of the CPU lines seem to be buffered to the 50-pin connector at the right edge. Probably this connected to another board, hopefully one with memory on it, because I don't see any RAM or EPROM here.

    The 50-pin connector on the left edge goes through a lot of line drivers and buffers, so it is probably an interface to external signals.

     

    Thanks for sharing these photos.

    • Like 1

  12. Quick rundown:

     

    At the CTIUG meeting, we had an issue with a PBox or card or something.

     

    We were able to read and write to disks just fine, and we initialized and formatted a couple of disks.

     

    On our third initialization attempt, the system refused to format a disk. It still reads and writes just fine, but it will not initialize. We tried multiple 32k cards, multiple disks, and 3 different disk managers. We also swapped drives.

     

    We can read previously formatted disks, AND write to them--just cannot format/initialize.

     

     

    What in the good hell would cause this?

     

    I looked for IO Error 43 in the TI disk DSR source code. I did not find it yet.
    It means Illegal Operation on Seek/Rewind/Restore.
    Some guesses:
    1. I wonder what is the expected error when you enable Protect Disk (the anti-copy protection flag, letter P on sector 0)
    2. There was an error trying to move the head to a particular track (but this should be a 6 not a 3)
    Maybe it is a power supply issue. Try a different Pbox? Drives draw the most power when spinning and seeking.
    • Like 1

  13.  

    What exactly are you writing to VDP? Can you share some code?

     

    I've got 2 ideas going:

     

    one is re-writing a 16x16 area in the bitmap name tables to cycle through 8 versions of the characters, to make it scroll one pixel at a time. This is 16 writes of 16 bytes each to the name table.

     

    the other is rewriting the corresponding pattern table (hopefully leaving color alone) which is 2k of data.

    I've organized the name table so that it increments characters going down, not across. That way I can blast 64 bytes for a precomputed column of 8x1, then do the next, without setting up the address again.

     

    Doing the second, it takes more time than one refresh to write 2k, so yes it's tearing obviously. It's going at about 4 frames per second.


  14.  

    I honestly wouldn't worry about vertical sync issues until you observe them. Until you're trying to blast bitmap graphics in real-time you don't really have an issue with this in assembly. (Coming from Basic and Extended BASIC it's easy to think "But sprites and graphics are SLOW!")

     

    Your best method of handling the VDP is to treat it like an output device, like a printer. Don't try and figure out WHAT you're writing in the midst of writing to VDP. Use buffers in CPU and pre-calculate so you can just blast it all out in one large block without stopping. You can also use a alternate screen in VDP and do swaps with a single VDP register change.

     

    I think I am seeing some tearing. And I am enjoying unrolling loops to just blast it all out!

     

     

    Hmm, I forgot that I could move the name table from >1800 to >3800 to do page flipping.

     

    But isn't there something with reading VDPSTA? I did something with the 9938 back in the day to synchronize page flipping (register write) with vertical retrace, because it was tearing even more obviously during a page flip.


  15. What is the technique to synchronize screen updates with the vertical sync?

    To avoid tearing by trying to draw in between video frames.


    My game loop is like this:


    LOOP

    enable interrupts briefly

    write screen and sprites to VDP

    KSCAN

    update internals

    B @LOOP


    I'm not sure the VDP writes still take more than 1/60th of a second, but I'm working on that.

    3 address changes for 3 blocks of 128 consecutive bytes seems like it could fit into one refresh cycle.

    2 writes to Bitmap name table and another to sprite attribute table.

  16. I started working in Magellan for bitmap mode. Version 3.3 x64 made the Export Assembly dialog work for me. I could not get the dialog in 3.05, 3.1, etc.

     

     

    The link on the Development Resources thread points back to the 3.05 version.

     

    This is the most fun I've had in a great while. Tak for dit forbedring!

     

    -Erik


  17. Parsec doesn't work on a TI-99/4 :P

     

    As the owner of that TI-99/4 monitor and the 99/4 console used in the magazine, I swear that Retro Gamer photoshopped that together. Radically. The table was white and there was stuff in the background. It's possible that the 99/4 monitor screen image did not photo well, so they just photoshopped a Parsec image onto it.

     

    As Marty stated here, conditions were far from ideal. I was setting up exhibits when the request came in: Retro Gamer wanted a 99/4A photo shoot. And Marty had 1 week to write up an article. I had a work deadline right after the show, so I pointed him at Orphan Chronicles and Bill Gaskill's TImeline. I was not shown any of the article in progress.

     

    Oh well.

    • Like 2
×
×
  • Create New...