Re: Apple //e Upgrade to 640x192 Resolution?

["Bryan Parkoff" <nospam@nospam.com>]

"Michael J. Mahon" <mjmahon@aol.com> wrote in message 
gr6dnRYY1uoxcpvYnZ2dnUVZ_tSdnZ2d@comcast.com">news:gr6dnRYY1uoxcpvYnZ2dnUVZ_tSdnZ2d@comcast.com...
> Bryan Parkoff wrote:
>> "Michael J. Mahon" <mjmahon@aol.com> wrote in message 
>> NqCdnaaGcfsb_JvYnZ2dnUVZ_rSdnZ2d@comcast.com">news:NqCdnaaGcfsb_JvYnZ2dnUVZ_rSdnZ2d@comcast.com...
>>
>>>Bryan Parkoff wrote:
>>>
>>>>"mdj" <mdj.mdj@gmail.com> wrote in message 
>>>>1158026927.788778.313390@m73g2000cwd.googlegroups.com">news:1158026927.788778.313390@m73g2000cwd.googlegroups.com...
>>>>
>>>>
>>>>>I doubt anyone is much interested in changing the resolution - all the
>>>>>software stops working.
>>>>>
>>>>>Matt
>>>>
>>>>Matt,
>>>>
>>>>    I am sure that all software will work fine unless HiRes and DHiRes 
>>>> are to be modified.  Nothing is worried to modify any routines.  All 
>>>> software should run fine at 1 MHz.
>>>
>>>How do you propose to shift out 8 bits in 14 cycles of the 14MHz clock,
>>>so that video reads still interleave perfectly with the 1MHz processor
>>>clock?  Do you propose a 16MHz dot clock for text mode, and how would
>>>that be synchronized with the 14MHz master clock?
>>
>>
>> Michael,
>>
>>     Good question.  It would shift out 8 bits in 16 cycles of the 14MHz 
>> clock when LDPS' is extended extra 2 periods.  14MHz crystal osc is 
>> needed to sustain 60 frames vertically per second.  It is important to 
>> stick 14MHz crystal osc chip so 16 periods can be performed each video 
>> cycle.  It is only a way to change the timing equations in the HAL16R8 
>> chip.  I used to duplicate equations from PAL16R8 chip (same as HAL16R8 
>> chip) to GAL16V8 chip.  GAL16V8 chip is useful for reprogrammed 
>> equations.
>>     First of all, timing simulation in my C++ source code would help to 
>> study 16 periods while modifying RAS', AX, CAS', Q3, Phase0, Phase1, 
>> VID7M, and LDPS' to extend extra two periods like long cycle.  If timing 
>> simulation is correct according to my prediction, then equations can be 
>> reprogrammed into GAL16V8 chip.  It needs to modify video scanner to 
>> sustain 57 video cycles instead of 65 video cycles in the IOU chip.
>>     I hope to answer your question.
>
> What you describe would lengthen the active horizontal line by 8/7 and
> will slow down the video memory accesses to 7/8 MHz rather than 1MHz.
> Doing so will cause numerous "ripple" effects to Apple II timing.
>
> As I've said before, the Apple II is a carefully meshed set of gears,
> and you can't change the speed of just one without a complete review
> of system timing.
>
> BTW, I can understand persuing this out of curiosity, but this sounds
> like a lot of trouble just to use a 1-pixel wider non-standard font.
> ;-)
>
> -michael
>
> New, faster SUDOKU v2.0 solver for Apple II's!
> Home page:  http://members.aol.com/MJMahon/
>
> "The wastebasket is our most important design
> tool--and it's seriously underused."

Michael,

    Does it mean that modified timing equation will affect video scanner to 
read data from RAM at 2 MHz?  Is it likely that data from RAM is on databus 
and attempts to be valid two extra periods longer and it is considered to be 
invalid as corrupted or garbage on databus?  Then invalid data from databus 
may be latched to video databus and is sent to the screen which shows wrong 
data as wrong pixels.  It is like corrupted data.

Bryan Parkoff