<div dir="ltr">On 20 September 2013 11:02, Nick Sabalausky <span dir="ltr"><<a href="mailto:SeeWebsiteToContactMe@semitwist.com" target="_blank">SeeWebsiteToContactMe@semitwist.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Thu, 19 Sep 2013 23:07:42 +1000<br>

Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>
<br>
> On 19 September 2013 17:24, Nick Sabalausky <<br>
> <a href="mailto:SeeWebsiteToContactMe@semitwist.com">SeeWebsiteToContactMe@semitwist.com</a>> wrote:<br>
><br>
</div><div class="im">> > On Wed, 18 Sep 2013 13:31:48 -0700<br>
> > "H. S. Teoh" <<a href="mailto:hsteoh@quickfur.ath.cx">hsteoh@quickfur.ath.cx</a>> wrote:<br>
> > ><br>
> > > I remember in the old DOS days, some games would load up custom<br>
> > > graphics into the video card's text font buffer, so that they can<br>
> > > draw sprites just by writing the corresponding characters into the<br>
> > > video card's text buffer.  You can get very fast drawing rates<br>
> > > since the video card does most of the work for you (and you only<br>
> > > need to transfer 1 byte per 8x8 block of pixels instead of 8<br>
> > > bytes or more).<br>
> > ><br>
> ><br>
> > That's essentially the same strategy behind the graphics hardware in<br>
> > most 8/16-bit consoles. Basically the ones from around SMS/NES and<br>
> > then up until 3D. You can identify them from the grid-based<br>
> > layouts (which were a huge improvement, for both gamers *and*<br>
> > developers over the "carefully time your opcodes to adjust the<br>
> > scanlines while they're being drawn" used by Atari VCS/2600 and, I'm<br>
> > guessing, probably the ColecoVision and SG-1000, which is what make<br>
> > them so amazingly affordable at the time).<br>
> ><br>
><br>
</div><div class="im">> Atari 2600 was the only scanline renderer I know of from that time,<br>
> and it certainly was made to be cheap!<br>
<br>
</div>It's a genuinely impressive feat of minimalistic engineering. And it<br>
makes Pitfall all the more impressive.<br></blockquote><div><br></div><div>That it was. I'm still amazed someone actually thought it was a viable games platform, and even more amazed that so many developers made games for it!</div>
<div>Fancy only having a couple of hundred cycles in the vblank, and just a couple more cycles each hblank to perform 'game logic' ;)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Several years ago, I made a little semi-game for it. It wasn't really a<br>
true game - there was no objective or score or game over - just a<br>
player character, a one-screen room with wall collision[1] and two<br>
objects that made you change color when you touched them (and then<br>
change back upon pressing the button. Heh, yea, "the" button on the<br>
controller ;) ).<br>
<br>
I even designed and built a (not particularly reliable, b/c I forgot<br>
to account for signal propagation delays) EEPROM burner, bought a<br>
2600-cart PCB with IC socket, and ran the "game" on actual hardware :)<br>
Cool stuff.<br>
<br>
[1] That's another fascinating thing about the VCS/2600: Unlike<br>
many later systems (at least to my knowledge), it had *pixel-perfect*<br>
collision detection *in hardware*, as a trivial result of the<br>
playfield/sprite *rendering* hardware.<br></blockquote><div><br></div><div>Nearly all systems from that era had pixel-perfect collision handled by the rendering hardware in more or less the same way.</div><div>Anything with separates fields (tilemap vs sprites, sprite vs sprite) could easily latch a bit when an intersection occurred.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> ColecoVision and SG-x000 were not affordable by comparison to the<br>
> 2600.<br>
><br>
> ColecoVision, Intellivision, Atari 5200, Atari 7800, NES, SMS<br>
> (SG-1000 and friends), Genesis, Snes, C64, etc, etc were all tile<br>
> renderers, and the first 5 items in that list didn't even have<br>
> scroll-offset registers.<br>
><br>
<br>
</div>Ahh, ok, I didn't know that about ColecoVision, SG-x000 or<br>
Intellivision (or the later Ataris). I've never had much experience<br>
with those ones  (even as just a player), so I was just guessing<br>
based on what little I could remember of the graphics. I'm more familiar<br>
with VCS/2600, NES, and to a lesser extent the SMS (beyond the SG-1000<br>
era, so like Alex Kidd, Fantasy Zone, Phantasy Star, etc).<br>
<br>
Come to think of it, I have played an SG-1000 game (involving a penguin<br>
pushing an egg) that was very clearly tile-based. Actually looked very<br>
CGA-like, come to think of it.<br></blockquote><div><br></div><div>The SMS was an awesome little piece of hardware... perhaps my favourite vintage platform :)</div><div>The took the popular <span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:19.1875px">TMS9918 video chip (used in colecovision, sg-1000, msx, and a bunch others), and with just a couple of minor tweaks made the system WAY better than any of the others listed.</span></div>
<div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:19.1875px">All they did was added a few bytes for a user-specified clut (rather than a hard-coded colour table), made use of an unused bit in the tile gfx table to select between a second clut (doubling the number of available colours), and added a horizontal+vertical scroll register for the tilemap.</span></div>
<div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:19.1875px">The difference this made in practise was huge, and it's barely any more gates in the chip. </span><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:19.1875px">I always wondered why TMS stopped so short of the mark...</span></div>
<div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:19.1875px">I suppose adding a user-defined clut is more than 16 bytes though. Fixed clut will just switch between some hard-wired resister circuits, a user-clut requires some more video output circuitry, but resisters are cheap... even back then.</span></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> In DOS, a lot of CGA/EGA/VGA games used a similar approach as<br>
> > DOS-text-mode/NES/SMS/etc, but it had to be done in software.<br>
> > Obviously in those cases it didn't reduce the amount of data sent to<br>
> > the video card, but it did still reduce (significantly) the amount<br>
> > of HDD and RAM required to store the levels, and it somewhat<br>
> > simplified/reduced the amount of processing needed to render.<br>
> ><br>
> > (I've done a bit of old-school homebrew, and got my real coding<br>
> > start in DOS VGA gaming. Fascinating and incredibly fun stuff to<br>
> > develop for. I'd love to design/build my own tile-based console<br>
> > someday, just for the heck of it.)<br>
> ><br>
><br>
</div><div class="im">> Do it, it's surprisingly easy, but jolly good fun :)<br>
><br>
<br>
</div>Yea, it really is surprisingly easy, and I definitely want to. If you<br>
understand low-level bit-manipulation, then you really understand the<br>
core of that you need to know. The rest is pretty easy to pick up if<br>
you already have that basic knowledge, since that's all digital<br>
hardware really is - bit manipulation and logic gates.<br>
<br>
You just have to remember to take into account:<br>
<br>
1. Signal propagation delay (Probably the main reason my EEPROM burner<br>
failed about 67% of its full image transfers - there were brief<br>
intermittent bit flips, like 0->1->0, when the logic was *supposed* to<br>
keep an output bit the same)<br>
<br>
and 2. Remember to stick a capacitor across the GND and +5v (or<br>
whatever voltage) pins of each IC (Which *improved* my burner's success<br>
rate *up to* 33% of full images written versus a paltry 33% of *bytes*<br>
written ;))<br></blockquote><div><br></div><div>Aye to that; I had a lot of problems with the gnd circuit on vintage hardware. They were very poorly isolated, and the gnd circuit would often feed-back through all manner of surprising places.</div>
<div>A capacitor will smooth it off a bit, maybe protect you against some suddenly flipping bits, or at least delay it until after a bit value sampling tick has happened.</div><div>Considering how tricky that stuff is in practise, I'd like to know more how it extends to modern circuitry. surely modern hardware must be better isolated...</div>
</div></div></div>