[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Apple II Simulator



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

Bryan Parkoff