Bell & Howard Apple II - issues with stability and ROM CARD 600

16 posts / 0 new
Last post
Offline
Last seen: 3 days 23 hours ago
Joined: Nov 26 2024 - 20:56
Posts: 6
Bell & Howard Apple II - issues with stability and ROM CARD 600

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!

 

 

 

 

 

 

 

 

 

S.Elliott's picture
Offline
Last seen: 2 hours 30 min ago
Joined: Jun 23 2022 - 16:26
Posts: 239
FYI, that ROM card does

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  E000G  and 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.

  • To switch-on the ROM card, move the red switch to its "up" position and reset the computer by holding CTRL and pressing RESET
  • To switch-off the ROM card, move the red switch to its "down" positon and reset the computer as described above
Offline
Last seen: 3 days 23 hours ago
Joined: Nov 26 2024 - 20:56
Posts: 6
Apple2-IntBasic

 

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.

Online
Last seen: 58 min 28 sec ago
Joined: Jun 18 2010 - 13:54
Posts: 795
It's possible that one or

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!

Offline
Last seen: 3 days 23 hours ago
Joined: Nov 26 2024 - 20:56
Posts: 6
Jeff, is there a way to check

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.  

Offline
Last seen: 4 days 8 hours ago
Joined: Jan 31 2024 - 06:40
Posts: 229
ArcadeDanger wrote:Jeff, is
ArcadeDanger wrote:

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

 

 

Online
Last seen: 58 min 28 sec ago
Joined: Jun 18 2010 - 13:54
Posts: 795
 ArcadeDanger wrote:Jeff, is

 

ArcadeDanger wrote:

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.  

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.

S.Elliott's picture
Offline
Last seen: 2 hours 30 min ago
Joined: Jun 23 2022 - 16:26
Posts: 239
Checksum-computing routine and ROM checksums
ArcadeDanger wrote:

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.  

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 A5

    308:43 85 3D A0 00 84 06 84

    310:07 84 08 84 09 38 B1 3C

    318:65 06 85 06 A5 07 69 00

    320:85 07 A5 08 65 06 85 08

    328:A5 09 65 07 85 09 20 BA 

    330:FC 90 E3 A9 BD 20 ED FD

    338:A2 04 B5 05 20 DA FD CA

    340:D0 F8 8D 10 C0 60 00 

 

Step 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.346G

Step 4: Enter the following Monitor commands to print checksums of the four principal ROM chips currently installed in the ROM card.

    E000<300.E7FFG

    E800<300.EFFFG

    F000<300.F7FFG

    F800<300.FFFFG 

When 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.

 

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.  

S.Elliott's picture
Offline
Last seen: 2 hours 30 min ago
Joined: Jun 23 2022 - 16:26
Posts: 239
Checksums for Applesoft ROMs

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  C0A1  and 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.  The   C0A1   command should silently print  C0A1-  followed by a meaningless value (often A0) 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.D7FFG

    D800<300.DFFFG

    E000<300.E7FFG

    E800<300.EFFFG

    F000<300.F7FFG

    F800<300.FFFFG 

I 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.)

 

stivo's picture
Offline
Last seen: 8 hours 32 min ago
Joined: Nov 18 2017 - 03:36
Posts: 3
I think the Apple II plus F8 ROM checksum is wrong.

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?

 

 

 

 

Offline
Last seen: 3 days 23 hours ago
Joined: Nov 26 2024 - 20:56
Posts: 6
AppleIIPlus-BadAppleSoftROMs

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 

Offline
Last seen: 3 days 23 hours ago
Joined: Nov 26 2024 - 20:56
Posts: 6
stivo wrote:Using MAME,
stivo wrote:

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...

 

 

S.Elliott's picture
Offline
Last seen: 2 hours 30 min ago
Joined: Jun 23 2022 - 16:26
Posts: 239
Authentic vs non-authentic F8 ROM images
ArcadeDanger wrote:
stivo wrote:

Using MAME, OpenEmulator and my own emulator I'm getting: 7BE1E43F

Can someone verfy the correct result on real hardware?

 

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 7BE1E43F like 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?

 

S.Elliott's picture
Offline
Last seen: 2 hours 30 min ago
Joined: Jun 23 2022 - 16:26
Posts: 239
E0 ROM issue, maybe?
ArcadeDanger wrote:
 
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...

 

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 a BRK (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  E7C6L

 

Assuming the E0 ROM is working, it should look exactly like this:

stivo's picture
Offline
Last seen: 8 hours 32 min ago
Joined: Nov 18 2017 - 03:36
Posts: 3
re: Authentic vs non-authentic F8 ROM images

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.

Offline
Last seen: 3 days 23 hours ago
Joined: Nov 26 2024 - 20:56
Posts: 6
S.Elliott wrote:With the
S.Elliott wrote:
With the Applesoft ROMs active, try listing the ROM around that address with the command  E7C6L
 
I removed the E0 ROM off the board, checked for corrosion/broken legs and reseated it.  No change.  I ran your checksum against the e000 space and every time it computed a different number.  The results of running the E7C6L also came back different every single time.  Feels like I'll need to source a new E0...
Log in or register to post comments