• Please review our updated Terms and Rules here

AT&T 3B2 Emulator - Still working on it!

Twylo

Experienced Member
Joined
Feb 12, 2009
Messages
230
Location
Poulsbo, WA
Hi folks,

Just a general update, I'm still working on my AT&T 3B2 emulator based on the SIMH platform. It lay dormant for almost a year while I was dealing with life matters, but I've recently dived back in with a vengeance.

I'm still desperately seeking any documentation or schematics that anyone might have related to the 3B2. I've scoured the Internet pretty well, so anything that's online I probably already have. I'm hoping that my pleading for docs will eventually uncover some printed documents that aren't yet online. I'm ESPECIALLY interested in the documents "AT&T 3B2 and 3B5 Computer Driver Design Guide" and "AT&T 3B2 Computer Feature Card Interface Design Manual", neither of which appear to be online anywhere. If you have either of them, let's talk -- I just want to scan them, not keep them.

For reference, I'm keeping notes about 3B2 internals here: http://www.loomcom.com/3b2/

Best Wishes,

-Twylo
 
Nice! Could you rebase your source tree to head of SIMH? I hope to restart my work on dmd5620 sim soon, too.
 
Well, I very badly screwed up my rebase. I'm not surprised, given I was about 14 months out of sync with upstream. The real problem is that I tried to use the GitHub desktop client for the first time, and ended up pushing a terrible state to my repository. Rather than try to undo that mess, I basically restarted from scratch by forking simh/simh again, dropping my 3B2 directory into it, and starting a new fork.

Shattered, that means if you were based off of my fork, you'll have to do some manual work to sync up your changes to the new repository. I'm so sorry about that :(

The good news is that no work has been lost.

From now on, I will keep my fork in sync with upstream to prevent any rebasing problems in the future.

-Twylo
 
Just a quick note to say that I'm getting really, really close to booting UNIX in the emulator. I've implemented just enough of the MMU to support virtual space for the kernel. It's dying during boot because the free page table is corrupted somehow, but I'm working actively on it.

We're getting there!

3b2_booting.jpg
 
Somehow, the idea of being able to use an emulated 3B2 from a simulated BLIT terminal makes very happy. I'll be watching this space with interest.
 
5620 actually is not the original BLIT, but if anyone can share ROM images for the BLIT and a technical manual, it should be much easier to emulate -- since it uses m68k, not we32k cpu.
 
Still more progress, but it feels like one step forward, two steps back. Floppy commands are timing out, and I'm not entirely sure why. Sure wish I had better documentation!

3b2_20160319.jpg
 
That trap looks a lot like the error I got on my old /300 (with the WE32000) when I had the wrong ROMs (for the newer WE32100-based /310 and /400) in it. The standalone utilities disk would work and I was able to format a new drive with the machine in that state, but I couldn't boot any version of UNIX until I got the correct ROMs installed.

...wish I'd saved the console log from those sessions so I could say for sure that was the trap I got.
 
That trap looks a lot like the error I got on my old /300 (with the WE32000) when I had the wrong ROMs...

I figured out the TRAP, luckily. A bug in the CPU code was setting the Z flag incorrectly, so it was jumping to the wrong location and loading garbage data as an instruction. I'm shocked I didn't find it earlier.

Current status: It's now made it past initing process 0, and it's sitting in a sleep() loop waiting for interrupts. I'm honestly not sure what interrupts it expects. I sure wish I had documentation, but alas, it's unobtanium. I'm still just reverse-engineering everything and applying copious amounts of Trial-and-Error.
 
A timer interrupt, perhaps?

From my reverse engineering so far, there seem to be three sources of timer interrupts:

  1. The realtime clock, which interrupts at priority level 11 every 100 Hz.
  2. The 2861 DUART timer, which issues priority level 9 interrupts based on UART timer settings.
  3. The 8253 interval timer, which may issue priority level 8 and 9 interrupts (I think?) based on 8253 timer settings.

I've been using the SVR3 source code to reverse engineer what these interrupts drive. There are precious few comments in the code, so the source of interrupts has been a combination of guesswork and assumption.

I'm very certain that the 100Hz RTC is generating the right interrupts at the right time, now. I can watch the RTC clock interrupt handler running and doing its thing. I'm also fairly confident that the UART timer is working correctly. But, I'm much less confident in the 8253 timer. That one remains total guesswork, and is probably the source of my woes. Maybe. Potentially :)
 
From my reverse engineering so far, there seem to be three sources of timer interrupts

Aha!! I was wrong. I'm just replying here to keep track of what I've discovered.

So, there really are only TWO sources of timer interrupts, as I confirmed by more careful study of the SVR3 source code (and some basic reasoning I should have done earlier).

The only two timer clock sources on the 3B2 are:

  • The 2861 DUART timer.
  • The 8253, which has three separate timers.

The 100Hz RTC is provided by Timer B on the 8253. Timer A provides a sanity timer. Timer C appears not to be used.
 
simulation is mostly working, I guess now it's time to find out how to actually use this device as intended (with 'layers')...


Emulated DMD 5620 connected to BSD machine, dvidmd man page displayed
 
More progress. This is layers running 'jim' text editor and 'crabs' "malware":

DMD 5620: jim infested by crabs
 
Back
Top