Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Community Reputation

1,015 Excellent

1 Follower

About FarmerPotato

  • Rank
  • Birthday 01/01/1971

Profile Information

  • Gender
  • Location
    Austin, TX
  • Interests
    TI-99/4A. FORTH. Verilog.
  • Currently Playing
    Last year: Port Royale 3, Pocket Trains, Minecraft, Master of Orion II, PacMan 256, Katamari Damacy, We Love Katamari, NY Times Crossword
    This year: Katamari Damacy Reroll, Settlers of Catan Universe, Chisholm Trail, NY Times Crossword

Recent Profile Visitors

4,059 profile views
  1. I bought 2 ZIF 32-pin sockets from Polida2008 (eBay). I let my kids play with them first, cuz they are the neatest connectors around. After loading a chip in and out a few times on one, they tried the other! It wouldn't go in! Looks like I got wonky ZIFs. One of them locks with the lever down. The other locks with the lever up. Is this a normal variety? They say 3M on them, but I have a doubt.
  2. I don't think I ever mixed them. I found uses for DORG 0 at the top of a file, like building struct offsets, then RORG for the code. I wrote whole programs with AORG (for XB environment or cart images).
  3. That got me thinking. When a write starts, READY must be pulled low on the falling edge of SE*, then pulled high after a falling edge of CLKOUT and a rising edge of CLKOUT. Otherwise SE* will never be released back to high. There may be a rising edge of CLKOUT as SE* falls... they overlap. I think the solution is an edge detector with a delayed pulse. The edge is SE* = CE*+WE* (falls when a CRU cycle begins) So I'm still working on this. I've come with a half dozen ideas that don't work. Here's the 99105 CRU cycle. The cycle on the right is what I want.
  4. So does RORG _RORG1 restore the address count to what it was at _RORG1? It sounds like Ralph is saying that the E/A loader interprets it to add _RORG1 to the first free address and continue there. The listing file should sort that out.. or its a bug in the loader.
  5. What is the effect of these changes? Pin 14, CSW*, has been disconnected from the motherboard. Pin 15, CSR*, is still connected but shared with the AVPC. The theory I see this working under is: The AVPC decodes A12,A13,A14,A15,DBIN,WE* to derive CSW*, CSR*, MODE0, MODE1 Cutting the trace means that the side port can respond to a read from >8800 (VDPRD) or >8C00 (VDPSTA) instead of contending with the 9918's driver. The 9918 outputs data during CSR* but the motherboard doesn't gate it onto the 16 bit bus. Also: The AVPC can allow motherboard writes to the 9918 within the first 16K? Interrupts are no longer synchronized with VSYNC if the 9918 generates them.
  6. I'm struggling to design a wait-state generator that counts 3 CLKOUT cycles. Counting two is easy enough... just clock a flip flop on CLKOUT=low, with input = !output, when each cycle completes. It outputs READY during the 2nd cycle, and the CPU samples that. Unfortunately, it doesn't stop and it gets the next CLKOUT too, which would freeze the machine. I guess I need a count-to-four that stops on 3 and resets somehow.. yuck. I considered dropping the 9901 in favor of separate TTL (re-implementing the 9901!), but the 9902s would be left cold.
  7. Cooperative - well, I'm talking about a single instruction like TB, or the LDCR cycles. Normally a 99110 CRU cycle is 2 clocks (333 ns) and I think I need 1 more wait state, for 500ns.) Nothing else could happen in that time, because the address/data bus AD0 and AD15 are used as CRUIN/CRUOUT. I'll be happy to have CamelForth on it. For starters, the memory map is the same as Stuart's 99110 where the first 32K is ROM, second 32K is RAM. The 99110 only reserves addresses FFFC-FFFF, no onboard RAM. I planned to use Stuart's 9900 FORTH for hardware debugging at first.I'm looking forward to having the FORTH assembler there for doing the testing and debugging! In fact, the machine will always and forever have a built-in FORTH bios. There is actually 128K of ROM and 128K of RAM. 32K of each is the supervisor. The rest is 3 separate user spaces with 32K ROM, 32K RAM too. Just because the bigger chips are cheaper than smaller ones! For now, each extra user space will be like a "cartridge" you can jump into, after the supervisor gives you a FORTH prompt. Privileged instructions jump back into supervisor space. This is just a prototype though. But this initial ROM/SRAM in user space will be "mapped over" when the FPGA is in certain modes (Geneve for example). It could be covered by 4K DRAM pages (up to 32MB) or memory mapped device addresses. That's the mechanism for implementing the Geneve memory map.
  8. Continuing with 9901 to 99105 timing relationships, I calculate that the 6 MHz 99105 has IOCLK* low time of 70ns. The fall time is 13 ns, the rise time is 15 ns. This gives a width of less than 80. According to the 9901 datasheet, the minimum CRUCLK pulse width tw(cc) is 80 ns. This can be mitigated by inserting another wait state on 9901 cycles. Or live dangerously. For the 9902, I calculate the setup time for address before cruclk, tsu(ad) , is 165 ns, but the typical is 220. CE to CRUCLK will be 165ns less ~15ns from a latch, vs typical 180 ns. Hold time for address after CRUCLK squeaks by with 80ns, but CRUCLK pulse width is typical 100, and as above tw(cc) I have just under 80 ns. So that's 3 strikes against the 9902 (at least from the 1977 data manual I have. Maybe I need the 4Mhz variety!) Running at 4 MHz (16 MHz crystal) seems so much safer when operating 9901 and 9902. But it looks like I need to generate a wait state for all CRU cycles.
  9. Yes. I was wondering, if I put a pull-up resistor on CRUIN, how do I measure when a pin goes hi-Z if I don't know if it was outputting a 0 or a 1. I think I need two transistors, one which switches on when CRUIN is high, one which switches on when CRUIN is low.
  10. I'm getting one of these 25W CUI adaptors for $19. It has a 2.5mm barrel plug. https://www.mouser.com/ProductDetail/490-SDI36-5-U-P6 It's way overkill, but I plan to add a lot of other things for a budget of up to 12W. I remember finding a 5V switching power supply in TI's dumpster, long ago, that powered my first 9995 project.
  11. Nope, the 99105 book doesn't mention any other 9900 family. This textbook builds up CRU from discrete chips - priority encoders, 8-bit addressable latch '259 and 1-of-8 selector '151. No 9901. The '151 doesn't have an output enable pin, so it says to gate its output with a '125 tristate with OR(CE*, RD*) connected to its output enable. The 99000 Microprocessor - Architecture Software and Interface Technique Found on: http://www.stuartconner.me.uk/tms99110_breadboard/tms99110_breadboard.htm#references 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?
  12. Exciting! I'm studying Stuart's board very closely for my own version, adding 9901 and V9958. (not sure if the 9901 is going to work.) I got the 99105 from polida2008 on eBay for $33. You can ask him or hth-chips (also eBay) to make a custom eBay listing for you with all the chips you want. I have not verified the 99105 running code yet, only that it powers on and clocks. You can also get 32-pin ZIF for the ROMs on eBay. I ordered those and a bulk lot lot of crystals and discrete components from giorgio11185 (eBay). Happy to share those. The narrow RAMs are nice, but I'm using plain old wide ones. My power supply is a bench supply. If you use an AC adaptor, (or any supply) you should check the voltage rail with a scope. When I first put the 99105 in, it was swinging from 4.75 to 5.25 with the clock pulses, barely in spec. Caps tightened that up.
  13. I'm having a lot of questions about interfacing the 4MHz TMS9901-40 to the 99105 (6 MHz). The 1978 databook covers both the 3Mhz (as in 99/4A) and 4MHz revisions, but I have found no actual examples (the two books I have do not show a 9901 in use.) I want to know the time it takes between /CE (chip enable, low) rising, and the CRUIN output being disabled (yeah, its named after the CPU's CRUIN.) The datasheet gives the time from /CE low to data valid, but not from /CE high to output disabled. The TMS99105 multiplexes CRUIN on the A0 pin, so, any CRU device needs to be off the bus when the next address is output. The textbook by Avtar & somebody says to use a '125 tri-state gate, enabled by the RD* cycle pin, on any CRUIN. I'm reluctant to do that because it means adding an OR gate between each CRU chip enable and the RD* signal, so that's 3 chip delays (maybe OK, if they are the 74F32 OR gate and 74F125, to keep it under 25ns.) LS125.G1* = OR(OR(CE0*, CE1*), OR(CE2*, RD*)) or 3 125 gates with outputs tied together: G1 = OR(CE0*, RD*) G2 = OR(CE1*, RD*) G3 = OR(CE2*, RD*) The routing for this is a mess. If the 9901 and 9902 are fast enough at getting off the bus after /CE goes high, those gates are unnecessary.
  14. So Howard's PBox came out of my garage. I've lost track of who I got it from or when it was last used. I *think* it came from a TI employee in Plano, with a sticker marked "Works", and that I used it to load some Best of HCM disks. When I tested it recently, I got the drive behavior Howard describes, so I made sure he took another internal drive (I figured just the drive was bad). I tested it with an external 3.5 floppy (from mdude) and the controller was able to initialize and use a disk as DSK3. So I don't think the controller is the problem. Maybe the power to the drive? Maybe the drive motors draw more current when they get old and squeaky? I have the same problem now, with a formerly good PBox, which can't initialize or read using a TI original full height, or my last known good TEAC 55-BR from 1984. But the controller works ok with the external 3.5. When I use Kryoflux (floppy disk reader with USB interface board) to control the TEAC-55BR, it works. The drive is fine on external power. On my bench supply, it draws more than 500mA on 12V to start the drive. My bench supply maxes out at 500mA, but once the drive gets spun up, it doesn't need 500 mA. So it's possible that an external power supply for the drive will help. An external CDROM enclosure might be just right. A PC power supply would be worth trying. (For a PC supply, you need the button to switch it on, plus a load to start with. I have a "load brick" to put on the 40 pin motherboard connector. I think powering up a spare hard drive does the trick. See https://www.electronics-tutorials.ws/blog/convert-atx-psu-to-bench-supply.html ) Ugh, external 5.25" enclosures are not easy to find anymore. I found one for $77 http://www.servercase.com/Merchant2/merchant.mvc?Screen=PROD&Product_Code=CK7021&Category_Code=
  15. I’m reminded of using phone lines, to remotely operate equipment in a radio tower. A tone of a particular frequency is robust. One chip on there is a PIC cpu, probably with its own clock. The other chip, 74LS14, is used to translate a noisy signal into digital pulses for the cpu to count.
  • Create New...