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

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

"Michael J. Mahon" <mjmahon@aol.com> wrote in message 
Ac6dnThENIPf3prYnZ2dnUVZ_uWdnZ2d@comcast.com">news:Ac6dnThENIPf3prYnZ2dnUVZ_uWdnZ2d@comcast.com...
> Bryan Parkoff wrote:
>> "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.
>
> No, it means that in a 1MHz Apple II (which they all are at the bus
> level), one-half of every 1 microsecond cycle is made available to the
> processor and the other half is made available to the video scanner.
> Period.
>
> There are no other ways to access memory without interrupting the timing
> of the system.  (DMA shares the half-cycles allocated to the processor.)

Michael,

    Yes, I agree.  Think 70 ns per 1 period out of 14 periods.  Seventy ns X 
7 periods = 488 ns.  It is close 500 ns as half 1 microsecond.  6502 MPU and 
video scanner must respond to be valid on data bus between 200 ns and 450 
ns.

>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.

    Think of increasing from 14 periods to 16 periods can slow 2 MHz and 1 
MHz.  Suppose 14 periods plus long cycle as 16 periods is running 1.020484 
MHz.  If 14 periods is increased to 16 periods, it would run 0.89488625 MHz. 
It is likely that 16 periods is slower than 14 periods which it affects 6502 
MPU instructions to finish longer than 1 MHz and Disk II may have trouble 
finishing reading number of bits from sector by sector.
    Do you think that Apple IIgs have similiar timing?  It has clever design 
than Apple //e's design which 28MHz crystal osc chip is used.  I can't 
imagine if Apple IIgs' timing use 28MHz crystal osc chip to work with 14MHz, 
7MHz, 3.5MHz, 2MHz, and 1MHz.  Maybe, it has extra signal like 2.5MHz for 
65C816 MPU and 3.5" AppleDrive.  It looks like that it switches to use 1 MHz 
and 2.5 MHz from timing.

Bryan Parkoff