Hi guys,
Quick update regarding the disc analyser... Latest news is:
* The USB interface is now running properly at full speed.
Write-to-buffer has gone from 84Kbytes/sec to over 180 with two small
firmware tweaks. Read speed is a little under 250Kbytes/sec, which means
the entire 512K buffer can be read out in a shade over two seconds. It's
not going to win me any awards, but I think it's plenty fast enough.
* It Has A Name! One of my friends suggested "DiscFerret" partly as
a slight dig at the Catweasel. The name has stuck to the point where
I've... um... registered a .com domain name for it... (hey, it only cost
?12). I'll be setting up the site as soon as I find a nice Wiki package
that isn't bloated to the size of a small main-sequence star (*koff*
Mediawiki).
* Schematics are basically done. I need to test the power supply
section, which is on the to-do list for a bit later on. Soldering down
the QFN-packaged power regulator IC will be interesting.
* There's an external power output for disc drives. It provides +12V
at 1.5A and +5V at 1.5A. Perfect for running small 3.5in drives, and
saves a mains socket. Haven't decided on a connector, but the +12 is fed
directly from the input power supply, so if you connect a 15V PSU you'll
see 15V on the EPS output.
* Power supply can accept between 9 and 15V, though it is specified
to operate with peak efficiency at approx. 12V. Input is
reverse-polarity protected with a grounded-gate low-Rds(on) MOSFET.
I'll probably be building up a prototype power supply board tonight or
tomorrow, and giving that a good beating with a homebrew DC load. I
think I've got some MJE3055s and trimpots somewhere, though whether
they'll work with Vce=1.2V remains to be seen (I suspect a MOSFET might
work better).
But first I need to get my paws on some 0.5mm carbide drill bits. There
are a couple of vias on that board that are in a really tight spot... I
make no secret of the fact that it was designed to be commercially
manufactured, not haphazardly assembled by some semi-skilled engineering
student in a garden shed (i.e. me!)
The plan for those is to drill out the holes, push in a resistor leg
flush with one side, solder on one side, cut and file flush on the other
side, then solder that side too. I figure that should be a tight enough
fit that the wire won't be going anywhere... and if that doesn't work
there's always 26SWG tinned copper wire.
Cheers,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
From: Josh Dersch <derschjo at mail.msu.edu>
> (As a related aside, is there *anywhere* one can get hard-sectored 5.25"
> floppies these days?)
People have been known to make their own 5 1/4" hard-sectored disks. I
don't remember the details, but the basic idea was to take a 5 1/4" disk
drive to hold the disk, make an index wheel for the holes, add a hole
punch, and then just add time.
Hi Dave,
Interested to read about your Northstar S100 bus computer
I have two of these withdual 51/4 disk drives sitting in my shed here in
Adelaide South Australia
I think I also have some manuals and software somewhere in the shed as well
Are these of any value ?
I also have some DEC desktop comuters and screens, disk units and tape units
along with some operating software
Kind regards
Andy Cheel
Hi folks,
I'll most probably offer a TC11 controller for sale in the next days.
The controller connects to a pdp11's Unibus and can handle up to eight
TU55/TU56 tape transports (i.e. four TU56). It is configured for TU56
control levels ("integrated circuit").
Ebay would probably be the easiest way to handle a transaction with
overseas buyers. Are there interested persons willing to pay nearly USD
150 for shipping?
Regards,
Philipp
> This is certainly not a capacitor problem...
>
> I think this board uses 2144s as the video memory
> So my first guess is to replace the RAMs.
>
> -tony
>
> ----
>
> I'd be looking for a stuck address bit, or possibly a failed RAM chip
> My money's on a 74xx chip (possibly a counter, buffer or multiplexer)
> that's had an output fail open.
>
> Phil
>
> -----
> Along with Phil's suggestion of memory addressing issues resulting in a
> double-scan of the memory, the staggering of the images suggests
interlacing
> might be occurring when it shouldn't be. Sometimes it is possible to
tweak the
> V/H-hold controls enough on monitors to end up with interlacing
occurring when
> it shouldn't. Can you discern whether each of the scan images
contains a full
> set of lines vs half the number of lines?
>
> I hate to ask, but what sort of monitor is this being displayed on?
> IIRC the scan rate for MDA was higher than NTSC and I'm not not sure
whether an
> NTSC monitor would sync up or sync down to half the scan rate.
>
> Brent
-----------------
Thanks for the feedback. I am using a standard IBM monochrome monitor.
I tested the monitor with another known-working card, and I also tried
another monitor. The problem is with the display card.
This is one of the original black connector versions of the IBM 1904057
XM 407 display cards. It has 9114 RAMs in it, not socketed of course,
so I think if I can probe each RAM chip first to ID the bad chip it'd be
more efficient. I would similarly have to check the 74L chips. oy!
Bill Degnan
Hello,
I cannot find doc informing how to send ie an .HEX file from Hyper terminal to my programmer, when the programmer sends a file to the cpu the format is a sort of a start character, the address of the first byte and then a series of :
HH HH HH HH HH etc where H stands for a hex symbol.
Do I need to translate the Intel Hex file or how can I send an OMF-51 file?
Do I have to use another communication program??
Thanks if you can help me.
Marc De Lepeleire
_________________________________________________________________
Hotmail: Trusted email with Microsoft?s powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
>
> If it's the original IBM5151 monitor, remember there's no horizontal
> oscillator in the monitor. The Hsync (or more correctly HDrv, which is
> what IBM called it) output from the MDA card goes to the base of the
> horiztoal driver transistor, the collector is then transformer-coupled to
> the base of the horizotnal output transistor.
>
> This means a 5151 will try to run at whatever freqeucny you give it, the
> horizotnal output stage is likley to protest if it's way off, though. I
> don;t think that if you give it an HDrv of the wrong frequency it will
> ever give you a double image.
>
> -tony
>
It is a 5151. I was able to reproduce the problem on a newer monochrome
monitor.
bd
All this talk about the HP 64000 has got me thinking...
The HP 165xB Inverse Assembler Toolkit includes a DOS-based table
assembler that appears to be derived from something used on the HP
64000, and it spits out what the manual calls a "HP 64000 format
relocatable object file". This is what the analyser loads to run an IA.
Did HP ever publish a spec for the .R (relocatable object) file, or has
it ever been successfully reverse engineered?
This is one of those "curiosity killed the cat" type projects; I've been
wanting to use the HP LA inverse assemblers on a PC since I got my 1651B
(mainly because a PC can theoretically handle a much larger symbol table).
Writing an assembler / compiler for my own custom format and VM is
always an option, I suppose, but I'd rather like to be able to run the
HP IAs that I don't have the source code for (ISTR I've got a 68000 one
somewhere).
Thanks,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
... that was announced by Bruce Ray back in December. The original
posting promised details in a few weeks but AFAIK such details never
can forward. Did something happen to cancel the deal at the last
second or are things just taking longer than originally thought.
Mike
