It's interesting and fun that Terry's odd but impressive project is getting a little cult traction. This is kind of neat, though the physics and animations could use some work.
For me, a big irritation with Python - intermediate bytecode or not - is that foolish small mistakes in formatting, or missing symbols, etc. will only make themselves apparent when the interpreter (or bytecode interpreter) actually tries to run or use them. In some configurations, it can be preprocessed and checked, but the most typical and default use cases for Python do not promote this.
Alternate fields have an offset, but only if the horizontal sync timings make it so. If a machine is built to output a progressive image, there aren't really "fields", or you can consider them "all odd" or "all even" fields. I don't know anything about the BBC micro, but the Commodore 64 outputs a progressive image.
No, this isn't correct. The image isn't "progressive" or "interlaced" until the output stage. Whether or not they are identical is secondary to the timings, which is all that matters. If every frame has an integer number of scanlines (and VSYNC begins during H-blank), it's going to be a progressive scan image.
A "CRT from the time" - the things littered around my apartment that occupy a little too much of my time - can easily illustrate the effect I am describing of a progressive scan image without alternating scanline positions. Go grab almost any '90s game console, or have fun with the Sega Genesis, which supports 240p as well as 480i; Sonic 2 uses 480i to fit two viewports into the two-player mode, but uses 240p during a single-player game.
The difference in signaling is that in an interlaced mode, the final scanline is half-length - Vsync begins halfway through the line, causing the next frame to be offset by half a line vertically.
The monitor doesn't "know", in that case. The interlacing is simply a physical phenomenon. Later digital capture devices must recognize this situation and handle it appropriately. Many assume it's always happening, as progressive-scan 252-field NTSC is out of spec anyway.
That isn't quite correct. The C64 outputs a progressive-scan image, which is a hack on top of NTSC or PAL. In this configuration, there are only even or odd fields, which double-strike the same area. Thusly, it is 60 fields per second, and since only one field forms the full frame, it's 60 frames per second as well.
There is no scanline striping; that is strictly an artifact of poor NTSC capture devices (like most HDVTs) that naively assume the incoming signal is a 480i image with odd and even fields.
What sucks is that every smooth-scroll implementation is just another copy of "the most popular one" - a simple S-curve, where it accelerates up to a point and then begins to slow down at the midpoint. If they were implemented with a 1/x curve, you'd get the immediate response from input, without that "slow and drunk" feel typical smooth scrolling delivers, in addition to a smooth animation.
One thing that shouldn't change is the Caltrain ticketing UI. The interface is simple enough to use, and it responds to user input instantly. I can select the ticket I want with four taps in about a second, where the only slowdown is the actual payment.
My Panasonic CF-RZ5 weighs 1.6lbs, and sports VGA, HDMI, Ethernet, 3xUSB3, a headphone jack, a power socket, a 1920x1200 IPS display, and a removable battery. It is from 2016, and makes the idea of all of these features compromising portability questionable.
Even the oldest CRT televisions have a "brightness" control, and it's supposed to be used to set the black level to black, not grey. The face of the tube has a grey color while it's off because that's how the surface of the tube looks - but that's not the result of emission from the tube, and even by the eighties tubes had dark anti-glare tinting for this. Unless you're shining a light on the tube, the black levels should be black.
Are we to say that the black level of an OLED display isn't black because external light can raise it through reflection?
> a "black" that is grey...
I hear this a lot. Why is an incorrectly biased monitor's bad black levels so widely considered the way it is supposed to be?
I won't vouch for the productivity savings from moving your hands less, since I think that's an absurd micro-optimization. Rather, I prefer it because I find it to be quick and accurate. After a week or so of getting used to it, when I first got a ThinkPad that only had it, it became the most natural and comfortable way of navigating. Not having to repeatedly paw at the bottom of the laptop and confort my hand to make a click (or deal with a single-finger click0 has been nice.
Mind you, I'm only speaking for the real ThinkPad trackpoints. The one in a Dell laptop I had for work was nowhere near as comfortable, and felt slippery and awkward.
I don't buy it as the main problem. 60fps is not asking for very much from a terminal emulator. VGA text modes can handle it, my old 486DX laptop can handle it, and XTerm can handle it (even fully software rendering everything to a buffer). It's possible core text is to blame, but this seems like an odd problem for an emulator to have in 2017.
* ADC enable register?
* Reference level set?
* Giving it ample time for a signal to settle?
* Are you testing with a known input source? I would test first with a variable PSU and verify with a voltmeter externally to eliminate a possible second confusion.
Zero. I use iTerm2 when I have to use a Mac, where I act as though it's Xterm. This is just out of the box behavior. Older versions had an adjustable refresh rate slider.
Is there still no way to make iTerm2 refresh faster? When doing quick scrolling or output, it's so noticeably choppy compared to Terminal.app, or even Xterm.
Context is everything. Profanity and hyperbole are as far from the aloof and stuffy professional language one uses with unfamiliar people or those in higher positions. It's something that becomes appropriate in personally close and comfortable quarters, and it can be a signal of comradery.
I like the principles behind its design, but not supporting scrollback and saying "that functionality should be provided by tmux or something similar" is baffling when it's done in the name of removing bloat and complexity.
Not everybody wishes to use a terminal multiplexer in all cases, either.
This is one effect I discovered when I was working on getting around the anti-piracy effects of an arcade game[1][2] in order to run it on similar hardware. I think it is a more clever copy defeat mechanism than stopping the game from booting.
A small micro or DSP processor can sit in the data path and solve this problem "in software, in hardware". It's unusual for software to be able to damage hardware for a consumer product.
It has always been possible to set those keys to default to F-key functions instead of media functions. The difference here is that the position may not be constant, and you can't feel with your fingers what you're over before you commit to activating the function, so you must look. In some contexts you can "get used to it", but this is a steeper uphill battle.