[Simh] Announcing TCP/IP for RSX-11M-PLUS

[Johnny Billquist]

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 support if needed. BQTCP/IP is already running on the 
internet, and have been for a while. People who are curious to check it 
out can ether look at http://madame.update.uu.se/, or telnet to 
telnet://madame.update.uu.se and login as user GUEST with password 
GUEST, or use ftp against ftp://madame.updat

[Simh] cdecl

[R P Herrold]

On Mon, 29 Jun 2015, Bill Cunningham wrote:

> I guess cdecl was removed from my distro of linux; 
> fedora because of copyright concerns. I have read the 
> project was long dead.

There is less there than meets the eye, but it was formerly in 
CentOS, and PUIAS

the SRPM rebuilds trivially on C 6 -- I placed a copy, after 
rebuild, out at:
ftp://ftp.owlriver.com/pub/local/ORC/cdecl/

-- Russ herrold


-- 
--
end
==
 .-- -... ---.. ... -.- -.--
Copyright (C) 2015 R P Herrold
  herr...@owlriver.com
   My words are not deathless prose,
  but they are mine.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] cdecl

[Christian Brunschen]

There is also http://www.cdecl.org/ ...

// Christian

On 30 June 2015 at 16:19, R P Herrold  wrote:

> On Mon, 29 Jun 2015, Bill Cunningham wrote:
>
> > I guess cdecl was removed from my distro of linux;
> > fedora because of copyright concerns. I have read the
> > project was long dead.
>
> There is less there than meets the eye, but it was formerly in
> CentOS, and PUIAS
>
> the SRPM rebuilds trivially on C 6 -- I placed a copy, after
> rebuild, out at:
> ftp://ftp.owlriver.com/pub/local/ORC/cdecl/
>
> -- Russ herrold
>
>
> --
> --
> end
> ==
>  .-- -... ---.. ... -.- -.--
> Copyright (C) 2015 R P Herrold
>   herr...@owlriver.com
>My words are not deathless prose,
>   but they are mine.
> ___
> Simh mailing list
> 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] cdecl

[R P Herrold]

On Tue, 30 Jun 2015, Christian Brunschen wrote:

> There is also http://www.cdecl.org/ ...

noted -- but that is a (the same, actually) tarball; for 
people using the RPM package namagement system, the SRPM 
simplifies matters

-- Russ herrold
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] cdecl

[Christian Brunschen]

My point was more that you can ask http://www.cdecl.org directly, without
having to install anything anywhere.

// Christian

On 30 June 2015 at 16:42, R P Herrold  wrote:

> On Tue, 30 Jun 2015, Christian Brunschen wrote:
>
> > There is also http://www.cdecl.org/ ...
>
> noted -- but that is a (the same, actually) tarball; for
> people using the RPM package namagement system, the SRPM
> simplifies matters
>
> -- Russ herrold
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] cdecl

[Bill Cunningham]

The copy I found wanted lex and yacc. Well evidently byacc was acceptable. Lex 
is from unix of course so I didn't have the dependancies to compile the C 
program. I am not sure if it would accept flex or not. 
  - Original Message - 
  From: R P Herrold 
  To: Bill Cunningham 
  Cc: simh@trailing-edge.com 
  Sent: Tuesday, June 30, 2015 11:19 AM
  Subject: cdecl


  On Mon, 29 Jun 2015, Bill Cunningham wrote:

  > I guess cdecl was removed from my distro of linux; 
  > fedora because of copyright concerns. I have read the 
  > project was long dead.

  There is less there than meets the eye, but it was formerly in 
  CentOS, and PUIAS

  the SRPM rebuilds trivially on C 6 -- I placed a copy, after 
  rebuild, out at:
  ftp://ftp.owlriver.com/pub/local/ORC/cdecl/

  -- Russ herrold


  -- 
  --
  end
  ==
   .-- -... ---.. ... -.- -.--
  Copyright (C) 2015 R P Herrold
herr...@owlriver.com
 My words are not deathless prose,
but they are mine.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] cdecl

[Clem Cole]

It should preprocess, build and compile with and modern YACC or Lex
implementation although it will get some warnings and even errors with some
modern compilers.   For instance, the  when you try to compile with LLVM on
the Mac, it will get a few errors some of them because the version of GNU
readline that it assumes is different from the version that Mac OS installs
[and while Brew updates /usr/local/Cellar to have the new one, it did not
put the link in /usr/local/include/readline to the Cellar so the default
one was getting sucked in).

If anyone chars I have a and updated cdecl.c that will fix the warnings
LLVM..

If I feel charitable and have a few minutes, I'll try to see what icc does
with it.

Clem

On Tue, Jun 30, 2015 at 12:37 PM, Bill Cunningham 
wrote:

>  The copy I found wanted lex and yacc. Well evidently byacc was
> acceptable. Lex is from unix of course so I didn't have the dependancies to
> compile the C program. I am not sure if it would accept flex or not.
>
> - Original Message -
> *From:* R P Herrold 
> *To:* Bill Cunningham 
> *Cc:* simh@trailing-edge.com
> *Sent:* Tuesday, June 30, 2015 11:19 AM
> *Subject:* cdecl
>
> On Mon, 29 Jun 2015, Bill Cunningham wrote:
>
> > I guess cdecl was removed from my distro of linux;
> > fedora because of copyright concerns. I have read the
> > project was long dead.
>
> There is less there than meets the eye, but it was formerly in
> CentOS, and PUIAS
>
> the SRPM rebuilds trivially on C 6 -- I placed a copy, after
> rebuild, out at:
> ftp://ftp.owlriver.com/pub/local/ORC/cdecl/
>
> -- Russ herrold
>
>
> --
> --
> end
> ==
>  .-- -... ---.. ... -.- -.--
> Copyright (C) 2015 R P Herrold
>   herr...@owlriver.com
>My words are not deathless prose,
>   but they are mine.
>
>
> ___
> Simh mailing list
> 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

[Simh] C64 word size

[Bill Cunningham]

Ok anyone know the C64 word size of memory? The 6510 was 8 bit and there 
was 16 bit addressability. I guess that would be a "16 bit address bus"; if 
they had that back then. It had 64kb of ram.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] C64 and C128

[Bill Cunningham]

Did the C64 not run CP/M? I know the 128 did. It had a 8502 processor and 
Z80A processor I believe. One was for CP/M. What good is a commodore machine 
without CP/M ;)

Bill
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] simh tools

[Kevin Handy]

Some time ago, I wrote a DecMate II word processing conversion to Word
Perfet converter. I was wondering if it should be included in the simtools
distribution, before it disappears entirely off the net.

It origanally ran unger MSdos, and is written in C. This was a complete
reverse engineering job, so it may have a lot of prblems. It had some
conversion issues (DecWord and WordPerfect had different ideas on
formatting), but it got the text out.

Modified/pdated versions of it is at

ftp://ftp.pdp8online.com/software/wps/

as decmate.tar and dmdos.tar

If I remember correctly, the license on it is "use at your own risk".

It might be able to read simh floppy disk images as is, but I don't have
any to try it on now.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] C64 and C128

[Kevin Handy]

The C64 did not run cp/m out of the box, because it did not have any kind
of Intel 8080 based processor. You could buy a cartridge (iirc) that would
allow you to run cp/m, but it was basically bolting a cp/m machine onto the
side of the C64.

The C128 had both the C64 processor, and a Z80 processor built in, and it
could run cp/m. The floppy drive speed was really lousy though (300 baud
serial bus iirc).

On Tue, Jun 30, 2015 at 5:21 PM, Bill Cunningham 
wrote:

>  Did the C64 not run CP/M? I know the 128 did. It had a 8502
> processor and Z80A processor I believe. One was for CP/M. What good is a
> commodore machine without CP/M ;)
>
> Bill
>
>
> ___
> Simh mailing list
> 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] simh tools

[Timothe Litt]

On 30-Jun-15 19:34, Kevin Handy wrote:
> Some time ago, I wrote a DecMate II word processing conversion to Word
> Perfet converter. I was wondering if it should be included in the
> simtools distribution, before it disappears entirely off the net.
>
> It origanally ran unger MSdos, and is written in C. This was a
> complete reverse engineering job, so it may have a lot of prblems. It
> had some conversion issues (DecWord and WordPerfect had different
> ideas on formatting), but it got the text out.
I guess you could call this a weak objection - SimH tools have been
tools for getting things into and out of SimH formats/containers.  And a
few for working on SimH itself.

Another option is to create a repo on GitHub for it.  They're free and
easy to setup.  If you're not willing to do that, I guess it's better to
save it in the "wrong" place than to lose it.  I wouldn't object to a
pointer somewhere in SimH - it could use a directory of related
repositories.

(DECMate has some truly odd formats; I once wrote a WPS to DSR converter...)

In any case it would be better if you could take the time to make
(sure?) it run(s) under at least one more modern environment - Linux,
VMS, Windows...  Portable code is a lot more useful and lasts longer...

That's my 3 cents; others may see things differently.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] C64 and C128

[Bill Cunningham]

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?

  - Original Message - 
  From: Kevin Handy 
  To: Bill Cunningham 
  Cc: simh@trailing-edge.com 
  Sent: Tuesday, June 30, 2015 7:46 PM
  Subject: Re: [Simh] C64 and C128


  The C64 did not run cp/m out of the box, because it did not have any kind of 
Intel 8080 based processor. You could buy a cartridge (iirc) that would allow 
you to run cp/m, but it was basically bolting a cp/m machine onto the side of 
the C64. 


  The C128 had both the C64 processor, and a Z80 processor built in, and it 
could run cp/m. The floppy drive speed was really lousy though (300 baud serial 
bus iirc).



  On Tue, Jun 30, 2015 at 5:21 PM, Bill Cunningham  
wrote:

Did the C64 not run CP/M? I know the 128 did. It had a 8502 processor 
and Z80A processor I believe. One was for CP/M. What good is a commodore 
machine without CP/M ;)

Bill


___
Simh mailing list
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

[Simh] Kaypto II

[Kevin Handy]

I've been playing with the altairz80 emulation to see how close I could get
to a Kaypto2 emulation. Attached is my config file so far, and it's about
as fat as I can go without changing any code.

A couple of issues came up about the emulated hardware, and I thought I'd
ask preferences before modifying anything.

1. What are some of the source file (.c, .h) marked executable>
2. The flexwriter is similiar to yj kp2 display, except that the fw has a
80x24 mapped into memory as a 80x24 array. The kp2 has an 80x25 display
mapped into a 128x25 array (memory between 81 and 128 is unused). Should I
make a new kp2 display device, or add parameters to the fw code?
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?
... Probably more if I get more time to play.


kp2
Description: Binary data
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] C64 and C128

[Rich Alderson]

> From: "Bill Cunningham" 
> Date: Tue, 30 Jun 2015 19:56:06 -0400

> 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?

The Z80A ran at 4MHz.  It is a faster variant of the Z80, which ran at 2.5MHz.

You can leave off the word "memory" and the scare quotes in your question, and
stop worrying about addressing in the same breath.  The 2 are orthogonal.

Before the IBM System/360 came along, computers were word-addressed, character-
addressed, bit-addressed, or digit-addressed (decimal).

Bit-addressed computers represent characters as sequences of bits (the term
"byte" originally meant "sequence of bits representing a character", not just
"eight bits").  Decimal digits require 4 bits to be represented in binary, so
that's the "word" size there.  Character-addressed machines generally used 6
bits to represent a character, so that's the "word" size there.

Word-addressed computers comfortably operate on large numbers of bits at one
time, with data paths which transfer all of the data in parallel (except in
some very special cases like the PDP-8/s).  The size of the word in bits is the
defining characteristic of the computer.  Let's list a few examples of word-
addressed machines:

  SystemBits/Word   Bits/Addr
  ===   =

CDC 160448 15
CDC 160-A   12   6 or 12
CDC 660060 18
DEC PDP-1   18 12
DEC PDP-7   18 13
DEC PDP-10  36 18
IBM 709436 15

OK, that's enough for starters.  In each of those systems, the amount of data
which will be found at each consecutive address is the same number of bits, and
that is what the computer operates on.

OK, enter the System/360.  IBM had for years been manufacturing word-addressed
"scientific" computers (like the 709/7090/7094) and character-addressed
"business" computers (like the 1401).  They wanted to make a single line of
computers which could do both kinds of computing (character-oriented or larger
word-data oriented) equally well; the result was something of a compromise for
both sets of customers, but's beside the point.

What IBM did was take the "byte" notion, give it a fixed length, make it the
addressable element, and DEFINE THE WORD TO BE MULTIPLE BYTES (in this case,
four).  So the byte addresses go 0, 1, 2, 3, ... but the word addresses go
0, 4, 8, 12, ...  Data gets moved into and out of registers as words (or
halfwords or doublewords, but that's another story).[1]  From one memory
location to another, data moved in bytes.

SO:  Now we have a new definition of "word size", one in which 8-bit bytes are
constant and addressable.

So people started building computers to work with the 880lb (400Kg) gorilla.
Some examples of computer systems that use this model:

  SystemBits/Word   Bytes/Word   Bits/Addr
  ===   ==   =

IBM System/360 324  24
DG Nova162  15
DEC PDP-11 162  16
DEC VAX324  32

At the same time, microprocessors began to appear, with smaller data sizes, and
it gets complex all over again.  The addressable unit is the 8-bit byte, and
registers only handle 8 bits, but addressing may be larger:

  Microchip Bits/Word   Bits/Addr
  = =   =

  Intel 80088   14
  Intel 80808   16
  Zilog Z80A8   16
  MOS Tech 6502 8   16
  Motorola 680916   16
  Motorola 68000   16   24
  Motorola 68030   32   32
  Intel 8086   16   20
  Intel 80286  16   24
  Intel 80386  32   32

Obviously, "word size" here is how large a register is into which data from
some number of bytes in memory can be stuffed.

I hope that clears up your confusion.

Rich

[1] As is the fact that different models hide the fact that they're really
moving 8 bits = 1 byte or 16 bits = 2 bytes = a halfword at a time in the
hardware, because that's an implementation detail which the 8 bits/32 bits
System/360 ignores.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] C64 and C128

[Johnny Billquist]

On 2015-07-01 01:56, 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?


You are asking very weird questions.
What do you mean by "word size"?

Johnny



- Original Message -
*From:* Kevin Handy 
*To:* Bill Cunningham 
*Cc:* simh@trailing-edge.com 
*Sent:* Tuesday, June 30, 2015 7:46 PM
*Subject:* Re: [Simh] C64 and C128

The C64 did not run cp/m out of the box, because it did not have any
kind of Intel 8080 based processor. You could buy a cartridge (iirc)
that would allow you to run cp/m, but it was basically bolting a
cp/m machine onto the side of the C64.

The C128 had both the C64 processor, and a Z80 processor built in,
and it could run cp/m. The floppy drive speed was really lousy
though (300 baud serial bus iirc).

On Tue, Jun 30, 2015 at 5:21 PM, Bill Cunningham
mailto:bill...@suddenlink.net>> wrote:

__
 Did the C64 not run CP/M? I know the 128 did. It had a 8502
processor and Z80A processor I believe. One was for CP/M. What
good is a commodore machine without CP/M ;)
Bill

___
Simh mailing list
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




--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] C64 and C128

[Bill Cunningham]

  - Original Message - 
  From: Johnny Billquist 
  To: simh@trailing-edge.com 
  Sent: Tuesday, June 30, 2015 10:07 PM
  Subject: Re: [Simh] C64 and C128


  On 2015-07-01 01:56, 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?

  You are asking very weird questions.
  What do you mean by "word size"?

  Johnny


  I read in some specs either for 6502 or Z80A the term "memory word size". 
These are all 8 bit cpus I know that but they have different sized address 
buses. Rich straightened me out. The term "memory" was throwing me off. I these 
cases Word Size would be 8 bit. Like todays 64 bit machines. Word size is now 
considered "64" on 64 bit processors. Although the 6502 had 8 bit registers 
except maybe for one, and a 16 bit address bus. They are 8 bit "word" sized.
  Under control now. Thanks though. 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] C64 and C128

[Clem cole]

The C64 and C128 were based on the MOS Technology 6502 which Commodore 
eventually became the IP owner.I do not know of an 8502 processor. 

As I said previously this is the same chip as used by Apple, Atari and many 
others. 

It did not run CP/M which needed an Intel 8080 based instruction set (the Zilog 
Z80 is an 8080 superset). 

Clem
Sent from my iPhone

> On Jun 30, 2015, at 7:21 PM, Bill Cunningham  wrote:
> 
> Did the C64 not run CP/M? I know the 128 did. It had a 8502 processor and 
> Z80A processor I believe. One was for CP/M. What good is a commodore machine 
> without CP/M ;)
>  
> Bill
>  
> ___
> Simh mailing list
> 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] C64 and C128

[Johnny Billquist]

On 2015-07-01 04:13, Bill Cunningham wrote:

- Original Message -
*From:* Johnny Billquist 
*To:* simh@trailing-edge.com 
*Sent:* Tuesday, June 30, 2015 10:07 PM
*Subject:* Re: [Simh] C64 and C128

On 2015-07-01 01:56, 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?

You are asking very weird questions.
What do you mean by "word size"?

Johnny

 I read in some specs either for 6502 or Z80A the term "memory
word size". These are all 8 bit cpus I know that but they have
different sized address buses. Rich straightened me out. The term
"memory" was throwing me off. I these cases Word Size would be 8
bit. Like todays 64 bit machines. Word size is now considered "64"
on 64 bit processors. Although the 6502 had 8 bit registers except
maybe for one, and a 16 bit address bus. They are 8 bit "word" sized.
Under control now. Thanks though.


But you are conflating many different things here.

If we start with something like the Z80, the memory address is 16 bits, 
while the data bus holds 8 bits. The basic CPU register size is 8 bits, 
but you have native instructions that also handle 16 bit data, and 
registers can be used in pairs, to have 16-bit CPU registers. And 
addresses are always expressed as 16-bit quantities.


The 6502 is similar to the Z80, but some addresses are sortof only 
expressed as 8-nit quantities, and I'm not sure you have any 16 bit 
registers in there that are for generic use, nor any native 16-bit 
instructions/operations.


A modern CPU is no easier. You might have 48 address bits on the 
physical address bus. 256 bits on the physical data bus. The virtual 
address is 64 bits, and the CPU have instructions that can work on 8, 
16, 32, 64 and possibly also larger data sizes. The registers normally 
holds 64 bits, though, and addresses are normally expressed as 64-bit.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] C64 and C128

[Ethan Dicks]

On Tue, Jun 30, 2015 at 7:46 PM, Kevin Handy  wrote:
> The C64 did not run cp/m out of the box, because it did not have any kind of
> Intel 8080 based processor. You could buy a cartridge (iirc) that would
> allow you to run cp/m, but it was basically bolting a cp/m machine onto the
> side of the C64.

There was a C-64 CP/M cartridge.  It was apparently awful.  I never
knew anyone that ever bought one (contrasted with several people I
know that ran CP/M on a card in their Apple II).

The C-64 CP/M card was announced, advertised on the outside of the
C-64 box, then later, engineered and sold mostly to avoid FTC action
for false advertising.

Some Info:

http://www.zimmers.net/cbmpics/xother3.html
http://www.z80.eu/c64.html

> The C128 had both the C64 processor, and a Z80 processor built in, and it
> could run cp/m.

It did, and I've heard Bil Herd's excellent stories about what it took
to make it all work.  I'm pretty sure you can look them up on YouTube
if you haven't had the chance to hear about them in person at a
VCFeast.

> The floppy drive speed was really lousy though (300 baud
> serial bus iirc).

It was a little faster than that... the IEC bus was a sync serial bus
with the CPU doing the bit-banging (due to a well-known (now) hardware
bug with the 6522 VIA shift register used in the 1540 drive and the
VIC-20, or else the IEC bus would have been bytes from the CPU shifted
in/out bit-serial by hardware and several times faster).

Actual throughput was something close to 500 bytes/sec or about 4000
bps.  It took a little over 2 minutes to read 64Kbytes of data.  This
is still much slower than all the other (non-IEC) machines of the day.

Commodore did fix things up later with the C-128 and 1571 and 1581
drives with a "fast serial" interface that did use hardware features
of the 6526 CIA (found in the C-64 but not used to its potential).
There's a lot of history behind the story of these interfaces, but
those are some of the high points.

-ethan
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh