Recently one of my 'IWMless' beta testers ran into a problem with his Apple IIc and needed a memory test program. Since the machine would refuse to boot ("Check Disk Drive" error message), the best way is to remove the firmware ROM (always socketed) and plug in an EPROM with a memory test.
All you need is an EPROM programmer and a suitable EPROM for your Apple II (2716, 2732, 2764, 27128, 27256). ROMs in earlier Apple II have only 2 kByte and need some pin "lifting" on the EPROM and some flight wires for the proper EPROM hookup and its chip select. Consult the appropriate Apple II schematic and the EPROM datasheet and decide which pins are different between ROM and EPROM. These different pins need some flight wire mods. The rest of the pins (addresses, data) are 1:1 EPROM compatible in most cases.
APPLE IIc SPECIFIC
The image is for a 16 kByte / 27128 type. If your Apple IIc has been upgraded to ROM4 (27256) the best way to deal with it is to burn the 16k image in both the top and lower 16k of the 27256. Otherwise you need to temporarily undo the two solder option changes (W1 and W2 on the motherboard).
OTHER APPLE II
If your Apple II has smaller EPROMs, move the code in the image to the top (the topmost byte goes to address $FFFF in the Apple II).
RUNNING THE TEST
If everything works you get vertical stripes alternating between the two hires color sets. Let it run for a few hours.
A DRAM error should be shown as a syndrome but if the DRAM is too bad to even do text output, the software telegraphs the number of the bad DRAM in a way it can be seen with an oscilloscope, but I've forgotten how that works, despite I wrote it.
The syndrome shows a 4 digit address and a single byte in which the '1' bits correspond to the bad DRAM bits.
- Uncle Bernie
memt_27128.bin
Hi Uncle Bernie
I like this solution for ram testing without a card.
I don't fully understand the "apple ii smaller eprom" section.
I soppose your code could fit the eprom once but not twice.
So...do you mean: push all the code to the top (so ffff and nearby vectors are satisfied), and leave empty the bottom area ?
Thank you
Julian
In post #2, 'JulGiul' wrote:
" ... push all the code to the top (so ffff and nearby vectors are satisfied), and leave empty the bottom area ? "
Uncle Bernie answers:
Correct. Most programmers must be set to a 27128 (16 kByte) EPROM first and then you can load the binary. On the top ($FFF8-$FFFF in the Apple, $3FF8-$3FFF in a 16 kByte EPROM) you can easily identify the 6502 vectors by using the "Edit" mode of your programmer. Most programmers allow you to specify a start address in their data buffer for programming. For instance, if using a 2732 EPROM, set the start address to $3000. For a 2716, set it to $3800. Then change the EPROM type and program it. Note that programmers differ in the details on how this can be done.
Another thing I forgot to mention is that this DRAM test only tests the lower 48 kBytes which should be present in any Apple II. Once this block of DRAM is tested and has been repaired as needed, you can boot DOS 3.3 and then load one of the more sophisticated DRAM tests available as floppy disk images.
The rationale behind this intentional limitation is that in the Apple II, any DRAM other then the basic lower 48 kBytes involves a plethora of soft switches to be flicked and this is difficult to program if you can't use any RAM (no stack use, no subroutines, ...). The only RAM this DRAM test uses are two zero page bytes for the pointer and these are checked to respond properly, and the test algorithm is chosen such that any disturbance to these pointers causes a DRAM error message. Which typically has the syndrome 10101010 or 01010101 ... so if you get such a syndrome, change the lower RAM bank first, because it may have been caused by a corrupted pointer.
The test algorithm as such is the same as was used by DRAM manufacturers for the wafer sort test, so it is very fast and efficient and well proven for the kinds of older DRAM architectures used in the Apple II.
- Uncle Bernie
Thank you for explanation and details.
Expecially for the 48K scope :-)
Have a nice day!
Julian
I am using DeadTest from the mysterious misterblack1 from GitHub and it has worked great for me. I'm open to new things, but maybe you could explain how your test is better and why I should opt for it.
Thanks in advance!
In post #5, 'Macintosh_nik' wrote:
" ... maybe you could explain how your test is better and why I should opt for it ... "
Uncle Bernie answers:
What 'Misterblack' does is to first test the zero page and then declares it good, and proceeds with his tests. I can't say if his approach is better or worse, and I don't care. My code is coming from the diagnostic page of my Apple-1 PROMs. It is field proven and has found all DRAM errors that were there, even the difficult ones caused by the ringing on the multiplexed address lines. Which could also corrupt the zero page ... but only after the test enters higher addresses.
This thread was born out of lazyness = efficiency so I can point 'IWMless' beta testers to this thread instead of sending each one individual emails with the binary attached.
If other Apple II users get a benefit out of it, why not.
- Uncle Bernie
The DeadTest does a good job as does UncleBernie's. I'd also like to point out that the ROMX products can load these images into it's RAM so that they're always available with a simple keypress. No burning EPROMs or swapping chips. And ROMX also has its own built-in dead test that can check for missing or bad RAM. The advantage of this test is that if any errors are found it will "beep out" the chip number that is bad. Video does not have to be working or even connected to a monitor.
* Usual disclaimer that I'm involved in the ROMX project so take that into account.
EPROMs are not burned, they are programmed. BPROMs a have fusible links.
Even the much cheaper than your constantly advertised here ROMX (and much more useful) Xgecu T48 Chinese low cost USB driven programmer which I neither own nor need can program 2716 and higher EPROMs.
I don't mind trying it, why not, maybe I'll like it. The ROM in Apple II and EPROM 2716, if I'm not mistaken, do not match in terms of pins, and I don't want to mess with an adapter. What kind of ROM is in Apple //e? Can it be replaced with an EPROM without any adapters? If so, which one? Thanks in advance!
PS. ROMX is mentioned here so often that I feel a bit foolish because I still don't have it.
In post #9, 'Macintosh_nik' asked:
" What kind of ROM is in Apple //e ? "
Uncle Bernie answers:
In my specimen of Apple IIe there are two firmware ROM sockets, named "CD" and "EF". Both are drop-in compatible with the 2764 EPROM. The DRAM test would go to the "EF" socket. I used this test to repair several Apple IIe. But note that there were several versions of the Apple IIe, and later ones had only two 64k x 4 DRAM IC instead of the usual eight. I don't remember if that one had a 27128 to replace the two 2764.
- Uncle Bernie
P.S.: all firmware ROMs in the Apple II family, even the mask ROMs, followed the industry standard pinout and most pins are 1:1 drop-in compatible with the 27xx EPROM of the same size. The difference is in the chip selects: some mask ROMs have up to three mask programmable chip select inputs and this allowed selection of one of eight such ROMs without extra decoding logic. EPROMs only have /OE and /CE inputs and then some EPROM related extra functions like the programming voltage pin VPP. I never had a problem with rewiring EPROMs by lifted pins and flight wires to drop into a ROM socket. If no decoder is on the motherboard, you can always add a 74LS138 in top of the EPROM (glued on back to back with double sided sticky tape) and add the required flight wires to the appropriate address lines.
The Platinum IIe (with numeric keypad) uses a "CF" ROM comparable to a 27C128.
This is correct, the original //e boards used two ROMs and the Platinum ones a single one. 27x64 and 28C64 work in the original boards and you can use a 27c128 or a 28C256 in the Platinum (put in the image twice to be safe).
28C64 and 28C256 are fairly easy to get, don't require a UV eraser and even the Minipro/XGecu TL866-II+ which has trouble with some high voltage EPROMs handles them with ease. Plus they look more like the original Apple chips as they don't have the "window".
Thanks for the replies, I have an early Apple //e c 8 memory chips and white letters on the keyboard. Who told me that such a keyboard is called California, but as I guess that someone came up with that name themselves. At least I've never heard of such a classification from anyone else.
Tomorrow I will see if I have the necessary EPROM in my den, if not I will order it on Aliexpress.
I have never heard of a keyboard referred to like that. Those are generally known as "white letter" //e keyboards. They were from the first couple years of //e production. All Rev A boards and the early Rev B came with that, later Rev B they switched to the black letters. There were some changes to the case latching and then the Enhanced ROMS/65C02 came out. Then much later the Platinum models with the numeric keypad and the reduced chip count motherboard.
With your //e you can use 28C64 EEPROMs if you want instead of 2764 or 27C64 EPROMs.
Compatibility caution:
That's absolutely safe when the status is RDY because an open-drain output is essentially unconnected in that state. But it would certainly short-circuit the +5 volt power supply through the 28C64 if the chip ever asserts BUSY' unless you choose an EEPROM with an "X" suffix, like Atmel's AT28C64X, which leaves pin 1 unconnected for maximum compatibility with ordinary EPROM sockets.
It probably won't be a real problem because the EEPROM shouldn't need to activate its BUSY' output while installed in an Apple computer. But it's not best-practice to attach a component's output directly to the +5 volt power supply, even if you don't expect the output to be activated, so try to choose an EEPROM with the "X" suffix like the aforementioned AT28C64X.
So, to close the loop I was the tester UB was refereing to and I indeed used the Xgecu T48 Chinese low cost USB driven programmer to make the ROM - quick and easy to do and pop into the motherboard.
In this case the RAM was all good - but when diagnosing machines that I've pulled apart to the bare motherboard this is an easy approach.
Thank You UB for sharing the BIN
It's a good note. I have a couple //e that I "enhanced" using 28C64, but I believe that the ones I used were Atmel, so possibly the AT28C64X you mention. Or I've just been lucky or it just happens that the signal you mentioned is never asserted in practice.
In general, I decided not to buy the EPROM 27128, as it is not used in my current projects. Instead, I recorded this memory test on my existing EPROM 2716 and used it in conjunction with a Language Card clone on Apple //e. On my Russian-made Sterch-007 programmer, there is no option to select the address from which to start programming, but you can select a specific block and save the trimmed firmware as a new file. I saw two colored stripes on my monitor screen, green and orange, alternating with each other. And it seems like nothing else is happening. I'm not sure if I did everything right.
IMG_20250808_110941.jpg
IMG_20250808_110457.jpg
If you program F8 ROM contents on a 2716 and plug it into this pathetic RAM card does your apple2 motherboard boot with it?
Yes, I've tried that as well as DeadTest and everything works on my Apple //e. I just still can't get this card to work for its intended purpose, which is to add 16k of memory to my Rev0 replica.
No way, you could't have tried successfully what I asked on a //e.
It's true, I was surprised myself. I left town for the weekend, but on Monday I'll send you a link to the video, and you'll see for yourself.
F8 Apple ][ ROM does not work on a //e.
The chip itself won't work, but you can program its contents into a 2764 and put that into the EF socket. The machine will boot (and mostly work).
https://youtu.be/IXDysahINcE?si=YryivX36qUTTX1a8
https://youtu.be/renY1gLYrUU?si=8hcsBjEewHc1qeDa
https://youtu.be/M90g8tJ0RJg?si=VUDTTj34iAzbjUWL
For what it is worth, an Apple ROM card (and others like the Mike Willegal Brain Board) works in a //e, even an "Enhanced" //e. If you want to run stuff that requires the old ][+ style ROM contents either Applesoft or Integer BASIC, it is a way to go. It is also a way to drop in an alternate F8 like "The Freeze".
The Apple card and close clones of it require modification because the switch causes them to not physically fit. I used a modified card back in the day to crack copy protection. Either with just the non-Autostart F8 or an alternate one, and 6116 SRAMs in the empty sockets (Integer BASIC on the card). I had modified F8 that would copy the text, zero page or keyboard buffer to the SRAM, which could then be extracted after a warm reboot.
How was the apple firmware card modified exactly?
The main modification was to relocate the switch on a wire so it could be accessed externally to a //e and so that the card would fit into a //e, which it wouldn't with the switch in place. The other modifiction was an adapter socket to allow 6116 to be used in place of the empty socket and another swapped into place where the programmer's aid ROM comes on the INTEGER card. Also when a modified F8 was used in an EPROM an adapter socket for that was needed. Nothing really exotic, just things that were needed to facilitate using in a //e and for allowing a tiny little bit of extra RAM for storing things that get wiped out otherwise or to use an alternate F8.