🐈 play junkoid for nintendo now, it's a romhack of metroid where you can play as a women, something never seen before in video games. patched rom download here >>> https://sylvie.website/Junkoid.nes
A thing that is really fun with fighting game tournaments as well as speedrunning events is how the commentators will get really inconsistent with pronouns, like do you refer to a player by their own pronouns or by the pronouns of the character they're playing. Could go either way. Identity becomes fluid with performance
His 2014 modification to the Apple // design would have reduced the production cost of the machine while also adding an additional color to the LORES mode (this mode has 16 colors but colors 5 and 10 are identical shades of gray so on the shipping device it's really only 15; Woz's 2014 change would have made them lighter and darker shades of gray, bringing it up to a true 16 colors). Somebody tested it and it seems to work
It's really difficult to search search engines for information about the Apple 1 and Apple 2 due to the ambiguous and symbol-heavy naming of Apple 2 vs Apple II vs Apple //
@Cdespinosa I'm thinking of the thing that you could make happen on an Apple // where you crash so hard it would just print columns of hexadecimal numbers from memory. I've recently been told (for example the The 8-Bit Guy video on the Apple I on YouTube) that was called "Wozmon" and that it was reused from the Apple I where it served as a kind of bootloader (or maybe a bootloader loader, as you'd type in the bootloader program as hex).
@Cdespinosa Now that I double check, I cannot right now find any sources verifying the Apple I hexadecimal-columns mode and the Apple II hexadecimal-columns mode were literally the same program, so maybe I jumped to a conclusion there! But there is some very Wozmon-like memory debugger in the Apple II ROM, I've triggered it…
How similar was the command syntax in the 1 and 2 monitors? I've been wondering about this…
In my experience, it was a "common uncommon" experience for Apple // software to drop into the monitor program when things got messed up. But I guess that might have been something the program was doing internally (detect a crash condition and poke the monitor awake)…
@SteveSyfuhs@pb@anildash Would it be, in principle, possible (for example by plugging in the correct debugger) to configure a Windows machine just stay inside the mini-kernel and drop you into an in-kernel debugger interface?
The code ran on the pocket but it's only playing out heavy static :( I dunno if the problem is in my code, the .xm player code, the CPU (it's an FPGA softcore) or my port of the .xm player to no_std :(
Gonna be depressing if I spend all that time porting this library to no_std and it turns out to be too slow to run on my target machine :(
The library's using, like, floats for the audio samples. That's weird to me. The format it plays was created for FastTracker 2. Surely FastTracker 2 ran on non-FPU machines. (We have an FPU on the Pocket softcore, but I don't know how good it is. I've been avoiding using it until now.)
Okay progress! I guess! I have upgraded from structured white noise to some REALLY WEIRD chirpy hissing. Gonna try to record some and post it later. May have accidentally found an entirely novel audio glitching method
@maks The Analogue Pocket has no CPU at all (other than a small PIC chip which is used only for bootloading and could probably be removed in a future revision, as there is no direct access to it). I am using agg23's riscv core, which packages the open source LiteX and "vexriscv" projects and exposes a framebuffer plus registers for accessing Pocket features like audio and the sd card.
@maks This puts me in the unusual scenario that I could potentially solve my speed problems by adding a second CPU core. I think we actually have spare space on the FPGA for several.
My use of the word "softcore" was meant to refer to a CPU that doesn't "exist" but is running on an FPGA as gateware.