17.Aug.2021
|
Accelerator board: Returning the Buffees for rework
In the middle of June the developers reported that a second batch of 60 beta Buffees was ordered which now arrived. They "managed to power them up."
However, new problems were found, as the developers further report:
"While we did manage to boot them up and verify that some of the issues we had with the alpha were fixed, we also managed to introduce a couple of more. And a third issue that doesn’t really hurt us too much, but it is a pain:
- 1. the GreenPAK was mounted wrong; in their infintie wisdom, Dialog chose to reverse the pinout between packages. Same number of pins. Completely different order. One is clockwise. One is counter clockwise. Oh my god. This is on me, I should have checked had I thought to, but I’ve never had a part where the pin outs reversed, so this is a new one for me. Oh well.
- 2. There are three power rails on the PMIC; AC, USB and BAT. The USB and AC can both take really high voltages, but have a minimum of 4.5V which worried me as these old 68000 machines aren’t getting any younger and neither are their power supplies. Getting a solid 5V is rare, so I chose to use the BAT rail instead which operated nicely down to about 2.7V. Except TI didn’t make this rail “default on” and needs a push button. What the hell? Anyway, easier fix than #1, just need to short PB_IN to PGOOD.
- 3. Parts are disappearing and one of them was the 16MB Flash. We had to go with an 8MB one or “not at all”. So … this will be interesting.
So, they’re off for some rework and hopefully we get them back by the end of next week. I have to say these shipping delays and parts shortages all on top of dealing with COVID and a new fourth wave is so stressful. But I digress. At least we’re still under-budget.
We’ve made excelent progress on Buffee despite all these set backs and have developed a new method of handing the weird world of the variable length 68000 instruction and it’s dasterdly sidekick, the extended addressing mode. This has been the one last issue with PJIT that I had yet to solve.
The current method was to bake in the complex decode logic into every instruction that uses it – and for an addressing mode that’s not nearly as often used as say register direct or simple load/store operations, it was eating up a huge amount of the code base, since the “inline” nature of PJIT meant copying the same 20-30 ARM instructions for each opcode. Not efficient! And not fast either, the instruction routinely had to dig back into 68K memory and to do that, it would need to compute the 68K program code since we don’t always track it and … well, it was a mess.
So of course the answer was staring me in the face all the time. Our old model shows all these NOP’s filling the operand-gaps between opcodes – so why not simply shuffle them around and have all the literals and extended addressing modes get handled BEFORE we execute the actual instruction. Most 68000 opcodes are a single word and PJIT must either compile these to a single, inline ARM instruction or branch to a subroutine to handle more complex operations. But there are many 68000 opcodes that take considerably more than one word and PJIT can handle these by having special operators for each word within the whole instruction." (dr)
[News message: 17. Aug. 2021, 08:07] [Comments: 0]
[Send via e-mail] [Print version] [ASCII version]
|
