Jump to content

FarmerPotato

+AtariAge Subscriber
  • Content Count

    1,650
  • Joined

  • Last visited

  • Days Won

    1

FarmerPotato last won the day on June 30

FarmerPotato had the most liked content!

Community Reputation

2,328 Excellent

About FarmerPotato

Profile Information

  • Gender
    Male
  • 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

5,641 profile views
  1. To summarize how it can be done: First, it’s code that can be in ROM. You assemble it in 8K chunks with AORG >6000 at the top. Every file has the same stuff at the top, a bunch of “trampolines” which are code to flip to a page and branch to a routine in it. If all the banks have all the trampolines, it’s easier to code. You need one shared source file with all the trampoline addresses. @retroclouds document shows a good way to keep track of trampoline addresses. TI had a bunch of directives to link shared libraries at load time, but those aren’t implemented in any loader for the 4A. on the Geneve, with GENASM, trampolines are a piece of cake, it’s just one setting in your Makefile to declare banks, then the linker does the real work.
  2. Doing it all in 16K is one of the creative limitations with the F18A! You want to use all the features—3bpp, separate sprite pats, two scrolling pages, BML! But you have to allocate budget 16K and make compromises. I find that it gets me thinking, and the trade offs are still fun, more fun than being stuck with 9918A.
  3. The 12V5A adapter arrived (I have lost my original.) Geneve 2020, powered by its actual enclosure, has 4.95V average on the 5V rail. There's a bit of noise: RMS 5.09V. The BIOS card is still emitting FFFF on the databus during read cycles. Can't get these test clips to stay on: 16 and 20 pin Test clips from Pomona for SOIC (1.27mm) Maybe it is my solder joints. However, I got a 8-pin test clip out of NI's dumpster long ago, and that works like a champ. I checked one of the data buffer chips, LS245 type. I measured bus signals Bus to LS245 RDBENA* -> DIR (pin 1) B_D9 <--> A1 LS245 to BIOS Board OE* <- MEMSEL* B1 <--> D9 On the bus side: I see the CPU makes RDBENA* pulse low which is DIR. Low DIR means B1(internal) goes to A1 (bus). (High DIR means A goes to B.) I see B_D9 (bus D9) at 1. Whole data bus goes from 0000 to FFFF while RD* and RDBENA* pulse low. On the board side: I see MEMSEL* (OE*) staying low according to the address and bus MEM* (memory access) decoder in the 22V10 PLD. Good. I see D9 (internal D9 data) always 0 during a read cycle. BAD. Because data bus shows FFFF. So definitely the 245 is NOT driving the bus, when the OE* and DIR signals are correct. I almost though that DIR was backwards. Triple quadruple checked. WHY? Fried chip? This worked fine on the wire wrap board, so it can't be a problem with the CPU card. EDIT: A forum post at TI.com listed some possible mistakes leading to misbehaving '245. I'm going to check with the analog probes, not just digital inputs 0/1 that might be floating.
  4. Saturday Pandemic club channel is active today during the TI Faire (especially during the technical difficulties) For easy reference: Saturday channel https://us02web.zoom.us/j/88092618677
  5. Some of us are chatting on the Saturday pandemic club link. For easy reference: https://us02web.zoom.us/j/88092618677
  6. I plan to attend in 2022. Not going places outside my pod yet. I’ve been working on a video about the TI Archive but it’s hardly ready.
  7. Indeed @wierd_w controlling a plotter with HPGL is no problem from BASIC. My brother immediately saw the usefulness of our high school’s HP plotter, borrowed it, and wrote many routines in TI BASIC to plot conic sections. Those became components for assembling a parabolic dish and other experiments. It’s just text after all.
  8. Is that disk label also made by TexComp? I imagine the TI original at least being brown? I’ve never seen a Not-Polyoptics disk or cassette.
  9. @speccery I like the wire wrap. In 1989 I only had one color, too: pink! Wire-wrapped my own 9995 board. maybe like you, I wrote to TI asking about the TMS340, but they only sent back glossy brochures. Did you get free sample chips? My 9995 board didn’t get me a job, but I did win a memorable trip from city-level to state science fair, exhibiting “Udo: the 16-bit Microcomputer”. looks like I wrote a TLDR; here, feel free to not indulge my digression. TLDR; My dad worked for TI and introduced me to several engineers. For the 9995, I robbed an irreplaceable Mike Read one-off bar code scanner. (TI engineer who went also worked on 9900-based HARM missile.) Wish I had that barcode reader now, cuz I just found hundreds of speech bar codes for it, buried in my dad’s basement. Yamaha sent me a 9938 chip sample, unaware that it was just a teenager who wrote asking about it. For the 9938, I had, and never returned the 21.77 MHz crystal, which came out of Nick Hulbert’s HAM gear. (deceased TI engineer. Author of a TI technical book?) Nick also lent me his EPROM programmer for burning 2532s on the 4A. He kept my Apple II floppies, but still hardly a fair trade. (I feel weird that he passed away while I had his stuff.) Everyone I met was so generous in time, knowledge, and parts. Can’t remember the name of the engineer who loaned the wire wrap gun, fixed up the 9938, guided me in how to draw a proper schematic, and taught me to use his oscilloscope. (Which scope I had to return before the state science fair, alas.) To use the shrink-DIP 9938, he proposed a machine pin 64-pin socket a la 9900, a chunk of wood, and very short wire wrap from the 9938 soldered to each of the socket pins. That took hours to make. I never understood video out. I connected composite out, directly to a monitor. No way could that ever sync up. 9995 from the bar code reader: Better than stealing the 9995 from a 99/8, made available by another TI engineer. Now I know that the >F000 RAM is disabled on the 9995 from the 99/8. Drove me crazy trying to start it up until I tried the “normal” 9995 from the bar code reader. still have what’s left of my board, esp the 9938 adapter monster, and the 2532 EPROMs. Alas, I later started to tear it down, to start an all new one, so it can’t run. Yours looks complete and very tidy.
  10. What I want is a process. Currently I do all drafting in CorelDraw. It integrates to the two types of laser driver, no issues (Inkscape not so much.) But It’s more tedious than creative, for mechanical drawings. In CorelDraw, I maintain front, top, and side views with interlocking features. Line segments are color coded for laser power and sequence of cuts. (For instance, drills first, then internal cutouts, markings, lastly outside perimeter cuts.) I calibrate speed and power for each situation. maintaining the drawing is horrendous —when I realize I need to move a bunch of everything by 1.2 mm. I’ve built up a parts library, but I find that the only way to stay precise, is to constantly calculate and enter X and Y offsets or centers. So I do calculations on paper and spreadsheet for stack-ups… that’s where a 3D model would be nice. And my favorite kind comes from typing all the numbers (NO mousing) and that’s OpenSCAD. I like OpenSCAD. I can be creative there. But I think that to slice, you must rely on exporting, say to FreeCAD (what the OpenSCAD FAQ suggests for any features not in SCAD…) Another ordeal is that: whatever does the slicing, needs to carry the units all the way through, keep geometry, and somehow color code the types of cuts. Slices must produce long vectors and arcs, not gobs of tiny segments. To drive the laser, any export must come back into CorelDraw (DXF for instance) with correct units AND origin not screwed up. Or I spend too much time fixing the garbage DXF before cutting—then do it from scratch again. Command line tools would be better than any GUI for repeatability. So I’m looking for a process, and it’s going to take some time to explore how to slice, then how to streamline doing it for each iteration. Recreating my drawings as a 3D model is the fun, creative part. It must be streamlined. Laser time is precious. Often I make edits and re-cut several times in a session. Both to alter the design a bit. Mostly, fixing tolerances: add some for the fit of tabs and slots, calibrate hole sizes to account for how clean the plastic ended up, or enlarge tiny draft angles or fillets. And I might manage this separately for two plastics. Though the top view is now only acetal, having graduated from Cheerios box to acrylic to acetal. Front and sides are still acrylic. Acetal has been tough (haha) because it warps easily, and so I learned to use many passes of the laser on acetal. Acrylic cuts beautifully, but has little strength. Snap-fit parts going into acetal is good, but the pressure shatters acrylic.
  11. File pipelining, as in Unix. Not the CPU architecture
  12. Moving to the picoPSU power supply, which I last used to test the fans. I can't find the 12V 5A brick. Melancholy late night. I worked on the enclosure for a while. It required some modeling clay, painter's tape, and several screws. I remember how much fun it was to design, laser-cut (acetal and acrylic), and build the enclosure. But it has many parts that don't quite fit together, once the actual power-I/O PCB is in there. Must re-draft all the CorelDraw files of the plastics. Yuck. I wish I could do it in SCAD and export a 2D profile. The acetal floor parts, I've solved most of the warping (from laser cutting.) But there are unsolved problems. What I struggle with is: mounting the fans to the side panel (I'm particularly proud of the slotted floor. I read a lot of catalogs to select those Bivar rails to guide PCBs into the backplane.) building vertically or anchoring boards at right angles. Left: PCB with picoPSU, front panel MIDI x2/keyboard/mouse/sound ports, headers for fans, headers for all the ports, power switch, and whatever needs 3V3+5V in the front panel. Right: fan hanging on 1 screw and clay. Look at the ports panel behind any PC motherboard--it has stacks of connectors. Those aren't all commodities I can find. Also, my front panel is 75mm wide and 120mm tall. My best idea is to make a stack of 3 circuit board sandwiches (thanks whoever showed me that technique). Then, to resist the force of inserting plugs, right-angle screw brackets to the front panel. But those eat precious space (10mm each.) 75-20mm = 55mm, very tight for 2 SD cards across a little PCB. AND I need to shift everything left by 10mm, squeezing that space to just 45mm between screws. Stacking metal risers doesn't save much space. Still, I have an idea that will eliminate internal cables and create a back panel. So some ports will move to the back, like VGA, MIDI, serial. (Only a laboratory computer would have a VGA on the front!) Hammond 1458 enclosure (mine is 1458VG5B) Later, I've got to use CNC milling to cut out the final, metal front/back panels. Two metal panels come in the Hammond enclosure kit . But I am no good at setting up CNC jobs, so I'll need someone more skilled. Until then it's the CO2-laser-cut, acrylic front prototype. No, a CO2 laser can't cut metal. You need a UV laser to even cut it a little. Hmm, the metal is anodized, so I can laser engrave that. The thought makes me happy. This enclosure got me thinking. Nah. NONE of my cards fit in there. Maybe this one? Nope.
  13. Yeah, I thought through both of those paths. Implementing blocking I/O is the Unix way, but PAB I/O doesn't do blocking, and not know the difference between pending and true EOF. So, semaphores could indicate that a record is ready, using the ABS instruction in shared memory. I'm not sure if it's even legal to open the same file for read and write, or if it needs a whole new concept of piped-file-in-memory. So why not just share data, too, in the shared page... That requires the program to know two modes, pipeline and file/console output for the final stage. Using complete temp files is the other way, and requires mostly changes to the CLI, or a whole new shell.
  14. I don't get why this board draws more power than the wire-wrap version. That version lacked the bus buffers/drivers, and the PLD. The WW version had the same two Flash ROMs and static RAMs, and consumed about 300 mA. The current of this board went up 250 mA just from the two flash ROMs. 550+ mA in all. It runs, sort of, with the RAM installed. Current is maxed out at 1A, and supply voltage drops to 4.5V. The CPU seems to keep at it, but it is getting >FFFF back from reading the ROM. I have a 8-pin SOIC test clip, and that's going to have to suffice for testing. Still hunting for that darn 12V 5A brick for the picoPSU. Not sure what happens if I find a 12V 3A, but draw too much from the supply. They do rate this picoPSU at 85W, but ship it with a 60W adaptor.
  15. Aha, there is a perfect spot for that on the motherboard: a power switch terminal I'm not using!
×
×
  • Create New...