Re: New "CP/M for Commodore" project

On Apr 2, 8:48 am, Ruud <Ruud.Baltis...@xxxxxx> wrote:
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?

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

Relevant Pages

  • Nontraditional inheritance structure.
    ... general topic (subject: Interface Delegation or ??). ... segments, quadratic segments, or spline segments. ... class StraightLineSegment implements ISegment{} ... class DefaultEdge implements IEdge{ ...
    (comp.object)
  • Re: [PATCH 0/3] map multiple blocks in get_block() and mpage_readpages()
    ... And also to not go backwards on what the current DIO mapping ... size of I/O for some time, and as someone who has hunted down some ... in with other changes allowing the get_block_tinterface to ...
    (Linux-Kernel)
  • best option for terminal emulation?
    ... to interface a MicroVGA adaptor (http://www.dontronics-shop.com/4d- ... So I need to work out what the command protocol will be betwen the I/O ... moving the cursor to a particular location etc. ... CURSOR (Cursor addressing sequence, sends cursor to ...
    (comp.os.cpm)
  • Re: aio_read/write versus O_NONBLOCK
    ... | rarely useful because 'I/O-cache' (page cache, block buffer cache) ... If what is intended does not include being able to overlap I/O in a consistent ... Creating a new interface designed to support ... interfaces should be completely uniform for everything I/O ever needs to ...
    (comp.unix.programmer)
  • Re: Firewire of PCI? I cant decide!
    ... "PCI is a pain in the ass" and "completely unnecessary for audio ... the firewire interface chips are PCI devices.. ... ADAT I/O. ...
    (rec.audio.pro)
Loading