Andrew Collier wrote: > The "stretching" effect is just the right hand side of the scrolly -- > because I had assumed a TV doesn't display further right,
Ah, yeah, I stepped thru it and found the preparations for the next line :-) > 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. It's 32 on each side at the moment, which is half of the potential border area. Might be worth chopping down to avoid seeing problems that don't really exist! Is a typical TV border only 16 pixels? I'll have to check mine... > I reckon there should be something like 40 pixels at the top and bottom, > but less at the sides than you've already got.... The current 24 pixels top and bottom is quite a bit short of that! It's probably worth generating the extra lines as they can be displayed in the windowed mode and just cropped for full screen. The 125% horizontal stretching you mentioned in a previous message could also be done for free if the video card supports hardware stretching, but would be deadly slow if it needs to be done it hardware. It might look awful anyway so I'll have to try it out first! > 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. I've only got FRED disks 37 and 37 :-/ Shame there isn't a CD compilation of them for sale or something! > Yes, it does look like an 8 tstate rounding thing going on. Thanks for the results - the uncontended timings and I/O delays seems to be working well, it's just the contended timings that are complete pants! The simple doubling causes problems with a lot of software (even with the exceptions mentioned on the list) so I'm going to stick with 8 t-state rounding and add extra time for the more memory intensive exceptions. In the end it may end up simpler with time doubling and reductions for the exceptions but I'll have to see. > How many comparisons would you need to do in order to determine if the > instruction covers the transition between contended and uncontended > operation? I have 2 flags for the current contention: the first is recalculated once per line (or on each video change) to determine whether the current line might be contended (checking screen on/off state, for mode 1, and vertical position wrt the borders). The second it done for each instruction iff the first flag is set, and checks for mode 1 and horizontal position wrt the borders). For a split check: if the first one is set (and we're not in mode 1) we need to check to see if the current position + instruction time pushed it over the borders at 64 or 320 cycles. Could be done something like: (64 - tstates) < (LineCycleCounter > 64 ? LineCycleCounter-320 : LineCycleCounter); Si
