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,909 Excellent


About intvnut

  • Rank
    River Patroller

Profile Information

  • Gender
  • Location
    @R6 (top of stack)

Recent Profile Visitors

20,308 profile views
  1. 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.
  2. 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.
  3. It looks like members of the COSMAC ELF group may be able to see these files.
  4. 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.
  5. 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.
  6. 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. 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)
  7. 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.
  8. 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 _tmp You 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 words And 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 words Only 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.
  9. 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.
  10. 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!
  11. ...he says in a thread devoted to a flash cart for a system that went off the market over 30 years ago. 😉😉😉😉😉
  12. 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. 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.
  13. 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.
  14. 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.
  • Create New...