![Image](https://cdn1.imggmi.com/uploads/2019/10/10/204810792e01654ee184d77a5b1297c5-full.png)
This is the one i'm using but without the VSYNC attached, i had no problems before the SS fix.
I will ask but if it isn't in the schematic i posted then there's no limiter.rama wrote:Would be great if you could ask the builder whether the LM1881 has a signal output limiter, or some other method to restrict the output levels.
I don't think it does, and hence the output would scale with the Vcc it gets.
The aggressive caching of GET requests from XMLHttpRequest certainly used to be a fairly common problem, to the extent that jQuery and MooTools provide a simple way to append a unique value in a query parameter for each request as per my suggested workaround so there is some precedent. I'm not sure why I was having issues in mobile Firefox on Android as the desktop browser was fine.rama wrote:That's odd. Maybe something else is going on there, as I can't reproduce this here.
But sure, I can add that hack.
I liked get requests better as they produce far less traffic than posts.
Haha, that's certainly a lesson learned :pbenryves wrote: The aggressive caching of GET requests from XMLHttpRequest certainly used to be a fairly common problem, to the extent that jQuery and MooTools provide a simple way to append a unique value in a query parameter for each request as per my suggested workaround so there is some precedent. I'm not sure why I was having issues in mobile Firefox on Android as the desktop browser was fine.
GET shouldn't really modify the resource, but at least it's not harmful in this case. I knew someone who used GET requests for a publicly-editable website (including "delete" links) who then lost a lot of data when Google crawled the site... Anyway, I'm here for the gaming so will take off my web developer's work hat!
Looks good to me! I wouldn't want there to be a variable name conflict but you could always shave a few bytes by using &nc= and then an global integer that increments on every request rather than nocache and the current time. Considering you're already using a WebSocket to retrieve the current state (at least that's what it looks like is happening to me) could you not also send commands over that instead of using the overhead of an HTTP request? Unfortunately I don't believe there's a way to remove specific HTTP headers so I think you'll always have the default browser headers going over the wire.rama wrote:Does that look okay now?
Is there a way to get the packet smaller, maybe?
Of course.Just have to work out the age old SOG issue first.
The "I:40" suggests VSync is connected and unstable. Is this the LM1881 VSync?h: 431 v: 624 PLL:00 A:7b7b7b S:a7.00.02 I:40 D:0585 m:2 ht:2340 vt: 319 hpw: 171 u: 0 s:13 TF:0000 W:31
h: 430 v: 624 PLL:00 A:7b7b7b S:a7.00.02 I:40 D:0585 m:2 ht:2338 vt: 319 hpw: 171 u: 0 s:13 TF:0000 W:31
h: 431 v: 624 PLL:00 A:7b7b7b S:a7.00.02 I:40 D:0585 m:2 ht:2341 vt: 319 hpw: 171 u: 0 s:13 TF:0000 W:31