Occupied PBI IDs

This is an area to discuss information about known existing PBI/ECI devices.
Forum rules
Read me first before posting!

1. No politics, religion or sports. There's plenty of other boards to discuss those topics.
2. You can diss an idea, don't diss a person.
3. Don't steal, borrow with attribution and permission if possible.
4. If you get mad, walk away for an hour. Think about it. If you are still mad, stay civil.
Post Reply
Posts: 1
Joined: Sat Feb 25, 2017 7:46 am

Occupied PBI IDs

Post by drac030 » Fri Mar 17, 2017 11:20 am

I will repeat the question I asked via PM on the AAge: what if some PBI id is already used by the computer? As far as I know, ids 0 and 1 were occupied in 1450XLD. This may seem an academical problem, but in fact the Rapidus accelerator board does occupy PBI id 0. So what provisions are/should be planned to avoid a conflict like this between the computer and the new 1090? If the 1090 allocated id 0 for something important, such a conflict would be rather unpleasant.

Site Admin
Posts: 17
Joined: Mon Jan 30, 2017 5:26 am

Re: Occupied PBI IDs

Post by dropcheck » Fri Mar 24, 2017 6:44 pm

That has historically been a problem with any single PBI device developed. When a developer is only developing for a single purpose PBI device the tendency is to hard code the id instead of providing for a method to either programmatically have changeable IDs or have a physical jumper. Now I'm not saying there isn't a good reason in this case, the accelerator is designed to take control first above all other devices. It has to in order to function well, but it does damage to the idea that all PBI devices should work together by negotiating their position in the id pool.

If you look at the original documentation, there is at least the basics of bus mastering/ID negotiating baked into the Atari OS. The problem is that it never got fleshed out, new products were planned, but never actually released (1090 and 14050XLD etc) with their own expectations. If as you say the 1450XLD is hard coding ID 0 and 1, then again it does damage to ID negotiation. In that example the Rapidus accelerator would not function either.

I would be interested in getting a list of PBI devices that hard code the ID and what ID #. Next I would like to take a look at the numbers of these devices that were released. That would tell us how much of an issue it really is. :)

Posts: 2
Joined: Tue Oct 10, 2017 1:36 pm

Re: Occupied PBI IDs

Post by mega-hz » Tue Oct 10, 2017 1:41 pm

i would suggest to make DIP-Switches for the ID on every new devoleped PBI Device to make things easier.


Post Reply