intvnut

The GUI itself, though, is drag-and-drop. I double checked just now that I can easily drag and drop ROMs into the GUI and it'll add them to the ROM list and offer to populate them in the cartridge menu. If you happen to have an Intellivision Lives! and/or Intellivision Rocks! CD, it's super straightforward thanks to intvsteve's amazing efforts. While I might seem like I'm hyping my own product, I'm actually hyping intvsteve: I still stand in awe at the GUI intvsteve created. It's amazing. You can also ask it to scan a folder (and the folders it contains) for Intellivision ROMs, and add them all to the ROMs it knows about. If it identifies the ROMs (based on a CRC checksum), it'll populate some information about the ROM as well. With recent versions of the assembler, homebrew authors can choose to include metadata about the game (title, author, etc), and the GUI should pick these details up. I've been encouraging game authors to include this information. Recent versions of jzIntv will also report this information.

If IntyBASIC can find intybasic_prologue.asm and intybasic_epilogue.asm, it should be able to find constants.bas. An IntyBASIC compile won't succeed if it can't find intybasic_prologue.asm and intybasic_epilogue.asm. Try copying contants.bas to the same directory as those two files?

I don't have an SE preorder list. When the SE is available, I'll describe all its details, and how to get on the list.

Just a heads up. I realize I've been very quiet lately. I've been trying to keep to a policy of not saying a darn thing until I can announce a shipping date. I don't have a shipping date yet. But, I can confirm two things: The Special Edition is happening, and will hopefully happen by the end of January. There is another run of LTO Flash! due after the Special Edition. These boxes have a bunch of LTO Flash boards waiting to get firmware and testing...

When they removed the other games from Roulette, they left room for this: .TITLECODE: PSHR R5 ; 5026 0275 MVI .PSG0.rgt_hand,R0 ; 5027 0280 01FE CMPI #$001E, R0 ; 5029 0378 001E BNEQ L_5079 ; 502B 020C 004C MVI .PSG0.lft_hand,R0 ; 502D 0280 01FF CMPI #$005E, R0 ; 502F 0378 005E BNEQ L_5079 ; 5031 020C 0046 MVII #$0007, R3 ; 5033 02BB 0007 MVII #$023C, R4 ; 5035 02BC 023C JSR R5, X_PRINT_R5 ; 5037 0004 0118 007B STRING " JOHN " ; 503A DECLE $0000 ; 504E 0000 MVII #$0007, R3 ; 504F 02BB 0007 MVII #$0292, R4 ; 5051 02BC 0292 JSR R5, X_PRINT_R5 ; 5053 0004 0118 007B STRING "ETTELUOR" ; 5056 DECLE $0000 ; 505E 0000 MVII #$0007, R3 ; 505F 02BB 0007 MVII #$02D0, R4 ; 5061 02BC 02D0 JSR R5, X_PRINT_R5 ; 5063 0004 0118 007B STRING "2001" ; 5066 0032 0030 0030 0031 DECLE $0000 ; 506A 0000 MVII #$0007, R3 ; 506B 02BB 0007 MVII #$02D5, R4 ; 506D 02BC 02D5 JSR R5, X_PRINT_R5 ; 506F 0004 0118 007B STRING " D E I" ; 5072 DECLE $0000 ; 5078 0000 L_5079: PULR R5 ; 5079 02B5 MOVR R5, R7 ; 507A 00AF Dabney Eats It, I suppose. If I decoded that correctly with my calibrated eyeball, that requires you to press 1+2+3 on the right controller, and 1+3 on the left controller. (O HAI!, I DID!) You should get this:

The tape drive is chonk! So's that electric razor... I mean microphone: Watch closely at around 2:54 - 3:00, where the cassette "lid" shifts in a way that makes it obvious it's just a piece of plastic sitting over a hole. And yeah, something's weird with the text in Football. Good spot on the extra pixel on the 0. The other labels do indeed seem to be GRAM-based text. Also, watch the display glitches during horizontal scroll around 3:54 (+/-). As you noted, the background wash doesn't seem to scroll with the foreground pixels (see right edge of screen). At the very least, they aren't suppressing the pixels that went beyond the right-hand boundary. In 1978, they would still be using a STIC emulator box rather than the final chip. That still seems like a weird bug to have. The blue in Baseball is somewhat muted. (Also seen in Armor Battle and Math Fun.) It actually looks a lot like the blue I got from the AY-3-8915 data sheet a long time ago. The flickery tanks in Armor Battle are likely due to the fact they're two MOBs each, and they probably haven't coordinated the MOB updates properly yet. The version of Math Fun is the "forward digits" version, and that brown looks brown! Well, orangish brown rather than greenish brown. And yeah... that text from the keyboard component was a total mockup. And the physical fitness... LOL.

What you really want, if you're going to do that, is a daughtercard that replaces the RA-3-9600 and has a socket for the STIC. With that, you could easily add a 20x24 character mode, double vertical-res text, multi-color background tiles, 256 GRAM tiles, full access to all 512 tiles in FG/BG mode (at least for the background; MOBs would still be limited), etc. With a little more elbow grease, you could also probably manage to do higher-vertical-res MOBs as well, just by curating the STIC's experience. Imagine a max-height MOB (128 scanlines?) that actually had different bitmap data on each scanline? That could be used to add a lot of detail to a scene when combined with higher-res BACKTAB. At some point, though, you have to ask yourself: Is it still Intellivision? I mean... look at this "TI-99/4A" demo, which is really just showing off the 100MHZ TMS9900 clone + DMA engine inside the F18A FPGA. At what point does it stop being an Intellivision and start being an Intellivision controller interface for something completely different? (Skip to 2:30 for where it gets really ridiculous.)

That's correct. The priority bit is a little odd: It determines if a given sprite is in front of or behind the background pixels. But, it does not change its ordering with respect to the other sprites. You might be wondering how that works. First, the sprites are stacked on top of each other with 0 in front, 7 in back. Then, for each given pixel of the result, that pixel either goes in front of or behind the background based on whichever sprite was "front-most" in the stackup of sprites. This can lead to weird paradoxes. For example, suppose MOB #0 is a horizontal bar, and MOB #1 is a vertical bar, and they overlap like this: 111 111 111 00000000 00000000 111 111 All fine and dandy. Now suppose I set both #0 and #1 to be "behind" the background, and I overlap the bottom right corner with background pixels 'b': 111 111 111 00000000 0000bbbb 1bbbb 1bbbb bbbb So far, so good. Now let's say I change #1 to be "in front of" the background. The image becomes: 111 111 111 00000000 0000bbbb 111bb 111bb bbbb Weird, huh?

I've never been great at reading linearly. I do more of a page level non-linear grep. Maybe that's why I'm better with data sheets and could never really grok fiction narrative.

Finally found the mask number table, by the way. Page 197 of the same PDF. This confirms 32040 is the mask number for the RAM. I wish I could find a CPS for the "40-1/4K Exec. ROM", as it might tell us what pin selects Sears vs. Mattel.

Aha... I figured out what's up with RA-3-9600-1. Basically, it looks like they speed-binned these turds, and the -1 parts aren't fast enough for PAL systems. See the clock period spec at the top of the page, and Note 2 at the bottom, on page 68 of this PDF: http://papaintellivision.com/pdfs/CCF10232011_00012.pdf And if that wasn't clear enough, on page 74: I'm sure I've read this text before. I must've forgotten about it.

BTW, this is the doc that has all the thermal testing stuff: http://papaintellivision.com/pdfs/CCF10222011_00011.pdf

Iiinteresting. I'm trying to remember whether I've seen Inty IIs with just the mask-number on top. I think I have. (That's that 32040 number you mentioned previously.) Sounds positively chilly compared to this:

That's actually by design. As the RAM test goes on, it increases the number of iterations of each test. The net effect is that it appears the test sequence slows down. Really, it's iterating each test in the sequence more times. I'm not sure that's necessary. And I'm almost 100% certain they won't fit in an Intellivision II with heat sinks, as the trays for the controllers nearly rest on top of the chips. The chips that were intended for use only with heat-sinks tend to have their pertinent information printed on the underside, and came with heat sinks epoxied on the top.

If the IAB bus phase doesn't produce the right vector at reset, then the machine won't boot. That's a nice single-point-of-failure right there. IAB is supposed to return $1000 right after reset, and $1004 subsequently. It only knows about reset thanks to ~MSYNC. So, if its ~MSYNC pin is damaged... Basically, if ~MSYNC is damaged and IAB causes the ROM to output the interrupt vector ($1004) rather than the reset vector ($1000), things are unlikely to go well from there, as the stack pointer isn't initialized, the RAM interrupt vector at $100/$101 isn't initialized... it'll send the CPU on a jump into some random location, most likely $FFFF. Since ~MSYNC is a pin that's also exposed on the cartridge port, I suppose that's a likely candidate for ESD strikes and damage.

I'm pretty sure the IntyBASIC random number generator isn't meant to be repeatable. It has a _next_random function that gets called in the interrupt service routine to advance the random generator. If you want a repeatable, replayable random number generator that runs from solely a seed and produces the exact same random numbers every time from that seed, you'll have to code one directly, I think. LFSRs are cheap both in execution time and storage. If you have some RAM to spare, a lagged-Fibonacci generator is also cheap, but requires RAM for the state. And, of course, you need to expand the seed to initialize the lagged-Fibonacci history buffer. I'm guessing you don't want the xkcd approach: And then there's the Doom approach.

Found it right away, I see. Awesome! It's fun to watch, isn't it?

Actually... I have seen Rick Koenig's original docs for his debugger (Version 3.0). He specifically mentions using "two of your business cards" as overlays (presumably drawing the debugger inputs on the back). I kid you not.

I keep staring at that and it hurts my eyes. I know you're losing 6 cycles to "ADDI" being split into "MVII + ADDR", but it feels like you're losing as much to "SLR + MULT." This sequence: ANDI #248,R2 SLR R2,1 MULT R2,R4,5 ADDR R2,R1 expands to: ANDI #248,R2 SLR R2,1 MOVR R2,R4 SLL R2,2 ADDR R4,R2 ADDR R2,R1 That's 40 cycles and 7 words. If you coded this in assembly yourself you could do: ANDI #$F8, R2 SLR R2, 1 ADDR R2, R1 SLL R2, 2 ADDR R2, R1 That's 34 cycles and 6 words, and leaves R4 untouched. *shrug* If you care about 6 cycles and one word, why not code directly in assembly?

BTW, in case I wasn't clear: I'm documenting what's already shipped and is in all 600-ish LTO Flash units today, and has been in jzIntv for over 3 years now. If I change anything, it will be to add to the ISA in a backward compatible way. Yes, there aren't any programs out there that use the existing ISA. But, the ISA has already shipped, and is actually verified. There's no real indication you're in an interrupt context or not. PV is not banked nor is it preserved. PV is primarily intended to be ephemeral and should be consumed immediately after it's generated. The instructions that set PV are also non-interruptible. Thus, the intended, safe and idiomatic use of PV is: EXT3OP X0, X1, X2 MVI PV, R0 I should make this clearer in the documentation. It's not meant for any other use. From this, you can implement a number of interesting idioms, but you really have to bolt a MVI or ADD, or something next to it to immediately consume the value. In general, using the extended register set (X0 - XF) from an interrupt handler needs to be done with care, as the standard ISR save/restore won't save and restore it. I'd wanted PSHM/PULM to make that more efficient. For now, it's maybe easier to say "don't use these from ISRs," but I need to include context switch concerns in the Programmer's Guide as well. Either that, or partition the Xregs so that some are for interrupt context and the rest are for foreground context. There are 16 of them. If I do an "upgrade" to the ISA, it might be work considering register banks as well, similar to an 8051. I don't want to try to detect "return from interrupt," though. I'd make bank selection manual. But, it'd be one instruction as opposed to many. At the start, I really wanted to avoid having an external status register, in particular because I hadn't worked out how to do branches efficiently. As it stands, I have a limited ability to encode new conditional branches efficiently, and I may have wasted my one opportunity by using the MVI xx, R7 encoding for TSTBNZ. I encoded the CMPxx the way I did, to better reflect how IntyBASIC performs comparisons. The CMPxx& construct allows you to build compound comparisons quickly, or to conditionally zero out a value (think "break statement"). A XSWD becomes part of the interrupt context in a strong way. PV seemed safe to me as long as you stick to the idiomatic use. XSWD is a little more of a problem because the instruction that generates it is not necessarily immediately before the instruction that consumes it. Reading it and PSHR'ing it onto the stack is no fun either. And then there's the simple concern that it's costly for me to compute. Some of the ISA implementations pushed the limit of what I could do on a 40MHz PIC. The I2BCD, BCD2I, ABCD/SBCD, ATAN2, and ISQRTFX were tight, as I recall. If you gave me 20% more cycles, I could compute the flags. I don't have those cycles. The lack of flags forces you into a "branch-free algorithm" mindset. Given that branches are costly anyway, it's not necessarily a bad place to be. What I'm missing is a good conditional-move instruction to round it out. "Based on src1, conditionally move src2 into dst." I like them, but I couldn't figure out how to arrange the operands to make it efficient. It really wants to be a 4 operand instruction, with the extracted-from entity separate from the extracted-to entity. In the end, I settled for a two-instruction sequence of shift (or multiply) followed by a rotate. Perhaps, in a V2 of the extensions. As you note, this starts looking more like an anti-goal. I'd need to consider whether to prioritize GRAM loading efficiency or obviousness. (e.g. use the more obvious encoding of 8 LSBs in each of 8 registers, or the more efficient encoding of packed 8-bit pairs in 4 registers.) And, without PSHM/PULM to quickly block transfer data into and out of the Xregs, the memory bottleneck quickly overwhelms whatever you might save. So, I decided to table those ideas until I had an efficient way to get data into and out of Xregs. I didn't bother trying to solve that one, as JLP stores 10-bit ROM in 12-bit pages rather than 16-bit pages, and already gets most of the benefit for me. (The 16-bit vs. 12-bit decision works on 4K page boundaries. Any game with significant voice can pack it in dedicated 4K pages and get the benefit.) That said, if you set aside an 8 word buffer of RAM, it wouldn't be hard to write an efficient 5-to-8 decoder that took a block of 5 16-bit words and output 8 10-bit words using the existing shifts and bit operations. It just didn't seem like the more pressing concern. A better use of my time would be to work on a tighter encoding for Intellivoice data, as the current data is not at all compressed. Yes, I used both meanings from C here: Address-of for the effective-address addressing modes, and bitwise-AND for the comparison instructions. I figured there's enough variation in heading update logic that having the inverse didn't make sense. You can easily convert ATAN2 into sine/cosine values of the desired precision with something like: ATAN2 R0, X0, X1 MVI @X1(sintbl), R1 ; sine value MVI @X1(sintbl+4), R2 ; cosine value MPY16 R1, X2, X3 ; assume X2 is velocity MPY16 R2, X2, X4 If you instead wanted to do that in fixed point, just replace MPY16 with MPYFXS. Or, if you want to model rotational inertia and use a finer-grain sine table, you could do that. etc. etc. Ah, remember the bad old days of how to detect 8088 vs. 8086 vs. 80286, before they added CPUID? I could even return a short manufacturer string like x86 does ("GenuineIntel" / "AuthenticAMD"). "LegitLTO"? I need to check whether RXSER / TXSER modify the register when branching to the error path. In any case, JLP and Locutus both put their serial port at the same address, so if / when these instructions come to JLP, the address for serial status will be the same. If someone figures out how to backport this to a CC3, you could always add a CP-1600X compatible serial port window at the alternate address. That's an out-of-place accumulation, as it required storing the intermediate result in X8 - XB. An in-place accumulation would have stored the accumulated value directly in X4 - X7 without disturbing other registers (except perhaps one for the carry). If I had instead defined the extended precision instructions as adding the carry/borrow to dst_hi, then I could have gotten away with fewer new instructions (just 2 rather than 4). This is a case where the rapid speed with which I spec'd the ISA caused me to miss an opportunity.

Good idea. I've gotten into the habit of not turning those on, since at $DAYJOB we just share the Google Docs directly and don't generate PDFs. They're a distraction there. Since I'm publishing PDFs, they make sense here. Excellent question. They're not all a slam dunk. I need to add performance data. Executive overview: The extended addressing modes build on Direct Mode, and so the cycle counts are the same as Direct Mode. That means "ADD @X1++(1), R0" takes 2 cycles longer than "[email protected] R4, R0". Extended branches are also built on Direct Mode, and have the same execution time as MVI addr, R7. Extended Reg-Reg instructions build on MVOI. I'm not sure if that's a 9 or 10 cycle instruction, but I think it's 9 cycles. The flat cycle count profile helps. There's no long-run-time microcoded beasts like x86. The fact that none is faster than 9 cycles, though, gives a drag relative to the 6 to 8 cycle reg-reg native instructions. Many of the instructions save time only if you have all the values you need in the X registers already. There's definitely a communication bottleneck between the X registers and the CP-1600. Popping over there for just an instruction or two is a loss far more often than not. When I went through Tag-Along Todd 2 to convert portions to CP-1600X, I found it tricky to get obvious wins everywhere. When I did, I found the computation largely migrated into the X registers, popping back at the end. The wins also tend to come when using the more complex instructions (BOUND, multiply/divide, I2BCD) that absorb multiple CP-1600 instructions. The simpler CP-1600X instructions only really help as glue when all the values are stuck in X registers and you need to glue the fancier instructions together. Some things turned out rather cute, such as the decimal print loop. I haven't really optimized this, but it's nice and compact. Perhaps a more focused version (with more comments and commentary) of this should appear in the Programmer's Guide section. DEC16: PROC ADDR R3, R3 ; \_ Set LSB to 1 to indicate leading spaces. INCR R3 ; / INCR R7 ; Skip the ADDR. DEC16A: ADDR R3, R3 ; Set LSB to 0 to indicate leading zeros. SUB3 5, R2, X2 ; X3 is number of digits to display. I2BCD 0, R0, X0 ; BCD decode the number SLL R2, 2 ; \_ Pop off suppressed digits into X1. SHLU3 X0, R2, X0 ; / AND3 X1, $F, X1 ; Keep only the last one. @@digit_loop: MOVR R3, R1 SARC R1, 1 TSTBNZ X1, @@non_zero BC @@no_digit @@non_zero: ANDI #$FFFE, R3 MPY16 X1, 8, X1 ADD X1, R1 ADDI #$80, R1 @@no_digit: [email protected] R1, R4 SHLU3 X0, 4, X0 ; Pop next digit into X1 DECBNZ X2, @@digit_loop SLR R3, 1 ; Restore R3 JR R5 ENDP As another example, the velocity/position update also ended up kinda cute, but also was almost entirely in X registers. It also leaned heavily on the rotated fixed point representation. The original used non-rotated fixed point, though, and was competitive in the base instruction set. I need to work up an actual performance analysis of the two to see how far ahead (if I did end up ahead) CP-1600X actually ended up. I suspect it wasn't very big. ; Note: X4 = $00FF at the start. [email protected] R4, R0 ; Target Velocity [email protected] R4, R1 ; \_ Velocity MVO R1, X0 ; / SUBFX R0, X0, X1 ; Velocity difference CMPLTFX X1, 0, X2 ; \_ +/- 01.00 based on sign of BOUNDU X4, 1, X2 ; / difference MVII #$0300, R1 ; Round away from zero (00.03) MPYFXSS R1, X2, X2 ; +/- 00.03 based on sign of diff ADDFX X1, X2, X1 ; Add rounding term DIVFXS X1, 4, X1 ; Divide by 04.00 ADDFX X1, X0, X0 ; Add rounded diff to velocity MVI X0, R0 ; Updated velocity [email protected] R4, R1 ADDFX R1, X0, X0 ; Updated position BOUNDFXU X5, X6, X0 ; Clamp to screen MVI X0, R1 ; Updated position SUBI #2, R4 [email protected] R0, R4 ; Save updated velocity [email protected] R1, R4 ; Save updated position Yeah, the TXSER / RXSER venture into "over the top" territory, and are really intended only for LTO Flash use, to improve serial transfer performance. I need to document how to detect whether they're supported, as I don't intend all implementations to support them. jzIntv doesn't support them at the moment, for example. JLP could support them, as it does have a serial port. Most of the instructions are focused on game-oriented communication. TXSER / RXSER are for space cadet applications, such as turning your Intellivision into a terminal server. Anyone want to write a BBS that runs on an Intellivision? LOL

I'm curious as well... It looks like it's based on my mod, just from a rough eyeballing of the component count and mix.

OK, so I think I've got the CP-1600X macro file in decent shape. I tested it a bit more thoroughly, and I modified Tag-Along Todd 2V to use the CP-1600X ISA a bit more heavily, including converting it to use the fixed-point types. One thing to watch out for: The extended register-to-register instructions are non-interruptible. This is both a blessing and a curse. You'll need to drop in a NOP every so often, or carefully partition your code to run on both the CP-1600 and the CP-1600X instruction sets. There's a few NOPs in Todd that I could eliminate if I scheduled the instructions a little differently. Some of the mnemonics changed names slightly compared to earlier PDFs. ADD, SUB, SHR, SHRU, etc. became ADD3, SUB3, SHR3, SHRU3. The "3" suffix means "three operands," and is meant to placate the assembler. The Tag-Along Todd download includes the cp1600x.mac file that defines the ISA extensions. You can copy that into the "examples/macro" directory in jzIntv, or put it wherever you need it. The attached ZIP file is designed to unpack directly in jzintv/examples/. The ISA document itself still doesn't have all the details, but it has plenty. Good luck! Locutus_CP-1600X_Instruction_Set_Extensions_20191203a.pdf tagalong2v_cp1600x.zip

I'd love to know how that turns out if/when you try it.