freewheel Posted January 18, 2018 Share Posted January 18, 2018 Cross-posting this as it's likely that some of the lurkers here have one. I've whipped up a program to test the various chips in a console, and try to help determine if you have a Tutorvision (or part-Tutorvision, sometimes referred to as an INTV88 motherboard with a standard EXEC ROM). I'd be curious if this actually works on real hardware, as I only have standard consoles to test it on tv_check.zip 3 Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 18, 2018 Share Posted January 18, 2018 (edited) I suppose I should add an explicit INTV88 mode switch to jzIntv? You can fake it right now by appending 8K bytes of 0xFF to an Intellivision 1 EXEC. However, that won't let you test "INTV88 w/ Intellivision 2 EXEC", which may well exist in the wild. If you append 8KB of 0xFF to the Intellivision 1 EXEC and feed it to jzIntv, this is what you get: EDIT: INTV88 w/ Intellivision 2 EXEC cannot exist in the wild, as the Intellivision 2 EXEC would conflict with the additional RAM on the INTV88 motherboard. Edited January 18, 2018 by intvnut Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 18, 2018 Share Posted January 18, 2018 On SuperPro system #1: On SuperPro system #2: On SuperPro system #3: On SuperPro system #4: My stack of SuperPro systems... As for why System #4 crashes: I suspect there's a bug in this logic on the mainboard: Here's what I've been able to work out on why IntyBASIC hangs: Right after taking our first interrupt (as part of the PAL vs. NTSC detection code), the Intellivision takes a second interrupt around address just before address $100A, double-stacking us in IntyBASIC's PAL/NTSC detection logic. While dispatching to the _pal1 ISR, the CPU takes another interrupt at location $100A... part of the interrupt dispatcher!! So, we run the _pal1 ISR, which sets _ntsc = 3. It also changes the ISR vec to point to _pal2. We return from _pal1 to location $100A... which immediately dispatches to _pal2 and sets _ntsc = 4. Once we return from this whole mess, we end up back at the _MAIN1 loop waiting to see _ntsc = 3. Instead, it sees 0 once and then 4. The code gets stuck there. So what's wrong with the circuit? Suppose the UNK_2 input in the bottom of the circuit really is generated in response to INTAK. If we respond late to an interrupt, we'll get a double interrupt. The INTAK response will cause INTRM* to pulse low briefly due to the AND gate on the lower right. It should also clear the BCD counters due to the AND gate at the lower left, feeding into the CLR inputs of the 74LS163s. However, the 74LS163s are synchronous-reset devices. So, if the CBLNK input happens to remain high at this time (because it's not an appropriate time for it to toggle), the counters won't reset. Thus, we'll get a short pulse of INTRM*, giving us a new interrupt. The CP-1610 does not disable interrupts when dispatching to the interrupt handler. So each new falling edge of INTRM* could send us off to an interrupt. What's the fix for IntyBASIC? One possibility: Move the MAIN1 label before the code that sets the ISR to _pal1. Another possibility: Make the very first ISR do something like this: . MVII #@@cont, R0 MVO R0, $100 SWAP R0 MVO R0, $101 EIS DECR PC @@cont: DIS MVII #STACK, R6 MVII #_pal1, R0 ; ... continue initialization with PAL/NTSC check. . This would ensure you reset the stack when you hit that first interrupt, so it doesn't matter if it starts with a double dispatch. 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 18, 2018 Share Posted January 18, 2018 With a one byte change, I was able to make this work on SuperPro #4. What was the one byte change? I changed location $5076 from $5 to $D. The net effect of this change was to change this loop in intybasic_prologue.asm from this: . MVII #_pal1_vector,R0 ; Points to interrupt vector MVO R0,ISRVEC SWAP R0 MVO R0,ISRVEC+1 EIS _MAIN1: MVI _ntsc,R0 CMPI #3,R0 BNE _MAIN1 . into this: . _MAIN1: MVII #_pal1_vector,R0 ; Points to interrupt vector MVO R0,ISRVEC SWAP R0 MVO R0,ISRVEC+1 EIS MVI _ntsc,R0 CMPI #3,R0 BNE _MAIN1 . That causes the PAL/NTSC detection to start over from scratch if it gets a double interrupt. The issue is that the ISRs for PAL/NTSC detection wind all the way to the "_ntsc == 4" state, without letting the detect loop at _MAIN1 ever see "_ntsc == 3", on an INTV88 system, and that's due to the double interrupt dispatch I mentioned, due to the apparent logic bug on the INTV88 mainboard. I don't actually have a logic analyzer to fully check out my hypothesis, but so far all the data I've been able to collect otherwise seems to confirm it. tv_b.zip 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 18, 2018 Share Posted January 18, 2018 Another possibility: Make the very first ISR do something like this: . MVII #@@cont, R0 MVO R0, $100 SWAP R0 MVO R0, $101 EIS DECR PC @@cont: DIS MVII #STACK, R6 MVII #_pal1, R0 ; ... continue initialization with PAL/NTSC check. . This would ensure you reset the stack when you hit that first interrupt, so it doesn't matter if it starts with a double dispatch. Isn't that what CART.MAC does? For what it's worth, I always thought this was a good thing to do anyway during boot up since the whole point is to take over command from the EXEC. -dZ. Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 19, 2018 Author Share Posted January 19, 2018 I suppose I should add an explicit INTV88 mode switch to jzIntv? You can fake it right now by appending 8K bytes of 0xFF to an Intellivision 1 EXEC. Quite possibly. If not, we just need to keep programmers in the loop on the EXEC hack. While there's not a huge practical need to do what I'm going, there IS the possibility of developing games for the INTV88 boards, if there are enough of them around. From what I've seen, someone could simply code for the Tutorvision and jam the WBEXEC onto the resulting ROM, but it'd still be nice to be able to test against both. Very cool that you've got a workaround in the meantime, much appreciated! Also appreciated is the level of detail you've put into analyzing this so far. We'll have to get Sir Nanochess to chime in on the PAL/NTSC detection. I've already pointed out a bug in the latest IntyBASIC, so if he's fixing that, he may want to fix this at the same time. I have no idea what kinds of side effects these changes could have, but I'm happy to muck up my own prologue.asm and see what happens. One thing though - on your INTV88, my program also detected the Tutorvision EXEC. Is that actually true, or did I mess something up? I wasn't aware of a "full" TutorPro being found yet. 2 Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 19, 2018 Share Posted January 19, 2018 One thing though - on your INTV88, my program also detected the Tutorvision EXEC. Is that actually true, or did I mess something up? I wasn't aware of a "full" TutorPro being found yet. Your code is operating correctly. FWIW, it's possible to make an INTV88 that lacks WBEXEC behave like a TutorPro w/ WBEXEC if you know what you're doing. Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 19, 2018 Author Share Posted January 19, 2018 Your code is operating correctly. FWIW, it's possible to make an INTV88 that lacks WBEXEC behave like a TutorPro w/ WBEXEC if you know what you're doing. Very very cool. I have a dozen or so consoles but nothing from 1988 onwards, so I can't test this myself. It *should* work on Lathe26's mostly-Tutorvision too. Maybe we'll find a few more in the wild this way. From what I can tell, we just need to hack Tutorvision ROMs and we can sneak the WBEXEC in that way. Not sure if that's what you're referring to, but it at least gives non-technical folks a way to play Tutorvision games. I'm really hoping someone makes some new ones, given what we've got at our disposal (and the likelihood that we can find a few dozen INTV88s over time). 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 19, 2018 Author Share Posted January 19, 2018 Oh, and in case no one else has tested this - I saw the comment about column 160 with the STIC1A and the possibility that this affects collision detection. I tested this out, and not as far as I can tell. Even though the original STIC doesn't draw at 160, collision detection does in fact work there. I had to look at $0022-0027 to spot the 1A. But you probably already figured that out, if you've looked that closely at my stuff 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted January 19, 2018 Share Posted January 19, 2018 I've corrected the problem counting the cycles for NTSC/PAL, and I'll look into the solution suggested by Joe for the start of IntyBASIC. I would be pretty glad to make it compatible with Tutorvision 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 19, 2018 Share Posted January 19, 2018 From what I've seen, someone could simply code for the Tutorvision and jam the WBEXEC onto the resulting ROM, but it'd still be nice to be able to test against both. FWIW, there's pretty much zero value in appending the WBEXEC to anything other than a game that uses routines in the WBEXEC. If you have an INTV88 SuperPro w/out WBEXEC, you have a strictly more-capable machine than an INTV88 SuperPro w/ WBEXEC. The latter won't work with an ECS, for example. You can always club the extra WBEXEC code onto a TutorVision ROM if that's your thing, but that's just a small number of games that benefit from that. Other than the collector value, having the extra ROM at $2xxx that you can't dismiss is more of a liability than a feature. If you're coding to the "42K" map, you'll have to avoid the $2000 - $2FFF segment entirely if you want it to work on a true TutorVision, and drop back to a "38K" map. Oh, and in case no one else has tested this - I saw the comment about column 160 with the STIC1A and the possibility that this affects collision detection. I tested this out, and not as far as I can tell. Even though the original STIC doesn't draw at 160, collision detection does in fact work there. I had to look at $0022-0027 to spot the 1A. But you probably already figured that out, if you've looked that closely at my stuff I honestly haven't dug that far into what you're doing yet. :-) Location $22 is the only special one in the STIC1A that I know of. As for column 159 (the 160th column, if you count starting at 0), there are three different things that need testing: MOB - MOB collision, in column 159 and beyond. MOB - border collision. Even jzIntv doesn't quite match hardware here for the regular STIC. IIRC, the hardware checks for collisions further to the right than I do. MOB - BACKTAB collision. Previously, there were no BACKTAB pixels in the 160th column. Which collision(s) did you check? I've corrected the problem counting the cycles for NTSC/PAL, and I'll look into the solution suggested by Joe for the start of IntyBASIC. I would be pretty glad to make it compatible with Tutorvision If you have something you'd like me to test, let me know. 1 Quote Link to comment Share on other sites More sharing options...
mr_me Posted January 19, 2018 Share Posted January 19, 2018 (edited) What would happen if there is an identical copy at the same address of the wbexec both on the cartridge and on the mainboard. Would it still work? ... I had to look at $0022-0027 to spot the 1A. But you probably already figured that out, if you've looked that closely at my stuff So what are you doing here to identify the stic? ...MOB - border collision. Even jzIntv doesn't quite match hardware here for the regular STIC. IIRC, the hardware checks for collisions further to the right than I do.... Which pixel [location] does jzintv do right border collision?Edit: {I tried testing with NHL Hockey. Both jzintv and hardware look to have the same border collision on the right side. That's exactly where the border appears; where the 160th pixel would be. With jzintv in tutorvision mode with the border being at the 161st pixel location, border collision still happens at the 160th pixel location where the old border would be. Not sure what a real Tutorvision does.}Okay I tried ML Baseball. Here the right border collision detection looks to be at the 161st pixel location. And it's the same for jzintv, hardware, and jzintv in tutorvision mode. I guess NHL Hockey isn't exactly doing border collision. The 161st pixel location is where the tutorvision border is. So on a real intellivision border collision happens one pixel right of the border. One more time; I tried Star Strike. Here the right border collision detection does appear to be several pixels (maybe three) right of the 161st pixel. Its's hard tell because the object moves a couple of pixels at a time. It's still the same location whether its jzintv or hardware. The object is horizontally stretched, don't know if that has any effect. Edited January 19, 2018 by mr_me Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 19, 2018 Share Posted January 19, 2018 (edited) What would happen if there is an identical copy at the same address of the wbexec both on the cartridge and on the mainboard. Would it still work? I don't think that's safe. The exact voltages the different components drive won't necessarily match, and so you could still be buffer-fighting to a degree. Which pixel [location] does jzintv do right border collision? It's not quite that cut and dried. Let's back up slightly. jzIntv does its MOB-to-MOB collision detection between active MOBs that have their "interact" bit set. A MOB is considered inactive if its X coordinate is 0 or >= 167. Now, these coordinates are relative to the MOB field, and those coordinates start 8 pixels above and to the left of the BACKTAB. So, the rightmost column of the BACKTAB (the one that's blanked on the original STIC) is column 167. So right off the top, you could have MOBs that are not visible on the STIC1, but may visible on the STIC1A. Right now, in jzIntv, a MOB whose X coord is 167 won't interact, and I think may not even be visible, regardless of STIC type. I haven't analyzed what STIC1A does here yet. I'm pretty sure jzIntv's collision detection has some minor inaccuracies still wrt. to the STIC1 and STIC1A around the borders. Edit: {I tried testing with NHL Hockey. Both jzintv and hardware look to have the same border collision on the right side. That's exactly where the border appears; where the 160th pixel would be. With jzintv in tutorvision mode with the border being at the 161st pixel location, border collision still happens at the 160th pixel location where the old border would be. Not sure what a real Tutorvision does.} Okay I tried ML Baseball. Here the right border collision detection looks to be at the 161st pixel location. And it's the same for jzintv, hardware, and jzintv in tutorvision mode. I guess NHL Hockey isn't exactly doing border collision. The 161st pixel location is where the tutorvision border is. So on a real intellivision border collision happens one pixel right of the border. One more time; I tried Star Strike. Here the right border collision detection does appear to be several pixels (maybe three) right of the 161st pixel. Its's hard tell because the object moves a couple of pixels at a time. It's still the same location whether its jzintv or hardware. The object is horizontally stretched, don't know if that has any effect. I'm not sure how much you can really get by eyeballing the games, in particular because the EXEC does a mix of manual software checks and hardware collision detection. The exact X coordinate of the MOB also matters. Eyeballing the game may work if you also have some deeper knowledge of the game implementation, but something tells me you're not looking at a disassembly of the games, or at the exact values in the registers at these times. :-) You'd be better off playing with mob_test from SDK-1600. It has some specially designed MOBs for probing the collision detection behavior. Four of the bitmaps have exactly 1px set, one of the four corners. That lets you tease out the different components that factor into the collision detection (X coordinate vs. which pixels are set.) For example, the top and bottom borders are 1 scanline deep, not 1 pixel deep, but you wouldn't know it if it weren't for specially chosen bitmaps like these. Edited January 19, 2018 by intvnut 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 20, 2018 Author Share Posted January 20, 2018 I've corrected the problem counting the cycles for NTSC/PAL, and I'll look into the solution suggested by Joe for the start of IntyBASIC. I would be pretty glad to make it compatible with Tutorvision So- the fix that Joe suggested has broken the NTSC/PAL detection - it now always thinks it's PAL. Here's my prologue.asm: _MAIN1: MVII #_pal1_vector,R0 ; Points to interrupt vector MVO R0,ISRVEC SWAP R0 MVO R0,ISRVEC+1 EIS MVI _ntsc,R0 CMPI #3,R0 BNE _MAIN1 CLRR R2 _MAIN2: INCR R2 MVI _ntsc,R0 CMPI #4,R0 BNE _MAIN2 ; 596 for PAL in jzintv ; 444 for NTSC in jzintv CMPI #$01DB,R2 ;CMPI #520,R2 MVII #1,R0 BLE _MAIN3 CLRR R0 Hopefully we can figure out this section to work for both things Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 20, 2018 Author Share Posted January 20, 2018 As for column 159 (the 160th column, if you count starting at 0), there are three different things that need testing: MOB - MOB collision, in column 159 and beyond. MOB - border collision. Even jzIntv doesn't quite match hardware here for the regular STIC. IIRC, the hardware checks for collisions further to the right than I do. MOB - BACKTAB collision. Previously, there were no BACKTAB pixels in the 160th column. Which collision(s) did you check? MOB-BACKTAB and MOB-border collisions. I simply drew a vertical line at 160, and slowly moved a pixel-wide MOB towards it. The collision behaviour was exactly the same on all hardware (in jzintv, obviously - might be worth testing this on real hardware). Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 20, 2018 Author Share Posted January 20, 2018 So what are you doing here to identify the stic? Pretty simple stuff: IF PEEK($0022) = 16383 THEN stic_num = 0 'standard STIC IF PEEK($0022) = 16375 THEN stic_num = 1 'STIC1A Joe's right, it's literally that one byte that differs. I had originally looked at a range just in case, but nope. 3 Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 20, 2018 Share Posted January 20, 2018 So- the fix that Joe suggested has broken the NTSC/PAL detection - it now always thinks it's PAL. Here's my prologue.asm: _MAIN1: MVII #_pal1_vector,R0 ; Points to interrupt vector MVO R0,ISRVEC SWAP R0 MVO R0,ISRVEC+1 EIS MVI _ntsc,R0 CMPI #3,R0 BNE _MAIN1 CLRR R2 _MAIN2: INCR R2 MVI _ntsc,R0 CMPI #4,R0 BNE _MAIN2 ; 596 for PAL in jzintv ; 444 for NTSC in jzintv CMPI #$01DB,R2 ;CMPI #520,R2 MVII #1,R0 BLE _MAIN3 CLRR R0 Hopefully we can figure out this section to work for both things Why does your prologue set the PAL/NTSC threshold to $1DB? The stock value is 520. $1DB is 475. Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 20, 2018 Author Share Posted January 20, 2018 Why does your prologue set the PAL/NTSC threshold to $1DB? The stock value is 520. $1DB is 475. Oscar suggested this in another thread. Keep in mind that on this one, I don't actually know what I'm doing http://atariage.com/forums/topic/241446-intybasic-compiler-v129-the-good-things-are-now-better/page-12?do=findComment&comment=3930768 Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 20, 2018 Share Posted January 20, 2018 (edited) 0000 0000 028D 8007 0360 5069 02F0 5069 S---I-i- MVII #$5135,R0 77428 5135 0000 028D 8007 0360 5069 02F0 506B S---I-i- MVO R0,$0100 77436 5135 0000 028D 8007 0360 5069 02F0 506D S---I--- SWAP R0 77447 3551 0000 028D 8007 0360 5069 02F0 506E ----I--- MVO R0,$0101 77453 3551 0000 028D 8007 0360 5069 02F0 5070 ----I--q EIS 77464 3551 0000 028D 8007 0360 5069 02F0 5071 ----I--q MVI $0103,R0 77468 0000 0000 028D 8007 0360 5069 02F0 5073 ----I-iq>> CMPI #$0003,R0 77478 0000 0000 028D 8007 0360 5069 02F1 1004 ----I-iQ PSHR R0 77490 0000 0000 028D 8007 0360 5069 02F2 1005 ----I--- GSWD R0 77499 0000 0000 028D 8007 0360 5069 02F2 1006 ----I--- PSHR R0 77505 0000 0000 028D 8007 0360 5069 02F3 1007 ----I--- PSHR R1 77514 0000 0000 028D 8007 0360 5069 02F4 1008 ----I--- PSHR R2 77523 0000 0000 028D 8007 0360 5069 02F5 1009 ----I--- NOP 77532 0000 0000 028D 8007 0360 5069 02F5 100A ----I-i- PSHR R3 77538 0000 0000 028D 8007 0360 5069 02F6 100B ----I--- PSHR R4 77547 0000 0000 028D 8007 0360 5069 02F7 100C ----I--- PSHR R5 77556 0000 0000 028D 8007 0360 5069 02F8 100D ----I--- MOVR R7,R5 77565 0000 0000 028D 8007 0360 100E 02F8 100E ----I-i- ADDI #$0006,R5 77571 0000 0000 028D 8007 0360 1014 02F8 1010 ----I-i- MVII #$0100,R4 77579 0000 0000 028D 8007 0100 1014 02F8 1012 ----I-i- SDBD 77587 0000 0000 028D 8007 0100 1014 02F8 1013 ----ID-- MVI@ R4,R7 77591 0000 0000 028D 8007 0102 1014 02F8 5135 ----I-i- MVII #$5141,R0 77601 <---- proceed to step 4 5141 0000 028D 8007 0102 1014 02F8 5137 ----I-i- MVO R0,$0100 77609 5141 0000 028D 8007 0102 1014 02F8 5139 ----I--- SWAP R0 77620 4151 0000 028D 8007 0102 1014 02F8 513A ----I--- MVO R0,$0101 77626 4151 0000 028D 8007 0102 1014 02F8 513C ----I--- MVII #$0003,R0 77637 0003 0000 028D 8007 0102 1014 02F8 513E ----I-i- MVO R0,$0103 77645 0003 0000 028D 8007 0102 1014 02F8 5140 ----I--- MOVR R5,R7 77656 0003 0000 028D 8007 0102 1014 02F8 1014 ----I-i- PULR R5 77663 0003 0000 028D 8007 0102 5069 02F7 1015 ----I-i- PULR R4 77675 0003 0000 028D 8007 0360 5069 02F6 1016 ----I-i- PULR R3 77687 0003 0000 028D 8007 0360 5069 02F5 1017 ----I-i- PULR R2 77699 0003 0000 028D 8007 0360 5069 02F4 1018 ----I-i- PULR R1 77711 0003 0000 028D 8007 0360 5069 02F3 1019 ----I-i- PULR R0 77723 0000 0000 028D 8007 0360 5069 02F2 101A ----I-i- RSWD R0 77735 0000 0000 028D 8007 0360 5069 02F2 101B ----I--- PULR R0 77741 0000 0000 028D 8007 0360 5069 02F1 101C ----I-i- PULR R7 77753 0000 0000 028D 8007 0360 5069 02F0 5073 ----I-i- CMPI #$0003,R0 77765 0000 0000 028D 8007 0360 5069 02F0 5075 S---I-i- BNEQ $5069 77773 0000 0000 028D 8007 0360 5069 02F0 5069 S---I-i- MVII #$5135,R0 77782 <--- No, no, redo step 3 5135 0000 028D 8007 0360 5069 02F0 506B S---I-i- MVO R0,$0100 77790 5135 0000 028D 8007 0360 5069 02F0 506D S---I--- SWAP R0 77801 3551 0000 028D 8007 0360 5069 02F0 506E ----I--- MVO R0,$0101 77807 3551 0000 028D 8007 0360 5069 02F0 5070 ----I--- EIS 77818 3551 0000 028D 8007 0360 5069 02F0 5071 ----I--- MVI $0103,R0 77822 0003 0000 028D 8007 0360 5069 02F0 5073 ----I-i- CMPI #$0003,R0 77832 0003 0000 028D 8007 0360 5069 02F0 5075 -C-ZI-i- BNEQ $5069 77840 0003 0000 028D 8007 0360 5069 02F0 5077 -C-ZI-i- CLRR R2 77847 0003 0000 0000 8007 0360 5069 02F0 5078 -C-ZI-i- INCR R2 77853 0003 0000 0001 8007 0360 5069 02F0 5079 -C--I-i- MVI $0103,R0 77859 0003 0000 0001 8007 0360 5069 02F0 507B -C--I-i- CMPI #$0004,R0 77869 ; But hey, let's move on to 4 anyway. 0003 0000 0001 8007 0360 5069 02F0 507D S---I-i- BNEQ $5078 77877 0003 0000 0001 8007 0360 5069 02F0 5078 S---I-i- INCR R2 77886 So, that's where it goes wrong, right there. Part of the issue is the tricky synchronization between the foreground code and the background code. In situations like this, I usually just prefer to flatten foreground and background into one flat thread, since it's easier to reason about and make robust. For example: . MVII #_MAIN1, R0 MVO R0, ISRVEC SWAP R0 MVO R0, ISRVEC+1 EIS DECR PC _MAIN1: DIS MVII #STACK, R6 MVII #_MAIN3, R0 MVO R0, ISRVEC SWAP R0 MVO R0, ISRVEC+1 MVII #-1050, R2 EIS _MAIN2: INCR R2 B _MAIN2 _MAIN3: MVII #STACK, R6 CLRR R0 ADDR R2, R2 ADCR R0 MVO R0, _ntsc MVII #_int_vector, R0 MVO R0, ISRVEC SWAP R0 MVO R0, ISRVEC+1 . That seems to work pretty well in my limited testing just now. Haven't tried it on the INTV88 yet, but I expect it'd work, because each step resets the stack, and so would nullify the double-dispatch. (Oh, and once you add that, you can delete the _pal1_vector/_pal2_vector stuff from intybasic_epilogue.asm) Edited January 20, 2018 by intvnut Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 20, 2018 Share Posted January 20, 2018 MOB-BACKTAB and MOB-border collisions. I simply drew a vertical line at 160, and slowly moved a pixel-wide MOB towards it. The collision behaviour was exactly the same on all hardware (in jzintv, obviously - might be worth testing this on real hardware). jzIntv hasn't implemented anything special for STIC1A there, other than that it unmasks some stuff in the right column. I believe jzIntv will register certain MOB-MOB collisions slightly differently for pixels outside the visible screen on the left and the right, due to the fact I skip one of the masking loops that could influence out-of-screen MOB-MOB collisions on STIC1A. (See STIC_FIX_BORD in stic/stic.c) I would not take jzIntv's behavior as canonical for STIC1A. Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 20, 2018 Author Share Posted January 20, 2018 jzIntv hasn't implemented anything special for STIC1A there, other than that it unmasks some stuff in the right column. I believe jzIntv will register certain MOB-MOB collisions slightly differently for pixels outside the visible screen on the left and the right, due to the fact I skip one of the masking loops that could influence out-of-screen MOB-MOB collisions on STIC1A. (See STIC_FIX_BORD in stic/stic.c) I would not take jzIntv's behavior as canonical for STIC1A. Yeah, I wasn't sure how accurate my testing would be - but I can only work with what I have I wasn't sure if you'd done anything to jzintv itself yet in this regard. Either way, it looks like it's fairly accurate given the testing I've seen so far. Quote Link to comment Share on other sites More sharing options...
mr_me Posted January 20, 2018 Share Posted January 20, 2018 (edited) ... I'm not sure how much you can really get by eyeballing the games, in particular because the EXEC does a mix of manual software checks and hardware collision detection. The exact X coordinate of the MOB also matters. ... Your're right. It's obvious, even to the eye that ML Baseball is not using border collision to keep the players on the field. Even with Star Strike you can see it's also using object coordinates; it's the stretched object that pushes half your ship out of display on the right but not the left. When you mentioned jzintv border collision might be different than original hardware I had to see if I could notice anything. ...something tells me you're not looking at a disassembly of the games, or at the exact values in the registers at these times. :-) That's not going to happen anytime soon, I haven't touched assembly since 1989. Edited January 20, 2018 by mr_me Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 20, 2018 Share Posted January 20, 2018 Pardon my ignorance, what makes a Tutorvision special? What did they extend in the roms? -Thom Quote Link to comment Share on other sites More sharing options...
mr_me Posted January 20, 2018 Share Posted January 20, 2018 Pardon my ignorance, what makes a Tutorvision special? What did they extend in the roms? -Thom They are very rare, four or five are known to exist. The extended rom include graphic characters, and a narrow text writing routine. Tutorvisions have more graphics ram, enough to bitmap the screen. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 20, 2018 Share Posted January 20, 2018 They are very rare, four or five are known to exist. The extended rom include graphic characters, and a narrow text writing routine. Tutorvisions have more graphics ram, enough to bitmap the screen. Oh my... And suddenly, the magnitude of his plan was revealed in a blinding flash, all the devices and stratagems of freewheel's were at last laid bare. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.