Enterprise Forever

:UK => Hardware => Topic started by: Zozosoft on 2014.November.24. 23:56:49

Title: MICROTEAM card DRAM problem
Post by: Zozosoft 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!
Title: Re: MICROTEAM card DRAM problem
Post by: Prodatron 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?
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft 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 :-)
Title: Re: MICROTEAM card DRAM problem
Post by: lgb 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.
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft 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 :-)
Title: Re: MICROTEAM card DRAM problem
Post by: lgb 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 :-)
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft 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! (http://gafz.enterpriseforever.com/Galery/Bovitmenyek/Picture/EXDOS_Microteam-ISS4~1.jpg)
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft 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)
Title: Re: MICROTEAM card DRAM problem
Post by: Prodatron 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?
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft 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.
Title: Re: MICROTEAM card DRAM problem
Post by: BruceTanner 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?
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft 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.
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft 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?
Title: Re: MICROTEAM card DRAM problem
Post by: BruceTanner 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)
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft 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 :-)
Title: Re: MICROTEAM card DRAM problem
Post by: BruceTanner on 2014.November.26. 14:29:05
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 :-)
The simple way of course is to just copy some code there and call it, but if it crashes so does the memory test. The complicated way would be to use an interrupt routine to monitor the copied code and recover back to the memory test if the copied code crashes :evil: :shock:
Title: Re: MICROTEAM card DRAM problem
Post by: Prodatron on 2014.November.26. 15:05:30
@Bruce: It shouldn't be the interrupt, as it is locked as long as the initialization isn't finished.

Now I looked it in ep128emu debbuger, but never see really change at B0h! It is outputing but same value as previous.
Usually you will always see the same page here (part of the kernel "bank 0"). Start the screensaver (scrstars.sav), in this case it will be mostly in a secondary bank and switch back to bank 0 on each v sync.
Anyway I also think that it's another problem: During initialisation the page at 0000-3fff is always the same. Ok, I will hurry up with the "border colour"-debug-version :)
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft on 2014.December.02. 10:19:09
I moved this thread to new HW topic, because it is a hardware problem not a SymbOS problem.
SymbOS just a great test program for the problem :-)
Title: Re: MICROTEAM card DRAM problem
Post by: lgb on 2014.December.02. 11:17:06
Maybe, it's a good reason to write more advanced memory tests :) I mean not just read/write etc tests, but also rapid memory paging meanwhile etc, I don't know if it can be tested with a specific tester at all. If a memory tester can be written which triggers a bug like SymbOS did, it can be useful later to test machines, both of old and new memory expansions, etc etc. And at least someone can be very sure it's not SymbOS problem then of course, at a 100% level :)
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft on 2014.December.02. 11:22:07
Gflorez's card make a "white" border with the border colour debugging SymbOS, it is means freeze at very early phase.
(When using the DRAM segments, and more than 4MHz)

Firstly I replaced the 150ns chips to 80ns (near to 2x faster), but not change to many, it is generate broken screen (little more running than the white border).

Then I replace two 74HCT08 to 74ACT08, and the multiplexers (2x ...157, 1x ...153) to 74F series.
Now it is stable running SymbOS at 7.12MHz :ds_icon_cheesygrin:

For a 10MHz probably need to buy more 74F series chips :oops:


Ok, I can fix the strange problem, but don't know what is the problem :shock: and how can write test for this...
Title: Re: MICROTEAM card DRAM problem
Post by: lgb on 2014.December.02. 12:17:53
The problem can be simply the propogation delay of those logic ICs, so with faster one it works. Though a single HC/HCT type 74xx IC should be enough I guess, if you chain some ICs together (output of one is used as the input of another, etc), the combined delay of the logic network can be simply too much for 7.12MHz, or can be at the limit, thus being not stable too much. Also, the delays caused by ICs inside EP should count as well, producing the signals used on the card. Well, data sheets should be checked about the exact situation :-P Also, long wires or PCB traces, not so optimal PCB layout etc can increase the capacity of the bus system which deforms the signals, thus giving too short stable state for slower ICs but may work with faster ones still (even if the key problem is not about these ICs but the wiring, etc?). Sorry, just general thoughts in a situation like this, maybe this is not the case here ...
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft on 2014.December.02. 12:25:11
The strange part of problem: enabling wait states don't change anything.
And my card used on 7.12Mhz, from about 1993, and until SymbOS no problem found :oops:
Title: Re: MICROTEAM card DRAM problem
Post by: lgb on 2014.December.03. 10:57:49
The strange part of problem: enabling wait states don't change anything.
And my card used on 7.12Mhz, from about 1993, and until SymbOS no problem found :oops:

I see. Interesting. No idea too much then ... I guess there can be something in SymbOS which "stretches" the system (or only one component) more than other EP softwares so it can trigger the problem. But now we're again at the point that "no idea" :)
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft on 2014.December.17. 00:21:54
On my card from the original components replaced two 74HCT08 to 74F08, and the address multiplexers: 2x74HCT157+1x74HCT153 to 2x74F157+1x74F153.
And looks working up to 10MHz! :ds_icon_cheesygrin:

I try similar on Gflorez's card, but not successful :-( On 10Mhz the SymbOS halt at two dots at second line.
I also tried change more IC to 74F, and also tried with my address decoder PROM.

I think the main difference the RAM chips, but there is the strange things: Gflorez card have a MN41256-08 (80ns) ICs, my card have HY53C256-10 (100ns) ICs.
My are the slower, but working on 10Mhz... probably because these are CMOS?
Title: Re: MICROTEAM card DRAM problem
Post by: lgb on 2014.December.17. 00:52:43
Hmm, interesting. I am far from being an expert, however I think the TTL or CMOS level logic values can mean difference. Another thought (which can be false ...) CMOS ICs may cause less load on the bus compared to NMOS/TTL versions, eg "at the old days" CPUs like Z80, 6502 are always surrounded by bus drivers, but it's not so much needed today with CMOS only ICs (but it's also true that a hobby user today would use a single CMOS SRAM, while in the old days we had "tons" of DRAMs to form the memory which caused much more load and not even CMOS ones, etc). Also, mixing CMOS and TTL logic levels surely can cause interesting happenings sometimes. But please note, that I am just guessing here.

By the way, the "typical" propagation delays (according to the daya sheets) for 74HC08, 74HCT08 and 74F08 at 5V are (ns): 7, 11, 4.2. The difference between HC and HCT is that HCT has TTL level inputs, afaik something built in pull-up resistor or so (?), but it causes somewhat slower than HC. HC/HCT being CMOS uses less power and generally not much slower than LS, however CMOS things in general uses more and more power with frequency increasing and there is a point when an LS IC can be more efficient already.

The mentioned  HY53C256-10 seems to be CMOS indeed, according to the data sheet, the inputs are TTL compatible anyway. So if you try the same with Gflorez's card (which uses even faster RAM but not CMOS), then I can only think about that a more modern kind of technology (CMOS) can "interpret" not so perfect signals as well at higher frequency, or whatever. Maybe the higher impedance of inputs (caues less loads). Well, I guess these cards are not designed for 10MHz originally ....
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft on 2014.December.17. 01:04:23
Another thought (which can be false ...) CMOS ICs may cause less load on the bus compared to NMOS/TTL versions
Yes, but these RAM ICs don't connected to the computer bus directly. (And also use less power, voltage regulator make a less heat).

Both card have a 74HCT ICs when started the SymbOS testing. Gflorez's card have a TMS 4125-15 (150ns) RAM ICs, I replaced these to the 80ns ones. After this changes (two 74HCT08 also changed to 74ACT08) started working with SymbOS up to 7.12Mhz.
Title: Re: MICROTEAM card DRAM problem
Post by: lgb on 2014.December.17. 12:50:09
Hmm, btw, is there a table anywhere to get to know what time the system has to respond a memory (and I/O too would be nice) r/w request for a given clock frequency? On 65xx it's quite easy, as you have one half of a clock period, so for 1MHz it's 500ns, 10MHz is 50ns (for sure, it's not the speed of needed RAM, as logic ICs cause some delay too, etc etc) ... But I don't know about Z80 exactly.
Title: Re: MICROTEAM card DRAM problem
Post by: Zozosoft on 2014.December.17. 14:54:29
In M1 cycle (instruction reading) are 1.5 clock cycles, which are 250*1.5=375ns at 4Mhz.
6Mhz 250ns, 7.12Mhz 210ns, 10Mhz 150ns