Notices by Studio 8502 :verified: (mos_8502@soc.studio8502.ca)

@thomasfuchs Well poop.

@gnutelephony I long ago gave up trying to fix people.

I should be allowed to physically beat with a cane anyone who praises or defends Elon Musk on social media.

Fuck, at least Gates is trying to get people vaccinated, that’s *something* productive.

Is there a survey yet of mastodon instances which are and are not blocking Threads?

I keep trying to get into these book series everyone seems to like, and they're all the literary equivalent of the machine in a Japanese toilet that makes the sound of water flowing over rocks so nobody hears you violently shitting yourself.

Hey, corpo fuckwits: I can’t physically stop you replacing your human staff with language models, but don’t be surprised when your attempts to market shit to me get diverted to my own life model decoy, who has all my preferences but no money or authority to purchase anything.

So, I would say that we now have a credible, manufacturable design for the Sentinel 65X. Doubtless there will be many little refinements as it grows into a real product, but the core design seems to have settled into a form that is practical to build.

So the next steps are to design the developer harness for the clock port which @swetland proposes to make, and to design the Rev0 PCB, and to have a small test batch made.

This is where I begin to get neurotic about the whole thing.

Let’s talk kernel API.

On the 6502, normally your kernel is just a bunch of library routines and an interrupt handler. You access it by the JSR instruction. That’s not really practical on the 65816, though, because of the program and data bank registers and movable stack and direct pages.

So what you want is an interrupt based API. 16 bit CP/M, DOS, and Linux on x86 use software interrupts to trigger kernel functions. The specifics differ, of course.

65816 has two software interrupt instructions: BRK and COP. Each has its own vector in memory. BRK is usually meant for inserting breakpoints. COP is nominally meant for invoking coprocessor functionality, but no such coprocessors exist. Of the two, COP is this more useful as your kernel API interrupt.

On x86, you get numbered software interrupts, like int 21h and int 80h. 65816 doesn’t really have that. It can emulate it, but the costs outweigh the benefits in my book.

So, you have the ability to say “call the kernel”. What part of the kernel are you calling? How are you passing arguments? How are you returning values? Basically, what is the kernel calling convention?

I want fewer, higher quality products that last longer, cost more, and were made by workers who can afford to feed their families and own their home.

But the world isn’t ready for that yet, apparently.

@gnutelephony I don't know much about that. There are lots of designs probably better suited to that than whatever I can come up with. Cheaper, too, most likely. But I would consider it a stunning success if it sold 1,000 units. Retrocomputing is a small world, and it's really tough to get people to pay hundreds of dollars for a machine with zero (at the moment) software.

Okay. Big old image heavy thread. There will be no alt text, because alt text that accurately describes schematic diagrams would get real repetitive repetitive real real fast fast. Sorry.

Schematic review, a section at a time. Let's start with the CPU. The W65C265S, clocked at 8MHz. I doubt I got anything wrong here. Capacitors are 1%, 0402 SMDs unless otherwise noted. The CPU for this revision is a PLCC84 (SMD socket) because I have a tube full of the things on my desk.

#sentinel65x

Our various active-high/active-low signals get appropriate pull up/down resistors; 0402 SMD again.

Glue logic is an ATF22LV10C programmable logic device. Cheap and cheerful, even if CUPL *sucks* so *hard* as an HDL. The code for this is ~90% written.

SRAM and ROM are 512KB each. SRAM is a TSOP, ROM is a socketed PLCC. Nothing complex or innovative or even clever here -- ROM gets selected by the /LOROM or /HIROM signals through the /ROM0 output of the glue chip.

The FPGA for the VERA is only very slightly different from the X16's implementation. It was more efficient on hardware to make the VERA IRQ output active-high, since I had an extra active-high interrupt line in the CPU to use up.

An FPGA needs configuration ROM. Here, just a cheap and cheerful SPI flash chip.

The VERA outputs digital audio over I2S, which feeds this DAC. Again, cheap and cheerful.

The VERA audio, processed by the I2S DAC, gets piped to this mixer circuit to be mixed with the line-level audio from the expansion cart port, and output to two RCA plugs, exactly like the Amiga had. Not using mini-plug helps remind that this is line-level audio, not suited for headphones.