On Thursday, 19 September 2013 at 11:53:50 UTC, Nick Sabalausky wrote:
> Unfortunately I don't have much (any) time for hardware tinkering these days :(

yeah... I never did real hardware - too rich for my blood - but I've written emulators, compilers, and assemblers for "hardware" I defined myself. It can be quite a blast, though it takes a while.... and it does kinda force you to ask: why not just do a library without all the weird bytesin the middle?

And practically, maybe that's right, but nothing beats the fun of doing it all yourself. (ditto for running on bare metal - you could do pretty much everything in userspace, but there's a part of sticking that floppy disk in and knowing it is all you.)

On Thursday, 19 September 2013 at 14:49:35 UTC, Adam D. Ruppe wrote:
>
> actually, I do want some way to transfer files easily. Using scp and so on is kinda a pain, I would like to just
>
> cat file > REMOTE_COMPUTER
>
> and be done with it. scp is ok if you have keys set up on both sides and they are unix, but when you're on putty and just want to dump a file over to the Windows side, what I'd love is to hit a command and then get a save as prompt on the receiving end. Or, better yet, run a program right on it too.
>
At the lowest level, you could use netcat for this (and like a million other awesome/silly things).  An rsync daemon might also pinch hit here.  But it sounds like what you really want is a writable CIFS mount.  Or sshfs.

-Wyatt

On Thu, 19 Sep 2013 16:58:44 +0200
"Adam D. Ruppe" <destructionator@gmail.com> wrote:

> On Thursday, 19 September 2013 at 11:53:50 UTC, Nick Sabalausky wrote:
> > Unfortunately I don't have much (any) time for hardware tinkering these days :(
> 
> yeah... I never did real hardware - too rich for my blood -

It does tend to be a much more expensive hobby than software. :/

> but I've written emulators, compilers, and assemblers for "hardware" I defined myself. It can be quite a blast, though it takes a while.... and it does kinda force you to ask: why not just do a library without all the weird bytesin the middle?
> 
> And practically, maybe that's right, but nothing beats the fun of doing it all yourself. (ditto for running on bare metal - you could do pretty much everything in userspace, but there's a part of sticking that floppy disk in and knowing it is all you.)

Yea.

On Thu, 19 Sep 2013 23:07:42 +1000
Manu <turkeyman@gmail.com> wrote:

> On 19 September 2013 17:24, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> > On Wed, 18 Sep 2013 13:31:48 -0700
> > "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> > >
> > > I remember in the old DOS days, some games would load up custom graphics into the video card's text font buffer, so that they can draw sprites just by writing the corresponding characters into the video card's text buffer.  You can get very fast drawing rates since the video card does most of the work for you (and you only need to transfer 1 byte per 8x8 block of pixels instead of 8 bytes or more).
> > >
> >
> > That's essentially the same strategy behind the graphics hardware in
> > most 8/16-bit consoles. Basically the ones from around SMS/NES and
> > then up until 3D. You can identify them from the grid-based
> > layouts (which were a huge improvement, for both gamers *and*
> > developers over the "carefully time your opcodes to adjust the
> > scanlines while they're being drawn" used by Atari VCS/2600 and, I'm
> > guessing, probably the ColecoVision and SG-1000, which is what make
> > them so amazingly affordable at the time).
> >
> 
> Atari 2600 was the only scanline renderer I know of from that time, and it certainly was made to be cheap!

It's a genuinely impressive feat of minimalistic engineering. And it makes Pitfall all the more impressive.

Several years ago, I made a little semi-game for it. It wasn't really a true game - there was no objective or score or game over - just a player character, a one-screen room with wall collision[1] and two objects that made you change color when you touched them (and then change back upon pressing the button. Heh, yea, "the" button on the controller ;) ).

I even designed and built a (not particularly reliable, b/c I forgot to account for signal propagation delays) EEPROM burner, bought a 2600-cart PCB with IC socket, and ran the "game" on actual hardware :) Cool stuff.

[1] That's another fascinating thing about the VCS/2600: Unlike
many later systems (at least to my knowledge), it had *pixel-perfect*
collision detection *in hardware*, as a trivial result of the
playfield/sprite *rendering* hardware.


> ColecoVision and SG-x000 were not affordable by comparison to the 2600.
> 
> ColecoVision, Intellivision, Atari 5200, Atari 7800, NES, SMS (SG-1000 and friends), Genesis, Snes, C64, etc, etc were all tile renderers, and the first 5 items in that list didn't even have scroll-offset registers.
> 

Ahh, ok, I didn't know that about ColecoVision, SG-x000 or
Intellivision (or the later Ataris). I've never had much experience
with those ones  (even as just a player), so I was just guessing
based on what little I could remember of the graphics. I'm more familiar
with VCS/2600, NES, and to a lesser extent the SMS (beyond the SG-1000
era, so like Alex Kidd, Fantasy Zone, Phantasy Star, etc).

Come to think of it, I have played an SG-1000 game (involving a penguin pushing an egg) that was very clearly tile-based. Actually looked very CGA-like, come to think of it.


> In DOS, a lot of CGA/EGA/VGA games used a similar approach as
> > DOS-text-mode/NES/SMS/etc, but it had to be done in software. Obviously in those cases it didn't reduce the amount of data sent to the video card, but it did still reduce (significantly) the amount of HDD and RAM required to store the levels, and it somewhat simplified/reduced the amount of processing needed to render.
> >
> > (I've done a bit of old-school homebrew, and got my real coding start in DOS VGA gaming. Fascinating and incredibly fun stuff to develop for. I'd love to design/build my own tile-based console someday, just for the heck of it.)
> >
> 
> Do it, it's surprisingly easy, but jolly good fun :)
> 

Yea, it really is surprisingly easy, and I definitely want to. If you understand low-level bit-manipulation, then you really understand the core of that you need to know. The rest is pretty easy to pick up if you already have that basic knowledge, since that's all digital hardware really is - bit manipulation and logic gates.

You just have to remember to take into account:

1. Signal propagation delay (Probably the main reason my EEPROM burner failed about 67% of its full image transfers - there were brief intermittent bit flips, like 0->1->0, when the logic was *supposed* to keep an output bit the same)

and 2. Remember to stick a capacitor across the GND and +5v (or
whatever voltage) pins of each IC (Which *improved* my burner's success
rate *up to* 33% of full images written versus a paltry 33% of *bytes*
written ;))

On Thu, 19 Sep 2013 16:55:06 +0200
"Adam D. Ruppe" <destructionator@gmail.com> wrote:

> On Thursday, 19 September 2013 at 07:24:19 UTC, Nick Sabalausky wrote:
> > That's essentially the same strategy behind the graphics hardware in most 8/16-bit consoles.
> 
> Something else I love from the good old days: palette swaps. (This is why color.d, previous image.d, has a separate class for IndexedImage - it isn't a true color image with limited colors. It is a whole new paradigm with rich semantics! You can saw entry 1 == foreground and stick to that in your images and get some cool matching with the user's theme with ease.)
> 
> You could do so much with it to get cool looks, and it was fast. One of my favorite palette swap things was the old Nintendo game Dragon Warrior.
> 
> When your life ran low, it changed the font entry from white to red. But, of course, there's other places that used that entry too - the NES had only a 16 color palette (with only 4 colors per tile) so reuse was a necessity - so you'd have parts of the world changing to red too!
> 
> On one hand, that's a technical limitation, but on the other hand I thought it looked great and purposefully copied it for my 256 color DOS rpg.
> 
> You could also show/hide things by changing palette entries to be black on black, you could do transitions to night time with a palette swap, the list goes on.
> 
> I love it.

Yup. The NES Mega Man games made very heavy use of that to fantastic effect. Most notably changing Mega Man's color theme for each weapon, but the levels made very intelligent use of it, too.

It was also a common trick in DOS VGA games, and really almost anywhere you look in late-80's/early-90's gaming.

Palette swaps were a great way to get variety while inherently *guaranteeing* consistency, not to mention the processor/bus/memory savings.

That said, 16/24/32 bit color is *also* nice since you no longer have to worry about managing and matching up palettes or getting the wrong colors where you didn't expect it.

.... even more off topic lol

On Friday, 20 September 2013 at 01:02:59 UTC, Nick Sabalausky wrote:
> Phantasy Star

man, great series there. 1,2, and 3 were kinda slow moving.... I think I had to grind over to like level 8 before I dared venture more than ten steps away from the town in phantasy star 1!

PS4 is one of the best games ever made though. It's like they looked at the best parts of all three, put them together, then saw the glaring flaw: you walked too bloody slowly - and fixed it!

Great game, it's the reason I had to have a Genesis.

On Thu, 19 Sep 2013 16:49:34 +0200
"Adam D. Ruppe" <destructionator@gmail.com> wrote:

> On Wednesday, 18 September 2013 at 20:33:10 UTC, H. S. Teoh wrote:
> > Plus, they don't include quite enough Unicode glyphs for my needs (actually, do they even support unicode at all?!).
> 
> not really, I don't think so anyway. They (at least on my box) have some iso 8859-1 characters, but not beyond that.
> 

I've always felt text rendering engines should be able to automatically fallback to another font for any characters that aren't in the selected font. (Ideally with a user-configurable chain of fallbacks, similar to CSS, but selected on a per-character basis.) Because showing the right character in a mismatched font has *got* to be better than not showing the character at all and a generic "missing font" glyph.

Besides, even with the same font, it's not as if there's really all *that* much consistency between, ex., latin, cyrillic, hiragana, hangool, arabic, aincient egyptian...uhhh...klingon...etc.

> 
> BTW I'm pretty sure Unicode has a few user defined sections that would be ideal for this. You set a bitmap for your user defined characters and then send them right out.

Unicode even has (experimental, last I checked) pages defined for a
variety of common (and not-so-common) non-text symbols. The four
playing card suits, methods of transportation, etc.

On Thu, 19 Sep 2013 17:17:24 +0200
"Wyatt" <wyatt.epp@gmail.com> wrote:

> On Thursday, 19 September 2013 at 14:49:35 UTC, Adam D. Ruppe wrote:
> >
> > actually, I do want some way to transfer files easily. Using scp and so on is kinda a pain, I would like to just
> >
> > cat file > REMOTE_COMPUTER
> >
> > and be done with it. scp is ok if you have keys set up on both sides and they are unix, but when you're on putty and just want to dump a file over to the Windows side, what I'd love is to hit a command and then get a save as prompt on the receiving end. Or, better yet, run a program right on it too.
> >
> At the lowest level, you could use netcat for this (and like a million other awesome/silly things).  An rsync daemon might also pinch hit here.  But it sounds like what you really want is a writable CIFS mount.  Or sshfs.
> 

I love sshfs.

Only thing is, I wish it were better integrated with ssh command lines. I don't know it would work though. Maybe establishing an sshfs connection would also establish a nickname you could prefix to commands to execute them remotely, plus special attention for remote envars. Something like:

joe@home$ pwd
/etc/blah

joe@home$ sshfs remoteuser@myserver ...etc... --cli=ssh-myserver

joe@home$ pwd
/etc/blah

joe@home$ ssh-myserver pwd
/home/remoteuser

joe@home$ echo $HOME
/home/joe

joe@home$ echo $ssh-myserver->HOME
/home/remoteuser

joe@home$ ssh-myserver echo $HOME
/home/joe

joe@home$ ssh-myserver echo $ssh-myserver->HOME /home/remoteuser

joe@home$ cp ~/hello.d /mnt/myserver
joe@home$ ssh-myserver cat hello.d
import std.stdio; void main() { writeln("hello"); }

joe@home$ sshfs cli ssh-myserver
remoteuser@myserver$ pwd
/home/remoteuser

remoteuser@myserver$ echo $HOME
/home/remoteuser

remoteuser@myserver$ -- Mostly just like a normal ssh prompt now, but with bonuses (bonuses require special support on remote system)

remoteuser@myserver$ ssh-client pwd
/etc/blah

remoteuser@myserver$ echo $-<HOME
/home/joe

remoteuser@myserver$ echo "Made on myserver" > /ssh-client/msg.txt
remoteuser@myserver$ exit
joe@home$ cat msg.txt
Made on myserver

On 20 September 2013 11:02, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:

> On Thu, 19 Sep 2013 23:07:42 +1000
> Manu <turkeyman@gmail.com> wrote:
>
> > On 19 September 2013 17:24, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:
> >
> > > On Wed, 18 Sep 2013 13:31:48 -0700
> > > "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> > > >
> > > > I remember in the old DOS days, some games would load up custom graphics into the video card's text font buffer, so that they can draw sprites just by writing the corresponding characters into the video card's text buffer.  You can get very fast drawing rates since the video card does most of the work for you (and you only need to transfer 1 byte per 8x8 block of pixels instead of 8 bytes or more).
> > > >
> > >
> > > That's essentially the same strategy behind the graphics hardware in
> > > most 8/16-bit consoles. Basically the ones from around SMS/NES and
> > > then up until 3D. You can identify them from the grid-based
> > > layouts (which were a huge improvement, for both gamers *and*
> > > developers over the "carefully time your opcodes to adjust the
> > > scanlines while they're being drawn" used by Atari VCS/2600 and, I'm
> > > guessing, probably the ColecoVision and SG-1000, which is what make
> > > them so amazingly affordable at the time).
> > >
> >
> > Atari 2600 was the only scanline renderer I know of from that time, and it certainly was made to be cheap!
>
> It's a genuinely impressive feat of minimalistic engineering. And it makes Pitfall all the more impressive.
>

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!
Fancy only having a couple of hundred cycles in the vblank, and just a
couple more cycles each hblank to perform 'game logic' ;)

Several years ago, I made a little semi-game for it. It wasn't really a
> true game - there was no objective or score or game over - just a player character, a one-screen room with wall collision[1] and two objects that made you change color when you touched them (and then change back upon pressing the button. Heh, yea, "the" button on the controller ;) ).
>
> I even designed and built a (not particularly reliable, b/c I forgot to account for signal propagation delays) EEPROM burner, bought a 2600-cart PCB with IC socket, and ran the "game" on actual hardware :) Cool stuff.
>
> [1] That's another fascinating thing about the VCS/2600: Unlike
> many later systems (at least to my knowledge), it had *pixel-perfect*
> collision detection *in hardware*, as a trivial result of the
> playfield/sprite *rendering* hardware.
>

Nearly all systems from that era had pixel-perfect collision handled by the
rendering hardware in more or less the same way.
Anything with separates fields (tilemap vs sprites, sprite vs sprite) could
easily latch a bit when an intersection occurred.

> ColecoVision and SG-x000 were not affordable by comparison to the
> > 2600.
> >
> > ColecoVision, Intellivision, Atari 5200, Atari 7800, NES, SMS (SG-1000 and friends), Genesis, Snes, C64, etc, etc were all tile renderers, and the first 5 items in that list didn't even have scroll-offset registers.
> >
>
> Ahh, ok, I didn't know that about ColecoVision, SG-x000 or
> Intellivision (or the later Ataris). I've never had much experience
> with those ones  (even as just a player), so I was just guessing
> based on what little I could remember of the graphics. I'm more familiar
> with VCS/2600, NES, and to a lesser extent the SMS (beyond the SG-1000
> era, so like Alex Kidd, Fantasy Zone, Phantasy Star, etc).
>
> Come to think of it, I have played an SG-1000 game (involving a penguin pushing an egg) that was very clearly tile-based. Actually looked very CGA-like, come to think of it.
>

The SMS was an awesome little piece of hardware... perhaps my favourite
vintage platform :)
The took the popular 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.
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.
The difference this made in practise was huge, and it's barely any more
gates in the chip. I always wondered why TMS stopped so short of the mark...
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.

> In DOS, a lot of CGA/EGA/VGA games used a similar approach as
> > > DOS-text-mode/NES/SMS/etc, but it had to be done in software. Obviously in those cases it didn't reduce the amount of data sent to the video card, but it did still reduce (significantly) the amount of HDD and RAM required to store the levels, and it somewhat simplified/reduced the amount of processing needed to render.
> > >
> > > (I've done a bit of old-school homebrew, and got my real coding start in DOS VGA gaming. Fascinating and incredibly fun stuff to develop for. I'd love to design/build my own tile-based console someday, just for the heck of it.)
> > >
> >
> > Do it, it's surprisingly easy, but jolly good fun :)
> >
>
> Yea, it really is surprisingly easy, and I definitely want to. If you understand low-level bit-manipulation, then you really understand the core of that you need to know. The rest is pretty easy to pick up if you already have that basic knowledge, since that's all digital hardware really is - bit manipulation and logic gates.
>
> You just have to remember to take into account:
>
> 1. Signal propagation delay (Probably the main reason my EEPROM burner failed about 67% of its full image transfers - there were brief intermittent bit flips, like 0->1->0, when the logic was *supposed* to keep an output bit the same)
>
> and 2. Remember to stick a capacitor across the GND and +5v (or
> whatever voltage) pins of each IC (Which *improved* my burner's success
> rate *up to* 33% of full images written versus a paltry 33% of *bytes*
> written ;))
>

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.
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.
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...

On 20 September 2013 11:40, Adam D. Ruppe <destructionator@gmail.com> wrote:

> .... even more off topic lol
>
> On Friday, 20 September 2013 at 01:02:59 UTC, Nick Sabalausky wrote:
>
>> Phantasy Star
>>
>
> man, great series there. 1,2, and 3 were kinda slow moving.... I think I had to grind over to like level 8 before I dared venture more than ten steps away from the town in phantasy star 1!
>
> PS4 is one of the best games ever made though. It's like they looked at the best parts of all three, put them together, then saw the glaring flaw: you walked too bloody slowly - and fixed it!
>
> Great game, it's the reason I had to have a Genesis.
>

+1 ;)