Jump to content
IGNORED

Tutorvision detection ROM


freewheel
 Share

Recommended Posts

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

  • Like 3
Link to comment
Share on other sites

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:

 

post-14113-0-85962300-1516257401.gif

 

 

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 by intvnut
Link to comment
Share on other sites

On SuperPro system #1:

post-14113-0-36549900-1516258241_thumb.jpg

 

On SuperPro system #2:

post-14113-0-84025300-1516258263_thumb.jpg

 

On SuperPro system #3:

post-14113-0-53509800-1516258287_thumb.jpg

 

On SuperPro system #4:

post-14113-0-15585000-1516258303_thumb.jpg

 

My stack of SuperPro systems...

post-14113-0-11509000-1516258335_thumb.jpg

 

As for why System #4 crashes: I suspect there's a bug in this logic on the mainboard:

post-14113-0-75938400-1516258944_thumb.png

 

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.

  • Like 1
Link to comment
Share on other sites

With a one byte change, I was able to make this work on SuperPro #4.

 

post-14113-0-24826200-1516261380_thumb.jpg

 

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

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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).

  • Like 1
Link to comment
Share on other sites

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 :)

  • Like 1
Link to comment
Share on other sites

 

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 8)

 

If you have something you'd like me to test, let me know.

  • Like 1
Link to comment
Share on other sites

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 by mr_me
Link to comment
Share on other sites

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 by intvnut
  • Like 1
Link to comment
Share on other sites

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 8)

 

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 :)

 

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

 

 

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

Link to comment
Share on other sites

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 by intvnut
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

 

 

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.

Link to comment
Share on other sites

...

 

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 by mr_me
Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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. :o

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...