Thanks Henrik, Dave and Darrel!
I was forlorn late last night - felt a bit better so I thought I would tackle my own idea, only to find out I do NOT have write privileges to the RCREGx register, and as it now seems, that would not be the way to go.
Darrel, I will read this over and see what I can do with it, I completely missed the RCIDL bit as it was buried in the Baud Rate Generator section, but, sure 'nuff on page 349 of 622 (who REALLY calls these things datasheets any more? I can remember the old 7400 data sheet........) it does say:
'To assure that no actual data is lost, check the RCIDL bit to verify that a receive operation is not in process.' Dang that Darrel, his frontal lobes must be HUGE! Thanks for that Darrel, I'll try some stuff tonight.

I am hoping that it can be done effectively using 2 wire, but as its just for me, I can change to 4 wire or use an 'attention' line if need be, just not as cool.

So, according to the app note, this looks a lot like the forunner to CAN? I have worked with CAN and found it too troublesome - even for work solutions which is why I wanted to use 485 and figure out my own or use someone else's with any changes.

One thing I had not thought about before reading the app note (Thanks again), it looks like I can set priorities, something I had not thought of - thought the nodes would arbitrate that....... The note's logic is pretty much what I started with, without MIDs and the nifty way of determining message priority delays. The part about determining bus idle is also interesting. This J1708 protocol might just be the ticket.

Its interesting that the data into the 485 chip goes into the DATA ENABLE while the DATA INPUT is held at ground and the result is apparently NO electrical bus contention.
I have my 75LBC184 wired in the conventional sense with RE/DE tied together and driven by the proc as a 485 ENABLE and the TX and RX going to their re3spective inputs/outputs.

So, if I use the 'standard' 485 wiring, I should be able to follow the note as:
The steps to arbitration are as follows:
1. Wait for the bus to become Idle.
2. Wait the required priority delay after the Idle period has started.
3. Make sure the bus is still Idle. If the bus is not Idle, go back to step 1.
4. Transmit the device MID (or my address of the node) on the bus.
5. Receive the transmitted MID and determine that the sent MID matches the received MID.
6. If the match was successful, we have claimed the bus. Send the packet.
7. If the match failed, we lost the arbitration. Continue to step 8.
8. If this was the first collision for this packet, go to step 1.
9. Wait for the bus to become Idle.
10. Wait for a pseudo-random number of bit times (between 0-7).
11. Go to step 3.

Has anyone else use this? I'll start coding a trial tonight!
Thanks Guys, this will help!
-Steve