D1xx on both XL and XE computers

[+tf_hh]

Actually it would be better to say that EXTENB is not the same as the decoded $D1xx output, but that $D1xx has perhaps been used instead of EXTENB for particular cases like the MIO. And furthermore, neither signal connection is an absolute requirement for a PBI device.

 

EXTENB alias CASINH isn´t the same like $D1xx. When the MIO (?) adapter assumed that, it´s wrong - so easy.

 

EXTENB / CASINH is provided by MMU, low-active signal, goes LOW when DRAM shouldn´t be accessed in any way. When CASINH is low, then the CAS-signal forwarding to the DRAMs remains high - DRAM is not selected. RAS of course remains clocked, otherwise the DRAMs would loose their contents.

 

D1XX on the XE ECI is directly connected to the 74LS138 address decoder and it´s also low-active. When any (!) access to the address are $D100....$D1FF is done, then this signal goes low.

 

So these both signals aren´t the same thing.

[Dropcheck]

Here's a 3 part article delving into the Atari XL Parallel Bus Interface that I found while trying to come up with answers related to the choice using of EXTENB vs $D1xx...

Part 1

Part 2

Part 3

 

It's a fairly good tutorial on how to decode the bus and write a driver. Interestingly it doesn't make use of the EXTENB signal, and instead shows how to do the decoding entirely from the other bus signals. Due to the way Tramiel Atari changed the bus when introducing the XE series, it wouldn't surprise me if no one uses those signals anymore, so as to maintain compatibility between the XL and the XE. And as it has been mentioned, decoding whatever??? is not that big of a deal when using a CPLD, which most any modern parallel device will. But I'll keep digging and see if I find anything related to the MIO in reference to the XL vs XE interface.

 

- Michael

 

 

I've been in talks with Roland Scholz for a couple of weeks now, starting to work out details of a template prototype card and internal bus system for the 1090XLR. He has been enthusiastic, but is a bit rusty on the Atari since it went up into the attic a decade or so ago. Add to that the big pond between us and you can see why it may take awhile. Think months while the particulars are nailed down and test boards are made up to see if what we plan actually works. But if we are successful, then like I said it provides a foundation for others to follow and build on.

 

We will start with a simple I/O card, but the principles should transfer over to other devices. I can't give out details at this point because it is all in flux and way to early in the process. One of the reasons why I'm exploring the D1XX signal, trying to combine the 130XE/800XL PBI/ECI buses and create a standard interface to the 1090XLR. Anything to make it easier for us, the developers and the user.

 

A lot of his work in these articles was leading up to a fourth article that he published later on an interface he named a PC Bridge. Not really an Atari device, so some of his processes and methods were geared to a different way of connecting to the then 8bit IBM PC cards. Some methods may transfer over to this prototype, some may not.

Edited January 11, 2017 by Dropcheck

[+mytek]

 

EXTENB alias CASINH isn´t the same like $D1xx. When the MIO (?) adapter assumed that, it´s wrong - so easy.

 

So these both signals aren´t the same thing.

 

Hi Jurgen Yes I never really thought those two signals were the same, but for some odd reason ICD was using them interchangeably when going from their default MIO XL connection over to their 'adapted' XE connection. I was just trying to find an explanation for doing that, or how that would even work (?)

 

 

I've been in talks with Roland Scholz for a couple of weeks now, starting to work out details of a template prototype card and internal bus system for the 1090XLR. He has been enthusiastic, but is a bit rusty on the Atari since it went up into the attic a decade or so ago. Add to that the big pond between us and you can see why it may take awhile. Think months while the particulars are nailed down and test boards are made up to see if what we plan actually works. But if we are successful, then like I said it provides a foundation for others to follow and build on.

 

We will start with a simple I/O card, but the principles should transfer over to other devices. I can't give out details at this point because it is all in flux and way to early in the process. One of the reasons why I'm exploring the D1XX signal, trying to combine the 130XE/800XL PBI/ECI buses and create a standard interface to the 1090XLR. Anything to make it easier for us, the developers and the user.

 

A lot of his work in these articles was leading up to a fourth article that he published later on an interface he named a PC Bridge. Not really an Atari device, so some of his processes and methods were geared to a different way of connecting to the then 8bit IBM PC cards. Some methods may transfer over to this prototype, some may not.

 

Thanks for the link to the 4th article. I had tried to find that earlier, but couldn't . However it's too bad that the enlarged image links are broken, is there any way that you can get Roland to post those here (or somewhere) so we can better see the details? Is Roland an AtariAge member?

 

The mention of interfacing to the Hercules TTL monochrome card, sure brought back a lot of memories for me. Back in 1992 I did something similar, but of a much simpler design and not really in an 'approved' PBI device sort of way. Unfortunately time has left me without the details of what I actually did to accomplish this, and none of my documentation has survived. The one and only prototype was given to Curt Vendel in a pile of other A8 stuff many years ago. I always envisioned doing something more along the lines of Roland's PC Bridge project, but lacked the expertise to really pull it off at the time. Nice to see that someone else was heading in the same direction, and was taking it to the next level.

 

- Michael

Edited January 11, 2017 by mytekcontrols

[Dropcheck]

 

Hi Jurgen Yes I never really thought those two signals were the same, but for some odd reason ICD was using them interchangeably when going from their default MIO XL connection over to their 'adapted' XE connection. I was just trying to find an explanation for doing that, or how that would even work (?)

 

 

 

Thanks for the link to the 4th article. I had tried to find that earlier, but couldn't . However it's too bad that the enlarged image links are broken, is there any way that you can get Roland to post those here (or somewhere) so we can better see the details? Is Roland an AtariAge member?

 

The mention of interfacing to the Hercules TTL monochrome card, sure brought back a lot of memories for me. Back in 1992 I did something similar, but of a much simpler design and not really in an 'approved' PBI device sort of way. Unfortunately time has left me without the details of what I actually did to accomplish this, and none of my documentation has survived. The one and only prototype was given to Curt Vendel in a pile of other A8 stuff many years ago. I always envisioned doing something more along the lines of Roland's PC Bridge project, but lacked the expertise to really pull it off at the time. Nice to see that someone else was heading in the same direction, and was taking it to the next level.

 

- Michael

 

I do have the files somewhere on my harddrive. ........... okay here we go.

PCBridge.zip

[+mytek]

Thanks Lenore

 

Here is a portion of Roland's block diagram for his PC Bridge.

 

 

Notice the absence of either EXTENB (CASinh) or $D1xx.

 

I think this has been condensed down into the minimally required signals to create a full featured PBI interface that will work on either an XL or and an XE computer. Of course not shown in the diagram is RST, which is already a part of both the PBI and ECI and should be considered essential.

 

So what's missing that might also be useful? As was already pointed out, any address space can be decoded from these 'essential' signals, which would include $D1xx. So what can't be easily decoded and still fit in within the 3 'reserved' PBI pin locations?

 

HALT

RD4 and/or RD5?

CSYNC?

OSC?

???

 

So after going left, down, and sideways on this subject. I no longer feel that $D1xx should be one of the reserved pin allocations. But I think everyone agrees that HALT would be a good one to include, so lets lock that one in for PBI Pin-33. I also threw out a couple of other possibilities for the remaining pins just for thought (not to say that these are the only possibilities, just some possible considerations). And we could just leave those two extra pins as reserved, so that the user can do whatever they want with them, which was suggested earlier by Gunstar.

 

- Michael

Edited January 11, 2017 by mytekcontrols

[lemiel]

There is one use case:

 

http://atariage.com/forums/topic/254160-antonia-4mb-operational-questions/page-4?do=findComment&comment=3668793

 

Do you hold the OPTION key during power-on?

Look at the pictures. The first is taken from this place and the locations of the EXSEL signal are marked with three red circles. The second picture shows where to connect the EXSEL on the Antonia board.

Black wire on the second picture is useful with rev.E IDE+. It derives the RD5 signal to the free 39th PBI contact.

[+mytek]

There is one use case:

 

http://atariage.com/forums/topic/254160-antonia-4mb-operational-questions/page-4?do=findComment&comment=3668793

 

 

So if we were to include that into the spec, which we probably should since it is a documented option for the IDE+, here's what the modified PBI pin-out would look like.

 

Pin-33: HALT

Pin-39: RD5

Pin-37: RD4 ?

 

Is RD4 useful? I'm thinking yes.

 

- Michael

Edited January 11, 2017 by mytekcontrols

[Mathy]

Hello guys (m/f)

 

I can never remember what S4/5 and RD4/5 do. Can somebody please explain what they do? I do know they are cartridge and memory bank related, but how?

 

Sincerely

 

Mathy

[+mytek]

I can never remember what S4/5 and RD4/5 do. Can somebody please explain what they do? I do know they are cartridge and memory bank related, but how?

 

I think Bob said it best here "RD4 and RD5 tell the MMU that it has to activate S4 or S5 chip selects."

 

So as I understand it, if RD4 is 'high' then a cartridge is assumed to be in the 'Right' cartridge slot (or using that area of memory if a cart in the 'Left' slot has this line connected to +5 V). So the same logic applies to RD4 only referring to the 'Left' cartridge slot. S4 and S5 are the chip select (/CS) signals that will actually enable the ROM in a given slot in response to RD4 and RD5 being 'high'. And a cart that has both RD4 and RD5 set 'high' covers a 16K area of memory (8k Left and 8k Right). When a cart is selected, the area of RAM that it overlays is deselected to avoid conflict.

 

Since RD4 and RD5 are only changed by the physical insertion of a cartridge. The only way this action could be seen without these signals, would be to interpret the S4 and S5 lines (but those are created internal to the MMU, so not available by decoding the address bus).

 

- Michael

Edited January 11, 2017 by mytekcontrols

[Mathy]

Hello Michael

 

So RD4/5 is the cartridge telling the computer: "Hey, I'm here" and S4/5 is the computers telling the cartridge: "OK, go ahead".

 

Sincerely

 

Mathy

[Dropcheck]

There is one use case:

 

http://atariage.com/forums/topic/254160-antonia-4mb-operational-questions/page-4?do=findComment&comment=3668793

 

 

 

While I welcome an adaption to this device to allow it to run in a 1090XLR box, this is currently an internally placed CPU/Memory/OS replacement board that may also require other signals to function that are not on the either the ECI or PBI bus. Has someone checked?

[Dropcheck]

Thanks Lenore

 

Here is a portion of Roland's block diagram for his PC Bridge.

 

 

Notice the absence of either EXTENB (CASinh) or $D1xx.

 

I think this has been condensed down into the minimally required signals to create a full featured PBI interface that will work on either an XL or and an XE computer. Of course not shown in the diagram is RST, which is already a part of both the PBI and ECI and should be considered essential.

 

So what's missing that might also be useful? As was already pointed out, any address space can be decoded from these 'essential' signals, which would include $D1xx. So what can't be easily decoded and still fit in within the 3 'reserved' PBI pin locations?

 

HALT

RD4 and/or RD5?

CSYNC?

OSC?

???

 

So after going left, down, and sideways on this subject. I no longer feel that $D1xx should be one of the reserved pin allocations. But I think everyone agrees that HALT would be a good one to include, so lets lock that one in for PBI Pin-33. I also threw out a couple of other possibilities for the remaining pins just for thought (not to say that these are the only possibilities, just some possible considerations). And we could just leave those two extra pins as reserved, so that the user can do whatever they want with them, which was suggested earlier by Gunstar.

 

- Michael

 

I have to disagree here, for the same reasons I've already stated. Again Roland set this up to support a specific device and not necessarily an Atari device. At this point we don't know until we've done some more tests on actual Atari PBI card whether these signals are all that are needed.

 

As I've said before, it makes no sense to keep reinventing the wheel. If we already have a decoded signal on the ECI bus and that same signal can be brought out on an unused pin on the PBI bus, that is less work and one less chance for error for the developer.

[+mytek]

Okey-dokey it's your call with your project

 

BTW, I found yet another good article on the PBI here.

 

- Michael

 

EDIT: How about this (maintains compatibility with IDE+, and should satisfy your desire to keep $D1xx)?

 

Pin-33: HALT
Pin-39: RD5
Pin-37: $D1xx

 

This way you still know if a cartridge is inserted (any cartridge inserted into the left slot would default to bringing RD5 high, so likely no need for RD4).

Edited January 12, 2017 by mytekcontrols

[_The Doctor__]

Nice revival of the Rice article!

The XE eci only had one reserved pin if I remember correctly....

I always thought that adding the most important of the XL pbi to that line would solidify the standard...rd4 and rd5 are on the XE already.

Pin A of the ECI was the reserved pin btw.... never did understand why that was done other than they wanted one spot open just in case something would come up in the future and possibly need that for some unknown chip/etc.... but since that never came about lets finalize it....

 

So my vote is for

 

Antic Halt-

RD4

RD5

$D1xx

 

I thought there were 4 unused pins on the 800XL..... 33 37 39 48

 

47 is +5 on 600XL and 800XL.... I better get a meter and check 48 but I don't remember it having anything on either....

Edited January 12, 2017 by _The Doctor__

[_The Doctor__]

Remember that the schematics in the Rice article are incomplete and simplified to convey the idea of how the hardware works.....

 

and I went looking for an old reference and found the mapping the Atari attempt at pbi pinouts...

http://www.atariarchives.org/mapping/appendix14.php

 

eci pin 3 $D1xx

xlpbi pin 38 decoder...

 

can someone explain them both fully?

Edited January 12, 2017 by _The Doctor__

[+mytek]

Nice revival of the Rice article!

The XE eci only had one reserved pin if I remember correctly....

I always thought that adding the most important of the XL pbi to that line would solidify the standard...rd4 and rd5 are on the XE already.

Pin A of the ECI was the reserved pin btw.... never did understand why that was done other than they wanted one spot open just in case something would come up in the future and possibly need that for some unknown chip/etc.... but since that never came about lets finalize it....

 

So my vote is for

 

Antic Halt-

RD4

RD5

$D1xx

 

I thought there were 4 unused pins on the 800XL..... 33 37 39 48

 

47 is +5 on 600XL and 800XL.... I better get a meter and check 48 but I don't remember it having anything on either....

 

Unfortunately only 3 pins were available, since 47 and 48 were +5 V on the 600XL PBI. Luckily RD5 will probably do the trick all by itself, since the key issue would be to detect if a cart were inserted, and on anything but an 800, RD5 is all that is required to do that (RD4 is for the Right Cart, which is only on an 800).

 

As to your other question (I saw your other post pop up while I was writing this one), I think Jurgen spelled it out pretty well here. Also if you want to know more about the $D1xx signal and what that area of memory is used for on the PBI, check out some of those article links on the PBI.

 

- Michael

Edited January 12, 2017 by mytekcontrols

[lemiel]

 

 

While I welcome an adaption to this device to allow it to run in a 1090XLR box, this is currently an internally placed CPU/Memory/OS replacement board that may also require other signals to function that are not on the either the ECI or PBI bus. Has someone checked?

This RD5 is for external IDEPlus, not for internal Antonia.

http://atariage.com/forums/topic/248397-ide-plus-20-the-newestl-edition-available-very-soon/page-1

I will ask Simius about this signal.

Edited January 12, 2017 by lemiel

[Dropcheck]

This RD5 is for external IDEPlus, not for internal Antonia.

http://atariage.com/forums/topic/248397-ide-plus-20-the-newestl-edition-available-very-soon/page-1

I will ask Simius about this signal.

 

So was this example for the IDEPlus that fits in the cartridge slot. I'm confused.

[+mytek]

So was this example for the IDEPlus that fits in the cartridge slot. I'm confused.

I believe it was shown in the 2nd photo in that linked post, you'll see a black wire jumper going to pin 39 on the PBI, which is adding the RD5 signal. And I did some further checking that describes it as a way for the IDE+ to detect if a cart is inserted, and respond accordingly. So with IDE+ being a well known PBI device, it establishes at least one known case of needing and implementing this signal on the bus.

 

And as I mentioned before, RD5 is not something that can be decoded from any of the other signals available on the PBI, has importance, and therefore really should qualify for inclusion.

 

- Michael

[+mytek]

OK I found probably the best reference to the IDE Plus 2.0 PBI-add-RD5 jumper mod here. This gives both the reason and the mod, but initially specifies that an inline diode was required which is no longer the case due to a later CPLD update.

PBI-add-RD5 mod initial post...

Important information, As already known, when IDE+ is connected to the 600/800XL computers, correct work of SDX need turn-off BASIC holding the OPTION key during power-on, because of lack of the RD5 signal on the PBI (although some interfaces connected to some computers are working without OPTION - this occurs when FLASH in the IDE+ can force their data versus BASIC ROM and is not desirable beacause of excessive power consumption). For this reason RD5 signal output of the Rev.E is connected to the unused pin39 of the PBI and can be connected to the RD5 input of the MMU inside the computer. Unfortunately, this is a totem-pole output, so can't be connected directly, but through a diode (cathode to the MMU). Otherwise RD5 output can be shorted to the +5V and damaged by the cart inserted to the slot in the computer.

PBI-add-RD5 Follow-up post...

Sorry, if my english isn't clear enough. It's not my first language nor even the second.
With or without Antonia, it doesn't matter. Moreover, I found the solution and it will possible to doing it without a diode (ie. direct), after reprogramming of CPLD.

 

 

And as you can tell by the date of that topic, this is a current PBI device that is being talked about. So it definitely has relevance to our PBI discussions.

 

- Michael

 

EDIT: In case you are curious here is what the IDE Plus 2.0 looks like...

 

Edited January 12, 2017 by mytekcontrols

[lemiel]

It is for new IDE Plus, created on CPLD not discrete elements - Rev. E.

This photo is for earlier revisions D,C or S.

Rev.E photo should be available on forum.

[+mytek]

It is for new IDE Plus, created on CPLD not discrete elements - Rev. E.

This photo is for earlier revisions D,C or S.

Rev.E photo should be available on forum.

 

Opps! Here's the the correct photo for the Rev E model...

 

 

- Michael

[Dropcheck]

Okay..... Just want to make sure I'm on the same page.

 

The first pic is of an older model coming off the 130XE ECI bus. That RD5 signal is available to it off that bus.

 

The last pic I am assuming is a PBI (800XL) version. A jumper wire has to be run from an internal point on the computer to some point on the board for the RD5 signal?

 

Both versions do require the RD5 signal for operation.

[+mytek]

Okay..... Just want to make sure I'm on the same page.

 

The first pic is of an older model coming off the 130XE ECI bus. That RD5 signal is available to it off that bus.

 

The last pic I am assuming is a PBI (800XL) version. A jumper wire has to be run from an internal point on the computer to some point on the board for the RD5 signal?

 

Both versions do require the RD5 signal for operation.

 

My mistake on posting that earlier revision photo, so please don't pay too much attention to that, and I don't know if that version required RD5, but if it did the ECI interface would have provided that on an XE (I don't know if that version was also XL compatible or not).

 

So yes the 2nd photo with the ribbon cable and edge card connector would be for the 600/800XL series. And yes to enable cart detection, a jumper from RD5 ( MMU pin-8 ) to PBI pin-39 is required.

 

- Michael

 

EDIT: Also keep in mind that without the RD5 signal, there really isn't practical way that a PBI connected device would know if a cart has been inserted. So to me, that really makes it a must have signal. Remember your reason for wanting to retain the $D1xx signal was to make it easier for the PBI developer. At least $D1xx can be decoded from the address lines, whereas RD5 can not.

Edited January 12, 2017 by mytekcontrols

[Dropcheck]

Okay, I'm on board with RD5 being on one of the reserved pins.

 

Something that is an option, but maybe distasteful. We can re-purpose two additional pins on the 800XL PBI. We are in agreement that CAS and RAS signals would not be used on new devices. Those two signal traces could be cut and that would give us two more pins.

 

Like I said it would be distasteful, but possible.