At 10:00 pm +0100 24/9/99, Si Owen wrote: >Mnemo demo 2, part 2 (http://www.obobo.demon.co.uk/mnemo2p2.jpg). Scroller >lined up ok, but the right hand edge has a strange stretching effect for the >edge of the character (and 'o' in this case) that's appearing.
Hard to tell from that picture, but I think the scrolly is still too far to the left (by either 8 or 16 pixels). The "stretching" effect is just the right hand side of the scrolly -- because I had assumed a TV doesn't display further right, that's where I stop caring about the scrolly. It stretches because I don't bother reseting the colour, why would I need to when it isn't displayed :) So... that scrolly was written on the assumption that the left border is no bigger than 24 pixels wide, and the right border is no bigger than 16 pixels wide. (in other words, if you're displaying 32 pixels of border, then you should start seeing artefacts on the left if the scrolly is positioned correctly). >Mnemo demo 2, part 3 (http://www.obobo.demon.co.uk/mnemo2p3.jpg). Bars in >bottom border jump left and right by 1 to 2 blocks worth, and the >misalignment give additional lines that should probably be aligned with the >bars (?). Yes, it all should be aligned vertically. >E-Tunes demo (http://www.obobo.demon.co.uk/e-tunes.jpg). VMPR switched >scroller now visible, tho the start position is slightly to the right and >it's also a couple of blocks too short. And it should be neat at the sides too, rather than displacements every second line. >The current SimCoupe doesn't seem to show enough of the border areas (mainly >top and bottom) to show all of the border effects, so it might be worth >having windowed modes show more of them (possibly optionally). 'ESI' in >Lyra 3 does look rather like 'FST' :-) I reckon there should be something like 40 pixels at the top and bottom, but less at the sides than you've already got.... In my menu for FRED issue 65, there's an effect underneath the border scrolly which goes to just about the bottom of my old TV display, if that helps. >> Summary: >> OUT (n),a OUT (c),a IN a,(n) IN a,(c) >> VMPR 16 * 20 ** 16 * 20 ** > >Those values fit the case when the scan position isn't 8 t-state aligned, >since the extra 4 t-states is being added to both (of course, there's no 8 >t-state rounding to consider in your tests). If you put a NOP before the >other instructions I'd expect you to get the same timing result, as the NOP >will add 4 t-states but there won't be an additional 4 t-states to add for >the alignment - would you please be able to try it? LD a,254 : OUT (VMPR),a = 24 * uts total LD a,254 : NOP : OUT (VMPR),a = 24 uts total LD a,254 : NOP : NOP : OUT (VMPR),a = 32 * uts total (LD a,254 should account for 8 uts) LD bc,VMPR : LD a,254 : OUT (C),a = 40 ** uts total LD bc,VMPR : LD a,254 : NOP : OUT (C),a = 40 * uts total LD bc, VMPR : LD a,254 : NOP : NOP : OUT (C),a = 48 ** uts total (LD bc,VMPR : LD a,254 should account for 20 uts) Yes, it does look like an 8 tstate rounding thing going on. >I'm also starting to wonder about instructions lying across the boundaries >where memory contention is introduced, as the subtle timings might make a >difference, and that'd be difficult to implement. Another sub-instruction >thing I've wondered about is whether I need to worry about which part of the >instruction actually does the OUT that'll affect the video e.g. does it >occur before the end of an OUTI? and if so, could it make a 1 block >difference in some cases? Yes, it could certainly. How many comparisons would you need to do in order to determine if the instruction covers the transition between contended and uncontended operation? For the general case (in one state or the other, but not across the two) a couple of untaken branches might end up faster than emulating the whole chip at a t-state level. Maybe. Andrew -- -- Andrew Collier ([EMAIL PROTECTED]) -- My other -- http://mnemotech.ucam.org -- .sig is a -- Part 3 Materials Science, Cambridge -- PDF file --
