Bryan Parkoff wrote:
"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 thesoftware stops working. MattMatt,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.
Exactly--the disk software won't work.
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.
The IIgs timing design *apart from the peripheral bus and video memory* is more flexible than other Apple II's, but video memory is the issue. Again, this is *not* a simple modification to the HAL. It is a complete re-design of the Apple II video/bus timing--all for a 6x7 text font in place of the standard 5x7 font. Seems like using a cannon to shoot a mouse... -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."