Happy holidays from 8bitworkshop! Here are as many snowflake sprites as the C-64 can manage. https://github.com/sehugg/holiday2023
| Web | https://8bitworkshop.com |
| Books | https://8bitworkshop.com/docs/books/ |
8bitworkshop
- 863 Followers
- 197 Following
- 148 Posts
Hi, I am an online IDE for 8-bit programming!
It's a pretty straightforward platform to program, just a 32x32 tile map and two 16x16 sprites laid out just like the TMS9918. The sprite data is in ROM, but the character tiles are in RAM which could make for interesting effects. The sound board is a separate 6502 which could probably play short samples. Now just to figure out what to do with this maze...
Anybody interested in old Exidy arcade hardware? It's a 6502, but with just two sprites and 8 colors there's not much going on. Venture was pretty cool though. It could use a Votrax.
Playing around with cc7800, a C-inspired compiler for the Atari 7800. The "reversed" and "scattered" keywords may sound like ordering hash browns at Waffle House, but they handle the 7800's weird memory layout.
OMG MikeDX's remakes are just the best. Here's Pitfall on Scramble arcade hardware.
Don't know why it took so long to do this, but the next version of the IDE will show you exactly where the electron beam is positioned when you hit a breakpoint.
The NES "Solarian" game works on llvm-mos with a little fiddling. I was even able to replace an inline assembly routine with C, and it improved it a bit :/ It improved the compressed ROM size by about 15% and the speed by 2x. There are still a lot of fit-and-finish things that you miss from CC65, and also the issue of how do you run this thing from the browser :) #nesdev
Playing with the llvm-mos 6502 assembler, and it cut the code size of this c64 demo in half. There's still a long way to go wrangling #ifdefs and inline assembly clobber lists, but it looks promising. It's still weird to use an executable the size of 311 floppy disks to compile a 1.2kb program...
This might be one of the culprits. CPX #0? Who does that? :)
Anyway, CC65 is clever enough to do this shift (msb |= 1 << t) with an ASL / DEY / BPL loop, correctly deducing that it can ignore the upper 8 bits because the result eventually goes into a byte variable.
Got the "Up, Up and Away" sprite test working -- reduced from 834 bytes (cc65) to 686 bytes (llvm-mos) but performance was about the same. Must be some missed optimization opportunity, but LLVM moves things around so much I don't know where yet :)