Help getting a homebrew v9958 to work

페이지 1/2
| 2

By Stupid20CharLimit

Supporter (4)

Stupid20CharLimit의 아바타

01-09-2020, 01:21

So I'm making a homebrew z80 system with a video card that has a v9958 on it. It has 4 41464 ram chips on it for a total of 128k of video ram. Not an msx, I know, but hopefully someone here will be able to help or give me ideas of stuff to try that I haven't already. I am completely out of additional ideas of things to try. This will be a long post as I am going to type every single little thing I have tried and what results, if any that happened because of it.

I have some information including schematics of both my z80 system's mainboard and my v9958 board here (the most recent post is at the bottom). The github repository for my code is here which also has schematics posted.

Anyway, so I'm trying to get my v9958 to work. So far, I have got it to output a solid color but nothing else. I can change the color by modifying the palette register but if I change the text1 or text2 mode colors in register 7 to anything, nothing different happens. It refuses to do anything except make the entire screen a solid color of whatever is in the palette register 0. I can also access the status registers and print them to my 20x2 character lcd screen and the results make sense according to the v9938 programmers guide.

Here are pictures of a solid red screen and a solid green screen:
blank red screen
blank green screen
In my current code on github, I put the color green into palette 0 and as a result, it shows a green screen entirely regardless of what's in register 7.

My schematic is largely based off of that one primrose bank schematic with the CXA1645P.

Anyway so the first problem I had was I was getting no video at all - turned out I had the composite and the s-video on backwards. I fixed that and suddenly, a solid color showed up on the screen. This then began my long and fruitless process of trying to get it to do anything other than show 1 solid color.

In a nutshell what my code does is set the video mode, set up registers 0, 1, 8 and 9, set palette registers, set register 7 and then set up registers 2, 3, 4 and 10 to have the correct vram addresses for when I type the command to copy over the font and/or type the command to try to display text on the screen. I have tried setting the registers in all kinds of different orders and have found that it doesn't seem to make a difference.

I don't even get garbage on the screen as expected. Shouldn't there be a bunch of random stuff in the vram, or doesd the vdp clear it? Since this seems like a vram issue, that's the first thing I started investigating.

One of the first things I noticed was that I forgot to attach RAS (pin 62 of the vdp) to RAS of the 41464 ram (pin 5). I fixed that which caused nothing different to happen. I tested every different pin of each of my 4 41464 chips and found that that they all had perfect continuity to where they were supposed to go. I hooked up a logic analyzer to see if the vdp was indeed sending and receiving data to the ram and indeed it was. Here is a screenshot of my logic analyzer screen when writing data to vram. and here is a screenshot of the vdp reading from vram.

I tried putting a 10k resistor on r3 instead of a 1k resistor. This resulted in video no longer coming out so I put it back. I tried replacing C33 with a 30pf ceramic disc capacitor which resulted in nothing being different. I then put back on a different variable capacitor which resulted in nothing different happening no matter what I adjusted it to (as before when I had a variable capacitor on). At one point I had a 300ohm resistor between xtal 2 and c16. I took that out and jumped the connection with the shortest ide cable wire possible to reduce interferance and nothing different happened. I tried hreset and vreset directly to 5v. I put a 10k resistor between vreset and +5v and then hreset and +5v. This made no difference. I tried putting in a different v9958 chip and nothing happened. I have NOT tried putting in different ram chips yet (which I am doing to try when I get different ones) but I have taken them all out of their dip sockets, put them back and tested for continuity again.

The address decoding logic I had on there wasn't correct at first but I fixed it. I can successfully read data from the vdp as well as write to the vdp on all ports and have confirmed this with a logic analyzer. My z80 cpu is clocked at 1MHz so there's no way it's going too fast for the vdp. Also note that I forgot to connect ioreq, wr and rd on my mainboard which I fixed even though I haven't updated it in the schematics.

The CXA1645P will output to the s-video and the composite plug. When I switch j4 to use the composite signal straight from the v9958 and not the video encoder, it's just a blank white screen each time.

I have thoroughly checked my code thinking the palette register subroutine or the font copying subrountine wasn't working but nothing I ever did programming wise has made a difference (other than when I load a different color into palette register 0). While I am quite certain my code should be correct as far as setting up the vdp goes, I am open to any suggestions you may find by looking at it. The relevant stuff is is "9958driver.asm" and a little bit of relevant stuff is at "commands.asm". I have tried text 1, text 2 and graphics 1. In all of those modes, it has been just a solid screen of whatever color is in palette register 0. No graphical garbage. No random font sprites. Just a solid screen. It doesn't matter if I run the "loadfonts" command (the one that loads the font data into vram) or "vprint" which loads a bunch of random stuff onto the screen. It's always just a blank solid screen.

I feel like I have done and tried every single thing there is to try. Does anyone have any other ideas? Anything I'm missing or forgetting? Any help would be greatly appreciated and if anyone would like me to post the results of any additional data or tests, let me know.

Login or 등록 to post comments

By Stupid20CharLimit

Supporter (4)

Stupid20CharLimit의 아바타

01-09-2020, 04:45

Ok I just wrote a vram test program to see if the cpu can write data to the vram then load it so that I could see if it returned the same value I wrote. The returned values were all the same. I tested from vram address $00002-$00006 and then from $00102-$00106. While I didn't test all 128k bytes, this proves that the vram should at least be working enough to show more than just a solid colored blank screen. If I could even get at least a bunch of graphical glitchyness right now, I would throw a party. But no. The search for what's wrong continues.

By bsittler

Expert (72)

bsittler의 아바타

01-09-2020, 09:17

No idea whether it's helpful in this case, but when I was programming a related Sega VDP I got similar results until setting bit 6 of VDP register 1 to un-BLank the output

By sdsnatcher73

Paragon (1147)

sdsnatcher73의 아바타

01-09-2020, 16:28

Maybe it is an idea to examine the MSX BIOS initialization routines to see what VDP register settings it makes before continuing? It’s sources are available here.

By sdsnatcher73

Paragon (1147)

sdsnatcher73의 아바타

01-09-2020, 16:49

bsittler wrote:

No idea whether it's helpful in this case, but when I was programming a related Sega VDP I got similar results until setting bit 6 of VDP register 1 to un-BLank the output

https://www.msx.org/wiki/VDP_Mode_Registers indicates this as well. It says it is 1 by default but that is on an MSX after BIOS initialization.

By NYYRIKKI

Enlighted (5595)

NYYRIKKI의 아바타

01-09-2020, 20:09

Quickly looking I can't see anything wrong with this (very cool project BTW!)

I would maybe try to do some really simple tests next like changing reg #9 to 2 to see if the sync signal drops to 50Hz correctly... Not very helpful, but just to see if the VDP is receiving any writes to internal registers from port #21

Here is also alternative test program that you may also try if you suspect software problem... This stupid example routine just fills second half of Z80 memory space and then dumps the content as HEX to screen and loops (does not really require RAM to be present or working)

By Parn

Hero (607)

Parn의 아바타

01-09-2020, 22:54

Another thing, you could take the CXA temporarily out of the equation and just use the RGB signals from the VDP directly. If you don't have an RGB monitor capable of accepting 15kHz video, you can use each component separately as if it were composite video.

By Stupid20CharLimit

Supporter (4)

Stupid20CharLimit의 아바타

02-09-2020, 01:16

Alright thanks for the responses everyone.

bsittler wrote:

No idea whether it's helpful in this case, but when I was programming a related Sega VDP I got similar results until setting bit 6 of VDP register 1 to un-BLank the output

While I already have my code set bit 6 of register 1, I thought maybe it resets register 1 bit 6 each time a register write is made or something. I then made a subroutine to set bit 6 of register 1 and pasted it below everywhere in my code that has anything to do with vdp registers. This did not change anything.

BYYRIKKI wrote:

I would maybe try to do some really simple tests next like changing reg #9 to 2 to see if the sync signal drops to 50Hz correctly... Not very helpful, but just to see if the VDP is receiving any writes to internal registers from port #21

After reading your suggestion, I made a command where I could type "togglevmode" and it would toggle between pal and ntsc by setting/resetting bit 1 of register 9. Whenever I did this, nothing differently that I could observe happened on the screen. It continued to display a blank solid color screen.

BYYRIKKI wrote:

Here is also alternative test program that you may also try if you suspect software problem... This stupid example routine just fills second half of Z80 memory space and then dumps the content as HEX to screen and loops (does not really require RAM to be present or working)

Cool. So obviously, my system is different than an msx or something but it should work somewhat the same when the correct addresses get put in. One change I did make is I put a "ld b, $A0" before every out (and be sure to push bc before and pop bc after in case it needs the b register for anything). However, my compiler (z80asm) doesn't know how to handle the ".LOOP" stuff and I'm not sure what they are either. I tried putting a colon at the end of them so the compiler treats them as jump addresses but there are 2 "RETURN1"s. What does that stuff mean?

I did decide to use my vram test to test more of the vram space and I have yet to have it find any problems. Perhaps I'll modify it so that it tests all of the vram just to be thorough.

Parn wrote:

Another thing, you could take the CXA temporarily out of the equation and just use the RGB signals from the VDP directly. If you don't have an RGB monitor capable of accepting 15kHz video, you can use each component separately as if it were composite video.

Alright so I connected a composite rca port to the green rgb out of the vdo (pin 22) and connected the negative lead of the rca port to ground. That made this happen:

Changing between ntsc and pal as NYYRIKKI suggested made no changes to the appearance of the screen.

Another thing which I mentioned in my first post is that if I try to output pin 6 (csync) of the vdp directly to rca and try to view that on the screen, I get this:

Note that the image displayed on the screen when I do this does not change when I toggle between pal and ntsc through register 9.

By bsittler

Expert (72)

bsittler의 아바타

02-09-2020, 07:33

Is the VDP known to be fully functional? And does it have the correct crystal attached to XTAL1 and 2?

Since you're able to program the pallette register, try cycling the value rapidly. Do you see "color stripes" this way? And if you have an oscilloscope, can you inspect the sync pulses the VDP generates? Measuring these (amplitude, duration and frequency of recurrence) might help diagnose whether video generation is basically functional

By Manuel

Ascended (16974)

Manuel의 아바타

02-09-2020, 08:51

Can your monitor show the refresh rate of the input signal (vsync frequency)? If yes, it should change when toggling that NTSC/PAL bit. If it doesn't change, there are fundamental issues.

By NYYRIKKI

Enlighted (5595)

NYYRIKKI의 아바타

02-09-2020, 10:35

Stupid20CharLimit wrote:

After reading your suggestion, I made a command where I could type "togglevmode" and it would toggle between pal and ntsc by setting/resetting bit 1 of register 9. Whenever I did this, nothing differently that I could observe happened on the screen. It continued to display a blank solid color screen.

I would probably use that signal analyzer to check if it can read 50Hz and 60Hz from csync (pin 6)... As Manuel pointed out there are some really fundamental problems if this does not change. This test does not require VRAM to be connected or anything. It should be enough that the VDP receives what you write to registers and you have crystal connected ok. Maybe worth to check that A0 and CSW (pins 29,30) get the signals that you expect.

Quote:

Cool. So obviously, my system is different than an msx or something but it should work somewhat the same when the correct addresses get put in. One change I did make is I put a "ld b, $A0" before every out (and be sure to push bc before and pop bc after in case it needs the b register for anything)

Ah yes, sorry... I missed that you are using 16bit I/O... Be careful with the PUSH/POP stuff (maybe EXX instead?)... I did not know where you have RAM, so no stack pointer is initialized... The program also erases #8000-#FFFF by default on each test loop.

Quote:

However, my compiler (z80asm) doesn't know how to handle the ".LOOP" stuff and I'm not sure what they are either. I tried putting a colon at the end of them so the compiler treats them as jump addresses but there are 2 "RETURN1"s. What does that stuff mean?

I used SjAsmplus to compile it... Yes these are jump addresses aka labels, but local ones... If you ie. have global label like "PRINT:" and then some lines later you have local label like ".LOOP", this will create a label called "PRINT.LOOP:" that can be referred just as ".LOOP" until next global label is defined. If you changed all labels to global, then change the first RETURN1 label to ie. RETURN9 and fix the LD IY,RETURN1 few lines earlier to 9 and it should be fine.

페이지 1/2
| 2