VSync help! (Sharp MZ-80A !)

[kelp7]

The line time *may* be 15Khz. The 8253 has an input clock of 31.5hz so it's close to twice per line.

According to google 15Khz divided by 300 is 50hz. There aren't 300 lines on the display though, only 200. You can't really access individual pixels on this machine but if you could then its resolution is 320 x 200


I shall be trying two sets of 8 pixel-high inverse bars tonight 

[kelp7]

   Success!!


I decided to just try and create three separate inverse-mode bars on the screen as quickly as the interrupt can possibly be launched (so that I could see how many scanlines between changes there were). I (eventually, see below) managed to get three bars of inverse on the screen and it looks like I get about 4 scanlines between each interrupt with the 8253 firing the interrupts as quickly as it can (with a touch of tearing and flickering but that can be sorted out).


However, initially I only saw two of my horizontal bars. I presumed that the first bar was happening so quickly that it was occurring within the vsync and therefore not part of the frame draw. So I changed the 8253 counter in my first interrupt handler (which set inverse mode on) to trigger the 2nd interrupt handler after a larger amount of delay (I put &0040 into counter #1). As expected I saw all three bars then but the really weird thing was that I had a big gap between my first bar and the other two bars.


Here's a mock-up of how it looked:





I wasn't expecting this. I would have expected to see a very large bar of inverse-mode but not a large gap of non-inverse. (The delay was only to wait a while for top of screen and then switch inverse off just after the top). There was no delay in the 2nd interrupt handler to keep inverse-off going for any length of time.


My only conclusion is that the 8253 counters are the culprits. When I set the first interrupt handler to wait &0040 before triggering the 2nd interrupt handler, this probably worked okay and waited with inverse on for long enough to come out the other end of the vsync. Then when I set the counter in my 2nd handler back to &0002 it must have stayed on &0040 for another clock cycle. This is the only conclusion I can come to. I do believe when you load a new value into an 8253 counter it does take a full clock cycle to make the change. If anyone can come up with another reason then I'd be glad to hear of it!!!


But I really am progressing well now with this and it's mainly thanks to you guys and the help you've given!


Cheers
kelp


[EDIT : I forgot to say that I was loading the rate generator with a value of &0002 rather than just &0001. I wasn't sure if I could use &0001 or not as the 8253 rate generator mode counts from n to 1 and it never reaches 0. Perhaps this is something else I need to experiment with]

[kelp7]

And just to finally confirm : You cannot put the value &0001 into a rate generator (8253 mode 2 counter), it simply does nothing (not even count at all as if it is frozen). I was hoping it might simply allow the full input clock rate (31.5khz), I presume I can only get half this perhaps (counting from &0002 to &0001).

[kelp7]

One very last thing : I have corrected the timing issue caused by needing to wait for the 8253 to register a change to its counter values (and therefore have stopped that big blank section of screen between my 1st and 2nd inverse bars). Solution was obvious really. I was waiting for vsync and setting my counters to a bigger value than I normally would just to get past the end of vsync to the top of screen, then setting to lowest value to switch inverse off (but it would take full clock cycle of 8253 to do this). Instead, I have changed it now to wait for vsync, switch inverse on and then wait for vsync to finish before setting up lowest value counter!! This works great and I can get 4 scanlines of inverse at the top of the screen and four lines of non-inverse before the next interrupt occurs. Perfect!


(I suppose the only issue with this is all the waiting around for vsync status during which the main program can't do any processing. Swings & roundabouts really)

[kelp7]

Just updated my website with the working code for a working piece of interrupt triggered inverse (along with screenshot), look right at the bottom of the page.   (Will be tidying up the website properly soon)


Sharp MZ-80A Secrets


(quite a long bit of code but it takes the least amount of time away from main program code as it can). Got it working in BASIC as well which was good to see, will add an additional screenshot of that shortly.