Silly person!

Use UMBPCI instead of EMM386, and use CTMOUSE for the mouse driver.

(assuming your modern system still knows how to play right in real mode anyway. Many modern chipsets have problems with ISA style DMAs, which makes using the hardware UMBs free with UMBPCI can have unpredictable results. For such systems, you are stuck with EMM386 doing protected mode memory reassignments, and gobbling down a big chunk of conventional. Blech.)

Really, there are much better memory managers that came about since the DOS days (FreeDOS is still a living project for devices that simply must run DOS. Industrial vinyl cutters and the like come to mind), and you can reasonably get over 568k conventional free with little hassle.

Whoo hoo!

You know, pretty much the only reason why HP makes these (or orders them from actual manufacturers and brands them) is because there is obscene demand for them for CAD/CAM workstations. Many CAM suites use combinations of button clicks to maneuver in the 3D design space, including the use of the middle button.

Dassault Systemes CATIA and Siemens Unigraphics come instantly to mind.

HP has an industrial workstation lineup that they offer to small and midsize companies that need fairly high end engineering workstations, and these mice are a usual staple.

No, the crazy clicking involved means a scroll wheel mouse is just not up to the challenge.

(1st hand experience.)

At my last job, I literally wore one of these mice out. Guess which button died first? The middle one.

I am VERY glad that these are available again.

I said "in theory". The devil's in the details.

still, I wonder how far one could get coopting both the EXT connector on the bottom, and the cartridge slot. Use the EXT connecter for IO (including video and SPU channel) and use the cartridge slot for the snes-side program code, ram access, and return communications. A hardware mpeg decoder in the cartridge slot, with the mpeg stream coming in on the ext port or something maybe. Given that the screen resolution isnt so big to begin with, a few hundred kbps would be sufficient. (600 or so, iirc.)

Why somebody would go through all the effort is another matter entirely-- the point was that in theory, one could do this on a cartridge, and never hope to do so over USB.

Clearly, you do not understand the implications of what I said.

USB storage requires an entire operating system to even access. It requires a kernel OS process, a driver for the specific USB chipset attached to the system, and yet another driver for the filesystem stored on the device. In addition to this, it has to have multitasking capabilities to switch between reading and decoding the data on the device, and executing the read program code.

In stark contrast, a game cartridge requires no OS at all. The CPU simply jumps to the address location where the cartridge's ROM chip is logically assigned, and the CPU treats it exactly like it was fetching from RAM. The game is the ONLY thing running.

The better comparison would be "USB is the new data cassette!"

You can put all kinds of crazy things inside a cartridge that you simply could never put inside a USB stick. Things like additional RAM that runs at full speed, Whole new CPUs, an additional peripheral bus connector-- you name it.

In theory, a (crazy) person could take an old SNES console, and with a very purpose built cartridge, turn it into a playstation.

Really, the comparison you are drawing does not really reflect what a cartridge actually is.

And apparently the site I linked does not like hard links. Meh. Whatever. Just image search for "2600 cartridge interior", you will find it.

Not exactly. A flashdrive is a serial bus peripheral that communicates using an encoded format.

A cartridge is typically little more than an exposed parallel logic bus that directly maps to the console's main memory. (Atari 2600 carts were literally a ROM chip, with its leads exposed on the card edge. Nothing else. http://www.hardwaresecrets.com... )

NES and SNES carts had special purpose chips on them to help page the address of the ROM inside the main CPU's memory space, and even a few special co-processors on occasion, but were still just a direct tie-in to the memory bus.

A DIMM and a cartridge have more in common than a USB stick does with a cartridge.

The theme is there, but it isn't so "In your face", no. When you think about it, the futuristic technology required didn't exist yet in the TOS timeline. They had food slots, but not "Hey bro, I can make any fucking thing you can fit in my compartment!" omni-fabrication like they do in TNG with pattern replicators. This meant that there was still some value for physical possessions and the like. The "Full on" utopia happens in TNG.

However, the underpinnings of that future utopia are present in TOS-- In several episodes the race and gender of Uhura get pulled up, and the crew has to calmly explain how such distinctions are handled in their century.

https://www.youtube.com/watch?...
(Yes-- that is abaham lincoln-- or rather, a facsimile of lincoln made by aliens)

There are of course, many others where this issue was brought up, and the "Utopian future" vibe was strong.

It was very much a part of TOS.

As for exploding consoles-- I think that was more a gimmick because the viewing audience would not understand "Broken console" without smoke and sparks. Even today, think of the difficulty IT people have explaining things like "Bad capacitors" to non-technical people. ("But it works just fine, then starts to act funny! Can't you fix it!?")-- That is still just a diversion from the original statement though. Star Trek was envisioned as a vehicle for an optimistic future. That vehicle used cheap gimmicks to accomplish that goal, but it still focused on that goal. The new reboot keeps the gimmicks, but sheds that goal.

Because it sheds the ideological purpose that startrek was created for.

Startrek was by design, created to illustrate a damned-near utopian future where all races and genders work together as equals, and accomplish a society that all can be proud of.

In fact, Johnathan Frakes shares this little pearl of wisdom on the subject.

https://www.youtube.com/watch?...

It is for this reason that I do not like the startrek reboot. It has shed its soul, to capitulate to the american audience's desire for boobies and explosions. It is not startrek.

That's unfortunate... I can see why it would be desirable by the manufacturer and dealer, (as it would enable quite a few shady practices by both), but I question how stable EEPROM is compared to PROM in the hazardous environment under the hood or dash. (I know some modern systems are installed under the center console between the front seats, and some are installed under the passenger or driver seat, but this is still a problematical location in terms of operating environment. Still has large fluctuations in ambient temperature and issues with moisture and corrosion.)

I have seen ODBII dongles made specifically for hotrodding that contain new fuel mix tables and timing data for the ignition control system, but havent really seen kits to completely re-flash the ICS's computer.

Guess you learn something new every day.

No need to do such extreme damage, when the same effect can be achieved with a simple fuse on the positive voltage line of the port. Suspicious activity? Burn the fuse-- BAM-- port is dead, but easily fixed.

However, this would require a "smart" component inside the dash, between the actual ignition control system/ACS system, and the ODBII port interface. Such a device would need to have a reference pattern to check current communications against, and would need some level of processing capacity to compare realtime engine diagnostic data and bus activity against the reference. (Does not need to be fancy here, but this does imply the ability to program a new reference pattern later, especially if the system is fully adaptive to changing engine conditions over time.)

This then places some significant implementation considerations on the vehicle manufacturer-- this device has to somehow be able to be field-reset at a dealership if it gets confused after having the engine serviced, and also needs to have nothing but read-only access to the engine's control system. The only thing it should have "write" access to should be the fuse. (And maybe an indicator lamp)

However, given the less than spectacular implementations of integrated devices in modern vehicles (in terms of security, and security oriented design/implementation) I question if such a device would be properly implemented.

I get the sneaky suspicion that the automaker would be ... "tempted" ... by dealerships and other retailers in the market to integrate lojack functionalty into the security device, thus making it itself into the target of exploits. (Otherwise, the purposeful activation of the intrusion failsafe would render actual lojacks incapable of stopping cars, by disabling the communication bus. This means removing the fuse would essentially disable such countermeasures.) This would then make "remove the dongle" no longer an option.

When presented with a choice between "properly implemented security" and "Pressure from their customers" (Auto manufacturers RARELY, if ever, sell directly to the public. THEIR customers are the dealerships.) , I expect automakers will choose to placate their customers every single time.

except that the firmware in the ignition control system of the vehicle is written on actual PROM chips, not EEPROM chips, because they have to operate in a hazardous environment. (Temperature extremes, moisture intrusion, dirt, corrosion, etc.) Voltage spikes from slowly decaying wiring, or other sources of irregularity can damage an EEPROM's contents, where a PROM will just burp a little, then be fine after the irregularity. (assuming it isnt a very large spike that can kill silicon anyway)

This means that the ODB2 interface (the little connector under the dash) can at best, only be used to circumvent proper engine function when another device is attached to the bus that has such programmability.

There most certainly ARE such devices on the market, such as the lojack type devices used to prevent vehicle theft on vehicles that arent paid off, etc-- used by used car lots and the like, but these are purposefully installed in a fashion that makes physical removal of the device difficult without the correct tools/equipment. The vehicle runs just fine without such devices attached.

In the case of one of these really shitty dongles, physical removal of the dongle should suffice. The vehicle would then operate with no outside manipulation of its ignition control system. They try ransoming the vehicle, just pull the dongle.

The bigger concern is possible malicious actions, such as "Murder by remote" type situations. The vehicle has such an exploitable device (with its lack of challenges against the network it is communicating with), and a murderer chooses to exploit this to make the ignition control system refuse to fire any of the spark plugs, or to drive any of the fuel injectors. The vehicle stalls while driving 70mph (or faster) on a crowded highway during a lane-change, or while passing. Perhaps the antilock brakes (automatic skid control systems have control over braking) are exploited, and the brakes on one side of the vehicle slam down while doing said 70mph, and the vehicle spins out of control or flips over.

Considering that there is absolutely NO protection here, (No challenge/response, no encryption, no verification of remote network authenticity, etc.) there is definitely room in the criminal underworld for such a remote exploit. Professional hitmen, (and government agencies) would love such a toy.

I mention this possible application, because the obvious one of insurance fraud has already been brought up a few times.

Still, the solution is the same. Physical removal of the dongle solves all the problems.

The problem with the latter approach, is that programmers spend time when they arent working, thinking about the problem they are being paid to work on when they are working.

EG, they may have the sudden epiphany while playing super mario brothers, that they have failed to have while sititng in their cublcle, trying so very hard to push that solution out under great duress from their manager.

Or, as archimedes had his epiphanies-- In the tub.

This is not a new thing, and creative problem solving REQUIRES downtime to be effective. The people that insist "You arent applying yourself all the way, therefor I will ding you on your reviews!" are a problem, not a solution.

Usually with the closed source applications, you send in the bug report, and it appears to vanish from your end. There is no feedback from the bug treacking team. There is no update on if the issue is pending more data (which you could supply if they ask. Clearly the bug was severe enough to warrant a report, so clearly you must run into it fairly frequently-- but no-- no access to the bug tracker, so you dont see the comments about "Cant reproduce! closing!" getting thrown about in there) or even if the bug gets closed with "Working as expected, wont fix"

Nope, you get a "Send us a bug report! Fill out this window (which has a max size text field, so keep it contrite!) and hit submit to send it on its way to digital purgatory!

You dont get informed when a fix will be incorporated, you dont get informed of any work arounds. Nada.

Compare that with FOSS bug trackers, and it is night and day.

Yes. I KNOW.

If you had READ THE WHOLE THING, you would have seen the parenthetical comment at the end about how the micro cell could be at an event!)

For fuck's sake, this is the last comment like this I am going to respond to!

All you need is a few kilobytes of storage. Most phones have this already in the underlying hardware for use with things like the region ID and the like.

Seriously, each entry in the blacklist needs only the UUID of the blacklisted tower. That's it. Hell, this could live in the damned SIM card.

Everything else can live in the app.