intvnut
-
Content Count
3,713 -
Joined
-
Last visited
-
Days Won
7
Posts posted by intvnut
-
-
On 2/22/2021 at 10:00 AM, DZ-Jay said:Ah, so writing doesn't occur per sector, I see. I thought you had to read/write/erase in blocks of 8 rows. Re-reading the documentation I see that erase is per sector, but read and write is per row.
Implied in all that is that a "FLASH row" can hold an array of 96 words, is this true?
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.
On 2/22/2021 at 9:41 AM, DZ-Jay said:I though of that, but didn't really know why it was split to being with. Is there any reason why you would ever call FLASH WRITE without first calling FLASH ERASE? If not, why not build it into the call to FLASH WRITE?
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.
-
2 hours ago, carlsson said:It seems sometimes you can replace an electrolyte with a ceramic, though you would watch out for ESR. Perhaps better to wait for the right kind, plus that 1 uF ceramics apparently is on the upper end of its range.
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.)
-
3 hours ago, carlsson said:Are there any timers, NE555, capacitors or similar inside the Intellivision that could have gone bad, so some games that are fast on initializing are border cases for the system being ready to boot without pressing the reset button? I have a very vague memory of some VICs that took very long to count its memory on boot and it was some aged component. If Joe has tested the LTO hardware and firmware on plenty of systems (both directly and their customers) and it usually works, it might be a straw to grab?
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.)
-
4
-
-
8 hours ago, Sinjinhawke said:It’s an original.
I assume that means "original Intellivision I console."
QuoteHitting reset does indeed get the game working. I didn't try this because I have the console open and I need to stick something in to press down on the reset. Much appreciated.
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.
-
4
-
-
11 hours ago, Sinjinhawke said:Didn't realize I posted this in Programming. That was not intended. I will repost in the main forum.
FWIW, I only saw this because you posted it in the programming forum. 🙂
-
2
-
-
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?
-
1
-
What type of system is it? If there's a firmware issue on my boards, I can try to address it.
-
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.
-
-
3 hours ago, etxmato said:Yes the Studio IV BASIC is rather slow. One reason for it being slow is that it is written in a pseudo code language, similar set-up as the Chip8. The same BASIC was released for the VIP as the VP700 Tiny BASIC. Both use the same pseudo code (more or less) but interpreters have some larger differences. So the fact that it is not really coded in 1802 code makes it that much slower.
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.
-
1
-
-
2 hours ago, carlsson said:The binary files are included in the emulator package, the assembler source is not.
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.
-
14 minutes ago, carlsson said:It looks like members of the COSMAC ELF group may be able to see these files.
-
On 2/15/2021 at 8:43 AM, carlsson said:So what does this emulated RCA Studio IV clock in at? Roughly 16 minutes and 35 seconds = 995 seconds! That is just over 3 times as much time as the ECS BASIC and almost 14 times longer than the Comx BASIC that among micros is considered to be slow. Actually at first I ran the benchmark without the division on line 35 which then took about 760 seconds, or 3.5 times as long as ECS BASIC.
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.
-
1
-
-
14 hours ago, carlsson said:Probably the two BASIC implementations are quite different under the hood, in particular if the VIP II runs on half the clock frequency but is five times faster...
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.
-
21 hours ago, Intelligentleman said:So if I play a certain "note” on the keyboard, the program knows to call up a specified BASIC routine. This routine then runs and causes the audio/visual experience to change.
It seems like you'd want higher-order snippets than just a BASIC statement. You want a full-blown subroutine. If you use IntyBASIC, it seems like it shouldn't be too hard to write a program that scanned the synth keyboard and had an ON x GOSUB to invoke one of 49 different routines based on which synth key you pressed.
You'd need to write that scanner, or integrate my assembly code synth scanner.
My assembly code scanner would actually do the "ON x GOSUB" thing for you, the way it's currently written. It dispatches key-down and key-up events for all 49 keys independently, so you can press chords, etc.
A different approach, depending on what you're going for, might be to have a main loop that has up to 49 * 4 different condition tests ("just pressed", "held down", "just released", "not pressed") that repeatedly cycles and processes all keys.
21 hours ago, Intelligentleman said:Alternatively, could I record the audio “sound” of rudimentary BASIC programs or definitions and piece together a BASIC program in a wav editor like audacity? Then, play it back to a the intellivision?
That won't quite work, as I believe the data structure that represents each line of an ECS BASIC program has absolute address information hardcoded in it. MS BASIC does the same thing; however, MS BASIC has a fixup pass that runs after loading the program. I don't think ECS BASIC has that.
All that said, it seems like it shouldn't be too hard to write an ECS BASIC tokenizer that runs on a PC and produces a binary that can be run through a binary-to-wave converter to produce something you could CLOD. (I believe I've posted my bin2wav utility in the past that did the necessary FSK encoding. It's not a difficult conversion)
-
1
-
-
The IntyBASIC compiler output interlists your original code with the assembly code it generated.
It can be rather instructive to write code, compile it, and see what IntyBASIC produces. IntyBASIC doesn't have a general register allocator, but it does try to reuse values it's already loaded in registers within an expression. So, swapping the order of operands in an addition, or placing parentheses creatively can make a difference.
-
2
-
-
I have merged cart.mac with IntyBASIC multiple times over the years and it works nicely. Since it keeps track of how much you've used in each "ROM segment", you can issue ROMSEG directives to move pieces of code around without using fragile ORG statements. I realize that "pushes people toward a specific work flow," but it's a workflow that not dramatically different from ASM ORG. It's just a lot friendlier about reporting ROM size and overflows, and a lot less fragile genereally. That, and you don't have to change the order you define things in your source file when you want to move things around physically in your ROM.
But, you don't need to go that far to get some basic sanity checking. To detect basic ROM overwrite bugs, add the assembler command line flag --err-if-overwritten, or the shorter spelling -e.
And if you have certain memory areas that are 100% no-go, you can add some code near the top of your BASIC program to make them off limits. I think the following should work. A Q&D test confirms it.
' Make $7000, $C000 off-limits. ASM ERR_IF_OVERWRITTEN 1 ASM _tmp QSET $ ASM ORG $7000 ASM DECLE -1 ASM MEMATTR $7000, $7000, "-RWBN" ASM ORG $C000 ASM DECLE -1 ASM MEMATTR $C000, $C000, "-RWBN" ASM ORG _tmpYou can get AS1600 to output a friendly, human readable memory map summary by adding --show-map or -m to the assembler command line. For TagAlong Todd 2V, it outputs:
MEMORY MAP SUMMARY =========================================================== Address Range Size Flags ----------------------------------------------------------- $5000 - $5EC2 $0EC3 R---P =========================================================== TOTAL INITIALIZED SIZE: $0EC3 wordsAnd if you add the overwrite checker above, you'll get additional lines in the memory map summary for those addresses. You'll see that the flags show this area as no-read, no-write. The additional words will not appear in the final BIN file either.
MEMORY MAP SUMMARY =========================================================== Address Range Size Flags ----------------------------------------------------------- $5000 - $5EC2 $0EC3 R---P $7000 - $7000 $0001 ----P $C000 - $C000 $0001 ----P =========================================================== TOTAL INITIALIZED SIZE: $0EC5 wordsOnly downside is that the two extra words count toward your Initialized Size that the assembler reports.
I suppose I could had a more general feature to the assembler to throw an error if the current address ever crosses boundaries that the programmer specifies.
-
1
-
-
3 hours ago, RetroRonny said:I thought it was ready to run, but it is empty and I have to fill it first
I unfortunately do not have the necessary licenses to all of the original games in order to do that. And yes, I intend to stay in the good graces of the copyright holders, just as Chad did with the Intellicart and Cuttle Cart 3.
-
3
-
-
2 hours ago, intvsteve said:Drop old OSs: inevitably there will be an outcry! To this I suppose i could simply say: use the last version that worked - no new features for you!
For $10 more, we could ship a Raspberry Pi Zero with a sufficiently up-to-date Linux + GUI. ($5 for the RPi0, $5 for the power brick and SD card.) 😉
For $10 you can get a machine comparable to a economy machine at the time Windows XP came out, but hopefully running a new enough OS to run the LTO Flash GUI. 😀 And with a little more work, it'll run jzIntv just fine as well!
-
2
-
-
3 hours ago, ClassicGMR said:if the manufacturer isn't supporting an operating system anymore then you shouldn't feel obligated to find ways to make your software work on the outdated platforms. Just my 2 pennies...
...he says in a thread devoted to a flash cart for a system that went off the market over 30 years ago.
😉😉😉😉😉
-
2
-
-
On 1/28/2021 at 9:49 AM, rietveld said:Linux Wine
but if you have a link to the source code I will try to build and compile it in commnand prompt on Ubuntu Bionic
There's a Download Source Code link on the LTO Flash User Interface page. I don't know offhand whether there's also a public repository with the latest work-in-progress. I'll let @intvsteve comment on that.
5 hours ago, stringfellow said:It's all good. I was just worried that I did something wrong or that I would miss out
I've had a handful of emails come in (yours included) that I need to go through and respond to. I will do that before I open the floodgates again. I've just been really busy the last week and a half between LTO Flash! and some other Intellivision commitments that I'm working on. I went through a surprising number of JLP boards in less than a year, and needed to get more made! My typical batch size usually lasts longer than a year.
Email is a special kind of time sink. It doesn't seem like it should take that long, but somehow once I start processing email, I lose most of an evening. AtariAge programming questions, OTOH, I can usually whip out on my phone w/out too much thought, because I don't have to cross check anything or update tracking spreadsheets, etc.
-
Chances are good that your program has either spilled into an address range such as $7xxx, which requires special handling, or one part of your program ended up overlapping another part of your program.
It's not clear from your message, however, whether:
- IntyBASIC fails to compile your BAS file into an ASM file.
- AS1600 fails to assemble your ASM file into a BIN+CFG (or .ROM).
- jzIntv fails to run the resulting BIN+CFG (or .ROM). This includes the Intellivision starting up, but going "of in the weeds" / "CPU crashed".
Knowing what to do next depends on which step is failing.
-
1
-
Hey, sorry for the silence. I have been busy, and will get back to following up on email now that we're close to availability again.
I'll post a more detailed update here soon.
-
1
-
-
Adding to the ASCII art and diagrams: Here's the diagram I personally refer to when I need to look up how bits map to disc and keypad inputs. This diagram appears in jzintv/examples/task/scanhand.asm, FWIW.
;; DISC ACTION KEYPAD ;; ;; Bit 0: Down Row 0 keys --------- 1 2 3 ;; ;; Bit 1: Right Row 1 keys --------- 4 5 6 ;; ;; Bit 2: Up Row 2 keys --------- 7 8 9 ;; ;; Bit 3: Left Row 3 keys --------- C 0 E ;; ;; Bit 4: Corner | | | ;; ;; Bit 5: T/L Col 2 keys --------- | -- | ---+ ;; ;; Bit 6: L/R Col 1 keys --------- | ---+ ;; ;; Bit 7: T/R Col 0 keys ----------+ ;;"Corner" refers to diagonals on the DISC. It disambiguates between different diagonals. You can see why I called it that in this image I created eons ago.
I think I'm the only person who doesn't think that diagram is ugly. YMMV. The four short spans associated with bit 4 are all on diagonals, which is why I called that bit "corner." Maybe "diagonal" would be a better term?
Bit 4 is only set by the DISC, and never set by the keypad or action buttons.
The IntyBASIC up/down/left/right test bits 0, 1, 2, 3 directly, and I believe ignore bit 4.
-
2
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
LTO Flash! - Intellivision Flash Cartridge Information
in Intellivision / Aquarius
Posted
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.