Fixing initial problems discovered by DevKit owners

We now have 100 DevKits in the hands of their new owners, or very much on the way in the post. One of the purposes of this is to help us find and shake down bugs in the MEGA65... which have indeed started to flow in. So here is a summary of what we have fixed, and also some new things that have been implemented.

(Most of this was written several weeks ago, but I have had a busy patch returning to work, and getting ready to teach, so the draft has sat here for a while, almost finished. So I'm finally squeezing this out now that I have surfaced briefly for air.)

1. VIC-IV Raster Re-Write Buffer & Full-Colour Text Mode Bugs

There were several bugs identified in the VIC-IV's full-colour text mode and Raster Re-write Buffer (RRB) logic, which I have fixed.  

This includes using colour $FF in Full-Colour Text Mode, which now correctly uses the colour from colour RAM. If the VIC-IV has extended attributes mode set, then the colour is only 4-bit, but you have the VIC-III extended attributes, such as blink and underline available. If extended attribute mode is not set, then you instead have all 8 bits of colour RAM to select any colour from the palette.

2. Floppy Drive Was Not Working

People also reported that the internal floppy drive wasn't working:  First, when you configure it to be used, it seems to still use the SD card. Second, when you do select it from the freeze menu, it gives drive not ready or hangs when trying to read disks.

So to investigate, I have gone back to an earlier bitstream that is known to work with the internal drive.  I wanted to start here, firstly to make sure that the internal drive in my R3 system works.  Anton tested and found that commit 989d598 on the 138-hdmi-audio-27mhz branch was the last working commit for the internal floppy.

The only challenge right now, is I can't easily find any of the 1581-formatted disks I know I have hanging around the place.  I have found one little cache of disks, but the first disk I tried has the directory track erased, probably from a couple of years ago when there was a bug that had the write enable line set instead of cleared. So I can't easily test loading from that disk.  The second disk I found has the same problem.

Now, as I went through the disks, I used the magnetic flux histogram display to see when I had disks with valid data. Doing this, I made the chance discovery that HD disks are reading fine, just with the expected 1/2 distance between the flux inversions.  So I tried setting the floppy bitrate to double the DD rate to match the HD rate, and voila, I was able to read sectors from a PC formatted 1.44MB floppy disk (or is it an FD2000 disk? I don't have a PC to confirm). Either way, reading data from HD disks works.  A lovely side-discovery, but not particularly helpful to my current challenge. Also, we don't yet have an HD aware DOS for the MEGA65.

So back to my little cache of disks, and it looks like I don't have any that have valid directory tracks.  And as I don't have an old DOS PC hanging around, nor do we have write support on the MEGA65 floppy controller yet, I don't have a great way to debug this as easily as I would like.  I can at least test that the latest bitstream version shows the same behaviour, though.

Ok, so I have loaded the latest bitstream, and the first thing I notice, is that it doesn't seem to be enabling the floppy motor.  Well, the DOS doesn't, but if I write the correct value to $D080, the motor does go.  Nonetheless, a curious thing.  Okay, when I try to use the floppy test programme to display the histogram data, the motor doesn't start.  But if I clear $D080 and then write $60 to it again to start the motor and select the drive, it does start, and I start getting sectors being read. Once the motor is going, the disks read.  

So this is good progress: The problem is most likely that the motor gets stopped for some reason, or the motor start signal is otherwise ignored. 

Next challenge is that my oscilloscope is 700km away, so I can't probe the floppy pins to see if the drive thinks it should stop because of some invalid combination of signals, or whether the VHDL has some change in it that stops the motor.  I know that the drives can stop themselves, because I accidentally discovered this when toggling the /DENSITY select line, and noticed the motor stops until you release the /MOTOR and /SELECTA lines, and then assert them.

Around the time of the commit that corresponds to when this problem started, I plumbed the "drive B" control signals onto the floppy interface. So I am suspecting that this might be all interelated somehow. But again, the drive activates and spins when I write $60 to $D080.  So there must be some funny sequence in the that the DOS in the ROM does, that is upsetting things. Again, not sure if this relates to other signals on the floppy interface being twiddled and upsetting the drive, or if it is being cancelled by some internal logic in the floppy controller.

Yup -- that's the problem: The ROM toggles bit 2 to work around some bug in the real C65's floppy controller. The MEGA65's floppy controller has a different bug that causes the currently selected drive to sometimes not be considered, instead using the previously selected drive.  This combined to cause the MEGA65 to think that the ROM DOS was de-selecting the drive when it was actually selecting it.  The fix required changing only a couple of lines.

3. Floppy/SD Card Select Was Not Working In MEGA65 Configure Utility

The other problem with the floppy, was that selecting to use the internal drive in the MEGA65 Configure programme from the utility menu has no effect: It always uses the SD card. But configuring it until next reset using the freeze menu does work.  Here I suspect the problem is that we are setting the wrong register bits in the hypervisor when it applies the settings, as the drive selection logic did change a while back... Except that it all looks like its correct: Byte four of the config sector gets $01 when set to use the real drive.  The code in the Hypervisor stores that into $D6A1, and it seems that nothing else touches that register... except mounting D81 disk images.  That's almost certainly the problem: We need to NOT mount D81 disk images if we have set $D6A1 to use the internal drive.

4. ASW Instruction Did Not Set Carry Flag

Totally unrelated, someone else also discovered a bug in the ASW instruction, where bit 15 of the operand was not being copied into the C flag.

5. Q-Family Instructions Would Mess Up Following Instructions

On the topic of CPU bugs, we also discovered that the Q family of instructions that use the A,X,Y and Z registers together as a virtual 32-bit register were causing trouble: The flag to write 32-bits of data was not being cleared in these instructions, so all following normal instructions would keep writing multiple bytes, until a single-cycle instruction was encountered. Needless to say this caused various forms of hilarity when a couple of developers tried to use the Q instructions.  A big thank you has to go to mdf200 for working out various clues as to the cause of this problem, including realising that single-cycle instructions were implicated. 

6. Freeze Menu Bugs

Then we had some bugs with the freeze menu not resetting certain VIC-IV registers, resulting in a garbled freeze menu display. 

7. 16-Colour Sprite Mode Glitches Fixed

16-colour sprites had a problem where transparent pixels were only transparent if there were no other sprites behind them. If there was another sprite behind, then Weird Things(tm) would happen.

8. MEGA65 Defaults to PAL if no valid configuration sector is found

Previously it would default to NTSC for better monitor compatibility, but the MEGA65 Configure routine would show that it was set to the default setting of PAL.  This inconsistency was very confusing, and has now been fixed through the introduction of default-to-PAL, and a once-only on-boarding screen that appears in NTSC to allow users to select their preferred video mode.

The Freeze Menu now follows the choice of PAL or NTSC, instead of always being NTSC, which avoids the annoying "resyncing monitor" behaviour that would previously occur. 

9. Fix the use of alternate palettes in Full-Colour Text Mode (FCM)

The logic for switching palettes was fault, and has been fixed.

10. Audio DMA can now interrupt normal DMA operations

This makes it possible to use the DMAgic controller while play DMA-based audio, without causing problems for the audio playback.

New Features

There were also a few small improvements:

1. You can now trigger raster interrupts based on the horizontal raster beam position. Should be handy for horizontal sprite multiplexing.

2. The colour RAM contents is now used in 16-colour text mode (where each pixel is represented by a nybl, and the characters are thus 16 pixels wide) to provide the upper four bits of the colour of each pixel, with the nybl from the character data providing the lower four bits. 

3. The Raster-Rewrite Buffer (RRB) now provides a mechanism to do smooth vertical positioning of characters by setting the trim-pixel values during a GOTOX token. Those bits instead get read as a a Y offset for Full-Colour Mode characters, effectively adding 8 x value to the address. This removes the single annoying limitation that the RRB suffered previously, in terms of using it to display moving sprite-like objects.

4. Various improvements to the MEGA65 Configure programme.

5. Bitplanes can now use memory other than in banks 0 and 1, although they must all still reside in the same 128KB region, that must be aligned on a 128KB boundary. This is to allow a modified BASIC 10 ROM to support 256 colour screens while still having close to 128KB of RAM available for BASIC programmes and variables.

6. The Raster-Rewrite Buffer (RRB) now supports more effective controls for placing sprites in front of, behind, or between layers of graphics rendered using the RRB.

7. The MEGA65 now has an option to enable "CRT scanline emulation" via bit 5 of $D054. The on-boarding process now asks users if they would like this enabled. The result feels much more like using an original C65:

8. The dip-switches on the main board can now be read from the MEGA65. They are connected to the MAX10 FPGA, not the main FPGA.  This was a bit of work to get happening.  My wandering notes as I went through this process follow.

We have only 3 lines to connect the two FPGAs for normal communications.  One of those by default is used to communicate the reset button status from the MAX10 to the main FPGA (like the dipswitches, it too is connected to the MAX10).   That said, we can do a bit of skull-duggery to use it as a 3rd communications line.  

In theory, we can also use the FPGA_DONE pin of the main FPGA to communicate to the MAX10 FPGA. I had wanted to do this, but for some reason, I don't seem to be able to control it, even though I have put the right stuff into the VHDL to do so.  This is a bummer, because with four lines, I could do a nice high-speed link between the two FPGAs with TX, RX, CLOCK and SYNC.  This would allow low-latency control of the 12-pin J21 header (also connected to the MAX10), as well as reading the dip switches.  The reason we need to provide clock information, is that the clock speed of the MAX10 when using its internal oscillator is quite unstable: It can be anywhere between 55MHz and 116MHz according to the data-sheet. This means that a simple UART won't work, because the apparent baud rate will vary by a factor of two -- and UARTs would have to be much slower, anyway.

So we have just three lines. We could still do an SPI-like protocol, as at least that way we can still get higher speed.  But we don't need a lot of the complexity of SPI.  But having an explicit clock will make it much easier to do, so we probably can't avoid using one of the three lines for that.  We can at a small cost add a sync mechanism into the clock. As we know some reasonable bounds for the difference in clocks of the two FPGAs, we can create a mechanism where the clock from the Xilinx FPGA is used to drive the receiver logic, but then also be separately be monitored by some logic clocked by the MAX10's internal clock to detect if the clock doesn't tick for a certain period of time, that it signals a sync.

As not everyone will have an Arrow programmer on hand to update their MAX10 bitstream, I will also implement a backward compatibility check, where we check for the old behaviour of the reset signal from the MAX10 FPGA.  

So we have things working with the new MAX10 programme and new bitstreams, including the reset button, and reading the MAX10 programme version.  However, if we use an old bitstream with the new MAX10 programme, it gets held in reset. So we need a solution for that. 

In the MAX10 code, the line previously called FPGA_RESET_N, i.e., and active-low reset out signal from the MAX10 to the main FPGA, is now the XILINX_SYNC output from the main FPGA into the MAX10. That is, its direction has reversed, which makes backward compatibility a bit of a pain to achieve.  We are now also using XILINX_TX (transmit from main FPGA into the MAX10) and XILINX_RX (transmit from the MAX10 into the main FPGA).  Thus the better way to have this protocol, would be to swap the XILINX_SYNC and XILINX_RX lines, so that when an old main FPGA bitstream meets a new MAX10 programme, the MAX10 is still sending on the line that the main FPGA expects to see the reset signal.  Thus if we don't see the clock signal from the Xilinx FPGA, the MAX10 programme can go back to the old behaviour of having the FPGA_RESET_N signal (which will now be the XILINX_RX signal) follow the state of the reset button.

So the three pairs of signals we have between the Xilinx and MAX10 FPGAs are, together with their signal names from the current bitstream builds for each, that have the old reset button protocol working with old MEGA65 bitstreams:

Xilinx K16 (MAX10_RX) -> MAX10 L11 (XILINX_SYNC)

Xilinx L16 (RESET_FROM_MAX10) -> MAX10 K11 (XILINX_TX)

Xilinx M13 (MAX10_TX) -> MAX10 J9 (XILINX_RX)

The XILINX_RX signal on the MAX10 must be correct, because this is the pin on which the old reset button protocol operates, and we know that this is working.

So this means we probably have the MAX10 L11 and K11 signals switched. So we should have it instead like this:

Xilinx K16 (MAX10_RX) -> MAX10 K11 (XILINX_TX)

Xilinx L16 (RESET_FROM_MAX10) -> MAX10 L11 (XILINX_SYNC)

Xilinx M13 (MAX10_TX) -> MAX10 J9 (XILINX_RX)

Swapping those at least gets the protocol running again, based on the MAX10's LEDs. However, neither the reset button nor the MAX10 version data is visible on the MEGA65 core, so something must still be messed up.

So it looks like we should instead switch K16 and M13 on the MEGA65 side, because the max10_rx and max10_tx signals are actually backwardly labelled. 

Indeed, fixing that fixed it, and it now works as expected. So that one's done, now, too.

Next stop was to make it possible to enable/disable digital audio on the digital video output.  This is because some DVI monitors don't display a picture if HDMI-style audio is provided. So we have disabled this by default.

Guest post from Bit Shifter: Improving the C65 ROMs

Today's post is from Bit Shifter, who is working on improving the original C65 ROMs. Best if I just let him explain...

The C65 ROM: Pick up the thread after 30 years. 

 

I watched the MEGA65 project very early and wondered, if it would ever happen, that this machine would see the light of day. But I got the impression, that this is a promising project and offered my assistance. I was accepted and wrote the User’s Guide chapter on BASIC 10, mainly using information from C128 manuals, preliminary C65 documentation and experimenting with the XEMU emulator from Gábor Lénárt. Soon I found out that the existing ROM images that were available thanks to Bo Zimmerman, were in a preliminary state. There were unimplemented commands and functions, bugs inherited from the BASIC 7 of the Commodore 128, which was obviously used as base for the BASIC 10, and a graphics library that was about 80% completed. Also there were ROM images for different types of hardware, programmed while hardware changes in the development of the C65 happened, like the DMA controller or the floppy controller.


Then there was the day, when I got a MEGA65 prototype loaned from the MEGA65 team and I could really program this machine. Soon I found out, that the existing firmware, that was loaded as ROM image from the SD card, could barely be used beyond using some simple programs and demos. The C64 mode was fine, but I wanted to use the power of the MEGA65. This could be done in machine language, so I wrote my first MEGA65 program, a Z-interpreter for playing stories of the legendary Infocom archive, like Zork, The Hitchhiker’s Guide To The Galaxy, The Leather Goddesses Of Phobos and many more. This worked out very well and I turned my attention back to the incomplete BASIC interpreter. I knew, there was the open ROM project, which promised to deliver an advanced BASIC interpreter, but the time schedule was such, that I didn’t want to wait. So I self assigned the job of finishing the BASIC interpreter to myself. My motivation was not to just finish the interpreter for the C65. I found it more challenging to unleash the power of the MEGA65 and decided to use the new features of the MEGA65, which could in many cases overcome the insufficiency of the C65. The task can be described like:

1) Fix bugs 

2) Finish incomplete code

3) Implement planned, but missing commands and features

4) Change the memory map, to take advantage of the RAM capacity of the MEGA65

5) Exchange awkward code, that was necessary due to a bad bank switching design

6) Optimise existing code: faster and shorter alogrithms

7) Use the hardware multiplication and divison unit of the MEGA65

8) Implement convenient features, like the DOS wedge

It would be nearly impossible to work on these tasks without the original source codes as a starting point, but thanks to Bo Zimmerman, who probably hosts the largest arvchive of CBM related technical information, ROM images and software, I could find the necessary source files of Dennis Jarvis, one of the former C65 developers.

Looking at the source, I saw the next obstacle: They were written in an assembler format, that none of the currently used assemblers could understand. Some of the issues were:

1) No different mnemonics for short and long branches, the assembler has to figure out

2) Local label of the form nn$, which can be reused after each normal label

3) Octal constants are prefixed with @, not the usual & as in other assemblers 

4) Use of 65GS02 mnemonics, which were not 65C02 compatible and unknown to many assemblers

5) Different form of pseudo-ops for many data declarations

After some research I found out, that the sources were 1991 assembled, using the BSO (Boston Systems Office) assembler, which was a cross assembler, running on a DEC-VAX with the operating system VMS. This assembler (and the hardware) isn’t available anymore.

Fortunately I had written my own 6502/65C02 assembler some years ago, in order to write programs for a variety of 6502 powered retro computer. So I enhanced the assembler, to support all features of the MEGA65 CPU 45GS02, which includes all of the C65 CPU, but added even more instructions and address modes. Then I introduced a compatibilty mode, which could handle all of the particularities of the BSO assembler. (Funny that I had named my assembler BSA many years ago)

Fortunately the old source archives included besides the source files, the list files, that were the result of the assembler run too and these included the object code in form of hex numbers.

So I could test my assembler by assembling the old source files and comparing the result with the listings. This helped to iron out all issues and finally the output of the BSA was bit identical to the object code, extracted from the list files of the BSO from 1991.

After all these preparations I could finally start to continue the development of the BASIC interpreter and the graphics library by using my self built toolchain. So far I did following changes or implementations:

1) Memory usage

C65: bank 0: 0000-1fff : 8K : system and basic internal variables, zero page, stack, buffers, etc.

C65: bank 1: 0000-1fff : 8K : DOS variables and buffers

C65: bank 0: 2000-7fff : 24K : BASIC program text

C65: bank 1: 2000-7fff : 24K : BASIC variables

C65: bank 0: 8000-ffff : 32K : graphics RAM

C65: bank 1: 8000-f7ff: 30K : graphics RAM

C65: bank 1: f800-ffff: 2K : colour/attributes RAM

MEGA65: bank 0: 0000-1fff : 8K : system and basic internal variables, zero page, stack, buffers

MEGA65: bank 1: 0000-1fff : 8K : DOS variables and buffers

MEGA65: bank 0: 2000-ffff : 56K : BASIC program text

MEGA65: bank 1: 2000-f7ff : 54K : BASIC variables

MEGA65: bank 4: 0000-ffff : 64K : graphics RAM

MEGA65: bank 5: 0000-ffff: 64K : graphics RAM

MEGA65: bank 1: f800-ffff: 2K : colour/attributes RAM

Summarising:

The C65 had 24K free for program and variables each

It could use at maximum one 320 x 200 screen with 7 bitplanes (128 colours) or a

640 x 400 screen with 2 bitplanes (4 colours)

The MEGA65 with the new memory map can use 56K for BASIC program and 54K for variables and use 128K for graphics, enough for a hires screen 640 x 400 with 4 bitplanes (16 colours) or two 320 x 200 screens with 8 bitplanes (256) colours.

2) BUG fix

There was a bug in BASIC 10 inherited from the BASIC 7 of the Commodre 128:

Imagine following code snippet:

100 IF A=1 THEN PRINT "A=1": ELSE BEGIN

110 PRINT "A # 1":BEND: PRINT "SEE"

Executed on a C128 or C65 this code will print the text "SEE" only, if the ELSE branch is executed, but will be ignored, if the TRUE branch is taken. So it’s clear, that the PRINT "SEE" should be executed in any case, because it’s outside the IF-THEN-ELSE statement.

This one was easy to fix.

3) Code optimisation

Then there were so many code parts, especially in the graphics library, that were unnecessary long. I could reduce the code size of the graphics library already from 12K to 9K by using loops and tables to replace long linear and repetitive code sequences. The new won space may be used for enhancements.

4) Bank access

The C65 has an awkward memory management. It can combine many different 8K segments from ROM and RAM, but there is no easy way for a program running in a bank, to access data from a different bank. The solution for the C65 was, to use DMA transfer. So even for fetching a single byte from another bank, for example getting the next character from the BASIC source, it was necessary to build a 12 byte long list describing the desired DMA transfer, trigger the DMA controller and then reading the byte. What a tremendous effort to retrieve just one byte.

The MEGA65 has here a brilliant and easy to use solution: An address mode, that uses 4 zero page bytes to construct an effective 28 bit address, which is sufficient to access the complete 256 MB address space of the MEGA65. So you can uses instructions like:

LDA [ZP],Z STA [ZP],Z CMP [ZP],Z etc. to access any address in the MEGA65.
Replacing some of the DMA calling codes with the 32 bit indirect access already increased the execution speed of BASIC by more than 30%.

5) Hardware multiplication and division

The MEGA65 has an easy to use hardware math unit.

A mulitiplier performs a 32 x 32 bit multiplicazion in just 1 cycle.

A division unit performs a 32 / 32 bit divison in 16 cycles.

So far the multiplier is used to speed up the floating point multiplication in using the hardware to multiply the mantissas of both factors. This increased the speed by a factor of more than 2.2.

6) Convience Enhancments

Finally I made my dream from the C64 days come true and make the BASIC more convenient by implementing very small features, which I like nevertheless much.

How often did it happen, that one hits return, while the cursor is on the line with the READY. Prompt and see the ?OUT OF DATA ERROR, because the interpreter tries to read data for the variable Y. Now you can hit RETURN on the READY. line and nothing happens.

Also the DOS wedge, using the shortcuts @ / ← $ for disk command, load, store and directory is implemented now.

The line numbers can now use the full 16 bit range from 0 to 65535.

Lines can be indented with spaces, which are not swallowed by the interpreter.

And there is much more to come.

Finally it’s interesting to read in the old sources.

You find gems like [….] is an asshole (I’ll not repeat the name here).

Or: OH-OH I programmed a recursion, Dr. Ja-Ja warned me about this.

In fact, that is one of the code pieces which have to be fixed.

Nesting BEGIN … BEND compound statements is dangerous and can crash the machine.

Or the funny code, where a 16 x 16 bit multiplication is called, in order to multiply an index with 1.5, which can be done with only 4 simple instructions instead.

So far my text on working on the MEGA65 kernel and BASIC software.

The text became longer, than expected, I hope, I didn’t bore you, but if you read this sentence, you read it probably completely.

Best wishes,

Bit Shifter

ZX-Spectrum on the MEGA65

From the beginning, it was our hope and intention that the MEGA65 would be able to run multiple cores, allowing it to be many different computers and consoles.  This is why we built the whole Flash Menu framework, that allows a user to select which core to load when powering up by holding down the SCROLL LOCK key when powering on, like this:

 

We already have an Amiga core being ported, although it is not finished, while we work out some issues with our HyperRAM controller.  But in the meantime, Sy2002 has managed to largely port a Spectrum core from the ZX-Uno project, as you can read below.  So this is a really nice achievement, as it means that you can run the two main camps of 8-bit  systems on the MEGA65: The Commodore 64/65 and now the ZX Spectrum family -- all with our really nice keyboard and case for a very authentic experience.

We are still working on the bootstrap ROM, but it already gives you the ability to select which exact model you wish to operate as:

The ZX-UNO is designed to run mainly as Sinclair ZX Spectrum machines (48K/128K/+2a)

with DivMMC support (MMC/SD/SDHC storage), ULA+ (multi-color, high resolution graphics),

turbo sound (double AY chip), among other things.

 

The ZX-UNO hardware, software, logo and concept have been created by the ZX-UNO TEAM

(Superfo, AVillena, McLeod, Quest, Hark0) and released under Creative Commons Attribution-

ShareAlike Licence.

 

So thanks to their hard work, you can already have a lot of Spectrummy fun with a MEGA65, as the following images show:

 

The ZX-UNO being completely open source matches the spirit of the MEGA65 perfectly!

Announcing the MEGA65 Developer Support Programme

Howdy folks! We thought it was time to (very slightly) formalise our MEGA65 Developer Supporter Programme (M65DSP).  We have already been informally finding solutions to help people get access to MEGA65 development hardware, for folks who don't have an official DevKit.  We now want to make it clear that we are keen to support folks who would like to develop software, games, tools, documentation, promotion or other goodies for the MEGA65 platform.

What are the eligibility requirements for the MEGA65 Developer Support Programme?

Unlike some developer programmes, we don't require you to have a promissory letter to the value of US$4.7M, a private island or a double-degree in rocket science and underwater basket weaving! All you need to do is to have a clear idea of what you intend to do or to create, and explain that to us.

To be clear: If you can't afford any hardware, this is not necessarily an impediment. We have some R2 PCBs, Nexys4 development boards and other bits an pieces that we can potentially make available.  But if you are able to afford your own development hardware, that will make it easier for us to support more developers, and thus help even more cool goodies come out for the MEGA65 sooner.

I'm convinced. So where and how do I sign up?

You have several options:

1. Carry your One Ring of Windows 98SE Installation (CD or DVD) to the summit of Mount Doom and throw it into the Schicksals Kluft, and await pickup by the first cooperative oversized avian.

2. However, recognising the difficulty of definitively locating Mount Doom on modern maps, you may instead simply fill out the contact form on the MEGA65 website, explaining that you would like to be considered for the MEGA65 Developer Support Programme, and what you would like to make for the MEGA65 (or if you prefer, volunteering to work on whatever we think is most needed at the time).

3. Attempt to convince an existing DevKit owner to temporarily or permanently part with their MEGA65 DevKit in return for some object of mystical value*.

4. Move house to live conveniently near to a known MEGA65, and dig a secret tunnel that allows you to access the MEGA65 when its owner is sleeping.  Be sure to mend and polish the shoes of the owner, so that they think it's just fairies, and don't become suspicious.

5.  Enrol in a PhD programme related to the MEGA65 or MEGAphone, and maybe even get paid to do awesome 8-bit goodness for three years.  In this post-COVID world, it probably isn't even necessary to move to Adelaide to do this (although we have basically eliminated COVID, and have awesome beaches and stuff that we are all free to use again). In case you think I am joking about this, I'm not: There are opportunities to study the education of students in CS using 8-bit systems, the development of resilient and secure communications systems around the MEGAphone hand-held, including hybrid space-terrestrial mesh networks, FPGA-based cryptography and all sorts of other fun and interesting things.

* We cannot guarantee success of this method.  We recommend MEGA65 owners verify the actual value and function of such mystical value before accepting a trade. The origin of any Palantíri should be subjected to particularly thorough scrutiny.

I'm not convinced, yet. What should I do?

Hmm.... Look closely at this watch swing on it's chain... Closer... Deeper...

DevKits are appearing around the world!

 It has been a sheer delight the past few days, as people have begun receiving and assembling their MEGA65 DevKits, and even started to create things using them!

In case you missed the action, there are now several first impressions / assembly videos up on youtube:

That first one is from Shallan, who does regular twitch feeds, including writing C64 games -- and now that he has a MEGA65 DevKit, on coding for the MEGA65.  He has already made his own 256-colour image loader, and started working on using the MEGA65's Raster Rewrite Buffer (RRB) to do a thousand hardware drawn 256-colour moving bullets over the top of a 256-colour background, and using only about 10% of the CPU to do it. You can see what a busy 320x200 screen with 1,000+ blobs looks like here:

 

You can hardly even see the background.  This is just one of many uses of the Raster Rewrite buffer -- so expect to hear a lot more of "RRB" being thrown around.

So hop onto Shallan's live twitch feeds or playlist of videos he posts after for the low-down on how to make the MEGA65 do amazing things.

There is also plenty of action elsewhere. For example, there is a CSDB C64 sprite graphics competition, offering a MEGA65 DevKit as a prize, thanks to the generosity of the community!

Anyway, we are just so happy that people are having a great time with the MEGA65, and re-experiencing that joy of Christmas 1982 of receiving their first C64 (or VIC-20 or other home computer), and then diving in to explore the machine, knowing that they were entering exciting and uncharted territory.  

One great point of satisfaction for everyone involved, is how amazingly nice the keyboards have turned out.  We put a huge amount of effort into making the best possible keyboard for the MEGA65 -- from Cherry MX mechanical keys to the double-shot top and front-marked key caps and space bar long enough to land a fully laden A380. And so it has been sheer delight to see people fall in love with the keyboard, and experience sitting down at a device that _is_ a brand new 8-bit era computer for the first time in decades.

I am sure that there will be lots more interesting videos and material coming out, as people get their DevKits setup, and start tinkering.  We hope you enjoy the journey as much as we are!

The DevKits have started shipping!

100 MEGA65 DevKits sitting in the warehouse

100 MEGA65 DevKits sitting in the warehouse

77 went into the post

23 MEGA65 DevKits sitting in the warehouse

23 MEGA65 DevKits sitting in the warehouse

...

And by this time tomorrow, my understanding is that all 100 will be underway!

This is of course very big news for us, and more importantly, for the 100 people who ordered the DevKits, and supported the preparation for release of the final machines through their purchase.

So now we just need 2020 to hold off from come further crazy calamity, like, say, an alien invasion that disables all transport logistics, and then hopefully everyone will have their DevKits before Christmas.  We are so looking forward to what people will begin to do with their DevKits!

Now, for those wondering exactly what is in a DevKit, and how to assemble one, we have our great assembly video:

If you can't see the video above, you can get there via https://www.youtube.com/watch?v=WJlWK1pexD8

 

Meanwhile, things have been quiet from my side as I try to get my work finished up for the year, move back from the middle of the Outback to our usual home, get the kids enrolled in their new schools for next year, and a hundred other things.  Hopefully I will start doing some more visible things in coming weeks.

MEGAphone PCB Changes

Things have been a bit quiet on the blog here, as I have been pretty flat out with work, and starting to plan to move back to the city after nearly a year here in the Outback.  The work on getting the MEGA65 DevKits shipped has been going along steadily over the last few weeks as well, but with less bloggable moments from my side.  What has also being going on, is the work on the next milestone of the MEGAphone grant from the NLnet Foundation.  For those who aren't familiar with this, this is a grant to move the MEGAphone project forward to having a PCB design that is mature enough that we can make a bunch for the community to get hold of, and to innovate on as a platform for resilient and secure communications.

The work on the MEGAphone results in various benefits for the MEGA65 work, as well as the value of making a hand-held MEGA65.  For example, in the last work unit under this grant, the multi-port serial port interface got a complete overhaul, and makes it much easier now to interface multiple serially-connected peripherals to the MEGA65.  People have already been talking about making trap-door wifi adapters, which would make use of this. 

So in short, if a handheld MEGA65 doesn't interest you, there are plenty of side-benefits of the MEGAphone.  One of the potential benefits of today's work unit, is that we think we have found the cause of the speakers connected to the MEGA65 R3 PCB getting hot (we use the same speaker amplifier circuit on both, as yet another commonality between the MEGA65 and handheld MEGAphone).

But enough of that, let's take a look at the 3rd milestone for this grant, and then what we have done to complete it:

3. Determine specifications for MEGAphone r3 hardware prototype

As described in sub-task 2, we wish to make a revision 3 hardware prototype that should have all key functionality included, that would make the device in principle usable by a developer. This means that it must have functioning communications, energy, computation, display and input sub-systems, such that it can be used and programmed without undue complication.

Milestone(s)

• Combine the errata identified in sub-task 2, together with consideration of the functional requirements of the revision 3 milestone, and identify the design and component changes that this entails to achieve that goal.

• Determine the revised intended specifications of the device.

• Determine the revised list of sub-systems required to achieve this

• Identify the changes to the Bill of Materials for the revision 3 device

• Sketch out possible schematic changes / PCB floor plans for each of the above, accepting that they may not be final.

• The milestone shall be considered complete when the four preceding dotpoints have been completed and their results communicated via the MEGA65 blog (https://c65gs.blogspot.com.au), specifically addressing those five points above.

So in the previous milestone, we had collected together all the errata, and actually also completed part of this milestone, by suggesting a number of potential solutions to various of the errata.  This milestone basically transforms that set of errata into a set of concrete design changes for the MEGAphone R4 PCB.

These changes can be largely be lumped into four groups:

1. Corrections to known problems with the MEGAphone R2/R3 PCB, e.g., problems with some of the power control circuits;

2. Improvements to the existing functions, that aren't so much fixing problems, as making things better / more logical, e.g., moving some of the switches around;

3. Adding originally planned but missing sub-systems, e.g., battery charge circuit; and

4. Adding the ability to use a Raspberry Pi Compute Module 3+ as an "Android Co-processor".

Now, the first three are probably no great surprise, but its worth explaining why we want to make it possible to include a Raspberry Pi Compute Module in the MEGAphone, especially when in the MEGA65 we have purposely avoided including any "big" processors.

As a geek and University Academic, I keep thinking about multiple possible uses for the MEGAphone.  First, it is simply a hand-held MEGA65, for retro-fun on the go.  Second, its a phone that you can trust, through the careful security design of the hardware, that isolates all the untrustable parts, like the cellular modem. Third, it is designed to support resilient communications, e.g., including UHF packet radios (or rather connectors for them), so that it can do mesh networking.  Fourth, I have been thinking for a while about the challenge for people who need accessible devices.

The challenge for accessible devices is that while certain kinds of disabilities are fairly well catered for, e.g., impaired sight or hearing, this is not the case for motor control impairments, where special input methods may be required. Think, for example, of Stephen Hawking, who in the latter part of his life controlled computers using a single cheek muscle.  One of the problems I see for people in such situations, is that computers keep advancing very rapidly, and that keeping up with the changes to computers -- or in this case, with mobile phones. We are all familiar with how quickly a phone becomes obsolete, and stops getting updates, and how hard it is to compile your own custom version of Android, let alone modify it to support some custom feature.

So what we have envisaged with the MEGAphone, is that we can have support for an upgradeable co-processor module that can run ordinary Android, unmodified. This means that as newer builds of Android for the module come out, or as the module itself is upgraded over time, the rest of the chasis of the phone can remain unchanged.  By using the FPGA in the MEGAphone to pretent to be a normal touch screen interface, we can make the acessibility layer live entirely in the MEGA65 side, with the Android instance not even realising that it is on the receiving end of an accessibility interface. That is, the user can upgrade Android as often as they want, and even upgrade the processor that it is running on as often as they want, and they won't have to worry about losing their accessibility customisations. 

Also, by having the accessibility layer in the MEGA65 side, it is much more tractable for end-users (or their support networks) to make fully customised accessibility interfaces that suit the capabilities and preferences of the user, rather than having to accept cookie-cutter accessibility solutions.  In this way, we hope to help support the dignity of people living with disability, and help them to more fully participate in the digital world, by allowing them to keep up to date in the mobile phone sphere.

We selected the Raspberry Pi to be this co-processor, as there is a very strong and long-term community around the Pi, including maintaining an up-to-date port of Android. For example, there is a commercial supplier of Android for the Pi, who offer ongoing automatic updates for 5€ per year. Or there are also multiple open-source initiatives as well.  The key here again is choice, which means dignity for the end-user.

If I had to guess the best option for making a sustainable commercial market for the MEGAphone, it would be this one around accessibility. Here in Australia we have a National Disability Insurance Scheme (NDIS) that would effectively be the customer, if we progress things sufficiently.  This is why we have had a student, Luke, working on an initial concept of this, based on the existing R2/R3 PCB, to see what might be possible.  Here is the 3D printed case and jelly switch connected on the MEGAphone's standard joystick port, to allow single-muscle operation:

 

Now, the above build is based on the R2/R3 PCB as I mentioned, which makes the whole thing bigger than necessary. It also uses a bunch of different switches than we would intend to use in the end, which also makes it bulkier.  But its a start as a proof-of-concept.

We already have partly implemented the single-muscle input method for controlling the keyboard of the MEGA65, to demonstrate that side of input accessibility.  Mouse/touch interface control would be the next, and the MEGA65's VIC-IV already has a hardware cross-hair indicator that could be used as part of that, to move the touch point, and toggle the touch up/down, thus allowing full control of a touch screen oriented device in this way.  

The D-PAD and other buttons on the MEGAphone are already much more disability friendly for those with impaired fine motor control, compared with having to use a touch screen. Also even if the device ends up relatively chunky, this is also an advantage in many cases, by making it much easier to manipulate the device with impaired fine motor control. 

Also, apart from the disability support use-case, we are also looking at the MEGAphone for resilient field data collection for disaster zones, using the planned built-in solar + large battery (which is also helpful for the disability use-case, by helping users to maintain charge in the device, and thus their ability to communicate, even in the face of negligence on the part of carers, which sadly, is a phenomena that does occur).  Having real buttons etc for input allows, for example, for the device to be used inside a water-proof or vacuum sealed pouch, allowing use in a wider range of disasters -- including in response to pandemic or other disease outbreaks, while keeping the device sterile and dry.  Again, the solar charging option allows the device to be used in such situations without having to ever break the seal on the pouch.

We have digressed a little, but hopefully, it gives some idea of the wider uses of the MEGAphone that we are thinking about. But let's dive straight into the set of PCB design changes that we are planning for the next milestone.  One of the more obvious changes, is that we will be making more use of mezzanine PCBs, to help keep the area of the PCB down. As there are already a bunch of things sticking up on the back of the PCB, the use of such mezzanines will not increase the thickness or volume of the device, but rather help to reduce them somewhat.

So anyway, let's just dive straight in:

General Comments

The PCB is already rather complex and congested. To the extent possible, it is desirable to reduce the complexity of the PCB, rather than increase it. For these reasons, including the significant development advantages of modularising some of the trickier outstanding parts, like the headphone jack and Bluetooth, the current plan is to use a number of mezzanine PCBs that will lie across the rear of the device adjacent to the battery. Given that the FPGA board is already a mezzanine board, this is not a great departure from the existing approach, and will not make the device any thicker or larger.

Otherwise, the changes that will allow the two D-SUB connectors to be moved back inside the PCB outline, the result will be a reduction in overall size. Significantly, it will allow the device to return to being only ~100mm deep. Expected depth will also be slightly improved, as the joystick port will not longer be located beneath the battery. This means that the battery can sit perhaps 7 – 9mm above the PCB, rather than the current 13 mm forced by the D-SUB. The PCB is 1.6mm thick, and the battery ~15mm thick. Front-side components are ~6mm thick, not counting any raised surrounds required around the buttons and DPADs. Front and rear case facings, including the rear solar panel, will add perhaps 5 mm more. This suggests a total thickness of around 35 mm, and not more than 40mm. Total length will be 220 – 225 mm, allowing for case surrounds, including indentations/covers for power switches and SD/SIM card slots. This is likely to be at the higher end, as having securable covers over the SIM and SD card slots makes considerable sense, and we are also likely to want at least some kind of simple tamper evident housing to help make evil maid attacks more detectable.

JTAG debugger for the FPGA board will not fit in a ~35mm thick case, but could likely fit in a 40mm thick case. For development versions, a removable hatch could be supplied to make connecting a debug interface easy. However for the same reasons of defending against evil maid attacks, it would be preferable to NOT have such a hatch in final units.

While FPGA pin count is a significant limiting factor to the design, we do not wish to replace the entire FPGA module with either a BGA-placed FPGA on the main PCB, or with a different FPGA board, e.g., one from Trenz with 200+ pins that we have found, because it would effectively necessitate a complete redesign of the PCB. Rather, for this new revision of the PCB, we want to focus on fixing the known problems, and implementing the remaining missing sub-systems. 

Now onto the planned changes:

1 Make assembly easier

There are lots of little resistors around the board of differing values, that are a bit of a pain to place on the PCB when assembling by hand.  As we expect many people to build their own PCBs over time, this would be nice to make easier.

1. Renumber capacitors and resistors to be more easily located on the board.

2. Consider having the numbers relate to the values, where there are some common values?

3. Consider putting sub-system suffixes on other sub-systems, not just modems.

4. https://au.mouser.com/ProductDetail/ROHM-Semiconductor/RS1G120MNTB?qs=npTsUczJOtMlfWBQYBagow%3D%3D parts tend to move during reflow due to asymmetric thermal pad on underside. Consider an alternative part that does not have this problem. Maybe these? https://www.digikey.com.au/product-detail/en/alpha-omega-semiconductor-inc/AO4484/785-1202-2-ND/2353867

2 Remove all intentional transmitters from the main PCB

For regulatory purposes, it is desirable for the main PCB to not be an “intentional transmitter”, that FCC/EC etc approvals are greatly simplified. This means moving the WiFi and BT modules from the main PCB to mezannines, which is explained later in this document.

The design changes for this will be described in separate sections below.

3 PCB Outline Changes

1. Return the PCB outline to the main rectangle, removing the extensions for the D-SUB connectors (ERRATA#20).

2. Make a notch in the PCB for the touch digitiser cable to be able to wrap around the edge, without being crushed. (ERRATA#2).

4 Remove Smart-Card Connector

Removing this frees up a lot of PCB space, and 2 FPGA pins.

1. Remove smart-card connector.

5 Speakers / Headphone Jack / BT Circuit Changes

Net PCB area change: reduction of 4 – 8 cm^2

The MEGAphone has both a headphone jack with audio in and out, and separate from that, 2W amplifiers for stereo internal speakers. These audio circuits are completely separate from one another, and both have problems that require rectification.

It may well be possible to eliminate the bulk of the headphone audio output circuit, using a simple R/C filter to knock out the high frequency components (>22KHz) of the signal, and just give it some reasonable amplification. Maybe a transistor on the digital signal to provide more current, and then the R/C filter would give reasonable sound quality? Would it be too inefficient, as the high-frequency energy would be dumped after amplification.

We suspect that the amount of high-frequency energy that is reaching the speakers with the current circuit design is also why the speakers in the MEGA65 get hot, and thus it would be beneficial to add additional high-frequency filtering to the internal speaker circuit.

Separately, we could move the entire audio circuit – including the BT module onto a mezzanine, so that these problems can be resolved asynchronously from the main PCB. This would also reduce pressure on PCB space. We would only need to have 3.3V, 5V, GND, UART RX/TX for BT, 4x PCM audio lines for BT and three lines for headphone jack = 12 pins. This would also help the BT antenna to be further from other components etc. The internal speaker connectors could be on the mezzanine board instead of on the main PCB.

The main challenge here is that the LCD panel is behind the PCB here. So as with the existing speaker connectors and WiFi header, we will need to make those pins flush, and provide insulation on the panel side of the PCB.

1. Consolidate the stereo speaker headers into a single smaller 4-pin connector to save PCB space (ERRATA#6). (Note that this will end up being on the mezzanine connector, instead of on the main board.

2. Design a mezzanine PCB that replaces the entire audio circuit, the BT module layouts on the main PCB, and that routes all necessary signals (ERRATA#8). This mezzanine requires 3.3V, 5V, GND, UART RX/TX for BT, 4x PCM audio lines and three lines for headphone jack, plus one extra for the headphone jack sense line and the two PDM audio lines for the stereo internal speakers. It should use a BM83 BT module in place of the existing RN52 for Bluetooth function (ERRATA#9).

3. Determine connector type and location for the mezzanine PCB, taking into account layout on the main PCB and stability of the mezzanine PCB during connector insertion/removal.

4. Ensure that the BT antenna of the BM83 hangs slightly over the edge of the main PCB outline for optimal performance (ERRATA#10).

5. Change the audio filter circuit for the headphones to something that more effectively blocks high-frequency noise to fix the excess background hiss of the current circuit (ERRATA#21), e.g.:
   https://github.com/MrBuddyCasino/ESP32_MP3_Decoder/blob/master/doc/filter_schematics.png
   or even the very simple:

   https://web.archive.org/web/20180423024219/https://janostman.wordpress.com/audio-hacking-with-the-esp8266/

6. Consider removing the audio amplifier for the headphones jack, if not required, i.e., if the new circuit is loud enough without amplification (ERRATA#22).

7. Connect headphone jack sense line to a spare I2C IO expander input pin, so that we can detect when headphones are connected (ERRATA#23).

8. Add additional high-frequency filtering to the internal speakers to block all energy above 22KHz.

6 MEGAphone Power Management Circuit Ideas

Net PCB area change: 0 cm^2

The CN3801 is a simple solar MPPT (constant voltage, which is okay, but not optimal) LiFePO4 charger IC.

There is a nice little design based on this that does exactly what we need:

https://easyeda.com/wagiminator/y-cn3801-lifepo4-solar-charger_copy_copy

This has battery protection, 5V step-up and the solar charge circuitry all in one. The only question, really, was whether the circuit is too big to fit on our board.

It should also allow charging from a normal boring USB mini/micro connector, admittedly at lower current than we can supply through a barrell connector. But USB charging might trump that. Or we can just add a microUSB power input connector parallel to the DC barrel connector, since it won’t take much space.

A further advantage of using this circuit, is that the DC barrel connector will be treated like the solar panel, and thus able to be up to ~21V, allowing use of a MEGA65 12V DC power supply. Appropriate over-voltage protection will be required when both DC and solar are active, if the solar panel is capable of generating >12V.

The PCB area is ~15.35 cm^2, but could probably be reduced to more like ~12cm^2. So it might be possible to rearrange the power connector corner of the PCB to smoosh it in, especially if we put a few of the larger easier to place SMT components on the reverse side of the PCB, where there is (a little bit of) space above the D-PAD, especially after the DPAD gets shrunk to its correct size.

The main challenge would be that the headphone jack and its amplifier and filter circuits would need to be moved – but we are already planning to put those on a separate mezzanine PCB, so this is not a problem.

Actually, we can do this much more simply and easily: Use this existing power module as a mezzanine PCB that sits adjacent to the battery over the corner of the PCB that has the DC barrel connector and battery connector. Indeed the battery connector can then be replaced by two a 2-pin IDC header that just run jumper leads to the power circuit, which then also directly connects to the battery. Thus we lose no PCB space.

The only issue would be making the mazzanine PCB sit stably, as it has no mounting holes through which we could fix it to stand-offs. It would not be hard to extend the PCB to include such stand-offs. It could also be extended to include a header for the power connections, and microUSB + DC barrel connectors. These would all be placed where the current DC barrel connector and battery bulk connector sit on the PCB, so that they won’t interfere with the Pi Compute Module slot (described later). If the DC barrel connector and microUSB connector are placed on the opposite side of the stand-offs to the rest of the PCB, this will help to counteract the mezzanine leaning down over the Pi CM too easily. Similarly, if we make the power header connector sideways and long enough, it will also help to stabilise in that axis.

Care will be required to make sure the stand-off hole(s) and header don’t line up with the D-PAD. Some creativity may be required here, as to working out the best placement, but it should be possible. There are already two stand-off holes in the general vicinity.

Overall, what we are proposing is to take this y-cn3801 based PCB, and adapting it to meet the above requirements:

1. Take the y-cn3801 PCB design, and modify it to include 2.1mm DC barrel connector (centre positive) and USB micro connectors, both of which are parallel to the solar panel input, and thus can be used to charge the single LiFePO4 cell. Provide a two pin 0.1” IDC header for the solar panel (ERRATA#24, ERRATA#25). It is possible (but should be verified) that all three of these can simply be connected in parallel (ERRATA#26).

2. Also modify this PCB design to be able to fit as a mezzanine PCB, located on the battery-side of the MEGAphone PCB in the corner where the current DC connector and battery connector are attached. Take care to ensure that the hole-throughs do not interfere with the D-PAD pads on the opposite side of the PCB.

3. Add the means to measure the battery voltage to the main PCB, so that the level of charge can be determined (ERRATA#27). There is considerable freedom as to how this could be done. One approach would be to add a 2^nd LIS3DH accelerometer, and use one of the ADC inputs of that to monitor the battery.
   If this ADC is placed on the power mezzanine, this would give it separation in the X, Y and Z axes, and allow the two ADCs in combination to detect rotation as well as orientation, which while not a core requirement, would be a pleasant side-effect of solving the battery voltage monitoring function in this way. This would require connecting one of the I2C busses to the power mezzanine, and selecting an appropriate available I2C address for the accelerometer. The existing LIS3DH would then ideally be moved as far as possible towards the opposite corner of the PCB to maximise the ability to detect rotation.

4. While tending to the LIS3DH accelerometer, the current circuit has the sense of the interrupt lines reversed. Correct the sense of this circuit, or no space, remove it (ERRATA#36). It would be desirable to connect the interrupt pins on the newly added LIS3DH as well, as this could be used to trigger an interrupt to wake up the phone when the battery level increases to a certain level.

7 Power Switch changes

Net PCB area change: reduction of ~1 cm^2

It feels a bit weird having two of the power switches on the top edge, and four down the side. We should probably move the two at the top to the same side as the other four. There seems to be space – unless routing congestion causes problems.

As the space on the edge where the switches currently sit is relatively useless, this effectively frees up the space previously occupied by these two switches.

1. If possible, move the two power switches from the top edge of the PCB to the left-edge of the PCB. If the PCB must be widened by upto 2mm to accommodate this, this would be acceptable.

2. Swap pins 1 and 3 of S7, so that the "on" position is "on under control of the power control circuit" and "off" is truly off (ERRATA#39).

8 NOR OTP Flash + IO Expander U12

Net PCB area change: reduction of ~2 cm^2

These can most likely, and should be moved to the reverse side of the PCB, as both can be placed relatively simply using hot-tweezers or other soldering techniques, without requiring double-sided relow. This will free up a little bit of space.

1. Move the NOR flash to the reverse side of the PCB (ERRATA#41).

2. Move IO Expander U12 to the reverse side of the PCB (ERRATA#41).

3. Connect the SI and SO pins of the NOR flash to pins on the U12 IO expander (ERRATA#40).

9 LCD & Panel Touch Connector Relocation

Net PCB area change: reduction of ~3 cm^2

1. Remove the currently routed 6-pin FLC connector for the touch panel, and the 6-pin FLC connector near the bottom of the PCB, but not the one nearest the bottom of the PCB, which is to be retained (ERRATA#5).

2. Remove the smaller of the two slot-holes in the PCB, and the two extra 6-pin FLC connectors to free up some PCB space (ERRATA#29). This will be somewhat offset by having to route the I2C lines further to get to the connector’s new position.

3. Move the remaining 6-pin touch panel digitiser connector 2mm in the direction of the D-SUB9 joystick port (ERRATA#3).

4. Move the 40-pin LCD panel connector 10mm further towards the top of the board (ERRATA#1).

10 Touch-screen 6-pin connector footprint wrong

The mounting pads are wrong for the connectors we are using, resulting in inadequately stabilised connectors prone to ripping off, and taking tracks with them. Work around is to hotglue them down, but on next PCB revision we should just fix them.

1. Ensure the footprint and connector for the 6-pin FLC connector for the touch screen match. This should be a piano-hinge type connector, as other forms of FLC connector have been tested, and proven to be a royal pain to insert.

11 LoRa Modules

Net PCB area change: 0 cm^2

We should replace these with ones based on the RNode, which uses a much newer chip, and are Arduino compatible. It’s not clear what the net difference in PCB area will be. It is likely to remain similar. It may be that one STM32 is sufficient to control both LoRa chips, which would also free up two FPGA pins, which is a rather attractive proposition.

1. Replace the on-board LoRa radios with a single header connector that can be used to connect an arbitrary packet radio module (ERRATA#12). This connector should be compatible with the RFD900 packet UHF radio.

2. Design an Rnode compatible PCB that can be fit to this header connector, and still fit beneath the battery (ie no higher than the other components under the battery, and not physically overlapping with other components in the region, and with the antenna protruding just beyond the edge of the main PCB, if possible.

12 Q15 Fix

Q15 is a MUN5233 on the R2 board, and the bodge fix that was made apparently is a BSS138. This should be updated on the new PCB. See section 5.1.7 of Lucas Moss’ thesis for an explanation of the problem, and the temporary fix used there.

1. Replace Q15 with a BSS138, including any consequent corrections required (ERRATA#44).

13 Replace VGA with HDMI interface

Use the HDMI circuit design from the MEGA65 R3 PCB schematic to implement HDMI, freeing up a number of pins (ERRATA#4). We need to verify that the necessary signal integrity is possible via the standard .1” IDC headers for this. This may mean that the first step is to make a small test PCB that has just an HDMI connector that can connect to the TE0725 via its IDC headers, in the same location as would be required on the complete PCB.

1. Replace the VGA interface with HDMI interface based off the MEGA65 R3 PCB (ERRATA#4).

14 Relocate and verify orientation of ESP8266 Connector

1. Relocate and reorient this connector so that the wifi antenna would hang slightly over the top edge of the PCB (ERRATA#7).

2. Verify the pinout and chirality (correct side of mirror/PCB orientation) of pinout for the ESP8266 to attach to the rear (non-panel) side of the PCB (ERRATA#7).

3. Connect RST and all other open pins on this connector to spare I2C IO expander pins.

15 Use Opto-Isolators for improved power isolation

Back-flow through a number of the circuit interconnections result in sufficient voltage and current to allow some components to continue to operate when their VCC is shut down. The issue is that voltage can flow from powered on components to components that are supposed to be powered down. Thus it is pins that are inputs into the various power domains that are the primary problem. However, any output that has pull-up external to the power domain will also require isolation.

1. Identify all pins that can potentially leak current between the various power domains.

2. Add opto-isolators or some other means of isolation on all mono-directional signals between the different power domains (ERRATA#11).

3. Audit the final design for current leakage between the different power domains.

16 Verify microSD card connectivity

The test PCB had an assembly fault, that means the microSD card could not be properly tested.

1. Confirm correct layout of microSD card, and remediate any problems identified (ERRATA#13).

17 M.2 Expansion Bays

Net PCB area change: ~1-2 cm^2

There is conflicting information on the correct voltage for the UART voltage for these. We have been using 3.3V, and it seems to work, but according to the EC-25AU documentation, they should be 1.8V.

1. Move M.2 UART connections to use voltage level converters, with a mechanism to select either the 3.3V or 1.8V domain (e.g., via PCB jumper pads) (ERRATA#14, ERRATA#15). The existing voltage level conversion circuits used on other pins of the M.2 bays can be used as a model for the voltage conversion.

2. Add pull-ups to VCC_FPGA on the RI lines on the M.2 bays (ERRATA#37)

3. Examine and correct the circuit for Q2_M1 and Q2_M2, if required (ERRATA#38). See the blog post for explanation of the problem.

18 Real Time Clock

We have proposed switching the real-time clock to match that used on the MEGA65 R3 PCB. However, this is not necessary, and to avoid (further) unnecessary changes to the PCB, we will leave it as it is. Thus we are NOT acting on ERRATA#16.

19 D-SUB9 Joystick Port

1. Copy the POT-X/Y circuitry from the MEGA65 R3 PCB (ERRATA#17)

2. Allow the FIRE line of the joystick port to be controlled and read at high-speed, by using 2 FPGA pins: one to read the level-converted FIRE input, and the other to control a transistor that can be used to pull the 5V side of the FIRE pin to GND when activated. Retain the existing connection to the I2C IO expander (ERRATA#18).

3. Move the D-SUB9 connector to the approximate position of U24, so that it can fit in the main rectangular outline of the PCB (ERRATA#19).

20 D-Pad

In short: The spacing between the pads is currently 18mm, but should be 16mm.  The outline hole positions for retaining the light green contact part must also be reduced. The distance between these should be 30mm, rather than the 40mm on the current PCB. The outline of the circle should have a diameter of 29mm, cropped at top and bottom to 27mm. See the blog post for more specific information.

1. Fix the position and markings of the D-PAD, including orientation holes (ERRATA#28).

2. Replace the two small thin black buttons with another pair of round pads, as described in the blog post (ERRATA#29).

3. Swap the function of the existing pair of round pads and the two thin black buttons (ERRATA#30).

21 Thumb-wheel knobs

We had a terrible time trying to work out the correct resistance to get full range of motion being detected on the volume wheels. Thus we wish to replace all the fixed resistors for the voltage dividers with trimpots, so that we don’t have to worry about this.

1. Replace R46, R47, R48, R67, R68 and R70 all with 1K resistors, and place 50K Ohm trim-pots serially with each of those resistors (ERRATA#31).

2. Change VCC_FPGA to VCC_MIC for the thumbwheels (ERRATA#33).

22 Indicator LEDs

One of the buttons on the PCB causes LEDs either side of the LCD panel to illuminate if the relevant sub-system is powered. However the carbonised rubber buttons have high resistance, which is also somewhat proportional to the pressure on the button. This causes the indicator LEDs to vary in brightness with pressure, and between one another, because of the way the circuit is currently structured. It would be better to digitise the button, so that constant voltage and current is supplied to the indicator LEDs.

There is also some problem with the VCC_MIC power rail, as described in the blog post and referenced in ERRATA#34. It is quite possible that adding isolation among the different voltage domains will correct this problem.

1. Digitise the indicator button input to deliver constant voltage/current to the indicator LEDs (ERRATA#32).

2. Investigate the whole VCC_MIC power rail and associated indicator LED circuit for correctness, as something is clearly wrong with it (ERRATA#34).

23 Infrared LED Receiver

1. Add a TSP382-series or similar IR LED receiver using last spare FPGA pin (ERRATA#35).

2. Verify that the specified IR TX LED is compatible with this receiver.

24 Raspberry Pi Slave Processor

An anticipated criticism of the MEGAphone will be that it cannot run modern phone apps, e.g., designed for Android. This problem is largely resolvable by allowing the attachment of a slave processor that can run an Android instance. One approach to this is to use a Raspberry Pi Compute Module for this purpose. The latest revision of this board contains 32GB onboard flash, and thus does not require an external SD card. There is also a "lite" version that does use an external SD card slot. As we have an unused SD card slot on the 2nd SIM card/SDcard slot, it probably makes sense to use the "lite" version.

The compute module itself is 68mm x 30mm compared with the 60mm x 40mm footprint of the Smart card. There are vertical and horizontal connectors. The horizontal connectors are preferable.

Basically the idea is to add a Raspberry Pi with its digital VGA output in parallel to the MEGAphone’s own digital VGA output, with these two being muxed to the LCD panel. Several of those signals, in particular HSYNC, VSYNC and PIXELCLOCK need to also be available to the FPGA as inputs, so that the MEGAphone can synchronise with the Pi’s display for displaying composited over-lays, e.g., for call notifications. Some creative re-use of existing inputs is required to achieve this. The current plan is to multiplex four input lines from the M.2 modem bay with these four signals from the Pi. The multiplex control can be driven from a spare pin on an I2C IO expander. The M.2 UART RX, PCM DATA OUT, PCM SYNC can be the 3 pins that are multiplexed for this.

Refer to the blog post for more information on what is being considered here.

1. Remove the smart-card connector.

2. Add a connector to accept a Raspberry Pi Compute Module and associated interface circuitry (ERRATA#42). This should be powered from an independent VCC_PI, which can be hard-switched by the same switch that controls the power to the 2^nd M.2 module, but with an independent soft power cut circuit. See https://www.raspberrypi.org/documentation/hardware/computemodule/datasheets/rpi_DATA_CM3plus_1p0.pdf for information about the power control requirements for the Pi, including the sequence of power on.

3. Multiplex the Raspberry Pi and MEGAphone’s digital video interface to the LCD panel, with multiplexor control via an FPGA pin.

4. Multiplex the Raspberry Pi’s HSYNC, VSYNC and PIXEL CLOCK lines as described above, with the selection pin coming from an I2C IO expander, so that the FPGA can read these signals at high speed.

5. Add a multiplexor to the touch panel I2C bus, that allows the FPGA to connect to the Pi’s I2C bus or to the touch panel I2C bus. Note that the Pi cannot directly connect to the touch digitiser, as we intend to have the FPGA provide synthetic touch events to the Pi (ERRATA#43).

Summary

The above changes explicitly indicate which errata they address, so that I could check in the reverse direction, that all errata are covered.  Together with identifying the design and component changes, this covers the first of the five requirements of this milestone:

• Combine the errata identified in sub-task 2, together with consideration of the functional requirements of the revision 3 milestone, and identify the design and component changes that this entails to achieve that goal.

This also has also dealt with the next three, to the extent that this is possible:

• Determine the revised intended specifications of the device. 
• Determine the revised list of sub-systems required to achieve this
• Identify the changes to the Bill of Materials for the revision 3 device
• Sketch out possible schematic changes / PCB floor plans for each of the above, accepting that they may not be final.

We are currently talking with a contracter to do the actual PCB layout, which is focus of the next mile-stone, so it is counter productive to define the PCB floor plan more finely than we have done in the above text.

So indeed, the next step is to get the next PCB revision completed, so that we can then get some prototypes built up from that, and get the MEGAphone hardware working to the point where it can be shared with the community more widely, so that we can move onto the software side of development -- which is all very exciting :)