|
Revealing the SpectraVideo SV-318/328
Cartridge Slot: The Hardware
By
Greg Vigneault (Former Spectravideo employee)
For the while that I studied the
SV-318/328, some years ago, I focused on implementing my CP/M-clone; the
keyboard, display, memory mapping, I/O, etc. Until Tomas Karlsson asked
about the cartridge slot, I hadn't given it any attention. Maybe its
association with games made me think that it didn't warrant serious
thought (the slot is labelled "Game Cartridge" in technical documents; I
don't play computer games). But, as I researched an answer to Tom's
question, I was surprised at how the cartridge slot ties into SV
resources; and, I was reminded at how satisfying it can be to delve into
the internals of a fun machine.
This article discusses the SV-318/328 hardware implementation and
control of the cartridge slot; it doesn't cover how the SV detects and
engages cartridge ROM code -- that's a software subject for another
chapter. I assume the reader is familiar with some computer electronics,
the Z80 in particular (e.g. ~MREQ), so I don't explain such common
things as "bus transceivers" and "nand gates." If you're strictly a
software guru there may be things here that don't have meaning for you.
If you're a hardware project maker, these details can allow you to
create accessory items that interface to the SV-3x8 cartridge slot.
I'd like this text to be considered as a work-in-progress, and the
information herein at a "beta" level. This is an exercise in
back-engineering; my SV material is aged and fading (as, perhaps, am
I!), so I could overlook some detail, until I or someone else stumbles
over it -- my previous text about the slot signals has such an error,
which I correct here.
So, without further ado, let's look at the SV-3x8 "Game Cartridge"...
+-----+---------+ +------+---------+
| Pin | Name | | Pin | Name |
+-----+---------+ +------+---------+
| 1 | +5 VDC | | 2 | +5 VDC |
+-----+---------+ +------+---------+
| 3 | A7 | | 4 | A12 |
+-----+---------+ +------+---------+
| 5 | A6 | | 6 | A13 |
+-----+---------+ +------+---------+
| 7 | A5 | | 8 | A8 |
+-----+---------+ +------+---------+
| 9 | A4 | | 10 | A9 |
+-----+---------+ +------+---------+
| 11 | A3 | | 12 | A11 |
+-----+---------+ +------+---------+
| 13 | A10 | | 14 | A2 |
+-----+---------+ +------+---------+
| 15 | A0 | | 16 | A1 |
+-----+---------+ +------+---------+
| 17 | D0 | | 18 | D7 |
+-----+---------+ +------+---------+
| 19 | D1 | | 20 | D6 |
+-----+---------+ +------+---------+
| 21 | D2 | | 22 | D5 |
+-----+---------+ +------+---------+
| 23 | D3 | | 24 | D4 |
+-----+---------+ +------+---------+
| 25 | ~CCS3 | | 26 | ~CCS4 |
+-----+---------+ +------+---------+
| 27 | ~CCS1 | | 28 | ~CCS2 |
+-----+---------+ +------+---------+
| 29 | Gnd | | 30 | Gnd |
+-----+---------+ +------+---------+
The slot has the Z80's eight data
bits (D0..D7) and bottom fourteen address lines (A0..A13), four
cartridge chip-selects (~CCS1..~CCS4) which I refer to collectively as
~CCSx, +5 Volts DC, and Ground.
The ~CCSx signals can be used to select up to 4 separate cartridges,
e.g. in a piggy-back, daisy-chain, or expansion-bus configuration; or,
one cartridge could use any/all ~CCSx signals for its own purposes.
The ~CCSx decode logic has the following signal dependencies ...
~CCS1 ---+
|---------------------+
~CCS2 ---+ |
+-- ~CART, ~MREQ, A15, A14.
~CCS3 ------ ~ROMEN0 --+ |
|-------+
~CCS4 ------ ~ROMEN1 --+
The ~CART, ~ROMEN0, and ~ROMEN1
signals are set to 1 or 0 by your code modifying the bit-mapped "Port B"
of the AY-3-8910 PSG ...
~CART: Bit-0 of PSG Port B (register 15).
~ROMEN0: Bit-6 of PSG Port B (register 15).
~ROMEN1: Bit-7 of PSG Port B (register 15).
A pair of logic ICs
(74LS32,74LS139) ensure that ~CART and ~MREQ are both low (0) to assert
any ~CCSx -- but it's up to your code to make sure that ~CART is
asserted (0) only when you're ready to loose direct access to SV BASIC
ROM and/or RAM (as explained below).
Cartridge pins A0..A13 provide up to 16k of address space for each slot.
Let's regard each of the four ~CCSx as being a select signal for one
16k-bank of slot space. SV address lines A15 and A14 use a decoder IC
(74LS139) to enable one of the four 16k-banks; this maps the four slots
into the SV 64k memory space, segmented as...
~CCS4: SV memory addresses C000H..FFFFH (16k) (A15:1, A14:1)
~CCS3: SV memory addresses 8000H..BFFFH (16k) (A15:1, A14:0)
~CCS2: SV memory addresses 4000H..7FFFH (16k) (A15:0, A14:1)
~CCS1: SV memory addresses 0000H..3FFFH (16k) (A15:0, A14:0)
In order to avoid conflicts
between SV system ROM/RAM and the slot addressing segments, the SV BASIC
ROM and/or RAM is automatically disabled, depending upon which of the
slot enable/select signals are being asserted. The BASIC ROM/RAM is
automatically re-enabled when there are no conflicting slot segments
being accessed.
Even though the slots are just 16k each, they disable all of the 32k
BASIC ROM, and/or all of the 64k+ RAM, as explained below.
The ~CART signal disables the BASIC ROM, at addresses 0..7FFFH,
regardless of which of the four slot-select signals (~CCSx) is to be
asserted. This was done by feeding ~CART into a Nand IC (74LS20) to
enable/disable the address decoder IC (74LS139) that either allows or
inhibits access to BASIC ROM.
Before putting ~CART low, your code should disable Z80 interrupts,
because each interrupt causes the Z80 to call address 0038H (at either
50Hz or 60Hz, depending on which country you live in). So, your slot
code should do its business as quickly as possible, then put ~CART
inactive (1) to re-enable BASIC ROM, and then re-enable Z80 interrupts
so that it may continue with its interrupt-driven "house-keeping"
activities, such as scanning the keyboard (at about 20
times-per-second). Otherwise your code would need to have its own
interrupt service routine (ISR) starting at address 0038H of slot #1
(~CSS1).
The cartridge connector doesn't have Read, Write, or bus-direction
signals, so the selected slot memory/device logic must determine whether
it should read the Z80 data lines, or load the data lines. This can be
done with memory-mapped I/O (~MREQ), with some address ranges being
assigned as Read-Only and some as Write-Only in the 16k slot space.
However, the lack of a Read/Write signal presents a challenge when
enabling ~CCS3 or ~CCS4 (see the Caution, below).
In addition to ~CART, your code must assert ~ROMEN0 (set it to 0) to
enable ~CCS3; ~ROMEN1 must be asserted (0) to enable ~CCS4.
CAUTION: If either ~CCS3 or ~CCS4 is enabled, _all_ banks of SV RAM are
automatically disabled, including RAM at 8000H..0FFFFH, and the "shadow"
RAM at 0..7FFFH. This could be a disaster if not handled properly, as
the Z80 stack must have enough RAM to accommodate the automatic
register-push/pulls caused by interrupts and subroutine calls. This
situation is aggravated by the lack of a slot Read/Write signal, which
would make it simple to have contiguous read/write memory in any single
slot segment.
(RAM is disabled by a SV signal named ~RAMDIS. An asserted ~RAMDIS holds
~CAS high, putting the DRAM chips into tri-state, preventing all Reads
and Writes, while the DRAM remains ~RAS-refreshed.)
NOTE: Enabling _any_ slot-select signal (~CCSx) will automatically
disable all data transfers to/from the main expansion bus -- the 50-pin
edge-connector at the rear of your SV-318/328 that lets you add such
goodies as disk drives, more memory, serial & parallel I/O, etc. Address
and control signals get buffered out onto the bus, but data bits travel
in and out via a bus-transceiver IC (74LS245). The transceiver is
governed by a Nand IC (74LS30) that all ~CCSx signals feed into -- so if
any of them become active the transceiver closes the data path (by going
into high-Z tri-state mode).
Any cartridge that seems to happily co-exist with your expansion
accessories is very busy jumping into and out of slot segments!
I welcome your feedback and ideas.
Regards,
Greg Vigneault (Former Spectravideo employee)
Source: Tomas Karlsson
|
