porting CP/M
Kenneth Casselman
the current listings or in the FAQ (it’s the kind of question I would
expect to find in a FAQ).
I’d like to adapt CP/M to a home built 8080 system, but after reading
the CP/M User’s Manual I’m a bit confused about the memory map.
Following reset, the 8080 attempts to fetch its first instruction from
0000H so that’s where I would expect a boot ROM to be located. CP/M on
the other hand, expects 0000H to be the start of RAM.
The CP/M user's manual contains fairly detailed instructions on
customizing the BIOS, but to read the manual you'd think everything gets
loaded into RAM from disk. Obviously there has to be a boot ROM
somewhere, even if it contains nothing more than hardware initialization
and a boot loader.
I suppose you could map the boot ROM to 0000 following reset, then
relocate it or copy the relevant bits to RAM once the system has
been initialized (kind of reminds me of the 68000). Any hints?
Ken
Ty Hoeffer
Most systems used a setup like this.
ON reset a boot rom of nK ( 2k,4k,8k, whatever ) is enabled. !st it
copies itself into upper ram. next it jumps to a location within the high ram
version of itself that is compiled to un in that location. Next it outputs a 0
or 1 depending on the Hardware requirements to a hardware port that disables
the rom & enables the Low RAM. Next it starts executing the boot loader
section that goes out & reads CP/M from the disk.
PSUEDO CODE ON:
start: equ 0000h
start+0 call init_ram ; go zero out the ram 32768-65535...
start+4 copy rom to locations starting at 32768
start+50 verify values in 32768 to be valid.
start+100 jmp newstart
;
; newstart code is really at say byte #128 in the rom but the
; copy rom routine places it in the correct location to run.
; so newstart = start+103 in the rom.
newstart: equ 08000h
do boot loasder stuff here
;
PSUEDO CODE OFF:
This was a simplified version of ONE way to do what you need. There
were MANY other ways to do it. CCS used to play a trick on the memory
addressing so that untill a bit was turned on every time you tried to access
the first 2048 bytes of ram it set the high Address lines high so you were
really accessing the rom at the top of Ram. I personally hated that method
but it worked for the 4 years I had that CPU card.
Does this help?
Ty Hoeffer
Network Analyst
UVa Health System/Computing Services
In article <399457...@home.com>, Kenneth Casselman
Kenneth Casselman
Thanks,
Ken
Tim Shoppa
>
> I'm sure this question has been asked before, but I couldn't find it in
> the current listings or in the FAQ (it’s the kind of question I would
> expect to find in a FAQ).
>
> I’d like to adapt CP/M to a home built 8080 system, but after reading
> the CP/M User’s Manual I’m a bit confused about the memory map.
>
> Following reset, the 8080 attempts to fetch its first instruction from
> 0000H so that’s where I would expect a boot ROM to be located. CP/M on
> the other hand, expects 0000H to be the start of RAM.
>
> The CP/M user's manual contains fairly detailed instructions on
> customizing the BIOS, but to read the manual you'd think everything gets
> loaded into RAM from disk. Obviously there has to be a boot ROM
> somewhere, even if it contains nothing more than hardware initialization
> and a boot loader.
No, there doesn't have to be a boot ROM anywhere. Remember, we're
talking mid-1970's here, when all computers still had front panels
for you to toggle in the bootstrap with. Some early microcomputer
disk controllers had a "boot" button which read the first block from
disk into memory at location 0 for you, so there was nothing to toggle
in.
Later on, when front-panel-less systems became the norm, there
was a "PHANTOM" signal used to map the a ROM bootstrap out of
main address space after the booting process got far enough along.
See, for example, the S-100/IEEE-696 spec at
http://s-100.trailing-edge.com/
> I suppose you could map the boot ROM to 0000 following reset, then
> relocate it or copy the relevant bits to RAM once the system has
> been initialized
Yes, that's exactly the way it was often implemented. There are
of course many other methods to get the same end result, but what
you came up with is probably the most common.
Tim.
John Elliott
>CCS used to play a trick on the memory
>addressing so that untill a bit was turned on every time you tried to access
>the first 2048 bytes of ram it set the high Address lines high so you were
>really accessing the rom at the top of Ram.
The Amstrad PCW is just as devious. When it's turned on, opcodes are
generated by the printer controller chip and fed into the CPU. This
continues until the opcode OUT 248,0 is encountered; by which time, the
disc boot sector has been loaded and control passes to it.
OUT 248,1 gives control back to the printer controller and thus reboots
the machine.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Richard Erlacher
signal, which muxes the start address of a PROM, sat at 0xF000 (for a
4K EPROM, e.g. 2732) onto the bus during the first and only M1 cycle
following RESET*. It is self-disabling, in that a flipflop disables
it during the rest of the time. It finds an EPROM at 0xF000 and
proceeds. '
Another pretty common trick is to put the entire boot image in a 64Kx8
EPROM, then start the code with a routine that copies everything from
0x40 upward in the EPROM to locations 0000-0xFFBF. When it's done, it
disables the EPROM, and no disk boot was even necessary. Now you have
the full OS at your disposal. It's best, by the way, if you load a
debugger into the memory image as well. You never know . . .
Dick
On Fri, 11 Aug 2000 19:41:49 GMT, Kenneth Casselman
<ken.ca...@home.com> wrote:
>I'm sure this question has been asked before, but I couldn't find it in
>the current listings or in the FAQ (it’s the kind of question I would
>expect to find in a FAQ).
>
>I’d like to adapt CP/M to a home built 8080 system, but after reading
>the CP/M User’s Manual I’m a bit confused about the memory map.
>
>Following reset, the 8080 attempts to fetch its first instruction from
>0000H so that’s where I would expect a boot ROM to be located. CP/M on
>the other hand, expects 0000H to be the start of RAM.
>
>The CP/M user's manual contains fairly detailed instructions on
>customizing the BIOS, but to read the manual you'd think everything gets
>loaded into RAM from disk. Obviously there has to be a boot ROM
>somewhere, even if it contains nothing more than hardware initialization
>and a boot loader.
>
>I suppose you could map the boot ROM to 0000 following reset, then
>relocate it or copy the relevant bits to RAM once the system has
Steve
>
> I'm sure this question has been asked before, but I couldn't find it in
> the current listings or in the FAQ (it’s the kind of question I would
> expect to find in a FAQ).
>
> I’d like to adapt CP/M to a home built 8080 system, but after reading
> the CP/M User’s Manual I’m a bit confused about the memory map.
>
> Following reset, the 8080 attempts to fetch its first instruction from
> 0000H so that’s where I would expect a boot ROM to be located. CP/M on
> the other hand, expects 0000H to be the start of RAM.
The Boot ROM is located at 0000H till the boot process has loaded CP/M
and written it to high RAM and then banks switches out the ROM for RAM
down at 0000H and then writes a jump instruction at 0000H to high RAM
where CP/M is before turning over control to it. That warm boot remains
at 0000H-0002H and is the warmboot entry jump.
> The CP/M user's manual contains fairly detailed instructions on
> customizing the BIOS, but to read the manual you'd think everything gets
> loaded into RAM from disk. Obviously there has to be a boot ROM
> somewhere, even if it contains nothing more than hardware initialization
> and a boot loader.
--------------------------
It lives at 0000H till it loads CP/M up high, and then switches itself
out of the low address space and CP/M writes the system scratchpad from
0000H to 00FFH, which contains the entry jump and it jumps to the warm
boot.
> I suppose you could map the boot ROM to 0000 following reset, then
> relocate it or copy the relevant bits to RAM once the system has
> been initialized (kind of reminds me of the 68000). Any hints?
>
> Ken
----------------------
There are a few schemes, but all rely on an enable register to turn off
the ROM and turn on the RAM in the lower half of memory address space.
Steve
Kenneth Casselman
> [snip]
>
> No, there doesn't have to be a boot ROM anywhere. Remember, we're
> talking mid-1970's here, when all computers still had front panels
> for you to toggle in the bootstrap with. Some early microcomputer
> disk controllers had a "boot" button which read the first block from
> disk into memory at location 0 for you, so there was nothing to toggle
> in.
>
Uh, yes, you're quite right, I could toggle in the boot loader via
the front panel each time, but even 25 years ago the novelty of this
approach wore off after a while.
Actually, I did plan on including a front panel, mostly for old times
sake, but also because it provides a convenient(?) way of entering
short programs when bring the system up for the first time, or at
least it provides an alternative to the EPROM burn and churn routine
(OK so maybe it was mostly nostalgia), but unless you can find a good
deal on SPDT switches, the front panel ends up costing almost as much
as the rest of the system.
> Later on, when front-panel-less systems became the norm, there
> was a "PHANTOM" signal used to map the a ROM bootstrap out of
> main address space after the booting process got far enough along.
> See, for example, the S-100/IEEE-696 spec at
>
> http://s-100.trailing-edge.com/
>
Thanks for the link to the S-100 spec.
Ken
Jack Peacock
news:399457...@home.com...
> Following reset, the 8080 attempts to fetch its first instruction from
> 0000H so that's where I would expect a boot ROM to be located. CP/M on
> the other hand, expects 0000H to be the start of RAM.
>
force the CPU to a hi-addr ROM boot. You are correct in that the
program counter starts at 0000H, but you can force a JMP xxxxH as the
first three bytes the CPU fetches, C3 xx xx, then allow all further
fetches from the regular data bus. This is how the S-100 front panel
worked. You set the 16-bit address in the switches, then did an
EXAMINE, which actually clocked in the C3 opcode followed by the upper
and lower switches. That's why S-100 CPU cards required a special front
panel connector, to bypass the data bus for EXAMINE (JMP xx xx) and
EXAMINE NEXT (NOP) operations.
CPU cards with the ROM onboard simply gated the data from the ROM
instead of the data bus for reads until a flipflop was reset, usually
with an I/O command to a specific port. The onboard ROM would copy
itself to hi memory and run, or load the first sector of a boot disk
then disable the ROM and jump to the boot code.
CPUs with a MMU (memory management unit) had it easier, they did mapping
tricks to load low memory from the ROM, then remapped the memory and
just JMPed to 0000H. The Ithaca XPU-B had this capability. I have one
in my IMSAI, it maps a 4K page size to a 19-bit address space, allowing
up to 512K RAM physical mapped to 64K logical. Works great with CP/M
V3's and MP/M's support for extended/banked memory. I run 256K in mine.
Jack Peacock
Kenneth Casselman
Ken
dwight_...@my-deja.com
Kenneth Casselman <ken.ca...@home.com> wrote:
> Tim Shoppa wrote:
>
> > [snip]
> >
> > No, there doesn't have to be a boot ROM anywhere. Remember, we're
> > talking mid-1970's here, when all computers still had front panels
> > for you to toggle in the bootstrap with. Some early microcomputer
> > disk controllers had a "boot" button which read the first block from
> > disk into memory at location 0 for you, so there was nothing to
toggle
> > in.
> >
>
> Uh, yes, you're quite right, I could toggle in the boot loader via
> the front panel each time, but even 25 years ago the novelty of this
> approach wore off after a while.
>
Hi
You may still not need to toggle code in. My IMSAI has a
controller that does DMA. If I put the boot disk in drive A
and push the reset button, it will load the boot sector into
location zero. I then just start the execution there and
my boot code loads the rest of the system into high memory.
I do no toggling, only reset and run. There is not ROM in
the system memory, only the state machine ROM in the controller.
So, you really need to know what type of controller you have
before deciding if you need a boot ROM or not.
Dwight
Sent via Deja.com http://www.deja.com/
Before you buy.
Howard Harte
Just a note: what I did on my Northstar Horizon was modify the
power-on-jump address (a feature of the CPU board) to get it to boot from
location 0x4000. I have a FLASH device there (32K, of which 16K is actually
mapped over the RAM). On power-on-reset, the FLASH is enabled. The CPU
jumps to this address, and then the FLASH runs the boot code (I actually put
a small bootstrap program, about 256 bytes) that loads the rest of CPM3.SYS
which is also in FLASH into RAM. Then I disable the FLASH, and jump to the
newly loaded cold-boot BIOS entry point. The neat thing about this design
is that when the FLASH is enabled, reads come from the FLASH, while writes
are propagated through to the underlying RAM. This allows me to do some
neat stuff, for example, to swap out the FLASH, I copy code in place from
FLASH to the RAM underneath. Then, when the FLASH is disabled, I just keep
on executing, now from RAM. The FLASH mapping/unmapping is done via an I/O
port. My next step is to allow access to the upper 16K of the FLASH by
paging that in. This will allow me to have a boot/diags portion of FLASH,
and a lot left over so that I can put CPM3.SYS and CCP.COM. This will give
me
"instant" boot and warm boot, with no floppy disk necessary!
If you are interested, I have some source code to program the FLASH
under CP/M. This is nicer than a EPROM, because you can program it in
place. The only thing is that if I mess up the FLASH image so it won't
boot, I have to dig out my old 5.25" floppy controller, change to power-on
jump address, and boot the old N* CP/M to re-FLASH it again. I guess that's
what the boot-block FLASHes are for these days. The FLASH device that I'm
using is a 28F256A. It's 32Kx8, the same pinout as an EPROM.
Kenneth Casselman wrote in message <3996CD...@home.com>...
Lee Hart
> on my Northstar Horizon... modify the power-on-jump address to get it
> to boot from location 0x4000. I have a FLASH device there... If you
> are interested, I have some source code to program the FLASH under
> CP/M.
Pretty slick! I for one would be interested in the details on how you
did this. Essentially all CP/M computers have EPROMs. What would it take
to replace these with a Flash EPROM that could be written to in the
system?
--
Lee A. Hart Ring the bells that still can ring
814 8th Ave. N. Forget your perfect offering
Sartell, MN 56377 USA There is a crack in everything
leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen
Kenneth Casselman
>
> Ken,
>
> Just a note: what I did on my Northstar Horizon was modify the
> power-on-jump address (a feature of the CPU board) to get it to boot from
> location 0x4000. I have a FLASH device there (32K, of which 16K is actually
> mapped over the RAM). On power-on-reset, the FLASH is enabled. The CPU
> jumps to this address, and then the FLASH runs the boot code (I actually put
> a small bootstrap program, about 256 bytes) that loads the rest of CPM3.SYS
> which is also in FLASH into RAM. Then I disable the FLASH, and jump to the
> newly loaded cold-boot BIOS entry point. The neat thing about this design
> is that when the FLASH is enabled, reads come from the FLASH, while writes
> are propagated through to the underlying RAM. This allows me to do some
> neat stuff, for example, to swap out the FLASH, I copy code in place from
> FLASH to the RAM underneath. Then, when the FLASH is disabled, I just keep
> on executing, now from RAM. The FLASH mapping/unmapping is done via an I/O
> port. My next step is to allow access to the upper 16K of the FLASH by
> paging that in. This will allow me to have a boot/diags portion of FLASH,
> and a lot left over so that I can put CPM3.SYS and CCP.COM. This will give
> me
> "instant" boot and warm boot, with no floppy disk necessary!
>
This is very much like what I had in mind. I started out with the idea
of having a fixed boot ROM somewhere, but when I looked at the
guidelines
for adapting CP/M, it became "obvious" that I would have to remap or
disable
the ROM after booting. This was more or less confirmed by the responses
I got, although a number of alternative approaches were also suggested.
Since I'm designing the hardware myself, I'm not tied in to any existing
approach. What I found particulary clever about your design is the idea
of
directing the reads to FLASH and the writes to RAM - similar to the idea
of having an input port and an output port located at the same address.
It seems obvious after the fact, but I don't know how long it would have
taken to come up with the idea on my own (if ever).
> If you are interested, I have some source code to program the FLASH
> under CP/M. This is nicer than a EPROM, because you can program it in
> place. The only thing is that if I mess up the FLASH image so it won't
> boot, I have to dig out my old 5.25" floppy controller, change to power-on
> jump address, and boot the old N* CP/M to re-FLASH it again. I guess that's
> what the boot-block FLASHes are for these days. The FLASH device that I'm
> using is a 28F256A. It's 32Kx8, the same pinout as an EPROM.
>
I agree, Flash is much easier to work with than EPROM. I still use a
separate
programmer, but at least I avoid the uv erase part of the cycle.
Ken
Howard Harte
Kenneth Casselman wrote in message <399BFA...@home.com>...
>Howard Harte wrote:
>>
>> Ken,
>>
>> Just a note: what I did on my Northstar Horizon was modify the
<snip>
>
>This is very much like what I had in mind. I started out with the idea
>of having a fixed boot ROM somewhere, but when I looked at the
>guidelines
>for adapting CP/M, it became "obvious" that I would have to remap or
>disable
>the ROM after booting. This was more or less confirmed by the responses
>I got, although a number of alternative approaches were also suggested.
>
>Since I'm designing the hardware myself, I'm not tied in to any existing
>approach. What I found particulary clever about your design is the idea
>of
>directing the reads to FLASH and the writes to RAM - similar to the idea
>of having an input port and an output port located at the same address.
>It seems obvious after the fact, but I don't know how long it would have
>taken to come up with the idea on my own (if ever).
>
actually, I came up with more or less by accident. While trying to make
CPMLDR.COM ROMable (ie, separate code and data), I had a hard time finding
everything, and the FLASH version didn't work. This made me think of
allowing writes to go through to the RAM. WHat I did was program "known"
values in the entire RAM area, and then run my CPMLDR. If any bytes
changed, I knew that's where my bugs were. So it was really more of a
debugging aid. Only when I came to the point of needing to "swap out" the
FLASH on the fly, did it really come in handy. Also, say if your FLASH
happened to overlay an area of RAM that you needed to copy the OS to, you
can still do it. For this reason, I will probably increase my usable FLASH
from 16k to 32k.
-Howard
Harold Bower
>
> Howard Harte wrote:
> > to boot from location 0x4000. I have a FLASH device there... If you
> > are interested, I have some source code to program the FLASH under
> > CP/M.
>
> did this. Essentially all CP/M computers have EPROMs. What would it take
> to replace these with a Flash EPROM that could be written to in the
> system?
> --
> Lee A. Hart Ring the bells that still can ring
> 814 8th Ave. N. Forget your perfect offering
> Sartell, MN 56377 USA There is a crack in everything
> leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen
To see how easy it is to implement, look at Dave Brooks' P112. It can
program many sizes and types of flash memory, and uses a 32k x 8 unit as
the boot device. It can be in-circuit updated, and a 28-32 pin adapter
can be easily made to plug in a 27c256 EPROM for disaster-recovery. I
keep one around for my two P112s. I think that if I ever build another,
I'll incorporate the design there as well.
Hal
Jack Cammell
Please keep the Group advised to the progress of this effort, I for one am very
interested. With maybe a how to do it later on.
Jack
Herbert R Johnson
Tim Shoppa <sho...@trailing-edge.com> wrote:
*>Kenneth Casselman wrote:
*>>
*>> Following reset, the 8080 attempts to fetch its first instruction from
*>> 0000H so that’s where I would expect a boot ROM to be located. CP/M on
*>> the other hand, expects 0000H to be the start of RAM.
*>>
*>> The CP/M user's manual contains fairly detailed instructions on
*>> customizing the BIOS, but to read the manual you'd think everything gets
*>> loaded into RAM from disk. Obviously there has to be a boot ROM
*>> somewhere, even if it contains nothing more than hardware initialization
*>> and a boot loader.
*>
*>No, there doesn't have to be a boot ROM anywhere. Remember, we're
*>talking mid-1970's here, when all computers still had front panels
*>for you to toggle in the bootstrap with. Some early microcomputer
*>disk controllers had a "boot" button which read the first block from
*>disk into memory at location 0 for you, so there was nothing to toggle
*>in.
*>
*>Later on, when front-panel-less systems became the norm, there
*>was a "PHANTOM" signal used to map the a ROM bootstrap out of
*>main address space after the booting process got far enough along.
[snip]
There are a number of ways to force an 8080/Z80 system to "start"
at an arbitrary address. A classic front panel system jams instructions
directly into the data lines of the processor: say, a "jump F000H"
instruction so that a ROM at F000H is executed. Some S-100 processor
cards jammed such an instruction into the processor after reset and
restart. Or, a ROM is addressed
at 0000H after system reset, but then the address logic is changed
(either at the end of the ROM program, or by a memory or I/O access)
to map the ROM to a new location or to disable it. Also, some S-100
disk controllers included the logic to access their ROMs
from startup, in the ways I've described; but some did not.
The DRI CP/M manuals (apparently) did not discuss this because there was no
standard method, and it was an issue somewhat independent of the CP/M
implementation, other than the fact that EVENTUALLY low memory must be
available for CP/M. (Even so there was a flavor of CP/M for use in
higher memory, but it was not very popular.)
One source for the various ways to start-up an 8080/Z80 system is the
various CPU and floppy disk controller designs used in S-100 systems
(IMSAI, Altair, Compupro, etc.). CHeck my Web site for a list of manuals
for those cards for many S-100 systems. Another source would be other Z80
or 8080 hardware designs (or for that matter other 8-bit processors) that
may reside on the Web: A Web search would be productive.
But I see in a later note of yours (Ken) that you have considered a front
panel as well for your system. Again, there are some front panel designs
in my S-100 docs; at least they offer hints about how that has been done.
Herb Johnson
Herbert R. Johnson http://pluto.njcc.com/~hjohnson
hjoh...@pluto.njcc.com voice 609-771-1503, New Jersey USA
amateur astronomer and astro-tour guide
S-100 computer parts, manuals as "Dr. S-100"
reseller of 68K Macs & accessories for your computing pleasure
--
Herbert R. Johnson http://pluto.njcc.com/~hjohnson
hjoh...@pluto.njcc.com voice 609-771-1503, New Jersey USA
amateur astronomer and astro-tour guide
classic S-100 computers restoration & parts as "Dr. S-100"
rebuilder/reseller of classic Macs for your computing pleasure
and senior engineer at Astro Imaging Systems
av...@spam.com
>I'm sure this question has been asked before, but I couldn't find it in
>the current listings or in the FAQ (it’s the kind of question I would
>expect to find in a FAQ).
>
>I’d like to adapt CP/M to a home built 8080 system, but after reading
>the CP/M User’s Manual I’m a bit confused about the memory map.
>
>Following reset, the 8080 attempts to fetch its first instruction from
>0000H so that’s where I would expect a boot ROM to be located. CP/M on
>the other hand, expects 0000H to be the start of RAM.
>
>The CP/M user's manual contains fairly detailed instructions on
>customizing the BIOS, but to read the manual you'd think everything gets
>loaded into RAM from disk. Obviously there has to be a boot ROM
>somewhere, even if it contains nothing more than hardware initialization
>and a boot loader.
>
>I suppose you could map the boot ROM to 0000 following reset, then
>relocate it or copy the relevant bits to RAM once the system has
>been initialized (kind of reminds me of the 68000). Any hints?
>
>Ken
I've read all the information posting on this topic. It's very
interesting for me as I'm thinking in doing something similar.
But I have an interesting question...
Is possible to implement CP/M on a small home made computer without
using any "SOFT/HARD RAM-ROM switch stuff"?
Maybe some minor changes on the CP/M source code would be sufficient.
What do you think?
Mario Emmanuel.
http://www.terra.es/personal2/mario_emmanuel
Spain. Western Europe.
Steve
>
> I've read all the information posting on this topic. It's very
> interesting for me as I'm thinking in doing something similar.
>
> But I have an interesting question...
>
> Is possible to implement CP/M on a small home made computer without
> using any "SOFT/HARD RAM-ROM switch stuff"?
>
> Maybe some minor changes on the CP/M source code would be sufficient.
> What do you think?
>
> Mario Emmanuel.
> http://www.terra.es/personal2/mario_emmanuel
> Spain. Western Europe.
There has to be some code that the processor can read when it starts.
If you have RAM code, then how did it get there? If ROM, then it will
have to be switched out to have a contiguous 64K. There are not many
ways to do this unless your FDController can DMA code in for you and
then start the processor.
-Steve
Harold Bower
>
> I've read all the information posting on this topic. It's very
> interesting for me as I'm thinking in doing something similar.
>
> But I have an interesting question...
>
> Is possible to implement CP/M on a small home made computer without
> using any "SOFT/HARD RAM-ROM switch stuff"?
>
> Maybe some minor changes on the CP/M source code would be sufficient.
> What do you think?
>
> Mario Emmanuel.
> http://www.terra.es/personal2/mario_emmanuel
> Spain. Western Europe.
If you use a Z180 or variant that uses this core, you can simply map the
ROM out with the MMU. Among systems that did this were MicroMint's
SB180 (HD64180) and SB180FX (Z180), YASBEC (Z180) and P112 (Z182). With
a 1MB Memory Map, this opens up quite a bit even though only 64k is
directly accessible for executing. The remapping would be done at the
end of the startup code and usually goes either to a monitor or boot
loader. No changes are required to CP/M unless you get fancy by adding
your own drivers such as a RAM disk, but these only affect the BIOS
which you must write yourself anyway.
Hal
Howard M. Harte
It seems to be working pretty well. I got the hard drive (IDE)
interface going, and I'm using 8-bit transfers instead of 16. This saved me
a lot of wire wrapping and re-wrapping stuff that I already did. I got the
idea from Andrew Quinn's TRS-80 Hard Disk interface design. The only
difference is that I used a PC/AT I/O card. With two serial. parallel, FDC,
IDE, and game ports. Both floppy drives work well, at 720k each
(low-density 3-1/2" disks) I "overclocked" the Z80 CPU board to 6MHz (I put
a 20MHz CMOS Z80 in the socket though!) It actually runs fine at 8MHz too,
the only problem that I have is that I haven't written a driver for my
second serial port to work with Kermit, so I need to use the serial port on
the Horizon motherboard for that. It only seems to work ok to 6MHz. After
that, I get nothing from the UARTs. Running the Z80 at 6 or 8 MHz, I may be
able to get 1.44M disks to work too. They use a faster data rate than the
720K disks.
I put a 1.2GB IDE drive in the machine, but since I'm using only 8-bits
of the IDE interface, I get only 600M useable with a 256-byte physical
sector size. The drive has 16 heads, so for now, I'm using each head as a
separate "drive" of 8MB each, using 8K blocks. I tried having 32M drives,
but it takes very long to read the directory, so I figured 14 8Mb drives
will be enough for now. I am not using hashing for the directory, because
since I haven't gotten the bank switching working yet or written the BIOS
routines for that, it eats up way too much memory. Without hashing, I have
a 50K TPA. The hard drive BIOS module added less than 450 bytes, so I'm
happy with that.
I need to clean up the code and finish the schematics, but I will put
all the stuff on-line as soon as possible. If anyone is interested in a
specific portion sooner, just email me.
-Howard
"Jack Cammell" <j.ca...@xtra.co.nz> wrote in message
news:399C4DC3...@xtra.co.nz...
Andrew Quinn
looking at modifying CP/M for the Model 4 to use the IDE drive.
Regards..... Andrew
"Howard M. Harte" <hha...@cisco.com> wrote in message
news:966744583.24617@sj-nntpcache-3...
Unknown
>There has to be some code that the processor can read when it starts.
>If you have RAM code, then how did it get there? If ROM, then it will
>have to be switched out to have a contiguous 64K. There are not many
>ways to do this unless your FDController can DMA code in for you and
>then start the processor.
>-Steve
Well I was thinking in starting with an 16KB EPROM at 0000H. Then the
EPROM moves what it needs to the rest of the memory (that is, 48KB of
upper RAM) and then CP/M is executed at that address without any
switching stuff. Doing this is possible, I'm sure about that, but
question is how complex is to rearrange the CP/M source code to do
this. Maybe someone experienced could give some kind of help or
comments.
All this is not a nonsense because it would provide the ability to use
CP/M on a large number of Z80-based cheap single board computers. I'm
thinking in build such a single board computer, which doesn't have any
ROM/RAM switching stuff (if anyone is interested the schematics are
available in my web site, see
http://www.terra.es/personal2/mario_emmanuel/PROJECTS/MonoplacaZ80.pdf
)
Thanks for your comments.
Mario Emmanuel Martinez
Unknown
<halb...@cablespeed.com> wrote:
>If you use a Z180 or variant that uses this core, you can simply map the
>ROM out with the MMU. Among systems that did this were MicroMint's
>SB180 (HD64180) and SB180FX (Z180), YASBEC (Z180) and P112 (Z182). With
>a 1MB Memory Map, this opens up quite a bit even though only 64k is
>directly accessible for executing. The remapping would be done at the
>end of the startup code and usually goes either to a monitor or boot
>loader. No changes are required to CP/M unless you get fancy by adding
>your own drivers such as a RAM disk, but these only affect the BIOS
>which you must write yourself anyway.
>
>Hal
Sounds nice and easy. But as the purpouse is to allow me using cheap
Z80 single board computers it would make me to search for new boards
or building my own Z180 board, which is something that at this time I
don't want to do.
Anyway the solution you give seems to be useful and easy.
Mario Emmanuel Martínez
nos...@nouce.bellatalntic.net
(s...@my.web.site.to.get.my.email) wrote:
>On Sat, 19 Aug 2000 16:29:59 -0700, Steve <rst...@armory.com> wrote:
>
>Well I was thinking in starting with an 16KB EPROM at 0000H. Then the
>EPROM moves what it needs to the rest of the memory (that is, 48KB of
>upper RAM) and then CP/M is executed at that address without any
>switching stuff. Doing this is possible, I'm sure about that, but
>question is how complex is to rearrange the CP/M source code to do
>this. Maybe someone experienced could give some kind of help or
>comments.
>
this can be done... There are caveats though. The base page stuff at
locations 0-100h would simply be moved up to start of ram. Interrupts
that use the base page would ahve gode in rom to revector them.
Here's the yabut, ALL OF YOUR APPS will not run as they expect to load
at 100H! Anything you dont have source to will be broken as it
expects tpa to start at 100h. This also inclused DDT, PIP, ASM, ED,
STAT, they would all have to be reassembled for your new starting TPA
(4100h for 16k rom). Also the BIOS coldboot, warmboot would ahve to
do their thing to a start address offest of 4000h and CCP would have
to load to 4100h.
For one lousy bit and a trivial logic you could have a system that
bots from rom and has a 64k memory address range.
Allison
William J. Leary Jr.
news:39a01c1b....@news.bellatlantic.net...
> For one lousy bit and a trivial logic you could have a system that
> bots from rom and has a 64k memory address range.
Back in the TRS-80 days a fellow I worked with modified his '80 so that he
could turn off the ROM and map in RAM and move the video memory. I don't
recall the details right now. He ended up with, as I recall, a 50 or 60K
linear address space with the video sitting above main memory.
He then got standard CP/M (with his own BIOS) to run on it by having it boot
his own code to RAM, turn on is re-mapper, then boot CP/M normally. Very
creative. His motivation, of course, was that he didn't want to be limited
to TRS-80 specific versions of CP/M programs. There were things he wanted
to use that weren't available. And he wanted the stuff he wrote to be
"normal."
- Bill
Barry Watzman
1. The system is all RAM. A DMA disk controller puts boot code into the
RAM. Example: The original IMSAI system with the IFM/FIB dual 8" calcomp
drives.
2. There is a boot rom in high memory. The CPU board does a power on jump
after reset. This is done in HARDWARE on the CPU board, memory is uneffected
in any way. After booting from disk, the boot rom in high memory MIGHT "go
away" and be replaced with RAM through some form of bank switching. Example
of this: Cromemco systems, SOL-20 computers.
3. The system is all RAM, but the RAM at zero responds to the "Phantom"
signal, an S-100 bus signal. When this signal is asserted, any memory board
responding to it stays off the bus and does not respond to memory reads,
while (in most cases) responding normally to memory writes. The disk
controller has a small PROM that shows up at address zero after a reset and
until disabled. The disk controller also asserts Phantom while this PROM is
enabled. The prom reads the boot code into memory and jumps to it, the boot
code disables the PROM, leaving an all-ram system after booting. Example:
Tarbell disk controlers
There are other ways, but these three or a variant were the most common
techniques.
av...@spam.com wrote:
> On Fri, 11 Aug 2000 19:41:49 GMT, Kenneth Casselman
> <ken.ca...@home.com> wrote:
>
> >I'm sure this question has been asked before, but I couldn't find it in
> >the current listings or in the FAQ (it’s the kind of question I would
> >expect to find in a FAQ).
> >
> >I’d like to adapt CP/M to a home built 8080 system, but after reading
> >the CP/M User’s Manual I’m a bit confused about the memory map.
> >
> >Following reset, the 8080 attempts to fetch its first instruction from
> >0000H so that’s where I would expect a boot ROM to be located. CP/M on
> >the other hand, expects 0000H to be the start of RAM.
> >
> >The CP/M user's manual contains fairly detailed instructions on
> >customizing the BIOS, but to read the manual you'd think everything gets
> >loaded into RAM from disk. Obviously there has to be a boot ROM
> >somewhere, even if it contains nothing more than hardware initialization
> >and a boot loader.
> >
> >I suppose you could map the boot ROM to 0000 following reset, then
> >relocate it or copy the relevant bits to RAM once the system has
> >been initialized (kind of reminds me of the 68000). Any hints?
> >
> >Ken
>
> I've read all the information posting on this topic. It's very
> interesting for me as I'm thinking in doing something similar.
>
> But I have an interesting question...
>
> Is possible to implement CP/M on a small home made computer without
> using any "SOFT/HARD RAM-ROM switch stuff"?
>
> Maybe some minor changes on the CP/M source code would be sufficient.
> What do you think?
>
> Mario Emmanuel.
nos...@nouce.bellatalntic.net
<hha...@cisco.com> wrote:
>Just wanted to give an update of my progress with CP/M 3 on the Northstar.
>
> It seems to be working pretty well. I got the hard drive (IDE)
>interface going, and I'm using 8-bit transfers instead of 16. This saved me
It's a cheap and dirty way to get a hard disk on a system, works
though.
The Serial port ptoblems are likely marginal timing due to when the
device select becomes true and the read/write line timing overlap.
Try delaying (use a few 7404s in series) the IORQ/. (I assume your
using a Z80 not Z180). Also be wary that at 8mhz your Tacc timing for
read/write to the serial devices may be marginal due to accumulated
delays through bus interface and IDE interface logic.
> I put a 1.2GB IDE drive in the machine, but since I'm using only 8-bits
>of the IDE interface, I get only 600M useable with a 256-byte physical
>sector size. The drive has 16 heads, so for now, I'm using each head as a
>separate "drive" of 8MB each, using 8K blocks. I tried having 32M drives,
>but it takes very long to read the directory, so I figured 14 8Mb drives
Use P2dos or ZRdos as they can have logical drives harger than 8mb.
You can also use OFFSET (the reserved tracks) to map a second disk
to each head as it appers you only using half the available cylinders
per head.
Also DON'T, unless your have a specific reason, install all possible
drives. It's going to eat TPA space like mad. A banked bios of will
support this better. An alternative is to create a means to mount
and dismount logical drives and keep a smaller number of partitions
online, This also can allow for mapping the lonted drive to specific
physical device names (A:, B:...). I find it handy to do this.
You didn't say what the ALLOCation size is. I happen to use 4k
most of the time unless the drive is for starting large hunks of data
then I may go with 16k or 32k. Keep the directory to one allocation
where possible or minimum of 256 entries whichever happens first.
I'ts a trick and often useage will fill a directory first or fill the
disk first if the ALLOC siaze and DIRsize are out of scale to each
other.
Also as you have learned a linear search of the directory is painful.
there are two things you can do (banked bios is a must), one is cache
the directory as that will save disk IO. the other is limit the number
of directory entries. Novados (or was it suprbdos) is a possible
solution as it has drectory hashing in the BDOS.
> I need to clean up the code and finish the schematics, but I will put
>all the stuff on-line as soon as possible. If anyone is interested in a
>specific portion sooner, just email me.
I'd be interested in seeing your IDE driver.
My major project is heirarchal directories that would be compatable
with existing apps. I find the user directory scheme too limiting.
The basic plan is start with a BDOS that can can handle large disks
512mb-->1gb then allow for subdirectories (max 32mb) within the
larger disk. use of partitions and User are ruled out to implement
this though they would be supported in their normal way. Two starting
issues are insuring recusive/reentrant code in BDOS and BIOS to
allow it to call itself if need be and ALLOCATION tracking.
The latter is the mean peice. ALLOCCATION tracking or "who used what"
is done by reading (or rereading the directory) and building an in
memory bit map (ALLOC) of the used and not used allocations(blocks of
physical sectors). This has a few problems, it's slow and if you have
a subdirectory you have to transverse all of them before you know
whats in use. That is very important so you know what can be used
when you write a new file or directory.
Anywho I have some ideas but would be interested in activities along
this line.
Allison
Mario Emmanuel
>this can be done... There are caveats though. The base page stuff at
>locations 0-100h would simply be moved up to start of ram. Interrupts
>that use the base page would ahve gode in rom to revector them.
>
>Here's the yabut, ALL OF YOUR APPS will not run as they expect to load
>at 100H! Anything you dont have source to will be broken as it
>expects tpa to start at 100h. This also inclused DDT, PIP, ASM, ED,
>STAT, they would all have to be reassembled for your new starting TPA
>(4100h for 16k rom). Also the BIOS coldboot, warmboot would ahve to
>do their thing to a start address offest of 4000h and CCP would have
>to load to 4100h.
>
>For one lousy bit and a trivial logic you could have a system that
>bots from rom and has a 64k memory address range.
>
>Allison
I think I understand the problem... it isn't sufficient to rewrite the
CP/M code itself, I should reassemble every application I would like
to use. That does my solution invalid so I will build a board with a
normal bootstrap with EPROM/RAM switch stuff.
If I build a board using CP/M it's clear that I would like to use as
many standard software as possible.
Thank you very much for your comments Allison.
Mario Emmanuel Martínez
Kenneth Casselman
design stage.
The basic idea is to provide roughly the same functionality as a PC or
XT using an 8080 instead of an 8088. I had originally intended to port
MS-DOS to the 8080 as well, but after reading the CP/M User's Manual,
decided that it might be more realistic to adapt CP/M.
One of the objectives of this project is to minimize cost by using as
many readily available, off the shelf PC components as possible (e.g.
case, power supply, keyboard, disk drives, etc.). It may also be
possible to use some of the existing adapters (e.g. disk controller,
I/O, etc.), but I’m not sure if I really want to go that route (kinda
takes all the fun out of it). I don't mind building my own floppy
controller, but I intend to use an IDE hard disk as well, also inspired
(at least in part) by Andrew's interface for the TRS-80. (Panasonic has
an IDE floppy drive of sorts, the LS-120, that's designed to work with
120Meg removable media, but that can read and write 3 1/2" floppies as
well).
I wasn’t sure at first how (or even if) I was going to allow for future
expansion. Since the whole idea is to provide the functionality of a
PC, it would seem only logical to adopt the ISA bus as well. I briefly
considered the S-100 bus (the "classic" 8-bit expansion bus) and STD bus
(another classic) but ruled them out largely on the basis of cost. At
one point I seriously considered adopting PC/104 which is electrically
similar (identical?) to the ISA bus but eliminates the backplane all
together by stacking the cards. What decided it in the end was when I
discovered just how inexpensive ISA backplanes are. Advantech sells a
6-slot passive backplane for about $40 US and an 8-slot backplane for
about $60 (someone had a 6-slot backplane listed on eBay recently for
as little as $12.95).
Ken
Harold Bower
>
> Wish I could report the same success, but I'm still pretty much in the
> design stage.
>
> The basic idea is to provide roughly the same functionality as a PC or
> XT using an 8080 instead of an 8088. I had originally intended to port
> MS-DOS to the 8080 as well, but after reading the CP/M User's Manual,
> decided that it might be more realistic to adapt CP/M.
Why use the 8080? It was an outmoded part as soon as the Z80 came out.
> One of the objectives of this project is to minimize cost by using as
> many readily available, off the shelf PC components as possible (e.g.
> case, power supply, keyboard, disk drives, etc.). It may also be
> possible to use some of the existing adapters (e.g. disk controller,
> I/O, etc.), but I?m not sure if I really want to go that route (kinda
> takes all the fun out of it). I don't mind building my own floppy
> controller, but I intend to use an IDE hard disk as well, also inspired
> (at least in part) by Andrew's interface for the TRS-80. (Panasonic has
> an IDE floppy drive of sorts, the LS-120, that's designed to work with
> 120Meg removable media, but that can read and write 3 1/2" floppies as
> well).
>
> I wasn?t sure at first how (or even if) I was going to allow for future
> expansion. Since the whole idea is to provide the functionality of a
> PC, it would seem only logical to adopt the ISA bus as well. I briefly
> considered the S-100 bus (the "classic" 8-bit expansion bus) and STD bus
> (another classic) but ruled them out largely on the basis of cost. At
> one point I seriously considered adopting PC/104 which is electrically
> similar (identical?) to the ISA bus but eliminates the backplane all
> together by stacking the cards. What decided it in the end was when I
> discovered just how inexpensive ISA backplanes are. Advantech sells a
> 6-slot passive backplane for about $40 US and an 8-slot backplane for
> about $60 (someone had a 6-slot backplane listed on eBay recently for
> as little as $12.95).
Yes, you CAN use an 8-bit Micro to take advantage of the ISA
peripherals, but I'd recommend that you re-consider the use of an 8080
processor, and suggest one with a Z180 core. The rationale is:
- Z180 MMU handles the 20-bit (1MB) memory addressing
- Z180 core has simpler mechanisms for handling IO Ports > 255
- Z180 has more Interrupt pins than the 8080 to simply IRQ
equivalences
I have a laptop built with a Z180 CP/M machine interfaced to an ISA
8-bit LCD controller. The system only required a single 16V8 GAL to
generate the necessary interface signals, and even keeps the video ROM
(rewritten in Z180 code, of course) at the C0000-C7FFFH address range,
and the Video Memory at B8000-BFFFFH as in the IBM-type PC. I would
never even consider such a project with a less capable processor.
Just an opinion.
Hal
> Ken
nos...@nouce.bellatalntic.net
(Mario Emmanuel) wrote:
>I think I understand the problem... it isn't sufficient to rewrite the
>CP/M code itself, I should reassemble every application I would like
>to use. That does my solution invalid so I will build a board with a
>normal bootstrap with EPROM/RAM switch stuff.
>
>If I build a board using CP/M it's clear that I would like to use as
>many standard software as possible.
If you use 64k of ram the simpest thing is to overlay a rom,
such that its enable disables ram for that address space.
then all you do is copy from boot rom to high ram disable the rom and
then setup low ram.
FYI CPM runs best with a 56-64k TPA as many of the better apps
want that much space.
A good cpm system should have: <in my opine...)
Z80, faster the better (or z180)
3 serial ports (console, modem, serial printer or AUX)
parallel port for parallel port printer (centronics interface)
64k of ram (more bank switched with rom is better)
Timer (8253 or similar)
DMA (to unburden cpu for FDC and block IO)
FDC
IDE interfaced HDC
Optional:
Time of year clock (not widely used by cpm apps.)
Generic parallel port (one or two 8255s) for expeimental IO
Allison
nos...@nouce.bellatalntic.net
<ken.ca...@home.com> wrote:
>Wish I could report the same success, but I'm still pretty much in the
>design stage.
>
>The basic idea is to provide roughly the same functionality as a PC or
>XT using an 8080 instead of an 8088. I had originally intended to port
>MS-DOS to the 8080 as well, but after reading the CP/M User's Manual,
>decided that it might be more realistic to adapt CP/M.
MSdos for 8080 is possible as it's the filesystem that is different
(fat vs allocation). there is evena utility for 8080 cpm that will
read/write dos files on floppy.
>One of the objectives of this project is to minimize cost by using as
>many readily available, off the shelf PC components as possible (e.g.
Why 8080 and not Z80, it's far easier to use and offeres better
perfomance?
>case, power supply, keyboard, disk drives, etc.). It may also be
>possible to use some of the existing adapters (e.g. disk controller,
>I/O, etc.), but I’m not sure if I really want to go that route (kinda
>takes all the fun out of it). I don't mind building my own floppy
>controller, but I intend to use an IDE hard disk as well, also inspired
>(at least in part) by Andrew's interface for the TRS-80. (Panasonic has
>an IDE floppy drive of sorts, the LS-120, that's designed to work with
>120Meg removable media, but that can read and write 3 1/2" floppies as
>well).
The easy way would be to make a Z80 card that has DMA, ram, rom and
bus interface for ISA-8bit, then you can use ISA-8bit boards. if you
wanted to keep the cards simpler one could have Z80 and DMA with bus
interface for ISA-8, then card two would be ram/rom with the
remaining cards for Video, keyboard, Serial, Parallel printer and of
course FDC/IDE. There are boards to do ISA-8 to standard IDE
as well. The interface of Z80 to ISA-8 is trivial, buffer address,
data and decode MEMRD/, MEMWR/, IORD/, IOWR/ from the
z80 IORQ/, RD/, and WR/ few touches for DMA and done.
>expansion. Since the whole idea is to provide the functionality of a
>PC, it would seem only logical to adopt the ISA bus as well. I briefly
>considered the S-100 bus (the "classic" 8-bit expansion bus) and STD bus
S100 suffers from a multitue of signals that were derived from the raw
8080 pins. MULTIBUS and ISA are nearly identical if you allow for
some inversions and the munged interrupts.
>(another classic) but ruled them out largely on the basis of cost. At
>one point I seriously considered adopting PC/104 which is electrically
>similar (identical?) to the ISA bus but eliminates the backplane all
>together by stacking the cards. What decided it in the end was when I
>discovered just how inexpensive ISA backplanes are. Advantech sells a
>6-slot passive backplane for about $40 US and an 8-slot backplane for
>about $60 (someone had a 6-slot backplane listed on eBay recently for
>as little as $12.95).
ISA backplanes, I cut them out of old XT (isa-8) or AT (isa-16)bus
motherboards. typically 4-6 slots.
What makes ISA appealing is the abundance of old cards for small
prices. Current effort is a z280 based ISA-16 (ATbus) firebreather
that I'm working on for the revised BDOS effort.
Allison
nos...@nouce.bellatalntic.net
<halb...@cablespeed.com> wrote:
>> MS-DOS to the 8080 as well, but after reading the CP/M User's Manual,
>> decided that it might be more realistic to adapt CP/M.
>
>Why use the 8080? It was an outmoded part as soon as the Z80 came out.
Hal, I'm with you there. I jumped on the z80 when it hit the streets.
Much better.
>Yes, you CAN use an 8-bit Micro to take advantage of the ISA
>peripherals, but I'd recommend that you re-consider the use of an 8080
>processor, and suggest one with a Z180 core. The rationale is:
or even a z80 and limit to 64k space. Though MMU is trivial.
>I have a laptop built with a Z180 CP/M machine interfaced to an ISA
>8-bit LCD controller. The system only required a single 16V8 GAL to
This interests me, Which LCD and controller?
Allison
Harold Bower
[snip]
> >I have a laptop built with a Z180 CP/M machine interfaced to an ISA
> >8-bit LCD controller. The system only required a single 16V8 GAL to
>
> This interests me, Which LCD and controller?
>
> Allison
I used the 8-bit controller card from Earth Technologies. They
advertise in Circuit Cellar. Actually, they have a kit price with 7 or
9" monochrome backlit displays, a cable and the controller. Used a 7"
display for the laptop, and a 9" on a stand-alone terminal powered by a
Z-World controller with the ROM redone to make a terminal to emulate
H19, Wyse 60 or VT100 at up to 38.4 kbps (with handshaking for flow
control). The last time I ordered (nearly 2 years ago), they only had a
few hundred of the 8-bit controller cards left.
Hal
Hans Bus
<snip>
> All this is not a nonsense because it would provide the ability to use
> CP/M on a large number of Z80-based cheap single board computers. I'm
> thinking in build such a single board computer, which doesn't have any
> ROM/RAM switching stuff (if anyone is interested the schematics are
> available in my web site, see
> http://www.terra.es/personal2/mario_emmanuel/PROJECTS/MonoplacaZ80.pdf
> )
- you use memory mapped i/o (decoding with MREQ on the LS138)
- the Z80-SIO uses IORQ in its decoding, not MREQ, so SIOSEL and
IORQ will never be active simultaniously : it won't work
the parallel interface will work, it doesn't use IORQ.
You cannot use the i/o instructions for them, since you use MREQ to decode.
You connect the OE pins to GND : What happens if you write to RAM ?
-CS1 gets active (via MREQ), OE is grounded (active) : RAM outputs get active
BUT you wanted to write, so the Z80 has data on the bus as well !!!!
You could perhaps use RD to enable OE, or change the memory decoding.
Good luck.
>
> Thanks for your comments.
>
> Mario Emmanuel Martinez
> http://www.terra.es/personal2/mario_emmanuel
> Spain. Western Europe.
Regards,
Hans Bus (jbu...@LucentDOT.COM, you get the SPAM-drift?)
anon...@bogus_address.con
On 2000-08-20 ken.ca...@home.com said:
>The basic idea is to provide roughly the same functionality as a PC
>or XT using an 8080 instead of an 8088. I had originally intended
>to port MS-DOS to the 8080 as well, but after reading the CP/M
>User's Manual, decided that it might be more realistic to adapt
>CP/M.
>
>One of the objectives of this project is to minimize cost by using
>as many readily available, off the shelf PC components as possible
>(e.g. case, power supply, keyboard, disk drives, etc.). It may
>also be possible to use some of the existing adapters (e.g. disk
>controller, I/O, etc.), but I’m not sure if I really want to go
>that route (kinda takes all the fun out of it). I don't mind
>building my own floppy controller, but I intend to use an IDE hard
>disk as well, also inspired (at least in part) by Andrew's
>interface for the TRS-80. (Panasonic has an IDE floppy drive of
>sorts, the LS-120, that's designed to work with 120Meg removable
>media, but that can read and write 3 1/2" floppies as well).
>
>I wasn't sure at first how (or even if) I was going to allow for
>future expansion. Since the whole idea is to provide the
>functionality of a PC, it would seem only logical to adopt the ISA
>bus as well. I briefly considered the S-100 bus (the "classic"
>8-bit expansion bus) and STD bus (another classic) but ruled them
>out largely on the basis of cost. At one point I seriously
>considered adopting PC/104 which is electrically similar
>(identical?) to the ISA bus but eliminates the backplane all
>together by stacking the cards. What decided it in the end was
>when I discovered just how inexpensive ISA backplanes are.
>
>Advantech sells a 6-slot passive backplane for about $40 US and an
>8-slot backplane for about $60 (someone had a 6-slot backplane
>listed on eBay recently for as little as $12.95).
You can pick up a used, completely functional 8088-based 8 or 10 MHz.
turbo XT-class IBM-compatible in many thrift stores for as little as
$US 1.99.
Why not consider using one of these machines instead?
You could run CP/M-86 (or even DOS) as your O.S., and still run all
your favorite CP/M software, using CP/M-80 emulation.
It would be a cheap, fast, and totally standardized way of getting
you wherever you're going.
Just a thought. :)
Marten Feldtmann
> 3 serial ports (console, modem, serial printer or AUX)
> parallel port for parallel port printer (centronics interface)
> 64k of ram (more bank switched with rom is better)
> Timer (8253 or similar)
> DMA (to unburden cpu for FDC and block IO)
> FDC
> IDE interfaced HDC
Is something like this available ? I've several old Z-80
machines and I would like to add a new card to this system
having DMA, FDC and IDE support.
Of course the i/o-port addresses have to be configurable
due to the system I use ....
Marten
Kenneth Casselman
<snip>
>
> Why use the 8080? It was an outmoded part as soon as the Z80 came out.
>
Just because...
(It would probably be impossible to justify using an 8080 so I won't
even try).
Ken
Axel Berger
KC>What decided it in the end was when I discovered just how inexpensive
KC>ISA backplanes are. Advantech sells a 6-slot passive backplane for
KC>about $40 US and an 8-slot backplane for about $60
That's cheap, is it? All you need is a single sided PCB and a few
connectors. Power lines can be soldered wires. 80 and 120 DM sounds way
excessive.
--
Tschö wa
Axel
cbfal...@my-deja.com
anonymous@bogus_address.con wrote:
>
> On 2000-08-20 ken.ca...@home.com said:
>
> >The basic idea is to provide roughly the same functionality as a PC
> >or XT using an 8080 instead of an 8088. I had originally intended
> >to port MS-DOS to the 8080 as well, but after reading the CP/M
> >User's Manual, decided that it might be more realistic to adapt
> >CP/M.
.... snipped ...
>
> You can pick up a used, completely functional 8088-based 8 or 10 MHz.
> turbo XT-class IBM-compatible in many thrift stores for as little as
> $US 1.99.
>
> Why not consider using one of these machines instead?
>
> You could run CP/M-86 (or even DOS) as your O.S., and still run all
> your favorite CP/M software, using CP/M-80 emulation.
>
> It would be a cheap, fast, and totally standardized way of getting
> you wherever you're going.
Get one with a V20 chip and it has the capability of executing 8080
(not z80) machine code in addition to the 8088 opcodes.
--
Chuck Falconer (cbfal...@my-deja.com)
http://www.qwikpages.com/backstreets/cbfalconer/
Sent via Deja.com http://www.deja.com/
Before you buy.
Howard Harte
If you really want to take all the fun out of it, maybe you can just
pick up an old XT machine, and make a daughter card that plugs into the 8088
socket, and has an 8080 on it. You just have to add some logic to be able
to access the entire 0-0x3FF ISA I/O address space. Also, you might want to
put an SRAM on the board so you don't have to hassle with all the DRAM
stuff. The best part about this approach is that it would be pretty easy,
and you have a chassis, power supply, motherboard with peripherals and a
backplane. You even have room for EPROM on there. May just need to move
some address lines around.
-Howard
Harold Bower wrote in message <39A07E0E...@cablespeed.com>...
>Kenneth Casselman wrote:
>>
>> Wish I could report the same success, but I'm still pretty much in the
>> design stage.
>>
>> The basic idea is to provide roughly the same functionality as a PC or
>> XT using an 8080 instead of an 8088. I had originally intended to port
>> MS-DOS to the 8080 as well, but after reading the CP/M User's Manual,
>> decided that it might be more realistic to adapt CP/M.
>
>Why use the 8080? It was an outmoded part as soon as the Z80 came out.
>
>> One of the objectives of this project is to minimize cost by using as
>> many readily available, off the shelf PC components as possible (e.g.
>> case, power supply, keyboard, disk drives, etc.). It may also be
>> possible to use some of the existing adapters (e.g. disk controller,
>> I/O, etc.), but I?m not sure if I really want to go that route (kinda
>> takes all the fun out of it). I don't mind building my own floppy
>> controller, but I intend to use an IDE hard disk as well, also inspired
>> (at least in part) by Andrew's interface for the TRS-80. (Panasonic has
>> an IDE floppy drive of sorts, the LS-120, that's designed to work with
>> 120Meg removable media, but that can read and write 3 1/2" floppies as
>> well).
>>
>> I wasn?t sure at first how (or even if) I was going to allow for future
>> expansion. Since the whole idea is to provide the functionality of a
>> PC, it would seem only logical to adopt the ISA bus as well. I briefly
>> considered the S-100 bus (the "classic" 8-bit expansion bus) and STD bus
>> (another classic) but ruled them out largely on the basis of cost. At
>> one point I seriously considered adopting PC/104 which is electrically
>> similar (identical?) to the ISA bus but eliminates the backplane all
>> together by stacking the cards. What decided it in the end was when I
>> discovered just how inexpensive ISA backplanes are. Advantech sells a
>> 6-slot passive backplane for about $40 US and an 8-slot backplane for
>> about $60 (someone had a 6-slot backplane listed on eBay recently for
>> as little as $12.95).
>
>Yes, you CAN use an 8-bit Micro to take advantage of the ISA
>peripherals, but I'd recommend that you re-consider the use of an 8080
>processor, and suggest one with a Z180 core. The rationale is:
>
> - Z180 MMU handles the 20-bit (1MB) memory addressing
> - Z180 core has simpler mechanisms for handling IO Ports > 255
> - Z180 has more Interrupt pins than the 8080 to simply IRQ
>equivalences
>
>I have a laptop built with a Z180 CP/M machine interfaced to an ISA
>8-bit LCD controller. The system only required a single 16V8 GAL to
Richard Erlacher
an S-100 board with a pair of 8-bit ISA slots on it for a friend who
used one slot for a video board and one for a WD hard disk adapter.
When he moved away, I understood he was working on adding a PC/XT
keyboard to the thing but hadn't yet finished the HDC or video board's
integration into the system.
I personally like the idea of using these readily available parts,
though I think the 8-bit HDC is probably a bit too uncommon. OTOH,
the IDE unit is an excellent choice once one has a functional
interface.
For CP/M use, I think a PC FDC has to be modified somewhat to support
8" FM diskettes, since that's what the "standard" format requires. PC
controllers normally have the MFM*/FM pin on the 765 controller IC
grounded, so they can't do FM. Of course a port pin could fix that,
and since the clocks have to be counted down and steered appropriately
for each combination of modulation and data rate, that should present
little overhead (except a bit of thinking).
I'd be very interested in seeing how you've implemented the IDE in the
software. Could you share these details?
Dick
On Sat, 19 Aug 2000 21:05:09 -0700, "Howard M. Harte"
<hha...@cisco.com> wrote:
>Just wanted to give an update of my progress with CP/M 3 on the Northstar.
>
> It seems to be working pretty well. I got the hard drive (IDE)
>interface going, and I'm using 8-bit transfers instead of 16. This saved me
>a lot of wire wrapping and re-wrapping stuff that I already did. I got the
>idea from Andrew Quinn's TRS-80 Hard Disk interface design. The only
>difference is that I used a PC/AT I/O card. With two serial. parallel, FDC,
>IDE, and game ports. Both floppy drives work well, at 720k each
>(low-density 3-1/2" disks) I "overclocked" the Z80 CPU board to 6MHz (I put
>a 20MHz CMOS Z80 in the socket though!) It actually runs fine at 8MHz too,
>the only problem that I have is that I haven't written a driver for my
>second serial port to work with Kermit, so I need to use the serial port on
>the Horizon motherboard for that. It only seems to work ok to 6MHz. After
>that, I get nothing from the UARTs. Running the Z80 at 6 or 8 MHz, I may be
>able to get 1.44M disks to work too. They use a faster data rate than the
>720K disks.
>
> I put a 1.2GB IDE drive in the machine, but since I'm using only 8-bits
>of the IDE interface, I get only 600M useable with a 256-byte physical
>sector size. The drive has 16 heads, so for now, I'm using each head as a
>separate "drive" of 8MB each, using 8K blocks. I tried having 32M drives,
>but it takes very long to read the directory, so I figured 14 8Mb drives
>will be enough for now. I am not using hashing for the directory, because
>since I haven't gotten the bank switching working yet or written the BIOS
>routines for that, it eats up way too much memory. Without hashing, I have
>a 50K TPA. The hard drive BIOS module added less than 450 bytes, so I'm
>happy with that.
>
> I need to clean up the code and finish the schematics, but I will put
>all the stuff on-line as soon as possible. If anyone is interested in a
>specific portion sooner, just email me.
>
Richard Erlacher
NEC built into their V30 or even their V-50 processor. Has anybody
attempted that? It would appear that such a maneuver would inherently
be a significant speedup over the fastest 8080 or even Z80.
Dick
On Mon, 21 Aug 2000 19:29:41 GMT, Kenneth Casselman
<ken.ca...@home.com> wrote:
>Harold Bower wrote:
>
><snip>
>>
>> Why use the 8080? It was an outmoded part as soon as the Z80 came out.
>>
>
Kenneth Casselman
Cheap is a highly subjective term. Having worked with VME and
CompactPCI systems I was expecting backplanes to cost hundreds of
dollars, so $40 - $60 seemed relatively inexpensive.
Free is cheap.
$12.95 is still relatively cheap.
$40 - $60 is almost affordable.
Hundreds of dollars is "way excessive."
Someone also suggested cutting the backplane out of an old motherboard
(crude but, I assume, effective).
Ken
Don Maslin
: What's interested me for some time is using the "internal" 8080 that
: NEC built into their V30 or even their V-50 processor. Has anybody
: attempted that? It would appear that such a maneuver would inherently
: be a significant speedup over the fastest 8080 or even Z80.
: Dick
I tried it briefly with a V40 in an Ampro Littleboard/PC just to see if
the capability was in the chip. It is. No speed comparisons were done
though.
- don
: On Mon, 21 Aug 2000 19:29:41 GMT, Kenneth Casselman
Clarence Wilkerson
Z80. Using the DOS OS as a big disk buffer can really
speed things up, however.
--
Clarence Wilkerson \ HomePage: http://www.math.purdue.edu/~wilker
Prof. of Math. \ Internet: wil...@NOspam.math.purdue.edu
Dept. of Mathematics \ Messages: (765) 494-1903, FAX 494-0548
Purdue University, \
W. Lafayette, IN 47907-1395 \
nos...@nouce.bellatalntic.net
>Z80. Using the DOS OS as a big disk buffer can really
>speed things up, however.
I've tried it on a turbo XT chasis and a Tandy HX1000 and it's
not faster than z80 and suffers from 8080 code limitations.
FYI the 8080 in the V20 implmentation still takes the usual number of
cycles as a real 8080 and while it's running at up to 8mhz I can do
better running z80 at 8mhz due to tighter coding. Also the V20
still needs some 8088 cod around it to do some stuff.
All in all falls into the neat but not quite bucket.
Allison
nos...@nouce.bellatalntic.net
>
> If you really want to take all the fun out of it, maybe you can just
>pick up an old XT machine, and make a daughter card that plugs into the 8088
>socket, and has an 8080 on it. You just have to add some logic to be able
>to access the entire 0-0x3FF ISA I/O address space. Also, you might want to
Actually an 8085 would interface easier as the 8080 requires +12v and
-5v along with a 8224 for the clock, a latch plus some glue to create
8088 control signals. the 8085 is very close to 8088 MIN CONFIG for
the signals.
Once doen the biggest work would be the bios and dealing with address
mapping.
Then again I'd do most anything to NOT program 8088 and friends at the
assembly level.
Allison
nos...@nouce.bellatalntic.net
wrote:
>I personally like the idea of using these readily available parts,
>though I think the 8-bit HDC is probably a bit too uncommon. OTOH,
>the IDE unit is an excellent choice once one has a functional
>interface.
Well the easy way is to find a WD1002 from an XT class machine and do
what I wrote about in TCJ. You can find them as MFM (1002) or RLL.
I used the MFM version as I could get them at the time used/tested for
5$(US). Very easy to interface.
>For CP/M use, I think a PC FDC has to be modified somewhat to support
>8" FM diskettes, since that's what the "standard" format requires. PC
>controllers normally have the MFM*/FM pin on the 765 controller IC
>grounded, so they can't do FM. Of course a port pin could fix that,
>and since the clocks have to be counted down and steered appropriately
>for each combination of modulation and data rate, that should present
>little overhead (except a bit of thinking).
This would have to be done for 8" as few PC controllers are really
complete implmentations.
Allison
anon...@bogus_address.con
On 2000-08-22 nos...@nouce.bellatalntic.net said:
>Then again I'd do most anything to NOT program 8088 and friends
>at the assembly level.
Awh, it's not so bad, Allison. :)
CP/M-86 has certainly benefitted greatly over the last five years
from i86 assembly language. All of the software advances for that
o.s. -- with the exception of the graphics file viewers -- were
written in 8086 assembly language. And even the graphics viewers,
which were written in C, had significant sections done in ASM.
I'd hate to have to write a real-mode, memory-resident software
driver in C++ ! <g, r & d>
Richard Erlacher
the 10-12 MHz version of the part with its 16-bit interface (v30, V50)
in addition to its built-in hardware. It's essentially a PC
motherboard on a chip, though not completely, but it does have timers,
DMAC's, DRAM refresh unit, interrupt controller, Serial I/O. That
should make for a nice CPU card masquerading as an 8080.
Dick
Richard Erlacher
V-20? or what?
I once () 1986) designed a board with the V-50 and found that by using
its built-in features, some tasks made the entire system MUCH faster.
I found, for example, that using DMA for otherwise-too- slow processes
simplified the code enough that one could do more, hence speeding the
system up. It saved on overhead. Having a channel available for DRAM
refresh was a big factor. Now that we have 1MB SRAM chips it's not so
attractive, but still, why not? The stuff's all built into the same
plant as the 8080. What's more, the I/o handlers can be written in
16-bit code using the V-50 instructions.
There should be a big difference (in theory). There's no question
that the 5 MHz V20 would be slower than a Z80, but a 10 MHz V-50 ought
to be quite a bit faster.
Dick
Kenneth Casselman
>
>
> Actually an 8085 would interface easier as the 8080 requires +12v and
> -5v along with a 8224 for the clock, a latch plus some glue to create
> 8088 control signals. the 8085 is very close to 8088 MIN CONFIG for
> the signals.
>
The similarities between the 8085 and the 8088 may well be where this
whole thing started, and I just kept going backward from there.
The extra voltages are not that much of a problem since they are already
available if you're using a PC power supply.
At the chip level, there are a number of similarities between the 8080
and the 8088 as well:
CPU 8080 8088
clock generator 8224 8284
bus controller 8228 8288
(In some ways the 8088 seemed like a step backward. Not only did it
retain the multiplexed bus of the 8085, it also required a separate
clock generator and bus controller like the 8080).
Add to this an 8251 (or 8250) for the console, an 8253 Timer, an 8255
for Parallel I/O, an 8257 (or 8237) DMA Controller, and an 8259
Interrupt Controller and you've got something that looks a lot like a
PC, not to mention your recommendations for a minimum CP/M system
(apart from the choice of CPU).
I won't try to argue the 8080's technical merits. I just found it
amusing to use the 8080 and all the old Intel peripherals. I'm sure
I could build a "better" machine using a Z80 or one of its derivatives
(the P112 using a '182 looks like a pretty neat machine, and Rabbits
seem to be all the rage) and maybe I will, but first I've got to get
the 8080 out of (or rather into) my system.
Ken
nos...@nouce.bellatalntic.net
<ken.ca...@home.com> wrote:
>(the P112 using a '182 looks like a pretty neat machine, and Rabbits
>seem to be all the rage) and maybe I will, but first I've got to get
>the 8080 out of (or rather into) my system.
>
>Ken
All it took for me is working with it from 1974 to 1976 to make me
look for better. Now when I want to play 8080 I use an 8085 as
it is a better beast in many ways.
Allison
Lee Hart
> To see how easy it is to implement, look at Dave Brooks' P112...
What is a P112? Can you provide, or point me to a description of it?
--
Lee A. Hart Ring the bells that still can ring
814 8th Ave. N. Forget your perfect offering
Sartell, MN 56377 USA There is a crack in everything
leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen
Harold Bower
http://www.iinet.net.au/~daveb
follow the link to the P112 which was a computer with the footprint of a
3.5" drive with a Z182, two serial ports on board (two more with
external CMOS to RS232 converter), three floppies, parallel port, up to
1MB RAM, 32k x 8 flash ROM for BIOS (in-circuit programmable), RTC with
a few bytes of non-volatile battery backed RAM and connectors for
external peripherals. I have one in which I made a 5380 SCSI interface
(circuit on dave's page) and another where I added one of Tilmann Reh's
GIDE interface and is now running with an 82MB 2.5" HD. The entire
board runs from 5VDC.
Hal