Create ROMs to determine correct INTIM/TIMINT behaviour

[+stephena]

Deleted, I submitted by mistake.

[+stephena]

Have you posted a "nightly build" with the latest fixes yet? I'm not a C programmer, but if I could look at the latest source code, I might be able to help you figure out what to change and where.

 

Test build is available here: http://minbar.org/St...re1-windows.zip

 

Source code is viewable here: http://stella.svn.sf...551&view=markup, http://stella.svn.sf...551&view=markup

 

For the source code, I added line 168 "if(divByOne != 0 && divByOne != 255)" to fix the issue in the last ROM posted by Omega, but I'm not sure it isn't just a hack. In particular, I see why checking for 255 is required, but not for 0.

 

And the following are all the test ROMs I'm using. Some were provided in this thread, and others provided by you in a thread from 2007!

intim_timint_tests.zip

 

For the test ROMs, the last one (timer_test.bas.bin) is the only one that doesn't completely match Stella with real hardware. In particular, when selecting T1024T, the values for 0 and below give 0 on a real console, and very large numbers in Stella.

[SeaGtGruff]

For the test ROMs, the last one (timer_test.bas.bin) is the only one that doesn't completely match Stella with real hardware. In particular, when selecting T1024T, the values for 0 and below give 0 on a real console, and very large numbers in Stella.

In that case, the program itself may be faulty. I remember someone pointing out there was an issue with T1024T back when I posted the program, but I couldn't figure out what was wrong with it. It may be something very simple (those can be the hardest mistakes to find), or it may be that the timer doesn't behave as expected when using T1024T on a real console. Note that the "very large numbers in Stella" are green, which indicate that they match the expected values. So the real question is, why does a real console show 0 for those values?

[+stephena]

I'd appreciate anyone reading this thread (and who has a Harmony cart) to try the test ROMs on their console and note any discrepancies with Stella. I only have a light-sixer hooked up now, but in the past I've noticed different behaviour from it wrt TIA output compared to other systems. So until I hook up another system and get more feedback, I can't be sure what's going on.

[SeaGtGruff]

I'd appreciate anyone reading this thread (and who has a Harmony cart) to try the test ROMs on their console and note any discrepancies with Stella. I only have a light-sixer hooked up now, but in the past I've noticed different behaviour from it wrt TIA output compared to other systems. So until I hook up another system and get more feedback, I can't be sure what's going on.

I'm going to see if I can create a better test ROM for testing T1024T, in case there's a problem with the way my other test ROM was designed. Of course, even if it were a bug in the program, you'd still want Stella to duplicate the behavior of a real console.

 

I can test on a heavy sixer with a Krokodile Cartridge for sure, and maybe on a 7800 with a Cuttle Cart II.

[+stephena]

I might be able to try on a Junior later today. Until I get more feedback on this, I'm going to assume that all cases where Stella match real hardware are actually valid. I'm going to look at the PA7/D6 stuff next.

[cd-w]

I'm not sure if this is relevant to PAL consoles, but on my PAL Jr the numbers are completely different from Stella:

 

test1: 192246

test2: 64249

test3: 192248

test4: 192245

test5: 192245

 

Chris

[+stephena]

I'm not sure if this is relevant to PAL consoles, but on my PAL Jr the numbers are completely different from Stella:

 

test1: 192246

test2: 64249

test3: 192248

test4: 192245

test5: 192245

 

Chris

 

The lower 3 #'s are for INTIM, and the upper 3 are for a combination of D7 and D6 of the interrupt flag register (Ie, TIMINT). For TIMINT, if D6 is set, the value is 0x40 (ie, 64). And if D7 is set, the value is 0x80 (128). Your values exactly match mine in that the only difference is that D6 is never set (or to put it another way, subtract 64 from the upper 3 digits). That's not surprising, since Stella doesn't emulate that yet Sometimes when I turn on my machine it also shows 192/64, so I suspect D6 is sometimes set on powerup, and sometimes not, probably because of randomness on the address bus.

 

Could you also check the other test ROMs in the ZIP provided earlier in this thread?

[cd-w]

Could you also check the other test ROMs in the ZIP provided earlier in this thread?

 

Sure:

1. testTIMINT_flawed - both BEFORE and AFTER are 0x00.
   
2. testTIMINT_withDelay - both BEFORE and AFTER are 0x00, except when the delay is either 0 and 255 when AFTER is 0x80.
   
3. timer_test - for 1T the values at the bottom are: 00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10
   
4. timer_test - for 8T the values at the bottom are: 00, 01, 09, 17, 25, 33, 41, 42, 43, 44, 45
   
5. timer_test - for 64T the values at the bottom are: 00, 01, 65, 129, 193, 257, 321, 322, 323, 324, 325
   
6. timer_test - for 1024T the screen just turns black and nothing is displayed
   

Chris

 

EDIT: Actually 1024T just takes a while before anything is displayed - the values are: 00, 01, 1025, 2049, 3073, 4097, 00, 00, 00, 00, 00. The last 5 numbers (all 00) are in a different color than normal.

Edited September 16, 2012 by cd-w

[+stephena]

All these values match my console and Stella, except the last 5 results for T1024T; they're also 0 on my console, but something else in Stella. We're still trying to figure out why that is. Any ideas??

[cd-w]

All these values match my console and Stella, except the last 5 results for T1024T; they're also 0 on my console, but something else in Stella. We're still trying to figure out why that is. Any ideas??

Do you have the source for timer_test.bas.bin - I'm not completely sure how the calculation is being performed?

 

Chris

Edited September 16, 2012 by cd-w

[+stephena]

I don't have the source, and didn't even realize who created it until SeaGtGruff indicated above that he originally posted it. Maybe he still has the source?

 

Also, I'm having problems getting both my Junior and 7800 working on my LCD TV, so I can't provide more feedback until I find another TV.

[Omegamatrix]

Sure:

1. testTIMINT_flawed - both BEFORE and AFTER are 0x00.
   
2. testTIMINT_withDelay - both BEFORE and AFTER are 0x00, except when the delay is either 0 and 255 when AFTER is 0x80.
   
3. timer_test - for 1T the values at the bottom are: 00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10
   
4. timer_test - for 8T the values at the bottom are: 00, 01, 09, 17, 25, 33, 41, 42, 43, 44, 45
   
5. timer_test - for 64T the values at the bottom are: 00, 01, 65, 129, 193, 257, 321, 322, 323, 324, 325
   
6. timer_test - for 1024T the screen just turns black and nothing is displayed
   

Chris

 

EDIT: Actually 1024T just takes a while before anything is displayed - the values are: 00, 01, 1025, 2049, 3073, 4097, 00, 00, 00, 00, 00. The last 5 numbers (all 00) are in a different color than normal.

 

I am getting the same results as Chris on real hardware for all the roms he mentions above. 1024T turns to red for the last five numbers, and is zero.

 

The other test roms (test1.bas.bin,etc) are all screwed up on my Jr. I took a peak and I think it's because it's using ASR, which is unstable on my Jr. I've ran into a similar issue before. The other issue could be the timing is a little off, but I didn't check that. My Jr is a late model that has a slightly slower TIA:

 

 

So here is what I saw with Test1.bas.bin. Note the value differed between tests too.

 

[+stephena]

I am getting the same results as Chris on real hardware for all the roms he mentions above. 1024T turns to red for the last five numbers, and is zero.

 

The other test roms (test1.bas.bin,etc) are all screwed up on my Jr. I took a peak and I think it's because it's using ASR, which is unstable on my Jr. I've ran into a similar issue before. The other issue could be the timing is a little off, but I didn't check that. My Jr is a late model that has a slightly slower TIA:

 

I'm going to assume the graphics corruption is the ASR opcode, and ignore this for now.

 

All feedback so far from real consoles is that the last 5 values of T1024T should be zero. Stella doesn't give that, and I'm not sure how to make it do so. Or more to the point, why it does it on a real system.

 

The differences in the first 3 digits in your tests are because sometimes D6 is set for the Interrupt Flag register (IOW, what you get from reading TIMINT). If D6 is set, the numbers will have 64 added to the first 3 digits. D6 is set on active transition of pin 7 (ie, joystick 0, right direction). Sometimes, the 2600 will power on with the right combination of random signals that D6 is triggered, and you'll see 192xxx (or 064xxx) for the above tests. Other times D6 will be off, and you'll see 128xxx/000xxx instead. Stella emulates the latter; to emulate the former I guess some randomness needs to happen on power-up.

[+stephena]

OK, I just added code that emulates the edge-detect circuitry and the resulting association with D6 of Interrupt Flag register. My understanding is as follows:

1. PA7 corresponds to pin 4 of the left joystick; IOW, the right direction
    
   
2. The circuitry detects when PA7 transitions from high->low or low->high; the former is called negative edge-detect, and the latter positive edge-detect
    
   
3. This active edge detection is always enabled, whether PA7 is input or output, and regardless of whether IRQs are enabled or not (on the 2600, the latter is irrelevant)
    
   
4. The type of edge-detection can be changed by writing to the appropriate address
    
   
5. A real console seems to start up with negative edge-detect, but this is possibly where randomness could occur and we get positive instead
    
   
6. When an active transition occurs, D6 is set
    
   
7. When TIMINT is read, D6 is cleared after it has been returned in the read (ie, you see that it was set, but the next read will have it cleared)
   

With that in mind, here's another test release of Stella that emulates the above: http://minbar.org/St...re2-windows.zip

 

Note that in the 'flawed' test ROM, we can now see the digits flickering when pressing right on the joystick.

[Omegamatrix]

The emulation is getting better. However, on my real hardware the 'flawed' test rom will have the 'after' value flickering too, most of the time.

 

 

The flickering on the after value will happen most of the time, but not everytime. Is is the same on other peoples real hardware?

[Omegamatrix]

And with my previous tests with my previous tests with test1.bas.bin, I'm pretty sure the problem is related to ASR in that case too.

[+stephena]

To better emulate the PA7 functionality we really need new test ROMs. The current ones were sufficient to show that something not previously emulated was occurring, but now we need to see exactly what's going on. And a quick flicker isn't going to help much ...

 

As to flicker frequency, for me the before happens every time, and the after is perhaps every 3-4 times. So obviously something else is going on. The current emulation includes everything mentioned wrt PA7 edge-detection from the 6532 technical manual. Beyond that, I can't proceed without more test ROMs or better documentation. But I suspect this will be difficult to track down; none of the other emulators even consider D6/PA7 at all.

[SeaGtGruff]

Sure:

1. testTIMINT_flawed - both BEFORE and AFTER are 0x00.
   
2. testTIMINT_withDelay - both BEFORE and AFTER are 0x00, except when the delay is either 0 and 255 when AFTER is 0x80.
   
3. timer_test - for 1T the values at the bottom are: 00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10
   
4. timer_test - for 8T the values at the bottom are: 00, 01, 09, 17, 25, 33, 41, 42, 43, 44, 45
   
5. timer_test - for 64T the values at the bottom are: 00, 01, 65, 129, 193, 257, 321, 322, 323, 324, 325
   
6. timer_test - for 1024T the screen just turns black and nothing is displayed
   

Chris

 

EDIT: Actually 1024T just takes a while before anything is displayed - the values are: 00, 01, 1025, 2049, 3073, 4097, 00, 00, 00, 00, 00. The last 5 numbers (all 00) are in a different color than normal.

 

timer_test displays the numbers in green if they match the expected values, or red if they don't.

 

The reason the screen goes blank for a bit when choosing T1024T is because the program actually checks to see when the timer changes from one value to another, and for T1024T this takes too much time to do during a vertical blank, so I just turn blanking on and leave it on-- no vertical sync and no active video-- until processing is done.

 

All these values match my console and Stella, except the last 5 results for T1024T; they're also 0 on my console, but something else in Stella. We're still trying to figure out why that is. Any ideas??

 

I haven't figured out the problem yet, but I initialize all of the values to 0 before determining when the timer changes, so my gut feeling is that the program is branching out of the loop when it gets to 00, FF, FE, and so on, such that it never determines when they occur-- but only on a real console, not in Stella. I didn't work on the program this weekend like I'd wanted to, so I'll look at it this week.

 

Do you have the source for timer_test.bas.bin - I'm not completely sure how the calculation is being performed?

 

I'm attaching a slightly updated version of it to this post. The only differences between this version and the original version are that I tweaked the letters a bit to make them look better, I had to change the vertical position of the players 1 line for bB 1.1, and I moved the position of the "align 256" instruction. I haven't tried the new version on a real console yet, and I'm curious if it still gives 0 for the last several numbers.

 

Be warned, the logic can be a bit difficult to follow!

timer_test.bas

timer_test.bas.bin

[+stephena]

Thanks, I'll check it out on a real console when I get home from work later this evening.

[+stephena]

I'm attaching a slightly updated version of it to this post. The only differences between this version and the original version are that I tweaked the letters a bit to make them look better, I had to change the vertical position of the players 1 line for bB 1.1, and I moved the position of the "align 256" instruction. I haven't tried the new version on a real console yet, and I'm curious if it still gives 0 for the last several numbers.

 

Still giving 0 for the last 5 numbers on a real console, and large numbers in Stella.