pfeuh Posted August 6, 2014 Share Posted August 6, 2014 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? Quote Link to comment Share on other sites More sharing options...
pfeuh Posted August 7, 2014 Author Share Posted August 7, 2014 (edited) 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? Edited August 7, 2014 by pfeuh Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 7, 2014 Share Posted August 7, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
pfeuh Posted August 7, 2014 Author Share Posted August 7, 2014 (edited) 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 August 7, 2014 by pfeuh Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 7, 2014 Share Posted August 7, 2014 (edited) 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 August 7, 2014 by Rybags 1 Quote Link to comment Share on other sites More sharing options...
pfeuh Posted August 7, 2014 Author Share Posted August 7, 2014 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. Quote Link to comment Share on other sites More sharing options...
pfeuh Posted August 8, 2014 Author Share Posted August 8, 2014 (edited) 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. Edited August 8, 2014 by pfeuh Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 8, 2014 Share Posted August 8, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
tregare Posted August 30, 2014 Share Posted August 30, 2014 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 1 Quote Link to comment Share on other sites More sharing options...
pfeuh Posted August 30, 2014 Author Share Posted August 30, 2014 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 Quote Link to comment Share on other sites More sharing options...
Innovative Leisure Posted September 9, 2014 Share Posted September 9, 2014 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.htmlhttp://www.atarimagazines.com/v3n10/parallelbus.htmlhttp://www.atarimagazines.com/v3n11/parallel_bus.htmlhttp://www.atarimagazines.com/v3n12/toolbox.html 1 Quote Link to comment Share on other sites More sharing options...
pfeuh Posted September 11, 2014 Author Share Posted September 11, 2014 Awesome! Thanks, it helps a lot! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.