ULIfAC:Usb Mass storage,WiFi, 512KB Ram/32XROM Board/256K Ram+16X Rom Board!

[vasilisk]

Bit of an odd question, but my 6128 has some kind of problem with the upper memory bank where 64k programs work fine but 128k ones either crash or get graphical glitches.

I know the Ulifac can effectively turn a 464 into a 6128, so is it possible to disable the top 64k on my machine then use the Ulifac's memory to bring it back up to 128k?

When you connect ULIfAC on a CPC6128, the 2nd bank of 64k on Amstrad board, will practically disable,and only the 512k/256k extra ram on ULIfAC board (depending on the mode you are),will be used. So, most probable it will resolve the problem with the 2nd bank on your Amstrad.

So you can't have 128k but only 256 or 512?

[ikonsgr]

So you can't have 128k but only 256 or 512?

You have 320kb or 576kb total ram (256+64k internal or 512+64k internal)

[vasilisk]

So you can't have 128k but only 256 or 512?

You have 320kb or 576kb total ram (256+64k internal or 512+64k internal)

I was only asking about @Amagni 's "problem". For example, dragon ninja have speech samples if 128k is present. Is it going to see the total ram or the 64+256, 64+512.

[andycadley]

So you can't have 128k but only 256 or 512?

You have 320kb or 576kb total ram (256+64k internal or 512+64k internal)

I was only asking about @Amagni 's "problem". For example, dragon ninja have speech samples if 128k is present. Is it going to see the total ram or the 64+256, 64+512.

Part of the ULifAC RAM will replace the internal 64K (as it would if that RAM worked). Whether or not it will fix the issue might depend on exactly how it has failed. I don't think anyone could say for certain without actually just trying it, though there is a good chance it would fix it.

[vasilisk]

I dont know if @Amagni is talking about failed memory.

[Amagni]

Ok, I did a bit more testing and now I'm even less sure of the issue!

If I run the |DIA utility on the Ulifac, it shows lower RAM as ok, but upper RAM gives some error codes (see the first image below).  I assume this is the CPC's internal memory and not the added RAM, right?  It doesn't continue past bank 0 and the computer locks up and needs to be rebooted.

It also gives odd results for the ROM test but I don't know if it that's a problem.

I tried copying the "Logon's Run" demo to a floppy, and if I run it without the Ulifac it just fills the screen with dots that gradually settle into the stripes shown in the 4th image below, while the speaker emits a single tone.
If I run it with the Ulifac, either from floppy or USB, it runs but gets lots of visual artefacts and random characters.  I tested it on a friend's original Amstrad CRT monitor and it looks the same, so it's not just my HDMI converter acting up.

Some other games and demos get the same kind of video noise, but others (presumably 64k ones) work just fine with no glitches at all.

Is it possible that the faulty RAM is still having an effect when the Ulifac is in use, or that some other related chip is causing the issues?

[ikonsgr]

@Amagni ,first thing, did you set the small switch on ULIfAC to "6128" position? Otherwise, it will enable the MREQ signal depression (required for extra ram to function on CPC464) which might cause problems on CPC 6128.
 Now, if you still get same problems with "6128" mode, then, apart from maybe having a faulty internal ram interfere, there is also a chance of having a faulty (or maybe bad contacts) of PAL/GAL 16L8 chip (https://www.cpcwiki.eu/index.php/PAL16L8) which implements the memory management on CPC6128.

[Amagni]

Ok, it was in 6128 mode, so I tried switching to 464 mode and it actually works better!

The upper RAM test completes and all looks good.
The "Wolf 128" demo no longer has glitches and works fine.
The "Women & Dragons" demo now runs instead of halting at the initial "loading" message, but it does glitch in one of the scenes.
"Pinball Dreams" runs the intro screen with the nice animated lightning but freezes after a few seconds of the title music.
"Logon's Run" looks even worse, it's just the red screen below with weird snow flying around.

Do you think it's worth pulling the HAL1618 chip and popping it back in?

[ikonsgr]

Ok, it was in 6128 mode, so I tried switching to 464 mode and it actually works better!

The upper RAM test completes and all looks good.
The "Wolf 128" demo no longer has glitches and works fine.
The "Women & Dragons" demo now runs instead of halting at the initial "loading" message, but it does glitch in one of the scenes.
"Pinball Dreams" runs the intro screen with the nice animated lightning but freezes after a few seconds of the title music.
"Logon's Run" looks even worse, it's just the red screen below with weird snow flying around.

Do you think it's worth pulling the HAL1618 chip and popping it back in?

 Hmmm, it seems that the MREQ signal masking on CPC464 mode, somehow "masks" the problem too...   And that, indeed indicates some kind of problem with the HAL chip. Fortunately this chip is in socket, so you can easily unplug it, spray some contact cleaner onto socket and replug it. If again you have the same symptoms, then maybe the chip went bad.
Btw, if you unplug ULIfAC, or swap to 32xrom mode (so Amstrad will use the internal 64k extra ram) you also get the same problems?

p.s. unfortunately the MREQ masking has some limitations: C3 mode is not supported, symbos, futureos and cpm+ are not working, and also a few games too, one of which, is  pinball dreams. I'm actually in a process of redesigning the hole extra memory management  for cpc464, by replacing completely the internal 64k main ram, with a block of 64k from the external 512k ram, in order to fully emulate all memory configuration modes without problems, i recently manage to load symbos and pinball dreams on CPC464 in dual 256k ram/16x rom mode, but i get some kind of video noise on screen when specific configuration modes 1,2,3 are active (e.g. use &C000-&FFFF video ram memory range from external ram), which i'm afraid is because CRTC video chip always access the 16k  video ram from internal ram, so i have to somehow find a way to "selectively" disable writing internal ram -possibly using the same mreq masking method- but ONLY when Amstrad access video ram range and the specific configuration modes are active. Hopefully this will resolve the problem...