This is one of the most interesting posts that I've read in quite a while.
Very interesting practical information. My first thought after reading this
was to wonder if I could develop a circuit that could serve as a buffer to
collect the Sega vectors as they arrive and send them out to a wg6100
monitor with the waits between them. The buffer would only have to be deep
enough to hold one frame. My second thought was to wonder if the Sega rom
code could be hacked to add the wait states into the program itself. If it
really draws the whole frame and then does nothing (I seriously think that
the cpu runs off and does other tasks during this period), then maybe a
simple hack could make it work like this "draw vector, wait, draw, wait,
draw, wait,etc.". I've never read a line of the code but I had to wonder if
such a hack could be implemented. It would certainly be easier to burn new
roms than to add some sort of complex hardware vector buffer.
William Boucher
----- Original Message -----
From: "Zonn" <mlists@zonn.com>
To: <vectorlist@vectorlist.org>
Sent: Wednesday, July 15, 2009 9:46 PM
Subject: Re: VECTOR: SEGA to Amplifone converter
> Clay Cowgill wrote:
>>> I found David Shuman's info on building a converter to run SEGA vector
>>> games on Atari XY monitors, including a caveat that it can't seem to
>>> keep up when there are a lot of vectors to draw.
>>>
>>
>> That more or less mirrors my experience. It was fine for testing and
>> tinkering, but I probably wouldn't want to use it as a final solution.
>>
>>
>>> David postulates that it's a bandwidth problem with the amplifiers.
>>> Could the cause be the slew rate of the WG6100? Since the Amplifone is
>>> faster, perhaps the converter would work 100% when using an Amplifone?
>>> Anyone have any experience running this setup?
>>>
>>
>> I really don't remember what I did when I used my Wg6100 on the
>> SegaMultigame prototyping. I probably had something very similar to
>> David's
>> circuit if it wasn't the actual one he posted. (The timing is quite
>> suspicious since that's about when I was working on the Sega Multigame,
>> so I
>> probably saw his post and tried it.)
>>
>> As I mentioned before in another thread, probably 98% of things looked
>> fine,
>> but that 2% resulted in visible tearing. I mostly noticed it when there
>> was
>> a large delta between points (not necessarily just when there was "lots"
>> to
>> draw). I'd wager a guess that that was the fallout from GO8 being able
>> to
>> reposition the beam faster than the WG6100 could. (In the Atari AVG's
>> you
>> generally don't ever jump the beam more than half a screen width at a
>> time,
>> so the SegaXY vector generator doing that probably exceeds the WG6100's
>> design spec.)
>>
>> At the time I remember thinking that if you could essentially add a
>> hardware
>> wait state in the G-80 system vector generator when there's a long beam
>> jump
>> that it'd probably work 100%, but at the expense of a slight framerate
>> hit
>> possibly. If I ever explored that further I don't remember what became
>> of
>> it now. ;-)
>>
>> Zonn will probably know off the top of his head, but I don't think it
>> would
>> be any sort of bandwidth problem. I suspect it's just slew rate limited
>> with the WG6100's lower deflection voltages. It would be interesting to
>> find out if the WG6400 could keep up though.
>>
>
> Off the top of my head... Clay is correct. :-)
>
> The issue is vector drawing speed of the WG6101. The speed a vector can
> be drawn is dependent upon the voltage available and the inductance of the
> yoke. The bandwidth of the drive electronics, on both monitors, is way
> beyond being an issue.
>
> The WG6101 has a higher inductance yoke than the G08, and uses a +/-25V
> supply, it ends up being one of the slower vector monitors.
>
> The G08 has a fairly low inductance yoke and a high voltage supply of
> +/-50V (and also runs very hot, and originally shipped with underrated
> resistors that could catch fire). The G08 is pushing some design limits,
> especially the safe operation area of it transistors and the ability to
> keep them cool, hence the "wind tunnel heatsink". The G08's inductor is
> small enough that even running it at a lower voltage, it would still be
> fast enough to run any vector game built. Someone posted at one time
> (John Robertson maybe?) that they always set the voltage jumpers on the
> main transformer to the 130V settings (or whatever the highest setting is
> without jumping up to 200V range), that's really a good idea since since
> it's operating so close to it's limits, a 10% reduction in voltage would
> be really helpful.
>
> The thing about the Sega games is that the vector generator is not that
> fast (about the same as Asteriods), however it jumps very quickly between
> vectors, and that's the problem. Even though the WG6101 could easily
> handle the vector drawing speed, the Sega games don't wait long enough,
> when jumping between vectors, for the WG6101 to make it to the start of
> the next vector.
>
> The frame rate for the Sega games is 40Hz, and the games don't use most of
> this time, they quickly draw the frame and then wait a the next 40Hz tick.
> If a wait state could be added between vector jumps it should work just
> fine and not have any affect on the game's frame rate, since there is a
> lot of idle time at end of a frame draw. This is why the ZVG can run Sega
> games at a full 40Hz on a WG6101, it just adds wait states between vector
> jumps, with plenty of time left at the end of the current frame and the
> start of the next.
>
> -Zonn
> ---------------------------------------------------------------------------
> ** Unsubscribe, subscribe, or view the archives at
> http://www.vectorlist.org
> ** Please direct other questions, comments, or problems to
> chris@westnet.com
---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Thu Jul 16 20:10:16 2009
This archive was generated by hypermail 2.1.8 : Fri Jul 17 2009 - 01:50:01 EDT