A chip too far? Where is your solution Mr Larkin?

Note that there are now two models of the Kill-a-watt power meter. The original does not have a backup battery and will lose it's accumulated totals if the power is unterrupted. The Kill-A-Watt EZ (about $50) has a backup battery and will display estimated costs in dollars.

"Joel Koltner" wrote in news:4QZqk.34235$ snipped-for-privacy@en-nntp-09.dc.easynews.com:

IIRC, Fiskars tools are still made in Finland. They last a long time, are more robust, operate smoothly, and hold their edge. At least around here, they actually aren't all that much more expensive - pruners, maybe $15-$17 as opposed to $12.

Guy Macon wrote in news:l snipped-for-privacy@giganews.com:

Well, so far, KillAWatt si batting 1000 :) THat's good to know, thanks!

- Kris

The only wish I have for it is a backlight for the display. Well, that and if it didn't cover both receptacles of a standard duplex outlet. Both issues are solved by using a short, heavy gauge extension cord for a pigtail. With most residential outlets down near the floor, that pigtail comes in really handy ...

I wonder if anyone still uses the analog wattmeters with a current coil and a "potential" coil?

I'm guessing probably not, with all the digital ones around.

Cheers! Rich

Hi! If all you want is to run a real CP/M (not emulated) you could build the N8VEM Z80 home brew computer and run CP/M 2.2 from RAM and ROM drives.

Use the serial port to transfer your CP/M program to the RAM drive and run it. People are doing this often and today. Not many new computers are still running real CP/M although all recent computers can run CP/M on Z80 emulations.

If you need special peripherals, you can build them yourself and place them on the standardized ECB-bus backplane.

Thanks!

Andrew Lynch

You have my sympathy. ;-)

There are some things you can't buy homegrown, so if you are forced to buy Chinese, it might as well be at the lowest price. Of course it helps a lot if you know what a quality tool looks like. Some imports cause flashbacks to the early '60s and the crap Japan exported. A lot of it broke, just trying to get it out of the package. :(

ut

Here are some examples

Thanks!

Andrew Lynch

If you're doing that, you'd better also add a column for the power these applications require. All those cycles aren't free (neither are those to JohnL's checking).

Bloated => buggy.

Yep, there pretty much has to be. More code = more bugs.

I'm now tweaking a PBCC program that displays/tests/calibrates one of my little serial waveform generators. It talks RS-232 or Ethernet to the box, with a console-mode user interface. Easy, works great: 5 different screens, HELP, all the calibration communications and math. No includes, headers, libraries, DLLs, any of that nonsense. 760 lines of code (counting comments and whitespace), 47K exe file. Compile time is 0.1 seconds.

John

"The preferable model, and easiest for a mere human coder to deal with, is one program (thread) on one processor. My desktop has 1,095 active threads under Vista at this moment. It took Microsoft more labor to build Vista to manage those threads than the Apollo moon project required. With lots of (X86-compatible) processors, I like the idea of the OS handling the job more than expecting commercial apps to do the job right. The past five year history of PC threading/multi-core is an example of the current way that?s not moving fast enough. 2. Use the terrascale processor pool for general purpose, I/O, comms, and graphics processing. If there aren?t enough active threads, put the processors to sleep.

The easiest set of applications to harness terrascale processors are commercial server applications like databases, web servers, and apps that already are well-threaded. That suggests Xeon deserves terrascale first. However, a couple of decades of systems engineering have gone into excruciatingly complex code to share a small number of cores. If the OS can give every thread its own (virtual) memory, OS, and processor resources, the need for processor contention management gets much simpler."

John

What's happening is that features and functions get added faster than bugs get fixed. The inevitable trend is toward feature infested and bloated software, with a chronic bug problem. Also, there's market for debugged software, while there's a much larger market for features and functions.

There's also an incentive to *NOT* fix the bugs. Upgrades are the major revenue stream for any OS or software company. Users often buy upgrades not for the new features and functions, but in the vain hope that perhaps some of the bugs may have been fixed. If a company ever released a bug free product, the sales of upgrades would cease.

You think that's insane? You haven't even analyzed it on modern hardware. The FAR CALLs wreak havoc on cache, as far as I can tell. QBasic programs typically run at about bus speed. Relative to core clock frequency, QBasic is approximately 20 times slower than equivalent assembly code on the 8086, but more like 4000 times slower than assembly, without far calls, that runs inside the cache, if not inside just the instruction pipeline itself. So relatively speaking, QB runs 20 times *slower* on modern hardware.

Comparing QBasic to assembly programs on both machines, the difference in speed, even the palpable relative speediness of QBasic on the XT machine, is amazing.

Tim

I've been programming in uppercase since before there was a lowercase.

.SBTTL COMMAND INTERPRETER

; A COMMAND LINE CAN CONTAIN ANY NUMBER OF COMMANDS, SEPARATED ; BY SEMICOLONS. THE LINE IS TERMINATED BY A NULL. SERIAL INPUT ; CHARACTERS MUST BE FIRST EDITED THROUGH THE 'CROOK' TABLE.

; EACH COMMAND HAS A MAIN TOKEN, FOLLOWED BY EITHER... ; ; TERMINATOR: IT'S A SIMPLE ACTION OR INQUIRY STatus ; A LETTER: WE ASSUME A 2-LETTER SECOND TOKEN LOad SInewave ; A NUMBER: A NUMERIC ARG 3Set 4096

; A TOKEN IS A STRING OF AT LEAST 2 LETTERS. ONLY THE FIRST TWO MATTER. ; THIS EDITION ALSO ALLOWS COMMANDS OF THE FORM 2Set R3

; ENTER HERE WITH A6 AIMING AT A LINE TO EXECUTE. IT MAY ; BE ANY LENGTH BUT *MUST* HAVE THE NULL TERMINATOR.

; WE GENERATE THE REPLY STRING DIRECTLY TO THE SPI TRANSMITTER, ; WITH BASIC RULES... ; ; A COMMAND GENERATES REQUESTED DATA, "OK", OR "??" ; SEMICOLON ECHOES AS SEMICOLON ; THE FINAL NULL ECHOES AS CR/LF ; IF ANY COMMAND THROWS THE "??" ERROR, WE TERMINATE.

; 'SCOUT' AND 'LINUX' OUTPUT CHARS AND LINES. IF 'QUIET' IS SET, WE ; WILL *NOT* GENERATE SERIAL REPLIES. THIS LETS US SILENTLY EXECUTE ; STRINGS FROM EPROM IF WE WANT TO, DEMOS FOR EXAMPLE.

; SUB 'EVAL' SETS CC'S BASED ON THE CHAR AIMED AT BY A6... ; ; Z NUL, END OF COMMAND LINE BEQ ; N NUMBER BMI ; V SEMICOLON COMMAND DELIMITER BVS ; C LETTER BCS

; A0 AIMS AT TEXT TO SEND ; A2 SCANS COMMAND TABLE ; A3 POINTS TO COMMAND PARAM ; A6 AIMS INTO TEXT BEING PARSED

moment. It took Microsoft more labor to build Vista to manage those threads than the Apollo moon project required."

You might be interested in my comments about the engineering behind the Apollo moon project. It's at

(Scroll down part the sections on Thomas Edison and WWII Liberty Ships).

I noticed that James is writing about QuickBasic and Tim replied with comments about QBasic. Are you aware that those are not the same thing?

Please remind me of the arithmetic condition codes of the M68k family. Its decades since I last used 68k. Incidentally it seems to spend a heck of a lot of time updating the error flags considering that it cannot exit this loop unless a is received.

I presume some other thread monitors FLAGS in realtime? If so then there is a small risk that RED could still be zero whilst FLAGS has been seen non-zero by the external error monitoring thread.

Also on coding style:

BCC.S NOPUPPY JSR POWER.W ; CHECK THE POWER (SLOPPY = 0) NOPUPPY: BVS.S NOZERO JSR AZERO.W ; REZERO THE DAC (SLOPPY = 0x8000)

NOZERO: MERLIN:

Would be shorter, clearer and only slightly slower than the code you are using. And FLAGS would be updated consistently every time around the loop. Incidentally why the cryptic label names?

BTW Modula2 could do this sort of low level stuff with relative ease and be a lot more readable. It has enumerated SETs (packed bits) which can be mapped onto hardware registers as required.

PS: TYPING ALL IN CAPITALS IS PAINFUL ON THE EYES THESE DAYS

Regards, Martin Brown

Yes, that claim was silly. It cost about $150 million to write NT as of its first public release. I can't imagine that Vista cost more than a billion or so.

John

C V N and Z, are respectively carry overflow negative and zero. But my BSFLAG etc are word variables, not cc bits. Each partial-flag word is zero or has its specific flag bit set in the proper position, so it's easy to build the composite FLAGS word without a lot of testing and shifting.

It's waiting for a serial command string to be ready to parse and execute, so it has nothing else to do. The serial input interrupt service routine will build a string and set RXDONE, and there's a periodic interrupt routine blinking led's and maintaining some counters and such.

No, not that it would matter. There are no threads, just this main loop and the two isr's.

Yes, but it would be incorrect. The state of the overflow flag wouldn't survive the execution of the POWER subroutine, so the adc autozero routine would be run randomly, maybe never.

That doesn't matter. They are being crunched too often anyhow. The paths here minimize serial command execution latency. Minimizing worst-case run time is different from optimizing CPU usage in the classic way.

Incidentally why the cryptic label names?

It's just a local label, and it's in plain sight.

My listings are paged and formatted to print on 11x17 fanfold paper, which I print on an NEC dot matrix printer. It's easier to read that in uppercase. Before I dare to run a program, I *read* it carefully several times, and tweak it for logical and visual perfection. The result is correct comments, clean structure, few initial bugs, and usually zero shipped bugs.

I also time interesting routines with an oscilloscope and note their runtimes in the source code.

John