G'day all! That's me ... as you can tell, it's been on the back-burner for a while due to work and so on but I'll get back to it at some point and at least get our goose walking around.
@deater those look great, I'll check them out and add a link, especially since there's some lo-res stuff there! I don't recall every seeing a lo-res game other than brick out!
Thanks for the tips re: blanking interrupts, although to be fair there's no way in the world I'm going to cycle-count the entire thing ... unless ... unless ...
Anyway, such a shame there's no little wire there to trigger IRQ from VBI, it'd make so many things easier. It seems really obvious now but I guess at the time it Wozn't.
In the olden days of x86: "REPNZ SCASB" to get the length of a zero-terminated string and "REP MOVSB" to copy bytes from place to place. But I think more modern CPUs actually work faster with the RISCier equivalents.
Yep, a pretty serious piece of kit, although you really needed a monochrome monitor for it to work properly ... regular TVs didn't have the horizontal bandwidth.
Sydney's works fine. London's too, not the special one the regular tube one. Also Tokyo Narita and Schipol. What they've all got in common is that they're well connected to a good public transport system.
The SFO airport BART line serves the suburbs too and it counts just fine. Airport connections come in a bunch of different varieties. I agree that Bangkok's is definitely one that's faced challenges though!
Well, sure, and theoretically a success gets you 2xx and a failure gets you 4xx/5xx.
But there's a layer beneath HTTP as well. If all you get back is a TCP RST, did the request succeed or fail? How about if you get an ICMP unreachable or just a timeout ... should you retry?
So, the Internet being what it is, it is probably not a bad idea to aim for idempotence for the critical bits.
What I'm a bit puzzled by here is that if I'm reading the X-axis right the rot sets in at 3 weeks ... I mean, that's not very far in. It seems odd that the graphs are both otherwise so linear.
I just EOLed a project which started 8 years ago ... at least one bug existed for 7.5 years of that. It was a minor UI bug and just bumped along at Priority Low with no-one really minding it until the company got acquired and the project got merged into another one. There were others as well.
My point is: without splitting the "backlog" by priority it is hard to see if this is really "software death" or just "bug fossilization" ...
This is an accumulation over the 4 month period, not a total issue count on the tracker. So... there were already many issues in the backlog before the measurement window started, and 500 new issues were opened during the period. :-/
I think also, a really top notch expert makes what they're doing seem so effortless that you do think "yeah, that's just what I would have done".
And probably you would have, at least eventually, although maybe with a couple of false starts and by that point perhaps some misfeatures have already been locked in and now your simple, elegant solution (the one you came up with all on your own without some fancy consultant) isn't quite going to work the way you'd like it to, but it's still 90% of the way there and you're only a little bit over budget -- so long as you cut a couple of the less useful features you should hopefully get the whole thing done before you lose the support of management -- but then they change CTO and the whole thing gets put on hold indefinitely.
