iie enhancement upgrade strangeness

20 posts / 0 new
Last post
Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
iie enhancement upgrade strangeness

I recently bought an apple iie, used. I also bought an enhancement kit from Reactive Micro. The enhancement didn't work like I expected it to. Here is what happened:

 

I received the kit and did the install. I booted the machine and saw Apple //e, which was great. I then did the self test (CTRL-Closed Apple-Reset). It went to a crazy screen with different kinds of boxes all over it. It did some changes to the screen for 20-30 seconds and then said: System OK. I took this to be success.I rebooted, hit CTRL-RESET to get the ] basic prompt, typed in an obligatory basic program (hello, will; for infinity), ran it successfully and pressed CTRL-C when I got bored. Then I typed, call -151, to enter the monitor and then:

*300: A9 33 00

and*300L

which displayed my code:

0300-  A9 33 LDA #$33

0302- 00       BRK

...then, I tried executing the code:

*300g

Unexpectedly, it buzzed my floppy drive and continued seeking on the drive (no floppy in the drive)what should have happened, at least according to me, was, it should have displayed:

0304- A=33 X=FF Y=FF P=30 S=F0

and stopped*showing that the accumulator had been loaded with 33 hex (what my machine code told it to do).This works fine in the Virtual ][ emulator w/the enhanced iie and it worked fine with the unenhanced iie that I upgraded.

I replaced the original video rom and the problem persisted until I replaced both the CD and EF roms with the originals. It works fine with the new 65c02 chip, but not the ROMs. I talked with the Reactive folks and they sent me a second kit, but the result is the same with the new chips.

 

Help :). This should work as I've described, shouldn't it? If you have any thoughts on what might be at issue here, I'd appreciate it. I've done it several times and each time with the same result. I'm attaching a pic of the system and the identification from the board.

 

Thanks for any assistance you can provide.

 

Will

 

 

 

 

Offline
Last seen: 1 year 11 months ago
Joined: Mar 31 2020 - 19:55
Posts: 848
Have you done a memory fill

Have you done a memory fill (00 and FF) tand read back the adr ranges to ensure that r/w to your RAM is giving and storing the correct values? Also, try a fill of 00 02 03 04 05 06 07 ... ) to see if anything is being mirrored or otherwise gets stuck at a value. 

 

Also, what card if any is in your 0/EXP slot? I take it that your DuoDisk otherwise runs software properly and does proper r/w on both drives?

 

P.S. This wou;d get more attention in the Apple II Subforum. I only noticed it because it is a new topic, but it will fall off that list in short order.

 

 

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
Thanks. I'll move it over

Thanks. I'll move it over there and add details related to your asks. I don't know how to delete this one, or I would!

MacFly's picture
Offline
Last seen: 2 weeks 1 hour ago
Joined: Nov 7 2019 - 13:49
Posts: 442
The BRK instruction triggers

The BRK instruction triggers the 6502's interrupt routine. The Apple ROM will eventually execute the routine given by the address stored at $3F0/$3F1.

 

So, when entering the monitor, check if 3f0/3f1 were set correctly:

3f0L

=> 03f0: 59 FA ...

$FA59 is the ROM routine which dumps the registers and enters the monitor.

Also try executing $FA59 directly. See if this dumps registers as expected, or whether this results in a reboot:

FA59G

 

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
Timelord wrote:Have you done
Timelord wrote:

Have you done a memory fill (00 and FF) tand read back the adr ranges to ensure that r/w to your RAM is giving and storing the correct values? Also, try a fill of 00 02 03 04 05 06 07 ... ) to see if anything is being mirrored or otherwise gets stuck at a value. 

Yes:

10 for i = 768 to 853

20  poke i, i-768

30 next i

40 for j = 768 to 853

50  print peek(j),

60 next j

seemed fine.

 

Also, what card if any is in your 0/EXP slot? I take it that your DuoDisk otherwise runs software properly an

 If you mean the aux slot, nothing. The only other slots are numbered 1-7 and the duo disk card is in slot 6.

 

 

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
MacFly wrote:The BRK
MacFly wrote:

The BRK instruction triggers the 6502's interrupt routine. The Apple ROM will eventually execute the routine given by the address stored at $3F0/$3F1.

 

So, when entering the monitor, check if 3f0/3f1 were set correctly:

3f0L

=> 03f0: 59 FA ...

$FA59 is the ROM routine which dumps the registers and enters th

 

Hmm. 03f0.03f1 has 59 FA and running FA59G does display the registers, but no matter what 300 has, including 00 (BRK), 300G doesn't run the code there, the disk 1 light comes on, the drive does a seek, and then the drive light stays on, but the seeking stops. Control doesn't return unless I CTRL-Open-Reset or CTRL-Reset...

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
Also, just to clarify - it

Also, just to clarify - it doesn't matter what address I G to, except 0G, I get the same story:

0G (returns to [)

1G (buzz, lights, etc)

300G (buzz, lights, etc)

400G (buzz, lights, etc)

800G (buzz, lights, etc)

etc...

Offline
Last seen: 1 year 11 months ago
Joined: Mar 31 2020 - 19:55
Posts: 848
decuser wrote:Also, just to
decuser wrote:

Also, just to clarify - it doesn't matter what address I G to, except 0G, I get the same story:

0G (returns to [)

1G (buzz, lights, etc)

300G (buzz, lights, etc)

400G (buzz, lights, etc)

800G (buzz, lights, etc)

etc...

 

 

 

You should certainly talk to Henry about this. He is a brilliant man with a lot of experience, and if there is a fault wither in the ROM images that he is using, or on your machine--or if you are somehow hitting an address that has been remapped--he would be able to help. 

 

I have several enhanced //e systems, but none with the ReActive ROMs. If you want to post the entire monitor programme and so forth, I could try it, but my system is wildly different from your nearly stock machine. 

 

For whatever it is worth, it doesn't seem as if you are doing anything that requires the enhancement kit. You are running a DuoDisk and using core software, so IDK why you went after the ENH upgrade. What features of it are you planning to use?

 

Magnificat's picture
Offline
Last seen: 3 months 1 week ago
Joined: Mar 16 2020 - 12:53
Posts: 32
I have a Courbis RM

I have a Courbis RM Enhancement chip set i purchased back in April or May 2020 and installed and here is the output on my apple IIe. This is a Rev A motherboard with the enhancement kit.  You can see pictures of it in my other thread about the double hi res graphics not working on my Rev A board which alas isn't supported.  But you can see the Courbis kit installed with the Silver Reflective CD and other labels on the chips which i left there for indication its enhanced with a Kit.

 

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
Timelord wrote:For whatever
Timelord wrote:For whatever it is worth, it doesn't seem as if you are doing anything that requires the enhancement kit. You are running a DuoDisk and using core software, so IDK why you went after the ENH upgrade. What features of it are you planning to use?

I don't have any particular need ATM, just seemed like the thing to do. Eventually, I'll get a floppy emulator and run Merlin and other software.

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
Magnificat wrote:I have a
Magnificat wrote:

I have a Courbis RM Enhancement chip set i purchased back in April or May 2020 and installed and here is the output on my apple IIe. This is a Rev A motherboard with the enhancement kit. 

Yeah, this is what I expected it to do. Ah, well. I'll wait to see if any more suggestions or advice are forthcoming. Maybe somebody will have seen this behavior before.

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
decuser wrote:Hmm. 03f0.03f1
decuser wrote:
Hmm. 03f0.03f1 has 59 FA and running FA59G does display the registers, but no matter what 300 has, including 00 (BRK), 300G doesn't run the code there, the disk 1 light comes on, the drive does a seek, and then the drive light stays on, but the seeking stops. Control doesn't return unless I CTRL-Open-Reset or CTRL-Reset...
 

 Except that FA59G works, odd... and confusing. I wonder why it works, but not 300, 800, etc?

MacFly's picture
Offline
Last seen: 2 weeks 1 hour ago
Joined: Nov 7 2019 - 13:49
Posts: 442
decuser wrote:03f0.03f1 has
decuser wrote:
03f0.03f1 has 59 FA and running FA59G does display the registers, but no matter what 300 has, including 00 (BRK), 300G doesn't run the code there, the disk 1 light comes on, the drive does a seek, and then the drive light stays on, but the seeking stops. Control doesn't return unless I CTRL-Open-Reset or CTRL-Reset...

 

Well, I'm sure "300G" will still run the code. The issue is the BRK instruction. This triggers the IRQ handler (at $FFFE/$FFFF), which is located in the ROMs - and shared between IRQ and BRK. This runs a number of checks to determine whether an actual IRQ was triggered and needs to be handled. Otherwise it runs the BRK handler (at $3f0). The BRK handler is properly set ($FA59 at $3f0) and you say directly executing $FA59 results in the normal behaviour. So the issue must be in those checks to distinguish IRQ from BRK.

I haven't checked what has changed with the IRQ code in the newer enhanced ROMs. But I'd assume that your machine has some kind of issue which results in the new IRQ routine eventually triggering a RESET, rather than executing the expected BRK handler.

Try:

300: A9 33 4C DA FD

300G

This should print the value of the A register and return to the monitor. When this works, then you know executing code at $300 works fine, and it's just the IRQ vs BRK routine failing.

Online
Last seen: 1 hour 18 min ago
Joined: Jun 18 2010 - 13:54
Posts: 734
MacFly wrote:This runs a
MacFly wrote:
This runs a number of checks to determine whether an actual IRQ was triggered and needs to be handled.
 

 Just to clarify, BRK and IRQ share the same interrupt vector. The code only needs to check the Status register "B" flag to determine if a BRK was executed.

decuser's issue is certainly strange. It wasn't clear if all G commands (except 0G) did the same thing no matter what data was there. If the issue truly only happens when a break instruction is executed, then I would suspect something with the SLOT3ROM softwswitching (i.e. bad MMU?). The IRQ/BRK handler is located at $C3FA in the enhanced ROM set. This requires that the main ROM is active when the BRK occurs. It seems like the slot ROM might be active instead which could lead to weird results like trying to activate a disk controller card. Note that this differs from the non-enhanced ROMs which have the INT/BRK handler at FA40 like the Apple II+.

 

Or it could be that BOTH enhanced ROM sets are bad.

 

MacFly's picture
Offline
Last seen: 2 weeks 1 hour ago
Joined: Nov 7 2019 - 13:49
Posts: 442
jeffmazur wrote:This requires
jeffmazur wrote:
This requires that the main ROM is active when the BRK occurs. It seems like the slot ROM might be active instead which could lead to weird results like trying to activate a disk controller card. Note that this differs from the non-enhanced ROMs which have the INT/BRK handler at FA40 like the Apple II+.

 

Very good. I hadn't checked the location of the handler with the old ROM, but it's almost conclusive now. The location of the IRQ/BRK handler has moved to the SLOT ROM area with the new ROMs, so when ROM switching has a defect, then the handler would still have worked with the old, but not with the new ROMs. Since it's unlikely that Henry sent out two sets of defective ROMs, I'm pretty convinced that that is going to be the issue.

 

Try a manual dump of IRQ/BRK handler with the new ROMs.

Enable the slot ROM by writing to $C007 and then dump the handler:

C007: 01

C3FAL

And the new ROMs should show the handler:

 

Just for comparison, this is what the area looked like with the old, unenhanced ROMs (no handler at $C3FA and $C400 was used for something else):

C007: 01

C3FAL

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
MacFly wrote:Well, I'm sure
MacFly wrote:

Well, I'm sure "300G" will still run the code. The issue is the BRK instruction. This triggers the IRQ handler (at $FFFE/$FFFF), which is located in the ROMs - and shared between IRQ and BRK. This runs a number of checks to determine whether an actual IRQ was triggered and needs to be handled. Otherwise it runs the BRK handler (at $3f0). The BRK handler is properly set ($FA59 at $3f0) and you say directly executing $FA59 results in the normal behaviour. So the issue must be in those checks to distinguish IRQ from BRK.

I haven't checked what has changed with the IRQ code in the newer enhanced ROMs. But I'd assume that your machine has some kind of issue which results in the new IRQ routine eventually triggering a RESET, rather than executing the expected BRK handler.

Try:

300: A9 33 4C DA FD

300G

 Good call, it worked fine. I couldn't have expressed it before, but I had a sneaky suspicion that it had to be executing the code because, how could it not, there's not much code to read the input, decode it, and execute it... but assembly's not my first language. This makes a lot more sense. I have no idea how to fix it, but this is progress!

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
MacFly wrote:jeffmazur wrote
MacFly wrote:
jeffmazur wrote:
This requires that the main ROM is active when the BRK occurs. It seems like the slot ROM might be active instead which could lead to weird results like trying to activate a disk controller card. Note that this differs from the non-enhanced ROMs which have the INT/BRK handler at FA40 like the Apple II+.

 

etc...

 

Wow. Y'all are good. I'm travelling this morning, but will test it when I get back this afternooon!

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
MacFly wrote:Try a manual
MacFly wrote:

Try a manual dump of IRQ/BRK handler with the new ROMs.

Enable the slot ROM by writing to $C007 and then dump the handler:

C007: 01

C3FAL

 

 I did the enable and dump and got identical output to what you showed. Is this a good sign? I really don't understand the ROM switching discussion, but is there a way to test that?

MacFly's picture
Offline
Last seen: 2 weeks 1 hour ago
Joined: Nov 7 2019 - 13:49
Posts: 442
decuser wrote: I did the
decuser wrote:

 I did the enable and dump and got identical output to what you showed. Is this a good sign?

 

Well, it's a good sign in the sense that the ROM bank was properly enabled, so the CPU should be able to correctly execute code from this ROM area. So this did *not* confirm our theory that something was broken about the switching of the lower ROM area. Well, at least, it's not a simple, obvious issue (so that's a bad sign, since it may be more complicated).

Offline
Last seen: 3 years 2 months ago
Joined: Nov 5 2020 - 11:41
Posts: 14
received replacement and same story

So, I got some replacement roms from Bulgaria, but the result was the same. Any ideas what to try next?

Log in or register to post comments