Date: Mon, 9 Feb 2015 12:22:53 -0800
From: mon...@vitasoft.org <mailto:mon...@vitasoft.org>
To: n8vem...@googlegroups.com <mailto:n8vem...@googlegroups.com>
Subject: [N8VEM-S100:6247] Re: A S100 Bus (8 bit data bus) XVGA Video
OK I have the following list for people that would like an S100 VGA
Andrew L., 1
Paul B., 1
Peter Cole, 1
So I will order 20 boards (2 extra). Will take 3-4 weeks.
Do NOT send any PP payments until you receive the boards.
Peter could you send me your shipping address.
On Wednesday, February 4, 2015 at 11:45:09 PM UTC-8, monahanz wrote:
Well here it is after no less than 10 prototypes I'm delighted to
introduce the first XVGA video board that sits in the S100 bus.
Scroll half way down the page.
There is one major limitation with this S100 bus XVGA board, It
will only work with our _8088 CPU board_. With that board as best
I can tell it is rock solid running MSDOS with an S100 bus clock
speed (PHI) of 8 MHz (i.e. a 24 MHz Oscillator on the board). It
will _NOT_ work with our current 16 bit CPU's ( the _8086_,
_80286_ or _80386_). The reason for this is due to the fact that
these VGA chips (at least for the Cirrus & Trident chips),
require the CPU to be able to send 16 bit data as two back to back
8 bit bytes. The chips actually have dedicated lines (MCS16* &
IOCS16*) to flag the CPU to let it know it is capable of a 16 bit
transfer. However I found out the hard way, that these chips do
not always exercise this option -- particular during
initialization. On our ISA converter board I played around with
the circuit to sequentially send two 8 bit bytes using Sergey's
ISA Super VGA board
could not find a reliable solution. The best effects were
sensitive to the bus CPU speed and failed altogether at high MHz
The fundamental problem was that these VGA chips can and do pull
wait states on the bus at impossible to determine times
(particularly during screen scrolls). The length of the wait
states is highly variable. I concluded the only way to solve
this is to redo the S100 CPU boards themselves so that if the 16
bit CPU board does not get a SIXTN* acknowledge from a sXTRQ* it
proceeds to send two back to back 8 bit bytes. This was actually
part of the IEEE-696 specification. However most manufactures at
the time (an also in our cases), ignored this and simply supplied
16 bit capable RAM and/or IO boards. The only documented circuit
I could find was the (excellent) one described for the TecMar 8086
The good news is that the 80486 CPU has the ability to /on the
fly /send 8, 16 or 32 bit data depending on the chips on the
receiving end. The other good news is that this XVGA board can
send and receive 16 bit data. The chips themselves have 16 bit
data pins so such a board should work at full speed with such a
CPU. Most of the time transfers will be 16 bits but
initialization and ROM access will be 8 bits -- just as in the
I must point out however that currently this is all theoretical. I
am in the process of building a knockout 80486 CPU board that
should in theory be capable of working with any S100 board (old or
new). If this does not come about then I would fall back to
modifying some of our earliest CPU boards. - That's the plan.
Anyway wanted to let the group know of the board. I will be doing
a usual group order of bare boards in the next week or so. If
interested please let me know.