[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A S100 Bus (8 bit data bus) XVGA Video Display board
I think you might mean Andrew B. instead of Andrew L? Unless Andrew Lynch asked for one as well
On Monday, February 9, 2015 at 12:22:53 PM UTC-8, monahanz wrote:
OK I have the following list for people that would like an S100 VGA video board:-
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. See here:-
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. I could not find a
reliable solution. The best effects were sensitive to the bus CPU speed
and failed altogether at high MHz speeds.
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.
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 board.
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 IBM-AT box!
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.