OK I have the following list for people that would like an S100 VGA video board:-
Fabio,3 David ,2 Todd,1 Matt,1 Andrew L., 1 Neil,1 Peter,1 Elsid, 1 Paul B., 1 Gary, 1 Peter Cole, 1 John M.,4 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. John 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:- > http://s100computers.com/My%20System%20Pages/VGA%20Board/VGA%20Board.htm > 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* > <http://www.malinov.com/Home/sergeys-projects/isa-supervga>. 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* > <http://s100computers.com/Hardware%20Folder/TecMar/8086%20Board/8086%20Board.htm>. > > > > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
