It is currently Sun Jun 16, 2019 3:40 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Tue Jun 14, 2016 2:57 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8379
Location: Seattle
That's confusing. When I generate the same pattern and load it into sms_ntsc, I get this:
Attachment:
onehalf.filtered.png
onehalf.filtered.png [ 1.4 KiB | Viewed 3800 times ]


It really shouldn't be doing the flickering red and blue thing.


Top
 Profile  
 
PostPosted: Tue Jun 14, 2016 3:07 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
Great Hierophant wrote:
Please don't rely on the second video to give an accurate visual of what the effect looks like, my video does in 60p :

https://youtu.be/Fyl1n70tmcM

That is a reasonable representation of what the eye will see on a Genesis in SMS mode with an NTSC CRT. I apologize for the lack of sound, the handheld camera and the one-handed playing. When you scroll the screen, if your eyes are sharp enough you can see the alternating lines a bit. The total effect appears like a wall of rolling cylinders, one level rolling left, the next level rolling right and the third rolling left and so on.

Wow, yes. I haven't seen that since my childhood. :) SMS Shinobi was my favourite game for a long while.


Top
 Profile  
 
PostPosted: Tue Jun 14, 2016 3:56 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 739
Does anyone have a download source for the most recent version of the binary sms_ntsc plug-in? The ones I could find are from 2008-2009 or require compiling.

lidnariq wrote:
That's confusing. When I generate the same pattern and load it into sms_ntsc, I get this:
Attachment:
onehalf.filtered.png


It really shouldn't be doing the flickering red and blue thing.


That looks much closer to the CRT than anything else I have seen. Oddly enough the lines are really hard to distinguish when the image is stationary but are much thinner when you are moving and looking intently at the screen.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Tue Jun 14, 2016 5:36 pm 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
tepples wrote:
CoCo's video chip is an MC6847 Video Display Generator, whose datasheet indeed specifies half a color burst period per pixel. At that, rate, the scanline can reasonably be 454, 455 (standard), or 456 dots long. It turns out, according to note 6 on page 7, that the MC6847's scanline is of the standard length, 455 dots or 227.5 color burst periods, which causes the color burst phase to be opposite from one scanline to the next. Thus artifact colors would appear slightly harder to exploit than they would be on a 228-period video circuit like that of an Apple II or a 7800: you have to make checkerboards rather than vertical lines.

I think you got that wrong. The artifacting colors (blue/orange) remain solid/fixed on the CoCo systems. But you never know what state you'll be in on power up, so games as the user to "reset" the system until the "right" colors appear (or some other matching system).

It doesn't change per scanline:
Image

_________________
__________________________
http://pcedev.wordpress.com


Top
 Profile  
 
PostPosted: Tue Jun 14, 2016 6:29 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 739
Tepples is not wrong about the datasheet, it clearly says 227.5. I agree that if you hooked up a CoCo 1 & 2 game to a B&W monitor, you would see straight vertical lines, not checkerboard. I would suggest that Tandy's implementation works by lengthening the number of pixels somehow to an even 228.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Tue Jun 14, 2016 6:33 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21439
Location: NE Indiana, USA (NTSC)
Even though it's from a CoCo, that screenshot looks so Apple II-like it isn't funny.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Jun 14, 2016 6:45 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8379
Location: Seattle
Wikipedia's article about the CoCo says that
Quote:
Unfortunately the VDG internally can power up on either the rising or falling edge of the clock, so the bit patterns that represent orange and blue are not predictable. Most CoCo games would start up with a title screen and invited the user to press the reset button until the colors were correct. The CoCo 3 fixed the clock-edge problem so it was always the same; a user would hold the F1 key during reset to choose the other color set.


Unfortunately, I'm not altogether clear what they mean by that. Having found the schematic, the color/pixel clock ("VCK") is generated by the MC6883 ("SAM") and goes through a slight lowpass (first order, 6MHz) before feeding the MC6847.

The datasheet for the bus arbiter ("SAM") has the following note:
Quote:
In order for the VDG and MPU to share the same dynamic RAM [...] the VDG clock must be stopped until the VDG data fetch and MPU data fetch are synchronized [...] Once synchronized, the VDG clock resumes its [master clock÷4] rate and is not stopped again unless an extreme temperature change [occurs]. When stopped, the VDG remains stopped for no more than 32 OscOut cycles
(boldface original) ... so I don't think there's any such scanline stretching going on.

[edit] Wait, the output of the MC6847 is still component (Y ΦA=V ΦB=U); it doesn't become QAM until it is processed by the next IC (the MC1372). Somehow that's got to be what's doing this.

Internally, the MC1372 looks like it just rapidly multiplexes between (A-ref), (B-ref), (ref-A), and (ref-B). I really don't see how this would cause the observed behavior.


Top
 Profile  
 
PostPosted: Tue Jun 14, 2016 7:57 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 739
tepples wrote:
Even though it's from a CoCo, that screenshot looks so Apple II-like it isn't funny.


For this particular example, the CoCo graphics are almost too exact in terms of likeness compared to the Apple II :

Image

As you can see, neither machine has offset graphics :

Attachment:
Ddpg2_000000000.png
Ddpg2_000000000.png [ 7.67 KiB | Viewed 3733 times ]


Attachment:
Clipboard01.png
Clipboard01.png [ 7.55 KiB | Viewed 3733 times ]

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Mon Jul 04, 2016 7:37 am 
Offline

Joined: Sat Jun 16, 2007 11:55 pm
Posts: 81
Great Hierophant wrote:
That is a reasonable representation of what the eye will see on a Genesis in SMS mode with an NTSC CRT.


Do SMS games look different on an actual SMS?

I've never owned one, so I've only played them through Genesis (Model 1) and emulation.


Top
 Profile  
 
PostPosted: Mon Jul 04, 2016 9:33 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 739
Asaki wrote:
Great Hierophant wrote:
That is a reasonable representation of what the eye will see on a Genesis in SMS mode with an NTSC CRT.


Do SMS games look different on an actual SMS?

I've never owned one, so I've only played them through Genesis (Model 1) and emulation.


Ditto, but I seriously doubt it. I cannot seem to find any Youtube videos of the game as played on a real SMS, but this TV commercial for the game seems to support the idea that it does : https://www.youtube.com/watch?v=n-N2fjSrouI

Does anyone have a recent blargg ntsc filter for Kega Fusion? The only ones I have been able to find are five to six years old and fail miserably to reproduce this effect.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Mon Jul 04, 2016 3:08 pm 
Offline

Joined: Sat Jun 16, 2007 11:55 pm
Posts: 81
Two-player Double Dragon!? I can't wait!


Top
 Profile  
 
PostPosted: Mon Jul 04, 2016 3:46 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
Asaki wrote:
Two-player Double Dragon!? I can't wait!

The NES version should really have been called Single Dragon.


Top
 Profile  
 
PostPosted: Mon Jul 04, 2016 8:29 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 739
rainwarrior wrote:
Asaki wrote:
Two-player Double Dragon!? I can't wait!

The NES version should really have been called Single Dragon.


It did technically have two player, but its two player modes are :roll:

I know this is getting a bit off topic now, but here is a stumper. The C64 has a low resolution 160x200 and high resolution 320x200 mode. But all the available evidence suggests that it does not show composite artifact colors. By comparison, the IBM CGA uses the same resolution and the Apple II is pretty close. Consider this dungeon walls on screenshot of what the C64 would display (according to WinVICE) on an NTSC color monitor :

Image

On an IBM PC with CGA, the walls will look something like this :

Image

And on an Apple II, they will look like this :

Image

An Atari 8-bit machine will show walls with brown and blue colors, although this varies on the model of the machine.

The only reason why I can tell that the C64 does not show artifact color is because it is using a 8.18MHz dot clock whereas the other systems are using a 7.16MHz dot clock : http://dustlayer.com/c64-architecture/2 ... your-clock

8.18MHz is not an even multiple of the 3.58MHz color burst, so you don't have the half-clock which makes for the ideal artifact color.


Attachments:
847061-ultima-iv-quest-of-the-avatar-commodore-64-screenshot-dungeon.png
847061-ultima-iv-quest-of-the-avatar-commodore-64-screenshot-dungeon.png [ 3.15 KiB | Viewed 3615 times ]
236405-ultima-iv-quest-of-the-avatar-apple-ii-screenshot-dungeon.png
236405-ultima-iv-quest-of-the-avatar-apple-ii-screenshot-dungeon.png [ 29.92 KiB | Viewed 3615 times ]
142941-exodus-ultima-iii-dos-screenshot-dungeon-crawling-cga-with.png
142941-exodus-ultima-iii-dos-screenshot-dungeon-crawling-cga-with.png [ 61.52 KiB | Viewed 3615 times ]

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog
Top
 Profile  
 
PostPosted: Mon Jul 04, 2016 9:10 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8379
Location: Seattle
Great Hierophant wrote:
I know this is getting a bit off topic now, but here is a stumper. The C64 has a low resolution 160x200 and high resolution 320x200 mode. But all the available evidence suggests that it does not show composite artifact colors.
[...]
The only reason why I can tell that the C64 does not show artifact color is because it is using a 8.18MHz dot clock whereas the other systems are using a 7.16MHz dot clock
The C64 and VIC-20 were designed to generate a completely compliant NTSC signal (other than 240p vs 480i - although on the NTSC VIC-20 there's even a control to use proper interlaced timing), 227.5 color periods per scanline, proper phase reversal from scanline to scanline, &c.

The VIC-20 (because I looked it up more recently) uses a 4 ¹/₁₁ MHz master pixel clock, with exactly 260 pixel periods per scanline. (The C64 would thus have exactly 520 pixel periods per scanline). The visible portion or the scanline (75%) corresponds to ≈96 low-resolution VIC-20 pixels; ≈192 high-resolution VIC-20 pixels/low-resolution C64 pixels, or ≈392 high-resolution C64 pixels.

The real question to me is what is the CoCo doing wrong such that artifact colors work. But short of ever getting an oscilloscope into one, I'm not certain I'll find a technical explanation I'm satisfied with.


Top
 Profile  
 
PostPosted: Tue Jul 05, 2016 6:30 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 739
lidnariq wrote:
The C64 and VIC-20 were designed to generate a completely compliant NTSC signal (other than 240p vs 480i - although on the NTSC VIC-20 there's even a control to use proper interlaced timing), 227.5 color periods per scanline, proper phase reversal from scanline to scanline, &c.


Isn't "proper phase reversal from scanline to scanline" a PAL (Phase Alternating Line) feature? If not part of NTSC, this suggests that the feature is useful in cancelling out color errors like artifact color even with NTSC.

lidnariq wrote:
The VIC-20 (because I looked it up more recently) uses a 4 ¹/₁₁ MHz master pixel clock, with exactly 260 pixel periods per scanline. (The C64 would thus have exactly 520 pixel periods per scanline). The visible portion or the scanline (75%) corresponds to ≈96 low-resolution VIC-20 pixels; ≈192 high-resolution VIC-20 pixels/low-resolution C64 pixels, or ≈392 high-resolution C64 pixels.

The real question to me is what is the CoCo doing wrong such that artifact colors work. But short of ever getting an oscilloscope into one, I'm not certain I'll find a technical explanation I'm satisfied with.


Apparently they did not do enough right with composite color because you cannot guarantee which pattern of colors will be generated when you boot the system. Atari did not do so hot here either, almost every system in the line shows different colors. I guess that Origin forgot that the C64 does not support artifact color, so their stripey walls would still look rather stripey and colorless on a TV. They could easily have used solid colors.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group