| Posted By
MikeZ
on 2008-10-19
10:26:55
 |  emulator frames
For emulators that advance the state of the simulated machine in discrete units called frames - what is the relationship between a frame of information and the simulated machine's regularly timed irq service interrupts? Thanks.
|
|
Posted By
Csabo
on 2008-10-19
16:44:56
| Re: emulator frames
Here it is as I understand it, sorry if I use the wrong words. The term "frame" in this case is quite accurate, as it refers to one full frame of visual information rendered on the display. The IRQ stars at the top, as the raster is scanning down to the bottom of the picture. When it reaches the bottom, that's one full frame, and then it starts again at the top. On PAL machines 50 frames per second are rendered, on NTSC it's 60.
If you want need a more precise or more technical description, we need someone like TLC or Crown to chime in. 
|
|
Posted By
MikeZ
on 2008-10-19
17:59:51
| Re: emulator frames
Thanks for your help. Yes, I understand that what you said is how a single video frame is painted on the screen.However, between screen frames things are happening. The system clock is running, the PC counter is running, and code(both program code and IRQ service) is being executed. The emulator must make all these calculations and get them ready to present at the next visual screen frame update. Its the processing between screen/visual frames that I am interested in. In particular, I am interested in how the emulator programmer decided what behind- the - scenes processing was required during the interval between one screen frame and the next, and how the timed IRQ fits into that. Any insight would be greatly appreciated.
|
|
Posted By
Litwr
on 2008-10-20
04:03:33
| Re: emulator frames
Exact emulation requires to work with individual CPU and TED cycles -- the frames are too big.
|
|
Posted By
indi
on 2008-10-20
06:41:44
| Re: emulator frames
Even simple emulators will tend to work in scanlines and not frames. On machines like the C64/Plus4 raster splits means things like scrolling changes from line to line so its much easier to process a line and draw it than process a whole frame and remember everything...
Even a speccy emulator will tend to get processed as a scanline since you can do hires colour, or change the border part way down, so same rules apply.
|
|
Posted By
MikeZ
on 2008-10-20
11:31:41
| Re: emulator frames
OK. I think I'm getting it - thanks to all. Just one final question then. If a scanline is the discrete chunk of data that constitutes one "update", what event, count, etc defines the beginning of an update of a screenline and the end of that update. Horizontal raster position, raster interrupt value, timer interrupt value?? Thanks Again.
|
|
Posted By
indi
on 2008-10-20
12:01:18
| Re: emulator frames
In general the number of scanlines.
A (very) simple view on the plus 4 would be....
top border scanline = 114 CPU cycles
a DMA screen line = 20 CPU cycles
a non-DMA screen line= 65 cycles
(these numbers arent right...i've just pulled rough ones out my head).
You then run around 312 scanlines and then start again... C64, Spectrum etc. all have their own numbers and rules per scanline, but are in general the same idea.
However.... for "proper" emulation, its obviously a LOT more complex, and you work in TED cycles which is a fraction of a CPU cycle, and update as you go - or as a screen/register change is made. A lot more work.....
|
|
Posted By
MagerValp
on 2008-10-20
14:36:34
| Re: emulator frames
Here's a little Python inspired pseudo code for a cycle based emulator:
def emulate_machine():
# These objects emulate the various parts of the machine
video = Video()
sound = Sound()
cpu = CPU()
# The frame object contains arrays of pixel data and sound
# samples, and methods to manipulate them
frame = Frame()
# A line contains a line's worth of pixels
line = Line()
while True:
frame.clear()
line_ctr = 0
while line_ctr < LINES_PER_FRAME:
line.clear()
cycle_ctr = 0
while cycle_ctr < CYCLES_PER_LINE:
# Each cycle of video emulation gives us eight
# pixels of graphics data
line.append_8_pixels(video.emulate_cycle())
sound.emulate_cycle()
cpu.emulate_cycle()
cycle_ctr += 1
# We store a full line of graphics in the framebuffer
frame.set_gfx_line(line_ctr, line.get_pixels())
# We sample the oscillators every line
frame.set_audio_sample(line_ctr, sound.get_sample_value())
line_ctr += 1
# Draw a new frame 50 or 60 times per second
frame.wait_vblank()
frame.draw()
# Play the audio samples at 15625 or 15750 Hz
frame.play_audio_buffer()
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
