Jump to content

samscud

New Members
  • Posts

    1
  • Joined

  • Last visited

samscud's Achievements

Combat Commando

Combat Commando (1/9)

1

Reputation

  1. I realize this is an old thread, but it's still showing up for searches so here's some info... The O2 actually generates the image on the fly, so you can alter registers halfway through a field to have more than 4 sprites + 28 characters simultaneously on the screen. You just have to make sure you have enough time to update and the data. The 8048 in the O2 runs at 1.79Mhz, which is further divided by 5 "states" for a one byte instruction, or 10 "states" for a two-byte instruction. This works out as between 179,000 and 358,000 instructions per second. This seems like a lot, but (for NTSC) when you divide this by 59.94 (field rate), you have at most 5,972 instructions per field or 22.75 instructions per scanline, and 443 instructions during vertical blanking. The 8244 VDC can control several objects and helps reduce to load on the processor. It will output signals for background color, grid color and position, the 4 sprite colors and 28 (4 x 4 quads + 12 individual) characters that are in it's memory. To change info in the 8244 VDC (video display controller), you have to enable it onto the bus (you would do that in vertical blanking); then you have to turn off graphics to update them; you need to copy the new data over to the VDC byte by byte; and finally need to reenable the graphics again. This will take longer than one scanline. To reposition a sprite, you will need to update 3 bytes (assuming you don't change the bitmap) per sprite. The hardware has a special "copy EXTERNAL RAM to VDC" mode, where the following sequence uses 8 instruction cycles per byte copied from RAM to VDC: LOOP: MOVX A,@R0 ;reads from external ram MOVX @R1,A; writes to VDC DEC R0 INC R1 DJNZ R2,LOOP Just copying three bytes takes 24 instruction cycles (longer than a scanline). You could save a few instruction cycles by not using a loop. The following code takes 18 instruction cycles instead of 24 (although it uses 12 bytes of memory instead of 6): MOVX A,@R0 MOVX @R1,A DEC R0 INC R1 MOVX A,@R0 MOVX @R1,A DEC R0 INC R1 MOVX A,@R0 MOVX @R1,A DEC R0 INC R1 To see if a game uses these "mid-screen update tricks", just hold the RESET button down on an actual console. This will halt the 8048 as long as you're holding the button down, and stop any VDC updates. Since the 8244 continues to generate the video signal, you can see what is actually in the VDC memory. If half the on screen objects disappear, you'll know that updates are ocurring. I think the source of your misconception might be because the O2EM emulator caches parts of the screen to speed up screen updates, and this is why some games (Wall Street, Frogger) have problems running correctly.
×
×
  • Create New...