Michael Joosten stands accused of saying:
> 
> >An 8-byte _output_ fifo?  Obviously designed for terminals or printers?
> 
> Sounds weird, but I vaguley remeber having read a similar thing in the
> datasheet of an 2681. But don't nail me down...

Ok, I'll be gentle 8)  The 2681 has a 3-byte receive FIFO and no transmit
FIFO.  (If you include the RSR and TSR in your accounting, you can claim 
it has a 4-byte receive queue and a 2-byte transmit queue.)

> I'm experimenting with Domain/OS monitor in service mode (button and green
> LED), which has a simple machine code monitor build in. I was just too lazy to
> figure out how to use kgdb or such...

I couldn't actually work out how to get it to do disassembly, and sometimes
if you cause a fault (reading from a bad address eg.) it goes into
'go very slow' mode (like turning off the instruction cache when you're 
using a monitor rather than a terminal).

> and there is some address space mapped at 0x600000 + 9 * 0x10000:
> >D 690000 690100
>    690000: FFC2 FF20 FFC2 FF20 FFC2 FF20 FFC2 FF20 
>    690010: FF80 FF00 FF01 FF07 FF00 FF60 FF0F FFFF 
>    690020: FFC2 FF20 FFC2 FF20 FFC2 FF20 FFC2 FF20 
>    690030: FF80 FF00 FF01 FF07 FF00 FF60 FF00 FFFF 
> 
> .. but I'm a bit surprised why that parallel port takes almost 16 registers, as
> the values of ...10 - ...1f are not repeating or mirrored. (..00- ..0f is the
> usual HP card identifier and such) I got the apollo_pci.o just from HP patch
> archive, I'm not sure if there is also a patch containing the module for the
> parallel port.

Yes, I've looked at that too.  It makes register access at offsets
1,3,7 and 9 (but I suspect that 9 may be a hack to write a 0 to 0 which I
understand is meant to be the DIO 'reset' command).  The HP/UX 
parallel driver is kinda tough to read, as it seems to do a lot of 
DMA-related stuff (but I'm still looking at it).

> The extended selftest confirms some of my guesses:
> UTILITY CHIP SIO TESTS STARTED
>    Internal Loopback SIO 0             - PASSED
>    Internal Loopback SIO 1             - PASSED
>    Internal Loopback SIO 2 line in use - SKIPPED
>    Internal Loopback SIO 3             - PASSED

Hey, that's interesting.  Are you using a serial console on a different
port?  (On my 425 I get SIO 1 in use...)

> >They didn't bother emulating the 2681, why go with the 6840?  More
> >interestingly, perhaps, can the timer generate interrupts?

> I'd guess they had to provide a timer with Domain/OS suitable
> function, as the comments in NetBSD indicate that the HP one is
> already 'wired': two counter are concatenated.

Ah.  In this case, another clock might be quite useful.

> And perhaps the clock
> is different. Interrupts... generally an interesting question, also
> for the sio ports... but a timer without interrupts doesn't make
> much sense in a multitasking os, does it?

Um, depends.  A fast non-interrupting timer can be helpful in that it
can give you much finer time resolution for things like microtime().
(On your regular clock interrupt, grab the timer.  When microtime is
called, take the current timer value less the one at the last clock
interrupt, and that gives you the current time to much better
resolution than you would normally get.)

> Perhaps the 'fake' scode
> of the utility chip (41) or the blurb of changing the scode in the
> driver and also in the configuration part of the monitor PROM gives
> a hint on what interrupt level it can work. (Priority Interrupt
> Tests, UTIL_PIC, perhaps means Priority Interrupt Controller,
> hmmm...)

I'm fairly certain that the Utility chip has a single interrupt output
muxing all its interrupt sources, and you'll have to read a status
register (what does the area around 0xe0 in the chip read like?) to
work out what's interrupting.  I could give you a simple sequence of
things to do that should make one of the UARTs register an interrupt;
(if you can't do that yourself) you could then hunt for changes around
the PIC registers.

> >> clock frequency...  Well, there is an 14.318 Mhz oscillator near
> the 16550 on the board (together with a 40 Mhz one), but it does not
> seem to be directly connected to the 16550.  But I'd assume that,
> since both port types are so similar, they use the same master clock
> - I hope... 

I doubt it.  The 14.318 crystal is the (NTSC colourburst?) crystal
used for the ISA bus, and divided down for the dca I think.  There's a
40MHz crystal just next to it that I suspect is the memory subsystem
clock.  (It appears that the CPU is asynchronously coupled to the rest
of the system, but that's really a flying guess and not backed up by
much other than that it works at 33MHz. 8)

> At least for the domain side, the divisors seem to be
> correct for the domain keyb, as I can properly read keys out of the
> register.  Or is it possible to read these divisor latches back ?
> No, doesn't seem to work...

The bootprom almost certainly sets the dividers correctly for the
domain keyboard.  When you said that it didn't work, how did you do
it?  Did you set DLAB in the LCR first?  The 8250 datasheet implies
that you should be able to read them back.

(DLAB is bit 7 in register 3, it must be set to 1 to access the
divisor latch and 0 to access the data register.)

> How did you create the dissasembly? Looks quite nice...where did you get the
> reloc info from? 

I built GNU binutils with --target=m68k-hp-hpux, and then used

m68k-hp-hpux-objdump --reloc --disassemble apollo_pci.o

In some places it gets out of sync (where the HP compiler has inserted
padding), so occasionally it's necessary to use the --start-address and
--stop-address arguments to emit small snippets.

-- 
]] Mike Smith, Software Engineer        msmith@gsoft.com.au             [[
]] Genesis Software                     genesis@gsoft.com.au            [[
]] High-speed data acquisition and      (GSM mobile)     0411-222-496   [[
]] realtime instrument control.         (ph)          +61-8-8267-3493   [[
]] Unix hardware collector.             "Where are your PEZ?" The Tick  [[