ROMless PBI device to cooperate with other devices?

[ol.sc]

Hi,

 

I'm thinking about to create a device for the PBI without a ROM but only a few I/O ports at $D1xx. It won't be recognized by the OS but is only accessed by a specific program. My question is:

 

Assume the device detects write access to $D1FF and only responds to I/O port access if $D1FF contains the right bit - which is as far as I understand what PBI devices are supposed to do. Is that enough to cooperate with other "proper" PBI devices?

 

In other words: Is it reasonable to presume that the OS will set $D1FF before trying to access any recognized PBI device? And is it acceptable that some other part of the system (e.g. the specific program) writes to $D1FF (prior to accessing the device I/O ports)?

 

Note: The device won't generate interrupts. The program won't access $D1FF and/or the device I/O ports from within an interrupt handler.

 

Thanks for your help,

Oliver

Edited November 25, 2018 by ol.sc

[Rybags]

If it's just a passive device with no handler or special stuff going on, then why not just map it somewhere else?

 

The XE has an ECI line that decodes $D1xx for you but the XL doesn't. So it'd be equally easy to just map somewhere else, like $D600 or $D700 (though VBXE can live there)

[ol.sc]

The specific scenario at hand is about 4 I/O ports. If there are 4 addresses available that can be assumed to be unused "no matter what" then this would certainly be the by far easiest solution.

[phaeron]

Even if your PBI device isn't used from interrupt, it's possible for other devices to be. The OS will write to $D1FF as part of PBI IRQ handling, so to co-exist with such a device you would need to either mask IRQs when accessing your device or update the shadow variable SHPDVS before each write to $D1FF.

[Rybags]

VBXE maps to $D640 onwards or $D740.

 

Other devices - not sure. In the modern day we have Ultimate 1 Meg and Incognito which I think mostly use the PIA space in creative ways but there might be more.

The $D6 page I think might also be used by 80 column cards for the 800 - I'm fairly sure it's the only machine that provides an easy user-accessable D6 signal, it's present on Ram slot 3 which was also intended to be a generic expansion card slot.

 

Unless you're planning to go mass-market then I reckon you'd be fairly safe just using something like $D700-$D73F

[flashjazzcat]

U1MB config register is at $D380, but it is locked and inactive by the time the OS takes control. If SDX and other optional features are disabled, the machine essentially behaves as stock aside from the DS1305 RTC register at $D3E2 and the button sense register at $D384. Incognito additionally uses $D1E0-$D1E7 for IDE registers; 1088XEL (with XEL-CF) uses the same, plus $D1C0 for card reset, etc. Decoding may be partial so I would probably rule out $D1C0-$D1EF and $D3E2 if compatibility with this stuff is to be maintained. See the XEL-CF docs for more info.

 

PBI RAM ($D1xx, $D5xx, $D6xx, $D7xx) is only accessible when the config is unlocked or when the U1MB PBI device is selected; see the Altirra Hardware Reference Manual for details.

[ol.sc]

@phaeron: Thanks for the hint :-)

 

As you "only" comment on the IRQ aspect I presume the rest of my assumptions are okay from your perspective. I'll summarize what I believe to have understood. Please correct me where I'm wrong...

 

The OS generally doesn't make assumptions on the content of $D1FF. When it wants to call a PBI handler it "just" writes the corresponding PBI index to $D1FF to have the corresponding ROM mapped.

 

When an IRQ is asserted by a PBI device the OS needs to learn which one did so. Therefore the device in question makes a read from $D1FF retrieve its own PBI index. Therefore the OS IRQ handler can't save the $D1FF content in order to restore it prior to returning from the IRQ.

 

Instead everybody writing to $D1FF needs to write the same value to SHPDVS. This allows the OS IRQ handler to read the "correct" value from there and write it to $D1FF prior to returning from the IRQ.

 

In order to be really safe, writing a value to both $D1FF and SHPDVS should be made an atomic operation be masking IRQs while the two writes.

[ol.sc]

[...] Unless you're planning to go mass-market then I reckon you'd be fairly safe just using something like $D700-$D73F

 

Thanks for the recommendation (and the explanation) :-)

 

Any different opinions?

[ol.sc]

@flashjazzcat: Thanks for the detailed information :-) However, I'm unfortunately not able to determine from it if you see addresses generally unused.

[flashjazzcat]

There have been other topics in which similar questions were asked. Here's one:

 

http://atariage.com/forums/topic/157241-list-of-hardware-registers/

[phaeron]

When an IRQ is asserted by a PBI device the OS needs to learn which one did so. Therefore the device in question makes a read from $D1FF retrieve its own PBI index. Therefore the OS IRQ handler can't save the $D1FF content in order to restore it prior to returning from the IRQ.

Reads from $D1FF don't read the selected index, they either read IRQ status or garbage. Reads and writes to the same address don't have to correspond to the same register, and in fact read/write registers are uncommon on the Atari. There actually isn't even a single $D1FF write register, it's actually a virtual register whose behavior is defined by all of the PBI devices that interpret writes to that address.

 

What reading from $D1FF specifically gives is the IRQ status, only for the PBI devices that support IRQs (those with bits set in PDMSK). This is because each PBI device supporting an IRQ only drives its own bit on the data bus, so this is also a virtual register. All other bits are undefined and will give bus noise on some systems, which for most systems will be all bits.

 

In order to be really safe, writing a value to both $D1FF and SHPDVS should be made an atomic operation be masking IRQs while the two writes.

 

Masking interrupts is one way and is cheap, but it's enough to just write SHPDVS first. If a PBI IRQ happens in between the two writes, the IRQ handler will "restore" $D1FF to the value that the second write will use anyway. This works because the IRQ handler has to restore SHPDVS/$D1FF, it can't leave it permanently changed like POKMSK/IRQEN (for which this trick isn't safe). This trick is also required if devices can be temporarily selected from an NMI, though I don't know if that is allowed.

[ol.sc]

@flashjazzcat: Thanks for the link :-)

 

@phaeron: Thanks for detailed feedback :-)

If a PBI IRQ happens in between the two writes, the IRQ handler will "restore" $D1FF to the value that the second write will use anyway.

 

I now see!