5 Apr
2009
5 Apr
'09
2:06 a.m.
Did you try this copy of the code? It appears to have
the data file
in plain-text (atext.txt).
<http://simh.trailing-edge.com/games/adventure.zip>
I tried that and atext.txt looks better, but the fortran source files are
still messed up some how - at least they won't compile and the error
messages imply that there is still a record problem. I also tried a
precompiled executable with the improved atext.txt, but that doesn't work
either.
5 Apr
5 Apr
2:27 a.m.
Source files should not be giving you a 'record problem' (since they're text)
- but there is another potential issue. I downloaded some BASIC source files on a PC,
zipped them up and transferred them over to a VAX. I picked one to compile (this is BASIC
we're talking about), and it failed with an error per line. I opened up the file in
TPU and discovered that there was a 'spurious' CR at the end of each line. I
removed those and everything compiled and linked. Take a look at the line-level
translation that may be happening. -- Ian
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of
David Coolbear [david at thecoolbears.org]
Sent: Saturday, April 04, 2009 11:06 PM
To: cctech at classiccmp.org
Subject: Re: The VAX is running
Did you try this copy of the code? It appears to have
the data file
in plain-text (atext.txt).
<http://simh.trailing-edge.com/games/adventure.zip>
I tried that and atext.txt looks better, but the fortran source files are
still messed up some how - at least they won't compile and the error
messages imply that there is still a record problem. I also tried a
precompiled executable with the improved atext.txt, but that doesn't work
either.
4:27 p.m.
New subject: Text differences (Was: The VAX is running
On Sat, 4 Apr 2009, Ian King wrote:
Source files should not be giving you a 'record
problem' (since they're
text) - but there is another potential issue. I downloaded some BASIC
source files on a PC, zipped them up and transferred them over to a VAX.
I picked one to compile (this is BASIC we're talking about), and it
failed with an error per line. I opened up the file in TPU and
discovered that there was a 'spurious' CR at the end of each line. I
removed those and everything compiled and linked. Take a look at the
line-level translation that may be happening. -- Ian
New-line is not really standardized.
Although the machines may all claim to be using ASCII,
newline may be represented by
CR LF,
CR,
LF,
or LF CR (rarest)
The reasons are enough for a thread of its own.
5:43 p.m.
New subject: Text differences (Was: The VAX is running
On 5 Apr 2009 at 13:27, Fred Cisin wrote:
New-line is not really standardized.
Although the machines may all claim to be using ASCII,
newline may be represented by
CR LF,
CR,
LF,
or LF CR (rarest)
The reasons are enough for a thread of its own.
The CDC STAR OS used US as an EOL character. It was useful on a batch-
input OS; one could organize a job with US, RS, GS and FS characters.
Files consisting of groups of records consisting of units. Makes
sense--and odd that it wasn't more widely adopted. One would
logically assume that the matter of carriage control would be treated
as an issue of formatting, not of delimiting information.
Cheers,
Chuck
5:53 p.m.
New subject: Text differences (Was: The VAX is running
On Sunday 05 April 2009 05:43:02 pm Chuck Guzis wrote:
On 5 Apr 2009 at 13:27, Fred Cisin wrote:
I remember seeing those and thinking that something of that sort would be a
good idea, and wondering if it were actually being done that way. Sometime
around the point in time when I first ran across definitions of all that
ASCII stuff...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
New-line is not really standardized.
Although the machines may all claim to be using ASCII,
newline may be represented by
CR LF,
CR,
LF,
or LF CR (rarest)
The reasons are enough for a thread of its own.
The CDC STAR OS used US as an EOL character. It was useful on a batch-
input OS; one could organize a job with US, RS, GS and FS characters.
Files consisting of groups of records consisting of units. Makes
sense--and odd that it wasn't more widely adopted. One would
logically assume that the matter of carriage control would be treated
as an issue of formatting, not of delimiting information.
8:57 p.m.
New subject: Text differences (Was: The VAX is running
On 5 Apr 2009 at 17:53, Roy J. Tellason wrote:
I remember seeing those and thinking that something of
that sort would
be a good idea, and wondering if it were actually being done that
way. Sometime around the point in time when I first ran across
definitions of all that ASCII stuff...
One of the terminal collectors (Richard?) could verify this, but I
believe that in page edit mode, the Beehive Superbee used US as an
end-of-line character.
--Chuck
6 Apr
6 Apr
8:39 a.m.
New subject: Text differences (Was: The VAX is running
In article <49D8F127.29445.52ED813C at cclist.sydex.com>,
"Chuck Guzis" <cclist at sydex.com> writes:
On 5 Apr 2009 at 17:53, Roy J. Tellason wrote:
Probably, although I can't confirm that specifically. The Beehive
terminals did so many damned weird things, though!
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
I remember seeing those and thinking that
something of that sort would
be a good idea, and wondering if it were actually being done that
way. Sometime around the point in time when I first ran across
definitions of all that ASCII stuff...
One of the terminal collectors (Richard?) could verify this, but I
believe that in page edit mode, the Beehive Superbee used US as an
end-of-line character. 
5:35 p.m.
New subject: Text differences (Was: The VAX is running
On Mon, Apr 6, 2009 at 8:39 AM, Richard <legalize at xmission.com> wrote:
Probably, although I can't confirm that
specifically. ?The Beehive
terminals did so many damned weird things, though!
I wish I still had my Beehive terminal - I got it from OCLC in the
mid-1980s, but it was damaged in a flood a few years later and was too
rusted for me to think about repairing (I lost a Diablo 30 "RK03" in
the same flood).
I remember having problems getting it strapped right to work with a
PDP-8 or a PDP-11 - it was a strange beast.
-ethan
5 Apr
5 Apr
11:17 p.m.
New subject: Text differences (Was: The VAX is running
Chuck Guzis wrote:
The CDC STAR OS used US as an EOL character. It was useful on a batch-
input OS; one could organize a job with US, RS, GS and FS characters.
Files consisting of groups of records consisting of units. Makes
sense--and odd that it wasn't more widely adopted.
One would
logically assume that the matter of carriage control would be treated
as an issue of formatting, not of delimiting information.
The Zed language (sibling to C) used one of the separator ASCII characters for
end-of-line (IIRC it was RS) for these sorts of reasons. It was nice for
clarity and helping to avoid ambiguity.
6:17 p.m.
New subject: Text differences (Was: The VAX is running
New-line is not really standardized.
Although the machines may all claim to be using ASCII,
newline may be represented by
CR LF,
CR,
LF,
or LF CR (rarest)
Or none of those. VMS and PDP-11 operating systems that use RMS often
use sequential variable length record format, in which each record
starts with a byte count followed by data, but no end of line character.
The record boundary is end of line. OS/360 does the same thing.
Then there were the CDC 60-bit operating systems, where EOL is defined
as a 60-bit word ending in 2 or more 6-bit characters of 00.
paul
8:49 p.m.
New subject: Text differences (Was: The VAX is running
On 5 Apr 2009 at 18:17, Paul Koning wrote:
Then there were the CDC 60-bit operating systems,
where EOL is defined
as a 60-bit word ending in 2 or more 6-bit characters of 00.
That 00 character sure got overloaded didn't it? You could put two
colons in a row only if they fell in the right place. Lowercase
alpha was later added by prefixing each lowercase character with 00
and using a different character for colon.
7600 SCOPE 2 Record Manager used I-type records quite a bit with a
word prefixing the record giving byte count and other information--
later supported by 6RM/CRM, but the older Z-type record was too
firmly established.
<off topic>
7600 SCOPE fascinated me with its approach of nested FLs according to
privilege, with differing RAs. So you had a Matryushka doll setup
with the user inside of Record Manager, inside of Buffer Manager,
inside of Job Supervisor (or something like that; it's been too
long). The notion fascinated me enough that as an experiment. I
modified 6000 TCM to provide the same sort of service--I tried to
work it into a proposal, but the project got canceled before the spec
could be published.
</off topic>
Cheers,
Chuck
4:39 p.m.
At 02:06 AM 4/5/2009, David Coolbear wrote:
Frequently you can fix record formats using TECO.
$ DEFINE TECINI
$ EDIT/TECO foo.for
* EX$$
(TECO prompts with "*", you type 'EX<escape><escape>' to
exit.)
-Rick
Did you try
this copy of the code? It appears to have the data file
in plain-text (atext.txt).
<http://simh.trailing-edge.com/games/adventure.zip>
I tried that and atext.txt looks better, but the fortran source files are
still messed up some how - at least they won't compile and the error
messages imply that there is still a record problem. I also tried a
precompiled executable with the improved atext.txt, but that doesn't work
either.
5567
days inactive
5568
days old
11 comments
10 participants
participants (10)
-
cclist＠sydex.com -
cisin＠xenosoft.com -
david＠thecoolbears.org -
ethan.dicks＠gmail.com -
hilpert＠cs.ubc.ca -
IanK＠vulcan.com -
legalize＠xmission.com -
Paul_Koning＠Dell.com -
rick＠rickmurphy.net -
rtellason＠verizon.net