New "CP/M for Commodore" project

Hallo allemaal,


I always had the idea to build my own CP/M computer using some old Z80
based printer buffers I have laying around. In this case I was
thinking of one using a RS-232 connection to a terminal. Small
problem: none of these boards have a RS-232 interface. And not having
that much time I rather favour Commodore oriented projects.

But the article regarding the Z80 card for the CBM 8032, "Somebody
knows more about 'CP/Maker' (related to Commodore 40xx and 80xx, Z80
extension)", triggered the next idea: why not using the available I/O
lines to interface it with an I/O IC which on its turn is connected to
an expansion port of a Commodore?
This means I need a BIOS for the printerbuffer board. And I just found
out that BIOS is the name for the part on the flop that takes care of
the machine dependant part of CP/M. My first question was: is there a
documented sourcelisting available that I can use as base for a ROM
for this system? But I know now that I need to program the BIOS as
well. I found this page, [url]http://www.seasip.demon.co.uk/Cpm/bios.html[/url],
so writing one should be doable. But a documented sourcelisting would
welcome here as well :)

Many thanks in advance!


--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org

On Apr 2, 7:48 am, Ruud <Ruud.Baltis...@apg.nl> wrote:[color=blue]
> Hallo allemaal,
>
> I always had the idea to build my own CP/M computer using some old Z80
> based printer buffers I have laying around..... Small
> problem: none of these boards have a RS-232 interface.
>....... why not using the available I/O
> lines to interface it with an I/O IC which on its turn is connected to
> an expansion port of a Commodore?
> This means I need a BIOS for the printerbuffer board. And I just found
> out that BIOS is the name for the part on the flop that takes care of
> the machine dependant part of CP/M. My first question was: is there a
> documented sourcelisting available that I can use as base for a ROM
> for this system?[/color]

The simple answer is "probably not".

But I think you might benefit from reading the ORIGINAL manuals which
came with CP/M-80 version 2.2. They talk about how CP/M works and how
to move it to a new set of hardware. You might get a better idea of
what may be needed, to do what you have in mind. The unofficial CP/M
archive is at [url]http://www.cpm.z80.de/[/url] . They have CP/M sources and
binaries, and PDF's of the original manuals. CP/M-80 version 2.2 is
what you want.

In the old days, people interested in CP/M would get books about CP/M,
or look over old manuals which had hardware descriptions for specific
systems which ran CP/M. The "S-100" computers of the 1970's are a good
example. But I'm not sure people today read "books", anymore; or even
manuals. If you want to, you can find them.

Herb Johnson
retrotechnology.com

On Apr 2, 8:48 am, Ruud <Ruud.Baltis...@apg.nl> wrote:[color=blue]
> I always had the idea to build my own CP/M computer using some old Z80
> based printer buffers I have laying around. In this case I was
> thinking of one using a RS-232 connection to a terminal. Small
> problem: none of these boards have a RS-232 interface. And not having
> that much time I rather favour Commodore oriented projects.[/color]
[color=blue]
> But the article regarding the Z80 card for the CBM 8032, "Somebody
> knows more about 'CP/Maker' (related to Commodore 40xx and 80xx, Z80
> extension)", triggered the next idea: why not using the available I/O
> lines to interface it with an I/O IC which on its turn is connected to
> an expansion port of a Commodore?[/color]

If you have enough I/O lines to interface to an I/O IC to connect to
an expension port of a Commodore, then it seems to me that your first
idea is the simpler.

The CP/M system model is a BIOS which contains the hardware-specific
code, and the BDOS, which contained the operating-system-specific
code.

So what you are talking about is creating a new hardware base on which
to bring up a new BIOS.

Now, what you need at a minimum is something that the BDOS thinks is a
drive and something BDOS thinks is a terminal. With an RS-232C port,
you can get a terminal from almost anywhere ... a PC (Windows or Dos),
a linux box, including an obsolete old laptop with a trashed hard
drive that has to boot its Linux off a floppy disk, even a C64 or C128
(preferably the latter).

And the minimum hardware support for that if you have five I/O lines
available is two SPI parts.

The Serial Peripheral Interface is a patient interface, so that you do
not have to hit the timing required for I2C. It is based on an
synchronous serial port design:

SSOUT: synchronous serial out
SSIN: synchronous serial in
SSCLK: synchronous serial clock
SSSL: synchronous serial select (low for selected, high for
deselected)

SSSL goes low, then the device get ready to respond. If the controller
is slower than the device, you can just start firing. For each clock
cycle, the controller sends a bit to the device on SSOUT and receives
a bit from the device on SSIN. Eight clock cycles and one byte has
been sent at the same time one byte has been received.

There are complications (its an ad-hoc standard rather than a formal
one, so basically there are physically four different ways that the
clock and the serial lines can interact, and all four have been
implemented) ... but there are a variety of serial flash RAM devices
that use SPI, as well as SD and MMC flash cards supporting it.

Because of the SSSL line, it works like a bus. To have two devices
requires a common trio of SSOUT, SSIN, SSCLK, and one SSSL line per
device, or five lines. To have three devices requires six lines.

And three SPI devices could make a very handy little CP/M system. One
SPI serial flash part as "Drive A" (but see below) ... one SPI RS232
UART ... and one MMC slot as "Drive C".

You'd have to write your own BIOS for all of this, but once you have
the "Transfer One Byte" routine, it will all be much simpler than the
BIOS code for the original CP/M machines.

An extension I'd suggest would be to divide the built in serial flash
part into distinct segments, with one segment allocated as "Drive A",
and the remaining segments all able to be "Drive B", with a little
utility routine to swap which segment is treated like Drive B.

Ruud wrote:[color=blue]
> Hallo allemaal,
>
>
> I always had the idea to build my own CP/M computer using some old Z80
> based printer buffers I have laying around. In this case I was
> thinking of one using a RS-232 connection to a terminal. Small
> problem: none of these boards have a RS-232 interface. And not having
> that much time I rather favour Commodore oriented projects.
>
> But the article regarding the Z80 card for the CBM 8032, "Somebody
> knows more about 'CP/Maker' (related to Commodore 40xx and 80xx, Z80
> extension)", triggered the next idea: why not using the available I/O
> lines to interface it with an I/O IC which on its turn is connected to
> an expansion port of a Commodore?[/color]

What advantages would you get ?

Beside this, much more elegant is the idea to get a CP/M for a 6502
processor ;-) And in fact, Richard Leary is working hard to get this
possible for a C64 (he already had this implemented for a S-100 based
system, but these systems are rare) ! I will publish the good news asap
if there is a final result reached, at [url]http://www.z80.eu/dos65.html[/url] ...
be patient.

Regards
Peter

Hallo Peter,

[color=blue]
> What advantages would you get ?[/color]

Fun doing it :) But I know some people who are really interested. And
for the same reason, just for fun.

Have you heard of the 1541-Ultimate? This is a card that can be
connected to the expansionport of a C64/128. It emulates a 1541 drive
plus some other things. This means it emulates a 6502, RAM, ROM, I/O
and other things. The core is an FPGA. Now let it emulate a Z80, RAM,
ROM, PIO and a 6526 and we have our CP/M module.

[color=blue]
> Beside this, .... at [url]http://www.z80.eu/dos65.html[/url]...
> be patient.[/color]

I already have been patient for four years, since Richard mailed to me
that he was working on it and would email me back. But I can be a bit
more patient :)

Groetjes, Ruud

On Apr 7, 6:42 am, Ruud <Ruud.Baltis...@apg.nl> wrote:[color=blue]
> Have you heard of the 1541-Ultimate? This is a card that can be
> connected to the expansionport of a C64/128. It emulates a 1541 drive
> plus some other things. This means it emulates a 6502, RAM, ROM, I/O
> and other things. The core is an FPGA. Now let it emulate a Z80, RAM,
> ROM, PIO and a 6526 and we have our CP/M module.[/color]

Do it right, though ... give the Z80 its own RAM and let it run on the
8MHz dot clock, using the system clock to synchronize with the C64 bus
for I/O.

Ruud wrote:[color=blue]
> Hallo Peter,
>
>[color=green]
>> What advantages would you get ?[/color]
>
> Fun doing it :) But I know some people who are really interested. And
> for the same reason, just for fun.[/color]

Ok, Fun is a good reason ;-)
[color=blue]
> Have you heard of the 1541-Ultimate? This is a card that can be
> connected to the expansionport of a C64/128. It emulates a 1541 drive
> plus some other things. This means it emulates a 6502, RAM, ROM, I/O
> and other things. The core is an FPGA. Now let it emulate a Z80, RAM,
> ROM, PIO and a 6526 and we have our CP/M module.[/color]

Yes, I read a bit about it, but also, that it can't be used with the
CP/M cartridge.
[color=blue][color=green]
>> Beside this, .... at [url]http://www.z80.eu/dos65.html[/url]...
>> be patient.[/color]
>
> I already have been patient for four years, since Richard mailed to me
> that he was working on it and would email me back. But I can be a bit
> more patient :)[/color]

So you don't have to be patient anymore. It's there ! Richard made a
first running beta and he provided me also with .D64 image files, not
only but also with the assembler sources.
Try it.

--
* DOS/65 (a CP/M alike for the 6502 cpu) can be found at
[url]http://www.z80.eu/dos65.html[/url]

Peter Dassow wrote:
[color=blue][color=green]
>> I already have been patient for four years, since Richard mailed to me
>> that he was working on it and would email me back. But I can be a bit
>> more patient :)[/color][/color]
[color=blue]
> So you don't have to be patient anymore. It's there ! Richard made a
> first running beta and he provided me also with .D64 image files, not
> only but also with the assembler sources.
> Try it.[/color]

I'd like to. Where are the .D64 images? All I find on your site is the
source code.

On Apr 7, 6:10 pm, Peter Dassow <z8...@arcor.de> wrote:[color=blue]
> Ruud wrote:[color=green]
> > Have you heard of the 1541-Ultimate? This is a card that can be
> > connected to the expansionport of a C64/128. It emulates a 1541 drive
> > plus some other things. This means it emulates a 6502, RAM, ROM, I/O
> > and other things. The core is an FPGA. Now let it emulate a Z80, RAM,
> > ROM, PIO and a 6526 and we have our CP/M module.[/color][/color]
[color=blue]
> Yes, I read a bit about it, but also, that it can't be used with the
> CP/M cartridge.[/color]

If it worked with the CP/M cartridge, then there would be no need to
extend the 1541-Ultimate to internally support a CP/M module.

But if the internal CP/M module had its own memory and ran on the 8MHz
dot clock, there would still be a benefit in doing so.

Steven Hirsch wrote:[color=blue]
> Peter Dassow wrote:
>[color=green][color=darkred]
>>> I already have been patient for four years, since Richard mailed to me
>>> that he was working on it and would email me back. But I can be a bit
>>> more patient :)[/color][/color]
>[color=green]
>> So you don't have to be patient anymore. It's there ! Richard made a
>> first running beta and he provided me also with .D64 image files, not
>> only but also with the assembler sources.
>> Try it.[/color]
>
> I'd like to. Where are the .D64 images? All I find on your site is the
> source code.[/color]

There are disk images, just under the colored "*New* First beta of a C64
port" line ! I guess you have to refresh your browser, because I've done
it just 15h before this message.

Regards
Peter

--
* DOS/65 (a CP/M alike for the 6502 cpu) can be found at
[url]http://www.z80.eu/dos65.html[/url]

"Steven Hirsch" <snhirsch@gmail.com> wrote in message
news:0dCdne2bdJCgPWfanZ2dnUVZ_tqtnZ2d@giganews.com...[color=blue]
> Peter Dassow wrote:
>[/color]
So you don't have to be patient anymore. It's there ! Richard made a[color=blue][color=green]
>> first running beta and he provided me also with .D64 image files, not
>> only but also with the assembler sources.
>> Try it.[/color]
>
> I'd like to. Where are the .D64 images? All I find on your site is the
> source code.
>[/color]
I see this on the site:

Richard has prepared two .D64 files (work in progress!):
DOS65A.D64
DOS65-1A.D64

Tom Lake

Hallo Bruce,

[color=blue]
> Do it right, though ... give the Z80 its own RAM and let it run on the
> 8MHz dot clock, using the system clock to synchronize with the C64 bus
> for I/O.[/color]

Hey, a very good idea!


Groetjes, Ruud

Hallo Peter,

[color=blue]
> Yes, I read a bit about it, but also, that it can't be used with the
> CP/M cartridge.[/color]

The Ultimate also emulates the Final Cartridge. Both cartridges use
the same lines to address some onboard I/O. Result: conflicts. But as
said before, the Ultimate is programmed in FPGA, I could ask Gideon,
the designer, to skip the FC and then it should work with CP/M
cartridge.

[color=blue]
> So you don't have to be patient anymore. It's there ![/color]

Thanks !!!


Groetjes, Ruud

On Apr 8, 6:22 am, Ruud <Ruud.Baltis...@apg.nl> wrote:[color=blue]
> Hallo Peter,
>[color=green]
> > Yes, I read a bit about it, but also, that it can't be used with the
> > CP/M cartridge.[/color]
>
> The Ultimate also emulates the Final Cartridge. Both cartridges use
> the same lines to address some onboard I/O. Result: conflicts. But as
> said before, the Ultimate is programmed in FPGA, I could ask Gideon,
> the designer, to skip the FC and then it should work with CP/M
> cartridge.[/color]

Working with the CP/M cartridge would be nowhere near as useful as
providing a better version of the CP/M cartridge. And for that, with
the Z80 having its own memory to work with, you can put the portal
input, output, and status byte anywhere that is compatible with the
Final Cartridge use of the two expansion port I/O pages.

And then, with the 6502 running in parallel to the Z80, because they
have independent memory buses, its possible to do things like running
those soft high-res screens with 8x4 and 8x5 character bitmaps where
25x80 and 25x64 character sets are needed for a program. The 6502 and
VIC are, IOW, is free to use all the main memory bus clock cycles on I/
O in support of the Z80 processor, allowing for a very small BIOS in
the Z80 memory space.

BruceMcF wrote:[color=blue]
> On Apr 8, 6:22 am, Ruud <Ruud.Baltis...@apg.nl> wrote:[color=green]
>> Hallo Peter,
>>[color=darkred]
>>> Yes, I read a bit about it, but also, that it can't be used with the
>>> CP/M cartridge.[/color]
>> The Ultimate also emulates the Final Cartridge. Both cartridges use
>> the same lines to address some onboard I/O. Result: conflicts. But as
>> said before, the Ultimate is programmed in FPGA, I could ask Gideon,
>> the designer, to skip the FC and then it should work with CP/M
>> cartridge.[/color]
>
> Working with the CP/M cartridge would be nowhere near as useful as
> providing a better version of the CP/M cartridge. And for that, with
> the Z80 having its own memory to work with, you can put the portal
> input, output, and status byte anywhere that is compatible with the
> Final Cartridge use of the two expansion port I/O pages.
>
> And then, with the 6502 running in parallel to the Z80, because they
> have independent memory buses, its possible to do things like running
> those soft high-res screens with 8x4 and 8x5 character bitmaps where
> 25x80 and 25x64 character sets are needed for a program. The 6502 and
> VIC are, IOW, is free to use all the main memory bus clock cycles on I/
> O in support of the Z80 processor, allowing for a very small BIOS in
> the Z80 memory space.[/color]

Yes. It would be very nice. BUT - in reality we do have nothing similar,
and I am absolutely *not* sure somebody will do the work.
Very often I have ideas to improve things, but the factor is time - and
nobody has really much time to spend for these things...

Regards
Peter

P.S.: I have published some screenshots from the running DOS/65 for the
C64 now also ...

On Apr 8, 10:49 am, Peter Dassow <z8...@arcor.de> wrote:[color=blue]
> BruceMcF wrote:[color=green]
> > On Apr 8, 6:22 am, Ruud <Ruud.Baltis...@apg.nl> wrote:[color=darkred]
> >> Hallo Peter,[/color][/color]
>[color=green][color=darkred]
> >>> Yes, I read a bit about it, but also, that it can't be used with the
> >>> CP/M cartridge.
> >> The Ultimate also emulates the Final Cartridge. Both cartridges use
> >> the same lines to address some onboard I/O. Result: conflicts. But as
> >> said before, the Ultimate is programmed in FPGA, I could ask Gideon,
> >> the designer, to skip the FC and then it should work with CP/M
> >> cartridge.[/color][/color]
>[color=green]
> > Working with the CP/M cartridge would be nowhere near as useful as
> > providing a better version of the CP/M cartridge. And for that, with
> > the Z80 having its own memory to work with, you can put the portal
> > input, output, and status byte anywhere that is compatible with the
> > Final Cartridge use of the two expansion port I/O pages.[/color]
>[color=green]
> > And then, with the 6502 running in parallel to the Z80, because they
> > have independent memory buses, its possible to do things like running
> > those soft high-res screens with 8x4 and 8x5 character bitmaps where
> > 25x80 and 25x64 character sets are needed for a program. The 6502 and
> > VIC are, IOW, is free to use all the main memory bus clock cycles on I/
> > O in support of the Z80 processor, allowing for a very small BIOS in
> > the Z80 memory space.[/color][/color]
[color=blue]
> Yes. It would be very nice. BUT - in reality we do have nothing similar,
> and I am absolutely *not* sure somebody will do the work.
> Very often I have ideas to improve things, but the factor is time - and
> nobody has really much time to spend for these things...[/color]

The big question is the Z80 softcore for the FPGA (or for an upwardly
compatible FPGA, if its necessary to get more blocks to support
it) ... if that exists as an open source design, then its likely to
have RAM and some form of I/O port worked out as well. And that would
be easier to fit into a small slot in one of the two I/O pages than
trying to replicate the existing CP/M cartridge, as suggested above.

The material at:

[url]http://zxgate.sourceforge.net/[/url]

.... might give a starting point, I dunno.

BruceMcF wrote:[color=blue]
>
> The big question is the Z80 softcore for the FPGA (or for an upwardly
> compatible FPGA, if its necessary to get more blocks to support
> it) ... if that exists as an open source design, then its likely to
> have RAM and some form of I/O port worked out as well. And that would
> be easier to fit into a small slot in one of the two I/O pages than
> trying to replicate the existing CP/M cartridge, as suggested above.
>
> The material at:
>
> [url]http://zxgate.sourceforge.net/[/url]
>
> ... might give a starting point, I dunno.[/color]

So would YOU start to implement this in a FPGA ?
You didn't answer my thoughts about time and who is doing it....

Regards
Peter

Peter Dassow wrote:
(snip)
[color=blue]
> So would YOU start to implement this in a FPGA ?
> You didn't answer my thoughts about time and who is doing it....[/color]

How about a board with ATX form factor using an ATX power supply
with one big (or medium sized) FPGA in the middle. Slots for as
many different buses as one might possibly use with it, all
slots wired to the FPGA. (Possibly with external buffers, though
some FPGAs have pretty good current drive.)
(ISA, PCI, Apple II, Commodore, S-100, Q-bus, ...)

Interface for PS2 keyboard and mouse, parallel and serial port,
floppy (34 and 50 pin) and IDE drives, all wired directly to the
FPGA such that the signals can be processed in any way desired.

The bus interface might be such that one chooses which to use
on a given board. That would allow for one PC layout,
but one could choose at board assembly time which were
to be used.

That should allow hardware emulators for a large number of
older computers. S-100 based 8080, Z80, 8086, 6800,
Z8000, 6502 based Apple I, II, and III, Commodore
and PDP-11 systems.

-- glen

On Apr 8, 1:28 pm, Peter Dassow <z8...@arcor.de> wrote:[color=blue]
> BruceMcF wrote:
>[color=green]
> > The big question is the Z80 softcore for the FPGA (or for an upwardly
> > compatible FPGA, if its necessary to get more blocks to support
> > it) ... if that exists as an open source design, then its likely to
> > have RAM and some form of I/O port worked out as well. And that would
> > be easier to fit into a small slot in one of the two I/O pages than
> > trying to replicate the existing CP/M cartridge, as suggested above.[/color][/color]
[color=blue][color=green]
> > The material at:
> >[url]http://zxgate.sourceforge.net/[/url]
> > ... might give a starting point, I dunno.[/color][/color]
[color=blue]
> So would YOU start to implement this in a FPGA ?
> You didn't answer my thoughts about time and who is doing it....[/color]

No, if I was doing it, it would talk to the C64 over an SPI interface,
so that it would be possible to use it with a C64TV hacked to give 2
joystick ports (but on a real C64, I'd use the hardware serial on the
User port with its 250kb/s).

I didn't suggest putting it inside an expanded version of the 1541
Ultimate design, that was Ruud.

QUOTE
Have you heard of the 1541-Ultimate? This is a card that can be
connected to the expansionport of a C64/128. It emulates a 1541 drive
plus some other things. This means it emulates a 6502, RAM, ROM, I/O
and other things. The core is an FPGA. *Now let it emulate a Z80, RAM,
ROM, PIO and a 6526 and we have our CP/M module.*
UNQUOTE

And regarding time and who is doing it, irrespective of who would be
doing it, this approach would not only result in a far more nimble CP/
M system, but it would also be simpler to implement than providing an
exact hardware emulation of the original CP/M cartridge.

On Apr 8, 6:15 am, Ruud <Ruud.Baltis...@apg.nl> wrote:[color=blue]
> Hallo Bruce,
>[color=green]
> > Do it right, though ... give the Z80 its own RAM and let it run on the
> > 8MHz dot clock, using the system clock to synchronize with the C64 bus
> > for I/O.[/color][/color]
[color=blue]
> Hey, a very good idea![/color]

I really think its easier to do it that way ... I'm fuzzy on how the
z80 PIO works, since I spent most of my time on the 6502 side where
all I/O is memory mapped, but from somewhere I picked up the
impression that it fits this kind of situation where the processor
clock is at one rate and the I/O bus is on a different clock.

And if the thing is sitting inside an Ultimate Cartridge, the problem
in finding a permanent place for the 6502 side I/O support software is
already solved.

Plus the z80 FPGA softcore that I saw in a quick glance around ...

[url]http://zxgate.sourceforge.net/[/url]

.... already has external RAM and ROM for a Spectrum clone ... expand
the RAM to 64K and switch the external ROM to an SPI flash RAM with an
SPI bootloader in the FPGA (this one uses a Xilinx part, and I am
pretty sure that I saw a standard SPI flash bootloader for *some*
Xilinx part, so that might already be done), and then its a matter of
designing a low footprint I/O register bank that fits into whatever
the existing IO1/IO2 footprint is.

However, it might be a lot simpler to make something as a
daughterboard to the 1541U ... it has a 6 pin expansion header, should
be enough for an SPI interface ... and if its designed to fit on a
1541U, then it can be assumed that the person can just load the 6502
support software from an SD card, so the daughterboard would only need
the Z80, RAM, flash bootloader, and SPI port.

Don't know about power supply on the expansion header.