7

I recently purchased an Apple //e online as well as a BMOW Floppy Emu in order to emulate some disk images. After working with it successfully for awhile, this monitor consistently appeared in lieu of the expected program. This occured after many resets/power cycles over the course of a few hours.

System details:

  • Apple //e model A2S2064
  • A Software Dimensions Inc Firmware ID Card (apparently used for some kind of accounting software)
  • DataLink 1200 Modem
  • Super Serial Card II
  • Apple IIe 80 Column / 64k RAM Expansion Card
  • duodisk drive

This monitor consistently appears when:

  • Booting from the duodisk
  • Booting from the BMOW Floppy Emu
  • Booting from multiple diffent physical disks via the duodisk
  • Booting from different emulated disk images via the BMOW Floppy Emu
  • Booting ProDOS

Attempted "fixes":

  • Ensuring all cards are properly connected
  • Leaving the computer sit for a few hours without operation (shows monitor on boot)
  • Removing all "unnecessary" cards (super serial, the weird firmware id card, memory expansion, and data link modem) and attempting to boot (shows monitor on boot)
  • Removing ALL cards and booting into BASIC (successful)

Why would this monitor consistently appear when attempting to boot from floppy? What types of debugging techniques can be used to find the root cause of this issue?

Monitor when booting a ProDOS disk: Original monitor on arbitrary ProDOS image

Monitor when booting a DOS3.3 disk: Monitor on Dos3.3 image

Improve this question
10
  • 1
    I'm not familiar with Apple ][, but I'm sure it's the system monitor which is meant for debugging, and yes, it's a memory dump. "The system monitor is identified with an asterisk for a prompt. If you have one of the earliest versions of the Apple II ROM, you will be placed in the monitor immediately on powerup." wiki.apple2.org/index.php?title=System_Monitor
    – 比尔盖子
    Jun 12, 2019 at 7:57
  • 1
    You might want to add what Apple IIe model, what memory, which DOS. Also, just looking if everything is plugged doesn't change symptoms. Unplugging all cards, resettle chips and firmly plug everything again is the way to go - with all hardware, not just IIs
    – Raffzahn
    Jun 12, 2019 at 8:36
  • I've updated my question with more details on system specs and what I've tried so far.
    – Steven Goodman
    Jun 12, 2019 at 9:10
  • 2
    On a 128KiB model Prodos boot into Language Card space. So if you're saying this happenes during boot, then it might be during relocation phase. Please pull all unneeded cards. Basically everything but 80col and Disk.
    – Raffzahn
    Jun 12, 2019 at 9:16
  • 2
    You often end up in the monitor when executed code goes wrong (for example, because it was loaded incorrectly). First pull all cards, see if you can start up and land in BASIC. If this doesn't work, the problem is with the Apple itself. If it works, add Floppy EMU and boot a DOS 3.3. disk. If that fails, it's a problem with the Floppy EMU card and/or the disk images. Continue debugging this way until you've narrowed down the problem.
    – dirkt
    Jun 12, 2019 at 9:32

4 Answers 4

Reset to default
7

If your Apple is dropping you at the monitor, it means it tried to execute some set of instructions that went off the rails somehow. I'll admit I am fuzzy on all the details, but generally you can attribute that to either the Apple motherboard, or a peripheral, or code. The trick is to do a series of isolation steps to keep reducing complexity until you can pinpoint the culprit.

For example, removing ALL cards from the Apple and powering on seems to work as expected, which would indicate the core system is a-ok.

Next, you want to add cards one by one, starting with the disk controller card. If adding the disk controller card and trying to boot from a clean DOS 3.3 disk causes the problem to return, then you know the problem is with either the controller card, the duodisk, or the DOS 3.3 disk (because you've eliminated/removed all other possibilities from the system).

At this point, you can try one or more alternate disks. If the problem persists across multiple disks, you can safely rule out a single bad disk and focus on either the Duodisk hardware or the controller card.

This is when having some extra junk laying around really helps because now is a good time to apply some basic swaptronics troubleshooting. Swap the controller card but keep the duodisk. Does the problem go away? Then it's the original controller... does the problem persist? Try swapping the duodisk. Does the problem go away? etc.

Backing up a few steps, if you reinstall the disk controller card, connect the duodisk and boot a DOS 3.3 disk without any problem, then you would draw the conclusion those components are all working as expected and add the next most basic card into the system (probably the 80 column card). rinse and repeat.

Ultimately, you should be able to narrow things down to a single item (the disk controller card, or the duodisk hardware, or a bad memory expansion, or whatever).

Improve this answer
7

What kind of error is this and how can I remedy it?

To start with, this isn't an error, but the monitor program.

Look here for a short command list - and Apple Monitors Peeled for in detail information.

To leave it press CTRL-C - or RESET. It's an Apple II, so RESET will always help and bring the system into a default state while destroying as little as possible.

Now, why the system enters the monitor during floppy operation can not even be speculated, at least not in a serious manner.

  • It may be a defect on the controller side, so try unplugging, resettle all chips and plug in again - the old pull the plug routine.

  • It could be software as well. Was it always the same program/disk?

    Maybe the data loaded is placed into page three and corrupts the cold start vector?

  • The monitor is also the default target for any unserved interrupt. Which again may have any random source - no way to tell without more information.

    This includes code running into a 00-byte which will trigger a debug interrupt - here dropping into the monitor is after all intended behaviour to allow debugging.

As said before, pure guessing at this information level.

Does the dump on screen have any meaning

Jau, it shows you some memory locations - 8 bytes with every press of return :))

$B8xx is somewhere at the top of the first 48 KiB of RAM, depending on the Apple model and DOS you're using this might be some part of DOS code. But without more information it's hard to tell more. Often (not always) the first displayed address is the one where the interrupt has that - so not really useful, except telling that the CPU was just running some DOS code.

Improve this answer
1
  • I was able to replicate this same behavior of showing this monitor with a handful of different physical disks and different emulated disks. Will update my question with more details after performing some more "physical" debugging.
    – Steven Goodman
    Jun 12, 2019 at 8:11
4

FWIW, starting after the first FB (which appears to be the end of a previous instruction), this disassembles as:

Lb8c9               lda $bb00,y
                    lsr $bc00,x
                    rol a
                    lsr $bc00,x
                    rol a
                    sta ($3e),y
                    iny
                    cpy $26
                    bne Lb8c6
                    rts

Lb8dc               ldy #$20
Lb8de               dey
                    beq Lb942
Lb8e1               lda $c08c,x
                    bpl Lb8e1
Lb8e6               eor #$d5
                    bne Lb8de
                    nop
Lb8eb               lda $c08c,x
                    bpl Lb8eb
                    cmp #$aa
                    bne Lb8e6
                    ldy #$56
Lb8f6               lda $c08c,x
                    bpl Lb8f6
                    cmp #$ad
                    bne Lb8e6
                    lda #$00
                    dey
                    sty $26
                    ldy $c08c,x
                    bpl L0000

Posted and wikified in case anyone more knowledgeable of the Apple ][ can do anything with it! (Disassembly courtesy of https://www.white-flame.com/wfdis/).

Improve this answer
3
  • Standard DOS 3.3 code.
    – Nick Westgate
    Jun 12, 2019 at 9:39
  • 1
    But according to the OP this is supposed to be a Prodos Disk.
    – Raffzahn
    Jun 12, 2019 at 10:27
  • 1
    @Raffzahn Yeah, but ProDOS lives mostly in the Language Card. Maybe he partially succeeded in booting DOS prior to this and didn't power off. Anyway, IMHO he really does need to seek help at a forum.
    – Nick Westgate
    Jun 18, 2019 at 23:35
3

As others have mentioned, the Apple will drop to the monitor when it attempts to execute code that doesn't make sense (illegal/invalid instructions for example). As you have mentioned, it works fine when you boot the machine without the disk controller card inserted. This is good because it at least suggests the core system should be OK.

The Apple II will attempt to boot the first disk controller that it finds (descending from slot 7 down to 1) when you turn it on. The non-disk controller cards are probably not contributing to the problem, so I would focus on the disk controller.

First off, I would remove the disk controller and attempt the system test. This is done by holding down the closed apple (the one on the right of the keyboard) and pressing control-reset. This will do a system test that takes ~20 seconds. If it comes back with "System OK" then things are probably good with the Apple itself.

Second, put the disk controller back in with the DuoDisk attached. Put in a disk that should work. Power on and I presume you'll hit the monitor. See if you can press Control-C and then hit return and get to the BASIC prompt. If it doesn't go to BASIC, something is screwy beyond this. Most likely it will and you should be able to type "NEW" as a sample command without error.

Assuming the disk controller is installed in Slot 6 (its default location on the Apple II), type PR#6 and hit return. If you're in the monitor, you could type C600G and hit return to effectively do the same thing. This should cause the disk to boot.

My suspicion is that the controller card PROM is corrupt for some reason. If the PR#6 or C600G doesn't cause the disk to boot (and make the head alignment chatter), then I'd say that this suspicion is correct. However, let us know if it actually boots instead.

If the controller is no good, you should be able to find a replacement on eBay without too much difficulty.

Improve this answer
2
  • 1
    Thanks for the advice. Running PR#6 while in BASIC causes it to attempt to read (head alignment chatter for the duodisk and "READ" state for the floppy emu) so your suspicion of the controller card having issues may be it. I will see if another controller card solves the problem.
    – Steven Goodman
    Jun 13, 2019 at 0:39
  • 1
    I'm thinking it is the card and not something with the drive because you said the FloppyEmu shows the same problem. I've had a DuoDisk controller go bad on me in the last few years though despite swapping out half of the chips it still holds the RESET line. But despite that not being your issue, during my journey I did come to realize that finding replacement PROMs is very difficult so its just better to replace the card for ~$15-20 instead.
    – bjb
    Jun 13, 2019 at 12:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .