KMK/JZ IDEa Technical Help

[+bob1200xl]

No doubt that it works most everywhere else, but we have this one that does not. The RAM or ROM test fails, depending on the phase of the moon, or something. Considering the unusual select logic, I would suspect that first.

 

You know, there are usually dozens of possibilities. With no other input to filter them, you pick what seems to be the most likely and play with that. In many cases, these are all low-probability trials, with lots of other, equally unlikely, siblings.

 

If we can find one thing that fixes all the KMKs in the known universe, that would be good. Probably won't work that way, of course.

 

Bob

 

I used to have customers tell me that this machine works and that one does not, ergo, the non-working machine must be broken... even if the machine specs say it isn't supposed to work that way.

 

 

If the RAM and ROM are stepping on each other...

 

... then how does it work here?

[drac030]

If we can find one thing that fixes all the KMKs in the known universe, that would be good.

 

A side note: "KMK" is my nickname. I don't consider good if anyone wants to fix me. The device in question is called "IDEa".

[+bob1200xl]

Oh... I thought they were two versions of a PBI IDE interface.

 

My apologies.

 

People are part of the solution, not the problem. We don't fix people.

 

Bob

 

 

 

If we can find one thing that fixes all the KMKs in the known universe, that would be good.

 

A side note: "KMK" is my nickname. I don't consider good if anyone wants to fix me. The device in question is called "IDEa".

[flashjazzcat]

Sure, Bob - I can tie CS and OE together. So you're saying CS is enabled on both chips simultaneously in routine use, but OE on an individual basis, and that by tying CS and OE together we effectively cause OE to be low on both chips at once???

Edited December 7, 2010 by flashjazzcat

[+bob1200xl]

Looking at the schematic, it appears that chip-select (CS) on both RAM and ROM is active for the whole time that MPD is set. Output-enable (OE) is active on a select basis when you want data from one or the other. You can't just tie OE and CS together, then. (it will take a logic change to do that) You may be able to swap the two signals - where CS will be active by address selection and OE will be enabled by MPD. What I'm concerned about is the idea that the chip is selected during transition times. Even with OE disabled, all the internal circuits are active in the chip. The specs may call for a 30ns delay between OE and data, but that is a maximum - it could only take 5ns. Or, most chips work at 5ns and yours just happen to take 25ns. Or, worse, the two chips sit at the opposite ends of the timing window.

 

Do any of these tests tell you the expected and actual results? Can you pull the ROM and just run RAM tests? And, the other way around?

 

Bob

 

 

Sure, Bob - I can tie CS and OE together. So you're saying CS is enabled on both chips simultaneously in routine use, but OE on an individual basis, and that by tying CS and OE together we effectively cause OE to be raised on both chips at once???

[flashjazzcat]

Right: I see what you're getting at. Tying CS and OE together is only useful for the testing phase. I can't see the device being recognized by the diagnostic program without the ROM present, but I'll try it later. Maybe it'll work without the RAM.

 

Swapping the CS and OE signals would be a nifty trick if it worked. One way or another, I'm learning a lot here.

Edited December 7, 2010 by flashjazzcat

[BillC]

If we can find one thing that fixes all the KMKs in the known universe, that would be good.

 

A side note: "KMK" is my nickname. I don't consider good if anyone wants to fix me. The device in question is called "IDEa".

It is your own fault people call it that.

 

The following is a quote from the foreword of the manual available at http://drac030.krap.pl/KMKJZ-manual.pdf

 

The KMK/JŻ IDE Interface allows you to attach an ATA (IDE) hard drive, a

CF (Compact Flash) card or an ATAPI device (e.g. a CD-ROM drive) to your

Atari 130XE computer.

[flashjazzcat]

He has a point. The nomenclature for the two versions of the same device is also somewhat confusing. Is the KMK/JZ an IDEa at all? Or is it the KMK/JZ IDE Interface?

Edited December 7, 2010 by flashjazzcat

[flashjazzcat]

OK: I tried lifting the CS pins on both ROM/RAM and individually (tying them to OE and/or WE of the same chip) and the system won't boot in this configuration. Does there have to be a tiny delay between CS and OE/WE?

 

Also: With RAM pulled, computer will boot and KMKDIAG fails on Bank #0 of the ROM stability test (and - naturally - the RAM test) and then aborts.

 

Additionally: has anyone got a schematic of the second version (KMK/JZ) of this board? The JPEG I posted here refers to the first version which uses discreet logic chips instead of GALs. I have a DBB file of the second version, but I'm having to jump through fiery hoops to open it up...

Edited December 7, 2010 by flashjazzcat

[drac030]

It is your own fault people call it that.

 

Now it will be their fault

 

@fjc: this is not even the same device. These are two devices, built by different people. But they behave as one, because IDEa is a clone of the KMK/JŻ IDE.

[flashjazzcat]

...this is not even the same device. These are two devices, built by different people. But they behave as one, because IDEa is a clone of the KMK/JŻ IDE.

That quickly became apparent after comparing the board with the schematic. That's why we need a readable schematic of the IDEa. Pigula should surely have one, somewhere... some time...

Edited December 7, 2010 by flashjazzcat

[+bob1200xl]

Your interfaces have GALs? What devices are they? That would be nice since you can just re-program the logic in them. Of course, you need the schematic and the logic files.

 

Normally you tie CS and OE together. Look at all the ROMs in the Atari 8-bits. You do not need any delays or such.

 

If the ROM test fails with the RAM pulled, then they are not in conflict. Did you try just swapping the OE and CS pins on the ROM with the RAM out of circuit?

 

Does the ROM test give you expected/actual results? An address?

 

Bob

 

 

 

 

 

OK: I tried lifting the CS pins on both ROM/RAM and individually (tying them to OE and/or WE of the same chip) and the system won't boot in this configuration. Does there have to be a tiny delay between CS and OE/WE?

 

Also: With RAM pulled, computer will boot and KMKDIAG fails on Bank #0 of the ROM stability test (and - naturally - the RAM test) and then aborts.

 

Additionally: has anyone got a schematic of the second version (KMK/JZ) of this board? The JPEG I posted here refers to the first version which uses discreet logic chips instead of GALs. I have a DBB file of the second version, but I'm having to jump through fiery hoops to open it up...

[flashjazzcat]

2 x GAL16V8D / 15LPN. It would be nice - if my programmer would write GALs properly. It won't.

 

The ROM failure varies but is generally in the $D9xx region. The machine wouldn't boot with OE and CS tied/swapped (yet), so I wasn't able to run tests, and also wasn't able to test with the RAM out of circuit with anything other than standard ROM pin configuration.

 

A problem I can see is that tying OE and CS is all well and good with the ROM, but since the RAM has both write and read select, surely they need to be mutually exclusive? Or perhaps not...

Edited December 7, 2010 by flashjazzcat

[+bob1200xl]

If the machine comes up with the RAM out of the socket, you should try to fix the ROM problem without worrying about the RAM. Can you write a little routine to scan a block of ROM ($D9xx) and compare it to the last read? Read the ROM and store the data in a block of main RAM - compare the second read with the data stored from the first read... stop if it does not compare. Loop until failure.

 

You'll either get random garbage (boooo...), a bit picking or dropping, or $FF on the read. Probably...

 

Bob

 

The RAM is active when CS is asserted (and drawing full power), drives data onto the buss on a read if OE is asserted, or takes data from the buss if WE is asserted. OE is disabled if WE is active. The normal sequence should be: WE is active at the start of the Phase2 cycle and stays active until the cycle ends. CS and OE are brought up in the middle of the cycle, after all the addresses and data are stable. They all drop at the end of the cycle. (or stay up for the next cycle - it's hard to tell sometimes)

 

 

2 x GAL16V8D / 15LPN. It would be nice - if my programmer would write GALs properly. It won't.

 

The ROM failure varies but is generally in the $D9xx region. The machine wouldn't boot with OE and CS tied/swapped (yet), so I wasn't able to run tests, and also wasn't able to test with the RAM out of circuit with anything other than standard ROM pin configuration.

 

A problem I can see is that tying OE and CS is all well and good with the ROM, but since the RAM has both write and read select, surely they need to be mutually exclusive? Or perhaps not...

[flashjazzcat]

If the machine comes up with the RAM out of the socket, you should try to fix the ROM problem without worrying about the RAM. Can you write a little routine to scan a block of ROM ($D9xx) and compare it to the last read? Read the ROM and store the data in a block of main RAM - compare the second read with the data stored from the first read... stop if it does not compare. Loop until failure.

 

You'll either get random garbage (boooo...), a bit picking or dropping, or $FF on the read. Probably...

That's pretty much what the KMKDIAG program does. With the RAM pulled, the stability test craps out at $D9xx in just the same way it does when the RAM is present. Bank #2 of the ROM passes the test.

 

Note that all this is with no jumpers or tied EPROM legs. I've already broken a pin on the original PROM, and now I'm using a 512 bit EPROM with four legs bent up because the only 64 bit EPROM I have (which I bought new) I won't program for some reason. If I damage the 512 bit EPROM, my experiments will come to an abrupt end, at least until I find some more suitably cheap (E)EPROMs on eBay.

 

Pigula replied to my email, and although his reply was detailed the only new piece of information was his suggestion that while 15ns GALs are good, 25ns GALs are somehow better. My board has 15ns GALs. I can't program any GALs since my chip programmer doesn't seem to like them.

 

So the single constant factor remains that Bank #0 of the ROM always fails in the $D9xx-$DBxx region, with or without the RAM, while bank #1 always passes.

 

Of course, let's not forget the other 130XE, on which the ROM always passes the stability tests, while the RAM fails.

 

The solder joins on the underside of the (uncased) IDEa have literally worn grooves in the top of the desk where I have plugged the board into the back of the Atari about 200 times over the past three months or so...

 

I might come back to this with a clearer head later in the week.

 

I also tested the unit again with three other XE machines: in all cases, the stability test detected ROM errors in Bank #0. In one instance, errors were detected in ROM banks 0 and 1, and RAM bank #0.

 

Pigula tells me out of four machines he tried his IDEa in, the adapter worked in only one. Well, I've tried four and it works in none. I am inclined to suspect the board is defective in ways I lack the time, energy (and - as time goes on - the enthusiasm) to diagnose.

Edited December 7, 2010 by flashjazzcat

[+bob1200xl]

As I scrap out old computer circuit boards, I pull the EPROMS and anything else that looks interesting. So, I have quite a few EPROMs that I could send you, if you're interested. A flat rate box would cost $14 and hold at least a dozen EPROMs.

 

Yes, tell me about enthusiasm... I do this for a living, so I'm a little better prepared than most people.

 

Bob

 

 

If the machine comes up with the RAM out of the socket, you should try to fix the ROM problem without worrying about the RAM. Can you write a little routine to scan a block of ROM ($D9xx) and compare it to the last read? Read the ROM and store the data in a block of main RAM - compare the second read with the data stored from the first read... stop if it does not compare. Loop until failure.

 

You'll either get random garbage (boooo...), a bit picking or dropping, or $FF on the read. Probably...

That's pretty much what the KMKDIAG program does. With the RAM pulled, the stability test craps out at $D9xx in just the same way it does when the RAM is present. Bank #2 of the ROM passes the test.

 

Note that all this is with no jumpers or tied EPROM legs. I've already broken a pin on the original PROM, and now I'm using a 512 bit EPROM with four legs bent up because the only 64 bit EPROM I have (which I bought new) I won't program for some reason. If I damage the 512 bit EPROM, my experiments will come to an abrupt end, at least until I find some more suitably cheap (E)EPROMs on eBay.

 

Pigula replied to my email, and although his reply was detailed the only new piece of information was his suggestion that while 15ns GALs are good, 25ns GALs are somehow better. My board has 15ns GALs. I can't program any GALs since my chip programmer doesn't seem to like them.

 

So the single constant factor remains that Bank #0 of the ROM always fails in the $D9xx-$DBxx region, with or without the RAM, while bank #1 always passes.

 

Of course, let's not forget the other 130XE, on which the ROM always passes the stability tests, while the RAM fails.

 

The solder joins on the underside of the (uncased) IDEa have literally worn grooves in the top of the desk where I have plugged the board into the back of the Atari about 200 times over the past three months or so...

 

I might come back to this with a clearer head later in the week.

 

I also tested the unit again with three other XE machines: in all cases, the stability test detected ROM errors in Bank #0. In one instance, errors were detected in ROM banks 0 and 1, and RAM bank #0.

 

Pigula tells me out of four machines he tried his IDEa in, the adapter worked in only one. Well, I've tried four and it works in none. I am inclined to suspect the board is defective in ways I lack the time, energy (and - as time goes on - the enthusiasm) to diagnose.

[flashjazzcat]

As I scrap out old computer circuit boards, I pull the EPROMS and anything else that looks interesting. So, I have quite a few EPROMs that I could send you, if you're interested. A flat rate box would cost $14 and hold at least a dozen EPROMs.

Very interested, Bob. This board has cost me upwards of 100GBP so far (purchase, shipping, customs charges, parts), so $12 on a few EPROMs seems a sound investment.

 

Send me a PM with Payment details when you get a chance, and I'll shoot you my postal address.

 

I'm also watching a couple of static RAM chips. If I get one on the cheap, it's all grist to the mill.

Edited December 8, 2010 by flashjazzcat

[flashjazzcat]

It appears I wasn't using Seban's test program properly (the IDEa was supposed to be set as PBI #1).

 

Output:

 

 

The bitmap at the top (ROM) doesn't change at all. The areas below (RAM), however, have four fixed "holes" in them (value $00).

 

These offsets from the base of RAM are:

 

$0D3

$0E8

$0EB

$15A

 

Running KMKDIAG again, here's a sample of ROM verify failure addresses:

 

$DBF9

$DBED

$DBED

$D9E8

$DBFB

$D9E8

$DBCF

$DBED

$DBED

Edited December 8, 2010 by flashjazzcat

[+bob1200xl]

Well, I've got lots of those, too. Which ones? You might as well stock up since it all costs the same.

 

Bob

 

 

 

As I scrap out old computer circuit boards, I pull the EPROMS and anything else that looks interesting. So, I have quite a few EPROMs that I could send you, if you're interested. A flat rate box would cost $14 and hold at least a dozen EPROMs.

Very interested, Bob. This board has cost me upwards of 100GBP so far (purchase, shipping, customs charges, parts), so $12 on a few EPROMs seems a sound investment.

 

Send me a PM with Payment details when you get a chance, and I'll shoot you my postal address.

 

I'm also watching a couple of static RAM chips. If I get one on the cheap, it's all grist to the mill.

[+bob1200xl]

What am I looking at, here? What is the significance of the 5s and 4s? Which part is ROM? I suspect that this RAM test is writing all 5s to memory, which may mean that something like 57 addresses fail by dropping bit 5 and 4 addresses fail by dropping both bit 5 and 7.

 

Can you write a quickie test?:

 

lda #$01 ;PBI device #1?

sta $d1ff

lda $(one of the failing ROM addresses)

sta $600

lda #$00

sta $d1ff ;turn off PBI

brk

 

Run that from ASM/ED and look in $600 to see what is read from the ROM at that location. You can add code to compare the data in $600 (after the first read) with what is read and if no compare, store that value in $610. Store the next mis-compare in $620 if the next read does not match either $600 or $610.

 

You can go on like that until you get 8 or F failures...

 

Bob

 

 

It appears I wasn't using Seban's test program properly (the IDEa was supposed to be set as PBI #1).

 

Output:

 

 

The bitmap at the top (ROM) doesn't change at all. The areas below (RAM), however, have four fixed "holes" in them (value $00).

 

These offsets from the base of RAM are:

 

$0D3

$0E8

$0EB

$15A

 

Running KMKDIAG again, here's a sample of ROM verify failure addresses:

 

$DBF9

$DBED

$DBED

$D9E8

$DBFB

$D9E8

$DBCF

$DBED

$DBED

[flashjazzcat]

To tell you the truth I still have scant ideas (no pun intended) of what the output of that test program is supposed to signify. Top part is ROM, I think.

 

EDIT: Candle explains:

 

area at the top is xor pattern, and should display nice "animation"

area at bottom is memory error locations counters - each increase of value (char on screen) means that in that particular address reads and writes to memory are failing

if you have such display as on your picture, this mean that you have four valid bytes of ram there, and rest is garbage

 

Test results of a few runs of my hastily written SDX test app:

 

 

Grim reading. The top entries (obscured by the reflected light) are:

 

$DBC9: old $FF, new $04

$DBFF: old $C8, new $FF

$DDEA: old $FF, new $A5

 

The program simply loops through the PBI ROM, reads a value for each location, stores it, reads the ROM location again, and compares it with the saved value.

 

The only chips I found for sale online which would be useful in the IDEa are Hitachi HM6116-3 static RAMs. The board has a UM6116-3 in it right now.

Edited December 8, 2010 by flashjazzcat

[+bob1200xl]

Yes! That tells us what's happening. When you 'read' a $FF, it says that you didn't select the chip - either OE or CS was not active when the CPU latched the data. So, one time you read real data, say $3B, and the next you get $FF - no chip selection. If slower GALs make it better, then the GAL is probably dropping OE or CS too soon. (dropping OE, in particular, de-gates the buss in less than 10ns) Since CS is active continuously while MPD is active, I vote for OE!

 

Except... they buffer the data through a gate, which has to set gating and direction. We'll have to consider that, also. (I would try just jumpering that gate, actually) (but I have no fear... and, a ton of parts)

 

Do we have the GAL files? I could burn some slower chips and you could try that.

 

Bob

 

 

To tell you the truth I still have scant ideas (no pun intended) of what the output of that test program is supposed to signify. Top part is ROM, I think.

 

EDIT: Candle explains:

 

area at the top is xor pattern, and should display nice "animation"

area at bottom is memory error locations counters - each increase of value (char on screen) means that in that particular address reads and writes to memory are failing

if you have such display as on your picture, this mean that you have four valid bytes of ram there, and rest is garbage

 

Test results of a few runs of my hastily written SDX test app:

 

 

Grim reading. The top entries (obscured by the reflected light) are:

 

$DBC9: old $FF, new $04

$DBFF: old $C8, new $FF

$DDEA: old $FF, new $A5

 

The program simply loops through the PBI ROM, reads a value for each location, stores it, reads the ROM location again, and compares it with the saved value.

 

The only chips I found for sale online which would be useful in the IDEa are Hitachi HM6116-3 static RAMs. The board has a UM6116-3 in it right now.

[+David_P]

If you're looking for 6116s - take a gander at: http://futurlec.com/ICRAM.shtml They have them for $2.20 USD each (+ shipping); they've got a wide variety of other components as well.

 

They ship out of Thailand, as I recall, so expect to wait 3-4 weeks.

[flashjazzcat]

Do we have the GAL files? I could burn some slower chips and you could try that.

We do. I'll PM them later on...

 

If you're looking for 6116s - take a gander at: http://futurlec.com/ICRAM.shtml They have them for $2.20 USD each (+ shipping); they've got a wide variety of other components as well.

 

They ship out of Thailand, as I recall, so expect to wait 3-4 weeks.

Duly noted: thank you.

[flashjazzcat]

Phew... had to install a licensed trial of Altium designer to get at the schematic. Both GAL JED files and PDF schematic here:

 

IDEa_GALs_and_Schematic.zip