Hi, John,

I am interested in 1 as well if it's not too late.

Regards,

Brian

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:-
>
> 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.

Reply via email to