Help getting a homebrew v9958 to work

Página 2/2
1 |

Por vossi

Rookie (25)

Imagen del vossi

02-09-2020, 12:32

I made a mistake with my v9958-cbm2 graphics card-intro.
I cleared the first 16kB vram and got no picture except the background color.

Reason: After clearing the vram autoincrement points to the next 16kB and all my other vram writing go to the next 16k-block!!! Wink

github.com/vossi1

Christian

Por NYYRIKKI

Enlighted (5605)

Imagen del NYYRIKKI

02-09-2020, 16:36

I actually fixed the source now so that it does not use local labels but uses 16bit I/O ports and gave it a quick spin in Spectravideo emulator to see that it still works. The updated version is here.

BTW may I ask why you have selected to use these 16bit I/O ports in your system??? From my eyes they just waste space and time in code, make totally good and fast B-register as well as commands like OUTI pretty useless not to mention that they make the hardware more complicated... I bet there must be some positive sides that I just can't imagine right now. :)

Por NYYRIKKI

Enlighted (5605)

Imagen del NYYRIKKI

02-09-2020, 16:48

vossi wrote:

Reason: After clearing the vram autoincrement points to the next 16kB and all my other vram writing go to the next 16k-block!!! Wink

I have quite a strong impression that this should not happen at least on "text modes"... Not quite sure where I've got this impression though... I bet I've heard it from someone.

Por Grauw

Ascended (9379)

Imagen del Grauw

02-09-2020, 18:19

Yes, iirc in the TMS9918-modes the address pointer does wrap around at 16K for compatibility.

openMSX source confirms:

void VDP::executeCpuVramAccess(EmuTime::param time) {
    ...
    vramPointer = (vramPointer + 1) & 0x3FFF;
    if (vramPointer == 0 && displayMode.isV9938Mode()) {
        // In MSX2 video modes, pointer range is 128K.
        controlRegs[14] = (controlRegs[14] + 1) & 0x07;
    }
}

/** Was this mode introduced by the V9938?
  * @return True iff the base of this mode only is available on V9938/58.
  */
constexpr bool isV9938Mode() const {
    return (mode & 0x18) != 0;
}

Por Stupid20CharLimit

Supporter (4)

Imagen del Stupid20CharLimit

03-09-2020, 00:28

Wow so I took NYYRIKKI's hexdump2 program and compiled it with sjasmplus without changing anything. I then burned it onto a blank eprom, plugged it into my computer and got this:


For those wondering, my ram is from 2000h to 9FFFh. When the program got to address A000h, it showed a bunch of random characters stuff from A000h to ~A023 and then started showing zeros (where I don't have anything at). This means the thing preventing stuff from displaying on the screen appears to have been problems with my code and was actually entirely in software and now I just have to compare hexdump to my code until I find what I've been doing wrong.

NYYRIKKI wrote:

BTW may I ask why you have selected to use these 16bit I/O ports in your system??? From my eyes they just waste space and time in code, make totally good and fast B-register as well as commands like OUTI pretty useless not to mention that they make the hardware more complicated... I bet there must be some positive sides that I just can't imagine right now. :)

When I first started this, it was just a simple led counter on a breadboard. I wasn't even trying to make a personal computer type thing like an msx or z80 spectrum or something until I got the idea to try to do that later. I eventually added an 8k eprom which was naturally 0000h to 1FFFh. I then later added a 32k ram chip and it was easiest at the time to wire up the logic to make the ram be from 2000h-9FFFh. When I initially started experimenting with the 20x2 lcd display, keyboard controller and rtc, I didn't think to put it in i/o at all so I just put all that stuff above the ram starting at A000h.

When it became time to actually start making the io devices use the io space (lol and the keyboard controller and rtc still uses mem space), not all address decoders were wired to be able to distinguish io space from memory space so for testing purposes while I started fixing that, it was easiest to leave it.

That may not be a good reason for the io addresses to be 16 bits lol but that is the reason.

Edit:
So. What I think the problem was is that I had the pattern generator and pattern layout addresses overlapping. I think that the reason anything video related was unresponsive to palette changes or switching between ntsc/pal mode is that once I loaded those invalid settings, maybe it crashed the video signal part of the vdp without crashing the vram, status registers or ports.

This doesn't explain why I didn't get anything on the screen in the beginning before I was setting those registers but perhaps one of the capacitors or resistors I changed also fixed something related.

But anyway, here is a picture of a bunch of garbage and also some characters that I wrote to the screen

ITS WORKING NOW!!!!!!!!!!!! B-)

Por NYYRIKKI

Enlighted (5605)

Imagen del NYYRIKKI

03-09-2020, 00:36

Yes, it looks like what I expected it to look like... So, this is indeed a software problem... I guess this is good news after all... Although your software is still not working, at least we managed to rule out hardware side of the problem.

Edit: Ah, you fixed it already. Congratulations!!!

Página 2/2
1 |