This may never see the light of day (if the prototype turns out to be
stillborn) but it's pretty and I can't resist posting a pic before I've
powered it on and proven its uselessness:
http://www.dbit.com/wilson/projects/qba.jpg
Officially it's for my morally repugnant attempts to earn a living (so it's
supposed to be a Q-bus bridge that connects over Ethernet), but I wanted to
still be able to do something fun in the very likely case that the Ethernet
port doesn't work (no idea if my PCB layout is kosher for something as fast
as the gigabit PHY's bus) or has uselessly high latency, so I added an SD
card slot and made all the CPU-end terminators switchable, so it can act
as just a plain peripheral (I'm mainly thinking disk controller -- I've
already found a reason why the USB device port can't work), if its CPU's
alive and can talk to the Q-bus. We'll see. Many many many chances for
mistakes. Five different power-supply voltages, for starters.
As always, I can't say enough good things about XMOS microcontrollers and
OSHpark.com.
John Wilson
D Bit
Looking for an Atari ST mouse, have an extra Amiga mouse to trade?
Also looking to buy a 520ST power supply to complete a system if anyone
knows of extras.
--
Ethan O'Toole
I wanted to let folks know what the current status is on the MEM11
project. I apologize in advance for the long post.
Previously I had mentioned that the emulator was fully functional (more
on that later) and that I was starting to debug the MEM11 firmware. I
have made significant progress and I'm in the final stages of testing
the recovery image firmware and the configuration image firmware. In
reality, the recovery image firmware is a heavily stripped down version
of the configuration image firmware - I had to make space for all of the
strings, in the configuration image the strings are kept in FRAM. This
usually means that I can do most of the testing in the configuration image
and (with a few exceptions) I'm assured that it'll work properly in the
recovery image.
The recovery image is what will be in the J1's RAM (in the FPGA) after
reset. It is also the "cold boot" loader. Depending upon configuration
settings and a couple of jumpers, it looks for a version of firmware
to run. Recall that there are up to 5 copies of the firmware:
2 copies of the "run time" firmware, this is what makes the MEM11
a set of Unibus devices
2 copies of the "configuration" firmware, this allows you to
configure the board, load new firmware, load/save memory, ROM
images and RS11 disk images
1 copy of the "configuration" firmware that is deemed "safe". This
copy cannot be updated except by the recovery image
The recovery image is part of the FPGA programming so it cannot be
updated in the field.
The recovery and configuration images support the XMODEM protocol for
uploading/downloading FRAM contents.
I'm going through and exhaustively testing all of the command and
checking that they produce the proper results and leave no extraneous
bits on the stack(s).
I haven't been able to do any testing on the XMODEM command yet because
I don't have support in the emulator for connecting other programs to
the console. So once all of the other commands have been tested, I'm
going to extend the emulator to handle some other devices. I'm also
going to add some scripting capabilities. I'm getting really tired of
typing some commands (the first 3 in the session below are burned into
my brain). It should also allow me to provide some capability to
emulate the Unibus side of things once I get to the point of testing
out the runtime firmware.
Here's a short session on using the emulator:
$ gforth emulator/j1-emulator.fs
J1> mode status 0008
J1> load 60000 mem11-cfg.img
J1> get j1-boot-ram.img
J1> run
MEM11 Recovery Interface
MEM11 Firmware Version 0.4 (EMUL)
RECOVERY> help
Commands:
BOOT Boot selected image
CLEAR Clear specified memory region
DUMP Dump out a section of FRAM
MAP Display FRAM address map
MODIFY Modifies contents of FRAM
VERSION Display version
RESET Perform a HW reset
XMODEM Download into FRAM using XMODEM protocol
SET Set configuration information
SHOW Show configuration information
Additional help:
HELP <command-name>
RECOVERY> boot safe
MEM11 Command and Configuration Interface
MEM11 Firmware Version 0.3 (EMUL)
SAFE> help
Commands:
BOOT Boot selected image
CLEAR Clear specified memory region
DUMP Dump out a section of FRAM
ENABLE Enable indicated UNIBUS device
DISABLE Disable indicated UNIBUS device
EXAMINE Examine J1's RAM
LIST Lists names of images
MAP Display FRAM address map
MODIFY Modifies contents of FRAM
POKE Change J1's RAM
VERSION Display version
RESET Perform a HW reset
XMODEM Download into FRAM using XMODEM protocol
SET Set configuration information
SHOW Show configuration information
Additional help:
HELP <command-name>
SAFE> set defaults
SAFE> show dl11 0
ENABLED
SLOT: 3
CSR: 777560
LENGTH: 000010
INT VECTOR: 060
INT PRIORITY: BG4
BAUD RATE: 9600
PARITY: NONE
DATA BITS: 8
STOP BITS: 1
SAFE> show memory
ENABLED
BASE ADDR: 000000
LENGTH: 760000
SAFE> show kw11l
DISABLED
SLOT: 7
CSR: 777540
LENGTH: 000010
INT VECTOR: 100
INT PRIORITY: BG6
LINE FREQ: 16667 uS
SAFE> list boot-image
0 : <NO IMAGE>
1 : <NO IMAGE>
2 : <NO IMAGE>
3 : <NO IMAGE>
B SAFE : MEM11 Config V0.3 (EMUL) Built on Fri Oct 9 20:18:31 PDT 2015
SAFE>
Execution Stopped at: PC: 016C
J1> help
Commands:
HELP - Help command
DUMP - Examine the contents of FRAM
MODIFY - Modify the contents of FRAM
EXAMINE - Examine the contents of J1 RAM
PATCH - Modify the contents of J1 RAM
CLEAR - Clear the contents of FRAM
LOAD - Load FRAM from a file
SAVE - Save FRAM into a file
GET - Load J1 RAM from a file
QUIT - Exit the emulator
RUN - Run the J1 program
STEP - Single step the next J1 instruction
BREAKPOINT - Set a breakpoint
CONTINUE - Continue J1 execution
.R - Dump the J1 return stack
.S - Dump the J1 data stack
.PC - Display the current J1 program counter
DEPTH - Report the depth of the J1 data and return stacks
TRACE - Control tracing of J1 instructions
RESET - Reset J1 and the emulated peripherals
MODE - Set or view the MEM11 mode
LED - Display the LEDs that would appear on a MEM11 board
Typing 'HELP <command>' will give additional details about the command
J1> .s
DSP: 5
ST0: 0005
Data Stack:
5 : 0000
4 : 1E1E
3 : 1E6E
2 : 1E1E
1 : 0000
J1> .r
RSP: 6
Return Stack:
6 : 0D84
5 : 0D4A
4 : 0D7E
3 : 1C1A
2 : 3B26
1 : 3BB2
J1>
Unfortunately SVT ?ppet Arkiv is not available to anyone outside Sweden,
which is a pity. A great source.
This interest for computers and election vigils come from the fact that I
had a email conversation with a person that was involved when DEC won the
contract to for the election in 1976 in Sweden for SVT. He was involved in
adapting the VT30 system for TV use. Genlock and stuff.
I found three clips in ?ppet Arkiv which I trimmed down heavily. These
shows tend to be quite long anyhow. I hope SVT is not getting mad now.
https://www.youtube.com/watch?v=qDoFM3hfbic
/Mattis
Glen,
I'm right in the middle of resuscitating an HP7970E (1600 bpi with the HP-IB
interface). The main problem I had so far was the rubber in the reel hubs
had completely fused to the tape reels that were left on the hubs. I had to
disassemble the hub locking mechanism and use lots of careful X-Acto knife
work to separate the two. A few tape rollers were rough or stuck - just
oiled them for now. Then it started to work, I am very surprised. There are
three red switches on the motor control board inside to make the tape go
forward, reverse and fast rewind. So it's pretty easy to test if the
transport works and the motor servos and tension arms move how they are
supposed to.
Brent,
Wow, looked at your site, and you actually wrote a HP 2100 cross-assembler?
Nice. Would it work for the HP21MX too? Did you compile it using the command
line tools in XCode?
Marc
==========================================================
Date: Wed, 7 Oct 2015 13:29:37 -0700
From: Brent Hilpert <hilpert at cs.ubc.ca>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: HP & 800BPI / was Re: Tape cleaner on eBay
Message-ID: <858603D2-2D79-45D6-993C-A8939D996815 at cs.ubc.ca>
Content-Type: text/plain; charset=us-ascii
On 2015-Oct-07, at 12:56 PM, Glen Slick wrote:
> I have an 800BPI 7970B in a 2113B rack system. I've never gotten
> around to trying to get it up and running. Are they fairly reliable
> drives to get going again? I don't have any other 800BPI drives to
> write any tapes to read with it.
>On Wed, Oct 7, 2015 at 12:46 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
Well, the unit here was in pretty good physical condition as received.
It had a cascading failure in the capstan driver but it was a fairly
straightforward fix.
I think there was one sluggish/partially-seized pulley bearing (freed up
with some oil).
Pretty rugged drives as you know. I wonder about the capstan rubber in the
long term but I think that's about the only thing to worry about on age
alone.
I think bitsavers nowadays has manuals and schematics for the B version as
you have, years ago I had to do some reverse-engineering for the capstan
repair.
This page is over ten years old and needs some updating, but FWIW:
http://www.cs.ubc.ca/~hilpert/e/HP21xx/HP2116CSys/index.html
Note the tape drive repair log page linked there.
Hello All,
This is just a general shout out and thanks to David (Gesswein) for the
excellent work on the MFM emulator boards. I received both of my fully
assembled emulators today. They arrived professionally packaged and ready to
go out of the box. I wish more hobby/home brew projects went this smoothly
and bore such excellent fruit. Kudos to David!
-Ali
