Hacker News Reader

> 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.

Let me take hougaard's reply first here...

> 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.

Sweet. That much VRAM will pretty much eliminate the need for the video system to be on the main bus.

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.

Even on the NES the PPU RAM is on a separate bus

What I took exception with was:

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 :)

> Using 256 color bitmap, select the 320200 resolution. 64k for one full screenbuffer.

Based on what I see here, you've got a good explanation: https://github.com/FrankBuss/x16-demo/tree/master/assembly

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 assumed they’d just add more ram to the Vera chip, but I don’t know the details of if that’d be possible.

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!

> It has a tile mode. That's going to be how larger images are handled.

Perhaps. But in the video, he said mode 7, and the VERA module documentation https://github.com/commanderx16/x16-docs/raw/master/vera-mod... lists that as a bitmapped mode, 8 bits per pixel.

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.

That same documentation shows 320 pixels per line too, in mode 7, depending on tile width.

More than plenty, IMHO.

A simple design will get hacked on, expanded, etc. That is definitely my preference.