Bytecode Renderer

[jthwho]

I'm working on a bytecode 2D renderer for the VGA pico for my own purposes (to make graphics rendering faster than doing it natively on the 6502). It will work by putting bytecode data into the xram then asking running the interpreter on that memory via a register access. The interpreter will run on the VGA pico, and will draw on any of the supported 2D surfaces (held in another segment of xram). I'm wondering if this is something that'd be interesting to others? And if there's sufficient interest, would it be considered for inclusion in the default VGA pico build?

If this is of interest to you, what sort of drawing primitives would you like to see? So far, I've got point, line, and basic polygon (filled and unfilled) operations accounted for, as well as some basic looping and conditionals.

As soon as I've got the first pass working, I'll post to my GitHub. Right now, my first pass includes the implementation of the actual drawing library (a C library, which would be the only thing that runs on the pico) as well as an assembler to build the bytecode and an SDL based C++ application to interpret and test the bytecode. Once I have it further along, I'll start working on adding it to the pico VGA code.

[rumbledethumps]

I'm not sure how this would be possible without moving to a pre-emptive scheduler. The VGA system won't even tolerate clearing a text screen without a stdio buffer overrun. There's also a scanline underrun problem. And you'll need to solve the xram being out of sync before something like this would be considered for main. Probably other stuff too since this isn't a problem I've given much thought.

[jthwho]

I've been thinking along the same lines. It sort of looks like maybe that's where you're going for core0, but not sure. Happy to help out here if that's something you're looking to do. As for the xram sync, not sure how that'd get solved if the 2d state machine is running on the VGA (since the pix bus is only one direction, correct?) Should I consider running the render on the RIA instead? I suppose it wouldn't matter, but I had assumed the RIA was probably even more resource constrained given all it has to do.

Either way, good to know what you're expecting for merge consideration. Not sure if I'll get there, but I'll certainly work that into how I start to work the problem. Anyways, thanks for the great body of work so far. You've done a great job putting together the toolchain; it has been a pleasure to use so far. Good 6502 assembly nostalgia to modern day convenience ratio ;-)

[rumbledethumps]

This type of co-processing wasn't common until the 32-bit era. 8-bit computers with a GL, like the TI/99, didn't do it for performance. That's why I didn't design for it. The goal was to compete with the commercial modern-retros on price, not crush them with performance or features.

[jthwho]

Totally agree with you, and I think you're on the right track optimizing for BOM cost. Part of this adventure for me is having a 6502 machine I can use w/ my daughter. A $600 or whatever machine would be out of the question, but this is absolutely the right price point for this thing.

As to the larger issue of performance in 8-bit retro, for me it has always seemed sort of arbitrary. Where does one draw the line between what's retro and what's modern? If we're really going to be pure about it, then I guess ASIC design should be on the table. Because ASIC design was very much alive and well in that era. Actually the amount of ASIC design back then has always amazed me, both with the crap tools they had and how ubiquitous it was. But I guess that's just what you had to do to meet a commercial price point. And I guess that's sort of where I see the RIA and VGA pico in these designs. As very powerful, albeit bordering on anachronistic, ASICs.

And you know, why not crush them with price and performance :-P