intvnut

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: I'm applying three tricks. 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. 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. 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.

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.

Bonus points to anyone who figures out how my functions above work. I can post more details later, but it might be fun to work it out for yourselves first.

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

BTW, we use this for two purposes: 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. 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.

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

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.

I haven't officially fully opened direct orders, but I should probably go ahead and do so. I think all the stragglers from the original waiting list have come in that are going to.

It took a bit of mathifying.

Particularly because it's empty.

You said that LUI (the LTO Flash GUI) quit unexpectedly. That's something we should have @intvsteve look at.

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.

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

You can simulate it by changing your device name in LUI and uploading it to the cart. 🙂 On the plus side, it won't make your cart forget how to count. 😉

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... That board didn't even know how to count. Watch PBlocks Clean and PB Erasures... those should increase monotonically... VID_20160819_010559.mp4

🥳 🎉 🥳 🎉 🥳 🎉

We don't have an official Linux version at the moment. I think @intvsteve has built it successfully for Linux. In principle it should work, although we might need slight tweaks to the user-interface code that are specific to Linux.

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.

Actually, I think it may be the second batch. I got notification the second batch cleared Customs.

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!

🥳🎉🎊🎉🥳

I'll throw my hat in the "vim" ring, as that's what I use for everything. Also, it pains me to see Kiwi's complex, manually managed memory maps. I have integrated cart.mac w/ IntyBASIC's prolog/epilog code a couple times for folks. It's soo much nicer and has better error checking.

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

Well, that's where living, as we know it, was already taking over. (Jump to 8:06 if the link doesn't take you there.) And remember Fudd's First Law of Opposition: if you push something hard enough, it will fall over.

Well, I lived all my life on Planet Earth. (Yes, fake backdrop. Could it not be more DEVO?)