Jump to content
IGNORED

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


FarmerPotato

Recommended Posts

45 minutes ago, Brufnus said:

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

Just let @InsaneMultitasker and I know when you want to start working on the code in the CLI to handle that level of pipeline commands.

 

However, as I mentioned in another thread about the time you were posting here, creating a file (not DIS/VAR 80), but something a bit longer in record size, is probably a simpler process than adding the pipeline code desired in the CLI.

 

Beery

Link to comment
Share on other sites

1 hour ago, 9640News said:

Just let @InsaneMultitasker and I know when you want to start working on the code in the CLI to handle that level of pipeline commands.

 

However, as I mentioned in another thread about the time you were posting here, creating a file (not DIS/VAR 80), but something a bit longer in record size, is probably a simpler process than adding the pipeline code desired in the CLI.

 

Beery

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

 

Quote

A big machine would be 64 k-bytes--K, not M or G--and so that meant any individual program could not be very big, and so there was a natural tendency to write small programs, and then the pipe mechanism, basically input output redirection, made it possible to link one program to another.

--Brian Kernighan (famous for Unix, with Dennis Ritchie and Ken Thompson)

 

My thoughts do tend toward making everything more like Unix.

 

 

Link to comment
Share on other sites

On 10/7/2021 at 5:39 PM, mizapf said:

Pipelining also implies multitasking and a kind of synchronization (like semaphores), unless you understand pipelining like running command 1, collecting its complete output, and then running command 2 with that output as input.

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. 

 

Link to comment
Share on other sites

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. 

 

IMG_4305.thumb.jpeg.5c5a8eb841ff5f2e8e696f65efcd9794.jpeg

 

 

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

 

IMG_4302.thumb.jpeg.33d39303972c64ca1a91060a75374a6b.jpeg

 

(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.

 

IMG_4297.thumb.jpeg.da20b27b2589727f409c8f6719833e06.jpeg

 

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.thumb.png.9f4c36cb4afb21891e5436011e360ad1.png

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.

 

 

 

1367406283_ScreenShot2021-10-10at4_40_16PM.png.3a80ddee4445b8020efc9b72021c3412.png1141243209_ScreenShot2021-10-10at4_39_54PM.png.d54d6fdded5e176476c57f63d72bc38f.png

 

This enclosure got me thinking. Nah. NONE of my cards fit in there. 

 

270597813_ScreenShot2021-10-10at4_42_37PM.png.ebb379baf21691aa6328a648e1eafc62.png

Maybe this one? Nope.

 

  • Like 1
Link to comment
Share on other sites

On 10/7/2021 at 6:39 PM, mizapf said:

Pipelining also implies multitasking and a kind of synchronization (like semaphores), unless you understand pipelining like running command 1, collecting its complete output, and then running command 2 with that output as input.

I am confused. (No shock there) :) 

Are we talking about file "pipes"?

 

Pipelining to me is a technique in CPU design where you make an instruction pipeline so you can minimize stalling the CPU.

 

If we are talking about pipes then as you say MSDOS later versions had pipes without multi-tasking. 

I am not certain of the exact mechanism used. (Temporary files as output/input buffers?)

 

This sounds like something I should add to the Fox Shell with some filter programs.  hmm... ? with multi-tasking too.  

 

Link to comment
Share on other sites

2 hours ago, TheBF said:

I am confused. (No shock there) :) 

Are we talking about file "pipes"?

 

Pipelining to me is a technique in CPU design where you make an instruction pipeline so you can minimize stalling the CPU.

 

If we are talking about pipes then as you say MSDOS later versions had pipes without multi-tasking. 

I am not certain of the exact mechanism used. (Temporary files as output/input buffers?)

 

This sounds like something I should add to the Fox Shell with some filter programs.  hmm... ? with multi-tasking too.  

 

File pipelining, as in Unix.  Not the CPU architecture :)

 

  • Like 1
Link to comment
Share on other sites

9 hours ago, wierd_w said:

You want 2D IGES files from 3D CAD data?

 

--GIMME-- I can deliver in minutes.

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. 
 


 

 

 


 

 

 

 


 


 

 

Link to comment
Share on other sites

Well, I personally use something more professional than an open/free cad.  It has interoperable workbenches, and can maintain document linkages between 3D and 2D data internally. (It uses the 3D data to generate the 2D data). 

 

It is able to export as DXF directly, and can retain origin points and unit type.

 

I should see if the lower-tier offer from the same maker can do 2D draft also...

Link to comment
Share on other sites

  • 2 weeks later...

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.

 

 

Edited by FarmerPotato
  • Like 3
Link to comment
Share on other sites

The problem wasn't the 245 buffers, the PLD, or the control lines to the ROM/RAM.

 

The set of Flash chips was reading out all FFFF.

 

I pulled those and put in the prior set, which had been flashed before I had all that trouble with the TL866 II. Aha! Code running.

 

The problem I see now is that the even/odd bytes are swapped, and worse! RESET vector 8000,0096 is retrieved as 0082,8600

 

It goes off executing from RAM (8600) and hits 2E22, which decodes to XOP @2E22(R2),8. I see it vector through >0060.

 

Both Flash chips have identical images, with the low address bit hard-coded. If I can exchange the LSb of the address I can repair this.

 

It is a big goof I made.

 

Another reason to hate the ancient Kontron Z80 8-bit bus layout, with 16-bit extensions for 8086...

 

  • Like 3
  • Haha 1
Link to comment
Share on other sites

So, I decided to swap the bytes in a new set of Flash chips, to see how that does. Before I go and solder any bodge wires. (I just have to change two pins, swap +5 for GND.)

 

I think my TL866-Plus has broke down.

 

First there was all the short-circuit warnings with 22V10 PLD and 27C010 Flash.  Tonight I can't get it past the errors no matter what I try. Granted, I did spent some time trying to read a static RAM chip, because I'm sleep deprived. So if I damaged it, oh well.

 

I went shopping for a new TL866.

 

Then I noticed that the T56 supports ATF750 and ATF2500 devices. I want to use the 750 instead of the 22V10! Same software, different set of supported chips.

 

ATF750 is pinout compatible with the 22V10, but adds 10 internal flip-flops, beside the 10 driving the outputs. That potentially saves you 1-2 more external ICs. You can compile the logic in WinCUPL or some other free tools.  I got the license to the ProChip Designer that does 1500 and 2500. They used to say use Protel for 750s. I guess I'm stuck with WinCUPL.

 

In my case,  it will absorb the '157 multiplexer, and a couple more address inputs.  Costs $4, vs the $2 22V10.

 

I've used the 22V10 to do the job of:

  • a LS259 register. Typically used as 8-bit CRU addressable.
  • the '251 that reads back the register in CRU operations,
  • a '14 triple 3-input NOR,
  • an '04 inverter.

It doesn't have enough inputs to replace a '138. I feed that 6 address bits to get 1 select out.

 

But with the 750 I can absorb a '157 multiplexer.  I need to store 2x 4-bit registers and select 1 set of 4 at a time. With the 22V10, the register uses up 8 flip-flops which are on the output drivers. With the 750, those 8 bits are internal, so 8 outputs are freed. I will have 4 outputs for the multiplexer and 4 for other uses. Probably add those address bits that are needed to fully decode a CRU address.

 

The 2500 is a much bigger chip that I've considered.

 

It's unfortunate that the cheap TL866-Plus doesn't support the 750, but I'm splurging on the pricier T56.

 

 

  • Like 4
Link to comment
Share on other sites

  • 1 month later...
  • 4 weeks later...
On 12/10/2021 at 6:47 PM, dhe said:

F Po,

  Any update on how your loving your T56?

Oh yeah! The T56 is great. I've updated the 22V10s a few times, and the Flash ROMs. No issues at all.

 

It says it can do ATF750 and ATF1500 . I'm going to use ATF750s. They have 10 hidden bits of register, so you don't have to burn the 10 output registers (I/O pins)

 

 

 

 

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...
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.

I’m now trying out the XC9572-tq64 to see if the memory mapper will fit. Since it’s doing a job for a ICE40HX1K, it has to have external SRAM, and use registers sparingly. 
 

I installed ISE 14.7 for Win10, which is a Linux container in Virtual Box. I moved that over to my MacBook and that works for me (we’ll see about programming though reviews say it works.) 

 

The Language Templates menu provides macros for lots of tiny modules like D flip flop.  I have to translate the Lattice macros anyway. 
 

The memory mapper is challenging because it has so many jobs. Chiefly paging memory, but it provides memory-mapped I/O for 4 memory maps.

 

It has to do four read/modify/write transactions sometimes, because I’ve got a 16-bit bus, and Geneve  9640 packs two 8-bit registers together in a word. GeneveOS uses a mix of MOV and MOVB on them. 
 

While I’m at it, the memory mapper implements a scheme where page registers are a full 16 bits. they are 8 bit on Geneve 9640. (2MB reach.)

 

user code can only see and modify the lower 8 bits. Rather than hand out 2MB slices to every process, I’ve developed two schemes to mask off which bits the user can modify.   So BIOS could allocate any size slice (though GeneveOS always needs has 256 page numbers.) Cartridges and SAMS memory can have their own address space in any power of 2.  

 

 I want to cause a bus error if a 1 is written to a protected bit. But I’m sure the XC9572 will run out of space before that. 
 

There are still unsolved problems, like GROM, but I’ve spent January working on this piece. The memory mapper is what turns a general machine architecture into the personality of Geneve 9640 or TI-99/4A.  
 

P.S. designed in protected memory and multitasking, support for multiple OS instances or tiny processes. 
 


 


 


 


 

 

  • Like 5
Link to comment
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...