Thanks Tom! That’s it!
I checked on the V9938 datasheet and it appears the *RESET signal is plain bi-level TTL so I don’t think we’ll need the NPN and pull up.
Do you have any other changes and/or corrections for the S-100 VDP V2 prototype board? Leon did get an earlier version of the S-100 VDP working.
Thanks and have a nice day!
From: Tom LeMense [mailto:tlem...@ameritech.net]
Sent: Friday, August 24, 2012 1:13 PM
To: Andrew Lynch
Cc: n8vem...@googlegroups.com; danwerner21
Subject: Re: [N8VEM-S100:1047] Re: S100 VDP success
The reason behind having CPU control over the VDP and the AY-3-8910 was to be able to quickly get everything back to a known state. In particular it's convenient to be able to 'shut up' the sound card if it's chattering away... By using a 74LS174 with an asynchronous RESET input, when the CPU resets, the AY-3 and the VDP will reset, also. The CPU has to write to the '174 in order to bring the AY-3 and the VDP out of reset.
Perhaps a bit less obvious - the TMS9918/9118 RESET line is a ternary-logic input. logic LOW for device RESET, TTL HIGH is "normal", and "higher-than-HIGH" (>9V?) allows you to re-sync the VDP video frame. So, on the ECB SCG card, you'll see an NPN and passive pullup for the VDP RESET/SYNC line. This allows the "higher-than-HIGH" voltage to be applied to the RESET/SYNC line without damage to the TTL reset-generating components.
On 8/20/2012 9:48 PM, Andrew Lynch wrote:
Hi! Thanks Leon! I think the reset latch interlock is a feature not a bug! The S-100 VDP design traces from the ECB Sound and Color Graphics board (TMS9918 and AY-3-8910) and a bit from the N8 (joysticks). In fact our own Tom LeMense and Dan Werner helped with the original design.
The reset logic is intentional and part of the initialization routine is to set the latch pins so the bus reset lines are enabled. I forget the exact reasoning but as I recall we wanted the CPU to have control over when the TMS9918 and/or AY-3-8910 could be reset. If the CPU did not initialize the latch then both chips were disabled and output suppressed for sound or video.
Maybe Tom and/or Dan can shed some light on the original SCG design. I have no problem removing the reset latch interlock but I’d like to know why it was added in the first place. I just remember all the details anymore!
Thanks and have a nice day!
The problem with the VDP reset circuit is that the BRD-RESET* power on pulse has to go through the U27C AND gate. The other input, SYNTMS* of the AND gate will be at logic level 0 having just been reset by BRD-REST* on p1 of U20. Thus the output of U27 cannot go to logic 1 (which it needs to do to reset the VDP) until you output a 1 on SYNTMS* via the lactch (U20).
On Monday, August 13, 2012 5:08:30 AM UTC+10, lynchaj wrote:
Hi Leon! Thanks! I believe the V9938 will have to be configured to output its color information on the Cx port. I don’t think it will do it by default but I think it is designed to work with a RAMDAC.
The BRD-RESET* circuit should also be able to reset the V9938. What is your setting on K1? It allows either RESET* or SLAVE_CLR* to reset the VDP depending on which is pulled low. Please check your S-100 bus to make sure RESET* and SLAVE_CLR* are pulled high and also what K1 is set to. Then try pressing the reset button and see if BRD-RESET* goes low.
What CPU board are you using and how is it configured to export its reset function (RESET* or SLAVE_CLR*)?
The SYNTMS* signal was intended on the ECB SCG board to reset the TMS9918 at will independent of the system reset. It is useful to keep in case the V9938 goes insane and the CPU wants to regain control of it. It and the system reset function should both work so if it is not there is something funky going on.
Thanks and have a nice day!
I didn't get the RAMDAC to respond. I'll have to recheck the test program to make sure I was doing everything right.
I got the LM1881 circuit going ok but used the CSYNC output on p5 to drive it rather than COMP_VIDEO on p21. I guess it would work on either. I'll try swapping it to p21 to test.
The VDP reset circuit may need redoing as the Power On reset via BRD-RESET on U27C p9 will never reach the VDP. But you can still reset it through the Latch.
On Saturday, August 11, 2012 1:55:36 AM UTC+10, lynchaj wrote:
Hi Leon! I was wondering if you ever got the RAMDAC to respond during build and test? By itself the RAMDAC would not be sufficient for VGA display but with some additional circuitry in the prototyping area I think it may be possible with the V1 prototype.
The key would be to configure the V9938 to output color information on its Cx port. Then the RAMDAC could decode that information and produce “almost” VGA compatible signals. It would still need the final stage circuitry and the HD15 connectors. One signal that is absolutely missing though is VSYNC* and on the V2 prototype it will be (hopefully) derived from the composite video signal using the LM1881 circuit.
Even just establishing the V9938 can output color information on the Cx port would be big progress though. I am confident the RAMDAC will work since it does so beautifully on the ECB uPD7220 circuit. Once programmed, the RAMDAC gives a *lot* of flexibility over the display palette and is really a neat device.
Also, the V9938 could be tweaked to produce sort of VGA signals using a set of 390 ohm resistors on R, G, and B. Also the HSYNC* comes directly from the V9938 but VSYNC* would again have to be derived using the LM1881 or other means.
I appreciate your help on this neat board! Thanks and have a nice day!
Sure, I can check things look OK on the new board design.
I don't think I ever got the VGA output going.
Did anyone else have any success with this board?
On Thursday, August 9, 2012 10:42:23 PM UTC+10, lynchaj wrote:
Hi Leon and Pontus! Thanks!
Remember the S-100 VDP project? I’ve finally found some time to update the circuit to include the AY-3-8910 sound generator, VGA monitor interface, and do some other clean ups. Would you please check out the schematic and PCB layout and compare against your notes from the last prototype build and test?
I would like to do another round of the S-100 VDP prototype boards and would like to make sure all the lessons we learned from the first prototype are fixed.
Thanks and have a nice day!
The additional caps across the V9938 power pins are an attempt to make the video less noisy. They didn’t seem to have much effect. I suspect the noise I’m seeing on the video signal on the CRO may be due to the routing of the power lines for the video amp through the dynamic RAM circuit. (lots of hash from the refresh?) Maybe the video output could be routed away from the RAM and separate traces for the video amp power from the regulator provided.
The extra pull up on DHCLK p3 of the V9938 (and cut trace to R53) is there because I was worried that the 5.37MHz output would be doing something to the LightPen inputs LPS and LPD.
The 470 ohm pull downs on R, G and B outputs (p22, p23 and p24) on the V9938 are there because I suspected I may have damaged the COMP_VIDEO output (p21) and needed the pull downs to get the internal transistors to drive – the output was OK as it turned out.
The reset circuit needs some changes. The V9938 is not receiving a “power on” reset because BRD-RESET* is being gated by SYNTMS* at U27C. (SYNTMS* is reset at turn on by BRD-RESET*). The V9938 has to the manually reset by toggling SYNTMS*.
I have tried the FMS6141 video amp configuration and it works fine.
Parts of the board working/not working:
1. Address decoding – working but could do with changes to make more MSX compatible – as you’ve said.
2. Reset circuit – only working manually – see comment above.
3. Composite video output – working but noisy – power routing?
4. Video RAM – working – I tried adding in 100 ohm resistor in the RAS,CAS and R/W* lines (like some MSX2 designs I’d seen) to reduce ringing. It didn’t reduce the video noise but it may be a good idea anyway.
5. BT478 – I haven’t tried yet but maybe we can route the RED, GRE and BLU outputs to a header for a DBS15 connector to drive a 15kHz VGA monitor.
On Sunday, 1 April 2012 00:00:57 UTC+11, lynchaj wrote:
Hi Leon! Thanks! I am updating the S-100 VDP design and would like
I see the data lines on the V9938 are reversed. That's a carry over
from the N8VEM SCG board. Apparently the TMS9918 *did* flip the data
lines and I carried that over but it wasn't necessary.
So far, I've fixed the V9938 data bus but I see from your photos there
were several other changes. Additional capacitors and what appear to
be pull up resistors on the V9938. Also the data lines going into the
BT478 and also picking off signals from the U7 data bus latches. I
presume those are data lines?
Have you had any luck accessing the BT478? John Coffman was able to
get it to work on the uDP7720 board. I think the first step is to see
if its registers are responding. In theory at least the BT478 RAMDAC
would allow the VDP to produce VGA like signals. They would still be
the lower NTSC like dot clock but should still work on modern LCD
My plan is to add in the AY-3-8910 sound generator and the joystick
interface from the N8 board.
Also to rearrange the IO decoding so the V9938 can appear at x8H
Are there any other changes we need on this board?
Would it be possible to list out what parts of the board work and
It seems the the V9938 is working so that implies the VRAM subsystem
is working. Also the IO decode is at least partially working.
Thanks and have a nice day!
On Mar 19, 7:57 pm, Elsid <le...@swiftdsl.com.au> wrote:
> I’ve finally had some success getting video out of the prototype S100-
> VDP board.
> The first thing I found was the data bus on the V9938 swapped around.
> That is, D7 was wired to CD0 not CD7, D6 was wired to CD1 not CD6 etc
> down to D0. I think this may have been an early error on one of the
> prototype N8VEM VDU boards also.
> I correct the Data bus swap around but still no video output on p21
> COMP_VIDEO or P22,23or 24 (RGB). I should say there was actually a
> composite video signal complete with color burst and synchs but there
> was no video component on the top half of the waveform. I tried
> another V9938 – same result. I pulled out the BT478 to just try and
> get the V9938 part going on its own. Still no luck.
> Finally last night Wayne posted that he’d found some problems were
> caused on the N8VEM Color VDU board when the VT82C42 is not reset. I
> looked at the VDP reset circuit and found that the V9938 is not
> receiving a reset because BRD-RESET* is being gated by SYNTMS* at
> U27C. SYNTMS* is reset at turn on by BRD-RESET*. – Thanks for the
> inspiration Wayne.
> I’m not sure what the function of SYNTMS* is. If it’s to enable a
> programmable reset for the V9938 we may be better off inverting it and
> eliminating the inverter U11F after U27C. This should give us a reset
> from either SYNTMS or BRD-RESET.
> I was using a modified version of HW9918.COM to test the VDP board so
> I added a couple of lines to toggle the SYNTMS* signal to reset the
> V9938 in the initialization section and Bingo – “Hello World” popped
> up on the screen.
> I’ve put some photos and the test program on the N8VEM site at:http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder¶m=VDP
> for anyone who is interested.
> I set the address base to 90H but maybe it would be nice to change
> this to 98H (start of the V9938 registers) for MSX2 compatibility. I
> think it will need some rewiring in the address decoding.
> Next step is checking out the BT478 and maybe VGA output.
> How’s everyone else going with their VDPs
> Leon Byles