Hello, hoping someone can set me on the right path, my knowledge is limited as the las time I played with an Apple II I was a student in Jr. High in the computer class run by Mrs. Quigley. A bit of backstory in case it'll help. A B&H Apple II came to me with a dead power supply, and only one ROM CARD 600 in it.
I tried repairing the power supply with a capacitor kit but was ultimately unsuccessful. I ended up getting a replacement PSU from ReActive, and that got the Apple II booting up to a garbage screen to the monitor prompt.
After taking the ROM CARD 600 out of it I was able to get a "BR NEXT WITHOUT FOR ERROR".
While reseating the chips on the board I discovered the D0 ROM (341-0011-00) on the main board had a broken leg. There was enough leg to solder on a replacment and I got it to boot and literally PRINT "HELLO WORLD". However, it still seems like something's off. It does crash to monitor on simple programs. On a friend's adivce, I did some memory tests via the monitor and that confirmed that the memory seems to be setting and coming back fine (if I did this right). I also tried to enter a short basic program to exercise the memory, but after typing the program in and typing "LIST" at the ] prompt caused it to drop to the monitor with the line "E7D0 - A=86 X=00 Y=01 P=36 S=EC" for example. I think if cold it boots to BASIC but after warms up seems to boot to Monitor with another E message.
So issue #1 is the motherboard with nothing on it is being unstable.
I read that my ROM CARD 600 has Integer Basic on it (341-0001-00 @ E0, 341-0002-00 @E8, 341-0003-00 @ F0 and 341-0004-00 @ F8) with the Programmers Aid ROM (341-0016-00 @D0). However, with the switch up it dumps to Monitor with a bunch of @ signs as above. I tried reseating the chips, cleaning the legs and even replaced all the 74LS with spares I had but no change in behavior - I'm is it the mother board or the card itself or a bit of bitrot on the ROMs?
This is issue #2, how to get the ROM CARD 600 working and finding out how to invoke some of the Programmers Aid to possibly check the ROMs?
There's no drives or other cards besides the above, so I've ordered a Disk ][ controller card from ebay that should arrive in a week or so, and I ordered a wDrive (arrived already!) to be able to load images to the Apple II, with the idea of getting some diagnositic programs loaded to investigate further.
Any suggestions on what to try while I wait for the controller to show up?
Thanks!
FYI, that ROM card does appear to be working properly -- it makes the computer start in the Monitor like the earliest Apple II's which didn't have a pretty startup screen. Computers weren't yet trying to be user-friendly, they just handed control to the user and awaited input.
With the ROM card installed with its red switch in the "up" position, the computer will start with a screen full of random-ish characters and a Monitor prompt on the bottom line. To start Integer BASIC, type CTRL+B and press Return. Or type the (cryptic looking) command
E000Gand press return.The red switch determines how the ROM card reacts to being RESET. It's okay to change that switch while the computer is on.
Apple2-IntBasic-ThankYouElliot.jpg
Thank you S.Elliot!!! CTRL+B Return did not work, but E000G did. Looks like the ROM Card is behaving appropriately, so issue #2 resolved.
Issue #3 might be a keyboard issue, aside from the CTRL+B and CTRL-RESET not doing anything, sometimes different letters than what are being typed show up on the screen. I'll investigate/reproduce and share when I get more info.
It's possible that one or more of your ROMs on the motherboard are failing. It that turns out to be the case, you might want to look at the ROMX board. This will replace all of the motherboard ROMs as well as provide the same functionality of the ROM CARD 600. Plus a whole lot more!
Jeff, is there a way to check the ROMs? In the arcade world I'd dump them in my GQ-4x programmer and compare with known images.
Mike gives better info than advertising answers of jeff:
http://www.willegal.net/appleii/appleii-integer.htm
The link that retro_devices provided above has a comprehensive discussion of the topic. The ROM images are available online for you to compare with yours. The main takeaway however is that the Apple II uses mask ROMs which cannot be directly replaced with EPROMs.
Although you could check them by dumping the ROMs, there are two complications: first you'll need to find known-good ROM images, and second you'll need to adjust the GQ-4x settings to match the chip-select signals on pin 18, pin 20, pin 21 of Apple's customized 2316B ROM chips. Unfortunately, the linked page mentions both of those issues but doesn't provide instructive details.
But you've demonstrated some proficiency in using the Monitor, so that give us another option: use some Monitor commands to compute and print ROM checksums.
Step 1: Switch on the computer with the ROM card installed in slot 2 and the red switch in the "up" position. It should start with a Monitor prompt at the bottom of the screen, like it did in your previous adventure.
Step 2: Enter this machine-code program by typing each line below and pressing Return at the end of each line. If entered correctly, the Monitor should silently accept each line without emitting any beeps or printing any responses except the next Monitor prompt. (See picture.)
300:8D 10 C0 A5 42 85 3C A5308:43 85 3D A0 00 84 06 84310:07 84 08 84 09 38 B1 3C318:65 06 85 06 A5 07 69 00320:85 07 A5 08 65 06 85 08328:A5 09 65 07 85 09 20 BA330:FC 90 E3 A9 BD 20 ED FD338:A2 04 B5 05 20 DA FD CA340:D0 F8 8D 10 C0 60 00Step 3: Test the checksum routine by entering the following command to compute a checksum of itself. It should respond by printing an equal sign followed by its own checksum, which should be
A9CC1CE6. If (and only if) it prints the correct result then go on to step 4.300<300.346GChecksum 9 lines.png
Step 4: Enter the following Monitor commands to print checksums of the four principal ROM chips currently installed in the ROM card.
E000<300.E7FFGE800<300.EFFFGF000<300.F7FFGF800<300.FFFFGWhen I ran these commands with a set of Integer BASIC ROMs, it printed the checksums shown in the picture below. NOTE: I added the labels in the yellow boxes to help distinguish which ROM is which -- those messages will not appear on your screen.
Checksums Apple II Integer.png
It's likely that your ROMs will work on the first try, since your previous test demonstrated that Integer BASIC seems to work correctly from the ROM card.
If the previous exercise was successful, and you're feeling ambitious, you can begin troubleshooting the motherboard by computing checksums of its ROMs too.
The following commands require the checksum routine entered in step 2 above! If you've turned off the computer, go back and repeat steps 1-3 of the previous comment to enter the machine code for the checksum routine.
To activate the motherboard ROMs, type
C0A1and press Return. This turns off the ROM card and switches back to the motherboard ROMs, which needs the F8 ROM (Autostart) to be at least partially working. TheC0A1command should silently printC0A1-followed by a meaningless value (oftenA0) and then it should display another Monitor prompt. The computer should not beep, print additional gibberish, or stop responding.To print checksums of each motherboard ROM, enter the following commands:
D000<300.D7FFGD800<300.DFFFGE000<300.E7FFGE800<300.EFFFGF000<300.F7FFGF800<300.FFFFGI got the following checksums when I tested on an emulator with Apple II Plus ROMs. If one of your ROMs is faulty then its checksums won't match. But if more than one doesn't match, then it's more likely that your motherboard has a faulty TTL chip, such as the LS138 line decoder at F12. (Another common failure.)
Checksums ROMCARD off Applesoft.png
Using MAME, OpenEmulator and my own emulator I'm getting: 7BE1E43F
Virtual II gets the same result you had.
MD5 (roms/Apple II plus ROM Pages F8-FF - 341-0020 - Autostart Monitor.bin) = 8925b695ae0177dd3919dbea2f2f202b
Can someone verfy the correct result on real hardware?
AppleIIPlus-BadAppleSoftROMs.jpg
Thank you, great instruction! As you can see in the output, the integer roms on the card check out ok. It looks like my bodge leg repair to the D0 ROM was effective, so that's nice. It appears that 2 of the mainboard ROMs, E0 and F8 are coming back with different checksums. Based on the fact that 2 were misbhaving I tried replacing the F12 74LS138 with some spares I had but there was no change and it dumped to the monitor as before. Given @stivo's comment, I will pop off E0 to see if they have corrosion or other issues that I missed.
EDIT: F8 may be correct according to stivo
Using MAME, OpenEmulator and my own emulator I'm getting: 7BE1E43F
Can someone verfy the correct result on real hardware?
Oh this is interesting, that's what I got off my hardware - now I'm wondering if I just have a bad E0 since swapping the 74ls138 chips didn't seem to make a difference...
Sure enough, the AppleIIjs emulator is using a non-authentic F8 ROM image. When I run checksums of F8 ROM images that I saved on floppy disks, their checksums are
7BE1E43Flike yours. The other checksum,7C18E45D, is a ROM that has its IRQ routine patched to point at the old reset routine.If @stivo's comment is correct, Virtual II must be using the same non-authentic ROM image as AppleIIjs, since it gave the same checksum. I wonder if someone had created a patched image in an EPROM (like I did in the 80's) and inadvertently archived it as an authentic F8 ROM image?
Checksums F8 vs JS.png
A bad E0 ROM could certainly explain another symptom you described in the OP: the Monitor printed processor status at
E7D0, which it would do if the processor had executed a machine-code breakpoint at E7CE. But the (correct) ROM listing shows there isn't aBRK(break) instruction at that location so it shouldn't have stopped there.With the Applesoft ROMs active, try listing the ROM around that address with the command
E7C6LAssuming the E0 ROM is working, it should look exactly like this:
E7C6L listing.png
It looks like this rom was a replacement for the 341-0004 integer F8 rom. The original source? who knows... Used with the other integer roms it will autoboot and drop to the integer prompt instead of the monitor. Many of the rom packs/blobs floating around the internet contain this variation.
When you mentioned the reset vector I remembered a conversation about this years ago on slack. https://apple2infinitum.slack.com/archives/C1J89GVL4/p1561657785410000
Virtual II seems to checksum which roms you try to use but unfortunately allows this variation. Even worse, the help page still links to one of these modified rom blobs... I'm sure this causes problems with some copy protected disks. Quadrant 6112
Anyway, thanks for posting the checksum code. It's super helpful and a great troubleshooting tool.
While it is possible to have a bad rom, there are 3 aspects of ram testing. Write, Read and Refresh. Refresh is often overlooked. A memory test on ram with bad refresh could very well pass write and read, but cause the crash in E000. A Prometheus applesurance diagnostic disk interface card will detect this and identify the chip location, if you know someone with one.
I suggest focusing back on the ram and start swapping it. If you do it with the ram on the motherboard and you see a change in behavior, start replacing with known-good ram.
Do any testing without the 600 card installed, using only the applesoft roms on the motherboard for now. This is just to take it out of the equation from a code and hardware expansion perspective.
FWIW, the 600 started life as an applesoft add-on for integer machines. Often, the applesoft roms were moved to the motherboard and the integer roms moved to the 600.
The 670 is the same card, but came with integer roms for applesoft-delivered machines for backwards compatibility. Language cards negated the need for both.
If you know someone with a backbit chip tester pro v2, it can test all the roms, both integer and applesoft. I assisted with that mod and I have the config file for that if you need it.
Really? Only these 3? What about address lines problem? Anyway, you can have all sorts of fancy cards, instruments, but with diagnostics one cannot only compensate for lack of them but perform better with smarter thinking. Your message looks to me as an ad of some useless chip tester.
Just wanted to close the thread out - I looked around (and even asked some Apple colleagues) to find a replacement E0 ROM - replacements were very expensive, and I didn't want to jump through the trying to build an adapter to get a EPROM replacement working for it. Given the cost/time factor, I decided to go with a ROMX. That installed very straightforward, and the additional ROM/Program options are welcome. Specifically the diagnostics ROM, that helped determine that one of the DRAMs was broken. That too was replaced with spare. The other thing I acquired was an original Disk Interface II card, and a wDrive floppy emulator - getting a B&H black colored drive seems excessively pricy on ebay due to its rarity. After fiddling with it a bit I'm able to load software from the SD card just fine.
One last thing I was wondering was why wasn't there any sound coming from the speaker (not even the boot beep). After reading through Gayler's 'The Apple II Circuit Description" it pointed me to a possible probelm with the 74LS74 Flip Flop IC located at J13 - which in this computer was missing! My guess is the school this computer was at disabled the speakers this way? Or maybe the flip flop was busted and making the computer screech? Who knows why it was missing. But I had one on hand and the beep is back, baby...
The 'stretch goals' would be to find the joystick adapter to connect to the IO controller port to play some games, and maybe a RAM expansion beyond 48k.
BHAppleII-MerryXmas.jpg
Now that the main OP's problem has been resolved in a very uninteresting and on my opinion irrational way, may I ask -- am I the only one here who is puzzled by the format of G monitor command? Elliott, how is it working with this syntax?
It's pretty simple, just the same syntax as used by the monitor's M and V commands. The monitor transfers the addresses preceding the < or . characters into locations in the zero page (#A2 $3E, #A4 $42 etc) and the program can retrieve them from there. It also calls the same entry points used by the M and V commands to iterate through the address range (#NXTA4 etc).
Glad you were able to get your machine going with the ROMX and that you are enjoying its extra features. When you're ready to expand the machine beyond 48K, there are plenty of options out there. You can go the 16K Language Card route or for roughly the same price add a 128K Saturn type RAM expansion. Many of those to choose from including our own RAMX128K. Just make sure you get one with at least a gold plated edge connector to avoid damage to the motherboard.