Purpose of this text:

To have some kind of summary on the EP system, to be able to see the "big picture"
without all of the details. So it's relatively short. I hope ... After understanding
the basic concepts of EP you should read all much detailed (and maybe much more correct ...)
information on the given topic somewhere else ...

SO THEN:

Enterprise-128 ("EP-128" or just "EP") has the nice feature that it has got
22 bits wide address bus on the motherboard itself. So while on other computers
sometimes it's quite hard and non-standard to add more RAM to the system,
on EP, it's quite easy. EP - with 22 bit wide address bus - can use 4Mbyte
of address space (ROM+RAM). However Z80 can only "see" 64Kbyte of memory. The solution is
the following:

The 4Mbyte address space is divided into 256 16K wide areas, "segments". The
CPU's 64Kbyte address space is also divided into 16K wide areas, thus 
4 of 16K wide "pages". The trick here, that any of the 256 segments can be
"mapped" to any of the 4 CPU pages. A segment can contain RAM, ROM, or can
be "undecoded" (empty, no memory there). This mapping can be done on ports
(belongs to the Dave chip) 0xB0 ... 0xB3 for the 4 CPU pages. So for example
writing value "6" to port 0xB1 will cause that CPU addresses between
0x4000-0x7FFF will see the segment #6, which is the 16K*6=0x18000 starting
address on the EP bus system. It's another question if there is any memory
there or not.

About I/O ports: EP uses only the low 8 bit of I/O address decoded, unlike
eg Spectrum. The high byte of I/O address is not important. So you can freely
uses OUT (n), A without worrying the high byte of address, or INI, etc.

The lower two segments (0, 1) are ROM, and contains the EXOS operating system
(or even 2, 3 with Zozo's version of EXOS also including BASIC etc). Segments
4-7 are mapped to the cartridge port where usually you can find the IS-BASIC
ROM cartridge, but there can be other stuff there, other software ROM, or even
totally different equipment, like the "famous" SD card cartridge for the EP.

A quick chapter about the software:

Other ROMs can be in the system, they are scanned EXOS on "boot" time, just
as the scanning for the available (and working ...) RAM segments. So there
can be tons of RAMs and ROMs in a well expanded EP system. Moreover, ROMs
has the ability to chain themselves into the OS, you can define new
"EXOS commands" and even devices so if you build like an ethernet hardware
(EPNET will come from Bruce!) there is no need to modify the "base" OS,
just to add an EXOS device driver for eg using FTP, and from that even
in the "stock" BASIC you can load your programs directly from FTP from the
Internet ... EXDOS is also and EXOS "extension" and provides disk access
software layer but also the name of the EXDOS card. EXDOS software is
also utilized eg with the SD card cartridge, since EXDOS is also modular,
and only low level block I/O must be provided for a new media. IS-DOS
is a CP/M (and it's said also MSX DOS, I don't know) compatible system.
IS-BASIC is the standard BASIC interpreter for EP, usually used as a
cartridge in the cartridge port (unless you use Zozo's EXOS which also
contains IS-BASIC, so the cartridge port can be "freed" then). EXDOS uses
DOS compatible FAT12 filesystem, and most EXDOS commands are similar to
DOS ones. The famous SymbOS (somewhat Windows like, true, multi tasking
window oriented OS which also runs on MSX and CPC) has port for the
Enterprise.

The last four segments at the top of the 4Mbyte address space (segments
0xFC, 0xFD, 0xFE, 0xFF) are special, this 64K area (in case of an
unexpanded Enterprise 64 this is also the only RAM area) is the video RAM
also named as "VRAM" for being short. VRAM is the area which can be used
by the Nick (the video chip). Nick cannot access other parts of the memory map!
VRAM can be used as regular RAM by the CPU (just like other RAM segments)
however, since it's _shared_ with Nick, the access is _slower_ compared to
other (non-VRAM, thus segment numbers below 0xFC) RAM areas. This sharing
work is controlled by the Nick chip also by "deforming" the clock signal of
the Z80 CPU not to conflict with Nick's own accesses.

Also, a very important rule, that the segment/page mapping is meant for the
CPU only! Nick _always_ sees the 64K VRAM directly in a linear way, even
if none of the VRAM segments are mapped by the CPU! It's totally legal to
create some screen content and not even "page in" VRAM for the CPU, Nick will
continue to use the VRAM of course! That is, Nick VRAM address 0 is always
at the start of 0xFC segment, regardless, segment is mapped to 0x4000-0x7FFF
by the CPU for example, or not mapped at all. Thus, you must be careful if
you define addresses for the Nick, since then you must use linear VRAM
relative addresses.

Enterprise-128 (or even expanded Enterprise-64) has other, non-VRAM RAM area
as well. EP128 contains another 64K (or more, if expanded) RAM which is not
VRAM of course. Please note that you CANNOT assume where the memory is
exactly (in what segments!) as every memory expanders have their own idea
where it puts its RAM segments within the 4Mbyte memory area (of course the
VRAM is fixed). Thus, you should not assume RAM segment numbers (other than
VRAM) but you should ask for EXOS (the operating system) to allocate a
segment since it knows where RAM is (it tests memory at boot time and books
RAM segments on demand).

Even VRAM is fixed by location, you should not just wildy use it, since
EXOS structures are there. The so called "system segment" is usually in
segment 0xFF. If you need VRAM, unfortunately the only way is to allocate
RAM segments in a loop and waiting for a segment number equal or greater
than 0xFC. This is because EXOS does not have a function to allocate VRAM,
only for allocating any RAM segment, and it starts to allocate them from the
lowest RAM segment number (well, the lowest one is called page zero, which is
always allocated for the actual application). Of course you should also free
the allocated segments once :) You can (and will) see that EP has quite
"complex" (but elegant) internals even in hardware but also the software
(EXOS, EXDOS ...).

Dealing with the display ... Again, here EP is quite unique. Most of the other
8 bit systems has some kind of "video mode", I mean global video mode, so you
can say, the screen in graphical mode, or text mode, and so on. There is no
such a thing on the EP! In fact, Nick has only _four_ I/O registers which sounds
odd at first. The key here, that Nick does not use "global" settings (only
a few) but it reads from the VRAM in each scanline! So you can have a display
using _different_ video/colour modes for _each_ scanlines of the screen if
you need this! And not in the way like on Commodore 64 (that you use a raster
IRQ and modify the settings in the IRQ handler), but Nick handles this without
using not even a single cycle from the CPU!

While "building the screen" Nick - in each scanlines - reads a "table" from
VRAM called as the LPT (Line Parameter Table). LPT is a continuous area in
VRAM, it's starting address is defined by Nick I/O ports, but almost every
other information needed for the video display is defined by the LPT then.

LPT itself contains 16 byte long "chunks" called as the LPBs (Line Parameter
Blocks) which describes one (or more - since an LPB also contains the
information how much scanlines it's valid for, of course it can be only 1,
but also more) scanline. An LPB contains information about video mode
(ie, text, attribute graphics, pixel graphics) and colour mode (2, 4, 16
and 256 colours) left/right margins (outside parts of the screen are treated
as the border) and VRAM locations for the pixel/other (like font definition
area in case of text mode) information. It also contains palette (the first
8 colours only, however it is only important in 16 colour mode, and 256 colour
mode does not use LPB palette). An LPB also carries other information, like
request for "raster interrupt" on a give scanline. The last LPB should have
the "RELOAD" bit set, thus Nick will re-start to parse the LPT again from the
first LPB.

It's important, that also the user (in the LPT) who _must_ produce the right
vertical sync (VSYNC) sequence, without this, there will be no stable picture
on a TV ... This sounds odd, an complex, but it also gives you a great 
possibility to define your own scheme, even like interlaced video modes and so.
Without using any CPU, still! Also, you can even create animation (not so
practical, but possible) created only by the Nick, in a way that an LPT
contains enough LPBs for one frame, than without the RELOAD bit, the VSYNC
is issued, than another _different_ frame is described, etc etc, and only
after some frames you utilize the RELOAD bit. Other tricks can be imagined
as well, like re-using the screen content later, ie using the same pixel
data pointers in different LPBs, so CPU can modify a single area, and can be
seen multiple times in different scanlines as well.

Almost the only thing you set globally with Nick, is the start VRAM address
of the LPT. The other typically used global thing however is the border
colour, and the so called FIXBIAS. FIXBIAS is a bit unfortunate, and it's
because in 16 colour modes, the LPB has only place for 8 palette colours,
the first 8 colours. The FIXBIAS helps to define the second 8 colours, but
because of the lack of enough space in LPBs, this _is_ global (of course
you can modify FIXBIAS by the CPU still, if you need ...).

256 colour mode does not use palette at all, since a byte then directly
defines one of the 256 colours of the EP. 

Note, that "40 column text" mode is "hardware text mode", while "80 coloumn"
text mode is NOT, col80 is simply a pixel screen. This is because the
limtation how much data Nick can fetch within a scanline. A time needed for
a scanline (if I remember correctly it's 64 usec or something like that in
PAL signal) is divided into 57 time slots, called simply "slot". In each
slots, Nick has time to read two bytes. The first 8 slots (of a scanline)
is used to read the current LPB (thus, 8*2=16 bytes). The last 3 slots is
used ot generate horizontal retrace (which is - unlike the vertical one - is
managed by the Nick chip as its own) and to provide DRAM refresh.

In theory, you can see, that 57-8-3=46 slots can be used to display something.
If you think about the text mode, it means 46 columns (since each character
needs a slot, 2 bytes to read: the character code, and the font definition
chargen). In practice however, it's often said, that because of the "overscan"
nature of TVs you may not able to see (out of visible screen area) 46 coloumns, but
42 is safe choice (I guess on modern TVs it can be more though). So the
"text 40" can be misleading it's not exactly 40 columns, it can be more
(though not more than 46, and in practice maybe only 42) or even less (using
broader left/right margin settings in the LPB). 

But it's clear that 80 column video mode is not a real text mode, since even the
overscan-max is 46.

For other modes, you can see, that eg a 2 colour (one bit per pixel) graphical
mode you have 8 pixels in a byte, and Nick allows two bytes to be read within
a slot, so the theoretical maximal horizontal resolution is 46*8*2 = 736
pixels. Again, because of the overscan, it's often said, that 42 slots should
be enough, which is then 42*8*2 = 672 pixels. Of course in 4 colour modes
(where you need two bits for a pixel) the resolution is the half of the above.
In case of 16 colour and 256 colour, you should half the value again and again.

LPIXEL mode is similar to pixel, however the horizontal resolution is halved.

ATTRIBUTE mode is somewhat similar to Spectrum's video mode, ie there is
the "pixel" area and the "attribute". Attributes can tell the colour of
pixels and the background, but unlike Spectrum 8*8 attribute block, on EP
it's only 8*1, though with the right LPBs you can simulate any other attribute
block height, even 8*8. This would be almost Spectrum compatible, however
the layout of attribute data is different (ink/paper, and no flashing) and
you are free to put pixel/attribute data in the VRAM to any position.

In text mode (the real text, text "40") Nick in each LPBs has the memory
"pointer" for font data and character codes area to display. Unfortunately
Nick can't handle colourful text then. However, there are different text modes:
what I said is true for Ch256 modes, which means 256 different characters can
be dislayed, with 8 bits. In Ch128 mode, only 128 characters can be used, but
the "free" bit then can be used to select different colour (of course, the nature
of LPT allows to have different colours in each lines, that's another question!).
And there is the Ch64 mode, with two bits left. EXOS uses Ch128 mode. Nick allows
any height of character, it's not fixed, it's defined by the LPB. This is also
the reason that origanization of the font definition is not what is usual with
other computers: eg in Ch128 modes, the font definition area contains 128 bytes
for the first scanline of each character, then 128 bytes for the second scanline
of each character and so on. In this way the height of the font can be increased
without breaking the organization of the font data.

Note, that most "official" documentation on Nick mainly speaks about the
"sane" combination of video/colour modes. However in theory you can mix them,
eg you can have even multicolour characters (with lowered resolution then). It's not
a rare trick to use "text" mode for games with colour mode other than "normal" 2.

Of course, especially if you don't need direct screen memory manipulation,
you can use EXOS to open a display, etc. However it's naturally won't be
fast enough eg a game or demo too much usually.

The vertical resolution is basically limited by the video signal standard
itself as you need to provide the right LPBs for VSYNCs. I have not so much
idea here, but it's said, that about 288 lines are still OK, though it's also
common to use not more than 256 or nearby. Maybe again the overscan, just now
"vertically".

Unfortunately, though Nick is quite flexible, it does not have "sprites".
Nick has an interesting ability to accept "colours" (4 bits of data) on
the expansion port, so in theory there can be external circuity to produce
image which can be mixed then with the Nick generated image in multiple ways.
Though not so much known hardware use this feature.

The other important custom chip besides Nick is Dave. The segment/page
"mapping" ports (0xB0 ... 0xB3) are also handled by the Dave. Unlike the Nick
(which has got quite specific single goal: dealing with video), the purpose
of Dave is somewhat mixed. It produces sound, provides controlling signals for some
I/O buffers (which is used for example the keyboard scanning), does the
memory mapping for the CPU I mentioned above, and also it works as some kind
of "interrupt controller" as well.

Dave has two external and two internal interrupt inputs producing a single
signal for the Z80 INT pin NMI is not used in EP though ZX Spectrum harware emulator
card uses NMI for example). EP works in IM1 Z80 interrupt mode. Dave has enable
bit for the four interrupt sources, and also a latch for each. If any (even more)
of the interrupt source inputs are active and and that source is enabled the
corresponding latch is set. If any of latches is set, the Z80 has active INT
level. This, it's important to clear the latch in your interrupt handler, as
it will provide INT forever if you don't do that! The important external interrupt
source for Dave is Nick, the raster interrupt. The other is not so much used,
as far as I remember, maybe serial port use it. The two internal sources
are the fixed, 1Hz interrupt source, and one which is switchable between
multiple sources: 50Hz, 1KHz, and frequency of the 0th or 1st oscillator
(which is also used to produce sound, so it's quite common to set volume zero
for the interrupt source channel, as it would also produce sound otherwise).

Audio capabilities of Dave means a custom solution, it's not the usual AY
chip can be found in many other computers. Though there are software emulations
to more or less play an AY music. Dave is stereo, every channels have 6 bit
left/right volume control. It can be even switched in D/A mode, so you can
use simple (though not so precise, because the simple resistor-ladder used
as rudimentary D/A inside the EP at the digital outputs of Dave) "digi player".
Noise channel can produce - guess what - noise. "Tone" channels produces
square wave, however some tricks can be used, like ring modulation and
filters. Please note that these things are not analog notions, and they are
simple bit operations on the signal. Distortion can be introduced with some
kind of called "polynomial counters". Though I am not the best persion to
talk about Dave's audio capabilities, I am afraid ...

Be careful with direct hardware programming! First, the memory layout is not
fixed. It's always better to ask EXOS for segments. Second, some of the
ports (like FIXBIAS or even audio stuffs) are used by EXOS as you can ask
sound, border colour etc via EXOS. They're may be set in the during the
normal interrupt handler regularly. So if you try to do it with direct
I/O port instructions, and normal EXOS interrupt works, it won't have too
much effect maybe ...