Jump to content

intvnut

+AtariAge Subscriber
  • Content Count

    3,713
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by intvnut


  1. On 1/26/2021 at 7:47 AM, Zendocon said:

    Of course, I know that looking at key presses involves looking at Bits 5-7.  But I'm curious why you're putting Bit 15 into these Functions.

     

    Does it have to do with the Sign/Carry bits in the CPU?  I know $1ff and $1fe are actually 16-bit, being lumped with the sound chip.

    It's possibly simpler than you're probably thinking.  For one thing, IntyBASIC doesn't give you direct access to any of the flag bits.  I have to make due with whatever comparisons it offers me.  That's a hint...

     

    Here's my code again for reference:

    On 1/25/2021 at 10:12 AM, intvnut said:
    DEF FN KEY_ON_CONT1 = ((PEEK($1FF) AND (PEEK($1FF) - $20)) + $7FC0) < $8060 
    DEF FN KEY_ON_CONT2 = ((PEEK($1FE) AND (PEEK($1FE) - $20)) + $7FC0) < $8060 
    DEF FN NOKEY_ON_CONT1 = ((PEEK($1FF) AND (PEEK($1FF) - $20)) + $7FC0) >= $8060 
    DEF FN NOKEY_ON_CONT2 = ((PEEK($1FE) AND (PEEK($1FE) - $20)) + $7FC0) >= $8060

     

     

    I'm applying three tricks.

    1. The construct (X AND (X - 1)) gives you the value of X after clearing the rightmost 1 bit. 
      • For example, $AA becomes $A8, and $F0 becomes $E0.  The number 0 remains 0. 
      • If you replace 1 with a power of 2, it removes the rightmost set bit at or above that power of 2.  So, X AND (X - $20) removes the rightmost set bit at bit position 5 or above; the lower bits remain untouched.  $FF becomes $DF.  $E5 becomes $C5.  $1F remains $1F.
    2. I operate on the inverted keypad input: 1 means no input and 0 means input.
      • I know bits 15:8 are always zero.
      • I know bits 7:5 are 111 when nothing is pressed, and one of 001, 010, 100, or 000 when action button(s) are pressed.
      • I know bits 7:5 are 110, 101, or 011 when keypad is pressed.
      • Based on this I was able to construct a truth table, which I'll include below.
    3. You can perform a range comparison with a single subtract and compare, rather than two comparisons.  This cuts the cost of a range comparison almost in half.
      • In C, I would do this using unsigned arithmetic, by subtracting "min" from the value I'm checking so the range effectively starts at 0.  Values below the range become large positive values.  I then compare the value against "max - min", and get both halves of the comparison in one step.  That is, with unsigned arithmetic, I can test min ≤ value < max with (value - min) < (max - min).
      • In IntyBASIC, the comparison is signed, unless I use an unsigned variable; however, I'm not using any variables.  I can do the same trick, but I have to bias all the values by $8000 to make it work with signed arithmetic.  If you add $8000 to $7FC0 and $8060, you'll get -$40 and +$60.  ($FFC0 = -$40).  That means I'm looking for $40 ≤ value < $A0.  (Remember, $40 + $60 = $A0.)

     

    So this is the truth table I mentioned above:

     

    'Truth table on bits 7:5 of the raw controller input:
    '(000 - 001) AND 000 = 000  two buttons?
    '(001 - 001) AND 001 = 000  button
    '(010 - 001) AND 010 = 000  button
    '(011 - 001) AND 011 = 010  keypad
    '(100 - 001) AND 100 = 000  button
    '(101 - 001) AND 101 = 100  keypad
    '(110 - 001) AND 110 = 100  keypad
    '(111 - 001) AND 111 = 110  nothing

     

    As you can see, among the 8 combinations, only two outputs, 0102 and 1002, correspond to the keypad.  So, numbers in the range 010000002 - 100111112 theoretically could correspond to a keypad key, whereas everything else isn't.  This range is slightly over-broad, but sufficiently tight for our purposes here.  We could always tighten the range.   (Note:  The subscript 2 just means "binary.")

     

    So, 010000002 is $40, and 100111112 is $9F.  I have a keypad press if $40 ≤ value ≤ $9F.  Or, equivalently, $40 ≤ value < $A0.  Ta da.

     

    • Like 3

  2. 13 hours ago, PuzZLeR said:

    Forgive me as I still don't get it. I played around with it.

     

    I know you guys know what you're talking about, but I just ask for just a bit more clarification.

     

    Particularly, if you can give me a simple example regarding:

     

    ' Just ignore keypad

    ' Process anything else

    'decode disc 1

     

    As an example of what I'm trying to do is that I have implented code to pause the game by hitting zero. It works, but, before it pauses it tends to shoot first (with what a side button is supposed to do) or move the avatar a bit (which is what only the disc is supposed to do).

     

    Any insight?

     

    Thanks again.

     

     

     

    As @mr_me said, none of the keypad bits aliases any of the side action buttons.  If you're seeing that happen, it's because you're using CONTx.BUTTON, and IntyBASIC's taking a shortcut.  IntyBASIC doesn't check whether two bits are set, and so will misinterpret keypad as button.

        ;[1] b = CONT1.BUTTON
        SRCFILE "/tmp/b.bas",1
        MVI 511,R0
        XORI #255,R0
        ANDI #224,R0
        MVO R0,var_B

    You can avoid that by testing for B0, B1, B2 explicitly, or maybe trying the following replacement, which is slightly more expensive than CONT1.BUTTON, but way cheaper than testing B0, B1, B2 separately.

    DEF FN CONT1_BUTTON = (PEEK($1FF) AND (PEEK($1FF) - $20)) < $20
    DEF FN CONT2_BUTTON = (PEEK($1FE) AND (PEEK($1FE) - $20)) < $20
    DEF FN CONT_BUTTON  = (PEEK($1FF) AND (PEEK($1FF) - $20) AND PEEK($1FE) AND (PEEK($1FE) - $20)) < $20

     

    As for how to use the tools that @nanochess and I offered, you want to do something like this:

     

    IF NOKEY_ON_CONT1 THEN
       ' decode action buttons
       IF CONT1.BUTTON THEN '... whatever
       IF CONT1.UP = ... THEN ' ... whatever
       IF CONT1.DOWN = ... then ' ... whatever
    ELSE
       ' handle keypad input
       IF CONT1.KEY = 0 THEN '... pause
       '... decode any other keypad keys
    END IF

     

    That said, as @mr_me points out, sometimes one switch will close before the other, and you don't know whether you're getting a keypad input or a DISC input.  I've tried several strategies over the years.  The best you can do is "good enough."  For example, in Space Patrol, if you press [Enter] on the Select Mission menu really, really slowly, on most controllers it'll close the switch associated with tapping the disc to the left first, and will switch the menu selection on you before recognizing the [Enter] key.  

     

    I added about a half-second debounce on that input, so only folks trying to cause problems would see an issue.  "Hurray, you succeeded.  You win a prize!  Your prize today is a wrong menu selection, because you decided to press [Enter] slowly over the course of 2 seconds."  Play stupid games, win stupid prizes, I guess!

     

    In a reaction-time driven game, you don't want to add a lot of debouncing on controller inputs as that adds to controller lag.  In the past I've implemented heuristics such as: 

    • If I see two bits asserted in bits 5..7, assume there's no keypad input.  Action buttons assert 2 out of 3 bits among bits 5..7.
    • If I see bit 4 asserted, assume there's no keypad input.  Bit 4 is only ever asserted by the DISC on certain diagonals.
    • If I see an input that looks like exactly N, S, E, W (i.e. exactly 1 bit asserted out of bits 0..3), and no other bit set among 4..7, then:
      • If I haven't seen any inputs at all recently, then wait a small bit of time before deciding that's a DISC input.
      • If it's been stable for a small bit of time, go ahead and assume it's DISC input.
      • If I've seen any other DISC inputs recently, assume it's a DISC input.

    So what are "recently" and "small bit of time"?  That's up to you.  Reasonable initial values for "recently" might be "4 or 5 frames", and "small bit of time" might be "1 or 2 frames."

     

    If you want to go down this path, then you're basically bypassing the CONTx infrastructure in IntyBASIC and writing your own.  

    • Like 3

  3. The following handy functions generate better code, and AFAICT are correct.

     

    DEF FN KEY_ON_CONT1 = ((PEEK($1FF) AND (PEEK($1FF) - $20)) + $7FC0) < $8060
    DEF FN KEY_ON_CONT2 = ((PEEK($1FE) AND (PEEK($1FE) - $20)) + $7FC0) < $8060
    DEF FN NOKEY_ON_CONT1 = ((PEEK($1FF) AND (PEEK($1FF) - $20)) + $7FC0) >= $8060
    DEF FN NOKEY_ON_CONT2 = ((PEEK($1FE) AND (PEEK($1FE) - $20)) + $7FC0) >= $8060

    Now you can say:

    IF KEY_ON_CONT1 THEN GOTO skip_disc1
    ' decode disc 1
    skip_disc1:

    Or:

    IF NOKEY_ON_CONT1 THEN 
       ' decode disc 1
    END 

    And, of course, you can make a version that lets you put the controller address in a variable, so that you don't force your user to use controller 1 (which may be the most worn on most systems).

    • Like 1

  4. 1 hour ago, intvsteve said:

    There will be ROMs that can be "locked" to a particular cart. Those won't be playable on a different cart.

    BTW, we use this for two purposes:

    1. Beta-testing new games in development.  Previously, we burned these onto boards and mailed them around, and that gets quite expensive.  Shipping a board two ways costs more than the board itself, and can be quite slow.
    2. Selling ROMs to individuals.  That's been discussed to death, so I don't intend to rehash it.  The short version, though, is that LTO Flash supports that business model.  And, as I said, if your LTO Flash board fails, we can arrange for you to get corresponding ROMs for the replacement board.

    The new batch of boards obviously has a new batch of keys.  I need to program up and test the blank boards that remain, so that they're covered as well.  That's actually the main blocking item at this point.

    • Like 1

  5. 13 minutes ago, Hastor said:

     Just would be crappy if your cart dies, you lose your ROMs too!

    In the untimely event your LTO Flash! dies, I will swap out the board.  At that time, we can also arrange to get you updated encrypted ROMs for the new board.

     

    I do try to keep a stock of boards for RMA purposes.  I have had a handful of failed boards returned.  The most common failure mode looks like a static electricity hit in the middle of the connector. 

     

    To avoid that fate, pick up your cart by the sides, not the ends, particularly in the cold, dry months.

     

    42 minutes ago, Games For Your Intellivision said:

    For those people acquiring the new copies of LTO Flash!, please keep in mind that I do NOT have encrypted ROMS for 'A Tale of Dragons and Swords' nor any other title.

    I hope to get to this in the next few days. I have been swamped every evening, as I also still have other Intellivision hardware and software commitments to fulfill in addition to wrangling LTO Flash! orders.

     

    Lately, I spend a few hours a day on Intellivision commitments after work.

    • Like 5
    • Thanks 1

  6. 3 hours ago, ITAdvantage said:

    I'm on the Sears variant, not the Model II...I was using that as an example of some of the compatibility issues wondering if that was the case with the Sears model.  It could just be a problem with my system, I was just checking if I was missing an obvious compatibility issue with the Sears model.

     

    3 hours ago, intvsteve said:

    The games you mentioned I think all use IntyBASIC (maybe Space Raid does not). That's the only common thread I see... The games tend to use a common controller input polling loop IIRC, so there's that I suppose.

     

    And the controllers are stock Sears controllers? It's almost like there's a shorted pin somewhere. I've observed cases in the past where some games would boot and get to the initial play screen, and others would seem broken, and it had to do w/ bad controllers (or, <ahem> someone hooked the controllers up backward on a 2609....)

     

    2 hours ago, ITAdvantage said:

    Ok, then that settles it, must be my unit.  I appreciate you checking that out, it was so weird I was questioning my sanity.  

     

    FWIW, I did much of my development and testing on a Sears unit.  In fact, I think one of the production batches used a Sears unit.  So, no compatibility issues on that front.

     

    As @intvsteve mentioned, many games have issues with stuck inputs.  It's common in many IntyBASIC games, as well as some of the classic titles.  In some cases, they wait for both controllers to be fully released, and the release never comes.  In other cases, the controller inputs get merged in a way that makes it impossible to register valid inputs properly.

     

    In the LTO Flash! menu, I believe I took some prophylactic steps to allow it to function even if there's some stuck bits.  

     

    To test your controller inputs, you probably want something really stripped down.  I don't know whether @freewheel's diagnostics are the right fit.  You really want something dirt simple that just shows what bits are being asserted on each port.  I'm certain I've seen such a ROM here in the forums.  Heck, I'm sure I've written one at some point.  That'll help get to the bottom of this.

     

    The last time this came up was when @Lathe26 had a controller issue that was caused by stray current on the I/O bus on an Intellivoice.  Its "wireless controller" support was causing one or two of the bits to get stuck on the controller port.  We eventually figured it out a slightly fancier debug monitor ROM.  In the end, a bit of rubbing alcohol and cotton I think fixed the Intellivoice.

     

    If anyone has time to dig up such a ROM, or write one (w/out using IntyBASIC, to rule out any vagaries of the intybasic prolog/epilog code), that's what we need here.


  7. 3 hours ago, poconojo said:

    I cannot figure out how to get the LTO flash to work. My Mac will not recognize the flash cart. Is there a step by step video on how to do the installation?

    Please double-check that you're using a data cable and not a charging cable. That's the most common cause. 

     

    Macs running 10.9 or later should already have a native FTDI driver that comes with the OS.  If you're running 10.7 or 10.8, you will need to install the FTDI VCP drivers from FTDI's web site.  The GUI doesn't support MacOS before 10.7.

     

    I have not yet tried the new M1 based Macs, but I expect they should work.  LTO Flash! looks like a serial port to the operating system.


  8. 11 hours ago, ClassicGMR said:

    Oh my God I want an HTK Blash! so badly now!!

    I think I found the original HTK Blash! cart, although I am not certain. This one actually reports itself as DTG Flas`!, but otherwise behaves the same. 

     

    PXL_20210116_061705331.thumb.jpg.061465b5011415e12d9b6c44064cc857.jpg

     

    I'm not entirely sure whether it's the same cart or one with a similar failure.  I don't recall seeing two carts with the "I can't count" problem.

     

    I'm not gonna lie: HTK Blash! is a hilariously awesome name.

     

    • Like 1

  9. 9 minutes ago, ClassicGMR said:

    THIS :) Had mine for 2 years * I think * and it has yet to leave the cartridge slot since I installed it. :)

    I'm in the opposite situation.  My Intellivisions have had over 900 LTO Flashes and several thousand JLPs in them over the last 4 years.  Good thing I use a daughtercard to avoid wear on the console's connector.

     

    Although, not all of those passed testing...

    IMG_20160819_010458.thumb.jpg.ec97cfc5af52e689f7ed9449dd800e36.jpg

     

    That board didn't even know how to count.  Watch PBlocks Clean and PB Erasures... those should increase monotonically...


  10. 36 minutes ago, Inky said:

    Received mine, and of course, windows isn't detecting it.  Grrrr

    EDIT:  Windows DID detect it, tried to install drivers, and the LTO software never detected it

     

    7 minutes ago, Inky said:

    And it works on my laptop.  Huh

     

    I don't use Windows much, so I am not well versed in the vagaries of driver install there.  Try restarting the LTO Flash! application. If that doesn't do the trick, try rebooting. And if that doesn't work, we'll have to pull in @intvsteve.

     

    ISTR, if you have the LTO Flash application open while the driver installs, it still won't see it.  You have to restart the app at a minimum.

     

    I don't think we ever figured out a pattern of which machines require a manual driver install and which work OTB. 

    • Like 1

  11. 29 minutes ago, ITAdvantage said:

    Just wanted to report I mailed a check to Joe, he promptly sent out my LTO flash which I received.  It was packed well, arrived quickly in perfect condition and I am beyond thrilled.  Just wanted to give @intvnut props for an excellent transaction and express my appreciation for his efforts.  I know these are a pain in the @$$ to make, but know this community is beyond grateful for providing us this amazing device.

     

    28 minutes ago, poconojo said:

    LTO Flash carts have arrived! Haven't been this happy since my first Intellivision console in 1980.

     

    I want to extend everyone's props to my mom, as well, as she's taken on a big portion of the assembly and shipping for this batch.  I'm not sure when these would have shipped without her help.

     

    I programmed and tested the boards, and assembled all the carts. She assembled, stuffed and shrink-wrapped the boxes and is shipping all the units to everyone.

     

    I handle the money side of the transactions, and send PDFs of shipping labels to Michigan for her to ship. It's a team effort, and I want to make sure she gets credit too.

     

    Thanks for all the kind words. I'm definitely going to forward these her way as well.

     

    And lest I forget, my excellent resellers are also an important part of the extended team.

     

    I want to thank @scalpel, @Steve Jones, and @gooddealgames for reselling LTO Flash!  That's helped us scale out the shipments a lot.

     

    I realize Canada's been slow, but it would have been 40× worse with 40 individual shipments.  The postal situation is outside our control.  I shipped the first 26 before Christmas!  At least they're finally in Montreal.

     

    @Games For Your Intellivision will be coming online soon with a handful of units as well.  About half of what I am sending him is already earmarked for individuals, though. I've gotten requests from all corners of the globe!

    • Like 4

  12. Note that if you're using hardware collisions, the visible flag is separate from the interaction flag.  An invisible MOB can still interact with other MOBs and the background.  IIRC, Maze-A-Tron uses an invisible MOB that's "one pixel larger" than the player's character, but otherwise coincident with it, for collision detection.

     

    (Or something like that.  Maybe it was one pixel "smaller".  I forget.)

×
×
  • Create New...