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

[+FarmerPotato]

Last night:

 

Can't fit device: XC9572XL-tq64:  377 pterms, 360 available.

 

 

Busted on:

•   implementing two more 8-bit registers, to hold 2 8-bit page reads from SRAM, then send 16 bits to the CPU.

  
Implemented:

•   16-bit address latch
•   mode bit CRU access
•   address output for memory-mapped I/O for VDP, RTC etc in 9640 mode
•   page registers for BIOS ROM/RAM access
•   addressing SRAM
•   select external page register when accessing main memory
•   multiplexing the AD bus port.

  

Not even touched:

•   mapping PAD to SRAM (probably cheap)
•   mapping LOAD interrupt to ROM at 3FFC (cheap)
•   state machine to do read/modify/write of 16-bit page registers:
•       reading 2 lower 8-bit halves, mask them, and return one 16-bit word to CPU.
•       writing 2 lower 8-bit halves
•       writing 2 lower 8-bit halves with mask
•   the curse of 4K and 8K pages together

Earlier I ran out of I/O pins (52 provided). But the solution was to multiplex EVERYTHING on
the 16-bit AD bus.

 

That includes CPU address/data in/out, the remapped I/O address out, SRAM data in/out. CPLD emits control signals to switch on external transceivers/latches, so the right things are gated onto one 16-bit bus.

 

So.. if I can't do everything in this CPLD, 

 

1. Double up to 2 chips or the 144 - which costs twice as much and has finer pin pitch.

 

2. Scrap the "2 8-bit registers per word" of the 9640, but generate a NMI bus error interrupt. Then handle it in software by decoding the MOV or MOVB instruction. 
    
3. I can go back to building the ICE40HX1K solution. Still beyond what I'm comfortable building.  Still, I hoarded 100 chips, so I'm kinda invested.  Looking at kludging the IceBlink board onto a CPU board first. It's got 43 I/O on a Arduino shield layout (yuck) and 16 other I/O. IceZero only has 24 I/O. 
 

 

[+FarmerPotato]

Finding a way forward with the XC9500:

 

first, I can change the fitting setting from Balance to Density. This spreads the logic to more equations (intermediate stages introduce a delay) and utilizes some part from every free cell. 

Second, back up: get rid of the 16-bit register I just added.

 

Now there is only one 16-bit register, used in different ways in memory or register cycles. 
 

When loading the register from either the CPU or SRAM data bus, operations are SET, INV, AND, OR.
 

Now page register read/mask/modify/write is a few micro instructions, shuffling things between the register, 4 words of the SRAM, and CPU data bus. 

 

Pretty happy with this idea. Hope it fits. 
 

 

 

 

 

[+9640News]

I'm following your progress.  I understand "some" of what you are saying, but it is well over my head.

Keep up the work!!!

 

Beery

 

[speccery]

Interesting updates! I've been using the XC95144XL chips in 100 pin package. These dense packages do require a bit of care when soldering, and I have certainly experienced my share of soldering issues, but so far I've been able to fix them with just reflowing. I'm just planning to order a bunch of ICE40HX1K 144-pin chips... They seems to be the only FPGA chips which are available, and cost a third of the XC95144XL CPLDs while offering better capabilities. If mixing with 5V logic one does require level converters to 3.3V, unlike with the XC95 series chips which are 5V tolerant.

@FarmerPotato have you already designed boards based on the ICE40HX1K? I have only used the BlackIce boards, but not yet designed my own boards. Interested in the 1.2V core voltage solution... I have already sourced 1.2V linear regulators, those should be an easily solution.

[+FarmerPotato]

2 hours ago, speccery said:

Interesting updates! I've been using the XC95144XL chips in 100 pin package. These dense packages do require a bit of care when soldering, and I have certainly experienced my share of soldering issues, but so far I've been able to fix them with just reflowing. I'm just planning to order a bunch of ICE40HX1K 144-pin chips... They seems to be the only FPGA chips which are available, and cost a third of the XC95144XL CPLDs while offering better capabilities. If mixing with 5V logic one does require level converters to 3.3V, unlike with the XC95 series chips which are 5V tolerant.

@FarmerPotato have you already designed boards based on the ICE40HX1K? I have only used the BlackIce boards, but not yet designed my own boards. Interested in the 1.2V core voltage solution... I have already sourced 1.2V linear regulators, those should be an easily solution.

I am still daunted by making my own ICE40HX1K board from scratch, though I had committed to that path when I bought 111 of the 144-pin ICE40HX1K chips.   But reading the ICE40 hardware design guide, I doubt my PCB layout skills, not to mention the board bring-up.  I've only studied lots of schematics (IceBlink, BlackIce) and drawn my own.

You have quite a collection of ICE boards.   I think a XC9572XL could serve as a 5V input buffer to the ICE40HX!  I've been successful with the 74LVC245A to interface 5V on the 4A to/from BlackIce II, or the 3V3 version of ATF22V10.

 

I have one idea to "clone" the very small IceZero (or the IceBlink) using the HX1K, a modest 3V3 RAM, plus JTAG. Amanda has successfully soldered my IceZero board, which is the 144 pin chip, so that's doable.  From the 99105, it needs AD15:0 and <8 others, so 3 LVC245s can do it. It needs a lot of outputs, but 3V3 is ok there.

I am open to any help with that ICE40HX1K piece. 

 

So far I had plans to put one HX1K next to the CPU, but an XC9572XL might suffice.  I still need the HX1K or 4K elsewhere, for digital audio/video, which I prototyped on BlackIce II.

 

I stocked up on XC9572XL 44 and 64 pin chips after my first trials. If the logic next to the CPU can't fit, it could partition into two CPLDs: 44 pin for the combinatorial logic, and 64-pin for the features with RAM and state.  It seems to me that a HX1K for those CPLD-type jobs is overkill. And my design principles say: use original chips where possible. Many TI add-ons use one XC9536 or 72.

[+FarmerPotato]

@speccery

Do you know of an open-source Kicad design for a XC9572XL prototyping board? I see a lot of $25 boards from China.  I think I should make something to prototype with.  It could plug it into a connector on my next build of the CPU card, or go into my wire-wrap area. 

 

[speccery]

11 hours ago, FarmerPotato said:

@speccery

Do you know of an open-source Kicad design for a XC9572XL prototyping board? I see a lot of $25 boards from China.  I think I should make something to prototype with.  It could plug it into a connector on my next build of the CPU card, or go into my wire-wrap area. 

 

Take a look at the RGB to HDMI project, which you perhaps already know: https://github.com/hoglet67/RGBtoHDMI

The logic board has XC9572XL (link to PDF schematics), and although it's not a prototyping board, that use case was one of the reasons I got 10 of these PCBs made. Of course these boards have been designed for different use, but at the end of the day you have a PCB which has not much else that the XC9572XL and some connectors. Should be easy to modify if you want it to be something else.

 

I have been using Eagle, but after the Autodesk acquisition of Cadsoft the pricing models have changed. I should learn Kicad, but all of my existing designs are in Eagle (including the ET-PEB with XC95144XL). Sigh.

 

One of the things bugging me about XC95 series chips is that there is no open source toolchain for them (at least to my knowledge), that's one of the primary attractions for ICE40HX series chips for me. That, and of course they are low cost, relatively fast. And indeed the entire TI-99/4A fits into an ICE40HX4K chip like I did in the icy99 project. The FPGA needs to be used as a 8K chip (possible with the Icestorm toolchain you're familiar with).

 

Forgot to mention that I am now using a Raspberry PI as a programmer for the XC95 chips. Works great at least with the ET-PEB. I don't have an official Xilinx programmer, and the clones I have are not very good...

Edited February 16, 2022 by speccery

[speccery]

12 hours ago, FarmerPotato said:

I am open to any help with that ICE40HX1K piece. 

 

So far I had plans to put one HX1K next to the CPU, but an XC9572XL might suffice.  I still need the HX1K or 4K elsewhere, for digital audio/video, which I prototyped on BlackIce II.

 

I stocked up on XC9572XL 44 and 64 pin chips after my first trials. If the logic next to the CPU can't fit, it could partition into two CPLDs: 44 pin for the combinatorial logic, and 64-pin for the features with RAM and state.  It seems to me that a HX1K for those CPLD-type jobs is overkill. And my design principles say: use original chips where possible. Many TI add-ons use one XC9536 or 72.

I have been wanting to design FPGA boards for a very long time, and I will definitely give it a go probably quite soon. The ICE40HX1K would be nice practicing ground. How hard can it be?  

With the ET-PEB I needed to go to a four layer board to make it work. I have soldered so many fine pitch components that I am no longer scared about that. I would like to do first a simple board, with the ICE40HX1K, 5V level converter buffers and probably a memory chip. And of course power supply, clock and some method of programming the FPGA, in practice with a Flash chip most likely.

[+chue]

13 hours ago, speccery said:

One of the things bugging me about XC95 series chips is that there is no open source toolchain for them

Maybe xc3sprog?  I recall it having been used to program the XC95 series chips, but I don't have the details off hand.

 

https://github.com/matrix-io/xc3sprog

[speccery]

9 hours ago, chue said:

Maybe xc3sprog?  I recall it having been used to program the XC95 series chips, but I don't have the details off hand.

 

https://github.com/matrix-io/xc3sprog

Yes I am using xc3sprog to program the bitstream to the chip. But the tools creating the bitstream are proprietary. That’s understandable, but having used ice storm tools for lattice has shown how much more convenient it is when one can just compile the tools to whatever OS, such as macOS.

[+FarmerPotato]

10 hours ago, speccery said:

Take a look at the RGB to HDMI project, which you perhaps already know: https://github.com/hoglet67/RGBtoHDMI

The logic board has XC9572XL (link to PDF schematics), and although it's not a prototyping board, that use case was one of the reasons I got 10 of these PCBs made. Of course these boards have been designed for different use, but at the end of the day you have a PCB which has not much else that the XC9572XL and some connectors. Should be easy to modify if you want it to be something else.

 

I have been using Eagle, but after the Autodesk acquisition of Cadsoft the pricing models have changed. I should learn Kicad, but all of my existing designs are in Eagle (including the ET-PEB with XC95144XL). Sigh.

 

One of the things bugging me about XC95 series chips is that there is no open source toolchain for them (at least to my knowledge), that's one of the primary attractions for ICE40HX series chips for me. That, and of course they are low cost, relatively fast. And indeed the entire TI-99/4A fits into an ICE40HX4K chip like I did in the icy99 project. The FPGA needs to be used as a 8K chip (possible with the Icestorm toolchain you're familiar with).

 

Forgot to mention that I am now using a Raspberry PI as a programmer for the XC95 chips. Works great at least with the ET-PEB. I don't have an official Xilinx programmer, and the clones I have are not very good...

I have not bought a Xilinx cable yet. Learning about XSVF I figured I might try a Bus Pirate or Pi, but I also want something that will work the first try. 
 

IceZero is programmed through a Pi connector.  

[speccery]

5 hours ago, FarmerPotato said:

I have not bought a Xilinx cable yet. Learning about XSVF I figured I might try a Bus Pirate or Pi, but I also want something that will work the first try. 
 

IceZero is programmed through a Pi connector.  

Does that mean that you haven't yet programmed the CPLDs with your designs? I have until lately used my clone Xilinx cables, but switched to using Raspberry Pi as the programmer recently: ISE 14.7 is old and I have used Windows as my development platform for Xilinx FPGA and CPLD development mostly (also the ISE 14.7 VM) but somehow its been a bit of a nightmare of getting the actual programming done from ISE with recent Windows versions. Always some driver trouble. Many FPGA development boards have built in programmers, and those have so far worked well for me. Anyway, Raspberry Pi seems to work well as a programmer, and I have loads of them  

I placed an order for some ICE40HX1K chips. My intention is to design a test board in Kicad. May not be the best of ideas to try simultaneously a new CAD tool and new chips (from PCB design point of view) simultaneously, but I will see where this takes me.

[+FarmerPotato]

5 hours ago, speccery said:

Does that mean that you haven't yet programmed the CPLDs with your designs? I have until lately used my clone Xilinx cables, but switched to using Raspberry Pi as the programmer recently: ISE 14.7 is old and I have used Windows as my development platform for Xilinx FPGA and CPLD development mostly (also the ISE 14.7 VM) but somehow its been a bit of a nightmare of getting the actual programming done from ISE with recent Windows versions. Always some driver trouble. Many FPGA development boards have built in programmers, and those have so far worked well for me. Anyway, Raspberry Pi seems to work well as a programmer, and I have loads of them  

I placed an order for some ICE40HX1K chips. My intention is to design a test board in Kicad. May not be the best of ideas to try simultaneously a new CAD tool and new chips (from PCB design point of view) simultaneously, but I will see where this takes me.

Right, I have not got to Impact or other XC9572XL programming. 
 

I’m still writing Verilog and watching the fitter (I read the optimizing guide for Xilinx CPLDs, very helpful! Also using their macros.)

 

9572s arrived from Mouser. Going to take time for me to layout any PCB, plus 2 weeks to turn around cheap PCBs (Using Aisler.)
 

 

Another full rewrite of all my Verilog in progress since Sunday. Tough with seven newborns (haha) to bottle feed and potty train. 
 

I got the ISE 14.7 VM on Windows 10. Moved that 40GB VM over to MacOS 11.3 Big Sur.  Some anecdotes say Impact works fine from there with a clone cable. 
 

I too have multiple Pis up to Pi 3 so I’ll set one up to program from. 

Trying two new things at once—I have learned my lesson from that! But sometimes it’s the only way. 

 

 

 

 

[+dhe]

Today I assembled on a linux boxen gcc source for a small grep command (about 100 lines - not including libs).

 

I was thinking what would this take to port to the geneve. Then I got to thinking, maybe that cute cuddle hard typed filesystem I loved so much in the early 80's wasn't so cute and cuddly anymore?

 

I've really grown to love the file in directory concept used by Classic99. On they Geneve, we are part of the way there with TIPI. I believe TIPI should be the target mass storage system. Bonus points if you can have the hypervisor access TIPI at the native filesystem level!

 

 

[+FarmerPotato]

@dheyes, FIAD in Classic99 and TIPI are pleasant to use. 
 

SD card first, doing FIAD on top of FAT32. TIFILES format (amazing how that’s still in use since BBS Xmodem days!) Then TIPI connection. Somewhere along the way, mounting DSK file existing on  FAT32. 

 

 

 

 

[+FarmerPotato]

@dhe  were you conpiling with gcc9900 or just to run on Linux?

 

I’ve posted some thoughts on pipelining here. Idea  from Camel99 Forth was to define mode-changers like DV80 DF128 IF254. Then a command entered like this (DOS like)

 

GREP /I DHE USERS | DF128 > FILE

Supposing these commands were written C style to expect open files for STDIN,STDOUT,STDERR they might check the record length themselves or just print away. The handling of newlines should somehow be automatic—stripped when writing out DV80, kept or inserted with Df128 text (and not record oriented.)  Subject to whatever default rules seem most convenient. 

Im thinking this pipelining would have to be custom programs in a new CLI. @9640News suggested it could be just a regular MDOS program. Maybe invite @jedimatt42 to suggest how to be a CLI looking like Force Command, cuz we don’t need another standard. (“Be more like Force Command”)

 

the point of pipelining , abs the Unix philosophy , is to have small programs that do one thing and do it well. 
 

My basic toolbox wishlist would include:(Unix names)

 

grep, echo, ls, pr, more, cat, sort, wc, uniq, find, cut, paste, tr, tee, head , tail

 

much much harder pipelined commands would include:

 

TI writer formatter (substitute for nroff) 

Zip

 But rapid implementations could be made with commands that send the real work over to TIPI!

 

 

 

 

 

[+dhe]

I was using the GPSCC.

 

Yea, I would love to have the same UNIX commands available.

 

Also, it is very unfortunate there isn't complete source code to TIC

  https://github.com/abeard01/fortran99/tree/master/tic

 

The Geneve really needs a maintained C compiler. I'm not sure if gcc9900 supports Geneve OS?

[+dhe]

Maybe these could be modded into the case for quick and easy diagnostics?

 

https://www.amazon.com/MakerFocus-Voltmeter-Three-Line-Protection-Measurement/dp/B077ZQQQFC/ref=sr_1_2?crid=2J1YM6NWEPYHX&keywords=makerfocus%2Bvoltmeter&qid=1647035161&sprefix=makerfocus%2Bvol%2Caps%2C156&sr=8-2&th=1

 

 

 

 

[+FarmerPotato]

8 hours ago, dhe said:

Maybe these could be modded into the case for quick and easy diagnostics?

 

https://www.amazon.com/MakerFocus-Voltmeter-Three-Line-Protection-Measurement/dp/B077ZQQQFC/ref=sr_1_2?crid=2J1YM6NWEPYHX&keywords=makerfocus%2Bvoltmeter&qid=1647035161&sprefix=makerfocus%2Bvol%2Caps%2C156&sr=8-2&th=1

 

 

 

 

These are fun gadgets. See if your voltage is dropping…  could be tracked by the computer.

 

2-wire protocol, that might be I2C or other. Fun to wire up to CRU control with +1 chip. 
 

look for “accessories” that are in PMOD form. The CRU I/O card has 2x PMOD on the front. 

A case thermometer would be more important. similar gadget. 

 

Someone told me they drive a RGB LED inside their PC case to indicate CPU temperature! See that red glow coming out the cracks?  Better hope it doesn’t turn white!

 

 

 

 

 

[+FarmerPotato]

@dhe
I’m not playing with the case lately, and I did not decide if the front will be plastic or aluminum. Easiest thing ever to make rectangle holes in plastic.

 

The front connector panel has to change again anyway, since I thought of a good way to put connectors on both back and front without gobs of wires. 
 

 

[+FarmerPotato]

Got some time this weekend to go after a random memory problem.

 

Programs bigger than 512 bytes of ROM, flake out.  I wrote a MEMTEST utility and it reports many, many aliased ranges of ROM/RAM.  But sometimes reports perfect.  Some address line like A9 (flips every 512 bytes. A0 LSB) is not responding consistently.

 

I suspect it's the ZIF sockets.  I think I've learned my lesson about buying surplus to stock up my parts shelf. 

 

I tested bank bits.  The bank bits are stuck on all 1s, which explains why the pageable ROM bank is not page 1 nor page 0... it's page 7!

Similarly, pageable RAM bank is the highest RAM page, which explains why destructive test doesn't clobber page 0 (my workspace!).

 

 

The PLD I am using for paging, it tested out ok on the TL-866+ logic tester (I wrote my own tests). Then it failed on the XGECU T-56 without any changes... I moved along but now I suspect there's something up. Maybe I fried the chip? 

 

On a brighter note, 9600 baud works fine, and I can get a round of edit-assemble-flash-boot in about 2 minutes. 

 

[+TheBF]

1 hour ago, FarmerPotato said:

Got some time this weekend to go after a random memory problem.

 

Programs bigger than 512 bytes of ROM, flake out.  I wrote a MEMTEST utility and it reports many, many aliased ranges of ROM/RAM.  But sometimes reports perfect.  Some address line like A9 (flips every 512 bytes. A0 LSB) is not responding consistently.

 

I suspect it's the ZIF sockets.  I think I've learned my lesson about buying surplus to stock up my parts shelf. 

 

I tested bank bits.  The bank bits are stuck on all 1s, which explains why the pageable ROM bank is not page 1 nor page 0... it's page 7!

Similarly, pageable RAM bank is the highest RAM page, which explains why destructive test doesn't clobber page 0 (my workspace!).

 

 

The PLD I am using for paging, it tested out ok on the TL-866+ logic tester (I wrote my own tests). Then it failed on the XGECU T-56 without any changes... I moved along but now I suspect there's something up. Maybe I fried the chip? 

 

On a brighter note, 9600 baud works fine, and I can get a round of edit-assemble-flash-boot in about 2 minutes. 

 

When you get the memory sorted out, SPUDBUG compiles 2.25 lines per second over the serial port so that could improve your edit/assemble/run loop time. 

I should be able to speed that up by sucking the source code into a buffer and compiling from memory.

[+FarmerPotato]

4 hours ago, TheBF said:

When you get the memory sorted out, SPUDBUG compiles 2.25 lines per second over the serial port so that could improve your edit/assemble/run loop time. 

I should be able to speed that up by sucking the source code into a buffer and compiling from memory.

Yeah!  

If only I can get both ZIF sockets to make good contact at the same time, I can flash into the first and top pages of ROM.  And I know that RAM is good from A000-FFFE.  So the SPUDBUG loader could survive the trip from ROM to RAM.  Forth interactivity will let me create good scope traces!

 

I need to move fast and break things.

 

Toy BIOS memory map:

 

0000 16K ROM Page 0

4000 16K ROM Pageable 0-7

8000 16K RAM Page 0

C000 16K RAM Pageable 0-15

 

 

[+Ksarul]

What size ZIFs are you using? I always try to keep a few NOS Aries ZIF sockets of various sizes on hand. . .

[+FarmerPotato]

3 hours ago, Ksarul said:

What size ZIFs are you using? I always try to keep a few NOS Aries ZIF sockets of various sizes on hand. . .

Two 32-pin ZIF for holding 27C010 flash.