Does anybody know (or can point me in the right direction) of a byte sequence for a peripheral card that will autoboot from the monitor and allow for BASIC I/O entry points? As far as I can tell, this area overlaps, and you would end up running undocumented opcodes for the BASIC I/O.
For reference, my understanding is that the Auto boot sequence is looking for:
cn01: 20
cn03: 00
cn05: 03
cn07: 3c

And BASIC Init, In, Out are at cn00, cn05, and cn07 respectively. I think this means $03 (SLO) and $3C (NOP) would be run, which are undocumented opcodes. Also, $20 would need to play some part in the init sequence, either as a JSR, or address byte, or something. The area is so tight that I can't figure out a solution even when running the illegal ops. Thanks for any help.

On Tuesday, June 8, 2021 at 11:49:51 AM UTC-7, epoo...@gmail.com wrote:
> Does anybody know (or can point me in the right direction) of a byte sequence for a peripheral card that will autoboot from the monitor and allow for BASIC I/O entry points?
[...]
> And BASIC Init, In, Out are at cn00, cn05, and cn07 respectively.

All BASIC does is redirect $36/37 or $38/39 to $Cn00. It's up to the card firmware to send it somewhere else. I'm looking at Applesoft's PR_NUMBER, which just calls the monitor OUTPORT (https://6502disassembly.com/a2-rom/Applesoft.html#SymPR_NUMBER and https://6502disassembly.com/a2-rom/AutoF8ROM.html#SymOUTPORT).

Looking at an emulated Apple //e, the 80-column firmware at $C82A sets $36/37 to $c307, and $38/39 to $C305. You should be able to set these wherever you want, so long as you're not trying to pretend to be an 80-column card in slot 3... $C305/C307 are documented entry points.

What are you trying to do?

"epoo...@gmail.com" <epooches@gmail.com> writes:

> Does anybody know (or can point me in the right direction) of a byte
> sequence for a peripheral card that will autoboot from the monitor and
> allow for BASIC I/O entry points? As far as I can tell, this area
> overlaps, and you would end up running undocumented opcodes for the
> BASIC I/O.
> For reference, my understanding is that the Auto boot sequence is looking for:
> cn01: 20
> cn03: 00
> cn05: 03
> cn07: 3c
>
> And BASIC Init, In, Out are at cn00, cn05, and cn07 respectively. I
> think this means $03 (SLO) and $3C (NOP) would be run, which are
> undocumented opcodes. Also, $20 would need to play some part in the
> init sequence, either as a JSR, or address byte, or something. The
> area is so tight that I can't figure out a solution even when running
> the illegal ops. Thanks for any help.

I think those constants are ID-bytes only for disk-controllers, if I
remember right.

For character I/O cards like the Super Serial Card, they do support the
Cx05 and Cx07 entry points, and they do it like:

C100: 2C 58 FF BIT $FF58 ; known $60 byte; set the V-flag, denoting PR# or IN# entry
C103: 70 0C BVS $C111 ; boot entry
C105: 38 SEC
C106: 90 ; fake BCC opcode that never branches, but skips the CLC
C107: 18 CLC
C108: B8 CLV ; clear V-flag, denoting "already initialized" entry
....

Notice how this code has none of those ID-bytes. But you cannot boot
DOS or ProDOS from a Super Serial Card. :)

If you wanted something that could handle character I/O and boot like a
disk drive, well, yes, those illegal opcodes are not going to work.

--
Jerry awanderin at gmail dot com

Welp, on reviewing the AppleSoft BASIC disassembly and the monitor, I am quite sure you are right. It seems strange because almost every Apple peripheral card follows this I/O convention, and it is documented here:
https://fabiensanglard.net/fd_proxy/prince_of_persia/Inside%20the%20Apple%20IIe.pdf#page=382
I think I confused its reference to "Applesoft" with "Applesoft BASIC" which does not even use this convention.
I am pretty sure this is just for programs that need access to the card's IO. Like maybe a communications program would not care what ACIA a serial card had if it could use those addresses for IO.
But for my purposes, I think as long as IN# and and PR# will work, and I can boot from it, I am not worried about other programs directly accessing those functions.

Thanks your help and time.

On Tuesday, June 8, 2021 at 9:42:05 PM UTC-7, fadden wrote:
> On Tuesday, June 8, 2021 at 11:49:51 AM UTC-7, epoo...@gmail.com wrote:
> > Does anybody know (or can point me in the right direction) of a byte sequence for a peripheral card that will autoboot from the monitor and allow for BASIC I/O entry points?
> [...]
> > And BASIC Init, In, Out are at cn00, cn05, and cn07 respectively.
> All BASIC does is redirect $36/37 or $38/39 to $Cn00. It's up to the card firmware to send it somewhere else. I'm looking at Applesoft's PR_NUMBER, which just calls the monitor OUTPORT (https://6502disassembly.com/a2-rom/Applesoft.html#SymPR_NUMBER and https://6502disassembly.com/a2-rom/AutoF8ROM.html#SymOUTPORT).
>
> Looking at an emulated Apple //e, the 80-column firmware at $C82A sets $36/37 to $c307, and $38/39 to $C305. You should be able to set these wherever you want, so long as you're not trying to pretend to be an 80-column card in slot 3... $C305/C307 are documented entry points.
>
> What are you trying to do?

In article <ba9967f7-f576-4fac-a297-a17422bdabf0n@googlegroups.com>,
epoo...@gmail.com <epooches@gmail.com> wrote:
>Does anybody know (or can point me in the right direction) of a byte
>sequence for a peripheral card that will autoboot from the monitor and
>allow for BASIC I/O entry points? As far as I can tell, this area
>overlaps, and you would end up running undocumented opcodes for the
>BASIC I/O.
>For reference, my understanding is that the Auto boot sequence is looking for:
>cn01: 20
>cn03: 00
>cn05: 03
>cn07: 3c
>
>And BASIC Init, In, Out are at cn00, cn05, and cn07 respectively. I
>think this means $03 (SLO) and $3C (NOP) would be run, which are
>undocumented opcodes. Also, $20 would need to play some part in the init
>sequence, either as a JSR, or address byte, or something. The area is so
>tight that I can't figure out a solution even when running the illegal
>ops. Thanks for any help.

I think it is intended to not be possible to have a card which can boot,
and which supports the standard character I/O interface.

Why do you want to do character in/out, and be bootable? It's likely if you
only wanted to support PR#n and IN#n and not much else to use non-standard
entry points: just update $36/37 or $38/39 to your entry points, and DOS/
ProDOS/Applesoft will work fine. But other programs expecting the Pascal
entry points will not work.

Kent

Kent,
Thanks for your thoughts. I agree, and that is my current plan. I think I have plenty of space to use the Pascal entry-point table though. It is just the "Applesoft" (not BASIC!) entry-points that will not work (whatever those are). My feeling is that those may have not been used much as several Apple cards did not comply with that standard anyway, so no big loss.
I want to have I/O and be bootable because I had plenty of space on the peripheral card ROM for the driver and the user interface for the card. Then, I thought it would be a nice feature to boot straight to the UI if there aren't any other boot devices installed, or if it is installed in slot 7, and make a stand-alone work station.
Thanks again,
--Eric
On Thursday, June 10, 2021 at 7:45:11 AM UTC-7, Kent Dickey wrote:
> In article <ba9967f7-f576-4fac...@googlegroups.com>,
> epoo...@gmail.com <epoo...@gmail.com> wrote:
> >Does anybody know (or can point me in the right direction) of a byte
> >sequence for a peripheral card that will autoboot from the monitor and
> >allow for BASIC I/O entry points? As far as I can tell, this area
> >overlaps, and you would end up running undocumented opcodes for the
> >BASIC I/O.
> >For reference, my understanding is that the Auto boot sequence is looking for:
> >cn01: 20
> >cn03: 00
> >cn05: 03
> >cn07: 3c
> >
> >And BASIC Init, In, Out are at cn00, cn05, and cn07 respectively. I
> >think this means $03 (SLO) and $3C (NOP) would be run, which are
> >undocumented opcodes. Also, $20 would need to play some part in the init
> >sequence, either as a JSR, or address byte, or something. The area is so
> >tight that I can't figure out a solution even when running the illegal
> >ops. Thanks for any help.
> I think it is intended to not be possible to have a card which can boot,
> and which supports the standard character I/O interface.
>
> Why do you want to do character in/out, and be bootable? It's likely if you
> only wanted to support PR#n and IN#n and not much else to use non-standard
> entry points: just update $36/37 or $38/39 to your entry points, and DOS/
> ProDOS/Applesoft will work fine. But other programs expecting the Pascal
> entry points will not work.
>
> Kent

FWIW, there's a pretty good explanation of BASIC vs. Pascal 1.0 vs. Pascal 1.1 entry points and such in the Super Serial Card manual. I get the sense that "BASIC" is mostly used in the "not Pascal" sense, rather than indicating that Applesoft or Integer BASIC is somehow tightly coupled.

https://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Interface%20Cards/Serial/Apple%20II%20Super%20Serial%20Card/Manuals/Apple%20II%20Super%20Serial%20Card%20-%20Installation%20and%20Operating%20Manual%201981.pdf

(Note: archive.org has the shiny "user's manual" but not the spiral-bound "installation & operating manual")