Jump to content
pfeuh

[ATARI 800XL] Using extension bus

Recommended Posts

Hello,

 

Here is a page about extension bus from an Atari 800XL

 

http://www.page6.org/archive/issue_32/page_66.htm

 

All pins to add a hardware device seem to be present: A0-A15, D0-D15, IRQ, read/write_, reset... Is there anybody experienced with this bus? Doing an additionnal card with some IOs, an UART, a RTC should not be a huge task... Idem for doing a PCB an product it for some pieces.

 

A couple of friends did a midi interface in the heighties, it was for the expansion bus of the 130XE, The uart was a Rockwell 24 or 40 pins, my memory is not at the top... But I think that if somebody did it in the 80's it should be possible to do it again now, isn't it?

Share this post


Link to post
Share on other sites

Last but not least, this expansion bus was used in the 600XL to add some ram, WIth it, the 600XL is a 800XL. It means that this bus is fonctional. Is there really no hardware developper, here? :-o

Edited by pfeuh

Share this post


Link to post
Share on other sites

There's multiple facets of the PBI to get to know. There's the physical interface, and also the extensions to the OS and system architecture that it allows.

 

For what you want to do, it might be sufficient to use the cartridge port. There are more constraints of course, physically you usually want to fit everything in the size of a game cartridge (maybe slightly longer) and there's the constraint of less addressability.

But the cart port allows addressing of a 256 byte area that appears at $D5xx which is handy for bankswitching ability or adding other custom chips.

 

The PBI - it's somewhat more complex. There are control lines coming into the computer like EXSEL - this allows disabling an access that would normally go to internal Ram. There is MPD which custom device handlers can hook into the system, it disables the FP ROM at $D800-$DFFF.

 

There's various protocols and standards to adhere to if you want to create a PBI "compliant" device. But if you're just doing a hobbyist project you can do it in a more simplistic fashion. Simply adding your IO devices to work in addresses $D600-$D7FF can be sufficient. You need to do your own address decoding though (note the ECI functions offered on the XE provide some different pin functions,the D1xx pin being one since PBI/ECI compliant devices will use the D1 page)

 

If you wanted to build something with some RAM, one option is to just address 256 bytes of it at a time, then have a banking register that selects the base. e.g. put your registers at $D600, put the Ram appearing at $D700.

  • Like 1

Share this post


Link to post
Share on other sites

Hello Rybags,

 

Thanks, it helps. It's a hobbist project for sure... But I would like to do it "properly". It's a midi interface. That means a UART, a quartz and the IRQ pin management. It doesn't need ram, just addressing a chip with 4 registers, I suppose. I can do this with the PBI in the area D600-D7FF as you said, First step is to find a connector and an experimentation board, second step is doing a partial address decoding in this area.

 

Do you confirm that area D600-D7FF is readable and writable on the PBI?

Edited by pfeuh

Share this post


Link to post
Share on other sites

Practically any area is R/W on PBI - of course you tend to avoid the pages D0, D2, D3, D4 since they're always connected to the system's I/O chips.

Avoid D1 also as it's intended for "compliant" PBI devices.

 

D6/D7 are used (sort of illegally) by some upgrades like VBXE but for your use just go ahead.

 

Also with the IRQ functionality you'd need to provide a custom handler for that part. PBI compliant devices can have their IRQs handled by the OS (of course though you still provide the ROM code to do the IRQ processing)

 

The only reason you'd do your project as a compliant device is if you have your own ROM onboard with the MIDI handler/driver. This is something you'd probably consider once it's all finalised. During development it'd probably be easier to just have the I/O available and have your driver loaded from disk.

 

With the address decoding - the system internally uses a 74LS138 which provides individual selects for each page from D0 to D7 - if you don't mind a bit of internal modding then you can use that to save some work.

Edited by Rybags
  • Like 1

Share this post


Link to post
Share on other sites

Thanks, Rybags, I see, I have found the 800XL schematic with the 74LS138 and the PAL16L8. I have notice that pages D1, D4 D6 and D7 are not connected...But I will use only D6 as you said. Using A7 and A6, it is possible to put 4 different devices together in this page, like a battery saved real time clock, general purpose io bits, SPI or I2C controller and so on.

 

The reception FIFO will be filled by the reception irq and emptied by the application.This is mandatory because of the long time of the VBI which disable polling method.

 

Generally, an application is a finite state machine, so the reception of a byte should not be blocking,.. That's why I have to add a fonction "inkey" to the driver, to test if reception FIFO is empty or not.

 

Ideally, the midi emission should have a FIFO too. As a must to have, if the "open" function manages the baudrate, 2 jumpers could switch the hardware from midi to rs232.

 

I have some other projects to finish, then I will dive into this one! I think it's a good project, but as there is a lot of hardware, I'm a little bit afraid.

Share this post


Link to post
Share on other sites

Here is what I propose for address decoding. All signals are active low.

 

PBI_IO D600-D6FF

PBI_IO_1 D600-D61F

PBI_IO_2 D620-D63F

PBI_IO_3 D640-D65F

PBI_IO_4 D660-D67F

PBI_IO_5 D680-D69F

PBI_IO_6 D6A0-D6BF

PBI_IO_7 D6C0-D6DF

PBI_IO_8 D6E0-D6FF

 

If a hardware guy could tell me which family (LS, ALS, ...) is the most able for low consumtion and speed, it could be cool. I'm not sure if cascading 3 chips as I've done let have enough speed. The schematic is in attachment.

post-32161-0-07964200-1407520708_thumb.gif

Edited by pfeuh

Share this post


Link to post
Share on other sites

I think the 74HC are best suited but someone more knowledgable could confirm.

 

I guess with the propogation delays... add up to get your worst-case scenario. 1 cycle = about 558 ns, you want to get in under half that. I remember reading that the longest acceptable latency for RAM was 250 ns.

The PDFs for the custom chips Pokey & GTIA have the timing diagrams showing the relationship among Phi2, r/w, CS etc.

  • Like 1

Share this post


Link to post
Share on other sites

I think the 74HC are best suited but someone more knowledgable could confirm.

 

I guess with the propogation delays... add up to get your worst-case scenario. 1 cycle = about 558 ns, you want to get in under half that. I remember reading that the longest acceptable latency for RAM was 250 ns.

The PDFs for the custom chips Pokey & GTIA have the timing diagrams showing the relationship among Phi2, r/w, CS etc.

 

74HCT, the HC is high speed cmos, HCT is high speed cmos, ttl compatible

  • Like 1

Share this post


Link to post
Share on other sites

Hello,

 

I'm currently on holydays at Toulon, on the Mediterranean Sea. ;) I've also got an unexpected Gibson jumbo for the long lazy afternoons! Water temperature is 21°C, very nice! See you later in a couple of weeks!

 

In the worst case, I will not sold the second multiplexer and just bypass it's pins let's say 4 and 15. For the moment, the project is froozen

Share this post


Link to post
Share on other sites

Earl Rice, who worked on the 1450XLD at Atari also recommended using 74HCT chips. He wrote a 4 part series in Antic magazine called 'Parallel Bus Revealed'.

http://www.atarimagazines.com/v3n9/Parallel_Bus.html
http://www.atarimagazines.com/v3n10/parallelbus.html
http://www.atarimagazines.com/v3n11/parallel_bus.html
http://www.atarimagazines.com/v3n12/toolbox.html

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...