David Murray (aka the 8-bit guy) has a plan to build the "Commander X16", a new 6502 based computer that is philosophically similar to a VIC-20 but has more RAM (2MB), a higher clock (probably 8 MHz) and an FPGA to do VGA video. It might not be on the radar of people here because of some odd choices, like using a Facebook group as the primary discussion forum.
I really can't wait for that to happen. I'm going to be throwing money at that project like crazy. There's already an emulator for the OS [1]. I had never done any C64 programming, but I was able to do some BASIC tutorials using it with the exception of any video stuff, since that will be different on the X16.
He did some videos about the project [2] [3].
I absolutely hate that he formed the group on Facebook. I'll be missing so much.
It's still primarily on Facebook, unfortunately, but the forum is starting to finally gain some momentum as well. Lots of information on the project in there.
Some good discussions on other retro topics too. Worth a visit.
His project certainly has my attention! Only two things have me concerned right now: cost (the question of if it can reach scale) and video.
His current choice for a video co-processor "Vera" excites and concerns me in equal measure. At the top-end, it outputs to VGA with a 640x480 bitmap mode using an an active palette of 256 colors (out of 4096 colors) per pixel. It supports 128 sprites and interrupts (used to indicate sprite collisions, an active video line, or vsync). All that sounds great, doesn't it?
The majority of what I don't like is that the video processor is essentially off of the main bus. The CPU only has access to video through a set of 8 registers (plus interrupt). So it has 128k of private video memory and an additional 16k for video registers, palette, and sprites.
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). I'm also wondering if an old-school technical like page-flipping is really going to be possible here.
EDIT: Or to put it another way, because the video co-processor doesn't have enough memory to hold the entire image all at once time, and because the video co-processor cannot access main memory, just to hold a static photo-realistic image on the screen you're going to have to constantly copy ~300K of pixels from main memory into video memory... each and every frame. If I'm doing my math right, that'd be more than 36 million operations per second just to pump the data into the video co-processor? It reads to me like the co-processor isn't doing a great job of offloading work from the CPU here.
All of these concerns might be dismissed simply by saying "the CPU is much faster than those other 8-bit platforms you're used to". Assuming that isn't the case, I'd probably like to see the video co-processor have enough memory to hold two full pages of bitmapped video. I'd also greatly appreciate it if they could arrange for direct CPU access through one of their pre-existing banked memory regions.
Still, I'm eager to see how David's project progresses.
> 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.
Last night a new version of the vera documentation was uploaded (https://github.com/commanderx16/x16-docs/blob/master/vera-mo...). It looks like the changes will allow for more memory, up to 1mb. Of which the last 64kb seem to be reserved for the registers, so max 960kb.
Constantly copying data to the VERA (chasing the beam/screen), seems unpractical. The 6502@8MHz can never move that much data.
The problem is that the 6502 can only address 64K which includes ROM and IO Space so for any acceptable resolution you need tricks like bank switching and/or a seperate memory bus.
1. Not enough video memory to contain a full Mode 7 image on the VERA co-processor.
2. All co-processor access (including video memory) has to go through eight registers starting at $9F20.
No problem here with bank switching. I think that's great!
Using 256 color bitmap, select the 320200 resolution. 64k for one full screenbuffer. The 640480 is still useful for sprites and tiles, but I think it will mostly be used for text.
8 bit computers always have a lot of limitations. And these limitations have sparked a lot of creativity :)
Their original image was 64K. They cut it down to 34K (+ 512 bytes) and then they included it in their binary (rather than loading from a file).
So it seems that David was correct in his explanation. They could only display about half of a 320x2X0 image because they ran out of low memory.
But it also seems that VERA doesn't have enough video memory to hold a 640x480 8bpp bitmapped image ("Mode 7"). 128K of private video memory just isn't enough unless they start playing tricks.
> 8 bit computers always have a lot of limitations. And these limitations have sparked a lot of creativity :)
I really am curious to find out if they plan on adding more memory or if this is going to be one of those quirks we'd have to really work to take advantage of? :)
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 and "streaming" to the video chip from a storage device or the high memory is not supported yet.
I'd hope so. Or they could leave it in as an old-school quirk that you have to hack around in order to get the most out of a bleeding-edge vintage home computer. I'm not sure of their intent here?
There's this clip https://www.youtube.com/watch?v=sg-6Cjzzg8s&t=2082 from his "Building my Dream Computer - Part 2". I'm kind of wondering if David understands the issue, or if he just had problems communicating it to his audience, or if I'm just plain wrong and this clip is just a coincidence?
It has a tile mode. That's going to be how many larger images are handled.
Given robust tiles and sprites, there really isn't a need to hold an entire screen in RAM, and given one does not exceed the sprite / line limits, nor is there a need to double buffer it.
Edit: For a smaller bitmaps, one could just make a buffer anyway. Dedicate X number of tiles to that bitmap, and another set for a buffer. Update one set, switch to display, update the other set. Collections of sprites can do this too. For use cases that involve part of the screen, I would imagine this working fairly well.
And one will need to write a little loader too. Fetch graphics assets, copy to video system, update registers, fetch more graphics, copy to video system, wash, rinse, repeat.
When the final program is running, that cache of graphics can get updates pretty much anytime those assets are not being used directly. (maybe directly too, depending...)
That said, yeah. I hear you. Part of the fun, in the retro scene, is racing the beam to draw more than one would expect. But, this seems well specified in my view.
While it's fun, having to do those tricks shuts out a lot of potential users. And it's those potential users we all, given interest in this sort of thing, want!
Quite some time back, a BASIC compiler for the Atari 2600, AKA VCS, was created. And it was super simple, offering up a basic COMBAT type kernel, with a score and a couple other little options.
Early in the development cycle, I knocked out a BREAKOUT type game, just as proof of concept. Took about an hour.
Once it released, tons of people started making goofy little games. A fair number of these were pretty good fun, and a few of those ended up "published" by some small time retro shops who make carts and media for old systems.
If David hits this just right, a similar thing can happen, and if it does, there will be a lot of fun to be had.
See Batari Basic for Atari 2600. A lot of games got written. It's impressive in that some of the people who wrote them really did not know much at the time. They just jumped in and made do with what few choices were available. That limited set of choices turned out to be very good at focusing people on gameplay. There was not too much else!
Now, as to why it's done the way it's done?
Simplicity. That's also why they didn't go with the 65816, which is a shame, but not a deal breaker. Too bad 65802 chips, which are pin compatible with this and many other computers, offer up the more powerful instructions without also offering up the multiplexed data / address bus. They are hoping to clock at 8Mhz, and that already weeded out AY sound chips.
They want a dev cycle that is sane and a part count that is also sane so they can hit a price people will pay. IMHO, totally fair call.
Putting the video on the main bus is an order more complex than the path they are taking right now. I'm pretty sure I saw an 8 bit parallel interface there too.
That means the same video system can be used on a number of older computers, not just this machine. Honestly, I doubt that will see too much use, but who knows? It could!
However, I do have some experience creating complex images on an 8-bit machine using tile mode (using interrupts to progressively load new character sets while the image is being rendered by the video chip). There is a place for each. (I believe it might have been used in Super Mario type image they demonstrated?)
> Now, as to why it's done the way it's done? Simplicity.
Yup. Hopefully I've made that design decision clear for those who might have missed it, and I'd certainly like to encourage them to see if they can improve upon this one particular architectural decision.
