Recent Posts

1

Projects, Designs, and Technical Stuff / Re: Help with DIY guitar pedal

« Last post by pipingmike on Today at 04:40:48 pm »

You guys are so mean, no wonder people are hesitant to share projects

2

Projects, Designs, and Technical Stuff / Re: LM5145 Inductor keeps heating up

« Last post by MBrahim on Today at 04:39:57 pm »

A 20A converter on 22uF output caps, with a 12mm inductor, slow low rent mosfets, gunning for a 1MHz switching frequency, what were they thinking?

Everything about it looks suspect. Buy the evaluation board and start from a working design.

First of all if you don't mind don't just move and trash talk anyone, We're not born with soldering Iron in our hands sir.
But I'll answer you anyway.
I was thinking according to TI WEBBENCH designer and the buck converter calculator that They provide in thier site

About the components selection, Coil was a mistake and I admitted it as I got no help from the education system on how to choose your coil or what are the parameters you need to check, It was all self-learning with limited resources. The Output caps are chosen according to the designer as well, every little detail even the layout I did it according to the datasheet with a little edit for my project needs.

And for that part about buying the evaluation board like bro in what world are you living, it's expensive, shipping can take a while. I needed to design very fast, there're deadlines.

3

Vintage Computing / Getting an MVME320B (Motorola VME HD controller) working

« Last post by LittleFrog on Today at 04:39:20 pm »

Hi

I'm reaching out to see if anyone has experience of the Motorola MVME320B disk controller card.

This is quite a long posting, but the bones of it are:  I have hooked everything up and to all intents and purposes, the disk controller does not show any sign of life on the HD interface ports no matter what I do.  I can see evidence that the disk controller is not dead on the VME bus side.

The detail is as follows;

My hardware set up is a VME rack containing two cards;

• MVME110 processor card with a 68000 running 110Bug V4.1.  It's fitted with 32K bytes static RAM
• MVME320B disk controller card with V4.2 firmware.  This is the later version of the card which does all the disk I/O through ribbon cables out the front of the rack.

The processor is in the left most slot and the disk controller is directly to the right of that.

I am only trying to connect a hard disk, I've not attempted anything with floppy disks.

I don't have any instructions for 110Bug but reviewing the source, I can see that there are basically two families of disk related commands;

• VersaDos boot through the "B*" commands.  These have options on what to do after the boot blocks are loaded
• Low level interaction with the disk controller through the "IO*" commands

I don't have a valid VersaDos image so my investigations only relate to the low level commands.

Actually I don't even have a real hard disk.  I'm using one of these;

https://www.pdp8online.com/mfm/mfm.shtml

this has the advantage that you get some diagnostics while it's running and I can create just about any topology of disk that I want.

The processor card serial port is connected to a Terminal Server like this;

https://amzn.eu/d/3c6rNQY

which comes in handy as I'll explain in a minute.   Basically I can run puTTY across my LAN and at the same time send sequences of keystrokes to the processor using a little program I wrote.

A characteristic of VME cards of this era is JUMPERS!  They're everywhere.  Also there seems to be a sensitivity to hardware/firmware revision status plus of course, the card(s) might be faulty.  Anyway back to jumpers, I used the information here to set the jumpers;

https://bitsavers.computerhistory.org/pdf/motorola/versados/MVMEVDOS_D2_VMEHwSwConf_May85.pdf

This works well for the processor card but unfortunately the disk controller card information relates to an earlier version of the card and the jumper layout has totally changed.

So what I did was write down all the settings for the earlier version of the disk controller in the guide.  Then I used the old disk controller user manual here;

http://www.bitsavers.org/pdf/motorola/VME/MVME320/MVME320_D1_Disk_Controller_Users_Manual_Feb85.pdf

to figure out what each jumper does and what it's set to.

Then I went to the user manual for the new version of the card which is here;

http://www.bitsavers.org/pdf/motorola/VME/MVME320/MVME320B_D1_Disk_Controller_Users_Manual_Jan88.pdf

and using the information from the old card, I made sure that my settings are correct.  I was heartened to see that actually there are no changes required from "default" which is good (I think).

There are two problems with this process

• There are many more jumpers on the new card so I just them to "default".  I don't think this is a problem because most of the new jumpers relate to Floppy Disk options which I'm not too bothered about.
• In the User Manual for the older card, there is a section on "MVME320 backplane settings".  This does not exist in the new card manual.  Am I missing something to do with the backplane?  Do I need to set something here too?  I've assumed that the old manual is referring to the breakout panel, an MVME702 I think it's called.  Anyway this mystery table is attached as a photo if you take a look.
  

So I turn everything on and set my HD emulator running.  It starts without error.  I think it works because I've used it on PC's without a problem.  I have a crude Logic Analyser connected to the HD control signals and although it's crude, I know that if anything moved, I'd at least see a trigger trace on the LA screen.  As I implied back at the top of this posting, it's always showing "Everything high"; in other words, fairly dead.

Because I don't have any documentation for 110Bug, I don't really understand what each command does.  There is Bug documentation on cards like the MVME177 but the functions of each IO* command is massivly expanded and so is of limited use.  I'm not good enough to figure out what the commands do by reading the source (sorry).  I find it amazing that the code could contain so much annotation without actually explaining what user function is provides anyway the authors will have assumed the reader had the User Manual....

I have figured out that in general, all the disk related command seem to take two arguments representing the HD ID and the controller.  My HD is a number 0 and my controller is a number 4.  I got this from the card user manuals.

So first of all we have IOT and IOP.  I think IOT teaches the controller about the geometry of the connected drives and IOP enables direct physical interaction with the drive.  So getting to actually try something, if I enter;

Code: [Select]

IOT
or

Code: [Select]

IOT 0,4
or

Code: [Select]

IOP
or

Code: [Select]

IOP 0,4
The bug hangs and after about 20 seconds, the Fault LED lights up on the processor card.  The only way out is a reset.

This leaves us with IOC which enables the user to set up a control block in RAM and then (I'm assuming) point the disk controller at it and let it carry out the command.

I don't know, but I'm assuming that the difference between IOC and IOP is that the former uses a RAM based control block (called an ECA in the manual) where as the IOP command enables you to poke the disk controller registers directly. That's just a guess of course.

So if I enter;

Code: [Select]

IOC
Then there is a delay of about 60 seconds and I get a prompt to enter the drive number, then the controller number.  I enter 0 and 4.

I am then presented with a PARTIAL memory dump of the ECA and I'm asked if I'm sure.  I say "Y" and the bug goes dead for about 30 seconds and finally returns a PACK error.

It's interesting that the ECA is longer than the memory dump.  Don't know why this should be but it's missing the geometry section at the end.  Not really a problem but interesting.

When I do a dump of the ECA following the command running, I can see that the main status is $07 which is "Card busy".  I don't think any other part of the ECA is altered.

This is really good because I'd like to think that the disk controller tried to do something and timed out.

Turning to the memory locations used by the disk controller card, if I dump the odd addresses, I see values.  If I dump even addresses, I get bus errors.  If I remove the card and try again, all memory addresses I try to dump give bus errors.  This gives me hope that the disk controller is not totally dead.

Returning to the ECA, loading it by hand is error prone so I wrote a little loader program that sends keystrokes to the serial port.  This is a dumb process, but it does seem to work.  Here's a list of the ECA I set up;

Code: [Select]

# Start loading the ECA as per MVME320 User Manual pg C-9
# Commands described pg 6-1
# Zap the buffer back to 00
bf 110 170 00
# Zap the data buffer
bf 1000 1800 00
# Fill the ECA
m 110
# Command code (Recalibrate to track 0) $00
07
# Main status $01
00
# Extended status (Should be 00 before command) $02
00
00
# Max retries $04
0a
# Actual retries $05
00
# DMA type $06
00
# Command options $07
00
# Buffer address (Hi word) $08
00
00
# Buffer address (Lo word)
10
00
# Buffer length requested $0C
00
01
# Buffer length transferred $0E
00
00
# Cylinder number $10
00
00
# Head number
00
# Sector number
01
# Current cylinder position $14
00
02
# Reserved $16
00
00
00
00
00
00
00
00
00
00
# Pre index gap $20
00
# Post index gap
00
# Sync byte count
00
# Post ID gap
00
# Post data gap
36
# Address mark count
03
# Sector length code
01
# Fill byte
e5
# Reserved $28
00
00
00
00
00
00
# Drive type - Soft sectored, Hard disk with CRC $2E
03
# Number of surfaces $2F
04
# Sectors per track $30
0a
# Stepping rate $31
06
# Head settling time $32
46
# Head load time $33
46
# Seek type $34
02
# Reserved (Phase count) $35
00
# Low write current $36
00
50
# Precomp cylinder $38
00
50
# ECC remainder $3A
00
00
00
00
00
00
# Appended EEC remainder $40
00
00
00
00
00
00
# Reserved $46
00
00
00
00
# MVME320 working area $4A
00
00
00
00
00
00
00
00
00
00
00
00
# Reserved for the controller $56
0f
f0
# Get out of data entry mode
.
# Present a dump of the commannd
md 110 5f
# Actually send the command to the MVME320
# ioc 0,4

and here's the program that loads it (via that Terminal Server I mentioned before).

Code: [Select]

# Send a series of keystrokes to an MVME110 serial port via a terminal server connected
# on the LAN.  The keystrokes are held in a file, e.g. keystrokes.key

# D. Waine 27/04/24

# In order that this program function, you need to have the TS and the MVME110 switched on (!)
# then start a terminal session using puTTY to the TS.  Run this program and the
# key strokes will load.

import sys
import os
import socket
from time import sleep

# Location of the TS on the LAN
terminalAddress = '192.168.0.3'
terminalPort = 8234

if len (sys.argv) != 2:
    print ('Incorrect number of arguments.  You need to supply the input .key file without an extension')
    sys.exit (2)

filename = sys.argv [1]
fileExtension = '.key'
inputFile = filename + fileExtension

lineCounter = 0
outputCounter = 0

# Open the input file
print ('Opening input file: ', inputFile)
with open(inputFile) as inFile:
    print ('Opening output stream to MVME110')
    sock = socket.socket()
    sock.connect((terminalAddress, terminalPort))

    print ('Connected')
    sleep (0.1)
    # Read it a record at a time
    for line in inFile:
        # Trim the input line of CR/LF & any spaces
        inputLine = line.strip()
        # Bump the correct input record type counter
        lineCounter += 1
        if inputLine [0] != '#':
            sock.send ((inputLine + '\r').encode())
            sleep (0.1)
            outputCounter += 1
    sock.close()
print ('Input records: ', lineCounter)
print ('Sent records:  ', outputCounter)

If anyone can shine a light on any of this, I'd be grateful.

Thanks for your attention.

Dave

4

Projects, Designs, and Technical Stuff / Can't make sense of this circuit on a controller loop

« Last post by osflores@qdusa.com on Today at 04:31:52 pm »

Hi All,
The circuit in the attachment is used on a voltage control loop. As you can see the integrator stage U301B is followed by a non inverting configuration with positive feedback U301A (which adds hysterisis to the circuit I assume). The tricky part is the MOSFET used in the positive feedback path Q300. Is someone familiar with this type of circuit and where I can learn about it?

5

Test Equipment / Keysight 34450A Help

« Last post by Louis_C on Today at 04:28:25 pm »

Hello all. I'm looking for some help on a Keysight 34450A. All calibration tests pass except for 100mV AC @ 100kHz. It reads 94.837. The Low limit is 96.700 and the high is 103.3. I tried performing the internal calibration and entering the new corrected reading for this test point and the unit rejects it and fails. I flashed the firmware to the latest version available ( 01.03-01.02). I'm not sure what else to do here. Can anyone give me some advice as to what to look at next? Thanks!

6

Beginners / Re: 5V buck converter debugging

« Last post by __steven on Today at 04:27:49 pm »

You mention there was no load attached and no short, therefore the only current you would see is the inrush to charge the output capacitors. The IC has a soft-start feature that should handle this no problem. Starting up at 4V is what the datasheet describes during start up.

How are you measuring for a short?

The only other two things I can think of. Can you verify the power good resistor is 100k and not something much smaller? The other thing is perhaps the feedback voltage is disconnected. Can you check continuity/resistance between the feedback pin and the output voltage?

I do not see issues in layout nor schematic causing a failure assuming they are implemented as documented. I would think that replacing the IC and trying again is best, if you see the same behavior at 4V try to find what is heating up.

7

Test Equipment / Re: Hacking the Rigol MSO5000 series oscilloscopes

« Last post by Sergey_21 on Today at 04:25:54 pm »

Hi all!
I'm trying to unlock additional options on my MSO5074 oscilloscope.
To do this, I use the rigol_kg2.py script, but after the python rigol_kg2.py -r xx.xx.xx.xx command I get an error.
Can anyone help me?

8

Projects, Designs, and Technical Stuff / Re: Connecting old handheld Magellan Explorist GPS to computer via serial

« Last post by coromonadalix on Today at 04:24:57 pm »

to simply your life you could take ftdi or any  usb to serial 3.3v interface,  do your connection and try with a terminal software  if the garmin spit some stuff when it boot

1st test is the tx rx shorted together in the garmin if the chars ... are echoed, if you are sure of the TX and RX line    ... 

unless this port get disabled once factory programmed


maybe the pins are .05 " spacing instead of the 0.1"  one we see often   oh    pogo pins thats what they are called, they have a spring in them

9

Projects, Designs, and Technical Stuff / Re: Connecting old handheld Magellan Explorist GPS to computer via serial

« Last post by themadhippy on Today at 04:23:42 pm »

whip the back of and find somewhere on the pcb to solder 4 wires,if theirs space bodge in a  4 pin jack socket

10

Beginners / Re: Raspi button hacking

« Last post by Ian.M on Today at 04:21:49 pm »

200mm isn't very long.  10nF between GPIO and Gnd may be added if it does pick up too much noise.  Instead of the SMD BAT54S, you can substitute 2x any other small signal axial leaded Schottky diode you have handy, one between Gnd and GPIO, and the other between GPIO and +3.3V, both cathode positive. Anything rated for 30-200mA and <=100V should be suitable, but avoid >=1A or >100V power Schottky diodes.

However, what you've designed wont harm your Pi, so if it exactly meets your requirements, and you can build it immediately, for free out of junkbox parts, the only downsides are its size and complexity, and the extra approx. 5mA current it wastes.