Jump to content

FarmerPotato

+AtariAge Subscriber
  • Content Count

    1,644
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by FarmerPotato

  1. 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.
  2. 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.
  3. @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.
  4. 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.
  5. File pipelining, as in Unix. Not the CPU architecture
  6. 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.
  7. 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.
  8. 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.
  9. Aha, there is a perfect spot for that on the motherboard: a power switch terminal I'm not using!
  10. That was fascinating. And free! I want to take a closer look at these PCBs, made at Aisler.net. Vias: Plated Thru-hole via (PTHV) (2.54mm pitch DIP) Here's a closeup of the pulled-out via: Vias look coppery. PTHV looks nickel-y, same as its pad. Estimates relative to the known 2.54mm thru-hole pitch: Via diameter 0.35 mm. Kicad said drill 0.40 mm PTHV diameter 0.90 mm. Kicad said drill 0.80 mm (pad is 2.4 x 1.6 mm oval) Checks out. Parameters at Aisler.net "Beautiful Boards Budget 8-day service" Surface finish: HASL, lead-free ("Hot Air Surface Leveling") IPC Classification: 2. (from that blog, 1=toy, 2=consumer, 3=critical. Aisler can do 3.) Minimal Drill diameter: 0.45 mm $25 for 3x 100x100mm, that is $1.50/3/sqin. My 50x100mm boards were $2/3/sqin. For ENIG it costs 2x, or 3x for ENIG and 2-day service Compare OshPark at $5/3/sqin all sizes, looks like ENIG and their purple solder resist doesn't scratch.
  11. Installed the two Flash ROMs. Current consumption of those is 150+100 mA. And with that, it is pushing the 1A limit. The CPU is running code, but poorly, with no RAM. It is not going to run on this 1A power supply. Time to put the PicoPSU back in. It is the 80W model, the smallest. I estimated 25W for everything I'm going to put in. With the PicoPSU, I lose the ability to measure DC current... hmm, I have a KillAWatt I could use to get the AC power.
  12. Building copy #2 of the BIOS memory card. This is why the prototype shop sends you 3 copies! I test powering up frequently. So far current consumption is up from 450 mA to 590. The SMD are all powered up with a lot of floating inputs. The '645s on the data bus suck 100 mA as the CPU hopelessly tries to get instructions. I think that will go down when ROM/RAM are connected to the data bus buffers. Other chips, not using much power. The rest of the 40mA is from address bus and decoding: '645, 645, 645, 125, 138, 157. A few floating inputs there. My VirtualBench power supply goes to 5V 1A, and I'm worried it will reach the limit with more cards. At that point, I will disconnect its 5V, and plug in the wall wart again. From the 1st card build, I removed a bunch of parts, so the short is isolated to the SMD chips, or the RAM sockets. Most likely, I damaged the PCB under the RAM sockets when I tried solder paste and had to unsolder that. I tried to salvage the ZIF sockets, and for the first time I yanked out vias! These pins had stubborn cold solder joints, and I'm out of that magic stuff that alloys with old solder, so I applied force. <- Coppery vias Owl Pellet -> The right picture is what came out of the desolder tool. I haven't cleaned it during this job. The suction started to fail after 1 ZIF. I ejected the "solder pipe", which stores the sucked-out solder. Found a large cone of solder bits, sintered together! (I crumbled it before I got a picture of Vesuvius, so I'm calling it Owl Pellet now.) The metal disc is probably salvageable (there's a disposable filter under it), but I put in a new one anyhow. Also, the desolder tip was clogged (a cone with a hole in the tip), and I could not unclog it. Lesson: just clean the tool before using it, every time. It has served well for years. Time to reorder the filters.
  13. I'm really glad you are doing this. It must have been amazing to see the UG collection in person!
  14. Yeah, I was thinking of where @TheBF put a DV80 or DF128 command in the MORE pipeline to change the format. Line-oriented TI mode vs Raw mode. I guess it would be fewer changes to the CLI code if it parsed the | pipeline character into separate tasks: One command writes its entire output file to disk CLI executes the next command in the pipeline with that input file So.... just put it on your ramdisk! I see that early Unix wrote the output of each command to a file, before starting the next one. Later, Unix pipes were like a print spooler--if it fills up, the writer is blocked until the reader frees some space. I like the quote about 64K in this question: https://unix.stackexchange.com/questions/450877/how-do-pipelines-limit-memory-usage My thoughts do tend toward making everything more like Unix.
  15. Best of luck preserving this archive! I preserved 200+ floppies from the Milwaukee (Wisconsin USA) area TI users group. I bought a Kryoflux board, then connected it to a floppy drive from the Corcomp MPES. A bit of scripting and I could process the floppies from my laptop. About 30 seconds for each.
  16. Referencing some ideas on implementing pipeline in the CLI. No pipelining, and if I recall > can only redirect output to the console or printer. I've been thinking about how to add pipelining . Some ideas, purely imaginary: Assuming the shell/CLI can be modified to parse a pipeline, special characters | < > Pipelining assumes multitasking, buffered I/O and blocking on read/write. Or does it? Assume that programs/builtins use the MDOS API to read keys and write to console. Assume you're willing to rewrite programs to understand stdin/stdout/stderr In CamelForth, for the MORE utility, @TheBF had a neat idea to switch I/O mode between DV80 and DF128, essentially text and raw mode. New programs that parse the | < or > on their command line, adjust their behavior, and tell MDOS to parse everything after | Imaginary examples: DIR /W > LISTING LS /R | TAR DSK1.BKUP_TAR Baby steps. Assuming these existed already: TAR C:\MYDIR HDS1.OUT_TAR ZIP HDS1.OUT_TAR DSK3.OUT_Z If the CLI saw this cmd line: TAR C:\MYDIR | ZIP > DSK1.OUT_Z It would execute: TAR C:\MYDIR HDS1.PIPES.PIPE1 ZIP HDS1.PIPES.PIPE1 DSK1.OUT_Z that is, append a temporary output file to the arguments, or insert a temporary input file as 1st argument (after switches). of course you just write your batch file to do that... There could be a multi-floppy option for ZIP. It would then prompt the user to change the floppy. Bigger example: CAT NAMES | SORT /A | TAIL becomes COPY NAMES HDS1.PIPES.PIPE1 SORT /A HDS1.PIPES.PIPE1 HDS1.PIPES.PIPE2 TAIL HDS1.PIPES.PIPE2 again, it's just like rewriting the command line into a batch file. Another: FIND /A HDS1.MYDIR | GREP GIF | ZIP H:\BKUP_Z where FIND /A outputs pathnames that don't have the archive bit set GREP looks through its 1st input arg file for lines containing "GIF" and writes to its 2nd file arg Resulting batch file: FIND HDS1.MYDIR /A HDS1.PIPES.PIPE1 GREP HDS1.PIPES.PIPE1 HDS1.PIPES.PIPE2 GIF ZIP /F HDS1.PIPES.PIPE2 H:\BKUP_Z Here assume that ZIP /F reads the names of files from a file (instead of zipping the one file) Essentially, each cmd needs to recognize one input file and one output file - no console I/O intended. Perhaps if they were written from scratch, a convention would be that the CLI inserts arguments to mark input with < and output with >. Position independent, so that implied /F option to ZIP is unnecessary. FIND HDS1.MYDIR /A >HDS1.PIPES.PIPE1 GREP <HDS1.PIPES.PIPE1 >HDS1.PIPES.PIPE2 GIF ZIP <HDS1.PIPES.PIPE2 H:\BKUP_Z Position independent, so this is equivalent: FIND >HDS1.PIPES.PIPE1 HDS1.MYDIR /A GREP GIF >HDS1.PIPES.PIPE2 <HDS1.PIPES.PIPE1 ZIP H:\BKUP_Z <HDS1.PIPES.PIPE2 Conclusion The idea of pipelining is that small programs can be really good at implementing one idea. LS is good at listing directories or expanding globs like H:\USERS\*\DOCUMENTS\* FIND can be good at picking files that match a bunch of user criteria like date modified, name pattern matching. GREP is good at pattern matching ZIP can be good at adding files to a zip, and not support a bunch of fancy options like testing the date modified (that's usually the "freshen" option in ZIP btw)
  17. No pipelining, and if I recall > can only redirect output to the console or printer. I've been thinking about how to add pipelining . Some ideas, purely imaginary: Assuming the shell/CLI can be modified to parse a pipeline, special characters | < > Pipelining assumes multitasking, buffered I/O and blocking on read/write. Or does it? Assume that programs/builtins use the MDOS API to read keys and write to console. Assume you're willing to rewrite programs to understand stdin/stdout/stderr In CamelForth, for the MORE utility, @TheBF had a neat idea to switch I/O mode between DV80 and DF128, essentially text and raw mode. New programs that parse the | < or > on their command line, adjust their behavior, and tell MDOS to parse everything after | Imaginary examples: DIR /W > LISTING LS /R | TAR DSK1.BKUP_TAR Baby steps. Assuming these existed already: TAR C:\MYDIR HDS1.OUT_TAR ZIP HDS1.OUT_TAR DSK3.OUT_Z If the CLI saw this cmd line: TAR C:\MYDIR | ZIP > DSK1.OUT_Z It would execute: TAR C:\MYDIR HDS1.PIPES.PIPE1 ZIP HDS1.PIPES.PIPE1 DSK1.OUT_Z that is, append a temporary output file to the arguments, or insert a temporary input file as 1st argument (after switches). of course you just write your batch file to do that... There could be a multi-floppy option for ZIP. It would then prompt the user to change the floppy. Bigger example: CAT NAMES | SORT /A | TAIL becomes COPY NAMES HDS1.PIPES.PIPE1 SORT /A HDS1.PIPES.PIPE1 HDS1.PIPES.PIPE2 TAIL HDS1.PIPES.PIPE2 again, it's just like rewriting the command line into a batch file. Another: FIND /A HDS1.MYDIR | GREP GIF | ZIP H:\BKUP_Z where FIND /A outputs pathnames that don't have the archive bit set GREP looks through its 1st input arg file for lines containing "GIF" and writes to its 2nd file arg Resulting batch file: FIND HDS1.MYDIR /A HDS1.PIPES.PIPE1 GREP HDS1.PIPES.PIPE1 HDS1.PIPES.PIPE2 GIF ZIP /F HDS1.PIPES.PIPE2 H:\BKUP_Z Here assume that ZIP /F reads the names of files from a file (instead of zipping the one file) Essentially, each cmd needs to recognize one input file and one output file - no console I/O intended. Perhaps if they were written from scratch, a convention would be that the CLI inserts arguments to mark input with < and output with >. Position independent, so that implied /F option to ZIP is unnecessary. FIND HDS1.MYDIR /A >HDS1.PIPES.PIPE1 GREP <HDS1.PIPES.PIPE1 >HDS1.PIPES.PIPE2 GIF ZIP <HDS1.PIPES.PIPE2 H:\BKUP_Z Position independent, so this is equivalent: FIND >HDS1.PIPES.PIPE1 HDS1.MYDIR /A GREP GIF >HDS1.PIPES.PIPE2 <HDS1.PIPES.PIPE1 ZIP H:\BKUP_Z <HDS1.PIPES.PIPE2 Conclusion The idea of pipelining is that small programs can be really good at implementing one idea. LS is good at listing directories or expanding globs like H:\USERS\*\DOCUMENTS\* FIND can be good at picking files that match a bunch of user criteria like date modified, name pattern matching. GREP is good at pattern matching ZIP can be good at adding files to a zip, and not support a bunch of fancy options like testing the date modified (that's usually the "freshen" option in ZIP btw)
  18. 2 MOhm is typical for ICs before power is on. Impedance is a natural term when there are active components like transistors or stored energy. My power supply protection kicks in at 1A and V falls to 2V. Ideas: One of the SMD caps or resistors shorts out when power is on Some of the 8 soldered ICs are bad. (I removed all the socketed chips first.) Really bad case of a floating input making an IC switch on/off madly Get an elf with infravision who can point out the hot spot If only there were some kind of cheap paper that changed color with heat.
  19. The current difficulty: I built the BIOS card and finalized the PLD chip. When I power on, it is apparent that it has a short. Right off, the impedance from VCC to GND is 2 MOhm. So the problem must be with some chip, huh? The PCB has some solder mask damage from that incident where I had to desolder 3 sockets. Fun thing: when touching the leads of a 0805 capacitor (0.1uF) my cheap multimeter says 350KOhm. Now that the cap is charged up, remove probes, reapply, it goes back to 2MOhm like other sensible traces. I've been over the whole board looking for solder bridges, poor solder joints, leftover solder paste or such. Reflowed all the SMD pins. Cleaned it up real good with isopropyl and a nylon brush. I realized at last that stray fibers come from my old flux pen, not the electronics wipes. Must replenish flux! I'm about to give up on it and build another card, testing it in between each part.
  20. That's certainly a good solution. The XC9572 appear in Jaime Maililong's NanoPEB cards. Though I have one with an XC9536, like his older CF7+ cards. Jaime soldered a PLCC onto the board (XC9572PC44A). Jaime's product was unusually prone to static discharge killing the XC9572, and only the older models used a socket for replacement. 3.3V is not a problem for me--I already change my 5V bus buffers/drivers to the LVC245A when interfacing to 3.3V. I value the option for customers to do their own updates, or ask for just the programmed chip. Sockets are preferable, but a Pi is reasonable (asking someone to buy a JTAG cable is not.) I assume someone to have a TL866-Plus or XGecu for programming flash, but for CPLD, those are limited to the ATF22V10.
  21. Cute! For XB. CALL LINK(“CURSOR”) replaces the cursor with a tiny Texas image.
  22. The LS157 forms this memory map: A14 A13 Selects 0 0 ROM 0 LS157 outputs all 0 on A18..15 0 1 ROM 1-7 LS157 outputs Q2..Q0 on A17..15 1 0 RAM 0 LS157 outputs all 0 1 1 RAM 1-15 LS157 outputs Q7..4 on A18..15 LI R12,>2100 LI R1,>1100 LDCR R1,8 set ROM page 1, RAM 1 A14..A0 are opposite from TI convention, with A0 the least significant bit, addressing a 16-bit word. pages are 16K bytes. Chips are 128K bytes. Only half the ROM is addressable The ROM has address bits shifted up, and A0 is wired to even or odd word. (Two identical images.) ROM page 0 contains interrupts, XOPs, Macrostore 1000-1FFE, and BIOS code. RAM page 0 contains workspace registers and working storage for BIOS. All interrupts and XOPs leave user menory and go to BIOS ROM, because the cpu takes PSEL* bit high . NMI /LOAD is still unpredictable. The VDP card overrides access to >8800, 8C02, F100 etc by asserting BMO*, bus master override, when GPL or MDOS mode VDP bit is set. Makes holes in RAM page 0. Otherwise, the VDP responds to CRU parallel at those addresses. The next version of this card will copy ROM into RAM for modification, force page 0 for NMI, and allow byte addressing.
  23. This is the GUI of WinSIM. The green inputs must produce the blue outputs. The red signals are fails. In this case, I moved Q3..6 to Q4..7. I have spent far too many hours clicking to edit these little cells. Fortunately, WinSIM inputs are just text files. I also reproduced WinSIM's GUI in LabVIEW, intending to connect the VirtualBench digital I/O, to a PLCC28 adaptor I made. That was a miserable chore, too. The XGPro logic tester is also ugly, but does the whole job.
  24. The 22V10 plus external LS157. The 157 saves on messy traces by multiplexing the ROM or RAM upper address bits and chip select. On 22V10, a register output always goes to the pin. If you want additional logic on it, you need another output pin with the equation. So the 157 saves 4 output pins, and 1 input for A14. I can see future use of the ATF1500 PLD, which has 32 I/O instead of 22, and a lot more stuff inside. And is supported by newer tools. I will not miss the 22V10 and WinCUPL.
  25. Finally! A 22V10 CPLD is perfected, after countless painful hours with WinCUPL and XGPro (among other tools I did not love). The 22V10 replaces a few logic chips, and the effort was far too much. The 22V10 replaces chips LS259 and LS251 (8-bit CRU register and addressable read-back), a LS04 NOT gate, and a LS27 triple 3-input NOR. All in $3.05--a little more than the 22V10. A lesson learned: Forget the PLCC28 version. The DIP24 version of 22V10 takes up the same amount of PCB area, is easier to insert/remove, and just looks better on a PCB. It will be much, much easier to route. XGPro (TL866II-Plus) really proved valuable. While taking 8 hours to get through the Logic Tester stage, I found a bad bug in my CUPL. At some point I did not update two of the pin numbers to match the final schematic! Here are the XGPro logic tester inputs and outputs: 1 and 0 are inputs. L and H are outputs. If an L or H doesn't match, it turns red. Lines 1-14 test the setting of CRU bits, Q0-Q6, output pins 15-21. Line 15-17 test MEMSEL* output, which indicates a memory cycle to the BIOS ROM/RAM. Here are the pin numbers if anybody cares to decipher that. My notes: DIP24 pins: 1 clock WE 2 2 I0 A0 3 3 I1 A13 4 4 I2/PD BST2 5 5 I3 BST1 6 6 I4 MEM 7 7 I5 PSEL 9 8 I6 A10 10 9 I7 SEL2100 11 10 I8 D0 12 11 I9 A1 13 12 GND 13 I10 A2 14 IO9 MEMSEL 17 15 IO8 RAMPAGE1 18 Q4 100 16 IO7 ROMPAGE1 19 Q1 001 17 IO6 RAMPAGE2 20 Q5 101 18 IO5 ROMPAGE2 21 Q2 010 19 IO4 RAMPAGE0 23 Q3 011 20 IO3 RAMPAGE3 24 Q6 110 21 IO2 ROMPAGE0 25 Q0 000 good 22 IO1 CRUIN ! 23 IO0 NOT_A13 ! plcc pin order: 25, 19, 21, 23, 18, 20, 24 24 VCC ! PLCC PIN------------/ This is the CUPL description of a LS259 8-bit register. LS259 is expensive for some reason, so the 22V10 pays for itself here. Only using 7 bits here. field output = [Q6..0]; /* internal 8-bit register */ field sel = [A2..0]; /* bit read-write selector */ /* next state logic, for clocked registers */ output.d = [Q6, Q5, Q4, Q3, Q2, Q1, D0] & sel:0 & CRUEN # [Q6, Q5, Q4, Q3, Q2, D0, Q0] & sel:1 & CRUEN # [Q6, Q5, Q4, Q3, D0, Q1, Q0] & sel:2 & CRUEN # [Q6, Q5, Q4, D0, Q2, Q1, Q0] & sel:3 & CRUEN # [Q6, Q5, D0, Q3, Q2, Q1, Q0] & sel:4 & CRUEN # [Q6, D0, Q4, Q3, Q2, Q1, Q0] & sel:5 & CRUEN # [D0, Q5, Q4, Q3, Q2, Q1, Q0] & sel:6 & CRUEN # [Q6, Q5, Q4, Q3, Q2, Q1, Q0] & sel:7 & CRUEN # [Q6, Q5, Q4, Q3, Q2, Q1, Q0] & !CRUEN; output.sp = 'h'00; /* synchronous preset not used */ output.oe = 'h'ff; /* tri-state control always on */ output.ar = 'h'00; /* asynchronous reset not used */ /* Readout of registered bit (cru input of the cpu) */ CRUIN = (Q0 & sel:0) # (Q1 & sel:1) # (Q2 & sel:2) # (Q3 & sel:3) # (Q4 & sel:4) # (Q5 & sel:5) # (Q6 & sel:6); Clock is WE* and 22V10 can't use an equation for the clock, only a single pin. OK. So the next-state logic for Q0.d includes the enable logic: "are we on a CRU cycle addressed to us? then D0. Else Q0." And WE* always clocks all registers. But WinCUPL compiles this puzzling code into the .sim output. Why the !Q0 input? I do not understand the .sim output. Fortunately, WinSIM still gives the correct results, and the chip works, so... Q0.d => !A0 & !A1 & !A2 & D0 & !SEL2100 # A0 & !A2 & !Q0 & !SEL2100 # !A0 & A1 & !Q0 & !SEL2100 # !A1 & A2 & !Q0 & !SEL2100 # A0 & A1 & A2 & !Q0 & !SEL2100 # !Q0 & SEL2100 Here is the original NOR logic for MEMSEL*. It unifies general ROM with macrostore. Takes up one LS27 and part of LS04. Originally, it was LS04 and LS27 NOR to produce the MEMSEL* by unifying general memory access and external Macrostore access. I was pretty happy with fitting this on the LS27. But the CPLD is superior.
×
×
  • Create New...