KMK/JZ IDEa Technical Help

[flashjazzcat]

Having purchased (second-hand, but as new and unused) a KMK/JZ (IDEa) IDE interface, I've had about twenty minutes of stable use out of the unit in three months. The infamous Phi2 timing problem hardly explains why the unit fails to work on any one of four XE machines (both modded and unmodded). The unit frequently causes what MetalGuy66 has referred to as "abstract art" on the Atari's screen, and the rest of the time is a mystery-tour of I/O errors and lock-ups. The unit did, however, show signs of working stably around a month ago, and I was inspired to purchase a very nice black project box for it (kind of like a mini-MIO) which is now gathering dust on the shelf since the interface decided to act up again.

 

Fortunately, I've spent around 200 man-hours writing a MyIDE driver for SpartaDOS X, and - now that I'm used to parallel I/O speeds - I'm obliged to continue using the MyIDE, which, although faster than the KMK/JZ, is something of a hack and is not bootable. Nor does it have a cartridge pass-through.

 

I have no argument whatsoever with the forum member from whom I bought the device, and I'm wise enough to realize that any retro-computer equipment has a certain load of caveats attached to it, such is the variance and age of the computers the interfaces are designed to work with. However, the interface represents a considerable investment in what I thought to be a highly desirable piece of equipment, and therefore consigning it to the skip is hardly an option, regardless of how many new and improved interfaces may be around the corner.

 

An email from another KMK/JZ user now having problems with a previously working device has prompted me to open this topic. So far, the problems with my interface have foxed the minds of our most pre-eminent experts, and I am thus far unable to contact Pigula, the original manufacturer of my device. Three variations of Phi2 mod have failed to alleviate my problems, and in any case: the device did work for a short while with the same system.

 

I have gone to the lengths of ordering a replacement 50 way ribbon cable to see if that helps. However, Drac030 assures me that the fact the interface fails to pass the IDEa stability test is BAD news. I feel confident enough to action basic diagnostics and repairs on the unit. However, I am currently at a complete loss as to how to proceed. The forum member who has emailed me reporting stability problems with his (infrequently used) unit would also appreciate the pooling of ideas.

 

Perhaps anecdotal information from KMK/JZ users would be a useful place to start, since I appreciate that no-one is likely to magically appear with a solution.

[8bitguy1]

There is a thread a ways back where Draco and Metalguy (been the excellent Atarians they are) tried to help me troubleshoot my KMK/JZ device, it doesn't sound like your having the exact same issues, but mine has never been stable. I sent it back to the original builder (which means the device has crossed the Atlantic twice more then I ever have) and he changed out some resistors, that however, didn't alleviate the stability issues. I have never been able to get my device to work for more then 30 minutes, so I gave up.

 

This isn't meant to discourage you, I've been thinking about trying to repair mine again, so I will follow this thread with interest, and post any discoveries I make. Anywayz....I share your frustration.

[+bob1200xl]

Do we have any documentation on the hardware and PBI code? If you boot up ASM/ED and scan $D1xx, what seems to be the addresses for the interface? (which locations are not $FF?) It may be useful to write your own tests for the interface that work directly with the hardware regs.

 

Bob

 

 

 

Having purchased (second-hand, but as new and unused) a KMK/JZ (IDEa) IDE interface, I've had about twenty minutes of stable use out of the unit in three months. The infamous Phi2 timing problem hardly explains why the unit fails to work on any one of four XE machines (both modded and unmodded). The unit frequently causes what MetalGuy66 has referred to as "abstract art" on the Atari's screen, and the rest of the time is a mystery-tour of I/O errors and lock-ups. The unit did, however, show signs of working stably around a month ago, and I was inspired to purchase a very nice black project box for it (kind of like a mini-MIO) which is now gathering dust on the shelf since the interface decided to act up again.

 

Fortunately, I've spent around 200 man-hours writing a MyIDE driver for SpartaDOS X, and - now that I'm used to parallel I/O speeds - I'm obliged to continue using the MyIDE, which, although faster than the KMK/JZ, is something of a hack and is not bootable. Nor does it have a cartridge pass-through.

 

I have no argument whatsoever with the forum member from whom I bought the device, and I'm wise enough to realize that any retro-computer equipment has a certain load of caveats attached to it, such is the variance and age of the computers the interfaces are designed to work with. However, the interface represents a considerable investment in what I thought to be a highly desirable piece of equipment, and therefore consigning it to the skip is hardly an option, regardless of how many new and improved interfaces may be around the corner.

 

An email from another KMK/JZ user now having problems with a previously working device has prompted me to open this topic. So far, the problems with my interface have foxed the minds of our most pre-eminent experts, and I am thus far unable to contact Pigula, the original manufacturer of my device. Three variations of Phi2 mod have failed to alleviate my problems, and in any case: the device did work for a short while with the same system.

 

I have gone to the lengths of ordering a replacement 50 way ribbon cable to see if that helps. However, Drac030 assures me that the fact the interface fails to pass the IDEa stability test is BAD news. I feel confident enough to action basic diagnostics and repairs on the unit. However, I am currently at a complete loss as to how to proceed. The forum member who has emailed me reporting stability problems with his (infrequently used) unit would also appreciate the pooling of ideas.

 

Perhaps anecdotal information from KMK/JZ users would be a useful place to start, since I appreciate that no-one is likely to magically appear with a solution.

[flashjazzcat]

This everything I have, including some source code for a RAM test, and another small test program (XEX):

 

kmk_hdd.zip

 

I'd also recommend downloading everything here:

 

http://drac030.krap....kmkjz-pliki.php

 

For registers, look here:

 

http://atariki.krap....KMK/J%C5%BB_IDE

 

Testing (yet) again, what intrigues me is that the unit is capable (sometimes) of working without I/O errors. However, usability is constantly blighted by strange on-screen effects, including shimmering characters, and the regular-as-clockwork setting of the upper two bits of GPRIOR during reads/writes. The unit still fails Draco's stability test, but appears to work behind all the on-screen crap.

 

I'd be interested to know what could cause the shimmering character effect. I know of no means of replicating the effect via software, so I'm assuming it's some kind of problem originating from the ECI port.

 

A film of the effect here:

 

IDEa Instability

Edited December 4, 2010 by flashjazzcat

[+bob1200xl]

The video seemed to have a number of problems, but the effect you described looks like noise getting into your display. I assume that you do not see this if the KMK is off or disconnected - how close is it to your monitor? Are you using a HDD or a CF card? (if HDD, move it far away from your monitor...) Where does the KMK get its power?

 

Bob

 

 

 

 

 

This everything I have, including some source code for a RAM test, and another small test program (XEX):

 

kmk_hdd.zip

 

I'd also recommend downloading everything here:

 

http://drac030.krap....kmkjz-pliki.php

 

For registers, look here:

 

http://atariki.krap....KMK/J%C5%BB_IDE

 

Testing (yet) again, what intrigues me is that the unit is capable (sometimes) of working without I/O errors. However, usability is constantly blighted by strange on-screen effects, including shimmering characters, and the regular-as-clockwork setting of the upper two bits of GPRIOR during reads/writes. The unit still fails Draco's stability test, but appears to work behind all the on-screen crap.

 

I'd be interested to know what could cause the shimmering character effect. I know of no means of replicating the effect via software, so I'm assuming it's some kind of problem originating from the ECI port.

 

A film of the effect here:

 

IDEa Instability

[flashjazzcat]

The video seemed to have a number of problems, but the effect you described looks like noise getting into your display. I assume that you do not see this if the KMK is off or disconnected - how close is it to your monitor? Are you using a HDD or a CF card? (if HDD, move it far away from your monitor...) Where does the KMK get its power?

This effect only occurs when the KMK is connected. Proximity to the monitor makes no difference. I don't think this is signal noise in the sense that it's affecting the monitor. It surely IS affecting ANTIC/GTIA/VBXE, however.

 

I'm using a CF Card and IDE adapter, although I've also tried HDDs, etc. The KMK is powered via the ECI port, and the CF card is powered off pin 20 of the IDE connector patched up to +5V on the board. And before anyone says it: I'm running the Atari off a 2A custom PSU, and I've tried powering the CF card adapter from a secondary PSU. It makes no difference.

 

I've also tried standing on one leg while turning the computer on, and chanting various incantations at it.

Edited December 4, 2010 by flashjazzcat

[+Larry]

I have two of the KMK-JZ (single-board) interfaces. One is used occasionally and one is essentially new. I was having fits yesterday and today, but it appears that the KMK-JZ and the 32-in-1 OS module do not work well together -- but only in some XE's. Sometimes they boot, sometimes not. Ditto for the USP+ module. I got out a stock 130XE and both interfaces started working well again with several different CF cards/modules. Then I got out another 320XE with a 32-in-1 in it, and both interfaces still worked just fine. (??) In testing with 4 different XE's today, I found that two worked all the time, and two worked intermittently to essentially not at all. This behavior is certainly frustrating, but I've seen it before with other interfaces. (FWIW, all 4 of these XE's worked perfectly with the Black Box.)

 

The XE's were:

Stock 128K XE (good)

320K XE w/32-in-1 (good)

128K XE w 32-in-1 (no good)

320K XE USP+ (no good)

 

At least on my interfaces, the KMK-JZ seems quite sensitive to having very clean contacts and PBI connectors. It may be because the pcb is (slightly) thinner than either the MIO XE adapter or Black Box (and might also be related to how "loose" the XE PBI connectors are).

 

So the story for mine is "works great with some XE's and not others." That's a pretty lame story, but it's the best I've got for now...

 

-Larry

[candle]

Jon

 

Every test You may have for SpeedDrive is still valid here

[drac030]

It may be useful to write your own tests for the interface that work directly with the hardware regs.

 

It may. But there is already a diagnostic program which talks directly to the hardware.

[flashjazzcat]

Every test You may have for SpeedDrive is still valid here

I don't think I have any...

[+Larry]

Hi drac030-

 

Do you think it would be useful to go back and test the 4 XE's/KMK-JZ combinations with a real 2-1/2" HD's as opposed to flash devices? I know that when I bought these interfaces, drives were "in" and CF was largely still on the horizon.

 

Also, please be assured that I really like these KMK-JZ interfaces a bunch, and appreciate all the hard work that went into making them a reality.

 

-Larry

 

It may. But there is already a diagnostic program which talks directly to the hardware.

[flashjazzcat]

I think I've killed mine. I managed to flash the BIOS to an EPROM, fitted it on the board, and the unit booted up and worked perfectly for about two minutes. I tried RWTEST three times and there was no screen corruption. Then, the next time I powered up the Atari, the RED activity LED flashed briefly, and the computer failed to detect the interface (or the interface failed to detect the drive). Even with the old PROM back in the board, this is still the state of affairs.

[+bob1200xl]

Does this test (what test is this?) give us enough information to diagnose the problem? A diagnostic should do two things: detail exactly what it did and what it expects to happen that did not happen, and loop the failing mode so we can scope/trace the failure.

 

From the looks of the video, a significant amount of noise is being generated by the KMK... that makes for interesting times.

 

Bob

 

 

 

It may be useful to write your own tests for the interface that work directly with the hardware regs.

 

It may. But there is already a diagnostic program which talks directly to the hardware.

[drac030]

(what test is this?)

 

This is a diagnostic program distributed on the ATR with the utility software for the IDEa.

 

give us enough information to diagnose the problem? A diagnostic should do two things: detail exactly what it did and what it expects to happen that did not happen, and loop the failing mode so we can scope/trace the failure.

 

I to does a variety of things to determine if the device works correctly. If it doesn't, it says what failed and what the failre was, if it can be said or determined automatically.

 

@fjc: does the diagnostic program detect the interface? It should even if there is no disk attached (if the device is detectable at all, that is). And it is easy to tell the difference between the Atari not detecting the IDEa and the IDEa not detecting the disk: in the latter case it will wait long time (10-20 secs) for the disk to become ready, before it gives up. In the former case the bootup will be as quick as if there was nothing attached.

[flashjazzcat]

@fjc: does the diagnostic program detect the interface? It should even if there is no disk attached (if the device is detectable at all, that is). And it is easy to tell the difference between the Atari not detecting the IDEa and the IDEa not detecting the disk: in the latter case it will wait long time (10-20 secs) for the disk to become ready, before it gives up. In the former case the bootup will be as quick as if there was nothing attached.

Yes - my apologies. There was a long initial timeout, so I've fired up KMKDIAG and the interface is detected. Moreover, the drive and its geometry are also detected. Clearly the partition table had got trashed. I hadn't thought of that...

 

Now it gets interesting:

 

I put the EPROM I'd prepared earlier back in the ROM socket and rebooted, FDISK'ed, and formatted partition C. I then tried RWTEST a few times. First time, it locked, and system reset was required. After that, it passed three times without incident.

 

Most importantly: THE SCREEN CORRUPTION NO LONGER OCCURS WITH THE NEW BIOS CHIP.

 

I wonder if the lock-up problems may hark back to Phi2. In any case, troubles are far less visually catastophic. However, the unit still fails the ROM stability test. Also, exiting KMKDIAG (either normally, or via system reset) sometimes locks the system.

Edited December 5, 2010 by flashjazzcat

[drac030]

However, the unit still fails the ROM stability test.

 

If the ROM doesn't give stable reads, the program it contains (IDEa BIOS) cannot work correctly either.

 

Also, exiting KMKDIAG (either normally, or via system reset) sometimes locks the system.

 

This may be due to the ROM/RAM banking problem early IDEa units (so called rev. A) have. It is harmless, except this one symptom. Anyway here is the most recent diag version: http://drac030.krap.pl/kmkdiag-1.32.zip

[flashjazzcat]

Thanks. I just ran the disk read/write stability tests, and the drive passed with no errors. The whole problem seems to be ROM stability. I don't know what was the matter with the original chip. Replacing it has somehow eradicated the screen corruption problem, although occasional lock-ups and I/O errors remain.

 

It should also be noted that only the bank #0 ROM test fails. All other banks (ROM and RAM) pass. Does this tell us anything we can then go about fixing?

Edited December 5, 2010 by flashjazzcat

[flashjazzcat]

ROM failures are always $D9F1 or $D9F5. I think that's about as much information as I can provide at the moment.

 

Was the length of the 50 way ribbon cable ever considered to be an issue? This one is 10" long.

Edited December 5, 2010 by flashjazzcat

[drac030]

You of course can cut the cable. Othewise I have no idea what may cause the ROM failures to be confined to bank 1. The address reported is the address of the first error encountered.

[flashjazzcat]

Well, I shortened the cable to about four inches (this is anyway more suitable for my envisioned positioning of the unit), but it hasn't improved the ROM problem. At least the screen crap has gone now and we know what we're dealing with. Pigula has promised me a detailed email tomorrow...

[+bob1200xl]

Is the screen noise repeatable? If you put in the old ROM, it is bad and swapping in the new one, it is OK? Does the old ROM fail at those addresses? Does it give you expected and received data for the failure?

 

Bob

 

 

 

Well, I shortened the cable to about four inches (this is anyway more suitable for my envisioned positioning of the unit), but it hasn't improved the ROM problem. At least the screen crap has gone now and we know what we're dealing with. Pigula has promised me a detailed email tomorrow...

[flashjazzcat]

Is the screen noise repeatable? If you put in the old ROM, it is bad and swapping in the new one, it is OK? Does the old ROM fail at those addresses? Does it give you expected and received data for the failure?

Hmmm... timely questions. I just tested it again with the original PROM and it completed 3 RWTEST runs without incident, and without screen noise. Running KMKDIAG with the PROM:

 

ROM Bank #0: Fail

RAM Bank #0: Pass

ROM Bank #1: Lock up...

 

So, slightly different results than with the EPROM, which only fails on Bank #0 and doesn't lock-up on Bank #1 (at least, not during tests I've run so far).

 

Screen noise is NOT currently repeatable with either chip. All I've done is shorten the SCSI cable (linking the PBI adapter to the interface), and "blanket solder" the board.

 

Both the PROM and EPROM are unstable, and I think we can say that they behave similarly: failing stability tests, and evidently causing improperly executed BIOS code to perform the occasional rogue write in main RAM.

 

One of the other diagnostic utlities I posted gives a graphical representation of both the device ROM (mapped onto a mode 8 display) and RAM. One can clearly see, while the test program writes to the RAM, several bits "flipping" in the ROM region.

[flashjazzcat]

More test results, if it helps...

 

I managed to get this up and running with a different (unmodified) 130XE. This time, things are reversed: KMKDIAG consistently detects RAM errors in both banks ($DE02 and $DE01 respectively), and no ROM errors at all.

 

The drive passes the read stability test. After formatting a partition on this machine, however, the system hangs.

 

On yet a third machine (which I haven't tested thoroughly yet, but which is - again - stock), both existing partitions are unreadable, and formatting a partition once again hangs the system.

Edited December 6, 2010 by flashjazzcat

[+bob1200xl]

The KMK actually enables Chip-Select on both the RAM and ROM and raises Output Enable on the chip it wants... this is not, not, not good. You may have both memories in collision. This would give you failures on one or the other IC, or both. Can you sneak in there and tie CS and OE together on each chip? (if you aren't sure about what that says, don't try it)

 

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

 

Bob

 

 

 

More test results, if it helps...

 

I managed to get this up and running with a different (unmodified) 130XE. This time, things are reversed: KMKDIAG consistently detects RAM errors in both banks ($DE02 and $DE01 respectively), and no ROM errors at all.

 

The drive passes the read stability test. After formatting a partition on this machine, however, the system hangs.

 

On yet a third machine (which I haven't tested thoroughly yet, but which is - again - stock), both existing partitions are unreadable, and formatting a partition once again hangs the system.

[drac030]

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

 

... then how does it work here?