Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


intvnut last won the day on December 27 2016

intvnut had the most liked content!

Community Reputation

2,976 Excellent


About intvnut

  • Rank
    River Patroller

Profile Information

  • Gender
  • Location
    @R6 (top of stack)

Recent Profile Visitors

22,739 profile views
  1. Hello everybody. I am not dead, but I'm completely snowed under and have been for the last month+ during a tricky hardware bringup at $DAYJOB. I have only barely looked at my personal email or FB or AtariAge, and haven't opened most of my mail. This is the culmination of 3+years development work in a complex program and I'm at the center of it as one of the system architects. My apologies for suddenly going dark. I thought I would have more bandwidth, but I just had to put Intellivision stuff completely out of my mind because there was no room for it. I got dinged for missing my 8:30AM meeting this morning because I was up till 5AM debugging an issue (and didn't get it debugged). It's crazy! @Games For Your Intellivision I need to send you the list of Australian customers. I'm taking a 3 day "away from keyboard" break this weekend, but I will truly be away from keyboard. The next major phase of the bringup starts in a week or so, at which time the focus shifts away from the low level stuff I'm on and onto higher levels. I'll start to get some cycles hopefully in a week or two. There are more LTO Flashes coming. Several are ready to go in MI already, I just need to connect units to requests. More will be manufactured. I have more plastic shells now. I have a dwindling supply of boxes. I just need time.
  2. Yes. This is exactly the same JLP flash savegame feature we used on Christmas Carol. I don't know if you have any of the notes or code from that era, from when we were going to integrate a high-score table, etc. Flash consists sectors with 8 rows of 96 words/row. Thus, each sector has 768 words. You can read/write on row granularity, but you can only erase groups of 8 rows. These quantities are all dictated by the hardware. IntyBASIC provides a raw interface to the read/write/erase primitives that I provide in JLP, and my JLP primitives are thin wrappers on the hardware. One big reason, as already explained, is that erase will erase 8 rows, while write only writes 1. But why not just expose an API that deals with 768 word chunks instead, and have everyone erase/write on that granularity? Here's why: The flash wears out. The flash cells on JLP are rated for a minimum of 10,000 erase/write cycles. I usually recommend to folks to use a collection of rows, and spend one word of the save data to store a "generation counter." I recommend spreading your writes over at least 32 rows. That takes you from 10,000 writes to 320,000 writes at least. There's an additional advantage: If you lose power or suffer a glitch between the erase and write, you only lose your most recent update, rather than losing everything. So far, I haven't gotten a lot of traction there, it feels like. To be fair, 10,000 erase/write cycles seems like a lot. And, if you only write to flash when the values change, it's unlikely that you'll see 10,000 changes. My not-unfounded fear is that most folks will just blindly say "save values" even if they haven't changed. Depending on what you're saving and when (e.g. saving "progress flags" when you reach certain places in a game), that could end up being a lot of extra "saves" that just burn flash lifetime without changing what's stored. I have produced some reference code examples (and I think I even did one or two in IntyBASIC at some point), but it doesn't seem to stick. Honestly, I think to make it stick, IntyBASIC needs to provide a higher level API that just handles this, period. I suppose it could be something that lives in IntyBASIC's contrib/ directory, if the IntyBASIC docs also point to it. It's possible I'm oversensitive to this. *shrug* Just know that LTO Flash! aggressively wear levels its flash, and its flash has a larger E/W endurance rating than JLP (100,000 per cell, IIRC). I keep a minimum pool of 40 sectors to wear level over when the device is "full"; otherwise, I wear level over all free sectors.* And if you run a game that uses JLP Savegame functionality on LTO Flash!, it actually gets translated to LTO Flash!'s filesystem and gets transparently wear-leveled in LTO Flash!'s filesystem. So, you won't break LTO Flash! unless you put in some dedicated effort. ("We're defending against Murphy, not Machiavelli.") Manual wear leveling for JLP only matters on single-game JLP boards. ___________ *In case anyone is curious, I measure LTO Flash!'s remaining lifetime assuming it only supports ~2,000,000 erase/write cycles. But, you might notice I wear level over a minimum of 40 sectors, and 40 × 100,000 = 4,000,000, so there's already a built in 2:1 safety factor. And, if your device is less than full, I wear level across all the free space. So, LTO Flash!'s remaining flash life indicator is conservative by at least a factor of 2, and probably much larger for most folks. And, I'm willing to bet nobody's below 80% flash life yet. I'd be surprised if there's anyone below 90%, actually.
  3. I'm less concerned about ESR for something like a reset pin. Ceramic isn't polarized—at least, I don't think I've encountered polarized ceramics—which is also nice. The main thing is making sure the capacitance is high enough that the reset low-to-high transition does what it's supposed to do. 1µF does sound high for a classic ceramic disc capacitor. But I wonder whether that's mostly a cost thing? For something like re-capping an old PCB, we're not as worried about saving 5 - 10 cents per capacitor as Mattel would have been in 1980. Looking at Mouser's selection, it seems we have a number of options in ceramic, but they're pricey. (Dunno if that search link will work, but I'll try anyway.)
  4. It's most likely the reset capacitor. If the system comes out of reset a little too fast, I'll lose that race. Ordinarily, the cart can pulse Reset and run the race again in the off-chance it loses the race. But, if the capacitor is totally gone, then the race is likely super fast and the cart can't ask to run the race again. LTO Flash! also uses the reset input pin to start the game once it's loaded, to try to give as close to "Just powered on"/"Just hit reset" environment to the game as possible. I know with TutorVisions and TutorPros, you have to hit the actual reset button to start the game after it loads. Or, at least you did. I don't remember if I added code to still try to start the game in the absence of hardware reset on TutorVision/TutorPros or not. I'm not even sure what's wrong with the TutorVision/TutorPro reset input pin. It's actually there, and actually wired to an RC circuit, and it actually doesn't do what you want it to do. (From what I recall on TutorVision machines, you're hitting reset for everything for everybody, not just LTO Flash! or JLP boards.)
  5. I assume that means "original Intellivision I console." Quote from the other thread. My guess is that the reset capacitor needs replacing. If this is truly an Intellivision 1 system, then the capacitor you're interested in is C26, which is listed as a 1µF capacitor, 20V, +/-20%. I got this from the schematic and service manual linked here. What's likely happening is that the capacitor itself has dried out, and so the reset signal hops up too quickly. Simple ROM designs may cope with that, but my firmware-based boards need a little more time to sync up. (I suspect Intellicarts and CC3s will have similar issues.) JLP and LTO Flash will detect when they've lost a "reset race" by pulsing the reset input. But, if that capacitor is just acting like an open circuit, then that pulse may not make it through. C26 should be the capacitor right next to the reset button. While this picture is from a System /// board (since that's what I had handy), this capacitor hasn't moved since the Intellivision 1, from what I can tell.
  6. FWIW, I only saw this because you posted it in the programming forum. 🙂
  7. LTO Flash and the BSR releases have modern firmware. The earliest JLP boards behave more like dumb ROMs, and so require manual reset about as often as dumb ROMs. I tested this with a couple original Mattel boards, and JLP. A simple power cycle required hitting reset afterwards a certain fraction of the time. ISTR the Mattel boards required reset slightly more often than JLP. I revised the JLP firmware to try to force a reset on power-up, to work around power-up glitches. With that change, JLP boards didn't require a manual reset in my power-cycle test. That change has been in the firmware for a very long time now: 8 or more years, I think. Early JLP builds didn't have it (early 2012 or before), but I believe it was in the firmware by the time Christmas Carol was ready for production. Whatever issue Sinjinhawk is reporting sounds different. @Sinjinhawke, some quick questions: What type of Intellivision? Original 2609, Intellivision II, System ///, SuperPro? Something else? (Tandy, Sears, French SECAM, Bandai...) Do you get a solid color screen that sits still, or does it flicker periodically (about once per second)? That flicker (if you see it) is the reset code in the firmware trying to make things healthy. What color screen do you get? If it's not solid color, what pattern do you see? Do you get a black screen with hot pink vertical stripes, for example? Have you tried putting an Intellivoice or ECS between the cart and the Intellivision, to rule out cartridge connector or shell fitment issues?
  8. What type of system is it? If there's a firmware issue on my boards, I can try to address it.
  9. LTO Flash! doesn't come with a cable. OK, the first 150 or so I sold 4+ years ago did. The rest did not. It's possible you need to install the FTDI driver. Some Windows machines won't install it automatically. You can install it from here: https://ftdichip.com/drivers/vcp-drivers/ In any case, that's separate from the problem of whether the GUI recognizes the BIN files. The GUI tries fairly hard to recognize all known Intellivision ROM extensions. It should handle the oddball extensions like INT as well. @intvsteve is the GUI expert. Hopefully he can help get you going.
  10. I'm not sure you can fully explain its speed by that. TI BASIC on the TI-99/4A is itself written in an interpreted pseudo-code, and has to access all of BASIC memory through a 1 byte pinhole on the VDP. Furthermore, it's a floating point BASIC with 8-byte Radix-100 floating point. And yet, it's about 50× faster than this. (At least, comparing 22 seconds to 995 seconds.) The ECS BASIC @carlsson compared it to is very slow (203 seconds, almost 10× the TI-99/4A), in part because it excessively synchronizes with the vertical retrace interrupt. For 2 frames out of N (where N is usually 3), the interpreter is completely paused. Even after I optimized the ECS BASIC interpreter and math routines, I could only speed it up about 20%, due to losing so many cycles waiting for the EXEC synchro. This Tiny BASIC is 5 times slower than that, it seems. It's slow enough that it seems to execute about one BASIC token per display refresh, or something close to that. This may also partly why there are some performance differences between PAL and NTSC. Perhaps there's a misguided SYNC / DO SYNC in the main interpreter loop (leftover debug code)? Or maybe it's looking for a "break" key between each token, but waiting for a full debounce interval for no good reason? I can understand a slowdown due to double-interpretation. This seems like a bit much, though.
  11. I wasn't sure if you were a member of the COSMAC ELF group or interested in joining. I already have too much email to go through.
  12. It looks like members of the COSMAC ELF group may be able to see these files.
  13. Putting this into perspective: The loop iterates 1000 times. It takes almost 1000 seconds. That's one iteration per second. The loop is only 5 lines long. So, somehow, it's taking an average of ~700K cycles (at ~3.5MHz) per line of BASIC code. What the heck would you spend 700K cycles doing? At 60Hz, you get a vertical retrace every ~60K cycles, so that's about 11 display frames per line of code, average. That's around the average line length of the loop. 20 LET A=A+I ; 12 characters, 7 tokens 30 LET A=A*I ; 12 characters, 7 tokens 35 LET A=A/I ; 12 characters, 7 tokens 40 LET I=I+1 ; 12 characters, 7 tokens 45 IF I<1000 THEN 20 ; 20 characters, 7 to 11 tokens, depending on number representation That works out to an average of 13 characters per line. It drops to 11 if you treat the entire line number as one "character." The BASIC interpreter executes roughly at the rate of one source character per display frame. Something is badly broken in that interpreter. I'm going to guess there's a SYNC opcode (or DO SYNC), perhaps as a debug statement, in the core interpreter loop. SYNC and DO SYNC are the pseudo-code opcodes for vertical retrace synchronization, according to this. ECS BASIC slow for similar reasons, but not to this level of insanity. ECS BASIC doesn't do a full Vsync; rather, it just blocks execution during 2/N frames while the EXEC does its thing, and runs "full speed" during the remaining (N-2)/N frames. (N is usually 3, but can be made higher.) Is there a pseudo-code disassembly of TinyBASIC visible somewhere on the web? It should be easy to look for such a SYNC/DO SYNC statement. EDIT: Never mind, I missed it when I'd looked for it from my phone previously. It's right here. EDIT 2: I fail at reading comprehension when I'm hungry and should eat some lunch. That's the pseudo-code interpreter, not the BASIC interpreter. My request stands.
  14. Indeed. To get that degree of slowdown, it's either reparsing every time, or it has unnecessary VBlank sync (like ECS BASIC) or some other fundamental deep wrongness.
  • Create New...