Debugging J.B. Langston's TMS9918A card for RC2014

[Dave Snowdon]

I recently build J.B. Langston's TMS9918A card for RC2014 from the kit supplied by Michael Kamprath on tindie.

I've just hooked this up to a monitor using an AV to HDMI converter, assembled some of the demos from https://github.com/jblang/TMS9918A/tree/master/examples using sjasm and run them on the RC2014 only to see a gloriously blank screen.

The card has the default jumpers.

The examples, such as sprite.asm contain an "org $100" statement so AFAIK I should be able to just run sjasm on the .asm file, copy  the resulting .out file to sprite.com on the RC2014 (running RomWBW) and run it.

I've used an AV modded ZX Spectrum to prove to myself that the AV cable and monitor are working. I know that the  TMS9918A generates 60Hz NTSC instead of PAL like the Spectrum but I think the AV converter should handle both.

I'm still a noob with the RC2014 and electronics in general but I do have access to an oscilloscope (but I'm new to using that too :-(

Any recommendations on things to try next? Any known gotchas with this card?

[Mark T]

Are you in the uk? I would suggest trying the composite output of the tms9918a into the composite input of a tv instead of the av converter. Most tvs in uk have been capable of pal or ntsc input for more than 10 years now.

If you dont have a tv with composite input, you could try one of the RGB inputs.

Blank screen could just mean the av converter wasnt able to synch to the input.

Mark

[Dave Snowdon]

Hi Mark

Yes, I'm in the UK. I didn't use a TV by default as I don't have one in my workroom.

I just tried what you suggested and while I still only saw a blank screen I did get one more piece of information: when I unplugged the composite cable from the TV it displayed it's "no signal" warning. This suggests that it was getting enough of a signal from the TMS9918A card to make it think a composite video signal was present.

Dave

[Mark T]

If you see a plain black screen then the timing signals are probably being generated by the tms9918a.

Its probably not getting initialised by the software. As you are using demo code, its likely the problem is in address decoding on the tms9918a card. Maybe the address selection links dont match the demo code.

Mark

[J.B. Langston]

Sorry, somehow I missed this discussion before.  I would suggest checking that your jumper configuration matches the settings configured in the example programs you assembled. I have updated the README section on jumper configurations to be less confusing now: https://github.com/jblang/TMS9918A/blob/master/README.md#jumper-descriptions

The README previously suggested the MSX jumper configuration by default but the examples were configured to use the ColecoVision jumper configuration. I now primarily use ColecoVision jumper settings on my own board so I can play CV games, and I updated the examples to use that configuration but forgot to update the README. Sorry for any confusion that caused.

[Dave Snowdon]

Thanks. I'll give that a go. Not found the time to take a look at this since my last post.

[Dave Snowdon]

Thanks JB. I've switched my card over to the CV jumper settings (I have an SIO/2 card so I need to use NMI anyway) and it looks like it's almost working.

• Mandelbrot - looks recognisable
• plasma & nyan - generate vertical white & black bars
• sprite - black screen
  

My guess is that the addressing is slightly off somehow. Anyone seen anything like this before?

thanks

Dave

On Sunday, 2 February 2020 15:33:40 UTC, J.B. Langston wrote:

[Dave Snowdon]

Posted the same attachment twice. Here's what the plasma & nyan examples display

[J.B. Langston]

Hmm, no I haven't seen that before.  The thing that nyan, plasma, and sprite have in common is that they use an interrupt, whereas mandelbrot and ascii don't.  Maybe the interrupt isn't executing the correct code. Do you have the code configured to set up NMI rather than INT?

Does the ASCII example work?

--
You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/qb2GNPCbbXM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/6828638c-9794-4ac9-b5aa-c73cdc5cf50d%40googlegroups.com.

[Dave Snowdon]

The ASCII demo produces some output (see attached ascii.jpg) and the letters are just about recognisable, but there are still the white grey & black vertical bars as there was with nyan and plasma

So that tends to suggest it isn't an interrupt issue.

I'm launching the examples from RomWBW running CP/M, could that cause any problems?

On Sunday, 9 February 2020 21:18:49 UTC, J.B. Langston wrote:

Hmm, no I haven't seen that before.  The thing that nyan, plasma, and sprite have in common is that they use an interrupt, whereas mandelbrot and ascii don't.  Maybe the interrupt isn't executing the correct code. Do you have the code configured to set up NMI rather than INT?

Does the ASCII example work?

On Sun, Feb 9, 2020 at 12:33 PM Dave Snowdon <dave....@gmail.com> wrote:

Posted the same attachment twice. Here's what the plasma & nyan examples display

On Sunday, 9 February 2020 18:32:34 UTC, Dave Snowdon wrote:

Thanks JB. I've switched my card over to the CV jumper settings (I have an SIO/2 card so I need to use NMI anyway) and it looks like it's almost working.

• Mandelbrot - looks recognisable
• plasma & nyan - generate vertical white & black bars
• sprite - black screen
  

My guess is that the addressing is slightly off somehow. Anyone seen anything like this before?

thanks

Dave

On Sunday, 2 February 2020 15:33:40 UTC, J.B. Langston wrote:

Sorry, somehow I missed this discussion before.  I would suggest checking that your jumper configuration matches the settings configured in the example programs you assembled. I have updated the README section on jumper configurations to be less confusing now: https://github.com/jblang/TMS9918A/blob/master/README.md#jumper-descriptions

The README previously suggested the MSX jumper configuration by default but the examples were configured to use the ColecoVision jumper configuration. I now primarily use ColecoVision jumper settings on my own board so I can play CV games, and I updated the examples to use that configuration but forgot to update the README. Sorry for any confusion that caused.

On Sunday, January 5, 2020 at 2:23:23 PM UTC-6, Mark T wrote:

If you see a plain black screen then the timing signals are probably being generated by the tms9918a.

Its probably not getting initialised by the software. As you are using demo code, its likely the problem is in address decoding on the tms9918a card. Maybe the address selection links dont match the demo code.

Mark

--
You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/qb2GNPCbbXM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to retro...@googlegroups.com.

[J.B. Langston]

Hmm, I'm not sure what the problem is. This seems more than a simple software or configuration issue though.  It's almost as if every other bit is stuck on in memory. The other possibility is that your TV doesn't like the signal.  So, a few questions/suggestions:

Have you tried using it on a different TV? 

Check the board for solder bridges or cold solder joints. I would especially suspect something in the interface between the VDP chip and the memory, so carefully check the solder joints on the VDP, the RAM, and the 574 chips between the two.

Check whether you can write data to the chip and read it back out successfully. Make sure that what comes out is exactly what you put in.  If reading and writing the memory works, then the issue is most likely with the video output rather than the memory. If you have a z80ctrl, you can use this via the tmsfill and tmsdump commands. If you don't, then you'll have to write some code.  You can use the following program for MBASIC to do this:

10 REM COLECOVISION PORTS; CHANGE TO MATCH JUMPERS
20 MEM=&HBE
30 REG=&HBF
40 REM SET TEXT MODE REGISTER VALUES
50 DATA 0, 208, 0, 0,  1, 0, 0, 249
60 FOR I = 0 TO 7
70 READ V
80 OUT REG,V
90 OUT REG,(I OR &H80)
100 NEXT
110 REM START WRITING AT ADDRESS 0
120 OUT REG,0
130 OUT REG,&H40
140 REM WRITE 16K OF MEMORY WITH ASCENDING VALUES 0-255
150 FOR I = 0 TO &H3FFF
160 REM TO OUTPUT FIXED VALUE, REMOVE "I AND &HFF" BELOW
170 REM AND CHANGE IT TO 0, &HFF, &HAA, &H55, ETC.
180 OUT MEM,I AND &HFF
190 NEXT I
200 REM START READING AT ADDRESS 0
210 OUT REG,0
220 OUT REG,0
230 REM READ 16K OF MEMORY AND PRINT EACH BYTE
240 FOR I = 0 TO &H3FFF
250 PRINT HEX$(INP(MEM))
260 NEXT

While the program is running you may see random garbage changing on the screen.  It will take a minute or two to fill the memory, then it will start printing out the values it reads back from memory. You can hit CTRL+C to stop the output after a while.  

You should see hex numbers increasing from 0 to FF and then starting over. If any numbers don't follow this pattern, then you likely have a memory issue.  If the numbers are correct, the issue is more likely in the video output.

You may also want to change line 180 to write a fixed value instead of the loop counter.  Some useful values to try would be 0, &HFF, &HAA, and &H55.  0 and &HFF are all 0 and 1 bits respectively.  &HAA and &H55 are the bit patterns 10101010 and 01010101, respectively.  You should get back out whatever number you put in.

If you try all these things, it should at least give you an idea of where the problem is. If you can't find anything obviously wrong with the board, it's possible you have a bad chip.

To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/2faa133a-686b-4f6a-90c4-55074ac1e8fa%40googlegroups.com.

[Dave Snowdon]

The memory test was very helpful. It looks like two bits are stuck together which was revealed by the &HAA and &H55 bit patterns (&HFF and 0 showed no issues).

Looks like I probably have a short between two of the data lines. I'll take another look at the board and see if I can find it.

thanks

Dave

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/2faa133a-686b-4f6a-90c4-55074ac1e8fa%40googlegroups.com.

[Dave Snowdon]

Took me a while to find more time for this. Looks like there is a short between VD5 & VD6 somewhere as these bits appear to be tied together. I spent a while visually checking my soldering and could not spot anything so I'm going to pull the chips from the board and test the connections with a multimeter. Thanks for all the help so far.

[zugan2]

Hi, there.

I also had stucked a few weeks with a memory failure trouble.

The BASIC program made by J.B. Langston-san was very helpful for analyze the failure.

In my case, HM62256AP A6 and A12 was shorted within the IC.

https://twitter.com/powpher/status/1234059841548607489

I ordered another HM62256AP from the other seller and am waiting for the parcel.

And I requested first seller to money refund.

But unfortunately under corona virus situation, all transportation is currently stopped.

Sooo, my troubleshooting is forced to postponed a month or more lol.

Regards,

2020年3月17日火曜日 15時55分43秒 UTC+9 Dave Snowdon: