Falcon undocumented registers

[czietz]

Certainly, I won't be the first to notice this - given that I'm a latecomer to the Falcon. But I couldn't find any posts about this. Looking through the register space from $FF8000 - $FFFFFF, I see two registers for which there seems to be no documentation:

$FFFF82: Always reads back as $1C00; likely read-only, as writes cause a bus error. A status register? Chip revision?
$FF800D: Is $00 after reset; apparently, only bit 0 is implemented and can be set to 1 and read back. I did not observe any effects: no crash, no change to the screen, system performance (as measured by Coremark and Nembench) unchanged.

Is there any information about these registers?

[Cyprian]

I wonder whether there is somewhere netlist for the Falcon, like it was for the Jag

[shoggoth]

Could 0xFFFF82 be related to the solder jumpers, i.e. ram/rom speed config?

[dhedberg]

Could 0xFFFF82 be related to the solder jumpers, i.e. ram/rom speed config?

Solder jumpers U46 and U47? Nah, parts of 0xFF8006 is mapped to U46 and parts of 0xFF9200 to U47.

[shoggoth]

@dhedberg: Ah, my bad!

@czietz: Please find us the magic turn-all-modes-chunky-register! Or... well, anything, because it's exciting stuff regardless. Ray/tscc did some similar investigations on the TT many years ago, and though most of it was really weird some of us just love to get a complete picture of our machines. The "new" graphics modes on the ST a few years ago just blew my mind, and the ability to move the cartridge space on the STE, it raises new questions about what could have been.

[frost]

the ability to move the cartridge space on the STE

Wait, it seems that I missed something. Do you have some link to provide ?

[mrbombermillzy]

Ray/tscc did some similar investigations on the TT many years ago, and though most of it was really weird some of us just love to get a complete picture of our machines.

Would love to know more about this too. I did write about the 'mysterious' reserved graphics modes of the TT in a previous thread, but Ppera sort of put me off investigating.

Would be good to get to the bottom of those F030 locations czietz!

[czietz]

the ability to move the cartridge space on the STE

Wait, it seems that I missed something. Do you have some link to provide ?

I suppose he was referring to https://www.atari-forum.com/viewtopic.php?t=32054.

[frost]

Thanks !

[sarnau]

In the FALCON.TXT at least xxFF800D can be found:

Refresh Control Registers

The MCU defaults to a 15.5 us maximum refresh interval after
a reset. This corresponds to the most common refresh rate for
currently available DRAMs, e.g. 512 row/8 ms for 256k deep parts,
and 1024 row/16 ms for 1M deep parts. Refresh cycles can then be
customized under software control. When the counter is enabled
with a time constant of zero, refresh is turned off. There are
seperate registers for video and fast memory.
The fixed clock to the refresh control counter runs at 2
MHz. The default refresh interval corresponds to a value of 001Dh
loaded into the counter. The minimum value of 1 in the counter
provides a refresh interval of 1500ns. The maximum value of 7FFFh
provides a refresh interval of 16.384 ms.


Address = xxFF8003 (video), xxFF800D (fast):

D7 - Refresh Interval Control
0 = Default Interval
1 = Counter
D6 - D0 Refresh Time Constant Bits 14-8

Address = xxFF8005 (video), xxFF800F (fast):

D7 - D0 Refresh Time Constant Bits 7-0

[sarnau]

And the same document says this:

FFFFFF80 ro xxxx xxxxIOC ID byte
FFFFFF81 ro xxxx xxxxMCU ID byte
FFFFFF82 ro xxxx xxxxDMA-A ID byte
FFFFFF83 ro xxxx xxxxDMA-B ID byte
FFFFFF84 ro xxxx xxxxVMEC ID byte
FFFFFF85 ro xxxx xxxxGPU ID byte

So, the DAM-A/B ID would be 1C00?!?

[czietz]

Of course, I know this document. Problem is: The document you refer to does not describe the production Falcon, but a different "Falcon" with Fast-RAM, VME, ... You'll find that most of the registers described in this document do not match the actual Falcon.

E.g. $FF800D is described as "fast [RAM] refresh rate", but obviously the Falcon does not have fast RAM.

EDIT: And what would DMA-A and DMA-B be in the context of the actual (=existing) Falcon?

[czietz]

Update: While I still do not see what DMA-A and DMA-B would be in the Falcon, there is evidence that puts the $FFFF82 register into the Falcon DMA ASIC: Combel register access is acknowledged via the XDTACK signal (pin 8 on GAL U63), whereas DMA (and some other ICs) register access is acknowledged via EDTACK (pin 13 on GAL U63). Accessing $FFFF82 doesn't generate a pulse on XDTACK, but on EDTACK. Therefore, $FFFF82 cannot be inside Combel. Hence, the DMA is a likely suspect. I already speculated about a chip revision number in my initial post.

But I find the writable $FF800D register more intriguing, anyway. However, finding its function is like searching for a needle in a haystack.

[czietz]

Unsurprisingly, the "mystery" bit in the undocumented register $FF800D does not have any influence on RAM refresh timing; I just checked that.

Another theory I tested unsuccessfully: Whether the bit dis-/enables a certain address range. But there is no change regarding which addresses can be read (i.e., don't cause a bus error).

[Cyprian]

Another theory I tested unsuccessfully: Whether the bit dis-/enables a certain address range. But there is no change regarding which addresses can be read (i.e., don't cause a bus error).

or as @shoggoth mentioned it turn-all-modes-chunky

[Rustynutt]

From a layman's perspective, you guys keep coming up with ways to boost execution faster than hardware can be accelerated

[dhedberg]

Unsurprisingly, the "mystery" bit in the undocumented register $FF800D does not have any influence on RAM refresh timing; I just checked that.

Another theory I tested unsuccessfully: Whether the bit dis-/enables a certain address range. But there is no change regarding which addresses can be read (i.e., don't cause a bus error).

If you haven't done so, have you checked if TOS is referencing that register anywhere? I guess it could be hard to find though as they could be using a base address with displacement.

[Cyprian]

If you haven't done so, have you checked if TOS is referencing that register anywhere? I guess it could be hard to find though as they could be using a base address with displacement.

could be easy under Hatari

[czietz]

If you haven't done so, have you checked if TOS is referencing that register anywhere? I guess it could be hard to find though as they could be using a base address with displacement.

What I have done: grep-ing through the source code available on dev-docs (Falcon BIOS/XBIOS, diagnostic cartridge, etc.) for this register, but to no avail.

[czietz]

Another theory unsuccessfully ticked off from the list. There's an interesting wording in the Falcon technical documentation: "Hardware within the COMBO IC allows the enabling of interrupt levels 1 and 3 as external VP A positive edge interrupts." (Emphasis mine.)

Thus, I wondered, could this be an interrupt enable / disable bit? But no, it isn't. Interrupts 1 and 3 at the expansion connector can be triggered regardless of the setting of the $FF800D register. (Of course, you have to lower the CPU's interrupt mask accordingly.)

[shoggoth]

Another theory unsuccessfully ticked off from the list. There's an interesting wording in the Falcon technical documentation: "Hardware within the COMBO IC allows the enabling of interrupt levels 1 and 3 as external VP A positive edge interrupts." (Emphasis mine.)

Thus, I wondered, could this be an interrupt enable / disable bit? But no, it isn't. Interrupts 1 and 3 at the expansion connector can be triggered regardless of the setting of the $FF800D register. (Of course, you have to lower the CPU's interrupt mask accordingly.)

What would that mean in practice, had it been the case? Disabling the HBL/VBL interrupts? (would make sense with a graphics card, if that graphics card generated those signals instead of the VIDEL, and Atari did leave some MATRIX driver residue in TOS4).

[czietz]

What would that mean in practice, had it been the case? Disabling the HBL/VBL interrupts?

No, my (disproven!) theory was that it would only disable/mask the interrupt input from the extension connector. Comparable to the MegaSTE/TT, where the SCU allows masking interrupts coming from the VME bus.

Next theory removed from the list: Does the mystery bit in $FF800D influence chip select timing of a certain peripheral? (I know [non-Atari] chips that have a "slow" mode, just in case.) But no, it does not change anything in this regard, either. I checked ACIA, MFP, PSG, RTC, SCC, joystick, IDE, Videl, and FPU CS and they look the same, regardless of the setting of the mystery bit.

[Greenious]

Yeah, wrote about this a few years back.

https://www.atari-forum.com/viewtopic.php?f=27&t=31904

[czietz]

Yeah, wrote about this a few years back.
https://www.atari-forum.com/viewtopic.php?f=27&t=31904

Hm, and I replied. Quite embarrassing that I don't remember what I wrote four years ago.

Searching for the meaning of the bit in $FF800D is really like searching for a needle in a haystack. I removed two further items from my list. 1. The bit does not influence the keyboard flow control (see https://www.atari-forum.com/viewtopic.p ... 28#p416128). 2. The bit has no influence on the (unconnected, anyway) Blitter interrupt output of Combel.

[Cyprian]

@czietz I've just realized you posted there a great document "Atari FALCON Product Specification"

I see there a video register "xxFF8260" where we can turn packed pixel modes. That's pity they didn't add it to the Falcon.