> If I'm reading this correctly, its private video memory won't hold a full 640x480 256 color bitmap image, which would be ~300k. So it seems like you'd have to load video memory with the second half while it is drawing the first half (and vice-versa).
No, I think this is incorrect.
The reason only half the bitmap is displayed in the demo on his latest update is that the image has to be loaded into low-RAM before being copied to video RAM. There's only about 40K of low-RAM, so not enough to hold the image.
He even mentioned in the video the need to build a custom loader to load the image into low-RAM a piece at a time, with each piece being copied to video RAM after it's been loaded. Their demo doesn't do this yet, hence only half the image displays.
> No, the half image problem showed in the video, is that the available low memory of the X16 is around 38K, only enough for half a vga image...
No, 38K isn't half of a VGA image. 38K is only an eighth of a VGA screen at 640x480 pixels, 1 byte (256 colors) per pixel. So 38K is only 60 lines tall.
Bartreadm the first part of your reply is essentially the same as the one above. But I like this second part a bit more:
> He even mentioned in the video the need to build a custom loader to load the image into low-RAM a piece at a time, with each piece being copied to video RAM after it's been loaded. Their demo doesn't do this yet, hence only half the image displays.
Can I be honest? I don't think that makes sense either. Here's why:
Every pixel of video data needs to be streamed to the video co-processor one byte at a time. (That's a known hardware limitation of their design.) Even a 6502-based GIF decoder works no more than a handful of lines at a time when decoding a static image.
In this architecture (and with any reasonable image decoder), there just isn't a need for the entire image to be decoded into main memory before streaming it into video memory. In fact, back in the day, it was possible to print full-color images to a printer (Okidata Okimate 10 or 20) that far exceeded what you could do on the screen in terms of color and resolution, and for essentially the same reasons.
Their technical specification clearly attributes the VERA module as only having 128K of video memory. 128K is just enough to display 42.5% of a 640x480 image. That's almost exactly what you see happening on his screen. Almost half.
So this goes back to what you said.
In order to display more, they'll need some more complicated tricks. They'll need to load the image, and while the video co-processor is in the middle of outputting the image and just as or before it exhausts the first half of the screen, it needs to overwrite what's currently in video memory with the rest of the image. And that'll need to be repeated for every video frame, or 60 times per second in the US.
So yes, he'll have to load the image into low-RAM a piece at a time. But it is because their video co-processor can't hold the entire image in memory so they're using main system memory and raw CPU power to work around it. They can work around it with more clever code, but it is a hardware restriction.
This does do a good job of demonstrating the kinds of games we had to play in the 80s to get the most out of our early consumer PCs.
As restrictions go, I'm OK with this. I looked into doing some Atari 800(XL/XE) coding and for most any graphics application, you're bottlenecked by what you can keep around in main RAM, plus the limits of what you can program ANTIC/GTIA to do per scanline. Programming the scanline interrupts, you can manage to do quite a lot, and similar tricks with VERA are likely(fingers crossed). A lot of the latter day demoscene work on Atari relies on aftermarket RAM upgrades to unleash more of the raw power of the graphics hardware.
Of course, the X16 already accounts for that with its banked 2Mb RAM. Large RAM effectively means that most software for the platform can be single load, streaming in whatever is needed 8k at a time instead of going to storage media. But even so, a full 640x480 256 color image is so large relative to the RAM size that it's likely to be relegated to splash screens and demo effects.
No, I think this is incorrect.
The reason only half the bitmap is displayed in the demo on his latest update is that the image has to be loaded into low-RAM before being copied to video RAM. There's only about 40K of low-RAM, so not enough to hold the image.
He even mentioned in the video the need to build a custom loader to load the image into low-RAM a piece at a time, with each piece being copied to video RAM after it's been loaded. Their demo doesn't do this yet, hence only half the image displays.