Closed oliverschmidt closed 2 weeks ago
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.
@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.
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.
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...
When an Ethernet card in slot 3 is enabled (which precludes VidHD emulation), then $BF98 is $62 too. This looks like an actual bug.
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.
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.
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.
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.
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.
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
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:
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.
@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.
Oh, that's interesting, and it makes sense to work that way in retrospect. So much for Write-Only Memory jokes.
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.
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.
@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.
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.
I'm pretty much certain that asking John Brooks for the VidHD 6502 firmware and details on the way it is mapped would succeed.
Regarding the Uthernet (II):
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.
- 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.
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
In this case, setting up the ROM handling means ensuring it appears to have no ROM.
@xotmatrix Thanks for the explanation. Now I see 😀.
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.
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).
The ProDOS global page location $BF98 is documented as
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.