I'm Designing a board that provides up to 30V OC outputs from 3v3 GPIO lines. The board will be attached directly to the processor board GPIO header (for example raspberry/banana pi etc).
My question is whether there is any special consideration required for the ground plane, currently it's a single solid copper pour with a 0.1uF bypass capacitor fitted near the Darlington common pin.
I'm trying to make a small (50mm x 50mm) board taking a 12V DC battery input and providing 3.3V @ 1.3A and 5V at 0.7A.
Initial plan was a pair of LM1086IS fixed output regulators - cheap and simple, but the power dissipation will be a problem (small sealed plastic box) and anyway it will waste battery power.
So I need an alternative approach; is the answer a switching regulator IC with external inductor and a MOSFET? Something like LTC1147-3.3 for example?
Hi, hoping you experts can give me some pointers :)
I have a 1990's fruit machine in which it's CPU board has the usual Varta 2.4V NiCd 110mAh battery (to preserve the contents of two static RAM chips when it's off so it can keep track of payouts), obviously this has leaked everywhere and the machine won't be used enough to keep it charged if replaced.
Hence plan is:
replace PCB mounted NiCd with fly leads and keyed connector
run that to 3x Alkaline AA or AAA batteries mounted elsewhere (RAM chip datasheet states supply voltage of 2 to 5.5V in standby mode, with typical current draw of 2uA at 3V)
have one or two simple diodes inline to block the charge supply when the machine is running.
Since the CPLD board has been proven in IBM PC/XT and other machines with ISA slots, and a v1b seems well under control, I wondered if we could turn some attention to the CPLD code itself?
The current 'chuck-mod' CPLD implementation provides read optimisation by enabling reads to be performed with a single 16-bit IO, rather than two 8-bit intrustuctions, and this coupled with some loop unrolling in the BIOS for it takes read speed from about 90KB/s to about 230KB/s on a 4.77MHz 8088 (not far short of underlying RAM speed). Note - currently any benchmarks for the board are unreliable, since the XT/IDE BIOS holds the interrupt flag cleared for the duration of transfers, which means the PC clock misses timer ticks and hence proceeds slower than real time so results are over-stated.
Writes currently aren't anywhere near as optimised; to get writes up to the same speed the circuit needs a bit of a rethink. Here's some comment on the initial mod (bear in mind it wasn't a CPLD implementation) from vintage-computer forum,
You can rearrange the addressing of the integrated IDE ports however you'd like, (e.g. another approach would be to invert A0-A3), but the supplemental "latch" port must follow the data port address. My approach was an "it's easy; any idiot can do it" one. I certainly wouldn't do it that way if I were designing from scratch. Two easily-located trace cuts; two jumpers--and more important, easily reversible.
The instruction savings is considerably more than a single instruction fetch. Consider the original way of moving data from the IDE internal buffer to the PC memory (and this is but one way to code the loop).
If you've got a V20 or better for a CPU, the loop can become a single INSW instruction.
Since we now have the luxury of designing from scratch if we so chose, here is some thought on that (reproduced here with kind permission) provided again by Chuck over on vintage-computer forum:
To streamline both, I propose going back to the original port mapping (none of this A8-A0 exchange) and use a state machine to control access to the data port. In over words, in word I/O, the CPU reads or writes the low-order byte first (even address), then immediately reads the high-order byte (high address). The sequence, being controlled by the BIU is atomic; I don't believe that DMA access can interrupt it.
So, the question of how to do "normal" 16-bit I/O is pretty simple:
For reading from the controller, latch the upper 8 bits of the IDE interface when the (even) data port address is accessed, and set a flip-flop. If the data port+1 is immediately accessed, gate the upper 8 bits onto the data bus. If any other port is accessed or an I/O write is generated, reset the flip-flop and proceed normally.
For writing, latch the 8 data bits when the (even) data port is accessed and set a flip flop. If the next access is a write to data port+1, gate all 16 bits to the IDE drive and generate an I/O write. Otherwise, reset the flip flop and proceed normally.
If I'm thinking right, then this would make accesses to the IDE controller on an 8088 indistinguishable from those on an 8086 or any other CPU supporting a 16-bit bus.
Maybe this is too involved, but writes would fly just as fast as reads.
Assuming something can be developed on these lines then the BIOS too would of course need some changes to take advantage of that.
Hence I wanted to open these ideas up to the community here - to my mind there is great potential in the CPLD implementation which was just a cracking idea! Whilst my BIOS coding and CPLD skills are limited at best, I can at least make boards and thoroughly test and benchmark them in a real XT with either 8088 or V20 CPUs :) But that said I will be looking through the BIOS code too (the universal BIOS source is here).
