25 Feb
2008
25 Feb
'08
9:58 a.m.
I am in the process of rebuilding an IMSAI 8080 and am using my Mac Pro as a
dumb terminal. I have it all to the point where I can type a character and
see the ascii appear on the front panel. What I need to do is write a
simple 1st stage loader that will take the HEX output from the ASM80
assembler, send it over the serial connection and put it in memory. This
way I can write a more sophisticated loader and not have to key it in by
hand.
The question is, what is the algorithm, in assembly language, for converting
an ascii character to its binary equivalent. By this, I mean converting an
'a' to 1010, not 041H which is the ascii value. I remember writing such a
thing 30 years ago but simply cannot get my head around it now.
The algorithm has to deal with taking an ascii string like
AF67DBFF6FF9AF81C2130053DBFF5FAAC2210039D20600780747D3FFAF4 and converting
each ascii character into the binary value it represents. The sting above
would convert, one character at a time, to:
1010
1111
0110
0111
1101
well, you get the point...It has to work only for 0-9 and A-F which should
make it easier.
Anyone out there remember how to do this?
Jeff Erwin
25 Feb
25 Feb
12:04 p.m.
On Feb 25, 2008, at 9:58 AM, Jeff Erwin wrote:
I am in the process of rebuilding an IMSAI 8080 and am
using my Mac
Pro as a
dumb terminal. I have it all to the point where I can type a
character and
see the ascii appear on the front panel. What I need to do is write a
simple 1st stage loader that will take the HEX output from the ASM80
assembler, send it over the serial connection and put it in memory.
This
way I can write a more sophisticated loader and not have to key it
in by
hand.
The question is, what is the algorithm, in assembly language, for
converting
an ascii character to its binary equivalent. By this, I mean
converting an
'a' to 1010, not 041H which is the ascii value. I remember writing
such a
thing 30 years ago but simply cannot get my head around it now.
The algorithm has to deal with taking an ascii string like
AF67DBFF6FF9AF81C2130053DBFF5FAAC2210039D20600780747D3FFAF4 and
converting
each ascii character into the binary value it represents. The sting
above
would convert, one character at a time, to:
1010
1111
0110
0111
1101
well, you get the point...It has to work only for 0-9 and A-F which
should
make it easier.
Anyone out there remember how to do this?
Jeff Erwin
I just went through this same exercise last week. Here is a link to
the source code of IMSAI's original paper tape loader which does
exactly what you're looking for. You will probably have to modify it
to suit your particular serial interface and memory map.
paper tape loader.asm
As an aside, here is a video of my IMSAI using this loader to bring up
a copy of Altair 4K Basic.
http://www.youtube.com/watch?v=ADplHpk33yY
-Mardy
12:23 p.m.
On Mon, Feb 25, 2008 at 9:04 AM, Marden P. Marshall <mardy at voysys.com> wrote:
As an aside, here is a video of my IMSAI using this loader to bring up
a copy of Altair 4K Basic.
http://www.youtube.com/watch?v=ADplHpk33yY
-Mardy
Kinda OT, but what's the name of that terminal sitting on top of your
IMSAI? I see terminals that look just like that EVERYWHERE but I
haven't found out what the name is. They're really cool looking, wish
I could find one...
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
12:43 p.m.
On Feb 25, 2008, at 12:23 PM, John Floren wrote:
On Mon, Feb 25, 2008 at 9:04 AM, Marden P. Marshall
<mardy at voysys.com> wrote:
It's a Lear-Siegler ADM-3A. Google it and you'll find all kinds of
information on it. They pop up on eBay every once in a while.
-Mardy
As an aside, here is a video of my IMSAI using this loader to bring
up
a copy of Altair 4K Basic.
http://www.youtube.com/watch?v=ADplHpk33yY
-Mardy
Kinda OT, but what's the name of that terminal sitting on top of your
IMSAI? I see terminals that look just like that EVERYWHERE but I
haven't found out what the name is. They're really cool looking, wish
I could find one...
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
1:28 p.m.
John Floren wrote:
On Mon, Feb 25, 2008 at 9:04 AM, Marden P. Marshall
<mardy at voysys.com> wrote:
Not OT at all. That's a Lear-Siegler ADM3a
Peace... Sridhar
As an aside, here is a video of my IMSAI using
this loader to bring up
a copy of Altair 4K Basic.
http://www.youtube.com/watch?v=ADplHpk33yY
-Mardy
Kinda OT, but what's the name of that terminal sitting on top of your
IMSAI? I see terminals that look just like that EVERYWHERE but I
haven't found out what the name is. They're really cool looking, wish
I could find one... 
6:50 p.m.
On 2/25/08 12:04 PM, "Marden P. Marshall" <mardy at voysys.com> wrote:
I just went through this same exercise last week. Here is a link to
the source code of IMSAI's original paper tape loader which does
exactly what you're looking for. You will probably have to modify it
to suit your particular serial interface and memory map.
paper tape loader.asm
As an aside, here is a video of my IMSAI using this loader to bring up
a copy of Altair 4K Basic.
http://www.youtube.com/watch?v=ADplHpk33yY
-Mardy
I actually used a version of Dave Dunfield's monitor which includes a hex
upload module. A few of the monitors I have from different sources have hex
upload capabilities.
That's obviously a bit more involved than the paper tape loader but is a
bridge to other things.
Rich
--
Rich Cini
Collector of Classic Computers
Build Master and lead engineer, Altair32 Emulator
http://www.altair32.com
http://www.classiccmp.org/cini
9:40 p.m.
On Mon, 25 Feb 2008, Richard A. Cini wrote:
I actually used a version of Dave Dunfield's
monitor which includes a hex
upload module. A few of the monitors I have from different sources have hex
upload capabilities.
That's obviously a bit more involved than the paper tape loader but is a
bridge to other things.
This paper tape fiddling made me wonder if anyone ever made a cassette
tape interface that emitted RS232 signals and looked to the computer like
a paper tape reader/writer.
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
9:53 p.m.
On 2/25/08 9:40 PM, "David Griffith" <dgriffi at cs.csubak.edu> wrote:
This paper tape fiddling made me wonder if anyone ever
made a cassette
tape interface that emitted RS232 signals and looked to the computer like
a paper tape reader/writer.
Isn't that what the 88-ACR board did? I'd have to pull the book, but IIRC,
it was an audio processing board connected to an SIO board. That's why the
MITS Absolute Tape Format worked -- the format of the paper tape and
cassette were the same but the media was different.
Rich
--
Rich Cini
Collector of Classic Computers
Build Master and lead engineer, Altair32 Emulator
http://www.altair32.com
http://www.classiccmp.org/cini
9:59 p.m.
On Feb 25, 2008, at 9:53 PM, Richard A. Cini wrote:
On 2/25/08 9:40 PM, "David Griffith" <dgriffi at cs.csubak.edu> wrote:
Yes that is basically what the Altair 88-ACR card was. There were two
parts to it, the main board that was a single channel serial card,
minus the RS232 line driver, and a daughter card which was basically a
FSK modem.
-Mardy
This paper tape fiddling made me wonder if anyone
ever made a
cassette
tape interface that emitted RS232 signals and looked to the
computer like
a paper tape reader/writer.
Isn't that what the 88-ACR board did? I'd have to pull the book, but
IIRC,
it was an audio processing board connected to an SIO board. That's
why the
MITS Absolute Tape Format worked -- the format of the paper tape and
cassette were the same but the media was different.
Rich
--
Rich Cini
Collector of Classic Computers
Build Master and lead engineer, Altair32 Emulator
http://www.altair32.com
http://www.classiccmp.org/cini
26 Feb
26 Feb
12:10 a.m.
From: dgriffi at cs.csubak.edu
On Mon, 25 Feb 2008, Richard A. Cini wrote:
Hi
On my Poly88, the same serial chip is used for both the cassette and
the serial port. The cassette used the serial chip in a synchronous
mode and the serial in async.
I made some minor changes to the setup and use most of the cassette
code to save tape programs to the PC through the serial port.
Other than being ascync, the data looks just like the cassette data.
Dwight
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
I actually used a version of Dave Dunfield's
monitor which includes a hex
upload module. A few of the monitors I have from different sources have hex
upload capabilities.
That's obviously a bit more involved than the paper tape loader but is a
bridge to other things.
This paper tape fiddling made me wonder if anyone ever made a cassette
tape interface that emitted RS232 signals and looked to the computer like
a paper tape reader/writer.
12:10 a.m.
From: dgriffi at cs.csubak.edu
On Mon, 25 Feb 2008, Richard A. Cini wrote:
Hi
On my Poly88, the same serial chip is used for both the cassette and
the serial port. The cassette used the serial chip in a synchronous
mode and the serial in async.
I made some minor changes to the setup and use most of the cassette
code to save tape programs to the PC through the serial port.
Other than being ascync, the data looks just like the cassette data.
Dwight
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging.?You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
I actually used a version of Dave Dunfield's
monitor which includes a hex
upload module. A few of the monitors I have from different sources have hex
upload capabilities.
That's obviously a bit more involved than the paper tape loader but is a
bridge to other things.
This paper tape fiddling made me wonder if anyone ever made a cassette
tape interface that emitted RS232 signals and looked to the computer like
a paper tape reader/writer.
6:20 a.m.
This paper tape fiddling made me wonder if anyone ever
made a cassette
tape interface that emitted RS232 signals and looked to the computer like
a paper tape reader/writer.
Hmmm....You are a bad guy, David! Now I'll have to think about it :o)
Easy path: two tone detectors, going to a microcontroller who store the
data read from the tape and send it in RS232 way. A very simple AVR
microcontroller can do that ;o)
2:57 p.m.
Easy path: two tone detectors, going to a
microcontroller who store the
data read from the tape and send it in RS232 way. A very simple AVR
microcontroller can do that ;o)
Argh!. I grew up learning to design solutions to problems, rather than
throw microcontrollers at them in the hope they'd go away.
For the standard 1200/2400Hz cassette tones, there's a very simple
circuit using a pair of monostables (one-shots) -- IIRC a single 74LS123
chip will do -- that does the decodning from the tones to a bitstream.
BTW, if you've got tone detectors (presumably one tuned to the '1' tone,
the other to the '0' tone), why do you need a miocrocontroller to turn
the output into a bitstrea?. A few logic gates is a lot simpler.
-tony
4:42 p.m.
On Tue, Feb 26, 2008 at 11:57 AM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
Well, microcontrollers are the cool new thing, right? I see in the
robotics club often that the response to just about any problem is,
"Oh, ok, we'll just drop in a microcontroller"
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
Easy path:
two tone detectors, going to a microcontroller who store the
data read from the tape and send it in RS232 way. A very simple AVR
microcontroller can do that ;o)
Argh!. I grew up learning to design solutions to problems, rather than
throw microcontrollers at them in the hope they'd go away.
For the standard 1200/2400Hz cassette tones, there's a very simple
circuit using a pair of monostables (one-shots) -- IIRC a single 74LS123
chip will do -- that does the decodning from the tones to a bitstream.
BTW, if you've got tone detectors (presumably one tuned to the '1' tone,
the other to the '0' tone), why do you need a miocrocontroller to turn
the output into a bitstrea?. A few logic gates is a lot simpler.
-tony
5:38 p.m.
John Floren wrote:
On Tue, Feb 26, 2008 at 11:57 AM, Tony Duell <ard
at p850ug1.demon.co.uk> wrote:
> BTW, if you've got tone detectors (presumably
one tuned to the '1' tone,
> the other to the '0' tone), why do you need a miocrocontroller to turn
> the output into a bitstrea?. A few logic gates is a lot simpler.
Well, microcontrollers are the cool new thing, right?
I see in the
robotics club often that the response to just about any problem is,
"Oh, ok, we'll just drop in a microcontroller"
"No, Nargato ,( an artificial human ) is way different in specs compared to four
PC's."
The Day of Sagittarius from The Melancholy of Haruhi Suzumiya.
Even from the point of si-fi you don't throw in a micro chip.
John
4:52 p.m.
On 26 Feb 2008 at 19:57, Tony Duell wrote:
Argh!. I grew up learning to design solutions to
problems, rather than
throw microcontrollers at them in the hope they'd go away.
Aw, Tony, a little 8 pin PIC or an ATiny can do this with no
additional active packages. The algorithm can be tweaked with no
component changes.
Yes, it might be fun doing it with NE567s or somesuch, but then,
someone even more conservative would castigate you for not using
tuned LC filters and discretes for the active part. A couple of
6SN7s and some powdered-iron core inductors should do the trick...
I really like the little microcontrollers--they're cheap and they do
the job. I'm not averse to using them when they're the best
solution.
Cheers,
Chuck
27 Feb
27 Feb
5:57 p.m.
On 26 Feb 2008 at 19:57, Tony Duell wrote:
No _new_ components, but you still have to reprogram the microcontroller
(which may involve pulling it from the board..). Personally, I'd rather
change some R's and C's
Argh!. I grew up learning to design solutions to
problems, rather than
throw microcontrollers at them in the hope they'd go away.
Aw, Tony, a little 8 pin PIC or an ATiny can do this with no
additional active packages. The algorithm can be tweaked with no
component changes.
Yes, it might be fun doing it with NE567s or somesuch, but then,
someone even more conservative would castigate you for not using
tuned LC filters and discretes for the active part. A couple of
6SN7s and some powdered-iron core inductors should do the trick...
I have an _old_ modem where the reciver has an input filter consisting of
a metal can with 8 or so tuned pot cores and capacitors in it. The output
of that is mixed with a local oscillator, the 'sum' frreqeuncy is taken
and fed to a discrimiator circuit. All discrete transsitors, of course...
I really like the little microcontrollers--they're cheap and they do
the job. I'm not averse to using them when they're the best
solution.
So do I. The operative part being 'when they're the bast solution'. I
don't feel they are in this case.
-tony
8:28 p.m.
On 27 Feb 2008 at 22:57, Tony Duell wrote:
No _new_ components, but you still have to reprogram
the microcontroller
(which may involve pulling it from the board..). Personally, I'd rather
change some R's and C's
Some uCs have the ability to program in-circuit. But popping a 6- or
8-pin PIC or AVR uC out of its (machine pin) socket for reprogramming
is a simple enough task. I keep a pile of them at the ready and just
cycle through them when I'm tweaking things. Most have wide supply
voltage tolerances and good (i.e. 25 ma) drive capabilities.
Cheers,
Chuck
Yes, it might be fun doing it with NE567s or somesuch, but then,
someone even more conservative would castigate you for not using
tuned LC filters and discretes for the active part. A couple of
6SN7s and some powdered-iron core inductors should do the trick...
I have an _old_ modem where the reciver has an input filter consisting of
a metal can with 8 or so tuned pot cores and capacitors in it. The output
of that is mixed with a local oscillator, the 'sum' frreqeuncy is taken
and fed to a discrimiator circuit. All discrete transsitors, of course...
I really like the little microcontrollers--they're cheap and they do
the job. I'm not averse to using them when they're the best
solution.
So do I. The operative part being 'when they're the bast solution'. I
don't feel they are in this case.
-tony 
6 Mar
6 Mar
3:29 a.m.
On Wed, 2008-02-27 at 22:57 +0000, Tony Duell wrote:
I've got microcontrollers. I've got tools to deal with
microcontrollers. I don't have any NE567s or pot cores left. Never
mind if something is particularly suitable, I use what I've got.
Gordon
On 26 Feb 2008 at 19:57, Tony Duell wrote:
No _new_ components, but you still have to reprogram the microcontroller
(which may involve pulling it from the board..). Personally, I'd rather
change some R's and C's Argh!. I grew up learning to design solutions to
problems, rather than
throw microcontrollers at them in the hope they'd go away.
Aw, Tony, a little 8 pin PIC or an ATiny can do this with no
additional active packages. The algorithm can be tweaked with no
component changes.
26 Feb
26 Feb
5:15 p.m.
Argh!. I grew up learning to design solutions to
problems, rather than
throw microcontrollers at them in the hope they'd go away.
Just like me!
But Tony, the world goes on...
Nowadays an attiny15 costs just like the same a 555. I have 1K of
program memory and other features, for almost the price of a 555. I like to
do puzzles, but there are lots of improvment in electronics. Why not use
them? Faster, easier, and it works!
I'm against programmable chips too. But Tony, we are in 2008! Things
doesn't need to be discardable, but also doesn't need to have 15 TTL chips
to work...
5:53 p.m.
On Feb 26, 2008, at 2:57 PM, Tony Duell wrote:
There's still quite a bit of design involved. Microcontrollers
aren't "automatic", as I'm sure you're well aware. A
microcontroller-
based design is every bit as valid and honest as an all-discrete design.
Easy path:
two tone detectors, going to a microcontroller who
store the
data read from the tape and send it in RS232 way. A very simple AVR
microcontroller can do that ;o)
Argh!. I grew up learning to design solutions to problems, rather than
throw microcontrollers at them in the hope they'd go away. For the standard 1200/2400Hz cassette tones,
there's a very simple
circuit using a pair of monostables (one-shots) -- IIRC a single
74LS123
chip will do -- that does the decodning from the tones to a bitstream.
BTW, if you've got tone detectors (presumably one tuned to the '1'
tone,
the other to the '0' tone), why do you need a miocrocontroller to turn
the output into a bitstrea?. A few logic gates is a lot simpler.
Well, Chuck said it best, but I'll add this: You get fewer
components, lower cost, easier maintainability and tweakability,
increased flexibility, the possibility for a reusable design...how is
this a bad thing?
-Dave
--
Dave McGuire
Port Charlotte, FL
6:14 p.m.
Dave McGuire wrote:
On Feb 26, 2008, at 2:57 PM, Tony Duell wrote:
Well, Chuck said it best, but I'll add this: You
get fewer components,
lower cost, easier maintainability and tweakability, increased
flexibility, the possibility for a reusable design...how is this a bad
thing?
I question the over head ... with all the design software closed source
I bet Mr Gates has control of I guess 75% of your hardware product.
-Dave
6:30 p.m.
David Griffith wrote:
This paper tape fiddling made me wonder if anyone ever
made a cassette
tape interface that emitted RS232 signals and looked to the computer
like a paper tape reader/writer.
Definitely. I used a lovely Techtran dual-cassette unit before I had
a floppy drive for my MITS 8800. Buffered in 128-byte blocks, fully
searchable and block-addressable. Used as a replacement for an ASR
tape unit--it understood XON and XOFF control codes. Baud rates to
2400, IIRC.
These were fairly common at one time in CNC applications, such as
embroidery and machining before they were replaced by floppy-disk
paper tape emulators.
Data was recorded as NRZ rather than FSK, however.
Cheers,
Chuck
10:34 p.m.
From: cclist at sydex.com
David Griffith wrote:
Hi
For the high speed cassette, the Poly88 used manchester encoding.
It is like a pushed to the limit FSK more more correctly phase
encoding.
Dwight
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging.?You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
This paper tape fiddling made me wonder if anyone
ever made a cassette
tape interface that emitted RS232 signals and looked to the computer
like a paper tape reader/writer.
Definitely. I used a lovely Techtran dual-cassette unit before I had
a floppy drive for my MITS 8800. Buffered in 128-byte blocks, fully
searchable and block-addressable. Used as a replacement for an ASR
tape unit--it understood XON and XOFF control codes. Baud rates to
2400, IIRC.
These were fairly common at one time in CNC applications, such as
embroidery and machining before they were replaced by floppy-disk
paper tape emulators.
Data was recorded as NRZ rather than FSK, however.
6:41 p.m.
On 26 Feb 2008 at 16:14, woodelf wrote:
I question the over head ... with all the design
software closed source
I bet Mr Gates has control of I guess 75% of your hardware product.
Eh? I use open-source development systems with both PIC and AVR.
Tony reminds me a bit of Bob Pease (who writes the analog column for
"Electronic Design"). When, on occasion, someone points out that a
simple microcontroller would satisfy the problem he's discussing, the
response is "I don't do software".
Bob might even recoil at Tony's suggestion of digital one-shots. If
you can't do it with op amps and comparators, Bob's generally not
interested.
Things are getting to the point where uCs even beat discrete logic in
the area of power consumption. TI's MSP430 16-bit uC, for example
draws a mere 250 microamps at 3 volts in active mode; 0.8 microamps
will keep the real-time clock going and 0.1 microamp will keep the
RAM intact.
Cheers,
Chuck
7:10 p.m.
Chuck Guzis wrote:
On 26 Feb 2008 at 16:14, woodelf wrote:
I have not seen such since I don't do any of that stuff.
I question the over head ... with all the design
software closed source
I bet Mr Gates has control of I guess 75% of your hardware product.
Eh? I use open-source development systems with both PIC and AVR. Things are getting to the point where uCs even beat
discrete logic in
the area of power consumption. TI's MSP430 16-bit uC, for example
draws a mere 250 microamps at 3 volts in active mode; 0.8 microamps
will keep the real-time clock going and 0.1 microamp will keep the
RAM intact.
Right now I am trying to VIEW the %$@! You-Tube stuff. I hate streaming
stuf on dial up. I don't think I will ever get more than the 1st few minutes
of the UNIVAC stuff. Nothing like comparing almost 60 years of computing
development.
Cheers,
Chuck
.
10:45 p.m.
From: cclist at sydex.com---snip---
> Tony reminds me a bit of Bob Pease (who writes the analog column for >
"Electronic Design"). When, on occasion, someone points out that a > simple
microcontroller would satisfy the problem he's discussing, the > response is
"I don't do software".
Hi
I've had lunch with Bob. He does enjoy analog.
> Bob might even recoil at Tony's suggestion of
digital one-shots. If > you can't do it with op amps and comparators, Bob's
generally not > interested.> > Things are getting to the point where uCs even
beat discrete logic in > the area of power consumption. TI's MSP430 16-bit uC, for
example > draws a mere 250 microamps at 3 volts in active mode; 0.8 microamps > will
keep the real-time clock going and 0.1 microamp will keep the > RAM intact.
How about 24 ea 18 bit processers in an array running at greater
than 1Gop/s ea and drawing .25 watts with all running and less
than 1 uw with all in sleep.
Look up SEAforth.
Dwight
_________________________________________________________________
Climb to the top of the charts!?Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
27 Feb
27 Feb
12:18 a.m.
On 26 Feb 2008 at 19:45, dwight elvey wrote:
How about 24 ea 18 bit processers in an array running
at greater
than 1Gop/s ea and drawing .25 watts with all running and less
than 1 uw with all in sleep.
That'd be overkill for a simple FSK decoder, wouldn't it? Unless, of
course, the bitrate was *very* high...
Cheers,
Chuck
12:26 a.m.
dwight elvey wrote:
How about 24 ea 18 bit processers in an array running
at greater
than 1Gop/s ea and drawing .25 watts with all running and less
than 1 uw with all in sleep.
Look up SEAforth.
Umm ....
SEAforth
In many ways, Seaforth is the quintessential small Ontario town.
Got a better idea?
Dwight
1:56 a.m.
On 26 Feb 2008 at 22:26, woodelf wrote:
In many ways, Seaforth is the quintessential small
Ontario town.
Or a boat, or a California town, or a Minnesota town....
Actually, the SEAForth processor seems to be the creation of a very
small firm:
http://www.intellasys.net/
With only 64 words of RAM and ROM for each of those 24 processors, my
guess is that some very fancy programming will be needed for anything
beyond simple tasks.
Actually, that FSK decoder for may be just the application.
Cheers,
Chuck
9:05 a.m.
From: cclist at sydex.com
To: cctalk at classiccmp.org
Date: Tue, 26 Feb 2008 22:56:58 -0800
Subject: Re: 1st stage loader for IMSAI - need ascii to binary conversion
On 26 Feb 2008 at 22:26, woodelf wrote:
Hi
It would be overkill but it was intended to be a flexible setup.
The ROM is rather limited but the way the processors are interconnected,
one can bring new code in from an external memory. Some of the processors
can be dedicated to transfering I/O and memory while the internal
ones would be doing the data processing.
Also, concider that they pack up to 4 instructions into each word of
ROM.
The interface between processors is such that one can execute instructions
directly from the neighboring processor. This makes the transfer of
data or instructions more efficient since the ROM of that processor
doesn't need to contain the transfer code.
The one thing I don't like is how they go to sleep. They sleep as soon as they
pass something on to the next processor and don't wake until that processor
reads the input. I'd rather have it sleep if there was a second data and
the first hadn't been yet read. Not as power efficient but It'd seem to
be better flow.
It also seems that a programming error could stall the entire sea with
a traffic jam.
It might be just the processor for building something that could extract
bit streams from hard disk and convert it to data. It seems fast enough.
For people like Tony, each processor could be treated like a component
in a circuit. Each with its own task to handle before passing data to
the next processor.
Dwight
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
In many ways, Seaforth is the quintessential
small Ontario town.
Or a boat, or a California town, or a Minnesota town....
Actually, the SEAForth processor seems to be the creation of a very
small firm:
http://www.intellasys.net/
With only 64 words of RAM and ROM for each of those 24 processors, my
guess is that some very fancy programming will be needed for anything
beyond simple tasks.
Actually, that FSK decoder for may be just the application.
10:21 a.m.
Chuck Guzis wrote:
Things are getting to the point where uCs even beat
discrete logic in
the area of power consumption.
Well, in terms of power, reliability, and physical footprint the uC can
probably equal a logic IC solution.
Where it loses out I suppose is maintainability; keeping the necessary
software and source code obtainable across the years may prove to be a big
headache, whereas with logic ICs there's no code to lose and no other software
needed (various programmable logic ICs excepted :)
In terms of fault diagnosis for simple things like the FSK application, I
doubt there's much difference - a fault can just as easily be traced to
"something's wrong with the uC" as it can "something's wrong with
that LS
logic chip".
6:19 p.m.
Tony reminds me a bit of Bob Pease (who writes the
analog column for
"Electronic Design"). When, on occasion, someone points out that a
simple microcontroller would satisfy the problem he's discussing, the
response is "I don't do software".
I take that as a wery high compliment!....
I also happen to agree with Bob Pease on the matter of the right number
of computers to control a car engine....
-tony
26 Feb
26 Feb
6:47 p.m.
On Tuesday 26 February 2008 18:14, woodelf wrote:
Dave McGuire wrote:
All of the "good" microcontrollers don't require any sort of Windows
software. Some may require closed-source compilers, etc, but you can
find open-source compilers for MCS51, PIC, and other uC architectures.
Pat
--
Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
On Feb 26, 2008, at 2:57 PM, Tony Duell wrote:
Well, Chuck said it best, but I'll add this: You get fewer
components, lower cost, easier maintainability and tweakability,
increased flexibility, the possibility for a reusable design...how
is this a bad thing?
I question the over head ... with all the design software closed
source I bet Mr Gates has control of I guess 75% of your hardware
product.
9:28 p.m.
Well, Chuck
said it best, but I'll add this: You get fewer components,
lower cost, easier maintainability and tweakability, increased
flexibility, the possibility for a reusable design...how is this a bad
thing?
I question the over head ... with all the design software closed source
I bet Mr Gates has control of I guess 75% of your hardware product.
9:36 p.m.
On Tue, 26 Feb 2008, Alexandre Souza wrote:
I know no microcontrollers that hasn't unix/linux tools, nor one who
doesn't is documented - programming algorithm, asm and like.
I remember seeing something like that at http://www.midibox.org/ and/or
http://www.ucapps.de/
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Well, Chuck said it best, but I'll add this: You
get fewer components,
lower cost, easier maintainability and tweakability, increased
flexibility, the possibility for a reusable design...how is this a bad
thing?
I question the over head ... with all the design software closed source
I bet Mr Gates has control of I guess 75% of your hardware product.
11:07 p.m.
On Feb 26, 2008, at 6:14 PM, woodelf wrote:
Huh?? No, nothing could be further from the truth. This is a
widely-believed myth that I want to put to bed *right now*. If you
choose a microcontroller and a compiler system that locks you into
BillyWare (or any other single vendor for that matter!), you've
chosen poorly.
I only use one microcontroller for which the compiler toolchain is
proprietary (ironically it's an extended Z80)...EVERYTHING else I run
is free. I regularly develop for (non-extended) Z80, at least four
different modern mcs51 variants, ARM7, and PIC architectures, and I
compiled every tool I use from source code. It's free software every
step of the way, including editing the source code, compilation,
linking, chip programming, debugging...everything. Soon I'll be
adding MSP430 and ARM9 to that list, and the most commonly used
development tools for those platforms are free (including source
code) also.
Further, there's no Windows involved anywhere (I don't have the
patience for it)...I usually run under Solaris on UltraSPARC, but
sometimes I develop (using the exact same tools!) under OS X. Hooray
for modern operating systems.
-Dave
--
Dave McGuire
Port Charlotte, FL
Well, Chuck
said it best, but I'll add this: You get fewer
components, lower cost, easier maintainability and tweakability,
increased flexibility, the possibility for a reusable design...how
is this a bad thing?
I question the over head ... with all the design software closed
source
I bet Mr Gates has control of I guess 75% of your hardware product.
6 Mar
6 Mar
3:30 a.m.
On Tue, 2008-02-26 at 16:14 -0700, woodelf wrote:
Dave McGuire wrote:
Mr who?
Gordon
On Feb 26, 2008, at 2:57 PM, Tony Duell wrote:
Well, Chuck said it best, but I'll add
this: You get fewer components,
lower cost, easier maintainability and tweakability, increased
flexibility, the possibility for a reusable design...how is this a bad
thing?
I question the over head ... with all the design software closed source
I bet Mr Gates has control of I guess 75% of your hardware product.
11:54 a.m.
Gordon JC Pearce wrote:
Mr who?
No that is Dr. Who. :)
Gordon
PS: I think the VDM-1 manual has a BOOT
strap loader listing in a appendex.
How many people had a TTY for hardcopy with 8080 machine?
I have fond memories of using a CP/M system. If the 8" floppy sticks
hit the drive. If you hit the drive TOO hard that machine reset for some reasion.
Lots of fun.
27 Feb
27 Feb
6:11 p.m.
Well, Chuck said it best, but I'll add this:
You get fewer
components, lower cost, easier maintainability and tweakability,
increased flexibility, the possibility for a reusable design...how is
this a bad thing?
OK, let's look at those advantages :
'Fewer COmpoentns'. OK, I'll grant that there are probably few bits to
pick up and solder to the PCB (although it's close -- as I mentioned last
night, there's a CUTS decoder using a single 16 pin TTL chip). But there
are certainly more 'devices' -- individual transistors, etc -- in the
microcontrolelr solution. Now, my expoerience suggests that while a
single chip is moree reliable than making the same circuit from many
chips or discrete transistors, a complex chip _is_ less reliale than a
simple one. So while trying to build the 'microcontroller' solution using
TTL (full adders, lateches for the registers, etc) would be considerably
less reliuable than the single chip microcontroller, I also suspect that
a single TTL chip, or a few of them, would be more reliable than the
microcontorller
'Lower cost'. I could make the flipant answer and say that my junk box
contains plenty of TTL chips and no microocntrollers. But I'd rather
point out that the cheapest solution is not necessarily the best, and
that this idea of always cutting the cost to the minimum is one reason
that I don't buy many new products.
'Easier maintainabilty and tweakaility'. Surely you jest here! It is a
lot easier to find a fault in a circuit when you can actually put the
'scope probe on a particular signal. Darn it, with a single-chip
microcontroller, you can't normally trace the firmware. Repairing it is a
nightmare unless you have the firmware (prefereably as source code). I'd
much rather change a 2-lead passive compoennt than reprogram a chip (and
it'll be quicker...)
'Increased fleximbility'. The original discussion was to decode cassette
tones. Why do I want to add any more features. I prefer a design that
does one job, and does it well.
'Reuseable Design'. Again 'Why?'. I'd much rather come up with the
_right_ design (IMHO) for each problem eather than try to kludge in a
previous design just ecause I have it. This quickly leads to the idea of
bodging together off-the-shelf units, which is another thing I dislike...
-tony
28 Feb
28 Feb
12:57 a.m.
On Feb 27, 2008, at 6:11 PM, Tony Duell wrote:
I can't really disagree with your assertion that a complex chip is
less reliable than a simple one, but we're talking about very simple
microcontrollers (granted they're a lot more complex than a 7473 or
something) that just don't fail all that often. I don't know of
anyone who has experienced high field failure rates with these little
chips. I guess, to me, it really doesn't matter if it lasts 100
years or 1000 years.
Well, Chuck
said it best, but I'll add this: You get fewer
components, lower cost, easier maintainability and tweakability,
increased flexibility, the possibility for a reusable design...how is
this a bad thing?
OK, let's look at those advantages :
'Fewer COmpoentns'. OK, I'll grant that there are probably few bits to
pick up and solder to the PCB (although it's close -- as I
mentioned last
night, there's a CUTS decoder using a single 16 pin TTL chip). But
there
are certainly more 'devices' -- individual transistors, etc -- in the
microcontrolelr solution. Now, my expoerience suggests that while a
single chip is moree reliable than making the same circuit from many
chips or discrete transistors, a complex chip _is_ less reliale than a
simple one. So while trying to build the 'microcontroller' solution
using
TTL (full adders, lateches for the registers, etc) would be
considerably
less reliuable than the single chip microcontroller, I also suspect
that
a single TTL chip, or a few of them, would be more reliable than the
microcontorller 'Lower cost'. I could make the flipant answer
and say that my junk box
contains plenty of TTL chips and no microocntrollers. But I'd rather
point out that the cheapest solution is not necessarily the best, and
that this idea of always cutting the cost to the minimum is one reason
that I don't buy many new products.
We're in agreement there, as I live in the country that is now
ruled by WalMart and all of their made-in-China garbage and it's
really getting to me. I would never suggest that the cheaper
solution is automatically going to be better. However, this (in my
opinion) better solution also happens to be cheaper.
'Easier maintainabilty and tweakaility'.
Surely you jest here!
Not at all. Read on and I will explain my position.
It is a
lot easier to find a fault in a circuit when you can actually put the
'scope probe on a particular signal. Darn it, with a single-chip
microcontroller, you can't normally trace the firmware.
In the context of a small microcontroller like the ones we're
talking about, these things just don't have that much code space.
Almost none of them allow self-modifying code. Nearly all of them
have small, simple instruction sets. If the programmer NEEDS to
actually trace the firmware to find a bug, I'd question that
programmer's competency. Seriously.
Repairing it is a
nightmare unless you have the firmware (prefereably as source code).
Of course we'd have the source code. We're talking about one of
us building something.
I'd
much rather change a 2-lead passive compoennt than reprogram a chip
(and
it'll be quicker...)
Well, personal preferences aside, it might be quicker and it might
not. I can type "make burn" at a shell prompt in the terminal window
to the right of this email message and squirt an entire new code
image into the Philips ARM7 chip I'm working with in less time than
it takes my (fast Metcal) soldering iron to heat up...and that code
image has BIG stuff in it like an IP stack.
'Increased fleximbility'. The original
discussion was to decode
cassette
tones. Why do I want to add any more features. I prefer a design that
does one job, and does it well.
Of course. You seem to have assumed that you're more anal and
more of a purist than I am, but I assure you that's not the case.
I've lost jobs (and very nearly my HOME) for taking a stand on such
matters in the past! So, in the context of decoding cassette
tones...There are all sorts of perfectly valid reasons why that
additional flexibility might be useful. What if you want to change
it to use different frequencies later? What if you want to
experiment with noise-resiliency algorithms or something? All of
these things can contribute to "doing one job well". Witness Phil's
floppy disk reader project.
'Reuseable Design'. Again 'Why?'.
I'd much rather come up with the
_right_ design (IMHO) for each problem eather than try to kludge in a
previous design just ecause I have it.
Reuse of a past design is not automatically a kludge. Reuse of a
*debugged* past design, if it's the right tool for the job, is
SMART. Period.
This quickly leads to the idea of
bodging together off-the-shelf units, which is another thing I
dislike...
...and I dislike it as well, and I'd never do it. Not everyone
who uses a microcontroller is boding together off-the-shelf units or
adding unnecessary complexity. Make no mistake my friend, some of us
microcontroller hackers are just as idealistic and picky as you are,
and our standards are just as high.
-Dave
--
Dave McGuire
Port Charlotte, FL
2:12 p.m.
'Easier
maintainabilty and tweakaility'. Surely you jest here!
Not at all. Read on and I will explain my position.
It is a
lot easier to find a fault in a circuit when you can actually put the
'scope probe on a particular signal. Darn it, with a single-chip
microcontroller, you can't normally trace the firmware.
In the context of a small microcontroller like the ones we're
talking about, these things just don't have that much code space.
Almost none of them allow self-modifying code. Nearly all of them
have small, simple instruction sets. If the programmer NEEDS to
actually trace the firmware to find a bug, I'd question that
programmer's competency. Seriously. I'd
much rather change a 2-lead passive compoennt than reprogram a chip
(and
it'll be quicker...)
Well, personal preferences aside, it might be quicker and it might
not. I can type "make burn" at a shell prompt in the terminal window
to the right of this email message and squirt an entire new code image into the Philips ARM7 chip I'm working with
in less time than
it takes my (fast Metcal) soldering iron to heat up...and that code
image has BIG stuff in it like an IP stack.
On the other hand, my sodlering iron is hot right now :-)
bodging
together off-the-shelf units, which is another thing I
dislike...
...and I dislike it as well, and I'd never do it. Not everyone
who uses a microcontroller is boding together off-the-shelf units or
4 Mar
4 Mar
2:01 p.m.
On Feb 28, 2008, at 2:12 PM, Tony Duell wrote:
So do I, when I can't find a bug by reading the source code. My
point is that these smaller processors are so simple that it's damn
difficult to write a bug that's impossible to find without wanting to
probe the internal circuitry of the chip.
In the
context of a small microcontroller like the ones we're
talking about, these things just don't have that much code space.
Almost none of them allow self-modifying code. Nearly all of them
have small, simple instruction sets. If the programmer NEEDS to
actually trace the firmware to find a bug, I'd question that
programmer's competency. Seriously.
OK, so I;m an incompetent programmer. I'm happy to agree to that.
Because
I certainly deug firmware (where possible) by hanging a logic analyser
off the address lines and seeing where the code is going. If you
can do it without, great!. Let me give you an alaogy. _I_ once tracked down a
logic fault in a
P850
by noticing some odd behviour of the front panel bulbs, in particular
that half were brighter than the other half. Knowing that it's
really an
8 bit machine interlally made me suspect that one half of the data
wasn't
being latched properly. That lead me to a missing latch strobe signal,
and so on.
On the other hand, most of the time I use a 'socpe and/or logic
analyser.
I like to debug by figuring out what the unit is doing and
comparing it
with what it should be doing. And I like to debug firmware the same
way.
Sure, that makes sense. But for what we're talking about, you
honestly don't think that's overkill? I too have a logic analyzer; I
use it with some regularity and I'm comfortable with it...but in such
a simple application, it'd likely take longer to hook up all the
logic analyzer pin grabbers to the circuit than it would to find a
bug in my own code running on a tiny processor with 1KB of program
memory.
Goal-oriented methodology isn't always a sellout.
-Dave
--
Dave McGuire
Port Charlotte, FL
26 Feb
26 Feb
2:48 p.m.
This paper tape fiddling made me wonder if anyone ever
made a cassette
tape interface that emitted RS232 signals and looked to the computer like
a paper tape reader/writer.
I doubt you could make a cassette interface that appeared identical to a
paper tape reader, since most paper tape readers will stop on a character
and cassettes don't
That said, there have been many cassette interfaces that were
hardware-intensive and which used a normal asynchronous serial chip. One
very common one (at least over here) is the BBC Micro. That has a 6850
chip linked to a ULA. The latter generates the baud clocks, switches the
6850 serial pins between the RS423 serial port and the cassette
circuitry, and encodes said serial stream to CUTS tones.
_Many_ years ago I built a CUTS encoder/decoder with an RS232 interface
and used it to read Basicode tapes. The encoder was a pair of counters
with a factor of 2 differnt in the division ration, one was held reset
when the TxD line was high, the other was reset wehn it was low. The
outputs were ORed toegether, they wete both clocked from the same
freqeuncy source.
The decoder was a couple of monostables (one-shots), connected in a
well-known circuit that I got from $deity-knows-where.
I even used one of hte handshake lines on the RS232 port to control a
relay wired to the remote socket o nthe cassette recorder.
-tony
4:49 p.m.
David Griffith wrote:
This paper tape fiddling made me wonder if anyone ever
made a cassette
tape interface that emitted RS232 signals and looked to the computer like
a paper tape reader/writer.
Yes, we had some at Westfield College, University of London in the
early 1980s. I can't remember the make/model, but I think I may
have one in the loft (will take a look). It was a modified audio
cassette recorder with a 25-pin "D" connector for the serial port.
--
John Honniball
coredump at gifford.co.uk
6:40 p.m.
David Griffith wrote:
This paper tape fiddling made me wonder if anyone ever
made a cassette
tape interface that emitted RS232 signals and looked to the computer like
a paper tape reader/writer.
reminds me of the TRS-232
It was an aftermarket printer interface ("RS232") that operated off of the
cassette port of the TRS-80
27 Feb
27 Feb
6:16 p.m.
reminds me of the TRS-232
It was an aftermarket printer interface ("RS232") that operated off of the
cassette port of the TRS-80
There was a circuit for that in an old issue of Byte magazine. It was
daically just an Op-amp that detected the state of the cassette output
line. The output of said op-amp swung to the supply rails (+/-9V IIRC)
and was the RS232 output :-)
Also, didn't one of the early Radio Shack modems have a switch on it to
make the 'RS232' input actually the same levels as the Model 1 cassette
port, so you could use it with a plain Model 1 with no RS232 interface
(although with special software, of course)
-tony
25 Feb
25 Feb
12:11 p.m.
On Feb 25, 2008, at 9:58 AM, Jeff Erwin wrote:
I am in the process of rebuilding an IMSAI 8080 and am
using my Mac
Pro as a
dumb terminal. I have it all to the point where I can type a
character and
see the ascii appear on the front panel. What I need to do is write a
simple 1st stage loader that will take the HEX output from the ASM80
assembler, send it over the serial connection and put it in memory.
This
way I can write a more sophisticated loader and not have to key it
in by
hand.
The question is, what is the algorithm, in assembly language, for
converting
an ascii character to its binary equivalent. By this, I mean
converting an
'a' to 1010, not 041H which is the ascii value. I remember writing
such a
thing 30 years ago but simply cannot get my head around it now.
The algorithm has to deal with taking an ascii string like
AF67DBFF6FF9AF81C2130053DBFF5FAAC2210039D20600780747D3FFAF4 and
converting
each ascii character into the binary value it represents. The sting
above
would convert, one character at a time, to:
1010
1111
0110
0111
1101
well, you get the point...It has to work only for 0-9 and A-F which
should
make it easier.
Anyone out there remember how to do this?
Jeff Erwin
Let me try this again.
I just went through this same exercise last week. Here is a link to
the source code of IMSAI's original paper tape loader which does
exactly what you're looking for. You will probably have to modify it
to suit your particular serial interface and memory map.
http://maben.homeip.net/static/S100/IMSAI/code/1976%20Self%20Contained%20Sy…
As an aside, here is a video of my IMSAI using this loader to bring up
a copy of Altair 4K Basic.
http://www.youtube.com/watch?v=ADplHpk33yY
-Mardy
5982
days inactive
5992
days old
47 comments
17 participants
participants (17)
-
alexandre-listas＠e-secure.com.br -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
coredump＠gifford.co.uk -
dgriffi＠cs.csubak.edu -
dkelvey＠hotmail.com -
gordonjcp＠gjcp.net -
jefferwin＠gmail.com -
jules.richardson99＠gmail.com -
mardy＠voysys.com -
mcguire＠neurotica.com -
pat＠computer-refuge.org -
ploopster＠gmail.com -
rcini＠optonline.net -
slawmaster＠gmail.com