Re: Apple II Simulator

["Michael J. Mahon" <mjmahon@aol.com>]

Bryan Parkoff wrote:
>     I have provided my information to the newsgroups -- "Cycle by Cycle 
> Problem?", but I have thought some ideas in my own.  It would be a little 
> long message when I appreciate what you respond to my idea.  I attempt to 
> develop Apple II Simulator which it runs accuracy than Apple II Emulator. 
> The fact is that I am very interested to study simulator, but I consider to 
> let the project to run in simulator alone, emulator alone, or mixed 
> simulator and emulator alone.
>     I have discussed earlier to record nanoseconds each cycle which it 
> measures the timing to match the fixed frequency.  It is 14,318,180 Hz.  It 
> would be 69.84127871 nsec per cycle.  If you attempt to add 69.84127871 nsec 
> each cycle until it reaches 14,318,180 cycles.  The result should be equal 
> to 1.0000000000 second, but it may be greater than 1.00000175731 second.  It 
> is still the wrong result.  The answer is that I don't support or trust 
> decimal floating because it is only 95% accuracy.  I expect to be 100% 
> accuracy perfection.  It must be exact 14,318,180 Hz before Sleep() may be 
> executed each second.  I have decided not to use decimal floating so I use 
> real integer instead.  I expect that real integer can do perfectly because 
> mesuring nanosecond and/or microsecond is not important to this simulator.

I don't know exactly how to respond to you.  I assume that by "95%
accurate" you mean *slightly* inaccurate, and by "100% accurate" you
mean *exact*.

First, don't keep time in nanoseconds.  Keep time in cycles of the 14MHz
clock.  There is no finer division of time on an Apple II, and all times
are integral numbers of cycles of the master oscillator.

Don't make things more complicated than they are...  ;-)

>     It is an example of 1,020,484.32 Hz for 6502 CPU cycle and long cycle. 
> I can assure that it is not to be exact 1,020,484.32 Hz, but it may be less 
> or more.  How can it be computed?  TV or monitor is supposed to have 910 
> dots per horizontial line, but it is designed to have 912 dots.  Sixty-four 
> cycles times 14 dots to complete 896 dots plus long cycle times 16 dots 
> which it equals to 912 dots per horizontial line.  The formula is (14318180 
> / 14) * (910 / 912) = 1,020,484.32 Hz.  Again, it is still decimal floating 
> so I don't accept inaccurate result.  Extra two cycles during 14M is needed 
> to correct color reference which it affects 1 MHz and 2 MHz.
>     If 14,318,180 cycles have been taken to respond video, it would be 3/4 
> frame or 2/3 frame at 60th frame per second.  It is like this -- 64 cycles 
> times 14 dots times 262 lines times 59 frames = 13,850,368 cycles of 14M and 
> long cycle times 16 dots times 262 lines times 59 frame = 247,328 cycles of 
> 14M.  Total 14,097,696 cycles of 14M is for video 59 frames.  Where is one 
> more frame?  It would be remaining 220,484 cycles of 14M to finish for 60th 
> frame.  It would be 64 times 14 dots time 241 lines times 1 frame = 215,936 
> cycles of 14M and long cycle times 16 dots times 241 lines times 1 frame = 
> 3,856 cycles of 14M.  Total 219,792 cycles is for video 3/4 frame in 60th 
> frame.  It has remaining 692 cycles to go for next 14,318,180 Hz at second 
> second, third second, and so forth.  Do not worry if 60th frame may have 
> almost completed of 1/4 frame to 3/4 frame.
>     I can't sustain 1,020,484.32 Hz for Apple II Emulator because it is 
> almost inaccuracy.  How do you expect that KEGS32 may be accuracy?  Didn't 
> you?
>     I have decided to simulate cycle by cycle sequence until it reaches 
> 14,318,180 Hz because "Understanding the Apple //e manual" claims that cycle 
> by cycle sequence is very accuracy because it always reponds to events each 
> cycle, 2 cycles, 4 cycles, or more.
>     I would respond 6502 CPU event each 14 cycles as 14M until it reaches 65 
> cycles before it respond again 16 cycles as 14M.  It repeats the same over 
> and over accurately.
>     I would start 1st cycle to respond 6502 CPU event while it responds 
> "load and shift bit for picture siginal" before 6502 CPU is suspended for 
> 2rd cycle through 14th cycles.  2nd cycle responds to 7M event by copying 
> previous bit for TEXT40 / HIRES40 while it responds "load and shift bit for 
> picture signal" before 7M is suspended each two cycles.  It does the same 
> for 3.5M color reference, 2M RAM, and 1M video scanner.  It is very 
> difficult and complex for me to explain exactly what I mean, but I am sure 
> what you know my meaing.  I do know what I am doing in my own to develop 
> simulator.
>     It seems conflict that Phase 0 should be high during half cycle of 1M 
> while 1st cycle through 7th cycle of 14M and it should be low during another 
> half cycle of 1M while 8th cycle through 14th cycle of 14M.  It is done on 
> electronic design.  It would be easier if Phase 0 should be executed during 
> half cycle of 1M while 1st cycle of 14M before it is suspended on 2nd cycle 
> through 7 cycle of 14M.  It would do the same on 8th cycle of 14M and 9th 
> cycle through 14 cycles of 14M.  Maybe, I should use boolean to mark true or 
> false.  Phase 0 would set to true on 1st cycle of 14M through 7th cycle of 
> 14M and it would set to false on 8th cycle of 14M through 14th cycle of 14M. 
> I have in my mind to think more.

Yes, you will need to delay the execution of the next 6502 cycle until
the completion of the Phase 1 video cycle.  If you do not, the 6502 will
see the data bus state left by the wrong video cycle.

BTW, there are much easier (computationally) ways of doing this with
exactly the same result, but I assume that you want to do a cycle-by-
cycle simulation...

>     When I start drafting my Apple II Simulator project, you will have an 
> ability to debug video of 14M, 7M of TEXT40 / HIRES40, 3.5M color reference, 
> 2MHz and 1MHz including video scanner and 6502 CPU.  It does include H sync, 
> V sync, color burst, and more.  Debugging mode allows you to choose to debug 
> 6502 CPU at cycle by cycle or instruction by instruction while it outputs 
> some registers including address bus and data bus and more.
>     I have already written 6502 CPU cycle by cycle and it ran well on my 
> Xeon Pentium 550MHz at 2MHz to 4MHz.  I predict that it might run little 
> faster at 4Mhz to 16MHz if you have Pentium IV 2GHz to 4GHz.  I am not 
> interested if Apple II Emulator may run faster at 100MHz, but I feel 
> comfortable to play with Apple II Simulator at 16MHz maximum (maybe faster 
> at later time).
>     Please comment what do you think my ideas to do cycle by cycle sequence 
> until it reaches 14,318,180 Hz to respond all events.  I do not care if 
> someone claims that it would be unnoticeable if it is inaccuracy speed of 
> MHz to manipulate video and general timing.

Well, a real Apple responds to events much faster than once per second,
so this is a pretty coarse time granularity.  Why wouldn't you sync up
the simulated time to real time more often?  Like at the end of every
video frame?

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."