the -o3, it does nothing
July 28, 2022 10:33 AM Subscribe
A 1977 Commodore PET as a 30 fps Youtube viewer.
This Youtube video about building the Youtube player does not include a recursive section where the player being built plays the video explaining how it works.
Previously, in the same spirit but by a different tinkerer, playing a Super Nintendo game on an original NES.
This Youtube video about building the Youtube player does not include a recursive section where the player being built plays the video explaining how it works.
Previously, in the same spirit but by a different tinkerer, playing a Super Nintendo game on an original NES.
Huh, I've never seen a rounded Commodore PET like that. The ones we had in high school were very squared off looking.
posted by octothorpe at 11:05 AM on July 28, 2022 [4 favorites]
posted by octothorpe at 11:05 AM on July 28, 2022 [4 favorites]
I'm not sure I could love this more.
posted by SNACKeR at 11:07 AM on July 28, 2022 [4 favorites]
posted by SNACKeR at 11:07 AM on July 28, 2022 [4 favorites]
I do not accept the premise. The PET is being used as a dumb video card. It's doing nothing but a memcpy every frame, moving already processed pixels (character codes) from external dual ported ram to its own video buffer. The dithering is moderately interesting, but again, all the magic is happening on a dual core ARM CPU running at a couple GHz hanging off the back.
I was hoping for at least a little of the work being done on the PET but as the guy documents, there's just not enough CPU to do much of anything to 2000 bytes at 30Hz on that thing.
posted by seanmpuckett at 11:46 AM on July 28, 2022 [10 favorites]
I was hoping for at least a little of the work being done on the PET but as the guy documents, there's just not enough CPU to do much of anything to 2000 bytes at 30Hz on that thing.
posted by seanmpuckett at 11:46 AM on July 28, 2022 [10 favorites]
That's a fair criticism, but it still says something interesting about the evolution of computing in the past 45 years. You have this top-of-the-line artifact from the past, and you'd like it to write its video memory to the screen thirty times per second. Great! It has time to do literally nothing else.
The Raspberry Pi programming side is also interesting. I was surprised at the slow running time to downsample a low-resolution video into 2000 characters, given that the Pi has high-definition video output. One of the times I played with a Pi, the distro came with a full-resolution copy of an open-source animated movie just so they could say, "look, video!"
I suspect the reason for the slowness is that the Pi's on high-definition video runs on dedicated graphics hardware with good parallelism and direct memory access (even if that graphics hardware is built into the CPU). Meanwhile the pixels-to-characters approach involves lots of comparisons and has to run on the CPU where there is some parallelization, but not nearly so much. This is kind of the exact same problem that the Commodore has, where the CPU has to spend all its time doing a job that might be better accomplished with dedicated hardware.
posted by fantabulous timewaster at 12:22 PM on July 28, 2022 [2 favorites]
The Raspberry Pi programming side is also interesting. I was surprised at the slow running time to downsample a low-resolution video into 2000 characters, given that the Pi has high-definition video output. One of the times I played with a Pi, the distro came with a full-resolution copy of an open-source animated movie just so they could say, "look, video!"
I suspect the reason for the slowness is that the Pi's on high-definition video runs on dedicated graphics hardware with good parallelism and direct memory access (even if that graphics hardware is built into the CPU). Meanwhile the pixels-to-characters approach involves lots of comparisons and has to run on the CPU where there is some parallelization, but not nearly so much. This is kind of the exact same problem that the Commodore has, where the CPU has to spend all its time doing a job that might be better accomplished with dedicated hardware.
posted by fantabulous timewaster at 12:22 PM on July 28, 2022 [2 favorites]
I just wasted a fantabulous amount of time watching that, so checks out!
posted by maxwelton at 12:34 PM on July 28, 2022
posted by maxwelton at 12:34 PM on July 28, 2022
I do not accept the premise. The PET is being used as a dumb video card.
And as the video makes pretty clear, it was only barely possible to do even that, requiring hand-tuned assembly on both ends and custom interface hardware in the middle.
Relative to the normal experience of interacting with a PET, just seeing that it's actually able to get data onto the screen that quickly is a startling result.
posted by automatronic at 12:38 PM on July 28, 2022 [4 favorites]
And as the video makes pretty clear, it was only barely possible to do even that, requiring hand-tuned assembly on both ends and custom interface hardware in the middle.
Relative to the normal experience of interacting with a PET, just seeing that it's actually able to get data onto the screen that quickly is a startling result.
posted by automatronic at 12:38 PM on July 28, 2022 [4 favorites]
just seeing that it's actually able to get data onto the screen that quickly is a startling result.
Is this one of those cases where you shouldn't complain if what your dog says is dumb, you should be impressed that it can talk at all?
posted by clawsoon at 12:40 PM on July 28, 2022 [26 favorites]
Is this one of those cases where you shouldn't complain if what your dog says is dumb, you should be impressed that it can talk at all?
posted by clawsoon at 12:40 PM on July 28, 2022 [26 favorites]
I'm annoyed that he did his error-diffusion dithering and then just mapped to whatever characters and threw out any error value introduced in that process. Surely you'd get better results dithering that too?
posted by aubilenon at 1:03 PM on July 28, 2022 [2 favorites]
posted by aubilenon at 1:03 PM on July 28, 2022 [2 favorites]
Prior to my existence as a software engineer, I was partially involved with hardware design. This was a long time ago, sort of in the PET era shown here. To see how much the tools have evolved, doing PCB design at home and then just ordering some boards, simulated circuit design and testing, and so on, makes me dream of creating my own electronic boxes. But it’s just a dream. Quite interesting and inspiring to see where we are now in designing electronics.
posted by njohnson23 at 1:09 PM on July 28, 2022 [4 favorites]
posted by njohnson23 at 1:09 PM on July 28, 2022 [4 favorites]
Maybe removing the 6502 would improve things, by giving the Raspberry Pi more bus bandwidth. One could call this zombified version of the hack “PET Sematary”.
posted by acb at 1:30 PM on July 28, 2022 [10 favorites]
posted by acb at 1:30 PM on July 28, 2022 [10 favorites]
I love how the PET's primitive architecture actually makes a tightly timed problem like this simpler to implement.
Makes me think of the musicians who still use Atari STs to drive their synths because the ST is single-threaded and has extremely predictable and stable timing.
posted by Sauce Trough at 1:33 PM on July 28, 2022 [7 favorites]
Makes me think of the musicians who still use Atari STs to drive their synths because the ST is single-threaded and has extremely predictable and stable timing.
posted by Sauce Trough at 1:33 PM on July 28, 2022 [7 favorites]
The Raspberry PI has a mechanism (DMA) for generating signals on the GPIO pins up to the MHz range, but it's a bit of a hack, and not at all easy to program. I feel like you could use it do to away with the SRAM buffer, though.
posted by credulous at 1:46 PM on July 28, 2022
posted by credulous at 1:46 PM on July 28, 2022
I'm with octothorpe. PETs, in my experience, were something closer to this or this. They weren't soft-edged and rounded. (Not to say there weren't any like that, it's just that they never made their ways into my local school.)
posted by sardonyx at 2:20 PM on July 28, 2022 [1 favorite]
posted by sardonyx at 2:20 PM on July 28, 2022 [1 favorite]
Learned 6502 assembly language on a chicklet-keyboard PET. Very fond memories of the excitement of those days.
posted by whatevernot at 2:33 PM on July 28, 2022
posted by whatevernot at 2:33 PM on July 28, 2022
I'm another sharp-angled PET kid.
those machines are so beautiful to me. these were the first computers I ever put hands on when I was nine years old and so on a primal level all those sheet-metal trapezoids add up to the platonic ideal of "microcomputer."
posted by Sauce Trough at 2:42 PM on July 28, 2022 [4 favorites]
those machines are so beautiful to me. these were the first computers I ever put hands on when I was nine years old and so on a primal level all those sheet-metal trapezoids add up to the platonic ideal of "microcomputer."
posted by Sauce Trough at 2:42 PM on July 28, 2022 [4 favorites]
The Raspberry PI has a mechanism (DMA) for generating signals on the GPIO pins up to the MHz rangeis the timing on the Pi deterministic/predictable enough so that it could sync with the PET and output the right byte out at exactly the moment the PET is expecting it? I think that's the main problem the sram buffer is solving.
posted by Sauce Trough at 2:49 PM on July 28, 2022 [1 favorite]
Apparently the rounded models appeared in 1984 for the European market, a couple of years after Commodore had otherwise retired the PET. Model numbers included 8032SK, 8096SK, 8296 and 8296-D. The one in the video is labelled PET 600, which seems to be a later rebrand of the 8096.
posted by automatronic at 2:54 PM on July 28, 2022
posted by automatronic at 2:54 PM on July 28, 2022
I'm annoyed that he did his error-diffusion dithering and then just mapped to whatever characters and threw out any error value introduced in that process.
It also seemed to me that dithering each frame independently would result in dither patterns that are unstable frame-to-frame, and that this would result in a lot of noise in the resulting monochrome video; this does seem somewhat the case in his example videos on the PET, in which the mostly-solid-color backgrounds seem quite jittery.
He does mention an initial experiment with propagating some of the error forward to the next frame but that it didn't make much/any difference.
It reminds me a lot of Lukas Pope's extended struggles with stable-under-camera-motion dithering for Return of the Obra Dinn; which also ended up as "throw a bunch of modern-PC CPU and GPU at it to end up with something convincingly 128K-Mac": previously on Metafilter.
posted by We had a deal, Kyle at 3:09 PM on July 28, 2022 [3 favorites]
It also seemed to me that dithering each frame independently would result in dither patterns that are unstable frame-to-frame, and that this would result in a lot of noise in the resulting monochrome video; this does seem somewhat the case in his example videos on the PET, in which the mostly-solid-color backgrounds seem quite jittery.
He does mention an initial experiment with propagating some of the error forward to the next frame but that it didn't make much/any difference.
It reminds me a lot of Lukas Pope's extended struggles with stable-under-camera-motion dithering for Return of the Obra Dinn; which also ended up as "throw a bunch of modern-PC CPU and GPU at it to end up with something convincingly 128K-Mac": previously on Metafilter.
posted by We had a deal, Kyle at 3:09 PM on July 28, 2022 [3 favorites]
is the timing on the Pi deterministic/predictable enough so that it could sync with the PET and output the right byte out at exactly the moment the PET is expecting it? I think that's the main problem the sram buffer is solving.
Probably only if you discard the OS kernel entirely and write fully bare-metal code for the Pi, at which point things like "stream a video from YouTube" become a lot harder. In practice you'd be better off swapping out the Pi for a Beaglebone, as the SoC on that board has a couple of independently programmable real-time units (PRUs) for doing exactly this sort of timing-critical work.
But you'd still have the problem that its clock isn't synced to that of the PET, so no matter how tightly you control the cycle counts, the synchronisation will drift off over time.
You could probably solve that by outputting a VSYNC-style pulse from the PET, just before writing each screenful, via one of the output pins on the user port. It would take a few extra cycles to toggle that pin, but he had some NOPs at the start of the refresh loop which could be replaced with the necessary instructions.
posted by automatronic at 3:13 PM on July 28, 2022 [1 favorite]
Probably only if you discard the OS kernel entirely and write fully bare-metal code for the Pi, at which point things like "stream a video from YouTube" become a lot harder. In practice you'd be better off swapping out the Pi for a Beaglebone, as the SoC on that board has a couple of independently programmable real-time units (PRUs) for doing exactly this sort of timing-critical work.
But you'd still have the problem that its clock isn't synced to that of the PET, so no matter how tightly you control the cycle counts, the synchronisation will drift off over time.
You could probably solve that by outputting a VSYNC-style pulse from the PET, just before writing each screenful, via one of the output pins on the user port. It would take a few extra cycles to toggle that pin, but he had some NOPs at the start of the refresh loop which could be replaced with the necessary instructions.
posted by automatronic at 3:13 PM on July 28, 2022 [1 favorite]
Would it maybe have been easier to just bypass the PET and send instructions to the CRT? Here is Doom on a green screen phosphor display for example
posted by rongorongo at 3:38 PM on July 28, 2022
posted by rongorongo at 3:38 PM on July 28, 2022
well yeah, it would have been easier, because displays are a lot chiller about timing than a PET system bus
but at that point you're just doing a real limited reimplementation of the PI video subsystem, so unless you're teaching yourself about how video display hardware is driven, there's not a lot of point or wow factor there that I see.
(disclaimer: I am a software goof and have only a hobbiest understanding of hardware and EE stuff)
posted by Sauce Trough at 4:35 PM on July 28, 2022 [1 favorite]
but at that point you're just doing a real limited reimplementation of the PI video subsystem, so unless you're teaching yourself about how video display hardware is driven, there's not a lot of point or wow factor there that I see.
(disclaimer: I am a software goof and have only a hobbiest understanding of hardware and EE stuff)
posted by Sauce Trough at 4:35 PM on July 28, 2022 [1 favorite]
I honestly had no idea there were round PETs until this video.
posted by chrominance at 5:42 PM on July 28, 2022 [1 favorite]
posted by chrominance at 5:42 PM on July 28, 2022 [1 favorite]
I don't like the dithering at all. PETSCII has a number of graphics characters that would trivially allow subsampling at 2x2 per character (80x50 pixels), and with a little work probably get you up to 3x3 (120x75) in most cases. That combined with temporal error correction should produce a less noisy display.
posted by seanmpuckett at 5:52 PM on July 28, 2022 [2 favorites]
posted by seanmpuckett at 5:52 PM on July 28, 2022 [2 favorites]
I enjoyed every moment of this, especially seeing processes I always thought ought to be achievable with less fuss (circuit simulation, ordering a board) exactly as hoped. And especially the fact that mistakes still get made and cost weeks. And that 3D printing isn't nearly as neat when you use the first rev.
But especially the open discussion of missteps and naivete while still doing something genuinely delightful (and surprisingly snappy, even for a souped up terminal).
Agreed though there's room to improve by faking up square pixels and a persistent adaptive lookup table and mapping grayscale rather than trying to map dither patterns..
But I recall a joke about actors that also applies to graphics engineers:
"How many actors does it take to change a lightbulb?"
"All of them. One to change the bulb and the rest to go 'pfft I could've done that, you should've done it this way...'".
posted by abulafa at 6:39 PM on July 28, 2022 [4 favorites]
But especially the open discussion of missteps and naivete while still doing something genuinely delightful (and surprisingly snappy, even for a souped up terminal).
Agreed though there's room to improve by faking up square pixels and a persistent adaptive lookup table and mapping grayscale rather than trying to map dither patterns..
But I recall a joke about actors that also applies to graphics engineers:
"How many actors does it take to change a lightbulb?"
"All of them. One to change the bulb and the rest to go 'pfft I could've done that, you should've done it this way...'".
posted by abulafa at 6:39 PM on July 28, 2022 [4 favorites]
ST is single-threaded and has extremely predictable and stable timing.
This is also why it's a great platform for running campgrounds, right?
posted by SaltySalticid at 7:04 PM on July 28, 2022 [3 favorites]
This is also why it's a great platform for running campgrounds, right?
posted by SaltySalticid at 7:04 PM on July 28, 2022 [3 favorites]
is the timing on the Pi deterministic/predictable enough so that it could sync with the PET and output the right byte out at exactly the moment the PET is expecting it?
You'd need a synchronization mechanism, as automatronic pointed out. The Pi can output very precise frequencies via the DMA hack (good enough for HAM radio in the kHz range) but you can't assume the PET's clock is as precise. But if you emit small packets with a sync bit somewhere, it might be good enough, and the author pointed out that a few random NOPs were required to adjust the clock anyway.
The challenge is getting the CPU sync'ed up -- any CPU-bound sync mechanism is going to have 6 or so cycles of jitter, and the data must be read every 10-15 cycles, so that's tricky. You'd want a sync mechanism that guarantees that the CPU is going to land in the center of every successive byte for a few dozen bytes or so.
posted by credulous at 7:19 PM on July 28, 2022 [1 favorite]
You'd need a synchronization mechanism, as automatronic pointed out. The Pi can output very precise frequencies via the DMA hack (good enough for HAM radio in the kHz range) but you can't assume the PET's clock is as precise. But if you emit small packets with a sync bit somewhere, it might be good enough, and the author pointed out that a few random NOPs were required to adjust the clock anyway.
The challenge is getting the CPU sync'ed up -- any CPU-bound sync mechanism is going to have 6 or so cycles of jitter, and the data must be read every 10-15 cycles, so that's tricky. You'd want a sync mechanism that guarantees that the CPU is going to land in the center of every successive byte for a few dozen bytes or so.
posted by credulous at 7:19 PM on July 28, 2022 [1 favorite]
This is also why it's a great platform for running campgrounds, right?that's a great link! thank you, SaltySalticid.
posted by Sauce Trough at 8:06 PM on July 28, 2022
> just seeing that it's actually able to get data onto the screen that quickly is a startling result.
Er, yeah. Beyond startling.
One of my famous hacks back in the very early 80s was machine language code to put a text mode on the Apple ]['s hires graphics screen that worked identically to the regular text screen, including scrolling.
It was amazing and made Apple ]['s hires graphics screen look and work exactly like its regular text screen. Except that you could also draw graphics on it, along with the text.
So the scrolling part involved simply copying every line of the graphics screen 8 lines higher - a very, very similar type of task to what he is doing with the PET, in transferring the video image over to the PET's screen buffer for display.
This was written in machine code and though it wasn't really highly optimized by any means, there really wasn't much scope to optimize there. It ran through a loop and copied about 50,000 memory locations to a different location.
Oh, yeah. And . . . scrolling was s-l-o-w. So slow. So amazingly s-l-l-l-o-o-o-w-w-w-w-w.
Something like 2-4 Hz at best.
So playing any form of recognizable video at 30 Hz on this type of hardware - no matter what tricks you use to get there - is really beyond astonishing.
Just simply being able to transfer the bytes to the display buffer that fast, in order to make an image that is usable and recognizable in any way, is astonishing.
(Apple ][ & Commodore Pets both run on 6502 processors at 1 MHz, by the way. So their native capabilities for operations like this are identical as can be.)
posted by flug at 1:39 AM on July 29, 2022 [4 favorites]
Er, yeah. Beyond startling.
One of my famous hacks back in the very early 80s was machine language code to put a text mode on the Apple ]['s hires graphics screen that worked identically to the regular text screen, including scrolling.
It was amazing and made Apple ]['s hires graphics screen look and work exactly like its regular text screen. Except that you could also draw graphics on it, along with the text.
So the scrolling part involved simply copying every line of the graphics screen 8 lines higher - a very, very similar type of task to what he is doing with the PET, in transferring the video image over to the PET's screen buffer for display.
This was written in machine code and though it wasn't really highly optimized by any means, there really wasn't much scope to optimize there. It ran through a loop and copied about 50,000 memory locations to a different location.
Oh, yeah. And . . . scrolling was s-l-o-w. So slow. So amazingly s-l-l-l-o-o-o-w-w-w-w-w.
Something like 2-4 Hz at best.
So playing any form of recognizable video at 30 Hz on this type of hardware - no matter what tricks you use to get there - is really beyond astonishing.
Just simply being able to transfer the bytes to the display buffer that fast, in order to make an image that is usable and recognizable in any way, is astonishing.
(Apple ][ & Commodore Pets both run on 6502 processors at 1 MHz, by the way. So their native capabilities for operations like this are identical as can be.)
posted by flug at 1:39 AM on July 29, 2022 [4 favorites]
The PET was my first computer. It takes me back...
Late 70s, I was in high school. Somehow I came across a PET in a department store (Eatons or The Bay) - and it was in the clothing section, on a white pedestal. Remarkably, it was plugged in and there were three younger kids playing games on it. They had brought their own data cassettes with games, and seemed to know about some magic world that I had no inkling of.
I started to skip school to go play games with it during the day, always standing up among the coats on racks, almost like the closet-forest in the chronicles of Narnia. It just was a quick 10-minute subway ride away.
I don't think this did much for my grades, and I am confused about what the younger kids were doing there in the daytime. After a time I stopped going, but my grades were not great and I left high-school not having completed it.
The following year, I tried an alternative school. Miracle of miracles, they had a Commodore PET (and a Moog synth, I had NO idea how good I had it at the time), and neither were getting used. I quickly acquired some games, and set about learning the mysteries of BASIC and how to rename the monsters with teacher's names, to the delight of students and faculty alike.
This experience left permanent hooks in me, and not too many years later I got my first PC, and the rest is history. As I type on a computer now, I can directly trace the lineage of this amazing device back to these early years of wonder and home-brew machines, and to have grown up with the industry during this time is such a privilege - what a frontier of human knowledge and development. The PET is linked to my psyche in a way that few would understand, but to me it represents the world of possibility that first drew me to computers, and that I still feel today.
Now, I pass on some of this feeling on with my son, as we build dungeon-crawler games and make sure to name of the characters after his stuffies. And I scour eBay looking for a good deal on a PET, so that I can one day go home again.
posted by SNACKeR at 5:29 AM on July 29, 2022 [5 favorites]
Late 70s, I was in high school. Somehow I came across a PET in a department store (Eatons or The Bay) - and it was in the clothing section, on a white pedestal. Remarkably, it was plugged in and there were three younger kids playing games on it. They had brought their own data cassettes with games, and seemed to know about some magic world that I had no inkling of.
I started to skip school to go play games with it during the day, always standing up among the coats on racks, almost like the closet-forest in the chronicles of Narnia. It just was a quick 10-minute subway ride away.
I don't think this did much for my grades, and I am confused about what the younger kids were doing there in the daytime. After a time I stopped going, but my grades were not great and I left high-school not having completed it.
The following year, I tried an alternative school. Miracle of miracles, they had a Commodore PET (and a Moog synth, I had NO idea how good I had it at the time), and neither were getting used. I quickly acquired some games, and set about learning the mysteries of BASIC and how to rename the monsters with teacher's names, to the delight of students and faculty alike.
This experience left permanent hooks in me, and not too many years later I got my first PC, and the rest is history. As I type on a computer now, I can directly trace the lineage of this amazing device back to these early years of wonder and home-brew machines, and to have grown up with the industry during this time is such a privilege - what a frontier of human knowledge and development. The PET is linked to my psyche in a way that few would understand, but to me it represents the world of possibility that first drew me to computers, and that I still feel today.
Now, I pass on some of this feeling on with my son, as we build dungeon-crawler games and make sure to name of the characters after his stuffies. And I scour eBay looking for a good deal on a PET, so that I can one day go home again.
posted by SNACKeR at 5:29 AM on July 29, 2022 [5 favorites]
One of my famous hacks back in the very early 80s was machine language code to put a text mode on the Apple ]['s hires graphics screen that worked identically to the regular text screen, including scrolling.
Apple wrote the same software internally! They released it as the HRCG (Hi-Res Character Generator) as part of the DOS Tool Kit 1.0 or Applesoft Tool Kit..
Apple even wrote a cool character editing tool called Animatrix, which is nearly impossible to search for now given the movie that was put out decades later in the sci-fi movie storyline.
Or....was that you?
posted by JoeZydeco at 8:14 AM on July 29, 2022 [2 favorites]
Apple wrote the same software internally! They released it as the HRCG (Hi-Res Character Generator) as part of the DOS Tool Kit 1.0 or Applesoft Tool Kit..
Apple even wrote a cool character editing tool called Animatrix, which is nearly impossible to search for now given the movie that was put out decades later in the sci-fi movie storyline.
Or....was that you?
posted by JoeZydeco at 8:14 AM on July 29, 2022 [2 favorites]
Who here is disappointed that he did not go for a Rickroll on the last video?
posted by boilermonster at 8:53 AM on July 29, 2022 [1 favorite]
posted by boilermonster at 8:53 AM on July 29, 2022 [1 favorite]
So playing any form of recognizable video at 30 Hz on this type of hardware - no matter what tricks you use to get there - is really beyond astonishing.it's pretty cool but not quite as cool as that. Pet screen memory is only 1K long -- it's a character-mapped display without hi-res graphics. the apple II hi-res screen is 8K long. So right off the start, doing a frame on the pet requires only 1/8th the work. all other things being equal, your 2-4 FPS on the apple ii turns into 16-32 FPS on the pet.
it would be interesting to do this exercise on the apple because you can do custom character sets on the apple, unlike the pet. With 256 characters, you can't quite get a 3x3 character grid ... that would need 512 characters for full fidelity ... but maybe that downsampling by half wouldn't be too bad.
(also I'm not sure if you can redefine all 256 characters freely, since the ROM duplicates the glyphs for inverse and flash modes)
Apple wrote the same software internally! They released it as the HRCG (Hi-Res Character Generator)I used Superfont from Compute! magazine for this purpose. Wrote a ton of code for an ultima / roguelike tile game with it, but alas at 15 I wasn't a real strong finisher.
Damn, Compute! was a fine magazine. Archive.org has a complete collection if you want to get your retrocomputing on.
posted by Sauce Trough at 11:15 AM on July 29, 2022 [1 favorite]
Does the PET's video chip not allow you to set the character definition pointer to an area in RAM and specify your own character set, as you can on the VIC-20 and every 8-bit Commodore that followed?
posted by acb at 11:24 AM on July 29, 2022 [1 favorite]
posted by acb at 11:24 AM on July 29, 2022 [1 favorite]
Nope:
Without the High Resolution Graphic board, the PET's graphics capabilities were limited to a character set hardwired in ROM, similar to the Apple II in text mode. On many of the PET range's home computer rivals, the look-up address of the character graphics could be changed and pointed to RAM, where new characters could be defined by a programmer to create custom graphics shapes. From a programming point of view, this was a relatively simple method of producing good-looking graphics, which used negligibly more RAM than a standard character display, and significantly less RAM than bitmap graphics. The PET's lack of a remappable character set is a major weakness in the machine's design.posted by We had a deal, Kyle at 12:35 PM on July 29, 2022 [3 favorites]
When I saw the title (for the second time, as YouTube has been suggesting this video to me too), my main reaction was no way. The PET doesn't have hi-res or even a programmable character set, so it'd be showing something in PETSCII in any case, unless there were some clever work around. And, as seanmpuckett notes, that work around is doing all the work via a Raspberry Pi and piping the data in via the User Port, with the poor processor using all its time frantically putting the characters shipped to it in place.
I suspect this had to be the case because just changing each character each frame is a challenging trick for a Commodore 64 doing smooth scrolling, which is processor intensive on that machine. Every time a full character's-width of data has shifted 8 pixels everything has to be moved over by one, which takes so much time that many games keep a second copy of the screen in memory so they don't have to do it in a single frame, and keep the colors in their game worlds low because color memory is its own 1,000 characters to shift every frame, and it can't be remapped.
A PET is a lot like a C64 without graphics and sound capabilities, but with an 80-column screen. It doesn't have color memory, but it does have twice as many characters, so, same problem. This is why the video is 30 fps and not 60. I knew the work had to be done by something, and lo, it's being done by an entirely separate, much much more capable computer attached to its User Port, that would be capable of displaying the YouTube video by itself if someone would let it, and in full color and resolution.
I don't really blame the makers of the video though. The YouTube content treadstone grindmill is ludicrously demanding.
posted by JHarris at 1:55 PM on July 29, 2022
I suspect this had to be the case because just changing each character each frame is a challenging trick for a Commodore 64 doing smooth scrolling, which is processor intensive on that machine. Every time a full character's-width of data has shifted 8 pixels everything has to be moved over by one, which takes so much time that many games keep a second copy of the screen in memory so they don't have to do it in a single frame, and keep the colors in their game worlds low because color memory is its own 1,000 characters to shift every frame, and it can't be remapped.
A PET is a lot like a C64 without graphics and sound capabilities, but with an 80-column screen. It doesn't have color memory, but it does have twice as many characters, so, same problem. This is why the video is 30 fps and not 60. I knew the work had to be done by something, and lo, it's being done by an entirely separate, much much more capable computer attached to its User Port, that would be capable of displaying the YouTube video by itself if someone would let it, and in full color and resolution.
I don't really blame the makers of the video though. The YouTube content treadstone grindmill is ludicrously demanding.
posted by JHarris at 1:55 PM on July 29, 2022
Aah, much of this had already been said by other people. Sigh.
posted by JHarris at 2:08 PM on July 29, 2022
posted by JHarris at 2:08 PM on July 29, 2022
Pet screen memory is only 1K longoh ack, this project used the pet's 80-character mode, so pet screen memory is 2K in this case.
we regret the error.
posted by Sauce Trough at 3:46 PM on July 29, 2022
> it's pretty cool but not quite as cool as that. Pet screen memory is only 1K long -- it's a character-mapped display without hi-res graphics.
Oh, I'm quite well aware of that. But still, the gut-level reaction to "Could a PET display full-screen graphics at 30 FPS" is: No way, the machine isn't even capable of copying the data that fast.
(And of course it doesn't even have a graphics mode - let's don't even get into that end of it.)
It's the clever use of the character-based dithering thing that makes it even possible.
FWIW on an Apple ][ you could do something similar in lores graphics mode, which would give you 40x48 graphics with 16 whole colors! Similar to the PET, refreshing that screen only takes 40X24=960 bytes. So it's very possible at something like 30 fps.
That actually might not look too terrible if you played it right.
posted by flug at 8:57 PM on July 29, 2022 [2 favorites]
Oh, I'm quite well aware of that. But still, the gut-level reaction to "Could a PET display full-screen graphics at 30 FPS" is: No way, the machine isn't even capable of copying the data that fast.
(And of course it doesn't even have a graphics mode - let's don't even get into that end of it.)
It's the clever use of the character-based dithering thing that makes it even possible.
FWIW on an Apple ][ you could do something similar in lores graphics mode, which would give you 40x48 graphics with 16 whole colors! Similar to the PET, refreshing that screen only takes 40X24=960 bytes. So it's very possible at something like 30 fps.
That actually might not look too terrible if you played it right.
posted by flug at 8:57 PM on July 29, 2022 [2 favorites]
oh man I forgot about the Apple low-res mode. that would definitely be a candidate for this stuff, although I bet you could get the exact same result by running the source video through a pixellation filter.
posted by Sauce Trough at 10:41 AM on August 1, 2022
posted by Sauce Trough at 10:41 AM on August 1, 2022
Speaking of Apple ][ lo-res, some motivated individual is doing "de-makes" of Myst and Another World in glorious 40x48 16-color lo-res. If you don't mind the screen being about the same resolution as Sonic the Hedgehog's sprite.
posted by credulous at 6:14 PM on August 1, 2022 [1 favorite]
posted by credulous at 6:14 PM on August 1, 2022 [1 favorite]
« Older Postcapitalism. Jewish mothers. Dandelion networks... | A Monument With Big Verga Energy Newer »
This thread has been archived and is closed to new comments
posted by umbú at 11:01 AM on July 28, 2022 [3 favorites]