EclaireXL

I agree, not to mention that 4th joystick port's poor fire button. I actually built most of this for the mist a while back.

Updated this issue to encompass further issues with the current OS-B implementation.

@Farb - do you know if the protection ever needs the floating data bus? For now I've set 0xc000 to either 0xff in <52K mode or ram in 52K mode.

I know of one game that relies on it -- Coleco's Wargames. Phaeron and I chatted about this a while back because I couldn't get Wargames to run on Altirra in Atari 800 OS/B mode but it ran on my real Atari 800 just fine. Here are some excerpts from that conversation:

The 800 is unique in having split data buses due to the personality board, which I call the "I/O bus" due to the components connected to it. You can float data on this bus separately from the main bus such that it only reflects the last data transferred on that bus. This causes the 800 to report different values when reading from undriven addresses than other computers with unified floating data buses, like the 130XE. It's why the OS memory scan stops at $C000, and WarGames depends on it for its ROM check to work.

I took a crack at hacking the emulator, and the game is definitely relying on the split memory buses. Essentially, it's writing a byte to the $Cxxx area to prime the bus and then reads eight sequential locations, relying on the personality board data bus to hold that value because the code is executing from RAM. Just capturing and holding all writes to that range doesn't work because it causes the OS memory test to think there's RAM there, which ordinarily doesn't happen because the memory sizing code is itself executing from ROM on that bus. Great.

His update to Altirra listed this change specifically:

Removes the non-functional green/blue parameters in the colors dialog and adds support for emulating the floating bus condition on the second I/O memory bus on the Atari 800. This is necessary to run the original version of WarGames on 800 hardware due to a rather nasty hardware check. Thanks to Farb for the test case. Emulating this is rather expensive, so it is opt-in via System > Memory Config > Floating I/O Bus. This also makes PEEK read the correct values in BASIC.

OK, that sounds ... fun! It won't be expensive to add support for but I need to think about it.

For now I just want the system to boot at all after my changes:-)

Got it booting again after a few small bug fixes.

Some reset issues on the 800... and it fails the XL banking acid test (which I guess should auto-disable).

Well, will fix up on Friday night.

This is great news! I look forward to testing it :-)

Squashed several bugs, but struggling with 16k and 32k mode for some reason, not booting.

Built as v25 anyway in case anyone wants to play, but definitely more to do on this...

Tried the salt xex. If I boot it on 48k, then change ram to 16k/32k it returns the expected results. i.e. ram test passes with 2 or 4 banks and rom test passes.

So not sure what is going on. Perhaps the low ram somehow effects the zpu kicking off the boot, need to set up signaltap to check the 6502 is indeed starting up I guess.

Got signal tap on it. Gets part way through booting then hangs at address 000c. This is after memory detection itself, which seems to work fine (0xb0 to 0x0006 in 48k mode, 0x70 to 0x0006 in 32k mode).

This is due to a brk being hit when it jumps to the cart to initialize it. Making the bus 0xff when no ram present which I think will work.

That worked... Now for that horrible beep on reset.

This is fantastic progress!!

Fixed the beep on reset. Will build as v26. Not sure whether floating data bus if worth it. Looks like it wasn't even the same on the 400. What do you think?

I‘d personally would love to see this get as close as possible to a real Atari 800 but obviously I’m not doing all the hard work :–P

FYI, I tested core 26 and put the Eclaire into 48K 400/800 mode using OS/B (what would even happen if I used XL OS with 400/800 mode?). It still has the same problem with the EA disks as stated in the issue description :-(

I’d better wire up the atx code so I can try it myself:)

Did you load the original OS B or use the one off the jic? I think the one I included on the jic is patched. I should find the original...

The OS ROM I'm using has a CRC of 0e86d61d.

I guess it’s checking c000-cfff then?

I’ll try adding a floating data bus...

From Ijor on the protection details:

IIRC it expects to be variable, non constant. The 800 doesn't have pullups on the data bus. So accessing an unoccupied address, as the CXXX in the 800, will return noise. That's why the earlier version of this protection is really 800 only. No kind of XL/XE translator, not even in ROM, would help.

Instead of random noise and depending on the capacitance, it might return the last data driven on the bus. Don't remember the exact coding of the protection that would allow to work or not in this case. Either way, the code reads twice a few memory locations on that range, and verifies that the value is not the same.

From phaeron:

Altirra implements a single floating bus by default for 800 and XE hardware profiles and has an opt-in for 800 dual floating buses (Memory > Enable floating I/O bus). The only game I know of that requires that is Warhawk. Quick way to distinguish is to run a BASIC program that prints PEEK in a loop; it'll mostly print 255 for no floating bus, 213/0 for an XL/XE floating bus, and 212/0 for an 800 floating bus.

OK, I built v27. This has a single floating data bus. I also updated the os rom in slot 4 to this one:
10 KB 0x0e86d61d 4177f386a3bac989a981d3fe3388cb6c Atari OS SYSROM_B_NTSC OS-B 1981 NTSC Production ROM, OS from late NTSC Atari 400/800, LINBUG version with incorrect checksums
(see https://www.wudsn.com/productions/atari800/atariromchecker/help/AtariROMChecker.html)

That worked! I tested both variants of Archon, MULE and One on One and they all loaded just fine. Great job! Now I just need to figure out what you mean by OS slots :-P