"Bus stuffing" like The Graduate.

[alex_79]

[...] With that arrangement there'd be 2 vertical black lines and 2 brighter overlap lines on the left side if player0 was shifted to the left on the "odd start" line. Since there's only 1 black line that tells me that player0 on the "even start" line is shifted to the right by 1 pixel.

Right. I missed the 2nd overlap line in the screenshot I posted.

I know that 2x and 4x players are positioned 1 to the right, perhaps your Light Sixer and 7800 are doing something similar based on the values in NUSIZx. After work I'll compare the DPC+ and BUS versions to see what the NUSIZx values are when the reposition of player0 for the left side of "even start" occurs.

It makes sense, altough I thought that those kind of differences were caused by different TIA revisions, while in my tests the same TIA that shows the bug in the sixer works fine in the vader and viceversa, so it's something else on the board that causes the shift. The TIA in the 7800 is soldered so I didn't tried swapping that one... yet!

 

[...]the cartridge puts data on the bus at the same time the 6507 does. When it works as expected the values are ANDed together. For any value the results of being ANDed with $FF is that same value. For some reason that's not working on the 7800 - the bit 7 appears to only be getting the value from the 6507, so is always on.

Judging by threads about some projects here on AA and elsewhere (the H2, for example), the 7800 seems to have much more variability across different revisions/batches of consoles causing many compability problems difficult to track down...

 

 

Thanks for your clear and helpful explanation. I find projects like this really interesting.

 

 

[+SpiceWare]

It makes sense, altough I thought that those kind of differences were caused by different TIA revisions, while in my tests the same TIA that shows the bug in the sixer works fine in the vader and viceversa, so it's something else on the board that causes the shift. The TIA in the 7800 is soldered so I didn't tried swapping that one... yet!

It's definitely not the results I would have expected. I'll post a new test once I have time to look over it. Probably not until tomorrow though, my folks are in town running errands (they live in Lake Jackson, about a 40 minute drive south of here) so we'll be heading out for dinner in a bit.

 

Judging by threads about some projects here on AA and elsewhere (the H2, for example), the 7800 seems to have much more variability across different revisions/batches of consoles causing many compability problems difficult to track down...

Oh yeah, during the development of Stay Frosty 2 we had numerous issues with DPC+'s Fast Fetch mode and some 7800s. We were able to figure out trigger conditions so I wrote evil7800, which analyzes the listing created by dasm to spot known issues:

 

evil7800.zip

 

Thanks for your clear and helpful explanation. I find projects like this really interesting.

No problem!

[tschak909]

Sweet jeebus! The 7800 _HAS_ a TIA in it, right? Is it a TIA or is it the VTI clone that was in the ColecoVision expansion module #1? Why the humongous killing fields of variance in the 7800s?

[Omegamatrix]

I ran the rom on a NTSC light sixer and a 4 switch. No problems to report. Also my TV didn't roll (It does with SF2), so it looks promising.

 

 

One thing I realized is that the text is really hard to read on my TV. It looks way better in the photos then actually viewing it. We hear this complaint a lot about the Harmony menu.

 

However, I discovered that the inverted graphics are easier to distinguish (black letters, solid blue background) then the other text. I will remember that if I ever do this routine.

 

 

[cd-w]

It makes sense, altough I thought that those kind of differences were caused by different TIA revisions, while in my tests the same TIA that shows the bug in the sixer works fine in the vader and viceversa, so it's something else on the board that causes the shift. The TIA in the 7800 is soldered so I didn't tried swapping that one... yet!

I suspect some minor difference in the clock between the two consoles. The code requires the TIA and 6507 to be synchronized, and any drift could cause the effects your are seeing. That said, it is strange that the original 32text demo works fine, suggesting that the timings are not too far out ...

 

Chris

[+SpiceWare]

I set up my 7800 during lunch, it doesn't like any of these demos. The parrot comes out like this:


The 128 demo briefly shows an incorrect image before the screen goes black.

The DPC+ 128 demo doesn't work either, and evil7800 didn't spot any issues with it.

[+SpiceWare]

One thing I realized is that the text is really hard to read on my TV. It looks way better in the photos then actually viewing it. We hear this complaint a lot about the Harmony menu.

 

Is that an HDTV? It looks like it's showing ever-other-frame.

[Omegamatrix]

 

Is that an HDTV? It looks like it's showing ever-other-frame.

Yes it is a HDTV. I have no options for "Game Mode" or anything like that.

 

I got this TV after SF2 development. SF2 rolls on it, but Space Rocks does not.

[alex_79]

You might try to manually turn off all the picture-enhancing options, but it seems that the problem is that the TV is applying a deinterlacing filter because it doesn't recognize the non-standard progressive signal from the Atari. Usually there's nothing you can do to fix that, other than using an external upscaler.
If you have a dvd recorder or PVR with analog inputs (composite and/or RF) and hdmi outputs you can try connecting the console to that. If you're lucky it can deal with the progressive signal and you can use it to bypass the TV built-in decoder/upscaler.

[tschak909]

The one upscaler that I've found that works perfectly with vintage game console 240p output is the XRGB mini Framemeister...and it is unbelievably expensive (but its explicit feature set way outweigh its price)

 

-Thom

[+SpiceWare]

We've revamped the cartridge layout. Initially we modeled it after DPC+ where 8K of the cartridge ROM gets copied over into RAM when you first power up:

 

Namely the 3K DPC+ driver, the 4K Display Data, and the 1K Frequency Data. The last is split in half when using C code to make space for the C Variable & Stack storage. If you weren't using DPC+ music you could use that entire 1K for C Variables & Stack.

 

One issue with DPC+ games is I've continually run short on RAM, so we were hoping to increase that.

 

With Stay Frosty 2 we learned we could create the frequency values on the fly, so could eliminate all but 24 bytes of frequency data, giving us 1000 bytes of RAM for C Variables & Stack.

 

Another thing we learned was to use the 4K of Display Data ROM as generic data storage, and to manually copy data into Display Data RAM as it was needed at run time.

 

Things like the DPC+'s random number generator, memory copy, etc. could also be eliminated because BUS is based on the asumption that you'll be using C code and would implement those yourself. That assumption's in place because the 6507 isn't fast enough to prep the amount of data that would be needed by a BUS Stuffing kernel.

 

With that knowledge we pared back the BUS Driver to just 2K! After that we rearranged the ROM usage:

 

Things to note:

• Only 2K of ROM is copied into RAM at power up (the BUS Driver must be in RAM for performance reasons).
• There's now seven 4K banks of ROM that the 6507 can directly access. The 2600 now boots up in bank 6, DPC+ boots up in bank 5
• There's a dedicated 2K ROM for C Code and its data. As with DPC+, the C code expands into bank 0, then 1, etc. as it grows in size
• There's now 2K of RAM for C Variables and Stack

cd-w's finished making changes to the BUS Driver, I'm still working on updates to Stella. One issue I'm having to solve is the new (and improved!) 3 voice audio routines required the use of 32 bit ARM code to access the FIQ shadow registers, while the ARM emulator in Stella only knows how to handle the more compact 16 bit Thumb code which does not even know those shadow registers exist.

[iesposta]

I set up my 7800 during lunch, it doesn't like any of these demos. The parrot comes out like this:

IMG_7565.jpg

 

The 128 demo briefly shows an incorrect image before the screen goes black.

 

The DPC+ 128 demo doesn't work either, and evil7800 didn't spot any issues with it.

IMG_7566.jpg

 

SpiceWare,

I just tried this 128 demo on my 7800.

Very surprised everything works good here, seeing your results with your 7800.

 

Only one thing was a few rolls at the start of the text drawing, (on an LCD), but once the screen fills, all is normal.

The Game mode on this LCD doesn't do that skip every other line deinterlace, and the Harmony menu is all there, but my Projector does that deinterlace skip line.

 

I want the Parrot Demo binary!! (and source!).

Found the bin: http://atariage.com/forums/topic/217629-a-programming-challenge/?p=3581686

I tried getting what is posted here to compile but no parrot.

Both you and Thomas were tweaking code, but nothing final ever posted.

I run the RGB flicker parrot from that thread. That's my fav. What did Andrew call it, Chronocolour™?

http://atariage.com/forums/topic/217629-a-programming-challenge/?p=2851023

Edited October 2, 2016 by iesposta

[+SpiceWare]

Not surprising, there's a lot of variation in 7800s that cause compatibility issues with various things.

Source for the demos will be released when we've finalized BUS, not before then as anything written against an older version will most likely not work in Stella - it's guaranteed that the BUS demos I've posted so far will not work.

As an example of what's changed - look back at the code snippet in reply 23. The BUS registers DS0INC, SETADDRESS, MAPADDRESS and MAPALL no longer exist. Those values must now be set via C code.

Still to do:

• finish rewriting Stella's BUS support
• rewrite the existing demos to work with the current version of the BUS Driver
• write new demos to test all the features, such as the updated audio functionality
• try to make it compatible with evil 7800s. We've had some input on this from batari on what he had to do in DPC+ for this.

And yes, I plan to do a demo using chronocolour:

Red


Green


Blue

[iesposta]

Not surprising, there's a lot of variation in 7800s that cause compatibility issues with various things.

 

Source for the demos will be released when we've finalized BUS, not before then as anything written against an older version will most likely not work in Stella - it's guaranteed that the BUS demos I've posted so far will not work.

 

As an example of what's changed - look back at the code snippet in reply 23. The BUS registers DS0INC, SETADDRESS, MAPADDRESS and MAPALL no longer exist. Those values must now be set via C code.

 

Still to do:

• finish rewriting Stella's BUS support
• rewrite the existing demos to work with the current version of the BUS Driver
• write new demos to test all the features, such as the updated audio functionality
• try to make it compatible with evil 7800s. We've had some input on this from batari on what he had to do in DPC+ for this.

And yes, I plan to do a demo]

It's a blue car, green grass!

[+SpiceWare]

Wow - that comes across better than I would have expected, you can even make out the orange turn signal and side blinker (just behind the front wheel).

 

[+SpiceWare]

Using Cortex Camera to take a photo of the animated gif:

 

I would have thought the stop sign would have shown up better.

[iesposta]

Wow - that comes across better than I would have expected, you can even make out the orange turn signal and side blinker (just behind the front wheel).

I noticed the blinker and the turn signal also.

 

That's just a 60fps gif and not the Atari 2600 interlaced ChronocolourTM, or Atari 2600 Bus kernel, just to let everybody know.

 

This is a 48 pixel example of the ChronocolourTM technique: http://atariage.com/forums/topic/243378-dpc-zaxxon-hd-demo/?p=3336559

Edited September 21, 2016 by iesposta

[+SpiceWare]

That's just a 60fps gif and not the Atari 2600 interlaced ChronocolourTM, or Atari 2600 Bus kernel, just to let everybody know.

 

Yeah, I expect the 128 pixel chronocolour image to be a painful flickery mess on the 2600 as the monochrome 128x200 image is already at 30 Hz flicker. I'm hoping it looks OK from across the room.

[+SpiceWare]

I've ported the demo to the current Bus Driver and added the Chronocolour 128 demo after the original demos, hit Fire to advance through them.

128bus_20161005.bin

 

The Chronocolour 128 is quite flickery, with very subtle color. Left Difficulty = A for PAL60, B for NTSC.

 

Cranking up the color on the monitor helps, though it makes the flicker even worse. If you have a pair of polarized sunglasses, put them on - it'll help reduce the flicker.

 

On a Light Sixer, the second 8 pixel wide column of graphics is shifted 1 pixel to the left. This glitch is present on all the 4 screens.

The Chronocolour demo uses the DPC+ player arrangement, so it might work OK on your Light Sixer. We've received some input from batari on what we need to do for the evil 7800s, but it's not yet in place.

[+SpiceWare]

The Chronocolour demo uses the DPC+ player arrangement, so it might work OK on your Light Sixer. We've received some input from batari on what we need to do for the evil 7800s, but it's not yet in place.

 

 

Correction - Chris says the layout isn't exactly the same, but real close. It is different than the layout used in the other demos though, so there's still a chance your Light Sixer will be OK with it.

[alex_79]

Thanks for the update!

Unfortunately, with my L6 the glitch is present in the chronocolour screen as well.

 

I will try it on the other consoles and report back.

Edited October 6, 2016 by alex_79

[+SpiceWare]

That's a bummer

 

Hmm - wonder if changing HMP0 would help, it's currently set to $B0 for the entire kernel, maybe $C0 or $A0 on those scanlines that are shifted would make it display correctly on your system. I'll review the code this evening to see if I can change it (it'll have to happen on every scanline).

 

How bad's the flicker on a PAL display? I recall reading that the phosphors used have a longer persistence than those used in NTSC sets, so flicker may not be as bad as over here.

[+SpiceWare]

I was able to recreate your image if I used $A0. Using $C0 results in the opposite - 2 gaps and 1 overlap:

 

So in theory, your Light Sixer needs $C0. Set Right Difficulty A for $C0, B for the original $B0. Only the chronocolour demo was changed for this test.

128bus_20161006.bin

 

Hopefully that works. If so, I think I can write an auto-detect routine by positioning the ball just right so it'll collide with player0 on one system, but not the other.

[alex_79]

How bad's the flicker on a PAL display? I recall reading that the phosphors used have a longer persistence than those used in NTSC sets, so flicker may not be as bad as over here.

Flcker is quite heavy. The TV I'm using is multistandard CRT that also support 60Hz (when it receives a 60Hz signals it also adjust the aspect ratio by stretching the image in the vertical direction), so I guess the phosphors are no different than those used in NTSC sets.

When looking at the road and driveway in the picture, which should come up almost white, I can clearly see the RGB triplet stripes moving up. I have to back away from the screen to make the colors more recognizable. I guess it would look better on smaller TV. Mine is 32" 16/9, which corresponds to about 26" when in 4/3 mode (pillarbox).

 

So in theory, your Light Sixer needs $C0. Set Right Difficulty A for $C0, B for the original $B0. Only the chronocolour demo was changed for this test.

Yes, it displays correctly with right diff in 'A' position on my sixer!

 

[+SpiceWare]

Flcker is quite heavy. The TV I'm using is multistandard CRT that also support 60Hz (when it receives a 60Hz signals it also adjust the aspect ratio by stretching the image in the vertical direction), so I guess the phosphors are no different than those used in NTSC sets.

When looking at the road and driveway in the picture, which should come up almost white, I can clearly see the RGB triplet stripes moving up. I have to back away from the screen to make the colors more recognizable. I guess it would look better on smaller TV. Mine is 32" 16/9, which corresponds to about 26" when in 4/3 mode (pillarbox).

Ah well, was just curious. While interesting as a tech demo, especially when you can take a photo to eliminate the flicker, I don't think 128 Chronocolour will be useful unless the framerate could be increased. My C= 1084 can handle a variety of framerates if it could handle down to 131p then the flicker would be exactly the same as Andrew Davie's Chronocolour examples...

 

Yes, it displays correctly with right diff in 'A' position on my sixer!

Awesome!

 

The bit of code causing the discrepency is this:

 

       sta HMOVE                   ; [70] + 3      > 72 < 75    LEFT 8
       sta RESP0                   ; [73] + 3

---

Per the Stella Programmer's Guide:

 

for mysterious internal hardware considerations, the motion registers should not be modified for at least 24 machine cycles after an HMOVE command

I would expect that same consideration to be taken to not strobe the RESxx registers during that time, but for this layout trick to work we must to strobe RESP0 3 cycles after the HMOVE. Setting the motion register for the missiles/ball during that time is how the starfield effect is created, from Stay Frosty:

	sta HMOVE     ;  3
	SLEEP 16      ; 16 19
	dex           ;  2 21
	stx HMM1      ;  3 24 ; this confuses the TIA and generates stars :-)

---

We already know that different revisions of TIA create different starfields:

 

 

 

 

so I'm not surprised that player0's position could be different.

 

 

 

I'll work on auto-detect this weekend, and see if I can't shoehorn in updating HMP0 in the kernel used by the other demos. For that kernel all 16 datastreams are already in use, so I'll need 6 cycles per scanline (for the load from RAM/store to HMP0).

 

For the chronocolour demo I could use a datastream, so was able to use bus stuffing and thus only needed 3 cycles per scanline. The data layout for chronocolour is convoluted though, so is very slow to update. For the earlier demos the bitmap data is laid out in memory like this:

 

Bitmap_0:     ds 200    ; display data for columns 00 & 01    
Bitmap_1:     ds 200    ; display data for columns 02 & 03   
Bitmap_2:     ds 200    ; display data for columns 04 & 05
Bitmap_3:     ds 200    ; display data for columns 06 & 07
Bitmap_4:     ds 200    ; display data for columns 08 & 09    
Bitmap_5:     ds 200    ; display data for columns 10 & 11
Bitmap_6:     ds 200    ; display data for columns 12 & 13    
Bitmap_7:     ds 200    ; display data for columns 14 & 15
Bitmap_8:     ds 200    ; display data for columns 16 & 17
Bitmap_9:     ds 200    ; display data for columns 18 & 19
Bitmap_A:     ds 200    ; display data for columns 20 & 21
Bitmap_B:     ds 200    ; display data for columns 22 & 23  
Bitmap_C:     ds 200    ; display data for columns 24 & 25
Bitmap_D:     ds 200    ; display data for columns 26 & 27
Bitmap_E:     ds 200    ; display data for columns 28 & 29
Bitmap_F:     ds 200    ; display data for columns 30 & 31

So the first 8 pixels in every row are in Bitmap_0, second 8 pixels in Bitmap_1, etc. Very logical, very easy to plot pixels, but uses all 16 datastreams.

 

In order to free up a datastream for the colors player0 and player1 share a single datastream in the Chronocolour example, so the order of the data is the order in which the players get updated. The layout's like this:

 

  ;         0123456789abcdef
  ; Even: H-0-0-1-101--0---0
  ; Odd:  _H_0_0_1___10_010_

---

So the order of the data stored in memory on even frames is: 0427689bf135acbe ^*

 

while the order for odd frames is: 135acbe0427689bf

 

 

^* you might have expected that to start as 024, not 042, but for timing player0 and player1 are both updated at the start of the scanline before anything's visible.