<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments for Reenigne blog</title>
	<atom:link href="http://www.reenigne.org/blog/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.reenigne.org/blog</link>
	<description>Stuff I think about</description>
	<lastBuildDate>Tue, 21 May 2013 08:42:51 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>Comment on How to get away with disabling DRAM refresh by Scali</title>
		<link>http://www.reenigne.org/blog/how-to-get-away-with-disabling-dram-refresh/comment-page-1/#comment-4617</link>
		<dc:creator>Scali</dc:creator>
		<pubDate>Tue, 21 May 2013 08:42:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.reenigne.org/blog/?p=1920#comment-4617</guid>
		<description><![CDATA[Yes, I think you&#039;re right.
The 2600 didn&#039;t even have any RAM chip as such, but the 128 bytes(!) of memory in the system were integrated in the PIA 6532 chip, which handled I/O and timers.]]></description>
		<content:encoded><![CDATA[<p>Yes, I think you're right.<br />
The 2600 didn't even have any RAM chip as such, but the 128 bytes(!) of memory in the system were integrated in the PIA 6532 chip, which handled I/O and timers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on How to get away with disabling DRAM refresh by Andrew</title>
		<link>http://www.reenigne.org/blog/how-to-get-away-with-disabling-dram-refresh/comment-page-1/#comment-4616</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Tue, 21 May 2013 08:24:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.reenigne.org/blog/?p=1920#comment-4616</guid>
		<description><![CDATA[That is interesting - thanks, Scali! I think the RAM in the Atari 2600 was static too, though that&#039;s a few years earlier.]]></description>
		<content:encoded><![CDATA[<p>That is interesting - thanks, Scali! I think the RAM in the Atari 2600 was static too, though that's a few years earlier.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on How to get away with disabling DRAM refresh by Scali</title>
		<link>http://www.reenigne.org/blog/how-to-get-away-with-disabling-dram-refresh/comment-page-1/#comment-4615</link>
		<dc:creator>Scali</dc:creator>
		<pubDate>Mon, 20 May 2013 20:31:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.reenigne.org/blog/?p=1920#comment-4615</guid>
		<description><![CDATA[An interesting bit of trivia: The Commodore VIC-20 did not have refresh built into the chipset. Commodore opted for static ram, so they did not have to handle the refresh problem. The machine only had 5 KB of RAM anyway, so the extra cost was not that much of an issue.

It&#039;s the only machine from that era that I know of, that uses static RAM, and no refresh.]]></description>
		<content:encoded><![CDATA[<p>An interesting bit of trivia: The Commodore VIC-20 did not have refresh built into the chipset. Commodore opted for static ram, so they did not have to handle the refresh problem. The machine only had 5 KB of RAM anyway, so the extra cost was not that much of an issue.</p>
<p>It's the only machine from that era that I know of, that uses static RAM, and no refresh.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on A new approach to the Monty Hall problem by Andrew</title>
		<link>http://www.reenigne.org/blog/montyhall/comment-page-1/#comment-4597</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Thu, 18 Apr 2013 21:39:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.reenigne.org/blog/?p=22#comment-4597</guid>
		<description><![CDATA[Your analysis takes it&#039;s conclusion (that P=1/2) as a premise, and is therefore a tautology. Just because there are two doors left and a coin has two sides doesn&#039;t mean that the probabilities of those two things work out the same, as I hoped my original post had clarified.]]></description>
		<content:encoded><![CDATA[<p>Your analysis takes it's conclusion (that P=1/2) as a premise, and is therefore a tautology. Just because there are two doors left and a coin has two sides doesn't mean that the probabilities of those two things work out the same, as I hoped my original post had clarified.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on A new approach to the Monty Hall problem by Dr. Subhash C. Sharma</title>
		<link>http://www.reenigne.org/blog/montyhall/comment-page-1/#comment-4596</link>
		<dc:creator>Dr. Subhash C. Sharma</dc:creator>
		<pubDate>Thu, 18 Apr 2013 20:47:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.reenigne.org/blog/?p=22#comment-4596</guid>
		<description><![CDATA[Probability calculation by using the coins.

After the host throws open the empty door (let’s say C), which he always knows beforehand as empty (due to the placing of the prize behind a certain door and the player choosing a door for himself), the choice involving two remaining doors (A or B) for the prize and by the player in terms of two sides of coin can be considered as the head H (corresponding to door A) and the tail T (corresponding to door B). These choices are mutually exclusive in terms of H and T, implying that the player or the prize can’t be both at door A and door B. 

Consider also that the prize and the player are represented now by two coins, coin 1 and coin 2, respectively. 

We can then represent all the possible choices involving prize, player and the two remaining doors A and B (after the host has opened the empty door with the prior knowledge about the door being empty) in terms of coins 1 and 2 and their heads and tails.

From the above, prize at door A will be designated as 1H (head in the case of coin 1) and the player at door A as 2H. Similarly, prize at door B will be 1T and the player at door B as 2T. 

The conditions for switch to work (leading to a win), i.e. either the prize is at door A (1H) and the player at door B (2T), or the prize at door B (1T) and the player at door A (2H): which in terms of probability, the probability for the switch to work,
P(s) = P(1H)*P(2T) + P(1T)*P(2H) ………….. (Eq. 1)

Similarly, the conditions for the switch to not work (i.e. failing to win), either the prize is at door A (1H) and the player at door A (2H), or the prize at door B (1T) and the player at door B (2T), which in terms of probability for switch not producing a win,
P(f) = P(1H)*P(2H) + P(1T)*P(2T) ……………(Eq. 2).

Since the probability for head or tail for any coin is 1/2, i.e. P(1H) = P(1T) = P(2H) = P(2T) = 1/2. 

The probability therefore for the switch leading to a prize (from Eq. 1),   P(s) = 1/2;

And the probability switch leading to no win (using Eq. 2), P(f) = 1/2

In other words, there is no advantage in the player making a switch]]></description>
		<content:encoded><![CDATA[<p>Probability calculation by using the coins.</p>
<p>After the host throws open the empty door (let’s say C), which he always knows beforehand as empty (due to the placing of the prize behind a certain door and the player choosing a door for himself), the choice involving two remaining doors (A or B) for the prize and by the player in terms of two sides of coin can be considered as the head H (corresponding to door A) and the tail T (corresponding to door B). These choices are mutually exclusive in terms of H and T, implying that the player or the prize can’t be both at door A and door B. </p>
<p>Consider also that the prize and the player are represented now by two coins, coin 1 and coin 2, respectively. </p>
<p>We can then represent all the possible choices involving prize, player and the two remaining doors A and B (after the host has opened the empty door with the prior knowledge about the door being empty) in terms of coins 1 and 2 and their heads and tails.</p>
<p>From the above, prize at door A will be designated as 1H (head in the case of coin 1) and the player at door A as 2H. Similarly, prize at door B will be 1T and the player at door B as 2T. </p>
<p>The conditions for switch to work (leading to a win), i.e. either the prize is at door A (1H) and the player at door B (2T), or the prize at door B (1T) and the player at door A (2H): which in terms of probability, the probability for the switch to work,<br />
P(s) = P(1H)*P(2T) + P(1T)*P(2H) ………….. (Eq. 1)</p>
<p>Similarly, the conditions for the switch to not work (i.e. failing to win), either the prize is at door A (1H) and the player at door A (2H), or the prize at door B (1T) and the player at door B (2T), which in terms of probability for switch not producing a win,<br />
P(f) = P(1H)*P(2H) + P(1T)*P(2T) ……………(Eq. 2).</p>
<p>Since the probability for head or tail for any coin is 1/2, i.e. P(1H) = P(1T) = P(2H) = P(2T) = 1/2. </p>
<p>The probability therefore for the switch leading to a prize (from Eq. 1),   P(s) = 1/2;</p>
<p>And the probability switch leading to no win (using Eq. 2), P(f) = 1/2</p>
<p>In other words, there is no advantage in the player making a switch</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Computer-controlled TV by Andrew</title>
		<link>http://www.reenigne.org/blog/computer-controlled-tv/comment-page-1/#comment-4579</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Mon, 11 Mar 2013 14:08:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.reenigne.org/blog/?p=1817#comment-4579</guid>
		<description><![CDATA[I didn&#039;t buy any discrete components for this - I had all that stuff lying around anyway. But the other side of is just that I find doing this sort of thing to be a lot of fun! If I needed to do it and the hard way wasn&#039;t fun, I&#039;d certainly spend a few pounds to do it the easy way.

I did actually try a universal remote first, but didn&#039;t have any success with it - perhaps that universal remote also got its codes from the LIRC database.

IR serial between Spectrums would certainly be a fun hack!]]></description>
		<content:encoded><![CDATA[<p>I didn't buy any discrete components for this - I had all that stuff lying around anyway. But the other side of is just that I find doing this sort of thing to be a lot of fun! If I needed to do it and the hard way wasn't fun, I'd certainly spend a few pounds to do it the easy way.</p>
<p>I did actually try a universal remote first, but didn't have any success with it - perhaps that universal remote also got its codes from the LIRC database.</p>
<p>IR serial between Spectrums would certainly be a fun hack!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on How to get away with disabling DRAM refresh by Andrew</title>
		<link>http://www.reenigne.org/blog/how-to-get-away-with-disabling-dram-refresh/comment-page-1/#comment-4578</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Mon, 11 Mar 2013 13:55:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.reenigne.org/blog/?p=1920#comment-4578</guid>
		<description><![CDATA[I think tile-based displays aren&#039;t really a problem because refresh only needs to touch each row, not each bit. So as long as the &quot;screen position to tile&quot; map covers all the rows, the &quot;tile to pixels&quot; map data will get refreshed as well.

The CGA isn&#039;t responsible for refreshing the system RAM, but as you said it does have its own VRAM which is also DRAM and does need to be refreshed. That RAM doesn&#039;t partake in the system refresh and the CGA card doesn&#039;t have any dedicated refresh circuitry so it must be refreshed by the display addresses. Fortunately the 6845 continues to generate addresses even in the non-display areas, so works fine for this task.

The C64 can&#039;t use the display address for refresh because the data would decay during vertical blanking as you said. However, it&#039;s simpler to refresh constantly (even in the active display area) than to add circuitry to turn off the refresh during the active time. It doesn&#039;t slow the system down either, since the Vic-II does a memory read every clock cycle anyway.]]></description>
		<content:encoded><![CDATA[<p>I think tile-based displays aren't really a problem because refresh only needs to touch each row, not each bit. So as long as the "screen position to tile" map covers all the rows, the "tile to pixels" map data will get refreshed as well.</p>
<p>The CGA isn't responsible for refreshing the system RAM, but as you said it does have its own VRAM which is also DRAM and does need to be refreshed. That RAM doesn't partake in the system refresh and the CGA card doesn't have any dedicated refresh circuitry so it must be refreshed by the display addresses. Fortunately the 6845 continues to generate addresses even in the non-display areas, so works fine for this task.</p>
<p>The C64 can't use the display address for refresh because the data would decay during vertical blanking as you said. However, it's simpler to refresh constantly (even in the active display area) than to add circuitry to turn off the refresh during the active time. It doesn't slow the system down either, since the Vic-II does a memory read every clock cycle anyway.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Computer-controlled TV by tahrey</title>
		<link>http://www.reenigne.org/blog/computer-controlled-tv/comment-page-1/#comment-4577</link>
		<dc:creator>tahrey</dc:creator>
		<pubDate>Mon, 11 Mar 2013 12:07:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.reenigne.org/blog/?p=1817#comment-4577</guid>
		<description><![CDATA[I sorta know how you feel, but when the remote in question can bought quite cheaply (I ordered a couple of 8-device ones for work in order to serve as backup for a load of different projectors etc where the remotes keep walking away ... those were £15 each, but models with fewer memory banks were cheaper still) it&#039;s kind of stretching the point a bit. How much are you willing to spend on discrete components and how much time are you willing to put in to avoid buying a commercial product that&#039;s worth less than 3 hours of minimum wage labouring?

Anyway, my question was in fact wondering why it wasn&#039;t possible to capture codes with your own kit, instead of trying to &quot;discover&quot; them or hunt them out another way, when commercial remotes can do it easily enough ;) ... 2-way infrared-to-serial-header doodads are pretty cheap if you go to the right places (...the wrong places will charge £10+ just for the tranceiver)

Bizarrely I actually have a couple of those IR beads hanging around here, too - I think they must have come either from someone&#039;s long-since-dead VC card, or are spares from a pro room control system - but I have no idea what we could use them for. There&#039;s not much they can connect to as-is, and the whole &quot;run it through a sound card&quot; thing would be a fun project but impractical for any real application, especially as you&#039;d then need a bespoke program to receive and interpret the data and do something with it.

Maybe it could be used to set up line-of-sight wireless communication between a pair of Sinclair Spectrums or the like?]]></description>
		<content:encoded><![CDATA[<p>I sorta know how you feel, but when the remote in question can bought quite cheaply (I ordered a couple of 8-device ones for work in order to serve as backup for a load of different projectors etc where the remotes keep walking away ... those were £15 each, but models with fewer memory banks were cheaper still) it's kind of stretching the point a bit. How much are you willing to spend on discrete components and how much time are you willing to put in to avoid buying a commercial product that's worth less than 3 hours of minimum wage labouring?</p>
<p>Anyway, my question was in fact wondering why it wasn't possible to capture codes with your own kit, instead of trying to "discover" them or hunt them out another way, when commercial remotes can do it easily enough ;) ... 2-way infrared-to-serial-header doodads are pretty cheap if you go to the right places (...the wrong places will charge £10+ just for the tranceiver)</p>
<p>Bizarrely I actually have a couple of those IR beads hanging around here, too - I think they must have come either from someone's long-since-dead VC card, or are spares from a pro room control system - but I have no idea what we could use them for. There's not much they can connect to as-is, and the whole "run it through a sound card" thing would be a fun project but impractical for any real application, especially as you'd then need a bespoke program to receive and interpret the data and do something with it.</p>
<p>Maybe it could be used to set up line-of-sight wireless communication between a pair of Sinclair Spectrums or the like?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on How to get away with disabling DRAM refresh by tahrey</title>
		<link>http://www.reenigne.org/blog/how-to-get-away-with-disabling-dram-refresh/comment-page-1/#comment-4576</link>
		<dc:creator>tahrey</dc:creator>
		<pubDate>Mon, 11 Mar 2013 12:00:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.reenigne.org/blog/?p=1920#comment-4576</guid>
		<description><![CDATA[Interesting ... I did figure mainly that as you would, at least for the bitplane based machines, have to do sequential-read at least on a line by line basis (even if you changed the video page/etc between lines), it would be a fairly effective and &quot;free&quot; way of effecting the whole-RAM refresh... with only programmers dealing with quite complex or advanced display-mashing techniques having to pay it particular attention and overriding the default mechanism (and implement their own, with the performance penalty being worth it for the flexibility). Anyone using regular screen access, or even simpler techniques like splitscreen etc wouldn&#039;t have to worry, as each column (row? I forget) in the matrix would be touched regularly enough to avoid fading out so long as a single text row&#039;s worth of bitmap was shunted from RAM to screen with reasonable regularity. (And a separate refresh routine maybe taking place in the Vblank area, but not being as much of an issue as it wouldn&#039;t directly interfere with display drawing by its very nature anyhow).

Tile-based displays may be more problematic though, as you can&#039;t predict the access pattern except for the relatively much smaller and lower frequency tile array block...

As for the CGA, I was considering that as being entirely separate to the main computer anyhow, as it doesn&#039;t use system RAM; hence the computer needs its own refresh anyhow. The CGA card doesn&#039;t do much other than taking stuff off the bus, putting it into the onboard VRAM, then repeatedly and sequentially reading it out into the monitor port (and/or whatever passes for a DAC on the composite video line...).

The Amiga I guess needs separate refresh, now I think about it, because of the &quot;fast RAM&quot;. Perhaps it doesn&#039;t have to bother when it comes to &quot;chip RAM&quot;, as that gets buzzed through by the vidchip, but the fast RAM is purely for the CPU&#039;s use, much like a PC&#039;s system memory... The C64 I&#039;m not familiar enough with, but I coulda sworn the background is bitmap and a large proportion of the bus time is given over to sequentially reading the video field data from RAM to VIC-II even though it has sprites as well? Is the separate refresh just for Vblank, or does it also run during the display time for some reason?]]></description>
		<content:encoded><![CDATA[<p>Interesting ... I did figure mainly that as you would, at least for the bitplane based machines, have to do sequential-read at least on a line by line basis (even if you changed the video page/etc between lines), it would be a fairly effective and "free" way of effecting the whole-RAM refresh... with only programmers dealing with quite complex or advanced display-mashing techniques having to pay it particular attention and overriding the default mechanism (and implement their own, with the performance penalty being worth it for the flexibility). Anyone using regular screen access, or even simpler techniques like splitscreen etc wouldn't have to worry, as each column (row? I forget) in the matrix would be touched regularly enough to avoid fading out so long as a single text row's worth of bitmap was shunted from RAM to screen with reasonable regularity. (And a separate refresh routine maybe taking place in the Vblank area, but not being as much of an issue as it wouldn't directly interfere with display drawing by its very nature anyhow).</p>
<p>Tile-based displays may be more problematic though, as you can't predict the access pattern except for the relatively much smaller and lower frequency tile array block...</p>
<p>As for the CGA, I was considering that as being entirely separate to the main computer anyhow, as it doesn't use system RAM; hence the computer needs its own refresh anyhow. The CGA card doesn't do much other than taking stuff off the bus, putting it into the onboard VRAM, then repeatedly and sequentially reading it out into the monitor port (and/or whatever passes for a DAC on the composite video line...).</p>
<p>The Amiga I guess needs separate refresh, now I think about it, because of the "fast RAM". Perhaps it doesn't have to bother when it comes to "chip RAM", as that gets buzzed through by the vidchip, but the fast RAM is purely for the CPU's use, much like a PC's system memory... The C64 I'm not familiar enough with, but I coulda sworn the background is bitmap and a large proportion of the bus time is given over to sequentially reading the video field data from RAM to VIC-II even though it has sprites as well? Is the separate refresh just for Vblank, or does it also run during the display time for some reason?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Preventing cheating in online games by Andrew</title>
		<link>http://www.reenigne.org/blog/preventing-cheating-in-online-games/comment-page-1/#comment-4572</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Thu, 07 Mar 2013 15:01:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.reenigne.org/blog/?p=1400#comment-4572</guid>
		<description><![CDATA[&gt; Does online gaming software have memory to store the way I played to make me lose in certain games ?

Certainly such a capability is technically possible. And I have heard of games adapting themselves to the players strengths to give more of a challenge to stronger players and to make themselves less frustrating to weaker players. An online component is not necessary though - offline games have been doing that for a long time.

&gt; If it does, then cheating is involved.

I don&#039;t think that necessarily implies cheating, though - if it&#039;s part of the way the game works, then it&#039;s part of the way the game works.

&gt; So, no matter how good math I have, I will still lose, just they are watching how I play.

Well, either it&#039;s a game of skill (in which case the computer has no influence) or a game of luck (in which case you can lose no matter how good your math is anyway). What kind of game are you talking about here anyway?

&gt; can you tell me how to prevent this?

Yes, there is an absolutely foolproof way to prevent this. Don&#039;t play games which you find frustrating.

&gt; If games software does not function well, would that mean the online games software lose the storage memory and the chance of winning is higher.

Not necessarily. Bugs in games can make the game easier, more difficult or have effects orthogonal to difficulty.]]></description>
		<content:encoded><![CDATA[<p>> Does online gaming software have memory to store the way I played to make me lose in certain games ?</p>
<p>Certainly such a capability is technically possible. And I have heard of games adapting themselves to the players strengths to give more of a challenge to stronger players and to make themselves less frustrating to weaker players. An online component is not necessary though - offline games have been doing that for a long time.</p>
<p>> If it does, then cheating is involved.</p>
<p>I don't think that necessarily implies cheating, though - if it's part of the way the game works, then it's part of the way the game works.</p>
<p>> So, no matter how good math I have, I will still lose, just they are watching how I play.</p>
<p>Well, either it's a game of skill (in which case the computer has no influence) or a game of luck (in which case you can lose no matter how good your math is anyway). What kind of game are you talking about here anyway?</p>
<p>> can you tell me how to prevent this?</p>
<p>Yes, there is an absolutely foolproof way to prevent this. Don't play games which you find frustrating.</p>
<p>> If games software does not function well, would that mean the online games software lose the storage memory and the chance of winning is higher.</p>
<p>Not necessarily. Bugs in games can make the game easier, more difficult or have effects orthogonal to difficulty.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
