Apple ][+ claims to have 80 column card

[oliverschmidt]

The ProDOS global page location $BF98 is documented as

 BF98:              108 * The following are informational only.  MACHID
 BF98:              109 * identifies the System Attributes:
 BF98:              110 * (Bit 3 off) BITS 7,6-  00=II  01=II+   10=IIe   11=/// EMULATION
 BF98:              111 * (Bit 3 on)  BITS 7,6-  00=NA  01=NA    10=//c   11=NA
 BF98:              112 *             BITS 5,4-  00=NA  01=48K   10=64K   11=128K
 BF98:              113 *             BIT  3  -  Modifier for MACHID Bits 7,6.
 BF98:              114 *             BIT  2  -  RESERVED FOR FUTURE DEFINITION.
 BF98:              115 *             BIT  1=1-  80 Column card
 BF98:              116 *             BIT  0=1-  Recognizable Clock Card

After booting both ProDOS 1.9 and 2.4.3 in Apple ][+ mode, $BF98 is set to $62. This indicates an 80 column card. Maybe there is some 80 column hardware emulated but there's for sure no 80 column firmware at $C300. So every ProDOS program looking at $BF98 bit 1 and trying to switch into 80 column mode with a JSR $C300 crashes into the monitor. I.e. in the MAME ][+ emulation without Videx emulation $BF98 is set to $60 and only with Videx emulation $BF98 is set to $62.

[xotmatrix]

In the Slack group, we never got confirmation that your configuration has VidHD in slot 3, which is the only way I could get your result.

[oliverschmidt]

@xotmatrix Even after reading your comment several times, I unfortunately can't follow you :-( What are you referring to with "your configuration"? And what are you trying to express regarding "your result"? You just switch to Apple ][+ mode, boot some ProDOS disk into BASIC.SYSTEM and enter: MTR BF98 The result is 62 instead of the expected 60.

[xotmatrix]

By "your configuration", I mean your settings in AppleWin Configuration panel, particularly the one that places a VidHD in slot 3. And by "your result", I mean you get 62. I get 62 when VidHD is in slot 3, 60 when it is not.

[oliverschmidt]

Thanks for the explicit explanation. It helped a lot because I never did anything about the VidHD setting - to be honest I didn't even know that the VidHD emulation exists.

So I now see several aspects...

1. When an Ethernet card in slot 3 is enabled (which precludes VidHD emulation), then $BF98 is $62 too. This looks like an actual bug.

2. When I enable VidHD emulation and list $C300 then there's no valid firmware.

   • Is this a scenario that would be possible with a real ][+ and a real VidHD? As far as I understand, ProDOS sets the bit in question, because it finds ID bytes in $C3xx. So I can't see how that bit should be set without $C300 containing valid firmware.

   • Is this scenario desirable? My understanding is that the bit in question denotes that a program can expect JSR $C300 to work. And this is not the case.

[xotmatrix]

1. This is fascinating. I'm not quite sure what is going on but ProDOS is being tricked. I think it might be that the Uthernet II appears to have a ROM when it should be producing a floating bus in that space. I don't have one to confirm this behavior. Another lead suggested maybe ProDOS thinks there is Aux memory. Unfortunately, I have to stop looking into it for now.
2. As I understand it, a real Apple II Plus could use a real VidHD and produce 80-column using Apple //e-style code in conjunction with the VidHD's on-board RAM, as well as extended text modes provided exclusively by the VidHD, but I doubt any such software exists.

[oliverschmidt]

Regarding 1.) Both the Uthernet and the Uthernet II don't even connect the IOSEL signal. See the below schematic from the Uthernet II manual. I already noticed that AppleWin listing $C300 with the Uthernet II emulation active seems to not like a floating bus but like a bunch of $00. This is wrong. But even if there are $00, then this still isn't a 80 col. card ROM signature.

Regarding 2.) The VidHD comes with its own $C300 ROM. See the below section from the VidHD manual. But AppleWin listing $C300 doesn't show it. Apart from that being wrong, I still don't see how ProDOS detects an 80 col. card without it.

[xotmatrix]

So this is turning into two issues that confuse ProDOS: 1) Uthernet II; and 2) VidHD. Both fail in very similar ways.

Regarding 1) The Uthernet II implementation in AppleWin has a "blank" ROM and produces $00 throughout the ROM space. The Uthernet II does not have a ROM and it should be producing floating bus values in $C300..$C3FF (thanks for confirming this Bobbi Manners and Oliver Schmidt). ProDOS detects this as a card with ROM and stores that knowledge for later (DEVSRCH.S, notcons). Later, it sees there is a ROM card in slot 3 and checks if it is a generic terminal card testing bytes IDs at $C305, $C307, and $C30B, and then if it is Apple 80-column compatible by checking the high-bit at $C30C (PROLDR.S, isromin3). It fails the first test byte because the entire ROM is $00. Then ProDOS does an Aux memory test (PROLDR.S, hitswtch). It seems to see Aux memory for unknown reasons. I don't know AppleWin's source code well enough to do more tests. With the belief there is Aux memory, ProDOS asserts there is an 80-column card in slot 3 by setting a bit in MACHID.

This change to Uthernet2.cpp seems to resolve the issue by eliminating the Uthernet II as a ROM card but I don't know if I did it right. It does not explain why ProDOS seems to think there is Aux memory.

void Uthernet2::InitializeIO(LPBYTE pCxRomPeripheral)
{
    RegisterIoHandler(m_slot, u2_C0, u2_C0, IO_Null, IO_Null, this, nullptr);
}

Regarding 2) The VidHD implementation in AppleWin doesn't have a ROM and produces floating bus values ... except for "magic" ID bytes at $C300..$C302. ProDOS detects this as a card with ROM and stores that knowledge for later (DEVSRCH.S, notcons). Later, it sees there is a ROM card in slot 3 and checks if it is a generic terminal card testing bytes IDs at $C305, $C307, and $C30B, and then if it is Apple 80-column compatible by checking the high-bit at $C30C (PROLDR.S, isromin3). It fails the first test byte because of the floating bus. Then ProDOS does an Aux memory test (PROLDR.S, hitswtch). It seems to see Aux memory. I think VidHD emulates it and AppleWin implements it. I don't know AppleWin's source code well enough to do more tests. With the belief there is Aux memory, ProDOS asserts there is an 80-column card in slot 3 by setting a bit in MACHID.

EDIT: I hesitate to suggest it but it looks like modern ProDOS goofs when an Apple II/II+ has ROM in slot 3.

[inexorabletash]

FWIW, the ProDOS logic @xotmatrix references above seems to be: (1) bail if not a IIe or later (2) turn on aux read/write (3) try to write to $800 and $C00, verify it sticks (4) verify that those are not mirroring each other. Done via a routine relocated to $80 during load.

[oliverschmidt]

I don't believe that I can add anymore useful input... Beside stating that both the Uthernet and the Uthernet II don't do anything with the Apple II bus when IOSEL becomes active.

[xotmatrix]

This is weird. It looks like a bug in ProDOS. I booted my real Apple II+ with a SSC in slot 3 and MACHID reports an 80-column card. I did a similar test in my emulator with a Disk II FDC in slot 3 and MACHID reports an 80-column card. It seems like any slot 3 card with a ROM will end up this way. I'm not sure how the Aux test is supposed to work. If it is not an //e or later, I feel like the Aux test should be skipped.

ProDOS bug report: https://github.com/ProDOS-8/ProDOS8-Testing/issues/75

[oliverschmidt]

Looking at this from the outside it for sure looked rather like a ProDOS problem than an AppleWin problem to start with. However, I plainly couldn't imagine that there's such a - from my perspective major - bug in ProDOS for so long. Therefore I opted to blame AppleWin - sorry!

So from my perspective there are "only" two aspects left relevant to AppleWin:

1. Make sure that the Uthernet and Uthernet II emulations don't emulate (empty) ROMs.
2. Decide if the VidHD emulation shouldn't rather include the VidHD ROM.

[xotmatrix]

Uthernet1.cpp behaves a little differently than Uthernet2.cpp. It appears to be coded to work right but it doesn't set up the I/O and ROM handlers if there isn't a valid host network to support it. I don't have one so I wasn't able to test it. Because I don't have one, Uthernet behaves like it has ROM (always returns 0) and falls into the ProDOS trap.

void Uthernet1::InitializeIO(LPBYTE pCxRomPeripheral)
{
    const std::string interfaceName = PCapBackend::GetRegistryInterface(m_slot);
    networkBackend = GetFrame().CreateNetworkBackend(interfaceName);
    if (networkBackend->isValid())
    {
        RegisterIoHandler(m_slot, TfeIo, TfeIo, TfeIoCxxx, TfeIoCxxx, this, NULL);
    }
}

Maybe AppleWin should set up the I/O and ROM regardless of network status.

[tomcw]

@xotmatrix -

As I understand it, a real Apple II Plus could use a real VidHD and produce 80-column using Apple //e-style code in conjunction with the VidHD's on-board RAM, as well as extended text modes provided exclusively by the VidHD

Yes, that's right. EG. AppleWin supports VidHD for Apple II, II+ and //e to display the IIgs' SHR (as supported by Total Replay).

But VidHD only supports writes to video switches & RAM, and not reads. So yes, VidHD can show 80 col's (for a II/II+), it can't be used to fully identify as an extended 80-col card.

[xotmatrix]

Oh, that's interesting, and it makes sense to work that way in retrospect. So much for Write-Only Memory jokes.

[oliverschmidt]

But VidHD only supports writes to video switches & RAM, and not reads. So yes, VidHD can show 80 col's (for a II/II+), it can't be used to fully identify as an extended 80-col card.

I believe this is a misconception. The VidHD manual says:

Regarding the issue at hand, John Brooks writes on Slack: VidHD should pass the ROM ID check that ProDOS uses to detect an 80 column card in slot 3, and hence should give a $62 on a ][+. [...] My guess is that Applewin is emulating VidHD's GS/VGC capabilities, but probably not the extended text firmware, so is in the awkward situation of wanting to indicate a VidHD video card in slot 3 to apps, but may not have 80+ column firmware.

[xotmatrix]

There are two different detections. John is referring to the terminal card ID bytes check (I was unable to find these bytes looking at what I thought was the VidHD firmware), which is the first check ProDOS does. Then ProDOS does an Aux RAM check which would determine if it is an extended 80-column card with 64KB (or more). If the VidHD internal RAM cannot be read, I suppose it might fail this test, though the validity of this test is under question.

[oliverschmidt]

@xotmatrix I'm not sure what you want to express with those statements. I believe that @tomcw thinks that the VidHD doesn't supply 6502 firmware while I see that the VidHD for sure supplies 6502 firmware.

[xotmatrix]

I don't have a VidHD to test with. I know it has 6502 firmware and AppleWin's implementation doesn't have it. ProDOS looks for generic terminal card ID bytes at $C305, $C307, and $C30B (#$38, #$18, and #$01 respectively), and another test at $C30C determines if the terminal card is Apple 80-column compatible (high-nibble is #$8). It sounds like the VidHD 6502 firmware should have these bytes. I downloaded a VidHD firmware package, part of which is the 6502 firmware. I thought I identified that part, but I did not see the ID bytes where I expected them. I did not look into it further.

EDIT: Giving it a closer look, it is not 6502 code. Maybe it's just a coincidence that it has a group matching the "magic" bytes #$24, #$EA, #$4C. It's quite possible the firmware is encrypted.

[oliverschmidt]

I'm pretty much certain that asking John Brooks for the VidHD 6502 firmware and details on the way it is mapped would succeed.

[oliverschmidt]

Regarding the Uthernet (II):

• As one would assume, the I/O ports visible when DEVSEL becomes active are always there, no matter if the card has a valid Ethernet connection or not. Coming from here I (like @xotmatrix) suggest to "activate I/O handling" always independently from a proper configuration.
• As mentioned before, IOSEL (and IOSTRB) aren't even connected, so it's undesirable to "activate ROM handling" whatsoever.

[xotmatrix]

In this case, setting up the ROM handling means ensuring it appears to have no ROM. When nothing is done, the default behavior is to return 0 which we don't want.

[tomcw]

2. Decide if the VidHD emulation shouldn't rather include the VidHD ROM.

I've spun off the VidHD discussion about firmware (and II/II+ 80-col support) into #1323.

[tomcw]

Regarding the Uthernet (II):

• [...] I (like @xotmatrix) suggest to "activate I/O handling" always independently from a proper configuration.

(I should've done this before...) Create a PR for this change here: https://github.com/AppleWin/AppleWin/pull/1324

[oliverschmidt]

In this case, setting up the ROM handling means ensuring it appears to have no ROM.

@xotmatrix Thanks for the explanation. Now I see 😀.

[tomcw]

This issue tracked the original problem with Uthernet & Uthernet II card implementation in AppleWin having a "blank" ROM and producing $00 throughout the ROM space. This will be fixed at 1.30.20.0.

Additionally, this issue uncovered that an Apple II/II+ with a VidHD will also cause ProDOS to report it has an 80 col card.

• This is actually true for real h/w (but not because ProDOS has detected this correctly!).
• This is not true for AppleWin though, as it only partially supports VidHD (specifically for a II/II+ AppleWin doesn't emulate 80 cols that VidHD provides for a II/II+).

See #1323 (this comment) for details.

Anyway, I'm closing this issue (as a fix for the original problem will be in an imminent AppleWin 1.30.20.0 release).