Welcome, Guest. Please login or register.


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

Offline BruceTanner

  • EP user
  • *
  • Posts: 484
  • Country: gb
  • OS:
  • Windows NT 6.3 Windows NT 6.3
  • Browser:
  • Chrome 39.0.2171.65 Chrome 39.0.2171.65
    • View Profile
Re: MICROTEAM card DRAM problem
« Reply #15 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:

Offline Prodatron

  • EP fan
  • *
  • Posts: 249
  • Country: de
  • Back on the Z80
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://www.symbos.de
Re: MICROTEAM card DRAM problem
« Reply #16 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 :)

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13374
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #17 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 :-)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://lgb.hu/
Re: MICROTEAM card DRAM problem
« Reply #18 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 :)

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13374
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #19 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...

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://lgb.hu/
Re: MICROTEAM card DRAM problem
« Reply #20 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 ...

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13374
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 33.0 Firefox 33.0
    • View Profile
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #21 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:

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 34.0 Firefox 34.0
    • View Profile
    • http://lgb.hu/
Re: MICROTEAM card DRAM problem
« Reply #22 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" :)

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13374
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 34.0 Firefox 34.0
    • View Profile
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #23 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?

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 34.0 Firefox 34.0
    • View Profile
    • http://lgb.hu/
Re: MICROTEAM card DRAM problem
« Reply #24 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 ....

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13374
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 34.0 Firefox 34.0
    • View Profile
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #25 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.

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 34.0 Firefox 34.0
    • View Profile
    • http://lgb.hu/
Re: MICROTEAM card DRAM problem
« Reply #26 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.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13374
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 34.0 Firefox 34.0
    • View Profile
    • http://enterprise.iko.hu/
Re: MICROTEAM card DRAM problem
« Reply #27 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