Jump to content

pnr2015

Members
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

1 Neutral

About pnr2015

  • Rank
    Combat Commando

Recent Profile Visitors

893 profile views
  1. I think you are maybe over-analyzing it: connecting CLKOUT to /PHI3 will likely work up to 4MHz. Connecting CLKOUT divided by two to /PHI3 will work up to 6MHz. Use the falling edge of CLKOUT to clock the divider to get phases right. 1. I think that the address lines may not yet be stable at the start of ALATCH, but certainly will be by the end of it, i.e. you may have a CE glitch during ALATCH. Normally this should not matter, as the actual fetch or write happens later in the cycle. 2. I think for the 9901 the PHI3 duty cycle does not matter. PHI3 appears to have only two uses: to drive the internal counter and to synchronize the interrupt circuit. The data sheet only says that the pulse width is *minimum* 45ns, it could be wider. Looking at the 99000 and 9901 data sheets, using CLKOUT for PHI3 should work for both purposes. 3. The 9901 output bits are driven by the falling edge of CRUCLK, not by PHI3; the extra PHI3 cycle does not matter I think. The input bits are read on the rising edge of /RD, again PHI3 does not matter. With the automatic wait state there is plenty access time, even at 6MHz. To be sure, set up a test circuit on Stuart's 99000 board. I've glued a small strip of solder less breadboard in one corner for such experiments, but I don't have a 9901 at hand to verify my above views.
  2. Memories can fade: I looked at the documentation again and indeed the TI990/4 had no mapper at all. The MAP chip in a TI990/10A is a 64 pin package, not 40.
  3. Are you sure? I thought the TMS9900-based TI990/4 had a 74612 mapper. The discrete logic TI990/10 used a MMU with three "base+extent" segments. The TMS99000 based TI990/10A used the same MMU, but integrated into a single custom VLSI chip (referred to as "MAPPER". It is a 40-pin DIP package; I don't think TI ever sold this chip separately).
  4. This was done in the later versions of 16 bit Unix (V7M, 2BSD). It split the 64K area in a base area (say 48K) and up to 15 overlays (say 16KB each). It worked like this: - first you compiled/assembled your code to separate object files. - then you linked it into the final program, specifying which object files went to into the base, and which into each overlay. - the linker worked out when a function call went from base to an overlay or from overlay to a different overlay. - the linker then added little stub subroutines to base, one for each such target function; the calls to the target function were patched up to be calls to the stub - the stub would check if the currently mapped overlay was the correct one and if so jump to the real target subroutine; if not, it would first map in the right overlay and only then make the jump BSD2.11 (released in 1992) managed to run a 250KB kernel in a 64KB address space.
×
×
  • Create New...