Jump to content
FarmerPotato

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

Recommended Posts

1 hour ago, FarmerPotato said:

I should have asked, do you know git?

 

The tools I use are:

 

Cygwin, a unix-like shell on Windows. Use the installer to choose git tools.

Make - again, install with cygwin

 

Ralph's xdt99 to assemble.   Requires python, so install that

 

There is an example in the bios directory, tiny.a99

 

cd bios

make

 

 

Well... I have code on Git but I am not an expert.

 

The tool I use is a cross-compiler I wrote that runs on DOS. :) 

(I have been threatening myself to move it to GForth so it would be more portable.)

 

I think you have given me what I need to make a kernel however I will need to give you the cross-compiler and the source files and a batch file for you to build it as well.

 

I am a bit of a square peg I guess.

 

 

 

Share this post


Link to post
Share on other sites
2 hours ago, TheBF said:

Well... I have code on Git but I am not an expert.

 

The tool I use is a cross-compiler I wrote that runs on DOS. :) 

(I have been threatening myself to move it to GForth so it would be more portable.)

 

I think you have given me what I need to make a kernel however I will need to give you the cross-compiler and the source files and a batch file for you to build it as well.

 

I am a bit of a square peg I guess.

 

Right,  I remember you saying that.

 

There are a couple more things.

 

Take a look at the memory map in the Appendix I linked.

 

The interrupt and XOP tables are reserved, >0000 - >7E

ill be working on interrupt handlers above that chunk. 

>800 - >FFE is macrostore.

1000 is additional macro store (They are unified on one flash ROM.)

 

It would be best to start your code at >1400

Of course, with the reset vector pointing into it.
 

I can merge a binary with yours and replace those chunks. 

 

RAM is from >8000 - FFF8.

more on that 

safe to say 9000 upward is free. 
 

there is paging. Rom in 4000 to 7ffe. Ram in c000-fff8. More on that later if needed. 
 

 

 

Edited by FarmerPotato
  • Like 1

Share this post


Link to post
Share on other sites

Thanks to the kindness and support of jbdigriz, I have cpus again.

 

I had two of his to test.

 

Then a surprise by speedy mail from China (est Nov 30, actually just 14 days)

And I found a seller in California.


For future comparison, here are the markings:

 

Markings on CPUs I have

TMS99105AJDL

P1  CM 9123 c 1981 TI 0408068 TAIWAN   ordered 2019.  6V applied, not ok?
P2  CM 8939 c 1981 TI EU02992 TAIWAN   
J1  MC 8925 US02240 c 1981 TI TAIWAN   where did I put it?
J2  QC8842 5817 c 1981 TI PHILIPPINES  
Q1  MC9230 c 1981 TI US03847 TAIWAN   
Q2  MC9230 c 1981 TI US03847 TAIWAN   
Q3  MC9230 c 1981 TI US03847 TAIWAN   



P polida2008 ebay
J jbdigriz   atariage
Q qsourceco_6 ebay

IMG-1386.thumb.JPG.6c512b7b4f655be27a9d524dd39cce05.JPG

  • Like 4

Share this post


Link to post
Share on other sites
On 10/24/2020 at 1:04 PM, FarmerPotato said:

 

IMG-1386.thumb.JPG.6c512b7b4f655be27a9d524dd39cce05.JPG

 

All CPUs have checked out OK.  Including J1, which didn't show up for this family photo. And even P1 is ok, that one that got 6V applied to VCC. (now I have to check other chips around it...)

 

 

 

  • Like 4

Share this post


Link to post
Share on other sites

F Po,

   How where you planning on doing memory?

   I've thought, that with plentiful cheap SRAM, it would be pretty easy to do a board with a single 4 or 16MB SRAM chip and put a logic glue chip around it to 'throw' away the pages you don't need? 

Share this post


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

F Po,

   How where you planning on doing memory?

   I've thought, that with plentiful cheap SRAM, it would be pretty easy to do a board with a single 4 or 16MB SRAM chip and put a logic glue chip around it to 'throw' away the pages you don't need? 

There will be some SRAM. These are 256K x 16 bits super-fast 10ns, and cost $4, so, SRAM is $8/MB.   Vintage parts are 55ns (and... still $8/MB.)


I'm testing vintage chips tonight.  The BIOS memory card has 256K SRAM and 128K Flash ROM. (70 ns parts)

 

The main memory will be in removable 30-pin SIMM module pairs. The memory mapper will support 2MB, 8MB, or 32MB.

MDOS will occupy a 2MB slice.

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Wait what? You mean, I'll be able to test memory, by removing it from a socket and swapping, instead of desoldering from a multi-side board, who's thru whole and traces are known to lift, from an ugly look?   Wonderbar!

  • Haha 1

Share this post


Link to post
Share on other sites
42 minutes ago, dhe said:

Wait what? You mean, I'll be able to test memory, by removing it from a socket and swapping, instead of desoldering from a multi-side board, who's thru whole and traces are known to lift, from an ugly look?   Wonderbar!

Yes, it is going to use real socketed chips, vintage, wherever feasible.

The Flash ROM and PLDs are all socketed (use inexpensive TL866 to update) 

The SRAM does have to be soldered as it is 0.5".

 

I love the idea of popping out SIMM modules, when you decide you need to go from 8 to 32MB.

It became feasible when I found the connector at peconnectors.com and new modules sold at memoryx.com

 

And... our 11-year old built his first PC last month. Which means, popping in the CPU and the DDR4 modules. Just something so satisfying about installing what parts are still left for the owner to install. Since then he's been telling everybody who will listen, that they can do it, too. The funny thing is that the Dell PC case he was reusing, doesn't fit any ATX boards at all. So he's got a cardboard box instead. The cardboard box now sports one of the power button/wire harnesses that I just made for Geneve2020.

 

I'm procrastinating just now. Because I need to move corrections from the breadboard, into the real board, which means soldering bodge wire on SMD. No fun.

 

 

  • Like 4

Share this post


Link to post
Share on other sites

Today I've got the CPU card accessing ROM and RAM over the backplane. It's running well. 

 

The memory is on a wire-wrapped card, so I can evaluate the bus signals before sending off for a PCB. The WW version is quite simplified.

Today I also imagined adding a 9902 to the wire wrap board. Here is the kind of planning I do before starting WW:

 

WireWrapLayout.thumb.PNG.ae4183bf799a92928eee55e3ccaacc85.PNG

 

It's made from bits of the main schematics, pulled into a new Kicad schematic. It's laid out in the kicad pcb, but intended for perf board. I try to label all the pins, and I can print all this on a sticky label. Not all the traces are drawn. The ones that are, try to follow a sensible path for pulling a wire.

 

As I build it, I highlight traces done.

 

Wire wrap forms a very durable system. They were typically used to make production units, until PCBs became very cheap and reliable. 

And yet you can unwrap a wire and make changes just as easily. It sure beats lifting pins and soldering wires onto a PCB. In fact, you know the little wires you see as corrections on PCB? Those are made specifically for wire-wrapping. Wire wrap has advantages over breadboard. You need similar attention to cable management, but you can't accidentally unhook a wire.

 

====

 

This will form a minimal-minimal system. Once it's in a PCB card, I can't hack on it so easily.  But it can run a BIOS and I can test communication over a serial port. With that, I can keep working on hardware or software while I wait for PCBs to get made.

 

The current roadmap:

 

Minimal system anticipated, made of 100x100 mm cards, on an 8-slot backplane:

  • CPU card
  • BIOS memory card
  • I/O card
  • Front Panel & Power PCB*

*has PSU, fans, & keyboard/mouse connectors (for I/O card)

Will run FORTH language, has 256K SRAM.

 

A full system would also have:

  • Video card
  • Sound card
  • Main 32MB memory & FPGA card
  • Front Panel SD card modules

Intended to run GPL and MDOS

 

In-between steps are:

  • Develop and test keyboard/mouse drivers
  • Resume work on SD modules. Cabled to I/O card.

 

Final system, made of 160x100 mm cards:

  • CPU and BIOS card
  • I/O card with second 9901
  • Main memory and FPGA
  • Video card
  • Sound card

For a possible 4-slot system with no expansion, the video&sound might be combined.

 

 

 

That's the current roadmap.

 

 

 

 

  • Like 9

Share this post


Link to post
Share on other sites

I have not done any new design work in a while. Here is the SD card interface.

 

I had put a single SD card ability on the CRU card-it has 1 PMOD connector that can accept an SD reader, provided it is 5V safe.

 

This design is for the front panel. This PCB screws in to the front panel where there are card insertion slots. It has 2 regular size SD modules underneath, and 1 micro-SD slot on top. It connect to the CRU card by 2x8 ribbon cable. One of the wires is the CRU base decoded--that's determined by the PLD on the CRU card. I'm situating it at 1600. I'm reserving the bit at 1600 for the ROM enable in a future 4A or Geneve 9640 version of the PCB. I imagine device names SDC1, SDC2, SDC3, though there's no barrier to coding it for DSK1, DSK2, DSK3 or HDS or WDS.

 

The control register has 8 bits in, 8 bits out, but I'm only using 3 of them. I imagined having Card Detect or Write Protect sense, but those aren't on the cheap SD modules.

CRU Map
1600 DSR ROM Enable (reserved)
1602 Card Select, LSBit (0 none)
1604 Card Select, MSBit (0 none)
1610 Alias of 1600
1620-163E  SPI transfer, MSBit first 
            (backwards from 9900!)
1640-16FE  Ignored

 

 

image.thumb.png.d8fc1377d73ba113a4243123db74e5ff.png

 

As far as software plans, the format will be FAT32, just as they come from PC formatting. This is what I developed on my FPGA board in Forth.

 

The DSR will decode a few extensions. TFI is expected to have a TIFILES header, with the file type info and a 10-char filename inside. Just like xdm99.py writes when you extract using -t. TXT will look like a DV80 file. Anything else will be treated as a DF128 file. Files without TFI headers will have 8-char filenames on the TI side (and unfortunately you will see the mangled-to-8-char kind with a ~ inside.)

 

Newly created files will always be TFI. 

 

I should probably think about:

  • supporting DSK or HDS image files, but that's like a whole nuther DSR. It would be easier to have an external program that extracts files from a DSK. 
  • emulating the catalog file
  • direct file access (level 2) and what that means--the TIFILES header is hidden?
  • whether any existing disk manager software is going to be a good fit. This will probably require a rewrite, of say DM1000 (like the NanoPEB has.)

 

As usual, all the files are open source. See https://gitlab.com/FarmerPotato/geneve2020/-/tree/master/kicad/sdc

 

  • Like 6

Share this post


Link to post
Share on other sites

Calculation of SD card sector access times with this scheme

 

In operation, either LDCR or STCR strobes the SPI CLK. 

 

The SPI clock equals the CRU clock of 3 MHz.

 

Letting the LDCR or STCR strobe the SPI CLK is quite efficient.

 

However, CRU emits LSBit first, while SPI does MSBit first.
Therefore it is necessary to reverse the bit order of each byte.
I propose a 256-byte lookup table for reversing the bits.
Reading or writing 16 bits at a time is not very practical.

 

I calculate the CPU cycles to read or write a 512 byte sector
with bit-reversal and Bit-Serial I/O (the usual CRU.)

 

Assuming a 6MHz 99105, which adds a wait state on every CRU cycle,
I calculate that reading 512 bytes (an SD sector) takes 4.8 ms
while writing takes 4.3 ms. 

 

One could add an extra hardware shift register (serial-to-parallel)
then read it as one byte to get the bits in correct order. For
this, I calculate 4.1 ms / read sector. So the parallel shift
register is not a great tool.

 

(Read and write need their own IC latch, two if 16 bits wanted.)

 

Both read and write are under 5 ms. This gives a theoretical 
disk I/O speed of 100Kbytes/s. Or the equivalent of one SSSD floppy
per second. That ought to be good enough.
 

Note: SD card natively has 512-byte sectors. I wish to remain compatible with

FAT32 file exchange, so I will no ignore half the bytes in order to match

TI sector size of 256-byte. Instead, the DSR will buffer 512 bytes each way.

 

Instruction Time Calculations:

T = ts ( C + W*M + A)

ts = 166ns
W = 0 (no wait states)

Some instruction times:

                  C             M     A    Total Time (usec)
LDCR              8+2*cnt       3     A     
                
LDCR R0,8        24             3     0     24   4.00
LDCR R0,0        40             3     0     40   6.67
LDCR *R1+,8      24             3     3     27   4.50
LDCR *R1+,0      40             3     3     43   7.17

STCR R1,8        27             4     0     27   4.50
STCR R1,0        43             4     0     43   7.17
STCR *R1+,8      27             4     3     30   5.00
STCR *R1+,0      43             4     3     46   7.67

parallel 
LDCR *R1+,2       8                   3     11   1.83
STCR *R1+,2      10                   3     13   2.17

SPI Clock rate: 3 MHz

WRITE sector of 512 bytes:

LI   R12,>1600
LI   R0,>0300       * dsr=1 + sdc slot number 1
LDCR R0,3

LI   R0,BUF              3
LI   R2,512              3
LI   R12,>1620           3

LOOP:
CLR  R1                  3
MOVB *R0+,R1             7
SWPB R1                  3
MOVB @BITREV(R1),R1      7
LDCR R1,8               24
DEC  R2                  3
JNE  LOOP                3
                        ==
                        50
50*512 = 25600 cycles, or 4.267 ms / sector

READ sector of 512 bytes:

RDLOOP:
CLR  R1                  3
STCR R1,8               27
SWPB R1                  3
MOVB @BITREV(R1),R1      7
MOVB R1,*R0+             7
DEC  R2                  3
JNE  RDLOOP              3
                        ==
                        53
                        
53*512 = 27136 cycles, or 4.767 ms / sector
max throughput: 100 KB
equivalent of loading MDOS in 2 seconds

BITREV BYTE 0,>80,>40,>C0,>20,>A0,>60,>E0,>10,>90,>50,>D0,>30,>B0,>70,>F0
       BYTE 8,>88,>48,>C8,>28,>A8,>68,>E8,>18,>98,>58,>D8,>38,>B8,>78,>F0
...


If there were hardware for bit reversing--an 8 bit latch--we still need 8 SPI clocks.

Read sector

RDLOOP:
LI   R12,>1620           3
STCR R1,8               27     * 8 clocks. returns reversed byte
LI   R12,>9620           3
STCR *R0+,2             10     * parallel read latch, correct
DEC  R2                  3
JNE  RDLOOP              3
                        ==
                        49

49*512 = 25088 cycles, or 4.1 ms / sector

                        

 

  • Like 2

Share this post


Link to post
Share on other sites

I think you have found the fastest form, maybe unrolling the loop 4 times would gain a few percent but that is it.

 

Slower but more compact options could be:

- If a 256 byte table is too much space, you could consider using a nibble table with 16 entries and do it in two steps.

- There is this hack for bit reversing a byte using MPY: https://graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith32Bits

 

If you place the hypothetical shift register in memory instead of parallel CRU space, your last example would not need the R12 adjustments and could be a bit faster still. For Unix on the Cortex I've found that disk access speed does matter a lot (but early Unix was quite disk intensive, maybe more so than MDOS).

Share this post


Link to post
Share on other sites
On 2/1/2021 at 8:09 AM, pnr said:

I think you have found the fastest form, maybe unrolling the loop 4 times would gain a few percent but that is it.

 

Slower but more compact options could be:

- If a 256 byte table is too much space, you could consider using a nibble table with 16 entries and do it in two steps.

- There is this hack for bit reversing a byte using MPY: https://graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith32Bits

 

If you place the hypothetical shift register in memory instead of parallel CRU space, your last example would not need the R12 adjustments and could be a bit faster still. For Unix on the Cortex I've found that disk access speed does matter a lot (but early Unix was quite disk intensive, maybe more so than MDOS).

Thanks for taking a look. 

 

I think I've seen that bit hack somewhere, maybe Hacker's Delight, but I assumed it would be too slow. There is plenty of good stuff in there. 

 

256 bytes is fine for a major function. In a 4A DSR of 8K, or my BIOS with 16K resident, 16K paged.

 

Your mention of Unix got me thinking about use cases. 100K/second sounds awful for a virtual memory swapfile... but there should be plenty of RAM (32MB max)

 


Use cases for sustained read/write

  • Loading O/S. Say 128K in 1-2 seconds
  • Verifying disk copies. Is verifying file copies a thing?
  • Virtual memory (100K/sec is way too slow)
  • Manipulating a DSK image in memory - read/write 360K DSK file
  • Image files. 128K max (VRAM max)
     

 

 

No memory mapping, only CRU. I'm sticking this device on a 16-pin header, where it has a block of 32 bits of CRU. This lets me revise the I/O card and SD module separately.   It can also be a reusable interface to other I/O ports--like moving each 9902 and MAX232 chip out to an external serial port pcb.  The big 9901 + I/O card itself needs no knowledge of what's in the modules--it just decodes CRU bases that I set in a PLD.

 

I imagined DSR ROM, which would require a memory bus, too. What could be cool is sticking a SPI ROM on the plug-in, which the OS sucks down at boot time. So the SD card access routines are actually plug-and-play. Ooh... Gregg Eshelman recently mentioned the DSR ROM as a feature of the 4A that deserved attention. So I've been imagining how to stick to it.

 

 

 

  • Like 6

Share this post


Link to post
Share on other sites
On 2/1/2021 at 8:09 AM, pnr said:

I think you have found the fastest form, maybe unrolling the loop 4 times would gain a few percent but that is it.

 

 

I did 2 bytes per loop and saved 10%.  That's good. Two bytes in 89 cycles (vs 50 per byte)

 

This optimization is most of it:

MOVB @BITREV(R1),R1      7
LDCR R1,8               24

becomes

LDCR @BITREV(R1),8     27

 

So doing two LDCR in the loop:

LDCR @BITREV(R1),8     27
LDCR @BITREV(R3),8     27

 

 
It turns out there's no savings from building a reversed 16-bit word, for one LDCR operation:

extra setup            16
LDCR R1,0              40

(LDCR takes 8+2*cnt bits, plus src addressing)


Unrolling to four bytes/loop would double the number of instructions--nothing to gain there.

 

I still need some 1-byte as well as multibyte reads/writes, as SPI commands have various lengths.

 

  • Like 4

Share this post


Link to post
Share on other sites
On 2/4/2021 at 6:21 PM, FarmerPotato said:

Unrolling to four bytes/loop would double the number of instructions--nothing to gain there.

The unroll also reduces the cost of the loop counter and loop jump. In the my Unix code (for an 8 bit CF card) I used first this:
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/c22c09b80a674a44?ln=75,78

but soon switched to:

https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/ad1f9336c3316aa1?ln=86,92

This made it much faster. In your case the loop overhead is less in relative terms, so it isn't as critical.

Another learning was dealing with interrupts. Your disk access code may be interrupted, and the interrupt may cause another disk access to happen before returning. Leaving interrupts off for long periods is not a good idea (e.g. your 9902's need servicing), so you have think about the time it takes to read a sector and if you can afford to leave interrupts off for that long, or you have to make sure the disk code is not re-entered twice in parallel.
 

The third learning was that using the CPU to read the disk is a hog. Once you start running parallel jobs (not sure MDOS supports this) you really start to notice this, although the short seek times on flash disks offset some of this. I am planning to add DMA capability to my next board.

  • Like 2

Share this post


Link to post
Share on other sites

Thought I'd be a pain and give this topic a nudge. Any updates? 

 

Spent a few bucks lately on upgrades and hacks for some TI hardware I've put in a larger case but I figure I probably shouldn't go too deep into it if I'm just going to move on to one of these and/or one of the other motherboard projects being worked on. 

Edited by Tornadoboy
Me be articulate
  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, Tornadoboy said:

Thought I'd be a pain and give this topic a nudge. Any updates? 

 

Spent a few bucks lately on upgrades and hacks for some TI hardware I've put in a larger case but I figure I probably shouldn't go too deep into it if I'm just going to move on to one of these and/or one of the other motherboard projects being worked on. 

 

I wouldn't wait for a thing that is not here yet. Don't put your current goals on hold!

 


I continue to work on Geneve2020 when I am able.

 

Some folks know that I was really sick in February. I won't publish any more details. I just didn't have all the time or abilities to make progress (like a 4 hour testing session).

 

My RS232 testing is still stuck. I see some blips on the TXOUT line but I need to do a deep dive on it.

 

I do have 3 PCBs in the mail--I'm using Aisler.net budget boards, which is variable between $0.60 and $1 a square inch per board. That's like half of OshPark ($1.33/sq-in), you get boards after 2 weeks, and they're made in USA or Germany.

 

I've done some work on the PS/2 keyboard interface--all the Verilog is written and fits in an IceStick for testing.

 

I thought of some video tests, any day a PCB will arrive. That's SCART and 9640 port out. I realized I never tested the SVIDEO or composite out. I still have two plans to get VGA out, one of them is sketchy (didn't work so far) and the other one is crazy (theoretically it could work and be awesome). 

 

I took some time to study audio amplifiers and ran some PSpice tests. I've gotten comfortable with TI's aging TINA simulator (based on PSpice). A simple 4A sidecar PCB is on the way with TI's OPA1688 headphone amplifier on board. I'll see if it matches what I see in the simulation! 

 

Meanwhile I worked on my Geneve 9640 and TIPI-PEB and I'm happy about that working.

 

So I'm trying to get my energy up to good levels. Meanwhile doing some small things.

 

Oh yeah, I spent some time with a Dremel, since my first plastics and PCBs for the front panel were a bad fit. Things fit together now, and I have one fan in place. It's comforting to see the blue box with all the plastics in place, with the green light ON and fan running smoothly, even though the backplane is empty.

 

Sticker shock warning: this baby is going to come in around $500. I'm very cost-conscious, so that's my upper estimate.

 

 

  • Like 6

Share this post


Link to post
Share on other sites

Not to be a pest here, but when you say $500, are you talking total price to get the PCBs and to populate them? Or is that just for the set of blank PCBs? Personally I was hoping to just get the blank PCBs and any custom components initially and slowly populate the rest as money because available and I find other things to cannibalize.

Share this post


Link to post
Share on other sites
On 4/29/2021 at 12:14 PM, Tornadoboy said:

Not to be a pest here, but when you say $500, are you talking total price to get the PCBs and to populate them? Or is that just for the set of blank PCBs? Personally I was hoping to just get the blank PCBs and any custom components initially and slowly populate the rest as money because available and I find other things to cannibalize.

That’s for everything. Including a nice case. 

  • Like 4

Share this post


Link to post
Share on other sites
17 hours ago, FarmerPotato said:

That’s for everything. Including a nice case. 

i know i'll be in for one!

  • Like 3

Share this post


Link to post
Share on other sites
On 5/1/2021 at 3:02 PM, Tornadoboy said:

Do you plan on selling bare boards too?

Too soon to say. I don’t see why not. However, I think I would try to order batches of boards with SMD assembled already. Also I can get bulk savings buying parts and putting them in complete kits. 

 

For instance, there is a Keystone 7790 connector part. I’ve already bought 2000 at .05 each, but the single price is 0.43. Each board uses two. This the most extreme example, but there are others.
 

 

  • Like 2

Share this post


Link to post
Share on other sites
3 hours ago, FarmerPotato said:

Too soon to say. I don’t see why not. However, I think I would try to order batches of boards with SMD assembled already. Also I can get bulk savings buying parts and putting them in complete kits. 

 

For instance, there is a Keystone 7790 connector part. I’ve already bought 2000 at .05 each, but the single price is 0.43. Each board uses two. This the most extreme example, but there are others.
 

 

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.

  • Like 5

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.

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