How to Make New PBI Devices

[UNIXcoffee928]

Thank you, Sloopy, for messaging me with the "Jerzy Schematics". Presuming that they are correct, the proper conductor designations for the Atari 800 Test Point Interface are as follows:

 

E

CC

DD

 

 

Y

 

 

26

BB

 

 

4

W

V

21

13

T

R

X

17

U

18

12

S

P

I

AA

 

27

EE

 

H

5

7

6

 

25

FF

28

 

J

K

8

F

 

 

Z

23

24

=========================

 

 

Am I correct , below, with regard to the Numbering Scheme, for the Conductor Designations of the conductors on the physical board, itself?

 

=========================

TOP Side of Atari 800 TPI

=========================

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

 

============================

BOTTOM Side of Atari 800 TPI

============================

A

B

C

D

E

F

H

J

K

L

M

N

P

R

S

T

U

V

W

X

Y

Z

AA

BB

CC

DD

EE

FF

 

 

 

 

 

Thanks!

 

 

[sloopy]

yup, looks right... and although those schematics have small errors here and there, the XEGS type cart, i fixed one of the schematics, and checked every trace to a real cart, so I can say its 100% correct...

 

sloopy.

[Noelio]

I too would welcome such an effort. While working at TV Guide a while back I was fascinated by their use of an ECI device on the 130xe to receive a sat signal and grab the guide data off of it. This is what renewed my interest in the Atari 8-bit computers. I had a few weeks in-between work projects last Christmas and, going throught the same article, I researched and purchased all the components on the PBI parts list but have not done anything with them yet.

Here's a few topics regarding the EPG Jrs used by TV Guide / Prevue. I ordered some out of intrigue and the handy rack mount they came with. Good discussions in these threads below...

 

http://www.atariage.com/forums/topic/120523-130xe-runs-the-show-update-on-script-roller-system/page__p__1458305__hl__prevue__fromsearch__1#entry1458305

 

http://www.atariage.com/forums/topic/118580-130xe-tv-station-setup/page__p__1698341__hl__prevue__fromsearch__1#entry1698341

 

AriX has been deconstructing the hardware & software...

http://www.atariage.com/forums/topic/171349-prevue-guide-epg-jr-reverse-engineering/page__p__2121309__hl__prevue__fromsearch__1#entry2121309

[UNIXcoffee928]

yup, looks right... and although those schematics have small errors here and there, the XEGS type cart, i fixed one of the schematics, and checked every trace to a real cart, so I can say its 100% correct...

 

sloopy.

 

OK, based on your verification of the numbering scheme, I attempted to correlate the data from Jerzy's schematics, and create a Pin Assignment Sheet for the Test Point Interface on the 800. I checked this against an actual physical Atari 800 main board, and found a number of discrepancies. I was able to find errors, because some of the conductors on the actual physical board were physically Not Connected.

 

 

With regard to my physical inspection of the board, I marked Connections with an 'X' and Not Connected with 'N/C', in the table, below. I assigned each of Jerzy's signals to the conductor that they were supposed to be going to in the following column. The Discrepancies between the observations of the physical board, and Jerzy's signal info are marked "????".

 

Can someone with the proper equipment give it a check? I suppose that you would need a logic analyzer... perhaps someone can also explain How one checks such signals?

 

Here are my findings:

 

Atari-800_TPI_Draft_01.txt

 

 

 

[sloopy]

for an absolute definite correct answer, removal of all components and then do an ocular scan is best...

 

if no one else answers tomorrow i will take a look...

 

sloopy.

[UNIXcoffee928]

for an absolute definite correct answer, removal of all components and then do an ocular scan is best...

 

if no one else answers tomorrow i will take a look...

 

sloopy.

Uggg. I got a horrible case of Poison Ivy on my face & arms, and it is misery.

 

My board is populated, and has all slots intact. I could take some good close-up photos, but maybe someone out there has a bare 800 board that they could post photos of...

 

 

I spent the day reading up on & looking at Logic Analyzers, and I think that I'd like to get a dedicated device, rather than a PC-based solution, even if it is older equipment. The trouble is that I would like to have the functionality of a multi-trace Oscilloscope, an RS-232 Protocol Analyzer, and a good Logic Analyzer, that I won't grow out of quickly. Since I really don't have a lot of money to spend, I don't think that I can afford get something that does it all, so I'll have to slowly buy separate stand-alone devices.

 

I was looking at older HP gear, and a fully tricked-out HP 1630G Logic Analyzer seems like it is still a very useful device, despite it's vintage. I spent some time reading it's manual in pdf, and it seems like it was pretty much top-of the line, back when it was introduced.

 

I do have a question about these devices, though... I see a lot of HP1630s on ebay with no Pods, and no Probes... are these Pods & Probes a standard with many models of HP gear or just the 1630s? What do I look for, model-number-wise? There were some complete setups, with the pods & probes, but they are often much costlier. Anyone familiar with these units?

 

I plan on using this stuff specifically for Atari 8-Bit vintage electronics, older RS-232 terminal gear, and early to mid 80s Roland synthesizers, so it probably is better, anyway, that I go with a bunch of similar-vintage HP test equipment, right?

 

 

[+bob1200xl]

Noooooo....

 

I am just one person who has purchased one logic analyzer, but you are really going to be able to do so much more with a PC-based product. It has very, very fast inputs and, most importantly, a large selection of trigger criteria. Intronix LA1034, $400, new.

 

The HP units that I remember are OK, but it's really no contest.

 

An old Textronix scope, however... very nice. (a 465A or a 475A or ?)(get the TeK probes!)

 

Bob

 

 

 

for an absolute definite correct answer, removal of all components and then do an ocular scan is best...

 

if no one else answers tomorrow i will take a look...

 

sloopy.

Uggg. I got a horrible case of Poison Ivy on my face & arms, and it is misery.

 

My board is populated, and has all slots intact. I could take some good close-up photos, but maybe someone out there has a bare 800 board that they could post photos of...

 

 

I spent the day reading up on & looking at Logic Analyzers, and I think that I'd like to get a dedicated device, rather than a PC-based solution, even if it is older equipment. The trouble is that I would like to have the functionality of a multi-trace Oscilloscope, an RS-232 Protocol Analyzer, and a good Logic Analyzer, that I won't grow out of quickly. Since I really don't have a lot of money to spend, I don't think that I can afford get something that does it all, so I'll have to slowly buy separate stand-alone devices.

 

I was looking at older HP gear, and a fully tricked-out HP 1630G Logic Analyzer seems like it is still a very useful device, despite it's vintage. I spent some time reading it's manual in pdf, and it seems like it was pretty much top-of the line, back when it was introduced.

 

I do have a question about these devices, though... I see a lot of HP1630s on ebay with no Pods, and no Probes... are these Pods & Probes a standard with many models of HP gear or just the 1630s? What do I look for, model-number-wise? There were some complete setups, with the pods & probes, but they are often much costlier. Anyone familiar with these units?

 

I plan on using this stuff specifically for Atari 8-Bit vintage electronics, older RS-232 terminal gear, and early to mid 80s Roland synthesizers, so it probably is better, anyway, that I go with a bunch of similar-vintage HP test equipment, right?

[UNIXcoffee928]

Noooooo....

 

I am just one person who has purchased one logic analyzer, but you are really going to be able to do so much more with a PC-based product. It has very, very fast inputs and, most importantly, a large selection of trigger criteria. Intronix LA1034, $400, new.

 

The HP units that I remember are OK, but it's really no contest.

 

An old Textronix scope, however... very nice. (a 465A or a 475A or ?)(get the TeK probes!)

 

Bob

 

I had looked at the LA1034, but it is out of my price range. I did use it as one of the benchmarks for my comparison shopping, though. It may be something that I purchase, in the future, to augment my setup, down the road, if I happen to run into some extra cash.

 

Fully configured, the HP 1630G has 65 channels, but it only has a 25MHz sampling rate. On the plus side, you can buy (if you can still find them) pin to pin probe socket interfaces that plug in directly between 1980s CPUs and the circuit board socket. It can monitor 8 signals at once on one display, and set labels & markers. The Inverse Assembly feature looks cool, too.

 

 

As far as a Protocol Analyzer goes, the HP 4953A (and some other 49xx series stuff) looks pretty decent. I'm trying to get set up as inexpensively as is possible, it's ok if this stuff takes up physical space. I'd rather have old pro gear, than new consumer gear.

 

I will check out the Tektronix 475A... Are there any other scopes that you recommend?

 

 

[+bob1200xl]

The TeK 454 is pretty good. The 453 is only 50mhz, kind of marginal for the Atari, depending on what you are doing.

 

 

If you're serious about working with this stuff, you really need good tools. Yes, I understand about the high entry cost, but buying something inadequate may be a waste of money in the long run. I did a *lot* of projects with no logic analyzer at all. Maybe you should put it off for a while?

 

This is how I connect to the logic with the Intronix. These clips are available for all DIP configurations and will work on chips that are not in sockets.

 

Bob

 

 

Noooooo....

 

I am just one person who has purchased one logic analyzer, but you are really going to be able to do so much more with a PC-based product. It has very, very fast inputs and, most importantly, a large selection of trigger criteria. Intronix LA1034, $400, new.

 

The HP units that I remember are OK, but it's really no contest.

 

An old Textronix scope, however... very nice. (a 465A or a 475A or ?)(get the TeK probes!)

 

Bob

 

I had looked at the LA1034, but it is out of my price range. I did use it as one of the benchmarks for my comparison shopping, though. It may be something that I purchase, in the future, to augment my setup, down the road, if I happen to run into some extra cash.

 

Fully configured, the HP 1630G has 65 channels, but it only has a 25MHz sampling rate. On the plus side, you can buy (if you can still find them) pin to pin probe socket interfaces that plug in directly between 1980s CPUs and the circuit board socket. It can monitor 8 signals at once on one display, and set labels & markers. The Inverse Assembly feature looks cool, too.

 

 

As far as a Protocol Analyzer goes, the HP 4953A (and some other 49xx series stuff) looks pretty decent. I'm trying to get set up as inexpensively as is possible, it's ok if this stuff takes up physical space. I'd rather have old pro gear, than new consumer gear.

 

I will check out the Tektronix 475A... Are there any other scopes that you recommend?

[sloopy]

I used to own a 1630 series, worked well for me and sold it to another AA member who uses it now... i now have a 16500A and i like it. If you are patient and keep a close eye on ebay you can get one for under $200 shipped.

 

afor the 1630/1631, make SURE you get the pods/wires for it, they are hard to find otherwise, the clips are just a matter of $$$, but the pods are a alittle difficult to find, and the small adaptors that go from pod to clips are impossible unless you get them with a LA. Mine came with 3, and I had to make one, which worked but the correctness of exact timing etc cant me really known...

 

sloopy.

[candle]

one question

 

why would one need LA for really?

for building complete, working PBI device it isn't required

for getting semi-working one it would be nice to see whats really on the bus, but that can be avoided on the first place

[+bob1200xl]

As I stated, you can build a lot of hardware without a logic analyzer. But, the hardware is not a deterministic plane. You can't characterize it completely - a one is not always a one and a zero is not always a zero. And, we don't know everything we need to know about what we are working with.

 

Some parameters cannot always be measured directly, like interrupt latency. You have to measure them in the real world.

 

Yes, this is not so useful for the casual experimenter.

 

Bob

 

 

 

one question

 

why would one need LA for really?

for building complete, working PBI device it isn't required

for getting semi-working one it would be nice to see whats really on the bus, but that can be avoided on the first place

[sloopy]

one question

 

why would one need LA for really?

for building complete, working PBI device it isn't required

for getting semi-working one it would be nice to see whats really on the bus, but that can be avoided on the first place

 

dont really 'need' one, it just makes things easier, especially when repairing broken and problem machines... i know a couple repairs, where it took less then 15-20mins for diagnosis, and the majority of that time I was just hooking up clips. But if i didnt have it, it would have taken me longer...

 

altho i dont charge by the hour for repairs, i dont want to spend a couple hours on just a simple problem...

 

sloopy.

[UNIXcoffee928]

I started reading the Original Guides from MOS ( MOS MCS6500 Family Hardware Manual & the MOS MCS6500 Family Programming Manual )... I wish that I had access to these, back in the day... they are REALLY good... much better than anything else that I had read, that came out later.

 

 

 

 

 

 

 

[UNIXcoffee928]

I ran across a very useful program called "Logisim", which is a logic simulator application that lets you build circuits, and modify them, while circuit simulation is enabled. It has a library of 7400-Series ICs freely available, and lets you build and test circuits in a similar fashion to the way that you would build them on a breadboard, without the hassle of having physical components on hand, during the design phase. In some ways, it is more useful than a breadboard, since you can modify component placement and groups of traces without a great deal of annoyance, and you don't have to worry about destroying components.

 

When I was in college, we studied Formal Logic and Discrete Structures, and I took to them very keenly, at the time, with all of the truth tables and expressions. I wish that they had had a program like this, back then, as well, to be able to show how all of that theory worked, in practice, as building blocks in real hardware. Logisim is really good, in this regard, because you can do just that, on a number of levels, from the most basic logic gate level up through the component level. I like that it is both visual & hands on, because it makes it really fun to experiment with the live circuit, and to determine interesting ways to wire groups of traces from standard DIP components.

 

If there's anyone else with a more CS-oriented background that is looking to expand their EE hardware design knowledge, this program will definitely help.

 

 

[sloopy]

they did, i dont rem the name of it, but i used to use it alot in college (i went for EE in 90/91), unfortunately we only had the mac version, and required a full color mac and i only had a SE/30, but would use it at uni...

 

EWB- Electronics WorkBench, that was the name of it... was like $1000 for retail version... no academic version :'/

 

(Note: there were two versions of Color QuickDraw, one was in mac starting with the SE and II, and the 'Full' which was supported later, and that is what this app needed for some reason, even tho it would run in 16 and 256 color mode fine... by the time i got my IIci, my disks were bad...)

sloopy.

[UNIXcoffee928]

I found a fairly recent six-part presentation, entitled, "Reverse Engineering the MOS 6502 CPU" which has a lot of good info in it. Slowly, I'm getting there, filling my head up with all of this stuff.

 

I'm sort of surprised that no one here can prepare a tutorial on the bare basics of how to hook up a single, user programmable 7-Segment Display component to the PBI... I mean, I'm pretty much starting from scratch, and I'm half-way to being able to explain it... I guess that the people who know how are too busy with other stuff, and everybody else hasn't the foggiest idea of how to do it. I guess that if no one has a go at it, then, sometime, within a year, I'll be able to explain how to do it.

 

 

[UNIXcoffee928]

I found a fairly recent six-part presentation, entitled, "Reverse Engineering the MOS 6502 CPU" ...

 

Here's a better quality download link of the full, uninterrupted, presentation:

 

 

http://ftp.ccc.de/congress/2010/mp4-h264-HQ/27c3-4159-en-reverse_engineering_mos_6502.mp4

 

 

[Rybags]

You could probably do that with a single joystick port.

 

There's PBI attached and there's proper PBI... just hanging something off there doesn't make it full capability.

 

You could probably just use a latch or two to drive the display, and a logic IC or 2 to take care of the addressing.

 

It only gets real complicated if you wanted to have a ROM + handler to drive the thing.

[UNIXcoffee928]

You could probably do that with a single joystick port.

Yup, when I was 13... although it's probably a good idea for prototyping the initial stages of this.

 

There's PBI attached and there's proper PBI... just hanging something off there doesn't make it full capability.

PBI Proper. I'm looking to create a 'skeleton method' for creating more complicated devices, by covering all of the bases of how to create a proper PBI device, from Square One, with a simple component that anyone can understand.

 

 

You could probably just use a latch or two to drive the display, and a logic IC or 2 to take care of the addressing. It only gets real complicated if you wanted to have a ROM + handler to drive the thing.

Well, that's the thing... everything else is fairly complicated... that's why wanted to simplify the matter by just using the bare minimum (the 7-segment display). The Antic article is no good for beginners, because the focus is on hooking up a much more complicated device.

 

Basically, I'd like to have a bare-bones basic PBI-activated 7-Segment Display handler, that can be expanded upon for any later projects. I don't think that a ROM would be necessary. Other than that a connector and a small PCB. I'd like to keep the hardware as simple as possible, so that the focus is more on creating a Generic Method for designing PBI devices and their associated handlers.

In general, there should be a loadable handler, and the actual PBI device. The 7-Segment Display should be able to be accessed via BASIC and Assembly, and each segment should be able to be programmed to light up or turn off independently.

 

 

My initial questions are:

 

- Why would you use a ROM in this case? I'm only looking for a device that a user can program, to specifically light or turn off any/all of the 7 segments, by sending it one byte of data, containing the desired on/off pattern for the 7-Segment Display.

 

- Which model/type of logic ICs are you suggesting, and why?

 

- Can you explain, further, how such addressing works, in a general way? (with regard to activating PBI signals for use).

 

- What is the proper Connector Name for the XL's PBI, and is it still available anywhere?

 

Thanks!

Edited July 13, 2011 by UNIXcoffee928

[Rybags]

You'd want a ROM to be a proper PBI device supplying it's own handler. That's half the point of the thing, the driver becomes in effect resident rather than needing to have AUTORUN files and such.

 

You need to do your own address decode for the D1 page. Then provide the correct bit input when the OS probes for attached device/s.

 

Aside from the known docs, you can get some clues by trawling through the XL OS. The SIOV $E459 codepath is worth checking out, as well as the cold/warmstart code.

 

I'm picking bits and pieces up as I play with IDE + 2. You look at how this stuff works and see just how versatile the OS was designed to be and what a tragedy it was that Atari did next to nothing with products to extend the architecture within it's framework.

[+bob1200xl]

If the ANTIC article is too complex, try a Supra MicroPort. It will give you basic decoding on the PBI. Add a latch and you're set.

 

Bob

 

 

 

I found a fairly recent six-part presentation, entitled, "Reverse Engineering the MOS 6502 CPU" which has a lot of good info in it. Slowly, I'm getting there, filling my head up with all of this stuff.

 

I'm sort of surprised that no one here can prepare a tutorial on the bare basics of how to hook up a single, user programmable 7-Segment Display component to the PBI... I mean, I'm pretty much starting from scratch, and I'm half-way to being able to explain it... I guess that the people who know how are too busy with other stuff, and everybody else hasn't the foggiest idea of how to do it. I guess that if no one has a go at it, then, sometime, within a year, I'll be able to explain how to do it.

[+bob1200xl]

You do not need a ROM.

 

Use 74HCxxxx devices. Low current, fast enough, cheap. Get a manual for them.

 

The decoder only activates the output when the inputs match a certain pattern. You set the pattern and anytime the inputs are as selected, you get an output signal. This output signal sets the latch on the data bus which drives the 7-segment display.

 

It's a PCB edge connector. 50 pins. .100inch spacing. Yes, hard to find...

 

Bob

 

 

 

You could probably do that with a single joystick port.

Yup, when I was 13... although it's probably a good idea for prototyping the initial stages of this.

 

There's PBI attached and there's proper PBI... just hanging something off there doesn't make it full capability.

PBI Proper. I'm looking to create a 'skeleton method' for creating more complicated devices, by covering all of the bases of how to create a proper PBI device, from Square One, with a simple component that anyone can understand.

 

 

You could probably just use a latch or two to drive the display, and a logic IC or 2 to take care of the addressing. It only gets real complicated if you wanted to have a ROM + handler to drive the thing.

Well, that's the thing... everything else is fairly complicated... that's why wanted to simplify the matter by just using the bare minimum (the 7-segment display). The Antic article is no good for beginners, because the focus is on hooking up a much more complicated device.

 

Basically, I'd like to have a bare-bones basic PBI-activated 7-Segment Display handler, that can be expanded upon for any later projects. I don't think that a ROM would be necessary. Other than that a connector and a small PCB. I'd like to keep the hardware as simple as possible, so that the focus is more on creating a Generic Method for designing PBI devices and their associated handlers.

In general, there should be a loadable handler, and the actual PBI device. The 7-Segment Display should be able to be accessed via BASIC and Assembly, and each segment should be able to be programmed to light up or turn off independently.

 

 

My initial questions are:

 

- Why would you use a ROM in this case? I'm only looking for a device that a user can program, to specifically light or turn off any/all of the 7 segments, by sending it one byte of data, containing the desired on/off pattern for the 7-Segment Display.

 

- Which model/type of logic ICs are you suggesting, and why?

 

- Can you explain, further, how such addressing works, in a general way? (with regard to activating PBI signals for use).

 

- What is the proper Connector Name for the XL's PBI, and is it still available anywhere?

 

Thanks!

[kurtm]

If the ANTIC article is too complex, try a Supra MicroPort. It will give you basic decoding on the PBI. Add a latch and you're set.

 

Anyone have the manual for the MicroPort? I picked one up used many years ago, but no book.

[UNIXcoffee928]

You'd want a ROM to be a proper PBI device supplying it's own handler. That's half the point of the thing, the driver becomes in effect resident rather than needing to have AUTORUN files and such.

 

Oh, I get it, it has to have a ROM to be a "Proper PBI Device". So, the average hobbyist would need to have access to an EPROM burner, to even think of beginning to develop for the PBI, then. This also implies that the average hobbyist would also need to understand how to connect an EPROM to the PBI.

 

I would guess that a microcontroller with a tiny amount of self-contained RAM & flash could be utilized, to eliminate the EPROM & Logic ICs, and simplify the design, so that anyone could put a device together, without having an EPROM programmer, right? Would Teensy be a good choice for this type of thing? Seems like it would be.

 

You need to do your own address decode for the D1 page.

 

Can you explain this further?

 

Then provide the correct bit input when the OS probes for attached device/s.

 

Does the machine constantly poll the PBI? That would be grossly inefficient, from a systems design standpoint. I would have thought that it was interrupt-driven. Even still, using an interrupt would probably be a better way of doing things with this, since this whole thing is meant to be a black-box to make any device that can attach to the PBI, and, as such, it should be designed as correctly as is possible. If it is interrupt-driven, it will ensure that future devices won't have performance hits from waiting around for polling.

 

Aside from the known docs, you can get some clues by trawling through the XL OS. The SIOV $E459 codepath is worth checking out, as well as the cold/warmstart code.

 

Thanks. That'll take a while.

 

I'm picking bits and pieces up as I play with IDE + 2. You look at how this stuff works and see just how versatile the OS was designed to be and what a tragedy it was that Atari did next to nothing with products to extend the architecture within it's framework.

 

I'm now wondering how the device's resident handler communicates with the OS... Am I correct in gathering that there will need to be both an OS HATABS handler, and a separate Resident Device Driver on the PBI?

 

 

Thanks!