Notices by Techokami (techokami@woof.tech)

Wait wait PhysX (ALL OF IT) is now FOSS????? https://github.com/NVIDIA-Omniverse/PhysX/discussions/384 HUH?????

Why is it called "OpenVMS" if it is closed source and proprietary? :blobfoxthinking:

@lanodan Yes, yes it is. Support for i960 was marked deprecated in 3.3 (which means it will always nag people with warnings), and made obsolete in 3.4 (errors unless you pass certain options)
From what I was reading of old mailing list postings, something got intentionally broken with i960 in 3.4, so I'm going with the last actually-supported version here in case the breakage originated in 3.3

@lanodan My current plan is to try and make an older GCC compile and use that as a cross-compiler. Though it's going to be rather interesting...

@lanodan that is rather cursed and a bit convoluted... you're saying that I should re-implement an entire ISA with pseudo-instructions to trick an x86-only assembler into making raw i960 binaries?

@lanodan Yeah I'm having trouble understanding what you're suggesting. nasm is for compiling for x86 targets only; it does not support assembling for the i960, which is the target CPU of the fantasy console.

As for using FORTH as the interpreter, that might be neat, but I get the feeling that it would be a lot more challenging for people to get started with compared to BASIC or Lua :blobfoxthinking:

@lanodan nasm doesn't do i960?

Looks like the most reasonable solution will be to build an older GCC (most likely 3.2.x) as a cross-compiler and ship it as a dedicated SDK toolchain. That will allow for assembly, C, C++, and some other languages as well. Something to look into more deeply over the weekend.

Okay, so, while we're thinking over the GPU side of things, there's a bigger issue that I will need some assistance and ideas for: actually making code to run on this platform.

The idea I have is that there will be two main ways of creating software: interpreted code and machine code. The former would make the platform feel like other fantasy computers (like PICO-8 and TIC-80), while the latter will actually take full advantage of the i960 CPU. But we need to solve the latter before we can tackle the former.

So the first big question is: what is available for i960 assemblers? GAS used to support i960, but it was ripped out at some point? Documentation is very unclear about which platforms are currently supported. Intel had an official assembler and I think it's here: https://github.com/biggestsonicfan/i960-CTOOLS-with-NINDY I can't seem to figure out if LLVM supports i960, the documentation on supported target architectures is missing. And there is a product by Archelon that costs ONE THOUSAND DOLLARS PER PERSON.

With an assembler, other languages should then be able to be supported, like C. If LLVM actually does support the i960, then Rust would also be an option for those that want it.

Once we have all THAT sorted, then the focus can move on to the interpreted language. BASIC is a period-correct option, but I have a feeling that most people would prefer something like Lua or maybe even Python instead. But it is hard to figure out what to use when we lack the ability to assemble code in the first place!

And in case you think I'm joking: https://www.digikey.com/en/products/filter/embedded/microprocessors/694?s=N4IgjCBcoKwAwDYqgMZQGYEMA2BnApgDQgD2UA2iAMwwDsALGLSALrEAOALlCAMqcAnAJYA7AOYgAvsQC0AJmQg0kQQFcipCiBitpIGQE5FytRrKRKEFpJtA

Also, just to add on to how the MIL-STD-1750A was so cursed:
1) The UK's Royal Air Force attempted to implement this with AMD 2901 bit slice processors. This broke men that were trained to kill. The paper about this implementation is declassified: https://apps.dtic.mil/sti/tr/pdf/ADA114029.pdf
2) Via DARPA, the US military bankrolled the development of RISC CPUs *specifically to get the hell off this thing.* They migrated to MIPS just to get away from this thing.

Right, so, time to start thinking about implementations and design decisions. First off, there is in fact a gaming platform that used the i960 as the main CPU, and it was the Sega Model 2 arcade system! I don't think it would be wise to completely copy this, as it uses a very complicated and proprietary set of graphics chips, but MAME will have the CPU emulated, so we can borrow that for a FOSS-based fantasy console emulator. In terms of making something physical, I would love to find the Model 2's schematics, as that would help with the multiplexing shenanigans. For video, that's going to be tricky. Having a very strong sprite-based system would be, IMHO, a good idea. Though being able to freely draw pixels in a bitmapped form would also allow for things like Doom to be possible. And people seem to expect polygon drawing support for something that's 32-bit... though I would like to avoid making it cursed like the Sega Saturn's polygons. Doing this all in a software environment is easy, but making a hardware counterpart will be rather sketchy. Anyone have thoughts about this?

Also, if you want to learn more about the i960, this is better than anything else I could write: http://www.righto.com/2023/07/the-complex-history-of-intel-i960-risc.html

surprised nobody said anything about my comment on the Sega Saturn's cursed polygons :blobfoxthinkowo:

So my good friend @lifning just gave me a concept for a GPU that might have some of the cursed-ness of the Sega Saturn, but actually sounds pretty fun! We'll have to bang on this concept for a bit in private.

@lifning so here's a quick rundown of some details about the concept we've been hashing out:
-It will feel era-appropriate for a CPU like the i960 but not be too limiting
-Mainly 2D-oriented but with a 3D coprocessor for doing basic 3D rendering
-Graphics are stored in 4 "charblocks", which are 512x512 pixel, 256-color bitmaps. There is only one palette, but it can be redefined with BGR555 colorspace
-The 3D coprocessor overwrites most of a charblock with the rendered 3D output, and can then use those tiles to display onto one of the 4 tile layers
-The tile layers are affine-transformable
-Screen resolution is 320x240
-Sprites perform double-duty as polygon quads
-Still haven't gotten everything concrete here, but we're thinking of somewhere between 1024 and 2048 sprites/quads, allowing for a crapton of sprites but a more basic 3D experience

I'll let @lifning chime in with other details that can be shared, if she wants. We'll post the full conceptual spec when we feel it's ready

3RD PLACE (25%): WC65C265
It's the 65816, but they actually fixed my biggest gripe: the weird, multiplexed address/data bus! Initially, I didn't even know they made that! It's also another microcontroller-y solution, but it doesn't provide a whole lot of RAM (it does provide enough for Zero Page and the Stack Page!) but it has a more interesting set of built-in peripherals, including a tone generator that's intended for telephony shenanigans, but it can just be used as a pair of mono sine wave channels to mix in with whatever the audio solution would be. I was hoping this one would win, it actually sounds really interesting... if anyone has a 65816-compatible compiler that's cross-platform and at least freeware.

2ND PLACE (34%): MIL-STD-1750A
A decomissioned and declassified military spec? No, that's too cursed... and it nearly won, oh dear lord. This is effectively a public domain ISA. While there are some companies that still produce CPUs that implement it, it's mainly for space-related stuff (because it's all rad-hardened) or are not available to be bought by normies, so a physical implementation would have to be done with FPGAs. It's a pure 16-bit architecture. By that, I mean the data bus is 16 bits, the 16 registers are 16 bits each, the address bus is 16 bits, and the smallest data unit you can work with is 16 bits. Interfacing with anything 8-bit is going to be a nightmare. It is possible to increase memory with the MMU specified in the documentation, but that's more of a bank switching solution. You can read the ISA docs here and take a sigh of relief at what was narrowly dodged: http://www.xgc.com/pdf/mil-std-1750a-1.7.pdf

1ST PLACE (35%): Intel i960
How the hell does Digikey still sell this? This is a RISC CPU by Intel that was created after the disaster that was the iAPX 432. It's a... relatively normal 32-bit RISC CPU! It was intended to be used in a computer platform co-developed by Siemens called BiiN, which was Ada-based, but that project tanked and Intel re-marketed the processor for other use cases. It couldn't compete with SPARC and MIPS, but it actually did well in embedded solutions. Not to be confused with the i860, mind you; that came out years later, was a 64-bit solution, and brought back all the problems the iAPX 432 had. The people that made the i960 went on to make the Pentium Pro; the people that made the i860 went on to make Itanium.

Only downside? Apparently the address and data bus are multiplexed :( So someone else has to develop a circuit to properly demux this nonsense if this were to become a physical device! But hey, aside from that, we can start thinking of better things, like what to do for graphics and audio. We get a full 4GiB of address space to play with!

Congratulations, you all avoided actual horror and instead only got mild horror! Time to reveal the options, in ascending order of rank.

4TH PLACE (6%): eZ80
It's the Z80! But with an expanded 16MB address space that doesn't require any cursed bank switching! It extends a bunch of register pairs to become register trios for the 24-bit address bus. It's generally only available in microcontroller-y form, but this provides a buttload of bonus peripherals (including serial ports, as well as built-in flash ROM and RAM) which would have simplified development. Though, this option would have made it directly compete with the Agon line of homebrew microcomputers, which use the same CPU. It's been done before, but still a fun choice.

@mos_8502 for people who had trouble trying to find out exactly what Agora in this context is (like me!) it's this: https://github.com/AgoraDesktop