2 Jan
2003
2 Jan
'03
10:27 a.m.
From: "Sellam Ismail"
<foo(a)siconic.com>
On Thu, 2 Jan 2003, Dwight K. Elvey wrote:
Hi
I thought you were using the pin as an input. As an input,
there is no pullup and a floating pin would not be good.
The pin is an input, but it's normal state is to be off/false. Therefore,
John's suggestion to put a pulldown resistor on it seems logical. It
should be normally off, and the M200 should bring it high when it wants to
signal the PICK CHECK error.
I'm trying to troubleshoot a more pressing problem right now: the reader
is picking 5 cards before the Apple thinks 80 Index Marks (e.g. 80
characters) have been detected. Either my code is wrong, my code is slow,
or the Apple is too slow to handle the reader input (in which case this
was all for naught).
Hi
It sounds like something is wrong. Are you reading with BASIC
or at code level. I would think that assembly code should be able
to keep up, as long as you were not expecting it to transfer to
disk while reading. Does the M200 have any kind of handshake?
Dwight
On Thu, 2
Jan 2003, John Lawson wrote:
> On Thu, 2 Jan 2003, Vintage Computer Festival wrote:
>
> > I've got the PICK CHECK signal from the reader going into CB2. I have
a
> 1K
resistor going from CB2 to ground.
^^^^^^^^^^^
Try changing to 5K or even 10K (what I always use for pull ups/downs in
TTL work. I think you're burying the poor PICK CHECK signal. Actually
all the resistors oughta be 10K, IMHO.
I'll certainly try that. But I'm wondering why that should be necessary
when the 6522 data sheet says that particular pin is a TTL level output.
I'm heading off to Radio Shack to take a mental break and to get some
resistors and to see if they can offer me more than just blank stares.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
2 Jan
2 Jan
11:08 a.m.
On Thu, 2 Jan 2003, Dwight K. Elvey wrote:
I'm not so sure. Here's what I know:
6502 operates at roughly 1,000,000 cycles per second.
I wrote a very tight code loop to simply look for the READY signal from
the reader, and then count Index Marks, as quickly as it can. Here's the
relevant loop code (the number is parentheses at the end of the comment
is the number of cycles that instruction takes):
LDX #$00
LOOP LDA $C0C1 ; Get the data at 6522 Port A (4)
AND #$08 ; Bit 4 is the RDY signal input (4)
BEQ LOOP ; Loop until it goes true (2)
WAIT LDA $C0C1 ; Now wait until it goes false (4)
AND #$08 ; (4)
BEQ WAIT ; (2)
INX ; Increment the count (2)
INC $06 ; Increment a zero page location* (6)
CPX #$50 ; 80 Index Marks yet? (4)
BNE LOOP ; No? Keeping looping (2)
* So I can view the resulting value when I reset the computer to break out
of the loop
So counting up the cycles to read the index mark, it's 10 to wait for it
to go true, 10 for it to go false, then 14 to increment a counter and go
back to the top of the loop.
The timing diagram of the M200 says that the Index Mark is pulsed for 6
microseconds. Now, if I'm computing this right, that is already less time
than it takes for the 6502 to wait for the pulse to fall back to false
I'm trying
to troubleshoot a more pressing problem right now: the reader
is picking 5 cards before the Apple thinks 80 Index Marks (e.g. 80
characters) have been detected. Either my code is wrong, my code is slow,
or the Apple is too slow to handle the reader input (in which case this
was all for naught).
It sounds like something is wrong. Are you reading with BASIC
or at code level. I would think that assembly code should be able
to keep up, as long as you were not expecting it to transfer to
disk while reading. Does the M200 have any kind of handshake? from true. The 6502 takes 10 cycles, or roughly 10
microseconds, assuming
a cycle is equivalent to a microsecond.
Further, the timing diagram of the M200 shows that there are 1314
microseconds of time to read the column data, and 2014 microseconds
between Index Marks. This should be enough time for the 6502 to read and
store the data, then loop again.
This is one fast reader. But too fast for the 6502 me thinks.
:(
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
11:28 a.m.
On Thu, 2 Jan 2003, Sellam Ismail wrote:
On Thu, 2 Jan 2003, Dwight K. Elvey wrote:
I'm not so sure. Here's what I know:
6502 operates at roughly 1,000,000 cycles per second.
I wrote a very tight code loop to simply look for the READY signal from
the reader, and then count Index Marks, as quickly as it can. Here's the
relevant loop code (the number is parentheses at the end of the comment
is the number of cycles that instruction takes):
LDX #$00
LOOP LDA $C0C1 ; Get the data at 6522 Port A (4)
AND #$08 ; Bit 4 is the RDY signal input (4)
BEQ LOOP ; Loop until it goes true (2)
WAIT LDA $C0C1 ; Now wait until it goes false (4)
AND #$08 ; (4)
BEQ WAIT ; (2)
INX ; Increment the count (2)
INC $06 ; Increment a zero page location* (6)
CPX #$50 ; 80 Index Marks yet? (4)
BNE LOOP ; No? Keeping looping (2)
* So I can view the resulting value when I reset the computer to break out
of the loop
So counting up the cycles to read the index mark, it's 10 to wait for it
to go true, 10 for it to go false, then 14 to increment a counter and go
back to the top of the loop.
The timing diagram of the M200 says that the Index Mark is pulsed for 6
microseconds. Now, if I'm computing this right, that is already less time
than it takes for the 6502 to wait for the pulse to fall back to false
from true. The 6502 takes 10 cycles, or roughly 10 microseconds, assuming
a cycle is equivalent to a microsecond.
Further, the timing diagram of the M200 shows that there are 1314
microseconds of time to read the column data, and 2014 microseconds
between Index Marks. This should be enough time for the 6502 to read and
store the data, then loop again.
This is one fast reader. But too fast for the 6502 me thinks.
Not really if you do one several possible things:
1. Generate an interrupt from the index mark (can the 6522/card do this?)
Or
2. Put a oneshot or flip flop on the index mark signal so its pulse can be
seen by the 6502...
~500 cycles per second is not a problem, the 6 uSec strobe is...
I'm
trying to troubleshoot a more pressing problem right now: the reader
is picking 5 cards before the Apple thinks 80 Index Marks (e.g. 80
characters) have been detected. Either my code is wrong, my code is slow,
or the Apple is too slow to handle the reader input (in which case this
was all for naught).
It sounds like something is wrong. Are you reading with BASIC
or at code level. I would think that assembly code should be able
to keep up, as long as you were not expecting it to transfer to
disk while reading. Does the M200 have any kind of handshake?
:(
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
Peter Wallace
Mesa Electronics
12:13 p.m.
On Thu, 2 Jan 2003, Peter C. Wallace wrote:
Yes, it can. But I'd rather not get into interrupt programming at this
point. Maybe at a later phase when I polish this up.
This is one
fast reader. But too fast for the 6502 me thinks.
Not really if you do one several possible things:
1. Generate an interrupt from the index mark (can the 6522/card do this?) 2. Put a oneshot or flip flop on the index mark signal
so its pulse can be
seen by the 6502...
Now that can be done pretty handily with the 6522. I can switch the IM
signal to one of the control lines, which will latch the signal. Good
idea ;)
Now I'll have to get that CA1 control line working for sure, which I've
been avoiding since it still seems dodgy, even with the pull-up. I'm
already using the CA2, CB1 and CB2 lines for other signals.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
1:34 p.m.
It was thus said that the Great Sellam Ismail once stated:
On Thu, 2 Jan 2003, Dwight K. Elvey wrote:
I'm not so sure. Here's what I know:
6502 operates at roughly 1,000,000 cycles per second.
I wrote a very tight code loop to simply look for the READY signal from
the reader, and then count Index Marks, as quickly as it can. Here's the
relevant loop code (the number is parentheses at the end of the comment
is the number of cycles that instruction takes):
LDX #$00
LOOP LDA $C0C1 ; Get the data at 6522 Port A (4)
AND #$08 ; Bit 4 is the RDY signal input (4)
BEQ LOOP ; Loop until it goes true (2)
WAIT LDA $C0C1 ; Now wait until it goes false (4)
AND #$08 ; (4)
BEQ WAIT ; (2)
INX ; Increment the count (2)
INC $06 ; Increment a zero page location* (6)
CPX #$50 ; 80 Index Marks yet? (4)
BNE LOOP ; No? Keeping looping (2)
First off, while I can't say this for sure on the 6502, I do know that the
6809 had two cycle counts for the various branches; one for branch taken and
one for not (although that may have been for the long branches---my
reference material is packed away somewhere), so you may be one or two
cycles off your count.
Now, going through the code:
LOOP LDA $C0C1 ; (4)
AND #$08 ; (4)
BEQ LOOP ; (2) - loop back if bit is zero
WAIT LDA $C0C1 ; (4)
AND #$08 ; (4)
BEQ WAIT ; (2) - loop back if bit is zero
Now, are you *sure* that is what you want? Your comments on LOOP make
sense---wait until the bit goes 1, but for WAIT, you say you are waiting
until it goes zero, but the code doesn't match that comment.
That might be your problem right there.
Since my 6502 reference is packed away (sigh---most of my computer
reference is packed away) does the INX/DEX instructions affect the flags?
If so, you may be able to shave some time off:
LDX #80
LOOP LDA $C0C1 ; (4)
AND #$08 ; (4)
BEQ LOOP ; (2) (10 per loop)
WAIT LDA $C0C1 ; (4)
AND #$08 ; (4)
BNE WAIT ; (2) (10 per loop-bug fix as well?)
INC $06 ; (6)
DEX ; (2)
BNE LOOP ; (2)
Save four cycles if DEX does affect the flags.
I'm
trying to troubleshoot a more pressing problem right now: the reader
is picking 5 cards before the Apple thinks 80 Index Marks (e.g. 80
characters) have been detected. Either my code is wrong, my code is slow,
or the Apple is too slow to handle the reader input (in which case this
was all for naught).
It sounds like something is wrong. Are you reading with BASIC
or at code level. I would think that assembly code should be able
to keep up, as long as you were not expecting it to transfer to
disk while reading. Does the M200 have any kind of handshake? * So I can view the resulting value when I reset the
computer to break out
of the loop
So counting up the cycles to read the index mark, it's 10 to wait for it
to go true, 10 for it to go false, then 14 to increment a counter and go
back to the top of the loop.
The timing diagram of the M200 says that the Index Mark is pulsed for 6
microseconds. Now, if I'm computing this right, that is already less time
than it takes for the 6502 to wait for the pulse to fall back to false
from true. The 6502 takes 10 cycles, or roughly 10 microseconds, assuming
a cycle is equivalent to a microsecond.
Can you change the location of the status bit? If you can make it so that
bit 7 of $C0C1 is the status bit you can save four cycles per loop:
LOOP LDA $C0C1 ; (4)
BPL LOOP ; (2) wait until status bit goes high
WAIT LDA $C0C1 ; (4)
BMI WAIT ; (2) wait for status bit to go low
I think the 6502 sets flags on loading the accumulator; if so, then
changing the status bit to be bit 7 will cause the Negative Flag to reflect
the state of bit 7---this gets rid the explicit compare and brings you
within range.
-spc (But better check the flags for each instruction)
3:26 p.m.
On Thu, 2 Jan 2003, Sean 'Captain Napalm' Conner wrote:
Indeed, this is the case, as I found out after I finally dug up my copy of
the 6502 opcode timings. Branches expend an extra cycle if they are
taken.
LDX
#$00
LOOP LDA $C0C1 ; Get the data at 6522 Port A (4)
AND #$08 ; Bit 4 is the RDY signal input (4)
BEQ LOOP ; Loop until it goes true (2)
WAIT LDA $C0C1 ; Now wait until it goes false (4)
AND #$08 ; (4)
BEQ WAIT ; (2)
INX ; Increment the count (2)
INC $06 ; Increment a zero page location* (6)
CPX #$50 ; 80 Index Marks yet? (4)
BNE LOOP ; No? Keeping looping (2)
First off, while I can't say this for sure on the 6502, I do know that the
6809 had two cycle counts for the various branches; one for branch taken and
one for not (although that may have been for the long branches---my
reference material is packed away somewhere), so you may be one or two
cycles off your count. Now, going through the code:
LOOP LDA $C0C1 ; (4)
AND #$08 ; (4)
BEQ LOOP ; (2) - loop back if bit is zero
WAIT LDA $C0C1 ; (4)
AND #$08 ; (4)
BEQ WAIT ; (2) - loop back if bit is zero
Now, are you *sure* that is what you want? Your comments on LOOP make
sense---wait until the bit goes 1, but for WAIT, you say you are waiting
until it goes zero, but the code doesn't match that comment.
Sorry, typo. The BEQ in the WAIT loop should be a BNE.
That might be your problem right there.
The code was correct. My transliteration was not.
Since my 6502 reference is packed away (sigh---most
of my computer
reference is packed away) does the INX/DEX instructions affect the flags?
Yes, they do.
If so, you may be able to shave some time off:
LDX #80
LOOP LDA $C0C1 ; (4)
AND #$08 ; (4)
BEQ LOOP ; (2) (10 per loop)
WAIT LDA $C0C1 ; (4)
AND #$08 ; (4)
BNE WAIT ; (2) (10 per loop-bug fix as well?)
INC $06 ; (6)
DEX ; (2)
BNE LOOP ; (2)
Save four cycles if DEX does affect the flags.
Well, this was just test code and the timing doesn't matter too much. It
just affirmed that not all the Index Mark signals were being caught in
time (56 out of 80 was average).
Can you change the location of the status bit? If
you can make it so that
bit 7 of $C0C1 is the status bit you can save four cycles per loop:
LOOP LDA $C0C1 ; (4)
BPL LOOP ; (2) wait until status bit goes high
WAIT LDA $C0C1 ; (4)
BMI WAIT ; (2) wait for status bit to go low
Yes and no. This would indeed save cycles, but logically it would break
my decoder routine.
I've re-worked the inputs and the reader control code and now have the
Index Marks latch into CA1 (I finally got it to work reliably with a 10K
pull-up resistor). Now when I get an Index Mark I have something like
2000 cycles to read the data and reset the IM latch (there are enough
cycles to decode the data in realtime, but I'll do that after I've got it
working right).
The problem I'm having now is timing out too quickly on the first column
read of the first card. According to the M200 docs I thought I had only
a few dozen microseconds to sense the first IM but it is timing out with
an 8-bit counter set to 255 and polling the IM signal in a loop that
takes about 14 cycles (14 * 255 = ~3500 cycles).
I'm alllllllmost there...
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
5:16 p.m.
New subject: Finally, SUCCESS! (Re: M200 interfacing continues...)
Ok, being that CA1 on my rig is definitely screwy, I moved the ERROR
signal (which hardly, if ever, gets triggered) over to it and moved the
Index Mark signal to CA2 (which is triggering reliably), fixed some bugs,
and I got one whole card read in!
The data was almost complete with some NULLs in the data. It turns out my
decoding routine was not properly decoding row 9. I fixed that and voila,
one (misinterpreted) FORTRAN code line!
I am using the IBM EBCDIC character table right now which is why I say
"misinterpreted". I just need to fix it to the classic FORTRAN character
set and that's it.
The way I designed this, I have a table that contains the characters for
the cards being read. You either have to know what character set the
cards are using or figure it out somehow, then load that character table
into the character space so the cards decode properly.
The last step will be to shoot the data out the serial port and I'll have
myself one punch card to serial data converter.
Thanks VERY, VERY much to all who helped, especially Mr. Lawson, Mr.
Duell, and Mr. Dunnington. Thanks also to Mr. McConnell for linking me
up with Doug Jones' punch card information, which was especially
invaluable. And of course, special thanks to David Gesswein for providing
the documenation which I used extensively throughout this project. It'll
be nice to get an original manual for the reader eventually (anyone have
a copy they're willing to part with? :)
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
5:22 p.m.
In the original message, Sellam said:
The timing diagram of the M200 says that the Index Mark is pulsed for 6
microseconds. Now, if I'm computing this right, that is already less time
than it takes for the 6502 to wait for the pulse to fall back to false
from true. The 6502 takes 10 cycles, or roughly 10 microseconds, assuming
a cycle is equivalent to a microsecond.
But in this message, Sellam said:
The problem I'm having now is timing out too quickly on the first column
read of the first card. According to the M200 docs I thought I had only
a few dozen microseconds to sense the first IM but it is timing out with
an 8-bit counter set to 255 and polling the IM signal in a loop that
takes about 14 cycles (14 * 255 = ~3500 cycles).
It actually sounds like the timing is 6 milliseconds, not 6 uSecs as
originally stated. If it is indeed 6 milliseconds, you then need to pause
for 6,000 cycles.
-spc (But it sounds like you may know that already ... )
6:40 p.m.
On Fri, 3 Jan 2003, Sean 'Captain Napalm' Conner wrote:
Actually, it is indeed 6 uSecs. The problem I eventually had was a dodgy
input on the 6522. Once I moved it to another pin it started working.
Peter Wallace's suggestion of moving it to a latched input was the key.
Since the signal is usually too fast for the Apple to catch while it is
doing other processing, latching it enabled the Apple to catch it, after
which there was plenty of time (~2000 cycles) to play with the data before
the next column is read.
I have the Index Mark input on CA2 and it's working flawlessly.
I just ran a few batches of the different cards I am converting and
everything is coming out swimmingly.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
The problem
I'm having now is timing out too quickly on the first column
read of the first card. According to the M200 docs I thought I had only
a few dozen microseconds to sense the first IM but it is timing out with
an 8-bit counter set to 255 and polling the IM signal in a loop that
takes about 14 cycles (14 * 255 = ~3500 cycles).
It actually sounds like the timing is 6 milliseconds, not 6 uSecs as
originally stated. If it is indeed 6 milliseconds, you then need to pause
for 6,000 cycles. 
7:13 p.m.
On Fri, 3 Jan 2003, Sellam Ismail wrote:
I just ran a few batches of the different cards I am converting and
everything is coming out swimmingly.
Bravo, Sellam! Really great work! Seems a simple modification to the
program would allow it to read paper tape as well.....
Cheers
John
11:44 p.m.
On Fri, 3 Jan 2003, John Lawson wrote:
Bravo, Sellam! Really great work! Seems a simple
modification to the
program would allow it to read paper tape as well.....
Actually, I was eyeing the pinouts of that paper tape reader that was
posted and was thinking, "Hey, I can build an interface for that" ;)
Actually, my next task like this will probably be to get one of my paper
tape readers interface so I can start dumping all these paper tapes I have
from different systems.
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
3 Jan
3 Jan
8:32 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1342 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20030103/5f79ae94/at…
7975
days inactive
7976
days old
11 comments
6 participants
participants (6)
-
ard＠p850ug1.demon.co.uk -
dwightk.elvey＠amd.com -
foo＠siconic.com -
jpl15＠panix.com -
pcw＠mesanet.com -
spc＠conman.org