11 Apr
2002
11 Apr
'02
7:24 p.m.
I've been doing some web searching and reading the "TV Typewriter"
book concerning puched tape encoding schemes, and I'm a bit confused.
I've written a program to punch tape on my PC, and a short bit of code
to read the tapes on my IMSAI 8080, but there are some problems.
Since the unpunched tape leader looks just like a "zero" to the tape
reader, I usually end up with some extra 0's at the start of my
programs on the IMSAI. Also, I have a feeling that the tape reader
may "eat" some of the codes if they're things like X-ON, X-OFF, etc,
although I may be wrong. If I'm going to do something along the lines
of using two 4-bit values to represent each byte, or an escape code to
distinguish real 0's from leading blanks, and maybe include a
full-width (FF) punch every foot or so to allow for easy folding,
while having the reader software ignore them, I'd like to follow some
kind of established standard. Can anyone give me any pointers on
this?
-Bill Richman (bill_r(a)inetnebr.com)
Web Page: http://incolor.inetnebr.com/bill_r
Home of the COSMAC Elf Microcomputer Simulator, Fun with
Molten Metal, Orphaned Robots, and Technological Oddities.
11 Apr
11 Apr
7:59 p.m.
You could look at Motorola .S19 files or Intel Hex
files. Both have a lot more overhead than pure binary
but they will definitely solve your problems at the
beginning and end of the tape. I'm certain that
someone has already written this and I think I have an
example in an old Byte maganize. I wrote a binary to
Moto S19 and binary to Intel Hex in VB not because no
one had ever done it before, but so that I was sure I
understood them.
I am in a similar situation; I've been thinking about
a short bootloader you key in that reads the first
64/128/256 bytes of the paper tape starting with the
first nonzero byte (you code it this way), and then
executes it. This code is the .s19/Intel Hex loader
(which is going to be much more complex). Then, you
load your stuff in .s19/Intel Hex. Both code chunx
could be on the same tape, theoretically. This, too,
has been done before.
BTW, I'm working on the Hazeltine. The keytops were
actually PUTTY, not BROWN! I had to polish them
individually with sandpaper and car rubbing compound
but they now look new. Haven't started on the
electronics but am confident that I can do it.
--- Bill Richman <bill_r(a)inetnebr.com> wrote:
I've been doing some web searching and reading
the
"TV Typewriter"
book concerning puched tape encoding schemes, and
I'm a bit confused.
I've written a program to punch tape on my PC, and a
short bit of code
to read the tapes on my IMSAI 8080, but there are
some problems.
Since the unpunched tape leader looks just like a
"zero" to the tape
reader, I usually end up with some extra 0's at the
start of my
programs on the IMSAI. Also, I have a feeling that
the tape reader
may "eat" some of the codes if they're things like
X-ON, X-OFF, etc,
although I may be wrong. If I'm going to do
something along the lines
of using two 4-bit values to represent each byte, or
an escape code to
distinguish real 0's from leading blanks, and maybe
include a
full-width (FF) punch every foot or so to allow for
easy folding,
while having the reader software ignore them, I'd
like to follow some
kind of established standard. Can anyone give me
any pointers on
this?
-Bill Richman (bill_r(a)inetnebr.com)
Web Page: http://incolor.inetnebr.com/bill_r
Home of the COSMAC Elf Microcomputer
Simulator, Fun with
Molten Metal, Orphaned Robots, and
Technological Oddities.
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
8:18 p.m.
On Thu, Apr 11, 2002 at 11:24:49PM -0500, Bill Richman wrote:
although I may be wrong. If I'm going to do
something along the lines
of using two 4-bit values to represent each byte, or an escape code to
distinguish real 0's from leading blanks, and maybe include a
full-width (FF) punch every foot or so to allow for easy folding,
while having the reader software ignore them, I'd like to follow some
kind of established standard. Can anyone give me any pointers on
this?
For programs, the encoding schemes I've seen generally divide the data
into blcoks. You skip tape until you find a block header; then you read
a given amount of tape and checksum it. You stick the data at a current
address and increment the current address. At the end of the tape (marked
by a zero-length block or some other format) you jump to a given starting
address. If the load goes bad, it's usually possible to reread only the
bad block rather than the entire tape.
If the loader has to be read from tape you'll often see a multistage
loading process -- toggle in tiny loader, which reads bigger loader,
which stays in memory and can read everything else. There have been
some very elegant tiny loaders -- I believe one of the Ellliott machines
had a particularly nice one, but I forget the details.
For data, the common practice seems to be to dictate "these characters
will be ignored on data tapes and those may not appear". That solves the
problem of control characters and leader and rubouts; also you can use
the high bit for parity.
pointers:
RIM mode on the PDP-1 (described in the PDP-1 Handbook which you can find
online); RIM and other loades on the PDP-6 and PDP-10, described in various
manuals which you can also find online (look on Al Kossow's site); RIM and
BIN loaders on the PDP-8, described in the Small Computer Handbook and other
places (I'm sure there's tons of PDP-8 information out there but I don't
know where offhand). Those machines have word sizes that are multiples
of 6, so they generally read 6 bits out of 8.
Motorola S-records (each one starts with the letter "S") were very popular
and may still be. They encode each byte as two hex digits so they are
long but avoid special characters.
The OS/8 handbook for the PDP-8 discusses formatting of data tapes.
Probably many others that I don't know about. There's also the subject
of reading (and booting from) punch cards but never mind that for now.
-- Derek
12 Apr
12 Apr
6:08 a.m.
Derek Peschel wrote:
The OS/8 handbook for the PDP-8 discusses formatting
of data tapes.
Probably many others that I don't know about. There's also the subject
of reading (and booting from) punch cards but never mind that for now.
* a sample bootstrap for the 8080
* from a VDM-1 manual
* starts at 0 and loads 256 bytes of data and jumps to start when done
beg lxi h,start
sphl
mov c,h
call in
cpi 7fh
jnz beg
chrin dcr c
jz start
call in
mov m,a
inx h
jmp chrin
in in sport get char status
ani smask check status
jz in
in dport get char
ret
ds 2 stack space
start
* program goes here
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
8:46 a.m.
Bill Richman wrote:
I've been doing some web searching and reading the
"TV Typewriter"
book concerning puched tape encoding schemes, and I'm a bit confused.
...
while having the reader software ignore them, I'd
like to follow some
kind of established standard. Can anyone give me any pointers on
this?
I can tell you about the MOS Technology paper tape format, as used
by the KIM-1 and some other 6502-based machines. It's also a format
that some EPROM programmers accept, but unlike Motorola S-Records,
it's limited to a 16-bit address space.
http://www.gifford.co.uk/~coredump/mosptp.htm
This format is used by the Compukit UK101's Extended Monitor. The UK101
documentation calls it "checksum format".
--
John Honniball
coredump(a)gifford.co.uk
9:15 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2035 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20020412/597b242c/at…
8133
days inactive
8134
days old
5 comments
6 participants
participants (6)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
bill_r＠inetnebr.com -
coredump＠gifford.co.uk -
dpeschel＠eskimo.com -
sloboyko＠yahoo.com