exxos's Atari, Amiga & retro forum

Posted: **09 Mar 2026 22:28**

PhilC wrote: 09 Mar 2026 13:45 Another observation. I've got some graphics glitches/oddities.

Thanks! But annyoing that I am not seeing any of these issues on my GD5434.

And if you would have moved the mouse cursor over "Read .INF file..." and then away from it you would have been left with the purple bars there too?
And if that guess was true, how would it look with the mouse cursor steady over one of the menu options before leaving it. Correctly inverted colors or also wrong? :)
(I am only guessing that where you have the purple bars you have already hovered the mouse over these entries? And the ones that are fine are fine because you have yet to mouse over them)

The small box under Disk C appears to be some other issue, or perhaps a different symptom of the same root cause.
Gut reaction, maybe a fillpattern blit where the pattern offset ended up wrong by a pixel, that could make the checkerboard not align in screenspace.
But the location of them are weird, unless one of the windows was there originally and then moved away -- leaving those lines?
(if so, then that reinforces the theory of misaligned source position for the fillpattern)

Posted: **09 Mar 2026 23:24**

agranlund wrote: 09 Mar 2026 22:12

If the screensaver kicks in then I would double check that you have these files installed:
c:\nova_col.acc
c:\nova_col.inf
c:\auto\sta_vdi.inf

(the inf files from the release package should already be configured to kill the two different ways Nova screensaver can trigger. One is time-based and the other can start the screensaver by mouse-coordinate -- both are broken in that they seem to trigger almost "randomly" and can never resume. I do not know why and Nova screensaver behaves equally broken on my (accelerated) Atari ST with ET4000)

Castway also no longer works well and has a dirty screen.

I take it you are using the Nova ET4000.Tx driver? Out of curiosity, do you experience the same issue when using the SVGA driver?
[/quote]

Yes. Same issue.

Posted: **09 Mar 2026 23:24**

luciodra wrote: 09 Mar 2026 23:24
agranlund wrote: 09 Mar 2026 22:12

I take it you are using the Nova ET4000.Tx driver? Out of curiosity, do you experience the same issue when using the SVGA driver?
Yes. Same issue.

Posted: **09 Mar 2026 23:25**

Yes. Same issue.

Posted: **11 Mar 2026 09:58**

agranlund wrote: 09 Mar 2026 22:28
PhilC wrote: 09 Mar 2026 13:45 Another observation. I've got some graphics glitches/oddities.
Thanks! But annyoing that I am not seeing any of these issues on my GD5434.

And if you would have moved the mouse cursor over "Read .INF file..." and then away from it you would have been left with the purple bars there too?
And if that guess was true, how would it look with the mouse cursor steady over one of the menu options before leaving it. Correctly inverted colors or also wrong? :)
(I am only guessing that where you have the purple bars you have already hovered the mouse over these entries? And the ones that are fine are fine because you have yet to mouse over them)

The small box under Disk C appears to be some other issue, or perhaps a different symptom of the same root cause.
Gut reaction, maybe a fillpattern blit where the pattern offset ended up wrong by a pixel, that could make the checkerboard not align in screenspace.
But the location of them are weird, unless one of the windows was there originally and then moved away -- leaving those lines?
(if so, then that reinforces the theory of misaligned source position for the fillpattern)

I had to re-remind myself what it does. The menu items are as normal until the mouse cursor passes over them. Upon closing they return to their normal colours once re-opened.

Hoping that's a good enough description :lol:

Posted: **20 Mar 2026 13:32**

Which Raven component governs the IDE interface?

Posted: **21 Mar 2026 06:22**

luciodra wrote: 20 Mar 2026 13:32 Which Raven component governs the IDE interface?

Should be U402

The readme in the FW directory says:
Iksi
- ATF22V10C 10ns : ym/mfp/ide control signals

Posted: **21 Mar 2026 08:38**

LarryL wrote: 21 Mar 2026 06:22
luciodra wrote: 20 Mar 2026 13:32 Which Raven component governs the IDE interface?
Should be U402

The readme in the FW directory says:
Iksi
- ATF22V10C 10ns : ym/mfp/ide control signals

While I was "experimenting" with biteswap I think I damaged the IDE in some way. Does not read data correctly both with and without BS. I prepare the partitions and copy the data and they appear corrupted with mismatched names (eg. rvbios.prg becomes rtvios.prg etc). Basically Raven is unusable.
I made many attempts:
- tried other sd and cf to ide adapters with various sd and cf;
- replaced and reprogrammed iksi and narnia;
- replaced MC68901 mfp;
-replaced YM.

All useless... any suggestions?

: IMG_2963.jpg (476.53 KiB) Viewed 1203 times

Posted: **23 Mar 2026 18:31**

luciodra wrote: 20 Mar 2026 13:32 Which Raven component governs the IDE interface?

This is not the answer you want but depending on how loosely we define governs, it could be several different things especially in the context of trying to troubleshoot and narrow down a problem.

Not all signals go through this exact chain but what would most directly be involved are these:
68060, 68150, Nessi, Iksi, transcievers (U103, U106)
(along with pullup or pulldown resistors connected to signals involved anywhere in the chain between CPU and IDE)

It's worth mentioning that many signals are shared among different things so the root of an error could be caused by something not obviously related to what one is investigating too (everything is guilty until proven innocent)

But as mentioned before, U402 (Iksi, ATF22V10) is the one that ultimately outputs the IDE control signals: RD, WR, CS0, CS1 on the IDE connector pins.
Directly on to the IDE connector there is also /RESET (from U108), parts of the address bus (from CPU) and the databus PD16..31 (from 68150).

U402 itself relies on inputs from other parts of the computer to generated those control signals though:
- IDECS signal from by U108 (Nessi, ATF1508)
- A5 on the CPU address bus
- RW signal generated by U104 (MC68150)
- DS signal generated by U104

MC68150 is choreographed by Nessi, both on the 68150<->68060 side and the 68150<->Peripheral side.
That chip governs the slower 16bit bus where IDE, YM, MFP1, MFP2 and ISA sits, and a fair few signals are shared between all those mentioned things.

Generally speaking, Nessi can be considered the puppet master for anything external to the CPU.
Either directly, or indirectly by controlling or cooperating with other chips in the chain between CPU <-> Thing

Sorry, I'm not sure this helped at all :/

Posted: **23 Mar 2026 20:58**

Hurray!
Thanks to your advice and after replacing everything I had arrived at the last two solutions: changing the CPU and the 68150. I made an attempt to reprogram Nessi and...bingo!
Raven lives again!

Thanks Anders and tell me if I can send you one of the network cards I have, with or without exchange. :D

exxos's Atari, Amiga & retro forum

Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer

Re: Raven. A homemade Atari-like computer