Home of the new 68K (and other stuff)
Oh how I've seen my share of bad scalars for old 2D games – from exaggerated CRT effects that make me feel as though I'm on LSD to interpolation routines that make every game look like its made with papercraft. Old school computers present a problem when being displayed on modern televisions that have resolutions significantly higher than the source material. Today, I provide my solution for this.
There's a persistent myth in the electronics commnity that if you want programmable logic to interface with 5V these days you have two options – very old CPLDs (Complex Programmable Logic Devices) or use level shifters to convert the 5V down to 3.3V as there are no 5V FPGA anymore. Well, I'd like to spend a few minutes busting this myth.
Well, I was laid off. But what sucks for me will be a win for the community as I'm working on Buffee again full-time, and progress has been … interesting. We're also really happy to see prices falling on some of the critical parts of our BOM, especially the main microprocessor. So how about a little "State of the Union Address?"
When Apple introduced PowerPC they also introduced the idea of system-level emulation providing a stop-gap for applications (and ROM) to remain as 68K code for a while. The emulator, written originally by Gary Davidian, introduced some novel features, but wasn't terribly fast – it was a later version made by Eric Traut that introduced us to the term "Dynamic Recompiler" which would become the…
When we originally chose to use the AM3358, one of the major reasons for it was the existence of the GPMC or General Purpose Memory Controller. We incorrectly assumed it would be able to cope with virtually any kind of bus, including the 68000, so we eventually had to add a small CPLD to our board – the GreenPAK. But it wasn't without its own issues.
Progress on "PJIT 2.0" has gone well so far and we're now into our third beta release. Executing code is still problematic when the bus timing is still not 100%, but we're getting there. Users are welcome to download the binary and play around, we'd be absolutely thrilled if anyone could play around with the GPMC settings and let us know what works and what doesn't.
We've updated our website to include commenting, provide RSS feeds as well as make it easier to find old aticles. There are still some bugs to iron out (like the splash screen never coming back), but I wanted to get this out sooner rather than later. This is a short one today, hope everyone's enjoying spring.
Happy New Year! With a new year comes new revelations and wow do I have a doozy – ARM GCC is just completely broken. I'm not saying it doesn't produce working code but there are cases where it produces obscenely poor performing code.
My first introduction to "typography" was the typewriter. My mothers old typewriter is so engrained into my psyche that today a good Courier font can trigger the smell of ink in my mind (Courier Screenplay is probably the best, imho). My second introduction was with computers and playing with fonts on my Commodore 64, and a bit latter with all manner of fonts in wordprocessing programs like…
In Part 1 we looked at how PJIT can be faster than existing traditional interpreters and in Part 2 how it might be slower than existing traditional recompilers such as Emu68 and UAE. While PJIT appears to live in a happy middle ground, there is one compelling reason why PJIT is better than either strategy – because PJIT is quicker than either of these methods. But what does that even mean?