[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Apple II Simulator
- Subject: Apple II Simulator
- From: "Bryan Parkoff" <none@nospam.net>
- Date: Mon, 02 Jan 2006 01:24:05 GMT
- Newsgroups: comp.sys.apple2
- Organization: SBC http://yahoo.sbc.com
- Xref: g2news1.google.com comp.sys.apple2:2870
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