On Apr 5, 7:08Β pm, "James Moxham (Dr_Acula)"
Post by James Moxham (Dr_Acula)This is a fascinating topic.
I have built a number of N8VEM boards and rewritten quite large parts
of the operating system, eg to include a keyboard driver that works at
the bit banging level.
The problem I came up against is that the more you put into CP/M, the
more memory you take at the top of ram. CP/M allows you to do this but
it starts taking memory away from other programs. Wordstar has less
working memory. Basic programs have less working memory. So you reach
a point where anything more than 16k is too much.
Exactly so, I especially liked cp/m+ RSX's to add features to the bdos
calls, but each one that was added reduced the top of TPA by its size,
like you say.
Post by James Moxham (Dr_Acula)What I did next is to take the knowledge of CP/M on the N8VEM board
and combine it with the emulations being done at the time by the
Propeller group. The Propeller can run CP/M and it can also run banked
versions of CP/M like MP/M. But the main feature of the propeller is
that it gets around the CP/M memory problem by offloading code into
propeller assembly.
So instead of writing a keyboard driver in Z80 (which you can do on
the propeller), you write it in propeller assembly, and then Z80 talks
to this with OUT and IN instructions to various ports. There are 256
ports available, and some of the port numbers in the propeller
emulation are the same as in the N8VEM. This enables programs like
XMODEM to be ported from the N8VEM to the propeller without any
changes to the code.
The big advantage to this turns out to be the disk drive code. The
original N8VEM used a ROM disk which didn't need much code space.
However, the hard drive code used a lot more space. Code to use an SD
card uses more code space again to do the SPI bit banging.
To me, it makes sense to keep the CP/M code to the more abstract level
of 'open a file', 'write n bytes to record x' 'close file', and to
offload the more bios type code to somewhere else.
On the propeller that code can be in propeller assembly, but where
would you put such code on a Z80 board?
I have been pondering this and maybe this isn't the best answer, but
what I am thinking is a banking system where the user has software
control and has control at a fine level, eg in 2k blocks. If you have
the ability to switch banks in and out of high memory and you can do
this in 2k blocks, then you don't need to be jumping around with bios
calls in low memory (which in themselves need custom code).
If you have a CP/M system that has an absolute maximum size of 10k,
and you count down from the top of memory then it occupies 64k to 54k.
Then have some banks that you can switch in and out from 52k to 54k.
Those banks can come from anywhere. They could come from ROM or EPROM
or from a SRAM chip.
The idea would be that you send an OUT instruction to a particular
address and that switches in a bank. Then run that code (it might be
the low level SPI driver for an SD card). Then return to CP/M and
maybe switch in a bank to talk to the keyboard.
I think this means that the CP/M part can be largely unchanged, and
all the new code (ie for things that did not exist when CP/M was
written, like PC keyboards and SD cards) - these drivers can be
written as separate modules. In fact, this code does already exist,
and would just have to be recoded so it would work in a 2k (or 4k)
block of code.
This could be USERF code in an alternate code bank..it would be great
if RSX's could reside in an alternate bank and accessed by a new
banked strategy.
Post by James Moxham (Dr_Acula)I'd be hoping that this would mean you could run CP/M 2, MP/M and a
new operating system on the same hardware.
Thinking about hardware, what I think this means is you don't want a
system that, say, switches the entire 16k of top ram in and out as a
bank. You need smaller blocks and the ability to switch both the size
of the block and the location of the block and control over where that
block came from.
I already have something very similar to this working on the propeller
with MP/M. It would be cool though to port it to a real Z80,
especially as the propeller emulation only runs at a Z80 speed of
about 2Mhz and I have some 10Mhz Z80 chips I'd like to use.
Thoughts would be most appreciated!
The Amstrad PCW8256 was probably the last and greatest of the Z80
production machines, with its 256k as standard, but since it was sold
as a word processing machine, a minority knew of its CP/M Plus
underpining, or cared back then as the ibm xt was the rage.
The pcw was socketed to accept another 256k. However, because the
buss was exposed on the back to accept a socketed buss peripheral,
after market peripherals were a mini-business, and one could obtain an
addon for another 512k plus a hard drive controller. The official
addon provided a serial port plus a parallel port, to support an
external printer and a modem, for example.
The memory map was organized in three banks, It used a block size of
16k (you are right, that is abit coarse, your suggestion of 2 or 4 k
would be ideal) the top 16k of the three banks was the same 'common'
block, variables and code in it was persistent across bank switches
that way. Bank0 was in context at reset, Bank1 was the 'normal' TPA
bank, like cp/m-80. Bank2 had the video mapped addresses/data (2
Blocks). I forget the exact mechanism for the mapping but it involved
writing a value to a port like F0h, I think something like writing a
logical block number to an ordinal port number - F0..FFh performed the
mapping.
So of the 256k, 144k (9) blks for the system as..
Bank0 :: Blk0, Blk1, Blk2, Blk3 - boot bank, USERF, loader, ccp
'banked' code
Bank1 :: Blk4, Blk5, Blk6, Blk3 - appeared as typical cp/m-80
Bank2 :: Blk0, Blk7, Blk8, Blk3 - boot bank USERF, memory mapped
blocks to video.
The 112k remainder was for the ram drive, and could be used that way, /
or/, could be accessed through the 'block select' USERF function
extentions and mapped into a bank at a given block position. Mostly
used by game programs for video 'tricks'.
Populating the next 256k memory sockets was the best bang for the
buck/
This, and alot of other stuff, was managed thru a FPGA that held the
logic for bank select and block mapping, and contained video
controller logic for something akin to a hercules video adapter. It
supported 90 character lines by 32 rows, and block graphic characters
as well as pixel graphics. Pretty effective for its custom
wordprocessing software to run on. And it managed an extended the
address bus (iirc it added 2 for a 18 address lines, or maybe 3.)
IIRC, the clock for the FPGA was at 32mhz, although the z80 ran at
something less than 4mhz.
So something like what you described, some open hardware design with a
'free cpm+' to go with it, that would be something to think about.
Even such, as a 'official' paper design, would be useful. Remember
that the 'official' CP/M was designed on and for the intel development
system and that was the cp/m 'standard' to compare against.
-= my 2 cents worth =-
Steve