Re: Converting C for KCC on TOPS20

[Warner Losh via cctalk]

On Tue, Dec 10, 2019 at 5:53 PM Sean Conner via cctalk <
cctalk@classiccmp.org> wrote:

> It was thus said that the Great David Griffith via cctalk once stated:
> >
> > I'm trying to convert some C code[1] so it'll compile on TOPS20 with
> KCC.
> > KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker,
> which
> > has a limit of six case-insentive characters.  Adam Thornton wrote a
> Perl
> > script[2] that successfully does this for Frotz 2.32.  The Frotz
> codebase
> > has evolved past what was done there and so 2.50 no longer works with
> > Adam's script.  So I've been expanding that script into something of my
> > own, which I call "snavig"[3].  It seems to be gradually working more
> and
> > more, but I fear the problem is starting to rapidly diverge because it
> > still doesn't yield compilable code even on Unix.  Does anyone here have
> > any knowledge of existing tools or techniques to do what I'm trying to
> do?
>
>   If you are doing this on Linux, an approach is to compile the code there,
> then run 'nm' over the object files, and it will output something like:
>
> [spc]lucy:~/source/boston/src>nm main.o
> 00ef t CgiMethod
>  U CgiNew
>  r __PRETTY_FUNCTION__.21
>  U __assert_fail
>  U crashreport_core
>  U crashreport_with
>  U gd
>  U gf_debug
>  T main
>  U main_cgi_get
>  U main_cgi_head
>  U main_cgi_post
>  U main_cli
>
>   The last column are identifiers; the second column is the type of
> identifier, and the first column is the value.  What you want to look for
> are types 'T' (externally visible function), 'C' (externally visible
> constant data) and 'D' (externally visible data).  It is these identifiers
> that will need to be six unique characters long.
>
> Something like:
>
> [spc]lucy:~/source/boston/src>nm globals.o  | grep ' [CDT] '
> 0041 T GlobalsInit
> 0004 C c_adtag
> 0004 C c_class
> 0004 D c_conversion
> 0004 C c_days
> 0004 C c_tzmin
>  D c_updatetype
> 0004 C c_webdir
> 0008 D cf_emailupdate
> 0004 C g_L
> 0004 C g_blog
> 0004 C g_templates
> 0020 D gd
> 0d09 T set_c_conversion
> 0beb T set_c_updatetype
> 0dbd T set_c_url
> 0cab T set_cf_emailupdate
>
> (but over all object files).  I would then generate unique six character
> long identifiers for each of these, and slap the output into a header file
> like:
>
> #define GlobalsInit id0001
> #define c_adtag id0002
> #define c_class id0003
> #define c_conversionid0004
>
> and then include this file for every compilation unit.  I think that would
> be the easiest thing to do.
>

You'd need to exclude libc symbols, though.

In a.out times you could just change the names from old to new and adjust
the string table offset to do this :)

Warner

Re: Converting C for KCC on TOPS20

[Sean Conner via cctalk]

It was thus said that the Great David Griffith via cctalk once stated:
> 
> I'm trying to convert some C code[1] so it'll compile on TOPS20 with KCC. 
> KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, which 
> has a limit of six case-insentive characters.  Adam Thornton wrote a Perl 
> script[2] that successfully does this for Frotz 2.32.  The Frotz codebase 
> has evolved past what was done there and so 2.50 no longer works with 
> Adam's script.  So I've been expanding that script into something of my 
> own, which I call "snavig"[3].  It seems to be gradually working more and 
> more, but I fear the problem is starting to rapidly diverge because it 
> still doesn't yield compilable code even on Unix.  Does anyone here have 
> any knowledge of existing tools or techniques to do what I'm trying to do?

  If you are doing this on Linux, an approach is to compile the code there,
then run 'nm' over the object files, and it will output something like:

[spc]lucy:~/source/boston/src>nm main.o
00ef t CgiMethod
 U CgiNew
 r __PRETTY_FUNCTION__.21
 U __assert_fail
 U crashreport_core
 U crashreport_with
 U gd
 U gf_debug
 T main
 U main_cgi_get
 U main_cgi_head
 U main_cgi_post
 U main_cli

  The last column are identifiers; the second column is the type of
identifier, and the first column is the value.  What you want to look for
are types 'T' (externally visible function), 'C' (externally visible
constant data) and 'D' (externally visible data).  It is these identifiers
that will need to be six unique characters long.

Something like:

[spc]lucy:~/source/boston/src>nm globals.o  | grep ' [CDT] ' 
0041 T GlobalsInit
0004 C c_adtag
0004 C c_class
0004 D c_conversion
0004 C c_days
0004 C c_tzmin
 D c_updatetype
0004 C c_webdir
0008 D cf_emailupdate
0004 C g_L
0004 C g_blog
0004 C g_templates
0020 D gd
0d09 T set_c_conversion
0beb T set_c_updatetype
0dbd T set_c_url
0cab T set_cf_emailupdate

(but over all object files).  I would then generate unique six character
long identifiers for each of these, and slap the output into a header file
like:

#define GlobalsInit id0001
#define c_adtag id0002
#define c_class id0003
#define c_conversionid0004

and then include this file for every compilation unit.  I think that would
be the easiest thing to do.

  -spc

Re: Converting C for KCC on TOPS20

[Warner Losh via cctalk]

any chance you can post-process the .obj files?

Warner


On Tue, Dec 10, 2019 at 5:26 PM David Griffith via cctalk <
cctalk@classiccmp.org> wrote:

>
> I'm trying to convert some C code[1] so it'll compile on TOPS20 with KCC.
> KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, which
> has a limit of six case-insentive characters.  Adam Thornton wrote a Perl
> script[2] that successfully does this for Frotz 2.32.  The Frotz codebase
> has evolved past what was done there and so 2.50 no longer works with
> Adam's script.  So I've been expanding that script into something of my
> own, which I call "snavig"[3].  It seems to be gradually working more and
> more, but I fear the problem is starting to rapidly diverge because it
> still doesn't yield compilable code even on Unix.  Does anyone here have
> any knowledge of existing tools or techniques to do what I'm trying to do?
>
> This is part of a project to get Infocom and other Z-machine games running
> once again on PDP10 mainframes, either real or emulated.  First up is to
> get the bare minimum of a current Z-machine emulator running on TOPS20.
> Then we can work on screen-handling, a disk pager[4], and porting to other
> PDP10 operating systems.  I'm hoping that this will lead to fun exhibits
> wherever PDP10s are displayed in museum or faire settings.
>
>
> [1] https://gitlab.com/DavidGriffith/frotz
> [2] https://github.com/athornton/gnusto-frotz-tops20
> [3] Change an objects shape.
> [4] Infocom's Z-machine emulators paged zcode from disk, but Frotz simply
> sucks the whole zcode file into memory.
>
>
> --
> David Griffith
> d...@661.org
>
> 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?
>

Converting C for KCC on TOPS20

[David Griffith via cctalk]

I'm trying to convert some C code[1] so it'll compile on TOPS20 with KCC. 
KCC is mostly ANSI compliant, but it needs to use the TOPS20 linker, which 
has a limit of six case-insentive characters.  Adam Thornton wrote a Perl 
script[2] that successfully does this for Frotz 2.32.  The Frotz codebase 
has evolved past what was done there and so 2.50 no longer works with 
Adam's script.  So I've been expanding that script into something of my 
own, which I call "snavig"[3].  It seems to be gradually working more and 
more, but I fear the problem is starting to rapidly diverge because it 
still doesn't yield compilable code even on Unix.  Does anyone here have 
any knowledge of existing tools or techniques to do what I'm trying to do?


This is part of a project to get Infocom and other Z-machine games running 
once again on PDP10 mainframes, either real or emulated.  First up is to 
get the bare minimum of a current Z-machine emulator running on TOPS20. 
Then we can work on screen-handling, a disk pager[4], and porting to other 
PDP10 operating systems.  I'm hoping that this will lead to fun exhibits 
wherever PDP10s are displayed in museum or faire settings.



[1] https://gitlab.com/DavidGriffith/frotz
[2] https://github.com/athornton/gnusto-frotz-tops20
[3] Change an objects shape.
[4] Infocom's Z-machine emulators paged zcode from disk, but Frotz simply 
sucks the whole zcode file into memory.



--
David Griffith
d...@661.org

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?

Re: FTGH - SORD Keyboard

[Zane Healy via cctalk]

> On Dec 10, 2019, at 3:54 PM, Kevin Parker via cctalk  
> wrote:
> 
> Was going through a box of stuff someone gave me ages ago in keeping with my 
> philosophy of grab first ask questions later.
> 
> At the bottom found a SORD keyboard (regrettably not the whole thing) - looks 
> like it comes from a M68. Photo:
> 
> http://koken.advancedimaging.com.au/index.php?/albums/interesting-finds/content/sord-m68-keyboard/
> 
> As this is all I have of a SORD (so I am unable to test it) I figure it may 
> be of use to someone else on this list.
> 
> (Would appreciate coverage of package and postage from Mortlake Victoria 
> Australia 3272 please. Please note that its the size of a keyboard and is a 
> little weighty so you'll need to factor that in. Alternatively I will be in 
> Melbourne in January 2020 if someone more "local" wants it).
> 
> Thank you.
> 
> 
> Kevin Parker

Inquiring minds want to know what the story is with that other photo!

Zane

FTGH - SORD Keyboard

[Kevin Parker via cctalk]

Was going through a box of stuff someone gave me ages ago in keeping 
with my philosophy of grab first ask questions later.


At the bottom found a SORD keyboard (regrettably not the whole thing) - 
looks like it comes from a M68. Photo:


http://koken.advancedimaging.com.au/index.php?/albums/interesting-finds/content/sord-m68-keyboard/

As this is all I have of a SORD (so I am unable to test it) I figure it 
may be of use to someone else on this list.


(Would appreciate coverage of package and postage from Mortlake Victoria 
Australia 3272 please. Please note that its the size of a keyboard and 
is a little weighty so you'll need to factor that in. Alternatively I 
will be in Melbourne in January 2020 if someone more "local" wants it).


Thank you.


Kevin Parker

Re: DECpc 425SE

[Antonio Carlini via cctalk]

On 07/12/2019 18:10, Antonio Carlini via cctalk wrote:



I'm going to set it to one side for now and get to the same stage with 
the Acorn A3000 (which looks OK but the battery really has to come out 
now ... it will eventually fail I suppose).



I might as well tackle both at the same time ...

I've unsoldered the battery lugs from the PCB and removed the battery 
that way. The PCB has the +ve side marked (it's the end by R337).


Once I mechanically peeled the lugs off the battery I could see the 
battery is a 3V Panasonic VL1220 rechargeable Lithium Vanadium Pentoxide 
and they're still available on eBay and Farnell (and probably everywhere 
else too ...).


If I'm going to replace it I'd prefer to do it in a way that leaves it 
(more) easily removable, so that if I decide that the machine goes back 
in a box, it can do so without a ticking time-bomb in it!


I think I want to find a suitable "IC-socket-style" connector (well, 
connectors I guess) that I can solder to the PCB and then slot a battery 
into. I guess it needs to be quite low profile to avoid fouling when it 
all gets put back together.


An alternative might be to use a small push-fit socket for the battery, 
hide that somewhere convenient in the system (I think there is room by 
the HDD) and then use flying leads back to the PCB.


Any ideas (I'm not sure of what terms to feed a search engine ...)


Antonio



--
Antonio Carlini
anto...@acarlini.com

Re: RSTS emulation in a browser

[John Foust via cctalk]

At 02:04 PM 12/10/2019, Boris Gimbarzevsky wrote:
>Downloaded files for previous PDP-11 emulator but couldn't get it to run.  
>Link to German site at bottom of your post works fine and Unix runs about same 
>speed that it ran on my 11/34 in 1983.  Scary that coding a PDP-11 emulator in 
>an incredibly inefficient scripting language such as Javascript matches speed 
>of the machine I was using back then.

Google says JavaScript is now only two to seven times slower than C++.

https://www.youtube.com/watch?v=UJPdhx5zTaw
 

https://blog.reactiveconf.com/5-reasons-why-javascript-is-eating-the-world-bbc4aca0a527
 

- John

Re: RSTS emulation in a browser

[Boris Gimbarzevsky via cctalk]

Downloaded files for previous PDP-11 emulator but couldn't get it to 
run.  Link to German site at bottom of your post works fine and Unix 
runs about same speed that it ran on my 11/34 in 1983.  Scary that 
coding a PDP-11 emulator in an incredibly inefficient scripting 
language such as Javascript matches speed of the machine I was using 
back then.  That slowness just applies to Unix; all of my code back 
then was written in PDP-11 assembler which allowed data sampling at 
20 KHz from A/D and essentially bypassed most of RT-11 to get 
speed.  Will play around more with this emulator when have time.


Unfortunately, a lot of people now seem to think that Javascript can 
be used to code large projects such as the provincial system which 
allows one to access patients reports and lab results from whole 
province; my comment to them was that it does a great simulation of a 
paper chart but also emulating a sloth with a fondness for 
barbiturates turning chart pages made it essentially useless.



At 10:51 PM 12/9/2019, Jay Jaeger wrote:
>No, not necessarily.  A web server provides a content header based on
>its own internal configuration.  For local files, it is determined
>locally, and so might be different.
>
>Also it is possible that there are some file references in there that
>are not purely relative or that there is another file that is not there.
> One would have to look at the .html and .js files to see.

The code looks pretty flat; no folders.  It didn't even need any
tweaks for file permissions when I uploaded to a web server.  The
HTML mentions two .js files fpp.js and vg11.js that aren't present
on his web or in the zip, but it runs without them.  It's not trying
to write back to the DSK files, it just keeps an in-memory cache
when it's running.  I imagined it was something related to security
in a local browser.

I tried emailing the author but no response yet.

http://pdp11.aiju.de/ seems to be a 
different, simpler PDP emulator

written in JavaScript.

- John

Re: RSTS emulation in a browser

[John Foust via cctalk]

At 10:51 PM 12/9/2019, Jay Jaeger wrote:
>No, not necessarily.  A web server provides a content header based on
>its own internal configuration.  For local files, it is determined
>locally, and so might be different.
>
>Also it is possible that there are some file references in there that
>are not purely relative or that there is another file that is not there.
> One would have to look at the .html and .js files to see.

The code looks pretty flat; no folders.  It didn't even need any 
tweaks for file permissions when I uploaded to a web server.  The 
HTML mentions two .js files fpp.js and vg11.js that aren't present 
on his web or in the zip, but it runs without them.  It's not trying 
to write back to the DSK files, it just keeps an in-memory cache 
when it's running.  I imagined it was something related to security 
in a local browser.

I tried emailing the author but no response yet.

http://pdp11.aiju.de/ seems to be a different, simpler 
PDP emulator
written in JavaScript.

- John