Oh, also, I've discovered bugs in the code I published yesterday and a few cases where I've clearly switched mentally into 6502 mode (eg, xor 255/inc a instead of just using neg). I don't think there's any value in dumping my code ad nauseam, but should anyone consider actually using the stuff I previously presented, they should be wary.
Tying this to my recent questions about interrupts: I'm mindful that if I use SP to draw scanlines with interrupts enabled, I will occasionally get 2 or 4 pixels of noise at the left edge of my scanlines if I leave interrupts enabled. However, I'm not aware of any way of tracking time other than hsync counting. Also, I'm triple buffering, so hsync catching allows me to advance a video page cleanly. Ideally I'd be able to disable interrupts to draw the scanline, then test at interrupt enable whether I'd missed one. But I guess there's no real way of achieving that? My understanding is that HPEN doesn't count outside the pixel area and the display interrupt will automatically expire in 20 us. I guess I can store HPEN before disabling interrupts, reset my stored value at interrupt, and if in execution generally I spot that it is lower than the stored value is greater than the hardware value then trigger a fake interrupt. But that's much less than neat. On Sun, Oct 25, 2009 at 9:21 PM, Thomas Harte <[email protected]> wrote: > If you're looking for an excuse to make a new release, it seems still > to accept illegal conditions on jr, like jr m, [symbol]. That specific > one turns into ld e, b followed by a lone 0x01. > > On Sat, Oct 24, 2009 at 11:21 PM, Andrew Collier > <[email protected]> wrote: >> >> On 25 Oct 2009, at 00:16, Thomas Harte wrote: >> >>> you fooled me by leaving "Version 1.1, released 13 April 2007" at >>> the top of the read me >> >> Whoops! So it does. >> Fixed in svn (though I don't think I will do a re-release at this point...) >> >> Andrew >> >> -- >> http://www.intensity.org.uk/ >> >> >> >> >
