mort@apollo.HP.COM (Stephen Moriarty) (03/29/91)
I have an APIC-A parallel interface card. I'm attempting to hook
it up to a Qume Sprint-5 printer. The first incompatibility I
know of is that the APIC-A wants an ACK* (active low) signal, but
the printer doesn't have it. I've attempted to recreate it from
the signals the printer does have, with limited success. If I do
]pr #1, I get what I type on the printer, but I get a dump of
some memory address, as though I was in the monitor, following
the first character I type at the ] prompt, and following a
RETURN. Is the APIC-A compatible with the enhanced //e? The EPROM
has a label marked, "APIC-A c.1983".
Failing that, I'd like to debug the firmware. I've listed it out
from the Apple monitor. If I had a printer interface, I could get
a hardcopy ;(. I'm reading the chapter on the monitor in the //e
Technical Reference Manual, but don't see anything about single
stepping, or setting breakpoints. There must be an indirect way
to do this, perhaps using the BRK instruction. I thought of
copying the card's firmware to RAM and putting the RAM copy
starting address in CSW, you know, the COUT vector. I could then
use BRK instructions (can I?) to figure out what's going on.
That's so much easier than reading the instructions and
predicting the code execution.
Also, is there a way to redirect output to disk? I would like to
list the code to disk and be able to examine it with an editor.
Thanks for any and all help.
ARPA: mort@apollo.hp.com UUCP: ...{decvax, umix, mit-eddie}!apollo!mort
Apollo, a subsidiary of Hewlett Packard, 300 Apollo Drive, Chelmsford, MA. 01824
Argue for your limitations, and they are yours.parkern@jacobs.CS.ORST.EDU (Neil Parker) (03/30/91)
In article <50a3ec40.20b6d@apollo.HP.COM> mort@apollo.HP.COM (Stephen Moriarty) writes: >I have an APIC-A parallel interface card. [...] > If I do >]pr #1, I get what I type on the printer, but I get a dump of >some memory address, as though I was in the monitor, following >the first character I type at the ] prompt, and following a >RETURN. Is the APIC-A compatible with the enhanced //e? The EPROM >has a label marked, "APIC-A c.1983". I have never owned (or even seen) an APIC-A parallel interface card, but your problem sounds familiar anyway. It seems that back when my mother upgraded the old Apple ][+ to a //e, her parallel interface card (a Tymac PPC-100) suddenly started spewing garbage (which looked like monitor dumps) at seemingly random intervals. The reason turned out to be that the Tymac was incompatible with the //e ROMs. It seems that a common technique used by interface cards to find out what slot they're in is to call an RTS instruction in the monitor and examine the return address that the JSR pushed onto the stack. Apple guarantees that there will always be an RTS at $FF58 for this very purpose. Unfortunately, the Tymac doesn't call $FF58--it calls $FDFF instead. On the Apple ][+ there was an RTS at $FDFF, so everything worked just fine. However, on the enhanced //e, that RTS was replaced with some other instruction (I think it was a NOP), so instead of returning execution fell through to $FE00, which is part of the monitor's memory dump routine. (Moral: Never call unpublished entry points in the ROM.) While I can't guarantee that this is the cause of your problems, I suspect it's probably worth adding to your list of possible causes. >Failing that, I'd like to debug the firmware. I've listed it out >from the Apple monitor. If I had a printer interface, I could get >a hardcopy ;(. I'm reading the chapter on the monitor in the //e >Technical Reference Manual, but don't see anything about single >stepping, or setting breakpoints. Unfortunately, Apple took out the built-in step and trace functions when they introduced the Apple ][+, and they've never been put back in (the Apple IIGS monitor has the "s" and "t" commands restored to it, but there's no built-in code for them--you have to supply your own stepping and tracing routines). If you insist on tracing the code, I would probably recommend getting a debugger. >ARPA: mort@apollo.hp.com UUCP: ...{decvax, umix, mit-eddie}!apollo!mort - Neil Parker -- Neil Parker No cute ASCII art...no cute quote...no cute parkern@jacobs.cs.orst.edu disclaimer...no deposit, no return... parker@corona.uoregon.edu (This space intentionally left blank: )
parkern@jacobs.CS.ORST.EDU (Neil Parker) (03/31/91)
In article <50a3ec40.20b6d@apollo.HP.COM> mort@apollo.HP.COM (Stephen Moriarty) writes: >[...stuff about non-functional APIC-A parallel interface card...] >Failing that, I'd like to debug the firmware. I've listed it out >from the Apple monitor. If I had a printer interface, I could get >a hardcopy ;(. Sorry for posting two separate followups to the same article, but I didn't think of this until after I sent the first article off on its way to net-land... In spite of the monitor-dump garbage you've been getting, it may still be possible to get printouts of simple stuff like BASIC or machine-language listings, assuming your interface works like most other parallel interfaces. 1. Make sure the interface is in slot 1. 2. Enter the following machine language program into the monitor: 300:A9 B 85 36 A9 3 85 37 4C EA 3 2C C1 C1 30 FB 310:48 29 7F 8D 90 C0 68 60 Check your work by typing "300L"--you should see something like this: 0300- A9 0B LDA #$0B 0302- 85 36 STA $36 0304- A9 03 LDA #$03 0306- 85 37 STA $37 0308- 4C EA 03 JMP $03EA 030B- 2C C1 C1 BIT $C1C1 030E- 30 FB BMI $030B 0310- 48 PHA 0311- 29 7F AND #$7F 0313- 8D 90 C0 STA $C090 0316- 68 PLA 0317- 60 RTS 3. Activate the printer by giving the BASIC command "CALL 768" if you're using DOS 3.3, or "PR#A$30B" if you're using ProDOS. If everything works out, all your commands should start going to the printer instead of the screen. Note that this simple driver does none of the fancy things that the interface can do--i.e. no control-I 80N is available. If everything comes out on one line, try to find a DIP switch on your printer to turn on automatic line feed after carriage return. If your printer doesn't have such a switch, add the following machine code to the driver: 316:C9 D D0 4 A9 A D0 F5 68 60 The modified driver should look like this when you type "300L": 0300- A9 0B LDA #$0B 0302- 85 36 STA $36 0304- A9 03 LDA #$03 0306- 85 37 STA $37 0308- 4C EA 03 JMP $03EA 030B- 2C C1 C1 BIT $C1C1 030E- 30 FB BMI $030B 0310- 48 PHA 0311- 29 7F AND #$7F 0313- 8D 90 C0 STA $C090 0316- C9 0D CMP #$0D 0318- D0 04 BNE $031E 031A- A9 0A LDA #$0A 031C- D0 F5 BNE $0313 031E- 68 PLA 031F- 60 RTS If your interface works like every other parallel interface I've ever seen, then one of these drivers ought to work. In most parallel interfaces, the byte at $CnC1 (n=slot number) is negative when the printer is busy and positive when it's ready for data, and the data is written by storing it at $C0n0 (n=slot number+8). Good luck! - Neil Parker -- Neil Parker No cute ASCII art...no cute quote...no cute parkern@jacobs.cs.orst.edu disclaimer...no deposit, no return... parker@corona.uoregon.edu (This space intentionally left blank: )
mturner@convex.com (Mike P. Turner) (04/03/91)
>I have never owned (or even seen) an APIC-A parallel interface card, but >your problem sounds familiar anyway. It seems that back when my mother >upgraded the old Apple ][+ to a //e, her parallel interface card (a Tymac >PPC-100) suddenly started spewing garbage (which looked like monitor dumps) >at seemingly random intervals. The reason turned out to be that the Tymac >was incompatible with the //e ROMs. > >It seems that a common technique used by interface cards to find out what >slot they're in is to call an RTS instruction in the monitor and examine >the return address that the JSR pushed onto the stack. Apple guarantees >that there will always be an RTS at $FF58 for this very purpose. >Unfortunately, the Tymac doesn't call $FF58--it calls $FDFF instead. On >the Apple ][+ there was an RTS at $FDFF, so everything worked just fine. >However, on the enhanced //e, that RTS was replaced with some other >instruction (I think it was a NOP), so instead of returning execution fell >through to $FE00, which is part of the monitor's memory dump routine. > I had the same problem with a TYMAC card when I upgraded my ][e. I had to modify the code and then create a new eprom. If someone is having similiar problems I'd be willing to try to fix their printer card. If interested send me some email at mturner@convex.com. Mike Turner mturner@convex.com Convex Computer Corporation 214-497-4834
mort@apollo.HP.COM (Stephen Moriarty) (04/19/91)
In article <1991Mar30.131325.24160@lynx.CS.ORST.EDU>: >It seems that a common technique used by interface cards to find out what >slot they're in is to call an RTS instruction in the monitor and examine >the return address that the JSR pushed onto the stack. Apple guarantees >that there will always be an RTS at $FF58 for this very purpose. >Unfortunately, the Tymac doesn't call $FF58--it calls $FDFF instead. On >the Apple ][+ there was an RTS at $FDFF, so everything worked just fine. >However, on the enhanced //e, that RTS was replaced with some other >instruction (I think it was a NOP), so instead of returning execution fell >through to $FE00, which is part of the monitor's memory dump routine. BINGO! I just changed two references to $FDFF in the driver firmware to $FF58, reprogrammed the EPROM, and voila! it works! Thanks for the help. ARPA: mort@apollo.hp.com UUCP: ...{decvax, umix, mit-eddie}!apollo!mort Apollo, a subsidiary of Hewlett Packard, 300 Apollo Drive, Chelmsford, MA. 01824 Argue for your limitations, and they are yours.