Welcome, Guest. Please login or register.


Author Topic: MICROTEAM card DRAM problem (Read 5614 times)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
MICROTEAM card DRAM problem
« on: 2014.November.24. 23:56:49 »
I found the problem: one of my memory expansions! The first preview only used 128k. Now using 1M...
If I remove this RAm expansion, or create a big RAMDISK, then SymbOS runs at any turbo mode (except floppy access).
Very strange what is the problem with this RAM, I never see any problem with it...
How can build RAM test from SymbOS code? :-D

With this RAM hang up before desktop displayed at booting, or in a few seconds if switched while running. Very-very strange!

Offline Prodatron

  • EP user
  • *
  • Posts: 256
  • Country: de
  • Back on the Z80
    • http://www.symbos.de
Re: MICROTEAM card DRAM problem
« Reply #1 on: 2014.November.25. 00:07:53 »
I found the problem: one of my memory expansions! The first preview only used 128k. Now using 1M...
If I remove this RAm expansion, or create a big RAMDISK, then SymbOS runs at any turbo mode (except floppy access).
Very strange what is the problem with this RAM, I never see any problem with it...
How can build RAM test from SymbOS code? :-D

With this RAM hang up before desktop displayed at booting, or in a few seconds if switched while running. Very-very strange!

Ah, thanks for your investigation! How is this expansion structured? How are the 16K blocks placed? Maybe my 4x16K "find" routine is failing in some cases?

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #2 on: 2014.November.25. 08:41:11 »
Ah, thanks for your investigation! How is this expansion structured? How are the 16K blocks placed? Maybe my 4x16K "find" routine is failing in some cases?
It is a 256K (8x41256 chips), at 40-4Fh.
But I think not a software problem, because at 4Mhz working.
But what a strange hw problem which is not discovered under about 22 years? :shock:

If least two segments free from this area (4Eh,4Fh, other RAMs at other location not continous) then also freeze on turbo, if one (4Fh), then working.
Can you specify what the SymbOS do with these segments in these situations?
I guess when the only one free then it is not used. When two free it is used for Bank 0?

Can you compile me two test version, BFh port value with 0 and another with 4? Try to play with different wait states settings :-)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: MICROTEAM card DRAM problem
« Reply #3 on: 2014.November.25. 11:03:14 »
Hmm, maybe the SymbOS loader in this early stage should ask the user about the BF port, and such things, so testers can try various things out instead of asking specific builds all the time :) But it's just an idea anyway.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #4 on: 2014.November.25. 11:11:44 »
And the next step, the boot loader write detailed dump of the booting process, see where is the problem :-)
When found the problematic parts then put to standalone memory test :-)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: MICROTEAM card DRAM problem
« Reply #5 on: 2014.November.25. 11:42:17 »
Well a detailed "boot log" is useful, also with Linux for example and what I miss in some OSes :-)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #6 on: 2014.November.25. 23:06:14 »
Can you compile me two test version, BFh port value with 0 and another with 4? Try to play with different wait states settings :-)
I do with modify the SYM file :-) But it is don't change anything...
But I can reproduce the problem with another MICROTEAM EXDOS card!

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #7 on: 2014.November.25. 23:59:06 »
@LGB: That's a good idea, but unfortunately exactly in the important part of the boot process there is no room for screen/disc logging routines :/
A little idea: changing border colour? It needs only a few bytes. (And just for now for testing purpose, it can be removed from the final version)
« Last Edit: 2014.December.16. 14:08:53 by szipucsu »

Offline Prodatron

  • EP user
  • *
  • Posts: 256
  • Country: de
  • Back on the Z80
    • http://www.symbos.de
Re: MICROTEAM card DRAM problem
« Reply #8 on: 2014.November.26. 11:00:23 »
Ok, I will do the border trick during loading/initialisation, so we can try to find out, where it hangs.

The problem which has been fixed was a wrong banking when defining colours. Sometimes it happend, sometimes not, so I was wondering, if this would happen more often on faster systems. But ok, it's still something else.

Changing blocks with #b0-#b3 doesn't require any delays? You can access the new memory as soon as the banking has been done, correct?
SymbOS often switches #b0 while the Z80 is executing code exactly in this area (#0000-#3fff). But this shouldn't be a problem on faster systems?

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #9 on: 2014.November.26. 11:28:22 »
Ok, I will do the border trick during loading/initialisation, so we can try to find out, where it hangs.
Thanks! I'm very curious what do this very strange problem. :shock:

Quote
Changing blocks with #b0-#b3 doesn't require any delays? You can access the new memory as soon as the banking has been done, correct?
SymbOS often switches #b0 while the Z80 is executing code exactly in this area (#0000-#3fff). But this shouldn't be a problem on faster systems?
Yes, no delay needed.
About the delays: my first guess the M1 cycles which are shorter than the normal RAM access. But all softwares worked with these expansion in more than 20 years, also with no addtional wait states.
But I tried it yesterday the other two wait state settings, 1 wait state at each M1 cycle, or 1 wait state at all memory access. (4 or 0 BFh port value) But this is don't change anything.

But I start thinking... lot of programs do page switching, also on P0. But possible not often as the SymbOS?
Can you specify which segments used on Page0, for example when memory at 40-5Fh, and F8h-FFh.

For example switching 4xh and Fxh will stress the high address lines. If some delay for these in the expansion probably can be do the problem.

Offline BruceTanner

  • EP lover
  • *
  • Posts: 607
  • Country: gb
Re: MICROTEAM card DRAM problem
« Reply #10 on: 2014.November.26. 11:43:21 »
Or could be some interrupt-sensitive code during initialisation? On slow machines the first interrupt happens before the critical code reached so ok, on fast machines the interrupt happens during the critical code, maybe when is something partially initialised?

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #11 on: 2014.November.26. 11:51:42 »
Or could be some interrupt-sensitive code during initialisation? On slow machines the first interrupt happens before the critical code reached so ok, on fast machines the interrupt happens during the critical code, maybe when is something partially initialised?
No, it is only depend from the RAM expansion type. Currently 3 MICROTEAM card tested, and 2 do the problem, when the DRAM expansion used on more than 4MHz. One of them  also have SRAM expansion, then no problem when the SRAM segments used. Also not problem when the internal 1M (from Saint) used. I will try more configurations.

Then I think the problem not with code. Just the SymbOS do something what the previously existing softwares not. This is why not discovered the problem many-many years ago.
And when the problem identified I want to add test routine for this to my Advanced Memory Test.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #12 on: 2014.November.26. 12:38:54 »
SymbOS often switches #b0 while the Z80 is executing code exactly in this area (#0000-#3fff). But this shouldn't be a problem on faster systems?
Now I looked it in ep128emu debbuger, but never see really change at B0h! It is outputing but same value as previous.
I think it is because the CPC paging emulation, then all four page registers written at all paging change.
But as I see in memory map documentation, in the most of cases the Bank 0 Block 0 stay on Z80 Page 0. If I think right only at some big applications use Bank n Block 0 to Page 0.
In the pure deskto loaded I don't change at Page 0.

Is any frequent page change while code running on other pages?

Offline BruceTanner

  • EP lover
  • *
  • Posts: 607
  • Country: gb
Re: MICROTEAM card DRAM problem
« Reply #13 on: 2014.November.26. 12:47:37 »
And when the problem identified I want to add test routine for this to my Advanced Memory Test.

Does your advanced memory test run code from the memory it is testing? (After testing with data of course)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #14 on: 2014.November.26. 13:24:10 »
Does your advanced memory test run code from the memory it is testing? (After testing with data of course)
No.
Now thinking about how to create code running test :-) I think if found the problematic part of the SymbOS will be good begin for the test routine :-)