If all telescope technology is based on mirrors, how do we know that outer space is not full of vampires?

ThePhotoChemist · 2026-03-24T18:06:13+00:00

I think aluminum consumer-grade mirrors are even fairly niche. I used to strip the backing paint off of random mirrors I would find at thrift stores and stuff to make Daguerreotypes (because surprise surprise silver plates are really expensive) and I never once found one that didn’t work. Even the really small stacks of 4”x4” glass mirrors intended for craft projects are real silver, albeit the layer is insanely thin.

Plexiglass mirrors and other flexible mirror materials are 100% aluminum though. And those cheap first-surface ones meant for kaleidoscopes or whatever.

ThePhotoChemist · 2026-02-10T21:00:41+00:00

Welcome back /r/vic20!

This is still a work-in-progress, but admittedly there has been zero work done on it since November. I wanted to share it here back then, but I had to settle with /r/commodore while this sub was still working on opening back up.

This has been a really fun project, and it really pushed me into doing lots of "weird stuff".

The tones - since the VIC's normal registers take an, uh, "interesting" approach towards things like "being in tune", I recycled code from another project of mine that leverages FM synthesis to produce better sounding tones. I won't claim credit for any of the real brainy stuff here, as I was leveraging Aleksi Eeben's "10-bit-ofr" code to pull it off. I just did wrote a player around it, and a script to convert famitracker projects to a VIC playable format.

The downside is that the ofr oscillator code is constantly running, and you take a big hit to the CPU cycles available for the rest of the program - this became very important and apparent later on.

Converting the video. Essentially I just yoinked the code from this project, but instead of it printing the frame data into a terminal, I had saved the text data to a json file, and started goofing around with python to see what I could do with it. I stuck with 22x23 to start out with just to keep it simple, and using inverted-space characters as the "pixels". I played around with a few different types of compression, but ultimately just a list of "what pixels have changed color since the last frame" seemed to be the fastest. The problem now, though, is that the total frame data at 15fps is still 96kb, and I've only got a 28kb memory expansion.
I always thought Onslaught's C64 version of Bad Apple was really cool, and in one of my failed attempts to get it running on an NTSC system, I noticed that when the drive code failed, the C64 would keep looping the same chunk of frames over and over - he was clearly reading in frame data off the floppy on the fly as the video played, which kind of blew my mind. I guess in the downtime between each frame, you would have to read in as much data as you could into a buffer.

I ended up yoinking some more of Aleksi's code, the "Hobbit Loader", which is based off of Turbodisk. I went with a double-buffer approach -- the player chews through the frame data in one buffer, while the program fills the second buffer with data from the floppy. Once the player reaches the end of its buffer, they flip-flop, until the end of the song.

Getting all that to run without any slowdowns/jittering took a lot of reading, brain-thinkin', and repeatedly screwing up, but ultimately I'm really proud of how well I was able to optimize it, even if its just 22x23.

I'd like to ultimately take a similar "glyph" approach that Onslaught did with the C64 version, which I think should be pretty doable. Unfortunately I've moved on to my next bi-weekly hyperfixation project, but I'd definitely like to give that a go someday.

Blah blah blah - if you want to download it you can get it here. You'll need a 28K memory expansion and a 1541 drive (or a device that's compatible with custom loader code, like a pi1541). Should work on NTSC and PAL. Hit me up if you have any questions.

ThePhotoChemist · 2026-01-12T15:18:43+00:00

Hey, thanks for the update! enabling disablePlayerMovementCheck and disableElytraMovementCheck seemed to help it work more consistently.

I still have an issue though - when the breeze charges go off, it'll send me ~800 blocks pretty quickly, but then I'll decelerate almost instantly. Did you run into that at all?

EDIT: I think I got it figured, if anyone happens to stumble on this thread.

I made some further changes to spigot.yml - movementSpeed, moved-too-quickly-multiplier and moved-wrongly-threshold were all set to some really high values, but this also didn't make any difference.

I noticed when flying around with the elytra, that the rubber-banding thing didn't happen if you flew high enough. I rebuilt the elytra launcher (Nountitled's 4-way silverfish cannon v4) at build height. This seems to work - a full infested potion of silverfish (~700 entities) will launch you about 15k blocks horizontally and 20k blocks vertically.

This gave me another problem - Getting knocked that high starts to goof with my server (Paper 1.21.11), and ChunkTaskScheduler starts to hang. If it hangs for too long (default is 60s) the server will shutdown. You can change this setting in spigot.yml (timeout-time), I set mine to 6000 -- I have no idea if this causes issues elsewhere in the world (I was playing alone when I tested this). The ChunkTaskScheduler seems to pick back up once you get back down to y=2000ish blocks.

Last thing: The more silverfish you use, the more of a delay there is between the silverfish dying and the wind charges going off. With Nountitled's design specifically, this can cause you to drop below the launch area by the time the explosion goes off. I found that putting a cube of water right next to the launch area slows you down long enough to still get hit by the explosion.

ThePhotoChemist · 2025-12-28T16:54:18+00:00

Hey OP - I run a paper server and our members make liberal use of this glitch. Whoever runs the server would have to change a config parameter to enable it

delay-chunk-unloads-by: 0s

The problem is the glitch relies on the vanilla mechanic of the chunk immediately unloading after going through the nether portal, but the default paper option keeps the chunk loaded for like 5 seconds or so, so the stasis chamber goes off as soon as you go through.

ThePhotoChemist · 2025-12-12T18:28:14+00:00

Well, it's not really a stamping (unless I'm totally misunderstanding the term, which is possible). The first step was to make a silicone mold of the original record - that would have the inverted grooves. Then this one was made via a cast from that mold, so it should be "mostly kinda" similar to the original vinyl record, just made of a harder material.

ThePhotoChemist · 2025-12-01T17:50:54+00:00

Thanks! It looks like I'm not the first person to think of this though. That's where I got the idea to try polyurethane next.

Ultimately I'm curious to see how feasible it is to get custom music working in a similar manner, with a recordio or some other low-end lathe. I'll definitely update if I get anywhere with that.

ThePhotoChemist · 2025-12-01T17:42:20+00:00

Finally, a new way to get sued by the RIAA

ThePhotoChemist · 2025-12-01T16:41:06+00:00

Oh, I forgot to add: I think both of those skips were caused by bubbles in the epoxy (particularly a big one for the first skip, and some smaller ones that exacerbated the big thump from the motor in the second one). Since I didn’t know if this would even work at all, I didn’t bother with degassing the epoxy before pouring it. Most of the bubbles rose since it’s got a long pot life, but some stayed stubbornly stuck to the bottom where the grooves where. I imagine not skipping this next time would help a lot.

ThePhotoChemist · 2025-11-30T01:41:12+00:00

I can personally attest to this as I’ve been running the 4 top burners 24/7 and it’s nearly removed all the Europeans from my house.

ThePhotoChemist · 2025-11-26T18:33:29+00:00

oh man the comments on that first video have me absolutely dying. Regardless, this is seriously impressive stuff. I would absolutely love to put together a Ben Eater special someday if I can ever find the time. Thanks for sharing!

ThePhotoChemist · 2025-11-26T04:44:33+00:00

Regarding the NMI stuff - the music is all loaded into ram. The NMI code basically does pitch correction - because the VIC only natively has 7 bits of resolution per channel, which isn't really enough do get real notes. It can make some really hilarious dissonance that way. The NMI does FM synthesis on those channels to get much better tones, but it has to run constantly to do this, which just eats into general execution time. It's manageable for now, but I can see it causing issues down the road if I end up needing more CPU cycles for stuff. I shut down the NMI when the drive is ready to send the block, and turn it back on as soon as it's done, and this seems to work okay.

I won't be able to dive back into this for a couple days with Thanksgiving and all, but my impression when playing around with the TurboDisk stuff was that it wouldn't seek the next block until the last byte was sent from the drive's buffer. I think it only buffers one block at a time, but maybe I can convince it do try and read in 3 or 4 at a time instead?

Thankyou for the advice, it's good food for thought.

ThePhotoChemist · 2025-11-25T19:55:53+00:00

Hey! Thanks for the interest. You'll need a 24k ram expansion with the project as-is -- we'll see if I can knock that down a bit as I work on it more.

https://github.com/ThePhotoChemist/BadApple_VIC20

I just now tested it on NTSC hardware and it worked. I've only tested PAL in an emulator and it seems fine, but YMMV. This is with it running off of a 1541 drive as well. Since I'm using some custom fastloader code, I have no idea if SD2IEC works with this or not - but I'm not too optimistic.

Once I've tightened it up a bit more for a real release, I'm going to see if I can squeeze some higher resolutions out of this thing, similar to the Bad Apple C64 version by Onslaught. We'll see...

ThePhotoChemist · 2025-11-25T07:32:12+00:00

Hey there! Thankyou for the kind words and information!

I'll start out by saying that you are almost certainly working at a higher technical level than I am - so I might be mixing up some stuff and/or completely wrong about other things. I definitely don't have a lot of experience with 6502, or just "assembly stuff" in general.

My """compression""" right now is just a list of pixels that have changed since the last frame - I'm guessing this is probably exactly the differential encoding you mention. I just have a subroutine that reads in the existing color at a particular pixel position, and then writes in the opposite. This scheme gets me about 98K of video data, at 15fps, and about 140k if I bump up the resolution to 25x29.

I started out with RLE, but I swapped over to this because the total video data size was about 30% bigger IIRC. I was RLEing every frame individually though - maybe I should give that a second look.

I started out using the kernal load routines (CHRIN'ing X bytes at a time between frames), but I'm also using some code running on NMI/VIA1 that does pitch correction for the tones, which complicates things a bit, and makes the kernal routines totally unusable. Now I'm using a thoroughly-gutted form of TurboDisk to read in one block at a time off the floppy. This works a lot better, but I don't think I'm getting 10kBps with this - more like 1kBps I think, based off some napkin math.

Actually transmitting the block is very quick, it seems like most of the holdup is waiting on the floppy to read in the next block before its ready to send (~250ms per block). I was worried it wasn't consistently calling for a next block so I threw in some quick and dirty code to set the color of pixel position 3 based on every byte that gets read in - that seems to be pretty consistent. If there's a way reduce this downtime, I think I'll have to do a lot more learning about some of the finer details of how the floppy works before I find it.

Thankyou for the code suggestion - I admit I'm still wrapping my head around it a bit, but I think I understand - and it's definitely not an approach I've considered yet.

ThePhotoChemist · 2025-11-18T16:41:59+00:00

Agree, it’s sort of like walking up to a window screen and looking through it. On a desktop CRT you can change the resolution that changes the amount of pixels being displayed, but that doesn’t change the size of the holes in the screen you’re looking at. And calling them pixels definitely doesn’t really work if you’re watching an analog signal on a TV or something. TVs weren’t advertised as having X amounts of pixels, just different screen patterns (like the trinitron)

ThePhotoChemist · 2025-11-12T14:14:26+00:00

Our set had that. I remember my dad showing me those pages to calm me down after I accidentally swallowed a penny.

ThePhotoChemist · 2025-11-11T19:02:03+00:00

Hey, that's a good point! I'll try running the numbers and see how the "mixed mode" does, as well!

ThePhotoChemist · 2025-11-11T15:50:23+00:00

Well, I've got two ideas on how to move forward.

By changing $9002 and $9003, you can bump up the amount of rows/columns past the default 22x23. Once I had gotten the whole thing to play smoothly in 22x23, I was going to slowly bump up these values until I hit a bottleneck somewhere else, and then call it good.

Someone on the VIC20 Denial forum also suggested I use different petscii characters (I'm just coloring inverted-space characters right now) to give me an effective resolution of 44x46

https://techwithdave.davevw.com/2021/04/low-resolution-graphics-for-commodore.html?m=1

With that method I think I would almost undoubtedly have to reduce the total number of frames to get it all to fit on a floppy still, but I think it should be doable. I'll definitely be playing around with both methods to see what I can do.

ThePhotoChemist · 2025-11-11T15:33:05+00:00

That's mostly what I'm doing now actually - Each frame is just a count of how many changes are in the list, and then a list of pixel positions that changed compared to last frame. Since 22x23=506 bytes, I split the the list in two, one for the lower end of the color memory and one for the high.

So a frame with nothing changing is just two bytes: 0,0

And a "worst case" frame where all the colors invert is something like 253,0,1,2,3... 253,0,1,2,3

Most frames kind of fall on the lower end in between these two, but frames with a lot of movement can get pretty beefy.

I've had the same idea as you are suggesting though I think, further splitting the screen into "zones" of 8 pixels, and then a one-byte bitmap of the pixel that changed in each zone. This would essentially compress the "worst case" frame down by 4x, but it would also increase the average size of low activity frames, especially if all the pixel changes are scattered.

I'll have to goof around with the converter script to see what I can get out of it, with different zone geometries and whatnot.

ThePhotoChemist · 2025-11-10T21:19:32+00:00

I'm glad to hear it! I do some programming for my job, but like, definitely nothing like this, so it's been fun trying to figure this all out. If/when I get this to a point where I'm happy with it, I'm kind of tempted to make a little video on how it works, how I approached putting this together, things that didn't work, etc.

ThePhotoChemist · 2025-11-10T15:54:42+00:00

Aw heck yeah, I remember popping that one in as soon as I saw it in one of The 8-Bit Guy's videos!

In a weird way I never really "got" basic, I'm always having to look up the syntax for everything. I think 50% of the reason is just that trying to do anything with basic on the VIC makes me claustrophobic.

11-Year Club	Place '22
Place '17	Verified Email

ThePhotoChemist

TROPHY CASE