XE specific PBI implementation info required

[candle]

Hi all

 

If anyone has some info on how to implement PBI device as described in Antic vol 3 (9-12) in XE series i would really apreciate sharing the info

 

Thing is late XE series come with ECI/CART ports rather than PBI (first XE computers didn't have ECI port - Traimel deciced it costs too much (0.02 per unit?)), but the later ones has ECI port that with CART port should replace functionality of PBI connector

There is no RAS, CAS, nor EXTEND (EXTENB) signals on that bus, thus implementing PBI device as described in Antic Toolbox article, or in various scraps of Atari references (as C024891-001 for example) but this is all i got, and its simply not enough

 

ECI port has some pins that orginal PBI hasn't - for example REF and HALT signals, it also has one pin marked as RESERVED - so they had a way to route EXTEND(B?) signal out - for some reason they didn't

 

I would really apreciate any input that could lead to my understanding WHY they did such thing

 

I know that EXTEND(B?) signal can be recreated outside using those signals provided on ECI/CART combination, but as i've already mentioned - they had one spare pin, the signal itself is present inside all XE computers, yet - they didn't bothered to connect it to that pin

 

WHY?!

[kenames99]

hi, all the info you need is in the "Mapping the Atari" book and most all online references to the PBI include the cart/eci explanation.

 

Ken

[GroovyBee]

Mapping the atari appendix 14 has the pinouts and a brief explanation :-

 

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

[candle]

what would you do with brief explanation?

build a device?

You need detailed info about the bus timing to do that realiable, otherwise you're guessing, and development time may take forever

 

I really need solid base to start with

 

I'm familiar with Dr Atari articles, Mapping The Atari, Antic ToolBox series articles, and several other sources that can be googled, but this is simple not enough

 

need more - a lot more

[+CharlieChaplin]

Well,

 

I don`t have any schematics, but here is a german manual for an XE - PBI adapter that was once sold commercially. Maybe it is helpful in some way... -Andreas Koch.

[candle]

Thanks Andreas

This is what i was talking about in my original post - casinh signal is wired to reserved pin at ECI port, but they designed the port without this singal on place - i'm assuming they had their reasons to do that, just need to know those reasons

[Rybags]

Can you deduce whether CAS or RAS should be active based on the Phase 2 output?

 

Which signal/s are you desperately missing?

[GroovyBee]

You have access to ANTIC's active low output REF (pin eight) signal on the ECI. It indicates that the current access is a refresh cycle.

 

EDIT: For number to smiley conversion.

Edited September 9, 2009 by GroovyBee

[candle]

just measured 5 of my XE systems that have ECI port having KMK/IDEa as pbi device and test program to verify memory access is valid

 

only one worked

 

PH0 to PH2 phase diffrence was 32ns

PH2 to BPH2 was also 32ns

 

others that didn't work maasured 28/28ns or 28/32ns

i've also measured 800xl both PAL and NTSC but since i don't have any way to connect IDEa interface to them i cannot tell whether it would work or not

 

working unit has 74AHCT08 chip at U18 location - others have LS08 chip

propagation delay for typical AHCT familly member is 7.7nS average, where LS familly propagation delay 12nS

 

i would like to swap ls for ahct, but i don't want to rip the only one i have to get this done

 

 

 

i can also destabilise IDEa interface using finger put onto R20 or pin #39 of CPU on orginal U1 (IDEa GAL chip), but i've taken some provisions for this, and current CUPL code for this GAL prevents this behaviour

 

rise/fall times in all cases were 190/50nS (measured at pin #39 of the CPU)

 

this is all unconclusive for me, and i would really put the guesswork aside, and read some specs

 

the goal is to provide full-proof interface that would work regardless of parts used inside the Atari XE series, because all i can say about designs we have is that they work by miracle, or after heavly tuning of the circuit

 

edit: the test program assumes that PBI device is #0, if any chars are present on lower part of the display, then IDEa interface almost works - just enough to get some data out of disk, and corrupt them in the another time

Edited September 9, 2009 by candle

[MEtalGuy66]

Candle. Here is the MIO servce manual:

 

http://www.megaupload.com/?d=0EUGQJBB

 

This includes complete schematics showing how we generate the 'CAS before RAS' refresh signals to the DRAM, and also has timing diagrams (logic analzer screenshots with notations)..

[candle]

but why i would need to generate cas before ras signlals at all?

and i only got dram concerned timings there - not my case at all

[GroovyBee]

but why i would need to generate cas before ras signlals at all?

and i only got dram concerned timings there - not my case at all

We seem to be confused about what you want to do. From reading your replies its nothing to do with DRAM, RAS or CAS. Maybe it would help if you gave more information about what you are looking for in terms of signals and their relationships.

[candle]

i'm bulding new IDE controller that would work in any XE series computer and had DMA support for C816 project

 

need proper atari documents describing the bus, not guesswork

 

thats all it is

[MEtalGuy66]

Hmm.. Well, based on my experience with PBi devices, I think your going to have to modify your strategy slightly..

 

First of all, the atari PBI interface on XL/XE machines is anything but "concrete" in terms of stability or conformity.. This is why you see such "fine tuning" of circuits on PBI devices that you mentioned. This is pretty much "par for the course" on the MIO, Black BOX, Supra, KMK, IdeA, etc..

 

Second, if you are trying to support a DMA standard used by the "816 project", I would reccomend inclusion of a DECENT local bus standard in that project, and designing your hardisk interface to use THAT standard, rather than trying to depend on ATARI's PBI standard. Perhapse make two versions of the interface (for Ataris with and without the accellerator board) with common firmware. On both the XL and XE, there is room to run a ribbon cable out the PBI opening, without modding the case or motherboard, and if you design your baord layout right, you could make it where either vesion of the device could be built using the same PCB, just depending on parts population.

 

To try to make a single version of a device that fits both these roles is probably going to cause you more headaches than you can imagine, and also limit the features/performance of the device in either role...

 

This is all pure speculation/suggestion on my part, but its based on what I know of existing PBI compliant devices. You can take it or leave it...

[candle]

i know but i need to get rid of that finetuning part and design the board in such way that it would accept some deviations in bus timing and still would work reliable

external pbi device would be limited to standard system clock, whereas internal one running from separate bus in 816 address space would run at full speed

 

headaches you're talking about are one time issues, and once solved serve well to all of the community

[MEtalGuy66]

No, they are very much CONTINUING headaches on any one of these devices. If you look at all the "extra" resistors and caps soldered onto most PBI devices for tuning purposes, they may or may not be there, depending on which exact parts manufacturer was used for various components.. In some cases, the device even needs further tuning to compensate for differences in timing on a specific machine..

 

Now certainly, with modern devices, and programmable logic, you eliminate ALOT of the variation in timing and signal chracteristics.. But the fact remains that the ATARIs are 20 years old, and the design does exhibit a relatively wide range of signal timing/characteristics in many cases, from one machine to the next. I have no doubt that you can build a device that supports the PBI standard and ALSO autodetects/uses some extension of that standard if the 816 board is present. What I think youll have trouble with is making it stable on ALL XL/XEs out there without system-specific fine-tuning..

 

As a whole, the PBI standard was under-developed/supported by atari, and the manufacturers of PBI devices have alwayse had to deal with the resulting inconsistancies. Email Bob Puff and ask him how many Black boxes had to be "custom tuned" to the systems they were run on.

[HiassofT]

Hi Candle!

 

this is all unconclusive for me, and i would really put the guesswork aside, and read some specs

Forget about the specs (if you are able to find any), Atari messed it all up and the signals are not how they should be :-(

 

The basic problem is that on some of the Ataris (mainly XE, but also several XLs) the address and/or data bus lines are already invalid at the falling edge of PHI2. This leads to errors when trying to interface with a fast device (IDE drive, SRAM, flash, CPLD, ...).

 

If I read the MIO schematics correctly, a PLL is used to reconstruct the PHI2 signal.

 

When I designed the TurboFreezer 2005 I used another, simpler approach:

 

The iM4A5 can be configured to have input latches. So I latch all address lines when PHI2 is high. This ensures that the internal logic doesn't get messed up if some of the signals change state before the falling edge of PHI2. This is mainly for the internal state machine and for the read access logic.

 

Writing data to the SRAM/flash requires some additional circuitry. I used a 74HCT123, configured as a one-shot, to generate a new WE signal. The new signal starts at the rising edge of PHI2 and is approx. 100ns long. This setup worked fine with the SRAM and flash we used (you might have to adjust the pulse width a little bit, depending on your device specs).

 

You can find the docs for the TurboFreezer 2005 here: http://www.horus.com/~hias/freezer/

 

The schematics are in hardware/schematics*.pdf, but please check the README, there are some bugs in them (for example all 74LSxx should be 74HCTxx).

 

so long,

 

Hias

[candle]

I've read Bob's article about finetuning the atari to get it more stable with PBI devices, still want to try to build this device in such way it would not require finetuning

 

i've already pm Curt Vendel and Bob Wooley, but they are extremly busy, are not able to help me at the moment, so i'm asking general public instead

 

i don't want to be a pest

 

Hias: since i'm having write problems rather than read ones i find your ideas verry good, can't check the latching mechanism right now (since i'm just i process of fixing IDEa interface rather than starting new one), but the WE solution is what i would want to try

i was going to delay PHI2 for generating WE signal and anding this delayed PHI2 with orginal one making it a bit shorter, so the latched address for SRAM chip would be (hopefully) valid

Edited September 9, 2009 by candle

[MEtalGuy66]

I've read Bob's article about finetuning the atari to get it more stable with PBI devices, still want to try to build this device in such way it would not require finetuning

 

That article is really the "tip of the iceberg" so to speak.. Many machines required alot more/different "tuning" than what he describes there.. That article was really meant to be a guide for the layman to TRY before sending the devices back in to CSS along with the atari.. If you read some of the newsgroup archives and old compuserve forums from the early-mid 90s you find several people attemtping to flame CSS for this reason, and BOB attempting to deal with them in some form of decent manner. Their anger was really misguided.. Its atari's fault for not paying closer attention to bus timing tolerances in their designs.

[candle]

might be, but it would be a lot easier if this modifications were done only to BB device, rather than Atari

anyway i'm not judging Bob nor the BB which i didn't even see, but just the fact the problem exists all the response i get is "hey, it works for me, so its your problem"

[MEtalGuy66]

might be, but it would be a lot easier if this modifications were done only to BB device, rather than Atari

anyway i'm not judging Bob nor the BB which i didn't even see, but just the fact the problem exists all the response i get is "hey, it works for me, so its your problem"

 

Yeah I dont agree with the "XL/XE Stability Fix" article either. I have found that many machines do not benefit from this "mod" and some even get worse from it.. And certainly, any "fine tuning" should be done on the PBi device, rather than the ATARI, whenever posible.. However, this does not change the fact that the "fine tuning" being done here is often very specific to the actual machine the device is being connected to. This is why in some cases, it is necessary for the "fine tuner" to have access to the user's actual machine for testing purposes, in order to effectively fix the problem.

[candle]

but what if the user wants to get his device working in serveral machines? would you like to get them all and sit your butt till you die or them all worked?

not the way out either

and comercial failure

this time should be spend once, and the troubles long forgotten

[MEtalGuy66]

Well, like it or not, it has been the "way out" in the past in many situations involving PBI devices.

 

Look, The idea of comming up with a "universal solution" to the problem has definite merit..

 

But the point I'm trying to illustrate is that the problem is not that the PBI devices are poorly designed.. The problem is that ATARIs were poorly manufactured..

[candle]

so we both agree there is problem

i just won't accept that it has no solution, even if its hard to get there

[dmlloyd]

Getting back to the original question, I've found some evidence in the OS listing I have that some or all PBI code was actually *removed* at some post-XL (pre-XE?) stage:

 

***	OS - Operating System
*
*	NOTES
*		This source is currently being refined.  Areas which
*		need work are indicated by question marks ("???").
*
*	MODS
*		Revision A (400/800)
*		D. Crane/A. Miller/L. Kaplan/R. Whitehead???	??/??/??
*
*		Revision B (400/800)
*		Fix several problems.
*		M. Mahar/R. S. Scheiman???	??/??/??
*
*		Revision 10 (1200XL)
*		Support 1200XL, add new features.
*		H. Stewart/L. Winner???
*		R. S. Scheiman/Y. M. Chen/M. W. Colburn	10/26/82
*
*		Revision 11 (1200XL)
*		Fix several problems.
*		R. S. Scheiman	12/23/82
*
*		Revision 1 (600XL/800XL)
*		Support PBI and on-board BASIC.
*		R. S. Scheiman/R. K. Nordin/Y. M. Chen	03/11/83
*
*		Revision 2 (600XL/800XL)
*		Fix several problems.
*		R. S. Scheiman	05/10/83
*		Bring closer to Coding Standard (object unchanged).
*		R. K. Nordin	11/01/83
*
*		Revision 3 (600XL/800XL/1450XLD)
*		Fix MAXDEV, problems resulting from CRASS65 version,
*		initial address for RAM sizing, "Boot Error" message,
*		initial address for cartridge equivalence checksum,
*		mishandling of SIO NAK, initializing of CHKSUM, and
*		initialization of PORTB.
*		R. K. Nordin	03/27/84
*
*		Revision 3, Version 2 (600XL/800XL/1450XLD)
*				
*               Dedicate PDVI ($D1FF) to external parallel device IRQ status
*		Dedicate IPDVI ($D1CF) to internal parallel device IRQ status
*		Using PDIMSK ($0249) for external parallel device IRQ selection mask
*		Using IPDIMK ($0254) for internal parallel device IRQ selection mask
*		After masking (PDVI, PDIMSK) & (IPDVI, IPDIMK), OR the result
*		together, piror to processing parallel device IRQ
*
*		On cold start, initialize PDVI = 0, to avoid potential
*		checksum error.
*		Y. T. JANG, V. WU	02/22/84
*
*		Revision 3, Version 3  (600XL/800XL/1450XLD)
*
*		Dedicate the 11 bytes at ACMVAR ($3ED-$3F7) for use as
*		a RESET routine area.  On warmstart, the OS will JSR
*		to ACMVAR immediately after initializing hardware.
*		MIKE BARALL		06/08/84
*
*		Revision 3, Version 4  (600XL/800XL/1450XLD)
*
*		Make CIO accept device number 0 (like Rev B did).
*		MIKE BARALL		06/21/84
*
*		Revision 4, Version 0 (600XL/800XL/1450XLD)
*
*		Add support for SIO fast mode (38400 baud).
*		Add resident Help Text Viewer.
*		Remove Peripheral Handler Loading Facility.
*		MIKE BARALL		07/16/84
*
*		Revision 5, Version 0 (800XL/800XLF/900XLF/900XLFK)
*
*		Revert to Rev. B device handlers (E:, C:, P:, S:, K:),
*		(with bug fixes) to eliminate need for Translator.
*		Remove parallel I/O support.
*		Fix keyboard display in self-test.
*		MIKE BARALL & VINCENT WU	09/04/84

 

No, I don't remember where I got this listing, but isn't "rev.5" what's in the XEs? And I can definitely verify that there is no PBI support in the IRQ, SIO, CIO, or boot path of this listing.

 

There is some evidence that this listing is divergent from the actual OSes which made it into production use, and that is the "Boot Error" message is in mixed-case rather than all-caps, which is what I see on my XE.

 

Anyone have any insight on the matter?