26 Apr
2008
26 Apr
'08
11:26 p.m.
Date: Sat, 26 Apr 2008 23:15:41 -0500
From: Jim Leonard
I disagree somewhat, if only to present the evidence
of the PCjr. Now
*that* was clearly meant as a home computer (cartridge slots, wireless
keyboard, small and light, built-in composite video)
I use the introduction of the Peanut as proof that IBM was still
suffering from the shock of having customers flock to buy the PC. As
they discovered, even the unwashed public had its limits as to what
could be passed off as an IBM product. Or maybe it was just the
result of a drunken bet. You forgot the complete lack of DMA and,
shall we say, "anemic" interrupt handling facility?
How about the 1990's IBM "multimedia" computer system? Use it as a
phone answering machine, fax machine, CD player, etc. The only
problem being that you have to leave it on all the time. Toshiba
made a similar blunder at about the same time with its Infinia
machines--only to abandon the desktop business altogether.
Cheers,
Chuck
27 Apr
27 Apr
1:14 a.m.
On Sat, 2008-04-26 at 23:26 -0700, Chuck Guzis wrote:
How about the 1990's IBM "multimedia"
computer system? Use it as a
phone answering machine, fax machine, CD player, etc. The only
problem being that you have to leave it on all the time. Toshiba
made a similar blunder at about the same time with its Infinia
machines--only to abandon the desktop business altogether.
Does anyone ever turn their computers off any more?
Gordon
8:11 a.m.
Chuck Guzis wrote:
You guys keep using the term IBM as the designer and manufacturer of the
PC. The stories I've heard was that it was more of a skunkworks project
in a little division in a swamp in Florida.
The people designing the PCjr had a few competing interests:
- Inexpensive and less 'industrial' for the home market.
- Compete on the low end with the C64, in the middle with the Apple ][,
and avoid competing on the high end with the PC
- Differentiate it from the PC clones
So they came up with a machine that had a base memory of 64K, was
expandable to 128K, better graphics than most machines at the times,
cartridges for the pre-K set, and a simplified keyboard. Oh, and it ran
most PC software.
If you judge it against the PC of course it falls short - it's not a PC!
Different design goals by much of the same group that designed the PC.
You could tell they were conflicted, or very forward thinking. For a
machine that only went to 128K, the standard BIOS knew to scan to 640K.
For a machine that only supported one parallel port and one diskette
drive, the BIOS knows to look for 2 parallel ports and it has support in
BIOS for three diskette drives.
The sidecar bus was a conflict of goals too - they were trying to make
expansion 'easier' than on a PC, but still preserve expansion. A lot of
what the machine needed was already built-in or accomodated with special
purpose slots on the motherboard. In just the cabinet with no sidecars
I can have 128K of memory, better than CGA graphics, an internal modem,
serial port, ports for two joysticks, diskette drive and controller. In
1984 that was a pretty complete machine, except for the parallel port.
Things like dropping DMA, using NMI for keyboard decoding and having the
video memory shared with main memory piss off engineers, not customers.
The single biggest complaint about the PCjr at the time was the
keyboard, not the lack of DMA.
24 years later, with the exception of a few games there is very little
software for the PC that I want to run on a Jr that doesn't run. It's a
pain to get extra memory on it, but once you clear that hurdle it was a
very capable little machine.
(Nevermind that mine has clock/cal, SCSI hard disk, Ethernet, etc.)
Mike
Date: Sat, 26
Apr 2008 23:15:41 -0500
From: Jim Leonard
I disagree somewhat, if only to present the
evidence of the PCjr. Now
*that* was clearly meant as a home computer (cartridge slots, wireless
keyboard, small and light, built-in composite video)
I use the introduction of the Peanut as proof that IBM was still
suffering from the shock of having customers flock to buy the PC. As
they discovered, even the unwashed public had its limits as to what
could be passed off as an IBM product. Or maybe it was just the
result of a drunken bet. You forgot the complete lack of DMA and,
shall we say, "anemic" interrupt handling facility?
How about the 1990's IBM "multimedia" computer system? Use it as a
phone answering machine, fax machine, CD player, etc. The only
problem being that you have to leave it on all the time. Toshiba
made a similar blunder at about the same time with its Infinia
machines--only to abandon the desktop business altogether.
Cheers,
Chuck
8:23 a.m.
New subject: 8251 troubles
Hi
I've got a funny problem with a 8251.
I've been writing 8080 code and seem to have a strange
problem.
I initialize the chip in async mode. I have a light box on the
serial wire. It is initialized to both send and recieve.
I send one character to the 8251 and it passes it to the software
on the 8080 side. I display it on the 8080 side.
I then send another character to the 8251. Nothing happens.
It won't receive until I reset it.
None of the status lights change. I can see the data light flicker.
It could be a bad part but it just doesn't seem that it would
work once and then fail to work for the second character.
It just doesn't make sense.
Is there something I'm missing about the 8251.
Dwight
_________________________________________________________________
Spell a grand slam in this game where word skill meets World Series. Get in the game.
http://club.live.com/word_slugger.aspx?icid=word_slugger_wlhm_admod_april08
8:45 a.m.
New subject: 8251 troubles
On Sun, 2008-04-27 at 08:23 -0700, dwight elvey wrote:
Hi
I've got a funny problem with a 8251.
I've been writing 8080 code and seem to have a strange
problem.
I initialize the chip in async mode. I have a light box on the
serial wire. It is initialized to both send and recieve.
I send one character to the 8251 and it passes it to the software
on the 8080 side. I display it on the 8080 side.
I then send another character to the 8251. Nothing happens.
It won't receive until I reset it.
None of the status lights change. I can see the data light flicker.
It could be a bad part but it just doesn't seem that it would
work once and then fail to work for the second character.
It just doesn't make sense.
Is there something I'm missing about the 8251.
Dwight
That could be caused by a lot of things. Could you post the relevant
code?
9:24 a.m.
New subject: 8251 troubles
Hi
The routines SETUP and COUT are ROM routines.
SETUP passes the first byte to the clock generator and the
remaining to the command port of the 8251. The command/status
port is 1 while the data is 0.
COUT sends text to a video board.
The second COUT never seems to get executed?? I give plenty
of time between characters because I send then manually.
The board can do interrupt driven serial but that didn't seem to
work so I went for the simpler polling method.
DI
CALL SETUP
; .DB $01F ; 9600
; .DB $01D ; 4800
.DB $01B ; 2400
; .DB $019 ; 1200
.DB $0AA ; SYNC
.DB $0AA ; SYNC
.DB $040 ; RESET
.DB $0CE ; 2STOP, NO PARITY, 8BIT , X16
.DB $010 ; CLEAR ERRORS
.DB 0
MVI A,$027 ; RTD, DTR AND REC-EN TX-EN
OUT 1
CALL TIN
CALL COUT ; This works
CALL TIN
CALL COUT ; never gets here
......................................
TIN:
IN 1
ANI 2
JZ TIN
IN 0
RET
From: thrashbarg at kaput.homeunix.org
To: cctalk at classiccmp.org
Date: Mon, 28 Apr 2008 01:15:04 +0930
Subject: Re: 8251 troubles
On Sun, 2008-04-27 at 08:23 -0700, dwight elvey wrote:
_________________________________________________________________
Express yourself wherever you are. Mobilize!
http://www.gowindowslive.com/Mobile/Landing/Messenger/Default.aspx?Locale=e…
Hi
I've got a funny problem with a 8251.
I've been writing 8080 code and seem to have a strange
problem.
I initialize the chip in async mode. I have a light box on the
serial wire. It is initialized to both send and recieve.
I send one character to the 8251 and it passes it to the software
on the 8080 side. I display it on the 8080 side.
I then send another character to the 8251. Nothing happens.
It won't receive until I reset it.
None of the status lights change. I can see the data light flicker.
It could be a bad part but it just doesn't seem that it would
work once and then fail to work for the second character.
It just doesn't make sense.
Is there something I'm missing about the 8251.
Dwight
That could be caused by a lot of things. Could you post the relevant
code?
9:58 a.m.
New subject: 8251 troubles
On Sun, 2008-04-27 at 09:24 -0700, dwight elvey wrote:
-- snip --
TIN:
IN 1
ANI 2
JZ TIN
IN 0
RET
-- snip --
One thing I found invaluable on my 8080 was the console LED port at
0FFh. I'd stick an OUT 0FFH after IN 1 to see what's going on in real
time. Do you have anything like that on your system? Or at least some
way to watch port 1? It's clear that the system isn't seeing bit 2 of
port 1 activate the second time around.
If you can, try and swap it with another 8251, just in case. Like you
say, I doubt it would be the 8251 because it works once, but it's a
simple thing to do and it gets it out of the way, just in case it
happens to be the problem.
What system is this by the way?
4:13 p.m.
New subject: 8251 troubles
Hi
I could send to the video. It is a Poly88. I've been working
on getting my images transferred. I thought the serial
would be easy. Ha ha ha.
I don't have another chip handy but can get one tomorrow.
I can alway send directly to video RAM. That is similar to the
led port.
Thanks for the sanity check.
Dwight
From: thrashbarg at kaput.homeunix.org
On Sun, 2008-04-27 at 09:24 -0700, dwight elvey wrote:
-- snip --
_________________________________________________________________
Make i'm yours.? Create a custom banner to support your cause.
http://im.live.com/Messenger/IM/Contribute/Default.aspx?source=TXT_TAGHM_MS…
TIN:
IN 1
ANI 2
JZ TIN
IN 0
RET
-- snip --
One thing I found invaluable on my 8080 was the console LED port at
0FFh. I'd stick an OUT 0FFH after IN 1 to see what's going on in real
time. Do you have anything like that on your system? Or at least some
way to watch port 1? It's clear that the system isn't seeing bit 2 of
port 1 activate the second time around.
If you can, try and swap it with another 8251, just in case. Like you
say, I doubt it would be the 8251 because it works once, but it's a
simple thing to do and it gets it out of the way, just in case it
happens to be the problem.
What system is this by the way?
28 Apr
28 Apr
2:22 p.m.
New subject: 8251 troubles
dwight elvey wrote:
Hi
The routines SETUP and COUT are ROM routines.
SETUP passes the first byte to the clock generator and the
remaining to the command port of the 8251. The command/status
port is 1 while the data is 0.
COUT sends text to a video board.
The second COUT never seems to get executed?? I give plenty
of time between characters because I send then manually.
The board can do interrupt driven serial but that didn't seem to
work so I went for the simpler polling method.
DI
CALL SETUP
; .DB $01F ; 9600
; .DB $01D ; 4800
.DB $01B ; 2400
; .DB $019 ; 1200
.DB $0AA ; SYNC
.DB $0AA ; SYNC
.DB $040 ; RESET
.DB $0CE ; 2STOP, NO PARITY, 8BIT , X16
.DB $010 ; CLEAR ERRORS
.DB 0
MVI A,$027 ; RTD, DTR AND REC-EN TX-EN
OUT 1
CALL TIN
CALL COUT ; This works
CALL TIN
CALL COUT ; never gets here
......................................
TIN:
IN 1
ANI 2
JZ TIN
IN 0
RET
I have the datasheet for the 8251A but not the 8251 here, so just some guesses:
- perhaps the 8251 (as opposed to the A) requires the receiver to be re-enabled
(not a full reset) after receipt of each character (an 'explicit ack') (?).
- .. check the error flags to see if a framing error is occurring?
- .. try sending a stream of (best random) characters at full rate,
as opposed to just 2 manually? This might get around some framing
inconsistency or such to at least see if a subsequent character can be received.
- (may be inconsequential, but in the init sequence the two sync characters
are not preceded by a mode byte (perhaps SETUP does this internally?))
9:02 p.m.
New subject: 8251 troubles
Date: Mon, 28 Apr 2008 13:22:08 -0800
From: hilpert at cs.ubc.ca
To: General at priv-edtnaa03.telusplanet.net
CC:
Subject: Re: 8251 troubles
dwight elvey wrote:
---snip---
DI
CALL SETUP
; .DB $01F ; 9600
; .DB $01D ; 4800
.DB $01B ; 2400
; .DB $019 ; 1200
.DB $0AA ; SYNC
.DB $0AA ; SYNC
.DB $040 ; RESET
.DB $0CE ; 2STOP, NO PARITY, 8BIT , X16
.DB $010 ; CLEAR ERRORS
.DB 0
I have the datasheet for the 8251A but not the 8251 here, so just some guesses:
- perhaps the 8251 (as opposed to the A) requires the receiver to be re-enabled
(not a full reset) after receipt of each character (an 'explicit ack') (?).
- .. check the error flags to see if a framing error is occurring?
- .. try sending a stream of (best random) characters at full rate,
as opposed to just 2 manually? This might get around some framing
inconsistency or such to at least see if a subsequent character can be received.
- (may be inconsequential, but in the init sequence the two sync characters
are not preceded by a mode byte (perhaps SETUP does this internally?))
This is the perscribed way to get around another feature. If the 8251 was in
the middle of a read sync sequence, one should first send 2 dummy
command/sync. It will then be sure to be waiting for a command.
Sending a reset command enables it to look for the mode. The
$0CE is the mode to select async and dividers and such. Anything that
then follows is a command.
I'll try resending the recieve enable to see if that makes a difference.
Dwight
_________________________________________________________________
Back to work after baby?how do you know when you?re ready?
http://lifestyle.msn.com/familyandparenting/articleNW.aspx?cp-documentid=57…
27 Apr
27 Apr
10:44 a.m.
I use the introduction of the Peanut as proof that IBM
was still
suffering from the shock of having customers flock to buy the PC. As
they discovered, even the unwashed public had its limits as to what
could be passed off as an IBM product. Or maybe it was just the
result of a drunken bet. You forgot the complete lack of DMA and,
shall we say, "anemic" interrupt handling facility?
I beleive it was possible to add a DMA chip on the expansion bus of the
PCjr. The necessary bus control signals, and even the DRQ and DACK lines
for the floppy controller, are there.
Not that many people did, of course...
-tony
1:59 p.m.
Chuck Guzis wrote:
You forgot the complete lack of DMA and,
shall we say, "anemic" interrupt handling facility?
I remember the DMA, but what do you mean about "anemic" interrupt handling?
(These are of personal interest to me as I'm about to add PCjr
functionality to a hobbyist program I'm writing)
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
6081
days inactive
6083
days old
11 comments
8 participants
participants (8)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
dkelvey＠hotmail.com -
gordonjcp＠gjcp.net -
hilpert＠cs.ubc.ca -
mbbrutman-cctalk＠brutman.com -
thrashbarg＠kaput.homeunix.org -
trixter＠oldskool.org