Any modern systems with just have a CPU and a frame buffer?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

psycopathicteen
Posts: 2910
Joined: Wed May 19, 2010 6:12 pm

Any modern systems with just have a CPU and a frame buffer?

Post by psycopathicteen » Fri Mar 01, 2019 11:19 pm

I'm interested in knowing if any modern system does it the easy way, and just has a CPU and video/audio buffer and nothing else.

User avatar
NovaSquirrel
Posts: 376
Joined: Fri Feb 27, 2009 2:35 pm
Location: Fort Wayne, Indiana
Contact:

Re: Any modern systems with just have a CPU and a frame buff

Post by NovaSquirrel » Sat Mar 02, 2019 12:37 am

Do graphing calculators count as "modern" if they're still being sold in 2019? Even ignoring stuff from 1999, the TI-84+ CE was introduced in 2015 and it looks like it's just got a framebuffer and DMA.

User avatar
Gilbert
Posts: 363
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: Any modern systems with just have a CPU and a frame buff

Post by Gilbert » Sat Mar 02, 2019 6:27 am

I think the Gameking is something like this, though how "modern" it is could be debatable.

Oziphantom
Posts: 776
Joined: Tue Feb 07, 2017 2:03 am

Re: Any modern systems with just have a CPU and a frame buff

Post by Oziphantom » Sat Mar 02, 2019 11:38 pm

Framebuffer as in zero GPU acceleration? Everything is going to have some form of GPU acceleration, even the old machines still have GPU acceleration.

User avatar
Dwedit
Posts: 4246
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Any modern systems with just have a CPU and a frame buff

Post by Dwedit » Sat Mar 02, 2019 11:46 pm

As in "no GPU acceleration" beyond having the ability to read out all video memory and send it to a display.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

Oziphantom
Posts: 776
Joined: Tue Feb 07, 2017 2:03 am

Re: Any modern systems with just have a CPU and a frame buff

Post by Oziphantom » Sun Mar 03, 2019 4:14 am

I think the last machine to do that was CGA, but even it had a Char Mode. Spectrum is pure framebuffer and nothing else. I think the BBC Micro and Amstrad have Char mode as well as bitmap. Oh wait Apple, yeah.. Apple IIgs, Macs up to(but no including) the G3 era? The Power Mac pages are very vague and don't mention graphics at all, the II didn't have any hardware acceleration though.

User avatar
Dwedit
Posts: 4246
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Any modern systems with just have a CPU and a frame buff

Post by Dwedit » Sun Mar 03, 2019 12:48 pm

Seems you're talking exclusive about PCs and ignoring everything that isn't a PC. Most PDAs (remember those!) had no hardware acceleration and just had a framebuffer.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

nocash
Posts: 1113
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Any modern systems with just have a CPU and a frame buff

Post by nocash » Sun Mar 03, 2019 5:00 pm

PCs did use bitmap graphics until including VGA and SVGA, I think wide-spread hardware accelleration came up with the switch from ISA bus to PCI bus (infamously resulting in glitchy mouse arrows in win9x with PCI video cards, unless disabling the accelleration). For slightly newer hardware, I think that the GP32 console was raw software with bitmap graphics, and I have heard about a mobile phone with VGA style graphics and built-in DPAD and buttons for gaming. But that's both about 10 years ago. Most modern hardware will also allow you to write to framebuffers - you don't have to use sprites or polygons or the like, even if the hardware has support for that.

But it may be increasingly difficult to find hardware without unneccessary extras. The hardware devrs today aren't shy of producing chips with 1600 configuration registers, even if one would have squeezed the same functionality into 16 registers a dozen years ago.
Even if you find a video controller without accelleration: I wouldn't be surprised if it would include stuff like brightness, contrast, and gamma adjustment (which alone might amount to a million of per-pixel multiplications per frame). And maybe also built-in MPEG encoding, programmable noise filters, uarts, infrared, usb, spi and i2c busses, backlight managment, flash memory, encryption hardware, thermometers, firmware updates, wifi, bluetooth, and ethernet.

psycopathicteen
Posts: 2910
Joined: Wed May 19, 2010 6:12 pm

Re: Any modern systems with just have a CPU and a frame buff

Post by psycopathicteen » Sun Mar 03, 2019 5:13 pm

I do wonder what the bare minimum Mhz speed it would take, say an ARM7, to make an NES style game without a graphics chip.

tepples
Posts: 21802
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Any modern systems with just have a CPU and a frame buff

Post by tepples » Sun Mar 03, 2019 5:28 pm

By "NES style" as opposed to "ColecoVision style", you include scrolling, correct? That depends mostly on whether the frame buffer's start address can be relocated to produce scrolling. If hardware scrolling in a dumb frame buffer is allowed, then Commander Keen in Marooned on Mars runs on a PC/AT with an EGA.

User avatar
slembcke
Posts: 170
Joined: Fri Nov 24, 2017 2:40 pm

Re: Any modern systems with just have a CPU and a frame buff

Post by slembcke » Sun Mar 03, 2019 6:42 pm

Probably not much? I remember playing smooth 60 fps games in 800x600/8bpp on a 30 Mhz 68k Mac with no hardware acceleration. 256x240 is ~1/8th as many pixels.


User avatar
samophlange
Posts: 46
Joined: Sun Apr 08, 2018 11:45 pm
Location: Southern California

Re: Any modern systems with just have a CPU and a frame buff

Post by samophlange » Sun Mar 03, 2019 11:41 pm

I’m pretty sure you can put a modern x86 in to real or protected mode and run vga mode-x. What exactly are you looking for?

User avatar
koitsu
Posts: 4216
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Any modern systems with just have a CPU and a frame buff

Post by koitsu » Mon Mar 04, 2019 12:21 am

The subject says "framebuffer", which to me means "a completely linear piece of memory". That rules out bitplane-based models.

Like samophlange, I thought of the standard VGA model on the PC, where you have these two choices:

* Standard VGA mode 0x13, which is 320x200 and 256 colours
* Mode X, which is 320x240 and 256 colours -- offering visually square pixels
* Mode Q, which is mode X but "tweaked", thus 256x256 and 256 colours -- many DOS NES emulators used this (I speak as the author of one!)

All these result in a linear framebuffer of sorts: a single byte of memory represents what pixel (in a palette index of 0-255) to visually show on screen. In real mode, the data is in segment 0xA000 or A000h; in protected mode it's 0xA0000-AFFFF or A0000h-AFFFFh. Example code.

All of this still works on PC architecture today, but of course present-day OSes etc. now inhibit you from doing anything with that memory (the last OS to let you play with it directly was, IIRC, Windows XP for specific DOS applications, using NTVDM).

I suspect the below answers are not what you're asking for/about, but I'll mention them anyway:

If you're wanting something that works with a present-day OS, I'm pretty sure the way this is accomplished (in Direct3D) is by setting up two triangles that thus make a square, and then mapping a texture across both of them -- your linear framebuffer then is that texture memory, which you can access directly IIRC. There's also using a locked RECT surface in D3D9. I believe there's a way to achieve this in Vulkan as well.

As for audio: good frickin' luck! I don't know of very many audio systems that worked that way to begin with. If what you're talking about is akin to, say, the old PC/DOS days with sound cards where there was a linear piece of memory your code was expected to update + tell the soundcard to play it (plus keeping track of where the card was in the buffer) -- and the hardware simply plays (and will loop) what's in the buffer -- AFAIK that is still the same model used today with DirectSound and other audio APIs.

In short, the "old way" of doing things -- the way that's simple and makes a ton of sense, gives the programmer the most control, etc. -- are going the way of the buffalo, replaced by layers and layers of abstraction, complications (no guarantee your code runs at a specific time/interval/whatever), and so on. A lot of this has to do with the fact that people's computer needs changed during the 90s and 2000s, alongside the introduction of multiprocessing. In exchange for the latter, we had to give up a lot.

Edit:

Oziphantom mentioned the Apple IIGS, so I'll talk about that. There's no video hardware acceleration of any kind of the IIGS, except maybe fill mode (you decide):

The IIGS's graphics are a linear framebuffer... kind of. The memory map looks like this:

Bank $E1, $2000-9CFF: pixel data
Bank $E1, $9D00-9DFF: scanline control data
Bank $E1, $9E00-9FFF: palette data

Pixel data represents the literal pixels of the two main video modes (320x200 and 640x200). In 320x200 each pixel is represented by 4 bits (16 colours), and in 640x200 represented by 2 bits (8 colours). I don't want to talk about 640x200 (it's a mess). There is no way to increase the vertical resolution. So on the IIGS, there's always a limit of 16 colours per horizontal scanline, but there's a nuance:

The scanline control data is a 200-byte area that controls what palette each individual scanline uses. Each byte represents a scanline (e.g. $E19D00 = scanline 0, $E19D01 = scanline 1, up to scanline 199). The remaining 56 bytes are unused. The format of the data is:

Bit 7: Graphics mode addressing (0=320x200 mode, 1=640x200 mode)
Bit 6: Generate IRQ when scanline drawn (0=off, 1=on)
Bit 5: Fill mode (0=off, 1=on; only available in 320x200 mode)
Bit 4: Reserved, must be 0
Bits 3-0: Palette number (0-15)

I forget exactly how bit 7 works but again I don't want to talk about 640x200 anyway.

Bit 5 / fill mode is kind of weird but useful in some situation: if the bit is set, any pixel with a value of $0 re-uses the colour of the preceding pixel on that scanline. So if pixel 0 was a value of 4, followed by 9 pixels of value 0, those 9 pixels would show value 4. Also, with fill mode, pixel 0 of that scanline can't be 0, otherwise you get weird behaviour. Many demos used this to achieve certain stuff, like giving the impression of full-screen horizontal text scrolling but with nothing else really visible (there's a demo that did this whose name I forget, else I'd find it for you).

The palette data is 512 byte area that defines what RGB values each pixel of the pixel data displays. There are 16 palettes, with 16 colours per palette; ex. palette 0 = $9E00-9E1F, palette 1 = $9E20-9E3F, etc.. The format of the palette data is as follows, with R/G/B being given 4 bits each:

Bits 15-12: Reserved, must be 0
Bits 11-8: Red
Bits 7-4: Green
Bits 3-0: Blue

So, you tell me -- does that count as a linear framebuffer or not? :P

The IIGS's graphics are kind of weird because of its memory map and backwards-compatibility with the Apple II and its bank shadowing (mirroring) capability and why certain memory accesses are at 1MHz rather than 2.8MHz. I started doing a write-up of it all from reference material, but then about 30 minutes in Googled and found that Eric Shepherd and Andy Mcfadden already explain it, along with just how unexpectedly powerful the IIGS's shadowing registers ($C035 and $C036) are. Eric talks about it but also uses GS/OS toolkit functions (ex. NewHandle) which confuses things a bit, but don't worry about that -- while Andy goes right for the guts. Both of them explain tricks that are used to achieve fast ways to copy data around, like relocating direct page and the stack and using pei copy data quickly (when mirroring bank $00 to $01, which then effectively let you map DP and the stack onto graphics memory). The nop-intermixed-with-pei thing at the end of Eric's reply is primarily a IIGS-specific thing (and even why people often say the IIGS runs at 2.6MHz rather than 2.8MHz). (Maybe me posting all of this gives some insight into why I talk about things like relocating DP all the time...)

All this brings me back to old times, and even reminds me why I loved PC graphics over Apple IIGS graphics so much: 16 colours per scanline really sucked for decent images. While the IIGS's palette-per-scanline thing is neat (and you can actually do a lot of really cool effects with this), you still couldn't display a GIF without applying dithering and so on to try and "make up" for it. The "peak" of displaying still images on the IIGS was what was called "3200 mode", where programs like DreamGrafx and Convert3200 by extending the palette count from 16 to 200 (one palette per scanline) purely by trickery in HBlank and tweaking palettes in real-time (200 scanlines * 16 colours = 3200 colours). You literally have *no* other CPU time available for anything -- I'm not exaggerating in the least -- displaying pictures this way... and you're *still* limited to 16 colours per scanline. I often thought the 3200 mode thing was a farce, and felt incredibly "Apple" in its modus operandi (kind of like false advertising), and was certainly invented out of spite towards PC and Amiga. All you had to do was give a IIGS person a GIF with a >16 colour gradient on a single scanline and laugh; but if the gradient was vertical, yeah, the results look better than a PC. Meanwhile, the Amiga with its HAM mode sat laughing at everyone.

User avatar
slembcke
Posts: 170
Joined: Fri Nov 24, 2017 2:40 pm

Re: Any modern systems with just have a CPU and a frame buff

Post by slembcke » Mon Mar 04, 2019 8:41 am

psycopathicteen wrote:This one?
This one: https://en.wikipedia.org/wiki/Macintosh_Quadra_650

Maybe more to the OPs question. You can certainly set an RPi up to operate in framebuffer mode, and that definitely has enough CPU power to do all sorts of fancy framebuffer style graphics.

Post Reply