This was awesome. I feel like there's something lost when devices are locked down so tight that you can't hack on them at a low level (despite whatever risks present themselves).
I remember using Norton Disk Editor in the early 90's to fix directory entries (and occasionally break them!). I learned some fantastic lessons about backups and how to recover from mistakes.
This is the reason that I'm firmly stuck in the Android camp (on devices that I can root). I'm one a very, very small minority though.
I echo the sentiment but think Android doesn't go far enough; especially as apps migrate to relying on the closed/proprietary Google Play Services framework rather than vanilla Android.
I'm a big fan of this project, too. However I'm disappointed that the final price is going to come out to about $1200 http://neo900.org/estimate
There seems to be a fair amount of money and attention being invested in secure messaging, Mark Cuban's Cyber Dust, Blackphone, the various things by Moxie's Open Whisper Systems, etc. However the Neo900 as far as I know is the only solution offering a sandboxed baseband which is critical.
The Pyra Console [https://pyra-handheld.com/] has a sandboxed baseband (in that it's a seperate chip controlled by tty with no direct access to anything), and at 500 Euros to obsolete my netbook and my phone in one go, I will certainly be getting one. Pre-orders should be opening any day now.
Well, it runs stock Debian- so I imagine either the freesmartphone.org stack or oFono (both packaged), coupled with a relevant user interface. Really the UI is the hard bit, you can send and receive SMS just by cat-ing stuff to the tty device. Ubuntu has a lot of oFono-based UI stuff that can be stolen, though there's quite a few dependencies. Given how the Pandora community rallied around their platform, I've no doubt that we'll end up with a plug-and-play solution before long.
Also it'll probably be awkward for phone calls without some sort of headset (or just putting up with speakerphone all the time), but I hardly ever make calls anyway and it'll more than make up for that by being awesome at texting.
> especially as apps migrate to relying on the closed/proprietary Google Play Services framework rather than vanilla Android.
Blame the manufacturers, Google started moving more and more functionality into the services instead of the base OS partially because manufacturers were being so horrible about updating their phones. With functionality in the Services instead of the base OS they can update functions without manufactures deciding that it's not worth their time and holding things back.
Maybe it's that a minority of people currently see the user-modifiability of Android devices as an important benefit, not that a minority of smartphone users use Android.
> The cruel joke? In business mode, the picture was fine. The problem, whatever it was, manifested itself only in casual mode: the mode all the games used.
Curious terminology.
A high resolution text mode being stable, but a low-res graphics mode going haywire is almost certainly an issue with the display adapter and not the cathode ray tube.
I'd blace my bet on the deflection circuits (horizontal output transistor). I had similar problems with a more recent CRT, where the top right corner of the image started to shake frantically after a few minutes if you switched to high resolution modes.
EDIT: It seems I didn't catch any of the details right... the author's display was probably not multisync and developed problems in the low resolution mode. Oh well.
EGA was "dual-sync": in the 200 line modes, it ran at 15 kHz, whereas the 350 line modes ran at 23 kHz. While it's quite possible that the card had the problem, it's also possible that CRT was the problem. If the components drifted out of spec, it might no longer be able to correctly sync at 15 kHz, especially after warming up.
The problems being described sound like capacitors that have gone bad in the deflection circuitry. In the world of arcade machines, which run CRT monitors for hours on end every day, this failure mode is very common, and it shows as a "curl" on one or more sides of the display.
The tube itself probably wasn't the problem. Trouble with the electron guns usually means a dead tube, or a dead color. Problems related to sweep are outside the tube.
If he had a problem that appeared as overheating, the first thing to try is freeze spray. Find out what component is temperature sensitive. It's probably a capacitor.
It's not that hard to work on a CRT unit. You have to discharge the second anode voltage after powering off. (I was once trained to repair analog radios and TVs. This is now a totally useless skill.)
With the risk of going OT, I have an deal old monocrome monitor (Zenith ZVM-121) that died on me shortly after feeding it 220 V @ 60 Hz from a step-up transformer. How does one go about fixing such? Are there any place that will still repair them?
Attempting to take apart a TV set back in my childhood got me a lesson in that just because it's not plugged in, doesn't mean there is no electricity in it, those capacitors pack a punch one never forgets.
Many moons ago, my CRT monitor's red gun went kaput. It's easy to imagine what that must have looked like. Anything red appeared as, well, black. Everything else was a shade of cyan, blue, or green. The solution? A TSR, like in the article.
The TSR I wrote was simple in comparison: it constantly refreshed the palette. A palette entry with a red value greater than zero had its blue and green values increased accordingly. The red component was then zeroed out.
Necessity is a powerful impetus for spurring creativity in frugal college students.
This looks to be an earlier version, as it doesn't increase the blue and green values, but gives an idea of how it worked:
{$M 1024,0,0 } { 1K stack, no heap }
USES Crt, DOS;
CONST
MAX_COUNT = 384;
READ_PAL = $3C7;
WRIT_PAL = $3C8;
RED = 1;
GRN = 2;
BLU = 3;
VAR
OldIntVec : PROCEDURE;
NoRed : ARRAY[ RED..BLU, 0..255 ] OF BYTE;
Count : INTEGER;
Colour : BYTE;
PROCEDURE ReadPalette;
Begin
FOR Colour := 0 TO 255 DO
Begin
Port[ $3C7 ] := Colour;
NoRed[ RED, Colour ] := Port[ $3C9 ];
NoRed[ GRN, Colour ] := Port[ $3C9 ];
NoRed[ BLU, Colour ] := Port[ $3C9 ];
End;
End;
PROCEDURE ChngPalette;
Begin
FOR Colour := 0 TO 255 DO
IF NoRed[ RED, Colour ] <> 0 THEN
NoRed[ RED, Colour ] := 0;
End;
PROCEDURE WritePalette;
Begin
FOR Colour := 0 TO 255 DO
Begin
Port[ $3C8 ] := Colour;
Port[ $3C9 ] := NoRed[ RED, Colour ];
Port[ $3C9 ] := NoRed[ GRN, Colour ];
Port[ $3C9 ] := NoRed[ BLU, Colour ];
End;
End;
{$F+}
PROCEDURE NewTimer; INTERRUPT;
Begin
InLine( $9C ); { PUSHF -- Push flags }
OldIntVec;
IF Count = MAX_COUNT THEN
Begin
Count := 0;
ReadPalette;
ChngPalette;
WritePalette;
End
ELSE
INC( Count );
End;
{$F-}
BEGIN
Count := MAX_COUNT;
GetIntVec( $1C, @OldIntVec );
SetIntVec( $1C, Addr( NewTimer ) );
Keep( 0 );
END.
This might have been because your VGA card didn't use dual ported RAM. I don't think all cards used it since it was more expensive. The safest way to ensure you don't get snow across a wide variety of cards is to wait for the vertical retrace period before updating the palette registers. This way you update while the CRT beam is returning to the top of the screen, instead of while it is drawing in some random part of the screen and potentially reading from the palette while you are in the middle of updating it.
Also it's possible that the vertical retrace period isn't long enough to update the entire palette (i.e. you're still updating it and vertical retrace has finished, and the video card has already started redrawing the screen). This kind of depends on a number of factors - VLB/ISA/CPU speed/video card speed. You can work around it by updating smaller sections of the palette at a time (e.g. 32 colours at a time).
When I was a kid my family got a big, ancient second hand TV that had individual "cards" for the R G and B components. One day a diode on the red card blew out. I soldered in a replacement and the replacement diode lasted a couple minutes before also blowing out with a "bang!" Obviously a short somewhere else, but I didn't feel like troubleshooting it. What to do? Well these 3 cards all look pretty similar, I wonder what would happen if I swapped slots? Well, turns out it works! Just whatever color channel the bad card was in would go out. To get a "full" range of colors I swapped the red and green cards so that we'd have red and blue and it would be the green that was out. The result was surprisingly decent; you could tell something was "off" about the colors but not bad. However, after watching TV for a couple hours, when you looked away the real world would appear green!!
Why green though. Green is actually the color human eyes are most sensitive too. Blue is the color we see the worst, and usually given extra compression by image compression algorithms.
That is awesome. I can't believe how simple and straight forward that is. I never know you could write TSRs in Turbo Pascal. Imagine for a second pulling off a similar trick today on, let's say, a Mac. Plain hopeless.
I love having to hack a little bit to get a game running. (Once in a while, at least.)
I remember trying to get SimCity 3000 Unlimited to run on my Windows XP laptop. The laptop was 10 years old, and the game was even older, meant to run on Windows 98 if I remember right. The game refused to run in anything but 16 bit color mode, while 32 bit was the default on XP. I thought maybe I could fiddle with the compatibility options on the shortcut, but all it had was a checkbox to run in 8 bit mode. I could go into XP's graphics options and manually switch to 16 bit mode, but that would be annoying to do every time I wanted to play the game, and then undo it afterwards.
I thought maybe I could write a batch script to do it, but Windows XP didn't have anything built in to change the color mode from the command line. Thankfully there's a program out there called QRes that does just that. I wrote a script that switched the color mode to 16 bit, ran SimCity, then waited for it to terminate before switching back to 32 bit.
Setting that up was more fun that actually playing the game.
It resides in the system tray, remembers profiles, and it could be useful for someone else.
I will upload the gamma.exe file to github one of these days, or sooner, if anyone wants it.
The great and unexpected thing, it even works in Wine and changes the gamma ramp in Ubuntu. I use xgamma in the command line instead of my own tool, but I'm glad it works.
33 comments
[ 107 ms ] story [ 1939 ms ] threadI remember using Norton Disk Editor in the early 90's to fix directory entries (and occasionally break them!). I learned some fantastic lessons about backups and how to recover from mistakes.
This is the reason that I'm firmly stuck in the Android camp (on devices that I can root). I'm one a very, very small minority though.
I'm anxiously awaiting the https://neo900.org/
There seems to be a fair amount of money and attention being invested in secure messaging, Mark Cuban's Cyber Dust, Blackphone, the various things by Moxie's Open Whisper Systems, etc. However the Neo900 as far as I know is the only solution offering a sandboxed baseband which is critical.
Also it'll probably be awkward for phone calls without some sort of headset (or just putting up with speakerphone all the time), but I hardly ever make calls anyway and it'll more than make up for that by being awesome at texting.
Blame the manufacturers, Google started moving more and more functionality into the services instead of the base OS partially because manufacturers were being so horrible about updating their phones. With functionality in the Services instead of the base OS they can update functions without manufactures deciding that it's not worth their time and holding things back.
How do you figure you're a minority? Android has the highest market share of any smartphone OS in most parts of the world, developed or otherwise.
Curious terminology.
A high resolution text mode being stable, but a low-res graphics mode going haywire is almost certainly an issue with the display adapter and not the cathode ray tube.
EDIT: It seems I didn't catch any of the details right... the author's display was probably not multisync and developed problems in the low resolution mode. Oh well.
I have never seen those circuits so can't comment on what could be wrong, but if cooling the monitor helped I think it wasn't EGA's fault.
Too bad the OP didn't keep this machine.
If he had a problem that appeared as overheating, the first thing to try is freeze spray. Find out what component is temperature sensitive. It's probably a capacitor.
It's not that hard to work on a CRT unit. You have to discharge the second anode voltage after powering off. (I was once trained to repair analog radios and TVs. This is now a totally useless skill.)
I instinctively went for the shift keys fractions of a second after seeing that Sidekick menu.
The TSR I wrote was simple in comparison: it constantly refreshed the palette. A palette entry with a red value greater than zero had its blue and green values increased accordingly. The red component was then zeroed out.
Necessity is a powerful impetus for spurring creativity in frugal college students.
This looks to be an earlier version, as it doesn't increase the blue and green values, but gives an idea of how it worked:
But in all the VGA cards I had, updating the palette caused a little bit of snow to appear onscreen. Didn't you get the same?
Also it's possible that the vertical retrace period isn't long enough to update the entire palette (i.e. you're still updating it and vertical retrace has finished, and the video card has already started redrawing the screen). This kind of depends on a number of factors - VLB/ISA/CPU speed/video card speed. You can work around it by updating smaller sections of the palette at a time (e.g. 32 colours at a time).
I remember trying to get SimCity 3000 Unlimited to run on my Windows XP laptop. The laptop was 10 years old, and the game was even older, meant to run on Windows 98 if I remember right. The game refused to run in anything but 16 bit color mode, while 32 bit was the default on XP. I thought maybe I could fiddle with the compatibility options on the shortcut, but all it had was a checkbox to run in 8 bit mode. I could go into XP's graphics options and manually switch to 16 bit mode, but that would be annoying to do every time I wanted to play the game, and then undo it afterwards.
I thought maybe I could write a batch script to do it, but Windows XP didn't have anything built in to change the color mode from the command line. Thankfully there's a program out there called QRes that does just that. I wrote a script that switched the color mode to 16 bit, ran SimCity, then waited for it to terminate before switching back to 32 bit.
Setting that up was more fun that actually playing the game.
Likely burned out after many years of use.
This is the tool I made to make it brighter:
https://github.com/macondobits/gamma
It resides in the system tray, remembers profiles, and it could be useful for someone else.
I will upload the gamma.exe file to github one of these days, or sooner, if anyone wants it.
The great and unexpected thing, it even works in Wine and changes the gamma ramp in Ubuntu. I use xgamma in the command line instead of my own tool, but I'm glad it works.