Re: [Simh] Kaypto II
my thoughts for what they are worth... On Tue, Jun 30, 2015 at 7:57 PM, Kevin Handy khandy2...@gmail.com wrote: Should I make a new kp2 display device, or add parameters to the fw code? If there is a way to split the fw code into mapped display common code and then fw and kp2 specific. Then a new kp2 device that sets up the spec stuff and calls the common code seems like a good idea. 2. the wd179x device is the right chip for the kp2, but it is single sided and different tracks/sectors. The side is controlled by an external ioreg. Modify the driver, or seperate it out? I'd suggest trying to add the ioreg and then define default values for the current emulation and the ability for the kp2 to set the ioreg as chip was used for the kp2. Clem ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] C64 and C128
I think maybe the simh doc too might have confused me a bit. 3.1.3 talks about word length, not addressability and that kind of confused me. I was looking into the PDPs and then commodore machines that ran CP/M which I guess was C128. I never had one. C64s and TRS-80 CoCos but not C128. So I began wondering word size? Which to me was a processor's register size. Not various system bus sizes. Addressability made me think of the address bus size and that varied. Well I wondered about a simh VM for the C128 that would use CP/M 2 or 3. Bill ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] C64 and C128
On 30-Jun-15 21:48, Rich Alderson wrote: [Snip] A great summary, to which I'll add a couple of additional infobits: The Intel 4004 (and 4040) use 4 bit data words, (mostly) 8-bit instruction words 12-bit addresses. (Some instructions use two 8-bit instruction words.) The external bus is 4 bits - different cycle types for ROM, RAM and I/O. Its documentation calls 8 bits both a word and a byte, and its 4-bit word a 'character'. Welcome to the wild world of early computing; all terms are context-sensitive! Adding 8-bit binary numbers is double-precision, requiring several instructions. The CPU supports BCD as well. The device was designed for a calculator, so it's not quite as crazy as at seems. At ~90KIPS, it isn't exactly speedy - though I had a project that managed to do some speech synthesis with it (!). Some of its architecture can be seen in the x86. CPU architectures usually have some extensions (warts) for various reasons. For example, the Z80 is an 8-bit machine, but has some instructions that operate on 16 bits. It, like the 4004/40, x86 and VAX, has variable length instructions. Many support multiple precision data types (double is common); these consume/generate multiple 'words' of memory and/or registers. Floating point throws another wrench into simplicity: floating point numbers can have a word size that differs from integers. The PDP-10's idea of 'character' or byte is flexible. 36-bits comes from the 6-bit BCD character of some industry predecessors. But the PDP-10 supports variable-size bytes - from 1 to 36 bits at arbitrary alignment in words. Most text, by convention, is stored in 7-bit bytes. But 6, 8, 9 and 12-bit characters are commonly used in applications and the OS. The -10 survived the transitions from 6 to 7 to 8-bit characters without architectural change. And if it was active today, it would be equally happy with 16 and 32-bit Unicode characters as 'bytes'. Hardware supports single, double quad integers (modulo how the sign bit is handled). The implementation details can become visible, both functionally and for performance. The KL10 memory system groups 4 words into each cache line, and it clever enough to request them in the right order (requested word first). The VAX fetches instructions in aligned words (or multiples). This is visible architecturally in the required sequence for turning memory management on, and can have a significant impact on performance following a branch. Many modern CPUs have different data path widths internally from the external bus (and register size). And the 'bits per address' usually diverges as memory gets cheaper and programs larger. Memory address 'banking' and 'mapping' provide more physical memory than an instruction can address. So life gets complicated - especially so as caches and other modern micro-architectural innovations provide one view to the programmer in user mode, another to the OS programmer and yet another to the hardware. Not to mention the layers of compatibility evidenced in machines like the x86. The only good news is that just about everyone has adopted IEEE floating point format. Well, one of them. As a general rule, the 'word size' that most people use is the width in bits of an integer register. And addressing targets either 8-bit bytes or words that are the width of a native integer register. The external bus's data path may be either wider or narrower than the apparent address target. Narrower to save pins and simplify the hardware; wider to increase performance. The external bus's address also can be either wider or narrower than an instruction can generate. Wider as the architecture ages and more memory is needed. Narrower early on to simplify implementation and match the 'affordable' amount of memory. Sorry if this adds any confusion; the one invariant in computer architecture seems to be that if you wait long enough, complexity always increases. smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Announcing TCP/IP for RSX-11M-PLUS
This looks very cool. I wonder when the first web server running this stack will come online. I also notice the presence of an IRC client. Has anyone tried to chat from a PDP-11 yet? Mike On Jun 30, 2015 7:46 AM, Johnny Billquist b...@softjar.se wrote: I'm happy to announce a new release of TCP/IP for RSX-11M-PLUS. Since I'm broadening the scope of the announcement slightly, a more complete list of features is included, and not just what changed since last. For anyone who is currently running TCP/IP for RSX, I strongly encourage you to update to this latest version. Several improvements have gone in in the last couple of weeks. Most important change is that there now is telnet support, both client and server side. The TCP/IP for RSX that I've written is sometimes referred to as BQTCP/IP, just to make clear that it is a different product than Process Software's TCPWARE, or JSA's TCP/IP. BQTCP/IP is a rather feature rich TCP/IP implementation, which also comes with libraries for various high level languages. The API is not compatible, even at the source level, with Unix, but on the other hand, if people write some code, they will see that it is a very easy API to work with. The reasons for the incompatibilities are several, including both resource concerns and differences between how RSX works and Unix like operating systems. BQTCP/IP has tried to comply with all relevant RFCs, but I'm sure there are corners where it does not do things right. It also does not demand much resources. It do require RSX-11M-PLUS with split I/D space, and it has only been tested properly on RSX-11M-PLUS V4.6. It should work on any version 4 release of RSX-11M-PLUS, but there might be a couple of tweaks or fixes needed. BQTCP/IP is distributed in binary form, so very little compilation is required to get it up and running. However, pretty much all utilities do come with sources. The actual TCP/IP stack sources are not included. I do not have a good setup for distributing them in a sane way, and it has had a low priority on my list of things to do. But I do not mind distributing the sources as a general principle. All that said, BQTCP/IP current supports the following protocols: o Ethernet and loopback interfaces. o ARP. BQTCP/IP can use Ethernet in co-existance with DECnet, or standalone using the provided Unibus ethernet device driver. o IP. The largest IP packets supported are approximately 8KB. o ICMP. o UDP. The largest UDP packets supported are approximately 8KB. o TCP. The window is approximately 8KB in size, and TCP do manage out of order packets in an efficient way. BQTCP/IP supports the following applications: o DHCP. DHCP can be used to configure interface addresses, network masks, default gateways, DNS servers and NTP servers dynamically. o NTP. NTP can be used to set the local time. o TELNET. The TELNET server hooks in to the standard TT: terminal driver, and the number of terminals to create is configurable. The TELNET client can be used to connect to other systems. o FTP. The FTP server can serve all kind of files to other RSX systems, and can serve text and binary files to any system. The FTP client can retrieve RSX format files from RSX servers, and text, binary and block format files from any system. o TFTP. The TFTP server and client can be used for simpler file transfer operations. o RWHOD. RWHOD is a program that reports current users and uptime from RSX, for other systems to collect. o IRC. IRC is a program to communicate with other users around the world. o IRCBOT. IRCBOT is a small example robot program connecting to IRC and performing a service for IRC users. o PCL. PCL is a protocol for printing, used by HP (and other) printers over a network. The PCL implementation in BQTCP/IP appears as a print symbiont, which you can create a printer queue for. o WWW. WWW (or World Wide Web) is a service that can present hypertext information to clients. The WWW server in BQTCP/IP also supports CGI, which makes it possible to create dynamic content. o DNS. BQTCP/IP have DNS implemented as an ACP, that anyone can query to get translations between IP addresses and domain names. It also supports different users using different name servers, or private translations. o SINK. A standard TCP service. o ECHO. A standard TCP service. o DAYTIME. A standard TCP service. o QUOTD. A standard TCP service. o IDENTD. A standard TCP service. BQTCP/IP also have automatic IP spoof detection and prevention. Additional tools are IFCONFIG, PING, TRACEROUTE, NETSTAT as well as two new pages for RMD. High level language libraries exists for BASIC+2, PDP-11 C and FORTRAN-77. I'm sure I have forgotten a thing or three, but that's a fairly comprehensive list. The documentation is a weak point, but there is hopefully enough documentation to get people running, and I am happy to answer any questions, or give
Re: [Simh] Announcing TCP/IP for RSX-11M-PLUS
On 2015-07-01 23:08, Michael Kerpan wrote: This looks very cool. I wonder when the first web server running this stack will come online. I also notice the presence of an IRC client. Has anyone tried to chat from a PDP-11 yet? You mean apart from mine, as Madame.Update.UU.SE is already serving web-pages, and is running this software. Yes, I use that IRC client myself every day. (I'm also running this on a real 11/93 at home, by the way. Speed is pretty ok.) Johnny Mike On Jun 30, 2015 7:46 AM, Johnny Billquist b...@softjar.se mailto:b...@softjar.se wrote: I'm happy to announce a new release of TCP/IP for RSX-11M-PLUS. Since I'm broadening the scope of the announcement slightly, a more complete list of features is included, and not just what changed since last. For anyone who is currently running TCP/IP for RSX, I strongly encourage you to update to this latest version. Several improvements have gone in in the last couple of weeks. Most important change is that there now is telnet support, both client and server side. The TCP/IP for RSX that I've written is sometimes referred to as BQTCP/IP, just to make clear that it is a different product than Process Software's TCPWARE, or JSA's TCP/IP. BQTCP/IP is a rather feature rich TCP/IP implementation, which also comes with libraries for various high level languages. The API is not compatible, even at the source level, with Unix, but on the other hand, if people write some code, they will see that it is a very easy API to work with. The reasons for the incompatibilities are several, including both resource concerns and differences between how RSX works and Unix like operating systems. BQTCP/IP has tried to comply with all relevant RFCs, but I'm sure there are corners where it does not do things right. It also does not demand much resources. It do require RSX-11M-PLUS with split I/D space, and it has only been tested properly on RSX-11M-PLUS V4.6. It should work on any version 4 release of RSX-11M-PLUS, but there might be a couple of tweaks or fixes needed. BQTCP/IP is distributed in binary form, so very little compilation is required to get it up and running. However, pretty much all utilities do come with sources. The actual TCP/IP stack sources are not included. I do not have a good setup for distributing them in a sane way, and it has had a low priority on my list of things to do. But I do not mind distributing the sources as a general principle. All that said, BQTCP/IP current supports the following protocols: o Ethernet and loopback interfaces. o ARP. BQTCP/IP can use Ethernet in co-existance with DECnet, or standalone using the provided Unibus ethernet device driver. o IP. The largest IP packets supported are approximately 8KB. o ICMP. o UDP. The largest UDP packets supported are approximately 8KB. o TCP. The window is approximately 8KB in size, and TCP do manage out of order packets in an efficient way. BQTCP/IP supports the following applications: o DHCP. DHCP can be used to configure interface addresses, network masks, default gateways, DNS servers and NTP servers dynamically. o NTP. NTP can be used to set the local time. o TELNET. The TELNET server hooks in to the standard TT: terminal driver, and the number of terminals to create is configurable. The TELNET client can be used to connect to other systems. o FTP. The FTP server can serve all kind of files to other RSX systems, and can serve text and binary files to any system. The FTP client can retrieve RSX format files from RSX servers, and text, binary and block format files from any system. o TFTP. The TFTP server and client can be used for simpler file transfer operations. o RWHOD. RWHOD is a program that reports current users and uptime from RSX, for other systems to collect. o IRC. IRC is a program to communicate with other users around the world. o IRCBOT. IRCBOT is a small example robot program connecting to IRC and performing a service for IRC users. o PCL. PCL is a protocol for printing, used by HP (and other) printers over a network. The PCL implementation in BQTCP/IP appears as a print symbiont, which you can create a printer queue for. o WWW. WWW (or World Wide Web) is a service that can present hypertext information to clients. The WWW server in BQTCP/IP also supports CGI, which makes it possible to create dynamic content. o DNS. BQTCP/IP have DNS implemented as an ACP, that anyone can query to get translations between IP addresses and domain names. It also supports different users using different name servers, or private translations. o SINK. A standard TCP service. o ECHO. A standard TCP service. o DAYTIME. A
Re: [Simh] C64 and C128
Il 01/07/2015 12:13, Timothe Litt ha scritto: At ~90KIPS, it isn't exactly speedy - though I had a project that managed to do some speech synthesis with it (!). O_O Respect !! Best regards from Italy, dott. Piergiorgio. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] bits and bites
Is that F-831F ? It's all I can find from May 65. - Original Message - From: Jack Rubin To: simh@trailing-edge.com Sent: Wednesday, July 01, 2015 12:14 PM Subject: [Simh] bits and bites Just to add to the general hilarity, the PDP-8 Interface Manual (DEC publication F-83, May, 1965, page 6) states that The PDP-8 ... collects and distributes data in 12 bit bites. The manual is on bitsavers. Jack ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] C64 and C128
On Tue 30 Jun 2015 at 19:56:06 -0400, Bill Cunningham wrote: I remember those floppy drives where big and heavy. I never had cp/m or a c128. I am reading that an 8502 and Z80A (which I can't find anything on) was inside. The Z80A was about 4 MHz. The Z80A word size I do not know. It was of course an 8 bit with a 16 bit address bus I believe. Now which is memory word size? If you want to play with the C64 and its siblings, you can have a look at VICE, the Versatile Commodore Emulator, http://vice-emu.sourceforge.net/ -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpy7f4cZTuhz.pgp Description: PGP signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Using an ODS-2 physical SCSI drive with simh
Hi Peter, It ‘should’ work just fine, but Christian’s suggestions to work from a copy are quite reasonable. The latest simh code from github can be used to make this copy for you: sim set rq2 rauser sim ! On Windows sim attach rq2 –fc raw Raw-Disk-Image.vhd \\.\PhysicalDrive1 sim ! On Linux sim attach rq2 –fc raw Raw-Disk-Image.vhd /dev/sdb -Mark From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Christian Brunschen Sent: Sunday, June 28, 2015 3:56 AM To: Peter Allan Cc: simh@trailing-edge.com Subject: Re: [Simh] Using an ODS-2 physical SCSI drive with simh If you have the option to do so, I would suggest making a byte-by-byte dump of the contents of the drive (a disk image), and putting that disk image somewhere safe and read-only; then, use a copy of that disk image for any experimentation. That way you're firstly reducing any wear on the drive itself, only reading data from it, once; and you're not risking any damage to the data, since you're working on a copy of the original which is safely stored elsewhere, and you can always start over with a fresh copy of the original at any point. Also, if your host computer is fairly modern, a disk image may actually be a lot faster to access than the original SCSI drive. // Christian On 28 June 2015 at 11:38, Peter Allan petermal...@gmail.commailto:petermal...@gmail.com wrote: I know that you can use a physical SCSI drive with simh by using the RAW device. However, before doing so, I want to check something. The drive that I have is a 9GB SCSI drive that was formatted and written to on an Alpha workstation that runs VMS 7.2-1. The disk structure on the drive is ODS-2. My question is - will using the drive as a RAW drive in simh let me access the existing file structure on the disk? I want to use the vax (microVAX 3900) simulator. Is it safe to write to the drive or might that mangle the file structure? Are there gotchas to watch out for, such as needing to tell simh the exact size of the drive? All comments gratefully received. Peter Allan ___ Simh mailing list Simh@trailing-edge.commailto:Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Announcing TCP/IP for RSX-11M-PLUS
Indeed. I meant apart from your own. Mike On Jul 1, 2015 5:24 PM, Johnny Billquist b...@softjar.se wrote: On 2015-07-01 23:08, Michael Kerpan wrote: This looks very cool. I wonder when the first web server running this stack will come online. I also notice the presence of an IRC client. Has anyone tried to chat from a PDP-11 yet? You mean apart from mine, as Madame.Update.UU.SE is already serving web-pages, and is running this software. Yes, I use that IRC client myself every day. (I'm also running this on a real 11/93 at home, by the way. Speed is pretty ok.) Johnny Mike On Jun 30, 2015 7:46 AM, Johnny Billquist b...@softjar.se mailto:b...@softjar.se wrote: I'm happy to announce a new release of TCP/IP for RSX-11M-PLUS. Since I'm broadening the scope of the announcement slightly, a more complete list of features is included, and not just what changed since last. For anyone who is currently running TCP/IP for RSX, I strongly encourage you to update to this latest version. Several improvements have gone in in the last couple of weeks. Most important change is that there now is telnet support, both client and server side. The TCP/IP for RSX that I've written is sometimes referred to as BQTCP/IP, just to make clear that it is a different product than Process Software's TCPWARE, or JSA's TCP/IP. BQTCP/IP is a rather feature rich TCP/IP implementation, which also comes with libraries for various high level languages. The API is not compatible, even at the source level, with Unix, but on the other hand, if people write some code, they will see that it is a very easy API to work with. The reasons for the incompatibilities are several, including both resource concerns and differences between how RSX works and Unix like operating systems. BQTCP/IP has tried to comply with all relevant RFCs, but I'm sure there are corners where it does not do things right. It also does not demand much resources. It do require RSX-11M-PLUS with split I/D space, and it has only been tested properly on RSX-11M-PLUS V4.6. It should work on any version 4 release of RSX-11M-PLUS, but there might be a couple of tweaks or fixes needed. BQTCP/IP is distributed in binary form, so very little compilation is required to get it up and running. However, pretty much all utilities do come with sources. The actual TCP/IP stack sources are not included. I do not have a good setup for distributing them in a sane way, and it has had a low priority on my list of things to do. But I do not mind distributing the sources as a general principle. All that said, BQTCP/IP current supports the following protocols: o Ethernet and loopback interfaces. o ARP. BQTCP/IP can use Ethernet in co-existance with DECnet, or standalone using the provided Unibus ethernet device driver. o IP. The largest IP packets supported are approximately 8KB. o ICMP. o UDP. The largest UDP packets supported are approximately 8KB. o TCP. The window is approximately 8KB in size, and TCP do manage out of order packets in an efficient way. BQTCP/IP supports the following applications: o DHCP. DHCP can be used to configure interface addresses, network masks, default gateways, DNS servers and NTP servers dynamically. o NTP. NTP can be used to set the local time. o TELNET. The TELNET server hooks in to the standard TT: terminal driver, and the number of terminals to create is configurable. The TELNET client can be used to connect to other systems. o FTP. The FTP server can serve all kind of files to other RSX systems, and can serve text and binary files to any system. The FTP client can retrieve RSX format files from RSX servers, and text, binary and block format files from any system. o TFTP. The TFTP server and client can be used for simpler file transfer operations. o RWHOD. RWHOD is a program that reports current users and uptime from RSX, for other systems to collect. o IRC. IRC is a program to communicate with other users around the world. o IRCBOT. IRCBOT is a small example robot program connecting to IRC and performing a service for IRC users. o PCL. PCL is a protocol for printing, used by HP (and other) printers over a network. The PCL implementation in BQTCP/IP appears as a print symbiont, which you can create a printer queue for. o WWW. WWW (or World Wide Web) is a service that can present hypertext information to clients. The WWW server in BQTCP/IP also supports CGI, which makes it possible to create dynamic content. o DNS. BQTCP/IP have DNS implemented as an ACP, that anyone can query to get translations between IP addresses and domain names. It also
