+mytek Posted January 13, 2017 Share Posted January 13, 2017 so what XL pbi pin should be on the eci? since the XL PBI seems settled? I was under the assumption that we were only working on one parallel bus interface (well at least that's what I aim to support in my project). - Michael Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 13, 2017 Share Posted January 13, 2017 (edited) looks like she was ready to commit so it's a case of afterthoughts.... I think it's good to go....thumbs up! I want the most important XL pin to fill the XE eci A pin as well so everybody can have a shot at the new device working and the most extensions having the possibility of working on the XE as well. No reason not to decide what's the most important pin to give the XE a shot... it is just one signal. Can't hurt! The other stuff seems pretty settled and this shouldn't affect what's been done for the XLpin standardization.... just helps the XE a bit... I use the MIO on both XL/XE(with supra eci/pbi cart board) and the Black Box on both(using ribbon cable to the XL)... so I figure why not the new XLR projects as well. Edited January 13, 2017 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
+mytek Posted January 13, 2017 Share Posted January 13, 2017 looks like she was ready to commit so it's a case of afterthoughts.... I think it's good to go....thumbs up! I want the most important XL pin to fill the XE eci A pin as well so everybody can have a shot at the new device working and the most extensions having the possibility of working on the XE as well. No reason not to decide what's the most important pin to give the XE a shot... it is just one signal. Can't hurt! The other stuff seems pretty settled and this shouldn't affect what's been done for the XLpin standardization.... just helps the XE a bit... I use the MIO on both XL/XE(with supra eci/pbi cart board) and the Black Box on both(using ribbon cable to the XL)... so I figure why not the new XLR projects as well. If I were to give the ECI one more signal, it would be CASinh (same as PBI EXTENB). I can't for the life of me see how this wasn't a part of the original ECI, and to top it off they had an extra pin available - Michael 1 Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted January 13, 2017 Author Share Posted January 13, 2017 (edited) If I were to give the ECI one more signal, it would be CASinh (same as PBI EXTENB). I can't for the life of me see how this wasn't a part of the original ECI, and to top it off they had an extra pin available - Michael Based on tf_hh's earlier statement, I am inclined to agree that CASinh(EXTENB) should be placed on Pin A of the ECI Edited January 13, 2017 by Dropcheck 2 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 13, 2017 Share Posted January 13, 2017 absolutely, makes perfect sense, publish it! There was a metal case that consisted of a base and 4 panels that were flat packed (cheap to send via usps if it fits it ships) or other carrier. Easy to assemble and looked nice. It assembles with shiny pan head stubby screws.... I am looking for it again. It came in a light beige and the second option was ligh greyish white. not sure what ideas or cases have been looks at but from a hobby shipping stand point it might be a good option. I am sure others can find similar or same cases. Just something I had seen over the last few years... Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 13, 2017 Share Posted January 13, 2017 (edited) A question about Bus arbitration.... The PBI currently allows for 8 devices and each device can have it's own logical units (just like scsii) Atari allowed for d1 thru d7 in the pbi... but d0 does exist..... d0 was reserved by Atari..... for their own takeover use a card that would always be in the primary slot allowing for the PBI to have a remote device actually be the computer and jam data to the Atari as the keyboard and and still use all the hardware in the Atari... The question I posit is.... will that still be the arrangement.... I know on later machines including the Falcon you assigned a scsii ID to the computer itself, that allowed for more than one computer on the scsii chain.... used in combination with proper software/drivers it allowed for files on the drives and well as access to the other machine on the network, I did this at one point and we still have two scsii differential boxes (by Black Box, not CSS) to extend that network in house... it allowed the network to reach very far... much faster than the network card/serial lan options that existed at the time.... The thought in my mind... one XLR two or three Atari's I may be getting way ahead of things but it is a persistent thought.... it does make for some interesting ideas! Edited January 13, 2017 by _The Doctor__ 2 Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted January 14, 2017 Author Share Posted January 14, 2017 (edited) A question about Bus arbitration.... The PBI currently allows for 8 devices and each device can have it's own logical units (just like scsii) Atari allowed for d1 thru d7 in the pbi... but d0 does exist..... d0 was reserved by Atari..... for their own takeover use a card that would always be in the primary slot allowing for the PBI to have a remote device actually be the computer and jam data to the Atari as the keyboard and and still use all the hardware in the Atari... The question I posit is.... will that still be the arrangement.... I know on later machines including the Falcon you assigned a scsii ID to the computer itself, that allowed for more than one computer on the scsii chain.... used in combination with proper software/drivers it allowed for files on the drives and well as access to the other machine on the network, I did this at one point and we still have two scsii differential boxes (by Black Box, not CSS) to extend that network in house... it allowed the network to reach very far... much faster than the network card/serial lan options that existed at the time.... The thought in my mind... one XLR two or three Atari's I may be getting way ahead of things but it is a persistent thought.... it does make for some interesting ideas! If I am reading this right, you are asking about the ability of the 1090XL/1090XLR to become a defacto server. The falcon I believe is a 16bit machine with the horse power to handle some networking and server like functions. I don't believe Atari ever intended nor designed the 1090XL to be connected to more than one computer at a time. The device ids were a preliminary version of the Commodore Amiga and Windows/IBM plug and play ability to avoid bus conflicts. There was some talk and an attempt at an trying to use the Atari as a keyboard terminal for an internal 1090XL Z80 card that never was completed. That might be possible. But as a server? Not likely. I won't say it's impossible, that would be stupid, because there would be someone who would prove me wrong. The 1090XL/1090XLR would have to be radically re-engineered, no telling what software/OS you would have to run on the computers etc, Edited January 14, 2017 by Dropcheck 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 14, 2017 Share Posted January 14, 2017 (edited) using hd driver and icd's pro hard driver it allowed ST/TT/Falcon all to be on the scsi bus... each got an id and the drivers provided file locking but that's.... 16 24 and 32 bit machines... on the 8 bit front there were a few networking options via the sio and parallel fronts. the only widely played with in this particular community was the multiplexer carts by css... the other networking solutions were primarily in schools and certain business centers. so long as the pbi id's can be polled and checked and an id is placed in tabs I should think it would be possible and shouldn't require a radical change at all....... the multiplexer carts could be used as a clue as to how it could implement.... it shouldn't require any real horsepower...... maybe some insight could be had by looking to how puff's multi user bbs ran and how steve carden had the multi node tcpip bbs set up with file locking (sparta and real dos) might be helpful in at least having the bits needed to be present in the xlr..... I even thought about it another way.... device id locking within the interface.... since all the devices already have to get along within the xlr anyway.. I guess the hardware needs to be done before we move on the firmware and software but keeping these things in mind could be helpful Like I said my mind is running with it....... Edited January 14, 2017 by _The Doctor__ 2 Quote Link to comment Share on other sites More sharing options...
+mytek Posted January 14, 2017 Share Posted January 14, 2017 Speaking of ID's, of the existing parallel bus devices, how many of those have unique ID assignments that would allow them to share the PBI? I don't know if any of them were programmed to coexist with other devices on the bus, or provide a means to switch to one of the 8 possible PBI slots. And the BB is definitely not going to be a contender since I believe it will respond to any of them. Is there some way that the 1090 can address this issue? Or are we looking at a firmware change on those existing PBI devices? - Michael Quote Link to comment Share on other sites More sharing options...
+mytek Posted January 14, 2017 Share Posted January 14, 2017 (edited) Based on what we have been talking about, here is what I am proposing to do on my project... Since my project has full support for Stereo Audio, I thought it only made sense to provide the the right channel audio input to the PBI as well as the default left channel input. I'm thinking SD Hard Drive with MP3 playback capability on the PBI Because the 3 'reserved' pins are broken out to 3 independent 3-terminal configuration headers, the USER still has a choice of what they ultimately want those pins to be. The basic choices are provided by simply using pin header jumper blocks, which will allow assignment of the 4 provided signals. For those situations where none of the provided choices are what the USER had in mind, then they are free to use jumper wires to connect any signal of their choosing. - Michael Edited January 14, 2017 by mytekcontrols 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 14, 2017 Share Posted January 14, 2017 (edited) if the audio is less than 1v peek to peek it wouldn't trigger one of those signals correct? maybe using band pass capacitor filtration to keep signal clean? no jumpers needed? or why not go whole hog and put the audio over the existing audio pin on a carrier or dsp since one will prolly already exist on the card.... here is some food for thought... http://elm-chan.org/works/vp/report.html https://www.dsprelated.com/showthread/audiodsp/153-1.php crazy ideas lead places.... Edited January 14, 2017 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 14, 2017 Share Posted January 14, 2017 Most currently available PBI devices are perfectly happy sharing the bus with one another providing all the devices have different PBI device IDs. So U1MB PBI/SIDE should work alongside IDE Plus 2.0, which will work alongside Rapidus, etc (although Rapidus' ID is fixed at 0). There's nothing special about PBI ID 0 AFAIK, and it's the default bus ID of the U1MB PBI. No further action should be required in order to have several devices plugged in at the same time, since a device will only respond when its device select bit is set in $D1FF. Those PBI devices which do not coexist with others are usually hogging more than one device ID or simply failing to observe the device selection protocol. 3 Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted January 14, 2017 Author Share Posted January 14, 2017 (edited) Based on what we have been talking about, here is what I am proposing to do on my project... Since my project has full support for Stereo Audio, I thought it only made sense to provide the the right channel audio input to the PBI as well as the default left channel input. I'm thinking SD Hard Drive with MP3 playback capability on the PBI Because the 3 'reserved' pins are broken out to 3 independent 3-terminal configuration headers, the USER still has a choice of what they ultimately want those pins to be. The basic choices are provided by simply using pin header jumper blocks, which will allow assignment of the 4 provided signals. For those situations where none of the provided choices are what the USER had in mind, then they are free to use jumper wires to connect any signal of their choosing. - Michael Problem with this is that you can't have any other PBI device that uses any of those pins and your board running at the same time. Since by definition you'll make almost constant use of the pins for the audio signal. That forces the user into an either or situation with the 1090XLR or possibly anyone else's PBI. Here's another idea. How about building the SD Hard Drive with MP3 playback as a 1090XLR card with stand alone onboard stereo audio processing to external speakers. In general once a selection or a playlist is made to play, the computer hands off the work to the card which takes care of all processing. That would lessen the CPU load on the computer, keep those pins free for other cards and probably produced a better quality sound. Audio generated by the computer still plays on the computer's own audio circuits to the tv/monitor/stereo system. It also doesn't change or interfere with the existing Stereo boards. It probably means that the SD Hard Drive with MP3 playback may be harder to design, but ultimately will be a better product. Take a look at this link for options: Or here: Edited January 14, 2017 by Dropcheck Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 14, 2017 Share Posted January 14, 2017 Yeah zero was supposed to be special to take over personality etc or do as I stated earlier....that's why Atari reserved it for itself... rapidus and the black box need to be tamed to co-exist on the bus..... the mio seems to play nice although making id's assignable would be nice Quote Link to comment Share on other sites More sharing options...
+mytek Posted January 14, 2017 Share Posted January 14, 2017 (edited) In response to comments made by _The Doctor_ and Dropcheck: Some good points were made. My intention was always to implement the MP3 player aspect with a separate stand-alone processor, since that tech has been available for quite some time and in various forms (just like what was referenced in your links). So playing MP3's would take zero % of the Atari's processing power. The Atari would merely act as a terminal to the MP3 player, and of course would have the option of doing so under program control. So a tiny bit of processing time would need to be spent to do things like select track, move to a certain time within the track, and play when desired. Think of this like the Atari closing switches on a tape deck, not exactly what I would consider taxing to the CPU. Only the Hard Disk aspect would require the Atari's CPU power, and that wouldn't be any worse than many of the existing solutions already out there. Nothing I am proposing here is unique in its independent aspects (MP3 Player or SD Hard Drive), both of these have already been done for the A8 (MP3 player on SIO). It is only the combination of both that is new in the A8 arena (as far as I know). As for making the reserved pins an either or situation, realistically we honestly don't know which, if any of those signals (other than R5) will ever be used. And the chances that all 3 will be implemented on any given user's collection of PBI cards is probably highly unlikely. And as has been stated over and over again, people use CPLD's now days on virtually every new PBI device being made which gives them great flexibility and power to decode virtually any area of memory. To maximize the number of people that will purchase their product means that they will likely not build it for only one denominator, that being the 1090XLR. Instead they will want it to work if at all possible in an unmodified 600/800XL. So that means the $D1xx signal will not be required for a new product plain and simple. Now if whatever is built absolutely requires something like HALT which can't be decoded, then yes it will probably be designed to use it. And as we know there is an existing PBI product that likes to see RD5 on pin 39. So in my way of thinking, the one signal that is expendable will be $D1xx, thus making it a good choice to substitute for the right audio channel. But just in case (because I can't see the future), I gave all 3 reserved pins the option of easily becoming the right audio channel by simply moving a jumper block. Now I'm pretty sure some will will disagree with me on this, but that's OK I feel like I've gotten a lot out of our discussions, and because of that I have been able to design a bus on my upcoming project to be compatible with the 1090XLR (which was my goal). The thing is, I decided to not confine it to that alone and have opted to give the user a choice in what, if anything is assigned to those reserved pins. If the 1090XLR becomes the cats meow and everybody who is anybody has one, then guess what, I have a bus that can be configured to support it --- end of story (there are no PBI police ). Dropcheck I wish you well with the 1090XLR, but unless you choose to go in a different direction with those assignments I consider the PBI aspect finished, and will be moving on to complete other parts of my project (sorry but I really need to complete what I started before I get much grayer in the beard ). - Michael P.S. Just so everyone is clear on this. In my 1088XEL project the AUDin-L and AUDin-R signals are simply audio inputs that get mixed with the stereo Pokey audio outputs and are then sent out through a 3.5 mm audio jack (for external amplification) and/or routed to an internal amplifier and speakers. As such they are independent from the actual computing aspect of the A8, thus requiring none of it's processing time. Edited January 15, 2017 by mytekcontrols Quote Link to comment Share on other sites More sharing options...
Mathy Posted January 15, 2017 Share Posted January 15, 2017 Hello Michael Pin 49 isn't "Audio Left" at the moment, it's "Audio Left plus Audio Right". Mono always is "Audio Left plus Audio Right". If you are gonna put a second "Audio In" on the bus, you might consider making that "Audio Left minus Audio Right". This would make it easier to separate into "Audio Left" and "Audio Right". Adding both signals ("Audio Left plus Audio Right" and "Audio Left minus Audio Right") together would give us "Audio Left", subtracting both signals from each other would get you "Audio Right'. Using "Audio Left plus Audio Right" (instead of only "Audio Left") on pin 49 (and "Audio Left minus Audio Right" on that other audio pin) would mean you still have both the Left and Right signal in your mono signal. So people with just one audio pin on the PBI would still hear the complete mono sound instead of only half the stereo sound. Sincerely Mathy Quote Link to comment Share on other sites More sharing options...
Mathy Posted January 15, 2017 Share Posted January 15, 2017 Hello guys If you really want to hear music in CD quality, use the Atari to control which song is played but don't want your hard drive to be wanting to much attention, why not hook a SCSI CD or DVD player to you BlackBox. Here's how it's done. Sincerely Mathy Quote Link to comment Share on other sites More sharing options...
+mytek Posted January 15, 2017 Share Posted January 15, 2017 Hello Michael Pin 49 isn't "Audio Left" at the moment, it's "Audio Left plus Audio Right". Mono always is "Audio Left plus Audio Right". If you are gonna put a second "Audio In" on the bus, you might consider making that "Audio Left minus Audio Right". This would make it easier to separate into "Audio Left" and "Audio Right". Adding both signals ("Audio Left plus Audio Right" and "Audio Left minus Audio Right") together would give us "Audio Left", subtracting both signals from each other would get you "Audio Right'. Using "Audio Left plus Audio Right" (instead of only "Audio Left") on pin 49 (and "Audio Left minus Audio Right" on that other audio pin) would mean you still have both the Left and Right signal in your mono signal. So people with just one audio pin on the PBI would still hear the complete mono sound instead of only half the stereo sound. Sincerely Mathy My project has full stereo support for both Pokey and external audio inputs. It's a similar circuit to what I did on the TK-II-STEREO board, but also includes audio mixing of the externally provided audio inputs as well. So although the PBI pin-49 was originally aimed at providing a 'mono' audio input from the PBI device, I will also be placing a second audio input on the bus (the right channel), so pin-49 now becomes my left audio input. Just keep in mind that there is nothing set in stone that says that has to be a mono signal. Of course for PBI devices that do produce only a mono output, that pin will still work and if you want to hear over both left and right speakers then the audio support in my project can easily be switched into mono mode and 'Y' that signal to both channels. I don't want to side track this thread too much, so I'll be starting a separate topic in a couple of weeks about the 1088XEL project, and I'll post schematics that should make this a bit clearer. - Michael 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 15, 2017 Share Posted January 15, 2017 I'm just saying there are ways to send stereo sound on a single pin.... or to double up in pins depending on frequency, or amplitude. I hope the ideas are helpful.... few solid ways to do so. I love the idea your attempting to implement.... happyface Quote Link to comment Share on other sites More sharing options...
+mytek Posted January 15, 2017 Share Posted January 15, 2017 I'm just saying there are ways to send stereo sound on a single pin.... or to double up in pins depending on frequency, or amplitude. I hope the ideas are helpful.... few solid ways to do so. I love the idea your attempting to implement.... happyface OK I'll bite. How would you send 'analog' stereo sound over a single pin without resorting to some complicated conversion/extraction process? - Michael Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted January 15, 2017 Author Share Posted January 15, 2017 In response to comments made by _The Doctor_ and Dropcheck: Some good points were made. My intention was always to implement the MP3 player aspect with a separate stand-alone processor, since that tech has been available for quite some time and in various forms (just like what was referenced in your links). So playing MP3's would take zero % of the Atari's processing power. The Atari would merely act as a terminal to the MP3 player, and of course would have the option of doing so under program control. So a tiny bit of processing time would need to be spent to do things like select track, move to a certain time within the track, and play when desired. Think of this like the Atari closing switches on a tape deck, not exactly what I would consider taxing to the CPU. Only the Hard Disk aspect would require the Atari's CPU power, and that wouldn't be any worse than many of the existing solutions already out there. Nothing I am proposing here is unique in its independent aspects (MP3 Player or SD Hard Drive), both of these have already been done for the A8 (MP3 player on SIO). It is only the combination of both that is new in the A8 arena (as far as I know). As for making the reserved pins an either or situation, realistically we honestly don't know which, if any of those signals (other than R5) will ever be used. And the chances that all 3 will be implemented on any given user's collection of PBI cards is probably highly unlikely. And as has been stated over and over again, people use CPLD's now days on virtually every new PBI device being made which gives them great flexibility and power to decode virtually any area of memory. To maximize the number of people that will purchase their product means that they will likely not build it for only one denominator, that being the 1090XLR. Instead they will want it to work if at all possible in an unmodified 600/800XL. So that means the $D1xx signal will not be required for a new product plain and simple. Now if whatever is built absolutely requires something like HALT which can't be decoded, then yes it will probably be designed to use it. And as we know there is an existing PBI product that likes to see RD5 on pin 39. So in my way of thinking, the one signal that is expendable will be $D1xx, thus making it a good choice to substitute for the right audio channel. But just in case (because I can't see the future), I gave all 3 reserved pins the option of easily becoming the right audio channel by simply moving a jumper block. Now I'm pretty sure some will will disagree with me on this, but that's OK I feel like I've gotten a lot out of our discussions, and because of that I have been able to design a bus on my upcoming project to be compatible with the 1090XLR (which was my goal). The thing is, I decided to not confine it to that alone and have opted to give the user a choice in what, if anything is assigned to those reserved pins. If the 1090XLR becomes the cats meow and everybody who is anybody has one, then guess what, I have a bus that can be configured to support it --- end of story (there are no PBI police ). Dropcheck I wish you well with the 1090XLR, but unless you choose to go in a different direction with those assignments I consider the PBI aspect finished, and will be moving on to complete other parts of my project (sorry but I really need to complete what I started before I get much grayer in the beard ). - Michael P.S. Just so everyone is clear on this. In my 1088XEL project the AUDin-L and AUDin-R signals are simply audio inputs that get mixed with the stereo Pokey audio outputs and are then sent out through a 3.5 mm audio jack (for external amplification) and/or routed to an internal amplifier and speakers. As such they are independent from the actual computing aspect of the A8, thus requiring none of it's processing time. Okay I'm going to vent. Understand I am civil in making these points. I am not screaming or jumping up and down. You obviously are going to do whatever you chose to do. It's really amazing how circular logic is used to justify a decision. We just decided to standardize four signals on four unused pins of the 600XL/800XL PBI and 130XE ECI. How can we know how many PBI devices will be made that use any or all of those pins when it's only been a couple days? And to use that uncertainty to justify going back on that agreement is nuts. Because you don't know. How does a 130XE use your device? It only has 1 pin in reserve. I assume you plan to co-opt that pin as well. How about pass thrus for other devices? Is the user going to be able to use their existing PBI devices or use new ones. I would think that only standard devices would co-exist with yours once the user modifies his/her bus. But okay....... If wizzbang things can be done with CPLD programing and your plan is to use a stand alone processor and the Atari as simply a selection terminal for playlists, why are you even involving the Atari audio circuits at all. That makes no sense. Any use of the Atari/Pokey audio circuit is going to consume processing power since the Atari is a one process cpu and operating system. You are either using a VBI to monitor and control or an Atari based MP3 player program as your process, either of which consumes Antic/Pokey/CPU cycles. Are you really creating a true PBI device? A true PBI device has to have a 2K rom device handler setup to tell the Atari how to communicate with it. Or are you actually doing an external audio mixer that just happens to hang off the PBI bus for signal access? But okay..... If I understand your statement, you want to run stereo audio into the computer, somehow mix it with the stereo Pokey outputs and then feed the combined audio signal back out of the computer to some external sound producing device. Huhhhh? If you are assuming an existing Stereo Pokey mod already internal to the computer, most mods I've bought and installed already have L/R Audio output jack connections that can feed stereo audio out via an external cable to the PBI device. Once in the PBI device you can mix the audio with other audio generated by your PBI device and output from there to external speakers. Even your TK-II Stereo Board has an audio output jack. There's no need to use any pins for an extra audio channel on the PBI bus. You don't even have to use the 1090XLR, a standard PBI interface would work in that case. But okay..... You are forcing the user to modify their computer bus to use your PBI device, but that mod is only good for your device. It provides no value to any other PBI device that isn't an audio device or your device. The HALT, D1XX and RD5 signals are relatively generic and can be used by nearly any device on the bus. I've already advised since only the 600XL/1064XL uses the CAS and RAS pins that they could be re-purposed for other signals if needed. You rejected that. By the way the internal bus pin out on the 1090XL/1090XLR is not nor can it be a pin for pin match to either the PBI or ECI bus. There will be additional signals and power feeds present. So no your bus is not compatible with the 1090XL internally or the 1090XLR either externally or internally. But okay.... Yes, it's true, I am upset. I was under the impression that you wanted to help redefine the ECI/PBI standard so that both busses would have common existing signals from each on them to allow easier new PBI device development and prevent further incompatibilities between computer models. Instead you add a completely new and I feel unnecessary signal to the PBI bus for your device only, making a second known non-standard PBI device. Exactly what I was trying to prevent. But okay..... My bad. I wish you well. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 15, 2017 Share Posted January 15, 2017 (edited) it would be more complex than a wire that's for sure.... and I kind of get the feeling that's not what we are after.... it would require an encode and decode just like in a television or radio....or cable tv system for that matter OR a cheap DSP/DAC solution...... but I'm probably confused about the direction.. tons of ideas out there like choosing a line that gets asserted or used very little keeping the vp-p below it's below transition thresholds and use a capacitor filter on the audio to keep the digital noise or pop out of the audio side.....none of it perfect I guess... I did write up a wonderfully researched and not to be done again set a paragraphs and then touched the mouse pad and blammo firefox closed the tab and my work went away. There are a number of sites and discussions on this sort of thing by experts well beyond my abilities.. I can only ask that they be read considered and maybe conversed with about a solution..... could just go wireless.... I have an mp3 player that takes a usb stick plugs into 12v, it puts out on whatever station I choose... and for about 2 bucks I bought a Chinese fm radio with earbud tiny as could be... jacked the earbud line into an amp... sounded just fine. I don't have a firm grasp on what this is now, don't think Dropcheck does either. If the computer is already outfitted with a stereo solution it's already got jacks out... if the stereo solution is to be in the box. the the audio would have to leave the computer to mix with the external pokey on the pbi bus to be jacked out in stereo. this looks like a two parter... A new computer that wants to join in on the pbi standard.... A new PBI card with external pokey and mp3 to work alongside said computers? re reading.... sound device on pbi bus, analog stereo thru the bus to computer... picked off the bus and sent to combine with the audio out of dual pokey to a 3.5 mm jack... in any event here's some multiplexing (muxing) and modulation to consider https://en.wikipedia.org/wiki/Multiplexing and some analog mux parts... http://www.jameco.com/shop/keyword=audio-multiplexer-ic http://www.mouser.com/Search/Refine.aspx?Keyword=74HC4052 for reference https://www.sparkfun.com/products/retired/9907 it think that covers it... http://coolcapengineer.wordpress.com/2013/01/04/electronics-serial-expansion-using-74hc4052/ so put one on each end, choose the appropriate direction the out on one to the in on the other.... and it's cheap! Edited January 15, 2017 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
+mytek Posted January 15, 2017 Share Posted January 15, 2017 Using something like the 4052 chip you referenced on both sides of the single wire would require an analog time division multiplexing scheme. Which means using a synchronized time base on both ends to continuously step through the mux/demux addressing, and also a sample and hold amp clocked by the same time base on the receiving end. Problem is that without another free signal wire, it quickly becomes problematic to sync the two ends together because you would need to reconstruct the clock circuit somehow on the receiving end, and have it be in-sync with the transmitting end. Not sure what all would be required to do this, but it's beginning to sound much more complex and expensive than simply dropping in two 4052's. The other methods such as a modulation/demodulation system similar to what is used for FM stereo also gets very tricky and likely expensive to do. But perhaps there are some inexpensive specialized chip pairs that can do this. Does anyone know of some? If there is a cheap (and small, as in single chip) solution for this I would love to use it and am all ears. - Michael Quote Link to comment Share on other sites More sharing options...
+mytek Posted January 15, 2017 Share Posted January 15, 2017 (edited) Dropcheck my intentions were always to include a standard XL PBI in my project, never did I say that I would also be including an XE ECI connection as well, other than perhaps adding some of those signals to the unused pins of the XL PBI. That last part is key. So instead of willy nilly just picking a few signals and assigning them, I thought why not do so in concert with what you want to do in the 1090XLR, so that at least from an 'XL' viewpoint we are the same. Since Atari had already established the +5 V usage of two of the reserved pins in the 600XL, this left us with 3 free pins. With only those 3 pins in contention, we came to an agreement on assignments. And I have honored that agreement in my proposed PBI implementation. Since my project is not a commercial offering, and never will be, I also reserved the right to add additional options to the usage of those reserved pins (besides the possible audio channel reassignment, they are open ended in nature, allowing for any usage or none). The 1088XEL as I am calling it for now, is going to be at best a DIY offering. However due to the complexity and cost I don't anticipate many people undertaking this venture. Which is OK, since everything I do related to the Atari is a hobby that I just so happen to share with the community. But since it is 'my' hobby project which is never a financial gain, and always a financial drain to my wallet, I do believe that gives me free rein to do whatever I please with it. If that offends or upsets someone, that is on them, not me. Although be assured it is never my intention to do so. As I said in an earlier post, my parallel bus interface can be configured to support the agreed upon reassignments to those reserved pins. I am sorry if that doesn't satisfy you and has made you mad, but it is what it is. As for the audio aspect, it is clear to me that we are thinking in different terms, and have a simple misunderstanding of what and how it will be used. This probably won't get any clearer through talk alone, so I suggest you wait until I have had a chance to post schematics before debating more about it. BTW, I only gave the SD Hard Disk/MP3 Player PBI device out as a possible example of needing a second audio input on the bus. I never said I would actually produce such a device. - Michael Edited January 15, 2017 by mytekcontrols Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 15, 2017 Share Posted January 15, 2017 (edited) since we're on the theoretical, could we use the clock on the bus and multiply it to a usable frequency for the pair? they would be sharing the same clock and would code/decode at the same fixed rate.... it could be interesting to play with and who knows what unused portions exists on other chips in whatever the device is being cooked up... there are other chips but I chose that one because plenty have played with them and the later uses included digital implementations as well, looking a few years back you're likely to find some very simple uses all the way to... let's see what this little chip can do crazy stuff.... It was rattling around in my head I know we used them in some projects many years ago....and it wasn't at all difficult or pricey to do.... like so many things it took forever to get it from the fog of my distant memory to light... so for my part I apologize for taking so long to get my grey matter to move on it... and likely longer to remember what we did... looks like there are better options for slightly more money these days... all pretty much built in 1 wire solutions..... in any event neat stuff to delve back into but I'm just playing about now btw they lie.... I mean 1 wire active 1 wire ground that's two but ground already exist still.... amazing bidirectional wonder the more you want the pricier they can be! Edited January 15, 2017 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.