Sorry Gary, I see you originally ordered 2, have made correction John From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com] On Behalf Of Gary Kaufman
Sent: Monday, February 9, 2015 1:12 PM
To: n8vem...@googlegroups.com
Subject: [N8VEM-S100:6249] Re: A S100 Bus (8 bit data bus) XVGA Video Display board John -
I'd like two if possible...
- Gary
On Monday, February 9, 2015 at 3:22:53 PM UTC-5, monahanz wrote: OK I have the following list for people that would like an S100 VGA video board:- 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.
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 board.
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 IBM-AT box!
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.
--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout. |