pnr2015
-
Content Count
14 -
Joined
-
Last visited
Posts posted by pnr2015
-
-
On 7/12/2020 at 6:54 PM, atrax27407 said:Here is a variant of the Hexbus DSR that might be interesting to dis-assemble - pnr?
How is the variant different? Where does it come from?
-
On 6/29/2020 at 2:53 PM, acadiel said:Great job!
Any idea why there were three RS232 device names in the DSR? What is done in the code with them?
They were added for compatibility with the Terminal Emulator II module, which has only these names in its code.
RS232 and RS232/1 are the same as HEXBUS.20 and RS232/2 is the same as HEXBUS.21
-
On 6/29/2020 at 3:19 PM, acadiel said:Here is the Michael Becker PHP1300 images (these are as high res as I have). I posted a lot of the PALs and dumps earlier in the thread. This is the standalone PHP1300 interface.
Ksarul is the owner of it, currently, and will have to dump the remaining GALs/PALs that I couldn't.
I think this is not a PHP1300, but a HX5102 clone. The 8272 chip is a floppy controller, and overall the components seem to match those on the HX5102 board (see the picture that @mizapf posted earlier in this thread). The ROM and RAM chips are higher capacity, so there is only one of each. Some more TTL logic seems replaced by PAL's.
I think MAME has a working emulation of the HX5102, so the contents of the PAL on the original board must be known. I guess somebody must have reverse engineered the schematics. Not sure what the edge connectors on the original HX5102 PCB were for - they are not mentioned in the draft manual.
There are some photos of the Michael Becker PHP1300 clone over on WHTech, but no photo of the actual board with components. I think it will have the very same chips as the original board - maybe the hex inverter chip (of which only one inverter is used) is integrated into a larger PAL/GAL. Are the whereabouts of that clone known?
Come to think of it, maybe it is a good idea to put the reverse engineered PHP1300 ROM source in that directory on WHTech?
-
@acadiel, @kl99, @mizapf, @Ksarul, @speccery
I've now fully analyzed the DSR rom of the PHP1300. This should help with MAME, cloned PHP1300 devices and FPGA work.
There is a bug in the "slave mode" code: a typo makes the DSR always return an error instead of working as planned. Fixing this byte will enable some interesting experiments (search for word "BUG" in source analysis).
In a few places the code could be cleaned up a bit, but this is not strange in what is beta version code.
-
5
-
1
-
-
That MAME encoding of the chip is helpful. thanks! The logic matches with my understanding of how it works.
-
All,
Worked my way (partly) through the ROM disassembly and squinted at the board shots a lot. I think I got a long way in figuring this out. The reverse engineered source is attached for reference.
It turns out that the Hexbus chip (PDF on WHTech) is not connected to the TI99/4A bus directly, but accessed via CRU bits (i.e. via the LS259 and LS251 on the board). The Hexbus chip is used in Mode 7. The wiring is as follows:
; CRU output bits After INCT R!2 ; 0 - ROM enable ; 1-4 - data out 0-3 - data out ; 5 - RS (0 = data, 1 = control) 4 - RS ; 6 - E (0 = write strobe) 5 - E ; 7 - INT enable 6 - INT enable ; CRU input bits ; 0 - INT asserted (from FF) ; 1-4 - data in ; 5-6 - n/c ; 7 - INT enableThe IRQ output from the Hexbus chip is latched into a flip-flop (half of the LS74) on its falling edge. The output of the goes back to the LS251 and via a transistor (i.e. open collector) to the /EXTINT line of the TI bus. The INT enable line from Q7 of the LS259 is attached to the /CLR line of the flip-flop, so setting it low both clears the latch and disables interrupts until it is set high again.
From the ROM source, it would seem that the interrupt logic is not used for disk operations, only for serial/modem operations (i.e. to listen for new data coming in). Disk operations appear to be synchronous (as they are on the TI99/2).
The Hexbus chip does not appear to do all that much: it is basically a line buffer, combined with a little logic for dis/enable and for latching the HSK line. That is about the same as what the Hexbus corner of the I/O chip in a 99/2 does. Still, if you had to replace it with TTL, it would take 4-5 packages (and a few software tweaks). In terms of Verilog, I think it will take a good 100 lines or so.
I have not really looked at the PAL, I think it is only there for address decoding. Not sure what CRU range it responds to. Also not sure what the switch on the left does (maybe pick from two CRU range options?)
In the ROM I have focussed on how it interacts with the Hexbus chip. All the Hexbus interaction is really done in software, but it is straightforward. Most of the ROM seems to be about dealing with connection strings, as detailed in the draft software specification (PDF on WHTech). I'm not too interested in this, but if someone wants to have a go, the community would have a full ROM source.
If anybody has more info or corrections to the above, please let me know.
-
5
-
-
@acadiel: I think the ROM image you attached is for the RS232 card, not the PHP1300.
Does anyone have a dump of the PHP1300 ROM at hand?
Thx in advance.
===
Never mind - I was a fool. The Hexbus DSR header begins with two entries for RS232, but HEXBUS comes after that. It is the right ROM.
-
1
-
-
@mizapf: thanks for pointing this out. I now understand the difference between this chip and the OSO chip in the 99/8.
@kl99: thank you for this reference. Do I understand correctly that this source is behind a pay wall then?
For a 4K DSR ROM I would expect that it is something like 1500 lines of assembler source, not an unsurmountable amount of work. -
On 5/7/2020 at 9:19 PM, acadiel said:Yeppers! That's what I was referring to above. Ksarul has most of the copies of the /4A interface. We also have schematics for the Hexbus drive controller.
Edit: These are the only pictures I have of the interface. Ksarul will need to provide any higher resolution ones we need. He also has tons of the Hexbus interface chips he got as surplus. I do see a PAL. I do have the ROM dumped (attached).
Did somebody ever do disassembly / reverse engineering on this DSR? Is it very similar to the TI99/8 DSR source that is up on WHTECH?
The community around the ULX3S FPGA board are looking into emulating a PHP1300 for Speccery's TI99/4A implementation. -
On 1/14/2020 at 1:54 AM, FarmerPotato said:So the only questions are tough:
1. I have a '138 decoding CRU addresses into CE for each thing. With chip enable G1= MEM indicating a CRU cycle. I'd like to use G2*=ALATCH so that all the CE outputs go high as soon as a new memory cycle begins with ALATCH=1.
2. If the PHI3 input is a 50% duty 3MHz clock, does the 9901 work at all? The datasheet indicates that the 9901 requires Phi3 to be 225ns high, 45ns low. That's what you get from Phi3 out of the 9900 - phase 3 of a 4 phase clock. However, the 9901-40 allows 160ns high, 45ns low, so it should work with a 3 or 4MHz 50% clock. So I think that's the answer to that.
3. The TMS99105 (6 MHz) gives an automatic wait state to CRU devices so that the cycle is 333ns. With the above clock, the falling edge of Phi3 may occur in the first or second half of this 333ns. Is there a required phase relationship between the input clock and the read/write cycle? Phi3 seems to control only the latching of interrupt bits in the CRU, and the internal timer. Will there be glitches reading interrupts that are simultaneously being latched? I hope the worst that happens is that they are read a cycle later.
4. Should I just give up on the 9901 and build the equivalent out of '147, '259, and '151 chips?
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.
-
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.
-
The 9900 based models had 64K.
I think the models that had over 64K used the 99000 series CPUs or discrete logic.
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).
-
The idea I'm noodling is that in branching to a subroutine in the bank area, the process of executing a BL (or BLWP, or XOP) against a specific address would cause the bank switch. If banking and landing on the exact routine is not possible, then maybe landing on a vector table in the banked-in memory to complete the jump to the proper routine... Maybe.
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.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Musings on 99000 macro code
in TI-99/4A Development
Posted
Do you have that user guide (or a link)? Did anybody ever come across a copy of the "990/12 Writeable Control Store Assembler and Language" manual?