Jump to content
FarmerPotato

What if? Designing "Geneve 2020". Cool 3D views!

Recommended Posts

Because I plan on using my TI stuff, for 30 more years, I'll pay for machine screw sockets - every single time! 😃

One of the things I love about SNUG boards, Michael Becker, made them to last.

  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)
On 5/10/2021 at 6:43 AM, Ksarul said:

This is one of the main reasons I generally sell my boards assembled--it allows bulk buys for most of the parts, significantly reducing the build cost and keeping the board prices reasonable.

I took a look at my BOM so far. Bulk savings looks like 8% on the big items. But there are real savings from shipping charges: there are a dozen sources.

 

Bad news for me:  I was shocked to discover parts that are out of stock!

 

  • iCE40HX4K-TQ144 is out of stock for a year maybe! This is the only non-BGA version of my FPGA. I can substitute the iCE40LP (or LM) and probably the 1K size. But those are also scarce. My little stockpile was 3 chips, now down to 1.

 

I am seeing the semiconductor crunch on multiple fronts. (It's not so much a shortage, as an increase in demand.)

 

  • A dev board, that I was eyeing, is now unobtainable. I placed a back order at the 20% higher price.

 

  • The audio amplifier part, OPA1688: 10K stock vanished while I took a week to simulate the circuit in PSPICE.

 

  • TMS99105. (eBay) Qsourceco_6 was my preference for new old stock at $33 each/$30 bulk. Now they are $40 for qty and $48 singly. (eBay) Polida2008 still offers $33. My stockpile of these is 6 chips. (BTW Qsourceco_6 has a US trove of NOS gold/ceramic chips!)

 

  • Memoryx.com has folded. This was my source for cheap, new, plentiful DRAM.  The new owner of the domain sells memory on eBay, and it is awful. I'm talking about 30-pin SIMMs. Because retro.

 

  • qsourceco_6 has an expensive pile of new XC9572-10TQG100I, 5V tolerant FPGA, hobbyist-friendly, that normally cost $5 new at mouser. But you have to get in line at the distributors.

 

I found MemoryMasters on newegg, they appear to have the same business model, but no good way to find a part. Like memoryx, they also sell 2x16MB for $30. 2x4MB is no longer cheap and 2x1MB is gone. Maybe I'll drop the idea in favor of a boring SDRAM after all.

 

Anyway, today it's back to progressing on the VGA upscaler for the 9958... which depends on that iCE40 part. I checked and (eBay) ic_detective is still selling the other main part I got. But stockpile!

 

All of these surprises are probably solvable, but what a headache.

 

Edited by FarmerPotato
  • Like 1
  • Sad 3

Share this post


Link to post
Share on other sites
22 hours ago, dhe said:

Because I plan on using my TI stuff, for 30 more years, I'll pay for machine screw sockets - every single time! 😃

One of the things I love about SNUG boards, Michael Becker, made them to last.

Wait, you prefer machine pin sockets?

 

Those drive me crazy! I broke pins on an EEPROM, while trying to put it back into a machine pin socket.

 

Still, bring your own sockets! Not an issue for me.

 

  • Like 1

Share this post


Link to post
Share on other sites

Even after many years of use, thermal expansion won't walk the chips out of these sockets.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

Audio Block Diagrams

 

I was checking chip availability today, and found an intriguing possibility.

 

So far, this is the current model for the audio card:

 

image.thumb.png.27ddd271763d50d40a65bce4ee248df0.png

 

 

 

Today, I saw that ic_detective has AD1888 chips for $5. This is a full PC AC'97 audio codec, made in 2005. AD1888 could replace a bunch of chips and result in input/outputs like this:

 

 

image.thumb.png.d442b4a37e0545fbdba2204b973ef5e6.png

 

 

With or without putting in all the extra features, the AD1888 saves a lot of hassle. I omitted my extra analog-out patch jacks, which had been a fun idea.

 

 

 

 

Edited by FarmerPotato
  • Like 4

Share this post


Link to post
Share on other sites

I bought a few TMS99105s from Qsourceco_6 last November, when his prices were lower. I was a bit surprised by the price increases when I went to look at getting a few more this past weekend. . .

  • Sad 1

Share this post


Link to post
Share on other sites

But, you've removed "Phono out". You're not eliminating the stylus?:evil:

...what will people say???:D

 

   P.S. Glad you're keeping-at-it.;-)

 

   P.P.S. For HI-REL, I always solder. ...Otherwise, I, too, swear by machined-pin sockets.:ponder:

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, HOME AUTOMATION said:

But, you've removed "Phono out". You're not eliminating the stylus?:evil:

...what will people say???:D

 

   P.S. Glad you're keeping-at-it.;-)

 

   P.P.S. For HI-REL, I always solder. ...Otherwise, I, too, swear by machined-pin sockets.:ponder:

The stylus is still buried in there, but it only plays 1 millimeter LPs.

 

It's a secret of the AC'97 committee. They didn't want to talk too publicly about it in the 90s. But now phono is cool...

 

 

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites
Posted (edited)

Working all week on Geneve 2020 -- No kids!

 

Semiconductor shortage update:

 

The dev kit for Lattice ECP5 was delivered today. This isn't related to Geneve 2020. It was for resume building. It is the only inexpensive FPGA development board with PCIe (and it is 3 years old "obsolete"). It is perfect if you want to learn to write a Linux device driver for PCIe. Use any of the peripherals onboard, or build on the prototyping area. The available stock vanished in May, with backorder time 8 weeks, but I got mine after 5 weeks.

 

Lattice FPGA ICE40HX4K-TQFP144 at Mouser are still expected in August, but in small quantities (300). (LM4K and LP4K don't come in hobbyist-friendly TQFP-144, only ball-grid. Must get TQFP package.) The 4K unlocks to 8K in IceStorm, which is terrific. I ordered and received 10 of the 1K parts, which are probably adequate. The VGA up-scaler fits in 1K, so far. 

 

I can use a 1K in each place that FPGA is needed, instead of sharing one big 4K part. Sharing was always going to be awkward, since 3 cards needed the FPGA: dynamic RAM controller/memory mapper, audio (digital mixing, I2S bus to DAC), video (to drive VGA output and new video mode). Substituting 3 1K chips for one 4K chip will add $16 to the bill. (chip+flash+oscillator+voltage regulator) 4K: $6.31 (less than qty 25) 1K: 

 

OPA1688ID, TI audio amplifier:  Digi-Key has none, Mouser has a stub end of a reel of SOIC-8, and lots of unfriendly SON-8 (pads under the package). Some 2,000 coming in June/July, but past stock levels had been 10,000. I have 10. NO PROBLEM: TI.com has lots of SOIC-8 for $1.07.  Also, I've begun soldering SON-type and it's as easy as SOIC-8.

 

CS4334 Cirrus audio DAC. Available at Mouser, for now. Several CS43* out of stock. Restock, including automotive grades, not til December! Been using this chip from the start.  But there are lots of DACs out there from Analog Devices and TI. CS4354 is fine too and cost under $3. Both are TSSOP parts (0.65mm) though.

 

For instance:  PCM1725. For $3.60 direct from TI in qty 1. SOIC-14 (1.27mm) that has I2S interface (like the Cirrus chips) with integrated amp. $6 at Mouser.

 

CS5343 audio ADC. Very little stock. Expected 2022. The ADC function  (mic, line in) is not designed yet anyhow. There's an 8-bit ADC on the YM2608 sound chip too. I think 8 bit is "retro correct", but still, 16-bit stereo samples were common by the 90s.

 

 

OK too much time shopping (and I'm not being considered for the Linux device driver job anymore.) Back to work, I've got 5 glorious days alone.

 

Articles on the semiconductor shortage:

https://semiengineering.com/shortages-challenges-engulf-packaging-supply-chain/

https://arstechnica.com/gadgets/2021/06/chip-shortages-lead-to-more-counterfeit-chips-and-devices/

 

6/18 Update: of the 10 ICE40HX4K-TQFP144  that I ordered, Mouser has allotted me 6 chips in December. They promise me 4 chips in March 2022. They advertise 400 back in stock in March. This tells me that they don't advertise expected shipments that are already spoken for. I infer they may get stock every quarter, but June, September were already sold when I ordered.   I am going ahead with planning the multiple 1K chips. 

 

6/25 Update: Mouser now has higher estimate for December, so I get 10 in December. All told, just 1200 chips available over the next year... Even fewer in the ball-grid packages (scary).

 

7/14 Update:

 

Mouser pushed back availability of the 4K part to March 2022. No parts in December. 

Edited by FarmerPotato
7/22 Update availability
  • Like 6

Share this post


Link to post
Share on other sites

Development continues, with some snags.

 

One is the ongoing semiconductor shortage.

 

My FPGA is backordered to March 2022, doubtful that. I hoarded 111 smaller FPGAs, which actually makes sense because then they can go on separate cards by function. 

 

The oscillators for the FPGA are out of stock, probably find an equivalent.

 

The audio taper is out of stock (digital pot, 32 values, logarithmic not linear) . So is the audio DAC I was using (CS4344) and the TI audio amplifier (OPA1688). Ugh. A TI part for the DAC will work, but cost more.

 

The small, parallel 8K FRAM (non-volatile high speed memory) which I was suggested to use, is out of stock. Still have the serial access one (slow, for persisting parameters through serial LDCR, but not MOV.) The serial access FRAM is enough to save and load configuration paramters, 1K bytes.  

 

I am going ahead with my 10x10 cm boards by function, since I have the PCBs. They are designed for Kontron (1977) / retrobrewcomputing.com ECB backplane.

 

BUT I want to redesign all of them to use TI's E-BUS backplane. That offers several advantages. First, it's designed for 99105 or 8086. Fewer pins (address and data multiplexed.) The interrupt structure is useless to me though. The entire B row (32 more pins) is unused and I'm going to route all the peripheral ports through it! This saves a bunch of cable connectors and ugly ribbon cables which are tough to install (like installing the floppy cable in the P-Box.)

 

E-BUS is intended for self-contained CPU cards plus interrupting peripherals--not for accessing main memory. But I'm ditching the interrupt and bus arbitration, in favor of simple backplane, with main memory and peripherals on the backplane. (like P-Box.) Otherwise, it's got TI's blessing for RF interference and termination. And extensive guide to bus loading calculations (albeit, before CMOS chips which are much more efficient.)

 

The routing over the B row is the best advantage.  This means VGA, sound, keyboard, mouse-- all travel from their front AND back panel ports, over to the peripheral card they connect to. No messy cables. And the back panel ports card just plugs into the backplane. (the front panel needs one big cable.)

 

So, there's the update.

 

The 9902 is still giving me trouble. Thanks for the suggestions (on the debugging thread.)

 

 

 

 

 

 

 

 

 

 

  • Like 3

Share this post


Link to post
Share on other sites

Also, after feedback from @dhe I’m changing all DIP sockets to machine pin instead of double-wipe. Got over my dislike for machine-pin and mangling new chips.  I get the ROM chips in and out frequently for programming. I found a surplus factory pin bender tool, which sounds helpful. 
 



 

 

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

Just now discovered this awesome project - I don't know how I managed to miss it before. Probably due to it being Geneve related, not TI-99/4A... It would appear I could probably adapt my existing TMS99105 FPGA system to be Geneve compatible. One of the other interesting aspects here is that you seem to be using the BlackIce 2 board - I have also used those and they're really nice. I've yet to design an extension PCB for it, to include 3V-5V converters and other such stuff. What you've done is inspiring indeed :)

 

Edit: what were the smaller FPGAs you @FarmerPotato refer to? ICE40HX1K? Sorry haven't read this thread, there seems to be a ton of stuff here. In one of the previous messages you mentioned the TQFP requirement for FPGAs, I have acquired (before they became sold out) a few ICE40UP5K-SG48I chips. My intention is to get them mounted on a PCB, let's see how difficult that will be :)

Edited by speccery
  • Like 2

Share this post


Link to post
Share on other sites

The substitute is indeed ICE40HX1K. It gives me 1280 LUT instead of 7680 (4K part with Icestorm.) and cost more given 3 not 1. But my verilog will fit, so far, broken up by function. 

  • Like 2

Share this post


Link to post
Share on other sites

Lesson learned:  Solder paste should not be used on thru-hole components. I thought hot air was, uh, cool.

 

I had 6 bridges under sockets. But thanks to Hakko FR-300, all components came off the board cleanly, leaving nice shiny pads on which to start over. 

 

I imagine QFN part nightmares are like this.

 

  • Like 3

Share this post


Link to post
Share on other sites

The BIOS card, now graduated from wire-wrap.

 

Ugh, I installed the PLCC-28 socket 180' off.

 

The BIOS card is for the supervisor mode. 128K ROM holds all the supervisor code, with 256K RAM workspace. This BIOS supplies all the interrupt handlers, XOPs, macrocode (99110 floating point), the "executive" monitor (FORTH!) and what I am calling a micro-kernel.  Also ZORK (just kidding) (not kidding.) 

 

Bank switching done by that little 10-bit PLD.  '259 is for 8 pretty LEDs. The screw mounts are for a pretty front panel. 

 

To be clear, user programs (GPL, GeneveOS) are loaded into main memory, up to 32 megabytes, which is a separate card.

 

BIOS-1.thumb.png.6afb362a95acf5098c0ef08bc676e032.png

 

The form-factor is 100x100mm, semi-Eurocard. This one is for Kontron backplane (retrobrewcomputing.com ECB)

Future path may be 100x100mm cards for hobby-friendliness, or regular single Eurocard 100x160mm.

 

 

  • Like 11
  • Thanks 1

Share this post


Link to post
Share on other sites

I know the issue with the PLCC socket installation. I usually just tack two pins and then double-check that they are oriented correctly. That saves me a lot of desolder work when something is wrong. . .

  • Like 2

Share this post


Link to post
Share on other sites

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:

 

image.thumb.png.be32c3934eee04c9a6170907eb68af02.png

 

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.

 

image.thumb.png.74cd1f1f139103b384b6bf886e859fde.png

 

 

 

 

 

 

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.

 

 

 

  • Like 4

Share this post


Link to post
Share on other sites

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.

 

 

 

image.thumb.png.c7a75566a1298d01c56f5fd67663c2f9.png

 

 

  • Like 4

Share this post


Link to post
Share on other sites

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.

 

image.thumb.png.b707baf45d858e643186077d93336efe.png

 

  • Like 4

Share this post


Link to post
Share on other sites

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. 

 

  • Like 6

Share this post


Link to post
Share on other sites

For what its worth a quick suggestion as far programmable logic is concerned: I just ordered more XC9572XL chips from mouser. Amazingly they are plentifully available at the moment. XC9572XL-10VQG44C - that's a very easy to solder SMD package in my opinion. I've used the 100 pin XC95144XL chips in the past, but those are harder to solder and also unnecessary for many smaller jobs. These are 5V tolerant but require 3.3 V supply. This same chip is used by RGB2HDMI board for Raspberry Pis, that's how I became again aware of this specific version. The Raspberry PI can program the chip, or a Xilinx style dongle can be used.

Edited by speccery
  • Like 2

Share this post


Link to post
Share on other sites
On 10/4/2021 at 1:24 PM, speccery said:

For what its worth a quick suggestion as far programmable logic is concerned: I just ordered more XC9572XL chips from mouser. Amazingly they are plentifully available at the moment. XC9572XL-10VQG44C - that's a very easy to solder SMD package in my opinion. I've used the 100 pin XC95144XL chips in the past, but those are harder to solder and also unnecessary for many smaller jobs. These are 5V tolerant but require 3.3 V supply. This same chip is used by RGB2HDMI board for Raspberry Pis, that's how I became again aware of this specific version. The Raspberry PI can program the chip, or a Xilinx style dongle can be used.

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.

 

 

 

  • Like 2

Share this post


Link to post
Share on other sites

Referencing some ideas on implementing pipeline in the CLI.

 

  

1 hour ago, Brufnus said:

By the way... is piping somehow possible with MDOS? I was thinking about creating a batch file, which reads the contents of my directories and then pipes it to SFBACKUP, which in turn saves the compressed output files to 1.44 MB floppies or a smaller hard drive. I don't know if that's possible, though...

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)

 

 


 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Whoah, that's quite a lot... I will need some time to read that thoroughly. :-D

 

Yes, another idea instead of direct pipelining could be to redirect output to a textfile and then use that as input for another program... or perhaps, in the absence of a sufficient buffer, a RAM disk or HDD or something could be used as some sort of buffer. It would be nice though, if the CLI itself handled pipelined commands. Perhaps in MDOS 9.70? :-D

Edited by Brufnus

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...