icestudio VS blockprotocol

In fact that docs are out of date and even more boards are supported and you can find the list directly in icestudio menu. If you want to check it beforehand, i think it's possible to see the list here in source code:

https://github.com/FPGAwars/icestudio/tree/develop/app/resou...

This is crazy helpful for beginners: https://github.com/FPGAwars/icestudio

They have drag and drop visual gates and cores with very well documented examples.

This is the project: https://github.com/FPGAwars/icestudio

I am slowly moving off my retro computing hobby. The last straw was recent chip shortage and crazy prices. I bought myself a copy of "The 8088 Project Book" and I wanted to build the presented 8088 breadboard computer. Guess what? The only factory that was building compatible 8088/8086 chips caught fire (Renesas factory fire). I had to order 20 year old chips for the price x2 of the new chips. But not only that, some chips are either unavailable or crazy expensive due to a lot of recent interests in retro-comp.

In other way, the hobby became unreasonably expensive for me. So I decided to move my interests into FPGA. The fun is almost the same, but the cost is way lower (you only need to buy a good board and a book, and you are set up). I started with this extremely simple IDE: https://github.com/FPGAwars/icestudio

As for this build, I have mixed feelings about using FPGAs to revive old computers. Can't we create something new out of it? It would be fun to have a _modern_ FPGA based SBC with easy to program graphics (memory mapped) and with simple device interface (I think USB is way too complicated for hobbyists). Just something powerful enough to create games, yet simple enough so that teenager can write a simple OS in his spare time.

Relevant to this conversation, I saw Joel Spolsky giving a talk about his new big project/stab at addressing this problem The Block Protocol.

1) The spec says that a block package includes its source code, and the block hub seems to be a browser of block packages, but it doesn't give me the full view into said block packages. Is there a reason for this? Is it on the to-do list?

It's on the to-list indeed - we are going to add links to the source of blocks. The package for distribution will typically be minified and less illuminating, although we can look to expose that too (as well as making it available for request via the API).

2) What's going on with the type signatures here?

The type signatures on functions in the spec definitely need cleaning up to be consistent and more helpful. They are pseudo-code. There are TypeScript types for them (https://github.com/blockprotocol/blockprotocol/blob/main/pac...) which won't be much use to you, but I am including in case they are of someone else.

The schema you mention in the Hub is autogenerated from the TypeScript interface for the block, which can lead to weird artefacts of the sort you identify. We need to add custom codegen to better handle this. It should valid JSON Schema.