I remember, back in the '80s when the rest of us were fiddling about with an Apple ][e and other primitive hardware, the really efficient programmers were typically Russian. They had significantly more constrained hardware, particularly in terms of memory space, so efficient and clever coding was priority number one.

 

 

The Atari VCS (2600) is known to be an especially difficult machine to program, and it has one unique characteristic which sets it apart from nearly every other microprocessor-based game console or computer: It has no framebuffer.

That's an even weirder limitation than having only 128 BYTES of memory. It means that the CPU has to draw the picture in real time, as the beam is moving across the screen. That's why the "playfield" has such large black borders around it. When the beam is in those spaces (and in the horizontal and vertical intervals), that's the only "free" time that the CPU has in which to actually execute the game code and do useful work such as polling inputs, doing collision detection, incrementing the score, etc.

There's a great book called Racing the Beam which talks about the development of the 2600, and also includes some detail about its rather unique architecture and the challenges faced by programmers when dealing with it.

Also a brief history here: https://atariage.com/2600/archives/d...?SystemID=2600

 

Relevant to earlier conversation:

 

Going on my cube.

 

The monkey is a metaphor for IB.

 

 

 

Also, deepfake technology is starting to become a tad worrysome:

 

@aidandj this pic is yours the other game is Mario Kart

@Joe Perez @Braineack guys awesome job on the forum site first fastest loading I have witnessed mobile uploading on android has the cleanest file browser 🙋🏻🤠

 

Shoot me a PM after you've sobered up, so that we can discuss further.

(Not judging, I totally get how strong the pull can be.)

 

Hope the insurance premiums are kept current,

 

 

Taxidermy level: expert:

 

Normally I don't care for taxidermy, but that's pretty awesome.

 

On a side note, I've been reverse engineering the API for my new DaikinOne+ thermostat. I now have a pretty much working Home Assistant integration (https://github.com/apetrycki/daikins.../daikinskyport if anybody cares). I pretty much just need to fix the services. I can't figure out what I'm doing wrong (I'm not a python expert by any means).

Here is some data logging that I've been doing with grafana:

 

hmm...lemme think...

nope...I have no idea what you’re talking about...

 

It's open source. So it looks like he's taking data points from the thermostat over time and graphing them. Something i feel an expensive digital thermostat should do by itself.

 

I agree. I was told the next firmware release includes logging. All in all, I'm not that impressed with the thermostat and I'm glad I didn't pay for it. The interface is slow, it seems to have issues keeping the setpoint (see graph), and it's really not very user friendly. I do have to say though, the API has a ton of information in it. Probably due to the fact it wasn't meant for public consumption. The main reason I wanted to get it into Home Assistant is because the interface is better than the thermostat's and I can automate the hell out of it. I also use the outdoor sensor for my temp and humidity info on my home controllers. Now I don't need their crappy app anymore. I've been seriously tempted to reverse engineer the actual serial protocol and build my own thermostat. For such a simple device, it amazes me they can f it up so bad.

 

This is actually really cool; build thread?