• Please review our updated Terms and Rules here

Apple IIe clone ASIC STK chips help required

Druid6900

Veteran Member
Joined
May 7, 2006
Messages
3,809
Location
Hamilton, Ontario, Canada
I know this is a long shot, but, I have the pictured IIe clone board shown below.

It shows a disrupted test screen keyboard attached or not.

Anyone have any information on this board or a source of STK 65301 or STK 65371 chips that it uses as the MMU and IOU?

I'd appreciate any assistance with this.
 

Attachments

  • AppeIIeASICclone.jpg
    AppeIIeASICclone.jpg
    94.3 KB · Views: 9
I've never been able to find much information on them.

What I can tell you is the are the functional equivalent of the Apple 2e MMU and IOU but they are not pin compatible.
Every clone 2e I have seen uses the chips.

With a little effort and an apple 2e schematic it wouldn't be too hard to trace the tracks to determine the pinouts.
 
I agree, but, without a replacement source, what difference does the pin-out make?

All the RAM and TTL chips have been tested, the ROM and analog chips tested by substitution, same with the CPU. That doesn't leave much else than the STK chips.
 
What do you mean by "disrupted test screen"?

If the board is running the built in diagnostics with the keyboard plugged in or out then I would expect the asics are working fine. The 2e goes into self test by holding down the closed apple key on reset, when the keyboard is plugged in there is a resistor that pulls that line low via a resistor, the line is pulled high by the keypress. With no keyboard the line floats high so the apple does a self test on power on.

Here is the good news, the closed apple key is not connected either to the asics or the keyboard controller. That line runs to the input of a 74LS251 and it is decoded by the 74LS154 and not an asic.
I'd trace back pin 5 of the keyboard connector, check the address lines going to the 74LS251, its output to D7 and its enable from the 74LS154. From memory the IOU does provide the course CxxxH decode but if that was faulty the video soft switching wouldn't work so you would not see the self test screen.

Oh... also check that the resistor is indeed pulling pin 5 of the keyboard connector low.


I agree, but, without a replacement source, what difference does the pin-out make?

All the RAM and TTL chips have been tested, the ROM and analog chips tested by substitution, same with the CPU. That doesn't leave much else than the STK chips.
 
In a nutshell, here's what I get;

You know how the built-in test starts with alternating black and white horizontal bars, and then merges into a full white screen a couple of times before going on to test RAM?

Mine starts with the bars, but, there are white graphic characters in the black bars (I don't know if there are any in the white bars, obviously) and sits there.

That's what I mean by a disrupted self test.
 
Strange I was sure I replied to this yesterday.

What you are seeing is not self test the bars are the typical uninitialised RAM pattern when a board powers on with the hires mode active.
Any problem accessing ROM or RAM will prevent the graphic mode being cleared.

Again its not all bad news, the fact that you seeing are different values in screen RAM locations is a good indicator the MMU is functional, because it is responsible for address multiplexing and general control of the memory.
You have a stable display, so that indicates the IOU is likely working because it generates the video sync signals and timing.

I'd be looking for bad sockets, dry joints or fractured tracks. Start with reset and look for read activity on the ROM enable lines. If that all looked good I'd trace out the address and data lines.

In a nutshell, here's what I get;

You know how the built-in test starts with alternating black and white horizontal bars, and then merges into a full white screen a couple of times before going on to test RAM?

Mine starts with the bars, but, there are white graphic characters in the black bars (I don't know if there are any in the white bars, obviously) and sits there.

That's what I mean by a disrupted self test.
 
I don't know how much profit there would be left in a clone board after pouring all that tech time into it, so, I'll probably just set it aside in the "if your day is going too well" stack for now and work on it as a hobby thing.

Thanks for your suggestions though, I appreciate then.
 
Try the ROM image I posted recently. It doesn't require the RAM to be fu7lly functional. What you see on the screen will give clues to here the problem is.

https://drive.google.com/open?id=0B8aVm3oIO3icNFd0aEJhNVN6RHM

I don't know how much profit there would be left in a clone board after pouring all that tech time into it, so, I'll probably just set it aside in the "if your day is going too well" stack for now and work on it as a hobby thing.

Thanks for your suggestions though, I appreciate then.
 
Try the ROM image I posted recently. It doesn't require the RAM to be fu7lly functional. What you see on the screen will give clues to here the problem is.

https://drive.google.com/open?id=0B8aVm3oIO3icNFd0aEJhNVN6RHM

I would LOVE to be able to burn and use the ROM you developed. I have all the files already.

However, the seller of the first TL866CS package I ordered said it was shipped and, when I inquired if there were any numbers that might be able to track it by (there was no provision to upgrade the shipping), cancelled the order and refunded the money. It was, obviously, never shipped.

After a month of that, I ordered another from a different supplier who didn't happen to mention that he didn't have them in stock. I had to wait an extra week, but, it shipped today (with tracking), so, when it gets here, I'll make a ROM and see what it does.
 
I had a similar issue with a phone I bought on ebay before Christmas, its frustrating. I use a TL866CS myself, the only problem I have found with it is that most of the old EPROMS are 25v VPP and cant be programmed. So the old ISA bus EPROM programmer and XT clone won't be retired just yet :)

I would LOVE to be able to burn and use the ROM you developed. I have all the files already.

However, the seller of the first TL866CS package I ordered said it was shipped and, when I inquired if there were any numbers that might be able to track it by (there was no provision to upgrade the shipping), cancelled the order and refunded the money. It was, obviously, never shipped.

After a month of that, I ordered another from a different supplier who didn't happen to mention that he didn't have them in stock. I had to wait an extra week, but, it shipped today (with tracking), so, when it gets here, I'll make a ROM and see what it does.
 
My programming needs are simple. Some diagnostic ROMs that I've acquired (including yours) for vintage stuff, burning some new ROMs for Plus hard-cards and, mostly, 27C chip work.

The worst thing is, all the various and sundry chips have arrived long ago and everything is waiting on the programmer, as per Murphy's Law....
 
It doesn't require the RAM to be fu7lly functional.
This is not exactly true. The 6502 needs the first two zero pages ($0000-$01FF) in order to run properly.
Moreover, the display uses $0400-$07FF for page 1.
So you do need at least 8K of working RAM to use the ROM diagnostic.
 
The ROM I was talking about does not require fully functional RAM because it does not use CALLs and as such does not require stack memory to be working.
I have used the ROM to boot boards with faulty RAM in bank 0, I've even removed one or two RAM's from bank 0 and it still boots.

Secondly $0400-$07FF falls within the first 2K of RAM, program memory starts at $0800, enabling the normal F8 boot ROM and applesoft or integer basic to run with 4k of RAM. In fact the Apple 2 originally shipped with as little as 4K of RAM.

This is not exactly true. The 6502 needs the first two zero pages ($0000-$01FF) in order to run properly.
Moreover, the display uses $0400-$07FF for page 1.
So you do need at least 8K of working RAM to use the ROM diagnostic.
 
I have used the ROM to boot boards with faulty RAM in bank 0, I've even removed one or two RAM's from bank 0 and it still boots.
Weird, I've tried the F8 ROM in an Apple II+. If I remove one RAM on row C, the only thing I get is a non booting machine.
Doing the same on row D or E report an error as expected.
I will try the IIe ROM and report back here.

ISecondly $0400-$07FF falls within the first 2K of RAM, program memory starts at $0800, enabling the normal F8 boot ROM and applesoft or integer basic to run with 4k of RAM. In fact the Apple 2 originally shipped with as little as 4K of RAM.
You are right.
 
I have tested the EF ROM in a IIe.
Removing a single RAM chip results in an non booting machine.
 
When I tried pulling a ram the 2e lost all video. However on a board with a faulty address line going to RAM the board would boot with thew ROM but not with the standard EF ROM.

I have tested the EF ROM in a IIe.
Removing a single RAM chip results in an non booting machine.
 
OK, I finally, finally got my programmer and made up the ROM for the EF replacement and put it in 2764B (I assume that the A ROM is CD) and nothing happened at all.

I took out each of the 4 ROMs, one at a time and powered up. With the exception of the 2732 at F4, which gave me a black screen, the display stayed the same.

Removing the "MMU" and "IOU", one at a time, did nothing to change the display (which I'll have to get a picture of today, so you can see what I'm talking about) and neither did removing the CPU.

I'm beginning to think that the problem may be, as someone suggested, a socket surface, mechanical or solder problem.

I'll have to look into that, when time lends itself.

On the plus side, I did source and get pricing on the STK65301 and STK65371 chips.
 
I have a ROM I wrote for the diagnostic card I'm designing, it will work in a 2e with RAM faults.

Use the 2764 version in the EF ROM socket of your 2e.

This ROM will work in a system with no RAM at all. It will do 4 RAM tests and beep according to the test results.
It will also set text mode and output messages to the screen, how visible they are will depend on how bad the fault is.
The order of the sets are as follows...
Zero fill test - One long beep if this fails.
Ones fill test - Two long beeps if this fails.
Walking one - Three long Beeps on fail.
Walking Zero - Four long beeps on fail.

If you hear 5 short higher tone beeps then all tests passed.

If you hear nothing then you should look at the data and address buses or the IOU decoding of the speaker address.

Here is a link to the ROM
Diag ROM beta

I just had a quick look at the photo you originally posted. The ROM on the bottom right of the board is the keyboard translation ROM, the one on the bottom left is the character generator rom. The two ROMS in the middle of the board are the CD and EF ROMS, which of them is the EF ROM I dont know but it is the EF rom that should be replaced with the diag ROM. If you have 2 2764's you can program... put one in each it wont hurt.
 
Last edited:
OK, I tried both the EF ROMs, even doing a combination of all 3 in the 2764A and 2764B sockets. No sounds.

They worked fine in my Apple IIe

Would these boards use copies of the actual IIe ROMS?

I ask because the 2732 @ F4 is considerably warmer than the other 3 ROMs.

I've attached a picture of what I get on the screen below. It is not precisely the same all the time, but, pretty representative.

I'm going to have to determine if all the IOU pins on the chip are the same as its STK equivalent.
 

Attachments

  • IMG_20170405_145934.jpg
    IMG_20170405_145934.jpg
    79.2 KB · Views: 1
No sound is not as great sign, but it does tell us RAM is not a problem (yet).
The fact that there is no change on the screen or sound with the ROM in place gives a few clues.
I'd be looking again at the CPU, data and address buffers. Double check you didnt accidentally bend a pin putting them back after your first round of testing.

If you suspect the 2732 thats an easy check, just read the data from it in your new eprom burner.

They do use copies of the IIe ROM's sometimes with a name change patch. However, Apple do a sneaky thing, the masked programmed version of their ROMS use the unused pin as an extra enable line which from memory needs to be tied low. That line is wired up on the mainboard for the masked ROM's and ignored when you use EPROM's in the board. But the masked ROM's read as blank in an EPROM burner because that extra line is not asserted. So you wont be able to read the chips to copy them, download the binary image of the ROM if you need it.

I have 6 faulty IIe clone boards here but they all have different layouts and missing chips, some don't identify what chip belongs in the empty socket and most have no ROM's.
What I have tried is putting the STK chips in a real IIe and I found they don't have the same pinout.

I do have one complete clone mainboard here, it is only populated with a 27128 in the 2764B position, the 2764A position does not have a socket fitted.
Some good news however, the working board I have happens to be the same as the one you have. So I can assure you that my diag ROM in a 2764 should work in the 2764B socket of your board because it works in mine. If you need working copies of the other ROM's let me know and I can read the data from these ones and upload them.

Its a shame you are not local, I could test your STK chips in this board.

Edit: I decided to read the EPROMS for you just in case.
https://drive.google.com/open?id=0B8aVm3oIO3icWHpjRVJIbDZfNFU

OK, I tried both the EF ROMs, even doing a combination of all 3 in the 2764A and 2764B sockets. No sounds.

They worked fine in my Apple IIe

Would these boards use copies of the actual IIe ROMS?

I ask because the 2732 @ F4 is considerably warmer than the other 3 ROMs.

I've attached a picture of what I get on the screen below. It is not precisely the same all the time, but, pretty representative.

I'm going to have to determine if all the IOU pins on the chip are the same as its STK equivalent.
 
Last edited:
Back
Top