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.

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?

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 AppleWorks. Even well into the WYSIWYG era, quotes were stricly vertical.

Following a catastrophic loss of the bootloader work to my sheer negligence, I've gotten it back up to where I last left it. The bootloader is responsible for initializing the hardware and it has not been easy getting this far, but at the moment, everything is working except the 68K bus. That is, of course, the most important thing Buffee needs to do, but it sure wasn't everything the bootloader needs to do.

So we have a LOT on the go right now trying to stay ahead of the chip shortage. I'd like to say that it's coming to an end, but we all know that's not true. Some chips have started showing up on sites like DigiKey only to almost immediately disappear within days. It's shocking and it's probably still going to be late 2023 before this settles down.

Wow, what a journey; to start with the Beaglebone finding big-endian worked fairly well to find out its completely broken on Buffee and that big endian is completely unsupported on the AM3358, something the people at TI will repeat in their support forums again, and again, and again. But it's all a lie and big endian does work … perfectly. So what's up?

As a follow-up to my original thoughts on open sourcing, I am pleased to announce that we've reopened the source code for PJIT as well as merged and closed the private repository. The one and only repository for PJIT can be found here.. PJIT will remain open-source forever but also only non-commercial use.

With Buffee sort of languishing in the wind, I took a few hours to slap together another board to ensure my PCB routing skills don't get rusty. Instead of a CPU accelerator or anything like that, this is going back to our original Amiga Replacement Project and prodiving DIP and PLCC sides replacements for all the custom and insanely difficult to get custom chips. First up is Gary, or as we call him, Gary Zander.

The idea of open source is a nobel one and as long as everyone "plays fair," it works. It was our genuine hope that people could learn from our design – we thought PJIT has some rather novel ideas in it that could be a benefit to everyone. How was this made? How does it work? We thought people could maybe try and make their own boards, but this is a slippery slope – what if someone wants to make 20 for their friends out of their own funds? What if someone has no regard for our license and simply uses our work to make their own Buffee?

I have many words for the last year, none of which I can really express here. Suffice to say that this "chip shortage" has pushed back retail production run into January – at least at this point – I believe nothing anyone's saying until I have boards physically in hand. Despite the delays, our beta testing is going along well, but very, very slowly. We're still waiting for the last of the beta boards to come in before we begin shipping, and I absolutely appreciate everyone's patience with this. Software is coming along nicely and we have good timing on the bus and can read and write, so that's progress!

I'm not one to brag, but when I mess up, I mess up like no one else. But before I start committing seppuku, let me tell you the good news: we got the beta's in and managed to power them up. And wow, do they look gorgeous!

With a ton of testing behind us, we've pushed on to the second round of Buffee boards and have officially submitted the order for sixty beta Buffees. While we had hoped that the alpha version would just work, we were not so lucky and Buffee v0.5 has a new little friend – a GreenPAK SPLD (Simple Programmable Logic Device) and we've ensured that on this version every signal that is not bound to the SPLD, is bound to the PRU (Programmable Realtime Unit) which is almost as good as the SPLD, just not quite as fast. This doesn't mean the alpha boards are useless though!

In the last part of the series we put PJIT up against the state-of-the-art 68000 emulator for ARM that used the traditional interpreter style of emulation, Cyclone 68000, and found PJIT to be rather compelling. But one cannot ignore the raw performance of a true JIT.

Just a small update; we've been working hard at getting the core of PJIT ready to boot up before receiving our first batch of boards. Getting the AM3358 up and running without the benefit of JTAG has been … interesting. To date we have:

• working clock reconfiguration
• set up of all the caches and mmu
• a timer by which we can measure performance
• our first runs of PJIT with the BogoMIPS test

Ooh it's been a busy month! But we have our first boards in ready to get all populated. We did have one small snafu with the wrong footprint for our Flash memory that might put us a little behind schedule, but nothing world-ending. Despite this, I think this looks really good for our first, officialy production boards.

There seems to be a bit of confusion with Buffee and perhaps that's my fault. My father's favourite saying is, "a word to the wise should suffice" and to me, that always meant be terse and to the point and people should figure it out. I've mastered the art of being terse to the point of sometimes not saying much at all – so I'll say it here, loud and clear – the Buffee supports everything your Amiga can do right now.

This is the first part is a three part series that will be doing a bit of a deeper dive into the mechanics of PJIT in contrast to existing emulation technologies. Part two will be "Why is PJIT Slow" and will compare PJIT to bleeding edge 68K JIT engines like Emu68 and UAE. Part three will be "Why is PJIT Quicker" and will explain the overhead of JIT and why PJIT doesn't have this problem.

Well, have to admit, I had missed a lot of minor design issues, but now that we've gone through the complete checklist and have finished our first professional review cycle, I can confidently say we're very near getting our first boards made. I even managed to shrink the board a little bit so that it fits precisely into a 64 DIP socket with zero overhang! A quick run down of all the major bits:

I have to admit, I was getting close to full burnout, but the Yuletide break has managed to give me a little more energy than I had before and I've had a pretty productive couple of weeks.

Well, 2020 has just flown by. I'm sure I'm not alone in saying good riddance. It's the year that broke the world and I sure hope that when we start rebuilding, that we don't make all the same mistakes.

So I've had a few people ask why PJIT and not leverage something else like Emu68. Is there really room in the fairly small market for two 68000 to ARM JIT engines for the Amiga? Well, of course I think so and here's why.

Alright, looks like I'm all set up! Welcome to my new blog! I'll update this weekly at a minimum focussing on the progress of my various projects including PJIT and the Buffy Acellerator. What is PJIT and Buffy you may ask? Glad you asked.