Jump to content


To infinity and beyond... (new hardware)

59 replies to this topic

#51 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 159 posts
  • Location:San Jose, CA

Posted Fri May 4, 2018 10:40 AM

Cartridge support


So it would be really nice to have a cartridge slot on the expansion box, as a convenient place to plug things into when your device is a 1088XEL and I've taken up the cartridge slot with the expansion bus... This does however have some issues.


The original design was to make all data-access local to the 6502 bus. That's why there's an SDRAM there - to provide plenty of buffering RAM for the peripherals to use. The basic idea for how a peripheral would communicate with the host machine is:


  • Let's say we have a MIDI card that receives and sends data and wants to communicate with the host computer when it does so.
  • On boot, the peripheral sets up an IRQ handler in its own section of the SDRAM, and any routines sending data. These will be mapped into a standard location when the IRQ is triggered or when the send-data routine is called
  • {midi data arrives}, the peripheral transmits the data over the link to the SDRAM, and then triggers an interrupt. The data is already in local SDRAM before the interrupt happens
  • {send-data}, the 6502 copies to a local buffer (in SDRAM over the bus) and then calls a TRAP routine (essentially a software interrupt, so set up a few "registers" in SDRAM memory, and tell XMOS to transfer data).

The important thing is that at no time is the 6502 talking directly to the peripheral. That's a "long path" for the data to go:

  • ​6502 writes address/control lines
  • XMOS [local] picks up address after 177ns
  • XMOS [local] transmits address/control lines over the link
  • XMOS [remote] receives the {address,control} packet
  • XMOS [remote] pushes signals out to peripheral
  • peripheral gets data (say a read-request) and pushes data out to its data-bus
  • XMOS [remote] gets the data off the local data-bus
  • XMOS [remote] packages data up and sends it over the link
  • XMOS [local] gets package and pushes data onto the 6502's data bus

The timing budget is given by




... which leaves me with (558-177)ns of time to do all the above. If *everything* synchronises up just perfectly, I think it's just-about do-able, but it's going to be very very tight if it's even possible. So, what else could we do ?



Option 1: De-serialise


I could ditch the serialisation approach and just transfer data over a parallel bus. There are 41 distinct signals (including GND and +5V) on the ECI. The simplest approach might be a 2x21 ribbon cable, but these are pretty bulky at ~6cm for the connector assembly, so would take up a lot of real-estate on the back-panel of an H80 case. The next simplest way of doing it would be to double-data-rate the signal and use an HD26 cable and sockets; these would take up 4cm x 1.2cm on the back panel. We're still only talking a data-rate of ~3.6MHz for this, so there's no need for differential drivers or even twisted pairs. If it came to it, we could use SCSI-2 cabling, although the only reliable source of cables I can find are the 50-way ones, which have sockets larger than the HD26 above, at 52mm long, although with 50 wires, there's no need for data-doubling, which might be worth it.


A major benefit is that it would make the electronics a lot simpler, and it still provides a single cable to the expansion box, even if it's a lot less flexible :)



Option 2: Emulate


There's a lot of work been done to identify cartridge types and how any individual banking has been done on those cartridges. I could leverage that, and (on boot) copy all the contents of the cartridge up to local SDRAM (banking as necessary to get all the data), then the cartridge could be emulated by the local XMOS. In this way, we're more in line with the original design. 


This does have some drawbacks though - there's no way that hardware cartridges (eg: USB, SIDEx, etc.) could be made to work. The hope would be that such functionality would be taken care of by the box itself, but it's still a barrier that I'd rather not have.



Anyway, food for thought. Is fully supporting a remote cartridge port worth a re-design...



#52 Dropcheck OFFLINE  



  • 1,211 posts
  • Location:Stigler, OK

Posted Sun May 6, 2018 7:15 AM

I don't think that as long as the user has the primary cartridge port fully available for use it is .  I make a dual switchable RA cartridge extension board.  ;-)

#53 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 159 posts
  • Location:San Jose, CA

Posted Sun May 6, 2018 4:53 PM

Well, it would simplify the interface a lot. It reduces the 'XE interface' part down to a few buffer chips and a transceiver for the D[7:0] lines.  


I was opposed to the idea originally because I didn't want to have a ribbon cable coming out the back, but having looked around, there's a VHDCI standard which would give 68 pins and it still has a round (if stiff) cable coming out the back. The price of 2 connectors and a 16" cable would be ~$37, which is about the price of my BOM for the interface card, in other words it's a wash.


On the positive side, 


  • I can pipe the audio line through, so the expansion box can source/sink audio as well. That wasn't going to be possible on the purely-digital approach. Not a huge win, but a win nonetheless.
  • I have 68 pins and I need 40 for the system-bus, so I can put the SIO signals on there as well. Then people can design either SIO or parallel-bus expansion cards. That's actually a pretty big win.
  • It means I can just have a single firmware change for the cross-platform aspect rather than two chips. Simplifying that is a major win, in my experience. Anything users might have to update is best made as easy as possible.
  • From a technical standpoint, there's no possibility of the two sides of the link being out of sync - it would have been possible for the interface board with the SDRAM on it to be plugged in and working, but not connected to the expansion box. The firmware on both would have to manage hot plugging (or at least graceful failure).
  • Different hardware configurations are easier to support - no need for a 4-layer PCB and software control, just route the wires from the edge-connector to the correct pins of the VHDCI connector, and you're done. The XL (with its PBI) and any non-atari boxes just got a lot easier.
  • It *is* a simpler system, I'm generally a fan of the KISS principle...

I'm snowed under with work right now (I have a demo to give on Tuesday) but I've ordered a VHDCI cable and connectors. I'll rig it up and see what the signal integrity is like across the bus, and we'll go from there.


I'm envisioning 2 internal PCB's, in the configuration {card-edge interface}<---ribbon-cable--->{VHDCI interface} which ought to allow it to be placed anywhere on the back-panel of either a stock XE/XL or in the mini-itx case of your choice.


The first PCB would have the XE card-edge interface, line buffers/transceiver, and connections for ribbon cables of the following:

  • ​2x34-way to the VHDCI connector PCB
  • 2x5-way for each joystick port [7 pins used] because why not {1088XEL-specific}
  • 1x7-way for the SIO interface [5 pins used] {1088XEL-specific}

There are 41 pins used for the system bus, so I have 8 currently 'spare'. I won't be running power across the link, but I can always use them as multiple grounds if there's no better use for them. I'll have to look at the C64 bus to see if there's any special requirements there as well.


The second PCB  would be the ribbon-cable-to-VHDCI connector. The VHDCI connector is a straddle-type, and I *think* the connector above would be panel-mountable such that it can be screwed to the back of the panel with some M2 hex standoffs, and then the VHDCI cable screw into the standoff.


Both of these PCB's can be 2-layer and they're simple designs with a short ribbon cable to connect them. Then there's the VHDCI cable to the expansion box, another VHDCI connector, and you're on the expansion box itself. 


[edit] The Monoprice cable turned up today, and it's a lot more flexible than I'd been expecting - I was thinking it was going to be like the SCSI cables of old on the ST, but it's way more bend-able than those were. I'd say it was slightly more flexible than a DVI cable, if that helps :) The connector's nice and small, I think we have a winner.

#54 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 159 posts
  • Location:San Jose, CA

Posted Wed May 9, 2018 10:02 AM

Thanks for the memory
One of the things I want to explore with the system is memory management. The 8-bit machines have a 64k limit on memory address ranges, and having 32MB of SDRAM attached means we have a lot of playground to play in

[aside: just to be clear, I'm not suggesting multiple types of memory descriptor here, I'm leading through the thought process, starting from the simplest form to the final type that will actually be implemented - sorry for any confusion :)]

The basics:

The obvious first step is to allow access to a range of memory. This will be possible using a memory-descriptor that the 8-bit can fill in, and subsequent memory accesses within the range of that descriptor will be fulfilled by the SDRAM instead of the on-board SRAM.

Memory will be made available on a page-by-page basis (ie: any contiguous available set of pages in the 8-bit memory space will be mappable from SDRAM). There are memory ranges which the external bus can't override, but in general it will be possible to source any normally-accessible RAM address from the SDRAM. The memory descriptor will have:
  • a four-byte source-address range (expressed in bytes),
  • a one-byte destination address range, expressed in pages.
  • a one-byte size, expressed in pages
This means that by modifying just one register in the source address, everything can shift by up to 256 bytes, and it takes changing a maximum of 4 registers to remap the pages to any location in SDRAM. All well and good, this is a simple linear memory mapping.

Graphics uses:

Now that we have a basic aperture-of-memory available, we can try some more things - we can add a 'stride' to the memory descriptor, which defines the length of a horizontal line in the backing memory. Consider setting up a memory-descriptor structure like

$+0000 [4]: Base address in SDRAM for start of memory aperture
$+0004 [1]: Page address in host-memory for start of memory aperture
$+0005 [1]: Number of pages to map
$+0006 [1]: 'stride', or pages per horizontal line
$+0007 [2]: width in bytes of each virtual line

Now, whenever an address is requested within the aperture of {page address + size} pages, the actual byte returned is discovered by using:

X    = (address - base * 256) % width   // % is the traditional 'C' modulus operator
Y    = (address - base * 256) / width
byte = base * 256 + Y * stride * 256 + X

The stride and width allow us to specify a longer virtual horizontal length than the physical linear map would allow - but yet we can map this into a linear space in host RAM. Again, moving everything left or right by a byte is a matter of changing the base address, by 1 and moving everything up or down by a line is a matter of changing the base address by 'stride * 256' bytes.

This is similar to how Antic can have longer lines in memory and then update display-list LMS values rather than copy data to effect a visual change.


So one other point is that there is 32 Megabytes of SDRAM available. That's an enormous amount of space, and even when you start taking chunks of it for each peripheral and giving them dedicated i/o space, you're still left with at least 31 Megabytes of space, or 496x the entire address space of a 6502. Clearly there ought to be services available for the use of this memory.

One thing we can exploit is that the memory is dissociated from the host computer's bus. Sure, the host has read/write access to a section at a time, and it's probably worth staying away from that while it's mapped into host space, but the rest doesn't have to be static.

Consider allocating a 2k memory-mapping into host space that extends for 512k of SDRAM, and just update the memory-descriptor to "scroll" through that mapping by bumping the memory descriptor by 512 bytes every VBLANK - that's just a few register changes.

Why do I choose those values ? Well,this thread here at AtariAge uses some clever coding to produce simply stunning 8-bit pulse-density-modulated audio from an Atari XL at 44.1kHz. The audio itself will take a lot of storage, obviously, and at 44.1kHz and 50Hz Vblank, 882 bytes are consumed every 1/50th of a second (it's similar for 60Hz NTSC, 745/second there). That means it ought to be possible to store the PCM audio in SDRAM, and pretend to have a linear buffer in host-ram that extends for the size of the audio in SDRAM, with judicious pointer/memory-descriptor manipulation on every VBLANK.

All well and good.

Now let's say, when we get to the point 256k into the 512k section, we ask for two things to happen

1. Memory Blit: we copy the last 2k of the 512k to the start of the 512k section. This gives us a buffer that means we can switch pointers and nothing has appeared to happen, but we're now in the first half of the memory buffer, not at the tail end.

2. Memory Fill: we request that the SD card copy from file /path/to/somefile.ext on the SD card to {memory-descriptor base + 2k}, with a length of {254k}, and an offset of {x}, where x increases by 254k every time we call the copy op.

The blit allows us to switch pointers at any point in the last 2k, to point to the same offset in that 2k, but now at the start of the buffer, making for a seamless transition, the read (which will happen in the background, the host computer being blissfully unaware apart from a status byte) will mean the next section of the song is now available once it finishes.

Keep ping-ponging between the two halves of the memory-descriptor, reading into one half while we play audio from the other, and we can play literally gigabytes of PCM audio on an 8-bit computer.


I'm envisioning the 'blit' operation as taking two memory descriptors and copying the contents of the first into the second. In the basic form, it's just a memory copy, but blits could also have operations associated, allowing masks and effectively getting software sprites. Given the memory-freedom, handling horizontal shifts of less than 1 pixel could be done by having multiple pre-shifted sprites and large enough backing defined in the memory-descriptors. In this case the memory descriptor starts to look like:
$+0000 [4]: Base address in SDRAM for start of memory aperture
$+0004 [1]: Page address in host-memory for start of memory aperture
$+0005 [1]: Number of pages to map
$+0006 [1]: 'stride', or pages per horizontal line
$+0007 [2]: X position in bytes within the defined descriptor range
$+0009 [2]: Y position in lines within the defined descriptor range
$+000B [2]: W position in bytes within the defined descriptor range
$+000D [2]: H position in lines within the defined descriptor range

... which fits nicely into 16 bytes with one left over for future expansion. Dedicate a page to descriptors, and you have 15 distinct blits that can be called using the software TRAP-style call {routine, descriptor-1-id, descriptor-2-id, operation} from the host to the XMOS chip. Obviously one of those descriptors will be the screen memory if you're blitting to screen-RAM, thus reducing the total down to 15. There's no reason those can't be re-used, of course...

I'm sure there'll be more services (JPEG decode, MP3 decode, ?) given that we have a CPU attached to the SDRAM, and can exploit that independently of the 8-bit host, but these are the fundamental ones that come to mind that will allow 8-bits to explore a lot more memory than they would otherwise be restricted to.

#55 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 159 posts
  • Location:San Jose, CA

Posted Thu May 10, 2018 5:33 PM

So things will probably get a little quieter, as I build up the re-design. There's a fair amount of stuff I can re-use, but there's a fair amount of new things as well, so it might take a little while... I also want to play with the card that I have, and code up some software on the XMOS to implement the behaviour of the expected new card - given that it's going to effectively plug into the bus, the "i/o" card I already have is actually a pretty good test-bed. At the very least, it'll let me validate some of the approach.

The new design will use a larger XMOS part - there are 4 tiles on this chip, each of which is effectively its own CPU, with its own RAM and other resources. The pins are mapped as below, which'll give you an idea of where it's headed...

xmos-tiles-0-and-1.png . xmos-tiles-2-and-3.png

Pins are listed down the side, ports are across the top, with the colours identifying the range of the port to be used for any given function. In summary, the tiles are structured as:

Tile 0: USB, SD-card, Debug, UART x2, XTAG-link
Tile 1: VHCI interface, peripheral i/o
Tile 2: SDRAM, SPI, peripheral i/o
Tile 3: Gigabit ethernet, I2C

At this point I'm pretty much committing myself to an external case as well - I'll either 3D print it at low volume, or if we drum up enough support, get a case made as detailed earlier. I've surrendered to the inevitable and ordered an H80 case to join y'all :)

With that in mind, the expansion main-board will offer a base set of expansion possibilities, and then the slots will allow anyone to do anything they want. At this point, I'm intending the slots to carry:
  • All bus signals @ native voltage
  • All SIO signals @ native voltage
  • All Joystick signals @ native voltage
  • An address stable signal from the XMOS @ 3.3v
  • A 3-bit peripheral-select output from the XMOS @ 3.3v
  • An 8-bit peripheral-wants-attention input to the XMOS @ 3.3v
  • An 8-bit data, 2-bit control input bus from peripherals to the XMOS @ 3.3v
  • An 8-bit data, 2-bit control output bus to peripherals from the XMOS @ 3.3v
... on a physical form-factor of PCIex16 slots, which have plenty of pins and more besides. Native voltage signals will be directly wired to the bus, so cards that want to use them will have to cope with the voltages themselves. Any cards content to interact via the peripheral-i/o bus can use 3.3v (in fact, must, since the XMOS is not 5v tolerant).

In addition, the expansion box motherboard will provide:

- 2x high-speed (anything up to 10 Mbit/sec) serial ports. More than the host computer can source/sink, anyway :)
- A USB-host interface
- A gigabit ethernet interface.
- An OLED display on the front (SPI-based)
- An SD-card interface (probably full-size).

I'm planning on putting these standard peripherals on the left or right hand rear side of the case, with the slots being rear-facing, that way I can put the motherboard against 2 sides and not have to fill the entire base of the unit. There are going to be SPI and I2C busses coming out of the XMOS, so there may be more things as I think of them. For now, thats 'it' :)

#56 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 159 posts
  • Location:San Jose, CA

Posted Wed May 16, 2018 9:30 AM

Speccing out the parallel connector

So I'm in the process of testing out the parallel bus interface to make sure the 1.79MHz bus speed will be successfully transmitted over the VHDCI cable, and figured I might as well make the PCB something we can actually use in the future - to this end it will serve a dual purpose.

  • If plugged into the back of an XE, it'll be a simple conduit (via buffering) to the VHDCI cable which will plug in the back. The goal is to keep the interface short here, so there's the minimum of space used at the back of the XE. I don't have a good way to get Joystick, or SIO connections to this PCB in this configuration (Lotharek has SIO plugs for ~$8, but I don't know where I'd get a socket to provide the onward daisy-chain)


  • If plugged into a 1088XEL, it will act as the aggregator of the {bus, joystick, SIO} connections, and feed them all to a 2x34 way ribbon cable, that in turn has a PCB that takes the ribbon cable and maps the signals 1:1 onto a VHDCI cable connector. This lets me have a tiny PCB that (because of the VHDCI connector mounting screws) is panel-mountable, and allows a lot of flexibility with placement.


With that in mind, I started figuring out which signals need buffering, which ones are bi-directional etc. If those-in-the-know could take a gander at the below, I'd appreciate it. I think I have them all in the correct buckets, but the more eyes the better...






#57 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 159 posts
  • Location:San Jose, CA

Posted Fri May 18, 2018 9:39 AM

Quick update
I'm ankle-deep in the re-design, and it's already undergone some fairly major changes to the above because I discovered that the XMOS USB library was device-only. I'd like to (eventually) support USB keyboards and mice which means the chip has to support host (or on-the-go) mode, so that was a bit of a deal-breaker. To be clear: I'm not saying this is all going to be there on day-1, but I want to make sure I remove as many barriers as possible to any future development, during the design phase. Anyway, for the same cost of the larger XMOS chip, I can get a smaller XMOS + an ARM M7 which has built-in USB (host, device, and OTG). I've re-jigged a few things on the XMOS side to account for the smaller chip ...


It occurs to me that this sheet may need some explaining - basically XMOS chips have fixed ports, of different widths (1,4,8,16,32-bit) which overlap the pins. All the pins on any given port have to be either read or write, you can't mix. That means there's an extra level of planning to make sure that each port is doing what you want. In this revision of the design, I've accounted for any future-needs for different hardware support by adding in 4 more bits of read-port from the VHDCI cable, and 4 more bits of write-port. If and when I get around to doing the (example: C64) version, the wiring from VHDCI to XMOS will remain fixed, but the signals will be specific to the hardware it's connected to, because of course I can flash a C64-specific image to the XMOS and the interface cable on the host side defines the wiring loom layout. As long as I match address-bus to address-bus, data-bus to data-bus, and common control signals to the same, it'll be all well and good.

Given that there is reduced functionality on the XMOS side, we now also have:


This is basically the expansion box motherboard host. It handles the peripheral-slot i/o (relaying to the XMOS for transmission back to the host) and also handles the motherboard-supplied peripherals (10/100 ethernet, full-speed (12Mbit/sec) usb, 2x serial (up to 27 Mbit/sec), SD card) and an experiment in video. You can see I've used up every pin available...

Hang on, what was that last thing ? Video ? Well, it occurred to me way back when I started this, that given access to every byte transferred over the bus by CPU and ANTIC, it ought to be possible to build a display just like ANTIC does. You'd need to understand the video-subsystem of the host, and you'd need to be able to produce a video signal. I'd already tried shoe-horning it into the XMOS, but with each core running at only 100 MHz, it was getting pretty tight without using too many resources. With the two chips now available, one of which has video-generation hardware, I have a bit more leeway so I could re-visit... Here's the plan:

  • You need to be able to interpret the bus activity on the fly. Pokey interrupts and DLIs can change the colour registers as the screen is being drawn, can move around players and missiles, and can instigate horizontal scrolling etc. There's a lot to support there.
  • Fortunately we have the XMOS monitoring every bus transaction, and I've included a dedicated video-bus to the STM32F7. I'll dedicate a core on the XMOS to understanding the video-layout of the host, and when ANTIC reads data (/HALT goes low), or when the display list vector is read, or when the display-list itself is read, or when a colour register is changed, or... that core will send a packet over the video-bus.
  • The STM32F7 will get an interrupt (its interrupt latency when running from ITCM memory is 12 clock cycles at 216 MHz) as the packet on the video bus is sent and it will process the packet as needed. The video-bus interrupt request line is the highest-priority ones so it ought to be able to respond quickly. The STM32F7 actually has a reasonable amount of time to respond, even if ANTIC is fetching back-to-back data (which it mainly doesn't), the bus-cycle is only 1.79 MHz, and the STM is running 120x faster than that).
  • The current plan calls for a double-buffered display (ie: I'll be writing to the framebuffer that will be displayed *next*), which puts me a frame behind the host computer (since it's generating the video signal on the fly). I'm not sure if that will be a deal-breaker. Maybe for some. It may be possible to write to the active framebuffer, but you're racing the beam and I'm not sure what that would look like. If I fall behind the beam, the data won't be displayed... If I subsequently catch up, the screen would start to draw again. It might be weird.
  • I'm currently planning on providing output via HDMI using an ADV7511 - the LCD interface on the STM32F7 provides 24-bit RGB, /HSync, /VSync, CLK and /DE signals, which is a good match for the ADV7511 inputs.
  • The ADV7511 can take digital audio, and encode that into the HDMI signal. There are 3 ADC's, I'll connect the SIO audio line to one via a 5v->3.3v scaling circuit, and we can have audio too (I'm assuming the audio is bi-directional, ie: it's not just the input from SIO, but also the output from the XL). There's also the (stereo!) audio output on the 1088XEL, but I'm not sure how to convert a +/- 0.4v signal into something that oscillates between 0 and 3.3v without corrupting the signal. I'll ask around the EE-types at work, or if y'all have any ideas, feel free to chime in. In any event, those signals will be connected to another 2 ADC inputs via the magic black box that will scale/offset them :)

Of course, it doesn't stop there. Once we can support standard atari video modes we can look at expanding it; since I'm using 16-bit access to SDRAM, according to ST 640x480 ought to be reachable in 24-bit colour, and 800x600 in 16-bit colour. If we use an indexed mode (256 colour registers) it could go as high as 1920 x 1080 (!) Coming back down to earth, it does support 320x240 as well, so mapping the existing atari modes to the output ought to be possible without playing tricks by plotting 4 pixels for each one.
One last note on video. It occurs to me that since I'll be writing to a frame-buffer, it ought to be possible to enable the pal-blending style of APAC-style modes. It would probably have to be software-enabled (flip a bit in a "register") or you'd see sharp colours on one scan-line followed by sharp greyscale on the next, but that could be one advantage of *not* racing the beam. It's also worth mentioning that in emulation on my Mac, double-buffering is always enabled by virtue of the host operating system, and Altirra still seems pretty darn good to me :)
And one last thing: Seeed offered me two options to make good on their mistake - they would either (at their expense) ship the boards back to them, re-work them, and ship them to me again, or they'd offer me a refund coupon against further work. I chose the coupon, and it arrived today, valid until 18th August. I was critical of them when they made the mistake, so it behoves me to be appreciative when they make up for it. A "hip, hip, hurrah" for Seeed :)


Had a chat with one of the EE guys, he suggested ...


... as a way to get the signal within range. It occurs to me that I actually have a 3.3v rail and a 1v power-rail, so I could do the same thing with the 1v rail and get a better dynamic range, since the signal swing is 0.8v. He did caution me that the current across the potential divider (+3.3v to ground) ought to be within an order of magnitude of the audio-signal current - if we're talking milliamps of supply current, then 3.3v and 1K resistors work reasonably well, I may need to change it for +1v<-->GND.

Question: what is the supply current on the 1088XEL audio pins ?


#58 AMenard OFFLINE  



  • 426 posts
  • Location:Beauharnois, Qc, Canada

Posted Tue May 22, 2018 6:46 PM

I'll take one when they become available.
I'm pimpin' out my 130xe and this will be a great an useful addition.

#59 mytek ONLINE  


    River Patroller

  • 2,696 posts
  • Location:Santa Rosa, CA

Posted Tue May 22, 2018 8:19 PM

Question: what is the supply current on the 1088XEL audio pins ?


It's enough to feed into headphones with very good volume, but that's about it. Speakers require amplification.

#60 Spaced Cowboy OFFLINE  

Spaced Cowboy

    Chopper Commander

  • Topic Starter
  • 159 posts
  • Location:San Jose, CA

Posted Tue May 22, 2018 9:34 PM


It's enough to feed into headphones with very good volume, but that's about it. Speakers require amplification.



Ok, so headphones are ~20mA IIRC, so I'll go with that. I think that's a good order-of-magnitude match to the circuit above anyway.

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users