"DoN. Nichols" wrote in message
...
On 2017-03-19, Jim Wilkins wrote:
"DoN. Nichols" wrote in message
...
On 2017-03-18, Jim Wilkins wrote:
"DoN. Nichols" wrote in message
...
On 2017-03-17, Jim Wilkins wrote:
[ ... ]
Better to go to memory-mapped devices for I/O if you can.
The 8080 and all its decendants have a separate I/O address space for
the physical hardware registers, which QBasic can directly read and
write.
http://stanislavs.org/helppc/bios_data_area.html
For instance address 40:08 normally holds a pointer to 03F8, the LPT1
port data bit register. The next addresses are the control bit outputs
and the status bit inputs.
That's how the parallel port can drive custom external hardware, but
it works well without OS interference only in DOS. Still, an LCD
screen and keyboard, a GHz CPU and files on a hard drive is waaay
beyond an Arduino.
COM1 and COM2 are similarly accessible at bit-banging level. Plug in a
serial-interfaced DVM and your program can measure voltage.
40:17 and 40:18 show the current up or pressed state of the
non-printing control keys. I checked them when my programs asked the
user to "press any key" and flashed the screen alarmingly when some
joker pressed Shift.
The Mac was difficult because plug-ins are supposed to have a
driver
in ROM at the top of the slot's address block, written by an Apple
Certified Programmer. When I gave him the simple register model for
my
16 bit A/D converter he quoted 3 months to write it. Instead I left
the card invisible and generated four lines of 68000 machine
language
in LabVIEW to select a MUX channel and read the data when ready.
:-)
Was this after the time the Mac moved to full 32-bit code? I
seem to remember stories of programmers (against the rules) using
the
upper 8 bits of addresses as data/flag storage, which caused serious
problems when the full 32-bit addressing was enabled.
https://en.wikipedia.org/wiki/NuBus
"In order to select the proper device driver, NuBus included an ID
scheme that allowed the cards to identify themselves to the host
computer during startup."
"On the downside, while this flexibility made NuBus much simpler for
the user and device driver authors, it made things more difficult for
the designers of the cards themselves."
Unless we dodged the rules, of course. That may have been why they
couldn't just buy a NuBus A/D converter card from National
Instruments. I wasn't otherwise involved in the project, a 6-port
microwave network analyzer.
The 16 bit A/D worked surprisingly well inside the noisy Mac II
chassis. The least significant bit bounced a little, that's all. I
ran the bus power through high quality Analog Devices DC-DC converters
to quiet it. I tried testing its dynamic response as an audio spectrum
analyzer but only found that the Mac sucks eggs as a real-time data
acquisition system. I had much better luck later generating accurate
timing on a PC running DOS.
But in the days before that, at the Army R&D lab where I worked,
you could not purchase anything called a "computer" for use in the
lab.
(The exception was the one IBM 370.) So, to get a computer, you had
to
call it something like "an instrument controller". :-)
Add LabVIEW and a GPIB card and that's exactly what it is.
My task at Unitrode was to turn any customer's lab computer into an
"instrument controller" to run application boards for new ICs without
modifying it. We did it with an I2C bus adapter that plugged into the
printer port and a floppy or flash drive that boots DOS. I bought
Visual Basic and then discovered it won't talk to the I/O address
space.
-jsw