Need help repairing Philips MSX2 NMS 8250

Hero (644)

26-09-2018, 11:42

The MegaFlashRom, if it is the ~~SCC+~~SCC+SD version, might have a RAM mapper. Depends on the configuration it was ordered with from the shop (the 512kb RAM mapper and 2nd µSD card slots are optional).

If it is just a MegaFlashROM (not the SCC+ version, EDIT:or plain SCC(+) without SD), it does not have a RAM mapper IIRC.

https://www.msxcartridgeshop.com/

There are other cartridges with a RAM mapper out there (new projects and, more rarely, something made back in the 80s and 90s).

By Grauw

Ascended (10772)

27-09-2018, 10:14

llopis wrote:

Grauw wrote:

Whether the RAM is the problem can be tested by plugging in an external memory mapper, if the machine boots normally then it’s the RAM.

Is this a ROM I can burn and put instead of the existing ROMs, or are we talking about a cartridge?

I’m talking about a RAM expansion cartridge with a memory mapper and a certain amount of RAM.

But if you have the ability to burn EPROM chips that’s nice too, you can use that to create a new BIOS ROM and replace that to rule out issues with the BIOS ROM as well...

llopis wrote:

Also, in a few days I should get a MegaFlashROM. Is that something I can use to try a test RAM program? Any recommendations for which one?

The MegaFlashROM SCC+ SD has a version with a 512K RAM option, if that’s the one you are getting then you should be able to use that to test the RAM as it will use that instead of the built-in memory when it’s plugged in.

By llopis

Resident (55)

27-01-2019, 22:36

All right, I finally got back to working on this MSX2. I haven't fixed it, but I made some progress:
- The user RAM ICs are all fine (tested on a Spectrum+2 with RAM tests)
- The Z80 is fine
- The ROMs... they all had some different bits from the ones in the OpenMSX archive. I don't know if that's normal or not. The MSX2Sub one of them just had 1 byte difference, and the BasicBios one (32K) had a bunch of bytes different. I don't know if those are different versions and that's why that happened. I replaced them with freshly burned ones and nothing.

So /CAS keeps being high all the time. I looked at the schematics to see where /CAS is coming from, and it's kind of a mess (at least for non-MSX experts). The schematic just throws it in the general "signals" bus and it's hard to tell where they're coming from. I see that they're being passed through IC111, which is an OR gate, but one of the inputs is always high.

That in turn is coming from IC149, which is a quad 4-bit latch (which only seems to actually store the first 3 bits of the data bus, not 0). That latch gets some reasonable inputs, /Gr is always low (as it should), but the outputs are always 1 for all 4 bits. So maybe this latch is bad? It would be nice if it was that simple, but I suspect there's something more than that. For now I ordered a new one and we'll see what I learn when I replace it.

By llopis

Resident (55)

29-01-2019, 14:04

Update: Replaced IC149 and there's now activity on the output bits but... as I suspected, /CAS is still always high. I need to continue investigating.

By Jipe

Paragon (1614)

29-01-2019, 16:34

do you know this manual

http://msx.hansotten.com/uploads/fyfiles/philipsnms8250rm.pdf

By Jipe

Paragon (1614)

29-01-2019, 17:03

http://msx.hansotten.com/special-msx-hardware/philips-test-c...

By llopis

Resident (55)

29-01-2019, 19:41

I had seen that repair manual, but I think it relied on the test cartridge (which I see you linked). Is there an easy way to run it from a Carnivore, or did it have some extra hardware built in?

By Jipe

Paragon (1614)

29-01-2019, 20:22

never testing , i think a 16k eprom cartridge is ok

By llopis

Resident (55)

29-01-2019, 23:13

Quick update for the night:
- I tried running the test rom on an EEPROM cartridge I had around (with the motherboard button pressed), but I didn't get any video signal or got anything else different.
- I started tracing logic around the generation of /CAS and all the glue logic seems to be working from what I can see, but it all comes down to /IORQ always being high. The Z80 has definitely been tested, so that's not it. And I replaced all the ROMs with new burned copies just to make sure, but /IORQ always remained high, which blocks most of the glue logic from activating.
- I also noticed that there was no /INT signal coming to the Z80, which is supposed to be generated in IC106 (VDP) pin 25. But there's no activity there. As a matter of fact, there's very little activity in the first 20-30 mins of IC106. I don't know if that's cause of consequence of the INT and IORQ missing signals.

Any ideas what could be causing that?

By Wierzbowsky

Guardian (3608)

30-01-2019, 00:23

In my Sony F700P the missing INT signal from the VDP didn't let the machine boot. After replacing the VDP everything worked fine. As the VDP was my last suspect, I changed quite a few chips on the motherboard...